Keywords

1 Introduction

Internet services and models have been going through a paradigm shift, product of three main factors: (i) widespread wireless technologies; (ii) increasing variety of user-friendly and multimedia-enabled terminals; (iii) availability of open-source tools for content generation. Together, these three factors are changing the way that Internet services are delivered and consumed as the end-user has a particular role in controlling content as well as connectivity, based upon cooperation. Specifically focusing upon Internet access, Internet connectivity models that rely upon cooperation (User-centric Networking, UCNs) [12, 41] are already being commercially adopted in some networks (e.g., FON, OpenSpark), from a nomadic perspective only. Nomadism can be seen as a property of global mobility management, property which relates to permanence of a subscribed environment, i.e., the possibility for an end-user to access his/her set(s) of subscribed services anytime, anywhere. In addition to nomadism, global mobility management also incorporates session continuity. Session continuity requires functionality capable of transparently and seamlessly diverting active sessions to whichever access location and whichever terminal (and interface) the end-user activates at an instant in time. In other words, while an end-user is on the move, the active sessions (independently of the type of application in use) are kept running without noticeable interruptions. Both support for session continuity as well as for nomadism should be contemplated in future Internet architectures and are also essential from a user-provided model perspective. The reason is that being user-centric and based on wireless technologies, these models rely on end-user mobility patterns to self-organize.

Future Internet models have to integrate properties that allow nomadic end-user experience for any application across multi-access or single-access networks, assuming that one or more operators are involved. Session continuity must also be considered in the new models, given that micro-providers (e.g. a user or a community of users) are also moving nodes. Depending upon micro-operator mobility patterns, it is likely that end-users receiving shared connectivity may experience disruptive connectivity breaks, which can be avoided if adequate session continuity support is provided.

