Chapters

8 NB-IoT Power Saving (PSM/eDRX)

cellular-iot
nb
psm
edrx

A buried water meter may sleep for hours, wake to send a reading, and then become unreachable again. PSM and eDRX trade network reachability for battery life in different ways. The granted timers and observed modem trace—not the requested settings—tell operators when the meter can receive data.

8.1 Read the Timer Gate From Wake to Sleep

This section: Read the Timer Gate From Wake to Sleep — Start with Figure 8.1.

Start with Figure 8.1. Follow the device from active communication into its reachable idle windows, then into power-saving mode. eDRX stretches the interval between paging checks while the device remains registered and periodically reachable. PSM turns the radio off more deeply; the network cannot page the device until it wakes for its own activity.

Figure 8.2 adds the operational decision. Request timer values, capture what the network grants, observe registration and paging behavior, measure current across the full cycle, and compare results with the reachability contract. Feed the measured evidence back into configuration instead of assuming the modem accepted every request.

Imagine a meter that reports every six hours and allows downlink work for two minutes after each report. A command arriving just after that window may wait almost six hours. That can suit a tariff update but not an urgent valve closure. Put urgent local protection in the device or choose a more reachable mode; no cloud retry can wake a modem in PSM.

Energy arithmetic needs the whole cycle. Suppose active transfer draws 120 mA for 20 s, reachable idle averages 8 mA for 100 s, and PSM draws 0.02 mA for the remaining 21,480 s of a six-hour cycle. Charge per cycle is ((120×20+8×100+0.02×21,480)/3,600=1.01 mAh)((120\times20+8\times100+0.02\times21{,}480)/3{,}600=1.01\ \mathrm{mAh}). Four cycles per day use about 4.04 mAh before battery ageing, retransmissions, temperature effects, and regulator losses.

Predict the trace. After an uplink, expect the modem to remain reachable for the granted active interval, then show the eDRX or PSM transition. Send a downlink inside the window and expect delivery. Send another after PSM begins and expect it to wait until the next wake. Compare requested and granted timers in modem or network evidence, and reject any battery estimate built only from requested values.

Networks and modem firmware can grant, round, or reject timers differently. Measure reachability and current with the target operator, radio conditions, firmware, and battery system before making a lifetime promise.

Queue downlinks with an expiry and purpose. A configuration update may wait for the next wake, but an old open-valve command may no longer be valid then. When the meter checks in, the service should deliver only commands whose time and device state still satisfy policy.

Repeat the cycle under weak signal. Extra access attempts and longer radio-on time can dominate charge even when PSM current stays unchanged. Report the distribution of full-cycle use rather than one quiet laboratory trace.

Expose the next expected wake and last granted configuration to support staff. When a command waits, those values distinguish normal PSM delay from a lost meter. Avoid a countdown that assumes the device clock and network timer remain exact after failed attachment attempts.

8.2 Overview: Power Saving Is a Reachability Contract

This section: Overview: Power Saving Is a Reachability Contract — Picture a water meter that reports once each day and then sleeps.

Write When the Device Can Hear You

Picture a water meter that reports once each day and then sleeps. Firmware is the software stored on the meter. The service team may want to send a new setting, but the meter cannot save energy and listen all the time. The product promise must say when a reply can arrive and how long the team may wait.

Write one daily cycle. Name the report event, listen window, requested timer, granted timer, next wake, queued command, age limit, weak-coverage rule, energy budget, maintenance window, and owner.

Test a command just inside and outside the listen window, a changed network grant, a missed report, weak coverage, a retry, a restart, low energy, and a planned update. Measure the whole device current and the real command result. A low sleep current or requested timer is not field proof.

Keep urgent water safety local while the device sleeps. The wider service can wait for a planned contact, but it should not promise an immediate command when the radio is unreachable.

This opening does not choose one timer or power mode. Practitioner builds the reachability and energy gate. Under the Hood examines timer state, network grants, paging windows, retries, phase energy, firmware changes, and the evidence needed at representative sites.

NB-IoT power saving is not a battery-life button. Power Saving Mode (PSM) and extended discontinuous reception (eDRX) decide when a device can be reached after it sends or receives traffic. A useful design starts by writing the product's downlink requirement, then chooses the least reachable mode that still lets operations do the work they actually need.

