What Are LoRaWAN Device Classes A, B, and C?

Detailed Explanation

The LoRaWAN device class system solves a fundamental constraint of low-power radio networks: a power-saving device that sleeps most of the time cannot receive a message from the network whenever the server needs to send one — it can only listen when it is awake. The three classes define three different strategies for managing this trade-off between downlink availability and power consumption.

Class A — Minimum Power, Maximum Efficiency

Class A is the mandatory baseline that every LoRaWAN device must implement. It defines two downlink receive windows that open after each uplink transmission.

Receive window timing:

After the device completes an uplink transmission, it opens:

• RX1: opens exactly RECEIVE_DELAY1 seconds after the end of the uplink preamble. For AU915, this is 1 second.
• RX2: opens exactly RECEIVE_DELAY2 seconds after the end of the uplink preamble. For AU915, this is 2 seconds.

The network server may send one downlink in either RX1 or RX2 — not both. If no downlink is sent in either window, the device has no further opportunity to receive a message until it transmits again. This is the defining constraint of Class A: the network can only send a downlink after the device initiates an uplink.

AU915 receive window parameters (per LoRaWAN Regional Parameters RP002):

The RX1 channel and data rate follow a mapping table in the AU915 regional parameters — the channel is selected based on which of the 64 uplink channels was used. The RX2 window always uses the same fallback frequency and data rate, providing a robust second chance at SF12 (lowest data rate, highest receiver sensitivity).

Power profile:

Between uplinks, the device sleeps at microamp-range current (the LoRa transceiver and MCU are both off). The duty cycle is dominated by the uplink frequency:

• A sensor that uplinks once every 10 minutes at SF9 (time-on-air approximately 200 ms) and opens two short receive windows (each approximately 50 ms) has an active duty cycle of approximately 0.05% — the sleep current dominates overwhelmingly.
• For typical LoRa transceiver modules at 3.3 V, RX mode draws approximately 5–15 mA and TX at 14 dBm draws approximately 30–45 mA.
• Average current for a Class A device uplink at 10-minute intervals: typically 1–5 µA, depending on the transceiver, MCU sleep current, and uplink rate.

Use Class A when:

• Battery life is the primary design constraint
• Downlink messages are rare or infrequent (configuration updates, occasional commands)
• The application can tolerate waiting until the next scheduled uplink to receive a command
• The device is a sensor that primarily sends data, not an actuator that receives commands

Limitations of Class A:

• Worst-case downlink latency equals the uplink interval plus the maximum RX window time. For a device that uplinks once per hour, a command can take up to one hour to be delivered.
• The network server cannot initiate communication — it must queue the downlink and wait for the next device uplink.
• Not suitable for devices that require prompt remote control, firmware updates, or real-time feedback.

Class B — Scheduled Receive Windows

Class B extends Class A with additional scheduled receive windows (ping slots) that enable the network server to send downlinks at predictable times, without waiting for an uplink.

Beacon synchronisation:

All Class B devices must first synchronise to a network-wide beacon transmitted by the gateways every 128 seconds. The AU915 beacon uses:

The beacon payload includes a timestamp that allows devices to maintain sub-millisecond timing synchronisation without GPS hardware in the device itself. A device that acquires the beacon can predict when all future ping slots will occur and wake accordingly.

Ping slots:

Within each 128-second beacon period, the device opens periodic receive windows (ping slots). The ping slot interval P determines both downlink latency and power consumption:

P = 2^k × 32 ms     (k ∈ {0, 1, 2, 3, 4, 5, 6, 7})

The ping slot frequencies hop pseudo-randomly using the device address (DevAddr), so different devices open ping slots on different channels within each 128-second period. This spreads downlink traffic across the available channels.

Class B power consumption:

Class B adds power cost in two ways:

1. The device must wake every 128 seconds to receive the beacon (approximately 5–15 mA for ~50 ms per beacon)
2. The device wakes for each ping slot (approximately 5–15 mA for approximately 5–10 ms per slot)

For k = 4 (512 ms ping period), the device opens 250 ping slots per 128-second period. If each slot takes approximately 10 ms at 10 mA, the ping slot current contribution is approximately: (250 × 10 ms × 10 mA) / (128 × 1000 ms) ≈ 195 µA

This is significantly higher than Class A at a 10-minute uplink rate, but substantially lower than Class C continuous receive.

Use Class B when:

• The device needs predictable downlink latency (seconds to minutes) without the continuous power draw of Class C
• The device is battery-powered but must respond to remote commands within a bounded time
• Examples: outdoor LED lighting control, vending machine restocking alerts, remote valve actuators with battery backup

Limitations of Class B:

• Requires gateways that support beacon broadcasting with GPS-disciplined timing — not all LoRaWAN gateways support this
• The device must acquire the beacon before entering Class B mode, which takes up to 128 seconds after power-on or loss of sync
• TTN public network Class B support depends on the gateways available in the coverage area

Class C — Continuous Reception

Class C devices keep the receiver open at all times, except when transmitting. After an uplink, the device opens RX1 (same as Class A), then RX2, and then — unlike Class A — keeps the RX2 window open continuously until the next uplink transmission.

Downlink timing:

The network server can send a downlink to a Class C device at virtually any time. The only constraint is that the device is in TX during its own uplink (typically a few hundred milliseconds), during which it cannot receive. Practically, downlink latency from the network server's perspective is bounded by the network server polling interval and transmission scheduling — typically under 1 second in well-configured deployments.

Power consumption:

