P27 Réseau LoRaWAN : Différence entre versions

Version du 17 janvier 2018 à 12:11

Présentation générale du projet

Contexte

Les réseaux bas débits, faible consommation et longue portée sont en plein essor pour des applications variées allant du suivi de troupeaux jusqu'aux villes intelligentes. Il est commun que certaines de ces applications manipulent des données sensibles. Il devient donc essentiel de penser à la sécurité des données échangées.

Description et objectifs

Le protocole LORA est un des protocole disponible actuellement qui permet le développement de réseaux de ce type. Dans ce projet, nous proposons alors de réaliser un réseau LoRaWAN, protocole réseau se basant sur la technologie LoRa. Au sein de cette architecture, nous retrouvons un concentrateur LoRa, qui sera déployé via une Raspberry Pi pour créer une station de base, ainsi que divers capteurs embarquant une radio LoRa qui échangeront avec la station de base. Une fois que ce réseau sera mis en place, nous évaluerons dans un second temps les possibilités d'attaque sur un tel réseau, aussi bien logicielle que radio, pour pouvoir proposer par la suite des contre-mesures à appliquer.

Noeud LoRa SX1276

Montage de la station de base

Raspberry Pi + station de base LoRa ic880A-SPI (SX1301)

Planning

Tableau de bord

Semaine 1 // 08/01/18 - 12/01/18

Jour 1

• Recherche d'un shield réalisant l'interface entre la Raspberry Pi et le module récepteur LoRa permettant de créer une station de base. Cela permettra d'éviter la conception d'un PCB pour réaliser cet interfaçage. Voici quelques liens où l'on retrouve ce type de composant :

https://www.tindie.com/products/gnz/imst-ic880a-lorawan-backplane-kit/

https://pcbs.io/share/zvoQ4

https://shop.coredump.ch/product/ic880a-lorawan-gateway-backplane/

• Nous nous sommes rendus compte que réaliser une commande sur n'importe lequel de ces sites prendrait un temps conséquent puisque les stocks sont épuisés sur chacun de ces sites. Sur l'un d'eux, il était possible de récupérer le schematic de ce shield. J'ai donc été rencontré Thierry Flamen pour savoir si la conception du shield était possible en réutilisant ce schematic. Nous allons donc demander au service EEI de Polytech pour concevoir ce shield.

• Recherche d'une implémentation du protocole LoRaWAN pour pouvoir la flasher sur les différents nœuds du réseau. On veillera à trouver une solution qui ne se base pas sur l'IoT The Things Network puisqu'on ne sait pour le moment pas vraiment quelle est la politique d'utilisation de ce réseau et on souhaite éviter que toutes les informations transitant sur notre réseau LoRaWAN soient accessibles par d'autres utilisateurs ou bien que certaines personnes avec de mauvaises intentions aient accès au réseau.

Jour 2

• Installation de Raspbian et des outils nécessaires sur la Raspberry. Il faut que l'interface SPI soit activée pour que la Raspberry puisse communiquer avec notre station de base. Nous avons également écrit un script sur la Raspberry qui permet de reset notre station de base. Ce script sera appelé à chaque fois que l'on démarre notre Raspberry, pour activer la pin de reset.

• Documentation sur le fonctionnement de l'implémentation LoRaWAN et recherche de différents programmes permettant d'implémenter ce protocole pour pouvoir les tester et déployer notre réseau.

Tutoriel pour la configuration de notre Raspberry pour le bon fonctionnement avec la station de base :

https://wireless-solutions.de/images/stories/downloads/Radio%20Modules/iC880A/iC880A-SPI_QuickStartGuide.pdf

Exemple d'une implémentation LoRaWAN pour notre station de base LoRa :

https://github.com/Lora-net/lora_gateway

Exemple d'une implémentation LoRaWAN pour nos noeuds LoRa :

https://os.mbed.com/teams/Semtech/code/LoRaWAN-demo-76/

Documentation sur l'implémentation LoRaMAC pour faire du LoRaWAN et comprendre le fonctionnement du protocole :

http://stackforce.github.io/LoRaMac-doc/index.html

http://www.ioi-labs.com/technologies/comprendre-reseau-lorawan

https://www.frugalprototype.com/technologie-lora-reseau-lorawan/

Tutoriel pour connaître le mappage des pins entre la Raspberry Pi et notre station de base et pouvoir initialiser notre module récepteur :

https://doc.info.fundp.ac.be/mediawiki/index.php/Setup_IC880A-SPI_(LoRaWAN_concentrator)_on_Raspberry_Pi_3

• En utilisant le dépôt GIT lora_gateway donné précédemment et le programme (util_pkt_logger) permettant de récupérer les paquets reçus sur notre station, il est possible de faire fonctionner la station de base et de récupérer les paquets transitant vers cette station en stockant toutes les informations associées aux paquets dans des logs sur notre Raspberry.

Jour 3

• On retrouve un exemple de déploiement d'un réseau LoRaWAN avec les liens suivants :

https://www.miscmag.com/lorawan-deploiement-dune-infrastructure-de-test-partie-1-2/

https://connect.ed-diamond.com/MISC/MISCHS-015/LORAWAN-deploiement-d-une-infrastructure-de-test

• Nous voulons maintenant faire fonctionner nos noeuds pour qu'ils puissent communiquer avec la station de base. On flashera nos STM32 avec le programme trouvé sur mbed.com (LoRaWAN-demo-76) en passant par le compilateur en ligne. On récupère ainsi un fichier bin que l'on copie sur notre microcontrôleur et celui-ci peut alors faire tourner notre programme.

