Muslam et al. EURASIP Journal on Wireless Communicationsand Networking (2017) 2017:71DOI 10.1186/s13638-017-0853-zRESEARCHOpen AccessDistributed mobility management withmobile Host Identity Protocol proxyMuhana M. Muslam1*, H. Anthony Chan2 and Neco Ventura3AbstractThe architectural evolution from hierarchical to flatter networks creates new challenges such as single points offailure and bottlenecks, non-optimal routing paths, scalability problems, and long handover delays. The cellularnetworks have been hierarchical so that they are largely built on centralized functions based on which theirhandover mechanisms have been built. They need to be redesigned and/or carefully optimized. The mobilityextension to Host Identity Protocol (HIP) proxy, mobile HIP Proxy (MHP), provides a seamless and secure handoverfor the Mobile Host in the hierarchical network. However, the MHP cannot ensure the same handover performancein flatter network because the MHP has also utilized the features offered by the hierarchical architecture. This paperextends the MHP to distributed mobile HIP proxy (DMHP). The performance evaluation of the DMHP in comparisonto MHP and other similar mobility solutions demonstrates that DMHP does indeed perform well in the flatternetworks. Moreover, the DMHP supports both efficient multi-homing and handover management for many mobilehosts at the same time to the same new point of attachment.Keywords: Handover, Distributed mobility, Mobility management, Mobility proxy1 IntroductionCellular network is evolving from a hierarchical to aflatter architecture [1]. The nature of a hierarchicalarchitecture can be harnessed to efficiently and seamlessly support host mobility. This is because it is possibleto select/identify between a mobile host (MH) andcorrespondent host (CH) a functional entity, which canbe updated on the MH’s current location. Consequently,handover performance will be optimized since theselected entity is topologically closer than the CH to theMH. Unfortunately, that specific aspect of a hierarchicalarchitecture’s nature that allows the selection of a centralentity for handover optimization is no longer available ina flat architecture where entities are distributed acrossdifferent networks.The architectural evolution from hierarchical to flatternetworks to handle increased data traffic volumescreates new challenges as identified in [1]. These challenges include single points of failure and bottlenecks,non-optimal routing paths, scalability problems, and* Correspondence: [email protected] of Information Technology, Al-Imam Muhammad Ibn SaudIslamic University, Riyadh, Saudi ArabiaFull list of author information is available at the end of the articlelong handover delays. Consequently, the handovermechanisms such as [2–4] that have been built based onthe centralized mobility function need to be redesignedand/or carefully optimized again.To support mobility with both Host Identity Protocol(HIP) hosts and non-HIP hosts in hierarchical networks,HIP proxy and mobile HIP can be integrated into mobileHIP proxy (MHP). In [3], we had presented a preliminary design of the MHP which was able to supportcentralized mobility management only. It therefore stillhas all the drawbacks of centralized mobility management described in [1]. For the host mobility support inflat network architectures, an improved design of theMHP to take the role of mobility anchor will achievedistributed mobility. This paper introduces such anetwork-based and distributed mobility management. Itdistributes to the access networks such as mobilityanchors based on an improved design of the MHPs tosupport the IP hosts in all these networks. The proposeddistributed mobile HIP proxy (DMHP) enables hostmobility in a flat network architecture and addressesproblems of handover delay, scalability, single point offailure, packet loss, and signaling overhead. Furtherenhancement can be added to our proposal, DMHP, by The Author(s). 2017 Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0International License (, which permits unrestricted use, distribution, andreproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link tothe Creative Commons license, and indicate if changes were made.

Muslam et al. EURASIP Journal on Wireless Communications and Networking (2017) 2017:71(1) using an optimization model to provide useful theoretical insights and a protocol of distributed data querysuch as one presented in [5] and (2) using a distributedonline algorithm that employs an optimal stoppingtheory to let nodes make adaptive, online decisions onwhether this communication opportunity should beexploited to deliver data packets in each meeting eventas explained in [6]. Although the method in [5] is developed to efficiently allow data query in a Mobile Ad hocSocial Network (MASON), many of its ideas can beemployed by DMHP, i.e., designed for infrastructurenetworks without centralized host mobility support, thatmay lead to further improvement.The main contributions in this paper are (1) introducinga network-based distributed mobility management solution for MHs in flat networks, (2) developing an architecture using the advantages of host identity protocol (HIP)for both HIP-enabled MH and non-HIP-enabled MH tosupport secured mobility and multi-homing, (3) developing mechanisms to enable our proposed solution, DMHP,to manage the handover of several MHs to the same newpoint of attachment (N-PoA), and (4) qualitatively andquantitatively investigating our proposed solution, DMHP,as well as some widely referenced distributed mobilitysolutions.The rest of the paper is organized as follows: Section 2reviews the related work. Section 3 presents the proposedsolution while Section 4 presents the simulation resultsand performance analysis. Section 5 concludes the paper.2 Related workMany mobility solutions have employed the networkbased approach to provide mobility support to hosts thatlack mobility support capability. For example, ProxyMIPv6 (PMIPv6) [4] extends mobile IPv6 (MIPv6) [7] toprovide network-based mobility support which is notimplemented in the MH protocol stack. However,PMIPv6 relies on the dual role of IP addresses for hostidentity and locator, and it lacks scalable mobility supportand required extensions to work in a flat networkarchitecture.Furthermore, in [8–10], authors extend PMIPv6 to provide network-based distributed IP mobility managementsolutions. However, these solutions need to communicatewith some central or distributed entity to verify andvalidate the handed over mobile hosts, thereby incurringadditional delay and signaling. In [10], authors have proposed a mobility solution, called multiple local mobilityanchor (MLMA), in which authors used the PMIPv6 whileemploying a replicating strategy. Since MLMA supportsthe host mobility management in flatter networks, i.e., thesame context our proposal is prepared for, further detailsabout MLMA are presented and its handover proceduresare shown in Fig. 1. As shown in this figure which explainsPage 2 of 12the MH’s handover procedure, the network consists ofmany access networks represented by access routers (AR),AR1 to ARn. MLMA has replicated the PMIP’s localmobility anchor (LMA) into each of the ARs, AR1 toARn, as well as the gateway router (GW).In the MLMA, when the MH performs the handoverfrom an access network through which the MH hasestablished the active session, at AR1 collocated withLMA, to another access network, at AR2 which detectsthe attachment of the MH and sends an proxy bindingupdate (PBU) packet to all ARs and GW in the network.When the ARs and the GW in the network receive thePBU, they all reply with proxy binding acknowledgment(PBA) packets, one packet from each. Therefore, MHdata traffic routing is improved. However, the MLMAhas the following shortcomings: (1) large buffer isneeded in each AR collocated with LMA to maintain arecord for each MH in the network in which host mobilityis managed by MLMA; (2) additional time is needed tosearch the database of MH records involving maybesimple but rather large buffer, when MH performs a handover, on when to receive packets for each of the MHs inthe network; (3) high signaling overhead for the new ARof MH to update all the other ARs and GW inside the network in which host mobility is managed by MLMA; and(4) MLMA does not have any mechanism that supportmanagement of handover of many MHs to the new AR.We have presented in [3] a preliminary mobility management design of MHP. It provides seamless, securehandovers for both HIP-enabled and non-HIP-enabledmobile hosts without unnecessary signaling overheads tothe hosts. However, it is only a centralized approach.The papers [11, 12], and [13] have developed networkbased distributed mobility solutions using ID/locatorseparation architecture. However, [11] and [12] is onlyconcerned with network mobility, whereas [13] leveragesneither network-based mobility support for host norHIP proxy.Although the PMIPv6 and MHP achieve a good handover performance in the hierarchical network architecture,there is a need for mobility solutions to respond to thechallenges of evolving the network architecture frombeing hierarchical to being flat.The preliminary design of MHP we reported in [3]combines mobility function with the HIP proxy function.Yet its mobility function is not serving as a mobility anchor but rather is equivalent to that of a mobile accessgateway in PMIPv6. It relies on another centralized entity to serve as a mobility anchor to support mobility.MHP is therefore a centralized mobility managementprotocol with the drawbacks described in [1].Distributed mobility management function is moregeneral and more capable of serving the future mobileinternet which continues to flatten. Compared to our

Muslam et al. EURASIP Journal on Wireless Communications and Networking (2017) 2017:71MHAR3AR2AR1LMAPage 3 of 12ARnGWLMALAM LMALMAPBU/PBAPBU/PBA PBU/PBAMH detachMH attachSame IPPBU/PBAFig. 1 MH handover procedures using MLMApreliminary design, we have enriched the MHP functionto act as a mobility anchor, which collocates at the access router. Distributed mobility management is thensupported by these mobility anchors. There is no longerneed to rely on a separate centralized entity, as in [3],which is now removed. The elimination of a centralizedanchor also simplifies signaling.3 Network-based distributed mobilitymanagementThis section introduces a network-based distributed mobility management solution that distributes the MHPs tothe access networks to provide HIP and mobility supportto all IP hosts. These mobility management functions ofthe MHP do not rely on any centralized mobility function such as the local mobility anchor in [2, 4] and thelocal rendezvous server in [3]. The MHPs are also included at the access routers taking advantage of the HIPproxy capability. They enable handover of mobile hostsin the flat network architecture with good performance.They enable an MH, whether or not HIP enabled, to usethe same IP address as it changes its points of attachments within the flat network architecture. To supportBind HIT(MH)DNSIP(RVS)RVSthe distributed solution, MHPs provide the followingfunctions: (1) each proxy serves as local mobility anchorfor all connections established through it (proxy); (2)each proxy updates its neighbor proxies about the MHsthat established their connections through it so the newproxy can determine the previous proxy from a distributed database; (3) a new proxy serves a mobile gatewayand establishes channel between the previous and newproxies; and (4) a new proxy sends directly to CH thetraffic for connections established through it and sendsvia previous proxies the traffic for connections established through other proxies.3.1 Mobility management architectureThe architecture for network-based distributed mobilitymanagement with a mobile HIP proxy is shown inFig. 2.The rendezvous server (RVS) [14] with the DNSenables reachability of an HIP host by maintaining amapping between the host identity, called HIT, and theIP address of the MH. This design, called distributedmobile HIP proxy, adds a set of co-located mobility andHIP proxy functions at the access router. Like the MHPBind HIT(MH)IP(proxy)GW routerMobility-HIP-proxyMobility-HIP-proxyBind HIT(MH)Bind )IP(proxy)IP(MH)Subnet2Subnet1MHFig. 2 Design of network-based distributed mobility management and HIP proxyBS/APBS/APMoveMH

