Seamless Handover Scheme for Proxy Mobile IPv6

IEEE International Conference on Wireless & Mobile Computing, Networking & Communication Seamless Handover Scheme for Proxy Mobile IPv6 Ju-Eun Kang 1, Dong-Won Kum 2, Yang Li 2, and You-Ze Cho 2 1 LGDACOM CORPORATION/Research Institute of Technology, Korea 2 School of Electrical Engineering and Computer Science, Kyungpook National University, Korea aries33@lgdacom.net, {8kumsy, liyang, yzcho}@ee.knu.ac.kr Abstract In a network-based approach such as Proxy Mobile IPv6 (PMIPv6), the serving network controls mobility management on behalf of the Mobile Node (MN). Thus, the MN is not required to participate in any mobility-related signaling. PMIPv6 is being standardized in the IETF NetLMM WG. However, the PMIPv6 still suffers from a lengthy handover latency and packet loss during a handover. In this paper, we propose a seamless handover scheme for PMIPv6. The proposed handover scheme uses the Neighbor Discovery message of IPv6 to reduce the handover latency and packet buffering at the Mobile Access Gateway (MAG) to avoid the on-the-fly packet loss during a handover. In addition, it uses an additional packet buffering at the Local Mobility Anchor (LMA) to solve the packet ordering problem. Simulation results demonstrate that the proposed scheme could avoid the on-the-fly packet loss and ensure the packet sequence. Index Terms network-based mobility management, proxy mobile IPv6, seamless handover. I. INTRODUCTION The future broadband wireless networks are quickly evolving towards all-ip networks. With an explosive growth in the number of users that using the Internet in wireless environment, the issue of IP mobility management technology is on the rise. Mobile IPv6 (MIPv6) [1], which is a host-based mobility management protocol, is one of the most representative efforts and proposed by the IETF as the main protocol for mobility management at the IP layer. However, although MIPv6 is a well-known mature standard for IPv6 mobility, it has some well known problems such as handover latency, packet loss and signaling overhead. Also, the MIPv6 requires protocol stack modification of the Mobile Node (MN) to support IP mobility [2][3]. Recently, a network-based mobility management protocol, which is called the Proxy Mobile IPv6 (PMIPv6), is being standardized by the IETF NetLMM WG [4][5]. Unlike the MIPv6, PMIP6 allows the serving network to control the mobility management on behalf of an MN, thereby eliminating the MN from any mobility-related signaling. PMIPv6 is essentially based on MIPv6 in the sense that it extends MIPv6 signaling and reuses many concepts such as functionality of Home Agent (HA). However, PMIPv6 is also designed to provide network-based mobility management support to an MN in a topologically localized domain. Therefore, an MN is exempt from participation in any mobility-related signaling, and a proxy mobility agent in the serving network performs mobility-related signaling on behalf of the MN. However, a network-based mobility management protocols, such as PMIPv6, still suffer from handover latency and packet loss during a handover, like MIPv6. Although several fast handover schemes based on PMIPv6 have already been introduced to reduce the handover latency and packet loss [6]-[8], these schemes still experience some packet loss and packet ordering problem during a handover. Therefore, this paper presents a seamless handover scheme for PMIPv6. We use a Neighbor Discovery (ND) message of IPv6 [9] to reduce the handover latency. Since this scheme sends the MN-profile to the neighbor MAGs through ND message before a handover, it can eliminate the need for the Mobile Access Gateways (MAGs) to acquire the MN-profile from the Policy Server (PS) whenever a MN performs a handover. Also, to avoid the packet loss of on-the-fly packet, which is routed between the Local Mobility Anchor (LMA) and the previous MAG (pmag), the proposed handover scheme uses a packet buffering at the pmag. In addition, this scheme uses an additional packet buffering at the LMA to ensure the packet sequence between the forwarding packets from pmag and the newly arriving packets from the LMA after a handover registration. Simulation results demonstrate that the proposed scheme can avoid the packet loss during a handover. The proposed scheme is also able to ensure the packet sequence through the use of additional packet buffering at the LMA. The remainder of this paper is organized as follows. In Section II, we describe a PMIPv6 protocol and related fast handover schemes for PMIPv6. In Section III, we explain the proposed handover scheme. Simulation results are presented in Section IV. Finally, we make conclusions in Section V. II. RELATED WORKS A. PMIPv6 PMIPv6 is designed to provide a network-based IP mobility management support to an MN in a topologically localized domain, without requiring the participation of the MN in any IP mobility related signaling. The core functional components are used to support mobility in PMIPv6 are the PS, LMA, and MAG. The PS is the entity that manages the MN s authentication and maintains the MN s profile which is a set of parameters configured for a given MN. The LMA is similar to the HA in MIPv6. However, it has additional capabilities required to support PMIPv6. The main role of the LMA is to maintain reachability to the MN s address while the MN 978--7695-3393-3/8 $25. 8 IEEE DOI 1.119/WiMob.8.15 41

