Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 11 Jul 2002 13:42:36 -0500

Hello Rajeev,
Please find my inline comments.
regards,
ajoy 

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 12:44 PM
To: James Kempf
Cc: [email-masked]
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions

Hello Jim,

James Kempf wrote:

> Rajeev,
>
> We implemented draft 04 and we feel that it was basically sound except it needed some editorial tightening. Therefore, the
> rather drastic revision represented by 05 is not particularly helpful toward moving this forward. It is actually going back to
> previous drafts, say 01, where many details were not as tightly specified as draft 04.
>

You didn't exactly say what _proposed_ change is drastic. I have itemized the
changes below under issues. Please comment on them.

>
> In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka BETH) can
> be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but Ibelieve
> we had WG concensus to put this into the draft and I would like to see them back.
>

Ok. Let's discuss how to accommodate L2 triggers _without_  normative dependency on
all link types that do and don't have such things. Do you have a proposal ?
I would like to be able to define generic constructs that can serve as triggers for the
protocol to be initiated.

Ajoy: L2 trigger is an abstraction. I do not think we need to provide references to 
specific link layers.

>
> However, we have found that implementation is aided by having the specification be very precise about when L2 information is
> needed and what information is needed. The FMIPv4 draft has this information in it, as does draft 04, and it has been very
> useful in both our FMIPv4 and FMIPv6 implementations. Draft 5 does not contain sufficiently detailed information, especially
> for Postregv6 but also for Preregv6. Many cases that will be common for particular link layers like standard 802.11 or
> cellular are relegated to Section 4.1, the Error Cases. The detailed information on the relationship between L2 events and
> FMIPv6 needs to be described somewhere. If the WG does not want it in this draft, then it must be in another.

Let's seek the WG opinion on this. I think the base protocol should concern itself
with IP messages while allowing any L2 feature to be used. The base protocol itself
could define generic L2 constructs that can initiate the protocol operation.

Others ?

Ajoy-> We already had WG consensus about this. As per cancerous, it was decided that BETH 
will be included in base FMIPV6 draft. So, I do not see why are you asking such questions 
again?
>
>
>
> But it must also be possible to do this in the absence of any prehandover signaling, for those link layers that specify no
> standard prehandover L2 triggers. The current draft treats this as an error case, and it would not be clear to an
> implementor on such a link layer that this would be possible and correct.

The reason for this is that proposed v05 is an adaptation of v04, in which
a MN attempts to send an FBU prior to moving.
Also, an implementor has to read the Error cases if he/she wishes to
implement a robust protocol.

If the WG agrees that the text should be under a different section,
that's fine with me.

>
>
> > 3. Allow L2 triggers to used
> >
> > Change from v04: Define generic, L2 independent constructs
> > (to be done).
> >
> > New implications: define exact trigger formats elsewhere.
> > The handover messages should be able to operate transparently.
> > Introduce a Handover Solicit from NAR (when a trigger indicates
> > that the MN is attached to it) to PAR to request a HI ?
> >
>
> The information about when the L2 information is used and where needs to be specified somewhere. This draft is not
> sufficiently precise about that.
>

Ok. What does the rest of the WG think about what L2 specific
information should be in the draft ?

>
> > And, here are the new features
> >
> > - the MN should be able to maintain uninterrupted IP connectivity
> >    (i.e., is able to send and receive IP packets) for its existing
> >    sessions while it expeditiously establishes itself as a Mobile IP
> >    end-point.
>
> Disagree about the word "connectivity." IP is not connection oriented. The issue is fixing the transient route failure caused
> by the mobile node changing links.

I don't see how "IP connectivity" translates to "IP is a connection oriented protocol".
"Internet connectivity" does not translate to "Internet is connection oriented", does it ?
Anyway, the parenthesis should help.
What do others think ?

>
>
> > - during the Binding Update procedure, the MN uses its PCoA
> >     to send and receive IP packets
>
> Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled.
>

I didn't see the connection between the two on this bullet..

>
> > - the protocol can be initiated when the MN is on the old link
> >    (via RtSolPr/PrRtAdv) or on the new link (via FBU)
> >
>
> Addition of initiation on the new link is a plus, but it is not clear from this description that this is allowed in the
> general case. It is couched as an error case.
>

Ok. I can include text that allows specific usage.

-Rajeev

