Content for TS 37.340 Word version: 17.3.0

1… 4… 4.2… 4.3… 5… 7… 8… 9 10… 10.2… 10.2.2… 10.3… 10.3.2 10.4… 10.5… 10.5.2 10.6 10.7… 10.8… 10.9… 10.10… 10.11… 10.12… 10.12.2 10.13… 10.14… 10.15 10.16… 10.17… 10.18… 10.19… 11… A B…

10.7 Inter-Master Node handover with/without Secondary Node change 10.7.1 EN-DC 10.7.2 MR-DC with 5GC
...

10.7 Inter-Master Node handover with/without Secondary Node change p. 71

10.7.1 EN-DC p. 71

Inter-Master Node handover with/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, as described in clause 10.8).

Copy of original 3GPP image for 3GPP TS 37.340, Fig. 10.7.1-1: Inter-MN handover with/without MN initiated SN change

Figure 10.7.1-1: Inter-MN handover with/without MN initiated SN change
(⇒ copy of original 3GPP image)

Figure 10.7.1-1 shows an example signaling flow for inter-Master Node handover with or without MN initiated Secondary Node change:

Step 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.

Step 2.

If the target MN decides to keep the UE context in SN, the target MN sends SgNB 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 allowing delta configuration, 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. Otherwise, the target MN may send the SgNB Addition Request to the target SN including neither the SN UE X2AP ID nor the UE context in the source SN that was established by the source MN.

Step 3.

The (target) SN replies with SgNB Addition Request Acknowledge. The (target) SN may include the indication of the full or delta RRC configuration.

Step 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.

Step 5.

The source MN sends SgNB 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.

Step 6.

The source MN triggers the UE to apply the new configuration.

Step 7/8.

The UE synchronizes to the target MN and replies with RRCConnectionReconfigurationComplete message.

Step 9.

If configured with bearers requiring SCG radio resources, the UE synchronizes to the (target) SN.

Step 10.

If the RRC connection reconfiguration procedure was successful, the target MN informs the (target) SN via SgNB Reconfiguration Complete message.

Step 11a.

The SN sends the Secondary RAT Data Usage Report message to the source MN and includes the data volumes delivered to and received from the UE over the NR radio for the related E-RABs.

Step 11b.

The source MN sends the Secondary RAT Report message to MME to provide information on the used NR resource.

Step 12.

For bearers using RLC AM, the source MN sends the SN Status Transfer message, including, if needed, SN Status received from the source SN to the target MN. The target forwards the SN Status to the target SN, if needed.

Step 13.

If applicable, data forwarding takes place from the source side. If the SN is kept, data forwarding may be omitted for SN-terminated bearers kept in the SN.

Step 14-17.

The target MN initiates the S1 Path Switch procedure.

Step 18.

The target MN initiates the UE Context Release procedure towards the source MN.

Step 19.

Upon reception of the UE Context Release message, the (source) SN releases C-plane related resources 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 UE context kept indication was included in the SgNB Release Request message in step 5.

10.7.2 MR-DC with 5GC p. 73

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, as described in clause 10.8). Only intra-RAT Inter-Master node handover with/without SN change is supported (e.g. no transition from NGEN-DC to NR-DC).

Copy of original 3GPP image for 3GPP TS 37.340, Fig. 10.7.2-1: Inter-MN handover with/without MN initiated SN change procedure

Figure 10.7.2-1: Inter-MN handover with/without MN initiated SN change procedure
(⇒ copy of original 3GPP image)

Figure 10.7.2-1 shows an example signalling flow for inter-MN handover with or without MN initiated SN change:

Step 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.

Step 2.

If the target MN decides to keep the UE context in 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 allowing delta configuration, 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. Otherwise, the target MN may send the SN Addition Request to the target SN including neither the SN UE XnAP ID nor the UE context in the source SN that was established by the source MN.

Step 3.

The (target) SN replies with SN Addition Request Acknowledge. The (target) SN may include the indication of the full or delta RRC configuration.

Step 3a.

For SN terminated bearers using MCG resources, the target MN provides Xn-U DL TNL address information in the Xn-U Address Indication message.

Step 4.

The target MN includes within the Handover Request Acknowledge message the MN RRC reconfiguration message to be sent to the UE in order to perform the handover, and may also provide forwarding addresses to the source MN. If PDU session split is performed in the target side during handover procedure, more than one data forwarding addresses corresponding to each node are included in the Handover Request Acknowledge message. 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.

Step 5a/5b.

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.

Step 5c.

The source MN sends XN-U Address Indication message to the (source) SN to transfer data forwarding information. More than one data forwarding addresses may be provided if the PDU session is split in the target side.

Step 6.

The source MN triggers the UE to perform handover and apply the new configuration.

Step 7/8.

The UE synchronizes to the target MN and replies with MN RRC reconfiguration complete message.

Step 9.

If configured with bearers requiring SCG radio resources, the UE synchronizes to the (target) SN.

Step 10.

If the RRC connection reconfiguration procedure was successful, the target MN informs the (target) SN via SN Reconfiguration Complete message.

Step 11a.

The source SN sends the Secondary RAT Data Usage Report message to the source MN and includes the data volumes delivered to and received from the UE over the NR/E-UTRA radio as described in clause 10.11.2.

Step 11b.

The source MN sends the Secondary RAT Report message to AMF to provide information on the used NR/E-UTRA resource.

Step 12.

For bearers using RLC AM, the source MN sends the SN Status Transfer message to the target MN, including, if needed, SN Status received from the source SN. The target forwards the SN Status to the target SN, if needed.

Step 13.

If applicable, data forwarding takes place from the source side. If the SN is kept, data forwarding may be omitted for SN terminated bearers or QoS flows kept in the SN.

Step 14-17.

The target MN initiates the Path Switch procedure. If the target MN includes multiple DL TEIDs for one PDU session in the Path Switch Request message, multiple UL TEID of the UPF for the PDU session should be included in the Path Switch Ack message in case there is TEID update in UPF.

Step 18.

The target MN initiates the UE Context Release procedure towards the source MN.

Step 19.

Upon reception of the UE Context Release message from source MN, the (source) SN releases C-plane related resources 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 UE contest kept indication was included in the SN Release Request message in step 5.