Soutenance mémoire
Nœuds capteurs
Afin de mesurer l’environnement et d’interagir avec lui, il est nécessaire d’avoir des capteurs et actionneurs simples, représentés à gauche sur la Figure 1.2. Ils sont utilisés dans des contextes variés et répondent à des besoins hétéroclites. Ils transmettent et reçoivent des messages courts comme une mesure d’un capteur ou l’ordre de déclenchement d’un actionneur et doivent fonctionner de manière fiable durant des périodes longues. Les améliorations technologiques sur les composants sont généralement utilisées pour baisser les coûts de production et d’exploitation, notamment en énergie, plutôt que pour améliorer les performances, ainsi leurs capacités restent limitées. Autrement dit, les architectures matérielles sont réduites (processeur, mémoire), la consommation énergétique doit être faible et la batterie doit tenir sur de longues périodes [194]. Pour qu’ils puissent avoir une grande durée de vie avec des batteries simples (piles classiques) les nœuds se mettent en veille autant que possible pour préserver leurs réserves d’énergie. Afin de masquer l’hétérogénéité des nœuds et des protocoles spécifiques qu’ils utilisent pour se parler, ces nœuds ont besoin de passerelles pour communiquer avec l’extérieur.
Passerelles
Ces passerelles (parfois aussi appelées routeurs de bordure) sont en charge de concilier un écosystème d’appareils hétérogènes, de collecter les données des nœuds capteurs et d’offrir une interface vers eux. La nature hétérogène des capteurs conduit les passerelles à supporter différents types d’interfaces (par exemple : Courant Porteur en Ligne (CPL), Bluetooth, cellulaire ou encore Wi-Fi) et protocoles réseau. Elles masquent ainsi la spécificité des capteurs derrière une interface présentant les ressources avec un formalisme commun. Les passerelles sont plus performantes que les nœuds capteurs et ont un rôle de médiateur entre différentes technologies, comme montré sur la Figure 1.2 . Du fait de leur position, les passerelles disposent de beaucoup d’informations sur les nœuds capteurs et peuvent en tirer parti entre autres pour établir et optimiser des tables de routage ou découvrir les services offerts par les capteurs.
Expériences automatisées et reproductibles pour LLNs
Effectuer une expérience avec des LLNs met en jeu de nombreux logiciels et des procédures qui sont longues et fastidieuses lorsqu’elles sont réalisées manuellement. Cela rend une expérience difficile à reproduire surtout si elle n’est pas ré-effectuée par la ou les mêmes personnes. Lorsque de nombreuses étapes sont nécessaires pour obtenir un résultat, documenter et automatiser l’expérience en question autant que possible devient crucial afin qu’elle puisse être reproduite et validée par la communauté scientifique et de s’assurer de leur véracité efficacement. Les bancs de test (appelés testbeds en anglais) prévus pour les LLNs fournissent de nombreux outils dédiés au lancement d’expériences et à la collecte de résultats [26, 68]. Cependant il n’existe pas de solution complète pour lancer, récupérer et exploiter les données issues d’expériences et de simulations dans un seul outil cohérent et intégré. En outre, l’un des écueils à éviter lors de la conception de tels outils est de définir une architecture trop spécialisée et donc inutilisable dans d’autres contextes, ce qui limiterait d’emblée son impact. Le chapitre 5 propose un framework d’organisation d’expérience permettant de documenter, d’exécuter et d’analyser l’ensemble d’une expérience sur LLN. Fonctionnant à la fois en simulation et sur nœuds réels, Makesense permet d’obtenir un framework d’expériences reproductibles. Ce chapitre consacré à Makesense illustrera son fonctionnement au travers d’une expérience typique. Il présente entre outre les étapes clés d’une expérience et montre que les choix technologiques ne requièrent pas une implémentation spécifique, mais utilise au contraire des outils classiques et largement utilisés par la communauté scientifique. Enfin, un mécanisme d’intégration continue automatisera l’expérience et apportera ainsi la preuve de sa reproductibilité.
Plan d’adressages dans un LLN
D’un point de vue fonctionnel, dans un réseau maillé, on distingue les hôtes simples représentés par un H sur la Figure 2.1 et les routeurs représentés par un R. Les hôtes envoient et reçoivent des messages, mais n’en transfèrent pas pour le compte d’autres nœuds. Les routeurs font suivre des paquets entre leur origine et leur destination. Il est à noter qu’un routeur peut également recevoir et envoyer des messages et assurer les deux fonctions (routeur et hôte). Au vu de cette répartition des rôles dans un LLN, il y a essentiellement trois types d’architectures possibles représentées sur la Figure 2.1. La plus simple consiste en un LLN connecté de manière ad hoc. Les nœuds hôtes envoient des informations que les nœuds routeurs relaient vers leurs destinations. Ce type de déploiement est par exemple utilisé dans des terrains sans connectivité avec un autre réseau [194]. Le second type de déploiement utilise une passerelle pour assurer le rôle de routeur de bordure entre le LLN et un réseau local. Ce type de déploiement peut par exemple se retrouver dans un scénario domotique dans lequel tous les équipements communiquent vers la même passerelle. Enfin un dernier type de déploiement étend le scénario du routeur de bordure pour prendre en charge le cas où des nœuds peuvent avoir plusieurs passerelles vers un réseau commun. Ce type de déploiement peut être pertinent dans le cas où les nœuds capteurs sont mobiles et doivent pouvoir changer de passerelles tout en restant connectés au réseau et en ne changeant pas leur adresse. Toutes ces architectures requièrent un adressage de chaque nœud afin de pouvoir garantir des communications en unicast qui sont importantes pour économiser de l’énergie et du débit par rapport à des communications broadcast. IEEE 802.15.4 fournit un identifiant (nommé Extended Unique Identifier (EUI) en anglais) pour chaque nœud du LLN qui est sous la forme d’un EUI-64 dans sa version “longue” et qui est fournie par le constructeur. Un identifiant plus compact EUI-16 peut être construit à partir du précédent pour réduire la place occupée par ces adresses dans les entêtes. Les protocoles basés sur IEEE 802.15.4 utilisent ces identifiants pour construire un plan d’adressage et une passerelle est requise pour faire une éventuelle traduction entre l’adressage du réseau standard et celui utilisé dans un LLN.
État de l’art sur la supervision dans les LLNs
Quelques contributions ont examiné le problème général de la surveillance d’un LLN efficace en énergie. Par exemple, [116] et [104] considèrent le problème de la sélection d’un sous-ensemble de capteurs “sondeurs” chargés de surveiller activement les autres capteurs “sondés”. Les sondeurs émettent des alarmes vers la passerelle s’ils détectent une anomalie. propose un algorithme distribué d’approximation pour sélectionner un nombre minimum de sondeurs et étudie le taux de faux positif généré. [104] propose de réduire la dépense énergétique en utilisant des paquets de contrôle de routage pour sélectionner les sondeurs et en intégrant les rapports de suivi dans les messages de contrôle du protocole de routage. Cependant, ces approches nécessitent des sondes déployées dans le réseau et reviennent donc à des approches actives distribuées qui peuvent être coûteuses à mettre en place. Dans [31], les auteurs proposent LiveNet, une architecture de surveillance semi-passive qui repose sur des sondes situées dans le LLN. En utilisant les traces agrégées transmises à la passerelle, LiveNet est capable de reconstruire la topologie de routage du LLN et de déterminer divers paramètres de performance. Ce travail vise explicitement la surveillance de l’énergie, mais pourrait être adapté à d’autres indicateurs de performance. Cependant, il nécessite la transmission et le traitement de traces issues des sondes dans le réseau, ainsi il n’est donc pas entièrement pertinent pour l’approche recherchée dans ce chapitre qui n’utilise pas de sondes et ne veut pas ajouter une nouvelle charge aux nœuds. Dans [203], les auteurs introduisent une méthode distribuée pour créer une carte de l’énergie restante d’un LLN. Les nœuds déclarent leur énergie résiduelle à un nœud voisin chargé de l’agrégation et de la compression de ces informations et ne transmettent que des mises à jour incrémentielles (condensées) à la passerelle. Suivant cette idée, laisse l’estimation et la prédiction de temps de vie à chaque nœud puis se charge de l’envoyer au moniteur de réseau. De plus, [https://www.rapport-gratuit.com/] compare une méthode probabiliste, basée sur les chaînes de Markov, une méthode statistique, sur la base d’un modèle auto-régressif, avec une méthode simple de déclaration explicite pour estimer un temps de vie. Dans [82], les auteurs étendent cette idée en modélisant l’énergie de chaque nœud avec un modèle de Markov caché dont les coefficients sont estimés avec des mesures explicites. Dans [30], les auteurs construisent une carte de l’énergie et changent la structure de surveillance régulièrement pour redistribuer le coût de cette surveillance de façon équitable à travers le réseau. Si l’idée de construire une carte de l’énergie du réseau est étroitement liée à la mesure efficace, toutes les méthodes mentionnées ci-dessus reposent fortement sur des rapports explicites et continus des nœuds et nécessitent donc une approche active alors que l’objectif de ce chapitre est d’apporter une méthode aussi passive que possible. D’autre part, l’observation passive du trafic réseau est une pratique courante qui permet de mesurer ses principales propriétés sous la forme de flots réseau. Ces flots sont spécifiés par différents protocoles tels qu’IPFIX [35] ou sFlow [146] et sont envoyés vers un collecteur qui sera ensuite interrogé par un logiciel d’analyse afin de diagnostiquer des problèmes (par exemple des congestions) ou de fournir des estimations de la quantité de flux traitée afin de procéder par exemple à une facturation. Bien qu’utilisées dans les réseaux classiques, ces techniques d’observations passives et d’analyses de flots ne sont le plus souvent pas disponibles sur les routeurs de bordure destinés aux LLNs. L’approche proposée dans ce chapitre s’inspire de cette méthodologie et propose d’utiliser ces observations de trafic pour en déduire des informations sur les nœuds du LLN.
|
Table des matières
1 Introduction
1.1 Taxonomie des machines en IoT
1.1.1 Nœuds capteurs
1.1.2 Passerelles
1.1.3 Infrastructure de services
1.2 Enjeux & motivations
1.2.1 Applications en milieu industriel
1.2.1.1 Agriculture et élevage intelligent
1.2.1.2 Gestion de bâtiment – Domotique
1.2.2 Applications pour les villes intelligentes
1.2.2.1 Voirie
1.2.2.2 Sécurité et Urgences
1.2.2.3 Environnements intelligents
1.3 Défis introduits par les LLNs
1.3.1 Défis liés aux nœuds
1.3.1.1 Hétérogénéité technologique et fonctionnelle
1.3.1.2 Cycle de vie
1.3.2 Défis liés au réseau
1.3.2.1 Pertes
1.3.2.2 Connexions intermittentes
1.3.2.3 Besoin de protocoles optimisés
1.3.2.4 Écoute passive en zone dense
1.3.2.5 Passage à l’échelle
1.4 Aperçu des contributions
1.4.1 Mesure implicite de la consommation énergétique d’un LLN
1.4.2 Optimisation des ressources du LLN avec un cache intelligent
1.4.3 Expériences automatisées et reproductibles pour LLNs
1.4.4 Collaborations extérieures faites durant la thèse
1.5 Plan du manuscrit
2 Caractéristiques d’une passerelle pour LLN
2.1 Technologie sans-fil et adressage
2.1.1 Communication vers LLNs
2.1.1.1 Accès longue portée
2.1.1.2 Accès courte portée
2.1.2 Plan d’adressages dans un LLN
2.1.2.1 IPv4
2.1.2.2 IPv6
2.1.2.3 6LoWPAN
2.2 Routage
2.2.1 Contraintes du routage dans les LLNs
2.2.1.1 Faible empreinte sur les ressources d’un nœud
2.2.1.2 Détection des boucles
2.2.1.3 Routage optimisé pour les types de trafic typiques des LLNs
2.2.2 Taxonomie des protocoles de routage
2.2.2.1 Construction des tables
2.2.2.2 Réactivité
2.2.3 Routing Protocol Layer
2.2.3.1 Structures et signalisation de routage
2.2.3.2 Construction du routage
2.2.3.3 Maintenance du routage
2.3 Interface applicative
2.3.1 Contraintes de l’interface applicative d’un LLN
2.3.1.1 Interface efficace avec les services web
2.3.1.2 Disponibilités sur plusieurs plateformes
2.3.1.3 Contraintes en ressources
2.3.2 État de l’art sur les protocoles applicatifs
2.3.2.1 Couches spécifiques à une architecture matérielle
2.3.2.2 Message Queuing Telemetry Transport (MQTT)
2.3.2.3 Application directe de HyperText Transfer Protocol (HTTP)
2.3.3 Présentation de Constrained Application Protocol (CoAP)
2.3.3.1 Support de notifications asynchrones
2.3.3.2 Traduction HTTP/CoAP
2.3.4 Traduction, proxy inversé et cache
2.3.4.1 Traduction
2.3.4.2 Proxy inversé
2.3.4.3 Cache
2.4 Supervision
2.4.1 Fonctionnalités recherchées
2.4.1.1 Suivi des équipements
2.4.1.2 Suivi de la disponibilité
2.4.1.3 Prévision
2.4.1.4 Construction de tableau de bord
2.4.2 Problématiques de la supervision pour les LLNs
2.4.2.1 Contraintes physiques et logicielles
2.4.2.2 Grande hétérogénéité
2.5 Conclusion
3 Mesure implicite de l’utilisation de la radio d’un LLN
3.1 Introduction à la supervision d’un LLN
3.1.1 Objectifs de la supervision dans les LLNs
3.1.1.1 Diagnostic de problèmes
3.1.1.2 Anticipation de problèmes
3.1.1.3 Mesure des performances
3.1.2 Contraintes liées à la supervision d’un LLN
3.1.2.1 Contraintes liées aux nœuds
3.1.2.2 Contraintes liées à la métrique
3.2 État de l’art sur la supervision dans les LLNs
3.3 Mesure de l’utilisation de la radio implicite et passive
3.3.1 Architecture de mesure implicite
3.3.2 Modélisation de l’impact du trafic réseau
3.3.2.1 Mesure passive “étoilée”
3.3.2.2 Mesure passive “maillée”
3.3.3 Modélisation de l’utilisation de la radio d’un nœud
3.3.3.1 Impact de IEEE 802.15.4
3.3.3.2 Impact de ContikiMAC
3.4 Validation expérimentale
3.4.1 Supervision passive
3.4.1.1 Analyse de l’impact de la profondeur
3.4.1.2 Analyse de l’impact des protocoles
3.4.2 Précision de la mesure passive de l’utilisation de la radio
3.4.2.1 Précision en fonction de la topologie
3.4.2.2 Évolution de δ au cours du temps
3.5 Mesures explicites
3.5.1 Validation expérimentale
3.5.2 Travaux en cours
3.5.2.1 Mesure systématique
3.5.2.2 Mesure ciblée dynamique
3.5.2.3 Méthode d’évaluation
3.6 Conclusion
4 Optimisation des ressources d’un LLN avec un cache intelligent
4.1 Introduction
4.1.1 Objectifs d’un Reverse Proxy Cache
4.1.2 Fonctionnement d’un Reverse Proxy Cache (RPC)
4.1.3 Problématique des reverse proxy
4.2 État de l’art
4.2.1 RPC pour les LLNs
4.2.2 Optimisation des ressources basée sur les temps de vie
4.2.3 Optimisation des ressources énergétiques par cache
4.3 Reverse Proxy Cache Adaptatif
4.3.1 Architecture
4.3.2 Calcul théorique de l’impact du cache sur l’intensité des requêtes
4.3.3 Modélisation de la durée de vie
4.3.3.1 Énergie résiduelle
4.3.3.2 États de transmission d’un nœud
4.3.4 Modélisation des temps moyens de transmission et de réception avec ContikiMAC
4.3.4.1 Transmission d’un paquet
4.3.4.2 Réception d’un paquet
4.3.4.3 Consommation des serveurs applicatifs
4.3.4.4 Consommation des nœuds routeurs
4.3.4.5 Consommation en phase d’écoute de canal
4.3.4.6 Consommation en phase de sommeil
4.4 Optimisation multi-objectifs
4.4.1 Paramètres du problème
4.4.1.1 Solution
4.4.1.2 Contraintes pour les durées de validité des réponses
4.4.1.3 Satisfaction d’un utilisateur
4.4.2 Résolution du problème multi-objectifs
4.4.2.1 Grand espace de recherche
4.4.2.2 Fonctions objectives quelconques
4.4.2.3 Économie de temps de calcul et de mémoire
4.4.3 État de l’art
4.4.4 Formalisation en algorithme génétique
4.4.5 Fonctionnement global
4.4.6 Aptitude
4.4.7 Sélection
4.4.8 Croisement & Mutation
4.4.8.1 Mutation
4.4.8.2 Croisement
4.5 Validation expérimentale
4.5.1 Compromis entre durée de vie et satisfaction utilisateur
4.5.2 Cache hit
4.5.3 Amélioration de la durée de vie
4.6 Conclusion
5 Expériences automatisées et reproductibles pour LLNs
5.1 Introduction à la recherche reproductible dans les LLNs
5.1.1 Reproductibilité
5.1.2 Problématiques expérimentales des LLNs
5.1.2.1 Expérience sur simulateur
5.1.2.2 Expérience sur émulateur
5.1.2.3 Expérience sur plateforme
5.1.2.4 Expérience en déploiement réel
5.1.2.5 Transitions entre niveaux
5.2 État de l’art sur les outils de gestion d’expériences
5.2.1 Documentation
5.2.2 Automatisation
5.2.3 Déploiement d’expérience sur nœuds réels
5.3 Makesense
5.3.1 Présentation d’une expérience typique sur les LLNs
5.3.2 Documentation d’une expérience
5.3.2.1 Introduction sur les notebooks
5.3.2.2 Propriétés recherchées pour un notebook
5.3.3 Automatisation d’une expérience
5.3.3.1 Découpage d’une expérience en étapes
5.3.3.2 Expérience séquentielle et script d’exécution
5.3.4 Garantie de reproductibilité d’une expérience
5.3.4.1 Intégration continue
5.3.5 Approvisionnement d’une expérience
5.3.6 Déploiement – Exécution et récupération des traces
5.3.6.1 Déploiement
5.3.6.2 Exécution
5.3.6.3 Récupération des traces
5.3.7 Exploitation des résultats
5.3.7.1 Mise en forme de traces brutes
5.3.7.2 Analyse des résultats
5.4 Conclusion
6 Conclusion et perspectives
6.1 Passerelle avancée pour les LLNs
6.1.1 Supervision
6.1.2 Mise en cache des réponses
6.1.3 Reproductibilité des expériences
6.2 Ouvertures
6.2.1 Mesure passive
6.2.2 Reverse Proxy Cache Adaptatif
6.2.3 Reproductibilité en simulations et expérimentations
6.3 Usages potentiels
6.3.1 Recherche reproductible
6.3.2 Supervision passive
6.3.3 RPC dans un contexte industriel
A Collaborations extérieures
A.1 A scalable and self-configuring architecture for service discovery in the internet of things
A.2 Bounding Degrees on RPL
Bibliographie
Télécharger le rapport complet
