1114-5G RRC状态及转换

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

5G RRC状态及转换
从LTE开始,无线网络的目标是
允许UE保持在“始终连接”模式,这有效地涵盖了许多场景,例如初始建立连接或过渡到UE可以开始与网络交换数据的状态。

在RAN2#98会议期间,NR引入了
INACTIVE状态,该状态被建模为独立的RRC状态。

其实在层
2还考虑了许多状态转换案例,并就如何实现这些案例做出了决定。

如何准确地引用IN ACTIVE状态以及CONNECTED是否引用特定RRC状态或是否应该有一种方法来指示UE具有A S上下文,而不管其处于何种RRC状态。

在3G时代,也就是UMTS系统中引入了不同的RRC状态。

参考TS
25.331,从NAS层的角度来看,UE可以处于空闲模式或连接模式,因此连接模式包括另外四种不同的RRC状态:URA_PCH、CELL_PCH、CellL_FACH和CELL_DCH。

当准确的RRC状态不重要时,这种方法允许区分IDLE和CONNECTED模式,但更重要的是强调UE具有AS上下文。

同时,可以参考特定RRC状态,例如CELL_DCH。

图1:图1:UMTS系统中NAS/AS状态的逻辑建模。

对于NR系统,可能会出现与UMTS中完全相同的术语问题:有时需要指示UE处于CONNECT ED模式,这意味着它具有as上下文,而有时需要参考特定的RRC状态(例如,INACTIVE 或ACTIVE/CONNECTED)。

考虑到NR第2阶段和第3阶段规范已经将RRC状态称为RRC_IDLE 、RRC_INACTIVE和RRC_CONNECTED,可以通过如下图2所示区分特定的RRC状态和“模式”。

该方法的另一个优点是它与LTE技术(只有IDLE和CONNECTED)在逻辑上一致,并且当连接到5G CN时也可能具有INACTIVE状态。

图2:NR系统的NAS/AS状态的逻辑建模
避免术语歧义的一种更激进的方法是将RRC_CONNECTED状态重命名为RRC_ACTIVE,如图3所示。

换句话说,CONNECTED模式将包含两种RRC状态:RRC_INACTIVE和RRC_ACTIVE。

优点是CONNECTED模式将明确地指代AS模式,并且不会与图2所示的相应RRC状态混淆。

这种方法的缺点是,即使NR RRC_ACTIVE 将直接对应于LTE CONNECTED ,名称也会不同。

图3:NR 系统的NAS/AS 状态的逻辑建模(替代方案)。

图4提供了NR
RRC 状态机的高级概述,以及RRC 状态之间的可能转换。

INACTIVE 被建模为独立的RRC 状态,因此可以设想以下状态转换情况:
● 从IDLE 到CONNECTED 以及从CONNECTED 到IDLE ; ● 从已连接到未激活,以及从未激活到已连接; ● 从停用到空闲。

图4:NR RRC 状态机。

关于从INACTIVE 状态到IDLE 状态的状态转换,可能存在各种错误情况,因此UE 丢失其上下文或重新排序以重新建立其RRC 连接和AS 上下文。

除此之外,还有由网络内部RRM 机制触发的正常RRC 连接释放过程。

即使可以假设没有用户面活动的
UE 将长时间保持在INACTIVE 状态,但不能假设网络将无限地保持UE 处于该状态;也不能强制执行这种网络行为。

此外,即使网络原则上可以在不通知UE 的情况下删除UE 上下文,并在下一次连接尝试时要求其建立新连接,但这不是运行整个系统的最有效方式,因为UE 将需要更多时间来恢复其连接。

除此之外,某些潜在特征的功能,例如INACTIVE 中的数据传输,将要求网络保持UE 上下文,结果,网络仍将寻求发送明确指示以释放UE RRC 连接。

图5:从INACTIVE转换到IDLE(完全)的信令程序。

用于将UE从INACTIVE重新配置为IDLE的基线过程是使得网络首先将UE带到CONNECTED模式,从该模式可以将其连接释放到IDLE。

然而,如图5所示,它将涉及在gNB和UE之间交换的大量RRC消息,因为前者必须寻呼UE(1条消息),确保其已进入CONNECTED模式(3条消息用于基线恢复过程),并最终释放连接(1条信息)。

当网络确实有理由将U E移动到CONNECTED状态之后,可以将其释放到IDLE时,该动作序列更适用于这种情况。

减少RRC消息数量的最简单方法之一是允许网络响应请求消息发送消息(例如RRCConne ctionRelease)。

相应的一组消息如下图5所示,涉及UE和网络之间交换的3个RRC消息。

响应消息是否应该始终加密并通过SRB1发送,以便UE可以信任它,或者是否也允许
通过SRB0发送响应消息。

图5:从
INACTIVE 转换到IDLE 的信令程序(优化)。

从图5中可以看出,仍需要3个RRC 消息将UE 从INACTIVE 移动到IDLE ,可以认为,将UE 从一个功率有效状态移动到另一个功率高效状态是一个简单操作的巨大信令开销。

进一步最小化RRC 消息数量的解决方案之一是对RRC 寻呼消息采用新的原因值,这将指示UE 释放其连接。

如图6所示,一旦UE 从网络接收到寻呼+释放指示,它将向网络发送“完
成”消息,确认接收到该寻呼指示符。

如果网络从UE 接收到响应,则它将知道UE
已经接收到寻呼并且将释放其连接;否则网络可以考虑重新发送寻呼消息。

图6:从INACTIVE 转换到IDLE (寻呼释放)的信令程序。

作为图6所示解决方案的进一步优化,可以考虑从UE 中删除“完整”消息。

此解决方案已经存在于UMTS 规范中,但由于没有来自UE 的“响应”,因此有些不可靠。

换言之,当网络发出带有“释放”命令的寻呼消息时,后者不知道UE 是否接收到该寻呼消息,
因此不知道如何到达该寻呼消息。

另一方面,处于INACTIVE状态的UE也可以接收CN寻呼消息,这意味着即使UE错过了RAN级寻呼,它仍将对网络稍后可能发送的CN寻呼采取行动。

图7:从INACTIVE转换到IDLE(paging)的过程。

相关文档
最新文档