PROJET-1FO5 1819 CampusIoT
Le projet en quelques mots
Ce projet à pour but de travailler sur la platforme CampusIoT en rajoutant certaines fonctionnalitées, sécuriser l'application et améliorer la gestion de l'authentification. La plateforme CampusIoT est un réseau LoRaWAN pour l'enseignement pratiques des technologies IoT long-range dans les établissements d'enseignement supérieur sur Grenoble et Valence. Ce réseau comporte plusieurs stations de base réparties dans des batiments des Campus.
L'équipe et leurs rôles
- William Weill - Chef de projet, Développement (Algorithme Géolocalisation)
- Timothée Depriester - DevOps, Recherche problématique Duty Cycle
- Benjamin Besnier - Développement (Algorithme Géolocalisation), dactylographe
- Guillaume Besnard - Opération, Intégration, Test
- Théo Lévesque - Opération, Développement authentification ACL, Token, Intégration, Test
Avancé équipe
Sprint 1 - Du 28/01/18 au 03/02/18
Prise en main d'outils :
- LoRa Gateway et émetteur.
- Test déploiement LoRaServer.
- Lecture de documentation et test de création de cluster Kubernetes sur VPS.
Sprint 2 - Du 04/02/18 au 10/02/18
- Création organisation github et fork Lora Geo Server et Lora App Server et Lora Server
- Mise en place d'environnement Docker de développement pour pouvoir compiler et déployer rapidement des modifications au Lora App Server et Lora Geo Server.
- Design et implémentation d'un calcul de géolocalisation RSSI.
Sprint 3 - Du 11/02/18 au 17/02/18
- Design et implémentation d'un calcul de géolocalisation TDDOA.
- Implémentation d'une API en go pour cette géolocalisation.
- Compréhension et modification de Lora Geo Server pour pouvoir utiliser un autre backend de géolocalisation et lancement de tests correspondants.
- Problème pour l'implémentation de Gateway Tokens : impossible de recréer l'api (make api). [Bug ref](https://github.com/brocaar/lora-app-server/issues/293)
- Début d'utilisation de 3 gateways pour avoir une résolution de géolocalisation.
- Opération : automatisation des builds d'images Docker en liant Github et Dockerhub.
Sprint 4 - Du 04/03/18 au 10/03/18
- Séparation en deux équipes :
- Une s'occupant de la géolocalisation
- L'autre du duty cycle
- Correction des calculs de géolocalisation
- Implémentation de la géolocalisation en fonction du RSSI
- Mise en place d'une baie de test
- Un routeur avec un réseau local
- Un partage de connexion pour accès Internet WAN
- Un raspberry Pi avec une Pico Gateway
- Un ordinateur avec une autre Pico Gateway
- Configuration d'une Gateway Kerlink
Sprint 5 - Du 11/03/18 au 17/03/18
- Mise du place du calcul de position par TOA
- Méthode de position par RSSI non utilisable car pas assez précis
- Recherche implémentation du Duty Cycle
- Compréhension de l'architecture du LoraServer pour le tri et l'élection de Gateway responsable du Downlink
- Recherche des Issues existantes en rapport avec le Duty Cycle
- Possibilité d'implémentation (cf. la partie Remarque concernant le duty cycle)
- Ajout d'un onglet avec une carte LeafLet permettant de visualiser la localisation d'un End Device.
Sprint 6 - Du 18/03/18 au 21/03/18
- Intégration de la carte Leaflet avec la géolocalisation effectivement remontée par le module geo api.
- Préparation soutenance
- Rédaction du rapport
Remarque concernant le duty cycle
Rappel
Pour rappel, le duty cycle consiste en la limitation du temps de parole de chaque objet est limité à 1% (plus d'informations [ici](https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html) ).
Cas du LoRaServer
Le LoRaServer a la responsabilité de toutes les passerelles de notre réseau. L'objectif est de pouvoir connaitre à tout moment l'état de l'utilisation de chaque passerelle pour pouvoir répartir la charge améliorer l'efficacité globale et respecter le duty cycle de chaque passerelle.
Pour cela, plusieurs solutions s'offrent à nous (une Issue a été ouverte à ce sujet sur LoRaServer [ici](https://github.com/brocaar/loraserver/issues/383) ) :
- Estimer l'utilisation de chaque passerelle en calculant le duty cycle au niveau de la fonction d'envoi "sendDownlinkFrame" du fichier "internal/downlink/data/data.go". En effet, grâce aux informations théoriques contenues dans la structure "txInfo" (puissance d'émission, slot d'émission, fréquence, gain, ...), il est possible d'estimer le "Time Over the Air" nécessaire pour une communication. Un chronomètre pourrait donc être déclenché pour savoir si une passerelle à trop émis et doit être mise en attente.
En l'état actuel, la passerelle avec le meilleurs SNR/RSSI est choisie. Ce tri est effectué lors d'un UPLINK. Lorsque le SNR est considéré comme suffisamment bon (seuil), on trie par rssi. Ce tri ne prend en aucun cas en compte le duty cycle, et n'est pas effectué avant un DOWNLINK, mais lors d'un UPLINK. Au lieu d'utiliser la première gateway du tableau pour le DOWNLINK, on pourrait parcourir les gateway du tableau, et élire un la première n'ayant pas dépasser son duty cycle. A défaut de gateway disponible, le message est perdu. On pourrait imaginer journaliser l'information dans le but d'avertir l'administrateur qui pourrait constater un nombre de passerelles insuffisant.
- Une autre solution, qui semble être le parti pris de Broocar ( [lien](https://github.com/brocaar/loraserver/issues/370) ), serait de déléguer le calcul de son propre duty cycle à chaque passerelle : cela permettrait de ne plus avoir d'informations théoriques mais des informations réelles. Cela permettrait aussi plus de modularité et dé-complexifierait le code coté LoRaServer en déléguant la difficulté au packet forwarder. Il faudrait par contre que les firmwares des passerelles calculent leur propre utilisation du réseau et envoient régulièrement des messages en MQTT pour en informer le LoRaServer qui pourrait donc répartir la charge. Cela crée donc une dépendance du LoraServer avec les packet forwarder et demande du travail de ces fournisseurs (ex: Semtech).
Remarque
Ce controle du duty cycle ne s'appliquerait qu'aux messages UNICAST et pas au MULTICAST qui utilisent une autre méthode d'envoi.