5.1.1 Mobility Management Objectives

The fifth generation (5G) access control and mobility management (MM) framework is intended to be adaptive and flexible, to cater for the disparate 5G mobility requirements coming from very diverse use cases.

Some main drivers for this MM framework are the following:

1. 1) Support of common access control procedures for third generation partnership project (3GPP) and non‐3GPP access. Enable development of a common protocol to perform access control for 3GPP access and non‐3GPP access.
2. 2) Frequent small data transmission. Smart phone applications have the need to send and receive small packets frequently to keep internet protocol (IP) connectivity open. This is referred to as “heart‐beat” or “keep‐alive.” MM state machine should be conducive to support frequent small data transmission without additional signaling overhead.
3. 3) Mobility on demand. Statistics from existing deployments showed that around 70% of the devices camping in cellular network are stationary thus, operators wanted to reduce the cost incurred due to support for MM framework by default resulting in additional cost overhead.
4. 4) Ensuring that the MM state machine is split from session management (SM) state machine (Modular functional split). This is to minimize dependencies between logical function modules, remove overlaps in functional scope from network functions.

With the interest to increase convergence between 3GPP and non‐3GPP access, features that are common to both access were considered “mandatory” and other access specific features were considered optional for the network to support. So, with the new system, registration procedure is part of the essential features for all access while features such as paging, reachability, etc. are 3GPP access specific thus considered optional rather it is necessary to support only for 3GPP access. Furthermore, need to support “mobility on demand” has also caused 3GPP to revisit the use of the term “mobility management” for MM framework in 5G system. The network function that supports registration, connection management (referred to as MM earlier) is called as AMF that stands for “access control and mobility management function.”

In a broader sense “mobility management” includes all procedures used to support registration and mobility of a user equipment (UE), such as:

• Selecting a network;
• Registering and Deregistering from the network;
• Camping on a suitable cell and Cell Synchronization;
• Keeping the network informed about the present location of the UE to be reachable for paging even after the connection to the network has been released;
• Maintaining the connection to the network while the UE is moving (referred to as “handover”);
• Re‐establishing the connection between UE and network when the UE needs to send uplink (UL) signaling or user data or when the UE was paged by the network because the network wants to send downlink (DL) signaling or user data.

Furthermore, certain security related tasks are usually performed as part of the mobility management procedures: authentication, confidentiality protection of the subscriber's identity and confidentiality and/or integrity protection of signaling messages and user data. Detailed security aspects are specified in Chapter 7.

This chapter provides a detailed overview of access control and mobility management framework in 5G Systems. It also provides a detailed overview of radio resource control protocol (RRC) states, non‐access stratum (NAS) states, handover and mobility procedure in various states, also handover procedures for Non‐Standalone (NSA) mode and Standalone (SA) mode. In addition, it provides some insights on challenges due to high mobility and requirements to support ultra‐reliable low latency with mobility. Furthermore, it outlines the procedures for inter‐system mobility. Finally, it provides an outlook for supporting enhanced Mobility features in subsequent 3GPP releases.

5.1.2 Mobility Requirements for the 5G System

The mobility requirements for 5G services are significantly more stringent compared to 3G or 4G. The user plane and control plane latency, reliability and robustness to radio link failures, mobility and mobility interruption time requirements are defined to ensure the introduction of mobile systems which support the new capabilities of systems beyond IMT‐2000 and IMT‐Advanced. IMT‐2020 [1] aims at more flexible, reliable and secure mobile system providing diverse services in the enhanced mobile broadband (eMBB), ultra‐reliable and low‐latency communications (URLLC), and massive machine type communications (mMTC). Further, 5G System is expected to operate in a wide range of frequencies (1–100 GHz) meaning that beamforming techniques are needed to compensate for the higher propagation loss at high frequencies. In this chapter, the 5G System mobility solutions are introduced which can address the 5G mobility requirements.

One of the key target agreements made so far in 3GPP is that handover interruption should be close to 0 ms with UE implemented with a single transceiver capability. While this is challenging and depends on the exact definition of interruption‐less mobility, this can be considered as a major improvement over 4G, which by default always involves a data interruption during handover due to legacy baseline handover procedure. Without going into more detailed solution, there are two basic principles on how the interruption‐less handover can be achieved. With a single TX/RX solution the UE and network can deploy a normal handover with Make‐Before‐Break handover (connectivity to source cell is maintained until connectivity to target cell is established), which won't be interruption‐less but can achieve close to 0 ms interruption with reasonable implementation cost. With more than one TX/RX solution at UE the connection to source cell can be maintained with uninterrupted user plane data while the connection to target cell is established, also known as multi‐connectivity in 5G.

Performance‐wise, the mobility solutions and supporting architectural decisions are having a paramount impact on the resulting capability of system performance. The user plane latency is targeted to be in the order of 4 ms for eMBB, while the URLLC services need far lower latency in the order of 1 ms. The 5G control plane needs to support both extreme power saving and low latency, e.g. transition time from battery efficient state to ready to data transfer. The minimum requirement for control plane latency is 20 ms and 3GPP has decided to target for 10 ms latency.

5.1.3 Mobility Support in the 5G System

Mobility supported in 5G for 3GPP access could be classified into several different categories. One classification is based on the RRC state of the UE:

1. a. Connected mode mobility.
2. b. Inactive mode mobility.
3. c. Idle mode mobility.

Further, in each of these states, depending on the type of mobility event, there is a further categorization:

1. a. Intra new radio (NR) mobility.
2. b. Inter radio access technology (RAT) mobility.

Then there is mobility in SA connectivity and NSA connectivity modes. This is applicable to both intra NR and inter‐RAT use cases.

There are more flavors available based on type of deployments, namely classical gNB deployment and cloud gNB deployment. Cloud gNB is a gNB where the constituents of a gNB (CU‐CP(Central Unit Control Plane), CU‐UP(Central Unit User Plane), DU) are separated over F1 (see TS 38.473 [2]) and E1 interfaces (see TS 38.463 [3]). A classical gNB is a gNB where the F1 and E1 interfaces are internal. A cloud gNB may have more than one gNB‐DU under its control, while a classical gNB has only one gNB‐DU under its control.

For more details on RAN architecture, please refer to Chapter 4.

While the architecture of a classical gNB is realized by juxtaposing the logical entities of a cloud gNB, the 3GPP defined interfaces between those logical entities (F1 and E1) will simply become internal. Therefore, we describe the mobility events for a cloud gNB and explain how they are realized for a classical gNB.

We describe in this chapter the various kinds of mobility for different RRC states (e.g. Intra gNB, Inter gNB. Intra DU, Inter DU, and Inter RAT). RRC Connected, RRC Inactive and RRC_IDLE have their own mobility procedures.

5.2.1 NAS State Machine and State Transitions

The NAS layer can be categorized into two main sublayers (See TS 24.501 [4]): MM sublayer and SM sublayer. The main function of the MM sublayer includes registration management (RM), and the main function of the SM sublayer is to manage the protocol data unit (PDU) session context.

The NAS state machine is applicable for both 3GPP and non‐3GPP access. In evolved packet system (EPS), 3GPP NAS SM protocol for non‐3GPP access was emulated to support wireless local area network control plane protocol (WLCP) between UE and enhanced packet data gateway (ePDG) (see [5]). However, the NAS specifications and the actual protocol were still different and evolved separately for 3GPP and non‐3GPP access. With 5G architecture, target was to specify a single NAS protocol that evolves together for both 3GPP and non‐3GPP access. Although not all information elements within NAS are expected to be common and applicable for both 3GPP and non‐3GPP access, it is expected that the overall mobility, authentication, and session management framework are applicable for both thus enabling support for converged core network. This also enables seamless mobility between 3GPP and non‐3GPP access without the need to re‐authenticate in all cases.

The simplified form of the state machine managed in the MM sublayer for RM is depicted in Figure 5.1. The state machine is managed per access type (i.e. 3GPP access or non‐3GPP access).

In the RM‐NULL state, 5GS services are disabled in the UE. No MM function is performed in this state. The UE in the RM‐DEREGISTERED state can enter to this state by disabling the N1 mode, a mode of a UE allowing access to the 5GC via the 5G‐AN. The UE in the RM‐NULL state can transition to the RM‐DEREGISTERED state if the N1 mode is enabled.

In the state RM‐DEREGISTERED, no MM context has been established and the location of the UE is unknown to the 5GC and hence it is unreachable by the 5GC. To establish a MM context, the UE shall start the initial registration procedure. The UE in the RM‐REGISTERED state can enter to this state by (locally) deregistering from the 5GS.

In the state RM‐REGISTERED, a MM context has been established. Additionally, one or more PDU session context(s) may be activated at the UE. The UE may initiate the non‐initial registration procedure (including the mobility registration update and periodic registration update).

Furthermore, in the state RM‐REGISTERED, UE can either be in CM‐CONNECTED state or CM‐IDLE state (Figure 5.2). When the UE is in CM‐IDLE state, the network must page the UE to be able to reach the UE in the case of the 3GPP access. Similarly, the UE needs to send an initial NAS message to transition to CM‐CONNECTED state to transmit either signaling or user plane packets. When the UE is in CM‐CONNECTED state, UE and network can communicate at the NAS layer level.

The simplified form of the state machine managed in the SM sublayer is depicted in Figure 5.3. The state machine is managed per PDU session.

In the INACTIVE state, no PDU session context exists. The successful PDU session establishment allows transition to the ACTIVE state.

In the ACTIVE state, PDU session context is active in the UE. The state of a PDU session context with the ACTIVE state changes to the INACTIVE state if the PDU session context is released by the PDU session release procedure. The PDU session context in this state can be modified by the PDU session modification procedure.

5.2.2 RRC State Machine and State Transitions

With 5G, there is a need to address the “smart” problem with “always on” applications:

1. – Multiple applications run on top of each other with independent heartbeats.
2. – “Always on” applications need to send and receive small packets frequently to keep IP connectivity open.
3. – The typical frequency of “keep alive” is once per minute, or once every few minutes, and the amount of data is very small (≪1 KB).
4. – Keep alive messages are typically generated by the application without any option for the network to control them (Figure 5.4).

Hence, to tackle this challenge, the 5G systems was expected to adopt connectivity with flexibility in its configuration to system access. In 5G, the system is expected to offer a solution to support “always connected” applications taking “always on” to the next level. Thus, the access to the network and state transition to connected state should be instantaneous from the application perspective, in the order of 10 ms [6].

An overview of existing RRC states and state transitions specified by 3GPP for LTE is shown in Ref. [7], which also illustrates the mobility support between evolved universal mobile telecommunications system terrestrial RAN (E‐UTRAN), universal terrestrial radio access network (3G RAN) (UTRAN) and GSM/EDGE RAN (GERAN). Details of mobility management for Evolved Packet System is described in TS 23.401[8] and TS 24.301[9]. The RRC states in LTE, namely RRC_IDLE and RRC_CONNECTED, try to minimize the UE power consumption, network resource usage and memory consumption while the RRC_CONNECTED was introduced for high UE activity and network controlled mobility respectively. The state transition from CONNECTED to IDLE and vice‐versa requires a considerable amount of signaling to setup the UE's AS context in RAN and introduces delay and extra e2e system signaling. Smartphone applications and machine type communications (MTC) devices have resulted in the reconsideration of state handling efficiency in LTE systems. It is costly to keep all the UEs in RRC_CONNECTED state, as high user activity increases power consumption and mobility related signaling. On the other hand, the state transition from RRC_IDLE to RRC_CONNECTED, in the order of 50 ms, cannot meet the 10 ms latency requirements of 5G. This resulted in the need to reconsider RRC state machine for 5G System.

