Casos de uso y consideraciones para LoRaWAN

Nota importante: Link Labs es el fabricante de Symphony Link, un protocolo alternativo para LoRa enfocado en casos de uso industriales y empresariales de alta confiabilidad. Más abajo.

Cuando se busca comprender LoRaWAN y sus casos de uso ideales y limitaciones, es importante comprender un poco de historia. LoRaWAN (entonces llamado LoRaMAC) fue desarrollado por Semtech (el único propietario de LoRa PHY IP) en colaboración con IBM Research (posteriormente abandonaron el proyecto). Las suposiciones cuando se diseñó el protocolo fueron:

• Para ser utilizado por redes de operadores móviles
• En una única red coordinada
• En la banda sin licencia de frecuencia de 868 MHz

Estos son supuestos importantes, porque el protocolo resultante tiene:

• Límite del ciclo de trabajo del 1% (para todos los transmisores Y la puerta de enlace)
• Mapa de canales de frecuencia común
• Procesamiento MAC (Capa 2) solo en la nube

Para respaldar la limitación del ciclo de trabajo del 1% para la puerta de enlace, en particular, son necesarias muchas compensaciones:

• Casi todos los mensajes de enlace ascendente no se reconocen
• Todas las puertas de enlace en el rango ven todo el tráfico de enlace ascendente
• Todo el cifrado se maneja mediante claves estáticas

Dado que todos los mensajes de enlace ascendente no se reconocen ni están coordinados, LoRaWAN se considera un esquema "puro-aloha". Una red de este tipo tiene aproximadamente un 18% de eficiencia. Esto significa que el 82% de los paquetes se pierden cuando una red LoRaWAN se utiliza por completo. Dado que la mayoría de los mensajes no se reconocen, el nodo final no sabe que se perdió el mensaje. Para evitar esto, algunos usuarios pueden transmitir con más frecuencia, lo que agrava el problema. Lea esta publicación fácil de entender sobre Aloha Networks.

Si se agregan reconocimientos a este sistema, la eficiencia falla aún más. Esto se debe a que siempre que la estación base está transmitiendo, no puede escuchar. Los nodos finales no saben que la puerta de enlace no puede escucharlos. Dado que la puerta de enlace solo puede transmitir el 1% del tiempo, esto solo da como resultado una pérdida de paquetes adicional de aproximadamente un 1,65%.

Además, si alguien más está usando una red LoRaWAN, todo su tráfico también cuenta en contra de su capacidad. Esto se debe a que todas las puertas de enlace están sintonizadas con las mismas frecuencias comunes.

Otra consideración importante para LoRaWAN es el problema de cerca / lejos. Dado que LoRa solo tiene 20-30 dB de rango dinámico cocanal, los nodos que están cerca de la puerta de enlace ahogan los nodos que están lejos. Esto es menos preocupante en las grandes redes MNO, ya que idealmente hay varias puertas de enlace dentro del alcance.

Nuestros amigos de The Things Network también han elaborado este artículo sobre las limitaciones de LoRaWAN.

Dicho todo esto, el caso de uso ideal para LoRaWAN es:

• Sensores simples que necesitan transmitir con poca frecuencia
• Perder entre el 5% y el 85% de los datos en ocasiones está bien
• Poca capacidad para controlar este dispositivo
• No se puede actualizar el firmware del dispositivo de forma inalámbrica
• Implementado decenas a cientos
• Puede implementar varias puertas de enlace para cubrir todos los nodos

Algunas lecturas automáticas de contadores son un gran ejemplo de un buen caso de uso de LoRaWAN. Para los medidores que actualizan la lectura, digamos una vez por hora, no importa si se pierden algunas lecturas, siempre que algunas lo superen.

Symphony Link resuelve muchos de estos problemas. Brevemente, así es como:

1. Encuadre: La puerta de enlace transmite un encabezado de trama cada 2 segundos, que contiene información sobre qué canales de enlace ascendente están disponibles y cuándo se abre la ventana de enlace ascendente.

2. Reconocimientos comprimidos: En Symphony Link, de forma predeterminada, se reconocen todos los mensajes de enlace ascendente. Para lograr esto, todos los reconocimientos se mezclan en un mensaje comprimido que reciben todos los nodos (que se acaban de transmitir).

3. Intervalo de tiempo variable de enlace ascendente / descendente: La puerta de enlace decide cuánto tiempo necesita transmitir en función del tráfico de enlace descendente en cola. Le dice a los nodos cuando la ventana de enlace descendente está completa, de modo que los nodos nunca transmitan cuando la puerta de enlace no está escuchando

4. Horario de enlace ascendente: Debido al entramado síncrono, las ventanas de enlace ascendente están ranuradas, lo que agrega aproximadamente un 100% más de capacidad. Esto se incrementa aún más agregando una ventana CSMA variable antes de cada transmisión.

5. Potencia variable y factor de dispersión: El nodo final recibe el RSSI del mensaje de entramado de la puerta de enlace y ajusta dinámicamente su potencia y factor de expansión para que coincida con el enlace más un factor de margen configurable. Esto maximiza la capacidad, mitiga el desvanecimiento rápido y evita el problema de cerca / lejos mencionado anteriormente.

6. Calidad de servicio: Los nodos registran un factor QOS (0-15) con la puerta de enlace, y esto limita su capacidad para acceder a los canales en cada trama. También proporciona una forma para que la puerta de enlace limite el enlace ascendente durante tiempos de congestión.

7. Multidifusión: Al asignar grupos de nodos en grupos de multidifusión, la cantidad de enlace descendente necesaria para el control y la transmisión de archivos es limitada.

8. MTU fija de 256 bytes: 12 bytes es demasiado pequeño para la mayoría de las aplicaciones. Symphony Link proporciona una MTU fija de 256 bytes y maneja toda la sub-paquetización (por SF) y reintentos en la capa MAC.

9. Firmware por aire: Debido a las potentes funciones de multidifusión de Symphony Link, los archivos de firmware se pueden enviar a los nodos.

10. Claves AES de sesión basadas en PKI: Symphony Link no utiliza cifrado de clave fija. Cada nodo estableció una sesión AES segura utilizando Diffie-Helmann, con la clave pública de nodo proporcionada por el servidor. Esto se conoce en toda la industria como el esquema de cifrado de canal más seguro.

¿Querer aprender más? Ponte en contacto.