5G NR—— RRC_INACTIVE状态

---

RRC_INACTIVE是这样一种状态，UE仍然保持在CM-CONNECTED状态、且UE可以在RNA区域内移动而不用通知NG-RAN。UE处于RRC_INACTIVE状态时，最后一个服务gNB保留UE的上下文和UE相关联的与服务AMF和UPF的NG连接。从核心网看终端，其就和UE处于连接态一样。

当UE处于RRC_INACTIVE时，如果最后一个服务gNB收到来自UPF的下行数据或者来自AMF的下行信令，则该gNB在RNA的所有小区寻呼UE，如果RNA的小区属于邻gNB的，则通过Xn口给对应的邻gNB发送XnAP-RAN-Paging消息。如果RAN寻呼失败，则【见于TS23.501 5.3.3.2.5】：

-如果NG-RAN有NAS PDU要发给UE，则RAN节点应该发起AN Release流程释放UE的N2口连接，将UE的CM状态迁移到CM_IDLE态。

-如果NG-RAN仅仅只有用户面数据要发送给UE，则NG-RAN节点可以继续保留N2连接或者发起AN Release流程释放N2口连接，如何选择取决于NG-RAN的本地配置。

注：在RAN寻呼失败时触发RAN寻呼的用户面数据包可能会丢失。

AMF给NG-RAN提供RRC Inactive Assistance Information，以供NG-RAN用于决定UE是否可以进入RRC_INACTIVE状态；这个RRC Inactive Assistance Information信息包括：配置给UE的注册区、UE特定的DRX、周期注册定时器、MICO指示、UE id index值等。

见于TS38.413 9.3.1.15

AMF可以在“INITIAL CONTEXT SETUP REQUEST”或“UE CONTEXT MODIFICATION REQUEST”消息中将RRC Inactive Assistance Information参数带给gNB；UE的注册区参数用于给gNB配置UE的RAN-based notification area（RNA）时参考，UE特性的DRX和UE id index值用于寻呼UE，周期性注册定时器用于给gNB配置RNA更新定时器时参考。

进入RRC_INACTIVE状态时，NG-RAN会给UE配置RNA更新定时器，同时NG-RAN会启动一个RNA更新保护定时器，该保护定时器时长要比RNA更新定时器的长一些；如果RNA保护定时器超时，则NG-RAN发起AN Release流程（即UE CONTEXT RELEASE REQUEST流程）释放N2口连接。

处于RRC_INACTIVE状态的UE移动出了RNA范围时要发起RNA更新流程，接收RNA更新请求的gNB可以决定UE后续是出于RRC_INACTIVE状态或RRC_CONECTED状态或RRC_IDLE态。

---

1 RNA（RAN-Based Notification Area）

• RNA可以覆盖一个小区或者多个小区，但一定要在核心网配置的注册区范围内

• 当UE的RNA定时器超时或者UE移动出了RNA范围时，UE都要发起RANU（RAN-based notification area update）流程

关于如何配置RNA有几种不同的选择：

    -小区列表：

        >>gNB给UE提供一个明确的小区列表作为RNA。

    -RAN area列表：

        >>gNB给UE提供一个RAN area ID列表作为RNA，这里提供的RAN area是CN Tracking Area的一个子集或者等于CN Tracking Area，一个RAN area对应一个RAN arean ID，一个RAN area由TAI和一个可选的RAN area Code组成。

       >>一个小区会在其系统消息广播它的RAN area ID。

---

2 状态迁移

2.1 RRC_INACTIVE to RRC_CONNECTED （UE发起）

1. UE从RRC_INACTIVE恢复，提供由最后服务gNB分配的I-RNTI
2. 如果能够解析I-RNTI中包含的gNB身份，则gNB请求最后服务gNB提供UE上下文数据
3. 最后服务gNB提供UE上下文数据
4. gNB完成RRC连接的恢复
5. 如果要防止在最后服务gNB中缓冲的下行用户数据的丢失，则接入的gNB给最后服务gNB提供下行数据转发地址
6. gNB执行路径切换（向服务AMF发路径切换请求消息）
7. AMF回复路径切换响应消息
8. 通知最后服务gNB释放UE上下文

在上面的步骤1之后，当gNB决定拒绝恢复请求（且在没有任何重新配置的情况下）将UE继续保持在RRC_INACTIVE中，或者当gNB决定建立新的RRC连接时，可以使用SRB0（SRB0是完全没有安全保护的承载）；当gNB决定重新配置UE时（例如，使用新的DRX周期或RNA）或当gNB决定将UE切换到RRC_IDLE时，应使用SRB1（SRB1是至少具有完整性保护的承载）。

2.2 RRC_INACTIVE to RRC_CONNECTED（网络发起）

1. 发生RAN寻呼触发事件（收到下行用户面数据，来自5GC的下行信令等）

2. 触发RAN寻呼，寻呼范围是RNA

3. 使用 I-RNTI寻呼UE

4. 如果UE被寻呼到，则后续流程同上面的“2.1 RRC_INACTIVE to RRC_CONNECTED （UE发起）”

3 RNA更新流程

1. UE从RRC_INACTIVE恢复，提供由最后服务gNB分配的I-RNTI和适当的原因值，例如RAN通知区域更新。
2. 如果能够解析I-RNTI中包含的gNB身份，则gNB请求最后服务gNB提供UE上下文
3. 最后服务gNB提供UE上下文
4. gNB可以将UE切到RRC_CONNECTED状态，或者将UE切回RRC_INACTIVE状态或者将UE切到RRC_IDLE状态。 如果UE被切到RRC_IDLE，则不需要以下步骤
5. 如果要防止在最后服务gNB中缓冲的下行用户数据的丢失，则接入的gNB给最后服务gNB提供下行数据转发地址
6. gNB执行路径切换（向服务AMF发路径切换请求消息）
7. AMF回复路径切换响应消息
8. 通知最后服务gNB释放UE上下文

4 参考：

TS33.300 9.2.2

TS23.501 5.3.3.2.5 “CM-CONNECTED with RRC Inactive state”