首页 › deep-tech › RRC三态机：终端的生命周期

RRC三态机：终端的生命周期

一、从"人的一天"说起：终端为什么有三个状态

想象你的一天可以分成三种状态：深度睡眠（什么都不想，手机关机）、午间小憩（半睡半醒，随时能被叫醒干活）、全神贯注（坐在工位上随时响应）。这三种状态的能耗、响应速度、被找到的难度完全不同——你不会在深度睡眠时立刻响应同事，也不会在全神贯注时还保持着午睡的省电姿态。

移动通信里的终端（UE）同样如此。3G/4G 时代，协议只给终端定义了两个状态：空闲态（RRC_IDLE）和连接态（RRC_CONNECTED）。这两个状态就像"深度睡眠"和"全神贯注"，中间没有过渡。问题来了：现代手机上跑着微信、QQ、各种推送，业务特征是"小数据、高频次、突发"——心跳包隔几十秒来一个，每个包都只有几十字节。

如果用两态模型，终端的体验是这样的：来一个心跳包 → 从深度睡眠爬起来建立完整连接（一堆信令）→ 发完几十字节 → 释放连接回去睡觉 → 下一个心跳再来……每一次"爬起来"都要经历随机接入、RRC 连接建立、安全模式激活、承载建立，发一个几十字节的小包，光控制面信令就要烧掉好几千字节，还要消耗上百毫秒时延和可观的电量。当基站下挂着的不是一部手机，而是成千上万台物联网传感器时，这种"为发一个小包而建立的完整连接"会汇聚成灾难性的信令风暴（Signaling Storm）。

5G 的回答很简洁：在深度睡眠和全神贯注之间，加一个"午间小憩"的状态——这就是 RRC_INACTIVE（非激活态）。它让终端"挂起但就绪"，既保留了几乎全部省电特性，又能在需要时几毫秒内秒回工作状态，而不必从头走一遍建立流程。

本文我们就把这个"三态机"拆开看清楚：三个状态各自意味着什么、它们之间如何切换、信令时序长什么样，以及——为什么偏偏是三个状态，而不是两个或四个。

二、三个状态：一个终端的三种"活法"

先把三个状态的定义和关键属性摆清楚。理解 RRC 状态机，核心是抓住三个维度的变化：

UE 上下文（UE Context）存在哪里：这是最关键的一点。上下文是终端在网络的"档案"——安全密钥、无线承载配置、能力信息等。
网络在什么粒度上知道终端的位置：是小区级、还是区域级、还是完全不知道。
终端的功耗与响应时延：能不能省电、醒过来要多快。

flowchart TD
    IDLE["😴 RRC_IDLE<br/>深度睡眠<br/>• 无RRC连接<br/>• 上下文只在UE和CN<br/>• CN在TA级追踪UE<br/>• 小区重选, 最省电"]
    INACTIVE["😐 RRC_INACTIVE<br/>午间小憩<br/>• 连接挂起但保留<br/>• 上下文在UE和gNB<br/>• RAN在RNA级追踪UE<br/>• 快速恢复, 较省电"]
    CONNECTED["😎 RRC_CONNECTED<br/>全神贯注<br/>• 完整RRC连接<br/>• 上下文在gNB<br/>• 网络知UE在哪个小区<br/>• 收发数据, 最费电"]

    IDLE -->|RRCSetupRequest 建立连接| CONNECTED
    CONNECTED -->|RRCRelease+suspendConfig 挂起| INACTIVE
    INACTIVE -->|RRCResumeRequest 恢复| CONNECTED
    INACTIVE -.->|RNA超时/寻呼失败| IDLE
    CONNECTED -.->|RRCRelease 释放| IDLE

2.1 RRC_IDLE：深度睡眠

这是终端最"裸"的状态，对应刚开机完成小区搜索但还没注册，或者长期没有业务的状态。它的特征是：

没有 RRC 连接，终端想发数据必须从随机接入开始，走完整的连接建立流程。
UE 上下文只存在于 UE 本身和核心网（AMF/UDM），基站里没有任何关于这个终端的 AS（接入层）上下文。这是和 INACTIVE 最本质的区别。
网络只在跟踪区（TA）级别知道终端大概在哪。所以寻呼要覆盖整个 TA，范围大、广播开销高。
终端自己做小区选择/重选（详见之前讲过的 S 准则与 R 准则），不经过网络控制。
功耗最低——DRX 周期可以拉到很长（几个甚至几十个秒级），绝大部分时间在睡。

