Re: [RRG] Re: Supposed impossibility of scaling for mobility

["William Herrin" <bill@herrin.us>]

On Thu, Mar 13, 2008 at 9:23 AM,  <hannu.flinck@nsn.com> wrote:
>  >On Wed, Mar 12, 2008 at 3:00 PM,  <hannu.flinck@nsn.com> 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 herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com 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