Towards Flat and Distributed MobilityManagement: a 3GPP Evolved Network DesignCarlos J. Bernardos , Juan Carlos Zúñiga†, Alex Reznik† Universidad Carlos III de MadridE-mail: [email protected]† InterDigitalE-mail: {JuanCarlos.Zuniga, Alex.Reznik}@InterDigital.comAbstract—The last few years have seen an exponential increase in mobile data use, coming primarily as a result of the“iPhone revolution”. Mobile operators are currently facing trafficdemands higher than what their networks can support, whichhas triggered the need of implementing offloading mechanismsat different levels of the architecture. One of the problems isthat existing mobility procedures are highly centralized, requiringall data traffic to traverse the mobile operator’s network core.This paper presents an evolved 3GPP architecture that supportsfull distributed mobility management, while allowing incrementaldeployment and co-existence with existing solutions.the paper is organized as follows: Section II briefly introducesthe background and motivation for this work. In Section III,we present and provide details of our designed architecture.Since there are other approaches that can be followed totackle the same problems, we analyze the most relevant onesin Section IV, comparing them with our proposed solution.Finally, Section V is devoted to concluding the paper andoutlining some future work.II. BACKGROUNDANDM OTIVATIONI. I NTRODUCTIONWe are witnessing an exponential increase in the use ofdata services by mobile subscribers. This is motivated bya variety of different reasons: 3G and WLAN accesses arewidely available (combined, coverage reaches almost 100% ofdense populated areas in developed countries) and affordableby users (most mobile handsets are 3G and WLAN capable,all laptops and netbooks are equipped with WLAN interfaces,3G USB modems are quite cheap and operators offer flat ratesto their customers). Additionally, the number and popularity ofsmart phone applications that make use of Internet connectivityis increasing every day.This huge amount of mobile data traffic seriously impactsthe dimensioning and planning of current mobile networks, asa) spectrum is limited and expensive, so available bandwidth inthe access cannot be easily increased; and b) deployed mobilenetworks are highly hierarchical and centralized, introducingserious scalability and reliability concerns. In order to tacklethe first issue by increasing system capacity of the wirelessaccess, operators are looking at deploying femto and picocells [1], as well as to selectively offload traffic from 3Gto WiFi [2]–[4]. Different approaches are currently beingdeveloped to address the second aspect, such as the Local IPAccess and Selected IP Traffic Offload (LIPA-SIPTO) withinthe 3GPP1 , and the Distributed Mobility Management (DMM)effort at the IETF2 .This paper focuses on the scalability and reliability problems caused by the use of current hierarchical and centralizedanchoring and mobility approaches, and proposes a 3GPPevolved architecture following a DMM approach. The rest of1 3rd2 TheGeneration Partnership Project: Engineering Task Force: mobile architectures such as WiMAX and theEvolved Packet System (EPS) are intended to be IP-based bothfor data and voice communications, triggering a real need tooptimize IP protocols for mobile networks.IP mobility management plays a key-role in providing thealways-on and ubiquitous service envisioned by future technologies. Unfortunately, IP mobility protocols standardized sofar have not met the deployment expectations, most of thembeing customized with proprietary solutions instead.The mobility management schemes standardized by IETFfor IPv6 networks are extensions or modifications of thewell known Mobile IPv6 protocol (MIPv6) [5], such asProxy Mobile IPv6 (PMIPv6) [6], Dual Stack Mobile IPv6(DSMIPv6) [7] and Hierarchical Mobile IPv6 (HMIPv6) [8].However, they come at the cost of handling operations at acentral point – the mobility anchor – and burdening it withdata forwarding and control mechanisms for a great amountof users. Table I shows, for the main mobility protocols andarchitectures, the equivalence between the principal mobilityroles and the logical entities playing them. The mobilityanchor is usually far away from the edge and deep into thecore network, and although HMIPv6 proposed to split themanagement hierarchically, this only shifts the problem closeto the edge without really addressing the flat IP architecturedemand.In order to address such issues, a new paradigm of solution,the so-called Distributed Mobility Management (DMM), iscurrently being analyzed by both academic and standardscommunities. DMM basically develops the concept of a flattersystem, in which the mobility anchors are placed closer to theuser, distributing the control and data infrastructures amongthe entities located at the edge of the access network.

