View source for My Intra-NR Notes

== 9.2.1 Mobility in RRC_IDLE ==

=== 9.2.1.1	Cell Selection ===

The principles of PLMN selection in NR are based on the 3GPP PLMN selection principles. <span style="color:red">Cell selection</span> is required on transition from RM-DEREGISTERED to RM-REGISTERED, from CM-IDLE to CM-CONNECTED and from CM-CONNECTED to CM-IDLE and is based on the following principles:

* The UE NAS layer identifies a selected PLMN and equivalent PLMNs;
* Cell selection is always based on CD-SSBs located on the synchronization raster (see clause 5.2.4):
** The UE searches the NR frequency bands and for each carrier frequency identifies the strongest cell as per the CD-SSB. It then reads cell system information broadcast to identify its PLMN(s):
*** The UE may search each carrier in turn ("initial cell selection") or make use of stored information to shorten the search ("stored information cell selection").
* The UE seeks to identify a suitable cell; if it is not able to identify a suitable cell it seeks to identify an acceptable cell. When a suitable cell is found or if only an acceptable cell is found it camps on that cell and commence the cell reselection procedure:
** A suitable cell is one for which the measured cell attributes satisfy the cell selection criteria; the cell PLMN is the selected PLMN, registered or an equivalent PLMN; the cell is not barred or reserved and the cell is not part of a tracking area which is in the list of "forbidden tracking areas for roaming";
** An acceptable cell is one for which the measured cell attributes satisfy the cell selection criteria and the cell is not barred.
* The IAB-MT applies the cell selection procedure as described for the UE with the following differences:
** The IAB-MT ignores cell-barring or cell-reservation indications contained in cell system information broadcast;
** The IAB-MT only considers a cell as a candidate for cell selection if the cell system information broadcast indicates IAB support for the selected PLMN or the selected SNPN.

Transition to RRC_IDLE:
* <span style="color:red">On transition from RRC_CONNECTED or RRC_INACTIVE to RRC_IDLE, a UE should camp on a cell as result of cell selection according to the frequency be assigned by RRC in the state transition message if any.</span>

Recovery from out of coverage:
* The UE should attempt to find a suitable cell in the manner described for stored information or initial cell selection above. If no suitable cell is found on any frequency or RAT, the UE should attempt to find an acceptable cell.

In multi-beam operations, the cell quality is derived amongst the beams corresponding to the same cell (see clause 9.2.4).

=== 9.2.1.2	Cell Reselection ===

<span style="color:red">A UE in RRC_IDLE performs cell reselection.</span> The principles of the procedure are the following:
* Cell reselection is always based on CD-SSBs located on the synchronization raster (see clause 5.2.4).
* The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process:
** For the search and measurement of inter-frequency neighbouring cells, only the carrier frequencies need to be indicated.
* Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which involves measurements of the serving and neighbour cells:
** Intra-frequency reselection is based on ranking of cells;
** Inter-frequency reselection is based on absolute priorities where a UE tries to camp on the highest priority frequency available;
** An NCL can be provided by the serving cell to handle specific cases for intra- and inter-frequency neighbouring cells;
** Exclude-lists can be provided to prevent the UE from reselecting to specific intra- and inter-frequency neighbouring cells;
** Allow-lists can be provided to request the UE to reselect to only specific intra- and inter-frequency neighbouring cells;
** Cell reselection can be speed dependent;
** Service specific prioritisation;
** Slice specific cell reselection information can be provided to facilitate the UE to reselect a cell that supports specific slices.

In multi-beam operations, the cell quality is derived amongst the beams corresponding to the same cell (see clause 9.2.4).

=== 9.2.1.3 RRC_IDLE State Transitions ===

The following figure describes the UE triggered transition from RRC_IDLE to RRC_CONNECTED (<span style="color:red">for the NAS part, see TS 23.502</span>):

<center>[[File:UE triggered transition from RRC IDLE to RRC CONNECTED.png|UE triggered transition from RRC IDLE to RRC CONNECTED sequence diagram]]</center>

: 1. The UE requests to setup a new connection from RRC_IDLE.
: 2/2a. The gNB completes the RRC setup procedure.
: NOTE: The scenario where the gNB rejects the request is described below.
: 3. The first NAS message from the UE, piggybacked in RRCSetupComplete, is sent to AMF.
: 4/4a/5/5a. Additional NAS messages may be exchanged between UE and AMF, see TS 23.502.
: 6. The AMF prepares the UE context data (including PDU session context, the Security Key, UE Radio Capability and UE Security Capabilities, etc.) and sends it to the gNB.
: 7/7a. The gNB activates the AS security with the UE.
: 8/8a. The gNB performs the reconfiguration to setup SRB2 and DRBs for UE, or SRB2 and optionally DRBs for IAB-MT.
: 9. The gNB informs the AMF that the setup procedure is completed.
: NOTE 1:	RRC messages in step 1 and 2 use SRB0, all the subsequent messages use SRB1. Messages in steps 7/7a are integrity protected. From step 8 on, all the messages are integrity protected and ciphered.
: NOTE 2:	For signalling only connection, step 8 is skipped since SRB2 and DRBs are not setup.

