5G RRC_INACTIVE 连接恢复流程：从 I-RNTI 定位到 resumeMAC-I 认证的全景拆解

一、为什么 5G 要发明一个"半挂起"状态

在 4G LTE 时代，UE 只有 RRC_IDLE 和 RRC_CONNECTED 两个 RRC 状态。一旦没有数据传输，网络只能选择把 UE 彻底释放到 IDLE——这意味着下一次有业务时必须重新执行完整的 RRC 建立、NAS 业务请求、鉴权、安全激活、承载建立一整套流程，时延动辄上百毫秒，信令开销巨大。对于即时通信、心跳包这类"突发小流量"业务，UE 在 IDLE 和 CONNECTED 之间反复横跳，既费电又费信令。

5G NR 在 TS 38.331 Section 4.2.1 中引入了第三个 RRC 状态——RRC_INACTIVE。它的设计哲学是：NAS 层保持 CM-CONNECTED（UE 与 AMF 的 N2 连接、UE 上下文在 RAN 侧以"挂起态"完整保留），但空口 RRC 连接被挂起。当业务再次到来时，UE 通过 RRCResumeRequest 这条极短的 CCCH 消息就能"原地复活"，复用此前挂起的 AS 上下文（无线承载配置、安全上下文、QoS 流映射），从而把恢复时延压缩到几十毫秒级别。

本文聚焦的核心问题不是"INACTIVE 状态长什么样"，而是 UE 发出恢复请求之后，网络如何在不重新鉴权的前提下相信这条请求确实来自那个被挂起的 UE——这正是 resumeMAC-I 与 I-RNTI 这对组合要解决的认证问题，对应 TS 38.331 Section 5.3.13 与 Section 5.3.1.4 的安全处理机制。

二、三状态转换全景

stateDiagram-v2
    [*] --> RRC_IDLE
    RRC_IDLE --> RRC_CONNECTED: RRC Setup (4步RACH)
    RRC_CONNECTED --> RRC_INACTIVE: RRC Release + suspendConfig
    RRC_INACTIVE --> RRC_CONNECTED: RRC Resume Request (本篇重点)
    RRC_INACTIVE --> RRC_IDLE: RRC Resume Reject / 超时回退
    RRC_CONNECTED --> RRC_IDLE: RRC Release (无suspendConfig)
    RRC_INACTIVE --> RRC_INACTIVE: RNA Update (跨通知区)
    note right of RRC_INACTIVE
        NAS 仍为 CM-CONNECTED
        UE 上下文挂在 anchor gNB
        AS 上下文本地存储 (含密钥/NCC)
    end note

理解恢复流程，必须先理解进入 INACTIVE 的前提。当 gNB 通过 RRCRelease 消息（TS 38.331 Section 5.3.8）并携带 suspendConfig 字段时，UE 会执行"挂起"动作：存储完整的 AS 上下文（包括所有 DRB/SRB 配置、当前安全密钥 kgNB、nextHopChainingCount 即 NCC），并保存网络分配的 I-RNTI。最后服务 UE 的那个 gNB 被称为 anchor gNB，它负责保留 UE 的 NG 接口上下文和 N2 连接。

三、I-RNTI：RAN 范围内的临时身份证

INACTIVE 态的 UE 不再有 C-RNTI，取而代之的是 I-RNTI（Inactive-RNTI）。根据 TS 38.331，它有两种长度：

这个设计很巧妙：40 bit 的 Full I-RNTI 既能唯一标识 UE，又能编码出"anchor gNB 是谁"。当 UE 移动到一个新的（非 anchor）gNB 下发起恢复时，新 gNB 解析出 I-RNTI 中的 gNB ID 字段，就知道该向谁去索取挂起的 UE 上下文——这是整个跨站恢复流程得以成立的基础。

I-RNTI 在 RRCResumeRequest 消息中以 resumeIdentity 字段出现，承载在 UL-CCCH 逻辑信道上（TS 38.331 Section 6.2.2）。

