Computer Networks 57 (2013) 2578–2596

Contents lists available at SciVerse ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/locate /comnet

Performance analysis of Virtual Mobility Domain scheme vs.IPv6 mobility protocols

1389-1286/$ - see front matter � 2013 Elsevier B.V. All rights reserved.http://dx.doi.org/10.1016/j.comnet.2013.05.004

⇑ Corresponding author. Tel.: +1 585 201 0834.E-mail addresses: hxt3948@rit.edu (H. Tuncer), axkeec@rit.edu (A.

Kwasinski), nxsvks@rit.edu (N. Shenoy).

Hasan Tuncer a,⇑, Andres Kwasinski b, Nirmala Shenoy c

a College of Computing and Information Sciences, Rochester Institute of Technology, Rochester, NY 14623, USAb Department of Computer Engineering, Rochester Institute of Technology, Rochester, NY 14623, USAc 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

Article history:Received 4 December 2011Received in revised form 2 March 2013Accepted 13 May 2013Available online 30 May 2013

Keywords:Next generation wireless networksMobility managementHandoff performanceAnalytical modeling

a b s t r a c t

The population of mobile users seeking connectivity to the Internet has been growing overthe years, spurred by the capabilities of handsets and the increasing rich Internet contentand services. Mobility management to enable efficient Internet access for users on themove is thus gaining significance. IETF has standardized several protocols such as MobileIPv6, Hierarchical Mobile IPv6, and Proxy Mobile IPv6 to provide mobility managementon the IP network. With future Internet design initiatives gaining momentum, it is impor-tant that these initiatives consider mobility management as an integral part of the design.In this article, we introduce the concept of Virtual Mobility Domain and describe the mainfeatures and key strengths of Virtual Mobility Domain that are designed to provide mobil-ity management in a newly proposed tiered Internet architecture. Instead of IP addressing,the proposed Virtual Mobility Domain uses a tiered-addressing scheme to identify a mobilenode with a single address regardless of its location. The tiered addressing provides adynamic address length which brings less signaling overhead and scalable management.We also propose a collaborative network-based mobility management mechanism to pro-vide low-latency handoffs and less processing-overhead on the mobile node compared tothe IPv6-based protocols. The proposed mobility scheme unifies inter and intra-domainmobility management by introducing common anchor cloud concept which provides a dis-tributed management and seamless mobility experience. We present comparative qualita-tive and quantitative performance analysis of Virtual Mobility Domain and aforementionedIPv6-based mobility protocols for Intra-AS roaming support. We examine handoff latencyand signaling overhead performance of each protocol based on numerical results retrievedfrom analytical models and OPNET modeler based simulations. The results from a compar-ative performance study show the potential for more efficient mobility management underthe proposed Internet architecture.

� 2013 Elsevier B.V. All rights reserved.

1. Introduction

Significant advances in hardware and wireless technol-ogies have made mobile communication devices affordableto a vast user community. With the advent of rich multi-media and social networking content, and influx of myri-

ads of applications, there is an increasing user demandfor Internet connectivity anywhere and anytime. RobustInternet protocols and evolutionary research efforts haveenabled the Internet to withstand the demands of the usersand the emerging technologies.

Research programs worldwide such as the National Sci-ence Foundation’s Future Internet Design Initiative [1] andFuture Internet Architecture Project [2] in the UnitedStates, the European Union’s sixth and seventh frameworkprograms [3], the Asia consortium [4], and New Generation

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2579

Networks [5] in Japan have started funding clean slate fu-ture Internet research to efficiently harness the related ad-vanced technologies and to better address user demands.Mobility management is an integral feature in many ofthese future Internet designs [6]. Mobility management in-cludes seamless roaming of mobile users requiring fast hand-off with low latency and low packets loss to allowcontinuation of active sessions transparently as userschange network connections [7].

The authors of this work proposed a tiered Internetarchitecture1 derived from the tiered structure existing to-day among Internet Service Providers (ISPs) to define theirbusiness and peering relationships [8,9]. The topologicalconnections between ISPs exhibit a hybrid structure thatleverages the attributes of hierarchical and distributedstructures. In a tiered structure, there can be several entitiesin one tier such as an ISP, an Autonomous System (AS) or anaccess network that operate in a distributed and autono-mous manner. However, entities at a lower tier are custom-ers of entities at a higher tier, exhibiting a hierarchicalrelationship. The tiered structure enables defining VirtualMobility Domains (VMDs) of varying scopes by deployingto any tier. VMD defines a virtual roaming boundary whichis not geographically or physically constrained to a localityfor a mobile user. A user is tracked with a single short-lengthtiered-address in the VMD. Seamless user movement withinthe domain is collaboratively managed by nodes in the net-work. Collaborative management scheme provides a distrib-uted and scalable management of the mobility.

In this article, extensive analytical and simulation basedperformance study of intra-AS roaming support of VMD[10] in a tiered Internet architecture in comparison withMobile IPv6 (MIPv6) [11], Hierarchical Mobile IPv6(HMIPv6) [12], and Proxy Mobile IPv6 (PMIPv6) [13] is pre-sented. These protocols are chosen specifically becausethey present fundamentally different ways of handling ahandoff and we aim to investigate the contributions dueto locations and functions of the different mobility agentson the network. It is not possible to compare the VMDbased mobility protocol with other recent future Internetsolutions because most are in the research phase. How-ever, a comparison with MIPv6, HMIPv6, and PMIPv6 willshow the relative performance improvements achievedwith VMD and also serve as benchmark for future mobilityrelated studies. Our study in this paper reveal that VMDoutperforms MIPv6, HMIPv6, and PMIPv6 significantly interms of handoff latency, packet loss, and signaling over-head – the three important performance metrics to assessseamless user mobility.

The rest of the paper is organized as follows. Section 2covers a summary of previous and ongoing research onmobility management. Section 3 presents the tiered Inter-net architecture and the VMD concept, followed by VMDintra-AS roaming support in Section 4. The analytical mod-els for VMD, MIPv6, HMIPv6, and PMIPv6 are provided inSection 5. Performance comparison of VMD against MIPv6,HMIPv6, and PMIPv6 based on both analytical and

1 This work was funded by NSF under Grant No. 0832008.

simulation models are presented in Section 6. Concludingremarks are given in Section 7.

2. Related work

Fundamental to any internetwork design is an under-standing of the current mobility solutions, the rationale be-hind their design, and their performance in the context ofthe current Internet architecture. This section is thus direc-ted to mobility solutions developed under the currentInternet architecture, followed by mobility solutions pro-posed by few future Internet efforts.

Mobility protocols can be categorized broadly as net-work-based or host-based [14]. They can also be categorizedbased on the scope (intra-domain vs. inter-domain) suchas micro-mobility or macro-mobility protocols [15]. Eachtype of mobility protocols operationally views mobile de-vices and networks differently depending on the underly-ing mobility management principles.

Few of the major mobility protocols that were devel-oped under the Internet Engineering Task Force (IETF) ini-tiatives are MIPv6 [11], HMIPv6 [12], and PMIPv6 [13].These protocols were developed to work with the currentInternet architecture and protocols. They use IP addressesto identify a mobile node (MN) and to route packets tothem [16]. Hence, when an MN moves across access rou-ters (ARs) or domains, new IP address has to be acquiredat the newly connected network. The MN next updatesthe previous network with the acquired address througha process called address binding. This will aid in forward-ing packets to the new location of the MN. The operationsof these protocols are described in Section 5. Improve-ments and enhancements to MIPv6, HMIPv6 and PMIPv6are proposed and studied in [17–19] respectively.

Another approach to enhance mobility management is toseparate the locator and the ID of an MN. Host Identity Pro-tocol (HIP) [20] uses an IP address only as a location identi-fier and introduces Host Identity name space as an endpointidentifier. Locator Identifier Separation Protocol (LISP) [21]uses an MN endpoint identifier and routing locator address.If an MN roams, its routing locator changes and the mappingbetween the endpoint identifier and the routing locator ishandled by a network-based map-and-encapsulate scheme[22]. Routing on Flat Labels (ROFL) [23] proposes a namingand routing architecture based on flat identifiers that donot have location semantics. Therefore, the MN name doesnot change and mobility support is provided by distributedhash tables maintained at each node. Mobility and Multih-oming Supporting Identifier Locator Split Architecture (MIL-SA) [24] proposes a hybrid design combining locator/ID splitand core–edge separation to provide renumbering andmobility support among others. MobilityFirst [25] andeXpressive Internet Architecture [26] identify the Internetcontent, mobile devices or users with human-readablestrings, and use naming and location services to map stringidentifiers to actual network addresses.

Another mobility management approach provides anoverlay structure to route data packets to an MN when itroams. General Packet Radio Service (GPRS) providesoverlay routing in the local topology so that identity and

Fig. 1. The FCT model is applied to ISP networks and ASes. Arrows showthe provider–customer relationships. Dotted arrow shows peering rela-tionships. Each arrow represents a single link or multiple links [8].

2580 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

location function of IP address remain the same while anMN roams [27]. Internet Indirection Infrastructure (i3) Ro-bust Overlay Architecture for Mobility (ROAM) providesrendezvous based overlay indirection service that forwardsdata to the current location of the MN [28].

Akari [29], supported by the Asia consortium, proposesnetwork virtualization, locator/ID split, and cross layer de-sign to support seamless MN movement across a variety ofwireless access technologies by deploying identity man-agement and mapping servers.

