A Proxy Mobile IPv6 Based Global Mobility Management Architecture ...

Mobile Netw Appl DOI 10.1007/s11036-009-0185-2

A Proxy Mobile IPv6 Based Global Mobility Management Architecture and Protocol Huachun Zhou & Hongke Zhang & Yajuan Qin & Hwang-Cheng Wang & Han-Chieh Chao

# Springer Science + Business Media, LLC 2009

Abstract This paper specifies a global mobility management architecture and protocol procedure called GPMIP, which is based on Proxy Mobile IPv6. In GPMIP, mobility management is performed by the network entity rather than individual mobile nodes. The benefit is the elimination of the wireless link data delivery tunnel overhead between a mobile node and the access router. To compare with the well known Hierarchical Mobile IPv6 mobility management protocol, the location update, packet delivery, and total cost functions generated by a mobile node during its average domain residence time are formulated for each protocol based on fluid flow mobility model. Then, the impacts of various system parameters on the cost functions are analyzed. The analytical results indicate that the proposed global mobility management protocol can guarantee lower total costs. Furthermore, a qualitative comparison between GPMIP and some other global management protocols is also investigated.

H. Zhou : H. Zhang : Y. Qin : H.-C. Chao School of Electronic and Information Engineering, Beijing Jiaotong University, Beijing 100044, China H. Zhou e-mail: [email protected] H. Zhang e-mail: [email protected] Y. Qin e-mail: [email protected] H. Zhou : H. Zhang : Y. Qin : H.-C. Wang : H.-C. Chao (*) Department of Electronic Engineering, National Ilan University, I-Lan, Taiwan e-mail: [email protected] H.-C. Wang e-mail: [email protected]

Keywords global mobility management . proxy mobile IPv6 . hierarchical mobile IPv6 . fluid flow mobility model . cost function

1 Introduction Mobile IPv6 (MIPv6) [1] enables a mobile node (MN) to maintain its connectivity to the Internet during handover. In order to reduce the amount of signaling between the mobile node, its correspondent nodes and its home agent, the Hierarchical Mobile IPv6 Mobility Management (HMIPv6) [2] protocol was established. HMIPv6 is an extension of Mobile IPv6 and IPv6 neighbor discovery to allow for local mobility handling. However, mobile IP protocols are mobile node-centric in that the handover related decision making is mostly performed by the mobile node. Recently, IETF proposed the Network-based Localized Mobility Management (NETLMM) [3, 4] protocol, which requires no localized mobility management support on the mobile node. Instead, the network is responsible for managing IP mobility on behalf of the mobile node. In previous NETLMM discussions, HMIPv6 was presented as a candidate solution but was ruled out because of host involvement. Proxy Mobile IPv6 (PMIPv6) [5] enables IP mobility for mobile nodes without inducing any mobilityrelated signaling. The PMIPv6 protocol was finally adopted by NETLMM since standards development organizations have identified requirements needed to support PMIPv6 solution. Note that although PMIPv6 was derived from MIPv6, it is different from HMIPv6. One limitation of PMIPv6 is that it is restricted to providing IP connectivity and reachability for mobile nodes within an access network. On the other hand, mobile nodes require global mobility management protocols in order to

Mobile Netw Appl

support global mobility across different NETLMM access networks [6]. To the best of our knowledge, no study has been conducted in the area of PMIPv6-based global mobility management schemes. In this paper, PMIPv6 is extended and the design of a PMIPv6-based global mobility management architecture and protocol support is described. The resulting scheme is called GPMIP. One distinguishing feature of GPMIP is that the mobility management is actually performed by the network entity instead of mobile nodes. Another feature is the separation of network address and identity of the mobile node. To assess the efficiency of the proposed scheme, the location update and packet delivery costs are compared against the well-known HMIPv6. The remainder of the paper is organized as follows. Section 2 gives the design motivations and provides an overview of related work. Section 3 describes the GPMIP, including the mobility management architecture and protocol. HMIPv6-based global mobility management architecture and protocol are described in section 4. In section 5, the analytical network and user mobility models are described, followed by the derivation of location update, packet delivery and total cost functions for GPMIP and HMIPv6-based method. Subsequently, the numeric results of cost comparison are analyzed in section 6. Section 7 gives a qualitative comparison between GPMIP and other global management protocols. Finally, in section 8, conclusion is drawn.

2 Design motivations and related work 2.1 Design motivations This paper specifies a PMIPv6-based global mobility management architecture and protocol. There are two design considerations. The first is that future mobile network requires network-based mobility management, shifting the mobility management function from mobile nodes to access network by using existing mobile IP protocols [7]. Recent developments in network architectures in standards development organizations, such as WiMAX Forum [8] and 3GPP [9] have identified a need to support proxy mobile solution. The WiMAX network architecture [8] currently supports proxy mobile IPv4 for enabling mobility for mobile nodes that may not have a mobile IPv4 client. PMIPv6 is a solution that is aligned with the architectural direction of WiMAX. In 3GPP, there has been some degree of interest in PMIPv6 as well, primarily in the SAE (System Architecture Evolution) [9] work item. The possible solution is the use of a hierarchical mobility concept including a global mobility protocol and a local mobility protocol. This paper extends PMIPv6 to support global mobility management.

