Difference between revisions of "PROJET-1FO5 1819 CampusIoT"

From air
Jump to navigation Jump to search
(3 intermediate revisions by the same user not shown)
Line 5: Line 5:
   
 
* William Weill - Chef de projet
  
* William Weill - Chef de projet
−
* Timothée Depriester - DevOps OVH
 +
* Timothée Depriester - DevOps
 
* Benjamin Besnier - Leading React software development
  
* Benjamin Besnier - Leading React software development
 
* Guillaume Besnard - Node Orchestrator
  
* Guillaume Besnard - Node Orchestrator
Line 31: Line 31:
 
==Sprint 4 - Du 18/02/18 au 24/02/18 ==
  
==Sprint 4 - Du 18/02/18 au 24/02/18 ==
 
==Sprint 5 - Du 25/02/18 au 03/03/18 ==
  
==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 gateway et de répartir la charge pour améliorer l'efficacité globale.
  +
Pour cela, plusieurs solutions s'offrent à nous, elles ont été discuté 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 en train de devenir le nouveau standard serait de déléguer le calcul de son propre duty cycle à chaque passerelle: cela permettrai de ne plus avoir d'informations théoriques mais des informations réelles et correctes. Cela permettrai aussi plus de modularité et dé-complexifierai 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.
  +
  +
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 passerelle 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.

Revision as of 17:22, 18 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

Sprint 5 - Du 25/02/18 au 03/03/18

  1. Remarque concernant le duty cycle
    1. 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) ).

    1. 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 gateway et de répartir la charge pour améliorer l'efficacité globale. Pour cela, plusieurs solutions s'offrent à nous, elles ont été discuté 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 en train de devenir le nouveau standard serait de déléguer le calcul de son propre duty cycle à chaque passerelle: cela permettrai de ne plus avoir d'informations théoriques mais des informations réelles et correctes. Cela permettrai aussi plus de modularité et dé-complexifierai 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.

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 passerelle insuffisant.


    1. 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.

Retrieved from "https://air.imag.fr/index.php?title=PROJET-1FO5_1819_CampusIoT&oldid=45327"