Although the UE is in CM CONNECTED state from the core network (CN) perspective, the RAN can suspend the RRC state of the UE during inactivity periods. From the RAN perspective, the UE can be in RRC connected, RRC Inactive or RRC Idle state. When inactivity is detected, the UE may request based on a configured timer that the network can suspend the RRC connection. Alternatively, the RAN may suspend the RRC connection from RRC_CONNECTED to RRC_INACTIVE after the data buffers are empty or if there is a temporary inactivity detected. The RRC_IDLE state may be rarely used, for example, as a recovery state when RRC resume fails. This resulted in the introduction of RRC_INACTIVE state for 5G and the RRC state machine comprises of RRC_IDLE, RRC_CONNECTED and RRC_INACTIVE [10]. Figure 5.5 illustrates the RRC State machine and expected transitions (for details see Ref. [11]):

Figure 5.6 shows how RRC state machine fits within the NAS states:

The UE mobility is controlled by the network during RRC connected state. However, during RRC Inactive state, the mobility of the UE is controlled by the UE with the assistance of the network. In RRC_IDLE state, i.e. in a kind of recovery state, the UE mobility using cell reselections is autonomously controlled by UE. Lightweight procedures called RRC suspend and RRC resume are respectively used to resume and suspend RRC connection. The RRC suspend message may contain service tailored configuration to address UEs with diverse service requirements.

The UE state transition happens when either the UE or the next generation RAN (NG‐RAN) node detects a low activity condition and UE has no ongoing data traffic in the user‐plane.

When the network commands the UE to Inactive state, the last serving NG‐RAN node (gNB or ng‐eNB) sends an RRC Connection Suspend message to the UE. The message that contains (at least) Resume Identification (ID, in this case the Last NG‐RAN node (gNB or ng‐eNB) ID), Inactive state related timing Information (e.g. Registration period), up‐to‐date list of TAs (Tracking Areas) in which the UE can move without TA update, and Security Information for UE identification while re‐connecting to the network.

Active connection in RRC Connected state is needed again when an application needs to send data. The UE is already connected so it will reconnect to the network via its current NG‐RAN cell and sends the RRC Connection Resume Request message to the NG‐RAN node including (at least) UE ID, Resume ID, Inactive state related timing Information (e.g. time spent in inactive state), and Security Information to verify the UE context. The NG‐RAN node responds to the UE with the RRC Connection Resume Complete message and UE is back to CONNECTED state.

A connection failure during the RRC Inactive can happen for example due to failed cell reselection or if the cell update to RAN was not acknowledged back to UE. Also RAN can detect and assume a connection failure or UE may have been powered off if RAN has not received any location update information from UE within the maximum reporting time period.

5.2.3 Inter‐RAT Operation of RRC States

In legacy networks, when a UE in RRC_IDLE state measures and selects to camp in a better cell in a new RAT, it enters RRC_IDLE in the new RAT. Similarly, it is agreed in Release 15 that UE in the RRC_INACTIVE state can perform selection to another RAT and the UE enters the RRC_IDLE state in that RAT. The tight interworking between NR and LTE evolution during inactive state could be exploited more effectively for NG‐RAN mobility. An NG‐RAN node can either provide NR or E‐UTRA control plane with RRC protocol terminations toward the UE. Therefore, it could be assumed that eLTE will support also RRC_INACTIVE and allow cell re‐selection between the systems within the NG‐RAN context. The RRC_INACTIVE state could have a common configuration with RAT specific details and a common RAN Notification area configuration shared within NG‐RAN. The RRC States in the UE and the anchor eNB remain the same, even if the UE selects a cell that belong to another RAT and its RAN area. The procedure can be referred as NG‐RAN RRC reactivation procedure to activate the RRC connection between the UE and the current anchor eNB, possibly located in another RAT. In addition to activating the RRC connection between the UE and the anchor NB, the anchor eNB may send the necessary UE context information to the new eNB.

As an example, let's consider a scenario where eLTE (E‐UTRA) and NR are connected to 5GC (Figure 5.7). The UE is under the NR coverage and network suspends the RRC connection to RRC_INACTIVE. The UE AS context is stored in the anchor gNB and the UE. The stored UE context may include, e.g. data radio bearer (DRB) configuration, AS security context, etc. The UE is provided with a NG‐RAN notification area that consists of cells that belong to eLTE and NR. If the UE reselects to eLTE, it does not need to update its location nor change RRC state to RRC_IDLE. When the UE has the data available for transmission, it initiates an NG‐RAN RRC activation procedure to the current cell, which fetches the UE Context from the anchor gNB and resumes the RRC connection with the state transition to RRC_CONNECTED.

5.2.4 Benefits of the New RRC State Model

The new state model and proposed new RRC state together optimize the power consumption of mobile devices during the low activity periods while minimizing the latency for the first packet transmission from the UEs to the network. The identified characteristics of the RRC state model are shown in the Table 5.1. The mobility and system access procedures of the new state model are configurable based on different aspects of use cases, device capability, access latency, power saving, security requirements and privacy.

The mobility state design for 5G has taken the learnings from the pros and cons of state handling design in the existing technologies and considered the 5G use cases and their requirements. Some benefits of the new 5G RRC state model using RRC_INACTIVE are that it:

• can keep the UEs always connected from 5GC perspective;
• enables minimum number of RRC states to avoid added complexity in the state model;
• provides fast and lightweight state transition between active data transmission and power saving, which can reduce CP signaling overhead for frequent state transitions;
• can fulfill the latency requirement of state transition for control plane;
• can support highly configurable procedures for contradictory requirements of various 5G use cases; and
• allows network slice specific state configuration.

5.4.1 NSA Mobility Scenarios

Here we consider mobility events related to MR‐DC (LTE‐NR Dual Connectivity). MR‐DC (MultiRAT Dual Connectivity) is a generic term used to represent all the three variants of LTE‐NR Dual connectivity, namely,

1. a. EN‐DC (option 3 family): LTE eNB master and NR gNB secondary.
2. b. NE‐DC (option 4): NR gNB master and eLTE ng‐eNB secondary.
3. c. NGEN‐DC (option 7): eLTE ng‐eNB master and NR gNB secondary.

The Master Node (MN) and Secondary Node (SN) roles could be taken by any node according to the configurations listed above. The following are the mobility events that could occur while dealing with a UE in any of the MR‐DC configurations. Here we describe the mobility events with a common MN and SN terminology:

1. a. Intra SN mobility;
2. b. Change of SN: Inter SN Handover (MN or SN initiated);
3. c. Inter MN Handover without SN change;
4. d. Master Node to eNB/gNB Change: SN Release.

5.4.1.1 Intra SN Mobility in a Cloud RAN Deployment

We describe mobility for the CU‐DU split option, where the CU can be implemented, e.g. in a cloud, since it has use cases like inter‐DU mobility to support that are not applicable for a gNB where CU and DU functions are collocated.

The intra SgNB mobility can be carried out over the SRB1 and SRB2 (eNB assisted) or over SRB3 (autonomous for gNB). Some topics that were considered:

1. a. The UE support for SRB3 is a major factor which influences if a UE will be configured with SRB3.
2. b. The support of SRB3 by a UE and network configuration for the same does not guarantee all the intra gNB mobility events to be executed over SRB3.
3. c. Whenever there is an inter MN cell change, the KeNB changes. This results in a S‐KeNB change as well. Therefore, in all cases involving a security key change, a combined Pcell and PScell RRC re‐configuration is performed. This is executed over SRB1/2 of MeNB.

However, it should also be noted that whenever SRB3 is used for RRC re‐configurations or mobility events, there is a certain optimization in terms of latency of the executed procedure.

Intra CU, Inter DU Mobility using SCG SRB (SRB3)

This scenario is applicable only for a cloud RAN gNB, since multiple DUs are not possible in a classical gNB.

This procedure is used for the case the UE moves from one gNB‐DU to another gNB‐DU within the same gNB‐CU during NR operation. Figure 5.10 shows the inter‐gNB‐DU mobility procedure for intra‐NR.

1. The UE sends a Measurement Report message to the source gNB‐DU.
2. The source gNB‐DU sends an Uplink RRC Transfer message to the gNB‐CU to convey the received Measurement Report.
3. The gNB‐CU sends an UE Context Setup Request message to the target gNB‐DU to create an UE context and setup one or more bearers, which contains Target Cell ID.
4. The target gNB‐DU responds to the gNB‐CU with an UE Context Setup Response message, which contains MobilityControlInfo. In a successful case, the admission control check has passed and resources are allocated at the target.
5. The gNB‐CU sends a UE Context Modification Request to the source DU, which indicates to suspend the data transmission for the UE, at the source gNB‐DU. The source gNB‐DU also sends a Downlink Data Delivery Status frame to inform the gNB‐CU about the unsuccessfully transmitted downlink data to the UE. Downlink packets, which may include packet data convergence protocol (PDCP) PDUs not successfully transmitted in the source gNB‐DU, are sent from the gNB‐CU to the target gNB‐DU.
6. S‐gNB‐DU responds with successful suspension of data transmission and UE scheduling.
7. PSCell change is triggered by gNB‐CU over SRB3. Message contains RRC: RRCReconfiguration message, which contains the CellGroupConfig IE, and internally the SpCellConfig IE and the SCellConfig IE. SpCellConfig IE contains the reconfigurationWithSync IE, which indicates to UE that PSCell change request is in question. SpCellConfig IE defines also the target PhysCellId, new cell radio network temporary identifier (C‐RNTI) and t304 for UE. TDCoverall timer is started after sending the RRC message.
8. UE sends an NR RRC: RRC Reconfiguration Complete message which confirms that UE has processed the message.
9. Random Access procedure is performed by the UE at the target gNB‐DU.
10. Downlink packets are sent to the UE. Also, uplink packets are sent from the UE, which are forwarded to the gNB‐CU through the target gNB‐DU.
11. The gNB‐CU sends an UE Context Release Command message to the source gNB‐DU.
12. The source gNB‐DU releases the UE context and responds the gNB‐CU with an UE Context Release Complete message.

Intra CU, Inter‐gNB‐DU Mobility using MCG SRB

This procedure is used for the case the UE moves from one gNB‐DU to another gNB‐DU within the same gNB‐CU when only master cell group (MCG) SRB is available during EN‐DC operation (see [16]). Figure 5.11 shows the inter‐gNB‐DU mobility procedure using MCG SRB in EN‐DC.

As mentioned earlier, using MCG SRBs for mobility causes additional latency for the handover event. This is because of the additional X2 messages in DL and UL. Hence it is recommended to utilize SRB3 whenever supported by UE and available at gNB.

However, there could be several reasons why a gNB must turn to MCG SRBs despite having configured SRB3. Combined PCell and PSCell change in MN and SN, reliability of a handover event are some example use‐cases.

It should also to be noted here that the UE will respond to the network in the same SRB route that it received the DL message.

