LoRaWAN Battery Life: How Long It Really Lasts and Why

LoRaWANProtocolLoRaWANOpen long-range, low-power LPWANView profile battery life is quoted as ten years on most datasheets, yet many sensors die after three, and the gap is almost always in the radio settings.

The ten-year figure is not a lie. It is a calculation made under specific conditions: a message every so often, a short payload, a strong signal, and mild temperatures. Change any of those and the result changes, sometimes by a factor of five. The problem is that nobody tells the integrator which assumption broke until the first batteries die in the field, usually all at once and usually in the hardest places to reach.

This guide explains where the energy in a LoRaWAN sensor goes, which settings matter most, and how to estimate battery life for your own deployment instead of trusting the brochure. It includes a worked example with the same sensor in two positions, and a checklist of settings that drain batteries without anyone noticing. It assumes you know the basics of how LoRaWAN works.

LoRaWAN Battery Life: Where the Ten Years Come From

Every battery life figure on a datasheet hides an energy budget. When you see "up to 10 years", look for the footnote. It will usually say something like: one uplink every hour, a payload of about ten bytes, spreading factor 7 or 8, 25 °C.

That last pair of conditions is the important one. Spreading factor 7 means the sensor is close to a gateway with a strong signal, so each transmission is short. In a real deployment, part of the fleet will always be far from a gateway, behind a wall, or inside a metal cabinet. Those devices transmit at higher spreading factors, and each of their messages can take more than 20 times longer than the datasheet's.

So the honest way to read a battery figure is as a best case for a well-covered device. Your job is to work out what happens to the devices that are not well covered, because those are the ones that will generate truck rolls.

The calculation itself is not complicated. It needs four numbers: how much current the device draws in each state, how long it spends in each state per message, how many messages it sends per day, and how much usable capacity the battery really has.

Where the Energy Goes: Sleep, Radio, and Sensor

A LoRaWAN Class A sensor spends almost all of its life asleep. It wakes up, measures, transmits, listens briefly for a reply, and goes back to sleep. Each of those phases costs energy.

Two conclusions follow from the table.

First, sleep current matters more than it looks. Five microamps is tiny, but it runs 24 hours a day for years. In a device that transmits every 15 minutes at a good spreading factor, sleep can be the largest single item in the budget.

Second, transmission dominates as soon as the signal gets weak. Transmit current is high, and transmission time grows quickly with spreading factor. A device that drifts from SF7 to SF12 multiplies its transmission energy by more than 20.

The sensor matters too. A temperature probe reads in milliseconds. An ultrasonic level sensor, a gas sensor that needs to heat up, or a probe that must stabilize for a few seconds can cost more than the radio. Check the warm-up time in the sensor's own datasheet, not the radio module's.

Spreading Factor: The Setting That Changes Everything

LoRa trades speed for range through the spreading factor (SF). Each step from SF7 to SF12 roughly doubles the time a message spends on air. The receiver can decode weaker signals, which is why distant devices use high spreading factors, but the transmitter pays for every extra millisecond.

For a typical payload of about 11 bytes on a 125 kHz channel, the airtime looks like this. You can check any combination with The Things Network airtime calculator.

In most networks the spreading factor is not fixed by hand. The network server manages it with adaptive data rate (ADR): it watches the signal quality of recent uplinks and tells each device to use the lowest spreading factor and transmit power that still get through. For static sensors, ADR is one of the most effective battery savers available.

ADR has limits. It needs a stable signal to work well, so it is usually disabled or restricted on moving devices. And it can only lower the spreading factor as far as the coverage allows: a sensor inside a basement will stay at SF12 whatever the network does. That is a coverage problem, not a configuration one, and the fix is a better antenna position or another gateway. The method for measuring coverage before you install is in our guide to LoRaWAN range.

Spreading factor also affects the network, not just the battery. In Europe the 868 MHz band imposes a duty cycle, and community networks add fair use limits. The Things Network, for example, documents a fair use policy of 30 seconds of uplink airtime per device per day. A device at SF12 sending every 15 minutes uses about 142 seconds a day, almost five times that allowance.

A Worked Example: Same Sensor, Two Battery Lives

Take one sensor design and install two units: one near a gateway, one in a pit at the edge of coverage. Both send an 11-byte message every 15 minutes, 96 messages a day. The numbers below are typical values for illustration, not measurements of a specific product.