The following figure describes the rejection from the network when the UE attempts to setup a connection from RRC_IDLE:

<center>[[File:Rejection of UE triggered transition from RRC IDLE.png|File:Rejection of UE triggered transition from RRC IDLE.png sequence diagram]]</center>

:1. UE attempts to setup a new connection from RRC_IDLE.
:2. The gNB is not able to handle the procedure, for instance due to congestion.
:3. The gNB sends RRCReject (with a wait time) to keep the UE in RRC_IDLE.

== 9.2.2	Mobility in RRC_INACTIVE ==

=== 9.2.2.1	Overview ===

RRC_INACTIVE is a state where a UE remains in CM-CONNECTED and can move within an area configured by NG-RAN, the RAN-based Notification Area (RNA), without notifying NG-RAN. In RRC_INACTIVE, the last serving gNB node keeps the UE context and the UE-associated NG connection with the serving AMF and UPF.

=== 9.2.2.2	Cell Reselection ===

A UE in RRC_INACTIVE performs cell reselection. The principles of the procedure are as for the RRC_IDLE state (see clause 9.2.1.2).

=== 9.2.2.3 RAN-Based Notification Area ===

A UE in the RRC_INACTIVE state can be configured by the last serving NG-RAN node with an RAN-based Notification Area (RNA), where:
* the RNA can cover a single or multiple cells, and shall be contained within the Core Network (CN) registration area; in this release Xn connectivity should be available within the RNA;
** a RAN-based notification area update (RNAU) is periodically sent by the UE and is also sent when the cell reselection procedure of the UE selects a cell that does not belong to the configured RNA.

There are several different alternatives on how the RNA can be configured:
* List of cells:
** A UE is provided an explicit list of cells (one or more) that constitute the RNA.
* List of RAN areas:
** A UE is provided (at least one) RAN area ID, where a RAN area is a subset of a CN Tracking Area or equal to a CN Tracking Area. A RAN area is specified by one RAN area ID, which consists of a TAC and optionally a RAN area Code;
** A cell broadcasts one or more RAN area IDs in the system information.

NG-RAN may provide different RNA definitions to different UEs but not mix different definitions to the same UE at the same time. UE shall support all RNA configuration options listed above.

=== 9.2.2.4 RRC_INACTIVE State Transitions ===

==== 9.2.2.4.1	UE triggered transition from RRC_INACTIVE to RRC_CONNECTED ====

The following figure describes the UE triggered transition from RRC_INACTIVE to RRC_CONNECTED in case of UE context retrieval success:

<center>[[File:UE triggered transition from RRC INACTIVE to RRC CONNECTED (UE context retrieval success).png|UE triggered transition from RRC INACTIVE to RRC CONNECTED (UE context retrieval success)]]</center>

:1. The UE resumes from RRC_INACTIVE, providing the I-RNTI, allocated by the last serving gNB.
: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.
:3. The last serving gNB provides UE context data.
:4/5. The gNB and UE completes the resumption of the RRC connection.
: NOTE:	User Data can also be sent in step 5 if the grant allows.
: 6. If loss of DL user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses.
: 7/8. The gNB performs path switch.
: 9. The gNB triggers the release of the UE resources at the last serving gNB.

After step 1 above, when the gNB decides to use a single RRC message to reject the Resume Request right away and keep the UE in RRC_INACTIVE without any reconfiguration (e.g. as described in the two examples below), or when the gNB decides to setup a new RRC connection, SRB0 (without security) is used. Conversely, when the gNB decides to reconfigure the UE (e.g. with a new DRX cycle or RNA) or when the gNB decides to push the UE to RRC_IDLE, SRB1 (with integrity protection and ciphering as previously configured for that SRB) shall be used.

NOTE:	SRB1 can only be used once the UE Context is retrieved i.e. after step 3.

The following figure describes the UE triggered transition from RRC_INACTIVE to RRC_CONNECTED in case of UE context retrieval failure:

<center>[[File:UE triggered transition from RRC INACTIVE to RRC CONNECTED (UE context retrieval failure).png|UE triggered transition from RRC INACTIVE to RRC CONNECTED (UE context retrieval failure)]]</center>

:1. The UE resumes from RRC_INACTIVE, providing the I-RNTI, allocated by the last serving gNB.
: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.
:3. The last serving gNB cannot retrieve or verify the UE context data.
:4. The last serving gNB indicates the failure to the gNB.
:5. The gNB performs a fallback to establish a new RRC connection by sending RRCSetup.
:6. A new connection is setup as described in clause 9.2.1.3.

The following figure describes the rejection form the network when the UE attempts to resume a connection from RRC_INACTIVE:

