En las redes LoRaWAN, surge una pregunta común: ¿quién decide la tasa de datos de un dispositivo (factor de dispersión, ancho de banda)? ¿El propio dispositivo o la red? La respuesta es ambos, pero el servidor de red lleva las riendas: ese es el mecanismo ADR (Adaptive Data Rate, tasa de datos adaptativa).

Este artículo desglosa cómo funciona el ADR, su lógica de decisión y sus limitaciones prácticas.

El problema que resuelve el ADR

LoRaWAN utiliza diferentes combinaciones de factor de dispersión (SF7–SF12) y ancho de banda (125/250/500 kHz) para definir las tasas de datos (Data Rate, DR). Las tasas bajas (p. ej., SF12) ofrecen mayor alcance y mayor resistencia a las interferencias, pero consumen más tiempo de aire y reducen la capacidad de la red. Las tasas altas (p. ej., SF7) minimizan el tiempo de aire y maximizan la capacidad, pero reducen el alcance.

El desafío: dentro de una misma red LoRaWAN, los dispositivos se encuentran a distintas distancias de las pasarelas, con diferentes condiciones de canal. Si todos los dispositivos usan una tasa fija, o los dispositivos lejanos no pueden conectarse, o los dispositivos cercanos desperdician tiempo de aire.

El ADR permite que el servidor de red ajuste dinámicamente la tasa de datos y la potencia de transmisión de cada dispositivo según la calidad de su enlace: los dispositivos con buena señal obtienen tasas más altas (ahorrando tiempo de aire, aumentando la capacidad), mientras que los dispositivos con mala señal obtienen tasas más bajas (garantizando una conectividad fiable).

Quién controla la tasa de datos

La autoridad de decisión del ADR se divide de la siguiente manera:

Punto clave: el ADR está dirigido por el servidor de red. El dispositivo establece el bit ADR (0 o 1) en la cabecera MAC de cada trama de enlace ascendente para indicar a la red: «Quiero que gestiones mi tasa de datos». Una vez que el ADR se establece en 1, el servidor de red comienza a recopilar datos de calidad del enlace (margen de SNR) para ese dispositivo, calcula los parámetros óptimos y envía los ajustes mediante el LinkADRReq comando MAC.

El dispositivo también puede hacer una cosa localmente: si detecta que se está moviendo (p. ej., mediante un acelerómetro que detecta cambios en el estado de movimiento), puede ignorar temporalmente los comandos ADR de la red y seleccionar por sí mismo una tasa más robusta. Esta es la influencia de la «movilidad del dispositivo» en el ADR definida en la especificación LoRaWAN.

Flujo de trabajo del algoritmo ADR

El ADR no es un algoritmo estandarizado y fijo: la especificación de la LoRa Alliance define la interfaz y el comportamiento, mientras que el algoritmo específico lo implementa cada servidor de red. Pero el flujo general es consistente:

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)

Margen de SNR: la métrica central

El servidor de red no observa el SNR de una sola trama: recopila estadísticas de SNR de un lote de tramas de enlace ascendente (normalmente el máximo o un determinado percentil) y luego calcula el «margen»:

• Margen positivo grande → la calidad del enlace supera lo que requiere la DR actual; se puede aumentar la velocidad
• Margen cercano a cero → la DR actual es la adecuada
• Margen negativo → la calidad del enlace es insuficiente para la DR actual; es necesario reducir la velocidad

El requisito mínimo de SNR varía según la DR (SF12 necesita aproximadamente −20 dB, SF7 necesita aproximadamente −7.5 dB; los valores exactos dependen del chipset y de la implementación).

Campos del comando LinkADRReq

El dispositivo responde con LinkADRAns, que contiene bits de estado que indican si la ejecución se realizó correctamente.

ADRACKReq: cómo el dispositivo «presiona» a la red

El ADR tiene un mecanismo de autoprotección: si el dispositivo no ha recibido un enlace descendente de la red durante un periodo prolongado, no puede confirmar si la red sigue gestionando su tasa. En ese momento, el dispositivo establece el bit ADRACKReq .

Cronología

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)

La intención del diseño: si el servidor de red se «desconecta», el dispositivo cambia automáticamente a la tasa más robusta, garantizando que, incluso sin gestión ADR, las tramas de enlace ascendente aún puedan recibirse.

Nota: Los valores predeterminados de ADR_ACK_LIMIT y ADR_ACK_DELAY son 64 y 32, pero el servidor de red puede ajustarlos mediante parámetros en el LinkADRReq comando (LoRaWAN 1.0.4 / 1.1 y superiores).