一句话：IDLE 是"我睡了，你要找我得在大区范围广播，而且找到了我还得重新办入职"。

2.2 RRC_CONNECTED：全神贯注

终端正在收发数据时的状态：

完整的 RRC 连接，SRB1/SRB2 和数据无线承载（DRB）都建好了，安全上下文激活。
UE 上下文完整保存在服务 gNB 里（还有一份在 AMF）。
网络精确知道终端在哪个小区，因为信令走的是专用的 RRC 连接，不用广播找。
移动性由网络控制的切换（Handover）来管——终端测量邻区、上报，网络决定切到哪、何时切（切换流程、Xn/N2 切换我们在前两轮讲过）。
功耗最高——终端要持续监听 PDCCH 控制信道（用 DRX 缩短监听时间，但周期短、唤醒频繁）。

一句话：CONNECTED 是"我坐在工位上，随时响应，但很费电"。

2.3 RRC_INACTIVE：午间小憩（5G 的关键创新）

这是 5G NR 新增的状态，介于两者之间，设计目标就是"省电如 IDLE，响应如 CONNECTED"：

RRC 连接被"挂起"（suspend）而非彻底释放——关键的是，UE 的 AS 上下文被同时保留在 UE 和"最后服务的 gNB"里。这就像你午睡时工牌还挂在工位、电脑没关、文档都开着，随时能接着干。
网络在 RAN 通知区（RNA，RAN-based Notification Area）级别追踪终端。RNA 通常比 TA 小，是一个 gNB 服务的若干小区集合。
终端像 IDLE 一样做小区重选、用长周期 DRX 省电，但在 RNA 范围内移动时不需要通知网络（IDLE 态跨 TA 要做位置更新）。
恢复时只要一条 RRCResumeRequest，几毫秒内回到 CONNECTED，不必重做安全激活和承载建立。

一句话：INACTIVE 是"我趴在桌上小憩，工牌还挂着，被叫一声立刻能干活"。

三、为什么是三个状态：信令开销的数学账

为了理解 5G 为什么非要加这个中间态，我们用最朴素的算式算一笔"信令账"。设：

$N$：单位时间内终端发起数据传输的次数（业务突发频率）
$C_{\text{setup}}$：从 IDLE 完整建立连接到能发数据的信令开销（条数/字节数）
$C_{\text{resume}}$：从 INACTIVE 恢复连接的信令开销
$C_{\text{suspend}}$：挂起/释放一次连接的开销（远小于建立）

在 LTE 的两态模型下，每次突发都要走完整建立，单位时间信令开销近似为：

$$ S_{\text{LTE}} \approx N \cdot C_{\text{setup}} $$

而 5G 三态模型下，终端大部分时间停在 INACTIVE，恢复开销为：

$$ S_{\text{5G}} \approx N \cdot C_{\text{resume}} + C_{\text{suspend}} $$

两者的比值（信令节省倍数）：

$$ \eta = \frac{S_{\text{LTE}}}{S_{\text{5G}}} \approx \frac{N \cdot C_{\text{setup}}}{N \cdot C_{\text{resume}}} = \frac{C_{\text{setup}}}{C_{\text{resume}}} $$

由于 $C_{\text{resume}} \ll C_{\text{setup}}$（恢复流程省掉了安全激活、承载重配、大部分 NAS 交互，信令条数大约只有完整建立的 1/5 到 1/3），$\eta$ 可以达到 3~5 倍。当 $N$ 很大（高频小包业务）时，这笔账非常可观。这正是 INACTIVE 态存在的根本理由——它不是为了让终端"多一个状态玩"，而是为了在小数据高频场景下，把控制面信令压下来一个数量级。

三态核心属性对比表

