LoRaWAN® Message Types
- Downlink – Transmission of a packet from a gateway to an end-device is known as downlink. These transmissions can be requested by a network or application server.
- Uplink – Transmission of a packet from the end-device to a gateway is known as uplink.
LoRaWAN End-Device Types
Battery Powered - Class A (All Devices)
Every transaction in a Class A end-device starts with an uplink transmission, which is then followed by two downlink-receive windows. The network server sends the downlink message after receiving the uplink. At the end of the downlink message, the end-device enters Sleep mode, thereby saving power. Therefore, Class A devices consume the least power and provide a long battery life. All LoRaWAN end-devices support Class A by default. The following figure shows the data transmission and reception sequence for a typical Class A end-device:
Low Latency - Class B (Beacon)
In Class A, the downlink is non-deterministic since it depends on random uplinks from a sleeping end-device. In Class B, the end-device reduces the downlink latency by opening periodic downlink receive windows. The periodicity of the downlink windows is maintained by synchronizing the clocks of the end-device and the network server. For the synchronization, the network server commands the gateways to send a beacon at regular intervals. During uplink, the Class B end-device behaves similarly to a Class A end-device. The Class B end-device manages to reduce power consumption and yet reduces the downlink latency. The following figure shows the data transmission and reception sequence for a typical Class B end-device:
No Latency - Class C (Continuous)
Except for the uplink period, the end-device in Class C continuously opens the receive windows, which reduces latency, but increases its power consumption considerably. The following figure shows the data transmission and reception sequence for a typical Class C end-device as per LoRaWAN Specification 1.0.2:
As per LoRaWAN Specification 1.0.4, a Class C-enabled end-device listens as often as possible using a combination of channel/DR parameters referred to as RXC. It opens the RXC window starting from the end of the uplink transmission and the beginning of the RX1 reception window, another between the end of the RX1 window and the beginning of the RX2 window, and it shall switch to RXC reception parameters as soon as the RX2 reception window is closed, which remains open until the end-device begins to send another packet.