首页 › ran › RRC_INACTIVE状态RNA管理机制与运营商成本博弈

RRC_INACTIVE状态RNA管理机制与运营商成本博弈

1. 引言:从"连着浪费"到"挂着省"

5G网络商用五年后,运营商面临一个尖锐的成本矛盾:数十亿终端时刻在线,但绝大多数时间不发数据。根据爱立信2025年移动报告,典型5G智能手机每分钟仅有约2秒有实际数据传输,其余58秒的RRC_CONNECTED状态纯粹是"开着射频等指令"——每秒钟都在消耗终端电池和基站射频资源。

3GPP在Release 15引入了一个全新的RRC状态——RRC_INACTIVE(TS 38.331 Section 4.2.1),核心思想是"挂起不断开":UE与核心网之间保持NAS信令连接(CM-CONNECTED),但在空口释放RRC连接,UE存储AS上下文(UE Inactive AS Context),可随时快速恢复。这看似简单的设计,背后涉及一套精密的RAN通知区域(RNA)管理机制,直接决定了运营商的信令开销、寻呼成本和用户体验。

本文聚焦TS 38.331 V18.5.0中RRC_INACTIVE状态的RNA配置、RNAU(RNA Update)流程、RAN Paging机制,从信令细节出发,逐层解析其对运营商OPEX的真实影响。

2. RRC_INACTIVE状态机制全景

2.1 三态模型与状态转换

5G NR定义了三个RRC状态(TS 38.331 Section 4.2.1),与LTE的两态模型相比,核心创新是RRC_INACTIVE:

                    RRCRelease
                   (with suspendConfig)
        RRC_CONNECTED ──────────────► RRC_INACTIVE
             │ ▲                           │ ▲
             │ │  RRCResume               │ │ RNA Update
             │ │  RRCSetup                │ │ RAN Paging
             │ │                          │ │ SDT
             │ │                          │ │
             │ │    RRCRelease            │ │
             │ ◄──────────────────────────│ │
             │     (without suspend)      │ │
             │                                │
             │  RRCRelease                    │ RRCRelease
             │  (go to IDLE)                  │ (go to IDLE)
             ▼                                ▼
        RRC_IDLE ◄───────────────────────────┘

2.2 RRC_INACTIVE的核心特征

根据TS 38.331 Section 4.2.1对RRC_INACTIVE的定义,UE在该状态下具备以下行为:

特征维度 RRC_INACTIVE RRC_IDLE RRC_CONNECTED
NAS状态 CM-CONNECTED CM-IDLE CM-CONNECTED
AS上下文 UE存储Inactive AS Context 不存储 UE和网络均存储
移动性 UE控制(小区重选) UE控制(小区重选) 网络控制(切换)
DRX 上层或RRC层配置 仅上层配置 MAC层C-DRX
寻呼监听 CN Paging + RAN Paging 仅CN Paging 不需要
RNA管理 周期性RNAU + 边界RNAU TA Update 不需要
安全上下文 挂起但保留 释放 完整激活
SDT R18支持 不支持 不需要

关键设计意图:RRC_INACTIVE的本质是"把移动性管理从网络侧下放到UE侧",通过小区重选替代切换,用RNAU替代TAU,大幅减少空口信令量。代价是引入了RAN侧的上下文管理和寻呼开销。

3. RNA机制深度解析

3.1 RNA(RAN Notification Area)配置

RNA是RRC_INACTIVE状态下的核心概念。根据TS 38.331 Section 6.2.2,RNA通过RRCRelease消息中的suspendConfig字段下发,包含以下关键IE:

图表1

图表 1

三种RNA配置模式(TS 38.331 Section 6.3.2):

配置模式 粒度 典型规模 信令开销 适用场景
TA List 跟踪区级别 数十个小区 低(仅TAC列表) 广域覆盖,UE移动性高
RAN Area Code RAN区域级别 数个到十数个小区 中(需配置RAN Area) 中等移动性,均衡方案
Cell List 小区级别 几个到几十个小区 高(需列举Cell ID) 固定位置IoT,极少移动

3.2 RNAU流程完整信令分析

RNA Update是RRC_INACTIVE状态下UE发起的核心流程,定义在TS 38.331 Section 5.3.13.8。

触发条件

