LoRaWAN Device Classes Workbench

LoRaWAN Device Classes Workbench

Compare Class A, B, and C receive-window timing, downlink latency, and power tradeoffs

animation
lorawan
lpwan
device-classes
downlink
receive-windows
intermediate
Interactive LoRaWAN device classes workbench showing uplink-triggered RX1/RX2 windows, Class B beacon-synchronized ping slots, Class C continuous receive, queued downlinks, and power-latency tradeoffs
LoRaWAN downlink Class A/B/C Receive windows

LoRaWAN device classes workbench

Compare when a network server can reach a LoRaWAN device. The class changes receive timing and power behavior; it does not change the radio modulation, activation method, or application payload format.

Class Aselected device class
31 s waitfirst downlink chance
short windowsreceiver behavior
battery sensorbest fit
TrySet Command arrives to 30 s and Uplink period to 60 s, then compare Device class A with Class B ping slot 16 s.
ObserveQueued downlink latency waits for the next Class A RX1/RX2 opportunity, drops toward 16 s with locked Class B, and is lowest for Class C.
ExplainClass A opens receive windows only after its own uplink, Class B adds beacon-scheduled ping slots, and Class C listens almost continuously at higher receiver power.
Technical boundariesThe receive timeline omits exact RX delays/window widths, beacon acquisition energy, clock drift, regional duty limits, gateway contention, retries, ADR, multicast, and battery chemistry.
Colour keylorawan identitycurrent / primaryreference / datasuccesscautionerror / failure

Scenario

Timing Controls

Ready: inspect receive timeline

Watch For

A downlink can only be sent while the device receiver is open. Class choice is mostly a downlink latency and power tradeoff.

Class ATwo receive windows after each uplink. Lowest receive duty cycle.
Class BAdds beacon-synchronized ping slots for scheduled downlinks.
Class CListens almost continuously except during transmit. Highest receive duty.
Queue riskIf no window occurs soon, the server must hold or expire the downlink.

Receive Timeline

uplink-triggered
LoRaWAN receive window timeline Timeline comparing Class A RX1 and RX2 windows, Class B beacon synchronized ping slots, and Class C continuous receive behavior with a queued downlink command marker.
1. Sleepreceiver mostly off
2. Uplinkdevice transmits
3. Queueserver has downlink
4. Listennext RX chance
5. Deliversend or wait

Class Profiles

Readouts

Class Aactive receive strategy
command at 30 sserver downlink request time
next RX at 61 sfirst matching opportunity
31 s waitqueued downlink latency
lowest RX dutyrelative power behavior
server queues commandoperational implication

Diagnosis

Step Transcript

Quick Reference
Class AMandatory baseline. The device opens RX1 and RX2 after an uplink, then returns to sleep.
Class BClass A plus network beacons and scheduled ping slots. It needs beacon lock and network support.
Class CClass A plus nearly continuous receive outside transmit time. Best latency, highest receive power.
Technical Accuracy Notes
Timing simplificationThe workbench uses seconds on a 128-second teaching timeline. Actual RX parameters depend on region, RX1DROffset, RX2 settings, MAC commands, and network configuration.
Class B beacon periodThe 128-second beacon period is shown as a synchronization frame. Ping-slot periodicity is configurable; smaller intervals cost more listening energy.
Do not overread powerPower labels are relative because real current depends on the radio, MCU sleep mode, firmware, temperature, and duty cycle.
SpecificationLoRaWAN Link Layer Specification v1.0.4
Device guidanceLoRa Alliance TR007 device development recommendation
Practice promptSet a Class A uplink period to 120 seconds and move the command just after RX2. Predict how long the server must wait.