LoRaWAN Downlink Scheduling Workbench

Schedule queued downlinks into Class A receive windows, Class B ping slots, or Class C continuous receive

Interactive LoRaWAN downlink scheduling workbench showing server queues, Class A RX1/RX2 timing, Class B ping slots, Class C low-latency receive, downlink priority, expiry, airtime, and gateway-capacity risk.

LoRaWAN downlink Server queue RX1 / RX2 / ping slots

LoRaWAN downlink scheduling workbench

Queue a command at the network server, then watch when a LoRaWAN device can actually hear it. The scheduler must match device class, receive-window timing, priority, expiry, and gateway capacity.

Class Adevice receive mode

RX1 after uplinkselected target

37 s waitqueued latency

normal capacityserver risk

Scenario

Scheduler Controls

Device class Class A Class A Class B Class C

Downlink type application MAC command / ADR Application command Bulk or low priority

Command arrives 24 s

Class A uplink period 60 s

Class B ping slot 16 s

Payload bytes 12 B

Downlink data rate SF9 SF7 / faster SF9 / middle SF12 / slowest

Message TTL 180 s

Class B beacon locked Beacon locked Beacon lost

Gateway state available Available RX1 busy, try RX2 Capacity delay

Ready: inspect scheduler timing

Watch For

Class A waitsA downlink follows an uplink. No uplink means no RX1/RX2 opportunity.

Class B plansPing slots give scheduled receive chances while the beacon is locked.

Class C listensLow latency is possible because the receiver is almost always on.

Capacity mattersSlow data rates and busy gateways make downlink scarce.

Server Queue And Receive Opportunities

Class A queue

1. Queuecommand accepted

2. Classreceive mode checked

3. Windownext chance found

4. Capacitypriority and gateway checked

5. Outcomesend, hold, or expire

Class Profiles

Readouts

Class Aactive receive strategy

queued at 24 sserver queue event

RX1 at 61 sselected transmit opportunity

37 s waitdownlink queue latency

185 ms airtimerough LoRa PHY airtime

server holds messageoperational implication

Diagnosis

Step Transcript

Quick Reference

RX1For Class A, RX1 opens after the uplink receive delay. The downlink normally uses a data rate derived from the uplink data rate and RX1 offset.

RX2RX2 is the second Class A chance after the uplink. Its frequency and data rate are region parameters and can be changed by MAC commands.

PriorityMAC commands and urgent control traffic often outrank routine application data, but every downlink still consumes scarce gateway airtime.

Technical Accuracy Notes

Class A ruleThe network server cannot wake a sleeping Class A device at an arbitrary time.downlink chance = uplink end + RX delay

Airtime modelThe shown airtime is a teaching estimate for LoRa modulation at 125 kHz bandwidth and coding rate 4/5.T_symbol = 2^SF / bandwidth

Capacity cautionA long downlink may be valid at the receive opportunity but still poor network practice because it occupies the gateway and can hit regional limits.scarcity rises with slow SF and large payload

• Receive delays, RX2 frequency, RX2 data rate, dwell-time, and duty-cycle rules are regional. This workbench keeps the timing model visible rather than simulating one complete regional parameter set.
• The visual RX markers represent scheduled receive opportunities. They are not arbitrary large file-transfer windows.
• Official references: LoRaWAN Specification v1.0.4 and TR007 Developing LoRaWAN Devices.

Related Animations

LoRaWAN Device ClassesCompare Class A, B, and C receive behavior. LoRaWAN ADRSee how data rate choices affect link behavior. Duty-Cycle CalculatorConnect gateway airtime to regulatory limits.