51学通信

深度解析 3GPP TS 38.300：9.2 Intra-NR Mobility (Part 2 - RRC_INACTIVE态移动性)

19分钟阅读

好的，在深入剖…

深度解析 3GPP TS 38.300：9.2 Intra-NR Mobility (Part 2 - RRC_INACTIVE态移动性)

本文技术原理深度参考了3GPP TS 38.300 V18.5.0 (2025-03) Release 18规范中，关于“9.2.2 Mobility in RRC_INACTIVE”的核心章节，旨在为读者深入解读5G独有的RRC_INACTIVE状态下的移动性管理框架，包括其核心概念（RNA）、小区重选、状态转换以及上下文获取流程。

前言：“智能待机”下的“有限自由”

在上一篇文章中，我们探讨了UE在RRC_IDLE状态下的“自由漫游”。然而，IDLE态的“绝对自由”带来的是接入时延的巨大代价。为了在功耗和时延之间找到一个更优的平衡点，5G引入了全新的RRC_INACTIVE状态——一种“智能待机”模式。

我们的主角小明，刚刚结束了一次短暂的网页浏览，他的手机便从CONNECTED状态进入了INACTIVE状态。此刻，他正漫步在校园里。他的手机看似与IDLE状态时一样“无拘无束”，自主地在不同小区间切换。但在这“有限的自由”背后，却有一根无形的“风筝线”将他与网络紧密相连。这根线，就是被“冻结”并保存在最后一个服务基站（gNB）中的UE上下文（UE Context）。

导师老王向小玲解释道：“RRC_INACTIVE状态的移动性，是5G为了应对海量物联网连接和提升信令效率而设计的核心创新。它允许UE在一定区域内‘隐身’移动，但在需要时又能被快速‘找到’和‘唤醒’。这个‘一定区域’和‘唤醒’的机制，就是INACTIVE态移动性管理的核心。它的设计原则，就写在38.300的9.2.2节里。”

今天，我们将深入INACTIVE状态的幕后，探索UE是如何在这片被称为**RNA（RAN-based Notification Area）**的“牧场”里漫步，以及当它需要与外界联系，或者“走出牧场”时，网络是如何通过这根“风筝线”将其快速拉回的。

1. INACTIVE态移动性的核心概念 (9.2.2.1 Overview)

RRC_INACTIVE状态的核心，是在UE与网络之间达成的一种“君子协定”：UE可以在一个预先约定好的区域内自由移动而无需通知网络，而网络则承诺在此期间为UE保留其“身份档案”（AS上下文），以便快速恢复连接。

RRC_INACTIVE is a state where a UE remains in CM-CONNECTED and can move within an area configured by NG-RAN (the RNA) without notifying NG-RAN. In RRC_INACTIVE, the last serving gNB node keeps the UE context and the UE-associated NG connection with the serving AMF and UPF.

这段话包含了INACTIVE态的几个关键特征：

  • 保持核心网连接（CM-CONNECTED）：从核心网的角度看，UE始终处于连接状态，其PDU会话和核心网连接并未释放。

  • RAN侧上下文保持：UE的AS上下文（安全密钥、承载配置等）被保存在最后一个服务的gNB（称为Anchor gNB或Last Serving gNB）中。

  • 在RNA内自由移动：UE可以在一个由RAN配置的**通知区域（RNA）**内自由移动，无需上报位置。

  • RAN侧寻呼：当有下行数据到达时，由Anchor gNB在RNA区域内发起RAN寻呼。

2. “电子围栏”：RAN侧通知区域 (RNA) (9.2.2.3)

RNA（RAN-based Notification Area）是实现INACTIVE态移动性的“电子围栏”。gNB在将UE释放到INACTIVE状态时，会为其配置一个RNA。

A UE in the RRC_INACTIVE state can be configured by the last serving NG-RAN node with an RNA…

RNA的配置方式非常灵活，可以是以下几种形式之一：

  • 小区列表（List of cells）：最直接的方式，明确告诉UE哪些小区属于这个RNA。

  • RAN区域列表（List of RAN areas）：一个RAN Area由一个TAC（跟踪区码）和可选的RAN Area Code组成。这种方式更具扩展性，gNB只需广播自己属于哪个RAN Area，UE就可以自行判断是否仍在RNA内。

  • 核心网注册区（CN registration area）：在某些情况下，RNA可以与核心网的注册区（TA列表）保持一致。

a RAN-based notification area update (RNAU) is periodically sent by the UE and is also sent when the cell reselection procedure of the UE selects a cell that does not belong to the configured RNA.

UE在两种情况下需要主动联系网络，发起**RNA更新（RNAU）**流程：

  1. 移出RNA：当UE通过小区重选，移动到了一个不属于当前配置RNA的小区。它必须立即“报告”自己的新位置，以便网络能够更新其锚点gNB，并将寻呼区域切换到新的RNA。

  2. 周期性更新：为了让网络确认UE仍然“存活”，UE需要在一个由网络配置的周期性RNAU定时器超时时，主动发起一次RNAU，即使它并未移出RNA。