Common to both:

• Battery: one AA lithium thionyl chloride cell, about 2,600 mAh nominal.
• Sleep: 5 µA, which is 0.12 mAh per day.
• Measurement: 3 mA for half a second per message, about 0.04 mAh per day.
• Transmission at 40 mA.

Unit A, near the gateway, SF7:

• Transmission: 96 messages of 62 ms at 40 mA, about 0.07 mAh per day.
• Receive windows and wake-up: about 0.03 mAh per day.
• Total: about 0.26 mAh per day.

On paper the cell would last for decades. In practice the cell's self-discharge and shelf life cap it well before that, so the realistic answer is that the battery outlives the project, typically 10 to 15 years.

Unit B, in the pit, SF12:

• Transmission: 96 messages of 1,483 ms at 40 mA, about 1.58 mAh per day.
• Receive windows and wake-up: longer at SF12, about 0.2 mAh per day.
• Total: about 1.94 mAh per day.

That is roughly 1,340 days, or 3.7 years, before any allowance for cold or battery ageing. Take off a reasonable margin and Unit B needs a battery change after about three years.

Same sensor, same firmware, same interval. One lasts the life of the contract and the other generates a field visit in year three. Multiply Unit B by the share of your fleet that sits at the edge of coverage, and you have your real maintenance budget. In a smart water metering project, where meters often sit in pits, that share can be large.

The Battery Itself: Chemistry, Temperature, and Pulses

The energy budget assumes the battery delivers its nominal capacity. Often it does not.

Most long-life LoRaWAN sensors use lithium thionyl chloride (Li-SOCl2) cells. They have very high energy density, a flat 3.6 V discharge curve, and self-discharge of around 1% per year, which is why they suit ten-year devices. They also have two quirks.

Passivation. During long periods of low current, a thin layer forms inside the cell. When the radio suddenly asks for 40 to 120 mA, the voltage can dip sharply before the layer breaks down. If it dips below the device's brown-out threshold, the sensor resets mid-transmission. The symptom in the field is a device that reboots or rejoins regularly with plenty of capacity left.

Pulse capability. Bobbin-type cells, the ones with the highest capacity, cannot supply high current pulses well. Designers add a capacitor, or use a hybrid layer capacitor pack, to supply the transmit pulse while the cell recharges it slowly. If you are choosing hardware, ask how the device handles the transmit peak.

Temperature compounds both problems. Cold reduces the available capacity and makes voltage dips worse. A sensor that works for years in an office can fail in a winter on a hillside or inside a refrigerated warehouse. Use the capacity figure at your real operating temperature, not at 25 °C.

Self-discharge belongs in the budget too. At around 1% a year, a cell loses roughly a tenth of its capacity over a decade without powering anything, and the months in storage before installation count as well. Devices that spent a year in a warehouse start their working life with less than the datasheet assumes.

The practical rule: derate the nominal capacity by 20% to 30% for a typical outdoor deployment, more for sustained cold.

Settings That Drain Batteries Without Warning

Some of the worst battery losses come from configuration, not hardware. These are the ones to check first.

• Confirmed uplinks. Asking the network to acknowledge every message doubles the radio activity on both sides and, when the acknowledgement is missed, triggers retransmissions. Use confirmed messages for alarms that truly need them, not for routine readings.
• Rejoin loops. A device that loses its session and keeps trying to join with OTAA can transmit join requests repeatedly at high spreading factors. A misconfigured key or a network server problem can empty batteries across a fleet in weeks.
• Too-short intervals. Sending every five minutes when the process changes hourly costs battery and adds nothing. Match the interval to the process, and use events for changes that cannot wait.
• Frequent downlinks. Every downlink is a reply the device must receive and often acknowledge. Configuration changes are fine; polling a device by downlink every hour is not.
• Class C by mistake. Class C devices keep their receiver on continuously. That is correct for mains-powered actuators and fatal for a battery sensor.
• ADR switched off on static devices. Without it, devices may stay at a high spreading factor long after coverage improves, for example after a new gateway goes up.

None of these show up in a lab test of a few days. They show up as a cluster of dead batteries a year later.

How to Extend LoRaWAN Battery Life in the Field

Battery life is decided at three moments: when you choose the hardware, when you install it, and while you operate the fleet.

