5G RRC_INACTIVE 态挂起与恢复信令全链拆解

一、为什么需要 RRC_INACTIVE：一个被低估的"省电+低时延"折中态

LTE 时代只有两个 RRC 状态——RRC_IDLE 与 RRC_CONNECTED。这种二态模型的痛点很直接：业务一停，UE 落到 IDLE，核心网侧 AMF/SMF/UPF 的 UE 上下文、N2/N3 连接全部释放；下一次有业务时，必须重走一遍 完整注册→鉴权→安全激活→PDU 会话建立 的长链路，信令开销大、时延高，对海量物联网与频繁小包业务尤其致命。

3GPP 在 Rel-15（TS 38.300 / TS 38.331） 引入了第三个 RRC 状态——RRC_INACTIVE，其核心设计意图可以一句话概括：

UE 在空口挂起（RRC suspended），但在核心网侧仍是 CM-CONNECTED，所有上下文（接入层安全上下文、PDU 会话、NG/N3 连接）均被保留，只待一个 RRCResumeRequest 即可秒级恢复。

它换来三件事：① UE 用更长的 DRX 周期（ran-PagingCycle）省电；② 恢复时省掉 NAS 注册与安全流程，时延大幅下降；③ 寻呼从 CN 侧的 Tracking Area 级缩小为 RAN 侧的 RNA（RAN-based Notification Area）级，本地化、轻量化。代价是 gNB 必须长期驻留 UE 上下文（内存开销），以及一套围绕 I-RNTI / shortMAC-I / RNA / t380 的状态机与安全校验机制。本文以 TS 38.331（RRC）+ TS 38.413（NGAP）+ TS 38.423（XnAP） 为主轴，逐条信令拆解这条"挂起—驻留—恢复"全链路。

二、三态定位：CM-CONNECTED 却空口挂起的"中间态"

理解 INACTIVE 的关键，是把它放到 NAS 层 CM 状态 × RRC 层状态 的二维视角里看。

stateDiagram-v2
    [*] --> RRC_IDLE
    RRC_IDLE --> RRC_CONNECTED : RRC Setup (注册/建链)
    RRC_CONNECTED --> RRC_INACTIVE : RRCRelease + suspendConfig (挂起)
    RRC_INACTIVE --> RRC_CONNECTED : RRCResumeRequest (恢复)
    RRC_INACTIVE --> RRC_IDLE : RNA回退/超时/释放
    RRC_CONNECTED --> RRC_IDLE : UEContextRelease (去注册/异常)
    note right of RRC_INACTIVE
        CM-CONNECTED（AMF/SMF/UPF上下文保留）
        RRC suspended（空口与AS安全上下文驻留gNB/UE）
        用 I-RNTI 寻呼，用 RNA 约束移动范围
    end note

INACTIVE 的独特性在于：NAS 层看它是 CONNECTED（AMF 持有 UE 的 NGAP 关联、SMF/UPF 持有 PDU 会话），而 RRC 层看它几乎像 IDLE（UE 只守着 DRX、做小区重选）。这一"中间态"是后续所有信令设计——尤其是 RAN 寻呼、RNA Update、上下文驻留——的逻辑起点。

三、挂起信令全链：RRC_CONNECTED → RRC_INACTIVE

3.1 触发与判定

挂起通常由 gNB 发起（也可由 AMF 通过 Initial Context Setup / UE Context Modification 中的指示请求挂起）。典型触发是 数据不活动：gNB 的不活动定时器超时，或 AMF 经由 RRC Inactive Transition Report Request 等机制建议挂起。判定挂起后，gNB 与 AMF 先在 N2（NGAP）上完成上下文挂起协商，再向 UE 下发挂起指令。

3.2 NGAP 侧：UE Context Suspend 过程

挂起在 N2 接口上对应 TS 38.413 clause 8.4（UE Context Management） 中的 UE Context Suspend 过程。完整时序如下：