Currently, the most popular solutions for global mobility management have in common a model where a centralized and static mobility anchor point is in charge of keeping some form of association between previous and current identities for a mobile node that roams across different networks. In UCN, these models should rely on a distributed architecture which raises the need to develop efficient anchor selection mechanisms based on reputation models, as well as models providing incentives to be a mobility anchor point. Moreover, time availability of mobility anchor points may be short in the presence of mobile connectivity access points. This poses an extra stress on seamless mobility mechanisms, which may need to perform handovers more often. Nevertheless, the impact on seamless mobility depends considerable on mobility patterns of mobile users (e.g. mobile users may follow the same movement of their current mobility anchor.

Moreover, in UCNs, strangers are expected to interact passively or actively for the sake of robust data transmission, several wireless access points and additional user equipment is controlled by the end-user, in addition to the regular model of control by operators. From a mobility management perspective, this implies that Mobility Anchor Points (MAPs) will often be physically located in Customer Premises (CP).

The term MAP used in the following description refers to a functional entity that takes care of all of the processes required to sustain movement of nodes that cross different networks, with reliability. For instance, in Mobile IP (MIP) [33] the MAP is the entity known as Home Agent (HA). In the Session Initiation Protocol (SIP) [34], it corresponds to the SIP server and proxy entities.

As several of these devices are controlled and/or owned by the end-user, the availability of MAPs cannot be easily controlled from a centralized perspective, as these elements they may disappear and appear in a dynamic and self-organizing way, thus disrupting the operation of mobility management solutions available in the network. Hence, for the case of UCN, the Internet end-user is also a network stakeholder. Assuming, for instance, that a MAP resides on an end-user device or in any element of the CP, then the period of time a mobility anchor point is available may vary frequently. This poses extra stress on seamless and centralized mobility mechanisms, which have to manage handovers more often.

The paper is provided in the context of this debate, giving insight to two new directions which are being addressed in the context of future Internet architectures, namely, distributed mobility management solutions, the impact and differences towards centralized solutions; mobility estimation as a handover optimization add-on to mobility management solutions.

This paper is organized as follows. Section 2 goes over related work, while Sect. 3 covers notions and current distributed mobility management (DMM) solutions. Section 4 explains the relevancy of DMM in the context of UCNs, covering also the main directions that are being developed. Then, Sect. 5 goes over mobility estimation, providing operational examples on how estimation can assist mobility management, in improving handover performance. The paper concludes with Sect. 6 where some guidelines concerning future research are also provided.

2 Related Work

Attempting to understand potential mobility patterns related to spontaneous environments, a study on an urban landscape based on the Google Wi-Fi mesh network [1] provides a good basis for the analysis of wireless usage. In particular, the authors show that such usage is split into three classes mostly based on user devices, namely, traditional mobile computers (notebooks), APs, and smartphones. The authors also show that urban mobility patterns exhibit the property of geographic locality. Specifically regarding accounting of mobile users in wireless environments a solution considers the application of agents that track node mobility, the Mobile Agent (MA) middleware. Such solution is based on having agents sent on demand to administer nodes. The central block works on the control plane only, in contrast to centralized mobility management solutions of today. A few proposals [2, 3] consider the application of overlays to deal with mobility from a global perspective. This gives the means to consider mobility management from a distributed perspective, where the mobility anchor point may be placed within the user premises. However, these solutions do not consider de-centralization or decoupling of mobility functionality.

A proposal for spontaneous environment mobility architecture based on the definition of more adequate addressing schemes and hence of more adequate routing [35] combines the notions of geographical routing based on ballistic trajectories with a location service based on Distributed Hash Tables (DHT) to achieve seamless mobility management in a k-neighborhood. Mobility management is based on the definition of an identifier that identifies the node on its constructed pseudo-geographical space and which associates the node with a k-neighborhood thus providing an identifier to its mesh area.

In what concerns optimizing the user roaming experience, roaming has been up until recently considered an integrated part (commodity) of a communication service provided to the user. In other words, mobility management in the form of roaming was not, up until recently, considered to be a service per se. This was mostly due to the fact that roaming was an integrated part of a subscribed plan in mobile networks. With the rise of wireless technologies and in particular of user-centric wireless architectures, roaming becomes a value-add service which is worth to be analyzed and optimized. Related work has analyzed a few aspects related to the optimization of such experience. From a user-centricity perspective, where user expectations drive the network selection Sofia et al. [5] propose an utility function (Satisfaction Degree Function) which based on specific criteria (user expectations) assist in dynamically switching between available networks. The exploitation of satisfaction degrees and algorithms from a user expectation (QoE) perspective has been pursued [21, 32] with the common goal of attempting to optimize the network selection, from a user-centric perspective.

New Internet paradigms and the need for scalability have been driving mobility management proposals which include the potential need to analyze mobility functional blocks and a potential better positioning from a networking perspective. Specifically considering mobility management in packet-based environments, Sofia et al. [40] analyze the possibility to separate control and data functionality in a way to provide a more flexible mobility management framework and to assist in developing non-centralized (e.g. distributed or hierarchical) mobility architectures. Following this work, Nascimento et al. validate, via simulations, a potential instantiation of such model [31], showing improvements in terms of node reachability time, and end-to-end delay.

Having in mind the recent trend of flatter mobile network architectures, Seite [36] addressed the concept of “flattening” by confining mobility support in the access network e.g. only confining it to access routers through a specific implementation of the application of Proxy Mobile IP. Following the same line of though, i.e. IP mobility management in flatter mobile networks, Liu et al. [26] debate on the idea of IP mobility management in such flatter environments.

Mobility estimation as a way to improve mobility management has been considered in the context of cellular works, context in which there are several studies dedicated to movement prediction. Several techniques have been considered, for instance, prediction based on Signal-to-Noise (SNR) ratio levels [9, 38]. Improvements have been considered, e.g. by adding a probabilistic selection based on user location (GPS). Such related work fell short in terms of adequately estimating movement, partially as it there was not a solid understanding on users’ roaming behavior. In the most recent years, the availability of large-scale data sets, such as mobile-phone records and global-positioning-system (GPS) data, has offered researchers from various disciplines access to detailed patterns of human roaming behavior, greatly enhancing our understanding of human mobility. Even though this is a recent effort, we highlight that attempting to capture social movement behavior is an old field of work. One of the first works in this field relates to human mobility modeling concerning diffusion (epidemics), and was based on the diffusion analysis of over one million dollar bills [4], attempt which lead the authors to derive universal properties concerning human mobility, which gave rise to one of the most popular diffusion theories.

US2013040644 [25] provides a method for movement prediction, considering one device and its neighborhood, in regards to different cells, by predicting population movement in each cell. While their solution is based on traffic volume assessment and on a collective behavior (of the mass of nodes roaming between cells), our proposed solution is based on passive collecting of available network information (without recurring to any traffic volume assessment) and a priority is provided based on specific user parameters (that are provided by the user, passively, or actively, e.g. preference of a network). EP1903828 [11] explores a technique for preferred network selection based on the notion of roaming units. Their solution relies on feedback provided in the form of call admission control of requests concerning roaming requests (e.g. rejected requests) to assist in influencing home and roaming network selection. While our solution provides a unique way to rank preferred network selection in a completely passive way and based on information that visited networks today already send around to nodes involved in visits. WO2012080305 [27] describes a method for controlling connections between multiple user devices and a network entity via a communication network, where in this part a controlling entity gets information from a social system to retrieve data from users, in order to police the network.

Our work shares with the related literature the concept that decoupling of mobility functionality may assist in better understanding how and where to manage mobility. As described, most of today’s attempts of flattening mobility management are being applied in the evolved packet core being the sole reason the urgent need to simplify mobility management. Albeit such urge is not as significant in today’s wireless networks we believe that there are two aspects that are relevant to undertake: i) understanding on how distributed mobility management functionality can be optimized across the different network regions and what is more beneficial concerning all of the stakeholders involved; ii) applying mobility estimation as a way to assist mobility management in making handover decisions.

