Introduction
In this blog, we will delve into the latest updates to 5G signalling procedures as of 2024, focusing on the Initial Context Setup, Xn Based Handover, and RRC Connection Release procedures. These procedures are crucial for maintaining efficient communication between the User Equipment (UE) and the network, ensuring secure and reliable connectivity in the 5G ecosystem.
Initial Context Setup In 5G Signalling Procedures
In 5G Signalling procedures The Initial Context Setup procedure can be completed after the UE has established an RRC Connection and has thus already configured SRB 1. The Initial Context Setup procedure is used to
create a UE context at the Base Station
activate ciphering and integrity protection
configure SRB 2
configure one or more Data Radio Bearers (ORB)
Procedure Overview
Figure below illustrates the Initial Context Setup procedure in combination with the RRC Connection Setup procedure assuming a Centralised Unit (CU)- Distributed Unit (DU) split Base Station architecture. This architecture requires Fl Application Protocol (FI AP) signalling between the CU and DU. The RRC Connection Setup procedure and the NGAP: Initial UE Message are described in the previous blog (Part-3).
The Base Station uses the 'UEContextRequest' flag within the NGAP : Initial UE Message to request that the AMF starts the Initial Context Setup procedure. The content of the NGAP: Initial Context Setup Request is presented in Table below.
The 'Old AMF' identity is included if the UE's control plane signalling connection has been re-routed from one AMF to another AMF. The AMF originally selected by the Base Station may determine that it cannot support the UE, e.g. due to not supporting the set of requested Network Slices. In this case, the original AMF may forward the initial NAS message directly to another AMF. The new AMF then becomes responsible to completing the Initial Context Setup procedure.
The UE Aggregate Maximum Bit Rate' (UE-AMBR) is included if the 'PDU Session Resource Setup Request List' is included. The UE-AMBR is a subscription parameter which is retrieved from the User Data Management (UDM) Network Function. It defines the maximum permitted bit rate summed across all non-GBR QoS Flows. It is not applicable to GBR QoS Flows.
The 'Core Network Assistance Information' includes the 'UE Identity Index' which the Base Station uses to calculate the UE's Paging Frame. The AMF derives the 'UE Identity Index' using the expression '5G-S-TMSI mod 1024'. This generates a bit string of length 10. The 'Core Network Assistance Information' can also include a UE specific paging DRX cycle duration, a Mobile Initiated Connection Only (MICO) flag and an expected UE behaviour in terms of mobility. The AMF also uses this field to specify the periodic registration update timer for the UE.
The 'PDU Session Resource Setup Request List' can be used to request the allocation of resources for one or more PDU sessions. For example, this field can be used to request the resources for a default PDU Session for transferring data and a default PDU Session for transferring IMS signalling. The 'PDU Session NAS PDU' is transparent to the Base Station and can be forwarded to the UE within the subsequent RRCReconfiguration message. The 'PDU Session Resource Setup Request Transfer' field provides the Base Station with information regarding the GTP-U tunnel to be used when transferring uplink user plane data towards the UPF. It also specifics the set of QoS Flows belonging to the PDU Session, the PDU Session type (1Pv4, 1Pv6, 1Pv4v6, Ethernet, Unstructured) and the security requirement in terms of ciphering and integrity protection. In addition, a PDU Session Aggregate Maximum Bit Rate can be specified.
The 'UE Security Capabilities' provides the Base Station with information regarding the UE capability in terms of ciphering and integrity protection. This assumes that the AMF has stored UE _capability information previously obtained from the UE. The 'Security Key' allows the Base Station to derive the keys for both ciphering and integrety protection. These fields provide the Base Station with sufficient information to start the RRC Security Mode procedure.
The 'Mobility Restriction List' can be used to specify a set of Equivalent PLMN which the UE is permitted to access. It can also be used to specify restricted Radio Access Technologies (RAT), Forbidden Area Information and Service Area Information. Forbidden Area Information can specify Forbidden Tracking Area Codes, whereas Service Area Information can specify Not Allowed Tracking Area Codes. The former impacts cell reselection behaviour whereas the latter does not impact cell reselection behaviour.
The 'UE Radio Capability' provides the Base Station with the UERadioAccessCapabilitylnformation RRC message. It is assumed that the Radio Access Network has previously retrieved this information from the UE and it has then been forwarded to the AMF. The AMF stores the UE Capability information to avoid having to re-request it each time the UE enters RRC Connected mode.
The 'Index to RAT/Frequency Selection Priority' (RFSP) can be used in the same way as the 'Subscriber Profile ID (SPrD) for RAT/Frequency Priority' belonging to the 4G system. Both define a pointer within the range 1 to 256 which is linked to the user's subscription. The Base Station can use the value to configure UE specific mobility rules, e.g. to allocate a specific set of Absolute Priorities for Idle mode cell reselection, or for selecting a specific set of target carriers for inter-frequency handover.
The 'Masked IMEISV' can be used to identify a UE model, without identifying the individual UE. The Base Station can use this information if there is a requirement to apply specific rules to some UE models. The 'Masked fMEISV' has the last 4 digits of the Serial Number (SNR) set to 1 to avoid exposing the full UE identity.
The 'Emergency Fallback Indicator' can be used to indicate that either EPS Fallback or RAT fallback can be performed for the purposes of an emergency call.
The 'RRC Inactive Transition Report Request' can be used to request the Base Station to forward an NGAP: RRC InactiveTransition Report if the UE is subsequently moved to the RRC Inactive state. This allows the AMF to adjust its behaviour to account for the RRC Inactive state. For example, it may be necessary to increase supervision timers to account for the increased delay associated with contacting the UE (it is necessary to send an RRC: Paging message to the UE and then move the UE back to RRC Connected mode before transferring any downlink signalling or data).
The 'UE Radio Capability for Paging' provides the Base Station with the UERadioPaginglnformation RRC message. It is assumed that the Radio Access Network has previously retrieved this information from the UE and it has then been forwarded to the AMF. The information specifies the set of operating bands which the UE supports for the paging procedure.
The 'Redirection for Voice EPS Fallback' field can be used to specify that both the UE and AMF support EPS Fallback for the TMS voice service.
Base Station CU and DU Interaction
The Base Station CU uses the NGAP: Initial Context Setup Request to generate the FIAP: UE Context Setup Request which is then forwarded to the DU. This FI AP message requests the DU to setup resources for both SRB 2 and the set of DRB required by the PDU Sessions listed within the NGAP message. It also provides the DU with UE capability information and a transport network layer address for the uplink GTP-U tunnel between the DU and CU.
The FIAP: UE Context Setup Request also includes an RRC Container which encapsulates the RRC: Security Mode Command ,i.e. this message is generated by the CU but is forwarded to the DU for scheduling and transmission towards the UE. The content of the SecurityModeCommand is presented in Table below. It specifics the ciphering and integrity protection algorithms to be used for Access Stratum Security.
The UE responds with a SecurityModeComplete message which serves as a simple acknowledgement without any information content.
The Base Station DU forwards the SecurityModeComplete to the CU within an FI AP: UL RRC Message Transfer.
The DU also generates a response for the FlAP:UEContextSetupRequest. This response specifies the SRB and DRB which have been successfully setup. It can also specify any SRB or DRB have it has failed to setup. In addition, the DU uses this message to provide the CU with a transport network layer address for the downlink GTP-U tunnel between the CU and DU.
The CU then proceeds to generate the RRC Reconfiguration message which is used to configure SRB 2 and these to DRB at the UE. This message is forwarded to the DU from where it is scheduled and transmitted to the UE using SRB 1. The UE responds with an RRCReconfigurationComplete which is returned to the CU.
The overall procedure is completed by the CU forwarding an NGAP: InitialContextSetupResponse to the AMF. The content of this message is presented in Table below. It is used to provide a list of PDU Session resources which the Base Station has successfully setup and a list of PDU session resources which the Base Station has failed to setup.
The 'PDU Session Resource Setup Response Transfer' field is provided for each of the successful PDU Session resources. This field is transparent to the AMF and is forwarded to the SMF. It provides a transport network layer address for the downlink GTP-U tunnel between the UPF and the Base Station CU.
The 'PDU Session Resource Setup Unsuccessful Transfer' field is provided for each of the PDU Session resources which the Base Station failed to setup. This field is transparent to the AMF and is forwarded to the SMF. It provides a cause for the failed setup procedure.
Xn Based Handover In 5G Signalling Procedures
The Xn based handover procedure allows the primary serving cell to be changed from one Base Station to another Base Station, when those Base Stations are connected using an Xn interface. An 'N2 based' handover can be used when the Xn interface is not available (N2 is the logical Reference Point between the Base Station and AMF so this corresponds to using NGAP signalling across the NG-C interface for the handover procedure).
Figure below illustrates the signalling procedure for an Xn based handover. This example assumes that the handover procedure has been triggered by an RRC: MeasurementReport from the UE. Alternatively, the handover could be triggered by the Base Station. For example, a load based handover could be triggered by the Base Station although this may also involve UE measurement reporting to verify the coverage of the target cell.
Handover Phases
The overall handover procedure is divided into three phases: Handover Preparation, Handover Execution and Handover Completion. The first two phases only involve the Radio Access Network, whereas the third phase also involves the Core Network. Network statistics typically allow the performance of each phase to be quantified. Overall handover performance should be based upon a combination of all three phases.
The content of the XnAP: Handover Request is presented in Table below. The source Base Station allocates the 'Source NG-RAN Node UE XnAP Identity' to the UE associated signalling procedure across the Xn interface.
The 'Cause' value is typically set to 'Handover Desirable for Radio Reasons' if the handover has been triggered by an Event A3 measurement report. Alternatively, it may be set to 'Time Critical Handover' if the handover has been triggered by Event A5. There is also a cause value of' Reduce Load in Serving Cell' which can be used for load based handover procedures, and a value of 'Resource Optimisation Handover' which can be used when distributing load across neighbouring cells.
The 'Target Cell Global Identity' is extracted from the database of neighbour relations at the source Base Station. In general, the UE will identity the target cell within an RRC MeasurementReport using a Physical layer Cell Identity (PCI). The Base Station is then responsible for mapping that PCI onto a specific target cell. This mapping requires that all neighbour relations belonging to a specific cell have a unique PCI, i.e. optimal PCI planning avoids the possibility of PCI confusion.
The 'Globally Unique AMF Identity' (GUAMI) provides the target Base Station with the identity of the AMF which is being used to serve the UE.
The 'UE Context Information' provides the target Base Station with information regarding the PDU Sessions to be relocated during the Handover procedure. The 'NG-C UE associated Signalling Reference' is provided to allow the target Base Station to address the connection when sending the NGAP: Path Switch Request to the AMF during the Handover Completion phase. The 'Signalling TNL association address at source NG-C side' provides an IP address for the AMF signalling connection. The 'PDU Session Resources to be Setup List' provides the TP address and GTP-U TEID for the uplink data transfer towards the UPF. It also specifies the PDU Session and the associated set of QoS Flows. The 'RRC Context' includes the HandoverPreparationlnformation message specified by 3GPP TS 38.331
The target Base Station applies its AdmissionControl checks after receiving the XnAP: Handover Request. These checks may account for the availability of radio resources, hardware resources and transport resources. The target Base Station can then proceed to complete the Handover Preparation phase by returning the XnAP: Handover Request Acknowledge presented in Table below.
The 'PDU Session Resources Admitted List' includes transport layer information (IP address and GTP-U TEID) which allows the source Base Station to start forwarding user plane data across the Xn interface. The 'Target NG-RAN Node To Source NG-RAN Node Transparent Container' includes the HandoverCommand message specified by 3GPP TS 38.331. This message encapsulates the RRCReconfiguration message which is to be sent to the UE. The RRCReconfiguration message can include one or more dedicated PRACH preambles to allow Contention Free access to a beam belonging to the target cell.
The source Base Station extracts the RRC Reconfiguration message and transmits it to the UE. The source Base Station also forwards an XnAP: SN Status Transfer message to the target Base Station (presented in Table below). This message is used to provide the target Base Station with information regarding the Sequence Number status at the PDCP layer. The 'UL COUNT' value specifies the Sequence Number of the first missing uplink SDU, whereas the DL COUNT' value specifies the next Sequence Number to be allocated to a downlink SDU. The 'Receive Status of UL PDCP SDU' can be used to provide a bitmap where each '0' corresponds to a missing PDCP SDU and the bit position corresponds to a Sequence Number which follows the first missing uplink SDU.
The downlink data which is forwarded across the Xn interface is buffered at the target Base Station until the UE completes theRandom Access procedure and forwards the RRCReconfigurationComplete message. At this stage, the UE is connected to the target Base Station and the Handover Execution phase has been completed. The target Base Station is able to forward uplink data towards the UPF but downlink data is still sent to the source Base Station from where it is forwarded across the Xn interface.
The Handover Completion phase is responsible for requesting the UPF to move the downlink data path from the source Base Station to the target Base Station. The target Base Station initiates this phase by sending an NGAP: Path Switch Request to the AMF. The content of this message is presented in Table below.
The 'Path Switch Request Transfer' and 'Path Switch Request Setup Failed Transfer' fields are transparent to the AMF. These fields are forwarded to the SMF because the SMF is responsible for managing the UPF. The AMF forwards these fields by encapsulating them within an 'Update SM Context' service request message which is forwarded using an HTTP POST method. This service request procedure is specified within 3GPP TS 29.502.
The 'Path Switch Request Transfer' field specifies the downlink transport layer information for the target Base Station (IP address and GTP-U TEID). The SMF uses a GTPv2-C: Modify Bearer Request to forward this information to the UPF. The UPF acknowledges the request using a GTPv2-C: Modify Bearer Response. These GTPv2-C messages arc specified within 3GPP TS 29.274.
The SMF provides an acknowledgement to the AMF to indicate that the service request has been completed, and this acknowledgement is forwarded to the target Base Station using an NGAP: Path Switch Request Acknowledge message. At this stage, the connection has completely moved across to the target Base Station in both the uplink and downlink directions. This means that the source Base Station is now able to release the resources it has been using for the connection. The target Base Station triggers the release procedure by sending an XnAP: UE Context Release message.
RRC Connection Release In 5G Signalling Procedures
The RRC Connection Release procedure can be used to:
Release an RRC Connection by moving a UE from RRC Connected to RRC Idle.
Suspend an RRC Connection by moving a UE from RRC Connected to RRC Inactive.
Release an RRC Connection by moving a UE from RRC Inactive to RRC Idle.
The Base Station is permitted to move a UE from RRC Connected to RRC Inactive if it has already setup SRB 2 and at least one Data Radio Bearer (DRB).
Figure below illustrates a Base Station initiating an RRC Connection Release procedure to move a UE from RRC Connected to RRC idle. This procedure could be triggered by the expiry of a UE specific inactivity timer. The RRC Release message instructs the UE to move to RRC Idle. The UE is permitted up to 60 ms to acknowledge this message at the MAC and RLC layers before following the instruction to move to RRC Idle. The Base Station uses the NGAP: UE Context Release Request message lo request the AMF to initiate the NGAP UE Context Release procedure. This releases the UE context at the Base Station, while the AMF maintains the UE context as long as the UE remains registered with the 5G Core Network.
Figure below illustrates an AMF initiating an NGAP UE Context Release procedure which results in the UE being moved to RRC Idle. This procedure can be triggered after the completion of a NAS MobiIity Registration Update.
Table below presents the content of the RRC Release message. The redirected Carrier lnfo allows the Base Station to instruct the UE to complete an RRC Release with Redirection when moving towards either RRC Idle or RRC Inactive. RRC Release with Redirection specifies the target carrier for cell selection. The Base Station can redirect the UE towards an NR carrier or an E-UTRA(LTE) carrier. In the case of NR, the UE is provided with the NR-ARFCN belonging to the SS/PBCH Blocks, the subcarrier spacing of the SS/PBCH Blocks and the timing of the SS/PBCH Blocks. In the case of EUTRA, the UE is provided with the ARFCN and the Core Network type.
The cellReselectionPriorities field allows the Base Station to allocate dedicated Absolute Priorities for cell reselection in RRC Idle and RRC Inactive. Priorities can be specified for up to 8 E-UTRA carriers and up to 8 NR carriers. The T320 timer can be used to limit the time that the dedicated Absolute Priorities rename valid. The UE reverts to using the Absolute Priorities broadcast by the System Information when T320 expires.
Inclusion of the suspendConfig indicates that the UE should move to RRC Inactive rather than RRC Idle. The UE is allocated an Inactive-RNTI (1-RNTI) which can be used to identify both the UE and the serving Base Station while the UE remains within the allocated RAN Notification Area (RNA). Figure below illustrates the use of an RRCRelease message to move a UE to RRC Inactive. In this example it is assumed that the AMF requested notification of the RRC state transition within the NGAP: Initial Context Setup Request.
The deprioritisationReq field allows either the current RF carrier to be deprioritised, or the set of all NRRF carriers to be deprioritised. Deprioritisation impacts the cell reselection procedure and means that the UE assumes an Absolute Priority for the targeted RF carrier(s) which is lower than any of the remaining carriers. The UE continues to apply deprioritisation if the UE moves to another Radio Access Technology (RAT). Deprioritisation information is discarded upon expiry of the T325 timer which is set equal to the value of the deprioritisation Timer.
If the waitTime is included, the UE starts timer T302 with its expiry value set equal to the waitTime. With the exception of Access Categories 0 and 2, all connection attempts are access barred until T302 expires. Access Categories 0 and 2 correspond to mobile terminated access and emergency access respectively. In the case of mobile terminated access, the network is responsible for controlling access by preventing the transmission of paging messages if necessary. T302 is stopped if the UE completes cell reselection so in that case, the UE is permitted to attempt an RRC Connection Setup with the new serving cell.
Conclusion
The Initial Context Setup, Xn Based Handover, and RRC Connection Release procedures are essential components of 5G signalling, each playing a critical role in maintaining secure and efficient communication within the network. As the 5G ecosystem continues to evolve, understanding these procedures ensures that network operators can optimize connectivity and provide seamless service to users. The updates in 2024 reflect the ongoing advancements in 5G technology, aiming to enhance the robustness and reliability of mobile communications.
References
Comments