1. 1. The UE sends a Measurement Report message to the MeNB.
2. 2. The MeNB transparently forwards this to the SgNB over X2 (see TS 36.423 [17]).
3. 3. The gNB‐CU sends an UE Context Setup Request message to the target gNB‐DU to create an UE context and setup one or more bearers.
4. 4. The target gNB‐DU responds the gNB‐CU with an UE Context Setup Response message after performing admission control and allocating required resources.
5. 5. The gNB‐CU sends a UE context modification request to suspend data transmission at DU for this UE.
6. 6. gNB‐DU responds with a successful suspension of data transmission and UE scheduling. At this stage, data transmission is suspended in both CU and DU.
7. 7. The SgNB sends an X2: SgNB Modification Required to initiate a PSCell change. The RRC Re‐configuration container inside this message contains the necessary configurations and information about the target cell.
8. 8, 9. The MeNB and the UE execute the Handover event by performing the RRC Reconfiguration procedure.
9. 10. The MeNB sends an SgNB modification confirm message to the gNB‐CU. Downlink packets, which may include PDCP PDUs not successfully transmitted in the source gNB‐DU, are sent from the gNB‐CU to the target gNB‐DU.
10. 11. Random Access procedure is performed at the target gNB‐DU. Downlink packets are sent to the UE. Also, uplink packets are sent from the UE, which are forwarded to the gNB‐CU through the target gNB‐DU.
11. 12. The gNB‐CU sends an UE Context Release Command message to the source gNB‐DU.
12. 13. The source gNB‐DU releases the UE context and responds to the gNB‐CU with an UE Context Release Complete message.

The procedure remains the same in NGEN‐DC case, except for the fact that the interface between MN and MN is Xn.

5.4.1.2 Change of Secondary Node (MN and SN Initiated)

EN‐DC

The change of Secondary Node procedure is initiated either by MN or SN and used to transfer a UE context from a source SN to a target SN and to change the SCG configuration in UE from one SN to another.

The Change of Secondary Node procedure always involves signaling over MCG SRB towards the UE and it cannot be autonomously performed by SN over SRB3.

EN‐DC: MN Initiated SN Change

Figure 5.12 shows the signaling flow for the MN initiated Secondary Node Change:

1. 1.‐2. The MN initiates the SN change by requesting the target SN to allocate resources for the UE by means of the SgNB Addition procedure. The MN may include measurement results related to the target SN. If forwarding is needed, the target SN provides forwarding addresses to the MN. The MN may send the SgNB Modification Request message (to the source SN) to request the current SCG configuration before step 1.
2. 3. If the allocation of target SN resources was successful (indicated in the SgNB Addition Request Acknowledge in step 2), the MN initiates the release of the source SN resources including a Cause indicating SCG mobility. The Source SN may reject the release. If data forwarding is needed the MN provides data forwarding addresses to the source SN. Reception of the SgNB Release Request message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.
3. 4‐5. The MN triggers the UE to apply the new configuration by sending an RRC Re‐configuration message. The MN indicates to the UE the new configuration in the RRCConnectionReconfiguration message including the NR RRC configuration message generated by the target SN. The UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.
4. 6. If the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN.
5. 7. If configured with bearers requiring SCG radio resources, the UE synchronizes to the target SN.
6. 8‐9. UE performs Random Access procedure. If applicable, data forwarding from the source SN takes place. It may be initiated as early as the source SN receives the SgNB Release Request message from the MN.
7. 10‐11. The source SN sends the Secondary RAT Data Volume Report message to the MN and includes the data volumes delivered to the UE over the NR radio for the related E‐RABs.
8. 12‐15. If one of the bearers was terminated at the source SN, path update is triggered by the MN.
9. 16. Upon reception of the UE Context Release message, the source SN can release radio and C‐plane related resource associated to the UE context. Any ongoing data forwarding may continue.

EN‐DC: SN Initiated SN Change

Figure 5.13 shows the signaling flow for the Secondary Node Change initiated by the SN:

1. 1. The source SN initiates the SN change procedure by sending SgNB Change Required message which contains target SN ID information and may include the SCG configuration (to support delta configuration) and measurement results related to the target SN.
2. 2.‐3. The MN requests the target SN to allocate resources for the UE by means of the SgNB Addition procedure, including the measurement results related to the target SN received from the source SN. If forwarding is needed, the target SN provides forwarding addresses to the MN.
3. 4.‐5. The MN triggers the UE to apply the new configuration. The MN indicates the new configuration to the UE in the RRCConnectionReconfiguration message including the NR RRC configuration message generated by the target SN. The UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.
4. 6. If the allocation of target SN resources was successful, the MN confirms the release of the source SN resources. If data forwarding is needed the MN provides data forwarding addresses to the source SN. Reception of the SgNB Change Confirm message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.
5. 7. If the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SgNB Reconfiguration Complete message with the encoded NR RRC response message for the target SN.
6. 8. The UE synchronizes to the target SN by performing Random Access procedure.
7. 9.‐10. If applicable, data forwarding from the source SN takes place. It may be initiated as early as the source SN receives the SgNB Change Confirm message from the MN.
8. 11. The source SN sends the Secondary RAT Data Volume Report message to the MN and includes the data volumes delivered to the UE over the NR radio for the related E‐RABs.
9. 12‐16. If one of the bearers was terminated at the source SN, path update is triggered by the MN.
10. 17. Upon reception of the UE Context Release message, the source SN can release radio and C‐plane related resource associated to the UE context. Any ongoing data forwarding may continue

MR‐DC

This is described in a generic manner as it is applicable for both NEDC and NGEN‐DC scenarios.

MR‐DC: MN Initiated SN Change

The MN initiated SN change procedure is used to transfer a UE context from the source SN to a target SN and to change the SCG configuration in UE from one SN to another.

The Change of Secondary Node procedure always involves signaling over MCG SRB towards the UE.

Figure 5.14 shows the signaling flow for the SN Change initiated by the MN:

1. 1.‐2. The MN initiates the SN change by requesting the target SN to allocate resources for the UE by means of the SN Addition procedure. The MN may include measurement results related to the target SN. If data forwarding is needed, the target SN provides data forwarding addresses to the MN. The MN may send the SN Modification Request message (to the source SN) to request the current SCG configuration before step 1.
2. 3. If the allocation of target SN resources was successful, the MN initiates the release of the source SN resources including a Cause indicating SCG mobility. The Source SN may reject the release. If data forwarding is needed the MN provides data forwarding addresses to the source SN. Reception of the SN Release Request message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.
3. 4.‐5. The MN triggers the UE to apply the new configuration. The MN indicates the new configuration to the UE in the MN RRC reconfiguration message including the target SN RRC configuration message. The UE applies the new configuration and sends the MN RRC reconfiguration complete message, including the encoded SN RRC response message for the target SN. In case the UE is unable to comply with (part of) the configuration included in the MN RRC reconfiguration message, it performs the reconfiguration failure procedure.
4. 6. If the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SN Reconfiguration Complete message with the encoded SN RRC message for the target SN.
5. 7. If configured with bearers requiring SCG radio resources the UE synchronizes to the target SN by performing Random access procedure.
6. 8.‐9. If applicable, data forwarding from the source SN takes place. It may be initiated as early as the source SN receives the SN Release Request message from the MN.
7. 10‐14. If one of the PDU session/QoS (quality of service) Flow was terminated at the source SN, path update procedure is triggered by the MN.
8. 15. Upon reception of the UE Context Release message, the source SN can release radio and C‐plane related resource associated to the UE context. Any ongoing data forwarding may continue.

MR‐DC: SN Initiated SN Change

The SN initiated SN change procedure is used to transfer a UE context from the source SN to a target SN and to change the SCG configuration in UE from one SN to another.

Figure 5.15 shows the signaling flow for the SN Change initiated by the SN:

1. 1. The source SN initiates the SN change procedure by sending the SN Change Required message, which contains a candidate target node ID and may include the SCG configuration (to support delta configuration) and measurement results related to the target SN.
2. 2.‐3. The MN requests the target SN to allocate resources for the UE by means of the SN Addition procedure, including the measurement results related to the target SN received from the source SN. If data forwarding is needed, the target SN provides data forwarding addresses to the MN.
3. 4.‐5. The MN triggers the UE to apply the new configuration. The MN indicates the new configuration to the UE in the MN RRC reconfiguration message including the SN RRC configuration message generated by the target SN. The UE applies the new configuration and sends the MN RRC reconfiguration complete message, including the encoded SN RRC response message for the target SN. In case the UE is unable to comply with (part of) the configuration included in the MN RRC reconfiguration message, it performs the reconfiguration failure procedure.
4. 6. If the allocation of target SN resources was successful, the MN confirms the change of the source SN. If data forwarding is needed the MN provides data forwarding addresses to the source SN. Reception of the SN Change Confirm message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.
5. 7. If the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SN Reconfiguration Complete message with the encoded SN RRC response message for the target SN.
6. 8. The UE synchronizes to the target SN by performing Random access procedure.
7. 9.‐10. If applicable, data forwarding from the source SN takes place. It may be initiated as early as the source SN receives the SN Change Confirm message from the MN.
8. 11‐15. If one of the PDU session/QoS Flow was terminated at the source SN, path update procedure is triggered by the MN.
9. 16. Upon reception of the UE Context Release message, the source SN can release radio and C‐plane related resource associated to the UE context. Any ongoing data forwarding may continue.

5.4.1.3 Inter‐Master Node Handover without Secondary Node Change

EN‐DC

Inter‐Master Node handover with or without MN initiated Secondary Node change is used to transfer context data from a source MN to a target MN while the context at the SN is kept or moved to another SN. During an Inter‐Master Node handover, the target MN decides whether to keep or change the SN (or release the SN).

Figure 5.16 shows the signaling flow for inter‐Master Node handover with or without MN initiated Secondary Node change. For an inter‐Master Node handover without Secondary Node change, the source SN and the target SN shown in Figure 5.16 are the same node.

1. 1. The source MN starts the handover procedure by initiating the X2 Handover Preparation procedure including both MCG and SCG configuration. The source MN includes the (source) SN UE X2AP ID, SN ID and the UE context in the (source) SN in the Handover Request message. The source MN may send the SgNB Modification Request message (to the source SN) to request the current SCG configuration before step 1.
2. 2. If the target MN decides to keep the SN, the target MN sends SN Addition Request to the SN including the SN UE X2AP ID as a reference to the UE context in the SN that was established by the source MN. If the target MN decides to change the SN, the target MN sends the SgNB Addition Request to the target SN including the UE context in the source SN that was established by the source MN.
3. 3. The (target) SN replies with SN Addition Request Acknowledge.
4. 4. The target MN includes within the Handover Request Acknowledge message a transparent container to be sent to the UE as an RRC message to perform the handover, and may also provide forwarding addresses to the source MN. The target MN indicates to the source MN that the UE context in the SN is kept if the target MN and the SN decided to keep the UE context in the SN in step 2 and step 3.
5. 5. The source MN sends SN Release Request to the (source) SN including a Cause indicating MCG mobility. The (source) SN acknowledges the release request. The source MN indicates to the (source) SN that the UE context in SN is kept, if it receives the indication from the target MN. If the indication as the UE context kept in SN is included, the SN keeps the UE context.
6. 6. The source MN triggers the UE to apply the new configuration.
7. 7.‐8. The UE synchronizes to the target MN and replies with RRCConnectionReconfigurationComplete message.
8. 9. If configured with bearers requiring SCG radio resources, the UE synchronizes to the (target) SN.
9. 10. If the RRC connection reconfiguration procedure was successful, the target MN informs the (target) SN via SgNB Reconfiguration Complete message.
10. 11a. The SN sends the Secondary RAT Data Volume Report message to the source MN and includes the data volumes delivered to the UE over the NR radio for the related E‐RABs.
11. 11b. The source MN sends the Secondary RAT Report message to mobility management entity (MME) to provide information on the used NR resource.
12. 12.‐13. Data forwarding from the source MN takes place. If the SN is kept, data forwarding may be omitted for SCG bearers and SCG split bearers.
13. 14–17. The target MN initiates the S1 Path Switch procedure. If new UL tunnel endpoint IDs (TEIDs) of the serving gateway (S‐GW) are included, the target MN performs MN initiated SN Modification procedure to provide them to the SN.
14. 18. The target MN initiates the UE Context Release procedure towards the source MN.
15. 19. Upon reception of the UE Context Release message, the (source) SN can release C‐plane related resource associated to the UE context towards the source MN. Any ongoing data forwarding may continue. The SN shall not release the UE context associated with the target MN if the indication was included in the SN Release Request in step 5.