The LoRa receiver in continuous RX mode draws approximately 5–15 mA at 3.3 V (depending on the transceiver — the SX1262 draws approximately 6 mA at 14 dBm/3.3 V in receive mode, per Semtech's datasheet). For continuous operation on a 2000 mAh battery, this gives roughly 130–400 hours (5–17 days) of battery life before depletion — far too short for most IoT deployments.

Class C is therefore practical only when:

• The device is mains-powered or has a large rechargeable supply
• A DC/DC converter is used to run the SX1262 receive chain efficiently
• Brief battery operation during mains failure is acceptable (battery backup for short interruptions)

Use Class C when:

• The device is mains-powered
• Near-real-time downlink response is required (< 1 s latency)
• Examples: smart street lights, industrial actuators and relays, electric vehicle charging stations with LoRaWAN management interfaces, mains-powered access control panels

Class Comparison

Firmware Implementation Notes

Class A is the default in all LoRaWAN stacks (MCCI LMIC, RadioLib, Arduino LoRa). No explicit class selection is required — devices start in Class A after OTAA join.

Class B in MCCI LMIC: partial support exists in the LMIC library. Class B beacon acquisition requires LMIC_requestNetworkTime() to sync the LMIC clock and then enabling ping slot scheduling. The LoRaWAN Specification v1.0.3 and v1.0.4 define the Class B procedures; ensure your network server (TTN or ChirpStack) version supports the LoRaWAN revision you are targeting.

Class C in MCCI LMIC:

/* Enable Class C immediately after OTAA join: */
void onEvent(ev_t ev) {
    if (ev == EV_JOINED) {
        LMIC_setLinkCheckMode(0);
        /* Switch to Class C — device keeps RX2 window open after each TX */
        LMIC_sendAlive();          /* Optional: tell NS this is Class C */
        /* In LoRaWAN 1.0.3+, MAC DeviceModeInd command signals class change */
    }
}

Some stacks require explicit Class C configuration. Check the LoRaWAN stack documentation and confirm with the network server that Class C is being respected — if the NS does not know the device is Class C, it will only schedule downlinks in the Class A windows.

Design Considerations

• TTN fair-use policy applies to all classes: The Things Network's fair-use policy limits each device to 30 seconds downlink time-on-air per day. Class C does not increase the permitted downlink volume — it only changes when downlinks can be scheduled. A Class C device that receives frequent downlinks can exhaust the daily downlink budget quickly.
• Class B gateway availability in Australia: before designing a product around Class B, verify that gateways in your target deployment area support beacon broadcasting. Contact TTN community members or use a private ChirpStack deployment with GPS-disciplined gateways.
• AU915 RX2 fallback: RX2 at 923.3 MHz / SF12 / 500 kHz is the robust fallback delivery mechanism for all classes. If downlinks are consistently arriving in RX2 but not RX1, check that the RX1 channel mapping and data rate offset are configured correctly on the network server.
• Class C and duty cycle: although Class C receives continuously, it is still subject to regional duty cycle limits on the transmit side. In AU915 there is no fixed duty cycle limit on the 915 MHz band (unlike the EU868 1% rule), but device certification requirements under ACMA still apply.
• ADR interaction with device class: Adaptive Data Rate (ADR) adjusts the uplink spreading factor based on link quality. A Class A device with long uplink intervals may experience link quality changes between ADR adjustments. For Class C devices, the network server has more visibility into the device's receive performance via downlink acknowledgements, which may improve ADR accuracy.
• Zeus Design designs LoRaWAN hardware and firmware for Australian IoT deployments — covering Class A sensor nodes, Class C actuator interfaces, AU915 gateway installation, and ACMA compliance for LoRa products.

Common Mistakes

• Expecting Class A to support real-time commands: Class A is not suitable for any application where the server needs to send a message at an unpredictable time and the device must respond quickly. A Class A remote actuator that uplinks once per hour can take up to an hour to respond to a command — design for Class C or an alternative protocol if response time matters.
• Not verifying network server Class C support: some older or misconfigured LoRaWAN network servers default to Class A scheduling for all devices. A Class C device that is not recognised as Class C by the NS will not receive the continuous downlink opportunities its firmware expects — the NS will queue downlinks for Class A windows only.
• Assuming Class B works everywhere on TTN: Class B requires all gateways in the coverage area to broadcast the synchronised beacon. In areas with limited TTN gateway coverage or gateways without GPS sync, Class B will fail silently — the device never acquires the beacon and the class switch does not complete.
• Ignoring RX2 data rate misconfiguration: the AU915 RX2 window must use 923.3 MHz at DR8 (SF12, 500 kHz). If a private network server is configured with different RX2 parameters, downlinks in RX2 will fail. This is a common misconfiguration when migrating between LoRaWAN specification versions or setting up a new ChirpStack instance for AU915.
• Shipping a Class C product on battery: a Class C device draws approximately 6–15 mA continuously in receive mode — a 2000 mAh battery lasts approximately 5–17 days. If the product is intended for field deployment without reliable mains power, Class C requires a battery pack sized for the expected deployment duration or a duty-cycled receive architecture (which defeats Class C's purpose). For battery products with low-latency downlink requirements, evaluate Class B with a short ping period instead.
• Not handling missed beacon synchronisation in Class B: Class B devices can miss the beacon due to RF noise or gateway downtime. The LMIC and Zephyr LoRaWAN implementations maintain beacon timing via internal clock extrapolation for a limited number of missed beacons. After too many misses, the device falls back to Class A automatically. Application firmware must handle this fallback and re-enter Class B mode when a beacon is re-acquired.