The experimental FHO performance evaluation is based on measurements in test networks, comprising Linux implementations of all modules, such as FHO kernel module, AR enhancements, movement detection via signal strength measurements,
2.5. PERFORMANCE EVALUATION - EXPERIMENTAL RESULTS 21 AAAC and QoS components. Each Moby Dick partner maintains a test network, e.g., for the development, implementation and testing of a specific component. The frequent integration and exchange of modules allows operating each network autonomously. The different trial sites can also be interconnected via IPv6 over IPv4 tunnels in the Internet in order to test interoperability or to evaluate the system over the unpredictable long distance links of the Internet.
Figure 2.7 illustrates the test network used in this thesis and at NEC. The ma- jority of experiments are conducted in this network. A set of handover latency measurements is conducted at the Moby Dick trial site at the University Carlos III Madrid (UC3M). The UC3M network set up is similar and, therefore, it is not illus- trated separately. The respective sections indicate results of the measurements at UC3M. The combination of measurements and results of different partners shows the strong interaction and cooperation in the Moby Dick consortium.
QoS Broker AAA S erver HA CN Wireless AR Wired AR Wireless AR MN Wired Connection Wireless Connection
Figure 2.7: Mobility enabled IPv6 Testbed including AAAC and QoS. All nodes in Figure 2.7 use the Linux operating system with kernel 2.4.16 and the MIPL Mobile IPv6 stack in the kernel. The test network consists of the follow- ing components.
The HA is the mobility proxy of the MN in the home network. The CN rep- resents an arbitrary node in the Internet. For the evaluation, the CN is one of the communication end-points. AAAC server and QoS broker implement the required AAAC and QoS databases and functionalities, respectively. The core router sepa- rates different IP sub-networks, such as the home network and foreign networks. Each foreign network consists of a separate IP sub-network. The core router pro- vides the main routing functionality, e.g., it routes the data stream for the mea-
surements to the respective foreign sub-network. The network includes three ARs: Two IEEE 802.11b wireless ARs and one wired Ethernet AR. All ARs include the FHO module, AAAC- and QoS attendants. The MN is a laptop, which is equipped with an on-board Ethernet and an IEEE 802.11b wireless LAN PCMCIA card. The MN roams between the foreign networks, using its FHO module, while commu- nicating with the CN. The MN performs intra-technology handover, staying in the same technology and using the same wireless LAN interface, and inter-technology handover which uses the different interfaces wireless LAN and Ethernet.
In this test network, the evaluation measures the handover latency, UDP and TCP performance in presence of standard Mobile IPv6 and Fast Handovers. All of the following scenarios evaluate intra-domain handovers, i.e., handovers within the same administrative domain, which assume a security association between the ARs. Furthermore, the scenarios use ideal QoS and AAAC entities since (i) QoS signaling takes place prior and after the actual handover, and AAAC signaling is coupled and combined with the FHO signaling, as explained before. Thus, this assumption does not impact on the performance evaluation. The evaluation focuses on WLAN-WLAN intra-technology, as well as WLAN-Ethernet inter-technology handovers. The remainder of this section describes the evaluation scenarios in detail.
Handover Latency Measurement Scenario This scenario measures the handover
latency of standard Mobile IPv6 handovers and Fast Handovers in the test network, as described above. The handover latency is measured in two dif- ferent ways: (i) The measurement of packet loss in a data stream with pre- defined inter-packet delay allows the calculation of the handover latency. However, the granularity of this method is restricted by the inter-packet de- lay. The measurements use the ping6 tool with an inter-packet delay of 10 ms to 20 ms, which determines the measurement granularity. (ii) The handover latency is measured by time-stamps in the source code of the FHO module. This method increases the accuracy of the measurement.
The packet loss measurements are conducted in the UC3M test network and the time-stamp measurements is carried out in the NEC test network. Be- yond, the focus of the measurements differs, as follows:
(i) The packet loss measurements focus on the impact of different delays between MN and CN or MN and HA on Mobile IPv6 and FHO handovers. The different delays emulate different locations of the respective nodes, with varying number of hops between the nodes. In the test network, the measure- ments use the NISTNET [100] tool to emulate different delays. NISTNET allows a single Linux PC, set up as a router, to emulate a wide variety of net- work conditions, such as e.g., delay, jitter or packet loss. Since NISTNET
2.5. PERFORMANCE EVALUATION - EXPERIMENTAL RESULTS 23 supports IPv4 only, the measurements use an IPv6-in-IPv4 tunnel between the ARs and the CN. This tunnel does not influence the measurements since the encapsulation time is negligibly small and constant for all packets. Further measurements evaluate the impact of the Router Advertisement in- terval on the handover latency. As explained before, the FHO movement de- tection scheme utilizes Router Advertisements, similar to standard Mobile IP handovers. In contrast to standard Mobile IP handovers, FHO evaluates the signal strength of the respective Router Advertisement during the handover preparation phase. The measurements use different Router Advertisement intervals of 0.5 - 1.5 s and 2.0 - 4.0 s. The results compare the impact of these different intervals on standard Mobile IPv6 and FHO handovers. (ii) The focus of the second measurement campaign in the NEC test net- work is on preciseness. Therefore, time-stamps are added to the FHO source code on the MN. These time-stamps measure the interruption time of the IPv6 connection. The measurement starts when the the MN leaves the old AR and ends when the MN receives the first data packet via the new AR. This method represents a very accurate granularity because the precision of the operation relies strictly on the operating system time (i.e., CPU TSC- Timestamp Counter Register), and the measurement follows immediately the respective FHO primitives.
UDP Performance Measurement Scenario The UDP performance evaluation in-
cludes qualitative and quantitative aspects. The qualitative performance mea- surements evaluate the user’s satisfaction when watching a video on a mobile device, while performing frequent handovers. The user compares the per- ceived quality under standard Mobile IPv6 and Fast Handovers. However, qualitative perception of the aural and visual human abilities is different for every individual person. In contrast, the quantitative evaluation measures the packet loss in case of handovers. These quantitative measurements provide comparable and reproducible results for a meaningful evaluation. The re- mainder of this paragraph describes both, the qualitative and the quantitative UDP performance measurement scenarios.
In the qualitative UDP performance evaluation, a video trailer is shown to a group of users while the MN frequently executes handovers. The CN trans- mits the video and audio stream to the MN, using the Linux tool Video- LAN [133]. The buffering capability of the tool is disabled. The CN trans- mits a video trailer of about 2 min and 20 s length at a data rate of approxi- mately 468 kBit/s. The tool is configured to use uncompressed, full frames since the codec is beyond the scope of this evaluation. The MN executes handovers every 40 s. The users evaluate the performance, i.e., the perceived noticeable interruptions, of Mobile IPv6 and Fast handovers in a question- naire.
The quantitative evaluation uses the self-implemented traffic generator, as described in Section 2.4. The CN transmits continuously UDP data in pack- ets of 1000 bytes and an inter-packet delay of 25 ms to the MN. Again, the MN executes handovers every 40 s. Tcpdump [129] captures the traffic on the sender and the receiver side. Furthermore, Tcptrace [117], which is recommended by the IETF [118], has been adapted to process basic IPv6 functionalities. The tool analyzes quantitatively the traffic and retrieves the information for the generation of the graphs, as presented in section 2.5.3.
TCP Performance Measurement Scenario The TCP performance evaluation mea-
sures quantitatively the TCP throughput in case of handovers. This includes the evaluation of the TCP state when the TCP sender detects packet loss due to handover. Typically, TCP assumes network congestion in case of packet loss and invokes its congestion control mechanisms, such as Fast Retransmit or Slow Start. The reaction of TCP, which depends on the number of lost segments, determines the throughput.
In this scenario, the CN establishes a TCP connection to the MN, using once more the self-implemented traffic generator tool. The evaluation uses TCP NewReno, which includes the Fast Retransmit and Selective Acknowledg- ment options. In presence of the established TCP connection, the MN ex- ecutes handovers. Lost segments invoke the TCP congestion control. The evaluation traces the TCP state and measures the resulting TCP performance.