3 Distributed Mobility Management

Mobility management embodies different perspectives depending on the object that it refers to. Personal mobility refers to the ability of a user to reach any of its services based on a personal identifier. This identifier allows the network to bind the user to one (or several) reachability profiles, anywhere, anytime. Device or Terminal mobility relates with the capability of a device in motion to access the user services independently of the location. Terminal mobility ensures that packets continue to be delivered to a terminal as it moves through the network and its point of attachment to the network changes. In Service mobility the same service (look and feel) is provided independently of access type and of the terminal in use.

Central to the topic of mobility are two additional definitions, namely, nomadism [13] (or nomadicity) and session continuity. Nomadism relates to the ability of a subscriber to obtain the same set of services independently of the location or device used. Nomadism implies physical reconnection (performed either manually or automatically), while session continuity refers to the property of keeping connectivity while on the move.

3.1 Nomadism/Nomadicity

Within the global concept of mobility, nomadism relates to usage models where session continuity is not required, e.g., the use of a Virtual Private Network (VPN) service across different networks. When the user moves between networks covered by the same VPN, session continuity is not a requirement of this service. Behind the nomadic notion is usually the underlying assumption that the user will be able to recover its service(s) profile(s) independently of location and device. This is in fact the model for the current 3GPP roaming service, which allows a user subscribed to a specific service from a specific operator, to obtain that same service (look and feel) by means of another access operator. Therefore, the nomadic perspective relies on a policy-based architecture. MIPv6 is therefore key to achieve nomadicity, given that it allows any IP host to be reachable independently of its access location. In this case, a subscriber (and not a device) is assigned to a personal identifier, which would be the key to access the subscriber’s profile(s). Whenever the subscriber moves to a new location, a re-connection is triggered and the subscribed set of services can be accessed independently of the access media. However, additionally to the global addressing requirement of nomadism, there is the need to rely on a global Authentication, Authorization, and Accounting (AAA) architecture, capable of providing the service profiles with the lesser disruption.

3.2 Session Continuity

Session continuity is provided both in the form of (automatic) IP continuity and of session continuity. In other words, session continuity is kept despite the change of access point, or UE. While this characteristic is crucial within the mobile environment, such is not necessarily the case within fixed network environments, given that in the majority of cases, service continuity for fixed environments implies physical re-connection. However, there are cases where session continuity may be required, e.g., between the fixed and the wireless networks. For instance, if a device holds more than one network interface service continuity should be possible. A specific example for this scenario is a user located in its office, and using its smartphone via fixed access. It then travels home on a train. While in the train, he might wish to keep his previous service session. These are issues currently being discussed in IEEE 802.21 [18], which explores the creation of Media Independent Handovers. Within the context of IEEE 802.21, session continuity covers adaptation to new link both on L2 and L3 (address adaptation), as well as session continuity at the application layer. 802.21 does not provide a standard in terms of which mobility stack (MIPv4 or MIPv6) to use, even though the discussion is currently following the direction of MIPv6.

From the 3GPP IMS perspective, currently SIP provides some session mobility management to (multimedia) services, when coupled with MIPv6. In this case the SIP server is used as a HA, and handover notification messages are traded via regular SIP messages to the HA (register) and to the CN (re-invite). The problem with the SIP approach is latency (it inherits all the delays of the transport and of the application layers). This aspect is not however crucial to the fixed network mobility, given that the underlying technology always requires the user to physically reconnect.

3.3 Mobility Management Roles and Functional Blocks

In terms of mobility management, one can isolate today three main roles: the Mobile node (MN), which usually is incorporated in portable device with limited energy capacity and also normally limited to short-range wireless or some form of cellular technology (e.g. LTE) through which the end-user connects to the Internet. Today, these devices also hold significant storage support (e.g. a tablet).

The MN is the element for which the mobility management service is offered. It has an identification (usually an IP address, or a username), that is associated to the IP address of the device’s interface currently connected. Moreover, this role exists both on the control plane and data plane of current mobility management solutions.

The MAP is a role which refers to control functionality that may reside in the network (e.g. router or access element) or in a server. This role has as usual main functions: to be capable of providing the up to date location of MNs; to perform the translation between old and up to date identifiers, and to dictate the rules that may influence the forwarding packets to the real destination of a MN active communication.

