Content for TS 37.340 Word version: 18.2.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… 10.20 11… A B…

10.17 Inter-Master Node RRC Resume without Secondary Node change 10.17.1 MR-DC with 5GC
...

10.17 Inter-Master Node RRC Resume without Secondary Node change |R17| p. 105

10.17.1 MR-DC with 5GC p. 105

Inter-MN RRC Resume 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. During the procedure, the target MN may decide not to keep the SN.

Copy of original 3GPP image for 3GPP TS 37.340, Fig. 10.17.1-1: Inter-MN RRC Resume without MN initiated SN change procedure

Figure 10.17.1-1: Inter-MN RRC Resume without MN initiated SN change procedure
(⇒ copy of original 3GPP image)

Figure 10.17.1-1 shows an example signalling flow for inter-MN RRC Resume without MN initiated SN change:

Step 1.

The UE resumes from RRC_INACTIVE, providing the I-RNTI, allocated by the source MN, i.e., the last serving NG-RAN node.

Step 2.

The target MN, if able to resolve the NG-RAN node identity contained in the I-RNTI, requests the source MN to provide UE Context by initiating the Xn Retrieve UE Context procedure.

Step 3.

If the verification is successful, the source MN provides UE context data. The source MN includes the SN UE XnAP ID, SN ID and the UE context in the SN in the Retrieve UE Context Response message.

Step 4b.

The SN replies with SN Addition Request Acknowledge message.

Step 4c.

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 5/6.

The target MN and UE complete the resumption of the RRC connection.

Step 7.

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

Step 8.

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

Step 9.

If the RRC connection reconfiguration procedure was successful, the target MN initiates the Xn Retrieve UE Context Confirm procedure and indicates to the source MN whether the UE context in the SN is kept or not.

Step 10.

The Xn-U Address Indication procedure may be invoked by the target MN to provide forwarding address information if loss of DL user data buffered in the source side needs to be avoided.

Step 11a/11b.

The source MN sends SN Release Request message to the SN including a Cause indicating MCG mobility. The SN acknowledges the release request. The source MN indicates to the SN that the UE context in the SN is kept, if it receives the indication from the target MN. If the indication as the UE context kept in the SN is included, the SN keeps the UE context.

Step 11c.

If received in step 10, the source MN sends the Xn-U Address Indication message to the 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 12.

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 13-16.

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

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

Step 18.

Upon reception of the UE Context Release message from source MN, the 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 SN Release Request message in step 11.