Mobility anchorSignaling agentMIPHAFAProxy MIPLMAMAGGPRS & UMTSGGSNSGSNEPSPGWSGW/ePDG/eNBTable IE QUIVALENCE BETWEEN MAIN MOBILITY ROLES AND LOGICAL ENTITIES .Centralized mobility solutions, such as Mobile IPv6 or thedifferent macro-level mobility management solutions of 3GPP(for GPRS & UMTS and EPS), base their operation on theexistence of a central entity, e.g., Home Agent (HA), LocalMobility Anchor (LMA), Packet Data Gateway (PGW) orGateway GPRS Support Node (GGSN), which anchors theIP address used by the mobile node and that is in chargeof coordinating the mobility management (MM), sometimeshelped by a third entity like the Mobility Management Entity(MME) or the Home Subscriber Server (HSS). This centralanchor point is in charge of tracking the location of the mobileand redirecting traffic towards its current topological location.While this way of addressing mobility management has beenfully developed by the Mobile IP protocol family and itsmany extensions, it brings several limitations that have beenidentified [9]: Sub-optimal routing. Since the (home) address used by amobile node is anchored at the home link, traffic alwaystraverses the central anchor, which leads to paths that are,in general, longer than the direct one between the mobilenode and its communication peer. This is exacerbatedwith the current trend in which content providers pushtheir data to the edge of the network, closer to theusers. With centralized mobility management approaches,user traffic will always need to go first to the homenetwork and then to the actual content location, addingunnecessary delay and wasting operator’s resources. Scalability problems. Existing mobile networks have tobe dimensioned to support all the traffic traversing thecentral anchors. This poses several scalability and network design problems, as the central mobility anchorsneed to have enough processing and routing capabilitiesto be able to deal with all the users’ traffic simultaneously.Additionally, the entire operator’s network needs to bedimensioned to be able to cope with all the users’ traffic. Reliability. Centralized solutions share the problem ofbeing more prone to reliability problems, as the centralentity is a potential single point of failure. Signaling overhead. By allowing mobility management tobe dynamically enabled and disabled on a per applicationbasis, some signaling can be saved, as well as theassociated handover latency.III. 3GPP EVOLUTIONTOWARDS DISTRIBUTED MOBILITYMANAGEMENTThis section describes our proposed 3GPP architectureevolution supporting distributed mobility management, by firstintroducing the architecture, and then providing more detailsabout the designed solution.A. DMM-based architectureIn this section we present a DMM-based solution for thenetwork-based and client-based mobility architectures currently supported in the latest 3GPP specifications. For theformer, we consider GPRS Tunnelling Protocol (GTP) andProxy Mobile IPv6 (PMIPv6) solutions, while for the later weassume Dual Stack Mobile IPv6 (DSMIPv6). For simplification, we only focus on the non-roaming scenarios. Figure 1shows the interface diagram, highlighting in light blue thoseparts that are new compared with latest 3GPP specifications.The key novelty introduced by our proposal is the DistributedGateway (D-GW), which is a new logical network entitylocated at the edge of the network, and can be considered asthe result of splitting and distributing the PGW functionality,so that it sits closer to the users.The distributed gateway (D-GW) implements the functionality of the PGW, in addition to some additional operationsrequired for DMM operation. In terms of capacity, a distributed gateway is not expected to manage a large numberof subscribers, as multiple D-GWs should be deployed. Theactual number of distributed gateways (or the ratio number ofD-GWs / number of PGWs) is up to the mobile operator andthe specific scenario needs. We next describe the additionalfunctionalities that the distributed gateway implements.For the case of the network-based DMM variant (Figure 1(a)), the distributed gateway behaves as access routerand mobility signaling agent3 . This basically matches with theMobile Access Gateway (MAG) functionality, according to theProxy Mobile IPv6 specification [6], if the PMIPv6 networkbased DMM solution is used. This functionality is performedon a per User Equipment (UE) and per-IPv6 prefix granularity.This means that a single D-GW instance may behave as aMAG when handling traffic of a given UE’s IPv6 prefix, whileoperating differently when handling traffic of a different prefixthat might or not belong to the same UE. The MAG functionality terminates the S5* interface (which is basically a DMMenabled version of the S5 interface) with another distributedgateway implementing the LMA counterpart functionality. Ifthe GTP network-based variant solution is used, the D-GWalso behaves logically as a mobility signaling agent, but usingin this case GTP for both control and data planes.The distributed gateway also implements the functionalityof mobility anchor. This corresponds with the Local MobilityAnchor (LMA) functionality according to the Proxy MobileIPv6 specification, if the PMIPv6 network-based DMM solution is used. This is already a functionality of the packet datagateway, but the D-GW implements it differently, as it shouldbe performed also on a per-UE and per-IP prefix granularity.The LMA functionality terminates the S5* interface with another distributed gateway implementing the MAG counterpartfunctionality. If the GTP network-based variant solution isused, the D-GW also behaves logically as a mobility anchor,but using in this case GTP for both control and data planes.3 Table I shows the equivalence between mobility roles and logical entitiesof the principal mobility protocols and architectures

