Subject: Re: [MOBILE-IP] IPv6 handover document

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 18 Aug 2000 01:17:54 +1000

Here is my understanding about the different between fast, smooth and
seamless handoff. Please correct me if I am wrong.

I feel smooth handoff and seamless handoff are the same, they describe the
handoff in the way what we want it achieve, i.e., minimized packet loss.
In basic MIPv6 smooth or seamless handoff is achieved through establishing
forwarding from a previous care-of address.

Fast handoff on the other hand describe how we can achieve it. Fast is
compared with basic MIPv6 in the sense that it will overcome the router
advertisement interval limit. Here I schemed one way of Fast handoff, I
call it Link Layer Assisted Fast Handoff.

=> Fast Handoff (as far as I am aware) was designed to reduce packet
loss AND reduce latencies in packet delivery due to handoffs by
anticipating MN's movement early, before it arrives at the next AR.
I'm referring here to the definition in :
draft-elmalki-mobileip-fast-handoffs-02.tx

I guess some L2 help is always needed to make a realistic handoff.
(ie. avoid these RA beacons).

>So MN will start fast handoff process when it is in active movement.
>MN will constantly measure signal strength of message received from
>current router, if it is lower than some threshold value (t1), MN will
>then send a router solicitation message in hope of receiving a router
>advertisement. In this way, MN can overcome the Router Advertisement
>interval limit, thus speed up handoff process. MN may then receive
>more than one Solicited Router Advertisement from neighboring routers.
>After compare the signal strength of current router (sc) with the one
>received earliest from new router (sn), MN can then decide to perform a
>Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise
>MN will send another Router Solicitation.  t2 is used to prevent
>unnecessary handoff in the "ping pong" like movement within the overlap
>of two router domain. After handoff new router becomes current default
>router or MN, MN will then measure its signal strength from this router.

=> What you say above is very interesting and we've been looking into
similar algorithms that reuse L2 knowledge. One general comment though,
Sending a Neighbour solicitation (or even worse router solicitation) only
due to signal measurements makes the assummption that whenever you change
Base station, you also change subnets. That coupling is not required by
MIP and hence may also be inefficient in terms of radio resource usage.

Also are you making the assumption that you can talk to two routers
in two subnets at the same time ?
Do you have a specific Layer 2 in mind ?

Hesham

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Aug 2000 09:14:52 -0700

Hello,

> forwarding from a previous care-of address.

It is useful to distinguish between lossless handover and low-delay
handover.  For instance, one can achieve zero loss, but not zero delay,
by merely buffering packets for future delivery to the new access router.
Achieving low delay probabilistically automatically _reduces_ loss, since
it reduces the time during which losses can occur, but sometimes one
might get a burst during the exact time when the mobile was disconnected.
Thus, low delay does not _necessarily_ mean low loss.  I'm willing to
concede that _zero_ delay "probably" means zero loss.

Since we are lately in the business of defining terminology, why
don't we define seamless to be low-loss _and_ low-delay?

> (ie. avoid these RA beacons).

L2 help makes for better handovers -- assuming that layer 3 has a
way to make use of the information.  However, I am sure that we can
make "realistic" handovers even with minimal L2 assistance.  What
seems "realistic" depends on the application, as always.  A seamless
handover for telnet or http may not appear seamless for voice.
A seamless handover for voice may not appear seamless for video.

> >router or MN, MN will then measure its signal strength from this router.

In the usual case, this can be done more simply by just letting the
mobile node switch to the newest beacon, if beacons overlap and if
they come fast enough.  As you point out, some provision has to be
made to avoid ping-pong behavior, but it does not have to be parameterized
by a time constant.  There are other simpler and more reliable solutions.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Aug 2000 18:44:50 +0200

In your previous mail you wrote:

=> I agree!

=> I agree about a NS is better than a RS.

   due to signal measurements makes the assummption that whenever you change
   Base station, you also change subnets.

