首页 › deep-tech › 非激活态：浅睡待命的第三态

非激活态：浅睡待命的第三态

一、从"假寐"说起：终端也需要打盹

想象你在一个重要岗位上值班。任务一来，你必须立刻全神贯注投入工作——这是连接态（CONNECTED），全程睁着眼、耗着电、随时响应。任务结束，你可以下班回家、彻底放松，下次上班重新走一遍登记流程——这是空闲态（IDLE），最省电，但再来任务时从零启动、最慢。

可是现实里，多数人的状态既不是彻底下班，也不是全程在岗，而是坐在值班室里打个盹：工牌还挂着、门禁还有效、岗位上下文（你负责什么、权限多少、上次干到哪）都原封不动记着。一旦有事，你不用重新办入职、不用重新发工牌，眨眨眼就能接着干。

5G 给终端设计的非激活态（RRC_INACTIVE），就是这个"打盹待命"的中间状态。它介于空闲与连接之间，既享受接近空闲态的低功耗，又保留了连接态的快速响应能力。理解这个状态，是理解 5G 移动性管理为何"既快又省"的钥匙。

一句话锚点：非激活态不是"断开连接"，而是"挂起连接"。上下文寄存在基站，终端打个盹。

二、LTE 的两态之痛：为什么非要多一个状态

要理解第三态的必要性，得先看清"只有两态"时会撞上什么墙。

在 4G LTE 时代，终端只有 IDLE 和 CONNECTED 两种 RRC 状态。这套机制对"打电话、看视频"这类连续长业务很合适——一旦连接，就长时间保持。但随着移动互联网和物联网的兴起，一个尴尬的现象出现了：

大量应用是"频繁的小数据包"——即时消息的心跳、社交软件的推送、智能电表每分钟一次的读数、可穿戴设备的健康上报。这些业务的特点是：

每次就传几百字节，传完就没动静；
但传的频率不低，几分钟到几十分钟一次；
对时延有要求（推送得及时）；
对功耗极度敏感（尤其是 IoT 设备，电池要撑几年）。

在这类场景下，两态机制进退两难：

如果留在连接态：终端要持续监听调度信道（PDCCH）、维持同步、定期发测量报告，功耗居高不下，一块电池几天就没电。
如果回空闲态省电：下次有数据时，终端必须走一遍完整的"连接建立"流程——随机接入、RRC 建立请求、安全激活、承载建立、能力查询……一连串信令来回，动辄上百毫秒到秒级，时延大不说，还把"省下的电"在重建过程中又吐回去了，同时给网络制造了海量的信令风暴。

这正是 3GPP 工程师们面对的矛盾：省电和省时延，在两态模型下是鱼和熊掌。 非激活态的出现，本质就是把这对矛盾拆开——它把"上下文还在不在网络里"和"空口连不连着"这两件事解耦了。

下面这个公式概括了三态在功耗与时延上的权衡：

