Media Independent
Mobility and QoS Support package for NS-2

---

Content

Main Page

Implementation

Software Tools

NS-2 NIST add-on

New Implementation

Related Links

IEEE 802.21
NIST

Publications

Neves, P.; Sargento, S.; Melo, M.; Fontes, F.; Pentikousis, K.; "Enhanced Media Independent Handover Framework", Proc IEEE Vehicular Technology Conference-(VTC-Spring), Barcelona, Spain, Vol. N/A, pp. N/A - N/A, April, 2009.

Neves, P.; Soares, J.; Sargento, S.; "Media Independent Handovers: LAN, MAN and WAN Scenarios", Proc IEEE Global Telecommunications Conf. - GLOBECOM, Honolulu (Hawaii), United States, Vol. N/A, pp. N/A - N/A, November, 2009

Contacts

Technical Development

In this section we enumerate the additions and modifications made to the simulator in order to improve the NIST add-on IEEE 802.21 implementation.

Modifications

One of the major drawbacks of the 802.21 NIST add-on was the lack of support for the 802.21 entities on the network side, specifically the MIHU. Therefore there was only local communication with the MIHUs, missing the communication between MIHUs on the network and on the MN. To overcome this limitation and permit the communication between all the network entities, either local or remote, an MIHU was specified and implemented on the network side (PoAs).

MIHF

The MIH code was also provided with several changes due to the UMTS technology:

• First of all, UMTS does not support broadcast, and so when a UE is sending a Capability
  Discover Request, it needs to send directly to the target MIH.
  
• As it is known, theoretically the UMTS network MIH is suppose to be in the BS in order to control each BS individually. However, due to the simulator limitations it was not possible to install it in the BS and as in the simulations there is only one BS for UMTS, the solution found was to install the MIH in the RNC node, and connect it to the MAC layer of the BS. This has no relevant implication because in this case the RNC only covers one BS. Although the network MIH for UMTS being in the RNC does not have major influence in a theoretically level, it has regarding the MIH implementation. The MIH_Link_Up function was modified in order to support the UMTS network MIH.
• The current simulator implementation only performs IEEE 802.21 handovers when a Link Going Down is detected. In this new upgrade, it is possible to perform a handover not only in a Link Going Down case, but also when a Link_Detected is received. The IEEE 802.21 - draft 14 in its examples only shows handovers deployed by a MIH_Link_Going_Down message. However it is possible that we are for example connected to an UMTS network, that provides the user the required resources, but at some time we have available another network that can have a better performance or even a better pricing and still provide the user its requirements. In this situation, the user could turn the interface up in order for it to detect the new network and see if it has better conditions than its serving network. If so, a handover process would occur.

The modifications mentioned above, are considered the most relevant ("high level") ones. Each of of these modifications led to more changes in the code, considered "low level" changes, and as so are not mentioned here.

New Messages

The new messages added/implemented in order to upgrade the previous IEEE 802.21 implementation were:

• MIH Commands
  • MIH_MN_HO_Candidate_Query
  • MIH_N2N_HO_Query_Resources
  • MIH_MN_HO_Commit
  • MIH_Net_HO_Commit
  • MIH_N2N_HO_Commit
  • MIH_MN_HO_Complete
  • MIH_N2N_HO_Complete
• MIH Information
  • MIH_Get_Information

UMTS implementation

The modifications made to the simulator in order to allow the interaction between the IEEE 802.21 and the UMTS technology were done, taking in consideration that the data channel used for UMTS in the simulations was the DCH channel.
There are several points extremely important to mention about the simulator's current UMTS implementation, which are:

• the implementation is based on the 3GPP Release 99, and so the model implemented is the UTRAN. When defining an UMTS scenario we define the RNC, BS and the UE.
  
• the concept of mobility using an UMTS interface is distorted. In fact, what happens is that the UE is a stationary point that has no capability to move and is always in the BS range. However what is done is that, the UE (interface) is defined and associated to a MN, so wherever the MN is, it is connected to the UMTS interface. The disadvantage is that the MN never leaves the UMTS BS range, and there is no possibility to simulate handovers between UMTS cells. The interpretation made regarding this situation was:
• Nowadays, the 3GPP is available worldwide and the user has access to the 3GPP network almost everywhere.
  
• when defining any type of device in NS-2, whether it is a router, a Wi-Fi/WiMAX BS or a MN interface, the simulator creates the MAC layer, and with it, an unique MAC address associated to the device. However this doesn't happen with the UMTS devices, namely the BS and the UE. According to the channels that are configured, DCH or HS-DCH, the MAC addresses are change. The devices are created with a specific MAC address by the base MAC class, but are changed according to the configurations made in the UMTS specific MAC class. Regarding this issue, the simulator works in the following way:
• Each technology has its specific MAC class. The NS-2 when creating any element, calls its MAC class which is common to all elements, and after that the specific one for each technology is called. In the UMTS case, when the specific one is called, it changes the unique MAC address given by the base class.

MAC Layer

Regarding the MAC address issue for UMTS elements, some changes in the simulator were done, namely in the MAC class.
To exchange the MIH messages between the different entities the current implementation works as follows: each MIH entity has associated to it a MAC address; in order to send messages we need to get the IP addresses; this is done through a function that receives as input the entity MAC address and returns the IP address of its node. In other words, we need the MAC address provided to each entity in the NS-2 MAC class, whether it is changed or not later (as happens with UMTS).
In order to provide unique MAC address values into UMTS elements, so that they could be distinguished it was necessary to made a small change in the MAC layer of the simulator. The NS-2 MAC layer is defined in the files located in the "mac" folder, namely in the mac.cc and mac.h files. An extra variable was created in order to store the original values of the MAC addresses. With this change, the variable of the MAC address of UMTS elements is still with the value zero, which is necessary for the UMTS structure to work, but at the same time it is possible to distinguish them from each other, and from other elements in the network by analyzing the new variable.