Handover delays measurements on the testbed in UFA and Implemented ISC

mented ISC for low-delay links

Handover delay components for Implemented ISC and UFA are defined in table 6.1. This section provides the measurements of these components on the testbed [81].

6.5.1.1 Tools and method to measure the handover delays

Before providing the component measurements, the tools and method used to measure them on the testbed are detailed in this section.

Tools used are:

• An airmagnet sniffer2_{[100] that measures the layer 2 attachment delay to the Target Gateway}

(D1).

• A Wireshark [101] that analyzes the messages exchanged on a given interface machine, is used on the MN, CN and UFA Gateways interfaces.

2

6.5. UFA PERFORMANCES 113

• SIP logs that are generated by dedicated programs on the MN, CN and UFA Gateways. • Pings are sent each 5ms from the MN to the CN.

The handover delay components defined in table 6.1 for Implemented ISC, are measured using the following method. Once the MN is handed from the Source Gateway to the Target Gateway:

1. D1 is read on the sniffer.

2. The application handover delay (Appli_HO_Delay) is deduced on the MN wireshark, based on RTCP (Real Time Control Protocol) packets that provide the number of application packets lost during handover. Appli_HO_Delay is also measured on the MN wireshark based on the time difference between the last application packet received before handover and the first application packet received after handover.

3. D1+D2+D3is measured on the MN wireshark, based on the delay between the last ping "echo

request" sent by the MN with the old IP address and the first "echo request" sent by the MN

with the new IP address. Then, D2 +D3 is deduced, as D1 is known from the last step. D2

is calculated on the MN wireshark based on D1and on the number of Router Advertisements

received by the MN before performing DAD (sending neighbor solicitation message). D3 is

finally deduced.

4. D4 is read on the MN SIP logs. It is the the delay between detecting the event of acquiring a

new IP address and the event of building the SIP Re-INVITE message.

5. D5 is deduced on the MN wireshark. It is the delay between sending SIP Re-INVITE and

receiving data from the CN.

The handover handover delay components defined in table 6.1 for UFA, are measured using the following method. Once the MN is handed from Source UFA Gateway to the Target UFA Gateway:

1. D1 is read on the sniffer.

2. The application handover delay (Appli_HO_Delay) is deduced on the MN wireshark using the same method as Implemented ISC.

3. (D1+D3) is measured on the MN wireshark, based on the delay between the last ping "echo

request" sent by the MN with the old IP address and the first ping "echo request" sent by the

MN with the new IP address. D3 is deduced, as D1 is known.

4. D4is read on the MN SIP logs. It is the delay between detecting the event of acquiring a new

IP address and the event of building the SIP Re-INVITE message (8).

6.5.1.2 Handover delay measurements on the testbed

On the testbed, the application handover delay and the handover delay components are measured for a streaming voice sending data packets over RTP/UDP, each 20ms, from the CN to the MN.

For Implemented ISC, handover delays measured on the testbed are as follows:

114

CHAPTER 6. IMPLEMENTATION AND PERFORMANCE OF UFA MOBILITY PROCEDURE FOR SIP NATIVE SERVICES

• The application handover delay Appli_HO_Delay is 1220ms based on the number of lost packets (61*20ms). Figure 6.6 shows that Appli_HO_Delay is 1238ms (packets 350 -> 381). The difference between the two results (1220ms and 1238ms) may be due to the fact that the 1220ms calculation only takes into account the number of lost packets, and does not consider the interval of time until the MN receives new data packets (data packets are sent each 20ms).

• D1 is 60ms.

• D2 is 100ms. It has been observed that the MN does not consider the first received Router

Advertisement, which explains the obtained 100ms instead of 50ms maximum (RA periodicity is 30-50ms).

• D3 is 1020ms.

• D4 is 13ms.

• D5 is 45ms. Although the very low-delay links, D5 is not low. It is due to the neighbor

discovery procedure performed by the target Gateway after receiving the first data packets from the CN to forward to the MN.

For UFA, handover delays measured on the testbed are as follows:

• The number of lost packets is 4 based on RTCP packets as shown in figure 6.7.

• The application handover delay Appli_HO_Delay is 80ms based on the number of lost packets (4*20ms). Figure 6.8 shows that Appli_HO_Delay is 60ms (packets 952 -> 957). The difference between the two results (80ms and 60ms) may be due to the fact that wireshark captures packets while the MN interface is not completely attached.

• D1 is 60ms as in Implemented ISC.

• D2 does not exist for UFA, as commented in table 6.1.

• D3 is 20ms, it corresponds to the delay necessary for the MN to enforce the IP configuration

received from the Source UFA Gateway. Compared to Implemented ISC, D3 is lower in UFA

as it does not include the delay due to Duplicate Address Detection. Indeed, in UFA, the uniqueness of the MN IP address has been checked proactively by the Target UFA Gateway during handover preparation procedure.

• D4 is 70ms. This delay does not impact the application handover delay (Appli_HO_Delay

value (80ms)) measured on the testbed, as buffering in the Target UFA Gateway in not im-

plemented. Indeed, D4 represents the delay in the MN at the SIP layer to detect the new IP

address and send message 8 (SIP Re-INVITE) to the Target UFA Gateway (UFA_GW_T). If this latter has buffered any data received from the CN or the Source UFA Gateway (UFA_GW_S), the reception of message 8 would trigger data sending to the the MN.

D4value is different from the one obtained in Implemented ISC, even though it is expected to

be the same. The difference can be explained by the fact that Iwevent (figure 6.4) employed in UFA to detect the completion of layer 2 configuration, is not very reactive.

• D5 is 0ms as messages 7A and 7 (SIP Re-INVITE) are received at the same time by the MN

6.5. UFA PERFORMANCES 115

Figure 6.5: Number of lost packets in Implemented ISC on the MN wireshark

116

CHAPTER 6. IMPLEMENTATION AND PERFORMANCE OF UFA MOBILITY PROCEDURE FOR SIP NATIVE SERVICES

Figure 6.7: Number of lost packets in UFA on the MN wireshark

6.5. UFA PERFORMANCES 117