5G RRC Inactive态移动性管理

5G RRC Inactive态移动性管理，相比空闲态，RRC INACTIVE态有更快的接入时延

将其信令流程与RRC Inactive态到RRC连接态的信令流程进行对比，可以发现RRC Inactive态下通过RRC Resume流程节省了大量的信令交互(例如Uu口上减少了RRC重配置过程、安全模式配置过程，NG口上减少了context建立过程、鉴权流程等)，这些信令交互的节省就使RRC Inactive态相对RRC空闲态获得了更快的接入时延。

RNA

RNA由一个或多个小区组成，相同RNA内的小区需要属于同一TAC区域。

UE处于RRC空闲态时，网络为了找到UE，需要核心网在TAI列表中的所有TA下的所有小区下发寻呼，我们将此称为核心网级别的终端跟踪。

显然，在这种级别的终端跟踪下，由于绝大多数寻呼消息是在UE不在的小区中下发的，所以会产生较高的寻呼消息传输开销。

要想节省传输开销，就需要缩小寻呼消息下发的范围。而要缩小寻呼消息下发的范围，又需要网络侧管理更小粒度的UE所在区域。处于RRC空闲态的UE，网络侧管理的最小粒度区域只能到核心网的TA。

针对处于RRC Inactive态的UE，为了进一步节省寻呼消息的传输开销，引入了比TA范围更小的“RNA(RAN-based Notification Area)”的概念，RNA由gNodeB管理，gNodeB可以基于RNA对UE进行寻呼(RAN寻呼)来找到UE，我们将此称为无线接入网络级别的终端跟踪。

gNodB如何在RNA中找到UE

RRC INACTIVE 开通后，需要先配置RNA。gNodeB基于RNA对UE进行RAN寻呼来找到UE

触发RAN Paging时，寻呼消息会发送UE所属的RNA区域(图中的RNA1的区域)中所有与Last serving gNodeB有Xn连接、且外部邻区的RNA ID为RNA1的小区(图中蓝框内的区域)

其中与Last serving gNodeB没有Xn连接的gNodeB下的小区，或外部邻区的RNA ID没有配置为RNA1的小区不会被寻呼

RAN寻呼是网络侧发起的，为了保证网络侧能够找到UE，要求在网络规划阶段，RNA区域内各gNodeB间需要规划有Xn接口，且外部邻区需要规划配置对应的RNA ID

RNA更新

Last Serving gNodeB可以根据I-RNTI推导出UE是否移出了配置的RNA。

当UE移出了配置的RNA，Last Serving gNodeB会决定将UE上下文提供给gNodeB，重新由gNodeB来管理UE上下文，我们将此场景称为有UE上下重定位。

当UE未移出配置的RNA，Last Serving gNodeB不会将UE上下文提供给gNodeB，仍由Last Serving gNodeB来管理UE上下文，我们将此场景称为没有UE上下重定位，此场景下的RNA更新流程一般是周期性地触发。

通过RNA的更新，网络侧能随时获取UE当前所处的RNA。