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.
The Problem ADR Solves
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).
Who Controls the Data Rate
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 Algorithm Workflow
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)
SNR Margin: The Core Metric
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":
- Large positive margin → link quality exceeds what current DR requires; speed can be increased
- Margin near zero → current DR is just right
- Negative margin → link quality insufficient for current DR; speed needs to decrease
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).
LinkADRReq Command Fields
| 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.
ADRACKReq: How the Device "Nudges" the Network
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.
Timeline
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).
DR Ranges by Region
ADR's adjustment range is constrained by each region's Regional Parameters definition. Below are DR mappings for major regions:
EU868
| 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.
US915
| 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.
CN470
| 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
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
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.
The Problem
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).
How Backoff Works
- ADR adjustment frequency is limited: The network server doesn't adjust ADR on every uplink — it sets a minimum interval (e.g., once every N uplink frames)
- Delayed confirmation for unfavorable adjustments: If the computed ADR adjustment is unfavorable for the device (e.g., rate decrease), the device delays confirmation, giving the network more time to evaluate
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.
ADR and Device Mobility
Mobile devices are an important edge case for ADR.
Static Devices
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.
Mobile Devices
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.
Practical Recommendations
When to Enable ADR
- Static devices → Enable ADR, let the network optimize rate
- Mobile devices → Disable ADR, use a fixed robust rate; or implement local ADR
- Battery-powered devices → Enable ADR (higher rate = shorter airtime = less transmit energy)
- Newly deployed devices → Start with a low DR, enable ADR after confirming connectivity
Common Misconceptions
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.
Debugging
If a device's rate never changes after enabling ADR, check:
- Insufficient uplink frames → Network server needs enough samples (typically ≥ 20) to compute ADR; confirm uplink frequency is adequate
- ADR bit not set → Confirm the device's uplink frame has ADR bit = 1
- Extreme link quality → If SNR margin is consistently very large or very small, ADR may determine no adjustment is needed
- Network server doesn't support ADR → Confirm the connected network server implements an ADR algorithm (most mainstream NS do)
- Regional constraints → Certain DRs may be unavailable in some regions (e.g., dwell time limits)
Integration with ThinkLink Platform
The ThinkLink IoT platform supports ADR functionality:
- LoRaWAN devices registered on ThinkLink have ADR management enabled by default
- The platform collects SNR/RSSI data from device uplink frames via gateways and automatically computes optimal DR
- Device ADR status, current DR, SNR margin, etc., can be viewed in the ThinkLink console
- For the GD6 open-source gateway, ADR data comes from statistics reported by the SX1301/SX1302 concentrator, transmitted back to the platform via Packet Forwarder / MQTT Bridge / Basic Station protocol
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.
Summary
| 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:
- LoRaWAN Device Activation Explained: OTAA vs ABP — Part 1 of this series
- GD6 Open-Source Gateway Documentation: think-link.net/docs/zh/Device/LoRaWANGateway/gd61x-user-guide
- LoRaWAN Regional Parameters Specification: lora-alliance.org
ManThink — Making IoT development more efficient.