# 5G RRC 连接恢复（RRCResume）信令全链拆解：从 RRC_INACTIVE 到上下文获取 ## 一、为什么 5G 要引入 RRC_INACTIVE 与 Resume 机制 在 LTE 时代，UE 只有两种 RRC 状态——`RRC_IDLE` 和 `RRC_CONNECTED`。一旦业务结束，eNB 通过 `RRCConnectionRelease` 把 UE 推到 IDLE 态，NG-RAN 侧不再保留任何 UE 上下文；下次有数据到达时，UE 必须从随机接入、`RRCConnectionRequest`、NAS 业务请求、鉴权、安全模式命令、初始上下文建立一整套走下来，空口往返数十条信令，时延和信令风暴问题在 IoT 海量连接和微信/IM 类"心跳型"业务下被放大。 5G NR 在 TS 38.331 中引入了第三个状态 `RRC_INACTIVE`（参考 TS 38.300 第 4.2.4 节 UE state machine）。其核心思想是：**NG-RAN 侧（锚点 gNB）保留完整的 UE 应用层上下文（AS context，包括安全上下文、无线承载配置、PDU 会话与 QoS flow 映射、DRX 参数等），AMF 侧 N2 连接也保持**，只把空口"挂起"（suspend）。这样 UE 再次有数据时，只需要一条 `RRCResumeRequest` 就能把上下文"取回并激活"，跳过鉴权和 NAS 重建立，把恢复时延压到毫秒级。 ```mermaid flowchart LR IDLE[RRC_IDLE
无RRC上下文
无N2连接] -->|RRC Setup| CONN[RRC_CONNECTED
活跃传输] CONN -->|RRC Release with suspendConfig| INACT[RRC_INACTIVE
gNB保留上下文
N2保持
UE保留AS context] INACT -->|RRCResumeRequest / Resume| CONN INACT -->|RRC Release| IDLE CONN -->|RRC Release| IDLE INACT -.RNA Update.-> INACT style INACT fill:#fff4cc,stroke:#d4a017,stroke-width:2px ``` 理解这套机制的关键，是分清三个角色的分工：**UE**（持有挂起的 AS context 与 resumeIdentity）、**锚点 gNB（last serving gNB / Anchor）**（持有完整的 NG-RAN UE context）、**新 gNB（new gNB）**（UE 当前驻留小区、负责把上下文取回）。本文围绕 TS 38.331（RRC）、TS 38.413（NGAP）、TS 38.423（XnAP）三本规范，把 `RRCResume` 从 UE 发起请求到核心网路径切换、锚点释放的全链逐消息拆开。 ## 二、挂起态的"身份证"：I-RNTI 与 suspendConfig 进入 RRC_INACTIVE 的入口是 `RRCRelease` 消息中携带的 `suspendConfig`（TS 38.331 6.3.2），其中包含： - `rnti-Value`：即 **I-RNTI**（Inactive-RNTI），Resume 时唯一标识本 UE； - `ran-PagingCycle`：RAN 寻呼周期，决定 gNB 在 RNA 内寻呼 UE 的 DRX 周期； - `ranac-Value` / `ran-NotificationAreaInfo`：**RNA（RAN-based Notification Area）** 配置，即一组 UE 允许在不发起 Resume 的前提下移动的小区列表； - `t380`：周期性 RNA Update 定时器； - `nextHopChainingCount`（NCC）：用于后续 Resume 时密钥刷新推演。 **I-RNTI 的结构是这套机制的灵魂**。规范定义了两种长度（参考 TS 38.331 38.331 IE `I-RNTI-Value` 与各 RNTI 解析文献）： | 类型 | 长度 | 组成 | 用途 | |------|------|------|------| | Full I-RNTI | 40 bit | gNB ID（22~32 bit）+ UE ID（8~18 bit） | 跨 gNB 场景，新 gNB 据此定位锚点 gNB | | Short I-RNTI | 24 bit | 仅 UE ID（gNB ID 隐含为当前小区所属 gNB） | 同 gNB 内 Resume，节省空口开销 | 正是因为 Full I-RNTI 内嵌了锚点 gNB 的标识（gNB ID），UE 漫游到一个全新的 gNB 时，新 gNB 能从 I-RNTI 中解析出锚点是谁，进而通过 Xn 接口向锚点发起上下文获取。这是 Resume 能跨 gNB 工作的根本设计。 ## 三、完整信令时序：跨 gNB 的 RRCResume 下面是最具代表性的**跨 gNB Resume 场景**（UE 已离开锚点、在新 gNB 下发起恢复），它把 RRC、XnAP、NGAP、N4 全部串起来： ```mermaid sequenceDiagram participant UE participant NGNB as 新 gNB
(new gNB) participant AGNB as 锚点 gNB
(last serving gNB) participant AMF participant UPF Note over UE: RRC_INACTIVE，触发：上行数据/被叫RAN-Paging/周期RNAU UE->>NGNB: 1. RRCResumeRequest-1
(Full I-RNTI, resumeMAC-I, resumeCause) Note over NGNB: 解析 I-RNTI 得到 AGNB ID NGNB->>AGNB: 2. XnAP: RETRIEVE UE CONTEXT REQUEST alt 上下文命中且安全校验通过 AGNB->>NGNB: 3a. XnAP: RETRIEVE UE CONTEXT RESPONSE
(UE Context + 安全上下文 + AS配置 + DRX + 数据转发地址) NGNB->>UE: 4. RRCResume
(reconfigurationWithSync, 新C-RNTI, 激活安全, NCC) UE->>NGNB: 5. RRCResumeComplete NGNB->>AMF: 6. NGAP: PATH SWITCH REQUEST
(新N2 UE TNLA) AMF->>UPF: 7. PFCP Session Modification
(下行N3隧道切换到NGNB) UPF->>AMF: 8. PFCP Modify Response AMF->>NGNB: 9. NGAP: PATH SWITCH REQUEST ACK
(含新CN侧下行隧道) NGNB->>AGNB: 10. XnAP: UE CONTEXT RELEASE
(释放锚点上下文) AGNB-->>NGNB: 11. 下行数据转发(按需) else 上下文已失效/找不到 AGNB->>NGNB: 3b. XnAP: RETRIEVE UE CONTEXT FAILURE NGNB->>UE: 12. RRCSetup / RRCReject
(回退到全新建立) end ``` 逐步解析关键消息： **消息 1：RRCResumeRequest-1（CCCH，msg3，64 bit）** 携带 Full I-RNTI（40 bit）、resumeMAC-I（16 bit）、resumeCause（3 bit）。注意规范里有两个变体：`RRCResumeRequest-1`（含 Full I-RNTI，用于 msg3 竞争解决前的初始请求，因为此时还无法用 C-RNTI MAC CE）和 `RRCResumeRequest`（含 Short I-RNTI，48 bit，用于后续）。新 gNB 收到后第一件事是验证 resumeMAC-I——这是避免"伪造恢复请求"的关键安全闸门。 **消息 2-3a：XnAP 上下文获取** `RETRIEVE UE CONTEXT REQUEST`（TS 38.423 9.x）携带从 I-RNTI 解出的 UE 标识。锚点 gNB 在本地查表，若上下文仍有效（未因 RRC Release/越区等被删除），返回 `RETRIEVE UE CONTEXT RESPONSE`，内含完整的 NG-RAN UE Context（安全上下文、AS 配置、DRX、PDU 会话/QoS flow 信息、`RRC-Container` 承载的锚点 AS 配置）。**这一步把锚点的"记忆"原封不动搬给了新 gNB。** **消息 4-5：RRCResume 与 ResumeComplete** 新 gNB 基于 retrieve 到的上下文生成 `RRCResume`，通过 `reconfigurationWithSync` 给 UE 重新同步（新 C-RNTI、新的 SpCell 配置），同时执行安全激活（基于新 gNB 推演的密钥）。UE 应用配置、重建 MAC/RLC 后回 `RRCResumeComplete`，恢复完成。 **消息 6-9：NGAP 路径切换** 新 gNB 通过 `PATH SWITCH REQUEST`（TS 38.413 8.x）通知 AMF："UE 现在在我这里了"。AMF 触发 UPF 的 N3/N9 下行隧道端点从锚点切换到新 gNB（PFCP 会话修改），并回 `PATH SWITCH REQUEST ACKNOWLEDGE`，其中 AMF 可指示是否需要数据转发。完成后 N2 UE Context 在逻辑上迁移完毕。 **消息 10-11：锚点清理与数据转发** 新 gNB 向锚点发 `XnAP: UE CONTEXT RELEASE`，锚点释放 NG-RAN UE Context；下行数据在隧道切换瞬间通过 Xn 接口转发（data forwarding），避免丢包。 ## 四、RRCResumeRequest 的关键 IE 解析 ```mermaid flowchart TB REQ[RRCResumeRequest-1] --> IE1[resumeIdentity
Full I-RNTI 40bit] REQ --> IE2[resumeMAC-I
16bit 完整性短令牌] REQ --> IE3[resumeCause
3bit] IE1 -->|解析| GID[gNB ID → 定位锚点] IE1 -->|解析| UID[UE ID → 锚点本地索引] IE2 -->|校验| VERIFY[锚点用本地安全上下文重算并比对
验证UE身份+消息完整性] IE3 --> CAUSE{取值} CAUSE -->|emergency| C1[高优先级
触发立即恢复] CAUSE -->|highPriorityAccess| C1 CAUSE -->|mt-Access| C2[被叫:RAN-Paging触发] CAUSE -->|mo-Signalling/mo-Data| C3[主叫:上行数据] CAUSE -->|rnaUpdate| C4[周期性/移动出RNA] CAUSE -->|mps/mpc| C5[优先服务] ``` | IE 字段 | 比特/取值 | 作用与设计意图 | |---------|-----------|----------------| | `resumeIdentity` (Full I-RNTI) | 40 bit | 同时承担"找锚点"与"UE 索引"双重职责，避免额外寻址信令 | | `resumeMAC-I` | 16 bit | 用挂起前的完整性密钥 + Cell ID + Count 等输入，按 Annex B.2 计算；网络重算比对，**不恢复则不分配资源**，是抗伪造与重放的核心 | | `resumeCause` | 3 bit | 让 gNB 区分主叫/被叫/周期更新，决定调度优先级与是否回 RNAU 处理 | `resumeMAC-I` 的计算（Annex B.2，基于 shortMAC-I 算法）输入包括：挂起时保存的完整性密钥（来自上一连接的 AS 安全上下文）、当前小区 PCI、ARFCN、以及一个计数器。**这就要求 UE 和锚点 gNB 必须保留同一份挂起态安全上下文**——任何一方丢失上下文，比对都会失败，从而触发回退。 ## 五、锚点 gNB 的决策分支：Resume / Setup / Reject Resume 不是"一定能成功"。锚点 gNB 在处理时有三条分支（TS 38.331 5.3.x 与 38.423 Retrieve 流程）： 1. **正常 Resume**：上下文命中、resumeMAC-I 校验通过、目标 gNB 资源允许 → 走上文消息 3a→... 的完整路径。 2. **回退 RRCSetup**：返回 `RETRIEVE UE CONTEXT FAILURE`（上下文超时被删、安全校验失败、或锚点拒绝迁移），新 gNB 只能下发 `RRCSetup`，UE 走全新初始接入流程，挂起的 AS context 被丢弃。这是设计上的"优雅降级"。 3. **RRCReject**：拥塞、准入失败等场景，新 gNB 直接拒绝并携带 `waitTime`，UE 退避后重试。 ```mermaid stateDiagram-v2 [*] --> INACTIVE: RRCRelease(suspendConfig) INACTIVE --> REQ: 发起 RRCResumeRequest-1 REQ --> Verify: 锚点校验 resumeMAC-I + 上下文 Verify --> Resume: 校验通过 + 资源可用 Verify --> Setup: 上下文失效/校验失败 Verify --> Reject: 拥塞/拒绝 Resume --> CONNECTED: RRCResumeComplete + PathSwitch Setup --> IDLE: 走全新RRCSetup+NAS Reject --> INACTIVE: waitTime后退避重试 Resume --> [*] ``` ## 六、安全上下文：密钥如何"跨 gNB 刷新" Resume 绝不是简单"原样恢复"密钥，否则一旦旧密钥泄露就会全线失守。5G 采用**水平/垂直密钥推演**（TS 33.501 + 38.331）： - 挂起时锚点保存的 AS 根密钥是 `k<sub>gNB</sub>` 与 NCC； - 新 gNB retrieve 到上下文后，基于 NCC 与目标 PCI/频点做一次 **horizontal key derivation**（或在切换类场景做 vertical derivation），派生出新的 `k<sub>gNB</sub>*`； - `RRCResume` 中携带**新的 NCC**，UE 侧用同样的 KDF 输入推演出相同的新密钥； - 后续 AS 信令与用户面加密/完整性保护（RRC 用 128/256 位算法，UP 用 NEA/NEIA）全部基于新密钥。 **这就是 `nextHopChainingCount` 在 suspendConfig 与 RRCResume 里反复出现的原因**——它是 UE 与网络对齐密钥推演次数的"水位标"。一次 Resume 必伴随一次密钥刷新，保证前向安全。 ## 七、RNA Update：RRC_INACTIVE 内部的"保活" RNA（RAN-based Notification Area）是 gNB 配置的一组小区集合，覆盖范围通常远小于 TA。UE 在 RNA 内移动**不必发起任何信令**；但当发生以下情况时，UE 必须发起 **RNA Update（RNAU）**： - **周期性**：`t380` 超时（resumeCause = `rnaUpdate`）； - **移动出 RNA**：重选到不在 RNA 列表的小区。 RNAU 走的就是 `RRCResumeRequest`，只是 cause 置为 `rnaUpdate`。锚点 gNB 收到后通常有两种处理： - **重定位上下文**：UE 已离开锚点覆盖，锚点把上下文迁移到新 gNB，回 `RRCRelease`（带更新的 suspendConfig + 新 RNA）； - **不重定位**：UE 仍在锚点范围，锚点直接回 `RRCRelease`（带 suspendConfig）刷新 t380，UE 继续留在 RRC_INACTIVE。 RNAU 让 gNB 能在 RNA 粒度（而非 TA 粒度）掌握 UE 位置，**下行 RAN-Paging 只需在 RNA 这几个小区广播**，寻呼开销远小于核心网在 TA 列表寻呼。 ## 八、与 NAS Service Request 的关系（去重说明） 很多工程师会把 RRC Resume 和 NAS 层 Service Request 混为一谈。二者关系是**承载与被承载**： - 当 UE 在 RRC_INACTIVE 且 CM-IDLE（核心网认为其空闲）时，下行数据到达会触发 AMF 发 **RAN Paging**（走 N2 Paging 或 gNB 本地 RNA 寻呼）→ UE 收到后发 RRCResumeRequest（cause=mt-Access）→ 恢复 RRC； - 若 UE 同时需要从 CM-IDLE 转为 CM-CONNECTED，RRCResumeComplete 之后的上行 NAS 消息才会真正承载 `Service Request`（TS 23.502 4.2.3.2）。 - **关键优化**：在 RAN-based Notification Area 内，UE 的 Resume 可以做到"AMF 完全不感知"——因为 N2 连接一直挂着，AMF 仍认为 UE 是 CM-CONNECTED，从而连 Service Request 都省了。这正是 RRC_INACTIVE 相对 LTE 的信令节省所在。 ## 九、抓包识别与排错实战 **抓包识别要点**（Wireshark/TShark 过滤）： - RRC 层：`rrc.rrcResumeRequest_r17` 或 `nr-rrc.RRCResumeRequest` 消息名；CCCH 逻辑信道；msg3 中携带 I-RNTI； - XnAP：`xnap.RetryUEContext...` 实为 `RETRIEVE UE CONTEXT REQUEST/RESPONSE/FAILURE`； - NGAP：`pathSwitchRequest` 与 `pathSwitchRequestAcknowledge`； - 失败时关注 `RETRIEVE UE CONTEXT FAILURE` 与紧随的 `RRCSetup`。 **常见故障点与排查**： | 现象 | 根因方向 | 排查建议 | |------|----------|----------| | Resume 后立即回 RRCSetup | resumeMAC-I 校验失败 / 锚点上下文已老化 | 核对 UE 与锚点 AS 安全上下文是否一致；检查 suspendConfig 的 NCC 与 Cell ID 输入 | | 反复 RRC_INACTIVE 抖动 | t380 过短 / RNA 配置过小 / 业务心跳频繁 | 评估 IoT/IM 心跳周期与 ran-PagingCycle 匹配 | | 下行数据中断 | PathSwitch 后 N3 隧道未及时切换 / 数据转发地址缺失 | 检查 PFCP Session Modification 的 F-TEID 与 Xn data forwarding address | | 寻呼不到 UE | RNA 列表与 UE 实际小区不符 / DRX 周期不匹配 | 核对 ran-NotificationAreaInfo 与 ran-PagingCycle | - RNA 粒度：部分厂商以"同一 gNB 下所有小区"为最小 RNA 单元，部分支持跨 gNB 的 Cell 级 RNA 列表，影响 RAN Paging 范围与 RNAU 频率； - 锚点上下文保留时长（context timer）：各厂商实现不同，过短导致频繁回退 RRCSetup、过长占用内存，是网络优化重要参数； - 数据转发：切换瞬间是否启用 Xn 转发、转发时长，不同设备默认策略不同，影响丢包率。 ## 十、演进：Rel-16/17 的 SDT 小数据传输 到 Rel-16，规范进一步引入了 **SDT（Small Data Transmission）**，让 UE 在 RRC_INACTIVE 态**不进入 RRC_CONNECTED 就能收发小包数据**（TS 38.331 5.x SDT）： - **RA-SDT**：通过 4 步/2 步 RACH 携带小数据（msg3/msgA 直接带 MAC/RLC PDU）； - **CG-SDT**：gNB 预配置 Configured Grant，UE 在 inactive 态按预配置 PUSCH 资源直接发数据； - UE 在 SDT 期间若数据量超阈值或定时器到期，再升级为完整 RRCResume。 SDT 是 Resume 机制向"零中断小包"演进的延续，尤其服务于 mMTC/可穿戴/工业传感器场景。 ## 常见问题 **Q1：RRCResumeRequest-1（Full I-RNTI）和 RRCResumeRequest（Short I-RNTI）到底什么时候用哪个？** A：msg3 阶段（竞争解决前）必须用 `-1` 变体携带 Full I-RNTI，因为此时还没有 C-RNTI，网络只能靠 40 bit 的 Full I-RNTI 找到锚点；恢复建立、获得 C-RNTI 后的后续过程（如同 gNB 内的再次请求）可用 48 bit 的 Short 变体节省空口。协议这样设计是在"可路由性"和"开销"之间做了取舍。 **Q2：Resume 失败为什么会让网络回到 RRCSetup 而不是直接重传 ResumeRequest？** A：因为失败通常意味着锚点上下文已丢失或安全校验不过，UE 手里的挂起态上下文已经不可信，继续重试只会重复失败。回到 RRCSetup 走全新建立+鉴权，是规范定义的安全降级路径，保证 UE 最终能恢复服务。 **Q3：RRC_INACTIVE 期间 UE 还做哪些事？** A：UE 维持挂起的 AS context、按 ran-PagingCycle 监听 RAN Paging、执行小区重选、在 t380 超时或移出 RNA 时发 RNAU、可选执行 SDT。它本质上仍"附着"于网络，只是空口静默。 **Q4：RAN-Paging 和核心网 Paging 有什么区别？** A：核心网 Paging（AMF 经 N2 在 TA 列表寻呼）针对 CM-IDLE 的 UE，粒度是 TA；RAN-Paging 由锚点 gNB 发起、仅在 RNA 范围广播，针对 RRC_INACTIVE 的 UE，粒度更小、开销更低。这正是把寻呼责任从核心网下沉到 RAN 的关键收益。 **Q5：SDT 会取代 RRCResume 吗？** A：不会取代而是互补。SDT 只处理"小数据包且无需连接态特征"的场景；一旦数据量超阈值、需要反馈/调度灵活性或定时器到期，仍要升级到完整 RRCResume。两者共同构成 inactive 态的分层接入体系。 ## 参考来源 1. [3GPP TS 38.331 V17.13.0 — NR; Radio Resource Control (RRC) Protocol Specification](https://www.etsi.org/deliver/etsi_ts/138300_138399/138331/17.13.00_60/ts_138331v171300p.pdf) — RRC_INACTIVE 状态机、RRCResume/ResumeRequest/Complete、suspendConfig、Annex B.2 2. [ShareTechnote — 5G RRC Inactive](https://www.sharetechnote.com/html/5G/5G_RRC_Inactive.html) — RRC INACTIVE 状态与 RNA 流程图解 3. [3GPP Explorer — I-RNTI / RNA / RNAU Glossary](https://3gpp-explorer.com/glossary/i-rnti/) — I-RNTI 40/24 bit 结构与 RAN-based Notification Area 定义 4. [Amarisoft Tech Academy — NR RRC Inactive](https://tech-academy.amarisoft.com/NR_RrcInactive.html) — RRCRelease / Paging / ResumeRequest / Resume / ResumeComplete 信令与测试日志 5. [3GLTEInfo — 5G RRC Resume Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g-rrc-resume/) — 跨 gNB Resume 完整呼叫流程与上下文获取分析 --- > 本文由「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 等场景全覆盖。