# Decentralized Vehicular Mobility Management Study for 5G Identifier/Locator Split Networks

Authors: Gaofeng Hong; Bin Yang; Wei Su; Qili Wen; Xindi Hou; Haoru Li
Journal: Wireless Communications and Mobile Computing
 (2022)

---

## Abstract

The identifier/locator split (ILS) architectures are highly promising to reduce the signaling latency of frequent handovers in fifth generation (5G) networks, while decentralized vehicular mobility management holds greater potential than the traditional centralized management to enhance the critical performance of highly dynamic and dense cell networks. By carefully exploiting ILS, dual connectivity, and multiaccess edge computing (MEC) concepts, this paper proposes a decentralized vehicular mobility management mechanism in the network with dense 5G Non-Standalone deployment. Under such a mechanism, we design an ILS-based local anchor handover management architecture to reduce signaling costs and handover latency. Specifically, we propose a quality of service- (QoS-) based handover decision algorithm using a long short-term memory- (LSTM-) based trajectory prediction method to obtain the cell sojourn time of connected vehicles (CVs) in predefined QoS coverage areas. Combining a built-in dynamic handover trigger condition, this algorithm can ensure a flexible load balance as well as low handover times. Extensive simulation results are presented to verify the effectiveness of the proposed mechanism in improving network performance.


---

## Body

## 1. Introduction

The ILS architectures, which decouple the IP address semantics into two types of roles, namely, user equipment (UE), access identifiers (AIDs), and routing identifier (RIDs), have been identified as a promising paradigm for the 5G and beyond wireless networks [1]. Such architectures can significantly reduce the cost of frequent handovers in highly dynamic networks [2]. For instance, because of the dense gNB deployment and fast moving vehicles, handovers occur frequently in the emerging 5G vehicular networks [3–5], which can cause heavy handover signaling load in traditional network architectures with the overloading of IP address semantics. Fortunately, ILS architectures have the potential to guarantee vehicular communications without occurring outage [6]. However, vehicular communications based on the ILS architecture still face some fundamental challenges in the 5G dense cell scenarios, like mapping management and real-time handover decisions [7]. Therefore, it is critical to explore a novel vehicular mobility management mechanism for improving the quality of the vehicular communications.Existing ILS architectures, such as lisp mobile node (LISP-MN) [8], Host Identity Protocol (HIP) [9], MILSA [10], MobilityFirst [11], and Smart Identifier Network (SINET) [12], provide various optimization schemes of the mobility management. Relevant schemes can be classified into two categories, namely, mobility signaling [13, 14] and mapping system update efficiency [15, 16]. The former aims at simplifying the handover signaling interaction to support a seamless roaming, while the latter is to boost the efficiency of mapping update to avoid the outdated identifier-to-locator mapping during a new handover.These works mainly focus on the centralized mobility management system with relatively low handover frequency and simple handover decision. Recently, some initial works focus on the highly dynamic 5G ILS networks [6, 17], which are intended to provide reliable communications of high-speed railways.It is notable that all above works demonstrate the potentials of ILS architectures in reducing the mobility management costs. However, these results cannot be directly applied to the 5G vehicular networks. On one hand, the frequent handovers in such networks can bring heavy update load to the centralized mapping system via the domain gateway (GW), which may lead to a single point of failure once if the requirements of vehicular communications increase. On the other hand, the moving routes of vehicles are more complex than high-speed trains, and thus the handover decisions proposed in high-speed railway communications cannot be directly applied to the complex target access network selection of the vehicular communications. Furthermore, the handover decision algorithms have also been proven to play vitally important roles in reducing the number of handovers and network load imbalance among the access entities [18]. Specifically, lacking efficient handover decision algorithms could not only degrade the Quality of Service (QoS) but also negate the benefits of mobility management using the ILS architecture in the 5G vehicular networks.By now, relevant research efforts have illustrated the superiority of decentralized mobility management in the traditional centralized cellular networks [19–24]. In addition, various handover decision algorithms in such networks are also proposed in [25–28] (please see Related Works of Section 2 for details). A fundamental issue is how to explore a distributed ILS mapping management scheme with an optimal handover decision algorithm, which fully considers UE’s requirements and network state in the dense 5G scenario. However, this issue has not been well addressed by now. Motivated by this observation, the paper presents a decentralized 5G vehicular mobility management architecture, which is based on the 5G Non-Standalone (NSA) dual connectivity (DC) networking [29–31] and the decentralized management capacity of the MEC technology [32]. It aims to proactively detect, predict, and perform fast handovers by fully exploiting the advantages of the ILS architecture in the 5G vehicular networks. To ensure the performance of the proposed mobility management architecture, we carefully address an efficient handover decision algorithm based on the movement characteristic of vehicles and the requirements of on-board services, which can largely reduce the overhead of mobility management and the unnecessary handover times as well as increasing the utilization of network resource.This paper extends our previous work [33], and the main contributions can be summarized as follows:
(i)
We propose a Local Mobility Anchor- (LMA-) based handover management architecture in the Evolved Packet Core- (EPC-) based 5G NSA networking mode reusing the current LTE facilities. DC technology in such an architecture, the LTE master eNB (MeNB), which serves as an LMA, takes charge of the control-plane (C-plane) procedures and is also a backup for the user-plane (U-plane) transmission of the 5G secondary gNB (SgNB). Remarkably, each MeMB is attached to an MEC server, which can process handover context parameter, manage local mapping information, and execute the predefined handover decision algorithm in a distributed manner. We further give the collection and management methods of the context information and the fast handover procedures for intra-MeNB and inter-MeNB handovers(ii)
For the intra-MeNB handover, we further propose a vehicular handover decision algorithm with the aim of reducing the number of SgNB handovers, balancing SgNB load and satisfying different networks requirements of CV services. In this algorithm, we design a novel QoS coverage conversion method to determine the QoS boundary of candidate gNBs including the specific service requirement and the real-time network load. Based on this method, we develop an LSTM-based trajectory prediction model, which is used to determine a vital decision variable, i.e., the sojourn time of a vehicle residing in the QoS boundary of each candidate gNB(iii)
Based on the predicted sojourn time and the real-time network status, we redefine the trigger condition of the intra-MeNB handover as a dynamic Time-to-Trigger (TTT) value, which enhances the robustness of mobility management in highly dynamic handover context due to the heterogeneity of 5G gNBs(iv)
Extensive simulation results are presented to validate the prediction accuracy of the trajectory prediction model in our proposed mechanism and also to conduct a comparison between our proposed mechanism and a classic traditional oneThe rest of the paper is organized as follows. Section2 presents the related works. Section 3 introduces our concerned network model. In Section 4, we propose the LMA-based handover management architecture and the relative handover procedures under this architecture. Section 5 further gives the QoS-based handover decision algorithm. Extensive simulation results are provided in Section 6. Finally, Section 7 concludes this paper. The abbreviations used in this paper are provided in Table 1.Table 1
Key abbreviations.
AbbreviationDescriptionILSIdentifier/locator splitAIDAccess identifierRIDRouting identifierGAIDGlobal access identifierLAIDLocal access identifierQoSQuality of serviceGWDomain gatewayCVConnected vehicleMeNBMaster eNodeB (LTE base station)SgNBSecondary gNodeB (5G base station)EPCEvolved Packet CoreDCDual connectivityLMALocal Mobility AnchorLSDLocation service domainNSANonstandalone networkingC-planeControl-plane (used for the interactive control signaling between the user and the network)U-planeUser-plane (used for data traffic transmission of users)MECMultiaccess edge computing technologyLSTMLong short-term memory (a variant of recurrent neural network)DMMDistributed Mobility ManagementRSURoad side unitOBUOn-board unitCAMCooperative awareness messageRSRPReference signal receiving powerRRCRadio Resource ControlTNTarget nodeRLFRadio link failureTTTTime-to-Trigger (the handover is initiated only if the triggering requirement is fulfilled for a certain time interval, which is called TTT)


## 2. Related Works

### 2.1. Distributed Mobility Management Mechanisms

The Distributed Mobility Management (DMM) mechanisms [34, 35] distribute the control and data functions among several infrastructures located at the edge of the network, instead of relying on a single central server in traditional centralized network. The DMM mechanisms are proposed in distributed ILS-based mobile networks to relieve the signaling loads and handover delays [19, 20]. The potentials of such mechanisms are further shown in cellular networks [21]. The work in [22] proposes an efficient local mobility management mechanism in a dense cell scenario. Under the mechanism, once if a handover happens, the target cell can establish a local path based on the X2 interface with the serving cell without sending a handover request to the core network. Similarly, two finer granularity location management mechanisms are proposed in dense cell networks [23], where the UE’s location in a cell or a tracking area is registered to an LMA selected by the surrounding cells, and then the signaling of location update is transmitted using the X2 interface for reducing the overhead at the core network. However, the efficiency of such DMM schemes probably depends on the network service duration, compared to the UE sojourn time within the coverage of the cells [24]. The DMM mechanisms also show their limitations in their performance when the UE is in a high-speed state and the cell sojourn time becomes shorter. Therefore, another critical issue is to design an appropriate handover decision algorithm for improving the performance of DMM mechanisms.


