概念
eDRX（extended Discontinuous Reception）在传统 DRX 基础上进一步拉长寻呼监测周期，使终端在两次寻呼窗口之间保持低功耗睡眠，仅在 PTW（Paging Time Window）内打开接收机监听寻呼。相比 PSM，eDRX 仍保持周期性可达，适合对下行时延有一定容忍但需要比 PSM 更好可达性的场景，例如偶发指令的市政设施。
参数含义
eDRX 周期长度与 PTW 需与网络协商，可用取值受基站与核心网策略限制。周期越长，平均电流越低，但最坏下行时延接近周期长度。应用需按业务 SLA 选择：若指令允许分钟级延迟，可选长周期；若需数十秒内响应，应缩短周期或辅以其他唤醒手段。
与 PSM 的组合
实际部署中，终端可先使用 eDRX 保持较低频可达，再在长时间无业务时进入 PSM。协议栈与模组 AT 指令需支持组合配置顺序。平台侧应在文档中明确“最坏下行延迟 = f(eDRX 周期, PSM 窗口, 网络队列)”，避免运营误解。
调试要点
用电流分析仪观察周期性尖峰应对齐寻呼窗口；若尖峰过多或周期不符，检查 NAS 配置是否与网络一致。弱网下频繁寻呼失败可能触发重搜网，反而耗电，需在射频侧保证最小可用覆盖。
与核心网、平台的配合
从网络视角看，eDRX 拉长了终端可被寻呼的时间粒度，核心网与短信中心若仍按“实时下发”设计缓存与重试策略，可能在业务层表现为“指令已发出但设备迟迟才执行”。物联网平台应在下发接口文档中明确：在 eDRX 或 PSM 开启时，下行可达性取决于协商周期与 PTW，不宜用互联网 API 的“毫秒级”预期去衡量。若业务需要近似实时，可评估改用常在线连接、缩短周期或增加短信唤醒预算。终端侧日志中建议记录每次从休眠到收到首条下行消息的时延，用于与运营商协商参数时的数据支撑。量产阶段还应在不同运营商 SIM 卡上交叉验证，因同一模组在不同 PLMN 上可用的 eDRX 参数集合可能不同。
寻呼时间窗外面的下行会排队
eDRX的技术含义，是在普通非连续接收之外，把两次监听寻呼的间隔拉得更长。终端大部分时间保持低功耗，只在寻呼时间窗里打开接收机。它没有进入完全不可达的深度睡眠，所以仍能在一个周期量级内被找到。使用条件是：网络同意终端申请的周期和窗口长度，业务能接受接近该周期的最坏下行时延，平台不会把“接口已返回”理解成“设备已经执行”。核心网若只允许较短的取值，终端侧写再长也不会生效。
窗口太窄，终端醒来的时间对不齐，寻呼会被错过，等于周期白设。窗口太宽，省电收益被吃掉。应用要按“周期加上附着和业务处理”来写操作说明，而不是按实验室里一次碰巧很快的下行来写。
各运营商开放的周期并不一样
同一模组、同一固件，换一张卡，可用周期集合可能变化。只在一家网络上验证，量产到另一家就会发现命令过夜才到。平台的重试若仍按实时接口去催，只会在设备还没醒时堆积重复命令。设备醒来后应按命令标识去重，执行一次。
需要近似实时时，应缩短周期、保持连接，或接受额外的唤醒成本，而不是在长周期上叠加更频繁的应用重试。和空闲态普通周期的差别见DRX周期权衡。表计阀控若套用这套长周期，要在AMI里把关阀时限写成周期的函数，避免欠费后仍以为阀门已经动作。
同一命令在窗口内只执行一次
平台在一个长周期里多次下发同一指令，设备醒来后会连续看到好几份副本。命令要带标识，终端在寻呼窗口内先合并再动作。关阀、复位和参数写入尤其不能按到达次数执行。没有标识的下行，应在文档里标明“可能重复”，并让设备侧的动作本身可以重复执行而不改变结果。