Network Mobility Management Challenges, Directions, and Solutions: An Architectural Perspective

Abstract

Efficient mobility management solutions are essential to provide users with seamless connectivity and session continuity during movement. However, user mobility was not envisaged as one of the early Internet’s use cases due to the early adoption of destination based routing and the assumption that end-nodes are static. This has become a critical hinder for providing efficient mobility support. This paper presents the challenges, drivers, and solutions that aim to overcome the drawbacks of current mobility management approaches. Furthermore, it introduces a promising solution that builds on emerging path-based forwarding architectures that identify network links rather than end nodes. Delivery path information is stored inside the packet while forwarding is achieved by performing a simple set membership test rather than the current destination-based routing approach. Mobility management in these architectures simply requires partial recomputation of the delivery path allowing for efficient mobility support over an optimal path. Evaluation results show significant cost savings in terms of delivery paths and end-to-end packet delay when using a path forwarding architecture.

1. Introduction

The Internet architecture was built on an Internet Protocol (IP) host-to-host communication paradigm which was sufficient at the time for the early Internet applications and user requirements. However, with the advancements in network and computing technologies, new data-intensive application scenarios have risen, e.g., [1,2]. These scenarios demand rethinking the existing Internet architecture, as patching it with fixes to accommodate the evolving requirements is simply becoming inefficient [3].

Achieving efficient mobility management in existing IP networks has been a challenge because the IP architecture ties the end host address to its location; thereby, a moving host can not naturally maintain a single identifier when attaching to different points in the network. Hence, in the case of mobility, the time it takes the IP routing to recover the forwarding state is far too slow to support seamless mobility handover, especially with the emerging interactive/real-time multimedia applications [4,5]. This has formed a critical obstacle for supporting mobility features, such as seamless handover and session continuity. The problem has generally been circumvented 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 [6,7].

Solutions such as Proxy Mobile IPv6 (PMIPv6) [8] have been standardised by the Internet Engineering Task Force (IETF) to support mobility, and can be optionally supported by cellular networks. In PMIPv6, a central Local Mobility Anchor (LMA) is responsible for maintaining the Mobile Node’s (MN’s) IP address during its movement between Mobile Access Gateways (MAGs). The LMA keeps the MN address binding in a binding table and maintains a tunnel to the MN’s MAG for packet delivery. The MAG is responsible for initiating binding registration on behalf of the MN and detecting the MN’s movement [9].

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 “dog-leg” routing. Distributed Mobility Management (DMM) efforts [10] try to solve the drawbacks above by evolving towards a flatter architecture using distributed anchoring, thereby providing a more efficient way to handle mobile traffic. In these approaches, although the anchor functionality is distributed into the network edges, they still perform traffic tunnelling and anchoring in a localized manner which does not eliminate the traffic overhead imposed to support mobility.

In addition to the limitations above, existing mechanisms either support fast handover but with possible packet loss or lossless handover that may incur a delay. Thus, forcing delay sensitive applications to tolerate packet loss, or on the other hand, loss sensitive applications to tolerate large delays, thereby degrading the users’ Quality of Experience (QoE). This became obvious in [11] where subjective evaluation experiments were performed regarding the video quality perceived by users. During these experiments, the effect of packet loss on videos encoded by High Efficiency Video Coding (HEVC) was quantified. It was shown that beyond $3\%$ loss, there is a detrimental effect on the QoE perceived by the users.

Clean-slate approaches to rebuilding the Internet architecture have been proposed as a solution to the location-dependent end host communication architecture. For example, Information Centric Networking (ICN) research projects, e.g., [12,13], aimed to address the increasing need for an information centric communication architecture that facilitates information dissemination rather than end-host communication. This clean-slate approach to rebuilding the current Internet architecture in spite of its benefits for information dissemination suffers from a number of implementation limitations in terms of protocol stacks and standardizations, stakeholders and vendors of the current internet, end user equipment modification and many other factors [14]. Therefore, recent research efforts such as [15,16] have focused on integration solutions that facilitate ICN information dissemination over legacy IP networks and Software Defined Networking (SDN).