When choosing hardware:

1. Ask for the battery calculation at your interval, payload, and the spreading factor your worst devices will use, not only the best case.
2. Check sleep current and sensor warm-up time.
3. Ask how the device handles transmit peaks and cold.

When installing:

1. Measure the signal at the real position before closing the enclosure. Moving an antenna out of a metal cabinet can drop a device several spreading factors, and each step down roughly halves its transmission energy.
2. Record the spreading factor and signal quality of the first uplinks for every device. That baseline is your early warning later.

While operating:

1. Enable ADR on static devices and make sure the network server applies it.
2. Report battery voltage in the payload, and watch the trend per device, not only an absolute threshold.
3. Raise an alarm when a device stops reporting, grouped by area so a gateway outage does not become a hundred tickets.
4. Review the spreading factor distribution of the fleet every few months. A growing share at SF11 and SF12 means coverage is getting worse, and batteries will follow.

The data for most of this comes from the network server, which sees signal quality and spreading factor for every uplink. Cloud Studio IoTITermIoT (Internet of Things)The IoT (Internet of Things) is the network of physical objects with sensors, software and connectivity that collect and exchange data and act autonomously.View profile receives LoRaWAN data through external network servers such as The Things Stack, LORIOT, or ThingPark X, so the battery voltage reported by the device can be stored, charted, and used in alarm rules, along with an alarm when a device goes silent, with notifications by email, SMS, WhatsApp, voice call, or push. For how the network server fits into the chain, see our guide to the LoRaWAN network server. For the wider question of keeping a fleet healthy over years, see IoT device management.

Conclusion

LoRaWAN battery life is predictable if you calculate it for the devices that are hard to reach, not for the easy ones. The key points:

• Datasheet figures are best cases: short payloads, long intervals, strong signal, and mild temperature.
• Spreading factor is the biggest single variable. SF12 costs about 24 times the airtime of SF7 for the same message.
• The same sensor can last more than ten years near a gateway and about three at the edge of coverage.
• Derate the battery for cold and pulse loads, and choose hardware that handles transmit peaks.
• Confirmed uplinks, rejoin loops, short intervals, and Class C by mistake drain fleets quietly.
• Measure signal at installation, keep ADR on for static devices, and watch battery and spreading factor trends.

If you are sizing a LoRaWAN deployment and want to check the energy budget or the coverage plan, see our LoRaWAN solutions or talk to the team. For the broader picture of IoT sensors and what changes when a fleet grows, read our guide to IoT scalability. The LoRa and LoRaWAN overview from Semtech is a good technical reference on the radio itself.

Frequently asked questions

How long does a LoRaWAN sensor battery last?

It depends mostly on the signal. In the worked example of this guide, the same sensor sending every 15 minutes lasts 10 to 15 years near a gateway at SF7 and about three years at the edge of coverage at SF12. Datasheet figures are best cases for a well-covered device.

Why do LoRaWAN batteries die sooner than the datasheet says?

Because the ten-year figure assumes a short payload, a long interval, a strong signal and mild temperature. Devices far from a gateway transmit at high spreading factors, and each message can take more than 20 times longer on air. Cold, confirmed uplinks and rejoin loops shorten it further.

How does the spreading factor affect battery life?

Each step from SF7 to SF12 roughly doubles the time a message spends on air. For an 11-byte payload, SF7 takes about 62 ms and SF12 about 1,483 ms, around 24 times the transmission energy for the same message.

Does ADR save battery?

Yes, on static sensors. With adaptive data rate the network server tells each device to use the lowest spreading factor and transmit power that still get through. It cannot go below what the coverage allows: a sensor in a basement stays at SF12 until the antenna position or the gateway coverage improves.

What type of battery do LoRaWAN sensors use?

Most long-life sensors use lithium thionyl chloride (Li-SOCl2) cells: very high energy density, a flat 3.6 V discharge curve and self-discharge of around 1% a year. They handle current pulses poorly, so designers add a capacitor, and cold reduces the capacity available.

How can I extend the battery life of a LoRaWAN deployment?

Measure the signal at the real position before closing the enclosure, keep ADR on for static devices, avoid confirmed uplinks for routine readings and match the interval to the process. Then watch battery voltage and spreading factor trends per device, and derate the nominal capacity by 20% to 30% outdoors.