PSM keeps the device registered from the network's point of view, but the sleeping device is not listening for arbitrary downlink. eDRX keeps a device periodically reachable by waking it for paging opportunities. Both modes are negotiated with the network, so requested timer values are only proposals until the field logs show what was granted.

Write the reachability promise before picking timers. A daily meter may only need a short post-uplink window for queued settings. A leak alarm may need a bounded acknowledgement path but not arbitrary cloud commands. A maintenance campaign may need a temporary window where devices listen more often, followed by proof that they return to the normal low-power policy. Those promises decide whether PSM, eDRX, a scheduled hybrid, or another technology is acceptable.

The approval evidence should include the granted timer values, the whole-board current trace, server receipts, missed-command behavior, and recovery from weak coverage. If any of those are missing, the power mode is still an assumption rather than a release decision. Record the approved timer policy with firmware version and operator profile, because both can change the reachable state later.

Use Figure 8.1 to determine when the network can reach the device after uplink: if PSM and eDRX are both granted, eDRX paging occurs during T3324 active time, and PSM begins when active time expires.

NB-IoT timeline shows progression from uplink to T3324, eDRX paging, and PSM sleep, with evidence on timers, current, and downlink results.
Figure 8.1: NB-IoT power saving timeline showing uplink, active timer, eDRX paging windows, PSM sleep, periodic update, and evidence gates.

Follow one sleep cycle. Check each wake cause. Read Figure 8.1 from active communication into the T3324 active period, when the device can be paged. If both eDRX and PSM are granted, the eDRX paging opportunities occur during that active period; PSM follows when active time expires. PSM then turns the radio off deeply enough that the network cannot page it until the periodic update or next device wake. The approval row ties this timeline to granted timers, a whole-board current trace, and a payload receipt. Those three artifacts make power saving a measurable reachability contract rather than an inference drawn from the modem’s requested configuration.

Use PSM when the device can lead

Fixed meters and simple sensors often fit PSM because the device can wake, report, listen briefly for acknowledgements or queued changes, and then sleep until the next event or periodic update.

Use eDRX when the cloud needs a window

eDRX fits delayed command paths where the operator can wait for paging windows but cannot wait for the next device-originated report.

Reject mode labels without evidence

A rollout gate needs granted timer values, current traces, payload receipts, downlink timing, retry behavior, and recovery evidence from representative sites.

If the service promise says "the cloud can command the device at any time," PSM-only behavior is not the right interpretation. Either change the service promise, use a reachable mode, or schedule explicit maintenance windows.

NB-IoT psm narrated tour

Play silently with captions on provisional storyboard timing; narration audio is pending. Production pacing is not protocol time. Choose Reduced motion for a complete still at each beat.

Play the tour to open the workbench. Pause, replay a beat, or read the full transcript below. Unsupported processes keep the existing frame and provide captions only.

Full transcript — NB-IoT psm (8 beats)

B1 — Sleeping water meter
You are responsible for a buried water meter that sleeps to save its battery. Your service team wants to send a new tariff setting, but an urgent valve closure would need a much faster response. How long can the meter leave a command waiting?

Model caption: A buried meter saves battery by sleeping. A tariff setting may wait; an urgent valve closure cannot.

B2 — Registered but unreachable
A command sent toward the meter is downlink traffic. Power Saving Mode, or PSM, saves energy by putting the radio to sleep, so the network cannot page the device. The meter remains registered with the network, but it is not listening for incoming commands while asleep.

Model caption: Power Saving Mode keeps registration but stops listening for incoming commands.

B3 — eDRX and active time
Extended discontinuous reception, or eDRX, offers a different listening schedule. It stretches the time between paging checks, when the device checks whether the network wants to contact it. If both modes are granted, those paging opportunities happen during the active interval. After that interval expires, PSM begins.

Model caption: Extended discontinuous reception provides periodic paging checks during active time; Power Saving Mode follows when active time ends.

B4 — Six-hour schedule
Give your meter the chapter's example schedule: it reports every six hours, then allows downlink work for two minutes after each report. During that short window, the service can send a setting and expect delivery. The window gives the service a brief chance to reach the meter.

Model caption: Chapter example: report every six hours; allow downlink for two minutes afterward. The asset adds two seconds of transfer before its active timer.