Providing an integration framework for different net-work technologies and protocols to operate together is an-other approach used in mobility management. For example,Ambient Networks [30], one of the future Internet projectssupported by European Union sixth framework program,introduces mobility control space and handoff toolbox thatenable the integration of different mobility managementmechanisms. Daidalos [31], a European Union large-scalecollaborative future Internet project, provides virtual iden-tity framework for an MN to access personalized serviceson seamlessly integrated heterogeneous network technolo-gies with the help of ID-Broker that supplies an MN’s loca-tion to a correspondent node (CN) and proxies the requestto the MN and the ID-Manager.

The VMD scheme introduced in this article is based on atiered Internet architecture which uses tiered addressesand a unique packet forwarding scheme. VMD supportsnetwork-based mobility management and leverages thetiered structure to provide collaborative handoff manage-ment in a domain that can span several networks or ASes.Collaborative mobility management offers a dynamichandoff management with respect to user mobility patternand hence is expected to bring less signaling overhead andlow latency. VMD is user centric as it is possible to overlapVMDs of different scopes and hence allow a user to select aVMD most suited to his roaming needs.

3. The tiered internetwork model

3.1. Tiered architecture

The new tiered Internet architecture leverages thetiered structure that exists among ISPs to define their busi-ness relationships. However, to overcome topologicalrigidity in the tiered ISP structure and to enable easyattachment of entities such as networks or ASes acrossthe tiers, granularity and modularity were introduced.Granularity was introduced through the concept of net-work clouds [9] where a network cloud can be an ISP net-work, a point of presence (POP) in an ISP, an AS, or a set ofrouters. Modularity was introduced by decoupling the rela-tionships between the network clouds through the use of anesting concept. Thus, the model was named the FloatingCloud Tiered (FCT) internetworking model. The FCT inter-networking model allows network clouds to connect atany tier without impacting their internal address or struc-ture when nesting is adopted [8].

The goal of the FCT is to overlay the tiered structure(existing among ISPs) on the meshed Internet topology tofacilitate efficient routing using the tiered addresses. Inher-ently, there is a hierarchy in the tiered structure which is

being used in the VMD scheme. To explain VMD in the con-text of the FCT internetworking model, we provide a briefdescription of the FCT model and its operation using ISPnetworks in Fig. 1. Each ISP or AS is identified with a tieredcloud address (CloudAddr), which is a function of the tier inwhich the network cloud resides and its association to itsservice provider network clouds. In Fig. 1, ISP A, which isthe first cloud in tier 1 has CloudAddr 1.1 following a formatTierValue.MyCloudID. ISP B similarly has a CloudAddr 1.2.ISP C is in tier 2 and connected to both ISP A (via CloudAddr2.1:1) and ISP B (via CloudAddr 2.2:1) simultaneously. TheCloudAddr format in this case is TierValue.ParentClou-dID:MyCloudID where the ParentCloudID is inherited fromthe upper tier clouds. ISP D is connected to ISP B throughCloudAddr 2.2:2. Similar provider-rooted address can benoticed in [32,33]. In Fig. 1, each arrow represents a singlelink or multiple links. Each link may get different address orsame address. When they are assigned same address, theaddress and each link’s port information needs to be sharedamong the routers in the same cloud [8].

The packet forwarding decision across the clouds (up,down, or sideways) depends on the relative positions ofthe source and destination clouds. To illustrate, if AS 3(4.2:2:2:3), source cloud, wants to send packet to AS 1(3.2:2:1), destination cloud, then the source compares itsaddress with the destination’s address to determine thetier of a common parent (or grandparent) cloud. In thiscase, the common parent cloud will be ISP D at tier ‘2’.The remaining fields in the destination address (after thecommon part) are then appended to the TierValue to pro-vide the forwarding address. In this case, the forwardingaddress will be 2.1. All the intermediate clouds betweenAS 3 and ISP D forward the packet upwards, using the tiervalue. When the packet reaches ISP D, then it identifiesthat the destination is at tier 3 because of the one addressfield following the tier value. It replaces the TierValue with3 and forwards the packet down to the destination cloud.However, if there were a peering link between ISP E andAS 1, the border routers in ISP E would have routing tableentries for the sibling cloud connections and ISP E couldforward the packet directly to the AS 1. The FCT architec-ture, its tiered addressing scheme, the cloud movementsupport, the packet forwarding and the study of Internet’stopology are explained in more detail in [8,34].

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2581

The tiered structure applied to ISP networks in theabove example can be applied within an AS or a network.If such were the case as illustrated in Fig. 2, the border orbackbone routers can be associated to a network cloud intier 1, the distribution routers can be associated to a net-work cloud in tier 2. The access routers and subnets canbe associated to tier 3. In this article, the VMD conceptand its intra-AS roaming support are discussed by applyingthe tiered structure to the AS network in Fig. 2.

The tiered addresses proposed for the FCT internet-working model is used to forward packets to the MN. Inthe VMD based mobility management, the relationship be-tween network clouds in the tiered structure and theinheritance information in the tiered address allow anMN to roam within a defined VMD using a single address.

3.2. Virtual Mobility Domain

The network cloud concept defined under the FCT inter-networking model can be extended to virtual networkclouds, where the set of devices in the network cloud arenot geographically or physically constrained to a locality.A virtual network cloud thus defines the boundary of aVMD. A VMD has to be supported by an upper tier cloud,thereby allowing MNs that have an address in the VMDto roam within the scope of that upper tier cloud i.e. withinall network clouds that are connected under the upper tiercloud. An MN’s movement in the VMD is collaborativelymanaged by the upper tier cloud and all network cloudsunder the upper tier cloud. The details are explained inSections 3.2.1 and 3.2.2.

A VMD can be applied to any tier or cloud to cover sin-gle AS, several ASes or ISPs in the current Internet. Theagreements across the clouds are necessary in extendingVMD across ASes or ISPs [9]. In this paper, we focus onlyon VMD deployment within a single AS. VMD deploymentacross multiple ASes and ISPs can be found in [35].

Fig. 2. VMD is applied to an AS. The backbone routers form the cloud in tier 1. Clorouters. Access routers reside in tier 3.

3.2.1. VMD implementationFig. 2 is used to explain the VMD deployment in an AS,

such as AS 1 (Fig. 1) with a CloudAddr 3.1:1:1. The networkclouds and tiers concept have been applied within the AS.Nesting of tiers as described in [8] allows the tier numberswithin the AS to start at 1.

The backbone routers and an authentication, authoriza-tion, and accounting (AAA) server form the network cloudin tier 1, that is named as Root Cloud. Cloud A and Cloud Bare the tier-2 network clouds comprising distribution rou-ters that connect to the backbone routers in Root Cloud intier 1. Each tier-2 cloud has a proxy AAA server to maintainan MN profile while the MN is roaming under the samecloud. The access networks and devices are in tier 3. Eachcloud maintains a forwarding base (FB) to track the physicallocation of the MN roaming within the cloud. CloudAddrsare noted beside the clouds and the devices.

In this article, we assume that there is only one RootCloud. In the case that there were two Root Clouds thatcovered all the clouds at lower tiers in an AS, any onecould serve to provide the coverage under the VMD. InFig. 2, the VMD cloud is defined under the Root Cloudand has a CloudAddr 2.1:2. MNs supported under this do-main will thus get an address in tier 3, namely 3.1:2:n(where ‘n’ can be any integer value). MNs can roam inany of the network clouds under Root Cloud namelyClouds A and B. The MN in Fig. 2 has an address 3.1:2:1.The global address of the MN will however be3.1:1:1{3.1:2:1} where the MN’s local VMD address is ap-pended to AS cloud address following the nested notationdefined in [8]. Forwarding data packets to the MN withinthe VMD however will use the internal address 3.1:2:1and is described in Section 4.4.

3.2.2. Collaborative mobility managementThe AAA server located in Root Cloud maintains the pro-

files and authentication details for MNs roaming within theAS. When the MN is registered to a VMD, a proxy AAA

ud A and Cloud B in tier 2 represent network clouds that have distribution

2582 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

server in a tier-2 cloud makes a copy of the MN profile fromthe AAA server in tier 1. The MN may roam in the vicinity ofAR1, AR2 or AR3, and its physical location is tracked by theforwarding bases maintained at the clouds. For example,when an MN is connected to AR1 or AR2, the distributionrouters in Cloud A will maintain an entry in the forwardingbase for the MN that points to the MN’s current AR, whilethe backbone routers in tier 1 will have a forwarding baseentry which indicates that the MN is physically located un-der Cloud A. If the MN moves between ARs i.e., AR1 and AR2under the same tier-2 cloud, then Cloud A will be the com-mon anchor cloud for AR1 and AR2. The common anchorcloud manages the MN mobility with the help of proxyAAA servers and forwarding bases. Hence, no communica-tion with Root Cloud is required.

4. VMD Intra-AS roaming support

This section describes the processes and the signalingfor intra-AS roaming using VMD. The MN is assumed tobe in its home network, which is a valid assumption asthe focus is on VMD based micro-mobility support. Toroam within a VMD, an MN requires an address. Addressacquisition in the VMD is described in Section 4.1. This isfollowed by the signaling required for the MN’s intra-cloud

Fig. 3. Control message flow for in

roaming, e.g. from AR1 to AR2 (in Fig. 2), which is de-scribed in Section 4.2. When the MN roams from AR2 toAR3 (inter-cloud), the signaling now involves Root Cloudin tier 1, and is described in Section 4.3. The informationflow and related processes during the handoff manage-ment are shown in Fig. 3.

4.1. Address acquisition in VMD

In Fig. 3, steps numbered 1–7 describe the processesand message exchanges for address acquisition by an MN.

1. The MN receives beacon packets from AR1. The MNdecides to associate with AR1 and sends a layer 2 asso-ciation request to AR1 along with its UniqueID, whichcan be its MAC address.2. (a) AR1 checks its forwarding base, for an entry for

