LoRaWAN Classes Explained

One of the things that distinguishes LoRaWAN from simpler radio protocols is that it defines three different classes of device behaviour. Not all LoRaWAN devices are the same, and understanding why the classes exist helps you make better decisions when choosing sensors and designing a deployment.

The classes are about one specific question: when is a LoRaWAN device able to receive a message?

That question sounds simple until you think about what a battery-powered sensor is actually doing most of the time, which is nothing. It is asleep, conserving power, waking up periodically to take a reading and transmit it. The radio receiver consumes power when it is listening. Keeping the receiver on continuously would drain a battery in days. So the design question is: how do you get a message back to a device that is mostly asleep?

The three classes represent three different answers.

Class A: listen after you speak

Class A is the baseline. Every LoRaWAN device implements it, and for most IoT sensor deployments it is the only class you need.

The rule is simple. After a device transmits an uplink, it opens two short receive windows. The first window opens one second after the uplink. The second opens two seconds after the uplink. If the network server has a downlink message queued for that device, it delivers it in one of those windows. If neither window is used, the device goes back to sleep and the network server waits until the next uplink to try again.

Outside of those two post-uplink windows, a Class A device is not listening. You cannot reach it. If the network server needs to send a firmware update, a configuration change, or any other downlink, it has to queue the message and wait for the device to transmit something first.

For most sensors, this is fine. A temperature sensor transmitting every ten minutes opens receive windows every ten minutes. If you need to change its configuration remotely, you send the downlink and it arrives within ten minutes at most. That latency is entirely acceptable for the use cases LoRaWAN is designed for.

The power implication is significant. Class A devices are the most battery-efficient because the radio is only listening for two brief windows after each uplink. A well-designed Class A sensor can genuinely run for years on a single battery.

Class A is the right default. If you are deploying sensors and you are not sure which class to use, the answer is almost certainly Class A.

Class B: scheduled listening

Class B adds a third receive window: a scheduled, periodic beacon-synchronised slot where the device listens for downlinks.

The way it works: the network server broadcasts a time synchronisation beacon every 128 seconds. Class B devices lock onto this beacon and open additional receive windows (called ping slots) at predictable intervals between beacons. The intervals are configurable: a device might open a ping slot every second, every two seconds, every four seconds, and so on up to every 128 seconds.

The result is that the network server knows exactly when a Class B device is listening, and can schedule a downlink without waiting for the device to transmit an uplink first. The maximum latency for a downlink is bounded by the ping slot interval rather than by however long it takes the device to wake up and send something.

Class B consumes more power than Class A because the device has to stay synchronised with the beacon and open additional receive windows. More frequent ping slots mean more power consumption. The balance between downlink latency and battery life is tunable per device.

Class B is appropriate when you need more responsive downlink capability but still want reasonable battery life. An actuator that needs to respond to commands within seconds rather than waiting for the next scheduled uplink is a candidate for Class B. A smart meter that needs to receive tariff updates at predictable times is another example.

The infrastructure requirement is also higher: the network server and gateways must support Class B synchronised beaconing. ChirpStack supports Class B, but you need to verify that the gateway hardware does too.

Class C: always listening

Class C is the simple one. A Class C device keeps its receiver on continuously, except when it is transmitting. It is always listening. A downlink can be sent at any time and arrives almost immediately.

The obvious trade-off: Class C devices consume significantly more power than Class A or B. The receive radio draws power constantly. For a mains-powered device, this is irrelevant. For a battery-powered device, it is generally not practical.

Class C is the right choice for devices that are plugged into mains power and need immediate response to commands. Smart plugs, actuated valves, lighting controllers, and similar mains-powered devices benefit from Class C because latency is minimised and power consumption is not a constraint.

A LoRaWAN street light controller, for example, needs to respond immediately when the network tells it to switch on at dusk. Waiting up to ten minutes for the device to transmit something before it can receive the switch command is not acceptable. Class C solves this.

The practical picture

For a homelab LoRaWAN deployment focused on environmental monitoring, almost everything will be Class A. Temperature sensors, humidity sensors, soil moisture sensors, door contact sensors, GPS trackers: all of these are battery-powered devices where the sensor initiates all communication and the network server occasionally sends configuration updates. Class A covers this perfectly.

Class B becomes relevant when you have actuators that need to respond within a defined time window but are still battery-powered. This is less common in a home monitoring context.

Class C is for mains-powered actuators. If you are controlling something with LoRaWAN, switching a relay or a valve, and the device is plugged in, Class C is worth considering.

Most off-the-shelf LoRaWAN sensors sold for environmental monitoring implement Class A only. Class B and C devices are typically more specialised hardware. When buying sensors, the class is usually stated in the datasheet. If it is not mentioned, it is almost certainly Class A.

One thing that catches people out

Class A does not mean the device can only receive immediately after an uplink. It means that is the only time the network server is guaranteed to reach it.

If you have a Class A device that transmits every ten minutes and you send a downlink, the device will receive it at the next uplink, at most ten minutes later. But if the device happens to transmit at an unexpected time, say because a threshold was crossed, the downlink arrives then instead.

The point is that with Class A, the network server cannot initiate contact on its own schedule. It has to wait for the device to open the conversation. With Class B, the network server can predict when the device will listen and deliver accordingly. With Class C, the device is always there to receive.

The classes are not a hierarchy where C is better than A. They represent different designs for different problems. A Class C sensor that does not need immediate downlinks is just wasting power. A Class A actuator that needs to respond immediately is making users wait unnecessarily. The right class is the one that fits the use case.