12 Cellular IoT Power Optimization
12.1 Start With the Story
12.1.1 Budget the Whole Wake Cycle
Firmware is the software stored inside a device. A payload is the useful content carried in a message. A protocol is an agreed set of exchange rules.
Picture a field meter that should last for years. It sleeps most of the day, yet one poor network visit can keep the radio awake through retries and erase the saving from many quiet hours.
Trace one full wake cycle. Record sleep current, startup work, search time, connection time, bytes sent, reply wait, retries, and the return to sleep. Repeat the trace with weak coverage, a larger message, a network outage, and a low battery. Keep the urgent safe action local when the network is late.
An average current from a calm bench test cannot prove field life. The result applies only to the tested network, device settings, battery, temperature, and traffic. The deeper sections show the power modes, timers, message choices, and measurements needed to turn this cycle into a defensible energy budget.
Power optimization starts with the current trace, not the marketing claim. Attach, transmit, wait, listen, retry, and sleep all leave marks on the battery budget.
Start simple: draw one reporting cycle and measure each state before changing firmware, PSM, eDRX, payload size, or antenna placement.
The mathematical gist. Five years of 0.7%/year self-discharge leaves 96.5% of a 3000 mAh cell, but retained charge does not prove pulse delivery. A 300 mA attach through 1.50 Ω sags 0.45 V, leaving 3.15 V from a 3.6 V cell. Through 15.0 Ω it requests 4.50 V of sag, so attach fails even while the mAh ledger looks nearly full.
12.2 Learning Objectives
After completing this chapter, you should be able to:
- Explain why cellular IoT battery life is a measured duty-cycle result, not a data-sheet promise.
- Compare PSM, eDRX, connected idle, and powered operation as reachability choices.
- Build a power budget from a current trace across search, registration, transfer, retry, idle, paging, sleep, and host activity.
- Decide how T3412, T3324, eDRX paging, release behavior, and retry policy should map to application service requirements.
- Identify firmware, protocol, antenna, coverage, battery chemistry, and operator behaviors that can break a battery target.
Start with Power Save Mode (PSM): A deep sleep behavior where the device remains registered but is not reachable until it wakes or performs a network update. Then Extended Discontinuous Reception (eDRX): A paging-cycle behavior where the device periodically wakes to listen for downlink messages. Next T3412: Periodic tracking area update timer requested by the device and controlled by the network. After that T3324: Active timer that controls how long the device remains reachable after activity before entering PSM. Continue by Paging Time Window (PTW): The portion of an eDRX cycle when the device listens for paging. Continue by Network-granted timers: The actual values allowed by the network; they may differ from the values the firmware requested. Continue by Release assistance: A device hint, where supported, that can help the network release radio resources sooner after data transfer. Finally Energy per cycle: The measured energy for one complete wake, register or resume, transfer, retry, idle, and sleep sequence.
The radio is not the only battery drain. The device also spends energy on the sensor, microcontroller, power regulators, GNSS or other peripherals, storage, retries, and failed network attempts.
PSM and eDRX help, but they do not rescue a design that wakes too often, has weak coverage, keeps a socket alive unnecessarily, or cannot put the host processor to sleep.
12.3 Prerequisites
Before working through this chapter, review:
- Cellular IoT Overview for cellular architecture, lifecycle risk, and operator validation.
- NB-IoT vs LTE-M Comparison for technology-selection context.
- Cellular IoT Implementations for modem state machines and field diagnostics.
12.4 Power Is a System Budget
Battery life depends on every state in the product, not only the lowest sleep current listed in a module brief.
Search, attach, transfer, retry
Weak coverage and repeated registration attempts can dominate the energy budget even when the nominal sleep state is efficient.
MCU and peripherals
The host processor, sensors, regulators, storage, GNSS, and debug interfaces must sleep as intentionally as the modem.
Timers are negotiated
The firmware can request PSM and eDRX values, but the network can grant different behavior. Always read back what was accepted.
Updates and support
Firmware updates, diagnostics, configuration changes, and emergency commands require reachable windows or explicit maintenance schedules.
Do not choose PSM because it sounds like the lowest-power option. First define the maximum acceptable delay for server-to-device commands. A device that must react quickly cannot spend most of its life unreachable.
12.5 Power Modes at a Glance
The same radio name can behave very differently depending on timers, coverage, firmware, and operator policy.
12.6 Measured Energy Cycle
Build the power model from one complete cycle. A useful cycle includes sleep, wake, network access, payload delivery, downlink window, retry behavior, return to sleep, and host cleanup.
Energy formula
For each measured state:
energy_mAh = current_mA * duration_seconds / 3600
For one day:
daily_mAh = sum(all state energy for each wake cycle) + background_sleep_mAh + self_discharge_allowance
For a fleet decision:
usable_life_days = usable_battery_capacity_mAh / measured_daily_mAh
The formula is simple. The hard part is measuring the right states under realistic coverage, temperature, retry, and firmware conditions.
12.7 PSM Design
PSM is strongest when the service is mostly uplink and delayed downlink is acceptable. The device can request a periodic tracking update timer and an active timer, but the network decides what is granted. Firmware should read back the granted behavior and log it.
Use PSM when the product can tolerate server-to-device delay until the next planned wake or active window. Do not use a long PSM interval for urgent commands, safety alerts, or interactive control.
Common PSM design questions:
Start by What is the longest acceptable command delay? Then How often does the device send normal telemetry? Next Does the device need scheduled maintenance windows for updates? After that What happens if the network grants a shorter or longer timer than requested? Continue by Does the application queue downlink at the cloud until the device wakes? Finally Can the device explain, through logs, why it woke and what timer was granted?
12.8 eDRX Design
eDRX is a compromise for devices that must be reachable more predictably than a PSM-only design but cannot afford continuous listening. The device wakes during paging windows, then returns to lower-power behavior if no downlink is waiting.
Choose the longest paging cycle that still meets the service-level delay requirement. Then test the granted cycle and PTW on the real operator network.
eDRX is often considered when:
Start by Configuration commands must arrive within a bounded but non-instant window. Then The product needs occasional server-initiated actions. Next A maintenance campaign must reach devices without waiting for the next long PSM wake. Finally Vehicle power or larger batteries allow more listening than fixed sensors can afford.
12.9 Protocol and Firmware Effects
Power modes only work if the rest of the firmware cooperates.
Keepalive can block sleep
Short TCP, MQTT, or application keepalive intervals can keep the modem awake or force repeated reconnects. Align keepalive policy with the sleep model.
Bytes are not just payload
Count headers, security handshakes, acknowledgments, retries, diagnostics, and update traffic, not just the sensor reading.
Do not idle accidentally
Where supported, release assistance and correct socket closure can reduce time spent waiting after the useful transfer is done.
Retry budgets matter
Weak coverage, server outages, DNS faults, TLS failures, and SIM rejection must have bounded retry policies.
12.10 Commercial Data-Budget Cross-Check
Power approval should include a commercial traffic check because the same behavior that drains batteries can also break connectivity plans. Record these items beside the current trace:
| Budget item | Records to capture | Failure signal |
|---|---|---|
| Normal report | Payload, headers, acknowledgements, security setup, and reconnect bytes | The spreadsheet counts sensor bytes but not protocol overhead |
| Exceptional traffic | Weak-coverage retries, DNS or server outage loops, SIM rejection, diagnostics, and firmware updates | Rare events consume the monthly allowance or keep the modem awake |
| Plan terms | Allowance, pooling rules, overage, throttling, roaming, suspension, and support API access | The cheapest headline plan lacks controls for a faulty device or campaign |
| Fleet operations | Per-device caps, usage alerts, isolation controls, and update dry-run results | One firmware issue can drain a shared pool or trigger field-service visits |
Treat battery life, data usage, reachable windows, and support cost as one acceptance budget.
12.11 Coverage and Antenna Effects
A weak RF path can erase the savings from careful timers. The device may search longer, use more robust transmission behavior, repeat messages, reconnect frequently, or fail to enter the expected sleep state.
Measure power at representative locations:
- Good coverage bench setup.
- Typical installed location.
- Worst expected indoor, basement, metal enclosure, or remote location.
- Moving route if the device is mobile.
- Server outage and network rejection cases.
A bench trace in strong coverage is a reference, not acceptance evidence. The fleet target depends on installed RF behavior and the retry pattern at the hardest sites.
12.12 Worked Example: Comparing Three Policies
This example uses illustrative measured values to show the method. Replace every number with measurements from the actual device.
Example calculation pattern:
normal_day_mAh =
sleep_state_mAh
+ wake_cycles_per_day * measured_wake_and_send_mAh
+ granted_active_window_mAh
+ expected_retry_mAh
+ host_and_sensor_mAh
+ self_discharge_allowance
maintenance_day_mAh =
normal_day_mAh
+ update_transfer_mAh
+ diagnostic_session_mAh
+ retry_margin_mAhDo not average away rare but expensive events. If a firmware update, weak-signal retry storm, or SIM failure drains a large share of the battery, it belongs in the lifetime model.
12.13 Measurement Setup
Use a measurement setup that can see both tiny sleep current and short active bursts. A single handheld multimeter is usually not enough.
Capture range and rate
Use a power analyzer, source meter, or shunt setup that captures sleep, wake spikes, transmit bursts, and long idle periods.
Align logs to current
Mark firmware states such as modem wake, registration, context activation, payload send, network response, and sleep entry.
Test realistic sites
Repeat traces in final enclosure, target temperature range, expected coverage classes, and common fault cases.
Compare to budget
Approve only when measured daily energy, retry margin, update allowance, and battery derating fit the service life.
12.14 Quick Check: Cellular IoT Power Decisions
12.15 Pilot Checklist
Full cycle current
Capture sleep, wake, search, registration, data transfer, retries, active window, paging, and return to sleep.
Granted network behavior
Record requested and granted PSM, eDRX, active-window, and paging behavior for each operator profile tested.
Sleep discipline
Confirm sockets, keepalives, debug ports, sensors, storage, and host wake locks do not prevent low-power entry.
Worst-site evidence
Repeat the model in representative bad coverage, temperature, enclosure, mobility, and outage scenarios.
12.16 Concept Relationships
12.17 See Also
12.18 Try It Yourself
Common Pitfalls
Sleep current is only one line in the model. Search, registration, retry, active windows, host peripherals, and failed network attempts often decide the real battery life.
A long PSM interval may save energy but delay urgent commands, firmware repair, profile changes, and support actions. Match timer policy to the service contract.
The network may grant different PSM or eDRX behavior than the firmware requested. Log granted values and treat unexpected grants as pilot findings.
MQTT, TCP, TLS sessions, DNS retry loops, and application heartbeats can keep the modem awake or force repeated reconnects. Align protocol behavior with the chosen sleep model.
Power tests in excellent bench coverage can miss search time, repetitions, retries, and failed registration behavior. Validate the battery model in representative installations.
12.19 Battery Life as a Measured Service Contract
Cellular IoT power optimization is not a single modem setting. It is a service contract between the application, host firmware, modem, battery, radio coverage, operator timers, and backend behavior.
A defensible battery claim states what the device must do, how reachable it must be, which low-power state it will use, and which measured current trace proves the claim under normal and bad-site conditions. Inspect Figure 12.1 to keep those requirements connected to the network grant and release decision.
Read Figure 12.1 from the service need to requested sleep or paging behavior, then compare that request with what the network actually grants. Continue through the measured whole-device current trace to the release gate. Power optimization is therefore a release flow, not a modem checkbox: reachability, retries, bad-site behavior, and battery margin must remain inside the same evidence chain.
Read the flow as a guard against optimistic battery estimates. A spreadsheet target is only the first step. The device still has to request a policy, receive granted timers from the network, prove the resulting current trace, and pass a release gate that includes reachability and retry margin.
The installed-RF part of that gate needs a delivered-message energy calculation, not transmit current alone. Use the fast-long-range preset below to separate radio startup, useful airtime, receive/ACK work, and failed attempts. Then compare it with the short reliable case while keeping the payload purpose unchanged.
Record energy per delivered report alongside the granted timers and current trace. A faster bearer can shorten airtime, but higher power and retry exposure can erase that saving at the installed site.
This is why “PSM enabled” is not a complete answer. PSM can be the right policy for a meter that reports on schedule, while eDRX or a shorter active window may be needed for a device that must accept configuration or repair commands within a bounded delay. The gate should reject any claim that cannot show both measured daily energy and measured command delay.
Decision signal: Approve a power policy only when measured energy and command reachability both satisfy the service target with margin for retries, updates, and battery derating.
12.20 Cellular Power Evidence Record
The evidence record should connect each power-saving choice to a measured trace and an operational consequence. That record gives firmware, hardware, RF, backend, and operations teams the same release standard.
Build the record from the product promise outward. Start with reporting interval, maximum command delay, battery-service target, and maintenance expectations. Then connect those requirements to requested timers, granted timers, protocol behavior, host sleep, field retries, and battery derating. The result is a release artifact, not just a lab note, and it should name who can approve or reject rollout when the trace misses target. Keep the raw trace and the decision summary together so later firmware changes can be compared against the same baseline.
| Record field | Use when | Trade-off | Measure |
|---|---|---|---|
| Service contract | Reporting interval, max command delay, update window, service life, and failure response are known. | Every sleep choice is judged against reachability, not just lowest current. | Requirement sheet and backend command-queue behavior. |
| Granted timers | The modem requests PSM, eDRX, active time, or paging behavior from the network. | The operator may grant different values than firmware requested. | Requested and granted T3412, T3324, eDRX cycle, PTW, and RRC release logs. |
| Current trace | The device is tested across normal, weak coverage, outage, retry, and maintenance cases. | Rare events can dominate lifetime even when daily payloads are tiny. | Annotated current capture aligned to firmware and modem state logs. |
| Fleet margin | The pilot must survive temperature, aging, battery pulse limits, and installation variation. | Bench success can fail after enclosure, antenna, or operator changes. | Worst-site trace, battery derating model, and rollout pass/fail rule. |
Use three operational rules:
- Firmware: disable debug loops, unnecessary keepalives, aggressive DNS retry, and sensor polling that prevents the host or modem from sleeping.
- Backend: design downlink, configuration, and firmware update delivery around the chosen reachable window instead of assuming always-on sockets.
- Operations: revalidate the trace after antenna, enclosure, SIM profile, operator, firmware, server endpoint, or reporting-cadence changes.
12.21 Network-Granted Timer Review
PSM and eDRX are negotiated behaviors. Firmware can request timer values, but the network grants the actual behavior the device must live with. A battery model that records only requested values is not a release-quality model.
The largest energy costs often sit outside the payload itself: cell search, attach or resume, authentication, bearer setup, DNS, TLS, retransmissions, coverage repetitions, paging windows, and delayed release from connected states.
Measure those costs as states, not averages. Mark when the host wakes, when the modem searches, when the SIM becomes ready, when registration succeeds, when the payload starts, when the last acknowledgement returns, and when both modem and host enter the intended low-power state. Without those markers, the same daily average can hide completely different failure modes.
Weak coverage is the usual trap. A device with a tiny payload can spend most of its energy repeating access attempts, holding a bearer open, retrying DNS or TLS, or waiting for release. The release model should therefore include normal coverage, weak installed coverage, outage recovery, server failure, and maintenance-update cases before it predicts fleet lifetime.
Also check tail energy after the useful message has finished. A socket left open, an aggressive keepalive, a debug UART, or a sensor rail that stays powered can erase the savings from a good radio timer. The trace should show the return-to-sleep point for the whole board, not only the modem.
12.22 Summary
Start by cellular IoT power optimization is a measured system budget across modem, host, sensor, battery, network, and application behavior. Then pSM is best when delayed downlink is acceptable; eDRX is better when bounded reachability matters. Next requested timers are not enough; firmware must read and log the network-granted behavior. After that battery models should use current traces from normal operation, weak coverage, retries, outages, updates, and maintenance windows. Finally a pilot passes only when measured energy and command reachability both satisfy the service contract.
12.23 Key Takeaway
Cellular power optimization starts with reducing radio wake time. Batch data, use PSM and eDRX where appropriate, avoid unnecessary attach cycles, and validate the power profile with real network conditions.