S10MMES1-MMELocal access toInternet and locallyavailable content,servers, etc.SGiS113GPPAccessD-GWS10SWxHSSS6a2SHUDWRU¶V ,3ServicesS11Local access toInternet and locallyavailable content,servers, x*D-GWPCRFSGiS6b*3GPP AAAServerS2c*GxbGx*S2cSGiS6b*S2cS2aSGiS6b*3GPP AAAServerLocal access toInternet and locallyavailable content,servers, etc.TrustedNon-3GPP on-3GPP IPAccessS6bS2bD-GWHPLMNNon-3GPPNetworksD-GWLocal access toInternet and locallyavailable content,servers, etc.Gx*Local access toInternet and locallyavailable content,servers, etc.TrustedNon-3GPP ocal access toInternet and locallyavailable content,servers, etc.S2bGxbS5*S5*S11SGiGxcGx*S5*2SHUDWRU¶V aS2c*(a) Network-based (GTP and PMIPv6 variants)Figure 1.UntrustedNon-3GPP IPAccessS2c(b) Client-based (DSMIPv6)Non-roaming DMM 3GPP evolved interface diagram.In case a client-based DMM solution is used (Figure 1(b)),the distributed gateway also implements the functionality ofDSMIPv6 Home Agent (HA), as described in [7], terminatingthe S2c* interface (which is a DMM-enabled version of theS2c interface).Since the distributed gateway directly interfaces with theuser equipment, D-GWs need to also implement the access androuting functionalities required to interact with the UE usingthe access technology in place (e.g., functions performed by aTrusted Non-3GPP Access). Note that for those Packet DataNetwork (PDN) connections that are decided to be handled viaa PGW on the Home Public Land Mobile Network (HPLMN),no specific D-GW functionality is used, so it is effectivelytransparent to the user equipment and the rest of the networkentities in the subsequent of procedures.Last, the D-GW replaces the evolved Packet Data Gateway(ePDG), assuming it performs the IPsec tunneling functionalitywith the User Equipment. For the case of the 3GPP access (EUTRAN), the distributed gateway acts as a transparent relaybetween the evolved Node B (eNB) and the Serving Gateway(SGW) for traffic not handled in a DMM way. Similarly, forTrusted and Untrusted Non-3GPP IP accesses, the distributedgateway is transparent for those communications that are notto be managed with distributed anchoring.Since the functionality of the distributed gateway is similarto the one of the packet data gateway, this should allowfor re-use of most of the software stack implementation ofthe PGW, helping minimizing the total additional deploymentcost. Additionally, the D-GW logical entity may be deployedas a standalone function or can be collocated with other3GPP entities, like for example the Home eNB (HeNB), LocalGateway (L-GW) or SGW.The user equipment also plays an important role in a DMMbased solution. It should implement additional intelligence inregards IP address management and source address selection,as compared with an existing 3GPP Release 10/11 capabledevice. This intelligence imposes additional requirements onthe connection manager. We list next some of them: The UE should keep track internally of the IPv6 prefix(es), APN tuple assigned on each D-GW it attachesto, for the case of the network-based (GTP/PMIPv6)solution. For the case of the client-based (DSMIPv6)solution, it also needs to keep track of the IPv6 addressof each D-GW anchoring a prefix used by the userequipment. The UE should perform intelligent source IPv6 addressselection, so new applications are presented with prefixeslocally anchored at the current D-GW. This allows forprefixes anchored at D-GWs visited in the past to stopbeing used. This is a complex problem, as there may beother aspects that need to be considered, in addition to thefact of preferring anchoring from the currently attachedD-GW. For instance, operator’s preferences on usinga particular distributed gateway for some destinationsdue to congestion, better routing costs, etc. Therefore,a mechanism to enable taking into account preferencesfrom the network should be enabled. This could bebased on enhancing the Access Network Discovery andSelection Function (ANDSF) framework, and/or mechanisms similar to the RFC 4191 [10], RFC 3484 [11] andRFC 5220 [12]. The user equipment may want to have the control onwhich traffic is managed in a distributed way by thenetwork and which traffic is anchored at the home corenetwork (anchor selection process). Specific access pointnames (APNs) can be defined to indicate which type ofanchoring behavior is selected by the UE. The UE should initiate the packet data network disconnection procedure for those PDN connections that areassociated with prefixes that the UE is no longer using,so the network releases the associated resources and – forthe case of the network-based solution – stops performingthe signaling procedures required to keep those prefixesreachable at the current location of the user equipment.

