ISSN : 2249-2763
EISSN : 2249-2771
SOLANKI V.K.1*, TYAGI N.2
1Marwar Engineering College & Research Centre, Jodhpur- 342001, Rajasthan, India
2Motilal Nehru National Institute of Technology, Allahabad- 211004, UP, India
* Corresponding Author : vksolanki84@gmail.com
Received : 25-10-2012 Accepted : 06-11-2012 Published : 10-11-2012
Volume : 2 Issue : 1 Pages : 30 - 34
Int J Neural Network 2.1 (2012):30-34
Conflict of Interest : None declared
Fast Handover for Hierarchical Mobile IPv6 (F-HMIPv6) [4] tends to provide fast handover scheme in Hierarchical mobile IPv6 which reduces the handoff latency and signaling overload. It involves the pre-configuration of the new care-of address used at the new access router by the mobile node at the old access router during the handoff and the early binding update at the mobility anchor point by the mobile node. This method have an uncertainty that when to shift data traffic from mobility anchor point to the new access router (when mobile node moves from old access router to new access router), which results in packet loss. In this paper, we have proposed an approach to minimize the packet loss during handoff procedure in F-HMIPv6. Here the mobility anchor point bi-casts incoming data traffic to both the access routers (old and new) during handoff so that, the mobile node is able to receive packets during handoff and the uncertainty can be removed. We simulate the performance using network simulator (NS-2) and we analyze the performance of our proposed approach by comparing it with F-HMIPv6. The results show that our proposed approach improves the performance of F-HMIPv6 by reducing the packet loss and TCP end-to-end delay.
IPv6, Handoff, care-of address, mobility anchor point, Fast handover, access router, binding update, TCP end-to-end delay.
We know that every host in the internet is having a fixed IP address via which it communicates through the internet. Mobility of host would abrupt its communication or it may be disconnected. The solution to this problem is proposed in Mobile IPv6 [10] . Mobile IPv6 provides mobility support for IPv6. In Mobile IPv6, each mobile node is identified by two IP addresses: its home address and its care-of address (CoA) [11] . When MN arrives to a foreign network, it must acquire a new CoA, which is used during the time that the MN is under this location in the visited network. The MN has to send a binding update message to its home agent informing it about its current CoA whenever it moves to a new point of attachment or foreign network. The home agent then form a binding cache containing the mapping of the home address of MN to the current CoA and then tunnels [9] the data to the MN's current CoA. This binding update massage constitute a considerable amount of signaling latency i.e. amount of time spent to register CoA at the home agent, which in turn constitutes the handoff latency. The signaling latency of MIPv6 can be improved by protocols such as HMIPv6 (Hierarchical Mobile IP) [3] , designed for IPv6, introduces a hierarchical structure of MAP's (Mobility Anchor Points). The handoff latency of MIPv6 can be improved by introducing Fast Handovers for Mobile IPv6 [1] . Further these two approaches can be combined which involves the hierarchy of mobility anchor point (MAP) with the fast handover scheme proposed as Fast Handover for Hierarchical Mobile IPv6 (F-HMIPv6) [4] . We propose a method here which improves the performance of F-HMIPv6 by reducing the packet loss and TCP end-to-end delay.
The HMIPv6 [3] was developed to reduce the signaling overhead and delay concerned with Binding Update (BU) in Mobile IPv6. In HMIPv6, when a MN moves within a MAP region, the MN only sends a local BU to the local MAP, rather than the Home Agent (HA) and Correspondent Node (CN), as done in Mobile IPv6. If the distance from the MN to HA/CN is long, this local BU will considerably reduce the time required for the binding update. If we want to support the fast handover scheme in HMIPv6 network, the simplest approach will be to apply the FMIPv6 to the HMIPv6 in the straightforward way. We describe how to use FMIPv6 over HMIPv6 networks so as to provide better handover performance during handover [8] . At a glance, it may be straightforward to simply integrate the FMIPv6 scheme with HMIPv6. However, such simple integration may induce unnecessary processing overhead for re-tunneling at the old Access Router (oAR) and also inefficient usage of network bandwidth. The main reason for this is that the operation of HMIPv6 mainly depends on the functionality of a MAP, while the major functionalities of FMIPv6 are located in Access Routers (AR).
Now we describe here the generic F-HMIPv6 operations. It is assumed that the handover anticipation is supported with appropriate layer 2 triggers; and that the MNs as well as ARs are aware of the F-HMIPv6 scheme. The F-HMIPv6 procedures described here are based on the assumption that the MAP already has the information necessary for handover support about the ARs located in the HMIPv6 domain. This information should include the link-layer address (or identifier) and network prefix of each AR. We consider mobile-Initiated Handover here, as our proposed approach is based on mobile initiated handover case. [Fig-1] illustrates the generic procedures for F-HMIPv6 operations for Mobile initiated Handover. The detailed description for the control flows are given below:
1. Based on Layer 2 handover anticipation, the MN sends proxy router solicitation (RtSolPr) message to oAR. The RtSolPr will include information about the link layer address or identifier of the concerned nAR.
2. In response to the RtSolPr message, the oAR sends the proxy router advertisement (PrRtAdv) message to the MN, which contains information about new LCoA for the MN to use in the nAR region.
3. The oAR sends Handover Initiate (HI) message to nAR informing the LCoA selected by MN at the nAR.
4. nAR will send Handover Acknowledgement (HAck) message to oAR in response to HI message.
5. The MN sends Fast Binding Update (FBU) message to MAP. The FBU message contains old LCoA and IP address of the nAR.
6. After receiving the FBU message from MN, the MAP will tunnel data packets to the nAR. The nAR may cache those data packets flowing from the MAP, until it receives the Fast Neighbour Advertisement (F-NA) message from the newly incoming MN.
7. The MAP sends Fast Binding ACK (FBACK) messages toward the MN over old LCoA and new LCoA. Then, the MAP will begin to forward the data packets destined to MN to the nAR by using the established tunnel.
8. The MN sends F-NA messages to nAR, when it detects that it is moved in the link layer. Then, the nAR delivers the buffered data packets to the MN.
9. The MN then follows the normal HMIPv6 operations by sending a Local Binding Update (LBU) to MAP, as per HMIPv6. When the MAP receives the new LBU with new on-link CoA from the MN, it will stop the packet forwarding to nAR and then clear the tunnel established for fast handover.
As with the F-HMIPv6, the MAP forwards the packets to the nAR when it receives the F-BU message from MN. But the exact time at which the MAP forwards packets to nAR cannot be known or un-deterministic due to link layer handover i.e. when MN will disconnect from oAR and connect to nAR. Forwarding too late or too early will cause packet loss. To remove this uncertainty we replicate the packets to both the access routers from the MAP, this will minimize the packet loss. When nAR first receives the HI message from oAR it will send a JOIN message to the MAP. On receiving JOIN message the MAP will make a tunnel to the nAR. The MAP will now replicate or make copies of the incoming packets destined to MN and tunnels the packets to oAR and nAR, where the MN moves.
The message exchanged in proposed scheme is shown in [Fig-2] . The message sequence in proposed scheme is explained below:
1. Based on L2 handover anticipation, the MN sends RtSolPr message to oAR. The RtSolPr will include information about the link layer address or identifier of the concerned nAR.
2. In response to the RtSolPr message, the oAR sends the PrRtAdv message to MN, which contains information about new LCoA (on-link CoA) for the MN to use at the nAR region.
3. The oAR sends Handover Initiate (HI) message to nAR informing the LCoA selected by MN at the nAR.
4. In response to HI message, nAR will send a JOIN message to the MAP and participate in tunnel between MAP and nAR and send a Handover Acknowledgement (HAck) message to oAR.
5. On receiving JOIN message from nAR the MAP starts replicating the packets and tunnels them to oAR and nAR.
6. MN sends F-NA messages to nAR, when it detects that it has moved to nAR's domain (completed Layer 2 handover).
7. On receiving F-NA message nAR will send UNJOIN message to MAP indicating that the MN is moved to nAR and MAP will now stop replicating the packets and tunnels them to nAR.
The NS-2 (Network Simulator version 2) [2] is used for simulation and analysis of the proposed approach. [Fig-3] illustrates the network topology used for the simulation experiment. This topology reflects that where the MN is situated in Foreign Network and connected to a distant home network. Both Corresponding Node (CN) and the Home Agent (HA) are connected to an intermediate router (N1) with 2 milliseconds (ms) delay, 100 Megabits/s (M/s) links. The link between N1 and the MAP is a 100M/s link with 50ms delay. The MAP is connected to 2 intermediate routers (N1, N2) with 2ms delay, 10M/s links. All intermediate routers in local networks are connected with the access routers AR1 and AR2 with 2ms delay, 1M/s links. All links use the RED (Random Early Detection) queue, except links from the intermediate nodes to the AR's which are Droptail (FIFO) queues. RED queues simply mark the delayed packets while FIFO queue discards the delayed packets. The simulation parameters used to create simulation environment is listed in [Table-1] .
An ns TCP source agent is attached to the CN and an ns TCP sink agent is attached at the MN. An application (FTP) is attached on the established TCP link that transfers packets from the CN to the MN, 10 seconds after the start of the simulation. The total duration for the simulation is 80 seconds. For proposed scheme simulation, AR2 sends the JOIN message to MAP on receiving the Handover Initiate (HI) message from the AR1. The MAP then replicate the packets coming from the CN to AR1 and AR2 until the AR2 will send the UNJOIN message. [Fig-4] shows the sequence number for TCP data packets received by MN for the F-HMIPv6 case. There is handoff around 40.5 secs in simulation. This is due to that MN enters into new base stations range. MN starts receiving the beacon of new base station and executes handoff. During this handoff period MN was unable to receive packets. When MN enters to new AR's range the MN would receive packets. Once the MN connects to the new AR, it is able to receive out of sequence packets and sends acknowledgement containing expected sequence number as shown in [Fig-5] .
Then TCP enters into retransmission mode, and starts slow start congestion control algorithm. The handoff delay in this case is 437 msec. [Fig-6] shows the sequence number for TCP data packets received by MN for the Proposed Scheme. There is handoff around 40.5 secs in simulation. The MAP starts replicating the incoming packets to both the old and new AR's, so that MN would continuously receive out of sequence packets during handoff. So, the total number of packets received by MN is more in proposed scheme. In proposed scheme, during handoff still MN is able to receive the out of sequence packets from both the access routers and sends acknowledgement containing expected sequence number as shown in [Fig-7] . Here at certain times during handoff more than two acknowledgements are sent by MN for the received packets. When a duplicate ACK is received at CN, it does not know if it is because a TCP packet was lost or simply that a packet was delayed and received out of order at the receiver. When more than two acknowledgements are received, it informs the TCP to not go into slow start mode and start a Fast Retransmit and Fast Recovery method. So in our scheme there is less packet loss than the F-HMIPv6. [Table-2] shows the amount of packet loss and average end to end delay for the TCP traffic for 80 seconds simulation time. There is 0.40% packet loss in the F-HMIPv6 method which is 0.14% in our scheme. So we say that we reduced the packet loss to 0.26% less than FHMIPv6. Also the Average End-to-End delay in FHMIPv6 it is 148.09 milliseconds where as in our approach it is 144.28 milliseconds. Here we reduced the Average End-to-End delay too.
We also simulated our topology for CBR traffic; we setup a CBR Agent at the CN. [Fig-8] shows the Packet loss over different data rates. We measured the Packet Loss in both the approaches at different data rates ranging from 32Kb/s to 1024Kb/s. At data rates 32Kb/s, 64Kb/s, 128Kb/s and 256Kb/s the packet loss is same in both the approaches. But at data rate 512 Kb/s the packet loss is 15.76% in FHMIPv6, but it is 14.31% in proposed approach, and also at 1024 Kb/s the packet loss is 67.22% in F-HMIPv6, but it is 63.96% in proposed approach. So our approach gives lower packet loss than F-HMIPv6. Also we tested our approach at different MN's speed keeping the data rate constant at 448kb/s. [Fig-9] shows the results at 20, 40, 60, 80 and 100m/s MN's speed. We have a comparable results and lower packet loss than F-HMIPv6. Thus we have proposed a modification in F-HMIPv6 which in turn improves the performance of F-HMIPv6.
The F-HMIPv6 provides fast handoff mechanism which minimizes the handoff latency but having uncertainty during handoff when MAP will shift data traffic from oAR to nAR. Our proposed scheme tends to modify the existing Fast Handovers in Hierarchical Mobile IPv6 to provide higher packet delivery during handoff. The replication of incoming data traffic by Mobility Anchor Point to the access routers where the MN will move during handoff will reduce the packet loss and end-to-end delay. We conclude that our approach produce better results for TCP and UDP data traffic in terms of packet loss and end-to-end delay.
[1] Dommety G., et al (2002) IETF Draft.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[2] Kevin Fall Editor, Kannan Varadhan, The Ns Manual, The VINT Project, A collaboration between Researchers at UC Berkeley, LBL, USC/ISI and Xerox PARC.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[3] Malki K., Soliman H., Castelluccia C. and Bellier L. (2001) IETF RFC, 4140.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[4] JongWha Y.I., HeeYoung Jung, EunAh Kim and HyeongHo Lee (2005) ETRI Journal, 27(6), 798-801.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[5] Hinden R. and Haberman B. (2003) IETF RFC, 3513.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[6] Narten T., Nordmark E. and Simpson W. (1998) IETF RFC 2461.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[7] Sangheon Pack, Taekyoung Kwon and Yanghee Choi (2007) Computer Networks, 51, 6, 1630-1642.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[8] Xavier Perez-Costa, Marc Torrent-Moreno and Hannes Hartenstein (2003) SIGMOBILE Mob. Comput. Commun. Rev., 7(4), 5-19.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[9] Perkins C. (1996) IETF RFC, 2003.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[10] Perkins C. (1996) IETF RFC, 2002.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[11] Jochen Schiller (2000) Mobile Communications, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[12] Thomson S. and Narten T. (1998) IETF RFC, 2462.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[13] Marc Torrent-Moreno, Xavier Pérez-Costa, Sebastià Sallent-Ribes (2003) 28th Annual IEEE International Conference on Local Computer Networks, 89.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
 | Fig. 1- Message sequence in F-HMIPv6 for Mobile-Initiated Hand ver |
 | Fig. 2- Message sequence in Proposed Scheme |
 | Fig. 3- Simulation Topology |
 | Fig. 4-Sequence number for TCP data in F-HMIPv6 |
 | Fig. 5- Sequence number for TCP Acknowledgement in F-HMIPv6 |
 | Fig. 6- Sequence number for TCP data in Proposed Scheme |
 | Fig. 7- Sequence number for TCP Acknowledgement in Proposed Scheme |
 | Fig. 8- Comparison of Packet loss at different data rates |
 | Fig. 9- Comparison of Packet loss at different MN’s speed |
 | Table 1- Simulation Parameters |
 | Table 2- Comparision of F-HMIPv6 and Proposed Scheme Over FTP Traffic |