Muslam et al. EURASIP Journal on Wireless Communications and Networking (2017) 2017:71[3] for the hierarchical network architecture, the mobileHIP proxy performs HIP signaling on behalf of non-HIPMH so that HIP services can be offered to non-HIPenabled hosts. It also tracks the movement of the MHand updates the MH binding record if the MH is moving away from the network during an established sessioneven when the session is active. The binding information, which is shown in a table in Fig. 2, is managed inthe hierarchy DNS-RVS-proxy to enable reachability ofan MH which is registered with the mobility-enabledHIP proxy.3.2 Registration and reachabilityBefore using an HIP service, an HIP host needs to registerwith the service using the registration mechanism definedin [15]. The registration of an MH, which may either beHIP enabled or not, is illustrated in Fig. 3. This figureillustrates an example flow diagram of DMHP operationsfor the attachment of an HIP enabled MH and a non-HIPenabled MH.Upon detection of a MH attachment, the MHP checkswhether the MH is HIP enabled or not. If not, the MHPassigns a HIT and returns it to the MH. The MHP usesthe HIT, from the HIP MH or the assigned one for nonHIP MH, to check whether the MH is registered or not.If it is not registered, the MHP sends an update messageto the RVS, which is the intermediate server of locationinformation between the MHP entities and the DNSservers.After registration, the mobile HIP proxy contains thebinding of the HIT of the MH, HIT (MH), to the IPaddress of the MH, IP (MH). The RVS contains thebinding of the HIT of the MH, HIT (MH), to the IPaddress of the proxy, IP (proxy). The DNS contains thebinding of the HIT of the MH, HIT (MH), to the IPaddress of the RVS, IP (RVS).If the MH has more than one interface, it has to registerthe physical address for each of its interfaces with its hostidentity, HIT (MH). For example, if the MH has two interfaces and their physical addresses are PHYaddr1 andPHYaddr2, then MH registers its HIT (MH) with both itsSTARTDETECT ATTACHMENT OF MHINITIATE REGISTRATION OF MH;ASSIGN IDENTIFIER TO MHNOIS MH HIP ENABLED?YESSEND UPDATE INFO TO MOBILITY ANCHORRECEIVE CONFIRMATION OF UPDATE INFOCONFIGURE MH’S ROUTING ADDRESSUPDATE BINDING INFORMATIONENDFig. 3 Attachment detection for an HIP and a non-HIP MHPage 4 of 12physical addresses, PHYaddr1(MH) and PHYaddr2(MH).This information will be registered at the MHP throughwhich the MH is attached during the registration process.This information is also accessible from other MHPs towhich the MH is possible to move/connect. Therefore, theMH uses its identity, HIT (MH), to find its record andthus be able to preserve its ongoing communicationsessions even those established via other interface so as tosupport multi-homing.3.3 Establishing communication sessionsThis distributed mobility management design enablesdata traffic between either an HIP-enabled MH or nonHIP-enabled MH and a CH. A Security Association (SA)is set up prior to the transport of data plane traffic. Ifthe MH is an HIP host, the SA ends or terminates at theMH. If the MH is not an HIP host, the SA ends at themobile HIP proxy to which the MH is registered.Like the MHP, two pairs of initiation-response packets(I1, R1 and I2, R2) are exchanged to prepare for an SAestablishment. Figure 4 illustrates an example flowdiagram of MHP operations in establishing an HIP baseexchange (HIPBE) between an HIP-enabled MH and anHIP-enabled CH. In addition, the figure illustrates anexample flow diagram of MHP operations in establishingan HIPBE between a non-HIP enabled MH and an HIPenabled CH.Upon receiving an I1 packet from the CH, the RVSchecks if the destination HIT corresponds to that of aregistered MH. If so, the I1 packet is forwarded to theregistered IP address of the proxy. Upon receiving an I1packet from the RVS, the mobile HIP proxy checks thedestination HIT in the HIP header. If the destinationHIT corresponds to that of a registered HIP-enabledMH, the mobile HIP proxy (proxy1) forwards the I1packet to the MH. The mobile HIP proxy does not storeany binding in the case of the HIP MH. The MH willstore the binding HIT (CH):IP (CH), and the MH willsend the reply R1.If the destination HIT corresponds to that of a registeredMH which is not HIP enabled, the mobile HIP proxy(proxy2) stores the binding HIT (CH):IP (CH). The mobile HIP proxy (proxy2) will send the reply R1 on behalfof the MH.After the successful exchange of the two initiationresponse packet pairs, an HIP SA will be establishedbetween the initiator and responder. In data traffic, theHIP proxy (proxy2) uses the HIP SA and ESP to encapsulate/decapsulate non-HIP MH data packets, whereasthe HIP MH uses its HIP SA and ESP to process itsdata. Figure 5 shows how the HIP SA is used based onthe traffic type, HIP or IP traffic. In addition, it illustrates an example flow diagram of MHP operations as aMHP receives a packet for and from a MH.

