5G第三态：终端的浅睡眠术——RRC_INACTIVE原理解析

一、从一个让人头疼的矛盾说起

做无线网络优化或终端开发的同学，几乎都被一个"左右为难"的问题折磨过：终端在没数据收发的时候，到底该保持连接还是断开连接？

让我们先用一个生活类比。想象你打电话叫了外卖：

• 保持通话（一直占线）：外卖小哥随时能联系到你，但你这条电话线被一直占着，电话费哗哗地流，而且别人也打不进来。
• 直接挂断：你的电话线彻底空闲了，电话费省到极致。但下次外卖小哥要找你，得重新拨号、重新接通，一来一回几十秒过去了，披萨都凉了。

这就是 4G LTE 时代终端面临的窘境——它只有两个"档位"：

• RRC_CONNECTED（连接态）：一直占着基站的资源，UE（终端）和核心网之间随时可以收发数据，延迟最低，但最费电、最占资源。
• RRC_IDLE（空闲态）：彻底释放掉所有连接，省电到了极致，但代价是要通信时必须从头走一遍"开机入网"流程——随机接入、RRC 建立、鉴权、安全激活、PDU 会话建立……一长串信令，费时又费力。

问题来了：很多业务（智能水表、心率手环、即时通讯的心跳包）发送的都是间歇性的小数据包——每分钟甚至每小时才传一次。如果让它们一直待在连接态，手机/物联网终端的电池撑不过一天；如果让它们待在空闲态，每次发包都要重跑一遍完整入网流程，不仅终端费电，基站的信令负担也会被这些"频繁小数据"拖垮。

4G 的解法是 DRX（不连续接收）——在连接态里让终端"打瞌睡"。但 5G 的设计者提出了一个更激进、也更优雅的方案：在"彻底清醒"和"彻底睡死"之间，再插一个中间档——RRC_INACTIVE（去激活态），也就是本文的主角。

二、三种状态，一张图看懂

5G NR 的 RRC 状态机第一次拥有了三个状态。下面这张状态图概括了它们之间的转换关系：

stateDiagram-v2
    [*] --> RRC_IDLE: 开机/注册
    RRC_IDLE --> RRC_CONNECTED: RRC建立（完整流程）
    RRC_CONNECTED --> RRC_IDLE: RRC释放（彻底断开）
    RRC_CONNECTED --> RRC_INACTIVE: RRC释放+SuspendConfig（挂起）
    RRC_INACTIVE --> RRC_CONNECTED: RRC恢复（快速续接）
    RRC_INACTIVE --> RRC_IDLE: 超时/移动出RNA/失败回退
    RRC_CONNECTED --> RRC_CONNECTED: 切换（Xn/N2）

关键就一句话：从连接态进入 INACTIVE 时，连接不是被"拆除"，而是被"挂起（Suspend）"——就像你把一个正在运行的程序最小化到后台，而不是彻底关闭它。所有的"现场"（RRC 上下文、安全上下文、无线承载配置）都被原封不动地保留下来。

为了让三种状态的差异一目了然，请看下表：

这张表里藏着 INACTIVE 的全部精髓，特别是两个细节：

1. 核心网视角下，终端还在"连接态"——N2 信令连接、N3 用户面隧道都没断，AMF（核心网接入管理功能）压根不知道 UE 已经去睡觉了。只有空口这一段被"剪断"了。
2. 寻呼责任下放给了 RAN——网络找这个 UE 时，不再麻烦核心网按整个跟踪区列表去寻呼，而是由 gNB 在一个更小的"RNA（RAN 通知区）"范围内局部寻呼。

三、为什么这样设计：核心动机拆解

理解一个技术，最好的方式是问"它解决了谁的什么痛点"。INACTIVE 状态同时讨好三方：

1. 终端的电池：省电

INACTIVE 态下，UE 不需要持续保持上行同步（不再一直维护定时提前量 TA），可以像空闲态一样进入较长的 DRX 睡眠周期，只在寻呼时机（PO）醒来瞄一眼。

2. 空口信令：减负

最关键的省信令发生在恢复（Resume）那一刻。从空闲态建连，要重跑这一长串：

随机接入(RACH) → RRCSetupRequest → RRCSetup →
鉴权(SMC) → SecurityModeCommand → 安全激活 →
PDU会话建立 → 用户面隧道打通