3. “熟悉的漫游”：INACTIVE态的小区重选 (9.2.2.2)

在RNA的“围栏”内部，UE的移动行为与IDLE态几乎完全相同。

A UE in RRC_INACTIVE performs cell reselection. The principles of the procedure are as for the RRC_IDLE state (see clause 9.2.1.2).

它同样遵循基于S准则和R准则的小区重选流程，持续监控服务小区和邻区的信号质量，自主地“择优而栖”。网络同样可以通过系统信息中的优先级、黑白名单等参数，来引导其重选行为。

唯一的区别是：UE在每次重选到一个新小区后，都需要检查这个新小区是否仍在当前RNA的范围内。

4. “快速唤醒”与“档案迁移”：状态转换 (9.2.2.4)

INACTIVE状态的真正魔力，体现在其高效的状态转换机制上。

4.1 UE触发的“快速恢复” (9.2.2.4.1)

当小明需要发送数据（例如，他想发一条消息），或者他移出了RNA需要上报位置时，就会触发从INACTIVE到CONNECTED的状态转换。这个过程被称为RRC连接恢复（RRC Resume）。

规范中的 Figure 9.2.2.4.1-1: UE triggered transition from RRC_INACTIVE to RRC_CONNECTED (UE context retrieval success) 描绘了最典型的“上下文获取”成功场景：

场景代入：小明（INACTIVE状态）在校园里移动，从gNB-A的覆盖区走到了gNB-B的覆盖区（gNB-A是他的Anchor gNB），然后他想发送消息。

  1. UE发起恢复请求：小明手机在gNB-B上发起随机接入，并在Msg3（RRCResumeRequest）中，携带一个关键信息——由gNB-A分配的I-RNTI。

  2. 新gNB请求上下文：gNB-B收到I-RNTI后，解析出其中的Anchor gNB（gNB-A）的标识。它通过Xn接口，向gNB-A发送**RETRIEVE UE CONTEXT REQUEST**消息，说：“请把I-RNTI为xxx的那个UE的档案给我。”

  3. 旧gNB提供上下文：gNB-A在本地找到小明的UE上下文（安全信息、承载配置等），通过**RETRIEVE UE CONTEXT RESPONSE**消息，将其完整地发送给gNB-B。

  4. RRC恢复完成：gNB-B收到上下文后，立即用这些信息恢复了与小明的安全和承载配置，并向UE发送RRCResume消息。UE收到后，发送RRCResumeComplete，连接快速恢复。

  5. 路径切换与旧上下文释放：gNB-B现在成为了新的服务gNB。它会通知核心网（AMF/UPF）将下行数据路径切换到自己这里（Path Switch）。切换完成后，它会通知gNB-A：“那个UE已经归我了，你可以删除他的档案了（UE CONTEXT RELEASE）。”

整个过程，由于UE上下文直接在RAN侧（gNB之间）传递，完全绕过了核心网的参与，信令路径短，处理速度快，时延远低于IDLE态的连接建立。

如果上下文获取失败呢？ 规范的 Figure 9.2.2.4.1-2 描述了这种情况。如果gNB-A由于某种原因（如上下文已超时删除）找不到小明的档案，它会回复一个失败消息。此时，gNB-B会“降级”处理，回退到完整的RRC连接建立流程，通过向AMF请求，重新为小明建立一个全新的上下文。

4.2 网络触发的“寻呼唤醒” (9.2.2.4.2)

当有下行数据要发给处于INACTIVE状态的小明时，网络会触发寻呼。

规范中的 Figure 9.2.2.4.2-1: Network triggered transition from RRC_INACTIVE to RRC_CONNECTED 展示了此流程：

  1. 数据到达Anchor gNB：下行数据到达小明的Anchor gNB（例如gNB-A）。

  2. RAN寻呼：gNB-A在其所管辖的、小明所在的RNA区域内，通过PCH信道发送寻呼消息。这个寻呼消息使用的是I-RNTI。如果RNA跨越了多个gNB，gNB-A还会通过Xn接口，请求邻居gNB协同寻呼。

  3. UE响应寻呼：小明手机在自己的RAN-Paging DRX时刻醒来，监听到自己的I-RNTI被寻呼。

  4. 发起恢复流程：UE立即发起RRC Resume流程，就像UE触发的场景一样，快速恢复到CONNECTED状态，准备接收数据。

5. 总结：“有管理的自治”——INACTIVE态的精髓

通过对9.2.2节的深入学习，我们揭示了RRC_INACTIVE状态下移动性的核心理念——“有管理的自治”。

  1. 自治的移动（小区重选）：在网络划定的RNA“牧场”内，UE拥有充分的移动自由，通过自主的小区重选来维持最佳的信号连接，无需向网络汇报，极大地降低了信令开销。

  2. 严格的管理（RNAU & 上下文）：这种自由是有限的。UE必须遵守“出界报告”（移出RNA时RNAU）和“定期报平安”（周期性RNAU）的规则。而网络通过在RAN侧锚定UE上下文，始终保留着对UE的快速控制能力。

  3. 高效的状态转换：无论是UE触发的Resume，还是网络触发的Paging，INACTIVE状态的核心优势都在于其基于RAN侧上下文获取的快速连接恢复机制，实现了远优于IDLE态的业务接入时延。

RRC_INACTIVE状态的设计，是5G为了平衡海量连接、低功耗和低时延这三大矛盾需求而祭出的“杀手锏”。它使得5G网络能够以极低的信令成本，管理数以亿计的、业务模式多样的物联网终端，是实现“万物互联”愿景的关键技术之一。

在下一篇文章中，我们将进入移动性管理的“主战场”——RRC_CONNECTED状态下的移动性，深入探讨5G的切换（Handover）技术，看看网络是如何为正在进行业务的UE，实现“无感”的平滑迁移。

FAQ

Q1：RRC_INACTIVE状态下的寻呼（RAN Paging）和RRC_IDLE状态下的寻呼（CN Paging）有什么主要区别？

A1：主要区别在于发起方、寻呼范围和使用的ID。

  • 发起方：CN Paging由**核心网（AMF）发起，通常用于IDLE状态。RAN Paging由最后一个服务的gNB（Anchor gNB）**发起，用于INACTIVE状态。

  • 寻呼范围：CN Paging的范围是整个跟踪区（TA），可能非常大。而RAN Paging的范围是RAN侧通知区（RNA），通常远小于TA，寻呼的无线资源开销更小。

  • 使用的ID：CN Paging使用UE的核心网临时ID，即5G-S-TMSI。而RAN Paging使用RAN侧为UE分配的I-RNTI。

Q2：什么是RNA更新（RNAU）？它和TA更新（TAU）有什么关系？

A2：RNAU是UE在RRC_INACTIVE状态下，为了更新其在RAN侧的位置信息而发起的流程。TAU（在5G中更准确地说是Registration Update）是UE在RRC_IDLE状态下，为了更新其在核心网侧的位置信息而发起的流程。关系：RNAU是一个纯粹的RAN内部流程（UE与gNB之间，gNB与gNB之间通过Xn交互），通常不涉及核心网。而TAU是一个NAS层流程，信令需要通过RAN透明地传递给核心网（AMF）。RNAU的信令开销和时延远低于TAU。

Q3：如果一个UE在RRC_INACTIVE状态下关机了，网络会如何处理它的上下文？

A3：当UE正常关机时，它会先发起一个信令流程，向网络（AMF）去附着（detach），AMF会通知gNB删除该UE的上下文。如果UE是异常掉电（例如，电池耗尽），Anchor gNB会因为长时间收不到该UE的周期性RNAU而最终判定该UE“失联”。gNB内部会有一个上下文保留定时器，当该定时器超时后，gNB就会清除这个“过期”的UE上下文，以释放资源。同时，核心网侧的AMF也会因为收不到UE的周期性注册更新，而在一个更长的时间尺度上（由Periodic Registration Update timer控制），将该UE标记为“不可达”。

Q4：为什么INACTIVE状态下的UE上下文要保存在gNB而不是AMF？

A4：保存在gNB是为了快。将上下文保存在离UE最近的RAN节点（Anchor gNB），有两大好处：1）快速恢复：当UE需要恢复连接时，新的服务gNB可以通过高速的Xn接口，直接从邻近的Anchor gNB获取上下文，整个过程在RAN内部完成，时延极低。如果上下文保存在AMF，则需要通过NG接口与远在核心网的AMF交互，信令路径长，时延大。2）RAN寻呼：当有下行数据到达时，由于数据路径的锚点UPF直接连接gNB，数据会先到达Anchor gNB。Anchor gNB可以直接发起RAN寻呼，无需先通知AMF再由AMF发起寻呼，流程更短，唤醒时延更低。

Q5：一个RNA可以跨越多个gNB吗？如果可以，上下文是如何传递的？

A5：可以。一个RNA可以由多个gNB下属的小区共同组成，但这要求这些gNB之间必须有Xn接口连接。当UE从Anchor gNB（gNB-A）下的小区，移动到同一个RNA内的另一个gNB（gNB-B）下的小区时，它不会立即发起RNAU。当有数据到达gNB-A时，gNB-A会在RNA内发起寻呼，并通过Xn接口请求gNB-B也帮忙寻呼。当UE在gNB-B上响应寻呼并发起RRCResumeRequest时，gNB-B就会通过Xn接口从gNB-A把UE的上下文“拉取”过来，并成为新的Anchor gNB，同时通知核心网进行路径切换。这个过程就是上下文的RAN内部迁移。

关系图谱