UE在RRC_INACTIVE状态下发起RNAU的两个条件:

  1. T380超时:周期性RNAU。T380由suspendConfig中的t380字段配置,取值范围为5分钟到12小时(min5, min10, min20, min40, min60, min120, min180, min300, min360, min720)。
  2. 移出RNA:UE通过小区重选移动到不在RNA配置范围内的小区。

图表2

图表 2

关键IE解析

RRCResumeRequest1消息(TS 38.331 Section 6.2.2)包含以下核心字段:

IE名称 含义 长度 说明
resumeID I-RNTI标识 40 bit 用于gNB识别UE及定位原gNB
resumeCause 恢复原因 3 bit rna-Update / emergency / highPriorityAccess / mt-Access / mo-Signalling / mo-Data / mo-VoiceCall / mo-SMS / mo-VideoCall
spare 预留 1 bit —
shortMAC-I 验证令牌 16 bit 基于存储的安全上下文计算,防止伪造

I-RNTI结构(TS 38.331 Section 6.2.2):共40 bit,由gNB分配,其中高位bit用于标识gNB本身,低位bit标识该gNB下的UE上下文。这意味着新gNB收到RRCResumeRequest1后,可以解析出原gNB地址,通过Xn接口获取UE上下文。

3.3 RAN Paging机制

当网络需要向RRC_INACTIVE状态的UE发送下行数据时,触发RAN Paging(TS 23.502 Section 4.8.2.2a):

图表3

图表 3

RAN Paging vs CN Paging对比:

维度 RAN Paging CN Paging
发起方 gNB(RAN侧) AMF(核心网侧)
范围 RNA内的小区 TA List内的小区
标识 fullI-RNTI 5G-S-TMSI
控制面路径 Xn接口(gNB间) N2接口(AMF→gNB)
响应 RRCResumeRequest Service Request
上下文获取 从原gNB Retrieve 从AMF重新建立
时延 ~10-20ms ~50-100ms
信令开销 RAN侧信令 RAN + CN侧信令

4. RNA大小与运营商成本博弈

4.1 RNA大小的核心矛盾

RNA大小的配置是运营商网络优化中最核心的决策之一,存在根本性的成本矛盾:

RNA过大→每次RAN Paging需要在更多gNB和小区发送寻呼消息→空口寻呼开销增大→影响其他用户PDCCH资源→降低小区容量→间接增加CAPEX(需要更多小区分担寻呼负荷)

RNA过小→UE频繁移出RNA→频繁触发RNAU→Xn接口信令风暴→gNB间Retrieve UE Context开销增加→增加RAN侧OPEX

4.2 量化分析模型

基于TS 38.331的参数体系,可以建立RNA大小的成本模型:

图表4

图表 4

成本估算公式:

假设网络中有N个RRC_INACTIVE UE,RNA包含M个gNB,RNAU周期为T分钟:

以一个中等规模城市为例:

参数 典型值
N(RRC_INACTIVE UE数) 100,000
M(RNA内gNB数) 20-200
K(每gNB小区数) 3
T(T380周期) 10min
λ_page(每小时每UE下行触发次数) 0.5
λ_boundary(每小时移出RNA次数) 0.1-2.0(取决于RNA大小)

每月信令成本对比:

RNA配置 RAN Paging信令/月 RNAU信令/月 总信令 估算OPEX影响
M=20(小RNA) 720万 4320万 5040万 +30%(Xn处理负荷高)
M=50(中RNA) 1800万 1800万 3600万 基准
M=100(大RNA) 3600万 1080万 4680万 +20%(PDCCH资源紧张)
M=200(超大RNA) 7200万 720万 7920万 +50%(PDCCH瓶颈)

结论:存在一个最优RNA大小(本例中M≈50),使总信令成本最低。这个最优点因网络拓扑、用户行为和业务模型而异,没有统一答案。

4.3 不同场景的RNA策略

场景 建议RNA策略 T380 理由
智慧城市IoT传感器 小RNA(Cell List,M=5-10) 60-720min 固定位置,极少移动,RNAU几乎不触发;小RNA减少寻呼范围
智能电表 最小RNA(Cell List,M=1-3) 720min 完全静止,超长周期RNAU即可
智能手机用户(城区) 中RNA(TA List,M=30-80) 10-20min 中等移动性,需要平衡寻呼和RNAU
车载UE(高速公路) 大RNA(TA List,M=100-200) 5-10min 高速移动,频繁移出小RNA导致信令风暴
RedCap可穿戴设备 中小RNA(M=10-30) 20-60min 低移动性,省电优先

