Subject: [mobile-ip] Timings for FMIPv4 and FMIPv6

From: James Kempf <[email-masked]>
Date: Thu, 24 May 2001 09:11:35 -0700 (PDT)

I revisited the MIPv6 handoff timings I calculated last week based
on comments on the list and a rereading of the spec 
(draft-ietf-mobileip-fast-mipv6-01.txt). In addition, I calculated the same 
figures for the MIPv4 low latency techniques describe in
draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt, which was posted
last week. The results are presented in a comparison table at the end
of this note.

Bandwith of Radio Connection
----------------------------

While the number of bytes in the messages exchanges is fixed and known,
one of the major sources of uncertainty in the calculations is the actual
bandwidth available over the air for IP signalling. The calculations
assume that the exchange of bytes over the air is the controlling factor
at L3 for when the MN stops getting packets at oldAR and starts getting
them again at newAR. The actual time required between when the MN stops 
getting packets at the oldAR and when the packet flow restarts at the 
newAR is important because it determines whether the user will perceive 
a pause or other distortion in a real time stream during the handover. 
Therefore, I think it is worthwhile as an indication of whether a 
particular handoff technique will have more or less of a probability of 
presenting the user with a perceptible delay. The threshold of preception 
is a 300 ms delay, according to the ITU, and this value includes both IP 
signalling and L2 signalling, so any L3 signalling delay figures must
be weighed by the fact that there will be an L2 delay during handover
as well.

In the original calculations, I used 7.5 kbps (960 bytes/sec). 
wCDMA actually uses a rate of 3 kpbs for signalling over the DCCH 
signalling channel. Currently, it is not possible to do IP signalling over 
the DCCH signalling channel in wCDMA. While this could be changed, it seems 
more likely that any mobile IP signalling in the immediate future will go over
a traffic channel. The DPCCH traffic channel has a variable bit rate on a 
per frame basis between 0 and 2.1 mpbs, and the rate can differ in the
uplink and downlink directions.  Using a traffic channel has an advantage 
in that the  data rate is higher and can be throttled up or down, but a 
disadvantage in  that any real time bearer traffic will be delayed until the 
signalling traffic is sent or received. The other disadvantage is that using 
a higher data rate is expensive.

Note that if it were possible to do IP signalling over the DCCH signalling
channel, it might be possible to achieve a higher degree of parallelism
even given the lower data rate, since DCCH signalling and DPCCH traffic
can flow simultaneously.

In order to take advantage of the multiple data rates, I calculated each 
handoff using data rates of 7.5 kbps (960 bytes/sec), 9.6 kbps 
(1200 bytes/sec), and 15 kbps (1875 bytes/sec). 

Modifications in the Calculation
--------------------------------

Correspondence on the list and a careful re-reading of the spec
established that the assumptions I made about the exchange of
messages were incorrect. The MN does not have to receive a F-BACK
before it can start sending traffic, the only constraint is that
oldAR cannot forward any traffic to the MN through newAR until
it receives a F-BU (pg. 5). This is true for all cases. In
addition, the MN cannot send or receive any packets until it
does an NA or, at the very least, an F-NA to newAR. So the
new calculations replace the F-BU received by the MN with an
F-NA sent by the MN. The MN does not have to receive a RtAdv
as a response to the F-NA before it can send packets, it can
send them using oCoA (pg. 11). 

The previous calculations also assumed that network assisted,
stateful handoff did not require a F-BU/F-BACK exchange with
oldAR. These assumptions were based on Fig. 2, pg. 9, which
shows no such exchange. But a rereading of the spec and correspondence
on the list established that Fig. 2 is incomplete, and it must
essentially be grafted onto Fig. 1 for completeness. Since
the message exchanges in both Fig. 1 and Fig. 2 are the same,
with the exception that the PrRtAdv in Fig. 2 is delayed until
the HI/HACK is exchanged, I've left off the network assisted,
stateful case in this calculation. The HI/HACK exchange will
likely add a delay in the millisecond to submillisecond range,
depending on the amount of time it takes newAR to allocate
a new CoA, which is insignificant compared to the air interface 
delay.

The message exchanges are designed for the fastest possible case in which 
the MN can start exchanging real time packets after a handoff . In
some cases, this means that the oldAR or MN are not using the new
CoA, but rather, that a bidirectional edge tunnel is available between
oldAR and newAR (or oldFA and newFA) to forward packets through newAR to MN. 
Eventually, MN will confirm its new CoA through newAR and can begin to
use it as well, but until that happens, it can still continue a real
time stream.

Finally, the original calculation neglected the 8 byte UDP header
for the post-handoff messages. The pre-handoff messages have both the IP and UDP
headers removed by header compression.

Other Assumptions
-----------------

