1. Introduction
The Internet has witnessed a tremendous shift in its usage as compared to the original purpose it was designed for. It has evolved from merely an experimental end-to-end host communication system intended to provide connectivity for military and scientific projects into a global content repository for content generation, sharing and access. Realizing this important role started with the conventional World Wide Web (WWW) that enabled content access through websites hosted at server machines. Information is gaining more and more importance with the emerging Internet of Things (IoT), as the majority of users are no longer interested in end host connectivity but rather in information content available [
1]. Mobile content delivery has gained increasing popularity and has evolved to be the key focus of many applications that provide Generated Content. Today, services like Flickr and YouTube, in addition to social media platforms such as Twitter and Facebook, not only provide content access, but also allow mobile users to create and share their own content [
1,
2]. Mobile video data are the fastest growing segment of mobile traffic and is forecasted to comprise 78% of total mobile data traffic by 2023 [
3]. The accelerated growth will be encouraged by wide adoption of live video, Augmented Reality (AR), and Virtual Reality (VR) [
4]. On the other hand, the significant progress achieved in mobile technologies has allowed users to enjoy Internet services during movement, which is facilitated through the use of mobility management protocols. Mobility management is a challenging task since it largely affects users’ experience with respect of preventing frequent disconnections and ensuring session continuity [
5].
Realizing this information centric and mobile usage of the Internet has raised various architectural challenges, many of which have not been handled efficiently by the Internet architecture [
6]. The mismatch between information dominance and the host-to-host communication model of the Internet has led to application specific solutions for content delivery which are very costly and often inefficient. Popular examples include Domain Name System (DNS) redirect which relies on maintaining multiple IP addresses to a single Fully Qualified Domain Name (FQDN) and mapping the FQDN to one of the IP addresses, depending on the location of the IP addresses. DNS redirect selects a nearest Point-of-Presence (PoP) to the local DNS point that is not necessarily closest to the client. This results in some scenarios having highly inefficient mappings, thereby degrading the end-to-end QoS while increasing load inside the network [
7,
8]. Another example is IP multicast that offers point-to-multipoint delivery for group communication applications on the Internet. However, its support for content delivery suffers from a lack of scalable access control mechanisms, address allocation, and network management [
9]. In terms of mobility, the IP host-to-host communication paradigm that ties the end hosts address to its location prevents a moving host from naturally maintaining a single identifier when attaching to different points in the network. Therefore, the moving host is exposed to intermittent and, possibly, opportunistic connectivity. Such an approach does not achieve continuous connectivity while on the move, which is becoming an increasingly important requirement. The problem has generally been addressed by using IP tunnelling through a central anchor point, which tracks the IP addresses of moving hosts and instructs the access gateways to provide the same IP address to the same host [
10,
11,
12].
In effect, the aforementioned solutions help to partially overcome the limitations of the Internet architecture; however, they do not provide a holistic solution to the problem. For example, they suffer from scalability constraints, as they create bottlenecks in the network. This is due to sub-optimal routing via the anchor point, which is often termed as “dog-leg” routing [
13].
In this paper, we present the result of a mobility management approach that utilizes path forwarding architectures. Solutions such as Line Speed Publish/Subscribe Inter-Networking (LIPSIN) [
14], Stateless Multicast Switching in Software Defined Networks [
15], Bit Indexed Explicit Replication (BIER) [
16], and IP-over-ICN [
13] rely purely on path information for end-to-end forwarding of packets instead of relying on host address-based communication with routing information distributed over various network elements. In these path-based approaches, path information can be stored in the forwarded packet (using Bloom filters) and forwarding is done by performing a simple set membership test to deliver a packet traversing the network to the final destination. Therefore, these architectures allow for efficient mobility management, specifically macro mobility support, which is becoming increasingly important for many IoT devices that need to roam across different domains. In this paper, evaluation results using an IP-over-ICN embodiment have shown promising results in terms of the packet delivery cost and signalling costs required to support macro mobility across different IoT domains.
The rest of the paper is structured as follows:
Section 2 provides an overview of mobility management solutions in different access technologies, while
Section 3 presents the related work.
Section 4 introduces mobility over path forwarding architectures, and presents the proposed macro mobility handover solution. The simulation and cost evaluation results are presented in
Section 5, and, finally, the paper is concluded in
Section 6.
3. Overview of Related Work
Fueled by the proliferation of media capable smart phones, the emergence of social networks, and the plethora of IoT sensory applications, there has been an increasing demand for uninterrupted mobile services. A large number of research efforts in the literature have aimed to realise this objective with solutions focusing on Information Centric Networks (ICN). The main drawback of such proposals is that the network stack of every mobile device, together with the application network interface code, have to be replaced [
27,
28]. Here, we look at the most relevant of these efforts.
The authors in [
29] present a blueprint for optimizing mobility support in ICN using the PURSUIT architecture [
30]. They demonstrate that the ICN mechanisms supported in PURSUIT, along with smartly placed in-network caches, enable the architecture to handle both mobile and fixed devices in an efficient uniform way. Mobile nodes can simply reissue subscriptions for information after handover and the network may direct these subscriptions to nearby caches rather than the original publisher.
In [
31], the authors propose a mobility management scheme for Content Centric Networks (CCN) that aims to provide faster service access and lower routing overhead. The solution presents a path redirection scheme, where all communications are done via a home domain content router. The mobile content source informs its home domain content router of its movement by delivering a prefix update message. Evaluation results show lower network convergence time and lower service disruption as compared to basic CCN; however, triangular routing is introduced by tunneling-based redirection.
An anchor-less solution to manage micro-mobility of content producers (Publishers) via a name-based CCN/NDN data plane is proposed in [
32]. The authors focus on Publisher mobility, given that Subscriber mobility is supported in ICN by design (in virtue of its connectionless pull-based communication model). The authors set up a comprehensive simulation environment to evaluate and compare their solution against existing solutions, including a realistic trace-driven car-mobility pattern under a 802.11n radio access. The results show that the proposed solution satisfies its objectives while equalling or outperforming the performance of existing alternatives, both in terms of user related metrics (e.g., loss, delays) and network related metrics (e.g., signaling overhead, link utilization). Similarly, the authors in [
33] describe an initial proposal for an anchor-less approach to manage producer mobility via Interest Updates/Notifications in the data plane, even in the presence of latency-sensitive applications. They detail the different operations triggered by producer movements and define a timely forwarding update mechanism populating a Temporary Forwarding Information Base FIB (TFIB) at routers relaying former and current producer location.
The authors in [
34] present a service-driven mobility support architecture for Information Centric Networks that provides seamless mobility as an on-demand network service. This service can be enabled/disabled based on network capabilities or resource availability. The architecture proposed in [
34] relies on the ID/Locator split on ICN namespaces to support the use of persistent names and avoids name reconfiguration due to mobility. The proposed solution has been implemented over a service-centric CCN platform and showed promising results towards achieving seamless handover.
The authors in [
35] present a multiple-level proxy caching model in an ICN architecture, where content requests from mobile subscribers and the corresponding items are proactively cached to these proxies at different levels. The caching model selects the appropriate subset of proxies and supports distributed online decision procedures in terms of the trade-off between delay and cache cost. Simulation results show significant savings in total costs for both full caching and no caching scenarios.
In [
36], the authors propose an ICN based mobility solution with a special focus on network mobility, where network segments/domains comprising of various networking nodes, consumers and producers can also experience mobility. Evaluation results show that the proposed solution significantly reduces the amount of signalling traffic, routing updates, and path inflation compared to existing solutions while ensuring connectivity for mobile nodes.
In [
37], the authors present a device-level information centric networking architecture that is able to perform intelligent content distribution operations according to necessary context information on mobile user mobility and content characteristics. The authors further introduce device-level online content caching and offline helper selection algorithms in order to optimize the overall system efficiency, which is demonstrated through simulation experiments and modeling.
In [
38], the authors design a mobility-aware proactive caching scheme in ICN to provide delay-sensitive services on Internet of Vehicle (IoV) networks. The real-time status and interaction of vehicles with other vehicles and Roadside Units is modeled using a Markov process. The authors apply Mobility aware proactive edge caching decision that maximizes network performance while minimizing transmission delay. Numerical simulation results show that the proposed scheme outperforms related caching schemes in terms of latency by 20–25% and by 15–23% in terms of cache hits.
In [
39], the authors propose a novel vehicle tracking-based Data packet forwarding scheme (VTDF) to improve the successful delivery rate of Data packets in Named Data Network (NDN) based Vehicular Ad Hoc Networks (VANETs). In this approach, the urban road structure is divided into complex multi-junction and straight lane scenarios and Data packets are forwarded according to vehicle movement information. Simulations indicated that this vehicle tracking scheme provides a lower average data transmission delay, shorter handover delay between roadside units, and higher data delivery rate for Consumers compared to the standard methods.
In [
40], the authors propose a reinforcement learning-based data source selection scheme (RLSS) for efficient High Definition (HD) map distribution in vehicular named data networking (NDN) scenarios. The proposed scheme aims at seeking the best data source (roadside infrastructures or nearby vehicles) in accordance with the map data requests. Specifically, the scheme adopts a deep reinforcement learning-based architecture to learn a neural network as an agent to make the decision of data source selection. The authors have demonstrated through extensive simulations that RLSS can significantly improve the transmission performance in terms of delay, throughput, and packet loss when compared with state-of-the-art data source selection schemes.
All of the above have shown promising results with using an information-centric approach, albeit with the requirement to change the end point networking stack. On the other hand, there are other proposals that enable applications running on IP protocol stacks to utilize ICN networks. They can be summarized as follows.
A general purpose tunneling protocol (IPoC) is presented in [
41], and uses Named Data Network (NDN) semantics and cellular communication as the driving example. IPoC is transparent to the IP applications on either end that remain unchanged. The authors compare their protocol performance with native IP and show that IPoC protocol overhead and performance degradation is minimal. In return, they show how NDN and IPoC can bring ICN benefits to 5G mobile networks by simplifying the mobility plane and introducing intelligent functionality.
The authors in [
42] present a TCP/ICN proxy capable of carrying TCP traffic between TCP/IP endpoints over NDN/CCN. They evaluate several alternative TCP/ICN proxy designs in a simulation environment. Performance measurements of their proxy design using both simulation and real implementation demonstrate that TCP can traverse ICN networks without significant additional delay or loss of goodput.
The authors in [
43] identify a common design space for providing IP and NDN mobility support and propose two knowledge-driven mobility support approaches. These approaches exploit knowledge such as network topology and movement trajectory to tweak the network for better mobility performance. Experiment results show that the knowledge driven approaches significantly improve mobility support performance.
The authors in [
44] propose a hybrid architecture to support video streaming simultaneously over TCP/IP and Named Data Networking (NDN)-based architecture via operating system and networking virtualization techniques. In addition, to relieve users from the burden of installing a new protocol stack (in the case of NDN) on their devices, the authors developed a lightweight solution in the form of a container that includes the network stack as well as the streaming application. A propotype evaluation demonstrates that, in the case of live streaming, NDN achieves better QoE per client than IP and can also utilize higher than allocated bandwidth through in-network caching.
Notably, the proposals above deploy NDN/CCN cores that introduce large stateful Pending Interest Tables (PITs) that keep track of information requests, hence, imposing scalability challenges.
4. Mobility over Path Forwarding Architectures
MN movement within a single operator domain from one Network Attachment Point to another is known as micro mobility or in other words intra-domain mobility. On the other hand, MN movement across two different domains is known as macro mobility or inter-domain. To this end, micro mobility management using a path forwarding architecture is described in detail in [
13], where interested readers are referred to. However, it forms the foundation of our macro mobility management solution introduced in this paper; therefore, a brief description is provided here.
In the proposed path forwarding architecture, we consider four types of entities that take part in any mobility scenario: an MN, a network attachment point (NAP), a Path Computation Element (PCE), and a Forwarding Element (FW). The MN connects wirelessly to an NAP that provides interconnection with a wider distribution network. The PCE determines a path of communication through the network on behalf of a MN or NAP. Optionally, the PCE can also include an information naming function (INF) that provides a method of storing identities (e.g., services, names, and/or IP Addresses) and matching interests. This can help in identifying different services, flows, or bearers for communication. The FW simply forwards information from the MN to the destination using a specific Forward Identifier (FID) generated for this transmission. All the NAPs receive their specified FIDs and populate a local table containing the complete set of FIDs required to reach any other NAP in the network. The first link connecting the MN to the network, e.g., the Network Attachment Point (NAP), is based on the IP protocol, while the NAP serves as an entry point to the core network, which is forwarding based. In the proposed architecture, IP simply becomes a service enabled through the forwarding core, and IP addresses are translated into identifiers used directly for routing.
The proposed handover process is described using the example shown in
Figure 4 for MNs with IP stack and connectivity; however, the solution is equally applicable using any other identifiers. Initially, the MN attaches to NAP A (collocated with gNB A) and performs Link Layer Connectivity and IP Address Establishment. The MN can acquire a global IPv6 address using the Stateless or Stateful address auto configuration procedures (or even manual address configuration) as specified in [
17]. NAP A then extracts the source and destination IP addresses from the first packet sent from the MN towards the corresponding node (CN). NAP A sends a forwarding path request including the identifiers (IP addresses) to the PCE. The PCE (or possibly the INF) keeps track of all MN identifiers in the network and links every identifier to its corresponding attachment NAP. Next, the PCE uses its knowledge of the network topology and end-user identifiers to calculate and send the required Forward Identifier (FID) to NAP A, which at this point is ready to forward packets to the CN at NAP B (Collocated at gNB B). The process described above is only for one side of the communication; therefore, the same should happen at the CN’s side in order to forward packets from the CN towards the MN. Crucially, this process only happens once for new communication flows, and not for every packet.
Upon handover, NAP A notifies the PCE of MN A’s departure so the latter can expect the MN’s connection from a different NAP. MN A then attaches to NAP C (collocated with gNB C) and re-establishes Link Layer Connectivity and IP Address allocation. This triggers NAP C (upon receiving the first IP packet from MN A) to extract the source and destination IP addresses, and send a forwarding path request including the identifiers (IP addresses) to the PCE. Then, the PCE can use its knowledge of the network topology and end-user identifiers to calculate and send the required Forward Identifier (FID) to NAP C which at this point is ready to forward packets to the CN at NAP B.
Macro Mobility Support
The proposed macro mobility solution in a path-based forwarding architecture is presented using an IP-over-ICN embodiment [
45]. This follows a gateway-based approach and provides the necessary path-based forwarding described in
Section 4 above. The access from the MN to the network uses existing IP-based protocols, such as HTTP, CoAP, TCP, or IPv4/v6, while the NAP serves as an entry gateway point to the ICN network and maps the chosen protocol abstraction to ICN. The ICN core employs a Publish–Subscribe paradigm [
45] for information dissemination that names information at the network layer, arranging individual information items into a context named scoping. Relationships between information items and scopes are represented as a directed acyclic graph of which leaves represent pieces of information and inner nodes represent scopes. Each node in the graph is identified with its full path starting from a root scope. In the context of an IP-over-ICN architecture, the ICN names are simply the IP addresses of the MNs or the fully qualified domain names (FQDNs) used by the end-systems. The IP-over-ICN solution uses Publish/Subscribe (Pub/Sub) semantics for carrying IPv4/v6 datagrams over the ICN network. As described earlier, the INF (referred to as the Rendezvous in the IP-over-ICN embodiment) looks after mapping names (IP address or FQDNs), and the PCE (referred to as the Topology Manager in the IP-over-ICN embodiment) creates the forwarding FIDs. Note that the FID encodes a delivery tree for the communication [
13].
Figure 5 presents an example of macro mobility handover in IP-over-ICN, where MN A moves from Domain 1 to Domain 2 while communicating with the CN that exists in Domain 1.
To support both micro and macro mobility management (referred to in this paper as global mobility management), we propose the namespace shown in
Figure 6, where every MN’s globally unique EUI48 identifier is represented as a scope identifier under the mobility namespace. Any IP address assigned to a MN will be represented as an identifier that is multi-homed to both the mobility root scope (M) and the EUI48 scope specific for that MN. This allows for two publication/subscription possibilities for a specific IP address. The first is without the EUI48 identifier when publishing a request for a destination IP address where the EUI48 identifier is unknown (e.g., /M/IP1), and the second is with the EUI48 identifier when subscribing to the MN’s own IP address where the EUI48 identifier is known (e.g., /M/EUI48/IP1).
We also propose that the Rendezvous (RV) maintains a mobility binding list whose rows represent MN EUI48 identifiers and columns represent corresponding IP addresses learnt by the Rendezvous for that MN. The last IP address in the list is the latest IP address allocated to the MN. These relations are learnt from the subscription messages sent from every MN each time it attaches to an NAP and requests communication through the ICN network.
Figure 7 shows a basic 2 Node initial session establishment scenario with mobility support. In this scenario, MN A and B attach to NAP A and B respectively completing Link Layer Connectivity and IP Address Establishment. NAP A then extracts the source and destination IP addresses from the first packet sent from MN A towards MN B and publishes scope (/M/IP-B 1) on behalf of MN A to request communication with MN B and implicitly subscribes to scope (/M/EUI48-A/IP-A 1), so it can receive any information directed to MN A. On the other hand, NAP B publishes scope (/M/IP-A 1) on behalf of MN B to request communication with MN A and implicitly subscribes to scope (/M/EUI48-B/IP-B 1), so it can receive any information directed to MN B. Upon receiving NAP A and B’s publication and subscription messages, the Rendezvous updates its mobility binding with MN A and B’s EUI48 and corresponding IP address that are extracted from the subscription messages. It also publishes scope /M/EUI48-B/IP-B 1 on behalf of MN A, and scope /M/EUI48-A/IP-A 1 on behalf of MN B, and then matches the corresponding publications and subscriptions for those scopes. The Rendezvous then triggers the Topology Manager (TM) to create new FID’s both ways from MN A to MN B and vise versa. The TM creates and forwards the new FID’s to the MNs, which will then be able to stream data packets between each other.
Figure 8 shows the sequence of messages when MN A changes its point of attachment to a new network domain (domain 2). When MN A de-attaches from NAP A, NAP A then un-publishes scope (/M/IP-B 1) with implicit un-subscription from (/M/EUI48-A/IP-A 1) on behalf of MN A. At this point, the RV keeps the entry in its binding list that has IP-A 1 as the last known IP address for MN A. Supposing MN A then re-attaches to NAP C in domain 2, NAP C publishes Scope (/M/IP-B 1) on behalf of MN A with implicit Subscription to (/M/EUI48-A/IP-A 2), which includes its new IP address (IP-A 2) allocated by the new domain. At this point, the RV updates its binding entry for MN A to include IP-A 2 as the latest IP address and also keeps IP-A 1 in the list in case it receives any publication request towards MN A’s previous address. It also instructs the TM to update the FID’s of MN A and MN B accordingly. This way, session continuity is maintained between the two mobile nodes even when IP addresses change. It is worth noting that, if an IP address that was previously added to the RV binding list is reassigned to a new MN, then it would be removed from the old MN entry and added as a new IP for the new MN, keeping only one instance of the IP address on the binding list at any time.