The motivation of this paper is to shed the light on one of the most challenging problems that network operators face, which is mobility management. It discusses the challenges to support mobility in current architectures, and the solutions presented, both in terms of architectural patches and new architectural proposals. The strengths and weaknesses of these solutions are also analysed and presented in addition to their effect on emerging application scenarios. Furthermore, the paper introduces a promising solution that builds on emerging path-based forwarding architectures that identify network links rather than end nodes. This enables packet forwarding without having to depend on end-to-end addressing. Delivery path information is stored inside the packet and used to forward the packet to it’s final destination. Mobility management simply requires partial recomputation of the delivery path allowing for efficient mobility management. The paper also presents evaluation results showing significant cost savings in terms of delivery paths and end-to-end packet delay when using a path forwarding architecture as compared to traditional Anchor Based solutions.

The rest of the paper is structured as follows. Section 2 provides and overview of mobility management in Cellular Networks. Section 3 presents the mobility handover types, while Section 4 elaborates on the most significant handover optimization challenges. Section 5 summarises the current mobility management challenges and limitations. Mobility management in Path Based Forwarding architectures is presented in Section 6 with an evaluation of the benefits of such architectures over Anchor Based solutions presented in Section 7 and Section 8. Finally, the paper is concluded in Section 9.

2. Overview of Mobility Management in Cellular Networks

The IP protocol’s location dependent end host identification mechanism is known to be the main cause of the mobility problems that the Internet faces today. By taking into consideration the continuously increasing number of lightweight computers and smartphones that can be always connected, it can be concluded that the problem of mobility will only grow bigger in the near future [17]. Traditional IP mobility procedures were based on functions residing in both the mobile terminal and the network. With the rapid proliferation of mobile devices and radio access technologies, the next generation of wireless networks is evolving, mostly focusing on solutions that relocate mobility procedures from the mobile device to network components [18]. This approach, known as network-based mobility management, allows conventional IP devices, e.g., devices running standard protocol stacks, to roam freely across wireless stations belonging to the same local domain. This property is appealing from the operator’s viewpoint because it allows service providers to enable mobility support without imposing requirements on the terminal side.

In the design of the Long-Term Evolution system (LTE), the Evolved Packet System (EPS) provides the user with IP connectivity to a Packet Data Network (PDN) for accessing the Internet, as well as for running services such as Voice over IP (VoIP). At a high level, the network is comprised of the core network (EPC) and the access network E-UTRAN. Figure 1 shows the overall network architecture, including the network elements and the standardized interfaces. In order to ensure uninterrupted communication in LTE systems, MN handover procedure should be performed. 3GPP specifies the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) [19] to support mobility in cellular networks by anchoring user data plane traffic at the Serving Gateway (S-GW) and control plane traffic at the Mobility Management Entity (MME) [20]. GTP is an important IP/UDP based protocol used to encapsulate user data when passing through the core network using GTP-U and also carries bearer specific signaling traffic between various core network entities using GTP-C [21].

Handover in cellular networks is performed: (a) over the X2 interface, which provides a direct connection between eNodeBs when both the source and the target eNodeBs are managed by the same mobility management entity (MME), and, (b) over the S1 interface when X2 handover is not possible or when the two eNodeBs fall under different MMEs. When the handover is performed over the X2 interface, downlink packets are delivered over the interface from the serving eNodeB to the target eNodeB during handover execution in order to prevent packet loss [22].

The handover process consists of three phases: handover preparation, execution and completion which are described briefly below [23]:

• During handover preparation, each of the MN, the previous eNodeB, and the new eNodeB prepare for handover execution. The previous eNodeB decides when to trigger a handover based on measurement reports received from the MN that include among other information, indicators of the radio signal strength of the previous and neighbouring cells as received by the MN. The new eNodeB also performs admission control based on QoS information during the preparation phase.
• The execution phase includes the MN de-attachment from the previous eNodeB, attachment to the new eNodeB and the forwarding of buffered and transit data from the previous eNodeB to the new one over the X2 interface (in case of X2 handover).
• Finally, the completion phase includes handover confirmation, path switching (the S-GW switches the path of the downlink data to the new eNodeB), and resource release of the previous eNodeB.