Rangos de DR por región

El rango de ajuste del ADR está limitado por la definición de Parámetros Regionales de cada región. A continuación se muestran las asignaciones de DR para las principales regiones:

EU868

Rango de ajuste de ADR: DR0–DR5 (SF12/SF125k a SF7/SF125k). DR6 y DR7 normalmente no se incluyen en el rango de ADR predeterminado.

US915

El rango de ADR de US915 es DR0–DR3 (subbandas de 125 kHz). DR4 y superiores son canales rápidos de 500 kHz.

Límite de tiempo de permanencia: Las regiones US915 y AU915 tienen un límite de "tiempo de permanencia": el tiempo de transmisión por subbanda no debe superar 400 ms. Esto significa que usar SF12 (tiempo en el aire ~1.5 segundos) activa la restricción de tiempo de permanencia, lo que afecta la selección de tasa de ADR. El servidor de red debe tener en cuenta esta restricción en los cálculos de ADR.

CN470

El rango ADR de CN470 es DR0–DR5, similar a EU868 pero no idéntico.

AS923

La tabla de DR de AS923 es esencialmente la misma que la de EU868 (DR0–DR7), pero AS923 tiene variantes subregionales como AS923-2, AS923-3, AS923-4, cada una con rangos de frecuencia diferentes y algunas diferencias en los parámetros de DR. El rango de ajuste de ADR suele ser DR2–DR5 (algunas variantes permiten un rango más amplio).

Backoff de ADR

El Backoff de ADR es un mecanismo complementario introducido en LoRaWAN 1.0.4, diseñado para evitar que los dispositivos soliciten ajustes de ADR con demasiada frecuencia, lo que provocaría una sobrecarga del tráfico de enlace descendente.

El problema

Considere: una red tiene 10,000 dispositivos, cada uno transmitiendo en enlace ascendente cada 5 minutos. Si cada dispositivo activara un ajuste de ADR en cada enlace ascendente, el servidor de red tendría que enviar comandos MAC de enlace descendente para cada dispositivo — inviable bajo las restricciones del ciclo de trabajo de enlace descendente de LoRaWAN (el ciclo de trabajo de enlace descendente del gateway es limitado).

Cómo funciona el Backoff

• Se limita la frecuencia de ajuste de ADR: El servidor de red no ajusta el ADR en cada enlace ascendente — establece un intervalo mínimo (p. ej., una vez cada N tramas de enlace ascendente)
• Confirmación diferida para ajustes desfavorables: Si el ajuste de ADR calculado es desfavorable para el dispositivo (p. ej., reducción de la tasa), el dispositivo retrasa la confirmación, dando a la red más tiempo para evaluar

Nota: Los parámetros específicos del Backoff de ADR varían según la implementación del servidor de red. La especificación de LoRa Alliance define el marco de comportamiento, mientras que los distintos proveedores (ChirpStack, TTN, ThinkLink, etc.) difieren en los detalles de implementación.

ADR y movilidad del dispositivo

Los dispositivos móviles son un caso límite importante para el ADR.

Dispositivos estáticos

La mayoría de los dispositivos LoRaWAN son estáticos (instalaciones fijas en edificios, fábricas, tierras de cultivo, etc.), con condiciones de enlace relativamente estables. El ADR puede funcionar a su máximo potencial — el servidor de red recopila datos durante un periodo y realiza optimizaciones, y el dispositivo mantiene la tasa óptima a largo plazo.

Dispositivos móviles

Si el dispositivo está en movimiento (p. ej., seguimiento de activos, seguimiento logístico), las condiciones de enlace cambian rápidamente con la ubicación: - Cuando un dispositivo se aleja de un gateway, la alta tasa previamente establecida por ADR puede provocar pérdida de paquetes - Los datos de SNR recopilados por el servidor de red están "desactualizados"

La recomendación de la especificación LoRaWAN: los dispositivos móviles deben deshabilitar el ADR (ADR = 0) y usar una tasa robusta fija (p. ej., SF11 o SF12). Alternativamente, el dispositivo implementa lógica ADR local — reduciendo autónomamente la tasa cuando se detecta movimiento, y volviendo a habilitar el ADR de red cuando está estacionario.

Algunos servidores de red (p. ej., ChirpStack) implementan la funcionalidad de "detección de movilidad", determinando automáticamente si un dispositivo se está moviendo mediante el análisis de la tasa de variación de SNR, y ajustando dinámicamente la estrategia de ADR.