Muslam et al. EURASIP Journal on Wireless Communications and Networking (2017) 2017:71Page 5 of 12STARTRECEIVE I1 PACKETNOYESIS I1 PACKET DESTINEDTO HIP ENABLED MHFORWARD I1 PACKET TO HIP ENABLED MHSTORE BINDING INFORMATIONRECEIVE R1 PACKET IN RESPONSE TO I1PACKET FROM HIP ENABLED MHRESPOND TO I1 PACKET WITH R1 PACKETON BEHALF OF NON-HIP ENABLED MHFORWARD R1 PACKETRECEIVE I2 PACKETRECEIVE I2 PACKETSTORE BINDING INFORMATIONFORWARD I2 PACKET TO HIP ENABLED MHRESPOND TO I2 PACKET WITH R2 PACKETON BEHALF OF NON-HIP ENABLED MNRECEIVE I2 PACKET IN RESPONSE TO I2PACKET FROM HIP ENABLED MHTRANSLATE IP/HIP PACKETS TO AND FROMNON-HIP ENABLED MHFORWARD R2 PACKETENDFig. 4 HIP SA establishment detection for an HIP and a non-HIP MHWhen the MHP receives HIP packets destined for oneof its MHs, it checks first whether the packets are sentfor an HIP or non-HIP MH. When the MHP receivespackets from a non-HIP, the MHP determines firstwhether packets need HIP services or not. To achievethis, there are two solutions: (1) enable the networklayer of the MHP to pass the received packets to theHIP layer. The HIP identifies the IP flow to which thereceived packets belong and accordingly offer HIP services if needed; and (2) add a flag, for example, an HIPflag to the packets of a flow that requires HIP services.The MHP then offers the HIP services if the HIP flag isset to 1.The re-use of the established HIPSA allows the MH toavoid some delay and signals and thus enable the seamlessIP handover in a secure way. In addition, the proposedDMHP ensures another way to at least obtain some of thenecessary security information from the local server, whilethe full authentication is being performed at the originalservers as explained in the HIP RFCs. In this case, at theCONVERT HIP PACKETTO IP PACKETPROCESS/FORWARD IPPACKET TO NON-HIPENABLED MH ASNEEDEDserver, for example, as responder in a remote networklocation, the average of the end-to-end delay for the interdomain will be about 110 ms [16] that can lead to a longhandover delay.3.4 HandoverFigure 6 shows the handover procedure of a MH, whichis either HIP MH or non-HIP-enabled MH, between twowireless access networks belonging to the domain managed by the same GW. The MH is communicating withan HIP-enabled CH (not included in the figure) whichlies in a different domain.The MH may change its point of attachment (PoA)and attach to another mobile HIP proxy (proxy2) underthe same GW. During this attachment, the MH presentsits HIT and previous IP address to proxy2. Proxy2 thendetermines the previous proxy, proxy1, from the networkprefix of the MH’s previous IP and then acts as the HIPproxy and updates the binding record of the MH atSTARTSTARTRECEIVE HIP PACKETFROM MHRECEIVE IP PACKETFROM MHNOIS MH HIPENABLED?CONVERT IP PACKETTO HIP PACKETNOIS MH HIPENABLED?YESPROCESS/FORWARDHIP PACKET TO HIPENABLED MHPROCESS/FORWARDPACKET AS NEEDEDENDENDFig. 5 HIP SA for data processing, encapsulation, and decapsulationYES

