# 5G第三态：终端的浅睡眠术——RRC_INACTIVE原理解析 ## 一、从一个让人头疼的矛盾说起 做无线网络优化或终端开发的同学，几乎都被一个"左右为难"的问题折磨过：终端在没数据收发的时候，到底该保持连接还是断开连接？ 让我们先用一个生活类比。想象你打电话叫了外卖： - **保持通话（一直占线）**：外卖小哥随时能联系到你，但你这条电话线被一直占着，电话费哗哗地流，而且别人也打不进来。 - **直接挂断**：你的电话线彻底空闲了，电话费省到极致。但下次外卖小哥要找你，得重新拨号、重新接通，一来一回几十秒过去了，披萨都凉了。 这就是 4G LTE 时代终端面临的窘境——它只有两个"档位"： - **RRC_CONNECTED（连接态）**：一直占着基站的资源，UE（终端）和核心网之间随时可以收发数据，延迟最低，但最费电、最占资源。 - **RRC_IDLE（空闲态）**：彻底释放掉所有连接，省电到了极致，但代价是要通信时必须从头走一遍"开机入网"流程——随机接入、RRC 建立、鉴权、安全激活、PDU 会话建立……一长串信令，费时又费力。 问题来了：很多业务（智能水表、心率手环、即时通讯的心跳包）发送的都是**间歇性的小数据包**——每分钟甚至每小时才传一次。如果让它们一直待在连接态，手机/物联网终端的电池撑不过一天；如果让它们待在空闲态，每次发包都要重跑一遍完整入网流程，不仅终端费电，**基站的信令负担也会被这些"频繁小数据"拖垮**。 4G 的解法是 DRX（不连续接收）——在连接态里让终端"打瞌睡"。但 5G 的设计者提出了一个更激进、也更优雅的方案：**在"彻底清醒"和"彻底睡死"之间，再插一个中间档——RRC_INACTIVE（去激活态）**，也就是本文的主角。 ## 二、三种状态，一张图看懂 5G NR 的 RRC 状态机第一次拥有了三个状态。下面这张状态图概括了它们之间的转换关系： ```mermaid 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 上下文、安全上下文、无线承载配置）都被原封不动地保留下来。 为了让三种状态的差异一目了然，请看下表： | 维度 | RRC_IDLE | **RRC_INACTIVE** | RRC_CONNECTED | |------|----------|------------------|---------------| | **RRC/AS上下文** | 无 | **挂起保留（在gNB和UE两端）** | 完整激活 | | **核心网注册状态** | CM-IDLE | **CM-CONNECTED**（核心网以为还连着！） | CM-CONNECTED | | **寻呼由谁发起** | 核心网（CN Paging，基于TA） | **RAN寻呼**（基于RNA，gNB发起） + CN寻呼 | 不需寻呼 | | **恢复到可通信的时延** | 高（完整建立流程） | **低（仅Resume）** | 已就绪 | | **省电程度** | 极高（长DRX） | **高（类似空闲态DRX）** | 低 | | **N2/N3接口** | 已释放 | **保持建立**（仅空口断） | 保持建立 | | **终端标识** | 5G-S-TMSI | **I-RNTI**（新引入） | C-RNTI | 这张表里藏着 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 把"连接的维护成本"和"连接的存在"解耦了——连接在逻辑上还在（核心网不操心），但在物理空口上被暂时挂起（省电省空口信令）。这是一次漂亮的"状态分层"。 ## 四、挂起与恢复：信令时序图详解 下面这张时序图是本文的灵魂，请重点看。它完整描绘了"挂起→恢复"的全过程： ```mermaid 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上下文
(N1/N2/N3信令连接保留) gNB->>UE: RRCRelease + suspendConfig Note left of UE: UE保存AS上下文
获得I-RNTI与RNA配置
进入RRC_INACTIVE Note over UE,AMF: 期间：UE在RNA内小范围移动，
周期性醒来执行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
确认UE合法且上下文匹配 alt 目标gNB就是原gNB（或可取回上下文） gNB->>gNB: 本地/通过Xn取回挂起的上下文 gNB->>UE: RRCResume (含重配置) Note left of UE: 重激活安全上下文
恢复无线承载
回到RRC_CONNECTED else 取回失败（移动远了/上下文丢失） gNB->>UE: RRCRelease / RRCSetup / RRCReject Note left of UE: 回退到RRC_IDLE
走完整建立流程 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**： ```mermaid flowchart TD A[UE处于RRC_INACTIVE] --> B{是否离开RNA
或周期计时器超时?} B -- 否 --> C[静默,无需任何信令
RNA内自由移动] B -- 是 --> D[发起RNA Update
携带I-RNTI] D --> E{当前gNB能否
取回UE上下文?} E -- 是 --> F[更新RNA分配
重新挂起,发新suspendConfig] E -- 否 --> G[进入RRC_IDLE
等待重新注册] C --> B F --> A ``` 这个机制的本质，是把"位置更新的成本"控制在一个非常小的粒度： - **空闲态**：跟踪区级别的移动性（TAI/TAC），更新要走核心网。 - **INACTIVE 态**：RNA 级别的移动性，更新只在 RAN 内部（gNB 之间）完成，**核心网全程不知情**。 这就让 INACTIVE 态非常适合"小范围、低频次"的终端——比如一个固定在某小区工作的传感器，它压根不会出 RNA，几乎永远不需要做位置更新，电池和网络信令双赢。 ## 六、上下文"搬家"：suspendConfig 里的关键参数 挂起时下发的 `suspendConfig` 是整个机制的配置核心。下表整理了工程师调试时最常打交道的几个关键参数： | 参数 | 作用 | 调试关注点 | |------|------|-----------| | **ran-PagingCycle** | RAN 寻呼周期，决定 UE 多久醒一次 | 值越大越省电，但寻呼延迟越高；物联网可设长，实时业务别设太长 | | **ran-NotificationAreaInfo** | RNA 的范围（小区列表或RNA ID） | 决定 UE 自由活动范围；范围太小→频繁RNA Update，太大→寻呼开销大 | | **t380** | 周期性 RNA Update 计时器 | 超时必须做RNA Update；设太短增加信令，太长gNB可能因超时而删上下文 | | **I-RNTI-Value** | UE 在 INACTIVE 态的标识 | 抓包看寻呼消息时，靠它辨认是哪个 UE 被叫 | | **shortMAC-I** | 用于恢复时完整性校验的短摘要 | 校验失败必导致Resume失败回退IDLE | 理解这套参数后，工程师在做终端功耗优化或网络覆盖规划时，就有了明确的调节旋钮。一个经典权衡公式可以表达这种设计本质——**总的信令开销**可以近似看成： $$ \text{总信令开销} \approx \underbrace{N_{\text{resume}} \cdot C_{\text{resume}}}_{\text{恢复次数} \times \text{单次恢复代价}} + \underbrace{N_{\text{RNAU}} \cdot C_{\text{RNAU}}}_{\text{位置更新次数} \times \text{单次代价}} $$ INACTIVE 态的设计，让 $C_{\text{resume}}$ 远小于从空闲态建立的代价 $C_{\text{setup}}$，同时通过 RNA 把 $N_{\text{RNAU}}$ 控制在低位。这就是它在数学上"省"的根源。 ## 七、4G vs 5G：移动性管理的代际进化 把视野拉高，INACTIVE 是 5G 移动性管理理念进化的一个缩影。下表对比了两个时代的设计哲学： | 对比维度 | 4G LTE | 5G NR | |---------|--------|-------| | **RRC状态数** | 2（IDLE/CONNECTED） | 3（**新增INACTIVE**） | | **核心网连接状态** | 与RRC状态绑定 | **与RRC状态解耦**（INACTIVE时核心网仍CM-CONNECTED） | | **小数据业务适配** | 依赖DRX，仍偏费电 | **INACTIVE原生优化** | | **位置更新粒度** | 跟踪区（TA） | TA + **RNA（更细）** | | **恢复机制** | 无，必须完整重建 | **Suspend/Resume** | | **省电策略** | DRX（连接态内） | DRX + **状态级挂起** | 可以看出，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状态详解：帮你省电并实现毫秒级唤醒](https://blog.csdn.net/weixin_42528780/article/details/160542907) — CSDN 博客，系统讲解 RRC Inactive 的省电机制、唤醒与移动性支持 2. [5G RRC Inactive 总结及部分 log 示例](https://zhuanlan.zhihu.com/p/591298124) — 知乎专栏，结合协议定义与实测 log 印证 INACTIVE 态行为 3. [5G NR 中 RRC_INACTIVE 状态下的 I-RNTI 机制深度解析](https://zhuanlan.zhihu.com/p/1893327873382794428) — 知乎专栏，深入解析 I-RNTI 分配、寻呼及跨 gNB 上下文取回机制 4. [5G NR RRC 协议总体介绍](https://developer.aliyun.com/article/945101) — 阿里云开发者社区，讲解 RAN 寻呼与 CN 寻呼在 INACTIVE/IDLE 态下的区别 5. [5G NR 的 RRC_INACTIVE 状态：比 4G 省电的秘密武器](https://wenku.csdn.net/column/g4ej2gau4gw) — 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 等场景全覆盖。