sequenceDiagram
    autonumber
    participant UE
    participant gNB as gNB(NG-RAN)
    participant AMF
    Note over gNB,AMF: 数据不活动，gNB 决定挂起 UE
    gNB->>AMF: UE CONTEXT SUSPEND REQUEST<br/>(AMF UE NGAP ID, RAN UE NGAP ID,<br/>PDU Session Resource List to suspend)
    Note over AMF: 挂起 N2 信令连接、N3 用户面<br/>SMF/UPF 上下文保留，PDU 会话仍存在
    AMF->>gNB: UE CONTEXT SUSPEND RESPONSE<br/>(UE Context Suspend Response,<br/>PDU Session Resource List suspended OK)
    Note over gNB: 下发 RRC 挂起指令给 UE
    gNB->>UE: RRCRelease (携带 suspendConfig)
    Note over UE: 进入 RRC_INACTIVE，<br/>驻留 inactive AS 上下文 + suspendConfig

需要特别澄清一个常见误区：挂起 ≠ 释放。Suspend 时，N2 信令连接与 N3 用户面被 suspended（暂停）而非 released（释放）——AMF、SMF、UPF 侧的 UE 上下文、PDU 会话、N3 隧道映射 全部保留。这正是恢复时能省掉 PDU 会话重建与 NAS 注册的根本原因。

3.3 RRC 侧：suspendConfig 逐 IE 拆解

gNB 通过 TS 38.331 定义的 RRCRelease 消息携带 suspendConfig，向 UE 下发进入 INACTIVE 态所需的全部参数。这是整个机制最关键的 IE 组合：

ran-NotificationAreaInfo 是 RNA 的两种粒度：网络既可以"枚举具体小区"（适合小范围、确定性区域），也可以下发"RNA 码"列表（适合大范围、按区码寻呼，类似 TA code 的 RAN 版本）。这种灵活性让运营商能在"寻呼开销"与"移动自由度"之间权衡。

四、挂起后的驻留与本地化寻呼

进入 INACTIVE 后，UE 上下文同时驻留在三处：UE 本地（inactive AS 上下文 + 安全密钥）、最后服务 gNB（NGAP/RRC/AS 上下文 + AS 安全上下文）、AMF/SMF/UPF（CM-CONNECTED 上下文）。这套驻留机制决定了两个子流程。

4.1 RAN 寻呼：用 I-RNTI 在 RNA 内本地寻呼

当有下行数据/信令要送达一个 INACTIVE UE 时，寻呼由最后服务 gNB 在 RNA 范围内发起，而不是由 AMF 走 Tracking Area 的 CN 寻呼：

sequenceDiagram
    autonumber
    participant UPF
    participant SMF
    participant AMF
    participant gNB as 最后服务gNB
    participant UE as UE(在RNA内某小区)
    UPF->>SMF: 下行数据到达(被挂起的PDU会话)
    SMF->>AMF: 通知有下行待发(UE处于CM-CONNECTED)
    AMF->>gNB: 经NGAP关联转发下行/寻呼触发
    Note over gNB: UE 当前RRC挂起→发起RAN寻呼
    gNB->>UE: Paging(寻呼标识 = I-RNTI, 范围 = RNA小区)
    Note over UE: 识别到自己的I-RNTI
    UE->>gNB: RRCResumeRequest(resumeCause=mt-Access)
    Note over gNB,UE: 后续进入恢复流程(见第五节)

这里有个关键对比点：CN 寻呼（RRC_IDLE）用 5G-S-TMSI、范围是整个 Tracking Area、由 AMF 发起；RAN 寻呼（RRC_INACTIVE）用 I-RNTI、范围是 RNA、由最后服务 gNB 发起。后者范围小、不上行到 CN、更省信令、更省时延。

为了让 AMF 掌握 UE 在 INACTIVE 态的动向，TS 38.413 还定义了 RRCInactiveTransitionReport 过程：当 AMF 设置了 RRC Inactive Transition Report Request，gNB 会在 UE 越出 RNA、发起 RNA Update、或被 RAN 寻呼等转换点主动上报 AMF，供 AMF 决定是否保留最后服务 gNB 处的上下文（或下发 UE Context Release 释放它）。

4.2 周期性 RNA Update：t380 的角色

t380 是 INACTIVE 态的"心跳"。定时器一到期，UE 必须发起一次 RNA Update（resumeCause = rna-Update），向 RAN 报"我还在"。这是 TS 38.300 / 38.304 中 RRC_INACTIVE 态 UE 行为的核心义务，直接对应下一节的恢复子流程。

