On Thu, Mar 13, 2008 at 9:23 AM, <[EMAIL PROTECTED]> wrote: > >On Wed, Mar 12, 2008 at 3:00 PM, <[EMAIL PROTECTED]> wrote: > >> Routing and mobility act on different time scales. 5 - 10s handovers > >> are not acceptable in any working system. \ > > > >Hi Hannu, > > > >Is "handover" a necessary part of a mobility system? > > Yes. Otherwise it is not a mobile system, but wireless extension of > fixed access. Right?
Hi Hannu, I don't think so, no. Handover is the routing technology which enables mobility in a circuit-switched network. Circuit-switched networks are necessarily single-homed: your voice channel can only take one path at a time. The mobility routing challenge is amounts to this: how do I re-terminate the tail of my circuit from this base station (wireless tower) to that base station while minimizing bit errors on the circuit's continuous stream? We give this re-termination process the name "handover." If those pre-conditions (circuit switched, single homed) don't hold then handover may be a suboptimal or even non-functional way of implementing mobility. Clearly those preconditions don't hold for TCP/IP: it's packet-switched and is as happy multihoming as singlehoming. > >What about an add/drop model where a mobile device adds a new > >base station when it comes into range and later drops an old > >base station that's leaving range? > > Not sure what do you mean by adding a base station. Do you mean that > mobile device discovers a base station and adds that into its own > configuration? Or does the terminal itself become a base station > starting to offer services to others? Or adds the base station to the > global mapp encap database. Base station = wireless tower. * Recast mobility as a granular multihoming problem rather than a circuit re-termination problem. * A mobile TCP/IP device need not associate with only one tower. It can associate with as many towers as are in range if desired so long as it's hardware allows it to receive from all of those towers simultaneously. This drastically changes the character of the multihoming problem. In a packet-switched network, mobility can be recast as a granular multihoming problem rather than a circuit re-termination problem. Suppose we make the mobile device's EID reachable through multiple network paths leading to towers that may be topologically and administratively distant from each other. Typical multihoming, in other words. When the mobile device detects a new tower in range, it authenticates itself to that tower and then adds the tower to its multihoming set. This change in multihoming state propagates through the routing system after which the device is reachable from the new tower as well as from all of the other towers in its current multihoming set. When the mobile device notices that the signal is getting weaker for one of the towers in its multihoming set, it announces a routing change saying that tower is no longer offers a valid path for packets addressed to the mobile device. That routing change propagates through the routing system after which nobody attempts to conact the mobile device via that tower. The delay characteristics in what I'm calling the "multihoming add/drop" mobility model are _very different_ from the handover model. Delay is nearly irrelevant for an "add." For a "drop," the routing change has to completely propagate between the time that the mobile device notices that the tower's signal is getting weaker and the time that the mobile device loses the tower's signal. That need not be anywhere close to the instantaneity required by the "handover" model. If the device can reliably detect that it's losing the tower's signal 10 seconds before it actually does lose the signal then it's perfectly acceptable for the routing change to take 10 seconds to propagate. > >Need a mobile station receive on only one > >channel at a time? > > No, but this depends the type of the radio and the coding used. > > But how do these questions relate to the scalability and how the mapping > data is distributed? If mobility can be recast as a granular multihoming problem with a modest propagation speed but a high churn rate, would it not it be a good idea to see if our mapping system can support granular multihoming with a high churn rate? Surely mapping approaches which support granular multihoming with a high churn rate should then be viewed favorably versus those which do not. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