Recomendaciones prácticas

Cuándo habilitar el ADR

• Dispositivos estáticos → Habilitar ADR, dejar que la red optimice la tasa
• Dispositivos móviles → Deshabilitar ADR, usar una tasa robusta fija; o implementar ADR local
• Dispositivos alimentados por batería → Habilitar ADR (mayor tasa = menor tiempo en el aire = menor energía de transmisión)
• Dispositivos recién desplegados → Comenzar con un DR bajo, habilitar ADR tras confirmar la conectividad

Conceptos erróneos comunes

Concepto erróneo 1: "El ADR siempre elige la tasa más alta"

Incorrecto. El ADR selecciona la "tasa más alta que sea justo suficiente" — el DR en el que el margen de SNR está cerca de cero. Si las condiciones de enlace no son suficientemente buenas, el ADR seleccionará una tasa más baja.

Concepto erróneo 2: "Deshabilitar el ADR ahorra energía"

Normalmente ocurre lo contrario. Con el ADR habilitado, los dispositivos con buena señal pasan a tasas más altas (p. ej., SF7), reduciendo el tiempo en el aire de ~1.5 segundos (SF12) a ~0.05 segundos (SF7) — un tiempo de transmisión 30× más corto, con un consumo de energía drásticamente menor. Deshabilitar el ADR y fijar SF12 en realidad desperdicia más energía.

Concepto erróneo 3: "El ADR cubre todas las regiones automáticamente"

No es así. El ADR solo ajusta dentro del rango de DR de la región actual. Al hacer roaming entre regiones, el dispositivo debe ejecutar primero un procedimiento de cambio de región, y los parámetros de ADR se restablecen.

Depuración

Si la tasa de un dispositivo nunca cambia tras habilitar el ADR, compruebe:

1. Tramas de enlace ascendente insuficientes → El servidor de red necesita suficientes muestras (normalmente ≥ 20) para calcular el ADR; confirme que la frecuencia de enlace ascendente es adecuada
2. Bit de ADR no establecido → Confirme que la trama de enlace ascendente del dispositivo tiene el bit de ADR = 1
3. Calidad de enlace extrema → Si el margen de SNR es consistentemente muy grande o muy pequeño, el ADR puede determinar que no se necesita ajuste
4. El servidor de red no admite ADR → Confirme que el servidor de red conectado implementa un algoritmo de ADR (la mayoría de los NS principales lo hacen)
5. Restricciones regionales → Ciertos DR pueden no estar disponibles en algunas regiones (p. ej., límites de tiempo de permanencia)

Integración con la plataforma ThinkLink

La plataforma IoT ThinkLink admite la funcionalidad de ADR:

• Los dispositivos LoRaWAN registrados en ThinkLink tienen la gestión de ADR habilitada por defecto
• La plataforma recopila datos de SNR/RSSI de las tramas de enlace ascendente de los dispositivos a través de los gateways y calcula automáticamente el DR óptimo
• El estado de ADR del dispositivo, el DR actual, el margen de SNR, etc., se pueden consultar en la consola de ThinkLink
• Para el gateway de código abierto GD6, los datos de ADR provienen de las estadísticas reportadas por el concentrador SX1301/SX1302, transmitidas de vuelta a la plataforma mediante el protocolo Packet Forwarder / MQTT Bridge / Basic Station

Si utiliza un servidor de red de terceros (p. ej., ChirpStack, TTN) con el gateway GD6, el ADR lo gestiona el algoritmo de ese servidor de red. El GD6 como gateway solo reenvía tramas de enlace ascendente/descendente y no participa en las decisiones de ADR.

Resumen

ADR es la piedra angular de la gestión de capacidad de LoRaWAN — sin ADR, una red debe sacrificar cobertura (todos los dispositivos usan tasas altas) o sacrificar capacidad (todos los dispositivos usan tasas bajas). Comprender cómo funciona ADR es el requisito previo para una planificación eficaz de la red LoRaWAN y la gestión de dispositivos.

Lectura relacionada:

• Activación de dispositivos LoRaWAN explicada: OTAA vs ABP — Parte 1 de esta serie
• Documentación de la puerta de enlace de código abierto GD6: think-link.net/docs/zh/Device/LoRaWANGateway/gd61x-user-guide
• Especificación de Parámetros Regionales de LoRaWAN: lora-alliance.org

ManThink — Haciendo el desarrollo de IoT más eficiente.