维度	RRC_IDLE	RRC_INACTIVE	RRC_CONNECTED
RRC 连接	无	挂起（suspend）	完整激活
UE AS 上下文位置	仅 UE + 核心网	UE + 服务 gNB 双存	服务 gNB
网络追踪粒度	TA（跟踪区）	RNA（RAN 通知区，通常更小）	小区级
移动性管理方式	小区重选（UE 自主）	小区重选（RNA 内不通知网络）	网络控制切换
寻呼来源	核心网（CN paging，跨 TA）	RAN 寻呼（RNA 内）/ 核心网寻呼	不需要（专用连接）
DRX 周期	长（最省电）	长（较省电）	短（频繁唤醒）
恢复到发数据的时延	高（完整建立，几十~上百 ms）	低（几~十几 ms）	0（已在态）
对应 NAS CM 状态	CM-IDLE	CM-CONNECTED	CM-CONNECTED

这张表里最容易被忽略、也最容易考倒人的两行：① INACTIVE 态下 AS 上下文双存于 UE 和 gNB；② INACTIVE 态在 NAS 层对应的是 CM-CONNECTED，不是 CM-IDLE。记住这两点，后面所有机制都能串起来。

四、状态转换的信令时序图

状态机不画时序图等于没讲。我们逐条看四个方向的转换。

4.1 IDLE → CONNECTED：完整建立（最"重"的一条路）

这是终端开机注册、或从 IDLE 醒来发数据走的路。前两轮我们讲过随机接入，这里接着随机接入之后看 RRC 层。

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    Note over UE,gNB: 前置：随机接入(msg1~msg2)已完成
    UE->>gNB: RRCSetupRequest (含UE标识, 建立原因)
    Note right of gNB: gNB此时还没有UE上下文
    gNB->>UE: RRCSetup (配置SRB1)
    UE->>gNB: RRCSetupComplete (捎带NAS注册请求)
    gNB->>AMF: Initial UE Message (转发NAS)
    AMF-->>gNB: 鉴权/安全流程 (多条NAS交互)
    gNB-->>UE: SecurityModeCommand
    UE->>gNB: SecurityModeComplete
    gNB->>UE: RRCReconfiguration (建立DRB)
    UE->>gNB: RRCReconfigurationComplete
    Note over UE,gNB: 至此才能收发用户面数据

可以看到，从 IDLE 爬起来要经历：随机接入 → RRC 三步建立 → 核心网鉴权安全 → 承载重配，全程十几条信令、跨 Uu 和 N2 两个接口、还要等核心网往返。一个微信心跳包如果每次都走这条路，体验和功耗都不可接受。

4.2 CONNECTED → INACTIVE：挂起（suspendConfig 是钥匙）

终端一段时间没数据，gNB 的不活动定时器（inactivity timer）超时，决定不直接释放到 IDLE，而是挂起到 INACTIVE。关键在于 RRCRelease 消息里带了一个 suspendConfig（挂起配置）。

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    Note over UE,gNB: gNB inactivity timer超时, 决定挂起
    gNB->>UE: RRCRelease (含 suspendConfig)
    Note right of gNB: suspendConfig 含: I-RNTI, RNA, 周期RNA定时器, DRX周期等
    gNB->>AMF: UE Context Suspend (N2 UE CONTEXT SUSPEND)
    Note over UE,gNB: ① gNB 保留 UE AS 上下文<br/>② UE 存储 inactive AS 上下文<br/>③ NAS层仍是 CM-CONNECTED
    UE->>UE: 进入 RRC_INACTIVE

这里有几个要点：

上下文不删，只是挂起。gNB 把 UE 的 AS 上下文（含安全密钥、DRB 配置）原样留在内存里，UE 侧也存一份"非激活 AS 上下文"。
suspendConfig 里下发了恢复所需的全部参数，最核心的是：
I-RNTI（Inactive-RNTI）：一个 40bit 的标识，相当于给挂起的终端发了一张"暂存号牌"，gNB 靠它找回上下文。
RNA（RAN 通知区）：告诉终端"你在这个范围内乱跑不用通知我"。
周期性 RNA 更新定时器：定期让终端报到一次，确认还活着。
核心网侧：gNB 通过 UE Context Suspend 通知 AMF"我把这个 UE 挂起了"，但AMF 认为 UE 仍然处于 CM-CONNECTED——这就是为什么表里 INACTIVE 对应 CM-CONNECTED。核心网根本不知道发生了挂起这一层的细节，对它来说连接还在，只是暂时没数据。

4.3 INACTIVE → CONNECTED：恢复（最"轻"的一条路，秒回工作位）

当挂起的终端要发上行数据，或收到 RAN 寻呼，就走恢复流程。这是 INACTIVE 态的全部价值所在。