B5 — Missed receive window
Now suppose the command arrives just after the two minutes have ended. The meter has entered PSM, so the command may wait almost six hours for the next wake. A short receive window can therefore leave a long wait for a command that misses it.

Model caption: Chapter example: a command arriving just after the two-minute window may wait almost six hours, until the next wake. Exact arrival timing is not available in the asset.

B6 — Service promise
For the tariff setting, that delay may be acceptable. For an urgent valve closure, it is not. Your service promise has to fit the time the meter can receive commands. Urgent protection can stay in the device, or the design can use a more reachable mode.

Model caption: A tariff update may tolerate the wait. Urgent valve protection needs local action or a more reachable design.

B7 — Retry cannot wake PSM
The misconception is that retrying the command from the cloud will wake the sleeping meter. A retry cannot make the radio listen during PSM. The command still has to wait for the next wake, so sending it again does not remove the almost six hour delay.

Model caption: A cloud retry cannot wake a modem in Power Saving Mode. The command waits until the next wake.

B8 — Choose acceptable wait
Choose how long a command may wait before choosing how long the meter may sleep.

Model caption: Choose how long a command may wait before choosing how long the meter may sleep.

8.3 Practitioner: Build the Gate From Granted Timers and Traces

This section: Practitioner: Build the Gate From Granted Timers and Traces — The practical workflow is a ledger.

The practical workflow is a ledger. Record the requirement, request candidate PSM or eDRX behavior, read the granted values, and test the same run through modem logs, server receipts, and whole-board current measurements. The battery model should use measured phase durations rather than a single sleep-current number.

Do not measure the modem alone. Host processors, sensors, regulators, debug interfaces, flash writes, and retry logic can dominate the budget after the radio appears to be asleep. The proof is a wake-to-sleep trace from the final firmware on representative hardware.

Evidence
Question
Failure mode
Gate record
Modem log
Were PSM, active timer, periodic update, or eDRX values accepted, changed, or refused?
The firmware schedules work from a value the network did not grant.
Attach result, grant indication, mode entry, mode exit, and reject cause when present.
Current trace
Does the whole board enter the intended low-power state after the transaction?
The modem sleeps while the host board continues to burn energy.
Annotated phases for wake, registration or resume, uplink, active window, paging, sleep, and next wake.
Cloud receipt
Do payloads and downlinks match the promised operational window?
Local modem success hides server queueing, acknowledgement, or ownership failures.
Payload identifier, server timestamp, downlink timestamp, retry count, and owner response.
Field repeat
Does the behavior hold in weak coverage and recovery paths?
Search, repetitions, retries, and attach failures erase the sleep-mode savings.
Normal-site, marginal-site, cold-start, failed-payload, and recovery traces.

8.3.1 Approval Sequence

Start by write the maximum acceptable downlink delay in operational language. Then choose PSM, eDRX, or a scheduled hybrid mode from that delay. Next request candidate behavior and record the modem configuration. After that read granted values after attach and update the application schedule from the grant. Continue by capture a whole-board current trace and matching server receipt. Finally repeat in weak coverage and recovery scenarios before pilot approval.

A clean lab trace is a baseline, not a fleet decision. The review should include at least one representative marginal site and one recovery path, because retry time can cost more energy than the intended sleep policy saves.

Hands-on lab · 150 min

NB-IoT Modem Bring-Up

I have explained sleep and reachability; now let's bring up a modem and record the settings it receives.

Open the lab

8.4 Under the Hood: Timers Shape the State Machine

This section: Under the Hood: Timers Shape the State Machine — The underlying state machine has three reviewable boundaries.

The underlying state machine has three reviewable boundaries. After a device-originated transaction, an active timer can keep the device reachable for pending downlink. eDRX can add periodic paging opportunities while reducing continuous listening. PSM can remove paging reachability until the device wakes by application event or periodic update. The exact values and transitions depend on the network grant and the modem implementation, so the state machine must be observed rather than assumed.

The state machine also includes the host application. The host decides when sensors run, when flash is written, when the modem is allowed to wake, how retries are bounded, and when queued commands are safe to apply. A modem may enter PSM correctly while a regulator, debug interface, sensor heater, or retry loop keeps the board above the expected current. Under-the-hood review therefore pairs modem state with board-level measurement.