### 2.2. Handover Decision Algorithms

The work in [36] illustrates that a proper handover decision algorithm can significantly mitigate the negative impact of UE’s mobility on the QoS. The impact of user trajectories on the final handover decision is analyzed by deriving the closed-form expressions for the relative mobility model and the handover rate [25]. The authors in [26] propose a mobility state estimation algorithm, with which UEs are divided into different classes based on their velocity, and each class is associated with a handover trigger condition to minimize their handover failure rate. These results of [25, 26] are still not well applied to practical scenarios, where the actual vehicular trajectory is more complicated such that an accurate cell sojourn time is difficult to be obtained. In [27], a trajectory prediction algorithm based on deep learning has been used in handover decisions of heterogeneous vehicular networks. The predication algorithm can effectively improve the accuracy of mobility prediction and reduce unnecessary handovers. Meanwhile, the Cell Range Expansion technique in [28] is utilized to appropriately enlarge the small cell coverage to control the number of UEs access in a specific cell, which relieve the imbalance network load brought by frequent handovers.


## 2.1. Distributed Mobility Management Mechanisms

The Distributed Mobility Management (DMM) mechanisms [34, 35] distribute the control and data functions among several infrastructures located at the edge of the network, instead of relying on a single central server in traditional centralized network. The DMM mechanisms are proposed in distributed ILS-based mobile networks to relieve the signaling loads and handover delays [19, 20]. The potentials of such mechanisms are further shown in cellular networks [21]. The work in [22] proposes an efficient local mobility management mechanism in a dense cell scenario. Under the mechanism, once if a handover happens, the target cell can establish a local path based on the X2 interface with the serving cell without sending a handover request to the core network. Similarly, two finer granularity location management mechanisms are proposed in dense cell networks [23], where the UE’s location in a cell or a tracking area is registered to an LMA selected by the surrounding cells, and then the signaling of location update is transmitted using the X2 interface for reducing the overhead at the core network. However, the efficiency of such DMM schemes probably depends on the network service duration, compared to the UE sojourn time within the coverage of the cells [24]. The DMM mechanisms also show their limitations in their performance when the UE is in a high-speed state and the cell sojourn time becomes shorter. Therefore, another critical issue is to design an appropriate handover decision algorithm for improving the performance of DMM mechanisms.


## 2.2. Handover Decision Algorithms

The work in [36] illustrates that a proper handover decision algorithm can significantly mitigate the negative impact of UE’s mobility on the QoS. The impact of user trajectories on the final handover decision is analyzed by deriving the closed-form expressions for the relative mobility model and the handover rate [25]. The authors in [26] propose a mobility state estimation algorithm, with which UEs are divided into different classes based on their velocity, and each class is associated with a handover trigger condition to minimize their handover failure rate. These results of [25, 26] are still not well applied to practical scenarios, where the actual vehicular trajectory is more complicated such that an accurate cell sojourn time is difficult to be obtained. In [27], a trajectory prediction algorithm based on deep learning has been used in handover decisions of heterogeneous vehicular networks. The predication algorithm can effectively improve the accuracy of mobility prediction and reduce unnecessary handovers. Meanwhile, the Cell Range Expansion technique in [28] is utilized to appropriately enlarge the small cell coverage to control the number of UEs access in a specific cell, which relieve the imbalance network load brought by frequent handovers.


## 3. Network Architecture

As shown in Figure1, we present an ILS-based 5G network architecture consisting of five main communication entities, namely, LTE MeNB, 5G secondary gNB (SgNB), MEC server, GW, road side unit (RSU), and connected vehicle (CV), which is based on the EPC-based 5G NSA DC networking. The functions of these entities are introduced as follows:Figure 1
ILS-based LTE-5G dual connectivity network architecture.MeNB: it can provide radio coverage over a larger area, which is responsible for bothC-plane and U-plane transmission, working as a mobility anchor for the SgNBs. Here, the U-plane transmission is used only when no SgNB is available, and the control region of a MeNB is also called a location service domain (LSD)SgNB: it can cover a relatively small area, which is responsible for user plane transmission, enhancing system capacity and providing high data transmission rate for vehiclesMEC server: it is placed near MeNBs and serves as a distributed local mapping server, which is responsible for handover context information management, executing the optimal network selection algorithm to make handover decisionsGW: in addition to acting as a gateway between MeNB and the Internet, it manages mapping information between CVs and each LSDRSU: it obtains the driving status information of vehicles within its coverage area, and then sends the information to MEC servers through fiber lineCV: it is equipped with multiple types of communication modules. The on-board unit (OBU) periodically broadcasts Cooperative Awareness Messages (CAMs) [37] such that RSU can receive CV’s real-time motion status through the Cellular-Vehicle-to-Everything (C-V2X) technology. Meanwhile, it maintains uninterrupted communication with cellular base stations and requests varieties of vehicular services from the remote server through cellular network connectionThe CV in this network architecture connects to MeNB and SgNB simultaneously based on the DC technology. The MeNB acts as a mobility anchor forC-plane transmission and a backup for U-plane transmission. The SgNB does not exchange control signals with the core network but enhances U-plane transmission. In this paper, we assume that the MEC server is merged with an MeNB, which provides extra storage and computing capacity of the MeNB for the subsequent mobility management. The combination of an MeNB and an MEC server is regarded as a mobility anchor.


## 4. Decentralized LMA-Based Handover Management Architecture

A decentralized LMA-based handover management architecture is proposed in this section. Figure2 illustrates the relative functions and behaviors under this architecture consisting of the obtaining and management of the handover context parameters, the hierarchical mapping system, the optimal handover decision algorithm, and the handover executing procedure (intra-MeNB or inter-MeNB). The details of the optimal handover decision algorithm will be depicted in the next section.Figure 2
The LMA-based handover management architecture.


### 4.1. Obtaining and Management of Context Parameters

To make optimal handover decision, it is essential to obtain the context parameters like SgNB coverage size, SgNB traffic loads, and vehicle motion trajectory. The MEC server associated with the MeNB is responsible for managing the context parameters of the SgNBs and CVs under the coverage of the MeNB. These parameters can be divided into the following three categories:


#### 4.1.1. Cooperative Awareness Message

There is the driving status of the CVvk in the CAM defined by the ETSI standard [37]. The CV periodically transmits CAMs to RSUs. To reduce the transmission cost, each CAM only contains PDU header, basic container, and HF container. When a RSU receives the CAM, it will synchronize the driving status information with the time stamp to the specified MEC server through fiber lines.


#### 4.1.2. Measurement Report

The Radio Resource Control (RRC) connection can be established between the CV and the MeNB. The MeNB provides measurement configuration to the CV through RRC connection reconfiguration [38]. The measurement configuration includes candidate SgNBs, measurement parameters, and measurement period. Here, the measurement parameters consist of reference signal receiving quality, current received data transmission rate, and service request data rate. The CV measures the link quality of the nearby networks according to the measurement configuration in the RRC connection reconfiguration message and periodically uploads measurement reports to the MeNB. The MeNB will synchronize the measurement report to the MEC server.


#### 4.1.3. Interaction between MeNBs and SgNBs

The MeNB, which serves as a mobility anchor, maintains the context information of its SgNBs, in terms of the maximum transmission power, residual available bandwidth, the number of current connected terminals, etc. These information will be periodically synchronized to the MEC server through C-plane transmission, with negligible transmission delay.Based on the first two categories of monitoring methods, we use a CV context setCvkt to synchronize the driving state and the on-board service network requirement of vk in the time slot t. The driving state consists of velocity, historical position sequence, acceleration, etc.A context information table (CIT) between CVs and candidate SgNBs can be built and updated on the MEC server, as depicted in Table2.Table 2
Context information.
CVCV context setSgNB1...SgNBIv1Cv1trsrp1,1...rsrp1,Iv2Cv2trsrp2,1...rsrp2,I...............vKCvktrsrpK,1...rsrpK,I


### 4.2. Identifier-Locator Mapping System