Muslam et al. EURASIP Journal on Wireless Communications and Networking (2017) 2017:71GWPoA2PoA 1MHPage 6 of 12AR1/Proxy1AR2/Proxy2MH detachMH attachPresents: HIT(MH)Update pkt1Update recordHIT(MH): IP(Proxy2)Update pkt2RA ofsame IP prefixFig. 6 Packet flow after MH handover within the IPn domainproxy1. Communicating with proxy1 allows proxy2 tosecurely know the context of the established HIP SA.Note that in a secure private network, for non-HIPMH, HIP communications can be terminated at proxy1and then exchanged with a MH as IP communicationsvia proxy2. That is, proxy1 performs HIP proxy functions while proxy2 performs mobility support. The advantages of this approach are the following: (1) non-HIPMH can move to any mobility-enabled access router andstill preserve its active sessions with HIP CHs and (2) itallows load balancing, for example, if the proxy is heavilyloaded, it can assign some of the load to other HIPproxies. However, this approach can result in inefficientrouting if the distance between proxy1 and proxy2 islarge while the distance between the GW and proxy2 issmall. In the DMHP, all HIP communications are handled in the new proxy, proxy2. Furthermore, the DMHPcan ensure efficient routing and reduces vulnerabilitybetween the MH and the proxy.When the MH performs the handover from a networkthrough which the MH has established the activesession, proxy2 detects the attachment of the MH andsends an UPDATE packet (packet1) to proxy1. Whenproxy2 receives the reply UPDATE packet (packet2)from proxy1, it will send a RA to the MH. The RA willhave the same network prefix that the MH used toconfigure its IP address in the proxy1 subnet. The MH,therefore, retains the same IP address configuration sothat duplicate address detection (DAD) is not needed.This procedure significantly reduces handover latency,signaling overheads and packet loss.Figure 7 shows exchanged messages between entitiesin a wireless communications system as a non-HIPenabled MH performs a handover from one accessnetwork to another, through which the active session isestablished.When the MH returns to the proxy, through whichthe active session is established, the proxy checks itscache binding to identify the MH and where its activesessions are established. If the sessions were establishedvia the new proxy, the latter updates the record of theMH and starts serving it instead of forwarding toPoA 1MHAR1/Proxy1MH detachMH attachUpdate recordHIT (MH): IP(Proxy1)Presents: HIT(MH)Configure IP addrRA of same IP prefixFig. 7 Handover procedure of a MH using DMHPGWPoA2AR2/Proxy2

