Guidelines towards Information-Driven Mobility Management

Abstract

The architectural semantics of Information-Centric Networking bring in interesting features in regards to mobility management: Information-Centric Networking is content-oriented, connection-less, and receiver-driven. Despite such intrinsic advantages, the support for node movement is being based on the principles of IP solutions. IP-based solutions are, however, host-oriented, and Information-Centric Networking paradigms are information-oriented. By following IP mobility management principles, some of the natural mobility support advantages of Information-Centric Networking are not being adequately explored. This paper contributes with an overview on how Information-Centric Networking paradigms handle mobility management as of today, highlighting current challenges and proposing a set of design guidelines to overcome them, thus steering a vision towards a content-centric mobility management approach.

1. Introduction

Internet traffic is consumed and produced by heterogeneous sets of mobile, resource-constrained end-user devices which are interconnected via fixed or wireless/cellular infrastructures. Moreover, the evolution of the Internet infrastructure, of which 5G is a relevant part, brings in new requirements, such as the need to support large-scale Internet of Things (IoT) environments, strict end-to-end latency requirements, and service-oriented model support [1]. Mobility management plays a key part in this evolutionary step of the Internet, and IP-based mobility solutions have been evolving towards the support of network decentralisation, to be able to cope with high topological variability, among other issues. Being based on the principles of IP networks only, current mobility management solutions face limitations such as the lack of integrated security; the need for an end-to-end path between consumers and producers; and being focused on host reachability, instead of on data reachability. Several engineering workarounds have been assisting the evolution of such mobility management solutions towards more complex, large-scale environments.

Information-Centric Networking (ICN) architectures, such as the Named Data Networking (NDN) architecture, have intrinsic features that are better suited to support environments with a high degree of mobility. For instance, ICN focuses on content and not on hosts as the addressable entities, thus providing better communication support while devices are on the move. Its connection-less nature and interface abstraction model are interesting features to support many-to-many communications, even if connectivity is intermittent [2]. Its per packet pull-based communication model is, at a first sight, sufficient to support consumer node mobility. On the other hand, its pull-based receiver-driven model does not support well mobility of producer nodes , as explained further in Section 4.4. Producer mobility is being handled by anchor-based proposals that mimic, in some aspects, IP-based mobility management and, consequently, are following a host-reachability mobility management model, instead of a content-centric one.

To better understand how to develop future mobility management solutions, it is necessary to think about the different mobility management functions, and how they are served (or not served) by ICN.

This work contributes to the debate on how to evolve mobility management, in a way that truly becomes content-centric:

• It highlights the functions that compose mobility management, based on the main architectural solutions developed thus far (Section 3).
• It explains ICN mobility management efforts, highlighting challenges to overcome (Section 4 and Section 5).
• It provides a set of architectural guidelines aiming at providing a content-centric approach to mobility management and yet, assisting interoperability needs (Section 5 and Section 6).

For this purpose, Section 2 covers related work explaining our contributions, while Section 3 provides a debate on mobility management functional aspects. Section 4 covers ICN mobility management. Guidelines towards a content-centric mobility management solution are provided in Section 5, being the paper concluded in Section 6, where future directions for research on this topic are also provided.

2. Related Work

Mobility management comprises a wide set of related work, including an extensive set of proposals that has been developed to support mobility from the perspective of different OSI Layers [3]. Out of the available solutions, IP-based solutions are today the basis of mobility management in cellular and wireless environments. The most recent evolution of such category of solutions concerns distributed mobility management and is being steered by the Internet Engineering Task Force (IETF) Distributed Mobility Management (DMM) Working Group [4]. Decentralisation of IP-based mobility management relates mostly with the integration of these approaches in large-scale heterogeneous environments (such as 5G) as well as with support towards flatter networking architectures [5]. The debate on decentralisation covers a wide set of topics, including decoupling of data and control planes, better management of mobility anchor points, etc.

