free html site templates

DutyCycle de LoRaWan

El duty cycle es un factor determinante a la hora de transmitir por LoRawan ya que un mal uso generalizado puede acarrear a la larga la saturación de la red.

El duty cycle marca el tiempo que podemos estar transmitiendo datos. Pero no nos confundamos entre el standard ETSI que rije el LoRaWan y el propio LoRaWan. El primero especifica el 1% y el segundo que el máximo son 30 segundos/24h.

Una frase muy común de escuchar es:" El Duty Cycle es un valor del 1%, es decir que si emitimos 1 segundo tenemos que dejar libre la frecuencia durante 99 segundos antes de transmitir de nuevo, o que se podría transmitir ininterrumpidamente 14,4 de los 1440 minutos del día mientras el resto estemos en silencio de radio."

Esta lectura podría llegar a ser cierta si tuviéramos un sistema propio, ya que la norma 7.2.3 del standard ETSI EN300.220 concretamente en la “Table 5: Maximum radiated power limit, e.r.p., channel spacing, spectrum access and mitigation requirements ”donde aparece indicado el 1% de uso de las frecuencias no especifica pausas mínimas ni tiempos máximos.

Pero TheThingsNetwork tiene sus propias reglas de dutycycle: the Fair Access Policy. Esta política se puede resumir en las siguientes restricciones que sirven tanto para nodos como para Gateways.  Como se puede apreciar son mucho más estrictas que las del standard ETSI.

  1. Máximo tiempo de uplink: 30 segundos cada 24 horas.
  2. Número máximo de downlinks: 10 cada 24 horas

Veamos un Ejemplo:

Nuestra trama de datos emite latitud, longitud, altitud, velocidad y rumbo. En un trabajo de compresión de datos hemos utilizado los siguientes pesos para cada campo:

payload: 12 bytes

4 bytes para la latitud (float de 4 bytes) 

4 bytes para la longitud (float de 4 bytes)

2 bytes para altitud en pies (unsigned int)

1 byte para velocidad en Kt ( unigned byte velocidad 0-255 kts)

1 byte para rumbo (unsigned byte 0-179 * 2 redondeando a rumbo par)

identificador de trama: El sistema utiliza 13 bytes como identificador. 

Por lo que el resultado total de bytes enviados es de 25.

Al enviar los datos no esperamos un ACK por lo que básicamente el sistema solo consume el tiempo de transmisión, pero en contra no sabemos si se ha recibido la trama. Un nodo solo debería enviar un máximo de 10 ack por día lo que no podemos hacer confirmación de datos.  

La velocidad de transmisión:

La velocidad de transmisión en sistemas de comunicación digitales se mide en baudios o baudrate y básicamente indica el numero de bits por segundo al que se envía la información. Pero en LoRa el concepto de velocidad es un tanto distinto, se conoce como Spread Factor, donde se combina velocidad y protocolo de errores. Este sistema es un poco más complejo que el baudrate pero para entenderlo de forma práctica podemos decir que tenemos distintas velocidades predefinidas que van desde el spread factor 7 (SF7) hasta Spread factor (SF12). La velocidad de transmisión SF7 es la más rápida, mientras que la SF12 es la más lenta. Por otro lado la SF12 es la que tiene mejor tasa de efectividad y mayor distancia mientras que la SF7 es la menor. 

Calcular el tiempo de aire es complejo, afortunadamente contamos con un Gateway que cronometra cada trama que recibe, por lo que podemos mostrar los resultados para nuestras tramas de 25 bytes para cada Spread Factor:

Mobirise

Esto nos indica que para cada tipo de SF podemos enviar un máximo de tramas diarias de:

Mobirise


Si emitimos una trama de 25 bytes en SF7 cada 30 segundos sin ACK necesitamos aproximadamente 4 horas para transmitir el máximo de 487 tramas diarias. Mientras que si emitimos en SF12 solo podríamos hacerlo durante unos 10 minutos y medio.