sequenceDiagram
    participant UE
    participant LastgNB as 最后服务gNB
    participant NewgNB as 当前gNB(可选)
    participant AMF
    Note over UE: 上行数据到达/收到RAN寻呼
    UE->>LastgNB: RRCResumeRequest (含 I-RNTI, 复用MSG3)
    Note right of LastgNB: 用 I-RNTI 找回挂起的UE上下文
    alt UE还在原gNB覆盖下
        LastgNB->>UE: RRCResume (仅发增量配置 delta)
    else UE已移动到新gNB
        NewgNB->>LastgNB: 取回上下文(retrieve)
        LastgNB-->>NewgNB: 上下文转发
        NewgNB->>UE: RRCResume
    end
    UE->>gNB: RRCResumeComplete
    Note over UE,gNB: 安全密钥由挂起密钥派生, 无需重新鉴权<br/>DRB沿用挂起前的配置<br/>不触发NAS信令
    Note over UE,gNB: 全程仅2~3条RRC信令, 无N2鉴权往返

恢复流程的精妙之处：

靠 I-RNTI 找回上下文：UE 把 RRCResumeRequest（复用随机接入的 MSG3 发送，含 40bit I-RNTI）发给"最后服务的 gNB"。如果终端没换小区，那个 gNB 一查就找到上下文。
带移动性的恢复：如果终端在 INACTIVE 态重选到了新小区，RRCResumeRequest 会发到新 gNB，新 gNB 用 I-RNTI 向最后服务 gNB 发起"取回上下文"请求（走 Xn 接口），把上下文搬过来再恢复。这就是 INACTIVE 态如何在 RNA 范围内实现"无网络感知移动"的——终端不用做任何位置更新信令，只在真正要发数据时才一次性把上下文搬过去。
三种可能的回应：网络可能回 RRCResume（成功，给增量配置）、RRCSetup（上下文丢了，回退到完整建立）、或 RRCReject（拒绝，等一会儿再试）。
密钥派生而非重鉴权：恢复时安全密钥是从挂起时保存的根密钥派生出来的（kgNB 衍生），完全跳过鉴权和安全模式激活，这是省时延和信令的大头。

4.4 INACTIVE → IDLE：回不去的退路

INACTIVE 不是永久的。当出现以下情况，终端会退回彻底的 IDLE：

周期性 RNA 更新超时：终端该来报到却没来，gNB 认为它"失联"，删除上下文。
RAN 寻呼失败：网络在 RNA 内发 RAN 寻呼找不到终端（比如终端真关机了）。
网络策略：比如挂起的终端太多，gNB 内存压力大，主动把一部分踢到 IDLE。

一旦退回 IDLE，gNB 里的 AS 上下文被删除，再想恢复就只能走 4.1 的完整建立。所以"挂起保活"是有成本和时限的，不是无限期。

五、两个支撑机制：I-RNTI 与 RNA

把这两个机制单独拎出来，因为它们是 INACTIVE 态能运转的两根支柱。

5.1 I-RNTI：挂起终端的"暂存号牌"

普通连接态下，gNB 用 C-RNTI（16bit）在 MAC 层寻址终端。但 INACTIVE 态没有专用连接，终端和其他挂起终端混在一起靠小区重选游走。怎么找回某一个挂起终端的上下文？答案就是 I-RNTI（Inactive-RNTI）。

它是一个 40bit 的标识（比 C-RNTI 长得多），由最后服务 gNB 在挂起时分配，全局在 gNB 范围内唯一。
它结构上通常分成两部分：gNB 标识部分 + UE 标识部分。这样当一个 gNB 收到别的 gNB 转来的 I-RNTI，光看前半段就能知道"这是哪个 gNB 挂起的"，从而知道该向谁取回上下文。
挂起期间，UE 监听寻呼时也是用 I-RNTI 来判断"这个 RAN 寻呼是不是找我的"。

工程直觉：I-RNTI 越长越能保证挂起终端的唯一性，但 RRCResumeRequest 塞进随机接入 MSG3 时就越占空间。40bit 是在"唯一性足够"和"MSG3 不超长"之间权衡的结果——MSG3 大小有限制，太长会触发更大的 MSG3，反而增加开销。

5.2 RNA（RAN 通知区）：INACTIVE 态的"活动围栏"

