TS38.300-i20学习-4

9.2.2.2 小区重选

在RRC_INACTIVE状态下，用户设备（UE）会进行小区重选。这个过程的原则与RRC_IDLE状态下的原则一致（详见9.2.1.2节）。

9.2.2.3 基于RAN的通知区

在RRC_INACTIVE状态下，UE可能会由最后服务的NG-RAN节点配置一个RAN通知区（RNA）。RNA可以涵盖一个或多个小区，且必须位于核心网注册区内；在这个版本中，RNA内部应有Xn连接。UE会定期发送基于RAN的通知区更新（RNAU），如果UE的小区重选选择了一个不属于配置RNA的小区，也会发送RNAU。
RNA可以通过几种方式配置：
小区列表：
UE会被提供一个明确的小区列表（一个或多个），这些小区构成了RNA。
RAN区域列表：
UE会收到至少一个RAN区域ID，RAN区域可以是核心网跟踪区的子集或等同于核心网跟踪区。RAN区域由一个RAN区域ID表示，该ID包括一个跟踪区代码（TAC）和一个可选的RAN区域代码；
系统信息中一个小区可能会广播一个或多个RAN区域ID，特别是在网络共享时。
NG-RAN可以为不同的UE提供不同的RNA定义，但不会同时向同一个UE提供混合的不同定义。UE应支持以上列出的所有RNA配置选项。

9.2.2.4 状态转换

9.2.2.4.1 由 UE 触发的从 RRC_INACTIVE 到 RRC_CONNECTED 的转换

下图描述了在成功检索 UE 上下文的情况下，由 UE 触发的从 RRC_INACTIVE 到 RRC_CONNECTED 状态的转换过程：

Figure 9.2.2.4.1-2: UE triggered transition from RRC_INACTIVE to RRC_CONNECTED
(UE context retrieval success)
（1）RRC Resume request UE 从 RRC_INACTIVE 状态恢复，并提供最后服务的 gNB 分配的 I-RNTI。
（2）Retriveve ue context Requset 如果 gNB 能够解析 I-RNTI 中的 gNB 身份，则请求最后服务的 gNB 提供 UE 上下文数据。
（3）Retriveve ue context response 最后服务的 gNB 提供 UE 上下文数据。
（4）RRC Resume 相应UE。
（5）UE回复到RRC_Connecte并相应RRC Resume Complete 标志着回复成功。（备注：如果授权允许，也可在步骤 5 中发送用户数据。）
（6）为防止在最后服务的 gNB 中缓存的下行用户数据丢失，gNB 提供转发地址。
（7）path switch request 发起路径转换，告诉网络下行数据的GTP-U端口号。
path switch requset response 主要是相应。gNB 触发释放最后服务的 gNB 中的 UE 资源。

说明：

在状态转换中的应用
在UE从RRC_INACTIVE恢复到RRC_CONNECTED的过程中，网络（gNB）可以选择不同的处理路径，具体路径选择取决于网络的策略和当前网络状态。
使用SRB0的场景
当gNB决定不接受UE的恢复请求时，它可能使用单个RRC消息立即拒绝该请求，这种情况下，UE会保持在RRC_INACTIVE状态。这种情况可能发生在网络过载或网络策略限制连接数量的场景下。在这种情况下，SRB0被使用，因为它简洁且不涉及安全机制，可以快速传递拒绝消息，避免不必要的资源浪费。
另一个使用SRB0的场景是当gNB决定建立一个新的RRC连接时。此时，由于UE和网络之间的上下文信息尚未建立，使用SRB0传输初始连接设置消息是合理的。
使用SRB1的场景
当gNB决定对UE进行重新配置，例如调整DRX（Discontinuous Reception）周期或更新RAN通知区域（RNA），或将UE推向RRC_IDLE状态时，使用SRB1是必要的。这是因为SRB1提供了完整性保护和加密功能，能够确保信令消息的安全性。这对于传输敏感的控制信息至关重要，如安全上下文的更新和连接参数的调整。