(a) Network-based (GTP and PMIPv6 variants)Figure 2.(b) Client-based (DSMIPv6)DMM-Based Mobile Network System Design: solution overview.B. Solution operationThis section provides an overview of the operation of thesolution, for both network and client-based mobility management approaches (see Figure 2).D-GWs are distributed at the edge of the network. For 3GPPand Trusted Non-3GPP IP accesses, these D-GWs are placedclose to the UE, at the access network level (i.e., close to theSGW or even to the Home evolved Node B/Local Gateway for3GPP access, and close to the Access Points for WiFi TrustedNon-3GPP IP access). For Untrusted Non-3GPP IP access, theD-GW is located at the edge of the HPLMN of the operator,instead of the ePDG, which is the operator-managed entityclosest to the user equipment.The distributed gateway behaves almost as a packet datagateway from the viewpoint of the user equipment and therest of the network, with some DMM modifications. The distributed gateway may provide Internet access (local breakout àla SIPTO) and connectivity to local resources (LIPA scenario).Each D-GW has a pool of IPv6 prefixes anchored at the D-GW(i.e., IP routing delivers packets addressed to those prefixes tothe D-GW) available for delegation to UE.When a user equipment initially attaches to the network, theAPN requested by the UE (or the default one, if none provided)is checked together with its profile at the home subscriberserver. Assuming a single packet data network connection, ifit is decided to be handled locally, then the following stepsdescribed on subsequent subsections apply. Otherwise, alreadyspecified 3GPP procedures would be followed, being the DGW transparent (i.e., a mere relay in most of the procedures).We now use a simple example to explain how the solution works, using the scenario shown in Figure 2 (bothnetwork and client-based cases are included). Every time aPDN connection is requested by a UE, it is handled by thedistributed gateway, which assigns an IPv6 prefix from its poolto the user equipment. This prefix is conveyed to the UE soit can auto-configure an IPv6 address. We assume statelessauto-configuration (i.e., the distributed gateway sends RouterAdvertisements carrying the assigned prefix), but other optionsare possible (e.g., use of DHCPv6). The D-GW updates onthe HSS (via the MME for 3GPP access and the AAA Serverfor non-3GPP access) the IPv6 prefix assigned to the userequipment, including the D-GW Identifier (and IPv6 address ifthe D-GW Identifier is not enough to derive the address). TheUE can then start sending and receiving IPv6 packets, whichare routed via the distributed gateway, without traversing theMobile Core Network (MCN) (for the case of Untrusted Non3GPP access, packets need to traverse the HPLMN, but notthe MCN). If we take UE1 in Figure 2, it is attached to DGW1 and configures PrefA:x::UE1/64 address out of theprefix PrefA:x::/64 assigned by D-GW1.For the sake of brevity in the explanation of the handoverscenario, we first focus on the network-based solution (Figure 2(a)). If the user equipment moves and attaches to anotheraccess network, there are two different kind of proceduresthat take place. First, the packet data network connectionsthat the UE has established needs to be maintained (i.e.,address preservation). This requires, for each of the PDNconnections of the user equipment, that the distributed gatewayanchoring the IP address used by the UE plays the roleof packet data gateway (i.e., mobility anchor) for that PDNconnection, meaning that the distributed gateway performs thelocal mobility anchor functions for that UE and that PDNconnection. The serving distributed gateway (i.e., the D-GWthe UE is currently attached to) has to play the role of signalingagent (e.g., MAG) for each of the UE’s packet data networkconnections that are anchored at other distributed gateways.The serving D-GW obtains the required information aboutthe on-going PDN connections of the UE, the IPv6 prefixesused and the D-GWs anchoring them, by interacting withthe HSS/AAA. Second, the user equipment requests a newpacket data network connection (or several) to the servingdistributed gateway. This provides the user equipment withan IPv6 address anchored at the serving D-GW, which can beused by the UE to enjoy optimal routing while making the

