你的5G手机是怎么做到既随时在线又不会半天就没电的?答案藏在两个你可能听过但没深究过的机制里:RRC状态机和DRX(不连续接收)。它们就像是手机的"睡眠管理大师",精确控制你的手机什么时候醒、什么时候睡、睡多深。今天我们就把这两套机制的底层逻辑彻底拆开。
想象你是一个24小时待命的急诊科医生:
四种模式,功耗从高到低,响应速度从快到慢。5G网络的核心省电策略,就是在合适的时候让手机进入合适的"待命深度"。
4G LTE时代只有两个RRC状态:RRC_IDLE(空闲态)和 RRC_CONNECTED(连接态)。这带来一个尴尬的问题:
手机刷完一条微博后,如果没有新数据,基站要么保持手机在连接态(白白耗电),要么直接踢到空闲态(下次有数据时要走完整套连接建立流程,延迟高、信令多)。
5G NR引入了第三个状态——RRC_INACTIVE(去激活态),完美解决了这个痛点。

图表 1
| 维度 | RRC_IDLE | RRC_INACTIVE | RRC_CONNECTED |
|---|---|---|---|
| CN连接 | 无(CM-IDLE) | 有(CM-CONNECTED) | 有(CM-CONNECTED) |
| RRC连接 | 无 | 挂起(Suspend) | 有 |
| UE上下文 | 不存储 | 存储在UE和gNB | 存储在UE和gNB |
| UE标识 | IMSI/SUPI | I-RNTI | C-RNTI |
| 移动性 | 小区重选 | 小区重选(受RNA约束) | 切换(gNB控制) |
| 位置追踪 | TAC级别(核心网知道你在哪个TA) | RNA级别(RAN知道你在哪个RNA区域) | 小区级别(基站知道你在哪个小区) |
| 监听行为 | 监听CN寻呼 | 监听RAN寻呼+CN寻呼 | 监听PDCCH |
| 功耗 | 最低 | 低(略高于IDLE) | 最高 |
| 恢复延迟 | ~50-100ms(需重新建立完整连接) | ~10-20ms(只需Resume) | 0ms(已连接) |
问题场景:微信消息的典型流量模型是"突发+长时间静默"。一条消息可能只有几百字节,但两条消息之间可能间隔几十秒到几分钟。
RRC_INACTIVE的巧妙之处:
$$ \text{信令开销比} = \frac{\text{RRC Resume信令数}}{\text{RRC Setup + NAS信令数}} \approx \frac{3 \sim 5}{10 \sim 15} \approx 30\% \sim 40\% $$
实测数据显示,RRC_INACTIVE相比IDLE→CONNECTED转换,可减少约60-70%的信令开销,同时恢复延迟降低3-5倍。
RRC状态机解决的是"大尺度"的功耗问题(秒级到分钟级),而DRX解决的是"小尺度"的功耗问题(毫秒级)。两者配合使用,才是5G省电的完整方案。
DRX(Discontinuous Reception,不连续接收)的核心逻辑极其简单:
手机不需要每时每刻都监听基站的控制信道,只需要在约定的时刻醒来检查一下,如果没有自己的数据就继续睡。
这就像你定了闹钟——每天早上8点醒来看一眼手机有没有重要消息,没有就继续睡到8点半再看。
连接态DRX(C-DRX)的配置由一组定时器组成,它们的协同工作决定了手机何时醒、何时睡:

图表 2
| 定时器 | 作用 | 典型值 | 对功耗的影响 |
|---|---|---|---|
| drx-onDurationTimer | 每个DRX周期开始时UE保持活跃的时间 | 1-10ms(1-10个子帧) | 越长越耗电,但减少漏检概率 |
| drx-InactivityTimer | 收到PDCCH后继续保持活跃的时间 | 1-2560ms | 越长越耗电,但减少数据传输中断 |
| drx-RetransmissionTimer | 等待HARQ重传的最长时间 | 0-15个子帧 | 影响重传时延和功耗的平衡 |
| drx-LongCycle | 长DRX周期(主要省电周期) | 10-1024ms | 越长越省电,但增加调度延迟 |
| drx-ShortCycle(可选) | 短DRX周期(数据突发后的过渡) | 2-640ms | 提供省电和响应速度的折中 |
| drxShortCycleTimer | 使用短周期的次数 | 1-16次 | 控制过渡到长周期前的等待时间 |
下面用一个具体的时序图展示C-DRX的工作过程(假设配置:Long Cycle=40ms,OnDuration=4ms,InactivityTimer=8ms):