IDLE 态网络在 TA 级别找终端，TA 通常覆盖很大（几十上百个基站）。INACTIVE 态引入了 RNA，把"找终端的范围"缩小到一个 gNB 服务的若干小区。

RNA 的构成：通常是"最后服务 gNB"及其部分邻区组成的小区集合，由 gNB 在挂起时通过 suspendConfig 下发给终端。
RNA 内自由移动：终端在 RNA 内做小区重选不需要任何信令，这是省信令的关键。
移出 RNA 才需更新：终端一旦重选到 RNA 外的小区，要发起 RNA Update（RAN 通知区更新）——本质就是一个 RRCResumeRequest（原因值是 RNA 更新），gNB 收到后把上下文搬过来、（可能）重新分配 RNA，然后又把终端挂回 INACTIVE。
周期性 RNA 更新：即使没移动，终端也要定期（由挂起时下发的定时器控制）发一次 RNA 更新，向网络报平安。网络借此知道挂起的终端还活着。

flowchart TB
    subgraph RNA["RAN 通知区 RNA (最后服务gNB + 邻区)"]
        direction LR
        C1["小区1"]
        C2["小区2"]
        C3["小区3(最后服务)"]
        C4["小区4"]
        UE(("UE<br/>RRC_INACTIVE"))
        UE -.小区重选.-> C1
        C1 -.无需信令.-> C2
        note1["RNA内移动:<br/>零信令, 自由游走"]
    end
    OUT["RNA外的基站"]
    UE -->|"移出RNA: 触发<br/>RNA Update"| OUT
    OUT -->|"上下文搬迁<br/>重配RNA"| UE
    note2["→ INACTIVE态能'隐身移动'<br/>只在必要时才与网络交互"]

特性	IDLE 态的 TA	INACTIVE 态的 RNA
范围	大（多 gNB）	小（通常单 gNB + 邻区）
跨越时是否需更新	是（TAU/注册更新，走核心网 NAS）	是，但走 RAN 内的 RNA Update，轻量
寻呼范围	整个 TA 广播	RNA 内广播（RAN 寻呼）
维护方	核心网（AMF）	接入网（gNB）
## 六、接入层与 NAS 层的状态机"双轨"

很多初学者只盯着 RRC 三态，却忽略了 NAS 层还有一套独立的状态机，两者协同才完整描述了终端的"身份"。NAS 层主要看两个状态机：

注册管理（RM）状态机：RM-DEREGISTERED（未注册）/ RM-REGISTERED（已注册）。决定终端在不在网，是否合法。
连接管理（CM）状态机：CM-IDLE（无 NAS 信令连接）/ CM-CONNECTED（有 NAS 信令连接，即 N2 连接还在）。决定终端和核心网之间有没有一条活的信令通道。

它们和 RRC 三态的对应关系是理解整个移动性管理的"罗塞塔石碑"：

flowchart LR
    subgraph NAS["NAS层 (核心网视角)"]
        RM1["RM-DEREGISTERED"]
        RM2["RM-REGISTERED"]
        CM1["CM-IDLE"]
        CM2["CM-CONNECTED"]
    end
    subgraph AS["RRC层 (接入网视角)"]
        R1["RRC_IDLE"]
        R2["RRC_INACTIVE"]
        R3["RRC_CONNECTED"]
    end
    RM1 -.未注册.-> R1
    RM2 --> CM1
    RM2 --> CM2
    CM1 ==>|"对应"| R1
    CM2 ==>|"对应"| R2
    CM2 ==>|"对应"| R3

关键对应关系：

RRC 状态	NAS CM 状态	含义
RRC_IDLE	CM-IDLE	终端既没有空口连接，也没有到 AMF 的 N2 信令连接
RRC_INACTIVE	CM-CONNECTED	空口挂起，但到 AMF 的 N2 连接仍存在（AMF 认为 UE 还连着）
RRC_CONNECTED	CM-CONNECTED	空口激活，N2 连接激活

这张表回答了一个高频面试/排障问题：INACTIVE 态时，核心网到底知不知道？答案是：知道，而且认为它还连着（CM-CONNECTED）。正因为 N2 连接还在，所以从 INACTIVE 恢复时不需要重新走注册、鉴权这些 NAS 流程——核心网那边的"户口"从没动过。挂起/恢复完全是接入网（gNB）在自导自演，核心网只在挂起时收到一个"我把它挂起了"的通知，并不删除任何东西。

