IMA4 2017/2018 P6

Présentation générale

Introduction

On estime à 20 milliards le nombre d’objets connectés d’ici 2020. Parmis ces objets, un grand nombre d’entre eux feront parti de ce qu’on appelle l’Internet des Objets (IoT) permettant de bâtir les villes et bâtiments connectés. La technologie LoRa (Long Range) est une des technologie permettant de créer des réseaux pour ces objets connectés.

Description

Cette technologie s’appuie sur la modulation LoRa (une modulation à étalement de spectre, bande fréquence 868Mhz), couche physique du modèle OSI créé par la startup francaise Cycléo, racheté par la société Semtech en 2012. La technologie LoRa permet de créer des réseaux sans fils sécurisés longue portée (2km en ville, 15km en campagne) et basse consommation.

Le protocole LoRaWAN constitue les couches supérieures du modèle OSI est est développé par l’alliance LoRa qui compte plus de 100 membres (des sponsors comme Semtech, IBM, Cisco, des contributeurs comme Microchip, des revendeurs comme IMST). Il utilise la bande radio libre ISM (Industrielle, Scientifique & Médicale) pour connecter les objets embarquant des radios LoRa reliés au réseau par le biais de concentrateurs.

Un réseau LoRaWAN est composé de 4 éléments :

• Les appareils (End Devices) : Équipé de capteurs et d’une radio LoRa, communiquent avec les concentrateurs via le protocole LoRaWAN transmis par modulation LoRa. La spécification LoRaWAN distingue plusieurs classes d’appareils :
  • Classe A : Les appareils peuvent communiquer à tout moment avec le serveur. Le serveur ne peut cependant communiquer avec les appareils que lorsqu’ils ouvrent leur fenêtre de réception (pendant un court instant après l’envoi de données au serveur). C’est la classe qui permet d’assurer une très basse consommation de l’appareil (>8 ans moyenne).
  • Classe B : Extension de la classe A, les appareils ouvrent leur fenêtre de réception périodiquement.
  • Classe C : Extension de la classe A, les appareils ont leur fenêtre de réception ouverte en permanence (sauf lorsqu’ils émettent). Cette classe permet d’assurer le moins de latence possible, c’est toutefois la plus énergivore.
• Les concentrateurs ou passerelles (GateWay) dont équipés d'une machine hôte sur laquelle est installé un "packet forwarder" permettant de centraliser les données des appareils LoRa et de les convertir en paquets TCP. Ces paquets seront transmis à une machine serveur (Network Server) en TCP/IP.
• Le serveur LoRaWAN gère la réception des paquets de données et les convertit pour les envoyer à l’application de l’utilisateur. Il permet également d’adapter dynamiquement le débit de données et d’assurer les respect du temps d’utilisation de la bande radio (Duty Cycle)
• Le serveur d’application (Application Server) : Objectif final du réseau, permet d’exploiter les données reçues par les capteurs via une page web par exemple.

Objectifs

Développer un réseau LoRaWAN "maison" et évaluer les possibilités d'attaques.

Analyse du projet

Positionnement par rapport à l'existant

De nombreux projets utilisent déjà la technologie LoRa mais se basent sur le serveur public The Thing Network. On fait ici le choix d'utiliser un serveur privé (sous forme d'un simple ordinateur) afin de contrôler au mieux la sécurité des données. (cryptées en AES-128 de bout en bout) Le but de ce projet sera également de concevoir des appareils de coût relativement faible, le plus petit possible.

Analyse du premier concurrent

A l'heure actuelle, le seul vrai concurrent de LoRa en terme de possibilités est Sigfox, créé en 2009. LoRa arrive donc 3 ans plus tard, mais les nombreux avantages par rapport à son concurrent lui permettent de s'immiscer sur le marché : Taille maximale des messages : 242 octets (12 pour Sigfox) Nombre de messages par jour illimités (à condition de respecter le duty-cycle) (140 msg/jour pour Sigfox) Immunité contre les interférence élevé grâce à la modulation à étalement de spectre (basse pour Sigfox) Coût d’installation et de maintenance faible (Sigfox nécessite un abonnement) Open Source du moment qu’on achète les puces (Sigfox est propriétaire)

Analyse du second concurrent