The second consideration is that future mobile network will introduce the separation between network address and identity of a mobile node entity. Ambient Networks have developed a framework of naming, addressing and identity mechanisms that enable dynamic bindings for supporting connectivity across heterogeneous network domains [10]. Furthermore, node-identity-based internetworking architecture is proposed in paper [11]. The Mobility Management framework [12] describes an IP-based Mobility Management framework. Some design considerations include separation of user identifier and location identifier, and location and handover management information flows. Recently, many architectural discussions show that the split of address and identity of a mobile node entity may help issues such as routing scalability, mobility, and identity authentication in the Internet architecture [13, 14]. In a PMIPv6 access network, the mobile node has a stable identifier. After the mobility management entities in a PMIPv6 access network identify the mobile node and acquire the mobile node's identity, the mobile node can be authorized for the network-based mobility management service, i.e., permitted by the network to obtain an access address. The proposed PMIPv6-based global mobility management architecture and protocol exploit this feature. 2.2 Related work There are two classes of mobility management methods. The first is tunnel based approach, as exemplified by Mobile IPv6, in which mobility agents establish tunnels to forward packets whose destination address does not belong to the network. As long as the tunnel endpoints can support the protocol, intermediate nodes need not be aware of the protocol and their routing tables are not affected. The second is host-routing based approach, such as Cellular IP and HAWAII [15], in which mobility agents maintain the next hop for the mobile node and packets destined for the mobile node are relayed by these agents. Although there is no tunnel overhead, all the nodes need to be aware of the protocol and their routing tables are influenced. A detailed description of these mobility support protocols is provided in [15]. It should be noted Mobile IPv6, Cellular IP and HAWAII are host-based solution. In contrast, GPMIP is a network-based solution, i.e., a network entity, the Mobile Access Gateway, sends Proxy Binding Update messages for location registration. The Local Mobility Anchor advertises the mobile node's home network prefix or an aggregated prefix with a larger scope to the Routing Infrastructure. Mobile IPv6 is a host-based solution for handling the global mobility of hosts in IPv6 networks. This means that a host is involved in mobility-related signaling and a modification of the host protocol stack is required for operating Mobile IPv6 [16]. In contrast, GPMIP provides a

Mobile Netw Appl

network-based solution for handling the mobility of IPv6 hosts. Therefore, no requirement on the hosts is needed. 3GPP General Packet Radio Service (GPRS) has devised its own protocol, the GPRS Tunneling Protocol (GTP) as documented in 3GPP TS 23.060, to handle mobility. In the GTP protocol, a tunnel is established from Serving GPRS Support Node (SGSN) to Gateway GPRS Support Node (GGSN) for the User Equipment’s data packets. GTP provides a kind of IP localized mobility management that requires minimal host involvement. From the IP perspective of the mobile node, the mobile node is attached to a single subnet while it moves around a particular GPRS domain. When the MN roams outside its home network, GPRS Roaming eXchange (GRX) as prescribed in GSM Operators' Association Permanent Reference Document IR.33 is used as a global mobility management protocol. GRX is a network-based protocol that enables the serving network GGSN to manage an address in the home network in a way similar to Mobile IP. To support the mechanism, Mobile Switching Center/Visitor Location Register (MSC/VLR) and Home Location Register (HLR) in the existing GSM network are also modified [17]. Recently, 3GPP is working on the new SAE Evolved Packet System (EPS) for Release 8. The target is a lowlatency, higher data-rate, all-IP core network capable of supporting real-time packet services over multiple access technologies. Two network architecture solutions are GTPbased solution described in 3GPP TS 23.401 and PMIPbased solution outlined in 3GPP TS 23.402. 3GPP does not require PMIP for different technology handover (that is done by LTE, WIMAX or UMTS specific L2 mobility), but wants to deploy PMIP for the integration of these technologies in an SAE architecture. In contrast, GPMIP has some resemblance to GPRS in that they are both network-based mobility management protocols and have similar functionalities. The bidirectional tunnel in GPMIP is established between the Local Mobility Anchor and Mobile Access Gateway and is typically a shared tunnel, and can be employed to route traffic streams for different mobile nodes attached to the same Mobile Access Gateway. From the perspective of the mobile node, the PMIPv6 access network appears as its home link or a single link. Furthermore, there exist a location database server for maintaining global and visitor locations and an Authentication, Authorization, and Accounting server for global AAA and AAA in the GPMIP core and access network, respectively. GPMIP is an Internet protocol which is not dependent on any access-technology-specific protocol. Therefore, it can be used in any IP-based network. On the other hand, GPRS is an access-technology-specific protocol closely coupled with the signaling protocols used in legacy cellular systems.

The roaming mechanisms between PMIPv6 domains have been discussed in NETLMM working group. In [18], Local Mobility Anchors and Mobile Access Gateways in two domains perform exchange of mobility signaling messages on behalf of mobile nodes. All scenarios that require direct interaction between MIPv6 and PMIPv6 are analyzed in [19]. One of the scenarios uses MIPv6 to manage mobility among different access networks and uses PMIPv6 to implement mobility within an access network. This interaction is very similar to the HMIPv6-MIPv6 interaction. However, based on the design considerations mentioned in subsection 2.1, the proposed GPMIP is a centralized architecture. It introduces a global location database server and a global AAA server. In this paper, the proposed GPMIP is compared with the distributed HMIPv6-MIPv6 protocol.

3 GPMIP global mobility management architecture and protocol This section describes the proposed PMIPv6-based global mobility management architecture and the protocol procedure. 3.1 PMIPv6 overview PMIPv6 [5] is a network-based mobility management protocol reusing MIPv6 entities and concepts as much as possible. PMIPv6 Domain is a localized mobility management domain where the mobility management of a mobile

PMIPv6 AAA

Domain LMA

PBU MAG2

MAG1

movement MN

Fig. 1 PMIPv6 domain architecture

Mobile Netw Appl