The other assumptions remain the same for both the MIPv6 and MIPv4
case. These are stated here:

	- Prior to handoff, the header compressor on the old AR is
	"hot" enough to compress the basic 48 byte IPv6 + UPD header 
        and 28 byte IPv4 + UPD header down to 1 byte, but after handoff, 
        the header compressor is "cold" and so the full IP + UDP 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 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.
	
Calculated Message Exchanges
----------------------------

The following table gives the message exchanges that were
calculated and the final configuration when real time traffic starts
again after handoff, indicating which CoA is used by the MN and newAR. 
The parenthesized (old) and (new) after the message name indicated whether 
the message is sent through the oldAR or newAR (or oldFA or newFA).

  Sequence Name           Message Sequence   Size     Final Configuration
  -------------           ----------------   -----    -------------------

FMIPv6 Network Full BU     PrRtAdv(old)       51           oCoA
(FMIPv6-NFB)               F-BU (old)         11          ------->
                           F-BACK (old)       10      MN  <------   newAR
                           F-NA (new)         106           nCoA
                           ----------------------
                           Total              178

FMIPv6 Network New BU      PrRtAdv(old)       51            oCoA
(FMIPv6-NNB)               F-BU(new)          58           ------->
                           F-NA(new)         106      MN   <-------  newAR
                           ----------------------            oCoA
                           Total             215  

FMIPv6 Network Old BU      PrRtAdv(old)       51            oCoA
(FMIPv6-NOB)               F-BU(old)          11           ------->
                           F-NA(new)         106      MN   <-------  newAR
                           ---------------------	     oCoA
                           Total             168

FMIPv6 Mobile Full BU     RtSolPrxy(old)      36        same as FMIPv6-NFB
(FMIPv6-MFB)              PrRtAdv(old)        51
                          F-BU(old)           11
                          F-BACK(old)         10
                          F-NA(new)          106
                          ----------------------
                          Total              214

FMIPv6 Mobile New BU      RtSolPrxy(old)      36        same as FMIPv6-NNB
(FMIPv6-MNB)              PrRtAdv(old)        51
                          F-BU(new)           58
                          F-NA(new)          106
                          ----------------------
                          Total              251

FMIPv6 Mobile Old BU      RtSolPrxy(old)      36        same as FMIPv6-NOB
(FMIPv6-MOB)              PrRtAdv(old)        51
                          F-BU(old)           11
                          F-NA(new)          106
                          ----------------------
                          Total              204

FMIPv4 PRE Old Network    PrRtAdv(old)        33              nCoA
(FMIPv4-PON)              HA Reg(old)         29            -------->
                          ----------------------        MN  <-------- newFA
                          Total               62              nCoA

FMIPv4 PRE Old Mobile     RtSol                               nCoA
(FMIPv4-POM)                w. Link Ind(old)  27            --------->
                          PrRtAdv(old)        33        MN  <--------  newFA
                          HA reg(old)         29               nCoA
                          ----------------------
                          Total               89

FMIPv4 PRE New Network    PrRtAdv(old)        33        same as FMIPv4-PON
(FMIPv4-PNN)              HA Reg(new)         37            
                          ----------------------           
                          Total               70              

FMIPv4 PRE New Mobile     RtSol                         same as FMIPv4-POM
(FMIPv4-PNM)                w. Link Ind(old)  27            
                          PrRtAdv(old)        33            
                          HA reg(new)         37               
                          ----------------------
                          Total               97

POST                        <none>                            oCoA
                                                            --------->
                                                        MN  <--------- newFA
                                                               oCoA

L3 Handoff Latency
------------------

The following table gives handoff latencies for the message exchanges
in the previous table. The exchanges are indicated by their 
abbreviations, i.e. FMIPv6-NFB stands for Fast MIPv6 Network Full Binding
update. The rows are sorted by time, from the lowest latency to the
highest latency.

   Message Xchange     940 bytes/sec       1200 bytes/sec     1875 bytes/sec
                       (7.5 kbps)          (9.6 kbps)         (15 kbps)
   ---------------     -------------       --------------     --------------

     POST                  0                   0                  0

     FMIPv4-PON           65                  51                 33 

     FMIPv4-PNN           74                  58                 37 

     FMIPv4-POM           94                  74                 47

     FMIPv4-PNM          103                  81                 51

     FMIPv6-NOB          178                 140                 89 

     FMIPv6-NFB          189                 148                 94   

     FMIPv6-MOB          217                 170                108 

     FMIPv6-MFB          227                 178                114 

     FMIPv6-NNB          228                 179                114   

     FMIPv6-MNB          267                 209                134 

Comments
--------

I'd like to keep comments in a separate thread, so I'll post another
message with interpretations and suggestions.

Acknowledgements
----------------

Thanx to Raj Patil of Nokia for researching wCDMA data rates, and Alper
Yegin of Sun for guiding me through the mysteries of 
draft-ietf-mobileip-fast-mipv6-01.txt.