五、恢复信令全链：RRC_INACTIVE → RRC_CONNECTED

恢复是整条链路最精彩也最容易出错的部分。它分"同一 gNB 恢复"与"新 gNB 恢复"两种情形，且要处理跨小区的上下文获取与安全校验。

5.1 RRCResumeRequest：最小的"我要恢复"消息

UE 在三种情况下发起恢复：① 有上行数据/信令（mo-）；② 收到 RAN 寻呼（mt-Access）；③ t380 到期（rna-Update）。无论哪种，UE 都通过 SRB0（CCCH）发送 RRCResumeRequest*。这条消息必须极其紧凑，因为它走的是容量极小的 CCCH（msg1/msg3 承载）：

resumeCause 是个枚举，决定网络如何调度与处理（TS 38.331 ResumeCause）：

5.2 shortMAC-I / resumeMAC-I：恢复时的安全校验

恢复不重跑 NAS 鉴权，那 gNB 凭什么相信发来 RRCResumeRequest 的就是真正的 UE？答案是这个 16 位令牌。其安全逻辑要点如下：

flowchart TD
    A["挂起时: gNB 基于 inactive AS 上下文<br/>(KRRCint + 完整性算法)<br/>计算 shortMAC-I(16bit)"] --> B["suspendConfig.shortMAC-I 下发 UE"]
    B --> C["UE 驻留 shortMAC-I"]
    C --> D["恢复时: RRCResumeRequest.resumeMAC-I = shortMAC-I"]
    D --> E["gNB 校验令牌<br/>只有持有正确 AS 上下文的 UE 才能算对"]
    E --> F{校验通过?}
    F -->|是| G["恢复 AS 安全上下文 + 重配 DRB"]
    F -->|否| H["拒绝/释放"]

其设计精髓在于：令牌由挂起时驻留的 RRC 完整性密钥 KRRCint 与配置的完整性算法 派生（计算输入串为 VarResumeMAC-Input / VarShortMAC-Input）。攻击者即使窃听到 I-RNTI，也无法伪造令牌，因为他没有那把挂起时的 AS 安全上下文。这正是 INACTIVE 能"免 NAS 鉴权秒恢复"却又"不丧失身份可信性"的安全底座。

5.3 情形一：在最后服务 gNB 恢复

最简单情形——UE 在保留其上下文的同一个 gNB 小区发起恢复：

sequenceDiagram
    autonumber
    participant UE
    participant gNB as 最后服务gNB(持上下文)
    participant AMF
    UE->>gNB: RRCResumeRequest(resumeIdentity, resumeMAC-I, resumeCause)
    Note over gNB: 本地校验 resumeMAC-I → 命中驻留上下文
    gNB->>AMF: UE CONTEXT RESUME REQUEST<br/>(RAN UE NGAP ID, AMF UE NGAP ID, Resume Cause)
    Note over AMF: 重激活 N2 信令连接<br/>通知 SMF/UPF 重激活 N3 用户面
    AMF->>gNB: UE CONTEXT RESUME RESPONSE<br/>(UE Context, PDU Session Resource to setup,<br/>Security Key, UE 无线能力)
    Note over gNB: 恢复 AS 安全上下文, 重配 SRB/DRB
    gNB->>UE: RRCResume(或 RRCSetup, 含重配)
    UE->>gNB: RRCResumeComplete
    Note over UE,gNB: 恢复完成, DRB 重建, 上下行恢复

注意 NGAP UE CONTEXT RESUME RESPONSE 携带了重建 PDU 会话资源所需的一切（PDU Session Resource List to setup、更新的安全密钥、UE 无线能力等），gNB 据此完成空口重配，避免再走一次完整 PDU 会话建立。

5.4 情形二：在新 gNB 恢复（RNA 内/跨小区）

UE 可能在 RNA 内移动到了另一个 gNB 的小区。此时新 gNB 手里没有该 UE 的上下文，必须跨站获取。这要靠 TS 38.423（XnAP）的 Retrieve UE Context 过程：