ICN introduced a relevant simplification, namely information-centricity instead of host-reachability. The capability to store status and data in routers (store-and-forward) provides the grounds to better support mobility of devices in a network. In this context, a thorough overview on mobility aspects for one of the existing ICN architectures, NDN, was provided by Zhang et al. [2]. The authors approached advantages and disadvantages in different scenarios with the aim of further assisting the support of mobility. Their analysis is compared to IP-based approaches in terms of architectural design. Zhu et al. provided a global overview on the NDN design and mobility support, alerting to the need to consider a better support for producer mobility [6]. In fact, most related work has focused on improving producer mobility, i.e., supporting movement of devices that provide data. Auge et al. provided a relevant overview on mobility support, in particular for environments focused on the interoperability of ICN and IP, proposing an anchor-less solution to support mobility coupled to a routing protocol [7]. Kite is a mobility solution for NDN which exploits NDN forwarding state to keep track of moving producers and their whereabouts. Kite follows IP-based approaches by considering a “rendezvous point” which assists in tracing where data are, while the producer performs reattachment to a new location [8].

Chen et al. described the steps towards a reference model for mobility-driven networks, debating on evolutionary principles such as the decoupling of service and device entity, for vertical handovers, and entity/locator identifiers, for horizontal handovers [9]. Tyson et al. provided a survey on ICN mobility issues from an architectural perspective, highlighting potential benefits brought by the ICN networking semantics [10]. Our paper closely follows the line of work that is focused on assisting in further evolving mobility management in an interoperable way, by learning from prior approaches, while at the same time by trying to keep the beneficial properties of ICN design (content-centricity). A contribution of our work is a clarification on different functional aspects of an abstract model of mobility management derived from prior learning. A second contribution is a clarification on the different functional entities (mobile node and correspondent node) and where they fit ICN architectures. A third contribution concerns an analysis of current mobility management approaches, and guidelines to assist a consolidated design of future mobility management approaches.

3. Mobility Management Functional Aspects

Mobility management is a relevant network function in today’s Internet, and yet it is still one of the most challenging. The purpose of mobility management is to provide support for active communication in a way that allows services to be active with the least interruption, while users are on the move. For that purpose, mobility management handles three main processes: (i) location management; (ii) handover management; and (iii) multi-homing.

Location management has as a main purpose allowing data to flow adequately between source and destinations, independently of the whereabouts of the involved devices. Location management is supported by binding mechanisms that support the mapping between mobile nodes to specific identifiers, before, during, and after a move occurs.

Handover management concerns being able to identify new points of attachment for mobile nodes, and to allow data and signalling to flow to the new whereabouts of devices, while they are moving.

From an end-user perspective, Multi-homing concerns support for a device to use simultaneously its multiple interfaces, in order to increase performance and/or reliability of data transmission. From a network perspective, multi-homing concerns supporting one or multiple services, via two or more distinct network regions (or segments), towards consumers.

In a pursuit to support these three processes, IP-based mobility management solutions share three main functional entities: (i) Mobile Nodes; (ii) Correspondent Nodes; and (iii) Mobility Anchor Points. The placement of these functional entities is illustrated in Figure 1. Such entities can then be co-located with different devices, depending on the selected mobility management approach [11].

The Mobile Node (MN) corresponds to a functional entity that is part of an end-user device. Today, it is often located in a portable, battery-constrained device which is wireless or cellular enabled. The MN is the mobile or static entity that triggers communication. The MN has an active communication towards peers over the Internet, known as the MN Correspondent Nodes (CNs). The MN has one (or more) identifiers, e.g., IPv6 addresses such as occurs in Mobile IPv6 (MIPv6) and its extensions; URIs for a mobility management solution such as the Session Initiation Protocol (SIP); and a locator-id based identifier for a solution such as the Host Initiation Protocol (HIP). The MN functional role resides both on the data and control plane.

The CN represents an “active partner” of the MN. The CN as defined in IETF RFC4885 [12] is “Any node that is communicating with one or more MNs. A CN could be either located within a fixed network or within a mobile network, and could be either fixed or mobile.” Today, it is an entity residing in a mobile device and is the receiver of a communication process started by the MN. In ICN, the functional representation of MN vs. CN could be simplified by considering a single entity, as we further explain in Section 4 and Section 5. The reason to still differentiate between these two functional entities relates with the evolution of the Internet: at first, mobility management approaches were developed to support service and session continuity for the consumer of that service. This was the MN. The signalling required to support handovers was devised having in mind that particular entity, and assuming that all other elements in the network would be static. Later, with the introduction of two-way real-time communication in mobile environments, the solutions developed integrated extensions to handle CN mobility, as well as to attempt to handle simultaneous mobility by all of the involved parties.

