Skip to content

PSM and eDRX: How an IoT Device Sleeps, and Who Decides How Long

By Saeed Baatiah · Published:

Short answer

PSM switches the radio off entirely so nothing can reach the device until it wakes; eDRX keeps it attached but listening only at long intervals. A device asks for a timer and the network grants one, which is why two identical devices on two operators return very different battery lives.

Key takeaways

  • PSM makes the device unreachable; eDRX keeps it reachable but only at long, agreed intervals.
  • The 3GPP TS 24.008 ceiling on the PSM extended timer is 413 days, which is a protocol limit and not a promise.
  • eDRX in Release 13 runs from a minimum of 5.12 seconds to a maximum of 43.69 minutes.
  • GSMA recommends a minimum granted period of 4 hours, so an operator can legitimately refuse a longer request.
  • A sleeping device cannot receive a command, so anything needing remote control cannot sleep deeply.

01Why a radio has to sleep at all

The energy an IoT device spends is dominated not by computing or by sensing but by keeping a radio ready. A modem that stays attached must listen for paging messages on the network's schedule, and that listening never stops even when the device has nothing to say and nobody is calling it. On mains power the cost is invisible. On a cell it is the whole budget. So the standards bodies did not make radios more efficient so much as make them absent: two mechanisms were added in 3GPP Release 13, alongside LTE-M and NB-IoT themselves, that let a device negotiate long periods of not listening. Understanding them is how you tell the difference between a datasheet battery figure and the life you will actually see, because the two mechanisms have very different consequences for whether anyone can reach the device.

02PSM: the device disappears

Power Saving Mode is the deeper of the two. The device tells the network it is going away, the network keeps its registration alive, and the modem then shuts down its receiver completely. Nothing can reach it. It is not merely slow to answer; it is off. When the sleep expires or an internal event wakes it, the device sends its data and does so without repeating a full attach, which is the second saving, the signalling that reattaching would cost is avoided. The extended timer that governs this is capped by 3GPP TS 24.008 at 413 days, a figure worth reading as the protocol's arithmetic limit rather than an achievable target. What matters operationally is simpler: for the entire sleep window, your platform will show the device as last seen at some point in the past, and that is correct behaviour rather than a fault.

03eDRX: the device dozes but stays reachable

Extended Discontinuous Reception is the lighter mechanism, and it keeps a property PSM throws away: reachability. Rather than going dark, the device agrees with the network on a long cycle and wakes briefly at each point in it to check for paging. If a command was queued, it arrives at the next wake rather than never. The GSMA LTE-M deployment guide gives the Release 13 idle-mode range as a minimum of 5.12 seconds and a maximum of 43.69 minutes. That upper figure is the honest headline: a device on the longest eDRX cycle can be up to about three-quarters of an hour behind a command. For a meter that is irrelevant. For a lock, a valve or anything an operator expects to actuate from a dashboard, it is the difference between a working product and a frustrating one.

04The request is not the grant

This is the point most datasheets quietly skip. Both timers are negotiated, not configured. The device asks for a value in its attach or tracking-area-update signalling, and the network answers with the value it is willing to honour, which may be shorter, and may be the operator's default regardless of what you asked. The GSMA guide makes the shape of that negotiation explicit by recommending a minimum granted period of four hours, which tells you two things at once: that operators are expected to grant long sleeps, and that they set the floor. So a bench test proves what the modem requests, never what a live network will allow. Before committing to a battery figure, read the granted timers back from the device on the actual operator you intend to deploy on, and treat any mismatch as a commercial conversation rather than a bug.

05Sleep and coverage fight each other

A second interaction ruins many battery estimates, and it is not in the timer tables at all. These radios extend their reach by repetition: the LTE-M guide caps coverage enhancement at 32 repetitions in CE Mode A and 2,048 in CE Mode B, and Qualcomm publishes the resulting budgets as NB-IoT at 164 dB and eMTC above 155.7 dB, with an Ericsson analysis stating both can reach 164 dB. Every repetition is transmit energy the device spends on one message. So a device in a weak location wakes on schedule, then burns far more per report than the same device at a good signal. The sleep timer sets how often it pays; the coupling loss sets how much each payment costs. Estimating battery life from the timer alone will always flatter a badly sited device.

06What deep sleep costs you as a platform

Choosing a long sleep is choosing a set of behaviours your operations team will have to live with. Remote configuration changes queue until the next wake, so a fleet-wide settings push becomes a campaign measured in cycles rather than minutes. An alert raised inside the sleep window is delivered late by definition, which means the alert design has to survive the delay, a threshold crossing that only matters within seconds cannot be carried by a deep-sleeping device at all. Diagnostics get harder, because a silent device and a sleeping device look identical on a dashboard unless the platform knows the granted timer and can say which it is. None of these are reasons to avoid sleep; they are reasons to write the timer down in the same document as the alert rules, so nobody later reports correct behaviour as an outage.

07Choosing between them, and when to choose neither

The decision follows one question: does anything ever need to reach this device unprompted? If the answer is no, a tank sensor, a meter, a status probe, PSM is the right mechanism, and the longest sleep the operator will grant is the right value. If the answer is yes but a delay of minutes is tolerable, eDRX is the mechanism, and the cycle should be set from the worst acceptable command delay rather than from the battery target. If the answer is yes and the delay must be seconds, neither mechanism applies, and the honest conclusion is that the device wants external power rather than a cleverer sleep. That third case is common and is worth stating plainly, because a great deal of engineering effort is spent trying to make a battery device behave like a powered one.

PSM against eDRX, on the properties that change your operations
PropertyPSMeDRX
Radio during sleepOff entirelyWakes briefly each cycle
Reachable by a commandNoYes, at the next wake
Published limitMax T3412 Extended = 413 daysMin 5.12 s, max 43.69 minutes
Who sets the valueNetwork grants; device requestsNetwork grants; device requests
Fits a tank or meter readingYesYes
Fits a remotely actuated lockNoOnly if minutes of delay are acceptable
Looks like an outage on a dashboardYes, unless the timer is knownLess so, it reappears each cycle

Figures and sources

Questions

What is the difference between PSM and eDRX in one sentence?

PSM turns the receiver off so nothing can reach the device until it wakes on its own, while eDRX keeps it attached and listening at long intervals so a queued command arrives at the next wake. PSM saves more energy; eDRX preserves reachability.

Can I really get 413 days of sleep?

That figure is the ceiling of the extended timer in 3GPP TS 24.008, not an entitlement. Both timers are negotiated: the device requests a value and the network grants one, which may be shorter. The GSMA guide recommends operators grant a minimum of four hours, which tells you the floor is theirs to set.

Why does my device show a long gap since last seen?

If it is in PSM, that is correct behaviour rather than a fault, the radio is off and the platform cannot see it until the sleep expires. The fix is not on the device but on the platform: record the granted timer so a sleeping device is distinguishable from a genuinely silent one.

Does a longer sleep always mean a longer battery life?

Not on its own. The timer sets how often the device transmits; the coverage at its location sets how much each transmission costs. Repetition ceilings of 32 in CE Mode A and 2,048 in CE Mode B exist precisely because a weak signal is paid for in transmit energy, so a badly sited device can undo a long sleep.

Sources

Related insights