5. R18增强:SDT对RNA管理的影响

Release 18中引入的Small Data Transmission(SDT)机制(TS 38.331 Section 5.3.13.1b)改变了RNA管理的成本模型。

5.1 SDT核心机制

SDT允许UE在RRC_INACTIVE状态下直接传输小数据包,无需恢复到RRC_CONNECTED:

SDT触发条件(TS 38.331 Section 5.3.13.1b): 1. SIB1包含sdt-ConfigCommon 2. sdt-Config已配置 3. 所有待传UL数据映射到SDT配置的DRB 4. 底层指示MO-SDT条件满足

两种SDT模式: - RA-SDT:基于随机接入的SDT,使用Msg3/Msg5携带数据 - CG-SDT:基于配置授权的SDT,使用预配置的UL grant

5.2 SDT对成本模型的重构

SDT引入后的成本对比:

维度 无SDT 有SDT
小包传输信令 RRCResume + RRCReconfig + 数据 + RRCRelease ≈ 6-8条RRC消息 RA-SDT: 2-4条消息;CG-SDT: 1条消息
状态转换次数 INACTIVE→CONNECTED→INACTIVE(两次) 保持RRC_INACTIVE
gNB间上下文 每次传输需Retrieve UE Context RA-SDT: 仍需;CG-SDT: 可避免
UE功耗 高(射频持续开启) 低(快速发完即休眠)
时延 30-50ms 5-15ms(CG-SDT)

对于运营商而言,SDT的核心价值在于:

  1. 信令风暴缓解:典型IoT场景(智能电表每小时发一个100字节包),SDT可将信令量降低75-85%
  2. gNB处理能力释放:不再需要为每个小包执行完整的RRC Resume流程
  3. 网络容量提升:减少PDCCH占用,单小区可支撑更多RRC_INACTIVE UE

6. 实战:抓包识别与故障排查

6.1 抓包识别关键流程

识别RRC_INACTIVE进入(挂起): - 查找RRCRelease消息(Logical Channel: DCCH, SRB1) - 关键判据:消息中包含suspendConfig字段 - 提取信息:t380值、ran-NotificationAreaInfo内容、I-RNTI

识别RNAU: - 查找RRCResumeRequest或RRCResumeRequest1消息 - 关键判据:resumeCause = rna-Update(值为0) - 在Xn接口:查找RETRIEVE UE CONTEXT REQUEST

识别RAN Paging: - 空口:Paging消息中包含fullI-RNTI(非5G-S-TMSI) - Xn接口:查找RAN PAGING消息

6.2 常见故障点

故障现象 根因 排查方向
UE频繁RNAU(每分钟多次) RNA配置过小或T380过短 检查suspendConfig中RNA范围和t380值
RAN Paging失败率高 RNA内gNB间Xn链路故障 检查Xn Connectivity和gNB拓扑
UE无法恢复RRC连接 原gNB已释放UE上下文 检查gNB上下文保持定时器
安全验证失败(shortMAC-I) UE与gNB安全上下文不同步 检查nextHopChainingCount是否正确
SDT失败回退到普通Resume SDT配置的DRB不匹配 检查sdt-DRB-List与实际数据承载
RRC_INACTIVE→RRC_IDLE意外转换 网络发送了无suspendConfig的RRCRelease 检查gNB判断逻辑,可能是RNAU拒绝
## 7. 状态转换图:RRC_INACTIVE生命周期

图表5

图表 5

8. 成本分析:运营商视角的ROI

8.1 RRC_INACTIVE带来的成本节约

终端侧(间接影响运营商补贴成本): - 典型5G智能手机在RRC_CONNECTED状态功耗约1.5-2W,RRC_INACTIVE降至50-100mW - 电池寿命延长20-40%,减少用户因续航不满的换机投诉和补贴压力

网络侧(直接影响运营商OPEX): - 减少50-70%的RRC Connection建立/释放信令(对比始终保持在RRC_CONNECTED) - 空口PDCCH、PUSCH资源占用降低,单小区可多支撑30-50%并发用户 - 核心网侧:因CM-CONNECTED保持,避免每次数据传输触发NAS信令

8.2 RRC_INACTIVE引入的成本

