Skip to main content

Device classes

The LoRaWAN class defines when a device listens and can receive data from the server (downlink). The class determines battery life and how quickly a command reaches the device. Orion Network Server supports classes A and C.

ClassWhen the device listensHow soon a command arrivesPowerIn ONS
ATwo short windows right after each of its uplinksAfter the next uplink — minutes or hours laterBattery, the most economical modeSupported
BIn addition, short scheduled windows synchronized by the gateway beaconPer the specification — by the next scheduled window; ONS sends no data to such devicesBatteryNot supported
CAlways, except while it transmitsSecondsExternal powerSupported

Class A​

The basic class supported by every LoRaWAN device. After each transmission the device opens two short receive windows: RX1, by default 1 second after the uplink, and RX2, 2 seconds after the uplink. The rest of the time the receiver is off, so the device uses the least energy.

How ONS sends data to a class A device:

  • The frame waits in the queue until the device reports. Right after an uplink the server transmits the frame through a gateway in one of the receive windows.
  • The window — RX1 or RX2 — is set in the device settings. If the frame can no longer reach the gateway in time for RX1, the server sends it in RX2.
  • One frame goes out per window. If more frames remain in the queue, the server tells the device so with the FPending flag, and the remaining frames go out after subsequent uplinks.
  • Until the device has sent at least one uplink after joining the network, the server cannot send it any data.

A queued frame waits 1 hour by default, then gets status 8 (Expired). If the device reports less often, set a longer waiting time when sending — the ttl field of downlink_data_req.

Class B​

Besides the windows after an uplink, a class B device opens receive windows on a schedule. The schedule is synchronized by a beacon transmitted by gateways with GPS.

ONS does not support class B: the server sends no data to a device whose settings specify class B. If the device firmware allows it, switch the device to class A or C.

Class C​

The receiver of a class C device is always on, except while the device transmits, so a command arrives within seconds. This mode consumes a lot of energy and suits devices with external power: relays, controllers, mains-powered metering modems.

How ONS sends data to a class C device:

  • The frame goes out right after queuing, at the frequency and data rate of the RX2 window.
  • The frame is transmitted by the gateway that received the device's last uplink best. Another gateway can be set with the gatewayEui field of downlink_data_req.
  • If the gateway is busy, sending is postponed. If the gateway airtime budget is exhausted, the frame gets status 14 (DC Limit) and stays in the queue.
  • As with class A, the device must report at least once after joining the network: before the first uplink the server does not know which gateway can reach it.

How to set the class​

The class is set in the device settings: the node_class field of the WebSocket API commands create_device_req and update_device_req — 1 for A, 2 for B, 3 for C. Class A is the default. When a change takes effect is described on the update_device_req page. The current class is returned by dev_lw_class_req.

Warning

The class in the settings must match how the device firmware actually works. The server neither detects nor changes the class: ONS does not process the LoRaWAN 1.1 DeviceModeInd command by which a device reports a class change. If the settings specify class C while the device operates in class A, the server sends the frame immediately, the device does not hear it, and the frame status is still 3 (Delivered) — an acknowledgement from the gateway, not from the device.

See also​