Use fault cases to test the transitions. Failed attach, refused timer grant, missed acknowledgement, cloud outage, profile error, and weak coverage can all keep the device active longer than the clean trace. The approved timer model should state the retry limit, backoff behavior, event log, and support action for each case. That model is what lets a reviewer distinguish expected delayed reachability from a defect.

Use Figure 8.2 to decide whether measured timer grants, whole-board current, delivery receipts, and weak-coverage repeats justify the proposed power-saving configuration.

The NB-IoT power-saving loop links downlink requirements, requested timers, network grants, full-board current measurement and weak-coverage repeats to an approve-or-reject gate.
Figure 8.2: Evidence loop for NB-IoT power saving from requirements to requested timers, granted timers, measured current, field retries, and rollout decision.

Follow Figure 8.2 from the reachability requirement to the mode request and then the network grant. The request is only intent; the post-attach grant controls when the modem can be reached. The same run must join that log with the whole-board current trace and the server receipt, preventing an attractive sleep interval from hiding host or delivery failures. A representative marginal site then tests retries and recovery before the rollout gate. Feeding those results back into configuration makes approval depend on observed state transitions rather than requested timer values.

8.4.1 Reason About the Energy Budget by Phase

A practical battery model sums measured phases rather than trusting a single nominal state. The model should include registration or resume behavior, uplink and receive time, active timer duration, eDRX paging windows where used, PSM sleep, host overhead, retry allowance, and maintenance windows.

Active timer

The active timer is useful for acknowledgements and queued configuration after an uplink. If it is too long, it can dominate an otherwise quiet daily-report design.

Paging windows

eDRX paging windows make delayed downlink possible, but every paging opportunity has a measurable energy cost and an operational latency consequence.

Recovery paths

Attach failure, poor coverage, application retry, SIM or profile faults, and cloud outage can keep the device active long enough to invalidate the clean model.

Hands-on lab · 45 min · Python 3

Model cellular PSM and eDRX energy versus reachability

I have explained the model; now run the cellular psm edrx budget lab and inspect each calculation.

Open the lab

8.4.2 Worked Review: Scheduled Maintenance

For a meter that reports once per day, normal operation can use PSM after the daily report if commands can wait. A monthly maintenance window can temporarily use eDRX or another more reachable policy for devices in the campaign. The approval record should prove three things: commands arrive during the maintenance window, firmware exits the higher-reachability mode afterward, and the post-window current trace returns to the normal sleep profile.

8.5 Start With the Story

This section: Start With the Story — A battery-powered device spends most of its life doing nothing visible.

A battery-powered device spends most of its life doing nothing visible. PSM and eDRX are the tools that decide whether it sleeps completely, listens occasionally, or stays reachable enough for the job.

Start simple: write the wake-up, listen, send, and sleep story before calculating battery life.

8.6 Summary

This section: Summary — Start by pSM is a good default when the device can initiate useful communication and cloud actions can wait for a device-originated window.

Start by pSM is a good default when the device can initiate useful communication and cloud actions can wait for a device-originated window. Then eDRX provides bounded but delayed reachability; it should be approved only when the paging cost and latency fit the workflow. Next requested timers are not enough. The battery model and application schedule must use network-granted behavior. After that field validation needs modem logs, whole-board current traces, cloud receipts, weak-coverage cases, and recovery paths. Finally maintenance modes need explicit exit conditions so a fleet does not remain more reachable, and less power efficient, after service work ends.

8.7 Key Takeaway

This section: Key Takeaway

NB-IoT PSM and eDRX are reachability contracts. Choose them from the service delay requirement, then prove the granted timers and whole-device current behavior before treating the battery model as rollout evidence.

8.8 See Also

This section: See Also

NB-IoT Fundamentals

NB-IoT Fundamentals - service model, narrowband tradeoffs, and NB-IoT fit evidence.

NB-IoT Architecture

NB-IoT Architecture - device, access network, core, and application boundaries.

NB-IoT vs LTE-M Comparison

NB-IoT vs LTE-M Comparison - when power behavior, mobility, payload, and reachability point to different cellular IoT options.

Cellular IoT Deployment Planning

Cellular IoT Deployment Planning - field gates, rollout records, and operational ownership.

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed