本文承接"切换流程""TAU打卡""寻呼找人"等话题，把视角拉回到一个容易被忽略的中间地带——RRC非激活态（RRC_INACTIVE）。它既不像空闲态那样彻底断开，也不像连接态那样时刻在线，而是 5G 专门为"频繁小数据、海量物联网"场景设计的一种"半睡半醒"工作模式。理解它，就理解了 5G 为什么能把信令风暴压下去、又为什么能把唤醒时延压下来。
把手机的 RRC 状态想象成一个人的三种作息：
为什么要发明这第三种作息？因为 4G 时代只有"清醒"和"熟睡"两种选择，对于频繁发小数据的应用（即时消息心跳、智能水表上报、可穿戴设备同步），陷入了"两难"：
5G 的答案就是：在中间加一档"半睡半醒"——把空口关掉省电，但把上下文留在 RAN 侧省信令、省时延。而支撑这套"半睡半醒"还能被找到、还能正确切换工位的，正是本文的两个主角：RAN 寻呼和 RNA 更新。
理解 RNA 之前，先把非激活态的几个关键事实钉死。挂起（Suspend）发生时，网络做了一件很有"分寸"的事：
| 资源/状态 | 挂起后怎么处理 | 与空闲态的差别 |
|---|---|---|
| UE 的 AS 上下文（安全密钥、DRB 配置） | 同时保留在 UE 和最后服务 gNB | 空闲态完全删除 |
| NAS 信令连接（N1，UE↔AMF） | 保持，UE 仍处于 CM-CONNECTED | 空闲态为 CM-IDLE |
| NG 信令关联（N2，gNB↔AMF） | 保留（针对该 UE） | 空闲态释放 |
| N3 用户面隧道（UPF↔gNB） | 仍终结在最后服务 gNB | 空闲态无 N3 |
| 空口无线承载（Uu） | 释放，radio 关闭 | 同样关闭 |
这张表是后续一切机制的"地基"，记住一句话就够：非激活态下，UE 在 NAS 层面还是"连着"核心网的，只是空口睡着了。 这一点决定了后面寻呼该由谁发起、数据该往哪送。
正因为上下文还挂在 gNB 上，挂起时 gNB 会给 UE 分配一个临时身份 I-RNTI（Inactive-RNTI），它唯一地指向"这个 UE 的上下文存在哪个 gNB 里"。唤醒时，UE 只要把 I-RNTI 报出来，目标 gNB 就知道该去找谁"取回上下文"。
stateDiagram-v2
[*] --> IDLE
IDLE --> CONNECTED: 连接建立（重量级）
CONNECTED --> IDLE: 释放（Release，删上下文）
CONNECTED --> INACTIVE: 挂起（Suspend，留上下文）
INACTIVE --> CONNECTED: 恢复（Resume，轻量级）
INACTIVE --> IDLE: 上下文丢失/拒绝回退
note right of INACTIVE
5G新增"半睡半醒"态
· UE上下文保留在gNB
· NAS保持CM-CONNECTED
· N3隧道仍在最后服务gNB
end note
现在问题来了：UE 在非激活态下空口是关的，它会像空闲态一样自主地做小区重选到处走动。那么网络怎么知道它大概在哪、来了下行数据该往哪里找？
核心网的办法是"注册区（TA 列表）"——只要你还在 TA 列表里，就不用报告位置（这就是 TAU 打卡的逻辑）。但非激活态的上下文留在单个 gNB，核心网那一套粒度太粗。于是 5G 在 RAN 层又画了一个更小的圈：RNA（RAN-based Notification Area，接入网通知区）。
挂起 UE 时，最后服务 gNB 通过 suspendConfig 给 UE 配一个 RNA，它满足三条铁律：
用一张图表示三层嵌套关系，你会发现粒度从粗到细、寻呼范围也从大到小：
graph TD
TA["注册区 TA List（AMF分配 · CN级 · 寻呼范围大）"]
RNA["RNA 接入网通知区（gNB配置 · RAN级 · 寻呼范围小）"]
C1["小区 Cell-1（gNB-A）"]
C2["小区 Cell-2（gNB-A）"]
C3["小区 Cell-3（gNB-B，Xn可达）"]
C4["小区 Cell-4（RNA外，但仍在TA内）"]
TA --> RNA
TA --> C4
RNA --> C1
RNA --> C2
RNA --> C3
style RNA fill:#cfe8fc,stroke:#1f77b4,stroke-width:2px
style C4 fill:#ffd6d6,stroke:#d62728
为什么 RNA 要做得比 TA 小？ 因为这里要权衡一对永恒的矛盾——寻呼成本 vs. 位置更新成本：
这就是为什么运营商在密集城区和稀疏农村会配不同大小的 RNA——本质是在 寻呼负载 × 寻呼范围 和 更新次数 × 更新成本 两块开销之间找平衡点。
UE 在非激活态下的移动性，分两种情况，先看简单的。
当 UE 仍待在配置的 RNA 内部时，它只是安静地做小区重选（空闲态那一套，按 S 准则、R 准则挑更好的小区驻留），全程不触发任何上行信令。网络根本不知道 UE 此刻具体在哪个小区，只知道"它在 RNA 这个圈里的某处"。
这样做的好处显而易见：
风险也恰恰在这里：网络只掌握 UE 的"粗位置（RNA 级）"，真到了要发数据时，只能在 RNA 全境发寻呼。所以 RNA 不能太大，否则一个 UE 的下行数据就要惊动整个 RNA 的小区。
当 UE 小区重选到了一个不属于当前 RNA 的细胞，或者 gNB 配的周期性 RNA 更新定时器 T380 到期，UE 就必须执行一次 RNA Update（RNA 更新），告诉网络"我挪窝了"。这本质上是一次带特殊原因值的 RRC 恢复请求，目的是让网络更新 UE 的位置锚点。
完整信令时序如下：
sequenceDiagram
autonumber
participant UE
participant TG as 目标gNB(当前驻留)
participant OG as 最后服务gNB(上下文所在)
participant AMF
UE->>UE: 驻留小区RNA ID不匹配 / T380超时
UE->>TG: RRCResumeRequest(I-RNTI, cause=RNA-Update)
TG->>OG: XnAP Retrieve UE Context
OG-->>TG: UE Context(AS+安全上下文)
TG->>AMF: NGAP Path Switch Request(N3迁到目标gNB)
AMF-->>TG: Path Switch Response
TG->>UE: RRCRelease + suspendConfig(可能配新RNA)
TG->>OG: XnAP Release UE Context(可选)
Note over UE,TG: 注意：纯位置更新无数据，恢复后又立即重新挂起
几个工程上很关键的细节：
把 RNA 更新和核心网的 TAU 放在一起对比，你会看到 RAN 在"抄核心网的作业"，但抄得更轻、更快：
| 维度 | TAU（核心网级） | RNA Update（接入网级） |
|---|---|---|
| 触发条件 | 走出 TA 列表 / 周期定时器到期 | 走出 RNA / T380 定时器到期 |
| 适用的 UE 状态 | RRC_IDLE（CM-IDLE） | RRC_INACTIVE（CM-CONNECTED） |
| 执行过程 | 完整 NAS 注册流程 + RRC 建立 | RRC Resume（带原因值）+ 重新挂起 |
| 上下文 | 核心网保留，RAN 侧无 | RAN 侧保留并跨站搬运 |
| 信令开销 | 大（涉及 AMF 多条 NAS 消息） | 小（主要在 RRC/Xn 层完成） |
| 目的 | 让核心网知道 UE 在哪个 TA | 让最后服务 gNB 锚点更新到 UE 当前位置 |
一句话总结：TAU 是给"熟睡"的人重新登记位置，RNA Update 是给"半睡半醒"的人悄悄换个沙发。
UE 在 RNA 内安静待着，万一这时候下行数据来了怎么办？这就是非激活态可达性的核心机制——RAN 寻呼。
先回到那张"地基表"：非激活态下 N3 隧道仍终结在最后服务 gNB，且 UE 仍是 CM-CONNECTED。这意味着下行数据不会像空闲态那样被核心网拦下后触发 CN 寻呼，而是直接顺着 N3 隧道送到最后服务 gNB。这个 gNB 手里有数据、有 UE 的上下文，却没有空口——于是由它（而非 AMF）来发起寻呼。这就是"RAN 寻呼"这个名字的由来：寻呼的发起方从核心网挪到了接入网。
sequenceDiagram
autonumber
participant UE as UE（INACTIVE·DRX休眠中）
participant G1 as 最后服务gNB(含N3隧道+UE上下文)
participant G2 as 邻居gNB(覆盖RNA其他小区)
participant UPF
UPF->>G1: 下行数据(沿N3隧道直达G1)
G1->>G1: 缓存数据 + 发起RAN寻呼
G1->>G1: 本站RNA小区:PCCH发Paging
G1->>G2: XnAP Paging(RNA内其他小区)
G2->>G2: 本站RNA小区:PCCH发Paging
Note over UE: 在寻呼时机PO醒来监听
UE->>G2: 收到匹配I-RNTI的寻呼
UE->>G2: RRCResumeRequest(I-RNTI)
G2->>G1: XnAP Retrieve UE Context
G1-->>G2: UE Context
G2->>UE: RRCResume
G2->>UPF: （经AMF Path Switch）下行数据投递
注意 RAN 寻呼的覆盖范围是 RNA，而不是 TA。这一步直接带来两个收益：
$$ N_{\text{paging}} \;\propto\; \underbrace{|\text{RNA}|}{\text{寻呼小区数}} \;\ll\; \underbrace{|\text{TA}|} $$}
$$ T_{\text{wake}}^{\text{(INACTIVE)}} \approx T_{\text{RRC Resume}} \;\ll\; T_{\text{wake}}^{\text{(IDLE)}} \approx T_{\text{CN Paging}} + T_{\text{RRC Setup}} + T_{\text{NAS}} $$
那 UE 怎么知道何时该醒来听寻呼？靠 DRX（非连续接收）。非激活态 UE 并非每时每刻都监听，而是按 DRX 周期在固定的寻呼时机（Paging Occasion, PO）醒来。每个 UE 该在哪个子帧醒来，由一个确定性公式决定（UE_ID 由 5G-S-TMSI 推得）：
$$ i_s = \left\lfloor \frac{\text{UE_ID}}{N \cdot N_s} \right\rfloor \bmod N_s,\qquad N = \min(T,\, n_B),\;\; N_s = \max!\left(1,\;\frac{n_B}{T}\right) $$
其中 $T$ 是 DRX 周期，$n_B$ 控制每个周期内寻呼密度。这套机制让海量 UE 被均匀分散到不同的 PO 上，避免所有终端在同一时刻醒来造成寻呼信道拥塞——这正是 5G 支撑海量物联网并发寻呼的关键。
还有一个 RAN 寻呼特有的"小技巧"：寻呼消息里携带的是 I-RNTI（或其短形式），而不是空闲态 CN 寻呼用的 5G-S-TMSI。UE 比对 I-RNTI 命中后，发起的就是带 I-RNTI 的恢复请求，目标 gNB 据此精准取回上下文。
这套原理不是悬在空中的，它在现网抓包、网优排障里非常具体。
1. 抓包看 resumeCause，一眼判断 UE"为什么醒"。 在 RRC 层日志里，RRCResumeRequest 的原因值是分诊的第一指标：
mt-Access（Mobile Terminated）→ 多半是 RAN 寻呼把它叫醒的，有下行数据在等；mo-Signalling / mo-Data → UE 自己有上行需求；rna-Update → 纯位置更新，正常现象。排查陷阱：如果网络里大量 UE 频繁出现 rna-Update，说明 RNA 配得太小了，UE 一走动就出圈，位置更新信令被放大——这时要调大 RNA。反过来，如果某个 gNB 的 RAN 寻呼负载高到拥塞，说明 RNA 配太大了，要调小。这两类问题在 KPI 上分别表现为"信令量异常"和"寻呼失败率升高"，根因都在 RNA 粒度。
2. 抓 Xn 接口看"上下文取回"成败。 Retrieve UE Context 失败（最后服务 gNB 已删上下文）是非激活态"降级回空闲态"的常见原因。出现这种情况时，UE 会走完整 RRC 建立，时延陡增。常见诱因：UE 在非激活态待得太久、最后服务 gNB 重启或上下文被 GC 清理、Xn 链路抖动。定位方法是看 XnAP 消息对——Request 发出但 Response 没回（或回了 Failure），就把锅坐实在"上下文丢失"上。
3. 区分"RAN 寻呼"和"CN 寻呼"。 这是最容易混的两个概念。简单判据：寻呼消息里用 I-RNTI → RAN 寻呼（UE 在非激活态）；用 5G-S-TMSI → CN 寻呼（UE 在空闲态）。如果一个本该在非激活态的 UE 却触发了 CN 寻呼，多半是它已经被降级回空闲态了，要往前追"为什么降级"。
4. 关注 N3 隧道锚点。 RAN 寻呼的前提是 N3 隧道还指向最后服务 gNB。如果发现下行数据到了 gNB 却迟迟没有 RAN 寻呼发出，要怀疑 gNB 是否误以为 UE 仍是连接态、或隧道状态不一致——这属于"控制面与用户面状态不同步"的疑难杂症。
把"移动性（出 RNA 打卡）"和"可达性（RAN 寻呼找人）"两条主线串起来，整个半连接态的设计哲学就清晰了：
flowchart TD
subgraph 触发["触发源"]
T1["下行数据到达(UPF→最后服务gNB)"]
T2["UE走出RNA / T380超时"]
end
subgraph 机制["两条主线"]
M1["RAN寻呼(RNA范围内找人)"]
M2["RNA更新(打卡报告位置)"]
end
subgraph 结果["统一动作"]
A1["RRC Resume(I-RNTI)"]
A2["XnAP 取回UE上下文"]
A3["N3隧道迁到当前gNB"]
end
subgraph 收尾["收尾"]
E1["有数据→进入连接态收发"]
E2["纯位置更新→重新挂起,可能配新RNA"]
end
T1 --> M1 --> A1 --> A2 --> A3 --> E1
T2 --> M2 --> A1
A3 --> E2
style M1 fill:#cfe8fc,stroke:#1f77b4
style M2 fill:#d4edda,stroke:#28a745
你会发现，无论是"被人找"还是"主动打卡"，最终都收敛到同一套恢复机制：发恢复请求 → 跨站取回上下文 → 迁移 N3 锚点。区别只在收尾——有数据就进连接态干活，没数据就重新挂起回去睡。这种"一套机制、两种用法"的设计，把信令复杂度压到了最低，正是 5G 应对海量终端的精妙之处。
Q1：RRC_INACTIVE 和 RRC_IDLE 最大的区别是什么？ A：一句话——上下文在不在线。非激活态的 UE 上下文（含安全、承载配置）保留在 UE 和最后服务 gNB，NAS 仍是 CM-CONNECTED，N3 隧道仍在；空闲态则全部释放、N1 断开。所以非激活态唤醒是"轻量级恢复"，空闲态唤醒是"重量级重建"。
Q2：RNA 和注册区（TA 列表）是什么关系？ A：RNA 是 gNB 在挂起 UE 时配置的、RAN 层面的"通知圈"；TA 列表是 AMF 分配的、CN 层面的"注册圈"。RNA 一定包含在 TA 列表之内，且粒度更细。UE 出 RNA 做 RNA Update，出 TA 列表做 TAU——后者更"重"。
Q3：为什么下行数据要由"最后服务 gNB"发起 RAN 寻呼，而不是核心网发起？ A：因为非激活态下 N3 隧道仍终结在最后服务 gNB，数据被直接送到这里。由它在 RNA 本地范围内发起寻呼，比回到 AMF 走全核心网寻呼范围更小、时延更低、CN 信令更省。
Q4：UE 在非激活态什么时候会"掉回"空闲态？ A：最常见的是上下文取回失败（最后服务 gNB 已删 UE 上下文、Xn 不可达），目标 gNB 拒绝恢复，UE 回退到空闲态重新建立。其次是无线链路长时间失败、或网络主动让 UE 去注册。掉回空闲态意味着丧失了非激活态的低时延优势。
Q5：RNA 配大好还是配小好？ A：没有标准答案，是寻呼成本与位置更新成本的权衡。RNA 大→UE 不易出圈、更新少，但单次寻呼要覆盖更多小区、寻呼信令大；RNA 小→寻呼省，但更新频繁。现网通常按业务密度和终端移动性分场景配置，密集城区偏小、广域物联网偏大。
本文由「51学通信」技术团队出品。51学通信由通信行业 18 年老兵爱卫生（微信 ID: gprshome201101）维护，聚焦 5G/6G 核心网、3GPP 标准解读、通信前沿技术深度分析。 出版作品有《5G 核心网原理与实践》《IMS 原理与实践》等 4 本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。