Tài liệu Réseau maillé sans fil à basse consommation énergétique

Mémoire de Stage de fin d’études Master Informatique Option Réseaux et Systèmes Communicants Rédigé par Mr. Tall HAMADOUN Réseau maillé sans fil à basse consommation énergétique Encadrants Mr. Hervé Rivano Chargé de Recherche INRIA Mr. Khaled Boussetta Maître de Conférences INRIA/Université de Paris 13 Remerciements Le travail réalisé tout au long de ce stage n’a été possible qu’avec l’aide et le soutien de nombreuses personnes. Je profite donc de l’occasion qui m’est donnée ici, pour leur exprimer toute ma gratitude. Au niveau du Laboratoire CITI : – Je tiens tout d’abord à remercier M.Hervé RIVANO et M.Khaled BOUSSETTA pour leur encadrement, leur disponibilité et les nombreux et précieux conseils qu’ils m’ont prodigué au cours de ces six mois de stage. – Je remercie très sincèrement le professeur Fabrice VALOIS, chercheur au Laboratoire CITI, et mon encadrant M.RIVANO pour les échanges très fructueux que nous avons eu au moment où je cherchais le stage. – Je voudrais également remercier tous le personnel du CITI au près du quel je suis resté pendant ces 6 mois de stage. En particulier Gaëlle TWORKOWSKI et les stagiaires Julien DELABORDE et Tristan POURCELOT avec qui j’ai le plus échangé durant ma présence au CITI. Du coté de l’IFI et du Bureau Asie pacifique de l’AUF : – Mes remerciement à la Direction de l’IFI et à tous les enseignants pour les précieux cours reçus pendant les trois semestres passer au sein de l’institut. – Je dis un grand merci à M.Victor MORARU et à M.Van Nam NGUYEN, mes deux encadrants du module Travail Personnel Encadré du Master 1, pour leur encadrement et les conseils reçus pendant les 2 semestres de travail commun. – Je remercie également M.Alain BOUCHER, ex Directeur des études de l’IFI pour tous conseils pratiques qui m’ont permis de bien préparer mon voyage au Vietnam après mon admission à l’IFI. – Mes remerciements au Bureau Asie-Pacifique de l’AUF pour m’avoir permis de poursuivre mes études très loin de mon pays, le Burkina Faso. – Je remercie ma famille et mes amis pour leur irremplaçable et inconditionnel soutien. – Enfin, bien sûr, je remercie tous mes camarades de classe à l’IFI pour les très bonnes relations que nous avons entretenus pendant les trois semestres d’études à l’IFI. 2 Résumé Dans ce travail, nous nous sommes intéressé à un cas d’usage où le fonctionnement des terminaux du mobilier urbain intelligent est géré par un serveur situé sur le réseau Internet. Dans le cas d’un déploiement, il n’est pas toujours possible de garantir une connectivité directe de ces terminaux avec le réseau Internet, ni filaire, ni en étant à portée d’un point d’accès radio. Pendant ce stage, nous avons étudié l’usage d’un réseau maillé 6LoWPAN de capteurs Z1 pour assurer la connectivité entre le serveur du réseau internet et les terminaux du mobilier urbain intelligent. Les capteurs du réseau 6LoWPAN fonctionnent sur des batteries, donc très limités en ressources énergétiques. Dans un premier temps, nous avons focalisé notre étude sur la minimisation de la consommation énergétique du réseau de capteurs en réduisant le trafic de contrôle du protocole de routage RPL (Routing Protocol for low power and Lossy network) puis en optimisant les cycles de réveil-sommeil (Duty-Cycle) des capteurs. Dans une seconde partie, nous avons étudié le mécanisme de fonctionnement des passerelles qui vont assurer d’une part la connectivité entre le serveur Internet et le réseau 6LoWPAN et d’autre part entre le réseau 6LoWPAN et le mobilier urbain intelligent. Nous avons enfin mis en place une plate-forme d’expérimentation sur des capteurs Zolertia Z1 pour montrer le fonctionnement de notre infrastructure. L’étude sur l’optimisation de la consommation énergétique a été faite, par méthode analytique et par des simulations à l’aide du simulateur Cooja associé au système d’exploitation des capteurs Contiki OS. Les résultats obtenus permettent de dire que lorsque le réseau est assez stable et que le trafic de données est très sporadique alors on peut espérer une durée d’autonomie d’environ 18mois pour chaque capteur alimenté par deux batteries de type LR6 AA1,5V de 15390 Joules. Mots clés : Réseau de capteurs, 6LoWPAN, RPL, trafic de contrôle, Consommation énergétique, DutyCycle, capteurs Z1 3 Abstract The operation of the smart urban furniture is manage by a server connected to the internet network. In the deployment of this infrastructure, it is a big challenge to ensure the connectivity between the server and the urbain terminals. In this subject, we study how to use a 6LoWPAN sensor network to connect the urban terminals to the internet server. The sensors are battery powered, so we have to optimize the energy consumption of the network’s nodes to avoid the discharge of batteries leading to a network outage. In this report, we optimize the nodes energy consumption by reducing the RPL routing protocole control message and reducing the sensors Duty-Cycle by puting the sensors in the sleep mode most of the time. After optimizing the motes energy consumption, we studied how to configure the gatways to route data between the sensor network and the internet server. we also made an experimentation using real Zolertia z1 motes. We get them communicate with a personal computer using IPv6 protocole. we conducted analytical studies and simulations with Cooja simulator of Contiki OS. Our result shown that, using two (02) LR6 AA1,5V Batteries, if the data frequecy is low we can get te Zolertia z1 motes to work for 18 months before the batteries to be decharge. Key words : sensors network, 6LoWPAN, control message and energy consumption 4 Table des matières 1 Introduction 1.1 Contexte . . . . . . . . . 1.2 Problématique . . . . . . 1.3 Objectif . . . . . . . . . 1.4 Motivation . . . . . . . . 1.5 Environnement du stage 1.6 Organisation du rapport . . . . . . 11 11 12 12 12 13 13 . . . . . . . . . . . . . . . . 14 14 15 16 16 17 18 18 18 20 20 20 22 23 24 25 25 3 Optimisation de la consommation énergétique 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Mécanisme du Duty-Cycle pour les capteurs . . . . . . . . . . . . . . . . . . 28 28 28 28 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Contexte technologique 2.1 Généralités sur les réseaux de capteurs . . . . . . . . . . . . . . . 2.2 La norme IEEE 802.15.4 et les réseaux 6LoWPAN . . . . . . . . . 2.2.1 La norme IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . 2.2.1.1 La couche physique . . . . . . . . . . . . . . . . . 2.2.1.2 La sous-couche MAC . . . . . . . . . . . . . . . . 2.3 La technologie 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . 2.3.1 La couche d’adaptation 6LoWPAN . . . . . . . . . . . . . 2.3.2 Le mécanisme de compression des entêtes des paquets IPv6 2.4 Le routage dans les réseaux de capteurs . . . . . . . . . . . . . . . 2.4.1 Le protocole RPL . . . . . . . . . . . . . . . . . . . . . . . 2.4.1.1 Procédure de construction du DODAG . . . . . . 2.4.1.2 Les différentes métriques du protocole RPL . . . 2.4.1.3 Les modes de fonctionnement du protocole RPL . 2.4.1.4 Les messages de contrôle du protocole RPL . . . 2.4.1.5 Mécanisme de réparation du DODAG . . . . . . 2.4.2 Le fonctionnement de l’algorithme Trickle . . . . . . . . . 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 Réduction du pourcentage du Duty-Cycle pour économiser l’énergie 3.2.2 Économie d’énergie par l’optimisation du trafic de contrôle . . . . . . . . . . Modélisation de la consommation énergétique des capteurs . . . . . . . . . . . . . . h i 3.3.1 Réduction de la probabilité P TI(i) d’émission des messages de contrôle . . 3.3.1.1 Utilisation d’un modèle analytique . . . . . . . . . . . . . . . . . . 3.3.2 Détermination de la valeur de D qui optimise la consommation énergétique 29 31 33 36 36 37 4 Simulations et Résultats 4.1 L’environnement de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Le système d’exploitation ContikiOS et le simulateur Cooja . . . . . . . . . . . . . . 4.2.1 Optimisation du trafic de contrôle par simulation . . . . . . . . . . . . . . . 4.2.2 Vérification de la rélation entre k et N Deg sur un scénario de trois nœuds . 4.2.3 Les valeurs de D et la consommation énergétique du réseau . . . . . . . . . . 4.2.3.1 Consommation énergétique pour un scénario de 5 nœuds en ligne . 4.2.3.2 Comparaison de la consommation du CPU et de la Radio sur 24heures de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3.3 Evolution de la consommation en fonction des intervalles de Trickle 4.2.4 Temps de convergence du réseau . . . . . . . . . . . . . . . . . . . . . . . . 39 39 39 40 42 44 44 5 Plate-forme expérimentale 5.1 La plate-forme des capteurs Z1 . . . . . . 5.2 La plate-forme des passerelles, Sheevaplug 5.3 Vue globale du réseau . . . . . . . . . . . . 5.4 Scénario expérimenté . . . . . . . . . . . . . . . . 50 50 50 51 52 . . . . . . . 54 54 54 55 55 58 61 65 . . . . . 67 68 68 69 69 3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Conclusion et perspectives 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Bref résumé : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Bilan : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Détailles des différents messages du protocole RPL . . . . . . . . . . . 6.3.1 Les différentes options possible dans un message DIO sont : . . 6.3.2 Les différentes options des messages DAO . . . . . . . . . . . . 6.3.3 Les trois options possible dans les messages DIS sont présenterés ci-dessous. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Configuration du Serveur . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Configuration de la passerelle 1 (GW1) . . . . . . . . . . . . . . . . . . 6.6 Configuration des passerelles 2, 3 et 4 . . . . . . . . . . . . . . . . . . . 6.6.1 Manipulations à faire sur les capteurs avant de flasher le code . 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en détaille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 47 48 6.6.2 Téléchargement du code sur le capteur . . . . . . . . . . . . . . . . . . . . . 70 7 Table des figures 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 Architecture d’un nœud capteur [21] . . . . . . . . . . . . . Exemple de réseau de capteurs . . . . . . . . . . . . . . . . . Table des fréquences et de bande passante de IEEE 802.15.4. Compression HC1 d’en-tête IPv6 avec 6LoWPAN [7] . . . . Compression IPHC d’en-tête IPv6 avec 6LoWPAN [7] . . . . Réseau physique utilisé pour construire le DODAG[8] . . . . Diffusion des DIO par le LBR [8] . . . . . . . . . . . . . . . Choix du LBR comme noeud parent [8] . . . . . . . . . . . . Poursuite de la construction du DODAG [8] . . . . . . . . . DODDAG final construit par RPL [8] . . . . . . . . . . . . . Fonctionnement en ”Non-Storing mode ”du protocole RPL . Fonctionnement en “Storing mode” du protocole RPL . . . . Algorithme de Trickle . . . . . . . . . . . . . . . . . . . . . . Fonctionnement de Trickle sans inconsistance . . . . . . . . . . . . . . . . . . . . . . 14 15 17 19 19 21 21 21 22 22 23 24 26 27 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Evolution de la consommation énergétique en fonction du Duty-Cycle [2] . . . . . . Consommation énergétique en fonction du Duty-Cycle et du nombre de nœuds [2] . Énergie consommée en fonction de la méthode d’assignation du Duty-Cycle[3] . . . Influence des messages de contrôle sur le Duty-cycle dans RPL[10] . . . . . . . . . . Pourcentage des messages DIO en fonction de la contance k de l’algorithme Triclke[5] Émission des messages de contrôle dans un scénario à trois nœuds . . . . . . . . . . Fonctionnement du module radio sur un intervalle I . . . . . . . . . . . . . . . . . . Emission des messages DIO sur une ériode de D + 2CCA ms . . . . . . . . . . . . . 30 30 31 32 32 34 34 38 4.1 4.2 4.3 4.4 4.5 4.6 Fenêtre de simulation et choix du firmware sur Cooja . . . . . . . . . Compilation et lancement de la simulations sur Cooja . . . . . . . . . h i Evolution de P TI(i) sans trafic de donnée . . . . . . . . . . . . . . . Tableau comparatif de la probabilité d’émission des messages DIO . . Scénario de simulation à 3 noeuds . . . . . . . . . . . . . . . . . . . . Temps cumulé en ticks et energie consommée pour la transmission des contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 40 41 42 43 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . messages de . . . . . . . . . . . . . 43 4.7 4.8 4.9 4.10 Scénario de simulation à 5 noeuds . . . . . . . . . . . . . . Consommation énergétique sur 10h30 et19h30 de réseau . Évaluation de l’énergie consommée par le CPU et la Radio Consommation pour chaque phase de l’algorithme Trickle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 45 46 47 5.1 5.2 5.3 5.4 Les capteurs Zolertia Z1 . . . . . . . . . . Passerelles Sheevaplug . . . . . . . . . . . Scénario d’interconnexion 6LoWPAN-IPv4 Scénario de l’expérimentation . . . . . . . 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17 Format du message DODAG Information Object Format du message DAO [6] . . . . . . . . . . . Format du message DAO-ACK [6] . . . . . . . . Format du message DIS [6] . . . . . . . . . . . . Format de l’option Pad1[6] . . . . . . . . . . . . Format de l’option PadN[6] . . . . . . . . . . . Format de l’option “DAG Metric Container”[6] . Format de l’option “Routing Information”[6] . . Format de l’option “DODAG Configuration”[6] . Format de l’option “Prefix Information”[6] . . . Format de l’option “RPL Target”[6] . . . . . . . Format de l’option “Transit Information“[6] . . Format de l’option “RPL Target Descriptor”[6] . Format de l’option Pad1[6] . . . . . . . . . . . . Format de l’option PadN[6] . . . . . . . . . . . Format de l’option “Solicited Information”[6] . . Capture d’écran des messages affichés . . . . . . 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 51 52 52 [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 59 60 60 61 61 61 62 62 63 65 66 66 67 67 67 72 Liste des tableaux 3.1 Résultats statistiques de la méthode analytique . . . . . . . . . . . . . . . . . . . . 37 4.1 Evolution de P TI(i) en fonction du degré y et de k selon le modèle analytique . . . 41 4.2 4.3 Evolution de P TI(i) avec trafic de données . . . . . . . . . . . . . . . . . . . . . . . 41 Temps de convergence du réseau en fonction de la valeur de D . . . . . . . . . . . . 48 h i h i 10 Chapitre 1 Introduction 1.1 Contexte Les réseaux radio maillés sont composés de routeurs radio interconnectant des terminaux mobiles ou fixes à un ou plusieurs points d’accès du réseau Internet. Dans ces réseaux de routeurs radio, les fonctionnalités de routage et de communication radio sont très coûteuses en énergie. La maximisation de la durée de vie du réseau est une question fondamentale à la quelle il faut trouver une réponse adéquate. Avec la miniaturisation croissante des équipements électroniques et les progrès réalisés dans les technologies de communication sans fil, on note une émergence des capteurs sans fil (Micaz, TelosB, Zolertia Z1) à faible coût avec une consommation énergétique raisonnable. L’objectif de ce stage est d’étudier un cas particulier d’interconnexion de terminaux fixes, du mobilier urbain intelligent à des points d’accès du réseau Internet en utilisant un réseau de capteurs maillé. Le mobilier urbain intelligent est composé de panneaux d’affichage électronique qui diffusent des informations à l’attention des usages urbains. Par exemple, sur la météo, l’état du trafic ou des événements culturels. Un serveur dans le réseau Internet envoie ce flux de trafic sporadique aux terminaux fixes du mobilier urbain intelligent qui l’affichent. En retour, ceux-ci renvoient au serveur des rapports d’état succincts et périodiques. L’idée de ce projet est d’exploiter des techniques bien maîtrisées dans les réseaux de capteurs autonomes en énergie pour acheminer les données entre les terminaux fixes du mobilier urbain intelligent et les points d’accès du réseau Internet. L’utilisation de noeuds de relais tels que ceux disponibles dans les capteurs sans fil est une alternative au déploiement de routeurs mesh coûteux et complexes à gérer. L’objectif de ce stage est 1) de montrer la faisabilité de notre solution et 2) d’étudier et d’optimiser l’autonomie du réseau. 11 1.2 Problématique Lorsque qu’on veut contrôler le fonctionnement des terminaux du mobilier urbain intelligent par un serveur situé sur le réseau internet, il n’est pas toujours possible de garantir une connectivité directe de ces terminaux au réseau Internet, même en étant à portée d’un saut d’un point d’accès radio. De cette contrainte est né l’idée d’utiliser un réseau maillé multi sauts de capteurs sans fils pour assurer la connectivité entre les terminaux et le réseau Internet. Cette idée de passer par un réseau maillé de capteurs pour le relayage d’informations soulève les questions fondamentales suivantes : – Les capteurs du réseau maillé fonctionnent sur des batteries, quel doit être le mode de fonctionnement (Duty-Cycle, fréquence d’envoi des messages de contrôle et des données) des capteurs pour optimiser la consommation énergétique et allonger la durée de vie du réseau ? – Quel type d’interfaces ou passerelles doit on choisir pour interconnecter d’une part le réseau Internet au réseau maillé de capteurs et d’autre part le réseau maillé au mobilier urbain intelligent ? – Quelle peut être la nature du trafic supporté et les garanties de qualité de service que peut fournir le réseau constitué ? Les réponses à cette problématique seront données dans la suite du présent rapport. 1.3 Objectif – Le but de ce travail est de construire un réseau maillé à base de capteurs qui assure l’interconnexion des équipements du mobilier urbain intelligent avec des points d’accès du réseaux internet. Les capteurs du réseau maillé étant alimentés par des batteries avec une capacité énergétique limitée, nous devons trouver les bons paramètres de fonctionnement pour ce réseau maillé afin de prolonger la durée de vie de l’ensemble du réseau construit. – Le présent rapport vise à présenter les différentes méthodes analytiques, de vérification et de validation notamment les simulations et expérimentations réalisées pour vérifier et valider la solution proposée puis tester les performances de la solution apportée au problème soulevé par le sujet. 1.4 Motivation Mon choix pour ce sujet découle d’une part, de l’intérêt et l’importance que j’accorde aux réseaux de capteurs. Pendant mes cours de Master 2, j’ai beaucoup aimé le module sur les réseaux spontanés avancés et en particulier les réseaux de capteurs à cause de son vaste domaine d’application notamment, applications militaire, médicale et systèmes de surveillance d’habitation. D’autres part, ce sujet comporte une importante partie pratique, toute chose qui va me permettre de faire 12 des manipulations directes sur les capteurs et les autres équipements connexes du réseau à mettre en place. 1.5 Environnement du stage Le stage s’est déroulé du 29 avril au 31 octobre 2013 au sein de l’équipe INRIA/URBANET au Laboratoire du Centre d’Innovation en Télécommunication et Intégration de service (CITI) de l’Institut National des Sciences Appliquées (INSA) de Lyon en France. Mon travail a été encadré et orienté par M.Hervé Rivano, Chargé de Recherche INRIA et responsable de l’équipe Urbanet, qui est localisée au Laboratoire CITI à l’INSA Lyon, et par M.Khaled Boussetta, Maître de conférences à l’université Paris 13 et en délégation INRIA au sein de l’équipe Urbanet. 1.6 Organisation du rapport Le rapport est repartis sur six (06) chapitres. Le premier chapitre un (01) introduit le sujet et son contexte. Nous présentons ensuite le contexte technologique (généralités sur les réseaux de capteurs et les couches protocolaires) du sujet dans le chapitre 2. L’état de l’art sur les techniques d’optimisation de la consommation énergétique dans les réseaux limités en ressources est présenté en début du chapitre 3. Puis, nous présentons un modèle de consommation énergétique et discutons du choix des paramètres de fonctionnement du réseau afin de réduire la consommation de l’énergie des capteurs. Le chapitre 4 présente le simulateur utilisé ainsi que tous les résultats pertinents obtenus. Nous présentons les plate-formes matérielles (capteurs et passerelles) et l’expérimentation réalisée dans le chapitre 5. Enfin, le chapitre 6 donne les conclusions du travail puis ouvre des perspectives d’extension possible de ce travail. 13 Chapitre 2 Contexte technologique 2.1 Généralités sur les réseaux de capteurs Les avancées récentes dans la micro-électronique et la communication sans fil ont permis le développement des nœuds capteurs (Zolertia z1, TelosB, Micaz) de petite taille, à faible coût, contraints en énergie et en portée radio. Un réseau de capteurs, (Wireless Sensor Networks (WSNs), en anglais), est consisté de nœuds capteurs distribués qui s’auto-organisent pour former un réseau sans fil multi-sauts (voir Figure 2.2 ). L’objectif des capteurs est de récolter des mesures physiques (température, pression, humidité, luminosité, etc.) à partir de l’environnement où ils sont déployés, éventuellement, de les traiter localement et enfin de les envoyer vers un (ou plusieurs) nœud(s) spécifique(s) du réseau appelé sink ou puits. Chaque nœud capteur est composé de (voir figure 2.1) : – D’une unité de mesure chargée de transformer une grandeur physique récoltée dans l’environnement où il est déployé en une grandeur numérique. – D’un micro-processeur avec une faible puissance de calcul et un faible espace de stockage par rapport aux ordinateurs ou aux Smartphones. – D’un module de transmission sans fil avec une puissance radio limitée ne dépassant pas une centaine de mètres en extérieur et quelques dizaines de mètres en intérieur. – D’une batterie à capacité limitée et partagée par toutes les unités décrites ci-dessus. Figure 2.1 – Architecture d’un nœud capteur [21] 14 Un schéma générale d’un réseau de capteur peut être présenté comme l’indique la figure cidessous : Figure 2.2 – Exemple de réseau de capteurs Selon les auteurs de [21], les principaux défis dans un réseau de capteurs sont le : – Besoin d’un mécanisme pour préserver l’énergie au niveau des nœuds capteurs et ainsi maximiser la durée de vie du réseau – Besoin d’algorithmes distribués, localisés et collaboratifs pouvant être exécutés avec des micro-processeurs à faible puissance de calcul et une mémoire limitée. – Besoin d’un protocole de routage multi-sauts sur une topologie qui peut être dynamique (en cas de decharge de la batterie d’un noeud ou de l’instabilité de la qualité du lien radio) pour acheminer les données à partir des nœuds capteurs vers le nœud sink. Dans la majorité des réseaux de capteurs actuellement commércialisés, les deux premières couches (physique et MAC) reposent sur le protocole IEEE 802.15.4. Au dessus du protocole IEEE 802.15.4, plusieurs autres protocoles (ZegBee et 6LoWpAN) peuvent être utilisés pour assurer les fonctions d’interconnexion du réseau. Dans les sections suivantes, nous allons présenter en détaille d’une part, le protocole IEEE 802.15.4 et d’autre part, la technologique 6LoWPAN qui permet aux paquets IPv6 d’être envoyés et reçus par une couche physique et MAC qui fonctionnent en IEEE 802.15.4 2.2 La norme IEEE 802.15.4 et les réseaux 6LoWPAN Un réseau 6LoWPAN est un réseau de communication sans fil constitué d’un ensemble d’équipements ayant peu de ressources (CPU, mémoire, batterie), puis reliés au travers d’un réseau limité en débit (environ 250 kbit/s [9]). Le réseau 6LoWAN permet aux paquets IPv6 d’être envoyés et reçus via le protocole de communication IEEE 802.15.4. La taille minimale d’un paquet IPv6 est de 1280 octets avec une entête de 40 octets, cependant la taille des trames supportées par le protocole IEEE 802.15.4 est de 127 octets. Pour permettre au protocole IEEE 802.15.4 de transporter des paquets IPv6, des techniques d’encapsulation, de compression des entêtes des paquets IPv6 puis des mécanismes de fragmentation et de ré-assemblage 15 des paquets ont été proposés. Les différentes modifications sont effectuées dans une couche, appelée couche d’adaptation 6LoWPAN située entre la couche liaison de données et la couche réseau du modèle OSI (Open Systems Interconnection). Dans la suite de cette section, nous présenterons d’une part, la norme IEEE 802.15.4 et d’autre part la couche d’adaptation 6LoWPAN permettant la transmission de paquets IPv6 à travers le protocole IEEE 802.15.4. 2.2.1 La norme IEEE 802.15.4 La norme IEEE 802.15.4 concerne uniquement les deux premières couches du modèle OSI, à savoir la couche physique et la couche liaison de données. C’est un standard de communication à bas débit qui fait partie des réseaux locaux personnels (PANs). Elle a été conçue pour garantir une facilité d’installation, un maximum de fiabilité de transfert de données, une opérabilité à court terme, un faible coût et une consommation d’énergie optimisée. La conception reste aussi simple et flexible. Voici quelques caractéristiques générales du réseau : – Offre trois types de débits : 250 Ko/s, 40 Ko/s et 20 Ko/s. – Supporte les topologies en étoile, paire à paire et hiérarchique. – Distance maximale entre deux nœuds : 100 mètres. – Adresses MAC courtes (16 bits) ou étendues (64 bits). – Permet l’allocation de tranches de temps garanties (GTS) pour les applications nécessitant des garanties de délais déterministes. – Utilise le protocole CSMA/CA pour l’accès partagé au canal de transmission. – Implante les acquittements au niveau MAC pour maximiser la fiabilité. Le réseau intègre deux types de périphériques : les FFD (Full-Function Devices) et les RFD (Reduced- Function devices). Les premiers implantent toutes les primitives (fonctions) définies par la norme. Ils communiquent entre eux et avec les RFD alors que les derniers ne communiquent qu’avec des FFD. Un RFD est désigné pour les applications simples comme les interrupteurs d’électricité ou les senseurs infrarouges et n’ont généralement pas besoin de transmettre beaucoup de données. En conséquence, les RFD sont implantés avec le minimum de ressources possibles. Un FFD peut être soit un coordinateur, un coordinateur du PAN ou juste un simple périphérique. Le coordinateur est un nœud qui fournit des services de synchronisation et de gestion du réseau à travers la transmission périodique de trames spéciales appelées BEACONs. S’il est le coordinateur principal de tout le réseau, il est alors appelé coordinateur du PAN. 2.2.1.1 La couche physique Cette couche implante les procédures d’activation et de désactivation de l’émetteur-récepteur radio, de détection d’énergie, de détection de la qualité du lien, de sélection de canaux, de test 16 de disponibilité du canal (CCA, Clear Channel Assessment), de transmission et de réception de données du support physique. La norme offre deux modes de transmissions dans la couche physique. Le premier opère autour de la fréquence 2.4Ghz, le deuxième dans les fréquences 868/915 Mhz. Ils doivent coexister dans un équipement IEEE 802.15.4 Le tableau ci-dessous présente les différentes fréquences et la bande passante de IEEE 802.15.4 Figure 2.3 – Table des fréquences et de bande passante de IEEE 802.15.4. 2.2.1.2 La sous-couche MAC C’est la partie la plus importante de la couche liaison de données. Elle ressemble beaucoup à celle de IEEE 802.11. Toutefois, les spécifications de cette sous-couche ont été adaptées aux besoins des réseaux WPAN comme l’élimination du mécanisme RTS/CTS et l’ajout d’une nouvelle variante du protocole CSMA/CA. Cette couche implante les procédures de gestion des BEACONs, d’accès au canal, de gestion des GTS, de validation des trames, de délivrance des acquittements ainsi que les fonctions d’association et de désassociation. En plus, elle implante les mécanismes de sécurité nécessaires à la protection des données (principalement le cryptage AES). La sous couche MAC supporte deux modes d’accès qui peuvent être sélectionnés par le coordinateur du PAN : – Le mode sans BEACON, dans lequel l’accès est commandé par le protocole CSMA/CA non slotté (version classique de CSMA/CA). – Le mode avec BEACON, dans lequel des BEACONs sont régulièrement émis par le coordinateur du PAN (ainsi que d’autres coordinateurs) pour synchroniser les nœuds associés et pour identifier le PAN. Dans ce cas une structure de super-trame est définie entre deux transmissions successives de BEACONs. L’accès dans ce mode est commandé essentiellement par le protocole CSMA/CA slotté mais il implante également un mécanisme d’allocation de tranches de temps dites "GTS" pour les nœuds nécessitant des services garantis. Pour envoyer ou recevoir des paquets IPv6 sur le protocole IEEE 802.15.4, une nouvelle technologie appelée 6LoWPAN a été mis au point par un groupe de travail de l’IETF. Cette technologie peut être utilisée dans un réseau de capteurs pour permettre aux nœuds du réseau de fonctionner avec 17 le protocole IPv6. Dans la section suivante, nous présentons le mécanisme de fonctionnement de la technologie 6LoWPAN. 2.3 La technologie 6LoWPAN La technologie 6LoWPAN fournie des mécanismes d’encapsulation et de compression d’entêtes permettant aux paquets IPv6 d’être envoyés ou reçus via le protocole de communication IEEE 802.15.4. L’ensemble des modifications sur les paquets IPv6 sont effectuées dans une couche spéciale, appelée couche d’adaptation 6LoWPAN que nous présentons ci-dessus. 2.3.1 La couche d’adaptation 6LoWPAN Située entre la couche réseau et la couche liaison de données du modèle OSI, la couche d’adaptation 6LoWPAN assure la compression des entêtes des paquets, la fragmentation et le ré-assemblage des paquets IPv6 puis le routage des fragments de ces paquets IPv6. 2.3.2 Le mécanisme de compression des entêtes des paquets IPv6 6LoWPAN utilise diverses techniques de compression des entêtes des paquets IPv6. Parmi ces techniques, le mécanisme de compression nommé HC1. Pour réduire la taille de l’en-tête IPv6, HC1 omet des champs spécifiques de cette en-tête car ils sont considérés comme implicites (par exemple le champ version a toujours pour valeur 6). En rompant la règle principale du modèle OSI, qui implique que chaque couche doit être indépendante des autres, HC1 peut réutiliser les informations des autres couches (par exemple la longueur peut être calculée à partir de l’en-tête MAC). Dans la compression effectuée avec HC1, seul le champ “hop limit” de l’en-tête IPv6 n’est pas compressé . L’encodage HC1 utilise un pseudo en-tête de 2 octets : un octet pour déterminer le contenu suivant, le champ dispatch, (en-tête IPv6, en-tête de fragmentation, etc.) et un second octet pour décrire comment chacun des champs de l’en-tête IPv6 est compressé. Un troisième octet, placé après le champ d’encodage HC1, contient la valeur non compressée du champ “hop limit”. Ce mécanisme de compression est en mesure de réduire l’en-tête IPv6 de 40 à 3 octets. La figure ci-dessous compare une trame compressée à l’aide de ce mécanisme avec une trame IPv6 sans compression d’en-tête. 18 Figure 2.4 – Compression HC1 d’en-tête IPv6 avec 6LoWPAN [7] L’encodage HC1 compresse uniquement des préfixes de type lien local, de ce fait, les communications globales incluront systématiquement le préfixe IPv6 global sur 64 bits pour les champs source et destination de l’en-tête IPv6. Cette contrainte limite sérieusement l’utilité de l’encodage HC1, car l’intérêt d’intégrer IPv6 dans les réseaux de capteurs sans fil est de permettre des communications globales à l’échelle d’Internet. En conséquence, l’IETF a défini un nouveau mécanisme de compression appelé LOWPAN_IPHC. Le mécanisme LOWPAN_IPHC permet de coder les entêtes des paquets IPv6 sur 2 à 7 octets en fonction des usages. Pour une comunication sur des liens locaux, une reduction sur deux octets est effectuée pendant que sept octets sont utilisés pour la communication sur plusieurs sauts. Il est également possible de faire un codage sur 3 octets, dans ce cas présis, on utilise un pseudo en-tête sur deux octets, dont 3 bits sont utilisés par le champ “dispatch” et les 13 bits suivants indiquent pour chaque champ de l’en-tête IPv6, s’il est supprimé ou inclus sans changement. Même si le concept est identique à l’encodage HC1, la manière dont sont compressées les données est différente. Le schéma ci-dessous présente la compression sur trois octets . Figure 2.5 – Compression IPHC d’en-tête IPv6 avec 6LoWPAN [7] Dans les sections 2.2 et 2.3, nous avons présenté le protocole (IEEE 802.15.4) et le mécanisme (6LoWPAN) utilisés dans les couches basses d’un réseau de capteurs pour qu’il fonctionne avec le protocole IPv6. Au dessus de la couche d’adaptation 6LoWPAN déjà présenté se situe la couche réseau qui est chargée du routage des paquets dans un réseau de capteur. Au regard des contraintes énergétiques que connaissent les réseaux de capteurs, le routage doit être adapté avec un protocole de routage qui consomme moins d’énergie. Nous allons dans la section suivante présenter les protocoles de routage les mieux adaptés pour les réseaux de capteurs. 19 2.4 Le routage dans les réseaux de capteurs Le routage est une fonctionalité cruciale dans n’importe quel type de réseau. L’objectif d’un protocole de routage est de trouver une route entre deux nœuds du réseau. Dans un réseau de capteurs, en plus du problème liée au fonctionnement distribué, les nœuds du réseau sont sous une forte contrainte énergétique car fonctionnant sur des batteries. De ce fait les protocoles de routage multi-sauts comme AODV[26], DSR[27], OLSR[28] et DSDV déjà standardisés par l’IETF ne sont pas adaptés car ils entraînent une forte consommation énergétique des nœuds. Principalement, les protocoles de routages dans les réseaux limités en ressources doivent fonctionner sous un ensemble de contraintes que les protocoles de routage dédiés aux réseaux ad-hoc ne prennent généralement pas en compte. C’est pour cette raison qu’un nouveau protocole de routage appelé RPL[8] (Routing Protocol for Low power and Lossy Networks) beaucoup plus optimisé en terme de coût énergétique a été mis au point par le groupe de travail ROLL[25] (Routing Over Low power and Lossy Networks) de l’IETF. Le protocole RPL permet à la fois une communication de point à point (P2P), de point à multi-point (P2MP) et de multi-point à point (MP2P). Dans la section suivante, nous présentons dans les détailles le protocole RPL. 2.4.1 Le protocole RPL RPL est un protocole de routage IPv6 à vecteur de distance qui construit un DODAG (Destination Oriented Directed Acyclic Graph ) à l’aide d’une fonction objectif constituée de métriques et/ou de contraintes. La fonction objectif du routage n’impose pas un ensemble de métriques ou de contraintes à utiliser mais dicte des règles à respecter pour la formation du DODAG. 2.4.1.1 Procédure de construction du DODAG Dans un DODAG, les nœuds peuvent être regroupés en trois types en fonction des tâches qu’ils assument. – Le root, encore appelé LBR (Low Power and Lossy Network Border Router), il joue un rôle très important dans le réseau. Le root est à l’origine de l’envoi des messages DIO servant à la construction du DODAG. Il maintient les tables de routage permettant d’atteindre chaque noeud au sein DODAG. – Les nœuds parents ou routeurs, un nœud parent possède au moins un fils (un nœud de rang inférieur). Le noeud parent assure la circulation des informations entre le root et ses fils. – Les nœuds feuilles, ce sont des nœuds qui ne possèdent aucun fils. Ils sont seulement connectés à leur nœud parent qui les transmettent les informations en provenance du root du DODAG. Le graphe DODAG formé par le protocole RPL, est une topologie logique de routage construite à partir d’un réseau physique en utilisant un certains nombre de critères fournis par l’administrateur 20