ters, such as the mobile node's home network prefix (HNP), permitted address configuration modes, roaming policy, and other parameters that are essential for providing networkbased mobility service. The GPMIP access network is a PMIPv6 Domain (PMIPv6 Domain). There are a Dynamic Host Configuration Protocol (DHCP) server, an AAAA server, and a Visitor Location Database (VDB) server in a PMIPv6 Domain. PMIPv6 Domains are interconnected by core routers (CRs). In a PMIPv6 Domain, LMA is the Home Agent for the mobile node. It has the functional capabilities of a Home Agent as defined in Mobile IPv6 base specification. It is also the entity that manages the mobile node's reachability state. MAG is the entity that performs the mobility management on behalf of a mobile node and resides on the access link where the mobile node is anchored. MAG is responsible for detecting the mobile node's movements on its access link and for sending binding registrations to the mobile node's LMA for updating the route to the mobile node's home address. Once the mobile node enters its PMIPv6 domain, the link layer Link Up trigger occurs when the link layer link between the MN and the MAG is established. The mobile node sends the Link Up trigger message to the MAG. When the mobile node attaches to an access link connected to the MAG, it presents its identity (e.g., NAI) as part of the access authentication procedure. If the mobile node enters a PMIPv6 domain for the first time, the AAA server does not have its policy profile, and the AAA server in the PMIPv6 domain will relay the AAA request to GAAA. After a successful access authentication using that identifier, the MAG will obtain the mobile node’s policy profile from GAAA server. The current PMIPv6 specification supports the perMN's interface prefix addressing model. In this addressing

node is handled using PMIPv6 protocol. The architecture of a PMIPv6 domain is shown in Fig. 1. In this protocol, the mobile nodes are differentiated by a Network Access Identifier (NAI) [20], which has an associated set of information stored on the network, including a profile containing the home prefix. The Mobile Access Gateway (MAG), located in the access router, retrieves the MN profile information from AAA server and sends the customized Router Advertisements (RAs) to the MN, emulating the home network behavior. The MN configures its Home Address (MN-HoA) on the network interface. Because the MN always receives the same home prefix, it believes that it is in the Home Domain. Furthermore, the Mobile Access Gateway performs Proxy Binding Updates (PBU) signaling on behalf of the MN to the MN's Local Mobility Anchor (LMA), informing the LMA that the current Proxy Care-of Address of the registered MN is the MAG's address. These procedures also lead to the establishment of tunnels between LMA and MAG. 3.2 PMIPv6 based global mobility management architecture The proposed GPMIP extends PMIPv6 to support global mobility management. The proposed GPMIP is shown in Fig. 2. The GPMIP administration domain is composed of a core network and several access networks. There exist a global location database server (GDB) and a global Authentication, Authorization, and Accounting (GAAA) server in the GPMIP core network. GDB is used to store up-to-date location information and controls the location management for all mobile nodes. GAAA server stores the policy profile of all mobile nodes. The policy profile typically contains the provisioned network-based mobility service characteristics and other related parameFig. 2 GPMIP architecture

core network GAAA GDB access network 2 VDB2 DHCP2 AAA2

access network 1 AAA1

DHCP1

PMIPv6 Domain 1

VDB1

LMA 1

CR

PMIPv6 Domain 2

CR LMA2 MAG3

MAG2

MAG 4

MAG1 movement MN

CN

Mobile Netw Appl

model, each interface of a mobile node is allocated an exclusively unique home network prefix and the prefix is not hosted on the home link. In this addressing model, the LMA is just a topological anchor point and the prefix is physically hosted on the access link to which the mobile node is attached. The home network prefix of the mobile node may have been statically configured in the GAAA's policy profile, or, it may have been dynamically allocated by the LMA. For updating the LMA about the current location of the mobile node, the MAG sends a PBU message to the mobile node's LMA. The message will have the mobile node's NAI option and Home Network Prefix option. The source address of that message will be the address of the MAG on its egress interface. Upon accepting the PBU request, the LMA allocates a prefix for the mobile node. As DHCP for IPv6 (DHCPv6) [21] servers can manage prefixes [22], GPMIP releases the prefix allocation tasks from LMA to the DHCPv6 server in a PMIPv6 domain. The procedure for prefix delegation with DHCP has been defined in [23] which is independent of address assignment with DHCP. After allocating a prefix for the mobile node, the LMA sends a Proxy Binding Acknowledgement (PBA) message which includes the Home Network Prefix option containing the allocated prefix value. It creates a Binding Cache entry and establishes a bi-directional tunnel to the mobile access gateway. It also sets up a route to the mobile node's home network over the tunnel. Upon receiving PBA message, the MAG sets up a bidirectional tunnel to the LMA and adds a default route over the tunnel to the LMA All traffic from the mobile node gets routed to the mobile node's LMA over the tunnel. Now the MAG has all the information for it to emulate the mobile node's home network on the access link. The MAG also starts sending periodic Router Advertisements to the mobile node advertising its home network prefix. After receiving the Router Advertisement messages on the access link, the mobile node will configure its interface using stateful address configuration modes. At this point, the mobile node has a valid home address from its home network prefix at the current point of attachment. The serving MAG and LMA have proper routing states for handling the traffic sent to and from the mobile node. From the perspective of the mobile node, the entire PMIPv6 domain appears as its home link or a single link. The serving MAG sends location registration or update message to the PMIPv6 domain’s VDB server. The VDB server will add (for an MN first entering a PMIPv6 domain) or update (for MAG handover in a PMIPv6 domain) the mapping table that contains the mapping relationship between the mobile node’s NAI and MN-HoA. For an MN first entering a PMIPv6 domain, the VDB server will then send a

location registration or update message to the GDB server of the core network. When the GDB server receives the location update message from the VDB server, it will update the associated entry in the mapping table for the mobile node. When a LMA is serving a mobile node, it must attempt to intercept correspondent node’s (CNs) packets that are sent to any address that is in the mobile node's home network prefix address range. The LMA advertises a connected route to the Routing Infrastructure for that mobile node's home network prefix or for an aggregated prefix with a larger scope. This enables routers in the IPv6 core network to detect the LMA as the last-hop router for that prefix. 3.3 PMIPv6-based global mobility management protocol procedure In GPMIP architecture, the stateful address configuration is used in PMIPv6 access links and prefix allocation using DHCPv6. The GPMIP protocol procedure is shown in Fig. 3. Here it is assumed that MAG has established a secure association with LMA, VDB, DHCP and AAA, respectively. Also it is assumed that all the AAA and VDB in a PMIPv6 domain have already established secure associations with GAAA and GDB, respectively. The procedure involves the following steps: 1-3) MN enters the network and MAG receives the authorization profile from AAA server after successful AAA exchanges. 4) MAG sends a PBU to LMA. When a MN first enters a PMIPv6 domain, the HNP field is set to zero, and then the LMA will allocate a prefix for the MN. If the MN moves to a different access link and a new MAG learns the MN’s HNP, the MAG will specify the same in the HNP option to request the LMA to allocate that prefix. MN

