一台 5G 手机最怕的不是信号弱，而是"屏息太久被基站忘记"。DRX（不连续接收）就是终端和基站之间一套精密的"呼吸协议"——什么时候吸气（醒来监听）、什么时候呼气（休眠省电），都有严格到时隙级的约定。本文从一条被反复追问的调试问题出发，把 DRX 的呼吸节律彻底拆开。
网优收到一个投诉：用户反馈"明明没打电话、没刷视频，手机一晚上还是掉了 15% 的电"。抓取 UE 侧 log 后发现，终端几乎全程"醒着"在监听 PDCCH——也就是说，C-DRX 根本没生效。
这就是 DRX 的核心价值场景。终端如果按照"基站随时可能调度我"的假设，时刻打开射频接收机去解调 PDCCH，那么即便没有任何数据要传，基带芯片也要持续工作，功耗会居高不下。对于一部每天大部分时间都"挂在线上却不传数据"的手机来说，这是灾难性的续航黑洞。
DRX 的设计哲学只有一句话：既然绝大多数时刻基站并不会真的给我发数据，那我就和基站约定好"点名时间"，没轮到我点名时，我就把射频关掉睡觉。
这种"间歇性醒来"的机制，本质上和老师上课点名是一个道理：
DRX 就是把这套"点名制"用信令固化下来的省电机制。
很多人一上来就把 DRX 等同于"省电"，其实 5G 里 DRX 分成两套完全不同的体系，分别服务两种场景。搞混这两套是新手最常见的第一大坑。
| 维度 | 空闲态/去激活态 DRX | 连接态 DRX（C-DRX） |
|---|---|---|
| 适用 RRC 状态 | RRC_IDLE、RRC_INACTIVE | RRC_CONNECTED |
| 监听对象 | PDCCH 上的寻呼（Paging） | PDCCH 上的调度授权（DCI） |
| 周期来源 | 寻呼周期 defaultPagingCycle | 网络配置的 Short/Long DRX Cycle |
| 谁配置 | SIB1 广播 + NAS 协商 | RRC 专用信令（drx-Config） |
| 典型周期 | 320ms ~ 1024ms | 10ms ~ 几百ms |
| 核心矛盾 | 越长越省电，但来电延迟越大 | 越长越省电，但首包调度延迟越大 |
flowchart TD
A[RRC_IDLE] -->|驻留camping| B{空闲态DRX<br/>周期监听寻呼}
B -->|收到寻呼| C[随机接入→建链]
C --> D[RRC_CONNECTED]
D -->|有数据传输| E[持续监听PDCCH]
D -->|无数据| F{连接态DRX<br/>C-DRX周期监听DCI}
F -->|收到授权| E
E -->|长时间无数据| F
D -->|RRC Release| A
D -->|RRC Release with suspend| G[RRC_INACTIVE]
G -->|RNA更新/寻呼| D
G -.->|空闲态DRX机制| B
这张图揭示了 5G 三态与 DRX 的对应关系。注意一个关键点：RRC_INACTIVE 是 5G 新增的"折中态"，它保留了 UE 的 RRC 上下文（包括 AS 安全上下文、承载配置），所以从 INACTIVE 恢复到 CONNECTED 比 IDLE 快得多。而 INACTIVE 态的 UE 同样按寻呼 DRX 规律醒来监听——只不过它监听的是 RAN 级寻呼（RNA 寻呼），而不是核心网级寻呼。
为什么 5G 要新增 INACTIVE 态？ 因为 IoT 设备和频繁小数据业务（比如即时消息的心跳包）如果每次都 IDLE↔CONNECTED 完整切换，信令开销太大、时延太高。INACTIVE 态配合寻呼 DRX，让设备既能省电又能快速被唤醒，这是 5G 面向海量物联场景的关键设计。
C-DRX 是工程师调试时打交道最多的部分。它的"呼吸曲线"由几个定时器精确刻画。先看核心原理示意图：
gantt
title C-DRX 呼吸节律（短周期→长周期过渡）
dateFormat X
axisFormat %s
section 活跃期
On Duration 监听PDCCH :0, 5
收到新数据延长 :5, 11
section 短周期
On Duration :20, 5
On Duration :40, 5
section 长周期
On Duration :80, 5
On Duration :160, 5
理解这条曲线，需要记住下面这组核心参数。它们都由基站在 RRC 重配置消息里下发给 UE：
| 参数 | 作用 | 直觉理解 |
|---|---|---|
| drx-onDurationTimer | 每个周期开始时 UE 必须醒着监听的时长 | "点名时至少要抬头 X 毫秒" |
| drx-inactivityTimer | 收到一个新调度（PDCCH 指示新传）后，继续醒着的时长 | "一旦有人找你，多守 X 毫秒看看还有没有事" |
| drx-HARQ-RTT-Timer | 每个 HARQ 进程从发送到等待重传的最小时长 | "问一句要等对方想一想的回环时间" |
| drx-RetransmissionTimer | 等待重传授权期间 UE 保持醒着的最大时长 | "对方说没听清，我睁着眼等他重说" |
| drx-ShortCycle | 短周期长度 | "最近有活动，频繁醒一下" |
| drx-LongCycle | 长周期长度 | "安静了，可以睡久一点" |
| drx-StartOffset | 周期起始位置的子帧/时隙偏移 | "全班错峰点名，避免一起醒来抢资源" |
为什么需要 On Duration 和 Inactivity 两个独立的定时器？ 这体现了一种"两级激进"的省电策略。On Duration 保证每个周期开始你都在岗，防止错过开头的调度；而 Inactivity Timer 是一个"一旦有业务就延后睡觉"的延长机制。设想如果只有 On Duration，那么数据一来一去，UE 还没传完就被迫进入下一个睡眠期，业务体验会很差。Inactivity Timer 让"有活的 UE"持续在线，"没活的 UE"尽快入睡，这是体验与功耗的精巧平衡。
C-DRX 最精妙的设计是两级周期自动切换。逻辑是这样的：
flowchart TD
A[On Duration<br/>开始监听] --> B{收到新传PDCCH?}
B -->|是| C[启动/重启<br/>inactivityTimer]
B -->|否| D{onDuration结束?}
C --> E{inactivity<br/>到期?}
E -->|否,又有新数据| C
E -->|是| F[进入短DRX周期]
D -->|是| F
F --> G{短周期次数<br/>耗尽?}
G -->|否| A
G -->|是| H[进入长DRX周期<br/>更深更久睡眠]
H --> A
为什么要有短周期这个中间态？因为业务往往有"突发后的拖尾"——一个网页加载完，可能马上还有图片请求；一次微信消息后，可能紧接着有第二条。短周期相当于"半梦半醒"，保持较高频次的监听以便快速响应后续业务；如果短周期里一直没动静，说明真的进入了空闲，再切到长周期"深度睡眠"。这是一种对业务自相关性的智能利用。
"UE 是否处于 DRX 激活期（Active Time）"的判定，在 MAC 层规范里有明确的布尔逻辑：
$$ \text{ActiveTime} = \text{onDurationTimer 运行中} \;\lor\; \text{inactivityTimer 运行中} \;\lor\; \text{retransmissionTimer 运行中} $$
或者对于任意 HARQ 进程 $i$，若其 $\text{HARQ-RTT-Timer}$ 未运行且有挂起的重传，也算激活。只有在非激活期，UE 才被允许关闭射频接收机——记住这个判定，调试 C-DRX 是否生效就是看这条布尔表达式在实际 log 里的取值。
很多人以为 UE 一进入睡眠就完全失联，其实不是。DRX 和 HARQ 的关系非常紧密，体现了"睡觉时也留着一只耳朵听重传"的巧思。
工作机理是这样的：当一个 HARQ 进程发送了数据但没收到 ACK，UE 启动 $\text{drx-HARQ-RTT-Timer}$（典型值约 8 个时隙，即一个 HARQ 回环时间）。在这段时间内 UE 可以安心睡觉——因为基站即使要重传，也得先处理完这个 RTT。等 RTT Timer 到期，UE 启动 $\text{drx-RetransmissionTimer}$，这时它必须重新醒来，监听这个 HARQ 进程的重传授权。
为什么要拆成两个定时器？因为 HARQ 回环时间是物理上确定的（信号来回传播 + 处理时延），在 RTT 之前基站根本不可能发重传，UE 没必要白白耗电等着；而 RTT 之后才是重传的"危险窗口"，必须保持清醒。这种设计把"必须醒着的时间"压缩到了理论最小值，是极致省电的体现。
连接态 DRX 是"有连接才省电"，而空闲态 DRX 才是终端绝大多数时间的省电主力。当手机锁屏放在桌上，它就处于 RRC_IDLE，按照寻呼周期醒来监听有没有人找它。
这里有一个让无数新人困惑的计算：UE 怎么知道该在哪个无线帧、哪个时隙醒来听寻呼？ 这就是 PF（Paging Frame，寻呼帧）和 PO（Paging Occasion，寻呼时机）的计算。
核心公式（来自 TS 38.304）：
$$ \text{SFN} \bmod T = (T \div N) \times (\text{UE_ID} \bmod N) $$
$$ i_s = \lfloor \text{UE_ID} \div N \rfloor \bmod N_s $$
其中：
min(UE 专属周期, SIB1 广播的 defaultPagingCycle)；这套公式背后的设计意图是"负载分散"。 想象一个基站下有上万个用户，如果大家都用同一个 DRX 周期、在同一时刻醒来听寻呼，那这个时刻的 PDCCH 会瞬间过载、拥塞。所以公式用 $\text{UE_ID}$ 做哈希，把不同用户均匀打散到不同的帧和不同的 PO 上。这就是为什么 $\text{nB}$ 可以设成 $T/32$——它本质是在说"把寻呼负载切分成 32 份，分摊到不同时间片"。
sequenceDiagram
participant UE
participant gNB
Note over UE: RRC_IDLE, 按 DRX 周期睡眠
UE->>UE: 计算 PF = (T/N)*(UE_ID mod N)
UE->>UE: 计算 PO = floor(UE_ID/N) mod Ns
Note over UE: 关闭射频, 深度睡眠
Note over gNB: 下行来话, AMF 触发寻呼
gNB->>gNB: 在对应 PF/PO 发送 Paging PDCCH
Note over UE: 到达自己的 PF, 醒来
UE->>gNB: 监听 PDCCH (PO)
gNB->>UE: DCI 指示 Paging 消息位置
UE->>UE: 解码 Paging, 发现是自己的 ID
UE->>gNB: 随机接入, 建立连接
注意一个易错点：PO 不是直接发寻呼消息的地方，而是发"寻呼调度 DCI"的时机。 UE 在 PO 监听 PDCCH，看到 DCI 里指示寻呼的 RNTI（P-RNTI），再去 PDSCH 上解码真正的 Paging 消息。这又是一次"先看信封再看信"的协议惯例。
回到连接态 DRX，还有一个被低估的参数：$\text{drx-StartOffset}$。它决定了每个 UE 的 DRX 周期从哪个子帧/时隙开始。
为什么基站要给不同 UE 配不同的 StartOffset？还是那个核心矛盾——避免唤醒风暴。如果一个小区下几百个 UE 全配成长周期 160ms、且 StartOffset 都一样，那么每隔 160ms，这几百个 UE 会同时醒来、同时去抢 PDCCH、同时做 CSI 测量，瞬时负载尖峰会冲击基站的调度器和射频前端。
错峰 StartOffset 把大家的"点名时刻"在时间轴上铺开，让基站的处理能力在每个时隙都能被平滑利用。这和空口上的"频率分集"、调度上的"频选调度"是同一哲学的时域版本：好的系统设计，永远在追求负载的均匀分布。
这是实战中最容易出问题的地方。当 UE 发生切换（无论 Xn 切换还是 N2 切换），目标 gNB 会重新下发 DRX 配置。很多掉电问题就出在切换前后的 DRX 参数衔接上。
典型陷阱有三个：
DRX 定时器在切换时如何处理？ 规范规定，切换后 UE 应用目标小区的 DRX 配置，所有 DRX 定时器会被重置。如果目标 gNB 配的 On Duration 很长、inactivityTimer 很大，UE 可能切换后长时间"醒着"——这就是为什么有些用户在高铁上（频繁切换）反而更费电。
短周期还是长周期？ 切换后 UE 通常从长周期重新开始（因为没有业务上下文继承），但如果马上有业务，又要经历一次短→长周期过渡，带来额外的首包延迟。
C-DRX 与测量 GAP 的冲突。 UE 在 On Duration 醒来监听 PDCCH 的同时，如果还配置了周期性测量 GAP（去异频/异系统测量），两者可能时间冲突。规范要求 GAP 优先级更高，但会导致 On Duration 被"打孔"，影响调度。网优在配置高铁/边缘场景时，需要仔细核算 GAP 周期与 DRX 周期的公倍数关系。
5G 在 DRX 基础上又叠了两层省电增强，值得了解。
eDRX（扩展 DRX）：把寻呼周期拉长到远超 1024ms，IoT 场景可达几十分钟甚至几小时。代价是来电/下行消息延迟极大，但对 NB-IoT 的水表、传感器这类"一天才被叫一次"的设备，这是用延迟换电量的划算买卖。
WUS（Wake-Up Signal，唤醒信号）/ DCP（DCI with CRC scrambled by PS-RNTI）：这是更聪明的省电。传统 DRX 里，UE 每个 On Duration 都得醒来解 PDCCH 看有没有调度——绝大多数时候是白醒一场。WUS 的思路是：基站在 On Duration 之前发一个超轻量的"是否需要醒来"指示（用 PS-RNTI 加扰的一个 DCI），UE 只需花极少功耗检测这个比特：
检测 WUS 的功耗远低于完整解 PDCCH，所以对"大部分周期都没事"的 UE，WUS 能再省一大笔电。这本质上是用一个"更便宜的预筛机制"替代"昂贵的全程监听"。
工程师拿到 UE 侧 log 或基站侧信令，可以从这几个层面验证 DRX：
看 RRC 配置：RRC Reconfiguration 里有没有 drx-Config，是 setup 还是 release。如果一直是 release，说明 C-DRX 根本没开。
看 MAC 层 Active Time 标记：商用 UE log（如 QXDM、XCAL）会逐子帧标注 UE 是否处于 Active Time。统计一段时间内 Active Time 的占比，就是"清醒率"。一个健康的后台待机 UE，清醒率应该是个位数百分比。
核对参数合理性：On Duration 太长（如 10ms 以上）会让每次醒来的固定开销变大；inactivityTimer 太长（如 200ms+）会让 UE 在小数据后久久不睡。常见经验值是 On Duration 2~5ms、inactivityTimer 30~80ms、短周期 20~40ms、长周期 80~160ms。
关联业务模型：即时通讯类应用的心跳间隔若短于长 DRX 周期，会反复打断睡眠，导致"配了 DRX 却省不到电"。这类场景要么调长 inactivityTimer、要么协调应用心跳。
Q1: DRX 和 DTX 是一回事吗？ A: 不是。DRX（不连续接收）管的是 UE "接收"侧的省电——什么时候关接收机；DTX（不连续发送）管的是"发送"侧——什么时候不发 SRS、不传 PUCCH。5G 里 DTX 通常和 DRX 配合使用，因为既然 UE 不监听 PDCCH（睡了），自然也不需要持续发上行参考信号，两者节律往往对齐。但概念上要分开，避免混淆。
Q2: 为什么我抓 log 看到 UE 频繁醒来，DRX 像没生效？ A: 最常见两个原因：一是应用层有高频心跳（微信、推送、定位上报）持续触发 inactivityTimer 重启，UE 根本进不了长周期睡眠；二是 inactivityTimer 配得过大，每次小数据后 UE 守很久。排查方法是先看是哪个 DCI 触发的 inactivityTimer 重启，再回到应用层去优化心跳或改用 NAS 信令的低频保活。
Q3: 寻呼 DRX 周期是越长越省电吗？有什么代价？ A: 对终端续航确实越长越省电，但有三个代价：来电延迟增大（被叫方要等到自己 PO 才能收到寻呼）；网络侧寻呼容量受限（周期越长，单位时间能承载的寻呼越少）；用户体验下降（被叫接通慢）。所以 defaultPagingCycle 是运营商在"终端省电 vs 接通性能 vs 网络容量"三者间的权衡，常见 320ms~640ms，IoT 才用 eDRX 拉到很长。
Q4: 切换后 UE 会丢失 DRX 的"睡眠进度"吗？ A: 会。切换到目标小区后，UE 应用目标 gNB 下发的新 DRX 配置，所有定时器重置，通常从长周期的起始时刻重新开始。这意味着刚切换完如果立即有业务，要重新走一遍 On Duration 和短→长周期过渡，可能带来首包延迟。这也是频繁切换场景（高铁、密集城区）需要特别优化 DRX 参数的原因。
Q5: WUS 唤醒信号是所有手机都能用吗？ A: 需要 UE 和网络双支持。UE 侧要在能力上报里声明支持，网络侧要通过 RRC 配置 PS-RNTI 和 WUS 相关参数。目前主要在中高端 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 等场景全覆盖。