Anda di halaman 1dari 17

Computer Communications 36 (2012) 6379

Contents lists available at SciVerse ScienceDirect

Computer Communications
journal homepage: www.elsevier.com/locate/comcom

Review

A survey of identity and handoff management approaches for the future Internet
Hasan Tuncer a,, Sumita Mishra b, Nirmala Shenoy b
a
Golisano College of Computing and Information Sciences, Rochester Institute of Technology, Rochester, NY 14623, USA
b
Department of Networking, Security, and Systems Administration, Rochester Institute of Technology, Rochester, NY 14623, USA

a r t i c l e i n f o a b s t r a c t

Article history: Since its inception almost 40 years ago, the Internet has evolved and changed immensely. New technol-
Received 3 February 2012 ogy solutions are desired to keep up with this unprecedented growth. Besides the traditional computing
Received in revised form 1 June 2012 devices, different types of mobile devices need to be supported by the future Internet architecture. In this
Accepted 26 July 2012
work, a survey of identity and handoff management solutions proposed in future Internet architectures is
Available online 10 August 2012
presented. Mobility protocols developed by the Internet Engineering Task Force initiatives are discussed
to give the background on the user mobility support challenges with the current architecture. The next
Keywords:
generation network architectures supported by global initiatives are presented and analyzed in terms of
Survey
Future Internet design
their support for seamless user and device mobility. Furthermore, this survey is extended to include the
Seamless mobility architectures proposed for wireless mesh networks, which are envisioned to be a part of the next gener-
Mobile user identity management ation networks with their self organizing and self conguring network characteristics.
Handoff management 2012 Elsevier B.V. All rights reserved.

1. Introduction approaches adopted by them, the challenges that they had tar-
geted, and their limitations given that they have to operate within
The advent of the 1980s brought major changes in the Internets the current Internet Architecture. In this article, we provide the
operation as commercial applications gained popularity. The num- identity and handoff management solutions for the current Inter-
ber of devices and networks connecting to the Internet has in- net Architecture for a reader to have a background information
creased along with the variety of applications and services. The and then focus on a survey of future solutions from several global
unprecedented and signicant technological advancements could projects. Identity and handoff management are closely related top-
not be foreseen during the initial design of the Internet. Despite ics because handoff management solutions get affected by how a
these changes, the Internet continues to operate based on the leg- mobile node (MN) is identied. Furthermore, a mobile nodes ad-
acy principles and protocols. The inclusion of mobile devices and dress is used to trace it while it is moving and also to route the
applications has affected the performance, scalability, and quality packets to the mobile node in its new network. Other factors such
of service (QoS) due to factors such as wireless node handoff, as application level solutions, QoS, and security provisioning are
re-addressing, routing, and security. The United States National also important in supporting seamless handoff management. How-
Science Foundations Future Internet Design (FIND) Initiative [1] ever, they are not covered in this study to maintain our focus.
and Future Internet Architecture (FIA) Project [2], the European Some of the well known mobility protocols developed under
Unions sixth and seventh framework [3] programs, the Asia con- Internet Engineering Task Force initiatives include Mobile IPv4
sortium [4], and New Generation Networks [5] in Japan supports (MIPv4), Mobile IPv6 (MIPv6), Hierarchical Mobile IPv6 (HMIPv6)
evolutionary solutions to overcome the challenges encountered and Proxy Mobile IPv6 (PMIPv6). All these protocols use IP
by the current Internet Architecture. The Global Environment for addresses to identify the mobile node and to route packets to the
Network Innovations (GENI) [6] in the United States and the Future mobile node using these addresses. However, the mobile node
Internet Research and Experimentation (FIRE) [7] in Europe pro- changes its address when it moves to another access point (AP),
vide large-scale experimental network infrastructure for validation network or domain. Therefore, the mobility protocols require ad-
of new protocols and schemes. dress resolution in the new network, while the previous network
Mobility is one of the challenges of existing and future net- is to be informed about the new address. For this purpose, a pro-
worked applications and services. Future Internet design requires cess called address binding is used. The routing tables of the related
an understanding of the current status of mobility solutions, the nodes need to be updated to accommodate the packet routing to
the new location of the mobile node. Other address related factors
Corresponding author. Tel.: +1 5852010834. that need to be considered are the address length (a long address
E-mail addresses: hxt3948@rit.edu (H. Tuncer), nxsvks@rit.edu (S. Mishra), uses up more of the scarce wireless bandwidth) and the support
sxm1145@rit.edu (N. Shenoy).

0140-3664/$ - see front matter 2012 Elsevier B.V. All rights reserved.
http://dx.doi.org/10.1016/j.comcom.2012.07.017
64 H. Tuncer et al. / Computer Communications 36 (2012) 6379

for large number of nodes in future networks. Note that these two initiatives focusing on network virtualization, network manage-
impose contradictory requirements to the addressing scheme. ment, routing, resource sharing, optical networking, and security
Current mobility protocols aim to provide seamless handoff of are explained in [22]. The architectural, socio-economic, and secu-
mobile nodes. A seamless handoff requires low handoff latency rity approaches in European next generation network projects are
and reduced data packet loss in an ongoing session while a mobile discussed in [23].
node transfers from one access point to another access point in the Our work is distinct from existing surveys described in this sec-
same network or another network. Successful implementation of tion because (i) it provides a comprehensive analysis of future
seamless mobility is closely related to the amount of handoff man- Internet Architectures and mobility protocols in light of their iden-
agement messaging between wired and wireless devices that han- tity and handoff management schemes; and (ii) it presents a qual-
dle the session, the number of the nodes that have to change their itative evaluation of current and future schemes on a unied
routing table entries (such as mobile node, correspondent node platform.
(CN), routers in the previous and new networks), and the change
in the current session setup to forward packets to the mobile node
at its new access point. There are various categories of protocols: 3. Background
network-based, host-based, micro-mobility, and macro-mobility.
Each type of protocol provides a different way of organizing the Since Internets advent and the rst RFC published by the Inter-
network and handling the handoff management. net Engineering Task Force in April 1969, it has come a long way,
This article surveys the literature over the period of 20022012 where today several millions of networks and billions of devices
for mobile node identity and handoff management. The survey is connect to the Internet. The number of wireless devices connecting
organized as follows. In Section 2, the related surveys published to the Internet however has far exceeded the number of wired de-
in the mobility research area are presented. Section 3 covers the vices. The inevitable need for Internet connectivity on the move
mobility protocols developed under Internet Engineering Task eventually required the development and deployment of network-
Force initiatives, followed by the solutions proposed towards ing protocols to support handoff of a mobile node. A mobile nodes
future Internet Architectures in Section 4. The discussion of the mobility is categorized based on mobility scope: macro mobility
approaches in Mobile IP protocols and next generation mobility and micro mobility. While macro-mobility refers to the mobility
solutions is provided in Section 5. Concluding remarks are pre- across administrative domains, micro-mobility refers to the move-
sented in Section 6, followed by the Appendix and References. ment of the user across access points or base stations under the
same administrative domain. Furthermore, depending on the ac-
cess technologies that a mobile node is handing off between, cate-
2. Related work gories of vertical and horizontal handoff exist. In vertical handoff, a
mobile node moves between different network types such as IEEE
In the last 15 years, user mobility support has been researched 802.11 WLAN to 3G cellular network while in horizontal handoff, a
extensively. There have been tens of evolutionary or revolutionary mobile node moves between same type of access networks such as
mobility approaches proposed to provide better handoff manage- WLAN to WLAN, or 3G network to 3G network etc.
ment in IP networks, cellular networks, ad hoc networks, or wire- Handoff process can be broken down into the following steps
less mesh networks. Likewise, there have been several literature regardless of the mobility scope and the access network technol-
reviews covering these mobility protocols and focusing on differ- ogy [24]:
ent aspects of mobility management. In this section, we aim to
highlight few of the surveys that investigate these protocols. 1. Handoff initiation: The decision of handoff request to a new net-
Akyildiz et al. [8] give a qualitative comparison of the mobility work is made considering several criteria. In horizontal handoff,
protocols running in all-IP-based wireless systems, categorizing few of the criteria are received signal strength (RSS), signal to
them as network layer, link layer, and cross-layer approaches. In noise ratio (SNR), bit error rate (BER), and channel availability.
[9], a detailed comparative analysis of location update, handoff la- In vertical handoff, additionally, battery lifetime, available band-
tency, and signaling overhead performance of the mobility archi- width, latency and congestion in the network, network cover-
tectures and protocols are presented. Furthermore, handoff age, mobility characteristics of a mobile node, number of users
management, paging, scalability, and robustness of some mobility in the network, policies and billing constraints are also taken
protocols are examined in [10]. Sun and Sauvola [11] present the into account before handoff. Combinations of these metrics are
limitations of Mobile IP in solving the micro mobility challenges, standardized as media independent handoff function module
and the possible solutions to address these challenges are exam- in IEEE 802.21 [25]. IEEE 802.21 provides a shim layer between
ined in [12,13]. OSI layer 2 and layer 3 for helping in handoff initiation, decision,
Xie and Wang [14] investigate the handoff management in and execution by coordinating the exchange of information
wireless mesh networks while IP mobility protocols deployment between 802.3, 802.11, 802.15, 802.16 and 3G networks.
in mobile ad hoc networks (MANETs) is examined in [15]. In 2. Handoff decision: Handoff decision process is categorized as net-
[16,17], the authors provide a survey of integration of 3G and wire- work-controlled handoff, mobile-assisted handoff, and mobile-
less local area network (WLAN), focusing on underlying network controlled handoff. In network-controlled handoff, the network
architectures, handoff management, and QoS. handles the necessary measurements and handoff decision,
In [18], a taxonomy and survey of location management strate- while in mobile-assisted handoff, a mobile node makes the
gies applied by mobility protocols are given. El Maliki et al. [19] measurements and waits for a networks decision on handoff.
cover identity management approaches, or standards considering However, in mobile-controlled handoff, a mobile node decides
privacy and security aspects. Furthermore, the requirements for when to handoff based on the measurements made by both
Internet mobility and a review of the primary handoff support the mobile node and the network.
methods used by IP or cellular network protocols are presented 3. Handoff execution: Handoff is executed as either hard or soft
in [20]. handoff. In hard handoff, also called break-before-make, the
Conti et al. [21] highlight the research challenges towards the ongoing connection with a current network is broken rst, then
design of the future Internet such as scalability, robustness, a connection with a new network is made. In soft handoff, also
security, energy efciency, and exibility. Future Internet design called make-before-break, a mobile node is connected to both
H. Tuncer et al. / Computer Communications 36 (2012) 6379 65

