LoRaWAN explained: range, data rates and when to use it

A sensor in a field, a water meter in a basement, a bin in a car park: none of these has Wi-Fi nearby, none can afford a cellular subscription and a large battery, and none needs to send more than a few bytes now and then. LoRaWAN, one of several low-power wide-area network (LPWAN) technologies, was designed for exactly that gap, and it does the job well as long as you understand what it trades away to get there.

LoRa and LoRaWAN are two different things

LoRa is a radio modulation technique. It is a way of encoding bits onto a radio signal that lets a receiver pick out a very weak signal from the noise, at the cost of sending slowly. It is proprietary to one chip manufacturer (Semtech) and is used in the unlicensed sub-gigahertz bands, which differ by region. On its own, LoRa lets two radios exchange packets over a long distance. It says nothing about addressing, security, networks or how many devices can share the air.

LoRaWAN is the network protocol built on top of LoRa. It is an open specification maintained by the LoRa Alliance, which publishes the LoRaWAN specification and regional parameters, and it defines how devices join a network, how packets are addressed and encrypted, how gateways forward them, how the network manages data rates, and how a device can receive messages back. When people say “a LoRaWAN sensor” they mean a device that speaks this protocol, and it needs a LoRaWAN network to talk to.

The distinction matters when you shop. Two LoRa modules can be made to talk to each other with a few lines of code, which is fine for a private point-to-point link. A LoRaWAN device needs a gateway and a network server, and in return gets security, scale, and interoperability with any other LoRaWAN network.

How a LoRaWAN network is built

A LoRaWAN network has four parts. End devices (the sensors) transmit packets whenever they have something to say. Gateways listen on several channels at once and forward every packet they hear, over an ordinary internet connection, to a network server. The network server deduplicates packets heard by more than one gateway, checks their integrity, manages each device’s data rate, and hands the payload to an application server. The application server decrypts the payload and does whatever the application does with it: store it, display it, forward it as an MQTT message.

Devices are not paired to a gateway. They broadcast, and every gateway in range forwards what it hears. Adding a gateway simply widens coverage and improves reliability for every device near it. That is a different model from Wi-Fi, where a device associates with one access point, and it is a large part of why LoRaWAN scales.

Security is built in at two layers. A network session key protects the packet’s integrity between the device and the network server; an application session key encrypts the payload between the device and the application server, so the network operator cannot read the data. Devices obtain both by a join procedure, using credentials programmed at manufacture.

You can use a public network run by an operator, a community network, or your own private one with your own gateways and server. The devices do not care which.

Range: what to expect

LoRa’s selling point is range, and the numbers quoted are real under the right conditions and misleading under the wrong ones. With a gateway antenna mounted high with a clear view, and a device outdoors, links across a rural area of several kilometers are routine, and much longer distances have been demonstrated with line of sight. In a town, with the gateway on a rooftop and devices at street level among buildings, expect a small number of kilometers. Indoors, or with the device in a basement or a metal enclosure, expect far less, and expect the data rate to drop to the slowest setting to keep the link at all.

The rules are the same as for any radio. Height at the gateway is the single most valuable thing you can buy; a gateway on a mast covers many times the area of the same gateway on a desk. Line of sight beats everything. Sub-gigahertz frequencies pass through walls and foliage better than Wi-Fi frequencies, which is part of why LoRa reaches where Wi-Fi does not, but every wall still costs signal.

Plan coverage by testing rather than by quoted range. A device that reports its signal strength, carried around the site, produces a map that no datasheet can.

Data rates and spreading factors

LoRa trades speed for reach through a setting called the spreading factor. A higher spreading factor sends each bit more slowly and more redundantly, so the receiver can recover it from a weaker signal, at the cost of a much longer transmission. A lower spreading factor sends faster and needs a stronger signal. Each step up in spreading factor roughly doubles the time a packet spends on the air.

Three consequences follow. Range and data rate are the same knob: the farthest devices are the slowest. Time on air is battery: a packet sent at the slowest setting keeps the radio transmitting for a much longer time than the same packet at the fastest, and that shows up directly in the power budget. And time on air is also capacity: because every device shares the same channels, and regulations in most regions limit how much of the time a device may transmit, slow packets crowd the air and reduce how many devices a gateway can serve.

The network server manages this with adaptive data rate. A device that is heard strongly is told to use a faster setting and lower power; one that is barely heard is told to slow down. Devices that move should not rely on it, because the setting that worked in one place fails in the next; fixed devices should let the server tune them.

Payloads are small by design. Depending on region and data rate, a packet may carry a few dozen to a couple of hundred bytes, and the regulatory duty limit means a device might send only a handful of messages an hour at the slowest rates. That is plenty for a meter reading and useless for anything chatty.

Device classes A, B and C

LoRaWAN defines three classes that decide when a device can receive.

Class A devices transmit when they choose, then open two short receive windows immediately afterward. That is the only time the network can send them anything. It is the lowest-power class and the one almost all battery sensors use: the device sleeps until it has something to say, sends, listens briefly, and sleeps again. A command from the network waits until the device next speaks.

Class B devices additionally open scheduled receive windows, synchronized by beacons from the gateways, so the network can reach them at known times without waiting for an uplink. That costs some power and needs gateways that transmit beacons.

Class C devices listen continuously except when transmitting. They can be reached at any time and use the most power, so they are mains-powered devices such as actuators, valves and street-lighting controllers.

Choose Class A unless you need to send commands to the device promptly, and in that case ask whether it can be mains powered and made Class C.

When to use LoRaWAN and when not to

Use it when the device is far from any Wi-Fi, when it must run for years on a battery, when it sends a few bytes a few times an hour, and when you can put a gateway somewhere high or there is already a public or community network covering the site. Meters, environmental sensors, agriculture, asset presence, tank levels and occupancy counters all fit. Private networks make sense for a campus, a farm or an industrial site where you own the roof.

Do not use it for anything that needs bandwidth, low latency, or frequent messages. It cannot carry audio, images or video. It is a poor fit for devices that move quickly across regions or that need to be commanded within seconds. It struggles deep inside large buildings unless you install indoor gateways. And a private network is a real system to run: gateways, backhaul, a network server, and someone who understands the frequency plan.

If the device needs to send more, or needs to be reached quickly, or sits where no gateway can be, cellular IoT is the neighbor to consider; the article on NB-IoT and LTE-M covers that side, and the IoT protocols explainer places all of them in one stack. If the devices need more data but stay on a site you control, Wi-Fi HaLow is the other option: Wi-Fi below 1 GHz, with less reach than LoRaWAN and ordinary IP networking. Between the two of them and Wi-Fi, almost every fixed sensor has a sensible radio. LoRaWAN is the one for the far, slow, patient end of that range, and within it there is little else that competes.