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

de la consommation énergétique du réseau de capteurs en réduisant le trafic de contrôle du protocolede routage RPL Routing Protocol for low power and Lossy network puis en optimisant les

Mémoire de Stage de fin d’études

Mr Hervé Rivano Chargé de Recherche INRIA

Mr Khaled Boussetta Maître de Conférences INRIA/Université de Paris 13

Le travail réalisé tout au long de ce stage n’a été possible qu’avec l’aide et le soutien denombreuses 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 leurencadrement, leur disponibilité et les nombreux et précieux conseils qu’ils m’ont prodigué aucours 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

ó 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 Gặlle TWORKOWSKI et les stagiaires JulienDELABORDE 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 coursreç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 cadrants du module Travail Personnel Encadré du Master 1, pour leur encadrement et lesconseils reçus pendant les 2 semestres de travail commun

en-– Je remercie également M.Alain BOUCHER, ex Directeur des études de l’IFI pour tous seils pratiques qui m’ont permis de bien préparer mon voyage au Vietnam après mon admis-sion à l’IFI

con-– Mes remerciements au Bureau Asie-Pacifique de l’AUF pour m’avoir permis de poursuivremes é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 relationsque nous avons entretenus pendant les trois semestres d’études à l’IFI

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 quivont assurer d’une part la connectivité entre le serveur Internet et le réseau 6LoWPAN et d’autrepart 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 Z1pour 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 capteursContiki 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, Cycle, capteurs Z1

The operation of the smart urban furniture is manage by a server connected to the internetnetwork In the deployment of this infrastructure, it is a big challenge to ensure the connectivitybetween the server and the urbain terminals In this subject, we study how to use a 6LoWPANsensor network to connect the urban terminals to the internet server The sensors are batterypowered, so we have to optimize the energy consumption of the network’s nodes to avoid thedischarge of batteries leading to a network outage

In this report, we optimize the nodes energy consumption by reducing the RPL routing cole control message and reducing the sensors Duty-Cycle by puting the sensors in the sleep modemost of the time After optimizing the motes energy consumption, we studied how to configure thegatways to route data between the sensor network and the internet server we also made an experi-mentation using real Zolertia z1 motes We get them communicate with a personal computer usingIPv6 protocole we conducted analytical studies and simulations with Cooja simulator of ContikiOS

proto-Our result shown that, using two (02) LR6 AA1,5V Batteries, if the data frequecy is low wecan 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

1.1 Contexte 11

1.2 Problématique 12

1.3 Objectif 12

1.4 Motivation 12

1.5 Environnement du stage 13

1.6 Organisation du rapport 13

2 Contexte technologique 14 2.1 Généralités sur les réseaux de capteurs 14

2.2 La norme IEEE 802.15.4 et les réseaux 6LoWPAN 15

2.2.1 La norme IEEE 802.15.4 16

2.2.1.1 La couche physique 16

2.2.1.2 La sous-couche MAC 17

2.3 La technologie 6LoWPAN 18

2.3.1 La couche d’adaptation 6LoWPAN 18

2.3.2 Le mécanisme de compression des entêtes des paquets IPv6 18

2.4 Le routage dans les réseaux de capteurs 20

2.4.1 Le protocole RPL 20

2.4.1.1 Procédure de construction du DODAG 20

2.4.1.2 Les différentes métriques du protocole RPL 22

2.4.1.3 Les modes de fonctionnement du protocole RPL 23

2.4.1.4 Les messages de contrôle du protocole RPL 24

2.4.1.5 Mécanisme de réparation du DODAG 25

2.4.2 Le fonctionnement de l’algorithme Trickle 25

3 Optimisation de la consommation énergétique 28 3.1 Introduction 28

3.2 État de l’art 28

3.2.1 Mécanisme du Duty-Cycle pour les capteurs 28

3.2.1.1 Réduction du pourcentage du Duty-Cycle pour économiser l’énergie 29

3.2.2 Économie d’énergie par l’optimisation du trafic de contrôle 31

3.3 Modélisation de la consommation énergétique des capteurs 33

3.3.1 Réduction de la probabilité P h T I(i)i d’émission des messages de contrôle 36

3.3.1.1 Utilisation d’un modèle analytique 36

3.3.2 Détermination de la valeur de D qui optimise la consommation énergétique 37 4 Simulations et Résultats 39 4.1 L’environnement de simulation 39

4.2 Le système d’exploitation ContikiOS et le simulateur Cooja 39

4.2.1 Optimisation du trafic de contrôle par simulation 40

4.2.2 Vérification de la rélation entre k et NDeg sur un scénario de trois nœuds 42 4.2.3 Les valeurs de D et la consommation énergétique du réseau 44

4.2.3.1 Consommation énergétique pour un scénario de 5 nœuds en ligne 44 4.2.3.2 Comparaison de la consommation du CPU et de la Radio sur 24heures de réseau 46

4.2.3.3 Evolution de la consommation en fonction des intervalles de Trickle 47 4.2.4 Temps de convergence du réseau 48

5 Plate-forme expérimentale 50 5.1 La plate-forme des capteurs Z1 50

5.2 La plate-forme des passerelles, Sheevaplug 50

5.3 Vue globale du réseau 51

5.4 Scénario expérimenté 52

6 Conclusion et perspectives 54 6.1 Conclusion 54

6.1.1 Bref résumé : 54

6.1.2 Bilan : 55

6.2 Perspectives 55

6.3 Détailles des différents messages du protocole RPL 58

6.3.1 Les différentes options possible dans un message DIO sont : 61

6.3.2 Les différentes options des messages DAO 65

6.3.3 Les trois options possible dans les messages DIS sont présenterés en détaille ci-dessous 67

6.4 Configuration du Serveur 68

6.5 Configuration de la passerelle 1 (GW1) 68

6.6 Configuration des passerelles 2, 3 et 4 69

6.6.1 Manipulations à faire sur les capteurs avant de flasher le code 69

6.6.2 Téléchargement du code sur le capteur 70

Table des figures

