LoRaWAN's message rhythm and keys

A node that only listens after it speaks

A Class A device, the usual kind, cannot be called when someone wants it. It sends when it has something to say, then opens two short receive windows and goes back to sleep. That is how a battery lasts. A downlink, a message from the network to the node, can only follow an uplink and can only land in one of those windows. If the server has a command ready, it waits for the node's next report.

The two windows

The first window opens after one second, counted from the end of the uplink. The second opens after two seconds, on a fixed channel and a slow setting, for the case where the first heard nothing. Those are defaults. The network can configure the delays, so treat one and two seconds as a starting point and not as a law of the radio.

Three classes

Class B adds ping slots that are synchronised to a beacon sent every 128 seconds, so the node is reachable at times the network knows. Class C keeps listening whenever it is not sending. It is reachable almost at once and pays for it in current, which is why it suits a mains-powered actuator better than a soil probe. Every window a node opens, and every downlink a gateway sends, costs energy and airtime.

Counters and keys

Each frame carries a counter that only goes up. A frame whose counter is not greater than the last one seen is rejected, which is what stops a recorded frame being played back later.

In version 1.0.4, a device that joins over the air starts with an identifier and a root key, and the join produces two session keys. One protects the integrity of each frame, so the network knows the frame was not altered and who sent it. The other encrypts the application payload. These are two jobs with two keys. LoRaWAN does not encrypt everything twice, and raw LoRa, with no network on top, has no encryption of its own, as the previous lesson showed. Past the network server, an application often moves the data on with MQTT.

Common mistakes

• Expecting to command a Class A node at any moment. It listens only after it sends. A command waits for the next uplink, which may be minutes away.
• Treating one and two seconds as fixed. They are the default delays. A network can change them, and a node on another configuration will not match a bench's numbers.
• Counting on an acknowledgement as proof the data was used. A confirmed uplink asks for an acknowledgement, and it does not guarantee the delivery of the application's data. It also spends a downlink.