In the proposed architecture, each CV is identified by a global AID (GAID) and a local AID (LAID). The GAID is unique and represents a CV’s identity in the global DNS system. The LAID only exists when a CV is attached to a SgNB. The dynamic LAID is highly related to the RID of the SgNB associated with the CV. Meanwhile, each SgNB and MeMB have an RID serving as a global service location inside the core network and can be globally routing.Each GW has a set ofGAIDCV-to-RIDMeNB mapping cache entries, which is used to map each CV to its MeNB LSD.Besides, each MEC server on the MeNB side has three sets of mapping cache entries:GAIDCV-to-RIDSgNB, RIDSgNB-to-RIDMeNB, and GAIDTN-to-RIDMeNB. The first entry maps the identifier of the CV to its connected SgNB service area, and the second entry maps SgNB global location to its local anchor, while the last entry is used to map the identifier of the target communication node to the current MeNB LSD through the core network.


### 4.3. Intra-MeNB Handover Procedure

When an intra-MeNB handover (SgNB-to-SgNB) is triggered by the MEC server, the CV will prepare an air interface to turn on for the target SgNB and continuously monitor the link status. Meanwhile, CV sends a Map Select Request message to the attached MeNB to notify its movement, which contains itsGAIDTN list and old and new LAIDs. MeNB configures a new LAID for the CV and starts a fast intra handover by sending Map Forwarding Request message to the target SgNB, which applies the access admission for the CV. The target SgNB sends a Map Forwarding Response to MeNB, and then the previous transmitting data is forwarded to the target SgNB. In this process, the MeNB acts as a backup U-plane transmission to CV, keeping a zero interruption data forwarding. Then, the MeNB responds to CV with a Map Select Response message, and CV will attach to the target SgNB. When the buffered packets on the target SgNB are delivered to CV, the MeNB stops the U-plane transmission. After the completion of the handover, the relevant mapping information will be updated on the MEC server, the UE context information on the former SgNB will be released, and the route will be optimized from CV to TN. Figure 3 gives the complete process of intra-MeNB handover signaling.Figure 3
Intra-MeNB SgNB handover.It is obvious that the handover latency of intra-MeNB handover is possible to be zero. Since the MeNB plays the role of backup data plane transmission in the process of SgNB switching, a seamless handover can be ensured.


### 4.4. Inter-MeNB Handover Procedure

When a CV moves towards to a new MeNB control region (a new LSD) and satisfies a handover trigger condition, it will send a Map Select Request message to the source MeNB with its GAID. The source MeNB then sends a Map Update message through the overlay network to the target MeNB, which contains the CV’s relevantGAIDTN list and its RID so that the target MeNB will update its GAIDTN-to-RIDMeNB cache. Then, the target MeNB configures a new LAID for the CV and sends a Map Update Response message to the source MeNB. The source MeNB and the target MeNB send MAP Forwarding Request message to the source SgNB and the target SgNB, respectively. After that, the source SgNB sets up a data forwarding path with the target SgNB through sending a Map Forwarding Request message. If the target SgNB promises the access admission, the target SgNB will response Map Forwarding Response message to the source SgNB and the target MeNB. Meanwhile, the source SgNB sends a Map Forwarding Response message to the source MeNB, and then the previous transmitting data is forwarded to the target SgNB. At the moment, the source MeNB sends a Map Select Response message to the CV, and the CV will establish a connection with the target MeNB and then attach to the target SgNB. The buffering packets on the target SgNB will be forwarded to the CV once it is attached to itself. After the completion of the handover, the relevant mapping information will be updated on the MEC server in the new LSD, and the GAIDCV-to-RIDMeNB mapping cache entries in the GW will also be updated. The UE context information on the former SgNB and MeNB will be released, and the route will be optimized from CV to TN. Figure 4 gives the complete process of inter-MeNB handover signaling.Figure 4
Inter-MeNB handover.Notice that the above handover procedures assume the existence of available SgNBs. If at a given time the coverage holes of SgNB exists, the U-plane transmission on the MeNB will immediately start. The originalGAIDCV-to-RIDSgNB mapping entry will be deleted, and the CV will discard its LAID. Once an available SgNB meets the CV’s connection requirements according to the algorithm described in the next section, the CV will reconfigure its LAID and performs a U-plane switch to the target SgNB. Figure 5 shows the signaling interactions of the fast U-plane switch procedures.Figure 5
U-plane fast switch procedure.


## 4.1. Obtaining and Management of Context Parameters

To make optimal handover decision, it is essential to obtain the context parameters like SgNB coverage size, SgNB traffic loads, and vehicle motion trajectory. The MEC server associated with the MeNB is responsible for managing the context parameters of the SgNBs and CVs under the coverage of the MeNB. These parameters can be divided into the following three categories:


### 4.1.1. Cooperative Awareness Message

There is the driving status of the CVvk in the CAM defined by the ETSI standard [37]. The CV periodically transmits CAMs to RSUs. To reduce the transmission cost, each CAM only contains PDU header, basic container, and HF container. When a RSU receives the CAM, it will synchronize the driving status information with the time stamp to the specified MEC server through fiber lines.


### 4.1.2. Measurement Report

The Radio Resource Control (RRC) connection can be established between the CV and the MeNB. The MeNB provides measurement configuration to the CV through RRC connection reconfiguration [38]. The measurement configuration includes candidate SgNBs, measurement parameters, and measurement period. Here, the measurement parameters consist of reference signal receiving quality, current received data transmission rate, and service request data rate. The CV measures the link quality of the nearby networks according to the measurement configuration in the RRC connection reconfiguration message and periodically uploads measurement reports to the MeNB. The MeNB will synchronize the measurement report to the MEC server.


### 4.1.3. Interaction between MeNBs and SgNBs

The MeNB, which serves as a mobility anchor, maintains the context information of its SgNBs, in terms of the maximum transmission power, residual available bandwidth, the number of current connected terminals, etc. These information will be periodically synchronized to the MEC server through C-plane transmission, with negligible transmission delay.Based on the first two categories of monitoring methods, we use a CV context setCvkt to synchronize the driving state and the on-board service network requirement of vk in the time slot t. The driving state consists of velocity, historical position sequence, acceleration, etc.A context information table (CIT) between CVs and candidate SgNBs can be built and updated on the MEC server, as depicted in Table2.Table 2
Context information.
CVCV context setSgNB1...SgNBIv1Cv1trsrp1,1...rsrp1,Iv2Cv2trsrp2,1...rsrp2,I...............vKCvktrsrpK,1...rsrpK,I


## 4.1.1. Cooperative Awareness Message

There is the driving status of the CVvk in the CAM defined by the ETSI standard [37]. The CV periodically transmits CAMs to RSUs. To reduce the transmission cost, each CAM only contains PDU header, basic container, and HF container. When a RSU receives the CAM, it will synchronize the driving status information with the time stamp to the specified MEC server through fiber lines.


## 4.1.2. Measurement Report

The Radio Resource Control (RRC) connection can be established between the CV and the MeNB. The MeNB provides measurement configuration to the CV through RRC connection reconfiguration [38]. The measurement configuration includes candidate SgNBs, measurement parameters, and measurement period. Here, the measurement parameters consist of reference signal receiving quality, current received data transmission rate, and service request data rate. The CV measures the link quality of the nearby networks according to the measurement configuration in the RRC connection reconfiguration message and periodically uploads measurement reports to the MeNB. The MeNB will synchronize the measurement report to the MEC server.


## 4.1.3. Interaction between MeNBs and SgNBs

The MeNB, which serves as a mobility anchor, maintains the context information of its SgNBs, in terms of the maximum transmission power, residual available bandwidth, the number of current connected terminals, etc. These information will be periodically synchronized to the MEC server through C-plane transmission, with negligible transmission delay.Based on the first two categories of monitoring methods, we use a CV context setCvkt to synchronize the driving state and the on-board service network requirement of vk in the time slot t. The driving state consists of velocity, historical position sequence, acceleration, etc.A context information table (CIT) between CVs and candidate SgNBs can be built and updated on the MEC server, as depicted in Table2.Table 2
Context information.
CVCV context setSgNB1...SgNBIv1Cv1trsrp1,1...rsrp1,Iv2Cv2trsrp2,1...rsrp2,I...............vKCvktrsrpK,1...rsrpK,I


## 4.2. Identifier-Locator Mapping System