$$ \text{总开销} \;=\; \underbrace{P_{\text{驻留}} \cdot T_{\text{待机}}}{\text{维持开销}} \;+\; \underbrace{L $$}} \cdot f_{\text{唤醒}}}_{\text{重建开销}

连接态：$P_{\text{驻留}}$ 大，$L_{\text{重建}}=0$；
空闲态：$P_{\text{驻留}}$ 小，但 $L_{\text{重建}}$ 大、$f_{\text{唤醒}}$ 高时总开销爆炸；
非激活态：$P_{\text{驻留}}$ 接近空闲，而 $L_{\text{重建}}$ 被压到极小（只发一条恢复请求）。这才是它真正的价值锚点。

三、三态全景：终端的三种"清醒程度"

先用一张表把三种状态的本质区别讲清楚。理解三态，关键看四个维度：上下文在不在、空口连不连、谁负责找你（寻呼）、功耗水平。

维度	RRC_IDLE（空闲）	RRC_INACTIVE（非激活）	RRC_CONNECTED（连接）
UE 接入层(AS)上下文	不保存	保存（挂起在锚点基站）	保存（激活）
空口(Uu)连接	无	已挂起（suspended）	有，可随时收发数据
NAS(核心网)连接状态	CM-IDLE	CM-CONNECTED（核心网仍当你"连着"）	CM-CONNECTED
谁负责寻呼/位置管理	核心网，按跟踪区(TA)寻呼	接入网，按 RNA 寻呼	无需寻呼，直接调度
谁认识你的身份	5G-S-TMSI（核心网临时身份）	I-RNTI（接入网临时身份）	C-RNTI（小区级身份）
功耗	最低	低（接近空闲）	高
恢复到连接的时延	慢（完整建立流程）	快（一条 Resume）	已在连接

这张表里藏着两个最反直觉、也最关键的设计点，请务必记住：

NAS 仍处于 CM-CONNECTED：终端进了非激活态，核心网（AMF）根本没觉得它"走"——核心网这层一直当你还是连着的。挂起的只是无线侧（Uu 空口）这一段。这意味着非激活态本质是"接入网内部的省电优化"，核心网基本无感。
上下文寄存在"锚点基站"：终端的完整配置（安全密钥、承载参数、能力信息）被原样存放在它进非激活态前最后服务的那个基站里。这个基站叫锚点基站（anchor gNB）。这正是"打盹待命"能瞬间清醒的物质基础——岗位上下文没丢。

下面这张状态机图，把三种状态的合法转换路径一次画清：

stateDiagram-v2
    [*] --> IDLE
    IDLE --> CONNECTED : RRC建立（完整流程）
    CONNECTED --> IDLE : RRC释放（释放上下文）
    CONNECTED --> INACTIVE : RRC释放（带挂起配置）
    INACTIVE --> CONNECTED : RRC恢复（快速，首选）
    INACTIVE --> IDLE : 恢复失败/超时回退
    note right of INACTIVE
        NAS仍CM-CONNECTED
        上下文挂在锚点基站
        用I-RNTI识别身份
    end note

注意图里那条 CONNECTED → INACTIVE 的虚线箭头：它不是"断开"，而是"带挂起配置的释放"。基站发的是一条 RRC Release 消息，但里面塞了一个 suspendConfig 字段——这条消息同时完成了两件事：释放空口、又把上下文冻起来。

四、挂起的智慧：上下文究竟"寄存"在哪里

非激活态的全部魔法，都源于一个朴素的设计：别把上下文删掉，把它冻起来。

当基站决定让终端进入非激活态时，它下发一条 RRC Release 消息，但消息里携带 suspendConfig，里面打包了几样关键"行李"：

寄存项	作用	类比
I-RNTI	40 比特的接入网临时身份，用于标识"哪个终端 + 寄存在哪个锚点基站"	打盹时发给你的"寄存柜号牌"
t380	周期性 RNA 更新定时器	"每 X 小时报一次到，否则算失联"
RNA 配置	终端可以自由活动的小区集合	打盹时允许溜达的区域范围
shortMAC-I（短 MAC 鉴权码）	恢复时证明"我是柜子真正主人"的凭证	寄存柜的密码

其中 I-RNTI（Inactive-RNTI） 是理解非激活态寻址的核心。它是一个 40 比特的标识，结构上拼了两段：

$$ \underbrace{I\text{-}RNTI}{40\ \text{bit}} \;=\; \underbrace{\text{NG-RAN 节点 ID}} $$}} \;\big|\; \underbrace{\text{UE 短身份}}_{剩余比特

前半段指向锚点基站（上下文存哪），后半段指向那个基站下的具体终端。这样设计有个妙处：当终端溜达到一个新基站、要恢复连接时，新基站只要解出 I-RNTI 的前半段，就知道"该去哪个老基站把它的上下文取回来"。

设计洞察：I-RNTI 同时编码了"东西存哪"和"是谁的东西"两层信息，这让"跨基站恢复"成为可能——这是非激活态区别于普通挂起的精髓。LTE 时代的挂起做不到任意基站恢复，正是因为缺少这种全局寻址。

与此同步，基站通过 NG 接口向核心网发一条 UE Context Suspend 请求，告诉 AMF："我把无线侧挂起了，但终端上下文我替你存着。" AMF 收到后，也把自己的状态记成"挂起"，但绝不把终端当成 CM-IDLE。

至此，终端安然入睡，它的"岗位"被原样封存在锚点基站和核心网里。

五、恢复的快车道：Resume vs 完整建立

非激活态最迷人的地方，是醒来极快。对比一下"从空闲态建立连接"和"从非激活态恢复连接"，差异一目了然。

完整的空闲态建立（IDLE→CONNECTED），信令像一条长队：

RRC Setup Request → RRC Setup → RRC Setup Complete
→ 安全模式命令(SMC)交互 → UE 能力查询 → 承载建立 → Path Switch ……

而恢复流程（INACTIVE→CONNECTED），核心只有一句话：终端发 RRC Resume Request，基站回 RRC Resume。

sequenceDiagram
    participant UE
    participant NewgNB as 新基站 gNB-B
    participant AnchorgNB as 锚点基站 gNB-A
    participant AMF
    UE->>NewgNB: RRC Resume Request<br/>(携带 I-RNTI + shortMAC-I)
    Note over NewgNB: 从I-RNTI解出锚点=gNB-A
    NewgNB->>AnchorgNB: XnAP: Retrieve UE Context<br/>(取回冻结的上下文)
    AnchorgNB-->>NewgNB: UE Context + 安全参数 + 承载配置
    Note over NewgNB: 校验shortMAC-I，派生新密钥
    NewgNB->>AMF: Path Switch Request<br/>(把数据通路切到新基站)
    AMF-->>NewgNB: Path Switch Response
    NewgNB-->>UE: RRC Resume<br/>(恢复空口，可收发数据)
    Note over UE: 一条请求+一条响应，连接就续上了

看清楚流程的精髓了吗？终端不用重新走安全激活、不用重新走能力上报、不用重建承载——因为这些配置全都从锚点基站原封不动地"搬"了过来。新基站做的只是：

从 I-RNTI 找到锚点基站；
通过 Xn 接口把冻结的上下文取回（Retrieve UE Context）；
用 shortMAC-I 验证终端身份、用旧的根密钥派生新的空口密钥（见下一节）；
把数据通路（N3 隧道）从锚点切换到自己；
下发 RRC Resume，连接瞬间续上。

更巧妙的是，恢复请求发出去之后，网络有三种合法回应方式，对应不同场景：

网络回应	含义	适用场景
RRC Resume	直接恢复成连接态，开始传数据	有正常上下行业务
RRC Release（带挂起）	恢复一下又让终端睡回去	只是来报个到（如 RNA 更新）
RRC Setup	退回完整建立流程	取上下文失败/安全校验不过，只能从头来

最后一种"回退到完整建立"是工程师必须知道的兜底：当锚点基站已经把上下文删掉（比如挂起太久超时）、或跨厂商取上下文失败时，网络不会让终端卡死，而是降级走完整流程，终端此时会从非激活态回退到空闲态再重新建立。

时延对比（量级）：空闲态完整建立通常在百毫秒级；非激活态恢复常被压到十几到几十毫秒。对时延敏感的物联网和即时消息业务，这个差距就是"能用"和"好用"的分水岭。

六、RNA：把"寻呼范围"做小的艺术

终端睡过去了，万一网络有下行数据要给它怎么办？必须得"叫醒"它，这就是寻呼。但在非激活态，寻呼这件事被接入网"接管"了，这里诞生了一个全新概念——RNA（基于接入网的通知区域，RAN-based Notification Area）。

先回顾空闲态怎么寻呼：核心网按跟踪区（TA）来寻呼终端。一个 TA 包含几十上百个小区，TA 还可以组成 TA 列表更大。核心网要找终端，就在整个 TA 范围内对所有小区广播寻呼——范围大、信令重。

非激活态的逻辑是：既然终端的上下文寄存在锚点基站，那就由这个锚点基站来管它的"活动范围"，把寻呼范围做小。

RNA 就是锚点基站给终端划定的一个或多个小区的集合（可以只在本基站内，也可以包含邻站的小区）。规则很简单：

终端在 RNA 范围内移动 → 完全静默，不用通知网络；
终端越出 RNA 边界 → 必须执行 RNA 更新，重新报到。

对比项	跟踪区 TA（空闲态）	RNA（非激活态）
管理者	核心网（AMF）	接入网（锚点基站）
粒度	大（几十~上百小区）	小（可小到单个基站几个小区）
触发的更新	TAU（核心网报到，信令重）	RNAU（接入网报到，信令轻）
寻呼执行	核心网下发，跨 TA 广播	锚点基站下发，只在 RNA 内广播
寻呼信令开销	高	显著降低

为什么把范围做小是好事？因为寻呼是广播行为——找一个人，要对范围内所有小区都喊一遍。范围越小，每次喊的代价越低。RNA 把"喊人范围"从整个跟踪区压缩到几个小区，大幅削减了寻呼信令风暴。

当然，天下没有免费的午餐。RNA 太小，终端稍微一动就出界，触发频繁的 RNA 更新，反而增加信令；RNA 太大，又失去了寻呼省信令的意义。RNA 尺寸的规划，是网优工程师手里一把关键的旋钮。

调优经验：城市密集区、终端移动性强，RNA 宜配大一些（减少更新）；固定物联网设备（如水表），RNA 可以配到最小（几乎不更新，寻呼也极轻）。RNA 大小本质是在"更新信令"和"寻呼信令"之间找平衡点。

七、RAN 寻呼：核心网"放手"的智慧

理解了 RNA，RAN 寻呼的流程就水到渠成了。

当非激活态终端有下行数据到来时，由于 NAS 仍是 CM-CONNECTED，数据其实能一路送到接入网附近。但终端此刻空口是挂起的，基站得把它叫醒。叫醒的任务，落在了锚点基站身上：它在 RNA 范围内（包括它自己和邻站的小区）广播寻呼。

sequenceDiagram
    participant DN as 下行数据源
    participant UPF
    participant AMF
    participant Anchor as 锚点基站 gNB-A
    participant Neighbor as RNA内邻站 gNB-C
    participant UE as 终端(非激活态)
    DN->>UPF: 下行数据包
    UPF->>AMF: 触发寻呼(NAS仍CM-CONNECTED)
    AMF->>Anchor: 寻呼请求(交给锚点基站处理)
    Note over Anchor: 锚点在自己+RNA内邻站广播
    Anchor->>Neighbor: Xn: RAN Paging(转发寻呼)
    Anchor->>UE: 空口广播寻呼(用P-RNTI/短消息)
    Neighbor->>UE: 空口广播寻呼
    UE->>Anchor: 收到！发起 RRC Resume Request
    Note over UE,Anchor: 唤醒后恢复连接，接收数据

这条流程的关键体感是：核心网只把"找人"的活儿交给锚点基站就甩手了，自己根本不用跨整个跟踪区广播。寻呼范围被精准限制在 RNA 这一小片区域。这就是非激活态"既省终端电、又省网络信令"的双赢所在。

一个常被忽略的细节：RAN 寻呼用的是和空闲态寻呼相同的空口物理信道（同样是 PDCCH 用 P-RNTI 加扰、PDSCH 承载），终端按非激活态专用的寻呼时机醒来监听即可。所以终端在非激活态下的"打盹节奏"，和空闲态的 DRX（不连续接收）是非常相似的——这也是它功耗接近空闲态的原因。

八、RNA 更新：第三态的"报到信令"

终端在 RNA 内溜达可以静默，但有两种情况必须主动报到，这就是 RNA 更新（RNAU）：

越界：移动到了 RNA 之外的小区；
超时：周期性定时器 t380 到期（即便没动，也得定时确认"我还活着、上下文还有效"）。

RNA 更新的信令流程，本质上就是一次"恢复 + 立刻再睡"的过程：

sequenceDiagram
    participant UE as 终端
    participant NewgNB as 新基站 gNB-B(新RNA)
    participant Anchor as 原锚点基站 gNB-A
    participant AMF
    Note over UE: t380超时 或 移动出RNA
    UE->>NewgNB: RRC Resume Request(I-RNTI + shortMAC-I)
    NewgNB->>Anchor: XnAP: Retrieve UE Context
    Anchor-->>NewgNB: 返回冻结上下文
    Note over NewgNB: 校验身份、可能成为新锚点
    NewgNB->>AMF: Path Switch / 通知核心网
    AMF-->>NewgNB: 确认
    NewgNB-->>UE: RRC Release(带新的suspendConfig)
    Note over UE: 给新RNA、重置t380，继续打盹

看出和普通恢复的区别了吗？RNA 更新结束时，网络不让终端留在连接态，而是立刻下发一条带新挂起配置的 RRC Release——给终端划定新的 RNA、重置 t380，让它继续回去打盹。终端报到完，转身又睡，全程对用户透明。

这正好呼应了上一轮科普里讲过的 TAU（跟踪区更新）。RNA 更新就是非激活态版本的"报到信令"，两者的设计哲学如出一辙，但层次不同：

TAU：报到给核心网，按 TA 边界触发，走 NAS 信令，重；
RNAU：报到给接入网，按 RNA 边界触发，走 RRC 信令，轻。

网优陷阱：t380 配得太小，海量终端会定时醒来发 RNAU，制造周期性信令尖峰；配得太大，挂起的上下文可能早就被网络因超时清除，下次恢复时被迫回退到完整建立，反而更慢。典型值在几小时量级，需结合业务模型和设备规模精调。

九、安全连续性：换个基站，为何还能认出你

非激活态有个绕不开的安全问题：终端睡在 A 基站，醒来时可能已经溜到 B 基站，B 凭什么相信"你是 A 当初挂起的那个终端"？又怎么保证密钥还能续上？

答案分两步。

第一步：身份校验。 终端在恢复请求里携带挂起时下发的 shortMAC-I（由挂起前的完整性密钥派生的一段短鉴权码）。基站取回上下文后，用同样的密钥材料重算一遍、和终端报上来的比对。对得上，就证明终端确实握有当初的密钥——这是"物归原主"的凭证。

第二步：密钥派生。 终端一旦在新基站恢复成功，空口密钥必须刷新（不能继续用老的，否则有重放风险）。5G 用一个叫 nextHopChainingCount（NHC） 的计数器来驱动一次横向密钥派生：

$$ K_{NG\text{-}RAN}' \;=\; \text{KDF}\Big(\, K_{NG\text{-}RAN},\;\; \text{"NG-RAN"} \,|\, \text{NHC} \,\Big) $$

$$ K_{RRCint},\; K_{RRCenc},\; K_{UPint},\; K_{UPenc} \;\leftarrow\; K_{NG\text{-}RAN}' $$

这里 $K_{NG\text{-}RAN}$ 是挂起前就安全保存的根密钥，KDF 是标准的密钥派生函数。每次恢复 NHC 加一，密钥就向前推进一步。这样即便终端换到新基站、跨小区多次挂起-恢复，密钥链始终连续、且前向安全——老密钥推不出新密钥，攻击者截获一次也复用不了。

设计洞察：非激活态的安全精髓，是"上下文寄存 + 密钥链连续"。它让"快速恢复"和"安全不降级"两个看似矛盾的目标同时成立。这也是为什么非激活态恢复省时延，却不以牺牲安全为代价。

十、SDT 小数据传输：连"醒来"都省了

非激活态已经够省了，但工程师们还想更省——对于"真的只有一丁点数据"的场景（比如智能电表上报一次读数、定位心跳），连走一遍恢复流程都觉得浪费。

于是 5G 后续版本引入了 SDT（Small Data Transmission，小数据传输）：允许终端在非激活态下，直接捎带少量数据，而无需完整恢复到连接态。它有两条技术路径：

SDT 方式	原理	特点
RA-SDT	复用随机接入过程（2 步或 4 步 RACH），在消息里捎带上行小数据	终端主动发起，灵活
CG-SDT	基站预先分配好上行授权（Configured Grant），终端直接在指定资源上发	无需 RACH，时延最低

SDT 的本质，是把非激活态从"只能睡"升级成"边睡边吐数据"。数据量小到一定程度时，终端根本不用真正醒来、不用恢复完整连接，吐完接着睡。对海量物联网设备，这是把信令开销和功耗又往下压了一个台阶。

工程边界：SDT 有严格的触发条件——数据量必须小于配置门限、且必须是上行触发或网络允许。一旦数据量超限或持续时间变长，SDT 会自动升级为完整恢复。所以 SDT 不是替代恢复，而是恢复的"轻量前置"。

十一、定时器体系：非激活态的"生物钟"

非激活态的行为由一组定时器驱动，理解它们是调试的基础。几个最关键的：

定时器	作用	超时后果
t380	周期性 RNA 更新定时器（非激活态专属）	终端发起 RNA 更新报到
t319	恢复过程相关定时器（等待恢复响应）	超时则恢复失败，可能回退空闲
T3324（NAS 层）	控制是否允许进入/保持在非激活态（与节电策略相关）	影响状态停留策略
锚点侧挂起保持定时器	锚点基站保留冻结上下文的时长	超时则删除上下文，恢复时只能回退完整建立

这些定时器构成非激活态的"生物钟"。其中 t380 是网优最常调整的：它决定了终端报到的频率，直接关系到信令负荷和上下文有效性之间的平衡。

十二、实战连接：工程师的调试视角与三大陷阱

讲了这么多原理，落到现网和调试台，这些知识到底怎么用？

1. 信令抓包识别非激活态。 在终端侧或基站侧抓 RRC 信令，看到 RRC Release 里携带 suspendConfig 字段，就能确认终端进入了非激活态（而不是普通释放回空闲）。恢复时看到 RRCResumeRequest（而不是 RRCSetupRequest），就知道是恢复流程。I-RNTI 是追踪终端跨基站行为的关键字段。

2. 定位"恢复慢/失败"。 终端从非激活态恢复慢，常见原因有二：一是锚点基站取上下文失败（Retrieve UE Context 超时或跨厂商不兼容），导致被迫回退完整建立——看 Xn 接口信令能定位；二是挂起时间过久、上下文已被锚点删除，同样会回退。

3. 网优看 RNA 与 t380。 寻呼成功率低、信令负荷高时，要审视 RNA 划分和 t380 取值。RNA 过小会导致 RNAU 风暴，过大则寻呼过重——这两个指标需要联合调优。

调试中常见的三大误解，专门点名：

误解一："非激活态就是空闲态的别名。" 错。最致命的区别：非激活态 NAS 仍是 CM-CONNECTED、上下文寄存在锚点、寻呼由接入网按 RNA 执行。把它当空闲态处理，会导致寻呼策略、计费、移动性管理全部错乱。
误解二："进非激活态就不耗电了，等于关机待机。" 错。非激活态仍要按寻呼时机醒来监听、维持基本同步，只是比连接态省得多，接近空闲而非等于空闲。
误解三："终端在非激活态移动到任何地方都不用通知网络。" 错。只在 RNA 范围内才静默；一旦越出 RNA，必须发 RNA 更新，否则网络找不到它，下行数据会因寻呼无响应而丢弃。

常见问题

Q1：非激活态和空闲态，到底谁更省电？ A：空闲态略省，但差距不大——两者都用 DRX 间歇性醒来监听寻呼，关掉了大部分持续发射。非激活态真正的优势不在"比空闲更省电"，而在"省电的同时，恢复成连接的速度快一个量级"。它是为"频繁小数据"量身定制的中间态，省电水平接近空闲、响应速度接近连接。

Q2：RNA 更新（RNAU）和跟踪区更新（TAU）是什么关系？ A：它们是同一设计思想在两个层次的体现。TAU 报到给核心网、按 TA 触发、走 NAS 信令；RNAU 报到给接入网（锚点基站）、按 RNA 触发、走 RRC 信令。非激活态终端只做 RNAU（轻量），不打扰核心网；只有回退到空闲态才会做 TAU。

Q3：为什么恢复到新基站时，不用重新做安全激活？ A：因为挂起前终端和网络的共享密钥 $K_{NG\text{-}RAN}$ 被安全保存了。恢复时，新基站用 shortMAC-I 验明正身，再用保存的根密钥通过 NHC 计数器做一次横向派生（$K_{NG\text{-}RAN}'$），就能得到全新的空口密钥。安全链是连续的，所以无需从头走一遍完整鉴权。

Q4：什么样的终端/业务最适合用非激活态？ A：频繁收发小数据、对时延敏感、又对功耗敏感的业务最受益：即时消息、社交推送、可穿戴设备、智能电表/传感器。对持续大流量业务（看视频、下载）意义不大，因为这类业务本来就要长期保持连接。

Q5：SDT 和普通恢复有什么区别，什么时候用 SDT？ A：普通恢复会把终端彻底唤醒到连接态、建立完整数据通路；SDT 则让终端在非激活态下"顺手"捎带少量数据，不完整恢复。只有数据量小于配置门限、且满足触发条件时才走 SDT；数据一旦变大或持续，会自动升级为完整恢复。SDT 是恢复流程的轻量化前置，不是替代品。

参考来源

5G | ShareTechnote — RRC INACTIVE — 5G RRC 三态及挂起/恢复机制的权威图解教程，理解状态转换的经典入口。
NR RRC Inactive — Amarisoft Tech Academy — 从协议栈角度剖析非激活态引入背景、RNA、寻呼与恢复流程的工程化讲解。
RRC States Explained: Idle, Connected and Inactive in LTE and 5G NR — Hicelltek — 对比 LTE 两态与 5G 三态差异，讲清"为什么要加第三态"。
5G NR 非激活态的移动性（RNA/寻呼/RNA 更新）— CSDN — 中文社区对 RNA、RAN 寻呼、RNA 更新与小区重选的详细流程梳理。
Small Data Transmission (SDT) — 3GPP — 3GPP 官方对非激活态下小数据传输（RA-SDT / CG-SDT）机制的标准性介绍。

本文由「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学通信知识星球海报-扫码加入