5G RAN寻呼区域RRC状态
admin
2023-10-20 00:20:28
0

新的RRC INACTIVE状态功能与RAN通知/寻呼区域的概念紧密耦合,其功能类似于UMTS URA区域。换句话说,具有有效AS上下文的UE可以在包括一个或多个小区的区域内移动,而不向网络发送任何通知。层2设想了如何定义RAN通知/寻呼区域的几个不同选项,其中已经考虑了两种主要方法——系统信息中的RAN area ID广播和小区的明确列表。然而,无论RAN通知/寻呼区域如何被定义并用信号通知给UE,UE具有两个支持附加过程以在新的INACTIVE状态下实现正确的功能。

参考TR 38.804和TS 38.800,RAN通知/寻呼区域的特征在于处于INACTIVE状态的以下UE行为:

  • 通知区域可以覆盖单个或多个小区,并且可以小于CN区域;
  • 当UE停留在通知区域的边界内时,UE不发送任何“位置更新”指示;
  • UE离开该区域时更新其到网络的位置。

下面的图1显示了包括Cell#1-5的示例性RAN通知区域。无论RAN通知/寻呼区域是如何定义的,只要UE停留在该区域内,UE就不会发送任何通知。如果它移动到例如Cell#6,则将发送相应的通知。




除了上面定义的RAN通知/区域“更新”过程之外,还需要有周期性的RAN区域更新过程。问题是,从核心网的角度来看,处于不活动RRC状态的UE被感知为已连接。结果,UE将不执行周期性TAU过程,这反过来触发需要具有某个RAN区域周期性更新过程。

1. 将RRC_INACTIVE定义为NR中的新RRC状态。

2. 当重新选择到不属于所配置的基于RAN的通知区域(RNA)的小区时,RRC_INACTIVE中的UE通过恢复过程周期性地通知NR RAN基于RAN位置区域更新(RLAU)。

值得注意的是,无论触发“RAN区域更新”过程(即跨越区域边界或定时器到期),UE都需要更新其到网络的位置,因此,假设连接恢复/激活过程是非常自然的。然而,网络还需要知道UE接入网络的原因。UE在向网络发送请求消息时应指示相应的“原因”。实际上,网络知道请求消息的原因(例如RAN区域更新、MO数据等)和UL缓冲值就足够了,以决定UE是否应该被发送回INACTIVE或移动到完全不同的状态。

1. 连接恢复消息将包括至少可以指示RAN区域更新的信息。不排除包含信息以实现访问控制。

一旦网络知道UE更新其RAN通知/寻呼区域位置,它就可以决定下一步做什么。网络最预期的动作将是将UE移动回提供相应RAN区域配置的INACTIVE状态。同时,UE下一步应该做什么最终取决于网络。作为示例,如果长时间没有用户面活动并且网络想要删除UE上下文,则网络可以将UE移动到CONNECTED状态(例如,如果存在下行数据)或将其移动到IDLE状态。此外,如果gNB丢失了UE上下文或无法从源锚gNB获取UE上下文,则连接恢复/激活过程甚至可能失败。基于此,发起“RAN区域更新”过程的UE应准备好从网络接收以下“命令”。

  • “Reconfiguration/Release”。网络可以将UE发送回INACTIVE状态或指示其移动到IDLE或CONNECTED。网络侧最预期的动作将是将UE移回INACTIVE。然而,网络还可以请求UE转移到CONNECTED状态(例如,如果网络具有下行数据)或移动到IDLE(例如,释放上下文)。
  • “Setup”。在这种情况下,网络请求UE建立具有新AS上下文的新RRC连接。当网络选择建立新连接时,最预期的情况是它不具有UE上下文或无法检索它。

“RAN区域更新”过程应该被理想地优化,以便网络和UE交换尽可能少的RRC消息。确保低RRC开销的最直接的方法是以这样的方式设计过程,即网络可以用单个响应消息发出所有必要的指令。换言之,来自网络的响应消息将告诉UE它应该使用相关配置参数进入哪个状态。应该注意,当目标状态为IDLE或INACTIVE时,可以很容易地完成。事实上,协议已经同意使用单个消息将UE从CONNECTED(已连接)移动到INACTIVE/IDLE(未激活/空闲),而没有“完整”消息,因此在接收到请求消息时可以遵循相同的原则。与CONNECTED to INACTIVE情况相比,唯一的区别是处于CONNECTED的UE激活了安全上下文,这意味着它可以从网络接收加密的RRC消息。

如果网络决定将UE重新配置为CONNECTED状态,则仍可能需要“完成”消息作为来自UE的所有物理级别参数已成功应用的最终指示。事实上,关于从INACTIVE到CONNECTED的过渡,层2的初步决定是使用三个RRC消息。然而,如果可以在转换到CONNECTED时消除“完整”消息,那么整个信令框架可以被统一。



相关内容