而从 INACTIVE 恢复，鉴权和安全模式流程可以被跳过或大幅简化——因为安全上下文还"热乎着"地保留在两端。一次 Resume 几条信令就能把"现场"重新接上。

3. 核心网信令：减负

这是常被忽视却影响巨大的一点。从空闲态重新建连，AMF/SMF 要重新参与鉴权、重建 PDU 会话、重建 N3 隧道，整个核心网被惊动。而 INACTIVE 态下这些都不变，核心网几乎零感知。在百亿级物联网终端的场景下，这等于给核心网"减寿"了好几个数量级的信令风暴压力。

设计哲学小结：INACTIVE 把"连接的维护成本"和"连接的存在"解耦了——连接在逻辑上还在（核心网不操心），但在物理空口上被暂时挂起（省电省空口信令）。这是一次漂亮的"状态分层"。

四、挂起与恢复：信令时序图详解

下面这张时序图是本文的灵魂，请重点看。它完整描绘了"挂起→恢复"的全过程：

sequenceDiagram
    participant UE as 终端UE
    participant gNB as 基站gNB
    participant AMF as 核心网AMF

    Note over UE,AMF: 阶段一：数据收发完毕，决定挂起
    UE->>gNB: （处于RRC_CONNECTED）
    gNB->>gNB: 检测到不活动计时器超时/数据结束
    gNB->>AMF: UE Context Suspend (N2消息)
    Note right of gNB: 核心网挂起UE上下文<br/>(N1/N2/N3信令连接保留)
    gNB->>UE: RRCRelease + suspendConfig
    Note left of UE: UE保存AS上下文<br/>获得I-RNTI与RNA配置<br/>进入RRC_INACTIVE

    Note over UE,AMF: 期间：UE在RNA内小范围移动，<br/>周期性醒来执行RNA Update

    Note over UE,AMF: 阶段二：有新数据，决定恢复
    UE->>UE: 上行数据到达/收到RAN Paging
    UE->>gNB: 随机接入(用I-RNTI)
    UE->>gNB: RRCResumeRequest (含I-RNTI, resumeMAC-I)
    Note right of gNB: gNB校验resumeMAC-I<br/>确认UE合法且上下文匹配

    alt 目标gNB就是原gNB（或可取回上下文）
        gNB->>gNB: 本地/通过Xn取回挂起的上下文
        gNB->>UE: RRCResume (含重配置)
        Note left of UE: 重激活安全上下文<br/>恢复无线承载<br/>回到RRC_CONNECTED
    else 取回失败（移动远了/上下文丢失）
        gNB->>UE: RRCRelease / RRCSetup / RRCReject
        Note left of UE: 回退到RRC_IDLE<br/>走完整建立流程
    end

    gNB->>AMF: （如跨gNB）UE Context Resume / 路径切换
    Note over UE,AMF: 用户面与信令面完全恢复，开始传数据

这里有几个工程上极其重要的细节，值得逐条拆解：

细节1：I-RNTI——INACTIVE态的"身份证" 进入 INACTIVE 态时，gNB 通过 RRCRelease 消息给 UE 分配一个 I-RNTI（Inactive-RNTI）。这是 INACTIVE 态终端的唯一标识，作用类似于连接态的 C-RNTI。它由两部分组成：一部分标识哪个 gNB 持有这个 UE 的挂起上下文（ng-eNB/gNB ID），另一部分标识该 gNB 内的具体 UE。这个拆分设计非常关键——当 UE 移动到新小区要恢复时，新 gNB 能从 I-RNTI 里"反查"出"这个 UE 的上下文存在哪个老 gNB 那儿"，然后通过 Xn 接口去把它取回来。

细节2：resumeMAC-I——防伪造的"暗号" 恢复请求里 UE 必须携带一个 resumeMAC-I（基于保存的安全上下文和 shortMAC-I 计算）。gNB 拿到后用它来验证两件事：①这个 UE 是合法的（不是冒充的）；②这个 UE 持有的上下文和 gNB 保存的还匹配（没过期、没错乱）。这相当于一次"轻量级鉴权"——因为完整鉴权已被省掉，必须用这个校验来堵住安全漏洞。

细节3：恢复失败的优雅回退 时序图里那个 alt 分支不是摆设。如果新 gNB 跑去原 gNB 取上下文失败了（比如移动太远、原 gNB 已经把上下文删了、或者 RNA Update 计时器逻辑出问题），网络不会让 UE 卡死，而是让它回退到 RRC_IDLE，走一次完整的建立流程。这叫"优雅降级"，保证了极端情况下系统仍可用。

