2022-12-04T21:23:34Z

Gaetan.Lavirotte: Created page with "=Résumé= =Abstract= =Introduction= Le réseau Helium est un réseau Internet des objets (IoT) sans fil décentralisé utilisant le protocole de communication radio LoRaWA..."

=Résumé=

=Abstract=

=Introduction=

Le réseau Helium est un réseau Internet des objets (IoT) sans fil décentralisé utilisant le protocole de communication radio LoRaWAN. Développé par la société américaine Nova Labs, Helium est un réseau communautaire et open-source visant à permettre la communication de capteurs IoT dans les zones où la couverture sans fil ou mobile est minimale ou nécessite trop d’énergie. A la différence d’autres réseaux communautaires comme The Things Network (TTN), le réseau Helium utilise une blockchain afin d’encourager la création de réseaux sans fil publics décentralisés. Chacun étant ainsi incité à posséder un nœud du réseau afin de fournir la couverture sans-fil de sorte que celui-ci appartienne à tous les participants et non à une seule entreprise. Le mécanisme de consensus de la blockchain est basé sur un nouvel algorithme de travail appelé Proof of Coverage, et récompense les participants (ou mineurs) en Helium Network Token (HNT).

=Le réseau Helium=

L'intérêt d’Helium est que ce dernier est compatible avec les appareils LoRaWAN de classe A. Pour rappel, le protocole LoRaWAN définit 3 classes d’équipement: A, B et C, cette classe n’est pas fixe et peut évoluer. Tous les équipements LoRa doivent implémenter la classe A qui est également la plus économe. Dans le cas de l’utilisation classique, le schéma de communication est le suivant, l’objet sans fil qui remonte les données sera appelé un end-device. Ce dernier envoie donc un message à l’aide de la modulation LoRa. Ce message est ensuite capté par une ou plusieurs passerelles LoRaWAN aussi appelés gateway. La ou les passerelles se chargent de faire suivre le paquet au serveurs réseau LoRaWAN, aussi appelé LoRaWAN network server ou encore LNS. Le LNS est un peu le cœur du réseau LoRaWAN, il est chargé de nombreuses tâches, par exemple ils suppriment la duplication du même message qui aurait été reçu par plusieurs passerelles. Ensuite le message est envoyé à un serveur d’application. Le serveur d’application se charge du traitement des données reçues.
Dans un réseau LoRaWAN classique, le LoRaWAN network server est géré par une seule entité, qu’il soit régional ou central. Ici, Hélium a également travaillé sur ce sujet pour proposer encore une fois quelque chose de décentralisé pour que l’accès au réseau ne soit pas soumis à l’acceptation de la part du gestionnaire du LoRaWAN network server. Pour pallier ce problème, Helium souhaite que les LoRaWAN network server privés soient compatibles avec l’infrastructure publique. Pour cela, sur le réseau Helium chaque LoRaWAN network server possède un OUI (Organizationally Unique Identifier), un appareil qui souhaite donc se connecter au réseau envoie donc un message particulier “Join Request” et en fonction des filtres (jusqu'à 5) enregistré par l’OUI sur la blockchain, la demande pour rejoindre est éventuellement acceptée. L’envoie de paquet peut ensuite se faire.
Fort du fait d’être le plus large réseau LoRaWAN, Helium se place comme une solution attractive pour les fournisseurs de LoRaWAN network server qui ne souhaitent pas développer leur propre infrastructure tout en souhaitant se développer. Helium possède pour cela un serveur itinérant ou “Helium Roaming Server”. Ce dernier est chargé de récupérer les paquets à destination des partenaires et de les acheminer vers un serveur qui va les accepter. Ceci permet donc à une entreprise de proposer ses services à travers le réseau Helium.

=La Blockchain Helium=

==Blockchain et algorithme de consensus==

Une blockchain est un réseau pair-à-pair permettant d’opérer des transactions sécurisées sans intervention d’un tiers de confiance. Pour cela, un algorithme de consensus est nécessaire et permet aux acteurs du réseau de se coordonner au sein d’un environnement distribué. Cet algorithme assure que tous les nœuds du réseau parviennent en un temps fini à se mettre d’accord sur une unique vérité même en cas de défaillance de certains nœuds. Une blockchain émettrice d’une crypto-monnaie , correspond ainsi à une base de données distribuées infalsifiable où chaque acteur du réseau conserve une copie identique des transactions. Les acteurs du réseau, appelés également validateurs, doivent fournir une preuve de leur travail de sécurisation via le mécanisme de consensus et sont alors récompensés en recevant une nouvelle unité de la crypto-monnaie émise par la blockchain. Différents algorithmes de consensus sont actuellement utilisés notamment l’algorithme de Proof of Work (PoW) pour sécuriser la blockchain Bitcoin ou le Proof of Stake (PoS) pour sécuriser la blockchain Ethereum. Afin qu’une blockchain puisse répondre aux besoins des utilisateurs, elle doit pouvoir répondre à trois caractéristiques majeures que sont la sécurité, la décentralisation et la scalabilité. A ces trois caractéristiques est venu s’ajouter la nécessité d’avoir une blockchain écologiquement responsable, c’est-à-dire que son algorithme de consensus ne nécessite pas une consommation d’énergie démesurée (ce qui est le cas de la blockchain Bitcoin). En prenant en compte ces caractéristiques, l’entreprise Nova Labs à développer son propre algorithme de consensus pour sécuriser les transactions de la blockchain Helium.

==Proof of coverage (PoC)==

Le principe de l’algorithme est de vérifier en continu que chaque Hotspot fournit une couverture réseau et qu’il se trouve bien à la position à laquelle il prétend être.
Un “challenge” correspond à une durée pendant laquelle les différents hotspots cherchent à se faire élire et appartenir au “groupe de consensus” pour pouvoir valider le prochain bloc de transactions. Lors d’un challenge les hotspots ont différents rôles:

:* Challenger : Le hotspot qui émet le paquet de challenge PoC (tous les 360 blocs).
:* Transmetteur: Le hotspot qui transmet qui transmet les paquets de challenge et pouvant être observé par un autre hotspot géographiquement proche.
:* Témoin: Un hotspot géographiquement proche du transmetteur et qui signale au réseau l’existence d’un paquet de challenge
:* Validateur: Un ordinateur connecté à la blockchain qui réceptionne et vérifie que le challenge s’est déroulé selon les règles du PoC. Il soumet la preuve de couverture à la blockchain pour faire partie du groupe de consensus et valider le prochain bloc.

Ces différents acteurs agissent ensemble afin de fournir une preuve de couverture réseau. Un exemple du processus de preuve de couverture est décris ci-dessous:

:*Le challenger émet un paquet “challenge“ via TCP-IP sur le réseau à destination d’un hotspot transmetteur afin que ce dernier prouve qu’il effectue bien une couverture réseau à l’endroit où il prétend être.
:* Le paquet est réceptionné par un autre hotspot (le Transmetteur)
:* Le Transmetteur envoie un paquet via onde radio (ici LoRa)
:* Ce paquet est éventuellement reçu par plusieurs hotspots entourant le Transmetteur. Ces hotspots sont appelés les “témoins”. Si plus de 10 témoins reçoivent ce paquet, 10 d'entre eux seront sélectionnés aléatoirement pour recevoir une récompense pour leur participation au PoC
:* Une fois le paquet reçu, les témoins vont alors renvoyer un paquet via TCP-IP au challenger pour lui confirmer que le Transmetteur est bien à proximité d’eux.
:* Le Challenger va alors contacter un Validateur en lui fournissant la preuve de couverture.
:* Le validateur vérifie que le travail a bien été réalisé et soumet une demande à la blockchain pour faire partie du processus de validation du prochain bloc.

Les hotspots impliqués dans ce processus (Challenger, Transmetteur et Témoin) sont récompensés pour leur participation à la sécurisation du réseau en recevant sur leur adresse une fraction du token HNT généré lors de la création du nouveau bloc.
Si le Validateur est choisi pour faire partie du groupe consensuel (composé de 43 membres), il suivra un algorithme similaire au HoneyBadgerBFT. HBBFT est un protocole de diffusion atomique asynchrone conçu pour permettre à un groupe de nœuds connus de parvenir à un consensus sur des liaisons non fiables. Dans la mise en œuvre d'Helium, un groupe consensuel de validateurs élus reçoit des transactions cryptées en entrée et procède à un accord commun sur l'ordre de ces transactions avant de former un bloc et de l'ajouter à la blockchain. Une fois le nouveau bloc créé, les nœuds du réseau (validateurs et hotspots) impliqués dans le processus de validation, reçoivent leur récompense en HNT. De pkus, tous les hotspots (y compris ceux ne pouvant pas participer au PoC car isolés géographiquement) reçoivent une récompense en HNT pour avoir retransmis les paquets de données provenant des appareils IoT.

=Références=

Nova Labs, Helium Network Documentation, docs.helium.com, Consulté le 3 Décembre 2022 sur https://docs.helium.com/

Coinbase, Guide to Helium, coinbase.com, Consulté le 3 Décembre 2022 sur https://www.coinbase.com/fr/cloud/discover/protocol-guides/guide-to-helium

VT2022 XXX fiche

2022-12-04T21:23:09Z

Gaetan.Lavirotte: Blanked the page

VT2022

2022-12-04T21:22:52Z

Gaetan.Lavirotte:

[[VT2021|<< Etudes 2021]] [[VT|Sommaire]] [[VT2023|Etudes 2023 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en INFO5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.

Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Chaque séance comporte 3 à 4 présentations suivi chacune d'une démonstration. Chaque présentation dure entre 20 et 25 minutes en fonction des séances. Pour plus de sécurité, la démonstration peut être pré-enregistrée.

Votre présentation sera réalisée de préférence avec [[reveal.js]] ou avec [[remarkjs]].

Votre présentation sera notée et commentée par tous vos camarades via un sondage (smartphone). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu en vaut-il la chandelle ?

[[File:presentation-VT-INFO5-2122.pdf|transparents d'introduction à l'UE]]

=Planning=

== Séance 1 : 07/11 (réporté)==

== Séance 2 : 14/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

Présentation et organisation.

== Séance 3 : 21/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[AdTech et capitalisme de surveillance]]: Julien Guigard, Angelo Alibert [[Media:VT2022_Adtech_presentation.pdf|présentation]], [[Media:AdTech et capitalisme de surveillance Rapport écrit.pdf|fiche]], [[VT2022_Adtech_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion : Kacha, Jardin [[Media:VT2022_AIArt_presentation.pdf|présentation]], [[Media:VT2022 AIArt synthese.pdf|fiche]], [[VT2022_AIArt_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Ansible]]: Da Costa [[Media:VT2022_Ansible_presentation.pdf|présentation]], [[VT2022_Ansible_fiche|fiche]], [[VT2022_Ansible_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 4 : 28/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[Web Assembly et Smart Contracts]]: Verrier, Mottino [[Media:Web_assembly_&_smart_contracts.pdf|présentation]], [[VT2022_WebAssemblyEtSmartContracts_fiche|fiche]], [[VT2022_WebAssemblyEtSmartContracts_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[GPT Neo|GPT la suite]] : Monthe Djeumou, Simo Yokam [[Media:VT2022_GPT_presentation.pdf|présentation]], [[VT2022_GPT_fiche|fiche]], [[VT2022_GPT_demo|demo]], [https://montube.com/GPTAZERTYUIO screencast]
* [[Implants rétiniens]]: Bernerd, NGuyen Justin [[Media:VT_Implants_Rétiniens.pdf|présentation]], [[Media:Fiche_de_synthèse.pdf|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 5 : 05/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* WebRTC: Hadiby, Mohsen [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Voice-First Development : Designing, Developing, and Deploying Conversational Interfaces: Conjard, Fodor [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Helium: Lavirotte, Pelisse [[Media:VT2022_Helium_presentation.pdf|présentation]], [[VT2022_Helium_fiche|fiche]], [[VT2022_Helium_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Internet of Audio Things]]: Teyssier, Drouin [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 6 : 12/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* NVidia [[Deep learning super sampling (DLSS)]]: Canin, Wagner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* OpenPose (ou autre): Poitevin, Reygner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* AzureRTOS: Bach, Chiotti [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Post-quantum cryptography]] : Zhang, Guiguis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 7 : 09/01 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* Vote électronique : Abecassis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* NFT : plateformes, technologies, vices et vertus: Faghloumi [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Géo-localisation Wifi : Fournier [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Generation of ASMR (Autonomous sensory meridian response)]]: Chappaz, De Oliveira [[Media:VT2022_ASMR_presentation.pdf|présentation]], [[VT2022_ASMR_fiche|fiche]], [[VT2022_ASMR_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 8 : 16/01 (très probablement en distanciel) ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[IPFS (InterPlanetary File System)]]: Capet, Royer [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Low Code Development]] : Breton, Nguyen Clément [[Media:VT2022_LowCode_presentation.pdf|présentation]], [[Media:VT2022_LowCode_fiche.pdf|fiche]], [[Media:VT2022_LowCode_demo.pdf|demo]], [https://montube.com/AZERTYUIO screencast]

=Sujets=
# [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion
# [[GPT Neo]]
# [[Predictive networks]]
# [[Objectives and Key Results]]
# [[Implants rétiniens]]
# [[Post-quantum cryptography]]
# [[Internet of Audio Things]]
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Generation of ASMR (Autonomous sensory meridian response)]]
# [[Wasm|WebAssembly]]
# [[Web Assembly et Smart Contracts]]
# [[Application Performance Monitoring]] : démonstration de [[Apache Skywalking]]
# [[Low Code Development]]
# [[Multi-Region Database Deployments: Patterns and Anti-Patterns]] : démonstration avec [[Cockroack]]
# [[Proof of Coverage Blockchain]] : démonstration d'[[Helium]]
# [[IPFS (InterPlanetary File System)]]
# [[Géolocalisation Wifi : principles et services de géolocalisation Wifi et cellulaire]]
# [[Caches distribués]]: démonstration avec [[Redis]]
# [[NEMU]] : open source hypervisor specifically built and designed to run modern cloud workloads on modern 64-bit Intel and ARM CPUs.
# [[Fission]] : open-source serverless function framework for [[Kubernetes]] with a focus on developer productivity and high performance.
# [[AdTech et Surveillance capitalism]]
# [[Conflict-free replicated data type]] (CRDT)
# [[ Voice-First Development]] : Designing, Developing, and Deploying Conversational Interfaces
# [[AzureRTOS]] : système d'exploitation pour l'Internet des Objets. démonstration sur [https://www.st.com/en/evaluation-tools/b-l475e-iot01a.html B-L475] à récupérer au fablab.
# Algorithmes et systèmes de vote électronique : vices et vertus.
# [[Pantavisor Linux]]: A Framework for Building Containerized IoT Systems
# [[WebRTC]] : Web Real-Time Communication
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Bundle Protocol]]
# [[NFT]] : plateformes, technologies, vices et vertues.
# [[MLOps]] : DevOps for Machine Learning projects

2022-02-14T11:18:33Z

Gaetan.Lavirotte:

* Projet INFO4 S8 2020-2021
* Encadrant: Didier DONSEZ.

L'enregistrement de noeuds IoT [[LoRa]]WAN dans un réseau public ou privé est en général une tache pénible pour les installateurs de réseaux IoT.

Une nouvelle spécification de la LoRa Alliance facilite l'enregistrement des noeuds IoT LoRaWAN au moyen de QRCode (LoRaWAN® Device Identification QR Codes for Automated Onboarding)

Le QRCode sur l'étiquette (label) de l'équipement à enregistrer contient une chaine de la forme suivante:
<pre>
LW:D0:1122334455667788:AABBCCDDEEFF0011:AABB1122:OAABBCCDDEEFF:SYYWWNNNNNN:PFOOBAR:CAF2C

Example
SchemaID of D0
JoinEUI of 11-22-33-44-55-66-77-88
DevEUI of AA-BB-CC-DD-EE-FF-00-11
ProfileID of AABB-1122
OwnerToken of AABBCCDDEEFF
SerNum of YYWWNNNNNN
Proprietary of FOOBAR
CheckSum of AF2C (CRC16)
</pre>

L'objectif est de développer une application mobile native (iOS, Android) qui permet l'enregistrement d'un noeuds IoT LoRaWAN à partir de son QRCode auprès d'un des réseaux de l'utilisateur.

L'application utilisera les API RESTFul des serveurs de réseaux privés (TTS et Chirpstack) et les API RESTFul des serveurs de réseaux publics (Orange, Bouygues Objetnious, TTN). Ces APIs requièrent une authentification qui pourront être également configurés via un QRCode.

Le code sera mis en open source ici : https://github.com/CampusIoT/lorawan-device-identification-qr-codes
Le code pour la version 2021-2022 est disponible ici: https://github.com/AlphagGone/ScanWAN.git
Remarque: LoRa By the Numbers
* > 1.2 million LoRa-based gateways deployed worldwide
* > 180 million LoRa-based end-nodes to be deployed worldwide on private and public networks by the end of 2020
* 148 Network operators in more than 99 countries and increasing
* 43% of all LPWANs are predicted to run on LoRa by 2023 (IHS MarketInsider, May 2019)

* https://lora-alliance.org/resource_hub/tr005-lorawan-device-identification-qr-codes/
* https://lora-alliance.org/wp-content/uploads/2020/11/LoRa_Alliance_Vendor_ID_for_QR_Code.pdf