In LoRaWAN networks, a common question arises: who decides a device's data rate (spreading factor, bandwidth)? The device itself, or the network? The answer is both, but the network server holds the reins — that's the ADR (Adaptive Data Rate) mechanism.
This article breaks down how ADR works, its decision logic, and its practical constraints.
LoRaWAN uses different spreading factor (SF7–SF12) and bandwidth (125/250/500 kHz) combinations to define data rates (Data Rate, DR). Low rates (e.g., SF12) offer longer range and stronger interference resilience, but consume more airtime and reduce network capacity. High rates (e.g., SF7) minimize airtime and maximize capacity, but reduce range.
The challenge: within a single LoRaWAN network, devices are at varying distances from gateways, with different channel conditions. If all devices use one fixed rate, either far-away devices can't connect, or near-by devices waste airtime.
ADR lets the network server dynamically adjust each device's data rate and transmit power based on its link quality — devices with good signal get higher rates (saving airtime, boosting capacity), while devices with poor signal get lower rates (ensuring reliable connectivity).
ADR's decision authority is split as follows:
| Role | What They Control | Trigger |
|---|---|---|
| Network Server | Computes optimal DR and Tx power, sends ADR commands | Device enables ADR (ADR bit = 1) |
| Device | Executes received ADR commands; may autonomously lower DR when mobile | Receives LinkADRReq MAC command |
Key point: ADR is network-server-driven. The device sets the ADR bit (0 or 1) in each uplink frame's MAC header to tell the network: "I want you to manage my data rate." Once ADR is set to 1, the network server begins collecting link quality data (SNR margin) for that device, computes optimal parameters, and sends adjustments via the LinkADRReq MAC command.
The device can also do one thing locally: if it detects that it's moving (e.g., via an accelerometer detecting motion state changes), it can temporarily ignore ADR commands from the network and select a more robust rate on its own. This is the "device mobility" influence on ADR defined in the LoRaWAN specification.
ADR is not a standardized, fixed algorithm — the LoRa Alliance specification defines the interface and behavior, while the specific algorithm is implemented by each network server. But the general flow is consistent:
Device uplink (ADR = 1)
↓
Gateway receives, records SNR and RSSI
↓
Network server collects sufficient samples (typically ≥ 20 uplink frames)
↓
Compute SNR margin = measured SNR − minimum required SNR for current DR
↓
Select highest DR where SNR margin ≈ 0 (i.e., the fastest rate that's just sufficient)
↓
Generate LinkADRReq command (with DR, TxPower, ChMask)
↓
Send via downlink frame to device
↓
Device executes, responds with LinkADRAns (success/failure)
The network server doesn't look at a single frame's SNR — it collects a batch of uplink frames' SNR statistics (typically the maximum or a certain percentile), then computes the "margin":
The minimum SNR requirement varies by DR (SF12 needs approximately −20 dB, SF7 needs approximately −7.5 dB; exact values depend on the chipset and implementation).
| Field | Bits | Meaning |
|---|---|---|
| DR | 4 | Target data rate index (0–15) |
| TxPower | 4 | Transmit power index (0–15, 0 = max) |
| ChMask | 16 | Channel mask, enable/disable specific channels |
| Redundancy | 4 | ChMask offset + NbRep (repetition count) |
The device responds with LinkADRAns, containing status bits indicating whether execution succeeded.
ADR has a self-protection mechanism: if the device hasn't received a downlink from the network for an extended period, it can't confirm whether the network is still managing its rate. At that point, the device sets the ADRACKReq bit.
Device enables ADR and starts counting
↓
Sends ADR_ACK_LIMIT uplink frames (default 64) without receiving any downlink
↓
Sets ADRACKReq = 1
↓
Continues sending ADR_ACK_DELAY uplink frames (default 32)
↓
If still no downlink → reverts to default DR (region's lowest DR)
The design intent: if the network server goes "offline," the device automatically switches to the most robust rate, ensuring that even without ADR management, uplink frames can still be received.
Note: The default values for ADR_ACK_LIMIT and ADR_ACK_DELAY are 64 and 32, but the network server can adjust these via parameters in the LinkADRReq command (LoRaWAN 1.0.4 / 1.1 and above).
ADR's adjustment range is constrained by each region's Regional Parameters definition. Below are DR mappings for major regions:
| DR | Modulation | SF | BW | Bit Rate |
|---|---|---|---|---|
| 0 | LoRa | 12 | 125 kHz | 250 bps |
| 1 | LoRa | 11 | 125 kHz | 440 bps |
| 2 | LoRa | 10 | 125 kHz | 980 bps |
| 3 | LoRa | 9 | 125 kHz | 1760 bps |
| 4 | LoRa | 8 | 125 kHz | 3125 bps |
| 5 | LoRa | 7 | 125 kHz | 5470 bps |
| 6 | LoRa | 7 | 250 kHz | 11000 bps |
| 7 | FSK | — | — | 50000 bps |
ADR adjustment range: DR0–DR5 (SF12/SF125k to SF7/SF125k). DR6 and DR7 are typically not included in the default ADR range.
| DR | Modulation | SF | BW |
|---|---|---|---|
| 0 | LoRa | 10 | 125 kHz |
| 1 | LoRa | 9 | 125 kHz |
| 2 | LoRa | 8 | 125 kHz |
| 3 | LoRa | 7 | 125 kHz |
| 4 | LoRa | 8 | 500 kHz |
| 5–7 | LoRa | — | 500 kHz (higher SF combos) |
| 8–13 | LoRa | — | 500 kHz |
US915's ADR range is DR0–DR3 (125 kHz sub-bands). DR4 and above are 500 kHz fast channels.
Dwell Time Limit: US915 and AU915 regions have a "dwell time" limit — transmit time per sub-band must not exceed 400 ms. This means using SF12 (airtime ~1.5 seconds) triggers the dwell time constraint, affecting ADR's rate selection. The network server must factor this constraint into ADR calculations.
| DR | Modulation | SF | BW |
|---|---|---|---|
| 0 | LoRa | 12 | 125 kHz |
| 1 | LoRa | 11 | 125 kHz |
| 2 | LoRa | 10 | 125 kHz |
| 3 | LoRa | 9 | 125 kHz |
| 4 | LoRa | 8 | 125 kHz |
| 5 | LoRa | 7 | 125 kHz |
CN470's ADR range is DR0–DR5, similar to EU868 but not identical.
AS923's DR table is essentially the same as EU868 (DR0–DR7), but AS923 has sub-regional variants such as AS923-2, AS923-3, AS923-4, each with different frequency ranges and some DR parameter differences. The ADR adjustment range is typically DR2–DR5 (some variants allow a wider range).
ADR Backoff is a supplementary mechanism introduced in LoRaWAN 1.0.4, designed to prevent devices from requesting ADR adjustments too frequently, which would cause downlink traffic overload.
Consider: a network has 10,000 devices, each uplinking every 5 minutes. If each device triggers an ADR adjustment on every uplink, the network server would need to send downlink MAC commands for every device — infeasible under LoRaWAN's downlink duty cycle constraints (gateway downlink duty cycle is limited).
Note: The specific parameters for ADR Backoff vary by network server implementation. The LoRa Alliance specification defines the behavioral framework, while individual vendors (ChirpStack, TTN, ThinkLink, etc.) differ in implementation details.
Mobile devices are an important edge case for ADR.
Most LoRaWAN devices are static (fixed installations in buildings, factories, farmland, etc.), with relatively stable link conditions. ADR can work to its full potential — the network server collects data over a period and makes optimizations, and the device maintains the optimal rate long-term.
If the device is moving (e.g., asset tracking, logistics tracking), link conditions change rapidly with location: - When a device moves from near a gateway to far away, the previously ADR-set high rate may cause packet loss - The SNR data collected by the network server is "stale"
The LoRaWAN specification's recommendation: mobile devices should disable ADR (ADR = 0) and use a fixed robust rate (e.g., SF11 or SF12). Alternatively, the device implements local ADR logic — autonomously lowering rate when motion is detected, and re-enabling network ADR when stationary.
Some network servers (e.g., ChirpStack) implement "mobility detection" functionality, automatically determining whether a device is moving by analyzing SNR variation rate, and dynamically adjusting ADR strategy.
Misconception 1: "ADR always picks the highest rate"
Wrong. ADR selects the "highest rate that's just sufficient" — the DR where SNR margin is near zero. If link conditions aren't good enough, ADR will select a lower rate.
Misconception 2: "Disabling ADR saves power"
Usually the opposite. With ADR enabled, devices with good signal get bumped to higher rates (e.g., SF7), reducing airtime from ~1.5 seconds (SF12) to ~0.05 seconds (SF7) — 30× shorter transmit time, dramatically lower power consumption. Disabling ADR and fixing at SF12 actually wastes more power.
Misconception 3: "ADR covers all regions automatically"
It doesn't. ADR only adjusts within the current region's DR range. When roaming across regions, the device must first execute a region-switching procedure, and ADR parameters are reset.
If a device's rate never changes after enabling ADR, check:
The ThinkLink IoT platform supports ADR functionality:
If you use a third-party network server (e.g., ChirpStack, TTN) with the GD6 gateway, ADR is handled by that network server's algorithm. The GD6 as a gateway only forwards uplink/downlink frames and does not participate in ADR decisions.
| Key Point | Description |
|---|---|
| What is ADR | Network server dynamically adjusts DR and Tx power based on device link quality |
| Who controls | Network server leads, device executes |
| Core metric | SNR margin (measured SNR − minimum SNR for the DR) |
| Adjustment range | DR range defined by each region's Regional Parameters |
| Mobile devices | Recommend disabling ADR or implementing local ADR |
| Power saving | ADR's rate increase shortens airtime, reducing transmit power |
| ADRACKReq | Device requests network confirmation after long downlink silence; otherwise reverts to lowest DR |
ADR is the cornerstone of LoRaWAN capacity management — without ADR, a network must either sacrifice coverage (all devices use high rates) or sacrifice capacity (all devices use low rates). Understanding how ADR works is the prerequisite for effective LoRaWAN network planning and device management.
Related Reading:
ManThink — Making IoT development more efficient.