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值等。

5G NR—— RRC_INACTIVE状态_第1张图片 见于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发起)

5G NR—— RRC_INACTIVE状态_第2张图片

  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(网络发起)

5G NR—— RRC_INACTIVE状态_第3张图片

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

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

  3. 使用 I-RNTI寻呼UE

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

3 RNA更新流程

5G NR—— RRC_INACTIVE状态_第4张图片

  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”

 

 

你可能感兴趣的:(5G)