定义
eDRX（Extended Discontinuous Reception，扩展非连续接收）是 NB-IoT、LTE 的省电模式，终端在大部分时间休眠，仅在设定周期内短暂唤醒监听寻呼，可显著降低功耗，延长电池续航。
工作原理
传统 DRX 的寻呼周期较短（如 2.56s），终端需频繁唤醒；eDRX 将寻呼周期扩展至数十秒甚至数分钟（NB-IoT 典型 2.56s～10485.76s），终端在 eDRX 周期内大部分时间休眠，仅在 PTW（Paging Time Window）窗口内短暂唤醒监听寻呼。若被寻呼则建立连接接收数据；否则继续休眠。eDRX 周期越长，功耗越低，但下行寻呼延迟越大。需根据业务对延迟的容忍度与续航需求权衡。
与 PSM 配合
PSM（Power Saving Mode）是更深度的休眠模式，终端在空闲一段时间后进入 PSM，完全关闭射频，仅 RTC 运行，无法被寻呼。eDRX 适合需要下行寻呼的被动唤醒场景；PSM 适合纯上行上报、无需下行唤醒的场景。两者可组合使用：终端上报后进入 PSM，定时唤醒后进入 eDRX 监听寻呼，再进入 PSM 或上报数据。NB-IoT 典型配置下，电池可支撑数年。
应用建议
智能表计、环境传感器等低频上报设备可启用 eDRX 与 PSM；需实时下发的场景（如远程控制）应缩短 eDRX 周期或禁用 eDRX。平台侧需支持 eDRX 寻呼延迟，在终端唤醒窗口内下发；或采用短信、非寻呼等替代方式。eDRX 参数通过 NAS 信令配置，需与运营商网络支持情况匹配。
寻呼窗口与下行可达
扩展非连续接收改变的是空闲态多久听一次寻呼，不是业务报文本身的速率。终端在周期的大部分时间关闭接收，只在寻呼时间窗里打开射频。窗口内没有寻呼，就继续睡；窗口内被叫到，才建立连接收数据。因此下行命令的等待时间至少是一个周期，再加建立连接的时间，不能按始终在线的模块来写超时。周期由终端请求、网络接受，最终以网络同意的值为准。终端本地写了一个很长的周期，网络若不支持，会配成更短的值，耗电和时延都与设计表不符。
使用条件是业务能容忍这段不可达时间，并且网络侧已经开通该特性。纯上行、没有下行的终端可以再进入更深的省电，此时根本听不到寻呼，扩展接收解决不了“随时叫得醒”。需要较快下行时，应缩短周期或在上报后的一小段时间保持连接，把命令夹在这次连接里，而不是等下一次寻呼。定时器要用网络与终端相同的单位换算，把秒和超帧混用会差出数量级。
周期参数和业务时延
常见错误是平台在任意时刻下发，下发接口立即返回成功，成功只表示平台收下了消息，不表示终端已经收到。消息若没有排队到下一次可达窗口，就会过期。另一错误是把寻呼周期当成上报周期。上报由终端时钟发起，寻呼由网络发起，两者对齐不好时，终端刚睡下就被寻呼叫起，省电收益消失，还可能和上行冲突。
跟踪区更新、附着和安全模式会暂时退出这种节律，调试时若一直 ping，看到的是在线电流，不是部署后的平均电流。SIM 或网络不允许该特性时，终端反复请求又被拒绝，日志里像是参数写不进去。更换运营商后要重新读回网络实际接受的周期，不要沿用旧卡的配置。告警类业务若把周期放得很长，告警到达时现场状态可能已经恢复，平台仍按告警处理。应在报文里带事件发生时间和当前状态，避免用到达时间代替发生时间。
事件时间与排队时限
平台收下下行消息的时刻不是终端执行的时刻。消息必须活到下一次寻呼窗口，过期就应返回未送达，而不是返回成功。告警报文里写事件发生时间和当前状态，到达时间只做传输记录。周期很长时，告警送到平台，现场可能已经恢复，若只看到达时刻会派一次无效检修。
上报周期和寻呼周期不是同一个定时器。两者凑巧叠在一起，终端刚睡就被叫起，平均电流会接近一直在线，和设计表对不上。更换运营商或卡之后读回网络实际接受的周期，本地请求值只是愿望。调试时连续查在线状态，测到的是附着电流，不能用来估算电池寿命。不需要下行的终端不必为了“可唤醒”把窗口留得很密，那会把省电模式的意义抵消掉。
终端请求的周期、网络接受的周期和平台排队使用的周期，三者一致才谈得上时延预算。只在终端侧写参数，平台仍按始终在线去超时，命令会在窗口到来之前被取消。窗口内如果同时有上行上报，下行是否还能插入取决于终端是否留了接收时间，不能假定窗口一定空着。业务报文要短于窗口能完成的传输，长报文应改成终端醒来后主动拉取。更换基站或跟踪区之后，第一轮附着可能暂时不用该特性，这段时间的电流不能外推成全天平均。记录里同时留下请求值和接受值，现场投诉耗电时才有对照，而不是只剩一个配置文件里的数字。