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