13 Cellular IoT Power Optimization
13.1 Start With the Story
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.
Phoebe’s Why
This chapter’s own energy formula – daily_mAh = sum(state energy) + background_sleep_mAh + self_discharge_allowance – quietly bundles three different physical mechanisms into one line. The state-energy sum and the background sleep term are the same physics: current the device itself draws, one episodic and one continuous. Self-discharge is a different mechanism entirely – the cell leaking charge through its own internal chemistry whether or not the device ever wakes up. Keeping the terms separate is not bookkeeping fussiness; it is the only way to catch a failure that charge accounting alone hides. The highest current in the whole cycle is usually not transmit – it is cell search and attach – and a charge ledger that says “the pack is 97% full” says nothing about whether that pack can still deliver the attach pulse without its terminal voltage collapsing.
The Derivation
The chapter’s own per-state formula is a discretized charge integral:
\[Q_{state} = \int I\,dt \approx I_{state}\cdot t_{state}\]
Its daily total keeps three physically distinct sources separate:
\[Q_{day} = \underbrace{\sum_{states} I_i t_i}_{\text{device-drawn, episodic}} \;+\; \underbrace{I_{sleep}\cdot 24\text{h}}_{\text{device-drawn, continuous}} \;+\; \underbrace{\sigma\,C_0\,\Delta t}_{\text{cell self-discharge}}\]
Terminal voltage during the highest-current state, search and attach:
\[V_{load} = V_{oc} - I_{attach}\,R_{int}\]
Worked Numbers: This Chapter’s Own Formula, Filled In
- Self-discharge is the small term: against this chapter’s own five-year vendor claim, a catalog-typical Li-SOCl2 self-discharge rate of 0.7%/year retains \(0.993^5=96.5\%\) of a 3000 mAh pack – a loss of only \(103\) mAh. That is why it is an “allowance,” not the dominant line in the sum.
- Search/attach is the dangerous term: a catalog-typical NB-IoT/LTE-M search-and-attach current peak of 300 mA is far above steady transmit current, and it hits a cell that has been sitting mostly idle. With a hybrid-layer-capacitor-buffered cell (\(R_{int}\approx1.50\,\Omega\) under pulse), sag is \(300\text{ mA}\times1.50\,\Omega=450\) mV, leaving \(3.6-0.45=3.15\) V – survivable. On a bare bobbin Li-SOCl2 cell without that buffering (\(R_{int}\approx15.0\,\Omega\)), the same pulse demands \(300\text{ mA}\times15.0\,\Omega=4.50\) V of sag – more than the 3.6 V the cell has to give. The attach does not slow down; it fails outright, on a pack the mAh ledger would still call nearly full.
- What antenna gain actually fixes, and what it does not: this chapter’s own warning that weak coverage makes “the device search longer” inflates the episodic term (\(I_i t_i\), more seconds at search current) – exactly where better antenna gain and link margin help, by shortening \(t_{search}\). But antenna gain does nothing for \(R_{int}\) or the attach pulse’s peak current, which are cell-chemistry and pack-design properties. A stronger antenna can save mAh; only a better cell or an HLC buffer can save the attach from a brownout.
13.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.
- 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.
- Extended Discontinuous Reception (eDRX): A paging-cycle behavior where the device periodically wakes to listen for downlink messages.
- T3412: Periodic tracking area update timer requested by the device and controlled by the network.
- T3324: Active timer that controls how long the device remains reachable after activity before entering PSM.
- Paging Time Window (PTW): The portion of an eDRX cycle when the device listens for paging.
- Network-granted timers: The actual values allowed by the network; they may differ from the values the firmware requested.
- Release assistance: A device hint, where supported, that can help the network release radio resources sooner after data transfer.
- 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.
13.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.
13.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.
13.5 Power Modes at a Glance
The same radio name can behave very differently depending on timers, coverage, firmware, and operator policy.
13.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.
13.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:
- What is the longest acceptable command delay?
- How often does the device send normal telemetry?
- Does the device need scheduled maintenance windows for updates?
- What happens if the network grants a shorter or longer timer than requested?
- Does the application queue downlink at the cloud until the device wakes?
- Can the device explain, through logs, why it woke and what timer was granted?
13.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:
- Configuration commands must arrive within a bounded but non-instant window.
- The product needs occasional server-initiated actions.
- A maintenance campaign must reach devices without waiting for the next long PSM wake.
- Vehicle power or larger batteries allow more listening than fixed sensors can afford.
13.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.
13.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.
13.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.
13.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.
13.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.
13.14 Quick Check: Cellular IoT Power Decisions
13.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.
13.16 Concept Relationships
13.17 See Also
13.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.
13.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.
Power optimization is a release flow: define the service need, request the sleep or paging behavior, verify what the network grants, measure the full trace, and gate the rollout.
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.
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.
13.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.
13.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.
13.22 Summary
- Cellular IoT power optimization is a measured system budget across modem, host, sensor, battery, network, and application behavior.
- PSM is best when delayed downlink is acceptable; eDRX is better when bounded reachability matters.
- Requested timers are not enough; firmware must read and log the network-granted behavior.
- Battery models should use current traces from normal operation, weak coverage, retries, outages, updates, and maintenance windows.
- A pilot passes only when measured energy and command reachability both satisfy the service contract.
13.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.