In the proposed architecture, each CV is identified by a global AID (GAID) and a local AID (LAID). The GAID is unique and represents a CV’s identity in the global DNS system. The LAID only exists when a CV is attached to a SgNB. The dynamic LAID is highly related to the RID of the SgNB associated with the CV. Meanwhile, each SgNB and MeMB have an RID serving as a global service location inside the core network and can be globally routing.Each GW has a set ofGAIDCV-to-RIDMeNB mapping cache entries, which is used to map each CV to its MeNB LSD.Besides, each MEC server on the MeNB side has three sets of mapping cache entries:GAIDCV-to-RIDSgNB, RIDSgNB-to-RIDMeNB, and GAIDTN-to-RIDMeNB. The first entry maps the identifier of the CV to its connected SgNB service area, and the second entry maps SgNB global location to its local anchor, while the last entry is used to map the identifier of the target communication node to the current MeNB LSD through the core network.


## 4.3. Intra-MeNB Handover Procedure

When an intra-MeNB handover (SgNB-to-SgNB) is triggered by the MEC server, the CV will prepare an air interface to turn on for the target SgNB and continuously monitor the link status. Meanwhile, CV sends a Map Select Request message to the attached MeNB to notify its movement, which contains itsGAIDTN list and old and new LAIDs. MeNB configures a new LAID for the CV and starts a fast intra handover by sending Map Forwarding Request message to the target SgNB, which applies the access admission for the CV. The target SgNB sends a Map Forwarding Response to MeNB, and then the previous transmitting data is forwarded to the target SgNB. In this process, the MeNB acts as a backup U-plane transmission to CV, keeping a zero interruption data forwarding. Then, the MeNB responds to CV with a Map Select Response message, and CV will attach to the target SgNB. When the buffered packets on the target SgNB are delivered to CV, the MeNB stops the U-plane transmission. After the completion of the handover, the relevant mapping information will be updated on the MEC server, the UE context information on the former SgNB will be released, and the route will be optimized from CV to TN. Figure 3 gives the complete process of intra-MeNB handover signaling.Figure 3
Intra-MeNB SgNB handover.It is obvious that the handover latency of intra-MeNB handover is possible to be zero. Since the MeNB plays the role of backup data plane transmission in the process of SgNB switching, a seamless handover can be ensured.


## 4.4. Inter-MeNB Handover Procedure

When a CV moves towards to a new MeNB control region (a new LSD) and satisfies a handover trigger condition, it will send a Map Select Request message to the source MeNB with its GAID. The source MeNB then sends a Map Update message through the overlay network to the target MeNB, which contains the CV’s relevantGAIDTN list and its RID so that the target MeNB will update its GAIDTN-to-RIDMeNB cache. Then, the target MeNB configures a new LAID for the CV and sends a Map Update Response message to the source MeNB. The source MeNB and the target MeNB send MAP Forwarding Request message to the source SgNB and the target SgNB, respectively. After that, the source SgNB sets up a data forwarding path with the target SgNB through sending a Map Forwarding Request message. If the target SgNB promises the access admission, the target SgNB will response Map Forwarding Response message to the source SgNB and the target MeNB. Meanwhile, the source SgNB sends a Map Forwarding Response message to the source MeNB, and then the previous transmitting data is forwarded to the target SgNB. At the moment, the source MeNB sends a Map Select Response message to the CV, and the CV will establish a connection with the target MeNB and then attach to the target SgNB. The buffering packets on the target SgNB will be forwarded to the CV once it is attached to itself. After the completion of the handover, the relevant mapping information will be updated on the MEC server in the new LSD, and the GAIDCV-to-RIDMeNB mapping cache entries in the GW will also be updated. The UE context information on the former SgNB and MeNB will be released, and the route will be optimized from CV to TN. Figure 4 gives the complete process of inter-MeNB handover signaling.Figure 4
Inter-MeNB handover.Notice that the above handover procedures assume the existence of available SgNBs. If at a given time the coverage holes of SgNB exists, the U-plane transmission on the MeNB will immediately start. The originalGAIDCV-to-RIDSgNB mapping entry will be deleted, and the CV will discard its LAID. Once an available SgNB meets the CV’s connection requirements according to the algorithm described in the next section, the CV will reconfigure its LAID and performs a U-plane switch to the target SgNB. Figure 5 shows the signaling interactions of the fast U-plane switch procedures.Figure 5
U-plane fast switch procedure.


## 5. Handover Decision Algorithm

To further improve the handover performance, we propose a QoS-based network selection method to select the most suitable SgNB for the CV in this section. The algorithm jointly considers network balance and the network requirements of CV, which mainly includes two parts: the SgNB QoS-boundary conversion and the LSTM-based sojourn time prediction. Moreover, we redefine a dynamic handover trigger condition of the intra-MeNB handover, so as to improve the robustness of the intrahandover under the dense network scenario. The proposed handover selection algorithm will be executed on the MEC server based on the handover context information.


### 5.1. SgNB QoS-Boundary Conversion

We define a QoS circular coverage area centered at the serving/candidate SgNB. As for a specific CV, the SgNB can provide a satisfactory data transmission rate within its QoS circular area. We call the boundary of the circle QoS boundary. The derivation process of the SgNB QoS boundary of a CV jointly considers the real-time load of the SgNB and the network requirement of the served CV, which is shown as follows:Suppose that each SgNBni has K UEs attached to it, the data requested rates of these UEs are D1,D2,⋯,DK. The network load of ni can be precisely defined as
(1)Lni=∑n=1K1Dn.The effective maximum throughput ofni is
(2)Tpni=1Lni+1/Dnimax,where Dnimax is the maximum data transmit rate that ni can provide at the moment. Dnimax can be predicted based on the relative measurement report parameters (RSRP and RSRQ) [39]. When a CV vk requests for a data rate Dvkreq, a ni will be added to the candidate network set F if the condition Dvkreq<Tpni is satisfied.When a CV is in the coverage of a specific SgNBni, its received power is expressed as
(3)PkiRX=PkiTX−PkiLOSS−FM+G,where FM and PkiLOSS represent the fading margin and the path loss, respectively. G represents the antenna gain between ni and vk. According to the log-distance path loss model under the urban environment, PkiLOSS can be calculated as
(4)PkiLOSS=λlog10r+βlog10fc+γ,where λ, β, and γ are related to the surrounding road environment, fc is the carrier frequency of the SgNB, and r represents the distance between ni and vk.We use the average signal powerPkiRavg received by vk over a period of time to represent PkiRX, which makes the QoS boundary of ni more representative. PkiRavg can be deduced based on the following Shannon’s theorem:
(5)Dnimax=Wlog21+PkiRavgN⇔PkiRavg=N2Dnimax/W−1,where W and N represent the channel bandwidth and the noise power, respectively. We use the radius rniQoS of the QoS circular coverage area to replace the parameter r in equation (4), and the value of rniQoS can be obtained by combining (3)–(5):
(6)rniQoS=10PkiTX−βlog10fc−γ−FM+G−PkiRavg/λ.


### 5.2. LSTM-Based Vehicular Sojourn Time Prediction

The historical motion of a CV can be utilized to predict its future driving trends in future period to time. We can apply the LSTM neural network to learn features among CV’s historical trajectories and predict the CV’s future trajectory [40]. Based on the predicted trajectory, we further obtain the sojourn time of the CV within the coverage of each candidate network. We summarize the architecture of a normal LSTM cell and the calculation of each parameter in Figure 6.Figure 6
LSTM cell architecture.In Figure6, ft, it, and ot represent the forget, input, and output gates, respectively. The function of each gate are described in [40]. bf,bi,bo,bc are the corresponding variable biases of ht−1,xt in ft, it, ot, and C~t. Wf,Wi,Wo,Wc are the corresponding weights of ht−1,xt in ft, it, ot, and C~t. Figure 7 illustrates the architecture of the proposed trajectory prediction model. The input of the prediction architecture is composed of 5 dimensions, i.e., the longitude and latitude coordinates xvkt,yvkt, the driving angle αvkt, the velocity vvkt, and the acceleration avkt of the vehicle. The final input set is represented as a vector Xvkn given by
(7)Xvkn=xvkt,yvkt,αvkt,vvkt,avkt,n=t−N+1,⋯,t,where N denotes the length of the historical input time sequence. Note that the actual position sequence of the vehicle is transformed to Frenet coordinates in our prediction model for improving the adaptability of the training data and the accuracy of the prediction.Figure 7
The architecture of the LSTM-based trajectory prediction model.In this architecture, a fully connected (FC) layer made up of 256 cells can transforms the input data into 256 dimensional equal to the LSTM cell dimension of the following LSTM stack. Each dimension has a strong relationship with the input data. Specifically, according to the feedback network update parameters, we can determine the input dimensions which are more relevant to the predicted trajectory trend after the input dimension conversion.The following LSTM stack consists of two LSTM layers each of which has 256 LSTM cells. The output vector from the first LSTM layer is an input of the second LSTM layer. The function of the LSTM stack is to extract higher-level features of the input time series. The output of the LSTM stack is combined by the FC stack with two FC layers in order to reduce the data dimension. Meanwhile, the input sequences are also fed to a 64-dimensional FC layer, bypassing the above network connections. The outputs of this FC layer and the previous FC stack are directly fed to the output stack to obtain the final predicted future states. This kind of design can establish a closer correlation between the current input states and the prediction output sequences, which boosts the training speed and improves the prediction accuracy of the model.The outputYvkn of the vehicular trajectory prediction model is shown as follows:
(8)Yvkn=xvkt,yvkt,n=t+1,⋯,t+M.Finally, the Frenet coordinates of the predicted trajectory will be converted back to the actual coordinates.Based on the QoS boundary coverage of each candidate SgNB and the LSTM-based vehicular sojourn time prediction model, we can obtain the sojourn timetnivk of a CV vk in the QoS boundary coverage of the candidate SgNB ni. For the network access entities of our proposed network architecture in Figure 8, green dotted circles represent the QoS coverage range of SgNBs.Figure 8
Network access entities of our proposed network architecture.Assuming ABCD is a predicted future driving track ofvk, point B and point D are two predicted positions within the QoS coverage of SgNB3 that are closest to the QoS boundary. Thus, the sojourn time tn3vk of the vk in SgNB3 can be determined as tDvk−tBvk, where tBvk and tDvk are the time when the vk reaches the positions B and D.