>             jak

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 12 Jul 2002 16:11:54 -0500

Basavraj,
I am not asking to specify L2 trigger in fast handoff draft.
We just have to state the appropriate L3 behaviors when 
specific link layer triggers are available. BTW, that is what 
is done in version V4 of the FMIPv6 draft. 
regards,
ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 3:21 PM
To: Ajoy Singh; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions

The Fast HO draft is not intended to specify L2 triggers.
Its primary focus is on L3 signaling to enable MIPv6 nodes
to perform fast HOs. I guess everybody acknowledges that it
is dependent on L2 triggers but in terms of what is actually
specified in the base draft w.r.t L2 triggers can be quite
abstract. The draft can simply say that a certain type of
HO or signaling is initiated as a result of some trigger from
L2. Other drafts can specify what triggers and how fast HO is
done for specific link layers. 
I do not believe that this draft is the one that should be
specifying what L2 triggers exist that are the basis for fast
HO.

> 
> Hello Vijay,
> Thanks for your email. BTW, can you please 
> explain how can we implement fast handoff without
> any link layer support? I also do not understand
> why standardization of FMIPv6 will get delayed
> because of L2 triggers. Is it not enough to 
> document various L2 triggers and the actions to be taken 
> based upon the L2 triggers? Do we need anything more than this?  
> regards,
> ajoy
> 
> 
> Ajoy,
> 
> you got me wrong. I am not against using L2 triggers. I know you
> need them to get the most optimized handovers. but we also need
> a generic FMIPv6 solution (I dont know how manys times I have
> said this now) that does not depend on L2 triggers. we need an
> RFC soon (dont you?).
> 
> Vijay
>

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 12 Jul 2002 16:46:28 -0500

Hello Basavraj,
Please find my inline reply.
regards,
ajoy

So rather than going down the path of identifying all the possible
link layer triggers and the corresponding behavior at L3, the
base FMIPv6 draft should simply document the L3 behavior.

Ajoy-> I disagree with this. We have to 
document important triggers at MN, oAR, nAR. Without such
documentation, how can we specify fast handoff scheme. Even in 
case of anticipated handover, we need L2 trigger either 
at MN or oAR. It will be highly confusing to describe
fast handoff without mentioning such triggers. BTW, I agree we 
do not have to explain how such triggers will be available at 
MN, oAR or nAR? This can be done in separate ID or may be 
left for implementers.
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 4:23 PM
To: Ajoy Singh; [email-masked]
Cc: [email-masked]; [email-masked];

Ajoy,

> specific link layer triggers are available. BTW, that is what 

I think we are agreeing on the general approach on how to deal
with triggers. All I am saying is that if link layer X provides
specific triggers to the upper layer, a separate I-D can
document how fast HO will work when these triggers (which would
be identified in that draft) are available. 
So rather than going down the path of identifying all the possible
link layer triggers and the corresponding behavior at L3, the
base FMIPv6 draft should simply document the L3 behavior.

> is done in version V4 of the FMIPv6 draft. 

And my belief is that the current L2 triggers specification in the
version 4 of the draft is of really no help and needs to be moved
to a more appropriate draft that deals with these triggers,.

> ajoy 

Cheers,
-Basavaraj

---

From: Phillip Neumiller <[email-masked]>
Date: Mon, 29 Jul 2002 14:33:36 -0400

I guess OBAST was ahead of its time?