the MN.(b) If there is no entry, AR1 will send an AAA

request (AAA_req) message that includes theMN’s UniqueID, and AR1’s network address.AR1’s address is included to receive theresponse back. The aim of sending AAA requestmessage is to authenticate the MN and to getan address for the MN.

tra-AS roaming in the VMD.

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2583

3. (a) The AAA request message is received by a rou-ter in Cloud A that is responsible of mobility

management. The router checks the proxyAAA server maintained by the cloud for anentry for the MN.

(b) If there is no entry, which could happen ifthis is the first time that the MN is roam-ing into Cloud A coverage area, the routerwill forward the AAA request message toRoot Cloud in tier 1.

4. A router in Root Cloud which receives the AAArequest message will check with the AAA serverto authenticate the MN. An address is then allo-cated to the MN from the VMD cloud. Let theMN address be 3.1:2:1. The forwarding base inRoot Cloud is updated with the MN address andCloud A address as a downlink address to be usedto forward packets to the MN.

5. Root Cloud then sends an AAA acceptance (AAA_acc)message to AR1 in Cloud A. While the AAA accep-tance message is delivered to AR1, the router inCloud A that handles mobility management recordsAR1 address in its forwarding base as a downlinkaddress for forwarding packets destined to the MN.The AAA profile of the MN is also maintained by aproxy AAA server in Cloud A to be used later for theMN’s intra-cloud roaming.

6. (b) AR1 forwards the AAA acceptance message tothe MN, with the newly allocated address forthe MN.

7. From the AAA acceptance message, the MN gets itsaddress. Subsequently, the MN will use this addressfor roaming under any cloud in the AS.

4.2. Intra-cloud roaming

In Fig. 3, steps numbered 8–12 describe the processesand message exchanges to support intra-cloud roamingof the MN.

8. The MN moves into the coverage area of AR2 andsends an association request to AR2.

9. (a) AR2 checks its forwarding base for an entry

using the MN’s UniqueID.

(b) If there is no entry, an AAA request messagewill be sent to a router responsible for mobilitymanagement in Cloud A.

10. Since the MN has been already registered in Cloud A,an entry for the MN will be located at the proxy AAAserver. The forwarding base entry for the MN isupdated with AR2 address as a downlink addressto forward packets to the MN.

11. (a) A location registration (L_reg) message is then

sent to AR2 by the cloud router.

(b) AR2 updates its forwarding base with the MN’saddress.

12. (a) A location deregistration (L_dereg) messagewill be sent to AR1 by the router in Cloud A.

(b) AR1 removes the MN address from its forward-ing base.

In the above transactions, mobility management relatedmessages are limited to Cloud A in tier 2 due to the collab-orative management supported by the VMD scheme.

4.3. Inter-cloud roaming

If the MN moves from AR2 to AR3, located in Cloud B,steps numbered 13–19 of Fig. 3 are executed. The mobilitycontrol message exchanges are similar to the movement ofthe MN from AR1 to AR2, the difference is that the AAA re-quest message is forwarded to Root Cloud in tier 1 byCloud B because MN is roaming in Cloud B domain forthe first time and hence proxy AAA server in Cloud B doesnot have the MN profile. Root Cloud receives the AAA re-quest, retrieves MN’s previously allocated address andthen sends a location registration message to AR3. The for-warding base and the proxy AAA server in Cloud B andthen the forwarding base at AR3 are updated with the loca-tion registration message. A location deregistration mes-sage is sent from Root Cloud to Cloud A to remove theMN from its forwarding base, and a similar notification issent from Cloud A to AR2.

4.4. Packet forwarding

Assume a correspondent node with address 2.2:1 asshown in Fig. 2 sends data packets to the MN using theMN’s global address namely 3.1:1:1{3.1:2:1} where MN’slocal VMD address is appended to AS cloud address. Thedata packets are delivered to the AS by the FCT packet for-warding scheme [8]. The backbone routers in Root Cloudthat receive data packets will remove the AS CloudAddr.Within the AS cloud, data packets to the MN will be deliv-ered using its local VMD address 3.1:2:1. At Root Cloud, arouter will check its forwarding base for the current net-work cloud of the MN. Packets will be forwarded to thatcloud, where a router will check the forwarding base to lo-cate the AR to which the MN is associated and forward thedata packets to that AR. The AR will then forward the pack-ets to the MN. In this packet forwarding scheme, tunnelingis not required avoiding the processing and overhead dueto tunneling.

5. Analytical models

In this section, we analyze the handoff performance ofVMD against MIPv6, HMIPv6, and PMIPv6 using an analyt-ical approach. The analytical study will be carried out forhandoff latency and handoff signaling overhead as theyare important performance indicators to assess seamlessmobility as described in [36–40]. The mobility protocolsare deployed in the network illustrated in Fig. 4, which isthe same network of Fig. 2, shown in our OPNET simulationenvironment. In the case of HMIPv6, mobility anchor point(MAP) is located at Root Cloud. For PMIPv6, local mobilityanchor (LMA) is located at Root Cloud while the mobilityaccess gateway (MAG) is located at each AR. To conductcomparison with MIPv6, the network in Fig. 4 will be as-sumed to be a foreign network, and hence home networkand home agent are located outside of the AS.

Fig. 4. The network topology that is used for OPNET simulation and analytical study.

2584 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

In Section 5.1, the different latency components thatcontribute to handoff latency are defined. Section 5.2 pro-vides a brief overview of the components used in the sig-naling overhead calculation. The latency and signalingoverhead equations used for MIPv6, HMIPv6, and PMIPv6are presented in Sections 5.3, 5.4, and 5.5, respectively.

5.1. Handoff latency

Consistent with [37], we define handoff latency as thetime that elapses between the events when an MN com-pletes its layer 2 association at the new AR and receivesa new data packet through the new AR. In general, the fol-lowing delays are incurred during a handoff: movementdetection delay, duplicate address detection delay, mobil-ity control message transmission delay, AAA procedure de-lay, and first data packet transmission delay. They aredefined as follows:

1. TMD (Movement Detection delay) is the time spent forthe discovery of a new AR performed through RouterSolicitation/Advertisement (RS/RA) message exchanges

between MN and AR [41]. ARs can be configured withminimum router advertisement interval (RAImin) thatis 0.5 s and maximum router advertisement interval(RAImax) that is 1 s to send unsolicited router advertise-ment messages more often. Hence, the mean value ofTMD is half of the mean time between unsolicited routeradvertisement messages [37].

TMD ¼ ðRAImin þ RAImaxÞ=4 ð1Þ

Detailed movement detection analysis can be found in[42].2. TDAD (Duplicate Address Detection delay) is the time

spent by MN to ensure that a configured care-of addressis likely to be unique on the new link. Duplicate addressdetection is performed by exchanging Neighbor Solici-tation/Advertisement (NS/NA) messages. As per [43],TDAD can be expressed as

TDAD ¼ RT � DTimes ð2Þ

where RT is the time interval that MN waits after sendingneighbor solicitation to see if a neighbor advertisement is

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2585

forthcoming, and DTimes is the number of repetitions of so-licit-and-wait process.3. tX,Y is one-way transmission delay of a message

between node X and node Y. The one-way transmissiondelay between MN and any router Y can be expressed as

Table 1The mo

Nota

BUs

BAs

BUcn

BAcn_

LBUs

LBAs

PBUs

PBAs

HoTIHoTs

CoTIs

CoTs

AAA_AAA_L_regL_de

tMN;Y ¼s

BwlþLwl

� �þðhMN;Y �1Þ � s

BwþLwþpq

� �ð3Þ

where s is the message size (mobility related message sizesare provided in Table 1), hMN,Y is the number of hops be-tween MN and Y, pq is the average processing and queuingtime of a packet at a router [44], Bwl and Bw are the band-width of wireless link and wired link respectively, Lwl andLw are the propagation delay of wireless link and wired linkrespectively [38]. The round trip delay between X and Y is2 � tX,Y.4. TBU(X, Y) represents the time required to send a mobil-

ity control message to node X and to receive aresponse message in return. X can be MN in MIPv6and HMIPv6; or mobility anchor gateway in PMIPv6.Y can be home agent (HA) or correspondent node inMIPv6, mobility anchor point as well in HMIPv6, orlocal mobility anchor in PMIPv6. TBU(X, Y) is calculatedas follows

TBUðX;YÞ ¼ 2 � tX;Y ð4Þ

5. TAAA is the delay involved in mobile agents’ communica-tion with AAA servers to authenticate the MN.

6. TPT is the data packet transmission delay from corre-spondent node to MN that includes the one-way trans-mission delay and the data packet interarrival time (tP)in the worst case.

tCN;MN 6 TPT 6 tCN;MN þ tP ð5Þ

Following assumptions have been made to conduct fairanalysis across all mobility protocols.

1. The aforementioned four protocols are deployed in thesame network topology under a single domain similarto the study in [37]. In MIPv6, the administrative

bility control messages.

tion Description Bytes

The Binding Update message 56The Binding Acknowledgment message s 56

_s The Binding Update message (to CN) 66s The Binding Acknowledgment message (from

CN)66

The Local Binding Update message 56The Local Binding Acknowledgment message 56The Proxy Binding Update message 76The Proxy Binding Acknowledgment message 76

s The Home Test Init message 64The Home Test message 74The Care-of Test Init message 64The Care-of Test message 74

accs The AAA acceptance message 76reqs The AAA request message 76s The location registration message 76

regs The location deregistration message 76

domain under consideration is assumed to be a foreignnetwork in which the MN is roaming. In HMIPv6, it isassumed to be the domain under a mobility anchorpoint. In PMIPv6, it is assumed to be domain under alocal mobility anchor. In VMD, it is assumed to be ahome network domain.