MAG1

LMA1

AAA1

GAAA 1.MN Attached 2.Access Authentication 3.Authentication success DHCP1 4.PBU (HNP=0) 5.DHCP Solicit 6.DHCP Advertise 7.DHCP Request (HNP) 8.DHCP Reply (HNP) 9.PBA (HNP) 10.Bi-directional Tunnel Profile Complete AAA1 VDB1 GDB 11.DHCP Request 12.DHCP Reply 13.Access-Request 14.Location Update 15.Access-Accept 16.Location query 17.Location Reply Deliver packets

Fig. 3 GPMIP protocol procedure

Mobile Netw Appl

5) LMA as the requesting router initiates DHCP Solicit procedure to request a prefix for the MN. LMA creates and transmits a Solicit message. The Solicit message should include an Identity Association for Prefix Delegation option [23]. 6) The DHCP server acts as the delegating router and sends an Advertise message to LMA. 7) LMA uses the DHCP Request message to obtain or update the prefix from a DHCP server. 8) LMA stores the prefix information it received in the Reply message. 9) LMA replies with PBA and sets its HNP parameter. 10) Bi-directional tunnel is established. Access authentication and profile acquisition are completed. 11) MN requests an address from the local DHCP proxy collocated in MAG. 12) DHCP Proxy assigns MN-HoA from this prefix and sends it to MN in DHCP Reply message. 13) Once address configuration finishes, the MAG sends Access-Request with MIP6-DNS-MO Attribute defined in [24] to instruct AAA server to perform a dynamic DNS update. 14) The AAA server performs DNS update according to [25]. 15) The AAA server sends Access-Accept message including MIP6-DNS-MO attribute to confirm the DNS update. 16-17) When a MN wants to communication with a CN, the MN sends a location query message including the CN’s NAI to VDB server. If there is no location entry of the CN, VDB server will forward the location query message to GDB server. GDB server will return the CN’s address to the MN through location reply message. In this paper, it is assumed that the CN has performed steps 1-15.

4 HMIPv6-based global mobility management architecture and protocol As the architecture and functionality of GPMIP are similar to HMIPv6 [2], HMIPv6 is chosen for comparison with the proposed GPMIP. 4.1 HMIPv6-based global mobility management architecture According to Mobile IPv6 definition, a MN must send Binding Updates (BUs) to its Home Agent and all Correspondent Nodes to keep session continuity while moving across different subnets. A return routability procedure before a correspondent registration must be executed between the MN and each CN. Four messages, including Home and Careof Test Init and Home and Care-of Test, form the return routability procedure. Since Home Agent is usually far away from mobile node and the Binding Updates latency is very large, HMIPv6 [2] is proposed. The Mobile IPv6 administration domain is also composed of a core network and several HMIPv6 access networks. HMIPv6 access network is a localized mobility management domain in which the mobility management of a MN is handled using HMIPv6 protocol. In order to implement global mobility management, HMIPv6 must interact with Mobile IPv6. For simplicity, HMIPv6 means HMIPv6-MIPv6 interactive protocol in this paper. The architecture of HMIPv6 is shown in Fig. 4. HMIPv6 defines a local Mobile Anchor Point (MAP) which acts as a local Home Agent. HMIPv6 domain is the same as MAP domain. A HMIPv6-compliant MN can send BUs to the local MAP rather than the Home Agent and CNs. This can reduce the amount of Mobile IPv6 signaling outside the local MAP domain. When a MN moves into a new MAP domain, thus inducing an inter-domain hand-

Fig. 4 HMIPv6 architecture Core network

access network 2

access network 1 AAA

DHCP2 HAAA

DHCP1

HMIPv6 Domain 1

MAP1

CR

HMIPv6 Domain 2

CR MA P AR3

AR2

AR4

AR1 movement MN

CN

Mobile Netw Appl MN

AR1

MAP1

HAAA 1.MN Attached 2.Access Authentication 3.Authentication Success 4.Prefix Advertisement DHCP1 5.DHCP Solicit 6.DHCP Advertise 7.DHCP Request 8.DHCP Reply 9.Binding Update 10.Binding Acknowledgement HA CN 11.Binding Update 12.Binding Acknowledgement 13.Bi-directional Tunnel 14.Home Test Init 15.Care-of Test Init 16.Home Test 17.Care-of Test 18.Binding Update 19.Binding Acknowledgement 20.Deliver packets

AAA1

Fig. 5 HMIPv6 protocol procedure in integrated scenario

over, it needs to configure two Care-of Addresses (CoAs): a Regional CoA (RCoA) on the MAP's link and an on-link CoA (LCoA) based on the prefix advertised by current Access Router (AR). The RCoA can be formed in a stateless or stateful manner. After forming the RCoA, the MN sends a local BU to the MAP, which returns a Binding Acknowledgement (BA) to the MN. After successfully registering with the MAP, a bi-directional tunnel between the MN and the MAP is established. Next, the MN must register its new RCoA with its Home Agent and CNs by sending each a BU that specifies the binding (RCoA, Home Address). Packets from the Home Agent or CNs will be tunneled from the MAP to the MN's LCoA. If the MN change its LCoA within a MAP domain (i.e., an intradomain handover), it only needs to register the new LCoA with the MAP. In HMIPv6, the MAP performs the function of a "local" Home Agent that binds the MN's RCoA to an LCoA. The Home Agent and CNs are unchanged. HMIPv6 requires updating the implementation of mobile nodes only.