2.1 Architecture d’un nœud capteur [21] 14

2.2 Exemple de réseau de capteurs 15

2.3 Table des fréquences et de bande passante de IEEE 802.15.4 17

2.4 Compression HC1 d’en-tête IPv6 avec 6LoWPAN [7] 19

2.5 Compression IPHC d’en-tête IPv6 avec 6LoWPAN [7] 19

2.6 Réseau physique utilisé pour construire le DODAG[8] 21

2.7 Diffusion des DIO par le LBR [8] 21

2.8 Choix du LBR comme noeud parent [8] 21

2.9 Poursuite de la construction du DODAG [8] 22

2.10 DODDAG final construit par RPL [8] 22

2.11 Fonctionnement en ”Non-Storing mode ”du protocole RPL 23

2.12 Fonctionnement en “Storing mode” du protocole RPL 24

2.13 Algorithme de Trickle 26

2.14 Fonctionnement de Trickle sans inconsistance 27

3.1 Evolution de la consommation énergétique en fonction du Duty-Cycle [2] 30

3.2 Consommation énergétique en fonction du Duty-Cycle et du nombre de nœuds [2] 30 3.3 Énergie consommée en fonction de la méthode d’assignation du Duty-Cycle[3] 31

3.4 Influence des messages de contrôle sur le Duty-cycle dans RPL[10] 32

3.5 Pourcentage des messages DIO en fonction de la contance k de l’algorithme Triclke[5] 32 3.6 Émission des messages de contrôle dans un scénario à trois nœuds 34

3.7 Fonctionnement du module radio sur un intervalle I 34

3.8 Emission des messages DIO sur une ériode de D + 2CCA ms 38

4.1 Fenêtre de simulation et choix du firmware sur Cooja 40

4.2 Compilation et lancement de la simulations sur Cooja 40

4.3 Evolution de P h TI(i)isans trafic de donnée 41

4.4 Tableau comparatif de la probabilité d’émission des messages DIO 42

4.5 Scénario de simulation à 3 noeuds 43

4.6 Temps cumulé en ticks et energie consommée pour la transmission des messages de contrôle 43

4.7 Scénario de simulation à 5 noeuds 45

4.8 Consommation énergétique sur 10h30 et19h30 de réseau 45

4.9 Évaluation de l’énergie consommée par le CPU et la Radio 46

4.10 Consommation pour chaque phase de l’algorithme Trickle 47

5.1 Les capteurs Zolertia Z1 50

5.2 Passerelles Sheevaplug 51

5.3 Scénario d’interconnexion 6LoWPAN-IPv4 52

5.4 Scénario de l’expérimentation 52

6.1 Format du message DODAG Information Object [6] 58

6.2 Format du message DAO [6] 59

6.3 Format du message DAO-ACK [6] 60

6.4 Format du message DIS [6] 60

6.5 Format de l’option Pad1[6] 61

6.6 Format de l’option PadN[6] 61

6.7 Format de l’option “DAG Metric Container”[6] 61

6.8 Format de l’option “Routing Information”[6] 62

6.9 Format de l’option “DODAG Configuration”[6] 62

6.10 Format de l’option “Prefix Information”[6] 63

6.11 Format de l’option “RPL Target”[6] 65

6.12 Format de l’option “Transit Information“[6] 66

6.13 Format de l’option “RPL Target Descriptor”[6] 66

6.14 Format de l’option Pad1[6] 67

6.15 Format de l’option PadN[6] 67

6.16 Format de l’option “Solicited Information”[6] 67

6.17 Capture d’écran des messages affichés 72

Liste des tableaux

3.1 Résultats statistiques de la méthode analytique 37

4.1 Evolution de P h

T I(i)ien fonction du degré y et de k selon le modèle analytique 41 4.2 Evolution de P h

TI(i)iavec trafic de données 41

4.3 Temps de convergence du réseau en fonction de la valeur de D 48

mo-Avec la miniaturisation croissante des équipements électroniques et les progrès réalisés dansles technologies de communication sans fil, on note une émergence des capteurs sans fil (Micaz,TelosB, Zolertia Z1) à faible cỏt avec une consommation énergétique raisonnable.

L’objectif de ce stage est d’étudier un cas particulier d’interconnexion de terminaux fixes, dumobilier urbain intelligent à des points d’accès du réseau Internet en utilisant un réseau de capteursmaillé Le mobilier urbain intelligent est composé de panneaux d’affichage électronique qui diffusentdes informations à l’attention des usages urbains Par exemple, sur la météo, l’état du trafic oudes événements culturels Un serveur dans le réseau Internet envoie ce flux de trafic sporadiqueaux terminaux fixes du mobilier urbain intelligent qui l’affichent En retour, ceux-ci renvoient auserveur 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 capteursautonomes en énergie pour acheminer les données entre les terminaux fixes du mobilier urbainintelligent et les points d’accès du réseau Internet L’utilisation de noeuds de relais tels que ceuxdisponibles dans les capteurs sans fil est une alternative au déploiement de routeurs mesh cỏ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

1.2 Problématique

Lorsque qu’on veut contrôler le fonctionnement des terminaux du mobilier urbain intelligentpar 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èsradio De cette contrainte est né l’idée d’utiliser un réseau maillé multi sauts de capteurs sans filspour 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 fondamentalessuivantes :

– Les capteurs du réseau maillé fonctionnent sur des batteries, quel doit être le mode defonctionnement (Duty-Cycle, fréquence d’envoi des messages de contrôle et des données) descapteurs 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éseauInternet au réseau maillé de capteurs et d’autre part le réseau maillé au mobilier urbainintelligent ?

– Quelle peut être la nature du trafic supporté et les garanties de qualité de service que peutfournir le réseau constitué ?

Les réponses à cette problématique seront données dans la suite du présent rapport

– Le but de ce travail est de construire un réseau maillé à base de capteurs qui assure connexion des équipements du mobilier urbain intelligent avec des points d’accès du réseauxinternet Les capteurs du réseau maillé étant alimentés par des batteries avec une capac-ité énergétique limitée, nous devons trouver les bons paramètres de fonctionnement pour ceréseau maillé afin de prolonger la durée de vie de l’ensemble du réseau construit

