TS38.300-i20学习-6

9.2.2.4.2 网络触发的从 RRC_INACTIVE 到 RRC_CONNECTED 的转换

以下图示描述了网络触发的从 RRC_INACTIVE 到 RRC_CONNECTED 的状态转换过程：

Figure 9.2.2.4.2-1: Network triggered transition from RRC_INACTIVE to RRC_CONNECTED
（1）RAN寻呼触发事件：当发生 RAN 寻呼触发事件时，例如有下行用户平面数据到达，或者从 5GC 发出下行信令。
（2）触发 RAN 寻呼：寻呼可以在由最后服务的 gNB 控制的小区内进行，也可以通过 Xn RAN 寻呼在其他 gNB 控制的、分配给 UE 的 RAN 通知区域（RNA）内的小区中进行。
（3）寻呼 UE：系统使用 I-RNTI 对 UE 进行寻呼。
（4）UE 响应：如果成功寻呼到 UE，它将按照 9.2.2.4.1 节的描述尝试从 RRC_INACTIVE 状态恢复到 RRC_CONNECTED 状态。
在这个过程中，网络利用 RAN 寻呼机制确保 UE 能够在需要时迅速恢复连接，这对于维持服务质量和网络效率至关重要。

9.2.2.5 RNA 更新

以下图示描述了UE触发的RNA更新过程，其中包括通过Xn进行上下文检索。该过程可能在UE移动出配置的RNA区域时或周期性触发。

（1）UE恢复：UE从RRC_INACTIVE状态恢复，并提供由最后服务的gNB分配的I-RNTI及相应的原因值，如RAN通知区域更新。
（2）身份解析与请求：如果gNB能够解析I-RNTI中的gNB身份信息，则请求最后服务的gNB提供UE上下文，并传递步骤1中收到的原因值。
（3）提供上下文：最后服务的gNB可能会提供UE的上下文信息（以下假设为这种情况）。否则，最后服务的gNB可能决定将UE移动到RRC_IDLE状态（流程参见图9.2.2.5-3的步骤3及后续步骤），或在UE仍在先前配置的RNA内时保持UE上下文并使UE保持在RRC_INACTIVE状态（流程参见图9.2.2.5-2的步骤3及后续步骤）。
（4）状态决定：gNB可能会将UE移动到RRC_CONNECTED状态（参见图9.2.2.4.1-1的步骤4），或者将UE发送回RRC_IDLE状态（此时gNB发送RRCRelease消息），或将UE保持在RRC_INACTIVE状态，如以下假设的情况。
（5）数据转发地址提供：如果需要防止最后服务的gNB中缓存的下行用户数据丢失，gNB提供转发地址。
（6）路径切换：gNB执行路径切换。
（7）路径切换：gNB执行路径切换。
（8）保持RRC_INACTIVE状态：gNB通过发送带有挂起指示的RRCRelease消息将UE保持在RRC_INACTIVE状态。
（9）资源释放：gNB触发最后服务的gNB释放UE资源

以下图示描述了在UE仍然位于配置的RNA内，且最后服务的gNB决定不迁移UE上下文并保持UE在RRC_INACTIVE状态时的RNA更新过程：
Figure 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
（1）UE恢复：UE从RRC_INACTIVE状态恢复，并提供最后服务的gNB分配的I-RNTI及相关原因值，例如RAN通知区域更新。
（2）身份解析与请求：如果gNB能够解析I-RNTI中的gNB身份信息，则向最后服务的gNB请求UE上下文，同时传递在步骤1中收到的原因值。
（3）信息存储与响应：最后服务的gNB存储接收到的信息，以备下次恢复尝试时使用（如与恢复小区相关的C-RNTI和PCI），并向gNB发送包含封装的RRCRelease消息的RETRIEVE UE CONTEXT FAILURE消息。RRCRelease消息包含挂起指示。
（4）消息转发：gNB将RRCRelease消息转发给UE。