The Mobility Anchor point (MAP) is a functional control plane entity that may reside in a network element (e.g., in a router) or in an end-user element (e.g., end-user equipment and server). The MAP controls the main functionality of mobility management, namely handover management, traffic offloading, location management, bindings and address translation, Quality of Service (QoS), and forwarding policies.

Learning from the evolution of prior solutions, and from the extension required to support additional features such as simultaneous mobility, it is relevant to consider that any future mobility management architecture needs to be designed already having in mind that any node on the network can move. Furthermore, it needs to consider that, due to the way the Internet is evolving, these functional entities can reside in any type of device, even embedded ones.

To further debate on how such support can be provided, the functional design of today’s solutions can be split into different blocks [11]:

• Identification. For IP-based solutions such as MIPv6, this would correspond to the mapping of a network interface to an IPv6 address; in SIP, this would be a mapping between an URI (known address) and one or multiple IPs; and in HIP, this corresponds to a Locator Id.
• Database control. Control functionality is usually provided by a central entity, which assists in a quicker mapping of the different identifiers. Usually, this functionality is part of the MAP entity.
• MAP selection. This is a control function that assists in a better deployment of MAPs having in mind to improve reachability of MNs. In centralised solutions, such selection is often performed in a static and centralised way.
• Binding registration. This is a control plane function that signals the first registration of a MN in a mobile system. For instance, in MIP, it is the first Binding Update message sent to a MAP or to a CN. In SIP, it is the REGISTER message sent to the Registrar server.
• Binding update. This is a control plane function that signals an update a record in the Identification control. Binding updates are used when the unique identifier of a device changes.
• 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 MAP or by the first access router in the path (Home Agent, HA). In SIP, this process can be performed by an external element, for instance, an RTP translator.
• Handover negotiation. This is the process taken when the device has its identifier changed, to allow active communications to be held with the least disruption. In MIP, the handover negotiation may be anticipated with, e.g., mechanisms such as the Fast Handover extension. SIP does not implement any anticipation, performing a re-negotiation after the connection between peers is lost.
• Resource management. This is the process that assists in guaranteeing the quality of a connection while devices perform a handover. Most solutions as of today do not integrate QoS support, recurring to external mechanisms to provide such support.
• Mobility anticipation. It is the procedure of performing a handover before an active connection experiences a break. For instance, anticipation is partially supported in MIPv6 via the extension Fast Handovers for MIP.
• Security and privacy. It refers to every security mechanism to assure the integrity of both data and channel for the active communication, as well as for the signalling of the mobility management system. Current centralised solutions require external security support to protect data, channel, as well as involved signalling.

The evolution of mobility management towards information-centricity (and, hence, better service support) requires looking into these different functional blocks, and understanding whether or not they can be simplified. To further assist such evolution, it is also relevant to remind that IP-based mobility management approaches have been designed keeping in mind support of mobility from a source-driven perspective. On later phases, adjustments of the centralised solutions for support of simultaneous mobility [13] as well as non-simultaneous mobility have been introduced. This is the case, for instance, of the Return Routability Procedure for MIPv6 solutions, intended to assist CN mobility.

As also stated in Section 2, efforts towards the evolution of IP-based mobility management is approaching a distributed vision, having in mind the support of mobility for the different entities, where IPv6 is the underlying protocol. In such context, solutions have looked into MAP selection and discovery; forwarding path and signalling management; and exchange of control information to assist faster handovers (e.g., better selection of identifiers to use on the new attachment locations).

4. Mobility in ICN

4.1. Mobile Nodes, Correspondent Nodes, and MAPs in ICN

The ICN architecture embodies a publish/subscribe pull-based communication model. Producer nodes correspond to devices that send data (Data packets), once they get an expression of interest by consumer nodes (Interest packets). Data are sent back following ICN forwarding strategies, and based on the network state left by Interest packets in routers along the way.