五、RNA：让 UE 在"小窝"里自由活动

上文反复出现的 RNA（RAN-based Notification Area，基于无线接入网的通知区） 是 INACTIVE 态的另一个核心概念，必须单独讲清楚。

还记得空闲态里，网络怎么找 UE 吗？核心网按 UE 注册的跟踪区列表（TA List）去寻呼，范围可能很大。而 INACTIVE 态下，UE 的"活动范围"被缩小为一个或多个小区组成的 RNA。只要 UE 在 RNA 内移动，完全不需要通知网络——这叫"RNA 内移动性，无需信令"。

只有当 UE 走出了 RNA，或者周期性 RNA Update 计时器到了，UE 才需要主动发起一次 RNA Update：

flowchart TD
    A[UE处于RRC_INACTIVE] --> B{是否离开RNA<br/>或周期计时器超时?}
    B -- 否 --> C[静默,无需任何信令<br/>RNA内自由移动]
    B -- 是 --> D[发起RNA Update<br/>携带I-RNTI]
    D --> E{当前gNB能否<br/>取回UE上下文?}
    E -- 是 --> F[更新RNA分配<br/>重新挂起,发新suspendConfig]
    E -- 否 --> G[进入RRC_IDLE<br/>等待重新注册]
    C --> B
    F --> A

这个机制的本质，是把"位置更新的成本"控制在一个非常小的粒度：

• 空闲态：跟踪区级别的移动性（TAI/TAC），更新要走核心网。
• INACTIVE 态：RNA 级别的移动性，更新只在 RAN 内部（gNB 之间）完成，核心网全程不知情。

这就让 INACTIVE 态非常适合"小范围、低频次"的终端——比如一个固定在某小区工作的传感器，它压根不会出 RNA，几乎永远不需要做位置更新，电池和网络信令双赢。

六、上下文"搬家"：suspendConfig 里的关键参数

挂起时下发的 suspendConfig 是整个机制的配置核心。下表整理了工程师调试时最常打交道的几个关键参数：

理解这套参数后，工程师在做终端功耗优化或网络覆盖规划时，就有了明确的调节旋钮。一个经典权衡公式可以表达这种设计本质——总的信令开销可以近似看成：