<center>[[File:Reject from the network, UE attempts to resume a connection.png|Reject from the network, UE attempts to resume a connection]]</center>

:1. UE attempts to resume the connection from RRC_INACTIVE.
:2. The gNB is not able to handle the procedure, for instance due to congestion.
:3. The gNB sends RRCReject (with a wait time) to keep the UE in RRC_INACTIVE.

==== 9.2.2.4.2	Network triggered transition from RRC_INACTIVE to RRC_CONNECTED ====

The following figure describes the network triggered transition from RRC_INACTIVE to RRC_CONNECTED:

<center>[[File:Network triggered transition from RRC INACTIVE to RRC CONNECTED.png|Network triggered transition from RRC INACTIVE to RRC CONNECTED]]</center>

:1. A RAN paging trigger event occurs (incoming DL user plane, DL signalling from 5GC, etc.).
:2. RAN paging is triggered; either only in the cells controlled by the last serving gNB or also by means of Xn RAN Paging in cells controlled by other gNBs, configured to the UE in the RAN-based Notification Area (RNA).
:3. The UE is paged with the I-RNTI.
:4. If the UE has been successfully reached, it attempts to resume from RRC_INACTIVE, as described in clause 9.2.2.4.1.

=== 9.2.2.5 RNA Update ===

The following figure describes the UE triggered RAN-based Notification Area (RNA) update procedure involving context retrieval over Xn. The procedure may be triggered when the UE moves out of the configured RNA, or periodically.

<center>[[File:RNA update procedure with UE context relocation.png|RNA update procedure with UE context relocation]]</center>

: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.
: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.
: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).
: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.
:5. If loss of DL user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses.
:6./7. The gNB performs path switch.
:8. The gNB keeps the UE in RRC_INACTIVE state by sending RRCRelease with suspend indication.
: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:

<center>[[File:Periodic RNA update procedure without UE context relocation.png|Periodic RNA update procedure without UE context relocation sequence diagram]]</center>

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

<center>[[File:RNA update procedure with transition to RRC IDLE.png|RNA update procedure with transition to RRC IDLE sequence diagram]]</center>

: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.
: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.
:3. Instead of providing the UE context, the last serving gNB provides an RRCRelease message to move the UE to RRC_IDLE.
:4.	The last serving gNB deletes the UE context.
:5.	The gNB sends the RRCRelease which triggers the UE to move to RRC_IDLE.

=== 9.2.2.6 Resume request responded with Release with Redirect, with UE context relocation ===

The following figure describes a UE triggered NAS procedure responded by the network with a release with redirect, with UE context relocation.

<center>[[File:Resume request responded with Release with Redirect, with UE Context relocation.png|Resume request responded with Release with Redirect, with UE Context relocation sequence diagram]]</center>

:1.	The UE resumes from RRC_INACTIVE, providing the inactive radio network temporary identifier (I-RNTI) allocated by the last serving gNB.
: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.
:3.	The last serving gNB provides the UE context.
: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).
:5.	If loss of DL user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses.
:6./7. The gNB performs path switch.
: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).
:9.	The gNB triggers the release of the UE resources at the last serving gNB.

NOTE1:	Upon receiving the release with redirect, the higher layers trigger a pending procedure so the UE tries to resume again after cell selection.

== 9.2.3 Mobility in RRC_CONNECTED ==

=== 9.2.3.1	Overview ===

Network controlled mobility applies to UEs in RRC_CONNECTED and is categorized into two types of mobility: cell level mobility and beam level mobility. Beam level mobility includes intra-cell beam level mobility and inter-cell beam level mobility.

'''Cell Level Mobility''' requires explicit RRC signalling to be triggered, i.e. handover. For inter-gNB handover, the signalling procedures consist of at least the following elemental components illustrated in Figure 9.2.3.1-1:

<center>[[File:Inter-gNB handover procedures.png|Inter-gNB handover procedures sequence diagram]]</center>

:1.	The source gNB initiates handover and issues a HANDOVER REQUEST over the Xn interface.
:2.	The target gNB performs admission control and provides the new RRC configuration as part of the HANDOVER REQUEST ACKNOWLEDGE.
:3.	The source gNB provides the RRC configuration to the UE by forwarding the RRCReconfiguration message received in the HANDOVER REQUEST ACKNOWLEDGE. The RRCReconfiguration message includes at least cell ID and all information required to access the target cell so that the UE can access the target cell without reading system information. For some cases, the information required for contention-based and contention-free random access can be included in the RRCReconfiguration message. The access information to the target cell may include beam specific information, if any.
:4.	The UE moves the RRC connection to the target gNB and replies with the RRCReconfigurationComplete.

NOTE 1:	User Data can also be sent in step 4 if the grant allows.

See spec for full details.

<center>[[My 3GPP 38.300 Notes|To My 3GPP 38.300 Notes]]</center>