From a functional and interoperable mobility management perspective, producer nodes and consumer nodes may be associated with both the MN or the CN functionality. At first glance, and from an abstract, functional perspective, mobility management entities could be reduced from MN vs. CN into a single MN entity, for instance. However, ICN is receiver-driven, while IP mobility management solutions are source-driven. Furthermore, ICN does not require the functional concept of a MAP to support mobility, as binding is directly performed to content and not to hosts, as shall be explained next.

4.2. Architectural Design Advantages

ICN integrates several features that are beneficial from a mobility management perspective. To assist in the understanding of such advantages,

Table 1. Mobility management functional blocks, support in different mobility management solutions.

Functional Blocks	MIP [14]	SIP [15]	HIP [16]	M-SCTP [17]	ICN [2]
Identification	IP address (interface)	URI (unique, associated with user)	Locator Id (device)	IP and port	Name prefix (content)
Id database control	MAP	Centralised, controlled by the provider. access through the MAP	MAP	None	Not required
MAP	Centralised solution, located in the provider premises (HA, access router)	Centralised solution, located in the provider premises Proxy SIP (server)	Centralised solution, located in the provider premises	Centralised solution, located in the provider premises	Not required
Binding mechanism	Periodic Binding Update message, MN to HA, MAP or CN	REGISTER message, MN to Registrar Server or Outbound Proxy	-	-	Pull-based Interest packet approach; in-network caching
Routing/forwarding	IP based (shortest-path)	Proxy or RTP translator	Dual, based on locator and on IP	IP-based	Data-based routing, forwarding strategies adapted to mobility
Handover negotiation	Make- before- break, with FMIP access routers negotiation	Break- before- make, RE- INVITE message, MN to CN	Make before break	Break before make, requires setup of new TCP connection	No need for consumers; required for producers
Resource management	None	None	None	None	Forwarding strategies
Security/privacy	Not integrated	Not integrated	Yes, intrinsic to HIP	Not integrated	Yes
Handover Anticipation	Partial, e.g., FMIPv6	No	No	No	No

provides an overview on how the different mobility management functional blocks described in Section 3 are supported via the most emblematic mobility management solutions of today.

From a mobility management perspective, a first advantage of the architectural design of ICN against its IP-based counterparts is the focus on content, instead of on host reachability. In ICN paradigms, content becomes the addressable entity, instead of a host identifier. Content is also the routing target, which serves better the handover process: there is no need for a database identifier control process, for instance.

A second advantage of ICN is its interface abstraction, Face. Faces provide a better support for multi-homing, including security [18]. Faces are also relevant in the support of distributed mobility management. The Face abstraction provides the means for applications to seamlessly and securely interact with multiple physical and virtual interfaces, as there is no dependency on interface identifiers or on host identifiers. Adding to the Face abstraction, Forwarding strategies serve better multi-homed devices, as Interest packets can be forwarded having in mind specific requirements for multi-homed environments. Forwarding strategies are based on the information stored in the Forwarding Information Base (FIB) and additional traffic measurement. The Pending Interest Table (PIT) stores Name Prefixes for which consumers expressed interest. Data packets simply follow the state left in the PITs.

Thirdly, the pull-based communication model of NDN, where data are only sent if Interest packets are first transmitted, allows for a binding signalling reduction during the handover process.

A fourth advantage of the architectural design proposed in ICN concerns the flexible forwarding strategies and the routing, which is data-oriented. Such approach provides better support for multi-homing environments, as well as for the support of frequent movement by devices.

4.3. Mobility Management in Different ICN Solutions

While ICN approaches have in common the advantages described in the previous section, different approaches tackle mobility management in different ways. To assist in a better understanding of the current situation,

Table 2. ICN main approaches, mobility challenges.

Approach	Mobility Management Description	Consumer Mobility	Producer Mobility	Multi-Homing
DONA [19]	Anchor-based, early-binding approach, producers register identifier to locator mapping that must be resolved before data can be sent. Intends to be interoperable with DNS.	Supported, but not intrinsic	No	No
CCNx [20]	Anchor-less, late binding approach, as data is only sent after an Interest packet is received. There is no direct identifier—locator mapping CCNx can handle 97% of requests during high mobility.	Intrinsic. When a consumer moves, Interest packets are again sent.	No	Yes
NetInf [21]	Anchor-based, early-binding, similar to DONA, even though it requires consumer lookups	Supported but not intrinsic.	No	No
PSIRP [22]	Anchor-based, late-binding, requires consumer re-registration after moving.	Intrinsic. When a consumer moves, Interest packets are again sent.	No	No
JUNO [23]	Middleware takes care of information-centric functionality. Relies on a DHT approach, where flat identifiers for content are registered.	Supported but not intrinsic. Middleware takes care of the mobility.	No	Yes
NDN [24]	Similar to CCNx.	Intrinsic. When a consumer moves, Interest packets are again sent.	No	Yes