四、resumeMAC-I：一条 CCCH 消息如何证明"我是我"

这是整个恢复流程中最精妙的安全设计。RRCResumeRequest 走的是公共控制信道 CCCH，此时还没有激活专用 AS 安全（SRB1 的加密/完整性保护尚未恢复），所以这条请求本身是"明文"在空口传输的。那么网络凭什么相信发出请求的 UE 就是当初那个被挂起的 UE，而不是一个伪造 I-RNTI 的攻击者？

答案就是 resumeMAC-I 字段。

4.1 计算原理

根据 TS 33.501 的密钥层级与 TS 38.331 Section 5.3.1.4，resumeMAC-I 的计算逻辑如下：

flowchart TD
    A["挂起前存储的上下文"] --> B["kgNB 密钥"]
    A --> C["nextHopChainingCount (NCC)"]
    A --> D["当前接入小区 PCI / 频点"]
    B --> E["派生 KRRCint 完整性密钥"]
    E --> F["用 KRRCint 对<br/>RRCResumeRequest 消息<br/>+ BEARER/DIRECTION/COUNT<br/>计算完整 MAC-I"]
    C --> F
    G["短认证令牌"] --> F
    F --> H["取 MAC-I 的 16 个最低有效位<br/>= resumeMAC-I (16 bit)"]
    H --> I["随 RRCResumeRequest 发送"]
    I --> J["gNB 用同样算法重算并比对"]
    J -->|一致| K["认证通过, 恢复上下文"]
    J -->|不一致| L["拒绝 / 回退 RRC Setup"]

具体而言（基于 TS 38.331 ASN.1 描述与 nrexplained 的解读）：UE 利用挂起前保存的 KRRCint 完整性密钥，对将要发送的 RRCResumeRequest 消息内容进行完整性计算，得到完整的 128 bit MAC-I，然后取其 16 个最低有效位（16 LSB）作为 resumeMAC-I。之所以只取 16 bit，是因为 CCCH 消息要尽可能短以节省空口资源和 RACH 容量。

网络侧（收到请求的 gNB）拿到上下文后，用同样的密钥和算法重新计算 MAC-I，比对低 16 位。若一致，则证明：该 UE 确实持有挂起时的密钥材料（即拥有合法的 AS 上下文），身份可信。这本质上是一次基于共享密钥的"轻量级挑战-响应认证"，绕开了完整的 NAS 层 5G-AKA 流程。

4.2 关键 IE 结构

RRCResumeRequest（TS 38.331 Section 6.2.2）的字段极简，通常只有几个关键 IE：

其中 resumeCause 的取值包括 emergency、highPriorityAccess、mt-Access（被叫，通常响应 Paging）、mo-Signaling、mo-Data、mo-VoiceCall、mo-ExceptionData 等。该字段会被 gNB 用于接入控制（UAC，TS 38.331 Section 5.3.14）和优先级判断。

五、完整信令时序：成功恢复、跨站获取上下文

下面给出最常见的"UE 移动到非 anchor gNB 下发起恢复"的完整时序，这是最考验协议实现的场景：