With the advancements in Network Function Virtualization (NFV) and Software Defined Networking (SDN), the new 5G architecture leverages service-based functions at the control plane and user plane of the 5G core. Therefore, as opposed to LTE, user plane traffic is anchored at the User Plane Function (UPF) and control plane traffic at the Access and Mobility Management Function (AMF) [24]. The Handover process is still similar to LTE, and is performed via the Xn interface, which provides a direct connection between base stations (gNBs) or via the N2 interface between the gNB and the AMF if Xn handover is not possible.

5G network optimisation is the focus of many research efforts today, in areas such as cooperative relay [25], IoT [26], and advanced signal processing [27,28].

3. Mobility Handover Types

Handover in mobile networks can be classified into two categories: seamless and lossless [29]. Seamless handover aims to minimize the interruption time during handover while lossless handover aims to eliminate packet loss during the MN’s movement.

3.1. Seamless Handover

Seamless handover is designed for data services that are reasonably tolerant of losses, but less tolerant of delay (e.g., voice services). This approach works as follows: if the source eNodeB operates in seamless handover mode, it sends a ‘HANDOVER REQUEST’ message to the target eNodeB indicating its desire to establish a tunnel between itself and the latter. Upon accepting the request, the target eNodeB sends a ‘HANDOVER REQUEST ACK’ message back to the source eNodeB which includes the tunnel endpoint that is expected to receive the handover traffic. The source eNodeB can then use the established tunnel to start forwarding the data arriving over the source S1 interface towards the indicated tunnel endpoint in parallel with sending the handover trigger to the UE over the radio interface. This forwarded data is then ready to be delivered to the UE as early as possible at the target eNodeB that delivers the packets forwarded over X2 interface before delivering the packets received over the target S1 interface (once the S1 path switch has been performed). The end of handover traffic forwarding is signalled over X2 interface to the target eNodeB by the reception of some special packets which the S-GW has inserted over the source S1 interface just before switching this S1 path; these are then forwarded by the source eNodeB over X2 interface like any other regular packets as shown in Figure 2 [29].

3.2. Lossless Handover

Lossless handover is used mainly for delay-tolerant services such as file downloads where packet loss can result in a severe reduction in the data rate due to the reaction of the Transmission Control Protocol (TCP) that uses congestion control mechanisms. If the source eNodeB operates in lossless handover mode, the same mechanisms for seamless handover described above are used for the handover tunnel establishment. However, the source eNodeB will additionally forward over X2, the user plane downlink packets that it has processed but are still buffered locally because they have not yet been delivered and acknowledged by the UE. These packets are forwarded together with their assigned sequence numbers included in an extension header field. They are sent over X2 prior to the packets arriving from the source S1 path as shown in Figure 3 [29]. The end of forwarding is also handled in the same way as seamless handover since in-sequence packet delivery also applies to lossless handover. In addition, the target eNodeB must ensure that all the packets (including the ones received with sequence number over X2) are delivered in sequence at the target side.

With the handover types described above, delay sensitive applications would inevitably have to tolerate packet loss in order to reach acceptable service delay, i.e., glitches in video transmission. On the other hand, packet loss sensitive applications would have to tolerate excessive delays in order to guarantee data delivery [30]. Consequently, this would restrict network operators ability to meet the strict constraints of emerging applications, i.e., augmented reality, virtual reality, distant surgery, and ultra high definition video, in terms of end-to-end delay, and packet loss in particular during movement (handover).

4. Handover Optimization Challenges