moves around within a PMIPv6 domain. The LMA includes a Binding Cache Entry (BCE) for each currently registered MN. The MAG typically runs on the Access Router (AR). The main role of the MAG is to detect the MN s movement and sends mobility-related signaling to the MN s LMA on behalf of the MN. In addition, the MAG establishes a tunnel with the LMA for packet transmission. The MAG ensures that an MN can obtain address from its HNP and move anywhere within the PMIPv6 domain. Therefore, the MN believes it is using the same link obtained with its initial address configuration, even after changing its point of attachment within the network. Fig. 1 shows the signaling flow of the overall operations in PMIPv6; the steps involved in the initial attachment and handover procedure are described as follows: Steps 1, 2, and 3: When a MN initially attaches to MAG-1 in a PMIPv6 domain, the access authentication procedure is performed using an MN-Identifier (MN-ID) via the deployed access security protocols on the access network. After successful access authentication, the MAG-1 obtains the MN s profile, which contains the MN-Identifier, LMA address (LMAA), supported address configuration mode. Steps 4 and 5: To update the LMA about the current location of the MN, MAG-1 sends a Proxy Binding Update (PBU) message to the MN s LMA on behalf of the MN. Upon receiving the PBU message, the LMA assigns a MN-HNP and creates a BCE that binds the MN-HNP to a Proxy-CoA which is the address of MAG-1. The LMA also establishes a bidirectional tunnel to MAG-1. The LMA sends a Proxy Binding Acknowledgement (PBA) message including the MN-HNP. Step 6: Upon receiving the PBA message, MAG-1 sets up a tunnel to the LMA and adds a default route over the tunnel to the LMA. It also creates a (BUL) that binds the MN-HNP and LMAA. The MAG-1 then sends Router Advertisement (RA) messages to the MN on the access Initial Attachment MN MAG-1 DHCP Relay Agent MAG-2 AAA&Policy Server LMA (1) MN Attachment (present MN ID) AAA Query MN-ID (2) with (3) AAA reply with profile (MN-HNP, Proxy-CoA1) (4) PBU (5) PBA disconnect connect Handover Tunnel Setup (6) RA (HNP, default-router address, address configuration parameters) Autoconfig MN-HoA MN_Detach Binding update List removed (9) MN Attachment (present MN ID) MN retains HoA/HNP (14) RA (7) DeReg PBU (lifetime value set to ) (8) PBA Fig.1. Signaling flow of PMIPv6. Start BCE delete timer (1) AAA Query with MN-ID (MN-HNP, Proxy-CoA2) (11) AAA reply with profile (12) PBU (13) PBA Tunnel Setup link to advertise the MN-HNP as the hosted on-link-prefix. When the MN receives these RA messages, the MN configures the IP address using either a stateful or stateless address configuration modes. After successfully completing the address configuration procedure, the MN uses this address for packet delivery. Steps 7 and 8: When the MN moves to the access network of MAG-2, MAG-1 detects that the MN has moved away from its access link. Therefore, MAG-1 sends a DeReg PBU (DeRegistration PBU) message to the LMA with the lifetime value set to zero for de-registration. Upon receiving the PBU message with a zero lifetime value, the LMA sends a PBA message to MAG-1 and waits for a MinDelayBeforeBCE- Delete amount of time, before it deletes the MN s BCE. Steps 9, 1, and 11: When MAG-2 detects the attachment of MN, MAG-2 obtains the MN-profile using an MN-ID after successful access authentication. These steps are same with Steps 1, 2, and 3. Steps 12, 13, and 14: To update the LMA about the current location of the MN, MAG-2 sends a PBU message to the MN s LMA on behalf of the MN. Within MinDelayBeforeBCEDelete wait period, if the LMA then receives a PBU message for the same MN from the MAG-2 with a lifetime value greater than zero, and if that request is accepted, the Binding Cache entry is not deleted, but rather updated with a new value, which is the address of MAG-2 (Proxy-CoA2). Otherwise the LMA deletes the MN s Binding Cache entry and removes the routing state for the MN-HNP. After updating the BCE, the LMA sends a PBA to MAG-2, MAG-2 then sends RA messages to the MN with its MN-HNP. Upon receiving the RA message, the MN believes it is still on the home link. Unlike MIPv6, a tunnel in PMIPv6 is established between the LMA and the MAG, and not the MN. Plus, as the tunnel between the LMA and the MAG is typically a shared tunnel, it can be used for routing traffic streams for different MNs attached to the same MAG. This shared tunnel also reduces the network and signaling overhead. After bidirectional tunnel is successfully set up, all traffic sent from the MN gets routed to its LMA through the tunnel. The LMA forwards the received packet from the CN to the MAG through the tunnel. After receiving the packets, the MAG on the other end of the tunnel removes the outer header and forwards the packets to the MN. B. Fast Handover Schemes for PMIPv6 When an MN moves to a new access network in a PMIPv6 domain, it inevitably experiences the packet loss or handover latency until it receives its MN-HNP advertisement from the newly attached MAG. Therefore, several fast handover mechanisms have recently been introduced to reduce the handover latency and packet loss with PMIPv6 [6]-[8]. In [6], Lee et al. suggested adapting IAPP (Inter-AP Protocol) to reduce the access 411