networks at the same time and hands off to the new network 3.1.1. Identity management in Mobile IPv4/IPv6
completely after all the mobility related processes are Mobile IP uses IP addresses to identify a mobile node. Mobile IP
completed. also uses IP addresses to locate the mobile node, and to forward
packets destined to a mobile node via its IP address. However, a
IETF aims to standardize different network types such as mobile node acquires a new IP address called care-of address
WLANs under 802.11 a/b/g/n, mesh networks under 802.11s, wire- (CoA) from a foreign network (FN), where it is roaming. Before
less personal area networks (WPAN) under 802.15, IPv6 over Low using the address, a mobile node has to do duplicate address detec-
power WPAN (6LoWPAN) that works with 802.15.4, broadband tion (DAD) to check the uniqueness of the new address in MIPv6
wireless access WiMAX under 802.16. As stated before, IETF also [28].
introduced 802.21 to provide a framework for media independent To handle this address change issue, Mobile IP uses the home
handover focusing on OSI layer 2. Seamless mobility management address of a mobile node (HoA) in its home network as its global
maintaining the desired QoS provisions is a challenging task be- identier. A mobile node is thus expected to register its care-of ad-
cause of the change in network connection, access technology, net- dress to its home network. Home network deploys home agent
work condition, and mobile node identiers. Current research aims (HA) which handles registration of mobile nodes care-of address
to provide solutions focusing on different OSI layers. For instance, at the home network. After a mobile node gets the care-of address,
IETF introduces 802.21 focusing on OSI layer 2, MIPv4, MIPv6, Fast the mobile node and home agent exchange binding update (BU)
MIPv6, HMIPv6, and PMIPv6 focusing on OSI layer 3, and further, and binding acknowledgement (BA) messages. The home agent is
the Session Initiation Protocol (SIP) as signaling protocol for con- also responsible of forwarding the packets to the mobile node
trolling voice and video sessions focusing on OSI application layer. using the mobile nodes care-of address.
In this survey, we concentrate on OSI layer 3 identity and handoff
management because a mobile node needs to preserve its identity
3.1.2. Handoff management in Mobile IPv4/IPv6
regardless of its network point of attachment, and supporting hand-
As a mobile node continues to use its home IP address as a glo-
off between different networks is vital for providing seamless mobil-
bal identier, a correspondent node does not have to be aware of a
ity experience and maintaining the QoS provisioning for the user.
mobile nodes current care-of address. The home agent intercepts
Furthermore, in the current Internet Architecture, its IP address is
these packets on behalf of the mobile node and then forwards data
used to trace the mobile node and also to route the data packets to
packets to the mobile node using IP-in-IP packet encapsulation or
it in its new network. In this section, the identity and handoff
tunneling [29]. However, packets that are sent from the mobile
management design fundamentals of MIPv4, MIPv6, Fast MIPv6,
node are not handled in this way, but are instead sent straight to
HMIPv6, and PMIPv6 mobility protocols are presented. Knowing
their destination. Hence, this packet routing process is called trian-
the phases that Mobile IP went through helps in understanding the
gular routing in MIPv4 [30]. This non-optimal packet routing and
reasons behind the current challenges of the Internet and the design
tunneling however impose a high redirection load on the home
philosophy of the future Internet projects discussed in Section 4.
agent and cause handoff latency as well. Therefore, MIPv6 intro-
duced route optimization to overcome this issue.
3.1. Mobile IP for Internet Architecture MIPv6 with route optimization enables a mobile node to com-
municate directly with a correspondent node using its care-of ad-
Mobile IP was rst designed as an extension to the IPv4 proto- dress without a home agent intervention. However, route
col, and it was named as MIPv4 [26]. Subsequently MIPv6 [27] was optimization process requires a sequence of signaling message ex-
proposed when IPv6 was introduced to overcome the limitations of changes between a mobile node, a home agent, and a correspon-
IPv4. dent node as depicted in Fig. 1 [31].
As it can be observed in MIPv4 and MIPv6, mobile node starts
communicating with a home agent after it gets a care-of address
from a foreign network which introduces some latency. To over-
come this problem, Internet Engineering Task Force proposed Fast
MIPv6 as an extension to MIPv6. Fast MIPv6 allows a mobile node
to establish a new temporary care-of address before breaking its
connection with its old access point which is called anticipated
handoff [32]. When the mobile node is attached to the new access
point, it can continue its communication with its new already-
known address. If the anticipated handoff fails, the mobile node
can always carry out a traditional handoff process. Moreover, Fast
MIPv6 sets up a tunnel between the old access point and the new
access point for the transmission of the data packets buffered at
the old access point during the handoff process.

3.2. Hierarchical Mobile IPv6

HMIPv6 [33] was designed to provide seamless handoff man-


agement for a mobile node within an administrative domain.
Therefore, it is categorized as a micro-mobility management proto-
col. When the mobile node is roaming within an HMIPv6 domain, it
does not have to send binding update messages to the home net-
work or the correspondent node. HMIPv6 reduces the signaling
load in the network by managing handoff locally in the domain
Fig. 1. The message ow for MIPv6 with route optimization when mobile node and is thus more scalable and can support more mobile nodes.
moves to a new network. Fig. 2 illustrates a typical HMIPv6 deployed network.
66 H. Tuncer et al. / Computer Communications 36 (2012) 6379

Fig. 2. Mobility anchor point deployment in a typical HMIPv6 network and the addresses mobile node acquires in the HMIPv6 domain.

3.2.1. Identity management in Hierarchical Mobile IPv6 3.3. Proxy Mobile IPv6
HMIPv6 uses two addresses to support the mobile nodes micro-
mobility. On-link care-of address (LCoA) is created based on access Proxy Mobile IPv6 (PMIPv6) was proposed by the Network-
point link and a regional care-of address (RCoA) is created based on based Localized Mobility Management Internet Engineering Task
currently connected networks prexes [34]. On-link care-of ad- Force Working Group [35]. PMIPv6 is a network-based micro-
dress is local identier for a mobile node within a domain while re- mobility management protocol, and it does not require a mobile
gional care-of address is used to identify a mobile node globally. node to incur any mobility related signaling such as sending of
binding updates, and encapsulation/decapsulation of data packets
[36]. This is unlike MIPv6, HMIPv6 and Fast MIPv6 which propose
3.2.2. Handoff management in Hierarchical Mobile IPv6 host-based solutions and require a mobile node to actively involve
HMIPv6 introduces a concept of mobility anchor point (MAP) in handoff management processes.
that manages a micro-mobility of a mobile node within a domain.
The mobile node exchanges local binding update and local binding 3.3.1. Identity management in Proxy Mobile IPv6
acknowledgement with the mobility anchor point to register to a PMIPv6 identies a mobile node with a 128-bits long IPv6 ad-
new access point. The mobile node then sends a binding update dress in a new network. Mobile node is not involved in address cre-
message to its home agent and correspondent node for them to ation process and this address does not change as long as mobile
bind the regional care-of address with the home address of the node moves within the same PMIPv6 domain [37].
mobile node. If the mobile node moves within the same mobility
anchor point domain as in Fig. 2, its regional care-of address will 3.3.2. Handoff management in Proxy Mobile IPv6
not change. The mobile node has to only register its new on-link PMIPv6 introduces a mobility access gateway (MAG) module
care-of address to the mobility anchor point. This is one of the which is installed on access points and a local mobility anchor
advantages of using micro-mobility protocols over macro-mobility (LMA) which is a wired node that all access points have connection
protocols, because in a macro-mobility protocol, whenever a mo- to. Mobility access gateway has the main role of detecting the mo-
bile node changes its address, a home agent has to be updated, bile nodes movements and initiating mobility-related signaling via
which results in higher signaling load, increased latency, and even- local mobility anchor on behalf of a mobile node [38]. Local mobil-
tually more packet loss. ity anchor module decides on the mobile nodes new address and
When the correspondent node or the home agent have packets then enables mobile node to communicate with external network
to send to the mobile node, they will address the packets to the nodes. To do that, mobility access gateway establishes a bidirec-
mobile nodes regional care-of address. Then, the mobility anchor tional tunnel with local mobility anchor.
point intercepts these packets and sends them to the mobile node As illustrated in Fig. 3, once a mobile node attaches to a mobility
through a bidirectional tunnel binded to the on-link-care-of ad- access gateway module for the rst time, the mobility access gate-
dress of the mobile node. way and the local mobility anchor exchange proxy binding update
H. Tuncer et al. / Computer Communications 36 (2012) 6379 67

Fig. 3. The micro-mobility related message ow occurs between mobility access gateway and local mobility anchor in PMIPv6.

(PBU) and proxy binding acknowledgement (PBA) messages, and current Internet Architecture. To overcome these challenges,
conrm the mobile nodes prole with an authentication, authori- MobilityFirst follows key design principles such as separation of
zation, and accounting (AAA) server. The local mobility anchor names from addresses, decentralized naming service, and general-
sends an address assigned to a mobile node via a proxy binding ized delay tolerant network (GDTN) with storage-aware routing. In
acknowledgement message. The local mobility anchor also sets order to maintain the focus of this survey, we will not go into de-
up a bidirectional tunnel with the mobility access gateway for tails of every component and functionality; instead we will explore
the mobile node to be able to communicate with a correspondent how host/node identication and handoff management are han-
node. dled by MobilityFirst.
To compare the current and future mobility protocols under a
unied platform, a set of categories is identied (see Appendix 4.1.1. Identity management in MobilityFirst
for details). Section 5 gives a qualitative discussion of all these pro- MobilityFirst provides three levels of identication as depicted
tocols under this developed platform. in Fig. 4 [43]. At the highest level, each entity, e.g. computing de-
vices, sensors and multimedia content, is presented with human-
4. Next generation mobility solutions readable, context strings such as Joes laptop or Movie-A. At
the second level, these entities are specied using a long-term,
Mobility protocols built to operate on the current IP architec- globally unique ID (GUID) from a at naming space which does
ture are discussed in the previous section. The performance of not depend on a network attachment point. Finally at the third le-
these protocols in terms of total overhead, handoff latency, vel, these entities are specied with a network address such as IP
capability of handling high mobility trafc and their limitations address. The proposed architecture provides a decentralized nam-
are studied in [37,3941]. The global initiatives stated in Section 1 ing service which has the following components: (i) Name Certi-
are also indicative of the realization of the need for new Internet cation Service maps a human readable name to a GUID; (ii) The
design approaches. In this section, we present the mobile node packet headers will have both a GUID and network addresses that
identication and handoff management approaches from the pro- will be protected by public key cryptography; and (iii) Location
jects supported by the aforementioned initiatives. In Section 5, Ta- Service maps a GUID to a complete network address that is used
bles 3 and 4 present the features of these protocols with respect to for routing [42]. This hierarchical addressing solution allows the
selected categories such as mobility scope, handoff management, routing design to address mobility and varying level of connectiv-
target network, mobile node address etc. The following projects ity considering mobile nodes and their associated applications as
and protocols are covered: MobilityFirst, eXpressive Internet rst-class Internet citizens.
Architecture (XIA), Virtual Mobility Domains (VMDs), Ambient
Networks, Designing Advanced network Interfaces for the Delivery 4.1.2. Handoff management in MobilityFirst
and Administration of Location independent, Optimized personal Handoff is handled using two mechanisms depending on the
Services (DAIDALOS), AKARI, Host Identity Protocol (HIP), Internet mobility characteristics of user. First, if a mobile node moves
Indirection Infrastructure (i3), Host Identity Indirection Infrastruc- slowly, the location service is updated to reect the new network
ture (Hi3), Locator Identier Separation Protocol (LISP), Mobility address. Second, to provide ongoing session continuity, a home
and Multihoming Supporting Identier Locator Split Architecture agent is deployed to redirect trafc to the new address of the node.
(MILSA), CARrier grade MEsh Networks (CARMEN), HURRICANE, MobilityFirst architecture deploys a delay-tolerant routing with in-
and MobileNAT. network storage [44,45]. In case of rapid host mobility, the net-
work can use late or repeated binding to resolve a GUID to a net-
4.1. MobilityFirst work address at different points along the route [43].

