4. eDRX（增强型非连续接收）：eDRX的超长周期原理，Paging Time Window (PTW) 的配置与权衡
各位做物联网模组的朋友，咱们继续聊省电的事。
上一章讲的DRX，周期最长也就2.56秒。对于大部分手机应用，这够用了。但到了NB-IoT、Cat-M这类场景——比如水表、烟感、资产追踪——设备可能几个月才上报一次数据。你让它每2.5秒醒一次听寻呼？那电池根本扛不住。
所以3GPP在R13引入了eDRX。说白了，就是把“睡觉”的时间从秒级拉到分钟级，甚至小时级。
4.1 eDRX的超长周期：从秒到小时的跨越
eDRX的核心思路很简单：让UE在更长的时间内完全不监听寻呼。这个“更长”有多长？
| 参数 | DRX（传统） | eDRX（增强型） |
|---|---|---|
| 最大周期 | 2.56秒 | 10.24秒（LTE） ~2.91小时（NB-IoT） |
| 适用场景 | 手机、实时通信 | IoT、低功耗传感器 |
| 寻呼窗口 | 固定1个子帧 | PTW（可配置多个子帧） |
| 省电增益 | 中等 | 极高（可达10倍以上） |
我刚开始做NB-IoT项目时，看到eDRX周期能配到10485.76秒，差点以为协议写错了。后来一想，水表一天才上报一次，你让它每2秒醒一次，那不是浪费电吗？
eDRX的周期由两个参数决定：
- TEDRX：超长周期，单位是秒或超帧（Hyper SFN）。在LTE里最大10.24秒，在NB-IoT里可以到2.91小时。
- PTW（Paging Time Window）：寻呼时间窗口。UE只在PTW内监听寻呼，其余时间深度睡眠。
关键点：eDRX不是简单的把DRX周期拉长。它引入了“超帧”的概念——1024个无线帧组成一个超帧，eDRX周期以超帧为单位。这样周期才能突破2.56秒的限制。
4.2 Paging Time Window (PTW)：省电与延时的平衡木
PTW是什么？我习惯把它理解成“闹钟窗口”。
设备在eDRX周期内大部分时间都在深度睡眠。但到了约定的时间点，它会醒来，打开一个时间窗口——这就是PTW。在这个窗口内，设备按照传统的DRX周期监听寻呼。窗口结束后，再次进入深度睡眠。
PTW的配置参数有两个：
- PTW长度：取值范围1.28秒到40.96秒（具体取决于频段和配置）。
- PTW起始偏移：决定在eDRX周期内的哪个位置打开窗口。
你想想看，PTW越长，设备醒着的时间越长，收到寻呼的概率越高，但功耗也越大。PTW越短，省电效果越好，但可能错过寻呼，导致下行数据延迟。
我的经验：对于上报间隔超过1小时的设备，PTW配2.56秒通常就够了。但如果你的应用对下行响应有要求（比如远程开锁），PTW建议配到5.12秒以上。我曾经在一个智能门锁项目里，PTW配了1.28秒，结果用户按了开锁键，门锁要等10分钟才有反应——那体验，你懂的。
4.3 eDRX的工作流程：一张图看懂
下面这张图展示了eDRX的完整工作流程。我建议你仔细看看，尤其是PTW内部的结构。
嗯，这里要注意：PTW内部的监听并不是连续的。它内部仍然按照传统的DRX周期来监听寻呼时机（PO）。也就是说，PTW是一个“窗口”，窗口内是“传统DRX行为”，窗口外是“深度睡眠”。
4.4 配置权衡：省电 vs 延迟 vs 可靠性
配置eDRX参数时，我建议你考虑三个维度：
- 省电效果：eDRX周期越长，PTW越短，省电越好。
- 下行延迟：网络侧有下行数据时，必须等到设备的下一个PTW才能发送。周期越长，延迟越大。
- 寻呼可靠性：PTW越长，设备监听的时间越多，丢失寻呼的概率越低。
| 应用场景 | 推荐eDRX周期 | 推荐PTW长度 | 权衡说明 |
|---|---|---|---|
| 智能水表（月报） | ~2.91小时 | 1.28秒 | 极致省电，延迟可接受 |
| 资产追踪（日报） | ~20.48秒 | 2.56秒 | 平衡省电与响应 |
| 智能路灯（远程控制） | ~5.12秒 | 5.12秒 | 低延迟优先 |
| 可穿戴设备（间歇同步） | ~10.24秒 | 2.56秒 | 兼顾省电与用户体验 |
避坑指南：我曾经在一个NB-IoT项目中，把eDRX周期配到了最大值，PTW配了最小值。结果设备确实省电了，但网络侧下发配置更新时，设备要等将近3小时才能收到。那段时间，设备一直用着旧配置，数据上报全乱套了。后来我学乖了——OTA升级或配置更新前，先把eDRX周期临时缩短。
4.5 网络侧配置：核心网与RRC信令
eDRX的配置涉及两个层面：
- 核心网（MME）：通过ATTACH ACCEPT或TAU ACCEPT消息，下发eDRX参数。包括eDRX周期和PTW长度。
- RRC层：在RRC连接释放时，通过RRCConnectionRelease消息携带eDRX配置。
配置参数在协议里定义得很清楚。我摘一段典型的配置示例：
-- 来自3GPP TS 24.301，eDRX参数IE
eDRX-Cycle ::= ENUMERATED {
hf2, -- 2个超帧（约20.48秒）
hf4, -- 4个超帧（约40.96秒）
hf6, -- 6个超帧（约61.44秒）
hf8, -- 8个超帧（约81.92秒）
hf10, -- 10个超帧（约102.4秒）
hf12, -- 12个超帧（约122.88秒）
hf14, -- 14个超帧（约143.36秒）
hf16, -- 16个超帧（约163.84秒）
...
hf1024 -- 1024个超帧（约2.91小时，仅NB-IoT）
}
PTW-Length ::= ENUMERATED {
s128, -- 1.28秒
s256, -- 2.56秒
s512, -- 5.12秒
s1024, -- 10.24秒
s2048, -- 20.48秒
s4096 -- 40.96秒
}实际开发中，我建议你通过AT命令或API来配置这些参数。以常见的NB-IoT模组为例：
// 配置eDRX周期为20.48秒，PTW为2.56秒
AT+CEDRXRDP=1,4,"0101","0010"
// 参数说明：
// 1: 请求eDRX参数
// 4: 请求类型（R13 eDRX）
// "0101": eDRX周期（hf4，约40.96秒）
// "0010": PTW长度（s256，2.56秒）小技巧：调试时，可以用AT+CEDRXRDP?查询当前配置。如果发现设备不进入eDRX，先检查网络是否支持——很多老基站不支持R13特性。我遇到过好几次，模组配了eDRX，但基站根本不认，设备还是按传统DRX跑，功耗一点没降。
4.6 实际项目中的权衡决策
最后，我想分享一个实际案例。
去年做共享单车锁的项目。车锁需要每天上报位置，但用户扫码开锁时要求低延迟（<5秒）。
我们一开始配了eDRX周期20.48秒，PTW 2.56秒。省电效果不错，但用户开锁时，最坏情况要等20秒——这显然不行。
后来我们用了动态eDRX策略：
- 设备空闲时：eDRX周期40.96秒，PTW 1.28秒（极致省电）。
- 用户扫码后：通过APP触发网络侧下发配置更新，临时将eDRX周期缩短到2.56秒。
- 开锁完成后：恢复长周期。
这样既保证了日常省电，又满足了开锁的实时性要求。嗯，说白了，没有银弹——eDRX的配置永远是在省电和延迟之间找平衡。理解你的业务场景，比死磕协议参数更重要。