authentication/obtaining MN s profile time of the total handover delay. Nonetheless, the on-the-fly packets will still be lost during a handover. In [7], Xia et al. used FMIPv6 signaling to improve the performance of the Layer 3 handover. Before an MN moves from the serving base station to the target base station, the MN provides the target base station information (t-bs ID) during the L2 handover signaling procedure. The MN then acquires the IP address of the target MAG from a tuple incorporated in all the MAGs and performs the L3 handover based on this information. However, this scheme also has some limitations: i) Each MAG needs to have a tuple that contains the BS-IDs and IP addresses for all the MAGs in the PMIPv6 domain. ii) After a handover, a packet ordering problem occurs between the packets buffered at the pmag and the packets from the LMA after registration. iii) The MN should provide information about the target network to pmag through L2 signaling. In [8], Park et al. proposed Fast and Local Proxy MIPv6 (FLPMIPv6) to reduce the handover latency and packet loss. This scheme is based on FMIPv6 and uses the messages defined in IEEE 82.21. The MN provides information on the target MAG using a MIH message before the handover. The current MAG then sends a handover-related message to the new MAG. However, since this scheme is derived from hostbased mobility and initiated by mobile nodes, the network access devices need L2 intelligence. In addition, since the current MAG sends a BU message to the LMA before the L2 handover occurs, this means the L3 handover is performed before the L2 handover. Therefore, significant packet losses occur from the time the L3 handover is completed until the end of the L2 handover. III. THE PROPOSED SEAMLESS HANDOVER SCHEME Handover latency is mainly caused by the authentication procedure and reconfiguration of the default router when the MN access to a new access network, as shown in Steps 1, 11, and 14 in Fig. 1. Therefore, we use a ND message of IPv6 in order to reduce the handover latency. When the previous MAG receives the Link Going Down (LGD) trigger, the MAG sends the MN-profile to neighbor MAGs through ND message of IPv6. In addition, the proposed handover scheme uses a packet buffering to avoid the on-the-fly packet loss as that in Xia s FMIPv6 [7]. Although, the packet buffering at the pmag can avoid the on-the-fly packet loss, the MN can still experience a packet ordering problem. The reason is that the packets from the LMA after new registration may arrive at MN before the buffered on-the-fly packets forwarded by the pmag. To solve the packet ordering problem, we use an additional packet buffering at the LMA. Fig. 2 shows the signaling flow of the proposed handover scheme for PMIPv6. Each step shown in Fig.2 is described as follows: MN MAG-1 MAG-2 MAG-3 disconnect connect LGD triggering (1) Neighbor Discovery buffering (MN_HNP, MN_ID, LMAA) MN detach Binding update List removed (a) Deliver packets (b) Deliver packets (4) HN (5)RA Forward packets (2) DeReg PBU (lifetime value = ) (3) PBA MN attach (6) PBU (7) PBA Forward packets Start BCE delete timer (MN-HNP, Proxy-CoA2) Fig. 2. Signaling flow of the proposed handover scheme. Step 1: When MAG-1 receives a LGD trigger, it sends the MN-profile to its neighbor MAGs using the ND message from IPv6. This ND message contains the MN-profile, including the MN-HNP, MN-ID, and LMAA. This eliminates the need for the MAGs to acquire the MN-profile from the policy server whenever an MN performs a handover. MAG-1 then starts buffering the packets for the MN in order to avoid the on-the-fly packet loss. Steps 2 and 3: When MAG-1 detects the detachment of the MN, it sends a DeReg PBU message to the LMA with a lifetime value of zero. Upon receiving the DeReg PBU, the LMA sets the BCE delete timer and starts buffering to ensure the packet sequence between the forwarding packets from pmag and the newly arriving packets from the LMA after a handover registration. The LMA then sends a PBA message to MAG-1. Steps 4 and 5: When MAG-2 detects the attachment of the MN on its access link, it sends a Handover Notification (HN) message to MAG-1. A new HN message is also proposed to confirm the fact that the MN is attached to the new MAG (e.g. MAG-2). Upon receiving the HN message, MAG-1 forwards the buffered packets to MAG-2 and MAG-2 forwards these packets to the MN (Step (a) in Fig. 2). Therefore, the packet buffering at MAG-1 can avoid the on-the-fly packet loss. Upon detecting the attachment of the MN on its access link, MAG-2 sends RA message with the same MN-HNP to the MN. Upon receiving the RA message, the MN reconfigures its default router. Steps 6 and 7: After MAG-2 forwards the packets to the MN, it sends a PBU message to the LMA to update the BCE and establishes a tunnel with the LMA. The LMA responds to MAG-2 with a PBA message. The packets buffered at the LMA after the LMA receives the DeReg PBU message from MAG-1 are then forwarded to the MN (Step (b) in Fig. 2) through the tunnel between the LMA and MAG-2. The advantages of the proposed handover scheme are as follows: i) This handover scheme reduces the handover latency by sending the MN-profile using a ND message of LMA buffering 412