=> we need to know the layer 2 property before in order to say if
this assumption was made. In a IEEE 802.11 network in an ad-hoc mode
("an" because a well-known vendor has its own ad-hoc mode :-) you
can do real good things with signal strength (no base station => no
assumption). Same if base stations and routers are always in the same box.

   That coupling is not required by
   MIP and hence may also be inefficient in terms of radio resource usage.

=> obviously there is something like overlapping cells here.

=> ah! This should be the next point after "Link Layer Assisted ...".
I am afraid it is a bit hard to rely efficiently on a generic layer 2.
Unfortunately not a scoop!

Thanks

[email-masked]

PS: is there a specialized mailing list for this topic?

---

From: Mika Ylianttila <[email-masked]>
Date: Thu, 17 Aug 2000 20:44:12 +0300

>(ie. avoid these RA beacons).

  I agree. To get this discussion further, let me ask two concrete
questions:

- Which L2s are we talking about?
- Which parameters are we talking about?

As we know there are several L2s we can think about (GSM, IS-95, UMTS, IEEE
802.11 WLAN, Bluetooth, cdma2000, etc.). I would suggest thinking about
common parameters in these and how they be could used in L3 with Mobile IP.
I have some parameters in my mind.  RSS is of course the most popular L2
parameter. Then there are BER, SNR, CIR, etc. In addition to these, there
can be thinked of some other parameters, such as location and velocity.

When thinking about the handoff mechanism, I would like to illustrate it as
a "black box", which has a number of inputs and a number of outputs.
Selected L2 parameters with potentially some additional parameters such as
location and velocity are the inputs, and the output would be handoff
signal, and potentially some other, such as "alert" signal for MH to
prepare for handoff.

For example, in an inter-technology mobility scenario between a cellular
and WLAN, MH can have two pcmcia cards in a laptop. While working at
cellular, WLAN card can be powered down. Network could inform e.g. based on
location info, that MH is approaching on overlay-WLAN, and thus "alert"
signal would mean: "power up your wlan card, you need to use it as soon as
you hear the WLAN beacon". I think this is a very realistic scenario where
location information could be used as an input for the handoff mechanism.

The actual handoff mechanism or algorith could be left (if mobile
controlled handoff is used) to be implemented by the manufacturers. I would
imagine that the IETF handoff drafts could define a framework for the
mechanism that ALLOWS measuring those L2-parameters-to-be-selected.

Looking forward to hear some concrete suggestions what "some L2 help" would
mean in practice. I think the challenge is to make the handoff mechanism
simultaneously generic enough and yet "optimized" even in a rough sense. ;)

--
Mika Ylianttila
M.Sc., Research Scientist
Centre for Wireless Communications
PL 4500, Tutkijantie 2 E, FIN-90014
University of Oulu, Finland

---

From: Linfeng Yang <[email-masked]>
Date: Thu, 17 Aug 2000 21:31:25 +0300

Hi,

> don't we define seamless to be low-loss _and_ low-delay?

I agree. If we cannot eliminate the use of seamless, smooth, and fast, we
should at least define them in terms of low-delay, low-loss, zero-delay,
and zero-loss before using them.

Regards,

Linfeng Yang
                Helsinki University of Technology
                Telecommunications Software and Multimedia Laboratory
                P.O.Box 9700, 02015 HUT, Finland
                Phone: +358 9 451 5250           Fax: +358 9 451 5351

---

From: Phil Neumiller <[email-masked]>
Date: Thu, 17 Aug 2000 14:20:20 -0500

Are we being too specific here?  Wouldn't a generic hinting mechanism
work better?  In ye olde layered models of days gone by, there was
something called a SAP and an SPP.  The SAP is a service access
port, and the SPP is a service provision point.  Something like
the following could be done.

Verticle Hinting Framework
==========================

     ------------------------
    | Any transport          |
     -------------------------
    | SAP |                  |
     ------------------------
    | IP routing / Mobile-IP |
     ------------------------
    | SPP  |                 |
    -------------------------
    | Any Link Layer         |
     ------------------------

No a generic packet for hinting up and down can be added and of
course easily extened.  This can cary bad/good news about the
link lauyer, and even propogate it up to the transport.

Thanks,

Phil Neumiller