Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff

From: "Dolan, Michael F (Mike)" <[email-masked]>
Date: Tue, 15 May 2001 09:48:26 -0500

Another important factor that must be considered is whether the individual
handoff schemes will be able to support handoff cancellation and handoff
failure.

Handoff cancellation is the decision at L2 to cancel a handoff that has been
initiated.

Handoff failure is the attempt at L2 to move the MN to a new L2 access
point, but failure by the MN to reach the new L2 access point.  The MN then
returns to the old L2 access point for continued connectivity.

Both handoff cancellation and handoff failure must be accomodated, since
they are already supported in existing radio access network protocols.

Have a good day,
Mike
[email-masked]

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, May 14, 2001 4:40 PM
To: [email-masked]
Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff

As an interesting exercise, I went through some calculations about how
long an IPv6 low latency handoff would take in some of the scenerios
described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the
following cases:

	- Network determined, stateless with the following two subcases:
		- F-BU/F-BACK received before handoff 
		- F-BU/F-BACK received after handoff  
		
	- Network deterimed, stateful 
	
	- Mobile determined, with the following two subcases:
		- F-BU/F-BACK received before handoff
		- F-BU/F-BACK received after handoff
		
I also made the following assumptions:

	- Prior to handoff, the header compressor on the old AR is
	"hot" enough to compress the basic 40 byte IPv6 header down
	to 1 byte, but after handoff, the header compressor is "cold"
	and so the full IPv6 header needs to be sent. Currently, there
	is some debate about whether the compressor could be partially
	restarted on the new AR using context transfer, so this could
	introduce an additional optimization and also a potential 
	area of timing uncertainty involving the context transfer
	time itself.
	
	- The BU/BACK pair completes on either side of the handoff.
	In actuality, it may span the handoff and Section 3.3 may
	come into play if the MN doesn't get a BACK back (so to
	speak) fast enough. Or, an additional BU may need to be sent.
	I view the assumptions made here as being fairly optimistic,
	since over the air signalling after L2 has indicated that
	handover is pending is likely to be subject to a considerably
	higher error rate due to deteriorating radio conditions in
	the old cell and not-yet improved radio conditions in the new.
	
	- The radio link layer is using its lowest bit rate for signalling.
	This assumption is based on either using a multiplexed common
	channel for signalling, in which case the MN would have to share
	the channel with other MNs in the cell, or using a dedicated
	channel but not wanting to charge the user much or nothing at
	all, and therefore not wanting to use a higher bandwidth. Of
	course, this will be radio-specific, but it seems like a good
	assumption for cellular systems. The value I used was 7.5 kbps
	(940 bytes/sec), which is the minimum for a wCDMA dedicated channel
	from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000.
	
	- The wired link ARs use Ethernet (48 bit MAC address link
	layer) and the wireless link is using 15 byte IMSIs (International 
	Mobile Station Identifiers) sent as ASCII digits.
	
	- The MN can neither send or receive traffic on the new AR until
	the old AR has confirmed the new CoA via a F-BACK. 
	
Here's the results.

Network Determined, Stateless
-----------------------------

As near as I can tell, the following messages get exchanged over the
air: PrRtAdv, F-BU, F-BACK.

Sizes of these are:

            hdr   msg   lnkAddrOpt   prxLnkAddrOpt   newCoA	Total
	
PrRtAdv      1     8        9             9            24         51

F-BU 
before       1    10						  11

F-BU
after        40   10						  50

F-BACK
before       1	   9						  10

F-BACK
after        40    9					          49

Total over the air sizes:

F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes
F-BU/F-BACK after:  51 + 50 + 49 = 150 bytes

Times:

F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec.
F-BU/F-BACK after:  150 bytes/ 940 bytes/sec = 0.160 sec = 160 msec.

However, total handoff time will consist of the above plus a
nondeterministic amount of time involved in L2 handoff and the
amount of processing time required on new AR to perform DAD and 
process the HI/HACK pair. Perhaps one could use the maximum
of L2 handover time and HI/HACK processing time as an estimate
to add to the above.

