5G NR—— RRC_INACTIVE状态

一、RRC_INACTIVE 状态的引入

在RRC_INACTIVE mode引入前，LTE原来只有RRC_IDLE和RRC_CONNECTED两种RRC状态， R13之后，LTE RRC新引入了一个新的inactive mode。

5G/NR的R15规范中延续了R13引入的inactive状态项，也就是NR下RRC有三种状态：IDLE、INACTIVE、ACTIVE (CONNECTED)。

那么为什么要引入inactive mode？

其实与LTE中的NB-IoT类似，NB-IoT属于部署低功耗场景，RRC_INACTIVE mode主要是为了降低终端能耗，并减小时延。而5G/NR的三大典型应用场景之一的mMTC正包含了NB-IoT。（当然RRC_INACTIVE态不局限于mMTC场景）

那么在inactive mode下如何实现能耗降低和时延减小的呢？

大致有以下三个原因：

（1）UE在进入RRC_INACTIVE态时会保留核心网的上下文 ；直到在RRC_INACTIVE态下出现有数据接收或发送，需要跃迁至RRC_CONNETED态时，只需要通过恢复过程携带核心网唯一UE标识进行恢复即可，并且在gNB收到连接恢复完成后就可以接收和发送数据包了。

（2）相比于以往的RRC_IDLE态直接跃迁RRC_CONNETED态（需要释放核心网所申请的上下文，在申请上下文时，需要与核心网侧进行信令的交互），RRC_INACTIVE态下跃迁至RRC_CONNECTED态则可以略去上述过程。

（3）UE接收gNB的信令消息时都需要去盲检PDCCH，以便知道信令所在的资源位置。而RRC_INACTIVE态跃迁至RRC_CONNECTED态时，由于UE并没有释放上下文，并且核心网侧也不需要再次分配上下文，因此减少了信令的接收。进而减少UE盲检带来的能耗以及空口传输带来的传输时间。

二、三种状态的区别与阐释

ACTIVE (CONNECTED): UE 和NG-RAN---connected NG-RAN和5GC---connected
IDLE: UE 和NG-RAN---released NG-RAN和5GC---released
INACTIVE: UE 和NG-RAN---suspend NG-RAN和5GC---connected

RRC_IDLE（空闲模式）：

PLMN选择;

广播系统信息;

小区重选移动性;

移动终止数据的寻呼由5GC发起;

移动终接数据区域的寻呼由5GC管理;

由NAS配置的用于CN寻呼的DRX。

上层可能为终端配置一个特定的DRX，用于处于空闲态的终端周期性地醒来接收可能来自网络的寻呼消息
终端根据网络配置控制移动性，即终端通过小区重选的方式来实现移动性管理。
UE行为 ：
★★ 监控PDCCH上传输的短信息（P-RNTI）；
★★ 监控 CN寻呼（5G-S-TMSI）；
★★ 执行邻区测量，小区选择或小区重选；
★★ 获取系统消息，可发送SI请求消息（if Configured）；
★★ 根据logged测量配置，记录包含location和time信息的测量数据；
★★ 根据logged测量配置，记录包含location和time信息的测量数据

RRC_INACTIVE(去激活模式) ：

PLMN选择;

广播系统信息;

小区重选移动性;

寻呼由NG-RAN（RAN寻呼）发起;

基于RAN的通知区域（RNA）由NG-RAN管理;

由NG-RAN配置的RAN寻呼DRX;

为UE建立5GC-NG-RAN连接（包括控制面 / 用户面）;

UE AS报文存储在NG-RAN和UE中;

NG-RAN知道UE所属的RNA。

RRC_INACTIVE态的UE，其行为不但包括RRC_IDLE态的所有，还需要存储 UE Inactive AS上下文，以及RAN区域同步。其中RAN区域同步尤其重要，包括如下：

RRC层为终端配置RAN通知区
监控PCH上的RAN寻呼（full I-RNTI）
当UE进入一个RAN通知区外的小区时，需要执行RAN区域通知过程
周期性地执行RAN区域通知过程

