thèse - LIFC - Université de Franche

Transcription

THÈSE
Présentée à
L’U.F.R DES SCIENCES ET TECHNIQUES
DE L’UNIVERSITÉ DE FRANCHE-COMTÉ
Pour l’obtention du
Grade de Docteur de l’Université de Franche-Comté
Spécialité INFORMATIQUE
Optimisation d’accès au médium et
stockage de données distribuées dans les
réseaux de capteurs
Par
Hung-Cuong LE
Rapporteurs
Directeurs
Examinateurs
Congduc PHAM
Professeur, Université de Pau et Pays de l’Adour
Jean-Jaques PANSIOT
Professeur, Université Louis Pasteur
Hervé GUYENNET
Professeur, Université de Franche Comté
Noureddine ZERHOUNI
Professeur, Ecole Nationale Supérieure de
Mécanique et des Microtechniques de Besançon
Vincent LECUIRE
Maître de Conférences, Université Henri Poincaré
Jean-Christophe LAPAYRE
Professeur, Université de Franche Comté
Remerciements
Je tiens à remercier en premier lieu le Professeur Hervé GUYENNET, mon directeur de thèse du
LIFC pour sa sympathie, sa disponibilité, ses idées, ses conseils et ses encouragements durant mes
trois années de thèse. Je voudrais également le remercier pour sa relecture et sa patience à corriger
cette thèse.
Je remercie le Professeur Noureddine ZERHOUNI, mon co-directeur de thèse du laboratoire
AS2M pour son suivi de mon travail de thèse et son aide lors du déploiement de la plateforme des
réseaux de capteurs au laboratoire AS2M.
J’exprime ensuite ma plus profonde gratitude au Professeur Congduc PHAM et au Professeur JeanJaques PANSIOT qui ont accepté de rapporter cette thèse malgré leur emploi du temps surchargé; à
M Vincent LECUIRE et au Professeur Jean-Christophe LAPAYRE qui m’ont fait plaisir de bien
vouloir participer au jury.
J’adresse également mes remerciements aux membres du LIFC pour leur accueil au sein du
Laboratoire d’Informatique de Franche Comté. Je me souviendrai toujours des Mercredis de
croissants pour les doctorants du LIFC.
Merci à mon ami, mon collègue de bureau depuis trois ans, Nabil ELMARZOUQI, pour les
discussions et ses encouragements dans la vie personnelle et professionnelle.
Merci à tous mes anciens et actuels collègues de bureau : Pamba CAPO-CHICHI, Kamal
BEYDOUN, Fabien HANTZ pour leur sympathie durant le temps où on a travaillé ensemble et
pour les discussions de recherche dans le domaine des réseaux de capteurs.
Je remercie Violeta FELEA, David MARTINS, Mohamed LEHSAINI pour les réunions et les
discussions dans le domaine de réseau de capteurs.
Je dois également remercier Weidong SHI, Yufei XU, Alan CASSARD, Olivier LUCIUS et Xavier
TITI pour leur travail lors de l’implémentation de la plateforme de réseau de capteurs.
Enfin et surtout, merci à mes parents, ma sœur, ma copine et mes amis vietnamiens pour leur aide
et leur encouragement durant toutes ses trois années.
III
IV
Table des matières
Remerciements ................................................................................................................. III Table des matières ............................................................................................................. V Table des figures .............................................................................................................. IX Liste des tableaux.......................................................................................................... XIII Chapitre 1. Introduction .................................................................................................... 1 Partie I
ETAT DE L’ART ........................................................................................... 7 Chapitre 2. Protocoles d’accès au médium ...................................................................... 9 2.1 2.2 2.3 Protocoles MAC basés sur la contention ............................................................ 10 2.1.1 Protocoles MAC basés sur la contention pour les réseaux sans fil :................. 10 2.1.2 Protocoles MAC pour les réseaux de capteurs ................................................. 13 Protocoles MAC sans contention ....................................................................... 26 2.2.1 Accès multiple par répartition dans le temps (TDMA) ................................... 27 2.2.2 Accès multiple par répartition en fréquence (FDMA) ...................................... 28 2.2.3 Accès multiple par répartition de code (CDMA).............................................. 28 Conclusion .......................................................................................................... 30 Chapitre 3. Méthodes de stockage de données distribuées ........................................... 33 3.1 Modèles de stockage de données dans les réseaux de capteurs.......................... 33 3.2 Stockage de données data-centric ....................................................................... 36 3.3 Partie II 3.2.1 Les paradigmes data-centric ............................................................................. 37 3.2.2 Stockage data-centric ........................................................................................ 38 Conclusion .......................................................................................................... 49 CONTRIBUTION ...................................................................................... 51 Chapitre 4. Protocole MAC économisant l’énergie pour réseaux de capteurs de
type surveillance ........................................................................................... 53 V
Table des matières
4.1 4.2 4.3 Protocole d’accès au médium basé sur l’écoute passive ..................................... 53 4.1.1 Hypothèse pour le réseau de capteurs ...............................................................54 4.1.2 Topologie du réseau ..........................................................................................54 4.1.3 Fonctionnement de OBMAC ............................................................................55 4.1.4 Portée influente .................................................................................................60 Evaluation de performance ................................................................................. 64 4.2.1 Paramètres de simulation ..................................................................................65 4.2.2 Temps de latence ...............................................................................................65 4.2.3 Consommation d’énergie ..................................................................................66 4.2.4 Variation de la portée influente .........................................................................67 4.2.5 Validation sur les capteurs Silicon ....................................................................69 Conclusion .......................................................................................................... 70 Chapitre 5. Protocole MAC à faible latence pour réseaux de capteurs orientés
évènement...................................................................................................... 73 5.1 5.2 5.3 5.4 Problème de la latence de transmission dans les protocoles existants d’accès au
médium................................................................................................................ 74 5.1.1 Topologie d’un réseau de capteurs orientés évènement ....................................74 5.1.2 Schéma de transmission multi-saut d’un évènement ........................................75 LLMAC : un protocole d’accès au médium à très faible latence ........................ 79 5.2.1 Transmission niveau évènement .......................................................................80 5.2.2 Intervalle Inter-trame de Continuité (Forward Inter-frame Spacing) ................81 5.2.3 Economie d’énergie ..........................................................................................83 Evaluation de performance ................................................................................. 86 5.3.1 Scénario de simulation ......................................................................................87 5.3.2 Variation du nombre R d’évènements...............................................................89 5.3.3 Variation du nombre d’évènements détectés ....................................................90 5.3.4 Variation du nombre de sauts vers la station de base ........................................91 5.3.5 Variation du nombre de trames par évènement.................................................92 5.3.6 Fiabilité .............................................................................................................93 5.3.7 Consommation d’énergie ..................................................................................94 Résultats d’expérimentation ................................................................................ 96 5.4.1 Scénario de test d’expérimentation ...................................................................96 VI
Table des matières
5.5 5.4.2 Latence de transmissions de chaque image ...................................................... 97 5.4.3 Comparaison entre LLMAC et CSMA ............................................................. 98 Conclusion .......................................................................................................... 99 Chapitre 6. Méthode de stockage de données distribuées pour réseaux de
capteurs ....................................................................................................... 101 6.1 Problème de stockage de données data-centric dans les réseaux de capteurs .. 102 6.2 Regroupement de capteurs pour optimiser le routage de DCS......................... 103 6.3 6.4 6.2.1 Organisation du réseau ................................................................................... 104 6.2.2 Stockage et récupération de données dans le réseau....................................... 106 6.2.3 Agrégation de données à deux niveaux .......................................................... 109 6.2.4 Technique de réplication de données .............................................................. 111 6.2.5 Réélection des cluster-heads ........................................................................... 112 Evaluation de performance ............................................................................... 112 6.3.1 Analyse théorique ........................................................................................... 112 6.3.2 Résultat de simulation .................................................................................... 113 Conclusion ........................................................................................................ 116 Chapitre 7. Conclusion ................................................................................................... 119 Bibliographie ................................................................................................................... 123 Bibliographie personnelle .............................................................................................. 131 Annexe A : Déploiement d’un réseau de capteurs pour la e-maintenance ............... 133 A.1 L’architecture de e-maintenance .......................................................................... 133 A.2 Le rôle d’un réseau de capteurs dans la e-maintenance......................................... 135 A.3 Plateforme de réseau de capteurs MicaZ de CrossBow ....................................... 136 A.3.1 Les compositions des matériels du kit ............................................................... 137 A.3.2 Les logiciels fournis par Crossbow ................................................................... 138 A.4 Accès à distance pour le réseau de capteurs via Internet ...................................... 139 A.5 Conclusion ............................................................................................................ 140 Annexe B : Abréviation et terminologie ....................................................................... 141 VII
Table des matières
VIII
Table des figures
Figure 1.1 - Architecture générale d’un réseau de capteurs ............................................................... 1 Figure 2.1 - Sous-couche MAC dans le modèle OSI et TCP/IP ......................................................... 9 Figure 2.2 - Problème de la station cachée et de la station exposée ................................................. 11 Figure 2.3 - Inter-frame spacing in 802.11 ....................................................................................... 13 Figure 2.4 - Périodique actif et endormi dans S-MAC ..................................................................... 16 Figure 2.5 - Ecoute adaptative de T-MAC ....................................................................................... 17 Figure 2.6 - Technique préambule d’échantillonnage ...................................................................... 19 Figure 2.7 - WiseMAC pour réduire le temps préambule ................................................................ 20 Figure 2.8 - Protocole MAC de IEEE 802.15.4 avec beacon ........................................................... 24 Figure 2.9 - Probabilité de choix de slot dans la fenêtre de contention CW = 32 ............................ 26 Figure 2.10 - Fonctionnement de CSMAC ....................................................................................... 30 Figure 3.1 - Modèles de stockage de données .................................................................................. 34 Figure 3.2 - Réseau pair-à-pair utilisant la table de hachage distribuée ........................................... 39 Figure 3.3 - Exemple de GPSR ........................................................................................................ 41 Figure 3.4 - Erreur de routage et la règle de la main droite .............................................................. 42 Figure 3.5 - Stockage de donnée de GHT basant sur GPSR ............................................................ 43 Figure 3.6 - Nœud “ home node” et “ home perimeter” dans GHT ................................................. 44 Figure 3.7 - Fonctionnement de GEM .............................................................................................. 48 Figure 4.1 - Topologie en arbre d’un réseau de capteurs ................................................................. 55 Figure 4.2 - Règle 4.1 de OBMAC avec 802.15.4 ........................................................................... 57 Figure 4.3 - Règle 4.1 de OBMAC avec S-MAC ............................................................................. 59 Figure 4.4 - OBMAC dans la portée influente de A ......................................................................... 61 Figure 4.5 - Diagramme du fonctionnement de OBMAC avec la portée influente ......................... 62 IX
Table des figures
Figure 4.6 - Temps de latence avec la portée influente α=-90 dBm .................................................65 Figure 4.7 - Consommation d’énergie de 802.15.4 et OBMAC .......................................................67 Figure 4.8 - Variation de la valeur de portée influente .....................................................................68 Figure 4.9 - Capteur Silicon ..............................................................................................................69 Figure 5.1 - Scénario de transmission d’un réseau de capteurs orientés évènement ........................75 Figure 5.2 - Chronologie de transmission pessimiste .......................................................................76 Figure 5.3 - Chronologie de transmission optimiste .........................................................................77 Figure 5.4 - Fonctionnement de LLMAC .........................................................................................80 Figure 5.5 - Economiser l’énergie dans LLMAC .............................................................................85 Figure 5.6 - Topologie de simulation ................................................................................................86 Figure 5.7 - Caméra Cyclops branchée sur Mica2 ............................................................................88 Figure 5.8 - Exemples des images prises par le capteur Cyclops .....................................................88 Figure 5.9 - Latence en faisant varier la valeur R .............................................................................89 Figure 5.10 - Latence en faisant varier le nombre de nœuds capteurs ..............................................90 Figure 5.11 - Latence en faisant varier le nombre de sauts à la station de base................................91 Figure 5.12 - Latence en faisant varier le nombre de trames par évènement ....................................92 Figure 5.13 - Pourcentage d’évènement reçu....................................................................................93 Figure 5.14 - Consommation d’énergie de chaque nœud avec N = 16 .............................................95 Figure 5.15 - Consommation d’énergie totale en faisant varier N ....................................................95 Figure 5.16 – Scénario de test d’expérimentation.............................................................................96 Figure 5.17 – Latence de transmissions en fonction de type d’images .............................................98 Figure 5.18 – Latence de transmission en comparaison entre CSMA et LLMAC ...........................98 Figure 6.1 - Gaspillage d’énergie dans le routage GPSR de GHT..................................................103 Figure 6.2 - Organisation du réseau ................................................................................................104 Figure 6.3 – Pseudo code sur la méthode d’organisation du réseau ...............................................106 Figure 6.4 - Stockage et récupération de données dans le réseau. ..................................................107 X
Table des figures
Figure 6.5 - Nœud mobile envoie une donnée............................................................................... 108 Figure 6.6 – Pseudo code sur le routage et agrégation de données ................................................ 109 Figure 6.7 - Deux niveaux d’agrégation de données ...................................................................... 110 Figure 6.8 - Nombre de transmissions total en faisant varier la valeur de Q.................................. 114 Figure 6.9 - Hotspot en faisant varier le nombre de requêtes Q ..................................................... 116 Figure A.1 - Classification de différentes architectures en maintenance ....................................... 133 Figure A.2 - Architecture d’un réseau de capteurs MicaZ ............................................................. 136 Figure A.3 - Composition d’un capteur MicaZ .............................................................................. 137 Figure A.4 - Station de base MIB520 ............................................................................................. 138 Figure A.5 - Interface de gestion d’un réseau de capteurs ............................................................. 139 Figure A.6 - Interface de gestion des évènements .......................................................................... 140 XI
Liste des tableaux
Tableau 2.1 - Niveaux de consommation d’énergie du capteur mica2 ............................................. 15 Tableau 3.1 - Paramètres du réseau .................................................................................................. 34 Tableau 3.2 - Comparaison des coûts des différents modèles de stockage de données.................... 46 Tableau 4.1 - Paramètres de simulation............................................................................................ 64 Tableau 4.2 - Valeurs de la puissance du signal reçu (dBm) en faisant varier la distance ............... 70 Tableau 5.1 - Paramètre de simulation ............................................................................................. 87 Tableau 5.2 - Nombre de trames par évènement en fonction de la taille des images ....................... 97 Tableau 6.1 - Paramètres de simulation.......................................................................................... 113 XIII
Chapitre 1.
Introduction
Ces dernières années ont été marquées par un développement très rapide des techniques de réseaux
sans fil. Des réseaux pour téléphones mobiles aux réseaux locaux sans fil et aux réseaux ad-hoc, la
recherche aujourd’hui s’est beaucoup focalisée sur les réseaux de capteurs sans fil (RdC). Ceux-ci
sont composés d’un grand nombre de nœuds communicants et distribués sur une zone donnée afin
de mesurer une grandeur physique ou surveiller un évènement [1][2]. La Figure 1.1 montre une
architecture générale d’un réseau de capteurs. Dans un tel réseau, chaque nœud est un dispositif
électronique qui possède une capacité de calcul, de stockage, de communication et d’énergie.
Chaque capteur est doté d’un module d’acquisition qui lui permet de mesurer des informations
environnementales : température, humidité, pression, accélération, sons, image, vidéo etc.
Réseau traditionnel,
Internet, …
Station de base
Bases de données
Passerelle
Capteurs
Figure 1.1 - Architecture générale d’un réseau de capteurs
En effet, suivant le type d’application, il y a plusieurs catégories de capteurs différents qui varient
en fonction de la taille, de la capacité de calcul, de la taille de la mémoire et de la bande passante.
Suivant les caractéristiques des capteurs, la taille du réseau, des protocoles de communications, le
RdC est structuré suivant quatre types principaux de plateformes [4]:
1
Chapitre 1. Introduction
•
Plateforme de capteurs miniaturisés : plateforme dédiée aux capteurs de taille très réduite
(quelques mm3) et de faible bande passante (<50Kbps). Un exemple très connu de ce genre
de plateforme est Spec [9], conçu par l’université de Berkeley. Avec une taille très petite
(2mmx2.5mm), Spec est un des plus petits capteurs au monde.
•
Plateforme de capteurs généraux : plateforme développée pour capter et router des
informations du monde ambiant. Quelques plateformes de cette famille ont été développés
et la plus récente est basée sur MicaZ [10], un capteur de taille ~10cm3 avec les protocoles
de communication IEEE 802.15.4 [12]. Aujourd’hui, MicaZ devient la référence dans les
travaux de recherche dans le domaine des réseaux de capteurs.
•
Plateforme de capteurs à haute bande passante : ces plateformes ont pour but de transporter
de gros volumes de données captées (la vidéo, le son, vibrations). Un exemple typique de
cette famille est Imote [11] dont la communication se base sur la norme Bluetooth 1.1 [13].
•
Plateforme de passerelles : ces dispositifs servent à transporter les informations envoyées
par le réseau de capteurs vers un réseau traditionnel (Ethernet, 802.11) dont Stargate [10]
est un exemple typique.
Parmi ces quatre plateformes, nous nous intéressons plus particulièrement à la plateforme de
capteurs généraux. La raison de notre choix tient à la popularité de ces réseaux ainsi que la
possibilité de programmation de ce genre de capteurs. Ainsi, nous avons déployé un réseau de
capteurs MicaZ au sein du laboratoire afin d’avoir une plateforme pour tester nos protocoles de
communication.
Les réseaux de capteurs sans fil font partie des thèmes de recherche très actifs actuellement car
cette technique peut être appliquée dans de nombreux domaines : surveillance des déplacements
des véhicules en zone hostile [14], observation de la vie des espèces rares [15], surveillance de la
structure des infrastructures [16][17], optimisation de traitement pour les patients [18] etc.
On trouve plusieurs méthodes pour classer les réseaux de capteurs [3][5]. Pour chaque type
d’application, les réseaux de capteurs ont des caractéristiques différentes. Ils se distinguent par le
modèle de communication, le modèle de transmission de données, le modèle de mobilité dans le
réseau etc. Selon les interactions entre le réseau de capteurs et la station de base, nous nous
intéressons à trois modèles principaux : modèle de mesure périodique, modèle de détection
d’évènements et modèle de transmission suite à des requêtes. Dans le premier modèle, tous les
capteurs envoient périodiquement leurs mesures à la station de base. Le type d’application visé
concerne les applications de type “surveillance” où le but principal est d’avoir une information
régulière de la zone surveillée. Dans le deuxième modèle, les capteurs envoient les mesures
seulement lorsqu’il y a un évènement qui se produit. Ce type de modèle est recommandé pour les
applications de surveillance d’évènements critiques où le but principal est l’obtention d’une
2
information sur l’évènement le plus rapidement possible. Dans le troisième modèle, les capteurs
mesurent des phénomènes et stockent ces mesures dans leur mémoire flash. Ils envoient ces
mesures seulement lorsqu’ils reçoivent des requêtes de la station de base. Ce modèle peut
également s’apparenter aux applications de type surveillance mais les capteurs utilisent une
mémoire flash importante afin de stocker les mesures localement.
Comme nous l’avons précisé dans la partie précédente, les capteurs sont de petits composants avec
une faible capacité de stockage, de calcul et sont alimentés avec une batterie ou avec des piles.
Pour qu’un réseau de capteurs reste autonome pendant une durée de quelques mois à quelques
années sans intervention humaine, la consommation d’énergie devient le problème fondamental.
Celle-ci n’est pas un grand problème pour les réseaux sans fil traditionnel, car on peut toujours
recharger les batteries des dispositifs sans fil comme les téléphones portables ou les ordinateurs
portables. Mais, dans un RdC, il est difficile (parfois impossible dans certaine applications) de
changer la batterie. Imaginons un réseau de capteurs déployé au pôle Nord pour surveiller la
variation de température, on ne peut pas envoyer quelqu’un toutes les semaines juste pour changer
la batterie.
Ces caractéristiques particulières du RdC modifient le critère de performance par rapport aux
réseaux sans fil traditionnels. Dans les réseaux locaux sans fil ou réseaux cellulaires, les critères les
plus importants à prendre en compte sont le débit et la latence. Avec la croissance de la
technologie, les utilisateurs sont de plus en plus exigeants en terme d’utilisation de service. Dans le
passé, les premières générations de réseaux cellulaires avaient uniquement pour but de transmettre
la voix. Depuis, les nouvelles générations de réseaux cellulaires permettent aux utilisateurs finaux
de faire beaucoup plus d’activités : transfert d’images, transfert de vidéos, navigation sur Internet.
Ces activités requièrent un débit important et une faible latence. Contrairement aux réseaux sans fil
traditionnels, dans le réseau de capteurs sans fil, nous n’avons pas besoin d’un grand débit de
transmission. Selon le type de RdC, nous avons besoin de critères de performances différentes.
Pour les réseaux de capteurs de type surveillance, puisqu’on veut maximiser la durée de vie, le
critère de consommation d’énergie est devenu le problème prépondérant tandis que les autres
critères comme le débit ou l’utilisation de la bande passante sont devenus secondaires. Pour les
RdC orientés évènement, nous voulons obtenir des informations à plus faible latence lorsqu’un
évènement se produit. Dans un réseau de capteurs, les communications coûtent chères par rapport
aux traitements locaux des données. Parfois, il vaut mieux stocker et traiter des données localement
plutôt que de faire des transmissions. Le modèle de stockage de données peut beaucoup influencer
la consommation d’énergie globale du réseau. Nous allons traiter toutes ces problématiques dans la
suite de cette thèse.
3
Plan de la thèse
Cette thèse est organisée en sept chapitres répartis dans deux parties principales : une partie état de
l’art et une partie contribution. La partie état de l’art présente les techniques existantes de
protocoles d’accès au canal et les protocoles de stockage de données distribuées dans les réseaux de
capteurs. La partie contribution expose nos propositions pour améliorer les performances des
réseaux de capteurs dans différentes applications. Plus précisément, notre contribution concerne
deux protocoles d’accès au médium pour deux types de réseaux de capteurs (réseaux de capteurs de
type surveillance et réseaux de capteurs orientés évènements) et un protocole de stockage de
données distribuées.
Dans le Chapitre 2, nous présentons l’historique des protocoles d’accès au canal pour les réseaux
sans fil et plus particulièrement pour les réseaux de capteurs sans fil. Les travaux dans les
protocoles d’accès au canal pour les réseaux de capteurs s’attache à minimiser la consommation
d’énergie afin de prolonger la durée de vie du réseau. Pour éviter le gaspillage d’énergie, deux
techniques sont développées: les protocoles MAC synchronisés et les protocoles MAC avec
préambule d’échantillonnage. Le but de ces deux techniques est de mettre les capteurs dans l’état
actif ou l’état endormi périodiquement pour économiser l’énergie. Ces techniques optimisent la
consommation d’énergie, mais elles impliquent une latence de transmission importante. Nous
présentons également quelques travaux existants sur la minimisation du temps de latence dans les
réseaux de capteurs. Nous discutons des avantages et des inconvénients de ces techniques afin de
les améliorer par la suite dans la partie contribution.
Dans le Chapitre 3, nous présentons les travaux existants dans les protocoles de stockage de
données distribuées. Dans un réseau de capteurs, les communications sont très coûteuses en terme
de consommation d’énergie. Le choix du stockage de données peut beaucoup influencer sur le
nombre de communications et ainsi la durée de vie du réseau. Nous présentons les différents
modèles de stockage de données et détaillons le modèle de stockage data-centric. Ce modèle est
basé sur les techniques de partage de données dans les réseaux pair-à-pair qui permet un bon
équilibrage de charge entre les nœuds dans le réseau. Cependant, l’adaptation des protocoles de
routage des réseaux pair-à-pair aux réseaux sans fil nécessite des modifications et cela implique
une problématique particulière dans ce domaine de recherche.
Le Chapitre 4 débute notre contribution avec une proposition pour améliorer les performances des
réseaux de capteurs. Dans ce chapitre, nous présentons un protocole d’accès au canal pour les
réseaux de capteurs de type surveillance que l’on appelle OBMAC (Overhearing Based MAC).
Dans ce type de réseau, nous nous intéressons à la minimisation de la consommation d’énergie.
L’écoute passive est le cas où un capteur perd le canal et doit patienter pour accéder au canal plus
tard. Pendant ce temps, il va gaspiller son énergie. Cependant, nous montrons que l’écoute passive
n’est pas toujours une cause de gaspillage d’énergie. En effet, elle peut être une bonne méthode
4
pour justement économiser cette énergie. En effet, nous profitons de l’écoute passive pour réduire
les transmissions redondantes, réduire la consommation d’énergie et prolonger la durée de vie du
réseau. Afin d’assurer la pertinence de notre proposition, nous limitons l’application de OBMAC
dans une portée que l’on appelle la portée influente. Le résultat d’évaluation de la consommation
d’énergie est réalisé par simulation et les valeurs de la portée influente sont évaluées à l’aide de
capteurs Silicons.
Dans le Chapitre 5, nous présentons un protocole d’accès au canal pour les réseaux de capteurs
orientés évènement. Contrairement aux réseaux de capteurs de type surveillance où l’on s’intéresse
à la consommation d’énergie, dans les réseaux de capteurs orientés évènement, nous nous
intéressons plus à la latence de transmission. Notre protocole d’accès au canal, LLMAC (Low
Latency MAC), permet une faible latence de transmission multi-saut pour les réseaux de capteurs
orientés évènements. Nous changeons les niveaux de priorité des nœuds pour favoriser le flux de
transmission des évènements. Comme les capteurs fonctionnent en utilisant des piles, nous
proposons également une technique qui permet d’économiser l’énergie afin de prolonger la durée
de vie du réseau. Les résultats d’évaluation sont réalisés par simulation et sur une plateforme réelle
des réseaux de capteurs d’image Cyclops.
Dans le Chapitre 6, nous traitons une autre problématique des réseaux de capteurs. Il s’agit du
stockage de données distribuées. Nous proposons une structure de regroupement des capteurs dans
le réseau afin d’optimiser le routage et réduire le nombre de transmissions dans le réseau. Nous
donnons également une classification des capteurs en deux types : capteurs statiques et capteurs
mobiles. Cette classification permet de réduire la mauvaise influence des nœuds mobiles du
protocole de routage du réseau. Profitant de la structure de regroupement, nous proposons deux
niveaux d’agrégation des données qui permettent de réduire encore le nombre de communications
dans le réseau. Comme ce travail est basé sur un réseau à large échelle, nous réalisons des
évaluations de performances via la simulation.
Dans le Chapitre 7, nous concluons cette thèse et nous présentons quelques perspectives de travail
pour le futur.
En annexe, nous présentons le déploiement d’un réseau de capteurs dans un atelier sur une chaîne
de transfert afin d’améliorer la maintenance de ce dispositif.
5
Partie I
ETAT DE L’ART
7
8
Chapitre 2.
Protocoles d’accès au médium
Dans les télé-communications, les médiums de transmission peuvent être classés selon deux types
de supports différents : filaire et sans fil. Les supports filaires sont les câbles électriques, des fibres
optiques ; tandis que les supports sans fil sont les ondes radio, les ondes lumineuses, magnétiques.
Le but de ces supports est de transporter un flot de bits d’information d’une source vers une
destination. Le médium de transmission est un dispositif commun pour tous les nœuds du réseau, il
nécessite donc un mécanisme qui gère l’accès des nœuds pour déterminer le droit d’émettre de
chacun d’entre eux dans le réseau. Dans le modèle OSI et TCP/IP [2], cette tâche est gérée par la
couche MAC, la sous-couche de la couche liaison de données Figure 2.1.
Réseau
Liaison de données
Sous-couche MAC
Physique
Figure 2.1 - Sous-couche MAC dans le modèle OSI et TCP/IP
En effet, les protocoles d’accès sont très variés selon le type de médium de transmission (filaire ou
sans fil). Dans les réseaux filaires, les protocoles MAC sont moins compliqués car il est plus facile
de détecter les transmissions des autres afin d’éviter les collisions. Nous nous intéressons dans cette
thèse seulement aux protocoles d’accès au médium des réseaux sans fil. Nous classons les
protocoles d’accès au canal en deux familles principales [21] : les protocoles MAC basés sur la
contention et les protocoles MAC sans contention. Dans la première famille, tous les nœuds
accèdent au canal en concurrence, il y a possibilité de collisions lorsque plus de deux nœuds
accèdent au canal simultanément. Au contraire, dans la deuxième famille, chaque nœud possède
son propre intervalle de temps ou sa propre fréquence de transmission. Les nœuds accèdent au
canal sans concurrence et il n’y a jamais de collisions. Nous allons analyser plus en détail ces deux
familles de protocoles MAC dans la partie qui suit. Les travaux de recherche des protocoles MAC
sont très riches [5][6][7][8] et le but de ce chapitre n’est pas de présenter une liste exhaustive de
9
Chapitre 2. Protocoles d’accès au médium
tous les protocoles MAC. Nous allons juste présenter des travaux principaux dans ce domaine afin
de proposer nos solutions dans la partie contribution.
2.1
Protocoles MAC basés sur la contention
Les protocoles MAC basés sur la contention sont apparus dès le début des communications sans fil.
Ils continuent à être améliorés pour s’adapter aux différents types de réseaux. Dans cette partie,
nous allons d’abord analyser les protocoles MAC pour les réseaux sans fil. Ensuite, nous nous
intéresserons aux protocoles MAC spécifiques pour les réseaux de capteurs sans fil.
2.1.1 Protocoles MAC basés sur la contention pour les réseaux sans
fil :
En 1970, le protocole ALOHA [22] est proposé comme le premier protocole de gestion d’accès au
canal pour les réseaux sans fil. L’idée du protocole ALOHA est simple : un nœud accède au canal
quand il a des données à transmettre. Si plusieurs nœuds accèdent au canal en même temps, les
trames de données rentrent en collision ce qui engendre des retransmissions. Après une collision,
les nœuds attendent un temps aléatoire avant de réessayer de transmettre à nouveau. Deux ans
après, L.J Roberts a proposé une amélioration du protocole ALOHA qui s’appelle ALOHA
discrétisé [23]. Dans ce protocole, le temps est divisé en slots correspondant aux trames de
données. Les nœuds se synchronisent entre eux et ils transmettent des trames de données au début
de chaque slot. La collision se produit seulement quand deux nœuds émettent en même temps sur le
même slot. ALOHA discrétisé génère de meilleures performances que ALOHA classique.
Les protocoles ALOHA ne prennent pas en compte les transmissions des autres, ce qui augment le
nombre de collisions dans le réseau. Pour remédier à ce problème, le protocole d’accès multiple par
écoute de porteuse (Carrier Sense Multiple Access – CSMA) a été proposé en 1975 dans [24]. Dans
ce protocole, avant de transmettre des trames de données sur le réseau, un nœud écoute le médium
de transmission pour voir ce qui se passe dans le canal. Si le canal est libre, il transmet les trames
de données. Sinon, il attend un certain temps et il peut retenter de transmettre à nouveau. Selon la
façon qu’un nœud attend le canal, les auteurs proposent 3 protocoles principaux CSMA [24] :
CSMA 1-persistant, CSMA non persistant et CSMA p-persistant. Dans le premier cas, si un nœud
détecte que le canal est occupé, il continue à surveiller le canal jusqu’à ce qu’il soit libre. Ce nœud
transmet ses trames dès que le canal est libre. Ce protocole est efficace en terme de temps d’attente.
Pourtant, si plusieurs nœuds sont entrain d’attendre avant de transmettre, lorsque le canal est libre
ils vont tous transmettre en même temps ce qui provoque une collision. Pour les nœuds qui sont
moins pressés de transmettre, le protocole CSMA non persistant est plus adaptable. Dans ce
protocole, une fois qu’un nœud détecte que le canal est occupé, il ne reste pas en écoute en
permanence mais il attend un temps aléatoire avant de retenter de transmettre à nouveau. Cela évite
10
2.1 Protocoles MAC basés sur la contention
le problème où différents nœuds attendent le canal et transmettent les trames de données en même
temps lorsque le canal devient libre. Enfin, le protocole CSMA p-persistant semble être le
protocole intermédiaire entre CSMA 1-persistant et CSMA non persistant. Après avoir détecté un
canal occupé, les nœuds restent en écoute sur le canal. Cependant, une fois que le canal est libre, ils
ne transmettent qu’avec une probabilité p.
Dans les trois protocoles CSMA présentés ci-dessus, les auteurs supposent que tous les nœuds sont
dans la portée des ondes radio des autres. Pourtant, cela n’est pas toujours le cas, car dans les
réseaux sans fil, il y a des nœuds qui ne sont pas dans la portée des autres. Un nœud ne peut pas
communiquer avec un autre si ce dernier est à l’extérieur de sa portée. Cela est complètement
différent par rapport aux réseaux filaires où les nœuds partagent le médium de transmission filaire.
Quand un nœud transmet, tous les autres nœuds dans le réseau sont immédiatement au courant (ou
dans un très court intervalle de temps) de cette transmission. Dans les réseaux sans fil, comme la
portée des ondes radio est limitée, il existe quelques problèmes avec l’utilisation de CSMA. Ces
problèmes sont bien connus sous le nom des problèmes de la station cachée [25] et exposée.
A
a)
B
C
D
C émet une transmission lorsque A
est entrain de transmettre
A
B
C
D
b) C ne peut pas émettre quand B est entrain
de transmettre
Figure 2.2 - Problème de la station cachée et de la station exposée
La Figure 2.2 illustre ces problèmes avec quatre nœuds interconnectés dans un réseau sans fil. Les
deux nœuds voisins sont connectés et la portée des ondes radio est limitée entre les voisins. Dans
Figure 2.2a, lorsque A transmet ses paquets à B, C ne détecte pas cette transmission car il se trouve
hors de la portée de A. Quand C trouve que le canal est libre, il commence à transmettre et cela
provoque une collision sur B. Ce problème où un nœud transmet des trames quand il n’a pas le
droit est appelé le problème de la station cachée.
Dans le cas symétrique, la Figure 2.2b illustre une transmission de B vers A. C est le voisin de B et
il détecte que le canal est occupé. Lorsque C a de données à envoyer vers D, il ne peut pas envoyer
car le canal est occupé. Cependant, C peut éventuellement transmettre des trames de données vers
D sans interférer le récepteur A. Ce problème où un nœud peut transmettre des trames alors qu’il
croit être sollicité est appelé le problème de la station exposée.
11
Pour éviter le problème de la station cachée, F.A Tobagi et Al ont proposé une extension de CSMA
nommé BTMA (Busy Tone Multiple Access) [25] la même année. L’idée de BTMA est d’utiliser
deux canaux de communication : le premier pour la transmission des trames de données et le
deuxième pour signaler qu’un nœud est en état de réception. Quand un nœud reçoit des données
sur le premier canal, il émet un signal occupé sur le deuxième canal pour que les nœuds voisins
n’émettent pas. Ainsi, le fait d’utiliser deux canaux de communication rend BTMA compliqué en
termes de conception de matériel. Quelques extensions de BTMA ont été proposées dont le premier
est MACA [26]. Les nœuds utilisent un seul canal de communication. Afin d’éviter le problème de
la station cachée, MACA (Multiple Access Collision Avoidance) utilise les paquets de contrôle
RTS (Request To Send) et CTS (Clear To Send). Cette idée est inspirée du protocole AppleTalk
[27]. Un nœud échange les paquets de contrôle avant d’émettre les trames de données. Une fois
qu’un nœud reçoit CTS après avoir envoyé RTS, il commence à transmettre immédiatement sans
utiliser l’écoute de porteuse. Lorsque les nœuds voisins reçoivent ces paquets de contrôle, ils
savent qu’il y a une transmission dans le médium et n’essaient pas d’accéder au canal
immédiatement.
Le protocole MACA fonctionne bien dans le cas où il n’y a pas d’erreurs de transmission. Mais,
dans un réseau sans fil, des erreurs de transmission sont inévitables à cause du bruit ou d’obstacle
dans l’environnement. MACAW (MACA for Wireless LANs) [28] ajoute les paquets
d’acquittement ACK (Acknowledgement) à la fin de chaque trame de données envoyée pour
garantir une bonne transmission dans le réseau. MACAW améliore MACA en augmentant le débit
du réseau. Avec le développement rapide de différentes techniques d’accès au médium des réseaux
locaux sans fil, l’organisation IEEE a standardisé une norme pour ce type de réseau local sans fil
nommé IEEE 802.11 [29][30][31]. Cette norme propose deux protocoles MAC : Fonction de
Coordination Distribuée (DCF - Distributed Coordinate Function) et Fonction de Coordination du
Point d’Accès (PCF – Point Coordinate Function).
Le mode DCF est un protocole d’accès au médium purement distribué et il se base sur MACAW en
ajoutant l’écoute d’un canal virtuel. Ce dernier est une évaluation du temps de transmission
lorsqu’un nœud reçoit des paquets RTS, CTS, ACK des autres. Pendant cette durée de temps, les
nœuds savent que le canal est occupé et ils essaient d’accéder au canal lorsque cette durée du temps
expire. En plus, le canal de communication sans fil est normalement bruité. La transmission est
fréquemment terminée par une erreur. DCF propose de diviser un paquet long en plusieurs
fragments et de les envoyer en rafale avec des accusés de réception.
Le mode PCF est un protocole d’accès au médium centralisé où la station de base gère tous les
droits d’accès au canal de tous les nœuds dans le réseau. Afin de faire coopérer les différents
modes d’accès au canal, IEEE 802.11 propose différents intervalles inter-trame pour distinguer les
différents niveaux de priorité : Intervalle Inter-trame court (SIFS – Short Inter-frame Spacing),
Intervalle Inter-trame PCF (PIFS – PCF Inter-frame Spacing), Intervalle Inter-trame DCF (DIFS –
12
DCF Inter-frame Spacing) (Figure 2.3). Un nœud doit attendre un intervalle inter-trame et un temps
back-off avant d’accéder au canal. L’intervalle inter-trame court est réservé pour les paquets de
contrôle (e.g RTS, CTS, ACK). Lorsqu’un nœud reçoit un RTS ou une trame, il est sûr de gagner le
canal pour répondre au transmetteur. Le standard IEEE 802.11 donne plus de priorité au mode PCF
qu’au mode DCF. Après l’expiration de PIFS, la station de base a le droit d’accéder au canal afin
de diffuser l’ordonnancement du temps d’accès au canal à tous les nœuds. Après tous ces
intervalles de temps, si aucun nœud n’accède au canal, tous les nœuds attendent la fin de DIFS
pour commencer la contention afin de décider le droit d’accès au canal.
DIFS
PIFS
Canal occupé
SIFS
Fenêtre de contention
Trame
Figure 2.3 - Inter-frame spacing in 802.11
Dans cette partie, nous avons présenté les contributions majeures dans le domaine du contrôle
d’accès au médium basé sur la contention pour les réseaux sans fil. Nous avons vu une évolution
rapide de ces techniques dans le temps. Une présentation complète de tous les protocoles d’accès
au médium n’est pas le but de cette partie. Ce sont simplement les protocoles de base qui ont
inspiré plusieurs protocoles d’accès au médium dans les réseaux de capteurs que nous allons
analyser dans la partie suivante.
2.1.2 Protocoles MAC pour les réseaux de capteurs
Comme nous l’avons présenté dans les parties précédentes, un réseau de capteurs sans fil a des
spécificités plus nombreuses qu’un réseau sans fil traditionnel. En particulier, dans un réseau de
capteurs sans fil, les dispositifs sont très sensibles à la consommation d’énergie. Il faut donc
trouver un moyen pour minimiser le niveau de consommation d’énergie afin d’avoir une durée de
vie plus longue.
Avant d’analyser les protocoles MAC qui optimisent la consommation d’énergie, nous
commençons par une analyse des raisons de dissipation d’énergie. En effet, les capteurs
consomment leur énergie dans deux cas: quand ils communiquent entre eux et quand ils traitent des
informations localement. Mais, dans quel cas les capteurs consomment-ils le plus d’énergie? Pour
avoir une estimation sur le niveau de consommation d’énergie dans les deux cas, G.J Potter et al
[32] ont montré que le transport de 1 ko de données sur 100m consomme autant d’énergie que le
traitement de 3 millions d’instructions. On voit donc que la communication coûte chère et qu’il est
préférable de traiter les données localement plutôt que de faire des communications entre les
capteurs.
13
Limiter les temps de communication est une solution pour réduire la consommation d’énergie. De
plus, lorsque les capteurs communiquent, il existe toujours des gaspillages d’énergie. Il nous faut
comprendre ces raisons afin de pouvoir réduire ces gaspillages. Dans [33][34], les chercheurs de
l’Université de Californie ont identifié quatre raisons de gaspillage d’énergie :
•
D’abord, la collision est le cas où deux nœuds transmettent les trames de données en même
temps vers un seul destinataire, cela génère une collision sur le récepteur. Cette collision
implique une retransmission des trames de données et augmente la consommation
d’énergie.
•
La deuxième raison est l’écoute passive (overhearing), où les nœuds écoutent les trames de
données qui ne leur sont pas destinées. Puisque le médium est un environnement commun,
lorsqu’un émetteur transmet ses trames de données, tous les nœuds qui se trouvent autour
de lui sont obligés d’écouter cette transmission. Cette écoute passive est nécessaire pour
déterminer le moment où le médium de transmission se libère afin de transmettre les
trames de données.
•
Le canal sans fil est un médium de transmission bruité et il y a très souvent des erreurs de
transmission. Alors, l’utilisation de paquet de contrôle est une méthode efficace pour
contrôler les trames d’erreurs. Cependant, lorsqu’ils ne contiennent aucune donnée et qu’ils
consomment, c’est un gaspillage d’énergie.
•
Enfin, la dernière raison est l’écoute non-active. En effet, c’est le temps où un nœud écoute
le médium pour attendre une éventuelle transmission vers lui. Quand un nœud ne peut pas
savoir le moment où les autres lui envoient des trames de données, il doit toujours mettre
son transceiveur en marche. De ce fait, s’il n’y a pas de transmission vers lui, ce nœud
consomme de l’énergie pour rien.
Le transceiveur possède quatre modes de fonctionnement : transmission, réception, écoute nonactive et endormi. Le Tableau 2.1 illustre les niveaux de consommation d’énergie d’un capteur
mica2 [10]. Dans la plupart des cas, les consommations d’énergie en mode réception et en écoute
non-active sont similaires et elles consomment environ la moitié du mode de transmission. Par
contre, la consommation d’énergie en mode endormi est beaucoup plus basse.
Comme nous l’avons précisé dans les parties précédentes, les réseaux de capteurs ont un niveau de
trafic très faible. Soit les capteurs envoient les données périodiquement, soit ils envoient les
données lorsqu’il y a un évènement. La plupart du temps, les nœuds sont en écoute non-active et
cela est une source de gaspillage d’énergie la plus importante. Dans le modèle réseau, la couche
MAC décide du mode de fonctionnement de transceiveur. Donc, cette couche doit gérer le
transceiveur pour réduire le temps d’écoute non-active des capteurs afin de réduire la
consommation d’énergie et prolonger la durée de vie du réseau de capteurs.
14
Etat
Consommation énergie (mW)
Transmission
80
Réception / non-actif
30
Endormi
0.003
Tableau 2.1 - Niveaux de consommation d’énergie du capteur mica2
Considéré comme la première proposition dans la famille MAC basée sur la contention qui réduit
la consommation d’énergie, PAMAS [35] a été proposé en 1998 pour les réseaux ad-hoc. En effet,
il est inspiré par MACA [26] en utilisant deux canaux de communication : un pour les paquets de
contrôle et la tonalité occupée (busy tone) et un pour les trames de données. Après avoir échangé
les paquets de contrôle, les nœuds commencent à communiquer en utilisant le canal de
transmission. En même temps, il émet une tonalité occupée sur le deuxième canal. Quand les
nœuds voisins reçoivent la tonalité occupée, ils savent qu’il y a une transmission et n’émettent pas
leurs trames de données. La solution de PAMAS réduit également les collisions par rapport à
MACA. En plus, quand les nœuds reçoivent une tonalité occupée, ils savent qu’ils ne peuvent pas
recevoir ou transmettre des données, ils vont éteindre leur transceiveur afin de réduire la
consommation d’énergie. Cela est un avantage de PAMAS par rapport à MACA. Pourtant,
PAMAS ne propose pas de technique pour réduire le temps d’écoute non-actif, ce qui génère le
gaspillage d’énergie le plus important. En plus, le fait d’utiliser deux canaux de communication
limite son application dans le domaine de réseaux de capteurs car la plupart des capteurs utilisent
seulement un canal de communication pour des raisons de prix et de conception de capteurs
Après PAMAS, plusieurs travaux de recherche ont été menés afin de réduire la consommation
d’énergie. Le but principal de ces travaux était de réduire le temps d’écoute non-active des
capteurs. Selon le mode de fonctionnement, ces travaux sont divisés en deux parties : des
protocoles "MAC synchronisés" et protocoles "MAC préambule d’échantillonnage". Nous allons
analyser plus en détails ces deux sous-familles de protocole MAC dans la partie qui suit.
a)
Les protocoles MAC synchronisés
Constatant que dans un réseau de capteurs, l’équité et la latence ne sont pas aussi importants que la
consommation d’énergie, W. Ye et al ont proposé S-MAC (Sensor-MAC) [33][34]. S-MAC fait
partie de la famille “MAC synchronisé” et il est considéré comme la référence des protocoles MAC
dans le domaine des réseaux de capteurs. L’idée principale de S-MAC est de diviser le temps de
fonctionnement du transceiveur en deux parties : active et endormi. Quand le transceiveur se met
en actif, le capteur est prêt à transmettre ou à recevoir les données, tandis que lorsque le
transceiveur se met dans l’état endormi, le capteur ne peut ni transmettre ni recevoir les données.
15
Comme le but de S-MAC est de réduire la consommation d’énergie, il faut prolonger le temps
endormi du transceiveur afin de réduire la consommation d’énergie des capteurs. Pourtant, lorsque
les capteurs se mettent dans l’état endormi et actif périodiquement, il pourrait y avoir un
problème. Comme les capteurs fonctionnent d’une manière indépendante, un capteur peut être actif
tandis que ses voisins sont dans l’état endormi. Si le capteur actif transmet des trames de données à
un capteur endormi, cela va poser le problème appelé “envoi sourd” (deaf listening) car le capteur
endormi ne peut pas recevoir des données. La solution de S-MAC est que les nœuds doivent se
synchroniser entre eux pour se mettre dans l’état actif et l’état endormi en même temps. La
synchronisation est réalisée grâce au paquet SYNC (Figure 2.4). Les nœuds envoient
périodiquement un paquet SYNC pour se synchroniser entre eux et pour connaître le temps où ils
ont le droit de transmettre et le temps où ils doivent être éteints pour économiser l’énergie. Quand
un nœud participe à un réseau, il cherche dans le réseau s’il y déjà un cycle de synchronisation. Si
cela est le cas, ce nœud adapte son cycle de travail avec le cycle existant. Sinon, ce nœud crée son
propre cycle et diffuse le paquet SYNC à tous les nœuds voisins. Comme les nœuds synchronisent
leur cycle de travail, S-MAC est classé dans la famille des protocoles MAC synchronisés.
En effet, l’intervalle actif est le temps où les nœuds se synchronisent et transmettent les paquets de
contrôle. La Figure 2.4 illustre bien la composition de ces intervalles dans le temps. Les nœuds qui
ont des données à transmettre ou à recevoir vont échanger les paquets de contrôles RTS/CTS. Une
fois que ces paquets de contrôle sont échangés, le transmetteur et le récepteur continuent de rester à
l’état actif pendant toute cette période. Les nœuds qui n’ont pas de données à transmettre ou à
recevoir vont éteindre leur transceiveur jusqu’à la fin de la période.
une période
SYNC RTS
CTS
endormi
SYNC RTS
CTS
endormi
Figure 2.4 - Périodique actif et endormi dans S-MAC
Cette méthode permet aux capteurs d’éviter le problème d’écoute non-active, mais elle augmente la
latence car les nœuds ne peuvent transmettre qu’au début de chaque période. Après avoir reçu les
données, le récepteur ne peut pas faire suivre les trames de données immédiatement car le nœud
suivant est déjà dans l’état endormi. Il doit attendre jusqu’au début de la prochaine période pour
accéder au canal. Les auteurs ont proposé une écoute adaptative [34] afin de réduire cette latence.
Quand un nœud écoute un RTS/CTS, s’il est transmetteur/récepteur, il va mettre son transceiveur
actif. Sinon, il se met en veille seulement pendant le temps de transmission entre transmetteur et
récepteur et il se réveille juste à la fin de cette transmission afin de savoir s’il est le futur récepteur
16
d’une transmission multi-saut. Mais, ces extensions restent toujours limitées à deux sauts car les
nœuds ne peuvent pas signaler les nœuds à distance qui doivent se mettre en actif pour toute la
transmission multi-saut. Cependant, avec certaines applications de réseau de capteurs, cette latence
est acceptable. S-MAC économise la consommation d’énergie et de ce fait, un réseau de capteurs
peut prolonger sa durée de vie jusqu’à quelques années. Un inconvénient majeur de S-MAC est que
la proportion entre le temps actif et endormi est fixe ce qui empêche les capteurs de s’adapter à
différents niveaux de trafic.
Pour remédier aux inconvénients de S-MAC, Tijs van Dam et al ont proposé T-MAC (TimeoutMAC) [36]. Dans T-MAC, les nœuds se synchronisent pour mettre leur transceiveur actif et
endormi périodiquement comme S-MAC. Cependant, T-MAC adapte l’intervalle de temps actif à
différents niveaux de trafic du réseau. Cet intervalle de temps n’est plus fixé par l’application mais
varie selon le trafic du réseau. Si le trafic est important, les capteurs restent plus longtemps en actif
afin de transmettre plus de données. Au contraire, si le trafic est faible, les capteurs restent un
temps plus bref actif afin d’économiser l’énergie. En effet, les capteurs décident de se mettre en
veille lorsqu’ils ne trouvent pas d’activités dans le réseau pendant une durée de temps que les
auteurs ont appelés TA. Ces activités concernent la réception d’une trame ou une collision et TA
est un seuil suffisamment long pour garantir qu’il n’y ait aucune activité dans le réseau. La Figure
2.5 illustre une comparaison entre S-MAC et T-MAC. Nous pouvons voir que l’intervalle actif de
S-MAC reste toujours fixe tandis que l’intervalle actif de T-MAC varie selon le trafic. Si le trafic
est en baisse, l’intervalle actif de T-MAC diminue et au contraire, si le trafic est en hausse,
l’intervalle actif de T-MAC augmente.
S-MAC
Actif
Actif
T-MAC
TA
endormi
endormi
Actif
endormi
endormi
Actif
TA
Actif
Actif
TA
Figure 2.5 - Ecoute adaptative de T-MAC
Pour réduire la latence de la transmission multi-saut, T-MAC propose un nouveau type de paquet
de contrôle FRTS (Future-RTS). Ce paquet a pour but de signaler au nœud qu’il est récepteur d’une
transmission, alors que le transmetteur est dans la portée d’une transmission en cours et ne peut pas
transmettre. Lorsqu’un nœud reçoit FRTS, il devient actif à la fin de la transmission en cours pour
recevoir les futures trames de données. Cette méthode réduit également la latence de transmission
multi-saut de capteurs vers la station de base. Comparé à l’écoute adaptative de S-MAC, cette
méthode de T-MAC est plutôt active car le transmetteur précise le nœud récepteur qui doit rester
17
actif après la transmission tandis que S-MAC est plutôt passive car les nœuds alentours doivent se
réveiller pour voir s’ils vont être prochainement récepteurs.
L’écoute adaptative de S-MAC [34] et T-MAC [36] améliore la latence de transmission en
affectant seulement le nœud du saut suivant et des deux sauts suivants. Afin de réduire la latence
d’une manière globale, FPA (Fast Path Algorithm) [37] propose une extension de S-MAC à
condition que ce soit une transmission unidirectionnelle de capteurs vers la station de base. Les
nœuds établissent un chemin de routage depuis un nœud feuille vers la station de base. Selon sa
position dans la topologie, un nœud estime le temps que son fils va lui envoyer des trames de
données. Il se réveille pendant ce temps afin de recevoir des données et les faire suivre à son père.
L’idée de FPA ressemble à l’écoute adaptative de SMAC [34], mais avec une aide plus efficace de
l’information de routage de la couche réseau. Ainsi, la latence globale est améliorée pour une
transmission multi-saut depuis une feuille vers la station de base.
Toujours dans le but de réduire la latence de transmission, DSMAC [38] change dynamiquement
les périodes actives de S-MAC selon la demande et le trafic. Au début, tous les nœuds fonctionnent
avec le même cycle. Quand un récepteur détecte un retard de transmission multi-saut, il double son
cycle de travail et annonce ce changement dans le paquet SYNC. Lorsqu’un transmetteur reçoit ce
changement, si il a des données à envoyer vers ce récepteur, il va doubler son cycle de travail
également afin d’envoyer les données à une faible latence. Pourtant, le choix de doubler le cycle de
travail dépend également de l’état du nœud. Un nœud double son cycle de travail seulement s’il a
suffisamment d’énergie. Comme le cycle de travail ajouté se trouve toujours au milieu des périodes
actives, les nœuds qui doublent leur cycle de travail se synchronisent aussi pour faire des
transmissions dans la période supplémentaire.
Toujours basée sur la méthode de mise en mode actif et endormi périodiquement des transceiveurs,
DMAC [39] offre une latence très faible si l’on compare avec d’autres protocoles MAC de la
même famille. En effet, DMAC [39] se base sur la topologie des réseaux de capteurs où les
capteurs forment un arbre de collection de données unidirectionnel. Une période active se divise en
deux sous-périodes : une pour la réception et une pour la transmission. La période de réception
d’un nœud correspond à la période de transmission de son fils et la période de transmission d’un
nœud correspond à la période de réception de son père. De ce fait, lorsqu’un nœud a reçu les
données de son fils, il peut les faire suivre tout de suite à son père. Nous pouvons constater que
selon la position d’un nœud dans le réseau, le cycle de travail est décalé entre un nœud père et son
fils. Pourtant, il requiert une forte synchronisation entre les nœuds. Bien que DMAC offre un
résultat intéressant en termes de latence, il souffre de quelques inconvénients. Lorsque la topologie
change, il faut modifier le cycle de travail des capteurs car leur position change dans l’arbre. En
plus, les capteurs dans le même niveau accèdent au canal en contention ce qui peut provoquer des
collisions.
18
b)
Les protocoles MAC avec préambule d’échantillonnage
Jusqu’ici, nous avons vu quelques protocoles MAC synchronisés pour les réseaux de capteurs afin
de réduire la consommation d’énergie. Dans ces protocoles, tous les nœuds doivent se synchroniser
pour travailler et dormir en même temps. Cependant, cette synchronisation requiert des échanges
de paquets de contrôle supplémentaires ce qui crée un surcoût de transmission. En plus, la garantie
de synchronisation globale d’un réseau de capteurs n’est pas facile à atteindre.
Une deuxième méthode pour réduire la consommation d’énergie sans utiliser la méthode de
synchronisation a été proposée sous le nom “préambule d’échantillonnage” (preamble sampling).
Dans le domaine des télécommunications, le préambule d’échantillonnage est une méthode
classique utilisée dans les systèmes paging [40][41] afin d’optimiser la consommation d’énergie
pour les dispositifs électroniques. Ceux-ci s’endorment la plupart du temps pour économiser
l’énergie et ils se réveillent périodiquement pour écouter les éventuelles transmissions. S’il n’y a
pas d’activité dans le médium, les dispositifs retournent à l’état endormi. Au contraire, ils restent
en écoute sur le canal pour recevoir d’éventuelles trames de données. Tous les nœuds utilisent la
même période d’échantillonnage (le temps entre deux écoutes consécutives). Cependant, comme ils
ne se synchronisent pas, cela nécessite donc que le transmetteur connaisse le moment où le
récepteur se réveille pour bien transmettre ses trames de données. Si le transmetteur envoie un
paquet quand le récepteur est endormi, il va provoquer le problème appelé “envoi sourd” (deaf
listening). Pour remédier à ce problème, le transmetteur doit envoyer avant chaque transmission un
paquet préambule qui ne contient que des bits 0 et 1 alternativement. Le but de ce paquet
préambule est d’alerter le récepteur qu’il a des données à recevoir et qu’il doit rester dans l’état
actif. La longueur de ce préambule doit être supérieure à la période d’échantillonnage pour pouvoir
signaler tous les récepteurs dans la portée. Cette technique déplace la consommation d’énergie du
côté transmetteur car il doit envoyer un paquet préambule avant chaque transmission.
T : Période d’échantillonnage
Préambule
Transmetteur
Récepteur
Données
T
Réveille et revient à endormi
lorsque le médium est libre
Reste actif en recevant le
préambule
Figure 2.6 - Technique préambule d’échantillonnage
19
La Figure 2.6 illustre le fonctionnement de cette technique "préambule d’échantillonnage” avec un
transmetteur et un récepteur. Le récepteur se réveille périodiquement après chaque période
d’échantillonnage T. Dans la Figure 2.6, lorsque le récepteur se réveille dans les deux premières
périodes, il trouve qu’il n’y a aucune activité dans le médium. Donc, il se met dans l’état endormi.
Le transmetteur commence sa transmission quand le récepteur est endormi. S’il transmet
directement les données, le récepteur ne va jamais recevoir ces données car il est dans l’état
endormi. Donc, le transmetteur commence sa transmission par un paquet préambule
d’échantillonnage. Lorsque le récepteur se réveille, il trouve que le médium est occupé (par le
paquet préambule), il sait qu’il y aura une transmission pour lui et reste actif pour recevoir
d’éventuelles trames de données. Après avoir signalé au récepteur sa transmission par le paquet
préambule, le transmetteur commence à transmettre ses trames de données en assurant que le
récepteur est actif pour recevoir ses données.
Dans un réseau de capteurs, les nœuds ne transmettent pas les données très souvent, surtout dans
les applications de type détection d’évènement où les capteurs envoient les données seulement
lorsqu’un évènement se produit. La technique préambule d’échantillonnage semble bien adaptée à
ce type de réseau pour réduire la consommation d’énergie. Le premier protocole d’accès au
médium pour les réseaux de capteurs utilisant la technique préambule d’échantillonnage a été
proposé par A. El-Hoiydi et Al en combinant avec Aloha sous le nom Aloha-PS [42]. Comme la
technique CSMA est plus avantageuse que Aloha en terme d’évitement de collision. A. El-Hoiydi
et Al ont proposé NP-CSMA-PS [43] qui est une version “écoute de porteuse CSMA non
persistant” avec préambule d’échantillonnage. Leurs résultats d’évaluation montrent que Aloha-PS
et NP-CSMA-PS donnent approximativement les mêmes performances en cas de trafic faible. Dans
le cas d’un trafic plus soutenu, NP-CSMA-PS est plus avantageux.
L’arrivé d’un paquet
Transmetteur
P
Données
attendre
Récepteur
T
Revient à endormi lorsque
le médium est libre
A
Reste actif en recevant
le préambule
Figure 2.7 - WiseMAC pour réduire le temps préambule
20
La combinaison de protocoles d’accès au médium Aloha ou CSMA avec la technique préambule
d’échantillonnage réduisent nettement le niveau de consommation d’énergie. S’il n’y a pas de
transmissions, les récepteurs ne consomment pas d’énergie entre les périodes d’échantillonnage.
Plus on élargit la période d’échantillonnage, plus les récepteurs peuvent économiser l’énergie. En
échange, les transmetteurs doivent envoyer un paquet préambule plus long ce qui augmente la
consommation d’énergie du côté transmetteur. De plus, le paquet préambule ne contient pas de
données utiles et c’est alors un gaspillage d’énergie.
Afin de réduire la consommation d’énergie globale, on doit donc trouver un moyen pour réduire le
temps d’envoi du paquet préambule. WiseMAC [44][45] améliore NP-CSMA-PS [43] en terme de
consommation d’énergie en réduisant la longueur d’un paquet préambule. Normalement, la
longueur d’un paquet préambule doit être supérieure à la longueur de la période d’échantillonnage
(pour que le transmetteur puisse signaler au récepteur une éventuelle transmission). Donc, s’il y a
une méthode efficace pour que le transmetteur sache le moment où le récepteur se réveille, il peut
se réveiller juste un peu avant ce moment sans envoyer un long paquet préambule. C’est la
méthode utilisée par WiseMAC. En effet, chaque nœud maintient une table contenant les périodes
d’échantillonnages de tous les voisins. Cette information n’est pas obtenue par un envoi explicite
de paquet SYNC comme dans les protocoles MAC synchronisés, mais par l’information
superposée (piggyback). L’information superposée est une information complémentaire ajoutée
dans les paquets de contrôle.
Dans WiseMAC, les transmissions sont suivies par des paquets d’acquittements afin de garantir
une bonne transmission entre les nœuds et permettre d’échanger les périodes échantillonnages (la
Figure 2.7). Au début, les nœuds transmettent des trames de données en utilisant un paquet
préambule de longueur normale (supérieure à la période d’échantillonnage). Ensuite, une fois que
la transmission est terminée, le récepteur renvoie un paquet d’acquittement. Ce paquet
d’acquittement signale au transmetteur qu’il a bien reçu les données. Mais, le récepteur ajoute aussi
dans son paquet d’acquittement une information supplémentaire qui est sa période
d’échantillonnage. Après avoir reçu le paquet d’acquittement, le transmetteur peut mettre à jour la
période d’échantillonnage du récepteur dans sa table des voisins. Pour la prochaine transmission, le
transmetteur connaîtra la période d’échantillonnage du récepteur, il transmettra juste avant le réveil
du récepteur. La Figure 2.7 illustre le fonctionnement de WiseMAC. A l’arrivée d’un paquet,
quand le transmetteur connaît déjà la période d’échantillonnage du récepteur, il n’envoie pas le
préambule toute de suite. Il attend et il envoie le préambule juste un peu avant le réveil du
récepteur. La transmission se termine par un paquet ACK envoyé par le récepteur pour signaler une
bonne réception des trames de données et annoncer sa période d’échantillonnage en même temps.
Dans le cas idéal, il suffit d’un échange de période d’échantillonnage pour que le transmetteur
sache exactement le moment où ses voisins se réveillent. Cependant, entre les dispositifs
électroniques, il y a toujours des décalages d’horloge. Ces derniers provoquent une erreur sur la
21
période d’échantillonnage des voisins. Après un certain temps écoulé, les informations sur la
période d’échantillonnage des voisins d’un nœud ne sont plus à jour. Le temps d’échantillonnage
d’un voisin dans la table d’un nœud n’est peut être plus son temps d’échantillonnage réel. Dans
WiseMAC, si le temps entre deux transmissions dépasse un certain seuil, le nœud revient à une
transmission avec préambule d’échantillonnage avec une longueur normale qui est supérieure à la
période d’échantillonnage.
Dans certains cas, WiseMAC offre de meilleures performances que S-MAC. Cependant, comme
les nœuds ne sont pas synchronisés, il est impossible de faire de la diffusion (broadcast). En plus,
WiseMAC n’utilise pas des paquets de contrôle et ne peut donc pas éviter le problème de la station
cachée.
Pour supprimer ces limitations, SCP-MAC [46] (Synchronized Channel Polling MAC) propose une
synchronisation entre les périodes d’échantillonnage des nœuds dans le réseau. Les nœuds se
synchronisent d’une manière passive en ajoutant ces informations dans les trames de données et
une manière active en envoyant des paquets SYNC s’ils ne sont pas synchronisés avec les voisins.
En plus, SCP-MAC peut s’adapter aux différents trafics du réseau. Quand le trafic est important,
SCP-MAC multiplie automatiquement le temps que les nœuds accèdent au canal afin d’augmenter
le débit et réduire la latence de transmission multi-saut.
Une autre contribution importante qui a été beaucoup publiée dans la pratique est B-MAC [47].
C’est un protocole MAC utilisé par les capteurs Mica [10]. B-MAC prend en compte des
conditions réelles du canal de communication. En condition réelle, le canal de communication est
toujours bruité. Cela est dû à des interférences avec plusieurs dispositifs sans fil : les routeurs sans
fil, les téléphones portables, ou les micro-ondes etc. Dans ces conditions, on trouve rarement le cas
où le canal de communication est complètement libre. Il faut évaluer le seuil où le canal est
considéré comme libre. Cela signifie que même si les nœuds détectent un signal dans le médium,
même très faible, les nœuds peuvent évaluer le canal comme s’il était libre. En effet, B-MAC
propose une opération dite “Evaluation de Canal Libre” (Clear Channel Assessment - CCA). C’est
une méthode d’évaluation du canal dans le cas réel du canal bruité. Si la puissance du signal reçu
est supérieure au seuil du canal bruité, on considère que le canal est occupé. Au contraire, même
s’il y a un signal dans le canal mais de puissance inférieure au seuil d’un canal bruité, on considère
que le canal est libre. D’une part, la technique CCA améliore l’exactitude des communications car
on prend en compte la condition réelle du canal de communication. Cette technique aide les nœuds
à économiser l’énergie car les nœuds peuvent éviter de se réveiller dans le cas d’un faux canal
occupé. Cependant, le débit de communication est inversement proportionnel au seuil de CCA. Si
le seuil est élevé, le débit de communication est réduit et vice-versa. En plus, B-MAC propose un
module qui permet de changer automatiquement ce seuil selon les conditions du canal de
communication. Pour recevoir la valeur de ce seuil, le signal du canal est échantillonné quand le
canal est considéré comme libre (Ex : juste après la réception d’un paquet). Cet échantillon est mis
22
dans une file de taille 10 et le seuil est obtenu par le médian de toutes les valeurs de seuil dans la
file.
A côté de la technique CCA, B-MAC utilise la même technique d’accès au médium Aloha avec
préambule d’échantillonnage. Les auteurs ont nommé cette technique "Ecoute à Faible Energie”
(Low Power Listening –LPL). Comme dans les techniques MAC avec préambule
d’échantillonnage, les nœuds se réveillent dans un court instant pour attendre éventuellement une
transmission. Ils appliquent CCA pour évaluer s’il y a des activités dans le canal. Si c’est le cas, ils
restent en écoute pour attendre la réception des trames de données. Sinon, ils retournent à l’état
endormi. Un avantage de plus de B-MAC par rapport aux autres protocoles MAC, est la facilité de
programmation. B-MAC fait partie de TinyOS [48], un système d’exploitation léger dédié aux
capteurs de petite taille comme Mica [10]. B-MAC est open-source et il offre des interfaces
simples pour faciliter le paramétrage de différentes valeurs comme la période d’échantillonnage.
Les protocoles MAC avec préambule d’échantillonnage que nous avons analysés utilisent le même
période d’échantillonnage que tous les nœuds dans le réseau. Cela est raisonnable pour un réseau
homogène où tous les nœuds jouent le même rôle et ont le même niveau d’énergie. Pourtant, dans
un réseau de capteurs, ce n’est pas toujours le cas. Les capteurs peuvent être hétérogènes en terme
de calcul, de niveau d’énergie etc. EA-ALPL [49] améliore B-MAC [47] en prenant en compte cet
aspect. En effet, il donne le choix de modifier la période d’échantillonnage à tous les nœuds dans le
réseau en fonction de leur état. Un nœud avec une période d’échantillonnage longue est moins
sollicité qu’un nœud avec un période d’échantillonnage court. Selon la topologie du réseau, si un
nœud a plus de fils, il doit faire suivre plus de paquets et de ce fait consomme plus énergie. Pour
réduire la charge de ce nœud, on choisit simplement une période d’échantillonnage plus longue
pour réduire la probabilité d’être sollicité à relayer les trames de données. En effet, les nœuds
échangent les informations de leur état avec les voisins. L’état d’un nœud est caractérisé par la
période d’échantillonnage, le niveau d’énergie restant et le routage. Les nœuds fils vont choisir les
voisins avec la période d’échantillonnage la plus courte, c’est-à-dire un voisin qui est prêt à faire
suivre des paquets.
c)
La norme IEEE 802.15.4
Nous venons de voir que la couche MAC joue un rôle très important dans le fonctionnement des
réseaux de capteurs. Plusieurs protocoles MAC ont été proposés dans la littérature et chacun a des
avantages et des inconvénients différents. Une nouvelle norme de réseau sans fil spécialisée pour
les réseaux de capteurs à faible consommation d’énergie fait son apparition en 2003. Elle se
nomme IEEE 802.15.4 [12] pour les réseaux sans fil à faible consommation, faible portée et faible
débit. Il s’agit de la couche physique et de la couche MAC pour les réseaux de capteurs sans fil.
Comme un réseau de capteurs se compose de plusieurs nœuds de faible portée, les nœuds ont
besoin de communication multi-saut pour transmettre des informations des nœuds vers la station de
23
base. Pour cette raison, le protocole Zigbee [50] a été proposé par une alliance de plusieurs grandes
entreprises. Zigbee est basé sur la norme IEEE 802.15.4 pour la couche physique et la couche
MAC. Il offre un routage multi-saut pour les nœuds dans le réseau et également des méthodes de
cryptage de données.
En effet, avec Zigbee, IEEE 802.15.4 offre trois types de topologie : étoile, arbre et maillé. La
topologie étoile permet seulement une communication à un saut. Pour une large zone de
déploiement, cette topologie n’est pas satisfaisante car la portée du transceiveur est limitée. La
topologie maillée permet les communications multi-saut pour un déploiement massif sur une large
zone. Cependant, les nœuds n’ont pas de méthodes pour économiser la consommation d’énergie.
Pour un réseau de capteurs avec une faible consommation d’énergie et des transmissions multisaut, nous nous basons sur la topologie "arbre".
La norme IEEE 802.15.4 propose un mode beacon pour économiser l’énergie sur les nœuds. Dans
un réseau, il y a un nœud coordinateur qui gère l’accès au médium de tous les nœuds. Comme SMAC [33], les nœuds se synchronisent pour travailler et dormir en même temps. Périodiquement, il
envoie un paquet beacon qui contient l’information de synchronisation pour signaler aux nœuds le
moment de se mettre dans l’état actif ou endormi. Le coordinateur peut modifier l’intervalle beacon
pour que les nœuds travaillent plus ou dorment plus selon le type d’application.
Intervalle beacon
B
CAP
B : Beacon
CFP
endormi
B
CAP : Contention Access Period
CAP
CFP
endormi
CFP : Contention Free Period
Figure 2.8 - Protocole MAC de IEEE 802.15.4 avec beacon
La Figure 2.8 illustre le fonctionnement du protocole MAC de la norme IEEE 802.15.4 avec
beacon. Grâce au paquet beacon, tous les nœuds sont en état actif pendant la période active. La
période active est composée de 16 slots de temps dont un est pour le paquet beacon. En effet, cette
période est divisée en deux parties : période d’accès en contention (CAP) et période sans
contention (CFP). La première période est réservée à des accès au canal en concurrence. Les nœuds
sont libres pour accéder au canal pendant cette période en utilisant CSMA/CA. Comme nous
l’avons vu dans la partie précédente, le CSMA/CA ne garantit pas une transmission fiable entre les
nœuds car il risque d’y avoir des collisions. En plus, les nœuds accèdent au canal aléatoirement et
nous ne pouvons pas assurer un accès au canal pour certains nœuds. Pour remédier à ce problème,
la norme IEEE 802.15.4 propose la période sans contention où le coordinateur attribue à certains
24
nœuds le privilège pour accéder au canal dans un intervalle de temps fixe. Pendant cette période, il
y a un seul nœud qui a le droit d’émettre et il n’y aura pas de collisions.
d)
MAC protocoles pour RdC orientés évènement
Les protocoles MAC que nous avons vu dans les parties précédentes avaient comme but principal
la réduction du temps actif du transceiveur afin de réduire la consommation d’énergie due à
l’écoute non-active. Ces propositions sont pour les réseaux de capteurs de type surveillance où la
latence n’est pas un problème critique. Cependant, pour les réseaux de capteurs orientés
évènement, la latence est un problème primordial et elle est plus importante que la consommation
d’énergie. Dans certaines d’applications (Ex : aéronautique, nucléaire, industriel etc.), nous
voulons avoir des informations sur les évènements avec le plus bref délai une fois qu’un évènement
critique se produit. Il n’existe pas beaucoup des travaux de recherche pour ce genre de protocoles
MAC.
SIFT [53] est le premier protocole MAC pour les réseaux de capteurs orientés évènement. En effet,
pour ce type de réseau de capteurs, quand un évènement se produit, plusieurs nœuds détectent les
informations similaires et veulent les envoyer à la station de base simultanément. La station de base
n’a pas besoin de toutes les informations envoyées par les nœuds pour pouvoir prendre une
décision. Le but de SIFT est de favoriser la transmission de R dans N paquets pour les évènements
(R < N).
Avant chaque transmission, les nœuds entrent dans la période de contention où chaque nœud
choisit un slot aléatoirement dans la fenêtre de contention. Le nœud qui choisit le premier slot
gagne le canal et commence sa transmission. Si plus de deux nœuds choisissent le premier slot en
même temps, ils commencent à transmettre en même temps et cela provoque une collision. Plus les
nœuds sont en contention, plus la probabilité de collision est élevée. Quand un évènement se
produit, il y a beaucoup de nœuds qui sont en contention pour transmettre des informations à la
station de base. Le risque de collision est de ce fait élevé. Les collisions impliquent une
retransmission du message avec un doublement de fenêtre de contention. Cela augmente le délai de
transmission et il faut du temps pour que la taille de la fenêtre de contention atteigne une bonne
valeur pour éviter des collisions.
Dans les méthodes d’accès au médium par écoute de porteuse, le choix du slot dans la fenêtre de
contention est uniforme ce qui explique un choix aléatoire du slot. Dans SIFT [53], les nœuds
choisissent les slots d’une manière non uniforme. Les auteurs ont défini une fonction pour que la
probabilité que les nœuds choisissent les slots petits soit plus faible que les slots grands. La Figure
2.9 illustre cette distribution de choix de slot avec la fonction pr. Le but est de réduire le nombre de
nœuds qui choisissent le même premier slot en même temps dans le cas d’un trafic élevé lorsqu’un
évènement se produit. Dans le cas d’écoute de porteuse, si le nombre de nœuds en contention est
élevé, la plupart des transmissions se termine par une collision. Dans SIFT, quand le nombre de
25
nœuds en contention est élevé, la probabilité que plusieurs nœuds choisissent le même premier slot
est toujours faible et nous pouvons garantir une faible probabilité de collision. De ce fait, SIFT
améliore la latence de transmission des paquets par rapport les méthodes écoute de porteuse
traditionnelles.
Figure 2.9 - Probabilité de choix de slot dans la fenêtre de contention CW = 32
En se basant sur le même principe d’une distribution non-uniforme de choix des slots dans la
fenêtre de contention, Y.C Tay et Al ont proposé CSMA/p [54]. Ils ont donné une analyse
mathématique de la probabilité de collision et prouvé que CSMA/p est plus avantageux en terme
d’évitement de collision. Ces deux propositions ont un objectif principal qui est de réduire la
latence pour un réseau de capteurs orientés évènement où la latence est le critère le plus important.
Cependant, ils ne traitent que les communications simples à un saut vers la station de base ce qui
n’est pas adaptable aux réseaux de capteurs où la transmission est très souvent de type multi-saut.
De plus, comme les capteurs sont très sensibles à la consommation d’énergie, il nécessite donc des
méthodes pour réduire la consommation d’énergie même si ce n’est pas le critère le plus important.
2.2
Protocoles MAC sans contention
Dans cette famille de protocoles MAC, les nœuds accèdent au canal sans concurrence. Chaque
nœud possède sa propre ressource pour accéder au canal et les autres nœuds ne peuvent pas utiliser
cette ressource. La ressource de chaque nœud peut être un intervalle de temps, une bande de
fréquence où un code. Les protocoles MAC sans contention sont divisés en trois catégories
principales : Accès multiple par répartition dans le temps (Time Division Multiple Access –
26
2.2 Protocoles MAC sans contention
TDMA), Accès multiple par répartition en fréquence (Frequency Division Multiple AccessFDMA) et Accès multiple par répartition en code (Code Division Multiple Access - CDMA). Nous
allons analyser ces trois catégories en détail dans la partie qui suit.
2.2.1 Accès multiple par répartition dans le temps (TDMA)
Dans ce type de protocole MAC, chaque nœud a un intervalle de temps où il peut accéder au canal.
Un nœud ne peut pas accéder au canal pendant l’intervalle de temps réservé à un autre. De ce fait,
il n’y a jamais de collision dans ce type de protocole MAC. Cependant, il faut toujours un ou
plusieurs nœuds coordinateurs qui attribuent les intervalles de temps aux autres. Pour que TDMA
puisse bien fonctionner, il faut un bon niveau de synchronisation entre les nœuds (quelques µs).
Quand la topologie du réseau change, il faut changer aussi les intervalles de temps attribués pour
les nœuds. A première vue, on peut dire que TDMA est bien adapté aux réseaux de capteurs en ce
qui concerne la consommation d’énergie car il n’y a pas du tout de collisions. Cependant,
l’attribution des intervalles de temps de TDMA est effectuée d’une manière statique. Si un nœud se
voit attribuer un intervalle de temps et qu’il n’a pas de données à transmettre, il ne peut pas laisser
cet intervalle de temps à quelqu’un d’autre. C’est aussi un gaspillage de bande passante et
d’énergie car le transceiveur continue à travailler dans cet intervalle de temps. D’ailleurs,
l’approche centralisée de TDMA semble moins adaptable aux réseaux de capteurs dynamiques où
nous voulons une gestion totalement distribuée pour un réseau à large échelle.
Une représentation de cette méthode d’accès au canal est Bluetooth [13]. Le but de Bluetooth est de
remplacer les câbles pour relier les périphériques : imprimantes, téléphone portable, oreillettes etc.
Il est conçu pour consommer moins d’énergie que IEEE 802.11. Cependant, Bluetooth ne permet
pas d’avoir une durée de vie de plusieurs années dans le cas d’un réseau de capteurs.
Comme nous l’avons vu dans la partie précédente, une des raisons de gaspillage d’énergie de
TDMA est l’attribution des intervalles de temps aux nœuds qui est fixe et le fait qu’un nœud ne
puisse pas utiliser un intervalle de temps d’un autre même si que ce dernier ne l’utilise pas. NAMA
[55] propose une attribution des intervalles de temps dynamique dans un rayon de deux sauts afin
d’éviter les problèmes de la station cachée. NAMA est une proposition pour les réseaux ad-hoc
dont le but principal est de maximiser le débit. TRAMA [56] réutilise l’idée d’attribution
dynamique des intervalles de temps de NAMA, mais il permet de réduire la consommation
d’énergie à cause d’écoute passive. En effet, le temps d’accès au canal est divisé en deux périodes :
une période d’accès basée sur la contention et une période d’accès sans contention. Dans la période
d’accès basée sur la contention, les nœuds échangent les adresses des voisins pour avoir une
topologie de tous les voisins situés à deux sauts. Dans la période d’accès sans contention, le temps
est divisé en plusieurs intervalles de temps. Un nœud calcule sa priorité pour chaque intervalle de
temps et il peut connaître les intervalles de temps où il a la plus haute priorité. Le niveau de priorité
pour un nœud dans un slot est calculé par une fonction de hachage basée sur l’identifiant du nœud
27
et de l’intervalle de temps. Donc, les intervalles de temps attribués pour un nœud changent
dynamiquement selon le trafic dans le réseau. Un nœud annonce les intervalles de temps qu’il
possède et les nœuds récepteurs dans un paquet ordonnancement. Les nœuds qui ne sont pas
récepteurs peuvent se mettre en veille pour économiser l’énergie pendant le temps de transmission
des autres. De ce fait, TRAMA évite les problèmes d’écoute passive. Cependant, la proportion
entre la période d’accès basée sur la contention et la période d’accès sans contention est fixe, ce qui
implique un cycle de travail assez important pour les capteurs. En plus, le calcul de hachage est
répété sur tous les capteurs pour chaque intervalle de temps, ce qui est préjudiciable par rapport à la
capacité de calcul des capteurs.
2.2.2 Accès multiple par répartition en fréquence (FDMA)
Dans ce type de protocole MAC, chaque nœud possède plusieurs bandes de fréquence différentes.
Un nœud connait la fréquence de ses voisins. Quand il veut transmettre des trames de données à un
de ses voisins, il choisit la fréquence de ce voisin pour transmettre. Les nœuds peuvent faire
plusieurs transmissions simultanément dans la portée des autres sans les interférer. Nous pouvons
imaginer ce type de protocole MAC comme le trafic sur une autoroute avec plusieurs voies dont
chacune représente une bande de fréquence. Les véhicules représentent les trames de données et
elles peuvent circuler chacune sur une voie sans perturber les autres. FDMA possède un gros
avantage car il peut fonctionner sans interférence et avec un débit important. En effet, chaque
transmission est réalisée sur une bande de fréquence différente. Cette technique est utilisée dans le
domaine du téléphone mobile où la taille des terminaux est assez importante et il n’y a pas trop de
contrainte de prix. Nous parlons du problème de prix des dispositifs terminaux car les capteurs sont
conçus pour un déploiement massif où le prix doit être le plus moins cher possible. FDMA requiert
une conception complexe de transceiveur avec des circuits complémentaires, ce qui augmente le
prix des dispositifs. De ce fait, FDMA n’est pas un bon candidat pour le protocole MAC des
réseaux de capteurs. Cela explique la raison pour laquelle il n’y a pas beaucoup de travaux sur le
protocole MAC de ce type pour les réseaux de capteurs. E. Shih et al [57] ont proposé un protocole
hybride entre TDMA et FDMA. Les auteurs ont prouvé que l’utilisation de TDMA ou FDMA pure
consomme plus d’énergie qu’un protocole hybride qui combine ces deux approches. Ils ont
également proposé une méthode pour déterminer le nombre de canaux optimaux de FDMA afin de
minimiser le niveau de consommation d’énergie. Pourtant, le problème principal de FDMA qui est
la complexité de la conception du transceiveur, reste toujours un problème non-résolu.
2.2.3 Accès multiple par répartition de code (CDMA)
Dans ce type de protocole MAC, les nœuds ont seulement une bande de fréquence pour faire les
transmissions. Ceci est pris comme une hypothèse des protocoles MAC basés sur la contention.
Dans les protocoles d’accès multiple par écoute de porteuse, quand plusieurs nœuds transmettent
en même temps dans la même portée, il y a une collision et le récepteur reçoit seulement un bruit.
28
2.2 Protocoles MAC sans contention
Ce n’est plus le cas dans CDMA où on considère que différentes trames de données peuvent se
chevaucher de façon linéaire. Ainsi, chaque nœud possède un code différent. Il diffuse son code à
ses voisins. Donc, un nœud garde aussi une liste des codes de tous ses voisins. Quand un nœud veut
transmettre une trame de données, il code sa trame de données avec son propre code et l’envoie au
récepteur. Plusieurs nœuds peuvent transmettre les données codées en même temps en utilisant leur
propre code. Les codes sont conçus d’une manière orthogonale pour que plusieurs trames de
données puissent se chevaucher sans perte de données. Le récepteur utilise le code de son
transmetteur pour recevoir les trames qui viennent du transmetteur. En utilisant le code de son
transmetteur, tous les bruits créés par les autres transmetteurs sont détruits et le récepteur peut
recevoir une bonne trame de données même si il y a des interférences.
Nous pouvons expliquer CDMA d’une manière plus simple. Supposons que dans une salle de
conférence, il y ait plusieurs groupes de personnes qui parlent différentes langues : français,
espagnole, chinois, vietnamien etc. qui représentent les “codes”. Tous les gens peuvent parler sans
interférer les autres car chacun a son propre “code”. Une personne prend les conversations des
autres comme bruit et ne traite que les conversations dans le même “code”. CDMA est avantageux
car les nœuds utilisent la même bande de fréquence, sans collision, sans problème d’interférence
avec une faible latence. Cette technique est beaucoup utilisée aux États-Unis dans le domaine des
téléphones mobiles. Cependant, la station de base est le seul nœud qui distribue les codes aux
autres dans le réseau. C’est donc une approche centralisée qui n’est pas adaptable aux réseaux de
capteurs.
Il n’existe pas beaucoup des travaux de recherche pour appliquer CDMA dans le domaine des
réseaux de capteurs. CSMAC (CDMA Sensor MAC) [58][59] est le travail le plus remarquable
basé sur CDMA. Comme un réseau de capteurs est un environnement complètement distribué, on
ne peut pas appliquer CDMA en tant que tel. En effet, CSMAC combine FDMA et CDMA (Figure
2.10). Les nœuds qui sont dans la même portée et qui peuvent interférer les autres utilisent chacun
une bande de fréquence différente. Les nœuds A, B, C, D E, F, G occupent des bandes de
fréquence f1, f2, f3, f4, f5, f6, f7 respectivement. Quand un nœud veut envoyer des trames de
données au nœud A, il choisit la fréquence f1 de A pour faire ses transmissions. C’est le cas de
FDMA. Cependant, si plusieurs nœuds envoient des trames de données en même temps au nœud A,
il y aura des collisions. Pour résoudre ce problème, à chaque lien dans le réseau est attribué un
code. Les liens BA, CA, DA, EA, FA, GA possèdent les codes PN1, PN2, PN3, PN4, PN5, PN6
respectivement. De ce fait, un nœud quelconque peut envoyer à A sans interférer sur les
communications des autres en appliquant la fréquence f1 de A et le code qui correspond à
l’identifiant du lien. Plusieurs communications peuvent ainsi être effectuées simultanément sans
interférence.
29
CSMAC est robuste par rapport au problème d’interférence. Il offre une transmission fiable avec
un taux de réception des paquets élevé et une latence faible. Cependant, il faut que les capteurs
soient dotés d’un transceiveur complexe avec plusieurs bandes de fréquence, le réseau doit être
immobile et il faut aussi un temps d’initialisation important.
B
f2
G
f7
PN6
PN5
F
f6
C
PN1
f1 PN2
A
PN4
f3
PN3 f4
D
f5
E
Figure 2.10 - Fonctionnement de CSMAC
2.3
Conclusion
Les réseaux de capteurs sans fil possèdent plusieurs caractéristiques différentes par rapport aux
réseaux sans fil traditionnels. Ces derniers sont conçus pour une utilisation par des êtres humains,
donc le critère de performance le plus important est le débit, la latence et l’équité de transmission.
Les autres critères comme la consommation d’énergie, le passage à l’échelle deviennent des
critères secondaires. Quand un utilisateur utilise un réseau local sans fil ou un réseau de téléphones
mobiles, il veut toujours être connecté au réseau à un grand débit et une faible latence. L’énergie
n’est pas un gros problème car il peut charger la batterie de son dispositif n’importe quand.
Contrairement aux réseaux sans fil traditionnels, les réseaux de capteurs sans fil sont conçus avec
un objectif différent. Ils n’ont pas besoin d’un grand débit de transmission mais ils ont besoin d’une
capacité de fonctionnement de manière autonome pendant une longue durée de temps. La
consommation d’énergie devient un problème majeur à prendre en compte. Plusieurs travaux de
recherche de la couche d’accès au médium ont été menés afin de réduire la consommation
d’énergie dans les réseaux de capteurs. L’idée principale est de réduire le temps non-actif, ce qui
30
2.3 Conclusion
est la source de gaspillage d’énergie la plus importante. Les protocoles MAC sont divisés en deux
familles principales : MAC basé sur la contention et MAC sans contention. Nous avons constaté
que les travaux de recherche sur la première famille sont beaucoup plus riches que la deuxième
famille. La raison est que la deuxième famille requiert soit une conception complexe de
transceiveur, soit une synchronisation stricte entre les capteurs. Ces conditions ne s’adaptent pas à
un environnement dynamique d’un réseau de capteurs sans fil à large échelle.
Concernant les techniques MAC économisant énergie, deux méthodes ont été présentées: des
protocoles MAC synchronisés et des protocoles MAC avec préambule d’échantillonnage. Chaque
type de protocoles possède des avantages et des inconvénients. Les protocoles MAC synchronisés
doivent échanger des paquets de contrôle afin de bien se synchroniser entre les nœuds voisins
tandis que les protocoles MAC avec préambule d’échantillonnage doivent transmettre un paquet
préambule avant chaque transmission. Pourtant, la synchronisation des protocoles MAC
synchronisés facilite les communications broadcast, et actualise la topologie du réseau. Nous
pensons que les protocoles MAC synchronisés sont plus avantageux que les protocoles MAC avec
préambule d’échantillonnage. Cela explique les propositions de recherche présentées dans la Partie
II où nous proposons un protocole MAC de type MAC synchronisé pour réduire encore la
consommation d’énergie par rapport aux propositions existantes. Dans la couche MAC, nous allons
présenter également un protocole MAC à faible latence de transmission pour les RdC orientés
évènement.
Nous avons discuté des différentes méthodes pour réduire le temps de transmission entre les
nœuds. Cependant, nous savons que les traitements locaux des données sont beaucoup moins
coûteux que les transmissions [32]. Dans certains scénarios, il est préférable de stocker les données
localement que d’envoyer périodiquement à la station de base. La méthode de stockage de données
joue donc un rôle important pour la consommation d’énergie et également pour la durée de vie
globale d’un réseau de capteurs. Dans le chapitre suivant, nous allons discuter des différentes
méthodes de stockage de données dans les réseaux de capteurs dans différents scénarios.
31
Chapitre 3.
Méthodes
de
stockage
de
données distribuées
Dans les chapitres précédents, nous avons montré que la consommation d’énergie était le critère le
plus important et qu’il influençait la durée de vie d’un réseau de capteurs de type surveillance. De
plus, nous avons constaté que le fonctionnement des transceiveurs était une activité coûteuse.
Donc, une idée évidente pour économiser énergie est de réduire le temps de fonctionnement du
transceiveur. La méthode d’optimisation de la couche MAC sert à activer et à mettre dans l’état
endormi le transceiveur périodiquement. Les capteurs envoient leurs mesures dans la période active
et s’endorment pendant l’autre période pour économiser l’énergie. Cependant, est-ce que toutes les
mesures envoyées par les capteurs sont utiles pour la station de base ? Dans certaines applications,
la réponse est non. Souvent, un utilisateur ne veut pas visualiser toutes les mesures de tous les
capteurs dans un réseau. Pour exemple, il peut poser une requête pour voir à quel moment, la
température sur une zone a dépassé 50°C. Dans ce cas, toutes les transmissions de température qui
sont inférieures à 50°C sont inutiles. Il vaut mieux ne pas transmettre ces mesures à la station de
base.
Comme un traitement local de données consomme beaucoup moins d’énergie qu’une transmission
de données [32], dans certains scénarios, il est préférable de stocker les données localement dans le
mémoire flash des capteurs plutôt que d’envoyer toutes les mesures à la station de base. Le mode
de stockage des données dans un réseau de capteurs peut beaucoup influencer le niveau de
consommation d’énergie. Dans 3.1, nous allons présenter quelques modèles de stockage de
données. Ensuite, nous analyserons quelques travaux de recherche dans le domaine du stockage de
données data-centric dans 3.2 . Enfin, nous concluons ce chapitre.
3.1
Modèles de stockage de données dans les réseaux
de capteurs
Le mode de fonctionnement d’un réseau de capteurs dépend beaucoup de l’application. Chaque
type d’application des réseaux de capteurs utilise un modèle de stockage de données différent.
Dans cette partie, nous allons analyser quelques modèles de stockage de données. Nous allons voir
également les cas ou un modèle est plus avantageux que les autres afin de mieux s’adapter aux
différents types d’application.
33
Chapitre 3. Méthodes de stockage de données distribuées
Paramètre
Valeur
Nombre de nœuds
N
Nombre d’évènements détectés
Dtotal
Nombre de requêtes
Q
Nombre d’évènements
demandés
Dq
Tableau 3.1 - Paramètres du réseau
Le stockage de données dans les réseaux de capteurs est classé en trois modèles différents :
stockage externe, stockage local et stockage data-centric[70][71]. Pour mieux illustrer le coût de
communication entre ces trois modèles, nous prenons un réseau de N capteurs déployés d’une
manière uniforme sur un rectangle. On suppose que la station de base se situe au coin de la zone de
déploiement. Dtotal est le nombre total d’évènements détectés par les capteurs. Q est le nombre de
requêtes réalisées par la station de base. Dq est le nombre d’évènements détectés pour Q requêtes.
Ces valeurs sont illustrées dans le Tableau 3.1. Nous utilisons ces paramètres tout le long de cette
partie afin de comparer la performance des différents modèles de stockage de données.
requête
donnée
a) Stockage externe
b) Stockage local
Figure 3.1 - Modèles de stockage de données
Le modèle de stockage externe est le modèle le plus utilisé dans les réseaux de capteurs. Cela est
aussi le modèle que nous avons présenté dans l’architecture générale d’un réseau de capteurs
34
3.1 Modèles de stockage de données dans les réseaux de capteurs
(Figure 1.1). Les capteurs envoient toutes leurs mesures à la station de base et ses mesures sont
traitées complètement sur la station de base (Figure 3.1a). Comme la zone de déploiement est fixée
dans un rectangle avec N nœuds, le coût d’envoi d’une mesure à la station de base est à O( N ) .
Avec Dtotal évènements détectés par des capteurs, le coût de transmission total est Dtotal N . Si Dq ~
Dtotal , cela signifie que tous les évènements détectés par les capteurs sont utilisés par la station de
base, ce modèle de stockage offre de bonnes performances. Par contre, dans certaines applications,
les requêtes sur la station de base ne donnent pas l’intégralité des évènements envoyés par les
capteurs (Dq < Dtotal). Dans ce cas, une partie des évènements envoyés à la station de base est
inutile et cela est un gaspillage d’énergie. Le nombre de transmissions inutiles est (Dtotal − Dq ) N .
Dans le cas extrême, s’il n’y a aucune requête sur la station de base ou aucune réponse à la requête,
toutes les transmissions par les capteurs sont inutiles.
Dans un réseau de capteurs, les nœuds sont normalement homogènes avec la même capacité de
calcul, de stockage et d’énergie. Dans le modèle de stockage externe, tous les nœuds envoient leurs
mesures à la station de base. Comme la zone de déploiement est étendue, il faut des
communications multi-saut pour router les informations des nœuds jusqu’à la station de base. De ce
fait, les nœuds qui se situent plus proches de la station de base doivent faire deux tâches en même
temps : surveiller des évènements et router les messages pour les autres. Plus un nœud est proche
de la station de base, plus il doit router des messages pour les autres. Donc, les nœuds qui sont à
côté de la station de base épuisent leur énergie plus rapidement que les nœuds éloignés. Une fois
que les nœuds à côté de la station de base épuisent leur énergie, ils ne peuvent plus router les
messages pour les autres, le réseau de capteurs n’est plus opérationnel. Même si les autres nœuds
dans le réseau ont toujours beaucoup d’énergie, la station de base n’a aucun moyen de récupérer les
mesures sur le réseau de capteurs. Donc, ce modèle de stockage de données souffre d’un gros
inconvénient qui est l’absence d’équilibrage de charge. Les nœuds ne travaillent pas sous la même
charge et la durée de vie du réseau n’est pas optimisée. Dans un réseau de capteurs, le nœud qui
travaille le plus est appelé un hotspot. Dans ce modèle, le hotspot est le nœud qui se trouve juste à
côté de la station de base. Il route tous les paquets envoyés par les autres nœuds dans le réseau.
Donc, la charge du hotspot est Dtotal.
Le modèle de stockage local fonctionne d’une manière différente. Les capteurs n’envoient pas
leurs mesures à la station de base périodiquement. Toutes les mesures sont stockées localement sur
les capteurs (Figure 3.1b). Les nœuds peuvent éviter de transmettre les mesures qui n’intéressent
pas les utilisateurs. En effet, les capteurs envoient leurs mesures seulement quand ils reçoivent une
requête sur les mesures qu’ils possèdent. S’il n’y a aucune requête sur les mesures des capteurs,
ceux-ci économisent bien l’énergie car ils ne doivent envoyer aucune donnée. Cependant, quand un
utilisateur pose une requête aux capteurs, il ne sait pas quels capteurs possèdent un éventuel
évènement en réponse sa requête. Donc, cette requête doit être envoyée vers tous les nœuds dans le
35
réseau. Cette diffusion de messages dans le réseau coûte cher s’il y a beaucoup de requêtes.
Lorsque les capteurs reçoivent l’une d’elles, ils traitent cette requête localement et répondent
seulement si ils ont des données appropriées. Dans la Figure 3.1b, deux nœuds seulement ont des
données appropriées et ils sont les seuls à renvoyer la réponse à la station de base. Avec Q
requêtes, le coût de diffusion des requêtes revient à Q*N. Dq est le nombre d’évènements
correspondant à Q requêtes, le coût de réponse est Dq N . Le coût de transmission total pour ce
modèle est donc QN + Dq N . On peut facilement voir que ce modèle n’est plus intéressant si le
nombre de requêtes Q et le nombre de nœuds N sont importants car la diffusion de paquets de
requêtes dans tout le réseau devient coûteuse. Ce modèle est plus adapté au cas où il y a peu de
requêtes dans le réseau. Comme dans le modèle de stockage de données externe, les nœuds qui se
trouvent à côté de la station de base doivent travailler plus que les nœuds qui se trouvent loin de la
station de base. Donc, le nœud qui se trouve à côté la station de base est le hotspot du réseau. Il
reçoit Q requêtes et Dq réponses de la part du réseau, donc la charge du hotspot est Q+Dq. De
même, si le nombre de requêtes est important, la charge du hotspot devient très élevée.
Les modèles de stockage de données externe et local offrent des avantages et des inconvénients
différents. Pourtant, ces deux modèles subissent le même inconvénient qui est l’absence
d’équilibrage de charge. Il faut trouver un autre modèle qui garantisse un nombre de
communications minimal et aussi réaliser l’équilibrage de charge. Le modèle de stockage datacentric répond à ces caractéristiques. Nous allons analyser plus en détails ce modèle de stockage de
données dans la partie suivante.
3.2
Stockage de données data-centric
Dans les réseaux traditionnels, la relation entre le nœud transmetteur et le nœud récepteur est très
forte. Un nœud récepteur doit absolument connaître l’identifiant du nœud transmetteur afin de
traiter les données envoyées par le nœud transmetteur. Par contre, dans certains scénarios
concernant les réseaux de capteurs, nous nous intéressons seulement aux informations envoyées par
les capteurs mais pas à l’identifiant de ces capteurs. Par exemple, un réseau de capteurs est déployé
dans une forêt pour détecter le feu. Quand il y a un feu qui vient d’une zone forestière, les capteurs
dans cette zone vont détecter un évènement et l’envoyer à la station de base. Sur la station de base,
on ne s’intéresse pas à l’identifiant des nœuds qui ont transmis les évènements. Ce qui nous
intéresse c’est la zone où le feu s’est déclaré. Le fait que nous nous intéressions seulement aux
données envoyées par les nœuds mais pas à leur identifiant est appelé data-centric. L’information
est centrée sur les données.
36
3.2 Stockage de données data-centric
3.2.1 Les paradigmes data-centric
Les travaux de recherche dans le domaine data-centric comprennent 3 paradigmes [5]: routage
data-centric, agrégation data-centric et stockage data-centric. Dans ces trois paradigmes, les
données sont au centre du protocole.
Le premier paradigme, routage data-centric, concerne la méthode pour distribuer un type de
données dans un réseau pour que les nœuds qui sont intéressés par ces données puissent les
récupérer. SPIN [60], le premier protocole de ce paradigme, a été proposé par les chercheurs du
MIT. SPIN est conçu pour un réseau où un ou plusieurs nœuds veulent diffuser leurs données dans
le réseau. La taille des données envoyées par des nœuds est importante et provoque une inondation
dans le réseau. En effet, plusieurs nœuds diffusent des données redondantes. En plus, il y a des
possibilités de boucles de routage. Dans SPIN, les nœuds envoient seulement un petit paquet
d’information qui décrit les données. Quand un nœud reçoit ce paquet, si ce type de données
l’intéresse, il va renvoyer une requête pour recevoir la donnée entière. Ensuite, il continue à
diffuser le paquet de publicité. En utilisant SPIN, les nœuds peuvent éviter d’envoyer les données
qui n’intéressent pas les autres. Dans le protocole SPIN [60], les nœuds qui possèdent les données
prennent l’initiative de faire la publicité pour ces données. Un autre cas où les nœuds diffusent leur
intérêt est présenté dans Diffusion Directe (Directed Diffusion) [61]. Les nœuds utilisent un
routage intelligent afin de diffuser leurs données favorites et de retrouver ces données d’une
manière efficace. Nous pouvons constater que dans ce paradigme, le centre du routage est le
contenu de données situées sur les capteurs mais pas l’identifiant de ces capteurs. Pourtant, quand
un nœud trouve des données, il va récupérer la totalité de ces données et faire les traitements de ces
données localement. A l’intérieur du réseau de capteurs, les données peuvent être traitées au fur et à
mesure le long du chemin de transmission vers la station de base.
Dans le deuxième paradigme, appelé agrégation data-centric, l’agrégation de données est une
opération simple (min, max, etc.) dont le but est de réduire le nombre de transmissions dans le
réseau. Par exemple, nous voulons juste la valeur de la température maximale. Dans l’architecture
générique d’un réseau de capteurs, tous les nœuds envoient leur mesure de température. Sur la
station de base, l’utilisateur choisit la température maximale. Dans ce paradigme, au cours de la
transmission des différents nœuds vers la station de base, un nœud fait la comparaison de
différentes valeurs de température et fait suivre juste la valeur maximale. Les avantages de ce
paradigme sont bien illustrés dans [62].
Le stockage data-centric est le dernier paradigme de la famille des travaux sur le data-centric. Nous
allons le détailler dans le paragraphe suivant.
37
3.2.2 Stockage data-centric
L’idée de stockage data-centric consiste à distribuer les données d’une manière uniforme sur le
réseau. Plus précisément, chaque nœud dans le réseau stocke un type de donnée appropriée. Cette
idée reprend le paradigme de stockage de données structurées dans les réseaux pair-à-pair. Ce
dernier est un domaine de recherche intense depuis ces dernières années [63]. Au début, le réseau
pair-à-pair se base sur une architecture d’indexation centralisée où l’identifiant de toutes les
données dans le réseau est stocké sur un serveur central. Avec la croissance de l’Internet, cette
approche n’est plus efficace à cause du nombre gigantesque de données à partager. Cela nécessite
donc un système complètement distribué et passant à l’échelle pour partager des données dans le
réseau pair-à-pair afin de distribuer la charge sur tous les nœuds. Un deuxième type de réseau paira-pair a été proposé sous le nom “réseau pair-à-pair structuré”. Ce type de réseau garantit un
partage de la charge d’une manière uniforme sur tous les nœuds dans le réseau. Les nœuds utilisent
une table de hachage [64] pour distribuer les données uniformément. En donnant une liste de
valeurs quelconque à l’entrée, une table de hachage donne une distribution uniforme des données
sur un intervalle de valeurs. En appliquant la table de hachage, chaque nœud est responsable d’une
partie de données globale et la charge globale est distribuée à tous les nœuds dans le réseau. De
nombreux travaux de recherche ont été menés pour les réseaux pair-à-pair structurés
[65][66][67][68][69] car ils ont beaucoup d’avantages par rapport aux réseaux pair-à-pair
centralisés.
Comme nous l’avons vu dans la partie précédente, les modèles de stockage de données externe et
local souffrent d’un inconvénient important lié à l’équilibrage de la charge. Cet inconvénient
empêche les réseaux de capteurs utilisant ces deux modèles de stockage de passer à grande échelle.
Vu que le réseau pair-à-pair structuré offre un partage de données d’une manière uniforme et un
équilibrage de charge, il est intéressant d’appliquer ce modèle de stockage de données au réseau de
capteurs sans fil. Ces travaux ouvrent un nouveau domaine de recherche "stockage data-centric".
En effet, c’est un domaine de recherche très récent et il n’y a pas beaucoup de travaux existants.
a)
Table de hachage distribuée
Les réseaux pair-à-pair structurés utilisent les techniques de table de hachage distribuée afin de
bien répartir la charge sur tous les nœuds. Une table de hachage distribuée fournit deux opérations
de base :
•
Déposer(clé, valeur) : Cette fonction stocke une valeur dans un nœud qui correspond à la clé
(la valeur de hachage de la donnée)
•
Récupérer(clé) : Cette fonction récupère toutes les données qui ont été stockées pour la clé
38
Dans un réseau pair-à-pair structuré, l’identifiant des nœuds et les données sont hachés sur un
espace logique. L’identifiant logique d’un nœud est obtenu par un hachage de son adresse IP.
Ainsi, un nœud a une adresse IP et une adresse logique sur l’espace logique du réseau. La fonction
de hachage garantit une distribution uniforme des identifiants et des données sur l’espace logique.
Un nœud va stocker toutes les données qui se trouvent dans son espace logique.
Nœud 3:
65.88.75.12
Nœud 1 :
192.168.72.14
Nœud 5 :
187.43.89.14
Déposer(5, "élephant")
Nœud 2 :
57.88.14.65
Récupérer(5)
Nœud 6 :
123.134.0.14
Déposer(5, "élephant")
Hacher("éléphant") = 5
Nœud 4:
112.34.56.65
Figure 3.2 - Réseau pair-à-pair utilisant la table de hachage distribuée
La Figure 3.2 illustre le stockage et la récupération de données dans un réseau pair-à-pair structuré
utilisant une table de hachage distribuée. Comme la fonction de hachage distribue les données
uniformément sur un espace logique, les valeurs de hachage des adresses IP rendent les adresses
logiques des capteurs uniformément sur l’espace logique. Supposons qu’il y ait 6 nœuds dans le
réseau. Hache (192.168.72.14) = 1. Cela explicite l’identifiant du nœud 1.
Chaque nœud a une adresse logique dans le réseau. Lorsque les nœuds captent un nouvel
évènement (l’arrivé d’un éléphant, par exemple), il hache la valeur de l’éléphant. Supposons que la
clé= hache("éléphant")=5. Ce nœud utilise la fonction déposer(clé, valeur) afin de stocker
l’évènement "éléphant" sur le nœud 5. Cette fonction va envoyer les données concernant les
éléphants sur le nœud 5 qui est responsable de toutes les données dont le hachage est égal à 5. La
même procédure de stockage est valable pour le nœud 2 lorsqu’il veut stocker un évènement
"éléphant". Pour la recherche, le nœud 6 cherche des nœuds qui ont vu un "éléphant", il hache la
39
valeur de “éléphant” et il obtient la valeur 5. Ainsi, il sait que le nœud 5 qui stocke la liste de tous
les nœuds qui ont vu les "éléphants” et il va venir poser la requête au nœud 5. Le nœud 5 renvoie le
résultat au nœud 6. Nous pouvons constater que le nœud 5 devient le nœud rendez-vous de toutes
les données concernant les “éléphant”.
Dans un réseau filaire, deux nœuds avec deux adresses IP dans n’importe quelle position dans le
monde peuvent dialoguer. Par contre, dans un réseau sans fil, seulement les nœuds qui se trouvent
dans la portée peuvent dialoguer. Ainsi, la position géographique des nœuds joue un rôle important
pour le routage des données. Afin d’appliquer la table de hachage distribuée dans un réseau de
capteurs sans fil, il faut donc faire des modifications sur la méthode de routage et de stockage
d’information.
b)
GHT – Geographic Hash Table
A ce jour, le travail le plus remarquable réalisé dans le domaine du stockage data-centric est GHT
(Geographic Hash Table) [70][71]. C’est une méthode de stockage de données distribuée datacentric pours les réseaux de capteurs. Comme il n’est pas possible d’utiliser la méthode de routage
du réseau filaire, GHT utilise un autre protocole de routage GPSR (Greedy Perimeter Stateless
Routing) [72]. Ce protocole de routage est basé sur la position géographique des nœuds. En effet,
dans un réseau de capteurs, les nœuds peuvent avoir des informations de leur localisation dans le
réseau en utilisant des supports de services [73][74][75] (Ex : GPS etc).
GPSR- Greedy Perimeter Stateless Routing
Dans les protocoles de routage filaire, les nœuds sont identifiés par leur adresse IP. Le routage est
basé sur ces adresses IP. Dans les réseaux sans fil, chaque nœud a une position géographique
différente dans le réseau et nous pouvons profiter de cette information comme identifiant du nœud.
C’est la base de GPSR où les nœuds sont représentés par leur position dans le réseau. Le routage
n’est plus un routage entre deux adresses IP mais un routage entre deux positions de deux nœuds
dans le réseau.
Le protocole de routage de GPSR se compose de deux parties : routage glouton (greedy
forwarding) et routage par périmètre (perimeter forwarding). L’idée de routage glouton est simple :
un nœud fait suivre les données à un voisin qui se trouve le plus près de la destination. En répétant
ce processus, les données approchent de plus en plus de la destination. La Figure 3.3 illustre un
exemple de routage de données de nœud S vers le nœud D. Les cercles sont les portées radios des
nœuds S, X, Y et Z. Lorsque S reçoit une donnée destinée à D, il cherche les voisins qui se
trouvent dans sa portée et celui qui est le plus proche du nœud D. Donc, S fait suivre la donnée à X.
A son tour, X cherche le nœud voisin le plus proche de D et fait suivre la donnée. La donnée
parcourt un chemin S→X→Y→Z→D. Nous voyons qu’après chaque étape de routage, la donnée
40
s’approche de la destination. D’autre part, le routage est basé seulement sur la position
géographique du nœud mais pas sur l’adresse IP du nœud.
S
X
Z
D
Y
Figure 3.3 - Exemple de GPSR
Dans GPSR [72], un nœud doit connaître la position de ses voisins afin de déterminer la position
du nœud le plus proche de la destination. Pour cela, les nœuds échangent périodiquement des
paquets contenant leur identifiant et leur position dans le réseau. Chaque nœud garde une table de
toutes les positions de ses voisins afin de les utiliser pour le routage des données. Si après un
certain temps, un nœud ne reçoit pas ce paquet d’un voisin, il considère que celui-ci s’est déplacé
hors de sa portée ou que ce voisin est tombé en panne. Dans ce cas, il enlève ce voisin de sa liste de
voisins. Nous pouvons constater qu’un nœud n’a besoin que des positions de ses voisins pour son
routage. Donc, même si la taille du réseau est grande, la taille de sa table de routage n’augmente
pas. Ce protocole est de ce fait capable de passage à l’échelle.
Pour la topologie illustrée dans la Figure 3.3, le routage glouton offre un bon compromis par
rapport à des protocoles de routage traditionnels qui doivent stocker une grande table de routage ou
inonder inutilement le réseau avec des messages de recherche des chemins. Cependant, le routage
glouton provoque une erreur lorsqu’un nœud ne peut pas trouver le voisin le plus proche de la
destination car il est déjà lui-même le nœud le plus proche de la destination. La Figure 3.4a illustre
ce problème où S veut envoyer un message à D. Parmi les voisins de S, il n’y a aucun voisin qui est
plus proche de D que le nœud S. Dans ce cas, S doit appliquer un autre protocole de routage afin de
sortir de ce problème.
Examinons maintenant la deuxième partie du protocole appelé routage par périmètre. Cette
technique applique la règle de la main droite pour son routage. Supposons que nous ayons trois
41
nœuds A, B et C (Figure 3.4b). Lorsqu’un nœud reçoit un message venant de son voisin, il doit
faire suivre à un autre nœud qui se trouve dans le sens inverse des aiguilles d’une montre par
rapport au lien précédent. Par exemple, le nœud A qui reçoit un paquet de C. A va faire suivre de
paquet à B car B est le nœud qui se trouve en premier dans le sens inverse des aiguilles d’une
montre du lien AC. Ce processus se répète et le paquet est routé autour d’une zone fermée ABC.
Prenant la règle de la main droite pour le cas de routage dans la Figure 3.4a, le capteur S reçoit un
paquet pour router vers le nœud D. S ne peut pas appliquer le routage glouton car il est le nœud le
plus proche de D. Donc, il applique le routage périmètre avec la règle de la main droite. Il prend le
lien SD comme repère pour réaliser la règle de la main droite. Le nœud S va choisir le premier
nœud dans la liste de ses voisins qui se trouve à droite du lien SD. Dans ce cas, S fait suivre le
paquet à X, même si le nœud X est plus loin de la destination. Une fois que le paquet arrive à X, si
X trouve un voisin plus proche de D, il retourne au routage glouton. Sinon, il continue en mode
routage par périmètre en prenant en compte le lien XD comme le repère pour la règle de la main
droite. Dans le scénario de la Figure 3.4a, le nœud X retourne en mode routage glouton et fait
suivre le paquet à Y. A son tour, Y envoie le paquet à D.
D
A
B
V
Y
C
X
U
S
a)
b)
Figure 3.4 - Erreur de routage et la règle de la main droite
Table de hachage distribuée sur GPSR
Comme nous l’avons présenté dans la partie précédente, dans la table de hachage distribuée,
l’adresse IP et les données partagées sont projetées sur un espace logique. De ce fait, les données
sont distribuées uniformément sur tous les nœuds. Dans un réseau de capteurs sans fil, le routage
dépend de la localisation des capteurs dans le réseau et on ne peut pas projeter l’adresse des nœuds
sur un espace logique. GHT [70][71] utilise une table de hachage distribuée basée sur le routage
GPSR. Au lieu d’utiliser un espace logique, comme dans le cas de table de hachage distribuée dans
les réseaux pair-à-pair, GHT utilise l’espace réel qui est la zone de déploiement des capteurs. Les
42
nœuds sont identifiés par leur position dans le réseau. Lorsqu’un nœud a des données à partager, il
applique la fonction de hachage sur la donnée qu’il veut partager. La fonction de hachage retourne
une position dans l’espace de déploiement réel de capteurs et le nœud qui se trouve dans cette
position devient le nœud responsable de cette donnée. Les procédures de stockage et de
récupération de données ressemblent à la table de hachage distribuée dans les réseaux pair-à-pair.
Dans GHT, chaque nœud a une position dans le réseau et il est responsable de données dont la
valeur de hachage est identique à sa position. Cependant, que va-t-il se passer si la valeur de
hachage d’une donnée ne correspond à aucun nœud dans le réseau ? C’est une supposition réelle
car le nombre de nœuds dans le réseau est limité et la probabilité que la valeur de hachage d’une
donnée ne corresponde pas à la position d’un nœud est élevée.
Y
100
Hacher("éléphant") = (80, 80)
Nœud 3 : (80, 80)
Hacher("souris") = (50, 40)
Nœud 1 : (20,70)
Déposer("80,80", "élephant")
?
Récupérer("80, 80")
Récupérer("50,40")
Déposer("50,40", "souris")
Nœud 2 : (40, 30)
0
Nœud 4 : (85, 35)
100
X
Figure 3.5 - Stockage de donnée de GHT basant sur GPSR
La Figure 3.5 illustre un stockage de données en utilisant GHT. La fonction de hachage retourne
une position dans le réseau. Supposons qu’il y ait 4 nœuds qui soient déployés sur une zone de
taille 100x100. En utilisant un dispositif de localisation, les nœuds connaissent leur position dans le
réseau. Quand le nœud 1 détecte un évènement “éléphant”, il hache la valeur de cet évènement. Clé
= hacher("éléphant") = (80, 80). En utilisant le routage GPSR, le nœud 1 va router la donnée
43
jusqu’à la position (80, 80) dans la zone de déploiement. Cette position correspond au nœud 3 et ce
dernier devient le responsable de tous les évènements "éléphant". Le nœud 1 utilise la fonction
Déposer("80,80", "éléphant") afin de stocker cet évènement sur le nœud 3. La récupération de
donnée est faite de la même manière. Lorsque le nœud 4 veut chercher les évènements "éléphant",
il hache la valeur de "éléphant”et va récupérer les évènements sur le nœud 3.
Le problème survient lorsque le nœud 2 détecte un évènement "souris". D’ici, la fonction de
hachage retourne une valeur de la clé = hacher("souris") = ( 50, 40). Le nœud 2 utilise la fonction
Déposer(“50,40”, “souris”) en espérant stocker son évènement sur un nœud qui se trouve à la
position (50, 40). Mais, lorsqu’il n’y a pas de nœud dans cette position, ce stockage retourne une
erreur car le nœud 2 ne sait pas sur quel nœud il va stocker son évènement “souris”. Le même
problème survient lorsque le nœud 4 veut chercher les évènements “souris” dans le réseau. Il ne
peut pas en trouver car il n’y a aucun nœud à la position (50,40).
B
home perimeter
home node
A
Y
C
X
Poser(Y)
D
replica
Figure 3.6 - Nœud “ home node” et “ home perimeter” dans GHT
Pour remédier à ce problème, GHT modifie légèrement le protocole de routage de GPSR. Au lieu
de router le message directement au nœud qui se trouve à une position donnée, GPSR route le
message vers un nœud qui est le plus proche de cette position. Le nœud qui se trouve le plus proche
de cette position est appelé “home node”. Cependant, en utilisant GPSR, nous ne pouvons pas
savoir directement si un nœud est bien le nœud le plus proche d’une destination car le routage de
GPSR est conçu avec un routage qui a besoin de l’adresse exacte du nœud destinataire. Lorsqu’un
paquet arrive à un “home node” d’une position, ce nœud continue à chercher un nœud à la position
destinataire. Comme il ne trouve pas le nœud dans cette position, il croit qu’il en est loin et espère
qu’il y aura des autres chemins vers cette position. Donc, il change le mode de routage glouton au
mode de routage par périmètre. Comme le “home node” est le nœud le plus proche de la position
44
donnée, le routage en mode périmètre s’éloigne de la position donnée et retourne toujours vers le
“home node” après avoir traversé un périmètre que l’on appelle “home perimeter”.
Pour illustrer le choix de “home node” et le “home perimeter”, supposons que le nœud X veuille
stocker une donnée sur la position Y (Figure 3.6). Il y a 4 nœuds qui se trouvent autour de la
position Y. En utilisant le routage glouton, le nœud X envoie le paquet à A. Le nœud A ne peut pas
envoyer à Y car il n’y a aucun nœud qui se trouve à cette position. A cet instant, A est le nœud le
plus proche de Y. Donc, le nœud A change son mode de routage en routage par périmètre en
appliquant la règle de la main droite. Le nœud A fait suivre le paquet à B même si B est plus loin
que A par rapport à la position Y. A son tour, le nœud B retourne au routage glouton car il trouve
son voisin C qui est plus proche de Y. C continue à faire suivre le paquet à D et D continue à faire
suivre le paquet à A. Lorsque A reçoit le paquet, il sait que c’est le même paquet qu’il a fait suivre
auparavant. Alors, il sait qu’il est le nœud le plus proche de la position et devient le “home node”
de la position Y. Le parcours que le paquet a fait avant de revenir au nœud “home node” est appelé
le “home perimeter”.
Dans un réseau de capteurs, les nœuds sont susceptibles d’être mobiles ou tomber en panne à tout
moment ce qui modifie la topologie du réseau. Donc, le “home node” pour une position doit être
mis à jour s’il se déplace ou tombe en panne. Cela nécessite d’autres méthodes afin d’actualiser le
“home node” et le “home perimeter” et garantir la consistance du réseau. Dans GHT, le “home
node” envoie périodiquement un paquet de rafraichissement afin de vérifier s’il est toujours le
“home node” pour une position. En effet, lorsqu’un paquet parcourt un “home perimeter”, il
réplique la donnée sur tous les nœuds dans le périmètre. Si le “home node” a tombé en panne ou
s’il s’est déplacé, il y a toujours un autre nœud qui garde une copie de la donnée perdue et prend en
charge la responsabilité de la position donnée comme un nouveau “home node”.
Nous venons d’analyser le fonctionnement de GHT : le routage, le stockage et la récupération de
données. Maintenant, il faut voir dans quel cas le stockage data-centric de GHT est plus avantageux
que les deux méthodes de stockage de données qu’on a vues dans la partie précédente: stockage
externe et stockage local. Afin de faire la comparaison, nous reprenons les mêmes hypothèses pour
les calculs de coût de transmission présentées dans le Tableau 3.1. Le coût de transmission total se
compose des requêtes, des transmissions de stockage pour tous les évènements et des à ces
requêtes. Le coût de transmission total de GHT est Q N + Dtotal N + Dq N . Avec cette méthode
de GHT, si on ajoute une autre option d’agrégation de données, le coût de transmission total va
être réduit. En effet, la fonction d’agrégation de données peut être appliquée sur le nœud de
stockage des évènements.
Revenons à la Figure 3.5, le nœud 3 stocke tous les évènements “éléphant”. Si un nœud lui pose
une requête concernant les éléphants trouvés dans le réseau, il va renvoyer une liste de tous les
évènements “éléphant” trouvés dans le réseau. Par contre, si un nœud pose une requête sur le
45
nombre d’éléphants trouvés ou le plus grand éléphant trouvé, le nœud 3 peut agréger les données et
renvoyer seulement une réponse pour chaque requête. De ce fait, le coût de transmission se
compose des requêtes, des transmissions de stockage pour tous les évènements et des réponses
agrégées pour les requêtes. Donc, le coût de transmission total de GHT avec agrégation est
Q N + Dtotal N + Q N . En terme de charge sur les nœuds, étant donné que le hotspot est la
charge la plus élevée sur le réseau, c’est toujours le nœud qui se trouve à côté de la station de base
qui doit travailler le plus et est le hotspot du réseau. Pour GHT, ce nœud reçoit Q requêtes de la
station de base et Dq réponses pour ces requêtes. Le hotspot dans ce cas est Q+Dq. Pour GHT avec
agrégation, ce nœud reçoit Q requêtes de la station de base et Q réponses agrégées. Le hotspot dans
ce cas est Q+Q.
Le Tableau 3.2 récapitule les coûts totaux de transmissions et les hotspots de différents modèles de
stockage de données. Comparé à la méthode de stockage externe, le coût total de transmission de
GHT est toujours plus élevé dans le cas du GHT normal et GHT avec agrégation. Pourtant, comme
la station de base se trouve au coin de la zone de déploiement, dans le stockage externe, tous les
paquets doivent parcourir un long chemin pour arriver à la station de base. Tandis que dans GHT,
les paquets de stockage peuvent parcourir un chemin plus court à l’intérieur du réseau pour aller
aux nœuds responsables de ces données (ces nœuds sont distribués sur la zone de déploiement).
Ainsi, le nombre de transmissions multi-sauts réelles de stockage externe est en fait supérieur à
GHT dans le cas où le nombre de requêtes et de réponses n’est pas important. Pour un réseau à
large échelle, la valeur de N est élevée et le coût de transmission de la méthode stockage local est
beaucoup plus élevé que les méthodes de stockage externe et GHT, surtout lorsque le nombre de
requêtes est important.
Le stockage data-centric de GHT est plus performant que le stockage externe et le stockage local
sur le hotspot du réseau. En effet, il offre un partage de charge plus uniformément réparti sur le
réseau avec des nœuds qui travaillent avec la même charge quelques soient leurs positions. En plus,
avec l’agrégation, le GHT a un petit hotspot de 2*Q.
Stockage
externe
Stockage
local
GHT
GHT avec agrégation
Nb total de
transmissions
Dtotal N
QN + Dq N
Q N + Dtotal N + Dq N
Q N + Dtotal N + Q N
Hotspot
Dtotal
Q + Dq
Q + Dq
2Q
Tableau 3.2 - Comparaison des coûts des différents modèles de stockage de données
46
Le Tableau 3.2 donne un récapitulatif de tous les coûts de transmissions et de hotspot de différents
modèles de stockage de données. Ces mesures montrent que le stockage externe est préférable si
tous les évènements détectés sont utiles. Le modèle de stockage local est préférable si beaucoup
d’évènements sont détectés mais peu de requêtes envoyées pour ces évènements. Le modèle GHT
est préférable dans le cas d’un réseau de capteurs à large échelle où la valeur de N est élevée et
plusieurs évènements détectés, mais peu d’évènements sont récupérés Dtotal >>max[Dq, Q].
c)
GEM – Graphe embarqué pour le routage et le stockage data-centric dans les
réseaux de capteurs sans information géographique
Dans les parties précédentes, nous avons supposé que les nœuds étaient dotés d’un support de
services (Ex : GPS) permettant d’obtenir une information sur leur position dans le réseau.
Cependant, cette supposition n’est pas réalisable dans certains cas. D’une part, le prix d’un GPS est
encore très élevé ce qui empêche un déploiement à large échelle des réseaux de capteurs. D’autre
part, le GPS ne fonctionne pas à l’intérieur des bâtiments. Donc, les réseaux de capteurs qui sont
déployés dans les bâtiments ne peuvent pas utiliser le GPS pour la localisation. Dans ce cas, il faut
utiliser une autre méthode de stockage data-centric sans utiliser d’informations géographiques.
GEM (Graph EMbedding) [76] est la première proposition de stockage data-centric sans utiliser les
méthodes de localisation de capteurs. Au lieu d’utiliser les coordonnées réelles des nœuds, GEM
utilise les coordonnées virtuelles. En effet, GEM propose un système de coordination polaire
virtuelle (VPCS - Virtual Polar Coordinate Space) où les nœuds ont une adresse virtuelle par
rapport à la station de base. En se basant sur cet espace virtuel, les nœuds appliquent un protocole
de routage VPCR (Virtual Polar Coordinate Routing) qui est un protocole de routage dédié pour
l’espace virtuel de GEM.
Espace de Coordination Polaire Virtuelle
Dans VPCS, on construit un espace virtuel qui est représenté par un arbre complété en anneau sur
la topologie du réseau. En effet, à chaque nœud est attribué un niveau qui correspond au nombre de
sauts vers la racine de l’arbre et un angle virtuel qui fait la différence entre les nœuds dans le même
niveau. La Figure 3.7 illustre la structure d’un espace de coordination polaire virtuelle. Pour
construire cet espace, un nœud initialise la topologie en prenant le niveau 0 de la racine d’un arbre
et diffuse un message d’annonce. Les nœuds qui reçoivent ce message prennent le niveau 1 et
continuent à diffuser ce message aux nœuds fils. Cette procédure est répétée jusqu’à ce que le
message arrive aux feuilles de l’arbre. Maintenant, tous les nœuds connaissent leur niveau dans
l’espace virtuel. Les nœuds renvoient aux nœuds parents la taille de leur sous-arbre. Le nœud père
connaît le nombre de sous-arbre pour chaque fils et il peut attribuer à son fils un espace adresse
suffisamment large pour tous les nœuds à ce sous-arbre (espace adresse est représentée par un
angle). Observons la Figure 3.7a, le nœud racine possède un angle de 90°, il a deux fils et ces deux
fils ont également deux fils. Donc, le nœud racine attribue à ces deux fils le même volume d’espace
47
d’adresse (45° pour chacun). Si un nœud fils possède plus de nœuds dans son sous-arbre, le nœud
père va lui attribuer un espace d’adressage de taille plus important. En utilisant cette méthode,
chaque nœud possède une adresse logique qui se compose de son niveau dans l’arbre et de son
angle. Cependant, le seul lien entre les nœuds est via leur père. Il n’y a pas de lien direct entre les
nœuds dans un même niveau. Dans VPCS, les nœuds utilisent une méthode heuristique afin
d’aligner les adresses des nœuds dans un même niveau. Pour cela, nous avons un arbre où les
nœuds d’un même niveau ont une adresse croissante comme illustré dans la Figure 3.7a. Les liens
directs entre les nœuds voisins dans le même niveau vont beaucoup améliorer le routage des
informations dans le système.
[0 :90]
Niveau 0
1
[0 :45]
[46 :90]
1
Niveau 1
1
1
2
[68 :90] Niveau 2
[0 :22]
2
D
S
[23 :45]
[46 :67
]
a) Espace de coordination polaire virtuelle
b)
Routage de coordination polaire virtuelle
Figure 3.7 - Fonctionnement de GEM
Routage Coordination Polaire Virtuelle
Dans l’espace de coordination polaire virtuelle, nous avons construit un arbre où nous garantissons
le lien entre les nœuds père et fils. De n’importe quelle position, un nœud peut envoyer
successivement un paquet à son père afin d’atteindre la racine (la station de base dans le cas d’un
réseau de capteurs). La Figure 3.7b illustre le routage en utilisant l’espace de coordination polaire
virtuelle.
Comme un nœud sait router vers la station de base en envoyant successivement à son père, la
première solution de routage consiste à passer par la station de base. Dans la Figure 3.7b, la route
notée 1 illustre ce routage du nœud S vers le nœud D. Le nœud S envoie le paquet à son père et
ainsi de suite vers la racine de l’arbre. Ensuite, le nœud racine envoie le paquet à son fils qui
48
3.3 Conclusion
contient l’adresse du nœud destinataire. Comme l’adresse d’un nœud fils est inclue dans l’adresse
de son ancêtre, nous pouvons choisir facilement le nœud fils qui contient l’adresse du nœud
destinataire. Cette solution garantit toujours un bon routage du nœud source au nœud destinataire.
Cependant, c’est un gaspillage de communication s’il faut toujours router le paquet vers la racine
même si qu’on n’a pas besoin.
Une amélioration de cette méthode de routage en utilisant VPCS est également proposée. En effet,
l’espace de coordination polaire virtuelle est construit pour que les nœuds dans le même niveau
puissent connaître les identifiants de leurs voisins et qu’ils aient une adresse croissante. De ce fait,
au lieu de router le message vers la racine dans tous les cas, les nœuds peuvent utiliser les
raccourcis entre les nœuds du même niveau afin de router plus efficacement. Observons la Figure
3.7b, la route notée 2 prend les raccourcis entre les nœuds du même niveau pour router son
message. En deux sauts, on arrive à transmettre le message du nœud source vers le nœud
destinataire tandis que pour la première solution, il faut 4 sauts pour cette transmission.
Dans cette partie, nous avons vu une méthode de routage sans utiliser la position réelle des nœuds.
Cette approche est avantageuse pour le stockage de données data-centric où nous pouvons éviter
l’utilisation de dispositifs coûteux pour connaître la position réelle du nœud. Cependant, cette
approche n’est plus optimale si il y a beaucoup de nœuds mobiles dans le réseau. En effet,
lorsqu’un nœud est mobile ou tombe en panne, il faut mettre à jour les adresses de tous les nœuds
fils de ce nœud car la liaison vers la station de base est coupée. Cette opération est coûteuse en
nombre de communications et elle influence la consistance du protocole de routage.
3.3
Conclusion
Dans ce chapitre, nous avons analysé différents modèles de stockage de données : stockage local,
stockage externe et stockage data-centric. Nous avons vu également que le modèle de stockage de
données peut beaucoup influencer à la consommation d’énergie du réseau. Chaque modèle est
normalement optimisé pour un scénario du réseau de capteurs. Le modèle de stockage de données
data-centric est préférable dans le cas d’un réseau de capteurs à large échelle où plusieurs
évènements détectés, mais peu d’évènements sont récupérés. Ce modèle est basé sur la table de
hachage distribuée afin de distribuer des données d’une manière uniforme dans le réseau. La table
de hachage distribuée a été utilisée pour les réseaux pair-à-pair structurés [65][66][67][68][69]
depuis longtemps et elle est juste utilisée dans les réseaux de capteurs récemment.
Nous avons présenté deux approches des travaux de stockage de données distribuées dans les
réseaux de capteurs : GHT [70][71] et GEM[76]. Dans GHT, le routage est basé sur une
connaissance de la position géographique des nœuds en utilisant des dispositifs spécifiques (Ex :
GPS). Cette approche est efficace en terme d’exactitude de position des capteurs. Cependant, elle
49
est coûteuse lorsqu’on veut déployer un réseau de capteurs à large échelle. Dans GEM, le routage
est basé sur une coordination virtuelle où nous n’avons pas besoin de position géographique des
nœuds. Cette approche ne requiert pas de dispositifs comme le GPS, mais la construction d’une
coordination virtuelle est coûteuse en terme d’échange des messages. En plus, GEM n’est pas
adaptable aux réseaux de capteurs mobiles car la mobilité des nœuds implique une restructuration
coûteuse de l’espace de coordination virtuelle.
Quelques extensions de ces travaux ont été également proposées dernièrement [77][78][79][80].
Cependant, ces propositions ne sont pas optimums et il existe encore des limitations en terme de
consommation d’énergie. C’est pour cette raison que nous présentons notre contribution dans ce
domaine dans le chapitre 6.
50
Partie II
CONTRIBUTION
51
Dans la partie I, nous avons donné un état de l’art sur les différents protocoles d’accès au médium
et les méthodes de stockage de données distribuées dans les réseaux de capteurs sans fil. La
recherche dans ce domaine est très fructueuse ces dernières années avec de nombreuses
propositions et améliorations au cours du temps. Ces protocoles peuvent être optimaux dans
certaines applications mais pas dans tous les cas. La recherche dans les réseaux de capteurs est
ouverte pour de nouvelles idées afin d’optimiser encore les protocoles existants pour obtenir de
meilleures performances.
Cette partie est dédiée à mes contributions de recherche durant cette thèse. Il s’agit des propositions
de protocole d’accès au médium et de protocole de stockage de données distribuées dans les
réseaux de capteurs. Pour chaque type d’application de réseaux de capteurs, nous utilisons des
critères de performance différents. Pour les réseaux de capteurs de type surveillance (Ex : surveiller
la vie des espèces rares), nous avons besoin d’optimiser la durée de vie du réseau de capteurs. Les
informations envoyées par les capteurs ne sont pas des informations critiques, donc la latence n’est
pas un critère primordial. Par contre, pour les réseaux de capteurs orientés évènement, les
informations envoyées par les capteurs sont des informations critiques et la latence est le critère
primordial pour le réseau tandis que la consommation d’énergie est moins importante. Pour régler
les paramètres des différents réseaux de capteurs, nous proposons deux protocoles MAC pour ces
deux types d’applications.
Dans le Chapitre 4, nous proposons un protocole MAC pour les réseaux de capteurs de type
surveillance pour objectif principal de réduire la consommation d’énergie le plus possible et
prolonger la durée de vie du réseau. Puis, nous proposons un protocole MAC qui offre une très
faible latence pour les réseaux de capteurs orientés évènements dans le Chapitre 5. Comme les
communications sont très coûteuses en terme de consommation d’énergie, nous traitons également
les modèles de stockage de données dans un RdC. Le stockage de données peut beaucoup
influencer la consommation d’énergie globale du réseau car les traitements locaux des données sont
beaucoup moins coûteux que les transmissions. Enfin, dans le Chapitre 6, nous présentons
également une amélioration de protocoles de stockage de données distribuées pour les réseaux de
capteurs.
52
Chapitre 4.
Protocole MAC économisant
l’énergie pour réseaux de capteurs de type
surveillance
Comme nous l’avons présenté dans les parties précédentes, la consommation d’énergie est un
facteur déterminantpour les réseaux de capteurs de type surveillance. Dans ce type de réseaux, les
capteurs prennent les informations ambiantes et les envoient à la station de base périodiquement.
Ces informations servent à analyser l’historique des changements intervenus dans le milieu
ambiant au cours du temps. Par exemple, si on considère un réseau de capteurs déployé sur un île
pour surveiller la vie des pétrels ou un réseau de capteurs déployé sur les glaciers pour mesurer la
variation de température dans le temps, ces informations ne sont pas critiques et le délai de
transmission n’est pas très important. Comme ce réseau est normalement déployé sur une zone
isolée, nous ne pouvons pas envisager un scénario où une personne se déplace pour changer les
piles des capteurs toutes les semaines. On doit donc développer des méthodes pour économiser
l’énergie pour que le réseau de capteurs puisse fonctionner pendant des années sans intervention
humaine. Ce critère de consommation d’énergie est donc très important à prendre en compte.
Dans ce chapitre, nous allons tout d’abord présenter dans 4.1 un protocole d’accès au médium
économisant énergie que l’on appellera OBMAC (Overhearing Based MAC) [80][82][83]. Ensuite,
nous analysons le comportement de OBMAC dans les différents scénarios et nous montrons que
dans certains cas, OBMAC peut donner de mauvaises résultats. Dans 4.1.3 , nous allons résoudre
ce problème en proposant une nouvelle notion appelée “portée influente” afin de raffiner le
comportement du protocole OBMAC. Dans 4.2 , nous évaluons notre proposition OBMAC en
utilisant un simulateur et une plateforme de capteurs réelle. Enfin, nous concluons notre
proposition dans la partie 1.1 .
4.1
Protocole d’accès au médium basé sur l’écoute
passive
Dans [32], les auteurs ont montré que la communication entre les capteurs est l’activité la plus
coûteuse. Cependant, c’est la seule méthode pour router l’information vers la station de base.
Lorsque les capteurs communiquent en utilisant le protocole d’écoute de porteuse, il existe des
53
Chapitre 4. Protocole MAC économisant l’énergie pour les réseaux de capteurs
raisons de gaspillage d’énergie: les collisions, l’écoute passive, les paquets de contrôle, l’écoute
non-active. L’écoute passive est inévitable dans certains protocoles d’accès au médium et elle est
toujours considérée comme une source de gaspillage d’énergie. Cependant, nous allons voir dans
cette partie que l’écoute passive peut être une bonne méthode pour réduire le nombre de
communications redondantes et la consommation d’énergie.
4.1.1 Hypothèse pour le réseau de capteurs
Nous commençons par une présentation du contexte propre au réseau de capteurs. Il y a plusieurs
types de réseaux de capteurs et chaque protocole d’accès au canal est normalement optimisé pour
un type de ces réseaux. Donc, il est nécessaire de bien définir le contexte du réseau de capteurs que
nous allons traiter. Nous supposons qu’un réseau de capteurs de type surveillance a pour but
l’envoi de mesures périodiquement. Les capteurs déployés sont denses et positionnées
aléatoirement pour mesurer des informations ambiantes : température, vibration, pression,
humidité, luminosité etc. Ce type de réseau de capteurs peut être utilisé dans le domaine de
l’environnement. Par exemple, les capteurs de température et d’humidité sont déployés dans une
forêt pour mesurer la variation de température et l’humidité. Puisque la forêt est très vaste, une
solution pour déployer les capteurs est donc de parcourir la forêt en avion et de jeter les capteurs.
Les capteurs vont s’auto-organiser afin d’établir des liaisons vers la station de base
dynamiquement. Pour ce genre de réseau de capteurs, on dit que les capteurs sont déployés d’une
manière dense et aléatoire.
Périodiquement, les capteurs prennent les mesures et les envoient à la station de base via les
communications multi-sauts. Comme les capteurs sont susceptibles d’être dans la même zone (ils
sont déployés aléatoirement), ils peuvent détecter les mêmes évènements et lorsqu’ils envoient tous
les mêmes informations à la station de base, c’est un gaspillage d’énergie. En effet, ce n’est pas une
seule transmission mais une transmission multi-saut, ce qui implique plusieurs transmissions à la
fois. Si nous pouvons trouver des méthodes pour éviter ce genre de gaspillage d’énergie, ce serait
très utile.
4.1.2 Topologie du réseau
En utilisant les techniques existantes [50][84][85], les capteurs s’organisent automatiquement sous
forme d’une topologie en arbre. Dans une telle topologie, il y a un nœud central qui joue le rôle de
la station de base. Les capteurs construisent des liens vers la station de base afin d’envoyer leurs
mesures. En effet, il y a normalement deux types de nœuds dans une topologie en arbre : des nœuds
routeurs et des nœuds feuilles. Le nœud routeur peut à la fois capter des informations ambiantes et
router les messages pour les autres, tandis que le nœud feuille ne fait que capter des informations
ambiantes et les envoyer à la station de base via des nœuds routeurs.
54
4.1 Protocole d’accès au médium basé sur l’écoute passive
Station de base
Nœud routeur
Nœud feuille
Figure 4.1 - Topologie en arbre d’un réseau de capteurs
La Figure 4.1 illustre cette topologie avec plusieurs nœuds routeurs, nœud feuilles et une station de
base. Nous pouvons constater que les nœuds feuilles sont aux extrémités de l’arbre et ils ne routent
pas les messages pour les autres. Chaque nœud routeur a plusieurs nœuds fils : nœud routeur ou
nœud feuille. Ce type de protocole est aussi normalisé dans 802.15.4 [12] où la station de base est
représentée par un coordinateur PAN (réseau personnel) ; les nœuds routeurs sont représentés par
les nœuds FFD (Full Function Device) et les nœuds feuilles sont représentés par les nœuds RFD
(Reduced Function Device). Dans ce type de fonctionnement du système, un nœud routeur peut
consommer plus d’énergie que les nœuds feuilles. Quand un nœud routeur estime qu’il ne reste
plus beaucoup d’énergie, il peut décider de devenir un nœud feuille pour réduire la charge et laisser
la tâche de routage pour un autre nœud. Lorsque la topologie du réseau est établie, les nœuds
commencent à transmettre les mesures périodiquement à la station de base via les nœuds routeurs.
La station de base récupère les mesures, et les stocke dans une base de données.
4.1.3 Fonctionnement de OBMAC
Dans la partie état de l’art, nous avons vu plusieurs protocoles d’accès au médium pour réduire la
consommation d’énergie : S-MAC [34], T-MAC[36], 802.15.4 [12], B-MAC[47] etc. Le but
principal de ces propositions était de réduire le temps de fonctionnement du transceiveur au
maximum. Pour atteindre ce but, les capteurs dans ces réseaux changent leur transceiveur de l’état
actif à l’état en veille périodiquement. Ils communiquent durant le temps où leur transceiveur est
actif et ils économisent l’énergie pendant le temps endormi de leur transceiveur. Afin d’éviter le
55
problème appelé "envoi sourd” (un nœud actif transmet à un nœud endormi), les capteurs se
synchronisent pour travailler et dormir simultanément. Cependant, comme les capteurs sont
susceptibles d’être dans la même zone, ils peuvent détecter les mêmes mesures et les envoyer à la
station de base. Ces transmissions sont redondantes et c’est un gaspillage d’énergie. En effet,
aucune des propositions existantes de la couche MAC n’a pris en compte cet aspect car le seul but
de ces propositions est de réduire le temps de fonctionnement du transceiveur mais pas de réduire
le nombre de transmissions redondantes.
Dans cette partie, nous allons présenter le fonctionnement de notre proposition OBMAC
(Overhearing Based MAC). L’objectif principal de OBMAC est de réduire la consommation
d’énergie. Cela englobe deux tâches : réduire le temps de fonctionnement du transceiveur et réduire
le nombre de communication redondante. Notre proposition améliore les protocoles existants en
utilisant des méthodes efficaces pour filtrer les communications redondantes afin d’éviter de
transmettre.
a)
OBMAC sur 802.15.4
OBMAC est une extension du protocole d’accès au médium synchronisé pour les réseaux de
capteurs. Nous illustrons le fonctionnement de OBMAC sur le protocole d’accès au médium de
802.15.4 [12], une norme de protocole d’accès au médium dédié pour les réseaux à faible
consommation d’énergie. Les nœuds divisent leur temps de fonctionnement en deux parties : une
période active et une période endormie (Figure 2.8). Les nœuds sont synchronisés par les paquets
“beacon” au début de chaque période active.
Pendant la période active, les nœuds accèdent au canal en contention en utilisant la méthode
d’écoute de porteuse. Ils sont obligés de rester en état actif durant la période active. Quand un
nœud gagne le canal et transmet son paquet, les autres nœuds changent le mode de transceiveur en
mode écoute pour recevoir d’éventuelles données ou pour connaître le moment où le transmetteur
termine sa transmission. Si un nœud n’est pas le récepteur d’une transmission, il abandonne les
paquets qu’il a écoutés passivement. On a ainsi le problème de l’écoute passive car ces nœuds sont
obligés d’écouter les paquets dont ils ne sont pas destinataires. L’écoute passive est une source de
gaspillage d’énergie et elle est inévitable pour la norme 802.15.4.
L’idée principale de OBMAC est de profiter du problème d’écoute passive afin de réduire le
nombre de transmissions redondantes. Pour cela, nous proposons une première règle pour
OBMAC.
Règle 4.1 : Un nœud vérifie le paquet qu’il a écouté passivement afin de savoir s’il possède la
même information qu’il veut transmettre au même destinataire.
56
Lorsqu’un nœud perd le canal de communication, il doit laisser le paquet qu’il veut transmettre
dans une liste d’attente dans sa couche d’accès au médium. En appliquant la règle 4.1, il va
comparer le paquet qu’il écoute passivement et le paquet qu’il veut transmettre dans sa liste
d’attente. Si les deux paquets ont la même adresse de destination (la station de base dans la plupart
des cas), la même information de mesure (température, vibration etc.), ce nœud enlève simplement
ce paquet dans sa liste d’attente car un paquet avec la même information a été envoyé à la même
destination. Au contraire, ce nœud jette le paquet qu’il a écouté passivement et réessaie de
transmettre son paquet de sa liste d’attente dans la prochaine période d’accès au canal.
Intervalle beacon
père
B
Réception
endormi
B
Réception
endormi
fils 1
B
Transmission
endormi
B
Ecoute passive
endormi
Vérifier des paquets redondants
fils 2
B
Ecoute passive
endormi
B
Transmission
endormi
B : Beacon
Figure 4.2 - Règle 4.1 de OBMAC avec 802.15.4
En réduisant le nombre de communications redondantes, nous réduisons également la
consommation d’énergie et prolongeons la durée de vie d’un réseau de capteurs. Ce qui est
intéressant dans la règle 4.1 est que nous supprimons seulement les transmissions inutiles alors que
les données non redondantes sont transmises normalement.
Afin de mieux comprendre le fonctionnement de la règle 4.1 de OBMAC, nous prenons le cas
d’une communication entre un nœud père et deux nœuds fils. Les deux nœuds fils mesurent les
informations ambiantes et les envoient périodiquement à la station de base via le nœud père. La
relation père-fils est réalisée lorsque les nœuds s’auto-organisent dans une topologie d’arbre. La
Figure 4.2 illustre le fonctionnement de la règle 4.1 basée sur 802.15.4. Pour chaque période active,
le père envoie un paquet de diffusion beacon pour que les nœuds fils puissent se synchroniser avec
lui. Les nœuds fils sont programmés pour envoyer leurs mesures périodiquement pour chaque
période active du réseau. Donc, ils accèdent au canal en contention en prenant une valeur back-off
aléatoire dans la fenêtre de contention. Dans la Figure 4.2, nous illustrons deux périodes de
transmission des nœuds. Pour la première période, supposons que le nœud fils 1 gagne le canal, il
57
va transmettre son paquet à son père. Le fils 2 perd le canal et doit écouter le canal passivement.
Dans le cas normal, cette écoute sert simplement à connaître le moment où le fils 1 termine sa
transmission. En appliquant la règle 4.1, le fils 2 utilise cette écoute passive pour vérifier si la
même information a été envoyée. Si c’est le cas, le fils 2 enlève ce paquet de sa liste d’attente de la
couche d’accès au médium. Après la période active, tous les nœuds s’endorment pour économiser
l’énergie jusqu’à la prochaine période. Une nouvelle période active commence par un paquet
beacon. Ensuite, les nœuds fils 1 et fils 2 sont en contention pour accéder au canal. Comme le
choix de la valeur back-off est aléatoire, nous ne savons pas à l’avance le nœud qui gagnera le
canal. Supposons que cette fois ci, le fils 2 gagne le canal. La procédure est répétée où le nœud fils
1 écoute passivement le canal pour vérifier les informations redondantes et annule son paquet dans
sa liste d’attente s’il trouve des données redondantes
En appliquant la règle 4.1 de OBMAC dans un scénario simple de la Figure 4.2, nous constatons
que si les nœuds fils 1 et fils 2 envoient la même information à la même adresse (la station de
base), nous pouvons filtrer ces informations redondantes et éviter des transmissions inutiles.
L’accès au canal aléatoire garantit qu’on peut économiser l’énergie sur les nœuds fils d’une
manière uniforme. Dans le schéma ci-dessus, nous observons que les nœuds fils 1 et fils 2
économisent chacun une transmission. La consommation d’énergie est distribuée uniformément sur
différents nœuds.
En analysant OBMAC, on pourrait penser que si un nœud écoute passivement et si les données ne
sont pas les mêmes, c’est un gaspillage d’énergie. Selon la norme 802.15.4, les nœuds mettent
toujours leur transceiveur en mode actif pendant la période active, peu importe s’ils ont de données
à envoyer ou pas. En plus, l’écoute passive est inévitable dans 802.15.4. Au lieu de gaspiller
l’énergie pour écouter les messages des autres, juste pour voir le moment où la transmission sera
terminée, nous profitons de cette écoute passive comme une méthode efficace pour filtrer et réduire
les transmissions redondantes.
b)
OBMAC sur S-MAC
Le protocole 802.15.4 [12] est bien connu car il est normalisé par l’organisation IEEE. Cependant,
il ne permet pas d’éviter l’écoute passive. Certains protocoles d’accès au médium de la famille
"MAC synchronisé” peuvent éviter efficacement le problème d’écoute passive (S-MAC [34], TMAC [36], DSMAC [38] etc.). Nous allons voir comment la règle 4.1 de OBMAC peut être
appliquée dans ces protocoles afin de réduire le nombre de transmissions redondantes.
Nous appliquons OBMAC sur S-MAC [34] car S-MAC est un exemple typique de la famille MAC
synchronisé. Dans S-MAC, les nœuds se mettent dans l’état actif et endormi alternativement.
Cependant, la période active est beaucoup plus courte que dans 802.15.4 et le but de cette période
est d’échanger les messages de contrôle pour savoir si un nœud est récepteur ou transmetteur. Si
58
c’est le cas, il laisse son transceiveur dans l’état actif pendant tout un cycle. Si ce n’est pas le cas, il
éteint le transceiveur et se remet en état actif pour la prochaine période.
OBMAC propose de modifier le fonctionnement de S-MAC. La Figure 4.3 illustre un scénario de
transmission entre un nœud père et trois nœuds fils. Supposons que les nœuds fils 1 et fils 2 aient
des données à envoyer, le fils 3 n’a pas de mesure à transmettre. Cela est possible dans certaines
applications où nous nous intéressons à une certaine mesure précise. Par exemple, nous nous
intéressons seulement aux valeurs de température qui dépassent 50°C. Dans ce cas, le capteur
envoie un paquet seulement quand il détecte une température supérieure à 50°C. Sinon, il n’envoie
rien du tout, et se réveille juste pour se synchroniser avec les autres capteurs. Dans ce scénario, les
nœuds fils 1 et fils 2 détectent une hausse de température et le nœud fils 3 ne détecte rien (il
pourrait se trouver loin de la zone où la température est élevée). Périodiquement, les nœuds
échangent les paquets de contrôle. Les nœuds fils 1 et fils 2 sont en contention pour accéder au
canal. Le fils 3 retourne à l’état endormi car il n’a pas de donnée à envoyer. Supposons que le
nœud fils 1 gagne le canal et envoie sont paquet à son père. Le fils 2 perd le canal, il laisse toujours
son transceiveur en marche pour écouter la communication entre le fils 1 et le père. Cette écoute a
pour but de vérifier si le fils 1 transmet la même information au nœud père. Lors de cette
vérification, si le fils 2 trouve qu’il possède la même information qu’il veut envoyer à la station de
base via le nœud père, il va supprimer sa transmission pour cette information. Dans le cas contraire,
il arrête immédiatement son écoute passive et revient à l’état endormi jusqu’à la prochaine période.
Cela peut éviter une longue durée d’écoute passive si l’information qu’il écoute n’est pas la même
que l’information qu’il veut transmettre.
Intervalle beacon
père
SYN RTS CTS
Réception
SYN RTS CTS
Réception
fils 1
SYN RTS CTS
Transmission
SYN RTS CTS
Ecoute Passive
fils 2
SYN RTS CTS
Ecoute Passive
SYN RTS CTS
Transmission
fils 3
SYN RTS CTS
endormi
SYN RTS CTS
endormi
Figure 4.3 - Règle 4.1 de OBMAC avec S-MAC
59
L’utilisation de OBMAC dans S-MAC n’est pas aussi avantageux que dans 802.15.4 car l’écoute
passive dans 802.15.4 est inévitable, tandis que dans S-MAC, nous obligeons les nœuds à rester en
mode d’écoute passive. Les capteurs consomment l’énergie en mode écoute passive et cela est une
source de gaspillage d’énergie. Alors, il faut prouver que les capteurs en mode écoute passive
consomment moins d’énergie que les capteurs qui envoient des informations redondantes. En effet,
il y a plusieurs raisons qui prouvent l’efficacité de OBMAC. Premièrement, la consommation
d’énergie en mode réception est inférieure au mode transmission dans la plupart des transceiveurs
existants. Deuxièmement, un nœud se met en état "écoute passive" seulement quand il a des
données à envoyer et il ne gagne pas le canal de communication. En plus, la durée du temps
d’écoute passive est normalement courte car elle est terminée si un nœud trouve les données
différentes que les données qu’il possède. Troisièmement, les capteurs qui se trouvent dans la
même zone ont une forte probabilité de mesurer les mêmes informations. Pour toutes ces raisons,
nous pouvons dire que OBMAC peut réduire le nombre de transmissions redondantes efficacement.
En effet, l’écoute passive a été utilisée dans les protocoles d’accès au médium par écoute de
porteuse. Cependant, elle sert seulement à connaître le moment où le canal sera libre. OBMAC est
la première technique qui utilise l’écoute passive pour réduire le nombre de communication
redondante. Cette technique ne peut pas être appliquée aux réseaux sans fils traditionnels car dans
ces réseaux, chaque nœud utilise un scénario de transmission différent. Le but de ces réseaux est de
garantir une transmission de bout en bout entre deux nœuds quelconques. Dans les réseaux de
capteurs, nous nous intéressons aux transmissions des informations sur une zone jusqu’à la station
de base. Si deux nœuds voisins ont la même information à signaler à la station de base, il vaut
mieux l’envoyer une seule fois pour économiser l’énergie. OBMAC est conçu particulièrement
pour les réseaux de capteurs afin de réduire les transmissions inutiles.
4.1.4 Portée influente
En profitant de l’écoute passive de la règle 4.1, nous pouvons réduire les communications
redondantes dans la portée radio des nœuds. Cependant, la portée radio est normalement assez
large : 100 mètre en 802.11 [31] et 70 mètre en 802.15.4 [12]. Quand on applique OBMAC, on va
voir que les nœuds peuvent annuler leur transmission pour les informations qui ne viennent pas de
la même source. La Figure 4.4 illustre un scénario où il y a deux sources d’information différentes
(représentés par les feux). Les nœuds A, B et C ont des données à envoyer à la station de base via
des nœuds routeurs. Supposons que le nœud A gagne le canal et commence sa transmission.
Puisque les nœuds B et C sont dans la portée radio du nœud A (le grand cercle) et ont la même
information qu’ils veulent transmettre, ils vont annuler leur transmission. Cela est justifié pour le
nœud B car il se trouve juste à côté du nœud A et il détecte la même source de changement de
température. Cependant, le nœud C se trouve loin du nœud A et il ne détecte pas le même
évènement. Donc, le nœud C ne doit pas annuler sa transmission. En plus, pour une zone de rayon
~ 100m, si les capteurs envoient seulement 1 paquet pour annoncer l’évènement (puisque tous les
60
capteurs aux alentours annulent leur transmission), cela pose un problème de tolérance aux fautes
qui ne permet pas de garantir une transmission fiable dans l’environnement sans fil.
La portée radio
Station de base
Nœud routeur
La portée influente
RSSI <α
Nœud feuille
B
A
Rayon ~ 100m
C
RSSI : Received Signal Strength
Indicator
RSSI >α
Figure 4.4 - OBMAC dans la portée influente de A
Pour remédier à ces deux limitations, nous raffinons l’approche de OBMAC en prenant en compte
la portée radio. Nous définissons un nouveau concept que l’on appelle la portée influente.
Définition 1: La portée influente d’un nœud N est la zone où les nœuds voisins sont susceptibles
d’observer les mêmes informations et est obtenue par la valeur de l’indicateur de puissance du
signal reçu (RSSI – Received Signal Strength Indicator)
En effet, la portée influente est différente de la portée radio et est toujours plus petite que la portée
radio d’un nœud. La Figure 4.4 illustre ces deux portées : la portée radio est le grand cercle et la
portée influente est le petit cercle. Pour raffiner OBMAC, nous appliquons une autre règle en
utilisant la portée influente.
Règle 4.2 : Un nœud applique la règle 4.1 si et seulement si, il est dans la portée influente du nœud
transmetteur.
La règle 4.2 garantit que nous annulons seulement les informations identiques qui se trouvent dans
le rayon de la portée influente. Les nœuds qui se trouvent à l’extérieur de cette portée ne vont pas
appliquer la règle 4.1 car leur information vient d’endroits différents et ce n’est pas une
61
information redondante. L’ensemble des règles 4.1 et 4.2 réalise la proposition complète de
OBMAC.
En effet, un nœud décide d’appliquer la règle 4.1 selon la valeur de la portée influente. Mais,
comment pouvons nous savoir si un nœud est dans la portée influente ? Dans notre approche, la
portée influente d’un nœud est définie par le transmetteur. Quand les capteurs communiquent, le
capteur qui se trouve le plus proche du nœud transmetteur reçoit un signal avec une puissance plus
forte que le capteur plus éloigné. La puissance du signal reçu est inversement proportionnelle à la
distance entre le transmetteur et le récepteur. Dans un réseau sans fil, chaque nœud est toujours
doté d’un dispositif d’évaluation de la puissance du signal reçu. C’est un indicateur de puissance du
signal reçu (RSSI – Received Signal Strength Indicator). Observons la Figure 4.4, quand le nœud A
transmet, le nœud B et le nœud C sont dans la portée radio du nœud A. Ils peuvent écouter la
transmission entre le nœud A et le nœud routeur. Cependant, la distance AB < AC, alors le RSSI
reçu au nœud B est plus fort qu’au nœud C. A partir de la valeur RSSI reçue, un nœud peut estimer
sa distance avec le transmetteur.
Un paquet à
transmettre
Ecouter le
canal
non
Libre
non
RSSI > α
non
oui
Paquets redondants ?
oui
oui
Envoi du
paquet
Suppression
du paquet
Figure 4.5 - Diagramme du fonctionnement de OBMAC avec la portée influente
Nous définissons un seuil α pour déterminer la portée influente d’un nœud. Lorsqu’un nœud reçoit
un paquet avec la valeur de RSSI plus grande que α, il sait qu’il est dans la portée influente du
62
nœud transmetteur. Le seuil α est une valeur paramétrable dans OBMAC et selon le type
d’application, nous pouvons lui attribuer des valeurs différentes.
La Figure 4.5 illustre le diagramme de fonctionnement de OBMAC dans la portée influente. En
appliquant ce diagramme sur la topologie de la Figure 4.6, lorsque les nœuds A, B et C veulent
transmettre les informations à la station de base via des nœuds routeurs, ils sont en contention pour
accéder au canal. Le nœud A gagne le canal et commence sa transmission. Les nœuds B et C
reçoivent la transmission du nœud A. Ils calculent la puissance du signal reçu pour savoir s’ils sont
dans la portée influente du nœud A. Le nœud B reçoit une puissance du signal plus forte que le
seuil α, il est dans la portée influente du nœud transmetteur A. Alors, il met son transceiveur dans
l’état actif pour l’écoute passive même s’il n’est pas le récepteur de cette transmission. En
appliquant OBMAC, il vérifie si le message qu’il écoute passivement est identique au message
qu’il veut transmettre à la station de base. Si c’est le cas, il va annuler sa transmission pour ce
message. Le nœud C reçoit une puissance du signal inférieure de la valeur α, il sait qu’il n’est pas
dans la portée influente du nœud A. Donc, l’information qu’il veut transmettre ne vient pas de la
même source que le nœud A et il ne va pas appliquer la règle 4.1 de OBMAC. Au contraire, il
éteint son transceiveur pour économiser l’énergie pendant cette période. Pour la prochaine période,
le nœud C va transmettre son paquet tandis que le nœud B ne transmet plus son paquet car il a
annulé sa transmission redondante.
En utilisant OBMAC dans la portée influente, le nœud B peut éviter une transmission inutile. Nous
pouvons éviter la transmission de B et le routage du message de B vers la station de base via 2
nœuds routeurs. Dans cet exemple, nous évitons 3 transmissions inutiles. Dans un réseau de
capteurs à large échelle avec plusieurs nœuds et des transmissions multi-sauts, nous pouvons éviter
beaucoup de transmissions redondantes.
Lorsque les nœuds A, B et C sont en contention pour accéder au canal, nous ne connaissons pas
l’ordre d’accès au canal de ces nœuds. Dans la Figure 4.4, le nœud A gagne le canal et transmet à
la station de base via 2 nœuds routeurs. Le nœud A consomme de l’énergie pour cette transmission.
Pour la prochaine période, il se peut que le nœud B gagne le canal, il va consommer de l’énergie
pour transmettre l’information ambiante de la zone tandis que le nœud A peut s’endormir pour
économiser énergie. Comme l’accès au canal est effectué d’une manière aléatoire, nous pouvons
voir que les capteurs A et B qui se trouvent dans la même zone vont économiser la même quantité
d’énergie. Les nœuds routeurs consomment plus d’énergie que les nœuds feuilles et épuisent leur
énergie plus rapidement. Ils doivent utiliser des techniques pour réorganiser la topologie du réseau
d’une manière intelligente en partageant la charge avec les autres nœuds. Cette approche est dans le
cadre d’une autre problématique sur l’auto-organisation du réseau de capteurs et nous n’allons pas
aborder ce problème dans cette partie. L’application de la règle 4.2 peut également améliorer la
tolérance aux fautes dans le réseau. Nous trouvons dans la Figure 4.4 que pour trois nœuds qui se
63
trouvent dans la portée radio, nous avons toujours deux paquets envoyés par les capteurs A (ou B)
et C.
4.2
Evaluation de performance
Dans cette partie, nous allons présenter les résultats d’évaluation de performance de OBMAC en
comparaison avec les protocoles d’accès au médium existants. Nous utilisons le simulateur
OMNet++ [86] afin de valider OBMAC. OMNet++ est un environnement de simulation
d’évènements discrets. Il est largement utilisé dans la communauté scientifique afin de simuler les
réseaux de communication. Après comparaison avec les autres simulateurs existants comme NS2
[87], Opnet [88], nous avons choisi OMNet++ car il est open-source et plus léger, ce qui nous
permet de simuler les réseaux à large échelle avec un nombre de nœuds important. OMNet++
fournit une architecture basée sur des composants programmés en C++ et il permet une réutilisation
de modèles existants facilement.
Zone de déploiement
500x500
Nombre de nœuds
5-20
La portée influente
-60 dBm à -90 dBm
Energie un pile AA
2900mAh
Processeur (Actif / Endormi)
8mA / 15µA
Transceiveur (Tx/ Rx/ Endormi)
27mA/ 10mA/ 1µA
Puissance du Transceiveur
3mW
Sensibilité du Récepteur
-98 dBm
Période active/ endormie
0.1s / 9.9 s
Fréquence de transfert de données
1 paquet / 10 secondes
Temps de simulation
500s
Tableau 4.1 - Paramètres de simulation
Afin de simuler les communications sans fil d’un réseau de capteurs, nous avons utilisé le modèle
Mobility Framework [89], un modèle pour OMNet++ qui fournit un environnement de simulation
de réseau sans fil et mobile. Enfin, pour simuler la consommation d’énergie sur des capteurs, nous
utilisons le Battery Model [90] pour mesurer le niveau d’énergie sur les capteurs dans un réseau.
L’environnement de simulation que nous venons de présenter est utilisé pour valider le protocole
64
4.2 Evaluation de performance
OBMAC. Cependant, c’est aussi l’environnement que nous utiliserons pour simuler et valider notre
proposition tout au long de cette thèse.
4.2.1 Paramètres de simulation
Le Tableau 4.1 illustre les paramètres de simulation utilisés dans notre évaluation de performance.
Nous déployons les capteurs aléatoirement dans une zone rectangle de 500x500. Nous utilisons les
paramètres de transceiveur radio de Mica2 [10] avec la consommation d’énergie en mode
transmission/ réception/ endormi ~ 27mA/ 10mA/ 1µA. La station de base est située au centre de la
zone de déploiement. Périodiquement, les capteurs envoient les données de l’environnement
d’ambiant à la station de base. Les nœuds changent le mode de fonctionnement du transceiveur de
l’état actif à l’état endormi périodiquement. Après avoir transmis un paquet dans une période
active, les nœuds se mettent à l’état endormi selon la norme 802.15.4 pour économiser énergie.
4.2.2 Temps de latence
Dans la première évaluation, nous comparons le temps de latence entre 802.11, 802.15.4 et
OBMAC. La latence est le temps pendant lequel les capteurs envoient les paquets concernant un
phénomène de l’environnement et le temps où la station de base reçoit tous les paquets pour cette
information.
Figure 4.6 - Temps de latence avec la portée influente α=-90 dBm
Nous fixons la portée influente α= -90 dBm ce qui signifie que les nœuds appliquent OBMAC
lorsque la puissance du signal reçu est plus élevée que -90 dBm. La Figure 4.6 illustre la latence de
transmission en faisant varier le nombre de nœuds dans la zone de déploiement. L’axe horizontal
illustre le nombre de nœuds et l’axe vertical le temps de latence. Observons cette figure, nous
trouvons que 802.11 donne une latence plus importante car ce protocole utilise les paquets de
65
contrôle (RTS, CTS, ACK) afin d’éviter les collisions relatives au problème de la station cachée.
Ces paquets de contrôle garantissent une transmission fiable entre les capteurs dans le cas du
problème de la station cachée. Cependant, ils ne donnent pas une latence optimale. Le protocole
802.15.4 améliore également le temps de latence par rapport à 802.11 car il n’utilise pas les paquets
de contrôle. Dans ces deux protocoles, lorsqu’on augmente le nombre de nœuds dans le réseau, ils
sont plus nombreux à communiquer et il faut donc plus de temps pour transmettre tous les paquets
à la station de base. Donc, la latence est proportionnelle au nombre de nœuds dans le réseau.
En appliquant OBMAC, les nœuds qui se trouvent dans la portée influente des autres peuvent
éviter les transmissions redondantes. Quand on augmente le nombre de nœuds, on augmente
également la densité de nœuds dans le réseau. Il y aura plus de nœuds qui se trouvent dans la portée
influente et plus de paquets redondants annulés. Nous constatons que la latence de transmission en
appliquant OBMAC est relativement constante par rapport au nombre de nœuds dans le réseau.
Bien que le but de OBMAC ne soit pas de réduire la latence de transmission, nous remarquons
qu’en annulant les transmissions inutiles, il faut moins de temps pour que la station de base ait une
vue globale sur les environnements de la zone de déploiement.
4.2.3 Consommation d’énergie
Etant donné que le but principal de OBMAC est de réduire la consommation d’énergie dans un
réseau de capteurs, nous comparons OBMAC avec 802.15.4 afin de montrer l’avantage de
OBMAC. Nous ne comparons pas OBMAC avec 802.11 car ce dernier n’utilise pas de méthodes
pour économiser énergie. La consommation d’énergie de 802.11 est très élevée par rapport à
802.15.4 et OBMAC. Si nous dessinons les trois protocoles sur la même figure, il sera difficile de
visualiser la différence de la consommation d’énergie entre 802.15.4 et OBMAC. C’est la raison
pour laquelle nous n’affichons pas la consommation d’énergie de 802.11 dans la Figure 4.7.
Cette figure illustre la consommation d’énergie moyenne de tous les nœuds dans le réseau en
faisant varier le nombre de nœuds. L’axe horizontal représente le nombre de nœuds dans le réseau.
L’axe vertical représente la consommation d’énergie moyenne de tous les nœuds. Dans 802.15.4,
tous les nœuds envoient les paquets à la station de base. Lorsqu’on incrémente le nombre de
nœuds, la congestion du réseau est augmentée et les nœuds doivent attendre plus de temps pour
accéder au canal. Notons que les courbes dans la Figure 4.7 représentent la consommation
d’énergie moyenne, la courbe de 802.15.4 ressemble à un trait horizontal car les nœuds travaillent
et dorment selon une durée identique.
Dans OBMAC, lorsqu’on incrémente le nombre de nœuds dans le réseau, il y a plus de nœuds qui
se trouvent dans la portée influente et ils ne vont pas transmettre leurs paquets redondants. Comme
nous l’avons vu précédemment, les nœuds qui économisent l’énergie en évitant les transmissions
redondantes ne sont pas pré-déterminés. Ce sont les nœuds qui ont perdu le canal lors de l’accès en
66
contention. La consommation d’énergie est bien distribuée à tous les nœuds dans le réseau. Au
contraire, ils ont été choisis aléatoirement parmi les nœuds dans le réseau. La courbe de OBMAC
montre une consommation d’énergie moyenne inférieure par rapport à 802.15.4.
Figure 4.7 - Consommation d’énergie de 802.15.4 et OBMAC
Dans une application de réseau de capteurs de type surveillance, les capteurs sont répartis
aléatoirement. Il peut y avoir des zones où les nœuds sont plus denses et d’autres où ils sont plus
rares. En appliquant OBMAC, les nœuds dans les zones où les capteurs sont peu nombreux ne vont
pas annuler leurs transmissions tandis que les nœuds dans les zones denses vont annuler leurs
transmissions car ceux-ci ont des transmissions redondantes. Nous avons filtré les transmissions
redondantes d’une manière efficace sans affecter le fonctionnement du système. Ainsi, OBMAC
est bien une proposition efficace pour économiser l’énergie dans un réseau de capteurs de type
surveillance.
4.2.4 Variation de la portée influente
Dans les deux résultats de simulation précédents, nous avons utilisé la valeur de la portée influente
qui correspond au seuil α= -90dBm. Comme cette valeur peut affecter le nombre de nœuds qui
utilisent l’écoute passive, nous allons faire varier ce paramètre afin de visualiser l’apport de la
portée influente au résultat de performance du système. Nous changeons la valeur du seuil α de -60
dBm à -90 dBm. Ensuite, nous mesurons la variation du nombre de paquets que les nœuds ont
écouté passivement.
La Figure 4.8 illustre ce résultat d’évaluation de performance. L’axe horizontal donne le nombre de
nœuds. L’axe vertical illustre le nombre de paquets que tous les nœuds ont écouté passivement
dans la portée influente. Nous supposons que ces paquets sont des paquets redondants et il faut les
67
éviter. Chaque courbe dans la Figure 4.8 correspond à la variation du nombre de paquets en écoute
passive selon différentes valeurs de la portée influente α. Pour une valeur de la portée influente,
lorsqu’on augmente le nombre de nœuds, le réseau est plus dense et le nombre de paquets évités est
plus important. Plus le nombre de paquets évités augmente, plus nous pouvons économiser
l’énergie. Le nombre de paquets évités est proportionnel au nombre de nœuds dans le réseau.
Figure 4.8 - Variation de la valeur de portée influente
Cependant, si nous comparons les différentes courbes pour différentes valeurs de la portée
influente, nous trouvons que OBMAC est plus avantageux pour les valeurs α plus petites. C’est un
résultat attendu car une petite valeur de α implique un rayon de portée influente plus grand.
Lorsque la portée influente est plus large, le nombre de nœuds qui se trouvent dans ce rayon est
plus important et ces nœuds vont écouter les paquets passivement afin de vérifier les transmissions
redondantes. Observons la Figure 4.8, nous pouvons constater que la courbe qui correspond à la
valeur α= -90 dBm est la plus avantageuse. Cependant, cela génère également un problème : il y
aura plus de nœuds qui vérifient des transmissions redondantes. De plus, les paquets que les nœuds
ont écoutés passivement ne sont pas toujours des paquets redondants. Si c’est le cas, les nœuds
gaspillent l’énergie pour vérifier des paquets non redondants. Donc, la valeur de la portée influente
joue un rôle important pour le fonctionnement de OBMAC. Ce paramètre est un compromis entre
le nombre de paquets écoutés passivement et l’exactitude des transmissions annulées. En fonction
de chaque type de réseau de capteurs, nous pouvons paramétrer cette valeur afin d’avoir une valeur
optimale.
68
4.2.5 Validation sur les capteurs Silicon
Figure 4.9 - Capteur Silicon
Comme nous venons de le voir dans la partie précédente, la portée influente peut beaucoup
influencer le fonctionnement de OBMAC. Dans cette partie, nous allons analyser la variation de la
puissance du signal reçu en fonction de la distance afin de déterminer la portée influente. Nous
utilisons les capteurs Silicon [91] pour la validation (Figure 4.9). Chaque capteur Silicon est doté
d’un microcontrôleur C8051F121 et d’une antenne transceiveur Chipcon CC2420 [92]. Le
microcontroleur comprend un processeur 8051 à 100 MIPS, une mémoire flash de 128 KOctets et
une mémoire vive de 8KOctets. L’antenne Chipconn CC2420 est composée d’un transceiveur 2.4
GHz et 128 octets FIFO.
Nous mesurons la puissance du signal reçu en faisant varier la distance entre les nœuds. Nous
utilisons 5 capteurs pour effectuer le test. Nous plaçons un nœud comme station de base et 5
capteurs autour de la station de base. Les capteurs envoient les paquets périodiquement et nous
faisons varier la distance de ces capteurs à la station de base. Sur la station de base, nous mesurons
la puissance du signal reçu pour chaque capteur.
Le Tableau 4.2 illustre les résultats de ce test avec 5 capteurs. Observons le tableau, nous trouvons
que la puissance du signal reçu est inversement proportionnelle à la distance entre les nœuds. Pour
le capteur 1, la puissance du signal reçu varie de -17 dBm à -46 dBm avec une distance de 10cm à
160cm. Cela est normal car le signal est atténué lorsqu’il traverse une distance plus longue.
Cependant, ce qui est intéressant dans ces résultats d’expérimentation est que les différents nœuds
réagissent de la même manière en fonction de la distance. Par exemple, avec une distance de 10cm,
69
on reçoit la même valeur de puissance du signal reçu (-17 dBm). De ce fait, nous pouvons utiliser
cette valeur pour évaluer la distance et définir le seuil α pour la portée influente. Par exemple, dans
une application, nous trouvons que les nœuds dans un rayon de 80cm détectent les informations
redondantes. Nous devons définir le seuil α pour que les nœuds qui se trouvent à l’intérieur du
rayon 80cm du transmetteur aillent appliquer le protocole OBMAC. Consultant le Tableau 4.2,
nous trouvons que cette distance correspond à la puissance du signal reçu -38 dBm. Alors, nous
assignons la valeur α = - 38 dBm. Dans ce cas, quand un nœud reçoit un paquet avec la puissance
du signal inférieur à -38 dBm, il sait qu’il n’est pas dans la portée influente et il va se mettre en état
endormi pour économiser énergie. Au contraire, il se met dans l’état actif pour écouter passivement
la transmission afin de vérifier les transmissions redondantes.
Nœud
Distance (cm)
1
2
3
4
5
10
-17
-17
-17
-17
-17
20
-23
-22
-24
-23
-24
40
-26
-27
-27
-28
-27
80
-38
-37
-39
-37
-38
160
-46
-50
-44
-52
-47
Tableau 4.2 - Valeurs de la puissance du signal reçu (dBm) en faisant varier la distance
4.3
Conclusion
Dans cette partie, nous avons présenté et analysé le fonctionnement d’un nouveau protocole
d’accès au médium que l’on a appelé OBMAC. Dans les différents protocoles d’accès au médium
existants [31][33][34][36][47], l’écoute passive est toujours considérée comme une source de
gaspillage d’énergie. Cependant, nous avons démontré que dans certains scénarios de transmission
d’un réseau de capteurs, cette écoute passive peut être une méthode efficace pour économiser la
consommation d’énergie en réduisant les transmissions redondantes. Nous avons raffiné la
proposition de OBMAC avec la nouvelle notion de la portée influente. Nous avons évalué le
protocole OBMAC en le comparant aux protocoles existants et nous avons montré que notre
protocole offre un avantage en terme de la consommation d’énergie. Nous avons mesuré également
la latence des transmissions et nous trouvons que OBMAC offre une faible latence par rapport
autres protocoles d’accès au médium. En appliquant la portée influente, nous garantissons que
seulement les nœuds qui se trouvent dans une petite zone appliquent l’écoute passive. Il n’y a que
70
4.3 Conclusion
les données redondantes qui sont supprimées. Nous recevons toujours quelques messages pour un
évènement. De ce fait, nous garantissons l’exactitude et la tolérance aux fautes du réseau. OBMAC
assure une faible consommation d’énergie dans un réseau de capteurs de type surveillance.
71
Chapitre 5.
pour
Protocole MAC à faible latence
réseaux
de
capteurs
orientés
évènement
Dans le chapitre précédent, nous avons présenté et analysé le protocole d’accès au médium
OBMAC pour les réseaux de capteurs de type surveillance. Dans ce type de réseau de capteurs, le
paramètre le plus important à prendre en compte est la consommation d’énergie. Nous avons
démontré que l’approche de OBMAC peut satisfaire cette condition en réduisant le nombre de
communications redondantes et de ce fait la consommation d’énergie. Cependant, pour les réseaux
de capteurs orientés évènement, le scénario de transmission est différent. Les capteurs envoient
leurs mesures seulement lorsqu’un évènement se produit. Par contre, en condition normale lorsqu’il
n’y a pas d’évènement, les capteurs mesurent les informations ambiantes bien que leur transceiveur
soit éteint. Ils peuvent stocker ces mesures dans la mémoire flash ou supprimer les vielles
informations. Dans les applications critiques (détection d’évènement dans un avion, dans un centre
de production industriel etc.), le critère le plus important à prendre en compte est la latence de
transmission. Lorsqu’un évènement se produit, nous voulons obtenir des informations sur ce qui se
passe dans la zone critique dans le plus bref délai. La consommation d’énergie dans ce type de
réseau est moins importante car ce réseau de capteurs est normalement déployé dans un milieu où il
y a souvent de l’intervention humaine contrairement au réseau de capteurs de type surveillance où
il y a rarement la présence d’êtres humains (sur des îles, au Pôle Nord etc.).
En se basant sur cette approche, nous proposons un protocole d’accès au canal dédié aux réseaux
de capteurs orientés évènement. Nous l’appelons LLMAC (Low Latency MAC) [93], qui est un
protocole MAC à très faible latence de transmission. Nous commençons dans la partie 5.1 du
chapitre en présentant le problème de la latence de transmission pour les protocoles existants
d’accès au canal. Ensuite, dans la partie 5.2 , nous exposons le fonctionnement de LLMAC afin de
résoudre ce problème de la latence de transmission. Pour illustrer l’avantage de LLMAC par
rapport aux autres protocoles existants d’accès au médium, nous utilisons le simulateur OMNet++
dans la partie 5.3 pour simuler un réseau de capteurs orientés évènement. Nous validons notre
proposition avec les capteurs Cyclops pour avoir une vue pratique de notre proposition. Enfin, nous
terminons le chapitre avec un conclusion et des perspectives de LLMAC.
73
Chapitre 5. Protocole MAC à faible latence pour les réseaux de capteurs orientés évènement
5.1
Problème de la latence de transmission dans les
protocoles existants d’accès au médium
Les protocoles existants d’accès au médium pour les réseaux de capteurs de type surveillance
utilisent des méthodes pour économiser l’énergie basées sur le changement du mode de
fonctionnement du transceiveur périodiquement entre l’état actif et l’état endormi. La latence de
transmission est très importante dans ce genre de protocole. En effet, lorsqu’un évènement se
produit, si le capteur est dans l’état endormi et il détecte un évènement, il ne peut pas envoyer les
messages car ces nœuds voisins sont dans l’état endormi. Ce nœud doit attendre jusqu’à la
prochaine période active afin de transmettre ses messages pour cet évènement. Pour une
transmission multi-saut, cette latence est encore plus importante. Les propositions existantes pour
les réseaux de capteurs de type surveillance en utilisant les périodes active/endormi ne sont pas
adaptables aux réseaux de capteurs orientés évènement où on s’intéresse plus à la latence de
transmission.
Pour garantir une faible latence de transmission, il faut que les capteurs soient actifs à tous
moments pour pouvoir transmettre l’évènement à la station de base. Un bon exemple de ce
protocole d’accès au médium qui garantit une faible latence de transmission est IEEE 802.11 [31].
Dans IEEE 802.11, les nœuds sont toujours actifs et ils sont toujours prêts à recevoir ou à
transmettre des données. Pour améliorer la latence de transmission, il y a également quelques
propositions existantes [53][54] que nous avons présentées dans la partie état de l’art. Cependant,
ces propositions sont conçues pour les réseaux de capteurs où il y a une communication directe
entre les capteurs et la station de base. Il n’y a pas la communication multi-saut. Nous allons
montrer, dans cette partie, que dans ces protocoles, il existe toujours le problème de la latence de
transmission pour les communications multi-saut dans un réseau de capteurs orientés évènement.
Nous commençons par la présentation d’un scénario simple de réseau de capteurs orientés
évènement dans la partie 5.1.1 . Ensuite, nous allons analyser un schéma de transmission multi-saut
où nous allons montrer le problème de latence de transmission pour le protocole 802.11.
5.1.1 Topologie d’un réseau de capteurs orientés évènement
Dans un réseau de capteurs orientés évènement, il y a généralement un nombre important de
capteurs déployés sur la zone de détection. La distance entre les capteurs et la station de base est
normalement plus longue que la portée radio de transmission. Donc, pour que les capteurs puissent
envoyer les alertes à la station de base, il faut utiliser des transmissions multi-saut.
La Figure 5.1 illustre un scénario simple de transmission d’un réseau de capteurs orientés
évènement. Dans ce réseau, il y a deux capteurs qui détectent un évènement et deux routeurs qui
74
5.1 Problème de la latence de transmission dans les protocoles existants d’accès au médium
routent les messages vers la station de base. Nous supposons que les nœuds transmettent les
messages vers le nœud le plus proche de la station de base. On veut que le réseau applique un
protocole de routage optimal pour minimiser le nombre de transmissions multi-saut. Pour les
nœuds S1 et S2, le nœud voisin qui est le plus proche de la station de base et qui se trouve dans leur
portée radio, est le routeur G1. Ainsi, les trames de données vont être transmises des capteurs S1 et
S2 vers le routeur G1. Ensuite, le routeur G1 fait suivre les trames de données au routeur G2.
Enfin, le routeur G2 fait suivre les trames de données à la station de base. Bien que le routeur G2
ne se trouve pas dans la portée radio des nœuds S1 et S2, il ne peut pas transmettre simultanément
avec les nœuds S1 et S2 à cause du problème de la station cachée [25]. Plus précisément, si
pendant le temps où le capteur S1 transmet au routeur G1, le routeur G2 transmet à la station de
base, cette transmission va interférer la réception du nœud routeur G1. Dans ce scénario, il y a
seulement un nœud qui a le droit de transmettre, tous les autres doivent rester silencieux. Si deux
nœuds accèdent au canal en même temps, il y aura de collisions. Ainsi les quatre nœuds dans la
Figure 5.1 partagent le médium de transmission alors qu’ils ne sont pas forcément dans la même
portée.
S1
évènement
G1
G2
S2
Station de base
Routeur
Capteur
Figure 5.1 - Scénario de transmission d’un réseau de capteurs orientés évènement
5.1.2 Schéma de transmission multi-saut d’un évènement
Observons le scénario de transmission de la Figure 5.1. Lorsqu’un évènement se produit, deux
capteurs S1 et S2 détectent cet évènement en même temps et veulent envoyer une alerte à la station
de base en même temps via des nœuds routeurs. Dans tous les protocoles d’accès au médium
existants, pour garantir l’équité dans le réseau, tous les nœuds accèdent au canal aléatoirement avec
75
la même probabilité après chaque transmission d’une trame de données. Nous ne pouvons pas
savoir à priori l’ordre de transmission des trames de données dans le réseau.
Comme les nœuds accèdent au canal aléatoirement, il y a différents scénarios de transmission pour
les trames de données. La Figure 5.2 et la Figure 5.3 illustrent les chronologies de transmission
pessimiste et optimiste pour le scénario de transmission de la Figure 5.1. Un scénario de
transmission pessimiste est le cas où on reçoit le premier évènement en plus long délai et un
scénario de transmission optimiste est le cas où on reçoit le premier évènement en plus bref délai.
Dans chaque figure, la transmission d’une trame est illustrée par un rectangle gris et la réception
d’une trame est illustrée par un rectangle blanc. Le numéro dans chaque rectangle représente le
paquet qui vient du nœud avec son identifiant. En observant les deux figures, nous pouvons voir
qu’à un moment donné, il y a seulement un nœud qui transmet et tous les autres doivent rester
silencieux. Une alerte doit être routée par deux nœuds routeurs consécutivement avant d’arriver à la
station de base. Un évènement que nous observons peut être composé de plusieurs paquets de
données : la variation de la température des dernières 10 minutes, une image prise sur une partie
particulière d’une machine ou du son enregistré dans la zone surveillée. Pour ce genre
d’application, nous nous intéressons à la latence de transmission qui est mesurée entre le moment
où l’évènement s’est produit et le moment où la station de base reçoit tous les paquets concernant
un évènement. Pour simplifier, nous supposons que chaque évènement détecté est composé de deux
paquets. Quand un évènement se produit, chaque nœud S1 et S2 détecte cet évènement et envoie à
la station de base deux paquets via deux nœuds routeurs. La transmission de chaque trame de
données prend ∆t temps.
∆t
S1
1
2
S2
G1
1
1
2
2
1
2
1
2
1
1 2
11*∆t
G2
Station de base
1
2
2
1
2
1
2
1
2
1
2
12*∆t
transmission
temps
réception
Figure 5.2 - Chronologie de transmission pessimiste
76
5.1 Problème de la latence de transmission dans les protocoles existants d’accès au médium
∆t
S1
1
1
S2
G1
G2
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
6*∆t
Station de base
12*∆t
transmission
temps
réception
Figure 5.3 - Chronologie de transmission optimiste
En appliquant les protocoles MAC existants basés sur la contention, les nœuds accèdent au canal
aléatoirement. Les nœuds S1, S2, G1, G2 ont la même probabilité d’accès au canal de transmission.
La Figure 5.2 illustre un scénario de transmission pessimiste où la station de base reçoit
l’évènement avec une latence importante. Cette figure illustre le cas où le routeur n’a pas de chance
car il perd toujours le canal lorsqu’il veut accéder au canal en contention avec les nœuds S1 et S2.
Pendant ce temps, les nœuds S1 et S2 accèdent au canal consécutivement. Le nœud routeur G1
reçoit tous les paquets qui viennent des nœuds S1 et S2 avant de gagner le canal pour faire suivre
les paquets au nœud routeur G2. Autrement dit, les paquets sont bloqués aux nœuds routeurs avant
d’être transmis à la station de base. Dans ce scénario pessimiste, la station de base reçoit le premier
évènement envoyé après 11*∆t temps. Elle reçoit la totalité de deux évènements après 12*∆t
temps.
La Figure 5.3 illustre un scénario de transmission optimiste pour la latence de transmission. Après
avoir transmis une trame de données, le capteur S1 continue à occuper le canal jusqu’à la fin de la
transmission de tous ces paquets pour un évènement. Nous voyons que les nœuds transmettent
toujours par blocs de 2 trames, ce qui est la taille équivalente d’un évènement. Comme dans ce cas,
chaque évènement se compose de deux trames, les nœuds transmettent deux trames avant de
commencer une nouvelle période d’accès au canal. Après avoir reçu les trames qui viennent d’un
capteur, un nœud routeur gagne le canal et fait suivre les paquets immédiatement. La Figure 5.3
illustre le cas où le capteur S1 gagne le canal pour transmettre un évènement au nœud routeur G1.
Ensuite, le nœud routeur G1 prend le canal immédiatement pour faire suivre cet évènement au
nœud routeur G2. A son tour, le nœud routeur G2 prend le canal immédiatement et fait suivre les
77
deux trames à la station de base. En appliquant ce scénario, la station de base reçoit le premier
évènement après 6*∆t temps. Ensuite, le capteur S2 commence à transmettre son évènement à la
station de base et cette dernière reçoit le deuxième évènement après 12*∆t temps.
Dans un réseau de capteurs orientés évènement, les capteurs peuvent détecter les données
similaires. Par exemple, deux capteurs d’image sont déployés dans une salle pour surveiller le
fonctionnement d’une machine. Des parties d’images de deux capteurs peuvent être identiques.
Pour certaines applications, nous n’avons pas besoin de recevoir tous les évènements envoyés par
tous les nœuds afin de savoir ce qui se passe sur la zone surveillée. Supposons que lorsqu’un
évènement se produit, N nœuds détectent cet évènement et veulent l’envoyer à la station de base.
La station de base a besoin de recevoir seulement R évènements (R<N) afin d’avoir une bonne
information sur l’évènement dans la zone surveillée. Donc, dans ce type de réseau de capteurs
orientés évènement, la latence de transmission des premiers R (R<N) évènements est le critère le
plus important.
Revenons aux schémas de transmission ci-dessus. Nous avons un réseau de capteurs avec deux
capteurs et deux nœuds routeur. Le nombre d’évènements auquel nous nous intéressons est R=1
(N=2) où chaque évènement se compose de 2 paquets. Dans le scénario optimiste, la station de
base reçoit le premier évènement après 6*∆t ; dans le scénario pessimiste, la station de base reçoit
le premier évènement après 11*∆t, ce qui est presque le double par rapport au scénario optimiste.
En général, la topologie d’un réseau est beaucoup plus large et cela implique des communications
multi-saut plus longues. Chaque évènement peut être composé de plusieurs paquets : une image
prise par les capteurs d’image ou du son enregistré par les capteurs sonores. Dans ces exemples, la
latence du scénario optimiste est beaucoup plus courte que celle du scénario pessimiste.
La cause principale d’une latence importante du scénario pessimiste est que les données sont
bloquées dans les nœuds routeurs et durant ce temps, la station de base n’a aucune information sur
l’évènement. La probabilité d’accès au canal des nœuds routeurs joue un rôle très important pour la
latence des transmissions. Dans les protocoles d’accès au canal par écoute de porteuse, les nœuds
accèdent au canal en contention et avec la même probabilité (pour garantir l’équité). Dans le
schéma de la Figure 5.1, si un des nœuds S1, S2 ou G1 gagne le canal, la station de base ne reçoit
aucune donnée. La probabilité que le nœud routeur G2 gagne le canal est plus basse que la
probabilité qu’un des trois nœuds S1, S2 et G1 gagne le canal (selon la théorie des probabilités).
Donc, la probabilité que les données soient bloquées dans les nœuds routeurs est élevée ce qui
implique une plus grande probabilité du scénario pessimiste par rapport au scénario optimiste.
Nous trouvons que l’équité n’optimise pas la latence de transmission, particulièrement dans les
réseaux de capteurs orientés évènement avec des communications multi-sauts. Afin de réduire la
latence de transmission, nous devons trouver une méthode pour que le scénario de transmission soit
toujours optimiste.
78
5.2 LLMAC : un protocole d’accès au médium à très faible latence
5.2
LLMAC : un protocole d’accès au médium à très
faible latence
Dans cette partie, nous allons présenter le fonctionnement du protocole LLMAC [93], un protocole
d’accès au canal garantissant une faible latence de transmission pour les réseaux de capteurs
orientés évènement. Nous commençons par une introduction du contexte des réseaux de capteurs et
prenons un réseau de capteurs avec les 5 hypothèses ci-dessous :
•
Nous traitons un réseau de capteurs orientés évènement où la latence de transmission est le
critère le plus important.
•
Chaque évènement se compose d’un nombre de paquets importants : une image, du son
etc.
•
Les réseaux sont organisés sous forme d’arbre en utilisant les techniques existantes
[50][84][85]. Lorsqu’un évènement se produit, les capteurs envoient les alertes à la station
de base via les nœuds routeurs.
•
Les capteurs sont dans la même zone et détectent les informations similaires. Lorsqu’un
évènement se produit et que N capteurs l’ont détecté, la station de base a besoin de recevoir
l’information de seulement R capteurs (R<N) afin de savoir ce qui se passe sur la zone
surveillée et d’avoir des réactions appropriées. L’objectif de ce type de réseau est de
recevoir l’information de R nœuds dans le plus bref délai.
•
Les capteurs sont alimentés par des piles et sont sensibles à la consommation d’énergie. La
proposition doit prendre en compte la consommation d’énergie afin d’optimiser la durée de
vie de réseau.
En nous basant sur ces hypothèses, nous proposons LLMAC, un protocole d’accès au médium qui
garantit une faible latence de transmission et une faible consommation d’énergie pour les réseaux
de capteurs orientés évènement. Avec LLMAC, nous garantissons que le scénario optimiste vu
dans la partie précédente est toujours réalisé et de ce fait nous obtenons une latence de transmission
de R évènements dans un délai très bref (sur N évènements détectés). LLMAC fait partie de la
famille des protocoles d’accès au canal basés sur la contention. Les nœuds utilisent la méthode
d’écoute de porteuse pour accéder au canal en évitant les collisions. Dans LLMAC, nous utilisons
également les paquets de contrôle et les intervalles inter-trame afin de différencier la priorité entre
les paquets de contrôle et les paquets de données. En effet, nous améliorons le protocole existant
802.11 afin de mieux l’appliquer aux réseaux de capteurs orientés évènement. La Figure 5.4 illustre
79
le fonctionnement du protocole LLMAC. Nous allons détailler LLMAC dans les parties qui
suivent.
Rafale des trames pour un évènement
DIFS
occupé
FIFS
PIFS
SIF
BO
RTS CTS Trame1
ACK
Trame2
ACK
…
TrameN
ACK
SIFS: Short Interframe Spacing
FIFS: Forward Interframe Spacing
PIFS: PCF Interframe Spacing
DIFS: Distributed Interframe Spacing
Figure 5.4 - Fonctionnement de LLMAC
5.2.1 Transmission niveau évènement
Dans un protocole d’accès au canal par écoute de porteuse, les nœuds écoutent le canal avant d’y
accéder. Si un nœud perd le canal, il doit attendre jusqu’à la fin de la transmission du nœud
gagnant. En effet, le nœud gagnant doit lâcher le canal et retenter d’accéder au canal après chaque
transmission d’une trame de données. Cela évite l’occupation du canal indéfiniment. En plus, il
permet aux autres nœuds d’accéder au canal et de garantir l’équité entre les nœuds. Comme le
médium de transmission est un dispositif commun, l’équité donne la même probabilité d’accès au
canal à tous les nœuds. Le critère de l’équité répond au besoin de partage de médium des réseaux
sans fil traditionnel où les nœuds ont des scénarios de transmission différents. Dans un réseau de
capteurs, tous les nœuds coopèrent pour faire un seul scénario de transmission : router des
messages de capteurs vers la station de base. Donc, le critère d’équité ne s’adapte pas aux réseaux
de capteurs orientés évènement car nous nous sommes intéressés par la latence de transmission
d’un évènement mais pas une trame de donnée.
La latence de transmission pour un évènement est l’intervalle de temps entre le moment où
l’évènement se produit et le moment où la station de base reçoit l’information de cet évènement. Si
un évènement se compose de P trames de données, la station de base n’a aucune information si elle
ne reçoit pas les P trames. Supposons qu’un capteur d’image envoie une photo de taille 1Moctets
de type jpeg à la station de base, si la station de base reçoit 0.9Moctets, elle ne peut pas visualiser
l’image pour comprendre ce qui se passe sur la zone de surveillance. Donc, le critère le plus
important dans ce genre d’application est la transmission de P trames d’un évènement pour un
nœud quelconque avec la latence la plus courte. Nous proposons une règle de transmission de
LLMAC du niveau évènement.
Règle 5.1 : Après avoir gagné le canal, un nœud continue à transmettre ses trames de données
jusqu’à ce que toutes les trames concernant un évènement soient transmises.
80
Dans LLMAC, nous voulons qu’un nœud puisse terminer sa transmission concernant un évènement
avant de relâcher le canal. La Figure 5.4 illustre ce niveau de transmission. Après avoir reçu un
évènement sur l’information ambiante, un capteur veut transmettre cet évènement à la station de
base. Il commence par tenter d’accéder au canal. S’il gagne le canal, il échange tout d’abord les
paquets RTS/CTS avec le nœud récepteur (la station de base dans le cas d’une transmission un-saut
et un nœud routeur dans le cas d’une transmission multi-saut). Lorsqu’il reçoit la permission du
nœud récepteur, il commence à transmettre sa première trame de données sur l’évènement. Cette
trame de données se termine par un accusé de réception du nœud récepteur. Dans LLMAC, au lieu
de relâcher le canal après la transmission de cette trame de données, ce nœud continue à
transmettre une rafale de trames de données. Les autres nœuds ne peuvent pas interrompre cette
transmission car ce nœud continue de transmettre avant l’expiration de l’intervalle DIFS. Cette
rafale de trames peut se composer de plusieurs informations ambiantes : température, vibration,
image, sons, etc. La longueur de cette rafale de trame est équivalente à la longueur d’un évènement.
La transmission de ce nœud se termine lorsqu’il termine la dernière trame de son évènement. En
appliquant LLMAC, lorsqu’un nœud gagne le canal, nous pouvons assurer qu’il peut envoyer son
évènement dans le délai le plus court. Selon chaque type d’application, le nombre de trames par
évènement est différent et c’est un paramètre du protocole d’accès au médium.
En effet, en utilisant une rafale de transmissions pour un nœud, les autres nœuds perdent le droit
d’accès au canal pendant la transmission de cette rafale de données. Nous ne pouvons pas garantir
l’équité entre les nœuds. Cependant, nous constatons que dans les réseaux de capteurs, les nœuds
coopèrent pour atteindre un seul objectif qui est de router les messages à la station de base. Ils ne
fonctionnent pas d’une manière indépendante comme le cas d’un réseau sans fil traditionnel et
l’équité est peu importante. Dans LLMAC, en changeant la transmission du niveau trame de
données au niveau évènement, nous avons fait un compromis entre l’équité et la latence des
évènements. Comme la latence est le critère le plus important dans ce type de réseau, il est
préférable de pénaliser l’équité pour obtenir une latence plus faible pour chaque évènement. La
solution de LLMAC est bien adaptée pour les réseaux de capteurs orientés évènement.
5.2.2 Intervalle Inter-trame de Continuité (Forward Inter-frame
Spacing)
En utilisant la règle 5.1 pour transmettre une rafale de trames de données, nous pouvons garantir
une faible latence de transmission pour un évènement dans la configuration un-saut (transmission
directe à la station de base). Cependant, un réseau de capteurs orientés évènement aura des
transmissions multi-saut. Après chaque transmission de niveau évènement, un nœud réussit à
transmettre cet évènement au nœud routeur. A la fin de la transmission, tous les nœuds dans leur
portée radio tentent d’accéder au canal. Si un autre capteur gagne le canal et fait suivre un autre
évènement dans le nœud routeur, ces évènements sont tous bloqués au nœud routeur. La règle 5 .1
n’améliore pas la latence de transmission dans cette situation car durant le temps où les évènements
81
sont bloqués dans les nœuds routeur, la station de base n’a aucune information sur l’évènement
dans la zone surveillée.
Dans le fonctionnement de 802.11, tous les nœuds utilisent le même intervalle DIFS et la même
valeur de fenêtre de contention afin de garantir l’équité. Cette équité augmente la probabilité que
les capteurs gagnent le canal et les évènements sont bloqués au nœud routeur car le nombre de
nœuds capteurs qui veulent transmettre est plus nombreux que le nombre de nœuds routeurs.
Afin de résoudre ce problème, nous devons nous assurer que le nœud routeur peut gagner le canal
immédiatement après avoir reçu un évènement. Dans ce cas, les évènements sont envoyés en multisaut et ne sont pas bloqués aux nœuds routeurs. Dans LLMAC, nous définissons un nouvel
intervalle inter-trame que nous l’appelons FIFS (Forward Inter-frame Spacing). Cet intervalle est
illustré dans la Figure 5.4, il est plus court que DIFS et plus long que SIFS et PIFS.
Règle 5.2 : Après avoir reçu un évènement, le nœud routeur accède au canal après l’expiration de
l’intervalle inter-trame de continuité (FIFS).
Selon le fonctionnement de 802.11, nous savons que les intervalles inter-trame servent à distinguer
les niveaux de priorités pour accéder au canal. Le SIFS est utilisé pour les paquets de contrôle car
ces derniers ont la priorité la plus élevée. Lorsque deux nœuds échangent les paquets de contrôle,
aucun nœud ne peut intercepter cette transmission car ces deux nœuds utilisent l’intervalle intertrame le plus court. Les autres nœuds commencent la période de contention après DIFS. Dans le
cas normal de 802.11, à la fin de chaque transmission d’une trame de données, tous les nœuds
attendent la fin de DIFS et commencent la période de contention. Chaque nœud choisit une valeur
aléatoire dans la fenêtre de contention. Donc, ils ont la même probabilité pour accéder au canal. Si
le nœud routeur perd le canal, il sera toujours le récepteur et recevra encore un autre évènement.
En utilisant la règle 5.2, le nœud routeur peut accéder au canal après l’expiration de FIFS. En fixant
la valeur de FIFS plus courte que DIFS, nous donnons la priorité d’accès au canal pour le nœud
routeur. Comme tous les nœuds accèdent au canal après DIFS, le nœud routeur peut accéder au
canal avant tous les autres. Lorsqu’un nœud reçoit une trame de données pour un évènement, il
vérifie s’il doit faire suivre cette trame de données à la station de base (un scénario typique d’un
réseau de capteurs). Si c’est le cas, il va mettre son intervalle intertrame à FIFS à la fin de la
réception de l’évènement. Ceci donne la priorité au nœud routeur pour accéder au canal après avoir
reçu toutes les trames de données pour un évènement. Lorsque le transmetteur termine sa
transmission d’un évènement, tous les nœuds tentent d’accéder au canal après DIFS sauf le nœud
routeur qui possède le FIFS. Quand FIFS expire, le nœud routeur peut faire suivre l’évènement
immédiatement. Il peut transmettre sans collision avec les autres nœuds car il occupe le canal avant
que les autres commencent la période de contention. Lorsque ce nœud routeur termine sa
transmission, il remet son intervalle inter-trame à DIFS comme tous les nœuds normaux. Le nœud
82
suivant devient le nœud routeur pour l’évènement et il va mettre son intervalle inter-trame à FIFS
pour avoir une priorité supérieure que les autres nœuds. Cette méthode garantit qu’il n’y a qu’un
seul nœud dans la zone influencée par le problème de la station cachée possédant la priorité de
FIFS. Ce processus est répété jusqu’à ce que l’évènement arrive à la station de base. Il réalise un
effet de vague où la priorité circule au cours de la transmission des nœuds capteurs jusqu’à la
station de base. La règle 5.2 garantit qu’un évènement n’est jamais bloqué au nœud routeur et peut
être envoyé en multi-saut avec une latence plus faible.
5.2.3 Economie d’énergie
Dans les deux parties précédentes, nous avons décrit le fonctionnement de LLMAC en prenant en
compte la latence de transmission pour les évènements dans les réseaux de capteurs orientés
évènement. Nous avons également mentionné que les méthodes d’accès au canal en mettant les
nœuds dans l’état actif et endormi périodiquement, ne sont pas adaptables pour les réseaux de
capteurs orientés évènement car cela augmente la latence de transmission. C’est pour cette raison
que nous avons proposé que les transceiveurs des nœuds soient toujours dans l’état actif pour que
les nœuds soient toujours prêts à transmettre. Cependant, cette méthode gaspille beaucoup énergie
car la plupart du temps, les nœuds sont dans l’état écoute non-active pour attendre une éventuelle
transmission [33][34]. Comme un réseau de capteurs se compose de plusieurs nœuds avec une
capacité d’énergie limitée, nous avons besoin d’une méthode afin de garantir toujours une faible
latence et une consommation d’énergie faible afin de prolonger la durée de vie. Dans cette section,
nous allons discuter le problème de la consommation d’énergie et nous allons décrire une méthode
efficace pour économiser l’énergie dans LLMAC.
Afin de mieux faire comprendre notre proposition, nous analysons le scénario de transmission avec
la topologie illustrée dans la Figure 5.1. En utilisant les deux règles 5.1 et 5.2, nous assurons que
lorsqu’un évènement se produit, la station de base reçoit les premiers évènements avec la latence la
plus faible. Donc, nous sommes sûrs que le scénario de transmission suit toujours le scénario
optimiste de la Figure 5.3. Observons cette figure, nous constatons que le capteur S2 ne peut pas
accéder au canal pendant le temps où le nœud S1 transmet son évènement au nœud routeur G1 et le
temps où les nœuds routeurs G1 et G2 font suivre l’évènement à la station de base. La règle 5.1
donne au capteur S1 le droit d’occuper le canal pendant le temps de la transmission de son
évènement. La règle 5.2 donne aux deux nœuds routeurs G1 et G2 la priorité pour gagner le canal
juste après la transmission de S1. Le capteur S2 ne peut pas accéder au canal car il utilise un
intervalle intertrame plus long que le nœud routeur. Le capteur S2 se trouve dans la portée de
transmission de S1 et G1, il ne peut pas transmettre durant la transmission du capteur S1 et du
routeur G1. Même lorsque le routeur G2 transmet, le capteur S2 ne peut pas transmettre car le
routeur G1 est dans la portée radio du routeur G2. Cela à cause du problème de la station cachée
[25] que nous avons mentionné dans les parties précédentes. Pour la même raison, le capteur S1 ne
peut pas accéder au canal durant le temps où les routeurs G1 et G2 font suivre son évènement à la
83
station de base même s’il a encore d’autres évènements à envoyer. Pour les capteurs S1 et S2,
quand ils ne peuvent pas accéder au canal, il serait préférable de mettre leur transceiveur dans l’état
endormi pour économiser l’énergie. Partant de cette observation, nous proposons les règles 5.3 et
5.4 pour le protocole LLMAC afin d’économiser l’énergie.
Règle 5.3 : Les capteurs se réveillent si et seulement si, ils détectent un évènement.
Règle 5.4 : Après avoir perdu ou relâché le canal, un capteur dort durant le temps où l’évènement
est transmis dans les deux sauts suivants.
Dans un réseau de capteurs orientés évènement, il y a souvent deux types de nœuds : les capteurs et
les routeurs. Les capteurs mesurent des informations ambiantes et envoient leur mesure à la station
de base via des nœuds routeurs. Ils ne doivent pas router les données pour les autres nœuds. Les
nœuds routeurs peuvent mesurer des informations ambiantes et router les données pour les autres
nœuds. Dans le scénario de transmission de la Figure 5.1, les capteurs S1 et S2 sont toujours dans
l’état actif même s’ils n’ont pas d’évènement à envoyer. En plus, durant le temps où les routeurs
G1 et G2 font suivre un évènement, les capteurs S1 et S2 ne peuvent pas accéder au canal.
Comme l’opération de transceiveur est une activité qui est plus coûteuse en terme de
consommation d’énergie, la règle 5.3 aide les nœuds capteurs à économiser l’énergie car les
capteurs se réveillent si et seulement si, ils détectent un évènement. En effet, les nœuds capteurs
peuvent s’endormir pendant tout le temps car ils ne doivent pas router les données pour les autres.
Ils activent seulement la carte “senseur” pour capter des informations ambiantes. Ces mesures sont
comparées avec un seuil afin de savoir s’il y a un évènement. Un évènement peut être : la
température qui dépasse une certaine valeur ; la lumière qui n’est pas suffisamment intense, le
niveau de vibration qui est trop élevé, etc. Selon le type d’application, ces informations sont
stockées dans la mémoire locale ou effacées pour libérer la mémoire. Nous constatons que les
nœuds capteurs ne consomment pas beaucoup l’énergie car l’opération de mesure de la carte
senseur n’est pas coûteuse en terme de consommation d’énergie. Les capteurs consomment
l’énergie seulement lorsqu’ils détectent un évènement et activent leur transceiveur. Ils se mettent
dans l’état endormi lorsqu’ils ont transmis leur évènement à la station de base.
Lorsqu’un nœud capteur veut accéder au canal en contention, il n’est pas sûr de pouvoir accéder au
canal immédiatement car il se peut qu’un autre nœud occupe déjà le canal. Normalement, quand les
capteurs n’arrivent pas encore à transmettre leur évènement, ils restent toujours dans l’état actif.
Cependant, nous avons vu que durant le temps où l’évènement est transmis par les nœuds routeurs,
les capteurs ne peuvent pas accéder au canal. La règle 5.4 permet aux nœuds capteurs d’économiser
l’énergie dans ce cas en mettant leur transceiveur dans l’état endormi durant le temps où
l’évènement est transmis dans les deux nœuds routeurs suivants.
84
La Figure 5.5 illustre comment les capteurs peuvent économiser l’énergie en utilisant les règles 5.3
et 5.4. Avant qu’un évènement se produit, tous les capteurs S1 et S2 sont dans l’état endormi (règle
5.3). Ils font des mesures pour détecter un évènement. Ils se réveillent lorsqu’ils trouvent un
évènement. Dans ce cas, les deux nœuds S1 et S2 sont en contention pour accéder au canal.
Supposons que le capteur S1 gagne le canal et fasse suivre l’évènement au nœud routeur G1. Cet
évènement est transmis comme le suivant : S1 → G1 → G2 → SdB. Supposons que ∆T soit le
temps de transmission pour un évènement. En appliquant la règle 5.4, le capteur S2 sait qu’il ne
peut pas accéder au canal pendant 3∆T : la transmission du nœud capteur S1 et des deux routeurs.
Donc, il se met en veille pendant 3∆T pour économiser l’énergie. Il se réveille après cette période
afin de retenter d’accéder au canal. Pour le nœud S1, après avoir transmis son évènement, il doit
attendre que son évènement soit transmis dans les deux sauts suivants. Il ne peut pas accéder au
canal pendant 2∆T. Alors, il se met en veille pendant 2∆T pour économiser l’énergie s’il a encore
d’autre évènement à envoyer. Sinon, il reste dans l’état endormi en utilisant la règle 5.3. Une fois
que l’évènement est transmis, tous les capteurs reviennent à l’état endormi pour économiser
l’énergie en utilisant la règle 5.3.
Un évènement se produit
S1
S2
endormi = 2∆T
endormi
période de
contention
endormi
Se reveille s’il a encore
des évènements
endormi = 3∆T
endormi
endormi
G1
G2
Sink
temps
transmission
réception
Figure 5.5 - Economiser l’énergie dans LLMAC
Les deux règles 5.3 et 5.4 permettent aux nœuds capteurs d’économiser l’énergie mais pas aux
nœuds routeurs. Nous ne pouvons pas mettre les nœuds routeurs dans l’état endormi car ils ne
savent pas quand ils vont recevoir un éventuel évènement envoyé par les capteurs. Nous avons
plusieurs scénarios pour fournir l’énergie aux nœuds routeurs d’une manière efficace. Prenons
l’exemple du train TGV où nous voulons déployer des capteurs pour mesurer le fonctionnement
des moteurs. Les capteurs sont obligés d’être petits et consommer peu d’énergie car ils sont
85
déployés sur le moteur où nous ne pouvons pas faire des interventions souvent. Les nœuds routeurs
servent juste à router les évènements, ils peuvent être branchés sur une prise électrique quelconque
dans une voiture pour avoir de l’énergie. Il faut seulement économiser l’énergie pour les nœuds
capteurs, et ce problème est résolu par les règles 5.3 et 5.4.
En appliquant ces deux règles avec LLMAC, nous pouvons économiser l’énergie pour les nœuds
capteurs et prolonger leur durée de vie. En plus, nous constatons que la latence des transmissions
est toujours optimale car nous mettons les capteurs dans l’état endormi seulement quand ils n’ont
pas d’évènement à envoyer ou qu’ils ne peuvent pas accéder au canal. LLMAC est un bon candidat
pour les protocoles d’accès au médium dans le cas de réseaux de capteurs orientés évènement où il
y a des communications multi-saut. La station de base reçoit toujours les premiers évènements de
la zone surveillée avec la plus faible latence. De plus, LLMAC est efficace en terme de
consommation d’énergie.
5.3
…
N capteurs
H sauts
Station de base
Routeur
Capteur
Figure 5.6 - Topologie de simulation
Dans cette partie, nous allons prouver l’efficacité de notre proposition LLMAC par rapport à IEEE
802.11. Comme LLMAC est développé pour les réseaux de capteurs orientés évènement, le critère
le plus important à prendre en compte est la latence de transmission de R premiers évènements (sur
N évènements détectés). La consommation d’énergie est également prise en compte mais en critère
86
secondaire. Comme le protocole OBMAC présenté dans la partie précédente, nous utilisons
OMNet++ [86] et les modules complémentaires [89][90] pour valider notre proposition LLMAC.
5.3.1 Scénario de simulation
Nous simulons un réseau de capteurs multi-saut orientés évènement avec la topologie illustrée dans
la Figure 5.6. Lorsque les capteurs détectent la présence d’un évènement, N capteurs envoient leur
mesure à la station de base via H sauts. Chaque mesure pour un évènement se compose de P trames
de données. La taille de chaque trame de données correspond à la taille maximale d’une trame de
donnée de 802.11. Tous les autres paramètres sont identiques à la norme 802.11. La valeur de
l’intervalle intertrame FIFS est la valeur moyenne entre SIFS et DIFS. Une liste des paramètres
importants de simulation est illustrée dans le Tableau 5.1.
500 x 500
Nombre de nœuds
1-32
Nombre de sauts
1-5
Nombre de trames par évènement
1-24
SIFS
10E-6 s
FIFS
30E-6 s
DIFS
50E-6 s
Energie un pile AA
2900 mAh
Processeur (Actif/Endormi)
8mA / 15µA
RF transceiveur (Tx/ Rx/ Endormi)
27mA/ 10mA/ 1µA
Temps de simulation
10s
Tableau 5.1 - Paramètre de simulation
Le réseau est déployé aléatoirement dans un rectangle de taille 500x500. Chaque capteur utilise les
caractéristiques d’un capteur Mica2 [10]. Pour illustrer, nous simulons un évènement composé
d’une image envoyée par un capteur d’image Cyclops [95]. Un capteur d’image Cyclops est une
caméra spéciale qui fonctionne en faible consommation d’énergie. Pour la transmission sans fils, ce
type de capteurs fournit une interface qui permet d’utiliser le transceiveur des capteurs Mica2. La
Figure 5.7 montre une caméra Cyclops branchée sur un capteur Mica2.
Les photos prises par la caméra Cyclops sont transmises via un connecteur à la mémoire du capteur
Mica2. Ensuite, le capteur Mica2 utilise son transceiveur pour faire suivre les photos à la station de
base ou à un nœud routeur quelconque. Une caméra Cyclops peut donner plusieurs résolutions
87
différentes : 32x32, 64x64 et 128x128 pixels. La Figure 5.8 illustre des images prises par le capteur
Cyclops sur une chaine de transfert au sein du laboratoire Automatique et Système MicroMécatronique (AS2M). Pour chaque résolution, nous pouvons obtenir une image en monochrome
ou en couleur. Comme chaque image est de type bitmap, la taille d’une image de qualité maximum
est 128*128*3 = 48Koctets (un pixel en couleur est représenté par trois octets correspondants à
trois couleurs : rouge, vert, bleu). Comme la taille maximale d’une trame de données de 802.11 est
2KOctets, le nombre de trames pour l’évènement est 48/2 = 24 trames.
Figure 5.7 - Caméra Cyclops branchée sur Mica2
64x64
128x128
32x32
Figure 5.8 - Exemples des images prises par le capteur Cyclops
En utilisant le scénario de simulation ci-dessus, nous allons faire varier les paramètres afin de voir
la performance de LLMAC dans des conditions différentes. Comme LLMAC est une extension de
88
802.11, nous comparons la performance de 802.11 et LLMAC afin de bien montrer l’efficacité de
notre proposition.
5.3.2 Variation du nombre R d’évènements
Dans le premier résultat de simulation, nous nous intéressons à la latence de la transmission des R
premiers évènements. Comme nous l’avons constaté dans les parties précédentes, dans un réseau de
capteurs orientés évènement, nous nous intéressons seulement aux R premiers évènements transmis
à la station de base mais pas à tous les évènements détectés par les N capteurs.
Figure 5.9 - Latence en faisant varier la valeur R
La Figure 5.9 illustre la latence de transmission depuis le moment où l’évènement se produit
jusqu’au moment où la station de base reçoit R évènements. Pour cette simulation, nous fixons le
nombre de sauts H=3 ce qui correspond à la limite du problème de la station cachée. Lorsqu’un
évènement se produit, 12 capteurs prennent une image de taille maximum (128x128 pixels ~
48KOctets) et l’envoient à la station de base. Observons les deux courbes de latence de
transmission entre LLMAC et 802.11. Nous voyons que LLMAC garantit toujours une faible
latence par rapport à 802.11 dans tous les cas. LLMAC est plus avantageux lorsque la valeur R est
petite. Lorsqu’il y a plusieurs nœuds dont certains sont routeurs, LLMAC donne la priorité aux
nœuds routeurs qui font router un évènement en direction de la station de base. Par contre dans
802.11, tous les nœuds sont en contention pour chaque trame de données. Lorsqu’on augmente la
valeur de R, le résultat de LLMAC se rapproche de ceux de 802.11. Cependant, même dans le cas
d’une transmission complète où tous les évènements sont envoyés à la station de base (R=N),
LLMAC donne toujours un meilleur résultat par rapport à 802.11. Cela est expliqué par le fait que
LLMAC utilise seulement un échange de paquet RTS/CTS pour la transmission d’un évènement
tandis que 802.11 utilise un échange de paquet RTS/CTS pour la transmission de chaque trame de
89
données. De ce fait, nous réduisons le surcoût des paquets de contrôle dans LLMAC et la latence
de transmission de LLMAC est toujours améliorée. Cependant, n’oublions pas que nous sommes
dans un réseau de capteurs orientés évènement, et que nous nous sommes intéressés seulement à
une petite valeur de R. Dans ce cas, nous voyons que LLMAC est très avantageux par rapport à
802.11.
5.3.3 Variation du nombre d’évènements détectés
Dans le modèle de simulation utilisé de la Figure 5.6, il y a N capteurs qui détectent chacun un
évènement. Donc, le nombre d’évènements détectés est identique au nombre de capteurs. En
faisant varier le nombre de capteurs du réseau, nous obtenons des résultats de performance
différents. Dans cette simulation, nous allons voir l’influence de ce paramètre (nombre de nœuds)
en faisant varier de 1 à 32 capteurs. Nous nous intéressons à la latence de transmission du premier
évènement (R=1).
Figure 5.10 - Latence en faisant varier le nombre de nœuds capteurs
Observons la figure ci-dessus, nous voyons que la latence de transmission pour le premier
évènement de LLMAC reste presqu’une valeur constante. Cependant, lorsqu’on augmente le
nombre de capteurs dans le réseau, la latence de transmission de 802.11 augmente rapidement. En
effet, quand il y a seulement un capteur dans le réseau, lorsqu’il détecte un évènement, il envoie cet
évènement à la station de base via des nœuds routeurs sans contention (il y a seulement un nœud
qui veut transmettre). Donc, LLMAC et 802.11 donnent le même résultat de latence de
transmission. Lorsqu’on augmente le nombre de capteurs, le nombre de nœuds qui veulent
transmettre augmente et le niveau de congestion est plus élevé. Dans 802.11, les trames de données
ont tendance à être bloquées aux nœuds routeurs avant d’être transmises à la station de base. Dans
LLMAC, les nœuds travaillent d’une manière coopérative, si un nœud ne gagne pas le canal, il
90
laisse le canal de transmission pour les nœuds voisins et les nœuds routeurs pour transmettre un
évènement. Nous garantissons toujours une faible latence de transmission jusqu’à la station de base
pour les premiers évènements. Au contraire de LLMAC, dans 802.11, lorsqu’on augmente le
nombre de nœuds dans le réseau, le nombre de nœuds qui veulent transmettre augmente, le niveau
de congestion est plus élevé. Alors, les nœuds rentrent en contention pour accéder au canal et
transmettre les données. Il faut plus de temps pour que la station de base reçoive le premier
évènement.
5.3.4 Variation du nombre de sauts vers la station de base
Comme nous l’avons précisé dans les parties précédentes, LLMAC est conçu principalement pour
un réseau de capteurs multi-saut. Il diffère des solutions existantes [53][54] où les auteurs se sont
intéressés à la latence de transmission de chaque trame pour un saut. Pour le problème de la station
cachée, les nœuds situés à deux sauts ne peuvent pas transmettre en même temps. Pour mieux
illustrer l’avantage de LLMAC par rapport à 802.11, nous simulons un scénario de transmission
multi-saut en faisant varier le nombre de sauts de 1 à 5 sauts.
Figure 5.11 - Latence en faisant varier le nombre de sauts à la station de base
La Figure 5.11 présente ce résultat d’évaluation en prenant en compte la latence de transmission
pour le premier évènement. Dans cette figure, nous voyons que LLMAC offre toujours un meilleur
résultat par rapport à 802.11 en terme de latence de transmission. Même dans le cas d’un scénario
de transmission un-saut où chaque nœud a une transmission directe à la station de base, la latence
de transmission de LLMAC est 4 fois moins que celle de 802.11. Cela est évident car dans 802.11,
tous les nœuds sont en contention pour accéder au canal après chaque transmission d’une trame de
données. Dans LLMAC, le canal est pris par un nœud durant le temps de transmission de toutes les
trames pour un évènement. Nous obtenons donc une plus faible latence de transmission pour le
premier évènement.
91
Lorsqu’on augmente le nombre de sauts vers la station de base, la contention est augmentée car il y
a également les nœuds routeurs qui veulent accéder au canal. Comme les nœuds routeurs sont
moins nombreux, la probabilité que les trames de données soient bloquées aux nœuds routeurs est
plus importante dans 802.11. Dans LLMAC, nous donnons la priorité de transmission aux nœuds
routeurs, et de ce fait nous éliminons le cas où l’évènement est bloqué sur les nœuds routeurs.
Donc, lorsqu’on augmente le nombre de sauts, LLMAC donne toujours la meilleure latence de
transmission pour le premier évènement.
5.3.5 Variation du nombre de trames par évènement
Dans un réseau de capteurs orientés évènement, un évènement peut se composer d’une image, du
son etc. Comme nous voulons simuler un évènement par un capteur d’image Cyclops, nous faisons
varier la taille d’une image avec différentes résolutions (32x32 pixels à 128x128 pixels) où chaque
image peut être en monochrome ou en couleur. Ce paramètre est configurable au niveau du
protocole d’accès au médium
Figure 5.12 - Latence en faisant varier le nombre de trames par évènement
La Figure 5.12 illustre la latence de transmission en faisant varier le nombre de trames par
évènement correspondant à différents résolutions de capteurs d’image Cyclops. Lorsque l’image
est petite (il s’agit d’une trame de donnée par évènement), nous ne voyons pas nettement la
différence de latence de transmission entre les deux protocoles d’accès au médium. Lorsqu’on
augmente la résolution et la qualité d’image, le nombre de trame de données par évènement
augmente. Nous voyons que la latence de transmission augmente dans les deux protocoles. C’est
un comportement normal car il faut plus de temps pour transmettre un volume de données plus
important. Cependant, la latence de transmission pour le premier évènement de 802.11 augmente
beaucoup plus vite que LLMAC. En effet, dans 802.11, plus on augmente le nombre de trames par
évènement, plus les trames sont bloquées sur les nœuds routeurs avant d’arriver à la station de
92
base. Dans LLMAC, même si on augmente le nombre de trames par évènement, il n’y a pas de
trames de données bloquées sur les nœuds routeurs. Toutes les trames de données pour un
évènement sont transmises en multi-saut à la station de base avec la plus faible latence. Pour une
image 128x128 pixels en couleur (24 trames), LLMAC donne une latence 7 fois plus faible que
802.11 pour le premier évènement. Plus on augmente le nombre de trames de données par
évènement, plus LLMAC est avantageux.
5.3.6 Fiabilité
Lorsqu’un évènement se produit, plusieurs nœuds sont en contention pour accéder au canal
simultanément. Cela augmente le niveau de congestion dans le réseau. Si un nœud ne gagne pas le
canal après un certain nombre d’essais pour accéder au canal, il va abandonner sa transmission et la
station de base ne reçoit jamais cette trame de données. Dans la simulation de la Figure 5.13, nous
allons analyser cet aspect en montrant le pourcentage d’évènements reçus à la station de base. Un
évènement est arrivé à la station de base quand cette dernière reçoit toutes les trames de données
concernant cet évènement.
Figure 5.13 - Pourcentage d’évènement reçu
Dans cette figure, l’axe horizontal illustre le nombre d’évènements détectés. Rappelons que c’est
également le nombre de nœuds capteurs dans le réseau car nous simulons le fait que chaque capteur
détecte un évènement et veut l’envoyer à la station de base en multi-saut. L’axe vertical illustre le
pourcentage d’évènement que la station de base reçoit. Lorsque le nombre de nœuds capteurs dans
le réseau est faible, il n’y a pas beaucoup de congestion et tous les évènements sont transmis à la
station de base sans perte de données avec 802.11 et LLMAC. Quand le nombre de nœuds qui
veulent transmettre un évènement augmente jusqu’à 4, il y a des pertes de données. Dans ce cas, le
protocole 802.11 garantit seulement la moitié du nombre d’évènements qui arrivent à la station de
base, tandis que LLMAC garantit 100% d’évènements qui arrivent. Lorsqu’on augmente le nombre
93
de nœuds capteurs, la congestion est plus élevée et nous ne pouvons pas assurer que tous les
évènements soient transmis à la station de base. En faisant varier le nombre d’évènements détectés
de 8 à 32, le pourcentage d’évènement reçu par la station de base diminue car la congestion est plus
élevée et il y a plus de transmissions qui terminent en collision. En plus, après un certain nombre
d’essais pour accéder au canal, si un nœud ne peut pas gagner le canal, il va abandonner la
transmission pour cette trame, et la station de base ne reçoit jamais cet évènement. Nous avons vu
que dans LLMAC, nous donnons la priorité de transmission aux évènements et réduisons la
congestion du réseau. Ainsi, LLMAC génère moins de collisions dans le réseau et permet d’obtenir
de meilleures performances (en pourcentage de réception) par rapport à 802.11.
5.3.7 Consommation d’énergie
Dans les résultats de simulation précédents, nous avons montré que LLMAC donnait une latence de
transmission plus faible que le protocole 802.11 dans presque tous les cas. Comme nous avons
aussi donné une méthode pour améliorer la consommation d’énergie, nous allons montrer son
efficacité dans la suite. Nous allons mesurer la consommation d’énergie de chaque nœud capteur
individuel et donner la somme totale de l’énergie consommée de tous les capteurs.
La Figure 5.14 illustre la consommation d’énergie pour 16 nœuds capteurs. Nous voyons les
différents niveaux de consommation d’énergie pour chaque nœud car il y a des nœuds qui doivent
essayer de transmettre plusieurs fois, tandis qu’il y a des autres qui peuvent gagner le canal
rapidement. Observons la figure, les nœuds qui utilisent LLMAC consomment toujours moins
d’énergie que 802.11. Dans LLMAC, les nœuds se mettent dans l’état endormi après la
transmission d’un évènement (nous simulons que chaque nœud veut transmettre un évènement).
Lorsqu’un nœud perd le canal, il se met en veille pendant 3 fois plus de temps qu’il faut pour
transmettre un évènement. C’est le temps de transmission d’un évènement par un capteur et son
routage dans deux nœuds suivants. Comme 802.11 ne propose pas des méthodes pour économiser
l’énergie dans le mode DCF (technique pour les réseaux ad-hoc), nous pouvons facilement montrer
que la consommation d’énergie de 802.11 est plus élevée que LLMAC dans chaque nœud. Mais,
nous ne voyons pas une grande différence car nous mesurons la consommation d’énergie seulement
durant la transmission d’un évènement. Si nous simulons la consommation d’énergie pendant une
longue période, alors nous allons voir une différence très importante car les capteurs en utilisant
LLMAC s’endorment tout le temps tandis que les capteurs en utilisant 802.11 ne s’endorment
jamais. Ainsi, ils consomment beaucoup d’énergie en mode d’écoute non-active.
Ce résultat d’évaluation a été réalisé avec 16 capteurs composant le réseau. Comme le nombre de
capteurs joue un rôle important pour le fonctionnement du réseau, nous allons comparer la
consommation d’énergie globale de LLMAC et 802.11. Nous prouvons que dans différents
scénarios, en faisant varier le nombre de capteurs, nous garantissons toujours un niveau de
consommation d’énergie plus faible dans LLMAC par rapport à 802.11.
94
Figure 5.14 - Consommation d’énergie de chaque nœud avec N = 16
Figure 5.15 - Consommation d’énergie totale en faisant varier N
La Figure 5.15 illustre ce résultat d’évaluation. L’axe horizontal donne le nombre de nœuds
capteurs. L’axe vertical montre la consommation d’énergie totale de tous les nœuds dans le réseau.
Lorsqu’on augmente le nombre de nœuds capteurs dans le réseau, il y a plus de nœuds qui
transmettent et la consommation d’énergie totale augmente. Cependant, comme LLMAC donne
aux nœuds l’occasion de s’endormir pendant la transmission d’un évènement, plusieurs nœuds
peuvent économiser l’énergie durant cette période. La consommation d’énergie de LLMAC est
évidemment toujours inférieure à celle de 802.11 car ce dernier ne possède pas de méthodes pour
économiser l’énergie. Plus on augmente le nombre de nœuds dans le réseau, plus le protocole
LLMAC est avantageux.
95
5.4
Résultats d’expérimentation
Dans la partie précédente, nous avons analysé les performances de LLMAC par simulation. Dans
cette partie, nous allons concrétiser la validation de LLMAC avec les capteurs d’image Cyclops
réels.
5.4.1 Scénario de test d’expérimentation
Camera 1
Deux caméras transmettent
simultanément
Camera 2
Figure 5.16 – Scénario de test d’expérimentation
Nous établissons un scénario de test comme illustré dans la Figure 5.16. Nous utilisons 2 caméras
Cyclops et un ordinateur portable qui joue le rôle de la station de base. Lorsqu’un évènement se
produit, les deux caméras sont activées en même temps et envoient une image à la station de base
simultanément. Pour déclencher un envoi en même temps sur les deux caméras, la station de base
émet une requête et cette requête représente un évènement critique. Quand les deux caméras
reçoivent la requête, elles vont renvoyer une image simultanément. Sur la station de base, nous
mesurons le temps entre le moment où nous envoyons la requête et le temps de réception des
images des deux caméras.
Les caméras Cyclops utilisent les capteurs MicaZ [10] pour leur interface de transmission sans fil.
Les capteurs MicaZ se basent sur la norme IEEE 802.15.4 [12] et le protocole d’accès au médium
utilisé est CSMA. En utilisant le système d’exploitation TinyOS [48], les capteurs MicaZ peuvent
96
5.4 Résultats d’expérimentation
transmettre les paquets de taille maximale à 27 octets. Selon la qualité d’image prise par les
caméras Cyclops, nous obtenons une taille d’image différente. Le Tableau 5.2 illustre la taille
d’image et le nombre de trames par image en fonction de la résolution de chaque image. Le nombre
de trames par image est calculé à partir de la taille de l’image et la taille maximale d’une trame de
données (27 octets). Par exemple, le nombre de trames pour une image 32x32 noir et blanc est
1024/27 ~ 38 trames. Il faut qu’un capteur transmette 38 trames pour que la station de base reçoive
une image complète.
Taille d’image (Octets)
Nombre de trames par image
32x32 noir et blanc
1024
38
32x32 couleur
3072
114
64x64 noir et blanc
4096
152
64x64 couleur
12288
456
128x128 noir et blanc
16384
607
128x128 couleur
49152
1821
Tableau 5.2 - Nombre de trames par évènement en fonction de la taille des images
Nous avons fait varier la qualité d’image afin de faire varier le nombre de trames par image.
Comme chaque image représente un évènement, ce test correspond au scénario de simulation dans
la Figure 5.12 où nous faisons varier le nombre de trames par évènement.
5.4.2 Latence de transmissions de chaque image
La Figure 5.17 illustre la latence de transmission de la première et la deuxième image transmise par
les caméras Cyclops en faisant varier la qualité d’images en utilisant CSMA. C’est évident que
lorsqu’on augmente la qualité d’image, il faut plus de temps pour transmettre un volume de
données plus important. Cependant, ce qui est intéressant à observer est que le temps de latence de
la première image est différent par rapport à la deuxième image.
Lorsque deux caméras reçoivent une requête, elles transmettent simultanément une image de P
trames de données. On peut connaître le nombre de trames pour chaque taille d’image en
consultant le Tableau 5.2. Comme ces deux caméras sont en contention pour accéder au canal pour
chaque trame de données en utilisant CSMA, les trames de données de chaque image venant de
deux caméras se chevauchent à la réception de la station de base. Par exemple, la caméra 1 gagne le
canal et transmet une trame de données, ensuite la caméra 2 gagne le canal et transmet une trame
de données et ainsi de suite. Le protocole CSMA garantit l’équité dans le réseau. Ainsi la caméra 1
et caméra 2 ont la même probabilité d’accès au canal lorsqu’elles sont en contention. En théorie, il
faut qu’on reçoive presque la même latence de transmission de la caméra 1 et caméra 2. Cependant
97
lorsqu’on observe la transmission réelle, nous voyons que lorsqu’une caméra gagne le canal, elle
occupe le canal durant la transmission de quelques trames (20-30 trames) avant de relâcher le canal
à la deuxième caméra. Donc, on reçoit une latence de transmission différente entre la première et la
deuxième image.
N&B : noir et blanc
Figure 5.17 – Latence de transmissions en fonction de type d’images
5.4.3 Comparaison entre LLMAC et CSMA
N&B : noir et blanc
Figure 5.18 – Latence de transmission en comparaison entre CSMA et LLMAC
Dans cette expérimentation, nous implémentons LLMAC sur les caméras Cyclops et nous
comparons la latence de transmission entre LLMAC et CSMA. Comme dans un réseau de capteurs
orientés évènement, nous nous intéressons à la latence de transmission des premiers évènements et
nous mesurons la latence de transmission pour la première image. Dans LLMAC, une caméra peut
garder le canal pendant le temps de transmission d’une image sans interruption de la deuxième
98
5.5 Conclusion
caméra. Pour les images de petites tailles : 32x32 N&B, 32x32 couleur et 64x64 N&B, LLMAC et
CSMA donne la même latence de transmission. En effet, en utilisant CSMA par défaut fourni dans
le kit de développement, une caméra peut garder le canal pendant la transmission de plusieurs
trames de données (un nombre aléatoire) avant de lâcher le canal à la deuxième caméra. Pour les
images de petites tailles, nous avons le même comportement entre CSMA et LLMAC où chaque
caméra transmet son image sans interuption. Cependant, lorsqu’on augmente la qualité d’image,
nous obtenons les résultats différents entre LLMAC et CSMA. Dans CSMA, les trames de données
de deux images commencent à se chevaucher et la latence de transmission pour la première image
augmente. Dans LLMAC, nous garantissons qu’une caméra peut transmettre l’intégralité de son
image sans interuption de la deuxième caméra. Ainsi, on observe une latence de transmission avec
LLMAC plus faible que CSMA.
En comparant avec le résultat de simulation (Figure 5.12), nous voyons que LLMAC donne un
meilleur résultat en terme de latence de transmission pour le premier évènement. Plus on augmente
la qualité d’image, plus LLMAC est avantageux. Cependant, nous remarquons une différence entre
le résultat d’expérimentation et la simulation. Dans la simulation, nous trouvons un avantage de
LLMAC même avec un nombre de trames par évènement petit. Par contre, dans
l’expériementation, LLMAC ne montre son avantage que si la qualité de l’image est de taille 64x64
couleur.
5.5
Conclusion
Dans cette partie, nous avons présenté et analysé le fonctionnement d’un nouveau protocole
d’accès au médium que l’on appelle LLMAC pour les réseaux de capteurs orientés évènement. A
l’inverse des protocoles d’accès au médium dans les réseaux de capteurs de type surveillance où le
critère le plus important à prendre en compte est la consommation d’énergie, dans les réseaux de
capteurs orientés évènement, nous nous intéressons principalement au critère de latence de la
transmission. Comme les critères de performance entre ces deux types de réseaux de capteurs sont
différents, nous ne pouvons pas appliquer un protocole d’accès au médium de l’un pour l’autre et
cela nécessite donc un protocole d’accès au médium spécifique pour réduire la latence de
transmission pour les réseaux de capteurs orientés évènement.
Dans LLMAC, nous avons changé le critère de performance en prenant la latence comme premier
paramètre tandis que la consommation d’énergie est considérée comme le deuxième paramètre.
Sachant que l’équité n’optimise pas la latence des transmissions pour les réseaux de capteurs
orientés évènement, nous avons fait un compromis entre l’équité et la latence afin de garantir un
faible délai de transmission pour les premiers évènements. Nous avons favorisé la transmission au
niveau évènement pour qu’un nœud puisse transmettre un évènement sans interruption des autres.
Nous avons également proposé un niveau de priorité FIFS qui donne aux nœuds routeur la priorité
99
d’accès au canal. Ces modifications pénalisent l’équité dans le réseau car on donne la priorité aux à
certains nœuds (routeurs). Pourtant, comme les capteurs fonctionnent d’une manière coopérative, le
fait de laisser le canal aux autres réduit la latence de transmission et la congestion dans le réseau.
En mesurant les résultats d’évaluation avec le simulateur OMNet++, nous avons prouvé que le
protocole LLMAC améliore nettement la latence de transmission par rapport à 802.11 en prenant
en compte la consommation d’énergie dans un réseau de capteurs multi-sauts orientés évènement.
Nous avons également validé notre protocole LLMAC sur les capteurs réels. Le résultat montre que
LLMAC donne toujours des meilleurs performances en terme de latence de transmission même
dans les expérimentations réelles.
100
Chapitre 6.
données
Méthode
distribuées
de
pour
stockage
de
réseaux
de
capteurs
Dans les deux chapitres précédents, nous avons présenté deux protocoles d’accès au médium pour
les réseaux de capteurs. L’objectif de ces deux protocoles est de réduire la consommation d’énergie
et la latence de transmission. Nous avons vu qu’en modifiant le mode de fonctionnement du
transceiveur, les protocoles d’accès au médium peuvent beaucoup influencer la consommation
d’énergie des capteurs. Cependant, comme les traitements locaux des données sont beaucoup
moins coûteux que les transmissions [32], dans certains scénarios, il est préférable de stocker les
données localement plutôt que d’envoyer périodiquement à la station de base. La méthode de
stockage de données joue donc également un rôle important pour la consommation d’énergie et la
durée de vie globale du réseau de capteurs.
Différents modèles de stockage de données ont été présentés dans la partie état de l’art. Chaque
modèle est normalement optimisé pour un scénario précis de réseau de capteurs. Le modèle de
stockage de données data-centric (DCS) est privilégié dans le cas d’un réseau de capteurs à large
échelle où plusieurs évènements sont détectés, mais peu sont récupérés. Cependant, cet axe de
recherche est encore récent et le nombre de travaux existants n’est pas très riche d’où notre
motivation pour rechercher et proposer des améliorations afin de les optimiser et avoir ainsi de
meilleures performances. Dans cette partie, nous allons présenter une méthode de stockage de
données distribuées basée sur une architecture de regroupement que nous appellerons C-DCS
(Clustered Data Centric Storage). Notre proposition améliore la consommation d’énergie totale du
réseau et réduit le taux de perte de données dans le cas d’un réseau mobile.
Nous commençons ce chapitre par une présentation des problèmes existants de DCS dans la partie
6.1 . Ensuite, nous donnons des solutions en proposant une structure de regroupement de DCS dans
la partie 6.2 . Nous évaluons les résultats de performance de notre proposition en utilisant le
simulateur OMNet++ [86] pour simuler un réseau de capteurs à très large échelle (N = 10.000
nœuds) dans la partie 6.3 . Enfin, nous terminons le chapitre avec une conclusion sur notre
proposition.
101
Chapitre 6. Méthode de stockage de données distribuées pour les réseaux de capteurs
6.1
Problème de stockage de données data-centric
dans les réseaux de capteurs
Le modèle de stockage de données data-centric est bien approprié dans le cas d’un réseau de
capteurs à large échelle car il y a plusieurs évènements détectés mais peu d’évènements récupérés.
Cependant, il existe encore des problèmes de routage dans DCS. Comme nous avons vu dans la
partie état de l’art, DCS utilise le protocole de routage GPSR [72] pour router les messages dans le
réseau. Pour que GPSR puisse fonctionner, les nœuds doivent connaître les adresses de tous leurs
voisins directs. En plus, GPSR est conçu pour le routage où l’adresse du nœud source et du nœud
destinataire sont connus. La technique de partage de données de DCS utilise la fonction de hachage
pour distribuer les données uniformément dans le réseau. Cette fonction de hachage garantit une
distribution uniforme des clés dans le réseau, mais elle ne peut pas garantir que la valeur d’une clé
corresponde à la position d’un nœud. Lorsqu’un nœud possède un évènement à partager, il hache
cet évènement pour obtenir une clé (une position dans le réseau). Ensuite, il transmet un message
d’avertissement à cette position en utilisant le protocole de routage GPSR en espérant qu’il y ait un
nœud quelconque qui se trouve à cette position. Cependant, il est probable qu’il n’y ait aucun nœud
qui se trouve à cette position. Dans ce cas, la solution de GHT [70][71] est de chercher le nœud le
plus proche de cette position (appelé le “home node”). Le parcours que le paquet doit traverser
forme un périmètre que l’on appelle “home perimeter”. Le nombre de nœuds dans un “home
perimeter” n’est pas très important (~3 nœuds). Cependant, comme pour chaque routage, il faut
traverser tous les nœuds dans un “home perimeter”, cela peut créer des surcoûts importants car il
est fortement probable que la valeur de hachage ne corresponde à aucun nœud dans le réseau.
La Figure 6.1 illustre le routage du nœud A vers la position Y. Lorsque le paquet arrive au nœud D,
il doit continuer à circuler car il ne sait pas encore si le nœud D est le nœud le plus proche de la
position Y. Dans cette figure, le rectangle dans le “home perimeter” est la zone où il y a un
gaspillage d’énergie. Les nœuds gaspillent l’énergie pour chercher le nœud “home node” à chaque
routage. Si nous pouvons trouver une méthode pour éviter cette recherche, nous pourrons réduire le
nombre de transmissions dans le réseau.
Dans un réseau de capteurs, il y a souvent des nœuds mobiles. Ce sont les capteurs déployés sur
des objets mobiles : un animal dans une forêt, un robot dans une usine etc. Ces nœuds mobiles
peuvent créer de mauvais comportements de routage pour GPSR. La Figure 6.1 illustre un
problème posé par le nœud mobile B. Le nœud A veut transmettre un message à la position Y, il
cherche dans la liste des ses voisins le nœud qui est le plus proche de la position Y. Il trouve que le
nœud B est le plus proche de la position Y, il transmet le paquet au nœud B. Si le nœud B est
toujours dans la portée radio du nœud A, il peut recevoir le paquet et le faire suivre au nœud C,
ainsi de suite jusqu’au nœud D. Le problème survient quand le nœud B est un nœud mobile. Il peut
102
6.2 Regroupement de capteurs pour optimiser le routage de DCS
se déplacer à la position B’, qui se trouve à l’extérieur de la portée radio du nœud A. Le nœud A ne
peut pas mettre à jour cette information immédiatement, il essaie de transmettre au nœud B mais le
paquet ne peut jamais arriver au nœud B. En plus, si le nœud B est le nœud qui stocke les données
pour un type d’évènement, le nœud A ne peut pas récupérer ces informations. A partir de cette
observation, nous voyons que les nœuds mobiles ont moins d’intérêt pour stocker ou router des
paquets car lorsqu’ils se déplacent, ils perturbent le réseau et les autres nœuds ne peuvent pas
récupérer les données stockées dans ces nœuds.
Gaspillage d’énergie
Home node
D
C
Y
A
B
B’
Home perimeter
Figure 6.1 - Gaspillage d’énergie dans le routage GPSR de GHT
6.2
Regroupement de capteurs pour optimiser le
routage de DCS
Dans cette partie, nous allons décrire en détail notre proposition C-DCS, une méthode de
regroupement de capteurs pour éviter le problème de routage que nous avons analysé ci-dessus.
Nous supposons un réseau de capteurs déployé aléatoirement, ce qui signifie que les capteurs sont
distribués uniformément dans la zone de déploiement. Au début, tous les capteurs ont la même
capacité de stockage et d’énergie. En utilisant les dispositifs de localisation (Ex : GPS) [73][74], les
nœuds connaissent toujours leur position dans le réseau.
Nous présentons d’abord la méthode pour organiser le réseau en clusters dans la partie 6.2.1 .
Ensuite, nous décrivons le fonctionnement du réseau en utilisant la structure de regroupement
proposée dans la partie 6.2.2 . Ensuite, nous profitons de la structure de regroupement pour
103
proposer un niveau d’agrégation de données supplémentaire afin de réduire le nombre de
transmissions dans le réseau. Enfin, nous discutons du problème de la tolérance aux fautes en
utilisant les techniques de réplications de données et réélection des cluster-heads.
6.2.1 Organisation du réseau
Dans C-DCS, nous organisons le réseau en clusters. Pour cela, nous divisons l’espace du réseau en
C clusters de la même taille (Figure 6.2). Nous estimons la taille d’un cluster pour qu’il y ait
toujours au moins un nœud dans chaque cluster. Puisque chaque nœud connaît sa position dans le
réseau, il sait de quel cluster il fait partie. Dans chaque cluster, un nœud est élu en tant que cluster
head. Son rôle est de gérer le fonctionnement du cluster. Plusieurs travaux existants sur les
méthodes de regroupement de nœuds ont été proposés [96][97]. Chaque méthode a un critère
spécifique pour sélectionner le cluster head. Comme les capteurs sont sensibles à la consommation
d’énergie et que les capteurs mobiles sont une source de perturbation du réseau, nous prenons le
niveau d’énergie restante et la mobilité des nœuds comme critères pour sélectionner le cluster head.
Nous classons les nœuds en deux types principaux : les nœuds statiques et les nœuds mobiles.
Cependant, comment savoir si un nœud est statique ou mobile ? Dans le cas où les nœuds sont
équipés d’un dispositif qui leur permet de connaître leur position à tout moment, un nœud peut
mesurer la variation de sa position dans le temps afin de savoir son niveau de mobilité. Lorsque ce
niveau dépasse un seuil prédéfini, un nœud sait s’il est mobile ou statique.
C1
C2
Cluster head
Nœud stable
C3
C4
Nœud mobile
Figure 6.2 - Organisation du réseau
Cependant, puisque les dispositifs de localisation (Ex : GPS) sont relativement chers, nous pouvons
prendre une autre méthode de localisation sans utiliser ces dispositifs [6]. Dans un réseau, il y a
seulement quelques nœuds qui sont dotés de dispositifs de localisation, appelé des nœuds “seed”.
Les autres nœuds peuvent estimer leur position dans le réseau en mesurant la distance avec
104
différents nœuds “seed” en utilisant la méthode de triangulation. Cette méthode est moins coûteuse
que des dispositifs GPS [75], mais elle est moins précise et elle requiert des communications
supplémentaires. De plus, les nœuds ne peuvent pas connaître la variation de leur position pour
savoir s’ils sont mobiles. Pour cela, ils peuvent utiliser la technique MOBIC [98], pour calculer
leur niveau de mobilité. Dans MOBIC, les nœuds mesurent la puissance du signal émise par leurs
nœuds voisins. Le niveau de mobilité est défini par la différence de niveau de puissance du signal
entre les différents moments. Lorsqu’un nœud est statique, sa distance avec les nœuds voisins ne
change pas car il obtient toujours le même niveau de puissance du signal de ses voisins. Par contre,
lorsqu’un nœud est mobile, sa distance avec ses nœuds voisins change et il obtient une variation de
puissance du signal venant de ses voisins. Lorsqu’un nœud reçoit une variation importante, il sait
qu’il est un nœud mobile et vice versa.
La mesure du niveau de mobilité est relative et le choix du seuil pour définir un nœud mobile ou
statique dépend fortement du type d’application. Pour chaque type d’application, il existe un seuil
différent. Par exemple, dans une application de surveillance de la forêt, un capteur qui change sa
position durant plus de la moitié de la journée est considéré comme un nœud mobile. De ce fait, les
capteurs qui sont sur le corps des animaux sont considérés comme des capteurs mobiles parce que
leur position change lorsque les animaux bougent.
Une fois que les capteurs sont déployés, on mesure leur niveau de mobilité afin de savoir s’ils sont
mobiles ou statiques. Comme les capteurs sont regroupés en cluster, le cluster head est élu parmi
les capteurs qui se trouvent dans une zone. Nous avons mentionné dans la partie précédente que les
capteurs mobiles causent des problèmes lors du routage. Pour éviter cet aspect, nous excluons les
nœuds mobiles de l’étape d’élection des cluster head. Seul les nœuds statiques ont le droit de
participer à l’élection pour le cluster head. Nous appliquons la règle d’élection de CLA [96] où
chaque nœud prend un identifiant selon un critère donné et le nœud qui possède l’identifiant le plus
petit devient le cluster head. Comme le niveau d’énergie restant sur les capteurs est un critère très
important pour la durée de vie du réseau de capteurs, nous utilisons ce paramètre pour calculer
l’identifiant des nœuds. Plus précisément, nous voulons qu’un nœud ayant une capacité d’énergie
plus importante prenne une valeur d’identifiant plus petite. Cela oblige le nœud qui possède le plus
énergie à prendre en charge le cluster head pour gérer le cluster. Au début du déploiement, tous les
nœuds ont la même capacité d’énergie, chaque nœud prend une valeur aléatoire pour son identifiant
(pour éviter le cas où tous les nœuds ont le même identifiant). Ensuite, les capteurs consomment de
l’énergie pour faire des communications, le niveau d’énergie est différent entre des nœuds et la
méthode d’élection ci-dessus va donner un résultat précis. La Figure 6.3 illustre en détails le
pseudo code de cette méthode d’organisation du réseau.
105
Méthode d’organisation du réseau
Pour chaque nœud dans le réseau faire
Evaluer le niveau de mobilité
Choisir une valeur identifiant aléatoire
/* Seuil α est le niveau qu’on déclare pour les nœuds mobiles */
Si le niveau de mobilité < seuil α alors
Diffuser un message d’avertissement avec l’identifiant aux nœuds voisins
Si l’identifiant est minimal alors
Déclarer entant que cluster head
Figure 6.3 – Pseudo code sur la méthode d’organisation du réseau
6.2.2 Stockage et récupération de données dans le réseau
Dans cette section, nous allons décrire comment la structure de regroupement présentée
précédemment peut éviter les problèmes de routage dû à la recherche du “home node” et à la
perturbation engendrée par les nœuds mobiles. Nous allons voir en détail les méthodes de stockage
et de récupération de données en utilisant la structure de regroupement.
Dans C-DCS, les nœuds mobiles ne peuvent pas participer au processus d’élection des cluster
heads. En plus, comme ils sont source de perturbation du réseau, nous voulons qu’ils ne participent
pas au protocole de routage et de stockage dans le réseau. Seuls les nœuds statiques stockent et
routent les données dans le réseau. A l’initiation du réseau où les nœuds envoient des messages
pour connaître les nœuds voisins, les nœuds mobiles ne répondent pas et les nœuds statiques ont
l’information seulement de leurs voisins statiques. De ce fait, quand les nœuds statiques veulent
transmettre un message, ils ne vont trouver dans la liste de leurs voisins que des nœuds statiques.
Lorsqu’un nœud statique détecte un évènement et qu’il veut transmettre cette information, il hache
le type d’évènement pour obtenir l’adresse du nœud responsable de ce type d’évènement. En
utilisant le protocole de routage GPSR [72], ce nœud route le message vers les nœuds qui se
trouvent plus proches de la position destinataire. Les nœuds mobiles sont exclus de ce routage car
les nœuds statiques n’ont aucune information sur la position des nœuds mobiles. De plus, comme
on a précisé auparavant, le problème de routage de GPSR survient lorsque la position destinatrice
106
ne correspond à aucun nœud dans le réseau. Dans la structure de regroupement de C-DCS, nous
pouvons éviter ce problème. Nous appliquons GPSR jusqu’à ce que le paquet arrive à un nœud
quelconque dans le cluster de la position destinataire. Ce nœud n’est pas à l’adresse de la position
destinataire, mais il connaît l’adresse du cluster head et il va faire suivre cette information
directement au nœud cluster head.
10 C1
C2
Cluster head
23
Hacher(température
A
=100) = (7,2)
C3
Nœud statique
1
2
1
C4
1
1
3
Nœud mobile
C
Station de base
B
Une valeur de hachage
(7, 2)
1
10
Figure 6.4 - Stockage et récupération de données dans le réseau.
La Figure 6.4 illustre cette procédure de stockage de données dans un réseau de capteurs déployé
dans une zone de taille 10*10. Lorsque le capteur statique A détecte un évènement X (Ex : la
température = 100°C), il va hacher la valeur de X. Supposons que la valeur de hachage de X soit Y
= hache(“température =100”) = (7,2). Le nœud A fait suivre son paquet aux nœuds les plus proches
de la position Y sans prendre en compte les nœuds mobiles. Sur la figure, nous voyons un nœud
mobile dans le cluster C1 qui se trouve le plus proche de la position Y, mais le nœud A ne transmet
pas son paquet à ce nœud mobile car ce nœud mobile ne figure pas dans sa liste des voisins. Le
routage suit le lien noté 1 dans la Figure 6.4. Rappelons qu’il n’y a aucun nœud à la position Y =
(7,2). Dans GHT, il faut traverser un “home perimeter” pour trouver le “home node” afin de
stocker la donnée. Dans C-DCS, lorsque le paquet arrive au nœud B, ce dernier n’est pas à la
position, il connaît que la valeur (7,2) est responsable par le cluster head de C4 (tous les nœuds
connaissent l’adresse de leur cluster head). Ainsi, le nœud B fait suivre le message directement au
nœud C sans traverser de “home perimeter”.
La récupération de données est réalisée d’une manière symétrique de la procédure de stockage de
données. La station de base est positionnée quelque part dans le réseau afin d’accéder aux
informations dans le réseau. Lorsqu’un utilisateur veut chercher une valeur X (Ex : l’endroit où la
température était 100°C), la station de base va hacher la valeur X pour obtenir la position Y =
107
hache("température =100") = (7, 2). La station de base utilise GPSR pour router la requête en
suivant le chemin noté 2 vers le nœud C qui est le cluster head du cluster C4 (Figure 6.4). Le
cluster head utilise le chemin inverse pour renvoyer la réponse à la station de base en suivant le
chemin noté 3.
Quelqu’un peut faire
suivre mon message ?
REQ
APV
M
message S
message Y
Figure 6.5 - Nœud mobile envoie une donnée
Le processus de stockage et de récupération de données ci-dessus néglige l’existence des nœuds
mobiles. Ces nœuds ne participent ni au protocole de routage ni au stockage de données.
Cependant, comme ils sont dans le réseau pour mesurer des informations ambiantes, ils doivent
partager les informations qu’ils ont observées. En effet, les nœuds mobiles ne connaissent pas
l’adresse de leurs voisins car s’ils gardent une liste de leurs voisins, ils doivent mettre à jour cette
liste tout le temps lorsqu’ils se déplacent et cela est un gaspillage d’énergie.
Pour que les nœuds mobiles puissent transmettre les données, nous avons conçu une méthode
d’avertissement. La Figure 6.5 illustre le cas où un nœud mobile détecte un évènement et veut
transmettre. Le nœud mobile M détecte un évènement X, il hache la valeur de X pour obtenir la
position Y pour stocker cette information. Comme un nœud mobile ne connaît pas l’adresse de ses
voisins, il ne peut pas savoir qui peut l’aider pour router le message. Donc, le nœud mobile M doit
diffuser un message REQ (REQUEST) pour demander aux nœuds autour de l’aide pour router le
message. Lorsqu’un nœud statique reçoit un message REQ, s’il reste encore de l’énergie et qu’il est
prêt à donner de l’aide, il va renvoyer un message APV (APPROVE) en mettant sa position dans le
réseau. Comme le nœud mobile peut recevoir plusieurs message APV, il va sélectionner le nœud
voisin qui se trouve le plus proche de la position Y pour faire router son message. Dans la Figure
6.5, le nœud M reçoit des messages APV et sélectionne le nœud S pour router leur message à la
position Y.
En effet, dans un réseau de capteurs, un capteur mobile reste souvent mobile durant toute sa vie.
Par exemple, un capteur qui est attaché sur le corps d’un animal ou dans un robot, est toujours
mobile. Cependant, comme nous classons les capteurs en deux types : capteur statique et capteur
108
mobile, nous pouvons envisager le cas où les capteurs changent d’état de statique à mobile ou vice
versa. Lorsqu’un nœud passe de l’état mobile à l’état statique, il change sa caractéristique et
annonce aux nœuds voisins ce changement. Maintenant, il peut participer au routage, au stockage
et à l’élection de cluster head. Au contraire, lorsqu’un nœud passe de l’état statique à l’état mobile,
il annonce ce changement aux nœuds voisins pour que ces nœuds sachent qu’il ne va pas participer
au routage et stockage de données dans le réseau. Si ce nœud est un cluster head, il va déclencher le
processus d’élection du nouveau cluster head et laisser les données à ce nouvel élu cluster head.
6.2.3 Agrégation de données à deux niveaux
Dans la partie précédente, nous avons présenté la structure de regroupement C-DCS afin d’éviter
les problèmes de routage dû à la recherche de “home node” et des nœuds mobiles. Dans cette
partie, nous allons profiter de la structure de regroupement pour proposer un niveau
complémentaire d’agrégation de données dans le réseau de capteurs. En fait, dans certaines
applications, les utilisateurs sont intéressés seulement par des informations agrégées : la valeur
totale, max, min et moyenne etc. Par exemple, un utilisateur veut connaître seulement la
température maximale dans un réseau. Dans ce cas, nous faisons une petite modification du
protocole de routage par rapport au protocole de routage présenté ci-dessus. Lorsqu’un nœud
possède une mesure à transmettre, il doit tout d’abord transmettre le message à son cluster head. Ce
dernier est le seul qui peut faire suivre le message aux autres. En modifiant le routage via des
nœuds cluster head, nous pouvons appliquer deux niveaux d’agrégation de données afin de réduire
le nombre de transmissions.
Routage et agrégation de données
Pour chaque évènement faire
Hacher la valeur de l’évènement et envoyer au cluster head
Pour chaque paquet reçu dans la position P(x,y) faire
Si P dans mon cluster alors
Transmettre le paquet au cluster head
Sinon
Chercher le nœud le plus proche de la position P(x,y) et transmettre à ce
nœud
Si un nœud est cluster head alors
Agréger les données
Figure 6.6 – Pseudo code sur le routage et agrégation de données
109
Le premier niveau d’agrégation de données est dans chaque cluster. En effet, après avoir reçu
toutes les données des nœuds dans un cluster, le cluster head agrège les données et n’envoie qu’une
seule donnée agrégée. Supposons qu’il y ait 5 nœuds dans un cluster, au lieu d’envoyer 5 paquets
vers le nœud responsable de ce type d’évènement, le cluster head agrège les données et n’envoie
qu’une seule donnée. Dans un cluster, nous économisons 4 transmissions multi-sauts.
Le deuxième niveau d’agrégation de données est au niveau du nœud qui stocke les données.
Exemple : les nœuds qui stockent toutes les températures maximales de tous les clusters dans le
réseau. Lorsque la station de base envoie une requête, le nœud responsable pour ce type
d’agrégation fait un deuxième niveau d’agrégation de données et renvoie la réponse agrégée à la
station de base. Une fois de plus, nous pouvons économiser l’énergie en transmettant seulement un
résultat agrégé à la station de base. La Figure 6.6 illustre un pseudo code pour le routage et
agrégation de données des nœuds dans le réseau. Nous détaillons ce procédure de routage et
agrégation de données de deux niveaux dans la figure suivante.
10 C1
hache("max(temp
érature ")=(9,1)
C2
Cluster head
2 3
A
Mobile node
1
2
Premier niveau
d’agrégation
C3
1
3
C4
1
Access point
A position
1
Y=(9,1)
1
Stable node
Deuxième niveau
d’agrégation
10
Figure 6.7 - Deux niveaux d’agrégation de données
La Figure 6.7 illustre un exemple d’agrégation de données à deux niveaux. Supposons qu’on
s’intéresse seulement à la température maximale dans le réseau. Chaque capteur mesure la
température et l’envoie au cluster head pour que ce dernier agrège les données. Dans le cluster C1,
tous les nœuds (statique et mobile) envoient leur mesure au nœud cluster head (le nœud noir) pour
que ce dernier fasse le premier niveau d’agrégation de données. Ces transmissions sont illustrées
par les flèches pointillées. Le cluster head hache le type d’agrégation (max) et le type d’évènement
(température) pour obtenir la clé Y=hache (“max (température)”) = (9,1). Cette valeur de hachage
est différente de la valeur de hachage “type d’évènement” qu’on a vu dans la partie précédente
(hacher(température=100) = (7,2)). Puisque cette position se trouve dans le cluster C4, le cluster
head de C1 choisit la valeur maximale de température et envoie cette valeur au nœud cluster head
du C4. Ce routage est illustré par les flèches labellisées 1. Le cluster head du C4 devient le
110
responsable de toutes les températures maximales des clusters dans le réseau. Lorsque ce dernier
reçoit une requête venant de la station de base, il choisit encore la valeur maximale de toutes les
données qu’il a reçues (deuxième niveau d’agrégation de données) et renvoie la réponse en suivant
le chemin labellisé 3 vers la station de base.
6.2.4 Technique de réplication de données
Dans la structure de regroupement que nous avons vue ci-dessus, il y a seulement un nœud dans un
cluster qui est responsable de toutes les données. Ce nœud devient un goulot étranglement et un
point d’accès unique dans le cluster. Lorsqu’il tombe en panne, nous perdons toutes les données
stockées dans ce cluster. C’est pour cette raison que nous proposons une technique de réplication
de données pour la tolérance aux pannes. En effet, chaque cluster head possède un nœud répliqué
qui garde une copie de ses données. Lorsqu’un nœud est élu comme cluster head, il diffuse
également un paquet "demande d’aide" à tous les nœuds dans son cluster pour trouver un nœud qui
est prêt à donner de l’aide. Lorsqu’il trouve un nœud volontaire, il le prend comme son assistant.
Périodiquement, il transmet les données qu’il gère à ce nœud répliqué afin de sauvegarder une
copie de ses données. Lorsque le cluster head tombe en panne, il y a toujours un nœud répliqué qui
prend en charge toutes les données dans le cluster. Un nœud répliqué prend le rôle de cluster head
s’il trouve que le cluster head est tombé en panne. En effet, il suffit que le nœud répliqué constate
que le nœud cluster head ne répond pas aux requêtes certaines fois, il peut considérer que le nœud
cluster head a tombé en panne et reprend le rôle de cluster head automatiquement. Ce mécanisme
garantit une sauvegarde des données sur un nœud répliqué. Il peut arriver le cas où ces deux nœuds
tombent en panne en même temps. Mais, il arrive rarement ce cas et il reste négligeable. Donc,
notre proposition garantit que les données ne sont pas perdues même dans le cas d’un réseau de
capteurs mobiles où les nœuds tombent en panne.
Les autres propositions GHT [70][71] et R-DCS [77] utilisent également une méthode de
réplication de données. Cependant, la technique de réplication de données utilisée dans GHT n’est
pas une réplication réelle. Elle est juste une distribution de données sur les zones rectangles afin de
réduire la charge pour les évènements importants. De ce fait, lorsqu’un nœud tombe en panne, il est
impossible de récupérer toutes les données. Dans R-DCS, les nœuds répliqués sont les nœuds qui
stockent réellement les données. Les nœuds moniteurs stockent seulement les informations
agrégées. Si les nœuds répliqués tombent en panne, les données réelles sont perdues et il ne reste
que les données agrégées. Dans C-DCS, nous répliquons réellement les données et même dans le
cas de panne, nous possédons toujours des données sur les nœuds répliqués pour récupérer
l’intégralité des données dans le réseau.
111
6.2.5 Réélection des cluster-heads
Comme dans n’importe quel système de regroupement des nœuds, C-DCS a un inconvénient
majeur : le cluster head doit travailler plus que les autres nœuds dans le cluster. Il épuise son
énergie plus rapidement et il va s’arrêter de fonctionner lorsqu’il n’aura plus d’énergie. Comme un
réseau est opérationnel si tous les nœuds dans les réseaux sont opérationnels, il est donc nécessaire
de distribuer la charge sur les différents nœuds pour éviter de surcharger les nœuds clusters head.
Nous appliquons une méthode de réélection des cluster head. Périodiquement, après un intervalle
de temps T, tous les nœuds recalculent leur identifiant selon leur énergie restante pour une nouvelle
élection de cluster head. La valeur de l’identifiant est inversement proportionnelle au niveau
d’énergie restant dans chaque nœud. Un nœud possédant moins d’énergie va prendre une valeur
d’identifiant plus grande pour éviter d’être élu cluster head. Un nœud possédant plus d’énergie va
prendre une valeur d’identifiant plus petite pour avoir plus de chance d’être élu cluster head. En
utilisant cette technique, le rôle cluster head est échangé entre les nœuds dans le même cluster et
nous pouvons prolonger la durée de vie des réseaux de capteurs.
6.3
Dans cette partie, nous allons analyser les performances de notre proposition et nous allons
comparer C-DCS avec les autres techniques existantes. Afin de faire des comparaisons, nous
reprenons les mêmes hypothèses pour les calculs de coût de transmission présentées dans le
Tableau 3.1. Nous commençons tout d’abord par une analyse théorique du coût de transmission de
C-DCS dans la partie 6.3.1 . Ensuite, nous allons concrétiser ces résultats théoriques par des
résultats de simulation dans un réseau à très large échelle dans la partie 6.3.2 .
6.3.1 Analyse théorique
C-DCS offre deux avantages par rapport à GHT : il évite le parcours de “home perimeter” et il a
deux niveaux d’agrégation de données. Dans GHT, le coût pour une transmission est O( N + X ) où
N est le nombre de nœuds et X est le nombre de capteurs dans un “home perimeter”. Dans, C-DCS,
le coût pour une transmission est O( N ) car on peut éviter la recherche du “home node”. En terme
de complexité, ces deux protocoles donnent le même résultat car O( N + X ) = O( N ) . Cependant,
le fait de parcourir dans un “home perimeter” pour tous les évènements détectés peut générer
beaucoup de messages supplémentaires.
Dans C-DCS, en appliquant deux niveaux d’agrégation, nous pouvons réduire nettement le nombre
de transmissions. Supposons que M soit le nombre moyen de nœuds dans un cluster. Au lieu
d’envoyer tous les évènements détectés par tous les nœuds, le cluster head agrège les données et
112
envoie seulement un seul paquet. Le nombre de transmissions total comprend le nombre de
requêtes, le nombre de transmissions pour le stockage et le nombre de réponses. Ainsi, on a une
valeur Totale = Q N + Dtotal N / M + Q N . Plus le nombre de nœuds dans un cluster est
important, plus le nombre de transmissions total est faible. Comme dans un système de stockage
DCS, la valeur Dtotal est la valeur la plus importante, en réduisant M fois cette valeur, nous
réduisons beaucoup de communications dans le réseau.
6.3.2 Résultat de simulation
Dans cette partie, nous concrétisons le résultat théorique de la partie précédente par les simulations.
Nous utilisons le simulateur OMNeT++ [86] pour simuler un réseau de capteurs à large échelle.
Comme le but de ce travail est d’optimiser le nombre de transmissions et le hotspot (la charge sur
le nœud le plus sollicité) dans le réseau, nous simplifions la simulation en négligeant la couche
MAC et la couche physique. Nous supposons que les capteurs peuvent transmettre sans collisions,
sans erreur. Lorsqu’un nœud transmet un paquet, il est sûr que le paquet arrivera à destination. Le
but est d’avoir une simulation légère qui permette de simuler un réseau de capteurs à très large
échelle.
a)
Paramètres de simulation
Paramètre
Valeur
1 km2
Portée radio
40 m
Nombre de nœuds
10.000
Densité
1 nœud / 100 m2
Nombre de clusters
1.000
Nombre de type d’évènement
100
Nombre de requêtes
0-100
Nombre de données pour chaque type d’évènement
100
Tableau 6.1 - Paramètres de simulation
Nous simulons un réseau de capteurs de taille 10.000 qui sont distribués uniformément dans une
zone de taille 100x100. Supposons que l’unité de distance soit de 10 m, nous avons une zone de
déploiement de 1 km2. La station de base est placée au coin de la zone de déploiement. Au début,
tous les nœuds génèrent un évènement ; ils hachent leur évènement et l’envoie au cluster head du
cluster responsable de la valeur de hachage. Nous fixons le nombre de type d’évènement à 100
113
comme les mesures effectuées dans GHT[71]. La station de base génère aléatoirement des requêtes
et les envoie dans le réseau. Nous faisons varier le nombre de requêtes de 0 à 100. Si un nœud
reçoit une requête et qu’il possède des données pour le type d’évènement de la requête, il renvoie
une liste de réponses ou juste une donnée agrégée à la station de base selon les cas. Le Tableau 6.1
illustre en détail les paramètres de simulation que nous utilisons pour valider le fonctionnement de
C-DCS.
b)
Agrégation à deux niveaux
Dans cette première simulation, nous voulons montrer l’avantage de C-DCS avec deux niveaux
d’agrégation par rapport aux autres modèles de stockage de données que nous avons présentés dans
la partie état de l’art. Ainsi, nous mesurons le nombre de transmissions total et le hotspot du réseau
en faisant varier le nombre de requêtes Q. Pour ne pas être influencé par les nœuds mobiles, nous
mettons tous les capteurs à l’état statique pour isoler la performance de C-DCS avec deux niveaux
d’agrégation.
Figure 6.8 - Nombre de transmissions total en faisant varier la valeur de Q
La Figure 6.8 illustre le nombre de paquets transmis par tous les nœuds dans le réseau en faisant
varier le nombre de requêtes entre [0 ; 100]. Le modèle LS (stockage local) offre un meilleur
résultat lorsqu’il n’y a aucune requête ou lorsqu’il y a peu de requête dans le réseau. Cela est un
résultat attendu car tous les nœuds stockent leurs mesures localement. Lorsqu’il n’y a aucune
requête, il n’y aura aucune transmission. Pourtant, lorsqu’on augmente le nombre de requêtes, le
nombre de transmissions total du modèle LS augmente très rapidement car chaque requête est
diffusée à tous les nœuds dans le réseau. Comme le nombre de nœuds dans le réseau est important,
cette méthode de diffusion est coûteuse et elle rend le modèle LS inutilisable pour un nombre de
requêtes important.
114
Au contraire du modèle LS, dans le modèle de stockage ES (stockage externe), tous les évènements
sont envoyés à la station de base quelque soit le nombre de requêtes. Le coût des requêtes et des
réponses est 0 car tous les évènements sont déjà dans la station de base. Dans la Figure 6.8, nous
obtenons une ligne horizontale pour le modèle ES car le nombre de messages total est une valeur
constante.
Comparativement aux deux modèles LS et ES, le modèle DCS donne un meilleur résultat dans le
cas d’un nombre de requêtes moyen. Par contre, lorsqu’il n’y a pas beaucoup de requêtes, le
modèle LS est le plus avantageux. Lorsqu’il y a beaucoup de requêtes, c’est le modèle ES qui est le
plus avantageux car tous les évènements sont utiles pour les utilisateurs. Le modèle DCS donne un
meilleur résultat seulement dans l’intervalle [30 ; 40] (Figure 6.6). Mais, en utilisant la variante de
DCS, S-DCS avec l’agrégation de données, on obtient de meilleurs résultats. S-DCS utilise
seulement un niveau d’agrégation qui est sur le nœud qui stocke les données pour chaque type
d’évènement. Lorsqu’un nœud reçoit une requête, au lieu d’envoyer la liste des évènements qu’il a
reçu (100 évènements pour chaque requête), ce nœud agrège les données et n’envoie qu’une seule
réponse à la station de base. Ce modèle donne un meilleur résultat par rapport aux modèles ES, LS
et DCS dans tous les cas. En effet, on obtient une courbe presque horizontale pour ce modèle car
lorsqu’on augmente le nombre de requêtes, le nombre de réponses n’augmente pas beaucoup.
Notre proposition C-DCS utilise deux niveaux d’agrégation de données : un niveau pour chaque
cluster et un niveau pour les nœuds responsables de chaque type d’évènement. Comme nous avons
fixé le nombre de nœuds dans chaque cluster à 10, nous obtenons un nombre de transmissions de
C-DCS 10 fois inferieur à S-DCS. Plus le nombre de nœuds dans chaque cluster est important, plus
on économise le nombre de transmissions.
En réduisant le nombre de transmissions, le modèle de stockage C-DCS réduit également le hotspot
dans le réseau. Nous utilisons le même scénario de transmission que pour la simulation précédente,
mais nous mesurons le nombre maximal de messages envoyés de chaque nœud dans le réseau. La
Figure 6.9 illustre ce résultat de simulation. Nous pouvons constater que le modèle ES donne le
plus mauvais résultat car toutes les données sont envoyées à la station de base quelque soit le
nombre de requêtes. Comme la station de base se trouve dans la zone de déploiement, le nœud
proche de la station de base doit router tous les messages pour la station de base (y compris les
requêtes et les réponses). Alors, ce modèle est illustré par une ligne constante où le nœud hotspot
doit toujours transmettre environ 5000 paquets.
Dans les modèles LS et DCS, lorsqu’on augmente le nombre de requêtes, le nombre de réponses
augmente rapidement et la charge sur le nœud à côté de la station de base augmente rapidement.
Ces deux modèles donnent le même hotspot par rapport au modèle ES dans le cas où le nombre de
requêtes est égal à 100 et toutes les données dans le réseau sont envoyées à la station de base. Nous
obtenons deux courbes linéaires pour le nombre de requêtes de la station de base.
115
Le modèle S-DCS améliore nettement le nombre de hotspot car un nœud envoie seulement une
donnée agrégée. Le nombre de réponses est identique au nombre de requêtes. C-DCS utilise deux
niveaux d’agrégation de données et il améliore encore plus le hotspot dans le réseau. La Figure
6.9a illustre le hotspot de tous les modèles de stockage. Cependant, les résultats de S-DCS et CDCS sont trop petits et nous ne voyons pas très bien la différence. Alors, nous détaillons la
différence de S-DCS et C-DCS dans la Figure 6.9b. Lorsqu’on augmente le nombre de requêtes, le
hotspot de S-DCS et C-DCS augmente, mais nous voyons que C-DCS donne toujours un meilleur
résultat que S-DCS.
a) Tous les modèles de stockage
b) Détails de S-DCS et C-DCS
Figure 6.9 - Hotspot en faisant varier le nombre de requêtes Q
6.4
Conclusion
Dans cette partie, nous avons présenté une méthode de regroupement des nœuds pour les modèles
de stockage de données distribuées que l’on appelle C-DCS (Clustered DCS). Notre proposition
améliore les modèles existants de stockage de données distribuées en particulier pour le routage
vers les positions où il n’y a pas de nœud. Nous avons profité de la structure de regroupement de
C-DCS pour faire un deuxième niveau d’agrégation de données pour les types de requête agrégée
afin de réduire le nombre de transmissions et ainsi prolonger la durée de vie du réseau de capteurs.
En analysant la complexité en nombre de transmissions, nous avons vu que notre proposition donne
un nombre de transmissions plus faible que les autres modèles de stockage de données. Par
simulation, nous avons montré qu’il y a moins de transmission dans C-DCS avec deux niveaux
d’agrégations de données
116
6.4 Conclusion
117
Chapitre 7.
Conclusion
Les réseaux de capteurs constituent un axe de recherche très fertile et peuvent être appliqués dans
plusieurs domaines différents. Cependant, il reste encore de nombreux problèmes à résoudre dans
ce domaine afin de pouvoir les utiliser dans les conditions réelles. Pour les réseaux de capteurs de
type surveillance, la problématique majeure est la consommation d’énergie car les capteurs sont
des petits composants avec une faible capacité d’énergie. Le but des recherches dans ce type de
réseau est de concevoir des protocoles de communication qui permettent de prolonger la durée de
vie d’un réseau de capteurs à quelques années sans changer les piles des capteurs. Pour les réseaux
de capteurs orientés évènement, la problématique majeure est différente. Il s’agit de la latence de
transmission des évènements pour les applications critiques. La recherche dans ce type de réseau se
focalise sur les méthodes pour réduire la latence de transmission des évènements dans le réseau.
Chaque type de réseau de capteurs a des caractéristiques et des contraintes différentes. Cela
nécessite donc de concevoir des protocoles spécifiques pour chaque type de réseau.
Dans cette thèse, nous avons présenté un état de l’art des différents protocoles MAC et des
protocoles de stockage de données dans les réseaux de capteurs. Nous avons vu l’évolution des
différentes techniques de gestion d’accès au canal et des différents modèles de stockage de
données. Ces propositions utilisent les techniques existantes des réseaux sans fil et des réseaux
pair-à-pair pour être adaptés dans les réseaux de capteurs en prenant en compte les caractéristiques
spécifiques de ces derniers. Nous avons montré que cette adaptation n’est pas toujours optimale et
il subsiste souvent des inconvénients dans les travaux existants ce qui donne une motivation
supplémentaire pour notre recherche. Les contributions principales de cette thèse concernent des
améliorations de la couche MAC et un protocole de stockage de données distribuées dans les
réseaux de capteurs.
Dans la couche MAC, nous avons travaillé avec deux types de réseau : réseaux de capteurs de type
surveillance et réseaux de capteurs orientés évènement. Pour le premier type, nous avons proposé
le protocole OBMAC afin de réduire la consommation d’énergie et prolonger la durée de vie. Nous
avons montré que l’écoute passive n’est pas toujours une source de gaspillage d’énergie. Au
contraire, elle peut être une bonne technique pour réduire les communications redondantes. Nous
avons également proposé la notion de la "portée influente" afin d’affiner le protocole OBMAC
pour garantir l’exactitude du système. Pour les réseaux de capteurs orientés évènement, nous avons
proposé le protocole LLMAC afin de réduire la latence des transmissions pour les applications
critiques. Nous avons montré que les protocoles MAC existants dans les réseaux sans fil
garantissent l’équité entre les nœuds et cette caractéristique ne favorise pas la latence de
119
Chapitre 7. Conclusion
transmission. Dans LLMAC, nous avons réalisé un compromis entre la latence de transmission et
l’équité pour que les nœuds fonctionnent d’une manière coopérative et la station de base reçoive
des évènements avec la plus faible latence. Selon le type d’application des réseaux de capteurs,
nous pouvons appliquer les protocoles MAC différents afin d’optimiser les performances.
Dans les protocoles de stockage de données distribuées, nous avons proposé une structure de
regroupement des capteurs dans le modèle de stockage de données data-centric. Notre protocole est
appelé C-DCS (Clustered Data-Centric Storage). Notre proposition améliore le routage des
données dans les modèles de stockage de données existants car nous pouvons éviter des recherches
inutiles dues à l’adaptation du routage dans les réseaux pair-à-pair au routage dans les réseaux de
capteurs. Nous avons également utilisé une méthode de classification des nœuds afin de bien isoler
les nœuds mobiles des tâches importantes dans le réseau car les nœuds mobiles sont une source de
perturbation dans le réseau. Profitant de la structure de regroupement des capteurs, nous proposons
une technique "deux-niveaux" d’agrégation de données pour les applications où nous avons besoin
seulement des résultats agrégés (min, max etc.). Nous avons montré que C-DCS offrait de
meilleures performances par rapport aux autres protocoles existants en terme du nombre de
transmissions, particulièrement dans le cas de deux niveaux d’agrégation de données.
Perspectives du travail de thèse
Dans cette thèse, nous avons présenté des propositions sur la couche MAC et le stockage de
données distribuées. Pourtant, ces propositions ne sont pas encore optimales et il nécessite donc
encore des améliorations. Au niveau des protocoles MAC, nous traitons principalement le partage
le médium afin de réduire la congestion et les transmissions dans le réseau. Cependant, la couche
MAC est liée directement à la couche réseau et la couche physique et il faut donc prendre en
compte ces aspects afin de pouvoir analyser la performance du réseau au niveau global de toutes
les couches. Au niveau du stockage des données distribuées, nous optimisons le routage et
l’agrégation de données pour réduire le nombre de transmissions dans le réseau. Les travaux
existants dans ce domaine ne prennent pas en compte la capacité de stockage de données sur la
mémoire de chaque capteur. Ils prennent comme hypothèse que les capteurs peuvent stocker ce
qu’ils ont dans leur mémoire ou supprimer les données si leur mémoire est pleine. La future
direction de ce travail de recherche pourrait être de traiter la capacité de stockage de données sur la
mémoire de chaque capteur pour garantir la disponibilité des données dans le réseau même dans le
cas où la mémoire est pleine.
Parmi les résultats de recherche que nous avons présentés dans cette thèse, la plupart sont obtenus
avec le simulateur OMNeT++. Nous avons également travaillé sur une plateforme des réseaux de
capteurs réels MicaZ de Crossbow. Nous avons obtenu des résultats réels sur les capteurs et ces
résultats correspondent aux résultats que l’on obtient via le simulateur. Cependant, comme la
plateforme des réseaux de capteurs MicaZ est une plateforme d’expérimentation, nous avons des
120
Chapitre 7. Conclusion
limitations : le code source n’est pas bien commenté, le programme ne fait que des tâches simples.
Il reste encore des validations sur les capteurs réels que nous ne pouvons pas encore réaliser. Un
des travaux futurs est d’implémenter les fonctionnalités qui manquent dans le kit de développement
afin d’enrichir les résultats d’expérimentation de recherche que nous avons présentés dans cette
thèse. Ensuite, il faut valoriser ces travaux de recherche dans une application réelle. Nous voulons
appliquer notre proposition dans le domaine de transport, par exemple, sur les moteurs de TGV
dont nous voulons surveiller le fonctionnement et générer une alerte à plus faible latence si un
évènement critique se produit.
121
Bibliographie
[1]. I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, A survey on sensor networks.
IEEE Communications Magazine, vol 40, pp. 102-114, August, 2002.
[2]. G. J. Pottie and W. J. Kaiser, Wireless Integrated Network Sensors, Communications of the
ACM, vol 43, pp. 51- 58, 2000.
[3]. S. Tilak, N. B. Abu-Ghazaleh, and W. B. Heinzelman, A taxonomy of wireless micro-sensor
network models, ACM SIGMOBILE Mobile Computing and Communications Review, vol. 6,
no. 2, pp. 28-36, April 2002.
[4]. J. Hill, M. Horton, R. Kling and L Krishnamurthy, The Platforms Enabling Wireless Sensor
Networks, Communications of the ACM, vol. 47 no. 6, June 2004.
[5]. H. Karl and A. Willig, Protocols and Architectures for Wireless Sensor Networks, Wiley, April
2005
[6]. Ivan Stojmenovic, Handbook of Sensor Networks, Wiley, September 2005.
[7]. S. Kumar, V. S. Raghavan and J. Deng, Medium Access Control Protocols for Ad-Hoc
Wireless Networks: A Survey, Elsevier Ad-Hoc Networks Journal, vol. 4, no. 3, pp. 326-358,
May 2006.
[8]. I. Demirkol, C. Ersoy and F. Alagöz, Mac Protocols For Wireless Sensor Networks: A Survey,
IEEE Communications Magazine, vol. 44, no. 4, pp. 115-121, April 2006.
[9]. Spec Specification, http://www.jlhlabs.com/jhill_cs/spec/index.htm.
[10].
Mica Sensors Specification , http://www.xbow.com.
[11].
Imote Specification, http://www.intel.com/research/exploratory/motes.htm.
[12]. Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for
Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE Std. 802.15.4. October 2003.
[13].
Specification of the Bluetooth System, http://www.bluetooth.org/.
[14]. T. He et al., Energy-Efficient Surveillance Systems Using Wireless Sensor Networks,
Proceeding of the ACM MobiSys, Boston, USA, June 2004.
[15]. A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, and J. Anderson, Wireless Sensor
Networks for Habitat Monitoring, First ACM Workshop on Wireless Sensor Networks and
Applications, Atlanta, GA, USA, September 2002.
123
Bibliographie
[16].
N. Xu, S. Rangwala, K. K. Chintalapudi, D. Ganesan, A. Broad, R. Govindan, and D.
Estrin, A wireless sensor network for structural monitoring. In Proceedings of the 2nd
international conference on Embedded networked sensor systems, November 2004.
[17]. M.J. Whelan, M.V. Gangone and K.D. Janoyan, Integrated Smart Wireless Sensors for
Bridge Structural Health and Homeland Security Monitoring, The 3rd International
Conference on Structural Health Monitoring of Intelligent Infrastructure, Vancouver, Canada,
November 2007.
[18].
Wireless Medical Sensor Networks, http://www.cs.virginia.edu/wsn/medical/.
[19].
A. Tanenbaum, Réseaux, 4ème édition, 2003.
[20].
G. Pujolle, Les Réseaux, édition 2008.
[21].
S. Kumar, V. S. Raghavan, J Deng, Medium Access Control Protocols for Ad-hoc Wireless
Networks: A Survey, Elsvier, pp. 326-358, November 2004.
[22].
N. Abramson, The Aloha System - Another Alternative for Computer Communication, in
AFIPS, pp. 295–298, 1970.
[23]. L. G. Roberts, ALOHA packet system with and without slots and capture, ACM
SIGCOMM Computer Communication Review, vol. 5, pp. 28 – 42, April 1975.
[24]. L. Kleinrock, F. Tobagi, Packet Switching in Radio Channels: Part I--Carrier Sense
Multiple-Access Modes and Their Throughput-Delay Characteristics, IEEE Transactions on
Communications, December 1975.
[25].
F. A. Tobagi and L. Kleinrock, Packet switching in radio channels: PartII - the hidden
terminal problem in Carrier Sense Multiple-Access and the busy-tone solution, IEEE Trans.
Commun., vol. 23, no. 12, pp. 1417–1433, 1975.
[26].
P. Karn, MACA - a new channel access method for packet radio, in Proc.of the 9th
ARRL/CRRL Computer Networking Conference, pp. 134–140, Ontario, Canada, Sept. 1990.
[27].
G. Sidhu, R. Andrews, A. Oppenheimer, Inside Apple-Talk, Addison-Wesley, Reading,
USA, 1989.
[28].
V. Barghavan, A. Demers, S. Shenker, and L. Zhang, MACAW: A media access protocol
for wireless LAN's, in Proc. of ACM SIGCOMM '94, pp. 212-225, 1994.
[29]. K.C. Chen, Medium access protocols of wireless lans for mobile computing, IEEE
Network 8, pp. 50–63, 1994.
[30]. B.P. Crow, I. Widjaja, J.G. Kim, P.T. Sakai, IEEE 802.11, wireless local area networks,
IEEE Commun. Mag. , 1997.
[31]. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification,
IEEE Std. 802.11-1999 edition.
124
Bibliographie
[32].
G.J Pottie and W. J. Kaiser. Embedding the Internet: Wireless Integrated Network Sensors.
Communications of the ACM, vol. 43, no. 5, pp. 51-58, 2000.
[33]. W. Ye, J. Heidemann, and D. Estrin. An Energy-Efficient MAC Protocol for Wireless
Sensor Networks. In Proceedings of IEEE Infocom, pp. 67-76, New York, NY, July 2002.
[34]. W. Ye, J. Heidemann, D. Estrin, Medium Access Control With Coordinated Adaptive
Sleeping for Wireless Sensor Networks, Networking, IEEE/ACM Transactions, vol. 12, no. 3,
pp. 493-506, June 2004.
[35].
S. Singh, M. Woo, and C. S. Raghavendra, Power-aware with Routing in Mobile Ad Hoc
Networks, Proceedings of Mobicom 1998, Dallas, TX, 1998.
[36]. T. van Dam and K. Langendoen. An adaptive energyefficient MAC protocol for wireless
sensor networks. In 1st ACM Conf. on Embedded Networked Sensor Systems (SenSys 2003),
pp. 171–180, Los Angeles, CA, November2003.
[37].
Y. Li, W. Ye, and J. Heidemann. Energy and Latency Control in Low Duty Cycle MAC
Protocols. In Proceedings of IEEE WCNC, New Orleans, LA, March 2005.
[38].
P. Lin, C. Qiao and X. Wang. Medium Access Control with a Dynamic Duty Cycle for
Sensor Networks. In Proceedings of IEEE WCNC, Atlanta, GA, March 2004.
[39]. G. Lu, B. Krishnamachari, C.S. Raghavendra, An adaptive energy efficient and lowlatency MAC for data gathering in wireless sensor networks, Proceedings of 18th International
Parallel and Distributed Processing Symposium, pp. 224-236, April 2004.
[40].
ITU-R Recommendation M.584-2 (11/97), Codes and formats for radio paging.
[41]. B. Mangione-Smith, Low power communications protocols: paging and beyond, in Proc.
IEEE Symposium on Low Power Electronics, pp. 8 -11, 1995.
[42].
A. El-Hoiydi. Aloha with Preamble Sampling for Sporadic Trafic in Ad Hoc Wireless
Sensor Networks. In Proc. IEEE Int. Conf. on Communications, pp. 3418-3423, New York,
USA, April 2002.
[43]. A. El-Hoiydi. Spatial TDMA and CSMA with Preamble Sampling for Low Power Ad Hoc
Wireless Sensor Networks. In Proc. IEEE Int. Conf. on Computers and Communications
(ISCC), pp. 685-692, Taormina, Italy, July 2002.
[44].
A. El-Hoiydi and J.-D. Decotignie. WiseMAC: An Ultra Low Power MAC Protocol for
Multi- hop Wireless Sensor Networks. In Proceedings of the First International Workshop on
Algorithmic Aspects of Wireless Sensor Networks (ALGOSENSORS 2004), pp. 18-31, July
2004.
[45].
C. Enz, A. El-Hoiydi, J.-D. Decotignie, and V. Pereis. Wisenet: An Ultra Low Power
Wireless Sensor Network Solution. IEEE Computer, vol. 37, no. 8, pp. 62-70, August 2004.
125
Bibliographie
[46].
W. Ye, F. Silva and J. Heidemann. Ultra-Low Duty CycleMAC with Scheduled Channel
Polling. In Proceedings of ACM SenSys, Boulder, CO, November 2006.
[47]. J. Polastre, J. Hill and D. Culler. Versatile Low Power Media Access for Wireless Sensor
Networks. In Proceedings of ACM SenSys, 2004.
[48].
TinyOS Community Forum. http://www.tinyos.net
[49].
R. Jurdak, P. Baldi, and C. V. Lopes. Energy-Aware Adaptive Low Power Listening for
Sensor Networks. In Proceedings of INSS, pp. 24–29, San Diego, CA, June 2005
[50].
Zigbee Alliance. http://www.zigbee.org
[51].
M. Buettner, G. V. Yee, E. Anderson, and R. Han, X-MAC: A Short Preamble MAC
Protocol for Duty-Cycled Wireless Sensor Networks, in Proc. ACM SenSys’06, pp. 307–320,
November 2006.
[52]. S. Mahlknecht, and M. Rötzer, CSMA-MPS: A Minimum Preamble Sampling MAC
Protocol for Low Power Wireless Sensor Networks, IEEE WFCS, Vienna, Austria, 2004.
[53].
K. Jamieson, H. Balakrishnan, and Y. C. Tay. Sift: A MAC protocol for event-driven
wireless sensor networks. Third European Workshop on Wireless Sensor Networks (EWSN),
February 2006.
[54]. Y.C. Tay, K.Jamieson, H. Balakrishnan, Collision-minimizing CSMA and Its Applications
to Wireless Sensor Networks, IEEE Journal on Selected Areas in Communications, vol. 22, no.
6, pp. 1048 – 1057, August 2004.
[55].
L. Bao and J.J. Garcia-Luna-Aceves, A New Approach To Channel Access Scheduling For
Ad Hoc Networks, Seventh Annual International Conference on Mobile Computing and
Networking, pp. 210–221, 2001.
[56].
V. Rajendran, K. Obraczka, and J. Garcia-Luna-Aceves, Energy-efficient, collision-free
medium access control for wireless sensor networks, in 1st ACM Conf. on Embedded
Networked Sensor Systems, pp. 181-192, Los Angeles, CA, November 2003.
[57]. E. Shih, S.-H. Cho, N. Ickes, R. Min, A. Sinha, A. Wang, and A. Chandrakasan, Physical
layer driven protocol and algorithm design for energy-efficient wireless sensor networks, in
International Conference on Mobile Computing and Networking, Rome, Italy, 2001.
[58].
B.H. Liu, C.T. Chou, J. Lipman, S. Jha, Using Frequency Division to Reduce MAI in
CDMA Wireless Sensor Networks, IEEE Wireless Communications and Networking
Conference (WCNC), pp. 657-663, New Orleans, LA, March 2005.
[59]. M. Liu, C.-T Chou, On the Fading and Shadowing Effects for Wireless Sensor Networks,
IEEE Proceedings of MASS 2006, October 2006
126
Bibliographie
[60].
W.R. Heinzelman, J. Kulik, and H. Balakrishnan. Adaptive Protocols for Information
Dissemination in Wireless Sensor Networks. Proceedings of the 5th Annual International
Conference on Mobile Computing and Networking, pp 174-185, Seattle, WA, August 1999.
[61]. C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed Diffusion: A Scalable and
Robust Communication Paradigm for Sensor Networks. In Proceedings of the Sixth Annual
International Conference on Mobile Computing and Networking (MOBICOM), August 2000.
[62]. B. Krishnamachari, D. Estrin, and S. Wicker. The impact of data aggregation in wireless
sensor networks. IEEE International Workshop on Distributed Event-Based Systems (DEBS),
pp. 575-578, July 2002
[63].
H.-C. Le. Rapport stage Master recherche. Université Pierre et Marie Curie, September,
2005.
[64].
FIPS 180-1. Secure Hash Standard. U.S. Department of Commerce/NIST, National
Technical Information Service, April 1995.
[65]. M. Abdallah, H.-C. Le. Scalable Range Query Processing for Large-Scale Distributed
Database Applications. In Proc. of the International Conference on Parallel and Distributed
Computing and Systems (PDCS), Phoenix, USA, November 2005.
[66].
S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker. A Scalable Content-
Addressable Network. In Proc. of the ACM SIGCOMM 2001 Conference, August 2001.
[67].
I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan. Chord: A scalable peer-
to-peer lookup service for internet applications. In Proc. of the ACM SIGCOMM 2001
Conference, August 2001.
[68].
Y. B. Zhao, J. Kubiatowicz, and A. Joseph. Tapestry: An infrastructure for fault-tolerant
wide-area location and routing. Technical Report UCB/CSD-01-1141, University of California
at Berkeley, 2001.
[69].
P. Druschel and A. Rowstron. Pastry: Scalable, distributed object location and routing for
large-scale peer-to-peer systems. In Proc. of the 18th IFIP/ACM International Conference on
Distributed Systems Platforms (Middleware), November 2001.
[70].
S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govidan, and S. Shenker. GHT: A
geographic hash table for data-centric storage. In First ACM International Workshop on
Wireless Sensor Networks and Applications, 2002.
[71]. S. Ratnasamy, B. Karp, S. Shenker, D. Estrin, R. Govindan, L. Yin, and F. Yu, DataCentric Storage in Sensornets with GHT, A Geographic Hash Table, in Proc. of Mobile
Networks and Applications (MONET), March 2003.
127
Bibliographie
[72].
B. Karp and H. T. Kung. GPSR: greedy perimeter stateless routing for wireless networks.
In Proceedings of the 6th annual international conference on Mobile computing and
networking (MobiCom ’00), pp. 243–254, New York, USA, 2000.
[73]. Jinyang Li, John Jannotti, Douglas S. J. De Couto, David R. Karger, and Robert Morris, A
scalable location service for geographic ad hoc routing, In Proceeding of ACM Mobicom,
Boston, MA, 2000.
[74]. N. Bulusu, J. Heidemann, and D. Estrin, GPS-Less Low Cost Outdoor Localization for
Wireless Sensor Networks, IEEE Personal Communications Magazine, October 2000.
[75].
B. Hofmann-WeUenhof, H. Lichtenegger, and J. Collins. Global Positioning System,
Theory and Practice. Springer-Verlag, 1993.
[76]. J. Newsome and D. Song. GEM: Graph Embedding for Routing and Data-Centric Storage
in Sensor Networks without Geographic Information. In Proceedings of First International
Conference on Embedded Networked Sensor Systems (SenSys’03), Los Angeles, California,
USA, November, 2003.
[77].
A. Ghose, J. Grossklags, and J. Chuang, Resilient Data-Centric Storage in Ad-Hoc
Wireless Sensor Networks, Proceedings of 4th International Conference on Mobile Data
Management (MDM2003), Melbourne, Australia, January 2003.
[78]. K. Seada, A. Helmy. Rendezvous Regions: A Scalable Architecture for Service Location
and Data-Centric Storage in Large-Scale Wireless Networks. IEEE/ACM IPDPS 4th Int'l
Workshop on Algorithms for Wireless, Mobile, Ad Hoc and Sensor, Santa Fe, New Mexico,
April 2004
[79]. D. Dudkowski, P.-J Marron, and K. Rothermel. An Efficient Resilience Mechanism for
Data Centric Storage in Mobile Ad Hoc Networks. Proceedings of the 7th International
Conference on Mobile Data Management (MDM'06), May 2006
[80].
C.-T Ee, S. Ratnasamy, S. Shenker: Practical Data-Centric Storage. In 3rd Symposium on
Networked Systems Design and Implementation, San Jose, USA, May 2006
[81]. H.-C Le, H. Guyennet and N. Zerhouni. Over-hearing for Energy Efficient in Event-Driven
Wireless Sensor Network. In First IEEE International Workshop on Intelligent System
Techniques for Wireless Sensor Networks(IST-WSN), Vancouver Canada, October 2006
[82].
H.-C Le, H. Guyennet and N. Zerhouni. Redundant Communication Avoidance for Event-
Driven Wireless Sensor Network. In International Journal of Computer Science and Network
Security (IJCSNS) vol. 7, no. 3 March 2007
[83]. H.-C Le, H. Guyennet and V. Felea. OBMAC: An Overhearing Based MAC Protocol for
Wireless Sensor Networks. The International Conference on Sensor Technologies and
Applications (SENSORCOMM07), Valencia, Spain, October 2007
128
Bibliographie
[84].
A. Woo, T. Tong, and D. Culler, Taming the Underlying Challenges of Reliable Multihop
Routing in Sensor Networks. In Proceedings of the First ACM Conference on Embedded
Networked Sensor Systems (SenSys 2003), Los Angeles, CA, November 2003.
[85]. B. Krishnamachari, D. Estrin and S. Wicker, The impact of data aggregation in wireless
sensor networks, in International Workshop on Distributed Event-based Systems, 2002
[86].
OMNeT++ Community Site. http://www.omnetpp.org
[87].
The Network Simulator NS2. http://www.isi.edu/nsnam/ns/
[88].
Opnet Technologies. http://www.opnet.com/
[89].
Mobility Framework for OMNeT++. http://mobility-fw.sourceforge.net
[90].
BatteryModule for MF2.02. http://inf.unisi.ch/projects/mics/downloads/BatteryModule.zip
[91].
Silicons Laboratories. http://silabs.com
[92].
2.4 GHz IEEE 802.15.4 / ZigBee-ready RF Transceiver,
http://focus.ti.com/lit/ds/symlink/cc2420.pdf
[93]. H.-C Le, H. Guyennet, V. Felea and N. Zerhouni. A Low Latency MAC Scheme for
Event-Driven Wireless Sensor Networks. In the 3rd International Conference on Mobile Adhoc and Sensor Networks (MSN2007), Bejing, China, December 2007
[94].
H.-C Le, H. Guyennet and N. Zerhouni. LLMAC: An Efficient MAC Protocol for Event-
Driven Wireless Sensor Networks, International Journal of Distributed Sensor Networks
(submitted 2008)
[95].
Cyclops Camera, http://www.cyclopscamera.com
[96]. A. Ephremides, J. Wieselthier, and D. Barker, A Design concept for reliable mobile radio
networks with frequency hoping signaling. In proceedings of the IEEE, pp. 56-73, 1987
[97]. M. Gerla and J.-C. Tsai. Multicluster, mobile, multimedia radio network. ACM/Baltzer
Journal of Wireless Networks, vol. 1, no. 3, pp. 255-265, July 1995
[98].
P. Basu, N. Khan, and T. Little. A Mobility Based Metric for Clustering in Mobile Ad Hoc
Networks. In Distributed Computing Systems Workshop (DISC), Lisbon, Portugal, October
2001.
[99]. I. Dedun et M. Seville, Les systèmes d’information interorganisationnels comme
médiateurs de la construction de la collaboration au sein des chaînes logistiques : Du partage
d’information aux processus d’apprentissages collectifs. Proc. du 6ième congrès international
du Génie Industriel, Besançon, Juin, 2005.
[100]. Association Française de Normalisation. http://www.afnor.org
129
Bibliographie
[101]. I. Rasovska, B. Chebel -Morello, N. Zerhouni. Process of s-maintenance : decision support
system for maintenance intervention. 10th IEEE International Conference on Emerging
Technologies and Factory Automation, Catania, Italy, september 2005.
[102]. A Sensor Network Deployment in AS2M. http://lifc.univ-fcomte.fr/moteview/
130
Bibliographie personnelle
1. Maha ABDALLAH, Hung-Cuong LE. Scalable Range Query Processing for Large-Scale
Distributed Database Applications. In Proc. of the International Conference on Parallel and
Distributed Computing and Systems (PDCS), pp.433-439, Phoenix USA, November 14-16,
2005
2. Hung-Cuong Le, Herve Guyennet and Noureddine Zerhouni. Over-hearing for Energy
Efficient in Event-Driven Wireless Sensor Network. In First IEEE International Workshop
on Intelligent System Techniques for Wireless Sensor Networks (IST-WSN), pp. 633-638,
Vancouver Canada, Oct, 2006
3. Hung-Cuong LE, Herve Guyennet and Noureddine Zerhouni. Redundant Communication
Avoidance for Event-Driven Wireless Sensor Network. In International Journal of
Computer Science and Network Security (IJCSNS) Vol. 7, No. 3, pp. 193-200, March
2007
4. Hung-Cuong Le, Herve Guyennet and Noureddine Zerhouni. A New Contention Access
Method for Collision Avoidance in Wireless Sensor Networks. In the Sixth International
Conference on Networking (ICN), pp. 27-34, Martinique, 21-28 April 2007
5. Hung-Cuong Le. A Clustered Data-Centric Storage for Wireless Sensor Networks. In the
Third International Workshop on Distributed Framework for Multimedia Applications
(DFMA), Paris, France, 5-6 July 2007
6. Hung-Cuong LE, Hervé Guyennet and Noureddine Zerhouni. Mobile Effect Reduction in
Data-Centric Storage for Wireless Sensor Networks. The Third IET International
Conference on Intelligent Environments (IE'07), pp. 304-311, Ulm, Gemany, September
2007
7. Hung-Cuong LE, Hervé Guyennet and Violeta FELEA. OBMAC: An Overhearing Based
MAC Protocol for Wireless Sensor Networks. The International Conference on Sensor
Technologies and Applications (SENSORCOMM),pp.547-553, Valencia, Spain, October
2007
8. Hung-Cuong LE, Hervé Guyennet, Violeta Felea and Noureddine Zerhouni. A Low
Latency MAC Scheme for Event-Driven Wireless Sensor Networks. In the 3rd
International Conference on Mobile Ad-hoc and Sensor Networks (MSN), pp. 291-301,
Bejing, China, December 2007
9. Hung-Cuong LE, Herve Guyennet and Noureddine ZERHOUNI. LLMAC: An Efficient
MAC Protocol for Event-Driven Wireless Sensor Networks, International Journal of
Distributed Sensor Networks (submitted 2008)
131
Bibliographie personnelle
132
Annexe A : Déploiement d’un réseau de
capteurs pour la e-maintenance
Dans cette thèse, nous avons abordé des différentes problématiques des réseaux de capteurs tels
que la consommation d’énergie, la latence de transmission et le stockage de données distribuées.
Comme le contexte de la thèse est d’appliquer un réseau de capteurs pour la e-maintenance, nous
allons analyser le rôle d’un réseau de capteurs dans la e-maintenance et présenter une plateforme de
test d’un réseau de capteurs que nous déployons au sein du laboratoire Automatique et Systèmes
Micro-Mécatroniques (AS2M) de l’Université de Franche Comté à Besançon. Nous commençons
par une présentation de l’architecture de la e-maintenance dans la partie A.1. Ensuite, nous
analysons le rôle d’un réseau de capteurs dans la e-maintenance. Les parties A.3 et A.4 présentent
la plateforme de test d’un réseau de capteurs MicaZ de Crossbow et un outil de gestion du réseau
de capteurs pour la gestion et la notification les informations dans la e-maintenance.
A.1 L’architecture de e-maintenance
Figure A.1 - Classification de différentes architectures en maintenance
Dans cette partie, nous présentons la définition de la maintenance et une classification de différents
types de maintenance. Nous proposons une terminologie caractérisant les différents systèmes
informatiques en maintenance et nous les classons selon deux axes : le type d’information utilisée
dans le système et l’intensité d’une éventuelle relation avec d’autres systèmes informatiques
(Figure A.1). Plus la relation est intense plus les systèmes sont reliés et intégrés et nous parlons
133
Annexe A : Déploiement d’un réseau de capteurs pour la e-maintenance
d’architectures communes qui seront implémentées à travers des plates-formes. Elles sont classées
sur une exponentielle car la collaboration entre ces systèmes est atteinte plus tôt que le niveau de la
compétence partagée. Le volume d’informations gérées automatiquement est concrétisé par la
surface du carré de chaque système et augmente avec l’intensité de collaboration et aussi avec la
complexité de l’information partagée. Nous tenons à signaler qu’il y a une parallèle entre notre
classification des systèmes et la classification des entreprises telle qu’elle est présentée dans
plusieurs travaux [99]. Il s’agit de l’entreprise traditionnelle, distribuée, coopérative et étendue.
- Le système de maintenance comprend un seul système informatique présent sur le site de
production et utilisé sur le site de maintenance. Ce système est autonome sans échange de données
avec d’autres systèmes. En parallèle avec la classification des entreprises, cela correspond à
l’entreprise traditionnelle, donc nous parlons d’une architecture traditionnelle d’un système
d’information.
- Le système de télémaintenance est constitué d’au moins deux systèmes informatiques : un
émetteur et un récepteur de données et d’informations qui échangent à distance. Selon la définition
d’AFNOR [100] la télémaintenance est “la maintenance d’un bien exécutée sans accès physique du
personnel au bien”. Nous parlons d’une architecture distribuée, basée sur la notion de distance qui
permet de transférer les données par une radio, une ligne téléphonique ou par l’intermédiaire d’un
réseau local.
- Avec l’extension d’Internet, les systèmes de télémaintenance émergent vers le concept d’emaintenance.
Le système d’e-maintenance sera implémenté sur une plateforme distribuée coopérative intégrant
différents systèmes et applications de maintenance. Cette plateforme doit prendre appui sur le
réseau mondial d’Internet (d’où le terme e-maintenance) et la technologie web permet d’échanger,
de partager et de distribuer des données et des informations et de créer ensemble des
connaissances. Ici le concept de la maintenance intelligente peut être exploité et les stratégies de
maintenance proactives et coopératives sont mises en place.
- La s-maintenance (où “s” signifie sémantique)
L’architecture d’une plateforme de s-maintenance [101] prend appui sur l’architecture d’emaintenance où l’interopérabilité des différents systèmes intégrés dans la plate-forme est garantie
par un échange de connaissances représentées par une ontologie. Afin que le partage de
l’information dans le réseau coopératif d’e-maintenance soit sans difficulté, nous formaliserons
cette information d’une façon à pouvoir l’exploiter dans les différents systèmes faisant partie du
réseau.
134
A.2 Le rôle d’un réseau de capteurs dans la e-maintenance
La coordination entre les partenaires du réseau sera approfondie et une base ontologique du
domaine de partage de l’information sera élaborée.
Les systèmes partageront ainsi la sémantique créée pour l’architecture commune de la plateforme
d’e-maintenance. Cette base terminologique et ontologique modélisera l’ensemble des
connaissances d’un domaine. Elle jouera le rôle de mémoire permettant de mettre en place un
système de gestion et de capitalisation des connaissances dans l’objectif d’améliorer le
fonctionnement de système de maintenance.
A.2 Le rôle d’un réseau de capteurs dans la e-maintenance
En amont de l'opération de maintenance préventive, il est nécessaire de collecter les informations
sur le fonctionnement des différents mécanismes. Cette collecte se fera à partir de capteurs dont le
rôle est de prévenir un éventuel dysfonctionnement en permettant de suivre en temps réel sur une
longue période les différents indicateurs de température, vibration, humidité, etc. Ces capteurs
intégrés dans le système sont soumis à des contraintes d'utilisation assez rudes en termes de
température, de vibrations et de champs magnétiques.
Dans le laboratoire, nous travaillons en particulier sur la mise en réseau des capteurs qui permet
d'augmenter la portée et la valeur des observations, de router les informations recueillies et
d'assurer la tolérance aux fautes. Une structure hiérarchique de capteurs offre la meilleure
souplesse pour s’adapter aux diverses missions de chaque élément du réseau : un nœud de
complexité croissante se traduit par une consommation croissante d’énergie et un coût de plus en
plus élevé. Nous envisageons donc une hiérarchie de capteurs distribués qui pourront être
géolocalisés (GPS).
Pour une performance de surveillance globale, le système doit permettre d’obtenir des informations
fiables et exploitables aussi bien en ligne (pour la détection et la localisation de défaillances
pendant la phase d’exploitation) qu’en hors-ligne. En effet, une autre partie de l’équipe développe
un système d’aide au diagnostic et à la réparation modélisant la connaissance experte dans le
domaine, et prenant appui sur les données capteurs observées. Ce système d’aide est basé sur le
raisonnement à partir de cas (RàPC), approche de l’intelligence artificielle pour l’apprentissage par
expériences.
Le RàPC [101] met en œuvre une base de cas contenant des expériences de problèmes résolus où
l’on peut rechercher des expériences passées similaires au problème à résoudre. Ces cas sont
mémorisés et organisés en fonction de critères bien déterminés permettant de les retrouver
efficacement. Le cas représente la synthèse de toute l’activité de résolution d’une situation sous une
forme économique. Il est ainsi possible d’y faire référence à l’avenir et de réutiliser directement la
135
méthode de résolution sans avoir à la redécouvrir. Un cas se définit comme “un ensemble de
connaissances contextualisées représentant une expérience porteuse d’enseignement en relation
avec un but précis d’un utilisateur potentiel du système”. Cet outil permet aux opérateurs de
maintenance de capitaliser la connaissance de leur métier et de la partager afin d’améliorer la
performance et l’efficacité de l’intervention du service de maintenance.
A.3
Plateforme de réseau de capteurs MicaZ de
CrossBow
Figure A.2 - Architecture d’un réseau de capteurs MicaZ
Dans le cadre de mon travail de thèse, j’ai utilisé le kit de développement professionnel fourni par
l’entreprise américain Crossbow [10] pour développer un outil permettant une gestion des capteurs
pour la e-maintenance. Ce kit contient 6 capteurs MicaZ et une station de base. Il fournit également
le protocole XMesh pour la communication des capteurs en réseau maillé, un outil de contrôle des
capteurs et un logiciel pour gérer la compilation et l’installation des programmes sur les capteurs.
Ce kit est un outil complet de point de vue matériel et logiciel permettant un développement et un
déploiement un réseau de capteurs. La Figure A.2 illustre l’architecture d’un réseau de capteurs
MicaZ où on voit l’interaction des capteurs, les composants dans le réseau et les logiciels
permettant la surveillance des capteurs. Nous allons décrire les compositions des matériels et des
logiciels du kit dans la partie A.3.1 et A.3.2 respectivement.
136
A.3 Plateforme de réseau de capteurs MicaZ de CrossBow
A.3.1 Les compositions des matériels du kit
Comme on le voit dans la figure ci-dessus, ce kit de réseau de capteurs contient : 6 capteurs MicaZ
et une station de base.
a)
Capteur MicaZ
Chaque capteur MicaZ se compose de deux modules : une carte MPR2600 et une carte MTS400
(Figure A.3). La carte MPR 2600 contient un microcontrôleur et un transceiveur. Le
microcontrôleur contient une mémoire flash de 128kB, une mémoire vive de 4kB et un processeur
de 4MHz. C’est la partie de calcul et de traitement des informations des capteurs. Sur la carte, il y a
également un module transceiveur à fréquence radio de 2.4 GHz allant jusqu’à 250kbps. Ce dernier
est le module de communication permettant des transmissions sans fil entre les capteurs et de
capteurs vers la station de base.
+
MPR2600
=
MTS400/420
MicaZ
Figure A.3 - Composition d’un capteur MicaZ
Une partie indispensable pour un capteur est le module “senseur”. En effet, c’est le module qui
permet de convertir des valeurs ambiantes en valeurs numériques tel que la température, les
vibrations etc. Pour les capteurs MicaZ, la carte MTS400 donne des mesures assez complètes de
différents facteurs environnementaux : la température, l’accélération, la pression, la luminosité et
l’humidité. Cette carte est dotée un connecteur spécifique afin de connecter avec la carte MPR2600
pour transmettre les mesures ambiantes. Une nouvelle génération de carte “senseur” MTS420 est
également fournie chez Crossbow avec une fonctionnalité supplémentaire. Elle donne toutes les
mesures de MTS400 et elle offre également la position géographique GPS du capteur qui permet de
les utiliser dans les applications où on a besoin de la localisation de capteurs.
137
b)
Station de base
La station de base contient deux composants dont un pour récupérer les mesures transmises sans fil
par les capteurs et un pour envoyer les données à l’ordinateur (Figure A.4). Le premier composant
est une carte MPR2600 qui permet la récupération de données transmises par les capteurs via des
ondes radio. Le deuxième composant est une carte MIB520 qui est dotée d’une liaison filaire vers
l’ordinateur via un câble USB. Cette carte reçoit des données de la carte MPR2600 et fait suivre
ces données à l’ordinateur via le câble USB. L’ensemble de la carte MIB520 et MPR2600 forme
une station de base permettant la récupération de données des capteurs dans le réseau. Mis à part la
tâche de relai des messages, la carte MIB520 sert également à injecter les programmes sur les
capteurs MicaZ afin de faire des tâches définies.
+
MIB520
=
MPR2600
Station de base
Figure A.4 - Station de base MIB520
A.3.2 Les logiciels fournis par Crossbow
Dans l’architecture des réseaux de capteurs MicaZ que nous voyons dans la Figure A.2, il y a trois
niveaux de logiciels :
•
XMesh : un programme installé sur les capteurs afin de prendre des mesures, faire des
communications multi-saut en réseau maillé vers la station de base
•
XServe : un programme installé sur le serveur de la station de base afin de stocker les
mesures venant des capteurs dans le réseau.
•
MoteView : Un programme installé sur les machines des utilisateurs finaux afin de
visualiser et diagnostiquer les résultats stockés dans la station de base.
138
A.4 Accès à distance pour le réseau de capteurs via Internet
Ces trois niveaux de logiciels nous permettent de déployer rapidement un réseau de capteurs
fonctionnels afin de surveiller une zone et donner des mesures pour la maintenance. Cependant,
MoteView est un logiciel assez lourd et il ne facilite pas l’accès aux données du réseau de capteurs.
Comme nous travaillons sur un réseau de capteurs appliqué à la e-maintenance, il nécessite donc un
accès à distance via Internet au réseau de capteurs. Il s’agit d’un portail web permettant la
consultation et l’interaction avec le réseau de capteurs via un navigateur web. En plus, il faut
ajouter une gestion des évènements pour définir le type d’évènement à gérer et une méthode de
notification telle qu’email ou SMS. Ces fonctionnalités n’existent pas encore dans le kit de
développement de Crossbow et nous les avons implémentées.
A.4 Accès à distance pour le réseau de capteurs via
Internet
Figure A.5 - Interface de gestion d’un réseau de capteurs
Dans cette partie, nous détaillons le développement que nous avons réalisé afin de construire un
portail web permettant un accès à distance pour le réseau de capteurs. En effet, parmi les trois
logiciels fournis par Crossbow, il n’y a que XMesh qui est open-source. Il nous faut donc
développer un programme de récupération de données comme XServe. Ce programme insère les
mesures dans une base de données. Ensuite, il faut écrire une page web dynamique afin de
visualiser les mesures des capteurs et gérer les évènements. Cette page web accède aux données
dans la base de données et visualise les résultats sur un navigateur web.
139
La Figure A.5 illustre cette interface de gestion d’un réseau de capteurs déployés au sein du
Département Automatique et Systèmes Micro-Mécatroniques (AS2M) à Besançon [102]. Dans
cette interface, nous trouvons la position de différents capteurs situés aux différentes positions sur
la chaîne de transfert. Nous pouvons également voir les mesures de chaque capteur ainsi qu’un
tableau récapitulatif de toutes les mesures de tous les capteurs. La fenêtre à droite donne toutes les
mesures prises par un capteur : la température, l’accélération, la pression, la luminosité et
l’humidité.
A partir de ces mesures, un utilisateur peut définir les évènements qu’il veut surveiller. Un
évènement se compose d’un type de mesure (la température, la luminosité etc.), une valeur pour ce
type de mesure et le type d’opérateur (inférieur, supérieur). La Figure A.6 illustre cette interface de
gestion des évènements où on crée un évènement lorsque la température dépasse 30°C. Cette
interface est protégée par un identifiant et un mot de passe. Elle permet la saisie de différents types
d’évènement. Nous avons également développé le module de notification qui permet d’envoyer
automatiquement un SMS ou un email lorsqu’un évènement prédéfini se produit.
Figure A.6 - Interface de gestion des évènements
A.5 Conclusion
Dans cette annexe, nous avons décrit une plateforme de réseaux de capteurs MicaZ déployés au
sein du laboratoire Automatique et Systèmes Micro-Mécatroniques (AS2M) afin d’avoir un outil
pour réaliser la e-maintenance. Notre plateforme offre de possibilité d’un accès aux informations
dans le réseau de capteurs et un module de notification des évènements via SMS et email. Nous
développons actuellement l’optimisation de la durée de vie et la sécurité dans le réseau de capteurs.
140
Annexe B : Abréviation et terminologie
RdC
Réseaux de capteurs
MAC
Multiple Access Control
CSMA
Carrier Sense Multiple Access
BTMA
Busy Tone Multiple Access
TDMA
Time Division Multiple Access
FDMA
Frequency Division Multiple Access
CDMA
Code Division Multiple Access
RTS
Request To Send
CTS
Clear To Send
MACA
Multiple Access Collision Avoidance
DCF
Distributed Coordinate Function
PCF
Point Coordinate Function
SIFS
Short Interframe Spacing
DIFS
DCF Interframe Spacing
FIFS
Forward Interframe Spacing
PAN
Personal Area Network
141
FFD
Full Function Device
RFD
Reduced Function Device
RSSI
Received Signal Strength Indicator
Piggyback
superposer
Overhearing
Ecoute passive
Idle
Ecoute non-actif
Preamble Sampling
Préambule d’échantillonnage
Broadcast
Diffusion
Greedy Forwarding
Routage glouton
Perimeter Forwarding
Routage par périmètre
Deaf listening
Envoi sourd
142
Optimisation d’accès au médium et stockage de données distribuées dans les
réseaux de capteurs
Les réseaux de capteurs constituent un axe de recherche très fertile ces dernières années. Cette
technique se développe dans différents domaines comme l’environnement, l’industrie, le
commerce, la médecine, l’armée etc. Selon le type d'application, les problématiques peuvent être
différentes.
Dans cette thèse, nous nous sommes intéressés à deux problématiques: les protocoles d'accès au
canal et le stockage de données distribuées. Le document est divisé en deux parties où la première
partie est un état de l'art de différentes techniques existantes et la deuxième partie décrit notre
contribution dans ces deux problématiques.
Dans la première contribution, nous avons proposé deux protocoles d'accès au canal. Le premier
optimise la durée de vie des réseaux de capteurs de type surveillance et le second réduit la latence
de transmission dans les réseaux de capteurs orientés événements pour les applications critiques.
Dans la deuxième contribution, nous nous sommes focalisés sur le modèle de stockage de données
data-centric. Nous avons proposé une structure de regroupement des capteurs afin d'améliorer le
routage et réduire le nombre de transmissions afin de prolonger la durée de vie d'un réseau de
capteurs.
Mot clés: économie d'énergie, latence de transmission, protocoles d'accès au canal, réseaux de
capteurs, stockage de données distribuées
143
Optimization of MAC protocols and distributed data storage in wireless sensor
networks
Wireless sensor network is a very hot research topic tendency for the last few years. This
technology can be applied into different domains as environment, industry, commerce, medicine,
military etc. Depending on the application type, the problems and requirements might be different.
In this thesis, we are interested in two major problems: the medium access control and the
distributed data storage. The document is divided to two parts where the first part is a state of the
art of different existing works and the second part describes our contribution.
In the first contribution, we have proposed two MAC protocols. The first one optimizes the
wireless sensor networks lifetime for surveillance applications and the second one reduces the
transmission latency in event-driven wireless sensor networks for critical applications.
In the second contribution, we have worked with several data storage models in wireless sensor
network and we focus on the data-centric storage model. We have proposed a clustering structure
for sensors to improve the routing and reduce the number of transmissions in order to prolong the
network lifetime.
Keywords: Energy save, Transmission latency, MAC protocol, Sensor networks, Distributed data
storage
145
146

thèse - LIFC - Université de Franche

Transcription

Documents pareils

Pas à pas bracelet brésilien

To OLIVER - Seatronic

/DNA/01-Q11/Parutions/2016-02-18/Pages/Locales/Haguenau

Collettori solari FR

shenandoah vers la baltique (2)

Tuto fashion papier crepon LoliRock

Catalogue - Mark-10

Feuillet Aéro-Solaire AULNOY.pub

CHAUFFE-EAU SOLAIRES

Imprimer - Propriétés Privées