l’inter-– Le présent rapport vise à présenter les différentes méthodes analytiques, de vérification et devalidation notamment les simulations et expérimentations réalisées pour vérifier et valider lasolution proposée puis tester les performances de la solution apportée au problème soulevépar le sujet

Mon choix pour ce sujet découle d’une part, de l’intérêt et l’importance que j’accorde auxréseaux de capteurs Pendant mes cours de Master 2, j’ai beaucoup aimé le module sur les réseauxspontanés avancés et en particulier les réseaux de capteurs à cause de son vaste domaine d’applica-tion notamment, applications militaire, médicale et systèmes de surveillance d’habitation D’autrespart, ce sujet comporte une importante partie pratique, toute chose qui va me permettre de faire

des manipulations directes sur les capteurs et les autres équipements connexes du réseau à mettre

en place

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) del’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 etresponsable de l’équipe Urbanet, qui est localisée au Laboratoire CITI à l’INSA Lyon, et parM.Khaled Boussetta, Maître de conférences à l’université Paris 13 et en délégation INRIA au sein

de l’équipe Urbanet

Le rapport est repartis sur six (06) chapitres

Le premier chapitre un (01) introduit le sujet et son contexte Nous présentons ensuite lecontexte technologique (généralités sur les réseaux de capteurs et les couches protocolaires) dusujet dans le chapitre 2 L’état de l’art sur les techniques d’optimisation de la consommation én-ergétique dans les réseaux limités en ressources est présenté en début du chapitre 3 Puis, nousprésentons un modèle de consommation énergétique et discutons du choix des paramètres de fonc-tionnement du réseau afin de réduire la consommation de l’énergie des capteurs Le chapitre 4présente le simulateur utilisé ainsi que tous les résultats pertinents obtenus Nous présentons lesplate-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

Chapitre 2

Contexte technologique

Les avancées récentes dans la micro-électronique et la communication sans fil ont permis ledéveloppement des nœuds capteurs (Zolertia z1, TelosB, Micaz) de petite taille, à faible cỏ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 ó ils sont déployés, éventuellement, de les traiterlocalement 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 ronnement ó il est déployé en une grandeur numérique

l’envi-– D’un micro-processeur avec une faible puissance de calcul et un faible espace de stockage parrapport aux ordinateurs ou aux Smartphones

– D’un module de transmission sans fil avec une puissance radio limitée ne dépassant pas unecentaine 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]

Un schéma générale d’un réseau de capteur peut être présenté comme l’indique la figure dessous :

ci-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 imiser la durée de vie du réseau

max-– Besoin d’algorithmes distribués, localisés et collaboratifs pouvant être exécutés avec desmicro-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 (encas 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 fonctionsd’interconnexion du réseau

Dans les sections suivantes, nous allons présenter en détaille d’une part, le protocole IEEE802.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

Un réseau 6LoWPAN est un réseau de communication sans fil constitué d’un ensemble d’équipementsayant 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 auprotocole IEEE 802.15.4 de transporter des paquets IPv6, des techniques d’encapsulation, de com-pression des entêtes des paquets IPv6 puis des mécanismes de fragmentation et de ré-assemblage

des paquets ont été proposés Les différentes modifications sont effectuées dans une couche, appeléecouche d’adaptation 6LoWPAN située entre la couche liaison de données et la couche réseau dumodè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’autrepart la couche d’adaptation 6LoWPAN permettant la transmission de paquets IPv6 à travers leprotocole 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 garantirune facilité d’installation, un maximum de fiabilité de transfert de données, une opérabilité à courtterme, un faible cỏ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écessitantdes 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éfiniespar la norme Ils communiquent entre eux et avec les RFD alors que les derniers ne communiquentqu’avec des FFD Un RFD est désigné pour les applications simples comme les interrupteurs d’élec-tricité ou les senseurs infrarouges et n’ont généralement pas besoin de transmettre beaucoup dedonnées En conséquence, les RFD sont implantés avec le minimum de ressources possibles UnFFD 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 coordinateurprincipal 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écepteurradio, de détection d’énergie, de détection de la qualité du lien, de sélection de canaux, de test

de disponibilité du canal (CCA, Clear Channel Assessment), de transmission et de réception dedonné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 Ilsdoivent 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 besoinsdes 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 queles 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 nateur du PAN :

coordi-– Le mode sans BEACON, dans lequel l’accès est commandé par le protocole CSMA/CA nonslotté (version classique de CSMA/CA)

– Le mode avec BEACON, dans lequel des BEACONs sont régulièrement émis par le dinateur du PAN (ainsi que d’autres coordinateurs) pour synchroniser les nœuds associés

coor-et pour identifier le PAN Dans ce cas une structure de super-trame est définie entre deuxtransmissions successives de BEACONs L’accès dans ce mode est commandé essentiellementpar le protocole CSMA/CA slotté mais il implante également un mécanisme d’allocation detranches 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 technologieappelé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

le protocole IPv6 Dans la section suivante, nous présentons le mécanisme de fonctionnement de

la technologie 6LoWPAN

La technologie 6LoWPAN fournie des mécanismes d’encapsulation et de compression têtes permettant aux paquets IPv6 d’être envoyés ou reçus via le protocole de communicationIEEE 802.15.4 L’ensemble des modifications sur les paquets IPv6 sont effectuées dans une couchespéciale, appelée couche d’adaptation 6LoWPAN que nous présentons ci-dessus

d’en-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 tion 6LoWPAN assure la compression des entêtes des paquets, la fragmentation et le ré-assemblagedes paquets IPv6 puis le routage des fragments de ces paquets IPv6

d’adapta-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 cestechniques, 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 carils sont considérés comme implicites (par exemple le champ version a toujours pour valeur 6) Enrompant la règle principale du modèle OSI, qui implique que chaque couche doit être indépendantedes 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 contenusuivant, le champ dispatch, (en-tête IPv6, en-tête de fragmentation, etc.) et un second octet pourdé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 Lafigure ci-dessous compare une trame compressée à l’aide de ce mécanisme avec une trame IPv6sans compression d’en-tête

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 nications globales incluront systématiquement le préfixe IPv6 global sur 64 bits pour les champssource et destination de l’en-tête IPv6 Cette contrainte limite sérieusement l’utilité de l’encodageHC1, car l’intérêt d’intégrer IPv6 dans les réseaux de capteurs sans fil est de permettre des com-munications globales à l’échelle d’Internet En conséquence, l’IETF a défini un nouveau mécanisme

commu-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 octetsest effectuée pendant que sept octets sont utilisés pour la communication sur plusieurs sauts Ilest é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éesest 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 leprotocole IPv6 Au dessus de la couche d’adaptation 6LoWPAN déjà présenté se situe la coucheré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 sectionsuivante présenter les protocoles de routage les mieux adaptés pour les réseaux de capteurs

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’unprotocole 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 cefait 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étiquedes nœuds Principalement, les protocoles de routages dans les réseaux limités en ressources doiventfonctionner 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 Protocolfor Low power and Lossy Networks) beaucoup plus optimisé en terme de cỏt énergétique a étémis au point par le groupe de travail ROLL[25] (Routing Over Low power and Lossy Networks) del’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ésentonsdans 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 nation Oriented Directed Acyclic Graph ) à l’aide d’une fonction objectif constituée de métriqueset/ou de contraintes La fonction objectif du routage n’impose pas un ensemble de métriques ou

