Simulation Environment and Scenarios

The following section provides an overview of the network simulator version 2 (ns-2) used to implement and evaluate the performance of the proposed scheme. The simulation scenarios used to model the proposed scheme, as well as the simulation configuration parameters and the simulation environment, are also given.

3.5.1 Network Simulator Version 2 Overview

Network simulator version 2 [66], commonly known as ns-2, is a discrete event driven network simulator popularly used to simulate wired and wireless networks. It is an open source network simulator written in C++ and OTCL programming languages. Object-oriented C++ provides fast execution; and it used to implement the protocol to be simulated. OTCL (Object Tool Command Language) provides simple and flexible scripts, which allow easy and quick modifications of simulation scenarios, such as simulation setup and the configuration of different models. These two languages are linked together through an interface called TclCl.

The simulator supports different network components, traffic, routing algorithms, and protocols (i.e., TCP and UDP). This provides a platform for network researchers to develop and simulate different network models. The researchers can modify or extend existing ns-2 models in C++ to suit their simulation requirements.

Simulation scenarios are implemented using OTCL scripts, which involve the creation and configuration of nodes, link creation, network setup and run of the scripts. The simulation results are collected in a trace file that includes all the events that have occurred. Text-processing tools, such as AWK can then be used to extract the desired data from the trace file for the analysis.

The simulation of the proposed scheme has been carried out using ns-2 (release 2.29) with NIST mobility package [67]. Ns-2.29 with NIST mobility package provides additional modules that can implement PMIPv6.

3.5.2 Simulation Scenarios

This sub-section presents the implementation and simulation scenarios used to evaluate the performance of the DM-RMG scheme. The ns-2.29 with the NIST mobility package introduced above has been extended to model and simulate DM-RMG scenarios. Two scenarios have been investigated, as explained below.

The first scenario investigates a situation when the MN is located away from its communicating IP address-anchoring network, in a visited network that is closer to the CN‟s network. Two routing paths followed by the packets when travelling from the CN to the MN were investigated. These paths are named the sub-optimal path and the optimal path. The sub-

optimal path represents the routing mechanism used in static anchoring DMM schemes (which is

also a mechanism used in centralized IP mobility management, such as PMIPv6).

In the sub-optimal path, the packets sent to the MN while away from its communicating IP address-anchoring network always pass via this anchoring network, which then tunnels them to the network that the MN is currently visiting, as shown in Figure 3-5. The optimal path is provided by the DM-RMG routing path optimization mechanism. It is achieved by DM-RMG optimizing the route – soon after the MN has performed a handover to the visited network (as

described in Section 3.3, with the illustration in Figure 3-5). So, the packets travel directly from the CN‟s network to the MN‟s currently visited network. Both the optimal and sub-optimal

paths that the packets follow are simulated under identical traffic loads; and the packet delivery

latency performances are compared.

The second scenario investigates the handover delay and packet loss performances of the DM-RMG handover mechanisms. The proposed handover mechanisms have been simulated. (This is discussed in sub-section 3.3.2 with Figure 3-7, and its extension with TMAG support given in Figure 3-9.) In both mechanisms, it is assumed that the MN has moved to a visited network (from its communicating IP address-anchoring network), and that it is performing a subsequent handover (from its initially visited network to a neighbouring visited network), as shown in Figure 3-6. The simulation extends the implementation in Figure 3-10 by adding another visited network and TMAG, as illustrated in Figure 3-6 and Figure 3-8 , respectively.

LM1 GW1/ RM1 MAG11 MAG12 GW2/ RM2 MAG21 GW3/ RM3 MAG32 CN MN R2 R1 R0 P11.. ..P14 Sink_n51 P21.. ..p24 p31.. ..p33 Sink_p11 Sink_p21 P61.. ..P64 p51.. ..p53 ..p 44 Sink_p61 Sink_p31 Sink_p41 p41. . movement

Figure 3-10 Simulated network topology

simulation, the LM and the RM are co-located at gateway routers (GW/RM), and the RM function is distributed in all the gateways. The GW1/RM1 network presents the MN‟s communicating IP address-anchoring network; GW2/RM2 network is the MN‟s visited network; and GW3/RM3 network is the network where the CN resides.

To demonstrate that the GW1/RM1 network is located far away from GW2/RM2 network, intermediate routers (R0, R1, and R2) are placed in the path to the GW1/RM1 network, as illustrated in Figure 3-10. To make the simulation closer to real Internet scenarios, four nodes are connected to the inputs of each intermediate router (to both sides). The nodes p11,…, p14 through p61,…, p64 generate background traffic with an exponential distribution to congest the buffers at the output of the routers to the link input, by sending traffic to the sink/null station connected to the next router.

Each node generates a traffic load of 18.75Mbps under heavily loaded network conditions. A total load of 75Mbps (75% of the transmission capacity) has been generated at the buffer of the intermediate routers in both output sides to the link. The background traffic is received by the sink (null) station connected to the next router. For example, sink station sink_p11 frees the background traffic generated from nodes p11, p12, p13 and p14.

All the wired links are configured with bandwidth of 100Mbps. The wired link delay between intermediate routers is set to 0.25ms; and for the rest of the wired links, a delay of 0.1ms is used. The CN transmits the Constant Bit Rate (CBR) traffic over UDP of packet size 1000bytes every 0.01s to the MN. The MN is configured to move in a horizontal line at a speed of 30m/s from GW1/RM1 network to GW2/RM2 network. These configuration parameters are arbitrarily chosen for the purpose of investigating the behaviour of the proposed scheme through simulation.

To investigate the impact of the topological distance of the MN visited network from its communicating IP anchoring network on packet delivery latency, the topological distance from GW/RM1 network to GW2/RM2 network is varied by increasing the number of the intermediate routers in the path to GW1/RM1 network. Three, six, nine and twelve intermediate routers have been used to emulate the increase in topological distance between the GW2/RM2 network and GW1/RM1 network. During these changes, the background traffic nodes are increased and configured in a similar manner to generate congestions in the network at each intermediate router.

To demonstrate the handover delay improvement of the proposed mechanism, the TMAG has been configured in the overlapping region of GW2/RM2 and GW4/RM4 networks, as shown in Figure 3-8. The TMAG has connections to both GW2/RM2 and GW4/RM4; and it is carefully configured, so that the power it transmits is limited to the overlapping region. A new flag named

tmag-flag is added to extend the PBU sent from TMAG to GW4/RM4 to include the address of

GW2/RM2 (in order to differentiate it from the normal PBU message).