5 Analytical models In this section, the analytical network and user mobility models are described. Based on these models, this section derives analytically the location update, packet delivery, and total cost functions generated by a MN during its average domain residence time in a PMIPv6 or MAP domain. For simplicity, the periodic binding refresh costs are not considered. The costs of GPMIP and HMIPv6 are compared in section 6. 5.1 Network model The GPMIP architecture given in Fig. 2 can be viewed as a three-tier hierarchical network model as shown in Fig. 6. The first tier comprises the GDB server and the GAAA server. The second tier has a mesh topology, which consists of M mesh nodes, i.e., LMAs. It is assumed that DHCP server, VDB server and AAA server in a PMIPv6 domain co-locate with the LMA node. It is also assumed that each second tier node is the root of an N-ary tree of depth 1. The third tier nodes are MAGs. Each PMIPv6 domain is composed of all the third tier nodes under the same second tier node. The domain size, i.e., N, is defined as the number of the third tier nodes in a PMIPv6 domain. In this paper, it is assumed that the link hop count between the first tier and second tier nodes is a, the hop count among the second tier nodes is b, the hop count between the second and third tier nodes in the same domain is c, and the hop count between the third tier nodes and an MN or CN in the same domain is 1, respectively. Obviously, the hop counts a, b, and c are for wired links, only the last hop is wireless. For the performance analysis of the two protocols under the same network architecture, the functionality of MAP is assumed to be resident on the second-tier node. There exists a DHCP server located in a MAP domain. The AAA server, HAAA server, and DHCP server are assumed to exist on GAAA,GDB

4.2 HMIPv6-based global mobility management protocol procedure MAP,DHCP,HAAA

Because of the similarities between GPMIP and Mobile IPv6 for integrated scenario, Mobile IPv6 for integrated scenario [26] is chosen for comparison. In an integrated scenario, the same Home AAA (HAAA) server can authorize the MN for network access and mobility service at the same time. In Fig. 4, there is an AAA and a Home AAA (HAAA) server in a visited MAP domain and the MN’s home domain, respectively. There exists a DHCP server located in a MAP domain. Figure 5 shows the HMIPv6 protocol procedure in an integrated scenario. The details are described in [26, 27].

LMA,DHCP,VDB,AAA or MAP,DHCP,AAA

a

MAG or AR HA

First tier nodes b

Second tier nodes

c

CN

Fig. 6 Network model

Third tier nodes

MN

Mobile Netw Appl

the second tier node, too. The access routers and the MN’s Home Agent (HA) form the third tier. It is also assumed that the CN, MN, and HA are located in different domains, and the PMIPv6 domain is identical to the MAP domain. 5.2 Fluid flow mobility model The fluid flow mobility model in [28–30] is adopted to analyze the costs for GPMIP and HMIPv6. In this model, it is assumed that a PMIPv6 or MAP domain is composed of N identical subnets. All the subnets are circular and of the same size and together form a contiguous area. The subnet handover in a PMIPv6 domain is a MAG handover. It is assumed that the MNs are moving at an average speed v, and their movement direction is uniformly distributed over [0, 2π]. Let S denote the subnet area. Following [28], the MN’s subnet residence time tsub can be derived as the following equation: pffiffiffiffiffiffi pS ð1Þ tsub ¼ 2v Furthermore, state i (0≤i≤N) is defined as the number of subnets wherein a mobile node has stayed within a given domain. State 0 represents the situation that the mobile node stays outside of a given domain. It is assumed that a mobile node moves out of a given domain within a maximum of N movements. Let πi be the steady-state probability of state i. Then we have

pi ¼

81 > > >2
N 1 > > : 1 1 p1ffiffiffi 2 1 2

p1ffiffiffi N

i1

N

if i ¼ 0 if 1 i N 1

ð2Þ

if i ¼ N

Let Φ(N) denote the average number of subnets within a given domain that an MN visits. Then we have ΦðN Þ ¼

N X

respectively, and τ denotes the additional weight of packet tunneling. Let LGG and LGV denote the location update costs to register with the GDB and the VDB, respectively. LGC denotes MN’s location query cost of CNs. LGPMIP denotes the average location update cost for GPMIP. By applying the GPMIP protocol procedure described in Fig. 3 to the network model given in subsection 5.1, we can obtain LGL, LGC and LGPMIP as shown in the equations below. LGG ¼ ðq þ 2ðc þ aÞhÞ þ 2ch þ q þ 2q þ 2ðc þ aÞh ¼ 4q þ ð6c þ 4aÞh

LGV ¼ ðq þ 2ðc þ aÞhÞ þ 2ch þ q þ 2q þ 2ch ¼ 4q þ ð6c þ 2aÞh

ð7Þ

LGPMIP ¼ p 0 ðLGG þ "LGC Þ þ ðΦðN Þ 1Þ LGV

ð8Þ

where ε is the average number of CNs when an MN moves into/out of a given domain. The term p 0 ðLGG þ "LGC Þ in (8) accounts for the inter-domain cost and ðΦðN Þ 1Þ LGV for the intra-domain cost. On the other hand, let DGPMIP be the average packet delivery cost for GPMIP. Then DGPMIP is given by the following equation: DGPMIP ¼ p tsub ΦðN Þ ð2q þ ð2tc þ bÞhÞÞ

ð9Þ

where p is the average packet arrival rate at an MN per subnet. Finally, the total cost CGPMIP for GPMIP can be expressed as follows: ð10Þ

ð3Þ

i¼1

Finally, the average domain residence time of an MN, tdomain, is obtained as tdomain ¼ tsub ΦðN Þ

ð6Þ

LGC ¼ 2q þ ð2c þ 2aÞh

CGPMIP ¼ LGPMIP þ DGPMIP ip i

ð5Þ

ð4Þ

5.3 Cost functions for GPMIP Although signaling messages as defined in GPMIP have different sizes, for sake of simplicity, it is assumed that they all have the same size. Thus, the location update costs are proportional to the link hops between the source and destination of a message. Let θ and η denote the unit transmission costs in a wireless and a wired link,