La 5G déjà en développement pourrait prendre un certain temps avant d'être courant sur le marché. Cependant, Orange à lancé la LTE-M, une évolution de la G spécialement dédié au objets connectés.

LTE-M proposera des débits allant jusqu'a 10Mb/s et bénéficiera de l'itinérance puisqu'ils se base sur le réseau 4G existant.

Scénario d'usage du produit ou du concept envisagé

Dans le cadre de sa politique d’amélioration continue, l’école Polytech Lille déploie un réseau LoRaWAN dans son établissement. Ce réseau longue portée et faible consommation permet l’installation de petits appareils dotés de capteurs dans les salles de classe permettant d’obtenir divers informations sur les salles pour réduire la consommation en énergie ou connaître l’occupation des salles. Des capteurs de luminosité sont installés dans les salles et permettent de repérer les endroits où les lumières sont allumées. Des capteurs de température permettent de contrôler la température des salles. Des capteurs de contact installés sur les fenêtres permettent de détecter les fenêtres ouvertes. Des capteurs de présence permettent de savoir si la salle est occupée.

Le réseau est composé d'un concentrateur LoRa, relié à une RaspBerryPi3 (installé dans un local technique de l'école) embarquant un programme de conversion des paquets LoRa en paquets TCP. Les capteurs, associés à des micro contrôleurs de type Nucleo-F4 équipés de radios LoRa vont envoyer les informations au concentrateur. Celui-ci par le biais de la RaspBerryPi va envoyer les information sous forme de paquets TCP au serveur.

L’utilisateur ciblé est l’appariteur de l’école, il pourra contrôler depuis une page web les différentes statut des capteurs lors de la fermeture le soir : fenêtres fermées, lumières éteintes, chauffage baissé raisonnablement, salles vides.

Réponse à la question difficile

Quels sont les limites du sujet ?

Le sujet est très vaste, il est donc nécessaire d'établir des limites claires dans ce qui sera réalisé.

En tout premier lieu, le but du projet sera de rendre opérationnel. Le concentrateur et la RaspBerryPi (machine hôte de ce concentrateur) devront être déployés. Ensuite, il faudra tester la communication d'un End Device équipée d'une radio LoRa avec le concentrateur. Puis le concentrateur devra être en mesure d'envoyer les paquets TCP à une machine (serveur) qui se chargera de les récupérer et d'extraire leur contenu par exemple sur une page web. Quand le système sera opérationnel pour un End Device, le test portera sur la mise en réseau de 2 End Devices.

Dans un deuxième temps, une étude approfondie sur les méthode de cryptage utilisées par LoRa sera menée, ainsi qu'une évaluation des différentes possibilités d'attaque sur le réseau.

Enfin, il sera intéressant de faire des tests sur les performances du réseau LoRa.

Quel tests seront effectués ?

Des tests de portée seront réalisés afin de déterminer la distance maximale de réception des données sur le réseau LoRa. Des tests de consommation énergétique seront menés afin d’estimer la durée de vie de la batterie ou des piles pour les End Devices.

Préparation du projet

Choix techniques : matériel et logiciel

Choix Matériel

