2. DRX（非连续接收）基础：周期、窗口与定时器
DRX 这玩意儿，说白了就是让 UE 在没事干的时候睡大觉。你想想看，手机大部分时间都在那等着，要是时时刻刻监听 PDCCH，那电池撑不了多久。我刚开始接触 LTE 协议栈时，觉得 DRX 不就是个开关嘛，后来踩了不少坑才明白——这里面的定时器配合，才是真正的技术活。
2.1 DRX 的核心概念
先理清三个基本概念。它们就像 DRX 的骨架，搞懂了后面都好说。
- DRX 周期：UE 从醒来一次到下一次醒来的总时长。周期越长，省电效果越好，但时延也会变大。
- On Duration：UE 醒来监听 PDCCH 的那段时间。说白了就是「睁着眼睛」的窗口。
- Opportunity for DRX：UE 可以关掉接收机去睡觉的时间段。这段时间里，UE 不需要监听任何下行控制信令。
嗯，这里要注意：Opportunity for DRX 并不是说 UE 一定在睡觉，而是说它可以睡觉。如果还有数据要收，协议栈会通过定时器把 UE 留在唤醒状态。
核心关系：DRX 周期 = On Duration + Opportunity for DRX。这个公式虽然简单，但实际调度时，两个定时器（onDurationTimer 和 drx-InactivityTimer）会动态改变 UE 的清醒时间。
2.2 三个关键定时器详解
DRX 的定时器就像闹钟和计时器的组合。我习惯把它们分成三类：
| 定时器名称 | 启动时机 | 停止条件 | 超时行为 |
|---|---|---|---|
| onDurationTimer | 每个 DRX 周期开始时 | 超时或进入 Active Time | UE 进入 Opportunity for DRX |
| drx-InactivityTimer | 收到新数据调度的 PDCCH 时 | 收到 MAC CE 或超时 | UE 回到短/长 DRX 周期 |
| drx-RetransmissionTimer | HARQ 重传等待时 | 收到重传数据或超时 | UE 停止监听该 HARQ 进程 |
2.2.1 onDurationTimer
这个定时器是 DRX 周期的「起床铃」。每个周期开始，UE 就启动它，然后开始监听 PDCCH。我记得有一次在优化 VoLTE 通话质量时，发现 onDurationTimer 设得太短，导致 UE 经常错过调度——那叫一个头疼。
典型配置值：
- 短周期：2~10 ms
- 长周期：10~200 ms
- VoLTE 场景：建议 6~10 ms，保证语音包不丢
我的经验：onDurationTimer 不是越长越好。设长了确实能提高调度成功率，但 UE 醒着的时间也长了，省电效果打折扣。我一般从 6 ms 开始调，看 PDCCH 漏检率再往上加。
2.2.2 drx-InactivityTimer
这个定时器是「加班计时器」。UE 在 On Duration 期间收到 PDCCH 调度后，就会启动它。只要这个定时器在跑，UE 就一直保持清醒，继续监听 PDCCH。
为什么会这样？你想想看，如果刚收到一个数据包，很可能后面还有更多数据要来。这时候让 UE 直接去睡觉，那下一个包就得等下一个周期了，时延受不了。
我曾经在项目中遇到过一个问题：某个厂商的终端在下载大文件时，drx-InactivityTimer 设了 100 ms，结果每 100 ms 就要重新进入 DRX 再唤醒，反而更费电。后来改成 200 ms，吞吐量上去了，功耗反而降了。
避坑指南：drx-InactivityTimer 不能设得太小。如果小于 TCP 的突发间隔，UE 会在每个突发之间反复唤醒，省电效果适得其反。我建议至少设到 80~100 ms。
2.2.3 drx-RetransmissionTimer
这个定时器专门处理 HARQ 重传。当 UE 发送了数据但没收到 ACK，或者下行数据解码失败时，协议栈会启动这个定时器，让 UE 在重传窗口内保持监听。
嗯，这里有个容易搞混的地方：drx-RetransmissionTimer 和 drx-InactivityTimer 是独立的。即使 drx-InactivityTimer 超时了，只要还有 HARQ 重传在等，UE 也得醒着。
典型配置：
- FDD 模式：8~16 ms
- TDD 模式：根据上下行配比调整，一般 10~20 ms
- 注意：这个值必须大于 HARQ RTT，否则重传还没到 UE 就睡了
2.3 DRX 状态机与定时器配合
光讲概念太抽象，我画了一张图，把 DRX 的完整流程串起来：
2.4 定时器配置实战建议
配置 DRX 定时器，说白了就是在省电和时延之间找平衡。我总结了几条经验：
- 先看业务类型：VoLTE 要求低时延，onDurationTimer 不能太短；网页浏览可以容忍一定时延，周期可以设长些。
- 注意定时器之间的耦合：drx-InactivityTimer 超时后，UE 会回到短 DRX 周期或长 DRX 周期。如果短周期设得太短，UE 可能刚睡下又被叫醒。
- HARQ 重传不能忘：drx-RetransmissionTimer 必须大于 HARQ RTT。我见过有人设了 4 ms，结果重传还没到 UE 就睡了，那叫一个惨。
- 实测验证：理论算得再好，也得拉到现网跑一跑。我习惯用路测工具抓 PDCCH 调度日志，看 UE 的 Active Time 占比，再微调参数。
一个小技巧：如果你不确定怎么配，可以用 3GPP 36.331 里的默认值做起点。默认的 onDurationTimer 是 6 ms，drx-InactivityTimer 是 100 ms，drx-RetransmissionTimer 是 8 ms。大部分场景下，这个组合都不会出大问题。
2.5 常见误区
最后聊几个我踩过的坑：
- 误区一：认为 DRX 周期越长越省电。其实周期太长会导致 UE 频繁进入深睡眠，醒来时同步开销更大，反而费电。
- 误区二：把 drx-InactivityTimer 设成 0。这样 UE 收到一个包就去睡觉，下一个包就得等下一个周期，吞吐量直接腰斩。
- 误区三：忽略短 DRX 周期。长周期省电但时延大，短周期时延小但费电。我建议两个周期都配，让 UE 根据业务动态切换。