这也解释了 INACTIVE 恢复为何如此之快：它纯粹是 RRC 层 + 少量 RRC 内部信令的事，根本不惊动核心网的控制面。

七、时延与功耗的权衡：一张"性价比"曲线

我们用公式把三态在"省电"和"低时延"上的权衡量化一下。设终端在状态 $s$ 下的平均功耗为 $P_s$、恢复到发数据的时延为 $D_s$：

状态	$P$（功耗）	$D$（恢复时延）
IDLE	$P_{\text{IDLE}}$（最低）	$D_{\text{IDLE}}$（最高，几十~上百 ms）
INACTIVE	$P_{\text{INACTIVE}} \approx P_{\text{IDLE}}$（接近）	$D_{\text{INACTIVE}}$（几~十几 ms）
CONNECTED	$P_{\text{CONN}}$（最高）	$0$

理想的"省电+低时延"目标函数可以写成：

$$ \text{Cost} = \alpha \cdot P_s + \beta \cdot D_s $$

其中 $\alpha, \beta$ 是业务对功耗和时延的权重。对不同业务，最优驻留状态不同：

对时延敏感、来包频繁的业务（如在线游戏、即时通信）：$\beta$ 大，应尽量停在 INACTIVE，恢复时延小。
对功耗极敏感、来包稀疏的业务（如物联网温度传感器，几小时一个包）：$\alpha$ 大，应停在 IDLE，INACTIVE 的保活开销反而不划算（gNB 长期为它占内存不划算）。
持续大数据业务（视频流）：停在 CONNECTED，因为反正一直要发数据。

这就是为什么状态驻留策略不是一刀切——gNB 会根据核心网下发的"核心网辅助信息"（如业务周期、终端类型）来动态决定把终端挂到 INACTIVE 还是直接释放到 IDLE。一个智能的挂起策略，能在大规模物联网场景下把信令和功耗同时压到最低。

八、现网实战：工程师如何看到这些

8.1 抓包和日志里长什么样

在路测软件或基站 log 里，三态切换有几个标志性的"指纹"：

进入 INACTIVE：看到 gNB 发出一条 RRCRelease，且其中包含 suspendConfig IE（而不是裸的 Release）。在 5G 信令解析里搜 suspendConfig 出现，就是挂起。同时 N2 接口能看到一条 UE CONTEXT SUSPEND REQUEST。
恢复：看到 RRCResumeRequest（MSG3 上，带 I-RNTI）→ RRCResume → RRCResumeComplete 三连，且之间没有 SecurityModeCommand、没有 NAS 鉴权。如果中间冒出了 RRCSetup，说明上下文丢了、退回完整建立——这是个值得注意的现象。
退回 IDLE：看到 RRCRelease 不带 suspendConfig，或者 RNA 更新超时后 gNB 删除上下文。

8.2 调试陷阱与常见误解

陷阱一：把 RRC_INACTIVE 误当成 CM-IDLE。 排查寻呼问题时常犯。终端在 INACTIVE 态，核心网认为它 CM-CONNECTED，下行数据到达时核心网不会发 CN 寻呼，而是直接通过已有的 N2 连接把数据送给 gNB，由 gNB 在 RNA 内发 RAN 寻呼唤醒终端。如果你按"IDLE 态靠 CN 寻呼"的老思路去排查，会一脸懵——为什么没有寻呼记录、数据却到了。

陷阱三：RNA 配置过大或过小。 - RNA 太大：RAN 寻呼要广播太多小区，寻呼开销爆炸。 - RNA 太小：终端稍微动一动就移出 RNA，频繁触发 RNA Update，省信令的好处全被抵消。合理的 RNA 规划是网优的关键工作之一。

陷阱四：小数据传输（SDT）和 Resume 的关系。 INACTIVE 态还支持在恢复过程中捎带少量数据（SDT, Small Data Transmission）——终端在 RRCResumeRequest/MSG3 阶段就把那点小数据发出去了，连 Resume 完成都不用等，进一步降时延。排障时看到数据在 Resume 还没完成时就开始传，别以为是抓包错乱。

九、一句话串起全文