The MobilityFirst Project [42], funded by NSF FIA program, 4.2. eXpressive Internet Architecture
comprises eight universities from United States. The aim of the
project is to address mobility, multihoming, connectivity robust- eXpressive Internet Architecture (XIA) [46] is also funded by
ness, context-aware routing, and security challenges found in the NSF FIA program. XIA aims to preserve the strengths of current
68 H. Tuncer et al. / Computer Communications 36 (2012) 6379

Fig. 4. MobilityFirst protocol stack [43].

Internet Architecture while substantially improving security, and by NSF FIND. The FCT Internetworking model is derived from the
building in the ability to support evolving network functionality tiered structure that exists among Internet Service Providers (ISPs)
over time. XIA introduces a new protocol called XIP as a replace- and Autonomous Systems (ASes) to dene their business relation-
ment for IP which introduces new protocol stack, rich addressing ships. Granularity and modularity overcome the rigidity in the
and per-hop forwarding semantics [47]. tiered structure. Granularity is enabled through the denition of
network clouds [50] where a network cloud can be an ISP network,
4.2.1. Identity management in eXpressive Internet Architecture a point of presence (POP) in an ISP, an AS, or set of backbone, dis-
XIA denes hosts, services, contents, and administrative do- tribution or access routers. Modularity is introduced by decoupling
mains with unique eXpressive identiers (XIDs). The eXpressive the relationships between entities and using a nesting concept
identiers are mapped to locators using either a naming service [49].
e.g., Domain Name System (DNS) or based on a locally maintained VMD aims to provide scalable, user-centric mobility service
mapping to internal address e.g., Medium Access Control (MAC) where users can register to any mobility domain depending on
address for a bluetooth device. their mobility patterns. VMD supports both inter Autonomous Sys-
tem (macro) and intra Autonomous System (micro) mobility by
4.2.2. Handoff management in eXpressive Internet Architecture leveraging the tiered addressing, network cloud concept, and un-
The building block of XIA for mobile users is called Tapa [48]. XIA ique packet forwarding scheme introduced by the Floating Cloud
provides segment based routing where each segment can be very Tiered Internetworking model.
diverse, ranging from wireless access networks such as multi-hop
mesh networks, 802.11, and bluetooth to wired segments in the 4.3.1. Identity management in Virtual Mobility Domains
Internet or an enterprise network [48]. Each segment is responsible Each cloud in the architecture is identied with a tiered cloud
for delivering data from one end of the segment to the other end. If a address (CloudAddr) that is a function of the tier in which the net-
mobile node changes its administrative domain, the mobile nodes work cloud resides and its association to its parent network cloud.
eXpressive identier does not change in the new administrative do- For example, ISP C has CloudAddr 2.1:1 following a format Tier-
main. If there is any ongoing session, it is transmitted by XIP routers Value.ParentCloudID:MyCloudID where the ParentCloudID is inher-
in the old administrative domain to the mobile node. For the new ited from the upper tier cloud i.e. ISP A and the last number is
communications, a new mobile node address is created by prepend- the cloud ID.
ing the eXpressive identier of the new administration domain to VMD extends the cloud concept to virtual network clouds where
the eXpressive identier of the mobile node. a set of mobile nodes get addresses from the virtual network
clouds that are not physically constrained to the cloud. Virtual net-
4.3. Virtual Mobility Domains work cloud denes the boundary of a VMD where mobility service
is provided. To illustrate, VMD3 is deployed under ISP C in Fig. 5.
Virtual Mobility Domains (VMD) is designed to work with the The mobile nodes connected to the VMD3 roam within ISP C, AS1
Floating Cloud Tiered (FCT) Internetworking model [49], funded and AS2. When a VMD is deployed to upper tiers as VMD1 and
H. Tuncer et al. / Computer Communications 36 (2012) 6379 69

Fig. 5. The FCT Internetworking model is applied to ISPs and ASes in the Internet. Thick and dashed arrows show the provider-customer and peering relationships,
respectively. Dotted arrows show the VMDs deployment to upper tier clouds, hence three different mobility domains are created.

VMD2, the scope of the mobility domain expands to domain 1 and identify the downlink address for the mobile node. For instance,
2, respectively. A mobile node connected to VMD3 with an address forwarding base at ISP C, will have a mobile node entry that indi-
of 3.1:1:3 will get an address of 4.1:1:3:n, (where n can be a cates that the node is physically roaming in AS1, while the for-
unique integer value) in tier 4 [See Fig. 6]. warding base at Root Cloud1 has an entry that shows Cloud A as
the downlink.
4.3.2. Handoff management in Virtual Mobility Domains If the mobile node moves to another access router, its identity
VMD provides collaborative handoff management among the will be conrmed by the nearest common parent cloud between
network clouds. In Fig. 6, the AAA server located in ISP C is as- the old access router and the new access router. This cloud is called
sumed to have the proles of mobile nodes roaming under common anchor cloud (CAC). Common anchor cloud changes
VMD3. Each cloud has forwarding bases to track the physical loca- depending on the mobile node movement. The proxy AAA server
tion of the mobile nodes and proxy AAA servers to keep their pro- in the common anchor cloud will have the mobile node entry be-
les. When a mobile node connects to an access router (AR) e.g. cause of its registration to the old access router. To illustrate, if
AR1 in domain 3, AR1 asks for the conrmation of the mobile node the mobile node moves from AR1 to AR2, the common anchor
identity from the upper clouds. Eventually ISP C, where VMD3 is cloud will be Cloud A. Similarly if it moves to AR3, the common an-
connected, sends the response back to AR1. This response is trans- chor cloud will be Root Cloud1. When the mobile node moves be-
mitted through the intermediate clouds, i.e. Root Cloud1, and tween AR3 and AR4, ISP C, where VMD3 is deployed, becomes the
Cloud A. During the message transmission, these intermediate common anchor cloud and controls handoff management. Details
clouds copy the mobile node prole into their proxy AAA servers. of VMD intra-domain and inter-domain mobility support can be
Furthermore, each cloud adds an entry to its forwarding base to found in [51,52], respectively. The challenges for VMD are the addi-

Fig. 6. Detailed view of the domain 3 in Fig. 5.


70 H. Tuncer et al. / Computer Communications 36 (2012) 6379

tional cost of deploying forwarding bases and proxy AAA servers on network technology and addressing domain. The naming in Ambi-
the network and the its adoption in the current Internet ent Networks is illustrated in Fig. 7 adopted from [53].
Architecture.
4.4.2. Handoff management in Ambient Networks
4.4. Ambient Networks In Ambient Networks, handoff management is handled by sev-
eral subcomponents. When a mobile node enters a new network,
Ambient Networks [53], a large-scale collaborative project sup- mobility triggering management subcomponent collects and identi-
ported by the European Union sixth Framework Program, was set es triggers that include quality of service information, user policy
up for investigating future communication mechanisms. This pro- information, security information, and end-to-end path informa-
ject aimed to create a complete and coherent wireless network tion from different sources [54]. A handoff decision is based on
solution based on dynamic composition of networks through an the information retrieved from these triggers in conjunction with
instant establishment of inter-network agreements. The concept the multi radio resource management subcomponent. Next, a hand-
offers common control functions to a wide range of different appli- off mechanism to be used for the mobility event is selected from
cations and access technologies, enabling the integrated, scalable, the handoff toolbox [55]. Handoff mechanism is selected primarily
and transparent control of network capabilities. Even though the based on the types of endpoints that the mobility event affects
project is currently closed, all the developed concepts are available and the performance requirements for ow continuity. Finally, at
in the repository. the handoff execution stage, the mobile node changes its network
Ambient Networks consists of three distinct components. The point of attachment. Hence, the mapping between its network and
connectivity component abstracts existing network infrastructure application points of attachment is updated at the mobile node.
on top of which the Ambient Networks functionality resides. The The actual updated mapping is dened by the mobility protocol
interface component is for managing resources such as routers, that is being used to support the handoff. The network layer update
switches, relays; providing application and service independence; is performed by a mobility protocol such as MIP or HIP, selected
and enabling interaction between different network technologies. from the toolbox. This requires interactions with the multi-radio re-
Finally, the control space component provides naming framework, source management subcomponent to identify and modify affected
connectivity abstractions, security architecture, multi radio access, ows. This handoff execution process is controlled by handoff and
resource management, QoS, congestion control, mobility control locator management subcomponent which actually aggregates pro-
functions, smart multimedia routing, and transport protocol for cedures to include handoffs between access points within a single
service-specic overlay networks, context awareness function, dy- radio network, between different access technologies, between dif-
namic business agreement establishment and execution functions, ferent IP address spaces, multiple service provider domains, or
and plug-and-play support functions. application level handoffs. Furthermore, reachability management
subcomponent enables a correspondent node to initiate communi-
4.4.1. Identity management in Ambient Networks cation with a mobility endpoint regardless of its current location.
The proposed architecture adopts a layered naming model to Ambient Networks mobility control space and handoff toolbox
provide dynamic indirection between names, addresses, and iden- components enables the integration of many different standards
tities which are currently being used [53]. Ambient Networks of- such as GSM, UMTS, Mobile IP, Host Identity Protocol, SIP [56],
fers two connectivity abstractions: bearer and ow. Bearer Stream Control Transmission Protocol [57], distributed hash table
provides abstraction to application services, or a specic data ob- based handoff management and so on. This feature aims to bring
jects i.e. Session Initiation Protocol (SIP) services and web pages maximum mobility support between networks based on existing
through Ambient service interface which includes application and future mobility protocols.
point of attachment that can be compared with TCP/IP socket
API. Bearer also provides the end-to-end customized transport ser- 4.5. DAIDALOS
vice that supports all the functionality provided by the control
space. On the other hand, ow is abstraction of the connectivity Designing Advanced network Interfaces for the Delivery and
provided by the underlying technology where network nodes, mo- Administration of Location independent, Optimized personal Ser-
bile nodes, links, and paths reside. Flow is constrained to a single vices, DAIDALOS [58], is supported by European Union sixth