IPv6 at the beginning of handover. Thereby, it can eliminate the need for the MAGs to acquire the MN-profile from the policy server whenever a MN performs a handover. In addition, the MN can receive a RA with its home network prefix as soon as it is attached to the new access link, thereby circumventing authentication and reducing the default router reconfiguration delay. ii) The proposed handover scheme uses a packet buffering to avoid the on-the-fly packet loss during a handover. iii) the proposed scheme ensures the packet sequence during a handover by using an additional packet buffering at the LMA. iiii) In the proposed scheme, the MN is not required to provide any information about the target network to the pmag, like [7]. However, the proposed handover scheme has some overheads. i) Each MAG needs to maintain a database including its attached MN information, such as MN_HNP, MN_IP and LMAA. This information also needs to be advertised to its neighbor MAGs through ND messages. ii) Also, sending ND messages to the neighbor MAGs causes additional traffic. iii) The packet buffering at the MAG and the LMA incurs an overhead. Nonetheless, the proposed scheme can reduce the handover latency, and avoid the onthe-fly packet loss while ensuring the packet sequence. IV. PERFORMANCE EVALUATION In this section we evaluate the performance of the proposed handover scheme using a NS-2 simulator [1]. We compare our proposed FPMIPv6 with PMIPv6 [5], and Xia s FMIPv6 [7]. In this simulation, IEEE 82.11b is used as MAC protocol for the MAGs, which has a 25 m transmission range and 2 Mbps link bandwidth. To create overlapping coverage, a 4m distance is used between the MAGs. Plus, a constant bit rate (CBR) application with.1 second intervals and FTP application using TCP Reno is considered. In the simulation, the MN starts from MAG-1 and moves to MAG-2 and MAG- 3 with a velocity of 1m/s and 3m/s, respectively. Fig. 3 shows the network topology for simulation. 1ms/Mbps Router LMA 1ms/1Mbps MAG-1 MAG-2 MAG-3 CN 1ms/1Mbps ms/mbps Internet PMIPv6 domain Fig. 3. Network topology for simulation. 1ms/Mbps Policy Server 5 4 3 & Xia's FPMIPv6 1 2 3 4 5 6 7 8 9 5 4 3 (a) Velocity of MN = 1m/s & Xia's FPMIPv6 5 1 15 2 25 3 35 4 (b) Velocity of MN = 3m/s Fig. 4. UDP throughput of MN. Fig. 4 compares the UDP throughput between the proposed FPMIPv6, original PMIPv6, and handover schemes when the velocity of the MN is 1m/s and 3m/s, respectively. These graphs show that the original PMIPv6 has the on-the-fly packet loss during a handover. On the other hand, the proposed handover scheme and the can avoid the on-the-fly packet loss, because they use packet buffering at the pmag. Fig. 5 shows a comparison of the TCP throughput between the proposed FPMIPv6, original PMIPv6, and handover schemes when the velocity of the MN is 1m/s and 3m/s, respectively. The throughput of original PMIPv6 reduces during a handover due to TCP retransmissions caused by the on-the-fly packet loss. Furthermore, even though Xia s FPMIPv6 uses packet buffering at the pmag to avoid the onthe-fly packet loss, like our proposed scheme, it still experiences a TCP throughput decrease during a handover. Since can not ensure the packet sequence between forwarded packets from the pmag and newly arriving packets from the LMA after a handover registration. This causes the packet retransmissions of TCP, resulting in throughput degradation. 413

