Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 38.300  Word version:  18.4.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.2.5…   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.2…   16.3…   16.4…   16.8…   16.9…   16.10…   16.12…   16.12.5…   16.12.6…   16.12.6.3   16.12.7   16.13…   16.14…   16.15…   16.18…   16.19…   16.21…   16.21.3…   17…   18…   19   20…   21…   A…   B…   C…   G… 
9.2.2.5 RNA update  9.2.2.6 Resume request responded with Release with Redirect, with UE context relocation 
...

 

9.2.2.5  RNA update  p. 83

The following Figure describes the UE triggered RNA update procedure involving context retrieval over Xn. The procedure may be triggered when the UE moves out of the configured RNA, or periodically.
Reproduction of 3GPP TS 38.300, Fig. 9.2.2.5-1: RNA update procedure with UE context relocation
Figure 9.2.2.5-1: RNA update procedure with UE context relocation
Up
Step 1.
The UE resumes from RRC_INACTIVE, providing the I-RNTI allocated by the last serving gNB and appropriate cause value, e.g., RAN notification area update.
Step 2.
The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide UE Context, providing the cause value received in step 1.
Step 3.
The last serving gNB may provide the UE context (as assumed in the following). Alternatively, the last serving gNB may decide to move the UE to RRC_IDLE (and the procedure follows steps 3 and later of Figure 9.2.2.5-3) or, if the UE is still within the previously configured RNA, to keep the UE context in the last serving gNB and to keep the UE in RRC_INACTIVE (and the procedure follows steps 3 and later of Figure 9.2.2.5-2).
Step 4.
The gNB may move the UE to RRC_CONNECTED (and the procedure follows step 4 of Figure 9.2.2.4.1-1), or send the UE back to RRC_IDLE (in which case an RRCRelease message is sent by the gNB), or send the UE back to RRC_INACTIVE as assumed in the following.
Step 5.
If loss of DL user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses.
Step 6./7.
The gNB performs path switch.
Step 8.
The gNB keeps the UE in RRC_INACTIVE state by sending RRCRelease with suspend indication.
Step 9.
The gNB triggers the release of the UE resources at the last serving gNB.
The following Figure describes the RNA update procedure for the case when the UE is still within the configured RNA and the last serving gNB decides not to relocate the UE context and to keep the UE in RRC_INACTIVE:
Reproduction of 3GPP TS 38.300, Fig. 9.2.2.5-2: Periodic RNA update procedure without UE context relocation
Figure 9.2.2.5-2: Periodic RNA update procedure without UE context relocation
Up
Step 1.
The UE resumes from RRC_INACTIVE, providing the I-RNTI allocated by the last serving gNB and appropriate cause value, e.g., RAN notification area update.
Step 2.
The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide UE Context, providing the cause value received in step 1.
Step 3.
The last serving gNB stores received information to be used in the next resume attempt (e.g. C-RNTI and PCI related to the resumption cell), and responds to the gNB with the RETRIEVE UE CONTEXT FAILURE message including an encapsulated RRCRelease message. The RRCRelease message includes Suspend Indication.
Step 4.
The gNB forwards the RRCRelease message to the UE.
The following Figure describes the RNA update procedure for the case when the last serving gNB decides to move the UE to RRC_IDLE:
Reproduction of 3GPP TS 38.300, Fig. 9.2.2.5-3: RNA update procedure with transition to RRC_IDLE
Figure 9.2.2.5-3: RNA update procedure with transition to RRC_IDLE
Up
Step 1.
The UE resumes from RRC_INACTIVE, providing the I-RNTI allocated by the last serving gNB and appropriate cause value, e.g., RAN notification area update.
Step 2.
The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide UE Context, providing the cause value received in step 1.
Step 3.
Instead of providing the UE context, the last serving gNB provides an RRCRelease message to move the UE to RRC_IDLE.
Step 4.
The last serving gNB deletes the UE context.
Step 5.
The gNB sends the RRCRelease which triggers the UE to move to RRC_IDLE.
Up

9.2.2.6  Resume request responded with Release with Redirect, with UE context relocation |R16|  p. 86

The following Figure describes a UE triggered NAS procedure responded by the network with a release with redirect, with UE context relocation.
Reproduction of 3GPP TS 38.300, Fig. 9.2.2.6-1: Resume request responded with Release with Redirect, with UE Context relocation
Figure 9.2.2.6-1: Resume request responded with Release with Redirect, with UE Context relocation
Up
Step 1.
The UE resumes from RRC_INACTIVE, providing the I-RNTI allocated by the last serving gNB.
Step 2.
The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide UE Context data.
Step 3.
The last serving gNB provides the UE context.
Step 4.
The gNB may move the UE to RRC_CONNECTED (and the procedure follows step 4 of Figure 9.2.2.4.1-1), or send the UE back to RRC_IDLE (in which case an RRCRelease message is sent by the gNB), or send the UE back to RRC_INACTIVE, including a release with redirect indication (as assumed in the following).
Step 5.
If loss of DL user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses.
Step 6./7.
The gNB performs path switch.
Step 8.
The gNB keeps the UE in RRC_INACTIVE state by sending RRCRelease with suspend indication, including redirection information (frequency layer the UE performs cell selection upon entering RRC_INACTIVE).
Step 9.
The gNB triggers the release of the UE resources at the last serving gNB.
Up

Up   Top   ToC