成本项 具体内容 量级估算
gNB内存 每UE约1-5KB上下文存储 10万UE = 100-500MB/gNB
Xn信令 Retrieve UE Context + RAN Paging 每UE每小时0.5-3次Xn交互
gNB处理能力 RNAU处理、RAN Paging分发 需额外5-10% CPU
网络规划 RNA设计需要精细化RF规划 一次性人力投入
互操作风险 不同厂商gNB间Xn兼容性 持续测试维护成本

8.3 综合ROI评估

以10万用户的中型城市网络为例(月度成本模型):

成本/收益项 金额(万元/月) 说明
RRC信令减少→节省无线资源 -15 可服务更多用户,推迟扩容
核心网信令减少→降低AMF负荷 -3 减少NAS交互
用户电池续航改善→投诉减少 -2 客服成本降低
gNB内存增加 +1 上下文存储
Xn链路信令增加 +2 RNAU和RAN Paging
网络优化人力 +1 RNA参数调优
净收益 -16 月度净节省约16万元

9. 常见问题

Q1: RRC_INACTIVE和RRC_IDLE的寻呼机制有什么本质区别? A: RRC_IDLE下的CN Paging由AMF发起,通过N2接口发送到TA List内的所有gNB,范围是核心网控制的TA级别。RRC_INACTIVE下的RAN Paging由gNB发起,通过Xn接口发送到RNA内的gNB,范围是RAN侧配置的,可以是TA/RAN Area/Cell级别,粒度更细。关键区别在于:CN Paging需要核心网参与,RAN Paging完全在RAN侧闭环。

Q2: T380应该设置多大? A: 取决于业务模型。对于智能手机用户,建议10-20分钟,确保网络能定期知道UE的大致位置。对于固定IoT设备,可以设置到360分钟甚至720分钟,因为UE几乎不移动,太短的周期只会增加无意义的信令开销。一个常见错误是所有UE使用相同T380值,导致整网在T380到期时出现周期性信令峰值。

Q3: SDT是否会完全替代RNAU流程? A: 不会。SDT解决的是"在RRC_INACTIVE状态下传输少量数据"的问题,RNAU解决的是"通知网络UE的位置变化"的问题。两者正交。即使支持SDT,UE移出RNA后仍需发起RNAU。但SDT可以在RNAU过程中携带小数据,减少一次额外的状态转换。

Q4: 多厂商组网时RRC_INACTIVE有什么特殊风险? A: 最大风险是Xn接口兼容性。RNAU需要原gNB和新gNB之间通过Xn接口传递UE Context(包含安全密钥、DRB配置等)。不同厂商对UE Context的编码和解析可能存在细微差异,导致Resume失败。建议在多厂商环境部署前,进行Xn互操作性测试(IOT),特别关注I-RNTI解析、UE Context编解码和安全上下文同步。

Q5: RRC_INACTIVE如何影响eMBMS/多播接收? A: Release 18扩展了RRC_INACTIVE能力,支持MBS多播接收(TS 38.331 Section 5.3.13.1d)。UE在RRC_INACTIVE状态下可以接收通过PTM方式发送的多播数据,无需恢复到RRC_CONNECTED。这通过MulticastConfigInactive和inactivePTM-Config配置实现。但需要注意,多播MRB的PDCP COUNT在RNA内需要同步,否则UE在小区重选后可能无法正确解密。

10. 参考来源

  1. 3GPP TS 38.331 V18.5.0 — NR RRC协议规范,Section 4.2.1(RRC状态定义)、Section 5.3.8(RRC连接释放/挂起)、Section 5.3.13(RRC连接恢复/RNAU/SDT)
  2. 3GPP TS 23.502 V18.x — 5G系统流程,Section 4.8.2.2(UE触发的Connection Resume)、Section 4.8.2.2a(网络触发的RRC_INACTIVE恢复)
  3. 3GPP TS 38.413 V18.5.0 — NGAP协议,Section 8.3.5(RRC Inactive Transition Report)、Section 8.3.14(RAN Paging Request)
  4. Predictive modeling of RRC inactive transitions - ScienceDirect — RRC_INACTIVE状态转换的机器学习预测模型
  5. Power Saving Techniques in 3GPP 5G New Radio - arXiv — 5G NR节能技术综述,包含DRX/RRC_INACTIVE功耗分析

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