Muslam et al. EURASIP Journal on Wireless Communications and Networking (2017) 2017:71another proxy. It is important to note that the proxydoes not send any handover-related signaling, and thus,the location update delay is eliminated. Furthermore,there is no need to update the MH record at the RVSsince the MH is still reachable via the registered proxyat the RVSs. Unlike [8–10], the DMHP does not incuradditional handover delay due to verification and validation of handed over MHs. And also unlike [12], theDMHP does not incur additional handover delay due toconfiguration of new IP address in the same domain andthus DAD delay.So far, we have discussed the handover of a single MH.Suppose, however, that two or more MHs need to handover to the same new point of attachment, N-PoA. Anexample scenario is when a train carrying many passengers moves from one network to another. Therefore, iftwo or more mobile hosts have moved at the same timeto the N-PoA, how does the N-PoA handle these MHs?And in which order?The movement of many mobile hosts at the same timeto the same new point of attachment, N-PoA, is one thatcan affect the handover latency, packet loss, andhandover-related messages. Either the newly attachedMHs can detach from different PoAs (that is wheresome MHs are coming from different PoAs) or all MHsdetached from the same PoA. The former case is referred to as case 1 and the other as case 2. Such concurrent movement (handover) of MHs may result in longhandover latency and packet loss as well as more handover messages, however. In this paper, we discussvarious methods to ensure the efficient management ofmany MHs that move at the same time to the same newPoA, so that handover performance is maintained. Tothe best of our knowledge, none of the existing host mobility solutions have addressed the abovementionedissue.In Fig. 8, we show case 1 with two MHs, MH1 andMH2, coming from different points of attachment, PoA1and PoA2, and attaching to the same new point ofattachment, N-PoA.Furthermore, in Fig. 9, we show case 2 with threeMHs, MH1, MH2, and MH3, coming from the samePage 7 of 12N-PoAPoA 1AR1MH1, MH2, and MH3 attachFig. 9 Many MHs attach at the same time to the same new PoAusing DMHPpoints of attachment, PoA1, and attaching to the samenew point of attachment, N-PoA.In case 1, if many MHs coming from different PoAshave moved to the same N-PoA, the N-PoA must firstclassify the MHs into different groups based on their oldPoAs. The N-PoA sends only one update packet, whichwe called a group UPDATE packet and denoted byGUPDATE packet, for each group and not for each MH.An example that explains this scenario is shown inFig. 10. As depicted in the figure, the N-PoA has classified the MHs, the nine MHs, into three groups becausethe attached MHs are coming from three different PoAs,PoA1, PoA2, and PoA3. Let us name these groups asgroup1, group2, and group3. Group1 includes two MHs(MH1 and MH2), group2 includes three MHs (MH3,MH4, and MH5), and group3 includes four MHs (MH6,MH7, MH8, and MH9). It is important to note that thenumber of MHs will equal the number of groups ifeach MH is coming from a different PoA, which isthe worst case.In case 2, if at the same approximate time many MHshave moved (handover) to the same N-PoA, the N-PoAbuilds an aggregated mobility packet that we denoted byAgUPDATE pkt1 and then sends it to the old PoA fromwhich the MHs detached. The aggregated UPDATEpacket includes the identifiers for all MHs attached tothe N-PoA. Sending of only one packet (an aggregatedUPDATE packet) will reduce the signaling overhead andPoA1PoA2PoA3GUPDATEPkt1(MH1,MH2)PoA 1AR1MH1 attachN-PoAAR2MH2 attachMHs attach2 MHs from PoA13 MHs from PoA24 MHs from PoA3PoA 2AR3Fig. 8 Many MHs attach at the same time to the same N-PoA butcoming from different PoAs using H7,MH8,MH9)Fig. 10 Handover procedure of many MHs at the same time fromdifferent PoAs to the same new PoA using DMHP