5.4 Cost functions for HMIPv6 Let LHM, LHH and LHC denote the location update costs to register with the MAP, the HA and the CN in HMIPv6, respectively. LHMIP denotes the average location update cost in HMIPv6. According to the HMIPv6 protocol procedure described in Fig. 5, LHM, LHH, LHC and LHMIP can be obtained as the following equations:

LHM ¼ 2ðq þ ch þ bhÞ þ 4ðq þ chÞ þ 2ðq þ chÞ ¼ 8q þ ð8c þ 2bÞh

ð11Þ

Mobile Netw Appl

LHH ¼ 2q þ ð2c þ bÞh

ð12Þ

2500 GPMIP location update GPMIP packet delivery

LHC ¼ ð2q þ ð2ðb þ cÞ þ 2cÞhÞ

GPMIP total

2000

HMIPv6 location update HMIPv6 packet delivery HMIPv6 total

þ ð2q þ ðb þ 2cÞhÞ þ ð2q þ ðb þ 2cÞhÞ ð13Þ

LHMIP ¼ p 0 ðLHM þ LHH þ "LHC Þ þ ðΦðN Þ 1Þ

1500 Costs

¼ 6q þ ð8c þ 4bÞh

1000

ð14Þ

LHM

The term p 0 ðLHM þ LHH þ "LHC Þ in (14) is the interdomain cost and ðΦðN Þ 1Þ LHM is the intra-domain cost. Let q be the probability that a single packet is routed directly to the MN without being intercepted by the HA. Dhdir, Dhindir and DHMIP denote the packet delivery cost incurred by a direct packet delivery (not intercepted by the HA), by delivering a single packet routed indirectly through the HA, and for HMIPv6, respectively. Then Dhdir, Dhindir and DHMIP can be expressed by the equations below. Dhdir ¼ 2tq þ ð2tc þ bÞh

ð15Þ

Dhindir ¼ 2tq þ t ð2c þ bÞh þ ð2c þ bÞh

ð16Þ

DHMIP ¼ p tsub ΦðN Þ fqDhdir þ ð1 qÞDhindir g

ð17Þ

Finally, the total cost CHMIP for HMIPv6 can be expressed as follows: CHMIP ¼ LHMIP þ DHMIP

ð18Þ

6 Numeric results This section evaluates the performance of GPMIP and HMIPv6 based on the analytic cost functions in section 5. The default parameter values for the analysis are given in Table 1. Some parameter values are taken from [28].

500

0

0

5

10

15 20 25 30 Average moving speed (km/hr)

35

40

Fig. 7 Costs as a function of the average moving speed

speed v is changed. As Fig. 7 shows, the location update costs generated by a mobile node during its average domain residence time are independent of average moving speed because the average number of subnets that an MN stays within a domain, given by Eq. (3), is not affected by the average moving speed. This means that a slowly moving MN may cross a lot of subnets within a domain, whereas a fast moving MN may cross few subnets within a domain, and vice versa. In addition, Eq. (1) shows that the MN’s subnet residence time decreases as average moving speed increases. Therefore, the packet delivery costs, given by Eqs. (9) and (17), decrease as the average moving speed increases. So, the total costs decrease as the average moving speed increases. Contrarily, when the average moving speed approaches zero, packet delivery costs approaches infinity, but for clarity of presentation, this is not indicated in Fig. 7.

0.79 0.78

6.1 Costs vs. Average moving speed

0.77

Table 1 Parameters for performance evaluation N

S

v

a

25 b 4

10Km2 c 2 η 1

20Km/hr ε 2 τ 1.2

6 p 100Kpkts/hr q 0.7

2

Costs ratios

0.76

Figure 7 shows the location update, packet delivery, and total costs of GPMIP and HMIPv6 as the average moving

0.75 location update packet delivery total

0.74 0.73 0.72 0.71 0.7 0.69

0

5

10

15

20

25

30

Average moving speed (km/hr)

Fig. 8 Cost ratios vs. average moving speed

35

40

Mobile Netw Appl 0.85 0.8 0.75 Costs ratios

Figure 8 shows the ratio of the costs of GPMIP to those of HMIPv6. The ratio of the location update costs is a fixed value of 69.2%. The ratio of the packet delivery costs is also a fixed value of 78.8%, and the value represents the ratio of a single packet delivery costs. GPMIP requires only 78.8–75.8% of the total cost of HMIPv6. This is due to the fact that there is no tunnel establishment between MAG and MN and that MN does not generate mobility messages. Furthermore, Fig. 8 shows that when the average moving speed approaches zero, the ratio of total costs approaches that of the packet delivery costs as they become the dominant factor. The ratio of total costs decreases as average moving speed increases because of short subnet residence time and location update costs becoming the dominant factor.

0.7 0.65

location update packet delivery total

0.6 0.55 0.5

0

5

10

15 Domain size

20

25

30

Fig. 10 Cost ratios vs. domain size

6.2 Costs vs. Domain size Figure 9 shows the location update, packet delivery, and total costs of GPMIP and HMIPv6 increase as the domain size N increases. This is because the average number Φ(N) of subnets that an MN stays within a given domain increases as domain size increases. Moreover, the average domain residence time of the MN increases. Consequently, the MN performs more movements and requires more frequent location updates and higher delivery costs. However, as given by Eq. (3), Φ(N) is not sensitive to the change of N. Thus, the costs increase slowly. Figure 10 shows the ratios of the costs of GPMIP to those of HMIPv6. The ratio of the packet delivery costs is also a fixed value, i.e., 78.8%.The inter-domain cost is fixed for GPMIP and HMIPv6, therefore the intra-domain costs become the dominant factor and the location update costs for GPMIP grows rapidly. This is reflected in the curve of location update cost ratio. Finally, GPMIP requires