MR‐DC with 5GC

Inter‐MN handover with/without MN initiated SN change is used to transfer UE context data from a source MN to a target MN while the UE context at the SN is kept or moved to another SN. During an Inter‐Master Node handover, the target MN decides whether to keep or change the SN (or release the SN).

Figure 5.17 shows the signaling flow for inter‐MN handover with or without MN initiated SN change. Note that for an inter‐Master Node handover without Secondary Node change, the source SN and the target SN shown in Figure 5.17 are identical.

1. 1. The source MN starts the handover procedure by initiating the Xn Handover Preparation procedure including both MCG and SCG configuration. The source MN includes the source SN UE XnAP ID, SN ID and the UE context in the source SN in the Handover Request message. The source MN may send the SN Modification Request message (to the source SN) to request the current SCG configuration before step 1.
2. 2. If the target MN decides to keep the source SN, the target MN sends SN Addition Request to the SN including the SN UE XnAP ID as a reference to the UE context in the SN that was established by the source MN. If the target MN decides to change the SN, the target MN sends the SN Addition Request to the target SN including the UE context in the source SN that was established by the source MN.
3. 3. The (target) SN replies with SN Addition Request Acknowledge.
4. 4. The target MN includes within the Handover Request Acknowledge message a transparent container to be sent to the UE as an RRC message to perform the handover, and may also provide forwarding addresses to the source MN. The target MN indicates to the source MN that the UE context in the SN is kept if the target MN and the SN decided to keep the UE context in the SN in step 2 and step 3.
5. 5. The source MN sends SN Release Request message to the (source) SN including a Cause indicating MCG mobility. The (source) SN acknowledges the release request. The source MN indicates to the (source) SN that the UE context in SN is kept, if it receives the indication from the target MN. If the indication as the UE context kept in SN is included, the SN keeps the UE context.
6. 6. The source MN triggers the UE to perform handover and apply the new configuration.
7. 7.‐8. The UE synchronizes to the target MN and replies with MN RRC reconfiguration complete message.
8. 9. If configured with bearers requiring SCG radio resources, the UE synchronizes to the (target) SN by performing Random access procedure.
9. 10. If the RRC connection reconfiguration procedure was successful, the target MN informs the (target) SN via SN Reconfiguration Complete message.
10. 11.‐12. Data forwarding from the source MN takes place. If the SN is kept, data forwarding may be omitted for SCG bearers and SCG split bearers.
11. 13–16. The target MN initiates the PDU Session Path Switch procedure. If new UL TEIDs of the UPF for SN are included, the target MN performs MN initiated SN Modification procedure to provide them to the SN.
12. 17. The target MN initiates the UE Context Release procedure toward the source MN.
13. 18. Upon receipt of the UE Context Release message from source MN, the (source) SN can release C‐plane related resource associated to the UE context towards the source MN. Any ongoing data forwarding may continue. The SN shall not release the UE context associated with the target MN if the indication was included in the SN Release Request message in step 5.

5.4.1.4 Master Node to eNB/gNB Change

The Master Node to eNB/gNB Change procedure is used to transfer context data from a source MN/SN to a target eNB/gNB. Basically, this is about releasing the dual connectivity and getting back to single connectivity. This could happen either due to UE not requiring DC anymore or due to deteriorating NR coverage and UE cannot see any other gNB cells.

EN‐DC

Here the Master Node to eNB change procedure is explained in the context of EN‐DC. This is the case when eNB is acting as the Master Node and gNB is the Secondary Node.

Figure 5.18 shows the signaling flow for the Master Node to eNB Change procedure:

1. 1. The source MN starts the MN to eNB Change procedure by initiating the X2 Handover Preparation procedure, including both MCG and SCG configuration. The source MN may send the SgNB Modification Request message (to the source SN) to request the current SCG configuration before step 1.
2. 2. The target eNB includes the field in HO command which releases SCG configuration, and may also provide forwarding addresses to the source MN.
3. 3. If the allocation of target eNB resources was successful, the MN initiates the release of the source SN resources toward the source SN including a Cause indicating MCG mobility. The SN acknowledges the release request. If data forwarding is needed, the MN provides data forwarding addresses to the source SN. Reception of the SgNB Release Request message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.
4. 4. The MN triggers the UE to apply the new configuration. Upon receiving the new configuration, the UE releases the entire SCG configuration.
5. 5.‐6. The UE synchronizes to the target eNB by performing Random access procedure.
6. 7.‐8. If applicable, data forwarding from the source SN takes place. It may start as early as the source SN receives the SgNB Release Request message from the MN.
7. 9a. The source SN sends the Secondary RAT Data Volume Report message to the source MN and includes the data volumes delivered to the UE over the NR radio for the related E‐RABs.
8. 9b. The source MN sends the Secondary RAT Report message to MME to provide information on the used NR resource.
9. 10–14. The target eNB initiates the S1 Path Switch procedure.
10. 15. The target eNB initiates the UE Context Release procedure towards the source MN.
11. 16. Upon reception of the UE CONTEXT RELEASE message, the S‐SN can release radio and C‐plane related resource associated to the UE context. Any ongoing data forwarding may continue.

MR‐DC with 5GC

Here the Master Node to target eNB/gNB is explained as applicable to MR‐DC in general. This is applicable for both cases:

1. 1) Master Node to target ng‐eNB
2. 2) Master Node to target gNB

The change procedure is used to transfer UE context data from a source MN/SN to a target ng‐eNB/gNB. Essentially, this is also about releasing the dual connectivity and getting back to single connectivity.

Figure 5.19 shows the signaling flow for the MN to ng‐eNB/gNB Change procedure:

1. 1. The source MN starts the MN to ng‐eNB/gNB Change procedure by initiating the Xn Handover Preparation procedure, including both MCG and SCG configuration. The source MN may send the SN Modification Request message (to the source SN) to request the current SCG configuration before step 1.
2. 2. The target ng‐eNB/gNB includes the field in HO command which releases the SCG configuration, and may also provide forwarding addresses to the source MN.
3. 3. If the resource allocation within target ng‐eNB/gNB was successful, the MN initiates the release of the source SN resources toward the source SN including a Cause indicating MCG mobility. The SN acknowledges the release request. If data forwarding is needed, the MN provides data forwarding addresses to the source SN. Reception of the SN Release Request message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.
4. 4. The MN triggers the UE to perform HO and apply the new configuration. Upon receiving the new configuration, the UE releases the entire SCG configuration.
5. 5.‐6. The UE synchronizes to the target ng‐eNB/gNB.
6. 7.‐8. If applicable, data forwarding from the source SN takes place. It may start as early as the source SN receives the SN Release Request message from the MN.
7. 9–13. The target ng‐eNB/gNB initiates the PDU Session Path Switch procedure.
8. 14. The target ng‐eNB/gNB initiates the UE Context Release procedure towards the source MN.
9. 15. Upon reception of the UE Context Release message from MN, the source SN can release radio and C‐plane related resource associated to the UE context. Any ongoing data forwarding may continue.

5.4.2 Standalone (SA) Mobility Scenarios

To support session continuity for UEs making inter‐NG‐RAN node mobility within the 5G system, the 5G system provides support for seamless handover procedures. If there exists a direct interface between NG‐RAN nodes, i.e. the Xn interface, and the use of it is not prohibited, the Xn handover procedure is performed. In the Xn handover procedure, the signaling for handover preparation and execution phases is exchanged between NG‐RAN nodes and then the core network is involved. Otherwise, the N2 handover is performed. In the N2 handover procedure, the core network takes part from the handover preparation phase.

Relocation of the AMF is not supported by the Xn handover. If the AMF must be relocated, the N2 handover needs to be performed. On the other hand, both handover procedures support the intermediate UPF relocation.

5.4.2.1 Xn Based Handover

The following call flow (Figure 5.20) shows the Xn based inter NG‐RAN handover.

1. The source NG‐RAN node decides to hand the UE over to the target NG‐RAN node, based on, e.g. measurement report from the UE. Then, the source NG‐RAN node sends the HANDOVER REQUEST message to the target NG‐RAN node. The message contains a transparent RRC container with necessary information to prepare the handover at the target side.
2. The target NG‐RAN node performs the admission control and, if admitted, responds with the HANDOVER REQUEST ACKNOWLEDGE message to the source NG‐RAN node. The message includes a transparent container to be sent to the UE as an RRC message to perform the handover, i.e. HandoverCommand message.
3. The source NG‐RAN node forwards the HandoverCommand message to the UE.
4. The source NG‐RAN node also sends the SN STATUS TRANSFER message to the target NG‐RAN node to transfer the uplink user data receiver status and the downlink user data transmitter status for each of the DRBs which require user data transfer and are accepted by the target NG‐RAN node. The source NG‐RAN node starts forwarding downlink user data from the core network to the target NG‐RAN.
5. The UE completes the RRC connection reconfiguration with the target NG‐RAN node. Now the target NG‐RAN node can forward the downlink user data to the UE and the UE can send uplink user data to the target NG‐RAN node.
6. The target NG‐RAN node sends the PATH SWITCH REQUEST message to the AMF to inform of the handover and PDU session‐related information including at least the downlink tunnel information to the target NG‐RAN node.
7. The AMF sends the Nsmf_PDUSession_UpdateSMContext Request message to the SMF. The message includes the PDU session‐related information.
8. If no UPF relocation is required, the SMF updates the UPF with the downlink tunnel information by exchanging the packet forwarding control protocol (PFCP) Session Modification Request and Response messages. One or more end markers are sent to the source NG‐RAN node. The UPF starts sending downlink user data toward the target NG‐RAN node. Otherwise, the SMF sends the PFCP Session Establishment Request message to a new intermediate UPF and the PFCP Session Modification Request message to the UPF working as a PDU session anchor, and receives response messages from them. Tunnel information is exchanged. One or more end markers are sent by the PDU session anchor UPF and are delivered to the source NG‐RAN node via the old intermediate UPF. The PDU session anchor UPF starts sending downlink user data toward the new intermediate UPF. The source NG‐RAN node forwards the end markers to the target NG‐RAN node. The target NG‐RAN node buffers the downlink user data coming directly from the core network until the target NG‐RAN node receives the end markers from the source NG‐RAN node. The path switch for downlink user data is completed.
9. The SMF responds with the Nsmf_PDUSession_UpdateSMContext Response message, which may include uplink tunnel information to the new intermediate UPF. Now the path witch for uplink user data is also completed.
10. The AMF acknowledges the path switch request. The resources for the inter‐NG‐RAN node data transfer are released.
11. The UE context in the source NG‐RAN node is released.
12. The UE triggers mobility registration procedure if any of the trigger conditions are met (see Section 5.5.2).
13. In case the new intermediate UPF has been allocated, the SMF deletes the session in the old intermediate UPF.

