你有没有想过一个问题：手机待机一整晚，电量可能只掉百分之几；可它明明一直“挂着网”，随时能收到消息和来电。如果手机的接收机真的每时每刻都在监听基站发来的信号，那点电池根本撑不过几个小时。这背后立功的技术，就是 DRX（Discontinuous Reception，非连续接收）——让终端学会“打盹”：该醒的时候准时醒，该睡的时候放心睡。
在“连接态也要省电”与“包随时可能到达”这两难之间，DRX 是整个移动通信体系里最精巧的机制之一。它同时决定了你的手机续航、App 消息的到达时延、甚至 VoLTE 通话的语音包抖动。对一线工程师来说，看不懂 DRX 时序图，很多“玄学问题”——比如 ping 值周期性跳变、寻呼偶发丢失、下载速率起步慢——就永远只能靠重启解决。这篇文章就把 DRX 的设计动机、定时器联动、长短周期切换、与寻呼及 HARQ 的关系，一层层讲透。
手机和基站之间的通信有个根本不对称：上行可以由手机自己决定什么时候发，下行却完全被动——微信消息、来电、推送，可能任何一毫秒从天而降。要保证“随时能收到”，最笨但最可靠的办法是：接收机永远开着，每个可能承载下行调度指令的物理下行控制信道（PDCCH）时刻都去解调一遍。
问题在于，射频接收链路（LNA、混频器、ADC）加上基带的信道估计、译码，是芯片里的“电老虎”。实测中，接收机满负荷工作的功耗可以是深度休眠状态的成百上千倍。而现网统计会告诉你一个扎心的事实：绝大多数手机在绝大多数时间里，根本没有下行数据——用户在口袋里、在锁屏后、在两个消息之间的沉默期。
把基站想象成一栋大楼，下行数据是送快递的，手机是你雇的保安：
这个“协议”之所以成立，依赖一个关键前提：发件方（基站）和收件方（手机）对“什么时候该看”达成了一致。基站绝不会在约定睡觉的时间给这台手机发调度指令——这不是善意，而是同样写进基站调度器里的硬约束。所以 DRX 本质上是一场双向协商的错峰：手机省了自己的电，基站也腾出了调度机会。
某百科对 DRX 的定义一语中的：手机与网络协商好数据传输的时段，其余时间设备关闭接收机进入低功耗状态。这正是“协议级省电”区别于“设备自己偷偷关机”的地方——关机会掉线，打盹不会。
最简单的 DRX 形态是长DRX周期（long DRX cycle）：以固定周期 $T_{DRX}$ 循环，每个周期开头强制监听一小段时间，其余时间休眠。
gantt
title 长DRX周期时序示意（周期=OnDuration+休眠段）
dateFormat X
axisFormat %s
section 醒（监听PDCCH）
OnDuration 激活期 :0, 1
下一周期 OnDuration :10, 1
下下周期 OnDuration :20, 1
section 睡（关闭接收机）
休眠段1 :1, 9
休眠段2 :11, 9
休眠段3 :21, 9
用占空比（duty cycle）可以粗算省电效果：
$$ D = \frac{T_{on}}{T_{DRX}}, \qquad P_{avg} \approx D \cdot P_{active} + (1 - D) \cdot P_{sleep} $$
假设 OnDuration 为 10 ms、DRX 周期 320 ms，占空比只有约 3%。即便把激活期内的峰值功耗算进去，平均功耗也远低于持续接收。这就是“待机一晚只掉几个百分点电”的数学基础。
上面有个明显的漏洞：如果业务是连发 100 个包的下载，按“只醒 10 ms”的规则，手机每个周期都要重新睡去再醒来，包全堵在基站。所以 DRX 设计了动态延长激活期的机制：
只要在激活期内收到一次属于自己的 PDCCH 调度，激活计时器就重置，手机继续保持清醒；直到连续一段时间（无数据）后，才允许入睡。
这就是“赖床”：本来说好只醒 5 分钟，但只要门口一直有快递，保安就一直不睡；快递停了，再等“最后一眼确认”的功夫，才关灯休息。
DRX 的所有行为，都由一组定时器的接力驱动。理解了它们，任何 DRX 时序图都能读懂。
| 定时器/参数 | 谁配置 | 作用 | 类比 |
|---|---|---|---|
drx-onDurationTimer |
基站下发给手机 | 每个DRX周期开头强制清醒的时长 | 保安每整点必须盯门的5分钟 |
drx-InactivityTimer |
基站下发 | 每次收到调度指令后额外保持清醒的时间；每次调度重置 | “再等一会儿，说不定还有件” |
drx-HARQ-RTT-Timer |
每个HARQ进程一份 | 等待对端HARQ反馈的往返时间；超时前手机可以睡 | “快递说要1小时后补发，我先眯着” |
drx-RetransmissionTimer |
每个HARQ进程一份 | HARQ反馈为NACK后，等待重传调度的最长时间 | “补发最晚什么时候到，等到就继续醒” |
drx-ShortCycleTimer + 短周期时长 |
基站下发 | 数据结束后先用短周期“警惕”几轮，再回落长周期 | 送完大件后，接下来几小时每小时多看两眼 |
关键细节：HARQ 相关的定时器是按进程独立运行的。 5G/LTE 的 HARQ 是多进程并行的（停等式流水线），某个进程在等重传，不代表其他进程也醒着。DRX 由此形成“粗醒（周期性 OnDuration）+ 细醒（个别 HARQ 进程的收尾监听）”的两级结构——这是很多人第一次画 DRX 时序图时最容易画错的地方。
flowchart TD
A[休眠中 Sleeping] -->|"到达OnDuration起点<br/>启动onDurationTimer"| B[激活期 Awake<br/>盲解PDCCH]
B -->|"解到自己的调度指令"| C[延长激活<br/>重置InactivityTimer]
C -->|"持续有数据<br/>每次调度都重置"| C
B -->|"整个OnDuration<br/>没有自己的指令"| A
C -->|"InactivityTimer超时"| D{有HARQ进程<br/>在等反馈/重传?}
D -->|"有: 启动HARQ-RTT<br/>与RetransmissionTimer"| E[半休眠<br/>仅监听特定HARQ时刻]
E -->|"收到重传调度"| C
D -->|"无"| F[进入短DRX周期<br/>启动ShortCycleTimer]
F -->|"短周期内再无数据"| G[回落长DRX周期]
F -->|"短周期内又来数据"| C
G --> A
这是 DRX 设计中最能体现“权衡艺术”的部分。
观察真实流量：一次 HTTP 页面加载、一段短视频、一次微信收发，数据往往成簇出现——主包之后紧跟着零星的后续小包（TCP 确认、图片分片、状态上报），间隔几十到几百毫秒；然后进入可能长达几十秒的静默。
如果只有一个长周期（比如 320 ms）：
如果只缩短周期（比如 20 ms）：
DRX 的答案是两档变速箱：
stateDiagram-v2
[*] --> 活跃传输: 收到调度
活跃传输 --> 短DRX: InactivityTimer超时
短DRX --> 短DRX: 短周期内新数据到达\n重新拉长激活期
短DRX --> 长DRX: 连续N个短周期无数据\n(drx-ShortCycleTimer到点)
长DRX --> 活跃传输: OnDuration内收到调度
短DRX --> 活跃传输: OnDuration内收到调度
长DRX --> [*]
drx-ShortCycleTimer 计满），说明余波散尽，回落长DRX周期：用稀疏的心跳换续航。一句话总结：短周期是对“业务还会回头”的押注，长周期是对“业务真的走了”的确认。参数配得好，用户完全感觉不到省电的存在；配得差，要么续航崩、要么卡顿成片。
| 配置取向 | 典型参数感觉 | 收益 | 代价 |
|---|---|---|---|
| 续航优先（物联网/后台） | 长周期大、OnDuration短、InactivityTimer短 | 占空比低至1%以下，省电显著 | 下行时延最差可达一个周期 |
| 时延优先（实时游戏/URLLC） | 短周期为主、InactivityTimer长 | 唤醒等待几乎为零 | 功耗明显上升 |
| 语音（VoLTE/VoNR典型配法） | 周期与语音包节奏对齐（约20ms量级） | 每个语音包恰好在激活期送达 | 占空比中等，续航可控 |
| 通用默认（智能手机） | 长短周期级联+较长InactivityTimer | 兼顾突发业务与静默期 | 需要大量外场调优 |
值得注意的是 5G 的参数空间比 4G 更细：子载波间隔可变导致“时隙”长度不同，同样以时隙为单位配置的定时器，在高频大子载波间隔下会自动变短——这既是灵活性，也是跨频段参数迁移时的坑（后面实战部分会讲）。
很多人把 DRX 理解成“连接态专属”，其实空闲态（及非激活态）的省电同样是 DRX 思想，只是形态变成了寻呼（Paging）机制。
空闲态手机没有专用连接，网络不知道它具体在哪，来电和下行业务只能通过寻呼广播。如果手机为了收寻呼而一直监听，省电就无从谈起。于是系统规定：
经典的教材公式（LTE/NR 通用的寻呼位置推导思路）：
$$ \text{PF 满足：}\quad (SFN + PF_{offset}) \bmod T = \left\lfloor \frac{T}{N} \right\rfloor \times (UE_ID \bmod N) $$
其中 $T$ 是寻呼周期（由网络广播的默认值和手机签约的特定值中取小者），$N$ 是一个周期内的寻呼帧分组数，$UE_ID$ 由用户标识推导。公式不用背，要理解的是它的设计目的：让成千上万的手机把寻呼监听时刻均匀打散在不同帧、不同时刻上——每个寻呼时刻只服务一小群手机，基站的寻呼容量才能摊得开。
sequenceDiagram
participant UE as 空闲态手机
participant gNB as 基站
participant AMF as 核心网(AMF)
Note over UE: 平时深度休眠
loop 每个寻呼周期T
UE->>UE: 在自己的PO醒来解码寻呼控制信道
alt 无寻呼
UE->>UE: 继续睡到下个PO
else 有自己的寻呼
gNB-->>UE: 寻呼消息(含用户标识)
UE->>gNB: 发起服务请求/响应寻呼
AMF-->>gNB: 下发用户面建立指令
Note over UE,gNB: 进入连接态，后续按C-DRX运行
end
end
Note over AMF: 来电/下行数据触发寻呼
| 维度 | 空闲态寻呼DRX | 连接态C-DRX |
|---|---|---|
| 醒来干什么 | 只解码寻呼控制信道 | 解PDCCH找自己的调度 |
| 周期谁定 | 网络广播默认值+核心网签约值，取小 | 基站RRC专信令逐用户配置 |
| 粒度 | 周期长（秒级常见），以帧为单位 | 周期短（毫秒级），以时隙为单位 |
| 测量行为 | 邻区测量极宽松 | 按连接态测量节拍执行 |
理解这层“同源不同态”的关系非常重要：调试寻呼问题时，你看的是周期、时刻打散是否均匀；调试 C-DRX 问题时，你看的是定时器接力是否正常。两套问题在信令里长得完全不一样。
DRX 的框架是 4G 时代定型的，5G 在其上叠加了一组“让睡得更死、醒得更准”的增强。这类特性在某百科对 5G NR 的介绍中也有印证：面向 RedCap 等低功耗设备，标准明确引入了扩展 DRX（eDRX）等增强省电手段，让传感器类设备电池可支撑数年。
传统 C-DRX 有个浪费：每个周期的 OnDuration，手机都必须完整解一遍 PDCCH——哪怕 99% 的周期里根本没有自己的数据。唤醒信号（WUS，Wake-Up Signal）的思路是：在 OnDuration 之前，基站可以先发一个极简的“起床哨”——
WUS 本身只用极低的速率、极小的带宽承载，检测它的功耗远低于解 PDCCH。相当于把“每整点睁眼 5 分钟”优化成“每整点听 1 秒哨声，没哨声翻身再睡”。
| 特性 | 核心思想 | 适合场景 |
|---|---|---|
| WUS 唤醒信号 | 用低成本信号决定是否跳过 OnDuration | 周期性小包+长静默的普通手机 |
| PDCCH 跳过（skipping） | 激活期内连续N个时刻无调度则允许短暂打盹 | 突发间隙的碎片化业务 |
| 跨时隙调度 | 调度指令提前指示后续时隙，减少持续监听 | 上行为主的业务 |
| eDRX（扩展DRX） | 把周期从秒级拉长到分钟级以上 | RedCap、可穿戴、传感器 |
| RRM 测量放松 | 静止/低速时降低邻区测量频率 | 固定态物联网设备 |
这些增强的共同哲学：省电的最高境界不是睡得久，而是“不必醒的次数一次都别醒”。唤醒、监听、测量，每一个动作都要问一句——这次真的有必要吗？
外场测试时如果发现 RTT 曲线呈规律性锯齿（比如大部分 12 ms，每隔一段冒出 300+ ms），第一反应就该查 C-DRX：空闲感业务（小流量保活）的探测包经常落在休眠期，要等下一个 OnDuration 才能被调度，于是时延里叠加了“唤醒等待”。把探测间隔和 DRX 周期对齐观察，锯齿的规律会立刻对上——这是最快定位“时延毛刺是无线问题还是省电机制”的方法。
页面/视频起播慢，不一定是覆盖差。若 InactivityTimer 配得过短，业务突发的首簇数据刚传完手机就睡了，后续图片分片全部撞上短周期甚至长周期的唤醒等待。抓取调度信令时间线，看数据包之间的“无调度空窗”是否恰好等于周期长度，即可确认。
空闲态侧：寻呼周期配得越长越省电，但来电建立时延越大；周期内 PO 数量与容量也要匹配用户数。极端情况下手机处于小区边缘，PO 那一瞬间的覆盖波动就会导致寻呼漏收——表现为“第一次呼叫振铃失败、第二次才通”这类经典投诉。
回看整个机制，DRX 的每一处设计都在回答同一个问题——如何在不破坏“随时可达”承诺的前提下，把一切不必要的开机时间压缩到零：
它没有用到任何高深的数学，靠的全是对业务统计特性的洞察和对状态机的精雕细琢。这恰恰是通信系统设计的普遍方法论：真正的复杂性不在单点算法，而在于让无数个简单机制严丝合缝地互相咬合。下次你的手机在口袋里安静地度过一整晚，不妨想想这个每几百毫秒醒一次、确认无事又睡去的“敬业保安”——那就是 DRX 在替你值守。
Q1: C-DRX 和空闲态寻呼 DRX 有什么区别？ A: 二者思想同源（周期性醒来、其余休眠），但形态不同。C-DRX 用于连接态，周期毫秒级、由基站通过专用信令逐用户配置，醒来解的是 PDCCH 调度；寻呼 DRX 用于空闲/非激活态，周期通常秒级、由广播默认值与核心网签约值取小，醒来只解码寻呼控制信道。调优侧重点也不同：前者盯时延与吞吐，后者盯寻呼容量与来电建立时延。
Q2: 为什么一定要短、长两个 DRX 周期，一个不行吗？ A: 一个周期无法同时满足“业务余波低时延”和“静默期高续航”。真实业务是成簇的：主传输后有几十至几百毫秒的小包余波，然后是长静默。短周期覆盖余波期（密心跳保时延），连续无数据若干轮后回落长周期（疏心跳保续航）。单周期要么牺牲续航、要么牺牲时延，双周期是对流量统计特性的拟合。
Q3: DRX 会不会影响 VoLTE/VoNR 通话质量？ A: 配置得当时不会，反而依赖它。语音是每 20 ms 一个包的高度规律业务，语音场景的 DRX 周期通常与打包节奏对齐，让每个语音包恰好落在激活期。若周期与语音节奏错配，会出现周期性抖动甚至丢包，表现为通话“机械感”或断续——这是语音 MOS 评分下降时值得排查的一项。
Q4: HARQ 重传和 DRX 是什么关系，为什么定时器要按进程分？ A: HARQ 是多进程并行的停等流水线，任一时刻可能只有部分进程在等反馈或重传。若用全局定时器，一个进程等重传就得让整机醒着，太浪费。按进程独立维护 HARQ-RTT 与重传定时器后，手机只需在对应进程的反馈/重传时刻短暂监听，其余时间可睡，实现“可靠性收尾”与“省电”两不误。
Q5: WUS 没听到就继续睡，会不会漏掉数据？ A: 不会。WUS 的发送权在基站：只要基站决定在该 OnDuration 调度这台手机，就一定会发 WUS 把它叫醒；手机没检测到 WUS 才跳过监听。它是对“空转 OnDuration”的优化，而不是绕过调度约定——这正是 DRX 一贯的双向协商原则。
本文由「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 等场景全覆盖。