Fondamentaux LoRaWAN

Cet article concerne l'architecture Wattsense LoRaWAN.

Communication LoRaWAN de base

Une fois que les capteurs ont effectué un processus d'appairage appelé JOIN, ils transmettent leurs données aux Wattsense Box en utilisant le protocole LoRaWAN.
Nos Tower/Bridges sont équipés d'un serveur LoRaWAN embarqué, conçu pour décoder localement et interpréter les informations provenant des capteurs.
Une fois les données décodées avec succès, elles sont transmises soit à notre système backend, si l'appareil en question est une Tower, soit au serveur Local dédié, dans le cas d'un Bridge ou d'une Tower.

Ce mécanisme de routage intelligent garantit que les données circulent correctement et sont livrées à la destination appropriée pour un traitement et une analyse ultérieurs.

L'architecture Wattsense LoRaWAN peut être décrite comme suit :

Glossaire :

End devices : des capteurs ou des actionneurs transmettent des messages sans fil via LoRaWAN à la passerelle Wattsense (Tower ou Brideg). Ils peuvent également recevoir des messages sans fil des passerelles.

Wattsense LoRaWAN Gateway : Nos passerelles reçoivent les messages des appareils finaux et les transmettent à notre backend dans le cas d'une Tower ou à un serveur local dans le cas d'un Bridge.

Si vous avez besoin d'informations supplémentaires, veuillez nous contacter ici.

Qu'est-ce que l'ADR (Adaptative Data Rate) ?

Le serveur LoRaWAN utilise un mécanisme de débit adaptatif (ADR), composant essentiel de la pile LoRaWAN, pour ajuster dynamiquement le facteur d'étalement (SF / Spreading Factor) selon certaines règles. Selon la documentation Semtech, le mécanisme ADR simplifie le processus de modification du débit en suivant les directives suivantes :

1. Si le bilan de liaison, qui représente la qualité et la puissance globales du signal, est élevé, le débit peut être augmenté en augmentant le facteur d'étalement (SF).
2. Inversement, si le bilan de liaison est faible, le débit peut être diminué en réduisant le facteur d'étalement (SF).

En adaptant le débit au bilan de liaison disponible, le mécanisme ADR garantit des performances optimales pour chaque terminal du réseau LoRaWAN. Le serveur réseau utilise l'indicateur de puissance du signal reçu (RSSI) des messages reçus d'un terminal pour évaluer la proximité de ce dernier avec la ou les passerelles les plus proches.
Ces informations permettent au serveur réseau de sélectionner les paramètres les plus adaptés à chaque terminal.

L'utilisation de l'ADR présente deux avantages : elle contribue à préserver la durée de vie de la batterie des appareils et réduit les interférences, augmentant ainsi les performances de communication de tous les appareils du réseau.

Pour affiner les ajustements de débit, notre serveur LoRaWAN utilise une stratégie. Il établit une moyenne à partir des données des 10 trames les plus récentes.
De plus, il attend 10 trames successives avec un débit de données de capteur stable avant de lancer une requête ADR.
Par exemple : si le serveur observe 8 trames successives à SF8 et que le capteur bascule ensuite à SF10 pour une raison quelconque, le serveur réinitialise la période d'attente et requiert 10 trames successives à SF10 avant d'envoyer une requête ADR. Cette approche garantit la stabilité et la fiabilité de l'ajustement du débit de données des terminaux.

Autres avantages :

Par ailleurs, un SF correct (faible) présente d'autres avantages notables :

1. Capacité de capteurs accrue : Le choix du facteur d'étalement influence directement le nombre de capteurs pouvant être connectés à votre box Wattsense. Un facteur d'étalement plus faible permet une plus grande densité de connexions de capteurs au sein de votre projet.
2. Réduction des délais d'uplink : lorsque le serveur LoRaWAN reçoit des uplinks modulées en SF12, il doit gérer des délais plus longs que pour les uplinks en SF7. Ce facteur est important pour optimiser l'efficacité et la réactivité globales du réseau.

En gérant soigneusement le spreading factor et en tenant compte de ces avantages, vous pouvez améliorer efficacement l'évolutivité et les performances de votre projet LoRaWAN.

Voici un schéma théorique :

Nous pouvons facilement voir qu’en utilisant un meilleur SF, le serveur LoRaWAN sera capable de gérer plus d'uplinks dans la même période de temps.

Veuillez nous contacter si vous avez besoin d'informations supplémentaires : Support Wattsense

Cet article concerne les bonnes pratiques pour les projets LoRaWAN.

LoRaWAN n'est peut-être pas adapté à tous les cas d'utilisation, il est donc crucial de comprendre ses limites. Voici un bref résumé des bonnes pratiques à suivre lors de la construction d'un projet LoRaWAN :

Cas d'utilisation appropriés pour LoRaWAN

