终端(UE)触发RRC_CONNECTED转换

进入RRC_INACTIVE状态后会因不同原因触发RRC连接，其中由终端触发到RRC_CONNECTED转换流程及消息如下；

一、UE触发流程到RRC_CONNECTED转换流程如图9.2.2.4.1-1所示：在UE上下文检索成功情况下UE触发从RRC_INACTIVE到RRC_CONNECTED的转换；

图9.2.2.4.1-1:UE上下文检索成功后触发到RRC_CONNECTED转换流程

二、UE触发消息解析

• Step1. UE从RRC_INACTIVE恢复由最后一个服务gNB提供分配的I-RNTI；

• Step2.如gNB能够解析包含在I-RNTI中的gNB标识，则gNB请求最后一个服务gNB提供UE上下文数据；

• Step3.最后一个服务gNB提供UE上下文数据；

• Step4/5. gNB和UE完成RRC连接的恢复；

  ----注意:如果授权允许，也可以在Step5中发送用户数据。

• Step6. 如应防止最后一个服务gNB中缓冲的DL用户数据丢失，则gNB提供转发地址。

• Step7/8.gNB执行路径切换。

• Step9.gNB触发最后一个服务gNB的UE资源的释放。

三、RRC_CONNECTED转换SRB使用在图9.2.2.4.1-1中Step1之后，当gNB决定使用单个RRC消息立即拒绝恢复请求并将 UE保持在RRC_INACTIVE状态而不进行任何重新配置时(如下面两个示例中所述)或者当gNB决定建立一个新的RRC连接使用SRB0(无安全性)。相反，当gNB决定重新配置UE(如使用新DRX周期或RNA)或当gNB决定将 UE推至RRC_IDLE时，应使用SRB1(具有先前为该SRB配置完整性保护和加密)。

----只有在检索到UE上下文后(即在Step3之后)才能使用SRB1。

四、UE上下文检索失败RRC_CONNECTED转换下图9.2.2.4.1-2描述了在UE上下文检索失败的情况下UE触发的从RRC_INACTIVE到RRC_CONNECTED的转换；

• Step1.UE从RRC_INACTIVE恢复，由最后一个服务gNB提供分配I-RNTI。

• Step2.如果gNB能够解析包含在I-RNTI中的gNB标识，则gNB请求最后一个服务gNB提供UE上下文数据。

• Step3..最后一个服务gNB无法检索或验证UE上下文数据。

• Step4.最后一个服务gNB向gNB指示故障。

• Step5.gNB通过发送RRCSetup执行回退以建立新的RRC连接。

• Step6. 如第2节所述建立新连接。

五、尝试RRC_CONNECTED转换网络拒绝下图(图9.2.2.4.1-3)描述了当UE尝试从RRC_INACTIVE恢复连接时网络的拒绝; 

• Step1.UE尝试从RRC_INACTIVE恢复连接;

• Step2.gNB无法处理该过程(例如由于拥塞);

• Step3.gNB送RRCReject(带有等待时间)以将UE保持在 RRC_INACTIVE状态。

本文根据3GPP R18 TS 38.300第9.2.2节编译整理