Fig. 7. Connectivity abstractions in ambient networks [53].


H. Tuncer et al. / Computer Communications 36 (2012) 6379 71

Framework Program and has 46 collaborators from industry and binding between IP and host ID tag happens at the kernel. The
academia. The DAIDALOS vision is to provide secure, personalized two communicating nodes at HIP are condent about each others
services built on seamlessly integrated heterogeneous network host ID tag after a four-way handshake, called base exchange. Base
technologies including cellular, satellite, broadcast, wired/wireless exchange employs DifeHellman authenticated key exchange
networks, and sensor networks. method, illustrated in Fig. 8. Then, these two HIP-aware end point
communicate with each other using their host ID tags in a secure
4.5.1. Identity management in DAIDALOS way by having encapsulated security payload (ESP) Security
DAIDALOS architecture supplies Virtual Identity (VID) Frame- Associations.
work in which a prole of an entity (single user or group of users)
may stem from contracts with different networks and services.
Subsets of this entity prole are called entity prole views, that 4.6.2. Handoff management in HIP
are the virtual IDs of the entity. A user can choose the virtual iden- HIP enables mobile node mobility across IPv4 and IPv6 [65,66].
tity service provider mapping. After virtual identity is conrmed HIP provides handoff management by splitting mobile node iden-
by the service provider, the entity gets an IP address tied to that tier and locator. Mobile node executes base exchange mecha-
virtual identity [59]. Virtual identity concept requires ID-Broker, nisms with correspondent node. Then two HIP-aware-end nodes,
that supplies entitys location to correspondent node and proxies correspondent node and mobile node, start communicating using
the request to the entity and ID-Manager. ID-Manager provides their host ID tags. Network layer connectivity goes over IP ad-
interface for creating, managing, and destroying virtual identities dresses but upper layers uses host ID tags. If the mobile node
by abstracting entitys physical interfaces. moves to a new network, its IP address changes. Even the transport
DAIDALOS also provides Virtual MAC infrastructure, which en- layer connectivity does not get affected because it relies on host ID
ables an entity to have two or more virtual identities bind to one tag, the correspondent node has to be informed about the mobile
physical interface to be able to access different providers. These nodes IP address change. Therefore, the mobile node executes
virtual identities can be expanded to the relationships between end-to-end three-way UPDATE signaling mechanism [67] in which
banks, governmental institutions, operators, and service providers. the mobile node sends UPDATE message to the correspondent
node with its new address and security association generated dur-
4.5.2. Handoff management in DAIDALOS ing the base exchange. Then, the correspondent node sends an UP-
DAIDALOS denes mobility as users can change their device DATE acknowledgement. The mobile node evaluates the UPDATE
while remaining connected to the Internet; the device can change acknowledgement and then echoes the nonce in the UPDATE
its point of connection; the session can be moved from one inter- acknowledgement message back to the correspondent node. After
face to another in the same device; or the source of the service the process is completed, the mobile node continues its communi-
can change during the session. DAIDALOS splits the architecture cation with the correspondent node.
into local and global domain to support mobility of a mobile node. HIP rendezvous servers (RVSs) [68] and HIP local rendezvous
In global domain, the mobile nodes macro-mobility is managed by servers [69] propose extensions to HIP by deploying rendezvous
MIPv6, or HIP while the mobile nodes micro-mobility in local do- servers for enhanced macro and micro-mobility management
main is managed with HMIPv6 and PMIPv6 with support of differ- respectively. Rendezvous server is an initial contact point for mo-
ent access technologies such as WLAN, WiMAX, 3GPP LTE and AD bile node and provides the HIP services to mobile node. Mobile
HOC/NEMO [60]. When the mobile node connects to a new net- node registers its new IP address and host ID tag to rendezvous ser-
work, depending on the mobility protocol, it gets a care-of address ver. Furthermore, mobile node uses IP address of rendezvous ser-
associated with the virtual identity that mobile node had. Depend- ver in base exchange with correspondent node. Then,
ing on the low or high privacy concerns, home address and care-of correspondent node sends packets to the IP address of rendezvous
address can be independent or dependent relatively. If high privacy server with the host ID tag of mobile node. The rendezvous server
is required, an entity receives a service via home address or care-of forwards the packet to mobile nodes actual IP address. If mobile
address which are associated with one virtual identity rather than node changes its location, hence IP address, the transport layer
several virtual identities. The dependency of mobile nodes care-of connectivity with correspondent node does not break down be-
address and home address to virtual identity causes an increased cause host ID tag stays same. At the network layer, correspondent
latency due to the fact that a new virtual identity needs to be boot- node continues to sends packets to IP address of rendezvous server.
strapped every time when a mobile node moves to a new domain Mobile node only needs to update its IP address at the rendezvous
and creates a new care-of address. Furthermore, care-of addresses server for rendezvous server to be able to direct packets to mobile
are by denition a locator of the point of attachment of the mobile nodes new location. [70] proposes improvements on the localized
node and hence creating a correlation between virtual identity and micro-mobility management by enhancing the functionality of Lo-
care-of address may be challenging. cal rendezvous server. HIP requires that all the changes happen in
the end-hosts which may potentially require signicant changes to
4.6. Host Identity Protocol (HIP) the current Internet structure and could lead to compatibility is-
sues for existing protocols and applications.
Host Identity Protocol [6163] created by Bob Moskowitz in
1999, is in the process of standardization by HIP Internet Engineer-
ing Task Force Working Group [64]. HIP offers a method of separat-
ing the end-point identier and locator roles of IP address to ease
mobility and multihoming as well as security.

4.6.1. Identity management in HIP


HIP separates the endpoint identier and locator roles of IP ad-
dress by introducing a one 128 bits long host ID tag (HIT). Host ID
tag is public key of a publicprivate key pair. HIP also creates thin
layer between the IP layer and the transport protocols. Applica-
tions are bound to host ID tag while IP still acts as a locator. The Fig. 8. HIP base exchange mechanism.
72 H. Tuncer et al. / Computer Communications 36 (2012) 6379

4.7. AKARI 4.8.2. Handoff management in i3


Lets rst analyze how i3 provides communication between the
AKARI [71], supported by Japanese government, aims for a fu- nodes. i3 deploys i3 servers that keep the node ID and address. If a
ture Internet Architecture to serve demands of solving societal mobile node wants to be reachable by a correspondent node, it
challenges and the conditions of future available technologies. sends a trigger which includes its ID and actual IP address (ID,
Some of the proposed approaches include ID/locator split, cross addr) to i3 servers. i3 servers store these triggers. If the correspon-
layer design, control layers with different time-scale behaviors, dent node wants to send a packet to the mobile node, it sends the
optical access switching and optical paths, overlay network, net- packet with the destination ID, (ID, data). The i3 server receives the
work virtualization, support for seamless movement across variety packets and then forwards the packets to the address of the
of wireless access technologies, and packet division multiple access matched ID owner. If the mobile node changes its network, it only
for wireless connectivity assuring quality of service. has to send a new trigger, which contains the same ID but the new
address (ID, new_addr) to i3 servers as illustrated in Fig. 9. Then i3
servers forward packets to the new address of the mobile node. If
4.7.1. Identity management in AKARI sender caches the address of i3 servers, it achieves fast packet
AKARI applies ID/locator split approach to give mobility and delivery. Zhuang et al. [74] build robust overlay architecture for
multihoming support to a larger number of users and devices mobility (ROAM) on top of i3 which controls the placement of i3
across dynamic heterogeneous environments. Node identiers servers in i3 to provide efcient routing, fast handoff, personal/ses-
can be totally independent of network topology and Internetwork- sion mobility, and location privacy. End-hosts can use off-line heu-
ing technology. Some identiers might have global scope while ristics to choose triggers that are stored at i3 servers close to either
others might be private and they might be tied to more than one itself or the correspondent node to avoid triangular routing prob-
locator. Application and transport layers use string or bit stream lem as well as location privacy. Location privacy can also be
to identify communicating nodes. Identiers have two versions: achieved if the mobile node advertises two triggers: (ID, ID) to
names and IDs. AKARI deploys identity management servers the i3 server near to correspondent node and (ID, addr) to the i3
(IMS) to assign locally unique names to the nodes. Each identity server near itself. During the movement, the mobile node can do
management server has a string identier such as mynet- soft handoff via multicasting triggers with new address before
work.com and a node receiving an address from identity manage- moving to the new network. i3 heavily relies on i3 servers and
ment server can have a name e.g. my.pc. Global names are hence the location of the servers should be considered carefully
created combining local name and identity management server to provide fast, reliable, and scalable mobility service.
name. On the other hand, ID is a hash value of a name. IDs are in-
cluded into packet header to identify the source and destination
4.9. Host Identity Indirection Infrastructure (Hi3)
nodes. Locators might be global or local and one locator might have
more than one IDs. Identity management server stores dynamic
Hi3 [7577] integrates HIP and i3 to provide better seamless
information such as mapping between names, IDs, and locators.
mobility support and security. Hi3 inherits mobility, multihoming,
Furthermore, AKARI also deploys a name mapping server (NMS)
and basic security mechanisms from HIP. Hi3 also deploys i3s se-
to store mapping between identity management server and loca-
cure integrated overlay rendezvous infrastructure as a control
tors which do not change so often. The ID layer is inserted between
plane.
network and transport layer. If a mobile node wants to communi-
cate with another node, rst it gets the ID of that node from iden-
tity management server and then gets the locator from location 4.9.1. Identity management in Hi3
management server. While the ID-locator mapping system is kept Hi3 uses IP addresses as locator for a mobile node. On the other
at the edge network to provide fast mobility support, global locator hand, the mobile node can have two identiers: host ID tag is used
information is kept at the core network to have scalable routing. as a public (server identier) and ID is used as private (lower
For transition purposes the rst 64 bits of IPv6 address is proposed naming layer) identier. Host ID tag is used to create association
to be used as an ID and the remaining bits can be used as a locator. between a client and a server and then the communication be-
tween server and client continues on private identiers. It results

4.7.2. Handoff management in AKARI


