Subject: Re: [MOBILE-IP] handover

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

>
>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.

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.

PatC

---

From: Gerald Maguire <[email-masked]>
Date: Wed, 26 Apr 2000 20:28:24 +0200

>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

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: "Andrew T. Campbell" <[email-masked]>
Date: Wed, 26 Apr 2000 15:22:24 -0700

> knows that a hand-off will occur before the MN would.

Pat this is not the case. Rather the opposit is true. Network controlled
handoff
and mobile assisted handoff call for the interaction with a central
controller
to drive handoff based on measurements supplied by the mobile/base.

In contrast, mobile controlled (or initiated) handoff drives the whole
deal itself and is as fast
if not quicker and its fully decentralized. We implemented multiple
schemes
in our testbed and the results (which are intutive) bare this out.

---

From: Thomas Kuehnel <[email-masked]>
Date: Wed, 26 Apr 2000 16:11:57 -0400

Hello:

There may be other reasons for a network to control the handover-process
like:
 - load balancing
 - roaming agreements in a multi-service provider environment
 - handover between different technologies WLAN - 3G
 - soft-handover support in CDMA systems

Cheers, Thomas

-----Original Message-----
From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
[mailto:[email-masked]]On Behalf Of Andrew T.
Campbell
Sent: Wednesday, April 26, 2000 6:22 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] handover

---

From: Gerald Maguire <[email-masked]>
Date: Wed, 26 Apr 2000 23:19:21 +0200

Thomas Kuehnel <[email-masked]> wrote:

Load balancing can be done in distributed manner, the base stations
only have to provide the appropriate information (such as current or
future prices for service) and the mobiles can start moving out or
moving in (depending on the pricing).

Roaming is an issue of AAA and a mobile can make use of any
infrastructure that will give it service -- so if any service provider
wants to service the mobile it can (if the mobile decides to ask it
for service).

I think that the mobile is best equipped to do the WLAN to (2G or) 3G
handover - the best part is that the 3G operator doesnot even have to
know of the existance of the WLAN. Also by allowing applications in
the mobile to be aware of the impending change from WLAN to WAN then
they can do things, such as quickly finish the transfer of the file
which is being moved, adapt their performance and data requirements,
... . Note that mobile can notify the WAN via the WLAN that it is
going to want service and thus the WAN system can start to allocate
resource, do authorization, etc. all before the mobile arrives
(perhaps using even lesss control channel capacity).

    - soft-handover support in CDMA systems
While adjusting the arrival times of the wavefronts from multiple base
stations can't easily be done by the mobile, the mobile can invoke
IP simulcasting from multiple base stations and then as long as at
least one copy of a packet makes it to the mobile it will not loose
any data and thus can achieve a soft-handoff.

So I'm still not convinced that there is a need to the network to do
handover control.

Chip

---

From: Jim Willkie <[email-masked]>
Date: Wed, 26 Apr 2000 14:26:49 -0700

> - soft-handover support in CDMA systems

this last one, "soft-handover support in CDMA systems", is not a viable
reason. Soft handoff occurs within cells of a single system. Although it
may be possible to have architect a CDMA network that has separate PDSNs
for cells within a single base stations it is not practical nor would there
be a benefit to doing so.

Jim Willkie

---

From: Arthur Ross <[email-masked]>
Date: Wed, 26 Apr 2000 14:38:32 -0700

>stations can't easily be done by the mobile, the mobile can invoke
[snip]

Au contraire! That's EXACTLY what they do, at least in the North American
system. It is one of the things the pilot is there for: to help determine
the multipath delay spectrum so that diversity combining can be done.

They despread with multiple correlators, and do true maximal ratio coherent
combining of the code symbols that result - very effective in improving
error performance, provided there are multipath components with not-greatly
different amplitudes and independent fading. Otherwise, not very helpful.

One reason for implementing the receiver that way is that the same
machinery can be used for soft handoff, which is, in a sense, artificially
created multipath. The SHO components can be combined in almost exactly the
same way.

>So I'm still not convinced that there is a need to the network to do
I'm not either, but that's in distinct contradiction to the way those air
interfaces are designed.

   -- Best
   -- Arthur

   Dr. Arthur H. M. Ross
   2325 East Orangewood Avenue
   Phoenix, AZ 85020-4730
   Tel: 602-371-9708
   Fax: 602-336-7074
   Portable (CDMA, of course!): 602-677-1021

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Apr 2000 10:19:47 +0900