Figure 3.DMM network based (PMIPv6 variant) example use of the operator’s network resources.Referring to the scenario illustrated in Figure 2(a), we showin Figure 3 an example Message Sequence Chart (MSC) of theDMM network-based (PMIPv6 variant) solution. UE2 initiallyattaches to D-GW2, where it establishes a PDN connectionand configures PrefB:y::UE2/64 as IP address (anchoredat D-GW2). Using this locally anchored IPv6 address, UE2can directly communicate (i.e., no tunneling, no sub-optimalpath) with any Correspondent Node (CN) of the Internet,such as CN1. Later on, UE2 moves and attaches to DGW3. The original PDN connection is handed over, by DGW3 playing the role of MAG and D-GW2 playing therole of LMA, establishing a PMIPv6 tunnel (in case of theGTP variant, a GTP tunnel would be setup instead) betweenthem to forward traffic addressed to PrefB:y::UE2 to thecurrent location of UE2. This allows UE2 to keep usingPrefB:y::UE2 and therefore to seamlessly maintain anyrunning services/applications/connections using that address(e.g., the communication with CN1). Besides, UE2 establishesa new packet data network connection at D-GW3, configuringa new IPv6 address (PrefC:z::UE2/64), anchored at DGW3, that can be used by UE2 for new connections (forexample with CN2, avoiding any tunneling and sub-optimalrouting). Note that Proxy Mobile IPv6 signaling is shown inFigure 3, and that GTP signaling would be used in case theGTP variant was deployed.Note that for the case of client-based mobility (Figure 2(b)),the basics of the solution are very similar. A user equipmentrequesting a PDN connection configures an IPv6 out of aprefix assigned by the distributed gateway. As before, if theUE moves and attaches to another access network, the UErequests a new packet data network connection (or several)to the D-GW the UE is currently attached to. For each ofthe PDN connections that the user equipment had previouslyestablished and needs to be maintained, the D-GW anchoringthe IP address used by the UE plays the role of PGW (i.e.,HA), meaning that the distributed gateway performs the homeagent functions for that UE and that PDN connection. The userequipment has to signal to each of the anchoring D-GWs itscurrent location and establish an IPv6-in-IPv6 tunnel, so datapackets can be redirected to the UE. In order to do that, theuser equipment uses the address obtained from the currentlyattached D-GW (i.e., serving D-GW) as care-of address, andsends a Binding Update message per Home Address (i.e., eachof the addresses assigned by the previously visited servingdistributed gateways, which now play the role of anchoringD-GWs). Note that this is only done for those addresses thatare still being used by the UE.It is important to highlight the role of the user equipment.Most of the advantages brought by a DMM approach areenabled by UE smart IP address management. This basicallymeans that the IP address selection mechanisms used by theUE should be enhanced to allow the UE to always preferan IPv6 address anchored at the distributed gateway the UEis currently attached to. In this way, new communicationsmake use of the locally anchored IPv6 addresses, whileold communications are seamlessly maintained by ensuringIPv6 address continuity. It is also important that as soon as