• Communication longue portée
• Faible consommation d’énergie : les appareils peuvent fonctionner pendant des années avec une seule batterie.
• Faible besoin de bande passante
• Large couverture : les utilisateurs peuvent établir leur propre réseau en installant des passerelles.
• Sécurisé : Cryptage de bout en bout avec sécurité 128 bits.

Ne convient pas à LoRaWAN

• Transmission de données en temps réel : De grandes quantités de données ne peuvent pas être envoyées fréquemment ; de petits paquets peuvent être envoyés toutes les quelques minutes.
• Appels téléphoniques : Pour la communication vocale, d'autres technologies comme GPRS/3G/LTE doivent être utilisées.
• Tâches à large bande passante comme l'envoi de photos ou le streaming de vidéos : le WiFi est recommandé à ces fins.

Bonnes pratiques d'installation du matériel

Placement de l'antenne de la Box

L'emplacement et la configuration d'une antenne peuvent avoir un impact significatif sur les performances et la portée des appareils LoRaWAN. Nous aborderons les considérations essentielles et les meilleures pratiques pour une installation correcte de l'antenne dans les réseaux LoRaWAN.

Une étape cruciale consiste à déterminer l’emplacement optimal pour votre antenne LoRaWAN. Voici quelques considérations :

Hauteur : Montez votre antenne aussi haut que possible pour réduire les obstacles et augmenter la communication en visibilité directe avec les capteurs.
Ligne de vue : minimisez les obstacles entre le périphérique LoRaWAN et la passerelle. Les bâtiments, arbres et autres structures peuvent atténuer le signal et réduire la portée. Dans la mesure du possible, choisissez un emplacement avec une ligne de vue dégagée vers la Box.
Longueur du câble : gardez la longueur du câble entre le périphérique LoRaWAN et l'antenne aussi courte que possible pour minimiser la perte de signal. Utilisez des câbles coaxiaux à faible perte pour les longueurs de câble plus longues. Le câble ne doit pas dépasser 10 m.

Emplacement du capteur

Assurez-vous de lire la documentation du fabricant, car elle contient généralement des recommandations sur le placement des capteurs.

Effectuer un radio-mapping

Réaliser un mapping radio LoRaWAN vous permettra d'évaluer la qualité de votre réseau et vous aidera à trouver le meilleur emplacement pour votre Box et vos capteurs.

Pour exécuter ce type de processus, vous aurez besoin d'un LoRaWAN network fieldtest (testeur Adeunis disponible dans notre base de données).

Le schéma suivant illustre la façon de déterminer la qualité du signal :

Bonne pratique de configuration des capteurs

Lors de la configuration d'un capteur LoRaWAN (uplink), il est important de considérer les aspects suivants :

1. Fréquence d'uplink optimale : veillez à ajuster le nombre d'uplink envoyées par jour pour trouver un équilibre entre la conservation de l'énergie de la batterie et l'optimisation du potentiel de connexion d'un plus grand nombre de capteurs. En trouvant la bonne fréquence, vous pouvez assurer une transmission efficace des données tout en prolongeant la durée de vie de la batterie de votre capteur. Analysez soigneusement les exigences de votre application et trouvez un équilibre approprié pour atteindre les performances souhaitées.
2. Tirer parti de la redondance : dans la mesure du possible, utilisez les fonctionnalités de redondance fournies par le réseau LoRaWAN. La redondance contribue à améliorer la fiabilité de la transmission et de la réception des données, conduisant à un système plus robuste et plus tolérant aux pannes. En tirant parti de la redondance, vous améliorez non seulement les chances de réussite de la transmission des données, mais vous contribuez également à économiser l'énergie de la batterie en réduisant le besoin de retransmissions.
3. Optimisation du spreading factor : envisagez d'utiliser le SF7 (Spreading Factor 7) comme choix principal pour la transmission des données de votre capteur. SF7 offre des avantages tels qu'une meilleure optimisation de la bande passante au sein du serveur LoRaWAN.

En prenant en compte ces facteurs pendant le processus de configuration, vous pouvez affiner la configuration de votre capteur LoRaWAN pour des performances optimales, une utilisation efficace de la batterie et une utilisation efficace des capacités du réseau LoRaWAN.

Lors de l'envoi des réponses de votre application au capteur (downlink), tenez compte des recommandations suivantes :

Notre objectif est de maximiser le nombre de nœuds pouvant être gérés par Box. Cependant, en raison de la disponibilité limitée des radios full-duplex, une Box ne peut pas recevoir de transmissions des nœuds (capteurs) pendant qu'elle émet. Cela signifie que pendant les 10% du temps où une Box transmet, elle ne peut recevoir aucune donnée.

Pour garantir un réseau hautement fiable, il est essentiel que la Box reçoive correctement les transmissions de tous les appareils. Afin de maintenir une disponibilité optimale des Box, nous vous demandons de bien vouloir respecter les recommandations suivantes :