$$ \text{总信令开销} \approx \underbrace{N_{\text{resume}} \cdot C_{\text{resume}}}{\text{恢复次数} \times \text{单次恢复代价}} + \underbrace{N $$}} \cdot C_{\text{RNAU}}}_{\text{位置更新次数} \times \text{单次代价}

INACTIVE 态的设计，让 $C_{\text{resume}}$ 远小于从空闲态建立的代价 $C_{\text{setup}}$，同时通过 RNA 把 $N_{\text{RNAU}}$ 控制在低位。这就是它在数学上"省"的根源。

七、4G vs 5G：移动性管理的代际进化

把视野拉高，INACTIVE 是 5G 移动性管理理念进化的一个缩影。下表对比了两个时代的设计哲学：

可以看出，4G 是"状态与连接强绑定"的二元思维，5G 则走向了"状态分层、按需挂起"的弹性思维。这种思维在后续版本中进一步演化为 SDT（Small Data Transmission，小数据传输）——在 INACTIVE 态下，UE 甚至不用走完整 Resume，直接用预配置的资源（CG-DTA 或 RACH 的 MSG3）就能把一个小包发出去，把"省信令"做到了极致。

八、工程师实战：调试陷阱与排查清单

光懂原理不够，下面是 1-3 年工程师在现网调试 INACTIVE 相关问题时最常踩的坑：

陷阱1：把 INACTIVE 当成 IDLE 抓包 很多新手看终端不传数据了，就以为它进了空闲态。其实它很可能在 INACTIVE——核心网还是 CONNECTED。排查时一定要同时看空口信令（RRCRelease 是否带 suspendConfig）和核心网状态（N2 连接是否还在），别只盯一面。

陷阱2：频繁 Resume 失败回退 IDLE 如果抓包发现 UE 反复"Resume→失败→回IDLE→重新注册"，多半是 I-RNTI 反查失败：UE 移动到了一个和原 gNB 没有 Xn 连接、或原 gNB 已删上下文的地方。排查方向：检查 Xn 接口拓扑、检查 t380/上下文保留时长配置是否过短。

陷阱3：寻呼收不到 INACTIVE 态的 UE 由 RAN 寻呼（gNB 发，用 I-RNTI），而空闲态是 CN 寻呼（AMF 发，用 5G-S-TMSI）。如果终端配置的 RNA 不对、或 UE 实际驻留的小区不在 RNA 内，就会发生"RAN 寻呼发出去 UE 收不到"。排查要核对 UE 的驻留小区与 RNA 配置是否一致。

陷阱4：功耗优化过度 为了省电把 ran-PagingCycle 设得极大，结果业务实时性塌方——寻呼延迟从几十毫秒涨到几秒。物联网可以激进省电，但语音/即时消息类业务，INACTIVE 的省电参数要保守。

一句话排查口诀：先判状态（INACTIVE 还是 IDLE？看核心网连接），再查标识（I-RNTI 能否反查？看 Xn 拓扑），后对范围（UE 驻留小区在不在 RNA/寻呼区里？）。

九、常见问题

Q1：RRC_INACTIVE 和 DRX 有什么区别？不都是省电吗？ A：DRX 是"连接态内的打瞌睡"——UE 仍是 RRC_CONNECTED，空口资源还占着，只是周期性睡觉。INACTIVE 是"连接被挂起的深睡"——空口彻底断开、不占专用资源，省电更彻底，但恢复需要走 Resume。两者层次不同：DRX 是连接态子状态级省电，INACTIVE 是 RRC 状态级省电，可以叠加（INACTIVE 态的 UE 同样用 DRX 周期醒来听 RAN 寻呼）。

Q2：进入 INACTIVE 后，UE 的上下文到底存在哪里？ A：存在两端：UE 本地保存一份 AS 上下文（安全密钥、承载配置等），最后一个服务 gNB 也保存一份完整的 UE 上下文。Resume 时，如果目标 gNB 就是这个 gNB，本地直接取；否则通过 Xn 接口向原 gNB 取回。核心网侧的上下文则一直挂着没动。

Q3：如果 UE 在 INACTIVE 态直接关机了，网络会发现吗？ A：不会立刻发现。核心网一直以为 UE 还在连接态。网络是通过 UE 长时间没有 RNA Update、或 N2 上长时间无活动，才"后知后觉"地清理掉这个挂起上下文。这也是为什么 t380 等计时器和上下文保留时长要合理配置——它们就是网络"发现 UE 失联"的兜底机制。

Q4：INACTIVE 态主要给什么业务用？手机通话会用到吗？ A：最大的受益者是物联网小数据业务（智能表计、传感器、可穿戴设备的心跳包）和不频繁的移动宽带小数据。普通手机在大流量下载时长期处于 CONNECTED；但当你锁屏、微信挂着偶尔收个心跳时，手机很可能就滑入 INACTIVE，从而显著省电。是否启用 INACTIVE 由运营商策略（在 AMF 下发的 UE 配置里）决定。

Q5：为什么 4G 不搞 INACTIVE，非要等到 5G？ A：因为 4G 时代没有今天这么庞大的物联网压力，二元状态够用。而 5G 的三大场景里有 mMTC（海量机器通信），百亿级低频小数据终端若都走传统二元状态，核心网和空口的信令会被压垮。INACTIVE 是为"海量、低频、小数据"这个新需求量身定制的——技术是为需求服务的，这是理解任何通信技术演进的根本视角。

参考来源

1. 5G RRC_Inactive状态详解：帮你省电并实现毫秒级唤醒 — CSDN 博客，系统讲解 RRC Inactive 的省电机制、唤醒与移动性支持
2. 5G RRC Inactive 总结及部分 log 示例 — 知乎专栏，结合协议定义与实测 log 印证 INACTIVE 态行为
3. 5G NR 中 RRC_INACTIVE 状态下的 I-RNTI 机制深度解析 — 知乎专栏，深入解析 I-RNTI 分配、寻呼及跨 gNB 上下文取回机制
4. 5G NR RRC 协议总体介绍 — 阿里云开发者社区，讲解 RAN 寻呼与 CN 寻呼在 INACTIVE/IDLE 态下的区别
5. 5G NR 的 RRC_INACTIVE 状态：比 4G 省电的秘密武器 — CSDN 文库，从工作原理与配置角度解析挂起/恢复全流程

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