### 5.3. Dynamic Time Threshold Condition

Since the heterogeneity of 5G gNBs may lead to highly dynamic handover context, we now redefine the trigger condition of the intra-MeNB handover based on the SgNB RSRP measurement reports, the predefined time threshold (TTT), and the QoS coverage area sojourn timetnivk.A SeNB in the candidate setF can build a link with the CV under each of the following two conditions that the SeNB has a better RSRP than the serving one, and it has also a higher sojourn time than the predefined threshold Tth. If both conditions hold, the MEC server checks for Δ seconds and then triggers the intra MeNB handover. Notice that the SgNB with the highest tnivk in the set F can be chosen as the original target SgNB. During the Δ, if the RSRP of the serving SgNB becomes the highest or tnivk<Tth, the handover will be cancelled. The Δ will be reset based on equation (9) when a new handover condition holds. rsrpc is the RSRP value of the serving SgNB. rsrpmax and rsrpmin represent the maximum and minimum RSRP values in the candidate network set F, respectively. Δmax and Δmin are static values based on historical experience. Then, we have
(9)Δ=Δmax−rsrpc−rsrpminrsrpmax−rsrpminΔmax−Δmin.TheΔ value will become smaller when the difference in RSRP between the serving SgNB and the target SgNB becomes larger. It is also worth noting that, when a CV detects a radio link failure (RLF) [41] with the serving SgNB and there happens to be no suitable candidate SgNB in the set F, the terminal maintains the C/U-plane transmission with the MeNB. Therefore, the impact of an SgNB on RLF is moderate.


### 5.4. Algorithm Complexity

We analyze the complexity of our proposed handover decision algorithm in two parts.Firstly, we deduce the complexity of training the LSTM-based vehicular sojourn prediction model. As for an LSTM layer, its training complexity is based on its input dimensionI and output dimension U [42], which can be presented as O4IU+U2+U. Meanwhile, the training complexity of the fully connected layer is OIU, so that the training complexity of our prediction model can be presented as OqIq1+8q1qL+qL2+qL+∑m=24qmqm+1+q5qO, where qm (m∈1,2,3,4,5) is the cell number of each fully connected layer in our model, respectively. qL is the cell number of each LSTM layer. qI and qO are the numbers of input and output cells. Considering that the prediction model has already completed its training process before being applied, it will not bring extra computing cost during the handover decision process.Moreover, we analyze the complexity of the decision process. Considering that our algorithm selects the gNB with the largest sojourn time from the candidate network setF, the complexity of each check can be easily deduced as OFlog2F, where F is the cardinality of set F.


## 5.1. SgNB QoS-Boundary Conversion

We define a QoS circular coverage area centered at the serving/candidate SgNB. As for a specific CV, the SgNB can provide a satisfactory data transmission rate within its QoS circular area. We call the boundary of the circle QoS boundary. The derivation process of the SgNB QoS boundary of a CV jointly considers the real-time load of the SgNB and the network requirement of the served CV, which is shown as follows:Suppose that each SgNBni has K UEs attached to it, the data requested rates of these UEs are D1,D2,⋯,DK. The network load of ni can be precisely defined as
(1)Lni=∑n=1K1Dn.The effective maximum throughput ofni is
(2)Tpni=1Lni+1/Dnimax,where Dnimax is the maximum data transmit rate that ni can provide at the moment. Dnimax can be predicted based on the relative measurement report parameters (RSRP and RSRQ) [39]. When a CV vk requests for a data rate Dvkreq, a ni will be added to the candidate network set F if the condition Dvkreq<Tpni is satisfied.When a CV is in the coverage of a specific SgNBni, its received power is expressed as
(3)PkiRX=PkiTX−PkiLOSS−FM+G,where FM and PkiLOSS represent the fading margin and the path loss, respectively. G represents the antenna gain between ni and vk. According to the log-distance path loss model under the urban environment, PkiLOSS can be calculated as
(4)PkiLOSS=λlog10r+βlog10fc+γ,where λ, β, and γ are related to the surrounding road environment, fc is the carrier frequency of the SgNB, and r represents the distance between ni and vk.We use the average signal powerPkiRavg received by vk over a period of time to represent PkiRX, which makes the QoS boundary of ni more representative. PkiRavg can be deduced based on the following Shannon’s theorem:
(5)Dnimax=Wlog21+PkiRavgN⇔PkiRavg=N2Dnimax/W−1,where W and N represent the channel bandwidth and the noise power, respectively. We use the radius rniQoS of the QoS circular coverage area to replace the parameter r in equation (4), and the value of rniQoS can be obtained by combining (3)–(5):
(6)rniQoS=10PkiTX−βlog10fc−γ−FM+G−PkiRavg/λ.


## 5.2. LSTM-Based Vehicular Sojourn Time Prediction

The historical motion of a CV can be utilized to predict its future driving trends in future period to time. We can apply the LSTM neural network to learn features among CV’s historical trajectories and predict the CV’s future trajectory [40]. Based on the predicted trajectory, we further obtain the sojourn time of the CV within the coverage of each candidate network. We summarize the architecture of a normal LSTM cell and the calculation of each parameter in Figure 6.Figure 6
LSTM cell architecture.In Figure6, ft, it, and ot represent the forget, input, and output gates, respectively. The function of each gate are described in [40]. bf,bi,bo,bc are the corresponding variable biases of ht−1,xt in ft, it, ot, and C~t. Wf,Wi,Wo,Wc are the corresponding weights of ht−1,xt in ft, it, ot, and C~t. Figure 7 illustrates the architecture of the proposed trajectory prediction model. The input of the prediction architecture is composed of 5 dimensions, i.e., the longitude and latitude coordinates xvkt,yvkt, the driving angle αvkt, the velocity vvkt, and the acceleration avkt of the vehicle. The final input set is represented as a vector Xvkn given by
(7)Xvkn=xvkt,yvkt,αvkt,vvkt,avkt,n=t−N+1,⋯,t,where N denotes the length of the historical input time sequence. Note that the actual position sequence of the vehicle is transformed to Frenet coordinates in our prediction model for improving the adaptability of the training data and the accuracy of the prediction.Figure 7
The architecture of the LSTM-based trajectory prediction model.In this architecture, a fully connected (FC) layer made up of 256 cells can transforms the input data into 256 dimensional equal to the LSTM cell dimension of the following LSTM stack. Each dimension has a strong relationship with the input data. Specifically, according to the feedback network update parameters, we can determine the input dimensions which are more relevant to the predicted trajectory trend after the input dimension conversion.The following LSTM stack consists of two LSTM layers each of which has 256 LSTM cells. The output vector from the first LSTM layer is an input of the second LSTM layer. The function of the LSTM stack is to extract higher-level features of the input time series. The output of the LSTM stack is combined by the FC stack with two FC layers in order to reduce the data dimension. Meanwhile, the input sequences are also fed to a 64-dimensional FC layer, bypassing the above network connections. The outputs of this FC layer and the previous FC stack are directly fed to the output stack to obtain the final predicted future states. This kind of design can establish a closer correlation between the current input states and the prediction output sequences, which boosts the training speed and improves the prediction accuracy of the model.The outputYvkn of the vehicular trajectory prediction model is shown as follows:
(8)Yvkn=xvkt,yvkt,n=t+1,⋯,t+M.Finally, the Frenet coordinates of the predicted trajectory will be converted back to the actual coordinates.Based on the QoS boundary coverage of each candidate SgNB and the LSTM-based vehicular sojourn time prediction model, we can obtain the sojourn timetnivk of a CV vk in the QoS boundary coverage of the candidate SgNB ni. For the network access entities of our proposed network architecture in Figure 8, green dotted circles represent the QoS coverage range of SgNBs.Figure 8
Network access entities of our proposed network architecture.Assuming ABCD is a predicted future driving track ofvk, point B and point D are two predicted positions within the QoS coverage of SgNB3 that are closest to the QoS boundary. Thus, the sojourn time tn3vk of the vk in SgNB3 can be determined as tDvk−tBvk, where tBvk and tDvk are the time when the vk reaches the positions B and D.