2. Handoff failure, link failure, and packet collision/back-off delay have not been considered [45]. We assumethat every message is successfully transmitted to thedestination, hence we are analyzing the normalizedhandoff delay as defined in [46].

3. We assume that the MNs are allowed to access a net-work after AAA procedure is completed, and theseaccess delays are the same for MIPv6, HMIPv6, PMIPv6,and VMD [37].

4. Layer 2 link switching delay is not included in thelatency calculations and is in accordance with ourlatency definition.

5.2. Signaling overhead

Signaling overhead incurred due to handoff is calcu-lated as the sum of the mobility control messages multi-plied by the number of hops that each message travelstill they reach the destination node [36,39]. The aim is todetermine the number of bytes transmitted over thewired/wireless links due to handoff. hX,Y represents thenumber of hops between nodes X and Y. In our calcula-tions, we did not include router solicitation and routeradvertisement exchanges between MN and AR since theyare not part of any mobility protocol. We also did not takeinto account the periodic binding refresh and the effect of abinding lifetime period as in [40]. Similarly, we excludeddata packet delivery cost that takes into account data pack-et transmission, tunneling and data processing. The reasonis that data packets travel the same path in the network forall the protocols. All mobility control messages and theirsizes are given in Table 1 [46].

The signaling overhead equations for IPv6-based proto-cols in the next sections are confirmed with those in[36,39].

5.3. Mobile IPv6 (MIPv6)

MIPv6 [11] is a host-based macro-mobility protocol.Hence, it requires an MN to be involved in the mobilitymanagement. While an MN is connected to its home net-work, it uses an address acquired in the home network.As the MN connects to a different subnet or network, anew IP address in that network called the care-of address(CoA) is required.

MIPv6 uses the IP address of the MN in its home net-work as its global identifier. MIPv6 deploys home agentsin the home network to handle mobility management.After the MN gets the care-of address (through stateless[43] or stateful mode [47]), it sends a binding update mes-sage with the new address to the home agent. In MIPv6with route optimization, the MN communicates with a cor-respondent node using its care-of address and thus avoidsthe home network intervention. However, the routeoptimization process requires a sequence of signaling

2586 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

message exchanges between the MN, home agent, and cor-respondent node [48].

5.3.1. Handoff latency in MIPv6Handoff latency in MIPv6 (DMIPv6) is expressed as fol-

lows using the terminology defined under Section 5.1 [39]:

DMIPv6 ¼ TMD þ 2 � TDAD þ TAAA þ TBUðMN;HAÞ þ TRO

þ TBUðMN;CNÞ þ TPT ð6Þ

Duplicate address detection process happens first atthe MN where the care-of address is created via statelessaddress autoconfiguration [43]. If the home agent doesnot have a binding for the care-of address, the homeagent also performs the duplicate address detection onthe care-of address before sending binding acknowledg-ment message to the MN. Stateless address autoconfigu-ration is one of the new features with IPv6 and doesnot require special communications (or protocols) witha DHCP server [47]. Hence, in this paper it was decidedto use the option of stateless address auto configuration,which then requires duplicate address detection to beexecuted in MIPv6 and HMIPv6.

TRO represents the time spent for route optimizationprocess which includes exchanging a sequence of signal-ing messages between MN, home agent, and correspon-dent node. Home address testing and care-of addresstesting can be initiated at the same time, hence TRO is gi-ven by

TRO ¼ maxð2 � ðtMN;HA þ tHA;CNÞ;2 � ðtMN;CNÞÞ ð7Þ

5.3.2. Signaling overhead in MIPv6Signaling overhead in MIPv6 (CMIPv6) is expressed as fol-

lows [39]:

CMIPv6 ¼ BUðMN;HAÞ þ ROHome þ ROCN þ BUðMN;CNÞ ð8Þ

where the binding update/acknowledgment with homeagent and correspondent node are represented by BU(MN,HA) and BU(MN, CN), respectively. They are given by

BUðMN;HAÞ ¼ BUs � hMN;HA þ BAs � hHA;MN ð9ÞBUðMN;CNÞ ¼ BUcn s � hMN;CN þ BAcn s � hCN;MN ð10Þ

Route optimization process comprises two phases:

1. Exchanging a sequence of signaling messages betweenMN and home agent. The signaling overhead incurredduring this phase is represented with ROHome and it iscalculated as

ROHome ¼ HoTIs � hMN;HA þ HoTIs � hHA;CN þ HoTs

� hCN;HA þ HoTs � hHA;MN ð11Þ

where the messages are defined in Table 1.2. Exchanging a sequence of signaling messages between

MN and correspondent node through home agent. Thesignaling overhead incurred during this phase is repre-sented by ROCN and is given by

ROCN ¼ CoTIs � hMN;CN þ CoTs � hCN;MN ð12Þ

where the variables are defined in Table 1.

5.4. Hierarchical Mobile IPv6 (HMIPv6)

HMIPv6 [12] is a host-based micro-mobility protocol.HMIPv6 introduces mobility anchor point to manage themicro-mobility of an MN in an HMIPv6 domain. When anMN enters an HMIPv6 domain, it listens to the routeradvertisements from AR and acquires information aboutAR and the mobility anchor point. Then, the MN configuresan address called on-link care-of address (LCoA) in a state-less manner [43] that represents the current point ofattachment of the MN. The MN also configures another ad-dress called regional care-of address (RCoA) by appendingits interface identifier to the mobility anchor point addressprefix. The regional care-of address of MN is global andused throughout the HMIPv6 domain.

After acquiring the on-link care-of address and the re-gional care-of address, the MN sends local binding updatemessage to the mobility anchor point to register thesetwo addresses. The MN and the mobility anchor pointhave to execute duplicate address detection to be surethat the on-link care-of address and the regional care-ofaddress are unique and not used by other nodes in thesame HMIPv6 domain. After the MN has completed itsregistration to the new network, the MN informs thehome network about its regional care-of address. Whenthe MN moves within the same mobility anchor point do-main, its regional care-of address does not change. TheMN has to register only its new on-link care-of addressto the mobility anchor point as it changes its subnet.The mobility anchor point also establishes a tunnel withthe MN for the MN’s communication with a correspon-dent node.

5.4.1. Handoff latency in HMIPv6If an MN moves to an HMIPv6 domain for the first time,

initial HMIPv6 latency (DHMIPv6_o) is expressed as follows[37]:

DHMIPv6 o ¼ TMD þ 3 � TDAD þ TAAA þ TBUðMN;MAPÞþ TBUðMN;HAÞ þ TRO þ TBUðMN;CNÞ þ TPT ð13Þ

TDAD is multiplied by three to include duplicate addressdetection delay for on-link care-of address at the MN andthe regional care-of address at the mobility anchor pointand at the home agent. However, while the MN moveswithin the HMIPv6 domain [37], the latency DHMIPv6 is gi-ven by

DHMIPv6 ¼ TMD þ TDAD þ TAAA þ TBUðMN;MAPÞ þ TPT ð14Þ

where TDAD represents the duplicate address detection de-lay for on-link care-of address.

5.4.2. Signaling overhead in HMIPv6Signaling overhead in HMIPv6 (CHMIPv6) caused by local

binding update/acknowledgment messaging between theMN and the mobility anchor point [36] is formulated as

CHMIPv6 ¼ BUðMN;MAPÞ ð15Þ

where BU(MN, MAP) represents the signaling overhead in-curred due to binding update messaging between MN andmobility anchor point and is calculated as

Networks 57 (2013) 2578–2596 2587

BUðMN;MAPÞ ¼ LBUs � hMN;MAP þ LBAs � hMAP;MN ð16Þ

H. Tuncer et al. / Computer

5.5. Proxy Mobile IPv6 (PMIPv6)

PMIPv6 [13] is a network-based micro-mobility man-agement protocol, and it does not require the MN to in-volve in any mobility related signaling such as addresscreation, sending of binding updates, and encapsulation/decapsulation of data packets. PMIPv6 introduces mobilityaccess gateway which is installed on ARs and local mobilityanchor which may be deployed in the tier-1 cloud of the ASnetwork in Fig. 2 thus defining a PMIPv6 domain. Themobility access gateway detects the MN’s movementsand initiates mobility-related signaling with the localmobility anchor on behalf of the MN [49]. The local mobil-ity anchor is the mobility manager in the PMIPv6 domain.The local mobility anchor decides on the MN’s new addressand then maintains reachability to the MN’s address whilethe MN moves within a PMIPv6 domain.

Once an MN attaches to a mobility access gateway forthe first time, the mobility access gateway and local mobil-ity anchor exchange proxy binding update/acknowledg-ment messages after confirming the MN’s profile with anAAA server. Local mobility anchor attaches a unique ad-dress to the proxy binding acknowledgment message forthe usage of the MN in the entire PMIPv6 domain. This ad-dress assignment process does not require duplicate ad-dress detection and the MN involvement. Local mobilityanchor also sets up a bidirectional tunnel with the mobilityaccess gateway for sending and receiving the MN’s datapackets with a correspondent node.

5.5.1. Handoff latency in PMIPv6If an MN moves to a PMIPv6 domain for the first time,

MIPv6 will be used to support macro-mobility. The handofflatency (DPMIPv6_o) is thus represented as follows [37]:

DPMIPv6 o ¼ TAAA þ TBUðMAG; LMAÞ þ TDAD þ TBUðMN;HAÞþ TRO þ TBUðMN;CNÞ þ TPT ð17Þ

As seen in Eq. (17), movement detection is not requiredwithin a PMIPv6 domain because of the mobility accessgateway [50].