Mobility handover is one of the most performance degrading processes in cellular networks. This led standardization bodies such as third Generation Partnership Project (3GPP) and Internet Engineering Task Force (IETF) to develop various standardized handover mechanisms in order to offer higher QoS to end-users [31]. Handover optimization in cellular networks can be done considering several parameters such as hysteresis margin, Time-To-Trigger (TTT), MN velocity, etc. [32]. In homogeneous networks, where all the cells have the same coverage area and radio configuration parameters, MNs typically use the same set of handover parameters for handing traffic over to a target cell. Differently, in heterogeneous networks, where cells may have different coverage areas and parameters, the consideration of the same set of handover parameters for all the cells and for all the MNs may result in an increase in the handover (HO) failure rate and/or ping-pong handover rate [33]. A ping-pong handover occurs when an MN is handed back and forth between 2 or more cells until settling on the intended candidate cell.

In order to optimize handover success rates, several works [34,35,36] proposed Time-To-Trigger (TTT) adjustment in heterogeneous networks. It was shown that handover failure and ping-pong handover rates are directly influenced by the TTT parameter, MN velocity and the cell coverage size. It was also shown that a handover failure rate of at least $20\%$ is inevitable in high mobility environments, and could reach $60\%$ of total handovers.

Overall, handover failures in cellular networks that occur due to misconfigured handover parameters are classified into three main categories:

• Over-Late Handover Failures: These failures happen when a handover is executed too late. In this case, a connection failure may occur in the source cell, and the MN may try to re-establish the radio link in a neighboring cell controlled by a different eNodeB. This usually results in an HO failure in current cellular networks.
• Over-Early Handover Failures: In this case, a handover is executed too early. In this type of handover failure, the MN may experience a connection failure in the target cell due to fluctuations of the radio signal, and try to re-establish the radio link in the original source cell. However, since the source eNodeB would have deleted all contexts related to that UE when the handover was completed, the re-establishment in the source cell results in a handover failure.
• Handover to an Inappropriate Cell: This handover category shares some similarities with the too-early handover. It usually leads to a connection failure in the target cell, which has not received any context related to that MN.

5. Summary of Mobility Management Challenges and Limitations

With the widespread use of IoT devices and applications such as wearable health monitoring devices, connected vehicles, cargo monitoring systems, and their demand for timely delivery of data during movement; the need arises for efficient mobility management solutions that can help to accommodate the emerging requirements. However, due to the limitations of the IP communication model that binds the end host IP address to its location; mobility support requires introducing a central anchor in the network core that can track the IP address movement from one location to another. Although this approach provides an effective way to facilitate user mobility, it has several shortcomings that can be summarized as follows:

• Non-optimal routes: Forwarding via a centralized anchor often results in non-optimal routes, thereby increasing the traffic delivery cost and end-to-end delay. The problem is manifested, for example, when the MN and Corresponding Node (CN) are in close proximity to each other, or when a Sensory Node (SN) is communicating with a nearby server, i.e., sending sensory readings. The excess cost due to this dog-leg routing approach has been shown in [37] to constitute more than 40 percent of the total traffic cost.
• Session Continuity limitations: During handover using mobility solutions such as PMIPv6, the LMA sends the IP packets of the MN to the original MAG via the tunnel even after the MN has left that MAG. This is because the LMA does not know the latest Care of Address (CoA) of the MN during the handover period until the MN registers with the new MAG. As a result, the dropped IP packets affect the communication between the MN and the CN especially when handovers occur frequently. Advancements of PMIPv6 such as PFMIPv6 [38], aimed to solve this issue by buffering the IP packets during handover and establishing an additional tunnel between the original and new MAG to forward them. However, problems with out-of-order packets and jitter are likely to be experienced.
• Lack of scalability: Tunnel setup and mobility context management for every MN through a central anchor usually introduces scalability limitations due to the increase in resource requirements. With the rapid increase in connected things, this becomes even more problematic. Specifically, with the expanding IoT network scenarios such as mobile IoT cache stores, and mobile IoT cloudlets [39]. In addition, the pressing need for efficient multicast solutions to facilitate application scenarios such as controlling groups of building-wide appliances (i.e., lights, doors, etc), or group subscriptions to live video streaming, increases the need for alternative data delivery and mobility management approach. Following the same tunneling approach, preparing multiple destinations for multicast, would mean establishing (and tearing down) a number of tunnels that is equal to the number of multicast destinations. From the above, it is obvious that while the tunnelling cost is bearable when preparing a single destination, it is simply infeasible for multiple destinations [40,41].
• Diversions in current communication models: Current mobility management solutions are designed toward session-based communication models, where the aim is to preserve a communication session opened between two MNs, or an MN and a server during movement. Although this is still a requirement today for many communication scenarios, there is a clear shift from this model in current IoT applications. IoT applications today are more data/content-oriented rather than session-oriented. For example, the timely and reliable delivery of sensory data is more important than session maintenance in wearable health monitors, or on-ship cargo temperature sensors. Therefore, new mobility management solutions are required, that can efficiently accommodate both session-based and content based-scenarios.
• Diversions in current architectural trends: IoT is evolving towards a flatter and more distributed network architecture with higher edge computing capabilities. This evolution comes to fulfill the needs and requirements of the emerging application scenarios being promised by 5G networks. However, centralized mobility management does not support this evolution which enables more sophisticated mobility solutions such as AI techniques to make smart decisions on resource allocation and hence improve user experience. For example, recent efforts such as [42] proposed removing routing protocols from future wireless networks and substituting them with ML approaches for intelligent traffic control.