communications using old IPv6 addresses finish, the UE isaware and signals to the network that reachability for thoseaddresses is no longer required, so no further signaling isgenerated and used tunnels are removed. This UE enhancedintelligence to manage IPv6 addresses can be implemented aspart of the connection manager, and should also support theuse of policies from the network.IV. C OMPARISONWITH OTHER APPROACHESIn this section, we overview other existing approaches thattry to address the challenges caused by the increase of themobile data traffic demand from users and the convergenceand integration of different types of networks (i.e., differentaccess technologies, enterprise and home networks, etc.), butrestricting the scope to solutions that are designed for the3GPP architecture. Although there are several mechanismsthat follow a DMM approach [13]–[16], to the best of authorsknowledge, none of them goes into all the details of how toimplement them in existing 3GPP architectures.If we first look at the ongoing efforts inside the 3GPPitself, there are two main solutions that try to alleviate theload of the mobile network core: Selected IP Traffic Offload(SIPTO) and Local IP Access (LIPA) [17]. SIPTO enablesan operator to offload certain types of traffic at a networknode close to the UE’s point of attachment to the accessnetwork, by selecting a set of GWs (SGW and PGW) thatis geographically/topologically close to the UE’s point ofattachment. LIPA, on the other hand, enables an IP capable UEconnected via a Home eNB (HeNB) to access other IP capableentities in the same residential/enterprise IP network withoutthe user plane traversing the mobile operator’s network core.In order to achieve this, a Local GW (L-GW) collocated withthe HeNB is used. LIPA is established by the UE requestinga new PDN connection to an access point name for whichLIPA is permitted, and the network selecting the Local GWassociated with the HeNB and enabling a direct user planepath between the Local GW and the HeNB.Both SIPTO and LIPA have a very limited mobility support,specially in 3GPP specifications up to Rel-10. In Rel-11, thereis currently a work item on LIPA Mobility and SIPTO atthe Local Network (LIMONET) [18] that is studying how toprovide SIPTO and LIPA mechanisms with some additional,but still limited, mobility support. Without going into muchdetails, LIPA mobility support is limited to handovers betweenHeNBs that are managed by the same L-GW (i.e., mobilitywithin the local domain), while seamless SIPTO mobility isstill limited to the case where the SGW/PGW is at or aboveRadio Access Network (RAN) level. Seamless mobility at thelocal network is still not considered in SIPTO. Therefore,although SIPTO and LIPA allow offloading traffic from thenetwork core similarly to the DMM approaches, even withLIMONET they just provide localized mobility support, requiring packet data network connections to be deactivated andre-activated when the UE is not moving locally.On the research side, there are also some proposals toextend current 3GPP mechanisms towards a flatter networkarchitecture, like [19] and [20], but they do only consider3GPP accesses (E-UTRAN), not addressing the distributionof anchors in non-3GPP accesses.V. C ONCLUSIONSANDF UTURE W ORKIn this paper we have presented an evolution of current3GPP architecture towards a flat and fully distributed mobilitynetwork design. This architecture allows pushing the dataanchors towards the edge, alleviating hence the overloadednetwork core infrastructures of mobile operators.The proposed solution follows the distributed mobility management paradigm, which has been so far mainly discussed atthe IETF, but takes into consideration the 3GPP architecturespecifics. A new logical entity, called distributed gateway, islocated close to the users, anchoring the data communicationsand supporting mobility when they move to a different DGW. Both network-based (GTP and PMIPv6) and client-based(DSMIPv6) procedures are provided. Last but not least, thesolution can be deployed incrementally, as both DMM andnon-DMM operation modes are supported, and the D-GW canalso be co-located with existing 3GPP network nodes.Future work includes the definition of the mechanismsrequired on the UE to fully benefit from this DMM approach,conducting an analytic and experimental evaluation of thesolution, and considering different network deployments, usertraffic patterns and user mobility models.R EFERENCES[1] V. Chandrasekhar, J. Andrews, and A. Gatherer, “Femtocell networks:a survey,” Communications Magazine, IEEE, vol. 46, no. 9, pp. 59–67,2008.[2] A. de la Oliva, C. Bernardos, M. Calderon, T. Melia, and J. Zuniga,“IP flow mobility: smart traffic offload for future wireless networks,”Communications Magazine, IEEE, vol. 49, no. 10, pp. 124–132, 2011.[3] K. Lee, I. Rhee, J. Lee, S. Chong, and Y. Yi, “Mobile data offloading:how much can WiFi deliver?” in Proceedings of the 6th InternationalCOnference, ser. Co-NEXT ’10. New York, NY, USA: ACM, 2010,pp. 26:1–26:12.[4] T. Melia, C. Bernardos, A. de la Oliva, F. Giust, and M. Calderon,“IP Flow Mobility in PMIPv6 Based Networks: Solution Design andExperimental Evaluation,” Wireless Personal Communications, vol. 61,pp. 603–627, 2011.[5] C. Perkins, D. Johnson, and J. Arkko, “Mobility Support in IPv6,” RFC6275 (Proposed Standard), Internet Engineering Task Force, Jul. 2011.[6] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil,“Proxy Mobile IPv6,” RFC 5213 (Proposed Standard), Internet Engineering Task Force, Aug. 2008.[7] H. Soliman, “Mobile IPv6 Support for Dual Stack Hosts and Routers,”RFC 5555 (Proposed Standard), Internet Engineering Task Force, Jun.2009.[8] H. Soliman, C. Castelluccia, K. ElMalki, and L. Bellier, “HierarchicalMobile IPv6 (HMIPv6) Mobility Management,” RFC 5380 (ProposedStandard), Internet Engineering Task Force, Oct. 2008.[9] H. Chan, “Problem statement for distributed and dynamic mobilitymanagement,” Internet-Draft (work in progress), Mar. 2011.[10] R. Draves and D. Thaler, “Default Router Preferences and More-SpecificRoutes,” RFC 4191 (Proposed Standard), Internet Engineering TaskForce, Nov. 2005.[11] R. Draves, “Default Address Selection for Internet Protocol version6 (IPv6),” RFC 3484 (Proposed Standard), Internet Engineering TaskForce, Feb. 2003.[12] A. Matsumoto, T. Fujisaki, R. Hiromi, and K. Kanayama, “ProblemStatement for Default Address Selection in Multi-Prefix Environments:Operational Issues of RFC 3484 Default Rules,” RFC 5220 (Informational), Internet Engineerin

EQUIVALENCE BETWEEN MAIN MOBILITY ROLES AND LOGICAL ENTITIES. Centralized mobility solutions, such as Mobile IPv6 or the different macro-level mobility management solutions of 3GPP (for GPRS & UMTS and EPS), base their operation on the existence of a central entity, e.g., Home Agent (HA), Local