only 70.6–76.8% of the total cost of HMIPv6 and the ratio of total costs increases as average domain size increases. Note that if the domain size becomes very large, the ratio of the location update costs approaches 0.8, the ratio of LGV and LHM, because the intra-domain location update costs become the dominant factor. The ratio of total costs approaches that of packet delivery costs because they increase faster than location update costs. 6.3 Costs vs. Link hops between the first tier and the second tier nodes The location update, packet delivery, and total costs of HMIPv6 are not affected by the link hops between the first and second tier nodes. This is due to the fact that there are no global location database server and AAA server in HMIPv6. On the other hand, the location update cost 1.1

700

Costs

500

0.9

400 300

0.8 0.7 0.6 0.5

200

0.4

100 0 0

location update pa cket delivery total

1

Costs ratios

600

GPMIP location update GPMIP packet delivery GPMIP total HMIPv6 location update HMIPv6 packet delivery HMIPv6 total

0

5

10

15 Domain size

Fig. 9 Costs as a function of domain size

20

25

30

2 4 6 8 10 Link hops between the first tier and the second tier nodes

12

Fig. 11 Cost ratios vs. the link hops between the first tier and the second tier nodes.

Mobile Netw Appl 0.79 0.78 0.77

0.75 0.74 0.73 0.72 0.71 0.7 0.69

6.4 Costs vs. Link hops between second tier nodes The location update, packet delivery, and total costs of HMIPv6 increases linearly with b. A large b means that the MN is located far away from HA or CN. Similarly, the packet delivery cost of GPMIP also increases linearly with b. However, the location update cost of GPMIP is not affected by the link hops between second tier nodes. Figure 12 shows the ratio of the costs of GPMIP to those of HMIPv6. In terms of location update cost, the ratio decreases with b as explained above. In terms of packet delivery cost, the ratio also decreases because the growth with b is slower for GPMIP than for HMIPv6. Finally, GPMIP requires only 84.0–71.3% of the total costs of HMIPv6. It can be calculated that the lower bound of the ratio for location update, packet delivery, and total costs are 0, 73.5% and 60.5%, respectively. 6.5 Costs vs. Average packet arrival rate per subnet The location update costs of GPMIP and HMIPv6 are not affected by p. The packet delivery costs of GPMIP and


0.76 Costs ratios

increases linearly with a for GPMIP. However, packet delivery cost is independent of a because MN and CN always communicate directly in GPMIP. Figure 11 shows the ratios of the costs of GPMIP to those of HMIPv6. The ratio of the packet delivery costs is a fixed value of 78.8%. GPMIP requires only 71.0–83.0% of the total cost of HMIPv6 and the ratio increases with a because of the linear increase of location update cost for GPMIP. Calculation reveals that when a equals 31, the ratio of total costs is 1. However, the hop count between any two nodes in the underlying Routing Infrastructure is typically smaller than 16.

0

50 100 150 200 250 Average packet arrival rate per subnet (Kpkts/hr)

300

Fig. 13 Costs ratios vs. average packet arrival rate per subnet

HMIPv6 increase linearly with p, because a larger p implies a higher delivery cost via the tunnel. Figure 13 shows the ratio of the costs of GPMIP to those of HMIPv6. The ratio of the location update costs is a fixed value of 69.2%, that of the packet delivery costs is also fixed at 78.8%. Overall, GPMIP requires only 69.2–78.1% total cost of HMIPv6. 6.6 Costs vs. Probability of a single packet being routed directly to MN The location update, packet delivery, and total costs of GPMIP are not affected by the probability q. Similarly, the location update cost of HMIPv6 is not a function of q. However, packet delivery cost of HMIPv6 decreases with q because as q increases, the number of the packets routed indirectly via HA to MN dwindles.

0.95

0.95 location update packet delivery total

0.9 0.85

0.9 0.85

Costs ratios

0.8 Costs ratios


0.75 0.7 0.65

0.8 0.75 0.7

0.6

0.65

0.55

0.6

0.5 0.55

0.45

0

2

4 6 8 10 Link hops between the second tier nodes

Fig. 12 Costs ratios vs. link hops between second tier nodes

12

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Probability of a single packet being routed directly to the MN (not via HA)

Fig. 14 Costs ratios vs. Probability that a single packet is routed directly to MN

Mobile Netw Appl Table 2 Protocol comparison

Protocol

HMIPv6 + MIPv6

GPMIP

GPRS

Location management scheme MN software modification Location management entities MN Lookup key MN address Tunnel

host-based Yes HA, MAP HoA HoA, CoA MN-MAP, per MN

network-based No GDB, VDB NAI HoA MAG-LMA, shared

network-based minimal HLR, VLR TMSI HoA SGSN-GGSN, shared

Figure 14 shows the ratio of the costs of GPMIP to those of HMIPv6. The ratio of the location update costs is a fixed value of 69.2%. The ratio of the packet delivery costs increases as the packet delivery cost of GPMIP remains constant whereas that of HMIPv6 decreases with q. GPMIP requires only 58.9–88.3% of the total costs in HMIPv6. When the probability q approaches 1, the ratio of packet delivery costs approaches 93.5% and the ratio of total costs approaches 88.8%.

7 Qualitative comparison This section gives a qualitative comparison of the proposed GPMIP with HMIPv6 and GPRS from location update and packet delivery perspective. The protocol comparison is given in Table 2. Again, HMIPv6 in the table means HMIPv6 + MIPv6. The analytical results given in Section 6 indicate that the total costs including location update and packet delivery of the proposed GPMIP are lower than HMIPv6. Furthermore, the deployment of HMIPv6 requires modification to the MN’s software, because HMIPv6 is a host-based solution. GPMIP and GPRS are both network-based solutions. GPMIP does not need software modification on the part of MN, and GPRS needs only minor modification. HMIPv6 mobility management has a distributed architecture, and its location management is performed by Home Agent and Local Mobility Anchor. GPMIP introduces global and visitor location database servers and is a centralized architecture. GPRS location management is also a centralized architecture. To query a MN’s location, HMIPv6 uses the MN’s Home Address, GPMIP uses the MN’s Network Access Identifier, and GPRS uses the MN’s Temporary Mobile Subscriber Identity (TMSI). Furthermore, a mobile node in HMIPv6 is configured with two IP addresses; but in GPMIP or GPRS, only one IP address is needed. In HMIPv6, a tunnel is established between every mobile node and MAP. In GPMIP and GPRS, the tunnel is established between wired network entities and is shared by mobile nodes. As a result, the total location update and packet delivery costs can be decreased.