6. Mobility Management in Path Based Forwarding Architectures

The IP protocol’s location-dependent end host identification mechanism has led many research efforts to focus on new solutions to improve network and mobility management with lower traffic cost and faster handover.

Software Defined Networking (SDN) brings new possibilities by using software-based controllers that can communicate with underlying hardware infrastructure to forward traffic on a network. There are three main components in a typical SDN architecture, namely: Applications that communicate resource requests and network information, Controllers that act on information from applications to make packet forwarding decisions, and Networking devices that are instructed by the controller on packet destination. SDN also uses OpenFlow, a programmable network protocol that is used for communication between the SDN controller and the Networking devices to forward packets. The main advantage of SDN is its agility and the ease of network management and change implementation [43,44]. A widely used approach in SDN Mobility management involves testing mobile flow entries against matching rule fields and finding a correct output action through every OpenFlow switch along the path. This has high costs in mobile flow management. As a result, most of the proposed SDN architectures in wireless networks cannot be directly applied to large-scale networks due to this reason [45].

The Line Speed Publish/Subscribe Inter-Networking solution (LIPSIN) [46] has introduced a novel forwarding fabric that is based on identifying network links rather than end nodes, which enables packet forwarding without having to depend on end-to-end addressing. The solution uses Bloom filters to encode forwarding information into a packet header, i.e., encode all link identifiers of the delivery path into a Bloom filter, and place it into the packet header. Forwarding is achieved by testing whether an outgoing link is a member of the delivery path link identifiers encoded into the Bloom filter. Solutions such as Stateless Multicast Switching in Software Defined Networks [47], the Publish-Subscribe Internet Technology (PURSUIT) [12,48] and IP-over-ICN [37] use the forwarding fabric described above and therefore 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. This approach provides the basis for more sophisticated mobility management that simply requires (partial) re-computation of a path upon MN movement [37,49,50].

In a path forwarding architecture [17], there are four types of entities that take part in any mobility scenario as shown in Figure 4: an MN, a network attachment point (NAP), a Path Computation Element (PCE), and a Forwarding Element (FW). The MN connects wirelessly to a NAP that provides interconnection with a wider distribution network. The PCE determines a path of communication through the network on behalf of an 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 numbers) such that there is some inter-relationship between the identities. The mobile nodes and NAPs may use this information naming entity to store and obtain relationships between identities. 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. In IP-over-ICN, the first link connecting the user device 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 this architecture, IP simply becomes a service enabled through the forwarding core and IP addresses are translated into identifiers used directly for routing.