In AKARI, each local access network is connected to the Internet
via gateways. If a mobile node moves to another network, MIPv6 is
deployed to inform a correspondent node about the mobile nodes
locator address change. However, the transport layer connectivity
will not be affected from the mobile nodes mobility since it is tied
to the mobile nodes ID. One of the challenges for AKARI is the sup-
port of micro-mobility.

4.8. Internet Indirection Infrastructure (i3)

i3 [72] offers rendezvous-based overlay indirection service to


provide robust, scalable, and efcient system for handoff manage-
ment, multicast, and anycast communications on the Internet [73].

4.8.1. Identity management in i3


i3 uses IDs which are simple integer numbers and addresses
which are IPv4/v6 addresses depending on the network of a mobile
node. Fig. 9. The i3 handoff management mechanism and data communication scheme.
H. Tuncer et al. / Computer Communications 36 (2012) 6379 73

in performance increase and security improvement because corre- packets with its own address as a source and ETR1s address as des-
spondent node talks to the mobile node directly with the private tination address, and sends over the Internet.
trigger not the public one.
4.10.2. Handoff management in LISP
4.9.2. Handoff management in Hi3 LISP provides routing scalability, mobility, and multihoming
When a mobile node moves to a new network, it only sends support with the help of naming mobile node with endpoint iden-
triggers to a naming server to update its address, as in i3. This pro- tier and routing locator as well as deploying Map-Encap layer.
cess introduces less signaling overhead compared to HIP. Hi3 out- When a mobile node changes its connection, the mapping between
performs i3 and enhances exibility and security compared to HIP. the endpoint identier and the routing locator has to be changed.
This process will cause delay and packet drop [85]. For the other
4.10. The locator Identier Separation Protocol (LISP) mobility related issues, LISP gets benet of the IPv4/6 mobility
protocols.
The Locator Identier Separation Protocol (LISP) [78,79]
adopts a locator/ID split approach and a network-based map- 4.11. MILSA
and-encapsulate scheme [80] to solve naming/addressing, mobil-
ity, and multihoming challenges. LISP runs on IPv4 and IPv6 Mobility and Multihoming Supporting Identier Locator Split
architectures as an incremental protocol which can be used for Architecture, MILSA [86,87], adopts a hybrid design of ID/locator
IPv6 transition, improving trafc engineering, and reducing size split and coreedge separation concepts. The aim is to provide a
of core routing tables [81]. solution to the current Internets challenges such as renumbering,
routing scalability, mobility, and multihoming [88].
4.10.1. Identity management in LISP
In LISP, a mobile node has endpoint identier (EID) and routing 4.11.1. Identity management in MILSA
locator (RLOC). LISP deploys mobility anchor point servers [82] to In the MILSA communication environment, there are comput-
store endpoint identier routing locators mapping. It also intro- ers, mobile computing devices, rewalls, servers, humans, compa-
duces two network nodes: ingress tunnel router (ITR) and egress nies, departments, cities, and countries. MILSA denes realms as a
tunnel router (ETR). Ingress tunnel router performs endpoint iden- hierarchical group of these objects that logically belong to the
tier to routing locator look up and encapsulates the packet with same organization such as an administrative domain [88]. Each
the routing locators for both source and destination address elds of them has a name/ID, called hierarchical URI-like Identier
separately. Egress tunnel router decapsulates the accepted packet. (HUI), and locator. Each name/IDs is valid within a realm. URI-like
Furthermore, LISP Alternative Topology (LISP-ALT) [83] builds an Identier can be {Hashed Key}.JohnRoberts.mail.us.google.com
overlay logical topology running instance of Border Gateway which is 128-bits long. The rst part is the hash of public key that
Protocol (BGP) [84] typically over GRE tunnels to ease endpoint uniquely identies an object while the second part is hierarchical
identier to routing locator mapping process. LISP also inserts logical part. Locators are the IP addresses which are given by topo-
Map-Encap layer into network layer of OSI to ease the mapping logically aggregated physical network called zones. Hence locators
of endpoint identier with routing locator and encapsulation of are used for routing. MILSA deploys realm-zone bridging (RZB)
the packets with routing locator. LISP handles mapping at LISP - servers that perform the mapping with the identiers and locators.
ALT control plane and it handles encapsulation and tunneling at While an IP address can be used as a locator, they also propose a
data plane. hierarchical code based locator structure as an alternate locator ad-
For example, in Fig. 10, a mobile node with endpoint identier dress scheme in Fig. 11. However, they did not go into details of
2.0.0.2 wants to send a packet to a destination which has endpoint how legacy routers in the zone will operate according to this
identier 3.0.0.3. The packet is retrieved by ITR1. If ITR1 does not addressing.
know endpoint identier to routing locator mapping for 3.0.0.3, it Fig. 12 shows the format of the packets travel on the network.
encapsulates the packet with the outer header having source ad- The length of the addresses in this packet structure may not be
dress (routing locator of ITR1) and destination address, endpoint wireless friendly because wireless networks require less band-
identier 3.0.0.3. The data probe is sent into the LISP-ALT topology. width usage.
The packet follows the paths computed by BGP in the LISP-ALT
topology to ETR1. ETR1 decapsulates the packet and forwards the in- 4.11.2. Handoff management in MILSA
ner packet to 3.0.0.3. Then, ETR1 also sends a mobility anchor point If a mobile node changes a network, the mobile nodes locator
reply (MAP-reply) to ITR1 which tells that endpoint identier-rout- address changes while its name/ID does not change. MILSA inserts
ing locator mapping for 3.0.0.3 has ETR1 whose routing locator is URI-like Identier mapping sublayer between application layer
12.0.0.2. After ITR1 receives the MAP-reply, it encapsulates the and network layer which is similar to HIP as a concept. The mobile

Fig. 10. Naming and packet forwarding in LISP.


74 H. Tuncer et al. / Computer Communications 36 (2012) 6379

Service Provider Country Province Region End-host gateways) and micro-mobility (handoff between CARMEN access
Code Code Code Code Code points) of mobile nodes. Handoff management scheme provides
the following functionalities available at CARMEN access point,
Fig. 11. Hierarchical code based locator structure used by MILSA. CARMEN gateway, and core network: location registration/update,
ow control, handoff preparation, deciding on target CARMEN ac-
cess point, and execution. Before a mobile node is moving to a
new CARMEN access point, all possible new CARMEN access points
MAC Next Hop Dst Src Dst Src Payload are investigated and then the resources of the chosen CARMEN ac-
Locator Locator Locator HUI HUI cess point are reserved. Then, the mobile node connects to the new
CARMEN access point. If the new CARMEN access point is con-
Fig. 12. Data packet format used at MILSA. nected to a different CARMEN gateway, then the CARMEN gateway,
in addition to CARMEN access point, is involved in handling the
transfer of the ongoing session to the new network and handling
node informs realm-zone bridging servers about the locator the correspondent node information. CARMEN mainly presents
change. MILSA deploys an access zone router and a backbone zone the characteristics of network-based handoff management because
router that use Mobile IP protocols for network layer handoff man- of the high involvement of CARMEN access point and CARMEN
agement. The access zone router in the edge performs the identi- gateway in mobility management.
er/locator indirection, and gets the ID/locator mapping from the
realm-zone bridging servers. The access zone router routes the 4.13. HURRICANE
packets to the remote host through the backbone zone router [89].
HURRICANE [93] supports ubiquitous and optimal broadband
4.12. CARrier grade MEsh Networks CARMEN connectivity among cooperative networking environments. It aims
to provide an optimized handoff operation across various radio
CARMEN [90,91], CARrier grade MEsh Networks, aims to inte- cooperative networking environments such as GPRS/UMTS, Wi-Fi,
grate heterogeneous wireless network technologies in a multi- WiMAX, and Digital Video Broadcasting-Handheld.
hop fashion to provide scalable and efcient ubiquitous connectiv-
ity. CARMEN basically adopts a general IEEE 802.21 architecture 4.13.1. Identity management in HURRICANE
but differs by targeting heterogeneous mesh networks in a media HURRICANE does not implement protocol stacks from scratch;
independent manner [92]. IEEE 802.21 focuses only on handoffs instead it species and modies mechanisms that allow the exist-
between heterogeneous technologies. The CARMEN cross-layer ap- ing protocols to operate in an efcient way. Therefore, the architec-
proach is composed of a MAC abstraction sub-layer and a mesh ture does not propose a new naming/addressing scheme. It uses
functions sub-layer. The MAC abstraction sub-layer is located IPv4/IPv6 addressing scheme.
between the subnet layer and the routing layer, in order to hide
technology specic issues at the low layers. The Mesh functions 4.13.2. Handoff management in HURRICANE
sub-layer consists of routing, capacity handling, handoff manage- HURRICANE provides vertical handoff using the concept of IEEE
ment, self-conguration, and monitoring modules. 802.21 [94] and enhances it inspiring with IEEE 1900.4 [95]. HUR-
CARMEN requires a mobile node to be 802.21 compatible to use RICANE deploys vertical handoff controllers (VHC), context infor-
the services of the CARMEN mesh. CARMEN mesh point (CMP) is a mation collectors (CIC), and handoff managers (HM) both at
node that is equipped with CARMEN capabilities. CARMEN access mobile node and network side. Furthermore, the media indepen-
point (CAP) is a CARMEN mesh point with the capability to provide dent handoff service of HURRICANE hides the technological differ-
the mobile nodes access to the CARMEN mesh. Typically, CARMEN ences among radio access networks. These components
access points have one or more access radio interfaces dedicated collaboratively give mobility decision according to a users quality
for the mobile nodes use, and thus these interfaces do not carry of service requirements, policies, network resources, and network
trafc to other CARMEN mesh points. CARMEN gateway (CGW) is condition. Then, these components orchestrate the legacy handoff
a CARMEN mesh point that also provides connectivity to the net- management protocols such as MIPv4, MIPv6, Fast MIPv6, HMIPv6,
work providers core or backbone network. CARMEN gateway is lo- PMIPv6, and so on. HURRICANE requires new capabilities and tech-
cated at the boundary between the core network and the CARMEN nologies on wired and wireless nodes. Hence, the seamless adop-
mesh. tion of HURRICANE is challenging.

4.12.1. Identity management in CARMEN 4.14. MobileNAT


CARMEN requires unique 48-bits identiers per node and per
interface. CARMEN provides media independent handoff function MobileNAT [96] supports micro mobility and macro mobility
to support mobility. In CARMEN, a mobile node gets two addresses. across heterogeneous networks. MobileNAT deploys network ad-
The rst address is network access identier encoded IP address i.e. dress translation (NAT) devices that translate internal private ad-
IPv4 or IPv6 address or domain name for layer 3 communication. dress of a mobile node to an external globally unique IP address
The second address is network access identier encoded link layer and vice versa. MobileNAT offers following benets: the use of pri-
address for layer 2 communications. Each interface ID is created vate addressing in large public networks, use of heterogeneous
converting the 48-bits interface ID into an extended unique identi- (IPv4/IPv6) addressing schemes, exibility in frequent changes in
er, 64-bits long. This interface ID is then used to generate the link addressing, and easy policy enforcement. MobileNAT architecture
local address via the IPv6 stateless address auto conguration introduces an anchor node (AN), a mobility manager (MM), and a
mechanism dened in [34]. DHCP server and relays.