sequenceDiagram
    participant UE as UE (RRC_INACTIVE)
    participant gNB as Serving gNB (新)
    participant Anchor as Anchor gNB
    participant AMF as AMF

    Note over UE: 有上行数据 / 收到 RAN Paging
    UE->>gNB: 1. PRACH (Msg1/MsgA)
    gNB->>UE: 2. RAR (Msg2/MsgB), 分配 TC-RNTI
    Note over UE: 用挂起密钥算 resumeMAC-I
    UE->>gNB: 3. RRCResumeRequest (CCCH)<br/>resumeIdentity + resumeMAC-I + resumeCause
    Note over gNB: 本地无该 UE 上下文
    gNB->>gNB: 4. 从 I-RNTI 解析出 Anchor gNB ID
    gNB->>Anchor: 5. RETRIEVE UE CONTEXT REQUEST (XnAP)
    Anchor->>gNB: 6. RETRIEVE UE CONTEXT RESPONSE<br/>(含 AS 上下文, kgNB*, NCC, DRB 配置)
    Note over gNB: 7. 用 kgNB* 重算 MAC-I<br/>与 resumeMAC-I 比对
    alt 认证通过
        gNB->>gNB: 8a. 派生新 kgNB (horizontal/vertical)<br/>生成新 C-RNTI
        gNB->>UE: 9a. RRCResume (DCCH, 已加密)<br/>radioBearerConfig + masterCellGroup<br/>+ securityConfig(含新 NCC)
        UE->>gNB: 10a. RRCResumeComplete (DCCH)<br/>可携带 ULInformationTransfer(NAS)
        gNB->>AMF: 11a. PATH SWITCH REQUEST (NGAP/XnAP)
        AMF->>gNB: 12a. PATH SWITCH REQUEST ACKNOWLEDGE
        Note over UE: 进入 RRC_CONNECTED, 业务恢复
    else 认证失败 / 上下文失效
        gNB->>UE: 8b. RRCSetup (回退为全新建立)
        Note over UE: 或 RRCResumeReject -> RRC_IDLE
    end

步骤解析

步骤 1-2：UE 仍需先做随机接入（4 步 RACH 的 Msg1/Msg2，或 2 步 RA 的 MsgA/MsgB）。注意 INACTIVE 态 UE 没有专用 RACH 资源（除非配置了 CG-SDT），所以走公共 PRACH。

步骤 3：RRCResumeRequest 经 CCCH 发送。这是整个流程的"敲门砖"，CCCH 上没有安全保护，所以全部信任押在 resumeMAC-I 这 16 bit 上。

步骤 4-6：跨站恢复的关键。新 gNB 本地查不到 UE 上下文，于是依据 I-RNTI 中的 gNB ID 字段，通过 Xn 接口向 anchor gNB 发起 RETRIEVE UE CONTEXT REQUEST（TS 38.423）。anchor gNB 校验请求合法性后，在 RETRIEVE UE CONTEXT RESPONSE 中返回完整的 AS 上下文，包括挂起时的 kgNB、NCC、所有 RB 配置、PDU 会话关联信息等。这是 RAN 侧的上下文迁移，全程不惊动核心网，这是 INACTIVE 态高效的核心来源。

步骤 7：serving gNB 用获取到的密钥材料重算 MAC-I 并校验。这一步是安全关，决定了后续走成功路径还是回退路径。

步骤 8a-9a：校验通过后，gNB 执行密钥派生。根据 TS 33.501 Section 6.9，恢复时的密钥更新分两种：若 UE 仍在同一小区（或同 kgNB 派生链），执行 horizontal key derivation（kgNB → 新 kgNB，NCC 不变）；若跨 gNB，则执行 vertical key derivation（用 NH 参数派生，NCC 加 1）。派生出的新密钥通过 RRCResume 中的 securityConfig 字段（含新的 NCC）下发给 UE，UE 据此同步密钥并激活 SRB1/DRB 的加密与完整性保护。RRCResume 走的是 DCCH，且此后的消息全部是安全保护的。

步骤 10a：RRCResumeComplete 确认恢复完成，UE 回到 CONNECTED。该消息可捎带 ULInformationTransfer，把 NAS 层的 Service Request 等信令透传给 AMF。

步骤 11a-12a：跨站场景下，新 gNB 通过 PATH SWITCH REQUEST 通知 AMF 切换 N3 隧道下行终点，AMF 确认后下行用户面锚定到新 gNB，同时原 anchor gNB 释放上下文。

六、三种结局：成功、回退建立、拒绝

恢复流程并非只有"成功"一条路，网络会根据上下文有效性、负载、安全校验结果动态决策：