## 5.3. Dynamic Time Threshold Condition

Since the heterogeneity of 5G gNBs may lead to highly dynamic handover context, we now redefine the trigger condition of the intra-MeNB handover based on the SgNB RSRP measurement reports, the predefined time threshold (TTT), and the QoS coverage area sojourn timetnivk.A SeNB in the candidate setF can build a link with the CV under each of the following two conditions that the SeNB has a better RSRP than the serving one, and it has also a higher sojourn time than the predefined threshold Tth. If both conditions hold, the MEC server checks for Δ seconds and then triggers the intra MeNB handover. Notice that the SgNB with the highest tnivk in the set F can be chosen as the original target SgNB. During the Δ, if the RSRP of the serving SgNB becomes the highest or tnivk<Tth, the handover will be cancelled. The Δ will be reset based on equation (9) when a new handover condition holds. rsrpc is the RSRP value of the serving SgNB. rsrpmax and rsrpmin represent the maximum and minimum RSRP values in the candidate network set F, respectively. Δmax and Δmin are static values based on historical experience. Then, we have
(9)Δ=Δmax−rsrpc−rsrpminrsrpmax−rsrpminΔmax−Δmin.TheΔ value will become smaller when the difference in RSRP between the serving SgNB and the target SgNB becomes larger. It is also worth noting that, when a CV detects a radio link failure (RLF) [41] with the serving SgNB and there happens to be no suitable candidate SgNB in the set F, the terminal maintains the C/U-plane transmission with the MeNB. Therefore, the impact of an SgNB on RLF is moderate.


## 5.4. Algorithm Complexity

We analyze the complexity of our proposed handover decision algorithm in two parts.Firstly, we deduce the complexity of training the LSTM-based vehicular sojourn prediction model. As for an LSTM layer, its training complexity is based on its input dimensionI and output dimension U [42], which can be presented as O4IU+U2+U. Meanwhile, the training complexity of the fully connected layer is OIU, so that the training complexity of our prediction model can be presented as OqIq1+8q1qL+qL2+qL+∑m=24qmqm+1+q5qO, where qm (m∈1,2,3,4,5) is the cell number of each fully connected layer in our model, respectively. qL is the cell number of each LSTM layer. qI and qO are the numbers of input and output cells. Considering that the prediction model has already completed its training process before being applied, it will not bring extra computing cost during the handover decision process.Moreover, we analyze the complexity of the decision process. Considering that our algorithm selects the gNB with the largest sojourn time from the candidate network setF, the complexity of each check can be easily deduced as OFlog2F, where F is the cardinality of set F.


## 6. Simulation Results

This section first validates our proposed model and then conducts the performance evaluation study.


### 6.1. Model Validation

In this paper, we use the NGSIM data set [43] to collect relevant vehicle trajectory in US101 sections for the training and testing of our proposed trajectory prediction model. We first randomly select 70% of data (i.e., 4269 trajectories) for training, 20% of data for validation (i.e., 1220 trajectories), and the remaining 10% of data (i.e., 610 trajectories) for testing. The sampling frequency of the dataset is 1 Hz. The model training is executed on GPU using the Pytorch with a batch size of 128. We have trained the model for 4 epochs, and the whole dataset has been processed for 20 times, which results in 80 effective epochs. The prediction accuracy of the model is measured by the root mean square error (RMSE) between the predicted value and the actual expected value of the position. The variation of RSME loss with training epoches is shown in Figure 9, and the RSME of our model in different prediction horizons is provided in Table 3.Figure 9
RSME versus training epoches of the proposed model.Table 3
RMSE values of the proposed model.
Prediction horizon1 s2 s3 s4 s5 s6 s7 s8 s9 s10sRSME in latitude0.0410.0720.0790.0840.0880.0960.110.120.170.31RSME in longitude0.650.860.991.101.151.251.381.662.144.02Total RSME0.660.861.001.111.151.261.381.672.154.03When a CV is traveling at an average velocity of 30 km/h, the average predicted sojourn time error is about 0.486 s in a 10 s prediction horizon. Since the actual sojourn time of the CV is about 24 s in a SgNB with coverage radius of 150 m, the prediction error of the sojourn time is negligible.


### 6.2. Handover Performance Evaluation

We build the network simulation environment on the NS-3 simulator [44]. A real road traffic environment around the US101 section is abstracted by SUMO [45] as shown in Figure 10. LTE MeNBs and 5G SgNBs with different configuration parameters are deployed in this area. The SgNBs are wired to their MeNB which act as an LMA. The MeNBs are wired to the GW. The CVs’ trajectories are randomly generated by SUMO based on the abstracted road traffic environment, and we set the value of the velocity as multiple constant values. The values of the main simulation parameters are shown in Table 4. We now define some fundamental performance metrics as follows:
(i)
Handover latency: it is defined as the average time duration from the time when a CV and the network system needs to update the relevant mapping information to the time when the CV receives the packet from the target access network entity(ii)
Handover times: it is defined as the average time over handover events happening for a certain simulation time(iii)
Packet loss rate: It can be expressed asXtot−Xrec/Xtot, where Xtot and Xrec are the number of packets sent by the TNs and that received by the CVs during a session, respectively(iv)
Mobility management load: it is the average number of mobility management packets processed at the relevant control entity per minute under the scenario of CVs’ mobility(v)
gNB utilization rate: it is the average ratio of the time that the CV is connected to the serving SgNB (Tused) to the time that the SgNB is available for CV to attach (Tusable), which can be expressed as Tused/TusableFigure 10
Real urban road scenario abstracted by SUMO.Table 4
Simulation parameters.
ParametersValuesNumber of base stations22 (3 MeNB, 19 SgNB)Number of GWs1Transmitting power of base stations23~46 dBmMaximum coverage radius of MeNBs500 mMaximum coverage radius of SgNBs150 mOperating frequency of base stationsMeNB: 1.85 GHz, SgNB: 700 MHzCV velocity (vvk){30, 40, 50} km/hCoefficient of the path loss modelλ=16.7,β=18.2,γ=38.77Fading margin (FM)8 dBAntenna gain (G)13 dBΔmax120 msΔmin15 msTransfer protocolUDPMTU1300 byteCIT updating cycle20 msThe cost of each mobility management on the GW24SgNB to MeNB linkDelay: 5 msLink type: point to pointMeNB to GW linkDelay: 10 msLink type: point to pointIntra-SgNB to SgNB linkDelay: 5 msLink type: point to pointSimulation time300 sSimulation area1000m∗900mTo illustrate the efficiency of our proposed mechanism, we conduct comparison study with the ILS mobility management mechanism (LISP-MN) [26] using the A2A4 [38] handover algorithm.


#### 6.2.1. Handover Latency

As shown in Figure11, we explore the average handover latency under two types of mechanisms with vvk=40km/h. Since the vehicular velocity is usually required to be no more than 40 km/h in the urban traffic scenario, the vehicular velocity 40 km/h is a typical example here. It can be observed from Figure 11 that our proposed mechanism has the lowest handover latency in comparison with the LISP-MN DC and LISP-MN Hard handover. This can be explained as follows. Firstly, the decentralized mapping system of our proposed mechanism significantly reduces the mapping update latency caused by the backbone transmission of the control signaling. Meanwhile, the DC technology provides the backup transmission of MeNB, which can reduce the link interruption time caused by SgNB handover. This can also explains the reason why the handover latency of LISP-MN DC is lower than that of LISP-MN Hard handover as shown in Figure 11.Figure 11
Handover latency under different handover types.Our proposed mechanism reduces the intra-MeNB handover latency up to 57.1 percent and the inter-MeNB handover latency up to 61.9 percent compared with the LISP-MN mechanism.


#### 6.2.2. Handover Times