Regarding Andrew's proposal to standardize an API for Mobile IP

which I certainly support, however I am a bit confused whether this should preempt

the continuing standardization process on Mobile IP.

  If we take IPv6 as an example, IPv6 has been standardized in several RFCs and

an Advanced API was also standardized to develop applications using IPv6 in a platform

independent manner. IPv6 advanced API is now supported by all major OSs including

Microsoft.

  Can someone clarify this please?

--Behcet

---

From: Jim Bound <[email-masked]>
Date: Wed, 26 Apr 2000 22:25:32 -0400

the Basic API is supported on all IPv6 implementations.  The advanced
API had to go back to the drawing board as it has more internal system
features associated with it than the base API (e.g. ancillary data from
the kernel, messing with header option alignments, etc...).  Both are
"Informational", both have been a valuable learning process for the IPv6
working groups and both APIs are useful to implementors.

the problem we may be facing here is that what we need is a base api to
link-layers.  It may be we can only specify the behavior of the api for
link-layers as the point is to have this happen before Mobile IP sees it
really and that regardless of the link-type the same stuff is passed to
the proverbial ip_input buffers when Mobile IP is seen (even on the
tiniest MNs and even in RTOS stacks).

and then it should be made extensible if we don't want to mess with all
aspects then for each link-type a MIPoverFOO-Link is defined by some
other info doc.

/jim

---

From: Tom Weckström <[email-masked]>
Date: Fri, 28 Apr 2000 12:29:22 +0300

Hello,

I divide the handoff types accordting to which element initiates the HO:
- Network controlled handoff
- Mobile assisted, but network controlled handoff
- Mobile controlled / mobile initiated handoff

Mobile IP currently does the mobile controlled handoff.
Chip described the power of this solution very well, thanks Chip. :)

I suggest we still use the mobile controlled method.
Practical tests have shown that this method is also quite effective at
least in IEEE 802.11 WLANs.

Regards,
        Tom

On Wed, 26 Apr 2000, Andrew T. Campbell wrote:
~
campbe >Patrice Calhoun wrote:
campbe >>
campbe >> >
campbe >> >Furthermore, I really like the idea of MN being able to decide about
campbe >> >the handoff. It brings some freedom to the MN, and doesn't add
campbe >> >complexity to the network, which makes the network faster/more robust.
campbe >>
campbe >> While I agree that having the MN determine whether a hand-off is necessary
campbe >> or not, does simplify the network (somewhat), it does significantly increase
campbe >> the delays associated with the hand-off. This is simply because the MN can
campbe >> ONLY know that it needs to hand-off when it is too late. Ideally, the network
campbe >> knows that a hand-off will occur before the MN would.
campbe >
campbe >
campbe >Pat this is not the case. Rather the opposit is true. Network controlled
campbe >handoff
campbe >and mobile assisted handoff call for the interaction with a central
campbe >controller
campbe >to drive handoff based on measurements supplied by the mobile/base.
campbe >
campbe >In contrast, mobile controlled (or initiated) handoff drives the whole
campbe >deal itself and is as fast
campbe >if not quicker and its fully decentralized. We implemented multiple
campbe >schemes
campbe >in our testbed and the results (which are intutive) bare this out.
campbe >
campbe >
campbe >>
campbe >> PatC
campbe >

--
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                [email-masked]
                                http://www.cs.hut.fi/Research/Dynamics/

---

From: Claude Castelluccia <[email-masked]>
Date: Fri, 28 Apr 2000 11:39:43 +0200

Hello,

I think you've forgotten probably the most useful type:
-Mobile controled, but network assisted...

regards,

Claude.
--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Tom Weckström <[email-masked]>
Date: Fri, 28 Apr 2000 13:35:12 +0300

On Fri, 28 Apr 2000, Claude Castelluccia wrote:

claude >Tom Weckström wrote:
claude >>
claude >> Hello,
claude >>
claude >> I divide the handoff types accordting to which element initiates the HO:
claude >> - Network controlled handoff
claude >> - Mobile assisted, but network controlled handoff
claude >> - Mobile controlled / mobile initiated handoff
claude >>
claude >
claude >
claude >Hello,
claude >
claude >I think you've forgotten probably the most useful type:
claude >-Mobile controled, but network assisted...