The MN’s handoff latency within the PMIPv6 domain(DPMIPv6) [37] is calculated as follows:

DPMIPv6 ¼ TAAA þ TBUðMAG; LMAÞ þ TPT ð18Þ

Duplicate address detection does not occur because the ad-dress assigned by local mobility anchor is used by the MNin the entire PMIPv6 domain [13].

5.5.2. Signaling overhead in PMIPv6The signaling overhead in PMIPv6 (CPMIPv6) is incurred

because of the communication of local mobility anchorwith the new mobility access gateway (MAGn) and theold mobility access gateway (MAGo) for registration orderegistration of the MN, respectively [36].

CPMIPv6 ¼ BUregðMAGn; LMAÞ þ BUderegðMAGo; LMAÞ ð19Þ

where BUreg(MAGn, LMA) represents signaling overhead in-curred during registration of the MN at MAGn and is givenby

BUregðMAGn;LMAÞ¼ PBUs �hMAGn ;LMAþPBAs �hLMA;MAGn ð20Þ

BUdereg(MAGo, LMA) represents the signaling overhead in-curred during deregistration of the MN at the MAGo andit is formulated as follows:

BUderegðMAGo;LMAÞ¼ PBUs �hMAGo ;LMAþPBAs �hLMA;MAGo ð21Þ

5.6. Virtual Mobility Domain (VMD)

In this section, we provide the equations for handoff la-tency and signaling overhead incurred in VMD deployed inthe FCT future Internet architecture.

5.6.1. Handoff latency in VMDIntra-domain handoff delay in VMD (DVMD) includes

AAA procedure delay and binding update messaging be-tween AR and common anchor cloud of the old AR andthe new AR. In VMD, movement detection is not requiredas it is a network-based mobility management scheme.Duplicate address detection is also not required becauseVMD assigns a unique address to an MN as explained inSection 4.1. Hence, DVMD is given by

DVMD ¼ TAAA þ TBUðAR;CACÞ þ TPT ð22Þ

where CAC is the common anchor cloud between the old ARand the new AR. For example, if the MN enters the VMD forthe first time, or moves between the tier-2 clouds in Fig. 2,the CAC will be Root Cloud. If the MN moves between ARsconnected to the same tier-2 cloud, then the CAC will bethat tier-2 cloud.

5.6.2. Signaling overhead in VMDDuring an MN’s roaming in VMD, wired nodes (i.e., ARs,

and routers in the tier-1 and tier-2 network clouds) handlethe mobility management. The signaling overhead is in-curred because of the location update messaging betweenAR and the different entities in the VMD cloud. Signalingoverhead in VMD (CVMD) is expressed as follows:

CVMD ¼ BUregðARn;CACÞ þ BUderegðARo;CACÞ ð23Þ

where CAC is the common anchor cloud between the pre-vious AR (ARo) and the new AR (ARn).

BUreg(ARn, CAC) represents the signaling overhead in-curred during registration of the MN to ARn which requiresAAA_req and AAA_acc message exchanges between ARn andCAC. BUreg(ARn, CAC) is expressed as

BUregðARn;CACÞ ¼ AAA reqs � hARn ;CAC þ AAA accs � hCAC;ARn

ð24Þ

BUdereg(ARo, CAC) represents the signaling overhead in-curred to deregister the MN at ARo which requires L_deregmessage transmission between ARo and CAC. BUdereg(ARo,CAC) is calculated as follows

BUderegðARo;CACÞ ¼ L deregs � hCAC;ARo ð25Þ

5.7. Operational comparison

In this subsection, we highlight the operational differ-ences between VMD and the IPv6-based mobility proto-

2588 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

cols. Table 2 presents the features of these protocols foreasy comparison.

5.7.1. VMD vs. MIPv6VMD is different from IPv6-based mobility protocols as

it is based on a new FCT internetworking model that doesnot use IP addressing and IP-based routing protocols. In themobility management scheme, an MN uses only one ad-dress assigned under a VMD cloud. After an MN is regis-tered under the VMD, data packet forwarding between acorrespondent node and an MN is handled by the FCTpacket forwarding process as explained in Section 4.4and does not require route optimization. A correspondentnode directly sends data packets to the VMD. The networkclouds in the VMD forward data packets to the MN inaccordance with their forwarding bases. During the move-ment of the MN in the same VMD, only the MN entry in therelated forwarding bases is updated with a new downlinkaddress as stated in Section 4. Therefore, updating a corre-spondent node is not necessary. VMD supports a network-based mobility management scheme and wired nodes han-dle the mobility management on behalf of the MN as ex-pressed in Eqs. (22) and (23). This results in reducedlatency, signaling overhead, and wireless resource usageas described in Section 6.

5.7.2. VMD vs. HMIPv6In HMIPv6, the node movement within the HMIPv6 do-

main is not visible outside of the domain. However,HMIPv6 accomplishes this by using two addresses for anMN. As expressed in Eq. (14), HMIPv6 requires duplicateaddress detection and the MN is expected to involve inmobility management as HMIPv6 supports a host-basedmobility management while VMD supports a network-based mobility management. HMIPv6 uses tunneled datacommunications which require higher signaling overheadduring data packet transmission for an MN as comparedto VMD.

5.7.3. VMD vs. PMIPv6VMD and PMIPv6 are both network-based mobility man-

agement schemes. These protocols thus avoid movement

Table 2Qualitative comparison of MIPv6, HMIPv6, PMIPv6, and VMD.

Category MIPv6 HMIP

Mobility management Host-based Host-Network architecture Flat HieraTarget network IP IPOperating OSI layer 3 3Required infrastructure HA AR anRouter advertisement Broadcast BroadAddressing model Shared-prefix ShareMN address HoA RCoAAddress type IPv6 IPv6Address length (bits) 128 128Address change in domain Yes YesAddress assigned by HA MAPTunneling Inter-AS Intra-Duplicate address detection Yes YesRoute optimization Yes Yes

detection and duplicate address detection processes as seenin Eqs. (18) and (22). Different from PMIPv6, VMD providesthe collaborative mobility management which limits the ef-fect of the mobility related signaling to the network cloudsthat have MN profile in their proxy AAA servers as explainedin Section 3.2.2. This benefits in fewer message exchangesand lower latency as discussed in the next section. PMIPv6still requires tunneling for mobile node’s datacommunication.

6. Analytical and simulation results

In this section, we show the analytical results based onthe equations derived in Section 5. Furthermore, we set upthe network of Fig. 2 using OPNET simulator and imple-mented VMD, MIPv6, HMIPv6 and PMIPv6 to validate theanalytical results. The analytical and simulation resultsare collected for handoff latency, signaling overhead, andpacket loss.

6.1. Network setup and simulation configuration

The FCT internetworking model and the VMD schemeare implemented using OPNET modeler simulation tool[51]. For comparative analysis, HMIPv6 and PMIPv6 arealso implemented based on related RFC documents[12,13]. The AS network topology that is used for analyticaland simulation studies is shown in Fig. 4. ARs operateusing 802.11 g with a data rate of 54 Mbps. ARs sendlayer-2 beacons every 20 ms (ms) while router advertise-ments are uniformly distributed between 0.5 s and 1 s asper OPNET modeler default settings. The transmit poweris 0.05 W with a power threshold of �80 dBm. ‘‘WLAN Bea-con Efficiency Mode’’ in OPNET is disabled to have real bea-con transmission on wireless media. Coverage areas ofneighboring ARs overlap to avoid link breaks at the physi-cal layer. Wired links have a data rate of 5 Mbps, similar to[52]. To include the effect of distances, link L1 has propaga-tion delay of 2 ms, link L2 4 ms, and link L3 10 ms, similarto [52]. Wireless link propagation delay is assumed negligi-ble as it is in magnitudes of nanoseconds in this networksetup. We used the same propagation delay values in

v6 PMIPv6 VMD

based Network-based Network-basedrchical Hierarchical Tiered

IP FCT2 and 3 2 and 3

d MAP LMA and MAG VMDcast Unicast Unicastd-prefix Per-MN-prefix Shared-prefixand LCoA CoA Tiered address

IPv6 Tiered128 DynamicNo NoLMA VMD

AS Intra-AS NoNo NoYes Yes

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2589

calculating Eq. (3) for the analytical results. The data trafficfrom the correspondent node to the MN has uniform pack-et interarrival time of 10 ms, because each router processesa data packet every 10 ms. Network settings are basedmainly on those provided in [52] and OPNET modeler de-fault settings and decided primarily based on RFCs.

MIPv6 operates in the whole network of Fig. 4. Thehome network and the home agent are assumed outsideof the AS under consideration. For the operation ofHMIPv6, PMIPv6 and VMD, the AS network is consideredas a mobility domain. For HMIPv6, mobility anchor pointis located at Root Cloud. For PMIPv6, local mobility anchoris located at Root Cloud while the mobility access gatewayis located at each AR. We ensured that all the protocolsoperate under the same network settings.

The MN travels between AR1, AR2, AR3, and AR4 con-secutively – following the trajectory shown by the red2