As shown in Figure12, we examine how total network handover times vary with vvk during the simulation process. We can see from Figure 12 that for each fixed vvk, total network handover times under our proposed mechanism are lower than the times under the traditional handover algorithm (A2A4). This is because the A2A4 handover algorithm only adopts the signal strength as the handover decision condition, while the CV mobility characteristic can result in unnecessary handovers, which largely affects the future network access. Our proposed mechanism not only guarantees the link quality but also consider the effect of cell sojourn time on the handover times. The SgNB with the maximum sojourn time is selected as the target access entity to minimize the possibility of unnecessary handover. We can also observe from Figure 12 that a larger vvk leads to higher handover times due to the fact that the higher velocity leads to a shorter cell sojourn time and thus higher frequency of handovers. However, our proposed mechanism can curb the increase of the handover frequency compared with the traditional mechanism.Figure 12
Total handover times under differentvvk.


#### 6.2.3. Packet Loss Rate

As shown in Figure13, we investigate how the packet loss rate varies with different packet arrival rates λ. We can see from the Figure 13 that for each fixed vvk, the packet loss rate under our proposed mechanism is lower than that under the traditional LISP-MN mechanism. This is due to the following reason. The decentralized mapping system in the proposed mechanism brings relative low update latency, which reduces the session recovery time and relieves the packet loss during the handover procedure. Meanwhile, the addition of backup data forwarding and fast handover signaling methods in the proposed mechanism further improves the performance of the packet loss rate.Figure 13
Packet loss rate versusλ under different vvk.Due to the relevant optimization, our proposed mechanism reduces the packet loss rate up to 51 percent in an extreme situation (λ=100packets/s, vvk=50km/h) compared with the LISP-MN mechanism.


#### 6.2.4. Mobility Management Load

As shown in Figure14, we explore how the total mobility management load on the GW varies with vvk. We can see from Figure 14 that for each fixed vvk, the total mobility management load on the GW under our proposed mechanism is lower than that under the traditional LISP-MN mechanism. It is because under the decentralized mapping update strategy, the intra-MeNB mapping update overhead has been offloaded to the local MEC server. We can also observe from Figure 14 that our proposed mechanism can alleviate the load caused by the velocity and the number of CVs. Specifically, the total mobility management load on the GW can reduced up to 83.5 percent in a high mobility and mass CV scenario with the setting of vvk=50km/h and CVnumber=200 compared with the LISP-MN mechanism.Figure 14
Total mobility management load on the GW versusvvk.


#### 6.2.5. SgNB Utilization Rate

Finally, we explore how the average SgNB utilization rate varies with data requested rate as shown in Figure15. It can be seen from Figure 15 that for each fixed vvk, the average SgNB utilization rate under our proposed mechanism is higher than that under the traditional LISP-MN mechanism. This is because the proposed mechanism selects the SgNB with the longest sojourn time as the target SgNB and ignores the SgNBs which do not meet the load requirements. A further observation from Figure 15 indicates that both the increases of data requested rate and velocity will reduce the SgNB utilization. We know that the CV will gain the access admission to the target SgNB when it has sufficient network resources. The high requested rate can increase the occupation of the network resource and cause the access reject during the handover process, which leads to a decreased Tused. Meanwhile, the increase of velocity can also reduce the cell sojourn time of the CV, which also results in a decrease of Tused.Figure 15
Average SgNB utilization rate versus data request rate.


## 6.1. Model Validation

In this paper, we use the NGSIM data set [43] to collect relevant vehicle trajectory in US101 sections for the training and testing of our proposed trajectory prediction model. We first randomly select 70% of data (i.e., 4269 trajectories) for training, 20% of data for validation (i.e., 1220 trajectories), and the remaining 10% of data (i.e., 610 trajectories) for testing. The sampling frequency of the dataset is 1 Hz. The model training is executed on GPU using the Pytorch with a batch size of 128. We have trained the model for 4 epochs, and the whole dataset has been processed for 20 times, which results in 80 effective epochs. The prediction accuracy of the model is measured by the root mean square error (RMSE) between the predicted value and the actual expected value of the position. The variation of RSME loss with training epoches is shown in Figure 9, and the RSME of our model in different prediction horizons is provided in Table 3.Figure 9
RSME versus training epoches of the proposed model.Table 3
RMSE values of the proposed model.
Prediction horizon1 s2 s3 s4 s5 s6 s7 s8 s9 s10sRSME in latitude0.0410.0720.0790.0840.0880.0960.110.120.170.31RSME in longitude0.650.860.991.101.151.251.381.662.144.02Total RSME0.660.861.001.111.151.261.381.672.154.03When a CV is traveling at an average velocity of 30 km/h, the average predicted sojourn time error is about 0.486 s in a 10 s prediction horizon. Since the actual sojourn time of the CV is about 24 s in a SgNB with coverage radius of 150 m, the prediction error of the sojourn time is negligible.


## 6.2. Handover Performance Evaluation

We build the network simulation environment on the NS-3 simulator [44]. A real road traffic environment around the US101 section is abstracted by SUMO [45] as shown in Figure 10. LTE MeNBs and 5G SgNBs with different configuration parameters are deployed in this area. The SgNBs are wired to their MeNB which act as an LMA. The MeNBs are wired to the GW. The CVs’ trajectories are randomly generated by SUMO based on the abstracted road traffic environment, and we set the value of the velocity as multiple constant values. The values of the main simulation parameters are shown in Table 4. We now define some fundamental performance metrics as follows:
(i)
Handover latency: it is defined as the average time duration from the time when a CV and the network system needs to update the relevant mapping information to the time when the CV receives the packet from the target access network entity(ii)
Handover times: it is defined as the average time over handover events happening for a certain simulation time(iii)
Packet loss rate: It can be expressed asXtot−Xrec/Xtot, where Xtot and Xrec are the number of packets sent by the TNs and that received by the CVs during a session, respectively(iv)
Mobility management load: it is the average number of mobility management packets processed at the relevant control entity per minute under the scenario of CVs’ mobility(v)
gNB utilization rate: it is the average ratio of the time that the CV is connected to the serving SgNB (Tused) to the time that the SgNB is available for CV to attach (Tusable), which can be expressed as Tused/TusableFigure 10
Real urban road scenario abstracted by SUMO.Table 4
Simulation parameters.
ParametersValuesNumber of base stations22 (3 MeNB, 19 SgNB)Number of GWs1Transmitting power of base stations23~46 dBmMaximum coverage radius of MeNBs500 mMaximum coverage radius of SgNBs150 mOperating frequency of base stationsMeNB: 1.85 GHz, SgNB: 700 MHzCV velocity (vvk){30, 40, 50} km/hCoefficient of the path loss modelλ=16.7,β=18.2,γ=38.77Fading margin (FM)8 dBAntenna gain (G)13 dBΔmax120 msΔmin15 msTransfer protocolUDPMTU1300 byteCIT updating cycle20 msThe cost of each mobility management on the GW24SgNB to MeNB linkDelay: 5 msLink type: point to pointMeNB to GW linkDelay: 10 msLink type: point to pointIntra-SgNB to SgNB linkDelay: 5 msLink type: point to pointSimulation time300 sSimulation area1000m∗900mTo illustrate the efficiency of our proposed mechanism, we conduct comparison study with the ILS mobility management mechanism (LISP-MN) [26] using the A2A4 [38] handover algorithm.


### 6.2.1. Handover Latency

As shown in Figure11, we explore the average handover latency under two types of mechanisms with vvk=40km/h. Since the vehicular velocity is usually required to be no more than 40 km/h in the urban traffic scenario, the vehicular velocity 40 km/h is a typical example here. It can be observed from Figure 11 that our proposed mechanism has the lowest handover latency in comparison with the LISP-MN DC and LISP-MN Hard handover. This can be explained as follows. Firstly, the decentralized mapping system of our proposed mechanism significantly reduces the mapping update latency caused by the backbone transmission of the control signaling. Meanwhile, the DC technology provides the backup transmission of MeNB, which can reduce the link interruption time caused by SgNB handover. This can also explains the reason why the handover latency of LISP-MN DC is lower than that of LISP-MN Hard handover as shown in Figure 11.Figure 11
Handover latency under different handover types.Our proposed mechanism reduces the intra-MeNB handover latency up to 57.1 percent and the inter-MeNB handover latency up to 61.9 percent compared with the LISP-MN mechanism.


### 6.2.2. Handover Times