The third role is the Corresponding Node (CN). The term CN is here applied with a broader meaning than the one of MIP and in fact being applicable to any existing centralized mobility management solution as of today, being an “active partner” to the MN and therefore requiring mobility management support. Relevant to the definition of mobility management is understanding the “proximity” (physical or based on a community perspective) of the CN to the MN and vice-verse.

In what concerns mobility management functionality, based on a thorough analysis of existing solutions which we summarize in Fig. 1, we consider ten possible functional blocks [30]:

  • Device Identification: corresponds to the network identification for the MN. Usually the main mechanism for a location management is the association between the device’s known-address and the device’s real-address. In MIP, known-address and real-address are IP addresses; in SIP, the known-address is a URI, and the real-address is a IP address. In MIP the Identification control is the Home Agent/Mobility Anchor Point/Correspondent Node cache binding. In SIP it is the user database used by the Proxy server.

  • Identification database control: corresponds to the mechanism that is applied to control the database identification. This is normally a block relevant from an access perspective, and which today follows a centralized approach.

  • Mobility anchor point location: corresponds to the mechanism applied to support all the processes that assist in identifying the MN at any instant in time, as well as processes that support communication to and from the MN.

  • Binding registration: it is the signaling related to the first time a device registers to the mobility system. It creates a record in the Identification control binding cache, associating the known-address to the real-address. In MIP it is the first Binding Update message sent to a HA/MAP/CN. In SIP it is the REGISTER message sent to the Registrar server.

  • Binding update: it is the signaling to update a record in the Identification control. Binding update are used when the real-address of a device changes, or periodically to maintain the register in the Identification control. In MIP, it is the Binding Update sent from the MN to the HA/MAP/CN.

  • Routing or forwarding: it is the process of intercepting the packets destined to the known-address, encapsulating them with the real-address, and forwarding them. In MIP this is performed by the HA/MAP, in SIP this process is performed by an element named RTP translator (when it is used).

  • Handover negotiation: the process taken when the device has its real-address changed. It involves negotiation and signaling. The main objective is to guarantee that the user will keep active all its sessions during the handover process. In MIP, the handover negotiation may be anticipated with the Fast Handover extension, and the SIP does not implement any anticipation, performing a re-negotiation after the connection between the peers is lost.

  • Resource management: the resource management is a necessary procedure for the mobility management to guarantee the quality of the connection when the MN changes its point of attachment to the network. However, it is not provided by most of the mobility management approaches. The 802.21 MIH standard is focused on the handover process based on a resource management aware negotiation for vertical handovers.

  • Mobility estimation: it is the procedure of changing the MN point of attachment to the network before its current connection breaks. The extension Fast Handovers for MIP, and the 802.21 MIH provide this functionality.

  • Security: it refers to every security mechanism to assure the integrity of the elements and signaling of the mobility management system.

Fig. 1
figure 1

Mobility management functional blocks, characterization across different existing solutions

Full size image

Out of the analysis provided it is clear that today’s mobility management solutions lack a few aspects in particular in the face of dynamic environments such as UCN, being the major gaps concerned with resource management as well as security aspects. Both aspects are crucial in wireless networks, and in particular in networking architectures where there is a highly variable roaming behavior. Database control is normally centralized, an aspect which may not be compatible with the notion of communities that UCN scenarios are based upon. Routing and forwarding is also based on mechanisms (e.g. proxy mechanisms) which may not be completely compatible with the fact that users in our scenarios are expected to roam frequently. This is an aspect that can be improved by integrating mobility estimation mechanisms as explained in Sect. 5.

4 Distributed Mobility Management in the Context of UCNs

4.1 UCN Mobility Management Characterization

Mobility management aspects in UCN contemplate an end-to-end Internet perspective, emphasizing the nature of spontaneous wireless environments on the fringes of the Internet, the last hop towards the end-user. This implies that when considering movement of people and of devices, one must take into consideration aspects that relate to spontaneous wireless environments.

UCNs are based on the notion of users carrying (or owning) low-cost and limited capacity portable devices which are cooperative in nature and which extend the network in a user-centric way, not necessarily implying the support for networking services such as multihop routing. For instance, in UCNs transmission may simply be relayed based on simple mechanisms already existing in end-user devices. These emerging architectures therefore represent networks where the nodes that integrate the network are in fact end-user devices which may have additional storage capability and which may or may not sustain networking services. Such nodes, being carried by end-users exhibit a highly dynamic behavior. Nodes move frequently following social patterns and based on their carriers interests; inter-contact exchange is the basis for the definition of connectivity models as well as data transmission. The network is also expected to frequently change (and even to experience frequent partitions) due to the fact that such nodes, being portable, are limited in terms of energy resources. From a mobility perspective UCNs therefore exhibit a highly dynamic behavior where the selection of the “best” mobility anchor points requires the pursuit of two main aspects: adequate selection and redundancy. This has to be achieved by always weighting user expectations and the support each user is willing to give as well as the network support (access sharing) each user can in fact provide to its counter peers in the network. Mobility anchor point location and selection optimization is therefore a crucial requirement of UCNs.