RRC 三态机本质上是移动通信对"省电、低时延、省信令"这个不可能三角的一次精妙分割：

IDLE 牺牲"找终端的容易度"和"恢复速度"，换极致省电；
CONNECTED 牺牲"功耗"，换极致响应；
INACTIVE 用"双存上下文 + RNA 隐身移动 + 派生密钥快速恢复"这套组合拳，同时把省电和低时延拿下了，代价只是 gNB 多占一点内存保活。

它不是 5G 工程师拍脑袋加的状态，而是被"高频小数据"这种现代业务特征倒逼出来的必然设计。理解了它，你就理解了 5G 为什么能在海量连接下还保持低时延和可控信令——因为绝大多数终端，正舒舒服服地趴在 INACTIVE 这个"午间小憩"里，随叫随到。

常见问题

Q1：RRC_INACTIVE 和 RRC_IDLE 到底最本质的区别是什么？ A：一句话——UE 的 AS 上下文在不在 gNB 里。IDLE 态 gNB 完全没有终端的接入层上下文，恢复必须从头建立（含鉴权、安全激活、承载重配）；INACTIVE 态上下文双存于 UE 和 gNB，恢复时用 I-RNTI 找回上下文、派生密钥即可，跳过全部 NAS 交互。由此衍生出 INACTIVE 对应 NAS 的 CM-CONNECTED、恢复快、寻呼靠 RAN 寻呼等所有差异。

Q2：为什么 INACTIVE 态下核心网不重新寻呼，下行数据怎么到终端？ A：因为挂起时 N2 连接没断，核心网始终认为终端是 CM-CONNECTED。下行数据到达时，UPF/AMF 通过已有的 N2/N3 路径直接把数据送到"最后服务 gNB"，由该 gNB 在 RNA 范围内发 RAN 寻呼唤醒终端，终端收到后发起 Resume。所以这种场景下你看不到传统的 CN 寻呼，看到的是 RAN 寻呼。

Q3：终端在 INACTIVE 态换小区了，需要做切换或位置更新吗？ A：不需要传统切换。终端按 IDLE 的方式做小区重选。只要还在 RNA 内，零信令、网络无感知。一旦重选到 RNA 外，才发起一次 RNA Update（本质是个 Resume 请求），由网络把上下文搬到新 gNB 并（可能）重配 RNA，然后再次挂起。这正是 INACTIVE 态实现"隐身移动"的机制。

Q4：挂起的终端能一直挂下去吗？什么时候会被踢回 IDLE？ A：不能无限期。主要触发回退的情形：① 周期性 RNA 更新超时（终端没按时报到）；② RAN 寻呼失败（在 RNA 内广播找不到终端）；③ gNB 因内存/策略主动回收上下文。一旦回 IDLE，gNB 删除 AS 上下文，恢复就只能走完整建立。所以挂起是"有限期的保活"，时长由 inactivity timer、RNA 更新定时器和 gNB 策略共同决定。

Q5：I-RNTI 为什么是 40bit 这么长，C-RNTI 才 16bit？ A：C-RNTI 只在单个小区内寻址激活连接的终端，16bit 在一个小区内够用。I-RNTI 要在 gNB 范围内（甚至跨 gNB 取回上下文时）唯一标识挂起终端，且通常编码了 gNB 标识 + UE 标识两段，所以需要更长位数保证全局唯一。40bit 是兼顾"唯一性足够"和"能塞进随机接入 MSG3 不超限"的折中。

参考来源

5G | ShareTechnote - RRC INACTIVE — 5G RRC INACTIVE 态的图文化讲解，含状态转换与挂起/恢复机制示意
5G NR RRC States - RRC_IDLE, RRC_CONNECTED, RRC_INACTIVE (3GLTEInfo) — 三态定义、属性与相互关系的参考页
5G NR Inactive-RNTI (I-RNTI) for RRC_INACTIVE State (TechPlayon) — I-RNTI 结构与 ResumeRequest 消息尺寸的细节
5G NR RRC INACTIVE State and RAN-Based Notification Area (RNA) (TelecomHall) — RNA 概念、核心网辅助信息与 RNA Update 流程
Meet 5G latency requirements with inactive state (Ericsson Technology Review) — INACTIVE 态如何满足 5G 低时延需求的厂商技术分析

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

51学通信知识星球海报-扫码加入