line (in Fig. 4) at a steady speed of 30 km/h. The MN makesa successful handoff to each AR and waits for 2 min beforemoving to the coverage area of the next AR. This path ischosen because along the path the MN performs two differ-ent handoff types that we aim to observe, which are intra-cloud handoff (i.e., handoff 1 and handoff 3) and inter-cloud handoff (i.e., handoff 2 and handoff 4). These hand-offs enable us to assess the effect of architectural differ-ences such as mobility manager locations and thefundamentally different ways of handling handoff such asnetwork-based and host-based. We are interested in howmobility protocols react after the MN establishes a layer-2 connection to a new AR (see Section 5.1). Therefore, westructured the movement of the MN on a trajectory withthe steady speed and we did not use different mobility pat-terns. As the focus is on handoff performance, the investi-gations and results are limited to a single node that goesthrough the handoff process. The study of the competitionof mobile users’ on the wireless resources, possible hand-off/link failure, and packet collision/back-off delay areout-of-scope of this paper as stated in Section 5.1. TheMN’s handoffs are homogenously distributed to each ARs.The recorded readings were averaged over 20 simulationruns with different seeds and the standard deviation ofthe latency results are 0.3 s which does not change signif-icantly when the number of simulation runs are increased.

It was verified that the MIPv6, HMIPv6, and PMIPv6simulation performance complied with that described in[52,53]. Simulation logs for each protocol were carefullyexamined to see that each protocol executes all the pro-cesses stated in Section 5.

6.2. Handoff latency

Fig. 5 shows the latency results based on the equationspresented in Section 5. Fig. 6 presents the latency valuesrecorded using OPNET simulations. We observed a lowerthan 5% difference between analytical and simulation la-tency results in most cases. The higher latency results inthe simulation are caused by the varying values of move-

2 For interpretation of color in Fig. 4, the reader is referred to the webversion of this article.

ment detection TMD and duplicate address detection TDAD

mainly because these processes are modeled as randomprocesses by OPNET while the analytical results are basedon the analytical models of Section 5 and representative ofthose discussed in [36–38].

In OPNET simulation, router advertisements and move-ment detection are handled by ipv6_ra_host module. MNconsiders a new router advertisement, that comes fromthe new AR as a movement hint. In OPNET simulation logs,we observed that TMD gets values between 0.2 and 0.8 swhile TMD value used in analytical results is derived fromEq. (1).

In analytical papers, varying values are used for dupli-cate address detection delay (TDAD): 0.5 s [40] and 1–2 s[54]. In OPNET default MIPv6 network and our implemen-tation, we observed that TDAD gets varying values between1 s and 1.4 s. In our analytical study, we assign TDAD 1.2 s inaccordance with Eq. (2).

In the simulation, we also observed that the MN re-ceives data packet from correspondent node around 6–8 ms after the mobility related messaging is completed.This is less than TPT value expressed in Eq. (5). From thesimulation logs, we observed that mobility managementis completed just before data packet arrives to the AS net-work, which means that while the data packet travels be-tween correspondent node and Root Cloud (which takes10 ms), mobility management is in process. All the abovedifferences in the OPNET modeler and the equations resultin a difference of 9–10 ms which is approximately 5%.

The comparative performance of all the four protocolsare however similar in the analytical and simulationstudies. MIPv6 has the highest handoff latency acrossall the four handoff events – typically 2.927 s from theanalytical models and around 3 s from the simulationmodels. This is because MIPv6 is a macro-mobility proto-col and has no optimized operations for roaming acrosssubnets within a mobility domain. The MN has to informits home network and execute route optimization-relatedsignaling with correspondent node every time it changesits AR. Furthermore, movement detection and duplicateaddress detection procedures have to be executed foreach MN movement as expressed in Eq. (6). MIPv6 la-tency plots however are useful as benchmark againstwhich the performance of the other three protocols canbe compared.

HMIPv6 has reduced handoff latency, around 1.6 s asthe global identifier of the MN, which is its regional care-of address, never changes in the HMIPv6 domain. Thus,the MN does not have to inform either the home networkor the correspondent node when the MN connects to an-other AR. However, the MN has to create its on-link care-of address and execute duplicate address detection forthe new on-link care-of address when it connects to anew AR inside the mobility anchor point domain. After itsuccessfully decides on the on-link care-of address, it hasto register its on-link care-of address to the mobility an-chor point. As expressed in Eq. (14), the MN’s involvementin the on-link care-of address creation, binding update tothe mobility anchor point, and the wireless media usagein these processes explain the higher latency of HMIPv6compared to PMIPv6 and VMD.

Fig. 5. Analytical handoff latency results for MIPv6, HMIPv6, PMIPv6 and VMD.

Fig. 6. Handoff latency results for MIPv6, HMIPv6, PMIPv6 and VMD observed in OPNET simulations.

2590 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

PMIPv6 and VMD have very low latencies, in the orderof milliseconds compared to MIPv6 and HMIPv6 mainlybecause PMIPv6 and VMD are network-based mobilitymanagement protocols. Therefore, movement detectionand duplicate address detection procedures are avoided(Eqs. (18) and (22)). They also do not require MN’s involve-ment in mobility management and this avoids communi-cation over wireless links. Mobility management ishandled by the wired nodes. PMIPv6 and VMD have thesame mobility performance for inter-cloud movement(handoff 2 and handoff 4) of MN since mobility messagingoccurs between AR and Root Cloud in VMD, betweenmobility access gateway and local mobility anchor inPMIPv6 which incur same delay. However, during intra-cloud roaming (handoff 1 and handoff 3) VMD handoff la-tency is lower than PMIPv6. This is because in VMD the MNmovement is handled by the closest common anchor cloudbetween the old and new access routers that the mobilenode is moving across. For handoff 1 and handoff 3, thecommon anchor cloud is tier-2 cloud. Due to collaborativemobility management, VMD performs better than PMIPv6for the cases where the common anchor cloud is lowerthan the cloud under which the VMD was deployed. How-ever, in the case of PMIPv6, a mobility access gateway hasto communicate with a local mobility anchor for allhandoffs.

6.3. Packet loss

Fig. 7 shows the packet loss during the four handoffevents in OPNET simulation. The results show a trendsimilar to that observed with handoff latencies in Fig. 6.With a constant interarrival time between packets that

are sent from the correspondent node to the MN, thepacket loss will be proportional to the handoff latency.MIPv6 and HMIPv6 cause more than 290 and 160 packetloss, respectively. In PMIPv6 and VMD, the packet loss isaround 1.

6.4. Signaling overhead

Fig. 8 is the plot of signaling overhead in bytes underthe four handoff events and the four mobility protocolsfrom analytical models. Fig. 9 provides similar plots fromthe OPNET simulation. The analytical and simulation re-sults are identical. MIPv6 has a very high signaling over-head of 2356 bytes, because binding update andacknowledgments are to be exchanged between the MNand its home agent – in this case the home agent is consid-ered outside the mobility domain. As given in Eqs. (11) and(12), the route optimization process also requires severalmessage exchanges between the MN, the home agent,and the correspondent node.

The signaling overhead with HMIPv6, PMIPv6, and VMDare less than 610 bytes because the AS network has beendefined as the mobility domain and any signaling is thusconstrained to this mobility domain. In the case of HMIPv6,the signaling overhead is due to the exchange of bindingupdate and acknowledgment messages between the MNand the mobility anchor point as in Eq. (15). No signalingis required between the MN and the home agent, and theMN and the correspondent node as the global address ofMN remains unchanged. PMIPv6 has 608 bytes overheadbecause the binding update and acknowledgment mes-sages are longer as seen in Table 1 and a deregistrationmessage from the mobility access gateway of the previous

Fig. 7. Number of packets lost during the four handoff events observed in OPNET simulations.

Fig. 8. The analytical signaling overhead results during handoffs.

Fig. 9. Signaling overhead during handoffs observed in OPNET simulations.

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2591

AR to the local mobility anchor is required as expressed inEq. (19). In the case of VMD, the signaling overhead is 228bytes during handoff 1 and handoff 3 as the handoff ismanaged locally within the tier-2 cloud, where the cloudrouters communicate with ARs. However, for handoff 2and handoff 4 the signaling overhead is 456 bytes as com-munication among the tier-2 clouds and Root Cloud is re-quired for the handoff.

Number of mobility control message exchanges amongthe nodes are important because each message exchangerequires processing which may affect the handoff perfor-mance. Fig. 10 shows that MIPv6 has the highest numberof message exchanges due to the binding update and routeoptimization between home agent and correspondentnode as expressed in Eq. (8). HMIPv6 causes 6 message ex-changes due to binding update process while PMIPv6

Fig. 10. The analytical number of message exchange results during handoffs.

Fig. 11. Analytical results for impact of wireless link delay over handoff latencies in MIPv6, HMIPv6, PMIPv6, and VMD (intra-cloud and inter-cloud).

2592 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

causes 8 message exchanges due to additional deregistra-tion process as expressed in Eqs. (15) and (19), respec-tively. VMD executes 3 message exchanges for intra-cloud handoff and 6 message exchanges for inter-cloudhandoff as expressed in Eq. (23). In VMD, a mobile nodedoes not involve in message exchanges, only access routersand the common anchor cloud which causes fewer mes-sage exchanges.

6.5. Factors affecting handoff latency

We provided overall comparison of handoff latency per-formances of the protocols in Section 6.2. Mobility proto-cols’ performance is sensitive to wireless/wired linkquality, network density, and network setup which mayvary in real-world situations. Therefore, we investigatehow mobility protocols get affected from changing wire-less/wired link delays and movement detection delays.Our analysis is based on the analytical models in Section 5,as it is convenient to adjust the parameters contributing tothe handoff latency.

6.5.1. Wireless link effect on handoff latencyWireless communication delay comprises transmis-

sion delay, propagation delay, and access latencydepending on network density, wireless medium, andcommunication technology. In Fig. 11, we present the