> From: Joseph Soma Reddy [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 12:59 AM
> To: [email-masked]
> Hello all,
> I would like to point out that mobility protocol should not
> only ensure routing to mobile hosts, it should be able to
> support macrodiversity(i.e. soft handoff) which is very
> important in cdma systems. Macrodiversity is already being
> incorporated in systems like HDR(High Data Rate system from
> Qualcomm) where the mobile can move between different
> cell sectors before receiving each packet. With a good
> mobility scheme, it is possible to extend this and enable
> the mobile to handoff quickly between BS, which can result
> in coverage and capacity increase.
> 
> I have addressed this issue in a recent draft
> ("macrodiversity in IP based cellular networks"
> available at http://cwc.ucsd.edu/~soma ).
> The main conclusions were that the mobile should be able to
> handoff as soon as channel conditions changes(i.e. post-reg
> handoff) and that it should be possible to handoff without
> requiring any over-the-air signalling.
> I am concerned that the v5 draft provides for these
> mechanisms only as error conditions.
> 
> Another concern I have with respect to anticipated handoffs
> is that it seems to place requirements on the physical/link
> layers with respect to how channel conditions change(i.e. it
> assumes that they change gradually enough to be anticipated).
> This is not necessarily true even in current systems. For
> example, the so called "street corner effect" occurs in dense
> urban areas where the base stations are mounted on poletops.
> The coverage of these BS extends linearly(along a block) rather
> than omnidirectionally. A mobile user who turns a street corner
> in such an environment will lose line-of-sight with current BS
> and enter line-of-sight of another BS. This causes a sudden handoff
> which can only be handled by post-reg type of mobility.
> These type of situations are common in micro-cellular
> networks which will become more common in future
> as increased demand for capacity is met by reducing cell
> size.
> 
> Comments are appreciated.
> 
> Regards,
> Joseph
> 
> 
> 
> 
> 
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 31 Jul 2002 08:54:24 -0500

Alper,

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Monday, July 29, 2002 3:25 PM
To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'
Cc: 'James Kempf'; Rajeev Koodli; [email-masked]
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions

Ajoy,

> This depends upon the radio condition and 
> RF planning. 

Sure. But I thought you could still answer this 
based on your experiments.

AJOY-> In our setup, we had approx 220ms window
to exchange all L2 and L3 messages. We found 
we were not able to complete the exchange 
of L2 and L2 exchange in the same  time frame.

> But anyway in case of cellular
> link only a few over the air messages are sent.
> Typically, it is difficult to overlap 
> L3 signaling with L2 signaling in same
> time frame. 

These L3 signaling is just IP packets.
Basically this says once L2 signaling starts
going on, IP packets are not guaranteed to
be delivered. 

AJOY-> Absoultely.  

This would create additional
latency on top of actual L2 blackout time between
link down and link up.. Right?

AJOY-> Correct  

alper

> From: Alper E. YEGIN [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 8:22 PM
> To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'
> Cc: 'James Kempf'; Rajeev Koodli; [email-masked]
> You missed my questions below.. Any data points on these areas?
> I'm asking these specific to your cellular links...
> 
> > Also, how much heads up can the mobile terminal or the network
> > get before the link is broken without any anticipation? 
> > I presume link down doesn't happen instantly, at least L2 has to 
> > exchange some messages. Is there a window
> > in which L3 can exchange packets?
> 
> alper
> 
> 
>

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 31 Jul 2002 15:19:23 -0500

Hello Alper,
Ajoy 

But now that you asked....
This is becoming more and more like a L2 handover mechanism,
now that the IP stack of MN doesn't even know it changed its
default router... Probably one can make this work, but making
serial link assumptions is also limiting...

AJOY-> I do not agree that this is becoming more or more 
like L2 handoff mechanism. MN always have option to 
perform Mobile/IP registration if required. The 
proposed solution only enables fast handoff 
to work more efficiently. 

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 2:11 PM
To: Singh Ajoy-ASINGH1; James Kempf; Rajeev Koodli
Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli';

Hi Ajoy,

> Alper,
> In my previous reply to Rajeev, I explained why
> MN is not required to know the L2 address of nAR
> in case of srial link. Why this question again?

The reason I cut-and-pasted the same question from an
earlier message was to make sure that we were answering the
same question with James....

> If you do
> not agree, please comment on my previous
> email.

But now that you asked....
This is becoming more and more like a L2 handover mechanism,
now that the IP stack of MN doesn't even know it changed its
default router... Probably one can make this work, but making
serial link assumptions is also limiting...

alper

> Ajoy
> Sent: Tuesday, July 30, 2002 6:12 PM
> To: James Kempf; Rajeev Koodli
> Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli';
> I think we need to include the complete question here:
>
>   1. How does the MN get the L2 address and IP address of the
>        new AR ? I see the following possibilities
>   a) PrRtAdv provides this
>   b) upon establishing a new link, the MN does RS and gets an RA
>
>   How can you avoid PrRtAdv ? Can we assume that L2 trigger
>   provides the necessary information ? Which L2 trigger today
>   provides such information?
>
> Does MN really get "L2 and IP address of the new AR"?
> I see MN is aware of the L2 id of the Base Stations, but note
> that this is not same as L2 id of AR(s) behind them.
>
> alper
>
>
>
> ----- Original Message -----
> From: "James Kempf" <[email-masked]>
> To: "Alper E. YEGIN" <[email-masked]>; "Rajeev Koodli"
> <[email-masked]>
> Cc: "Singh Ajoy-ASINGH1" <[email-masked]>; "'Vijay Devarapalli'"
> <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 30, 2002 1:58 PM
> > > > Which L2 trigger today
> > > > provides such information?
> > >
> > > I'm not aware of any...
> > >
> >
> > I refer you to "Draft Standard for W-CDMA (Wideband Code Division
Multiple
> > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS
> > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation",
> Section
> > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter",
and
> > Section 12.25.3.8, "Handoff Indication". This version is a little old
but
> > probably not very far off from the current W-CDMA specification.
> >
> > In Section 11.7, the procedures for mobile controlled and network
> controlled
> > handover are described. In the mobile controlled case, the mobile sends
a
> layer
> > 2 identifier to the current base station indicating the target base
> station to
> > which the mobile wants to hand over, and gets back a response indicating
> whether
> > handover is allowed or denied. In the network controlled case, the
current
> base
> > station sends the same information to the mobile. (Note: "layer 3" in
this
> > specification actually refers to what from the IP viewpoint would be the
> MAC
> > layer, or layer 2). The network controlled case is used to manage power
> and cell
> > load, the mobile controlled case is used when the power level on the
> mobile goes
> > below the specified handoff point.
> >
> > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the
IP
> layer,
> > what W-CDMA already does at the MAC layer. Also in either case, the
layer
> 2
> > information should be sufficient to allow the base station to perform a
> layer 3
> > handover without any over the air layer 3 signaling, provided the base
> station
> > has a way to map the target base station id to an IP address, using
GAARD
> or a
> > preconfigured table.
> >
> > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under
> the NBAP
> > and RNSAP RAN protocols.
> >
> > I don't have access to an IS-2000 specification at the moment, but I'm
> working
> > on getting the same information. Other wireless link layers must provide
> this
> > information in some form, either before handover, as with the cellular
> > protocols, or afterwards, as with 802.11. Barring make before break,
> without
> > some information at layer 2 about where the mobile is going, it is
simply
> > impossible for the link to get switched, and, without a link, it is not
> possible
> > to do IP. If the layer 2 protocol supports real make before break (not
> soft
> > handover), none of the fast handover protocols are necessary, since the
> mobile
> > can do RS/RA on the forward link while receiving its traffic on the
> backward
> > one.
> >
> >             jak
> >
> > (fyi, Alper, the specification in question is in the DoCoMo library, if
> you care
> > to check it out.)
> >
> >
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 Jul 2002 19:10:52 -0700

> > provides such information?

 I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple
Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS
Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", Section
12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and
Section 12.25.3.8, "Handoff Indication". This version is a little old but
probably not very far off from the current W-CDMA specification.

In Section 11.7, the procedures for mobile controlled and network controlled
handover are described. In the mobile controlled case, the mobile sends a layer
2 identifier to the current base station indicating the target base station to
which the mobile wants to hand over, and gets back a response indicating whether
handover is allowed or denied. In the network controlled case, the current base
station sends the same information to the mobile. (Note: "layer 3" in the
specification text actually refers to what from the IP viewpoint would be the
MAC
layer, or layer 2). The network controlled case is used to manage power and cell
load, the mobile controlled case is used when the power level on the mobile goes
below the specified handoff point.

In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP layer,
what W-CDMA already does at the MAC layer. Also in either case, the layer 2
information should be sufficient to allow the base station to perform a layer 3
handover without any over the air layer 3 signaling, provided the base station
has a way to map the target base station id to an IP address, using Seamoby
CARD protocol or a preconfigured table.

Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under the NBAP
and RNSAP RAN protocols, so this protocol is not seen by the GPRS IP layer.

This is, of course, just one example. Can you explain how a wireless protocol
would
switch the link without providing either the old access point with a link layer
identifier
of the new or vice versa? Can you supply an example of such a protocol?

An exception is make before break. If the layer 2 protocol supports real make
before
break (not soft handover) like flash OFDM does, none of the fast handover
protocols are
necessary, since the mobile can do RS/RA on the forward link while receiving its
traffic
on the backward one.

             jak