2.3GPP R12 eDRX 机制详解
各位好，我是老周。今天咱们聊聊 eDRX，也就是增强型非连续接收。这个特性是 3GPP R12 引入的，说白了就是为了让 LTE 模组在待机时更省电。我最早接触 eDRX 是在做一款智能水表项目的时候，客户要求电池撑 5 年，光靠传统 DRX 根本做不到。嗯，那会儿我就知道，eDRX 这东西必须得啃透。
2.1 eDRX 的引入背景
传统 DRX 的寻呼周期最长也就 2.56 秒。你想想看，模组每 2.56 秒就得醒来一次听网络有没有找它。对于手机来说这没问题，但对于一年才上报一次数据的抄表终端，这简直是灾难。
我算过一笔账：一个 NB-IoT 模组在空闲态电流约 3mA，如果按 2.56 秒周期醒来，平均电流大概在 15μA 左右。一年下来，电池消耗接近 130mAh。对于 2000mAh 的电池，撑不过 15 年。但客户要的是 10 年？不，他们要 15 年。
所以 3GPP 在 R12 里做了两件事：
- 把寻呼周期从秒级拉长到分钟级，甚至小时级
- 引入 PTW（寻呼时间窗口），让模组在窗口内按传统 DRX 工作，窗口外彻底休眠
说白了，eDRX 就是让模组「睡得更沉，醒得更少」。我在项目中见过不少工程师把 eDRX 和 PSM 搞混，其实区别很明显：PSM 是彻底关机，连寻呼都不听；eDRX 是还保留寻呼能力，只是间隔拉长了。
核心要点：eDRX 不是让模组一直睡，而是让它在大部分时间深度睡眠，只在预设的时间窗口内醒来监听寻呼。这个窗口就是 PTW。
2.2 寻呼周期与 eDRX 周期的关系
这里有个容易绕晕的地方。eDRX 周期和传统 DRX 周期是嵌套关系，不是替代关系。我画了张图，你看一眼就明白了。
从图上你能看到：
- eDRX 周期（T_eDRX）：模组两次醒来监听寻呼的间隔，单位是秒到分钟
- PTW 窗口：模组真正醒来监听寻呼的时间段，长度固定
- 传统 DRX 周期：在 PTW 窗口内，模组按传统 DRX 周期（如 1.28 秒）监听寻呼
我习惯把 eDRX 比作「闹钟模式」：你设了个 1 小时的闹钟（T_eDRX），闹钟响后你有 5 分钟时间（PTW）检查有没有人找你，这 5 分钟内你每 10 秒看一次手机（传统 DRX）。5 分钟一过，继续睡。
个人经验：我在调试时发现，很多工程师把 T_eDRX 设得特别大，比如 40 分钟，但 PTW 设得很短，比如 1 秒。结果模组经常收不到寻呼。为什么？因为网络侧发送寻呼的时间窗口和模组的 PTW 没对齐。我建议 PTW 至少包含 4 个传统 DRX 周期，留足余量。
2.3 eDRX 参数配置
eDRX 的核心参数就两个：T_eDRX 和 PTW。但这两个参数背后牵扯的东西不少。我整理了一张表，方便你对照。
| 参数 | 3GPP 定义 | 取值范围 | 典型值 |
|---|---|---|---|
| T_eDRX | eDRX 周期，模组两次 PTW 窗口的间隔 | 5.12s ~ 2621.44s（约 43 分钟） | 20.48s / 40.96s / 81.92s |
| PTW | 寻呼时间窗口，模组在窗口内监听寻呼 | 1.28s ~ 40.96s | 2.56s / 5.12s / 10.24s |
| 传统 DRX 周期 | PTW 窗口内的寻呼监听间隔 | 0.32s / 0.64s / 1.28s / 2.56s | 1.28s |
2.3.1 T_eDRX 配置
T_eDRX 决定了模组的休眠深度。值越大，省电效果越好，但寻呼延迟也越大。我举个例子：
- T_eDRX = 20.48s：平均电流约 8μA，寻呼延迟约 10 秒
- T_eDRX = 81.92s：平均电流约 3μA，寻呼延迟约 40 秒
- T_eDRX = 2621.44s：平均电流约 0.5μA，寻呼延迟约 20 分钟
注意，T_eDRX 不是随便设的。3GPP 规定它必须是 1.28 秒的整数倍，而且不能小于传统 DRX 周期。我在项目中遇到过有人把 T_eDRX 设成 5 秒，结果模组根本不进入 eDRX 模式——因为网络侧不支持这么短的周期。
避坑指南：我曾经在一个项目中，把 T_eDRX 设成 2621.44 秒（约 43 分钟），结果模组经常掉线。排查后发现，网络侧的寻呼超时时间只有 30 分钟。模组 43 分钟才醒来一次，网络早就认为它失联了。所以 T_eDRX 不能超过网络侧的寻呼超时时间，这个值通常由运营商配置。
2.3.2 PTW 配置
PTW 是模组真正干活的时间窗口。窗口越长，模组收到寻呼的概率越高，但功耗也越大。PTW 的配置有个经验公式：
PTW 长度 = 传统 DRX 周期 × (PTW 系数 + 1)
其中 PTW 系数取值范围：0 ~ 15
例如：传统 DRX 周期 = 1.28s，PTW 系数 = 3
则 PTW 长度 = 1.28 × (3 + 1) = 5.12s我建议 PTW 至少包含 2~4 个传统 DRX 周期。为什么？因为网络侧发送寻呼的时间点不一定和模组的 PTW 起始点对齐。多留几个周期，能提高寻呼成功率。
另外，PTW 不能超过 T_eDRX 的一半。你想想看，如果 PTW 占了 T_eDRX 的大半，那 eDRX 还有什么意义？
2.4 参数配置实战建议
说了这么多理论，咱们来点实际的。我根据项目经验，总结了三种典型场景的参数配置：
| 应用场景 | T_eDRX | PTW | 传统 DRX 周期 | 平均电流 |
|---|---|---|---|---|
| 智能水表（每日上报） | 40.96s | 2.56s | 1.28s | ~5μA |
| 资产追踪（每小时上报） | 163.84s | 5.12s | 1.28s | ~2μA |
| 环境监测（每日上报） | 655.36s | 10.24s | 2.56s | ~0.8μA |
注意，这些值是理论估算。实际功耗还受射频环境、信号强度、网络负载等因素影响。我习惯在实验室先跑 24 小时，用电流分析仪抓实际曲线，再微调参数。
调试技巧：我建议先用 AT 指令查询模组当前的 eDRX 状态。以 Quectel 模组为例：
AT+CEDRXRDP
返回示例：
+CEDRXRDP: 1,1,"0101","0100"
其中：
第一个参数：eDRX 使能状态（1=使能）
第二个参数：请求类型
第三个参数：T_eDRX 值（编码后）
第四个参数：PTW 值（编码后）拿到返回值后，对照 3GPP 36.331 的编码表解码，就能确认模组是否按预期配置工作。
2.5 常见问题与排查思路
最后，我列几个我在项目中踩过的坑，你遇到了可以直接对照排查：
- 模组不进入 eDRX 模式：检查网络侧是否支持 eDRX。有些运营商只在特定频段或特定 PLMN 下开放 eDRX 功能。
- 寻呼丢失率高：PTW 太短，或者 T_eDRX 和网络侧的寻呼窗口没对齐。我建议 PTW 至少 5.12s。
- 功耗比预期高：检查是否有周期性 TAU（跟踪区更新）打断了 eDRX 睡眠。TAU 周期必须大于 T_eDRX，否则模组会频繁醒来做 TAU。
- 模组频繁掉线：T_eDRX 超过了网络侧的隐式去附着定时器。这个定时器通常由运营商配置，范围在 30 分钟到 2 小时之间。
嗯，关于 eDRX 的核心机制，今天就聊到这儿。参数配置这块，我建议你拿到模组后先做一组对比测试，用电流分析仪抓出实际曲线，再根据业务需求微调。毕竟，理论算得再漂亮，不如实测数据来得实在。