El servidor de red gestiona la configuración de radio de cada dispositivo con comandos MAC: instrucciones breves que viajan en los downlinks y respuestas que viajan en los uplinks. El más importante es la velocidad de datos adaptativa (ADR). Esta página explica qué hace el servidor de red por sí mismo y cómo influir en ello desde el perfil.
Velocidad de datos adaptativa (ADR)
Un dispositivo cercano a una pasarela no necesita la velocidad de datos más lenta y de mayor alcance. ADR lo pasa a una velocidad de datos más rápida y a una potencia de transmisión menor, lo que ahorra batería y tiempo de emisión y deja espacio para otros dispositivos.
ADR se ejecuta cuando se cumplen ambas condiciones:
- Velocidad de datos adaptativa (ADR) está activada en el perfil del dispositivo (activada por defecto).
- El propio dispositivo solicita ADR en sus uplinks (la mayoría de los dispositivos lo hacen).
Cómo se decide un cambio
- Para cada uplink, el servidor de red anota la mejor SNR entre todas las pasarelas que lo recibieron.
- Una vez que tiene 20 uplinks, toma la mejor SNR de esos 20.
- Margen = esa SNR − la SNR que necesita la velocidad de datos actual − el margen de instalación (10 dB por defecto, ajuste de API
installationMarginDb, 0–30). - Cada 3 dB completos de margen equivalen a un paso. Los pasos primero suben la velocidad de datos, hasta la Velocidad de datos más alta (DR) del perfil; los pasos restantes bajan la potencia de transmisión 2 dB cada uno.
- El servidor de red nunca aumenta la potencia de un dispositivo ni baja su velocidad de datos por debajo de la actual.
- El cambio se envía como LinkADRReq. Cuando el dispositivo lo acepta, el historial se reinicia y no se hace ningún cambio nuevo durante los siguientes 20 uplinks.
Cuando se acepta un cambio, se actualizan los atributos del dispositivo lora.dr y lora.txPower.
Ajustes del perfil
| Campo | Por defecto | Efecto |
|---|---|---|
| Velocidad de datos adaptativa (ADR) | Activada | Desactivada: el servidor de red nunca envía cambios de ADR. |
| Velocidad de datos más baja (DR) | DR0 | El mínimo que mantiene ADR. |
| Velocidad de datos más alta (DR) | DR5 | El máximo al que ADR lleva los dispositivos. |
Desactive ADR en los dispositivos que se mueven (rastreadores): su señal cambia más rápido que 20 uplinks.
Otras acciones que el servidor de red realiza por sí mismo
| Acción | Cuándo |
|---|---|
| Establece el retardo de RX1 (RXTimingSetupReq) | Cuando el retardo de RX1 del dispositivo difiere del del perfil, por ejemplo un dispositivo ABP que arranca con 1 s. Se repite hasta que el dispositivo confirma. |
| Establece el desplazamiento de RX1 y RX2 (RXParamSetupReq) | Cuando los valores del dispositivo difieren de los del perfil. |
| Solicita batería y margen de enlace (DevStatusReq) | Después de cada unión y luego cada 24 horas (ajuste de API devStatusIntervalH, 0 = nunca). |
| Establece un límite agregado de ciclo de trabajo (DutyCycleReq) | Solo cuando el ajuste de API maxDutyCycle es superior a 0. |
| Responde a las comprobaciones de enlace (LinkCheckAns) | Cuando el dispositivo lo pide; le indica el margen y cuántas pasarelas lo recibieron. |
| Responde a las solicitudes de hora (DeviceTimeAns) | Cuando el dispositivo pide la hora de la red. |
La batería y el margen del dispositivo llegan como telemetría en el siguiente mensaje cuando Añadir los valores de radio está activado: lora.battery_level (0–100 %, ausente en dispositivos alimentados externamente o cuando se desconoce) y lora.margin_db (el margen de enlace medido por el dispositivo, de −32 a 31 dB).
Cómo se entregan los comandos MAC
- Las respuestas van primero, y después las solicitudes pendientes, en la cabecera del downlink (hasta 15 bytes). Cuando hay más pendiente de lo que cabe, los comandos se envían en FPort 0 en su lugar, y su downlink de aplicación espera a la siguiente ventana.
- Una solicitud pendiente se reenvía con cada downlink hasta que el dispositivo responde, como máximo 3 veces; después se descarta.
- El servidor de red responde a un uplink aunque no tenga datos de aplicación cuando hay una respuesta MAC pendiente o cuando el dispositivo solicita un acuse de recibo de su ADR (ADRACKReq).
- Los comandos MAC nunca bloquean un downlink de aplicación durante mucho tiempo: cuando caben ambos, se envían los dos.
Comandos MAC compatibles (LoRaWAN 1.0.x)
| Comando | Sentido | Compatible |
|---|---|---|
| LinkCheckReq / LinkCheckAns | El dispositivo pregunta, la red responde | Sí |
| LinkADRReq / LinkADRAns | La red pregunta, el dispositivo responde | Sí |
| DutyCycleReq / DutyCycleAns | La red pregunta | Sí (solo cuando maxDutyCycle > 0) |
| RXParamSetupReq / RXParamSetupAns | La red pregunta | Sí |
| DevStatusReq / DevStatusAns | La red pregunta | Sí |
| NewChannelReq / NewChannelAns | La red pregunta | Las respuestas se interpretan |
| RXTimingSetupReq / RXTimingSetupAns | La red pregunta | Sí |
| DlChannelReq / DlChannelAns | La red pregunta | Las respuestas se interpretan |
| DeviceTimeReq / DeviceTimeAns | El dispositivo pregunta, la red responde | Sí |
| TxParamSetupReq | La red pregunta | No se usa en EU868 |
| Comandos de clase B (PingSlot, Beacon) | — | No compatible |
| Comandos de LoRaWAN 1.1 (Rekey, Rejoin, ResetInd) | — | No compatible |
Un comando desconocido en un uplink detiene la lectura del resto de comandos MAC de ese uplink, como exige la especificación LoRaWAN.