5.4.2.2 N2 Based Handover

The following call flow (Figure 5.21) shows the N2 based inter NG‐RAN handover.

1. 1. The source NG‐RAN node decides to hand the UE over to the target NG‐RAN node, based on, e.g. measurement report from the UE. Then, the source NG‐RAN node sends the HANDOVER REQUIRED message to the AMF. The message includes the target NG‐RAN node identity and a transparent container. If the AMF decides to relocate the UE's serving AMF, the AMF invokes the Namf_Communication_CreateUEContext service toward the new AMF passing the target NG‐RAN node identity and the transparent container.
2. 2. The AMF sends the Nsmf_PDUSession_UpdateSMContext Request message to the SMF including the target NG‐RAN node identity.
3. 3. Based on the target NG‐RAN node identity, the SMF may decide to relocate the intermediate UPF, which leads to the exchange of the PFCP Session Establishment Request and Response message with a new intermediate UPF.
4. 4. The SMF acknowledges the request from the AMF. In the acknowledgement message, the uplink tunnel information (toward the new intermediate UPF, if the SMF decided relocation in step 3) is included.
5. 5. The HANDOVER REQUEST message is sent to the target NG‐RAN identified by the target NG‐RAN identity. The message includes the transparent container and the uplink tunnel information.
6. 6. The target NG‐RAN node sends the acknowledgement message back to the AMF. The message contains the HandoverCommand message and downlink tunnel information toward the target NG‐RAN node. The tunnel information is associated with the PDU sessions that are accepted by the target NG‐RAN node.
7. 7. The AMF sends the Nsmf_PDUSession_UpdateSMContext Request message to the SMF. The message includes the downlink tunnel information.
8. 8. Tunnel information for indirect data forwarding is exchanged. Refer to Ref. [12] for the details about tunneling for user data transfer.
9. 9. The SMF responds with the Nsmf_PDUSession_UpdateSMContext Response message. In the case of the AMF relocation, the target AMF acknowledges to the source AMF with the Namf_Communication_CreateUEContext Response message including the HandoverCommand message.
10. 10‐11. The HandoverCommand message is forwarded to the UE. The source NG‐RAN node starts forwarding downlink user date toward the target NG‐RAN either directly or indirectly.
11. 12. The UE completes the RRC connection reconfiguration with the target NG‐RAN node. Now the target NG‐RAN node can forward the downlink user data to the UE and the UE can send uplink user data to the target NG‐RAN node.
12. 13. The target NG‐RAN node notifies that the handover on the radio side is completed toward the AMF by sending the HANDOVER NOTIFY message. In the case of the AMF relocation, the Namf_Communication_N2InfoNotify service is invoked.
13. 14. The AMF sends the Nsmf_PDUSession_UpdateSMContext Request message to the SMF to inform of the handover completion.
14. 15. The downlink tunnel information toward the target NG‐RAN node is updated to the existing UPF or the new intermediate UPF. In the case of the new intermediate UPF allocation, the PDU session anchor UPF is also updated with the new tunnel information toward the new intermediate UPF. One or more end markers are delivered toward the old downlink user data path involving the source NG‐RAN node, and now downlink PDUs are delivered via the new downlink user data path involving the target NG‐RAN node and the new intermediate UPF (if any). The source NG‐RAN node forwards the end markers to the target NG‐RAN node. The target NG‐RAN node buffers the downlink user data coming directly from the core network until the target NG‐RAN node receives the end markers from the source NG‐RAN node. The path switch for downlink user data is completed.
15. 16. The SMF acknowledges the request.
16. 17. The UE triggers the registration procedure if any of the conditions is met (see Section 5.5.2).
17. 18. In case the new intermediate UPF has been allocated, the SMF deletes the session in the old intermediate UPF.
18. 19. The UE context in the source NG‐RAN node is released.

5.4.3 Conditional Handover

During connected mode mobility without dual/multi‐connectivity, the UE is connected to one cell or more cells at the same time. The UE measures the neighboring cells to guarantee that the given factors, e.g. link power or quality, cell load, UE capability, access class, are above the configured thresholds to meet the QoS requirements. The UE is configured to report the measurement results back to network. The measurement reports can be triggered based on a specific mobility event configured by network, such as the neighbor cell becomes better than the serving cell by a configured quantity and this condition must be valid for a given period before the measurement report is sent to the network. Typically, the network sends the handover command to UE soon after receiving the measurement report and UE executes the handover procedure immediately to access the specified target cell. However, radio link failures may happen during the handover procedure due to UE missing the handover command or network not receiving the measurement report. The UE may also fail to access the target cell. The Conditional Handover (Figure 5.22) described in [18] is a mobility procedure where the UE receives the prepared handover command a bit earlier and is configured to evaluate and access the target cell a bit later to avoid the risk of the above‐mentioned failures, for example. Thereafter, the Conditional Handover is a promising technique for improving the handover robustness. The following signaling flow indicates the difference to the baseline Xn handover:

1. The source NG‐RAN node configures the UE for Conditional Handover measurements to identify at least one potential NG‐RAN target node.
2. The configured condition is fulfilled and preparation of Conditional Handover is started with at least one cell being reported to network. The reported configuration is triggering the report earlier compared to baseline measurement report.
3. The source NG‐RAN node decides to prepare the UE for conditional handover to target NG‐RAN node candidate, based on, e.g. measurement report from the UE. The source NG‐RAN node sends the HANDVOER REQUEST message to the target NG‐RAN node. The message contains necessary information to prepare the handover at the target during the Conditional Handover execution.
4. The target NG‐RAN node performs the admission control and, if admitted, responds with the HANDOVER REQUEST ACKNOWLEDGE message to the source NG‐RAN node.
5. The source NG‐RAN node prepares the HandoverCommand message to the UE with all the prepared candidate NG‐RAN target nodes and the Conditional Handover Execution criteria.
6. The UE is measuring and evaluating the prepared target NG‐RAN nodes against the HO execution condition. When the NG‐RAN node is found which meets the target requirements, the Execute condition becomes valid and UE starts the synchronization and Random Access procedures to access the target NG‐RAN node. The target NG‐RAN node sends the PATH SWITCH REQUEST message to the AMF to inform of the handover and PDU session‐related information including at least the downlink tunnel information to the target NG‐RAN node.
7. The UE completes the Conditional Handover Execution with HandoverComplete message to the target NG‐RAN node.
8. The target NG‐RAN node informs the source node about successfully executed handover command.

5.5.1 Overview

The need for an IDLE mode/state has been questioned in 5G as “Always‐on Applications” used in the smart phones need to send and receive small packets frequently to keep IP connectivity open. Essentially the frequent connection requests are related to “push mail/content” services where the UE is frequently checking, if there are any new data available in the application server. Typically, this is a UE initiated event and happens in uncontrolled way from the radio network perspective. Another problem from network perspective are the “heart beat” or “keep alive” messaging events that may occur once per minute, or once every few minutes, and the amount of data is very small (≪1 KB). These messages are used to keep the device towards the network in RRC Connected state.

Despite the enhanced features and functionality, the IDLE state in 5G mobile systems is needed. One major reason is that the needed fault recovery mechanism will add complexity to the new RRC Inactive state. It is an essential requirement for the UE to be able to revert or fallback to a recovery state in case of sudden connectivity fault or network failure. The IDLE state in 5G can support the bootstrap procedures, initial PLMN selection, UE controlled mobility, contention based uplink transmission and core network based location tracking. The IDLE state allows also to reduce energy consumption in the UE, thus allows for longer re‐charge cycles.

5.5.2 Mobility Registration and Periodic Registration

Mobility of a UE in IDLE mode is managed by the AMF with a granularity of a registration area, which is a list of tracking area identities. Therefore, if a UE moves out of the registration area assigned during the most recent registration, it performs a new registration, which is called the mobility registration update procedure. On the other hand, for the network to make sure that the UE located in the allocated registration area has not deregistered locally, i.e. deregistered without informing the network, the network controls the UE so that it performs a new registration periodically, which is called the periodic registration update procedure. If the UE does not perform a registration procedure more than a certain period (by default, four minutes longer than the periodicity of the periodic registration update procedure), the network starts a process to deregister the UE implicitly. Figure 5.23 shows the registration procedure due to mobility or periodic update. See Ref. [12] for further details.

1. 1. In addition to step 1 of Figure 5.8, the REGISTRATION REQUEST message can include PDU session status or uplink data status. The uplink data status indicates the previously established PDU sessions(s) having uplink data pending. The PDU session status indicates the previously established PDU session(s) in the UE.
2. 2–4. If the NG‐RAN selected a new AMF, steps 2–4 are performed. See steps 13 and 14 of Figure 5.8 and steps 2, 3, and 7 of Figure 5.9.
3. 5. For a PDU session included in the uplink data status, the AMF invokes the Nsmf_PDUSession_UpdateSMContext service towards the SMF with which the PDU session is associated by sending the Nsmf_PDUSession_UpdateSMContext Request message. This will trigger user plane resource reactivation in the NG‐RAN. For a PDU session included in the PDU session status and not active in the AMF, the AMF releases the PDU session locally. The AMF invokes the Nsmf_PDUSession_ReleaseSMContext service towards the SMF with which the PDU session is associated by sending the Nsmf_PDUSession_ReleaseSMContext Request message.
4. 6. The SMF responds to the request message.
5. 7. See steps 17 and 18 of Figure 5.8.

5.5.3 Network Initiated Paging

In case user plane traffic (one or more downlink PDUs) or control plane signaling message(s) need to be delivered to the UE in IDLE mode, the AMF pages the UE. Since the AMF is not aware of the exact cell on which the UE is camping, the AMF may need to page the UE for the whole registration area in the worst case.

Figure 5.24 shows the paging procedure. See Ref. [12] for the further details.

1. 1. When a UPF receives a downlink PDU for a PDU session for which there is no downlink tunnel information towards the NG‐RAN stored in the UPF, the UPF sends the PFCP Session Report Request message to the SMF.
2. 2. The SMF acknowledges the request. The UPF may forward the downlink PDU towards the SMF if the SMF is supposed to buffer downlink PDUs.
3. 3. The SMF invokes the Namf_Communication_N1N2MessageTransfer service towards the AMF by sending the Namf_Communication_N1N2MessageTransfer Request message to the AMF. The message includes the PDU Session Resource Setup List to be delivered to the NG‐RAN transparently in step 8.
4. 4. The AMF acknowledges the request by sending the Namf_Communication_N1N2MessageTransfer Response message with a cause “attempting to reach UE.” The cause value implies that the AMF has started paging the UE.
5. 5. The AMF sends the PAGING message to the NG‐RAN node(s) belonging to the registration area in which the UE is registered.
6. 6. Then the NG‐RAN node(s) will page the UE.
7. 7. The UE performs the RRC connection establishment procedure and transitions to the connected mode. In response to the Paging message, the UE sends the SERVICE REQUEST message to the AMF. Since there is no UE‐specific association between the AMF and the NG‐RAN, the UE provides the NG‐RAN with the 5G‐S‐TMSI to ensure that the SERIVCE REQUEST message is routed to the correct AMF.
8. 8. The AMF sends the INITIAL CONTEXT SETUP REQUEST message to the NG‐RAN. The message includes the SERVICE ACCEPT message to be delivered to the UE transparently, PDU Session Resource Setup List that the AMF received in step 3, and some UE context, e.g. security context. The PDU Session Resource Setup List indicates QoS profiles of QoS flows in the PDU session and the uplink tunnel information towards the UPF.
9. 9‐10. The RRC connection is reconfigured to reactivate the user plane radio resources for the PDU session. The SERVICE ACCEPT message is delivered to the UE.
10. 11. The NG‐RAN acknowledges the INITIAL CONTEXT SETUP REQUEST message. The message includes the PDU Session Resource Setup Response List. The PDU Session Resource Setup Response List contains the downlink tunnel information towards the NG‐RAN and list of accepted QoS flows.
11. 12. The AMF sends the Nsmf_PDUSession_UpdateSMContext Request message to the SMF. The message includes the PDU Session Resource Setup Response List.
12. 13. The SMF updates the UPF with the downlink tunnel information towards the NG‐RAN. Now the downlink PDU can be delivered to the UE via the NG‐RAN.