flowchart TD
    M["收到 RRCResumeRequest"] --> N{本地有<br/>UE 上下文?}
    N -->|是| P[直接校验]
    N -->|否| Q[向 Anchor 取上下文<br/>XnAP Retrieve UE Context]
    Q --> R{Anchor 返回<br/>有效上下文?}
    R -->|否| S[回退路径]
    P --> T{resumeMAC-I<br/>校验通过?}
    R -->|是| T
    T -->|通过| U["RRCResume<br/>成功恢复到 CONNECTED"]
    T -->|不通过| S
    S --> V{网络决定}
    V -->|可建立| W["RRCSetup<br/>走全新 RRC 建立 + NAS"]
    V -->|拒绝| X["RRCResumeReject<br/>UE 转 RRC_IDLE"]
    U --> Y((业务恢复))
    W --> Y
    X --> Z((需重新注册))

• RRCResume（成功）：复用上下文，时延最低。
• RRCSetup（回退建立）：网络认为上下文不可信或失效（例如挂起时间过久、anchor 上下文已因超时被清除），于是不返回 RRCResume 而返回 RRCSetup，把这次请求"降级"为一次全新的 RRC 连接建立，后续走完整 NAS 流程。UE 收到后需丢弃本地挂起上下文。
• RRCResumeReject（拒绝）：网络显式拒绝，携带 waitTime。UE 进入 RRC_IDLE，需要重新注册。常见于接入禁止（UAC bar）或安全策略不允许恢复的场景。

七、密钥层级与恢复时的派生

flowchart TD
    K["KAMF (核心网主密钥)"] --> L["kgNB<br/>(gNB 密钥)"]
    L --> M["Horizontal: kgNB = KDF(kgNB, PCI/ARFCN)<br/>NCC 不变"]
    L --> N["Vertical: kgNB = KDF(NH, PCI/ARFCN)<br/>NCC+1, NH 更新"]
    M --> O["KRRCenc / KRRCint / KUPenc"]
    N --> O
    O --> P["SRB/DRB 加密与完整性保护"]
    Note["挂起时保存 kgNB + NCC + NH"]:::note
    classDef note fill:#e8f5e9,stroke:#388e3c;

恢复时究竟用 horizontal 还是 vertical，取决于 UE 恢复时所在的小区是否与挂起时属于同一 kgNB 派生域。网络在 RRCResume 的 securityConfig 中通过 nextHopChainingCount 字段告诉 UE 用哪个 NCC，UE 据此判断并派生。如果 NCC 与本地存储的一致，说明是 horizontal（仅用目标小区 PCI/频点重新派生 kgNB）；如果不一致，则需要先做一次 NH 推进（vertical）。这一机制保证了前向安全——即使旧的 kgNB 泄露，垂直派生后的密钥也无法回推。

八、抓包识别：如何在 wireshark 里认出这条流程

实操中（结合 TShark/pcap 分析经验），识别一次 RRC Resume 流程的关键特征：

1. 看 SRB 与逻辑信道：第一条上行消息出现在 UL-CCCH（SRB0），消息名是 RRCResumeRequest（而非 RRCSetupRequest）。在 wireshark 的 MAC/RLC 层展开，逻辑信道 ID 指向 CCCH。
2. 看消息内容：RRCResumeRequest 中能解出 resumeIdentity（40 bit I-RNTI）、resumeCause、resumeMAC-I（16 bit）。如果看到这三个字段而不是 ue-Identity（S-TMSI/random），就确认是恢复流程。
3. 看后续消息：下一条 DCCH 消息若是 RRCResume（含 radioBearerConfig 全量重配 + securityConfig + masterCellGroup），即成功；若是 RRCSetup 则是回退建立；若是 RRCResumeReject 则被拒。
4. Xn 接口：跨站恢复时，在 XnAP 过滤器下能看到 RETRIEVE UE CONTEXT REQUEST/RESPONSE 这一对消息，RESPONSE 中携带 UE Context、PDU Session Resource 等信息——这是判断"是否跨站恢复"的硬证据。
5. NGAP：成功恢复后会有 PATH SWITCH REQUEST（Xn 站间）或 INITIAL CONTEXT SETUP（若是 RRC Setup 回退，则走 NGAP 全套）。

