3、DRX参数调优实战：长周期 vs 短周期配置
DRX 参数调优，说白了就是在功耗和时延之间走钢丝。长周期省电但响应慢，短周期响应快但费电。这个平衡点怎么找？我拿一个现网优化案例来拆解。
3.1 长周期 vs 短周期：核心差异
先看一组基本参数对比。DRX 周期由 longDRX-Cycle 和 shortDRX-Cycle 共同决定，再加上 drxShortCycleTimer 控制切换时机。
| 参数 | 典型值 | 功耗影响 | 时延影响 |
|---|---|---|---|
| longDRX-Cycle | 320ms ~ 2560ms | 周期越长，休眠占比越高，省电效果明显 | 唤醒延迟大，首包响应可能等一个完整周期 |
| shortDRX-Cycle | 20ms ~ 80ms | 频繁唤醒，功耗相对较高 | 快速响应，适合突发小包业务 |
| drxShortCycleTimer | 2 ~ 8 个短周期 | 计时器越长，停留在短周期的时间越久 | 业务结束后快速切回长周期，降低功耗 |
嗯，这里要注意：长周期不是越长越好。我见过有人把 longDRX-Cycle 设到 2560ms，结果消息延迟到用户投诉。反过来，短周期设太短，终端电量撑不过半天。
3.2 现网优化案例：某城市 CBD 区域
去年我处理过一个典型场景。某运营商在 CBD 区域部署了 4G 基站，用户反映两个问题：
- 白天办公时段：、邮件等即时消息延迟 3~5 秒
- 夜间空闲时段：终端待机耗电快，一晚上掉电 15% 以上
我拉了一下网管统计，发现 DRX 参数用的是默认配置：
longDRX-Cycle: 1280ms
shortDRX-Cycle: 80ms
drxShortCycleTimer: 4
drx-InactivityTimer: 10ms
onDurationTimer: 6ms问题出在哪？白天业务密集，终端频繁在短周期和长周期之间切换。80ms 的短周期对于即时消息来说还是偏长，用户感知明显。而夜间虽然没业务，但 drxShortCycleTimer 只有 4 个周期，终端很快切回长周期，可长周期 1280ms 的监听窗口太短，导致寻呼漏检后重传，反而增加了无效唤醒。
核心矛盾：白天需要更短的周期降低时延，夜间需要更长的周期但保证寻呼可靠性。一套参数打天下，两头不讨好。
3.3 调优方案：分时段差异化配置
我的做法是引入 时间域差异化 DRX 配置。利用 eNB 的 PRC 重配机制，在一天内按时间段下发不同的 DRX 参数。
白天（08:00 - 20:00）配置：
longDRX-Cycle: 320ms
shortDRX-Cycle: 40ms
drxShortCycleTimer: 6
drx-InactivityTimer: 8ms
onDurationTimer: 4ms夜间（20:00 - 08:00）配置：
longDRX-Cycle: 1280ms
shortDRX-Cycle: 80ms
drxShortCycleTimer: 2
drx-InactivityTimer: 10ms
onDurationTimer: 8ms为什么这么调？白天把长周期压到 320ms，短周期降到 40ms。即时消息的端到端时延从 3~5 秒降到 800ms 以内。夜间把 onDurationTimer 从 6ms 提到 8ms，增加监听窗口长度，减少寻呼漏检。同时 drxShortCycleTimer 降到 2，业务结束后快速进入长周期休眠。
个人经验：分时段配置的关键是切换时机。我建议在业务低谷期前 30 分钟下发重配，避免在业务高峰期触发 RRC 重配流程，反而增加信令开销。
3.4 优化效果与数据对比
部署后一周，我拉了网管统计：
| 指标 | 优化前 | 优化后 | 改善幅度 |
|---|---|---|---|
| 白天平均用户面时延 | 3.2s | 0.7s | ↓ 78% |
| 夜间终端待机功耗 | 15% / 晚 | 6% / 晚 | ↓ 60% |
| 寻呼漏检率 | 2.3% | 0.8% | ↓ 65% |
| RRC 连接重建次数 | 12次/小时 | 3次/小时 | ↓ 75% |
用户投诉量从每天 20 多起降到 2~3 起。效果很明显。
3.5 避坑指南
调优过程中有几个坑，我踩过，你们别踩。
- 短周期不要低于 20ms。我曾经试过 10ms 短周期，终端频繁唤醒，功耗反而比不睡还高。终端芯片的唤醒开销是固定的，周期太短就失去了休眠的意义。
- onDurationTimer 和 drx-InactivityTimer 要联动。这两个参数加起来决定了每个唤醒周期的有效监听时间。我习惯让
onDurationTimer + drx-InactivityTimer不超过短周期的一半，否则终端刚睡下又被叫醒。 - 注意终端能力差异。不同芯片厂商对 DRX 参数的支持粒度不同。高通平台对 40ms 短周期支持良好，但某些国产芯片在 40ms 以下会出现定时器漂移。建议先在实验室验证，再推全网。
我曾经踩过的坑：有一次全网批量修改 DRX 参数，没注意某个基站版本不支持短周期 20ms 以下的配置。结果那个基站下的终端全部无法进入 DRX 状态，功耗飙升。从那以后，我每次改参数都会先检查 eNB 和 UE 的能力集。
3.6 DRX 参数调优决策流程
下面这张图是我自己总结的调优决策流程，每次做 DRX 优化都按这个走，基本不会漏掉关键点。
这个流程的核心思路是：先分析业务模型，再选周期倾向，最后做参数联动检查和终端验证。我每次做 DRX 优化都按这个走，基本不会漏掉关键点。
3.7 小结
DRX 参数调优没有银弹。长周期和短周期的平衡点取决于业务场景、终端能力和用户期望。我的建议是：
- 不要迷信默认参数。现网环境千差万别，默认参数只能保证能用，不能保证最优。
- 分场景、分时段差异化配置。一套参数打天下的时代已经过去了。
- 调优后必须持续监控。业务模型会变，用户行为会变，参数也要跟着迭代。
嗯，这一章就到这里。参数调优是个细致活，多试几次，找到感觉就好了。