5.6.1 Overview

This section on RRC Inactive state mobility covers the following topics:

• Cell selection and reselection
• Paging/Notification from RAN
• RAN Notification Area
• RRC Inactivation
• RRC Activation
• Need for configurability of RRC Inactive state
• Benefits of RRC Inactive state

To achieve a seamless UE state transition in the 5G system, a connectivity solution where the UE is kept “always‐on” from Core Network (CN) perspective (control and user plane) was defined. Once the UE is registered to the network, the connection to the CN is kept alive. However, the RAN can suspend the RRC connection when there is inactivity. The RAN also has the opportunity to configure differently the behavior of UEs with different service requirements during times of inactivity.

The new RRC Inactive state has many features of the existing LTE_IDLE state, such as low activity towards network and UE based mobility using the cell reselection procedure. The need for configurability of the RRC Inactive state is motivated by 5G use cases which have highly diverse, and sometimes contradictory requirements in terms of reliability, mobility, latency, bandwidth, security and privacy, battery life etc. For example, the E2E latency requirement varies from <1 ms for use cases with ultra‐low latency requirement such as industrial automation, to latencies from seconds to hours for use cases like massive (low‐cost, long‐range and low‐power) MTC. The battery life requirement is irrelevant in some use cases like autonomous driving, where the device can get unlimited energy from the car, whereas the battery life requirement for battery operated devices ranges from three days for smartphones up to 15 years for a low‐cost MTC device.

Allowing a device to use a specific RRC Inactive state configuration enables flexibility to the state handling mechanism. The requirements in Ref. [19] for state transition optimization for ultra‐low complexity, power constrained, and low data‐rate Internet of Things devices can be taken as an example of network slice specific state handling configuration. However, the relevant solutions may not necessarily be applicable for all use cases, e.g. autonomous driving of vehicle.

If parts of the RAN context are available in the network and UE, some of the potential RRC Inactive state configuration options include:

• Mobility/location tracking management configuration. RAN based mobility and location tracking, single/multiple cell‐level tracking.
• Measurement configuration. Measurement configuration for cell reselection, camping, etc. considering the existence of multiple air interface variants.
• Camping configuration. Single/multiple‐RAT camping, capacity based camping, etc.
• State transition/system access configuration. State transition and RACH access optimizations.
• Synchronization configuration. DL and/or UL synchronization.

5.6.2 Cell Selection and Reselection

During low activity periods the UE will evaluate the network conditions and select the suitable cell for camping based on UE measurements and according to rules given by the network. With the NR RRC state machine, the cell reselection is applicable in both RRC_IDLE state and RRC_INACTIVE state, while the cell selection is applicable only in RRC_IDLE state. The NAS controls the RAT selection and is looking for the selected PLMN, which is associated with the current RAT. The UE shall select a suitable cell based on RRC_IDLE state measurements and cell selection criteria. UE regularly evaluates the measurements against cell reselection criteria and searches for a better cell for camping. If a better cell is found, that cell is selected. During the normal service provisioning, the UE will decode the control channels to receive the system information of PLMN and receive the registration area information, as well as other AS and NAS Information. Identification of the cell where the UE should be camping is based on the reselection criteria, where the intra‐frequency reselection is based on ranking of cells and inter‐frequency reselection is based on absolute priorities. The cell reselection can be also UE speed dependent where the fast moving UEs are either preferred to stay at macro cell layer and/or perform the cell reselection faster.

Beam‐mobility and multi‐beam operation will also need support during low activity periods. For cell reselection in multi‐beam deployment, the number of beams and the measurement quantity for cell reselection is computed within the cell beams of the same synchronization signal (SS)/physical broadcast channel (PBCH) block per cell. The linear average of the power values from one beam up to the maximum number of highest beam measurement quantity is derived with values above the threshold, thus indicating the cell reselection criteria.

5.6.3 Paging and Notification from RAN

In 5G, the UE can be paged from 5GC or NG‐RAN. For paging occasions, the UE monitors the Paging Channel (PCH) only during the periods which are not configured with use of discontinuous reception (DRX) to reduce power consumption. When the UE is in RRC_INACTIVE state, the paging can be initiated by both 5GC and NG‐RAN and for this purpose the UE needs to monitor both RAN‐initiated and CN‐initiated paging information from paging control channel (PCCH). To minimize complexity of paging from two different sources, the paging occasions of NG‐RAN and 5GC should overlap and therefore the same paging mechanism can be used. As described in Figure 5.23, the RRC_INACTIVE state is configurable with service specific requirements thus allowing paging DRX cycle to be configurable either for power saving (long cycle) or low latency (short cycle). As the UE monitors both 5GC and NG‐RAN initiated paging, the DRX configuration will be provisioned to UE with the paging initiator specific method. The 5GC‐initiated paging and related DRX cycle is configurable via system information, while the NG‐RAN can configure a UE specific DRX cycle to be used for RAN‐initiated paging. During the paging occasions the UE periodically wakes up and monitors the physical downlink control channel (PDCCH) channel to check for the presence of a paging message. When the PDCCH indicates paging RNTI (P‐RNTI) in the paging message, then the UE demodulates the PCH to see if the paging message was directed to it or someone else.

5.6.4 RAN Notification Area

The mobility procedure during the RRC_INACTIVE is optimized for the RAN based location tracking, which means that the UE in the RRC_INACTIVE state can be configured with a RAN Notification Area (RNA). The RNA is the area where the UE can move in RRC_INACTIVE state without notifying the network about the cell reselections. RNA is equivalent to RAN based paging, e.g. if the paging initiator is NG‐RAN, then the UE is paged only in the configured RNA. This approach provides significant savings in terms of control plane signaling compared to paging always from core network over the whole tracking area, perhaps consisting of hundreds of cells. The RNA is flexible supporting stationary UEs and moderately fast moving UEs in low activity periods. Therefore, RNA can cover a single cell or multiple cells and the area falls within the registration area of 5GC. There are several ways to provision the UE with RNA. Typically, a stationary or slowly moving UE will get a configuration via list of cells, e.g. at least one cell. There is a trade‐off between small and larger RNAs and for above pedestrian speeds the UE could be configured with a list of RNAs or a RAN area ID, where a RAN area ID is a subset of a CN Tracking Area or equal to a CN Tracking Area. If the UE is not configured with a list of cells, then it needs to read the system information and use the broadcasted a RAN area ID for RNA updates.

5.6.5 RRC Inactivation

RRC Inactivation will follow the expiration of inactivity timer, which indicates to network that the UE will benefit from configuration to RRC_INACTIVE low activity period and power saving. After the RRC inactivation, UE remains in CM‐CONNECTED state and gets a configuration for RAN Notification Area where the UE can move without notifying NG‐RAN network. The UE Context is stored in the last serving gNB with the serving AMF and UPF keeping their respective UE‐associated N2 and N3 tunnels available. The NG‐RAN node may configure the UE with a periodic RNA Update timer value at transition to RRC_INACTIVE.

The RRC inactive state of a UE can be configured based on the characteristics of the service(s) provided to the UE if such information is available at the network. According to Figure 5.25, RRC Inactive state is included in the Suspend message (see Ref. [20]). If the UE has multiple services or purposes, e.g. a device with multiple concurrent services, then the configuration might be done based on the service with the most stringent requirement state is included in the Suspend message. If the UE has multiple services, e.g. a device with multiple concurrent services, then the configuration might be done based on the service with the most stringent requirements.

5.6.6 RRC Activation

The RRC State transition from RRC_INACTIVE state to RRC_CONNECTED state can be triggered by UE or the network, e.g. when the UE low activity period is over and there is data available for uplink transmission or if the network must page the UE for incoming downlink data. The RRC activation described in Ref. [21] specifies the UE and network triggered transition from RRC_INACTIVE to RRC_CONNECTED.

In general, when the UE is Inactivated, the UE is provided by the last serving gNB with the I‐RNTI identifier which is used to identify during the time of activation. This enables the current serving gNB to resolve the anchor gNB and request for the UE Context data. After the RRC activation the path switch is requested from the AMF and the resources are released from the last serving gNB.

Network initiated state transition from RRC_INACTIVE to RRC_CONNECTED involves the RAN paging procedure with the relevant trigger, e.g. there is incoming DL user plane data, DL specific signaling from 5GC, update of critical system information, etc. The RAN based paging is distributed on the need basis in RAN so that the UE can be paged only from the cells under the last serving gNB footprint, or by distributing the paging over Xn interface to other gNBs, which belong to the same configured RNA.

When the UE has been successfully paged from RAN, the U attempts to activate the RRC connection by sending the RRC Connection Resume Request to the network.

5.7.1 Overview

The millimeter wave (mmWave) frequencies identified for 5G enable significant bandwidths for next‐generation cellular mobile terminals, various new services in vertical applications, and industry deployments. However, radio links using mmWave frequencies are prone to quick channel variations and radio link failures due to deep free‐space pathloss and absorption. These challenges can be addressed using beam forming directional antennas at the UE and gNB to improve the link budget for better cell coverage. The application of beam forming requires beam management framework to align the transmitter and the receiver beams, which calls for beam formed initial access, beam selection, beam tracking and fast beam failure recovery to identify and maintain the optimal selection of beams to connect the UE and gNB during active data transmission. The beam forming approach chosen for NR allows beam level mobility with low‐cost analog antenna array beam‐sweeping.

5.7.2 Beam Management

Beam level mobility, e.g. intra‐cell mobility in NR, refers to mobility procedures within the same NR cell and can be done without higher level signaling procedures. That is, Beam level mobility does not require explicit L3 RRC signaling to be triggered and RRC is not required to know which beam is being used at a given point in time.

Multi‐beam operation in NR uses synchronization signal block, SS block (SSB), which comprises a primary synchronization signal (PSS), a secondary synchronization signal (SSS), and a PBCH. The UEs are receiving these signals to operate the beam management functions and a given SSB is repeated within an SS burst set to define the gNB beam‐sweeping transmission. Beam sweeping provisions the cell area with a set of beams in spatial domain. The transmitted beam interval and directions are specified and parameters are provided to UEs using system information and dedicated signaling. For example, during the initial cell selection, the UE assumes a default SS burst set periodicity of 20 ms which is repeated for gNB beam‐sweeping transmissions. In general, an SSB is a group of four orthogonal frequency‐division multiplexing (OFDM) symbols in time and 240 subcarriers in frequency where the Demodulation Reference Signal (DMRS) are associated with the PBCH to measure the SSB. The SSBs are grouped into the first 5 ms of an SS burst. Beam measurement will express the reception of SSB in beams in terms of Reference Signal Received Power (RSRP) of the received power with synchronization signals, Reference Signal Received Quality (RSRQ). Beam refinement is the procedure when the optimal set of beams is selected and configured for beamformed communication. Beam reporting sends the measurement information to network with the power and quality of the beamformed signals and the selection of beams is done during the beam refinement phase.