describes whether/how producer mobility, consumer mobility, and multi-homing are supported by reference approaches.

As described in Table 2, none of the main ICN architectures provides seamless producer mobility support. As for consumer mobility, existing approaches either take care of such support based on anchor-based approaches, following IP-based learning, or via anchor-less approaches. Furthermore, multi-homing is supported only in JUNO, CCNx and NDN.

These aspects are further debated on the next sections. The description provided is focused on the line of work derived from CCNx, including NDN.

4.4. Multi-Homing

ICN supports end-user device multi-homing via the Face abstraction. Support for networked multi-homing is achievable via ICN multi-path forwarding strategies, and routing. The Face abstraction brings in the possibility to jointly explore data transfer to multiple services and applications as well as to physical interfaces. Moreover, multi-homing is supported with fine-grained control: the ICN per packet pull-based model provides better support for resource management aspects, such as load-balancing (based on packets instead of flows). The ICN forwarding strategies are applied on a local basis: different nodes and/or regions of nodes can have different forwarding strategies, which strengthens multi-homing support capability via ICN.

Therefore, multi-homing is a mobility management process that is naturally supported by ICN approaches. In comparison, prior solutions required additional support of, for instance, Quality of Service (QoS) mechanisms.

4.5. Consumer Mobility

To explain how ICN supports consumer mobility, this section provides two examples: MN acting as consumer and CN acting as consumer. The explanation provided is based on the functional entities described in Section 3, which are the basis for today’s mobility management reference architectures, onto ICN. The purpose is to explain limitations that may arise from such mapping. MN is an ICN producer that is directly connected to the NDN router B, and in active communication with a consumer CN. Both MN and CN reside in mobile nodes. Between NDN routers A and B there is a distance of k hops. Router B and D are connected via a distance of N hops. Connectivity can be intermittent.

4.5.1. MN as Consumer

Figure 2 illustrates a scenario where a MN is attached to its original network, the home network. A, B, C and D represent routers. As ICN is receiver-oriented, data transmission for this example starts when the consumer entity expresses interest on a specific content, i.e., MN sends an Interest packet $I1$ with a specific Name Prefix. The Interest packet is stored in the PIT of ICN devices along the path (routers A, C, and D), until it reaches a node that has the requested content, the producer, or a router that already cached the respective content in its Content Store (CS). Meanwhile, and while packet I1 is being transmitted, MN starts to move and reattaches to router B, that serves a Visited Network. Based upon ICN principles, once reattachment occurs, MN again sends an Interest packet with the same Name Prefix (I1). When this packet reaches router C, this router already has the content requested stored (D1) and therefore, the forwarding of Interest packet I1 stops. The subsequent data exchange is directly handled between MN and any device that holds content requested by MN.

4.5.2. CN as Consumer

In this second example, illustrated in Figure 3, the CN entity is the consumer, while MN is a producer of information. In terms of consumer mobility, the situation is similar to the one described in the previous section: CN as a consumer expresses interest (sends an Interest packet, represented by I1) carrying a Name Prefix for specific content, which in our example is being produced by MN. Meanwhile, and either before receiving data or after receiving some data packets, CN moves to a new location, performing reattachment to NDN router B. The receiver-driven design of ICN implies that once CN reconnects to a new node (in our example, router B), it starts sending Interest packets to get the desired content, based on the respective application requirements and settings. Therefore, the pull-based receiver-driven nature of ICN is beneficial for the case of consumer mobility, independently of the entity that is moving. In other words, for the case of consumer mobility, there is no need to distinguish between a MN and a CN entity, in future mobility management solutions.

4.5.3. Consumer Mobility Discussion