8 Conclusion This paper proposed a new global mobility management architecture and protocol procedure. The advantages of the Proxy Mobile IP technology are inherited by the proposed scheme. To compare with the well known HMIPv6 mobility management protocol, the location update, packet delivery, and total cost functions generated by a mobile node during its average domain residence time are formulated based on fluid flow mobility model. Then, the impacts of various system parameters, such as the average moving speed of an MN, the domain size, the link hops between the first tier and the second tier nodes, the link hops between the second tier nodes, the average packet arrival rate per subnet, and the probability of a single packet being routed directly to the MN (not via HA), on the cost functions are analyzed, respectively. Results of the analysis indicate that the total costs generated by a mobile node during its average domain residence time for the proposed GPMIP are lower than that for HMIPv6. Moreover, a qualitative comparison of GPMIP, HMIPv6, and GPRS is given, which also shows the advantages of GPMIP. In the future, the location management and handover performance problems will be studied. Acknowledgements This work is supported by the National Natural Science Foundation of China (No. 60870015, 60833002) and 973 Program of China (No. 2007CB307101).

References 1. Johnson D, Perkins C, Arkko J (2004) “Mobility support in IPv6”, RFC 3775 2. Soliman H, Castelluccia C, El Malki K, Bellier L (2005) “Hierarchical Mobile IPv6 Mobility Management (HMIPv6)”, RFC 4140 3. Kempf J, Ed (2007) "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830 4. Kempf J, Ed (2007) "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831 5. Gundavelli S, Leung K, Devarapalli V, Chowdhury K, Patil B (2008) “Proxy mobile IPv6”, RFC 5213 6. Njedjou E, Riera J (2006) "Problem statement for global IP mobility management", draft-njedjou-netlmm-globalmm-ps-01

Mobile Netw Appl 7. Yabusaki M, Okagawa T, Imai K (2005) “Mobility management in all-IP mobile network: end-to-end intelligence or network intelligence?”. IEEE Commun Mag 43(12):16–24 8. WiMAX end-to-end network systems architecture, (Stage 2: Architecture tenets, reference model and reference points), http:// www.wimaxforum.org/technology/documents. 9. 3GPP (2008) “3GPP system architecture evolution (SAE): report on technical options and conclusions”, 3GPP TR 23.882 2.0.0 10. Ahlgren B, Eggert L, Ohlman B, Rajahalme J, Schieder A (2005) “Names, addresses and identities in ambient networks”, In first international ACM Workshop on Dynamic Interconnection of Networks (DIN'05). Cologne, Germany 11. Ahlgren B, Arkko J, Eggert L, Rajahalme J (2006) “A node identity internetworking architecture,” In Proceedings of the 9th IEEE Global Internet Symposium, Barcelona, Spain 12. ITU-T Draft New Recommendation Q.MMF (2007) “Generic framework of mobility management for next-generation networks (version 1.5)” 13. Meyer D, Zhang L, Fall K (2007) "Report from the IAB workshop on routing and addressing", RFC 4984 14. Internet Research Task Force Routing Research Group (RRG), http://tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup 15. Reinbold P, Bonaventure O (2003) “IP Micro-Mobility Protocols”. IEEE Commun Surveys & Tutorials 5(1):40–56 16. Kong K, Han Y, Shin M, Yoo H, Lee W (2008) "Mobility management for All-IP mobile networks: mobile IPv6 vs. Proxy mobile IPv6". IEEE Wireless Communications, pp. 36-45 17. Roberts P, Kempf J (2006) “Mobility architecture for the global internet,” Proc. MobiArch ’06, pp. 23–28 18. Na J-H, Park S, Moon J-M, Lee S, Lee E, Kim S-H (2008) "Roaming mechanism between PMIPv6 Domains", draft-parknetlmm-pmipv6-roaming-01

19. Giaretta G, Ed (2008) "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-ietf-netlmm-mip-interactions01 20. Patel A, Leung K, Khalil M, Akhtar H, Chowdhury K (2005) “Mobile node identifier option for mobile IPv6 (MIPv6)”, RFC 4283, 21. Droms R, Bound J, Volz B, Lemon T, Perkins C, Carney M (2003) “Dynamic host configuration protocol for IPv6 (DHCPv6)”, RFC 3315 22. Sarikaya B, Xia F (2007) “DHCPv6 based home network prefix delegation for PMIPv6”, draft-sarikaya-netlmm-prefix-delegation01 23. Troan O, Droms R (2003) "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633 24. Lior A, Chowdhury K, Tschofenig H (2007) “RADIUS mobile IPv6 support”, draft-ietf-mip6-radius-03 25. Vixie P, Thomson S, Rekhter Y, Bound J (1997) “Dynamic updates in the Domain Name System (DNS UPDATE)”, RFC 2136 26. Chowdhury K, Yegin A (2007) “MIP6-bootstrapping for the integrated Scenario”, draft-ietf-mip6-bootstrapping-integrateddhc-04 27. Giaretta G, Kempf J, Devarapalli V (2007) "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026 28. Kong K-S, Song MB, Park KJ, Hwang C-S (2006) "A comparative analysis on the signaling load of mobile IPv6 and hierarchical mobile IPv6: analytical approach". IEICE Trans Information and Systems E89-D(1):139–149 29. Zhang X, Castellanos G, Campbell AT (2002) “P-MIP: Paging extensions for mobile IP”. ACM/Kluwer Mobile Networks and Applications 7(2):127–141 30. Pack S, Choi Y (2004) "A study on performance of hierarchical mobile IPv6 in IP-based cellular networks". IEICE Trans Commun E87-B(3):462–469