图表 3
为什么要有两级DRX周期?因为数据流量往往是突发的——来了一个burst,紧接着可能还有几个小包,然后才是长时间静默。
| 阶段 | 行为 | 类比 |
|---|---|---|
| 活跃期 | 持续监听PDCCH | 你正在和人面对面聊天 |
| Short DRX | 短周期醒来(如20ms) | 聊完了但对方可能还会补充,你站在附近等一下 |
| Long DRX | 长周期醒来(如160ms) | 确认对方说完了,你回到座位上每隔一会回来看一眼 |
这种两级过渡避免了"一刀切"——数据刚停就把手机推入深度睡眠,导致后续小包的调度延迟过大。
DRX不是单一机制,而是根据RRC状态有三种不同的工作模式:

图表 4
| DRX类型 | RRC状态 | 监听对象 | 周期配置 | 功耗水平 |
|---|---|---|---|---|
| I-DRX | RRC_IDLE | 寻呼时机(PO)中的PDCCH | 默认寻呼周期(网络广播) | ★☆☆☆☆ |
| Inactive DRX | RRC_INACTIVE | RAN寻呼+CN寻呼 | 可用UE专属参数 | ★★☆☆☆ |
| C-DRX | RRC_CONNECTED | PDCCH控制信道 | RRC专有信令配置 | ★★★★☆(无C-DRX为★★★★★) |
手机在IDLE态时,不知道有没有人来找自己,所以必须定期醒来监听寻呼。但这个"定期"可以很长——默认320ms到1280ms不等。计算公式:
$$ \text{PO位置} = (UE_ID \mod N) \times N_s + i_s $$
其中 $UE_ID$ 由手机的IMSI派生,$N$ 是一个DRX周期内的寻呼帧数,$N_s$ 是每个寻呼帧内的寻呼时机数。这意味着不同的手机在不同的时刻醒来,避免所有手机同时醒来造成寻呼信道拥塞。
与I-DRX类似,但有两个重要区别:
最复杂也最需要精细调优的DRX模式。C-DRX的参数通过RRC Reconfiguration消息中的MAC-MainConfig→drx-Config字段下发。
一个典型的C-DRX配置示例:
drx-Config:
drx-onDurationTimer: ms4 // 每次醒来监听4ms
drx-InactivityTimer: ms8 // 收到调度后继续等8ms
drx-LongCycle: ms160 // 长周期160ms
drx-ShortCycle: ms20 // 短周期20ms(可选)
drxShortCycleTimer: 5 // 短周期用5次后切到长周期
drx-RetransmissionTimer: 0 // HARQ重传定时器
drx-HARQ-RTT-Timer: 8 // HARQ RTT定时器
RNA(RAN Notification Area,RAN通知区域)是RRC_INACTIVE状态特有的概念。它是基站级别的位置管理区域——gNB知道UE在哪个RNA范围内活动,但不知道具体在哪个小区。
| 位置管理 | 粒度 | 由谁管理 |
|---|---|---|
| TA(Tracking Area) | 核心网级别,一组小区 | AMF管理 |
| RNA(RAN Notification Area) | RAN级别,一组小区 | gNB管理 |
| Cell | 单个小区 | gNB精确知道 |