effect of varying wireless communication delay, namelywireless link delay, on the mobility protocols’ handoffperformance. The network setup and all parameters ex-plained in Section 6.1 are maintained the same. As seenin Fig. 11, handoff latencies in each protocol increaseswith different magnitudes. MIPv6 is the most affectedprotocol with 70 ms increase for the 10 ms incrementstep in the wireless link delay. As expressed in Eq.(6), the MN involves in binding update with the homeagent and the correspondent node (TBU(MN, HA) andTBU(MN, CN) respectively), and also route optimization(TRO) procedures which require a high level of messageexchange over wireless medium. HMIPv6 latency in-creases by 30 ms for each 10 ms increment on wirelesslink delay since the MN only does binding update withthe mobility anchor point once. On the other hand,PMIPv6 and VMD are affected from wireless link delaychanges only because of the data packet transmission(TPT), which is also present in all protocols’ latency cal-culation. The bottom right of Fig. 11 shows the en-larged view of the PMIPv6 and VMD results. PMIPv6and VMD inter-cloud handoff latencies continue tooverlap as explained in the previous section. The differ-ence between VMD intra-cloud handoff and inter-cloudhandoff stays the same, which is 8 ms caused by theround-trip over the wired link between the tier-2 cloudand the Root Cloud.

Fig. 12. Analytical results for impact of wired link delay between AR and Root Cloud over handoff latencies in MIPv6, HMIPv6, PMIPv6, and VMD (intra-cloud and inter-cloud).

Fig. 13. Analytical results for impact of wired link delay between Root Cloud and correspondent node or home agent over handoff latencies in MIPv6,HMIPv6, PMIPv6, and VMD (intra-cloud and inter-cloud).

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2593

6.5.2. Wired link effect on handoff latencyWired communication may be affected by various fac-

tors such as the network congestion, quality of the wiredlinks, and distance between nodes. The varying perfor-mance of wired communication is represented with wiredlink delay in Figs. 12 and 13, where we aim to capture theeffect of wired communication delay on mobility protocols’performance. Our analysis is twofold: (i) the links in themobility domain and (ii) the links outside the mobility do-main, mainly to observe performance of micro-mobilityand macro-mobility protocols distinctly.

The wired link delay between AR and Root Cloudnamely, L1 and L2 in Fig. 4 are set identical and are givenvarying values to observe the effect of wired link delay inthe mobility domain. All the other parameters stated inSection 6.1 are kept the same. Fig. 12 depicts that MIPv6is the most effected protocol with 70 ms increase for each10 ms increment on wired link delay, since binding mes-sages and route optimization messages are transferredthrough the wired links between AR and Root Cloud. On

the other hand, handoff in HMIPv6, PMIPv6, and VMD-in-tra-cloud increase by 30 ms for a 10 ms step-up on wiredlink delay since only the binding messages are transferredon the link between AR and Root Cloud. However, intra-cloud handoffs in the VMD gets affected least (20 ms),since the mobility related messaging only occur betweenAR and tier-2 cloud, and not Root Cloud.

We next vary delays on the links between Root Cloudand home agent/correspondent node, namely L3 in Fig. 4to show the effect of communicating with correspondentnode or home agent that are outside of the mobility do-main. As in Fig. 13, MIPv6 is most affected with 110 ms in-crease for 10 ms increment on the link delay since MIPv6 isa macro-mobility management protocol and MN informshome agent and correspondent node for every movement.However, micro-mobility protocols do not require inform-ing home agent or correspondent node because the intra-domain movements of MN are only visible to local domainand handled by mobility anchor point, local mobility an-chor or VMD depending on the protocol. In PMIPv6,

Fig. 14. Analytical results for effect of movement detection delay over the handoffs in mobile IP protocols and VMD.

2594 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

HMIPv6, and VMD, the increase in handoff latency is onlydue to the data packet transmission from correspondentnode.

6.5.3. Movement detection effect on handoff latencyMovement detection delay may depend on several fac-

tors such as AR configuration, router advertisement inter-val time, wireless medium, and access technology. Fig. 14presents the impact of varying TMD over the handoff laten-cies. In PMIPv6 and VMD, layer 3 movement detection isnot required since these protocols deploy mechanisms tocontrol MN’s attachment or detachment such as layer-2triggers. Therefore, from the perspective of the MN, theVMD or the PMIPv6 domain appears as a home network.On the other hand, MIPv6 and HMIPv6 handoff delays in-crease by the increase in TMD. MIPv6 and HMIPv6 requiremovement detection of an MN as they are host-basedmobility protocols and MN has to get new address at thenew AR.

7. Conclusion and future work

In this article, we have presented a new mobility man-agement protocol based on a Virtual Mobility Domain con-cept that is implemented in the proposed FCTinternetworking model [8]. A VMD is defined as a virtualnetwork cloud, which can be supported under a networkcloud at an upper tier. MNs are given an address underthe virtual network cloud to roam within the VMD. VMDsupports network-based collaborative mobility manage-ment. A comparative analytical and simulation study ofVMD is conducted with MIPv6, HMIPv6, and PMIPv6, astheir specifications are available and this study is targetedas a benchmark for future comparative studies.

Seamless roaming has been assessed based on handofflatency, packet loss, and signaling overhead during hand-off. VMD manages intra-cloud handoff in 98.9%, 98.7%,and 28.5% less time compared to MIPv6, HMIPv6, andPMIPv6 respectively. VMD manages inter-cloud handoffin 98.7% and 98.2% less time compared to MIPv6 andHMIPv6, and in the same time as PMIPv6. In terms of sig-naling overhead for intra-cloud and inter-cloud handoffs

respectively, VMD performs 90.3% and 80.6% better com-pared to MIPv6, 32.1% better and 35.7% worse comparedto HMIPv6, and 62.5% and 25% better compared to PMIPv6.

Collaborative mobility management helps VMD to per-form better during intra-cloud handoffs as compared to in-ter-cloud handoffs while IPv6-based mobility protocols donot exhibit any improvement. The performance resultsshow the potential for better seamless mobility manage-ment with new mobility management approaches thatcan be achieved with the new Internet architectures. Thepresented work has been limited to the introduction andperformance improvements achieved by the VMD ap-proach when deployed within an AS. Future work will in-clude evaluation under inter-AS roaming scenarios andoptimization based on the level of tiers supported undera VMD considering user requirements and quality ofservice.

References

[1] National Science Foundation Future Internet Design Initiative.<http://www.nets-find.net/>.

[2] National Science Foundation Future Internet Architecture Project.<http://www.nets-fia.net/>.

[3] European Future Internet Portal. <http://www.future-internet.eu/>.[4] Asia Future Internet Forum. <http://www.asiafi.net/>.[5] New Generation Network Research Center. <http://www2.nict.go.jp/

w/w100/index-e>.[6] P. Roberts, J. Kempf, Mobility architecture for the global internet, in:

Proceedings of First ACM/IEEE International Workshop on Mobilityin the Evolving Internet Architecture, MobiArch ’06, ACM, New York,NY, USA, 2006, pp. 23–28.

[7] A. Mohammad, A. Chen, Seamless mobility requirements andmobility architectures, in: Global Telecommunications Conference,2001. GLOBECOM ’01, vol. 3, IEEE, 2001, pp. 1950–1956.

[8] Y. Nozaki, H. Tuncer, N. Shenoy, A tiered addressing scheme based ona floating cloud internetworking model, in: Proceedings of the 12thInternational Conference on Distributed Computing and Networking,ICDCN’11, Springer-Verlag, Berlin, Heidelberg, 2011, pp. 382–393.

[9] N. Shenoy, M. Yuksel, A. Gupta, K. Kar, V. Perotti, M. Karir, RAIDER:responsive architecture for inter-domain economics and routing, in:GLOBECOM Workshops (GC Wkshps), 2010 IEEE, 2010, pp. 321–326.

[10] H. Tuncer, Y. Nozaki, N. Shenoy, Virtual domains for seamless usermobility, in: Proceedings of the 9th ACM International Symposiumon Mobility Management and Wireless Access, MobiWac ’11, ACM,New York, NY, USA, 2011, pp. 125–130.

[11] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6, RFC 3775(Proposed Standard), June 2004.

H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596 2595

[12] H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier, Hierarchical MobileIPv6 (HMIPv6) Mobility Management, RFC 5380 (ProposedStandard), October 2008.

[13] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, ProxyMobile IPv6, RFC 5213 (Proposed Standard), August 2008.

[14] K.-T. Tran, V. Gondi, N. Agoulmine, Analysis of client-based andnetwork-based mobility protocols, in: 2010 IEEE InternationalConference on Communications (ICC), 2010, pp. 1–5.

[15] I. Akyildiz, J. Xie, S. Mohanty, A survey of mobility management innext-generation all-IP-based wireless systems, WirelessCommunications, IEEE 11 (4) (2004) 16–28.

[16] H. Soliman, Mobile IPv6: Mobility in a Wireless Internet, Addison-Wesley, 2004.

[17] R. Koodli, Mobile IPv6 Fast Handovers, RFC 5568 (ProposedStandard), July 2009.

[18] H. Jung, H. Soliman, S.J. Koh, J.Y. Lee, Fast Handover for HierarchicalMIPv6 (F-HMIPv6), Internet draft, October 2005.

[19] H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia, Fast Handovers forProxy Mobile IPv6, RFC 5949 (Proposed Standard), September 2010.<http://www.ietf.org/rfc/rfc5949.txt>.

[20] A. Gurtov, Host Identity Protocol (HIP): Towards the Secure MobileInternet, No. ISBN: 978-0-470-99790-1, WILEY, August 2008.

[21] D. Farinacci, Locator/ID Separation Protocol (LISP), Internet draft,2009.

[22] R. Hinden, New Scheme for Internet Routing and Addressing(ENCAPS) for IPNG, RFC 1955 (Informational), June 1996.