As shown in Figure12, we examine how total network handover times vary with vvk during the simulation process. We can see from Figure 12 that for each fixed vvk, total network handover times under our proposed mechanism are lower than the times under the traditional handover algorithm (A2A4). This is because the A2A4 handover algorithm only adopts the signal strength as the handover decision condition, while the CV mobility characteristic can result in unnecessary handovers, which largely affects the future network access. Our proposed mechanism not only guarantees the link quality but also consider the effect of cell sojourn time on the handover times. The SgNB with the maximum sojourn time is selected as the target access entity to minimize the possibility of unnecessary handover. We can also observe from Figure 12 that a larger vvk leads to higher handover times due to the fact that the higher velocity leads to a shorter cell sojourn time and thus higher frequency of handovers. However, our proposed mechanism can curb the increase of the handover frequency compared with the traditional mechanism.Figure 12
Total handover times under differentvvk.


### 6.2.3. Packet Loss Rate

As shown in Figure13, we investigate how the packet loss rate varies with different packet arrival rates λ. We can see from the Figure 13 that for each fixed vvk, the packet loss rate under our proposed mechanism is lower than that under the traditional LISP-MN mechanism. This is due to the following reason. The decentralized mapping system in the proposed mechanism brings relative low update latency, which reduces the session recovery time and relieves the packet loss during the handover procedure. Meanwhile, the addition of backup data forwarding and fast handover signaling methods in the proposed mechanism further improves the performance of the packet loss rate.Figure 13
Packet loss rate versusλ under different vvk.Due to the relevant optimization, our proposed mechanism reduces the packet loss rate up to 51 percent in an extreme situation (λ=100packets/s, vvk=50km/h) compared with the LISP-MN mechanism.


### 6.2.4. Mobility Management Load

As shown in Figure14, we explore how the total mobility management load on the GW varies with vvk. We can see from Figure 14 that for each fixed vvk, the total mobility management load on the GW under our proposed mechanism is lower than that under the traditional LISP-MN mechanism. It is because under the decentralized mapping update strategy, the intra-MeNB mapping update overhead has been offloaded to the local MEC server. We can also observe from Figure 14 that our proposed mechanism can alleviate the load caused by the velocity and the number of CVs. Specifically, the total mobility management load on the GW can reduced up to 83.5 percent in a high mobility and mass CV scenario with the setting of vvk=50km/h and CVnumber=200 compared with the LISP-MN mechanism.Figure 14
Total mobility management load on the GW versusvvk.


### 6.2.5. SgNB Utilization Rate

Finally, we explore how the average SgNB utilization rate varies with data requested rate as shown in Figure15. It can be seen from Figure 15 that for each fixed vvk, the average SgNB utilization rate under our proposed mechanism is higher than that under the traditional LISP-MN mechanism. This is because the proposed mechanism selects the SgNB with the longest sojourn time as the target SgNB and ignores the SgNBs which do not meet the load requirements. A further observation from Figure 15 indicates that both the increases of data requested rate and velocity will reduce the SgNB utilization. We know that the CV will gain the access admission to the target SgNB when it has sufficient network resources. The high requested rate can increase the occupation of the network resource and cause the access reject during the handover process, which leads to a decreased Tused. Meanwhile, the increase of velocity can also reduce the cell sojourn time of the CV, which also results in a decrease of Tused.Figure 15
Average SgNB utilization rate versus data request rate.


## 6.2.1. Handover Latency

As shown in Figure11, we explore the average handover latency under two types of mechanisms with vvk=40km/h. Since the vehicular velocity is usually required to be no more than 40 km/h in the urban traffic scenario, the vehicular velocity 40 km/h is a typical example here. It can be observed from Figure 11 that our proposed mechanism has the lowest handover latency in comparison with the LISP-MN DC and LISP-MN Hard handover. This can be explained as follows. Firstly, the decentralized mapping system of our proposed mechanism significantly reduces the mapping update latency caused by the backbone transmission of the control signaling. Meanwhile, the DC technology provides the backup transmission of MeNB, which can reduce the link interruption time caused by SgNB handover. This can also explains the reason why the handover latency of LISP-MN DC is lower than that of LISP-MN Hard handover as shown in Figure 11.Figure 11
Handover latency under different handover types.Our proposed mechanism reduces the intra-MeNB handover latency up to 57.1 percent and the inter-MeNB handover latency up to 61.9 percent compared with the LISP-MN mechanism.


## 6.2.2. Handover Times

As shown in Figure12, we examine how total network handover times vary with vvk during the simulation process. We can see from Figure 12 that for each fixed vvk, total network handover times under our proposed mechanism are lower than the times under the traditional handover algorithm (A2A4). This is because the A2A4 handover algorithm only adopts the signal strength as the handover decision condition, while the CV mobility characteristic can result in unnecessary handovers, which largely affects the future network access. Our proposed mechanism not only guarantees the link quality but also consider the effect of cell sojourn time on the handover times. The SgNB with the maximum sojourn time is selected as the target access entity to minimize the possibility of unnecessary handover. We can also observe from Figure 12 that a larger vvk leads to higher handover times due to the fact that the higher velocity leads to a shorter cell sojourn time and thus higher frequency of handovers. However, our proposed mechanism can curb the increase of the handover frequency compared with the traditional mechanism.Figure 12
Total handover times under differentvvk.


## 6.2.3. Packet Loss Rate

As shown in Figure13, we investigate how the packet loss rate varies with different packet arrival rates λ. We can see from the Figure 13 that for each fixed vvk, the packet loss rate under our proposed mechanism is lower than that under the traditional LISP-MN mechanism. This is due to the following reason. The decentralized mapping system in the proposed mechanism brings relative low update latency, which reduces the session recovery time and relieves the packet loss during the handover procedure. Meanwhile, the addition of backup data forwarding and fast handover signaling methods in the proposed mechanism further improves the performance of the packet loss rate.Figure 13
Packet loss rate versusλ under different vvk.Due to the relevant optimization, our proposed mechanism reduces the packet loss rate up to 51 percent in an extreme situation (λ=100packets/s, vvk=50km/h) compared with the LISP-MN mechanism.


## 6.2.4. Mobility Management Load

As shown in Figure14, we explore how the total mobility management load on the GW varies with vvk. We can see from Figure 14 that for each fixed vvk, the total mobility management load on the GW under our proposed mechanism is lower than that under the traditional LISP-MN mechanism. It is because under the decentralized mapping update strategy, the intra-MeNB mapping update overhead has been offloaded to the local MEC server. We can also observe from Figure 14 that our proposed mechanism can alleviate the load caused by the velocity and the number of CVs. Specifically, the total mobility management load on the GW can reduced up to 83.5 percent in a high mobility and mass CV scenario with the setting of vvk=50km/h and CVnumber=200 compared with the LISP-MN mechanism.Figure 14
Total mobility management load on the GW versusvvk.


## 6.2.5. SgNB Utilization Rate

Finally, we explore how the average SgNB utilization rate varies with data requested rate as shown in Figure15. It can be seen from Figure 15 that for each fixed vvk, the average SgNB utilization rate under our proposed mechanism is higher than that under the traditional LISP-MN mechanism. This is because the proposed mechanism selects the SgNB with the longest sojourn time as the target SgNB and ignores the SgNBs which do not meet the load requirements. A further observation from Figure 15 indicates that both the increases of data requested rate and velocity will reduce the SgNB utilization. We know that the CV will gain the access admission to the target SgNB when it has sufficient network resources. The high requested rate can increase the occupation of the network resource and cause the access reject during the handover process, which leads to a decreased Tused. Meanwhile, the increase of velocity can also reduce the cell sojourn time of the CV, which also results in a decrease of Tused.Figure 15
Average SgNB utilization rate versus data request rate.


## 7. Conclusion

This paper proposed an optimal decentralized mobility management mechanism for the dense 5G networks. Under this mechanism, we first designed an LMA-based handover management architecture, which jointly applies the technical advantages of ILS, dual connectivity, and MEC to realize a low signaling cost mobility management under the dense gNB scenarios. Then, we proposed a QoS-based handover decision algorithm to ensure network balance and improve the network utilization, which unitizes a predefined QoS boundary conversion method involving an LSTM-based vehicular sojourn time prediction model. Moreover, we redefined the dynamic trigger condition in the handover algorithm to enhance the robustness of the intra-MeNB handover decision in highly different link scenarios with the heterogeneity of SgNBs. Simulation results illustrate that the LSTM-based prediction model in our proposed handover decision algorithm can achieve a low trajectory prediction error. Meanwhile, our proposed mobility management mechanism can significantly reduce the handover latency, the handover times, the packet loss rate, and the mobility management load and also improve the gNB utilization rate compared to a classic traditional mechanism.



---

*Source: 6300715-2022-07-15.xml*