Int. J. Ad Hoc and Ubiquitous Computing, Vol.
A network-based global mobility management architecture Huachun Zhou*, Hongbin Luo and Hongke Zhang School of Electronic and Information Engineering, Beijing Jiaotong University, Beijing 100044, PR China E-mail:
[email protected] E-mail:
[email protected] E-mail:
[email protected] *Corresponding author
Chi-Hsiang Lo Institute of Computer Science and Information Engineering and Department of Electronic Engineering, National Ilan University, I-Lan, Taiwan E-mail:
[email protected]
Han-Chieh Chao Institute of Computer Science and Information Engineering and Department of Electronic Engineering, National Ilan University, I-Lan, Taiwan Department of Electrical Engineering, National Dong Hwa University, Hualien, Taiwan E-mail:
[email protected] Abstract: This paper specifies a network-based global mobility management architecture, named NetGMM. NetGMM supports network-based mobility management and non-Mobile IP mobile environment. There are two design considerations. The first is that a future mobile network requires network-based mobility management, shifting the mobility management function from Mobile Nodes (MN) to Access Network (AN) nodes. The second is that future mobile networks will support IP multi-services, introducing a separation between network address and identity of a mobile node entity, allowing heterogeneous networks to work together without loss of functionality. Keywords: mobility; network-based; HI; host identity; handoff. Reference to this paper should be made as follows: Zhou, H., Luo, H., Zhang, H., Lo, C-H. and Chao, H-C. (2010) ‘A network-based global mobility management architecture’, Int. J. Ad Hoc and Ubiquitous Computing, Vol. Biographical notes: Huachun Zhou received his BS Degree from People’s Police Officer University of China in 1986. He received his MSE and PhD Degrees from Northern Jiaotong University and Beijing Jiaotong University, in 1989 and 2009, respectively. His research interests include computer network and network management technologies. Hongbin Luo received his MS and PhD Degrees (with honour) from the University of Electronic Science and Technology of China, in June 2004 and March 2007, respectively. He is the first author of more than 30 technical papers published on prestigious international journals including IEEE/ACM Transaction on Networking (IEEE/ACM ToN), IEEE Journal on Selected Areas in Communications (IEEE JSAC). His current research interests lie in the broad areas of wireless and wire-line networks. Hongke Zhang is Dean of School of Electronic and Information Engineering, Beijing JiaoTong University. He is the commissioner of Supervising Committee of College and University Teaching in the field of telecommunication, too. From 2000 to 2006, he has published 16 patents, four IETF-drafts, and more than 100 papers. Chi-Hsiang Lo received the BEd Degree in industrial education (majoring in electronic engineering) from the National Taiwan Normal University, Taipei, Taiwan in 1975, and the
Copyright © 2010 Inderscience Enterprises Ltd.
2
H. Zhou et al. MS and PhD Degrees in Computer Science from the Texas A&M University, Commerce, TX, and Kent State University, OH, USA, in 1992 and 2003. Since August 1975 he has been with National Ilan University and he is currently an Associate Professor of Electronic Engineering and the secretary general. His research interests are image processing, medical imaging, algorithm analysis and logical design. Han-Chieh Chao is a jointly appointed Professor of the Department of Electronic Engineering and Institute of Computer Science and Information Engineering, National Ilan University, I-Lan, Taiwan. He also holds a joint Professorship of the Department of Electrical Engineering, National Dong Hwa University, Hualien, Taiwan. His research interests include high speed networks, wireless networks and IPv6 based networks and applications. He received his MS and PhD Degrees in Electrical Engineering from Purdue University in 1989 and 1993 respectively. He is also serving as the Director of Computer Center, Ministry of Education Taiwan, Deputy Director of R&D division of the NICI Taiwan, Dean of National Ilan University. He is an IEEE senior member, IET and BCS fellows.
1
Introduction
Mobile IPv6 (RFC 3775) and Mobile IPv4 (RFC 3344) enable Mobile Node to maintain its connectivity to the internet during handover. However, all mobile IP protocols mentioned are mobile node centric, that is, the handover related decision making is mostly done in the mobile node only. Recently, IETF proposed Network-based Localised Mobility Management (NETLMM) (Kempf et al., 2006) protocol. The NETLMM problem is restricted to providing IP connectivity and reachability for Mobile Nodes (MN) within an Access Network (AN). A NETLMM scheme requires no localised mobility management support on the mobile node and is independent of global mobility management protocol. The result is that the host does not have to change its IP address within a restricted AN. However, MNs require global mobility management protocols to support global mobility when moving between different NETLMM ANs (Njedjou and Riera, 2006). Several related drafts have designed the NETLMM protocols. An IP layer interface between MN and Access Routers (AR) of a NETLMM domain is specified in Laganier and Narayanan (2006) Templin et al. (2006). By utilising network-based mobility support for a dual stack MN, proposed in Jeong et al. (2006). Future mobile networks will be compounded by multi-access capable terminals equipped with IP technologies, and of operator-provided multi-technology mobile connection software. So, it is required to specify an architecture that can across hybrid wireless networks (Siddiqui and Zeadally, 2006). Several related research papers have investigated new approaches to solve this problem. The first approach uses existing mobile IP protocols. Architecture for Ubiquitous Mobile Communications (AMC) is proposed in Akyildiz et al. (2005). Pure-IP Moby Dick 4G architecture has also been proposed in Jähnert et al. (2005). The second approach extends the internet architecture by introducing a separation between network address and identity of a host entity. Ambient Networks has developed a framework for naming, addressing and identity mechanisms that enable dynamic bindings for supporting connectivity across heterogeneous network domains (Ahlgren et al., 2005). Further,
the node-identity-based internet-working architecture is proposed in Ahlgren et al. (2006). The Mobility Management Framework (MMF) (ITU-T Draft New Recommendation Q.MMF, 2006) describes an IP-based MM framework, some design considerations such as separation of user Identifier and location Identifier, and MM information flows, including location and handover management. This paper specifies a network-based global mobility management architecture, named NetGMM. NetGMM supports network-based mobility management and a non-Mobile IP mobile environment. The rest of this paper is organised as follows: Section 2 presents the proposed NetGMM architecture. Sections 3 and 4 describe NetGMM location management and handover management, respectively. Finally, we conclude this paper in Section 5.
2
The proposed architecture
The proposed NetGMM architecture is shown in Figure 1. In the NetGMM administration domain, NetGMM ANs are inter-connected by Core Routers (CRs). There exists a global location database server, named HDB. HDB is used to store up-to-date location information and control the location management for all the MNs. Figure 1
NetGMM architecture (see online version for colours)
In a NetGMM Access Network (AN), there exists a Dynamic Host Configuration Protocol (DHCP) server, an Authentication, Authorisation and Accounting (AAA) server, a Visitor Location Database (VDB) server, and a set of Global Mobility Anchor Points (GMAPs). The VDB server is used to store current location information for
A network-based global mobility management architecture all MNs in the NetGMM access network. HDB and all VDB servers constitute a distributed location database. A NetGMM access network has some links served by a set of GMAPs and their associated ARs and MNs that provision addresses from the same IP subnet prefix (es). GMAPs function as access network aggregation routers or gateways and handle packet exchanges, with nodes in the access network. It also handles the NetGMM access network movement events of the mobile node. On behalf of the mobile node, GMAP itself manages its global mobility. The Access Router in an AN handles the movement events of the mobile node, registers the association of the mobile node with its point of attachment to a GMAP and provides routing services to MN. When the AR receives a packet encapsulating the original packet sent from the Correspondent Node (CN), it looks up the appropriate forwarding/routing table depending on the protocol version of the original packet. NetGMM supports network-based mobility management. In NetGMM, MNs are equipped with IP stack, but do not have any mobility management protocol stack. On NetGMM access networks, MNs can send DHCP requests via ARs to GMAPs to configure IP addresses MNIP and establish routes in AR/GMAP IP forwarding/routing table. Moreover, Network-based mobility management mechanisms allow MNs to retain their IP addresses unchangeable even if they change ARs within the NetGMM access network. To constrain the allocation of addresses to authorised MNs, the DHCP server will contact the AAA server to perform the necessary authentication and authorisation for the MN. NetGMM supports a non-Mobile IP mobile environment. In NetGMM, each MN has an identifier, named MNID. The MNID could be the Home address in a mobile IP, Host Identity (HI) in a HIP, Network Access Identifier (NAI), and MAC address of the mobile node’s interface, etc. The MNID may be a permanent identifier and is given by the home service provider. In NetGMM, each MN in a NetGMM access network has an unchangeable routable IP address, named MNIP. The routable IP address is assigned by AN. Through location management, MNID can be translated into MNIP and vice versa. When MN moves into another NetGMM access network, the MNIP is changed. As shown in the Figure 1, local mobility occurs when the MN moves between two different ARs in a NetGMM access network. The mapping between a mobile node’s MNID and its NetGMM access network address MNIP is stored and managed in the NetGMM access network visitor location database VDB and core network global location database HDB. Global mobility occurs when MN moves between two ANs. For local mobility, the location information stored in HDB need not be updated. HDB and VDBs perform location management for each MN, together. NetGMM provides location management. NetGMM will keep track of MN’s current location and save it in a distributed location database. The communication CNs can look up MN’s current location and establish a link.
3
NetGMM supports handover management. The handover management will provide the seamless mobility for the MNs moving between different NetGMM ANs.
3
Location management
3.1 IP address assignment When MN enters a new AN, it must first get its current MNIP, which is a routable IP address. A MN discovers ARs via standard IP router discovery. The MN then sends a DHCP request that is relayed to the GMAP by one or more ARs. The GMAP relays the DHCP request to the AN DHCP server. The DHCP server assigns an IP address from the same IP sub-net prefix(es) for the MN, performs necessary Duplicate Address Detection (DAD) and contacts with AAA server to perform authentication and authorisation for the MN. Then DHCP server informs a DHCP replay to the GMAP. The GMAP creates a route/tunnel to the address via an AR. The GMAP then sends a DHCP reply to the MN via this AR, and the AR creates a route to the address and then relays the reply to the MN. The MN now is assigned a unique IP address and knows that the GMAP and AR have established the correct route/tunnel state. The IP address assignment procedure is given in Figure 2. Figure 2
IP address assignment procedure (see online version for colours)
A detailed specification of the message exchange between MN and AR is also given in Laganier and Narayanan (2006), Templin et al. (2006). However, in NetGMM, the main operation is accomplished by using GMAP, rather than AR.
3.2 Location registration When the GMAP receives a DHCP Reply message, it registers the MNID and MNIP with the access network VDB by sending the Location Registration (Loc-Reg) message. Based on the Loc-Reg message received from the GMAP, the VDB will add a new entry of the mapping table that contains the mapping relationship between MNID and MNIP. The VDB will then forward the Loc-Reg message to the core network HDB. The Loc-Reg message sent by VDB to the HDB must contain the MNID and MNIP. When the HDB receives the Loc-Reg message from the VDB, it will add or update the associated entry in the mapping table for the MN. On the successful update of the mapping table, the HDB will respond with the Location Registration Acknowledgement (Loc-Reg-Ack) message to the VDB. The Loc-Reg-Ack message sent by HDB to VDB
4
H. Zhou et al.
must contain Information on whether the Loc-Reg request is accepted or not. In turn, the VDB will respond to the GMAP with the Loc-Reg-Ack message, which must contain the information on whether the Loc-Reg is accepted or not.
3.3 Location Query and reply When the CN wants to communicate with the MN, the CN will first query current location (MNIP) of the MN from the VDB that it currently belongs to. The CN sends a modified Router Solicitation (RS) message, including the Location Query (Loc-Query) message to GMAP. GMAP relays the message to the VDB. If the MN and CN are in the same AN, the VDB will respond with the Location Query Acknowledgement (Loc-Query-Ack) message to the GMAP. The GMAP will send a Link Setup message (link-Setup), including CN’s MNIP and CN’s MNID to the MN’s AR. The MN’s AR will replay a modified RA message including Link-Setup message to the MN. After getting the MNIP of the MN from the GMAP, the CN will begin the link establishment and the data transport process with the MN. If the CN is in a foreign AN, the foreign VDB will relay Loc-Query message to the HDB. The HDB will inform Loc-Query-Ack message to the foreign VDB. The foreign VDB will relay this message to the foreign GMAP. The foreign GMAP will respond with the Loc-Query-Ack message to the CN. The foreign GMAP also send a link-Setup including CN’s MNIP and CN’s MNID to the MN’s GMAP. The MN’s GMAP will relay the link-Setup message to the MN’s AR. The MN’s AR will replay a modified Router Advertisement (RA) message including Link-Setup message to the MN. After getting the MNIP of the MN, the CN will begin the link establishment and the data transport process with the MN.
3.4 Location Update and de-registration When MN continues to move into a foreign AN and, thus, changes its MNIP, the foreign GMAP must send a Location Update (Loc-Update) message to the foreign VDB to update location information. The foreign VDB will forward the message to the HDB. The HDB sends a Location Update Acknowledgement (Loc-Update-Ack) message to the foreign VDB. The foreign VDB will relay this message to the foreign GMAP. If the MN has a link with a CN, the HDB also sends this message to CN’s VDB. The CN’s VDB will relay this message to CN’s GMAP. Then CN’s GMAP will inform CN that the MN’s New MNIP. The foreign GMAP will also send a Loc-Update-Ack message to the MN’s old GMAP. The old GMAP will forward the MN’s packets to foreign GMAP. Then the old GMAP will perform a location De-registration procedure for the MN. When the MN terminates the connection with the network, the GMAP can de-register its location with the VDB by sending a Loc-De-Reg message. The VDB will
forward Loc-De-Reg message to the HDB for the MN. With the Loc-De-Reg, the HDB may respond with the Loc-Update-Ack messages to the VDB. The VDB may also respond with the Loc-Update-Ack message to the GMAP. Figure 3 gives the NetGMM location management message flows. It is noted that the key difference between NetGMM and Q.MMF (ITU-T Draft New Recommendation Q.MMF, 2006) location management is that NetGMM is a network-based mobility management protocol and the main operation for location management is accomplished by using GMAP, not a mobile node. Figure 3
4
Location management message flows (see online version for colours)
Handover management
4.1 MN moves in a NetGMM access network When MN moves into a sub-network within the same NetGMM access network, there will be a local handover. An example is when the MN moves from AR1 to AR2. The MN will execute some movement detection procedure and send a RS message to AR2. Since the AR2 has no state information about the MN, it sends a Loc-Query message to GMAP1 for information about the MN. The GMAP1 sends a Loc-Query-Ack message to the AR2 about the MN’s state information (e.g., MNIP, and so on), so the AR2 can configure its forwarding/routing table such that traffic to the MN’s MNIP will reach the MN through AR2. The GMAP1 also informs the old AR (AR1) so that it can clean up the state about the MN. The AR2 updates its forwarding state and sends a RA message in order to confirm MN’s MNIP. Figure 4 describes the handover procedures when MN moves from AR1 to AR2. Figure 4
Handover procedures in a NetGMM access network (see online version for colours)
A network-based global mobility management architecture When GMAP1 receives a packet destined for the MN’s MNIP, the GMAP1 knows that the MN has moved to AR2 by looking up its forwarding state. The GMAP1 tunnels the received packet to AR2. After receiving the packet sent from GMAP1, AR2 recovers the original packet which is sent from the CN. AR2 looks up its forwarding/routing table. When the destination address of the original packet is found in the forwarding/routing table, AR2 builds an L2 frame by using MNID and transmits it to the MN.
4.2 MN moving into a new NetGMM access network When the MN moves into a new NetGMM access network, there is a global handover. An example is when the MN moves from AR2 to AR3. The MN will execute some movement detection procedure and send a RS message to AR3. The MN will perform an IP address assignment procedure given in Section 3.1. After that, the GMAP2 sends a Loc-Update message to VDB2 for information about the MN. The location update procedure is given in Section 3.4. So the GMAP2 can configure its forwarding/routing table such that traffic to the MN’s new MNIP will reach the MN through AR3. The GMAP1 also informs the old AR (AR2) so that it can clean up the state about the MN. The GMAP2 sends a Loc-Update-Ack message to the AR3 the MN’s state information. Then, the AR3 updates its forwarding state and sends a RA message to the MN. Figure 5 shows handover procedures when the MN moves from GMAP1 to GMAP2. Figure 5
Handover procedures between NetGMM access networks (see online version for colours)
When GMAP1 receives a packet destined for the MN’s MNIP, the GMAP1 knows that the MN has moved to another AN by looking up its forwarding state. The GMAP1 encapsulates the received packet and delivers it to a GMAP2. The source and destination address in the outer IP header are the addresses of GMAP1 and GMAP2, respectively. The GMAP2 removes the outer IP header of the received packet and encapsulates the original packet. The GMAP2 looks up its state information and sets the source address in the outer IP header to GMAP2’s address and the destination to the address of AR3 which the MN is connected to. After that, GMAP2 sends the encapsulated packet to the AR3. After receiving the packet sent from GMAP2, AR3 recovers the original packet which is sent from the CN. AR3 looks up its IP forwarding/routing table. When the destination address of the original packet is found in the IP forwarding/routing table, AR3 builds an L2 frame by using MNID and transmits it to the MN.
5
It is noted that the key difference between NetGMM and utilising network-based mobility support for the dual stack MN proposed in Jeong et al. (2006) is that NetGMM supports the non-Mobile IP mobile environment and centralised location management.
5
Conclusions
This paper specifies a network-based global mobility management architecture, named NetGMM. NetGMM has the following characteristic features. NetGMM is an IP-based mobility management architecture. NetGMM supports network-based mobility management. In a NETGMM access network, the mobile node does not have to change its IP address. NetGMM supports a non-Mobile IP mobile environment. In NetGMM, the names of entities are location independent. NetGMM also provides distributed location management and seamless handover management.
Acknowledgements This work is supported by the National Natural Science Foundation of China (No. 60573001, 60870015).
References Ahlgren, B., Arkko, J., Eggert, L. and Rajahalme, J. (2006) ‘A node identity internetworking architecture’, Proceedings of the 9th IEEE Global Internet Symposium, April, Barcelona, Spain, pp.28–29. Ahlgren, B., Eggert, L., Ohlman, B., Rajahalme, J. and Schieder, A. (2005) ‘Names, addresses and identities in ambient networks’, First International ACM Workshop on Dynamic Interconnection of Networks (DIN’05), September, Cologne, Germany. Akyildiz, I.F., Mohanty, S. and Xie, J. (2005) ‘A ubiquitous mobile communication architecture for next-generation heterogeneous wireless systems’, IEEE Communications Magazine, Vol. 43, No. 6, June, pp.S29–S36. ITU-T Draft New Recommendation Q.MMF (2006) Generic Framework of Mobility Management for Next-Generation Networks (version 1.1), July. Jähnert, J., Zhou, J., Aguiar, R.L., Marques, V., Wetterwald, M., Melin, E., Moreno, J.I., Cuevas, A., Liebsch, M., Schmitz, R., Pacyna, P., Melia, T., Kurtansky, P., Hasan, Singh, D., Zander, S., Einsiedler, H.J. and Stiller. B. (2005) ‘The ‘pure-IP’ Moby Dick 4G architecture’, Computer Communications, Vol. 28, No. 9, 2 June, pp.1014–1027. Jeong, S., Han, Y-H. and Kim, H-J. (2006) Network-based Mobility Support for Dual Stack Nodes, draft-jeong-netlmmdual-stack-moving-00, June. Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G. and Liebsch, M. (2006) Problem Statement for IP Local Mobility, Internet-Draft, draft-ietf-netlmm-nohost-ps-04, June. Laganier, J. and Narayanan, S. (2006) Network-based Localized Mobility Management Interface between Mobile Node and Access Router, draft-ietf-netlmm-mn-ar-if-01, June.
6
H. Zhou et al.
Njedjou, E. and Riera, J. (2006) Problem Statement for Global IP Mobility Management, draft-njedjou-netlmm-globalmm-ps01, May. Siddiqui, F. and Zeadally, S. (2006) ‘Mobility management across hybrid wireless networks: trends and challenges’, Computer Communications, Vol. 29, No. 9, 31 May, pp.1363–1385.
Templin, F., Russert, S., Chakeres, I. and Yi, S. (2006) Network Localized Mobility Management using DHCP, draft-templin-autoconf-netlmm-dhcp-02, June.
