Abstract
The new IEEE 802.21 standard specifies link layer intelligence and other related network information to upper layers in order to optimize handovers between networks of different types, such as WiMAX, Wi-Fi, and 3GPP. This paper makes a short description of 802.21 standard, how it is implemented in ns-2, and the signaling used in a handover between WiMAX and Wi-Fi. The paper also proposes a novel and very simple approach to determine the expected number of handovers in an ns-2 simulation and also evaluates the reliability and scalability of ns-2 when simulating 802.21 scenarios with multiple nodes.
1. Introduction
As wireless users constantly demand for more mobility and bandwidth, a solution was needed that allows their mobile devices to use “any” network in range in order to get coverage or better service. The IEEE 802.21 standard [1] is a first step in order to allow mobile devices to successfully make a handover (HO) between networks of different technologies, such as WiMAX, Wi-Fi, UMTS, Bluetooth, or Ethernet.
The most basic way of describing an HO is when a phone call in progress is redirected from its current cell to a new cell. This normally happens when the mobile device making the call is in movement and detects that it is losing coverage, so it needs to “jump” to another antenna. When the HO is within the same technology, for example, between Wi-Fi cells, it is called a horizontal HO. If it is executed between different technologies, for example, WiMAX to Wi-Fi, then it is called vertical HO. Horizontal HOs are easy to implement because the operation is typically made under the same operation domain. Vertical HOs, on the other hand, are typically executed between different operators, and require a much more complex signaling.
This paper is an attempt to evaluate the reliability and scalability of the network simulator-2 (ns-2) [2] tool in simulating multiple vertical HOs under the scope of IEEE 802.21. Currently the 802.21 functionality can be incorporated in ns-2 by using external add-on modules developed by the National Institute of Standards and Technology (NIST) (NIST is a nonregulatory federal agency within the U.S. Department of Commerce. NIST's mission is to promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology.),that are based in 802.21 (draft 3).
The paper is structured as follows. Section 2 explains the current implementation of IEEE 802.21 in ns-2. Section 3 describes relevant related work published by research projects and the academic community. Section 4 provides a general description of the signaling involved in a handover between WiMAX and Wi-Fi technologies and presents a message sequence chart for the correspondent events in ns-2. Section 5 describes our simulation scenario, presents a novel approach to determine the expected number of handovers in an ns-2 simulation and also presents simulation results. Section 6 deals with result analysis and conclusions and future work. Finally, Section is for acknowledgments.
2. Related Work
Since the release of the mobility package by NIST, as part of their joint work with IEEE 802.21 and the IETF, numerous research studies have used these modules. Reference [3] evaluates the performance of an adaptive channel scanning algorithm for IEEE 802.16 using a previous version of the WiMAX module that is used in this paper. In [4] the handover latency for the cases where UDP and TCP carry MIH signaling messages is compared and some of the design tradeoffs are presented. The evaluation of the performance of a vertical handoff scheme between 802.11 and 802.16 wireless access networks with respect to signaling cost, handoff delay, and QoS support can be found in [5]. Reference [6] evaluates a proposed cross-layer mechanism for making intelligent handover decisions in FMIPv6 in terms of handover latency, packet loss and handover signaling overhead, and [7] evaluates a new enhanced Media Independent Handover Framework (eMIHF) that allows for efficient provisioning and activation of QoS resources in the target radio access technology during the handover preparation phase.
The use of ns-2 with NIST modules has also been used to propose new implementation guidelines to the new security extension for IEEE 802.21 that is yet to come (IEEE 802.21a). Reference [8] compares different authentication techniques, namely, reauthentication and preauthentication, that may be used in order to reduce the time and resources required to perform a vertical handover. Reference [9] measures the performance of the authentication process in media independent handovers and considers the impact of using IEEE 802.21 link triggers to achieve seamless mobility, and [10] proposes an extension to current network selection algorithms that takes into account security parameters and policies and compares the handover performance with and without the proposed extension.
3. Heterogeneous Handovers in ns-2
The support for vertical HO scenarios is available, but limited, in ns-2 through the use of NIST add-on modules [11]. These modules were developed for version 2.29 of ns-2. NIST added and changed numerous files in the standard release of ns-2 in order to support mobility scenarios. The following are some of these changes:(i)development of a new IEEE 802.21 add-on module [12], based on draft 3 of IEEE 802.21;(ii)development of a new IEEE 802.16 add-on module [13], based on IEEE 802.16g-2004 standard [14] and the mobility extension 802.16e-2005 [15] (both updated in 2007);(iii)development of a new Neighbor Discovery add-on module [16] for IPv6 (limited functionality);(iv)update of the existing IEEE 802.11 MAC implementation [17].
3.1. IEEE 802.21 Support in ns-2
The 802.21 add-on module contains an implementation of the Media Independent Handover Function (MIHF) based on draft 3 of IEEE 802.21 specification. An overview of the MIHF interaction with the different components of the mobile node (MN) is shown in Figure 1.
The MIHF and MIH Users are implemented as Agents. An Agent is a class defined in ns-2, extended by NIST, that allows communication with both the lower layers (i.e., MAC) and the higher layers (i.e., MIH Users), providing the mapping between the media independent interface service access point (MIH_SAP) and the media-dependent interface (MIH_LINK_SAP and media-specific primitives). Because of this, the MIHF can send layer 3 packets to remote MIHF and MIH User can register with the MIHF to receive events from local and remote interfaces. The MIHF is also responsible of getting the list and status of local interfaces and control their behavior. The MIH User class is hierarchy organized according to Figure 2.
From Figure 1, we can see that MIH Users make use of the functionalities provided by the MIHF in order to optimize the HO process. MIH Users typically will send commands to the MIHF and receive events or messages. The Interface Management class (IFMNGMT), depicted in Figure 2, provides flow management functions which facilitate the HO module in finding the flows that need to be redirected. The IFMNGMT also receives events from the Neighbor Discovery (ND) agent when a new prefix is detected or when it expires. The MIPV6 Agent adds the redirection capability to the MIH User. When a flow needs to be redirected, a message can be sent to the source node to inform it of the new address or interface to use. The Handover class provides a template for HO modules and computes a new address after a successful HO.
3.2. Supported Technologies in ns-2
Currently ns-2 supports the following technologies in IEEE 802.21 scenarios: WiMAX (802.16), Wi-Fi (802.11), and UMTS and ethernet (802.3). In the scope of the work described in this paper only WiMAX and Wi-Fi will be used in the simulation scenario described in Section 4.
3.2.1. Implementation of Nodes with Multiple Interfaces in ns-2
Supporting nodes with multiple interfaces is not intuitive in ns-2, because external packages do not necessarily follow the same node structure as the one defined in the basic model (i.e., routing algorithms are different). To resolve this issue, NIST created the concept of multiFace node, which is a node who links to other nodes. The other nodes are considered interfaces for the multiFace node, and the multiFace node can be viewed as a “supernode”. This concept is illustrated in Figure 3.
The interface nodes trigger events and send them to the multiFace node. The MIH Users on the multiFace node can register to receive these events. Additionally each of the interface nodes will also run an instance of the Neighbor Discovery (ND) agent, detailed in Section 3.2.5, in order to detect layer 3 movement.
3.2.2. Integration of WiMAX
The WiMAX module was developed entirely by NIST, the supported features are shown in Table 1.
A limitation of the implemented WiMAX model is that, when using WiMAX cells, at the beginning of the simulation there must be at least one MN within each cell range in order for the BS to function correctly. Due to this condition, a WiMAX simulation scenario has to include “phantom” nodes. Figure 4 illustrates this concept.
3.2.3. Integration of Wi-Fi
Regarding the Wi-Fi module, the following features were changed in order to support basic 802.21 functionality [17].(i)Backoff and Defer Timers. The modifications made include the separation of the defer time (such as SIFS, DIFS, or EIFS in IEEE 802.11 standard) and the backoff time. Another modification is that after receiving an ACK, a backoff is triggered only if there is no beacon to be sent.(ii)Management Frames—Beacons. The beacon messages have been added to the implementation. They can be used by an AP to inform the MN about its presence, and are sent at a specific interval (typically every 100 ms).(iii)Management Frames—Association Request and Response. The Association Request and Response frames have been added to allow an MN to connect to an AP at layer 2 and to add the possibility of an AP to reject the MN from accessing the network (e.g., as part of a congestion control mechanism).(iv)Support for Multiple APs and Scanning. Modifications were made to resolve the scanning functionality and the interference model when using multiple APs. As a result all MNs share the same channel object which is responsible of knowing the frequency used by each MN’s physical layer. Only the MNs using the same frequency will communicate with each other. With these new capabilities, it is possible to implement scanning mechanisms at the MAC layer.
3.2.4. Integration of Information Services, Command Services, and Event Services
IEEE 802.21 standard defines three types of services: Information Services (ISs), facilitate discovery and selection of multiple types of networks that exist within a geographical area; Command Services (CSs), enable higher layers to control the physical, data link, and logical link layers and; Event Services (ESs), indicate changes in state and transmission behavior of the physical, data link, and logical link layers or predict state changes of these layers. ISs are currently not supported in ns-2 802.21 implementation. Both CS an ES are supported, Table 2 shows the correspondent primitives.
3.2.5. Support for Subnet Discovery and Change of Address
For supporting subnet discovery and change of address when making an HO, ns-2 makes use of Router Advertisement (RA), Router Solicitation (RS), and ND messages. RA messages are broadcasted periodically by Access Points (APs) or base stations (BSs) to inform MNs about the network prefix. In ns-2, each AP (Wi-Fi) or BS (WiMAX) is on a different subnet (domain or cluster in ns-2 nomenclature) and therefore will require a layer 3 HO, so the prefix is the address of the AP/BS that sends the RA.
The ND agent located in each MN is responsible for receiving RA messages and determines if it contains a new prefix; if yes the ND agent informs the interface manager; if not, the timer associated with the current prefix is refreshed. If an MN loses the connection with its current point of attachment (PoA), AP or BS, it will not receive more RAs from that PoA therefore the current prefix expires; in this case a notification is also sent to the interface manager.
RS messages are used by MNs to discover new APs or BSs after the HO.
3.2.6. Power Boundaries in Wi-Fi and WiMAX Cells in ns-2
In order to identify power boundaries to be used in the simulation, three variables were defined [17]; see Figure 5. The description of the power boundaries is as follows.(i)CSTresh defines the minimum power level to sense wireless packets and switch the MAC from idle to busy;(ii)RX Tresh defines the minimum power level to receive wireless packets without error;(iii)pr_limit is always equal or superior to 1 and is used in the equation (RX Tresh_)*(pr_limit_); this equation defines the minimum power level that an interface senses before triggering a Link_Going_Down event. The higher the pr_limit_ coefficient, the sooner the event will be generated.
4. General Description of a Handover between WiMAX and Wi-Fi
This section provides a short description of the sequence of events that a MN and network perform in order to make a successful HO. The power received at MN’s interfaces, depicted in Figure 6, and the message sequence chart depicted in Figure 7 are important to better understand the description that follows.
Figure 6 shows that a particular MN started in a WiMAX cell and in the first 10 s the MN is stopped. Then it started to move in direction of the center of the BS, and in its way a Wi-Fi network was detected. Since the used HO algorithm considers Wi-Fi a better network than WiMAX, the MN makes the HO to the Wi-Fi network ( s). MN stays in this network for approximately 7 s, when it senses that it is losing coverage. Since the WiMAX signal is still available the MN makes a new HO to the WiMAX network (because it has no better network). The MN is the closest to the BS at instant , when the Rx power is at its highest value. The MN then continues its way and stops at instant s.
A more detailed description of the sequence of events is as follows.(1)MIH user on the MN sends MIH Get Status Request to MN’s MIHF.(2)MN’s MIHF responds with an MIH Get Status Response, saying that two interfaces are available: one is link type 27 (WiMAX) and the other is link type 19 (Wi-Fi); both interfaces support commands and events.(3)MIH user subscribes for events on both MN’s interfaces.(4)MN’s WiMAX interface receives a Download Context Descriptor (DCD) and an Upload Context Descriptor (UCD) from the BS and triggers a Link Detected event.(5)MIH User Agent in the MN receives the Link Detected and since this is the only interface detecting a possible PoA, it commands MN’s WiMAX interface to connect to the BS.(6)MN’s WiMAX interface connects to BS and triggers a Link Up event that is received by MN’s MIHF that then commands MN’s MIPv6 agent to request the ND Agent to send an RS.(7)MN’s WiMAX interface sends an RS; BS detects that this is a new neighbor, it then sends an RA including: router-lifetime (1.800 s), prefix valid_lifetime (5 s), network prefix (ex. 2.0.0), and advertisement interval (10 s).(8)MN’s WiMAX interface receives the RA. This interface will now reconfigure its address according to the received prefix (i.e., interface address = 2.0.1). MN’s MIH Agent is notified and commands the WiMAX interface to send an MIH Capability Request to the BS.(9)BS receives the MIH Capability Request and sends an MIH Capability Response including its MIHF identification; MIH Agent now knows the identification of the remote (PoA) MIHF identification.(10)At s, CN starts to send CBR traffic to the MN. Traffic is received through the WiMAX interface.(11)At s, MN starts moving towards Wi-Fi cell.(12)At approximately s, MN’s Wi-Fi interface starts detecting 802.11 beacons and triggers a Link Detected event when the received power of the beacon frames is above the threshold value; MIH Agent in the MN receives the Link Detected event and, since this is a better interface, it commands MN’s Wi-Fi interface to connect to the AP.(13)MN’s Wi-Fi interface and the AP exchange Association Request and Response frames in order to connect the MN to the Wi-Fi cell. After MN’s Wi-Fi interface receives the Association Response, it will trigger a Link Up event; MIH Agent in MN receives the Link Up event and commands MN’s MIPv6 agent to request the ND Agent to send an RS.(14)MN’s WiFi interface sends an RS; AP receives the RS and detects that this is a new neighbor, it then sends a RA including router lifetime (18 s), prefix valid lifetime (5 s), network prefix (ex. 3.0.0), and advertisement interval (10 s).(15)MN’s Wi-Fi interface receives the RA. This interface will now reconfigure its address according to received prefix (i.e., interface address = 3.0.1). MN’s MIH Agent is notified.(16)MN’s MIPv6 Agent commands the Wi-Fi interface to send a Redirect message to the CN in order to inform the CN of the new MN location; CN’s MIPv6 Agent receives the Redirect message and sends an Ack message that is later received by MN’s Wi-Fi interface which then notifies MN’s MIH Agent. This behavior is considered a make-before-break, that is, the MN will use both interfaces at the same time in order to perform a seamless HO.(17)At approximately s MN’s MIH Agent has the confirmation that the CN has been notified of MN’s new address and redirects the reception of CBR traffic from the WiMAX interface (2.0.1) to the Wi-Fi interface (3.0.1); traffic comes in using the link between Wi-Fi interface and AP.(18)MN’s MIH agent commands the Wi-Fi interface to send a MIH Capability Request to the AP; AP responds with a MIH Capability Response including its MIHF identification; this process is similar to what was described to WiMAX.(19)MIH Agent receives the MIH Capability Response with the identification of the new remote (PoA) MIHF identification.(20)At approx. s the MN is approaching the boundary of Wi-Fi cell so the Wi-Fi interface triggers a Link Going Down event (based on the received power of the beacon frames); due to MN’s speed the probability that the Wi-Fi link goes down starts to increase. When it reaches a specified value (90% in our case), and since MN’s WiMAX interface is still active, the MN MIPv6 Agent commands the WiMAX interface to send a Redirect message to the CN in order to inform the CN of the new MN location (2.0.1). Additionally the MN’s MIH Agent commands the Wi-Fi interface to execute a Link Scan in order to search for other nearby Wi-Fi networks.(21)MN’s Wi-Fi interface executes the scan sending a Probe Request in each of the defined IEEE 802.11 channel frequencies. A Probe Response is only received in channel 2 (where the MN currently is). Based on this, MN’s MIH Agent is notified that this is the only available Wi-Fi network.(22)CN’s MIPv6 Agent receives the Redirect message and sends Ack message that is received by MN’s WiMAX interface; MIH Agent is notified.(23)At approximately s MN’s MIH Agent has the confirmation that the CN has been notified of MN’s new address and redirects the reception of CBR traffic from the Wi-Fi interface (3.0.1) to the WiMAX interface (2.0.1); traffic now comes in using the link between the WiMAX interface and BS. (24)Almost at the same time MN’s Wi-Fi interface triggers a Link Down event, and the MN is disconnected from Wi-Fi cell.
5. Simulation Scenario
The simulation of 802.21 HOs between heterogeneous networks using ns-2 has two main purposes: (i) evaluating 802.21 NIST add-on modules for ns-2 and (ii) evaluating the reliability and scalability of ns-2 in simulating 802.21 scenarios.
In order to achieve these goals, a network topology consisting of one WiMAX base station, three Wi-Fi access points and a variable number of MNs was created. Choosing for a variable number of MNs allows us to measure ns-2 scalability in simulating 802.21 scenarios. Figure 8 presents the network topology, and Table 3 presents values for the most relevant variables.
5.1. Determining the Number of IEEE 802.21 Handovers in ns-2
When simulating IEEE 802.21 scenarios in ns-2 with a variable number of nodes with random start and end positions, it is important to determine the number of HOs that would be triggered by MNs. Comparison between this value and the effective number of HOs that were produced in ns-2 simulation is important because it is an indication of the HO success rate as the number of MNs increases in the simulation. Since ns-2 does not provide this information, a new innovative way of determining such a value is proposed in this paper. Taking in consideration Figure 8 and knowing that MNs have a rectilinear movement (Table 3), a handover happens when a MN crosses the boundary of a 802.11 cell; this is independent of the start and end positions of the MN.
Using the MN positioning data obtained from ns-2 simulation, it is possible to draw the trajectories of each simulated MN. The total number of intersections between the MNs trajectories and 802.11 boundaries gives the theoretic number of handovers in the simulation.
The trajectories for 100 MNs triggering a total of 79 handovers can be seen in Figure 9; the big circle corresponds to the WiMAX coverage area, the three small circles correspond to the three Wi-Fi cells coverage and the lines correspond to MN trajectories. Each line starts with a small circle (MN start position) and ends with a cross (MN end position). The intersections between lines and the three Wi-Fi circles are indicated by small triangles. Each Wi-Fi cell has also two doted circles representing the power boundaries described in Section 3.2.6.
5.2. Simulation Results
To evaluate ns-2 as a platform for simulating handovers in 802.21 scenarios, we measure (i) system packet loss, (ii) handover time (delay), and (iii) the impact of higher traffic bit rates in the system.
Figure 10 shows the packet loss in the system. The packet loss in the system is the difference between the total number of packets sent by the CN and the number of the packets received by all MNs (including both WiMAX and Wi-Fi interfaces).
Figure 11 shows the evolution of HO time from WiMAX to Wi-Fi and vice versa as the number of MNs increases in the system. The HO time is the amount of time that elapses between an interface sending an MIPv6 Redirect Request to the CN and receiving the correspondent Redirect Ack from the CN.
For the specific simulation of 100 MNs in the system, Figure 12 identifies the MNs that executed an HO, the wireless networks to which a particular MN has made the HO, and the specific time it took for that specific handover. As an example, we can see that MN number 10 executed two HOs, one to the WiMAX cell and the other to Wi-FI cell (AP3). MN number 60 has not made any HO. Figure 12 also shows that for 100 MNs in the system the average HO time to Wi-Fi cell (less sensitive to the number of MNs in the simulation) is approximately 5 ms, and the average HO time to WiMAX cell is approximately 230 ms (also see Figure 11 for 100 MNs).
Figures 12, 13, and 14 show how the increase in bit rate and the number of MNs in the simulation affect the packet loss and the HO time (delay).
6. Conclusions and Future Work
IEEE 802.21 uses a significant amount of signaling in the nodes themselves and between the nodes and network infrastructure. Even considering the fact that the NIST 802.21 add-on modules only support limited functionality of the standard, the amount of signaling generated by this module is significant. Adding to this, there is also all the signaling from 802.11 and 802.16 (including management and beacon frames). Beacons frames are mandatory in the simulation, because MN’s interface uses them to trigger MIH events such as “Link Detected” or “Link Going Down” (see Table 2); they are a fundamental part of the network discovery process MNs do in order to discover networks (better coverage or better service).
From our analysis, packets are lost mainly due to (i) address resolution issues, in which case ARP must run every time a MN enters a new cell, (ii) the handover operation and, (iii) insufficient bandwidth in the deployed radio access technologies. It is also possible to see this effect in Figure 13.
For audio, lost packets produce choppy, broken audio. The IEEE 802.20 Working Group [18] recommends less than 2% packet loss for mobile voice.
For video in mobile networks, packet loss tolerance heavily depends on the scenario. A packet loss of 1% [18] is accepted for noninteractive video; for interactive video, such as in a videoconference, the recommended is less than 0.1%.
Looking at the obtained results for packet loss in our simulated scenario, see Figure 10, we can see that if more than 40 MNs are present in the topology, voice would degrade to bad quality. For video, only non-interactive applications would be allowed, because buffering and retransmission of lost packets are possible. If traffic flow has an increased bit rate, see Figure 13, video support would degrade to unacceptable quality.
Regarding the handover time, results depicted in Figures 11 and 12 show that HO to the WiMAX cell is more sensitive to the number of MNs in the simulation than the Wi-Fi cells. This can be explained by the fact that the WiMAX cell is bigger than the Wi-Fi cells, so is the total number of MNs inside the WIMAX cell. Since each MN is receiving traffic from the CN, more traffic is being supported by the WiMAX cell. Additionally, we observed that the delay associated with the first part of the handover (till redirect message reaches the CN) has the same tendency as the ones in Figure 11. We concluded that this difference in behavior is related to how, in ns-2, these two technologies implement the uplink and downlink scheduler and the contention resolution/avoidance for the wireless shared medium.
Considering IEEE 802.20 Working Group recommendations for mobile voice, the one-way network delay should be less than 150 ms. By looking to the evolution of the handover delay to WiMAX depicted in Figure 11 we could think that in the simulated scenario the obtained results were acceptable to guarantee such recommendation; however the measured HO time does not take in consideration that some HO features, such as user authentication, resource query, and resource reservation in the target network, are not currently implemented in NIST add-on modules for ns-2. If such features were supported, the HO delay would increase; as shown in [10] by including authentication and some additional primitives for Information Services, the handover delay can reach up to 1 second.
According to [18] a delay of 150 ms and 200 ms is acceptable for low- and high-quality voice, respectively, in mobile networks. For non-interactive video a one-way network delay of 280 ms [18] is acceptable, and for interactive video, the delay will depend on the class of interactivity. According to ITU-T Recommendation Y.1541 [19], a network delay of 100 ms is acceptable for class 0 and up to 400 ms is acceptable for class 1.
Results depicted in Figures 11, 12, 14, and 15 show that such recommendations can be achieved during handover by both WiMAX and Wi-Fi technologies, given that the number of associated MNs and traffic flow volume are in acceptable values.
We can say that ns-2 with NIST add-on modules proved to be a valuable tool to simulate IEEE 802.21 handover scenarios and better understand the basic signaling of IEEE 802.21 standard. NIST add-on modules however, only support part of the standard (based on draft 3) and were not conceived to simulate a high number of MNs as some adaptations in ns-2 were needed in order to run the simulations described in this paper. Nevertheless obtained results have proven an acceptable approximation to what could be expected in real case scenarios.
Considering that add-on modules, such as WiMAX, Wi-Fi, UMTS, Bluetooth, FMIPv6, amongst others, are constantly being added and updated by the ns-2 community, the importance of ns-2 for 802.21 simulations becomes clear. It will not only allow simulating complex vertical handover scenarios, prohibitive to do in a real testbed, but also allow modifying such modules in order to model missing primitives and better predict results for a real scenario. As shown by our experiments, both WiMAX and Wi-Fi modules need improvements in the scheduling mechanisms and the contention resolution/avoidance for the shared medium in order to better reflect the technology’s real behavior.
As future work, new contributions could appear on the following topics: (i) implementation of missing IEEE 802.21 primitives in ns-2 using the current NIST modules in order to better simulate seamless HOs in conformance to the IEEE 802.21 standard; (ii) implementation of a retransmission mechanism for MIP messages in order to improve the success ratio of handovers; (iii) implementation of Information Services and a Media Independent Information Server (MIIS) that MNs could query in order to obtain neighbor network information.
Acknowledgment
The work presented in this paper was supported by the European Project ICT-HURRICANE and the Portuguese Foundation for Science and Technology (FCT) through Project AGILE.