Narrow beam Channel State Information Reference Signal (CSI‐RS) can be used for mobility management purposes in RRC_CONNECTED state. CSI‐RS are configured to UE to achieve better measurement accuracy and better cell range when the same transmitted energy is applied to a narrower CSI‐RS beam compared to wide beam SSB beam. The CSI‐RS beam properties of serving and neighboring cells should include at least NR cell ID, slot configuration for CSI‐RS and the periodicity e.g. 5, 10, 20, 40 ms, as well as configurable numerologies and association between CSI‐RS and SSB for radio resource management (RRM) measurement. For beam management, it is possible to configure multiple CSI‐RS to the same SS burst so the UE can first obtain cell synchronization using the SS bursts, and then use that as a reference to search and refine for CSI‐RS resources.

Considering directional communications with beams, the best beams need to be periodically identified with radio link monitoring and beam management is used to maintain the alignment between the communicating nodes. For this purpose, SS‐ and CSI‐based measurement results can be jointly used to measure if the best beam is selected for communication. The UE measurement configuration can include both SSB(s) and CSI‐RS(s) for the reported cell(s) if both measurement types are available. Beam management is controlled by the Medium Access Control (MAC) protocol (configured by RRC) where the beam failure recovery procedure indicates to the serving gNB of a new SSB or CSI‐RS when beam failure is detected. Beam failure is detected by counting beam failure instance indication from the lower layers to the MAC entity.

In RRC_CONNECTED, when the UE measures the beams of a cell, in practice, it measures a subset of the available beams because the beams not pointing to the UE are typically not measurable or not countable to the measurement result. Measurement results are filtered at first on physical layer for beam level quality and then at L3 for cell quality, potentially from multiple beams. Cell quality from beam measurements is derived in the same way for the serving cell and for the non‐serving cells. Measurement reports may contain the measurement result of more than of the beams with the best value for measurement quantity, although using just the best beam typically represents the cell quality well when beam management is already done below RRC level. Network configures the beam measurements to be included in measurement reports. The possible reported values may contain only the beam identifier, the beam identifier with the measurement result, or no beam reporting.

For RRC_INACTIVE and RRC_IDLE users the beam management means selection of beamformed initial access allowing the UE to establish a physical link to access the network.

5.7.3 Beam Level and Cell Level Mobility

Just like in LTE, NR Release 15 specifies network controlled mobility to UEs in RRC_CONENCTED state, with the difference that the mobility is classified into cell level mobility and beam management, e.g. beam level mobility. Cell level mobility with beams refers to inter‐cell mobility with handovers requiring L3 RRC signaling for inter‐gNB handovers. To perform a cell level handover between two gNBs, the four‐step procedure [21] is needed where the source gNB initiates handover and issues a Handover Request over the Xn interface. The target gNB performs admission control and provides the target RRC configuration as part of the Handover Acknowledgement. The source gNB provides the RRC configuration to the UE in the Handover Command as part of the connection reconfiguration. The prepared RRC Reconfiguration message contains the information required to access the target cell, which includes the target cell ID, the new C‐RNTI, the target gNB security algorithm identifier. For beam mobility the information can include a set of dedicated RACH resources, the association between RACH resources and SSBs and the association between RACH resources and UE‐specific CSI‐RS configuration. Intention is to access the target without reading system information, so that the common RACH resources, target cell SIBs, etc. can also be included. When the Handover Command is executed, the RRC connection moves to the target gNB and the target gNB gets Handover Complete message from UE.

5.8.1 Overview

5G targets to address many different use cases. One of the more challenging ones is the case, where the user is moving at high velocity. Examples of this kind of situation are high speed trains and cars, where the passengers wish to keep seamless contact with the network and the critical vehicle communications should be maintained as well.

The 3GPP document TR 38.913 [6] specifies a scenario, where a train is moving at 500 km h⁻¹ with up to 300 passengers connected to each macro cell. This leads to frequent handovers for each user and a very high total number of handovers, even if we assume that only some of the users would be active. Furthermore, each handover should be executed within the short time the UE is within the coverage of both the source cell and the target cell. In this kind of high‐speed scenario, the physical layer of 5G needs to be able to tolerate a very high Doppler shift as well.

Another viable scenario would be a car running along a street, which is covered by both <6 GHz macro cells and > 6 GHz small cells. Since the small cells can use frequencies up to several tens of GHz, their coverage areas will be small and their edges sharp. High frequency radio signals don't experience much diffraction and thus an obstacle between the transmitter and the receiver can cut the signal very abruptly. Thus, for these frequencies, a user velocity of 50 km h⁻¹ would already be high speed.

Figure 5.26 illustrates how the received radio signal can fade away, when a UE in a slowly (30 km h⁻¹) driving car passes a street corner. The figure is based on simulation results presented in Ref. [22]. It shows for example that at 28 GHz the signal level can drop 12 dB in 30 ms, which can be sufficient to cut the connection in some situations.

5.8.2 Enablers for High Speed Mobility

In order, to facilitate a fast handover, where the UE can attach to the target cell before the connection to the source cell is lost, 5G System supports the following features:

1. The detection of the handover need is made as fast as possible. However, the decision to initiate a handover is a critical one. Handover is a heavy process and a decision to hand over to the wrong cell can lead to a long service interruption. Thus, careful filtering of the cell measurement results is still needed, which limits the speed of detecting a handover need.
2. Handover process itself should be made as fast as possible, because a high velocity UE will experience very frequent handovers, when traveling across many small cells. One way to achieve this is a handover without random access procedure. Upon receiving a handover request from the source cell, the target cell defines the scheduling for the UE and sends it via the source cell to the UE. Thus, the UE can access the target cell directly, without random access procedure.
3. The multi‐connectivity based intra‐frequency make‐before‐break handover, specified for 5G, is a more robust solution than the normal single connected handover. This is because the UE can attach to one or more candidate target cells, while the traffic is still served by the source cell. Thus, new cells can be prepared and added to the multi‐connectivity set of links as soon as they are available. After that, the switching of the traffic to one of the target cells can happen using a very fast and lightweight process. And if the selected target cell proves to be a bad one, the decisions can be reverted quickly. The traffic stuck in the wrong target cell will be retransmitted by another cell (or all cells) in the multi‐connectivity set of links. The cell measurements used for steering the switching of traffic can be lighter filtered and have faster response times than those used for triggering handovers. Alternatively, the most critical low volume traffic (URLLC) can be continuously replicated to all available links.
4. Inter‐frequency multi‐connectivity enables a scenario, where the UE is continuously connected both to high frequency small cell layer and to macro cell layer. Figure 5.27 illustrates this scenario. Traffic is normally served by the small cells, which typically have higher capacity and this capacity is shared by less users that that of the large macro cells. In case new small cells can't be added to the set of links early enough for a “fast moving” UE, its traffic is seamlessly switched to the macro cell layer.

5.9.1 URLLC Requirements

3GPP TS 22.261 [23] defines Ultra Reliable Low Latency Communications (URLLC) as a class of latency critical reliable communication service for e.g. the following use cases, which have 10 ms or less latency requirement:

• Motion control. Conventional motion control is characterized by high requirements on the communications system regarding latency, reliability, and availability. Systems supporting motion control are usually deployed in geographically limited areas but may also be deployed in wider areas (e.g. city‐ or country‐wide networks), access to them may be limited to authorized users, and they may be isolated from networks or network resources used by other cellular customers.
• Discrete automation. Discrete automation is characterized by high requirements on the communications system regarding reliability and availability. Systems supporting discrete automation are usually deployed in geographically limited areas, access to them may be limited to authorized users, and they may be isolated from networks or network resources used by other cellular customers.
• Automation for electricity distribution (mainly medium and high voltage). Electricity is also characterized by high requirements on the communications service availability. In contrast to the above use cases, electricity distribution is deeply immersed into the public space. Since electricity distribution is an essential infrastructure, it will, as a rule, be served by private networks.
• Intelligent transport systems. Automation solutions for the infrastructure supporting street‐based traffic. This use case addresses the connection of the road‐side infrastructure, e.g. road side units, with other infrastructure, e.g. a traffic guidance system. As is the case for automation electricity, the nodes are deeply immersed into the public space.
• Tactile interaction. Tactile interaction is characterized by a human being interacting with the environment or people, or controlling a UE, and relying on tactile feedback.
• Remote control. Remote control is characterized by a device being operated remotely, either by a human or a computer.

Low latency and high reliability are basically conflicting requirements. High reliability of data delivery is usually achieved by retransmitting the lost data. However, re‐transmissions take time and increase latency. This effect also impacts the data packets following the lost ones, since RAN is expected to rearrange the received packets and send them to the higher layers in the right order. Thus, the latency requirement should always be accompanied by a reliability requirement, which states the probability of a data packet being delivered within the stated latency.

3GPP TR 38.913 [6] specifies RAN latency as the time it takes to successfully deliver an application layer packet/message from the radio protocol layer 2/3 service data unit (SDU) ingress point to the radio protocol layer 2/3 SDU egress point via the radio interface in both uplink and downlink directions, where neither device nor Base Station reception is restricted by DRX. For URLLC, the target for average user plane latency should be 0.5 ms for UL, and 0.5 ms for DL. The target for maximum latency of a 32‐byte packet is 1 ms with 99.999% reliability.

3GPP TR 38.804 [24] specifies that the latency target of 1 ms with 99 999% reliability specified in TR 38.913 [6] should be met in case no cell change (e.g. handover) is needed. If a cell change is required, e.g. because of mobility, some packets may be delayed more. There is no maximum latency specified for this case, but a general statement that the abovementioned latency should be the target.

5.9.2 The Challenges of URLLC Mobility

In the steady state (no cell change) the main sources of user data latency are:

1. Air interface latency, mainly driven by the radio frame structure.
2. Buffering latency (e.g. at radio link control protocol, RLC).
3. Processing latency of each node.
4. Retransmission latency. In case the delivery over air interface of a data packet or a part of it fails, a retransmission is needed. The retransmitted packet will experience an extra latency, since the receiving entity must first detect a faulty or missing packet, send a retransmission request to the transmitting entity and then the packet (or a part of it) must be transmitted again. Since RAN has the requirement of in order delivery, all the subsequent packets need to wait, until the retransmission is ready (or retransmission timer expires), before they can be processed in the receiver re‐ordering function.
5. Transport network latency. Transport network latency especially impacts retransmissions, if the retransmission request and the actual retransmission travel long distances between RAN nodes.

The additional sources adding latency due to mobility:

1. Single connectivity handover – detach/attach. During a single connectivity handover, there will inevitably be a short service interruption, since the UE must first let go from the source cell, before it can access the target cell. This interruption will delay the delivery of the subsequent data packets.
2. Single connectivity handover – data forwarding. When the source cell initiates the handover, it may still have data in its buffers and new data may still be arriving from the core network UPF. Since the UE is no longer connected to the source cell, the source cell PDCP layer must forward the data to the target cell PDCP over the Xn (corresponds to X2 in LTE) until it stops receiving new data from the UPF and its buffers are empty. If the source cell PDCP and the target cell PDCP are not co‐sited, the forwarded data will travel through the transport network to the source cell. During this time, it is not available for transmission to the UE. Any new data, that the UPF has sent to the target cell directly, must wait for the forwarding to complete first.
3. Multi‐connectivity and make‐before‐break handover. A 5G multi‐connectivity capable UE can communicate with both the source cell and the target cell simultaneously. Thus, there is no service break in the air interface. Similarly, if the UE using multi‐connectivity links under the same PDCP instance, as presented in Figure 5.28a, there is no data forwarding either. But when the UE has traveled far enough, there will be a need to relocate the PDCP to a location providing better latency (and/or load conditions), as presented in Figure 5.28b. This relocation may introduce a service interruption depending on the selected relocation process.