As the pull-based model relies on a per packet approach, even if a consumer already received some data chunks and then moves, transmission can be immediately re-established once the consumer (MN or CN) can send data to a neighbour. In our examples, this is synonymous with the consumer being in a state that allows it to forward Interest packets again. At a first glance, ICN supports consumer mobility well. Nevertheless, in large-scale networks and environments where consumers move frequently and quickly (e.g., vehicular networks and personal Internet of Things environments), data transmission may still be affected by frequent movement. Even though the in-network caching provided by ICN can counter-balance such situations, the performance of the data transmission is highly dependent on aspects such as the type of topology, type of movement, and speed of nodes.

4.6. Producer Mobility

Producer mobility is still a major challenge for ICN. To better exemplify the issues with producer mobility, let us consider the scenario previously addressed and illustrated in Figure 4, where MN, after receiving an Interest packet I1 from CN forwarded to MN via router A, sends back packet D1. MN then starts a handover to router B. In this situation and again depending on the topology, the CN will keep on sending Interest packets to get subsequent data chunks. Routers in between keep on looking up their FIBs and, as there is already an entry towards the respective Name Prefix, routers forward the CN Interest packets towards the respective Face (to router A). This process can result in significant latency. To circumvent this issue, there is the need to rely on additional mobility management solutions.

Producer mobility is currently being handled via anchor-based approaches and anchor-less approaches, as illustrated in Figure 5. Anchor-based mechanisms, of which the most relevant is KITE [2,8], follow IP-based approaches and often recur to the use of a “rendezvous” (RV) functional entity to temporarily assist data transmission. KITE tries to exploit the forwarding states to keep track of nodes in movement. KITE considers that applications can send Interest packets to a routable and static anchor entity (an RV) to create the PIT entries as breadcrumbs. The RV is therefore a mediating entity, host-driven. Via this RV-based approach, Interest packets can reach a producer on the move.

This approach requires additional structures in routers—a separate FIB or PIT—as well as additional state to be kept. Furthermore, in current approaches, the RV is considered to be static—mobility of the RV is not handled. Therefore, while such approaches may be relevant from a perspective of interoperability towards IP-based mobility solutions, the overhead introduced can be significant.

In what concerns anchor-less solutions, producers push a notification once a move occurs. Such notification can be based on Interest packets or on Data packets, being currently the preferred choice to rely on a special Interest packet known as Interest Update. This is the case, for instance, of MAP-ME [7], or of MobiCCN [25]. Interest Updates allow for arbitrary small data to be placed in Interest packets as a name component. Such packet is not registered in PITs, as no data are expected to be sent back. Time-to-completion can be reduced by relying on different strategies, such as occurs in MobiCCN, where a specific Name Prefix “greedy:/” supports communication based on a greedy routing protocol. Conversely, a make-before-break approach can be followed, as occurs in the Publisher Mobility Support in Content-centric Networks (PMC) solution [26].

5. Moving towards Content-Centric Mobility Management

The benefits provided by the ICN architectural design in regards to mobility support are the basis to rethink mobility management widely, having in mind a data-centric (and not host-centric) goal.

ICN de-centralised, asynchronous and pull-based model removes the need for a functional centralised or de-centralised MAP. Its architecture can support consumer mobility naturally; however, there is still the need to understand performance impact derived from the type of movement as well as from the types of underlying topologies. In what concerns consumer mobility, the pull-based nature of ICN gives the means to prevent serious packet loss; nevertheless, latency impact is still not clear, and requires future work on performance aspects under highly variable scenarios.

Producer mobility, on the other hand, is still a challenge to be overcome. Related work argues that producer mobility is a small subset of mobility. That has been the case up until recently. With the advent of IoT and with the growth of environments involving autonomous vehicles, producer mobility becomes as relevant as consumer mobility.

5.1. The Relevancy of Context-Aware Proactive Caching

Proactive strategies for in-network caching can assist both consumer and producer mobility, as they support make-before-break strategies, i.e., before a handover takes place. While in-network caching approaches per se may not suffice to support mobility [7], proactive caching can be coupled with an anchor-less strategy to improve mobility support. The key aspect to consider in such approaches is to decide when and where to cache content. Furthermore, reactive caching approaches are useful in the context of host-oriented ICN mobility management approaches, as they assist in reducing packet loss while a node transits to a new location. It should be highlighted that, while in IP-based solutions caching is used in regards to the first router in the path, in ICN caching refers to the content of the moving node and/or NDN routers in between.

