Subject: Re: [MOBILE-IP] handover

From: Patrice Calhoun <[email-masked]>
Date: Wed, 26 Apr 2000 11:45:50 -0700

Ah, it seems as if I wasn't quite clear in my response. I wasn't proposing that
the Mobile no longer participate in the hand-off. In fact, it does need to do
so, however, I believe that if the network is ALSO pro-active, then we can
reduce the hand-off process.

An example, if a new FA could setup resources in advance, and register with
a parent (or anchor) FA BEFORE the MN registers, then the hand-off process
will have minimal delays. However, the MN should still register as it did
before, but we could deliver packets to it before the registration is done.

Jim and I will update our proposal in the next week, to make this clearer.

PatC
>    >
>    >Furthermore, I really like the idea of MN being able to decide about
>    >the handoff. It brings some freedom to the MN, and doesn't add
>    >complexity to the network, which makes the network faster/more robust.
>
>PatC: While I agree that having the MN determine whether a hand-off is
>necessary
>      or not, does simplify the network (somewhat), it does significantly
>increase
>      the delays associated with the hand-off. This is simply because the MN
>can
>      ONLY know that it needs to hand-off when it is too late. Ideally, the
>network
>      knows that a hand-off will occur before the MN would.
>
>However, this is not necessarily true. To begin with, only the mobile
>really knows what it can hear/sense, the infrastructure only know what
>it is told by the mobile or what it can _infer_ from listening. If a
>mobile has multiple interfaces, it may or may not have a way to tell
>the infrastructure about these interfaces -- but it can certainly make
>a local decision of which interface it wishes to use. Unless this
>mobile node (or another mobile node which visited earlier) tells a
>given infrastructure system about the existance of another
>infrastructure which could be able to this mobile how can the various
>infrastructures know about each other. For example, there is no method
>of telling the IEEE 802.11 network access point that at this moment my
>notebook happens to have a better access via an IrDA link than it does
>via the the 802.11 access point that is on the same desk. But this is
>easily handled at L3, but making the route via the IrDA interface
>preferable to the link via the 802.11 interface. But should I set a
>glass of tea in the way of the IR link, the notebook can easily use
>the radio link.
>
>Of course there are way to have the various access points build a
>model of the world, but it is the mobile that directly senses this
>world -- hence the access points only have secondhand knowledge.
>
>As to the time when a mobile could make a handoff decision, there is
>no reason that you can't have a mobile initiated handoff. In the case
>of IR and Radio above, the mobile node can listen to the radio and
>listen via other interfaces. If IrLAN were not backwards -- the mobile
>could listen for IR access points, rather than having to probe for
>them {but this is an error in the design of the protocol not
>necessarily inherent to the link or interface}.
>
>However, it is a practical problem that currently most WLAN DS-SS
>receivers don't have an additional correlator to listen to other
>spreading codes in order to be able to determine if there are other
>access points available. Again there is nothing in the link which
>would require that only infrastructures have the information needed to
>initiate handoffs.
>
>With respect to the handover delay, it is clear that the time to
>detect that you should do a handover is a limiting factor in the time
>to do a handover (as J-O Vatn's thesis shows). However, this operation
>can be done in the background based on L2 information, information
>about the user's tasks and intentions, ... . Thus you _don't_ have to
>wait until "it is too late", and you have lost your current
>connection. However, to do this well means that we have to get more
>information from the interfaces and encourage the interface
>manufacturers to design their hardware and software with an eye to
>providing both this information and in some cases the ability to use
>{especially receiving} multiple links at the same time via an interface.
>
>Finally, it is only the mobible that can know what the mobile wants to
>communicate - hence the mobile can make a decision about urgency,
>energy consumption vs. available battery power, etc. So until the
>energy available at a mobile stops being a concern, it is the mobile
>that should be supported by the infrastructure (which has plenty of
>energy and other resources).
>
>Chip

---

From: Jim Bound <[email-masked]>
Date: Wed, 26 Apr 2000 21:45:39 -0400

Pat,

There are many link-layers to consider and some are not even defined
today.  Also variant MNs will exist so how does one specify the
link-layer?  But if its doable great love to see it.

Could we please get some Nokia and Ericsson product engineers building
the products here and now to participate in this decision process or I
fear, people won't wait, and we will have yet another wap type forum
with solutions we did not develop here in the IETF.  Most implementors
on this subject are not going wait to long on our process for 2.5G.

As far as the API I think a basic one that is Informational Only is a
good idea and a reality check as we review it for the working group. It
forces us to see implementation details we may not see otherwise and its
worthwhile just for that purpose.  I do not think we should try to
standardize APIs (anywhere in the IETF).

As far as the bear / bull paradigm (good one I thought).  I think after
looking more at bull solutions this:  bull long term and bear short term
(being this year and next for deployment).

regards,
/jim