• L'envoi des trames par les nodes devraient fonctionner correctement, formatées selon la spécification LoRaWAN. Cependant, du côté de la gateway, les trames reçues n'ont pas vraiment l'air d'être parsées selon cette spécification. Nous recherchons donc un autre moyen d'implémenter notre station de base. Nous avons trouvé quelques exemples qui utilisent un système de "packet forwarding" qui redirige les paquets reçus vers un serveur d'application qui traitera ces paquets, sans passer par le réseau TTN (The Things Network) :

https://blog.trifork.com/2016/05/20/collecting-data-from-a-private-lorawan-sensor-network-into-elastic/

https://github.com/Lora-net/packet_forwarder

https://github.com/gotthardp/lorawan-server

• Les deux premiers liens nous proposent de réaliser ce procédé en redirigeant les paquets vers un serveur personnel via une API appelée Logstash plutôt que de passer par TTN. Le dernier décrit un serveur LoRaWAN qui prend entièrement en charge la redirection de paquets ainsi que le traitement de ceux-ci, ce qui nous permettrait de pouvoir traiter toutes nos données sur la Raspberry. Nous testerons cet exemple en premier lieu.

Jour 4

• Récupération du PCB au service EEI qui est le shield permettant d'interfacer la Raspberry avec notre station de base.

• Soudures des broches sur le PCB pour pouvoir connecter directement les pins du module LoRa à la Raspberry Pi.

• Le shield n'alimente pas correctement notre station de base. Après plusieurs essais, nous nous sommes rendus compte que la broche d'alimentation pouvait être court-circuité ou bien pas suffisamment soudée.

Jour 5

• Nous cherchons à faire fonctionner notre shield. Après avoir discuté avec quelques professeurs, nous avons pu comprendre que tous les vias de notre PCB n'étaient pas effectifs. En effet, les PCBs réalisés au service EEI ne sont pas métallisés, ce qui empêche les vias de pouvoir conduire le courant entre les deux faces de notre PCB, qui est bien évidemment double face. Il a donc fallu dessouder tous les connecteurs pour pouvoir faire passer de fin fils à travers les trous qui doivent faire communiquer les deux faces pour les souder directement sur les pistes. Une fois cette chose faite, nous avons pu souder à nouveau les connecteurs comme il se doit.

• Après toutes ces manipulations concernant notre shield, celui-ci est donc fonctionnel. Nous pouvons à présent nous concentrer sur la partie logicielle du projet, à savoir déployer notre réseau LoRaWAN.

Couche supérieure du shield

Montage final avec shield

Couche inférieure du shield

Semaine 2 // 15/01/18 - 19/01/18

Jour 6

• Nous sommes repartis sur nos recherches pour pouvoir déployer un réseau LoRaWAN. Ne comprenant pas pourquoi notre station de base ne recevait presque aucun paquet, nous sommes partis de la base pour comprendre le problème. Nous avons voulu nous assurer que les nodes LoRa fonctionnaient correctement et pour cela nous avons testé un simple programme de ping pong entre deux nodes. Cela s'est révélé être un succès :

Ping Pong entre deux émetteurs LoRa

• Nous voulons maintenant tester si notre station de base arrive à bien recevoir des paquets. Nous savons déjà qu'elle arrive à en émettre en utilisant un programme de test du projet "lora_gateway" récupéré sur le github officiel Lora-net. Nous avons aussi ajouté une antenne à notre station de base ce qui facilitera grandement les communications radios, ce qui était sûrement la raison d'une réception partielle de paquets. Cependant cette modification ne semble pas apporter de gros changements.

• Après des recherches complémentaires, nous avons trouvé un autre moyen de déployer un réseau LoRaWAN à notre manière sans passer par le réseau TTN (les liens se retrouvent au jour 3), en utilisant un serveur open-source que l'on configure soi-même du début à la fin :

https://www.loraserver.io/

Jour 7

• Nous n'arrivons toujours pas à une réception convenable des paquets sur la station de base. Nous avons modifié la configuration du module pour qu'il ne réceptionne pas que des paquets LoRa avec une en-tête MAC. C'était possible que cela soit une source d'erreur cependant cela ne change pas grand chose. En regardant les retours sur le github de notre programme, nous avons pu remarqué que, comme dans notre cas, des personnes arrivent à émettre avec la station de base mais pas à recevoir. Dans la majorité des cas cela était dû à une alimentation qui ne fournissait pas une tension suffisante. Nous avons alors vérifier que nous avions du 5V aux bornes de notre station, ce qui était bien le cas.

Jour 8

• Après avoir modifié le code du ping pong pour un node en ne faisant qu'envoyer une trame toutes les secondes qui est "COUCOU", on réceptionne bien les paquets sur notre station de base, à quelques détails près.

• En effet, dans notre fichier de logs, on remarque que la taille de la payload est bien de taille 7, ce qui correspond à notre chaîne de caractères. On retrouve bien les mêmes paramètres de communication radio à savoir un Spread Factor de 7 et une bande passante de 250 kHz. Cependant on remarque que notre chaîne de caractères est altéré lors de la communication puisqu'on ne retrouve pas exactement la même chaîne de caractères sur la station de base. Après avoir décodé la payload via la table ASCII, on retrouve certains lettres qui sont correctes, d'autres non.