Ce projet utilisera le concentrateur LoRa iC880A-SPI (http://shop.imst.de/wireless-modules/lora-products/8/ic880a-spi-lorawan-concentrator-868-mhz)

La machine hôte du concentrateur sera une RaspBerryPi3.

Les micro-contrôleurs seront des Nucleo-F401RE (http://www.st.com/en/evaluation-tools/nucleo-f401re.html)

Les modules radio seront des Shields I-NUCLEO-LRWAN1 (http://www.st.com/en/evaluation-tools/i-nucleo-lrwan1.html)

Choix Logiciel

Ce projet ne requiert pas de logiciel particulier.

le GitHub https://github.com/Lora-net contenant les implémentations de référence des différents éléments du réseau LoRa sera utilisé comme base pour programmer le concentrateur et les microcontrôleurs.

Liste des tâches à effectuer

1. Déployer le concentrateur LoRa (et son système hôte sur la RaspberryPi)

2. Mettre en place un End Devices et tester sa communication avec le concentrateur

3. Tester le packet forwarder présents ur la RaspBerry Pi afin de convertir les paquets LoRa en paquets TCP vers le serveur.

4. Analyser le processus de cryptage des données de bout en bout

5. Trouver d'éventuelles possibilités d'attaque sur le réseau

6. Tester les performance des éléments du réseau LoRaWAN

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	0

Semaine 1

Séance 1 - 15/01/18 - 3H

Cette première séance de projet à permis de découvrir le matériel.

• 

  Concentrateur LoRa IC880A-SPI

• 

  Microcontrôleur Nucleo-F401RE

• 

  Shield LoRa I-NUCLEO-LRWAN1

• 

  RaspBerryPi3

La première étape consiste à rendre le concentrateur IC880A-SPI opérationnel. Pour cela il faut le connecter en SPI à la machine hôte (RaspBerryPi) selon les instructions données dans le guide de démarrage du concentrateur. (https://wireless-solutions.de/images/stories/downloads/Radio%20Modules/iC880A/iC880A-SPI_QuickStartGuide.pdf)

On peut donc établir la correspondance de PIN suivante :

Correspondance des PINS IC880A-SPI <> RaspBerry3

21 (VDD)	2 (+5V)
22 (GND)	6 (GND)
14 (SPI_CLOCK)	23 (SPI0_CLOCK)
15 (SPI_MISO)	21 (SPI0_MISO)
16 (SPI_MOSI)	19 (SPI0_MOSI)
17 (SPI_NSS)	24 (SPI0_CE0)
13 (Reset)	17 (GPIO_17)

Séance 2 - 17/01/18 - 5H

L'objectif de cette séance était de rendre le rendre la RaspberryPi opérationnelle.

Comme préconisé dans le guide de démarrage du concentrateur LoRa, une Raspbian Jessie à été flashé sur la microSD de la RaspberryPi.

Cependant il était impossible de connecter la RaspberryPi en liaison série à l'ordinateur. Après avoir exploré plusieurs pistes, et demandé conseil aux professeurs qui m'ont dirigé vers le wiki du BE PeiP, j'ai compris que mon erreur venait du fait que la RaspberryPi, depuis sa version 3 ne prend plus en charge la communication série par défaut.

En effet, le Bluetooth est activé par défaut et monopolise les pins de la communication série. Il faut donc rentrer dans la partition boot de la microSD et ajouter ajouter enable_uart=1 à la toute fin du fichier config.txt.

Malheureusement, après cette manipulation, la communication série ne fonctionnait toujours pas. Vers la fin de la séance j'ai finalement testé un autre câble usb/série. Le premier câble était bel et bien défectueux.

Bien que le projet ai peu avancé durant cette séance, cela m'a permis d'acquérir un certain nombre de compétences qui me seront très utile par la suite. J'ai appris à installer un système d'exploitation sur RaspberryPi3. J'ai également appris à flasher une image sous linux et je suis parvenu à établir la connexion série sur la RaspberryPi3.

Séance 3 - 18/01/18 - 3H

Disposant maintenant d'une connexion série sur la RaspberryPi, cette séance avait pour objectif d'établir l'accès en SSH depuis l'ordinateur et de connecter la RaspberryPi à internet pour pouvoir télécharger les paquets nécessaires au fonctionnement du concentrateur LoRa.

Après avoir essayé plusieurs méthodes de connexion j'ai finalement choisi la connexion en ethernet sur la 2ème carte réseau des ordinateurs Zabeth. J'ai paramétré la connexion en DHCP, la Raspberry est capable de pinger la Zabeth mais pour le moment pas d'accès à internet, probablement à cause du proxy.

La connexion avec le hotspot de mon smartphone constitue une solution provisoire d'accès à Internet pour ma RaspberryPi. En effet, il sera nécessaire d'établir une connexion ethernet avec une Zabeth puisque cette dernière jouera le rôle de network server.

Séance 3BIS - 19/01/18 - 2H

Cette séance avait pour objectif de rendre le concentrateur opérationnel. Après avoir branché le concentrateur en SPI à la RaspberryPi, celui-ci refusait de lancer le programme de test.

L'erreur venait du fait qu'avant toute utilisation, le concentrateur doit se réinitialiser, par le biais d'un signal reset envoyé sur un GPIO de la RaspberryPi. Pour cela, j'ai utilisé le script disponible sur le git LoraNet de Semtech car l'extrait de code proposé dans le guide de démarrage du concentrateur ne semblait pas convenir.

A la fin de la séance le concentrateur parvenait à émettre grâce au programme de test util_tx_test. Bien que le projet ne requiert pas que le concentrateur émette vers les End Devices, ce test montre que l'accès SPI de la RasperryPi avec le concentrateur est fonctionnel.

Les séances de la semaine prochaine seront dédiées à la création d'un EndDevice sur NucleoF4.

Semaine 2

Séance 4 - 22/01/18 - 2H

Cette séance a permis de me familiariser avec le microcontrôleur NucleoF4.

J'ai choisi d'utiliser le compilateur en ligne d'ARM os.mbed.com puisqu'il ne nécessite aucune installation sur l'ordinateur, est gratuit et convient tout à fait à mon usage.

Une fois le programme écrit et compilé, le site propose le binaire en téléchargement.

Selon le manuel d'utilisation il suffit de copier le binaire sur le NucleoF4, d'appuyer sur le bouton reset de celui-ci pour téléverser le programme.

Cependant, même en suivant les instruction à la lettre je n'ai pas obtenu de résultats satisfaisants. Les périphériques USB n'étant pas directement montés lors du branchement sur les Zabeth, il fallait le faire à la main. Le seul problème était qu'il fallait ensuite le démonter puis débrancher le microcontrôleur, et enfin le rebrancher pour que le programme prenne effet.

Je rechercherai donc une solution à ce problème pour la prochaine séance.

J'ai également profité de cette séance pour me documenter sur la shield LoRa I-NUCLEO-LRWAN1.

Cette shield est très peu documenté, les seules ressources que j'ai trouvé se trouvent sur le github https://github.com/USILoRaModule/USI_I-NUCLEO-LRWAN1 de la société USI qui commercialise ce produit.

Ceci m'a guidé vers le package I-CUBE-LRWAN distribué par ST.com Selon la documentation, ce package permet de créer une End Device de classe A sur NucleoLX et est compatible avec la shield I-NUCLEO-LRWAN1 de USI. Comme les série NucleoFX et NucleoFX sont assez semblables je pense que mon contrôleur NucleoF4 conviendra.

Séance 5 - 24/01/18 - 5H

J'ai commencé par chercher une solution à mon problème de téléversement sur le NucleoF4. Après recherches, j'ai trouvé l'utilitaire ST-Flash sur le github https://github.com/texane/stlink. Cet utilitaire permet de flasher la mémoire du NucleoF4 et après tests, convient parfaitement à mes attentes.

Mon objectif était ensuite de réussir à faire communiquer mon NucleoF4 avec mon concentrateur LoRa.

J'ai pour cela d'abord testé les implémentations de test fournies sur le github lora-net pour développer un end device de classe A.

Comme la radio LoRa de la shield est de type SX1272 j'ai utilisé le programme http://developer.mbed.org/teams/Semtech/code/LoRaWAN-demo-72/ fourni pour Semtech.

Je suis alors confronté à un problème : comment savoir si cette implémentation est adaptée pour ma shield lora ?

Séance 6 - 25/01/18 - 2H

Cette séance m'a permis de me documenter davantage sur la shield LoRa I-NUCLEO-LRWAN1.

J'ai trouvé des morceaux de codes pour ce module, dont un code de test "ping-pong" permettant à 2 appareils LoRa de communiquer entre eux (permet principalement de tester les modules). Cependant, je n'arrive pas à importer le projet sur os.mbed.

Je vais donc continuer de me documenter et essayer de travailler depuis un IDE afin de voir si j'obtiens de meilleurs résultats.

Semaine 3

Séance 7 - 29/01/18 - 2H

La mise en place d'un émetteur LoRa est plus longue que prévue, je suis bloqué depuis une semaine sur mon problème de shield LoRa très peu documentée.

Disposant du projet de test fourni pour ST j'ai essayé d'utiliser l'IDE gratuit basé sur Eclipse pour STM32 "System Workbench for STM32" proposé par http://www.openstm32.org/

J'y ai importé le projet mais je ne parviens pas à le compiler.

Des librairies sont manquante, et je n'arrive pas à comprendre la structure de ce projet de test pour le moment.