3. DRX（非连续接收）机制：用参数配置换取功耗
DRX 这玩意儿，说白了就是让 UE 在没事干的时候睡大觉。我见过不少工程师一上来就猛调发射功率，却忽略了接收通路才是功耗大头。你想想看，UE 大部分时间都在监听 PDCCH，如果一直保持唤醒状态，那电流根本压不下来。
DRX 的核心思想很简单：只在可能收数据的时候醒来，其余时间关闭接收机。但具体怎么睡、睡多久、什么时候醒，全靠三个参数来调配——DRX 周期、On Duration 和 Inactivity Timer。
核心公式：功耗 ≈ 唤醒时间 / 总时间 × 接收电流 + 睡眠时间 / 总时间 × 睡眠电流
你调参数，本质上就是在改这个比值。
3.1 DRX 周期：决定你多久醒一次
DRX 周期就是 UE 两次尝试接收数据之间的时间间隔。周期越长，UE 睡的时间越久，功耗越低，但代价是数据来了你得等下一个周期才能收到。
我个人习惯把 DRX 周期分成两类：
| 类型 | 取值范围 | 典型场景 | 功耗影响 |
|---|---|---|---|
| 短 DRX 周期 | 2～640 ms | VoLTE、实时游戏 | 较高，但延迟低 |
| 长 DRX 周期 | 10～2560 ms | 后台推送、心跳保活 | 较低，但延迟高 |
我在项目中遇到过一个问题：某款智能手表用长 DRX 周期（1280 ms）来省电，结果消息经常延迟 1 秒以上。用户反馈「消息来了手表不震」，后来我们把周期降到 320 ms，延迟可接受，功耗也只多了 8%。
我的经验：如果业务允许 200～500 ms 的延迟，直接用长周期。如果要求 100 ms 以内，老老实实用短周期，别在延迟上赌。
3.2 On Duration：每次醒来听多久
On Duration 是 UE 在每个 DRX 周期开始时保持唤醒的时间窗口。在这段时间里，UE 监听 PDCCH，看看网络有没有给自己调度数据。
这个值设大了，UE 醒着的时间长，功耗高；设小了，可能还没来得及收到调度信息就睡过去了，导致数据重传。
嗯，这里要注意：On Duration 的单位是 PDCCH 子帧数，通常配置为 1～200 个子帧（1 子帧 = 1 ms）。
- On Duration = 1～2 ms：极低功耗，但只适合信道条件好、调度及时的场景。
- On Duration = 5～10 ms：平衡点，我大部分项目都用这个范围。
- On Duration > 20 ms：功耗明显上升，除非信道很差，否则不推荐。
我曾经在一个 NB-IoT 项目里把 On Duration 从 10 ms 降到 3 ms，结果丢包率从 0.5% 飙升到 8%。后来发现是基站侧调度延迟不稳定，3 ms 窗口太短，UE 经常错过调度。最后调到 6 ms，丢包率回到 1% 以下，功耗比原来省了 22%。
避坑指南：On Duration 不是越小越好。我曾经吃过亏——为了省电把值压到 1 ms，结果 UE 频繁进入 DRX 又立刻被唤醒，反而增加了状态切换功耗。这叫「频繁进出损耗」，比一直醒着还费电。
3.3 Inactivity Timer：数据来了别急着睡
Inactivity Timer 是 UE 在收到最后一个数据包后，继续监听 PDCCH 的时间。说白了，就是「再等一会儿，说不定还有数据来」。
这个参数很关键。设短了，数据刚传完 UE 就睡，结果下一个包马上到，又得重新唤醒，延迟和功耗都吃亏。设长了，UE 一直醒着等，功耗白费。
我一般这样配置：
| 业务类型 | 推荐 Inactivity Timer | 理由 |
|---|---|---|
| VoLTE（语音） | 40～80 ms | 语音包间隔 20 ms，留 2～4 个包的时间 |
| 视频流 | 100～200 ms | 视频帧间隔较大，需要更长的等待窗口 |
| TCP 下载 | 50～100 ms | TCP 确认和重传可能密集到达 |
| 后台心跳 | 1～10 ms | 数据稀疏，没必要等 |
我记得有一次做 VoLTE 功耗优化，把 Inactivity Timer 从 80 ms 降到 40 ms，功耗降了 15%，但语音包偶尔出现断续。后来抓 log 发现，网络侧有时会延迟 50 ms 才发下一个包，40 ms 的窗口刚好错过。最后调到 60 ms，问题解决。
关键原则：Inactivity Timer 必须大于业务数据包的最大间隔，否则 UE 会频繁进出 DRX，反而更费电。
3.4 三个参数的联动配置
这三个参数不是孤立的。你调一个，另外两个也得跟着动。我画了一张图，帮你理清它们的关系：
3.5 实战配置策略
说了这么多理论，来点实际的。我总结了一套配置流程，你照着做基本不会翻车：
- 先定业务延迟要求——这是硬约束，不能妥协。
- 根据延迟选 DRX 周期——延迟要求 ÷ 2 作为周期上限。
- 根据信道质量定 On Duration——RSRP 好的用 2～5 ms，差的用 8～10 ms。
- 根据数据包间隔定 Inactivity Timer——取最大间隔 × 1.5 作为初始值。
- 实测调优——跑业务场景，抓 log 看实际唤醒次数和延迟。
我的习惯：先在实验室用信号源模拟不同信道条件，把参数扫一遍，找到 Pareto 最优曲线。然后到外场验证 2～3 个候选配置，选那个「功耗最低但延迟刚好达标」的。
3.6 一个真实案例
去年我做了一个 Cat-M1 定位器的项目，要求电池续航 3 个月，定位上报间隔 30 秒。初始配置是长 DRX 周期 1280 ms、On Duration 10 ms、Inactivity Timer 80 ms，实测功耗 2.5 mA。
我做了三轮调优：
| 轮次 | DRX 周期 | On Duration | Inactivity Timer | 平均电流 | 定位延迟 |
|---|---|---|---|---|---|
| 初始 | 1280 ms | 10 ms | 80 ms | 2.5 mA | 1.3 s |
| 第一轮 | 2560 ms | 8 ms | 40 ms | 1.8 mA | 2.6 s |
| 第二轮 | 2560 ms | 5 ms | 20 ms | 1.4 mA | 2.8 s |
| 最终 | 1280 ms | 5 ms | 20 ms | 1.6 mA | 1.4 s |
最终配置比初始省了 36% 的功耗，延迟只多了 0.1 秒。为什么没选第二轮？因为定位器要求延迟不超过 2 秒，第二轮 2.8 秒超标了。
血的教训：别只看功耗数字。第二轮虽然电流最低，但延迟超标，用户投诉定位不准。功耗优化必须在业务约束内做，否则就是白费功夫。
DRX 参数配置，说白了就是一场「功耗 vs 延迟」的博弈。你手里有三张牌——周期、窗口、定时器——怎么打，取决于你的业务到底能容忍多少延迟。我见过太多人只盯着功耗表，结果产品上市后被骂「反应慢」。记住：省电的前提是不影响用户体验，否则你省下来的那点电，全得花在售后上。