Automation Glossary • PSM and eDRX

What Are Cellular PSM and eDRX?

Merobix Engineering • • 7 min read

A cellular radio that stays awake to listen for the network is a battery's worst enemy, and for a device that only needs to report once an hour that constant listening is almost entirely wasted. PSM and eDRX are the two mechanisms that fix this, letting a modem sleep deeply between reports instead of paging the network continuously. This guide explains what Power Saving Mode and extended DRX do, how they slash a device's power draw, the reachability trade-off they introduce, and why a device's reporting schedule has to be designed around its wake windows.

Back to Blog

PSM and eDRX in one line: PSM (Power Saving Mode) and eDRX (extended Discontinuous Reception) are cellular power-saving features that let a device power down or sleep its radio for long stretches between communications instead of listening to the network continuously. PSM lets a device go dormant for hours while staying registered, and eDRX stretches the interval between the moments a device wakes to check for incoming pages, both cutting power dramatically at the cost of the device being unreachable while it sleeps.

Two Ways to Let a Modem Sleep

A normal cellular device listens for the network at short, regular intervals so it can receive an incoming call or message almost immediately. That readiness costs power, and for a battery telemetry device that only sends a reading occasionally, it is power spent for nothing. PSM and eDRX are two standardized ways to trade that instant reachability for much longer sleep, and they work at different depths. eDRX extends the gap between the brief moments a device wakes to listen for a page, so instead of checking every fraction of a second it might check every few seconds, minutes, or longer. The device is still reachable, just with more delay before it notices something waiting for it.

PSM goes deeper. In Power Saving Mode a device tells the network it is going dormant, then shuts its radio down almost entirely for a long period - potentially hours - while remaining registered on the network so it does not have to re-attach from scratch when it wakes. During that dormant stretch the device is effectively off the air: it is not listening at all, so nothing can reach it until it decides to wake up, typically to send its next scheduled report. When it does wake, it stays reachable for a short window before dropping back to sleep.

The two mechanisms are complementary rather than competing, and many devices use them together. eDRX is the lighter touch, keeping a device reachable but with relaxed timing, suited to a device that needs to receive downlink commands with only modest delay. PSM is the heavy sleep, suited to a device whose job is essentially to wake, report, and disappear again for hours. Choosing between and combining them is how a designer dials in exactly how deeply a given device sleeps.

Slashing Power at the Cost of Reachability

The power savings from these modes are large because the radio is by far the most power-hungry part of a small telemetry device, and keeping it awake to listen is the biggest continuous drain. By collapsing the time the radio spends listening - stretching it with eDRX or shutting it off with PSM - a device can cut its average current draw enormously, which is the difference between a battery lasting weeks and lasting years. For a sensor that reports a few times a day, most of the day is now spent in a deep low-power sleep rather than in wasteful listening, and the battery budget follows directly from that.

The unavoidable trade-off is reachability. While a device is in PSM sleep it cannot be reached at all - a command sent to it from the SCADA host simply waits until the device next wakes on its own schedule. With eDRX the device is reachable, but only at its widened listening intervals, so a downlink message may sit queued for up to the length of the eDRX cycle before the device notices it. In both cases the network buffers pending downlink traffic and delivers it when the device becomes available, but the host cannot count on immediate two-way contact. The device talks on its own clock.

This is a fundamental shift from the always-on mental model. An operator used to being able to poll a site any time has to accept, with sleepy devices, that outbound contact happens on the device's terms. That is perfectly acceptable for monitoring workloads, where the device reports and the host consumes, but it has to be understood and designed for. A control command that must reach a deeply-sleeping device is not instant; it is queued until the device wakes, and the design has to make that latency tolerable or keep controllable devices in a lighter sleep.

Aligning Reporting Intervals With the Wake Schedule in SCADA

Because a sleepy device is only reachable when it wakes, the whole telemetry design has to be organized around its wake schedule rather than around the host's convenience. The device's reporting interval and its sleep timers must be set together and consistently: if a device is meant to report every fifteen minutes, its sleep must be tuned so it wakes on that cadence, connects, sends its data, checks for anything the host has queued for it, and then goes back to sleep. Mismatched settings - a sleep longer than the intended reporting interval, or a host expecting data more often than the device wakes to send it - produce gaps and confusion.

Downlink timing needs the same discipline. Any command or configuration change the host wants to deliver has to be staged so it is waiting for the device at its next wake window, because that is the only time the device will collect it. A well-designed system queues downlink at the host, and the device pulls it during the brief reachable window after each report before returning to sleep. Get this right and remote configuration still works on a battery site; get it wrong and commands appear to be ignored simply because the device was asleep when they were sent.

For a cloud SCADA platform such as Merobix taking data from battery-powered cellular RTUs across remote oil and gas and other field sites, understanding these sleep modes is what keeps expectations honest. The platform is built to receive reports when a sleeping device pushes them and to hold any queued commands until the device is next reachable, rather than assuming a site is always online. Presenting a device's expected wake cadence, flagging when a report is overdue against that cadence rather than against a constant-connection assumption, and queuing rather than firing-and-forgetting downlink are all part of making deep-sleep telemetry work reliably. The reward is field units that run for years on a battery while still delivering trustworthy, gap-aware data.

Frequently Asked Questions

What is the difference between PSM and eDRX?

eDRX extends the interval between the brief moments a device wakes to listen for network pages, so it stays reachable but with more delay before it notices incoming traffic. PSM is a deeper sleep in which the device shuts its radio down for a long period, often hours, while staying registered, and is unreachable until it wakes on its own schedule. eDRX keeps a device reachable with relaxed timing; PSM lets it disappear almost entirely between reports.

How much power do PSM and eDRX actually save?

A great deal, because the radio is the most power-hungry part of a small telemetry device and keeping it awake to listen is the biggest continuous drain. By stretching or eliminating that listening time, these modes cut a device's average current draw enough to turn a battery life of weeks into years for a device that reports a few times a day. The exact saving depends on how deeply the device sleeps and how often it wakes to report.

Can I send a command to a device that is in PSM sleep?

Not immediately. While a device is in PSM sleep it is unreachable, so a command is queued by the network or the host and delivered only when the device next wakes on its own schedule. The right approach is to stage downlink commands so they are waiting for the device at its next wake window, and to design the system to tolerate that latency. If instant control is required, the device should be kept in a lighter sleep such as eDRX instead.

From Definitions to a Live Dashboard

Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.

Request a Free Demo +1 (903) 307-7300
More in Automation Glossary
Spreading factor  •  LoRaWAN duty cycle  •  Iridium SBD  •  LEO vs GEO satellite  •  Telemetry data plan  •  UDP vs TCP telemetry  •  All Automation Glossary →
Free SCADA operator training
Merobix University - 70 video lessons & 261 quiz questions, from first login to compliance reporting. No demo call required.
Start free →