Es una de las primeras sorpresas de quien diseña una red LoRaWAN: un nodo no puede transmitir cuando quiera ni todo lo que quiera. Hay reglas —algunas del regulador, otras del propio protocolo— que limitan cuánto tiempo puede estar “hablando” un dispositivo. Entender el duty cycle y el Time on Air (ToA) es la diferencia entre una red que escala a cientos de nodos y una que se satura con los primeros veinte.
Qué es el Time on Air
El Time on Air es, literalmente, el tiempo que un paquete ocupa el canal de radio: desde el primer símbolo del preámbulo hasta el último bit del payload. No es un concepto exclusivo de LoRaWAN, pero en LoRa es especialmente sensible porque depende directamente del Spreading Factor (SF) que use el nodo.
Como ya explicamos al detalle en el artículo sobre Spreading Factor, alcance y batería, un paquete de 20 bytes tarda unos 70 ms en aire con SF7 y hasta 1.800 ms con SF12: 25 veces más. Ese tiempo en aire no solo consume batería —también es el tiempo durante el cual el nodo ocupa el canal y ningún otro nodo puede transmitir en él sin colisionar.
Por eso el ToA es la base de casi todas las restricciones regulatorias y de diseño que vienen a continuación: cuanto más alto el SF, más caro sale cada mensaje en términos de espacio de radio compartido.
Duty cycle: la regla europea que no aplica en Ecuador
El duty cycle es un límite regulatorio sobre qué fracción del tiempo puede transmitir un dispositivo en una banda ISM. En Europa (banda EU868), el regulador (ETSI EN 300.220) exige un duty cycle máximo de 1% en la mayoría de subbandas (algunas van a 0,1% o 10%). Con 1%, un nodo puede transmitir un máximo de 36 segundos por hora en ese canal, sin importar cuántos paquetes reparta en ese tiempo.
Esta es la regla que suele generar confusión, porque mucha documentación de LoRaWAN en internet está escrita pensando en EU868. En Ecuador esa regla no aplica. Ecuador opera bajo el plan de frecuencias AU915 (915–928 MHz, compartido con Australia y buena parte de Sudamérica), regulado localmente por ARCOTEL bajo un esquema equivalente al de la FCC estadounidense: no existe un límite de duty cycle. Un nodo en AU915 puede, en teoría, transmitir con mucha más frecuencia que uno en Europa sin infringir ninguna norma de tiempo de ocupación por hora.
Lo que sí limita AU915: el dwell time
Que no haya duty cycle no significa que todo esté permitido. La banda AU915/US915 impone otra restricción: el dwell time, un máximo de 400 ms de tiempo en aire por transmisión en un mismo canal. Es una regla que viene del uso de bandas de salto de frecuencia (frequency hopping) típico de la normativa FCC.
Esto tiene una consecuencia técnica directa: con paquetes largos y SF alto (SF11 o SF12), el tiempo en aire puede superar los 400 ms y violar el límite de dwell time. La solución que usa el estándar LoRaWAN en AU915 es activar automáticamente el modo de codificación LDRO (Low Data Rate Optimization) y ajustar el tamaño máximo de payload permitido según el SF, precisamente para mantener cada transmisión dentro del límite. Es una de las razones por las que, en la práctica, los payloads muy grandes (>50-100 bytes) casi nunca se usan con SF11/SF12 en esta región.
En resumen, para un despliegue en Ecuador el parámetro que hay que vigilar de cerca no es el duty cycle (no existe), sino el ToA por transmisión —limitado a 400 ms por el dwell time— y el efecto acumulado de ese ToA sobre la capacidad total del canal.
Fair Access Policy: la regla que sí aplica, venga o no de la región
Aunque AU915 no tenga duty cycle regulatorio, la mayoría de los despliegues en Ecuador usan un network server como ChirpStack o se conectan a The Things Network (TTN), y ahí aparece una tercera capa de restricción: la Fair Access Policy (FAP), una política del operador de la red, no del regulador.
TTN, por ejemplo, limita el uso justo del canal a 30 segundos de tiempo en aire de subida por dispositivo por día, independientemente de la región o del duty cycle legal. Es una regla pensada para que ningún nodo acapare la capacidad de un gateway compartido. Si su despliegue usa ChirpStack en infraestructura propia (como suele ser el caso en redes privadas industriales o agrícolas), esta política no aplica automáticamente, pero sigue siendo una buena referencia de diseño: si un nodo necesita más de 30 segundos de ToA acumulado al día, probablemente esté transmitiendo con más frecuencia o con un SF más alto de lo necesario.
Ya cubrimos cómo se explica esa relación entre network server y gestión de la red en el artículo sobre qué es un network server LoRaWAN (ChirpStack, TTN).
Cuánta capacidad tiene realmente un canal
El ToA acumulado de todos los nodos de una red determina cuántos dispositivos caben en un gateway sin generar colisiones excesivas. Un cálculo de referencia con un ejemplo concreto:
- Un nodo transmitiendo cada 10 minutos con SF9 (ToA ≈ 250 ms) genera 144 paquetes/día × 250 ms = 36 segundos de ToA diario.
- El mismo nodo con SF7 (ToA ≈ 70 ms) genera solo ~10 segundos de ToA diario: 3,6 veces menos ocupación de canal por el mismo volumen de datos.
Esto explica por qué el ADR (Adaptive Data Rate) —que ya cubrimos en el artículo de Spreading Factor— no solo ahorra batería: también libera capacidad de canal para que la red admita más nodos. Una red con 500 sensores de humedad de suelo transmitiendo cada 15 minutos con SF7-SF8 tiene una carga de canal manejable; la misma red forzada a SF12 saturaría el gateway mucho antes de llegar a esa cantidad de dispositivos.
Cómo diseñar el intervalo de transmisión con esto en mente
Al dimensionar la frecuencia de reporte de un nodo —por ejemplo, un Sensor HUB midiendo oxígeno disuelto en una camaronera o humedad de suelo en una finca— conviene partir de tres preguntas:
- ¿Qué tan rápido cambia la variable que mide? Oxígeno disuelto o temperatura ambiental no necesitan reportarse cada segundo; cada 5-15 minutos suele ser suficiente para tomar decisiones a tiempo.
- ¿Cuántos nodos comparte el mismo gateway? A más nodos, menor debe ser la frecuencia individual de cada uno para mantener el ToA total del canal bajo control.
- ¿Qué SF está usando cada nodo en la práctica? No el SF configurado de fábrica, sino el que el ADR converge en campo. Un SF más alto de lo necesario multiplica el ToA sin necesidad.
En despliegues con gateways LoRaWAN bien dimensionados y ADR activo, una red de varios cientos de nodos opera cómodamente dentro de estos límites sin que el operador tenga que pensar en duty cycle día a día. El problema aparece cuando se ignora el ToA en el diseño inicial: redes que empiezan con 20 nodos y, al escalar a 300, empiezan a perder paquetes por saturación de canal que pudo evitarse ajustando intervalos y SF desde el principio.
Conclusión
En Ecuador, bajo AU915, el duty cycle europeo no es la limitante —lo es el dwell time de 400 ms por transmisión y, en redes compartidas como TTN, la Fair Access Policy de 30 segundos de ToA diario. Diseñar bien una red LoRaWAN significa calcular el Time on Air real de cada nodo (según su SF y tamaño de payload), no asumir reglas de otra región, y dejar que el ADR reduzca ese ToA donde el enlace lo permita.
¿Va a desplegar una red con muchos nodos y quiere confirmar que la capacidad del canal alcanza para todos? Escríbanos: revisamos el intervalo de transmisión, el SF esperado y el dimensionamiento de gateways antes de instalar el primer dispositivo.