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

From: James Kempf <[email-masked]>
Date: Mon, 14 May 2001 14:40:18 -0700 (PDT)

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: Erik Nordmark <[email-masked]>
Date: Tue, 15 May 2001 10:53:01 +0200 (CEST)

Jim,

> of L2 handover time and HI/HACK processing time as an estimate

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.

  Erik

---

From: Xiaofeng Xu <[email-masked]>
Date: Tue, 15 May 2001 11:30:04 -0500

Hi Jak,

See comments below.

Xiaofeng

>         from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000.

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.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 May 2001 11:32:59 -0700 (PDT)

James Kempf writes:

[nice analysis deleted]

 > or equal to about 1/4 of the ITU guideline. 

   This sort of gets back to my point earlier that it may
   worth combining the functionality of the RtSolPr with the
   BU itself. 
 
 > occur. Using a higher bandwidth channel could help also.

   I'm not entirely sure I believe this... in general
   if the BU doesn't happen on the old AR, you're
   already in trouble. How much more trouble the 
   lack of compression causes doesn't seem like it's
   all *that* significant[*]. If you had to put energy
   into something here, making this situation less
   likely would certainly be better.

[*] it obviously should be pointed out that the significance
    is mainly an attribute of your 9600 baud connection.
    In an all-IP universe, that would probably not be a
    good assumption. Whether it's significant given
    the messy details of our current mixed IP/TDM
    universe isn't as clear... the current
    techology is clearly not all that IP friendly,
    so I'm not sure how much weight I'd place on
    the here and now if IP carriage is more valued
    going forward.

		Mike