RRC_ACTIVE (CONNECTED)（连接模式）：

为UE建立5GC-NG-RAN连接（包括控制面 / 用户面）;

UE AS报文存储在NG-RAN和UE中;

NG-RAN知道UE所属的小区;

向或从UE传输单播数据;

网络控制移动性，包括测量。

AS上下文存储在NG-RAN和UE中。
传输数据。
At lower layers, the UE may be configured with a UE specific DRX
对于支持CA的终端，利用一个或多个SCells与SpCell聚合，以达到增加带宽的目的。
对于支持DC的终端，利用一个SCG与MCG聚合，以达到增加带宽的目的。
网络侧控制NR系统内或系统间的移动性。
UE行为 ：
★★ 监控PDCCH上传输的短信息（P-RNTI）
★★ 监控共享数据信道相关的控制信道，从而感知是否有相关的调度数据
★★上报信道质量信息给网络侧
★★ 邻区测量以及测量报告上报
★★ 获取系统消息
★★ 执行即时MDT（ Minimization of Drive Tests）

三. RRC_IDLE和RRC_INACTIVE态的移动性

空闲态和非激活态下的移动机制，其目的是确保网络可以联系到终端。网络通过寻呼消息来通知终端完成此操作。

发送寻呼小区的区域是寻呼设计机制的关键。

四. 进入inactive 态基站CU DU 分别需要做些什么

在5G网络中，RRC Inactive状态是一种节能状态，允许UE（用户设备）在不需要进行数据传输时减少与网络的通信，从而节省电量。当UE从RRC Connected状态进入RRC Inactive状态时，基站（gNB）的CU（Central Unit）和DU（Distributed Unit）需要执行以下操作：

基站CU（Central Unit）需要做的操作：

状态管理：CU需要更新UE的状态信息，将UE标记为RRC Inactive状态。
上下文保存：CU需要保存UE的RRC上下文信息，包括UE的能力、安全上下文、移动性管理上下文等，以便在UE需要重新激活时快速恢复连接。
寻呼信息更新：CU需要更新与UE相关的寻呼信息，确保当有下行数据到达时，能够正确地寻呼到UE。
安全处理：CU需要确保在RRC Inactive状态下，UE和网络之间的安全连接得以维持，包括密钥和算法的保存。
信令处理：CU处理UE进入RRC Inactive状态的信令流程，包括与DU的协调。

基站DU（Distributed Unit）需要做的操作：

资源释放：DU需要释放UE在RRC Connected状态下所占用的无线资源，如PRB（Physical Resource Block）。
上下文保存：DU需要保存UE的无线资源上下文，包括UE的传输和接收参数，以便在UE重新激活时快速恢复。
测量报告停止：DU停止接收UE的测量报告，因为这些报告在RRC Inactive状态下不是必须的。
同步信息更新：DU需要更新与UE同步相关的信息，以支持UE在RRC Inactive状态下的潜在小区重选。
寻呼准备：DU需要准备好接收来自CU的寻呼请求，并在UE处于RRC Inactive状态时能够有效地寻呼UE。
信令协调：DU与CU协调，确保RRC Inactive状态的信令流程正确执行。

当UE进入RRC Inactive状态后，CU和DU将不再维持与UE的持续RRC连接，而是通过NAS信令保持连接。这种状态下，UE可以迁移到其他小区而无需通知网络，直到需要重新建立RRC连接（例如，当有下行数据到达或UE需要上行通信时）。网络侧通过Paging过程来通知UE重新建立RRC连接。

如下图所示为UE进入RRC inactive 态的信令流程

参考：https://blog.csdn.net/weixin_45766278/article/details/126928988

参考资料：

3GPP 38.331

TS33.300 9.2.2

TS23.501 5.3.3.2.5 "CM-CONNECTED with RRC Inactive state"

RNA：RAN-based notification area，基于RAN的通知区域。

RNAU：RAN-based notification area update，RNA更新