Table 1 summarizes both assumptions and requirements for mobility management in UCNs.

Table 1 Mobility management assumptions and requirements in UCNs
Full size table

4.2 Problems

Current approaches to distribute mobility anchors focus on a light distribution of all mobility functionality, as a unique block (such as the Home Agent in MIP), through some network elements. Thus, most of the approaches do not decouple the mobility management functionality, which in our vision is crucial to achieve a better performance of mobility management when integrated with user-centric scenarios. Most of the proposals do not implement any kind of decoupling of functionality, and consequently they cannot have different degrees of distribution for different mobility functionality. Besides, most of the solutions do not follow flexible architectural principles, which allow the integration of selection mechanisms to optimize the mobility management [7]. Furthermore, DMM approaches do not consider the case of an anchor failure, so they do not implement mechanisms to support fault-tolerance, which can be really important when considering that some anchors can be placed closer to the user in user-centric environments.

From a mobility management perspective, the major implications faced by those scenarios is the fact that if we consider the possibility of placing some mobility management functionality in the customer premises, the MAPs may appear and disappear suddenly, thus exhibiting a high degree of variability which impacts the network operation as well as the user Quality of Experience (QoE). The QoE perception of two users that use the same mobility management mechanism could be completely different, depending on the user behavior and required services. Thus, QoE metrics and mechanisms should give an important contribution in the selection of mobility management. Another aspect relates to the fact that the roaming environment on user-centric scenarios is strongly dependent on human behavior, which, from a networking perspective, relates to social networking aspects. Thus, daily user’s movements usually present mobility patterns, by repeating the same actions and visiting the same places. Furthermore, the behavior of each user can show us his/her type of mobility, such as the pause times and crossed distances.

An aspect that may be critical to mobility management in the face of UCN is that due to the bet on centralized approaches, mobility management solutions are today available at OSI Layers 2, 3 or 6, or even between layers (as is the case of the Host Initiation Protocol, HIP [28]). Focusing on the network layer, solutions are normally based on a centralized approach, client/server paradigm. Part of the functionality resides on the MN, but the control-plane intelligence resides on a centralized MAP. The mobility management protocol is typically based on the principle of distinguishing between node identifier and routing address and maintaining a mapping between them, called binding. For instance, in MIPv6 the Home Address (HoA) serves as the identifier of the device whereas the Care-of Address (CoA) takes the role of routing address; the binding between them is maintained at the MAP, in this case, the Home Agent (HA). MIPv6 is a centralized mobility management approach; therefore, the mapping information between the stable node identifier and the changing IP address of an MN is kept at a centralized HA. Besides centralized binding placement, routing/forwarding is also centralized, since the HA acts also as a data central anchor, routing packets destined to an MN whenever is necessary. In other words, such mobility management systems are centralized in what concerns control and data plane and hence not the most suitable to be directly integrated into scenarios that, such as UCNs, where nodes roam frequently, even if following a specific movement pattern, tied to a specific routine which can be statistically defined.

