# RNA：5G半连接态的寻人与打卡 > 本文承接"切换流程""TAU打卡""寻呼找人"等话题，把视角拉回到一个容易被忽略的中间地带——**RRC非激活态（RRC_INACTIVE）**。它既不像空闲态那样彻底断开，也不像连接态那样时刻在线，而是 5G 专门为"频繁小数据、海量物联网"场景设计的一种"半睡半醒"工作模式。理解它，就理解了 5G 为什么能把信令风暴压下去、又为什么能把唤醒时延压下来。 --- ## 一、从一个生活类比说起：手机的三种"作息" 把手机的 RRC 状态想象成一个人的三种作息： - **清醒（RRC_CONNECTED）**：眼睛瞪着、耳朵竖着，老板（基站）随时派活都能立刻接——但耗电，不可能 24 小时这样。 - **熟睡（RRC_IDLE）**：彻底下班，工牌都交了（上下文全释放），谁也找不到你，只能靠广播大喇叭（核心网寻呼）全城喊。被找到后，得重新走一遍入职流程（重建安全上下文、重配无线承载）才能干活。 - **半睡半醒（RRC_INACTIVE）**：这是 5G 新增的作息。人躺在沙发上，眼睛闭着、省着电，但**工牌还挂在脖子上、岗位上下文（AS 安全上下文、无线承载配置、QoS）原封不动留在工位（最后服务的 gNB）上**。一旦有活，不用重新入职，"砰"一下弹起来（RRC Resume）就能继续上次的工作。 为什么要发明这第三种作息？因为 4G 时代只有"清醒"和"熟睡"两种选择，对于**频繁发小数据的应用**（即时消息心跳、智能水表上报、可穿戴设备同步），陷入了"两难"： - 一直清醒——耗电如流水，基站也要为每个 UE 保留信令连接，海量终端时**核心网信令被压垮**； - 让它熟睡——每次来一个数据包都得经历"核心网寻呼→UE 响应→重建安全→重建承载"这一长串，**时延高、信令开销大**，而且数据越频繁，"入职—下班—入职"的循环越剧烈，反而比一直清醒更耗信令。 5G 的答案就是：**在中间加一档"半睡半醒"**——把空口关掉省电，但把上下文留在 RAN 侧省信令、省时延。而支撑这套"半睡半醒"还能被找到、还能正确切换工位的，正是本文的两个主角：**RAN 寻呼**和 **RNA 更新**。 --- ## 二、RRC_INACTIVE 到底"悬"在哪里 理解 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 就知道该去找谁"取回上下文"。 ```mermaid 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 ``` --- ## 三、RNA：给半睡半醒的人画一个"值班范围" 现在问题来了：UE 在非激活态下空口是关的，它会像空闲态一样**自主地做小区重选**到处走动。那么网络怎么知道它大概在哪、来了下行数据该往哪里找？ 核心网的办法是"注册区（TA 列表）"——只要你还在 TA 列表里，就不用报告位置（这就是 TAU 打卡的逻辑）。但非激活态的上下文留在**单个 gNB**，核心网那一套粒度太粗。于是 5G 在 RAN 层又画了一个更小的圈：**RNA（RAN-based Notification Area，接入网通知区）**。 挂起 UE 时，最后服务 gNB 通过 `suspendConfig` 给 UE 配一个 RNA，它满足三条铁律： 1. **RNA 是小区的集合**——可以是一个小区，也可以是一组小区，且可以**跨多个 gNB**（前提是这些 gNB 之间有 Xn 接口）。 2. **RNA 一定 ⊂ 注册区（TA 列表）**——RAN 画的圈不能超出核心网给 UE 的注册区。 3. **UE 在 RNA 内随意走动，不必通知网络**——只有走出 RNA，或定时器到期，才需要"打卡"。 用一张图表示三层嵌套关系，你会发现粒度从粗到细、寻呼范围也从大到小： ```mermaid 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 越不容易走出 RNA，**RNA 更新（打卡）次数越少**，但下行数据来了要寻呼的小区越多，**寻呼信令越大**； - RNA 越小，寻呼成本低，但 UE 频繁出 RNA、频繁打卡，**位置更新信令越大**。 这就是为什么运营商在密集城区和稀疏农村会配不同大小的 RNA——本质是在 `寻呼负载 × 寻呼范围` 和 `更新次数 × 更新成本` 两块开销之间找平衡点。 --- ## 四、移动性之一：RNA 内"自由走、不打扰" UE 在非激活态下的移动性，分两种情况，先看简单的。 当 UE 仍待在配置的 RNA 内部时，它只是安静地做**小区重选**（空闲态那一套，按 S 准则、R 准则挑更好的小区驻留），全程**不触发任何上行信令**。网络根本不知道 UE 此刻具体在哪个小区，只知道"它在 RNA 这个圈里的某处"。 这样做的好处显而易见： - UE 省电——只做被动的测量和重选，不发射信号； - 网络省信令——圈内怎么走都不打扰 gNB。 **风险**也恰恰在这里：网络只掌握 UE 的"粗位置（RNA 级）"，真到了要发数据时，只能在 RNA 全境发寻呼。所以 RNA 不能太大，否则一个 UE 的下行数据就要惊动整个 RNA 的小区。 --- ## 五、移动性之二：走出 RNA，必须"打卡"（RNA Update） 当 UE 小区重选到了一个**不属于当前 RNA 的细胞**，或者 gNB 配的**周期性 RNA 更新定时器 T380 到期**，UE 就必须执行一次 **RNA Update（RNA 更新）**，告诉网络"我挪窝了"。这本质上是一次带特殊原因值的 **RRC 恢复请求**，目的是让网络更新 UE 的位置锚点。 完整信令时序如下： ```mermaid 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: 注意：纯位置更新无数据，恢复后又立即重新挂起 ``` 几个工程上很关键的细节： 1. **原因值（resumeCause）= RNA-Update**。它告诉目标 gNB"我恢复不是为了发数据，只是来报告位置的"，于是目标 gNB 在完成上下文迁移后，**立刻把 UE 再挂起**，而不是让它进入连接态空耗。这是和"有数据要发"的普通恢复最大的区别。 2. **上下文跨站搬运**：目标 gNB 用 I-RNTI 找到最后服务 gNB，通过 Xn 接口的"取回 UE 上下文"过程把上下文搬过来。如果搬失败了（比如最后服务 gNB 已经把上下文删了），目标 gNB 会**拒绝恢复**，UE 只能掉回 RRC_IDLE，重新走一遍完整建立——这是非激活态最怕的"降级"。 3. **N3 隧道迁移**：恢复成功后，下行数据隧道（UPF→gNB）从最后服务 gNB 切到目标 gNB，保证后续 RAN 寻呼、数据投递都以新 gNB 为锚点。 4. **新 RNA 可能被重新配置**：目标 gNB 可以在重新挂起时给 UE 配一个新的 RNA，以它自己为中心——这样 UE 又获得了一段"圈内自由走动"的额度。 把 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 是给"半睡半醒"的人悄悄换个沙发。** --- ## 六、可达性：RAN 寻呼——半睡半醒的人怎么被叫醒 UE 在 RNA 内安静待着，万一这时候**下行数据来了**怎么办？这就是非激活态可达性的核心机制——**RAN 寻呼**。 先回到那张"地基表"：非激活态下 **N3 隧道仍终结在最后服务 gNB**，且 UE 仍是 CM-CONNECTED。这意味着下行数据不会像空闲态那样被核心网拦下后触发 CN 寻呼，而是**直接顺着 N3 隧道送到最后服务 gNB**。这个 gNB 手里有数据、有 UE 的上下文，却没有空口——于是由它（而非 AMF）来发起寻呼。这就是"RAN 寻呼"这个名字的由来：**寻呼的发起方从核心网挪到了接入网。** ```mermaid 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。这一步直接带来两个收益： - **寻呼范围小**：RNA 小区数 ≪ TA 小区数，平均寻呼信令量显著下降。可以近似表达为： $$ N_{\text{paging}} \;\propto\; \underbrace{|\text{RNA}|}_{\text{寻呼小区数}} \;\ll\; \underbrace{|\text{TA}|}_{\text{空闲态寻呼小区数}} $$ - **寻呼延迟低**：因为是"最后服务 gNB"在本地发起，不必回到 AMF 走一整套 CN 寻呼流程，端到端唤醒时延也更短： $$ 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 寻呼找人）"两条主线串起来，整个半连接态的设计哲学就清晰了： ```mermaid 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 小→寻呼省，但更新频繁。现网通常按业务密度和终端移动性分场景配置，密集城区偏小、广域物联网偏大。 --- ## 参考来源 1. [LTE-5G 学习笔记：5G NR 非活动态的移动性（CSDN）](https://blog.csdn.net/wxq_wuxingquan/article/details/91474223) — 系统介绍 RRC_INACTIVE 下的小区重选、RAN 寻呼失败处理与 RNA 更新程序，中文工程视角。 2. [5G RRC Inactive 总结及部分 log 示例（知乎）](https://zhuanlan.zhihu.com/p/591298124) — 结合真实 log 讲解挂起/恢复、RNA、I-RNTI 与 RAN 寻呼，贴近排障实战。 3. [5G NR RRC INACTIVE State and RAN-Based Notification Area (RNA) — TelecomHall](https://www.telecomhall.net/t/5g-nr-rrc-inactive-state-and-ran-based-notification-area-rna/20238) — 英文社区对非激活态、RNA 配置与寻呼机制的原理性梳理。 4. [NR RRC 状态详解：寻呼（搜狐）](https://www.sohu.com/a/471728660_121124364) — 对比 RRC 三状态下的寻呼发起方、寻呼身份与覆盖范围。 5. [5G 移动通信系统设计与标准详解·非激活态（微信读书）](https://weread.qq.com/web/reader/1dc32e8071d82b271dcdf5eked332ca0262ed3d2c2191f2) — 从系统设计角度解释非激活态在时延与能耗上的折中。 --- > 本文由「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 等场景全覆盖。