Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 38.300  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   4.7…   5…   5.3…   5.4…   6…   6.2…   6.6…   7…   8…   9…   9.2.2…   9.2.3…   9.2.3.2   9.2.3.3…   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.3   16.4…   17…   A…   B…

 

9.2.3.3  Re-establishment procedureWord‑p. 77
A UE in RRC_CONNECTED may initiate the re-establishment procedure to continue the RRC connection when a failure condition occurs (e.g. radio link failure, reconfiguration failure, integrity check failure…).
The following figure describes the re-establishment procedure started by the UE:
Reproduction of 3GPP TS 38.300, Figure 9.2.3.3-1: Re-establishment procedure
Up
Step 1.
The UE re-establishes the connection, providing the UE Identity (PCI+C-RNTI) to the gNB where the trigger for the re-establishment occurred.
Step 2.
If the UE Context is not locally available, the gNB, requests the last serving gNB to provide UE Context data.
Step 3.
The last serving gNB provides UE context data.
Step 4/4a.
The gNB continues the re-establishment of the RRC connection. The message is sent on SRB1.
Step 5/5a.
The gNB may perform the reconfiguration to re-establish SRB2 and DRBs when the re-establishment procedure is ongoing.
Step 6/7.
If loss of user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses, and the last serving gNB provides the SN status to the gNB.
Step 8/9.
The gNB performs path switch.
Step 10.
The gNB triggers the release of the UE resources at the last serving gNB.
The IAB-MT in SA mode follows the same re-establishment procedure as described for the UE. After the backhaul has been established, the re-establishment procedure of the IAB-MT is part of the intra-CU backhaul RLF recovery procedure for IAB-nodes defined in TS 38.401. Modifications to the configuration of BAP sublayer and higher protocol layers above the BAP sublayer are described in TS 38.401.
Up

9.2.3.4  Conditional Handover |R16|Word‑p. 78
9.2.3.4.1  General
A Conditional Handover (CHO) is defined as a handover that is executed by the UE when one or more handover execution conditions are met. The UE starts evaluating the execution condition(s) upon receiving the CHO configuration, and stops evaluating the execution condition(s) once a handover is executed (legacy handover or conditional handover execution).
The following principles apply to CHO:
  • The CHO configuration contains the configuration of CHO candidate cell(s) generated by the candidate gNB(s) and execution condition(s) generated by the source gNB.
  • An execution condition may consist of one or two trigger condition(s) (CHO events A3/A5, as defined in [12]). Only single RS type is supported and at most two different trigger quantities (e.g. RSRP and RSRQ, RSRP and SINR, etc.) can be configured simultaneously for the evalution of CHO execution condition of a single candidate cell.
  • Before any CHO execution condition is satisfied, upon reception of HO command (without CHO configuration), the UE executes the HO procedure as described in clause 9.2.3.2, regardless of any previously received CHO configuration.
  • While executing CHO, i.e. from the time when the UE starts synchronization with target cell, UE does not monitor source cell.
CHO is not supported for NG-C based handover in this release of the specification.
Up
9.2.3.4.2  C-plane handlingWord‑p. 79
As in intra-NR RAN handover, in intra-NR RAN CHO, the preparation and execution phase of the conditional handover procedure is performed without involvement of the 5GC; i.e. preparation messages are directly exchanged between gNBs. The release of the resources at the source gNB during the conditional handover completion phase is triggered by the target gNB. The figure below depicts the basic conditional handover scenario where neither the AMF nor the UPF changes:
Reproduction of 3GPP TS 38.300, Figure 9.2.3.4.2-1: Intra-AMF/UPF Conditional Handover
Up
Step 0/1.
Same as step 0, 1 in Figure 9.2.3.2.1-1 of clause 9.2.3.2.1.
Step 2.
The source gNB decides to use CHO.
Step 3.
The source gNB requests CHO to one or more candidate gNBs. A CHO request message is sent for each candidate cell.
Step 4.
Same as step 4 in Figure 9.2.3.2.1-1 of clause 9.2.3.2.1.
Step 5.
The candidate gNB(s) sends CHO response (HO REQUEST ACKNOWLEDGE) including configuration of CHO candidate cell(s) to the source gNB. The CHO response message is sent for each candidate cell.
Step 6.
The source gNB sends an RRCReconfiguration message to the UE, containing the configuration of CHO candidate cell(s) and CHO execution condition(s).
Step 7.
The UE sends an RRCReconfigurationComplete message to the source gNB.
Step 7a.
If early data forwarding is applied, the source gNB sends the EARLY STATUS TRANSFER message.
Step 8.
The UE maintains connection with the source gNB after receiving CHO configuration, and starts evaluating the CHO execution conditions for the candidate cell(s). If at least one CHO candidate cell satisfies the corresponding CHO execution condition, the UE detaches from the source gNB, applies the stored corresponding configuration for that selected candidate cell, synchronises to that candidate cell and completes the RRC handover procedure by sending RRCReconfigurationComplete message to the target gNB. The UE releases stored CHO configurations after successful completion of RRC handover procedure.
Step 8a/b.
The target gNB sends the HANDOVER SUCCESS message to the source gNB to inform that the UE has successfully accessed the target cell. In return, the source gNB sends the SN STATUS TRANSFER message.
Step 8c.
The source gNB sends the HANDOVER CANCEL message toward the other signalling connections or other potential target gNBs, if any, to cancel CHO for the UE.
Up
9.2.3.4.3  U-plane handlingWord‑p. 81
The U-plane handling for Conditional Handover follows the same principles for DAPS Handover in 9.2.3.2.2, if early data forwarding is applied. If late data forwarding is applied, the U-plane handling follows the RLC-AM or RLC-UM bearer principles defined in 9.2.3.2.2.
9.2.3.4.4  Data Forwarding
If late data forwarding is applied, the source NG-RAN node initiates data forwarding once it knows which target NG-RAN node the UE has successfully accessed. In that case the behavior of the Conditional Handover data forwarding follows the same behavior as defined in 9.2.3.2.3 for the intra-system handover data forwarding, except the behavior for DRBs configured with DAPS Handover.
If early data forwarding is applied instead, the source NG-RAN node initiates data forwarding before the UE executes the handover, to a candidate target node of interest. The behavior of early data forwarding for the Conditional Handover follows the same principles for DRBs configured with DAPS Handover in the intra-system handover as defined in 9.2.3.2.3.
Up


Up   Top   ToC