图表 5
RNA的设计哲学是:让大部分小区重选都不触发任何信令。只有当UE走出RNA边界时才需要RNA更新,这大大减少了空口信令。
| RNA大小 | 优点 | 缺点 |
|---|---|---|
| 小(如几个小区) | 寻呼范围精确,寻呼开销小 | RNA更新频繁,信令开销大 |
| 大(如几十个小区) | RNA更新少,信令开销小 | 寻呼范围大,多个小区同时发寻呼 |
| 典型值 | 平衡寻呼和更新开销 | 根据移动模式和业务模型调整 |
现网中,RNA通常配置为一个gNB下属的所有小区或者几个相邻gNB的小区集合,覆盖范围大致对应一个TA List的子集。
除了RRC状态管理和DRX,5G还引入了几种辅助省电技术,它们和DRX协同工作:
在C-DRX的OnDuration到来之前,基站可以发送一个特殊的物理信号——DCP(DCI with CRC scrambled by PS-RNTI),告诉UE"下一帧有没有你的数据"。
实测表明,WUS可以额外节省10-20%的C-DRX活跃期能耗,在DRX周期较长时效果更明显。
5G支持带宽部分(BWP)动态切换。当UE处于低业务量状态时,gNB可以将其从宽BWP(如100MHz)切换到窄BWP(如10MHz)。
$$ P_{\text{baseband}} \propto B_{\text{active}} $$
基带处理功耗与激活带宽成正比。从100MHz切到10MHz,基带功耗可降低约30-50%。
5G网络可以动态通知UE减少MIMO层数——比如从4层降到2层甚至1层。每减少一层,就需要少处理一个数据流,射频和基带都能省电。
| 省电技术 | 适用场景 | 省电效果 | 代价 |
|---|---|---|---|
| C-DRX | 连接态低业务量 | 30-60% | 增加调度延迟 |
| RRC_INACTIVE | 突发小数据(IM/IoT) | 比CONNECTED省60-80% | 恢复延迟10-20ms |
| WUS | C-DRX周期较长时 | 额外省10-20% | 需额外监测WUS |
| BWP切换 | 低吞吐量场景 | 省基带功耗30-50% | 切换有延迟 |
| MIMO层数限制 | 空间复用不必要时 | 省射频功耗 | 降峰值速率 |
场景1:VoLTE/VoNR语音通话
语音包每20ms一个,DRX周期不能大于20ms,否则会丢包。典型配置:
场景2:视频流媒体(YouTube/抖音)
数据量大且持续,但偶尔有缓冲暂停。典型配置:
场景3:即时通讯(微信/WhatsApp)
突发小包,长时间静默。典型配置:
在终端侧log分析中,以下信息是DRX调试的关键:
| 日志关键字 | 含义 |
|---|---|
drx-Config |
RRC下发的DRX配置参数 |
OnDuration start/stop |
OnDuration的开始和结束 |
InactivityTimer start/expire |
非活跃定时器的状态 |
Long DRX cycle start |
进入长DRX周期 |
Short DRX cycle start |
进入短DRX周期 |
RRC Suspend/Resume |
RRC_INACTIVE的挂起和恢复 |
问题1:手机耗电异常快
排查思路: 1. 检查UE是否长时间停留在RRC_CONNECTED(未进入INACTIVE或IDLE) 2. 检查C-DRX是否被配置(有可能被去激活了) 3. 检查DRX周期是否过短(如10ms的周期几乎等于不休眠) 4. 检查InactivityTimer是否过长(导致每次醒来后长时间不睡)
问题2:业务延迟大
排查思路: 1. 检查DRX周期是否过长(如1024ms的周期会导致最差近1秒的延迟) 2. 检查是否因频繁进入RRC_INACTIVE/IDLE导致恢复延迟 3. 检查BWP切换是否引入额外延迟
3GPP Release 18进一步增强了终端省电能力:
| 增强特性 | 说明 |
|---|---|
| 增强型WUS | 更灵活的WUS配置,支持基于搜索空间组的WUS |
| PDCCH监听跳过 | UE可以在特定条件下完全跳过PDCCH监听 |
| RRC_INACTIVE态早期数据传输 | 在RRC Resume的同时传输数据,进一步减少延迟 |
| 终端功耗报告 | UE可以向网络报告自身功耗偏好,辅助网络优化配置 |
| TRX adaptation | UE可以关闭部分收发链路(如从4T4R降到1T1R) |
其中终端功耗偏好上报(UE Power Preference)是一个非常实用的功能——手机可以告诉基站"我电量只剩10%了,请帮我把DRX周期调长、BWP调窄"。这从"网络单方面决定"变成了"UE参与决策"。
Q: RRC_INACTIVE和RRC_IDLE最本质的区别是什么?
A: 核心区别在于CN连接是否保持。RRC_INACTIVE时,核心网(AMF)认为UE仍在CM-CONNECTED状态,NAS信令连接未断开,gNB保留了UE的全部上下文。这意味着恢复到CONNECTED只需要一个RRC Resume过程(约10-20ms),而不需要重新建立NAS连接和认证流程。而RRC_IDLE时,CN侧也断开了,恢复需要完整的初始接入流程(50-100ms+)。
Q: DRX周期设多长最合适?
A: 没有万能最优值,取决于业务模型。核心权衡是省电 vs 延迟。DRX周期越长,UE休眠时间越长,功耗越低,但调度延迟的最大值就等于DRX周期长度。现网常见的做法是根据QoS需求分组配置:语音用短周期(20ms),视频用中等周期(40-80ms),后台数据用长周期(160-320ms)。
Q: C-DRX的Short Cycle是不是一定要配置?
A: 不是,Short Cycle是可选参数。不配置时,UE在InactivityTimer超时后直接进入Long DRX。Short Cycle主要用于数据突发模型明显的场景——数据刚停时用短周期快速响应后续小包,确认真的没数据了再过渡到长周期。对于流量平稳的场景(如视频流),可以不配置Short Cycle。
Q: 为什么不干脆让手机一直在RRC_INACTIVE态?
A: RRC_INACTIVE态也有成本——gNB需要为每个INACTIVE态UE保留上下文,占用存储和计算资源;同时RAN寻呼需要在整个RNA范围内发送,消耗空口资源。如果大量UE长期处于INACTIVE态,gNB的负担会很重。所以网络会设置INACTIVE态的定时器,超时后自动转到IDLE释放资源。
Q: DRX和eDRX有什么区别?
A: eDRX(Extended DRX)是DRX的扩展版本,主要用于IDLE和INACTIVE态,将DRX周期从最大约10.24秒扩展到几十分钟甚至几小时。eDRX主要用于物联网场景(如NB-IoT),终端可能一天只需要醒来一次检查数据。普通智能手机不使用eDRX,因为几百秒甚至几分钟的寻呼延迟对用户体验不可接受。
本文由「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 等场景全覆盖。