Muslam et al. EURASIP Journal on Wireless Communications and Networking (2017) 2017:71Page 8 of 12Table 1 Simulation parameters under which MHP and DMHP are Speed1 m/sMobility modelRectangleRoute advertise interval 0.3 sNo. of POA2Packet flowBi-dir CBRNo. of MH1UDP packet transmit rate0.13 sAP power2.0 mWGrid size (m2)850 850Packet size256 BBeacon freq.0.1 s4 Simulation and results4.1 Simulation setupThe OMNeT v.4 [17], which is an open sourcenetwork simulator, is used to model the functionality ofDMHP.The simulation environment under which the authorsexamined the DMHP constitutes two IEEE 802.11bsubnetworks with MHPs co-located within the accessrouters. The two subnetworks partially overlap. A fixedHIP CH (i.e., hipsrv) is placed outside the access network of the MH and runs a UDP application to transmita data stream at 15 Kbps with a packet size of 256 bytesto the MH. It is important to note that these applicationsettings are chosen to represent configuration of thevoice IP application. Although TCP applications arepopular, we only check the performance of DMHP forUPD applications because these applications are delaysensitive. The simulation runs for 25,000 s while theMH speed is fixed at 1 m/s as it moves from subnet 1that is managed by MHP1 to subnet 2 that is managedby MHP2 and vice versa. The simulation parameters ofthis scenario are described in Table 1.This section presents and analyzes the handoverperformance results obtained from the MHP andDMHP. The handover delays, packet loss, and signalingoverheads are investigated. Also investigated are otherfactors that affect MH handover performance such asthe number of MHs simultaneously performing handover while communicating with different CHs. Inaddition, end-to-end delays before and after the MHhandover are investigated.Using the abovementioned simulation, the authorsexamined the model (DMHP). In addition, they recodedand analyzed a hundred handovers for the DMHP. Thefluctuation in the handover latency (HOL) of the DMHPand MHP over the first 23 handover (HO) instances isdepicted in Fig. 11.It is important to note that experiment of MHP isconducted in the hierarchical networks whereas experiment of DMHP is conducted in the flat networks. It isobserved that the DMHP exhibits varying handoverHandover Latency (s)location update latency as well as the packet loss. Thatis because only one update packet will be sent to updatelocations of many MHs instead of sending a separateupdate packet for each MH.Consider a movement of n MHs {MH0, MH1, , MHn-1}in case 1. After that, the N-PoA will send three UPDATEpackets, GUPDATE packets, instead of nine UPDATEpackets. One of the three UPDATE packets (that includethe identifiers of MH1 and M

to act as a mobility anchor, which collocates at the ac-cess router. Distributed mobility management is then supported by these mobility anchors. There is no longer need to rely on a separate centralized entity, as in [3], which is now removed. The elimination of a centralized anchor a