Several other existing mobility management deployments make use of centralized mobility anchoring in hierarchical network architectures. Another example of such centralized mobility element is the Local Mobility Anchor (LMA) in Proxy Mobile IP (PMIPv6) [16]. Moreover, current mobile networks such as the Third Generation Partnership Project (3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System (EPS) networks also employ centralized mobility management, with the Gateway GPRS Support Node (GGSN) and the Serving GPRS Support Node (SGSN) in the 3GPP UMTS hierarchical network, and with the Packet data network Gateway (P-GW) and the Serving Gateway (S-GW) in the 3GPP EPS network [24].

The main problems of current centralized approaches for mobility management in flat networks can be summarized as follows:

  • Signaling via a centralized anchor is often longer, so that those mobility protocol deployments that lack optimization extensions results in non-optimal routes, affecting performance; whereas forwarding optimization may be an integral part of a distributed design.

  • As a mobile network becomes less hierarchical, centralized mobility management can become more non-optimal. In contrast, distributed mobility management can support both hierarchical networks and flat networks. Furthermore, the recent trend in network flattening, with connectivity sharing among users in the same geographical area and direct communications among them, reinforce centralized architectures weaknesses.

  • Centralized route maintenance and context maintenance for a large number of mobile hosts is more difficult to scale. Scalability may worsen if there is no mechanism to determine whether mobility support is needed; dynamic mobility management (i.e., selectively providing mobility support) may be better implemented with distributed mobility management.

  • Excessive signaling overhead should be avoided when end nodes are able to communicate end-to-end; capability to selectively turn off signaling not needed by the end hosts would reduce the handover delay.

4.3 Splitting Mobility Management Functionality

As mentioned before, a first step to address in terms of understanding up to which point and how to develop de-centralized mobility management architecture relates to being able to better compose the functional sub-blocks required by such architecture. Therefore, thinking about mobility management functioning in a fine-grained way, we have identified a group of functional blocks as addressed in Sect. 3. Based on the dynamics of UCNs, the first step towards a more suitable mobility management approach is by understanding and further analyzing the basic tasks a mobility management system should provide.

Towards the idea of making mobility management more flexible (being the aim a reduced operational cost), Chan et al. suggest to position the mobility anchors closer to the mobile nodes, ideally in the first element visible on the path from a MN perspective [8]. Sofia et al. proposed and validated in comparison to centralized approaches the separation of management functionality into two elements, attempting to decouple data plane and control plane [31, 40]. In the proposed architecture, the HA-C (control plane element) is located in a server, and HA-Ds (data plane elements) are positioned in the access nodes, close to mobile nodes. Chan relies on the PMIPv6 solution, and also splits the mobility anchor functionality into three logical blocks [26]. Although the author states that those blocks of functionality are placed in the home network, they do not need to be placed in the same physical entity. Those works can be considered as a first step towards an architecture where the management functionality is split and distributed in different places in the network.

Condeixa et al. [10] provide a performance evaluation of a generic model of centralized vs. distributed mobility management approaches, showing significant improvement when distributed mobility management solutions are applied to environments such as UCNs.

Such approaches, the positioning of the MAP as well as the definition of interactions between the different roles of mobility management have been object of heavy analysis. Still, today there is not truly consensus in where MAP and additional functionality should reside. Such positioning depends on the network architecture and requirements; on the OSI Layer being tackled, as well as on the overall complexity from a technical and policing perspective. Considering that user-centric networks present particular characteristics (e.g. there is no clear splitting between network elements and end-devices), the current centralized standards may not be suitable. Thus, a novel mobility management approach should be designed for such networks, considering all its particularities and following this trend of rethinking the mobility anchor point element.

4.4 Solutions to Optimize the Distribution of Mobility Anchor Points

As the first step towards the distribution of mobility anchors is the analysis of the currently available proposals. A first approach relates with distributing the mobility management control in a way that becomes more functional from an end-to-end perspective. Several solutions today realize the need to address such control, by providing a better distribution of mobility anchor points, e.g. Hierarchical MIPv6 (HMIPv6) [42]. PMIPv6 splits the mobility management functionality that is in MIPv6 integrated into the MN, between this node and the network element Mobile Access Gateway (MAG). The MAG and the LMA manage the binding between the HoA and CoA, perform encapsulation and de-encapsulation, and are the tunneling endpoints for the traffic between the MN and the CN. The Flat Access and Mobility Architecture (FAMA) [14, 15] suggests moving the functionality of the HA closer to the edge of the network and placing it in the default gateways that provide IP connectivity to the MNs. Thus the access routers, called Distributed Access Routers (DARs), provide not only the access to the Internet for these MNs but also perform mobility management. However, FAMA does not specify when and under what conditions an MN would want to retain use of its old IP address. FAMA also does not specify whether the MN is associated with a permanent address that can be used to reach it by default. The use of multiple anchored addresses mandates a mechanism (such as DNS) on the correspondent node side to retrieve a proper and valid destination address for the MN. Care should also be taken to avoid routing loops between DARs and routing dead ends whenever the MN mutually binds a new and old address to two different DARs.

A second category of work takes a look at reliability and availability of MAPs by considering semi distributed architectures, i.e., some form of redundancy of elements. For instance, the Home Agent Redundancy Protocol (HARP) [17] applies the notion of HA cluster to provide reliability, where one HA from the group becomes the active HA and receives binding requests and updates from the MNs. Following the same line of though, Dynamic Mobility Anchoring (DMA) [37] proposes to distribute mobility traffic management with dynamic user’s traffic anchoring in access network nodes. The solution relies on a flat architecture, where the Mobility capable Access Router (MAR), implemented in access nodes supports both traffic anchoring and MN’s location management functionality. This is also the context of the Signal-driven Distributed PMIP (SD-PMIP) [22] which considers redundancy of all elements, control and data plane.

Closer to our belief that the functional blocks of mobility management themselves must be also distributed (and not only the physical elements that compose the mobility management solution), the Proxy Mobile IP with Distributed Mobility Anchors [6] propose to split the logical functions of a mobility anchor into three functional blocks: (1) allocation of home network prefix or HoA to a MN that registers with the network. (2) inter-network location management (LM) function; managing and keeping track of the inter-network location of MN, which include a mapping of the HoA to the mobility anchoring point that the MN is anchored to. (3) mobility routing (MR) function; intercepting packets to/from a MN’s HoA and forwarding the packets, based on the inter-network location information, either to the destination or to some other network element that knows how to forward to the destination. The logical functions of the Home Mobility Anchor (H-MA) do not need to be in one single physical entity or even co-locate. It is possible to have multiple instances of the LM and MR functions, and they do not need to be in one-to-one relationship.

5 Predicting Movement to Optimize Mobility Management

Mobility estimation, when applied to mobility management, can assist in reducing signaling overhead derived from the roaming behavior of MNs in self-organized environments such as UCN. Using the identifiers of visited networks together with the collection of network parameters for ranking visited networks enables the estimation of user roaming behavior in an easy way with no signaling overhead based on existing technologies which requires only small modifications on existing systems. Hence, based on intelligent and local algorithms, mobility estimation can be used to rank preferred network selection in a passive way, without any additional signaling overhead, but instead based on information that controllers in visited networks already send around automatically to nodes involved in visits. A resulting list of visited networks can reflect user and network preferences/policies. It can also incorporate some properties learned with the roaming behavior of the user in regards to visited networks.

Figure 2 illustrates three wireless visited networks served respectively by AP1, AP2, and AP3. MN periodically visits the three networks. Moreover, each visited network is served by a specific MAP which can be co-located to the AP, or placed somewhere else on the network, as occurs today.

MN follows a regular routine trajectory e.g. during a day, where it crosses the three different visited networks. Following the regular IEEE 802.11 operation MN is set to perform passive scanning, i.e., while roaming it passively receives Beacon frames sent by the surrounding APs. It can therefore get a list not only of APs that it regularly attaches to, but also of neighboring APs that it did not visit. We highlight that there is no relation whatsoever with GPS location or tracking of the nodes. MN integrates also some mobility management solution, e.g. MIPv6 or PMIPv6. On its list of visited locations, it keeps track of the different SSIDs, MACs of the APs, as well as a list of relevant parameters, for which an example is provided later in Sect. 5.1. Periodically and based on the collected input MN ranks the different visited networks and provides a time estimate for a move. Based on such estimate, MN can selectively trigger binding updates to the respective MAPs, as illustrated. In the next section we describe a tool that we have developed and that is available as open-source software, to incorporate mobility estimation into current or future mobility management solutions.

Fig. 2
figure 2

Example of Impact of Mobility Estimation

Full size image

5.1 The MTracker Solution

We have developed an instantiation of the proposed estimator in the context of the European project ULOOP - user-centric Wireless Local Loop [12], a tool which is named MTracker. The Mobility Tracker (or MTracker) [39] is an application that passively tracks anonymous properties of a user’s roaming behavior, and ranks each visited network based on a specific algorithm which takes into consideration aspects such as number of visits to a given access point and the average duration of such visits. Our solution is available as software licensed as LGPLv3.0. It relies on an algorithm which shall provide as outcome an estimate of time for the next move, and potential targets (list of ULOOP gateways with a priority) for the move. This outcome is then fed to the handover support module of ULOOP.Footnote 1

The MTracker application then tries to predict how much time the node will change the network connection, and which will be the next visited network. Figure 3 illustrates the main components of the MTracker, which has as input parameters that are passively collected by a node. This functionality is expected to reside on the end-user device, and as shown, has as input parameters that are passively collected by a node. The input is expected to be passively collected and to be obtained via background processes. The roaming behavior is analyzed via the Social Mobility Analyzer (SMA) entity which then periodically feeds the outcome to the Predictor entity.

Fig. 3
figure 3

High-level architecture for social mobility tracking and estimation

Full size image

A few examples for parameters that can be collected both directly via a software plugin (based on passive listening) in regards to visited networks preference characterization:

  • List of the MAC addresses for the most visited gateways.

  • Average node speed.

  • Number of times the node has seen a MAC attachment requested redirected

  • Average stationary association time.

  • Aggregate perspective on the roaming behavior of a node, e.g. daily, weekly, monthly values.

The Predictor is the entity that provides the final estimate for a potential handover. The Predictor’s core is an algorithm which shall provide as outcome an estimate of time for the next move, and potential targets (list of ULOOP gateways with a priority) for the move. This outcome can then be fed to a mobility management process, which can then decide whether or not to activate a handover.

The Predictor entity relies on the time T estimate for a potential move to target G. The selection of target G is based on a ranking utility function [39] which receives as input the parameters collected, and provides as output a rank for the gateway. The time estimate T relates to the average duration of a visit. The way this is computed in our tool is based on the average time a node connects to a gateway. In other words, the MTracker definition of stationary time is: the period between the instant a node becomes connected to a ULOOP gateway, until this connection is first broken, provided in seconds.

5.1.1 Operation

Figure 4 provides a flow-chart for the MTracker operation in the context of the ULOOP project, which assumes, in the context of mobility management, two key aspects: (i) there is a process, the MCF, which optimizes the availability of anchor points; (ii) in its proof-of-concept, ULOOP considered PMIPv6 as a potential mobility management solution.

The MTracker runs in the background. ULOOP assumes two different node roles: a regular node represents, for the context of mobility management, a role in the MN. While a gateway corresponds to the server side, where the control intelligence resides.

Fig. 4
figure 4

MTracker Flow-chart in the context of UCNs

Full size image

5.1.2 The MN Side

MTracker operates on the client side, as previously explained - refer to the right-hand side of the flow-chart. There are two main processes that the MTracker performs. One relates with tracking (collecting) data concerning visited networks. The other relates with estimating the next potential handover.

The first step after opening the MTracker list of visited networks (which is kept locally or remotely on another server). Assuming the node has Wi-Fi access it goes through the regular 802.11 operation (scanning) and periodically updates the data concerning the list of visited networks, including the computation of the ranking for each visited network.

The second part, also processed in background, relates with the time estimate and MAP target for a next handover. We highlight that the MTracker only notifies an entity (a user, some entity on the network, or even some other process in the local device) that a potential move may occur, so that a decision may assist the device in reaching some form of reliability in terms of active communication flow. Hence, it is up to the mobility management solution to perform such a move, or not, based on the information provided by the MTracker.

The estimate is based both on the computed ranking cost, as well as on the average duration of a visit. To provide a concrete example based on Fig. 2 we assume that MN has recorded an average visit duration of 15 min to AP1. On the current visit, 6 min have elapsed. Periodically, MN analysis its list of visited networks and checks whether or not the average duration visit is being reached. From a computational perspective, this means that MN has a time threshold which in this example we consider to be e.g. 1 minute, to reach and eventually send a notification to an entity in the current visited network (e.g., AP, MAP, etc). So, in our example, after 6 min, MN realizes that there is still a gap of 9 min and therefore does not send any information. When MN1 realizes that the current visit has reached 14 min, it sends a notification about the best possible visited network which, in our example, is the visited network served by AP3. In that notification, it therefore sends information to MAP1 about the best next MAP–MAP3, and also about how much time in average is left for a move. MN does not perform, however, any decision concerning moving (handover).

5.1.3 The MAP Side

In the context of PMIPv6, that information is provided to the MAG, which does not require any modification to handle such information. MTracker provides a server-side abstraction which takes care of collecting the notification provided by the MN, and sending it to the intended server-side component—the MAG, for our example.

6 Summary and Future Work

In this paper we describe our investigation concerning a better application of mobility management solutions in the context of environments such as UCNs, i.e., environments where networking elements are also subject to the Internet end-user control and willingness to share resources.

We have explained the main problems with current solutions, in particular, resource management, security, and predicting some characteristics of movement as a way to reduce the cost of dealing with mobility management. The work explains why distributed mobility management is more suitable for environments in which Internet connectivity is also provided and controlled by the end-user, by tackling aspects like the optimization of the distribution of mobility management elements in the network, the de-centralization of functionality in a way to achieve scalability and alleviate the load, mechanisms for automatic detection of such decentralized elements, and the signaling mechanism required by those elements to perform all the mobility management functions.

Based on a specific proof-of-concept developed so far in the context of the project ULOOP and also based on validation of solutions that we have developed in related work, we can state that the decoupling of mobility management functionality and the distribution of mobility management functionality in different points in the network are beneficial and improve network aspects, representing an adequate path towards mobility support in future networks architectures. Moreover, we have also exemplified the application of mobility estimation to mobility management, showing that it does not impose any significant additional cost, and explaining which benefits may arise from integrating mobility estimation even in the context of current centralized solutions.

As ongoing work, we are currently evaluating the proposed estimation in the context of today’s most popular mobility management approaches, namely, PMIPv6, and understanding how to better integrate such solution in the context of distributed mobility solutions, such as the DMA proposal.