sequenceDiagram
    autonumber
    participant UE
    participant NewgNB as 新gNB(无上下文)
    participant OldgNB as 最后服务gNB(持上下文)
    participant AMF
    participant UPF
    UE->>NewgNB: RRCResumeRequest(resumeIdentity=I-RNTI, resumeMAC-I)
    Note over NewgNB: 无本地上下文→用I-RNTI定位最后服务gNB
    NewgNB->>OldgNB: XnAP RETRIEVE UE CONTEXT REQUEST(I-RNTI, resumeMAC-I, 完整RRCResumeRequest)
    Note over OldgNB: 校验 resumeMAC-I → 校验通过
    OldgNB->>NewgNB: RETRIE UE CONTEXT RESPONSE(UE AS上下文 + 安全上下文)
    Note over OldgNB: 释放本地驻留上下文(移交)
    NewgNB->>AMF: UE CONTEXT RESUME REQUEST(新RAN UE NGAP ID)
    Note over AMF,UPF: 重锚定N2到新gNB; SMF/UPF更新N3下行隧道TEID
    AMF->>NewgNB: UE CONTEXT RESUME RESPONSE(PDU会话资源 + 密钥)
    NewgNB->>UE: RRCResume
    UE->>NewgNB: RRCResumeComplete

这里有三个工程要点：① 新 gNB 用 I-RNTI 中的 gNB ID 部分定位最后服务 gNB；② resumeMAC-I 与完整 RRCResumeRequest 一并转发给最后服务 gNB 做校验——校验权仍在持有上下文的那一方；③ 获取成功后，上下文从旧 gNB "移交"到新 gNB，AMF/UPF 侧把 N3 下行隧道重锚定到新 gNB（一次路径更新）。若获取失败（例如最后服务 gNB 已释放上下文、Xn 不通或上下文超时），新 gNB 将回退处理（见第六节）。

六、RNA Update 子流程与回退：INACTIVE 的"续命"与"退出"

RNA Update 有两种触发：周期性（t380 到期）与越区（UE 选到的小区不在 RNA 内）。处理逻辑分叉明显：

• 在最后服务 gNB 触发：gNB 校验通过后，可以轻量重新挂起——直接回 RRCRelease + suspendConfig（刷新 t380、shortMAC-I、I-RNTI），不必把 UE 完全恢复到 CONNECTED。这是最省信令的路径。
• 在新 gNB 触发：新 gNB 经 Xn 获取上下文成功后，成为新的最后服务 gNB，给 UE 重新挂起并下发新的 RNA/I-RNTI/shortMAC-I。
• 回退（fallback）：若新 gNB 无法获取上下文（retrieve 失败），按 TS 38.331，gNB 会下发 RRCReject 或 RRCRelease，迫使 UE 回到 RRC_IDLE，由 UE 发起新的 RRC 建立与注册（CN 侧重新走一遍）。这是 INACTIVE 失效的安全网。

stateDiagram-v2
    INACTIVE : RRC_INACTIVE
    INACTIVE --> ResumeProc : t380到期 / 越出RNA / 有业务
    ResumeProc : 发起 RRCResumeRequest(rna-Update)
    ResumeProc --> RelSuspend : 持有上下文gNB→校验OK→轻量重挂起
    ResumeProc --> MigrateSuspend : 新gNB→Xn获取成功→成为新最后服务gNB→重挂起
    ResumeProc --> IDLE : 获取失败→RRCRelease/Reject→回IDLE→重新注册
    RelSuspend --> INACTIVE
    MigrateSuspend --> INACTIVE

八、横向对比：INACTIVE 与相邻方案的边界

可以看出，INACTIVE 与 SDT 共享同一套底层（I-RNTI / RNA / 挂起上下文 / shortMAC-I），SDT 只是在"不离开 INACTIVE"的前提下额外允许小数据透传；而 INACTIVE 与 IDLE 的本质区别，就是上下文驻留与否、以及寻呼/恢复链路的轻重。

九、设计哲学小结

把整条链路串起来，RRC_INACTIVE 的设计哲学非常清晰：