九、常见故障点与排错

一个高频故障是"假恢复成功"：resumeMAC-I 校验通过、RRCResumeComplete 也发了，但因为 anchor gNB 上 PDU 会话资源已经过期或与 AMF 状态不一致，导致上下行数据面其实没有真正打通。此时表现是信令面恢复正常（ping 通控制面），但应用层数据卡顿，需要触发一次额外的 Service Request 或路径更新才能恢复。排错时必须把 RRC、NGAP、用户面三段分开看。

十一、与相邻机制对比

常见问题

Q1：RRCResumeRequest 走 CCCH 且没有加密，攻击者伪造 I-RNTI 不就能冒充 UE 吗？ A：不能。攻击者即使知道 I-RNTI，也无法伪造正确的 resumeMAC-I，因为该令牌基于挂起时才有的 KRRCint 密钥计算，且只取 16 bit 但仍要求与网络侧重算结果一致。没有密钥就无法生成匹配的认证码。

Q2：恢复时的密钥到底是 horizontal 还是 vertical，UE 怎么知道用哪种？ A：UE 比较网络在 RRCResume 的 securityConfig 中下发的 nextHopChainingCount 与本地存储值：若一致则 horizontal 派生（仅用目标小区 PCI/频点重算 kgNB）；若不一致则先推进 NH 再 vertical 派生。NCC 是这套同步机制的信令锚点。

Q3：anchor gNB 上 UE 上下文能保留多久？过期了怎么办？ A：由 gNB 的 inactive timer / RNA 周期等参数决定，通常几分钟到几十分钟。一旦上下文被清除，UE 发起恢复时 anchor 在 RETRIEVE UE CONTEXT RESPONSE 中无法返回有效上下文，serving gNB 就回退发送 RRCSetup，UE 走全新建立流程，原先的挂起上下文作废。

Q4：RRC_INACTIVE 与 NAS CM-CONNECTED 是什么关系？恢复时需要重新发 Registration 吗？ A：INACTIVE 态下 UE 与 AMF 的 N2 连接依然存在（UE 对核心网仍是 CM-CONNECTED），只是空口挂起。所以正常恢复不需要重新 Registration，往往只需在 RRCResumeComplete 里捎带一个 NAS Service Request 即可恢复用户面。只有回退到 RRC Setup 或被 Reject 时，才可能触发完整 NAS 流程。

Q5：R17 的 SDT 和 RRC Resume 是替代关系吗？ A：不是替代而是互补。SDT 适用于"数据量很小、不值得为它转 CONNECTED"的场景（如心跳），直接在 INACTIVE 态通过 CG-SDT 或 RA-SDT 传完即止，连状态都不切换；一旦数据量超过门限或网络判断需要，仍会触发完整的 RRC Resume 转入 CONNECTED。两者复用同一套挂起上下文和 resumeMAC-I 认证。

参考来源

1. 3GPP TS 38.331 V18.6.0 — NR RRC Protocol Specification — Section 5.3.13 RRC connection resume, Section 5.3.1.4 Security handling, Section 6.2.2 UL-CCCH messages
2. 3GPP TS 33.501 — Security architecture for the 5G System — Section 6.9 Key derivation, horizontal/vertical key chain
3. ShareTechnote — 5G/NR RRC INACTIVE — INACTIVE 状态机、挂起/恢复流程实例与抓包序列
4. 3GLTEInfo — 5G RRC Resume Procedure Call Flow — 恢复流程分阶段拆解、消息字段与故障路径
5. NR Explained — 38.331 RRC 消息浏览 — resumeMAC-I 定义：MAC-I 的 16 个最低有效位

本文由「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 等场景全覆盖。