4.12.2. Handoff management in CARMEN  Anchor node: A gateway router with network address trans-
The hierarchical positioning of CARMEN wired nodes provides lation (NAT) support or a separate NAT device connected to
easy management of macro-mobility (handoff between CARMEN a traditional router.
H. Tuncer et al. / Computer Communications 36 (2012) 6379 75

Table 1 the packet to the correspondent node. Advantage of the


Address translation done by MobileNAT device. scheme is less processing overhead while disadvantage is
Ap Av Policy 1 Policy 2 additional header overhead and increased packet size.
Case 1 Private Private Ap ! AAN Ap ! AAN
Case 2 Private Public Ap ! Av Ap ! AAN One of the issues that MobileNAT needs to address is how state-
Case 3 Public Private Ap ! AAN Ap ! AAN less autoconguration of IPv6 addresses will be supported.
Case 4 Public Public Ap ! Av Ap ! AAN

4.14.2. Handoff management in MobileNAT


When a mobile node changes domain, Ap is replaced with a new
 Mobility manager: A mobility manager signals mobility
one, however, Av stays the same. Home-NAT forwards the packets
events to the anchor node. A mobility manager may be co-
to the Visited-NATs external address. Visited NAT transmits pack-
located with the DHCP server.
ets to the mobile nodes new physical address. MobileNAT may ap-
 DHCP server and relays: DHCP assigns Av (host identication)
ply address translation and tunneling (between Home-NAT and
and Ap (physical address for routing) IP addresses to a mobile
Visited-NAT) for inter-domain movement of the mobile node.
node when the mobile node moves to a new subnet. Each
The trafc from Visited-NAT to the correspondent node can be
subnet has a DHCP relay that forwards the DHCP requests
either (i) direct, in which case the Visited-NAT fakes its source ad-
to DHCP servers at each domain. These DHCP relays are
dress as that of the Home-NAT, or (ii) it can always reserve proxies
either co-located with the router or separate in the network.
through the Home-NAT (via tunnel or translation method). When
the mobile node moves in a domain, Destination-NAT rules at
MobileNAT also provides a thin software layer, called shim-
the anchor node and the mobile node are appropriately altered
layer, between IP layer and network interface driver in the client
for the new Ap . When the mobile node enters to a new NAT, it gets
machine to maintain the translation rules as stated in Table 1.
new Av but keeps the old one until all old sessions are closed.
4.14.1. Identity management in MobileNAT
MobileNAT aims to solve the difculties come with using IP ad- 5. Discussion
dress to identify a mobile node and to route data packets to the
mobile node. MobileNAT provides use of two addresses for mobile In this section, we provide a comparative analysis of the iden-
node and tunneled packet forwarding. tity and handoff management approaches adopted by the Mobile
IP protocols and proposed next generation mobility solutions.
 Use of two addresses: A mobile node has Av (virtual IP for host Table 2 summarizes the Mobile IP protocols while Tables 3 and 4
identication) and Ap (physical IP for routing) addresses. An highlight the features of next generation mobility solutions. The
anchor node does address translation for source and destina- protocols and schemes have been compared using a unied plat-
tion addresses. A correspondent node sends packets with form which includes the attributes such as infrastructure needs,
destination address, Av . The anchor node translates Av to mobile address related features, and handoff management features
Ap . Therefore, NAT is transparent to the correspondent node. (see Appendix for complete list).
The mobile node addressing is subject to two policies with
different address combinations of Av and Ap as stated in 5.1. Discussion of Mobile IP protocols
Table 1. There are four different address combinations. There
are two policies can be applied by the anchor node: Policy1: This section provides the discussion of MIPv4, MIPv6, HMIPv6,
If possible, expose Av external to domain. Policy2: Never and PMIPv6 focusing on their advantages and disadvantages in
expose the mobile nodes Av . providing identity and handoff management. Table 2 provides a
 Tunneling: IP tunneling is used to forward the packets from a comparison chart highlighting the features of each Mobile IP
mobile node to an anchor node. The outer IP header has protocol.
source address Ap , whereas inner IP header has Av . The Deploying macro-mobility protocols i.e. MIPv4 and MIPv6 for
anchor node strips off the outer header before forwarding mobile nodes movement within a single autonomous system do-

Table 2
Comparison of MIPv4, MIPv6, FMIPv6, HMIPv6, and PMIPv6.

Category MIPv4 MIPv6 FMIPv6 HMIPv6 PMIPv6


Mobility scope Global Global Global/Local Local Local
Mobility management Host-based Host-based Host-based Host-based Network-based
Network architecture Flat Flat Flat Hierarchical Hierarchical
Target network IP IP IP IP IP
Operating layer L3 L3 L3 L3 L2 & L3
Required infrastructure HA & FA HA HA & AP AR & MAP LMA & MAG
MN modication Yes Yes Yes Yes No
Router advertisement Broadcast Broadcast Broadcast Broadcast Unicast
Addressing model Shared-prex Shared-prex Shared-prex Shared-prex Per-MN-prex
MN address HoA HoA HoA RCoA & LCoA CoA
Address type IPv4 IPv6 IPv6 IPv6 IPv6
Address length (bits) 32 128 128 128 128
Address change Yes Yes Yes Yes No
Address assigned by HA HA HA MAP LMA
Tunneling Inter-AS Inter-AS Intra-AS Intra-AS Intra-AS
Duplicate address detection Yes Yes Yes Yes No
Route optimization No Yes No Yes Yes
MN tunnel overhead Yes Yes Yes Yes No
Handover latency Bad Bad Good Moderate Good
76 H. Tuncer et al. / Computer Communications 36 (2012) 6379

Table 3
Comparison of MobilityFirst, XIA, VMD, Ambient Networks, DIPLOMAS, and HIP.

Category MobilityFirst XIA VMD Ambient Networks DAIDALOS HIP


Mobility scope Global Global Global Global/local Global/local Global/local
Mobility management Network Network Network Host Host
Network architecture Flat Flat Tiered Flat Flat/Hierarchical Flat
1

Target network IP IP FCT IP & cellular IP IP


Operating layer L3&L4 TAPA L2&L3 L1 - L5 L2 - L5 HI
Required infrastructure GDTN routers XIP routers VMD interfaces & components ID Manager &Broker RVS
Mobility protocol nna nna VMD MIP, HIP, SIP, GSM & UMTS MIP, HMIPv6, HIP & PMIPv6 MIP
MN modication Yes Yes Yes No No Yes
MN address GUID XID Tiered Flow & Bearer VID HIT & IP
Address type String Sring/IP Numeric Abstraction IPv6 IPv4/IPv6
Address length (bits) Dynamic 160 Dynamic Varies 128 32/128
Address change No No No Yes Yes Yes
Address assigned by Naming Service Naming Service VMD interfaces ID-manager RVS
Tunneling No No No Inter + Intra-AS

Depends on the mobility protocol used by the architecture. However, 1[69] proposes hierarchical HIP architecture.

Table 4
Comparison of AKARI, i3, Hi3, LISP, MILSA, CARMEN, HURRICANE and MobileNAT.

Category AKARI i3 Hi3 LISP MILSA CARMEN HURRICANE MobileNAT


Mobility scope Global/local Global/local Global/local Global/local Global/local Global/local Global/local Global/local
Mobility management Host Host Network Network Host Network Host Network
Network architecture Hierarchical Flat Flat Flat Hierarchical Hierarchical Hierarchical Flat
Target network IP & cellular IP IP IP IP Mesh Mesh Mesh
Operating layer ID L3 Overlay HI & L3 Overlay Man-encap HUI L2 & L3 L2 & L3 L3 & SHIM
Required infrastructure IMS & NMS i3 servers Rendezvous New network RZB & Zone CAP & CGW CIC & HM AN & MM
Mobility protocol MIP ROAM Hi3 MIP MIP CARMEN (H/P) MIPv6 IPv6
MN modication Yes Yes Yes No Yes Yes Yes Yes
MN address ID, name & locator ID & IP HIT, ID & IP EID & RLOC HUI & locator IDs IP IP
Address type String/bitstream IPv4/IPv6 IPv4/IPv6 IPv4/IPv6 string & IP IPv6 IPv4/IPv6 IPv6
Address length (bits) Varies 32 & 128 32 & 128 128 varies 48 & 128 32 & 128 128
Address change Yes Yes Yes Yes Yes Yes Yes
Address assigned by IMS AR & i3 Rendezvous New Network RZB & Zone CAP & CGW AN
Tunneling Intra-AS No Inter-AS Inter-AS No No Optional

Depends on the mobility protocol used by the architecture.

For acronyms, please refer to the sections covering the current and future mobility solutions.

main may bring signaling overhead and handoff latency as the or a combination. They aim to provide all the time connectivity
binding update messages use up wireless bandwidth and home regardless of the networking technology.
network or correspondent node might be far away from mobile The most popular identity management approach is the ID/loca-
nodes current network [97]. However, when micro-mobility pro- tor separation approach where a mobile nodes physical location
tocols i.e. HMIPv6 and PMIPv6 are deployed for mobile nodes in- and actual ID are different. Physical locator of the mobile node
tra-AS movement, they bring lesser signaling overhead and lower can be an IP address (DAIDALOS, i3, and Hi3), or routing locator
handoff latency because the routing tables at the home agent do resembling the router that mobile node is connected to (LISP and
not change as mobile nodes address does not change within the MILSA). The mobile node, the Internet content or a mobile user
domain. [37,98100]. can be identied with human-readable string (MobilityFirst and
HMIPv6, introduces scalability and also incorporates hierarchy XIA) or with specially encrypted ID-tags (HIP). Having content or
in the at IP structure for efcient handoff management. PMIPv6 mobile users being identied separately from the routing layer
does not require any software installation on mobile nodes be- help content-aware communication and user-centric mobility.
cause it follows a network-based handoff management approach. However, mapping and naming servers have to be located in the
It can also work without depending on any existing macro-mobil- network and the communication of other nodes with these servers
ity protocol. Therefore, PMIPv6 accommodates changing technol- have to be regulated via protocols to have easy, fast, reliable and
ogy and market requirements better. This characteristic of the secure communication.
protocol can accelerate the deployment of PMIPv6 [36]. In PMIPv6, In handoff management, the popular mechanism is providing
mobile node uses less computing resources, encounters less wire- an integration framework for different network technologies and
less channel access delay and less wireless transmission delay as handoff management protocols to operate together (Ambient
handoff is managed between mobility access gateway and the local Networks, DAIDALOS, and Akari). Integration frameworks could
mobility anchor [101,102]. be very feasible for next generation networking if they are modular
and extensible in allowing adaptation of new unforeseen mobility
solutions. In another approach, gateways are provided to hide the
5.2. Discussion of next generation mobility solutions technological differences between the access networks (CARMEN
and HURRICANE). Each access network connects to the Internet
In this section, we highlight the identity and handoff manage- via the gateways and handoff related messaging is generated
ment methodologies of the next generation mobility solutions between gateways and other wired mobility agents. Another
targeting current IP networks, cellular networks, mesh networks approach in handoff management is deploying an overlay infra-
H. Tuncer et al. / Computer Communications 36 (2012) 6379 77

structure (HIP, i3, Hi3, and LISP-ALT). This approach requires a References
strong tie between the identity scheme and the handoff manage-
ment protocol. [1] National science foundation future internet design initiative. <http://
www.nets-a.net/>.
[2] National science foundation future internet architecture project. <http://
6. Conclusion www.nets-a.net/>.
[3] European future internet portal. <http://www.future-internet.eu/>.
[4] Asia future internet forum. <http://www.asia.net/>.
Mobile Internet usage continues to increase at a dramatic pace. [5] New generation network research center. <http://www2.nict.go.jp/w/w100/
In this study, a survey of identity and handoff management index-e>.
[6] Global environment for network innovations (geni). <http://www.geni.net/>.
solutions in the next generation mobility architectures and proto- [7] Future internet research and experimentation. <http://cordis.europa.eu/fp7/
cols is presented. In addition, a qualitative comparison of Mobile IP ict/re/>.
protocols and next generation mobility protocols on a uniform [8] I. Akyildiz, J. Xie, S. Mohanty, A survey of mobility management in next-
generation all-ip-based wireless systems, Wireless Communications, IEEE 11
platform is provided. The goal of this survey is to provide an unbi-
(4) (2004) 1628.
ased report on all solutions current and future. Along with the [9] D. Saha, A. Mukherjee, I. Misra, M. Chakraborty, Mobility support in ip: a
several approaches adopted to overcome the current challenges survey of related protocols, Network, IEEE 18 (6) (2004) 3440.
[10] P. Reinbold, O. Bonaventure, Ip micro-mobility protocols, Communications
in identity and handoff management, the future Internet is
Surveys Tutorials, IEEE 5 (1) (2003) 4057.
envisioned to be open and receptive to different approaches based [11] D.H. Jun-Zhao Sun, J. Sauvola, Mobility management techniques for the next
on the future needs. The chosen approach will be dependent on generation wireless networks, APOC, Asia-Pacic optical and wireless
several factors such as user mobility characteristics, type of communications, in: Society of Photo-Optical Instrumentation Engineers,
Bellingham, WA, USA, vol. 2001, 2001, pp. 155166.
applications and QoS provisions etc. Our future work is focused [12] I. AI-Surmi, M. Othman, B.M. Ali, Review on Mobility Management for Future-
in this direction. IP-Based Next Generation Wireless Networks (2010) 989994.
[13] L.J. Zhang, L. Zhang, L. Marchand, S. Pierre, A survey of ip layer mobility
management protocols in next generation wireless networks, Next
Acknowledgement Generation Mobile Networks and Ubiquitous Computing (2010) 7993.
[14] J. Xie, X. Wang, A survey of mobility management in hybrid wireless mesh
networks, Network, IEEE 22 (6) (2008) 3440.
Authors would like to thank anonymous reviewers for their
[15] F. Abduljalil, S. Bodhe, A survey of integrating ip mobility protocols and
valuable feedback. mobile ad hoc networks, Communications Surveys Tutorials, IEEE 9 (1) (2007)
1430.
[16] Y.P. Yang Xiao, Kin K. Leung, X. Du, Architecture, mobility management, and
Appendix A. The denitions of the categories used at Tables 24 quality of service for integrated 3G and WLAN networks, Wireless
Communications and Mobile Computing 5 (7) (2005) 805823.
Mobility scope: The type of a mobile node mobility that the pro- [17] G. Lampropoulos, N. Passas, L. Merakos, A. Kaloxylos, Handover management
architectures in integrated WLAN/cellular networks, Communications
tocol deals with. i.e. macro or micro mobility. Surveys Tutorials, IEEE 7 (4) (2005) 3044.
Mobility management: Shows whether a mobile node is involved [18] A. Rahaman, J. Abawajy, M. Hobbs, Taxonomy and survey of location
in mobility management related signaling or not. If the mobile management systems, in: 6th IEEE/ACIS International Conference on
Computer and Information Science (ICIS 2007), 2007, pp. 369374.
node contributes to the part of the mobility management related [19] T. Miyata, Y. Koga, P. Madsen, S.-I. Adachi, Y. Tsuchiya, Y. Sakamoto, K.
activities, and then its called host-based mobility management. Takahashi, A survey on identity management protocols and standards, IEICE
Otherwise, network-based mobility management. Trans. Inf. Syst. E89-D (2006) 112123.
[20] P. Zhang, A. Durresi, L. Barolli, A survey of internet mobility, in: International
Network architecture: If a new architecture or protocol provides Conference on Network-Based Information Systems (NBIS 09 2009), 2009,
hierarchy between the new network nodes and there is a collabo- pp. 147154.
ration on mobility management, then this architecture is called [21] M. Conti, S. Chong, S. Fdida, W. Jia, H. Karl, Y.-D. Lin, P. Mhnen, M. Maier, R.
Molva, S. Uhlig, M. Zukerman, Research challenges towards the future
hierarchical. Otherwise, the architecture is called as at. internet, Computer Communications 34 (18) (2011) 21152134.
Target network: The type of network that the protocol aims to [22] J. Roberts, The clean-slate approach to future internet design: a survey of
provide mobility management. research initiatives, Annals of Telecommunications 64 (2009) 271276.
[23] Future Internet Assembly 2011: Achievements and Technological Promises,
Operating layer: The OSI layer(s) that the specied protocol
2011.
operates on. [24] N. Ekiz, T. Salih, S. Kucukoner, K. Fidanboylu, An overview of handoff
Required infrastructure: New network nodes are required by the techniques in cellular networks, International Journal of Information
Technology, 2 (2005).
specied protocol or architecture to be able to operate properly.
[25] A. De La Oliva, A. Banchs, I. Soto, T. Melia, A. Vidal, An overview of ieee 802.21:
Mobility protocol: The name of the mobility protocol used in the media-independent handover services, IEEE Wireless Communications 15 (4)
specied scheme. (2008) 96103.
MN modication: Whether the specied architecture or protocol [26] C. Perkins, IP Mobility Support for IPv4, RFC 3344, Proposed Standard,
obsoleted by RFC 5944, updated by RFC 4721, August 2002.
requires modication on a mobile node or not to be able to operate [27] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6, RFC 3775 (Proposed
properly. Standard) (2004).
MN address: Presents the general name given to a mobile nodes [28] N. Moore, Optimistic duplicate address detection (DAD) for IPv6, RFC 4429
(Proposed Standard) (2006).
address. [29] C. Perkins, IP Encapsulation within IP, RFC 2003, Proposed Standard, updated
Address type: Presents the type of the mobile nodes address. by RFC 3168, October 1996.
Address length: The length of the mobile nodes address in bits. [30] H. Levkowetz, S. Vaarala, Mobile IP traversal of network address translation
(NAT) devices, RFC 3519 (Proposed Standard) (2003).
Address change: Whether the address received by a mobile node [31] J. Arkko, C. Vogt, W. Haddad, Enhanced Route Optimization for Mobile IPv6,
in the protocol domain changes or not when the mobile node RFC 4866 (Proposed Standard) (2007).
moves to new network. [32] R. Koodli, Mobile IPv6 fast handovers, RFC 5568 (Proposed Standard) (2009).
[33] H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier, Hierarchical mobile IPv6
Address assigned by: The name of the node or agent in the net-
(HMIPv6) mobility management, RFC 5380 (Proposed Standard) (2008).
work that assigns an address to a mobile node. [34] S. Thomson, T. Narten, T. Jinmei, IPv6 stateless address autoconguration, RFC
Tunneling: Shows if tunneling used for the data communication 4862 (Draft Standard) (2007).
[35] Network-based localized mobility management IETF working group. <http://
between a mobile node and a correspondent node. If yes, then
datatracker.ietf.org/wg/netlmm/charter/>.
where the tunneled communication is applied, inter-AS or intra- [36] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, Proxy mobile
AS. IPv6, RFC 5213 (Proposed Standard) (2008).
78 H. Tuncer et al. / Computer Communications 36 (2012) 6379

[37] K.-S. Kong, W. Lee, Y.-H. Han, M.-K. Shin, H. You, Mobility management for [65] T. Henderson, End-host mobility and multihoming with the host identity
all-ip mobile networks: mobile ipv6 vs. proxy mobile ipv6, Wireless protocol, Internet Draft (2006).
Communications, IEEE 15 (2) (2008) 3645. [66] P. Nikander, J. Ylitalo, J. Wall, Integrating security, mobility, and multi-
[38] J. Korhonen, V. Devarapalli, Local mobility anchor (LMA) discovery for proxy homing in a hip way, in: NDSS 2003, Proceedings of the Network and
mobile IPv6, RFC 6097 (Informational) (2011). Distributed Systems Security Symposium, 2003, pp. 8799.
[39] I. Al-Surmi, M. Othman, B. Ali, Review on mobility management for future-ip- [67] P. Nikander, T. Henderson, C. Vogt, J. Arkko, End-host mobility and
based next generation wireless networks, in: The 12th International multihoming with the host identity protocol, RFC 5206 (Experimental),
Conference on Advanced Communication Technology 2010, (ICACT), vol. 2, April 2008.
2010, pp. 989994. [68] J. Laganier, Host identity protocol (HIP) Randezvous extention, Internet Draft
[40] J.-H. Lee, T. Ernst, T.-M. Chung, Cost analysis of ip mobility management (2005).
protocols for consumer mobile devices, IEEE Transactions on Consumer [69] S. Novaczki, L. Bokor, S. Imre, Micromobility support in hip: survey and
Electronics 56 (2) (2010) 10101017. extension of host identity protocol, in: IEEE Mediterranean 2006
[41] J.-I. Kim, H. Jung, S.J. Koh, Distributed mobility control for mobile-oriented Electrotechnical Conference (MELECON 2006), 2006, pp. 651654.
future internet environments, in: 2011 International Conference on ICT [70] M. Muslam, H. Chan, N. Ventura, Host identity protocol extension supporting
Convergence (ICTC), 2011, pp. 342347. localized mobility management, in: IEEE 2011 Consumer Communications
[42] Mobilityrst future internet architecture project. <http://mobilityrst. and Networking Conference (CCNC), 2011, pp. 106110.
winlab.rutgers.edu/>. [71] N. I. of Information, C.T.N. of Japan, New generation network architecture
[43] S.C. Nelson, G. Bhanage, D. Raychaudhuri, Gstar: generalized storage-aware akari conceptual design v 1.1, Tech. rep., October 2008, <http://akari-
routing for mobilityrst in the future mobile internet, in: Proceedings of the project.nict.go.jp/eng/index2.htm>.
sixth international workshop on MobiArch, MobiArch 11, ACM, New York, [72] i3 project. <http://i3.cs.berkeley.edu/>.
NY, USA, 2011, pp. 1924. [73] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, S. Surana, Internet indirection
[44] S. Paul, R. Yates, D. Raychaudhuri, J. Kurose, The cache-and-forward network infrastructure, IEEE/ACM Transactions on Networking 12 (2) (2004) 205218.
architecture for efcient mobile content delivery services in the future [74] S. Zhuang, K. Lai, I. Stoica, R. Katz, S. Shenker, Host mobility using an internet
internet, in: Innovations in NGN: Future Network and Services, 2008. K-INGN indirection infrastructure, Wireless Network 11 (2005) 741756.
2008. First ITU-T Kaleidoscope Academic Conference, 2008, pp. 367374. [75] A. Gurtov, D. Korzun, A. Lukyanenko, P. Nikander, Hi3: An efcient and secure
[45] L. Subramanian, M. Caesar, C.T. Ee, M. Handley, M. Mao, S. Shenker, I. Stoica, networking architecture for mobile hosts, Computer Communications 31
Hlp: a next generation inter-domain routing protocol, SIGCOMM Comput. (2008) 24572467.
Commun. Rev. 35 (2005) 1324. [76] D. Korzun, A. Gurtov, On scalability properties of the hi3 control plane,
[46] Expressive internet architecture. <http://www.cs.cmu.edu/xia/>. Computer Communication 29 (2006) 35913601.
[47] A. Anand, F. Dogar, D. Han, B. Li, H. Lim, M. Machadoy, W. Wu, A. Akella, D. [77] P. Nikander, J. Arkko, Host identity indirection infrastructure (Hi3), Internet
Andersen, J. Byersy, S. Seshan, P. Steenkiste, Xia: An architecture for an Draft (2004).
evolvable and trustworthy internet, Technical Report CMU-CS-11-100, [78] Locator/id separation protocol (lisp) ietf work group. <http://www.ietf.org/
Department of Computer Science, Carnegie Mellon University, February 2011. dyn/wg/charter/lisp-charter.html>.
[48] F. R. Dogar, P. Steenkiste, Segment based inter-networking to accommodate [79] D. Farinacci, Locator/ID separation protocol LISP, Internet Draft (2009).
diversity at the edge, CMU CSD Technical Report, CMU-CS-10-104, [80] R. Hinden, New scheme for internet routing and addressing (ENCAPS) for
Department of Computer Science, Carnegie Mellon University, February 2010. IPNG, RFC 1955 (Informational), June 1996.
[49] Y. Nozaki, H. Tuncer, N. Shenoy, A tiered addressing scheme based on a [81] D. Lewis, Interworking LISP with IPv4 and IPv6, Internet Draft (2009).
oating cloud internetworking model, in: Proceedings of the 12th [82] V. Fuller, LISP MAP server, Internet Draft (2009).
International Conference on Distributed Computing and Networking, [83] V. Fuller, LISP alternative topology (LISP+ALT), Internet Draft (2009).
ICDCN11, Springer-Verlag, Berlin, Heidelberg, 2011, pp. 382393. [84] Y. Rekhter, T. Li, A Border Gateway Protocol 4 (BGP-4), Proposed Standard,
[50] N. Shenoy, M. Yuksel, A. Gupta, K. Kar, V. Perotti, M. Karir, Raider: Responsive 1995.
architecture for inter-domain economics and routing, in: 2010 IEEE, [85] D. Meyer, The locator identier separation protocol (lisp), Cisco-The Internet
GLOBECOM Workshops (GC Wkshps), 2010, pp. 321326. Protocol 11, 2008.
[51] H. Tuncer, Y. Nozaki, N. Shenoy, Virtual domains for seamless user mobility, [86] J. Pan, S. Paul, R. Jain, M. Bowman, Milsa: A mobility and multihoming
Proceedings of the 9th ACM International Symposium on Mobility supporting identier locator split architecture for naming in the next
Management and Wireless Access, MobiWac11, ACM, New York, NY, USA, generation internet, in: 2008 IEEE Global Telecommunications Conference,
2011. IEEE GLOBECOM, 2008, pp. 16.
[52] H. Tuncer, Y. Nozaki, N. Shenoy, Virtual mobility domains a mobility [87] J. Pan, S. Paul, R. Jain, X. Xu, Hybrid transition mechanism for milsa
architecture for the future internet, in: 2012 IEEE International Conference on architecture for the next generation internet, in: IEEE 2009 GLOBECOM
Communications (ICC), 2012. Workshops, 2009, pp. 16.
[53] N. Niebert, M. Prytz, A. Schieder, N. Papadoglou, L. Eggert, F. Pittmann, C. [88] R. Jian, Internet 3.0: Ten problems with current internet architecture and
Prehofer, Ambient networks: a framework for future wireless solutions for the next generation, in: IEEE 2006 Military Communications
internetworking, in: 2005 IEEE 61st Vehicular Technology Conference, Conference, MILCOM 2006, 2006, pp. 19.
2005. VTC 2005-Spring. vol. 5, 2005, pp. 29692973. [89] J. Pan, R. Jain, S. Paul, M. Bowman, X. Xu, S. Chen, Enhanced milsa architecture
[54] R. Calvo, A. Surtees, J. Eisl, M. Georgiades, Mobility management in ambient for naming, addressing, routing and security issues in the next generation
networks, in: 2007 IEEE 65th Vehicular Technology Conference, VTC2007- internet, in: IEEE International Conference on Communications, ICC 09, 2009,
Spring, 2007, pp. 894898. pp. 16.
[55] J. Laganier, A.R. Prasad, Interactions of ambient networks composition and [90] Carmen, carrier grade mesh networks. <http://www.ict-carmen.eu/>.
mobility toolbox frameworks, Proceedings of the 3rd International [91] P. Patras, Carmen, ratied architecture deliverable, Tech. Rep. D1.2., January
Conference on Mobile Technology, Applications & Systems, Mobility 06, 2009.
ACM, New York, NY, USA, 2006. [92] IEEE draft standard for local and metropolitan area networks: media
[56] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, independent handover services, IEEE Unapproved Draft Std P802.21/D14,
M. Handley, E. Schooler, SIP: Session Initiation Protocol, RFC 3261 (Proposed September 2008.
Standard), updated by RFCs 3265, 3853, 4320, 4916, 5393, 5621, 5626, 5630, [93] H. Marques, J. Rodriguez, P. Marques, D3.2: Design of optimized handover
5922, 5954, 6026, 6141, June 2002. operations for heterogeneous wireless systems, Tech. rep., January 2008,
[57] R. Stewart, Stream Control Transmission Protocol, RFC 4960 (Proposed <http://www.ict-hurricane.eu/>.
Standard), updated by RFC 6096, September 2007. [94] IEEE standard for local and metropolitan area networks part 21: media
[58] Daidalos, designing advanced network interfaces for the delivery and independent handover, IEEE Std 802.21-2008, 2009, pp. 1301.
administration of location independent, optimised personal services, 2012. [95] IEEE standard for architectural building blocks enabling network-device
<http://www.ist-daidalos.org/>. distributed decision making for optimized radio resource usage in
[59] E. Papadopoulou, S. McBurney, N. Taylor, M.H. Williams, Linking privacy and heterogeneous wireless access networks, IEEE Std 1900.4-2009, 2009, pp.
user preferences in the identity management for a pervasive system, in: 1119.
Proceedings of the 2008 IEEE/WIC/ACM International Conference on Web [96] M. Buddhikot, A. Hari, K. Singh, S. Miller, Mobilenat: a new technique for
Intelligence and Intelligent Agent Technology Vol. 01, IEEE Computer mobility across heterogeneous address spaces, Mobile Networks and
Society, Washington, DC, USA, 2008, pp. 192195. Applications 10 (2005) 289302.
[60] S. Sargento, R. Sarro, Architecture and design: routing for ad-hoc and moving [97] J. Kempf, Problem Statement for Network-Based Localized Mobility
networks, Tech. Rep. DII-241, October 2007. Management (NETLMM), RFC 4830 (Informational), April 2007.
[61] R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, Host identity protocol, RFC [98] L. Osborne, A. Abdel-Hamid, R. Ramadugu, A performance comparison of
5201 (Experimental), April 2008. mobile ipv6, hierarchical mobile ipv6, and mobile ipv6 regional registrations,
[62] R. Moskowitz, P. Nikander, Host identity protocol (HIP) architecture, RFC in: 2005 International Conference on Wireless Networks, Communications
4423 (Informational), May 2006. and Mobile Computing, vol. 2, 2005, pp. 15451550.
[63] A. Gurtov, Host Identity Protocol (HIP): Towards the Secure Mobile Internet, [99] X. Prez-Costa, M. Torrent-Moreno, H. Hartenstein, A performance
WILEY, 2008, ISBN 978-0-470-99790-1. comparison of mobile ipv6, hierarchical mobile ipv6, fast handovers for
[64] Host identity protocol (hip) ietf work group. <http://www.ietf.org/dyn/wg/ mobile ipv6 and their combination, SIGMOBILE Mobile Computing and
charter/hip-charter.html>. Communications Review 7 (2003) 519.
H. Tuncer et al. / Computer Communications 36 (2012) 6379 79

[100] N. Jordan, A. Poropatich, J. Fabini, Performance evaluation of the hierarchical International Symposium on Wireless Pervasive Computing, ISWPC 2009,
mobile ipv6 approach in a wlan hotspot scenario, in: 2005 IEEE 61st 2009, pp. 15.
Vehicular Technology Conference, 2005. VTC 2005-Spring, vol. 5, 2005, pp. [102] J.-H. Lee, T.-M. Chung, S. Gundavelli, A comparative signaling cost analysis of
28102814. hierarchical mobile ipv6 and proxy mobile ipv6, in: IEEE 19th International
[101] M.-K. Yi, J.-W. Choi, Y.-K. Yang, A comparative analysis on the signaling Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC
load of proxy mobile ipv6 and hierarchical mobile ipv6, in: 2009 4th 2008, 2008, pp. 16.