Definition
eDRX (Extended Discontinuous Reception) is a power-saving mode for NB-IoT and LTE, where the terminal sleeps most of the time and only wakes up briefly during set intervals to listen for paging, which can significantly reduce power consumption and extend battery life.
Working Principle
The paging cycle of traditional DRX is relatively short (e.g., 2.56s), requiring the terminal to wake up frequently; eDRX extends the paging cycle to tens of seconds or even minutes (NB-IoT typically 2.56s to 10485.76s), allowing the terminal to stay in sleep mode most of the time during the eDRX cycle and only briefly wake up during the PTW (Paging Time Window) to listen for paging. If paged, it establishes a connection to receive data; otherwise, it continues sleeping. The longer the eDRX cycle, the lower the power consumption, but the higher the downlink paging delay. A balance must be struck based on the service's tolerance for latency and the power endurance requirements.
Combined with PSM
PSM (Power Saving Mode) is a deeper sleep mode where the terminal, after being idle for some time, enters PSM, completely shuts down the RF, only the RTC runs, and it cannot be paged. eDRX is suitable for passive wake-up scenarios that require downlink paging; PSM is suitable for scenarios with purely uplink reporting, without the need for downlink wake-up. The two can be used in combination: after the terminal reports, it enters PSM, then wakes up periodically to enter eDRX to listen for paging, and then returns to PSM or reports data. Under typical NB-IoT configurations, the battery can last for several years.
Application Recommendations
Devices with low-frequency reporting such as smart meters and environmental sensors can enable eDRX and PSM; scenarios requiring real-time downlink delivery (e.g., remote control) should shorten the eDRX cycle or disable eDRX. The platform side needs to support eDRX paging delay, sending during the terminal's wake-up window; or alternatively use SMS or non-paging methods. eDRX parameters are configured via NAS signaling and must match the support available from the operator's network.
Paging window and downlink reachability
Extended discontinuous reception changes how often an idle device listens for paging. It does not change the rate of the application message itself. For most of the cycle the device turns the receiver off, and it turns the radio on only in the paging time window. If nothing pages it inside the window, it goes back to sleep. Only if it is paged does it set up a connection and receive data. A downlink command therefore waits at least one cycle, plus the time to set up the connection. The timeout cannot be written as if the module were always online. The device requests the cycle and the network accepts it. The value the network agreed is the one that counts. If the device locally writes a very long cycle and the network does not support it, the network assigns a shorter one. Current and delay then disagree with the design sheet.
The condition is that the application can tolerate that unreachable interval, and that the network has enabled the feature. A device that only sends, and never receives, can enter a deeper power-save in which it cannot hear paging at all. Extended reception does not solve "wake it whenever you like." If downlink has to be faster, shorten the cycle, or stay connected for a short time after an uplink and put the command on that connection, rather than waiting for the next page. Convert timers in the same units on the network and on the device. Mixing seconds and hyperframes is off by orders of magnitude.
Cycle settings and application delay
A common mistake is for the platform to send at any moment and for the send interface to return success at once. Success only means the platform accepted the message. It does not mean the device has received it. If the message is not queued until the next reachable window, it expires. Another mistake is to treat the paging cycle as the reporting cycle. Reporting is started by the device clock. Paging is started by the network. If the two line up badly, the device is paged just after it has gone to sleep. The power saving disappears, and the page can collide with the uplink.
A tracking-area update, an attach, and security mode temporarily leave this rhythm. If debugging keeps pinging the device, the current you see is the online current, not the average current after deployment. If the SIM or the network does not allow the feature, the device requests it again and again and is refused, and the log looks as if the parameter will not write. After a carrier change, read back the cycle the network actually accepted. Do not keep the configuration from the old card. If an alarm application uses a very long cycle, the field may already have recovered by the time the alarm arrives, and the platform still treats it as an alarm. Put the time the event occurred and the current state in the message. Do not use the arrival time as the time it happened.
Event time and how long a queued message may wait
The moment the platform accepts a downlink message is not the moment the device acts on it. The message has to stay alive until the next paging window. If it expires, return not delivered, not success. An alarm message should carry the time the event occurred and the current state. Arrival time is only a transport record. With a very long cycle, the alarm can reach the platform after the field has already recovered. Looking only at the arrival time sends a maintenance visit that is not needed.
The reporting cycle and the paging cycle are not the same timer. If they happen to stack, the device is paged just after it sleeps, average current stays close to always-on, and it will not match the design sheet. After a carrier or a card is changed, read back the cycle the network actually accepted. The value requested locally is only a wish. Continuous online checks during debugging measure attach current. They cannot be used to estimate battery life. A device that needs no downlink should not keep a dense window just so it can be woken. That cancels the point of the power-save mode.
The cycle the device requests, the cycle the network accepts, and the cycle the platform uses for its queue have to agree before anyone can budget delay. If the parameter is written only on the device, and the platform still times out as if the device were always online, the command is cancelled before the window arrives. If an uplink report is already inside the window, whether a downlink can still be inserted depends on whether the device left receive time. Do not assume the window is empty. An application message has to be shorter than what the window can finish. A long message should be pulled by the device after it wakes. After a base-station or tracking-area change, the first attach may not use the feature for a while. Current in that interval must not be extrapolated to a full-day average. Keep both the requested value and the accepted value in the record, so a complaint about power consumption has something to compare, rather than a single number left in a configuration file.