(Desti-de contraintes à utiliser mais dicte (Desti-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’ilsassument

– Le root, encore appelé LBR (Low Power and Lossy Network Border Router), il joue un rơletrès important dans le réseau Le root est à l’origine de l’envoi des messages DIO servant à laconstruction du DODAG Il maintient les tables de routage permettant d’atteindre chaquenoeud au sein DODAG

– Les nœuds parents ou routeurs, un nœud parent possède au moins un fils (un nœud de ranginfé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

du système.

Ci-dessous, nous présentons les principales étapes de construction d’un DODAG, à partir d’unréseau physique donné

Figure 2.6 – Réseau physique utilisé pour construire le DODAG[8]

– 1ère étape : Le root ou LBR diffuse les messages DIO dans son voisinage à un saut :

Figure 2.7 – Diffusion des DIO par le LBR [8]

– Deuxième étape : chacun des nœuds ayant reçu le DIO envoyé par le LBR, va utiliser la fonction objectif contenu dans le message DIO et l’algorithme de choix du parent préféré

pour choisir son parent préféré Une fois le parent préféré choisi, le nœud envoi à ce parent

un message DAO pour signaler son choix Ces messages DAO contiennent des informationspermettant au root de construire des chemins vers les nœuds feuilles du DODAG

Figure 2.8 – Choix du LBR comme noeud parent [8]

– Troisième étape : Les nœuds ayant choisi le LBR comme parent vont à leur tour diffuser des messages DIO en multicast dans leur voisinage Les nœuds ne faisant pas encore parti du

DODAG qui vont recevoir ces messages DIO, vont donc faire un choix de nœud parent puisrépondre par des messages DAO indiquant leur attachement au DODAG

Figure 2.9 – Poursuite de la construction du DODAG [8]

– Quatrième étape : le processus de l’étape 3 se poursuive jusqu’à ce que tous les nœuds du

réseau se connectent au DODAG

La figure ci-dessous montre le DODAG final construit sur le réseau physique de départ par leprotocole RPL

Figure 2.10 – DODDAG final construit par RPL [8]

Dans la construction du DODAG présentée ci-dessus, la fonction objectif utilisée est la qualité

du lien (LQ) A la réception du premier message DIO, chaque noeud va prendre sa décision de sejoindre ou de ne pas se joindre au DODAG en construction Cette décision s’effectue en se basantsur la fonction objectif diffusée dans le DODAG mais aussi :

– Des caracteristiques du DODAG indiquées par le root dans les champs du message DIO– De la valeur de la métrique évaluée entre le root et le noeud

La construction du DODAG s’effectue par des messages de contrôle transportées dans des paquetsICMPv6

2.4.1.2 Les différentes métriques du protocole RPL

Les métriques de routage du protocole RPL peuvent être regroupées en deux classes :

– les métriques basées sur les nœuds, il s’agit de la métrique sur le nombre de saut (Hop count)

et la métrique sur l’énergie résiduelle des nœuds (Node Energy)

– les métriques basées sur les liens, cette classe regroupe la qualité du lien (LQ), la latence dulien (Latency), le débit supporté par le lien (Throughput) et le nombre de retransmissionattendu (ETX)

Le choix de la métrique à utiliser pour la construction du DODAG se configure au niveau du nœud

root Le root va diffuser la fonction objectif contenant la métrique dans les messages DIO à travers

un champ réservé à cet effet appelé “OCP” (Objective Code Point)[6]

2.4.1.3 Les modes de fonctionnement du protocole RPL

En fonction de la capacité des nœuds en terme de mémoire et de la taille éventuelle du réseau,

le protocole RPL offre deux modes de fonctionnement, le fonctionnement en “storing mode” et celui en ”Non-Storing mode”.

– Le fonctionnement en “Non-Storing mode”

Dans le fonctionnement en “Non-Storing mode”, seul le root est en mesure de stocker des

informa-tions de routage Les autres nœuds du réseau conservent uniquement les adresses de leur parentdirect Toutes les informations sur la structuration du DODAG sont transmises au root dans lesmessages DAO En cas de besoin de router des données vers une destination quelconque, les nœudstransmettent ces données au root en passant par leur parent Le root effectuera un routage à lasource vers la bonne destination

Dans ce mode de fonctionnement, chaque nœud génère son message DAO puis l’envoie au root

du DODAG à travers des communications multi-sauts Le message DAO envoyé est une réaction

à un message DIO reçu Le temps entre la réception du message DIO et l’envoie du DAO dépenddes paramètre de l’implémentation Cependant, les spécifications du protocole RPL exigent que

le délais entre l’émission de deux messages DAO successifs doit être inversement proportionnel

au rang du nœud dans le DODAG (le rang d’un nœud est sa position part rapport au root enconsidérant la métrique de routage) Selon cette exigence, les nœuds les plus proches du root vontgénéré moins de message DAO comparativement aux nœuds les plus éloignés

La figure ci-dessous présente un fonctionnement en non storing mode :

Figure 2.11 – Fonctionnement en ”Non-Storing mode ”du protocole RPL

A la réception d’un message DAO emis par un de ses fils, les nœuds intermédiaires vont specter le message pour s’assurer qu’il indique un chemin correct en direction du fils lui ayanttransmis le message avant de le faire suivre vers le root Le root va collecter toutes les informationsnécessaire pour la construction des tables de routage en direction des feuilles du DODAG Après

in-la construction de in-la table de routege par le root, tous les nœuds seront accessible grâce à un

mécanisme de routage à la source.

Le routage à la source consiste à insérer les adresses des nœuds par les quels transitera le paquetdans l’entête

– Le fonctionnement en “Storing mode”

Dans ce mode de fonctionnement, les nœuds intermédiaires sont en mesure de garder en mémoiredes informations de routage puis de rediriger les données reçues vers la bonne destination enconsultant les informations du routage

Contrairement au ”Non-Storing mode”, dans le fonctionnement en ”Storing mode”, les messages

DOA ne sont pas tous transmis au root Chaque nœud transmet son message à son parent direct(parent à un saut) qui maintient une table de routage à son niveau

Le schéma ci-dessous présente le fonctionnement en “Storing mode” :

Figure 2.12 – Fonctionnement en “Storing mode” du protocole RPL

Dans ce mode de fonctionnement, lorsque le root veut envoyer des données à un nœuds de ranginférieur, il n’effectue pas de routage à la source mais il envoie les données à ses fils situés à unsaut qui se charge d’effectuer le routage jusqu’à la bonne destination Pour envoyer des données

au root, les nœuds feuilles envoient les données à leur parent directe qui effectuera un routage en

se servant de la table de routage construite à l’aide des messages DAO

Il est également possible de faire une combinaison de ces deux modes de fonctionnement Dans

un tel scénario, les nœuds avec une faible capacité mémoire seront regroupé pour fonctionner en

“Non-Storing mode”.

2.4.1.4 Les messages de contrôle du protocole RPL

Les messages impliqués dans la construction et le maintient du DODAG sont :

– DODAG Information Object (DIO), initié par le LBR et retransmis en multicast par sesvoisins

– DODAG Destination Advertisement Object (DAO), envoyer par les neuds fils vers leur parent– DODAG Information Sollicitation (DIS), peut être envoyer par tous les noeuds sauf le LBR– Destination Advertisement Object Acknowledgement (DAO_ACK), envoyer par un noeudparent vers son fils

A l’exception des messages DAO et DAO_ACK, les deux autres messages ont un objectif local etsont envoyés en multicast vers les voisins en utilisant des adresses IPv6 de lien local Les messagesDAO et DAO_ACK sont eux envoyés en unicast à l’aide d’adresse globale ou d’une adresse localeunique.

Les principaux messages transportés par les paquets ICMPv6 permettant la construction et lemaintient du graphe logique DODAG sont présentés en détaille dans l’annexe 1

2.4.1.5 Mécanisme de réparation du DODAG

La réparation du DODAG est initiée par le LBR Chaque DODAG initié par le root est dotéd’un numéro de version L’opération de réparation consiste à incrémenter le numéro de la version

du DODAG en cours en vue de créer une nouvelle version Les nœuds dans la nouvelle version duDODAG peuvent choisir une nouvelle position dont le rang est plus petit par rapport au rang del’ancienne version Le root possède toujours le rang 0

L’émission des messages de contrôle (les messages DIO en particulier) par le protocole RPL

(présenté dans la sous-section 2.4.1.4 ) est contrôlé par un ”timer ” particulier appelé ”Trickle timer” L’algorithme du ”timer” Trickle permet de réduire l’émission des messages DIO lorsque le

réseau est stable Nous présentons en détail dans la section suivant le fonctionnement de rithme Trickle

l’algo-2.4.2 Le fonctionnement de l’algorithme Trickle

L’algorithme Trickle est utilisé pour contrôler l’emission des messages DIO par chaque nœuddans le réseau

Pour son fonctionnement, Trickle possède trois paramètres :

– la valeur de l’intervalle de départ appelé Imin L’algorithme Trickle commence son nement avec une taille d’intervalle qui est égale à Imin.

fonction-– la valeur de l’intervalle maximale de fonctionnement appelé Imax Lorque l’intervalle de fonctionnement atteint la valeur de Imax, alors elle se stabilise et n’augmente plus.

– et la constante de redondance k La constante k fixe le nombre de messages appelés ”message consistant” reçus par un noeud pendant un intervalle I et au delà du quel ce noeud peut

considérer que le réseau est stable et qu’il est donc inutile de générer un message DIO

Trickle initialise l’intervalle I qui sépare l’envoie de deux DIO à Imin Si aucune inconsistance n’a été détecté pendant cet intervalle, I est augmenté de façon exponentielle (doublé) jusqu’à Imax

et se stabilisera alors à cette valeur de Imax Au début d’un intervalle I, chaque noeud choisi

aléatoirement l’instant d’attente avant l’envoi possible d’un message DIO Cet temps d’attente est

choisi aléatoirement en suivant une distribution uniforme dans l’intervalle [I/2, I] A l’échéance de

ce délais, si le nombre de messages consistants reçu depuis le début de l’intervalle I est inférieur

à la constante de redondance k alors le noeud envoie un message DIO Autrement l’envoie du

message DIO est annulé

Dans le protocole RPL, un nœud du réseau détecte une inconsistance s’il reçoit un messageDIO d’un de ses voisins qui possède des informations non cohérentes avec celles qu’il dispose Parexemple si le message DIO reçu comporte un identifiant du DODAG qui est différent de celui dont

le nœud disposait

En cas d’inconsistance, quelque soit la taille actuelle de l’intervalle de fonctionnement,

l’algo-rithme Trickle revient à l’intervalle Imin afin d’envoyer rapidement des messages DIO.

Le schéma ci-dessous présente le fonctionnement de l’algorithme de Trickle

Figure 2.13 – Algorithme de Trickle

Dans un fonctionnement sans inconsistance de Trickle avec Imin = 4, 096 secondes et Imax =

8388, 608 secondes, nous avons représenté sur la figure (figure 2.14) suivante l’évolution des

inter-valles de fonctionnement de l’algorithme Trickle

– (1) représente la phase de croissance

– (2) la phase constante

Figure 2.14 – Fonctionnement de Trickle sans inconsistance

De façon générale, Trickle permet au protocole RPL de réduire le trafic de contrơle lorsque leréseau est consistant et stable puis d’envoyer plus de messages en cas d’inconsistance

Nous allons focaliser une partie de notre étude sur une configuration optimale de cet rithme de Trickle pour réduire le cỏt énergétique du trafic de contrơle du protocole RPL Notrecontribution est détaillée dans les chapitres 4 et 5

algo-Conclusion sur le contexte technologique

Dans ce chapitre dédié au contexte technologique, nous avons dans un premier temps présentéles réseaux de capteurs en générale et de façon détaillé les couches basses d’un capteur Nous avonsexpliqué le principe de la couche d’adaptation 6LoWPAN qui permet au paquets IPv6 d’êtreenvoyés et reçus via le protocole IEEE 802.15.4 Nous avons ensuite présenté le routage dans lesréseaux de capteurs et en particulier le protocole RPL qui est un protocole adapté pour les réseauxlimités en ressources comme celui des capteurs Enfin, nous avons présenté l’algorithme Trickle,qui est un algorithme optimisé pour l’émission des messages de contrơle (messages DIO) dans lefonctionnement du protocole RPL

A partir de ce chapitre, le contexte technologique de notre travail étant bien connu, nous allonsnous focaliser dans le chapitre suivant sur la modélisation et l’optimisation de la consommationénergétique d’un réseau de capteurs

Chapitre 3

Optimisation de la consommation

énergétique

Dans un réseau ó les nœuds sont alimentés par des batteries, la consommation énergétique est

un aspect important, car la durée de vie du réseau en dépend Dès lors que la batterie d’un nœud

se décharge, ce nœud sera hors service Lorsqu’un ou plusieurs capteurs se retrouvent sans batterie,cela peut provoquer une partition du réseau voir un dysfonctionnement global La consommationénergétique des nœuds doit donc être optimisée pour allonger la durée de vie du réseau

Plusieurs mécanismes ont été proposé pour réduire la dissipation énergétique dans un réseau decapteurs Dans la section suivante, nous présentons les principales idées proposées par les cherheurspour optimiser la consommation énergétique dans les réseaux limités en ressources comme lesréseaux de capteurs

Dans cette section nous faisons un état de l’art sur les mécanismes utilisés pour réduire laconsommation énergétique dans les réseaux limités en ressources appelés LLNs (Low power andLossy Networks)

3.2.1 Mécanisme du Duty-Cycle pour les capteurs

L’idée du Duty-Cycle est d’imposer aux capteurs, un cycle de fonctionnement qui consiste àéteindre périodiquement leur composante radio et de la rallumer à des instants précis pour écouter

le canal radio, envoyer ou recevoir des messages

Le Duty-Cycle est ainsi perçu comme étant le pourcentage de temps pendant le quel la posante radio du capteurs est en activité

com-La valeur du Duty-Cycle peut être statique et commune à tous les nœuds du réseau [2], celavise à faciliter la synchronisation entre ces différents nœuds On peut également avoir un Duty-Cycle adaptatif en fonction du trafic observé par chaque nœud du réseau [3] Dans tout les cas,l’objectif visé est d’avoir à chaque instant une valeur du Duty-Cycle qui optimise la consommationénergétique des nœuds et qui augmente les performances du réseau.

Dans un capteur, la composante radio est une entitée qui consomme beaucoup d’énergie [4],lorsque cette composante radio est éteinte le capteur peut reduire sa consommation

3.2.1.1 Réduction du pourcentage du Duty-Cycle pour économiser l’énergie

Pour les auteurs de [2], dans un réseau de capteurs, la consommation énergétique dependprincipalement du pourcentage du Duty-Cycle La durée de vie de chaque nœud est une fonction

mathématique qui prend en compte la capacité de la batterie (C batt), l’énergie dépensée pour la

transmission des données (E tex ) et surtout du pourcentage du Duty-Cycle (d).

L= (C batt∗3600)

(E tex ∗d)

L= durée de vie du capteur en secondes

C batt =capacité de la batterie du capteur en mAh

d=Duty-Cylce en pourcentage (%) de temps

E tex =énergie consommée pour la transmission en uJ

Dans cette même référence [2], les auteurs estiment que la durée de vie de chaque capteur estinversement proportionnelle à la valeur du Duty-Cycle Plus le pourcentage du Duty-Cycle estgrand, moins la batterie du nœud résistera longtemps

A travers des simulations sur un scénario composé de 100 capteurs, ils montrent que la

consom-mation énergétique des nœuds est très faibles Elle est strictement inférieur à 0.95 Joules, lorsque

la valeur du Duty-Cycle est inférieure à 0.01% de la durée d’un cycle Par contre, pour des valeurs

du Duty-Cycle strictement supérieur à 0.01%, la consommation énergétique de chaque capteurdevient très importante et augment de façon linéaire avec la valeur du Duty-Cycle Le schémaci-dessous présente les résultats statistiques :

Figure 3.1 – Evolution de la consommation énergétique en fonction du Duty-Cycle [2]

Lorsque le Duty-Cycle est de 0.1%, on observe une consommation énergétique d’environ 1.275Joules,

ce qui est largement supérieure à 0.95Joules, la consommation énergétique observée pour un Cycle de 0.01% A partir de ces résultats, on peut dire que dans un même scénario de réseau de

Duty-capteur, la consommation énergétique augmente avec le pourcentage du Duty-Cycle On pourraainsi économiser de l’énergie en réduisant au minimum possible la valeur du Duty-Cycle des nœuds

Figure 3.2 – Consommation énergétique en fonction du Duty-Cycle et du nombre de nœuds [2]

A travers le graphique ci-dessus, on constate que pour une taille du réseau comprise entre 25

et 150 capteurs, la consommation énergétique augmente avec le Duty-Cycle mais, pour chaquescénario, il y a une valeur du Duty-Cycle qui optimise cette consommation énergétique La valeuroptimale du Duty-Cycle est de 0.01 % pour les réseaux d’une taille de 75, 100, 125 et 150 capteurspuis de 0.02 % pour ceux de 25 et 50 capteurs

L’idée de la réduction du Duty-Cycle pour optimiser la consommation énergétique est égalementpartagé par Y Zhang et al dans [3] Ils ont proposé l’usage d’un Duty-Cycle adaptatif en fonction

de la distance de chaque capteur par rapport au noeud sink et de l’importance du trafic observé

par celui-ci Ainsi, dans un réseau de communication « convergecast » ó le trafic de données

observé au tour du nœud sink est plus important par rapport aux autres parties du réseau, et

un protocole de communication orienté réception qui permet aux nœuds de communiquer sansavoir besoin d’une synchronisation, les auteurs de [3] ont proposé deux méthodes d’assignationdynamique du Duty-Cycle

La première méthode proposée est appelé « Distance-based Duty Cycle Assignment (DDCA)

» Avec cette méthode d’assignation, le Duty-Cycle de chaque noeud est choisi en fonction de ladistance qui le sépare du nœud sink Avec la méthode DDCA, les nœuds situés à des distancesdifférentes du nœuds sink auront différentes valeurs du Duty-Cycle

La seconde méthode d’assignation du Duty-Cycle proposée, s’appelle « Traffic-Adaptive

Distance-based Duty Cycle Assignment (TDDCA) » Dans la méthode TDDCA, le Duty-Cycle est initialisé

à une valeur fournie par la méthode DDCA puis adapté par la suite en fonction du trafic desmessages RTS (Request to Send) observé par le nœud Les résultats des simulations effectuées parles auteurs montrent que ces deux méthodes d’assignation dynamique du Duty-Cycle permettentd’économiser plus d’énergie comparativement à un Duty-Cylce statique et commun à l’ensembledes nœuds du réseau

Figure 3.3 – Énergie consommée en fonction de la méthode d’assignation du Duty-Cycle[3]

Les résultats graphique montrent qu’un Duty-Cycle constant et identique pour tous les nœuds

du réseau entraỵne une consommation énergétique plus importante en comparaison avec un Cycle adaptatif représenté ici par les méthodes TDDCA et DDCA

Duty-3.2.2 Économie d’énergie par l’optimisation du trafic de contrơle

Le trafic de contrơle est l’ensemble des messages échangés par les nœuds pour la construction et

le maintient de la topologie du réseau En fonction de leur taille et de leur fréquence d’émission, cesmessages de contrơle peuvent sérieusement influencer le Duty-Cycle et la consommation énergétiquedes nœuds du réseau Dans un réseau de capteurs utilisant le protocole RPL pour le routage, les

auteurs de [1] et de [5] estiment qu’une optimisation des message de contrôle est nécessaire car,

le trafic de contrôle augmente considérablement le pourcentage du Duty-Cyle et la consommationénergétique La figure ci-dessous montre l’influence des messages de contrôle sur le Duty-Cycle

Figure 3.4 – Influence des messages de contrôle sur le Duty-cycle dans RPL[10]

Le graphique ci-dessus montre qu’avec le protocole RPL, le trafic de contrôle occupe près de

la moitié du Duty-Cycle Une optimisation de l’envoie de ces messages de contrôle permettra deréduire le Duty-Cycle dans un réseau de capteur qui utilise le protocole RPL pour le routage.Dans le protocole RPL, le trafic de contrôles est dominé par les messages DIO, une optimisation

de ces messages DIO va également diminuer les autres types de messages, notamment les messagesDAO et DAO_ACK car ces deux types de messages sont émis après l’émission d’un message DIO.Dans la référence [5], à travers une formule analytique et des simulations, les auteurs présen-tent la relation entre les différents paramètres de fonctionnement du protocole RPL permettantd’optimiser l’envoi des messages de contrôle (DIO) Le schéma ci-dessous présente l’évolution de laprobabilité de transmission des messages de contrôle du protocole RPL en fonction de la constante

de redondance k de l’algorithme Trickle.

Figure 3.5 – Pourcentage des messages DIO en fonction de la contance k de l’algorithme Triclke[5]

De ces résultats graphique, on constate qu’il y a une réduction du trafic de contrôle dans

le protocole RPL lorsque la constance de redondance K de l’algorithme Trickle est strictement

inférieur au degré du nœud Lorsque la constance de redondance K est supérieur au degré des

nœuds, le trafic de contrôle devient plus important

Conclusion sur l’optimisation de la consommation tique

énergé-– Bilan de l’état de l’art : une synthèse des articles lus sur la consommation énergétique

montre qu’on peut optimiser l’énergie consommée par les noeuds en proposant d’une part,

un faible Duty-Cycle pour le fonctionnement des capteurs Ce Duty-Cycle peut être statique

et communs à l’ensemble des nœud comme il peut être dynamique en fonction de la vision duréseau par chaque nœud D’autre part, on peut économiser l’énergie des noeuds en optimisant

le trafic de contrôle du protocole de routage

– Discussion : l’optimisation de la consommation énergétique est très importante dans les

réseaux limités en ressources Cette optimisation permet d’éviter la décharge instantanée desnœuds et d’allonger la durée de vie du réseau Dans le contexte de notre travail, le protocole

de routage que nous utilisons est le protocole RPL, ce protocole génère un trafic de contrôletrès important car c’est un protocole pro-actif (les routes son conservées même sans leurutilisation) Nous allons d’une part étudier le mécanisme du Duty-Cyle du réseau 6LoWPANdes capteurs pour trouver un meilleur Duty-Cycle qui permet d’économiser l’énergie desnœuds D’autres part, nous allons modéliser un scénario simple du trafic de contrôle duprotocole RPL pour quantifier la consommation énergétique et procéder à une optimisation.Dans la sous-section suivante, nous allons présenter le modèle de consommation énergétique et lesoptimisations effectuées

cap-teurs

L’objectif de cette partie est de formuler un modèle analytique de la consommation tique des capteurs pendant la phase stable du réseau et procéder à une optimisation de cetteconsommation

énergé-Après une étude du fonctionnement des capteurs Z1 dans un réseaux 6LoWPAN, nous avons

établie une formule de consommation énergétique par capteur et par intervalle de temps I = Imax

de l’algorithme Trickle

Considérons le scénario suivant d’un réseau de capteur avec RPL comme protocole de routage

Figure 3.6 – Émission des messages de contrôle dans un scénario à trois nœuds

Le nœud sink est connecté à une source d’alimentation électrique, donc on focalise notre tention sur la consommation électrique des autres nœuds du réseau

at-En plus des messages de contrôle (DIO, DAO et DAO_ACK) échangés, les nœuds 2 et 3etteignent régulièrement leur radio puis la rallume quelques instants plu-tard pour vérifier l’état

du canal à l’aide mécanismes CCA (Clear Channel Assessment) Dans les détails, le fonctionnementpeut être détaillé comme l’indique la figure ci-dessous

Figure 3.7 – Fonctionnement du module radio sur un intervalle INous quantifions la consommation énergétique liée à ce fonctionnement à travers les équationssuivantes :

– Définition des variables de la formule analytique de consommation

Soit :

DIO R= l’energie consommée pour la réception d’un message DIO

DIO E= l’energie consommée pour l’envoi d’un message DIO

DAO E=l’energie consommée pour l’envoi d’un message DAO

DAO R = la consommation énergétique pour la réception d’un DAO

DAO−ACK R= l’énergie dépensée pour la réception d’un DAO_ACK

DAO−ACK E =l’energie consommée pour l’envoi d’un DAO_ACK

d (i) = le nombre de fils à un saut d’un capteur i

l (i) = le nombre de voisins à un saut qui n’est ni fils ni parent d’un capteur i

m (i) = le nombre de fils du capteur i situés à deux sauts et plus de i

D = la durée de sommeil en millisecondes de la radio du capteur i

n D = le nombre de messages DIO émis durant D par le noeud i

CCA = l’énergie consommée pour effectuer un CCA (Clear Channel Assessment)

I =l’intervalle de fonctionnement du capteur

Imax = longueur maximale de l’intervalle de l’algorithme Trickle

P [T I ] = la probabilité pour qu’un noeud i envoi un message DIO dans l’intervalle I courant

– Formulation des équations de la consommation énergétique

Pour chaque DIO envoyé par le SINK dans un intervalle I, la consommation énergétique CE i (I)

d’un noeuds peut être évalué comme suit:

E1 = DIO R + DAO E + DAO−ACK R

(énergie consommée pour la réception et le traitement du DIO envoyé par son noeud parent)

E2 = DAO R + DAO−ACKE + DAO E + DAO−ACKR

(énergie consommée pour le traitement des messages DAO émis par les noeuds fils)

E3 = DIO R

(énergie consommée pour la réception d’un DIO émis par un noeud voisin ni fils, ni parent)

L’énergie CE i (I) consommée par chaque nœud i par intervalle I = I max, peut être estiméecomme suit :

Dans cette formule de consommation énergétique liée aux messages de contrơle et au CCA, on

constate que E1, E2 , E3, d (i) , l (i), m (i) , CCA et r sont des constantes Il s’agit pour nous ici d’agir sur les paramètres variables de cette formule analytique, notamment, Ph

T I(i)iet D pour

optimiser la consommation énergétique des nœuds dans le réseau

3.3.1 Réduction de la probabilité P hTI(i)i d’émission des messages de

contrơle

3.3.1.1 Utilisation d’un modèle analytique

Le protocole RPL génère un trafic de contrơle très important, il s’agit des messages DIO, DIS,DAO et DAO_ACK utilisés pour la construction et le maintien à jour de la topologie du réseau

Le trafic des messages DAO et DAO_ACK depend de celui des messages DIO Une optimisationdes messages DIO va donc reduire le nombre de message DAO et DAO_ACK émis dans le réseau.Cette optimisation du trafic de contrơle est nécessaire pour éviter une inondation excessive duréseau et économiser l’énergie des nœuds liée à l’émission des messages de contrơle dans le réseau.Dans le protocole RPL, l’envoi des messages DIO est géré par l’algorithme Trickle[5] présentéplus haut

Les auteurs de [5] ont présenté une formule analytique générique d’optimisation du trafic decontrơle mettant en relation la probabilité d’émission des messages de contrơle, la constance de

redondance k de l’algorithme Trickle et le degré des nœuds dans un réseau La formule présentée

par [5] est la suivante :



.



N −1 i



.



N −1 i



(P (tx)) j

(1 − (P (tx)) i−j

P (tx)=probabilité qu’un noeud emet un message DIO dans l’intervalle I courant

N = le nombre total de noeuds dans le réseau

A = la superficie occupée par l’ensemble des noeuds

a = la superficie couverte par la radio d’un noeud

k = la constante de redondance de l’algorithme Trickle

y = le degré du noeud

A partir des idées émises par cet article, nous faisons le constat suivant : Dans un réseau ó

la topologie est connue et le degré de chaque nœud fixe, la formule analytique ci-dessus donne les

deux cas suivant en fonction de la relation entre la constance de redondance k et le degré y du

nœud