Having in mind the support of data-oriented mobility management, proactive approaches assist in caching the node’s content before a handover occurs (make-before-break). The data to cache and when to cache them can benefit from mobility anticipation mechanisms as well as from network context awareness, e.g., history of requests and producer neighbourhood context [27,28].

Measures of neighbour availability and centrality, as well as measures concerning similarity (for instance, similarity in types of requests), and mobility awareness (e.g., handover frequency and estimation of time-to-handover) can be easily provided via an external agent [29]. Such information can assist in anticipating handovers, and selecting beforehand a “best” neighbour to cache producer content.

5.2. Guidelines

ICN is a relevant architecture to be integrated into large-scale mobile environments. While current mobility management proposals aim at solving specific issues under specific scenarios, for instance, producer mobility, future solutions need to consider the following:

• Producer and consumer mobility do not necessarily need to be treated independently, as has been done (by necessity) in prior approaches, which handle MN and CN mobility recurring to distinct mechanisms. In other words, the process of handling handovers should be the same for any node: any node becomes a MN. This can be supported by adding push-based communication support to ICN, via handover anticipation, for instance.
• Mobility anticipation mechanisms derived from context-awareness can be based on a MN’s/CN’s prior history and neighbourhood. Such concept is relevant to assist make-before-break handovers, thus eventually reducing the required signalling. In such cases, producers can perform data push towards a “best” neighbour based on a proactive caching strategy. Via this mechanism, packet loss can be reduced at the expense of a (potentially) small increase in overhead.
• The relevant aspect in an ICN context is “when” a move may occur, and not “where to” the node shall move. ICN provides global naming, so the location where nodes are should not be the key aspect, from a content-centric mobility management perspective.
• A proactive caching approach towards a “best” neighbour of a node can benefit from being associated with a specific Name Prefix, or specific metadata associated with the content to be transmitted. For instance, a timeout (TTL or TLV), or priority numbering.
• Once a move occurs, nodes should emit a notification. While this is the common procedure for consumers, producers can emit an Interest Update notification, as envisioned in the original ICN/CCNx design. This notification allows for a faster routing re-establishment.
• Naming in ICN is hierarchical and independent of location. Nevertheless, today it is common to consider a naming space associated with routing domains, e.g., “/lusofona.pt/videos/”. While such choice does not impact mobility management, it may negatively impact route aggregation, when producers move. ICN applications would benefit from a set of guidelines for the development of the naming space.

6. Conclusions and Future Research Directions

The benefits provided by the intrinsic ICN architectural design in regards to mobility are the basis to rethink mobility management widely and from a content-centric perspective. The ICN architectural design removes the need for a functional centralised or de-centralised mobility anchor-point. As such, anchor-less approaches seem to be a relevant approach as they reduce the need for additional state, and allow ICN supporting mobility management in a data-centric way.

Consumer mobility is well supported from a network architectural perspective, but there is the need to understand performance impact derived from the type of movement as well as from the types of topologies. The pull-based nature of ICN gives the means to prevent serious packet loss; nevertheless, consumer mobility may still result in large time-to-completion intervals.

In what concerns producer mobility, the support is not intrinsic, and the receiver-driven, pull-based ICN approach requires adjustments to fully support producer mobility. Multi-homing is well supported.

While ICN has relevant architectural properties which seem to provide better and integrated support for mobility management, there are a few aspects requiring further research. A first future research direction concerns a better support for mobility management via NDN routing. By devising routing approaches that are sensitive to node movement [30], Interest packets can be forwarded in a way that is automatically based on individual and collective roaming habits of devices, eventually reducing the need to perform re-registration once nodes reattach. This can be done by developing forwarding strategies based on mobility prediction, or by integrating routing support based on context-awareness [31]. A second research direction is to perform an analysis of the ICN mobility support support in highly variable topologies, where anchor-less strategies may not suffice to adequately support producer mobility. For this case, both producer and consumer need to be considered as mobile entities and, therefore, any future mobility management approach should simply look into the support of a single mobile entity, instead of supporting, as previously, a MN and a CN entity separation.