How LPWA Connectivity Affects IoT Battery Life

Battery life gets discussed as if it were purely a hardware and chemistry problem: pick the right cell, manage passivation, get the voltage curve right. All of that matters. But long before a device ever reaches the field, the single biggest lever on how long it survives on one charge is a decision made on the connectivity side: which network technology it runs on, and how well that connection is configured.

IoT Connectivity Is Rarely the Neutral Choice It Looks Like

It's tempting to treat cellular connectivity as a fixed cost, drop in a SIM, and put the real engineering effort into the battery and the hardware. In practice, the choice of network technology and how a device is configured to use it changes power consumption by an order of magnitude, not a small percentage.

LTE-M gives a good balance of power efficiency and data rate, which makes it a fit for applications that need relatively frequent communication, asset tracking, wearables, smart metering, where some responsiveness matters alongside battery life.

NB-IoT goes further in the other direction: ultra-low power consumption and deep indoor and underground penetration, at the cost of lower data rates and higher latency. It's built for devices that transmit small amounts of data infrequently, smart parking sensors, utility meters, environmental monitors, and it's the technology behind most of the multi-year battery lifetimes seen in the field. Depending on usage frequency, signal strength, and how well the power-saving settings are configured, NB-IoT devices commonly run 5 to 10 years on a single battery.

Choosing between them isn't about picking the "more efficient" option in the abstract, it's about matching the technology to how often the device actually needs to talk.

Power-Saving Modes: PSM and eDRX

Both LTE-M and NB-IoT support two power-saving features that do most of the practical work of extending battery life, and the choice between them depends entirely on what the application needs to receive, not just send.

PSM (Power Saving Mode) lets a device drop into a deep sleep state while remaining registered on the network. The device effectively powers down its radio, waking only at scheduled intervals to check for messages or transmit data. It's the deepest sleep available, and the tradeoff is that the device is unreachable, and any downlink message has to wait, until the next scheduled wake-up.

eDRX (Extended Discontinuous Reception) is the lighter-touch option: the device sleeps for extended but shorter periods and wakes on a predictable schedule to check for incoming messages, trading some of PSM's power savings for the ability to still receive commands with moderate latency.

A device that only ever needs to phone home, a soil moisture sensor reporting once a day, belongs on PSM. A device that occasionally needs a command pushed to it, a valve that needs to be told to close, needs eDRX's better reachability, and should be budgeted for the extra power that costs.

What Actually Drains the Battery Between Transmissions

Getting the network technology and sleep mode right solves most of the problem, but a few configuration details determine whether that theoretical battery life is achieved in practice or quietly eaten away:

Payload size and transmission frequency. Every transmission costs energy regardless of how efficient the underlying network is. Aggregating data into fewer, larger transmissions, sending only on meaningful events rather than a fixed schedule, and adjusting sampling rates to conditions (a higher rate only when something's actually changing) all reduce the number of times the radio has to wake up and talk.

Handling network failures gracefully. A device that mishandles a dropped connection can end up in a reboot-and-reconnect loop, which is one of the fastest ways to drain a battery that was supposed to last a decade. Radio policy management and back-off mechanisms that detect this pattern and slow down retry attempts, rather than hammering the network, protect both the device's battery and the network itself. For mobile or multi-market deployments, restricting network scans to the operators and frequency bands the device actually needs also shortens acquisition time, another place energy quietly disappears.

Protocol choice. Lightweight protocols built for constrained devices, MQTT-SN, CoAP, plain UDP where occasional data loss is acceptable, carry far less overhead than HTTP. On a battery-powered device, protocol overhead isn't a footnote, it's transmission time, and transmission time is battery.

Where computation happens. Processing data on the device or a local gateway instead of streaming raw data to the cloud can cut communication energy substantially, provided the added local processing doesn't outweigh the savings. The balance between edge computing and transmission has to be evaluated across the whole power budget, not just the radio bill, since continuous sensing and computation can quietly erase the gains from reduced communication.

Where eSIM and iSIM Change the Equation

Two developments on the connectivity side are changing what's achievable, not just how carefully existing technology is configured.

eSIM and iSIM move the SIM out of a physical, swappable card and into a soldered or embedded chip. Beyond the operational benefit, no truck roll to change a SIM, no separate contract per country, iSIM in particular integrates SIM functionality directly into the device's secure processor, which reduces power consumption and frees up internal space that can go toward a bigger battery, better antenna, or a smaller overall device footprint. For devices designed to run untouched for a decade, that's not a minor detail.

Multi-network SIMs also affect battery life indirectly: a device that has to search repeatedly for a usable signal because it's tied to a single weak operator burns power on failed connection attempts. A SIM that reliably finds the strongest available network the first time reduces that hidden drain, on top of the coverage benefit it's usually chosen for.

IoT Connectivity and Battery Design Have to Be Solved Together

None of this replaces good battery engineering, chemistry selection, cell construction, and voltage matching to the device's actual current profile still determine whether a battery performs as expected under the load a device puts on it. But that battery load is set upstream, by which network technology was chosen, whether PSM or eDRX fits the application, how big the payloads are, how often the device transmits, and how gracefully it handles a bad connection.

Getting the connectivity side right first means the battery is being sized against a realistic power budget instead of an optimistic one. Com4 works with IoT teams on exactly that piece, LTE-M and NB-IoT connectivity engineered for the low-power mindset, PSM and eDRX support, multi-network SIMs across 750+ operators in 190+ countries, and eSIM and iSIM options that reduce power draw at the hardware level, so that the battery a team eventually chooses only has to do its share of the job, not compensate for a connectivity decision made without power in mind.

If battery life is the constraint your next IoT deployment is designed around, it's worth having the connectivity conversation before the battery conversation, not after.