PROJET-1FO5 1819 CampusIoT: Difference between revisions
| Line 46: | Line 46: | ||
Dans notre cas, en temps que LoRaServer, nous avons la responsabilité de toutes les passerelles de notre réseau. Cela permet au LoRaServer de connaître à tout moment l'état de l'utilisation de chaque passerelle et de répartir la charge pour améliorer l'efficacité globale. |
Dans notre cas, en temps que LoRaServer, nous avons la responsabilité de toutes les passerelles de notre réseau. Cela permet au LoRaServer de connaître à tout moment l'état de l'utilisation de chaque passerelle et de répartir la charge pour améliorer l'efficacité globale. |
||
Pour cela, plusieurs solutions s'offrent à nous, elles ont été |
Pour cela, plusieurs solutions s'offrent à nous, elles ont été discutées avec Brocaar, mainteneur de 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". |
||
| ⚫ | * Une autre solution qui semble être le parti pris de Broocar 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 et correctes. 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 pourrrait 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). |
||
| ⚫ | * Une autre solution qui semble être le parti pris de Broocar serait de déléguer le calcul de son propre duty cycle à chaque passerelle: cela |
||
Finalement, lors de l'envoi réel de l'information à la passerelle, une structure contenant toutes les passerelles triées en fonction du SNR et rssi (lorsque le SNR est considéré comme suffisamment bon, on trie par rssi). Au lieu d'utiliser la première gateway du tableau pour envoyer, on pourrait boucler dessus et prendre la première gateway du tableau ayant un duty cycle respecté. A défaut de gateway disponible (SNR/Rssi trop mauvais et/ou duty cycle non respecté), 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. |
Finalement, lors de l'envoi réel de l'information à la passerelle, une structure contenant toutes les passerelles triées en fonction du SNR et rssi (lorsque le SNR est considéré comme suffisamment bon, on trie par rssi). Au lieu d'utiliser la première gateway du tableau pour envoyer, on pourrait boucler dessus et prendre la première gateway du tableau ayant un duty cycle respecté. A défaut de gateway disponible (SNR/Rssi trop mauvais et/ou duty cycle non respecté), 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. |
||
Revision as of 14:27, 19 March 2019
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
- Timothée Depriester - DevOps
- Benjamin Besnier - Leading React software development
- Guillaume Besnard - Node Orchestrator
- Théo Lévesque - Operations Manager (installation master)
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.
- 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.
Sprint 4 - Du 18/02/18 au 24/02/18
- Séparation en deux équipe :
- Une s'occupant de la géolocalisation
- L'autre du duty cycle
Sprint 5 - Du 25/02/18 au 03/03/18
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
Dans notre cas, en temps que LoRaServer, nous avons la responsabilité de toutes les passerelles de notre réseau. Cela permet au LoRaServer de connaître à tout moment l'état de l'utilisation de chaque passerelle et de répartir la charge pour améliorer l'efficacité globale. Pour cela, plusieurs solutions s'offrent à nous, elles ont été discutées avec Brocaar, mainteneur de 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".
- Une autre solution qui semble être le parti pris de Broocar 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 et correctes. 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 pourrrait 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).
Finalement, lors de l'envoi réel de l'information à la passerelle, une structure contenant toutes les passerelles triées en fonction du SNR et rssi (lorsque le SNR est considéré comme suffisamment bon, on trie par rssi). Au lieu d'utiliser la première gateway du tableau pour envoyer, on pourrait boucler dessus et prendre la première gateway du tableau ayant un duty cycle respecté. A défaut de gateway disponible (SNR/Rssi trop mauvais et/ou duty cycle non respecté), 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.
Remarque
Ce controle du duty cycle ne s'appliquerait qu'aux messages envoyés en unicast et as ceux en multicast qui utilisent une autre méthode d'envoi.