In the previous posts of this series I described O-RAN interfaces and protocols, connection establishment and connection release procedures. Now it is time to look at handovers.
As mentioned in one of the earlier posts the gNB-CU CP will be in charge of controlling hundreds of gNB-DUs in a similar way like the 3G RNC was in charge of controlling hundreds of UMTS NodeBs. As a result the most common 5G SA intra-system handovers will be intra-gNB handovers. These handovers can further be classified into intra-gNB-DU handovers (inter- as well as intra-frequency) and inter-gNB-DU handovers.
Due to the virtualization of RAN network functions we will also find another form of switching transmission path, which is a change of the gNB-CU UP during the call without mobility of the UE. This scenario I will discuss later in a separate blog post.
Today I want to focus on the intra-gNB DU handover. Here the UE moves from one cell to another one within the same distributed unit as shown in the figure below.
A prerequisite is the successful establishment of a NR RRC connection and a F1AP UE Context between the gNB-DU and the gNB-CU CP.
The F1AP transports all RRC messages between these two entities. Indeed, it transports the PDCP blocks and the gNB-DU is not aware that these PDCP blocks contain RRC messages. However, for better illustration I have not shown the PDPC part in the ladder diagram.
What we see in step 1 is a NR RRC Reconfiguration message that contains RRC measurement configurations to be enabled on the UE side. A typical trigger event for intra-frequency handovers is the A3 event that is already known from LTE RRC.
Once the UE detects a better neighbor cell meeting the A3 criteria it sends a RRC Measurement Report to the gNB-CU CP (step 2).
In step 3 the gNB-CU CP orders the gNB-DU to perform a F1AP UE Context Modification. The purpose is to allocate radio resources for the UE in the target cell and to prepare the cell change.
The gNB-DU replies with F1AP UE Context Modification Response. This messages contains the new C-RNTI and a large block of lower layer configuration parameters (e.g. for RLC and MAC layer) that need to be sent to the UE and thus, need to be transported to the gNB-CU CP before, because it is the only RAN function capable to communicate with the UE using the RRC protocol.
Hence, in step 5 we see another downlink RRC message transfer. This time it is used to transport the handover command towards the UE. The handover command is a NR RRC Reconfiguration message and it contains the new C-RNTI (new UE identity within the cell) as well as the physical cell ID of the target cell and the full set of lower layer configuration parameters previously provided by the gNB-DU.
When the gNB-CU CP receives the RRC Reconfiguration Complete message sent by the UE in step 6 the handover is successfully completed and the UE is now served by the cell with NR PCI 2.
As mentioned before there is neither XnAP (communication between two neighbor gNBs) nor NGAP (communication between gNB and AMF) involved in this handover procedure.
Related Posts:
As mentioned in one of the earlier posts the gNB-CU CP will be in charge of controlling hundreds of gNB-DUs in a similar way like the 3G RNC was in charge of controlling hundreds of UMTS NodeBs. As a result the most common 5G SA intra-system handovers will be intra-gNB handovers. These handovers can further be classified into intra-gNB-DU handovers (inter- as well as intra-frequency) and inter-gNB-DU handovers.
Due to the virtualization of RAN network functions we will also find another form of switching transmission path, which is a change of the gNB-CU UP during the call without mobility of the UE. This scenario I will discuss later in a separate blog post.
Today I want to focus on the intra-gNB DU handover. Here the UE moves from one cell to another one within the same distributed unit as shown in the figure below.
A prerequisite is the successful establishment of a NR RRC connection and a F1AP UE Context between the gNB-DU and the gNB-CU CP.
The F1AP transports all RRC messages between these two entities. Indeed, it transports the PDCP blocks and the gNB-DU is not aware that these PDCP blocks contain RRC messages. However, for better illustration I have not shown the PDPC part in the ladder diagram.
What we see in step 1 is a NR RRC Reconfiguration message that contains RRC measurement configurations to be enabled on the UE side. A typical trigger event for intra-frequency handovers is the A3 event that is already known from LTE RRC.
Once the UE detects a better neighbor cell meeting the A3 criteria it sends a RRC Measurement Report to the gNB-CU CP (step 2).
In step 3 the gNB-CU CP orders the gNB-DU to perform a F1AP UE Context Modification. The purpose is to allocate radio resources for the UE in the target cell and to prepare the cell change.
The gNB-DU replies with F1AP UE Context Modification Response. This messages contains the new C-RNTI and a large block of lower layer configuration parameters (e.g. for RLC and MAC layer) that need to be sent to the UE and thus, need to be transported to the gNB-CU CP before, because it is the only RAN function capable to communicate with the UE using the RRC protocol.
Hence, in step 5 we see another downlink RRC message transfer. This time it is used to transport the handover command towards the UE. The handover command is a NR RRC Reconfiguration message and it contains the new C-RNTI (new UE identity within the cell) as well as the physical cell ID of the target cell and the full set of lower layer configuration parameters previously provided by the gNB-DU.
When the gNB-CU CP receives the RRC Reconfiguration Complete message sent by the UE in step 6 the handover is successfully completed and the UE is now served by the cell with NR PCI 2.
As mentioned before there is neither XnAP (communication between two neighbor gNBs) nor NGAP (communication between gNB and AMF) involved in this handover procedure.
Related Posts:
Great POST, but did not able to understand, maybe because the step is not shown: UE would not do RACH to new RRH? Because the PCI, CRNTI and other lower-layer configuration parameters are different, I think UE would do sync, RACH with new RRH, apply those configurations and then sends RRC_Reconf_complete. Is not the case?
ReplyDeleteThat is correct. RACH procedures are performed during each HO execution. I have not described this in figure/text, because I was focused on the Layer 3 RRC Signaling messages. Thank you for the comment.
ReplyDeleteInformative post. I am wondering is it always mandatory for CU-CP to provide the SRBToAddModLst, DRBToAddModLst, and ScellToAddmodLst in UE modification request. What if CU-CP doesn't provide any details regarding the SCELLs, SRBs, and DRBs; Will DU considers all the SCELLs and RBs on the source cells to be added on to target cell.
ReplyDeleteOnly the CU-CP has the information which SRBs and DRBs must be added to the connection. In case of DRBs it gets this info from the core network on NGAP. NR RRC is the protocol layer where UE and RAN are "talking" about bearers and NR RRC terminates at CU-CP. DUs have no insight into NR RRC.
ReplyDeleteIs it possible for you to upload the complete ladder diagram? 38401 8.2.1.2 does not have it.
ReplyDeleteI am trying to understand at which step UE has disconnected from the source RU and connected to target RU. what happens to the DL packet at the time which is coming from UPF?
What happens to SMC (security proc) would it be done again or since DU is not changing, it wont be done?
ReplyDeleteLet me see if I can find some time for the full ladder diagram including random access procedure and data forwarding.
ReplyDeleteSecurity keys are expected to remain unchanged as long as the gNB-CU-CP (anchor point for Access Stratum security) is not changed.
Please share full ladder diagram including random access procedure and data forwarding for Intra 5G Handover, if possible.
ReplyDeleteHi Ralf, During Intra-DU HO does UE reestablish the RLC and reset all the context. In that case, is it mandatory to send all the RLC configurations for SRBs and DRB to UE?
ReplyDeleteThanks in advance.
Hi Ralf,
ReplyDeleteThank you for this very informative and descriptive post. I wonder whether this flow is valid for NSA scenarios where SgNB intra-cell change occurs.
Hi Ralf,
ReplyDeleteMay i know, from which 3GPP or ETSI that i could also look into this Intra-gNB DU HO?
I could not see this scenario from TS138401.
Many thanks
Chrisitne from TW.