1. Efficacité du débit de données : similaire à l'uplink, efforcez-vous d'obtenir une efficacité maximale du débit de données du downlink. L'efficacité de vos transmissions d'uplink déterminera l'efficacité de la réponse du réseau sous forme de downlinks.
2. Réduire les messages de downlink : dans la mesure du possible, évitez d'utiliser des messages de downlink. Si une transmission en downlink est nécessaire, gardez la taille du payload petite pour minimiser l'impact sur le réseau.
3. Considérez la nécessité d'un uplink confirmé : l'uplink confirmée n'est souvent pas essentielle pour la plupart des applications. Il est conseillé de concevoir votre application pour qu'elle fonctionne efficacement sans avoir besoin de confirmations.

En adhérant à ces recommandations, nous visons à établir un réseau avec une haute fiabilité et des performances améliorées.

Veuillez nous contacter si vous avez besoin d'informations supplémentaires : Support Wattsense

Cet article concerne les types de messages LoRaWAN.

Les messages LoRaWan peuvent être classés en deux catérogies : les uplink et downlink messages, en fonction de leur sens de déplacement.

Messages Uplink

Les uplinks sont transmis par les appareils finaux (capteurs) et reçus par le serveur réseau, souvent via plusieurs passerelles. Dans le cas où l'uplink est destiné au serveur d'applications ou au join server, le serveur réseau le transmet au destinataire approprié pour un traitement ultérieur.
Le serveur LoRaWAN intégré aux produits Wattsense a la capacité de recevoir simultanément des données sur 8 canaux. En théorie, nous pouvons représenter cette capacité à travers le schéma suivant :

Remarque : Les uplinks sont répartis aléatoirement entre les 8 canaux de communication du serveur Lorawan.

Messages Downlink

D'autre part, les downlink messages sont envoyés par le serveur réseau aux périphériques finaux (capteurs). Cela inclut les messages lancés à la fois par le serveur d'applications et le join server, garantissant une communication ciblée avec des périphériques spécifiques.

Dès réception d'une commande de downlink de la console, la box (utilisateur, PLC, etc.) au sein du réseau LoRaWAN le mettra en file d'attente dans une file d'attente spécifique au capteur. Le moment où le downlink est envoyé varie en fonction de la classe du périphérique final :

Pour les appareils de classe A 

la commande downlink sera transmise après que le serveur LoRaWAN aura reçu un message d'uplink du capteur. Cette classe suit un modèle de communication planifié dans lequel les messages downlink sont transmis uniquement après une transmission d'uplink.

Cas pratique :

Dans ce cas pratique nous voulons piloter la consigne de température d'une vanne thermostatique qui a une période d'émission de donnée toutes les 15 minutes avec un automate sur site.

Voici le schéma de principe à respecter pour un pilotage de qualité :

Pour les appareils de classe A, si vous programmez 2 downlinks l'un après l'autre et si le capteur n'a pas envoyé d'uplink (qui aurait déclenché le premier downlink) : Le dernier downlink écrasera le premier

Voici le schéma qui en résultera :

On remarque que la consigne de température de 20°C a été écrasée par celle de 22°C. Il faut donc programmer vos envois de consignes à une période supérieure à 15min afin de ne pas avoir de suppression de downlink.

Dans les logs vous verrez donc une information de "Downlink Lost" vous informant qu'un downlink a été supprimé.

Pour les appareils de classe C

La commande downlink est directement envoyée par le serveur LoRaWAN dès réception de la commande. Dans cette classe, les messages descendants peuvent être envoyés à tout moment, même sans attendre une transmission montante.

Cas pratique :

Dans ce cas, nous voulons piloter un seul thermostat connecté en lui modifiant sa consigne de température. Ce thermostat a une période d'émission toutes les 15 minutes.

Voici le schéma de principe à comprendre lorsque vous souhaitez piloter un capteur de classe C :

On remarque qu'à la différence de la classe A, le downlink est envoyé immédiatement au thermostat.

Il est important de comprendre qu'avec le protocole Lorawan, on ne peut pas recevoir d'uplink et envoyer des downlink en même temps. C'est pourquoi, lorsque l'on utilise des capteurs de classe C et que vous souhaitez piloter plusieurs équipements (par exemple plusieurs thermostats), nous ajoutons une temporisation entre chacun des downlinks programmés. Cette temporisation est fixée à 14 secondes. Ce qui permet une alternance entre les périodes d'émission et de réception.

Voici le schéma de principe lorsque vous envoyez des consignes sur plusieurs capteurs de classe C (dans cet exemple les thermostats) via votre automate:

Dans le cas présent toutes les consignes sont donc passées à 20°C et auront mise environ 14*2s = 28s à être envoyées.

Afin de ne pas créer une file d'attente qui augmente "à l'infini". Veillez bien attendre la fin de l'envoi massif programmé avant d'en lancer un nouveau. Autrement les consignes que vous enverrez pourrait être envoyées avec un "décalage" dû à un envoi trop fréquent.

Si vous avez besoin d'informations supplémentaires, veuillez nous contacter ici.