The throughput of the proposed FPMIPv6 outperforms those of the PMIPv6, and the during a handover, because it uses packet buffering at the pmag to avoid the on-the-fly packet loss and can ensures the packet sequence by using an additional packet buffering at the LMA. 9 8 7 6 5 4 3 1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 (a) Velocity of MN = 1m/s 5 1 15 2 25 3 35 4 (b) Velocity of MN = 3m/s Fig. 5. TCP throughput of MN. proposed FPMIPv6, original PMIPv6, and at 3m/s velocity of the MN. The sequence number of original PMIPv6 and does not increase during the handover due to the same reason as in Fig. 5. In contrast, with the proposed scheme, the sequence number continually increases, due to avoiding the on-the-fly packet loss while ensuring the packet sequence. Therefore, the TCP throughput of the proposed FPMIPv6 outperforms those of the original PMIPv6 and the. V. CONCLUSION In a network-based mobility management scheme such as PMIPv6, the serving network handles the mobility management in a topologically localized domain on behalf of a MN. However, the PMIPv6 still has a packet loss during a handover. Therefore, this paper presented a seamless handover scheme for PMIPv6 to reduce the handover latency and packet loss. The proposed handover scheme uses the ND message of IPv6 to reduce the handover latency, and packet buffering at MAG to avoid the on-the-fly packet loss during a handover. Plus, this scheme uses an additional packet buffering at the LMA to ensure the packet sequence. Simulation results demonstrated that the proposed handover scheme could avoid the on-the-fly packet loss while ensuring the packet sequence. Plus, the TCP throughput of the proposed scheme outperformed those of PMIPv6 and Xia s FPMIPv6 during a handover. ACKNOWLEDGMENT This work was partly supported by the IT R&D program [8-F-15-1, Research on Ubiquitous Mobility Management Methods for Higher Service Availability] and the ITRC (IT Research Center) program [IITA-8-(C19-81- 36)] of MKE/IITA. Sequence Number 13 125 1 115 1 15 95 9 85 12 12.5 13 13.5 14 14.5 15 15.5 16 Fig. 6. TCP sequence number of MN (Velocity of MN = 3m/s). Fig. 6 compares the TCP sequence number between the REFERENCES [1] D. Johnson, C. Perkins, and J. Arkko, Mobility Support in IPv6, IETF RFC 3775, Jun 4. [2] N. Banerjee, W. Wu, and S. K. Das, Mobility Support in Wireless Internet, IEEE Wireless Commun., vol. 1, no. 5, pp. 54-61, Oct. 3. [3] J. Kempf, Problem Statement for Network-Based Localized Mobility Management (NETLMM), IETF RFC483, Apr. 7. [4] http://www.ietf.org/html.charters/netlmm-charter.html. [5] S. Gundavelli, et al., Proxy Mobile IPv6, Internet-Draft, draft-ietfnetlmm-proxymip6-5.txt, Sept. 7. [6] J-C. Lee and D. Kaspar. PMIPv6 Fast Handover for PMIPv6 Based on 82.11 Networks, Internet-Draft, draft-lee-netlmm-fmip-.txt, July 7. [7] F. Xia, and B. Sarikaya, Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6, Internet-Draft, draft-xia-netlmm-fmip-mnagno- 1.txt, July 7. [8] Sihun Park, Jennifer E. L., Jaeyeon C., and Younghan K., Fast Localized Proxy Mobile IPv6 (FLPMIPv6), Internet-Draft, draft-parknetlmm-fastpmip-.txt, Feb. 7. [9] T. Narten, E. Nordmark, and W. Simpson, Neighbor Discovery for IP version 6 (IPv6), IETF RFC 2461, July 5. [1] Network simulator 2. [Online]. Available: http://www.isi. edu/nsnam/ns. 414