Réseau maillé sans fil à basse consommation énergétique : Luận văn ThS. Công nghệ thông tin

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 Mtre 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 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 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 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 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 Table des matières 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 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 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 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 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 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 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 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 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 (GW1) 6.6 Configuration des passerelles 2, et 6.6.1 Manipulations faire sur les capteurs avant de flasher le code en détaille 46 47 48 6.6.2 Téléchargement du code sur le capteur 70 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 Evolution de P TI(i) sans trafic de donnée Tableau comparatif de la probabilité d’émission des messages DIO Scénario de simulation noeuds Temps cumulé en ticks et energie consommée pour la transmission des contrôle 40 40 41 42 43 messages de 43 4.7 4.8 4.9 4.10 Scénario de simulation 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 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 10 Annexe1 : Les messages de controle du protocole RPL 6.3 Détailles des différents messages du protocole RPL – Le message DIO (DODAG Information Object) Ce message est initié par le LBR ou root du DODAG après son auto-configuration Il est envoyé en multicast et contient des informations permettant aux nœuds de découvrir l’existence d’une instance RPL, de conntre les paramètres de configuration de cette instance puis de choisir un nœud parent dans le DODAG en construction Le format du message DIO est le suivant : Figure 6.1 – Format du message DODAG Information Object [6] Le champ “RPLInstanceID” est un champ de 8-bits instancié par le root du DODAG et qui indique l’identifiant de l’instance RPL la quelle appartient le DODAG Le champ “Version Number” tient sur octet et contient un entier non signé répresentant le numéro de la version du DODAG Cette valeur est inscrite par le root Le champ “Rank” : un champs de 16-bits indiquant le rang du nœud ayant envoyé le DIO Le champ “G” est incrit sur un seul bit, il permet de savoir si le fonctionnement du DODAG est en mesure de satisfaire les exigences de l’application Lorque ce champ est instancié, cela signifie que le DODAG est connecté un autre réseau Le champ “MOP” (Mode of Operation) : ce champ définie le mode d’opération de l’instance RPL en cours Tous les nœuds qui se joingnent au DODAG de l’instance RPL, doivent être en mesure de fonctionner sous ce mode opératoire, dans le cas contraire, ils seront considérés comme des feuilles Le champ “Prf”, tenant sur trois bits, contient un entier non signé permettant aux noeuds dans le cas de plusieurs root d’une même instance RPL, de privilégier un seul Le champ “DTSN”, codé sur un octet, il contient le numéro de séquence du message DIO Le numéro de séquence permettra aux noeuds de sassurer que le message DIO reỗu est jour Le champ “Flags” tient sur un octet et contient les valeurs des flags Lorsqu’il est mis zéro par l’émetteur, il est ignoré la réception Le champ “Reserved” est codé sur un octet Il est initialisé zéro l’envoie puis ignoré la reception 58 Le champ “DODAGID” contient l’adresse IPv6 du root du DODAG codé sur 128 bits Ce champ permet didentifier de faỗon unique le DODAG Le champ “options”, permet d’utiliser une ou plusieurs options parmi les options possible dans un DIO Les options des messages DIO sont détaillés dans l’annexe1 sous-section 6.3.1 – Le message DAO (DODAG Destination Advertisement Object) Ce message est utilisé pour propager vers le haut (en direction du root), l’information sur les destinations dans le DODAG Dans un fonctionnement “Storing mode”, le message DAO est envoyé du nœud fils vers le parent sélectionné dans des paquets unicast En fonctionnement “Non-Storing mode” le message DAO est envoyé directement vers le root du DODAG en passant par le parent directe dans des paquets unicast Dans certains cas (lorsque le champ K est defini), l’envoie d’un message DAO un nœud parent entrnera immédiatement l’envoie d’un message DAO_ACK du parent vers le fils Le format du message DAO et ses différentes options sont detaillés dans la suite Figure 6.2 – Format du message DAO [6] Le champ “RPLInstanceID” est un champs de bits, contenant les informations sur l’instance RPL la quelles appartient le DODAG Le champ “K”, est un flag codé sur un bit Il indique si le noeud ayant envoyé le DAO ettend un message DAO_ACK en retour Le champ “D”, c’est un falg codé sur un bit et indiquant si le champ facultatif “DODAGID*” est présent ou pas Ce flag doit être definie lorsque l’identifiant de l’instance RPL est seulement utilisé un niveau local Le champ “Flags”, c’est un champ qui occupe bits et reservé pour les flags Il est mis zero l’envoi puis ignoré la reception Le champ “DAOSequence”, ce champ contient le numéro de séquence du message DAO Ce champ est incrémenté par le noeud chaque fois qu’il envoi un message DAO Le champ “DODAGID*” contient un entier non signé de 128 bits indiqué par le root et qui permet didentifier de faỗon unique le DODAG Le champ Option(s), ce champ est occupé par les différentes options du messages DAO Les options utilisées par les messages DAO sont détaillées dans l’annexe section 6.3.2 – Le message DAO_ACK (Destination Advertisement Object Acknowledgement) 59 C’est un message d’acquittement envoyé par un nœud parent (root du DODAG ou un nœud du DODAG ayant un fils) en rộaction un message DAO reỗu de son fils Le format d’un message DAO_ACK est le suivant : Figure 6.3 – Format du message DAO-ACK [6] Le champ “RPLInstanceID” codé sur bits indique l’identifiant de l’instance RPL associée au DODAG diffusé dans le message DIO précédemment envoyé par le nœud ayant émis l’ACK ; Le champ “D” est un flag qui indique la présence du champ optionnel DODAGID Ce flag est généralement activé lorsque l’identifiant de l’instance RPL est un identifiant local “Reserved” est un cahmp de bits réservé pour d’éventuel flags Le champ “DAOSequence” contient le numéro de séquence du message La valeur de ce champ sera incrémenté chaque fois qu’un nouveau message DAO est reỗu Le champ status est utilisộ pour indiquer au nœud récepteur si son message DAO a été accepté ou pas Ce champ tient sur bits et la valeur décimale de ces bits signifie l’un des trois messages suivants : – : une acception du parent sans réserve ; – 1-127 : une acceptation du parent mais celui-ci demande au nœud fils concerné de trouvé un parnet alternatif ; – 128-255 : rejet de la requête formulée dans le message DAO Le nœud qui a émis le message DAO-ACK n’est pas prêt devenir un nœud parent pour le nœud lui ayant transmis le message DAO ; Le champ “DODAGID*” contient un entier non signé codộ sur 128 bits Il permet didentifier de faỗon unique le DODAG Ce champ est présent seulement lorsque le champ ”D” est activé – Le message DIS (DODAG Information Sollicitation) Les messages DIS sont utilisés par les nœuds du réseau pour solliciter des informations sur le DODAG, en l’occurrence des messages DIO La structure du message DIS est la suivante : Figure 6.4 – Format du message DIS [6] 60 Le champ “Flags” est codé sur bits et destiné contenir la valeur du flag Selon les spécifications effectuée dans la RFC 6550 [6], ce champ est pour le moment inutilisé Il est initialisé zéro par le nœud l’origine du message puis ignoré par le récepteur Le champ “Reserved” est un champ réservé et initialisé zero pendant l’envoie du message La valeur contenu dans ce champ est ignoré la reception du message Le champ “Options” contient les options définies par le noeud pendant l’envoie du message Trois options sont possible, mais seulement deux peuvent être utiliser la fois Les options utilisées par les messages DIS sont détaillées l’annexe1 6.3.3 6.3.1 Les différentes options possible dans un message DIO sont : L’option “Pad1” L’option Pad1, elle est utilisée pour insérer un seul octet de bourrage dans le message Lorsqu’on a besoin de plus d’un seul octet de bourrage, l’option PadN sera utilisée Figure 6.5 – Format de l’option Pad1[6] L’option “PadN” Cette option est utilisée lorsqu’on a besoin d’insérer plus d’un octet de bourrage dans le message Les données contenu dans l’option PadN doivent être ignorées la réception Figure 6.6 – Format de l’option PadN[6] L’option “DAG Metric Container” Le format de cette option est la suivante : Figure 6.7 – Format de l’option “DAG Metric Container”[6] Cette option est utilisée pour reporter la valeur de la métrique tout au long du chemin emprunter par le message DIO dans le DODAG On peut utiliser les métriques telle que le nombre de sauts, la qualité des lien et le nombre de retransmission attendu Le champ “type” est égale 0x002 pour cette option Le type permet de distinguer les différentes options les uns des autres 61 Le champ “Option Length” contient la taille en octet des données de la métrique Le champ “métique Data” contient les données de la métrique L’option “Routing Information” Cette option contient les informations permettant aux noeuds d’effectuer une découverte du voisinage la réception du message Les informations de ce champ sont instanciées par le root du DODAG et ne sont pas modifiées durant le chéminement du message La structure de cette option se présente comme suit : Figure 6.8 – Format de l’option “Routing Information”[6] Le champ “Type” vaut 0x003 et permet d’identifier cette option parmi les autres Le champ “Option Lenght” répresente la taille en octets de l’option Le champ “Prefix Length”, un entier non signé sur huit bits Il contient la taille du préfixe du DODAG Les deux champs “Resvd” sont des champs reservés et non utilisé Ils sont mis zero l’émission et ignoré la réception Le champ “Prf”, contient l’indicateur de préférence d’une route Il tient sur deux bits Le champ “Route Lifetile” codé sur 32 bits, il contient le temps en secondes pendant le quel le préfixe est valide pour la determination d’une route Le champ “Prefix (Variable Lenght)” contient le prefixe d’une adresse IPv6 Dans ce champ, les bits qui ne font pas partir du préfixe sont reservés et mise zéro l’émission L’option “DODAG Configuration” Le format de cette option se présente comme suit : Figure 6.9 – Format de l’option “DODAG Configuration”[6] Cette option permet de transmettre aux noeuds du réseau, toutes les informations nécessaire pour la configuration du DODAG Les informations transportées par cette option ne changent pas presque pas dans un même DODAG, pour cette raison, certains messages DIO peuvent se passer 62 de cette option L’ option est modifiable seulement par le root Le contenu des différents champ est présenté ci-dessous Le champ “Type = 0x04” contient le type qui permet d’identifier cette option parmi les autres Le champ “option Lenght” contient la taille en octet de l’option Le champ “Flags” est un champ réservé pour les flags Le champ “DIOIntDoubl”, definie la valeur maximale (Imax) que le timer de l’algorithme Trickle va utiliser Le champ “DIOIntMin” indique la valeur minimale (Imin) du timer de l’algorithme Trickle Le champ “DIORedun” contient la valeur de la constante K que utilise l’algorithme Trickle pour autoriser ou interdire l’envoie d’un message DIO dans un intervalle donné Pendant un intervalle I si un nud reỗoit plus de K messages DIO, ils seront tous supprimés Le champ “MaxRankIncrease” definie la valeur maximale du rang que peut avoir les nœuds dans le DODAG Le champ “MinHopIncrease” contient l’augmentation minimale du rang entre un noeud et un de ses noeuds parent Le champ “OCP” permet d’identifier la fonction objectif utilisée pour la construction du DODAG Le champ “Reserved” un champ réservé Ce champ est initialisé zéro l’emission et ignoré la réception Le champ “Def.Lifetime”, la durée de vie par défaut des routes au sein du DODAG Le champ “Lifetime Unit”, ce champ contient un entier non signé codé sur 16 bits Il fournit l’unité en sécondes pour exprimer la durée de vie d’une route dans RPL Dans un réseau stable, elle peut aller de plusieurs heures une journée L’option “Prefix Information” Cette option contient essentiellement les informations sur les préfixes du réseau Elle est utile pour la decouverte du voisinage du protocole IPv6 et l’autoconfiguration d’adresses “Stateless” La structure de cette option est la suivante : Figure 6.10 – Format de l’option “Prefix Information”[6] 63 Le champ “Type = 0x08” permet de distinguer cette option des autres Le champ “Option Length = 30” représente la taille de l’option en octets Le champ “Prefix Length” contient un entier non signé codé sur un octet Cet entier représente les premiers bits valides du préfixe Le champ “L” est un flag codé sur un bit Lorsqu’il est défini, il indique que ce préfixe peut être utilisé pour déterminer un lien actif Lorsque ce champ n’est pas instancié, l’option permettra plus de savoir les liens actif et inactif du préfixe Le champ “A”, codé sur un bit, il donne des informations sur les configurations possibles de l’adresse Lorsqu’il est défini, il indique que ce préfixe peut être utilisé pour la configuration d’adresse “Stateless” comme spécifié dans la [RFC 4862] Le champ “R”est un flag donnant des informations sur l’adresse du routeur Lorsque ce champ est défini, il indique que le champ du préfixe contient une adresse IPv6 complète attribuée au routeur d’envoi qui peut être utilisé comme parent dans une autre option d’une cible A la réception d’un message DIO, un noeud examine la fonction ojectif du DODAG en construction puis decide de joindre ou de ne pas joindre ce DODAG Il va par la suite diffuser ce message DIO en multicast puis envoyer un message DAO au nœud lui ayant transmis le DIO s’il décide de se joindre Le champ “Reserved1” est un champ qui occupe bits mais non utilisé Ce champ est mis Zéro l’envoie puis ignoré la reception Le champ “Valid Lifetime”, il contient un entier non signé codé sur 32 bits Cet entier représente le temps en secondes pendant le quel le prefix peut permettre de determiner un lien actif Le champ “Preferred Lifetime”, contient un entier non signé codé sur 32 bits Il représente la durée du temps en secondes (par rapport au moment où le paquet est envoyé) que des adresses générées partir du préfixe via une autoconfiguration d’adresse “Stateless” reste préférable Il est noté que la valeur de ce champ ne doit pas depasser la valeur du champ “Valid Lifetime” pour éviter d’avoir une préférence qui n’est plus valide Le champ “Reserved2” est un champ inutilisé Il est mis zéro l’envoi puis ignoré la reception Le champ “Prefix”, contient une adresse IPv6 ou un préfixe d’une adresse IPv6 Le champ “Prefix Length” mentionné plus haut contient les premiers bits valides du préfixe Les bits du champ “Prefix” situés après la taille du préfixe doivent être initialiser zéro l’envoie puis ignoré la reception Un noeud fonctionant en “Non-Storing mode” s’abstient d’envoyer de préfixe jusqu’à ce qu’il obtient une adresse possèdant un préfixe A partir de ce moment, il va diffuser son adresse complet en activant le flag R Lorqu’un noeud diffuse une adresse complète avec le flag “R” activé, ces fils peuvent se servir de cette adresse pour déterminer les informations de transit sur le DODAG 64 6.3.2 Les différentes options des messages DAO Les options utilisées dans les messages DAO sont : “Pad1”, “PadN”, “RPL Target”, “Transit Information” et “RPL Target Descriptor” Les options Pad1 et PadN Ces deux options sont utilisée pour insérer un (Pad1) ou plusieurs (PadN) octet(s) de bourrage dans le message Le format des options Pad1 et PadN des messages DAO sont identique ceux des messages DIO que nous avons décris peu plus haut L’options “RPL Target” Cette option est utilisée pour indiquer une adresse IPv6 cible, un préfixe ou un groupe de multicast accessible sur le DODAG De faỗon gộnộrale, cette option des informations sur laccessibilitộ au niveau du DODAG Le format de l’option est indiquée sur la figure suivante Figure 6.11 – Format de l’option “RPL Target”[6] Le champ “Type = 0x05” permet d’identifier cette option parmi les autres Le champ “Option Length” représente la taille en octets de tout les champs qui compose cette option Le champ “Flags” codé sur un octet, est un champ reservé pour les flags Il est mis zéro l’émission puis ignoré la reception Le champ “Prefix length”, codé sur sur bits, il contient un entier non signé qui représente le nombre de bits du préfixe de l’adresse IPv6 Le champ “Target Prefix”, contient le préfixe de la cible Ce préfixe peut appartenir un seul nœud ou un ensemble de nœud qui sont atteignable partir d’un même préfixe L’options “Transit Information” Cette option est utilisée pour indiquer les attributs d’uns chemin vers une ou plusieurs destinations Ci-dessous, le format des différents champs de cette option 65 Figure 6.12 – Format de l’option “Transit Information“[6] Le champ “Type = 0x06” ce champ permet d’identifier l’option des autres options du message DAO Le champ “Option Length” indique la taille de l’option, cette taille permettra de savoir si le champ contenant l’adresse du parent est présent ou pas Dans le cas d’un fonctionnement en ”storing mode”, le champ de l’adresse du parent peut être supprimé Le champ “E”, ce champ est un flag qui indique si le root du DODAG redistribue des chemins externes au DODAG aux noeuds du réseau interne du DODAG Le champ “Flags” un champ de bits resevé pour les flags Il est mis zéro l’envoie puis ignoré la reception Le champ “Path Control” est utilisé pour limiter le nombre de parents aux quelq le message DAO peut être envoyé Le champ “Path Sequence” permet de savoir si les informations contenu dans le message sont mis jour Le champ “Path Lifetime” définit le temps durant le quel un préfixe pour une destination peut être conservée et considéré comme étant valide Le temps est mesuré en unités de durée de vie et est spécifique chaque implémentation Le champ “Parent Address”, c’est un champ facultatif contenant l’adresse du nœud parent L’options “RPL Target Descriptor” Cette option est utilisée pour qualifier une cible, ce qui est parfois appelé le «tagging» La structuration de l’option est la suivante : Figure 6.13 – Format de l’option “RPL Target Descriptor”[6] Le champ “Type = 0x09” sert l’identification de l’option Le champ “Opt Length” contient la taille de l’option 66 6.3.3 Les trois options possible dans les messages DIS sont présenterés en détaille ci-dessous L’option Pad1 L’option Pad1 est utilisée pour insérer un seul octet de bourrage dans le message Lorsqu’on a besoin de plus d’un seul octet, l’opton PadN sera utilisée Le format de l’option Pad1 est montré ci-dessous Figure 6.14 – Format de l’option Pad1[6] L’option PadN L’option PadN sert insérer plus d’un octet de bourrage dans le message Les données contenu dans l’option PadN doivent être ignorées la reception du message Le formet de cette option est comme suit : Figure 6.15 – Format de l’option PadN[6] Le champ “Option Lenght” contient le nombre N d’octets de bourrage Ce nombre N peut prendre une valeur comprise entre et La valeur signifie qu’il y a deux octets de bourrage et la valeur 5, indique octets de bourrage Le nombre maximale d’octets de bourrage autorisé est de L’option “Solicited Information” L’option “Solicited Information” est utilisée par un noeud pour solliciter des messages DIO dans son voisinage L’option contiendra la spécification des informations dont le noeud a besoin et qui fait l’objet du message DIS La structure de cette option est présentée ci-dessous : Figure 6.16 – Format de l’option “Solicited Information”[6] Le champ “type = 0x07” permet de distinguer cette option des autres 67 Le champ “Opt Length” contient la taille en octets de tous les champs de l’option Le champ “RPLInstanceID” est codé sur bits Lorsque ce champ est définie, il contient un entier non signé qui représente l’identifiant de l’instance RPL sollicité Le champ “V” est un flag qui représente le prédicat de la version Ce prédicat est vrai si le numéro de version du DODAG du récepteur du DIS est identique au numéro de version de la requête Lorsque ce champ n’est pas instancié, le champ “Version Number” n’est pas valide donc mis zéro l’émission puis ignoré la réception Le champ “I” est le prédicat de l’identifiant de l’instance RPL Ce prédicat est vrai lorsque la valeur du champ “RPLInstanceID” au niveau du noeud est identique la valeur du champ RPLInstanceID contenu dans le message DIS reỗu Si le champ “I” n’est pas coché, le champ “RPLInstanceID” n’est pas valide et doit être mis zéro l’émission et ignoré réception Le champ “D” est un prédicat de l’identifiant du DODAG (DODAGID) Ce prédicat est vrai si le parent du noeud a le même identifiant que celui contenu dans le champ “DODAGID” du message Le champ “Flag”, contient bits qui sont reservés Ce champ est mise zero l’envoi puis ignoré la réception Le champ “DODAGID”, lorsque ce champ est instancié, il contient l’identifiant du DODAG solicité par le noeud Le champ “Version Number”, s’il est assigné, il contient le numéro de version du DODAG sollicité par le noeud Annexe2 : Configuration du serveur et des passerelles 6.4 Configuration du Serveur Pour le serveur situé sur le réseau Internet, la passerelle par défaut pour joindre le réseau IPv4 contenant le mobilier urbain intelligent (MU2, MU3, MU4) est l’interface de la passerelle (GW1) ayant l’adresse IPv4 Le routage étant actif sur la passerelle 1, alors, elle se servira de la table de mappage géré par le logiciel Tayga pour transmettre les données au Sink du réseau 6LoWPAN qui se chargera d’acheminer les données vers le mobilier urbain intelligent en consultant sa table de routage 6.5 Configuration de la passerelle (GW1) La passerelle possède deux interfaces réseaux Une interface IPv4 communicant avec le serveur internet et une interface IPv6 relié au Sink du réseau 6LoWPAN 68 La première étape consiste installer le logiciel de translation d’adresses (NAT64) Tayga[22] sur la passerelle1 L’option « Grounded» étant activée dans les messages DIO du réseau 6LoWPAN, les données en direction du mobilier urbain intelligent seront acheminées par le Sink grâce un routage la source jusqu’à un capteur feuille (fi) qui est relié une passerelle en mesure de joindre le mobilier urbain intelligent En plus, les donnộes reỗu par le sink en provenance de ses fils et pour destination le serveur internet doivent être transmises la passerelle par le Sink 6.6 Configuration des passerelles 2, et Chacune des passerelles 2, et ont deux interfaces réseaux L’interface connectée au réseau 6LoWPAN possède une adresse IPv6 et celle connectée au réseau du mobilier urbain intelligent possède une adresse IPv4 L’interface IPv6 de chacune de ces trois passerelles est connectée un nœud feuille (fi) du réseau 6LoWPAN Les capteurs feuilles (fi) vont transmettre aux passerelles toutes les données utiles en provenance du Sink en direction du mobilier urbain Les passerelles vont également transmettre les données en provenance du mobilier urbain intelligent au capteur feuilles qui vont faire un acheminement par saut jusqu’au Sink Annexe3 : Expérimentation 6.6.1 Manipulations faire sur les capteurs avant de flasher le code – Première étape : connecté le capteur au PC l’aide du câble USB Une bte de dialogue est affichée par le PC pour informer de la reconnaissance du capteur Z1 connecté – Deuxième étape : voir sur quel périphérie USB le capteur sera accessible, pour cela faire : – 1- ls /dev/ttyUSB* (on verra s’il s’agit du 0, du ou ) Supposons qu’il s’agit du 0, faire ensuite – 2- sudo chmod 666 /dev/ttyUSB0 Si aucun message d’erreur n’est affiché, alors, le capteur est bien connecté et partir de on pourra lui donner des instructions en ligne de commande – Troisième étape : déterminer l’identifiant du capteur : dans le répertoire /home/user/contiki/examples/z1 faire : - make z1-motelist S’il y a un seul capteur qui est connecté, on verra un résultat semblable celui-ci : / /tools/z1/motelist-z1 Reference – Device Description – ——— —————- ——————————————— – Z1RC3394 /dev/ttyUSB0 Silicon Labs Zolertia Z1 69 Le chiffre en rouge est l’identifiant du capteur, le recopié quelque part pour la suite des configurations NB : on peut également décider de donner soit même des identifiants comme 1,2,3 aux capteurs, dans un tel scénario, on ne fera pas la troisième étape Le chiffre en rouge sera changé par l’identifiant que l’on souhaite donner au capteur – Quatrième étape : se place dans le répertoire /examples/z1 et imprimer l’identifiant sur le capteur l’aide de la commande suivante : – make clean && make burn-nodeid.upload nodeid=3394 nodemac=3394 && make z1-reset && make login – S’il y a plusieurs capteurs connecté la fois, ajouter l’argument de l’interface USB du capteur souhaiter comme suit : – make clean && make burn-nodeid.upload nodeid=3394 nodemac=3394 MOTES=/dev/ttyUSB0 && make z1-reset MOTES=/dev/ttyUSB0 && make loginMOTES=/dev/ttyUSB0 Le capteur affichera le message suivant si le flash a réussi : Starting ’Burn node id’ Burning node id 3394 Restored node id 3394 A partir de cette étape, le capteur est bien configuré et prêt recevoir le code de l’application uploader 6.6.2 Téléchargement du code sur le capteur – Il suffit maintenant de se placer dans le répertoire contenant le code flasher et suivre les étapes suivantes Cinquième étape : – Supposons que le code flasher se trouve dans le répertoire suivant :examples/ipv6/rplborder-router Une fois dans ce répertoire, exécuter les deux lignes de commandes suivantes : examples/ipv6/rpl-border-router$make TARGET=z1 savetarget examples/ipv6/rpl-borderrouter$make border-router.upload – Sixième étape : exécuter la commande suivante : examples/ipv6/rpl-border-router$ make z1reset && make connect-router Si le flash marche, le capteur affichera les messages suivant : – using saved target ’z1’ make -k -j 20 z1-reset-sequence using saved target ’z1’ make[1] : Entering directory ‘/home/a-linan/Desktop/Contiki/contiki-2.x/contiki-mirror/examples/ipv6/rplborder-router’ / / /tools/z1/z1-bsl-nopic –z1 -c /dev/ttyUSB0 -r MSP430 Bootstrap Loader Version : 1.39-goodfet-8 Use -h for help Use –fromweb to upgrade a GoodFET Reset device Done make[1] : Leaving directory ‘/home/a-linan/Desktop/Contiki/contiki2.x/contiki-mirror/examples/ipv6/rpl-border-router’ using saved target ’z1’ sudo / / /tools/tunslip6 aaaa : :1/64 ********SLIP started on “/dev/ttyUSB0” opened tun device “/dev/tun0” ifconfig tun0 inet ‘hostname‘ up ifconfig tun0 add aaaa : :1/64 ifconfig tun0 tun0 Link encap :UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr :127.0.1.1 P-t-P :127.0.1.1 Mask :255.255.255.255 inet6 addr : aaaa : :1/64 Scope :Global UP POINTOPOINT RUNNING NOARP MULTICAST MTU :1500 Metric :1 RX packets :0 errors :0 70 dropped :0 overruns :0 frame :0 TX packets :0 errors :0 dropped :0 overruns :0 carrier :0 collisions :0 txqueuelen :500 RX bytes :0 (0.0 B) TX bytes :0 (0.0 B) Rime started with address 193.12.0.0.0.0.4.7 MAC c1 :0c :00 :00 :00 :00 :04 :07 Contiki-2.5-1644-g7ca141b started Node id is set to 1031 CSMA ContikiMAC, channel check rate Hz, radio channel 26 Tentative link-local IPv6 address fe80 :0000 :0000 :0000 :c30c :0000 :0000 :0407 Starting ’Border router process’ ’Web server’ *** Address :aaaa : :1 => aaaa :0000 :0000 :0000 SIN : 10 Got configuration message of type P Setting prefix aaaa : : Server IPv6 addresses : aaaa : :c30c :0 :0 :9e fe80 : :c30c :0 :0 :9e Ladresse IPv6 du capteur calculộe de faỗon automatique est aaaa : :c30c :0 :0 :9e – A partir de là, on peut tester la connectivité entre ce capteur et le PC l’aide de la commande ping6 examples/ipv6/rpl-udp$ ping6 aaaa : :c30c :0 :0 :9e – PING aaaa : :c30c :0 :0 :9e(aaaa : :c30c :0 :0 :9e) – 56 data bytes 64 bytes from aaaa : :c30c :0 :0 :9e : icmp_seq=34 ttl=63 time=734 ms 64 bytes from aaaa : :c30c :0 :0 :9e : icmp_seq=35 ttl=63 time=3262 ms 64 bytes from aaaa : :c30c :0 :0 :9e : icmp_seq=36 ttl=63 time=2534 ms 64 bytes from aaaa : :c30c :0 :0 :9e : icmp_seq=37 ttl=63 time=3121 ms Une fois que le routeur de bordure est configuré et communique avec le PC, on pourra ajouter un sink et autant de nœud qu’on veux Pour ajouter un sink, on peut faire comme suit : – 1) Faire les configurations préliminaires sur le sink en reprenant les étapes 1,2,3 et expliquées plus haut – 2) Se placer dans le répertoire contenant le code flasher – Par exemple dans /home/user/contiki/examples/ipv6/rpl-udp – 3) Sauvegarder et flasher le code du sink comme suit : /examples/ipv6/rpl-udp$ make TARGET=z1 savetarget /examples/ipv6/rpl-udp$ make udp-server.upload MOTES=/dev/ttyUSB1 – 4) se connecté sur le sink pour voir les messages qui seront affichés make z1-reset MOTES=/dev/ttyUSB && make login MOTES=/dev/ttyUSB1 Pour ajouter des nœuds fils ou clients suivre les étapes suivantes : – 1) Se placer dans le répertoire contenant le code flasher Par exemple dans /home/user/contiki/examp udp – 2) Sauvegarder et flasher le code du sink comme suit : /examples/ipv6/rpl-udp$ make TARGET=z1 savetarget /examples/ipv6/rpl-udp$ make udp-client.upload MOTES=/dev/ttyUSB2 – BN :si on souhaite observer tous les messages échangés entre les nœuds et le sink, on doit déboguer le code avant de le flasher sur les capteurs Dans notre expérimentation, nous avons souhaité que chaque nœud fils ou client, envoi régulièrement des messages Hello suivi du numéro de séquence au sink qui les affiches la réception Le résultat que affiche le sink est le suivant : 71 Figure 6.17 – Capture d’écran des messages affichés 72