7. Why Path Forwarding Architectures for Network Mobility Management?

Anchor-based mobility solutions use a centralized Local Mobility Anchor (LMA) on both the data and control plane to facilitate network-based mobility support. This approach, on the one hand, helps to reduce signalling costs in high mobility rate environments while increasing traffic and packet delivery cost within the network’s core. Using this approach, all traffic sent to and from a mobile node is driven through a local mobility anchor (LMA) that keeps track of the location of the mobile node and routes the traffic accordingly. This approach leads to using non optimal routes for packet delivery, thereby increasing the traffic overhead and end-to-end delay. Path Forwarding-based solutions on the other hand only require a central anchor point for mobility signalling and delivery path creation, while the actual payload is delivered from source to destination through the shortest path without any anchoring.

To show the overhead caused by traffic anchoring in a simple way, we use the example in Figure 5. As shown in the example, for a packet sent from a mobile node (MN) to reach a corresponding node (CN) in Figure 5a it crosses two routers (hops) in a Path Forwarding Network while it crosses 4 hops in an Anchor Based Network to support network controlled mobility. Thus, the packet delivery cost using Path Forwarding solutions is half the cost of Anchor Based solutions using this topology. The gain shown in this example has proven to be topology dependant as can be seen in Figure 5b. Where the number of hops crossed in a Path Forwarding Network is one hop versus three hops in an Anchor Based Network. Therefore packet delivery cost using Path Forwarding solutions is a third of the cost of Anchor Based solutions due to the fact that more links have been added to the same setup. An extended evaluation of network topology effect on router-level internet performance has been shown in [51] and verified that many different graphs having the same distribution of node degree, may be considered opposites from the viewpoint of network engineering and result in widely varying end user bandwidths and Router utilization distributions.

8. Evaluation of Anchoring Overhead

An evaluation to show the anchoring overhead and its effect on the total hop count and packet delay is presented in Figure 6 and Figure 7 respectively. Random geometric networks ranging from 10 up to 100 nodes have been simulated with an average connection degree of 4 neighbors for every node. Every simulation experiment was run for 3600 s and repeated 20 times with results collated after reaching a steady state. It can be seen from Figure 6 that Path Forwarding solutions (without LMA) always outperform Anchor Based Solutions (with LMA) in terms of the total number of hops required to support network-based mobility management with an improvement factor of at least 1.4 due to the sub-optimal triangular routing mechanism of Anchor Based solutions. The difference in the number of hops tends to increase with network size reaching an improvement factor of 2 for Path Forwarding solutions, i.e., double the number of hops needed to support mobility in Anchor Based solutions.

Figure 7 shows the average, maximum, and minimum end-to-end packet delay for anchor-based and path forwarding solutions. The figure shows the measured delays in networks of sizes 10, 50, and 100 nodes respectively. From Figure 7, it is evident that path forwarding solutions incur lower delays of about 24 milliseconds on average, compared to 46 milliseconds for anchor-based solutions. It can also be seen that the maximum incurred delay can reach more than $1.2$ s for anchor-based solutions compared to only 30 ms for path forwarding solutions in a network size of 100 nodes. This huge difference is due to the sub-optimal triangular routing mechanism of Anchor Based solutions which increases the end-to-end delivery paths. It can therefore be concluded that path forwarding solutions can significantly improve the packet delay performance, and hence, provide a better quality of QoS for the end-user.

9. Conclusions

Anchorless path-based forwarding solutions can offer improved mobility services without necessarily incurring any changes to the end-user equipment that uses existing IP protocol stacks and connectivity. The presented architectures rely purely on path information for the end-to-end forwarding of packets instead of relying on host address-based communication. Path information is stored in the forwarded packet (using Bloom filters) which helps to deliver a packet traversing the network to the final destination. Decoupling the end-system IP address from the path-based data forwarding eliminates the need for anchoring traffic through the network core which allows flexible path calculation and service provisioning. The evaluation results presented show that significant cost savings can be harvested using such Path Forwarding architectures.