PROJET-1FO5 1819 CampusIoT - Revision history

Guillaume.Besnard1: /* Remarque */

2019-03-19T16:10:50Z

Remarque

← Older revision		Revision as of 16:10, 19 March 2019
Line 78:		Line 78:

	==Remarque==		==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.		Ce controle du duty cycle ne s'appliquerait qu'aux messages UNICAST et pas au MULTICAST qui utilisent une autre méthode d'envoi.

Guillaume.Besnard1: /* Cas du LoRaServer */

2019-03-19T16:09:11Z

Cas du LoRaServer

← Older revision		Revision as of 16:09, 19 March 2019
Line 73:		Line 73:
	* 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.		* 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 ~~envoyer~~, 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.		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).		* 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).

Guillaume.Besnard1: /* Cas du LoRaServer */

2019-03-19T16:08:41Z

Cas du LoRaServer

← Older revision		Revision as of 16:08, 19 March 2019
Line 73:		Line 73:
	* 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.		* 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 ~~ratio~~ est ~~calculé~~ 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 envoyer, 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.		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 envoyer, 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).		* 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).

Guillaume.Besnard1: /* Cas du LoRaServer */

2019-03-19T16:06:45Z

Cas du LoRaServer

← Older revision		Revision as of 16:06, 19 March 2019
Line 67:		Line 67:
	==Cas du LoRaServer==		==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.		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, ~~elles~~ ~~ont~~ été ~~discutées~~ ~~avec~~ ~~Brocaar,~~ ~~mainteneur~~ de LoRaServer [ici](https://github.com/brocaar/loraserver/issues/383) :

		⚫	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".

		⚫	* 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.
⚫	* 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.		En l'état actuel, la passerelle avec le meilleurs SNR/RSSI est choisie. Ce ratio est calculé 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 envoyer, 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==		==Remarque==

Guillaume.Besnard1: /* L'équipe et leurs rôles */

2019-03-19T15:30:36Z

L'équipe et leurs rôles

← Older revision		Revision as of 15:30, 19 March 2019
Line 4:		Line 4:
	=L'équipe et leurs rôles=		=L'équipe et leurs rôles=

	* William Weill - Chef de projet		* William Weill - Chef de projet, Développement (Algorithme Géolocalisation)
	* Timothée Depriester - DevOps		* Timothée Depriester - DevOps, Recherche problématique Duty Cycle
	* Benjamin Besnier - ~~Leading~~ ~~React~~ ~~software~~ ~~development~~		* Benjamin Besnier - Développement (Algorithme Géolocalisation), dactylographe
	* Guillaume Besnard - ~~Node~~ ~~Orchestrator~~		* Guillaume Besnard - Opération, Intégration, Test
	* Théo Lévesque - ~~Operations~~ ~~Manager~~ ~~(installation~~ ~~master)~~		* Théo Lévesque - Opération, Développement authentification ACL, Token, Intégration, Test

	=Avancé équipe=		=Avancé équipe=

Guillaume.Besnard1: /* Sprint 6 - Du 18/03/18 au 21/03/18 */

2019-03-19T15:26:07Z

Sprint 6 - Du 18/03/18 au 21/03/18

← Older revision		Revision as of 15:26, 19 March 2019
Line 55:		Line 55:

	==Sprint 6 - Du 18/03/18 au 21/03/18 ==		==Sprint 6 - Du 18/03/18 au 21/03/18 ==
	* Intégration ~~Carte~~ Leaflet avec la géolocalisation effectivement remontée par le module geo api.		* Intégration de la carte Leaflet avec la géolocalisation effectivement remontée par le module geo api.
	* Préparation soutenance		* Préparation soutenance
	* Rédaction du rapport		* Rédaction du rapport

Guillaume.Besnard1: /* Sprint 6 - Du 18/03/18 au 21/03/18 */

2019-03-19T15:25:54Z

Sprint 6 - Du 18/03/18 au 21/03/18

← Older revision		Revision as of 15:25, 19 March 2019
Line 55:		Line 55:

	==Sprint 6 - Du 18/03/18 au 21/03/18 ==		==Sprint 6 - Du 18/03/18 au 21/03/18 ==
			* Intégration Carte Leaflet avec la géolocalisation effectivement remontée par le module geo api.
	* Préparation soutenance		* Préparation soutenance
	* Rédaction du rapport		* Rédaction du rapport

Guillaume.Besnard1: /* Sprint 5 - Du 11/03/18 au 17/03/18 */

2019-03-19T15:25:02Z

Sprint 5 - Du 11/03/18 au 17/03/18

← Older revision		Revision as of 15:25, 19 March 2019
Line 51:		Line 51:
	** Recherche des Issues existantes en rapport avec le Duty Cycle		** Recherche des Issues existantes en rapport avec le Duty Cycle
	** Possibilité d'implémentation (cf. la partie Remarque concernant 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 ==		==Sprint 6 - Du 18/03/18 au 21/03/18 ==

Guillaume.Besnard1: /* Sprint 2 - Du 04/02/18 au 10/02/18 */

2019-03-19T15:23:58Z

Sprint 2 - Du 04/02/18 au 10/02/18

← Older revision		Revision as of 15:23, 19 March 2019
Line 18:		Line 18:

	==Sprint 2 - Du 04/02/18 au 10/02/18 ==		==Sprint 2 - Du 04/02/18 au 10/02/18 ==
	* Création organisation github et fork Lora Geo Server et Lora App Server.		* 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.		* 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.		* Design et implémentation d'un calcul de géolocalisation RSSI.

Guillaume.Besnard1: /* Sprint 3 - Du 11/02/18 au 17/02/18 */

2019-03-19T15:23:37Z

Sprint 3 - Du 11/02/18 au 17/02/18

← Older revision		Revision as of 15:23, 19 March 2019
Line 28:		Line 28:
	* 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)		* 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.		* 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 ==		==Sprint 4 - Du 04/03/18 au 10/03/18 ==