5.9.3 Multi‐connectivity as a Solution for URLLC Mobility

As described in the previous paragraph, the only way to avoid additional user plane latency at the air interface during mobility events (or any event, which includes a change in a serving cell) is to deploy make‐before‐break handover (e.g. soft handover). In a make‐before‐break handover, the UE is simultaneously connected to both the source cell and the target cell. Consequently, it is basically a form of temporary multi‐connectivity. A UE carrying URLLC traffic is expected to deploy multi‐connectivity also, when stationary, and thus it is natural that make‐before‐break handover should be based on multi‐connectivity.

As described above, multi‐connectivity can avoid interruptions in the air interface, but it may have a challenge, when relocating PDCP using legacy single connectivity principles. The two basic options for PDCP relocation process are (not yet discussed in 3GPP specifications):

1. a. The UE hosts only one PDCP counterpart per bearer as in a legacy single connected handover. A new (target) PDCP instance is established in the network and the connections from it to the same RLC instances, which the source PDCP is using, are built. When relocation starts, the gateway stops sending data to the source PDCP and sends an end‐of‐data mark (EM) to it instead. Any new data the UPF receives, it will send to the target PDCP. When the source PDCP receives the EM, it will send its status (e.g. last used PDCP PDU serial number) to the target PDCP using the Xn interface. After receiving this information, the target PDCP starts to process the data it has received from the gateway. During the PDCP status forwarding phase neither of the PDCP instances is processing data and thus there is a service interruption.
2. b. The UE hosts separate PDCP counterparts for each network PDCP instance (source and target) per bearer. Thus, when the target PDCP receives data from the gateway, it can process it immediately and there is no service interruption. Since the UE is now (temporarily) receiving data through two PDCP counterparts, the EM sent by the UPF shall now be forwarded to the UE for keeping the data packets in the correct order. However, the delivery of the EM may sometimes fail. In that case the UE needs to wait until reordering timer expires, before it can start processing the data coming from the target PDCP counterpart. Thus, a failure in EM delivery will introduce a short interruption. However, it should be noted, that if the source PDCP used multi‐connectivity, when delivering the EM to the UE, its failure would be very rare.

Most often mobility events take place between cells on the same frequency. Consequently, a capability to communicate with two or more cells on the same frequency virtually at the same time is essential, to avoid transmission collisions and latency due to consequent retransmissions. This would benefit from MAC layer coordination to avoid interference problems between the links. However, this coordination doesn't need to be as strict as e.g. in CoMP [25]. It is sufficient that the MAC schedulers in each cell are given guidelines that prevent simultaneous UL and DL allocations on the same frequency band. In FDD and static TDD systems this is automatically the case. However, in a TDD system with dynamic DL/UL split, coordination would be beneficial. Secondly, simultaneous UL transmissions on the same radio frequency (RF) hardware would split the available transmit power and reduce maximum range. The MAC coordination function should avoid this as well.

5.10.1 Mobility Restrictions

Mobility restrictions are a set of functionalities exploited to restrict mobility handling or service access of a UE in the 5G system. They are supported by the UE, the NG‐RAN and the 5G core network and consist of service area restrictions, forbidden area management, RAT restriction, and core network restriction.

The service area restrictions consist of either an allowed area, or a non‐allowed area. The allowed area can contain up to 16 tracking areas or include all tracking areas in a PLMN. The non‐allowed area can contain up to 16 tracking areas. The UE can initiate any MM and SM procedures while camped on a cell within a tracking area belonging to the allowed area or not belonging to the non‐allowed area. On the other hand, while camped on a cell within a tracking area belonging to the non‐allowed area or not belonging to the allowed area, the UE is prohibited from performing the mobility and periodic registration update procedure or the service request procedure involving user plane resource reactivation except for emergency services or for responding to core network paging. In addition, the SM procedures are also prohibited.

For the forbidden area management, the UE manages a list of “5GS forbidden tracking areas for regional provision of service,” as well as a list of “5GS forbidden tracking areas for roaming.” The UE updates one of the lists whenever a REGISTRATION REJECT, SERVICE REJECT or DEREGISTRATION REQUEST message is received with the cause value “tracking area not allowed” or “roaming not allowed in this tracking area.” In a tracking area whose identity is included in one of the lists, the UE is not permitted to initiate any communication with the network.

The RAT restriction defines the RAT which a UE is not allowed to access in a PLMN. In a restricted RAT, a UE is not permitted to initiate any communication for the PLMN. During the handover, the NG‐RAN should determine the target RAT and target PLMN considering the RAT restrictions for PLMNs, if any.

Core network type restriction defines whether a UE can connect to 5G core network for a PLMN. During the registration, deregistration, or service request procedure, the UE disables capability to connect to 5G core network if the message includes the cause value “N1 mode not allowed.”

5.10.2 MICO Mode

A UE may indicate preference for mobile initiated communication only (MICO) mode during the registration procedure. Based on the UE preference, UE subscription information, and network policies, or any combination of them, network determines whether MICO mode is applied for the UE and indicates it to the UE during registration procedure. The UE and core network can re‐initiate or exit the MICO mode at subsequent registration procedure. The MICO mode needs to be applied explicitly in every registration procedure.

When the AMF applies MICO mode for a UE, the AMF considers the UE always unreachable while in idle mode. The UE in MICO mode is reachable for mobile terminated data or signaling only when the UE is in connected mode and for the PDU sessions that has been reactivated. The network rejects any request for downlink data delivery for an idle UE in MICO mode. The network also does not allow downlink transport over NAS for short message service (SMS), location services, etc.

A UE in MICO mode does not listen to paging while in the idle mode. An idle UE in MICO mode may stop any access stratum procedures, until the UE transitions from idle to connected mode due to one of the following triggers:

1. – a change in the UE (e.g. change in configuration) requiring the registration procedure;
2. – expiry of the periodic registration timer; and
3. – pending mobile‐originated data or signaling.

5.11.1 Inter‐System Change in Single Registration Mode

The pre‐condition for this scenario is that the UE is single registered in EPS or 5GS, maintains only NAS state at any time (Figure 5.29).

1. 1. The E‐UTRAN or NG‐RAN decides to hand the UE over to the other type of RAN, i.e. NG‐RAN or E‐UTRAN and sends the HANDOVER REQUEST message to the MME or AMF, respectively. The message includes the target RAN identity and a transparent container.
2. 2. In the case of handover from 5GS to EPS, after receiving the HANDOVER REQUEST message from the NG‐RAN, the AMF invokes the Nsmf_PDUSession_ContextRequest service towards the PGW‐C + SMF to obtain the SM contexts including the mapped EPS bearer contexts.
3. 3. The source CN sends the Forward Relocation Request message to the target CN, selected considering the target RAN identity. The Forward Relocation Request message includes the MM context, the target RAN identity, and the transparent container.
4. 4. The AMF or MME obtains the uplink tunnel information required for the target RAN. In the case of handover from EPS to 5GS, the AMF invokes towards the PGW‐C + SMF the Nsmf_PDUSession_UpdateSMContext service. In the case of handover from 5GS to EPS, the MME exchanges the Create Bearer Request and Response messages with the S‐GW.
5. 5. The HANDOVER REQUEST message is sent to the target RAN identified by the target RAN identity. The message includes the transparent container and uplink tunnel information.
6. 6. The target RAN sends the acknowledgement message back to the target CN. The message contains the HandoverCommand message and downlink tunnel information for the target CN. The tunnel information is associated with the PDU sessions or bearers that are accepted by the target RAN.
7. 7. In the case of handover from EPS to 5GS, the AMF invokes towards the PGW‐C + SMF the Nsmf_PDUSession_UpdateSMContext service to update the PGW‐C + SMF with the downlink tunnel information. The PGW‐C + SMF provides the downlink tunnel information to the PGW‐U + UPF.
8. 8. The Forwards Relocation Response message is sent to the source CN. The message includes the HandoverCommand message.
9. 9, 10. The HandoverCommand message is forwarded to the UE.
10. 11. The UE completes the RRC connection reconfiguration with the target RAN.
11. 12. The target RAN notifies that the handover on the radio side is completed towards the target CN by sending the HANDOVER NOTIFY message.
12. 13. The target CN confirms the completion of the relocation.
13. 14. Then the source CN acknowledges the completion of the relocation.
14. 15. The target CN informs that the handover is completed towards the PGW‐C + SMF. In the case of handover from EPS to 5GS, the AMF invokes the Nsmf_PDUSession_UpdateSMContext service and in the case of handover from 5GS to EPS, the MME and S‐GW exchange the Modify Bearer Request and Response messages respectively with the S‐GW and the PGW‐C + SMF. During the exchange of the Modify Bearer Request and Response message, tunnel information is traded in addition. The PGW‐C + SMF interacts with the PGW‐U + UPF accordingly.
15. 16. The mobility registration update (in the case of handover from EPS to 5GS) or tracking area update (in the case of handover from 5GS to EPS) is performed and unnecessary resources are released.

5.11.2 Inter‐System Change in Dual Registration Mode

The pre‐condition for this scenario is that the UE is dual registered in EPS and 5GS (Figure 5.30). The UE can maintain NAS states independently in EPS and 5GS. The network may or may not support N26. It is up to UE to decide which system to use for which session but it is up to the network to determine which session is admitted in the system based on regular SM procedures in the respective systems. It is up to the network and operator policy to determine for which PDU Session and/or packet data network (PDN) connection, service continuity is offered for inter system mobility. This information is expected to be provided to the UE as part of registration procedure and corresponding session establishment procedures in the respective system. It is also up to the UE to decide which session to move from one system to another.

1. The UE decides to move a PDN connection or a PDU session from one system to the other. As shown in step 1‐A, if the UE wants to move a PDN connection in the EPS to the 5GS, the UE performs the mobility registration update procedure (see Figure 5.23) in case the UE is not already registered to the 5GS. During the mobility registration update procedure, the home subscriber server, HSS + UDM does not send cancel location to the MME so that the UE can be kept registered to both systems. Then the UE initiates the UE‐requested PDU session establishment procedure as shown in step 1‐B. In the PDU SESSION ESTABLISHMENT REQUEST message, the UE sets the request type to “Existing PDU Session.” Otherwise if the UE wants to move a PDU session in the 5GS to the EPS, the UE performs the attach procedure as shown in step 1‐C in case the UE is not already registered to the EPS. During the attach procedure, the HSS + UDM does not send cancel location to the AMF so that the UE can be kept registered to both systems. The PDN CONNECTIVITY REQUEST message piggy‐backed in the ATTACH REQUEST message includes the request type set to “Handover.” If the UE is already registered to the EPS, the UE directly initiates the UE requested PDN connectivity procedure as depicted in step 1‐D. In the PDN CONNECTIVITY REQUEST message, the UE sets the request type to “Handover.”
2. The resources in the source system are cleaned up, i.e. a PDU session moved to the EPS or a PDN connection moved to the 5GS is released in the source system.