Network Determined, Stateful
----------------------------

Messages exchanged over the air- PrRtAdv prior to handoff.

Byte counts the same as the above. No F-BU/F-BACK needed, so the
only over the air message required is the PrRtAdv.

Total over the air size:

PrRtAdv size: 51 bytes

Time:

51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec.

L2 handover time needs to be added.

Mobile Determined
-----------------

Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK.

Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr
sent by MN is done prior to L2 handoff.

           hdr    RtSolPr     MNlnkAddrOpt     newAttPtLnkOpt      Total
      
RtSolPr     1       8              18                9               36

Total over the air sizes:

F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes
F-BU/F-BACK after:  36 + 51 + 50 + 49 = 186 bytes

Times:

F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms
F-BU/F-BACK after:  198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms

Again, the maximum of L2 handoff time and HI/HACK processing time
would need to be included.

Conclusions
-----------

What conclusions to draw? These time range from respectible (55 ms
for network determined, stateful) to the clearly questionable (198 ms for 
mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms
maximum for delay before the user notices with real time voice traffic. 
Depending on the amount of time required for the L2 handover, the HI/HACK 
processing time, and any time required to send buffered traffic to
the MN if buffering is used on the old AR, the mobile determined,
F-BU/F-BACK
sent after case could easily exceed the ITU guideline, as almost 2/3 
of the noticable delay time is taken up by the L3 handoff. The others
require less L3 handoff time, but only the network determined, stateless,
F-BU/F-BACK before and the network determined, stateful are less than
or equal to about 1/4 of the ITU guideline. 

Clearly, header compression on the new AR could help a lot. IPv6 headers
are big, and if there were some way the header compressors on MN and new AR
could be jump started prior to handoff, the 40 byte header overhead could be
eliminated. Alternatively, if the link layer can guarantee that
the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't
occur. Using a higher bandwidth channel could help also.

Please send any comments or corrections (in case my math is wrong).

		jak

---

From: James Kempf <[email-masked]>
Date: Tue, 15 May 2001 08:48:02 -0700 (PDT)

Hi Erik,

>Your times assume that there is no added latency per packet imposed
>e.g. by waiting for the right timeslot.
>Since I know nothing about the actual radio channels I don't know
>if this might be an issue.
>

CDMA doesn't use time slots. Walsh codes generating a particular spreading 
pattern are used to differentiate multiple senders/receivers, rather than
assigning particular time slots. Except for wCDMA TDD (time division duplex) 
mode, in which the sender and receiver share the same bandwith and must
duplex on it, and I don't believe that anybody is planning on deploying that in 
the near future. Normal wCDMA and cdma2000 use FDD, frequency division
duplex, in which there are separate spectrum bands used for uplink
and downlink traffic.

GSM (TDMA) does use time slots, but I think the user throughput rates
would include that. The number I used was for user throughput.

		jak

---

From: James Kempf <[email-masked]>
Date: Tue, 15 May 2001 09:40:54 -0700 (PDT)

Xiaofeng,

>xfxu: The  handoff at mobile IP layer should be treated as traffic in stead of
>signalling from L2 point of view, while the L2 handoff is performed on
>signalling channel.
>

Thanx for the comment. The throughput number here is for user data throughput so
it does, in fact, reflect throughput on a traffic channel and not
on a signalling channel. My comments on using a signalling channel
were meant to reflect a future evolution in which mobile IP is
more tightly integrated into the radio control, i.e. the all IP network.
Today, the mobile IP signalling would be done on a traffic channel,
as you indicate.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 May 2001 19:36:42 +0200

> they are already supported in existing radio access network protocols.
	=> Absolutely. Unfortunately this is not supported in the 
	current Fast Handoffs draft. It is however supported in the 
	V4 low latency draft by use of simultaneous bindings. 

	Regards,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 May 2001 22:50:07 +0200

> >         => Why ? This is really an implementation issue that is up
> >         to the system designers and should not relate to the protocol.
> >         Having said that I do see benefits in integarating the
> >         signalling of the MIP handover into the signalling channels.
> >         I don't see why this can't be done.
> >
> >         Hesham
> 
> xfxu: you are mixing L3 signalling with L2 signalling.
> 
	=> No I'm not mixing L2 and L3 signalling. I'm
	sending L3 signalling on a different channel.

>  Logically don't do that.
	=> Logically ? why ?

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 May 2001 23:14:24 +0200

James,

	A couple of comments below.

> 	from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000.
	=> I thought the WCDMA specs says 15kbps (uplink) for a DPDCH
	(Dedicated Physical Data CHannel). Did you divide by 2 for a reason ?
> nondeterministic amount of time involved in L2 handoff
> 
	=> Not necessarily. They could happen simultaneously.

	There is also the L2 delays over the air that should be
	added. That is the big delay I believe.

>  and the
> process the HI/HACK pair. 
> 
	=> your figures are based on WCDMA. In this case there is no DAD.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Tue, 15 May 2001 14:26:05 -0700 (PDT)

Hi Hesham,

>	added. That is the big delay I believe.

I'm not sure I understand what you mean. Do you mean the amount of
time during handoff in which the mobile is listening to the pilot and
exchanging frames at L2 before it decides that the signal quality
is high enough to declare that L2 handoff is complete? At which
point it would start sending user L3 traffic again? Or do you
mean something else?

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 May 2001 23:35:42 +0200

Hi James, 

> point it would start sending user L3 traffic again? Or do you
	=> Sorry, I wasn't very clear. I meant that you calculated
	the transmission delay (no of bits / bit rate), but there 
	is also the delays in coding and sending the data over
	the air and getting an Ack (on the radio level). I suspect
	that is it comparable with the transmission delay based 
	on the worste case scenario.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Tue, 15 May 2001 14:48:48 -0700 (PDT)

Hi Hesham,

>	on the worste case scenario.

Actually, I used the user data throughput numbers from Holma and
Toskala, on pg. 90 for half rate coding at various spreading factors
and channel rates. I presume they've included coding, spreading,
and Ack delay in the user data figures.

		jak

---

From: [email-masked]
Date: Tue, 15 May 2001 17:46:55 -0500

Forwarding to list since he is not registered.

> From: Kularatna Shavantha (NET-TDMA/Dallas) 
> Sent: Tuesday, May 15, 2001 12:39 PM
> To: Patil Basavaraj (NET/Dallas)
> Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff
> 
> 
> Hi Raj
> 
> At least on the downlink the signaling channel is
> 3.4k. Hence the time for each of the messages roughly
> double. But, this not a problem as in UMTS DCH multiplexes
> speech and signaling together. Hence, the above 3.4k is
> accounted while full rate AMR max (12.2K) is there. Since
> both are simultaneous there should not be any interruption of
> speech service while the signaling is exchanged. This normally
> not the case in TDMA case where speech is interrupted by handoff
> messages.
> 
> Cheers,
> 
> Sha.
> 
> >
> >> From: ext James Kempf [mailto:[email-masked]]
> >> PrRtAdv      1     8        9             9            24  
>        51
> >> before       1    10					
> 	  11
> >> after        40   10					
> 	  50
> >> before       1	   9					
> >> 	  10
> >> after        40    9					
>           49
> >> RtSolPr     1       8              18                9        
> >>        36
> >> the MN if buffering is used on the old AR, the mobile 
> >> determined, F-BU/F-BACK

---

From: James Kempf <[email-masked]>
Date: Tue, 15 May 2001 16:03:35 -0700 (PDT)

Hi Raj,

>> not the case in TDMA case where speech is interrupted by handoff

As somebody noted this morning, currently MIP signalling is run
over a traffic channel, not a signalling channel. So this would
mean that the user data traffic would need to be interrupted to 
send across the MIP signalling. IP signalling can't currently get the
same kind of parallelism that the wCDMA/UTRAN signalling can.

If it were possible to do the MIP signalling on a signalling channel,
one could get the kind of parallelism described here, though the
a data rate of 3.4k would lengthen the handoff even more. However, 
as far as I can tell (and the draft is a bit murky on this point), the
current design of the IPv6 fast handoff doesn't seem to allow
the MN to continue send/receive traffic on its old CoA while 
at the newAR, so parallelism would not buy anything. The MN would
still have to stop sending/receiving on the old CoA and only
start on the new after the F-BU/F-BACK is complete.

		jak

---

From: [email-masked]
Date: Tue, 15 May 2001 18:44:39 -0500

> and Ack delay in the user data figures.

James, you used the numbers specified for the uplink and applied
the same for the downlink. The downlink data rates are different and
are specified on page 96 (table 6.3). So the downlink data rate would
be 1-3 Kbps (375 bytes/sec). Should'nt you take that into consideration
as well.

-Basavaraj

---

From: James Kempf <[email-masked]>
Date: Wed, 16 May 2001 08:45:18 -0700 (PDT)

Hi Raj,

>be 1-3 Kbps (375 bytes/sec). Should'nt you take that into consideration

Thanx for pointing this out to me. I should use different rates
for the uplink and the downlink.

There are a couple other points that occured to me where I think
I will need some clarification from the authors of 
draft-ietf-mobileip-fast-mipv6-01.txt. The draft is not clear on
these, or at least I couldn't figure it out from reading the
draft. They are:

- On pg. 9, Figure 2 shows stateful CoA configuration without the 
F-BU/F-BACK that is required for stateless. In  my calculations,
I assumed that the F-BU/F-BACK are not needed for stateful. However, I don't
see how the MN can tell whether a PrRtAdv is the result of
stateless or stateful address provisioning. There are no flags
or distinctive options that differentiate the two. Consequently,
I suspect that the F-BU/F-BACK would be necessary for stateful
CoA configuration as well. Can the authors confirm?

- It was unclear to me after reading the draft how F-NA and NA
are used, why the new F-NA was introduced, and whether the MN
can get packets before exchanging an acknowledged NA or F-NA to the newAR. 
Section 5.3 seems to imply that the F-NA can be sent by the MN if it
wants to start sending packets right away prior to receiving
the F-BACK, but other parts of the draft say that the F-BACK
is the gating factor. Can the authors of the draft confirm whether or not an
acknowledged F-NA or NA is required before the MN can start sending packets 
through newAR?

As soon as I get clarification from the authors on these points, I'll update the
calculations and repost them.

		jak

---

From: [email-masked]
Date: Wed, 16 May 2001 11:23:28 -0500

James,

>same kind of parallelism that the wCDMA/UTRAN signalling can.

If the traffic is real-time data, the traffic channel consists of
signaling and RT bearer simultaneously. So at the transport layer
(DCH) consists of 3.4 Kbps for signaling as well as 12.4 for AMR (max
data rate). So the MIP signaling should be carried over the 3.4 kbps
channel and as a result will not interrupt the traffic. So if you
look at section 6.2.1 (Harri's book) at paragraphs 1 & 2, you will
realize that.

>one could get the kind of parallelism described here, 

You actually can get that parallelism via the multiplexing feature of
DCH. 

>though the
>as far as I can tell (and the draft is a bit murky on this point), 

>the current design of the IPv6 fast handoff doesn't seem to allow
>at the newAR, 

The current draft does allow this. What I mean is that the MN can
continue to use it's old COA at the new AP, if it did not receive an
ACK from the handoff signaling.

>so parallelism would not buy anything. The MN would

Basavaraj/Shavantha

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 May 2001 18:19:54 -0700 (PDT)

> Section 5.2 on pg. 33 of draft-ietf-mobileip-fast-mipv6-01.txt talks about a 
> unidirectional tunnel from old AR to new AR but nothing about a reverse 
tunnel. 
> If there is no reverse tunnel in place, new AR can drop MN's packets
> with the old CoA because old CoA is not topologically correct
> in new AR's subnet, if egress filtering is on (as I would expect
> it to be, to prevent bogus MN from establishing service). Consequently,
> old AR forwards packets to new AR, who buffers them, but the real time
> stream still stalls because MN can't get any packets out. 

The solution is clearly to make the tunnel bi-directional. I remember this as 
our decision, but other authors would correct me if I'm wrong. Yes, we should 
clarify this on the draft.

> 
> Also, it is furthermore unclear whether new AR is allowed to send packets
> to MN prior to MN sending a Neighbor Advertisement or Fast Neighbor
> Advertisment to new AR. Exactly how and when NA or F-NA is used seemed
> also somewhat murky to me. It is not shown on the timing diagrams
> for the protocol, for example, though it is discussed in Section 5.3.

Figure 1. in section 3.1.1 shows F-NA in the diagram, but what it's missing is 
to show this is sent after "Connect"ing to the new link.

So, as soon as MN attaches to new link, it can send this F-NA to newAR.

> 		jak

alper

---

From: kempf <[email-masked]>
Date: Thu, 17 May 2001 18:58:12 -0700 (PDT)

Mike,

>Er, uh, why couldn't this be done with normal IP
>and L2'ism?  If the L2 provided a transport
>vehicle for IP datagrams, all of the normal ways
>of building an interface would apply, I'd
>think. In fact, I can't imagine why you'd want to
>distinguish "signaling" packets. You'd want to use
>normal QoS mechanisms (diff/intserv), I'd think,
>and let the application decide what it wants to
>prioritize, and the gateway decides how to police.
>

The problem is that unlike wired systems, there are actually
several (I think 15 in wCDMA) channels that can be used.
Each channel corresponds to a different chunk of spectrum
or a different configuration of Walsh codes. The mobile and
BTS can send and receive on multiple channels at once, so
you could conceive of doing all your handoff signalling on
one channel while the voice traffic was still flowing over the data channel.
It's kind of like having 15 interface cards on the back
of your workstation, with 15 wires going out of them. 
On top of that, as Raj mentioned in his email, the logical DCH
channel on the downlink actually consists of a physical realtime
data channel that is currently used exclusively for voice frames
and a signalling channel that is used for 3.5Kbps signalling.
So applications just write to the logical channel and 
presumably the MAC layer on the phone sorts out which physical channel
to use.

I agree that it could get complicated trying to figure
out how to send IP signalling over a special signalling channels
rather than just sending it as standard IP datagram traffic,
and while I think it could, in principle, be done, it is
probably impractical. I'm curious what 3GPP will do when they
start using SIP phones, since they will need to deal with this
issue. IMHO, this may be an example of a case where
radio protocols better engineered for IP might make sense,
as you've mentioned in the past, though most mobile operators
don't seem too interested in that right now.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 19 May 2001 01:13:02 +0200

Hi James, 

> unidirectional tunnel from old AR to new AR but nothing about a reverse tunnel. 
> it to be, to prevent bogus MN from establishing service). . 
> 
	=> In the case you're referring to the tunnel is terminated 
	in the new AR. A host route exists in the new AR. So it seems
	quite reasonable that egress filtering will not be done on 
	a host that is already allowed to exist on the subnet (by 
	virtue of the host route). Maybe some text is needed in the
	draft for this.

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 19 May 2001 01:37:49 +0200

Alper, 

> clarify this on the draft.
	=> I'm not sure if I'm missing something here but how does 
	a bi-directional tunnel help ? The src address for outgoing 
	packets will still be the old CoA.

	Hesham

---

From: Alper Yegin <[email-masked]>
Date: Fri, 18 May 2001 17:37:17 -0700 (PDT)

> 	packets will still be the old CoA.

Hesham,

As you pointed in your previous e-mail, as newAR keeps state about MN and knows 
it's using oldCoA, it can selectively let those packets go by. (yes, we need to 
clarify this on the draft).

Also, oldAR might be more than one hop away from newAR, in which case 
bi-directional tunnel will encapsualte packets with topologically incorrect 
source address and they won't be ingress-filtered by intermediate routers. (this 
is for packets sent by MN).

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 21 May 2001 00:29:37 +0200

Alper, 

> is for packets sent by MN).
	=> Ok I misinterprested your first mail and thought you meant
	 a tunnel starting from the MN. That sounds ok. 

	Hesham