[23] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I. Stoica, ROFL:routing on flat labels, in: Proceedings of the 2006 Conference onApplications, Technologies, Architectures, and Protocols forComputer Communications, SIGCOMM ’06, ACM, New York, NY,USA, 2006, pp. 363–374.

[24] J. Pan, S. Paul, R. Jain, M. Bowman, MILSA: a mobility andmultihoming supporting identifier locator split architecture fornaming in the next generation internet, in: GlobalTelecommunications Conference, 2008. IEEE GLOBECOM 2008,IEEE, 2008, pp. 1–6.

[25] S.C. Nelson, G. Bhanage, D. Raychaudhuri, GSTAR: generalizedstorage-aware routing for mobilityfirst in the future mobileinternet, in: Proceedings of the Sixth International Workshop onMobiArch, MobiArch ’11, ACM, New York, NY, USA, 2011, pp. 19–24.

[26] A. Anand, F. Dogar, D. Han, B. Li, H. Lim, M. Machadoy, W. Wu, A.Akella, D. Andersen, J. Byersy, S. Seshan, P. Steenkiste, XIA: AnArchitecture for an Evolvable and Trustworthy Internet, Tech. Rep.CMU-CS-11-100, Department of Computer Science, CarnegieMellon- University, February 2011.

[27] 3GPP, General Packet Radio Service (GPRS) Service Description:Stage 2, 3rd ed., June 2006.

[28] S. Zhuang, K. Lai, I. Stoica, R. Katz, S. Shenker, Host mobility using aninternet indirection infrastructure, Wireless Networks 11 (2005)741–756.

[29] N.I. of Information, C.T.N. of Japan, New Generation NetworkArchitecture AKARI Conceptual Design v 1.1, Tech. Rep., October2008. <http://akari-project.nict.go.jp/eng/index2.htm>.

[30] N. Niebert, M. Prytz, A. Schieder, N. Papadoglou, L. Eggert, F.Pittmann, C. Prehofer, Ambient networks: a framework for futurewireless internetworking, in: Vehicular Technology Conference,2005. VTC 2005-Spring. 2005 IEEE 61st, vol. 5, 2005, pp. 2969–2973.

[31] P.P. Aguiar R., Final Daidalos ii Global Architecture, Tech. Rep. DII-124, October 2008. <http://www.ist-daidalos.org/daten/publications/pu_deliverables.htm>.

[32] A. Eriksson, B. Ohlman, Dynamic internetworking based on latelocator construction, in: IEEE Global Internet Symposium, 2007, pp.67–72.

[33] X. Yang, D. Clark, A. Berger, NIRA: a new inter-domain routingarchitecture, IEEE/ACM Transactions on Networking 15 (4) (2007)775–788.

[34] Y. Nozaki, H. Tuncer, N. Shenoy, ISP tiered model based architecturefor routing scalability, in: 2012 IEEE International Conference onCommunications Workshops (ICC), 2012.

[35] H. Tuncer, Y. Nozaki, N. Shenoy, Virtual mobility domains – amobility architecture for the future internet, in: 2012 IEEEInternational Conference on Communications (ICC), 2012.

[36] J.-H. Lee, Y.-H. Han, S. Gundavelli, T.-M. Chung, A comparativeperformance analysis on Hierarchical Mobile IPv6 and Proxy MobileIPv6, Telecommunication Systems 41 (2009) 279–292, http://dx.doi.org/10.1007/s11235-009-9163-z.

[37] K.-S. Kong, W. Lee, Y.-H. Han, M.-K. Shin, H. You, Mobilitymanagement for all-IP mobile networks: Mobile IPv6 vs. proxyMobile IPv6, Wireless Communications, IEEE 15 (2) (2008) 36–45.

[38] Yong Li, Haibo Su, Li Su, Depeng Jin, Lieguang Zeng, AComprehensive Performance Evaluation of PMIPv6 over IP-BasedCellular Networks, in: Vehicular Technology Conference, 2009. VTCSpring 2009. IEEE 69th, 2009, pp. 1–6.

[39] J.-H. Lee, T. Ernst, T.-M. Chung, Cost analysis of IP mobilitymanagement protocols for consumer mobile devices, IEEETransactions on Consumer Electronics 56 (2) (2010) 1010–1017.

[40] C. Makaya, S. Pierre, An analytical framework for performanceevaluation of IPv6-based mobility management protocols, IEEETransactions on Wireless Communications 7 (3) (2008) 972–983.

[41] T. Narten, E. Nordmark, W. Simpson, H. Soliman, Neighbor Discoveryfor IP version 6 (IPv6), RFC 4861 (Draft Standard), updated by RFC5942, September 2007.

[42] Y.-H. Han, S.-H. Hwang, Movement detection analysis in MobileIPv6, Communications Letters, IEEE 10 (1) (2006) 59–61.

[43] S. Thomson, T. Narten, T. Jinmei, IPv6 Stateless AddressAutoconfiguration, RFC 4862 (Draft Standard), September 2007.

[44] Z. Liang, J. Zheng, S. Ma, S. Yang, B. Wang, J. Liu, Modeling andanalysis of queuing effect on Mobile IPv6 handoff performance, in:2010 IEEE 21st International Symposium on Personal Indoor andMobile Radio Communications (PIMRC), 2010, pp. 2282–2287.

[45] J. Xie, I. Howitt, I. Shibeika, IEEE 802.11-Based Mobile IP Fast HandoffLatency Analysis, in: ICC ’07. IEEE International Conference onCommunications, 2007, pp. 6055–6060.

[46] H. Fathi, S.S. Chakraborty, R. Prasad, Optimization of Mobile IPv6-based handovers to support VoIP services in wireless heterogeneousnetworks, IEEE Transactions on Vehicular Technology 56 (1) (2007)260–270.

[47] R. Droms, J. Bound, B. Vloz, T. Lemon, C. Perkins, M. Carney, DynamicHost Configuration Protocol for IPv6 (DHCPv6), RFC 3315 (StandardsTrack), July 2003.

[48] J. Arkko, C. Vogt, W. Haddad, Enhanced Route Optimization forMobile IPv6, RFC 4866 (Proposed Standard), May 2007.

[49] J. Korhonen, V. Devarapalli, Local Mobility Anchor (LMA) Discoveryfor Proxy Mobile IPv6, RFC 6097 (Informational), February 2011.

[50] J. Laganier, S. Narayanan, P. McCann, Interface between a ProxyMIPv6 Mobility Access Gateway and a Mobile Node, Internet draft,February 2008.

[51] OPNET Technologies, Inc. <http://www.opnet.com>.[52] X. Pérez-Costa, M. Torrent-Moreno, H. Hartenstein, A performance

comparison of Mobile IPv6, hierarchical Mobile IPv6, fast handoversfor Mobile IPv6 and their combination, SIGMOBILE MobileComputing and Communications Review 7 (2003) 5–19.

[53] F.F. Liza, W. Yao, Implementation architecture of proxy Mobile IPv6protocol for NS2 simulator software, in: Proceedings of the 2009International Conference on Communication Software andNetworks, ICCSN ’09, IEEE Computer Society, Washington, DC, USA,2009, pp. 287–291.

[54] H. Jeong, S. Maeng, Y. Chae, HIMIPv6: an efficient IP mobilitymanagement protocol for broadband wireless networks, IEICETransactions on Information and Systems E92.D (10) (2009) 1857–1866.

Hasan Tuncer received his B.S. degree inComputer Engineering in 2007 from KocUniversity, Istanbul, Turkey. In 2007, he star-ted to pursue a Ph.D. degree in Computing andInformation Sciences at Rochester Institute ofTechnology (RIT) in Rochester, NY. He ismember of wireless networking and securitylab at RIT since then. His research interests arein the area of Internet architecture, wirelessnetworks and protocols, mobility models andmanagement in wireless networks.

2596 H. Tuncer et al. / Computer Networks 57 (2013) 2578–2596

Andres Kwasinski received in 1992 hisdiploma in Electrical Engineering from theBuenos Aires Institute of Technology, BuenosAires, Argentina, and the M.S. and Ph.D.degrees in Electrical and Computer Engineer-ing from the University of Maryland, CollegePark, Maryland, in 2000 and 2004, respec-tively. He is currently an Assistant Professor atthe Department of Computer Engineering,Rochester Institute of Technology, Rochester,New York. Prior to this he was with TexasInstruments Inc., the Department of Electrical

and Computer Engineering at the University of Maryland, and LucentTechnologies. He is Area Co-Editor (Columns and Forums) for the IEEESignal Processing Magazine. Also, he is the Chair for the IEEE Multimedia

Technical Committee Interest Group on Distributed and Sensor Networksfor Mobile Media Computing and Applications and had been the Globe-com 2010 Workshop Co-Chair. Dr. Kwasinski has co-authored the book’’Cooperative Communications and Networking’’ (Cambridge UniversityPress, 2009). His research interests are in the area of multimedia wirelesscommunications and networking, cross layer designs, multiple access towireless networks, user cooperative communications, cognitive radio,

digital signal processing and speech, image and video processing forsignal compression and communication.

Nirmala Shenoy received her Ph.D. from theUniversity of Bremen (West Germany) in1991 in Computer Science, a Master’s inEngineering in the field of Applied Electronicsand a Bachelor’s in Engineering in Electronicsand Telecommunications from Madras Uni-versity, India. She worked several years as aresearch scientist in the Council of Scientificand Industrial Research Labs in India. Shesubsequently took up teaching and hasworked as an academic in Singapore andAustralian universities. She is currently an

Associate Professor in the Information Technology Department atRochester Institute of Technology. Her research interests are in the area ofInternet architecture, Quality of service, wireless networks and protocols,

mobility models and management in wireless networks and wirelessInternet.