Cas d'utilisation et considérations pour LoRaWAN

Remarque importante : Link Labs est le fabricant de Symphony Link, un protocole alternatif pour LoRa axé sur les cas d'utilisation industriels et d'entreprise de haute fiabilité. Plus ci-dessous.

Lorsque vous cherchez à comprendre LoRaWAN, ses cas d'utilisation idéaux et ses limites, il est important de comprendre un peu l'histoire. LoRaWAN (alors appelé LoRaMAC) a été développé par Semtech (le seul propriétaire de l'IP LoRa PHY) en collaboration avec IBM Research (ils ont ensuite quitté le projet). Les hypothèses lors de la conception du protocole étaient :

• À utiliser par les réseaux d'opérateurs mobiles
• Dans un seul réseau coordonné
• Dans la bande de fréquence 868 MHz sans licence

Ce sont des hypothèses importantes, car le protocole résultant a :

• 1 % de limite de cycle de service (pour tous les émetteurs ET la passerelle)
• Carte des canaux de fréquence commune
• Traitement MAC (couche 2) uniquement dans le cloud

Afin de prendre en charge la limitation du cycle d'utilisation de 1 % pour la passerelle, en particulier, de nombreux compromis sont nécessaires :

• Presque tous les messages de liaison montante ne sont pas reconnus
• Toutes les passerelles à portée voient tout le trafic de liaison montante
• Tous les cryptages sont gérés à l'aide de clés statiques

Étant donné que tous les messages de liaison montante ne sont ni reconnus ni coordonnés, LoRaWAN est considéré comme un schéma « purement aloha ». Un tel réseau a une efficacité d'environ 18%. Cela signifie que 82 % des paquets sont perdus lorsqu'un réseau LoRaWAN est pleinement utilisé. Étant donné que la plupart des messages ne sont pas acquittés, le nœud final ne sait pas que son message a été manqué. Afin d'éviter cela, certains utilisateurs peuvent transmettre plus souvent, aggravant ainsi le problème. Lisez cet article facile à comprendre sur Aloha Networks.

Si des accusés de réception sont ajoutés à ce système, l'efficacité échoue encore plus. En effet, chaque fois que la station de base émet, elle ne peut pas écouter. Les nœuds d'extrémité ne savent pas que la passerelle ne peut pas les entendre. Étant donné que la passerelle ne peut transmettre que 1 % du temps, cela n'entraîne qu'environ 1,65 % de pertes de paquets supplémentaires.

De plus, si quelqu'un d'autre utilise un réseau LoRaWAN, tout son trafic est également pris en compte dans votre capacité. En effet, toutes les passerelles sont réglées sur les mêmes fréquences communes.

Une autre considération importante pour LoRaWAN est le problème proche/loin. Étant donné que LoRa n'a que 20-30 dB de plage dynamique co-canal, les nœuds proches de la passerelle noient les nœuds éloignés. Ceci est moins préoccupant dans les grands réseaux MNO, car idéalement plusieurs passerelles sont à portée.

Nos amis de The Things Network ont ​​également rassemblé cet article sur les limitations de LoRaWAN.

Cela dit, le cas d'utilisation idéal pour LoRaWAN est :

• Capteurs simples qui doivent transmettre rarement
• Il est parfois normal de manquer de 5 à 85 % des données.
• Peu de possibilité de contrôler cet appareil
• Impossible de mettre à jour le micrologiciel de l'appareil par liaison radio
• Déployé par dizaines voire par centaines
• Peut déployer plusieurs passerelles pour couvrir chaque nœud

Certains relevés de compteurs automatiques sont un excellent exemple d'un bon cas d'utilisation pour LoRaWAN. Pour les compteurs qui mettent à jour la lecture, disons une fois par heure, cela n'a pas d'importance si certaines lectures sont manquées, tant que certaines réussissent.

Symphony Link résout bon nombre de ces problèmes. En bref, voici comment :

1. Encadrement : La passerelle transmet un en-tête de trame toutes les 2 secondes, qui contient des informations sur les canaux de liaison montante disponibles et à quel moment la fenêtre de liaison montante s'ouvre.

2. Remerciements compressés : Dans Symphony Link, par défaut, tous les messages de liaison montante sont reconnus. Pour ce faire, tous les accusés de réception sont mélangés dans un message compressé que tous les nœuds (qui viennent de transmettre) reçoivent.

3. Prise de temps variable pour les liaisons montantes/descendantes : La passerelle décide combien de temps elle doit transmettre en fonction du trafic de liaison descendante en file d'attente. Il indique aux nœuds lorsque la fenêtre de liaison descendante est terminée, de sorte que les nœuds ne transmettent jamais lorsque la passerelle n'écoute pas

4. Prise de temps de liaison montante : En raison du cadrage synchrone, les fenêtres de liaison montante sont fendues, ce qui ajoute environ 100 % de capacité supplémentaire. Ceci est encore augmenté en ajoutant une fenêtre CSMA variable avant chaque transmission.

5. Puissance et facteur d'étalement variables : Le nœud d'extrémité reçoit le RSSI du message de trame de la passerelle et ajuste dynamiquement sa puissance et son facteur d'étalement pour correspondre au lien plus un facteur de marge réglable. Cela maximise la capacité, atténue la décoloration rapide et prévient le problème proche/loin mentionné ci-dessus.

6. Qualité de service : Les nœuds enregistrent un facteur QOS (0-15) auprès de la passerelle, ce qui limite leur capacité à accéder aux canaux dans chaque trame. Il permet également à la passerelle de limiter les liaisons montantes pendant les périodes de congestion.

7. Multidiffusion : En attribuant des groupes de nœuds dans des groupes de multidiffusion, la quantité de liaison descendante nécessaire pour le contrôle et le streaming de fichiers est limitée.

8. MTU fixe de 256 octets : 12 octets est trop petit pour la plupart des applications. Symphony Link fournit un MTU fixe de 256 octets et gère toute la sous-paquetisation (par SF) et les nouvelles tentatives au niveau de la couche MAC.

9. Firmware sans fil : En raison des puissantes fonctionnalités de multidiffusion de Symphony Link, les fichiers du micrologiciel peuvent être transférés vers les nœuds.

10. Clé AES de session basée sur PKI : Symphony Link n'utilise pas de chiffrement à clé fixe. Chaque nœud a établi une session AES sécurisée à l'aide de Diffie-Helmann, avec la clé publique du nœud fournie par le serveur. Ceci est connu dans l'ensemble de l'industrie comme le schéma de cryptage de canal le plus sécurisé.

Vous voulez en savoir plus ? Contactez-nous.