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 重建立，把恢复时延压到毫秒级。

flowchart LR
    IDLE[RRC_IDLE<br/>无RRC上下文<br/>无N2连接] -->|RRC Setup| CONN[RRC_CONNECTED<br/>活跃传输]
    CONN -->|RRC Release with suspendConfig| INACT[RRC_INACTIVE<br/>gNB保留上下文<br/>N2保持<br/>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 内嵌了锚点 gNB 的标识（gNB ID），UE 漫游到一个全新的 gNB 时，新 gNB 能从 I-RNTI 中解析出锚点是谁，进而通过 Xn 接口向锚点发起上下文获取。这是 Resume 能跨 gNB 工作的根本设计。

三、完整信令时序：跨 gNB 的 RRCResume

下面是最具代表性的跨 gNB Resume 场景（UE 已离开锚点、在新 gNB 下发起恢复），它把 RRC、XnAP、NGAP、N4 全部串起来：

sequenceDiagram
    participant UE
    participant NGNB as 新 gNB<br/>(new gNB)
    participant AGNB as 锚点 gNB<br/>(last serving gNB)
    participant AMF
    participant UPF

    Note over UE: RRC_INACTIVE，触发：上行数据/被叫RAN-Paging/周期RNAU
    UE->>NGNB: 1. RRCResumeRequest-1<br/>(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<br/>(UE Context + 安全上下文 + AS配置 + DRX + 数据转发地址)
        NGNB->>UE: 4. RRCResume<br/>(reconfigurationWithSync, 新C-RNTI, 激活安全, NCC)
        UE->>NGNB: 5. RRCResumeComplete
        NGNB->>AMF: 6. NGAP: PATH SWITCH REQUEST<br/>(新N2 UE TNLA)
        AMF->>UPF: 7. PFCP Session Modification<br/>(下行N3隧道切换到NGNB)
        UPF->>AMF: 8. PFCP Modify Response
        AMF->>NGNB: 9. NGAP: PATH SWITCH REQUEST ACK<br/>(含新CN侧下行隧道)
        NGNB->>AGNB: 10. XnAP: UE CONTEXT RELEASE<br/>(释放锚点上下文)
        AGNB-->>NGNB: 11. 下行数据转发(按需)
    else 上下文已失效/找不到
        AGNB->>NGNB: 3b. XnAP: RETRIEVE UE CONTEXT FAILURE
        NGNB->>UE: 12. RRCSetup / RRCReject<br/>(回退到全新建立)
    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 解析

flowchart TB
    REQ[RRCResumeRequest-1] --> IE1[resumeIdentity<br/>Full I-RNTI 40bit]
    REQ --> IE2[resumeMAC-I<br/>16bit 完整性短令牌]
    REQ --> IE3[resumeCause<br/>3bit]
    IE1 -->|解析| GID[gNB ID → 定位锚点]
    IE1 -->|解析| UID[UE ID → 锚点本地索引]
    IE2 -->|校验| VERIFY[锚点用本地安全上下文重算并比对<br/>验证UE身份+消息完整性]
    IE3 --> CAUSE{取值}
    CAUSE -->|emergency| C1[高优先级<br/>触发立即恢复]
    CAUSE -->|highPriorityAccess| C1
    CAUSE -->|mt-Access| C2[被叫:RAN-Paging触发]
    CAUSE -->|mo-Signalling/mo-Data| C3[主叫:上行数据]
    CAUSE -->|rnaUpdate| C4[周期性/移动出RNA]
    CAUSE -->|mps/mpc| C5[优先服务]

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 退避后重试。

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。

常见故障点与排查：

• 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 — RRC_INACTIVE 状态机、RRCResume/ResumeRequest/Complete、suspendConfig、Annex B.2
2. ShareTechnote — 5G RRC Inactive — RRC INACTIVE 状态与 RNA 流程图解
3. 3GPP Explorer — I-RNTI / RNA / RNAU Glossary — I-RNTI 40/24 bit 结构与 RAN-based Notification Area 定义
4. Amarisoft Tech Academy — NR RRC Inactive — RRCRelease / Paging / ResumeRequest / Resume / ResumeComplete 信令与测试日志
5. 3GLTEInfo — 5G RRC Resume Procedure Call Flow — 跨 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 等场景全覆盖。