1. 把"连接保留"与"空口释放"解耦——CM-CONNECTED 留住核心网上下文，RRC suspend 释放空口资源，鱼与熊掌兼得。
2. 用驻留换时延——UE、gNB、核心网三方驻留上下文，恢复时省掉 NAS 注册与 PDU 会话重建，把"恢复"压缩成一次 RRC + 一次 NGAP。
3. 用 shortMAC-I 换鉴权开销——16 位令牌替代完整 NAS 鉴权，既快又安全。
4. 用 RNA + I-RNTI 换寻呼开销——本地化 RAN 寻呼替代广域 CN 寻呼。
5. 用 t380 + 回退换鲁棒性——周期性 RNA Update 维持活性，获取失败则安全回退到 IDLE/注册。

这套机制是 5G 应对海量连接、频繁小包、时延敏感业务的核心抓手之一，也是理解后续 SDT、MUSIM、节能增强等特性的基础设施。

常见问题

Q1: RRC_INACTIVE 与 RRC_IDLE 最本质的区别是什么？ A: 上下文驻留与 CM 状态。INACTIVE 态 UE 在核心网侧仍是 CM-CONNECTED，AMF/SMF/UPF 与最后服务 gNB 均保留 UE 上下文与挂起的 N2/N3 连接；恢复时复用这些上下文，免 NAS 注册与 PDU 会话重建。IDLE 态则是 CM-IDLE，所有网元上下文已释放，恢复需走完整长链路。

Q2: 恢复时既然不重新鉴权，gNB 怎么确认 UE 身份不被冒用？ A: 靠 shortMAC-I（16bit）。它由挂起时驻留的 RRC 完整性密钥 KRRCint 与完整性算法派生（输入串 VarResumeMAC-Input / VarShortMAC-Input）。攻击者即便窃听到 I-RNTI，没有 AS 安全上下文也算不出正确令牌；跨站恢复时新 gNB 会把它与完整 RRCResumeRequest 一并转发给最后服务 gNB 校验。

Q3: 同一个 gNB 恢复和在新 gNB 恢复，信令差别在哪？ A: 同一 gNB：本地命中上下文，直接走 NGAP UE CONTEXT RESUME 即可。新 gNB：需先经 XnAP Retrieve UE Context 向最后服务 gNB 取回 UE AS 上下文与安全上下文，校验 resumeMAC-I 后移交，再由 AMF/UPF 把 N3 隧道重锚定到新 gNB。获取失败则回退到 IDLE 重注册。

Q4: RAN 寻呼和 CN 寻呼有什么不同？ A: CN 寻呼（IDLE 态）由 AMF 用 5G-S-TMSI 在整个 Tracking Area 发起；RAN 寻呼（INACTIVE 态）由最后服务 gNB 用 I-RNTI 在 RNA 范围内发起。后者范围小、不上行 CN、更省信令、时延更低。

Q5: RNA Update 触发后会一定把 UE 恢复到 CONNECTED 吗？ A: 不一定。若在持有上下文的 gNB 触发，gNB 可轻量重新挂起（直接回 RRCRelease+suspendConfig 刷新 t380/I-RNTI/shortMAC-I），UE 全程不进入 CONNECTED，最省信令；只有在有真实业务或跨站迁移/回退时才真正恢复。

参考来源

1. 3GPP TS 38.331 — NR; Radio Resource Control (RRC) — suspendConfig、RRCResumeRequest/RRCResume/RRCResumeComplete、shortMAC-I/resumeMAC-I、t380、RNA 与 RRC_INACTIVE 状态机（clause 5.3 Connection control）
2. 3GPP TS 38.413 — NG-RAN; NG Application Protocol (NGAP) — UE Context Management（Initial Context Setup / UE Context Suspend / UE Context Resume / UE Context Release）、Paging、RRCInactiveTransitionReport（clause 8.4 / 8.7）
3. 3GPP TS 38.423 — NG-RAN; Xn Application Protocol (XnAP) — Retrieve UE Context 过程（跨站恢复上下文获取）
4. 3GPP TS 38.300 — NR; Overall description — RRC_INACTIVE 状态、RNA、RAN 寻呼与 RNA Update 总体描述
5. ShareTechnote — 5G/NR RRC INACTIVE 与 iTecSpec — TS 38.331 rrcresumerequest — RRC Resume 流程与 IE 图解；Amarisoft — NR Rrc Inactive — gNB/AMF 上下文驻留架构解读

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