True. I forgot this one. I think I forgot this because it is so deep in my
thinking that network always assists in handoffs. Maybe there are
situations, in which network does not assist...

Regards,
         Tom

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 28 Apr 2000 07:29:35 -0700

> claude >> I divide the handoff types accordting to which element initiates
> the HO: claude >> - Network controlled handoff
Sure, like Mobile IP. The network really doesn't assist in any way, shape or
form. All it does is issue beacons, and it is completely up the mobile to
perform the hand-off. While I still believe that the mobile should be the one
that does the registration, it would be nice if the network elements were
aware of movement, and setup some resources in advance. This way, when the
mobile comes to the new cell, registration still occurs, but we could be ready
to deliver packets to it. Of course, if no registration is issued, we would
timeout and free the resources.

Now I am not proposing that Mobile IP support movement detection using signal
strength, or any other method. What I am proposing is that the existing link
layers do this, and trigger events in Mobile IP when they do. This way, we can
keep Mobile IP layer-2 unaware. Perhaps the API mentioned earlier would state
what events Mobile IP expects to receive, and would be a good start.

PatC
PatC

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Fri, 28 Apr 2000 12:15:59 -0700

"[email-masked]" wrote:

> aware of movement, and setup some resources in advance.

"Connectivity" is the only "resource" in IP networks and it looks
like it will stay that way for sometime to come. So
"setup some resources in advance" is moot.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 28 Apr 2000 09:12:17 -0700

> "setup some resources in advance" is moot.

read resources as delivering packets to the mobile. That is the only "other"
resource in IP networks.

PatC

---

From: Arthur Ross <[email-masked]>
Date: Fri, 28 Apr 2000 14:17:36 -0700

At 12:15 -0700 04/28/2000, Andrew T. Campbell wrote:

>"setup some resources in advance" is moot.

RIGHT ON Andrew! This is pretty much the point that I have been quietly
trying to raise behind the scenes. There is big time disconnect between
the various air interface models, and this, the fundamental notion of
IP networks.

I think perhaps it is time to organize a very fundamental discussion
of:

1. What problem(s) are being solved [business problems, that is], and
...

2. What can/should to be done to bring the various extant air
interfaces into alignment with the IP model/philosophy/mindset, or to
reconcile these fundamental disconnects between them and MIP.

Chip Maguire said:

>Operators of networks that consistently fail to accept users wanting

>to use their services will find that other operators will build
around

>them (i.e., users will occasionally upload data about where they were

>not able to get service and a wise ISP will install an access point

>there with a time inversely proportional to the number of users with

>this same complain and directly proportional to their desire to

>support the set of customers who report this specific lack of

>service). Now you might ask, "Why would an operator install more

>capacity?" -- the answers include: (1) keep this customer, (2) take

>market from their competitors, ... .

This bears on #1, as it may not always be
<underline>possible</underline> for the competitor to "build around,"
depending on how the business problem and regulatory questions are
resolved.

As I have said quietly to several of you, I think the best technical
solution would be what I call the "Minimalist" Air Interface, which
could be created, ab initio, with the sole (primary?) purpose of
providing that basic physical layer connectivity for MIP. The existing
3G air interfaces are all based on the network-centric voice services
model, band-aided to support packet traffic, but not in a way that
takes much advantage of the underlying philosophy/characteristics of
IP.

>But to do "resources" the Mobile IP working

>group will have to digest DiffServ.

>(And that is an issue we won't want to fire up on the list

>right now). Needless to say, there are major

>difficulties when applying such a QOS

>paradigm to wireless and mobile.

These QoS issues must be part of that definition, especially if support
of VoIP is a goal. And yes indeed, they are major and fundamental.
There are also serious regulatory implications in addition to the
obvious business implications.

Sorry for playing the role of a sort of verbal bomb-throwing anarchist,
but I just can't stifle myself any longer. I do think that there is a
VERY interesting debate ahead, as it is going to be very difficult,
IMHO, to carry out Phil's charge:

>Monday we reinitiated the discussion of fast handover support for

>Mobile IP.  We proposed adding the following line to the charter:
'Develop

>an access technology independent method for supporting low latency
handover

>between access points within a system or across systems.'

... given the wide disparity in the design philosophies & details of
these air interfaces, the fact that that support will be an applique to
"existing" standards in most cases, and the potentially nightmarish
nature of inter-technology handoffs.

   -- Best regards,

   -- Arthur