Anne 2009

THESE
prsente LU.F.R DES SCIENCES ET TECHNIQUES DE LUNIVERSITE DE FRANCHE-COMTE pour obtenir GRADE DE DOCTEUR DE LUNIVERSITE DE FRANCHE-COMTE Spcialit : Informatique

CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS

par

Kamal BEYDOUN

Soutenue le 16 dcembre 2009 devant la commission dexamen :

Directeurs de thse

Herv GUYENNET Violeta FELEA

Professeur, Universit de Franche-Comt Matre de confrences, Universit de Franche-Comt Professeur, Universit de Paris XII Professeur, Universit de Reims Champagne-Ardenne Professeur, Universit de Cergy-Pontoise Professeur, Universit de Franche-Comt

Rapporteurs

Abdelhamid MELLOUK Michael KRAJECKI

Examinateur

Mohamed NAIMI Jean-Christophe LAPAYRE

Remerciements
Je tiens remercier en premier lieu Mr. Herv GUYENNET et Mlle Violeta FELEA, mes directeurs de thse pour leur encouragement, leur disponibilit, leurs ides, leurs conseils et leur sympathie qui mont permis de mener bien cette thse. Jadresse aussi mes trs sincres remerciements Mr. Jean-Christophe LAPAYRE pour lhonneur qui nous a t accord en prsidant le jury. Jexprime ensuite ma plus profonde gratitude Mr. Abdelhamid MELLOUK et Mr. Michael KRAJECKI qui ont accept de rapporter cette thse. Je tiens remercier galement Mr Mohamed NAIMI davoir examin la thse. Jai beaucoup apprci leur participation au jury de cette thse malgr le long voyage. Ce travail a t ralis au sein du Laboratoire dInformatique de lUniversit de Franche-Comt (LIFC). Je tiens donc remercier les responsables de ce laboratoire de mavoir accueilli et donn lopportunit de raliser ce travail de thse. Un grand merci tous les membres du Laboratoire dInformatique de lUniversit de FrancheComt qui mont procur une ambiance chaleureuse pour effectuer mon travail ainsi quun sjour extrmement agrable. Merci tous mes collgues de lquipe Rseaux de Capteurs : Hung-Cuong LE, Pamba CAPOCHICHI, David MARTINS, et Mohamad LEHSAINI pour leur sympathie durant le temps o on a travaill ensemble et pour les discussions de recherche dans le domaine des rseaux de capteurs. Merci galement mon cher ami Dr Jalal JOMAAH pour son soutien indfectible dans les moments difficiles. Merci tous mes amis libanais, franais et de toute nationalit qui mont normment soutenu aux moments les plus difficiles et qui taient toujours prs de moi. Je noublierai jamais les moments quon a passs ensemble. Un merci sans gal ma famille au Liban pour son soutien, son encouragement et dtre le pilier de ma russite, merci eux davoir t mon ct en France malgr mon absence prolonge surtout ma mre que jaime et jadore. Enfin et avant tout, le grand et le vrai merci Dieu qui ma donne la force et la vie pour accomplir cette tache.

Ddicace

A celui que jaime

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

TABLE DES MATIRES

Introduction ...................................................................................................................... 17 Chapitre 1. Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques . 21
1.1 1.2 Introduction .................................................................................................................. 21 Les rseaux Ad-hoc ...................................................................................................... 21
1.2.1 1.2.2 1.2.3 Classification des protocoles de routage Ad-hoc......................................................... 24 Mthodes utilises par les protocoles de routage Ad-hoc ........................................... 25 Distance Vector vs Link State ..................................................................................... 27

1.3

Les rseaux de capteurs ................................................................................................ 27

1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 Le capteur .................................................................................................................... 27 Architecture physique dun capteur intelligent............................................................ 28 Caractristiques principales dun capteur .................................................................... 29 Dfinition dun rseau de capteurs sans fil .................................................................. 31 Enjeux particuliers dans les rseaux de capteurs ......................................................... 34

1.4

Conclusion .................................................................................................................... 35

Chapitre 2. Protocoles de routage dans les rseaux de capteurs ................................. 37

2.1 2.2 Introduction .................................................................................................................. 37 Protocoles de routage non hirarchiques ...................................................................... 38
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9 Introduction ................................................................................................................. 38 DSDV (Destination Sequenced Distance Vector) ....................................................... 39 GSR (Global State Routing) ........................................................................................ 39 FSR (Fisheye State Routing) ....................................................................................... 40 AODV (Ad-hoc On Demand Distance Vector) ........................................................... 42 DSR (Dynamic Source Routing) ................................................................................. 43 OLSR (Optimized Link State Routing) ....................................................................... 44 GPSR (Greedy Perimeter Stateless Routing) .............................................................. 46 SPIN (Sensor Protocol for Information via Negotiation) ............................................ 47

2.3

Protocoles de routage hirarchiques ............................................................................. 48

2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7

Introduction ................................................................................................................. 48 ZHLS (Zone-based Hierarchical Link State Protocol) ................................................ 49 CGSR (Clusterhead Gateway Switch Routing) ........................................................... 51 CBRP (Cluster Based Routing Protocol)..................................................................... 52 LEACH (Low Energy Adaptive Clustering Hierarchy) .............................................. 52 PEGASIS (Power-Efficient Gathering in Sensor Information Systems)..................... 54 TEEN (Threshold-sensitive Energy Efficient sensor Network protocol) .................... 54

2.3.8 APTEEN (Adaptive Threshold-sensitive Energy Efficient sensor Network protocol) .................................................................................................................................... 55 2.3.9 VGA (Virtual Grid Architecture routing) .................................................................... 56

2.3.10 CTLMN (Clustering Technique for Large multihop Mobile wireless Networks) ....... 56 2.3.11 HEED (Hybrid, Eenergy-Efficient, Distributed approach) ......................................... 57 2.3.12 CSOS (Cluster-based Self-Organization algorithm for wireless Sensor networks) .... 57 2.3.13 SAR (Sensor Aggregates Routing) .............................................................................. 58 2.3.14 TTDD (Two-Tier Data Dissemination) ....................................................................... 59

2.4

Conclusion .................................................................................................................... 59

Chapitre 3. Protocole hirarchique de routage bas sur les zones (ZHRP - Zonebased Hierarchical Routing Protocol) ....................................................... 63
3.1 3.2 Introduction .................................................................................................................. 63 Algorithme distribu de partitionnement dun rseau de capteurs en zones ................ 64
3.2.1 3.2.2 3.2.3 Structure du paquet de contrle chang ..................................................................... 68 Description de lalgorithme distribu de partitionnement en zones ............................ 70 Maintenance de la topologie ........................................................................................ 72

3.3 3.4

Construction de la table de routage intra-zone ............................................................. 73 Construction de la table de routage inter-zones ........................................................... 76
3.4.1 3.4.2 3.4.3 Structure du paquet chang ........................................................................................ 76 Algorithme distribu de construction des tables inter-zones ....................................... 77 Exemple de table inter-zones....................................................................................... 81

3.5

Scnario de routage de donnes ................................................................................... 82

3.5.1 3.5.2 Structure du paquet de donnes ................................................................................... 82 Dtails de lapplication du scnario de routage ........................................................... 83

3.6 3.7

Maintenance des tables de routage ............................................................................... 86 Conclusion .................................................................................................................... 87

Chapitre 4. Exprimentations et rsultats ..................................................................... 91

4.1 4.2 4.3 Introduction .................................................................................................................. 91 Le simulateur J-Sim ...................................................................................................... 91 Larchitecture dtaille de J-Sim .................................................................................. 94
4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 Le composant............................................................................................................... 94 Le port ......................................................................................................................... 94 Le contrat ..................................................................................................................... 94 Langage utilis pour dfinir un scnario de simulation ............................................... 94 Modle de transmission dans J-Sim ............................................................................ 95

4.4

Evaluation du protocole de routage propos ................................................................ 96

4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 Evaluation du taux derreur ......................................................................................... 96 Evaluation du surcot .................................................................................................. 98 Evaluation de la dure de vie ..................................................................................... 108 Evaluation de la taille de lespace de stockage .......................................................... 110 Evaluation de la scalabilit ........................................................................................ 111

4.5

Conclusion .................................................................................................................. 112

Chapitre 5. Mise en uvre du protocole de routage ................................................... 113

5.1 5.2 Introduction ................................................................................................................ 113 Plateformes dexploitation pour les capteurs ............................................................. 114
5.2.1 5.2.2 TinyOS ...................................................................................................................... 114 SPOT (Small Programmable Object Technology) .................................................... 114

5.3

Description et mise en place du systme .................................................................... 115

5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 Premire tape : injection du protocole dans le capteur ............................................ 115 Deuxime tape : dploiement des capteurs .............................................................. 117 Troisime tape : partitionnement du rseau en zones .............................................. 117 Quatrime tape : construction des tables de routage intra-zone............................... 118 Cinquime tape : construction des tables de routage inter-zones ............................ 118

5.4

Fonctionnement du systme ....................................................................................... 119

5.4.1 5.4.2 5.4.3 Echange de donnes sans station de base .................................................................. 120 Echange de donnes avec station de base .................................................................. 121 Panne, apparition, et mobilit dun nud .................................................................. 122

5.5

Applications utilisant notre systme ........................................................................... 122

5.5.1 5.5.2

Guidage dun vhicule ............................................................................................... 123 Dtection de feu dans une fort ................................................................................. 126

5.6

Conclusion .................................................................................................................. 127

Chapitre 6. Conclusion .................................................................................................. 129

Perspectives ............................................................................................................................ 130

Bibliographie .................................................................................................................. 133

10

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Table des illustrations

Figure 1.1: Rseau mobile Ad-hoc ........................................................................................................ 22 Figure 1.2 : Classification des rseaux .................................................................................................. 23 Figure 1.3 : Fonctionnement dun capteur ............................................................................................ 28 Figure 1.4 : Architecture physique dun capteur intelligent .................................................................. 29 Figure 1.5 : Rayons de communication et de sensation dun capteur ................................................... 30 Figure 1.6 : Exemple de capteur intelligent MICA2 de Crossbow ....................................................... 30 Figure 1.7 : Exemple de rseau de capteurs .......................................................................................... 31 Figure 2.1 : Communication multi-sauts entre A et D .......................................................................... 38 Figure 2.2 : Technique "il de poisson" dans le protocole FSR ........................................................... 41 Figure 2.3 : Fonctionnement de la procdure de demande de route dans AODV ................................. 43 Figure 2.4 : Diffusion pure et diffusion en utilisant les MPRs dans OLSR .......................................... 45 Figure 2.5 : Fonctionnement du protocole SPIN (48) ........................................................................... 47 Figure 2.6 : Architecture en cluster ....................................................................................................... 49 Figure 2.7 : Dcomposition du rseau en zones dans ZHLS ................................................................. 49 Figure 2.8 : Formation de clusters dans LEACH (55)........................................................................... 53 Figure 2.9 : Classification des principales structures hirarchiques dun rseau .................................. 60 Figure 3.1 : Rseau de capteurs partitionn en zones ............................................................................ 64 Figure 3.2 : Taux des nuds-invitant proximit (Tr= 150m) ............................................................. 66 Figure 3.3 : Taux des nuds-invitant proximit (Tr= 300m) ............................................................. 67 Figure 3.4 : Partitionnement dun rseau en zones................................................................................ 68 Figure 3.5: Algorithme de partionnement dun rseau en zones virtuelles ........................................... 70 Figure 3.6 : Exemple dune rpartition de nuds dans trois zones ....................................................... 75 Figure 3.7 : Algorithme denvoi de la table inter-zones par le noeud-chef ........................................... 79

11

Figure 3.8 : Algorithme de construction de la table inter-zones ........................................................... 80 Figure 3.9 : Rseau dcoup en 9 zones ................................................................................................ 81 Figure 3.10 : Algorithme appliqu par le noeud source lors de lenvoi dun paquet de donnes ......... 84 Figure 3.11: Algorithme appliqu lors de la rception dun paquet de donnes ................................... 85 Figure 4.1 : Connexions entre composants dans J-Sim ......................................................................... 92 Figure 4.2 : Architecture interne dun noeud sensor dans J-Sim (78) ................................................... 93 Figure 4.3 : Champs de voisinage dans J-Sim ....................................................................................... 95 Figure 4.4 : Taux derreur pour 400 nuds ........................................................................................... 97 Figure 4.5 : Taux derreur pour 500 nuds ........................................................................................... 97 Figure 4.6 : Taux derreur pour 600 noeuds .......................................................................................... 98 Figure 4.7 : Nombre de paquets envoys durant la phase de partitionnement en zones pour 400 nuds ............................................................................................................................................................... 99 Figure 4.8 : Nombre de paquets envoys durant la phase de partitionnement en zones pour 500 nuds ............................................................................................................................................................... 99 Figure 4.9 : Nombre de paquets envoys durant la phase de partitionnement en zones pour 600 nuds ............................................................................................................................................................. 100 Figure 4.10 : Nombre de paquets reus durant la phase de partitionnement en zones pour 400 nuds ............................................................................................................................................................. 100 Figure 4.11 : Nombre de paquets reus durant la phase de partitionnement en zones pour 500 nuds ............................................................................................................................................................. 101 Figure 4.12 : Nombre de paquets reus durant la phase de partitionnement en zones pour 600 nuds ............................................................................................................................................................. 101 Figure 4.13 : Nombre de paquets envoys durant la phase de construction des tables de routage pour 400 nuds ........................................................................................................................................... 103 Figure 4.14 : Nombre de paquets envoys durant la phase de construction des tables de routage pour 500 nuds ........................................................................................................................................... 103 Figure 4.15 : Nombre de paquets envoys durant la phase de construction des tables de routage pour 600 nuds ........................................................................................................................................... 104 Figure 4.16 : Nombre de paquets reus durant la phase de construction des tables de routage pour 400 nuds .................................................................................................................................................. 105

12

Figure 4.17 : Nombre de paquets reus durant la phase de construction des tables de routage pour 500 nuds .................................................................................................................................................. 105 Figure 4.18 : Nombre de paquets reus durant la phase de construction des tables de routage pour 600 nuds .................................................................................................................................................. 106 Figure 4.19 : Pourcentage de la consommation nergtique de la batterie en variant le rayon de la zone R .......................................................................................................................................................... 107 Figure 4.20 : Pourcentage de la consommation nergtique de la batterie en variant le nombre de zones zN ........................................................................................................................................................ 107 Figure 4.21 : Pourcentage de la consommation nergtique de la batterie ......................................... 109 Figure 4.22 : Dure de vie du systme avec des vnements priodiques .......................................... 109 Figure 4.23 : Partitionnement dun rseau de 800 nuds en 10 zones................................................ 112 Figure 5.1 : Capteur SPOT fabriqu par SUN Microsystems (94) ...................................................... 115 Figure 5.2 : Capture dcran de loutil SerialForwarder .................................................................... 116 Figure 5.3 : Propagation des paquets dinvitation dans le rseau ........................................................ 118 Figure 5.4 : Echange de donnes entre les nuds du rseau ............................................................... 119 Figure 5.5 : Collecte des informations et envoi la station de base.................................................... 120 Figure 5.6 : Systme de guidage dun vhicule ................................................................................... 123 Figure 5.7 : Construction du chemin vers la destination ..................................................................... 124 Figure 5.8 : Dplacement du vhicule sur le chemin .......................................................................... 125 Figure 5.9 : Systme de dtection de feu dans une fort ..................................................................... 126 Figure 5.10 : Dtection dun nouveau feu lors de lintervention des pompiers .................................. 127

13

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Liste des tableaux

Tableau 1 : Bilan des protocoles de routage hirachique dans les rseaux Ad-hoc et de capteurs ....... 61 Tableau 2 : Champs du paquet ConstructZonesPacket ......................................................................... 69 Tableau 3 : Exemple de table-frontire BorderTable .......................................................................... 72 Tableau 4 : Table de routage intra-zone chez le nud N6 .................................................................... 76 Tableau 5 : Structure du paquet de contrle InterZonesPacket ............................................................. 77 Tableau 6 : Table inter-zones chez N6 appartenant la zone Z2 .......................................................... 78 Tableau 7 : Table de routage inter-zones des nuds BORDER da la zone Z1 ...................................... 82 Tableau 8 : Structure dun paquet DataPacket ...................................................................................... 82 Tableau 9 : Caractristiques dun capteur MICA2 .............................................................................. 106 Tableau 10 : Nombre d'vnements durant la simulation ................................................................... 108 Tableau 11 : Caractristiques dun capteur Tmote SKY ..................................................................... 108 Tableau 12 : Taille thorique de lespace de stockage (en octets) de la structure de donnes de routage ............................................................................................................................................................. 110 Tableau 13 : Taille exprimentale de lespace de stockage (en octets) pour la structure de donnes de routage dans un rseau de 600 nuds ................................................................................................. 111

15

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Introduction

Lvolution rcente de la socit sappuie sur des techniques de plus en plus tournes vers la communication, limage et la mobilit. Le tlphone portable et Internet sont les vecteurs principaux de cette rvolution technologique. A ct de ces techniques plutt lies aux loisirs se dveloppent galement des dispositifs pour amliorer notre connaissance du monde extrieur. Les informations recueillies dans la nature par exemple, vont tre rcupres pour tre intgres au processus de dcision. Le besoin dchange rapide dinformations et le dveloppement des communications ont abouti la cration dInternet qui rend accessible au monde entier une grande quantit de donnes et de services. Internet suscite une passion croissante, tant dans le domaine de la recherche, de lducation que celui des affaires. Ainsi le nombre de personnes qui accdent Internet pour leur travail, leurs tudes ou leurs loisirs augmente sans cesse, de mme que les services offerts sur ce rseau (messagerie lectronique, moteur de recherche, e-commerce, e-learning, etc.). Dans un avenir proche, Internet va enrichir ses bases de donnes avec des informations temps rel directement issues de phnomnes naturels. De plus, Internet ne va plus relier seulement les hommes, mais galement les objets. Toute cette volution ne pourrait se raliser sans une volution dans le domaine de la communication principalement sans fil et linformatique mobile gagne de plus en plus de popularit. Les dispositifs mobiles deviennent de plus en plus nombreux (PDA, laptops, etc.), ceci permettant lapparition de rseaux locaux sans fil dans les entreprises et mme chez les particuliers. La communication au sein de lenvironnement non-filaire se base essentiellement sur la transmission radio. Cependant cet environnement engendre de nouveaux problmes tels que les dconnexions frquentes, les dbits variables, et la quantit dnergie limite des clients mobiles. Mais ces environnements sans fil offrent une grande flexibilit demploi, et permettent la mise en rseau de sites dont le cblage eut t difficile et coteux raliser, ou mme impossible. Les progrs technologiques dans les domaines de la microlectronique, des communications sans

17

Introduction fil, coupls aux efforts de miniaturisation et la rduction des cots de production des composants lectroniques, ont permis le dveloppement de nouvelles gnrations de rseaux sans fils. Ces derniers offrent beaucoup davantages notamment en termes de dploiement. Cependant, de nouveaux problmes surgissent qui rendent les rseaux sans fils moins fiables que les rseaux filaires. Aussi de nouvelles techniques doivent tre mises en uvre pour pallier ces problmes. Des rseaux pour tlphones mobiles aux rseaux locaux sans fil en passant par les rseaux adhoc, la recherche aujourdhui sest beaucoup focalise sur les rseaux de capteurs sans fil (Wireless Sensor Network - WSN). Ceux-ci sont composs dun grand nombre de nuds communicants et distribus sur une zone donne afin de mesurer une grandeur physique ou surveiller un vnement. Dans un tel rseau, chaque nud est un dispositif lectronique qui possde une capacit de calcul, de stockage, de communication et dnergie. Les caractristiques particulires des WSNs modifient les critres de performances par rapport aux rseaux sans fil traditionnels. Dans les rseaux locaux filaires ou les rseaux cellulaires, les critres les plus pertinents sont le dbit, la latence et la qualit de service car les nouvelles activits telles que le transfert dimages, le transfert de vidos, et la navigation sur Internet requirent un dbit important, une faible latence, et une bonne qualit de service. En revanche, dans les rseaux de capteurs conus pour surveiller une zone dintrt, la longvit du rseau est fondamentale. De ce fait, la conservation de lnergie est devenue un critre de performance prpondrant et se pose en premier lieu tandis que les autres critres comme le dbit ou lutilisation de la bande passante sont devenus secondaires. La technique des WSNs peut tre applique dans de nombreux domaines : surveillance des dplacements des vhicules en zone hostile, observation de la vie des espces rares, surveillance de la structure des infrastructures, optimisation de traitement pour les patients etc. Le routage est fondamental dans ce type de rseau car il nexiste pas dinfrastructure qui gre les informations changes entre les diffrents nuds du rseau (comme par exemple les routeurs dans les rseaux filaires). En effet, cest chaque nud du rseau de jouer le rle dun routeur. Ainsi, tous les nuds collaborent afin de router une information vers une certaine destination. Lobjectif de cette thse est de traiter le problme du routage dans les rseaux de capteurs, surtout ceux taille importante. Le souci principal est de prolonger la vie du systme en conomisant lnergie dpense par chaque capteur du rseau. Pour cela, nous avons propos un algorithme de partitionnement du rseau en zones (ensemble de nuds), un algorithme de construction des tables de routage lintrieur de la zone (intra-zone) et entre les zones (interzones), et un algorithme de routage de donnes entre les nuds bas sur la topologie en zones. Le partitionnement du rseau est bas sur le nombre de sauts. Contrairement la plupart des algorithmes de partitionnement (par exemple la clusterisation), cet algorithme nexige aucune information sur le rseau (position gographique des nuds, tat des liens, nergie des nuds, etc.). Lalgorithme de construction des tables de routage (intra-zone et inter-zones) est bas sur lalgorithme Distance Vector (DV) qui a t modifi pour rpondre aux hypothses et contraintes. Lalgorithme de routage de donnes se base sur larchitecture en zones. Le routage se ralise deux niveaux : lintrieur de la zone et entre les zones. Ces algorithmes, constituant un protocole de routage appel ZHRP (Zone-based Hierarchical Routing Protocol), a t valu laide du

18

simulateur J-Sim. Les rsultats obtenus ont montr lefficacit du protocole surtout dans les rseaux de capteurs grande chelle. Cette thse est organise en 6 chapitres. Le premier chapitre introduit la thse et positionne le sujet dans la thmatique des rseaux sans fil. Nous dcrivons larchitecture dun capteur et nous prsentons les principes et les caractristiques des rseaux Ad-hoc et des rseaux de capteurs (sous classes des rseaux Ad-hoc) aussi que ses domaines dapplication. Dans le deuxime chapitre, nous donnons un tat de lart sur les protocoles de routage dans les rseaux Ad-hoc et nous focalisons notre prsentation sur les protocoles de routage dans les rseaux de capteurs. Le troisime chapitre prsente notre protocole de routage ZHRP. Nous montrons dabord en dtail un algorithme distribu de partitionnement dun rseau de capteur en zones, bas sur le nombre de sauts. Dans cet algorithme, nous nutilisons aucune information du rseau pour la construction de la topologie hirarchique. Nous essayons de minimiser les changes entre les nuds afin dconomiser leur nergie. Ensuite, nous dtaillons les phases de construction des tables de routage en se basant sur lalgorithme DV qui est simple et efficace dans les petits rseaux. A la fin de ce chapitre, nous montrons lalgorithme de routage des donnes entre les nuds du rseau en se basant sur larchitecture hirarchique ainsi que la maintenance du rseau lors dune panne, de lapparition ou de la mobilit dun nud. Dans le quatrime chapitre nous prsentons le simulateur que nous avons choisi J-Sim. Lavantage de ce simulateur par rapport aux autres est quil est open source. Les rsultats obtenus montrent que notre algorithme se comporte bien. En effet, nous avons valu le protocole en utilisant cinq mtriques : le taux derreur, le surcot, la consommation nergtique, la scalabilit, et lespace de stockage. Les rsultats des simulations ont montr que le taux derreur, dfini comme le nombre de nuds non affects aucune zone, est gal zro dans la plupart des cas. Ces rsultats montrent aussi un faible surcot pour construire la topologie hirarchique et les tables de routage, do la faible consommation nergtique. De mme, nous avons montr que notre protocole se comporte bien dans les rseaux grande chelle (500 et 600 nuds). Enfin, nous avons calcul lespace de stockage exig pour stocker les informations utiles pour le routage et nous avons montr que la taille de cet espace est modeste pour un capteur MICA2. Nous tudions la faisabilit dune implmentation de notre proposition dans le chapitre 5 laide de capteurs MICA2 et du systme dexploitation Tiny-OS. Nous dcrivons le comportement du systme et nous dtaillons deux applications relles. Nous concluons cette thse dans le chapitre 6 et donnons quelques perspectives de travail. En particulier, nous proposons de continuer ce travail en une approche de routage qui sadapte aux applications o le Sink est mobile sur un chemin non dfini pralablement. Une autre perspective consiste proposer une technique pour mettre en veille un ensemble de nuds ou une zone afin de prolonger la vie du systme. Nous proposons galement dintgrer dans notre protocole une mthode pour lagrgation des donnes collectes.

19

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Chapitre 1. Rseaux

Ad-hoc

et

rseaux

de

capteurs : principes et caractristiques

1.1

Introduction

Comme nous lavons vu dans les pages prcdentes, lapparition rcente des communications sans fil accessibles sur des portables, lvolution des dispositifs de calcul et les progrs dans linfrastructure de communication ont abouti la croissance rapide des rseaux sans fil. Ceux-ci sont gographiquement tendus (GSM, Wimax), locaux (802.11, Zigbee) ou personnels (Bluetooth). On trouve galement les NFC (Near Field Communication) utiliss pour de nouveaux services (paiement des transports, affichage dinformations contextuelles) et des RFID qui permettent doptimiser le fonctionnement des processus internes de lentreprise, comme la logistique, la traabilit ou la production par exemple. On assiste la croissance exponentielle des rseaux cellulaires qui sont bass sur la combinaison de technologies cbles et sans fil. Dans les rseaux cellulaires, comme les GSM, chaque antenne couvre un territoire dfini et lors des dplacements de lutilisateur le tlphone mobile change de cellule. On dit que ce type de rseau a une infrastructure fixe bien dfinie. Lorsque cette infrastructure pour grer le rseau nexiste pas, on parle alors de rseau Ad-hoc. Un tel rseau se caractrise donc par labsence dinfrastructure pour les nuds qui le composent. Les nuds jouent donc un rle primordial dans le transfert des informations et la gestion du routage de celles-ci, devant entre autre grer les reconfigurations topologiques. Cette caractristique, couple la forte implication des nuds dans le transfert des informations via des technologies sans fil, rendent la qualit de service, le routage et la scurit beaucoup plus complexes raliser.

1.2

Les rseaux Ad-hoc

Un rseau sans fil (ou non filaire) est un rseau informatique qui connecte les diffrents quipements entre eux par ondes radio. La norme la plus utilise actuellement pour les rseaux

21

Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques sans fil privs est la norme IEEE 802.11. Le rseau filaire relie les quipements par des cbles classiques. Ainsi, il est possible de crer un rseau mixte qui utilise la communication filaire et non filaire. Le principal dfi dun rseau filaire ou non filaire est sa gestion qui se complique suivant que lon est en mode sans infrastructure ou en mode avec infrastructure. Deux types de dispositifs composent un rseau : dune part, il sagit des quipements qui utilisent le rseau afin de pouvoir communiquer de linformation et dautre part, des quipements qui aident la communication. On parle dappareils tlphoniques vs les commutateurs (switch), dans la tlphonie, ou dordinateurs, de serveurs vs les routeurs, les commutateurs ou les concentrateurs (hub) dans linternet ou encore de tlphones portables vs les points daccs dans les rseaux cellulaires. Ces types de rseaux utilisent le mode avec infrastructure puisque les quipements ont besoin dune base architecturale pour grer le rseau. Dans le rseau sans infrastructure, il ny a pas besoin dune infrastructure prexistante (point daccs par exemple) pour grer le rseau : chaque membre du rseau peut recevoir et envoyer ses informations mais il agit aussi comme un routeur pour transfrer dautres donnes aux autres membres du rseau. Ce type de rseau est appel rseau Ad-hoc. Actuellement, le nombre dutilisateurs du rseau cellulaire approche des quatre milliards dans le monde. Bien que les efforts de recherche et de dveloppement consacrs aux rseaux sans fil traditionnels soient toujours considrables, lintrt de la communaut scientifique et industrielle dans le domaine des tlcommunications a rcemment chang avec des scnarios plus stimulants dans lesquels un groupe dunits mobiles quipes dmetteurs-rcepteurs de radio communiquent sans aucune infrastructure fixe.

Figure 1.1: Rseau mobile Ad-hoc

Plusieurs systmes utilisent dj le modle cellulaire et connaissent une trs forte expansion lheure actuelle mais requirent une importante infrastructure logistique et matrielle fixe. La contrepartie des rseaux cellulaires sont les rseaux mobiles Ad-hoc1. Un rseau mobile Ad-hoc peut tre dfini comme une collection dentits mobiles interconnectes par une technologie sans fil formant un rseau temporaire sans laide de toute administration ou de tout support fixe (voir la

Appel gnralement MANET (Mobile Ad hoc NETwork)

22

Les rseaux Ad-hoc Figure 1.1). Une dfinition de ces rseaux est donne formellement dans RFC2501 (1) : Un rseau mobile Ad-hoc comprend des plates-formes mobiles (par exemple, un routeur interconnectant diffrents htes et quipements sans fil) appeles nuds qui sont libres de se dplacer sans contrainte. Un rseau mobile Ad-hoc est donc un systme autonome de nuds mobiles. Ce systme peut fonctionner dune manire isole ou sinterfacer des rseaux fixes au travers de passerelles. Cest la caractristique qui distingue les rseaux mobiles Ad-hoc des rseaux sans fil plus traditionnels comme les rseaux cellulaires et les rseaux locaux sans fil. Aucune supposition ou limitation nest faite sur la taille du rseau. Cela veut dire quil est possible que ce type de rseau ait une taille trs importante. La Figure 1.2 rsume, de faon hirarchique, les types des rseaux avec leurs noms (les feuilles de lhirarchie). Nous citons un exemple pour chaque type de rseau : LAN (Local Area Network) et WAN (Wired Area Network) plusieurs quipements (ordinateurs, imprimantes, serveurs, etc.) connects ensemble via des cbles, Ad-hoc filaire deux ordinateurs connects via un cble, WLAN (Wireless Local Area Network) le rseau cellulaire (GSM) compos de tlphones mobiles sans fil et des stations fixes, MANET (Mobile Ad-hoc NETwork) plusieurs quipements mobiles connects via le radio, Ad-hoc non filaire plusieurs quipements fixes connects via le radio.

rseau

filaire

non filaire

avec infrastructure

sans infrastructure

avec infrastructure

sans infrastructure

mobile

fixe

WAN, LAN

Ad-hoc filaire

WLAN

MANET

Ad-hoc non filaire

Figure 1.2 : Classification des rseaux

23

Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques Dans la suite de notre document, lorsque nous parlons dun rseau Ad-hoc nous sous-entendons un rseau Ad-hoc non filaire. En effet, un rseau Ad-hoc filaire (des quipements connects avec fils) na pas beaucoup dintrt et par consquent, son utilisation est trs rare. Une application trs importante des rseaux Ad-hoc est celle de la mise en place rapide dun rseau de communication dans le cas de catastrophe majeure sur des zones dpourvues dinfrastructures ou encore dans le cas o linfrastructure existante est hors service, voire compltement dtruite. Les exemples les plus ralistes sont ceux de zones soumises des catastrophes naturelles comme les tremblements de terre, les inondations, etc. Les quipes de secours ont besoin de mettre rapidement en place un rseau de communication pour coordonner les recherches, les informations logistiques, voire dsenclaver les populations isoles en leur offrant rapidement un moyen de communication. Une autre application concerne le domaine militaire, puisquun tel rseau peut tre utilis pour assurer la liaison entre les diffrentes units dune arme. Vu les caractristiques et les limitations quengendre un rseau Ad-hoc, plusieurs problmes ont t poss pour ce type de rseaux : problme dacheminement de linformation, problme de sources dnergies (capacit des batteries), linteroprabilit avec dautres types de rseaux, etc. Nous nous sommes intresss aux problmatiques poses par le routage dans ce type de rseaux et aux solutions proposes.

1.2.1 Classification des protocoles de routage Ad-hoc

Suivant la mthode de cration et la maintenance des routes lors de lacheminement des paquets, les protocoles de routage dans les rseaux Ad-hoc peuvent tre classs en trois catgories : proactifs, ractifs et hybrides.

a) Protocoles de routage proactifs

Ils sont bass sur le mme principe de routage que les rseaux filaires. Les routes dans ce type de routage sont calcules lavance. Chaque nud met jour plusieurs tables de routage par change de paquets de contrle entre voisins. En effet, si un nud veut communiquer avec un autre, il a la possibilit de consulter localement la table de routage et de crer le chemin dont il a besoin. Le besoin de conserver et de contrler la validit des tables de routages en permanence (comprenant en outre des informations qui ne seront sans doute pas utilises) est le principal inconvnient des protocoles proactifs. Par contre, ils prsentent limportant avantage de ne ncessiter aucun dlai avant de transmettre un paquet puisque la route est dj connue. OLSR [ (2), (3)] et FSR [ (4), (5)] sont deux exemples de protocoles proactifs que nous dcrirons plus tard.

b) Protocoles de routages ractifs

Contrairement aux protocoles proactifs, les protocoles ractifs ne calculent la route que sur demande. Si un nud source a besoin denvoyer un message un nud destination, alors il envoie une requte tous les membres de rseau. Aprs la rception de la requte, le nud destination envoie un message rponse qui remonte vers la source (mthode Backward Learning (6)). Cependant, le routage la demande gnre une lenteur cause de la recherche des routes. Cela

24

Les rseaux Ad-hoc peut entraner une dgradation des performances des applications. Ce type de protocole prsente linconvnient dtre trs coteux en transmission de paquets lors de la dtermination des routes mais a lavantage de ne pas avoir maintenir des informations inutilises dans les tables de routage. AODV (6) et DSR [ (7), (8)] sont deux exemples de protocoles ractifs qui seront dcrits ultrieurement.

c) Protocoles de routage hybrides

Les protocoles de routages hybrides ou mixtes combinent les deux types de routages prcdents (proactif et ractif). Le protocole proactif est appliqu dans un primtre rduit autour de la source (nombre limit de voisins), tandis que le protocole ractif est appliqu au del de ce primtre (les voisins lointains). Cette combinaison est ralise dans le but dexploiter les avantages de chaque mthode et de contourner leurs limitations. ZRP et CBRP (9), sont deux exemples de protocoles hybrides que nous dcrirons plus tard.

1.2.2 Mthodes utilises par les protocoles de routage Ad-hoc

Le protocole de routage doit garder la trace des changements sur le rseau et doit partager ces changements avec des nuds dans le rseau. La plupart des protocoles de routage Ad-hoc utilise deux mthodes majeures : vecteur de distance (Distance Vector) et tat de lien (Link State). Par la suite, nous dtaillerons chaque mthode, prsentant ses avantages et ses inconvnients, et nous raliserons une comparaison entre les deux.

a) Distance Vector (DV)

Les protocoles de routage base de la mthode DV [ (10), (11)] tablissent une table de routage recensant le cot de chacune des routes du rseau puis transmettent cette table priodiquement aux nuds voisins. Au dbut, chaque nud dtecte ses voisins directs et construit sa propre table de routage puis il la diffuse ses voisins. Les tables sont mises jour en fonction des informations reues (ajout et modification dune entre) et convergent jusqu ce que la structure du rseau travers ces tables se stabilise. Chaque entre de la table de routage est un triplet (nud destinataire, nud suivant, mtrique) o la mtrique est le cot de la route pour atteindre le nud destinataire en passant par le nud suivant. La mtrique utilise peut tre le nombre de sauts, le dlai dacheminement, le nombre total de paquets en file dattente pour ce parcours, ou un critre semblable (12). Les mises jour rgulires entre les nuds permettent de communiquer les modifications de topologie. Les protocoles de routage vecteur de distance sont conus pour tre excuts sur de petits rseaux (en gnral moins de 100 nuds). DV utilise lalgorithme Bellman-Ford (13) pour calculer le meilleur chemin. Ces protocoles sont gnralement plus faciles configurer et exigent moins de maintenance que les protocoles utilisant la mthode dtat de lien. Si un nud tombe en panne, il nmet plus priodiquement. Ses voisins sen rendent compte et mettent leur mtrique pour ce nud linfini. La construction des tables de routage est ralise par vagues, de manire distribue, ce qui peut

25

Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques entraner des boucles de routage. Une boucle de routage est une route diffuse pour des paquets qui natteignent jamais leur destination : ils passent de faon rpte par la mme srie de nuds du rseau. Des boucles de routage peuvent se produire si la convergence lente dun rseau avec une nouvelle configuration entrane des entres de routage incohrentes. Les tables de routage ne peuvent plus assurer alors leur fonction pour une ou plusieurs destinations, et ainsi tous les paquets destins une entre errone seront transmis mais ne parviendront jamais au nud destination et circuleront sur une boucle constitue de plusieurs nuds (11). Une mtrique de mesure infinie est le rsultat dune boucle de routage qui engage les nuds incrmenter linfini la mtrique de mesure. Pour rsoudre ce problme, plusieurs mthodes ont t proposes (11) : Sequence number chaque entre de la table de routage possde un numro de squence. Par consquent, chaque nud peut rapidement distinguer lancienne route de celle nouvelle, ce qui vite la gnration de la boucle de routage (14). Maximum Count si ce compteur maximum est dfini, cela veut dire que le bouclage linfini sarrte ce nombre maximum. RIP (10) dfinit le compteur maximum 16. Route Poisoning Les nuds envoient des mises jour avec une mtrique infinie pour les routes qui deviennent invalides. Split horizon Le principe de cette technique consiste ne pas renvoyer une information incorrecte de routage vers son endroit de provenance. Holddown Timer Les holddown timers permettent de prvenir contre les mauvaises mises jour des routes invalides. Le holddown timer est dclench lorsquun timer dune route particulire est expir ou il nest plus atteint. Lorsque le holddown timer atteint le zro, la route est supprime et le nud est considr dfaillant. Triggered Update normalement, les tables de routages sont envoyes priodiquement mais un triggered update sera immdiatement envoy en rponse un changement de topologie du rseau. Ds quun nud dtecte un changement sur le rseau il envoie immdiatement une mise jour aux nuds voisins qui leur tour notifient immdiatement leurs voisins adjacents de ce changement. RIP (10), DSDV (14) et AODV (6) sont des protocoles de routage qui utilisent la mthode DV.

b) Link State (LS)

Les protocoles de routage utilisant la mthode LS (15) coutent le rseau en continu afin de recenser les diffrents lments qui lentourent. Chaque nud a une vue globale du rseau reprsent par un graphe. A partir de ces informations (temps, nombre de sauts, distance relle, dlai de transmission, fiabilit, etc.), chaque nud calcule le plus court chemin ( laide de lalgorithme de Dijkstra (16)) vers les nuds du rseau et diffuse cette information sous forme de paquets de mise jour. Les protocoles tat de lien ont t conus pour pallier les limitations des protocoles de routage utilisant le vecteur de distance. Ils ont pour avantage de rpondre rapidement aux moindres changements sur le rseau en envoyant des mises jour dclenches uniquement aprs quune modification soit survenue.

26

Les rseaux Ad-hoc Ds quun nud dtecte la modification dune liaison ou dune route, il cre une mise jour de routage tat de lien (LSA, link-state advertisement) concernant cette liaison. Cette mise jour LSA est ensuite transmise tous les nuds voisins. Chacun deux en prend une copie, met jour sa base de donnes (graphe) tat de lien et transmet la mise jour LSA aux autres nuds voisins. Cette diffusion de mises jour LSA est ncessaire afin que tous les nuds puissent crer des bases de donnes transcrivant de manire prcise la topologie du rseau et mettre jour leur table de routage. Les algorithmes tat de lien se servent gnralement de leurs bases de donnes (graphe) pour crer des entres dans la table de routage qui privilgient le chemin le plus court. Chaque nud construit enfin sa table de routage en calculant les plus courts chemins vers tous les autres nuds ( laide de lalgorithme de Dijkstra). OSPF [ (17), (18)] et OLSR [ (2), (3)] sont deux protocoles de routage bass sur LS.

1.2.3 Distance Vector vs Link State

Il y a deux grandes diffrences entre DV et LS. La premire est que DV change les mises jour de routage priodiquement mme sil ny a pas de changements de topologie. Cela maximise le temps de convergence et augmente les risques de boucles de routage. Dautre part, LS ne dclenche pas denvois de mises jour de routage que lors du changement de topologie. Aprs la premire inondation, des mises jour dtat des liens seront envoyes tous les autres nuds. Ceci permet de minimiser le temps de convergence et cest la raison pour laquelle il ny a aucune chance de boucles de routage. La deuxime diffrence est que dans DV, un nud se base sur les informations de ses voisins connects directement afin de calculer et daccumuler des informations sur les routes. Au contraire, dans LS, un nud ne se base pas uniquement sur linformation de ses voisins pour calculer linformation sur la route. LS a un systme de bases de donnes qui est utilis afin de calculer le meilleur chemin pour des destinations dans le rseau en utilisant lalgorithme de Dijkstra. Pour cela, DV ncessite trs peu de chargements depuis la mmoire et de puissance du processeur par rapport LS. Dans la section suivante, nous dcrirons un rseau Ad-hoc particulier : le rseau de capteurs dont les nuds possdent de faibles capacits dnergie, de stockage et de bande passante.

1.3

Les rseaux de capteurs

1.3.1 Le capteur
a) Modle dun instrument de mesure
Dans son ouvrage sur linstrumentation industrielle, llectronicien Georges Asch (19), a modlis trs prcisment la notion dinstrument de mesure, et donc celle de capteur (Figure 1.3). La grandeur physique objet de la mesure, nomme mesurande (m), est apprhende par diverses oprations exprimentales, que lon regroupe sous le terme de mesurage, qui dans un grand

27

Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques nombre de cas produit un signal lectrique (s) image de la grandeur physique et de ses variations. Le capteur est le dispositif physique qui, soumis laction du mesurande, non lectrique, produit la caractristique lectrique : s=F(m). Or toutes les lois physiques interagissent au sein des matriaux, donc le capteur est obligatoirement sensible dautres grandeurs physiques, secondaires, dites grandeurs dinfluence (20). La caractristique devient alors, en tenant compte des grandeurs dinfluence g1, g2, : s=F(m, g1, g2, ...). Les principales grandeurs dinfluence sont la temprature, lacclration, les vibrations, lhumidit, les champs magntiques (20).
m
s

Capteur
Mesurande (m)

Grandeur lectrique (s)

Figure 1.3 : Fonctionnement dun capteur

Donc, un capteur est un dispositif quip de fonctionnalits de sensation avances. Il mesure ou dtecte un vnement rel, comme le mouvement, la chaleur ou la lumire et convertit la valeur mesure dans une reprsentation analogique ou numrique. Il prlve des informations et labore partir dune grandeur physique (information dentre), une autre grandeur physique de nature lectrique.

b) Le capteur intelligent
Les capteurs intelligents (Smart Sensors) sont des dispositifs matriels dans lesquels coexistent le(s) capteur(s) et les circuits de traitement et de communication. Leurs relations avec des couches de traitement suprieures vont bien au-del dune simple transduction de signal . Les capteurs intelligents sont des capteurs dinformations et non pas simplement des capteurs et des circuits de traitement du signal juxtaposs. De plus, les Smart Sensors ne sont pas des dispositifs banaliss car chacun de leurs constituants a t conu dans lobjectif dune application bien spcifique (20).

1.3.2 Architecture physique dun capteur intelligent

Un capteur intelligent est compos de 4 units (voir la Figure 1.4) : lunit dacquisition compose dun capteur qui obtient des mesures sur les paramtres environnementaux et dun convertisseur Analogique/Numrique qui convertit linformation releve et la transmet lunit de traitement. lunit de traitement compose dun processeur et dune mmoire intgrant un systme dexploitation spcifique (TinyOS (21), par exemple). Cette unit possde deux interfaces, une interface pour lunit dacquisition et une interface pour lunit de communication. Elle

28

Les rseaux de capteurs acquiert les informations en provenance de lunit dacquisition et les envoie lunit de communication. Cette unit est charge aussi dexcuter les protocoles de communications qui permettent de faire collaborer le capteur avec dautres capteurs. Elle peut aussi analyser les donnes captes. lunit de communication unit responsable de toutes les missions et rceptions de donnes via un support de communication radio. Elle peut tre de type optique (comme dans les capteurs Smart Dust (22)), ou de type radiofrquence (MICA2 (23), par exemple). la batterie un capteur est muni dune batterie pour alimenter tous ses composants. Cependant, cause de sa taille rduite, la batterie dont il dispose est limite et gnralement irremplaable. Pour cela, lnergie est la ressource la plus prcieuse puisquelle influe directement sur la dure de vie des capteurs. Il existe des capteurs qui sont dots dautres composants additionnels comme le systme de positionnement GPS (Global Positioning System) et un mobilisateur lui permettant le dplacement. Dans le reste de notre rapport, lorsque nous parlerons de capteur nous sous-entendrons capteur intelligent avec un systme de capture et les circuits de traitement et de communication.

Processeur
Unit dacquisition

Mmoire
Unit de traitement

Unit de communication

Batterie
Figure 1.4 : Architecture physique dun capteur intelligent

1.3.3 Caractristiques principales dun capteur

Deux entits sont fondamentales dans le fonctionnement dun capteur : lunit dacquisition qui est le cur physique permettant la prise de mesure et lunit de communication qui ralise la transmission de celle-ci vers dautres dispositifs lectroniques. Ainsi, fonctionnellement chaque capteur possde un rayon de communication (Rc) et un rayon de sensation (Rs). La Figure 1.5 montre les zones dfinies par ces deux rayons pour le capteur A. La zone de communication est la zone o le capteur A peut communiquer avec les autres capteurs (le capteur B dans la Figure 1.5). Dautre part, la zone de sensation est la zone o le capteur A peut capter lvnement ( (24), (25)).

29

Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques

Rs

B C

Rc

Zone de communication

Zone de sensation

Figure 1.5 : Rayons de communication et de sensation dun capteur

En effet, pour quun capteur ait une porte de communication suffisamment grande, il est ncessaire dutiliser un signal assez puissant. Cependant, lnergie consomme serait importante (26). Il existe dans le monde plusieurs fabricants de capteurs. Nous citerons Crossbow, Cisco, Dalsa, EuroTherm, et Sens2B. Parmi ces capteurs, il existe quelques uns qui sont capables de varier la puissance du signal mis afin dlargir/rduire le rayon de communication et en consquence la zone de communication. La Figure 1.6 montre un capteur intelligent MICA2 fabriqu par Crossbow (27).

Figure 1.6 : Exemple de capteur intelligent MICA2 de Crossbow

30

Les rseaux de capteurs

1.3.4 Dfinition dun rseau de capteurs sans fil

Les rseaux de capteurs sans fil (WSNs2) sont un type particulier de rseau Ad-hoc, dans lesquels les nuds sont des capteurs intelligents . Ils se composent gnralement dun grand nombre de capteurs communicants entre eux via des liens radio pour le partage dinformation et le traitement coopratif. Dans ce type de rseau, les capteurs changent des informations par exemple sur lenvironnement pour construire une vue globale de la rgion contrle, qui est rendue accessible lutilisateur externe par un ou plusieurs nud(s). Les donnes collectes par ces capteurs sont achemines directement ou via les autres capteurs de proche en proche un point de collecte , appel station de base (ou SINK sil sagit dun nud). Cette dernire peut tre connecte une machine puissante via internet ou par satellite. En outre, lutilisateur peut adresser ses requtes aux capteurs en prcisant linformation dintrt.

Internet, satellite,

Station de base Zone dintrt

Utilisateur

Station de base

Capteur

Figure 1.7 : Exemple de rseau de capteurs

Un exemple de rseaux de capteurs est fourni dans la Figure 1.7 : les capteurs sont dploys dune manire alatoire dans une zone dintrt, et une station de base, situe lextrmit de cette zone, est charge de rcuprer les donnes collectes par les capteurs. Lorsquun capteur dtecte un vnement pertinent, un message dalerte est envoy la station de base par le biais dune communication entre les capteurs. Les donnes collectes sont traites et analyses par des machines puissantes. Les rseaux de capteurs viennent en soutien de lenvironnement et de lindustrie grce aux rcents dveloppements raliss dans le domaine des techniques sans fils. Depuis quelques dcennies, le besoin dobserver et de contrler des phnomnes physiques tels que la temprature, la pression ou encore la luminosit est essentiel pour de nombreuses applications industrielles et scientifiques.

Wireless Sensor Networks

31

Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques

a) Domaines dapplication des rseaux de capteurs

La miniaturisation des capteurs, le cot de plus en plus faible, la large gamme des types de capteurs disponibles ainsi que le support de communication sans fil utilis, permettent aux rseaux de capteurs de se dvelopper dans plusieurs domaines dapplication. Ils permettent aussi dtendre les applications existantes. Les rseaux de capteurs peuvent se rvler trs utiles dans de nombreuses applications lorsquil sagit de collecter et de traiter des informations provenant de lenvironnement. Parmi les domaines o ces rseaux peuvent offrir les meilleures contributions, nous citons les domaines : militaire, surveillance, environnemental, mdical, domestique, commercial, etc. (28).

Applications militaires
Le faible cot et le dploiement rapide sont des caractristiques qui ont rendu les rseaux de capteurs efficaces pour les applications militaires. Plusieurs projets ont t lancs pour aider les units militaires dans un champ de bataille et protger les villes contre des attaques, telles que les menaces terroristes. Le projet DSN (Distributed Sensor Network) (29) au DARPA (Defense Advanced Research Projects Agency) tait lun des premiers projets dans les annes 80 ayant utilis les rseaux de capteurs pour rassembler des donnes distribues. Les chercheurs du laboratoire national Lawrence Livermore ont mis en place le rseau WATS (Wide Area Tracking System) (30). Ce rseau est compos de dtecteurs des rayons gamma et des neutrons pour dtecter et dpister les dispositifs nuclaires. Il est capable deffectuer la surveillance constante dune zone dintrt. Il utilise des techniques dagrgation de donnes pour les rapporter un centre intelligent. Ces chercheurs ont mis en place ensuite un autre rseau appel JBREWS (Joint Biological Remote Early Warning System) (31) pour avertir les troupes dans le champ de bataille des attaques biologiques possibles. Un rseau de capteurs peut tre dploy dans un endroit stratgique ou hostile, afin de surveiller les mouvements des forces ennemies, ou analyser le terrain avant dy envoyer des troupes (dtection des armes chimiques, biologiques ou radiations). Larme amricaine a ralis des tests dans le dsert de Californie.

Applications la surveillance
Lapplication des rseaux de capteurs dans le domaine de la scurit peut diminuer considrablement les dpenses financires consacres la scurisation des lieux et des tres humains. Ainsi, lintgration des capteurs dans de grandes structures telles que les ponts ou les btiments aidera dtecter les fissures et les altrations dans la structure suite un sisme ou au vieillissement de la structure. Le dploiement dun rseau de capteurs de dtection de mouvement peut constituer un systme dalarme qui servira dtecter les intrusions dans une zone de surveillance.

Applications environnementales
Le contrle des paramtres environnementaux par les rseaux de capteurs peut donner naissance plusieurs applications. Par exemple, le dploiement des thermo-capteurs dans une fort peut aider dtecter un ventuel dbut de feu et par suite faciliter la lutte contre les feux de fort avant leur propagation. Le dploiement des capteurs chimiques dans les milieux urbains peut aider

32

Les rseaux de capteurs dtecter la pollution et analyser la qualit dair. De mme leur dploiement dans les sites industriels empche les risques industriels tels que la fuite de produits toxiques (gaz, produits chimiques, lments radioactifs, ptrole, etc.). Dans le domaine de lagriculture, les capteurs peuvent tre utiliss pour ragir convenablement aux changements climatiques par exemple le processus dirrigation lors de la dtection de zones sches dans un champ agricole. Cette exprimentation a t ralise par Intel Research Laboratory and Agriculture and Agri-Food Canada sur une vigne British Columbia.

Applications mdicales
Dans le domaine de la mdecine, les rseaux de capteurs peuvent tre utiliss pour assurer une surveillance permanente des organes vitaux de ltre humain grce des micro-capteurs qui pourront tre avals ou implants sous la peau (surveillance de la glycmie, dtection de cancers, etc.). Ils peuvent aussi faciliter le diagnostic de quelques maladies en effectuant des mesures physiologiques telles que : la tension artrielle, battements du cur, etc. laide des capteurs ayant chacun une tche bien particulire. Les donnes physiologiques collectes par les capteurs peuvent tre stockes pendant une longue dure pour le suivi dun patient (32). Dautre part, ces rseaux peuvent dtecter des comportements anormaux (chute dun lit, choc, cri, etc.) chez les personnes dpendantes (handicapes ou ges).

Applications domestiques
Avec le dveloppement technologique, les capteurs peuvent tre embarqus dans des appareils, tels que les aspirateurs, les fours micro-ondes, les rfrigrateurs, les magntoscopes, etc. (33). Ces capteurs embarqus peuvent interagir entre eux et avec un rseau externe via Internet pour permettre un utilisateur de contrler les appareils domestiques localement ou distance. Le dploiement des capteurs de mouvement et de temprature dans les futures maisons dites intelligentes permet dautomatiser plusieurs oprations domestiques telles que : la lumire steint et la musique sarrte quand la chambre est vide, la climatisation et le chauffage sajustent selon les points multiples de mesure, lalarme est dclenche par le capteur anti-intrusion quand un tranger veut pntrer dans la maison.

Applications commerciales
Il est possible dintgrer des capteurs au processus de stockage et de livraison dans le domaine commercial. Le rseau ainsi form pourra tre utilis pour connatre la position, ltat et la direction dun paquet. Il devient alors possible pour un client qui attend la rception dun paquet, davoir un avis de livraison en temps rel et de connatre la localisation actuelle du paquet. Pour les entreprises manufacturires, les rseaux de capteurs permettront de suivre le procd de production partir des matires premires jusquau produit final livr. Grce aux rseaux de capteurs, les entreprises pourraient offrir une meilleure qualit de service tout en rduisant leurs cots (34).

b) Caractristiques des rseaux de capteurs sans fil

Un rseau de capteurs prsente les caractristiques suivantes :

33

Rseaux Ad-hoc et rseaux de capteurs : principes et caractristiques absence dinfrastructure les rseaux Ad-hoc en gnral, et les rseaux de capteurs en particulier se distinguent des autres rseaux par la proprit dabsence dinfrastructure prexistante et de tout genre dadministration centralise. taille importante un rseau de capteurs peut contenir des milliers de nuds. interfrences les liens radio ne sont pas isols, deux transmissions simultanes sur une mme frquence, ou utilisant des frquences proches, peuvent interfrer. topologie dynamique les capteurs peuvent tre attachs des objets mobiles qui se dplacent dune faon libre et arbitraire rendant ainsi la topologie du rseau frquemment changeante. scurit physique limite les rseaux de capteurs sans fil sont plus touchs par le paramtre de scurit que les rseaux filaires classiques. Cela se justifie par les contraintes et limitations physiques qui font que le contrle des donnes transfres doit tre minimis. bande passante limite une des caractristiques primordiales des rseaux bass sur la communication sans fil est lutilisation dun mdium de communication partag. Ce partage fait que la bande passante rserve un nud est limite. contrainte dnergie, de stockage et de calcul - la caractristique la plus critique dans les rseaux de capteurs est la modestie de ses ressources nergtiques car chaque capteur du rseau possde de faibles ressources en termes dnergie (batterie). Afin de prolonger la dure de vie du rseau, une minimisation des dpenses nergtiques est exige chez chaque nud. Ainsi, la capacit de stockage et la puissance de calcul sont limites dans un capteur.

1.3.5 Enjeux particuliers dans les rseaux de capteurs

Dans cette section, nous dcrirons deux enjeux fondamentaux dans les rseaux de capteurs : le routage et la structuration des rseaux. Le routage permet lacheminement des informations vers une destination donne travers un rseau de connexion. Le problme de routage consiste dterminer un acheminement optimal des paquets travers le rseau au sens dun certain critre de performance comme la consommation nergtique. Le problme consiste trouver linvestissement de moindre cot qui assure le routage du trafic nominal et garantit la qualit de service. Le problme qui se pose dans le contexte des rseaux de capteurs est ladaptation de la mthode dacheminement utilise avec le grand nombre de nuds existant dans un environnement caractris par de changements de topologies, de modestes capacits de calcul, de sauvegarde, et dnergie. Toute conception de protocole de routage implique ltude des problmes suivants : Minimiser la charge du rseau en optimisant le nombre denvois et de rceptions des paquets. Cette minimisation aboutit une consommation nergtique minimale et une longue dure de vie du rseau. Offrir un support pour pouvoir effectuer des communications multi-sauts fiables.

34

Les rseaux de capteurs Assurer un routage optimal si possible. Offrir une bonne qualit concernant les temps de latence. Auto organiser le rseau ceci peut tre ncessaire dans plusieurs cas. Un rseau comportant un grand nombre de nuds placs dans des endroits hostiles o la configuration manuelle nest pas faisable doit tre capable de sauto-organiser. Un autre cas est celui o un nud est insr ou retir ( cause dun manque dnergie ou destruction physique). Ainsi le rseau doit tre capable de se reconfigurer pour continuer son fonctionnement. En gnral, le routage dans les rseaux de capteurs peut tre class, selon la structure du rseau, en routage plat et routage hirarchique. Dans le routage plat, tous les nuds ont typiquement les mmes rles et fonctionnalits. Cependant, le routage hirarchique est ralis plusieurs niveaux dans le sens o la vision du rseau est rduite. Certains nuds peuvent jouer des rles particuliers dans le rseau afin de router les informations. Notre intrt sest focalis sur les protocoles hirarchiques. Ces protocoles, proposs lorigine pour les rseaux filaires, sont des techniques bien connues avec des avantages particuliers lis la scalabilit3 et la communication efficace. Le concept de routage hirarchique est aussi utilis pour assurer une efficacit nergtique dans les WSNs. Dans une architecture hirarchique, les nuds qui disposent dune ressource nergtique importante peuvent tre utiliss pour traiter et envoyer les informations tandis que les nuds dnergie basse peuvent tre utiliss pour excuter la capture dinformation dans la proximit de la cible. Le routage hirarchique est une faon de minimiser la consommation nergtique du systme en rduisant la vision globale du rseau en une vision locale dans chaque nud. Ceci aboutit une prolongation de la vie du rseau en entier.

1.4

Conclusion

Dans ce chapitre, nous avons dfini et dcrit brivement ce quest un rseau Ad-hoc et ses caractristiques ainsi quun rseau de capteurs sans fil qui est un type particulier de rseau Ad-hoc. Nous avons dcrit le capteur, ses fonctionnalits et son architecture. Nous avons cit les caractristiques dun rseau de capteurs et prsent quelques applications. Nous avons aussi mis laccent sur le routage et la structuration virtuelle dun rseau qui sont des points essentiels que nous dvelopperons dans la suite de ce document. La classification des protocoles de routage Ad-hoc a t galement dcrite ainsi que des mthodes utilises par ces protocoles (Distance Vector et Link State). Dans la suite, nous prsenterons plusieurs protocoles de routage utiliss dans les rseaux Ad-hoc et de capteurs qui partagent des caractristiques identiques.

Aptitude dun systme de conserver ses proprits fonctionnelles malgr un changement de taille

35

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Chapitre 2. Protocoles de routage dans les rseaux de capteurs

2.1

Introduction

Le routage est une mthode dacheminement des informations vers une destination donne dans un rseau de connexion. Comme nous lavons dj vu, larchitecture des rseaux Ad-hoc est caractrise par labsence dinfrastructure fixe prexistante, linverse des rseaux de tlcommunication classiques. Un rseau Ad-hoc doit sorganiser automatiquement de faon tre dploy rapidement et pouvoir sadapter aux conditions du trafic et aux diffrents mouvements pouvant intervenir au sein des nuds mobiles. Dans le but dassurer la connectivit du rseau, malgr labsence dinfrastructure fixe, chaque nud est susceptible dtre mis contribution pour participer au routage et pour retransmettre les paquets dun nud qui nest pas en mesure datteindre sa destination directement ; tout nud joue ainsi le rle de poste de travail et de routeur. Cest le cas du rseau de capteurs qui est un rseau Ad-hoc avec des contraintes plus fortes dnergie, de capacit, de calcul et de stockage. Chaque nud participe donc au routage ce que lui permet de dcouvrir les chemins existants afin datteindre les autres nuds du rseau. Le fait que la taille dun rseau puisse tre importante, surtout dans le cas des rseaux de capteurs, souligne que les techniques de routage dans les rseaux classiques ncessitent des modifications. Le problme qui se pose dans le contexte de ces rseaux est ladaptation de la mthode dacheminement utilise un grand nombre de nuds possdant de modestes capacits de calculs et de sauvegarde et parfois prsentant des changements de topologie. Il est impossible quun nud puisse garder les informations de routage concernant tous les autres nuds, car le rseau peut tre volumineux. Ce problme ne se pose pas dans le cas des rseaux de petites tailles, car linondation (la diffusion pure qui fait propager un paquet dans le rseau entier)

37

Protocoles de routage dans les rseaux de capteurs faite pour ce but dans ces rseaux nest pas coteuse ; par contre dans un rseau volumineux, le manque de donnes de routage concernant les destinations peut impliquer une large diffusion dans le rseau. Cela si on considre seulement la phase de dcouverte des routes - peut dgrader considrablement les performances du systme caractris principalement par une faible bande passante et une capacit nergtique limite. Dans le cas o le nud destination se trouve dans la porte de communication du nud source, le routage devient vident et aucun protocole de routage nest initi, ce quon appelle envoi direct ou un seul saut. Mais ce cas est gnralement rare dans les rseaux Ad-hoc et les rseaux de capteurs. Un nud source peut avoir besoin de transfrer des donnes un autre nud qui ne se trouve pas dans sa porte de communication. La Figure 2.1 montre un exemple dun rseau constitu de quatre nuds. Le nud A envoie directement un paquet B sans besoin de routage puisque B est dans la porte de communication de A (envoi direct). Dailleurs, si le nud A veut envoyer un paquet au nud D, il doit utiliser les services des nuds intermdiaires B et C puisque le nud D nest pas dans la porte de A. A envoie le paquet B ; B transmet le paquet C ; C, son tour, transmet le paquet au nud D. Cette technique est appele routage multi-sauts (multi-hops).

Figure 2.1 : Communication multi-sauts entre A et D

Dans la suite, nous dcrirons des protocoles de routage dans les rseaux Ad-hoc et de capteurs. Nous les prsenterons sous deux catgories : hirarchique et non hirarchique (ou plat).

2.2

Protocoles de routage non hirarchiques

2.2.1 Introduction
Lobjectif principal dun protocole de routage pour un rseau Ad-hoc est ltablissement correct et efficace ditinraires entre une paire de nuds afin que des messages puissent tre achemins. Le protocole de routage permet aux nuds de se connecter directement les uns aux autres pour

38

Protocoles de routage non hirarchiques relayer les messages par des sauts multiples. Par la suite, nous prsenterons un tat de lart des principaux protocoles de routage plat (non hirarchique) dans les rseaux Ad-hoc car la prsentation de ces protocoles nous permettra de mieux analyser lavantage de lapproche hirarchique surtout dans les grands rseaux. Malgr que notre intrt se focalise sur les protocoles hirarchiques, nous avons rdig cet tat de lart parce quun rseau de capteurs partage forcment des caractristiques et des contraintes des rseaux Ad-hoc quil faut prendre en compte lors dune proposition dun protocole de routage.

2.2.2 DSDV (Destination Sequenced Distance Vector)

DSDV (14) est un protocole proactif de routage vecteur de distance. Chaque nud du rseau maintient une table de routage contenant le saut suivant et le nombre de sauts pour toutes les destinations possibles. Des diffusions de mises jour priodiques tendent maintenir la table de routage compltement actualise tout moment. Afin dviter le bouclage (loop-freedom), DSDV utilise les numros de squence (Sequence Number, voir la section 1.2.2 a) 1.2.2 ) pour indiquer la nouveaut dune route. Une route R est considre plus favorable quune autre R, si R a un numro de squence plus grand ; si ces deux routes ont le mme numro de squence, alors R est plus favorable sil possde un nombre infrieur de sauts. Le numro de squence pour une route est initialis par le nud metteur et incrment pour chaque nouvel avertissement de route. Quand un nud dtecte un lien bris vers une destination D, il met jour le nombre de sauts pour lentre de la destination D dans sa table avec la valeur infini et incrmente son numro de squence. Les boucles de routes peuvent survenir lorsque des informations incorrectes de routage sont prsentes dans le rseau aprs un changement dans la topologie du rseau (lien bris par exemple). Dans ce contexte, lutilisation des numros de squence adapte DSDV une topologie dynamique de rseau comme dans un rseau Ad-hoc. DSDV utilise des mises jour tiquetes lorsque la topologie change. La transmission des mises jour est retarde afin dintroduire un effet damortissement quand la topologie change rapidement. Ainsi DSDV permet une adaptation aux rseaux Ad-hoc mobiles (MANET).

2.2.3 GSR (Global State Routing)

Le protocole GSR (35) est un protocole similaire au protocole DSDV dcrit prcdemment. Ce protocole utilise les ides du routage bas sur ltat des liens (Link State, LS), et les amliore en vitant le mcanisme inefficace dinondation des messages de routage. GSR utilise une vue globale de la topologie du rseau, comme cest le cas dans les protocoles bass sur LS. Le protocole utilise aussi une mthode, appele la mthode de dissmination, utilise dans le DBF (Distributed Bellman-Ford (13)). Dans ce protocole, chaque nud ni maintient : une liste de voisins Vi, une table de topologie TTi, une table des nuds suivants NEXTi (Next Hop), et une table de distance Table_Di. La table de la

39

Protocoles de routage dans les rseaux de capteurs topologie TTi, contient pour chaque destination, linformation de ltat des liens telle quelle a t envoye par la destination, et une estampille de linformation. Pour chaque nud destination j, la table NEXTi contient le nud vers lequel les paquets destins j seront envoys. La table de distance contient la plus courte distance pour chaque nud destination. De la mme manire que les protocoles LS, les messages de routage sont gnrs suivant les changements dtats des liens. Lors de la rception dun message de routage, le nud met jour sa table de topologie (reprsente par un graphe dans LS) et cela dans le cas o le numro de squence du message reu est suprieur la valeur du numro de squence sauvegard dans la table (exactement comme le fait le protocole DSDV). Par la suite, le nud reconstruit sa table de routage et diffuse les mises jour ses voisins. Le calcul des chemins peut se faire avec nimporte quel algorithme de recherche des plus courts chemins. Par exemple, dans (35), lalgorithme du GSR utilise lalgorithme de Dijkstra modifi de telle faon quil puisse construire la table des nuds suivants (NEXT HOP) et la table de distance Table_D, en parallle avec la construction de larbre des plus courts chemins (larbre dont la racine est le nud source). La principale modification de GSR sur lalgorithme LS traditionnel, est la faon de diffusion des informations de routage qui circulent dans le rseau. Dans LS, si on dtecte des changements de topologie, les paquets dtats de liens sont gnrs et diffuss par inondation dans tout le rseau. Par contre, GSR maintient la table - la plus rcente - dtat des liens reus travers les voisins, et lchange uniquement avec ses voisins locaux, dune faon priodique.

2.2.4 FSR (Fisheye State Routing)

Le protocole FSR [ (4), (5)] peut tre vu comme une amlioration du protocole GSR prsent prcdemment. Le nombre lev de messages de mise jour changs implique une grande consommation de la bande passante, ce qui a un effet ngatif dans les rseaux Ad-hoc caractriss par une bande passante limite. Le protocole FSR est bas sur lutilisation de la technique "il de poisson" (fisheye), propose par Kleinrock et Stevens (36) qui lont utilise dans le but de rduire le volume dinformation ncessaire pour reprsenter les donnes graphiques. Lil de poisson capture, avec prcision, les points proches du point focal. La prcision diminue quand la distance sparant le point vu et le point focal augmente (36). Dans le contexte du routage, lapproche du fisheye matrialise, pour un nud, le maintien des donnes concernant la prcision de la distance et la qualit du chemin dun voisin direct, avec une diminution progressive, du dtail et de la prcision, quand la distance augmente. Le protocole FSR est similaire LS, dans sa sauvegarde de la topologie au niveau de chaque nud. La modification principale rside dans la manire avec laquelle les informations de routage circulent. Dans FSR, la diffusion par inondation de messages nexiste pas. Lchange se fait uniquement avec les voisins directs. Les donnes de mise jour, changes priodiquement dans FSR, ressemblent au vecteur chang dans le protocole DSDV, o les distances sont modifies suivant lestampille du temps ou le numro de squence associ au nud qui a t lorigine de la mise jour. Dans FSR (comme dans LS) les tats de liens sont changs, limage complte de la topologie du rseau est garde au

40

Protocoles de routage non hirarchiques niveau de chaque nud, et les meilleurs chemins sont changs en utilisant cette image. Comme nous lavons dj dit, ltat des liens change frquemment dans les rseaux Ad-hoc. FSR effectue la mise jour de ces changements de la mme manire que le protocole GSR; ce qui rsout les problmes de LS concernant le volume de paquets de contrle. Avec GSR, et quand la taille du rseau devient trs grande, les messages de mise jour peuvent consommer une bande passante considrable. Afin de rduire le volume de messages changs sans toucher la consistance et la prcision des donnes de routage, FSR utilise la technique il de poisson vue prcdemment. La Figure 2.2 illustre cette technique. Dans cette figure, on dfinit la porte, ou le champ de vision de lil de poisson, avec un nud du centre didentificateur gal 1. La porte est dfinie en termes de nuds qui peuvent tre atteints en passant par un certain nombre de sauts. Dans la Figure 2.2, trois portes sont montres pour 1, 2 et suprieures 2 respectivement. En consquence, les nuds sont colors en noir, gris et blanc. Le nombre de niveaux et le rayon de chaque porte va dpendre de la taille du rseau. Le nud de centre (le nud 1) maintient les donnes les plus prcises des nuds appartenant au cercle le plus proche ; la prcision diminue progressivement, pour les cercles moins proches du centre.
Saut = 1
29 28
12

Saut = 2
25

Saut > 2

10 24 11 27

5 4 1 6 7
16 21 9
23

14

26
17 20 13

15

30 19 22

Figure 2.2 : Technique "il de poisson" dans le protocole FSR

La rduction du volume des donnes de mise jour est obtenue en utilisant des priodes dchanges diffrentes pour les diffrentes entres de la table. Les entres qui correspondent aux nuds les plus proches sont envoyes aux voisins avec une frquence leve (donc avec une priode dchange relativement petite). Par exemple, les entres des nuds en gras (voir la Figure 2.2) sont changes frquemment. Le reste des entres est chang avec une frquence moins leve. De cette manire, un grand nombre dchanges de donnes de routage est vit, ce qui rduit le volume des messages qui circulent dans le rseau.

41

Protocoles de routage dans les rseaux de capteurs Cette stratgie fournit priodiquement des mises jour pour les nuds proches mais elle cre de grandes latences pour celles des nuds loigns. Cependant, limprcision sur le meilleur chemin vers une destination lointaine est minimise par le fait que la route devient plus prcise lorsque le paquet sapproche de la destination. Le protocole FSR peut tre utilis dans les rseaux Ad-hoc dont le nombre de nuds est grand. Le protocole utilise un volume raisonnable de messages de contrle. En outre, il vite le travail norme de recherche de chemins, effectu dans les protocoles ractifs ; ceci acclre la transmission. De plus, FSR maintient des calculs prcis concernant les destinations proches. Malgr ses avantages, FSR ne rpond pas aux contraintes des rseaux de capteurs (surtout la contrainte dnergies).

2.2.5 AODV (Ad-hoc On Demand Distance Vector)

AODV (6) est un protocole vecteur de distance, comme DSDV, mais il est ractif plutt que proactif comme DSDV. En effet, AODV ne demande une route que lorsqu il en a besoin. AODV utilise les numros de squence dune faon similaire DSDV pour viter les boucles de routage et pour indiquer la nouveaut des routes. Une entre de la table de routage contient essentiellement ladresse de la destination, ladresse du nud suivant, la distance en nombre de sauts (i.e. le nombre de nuds ncessaires pour atteindre la destination), le numro de squence destination, le temps dexpiration de chaque entre dans la table. Lorsquun nud a besoin de trouver une route vers une destination dont lentre dans la table de routage nexiste pas ou est expire, il diffuse un message de demande de route (Route Request message, RREQ) tous ses voisins. Le message RREQ est diffus travers le rseau jusqu atteindre la destination. Durant son parcours travers le rseau, le message RREQ ralise la cration des entres temporaires des tables de routage pour la route inverse des nuds travers lesquels il passe. Si la destination, ou une route vers elle, est trouve, une route est rendue disponible en envoyant un message rponse de route (Route Reply, RREP) au nud source. Cette rponse de route traverse le long du chemin temporaire invers du message RREQ. Dans son chemin de retour vers la source, RREP introduit la cration des entres pour la destination dans les tables de routage des nuds intermdiaires. Les entres de routage expirent aprs une certaine priode (time-out). Prcisons que le protocole AODV ne supporte que les liens symtriques dans la construction des chemins inverses.

42

Protocoles de routage non hirarchiques

Figure 2.3 : Fonctionnement de la procdure de demande de route dans AODV

La Figure 2.3 illustre le mcanisme de cration des routes dAODV. Il y a dabord diffusion de la demande de route. Ensuite, la destination envoie une rponse, qui, grce aux informations recueillies par les nuds lors de la diffusion de la demande de route, cre une route de la destination vers la source. A noter que le protocole de routage AODV nassure pas la dtection du meilleur chemin existant entre la source et la destination. Les nuds voisins sont dtects par des messages priodiques HELLO (un message particulier de RREP). Si un nud x ne reoit pas un message HELLO dun voisin y par lequel il envoie des donnes, ce lien est considr bris et une indication de dfaillance de lien est envoye ses voisins actifs. Ces derniers propagent lindication leurs voisins qui utilisaient le lien entre x et y. Lorsque le message du lien bris atteint finalement les sources affectes, celles-ci peuvent choisir darrter lenvoi des donnes ou de demander une nouvelle route en envoyant un nouveau message RREQ.

2.2.6 DSR (Dynamic Source Routing)

DSR [ (7), (8)] est un protocole de routage ractif qui utilise le routage de source afin denvoyer des paquets de donnes. Dans ce type de routage, les enttes des paquets de donnes portent la squence des nuds travers lesquels le paquet doit passer. Ceci signifie que les nuds intermdiaires ont juste besoin de garder des traces de leurs voisins intermdiaires afin de transfrer les paquets de donnes. Le nud source a besoin de savoir lordre complet des nuds jusqu la destination. Comme dans AODV, la demande dune route dans DSR exige une inondation avec des paquets Route Request. Un nud recevant ce paquet cherche dans sa cachette de route (similaire la table de routage dans AODV), o toutes ses routes connues sont stockes, une route contenant la destination demande. Sil ny a pas de route trouve, le nud transfre le paquet Route Request plus loin aprs avoir ajout sa propre adresse la squence de nuds stocke dans le paquet Route Request. Le paquet se propage dans le rseau jusqu larrive destination ou un nud possdant une route vers cette destination. Si une route est trouve, un paquet Route Reply contenant la squence de nuds approprie pour atteindre la destination est renvoy en unicast au nud source. DSR ne prend pas en compte la bidirectionnalit des liens puisque le paquet Route Reply est envoy au nud source selon une route dj stocke dans la cachette de routes dun

43

Protocoles de routage dans les rseaux de capteurs nud intermdiaire ou laide dune rponse du nud destinataire. Afin dviter des inondations inutiles du rseau avec des messages Route Request, la procdure de demande de route commence dabord questionner les nuds voisins sils ont une route disponible dans le voisinage direct. Ceci est fait en envoyant le premier paquet Route Request avec une limite de sauts gale zro, afin que celui-ci ne soit pas transfr ensuite aux voisins. Sil ny a pas de rponses obtenues lors de cette demande initiale, un nouveau paquet Route Request est diffus dans le rseau entier. Un nud DSR est capable de connatre des routes en lisant des paquets qui ne lui sont pas adresss (promiscuous mode) (37). Cependant, cette technique exigeant un rcepteur actif dans le nud, peut tre plutt consommatrice dnergie. Dans les rseaux o les nuds ont une capacit nergtique limite, le but est de mettre en veille lmetteur-rcepteur afin de conserver lnergie le plus possible.

2.2.7 OLSR (Optimized Link State Routing)

Comme son nom lindique, OLSR est un protocole proactif tat des liens optimis ; il permet dobtenir aussi des routes de plus court chemin. Alors que dans un protocole tat des liens, chaque nud dclare ses liens directs avec ses voisins tout le rseau, dans le cas dOLSR, les nuds ne dclarent quune sous-partie de leur voisinage grce la technique des relais multipoints (MultPoint Relaying, MPR) (38) dcrite par la suite.

a) Relais multipoints
Cette technique consiste essentiellement, pour un nud donn, ignorer un ensemble de liens et de voisins directs, qui sont redondants pour le calcul des routes de plus court chemin. Plus prcisment, dans lensemble des voisins dun nud, seul un sous-ensemble de ses voisins est considr comme pertinent. Il est choisi de faon pouvoir atteindre tout le voisinage deux sauts (tous les voisins des voisins) ; cet ensemble est appel lensemble des relais multipoints. Lalgorithme de calcul de relais multipoints est donn dans (39). Ces relais multipoints sont utiliss de deux faons : pour diminuer le trafic d la diffusion des messages de contrle dans le rseau, et aussi pour diminuer la taille du sous-ensemble des liens diffuss tout le rseau puisque les routes sont construites base des relais multipoints (38). Lide de MPR est de minimiser linondation du trafic de contrle dans un rseau en rduisant les retransmissions dupliques dans la mme rgion. Chaque nud dans le rseau slectionne un ensemble de nuds de son voisinage auxquels ses messages seront transmis. Un nud slectionne ses MPRs parmi ses voisins un saut avec un lien symtrique. Cet ensemble est choisi de manire couvrir tous les nuds qui sont deux sauts. Les nuds slectionns comme MPRs annoncent rgulirement leur condition de MPR dans les messages de contrle envoys son voisinage. De cette faon, un nud annonce au rseau quil est capable datteindre les nuds qui lont lu comme MPR. Dans le calcul de la route, les MPRs sont utiliss pour la mise en place des routes vers toutes les destinations du rseau. Ainsi, en slectionnant la route par lintermdiaire des MPRs,

44

Protocoles de routage non hirarchiques on vite les problmes lis la transmission de paquets sur des liens unidirectionnels. Chaque nud maintient linformation sur ses voisins qui ont t slectionns comme MPR. Un nud obtient cette information par les messages de contrle reus priodiquement de ses voisins (39). La Figure 2.4 montre la diffrence entre une diffusion pure et la diffusion en utilisant les MPRs. Par exemple, afin datteindre tous les nuds 3 sauts, la diffusion pure a besoin de 24 retransmissions du paquet envoy par la source (voir la Figure 2.4, ct gauche). En utilisant les MPRs ou les relais multipoints (nuds en gras dans le ct droit de la Figure 2.4), il suffit de retransmettre le paquet de la source 11 fois pour atteindre les nuds 3 sauts.

Figure 2.4 : Diffusion pure et diffusion en utilisant les MPRs dans OLSR

b) Fonctionnement du protocole
OLSR est un protocole proactif et trs bien adapt aux rseaux larges et denses. Tous les nuds du rseau serviront de routeur et OLSR maintient sur chaque nud une table de routage complte (comprenant une entre pour tous les autres nuds du rseau). Le protocole est compltement distribu, il ny a pas dentit centrale. Chaque nud choisit la route la plus adapte en fonction des informations quil a reues. Pour maintenir jour toutes les informations ncessaires au choix des relais multipoints (MPRs) et au calcul de la table de routage, les nuds OLSR ont besoin de schanger des informations priodiquement. Pour sinformer du proche voisinage, les nuds OLSR envoient priodiquement des messages dits HELLO contenant la liste de leurs voisins. Ces messages permettent chacun de choisir son ensemble de relais multipoints. Le deuxime type de message dOLSR est le message TC (Topology Control). Par ce message les sous-ensembles de voisinage que constituent les relais multipoints sont dclars priodiquement dans le rseau. Ils sont diffuss en utilisant une diffusion optimise par relais multipoints. Ces informations offrent une carte du rseau contenant tous les nuds et un ensemble partiel de liens, mais suffisant pour la construction de la table de routage.

45

Protocoles de routage dans les rseaux de capteurs La table de routage est calcule par chacun des nuds et le routage des donnes seffectue saut par saut sans lintervention dOLSR dont le rle sarrte la mise jour de la table de routage (38).

2.2.8 GPSR (Greedy Perimeter Stateless Routing)

La topologie a un caractre relativement provisoire d la mobilit des nuds dans les rseaux Ad-hoc et de capteurs mobiles. Pour cette raison, les protocoles de routage les plus tudis pour ce type de rseaux sont les protocoles de routage gographique car ils permettent dviter la surcharge dinformations changes entre les nuds qui cherchent obtenir la topologie du rseau ou construire les tables de routage. Ces protocoles de routage gographique se basent sur le fait que tous les nuds connaissent leur position, par exemple, grce un quipement GPS (Global Positioning System) ou encore par un systme de positionnement distribu. Il existe plusieurs protocoles qui dfinissent diffrentes manires dobtenir la localisation dun nud : ce sont les protocoles de localisation. Parmi les principaux, on peut citer SLURP (40), SLALoM (41), HGRID (42), GLS (43). Une fois la position obtenue, il reste acheminer le message. Pour ce faire, plusieurs protocoles de routage gographique sont ltude, comme le protocole ractif GPSR (44) qui a t conu pour les rseaux ad hoc mobiles et les rseaux de capteurs. Du fait de la mobilit des nuds, certains protocoles de routage qui se basent sur la topologie du rseau lancent une phase de dcouverte de routes pour acheminer des donnes. De ce fait, ils utilisent la position gographique des nuds pour lacheminement des paquets de donnes ou de contrle. GPSR en fait parti. Dans un rseau mobile, les nuds sont susceptibles de se dplacer. Il faut ainsi un mcanisme permettant chaque nud de savoir la position de ses voisins. Afin de signaler leur prsence et leur localisation, les nuds dans GPSR inondent le rseau en envoyant un paquet de signalement (messages beacon) contenant la position et un identifiant (par exemple, son adresse IP). Lchange priodique de ces paquets de contrle permet aux nuds de construire leur table de position. La priode dmission des messages beacon dpend du taux de mobilit dans le rseau ainsi que de la porte radio des nuds. En effet, lorsquun nud ne reoit pas de message beacon dun voisin aprs un temps T, il considre que le voisin en question nest plus dans sa zone de couverture et lefface de sa table de position. Il faut donc adapter le temps dmission des paquets de contrle. Un des avantages du BP (Beaconing Protocol) (44) est que chaque nud na besoin que des informations sur ses voisins directs, ce qui ncessite peu de mmoire. Alternativement, le protocole GPSR permet au nud dencapsuler sur quelques bits sa position dans les paquets de donnes quil envoie. Dans ce cas, tous les nuds doivent tre en mode promiscuit afin de recevoir les paquets sils se trouvent dans la zone de couverture de lmetteur. Lacheminement des paquets par GPSR se fait selon deux modes suivant la densit du rseau : le Greedy Forwarding (45) et le Perimeter Forwarding (46) .

46

Protocoles de routage non hirarchiques

2.2.9 SPIN (Sensor Protocol for Information via Negotiation)

Le protocole SPIN (47) permet de dissminer des informations sur le rseau de manire cible. Le fonctionnement du protocole SPIN permet de rduire la charge du rseau par rapport aux mthodes de diffusion traditionnelles telles que linondation ou lalgorithme de Gossiping4.

Figure 2.5 : Fonctionnement du protocole SPIN (48)

Le protocole SPIN utilise essentiellement trois types de paquets ADV/REQ/DATA. Un nud voulant mettre une donne commence par envoyer un paquet ADV. Ce paquet ADV consiste dune mta-donnes sur les donnes mettre. Les mta-donnes peuvent dcrire plusieurs aspects comme le type des donnes et la localisation de son origine. Les nuds qui reoivent ce paquet vrifient si les donnes les intressent. Si oui, ils rpondent par un paquet REQ. Le nud qui a initi la communication envoie alors un paquet DATA pour chaque rponse REQ reue (voir la Figure 2.5). Un nud peut parfaitement ne pas rpondre aux messages ADV, par exemple dans le but dconomiser son nergie. Ensuite chaque nud qui fait office de relais peut trs bien agrger ses propres donnes aux donnes qui sont dj contenues dans le paquet (49).

Technique de dissmination dinformation dans laquelle chaque nud qui reoit un paquet relayer, envoie le paquet reu un de ses voisins tir alatoirement

47

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

2.3

Protocoles de routage hirarchiques

2.3.1 Introduction
Lorsque la taille du rseau devient de plus en plus importante, sa gestion devient plus difficile. Les protocoles de routage plat fonctionnent bien quand le rseau ne comprend pas un grand nombre de nuds. La structuration dun rseau est un des outils principaux pour sauvegarder lnergie dans chaque nud du rseau, ce qui aboutit prolonger la vie du systme. Une des structures les plus connues est la hirarchie. La technique de hirarchisation sert partitionner le rseau en sous ensembles afin de faciliter la gestion du rseau surtout le routage, qui se ralise plusieurs niveaux. Dans ce type de protocoles, la vue du rseau devient locale ; des nuds spciaux peuvent avoir des rles supplmentaires. La littrature comprend plusieurs contributions dans les techniques de hirarchisation du rseau, que nous avons classifies, dans lintrt de faciliter leur comparaison. Cette classification brivement dcrite ici, dans lintroduction, sera prsente de manire dtaille dans la conclusion du chapitre. Nous distinguons deux types de groupes de nuds : la zone et le cluster. Un cluster est dfini par un ensemble de nuds et possde un nud nomm nud-chef ou Cluster Head (CH). Le rle du CH est de faire le relais entre les nuds du cluster et la station de base directement ou via dautres CHs. Le CH possde gnralement des ressources nergtiques suprieures aux autres nuds du rseau. Cette technique est appele clusterisation (voir la Figure 2.6). Le CH est lu suivant diffrents critres et informations sur le rseau : le niveau de lnergie dun capteur, la connexion avec les autres capteurs, la position gographique, etc. Une zone est dfinie par un ensemble de nuds mais ne possde pas un nud-chef (ou CH). Ainsi, un cluster est une sous-classe dune zone. La construction des groupes (zones ou clusters) sappuie sur des informations sur le rseau, exigeant donc son instrumentation. Cette prise de mesures peut tre, dans certaines circonstances, statique (comme la position des capteurs dans un systme immobile) ou dynamique (comme le niveau nergtique des capteurs). Une autre structure utilise est la chane (50). Le principe dune chane est quun nud ne peut communiquer quavec deux voisins. Nous trouvons aussi des structures qui combinent les groupes et les chanes. En se basant sur une architecture hirarchique, plusieurs protocoles de routage pour les rseaux Ad-hoc de grande taille ont t proposs. Dans la suite nous en dtaillerons quelques uns.

48

Protocoles de routage hirarchiques

Cluster #1

Station de base
Cluster #3

Capteur
Cluster Head
Figure 2.6 : Architecture en cluster

2.3.2 ZHLS (Zone-based Hierarchical Link State Protocol)

Zone 5

Zone 1

Lien entre nuds Lien entre zones

Zone 2

Zone 4

Zone 3

Figure 2.7 : Dcomposition du rseau en zones dans ZHLS

Le protocole ZHLS (51) est bas sur la dcomposition du rseau en un ensemble de zones disjointes. Dans ce protocole, les membres dune zone nlisent pas de reprsentants contrairement

49

Protocoles de routage dans les rseaux de capteurs dautres protocoles hirarchiques. ZHLS utilise la technique GPS5 afin que chaque nud sache sa position et la zone dans laquelle il se trouve. Avec cette dcomposition, on a deux niveaux de topologies : le niveau nud, et le niveau zone. La topologie base sur le premier niveau renseigne sur la manire dans laquelle les nuds dune zone donne sont connects physiquement. Un lien virtuel peut exister entre deux zones, sil existe au moins un nud de la premire zone, qui soit physiquement connect un nud de lautre zone (voir la Figure 2.7). La topologie base sur le niveau zone, donne le schma de la connexion des diffrentes zones. La taille de la zone dpend de la mobilit des nuds, la densit du rseau, la puissance de transmission et les caractristiques de propagation. Le protocole est proactif quand le nud destinataire est dans la mme zone que le nud metteur. Dautre part, il est ractif si le nud destinataire nappartient pas la mme zone que le nud metteur. Dans ce protocole, les paquets qui contiennent les tats des liens ou les LSPs (Link State Packet) peuvent tre diviss en deux classes : les LSPs orients nuds (NodeLSP) et les LSPs orients zones (ZoneLSP). Pour un nud donn, un paquet NodeLSP contient linformation dun nud voisin tandis quun paquet ZoneLSP contient linformation de la zone et il est chang dune manire globale. De cette faon, chaque nud du rseau possde une connaissance complte concernant les nuds de sa propre zone, et seulement une connaissance partielle du reste du rseau. Cette connaissance partielle est matrialise par ltat de la connexion des diffrentes zones du rseau.

a) Construction des tables de routage intra-zone

Chaque nud diffuse une demande de vrification de liens (Link Request). Les noeuds appartenant sa porte de communication rpondent par un paquet contenant lID du nud et sa zone. Aprs avoir reu toutes les rponses, le nud gnre son paquet NodeLSP. Ce paquet NodeLSP contiendra les IDs des nuds voisins dans sa zone et lID de la zone de ses voisins dans les diffrentes zones. Le paquet NodeLSP dun nud est transfr tous les nuds de la mme zone. Les informations de lensemble de ces paquets NodeLSP seront stockes chez chaque nud de la zone. Les informations des paquets venant des autres zones ne sont pas stockes puisquelles ne sont propages que dans leurs propres zones. De cette faon, un nud connat la topologie base sur le niveau nud de sa zone (graphe LS). Lalgorithme de Dijkstra (ou SPF, Shortest Path Algorithm) est utilis pour construire la table de routage intra-zone.

b) Construction des tables de routage inter-zones

Certains nuds peuvent recevoir des rponses sur leurs demandes de vrification de liens (Link Request) des nuds qui ne sont pas dans sa zone. Ces nuds sont appels des nuds gateway . Aprs lchange des paquets NodeLSP dans la phase intra-zone, chaque nud connat les zones connectes sa zone. A ce moment, chaque nud de la mme zone gnre le mme paquet ZoneLSP. Les nuds gateway envoient le paquet ZoneLSP tous les nuds du rseau. Chaque zone excute la mme procdure. Une liste de paquets ZoneLSP est stocke par chaque nud du rseau. Par la suite, chaque nud du rseau connatra la topologie du rseau (niveau zone). Une

Global Positioning System

50

Protocoles de routage hirarchiques table de routage inter-zone est construite et SPF est utilis pour trouver le plus court chemin. Les tables sont mises jour priodiquement. Les nuds gateway ne diffuseront pas les paquets ZoneLSP si les nouvelles valeurs sont les mmes que les anciennes. Le ZoneLSP nest mis jour qu la cration ou lors de la cessure dun lien virtuel entre les zones. Ainsi, si un nud gateway reoit deux copies du mme ZoneLSP, il ne transfre quune seule, ce qui rduit le surcot dans le rseau. Par consquent, lacheminement des donnes se fait de deux faons : le routage inter-zones, et le routage intra-zone. Pour une destination donne, les donnes sont envoyes entres les zones en utilisant les identificateurs de zones jusqu ce que les donnes atteignent la zone finale de destination. Par la suite, les paquets de donnes circulent lintrieur de la zone finale, en utilisant lidentificateur du nud destination. Ladresse < ID zone, ID nud >, est suffisante pour atteindre nimporte quelle destination mme si le rseau change de topologie.

2.3.3 CGSR (Clusterhead Gateway Switch Routing)

Le protocole CGSR (52) utilise principalement lalgorithme de routage DSDV, dcrit prcdemment. Le rseau est dcompos en groupes appels clusters. Dans chaque cluster un nud, appel ClusterHead (CH), est lu. Ce nud est responsable de contrler le cluster. Le cluster est form des nuds appartenant la porte de communication dun CH. Un nud qui appartient la porte de communication de plus dun CH est un nud de liaison (appel gateway). Comme les changements de topologie dans les rseaux Ad-hoc sont frquents, CGSR utilise un algorithme appel LCC (Least Cluster Change). Llection du CH se fait en utilisant un des deux algorithmes : lowest-ID algorithm (53) ou highest-connectivity (degree) algorithm (54). Dans lalgorithme LCC, un changement de CHs intervient seulement dans le cas dune fusion de deux clusters (les deux clusters se transforment en un nouveau cluster), ou dans le cas o un nud sortirait compltement de la porte de tous les CHs. Chaque nud possde deux tables. La premire est la table de membres du cluster, qui associe chaque nud du rseau lidentificateur dun CH. Chaque nud diffuse cette table dune faon priodique et met jour sa propre table en utilisant lalgorithme DSDV. La deuxime est la table de routage (vecteur de distance). Elle dtermine le nud suivant emprunter dans le cluster correspondant au cluster destinataire. Le routage des informations dans CGSR se fait de la faon suivante : le nud source transmet ses paquets de donnes son CH. Le CH envoie les paquets au nud de liaison, qui relie ce CH avec le CH suivant dans le chemin qui existe vers la destination. Le processus se rpte, jusqu ce que ces paquets atteignent le CH du cluster dans lequel se trouve la destination. Ce CH transmet alors les paquets reus vers le nud destination. Notons que cette manire de routage assure un procd dterministe et efficace pour lacheminement des informations. Cependant un chemin choisi peut ne pas tre optimal.

51

Protocoles de routage dans les rseaux de capteurs

2.3.4 CBRP (Cluster Based Routing Protocol)

Dans le protocole ractif CBRP (9), lensemble des nuds du rseau est dcompos en clusters. Le principe de formation des clusters est le suivant : un nud n qui nest pas encore un membre du cluster ou CH, active un timer avant de diffuser un message HELLO. Lorsquun CH reoit le message HELLO, il rpond immdiatement. Lors de la rception de rponse, le nud n rejoint le cluster. Si le timeout est atteint sans aucune rponse et dans le cas o n possde un lien bidirectionnel vers au moins un nud voisin, il se considre lui-mme CH. Dans le cas contraire, n rpte la mme procdure. Chaque nud maintient une table des voisins. Chaque entre de cette table est associe un voisin ; elle indique ltat du lien (uni ou bidirectionnel) et le statut du voisin (membre ou CH de cluster). Le CH maintient les informations des membres qui appartiennent son cluster. Il possde aussi une table des clusters adjacents. Chaque entre de cette table contient : lidentificateur du cluster, lidentificateur du nud de liaison travers lequel le cluster peut tre atteint. Comme CBRP est un protocole ractif, quand un nud source veut envoyer des donnes un nud destination, il diffuse une requte demandant un chemin uniquement aux CHs des clusters voisins. Chaque CH vrifie lexistence du nud destination dans son cluster (en utilisant la table de membres). Le CH de cluster qui contient le nud destination, y envoie directement la requte. Dans le cas contraire, la requte est rediffuse aux CHs des clusters voisins. Les adresses des CHs sont incluses dans cette requte. Le CH ignore toute requte dj traite. Quand la destination reoit la requte, elle rpond par lenvoi du chemin qui a t sauvegard dans le paquet de la requte. Dans le cas o le nud source ne reoit pas de rponse aprs une certaine priode, il envoie de nouveau une requte de demande de chemin. Lors du routage des donnes, si un nud dtecte quun lien est dfaillant, il envoie un message derreur la source et il applique un mcanisme de rparation locale. Dans ce mcanisme, si un nud n trouve quun nud suivant m ne peut pas tre atteint, il essaie de vrifier si le nud m ou le nud suivant m dans le chemin peut tre atteint travers un autre nud voisin. Si lun des deux cas est vrifi, les donnes sont envoyes en utilisant le chemin rpar.

2.3.5 LEACH (Low Energy Adaptive Clustering Hierarchy)

Dans (55), Heinzelman et al. ont propos un algorithme de clustering distribu appel LEACH pour le routage dans les rseaux de capteurs homognes. LEACH choisit alatoirement les nuds cluster-heads et attribue ce rle aux diffrents nuds selon la politique de gestion Round-Robin (cest--dire tourniquet) pour garantir une dissipation quitable dnergie entre les nuds. Dans le but de rduire la quantit dinformations transmises la station de base, les cluster-heads agrgent les donnes captures par les nuds membres qui appartiennent leur propre cluster, et envoient un paquet agrg la station de base. LEACH est excut en deux phases : la phase set-up et la phase steady-state suivant la Figure 2.8. Dans la premire phase, les cluster heads sont slectionns et les clusters sont forms, et dans la seconde phase, le transfert de donnes vers la station de base aura lieu. Durant la premire

52

Protocoles de routage hirarchiques phase, le processus dlection des cluster heads est dclench pour choisir les futurs cluster heads. Ainsi, une fraction prdtermine de nuds slisent comme cluster heads selon le schma dexcution suivant : durant une priode T, un nud n choisit un nombre alatoire nb dont la valeur est comprise entre 0 et 1 (0 < nb < 1). Si nb est infrieur une valeur seuil alors le nud n deviendra cluster head durant la priode courante, sinon le nud n devrait rejoindre le cluster head le plus proche dans son voisinage.

Figure 2.8 : Formation de clusters dans LEACH (55)

Cependant, bien que LEACH puisse augmenter la dure de vie du rseau, il prsente certaines limitations. LEACH suppose que tous les nuds puissent transmettre des donnes avec une grande puissance pour atteindre la station de base et que chaque nud a une puissance de calcul lui permettant de supporter diffrentes couches MAC. Par consquent, LEACH ne convient pas aux rseaux dploys dans de vastes rgions. En outre, LEACH choisit alatoirement la liste des cluster heads et il ne pose aucune contrainte sur leur distribution ainsi que sur leur niveau dnergie. Ainsi, les cluster heads peuvent se concentrer dans un mme endroit et par consquent, il pourrait exister des nuds isols (sans cluster head) pouvant se dclarer. Dautre part, dans LEACH, lagrgation des donnes est centralise et est excute priodiquement. Or, dans certains cas, la transmission priodique des donnes pourrait ne pas tre ncessaire, ce qui puise rapidement lnergie limite des capteurs. Une variante de LEACH appele LEACH-C (56) a t conue pour amliorer les performances de LEACH. Cette variante utilise une architecture centralise pour choisir les cluster heads tout en impliquant la station de base et linformation de localisation des capteurs. Cependant, elle augmente considrablement le surcot du rseau puisque tous les capteurs devront envoyer leurs informations de localisation la station de base en mme temps pendant chaque phase dlection de cluster heads. Plusieurs travaux prsents (49) dans la littrature ont prouv quune telle architecture centralise ne supporte pas le passage lchelle, tant plus particulirement approprie des rseaux de petite taille. Dans (57), les auteurs ont propos un protocole hirarchique bas sur LEACH. Les cluster heads forms dans LEACH sont groups et organiss en une hirarchie. Ils ont montr que la consommation nergtique diminue lorsque le nombre de niveaux de lhirarchie augmente.

53

Protocoles de routage dans les rseaux de capteurs

2.3.6 PEGASIS (Power-Efficient Gathering in Sensor Information Systems)

Dans (50), Lindsey et Raghavendra ont propos une version amliore de LEACH appele PEGASIS. Lide principale de PEGASIS est de former une chane entre les nuds de sorte que chaque nud reoive de et communique un voisin proche. Les donnes collectes sont transmises dun nud un autre qui les agrge jusqu ce quelles arrivent un nud particulier qui les transmet la station de base. Les nuds qui transmettent les donnes la station de base, sont choisis tour tour selon une politique round-robin dans le but de rduire lnergie moyenne dpense par un nud durant une priode (round). Contrairement LEACH, PEGASIS vite la formation des clusters et procure un seul nud dans la chane lenvoi de donnes la station de base. Dailleurs, PEGASIS suppose que les nuds sont capables de modifier leur puissance de transmission. Les rsultats de simulation ont montr que PEGASIS peut prolonger de deux trois fois la dure de vie dun rseau de capteurs relativement LEACH en fonction du critre choisi pour valuer la dure de vie dun rseau i.e. quand 1%, 20%, 50% ou 100% des nuds puisent leurs batteries. Un tel gain de performance est ralis par llimination du surcot caus par le processus de formation de clusters dans LEACH, et par la rduction du nombre de transmissions et de rceptions en agrgeant de donnes. Bien que le surcot du clustering soit vit, PEGASIS exige toujours un ajustement dynamique de la topologie puisquun nud devrait connatre le niveau dnergie de ses voisins avant de relayer ses donnes. Cependant, un tel ajustement de la topologie pourrait causer un surcot important en particulier dans les rseaux les plus utiliss. En outre, PEGASIS suppose que tout nud communique directement avec la station de base qui gre la topologie dune manire centralise. Or, cette supposition est loin de la ralit car les capteurs communiquent gnralement en mode multi-sauts pour atteindre la station de base. Dautre part, PEGASIS suppose que tous les nuds maintiennent une table contenant les localisations de tous les autres nuds dans le rseau. En rsum, PEGASIS est adapt seulement aux capteurs sans fil dont les nuds sont immobiles. Son valuation dans des environnements mobiles pourrait dgrader considrablement ses performances. Une variante de PEGASIS appele Hierarchical PEGASIS (58) a t conue afin damliorer PEGASIS. Dans Hierarchical PEGASIS, la chane est divise en groupes de la sorte que chaque nud communique avec un seul nud voisin de niveau plus bas de la hirarchie. Les transmissions simultanes en parallle dans des groupes diffrents minimisent le dlai de transmission. Un autre protocole similaire PEGASIS, appel C2E2S, a t propos dans (59). Il est bas sur les clusters et les chanes. Cest un protocole centralis o la station de base organise le rseau en se basant sur linformation de lnergie des nuds.

2.3.7 TEEN (Threshold-sensitive Energy Efficient sensor Network protocol)

Manjeshwar et Agrawal (60) ont propos une technique de clustering appele TEEN pour les

54

Protocoles de routage hirarchiques applications critiques o le changement de certains paramtres peut tre brusque. Larchitecture du rseau est base sur un groupement hirarchique plusieurs niveaux o les nuds les plus proches forment des clusters. Puis ce processus de clustering passe au deuxime niveau jusqu ce que la station de base soit atteinte. Aprs la formation des clusters, chaque cluster-head transmet ses membres deux seuils : un seuil Hard HT (hard threshold), qui est la valeur seuil du paramtre contrl (surveill) et un seuil Soft ST (soft threshold) reprsentant une petite variation de la valeur du paramtre contrl. Loccurrence de cette petite variation ST permet au nud qui la dtecte de la signaler la station de base en transmettant un message dalerte. Par consquent, le seuil Soft rduira le nombre de transmissions puisquil ne permet pas la transmission sil y a peu ou pas de variation de la valeur du paramtre contrl. Au dbut, les nuds coutent le mdium continuellement et lorsque la valeur capte du paramtre contrl dpasse le seuil Hard, le nud transmet linformation. La valeur capte est stocke dans une variable interne appele SV. Puis, les nuds ne transmettront des donnes que si la valeur courante du paramtre contrl est suprieure au seuil hard HT ou diffre du SV dune quantit gale ou plus grande que la valeur du seuil Soft ST. Puisque la transmission dun message consomme plus dnergie que la dtection des donnes, alors la consommation dnergie dans TEEN est moins importante que dans les protocoles proactifs ou ceux qui transmettent des donnes priodiquement tels que LEACH. Cependant, linconvnient principal de ce protocole est que, si les seuils HT et ST ne sont pas reus, les nuds ne communiqueront jamais, et aucune donne ne sera transmise lutilisateur, ainsi la station de base ne connat pas les nuds qui ont puis leur nergie. TEEN ne convient pas aux applications qui ncessitent des envois priodiques de donnes.

2.3.8 APTEEN (Adaptive Threshold-sensitive Energy Efficient sensor Network protocol)

Pour remdier aux limitations du protocole TEEN, les auteurs ont propos une extension de TEEN appele APTEEN (61). APTEEN est un protocole hybride qui change la priodicit et les valeurs seuils utilises dans TEEN selon les besoins de lutilisateur et le type dapplication. Dans APTEEN, les cluster-heads transmettent leurs membres les paramtres suivants : lensemble de paramtres physiques auxquels lutilisateur est intress pour obtenir des informations (A), les seuils : seuil Hard HT et seuil Soft ST, un Schedule TDMA permettant dassigner chaque nud un intervalle fini de temps appel slot, un compteur de temps (CT) : cest la priode de temps maximum entre deux transmissions successives dun nud. Dans APTEEN, les nuds surveillent en continu lenvironnement. Ainsi, les nuds qui dtectent une valeur dun paramtre qui dpasse le seuil HT, transmettent leurs donnes. Une fois quun nud dtecte une valeur qui dpasse HT, il ne transmet les donnes au cluster head que si la

55

Protocoles de routage dans les rseaux de capteurs valeur de ce paramtre change dune quantit gale ou suprieure ST. Si un nud ne transmet par de donnes pendant une priode de temps CT, il devrait faire une capture de donnes et les retransmettre. APTEEN offre une grande flexibilit qui permet lutilisateur de choisir lintervalle de temps CT, et les valeurs seuils HT et ST pour que la consommation dnergie soit contrle par la variation de ces paramtres. Cependant, APTEEN ncessite une complexit supplmentaire pour implmenter les fonctions de seuils et de priodes de temps CT. Ainsi, le surcot et la complexit associs la formation des clusters plusieurs niveaux par TEEN et APTEEN sont assez levs.

2.3.9 VGA (Virtual Grid Architecture routing)

Dans [ (62), (63)], les auteurs ont propos une approche de clustering pour maximiser la dure de vie dans les rseaux de capteurs dont les nuds sont immobiles ou se dplacent avec une faible vitesse. Ils ont utilis lapproche GPS-free (64) pour construire des clusters fixes, disjoints, et homognes en taille avec des formes symtriques. Dans [ (62), (63)], la zone de dploiement des rseaux de capteurs est divise en une topologie virtuelle rectiligne contenant des petites zones ayant la forme dun carr, et dans chacune, un nud est choisi comme cluster head. Lagrgation de donnes est ralise deux niveaux : local et global. Lagrgation locale est ralise par lensemble des cluster heads appels aussi Local Aggregators (LAs), alors que lagrgation globale est ralise par un sous ensemble de LAs appels Master Aggregators (MAs). Cependant, la dtermination de lensemble MAs est un problme NP-difficile. Les heuristiques qui ont t proposes pour former lensemble MAs partir de lensemble LAs, avaient comme objectif la maximisation de la dure de vie des rseaux de capteurs. Par exemple, dans lheuristique CBAH (65) (Cluster-Based Aggregation Heuristic) propose par les mmes auteurs, lensemble MAs est choisi selon la capacit des lments de LAs. Les membres dun mme cluster surveillent le mme phnomne, et leurs lectures (dtections) sont corrles par leur LA correspondant. Ce dernier son tour transmet ces donnes corrles son MA correspondant.

2.3.10 CTLMN (Clustering Technique for Large multihop Mobile wireless Networks)
Lin et Chu (66) proposent une technique pour un large rseau Ad hoc. La structure de cluster est contrle par la distance gale au nombre de sauts. Cette technique repose sur la manire dont les nuds sont regroups dans un cluster en utilisant le nombre maximum de sauts R qui indique le rayon du cluster. Chaque nud contient les informations (i, Ci, di, ni) dites informations de cluster qui sont respectivement : lID de nud, lID de son cluster, le nombre de sauts partir de CH, lID du prochain nud sur le chemin de cluster. Le maintien du cluster se fait comme suit : lorsquun nud se dplace au-del de R, il quitte son cluster et peut rejoindre un autre cluster sil se retrouve une distance gale R sauts du CH (du nouveau cluster). Si la distance entre deux CHs est infrieure ou gale un nombre prdtermin de sauts D (Distance de cluster cartant), le CH qui a le plus grand ID est cart, et les nuds dans

56

Protocoles de routage hirarchiques le cluster cart cherchent un autre cluster pour le rejoindre.

2.3.11 HEED (Hybrid, Eenergy-Efficient, Distributed approach)

Younes et Fahmy (67) ont propos un algorithme de clustering distribu appel HEED pour les rseaux de capteurs. Contrairement aux techniques prcdentes, HEED ne fait aucune restriction sur la distribution et la densit des nuds. Il ne dpend pas de la topologie du rseau ni de sa taille mais il suppose que les capteurs ont la possibilit de modifier leur puissance de transmission. HEED slectionne les cluster-heads selon un critre hybride regroupant lnergie restante des nuds et un second paramtre tel que le degr des nuds. Il vise raliser une distribution uniforme des cluster heads dans le rseau et gnrer des clusters quilibrs en taille. Un nud u est lu comme cluster head avec une probabilit Pch gale Pch = Cprob En ETotal

o En est lnergie restante du nud n, ETotal est lnergie globale dans le rseau et Cprob est le nombre optimal de clusters. Cependant, lvaluation de ETotal prsente une certaine difficult, cause de labsence de toute commande centrale. Un autre problme rside dans la dtermination du nombre optimal de clusters. De plus, HEED ne prcise pas de protocole particulier utiliser pour la communication entre les cluster heads et le sink. A lintrieur du cluster, le problme ne se pose pas car la communication entre les membres du cluster et le cluster head est directe ( un saut). Dautre part, avec HEED, la topologie en clusters ne ralise pas de consommation minimale dnergie dans les communications intra-cluster et les clusters gnrs ne sont pas quilibrs en taille.

2.3.12 CSOS (Cluster-based Self-Organization algorithm for wireless Sensor networks)

Les auteurs dans [ (68), (69), (70)] ont propos une technique dauto-organisation base sur lapproche de clustering pour optimiser la consommation de lnergie dans ces rseaux. Cette technique consiste regrouper les nuds proches gographiquement en clusters. Elle implique des paramtres dterminants pour produire un nombre rduit de clusters homognes en taille et en rayon, et que les clusters soient stables. Le poids de chaque capteur est calcul en fonction des paramtres suivants : la 2-densit, lnergie restante, et la mobilit. Le capteur ayant le plus grand poids dans son voisinage 2 sauts devient cluster head. En outre, la taille des clusters gnrs est comprise entre deux seuils ThreshLower et ThreshUpper, qui reprsentent respectivement le nombre minimal et maximal de capteurs dans un cluster. Ces deux seuils sont choisis arbitrairement ou dpendent de la topologie du rseau. Dans un cluster, chaque capteur membre est au plus deux sauts de son cluster-head correspondant. Le processus dlection des cluster heads est priodique aprs lcoulement dune certaine priode t afin de distribuer quitablement la consommation de lnergie parmi les capteurs durant la dure de vie du rseau.

57

Protocoles de routage dans les rseaux de capteurs Dans leur technique propose, les capteurs sont supposs avoir une connaissance topologique deux sauts, ils peuvent modifier leur puissance de transmission, et oprent dune manire asynchrone et sans contrle centralis. Chaque capteur utilise le critre poids pour lire un cluster head dans son voisinage 2 sauts. Ce poids est calcul en fonction de la k-densit, lnergie rsiduelle et la mobilit, puis diffus dans le voisinage 2 sauts de chaque capteur. Ainsi, le capteur ayant le plus grand poids parmi ses voisins 2 sauts, qui ne sont pas encore affilis dautres clusters, est choisi comme cluster head pour la priode courante.

2.3.13 SAR (Sensor Aggregates Routing)

Fang et al. (71) ont propos une approche de clustering pour lagrgation des donnes dans les rseaux de capteurs surveillant plusieurs cibles. Ces cibles peuvent tre stationnaires ou se dplaant nimporte quel moment indpendamment des tats des autres cibles. Lobjectif de cet algorithme est de dterminer le nombre de cibles et les localisations approximatives des clusters associs aux cibles dans la zone dintrt. Puis on surveille quand les cibles se dplacent, joignent, ou quittent la zone dintrt. Au dbut, les nuds examinent les caractristiques spatiales des signaux associs aux cibles quand plusieurs cibles sont dans la proximit les unes des autres. Puis, ils sont groups en clusters selon la puissance du signal dtect de sorte quil y ait un seul pic par cluster. Un pic pourrait reprsenter une cible, plusieurs cibles proches, ou aucune cible quand le pic serait produit par les attnuations du signal. Le processus dlection des cluster heads se fait dans un voisinage un seul saut et le nud ayant le plus grand paysage de champ de signal parmi ses voisins un seul saut se dclarera cluster-head. Ainsi, le choix des cluster heads (Sensor Aggregates) se fait selon lallocation des ressources aux tches de dtection et de communication. Dans (71), Fang et al. ont propos trois algorithmes pour la cration des nuds qui agrgent les donnes (Node Aggregates) : DAM (Distributed Aggregate Management) est un protocole distribu conu pour surveiller une cible. Il comporte un prdicat de dcision P pour chaque nud afin quil dcide sil devrait participer lagrgation de donnes et un arrangement dchange de message M concernant la faon dappliquer le prdicat de groupement aux nuds. Le but de DAM est dlire les cluster heads et maintenir les informations locales sur le paysage du signal. Dans DAM, seuls les nuds avec une puissance de signal dpassant le seuil ThresholdElection peuvent participer au processus dlection de cluster head. EBAM (Energy-Based Activity Monitoring) est une extension de DAM. Il fournit une solution pour dterminer le nombre de cibles dans un cluster. Il suppose que chaque cible a la mme puissance. Ainsi, lorsque la puissance dune cible dans un cluster est connue, le nombre de cibles peut tre dduit de la puissance totale du signal dans le cluster. EMLAM (Expectation-Maximization Like Activity Monitoring) enlve la supposition que chaque cible a la mme puissance. EMLAM estime les positions des cibles et lnergie du signal travers les signaux reus et utilise les valuations rsultantes pour prvoir comment les signaux des cibles peuvent tre fusionns dans chaque capteur. Ce processus est ritr, jusqu ce que lvaluation soit suffisamment bonne.

58

Protocoles de routage hirarchiques

2.3.14 TTDD (Two-Tier Data Dissemination)

Dans TTDD (72), chaque nud source cre une grille virtuelle sur le rseau. Cette grille est par la suite utilise par le protocole de routage pour acheminer les requtes et les donnes entre la source et le sink mobile. Dans TTDD, un systme de localisation (comme GPS) est utilis pour que les nuds homognes sachent leurs positions fixes. Une fois un vnement est dtect dans le rseau, les nuds qui lentourent traitent le signal de cet vnement et un de ces nuds devient la source et gnre les rapports de donnes. Ce nud source cre virtuellement la grille pour le rseau afin de prciser les nuds de dissmination responsables de router les donnes vers le sink.

2.4

Conclusion

Nous avons dcrit dans les sections prcdentes quelques protocoles de routage non hirarchique dans les rseaux Ad-hoc et de capteurs. Lorsque le rseau vis est plus tendu, la gestion devient plus difficile lorsquun protocole non hirarchique est utilis pour la gestion des communications. Chaque nud doit stocker plus dinformations concernant le rseau et ses voisins. Les exigences en taille des rseaux de capteurs, dues aux dploiements gnralement tendus, rendent le stockage des informations de topologie trs coteux par rapport aux ressources disponibles dans ces dispositifs. De mme, le surcot de communications entre les nuds devient plus important d aux changes additionnels de paquets. Toute communication se traduit en consommation nergtique, qui constitue un objectif de minimisation dans les rseaux de capteurs. La bande passante limite est ainsi influe par ltendue du rseau. Nous avons aussi dcrit des protocoles de routage hirarchique dans les rseaux Ad-hoc et de capteurs. Les travaux actuels concernant le routage hirarchique nous ont permis lidentification de trois structures principales dorganisation : les zones, les clusters et les chanes (voir la Figure 2.9). Celles-ci sont la base de la classification propose la fin de cette conclusion, qui rsume galement les caractristiques des algorithmes de routage hirarchique. Les zones dfinissent gnralement un sous-ensemble de nuds capteurs sans contrleur central. Une forme particulire prsente dans la littrature est la grille, zone bien identifie par des surfaces carres de taille donne. La structure du cluster est la plus rpandue : elle identifie, en plus du primtre de la zone, un nud particulier, le cluster head, ayant la fonction de gestionnaire de la construction et de lappartenance. Le choix des cluster heads est souvent dpendant de facteurs divers comme le niveau nergtique, les positions gographiques ou la connectivit. Les approches cluster prsentent les inconvnients classiques similaires aux systmes centraliss, car le cluster heads sont source de concentration dinformation et sont donc susceptibles de dfaillance rapide pour des raisons de consommation nergtique. La caractristique point--point des partitionnements en zones, dans lesquels les nuds ont tous le mme rle, permet dviter le goulot dtranglement dans le trafic, les points de dfaillance et simplifie la gestion de la mobilit. Les chanes, structure dans laquelle un nud ne peut pas communiquer quavec deux nuds voisins, sont le rsultat de la recherche des schmas

59

Protocoles de routage dans les rseaux de capteurs dagrgation qui fournissent un quilibrage de la consommation nergtique. Ce type de structure est utilis conjointement avec les clusters, afin damliorer les dlais de transmission.

Figure 2.9 : Classification des principales structures hirarchiques dun rseau

La hirarchisation rpond aux besoins dun rseau tendu, notamment un rseau de capteurs. Pour ce faire, certains protocoles exigent des informations concernant le rseau. Nous citerons la position gographique des nuds, lnergie rsiduelle des nuds, ltat des liens, etc. La position gographique peut tre obtenue en utilisant des techniques de localisation ou le GPS. Linformation concernant lnergie des nuds et des tats des liens ne peut pas tre obtenue qu travers la communication entre les nuds. Dautres protocoles exigent des contraintes matrielles comme la possibilit de varier la puissance de transmission du nud, une capacit de traitement adquate, une capacit nergtique importante, une vaste mmoire, etc. Certains protocoles se basent sur la structure en cluster, dautres sur la structure en zone, et dautres sur la structure en chane. Un bon tat de lart sur ces protocoles est dcrit dans ( (73), (74)). Le Tableau 1 rsume les caractristiques principales de chaque protocole.
Type hirarchie ZHLS Zone Cluster Cluster Cluster Chane Chane + cluster de Information exige sur le rseau Position des noeuds Connectivit nuds Etat des liens Energie des nuds Energie des nuds Energie des nuds des Variation de la puissance de transmission NON NON NON OUI OUI OUI Nombre prdfini clusters/zones/chanes NON NON NON NON NON NON de

Ad-hoc

CGSR

CBRP LEACH

WSN

PEGASIS Hierarchical PEGASIS

60

Conclusion
CES
2 2

Chane + cluster Cluster Cluster Cluster Cluster Cluster Cluster Cluster Zone

Energie des nuds Position des noeuds Position des noeuds Position des noeuds Position des noeuds Energie des nuds Position des noeuds Etat des liens Position des noeuds

OUI NON NON NON NON OUI OUI NON NON

NON NON NON NON NON NON NON NON NON

TEEN APTEEN VGA CTMN HEED CSOS SAR TTDD

Tableau 1 : Bilan des protocoles de routage hirachique dans les rseaux Ad-hoc et de capteurs

Dans les approches de routage pour les rseaux de capteurs, les efforts ont t concentrs sur la dfinition dune topologie hirarchique deux ou plusieurs niveaux base sur les clusters. Ces nuds exigeant une capacit de calcul et de communication plus importante, leur choix ncessite linstrumentation du rseau, permettant dappliquer des critres de slection. Un autre point critique est le besoin de dcentralisation des dcisions, surtout dans les rseaux de grande taille. En vue de ces besoins, notre objectif est de proposer un protocole de routage hirarchique, bas sur une topologie de zone, sappuyant sur des dcisions et calculs distribus. Ceux-ci ne dpendront que dinformations statiques, car la mise jour exige par des informations dynamiques serait trop couteuse. Les rseaux viss par notre proposition de protocole de routage bas sur les zones comprennent des nuds capteurs qui ne disposent pas dinformation de localisation. Ils sont fixes et ont un rayon de communication constant durant leur dure de vie. Ce nouveau protocole est dcrit et dtaill dans le chapitre suivant.

61

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Chapitre 3. Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol)

3.1

Introduction

Un rseau de capteurs est un ensemble de capteurs qui collaborent pour contrler et surveiller lenvironnement. Le nombre de capteurs peut atteindre des centaines, voire des milliers, suivant lapplication. Lnergie et lespace de stockage dans les rseaux de capteurs sont deux caractristiques critiques. Dans un rseau compos de milliers de capteurs, la gestion du routage et lchange de donnes entre les capteurs sont coteux en termes dnergie et de capacit de stockage. Un capteur doit stocker beaucoup dinformations (table de routage de taille importante dans les protocoles proactifs) afin deffectuer le routage de donnes. Des recherches et des travaux essayent de minimiser la consommation de lnergie en dcoupant le rseau en groupes afin de router les informations captures des niveaux diffrents. Dans les approches heuristiques proposes pour les rseaux de capteurs, bases sur la technique de clustering, les membres dun cluster ne transmettent pas leurs donnes collectes directement la station de base mais leur cluster head correspondant. En consquence, les cluster heads sont responsables pour coordonner les membres du cluster, agrger leurs donnes captures, et de les transmettre une station de base distante, directement ou via un mode de transmission multi-sauts. De ce fait, puisque les cluster heads reoivent plus de paquets et consomment plus dnergie pour les transmettre avec une longue porte, ils sont donc ceux dont lnergie sera puise le plus rapidement dans les clusters sils sont lus pour une longue priode. Par consquent, dautres techniques devraient viter le processus dlection des cluster heads, parce que ces derniers sont contraints par lnergie, et peuvent rapidement puiser leurs batteries cause de leur forte

63

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) utilisation. Ainsi, cela peut causer des goulots dtranglement dans les clusters et dclencher par le suite le processus de rlection des cluster heads. Dans ce chapitre, nous proposerons une nouvelle technique de partitionnement dun rseau de capteurs en zones base sur le nombre de sauts [ (75), (76)]. La structure en zones rsultante de ce partitionnement sera la base dun nouveau protocole de routage hirarchique deux niveaux. Les nuds dune zone possderont une table de routage utilise pour acheminer des donnes lintrieur de la zone. Une deuxime table de routage est utilise pour router des donnes entre les zones du rseau. Cette deuxime table nexistera que chez les nuds qui sont aux frontires des zones. Ces nuds joueront le rle de relais entre les zones. La Figure 3.1 montre un exemple dun rseau de capteurs partitionn en zones et dun acheminement de donnes entre deux nuds de zones diffrentes.

Figure 3.1 : Rseau de capteurs partitionn en zones

Par la suite, nous dtaillerons notre approche de partitionnement dun rseau de capteurs en zones.

3.2 Algorithme distribu de partitionnement dun rseau de capteurs en zones

Dans notre proposition de partitionnement du rseau en zones, nous ne nous intressons pas llection dun cluster head (CH), comme dans la clusterisation, car lapproche vise est compltement distribue. Les clusters prsentent un fonctionnement centralis cause des rles de gestionnaire de cluster et de relais de communication accords aux CHs. Nous supposons que nous ne disposons daucune information dinstrumentation sur le rseau (par exemple, les positions des nuds). Cette hypothse est induite par le cot dinstallation exig pour quiper les capteurs de systme de go-localisation. Dans la surveillance de grands espaces, le nombre de capteurs ncessaires pour la couverture est trop important, pour que les solutions de go-localisation, totales

64

Algorithme distribu de partitionnement dun rseau de capteurs en zones ou partielles, conjointement aux techniques de triangularisation, soient conomiques, efficaces et fiables. Dans ce contexte, nous considrons un dploiement alatoire des nuds, sans perte de gnralit. Ainsi, tout autre dploiement peut tre pris en compte, mme celui dirig par lutilisateur, pour lequel les positions pourraient tre connues lavance. Dans ce dernier cas, linformation de localisation sera ignore par notre protocole. Pour cela, nous avons dploy alatoirement les nuds. Cest un dploiement sans aucune contrainte. Nous supposons que les nuds ont une identification globale NodeId. Cette technique est base sur le nombre de sauts (hops). Le nombre de zones est donn au dpart (paramtre de lalgorithme). A la fin de lexcution de lalgorithme, les nuds devraient tre affects une seule zone. En consquence, les zones sont disjointes. Le dcoupage en zones propos est un processus distribu et a comme acteurs de dclenchement certains nuds appels nuds-invitant. Ces nuds particuliers nont pas les fonctionnalits des cluster-heads dans les techniques de clusterisation, grce au fait quils sont seulement linitiative du lancement de la construction des zones. Ce mcanisme exige que les nuds-invitant soient au dpart assigns chacun une zone diffrente et quils envoient des messages dinvitation aux autres nuds par propagation de proche en proche. Les nuds recevant ces messages peuvent soit accepter, soit dcliner loffre dinvitation, construisant ainsi les zones. Une fois les messages initiaux dinvitation envoys, les nuds-invitant perdent leur proprit particulire car ils noprent aucune gestion ultrieurement. Les points critiques dans cette phase dorganisation virtuelle concernent deux aspects : le nombre de nuds-invitant et leur choix parmi les nuds du rseau. La dfinition du nombre de nudsinvitant dpend directement du nombre total de nuds et de la taille voulue pour chaque zone. Si la premire information est disponible, la seconde ne peut pas tre dduite facilement : plus il y a des nuds-invitant, plus petite est la taille moyenne des zones et inversement. Et ceci pour un placement bien rparti des nuds-invitant. Le choix des nuds-invitant est donc un autre point cl pour une bonne organisation des nuds en zones. En labsence de contrle centralis, ce choix est rendu encore plus difficile : comment sassurer que deux nuds-invitant ne soient pas choisis trop proche lun de lautre ? Sils sont proches, les messages dinvitation risquent de ne pas arriver tous les nuds et par consquent des nuds peuvent rester en dehors de toute zone. Lespace de dploiement serait ainsi que pareillement couvert par les zones. Dterminer le nombre optimal (minimal) de nuds-invitant pour que la surface de dploiement soit entirement couverte, sans avoir dinterfrence, entre les nuds-invitant est un problme NP-complet (77). Dans un systme distribu, le choix le plus simple et souvent efficace qui limite le nombre de messages changs et rduit la perte dnergie est de dsigner alatoirement les nuds-invitant. Dans ce contexte, nous nous sommes intresss au pourcentage de prsence des nuds-invitant dans la proximit dautres nuds-invitant. Nous appelons cette valeur taux des nuds-invitant proximit. Ce calcul sappuie sur la dfinition de proximit de deux nuds-invitant. Une des pires situations serait davoir deux nuds-invitant avec un prsent dans la porte de communication de lautre (donc ils seraient voisins un saut). Nous dfinissons donc la notion de proximit de la faon suivante : un nud v est proximit dun nud u si et seulement si v appartient la porte de communication de u.

65

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) Le calcul de ce taux dpend du nombre de nuds-invitant, du nombre de nud total des nuds et de leurs positions. Le taux est dfini comme le nombre de liens de longueur infrieure la porte de communication entre les nuds-invitant divis par le nombre total des liens entre tous les nuds. Les simulations ont t faites pour des nuds capteurs ayant une porte de communication 150m6 et 300m dans un champ de dploiement de taille 1500m*1500m. Le nombre de nuds est vari de 400, 500 (rseau de faible densit) 600, 700, et 800 (rseau de forte densit). Le nombre de nuds-invitant a t vari de 5 jusqu 25 nuds. Nous avons effectu 1000 itrations par simulation. Comme le montre la Figure 3.2, le taux des nuds-invitant proximit (avec une porte de communication Tr = 150m) ne dpasse pas 2,7*10-5.
3,5E-04

3,0E-04

2,5E-04

2,0E-04

Taux

Tr=150, 800 nodes Tr=150, 700 nodes

1,5E-04

Tr=150, 600 nodes Tr=150, 500 nodes

1,0E-04

Tr=150, 400 nodes

5,0E-05

0,0E+00
5 10 15 20 25

Nombre de noeuds invitant

Figure 3.2 : Taux des nuds-invitant proximit (Tr= 150m)

Si on double la porte (Tr = 300 m), le taux ne dpasse pas 1,2*10-3 (voir la Figure 3.3). Dans les deux cas, nous remarquons que le taux est trs faible par rapport au pire de cas o tous les nuds du rseau sont des nuds-invitant communicant entre eux. Dans ce cas, le graphe des liens entre les nuds est connexe et donc le taux est gal 1.

La porte dun nud capteur MICA2

66

Algorithme distribu de partitionnement dun rseau de capteurs en zones

1,2E-03

1,0E-03

8,0E-04

Taux

Tr=300, 800 nodes 6,0E-04

Tr=300, 700 nodes

Tr=300, 600 nodes Tr=300, 500 nodes 4,0E-04 Tr=300, 400 nodes

2,0E-04

0,0E+00
5 10 15 20 25

Nombre de noeuds invitant

Figure 3.3 : Taux des nuds-invitant proximit (Tr= 300m)

Ce faible taux obtenu exprimentalement nous encourage utiliser une distribution alatoire des nuds-invitant dans lalgorithme de partitionnement du rseau en zones. Le choix alatoire des nuds-invitant est une technique qui prsente lavantage dtre moins coteuse que celle utilisant un algorithme distribu dlection comme dans la clusterisation. La minimisation du nombre de messages de contrle qui en dcoule permet dconomiser lnergie des nuds, et par consquent, de prolonger la dure de vie du systme. Aprs ce partitionnement virtuel du rseau, chaque nud est affect une seule zone. Les zones sont disjointes. Les paramtres de lalgorithme sont les suivants : R (rayon de la zone) - la distance maximale, en termes de nombre de sauts, entre le nudinvitant et les nuds invits. Par consquence, chaque nud une distance (nombre de sauts) du nud-invitant infrieure ou gale R devrait joindre sa zone. N - le nombre de nuds dans le rseau, zN - le nombre de zones, correspondant au nombre de nuds-invitant. Chaque nud spcifie durant lexcution de lalgorithme les valeurs suivantes : ZoneId - lidentification de la zone laquelle le nud appartient. Au dbut, cette variable a comme valeur ZONE_NodeId pour les nuds-invitant.

67

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) NodeType - le type du nud qui pourrait tre NORMAL ou BORDER. Tous les nuds ont initialement le type NORMAL. Le nud devient de type BORDER lorsquil est la frontire avec une ou plusieurs zones. Ainsi, il est voisin de ces zones. BorderTable - la table-frontire dans laquelle le nud de type BORDER sauvegarde les informations concernant des nuds de type BORDER des zones voisines lui.

Z1

Z2

Z3

Nud BORDER

Z4

Z5

Z6

Nud NORMAL

Figure 3.4 : Partitionnement dun rseau en zones

La Figure 3.4 montre un exemple dun rseau partitionn en zones virtuelles (la forme rectangulaire est donne titre dexemple). Les nuds BORDER (en blanc) joueront le rle de relais entre les zones. Lorsquun paquet de donnes passe dune zone une autre, il parcourt ces nuds BORDER qui peuvent tre voisins de plusieurs zones (le nud A, dans la Figure 3.4, est voisin des zones Z5 et Z3).

3.2.1 Structure du paquet de contrle chang

Le partitionnement dun rseau de capteurs en zones virtuelles requiert lchange des informations spcifiques. Pour cela, un paquet de contrle particulier a t conu. Les champs de ce paquet, appel ConstructZonesPacket, chang durant lexcution de lalgorithme de partitionnement sont illustrs dans le Tableau 2.

68

Algorithme distribu de partitionnement dun rseau de capteurs en zones

SrcId DestId ZoneId Subject NodeType TTL identificateur global ID du nud metteur du paquet identificateur global ID du nud destinataire identificateur de la zone du nud metteur du paquet sujet du paquet type du nud metteur du paquet Time To Live, dure de vie du paquet
Tableau 2 : Champs du paquet ConstructZonesPacket

Le champ Subject dun paquet ConstructZonesPacket dfinit son sujet. Ce champ peut avoir trois valeurs diffrentes : INVITATION : Il sagit dun paquet dinvitation une certaine zone. Ce paquet est initialement envoy par les nuds-invitant. Il est rediffus par les nuds qui rejoignent cette zone selon leur situation. Le premier paquet diffus par le nud-invitant a un TTL gal R (Rayon de la zone). DISAGREEMENT : il sagit dun paquet de refus dinvitation. Ce paquet est envoy quand un nud, dj attribu une certaine zone, reoit un paquet dinvitation une autre zone. Il sert aussi dfinir les nuds BORDER et complter la table BorderTable. BORDER : ce paquet est utilis, typiquement par un nud BORDER, pour informer ses voisins de son type. Ce paquet sert galement dfinir les nuds BORDER et complter la table BorderTable. NEW_NODE : ce type de paquet est chang lapparition dun nouveau nud dans le rseau. Il sert attribuer ce nouveau nud une certaine zone. A noter que lorsquun nud diffuse ou envoie un message dans un rseau sans-fil, tous les nuds dans sa porte de communication reoivent ce message. Nous les dsignerons par les nuds voisins ( un seul saut). Par exemple, si un nud veut envoyer un message un destinataire spcifique, il diffuse le message en spcifiant le destinataire concern par le message ; tous les nuds qui sont dans la porte de communication de ce nud reoivent le message mais seul le nud destinataire le traite. Donc, il ne sagit pas dun vrai unicast dans les rseaux sans fils comme dans les rseaux filaires.

69

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol)

3.2.2 Description de lalgorithme distribu de partitionnement en zones

INPUT : R PART A : IF (n is an inviting node) THEN Send a packet P (n.NodeId, ANY, n.ZONEID, INVITATION, NORMAL, R-1)[only once] ENDIF PART B : IF (n receives a packet P) THEN PART B.1 : IF (P.Subject = INVITATION) THEN IF (n.ZoneId is undefined) THEN Join the zone [n.ZONEID := P.ZONEID] IF (P.TTL = 0) THEN n.NodeType := BORDER Send a P(n.NodeId, ANY, n.ZONEID, BORDER, n.NodeType, 1) ELSE Send a packet P'(n.NodeId, ANY, n.ZONEID, INVITATION, n.NodeType, P.TTL - 1) ENDIF ELSE IF (n.ZONEID P.ZONEID) THEN n.NodeType := BORDER Send a packet P(n.NodeId, ANY, n.ZONEID, DISAGREEMENT, n.NodeType, 1) n.BorderTable.add(P.ZONEID, P.SrcId) ENDIF ENDIF ENDIF PART B.2 : IF (P.Subject = BORDER OR P.Subject = DISAGREEMENT) THEN IF (n.ZONEID P.ZONEID) THEN n.NodeType := BORDER n.BorderTable.add(P.ZONEID, P.SrcId) IF (BorderTable is modified) THEN Send a packet P(n.NodeId, ANY, n.ZONEID, BORDER, n.NodeType, 1) ENDIF ENDIF ENDIF PART C : IF (P.Subject = NEW_NODE) THEN Send a packet P(n.NodeId, P.SrcId, n.ZONEID, INVITATION, n.NodeType, 1) ENDIF ENDIF OUTPUT : BorderTable, ZoneID, NodeType at node n

Figure 3.5: Algorithme de partionnement dun rseau en zones virtuelles

Dans notre algorithme distribu propos, des informations concernant les nuds du rseau (lnergie, ltat des liens, la position gographique, etc.) ne sont pas ncessaires. Chaque nud possde un identificateur global NodeId. Lalgorithme excut par chaque nud du rseau, dune manire distribue, est illustr en pseudo-code dans la Figure 3.5.

70

Algorithme distribu de partitionnement dun rseau de capteurs en zones Initialement, les zones sont formes des nuds-invitant (un nud par zone7). Ces nuds-invitant diffusent un paquet dinvitation une seule fois leurs voisins (voir la Figure 3.5, partie A). Ce paquet dinvitation a un TTL gal R (rayon de la zone). Cette partie de code nest excute que par les nuds-invitant. Dans le but de spcifier le type de chaque nud NodeType et de complter la table-frontire BorderTable (stockant des informations utiles dans la phase de construction de la table de routage entre les zones), les nuds changent galement des paquets dont les sujets sont DISAGREEMENT ou BORDER. La partie B de la Figure 3.5 dcrit le comportement dun nud lorsquil reoit un de ces deux paquets. Quand un nud reoit un paquet dinvitation (voir la Figure 3.5, partie B.1), il le traite selon sa situation (sil est dj affect une certaine zone ou pas). Sil nest pas affect, il rejoint la mme zone du nud metteur du paquet. Si le TTL du message est gal zro, le nud est alors un nud BORDER, il diffuse ses voisins un paquet de type BORDER de TTL gal 1. Sinon, il rediffuse le message aprs avoir dcrment son TTL de 1. Quand un nud, dj affect une certaine zone, reoit un paquet dinvitation dun nud appartenant une autre zone, il change son type BORDER, puis il rpond en diffusant un paquet de type DISAGREEMENT de TTL gal 1. Lorsquun nud reoit un paquet de type DISAGREEMENT ou de type BORDER dun nud appartenant une autre zone (voir la Figure 3.5, partie B.2), il change son type en BORDER et enregistre le NodeId et ZoneID du nud metteur du paquet dans sa table BorderTable sils ny existent pas. Si la table BorderTable a t modifie, le nud diffuse un paquet de type BORDER de TTL gal 1. De cette faon, lchange des paquets BORDER sarrte lorsquil ny a plus de nouvelles informations insrer dans la table BorderTable. Lorsquun nud reoit un paquet de type NEW_NODE (voir la Figure 3.5, partie C), ceci signifie quil y a un nouveau nud qui apparat dans son voisinage. Pour cela, le nud rpond par un paquet dinvitation (de type INVITATION) de TTL gal 1 afin de joindre sa zone. A la fin de lexcution de cet algorithme, chaque nud doit tre attribu une certaine zone et avoir dfini son type. Pourtant, certains nuds pourraient rester sans aucune affectation. Ceci dpend, en effet, des paramtres de lalgorithme : le nombre de zones (zN), le rayon de la zone (R), le nombre de nuds (N) et leurs positions. Les nuds aux frontires (de type BORDER) possdent une table-frontire (BorderTable) utilise plus tard dans la phase de construction de la table de routage entre les zones. Chaque entre de la table BorderTable contient les informations suivantes : NeighZoneId - lidentification de la zone voisine avec le nud, BorderNodesIds - la liste des nuds appartenant la zone voisine et qui sont en communication directe ( un seul saut) avec le nud BORDER possdant la table BorderTable. Ces nuds sont galement des nuds de type BORDER dans leur zone.

A rappeler que le nombre de nuds-invitant est gal au nombre de zones zN (paramtre de lalgorithme)

71

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) TimeOut la dure de vie de lentre de la table. Cette information est utilise pour la maintenance de la table BorderTable. Le Tableau 3 montre un exemple dune table-frontire (BorderTable) pour un certain nud BORDER N1 qui est voisin de deux zones Z2 et Z5. N1 est en communication directe avec les nuds N30, N18 et N17 qui appartiennent la zone Z2 et avec les nuds N13 et N14 qui appartiennent la zone Z5 (voir le Tableau 3). Chaque entre possde un TimeOut qui dfinit la dure de vie de lentre. Ce champ est utile pour la maintenance des tables BorderTable explique plus tard.
NeighZoneId BorderNodesIds N30 Z2 N18 N17 N13 Z5 N14 T5 TimeOut T1 T2 T3 T4

Tableau 3 : Exemple de table-frontire BorderTable

3.2.3 Maintenance de la topologie

La structuration du rseau en zones est ralise lors du dploiement des nuds sur la surface explorer. Cependant, cette infrastructure nest pas fige cause des vnements particuliers qui sont : lapparition dun nud, la panne dun nud ou la mobilit dun nud. Ceux-ci doivent tre pris en compte dans la maintenance de la structure. Cette maintenance requiert gnralement des informations de mise jour des nuds voisins lorsquun nud rejoint ou quitte le rseau (d une dfaillance), et/ou lorsquun nud se dplace. Dans notre algorithme de partitionnement, si un nouveau nud rejoint le rseau il doit envoyer un paquet de type NEW_NODE pour quil se signale dans le rseau et quil demande tre affect une certaine zone qui est normalement la zone de ses voisins. Le nud qui reoit ce paquet (voir la Figure 3.5, partie C) rpond par un paquet dinvitation la zone laquelle il appartient. Par suite, le nouveau nud rejoindra cette zone. Supposons que le nouveau nud reoit plusieurs paquets dinvitation plusieurs zones, il rejoint la zone du premier paquet arriv et traite les autres comme illustr dans la Figure 3.5, partie B.1. En ce qui concerne la dfaillance des nuds, seuls les nuds BORDER envoient rgulirement des paquets de dcouverte de voisin (par exemple un paquet HELLO) afin de mettre jour leurs tables BorderTable. Ce paquet HELLO, de TTL gal 1, contient le NodeId du nud metteur et sa zone ZoneId. Il ny a pas besoin dune rponse pour ce paquet comme tous les nuds

72

Algorithme distribu de partitionnement dun rseau de capteurs en zones

BORDER lchangent priodiquement. Par exemple, si le nud BORDER (possdant le Tableau 3) ne reoit pas un paquet HELLO du nud N30 aprs un TimeOut T1, lentre sera supprime
du tableau. La dfaillance dun nud NORMAL na aucun effet dans la topologie actuelle du rseau. Elle sera traite plus tard dans la partie de routage o la panne dun nud NORMAL influe la topologie. Dans les rseaux dynamiques, la mobilit des nuds est un dfi traiter. A la fin de cette phase de partitionnement du rseau, la mobilit ne peut tre gre que si on suppose que les nuds peuvent dtecter eux-mmes leur dplacement (par exemple en possdant un capteur vitesse). Par la suite, la mobilit dun nud peut tre interprte dans la maintenance de la topologie comme une dfaillance de ce nud et son apparition dans le rseau un autre emplacement gographique. Cette mobilit peut tre reflte dans notre topologie de rseau base sur les zones de la manire suivante : un nud se dplaant dun endroit un autre dans le rseau rinitialise ses attributs BorderTable et ZoneID, puis il diffuse un paquet de type NEW_NODE. Les nuds qui reoivent ce paquet rpondent par un paquet dinvitation leurs zones. Le nud mobile, la rception du paquet dinvitation, le traite suivant lalgorithme dcrit dans la Figure 3.5, partie B.1. Les protocoles de routage base de tables utilisent des tables chez chaque nud afin deffectuer le routage des donnes dans le rseau. Les protocoles hirarchiques ( deux niveaux) base de tables exigent des tables deux niveaux : tables pour le routage lintrieur dune zone et tables pour le routage entre les zones. La construction de ces deux types de tables est dtaille dans les sections suivantes, en se basant sur la topologie hirarchique partitionnant le rseau en zones virtuelles.

3.3

Construction de la table de routage intra-zone

Afin deffectuer la communication entre les nuds dun rseau, chaque nud doit possder des informations sur dautres nuds. Par exemple, il doit connatre ses nuds voisins, dautres nuds plus loin et le cot de communication (nombre de sauts, quantit dnergie, etc.) pour les atteindre. La table est une des structures stockant ces informations. Dans notre approche et dans la phase qui suit le partitionnement du rseau en zones, nous construirons une table de routage dans chaque zone. Chaque nud possdera cette table appele dans la suite, la table intra-zone. Afin daccomplir cette phase, nous avons utilis lalgorithme Distance Vector (Bellmand-Ford) dune manire distribue. Comme nous lavons vu prcdemment, DV est simple et efficace pour les petits rseaux. Il nexige pas beaucoup de calculs, ni de communications, ni de stockage. La mtrique utilise est le nombre de sauts (hop). La mthode Maximum Count a t utilise afin dviter les boucles de routage (comme dans le protocole RIP (10)). En profitant des paquets changs, appels par la suite IntraZonePacket, durant la construction des tables de routage intra-zone, nous avons modifi lalgorithme DV afin de dfinir dans la table de routage intra-zone les informations suivantes :

73

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) le type de chaque nud - BORDER pour les nuds qui sont la frontire dune ou de plusieurs zones, NORMAL pour les autres, la/les zone(s) avec laquelle un nud BORDER est voisin. Nous avons pu calculer galement, durant lchange de ces paquets, ce que nous avons dfini la mtrique de la zone : cest le cot de passage travers cette zone en termes de nombre de sauts. Cette mtrique utilise dans la phase suivante servira la construction des tables de routage entre les zones. Nous avions six choix possibles pour calculer cette mtrique. Quatre choix se basent sur le calcul de la moyenne des mtriques dans chaque table intra-zone : 1. la moyenne des moyennes des mtriques dans chaque table intra-zone, 2. le maximum des moyennes des mtriques dans chaque table intra-zone, 3. la moyenne des moyennes des mtriques des nuds BORDER dans chaque table intrazone, 4. le maximum des moyennes des mtriques des nuds BORDER dans chaque table intrazone. et deux autres choix se basant sur le maximum des mtriques dans chaque table intra-zone : 5. le maximum des maximums des mtriques dans chaque table de routage intra-zone, 6. la moyenne des maximums des mtriques dans chaque table de routage intra-zone. En dautres termes, cest la moyenne des plus longs chemins chez chaque nud de la zone. Nous avions jug que le dernier choix est le meilleur. En effet, emprunter le plus long chemin caractrise le pire des cas ; ce chemin est gnralement un chemin entre deux nuds BORDER de la zone comme ils sont lextrmit de la zone. Si nous calculons la moyenne des mtriques dune table de routage (choix 1 et 2), alors les mtriques des chemins entre les nuds NORMAL sont prises en compte dans ce calcul. Ceci ne nous intresse pas car nous ne voulons que les mtriques des chemins entre les nuds BORDER. Dailleurs, les choix 3 et 4 ont t limins car le calcul de la mtrique de la zone prend en compte des chemins entre des nuds BORDER, qui ne sont pas les plus longs chemins. Les choix 5 et 6 rpondent nos attentes puisque les maximums des mtriques dans toutes les tables intra-zone (les plus longs chemins) sont extraits et le calcul de la mtrique est bas seulement sur ces mtriques. Dailleurs nous avons prfr le choix 6 dans le but davoir des mtriques de valeurs proches pour les diffrentes zones. Ainsi, le passage sera quitable travers les zones comme nous allons se baser sur ces mtriques pour choisir une zone traverser. Ainsi les petites zones ayant une faible mtrique seront moins sollicites.

74

Construction de la table de routage intra-zone Chaque entre de la table de routage intra-zone est compose de quatre champs : DestNodeId lID du nud destinataire, NextHopId le nud suivant emprunter afin datteindre la destination. Cest le nud auquel le message sera transfr, Metric la mtrique du chemin. Cest le cot en termes de nombre de sauts pour atteindre la destination DestNodeId, NodeType le type du nud (BORDER ou NORMAL), ZoneIds la liste des IDs des zones auxquelles le nud destinataire DestNodeId est voisin, TimeOut la dure de vie de lentre dans la table.

Z1

Z2

Nud BORDER Nud NORMAL

Z3

N2 N3 N4 N0

N9 N8

N6 N1 N5 N7

Figure 3.6 : Exemple dune rpartition de nuds dans trois zones

Le Tableau 4 montre une table de routage intra-zone chez le nud BORDER N6 qui appartient la zone Z2 illustre dans la Figure 3.6. Comme nous le remarquons, les entres des nuds BORDER N1 et N4 contiennent la zone (Z1) avec laquelle ces nuds sont voisins.

75

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol)
DestNodeId N0 N1 N2 N3 N4 N5 N6 N7 N8 N9 NextHopId N7 N7 N9 N7 N7 N7 N6 N7 N7 N9 Metric 2 4 2 3 3 3 0 1 2 1 NodeType NORMAL BORDER NORMAL NORMAL BORDER NORMAL BORDER NORMAL NORMAL NORMAL Z3 Z1 Z1 ZoneIds TimeOut T0 T1 T2 T3 T4 T5 T6 T7 T8 T9

Tableau 4 : Table de routage intra-zone chez le nud N6

La section suivante dcrit la phase de construction de la table entre les zones. Cette table sert router les donnes dune zone une autre travers les nuds BORDER.

3.4

Construction de la table de routage inter-zones

Aprs avoir partitionn le rseau en zones et avoir construit les tables de routage intra-zone (IntraZoneRoutingTable) dans chaque nud, une table est ncessaire pour le routage entre les zones. Le principe de lalgorithme distribu Distance Vector (Bellman Ford) est aussi appliqu pour la construction de cette table. Seuls les nuds BORDER la possderont car ils feront le relais entre les zones durant lchange des paquets de donnes. A la fin de cette phase de construction, les nuds BORDER de la mme zone auront la mme table. Dailleurs, elle est diffrente dune zone une autre. Cette table est appele par la suite table inter-zones.

3.4.1 Structure du paquet chang

La construction des tables inter-zones requiert, comme pour les tables intra-zone, des paquets de contrle particuliers. La structure de ce paquet de contrle chang durant cette phase, appel InterZonesPacket, est illustre dans le Tableau 5.

76

Construction de la table de routage inter-zones

SrcId NextHopId identificateur global ID du nud metteur du paquet identificateur global ID du nud suivant emprunter afin datteindre la destination identificateur global ID du nud destinataire final du paquet identificateur de la zone du nud metteur du paquet sujet du paquet table inter-zone change
Tableau 5 : Structure du paquet de contrle InterZonesPacket

FinalDestId ZoneId Subject ZoneTable

La table inter-zones change dans le champ ZoneTable du paquet peut tre une partie de la table (des mises jour de la table). Le nud destinataire du paquet (FinalDestId) peut savoir si la table est complte ou non partir de la valeur du champ Subject.

3.4.2 Algorithme distribu de construction des tables inter-zones

Afin dviter la redondance des calculs et pour ne pas charger le rseau par lchange des paquets de contrle (InterZonesPacket), un nud BORDER est dsign comme le chef des nuds BORDER dans une mme zone. Ce nud, appel nud-chef, sera le reprsentant de la zone durant cette phase. Les nuds-chef des zones schangent des paquets afin dtablir la table interzones. Ce sont les nuds qui ont le plus grand identificateur parmi les nuds BORDER de leurs zones. Les nuds peuvent extraire cette information partir de la table de routage intra-zone (par exemple, N6 est le nud-chef de la zone Z1 dans la rpartition illustre dans la Figure 3.6). Par ce fait, nous avons rduit le nombre de messages changs dans le rseau. Normalement, tous les nuds BORDER devront participer la construction de la table de routage inter-zones comme ils en auront besoin durant le routage de donnes. Pourtant, un seul nud BORDER a t dsign pour faire ce travail. Puis, la fin de la construction de cette table, il la diffuse aux autres nuds BORDER dans sa zone. Par la suite, le type du nud-chef sera CHIEF-BORDER. Lalgorithme est constitu de deux phases : phase dinitialisation et phase dchange des tables inter-zones.

a) Phase dinitialisation
Rappelons que chaque nud-chef possde pour linstant deux tables : une table frontire (comme le montre le Tableau 3) et une table de routage intra-zone (comme le montre le Tableau 4). Par une simple lecture de ces deux tables, le nud-chef extrait une nouvelle structure de donnes, la table inter-zones. Une entre dans cette table contient trois champs : DestZoneId - la zone destination,

77

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) NextZoneId - la zone suivante emprunter, ZoneM - la mtrique pour atteindre la zone destination DestZoneId. Au dbut, la table inter-zones contient des informations de base. Reprenons lexemple du nudchef N6 qui appartient la zone Z2 et qui dispose dune table de routage intra-zone (voir le Tableau 4) et dune table-frontire (voir le Tableau 3). Supposons que la mtrique de la zone Z2 est gale 7. La table inter-zones chez le nud-chef N6 est illustre dans le Tableau 6.
DestZoneId Z1 Z3 NextZoneId Z1 Z3 ZoneM 7 7

Tableau 6 : Table inter-zones chez N6 appartenant la zone Z2

Nous remarquons dans le Tableau 6 que les mtriques pour toutes les zones destinations ont la mme valeur. En fait, cette mtrique, dj calcule dans la phase de construction de la table intrazone, est le cot de passage travers la zone Z2. Comme toutes les zones destinations dans cette table sont initialement des zones voisines la zone Z2, alors leurs mtriques sont les mmes : le cot de passage travers la zone Z2. Nous remarquons aussi que la zone suivante emprunter NextZoneId a la mme valeur que DestZoneId, ceci est d au fait que ces zones destinatrices sont des zones voisines Z2. En dautres termes, cette table inter-zones contient, dans la phase dinitialisation, les informations concernant les zones voisines de la zone courante.

b) Phase dchange des tables inter-zones

Avant de dtailler lalgorithme distribu de construction des tables de routage inter-zones (InterZoneRoutingTable), nous citerons la structure de donnes existante jusqu cette tape dans les nuds du rseau. Chaque nud possde : NodeId, NodeType, ZoneId et la table de routage intra-zone (IntraZoneRoutingTable). Si le nud est un noeud BORDER, il possde de plus la table-frontire BorderTable. Si le nud est un nud-chef (de type CHIEF-BORDER), il dispose de plus de la table inter-zones (InterZoneRoutingTable). Le nud-chef, dans chaque zone, lance lexcution de lalgorithme distribu. Cette premire tape est illustre en pseudo-code dans la Figure 3.7. Il envoie au dpart (Figure 3.7, partie A) sa table inter-zones aux nuds BORDER de sa zone dune manire optimise (un seul nud par zone). Puis, il lenvoie aux nuds BORDER des zones voisines lui (Figure 3.7, partie B) de la mme manire optimise (un seul nud par zone).

78

Construction de la table de routage inter-zones

IF (n.NodeType = CHIEF-BORDER) THEN PART A : TempZones := For each entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER DO For each zone in entryRT.ZoneIds | zone TempZones DO Send a packet P (n.NodeId, entryRT.NextHopId, entryRT.DestNodeId, n.ZoneId, UPDATE_TABLE, n.InterZoneRoutingTable) Save zone in TempZones ENDDO ENDDO PART B : For each entryBT in BorderTable DO For each node in entryBT.BorderNodesIds DO Choose randomly node from entryBT.BorderNodesIds Send a packet P (n.NodeId, node, NULL, n.ZoneId, UPDATE_TABLE, n.InterZoneRoutingTable) ENDDO ENDDO ENDIF

Figure 3.7 : Algorithme denvoi de la table inter-zones par le noeud-chef

Ces paquets envoys par les nuds-chef de chaque zone seront traits par les nuds du rseau suivant lalgorithme illustr dans la Figure 3.8. A noter que durant lexcution de lalgorithme, les mtriques pour atteindre les zones destinations sont galement calcules. Dcrirons lalgorithme. Lorsquun nud NORMAL n reoit un paquet (Figure 3.8, partie A), il le transfre au nud suivant pour atteindre le destinataire final par un routage intra-zone. Si n est le nud-chef (Figure 3.8, partie B), il met jour sa table InterZoneRoutingTable. Si cette table nest pas encore complte, n envoie les mises jour aux nuds BORDER de sa zone (un nud par zone) et des zones voisines lui (un nud par zone). Si la table est complte, n lenvoie tous les nuds BORDER de sa zone. Si n nest pas le nud-chef mais un nud BORDER (Figure 3.8, partie C) et que le paquet reu arrive dune autre zone, il le transfre au nud-chef par un routage intra-zone. Si le paquet a t reu de sa zone et quil lui est destin (paquet envoy par le nud-chef), n le transfre aux nuds BORDER des zones voisines lui (un nud par zone) lorsquil sagit dun paquet de mise jour de la table inter-zones (UPDATE_TABLE). Sinon, n sauvegarde la table de routage complte inter-zones. Si le paquet nest pas destin au noeud n (il nest pas le destinataire final), il transfre le paquet au nud suivant pour atteindre le destinataire final par un routage intra-zone.

79

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol)

INPUT : InterZoneRoutingTable at CHIEF-BORDER nodes When node n receives a packet P PART A : IF (n.NodeType = NORMAL) THEN Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = P.FinalDestId Send a packet P(n.NodeId, entryRT.NextHopId, P.FinalDestId, n.ZoneId, P.Subject, P.ZoneT) ELSE PART B : IF (n.NodeType = CHIEF-BORDER) THEN UPDATE n.InterZoneRoutingTable IF (InterZoneRoutingTable is not complet) THEN TempZones := For each entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER DO For each zone in entryRT.ZoneIds | zone TempZones DO Send a packet P(n.NodeId, entryRT.NextHopId, entryRT.DestNodeId, n.ZoneId, UPDATE_TABLE, n.InterZoneRoutingTable) Save zone in TempZones ENDDO ENDDO For each entryBT in BorderTable DO Choose randomly node from entryBT.BorderNodesIds Send a packet P (n.NodeId, node, NULL, n.ZoneId, UPDATE_TABLE, n.InterZoneRoutingTable) ENDDO ELSE For each entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER DO Send a packet P(n.NodeId, entryRT.NextHopId, entryRT.DestNodeId, n.ZoneId, COMPLET_TABLE, n.InterZoneRoutingTable) ENDDO ENDIF ELSE PART C : IF (n.ZoneId P.ZoneId) THEN Find entryRT in IntraZoneRoutingTable | entryRT.NodeType = CHIEF-BORDER Send a packet P(n.NodeId, entryRT.NextHopId, entryRT.DestNodeId, n.ZoneId, P.Subject, P.InterZoneRoutingTable) ELSE IF (n.NodeId = P.FinalDestId) THEN IF (P.Subject = UPDATE_TABLE) THEN For each entryBT in BorderTable DO Choose randomly node from entryBT.BorderNodesIds Send a packet P (n.NodeId, node, NULL, n.ZoneId, P.Subject, P.ZoneT) ENDDO ELSE Save P.ZoneT in n.InterZoneRoutingTable ENDIF ELSE Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = P.FinalDestId Send a packet P(n.NodeId, entryRT.NextHopId, P.DestNodeId, n.ZoneId, P.Subject, P.ZoneT) ENDIF ENDIF ENDIF ENDIF OUTPUT : InterZoneRoutingTable at BORDER nodes

Figure 3.8 : Algorithme de construction de la table inter-zones

80

Construction de la table de routage inter-zones A la fin de lexcution de lalgorithme distribu, tous les nuds BORDER dans le rseau possdent une table inter-zones qui servira au routage entre les zones. Cette table inter-zones est videmment la mme chez les nuds BORDER de la mme zone et diffrente de celles des autres zones.

3.4.3 Exemple de table inter-zones

Dans cette section, nous montrons un exemple de table inter-zones. La Figure 3.9 illustre un rseau dcoup en 9 zones virtuelles (zones en rectangle titre dexemple). Chaque zone a une mtrique (valeurs entre parenthses). Nous nous intressons dans cet exemple aux liens entre les zones (dsigns par des flches entre les nuds BORDER) et aux tables inter-zones. Sil y a une ou plusieurs flches entre deux zones, ceci veut dire que ce sont deux zones voisines.
Z 1(4) Z2(7) Z3(8)

Nud BORDER

Z4(5)

Z5(7)

Z6(5)

Nud NORMAL

Z7(3)

Z8(4)

Z9(5)

Figure 3.9 : Rseau dcoup en 9 zones

La table inter-zones chez les nuds BORDER de la zone Z1 de la Figure 3.9 est illustre dans le Tableau 7. Nous remarquons que la mtrique des zones voisines de Z1 (Z2 et Z4) est gale la mtrique de la zone Z1. Un chemin dune zone courante (dans notre exemple Z1) une zone destination a un cot gal la somme de la mtrique de la zone courante et des mtriques des zones intermdiaires

81

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol)
DestZoneId Z2 Z3 Z4 Z5 Z6 Z7 Z8 Z9 NextZoneId Z2 Z2 Z4 Z4 Z4 Z4 Z4 Z4 ZoneM 4 11 4 9 16 9 12 16

Tableau 7 : Table de routage inter-zones des nuds BORDER da la zone Z1

3.5

Scnario de routage de donnes

Le routage efficace des donnes entre les nuds dun rseau est le but des protocoles de routage. Dans cette section, nous dcrirons algorithmiquement comment les nuds changent les donns en se basant sur notre approche hirarchique dcrite prcdemment.

3.5.1 Structure du paquet de donnes

SrcId LocalDestId NextHopId identificateur global ID du nud metteur du paquet identificateur global ID du nud destinataire local identificateur global ID du nud suivant emprunter afin datteindre la destination locale identificateur global ID du nud destinataire final du paquet identificateur de la zone destinataire donnes transmises
Tableau 8 : Structure dun paquet DataPacket

FinalDestId DestZoneId Data

Lorsque les nuds veulent changer des donnes, ils gnrent un paquet de donnes, appel

82

Scnario de routage de donnes

DataPacket, dont la structure est illustre dans le Tableau 8. Le champ FinalDestId dfinit le
dernier nud qui doit recevoir les donnes Data. Ce champ a toujours la mme valeur dans le paquet chang entre la source et la destination. Dailleurs, le champ LocalDestId dfinit le champ du nud destinataire local, cest--dire le destinataire lintrieur dune zone. En effet, afin de router un paquet, le routage est ralis par le routage interne (dans la zone) et le routage externe (entre les zones). Le champ LocalDestId est utilis pour router le paquet lintrieur dune zone. FinalDestId et LocalDestId ont la mme valeur lorsque le paquet arrive la zone destination, dfinie par DestZoneId, qui contient le nud destinataire final (FinalDestId).

3.5.2 Dtails de lapplication du scnario de routage

Rappelons que chaque nud du rseau possde la structure suivante : NodeId, NodeType, ZoneId, IntraZoneRoutingTable. Sil est un nud BORDER, il possde de plus les deux tables BorderTable et InterZoneRoutingTable. Un nud source n voulant mettre un paquet de donnes un nud destinataire n applique lalgorithme illustr dans la Figure 3.10. Si les deux nuds appartiennent la mme zone, un routage intra-zone aura lieu (Figure 3.10, partie A). Dans le cas contraire, le nud source envoie le paquet selon son type. Si le nud source n est un nud NORMAL (Figure 3.10, partie B), il cherche dans sa table de routage intra-zone sil y a un nud voisin de la zone dappartenance du nud destinataire. Sil en trouve un, il lui transfre son paquet de donnes. Sil nen trouve pas, cela signifie que la zone destination nest pas une zone voisine de sa zone. Dans ce cas, il transfre son paquet de donnes un des nuds BORDER. Si le nud source n est un nud BORDER (Figure 3.10, partie C) et voisin de la zone destination, il transfre le paquet de donnes un des nuds BORDER de la zone destination. Sil nest pas voisin de la zone destination, mais un autre nud BORDER de sa zone lest, il lui transfre le paquet de donnes. Le cas chant, le nud n cherche dans la table inter-zones la zone suivante pour atteindre la zone destination. Sil est voisin de la zone suivante trouve, il transfre le paquet de donnes un des nuds BORDER de cette zone. Sil ne lest pas, il transfre le paquet un nud BORDER de sa zone mais qui est voisin de la zone suivante trouve dans la table interzones. Aprs lenvoi du premier paquet par le nud source, chaque nud du rseau, afin dacheminer le paquet jusquau nud destinataire, transfre le paquet suivant les donnes de routage dont il dispose. Le comportement de chaque nud du rseau, la rception dun paquet de donnes, est dtaill dans la Figure 3.11.

83

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol)

When source node n wants to send DATA to destination node n PART A : IF (n.ZoneId = n.ZoneId) THEN Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = n.NodeId Send a packet P (n.NodeId, n.NodeId, entryRT.NextHopId, n.NodeId, n.ZoneId, DATA) ELSE PART B : IF (n.NodeType = NORMAL) THEN TempNodes := For each entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER DO For each zone in entryRT.ZoneIds DO IF (zone = n.ZoneId) THEN Save entryRT.DestNodeId in TempNodes ENDIF ENDDO ENDDO IF (TempNodes ) THEN Choose randomly destNode from TempNodes Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = destNode Send a packet P (n.NodeId, destNode, entryRT.NextHopId, n.NodeId, n.ZoneId, DATA) ELSE Find randomly entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER Send P (n.NodeId, entryRT.DestNodeId, entryRT.NextHopId, n.NodeId, n.ZoneId, DATA) ENDIF ELSE PART C : IF ( entryBT in BorderTable | n.ZoneId = entryBT.neighZoneId) THEN Choose randomly node from entryBT.borderNodesIds Send P (n.NodeId, node, node, n.NodeId, n.ZoneId, DATA) ELSE Find entryZone in InterZoneRoutingTable | entryZone.DestZoneId = n.ZoneId IF ( entryBT in BorderTable | entryZone.NextZoneId = entryBT.neighZoneId) THEN Choose randomly node from entryBT.borderNodesIds Send P (n.NodeId, node, node, n.NodeId, n.ZoneId, DATA) ELSE TempNodes := For each entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER DO For each zone in entryRT.ZoneIds DO IF (zone = entryZone.NextZoneId) THEN Save entryRT.DestNodeId in TempNodes ENDIF ENDDO ENDDO Choose randomly destNode from TempNodes Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = destNode Send a packet P (n.NodeId, destNode, entryRT.NextHopId, n.NodeId, n.ZoneId, DATA) ENDIF ENDIF ENDIF ENDIF

Figure 3.10 : Algorithme appliqu par le noeud source lors de lenvoi dun paquet de donnes

84

Scnario de routage de donnes

When a node n receives a data packet P PART A : IF (n.NodeId = P.FinalDestId) THEN Process P.data ELSE PART B : IF (n.ZoneId = P.DestZoneId) THEN Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = P.FinalDestId Send a packet P (n.NodeId, P.FinalDestId, entryRT.NextHopId, P.FinalDestId, P.DestZoneId, P.data) ELSE PART C : PART C.1 : IF (n.NodeType = NORMAL) THEN Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = P.LocallDestId Send a packet P (n.NodeId, P.localDestId, entryRT.NextHopId, P.FinalDestId, P.DestZoneId, P.data) ELSE PART C.2 : IF ( entryBT in BorderTable | entryBT.neighZoneId = P.DestZoneId) THEN Choose randomly node from entryBT.borderNodesIds Send P(n.NodeId, node, node, P.FinalDestId, P.DestZoneId, P.data) ELSE PART C.3 : TempNodes := For each entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER DO For each zone in entryRT.ZoneIds DO IF (zone = P.DestZoneId) THEN Save entryRT.DestNodeId in TempNodes ENDIF ENDDO ENDDO IF (TempNodes ) THEN Choose randomly destNode from TempNodes Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = destNode Send P(n.NodeId, destnode, entryRT.NextHopId, P.FinalDestId, P.DestZoneId, P.data) ELSE PART C.4 : Find entryZone in InterZoneRoutingTable | entryZone.DestZoneId = P.DestZoneId IF ( entryBT in BorderTable |entryBT.neighZoneId = entryZone.NextZoneId) THEN Choose randomly node from entryBT.borderNodesIds Send P(n.NodeId, node, node, P.FinalDestId, P.DestZoneId, P.data) ELSE PART C.5 : TempNodes := For each entryRT in IntraZoneRoutingTable | entryRT.NodeType = BORDER DO For each zone in entryRT.ZoneIds DO IF (zone = entryZone.NextZoneId) THEN Save entryRT.DestNodeId in TempNodes ENDIF ENDDO ENDDO Choose randomly destNode from TempNodes Find entryRT in IntraZoneRoutingTable | entryRT.DestNodeId = destNode Send a packet P (n.NodeId, destnode, entryRT.NextHopId, P.FinalDestId, P.DestZoneId, P.data) ENDIF ENDIF ENDIF ENDIF ENDIF ENDIF

Figure 3.11: Algorithme appliqu lors de la rception dun paquet de donnes

85

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) Si un nud n reoit un paquet de donnes dont il est le destinataire final, il traite les donnes du paquet (Figure 3.11, partie A). Sil ne lest pas, le nud n vrifie sil appartient la mme zone que le nud destinataire final du paquet afin de lui transfrer le paquet par un routage intra-zone (Figure 3.11, partie B). Sils se trouvent dans deux zones diffrentes, le comportement du nud est implment dans la partie C de la Figure 3.11. Si le nud n est NORMAL, il transfre le paquet au nud destinataire local (Figure 3.11, partie C.1). Si le nud n est BORDER et voisin de la zone destination du paquet, il transfre le paquet un nud BORDER de cette zone (Figure 3.11, partie C.2). Si le nud n nest pas voisin de la zone destination du paquet, mais un autre nud BORDER de sa zone lest, il lui transfre le paquet par un routage intra-zone (Figure 3.11, partie C.3). Si aucun nud de sa zone nest voisin de la zone destination du paquet, il cherche dans sa table inter-zones la zone suivante emprunter afin datteindre la zone destination. Il transfre le paquet un nud BORDER de cette zone suivante, sil en est voisin (Figure 3.11, partie C.4). Sinon, il transfre le paquet un nud BORDER appartenant sa zone et voisin de la zone suivante emprunter (Figure 3.11, partie C.5).

3.6

Maintenance des tables de routage

La maintenance des tables de routage intra-zone et inter-zones est ncessaire lorsquil y a une dfaillance, une apparition ou une mobilit dun nud. Lalgorithme Distance Vector (DV) permet aux nuds denvoyer priodiquement les mises jour de la table de routage afin de connatre les modifications de la topologie. Dailleurs, dans notre protocole et contrairement DV, aprs avoir fini la construction de la table intra-zone (IntraZoneRoutingTable), nous utilisons des messages de contrle priodiques8, appels HELLO, afin de dtecter une dfaillance ou une apparition dun nud et par la suite de mettre jour les tables. Si un nud dtecte un lien bris (d la non rception dun message HELLO dun nud voisin aprs lexpiration de son TimeOut), il met jour sa table et envoie ces mises jour ses voisins qui appliquent, leur tour, la mme procdure. Ainsi, linformation du lien bris se propage dans la zone sous forme des mises jour des tables intra-zone. Si ce nud dfaillant tait un nud BORDER, les nuds BORDER des zones voisines peuvent connatre cette nouvelle (lien bris) lors de lchange priodique des paquets de contrle (comme HELLO). Par la suite ils mettent jour leurs tables-frontire BorderTable. Lintrt de lenvoi priodique, durant la maintenance des tables, des messages - de petite taille -

HELLO est de minimiser la quantit de donnes changes (table entire dans DV) entre les
nuds. Par consquent, la consommation nergtique des nuds est minimise et la vie du systme est prolonge. Ainsi la convergence de la nouvelle information (nouveau nud, dfaillance, mobilit) est plus rapide surtout lorsque le dlai entre les envois rguliers est court.

Paquets avec un intervalle de temps paramtrable

86

Maintenance des tables de routage Si un nouveau nud apparat dans le rseau, il envoie un paquet de type NEW_NODE afin dtre affect une certaine zone (comme mentionn prcdemment dans la section de partitionnement du rseau en zones). Une fois ce nud affect une zone, il change des paquets de contrle DV avec ses voisins afin de construire sa table de routage intra-zone. Les voisins, leurs tours, mettent jour leurs tables intra-zone et propagent cette nouvelle information dans la zone en utilisant lalgorithme Distance Vector. Si ce nouveau nud constate quil est un nud BORDER (suite une rception de paquets dinvitation de diffrentes zones), sa table-frontire BorderTable quil possde est aussi mise jour par les paquets de contrle changs entre lui et les nuds un seul saut des zones voisines. De la mme manire que dans la phase de partitionnement en zones, la mobilit dun nud peut tre traite comme une dfaillance du nud dans lemplacement o il tait et son apparition dans le nouvel endroit. Donc, il envoie un paquet de type NEW_NODE afin dtre affect une certaine zone aprs avoir rinitialis ses attributs ( lexception de NodeId) comme sil est un nouveau nud. Puis il change des paquets de contrle DV pour construire sa table intra-zone. De mme, sil devient un nud BORDER il construit sa table-frontire BorderTable en changeant des paquets avec les nuds un seul saut des zones voisines. Notons que dans les trois cas prcdents, la mtrique de la zone (cot de passage travers la zone) est recalcule en utilisant les paquets DV. En ce qui concerne les tables inter-zones (InterZoneRoutingTable), si la mtrique dune certaine zone a chang dune manire significative (lcart entre lancienne valeur et la nouvelle valeur est grand), alors la procdure de construction des tables inter-zones est relance par le nud-chef de la zone. Ainsi, les tables inter-zones dans toutes les zones seront mises jour. La dtection du dplacement dun nud par le nud lui-mme reste un point cl pour enclencher la gestion de la mobilit. Les capteurs peuvent ne pas disposer de mcanismes physiques permettant didentifier le mouvement (comme par exemple les dtecteurs de vitesse ou les quipements permettant la localisation gographique). Dans ces cas, une solution logicielle devrait tre employe. Dans notre approche, un nud peut constater quil a t dplac sil ne reoit plus des messages priodiques HELLO dun certain nombre de ses voisins et en reoit des nuds non lists dans sa table intra-zone. Dailleurs lenvoi et la rception des paquets ConstructZonePacket, IntraZonePacket, InterZonePacket, et DataPacket ne peuvent pas indiquer la mobilit dun nud.

3.7

Conclusion

Dans ce chapitre, nous avons dcrit un protocole distribu de routage dans un rseau de capteurs tendu. Ce protocole est bas sur une topologie hirarchique issue dun dcoupage du rseau en zones virtuelles. Lalgorithme distribu de partitionnement du rseau en zones que nous avons propos ne requiert pas pralablement dinformations sur le rseau (par exemple, nergie des nuds, tats des

87

Protocole hirarchique de routage bas sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) liens, positions gographiques des nuds, etc.). Ce partitionnement est bas sur le nombre de sauts. Les zones sont disjointes. A la fin du dcoupage du rseau en zones virtuelles, chaque nud devrait tre affect une certaine zone. Nous classifions les nuds en deux types : BORDER si le nud est la frontire dune ou plusieurs zones et NORMAL dans le cas contraire. Les nuds BORDER jouent le rle de relais entre les zones. Nous neffectuons pas de clusterisation et nous ne nous intressons pas llection des clusters head qui exige gnralement des informations sur le rseau et provoque de la consommation nergtique. Contrairement aux protocoles bass sur la clusterisation qui exigent gnralement plus de ressources matrielles pour certains nuds (comme les cluster heads), nous nimposons pas cette contrainte pour lutilisation de notre protocole de routage. Le routage des donnes, dans notre protocole, se ralise deux niveaux : intra-zone et interzones. Nous parlons de routage intra-zone lorsque le paquet de donnes est achemin lintrieur dune zone. Lorsquil sagit du passage du paquet dune zone une autre, nous parlons de routage inter-zones. Le routage se ralise dune manire compltement distribue et ne dispose pas dune centralisation comme dans la clusterisation (les nuds envoient leurs paquets aux cluster heads qui les transmettent la station de base). Chaque nud du rseau possde une table de routage dont la construction est base sur lalgorithme Distance Vector (Bellman-Ford). Cette table sert au routage intra-zone. Les entres de cette table, chez un tel nud, contiennent les informations de routage vers tous les autres nuds de la mme zone. Durant la phase de construction de la table intra-zone, des informations concernant les nuds (sils sont NORMAL ou BORDER, leurs zones voisines, etc..) ont pu tre dcouvertes et la mtrique de chaque zone a t calcule. Cette mtrique est dfinie comme le cot de passage travers la zone. Cette information est utile pour le routage inter-zones. Comme les nuds BORDER servent de relais entre les zones, ils possdent une table utilise pour le routage interzones. Cette table est galement construite en se basant sur lalgorithme Distance Vector. Chaque entre de cette table contient les informations de routage de la zone courante vers les autres zones. Nous avons dcrit aussi, dans ce chapitre, des algorithmes de maintenance des tables de routage (intra-zone et inter-zones) utiles lors dune dfaillance, dune apparition ou dun dplacement dun certain nud. Cette maintenance est base sur lenvoi priodique des paquets de contrle HELLO entre les nuds. Notre protocole de routage se distingue de la plupart des autres protocoles hirarchiques par les caractristiques suivantes : notre protocole est compltement distribu, lalgorithme de partitionnement du rseau en zones nexploite aucune information sur le rseau (position des nuds, niveau nergtique, etc.), le protocole sappuie sur lalgorithme Distance Vector qui est simple et non coteux pour la construction des tables de routage, adapt aux larges rseaux de capteurs,

88

Conclusion la maintenance des tables de routage seffectue par des envois priodiques de petits messages HELLO, ce qui est une amlioration de lalgorithme Distance Vector qui transmet rgulirement toute la table.

89

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Chapitre 4. Exprimentations et rsultats

4.1

Introduction

Dans ce chapitre, nous valuons le protocole de routage propos prcdemment. Une des caractristiques principales des rseaux de capteurs viss est la taille de ces rseaux. Le nombre important de capteurs ncessaires pour la couverture de lespace surveill et les principes du protocole de routage propos constituent les arguments pour lutilisation dun simulateur afin dvaluer notre proposition. Cependant, une analyse de fiabilit de limplmentation sur un systme rel sera galement prsente dans le dernier chapitre, dcline en deux types dapplications. Nous commencerons par une description du simulateur J-Sim que nous avons utilis pour tablir les simulations. Ensuite, nous montrerons les rsultats de simulations et valuerons notre protocole suivant quatre mtriques : le taux derreur, le surcot, la dure de vie du systme, lespace de stockage et la scalabilit. Nous dfinissons le taux derreur par le pourcentage de nuds isols restant sans affectation aucune zone. Le surcot sera valu par le nombre de messages de contrle envoys et reus durant lexcution du protocole. Une valuation du niveau nergtique de la batterie des nuds sera ralise galement. La dure de vie du systme sera calcule par rapport au nombre dvnements qui pourront tre effectus. Nous estimerons aussi lespace de stockage requis pour la structure de donnes utilise pour le routage (tables et attributs). Enfin, nous montrerons le bon comportement de notre protocole de routage dans des rseaux de grande taille, ce qui prouve sa scalabilit.

4.2

Le simulateur J-Sim

J-Sim [ (78), (79), (80)] est un logiciel utilis pour simuler le comportement des processus pseudoparallles. Dans J-Sim cest lutilisateur (programmeur) de crer la simulation. Le simulateur est programm en Java. Pour modifier le comportement du simulateur, il est ncessaire de complter ou de modifier ses fichiers sources. J-Sim repose sur une structure

91

Exprimentations et rsultats logicielle base sur des composants, appele Autonomous Component Architecture (ACA). Le code source est organis en paquetages relatifs un type de composants. Un composant est une entit indpendante reprsentant un objet physique (une batterie, un module radio, une couche logicielle, etc.) ou logique (un protocole de routage, un modle de mobilit, etc.). Ces composants seront ensuite connects laide de ports afin de gnrer un rseau simul. La simulation du fonctionnement dun rseau de capteurs, qui exige la dfinition des composants et leur mise en relation, est ralise grce un langage spcifique, TCL (81). Il sagit dun langage de script dans lequel on spcifie larchitecture du rseau ainsi que les paramtres de simulation et danalyse. Les commandes de script peuvent galement tre fournies en ligne de commande, instruction par instruction. A laide de TCL, on dfinit les composants puis on les connecte. Tous les composants sont hbergs dans un conteneur, qui est son tour un composant. La dfinition des composants est en fait la cration des objets. Cette cration est ralise par la commande TCL mkdir. Chaque composant est dune entit indpendante (la couche MAC par exemple) qui fonctionne indpendamment des autres entits. Les composants possdent des ports par dfaut pour quils puissent communiquer entre eux. Dautres ports peuvent tre crs pour un composant. Une connexion entre deux composants est ralise par lintermdiaire de deux ports ddis, un dans chaque composant (voir la Figure 4.1). Cette connexion est matrialise par la commande TCL connect. Il suffit de suivre un schma qui indique linterconnexion entre les diffrents types de composants que lon veut utiliser. On obtient ainsi larchitecture du nud. Toujours dans ce script TCL, on y dfinit les paramtres globaux (par exemple la taille du champ de simulation), les outils de visualisation des rsultats et lordonnancement de la simulation.
composant port

connexion

Figure 4.1 : Connexions entre composants dans J-Sim

On distingue trois types de nuds : target, sink et sensor. Les nuds target ont pour fonction de gnrer des signaux (stimuli) qui peuvent tre, par exemple, une secousse sismique, un bruit, etc. Le nud sink est quant lui le nud cible, celui o les informations doivent arriver. Le reste du rseau est form par les nuds sensor qui acheminent les paquets jusquau nud sink. Lorsquun nud target envoie un stimulus et quil est capt par un nud sensor, ce dernier cre un paquet contenant linformation de mesure pour la faire parvenir au nud sink via le rseau.
92

Le simulateur J-Sim La Figure 4.2 (partie en pointill) montre larchitecture interne dun nud sensor dans J-Sim. On y distingue notamment les composants CPU et Radio qui dfinissent les modles de la consommation nergtique du microcontrleur et de lantenne radio. Le composant CPU dcrit en principe le cot de traitement des instructions. Le composant Radio dcrit le cot de lenvoi et la rception des signaux et la mise en veille. Le composant Battery dfinit le modle de la batterie dun nud. Ce composant calcule la consommation nergtique due au traitement des instructions, envois et rceptions des signaux en se basant sur les modles du CPU et de Radio. Un programmeur peut facilement crer ses propres modles (CPU, Radio, Battery) et les insrer dans un scnario de simulation afin de les tester. A noter que seuls les nuds sensor sont dots dune batterie. La Figure 4.2 montre aussi que les composants des diffrentes couches dun nud sont spars (Network layer, Mac Layer, Physical Layer). Ils communiquent entre eux via des ports. Les connexions (dsignes par des flches) entre les composants peuvent tre unidirectionnelles ou bidirectionnelles. Une connexion unidirectionnelle dun composant C1 vers un composant C2 signifie que les informations peuvent tre envoyes dans une seule direction (de C1 C2). Dautre part, une connexion bidirectionnelle signifie un change dinformation dans les deux directions. Le composant Wireless Channel est le composant commun pour tous les nuds sensor du rseau. Il fait communiquer tous les nuds sensor entre eux. Chaque nud sensor du rseau doit avoir une connexion, ralise par le programmeur, avec ce composant. Le cas chant, le nud ne peut pas communiquer avec les autres nuds. Le composant Sensor Channel est responsable de la communication entre les nuds target et les nuds sensor. De mme, chaque nud (sensor ou target) doit avoir une connexion avec ce composant. Si, par exemple, un tel vnement est cr par un nud target, ce composant envoie linformation tous les nuds sensor qui entourent le target (la distribution des nuds et leurs positions dans le champ de simulation sont dfinies dans le fichier TCL). Notons quil existe plusieurs simulateurs dans la littrature tels que GlomoSim (82), OMNET++ (83), OPNET (84), NS-2 (85).

Figure 4.2 : Architecture interne dun noeud sensor dans J-Sim (78)

93

Exprimentations et rsultats

4.3

Larchitecture dtaille de J-Sim

4.3.1 Le composant
Lentit de base dans larchitecture logicielle de J-Sim est le composant. Nous dfinissons une application en ralisant une composition de composants. La notion des composants nest pas nouvelle et a t employe dans plusieurs normes composant telles que JavaBeans, CORBA et COM/DCOM/COM+. A la diffrence des JavaBeans, de CORBA, et de COM/DCOM, les composants dans J-Sim sont faiblement connects (loosely coupled). Ils communiquent entre eux en connectant leurs ports ensemble, et sont lis par des contrats. Les contrats indiquent la causalit des informations envoyes/reues entre les composants, mais nindiquent pas les composants qui participent la communication.

4.3.2 Le port
Un composant communique avec les autres composants par lintermdiaire de ses ports. Il peut possder plus dun port. Linterface de programmation entre un composant et son port est bien dfinie. Un composant peut tre dvelopp sans la prsence dautres composants (il se doit dtre autonome). En outre, le mcanisme rel de communication quun composant emploie pour communiquer avec le reste du monde est compltement cach par la notion de port.

4.3.3 Le contrat
La communication entre composants est dcrite par les contrats. Le contrat impose les conditions sur les ports dentre/sortie des composants afin de les faire communiquer. Un contrat indique comment un initiateur (visiteur) et un racteur (appel) accomplissent une certaine communication. Il dcrit comment un composant rpond aux donnes qui arrivent chacun de ses ports (par exemple, comment le composant traite les donnes, certaines structures de donnes de mises jour, et produit des sorties certains ports).

4.3.4 Langage utilis pour dfinir un scnario de simulation

Bien que J-Sim soit crit en Java, les scnarios de simulation ne sont pas dcrits en Java (car ce processus serait trop complexe). La combinaison des langages Java et TCL ne facilite pas cette tche. Pour dvelopper un grand projet, il peut devenir encombrant demployer des commandes TCL/Java parce que les rfrences des objets Java doivent tre stockes dans des variables TCL afin dy accder. Pour simplifier la syntaxe des simulations il existe un systme appel RUntime Virtual (RUV). Ce systme sappuie sur la similitude entre les systmes composants et les systmes de fichiers dUNIX. Lanalogie entre un composant/port et un chemin de fichier permet daccder au composant de la mme manire que lon accde un dossier dans un systme de fichiers.

94

Larchitecture dtaille de J-Sim Dailleurs des commandes systmes UNIX, telles que ls, cd, pwd, mkdir, cp, mv, et rm peuvent tre utilises pour manuvrer des composants et des ports dans le systme. Les ports ont une utilisation particulire pour le nommage : a@b (o a est le nom du port et b le groupe du port). En rsumant, des composants peuvent tre crs et ils peuvent tre lis grce une interface de commande qui utilise la syntaxe des invits de commandes (shells).

4.3.5 Modle de transmission dans J-Sim

Comme la plupart des simulateurs de rseau, J-Sim possde un modle propre de transmission. Lutilisateur peut tout moment implmenter son propre modle ou modifier celui de J-Sim. Dans J-Sim, le champ de simulation est divis en plusieurs sous-champs deux dimensions. Chaque souschamp est un rectangle de taille dx*dy (voir la Figure 4.3 ct gauche). Un nud dfinit sa porte de transmission comme suit : il peut communiquer seulement avec les nuds appartenant son sous-champ et avec ceux dans les sous-champs voisins. La Figure 4.3 (ct gauche) montre un nud A et ses nuds voisins quil peut atteindre en un seul saut. Il peut communiquer avec les nuds appartenant aux neuf sous-champs griss : le sous-champ o il appartient et les huit souschamps voisins au sien.

Figure 4.3 : Champs de voisinage dans J-Sim

Le rayon maximal de transmission, nomm Tr, est la distance maximale entre deux nuds communicants. Selon le modle de transmission de J-Sim, ce rayon est la diagonale du carr form par quatre sous-champs (voir la Figure 4.3, ct droit). Ainsi, ce rayon peut tre calcul en utilisant la formule T = 2(dx+dy).
r

Le ct droit de la Figure 4.3 dcrit le comportement de trois nuds communicants dans J-Sim en se basant sur le modle de transmission dcrit prcdemment. Le nud A ne peut pas communiquer avec le nud C qui nappartient aucun sous-champ des neuf en gris (porte de transmission de A) mme si la distance d entre eux est infrieure Tr. Cependant, le nud A peut communiquer avec le nud B qui appartient un des neuf sous-champs en gris. Ce modle de

95

Exprimentations et rsultats propagation est spcifique J-Sim, qui nutilise donc ni le modle thorique sphrique ni celui de voisinage qui en dcoule et est indpendant dune distance constante entre lmetteur et le rcepteur. Ceci peut traduire une simulation de lattnuation du signal cause des obstacles ou dautres facteurs (par exemple antenne unidirectionnelle). Dans nos simulations, nous avons modifi le code dimplmentation de J-Sim de faon avoir un rayon de transmission sphrique pour les nuds du rseau car la gestion des obstacles dans le simulateur J-Sim nest pas simple et les simulations se font gnralement dans les conditions idales.

4.4

Evaluation du protocole de routage propos

Dans J-Sim, un module ddi aux rseaux de capteurs est incorpor dans le paquetage

drcl.inet.sensorsim. On y retrouve les classes concernant les composants suivants : les nuds (sensor, target et sink), le canal des nuds sensor (sensor channel), le modle de propagation des
signaux radio (le canal radio, la couche physique, la couche Mac), le modle de batterie, le modle de CPU, le modle radio pour chaque nud et le protocole de routage. Nous utiliserons le simulateur J-Sim, afin dvaluer lefficacit du protocole de routage propos dans ce rapport. Quatre mtriques ont t prises en compte : le taux derreur, le surcot (overhead), lespace de stockage exig et la scalabilit. Le partitionnement du rseau en zones affecte les nuds une zone particulire. Idalement, chaque nud du rseau devrait tre membre dune zone. Suivant les paramtres du protocole et le dploiement des nuds dans le rseau, nous valuons lefficacit de notre protocole propos en termes de pourcentage des nuds non affects aucune zone (nuds isols), dfini comme le taux derreur. Une autre mtrique particulire dvaluation est le surcot gnr. Nous lestimons par le nombre de paquets envoys et reus et le niveau nergtique de la batterie (86). Une des mtriques dvaluation principales pour un protocole de routage dans un rseau de capteurs est lespace de stockage. Nous lvaluons par le nombre de bits occups par la structure de donnes intervenant dans les algorithmes (tables de routage et attributs). Les trois mtriques prcdentes dpendent de la taille du rseau. La scalabilit dun protocole de routage est une des caractristiques importantes pour un rseau de capteurs de grande taille. Pour cela, nous valuons aussi le comportement du protocole propos lors de la variation de la taille du rseau de capteurs. Les simulations ont t excutes dans un espace de 1500m*1500m. Le rayon maximal de transmission est de 150m. Dans nos simulations nous avons fait varier la taille du rseau de 400 600 nuds.

4.4.1 Evaluation du taux derreur

Cette valuation montre lefficacit de la phase de partitionnement du rseau en zones. Le but est de savoir combien de nuds du rseau restent sans affectation aucune zone. Pour cela, nous avons dfini le taux derreur comme le pourcentage des nuds non affects aucune zone (nuds isols) aprs le partitionnement du rseau. Il est valu en fonction de deux paramtres de lalgorithme : le rayon de la zone (R) et le nombre de zones (zN).

96

Evaluation du protocole de routage propos

14

12

10

Taux d'erreur (%)

R=5 R=10

R=15 R=20

R=25

0 5 10 15 20 25

Nombre de zones

Figure 4.4 : Taux derreur pour 400 nuds

Les figures (Figure 4.4, Figure 4.5, et Figure 4.6) montrent les taux derreur pour des rseaux constitus respectivement de 300, 400 et 600 nuds. Les graphes montrent que le taux derreur atteint zro sauf dans le cas o le rayon de la zone R a la valeur 5. Ceci sexplique par le fait quil y a des nuds dans le rseau qui nont pas reu un paquet dinvitation car le rayon R est petit.
4,5 4 3,5 3 2,5 2 1,5 1 0,5 0 5 10 15 20 25 R=5 R=10 R=15 R=20 R=25

Taux d'erreur (%)

Nombre de zones

Figure 4.5 : Taux derreur pour 500 nuds

97

Exprimentations et rsultats
3,5

2,5

Taux d'erreur (%)

R=5 R=10

1,5

R=15 R=20

R=25

0,5

0 5 10 15 20 25

Nombre de zones

Figure 4.6 : Taux derreur pour 600 noeuds

4.4.2 Evaluation du surcot

Dans cette sous-section nous prsentons le surcot d au partitionnement du rseau en zones et la construction des tables intra-zone et inter-zones. Comme nous lavons dj dfini, le surcot est valu par le nombre moyen de paquets de contrle reus et envoys durant lexcution des algorithmes (de partitionnement et de construction des tables). La moyenne est ralise sur le nombre de nuds du rseau. Nous prsenterons les graphes selon les deux phases : le partitionnement du rseau en zones et la construction des tables de routage.

a) Phase de partitionnement du rseau en zones

Figure 4.7, Figure 4.8 et Figure 4.9 montrent le nombre de paquets envoys par chaque nud du rseau durant la phase de partitionnement en zones pour 400, 500 et 600 nuds respectivement en fonction du nombre de zones et du rayon de la zone (R). Les figures montrent que le nombre de paquets envoys est faible et ne dpasse pas 16 paquets/nud dans le pire des cas (Figure 4.9, R = 25, nombre de zones = 25, N=600). Nous remarquons aussi que ce nombre augmente proportionnellement mais faiblement avec le nombre de zones, le rayon de la zone et le nombre de nuds ; ceci sexplique par le fait que laugmentation du nombre de nuds-invitant (nombre de zones) aboutit une augmentation du nombre de paquets dinvitation envoys. De mme, lorsque le rayon de la zone et le nombre de nuds sont plus grands, les paquets dinvitation sont rediffuss plus largement pour atteindre des nuds plus loigns du nud invitant.

98

Evaluation du protocole de routage propos

5,5
5

Nombre de paquets envoys

4,5 4 3,5 R=5 R=10

3
2,5 2 1,5 1 5 10 15 Nombre de zones 20 25

R=15
R=20 R=25

Figure 4.7 : Nombre de paquets envoys durant la phase de partitionnement en zones pour 400 nuds
6 5,5

Nombre de paquets envoys

5 4,5 4 3,5 3 2,5 5 10 15 Nombre de zones 20 25

R=5 R=10 R=15 R=20 R=25

Figure 4.8 : Nombre de paquets envoys durant la phase de partitionnement en zones pour 500 nuds

99

Exprimentations et rsultats
7,5 7
6,5

Nombre de paquets envoys

6 5,5 5 4,5 4 3,5

3

R=5 R=10 R=15 R=20 R=25

10

15 Nombre de zones

20

25

Figure 4.9 : Nombre de paquets envoys durant la phase de partitionnement en zones pour 600 nuds
16,00
15,00

Nombre de paquets reus

14,00 R=5 13,00 12,00 11,00 10,00 5 10 15 Nombre de zones 20 25 R=10 R=15 R=20 R=25

Figure 4.10 : Nombre de paquets reus durant la phase de partitionnement en zones pour 400 nuds

Les figures (Figure 4.10, Figure 4.11, et Figure 4.12) montrent le nombre de paquets reus par chaque nud du rseau durant la phase de partitionnement du rseau pour 400, 500 et 600 nuds respectivement. Ce nombre ne dpasse pas 24 paquets/nud dans le pire des cas (Figure 4.12, R = 25, nombre de zones = 25, N=600).
100

Evaluation du protocole de routage propos

19,5 19

Nombre de paquets reus

18,5 18 R=5 17,5 17 16,5 16 15,5 5 10 15 Nombre de zones 20 25 R=10 R=15 R=20 R=25

Figure 4.11 : Nombre de paquets reus durant la phase de partitionnement en zones pour 500 nuds
24 23,5 23

Nombre de paquets reus

22,5 22 21,5 21
20,5

R=5 R=10 R=15

R=20 R=25

20 19,5 19 5 10 15 Nombre de zones 20 25

Figure 4.12 : Nombre de paquets reus durant la phase de partitionnement en zones pour 600 nuds

La mme remarque que dans les graphes des paquets envoys peut tre extraite de ces trois figures : augmentation proportionnelle mais faible avec le nombre de zones, le rayon de la zone et le nombre de nuds. Ceci sexplique par le fait que laugmentation du nombre de nuds-invitant (nombre de zones) aboutit une augmentation du nombre de paquets dinvitation envoys dans le

101

Exprimentations et rsultats rseau, et par suite cela augmente le nombre de paquets reus. De mme, lorsque le rayon de la zone et le nombre de nuds sont plus grands, les paquets dinvitation sont rediffuss plus largement pour atteindre des nuds plus loigns du nud invitant. Ceci engendre laugmentation du nombre de paquets reus. Dailleurs si nous comparons les graphes des paquets envoys et ceux des paquets reus pour un mme nombre de nuds, nous remarquons que le nombre de messages reus ne dpasse pas quatre fois le nombre de ceux envoys. Ceci sexplique par le fait que les nuds, aprs laffectation la zone, rediffusent les paquets dinvitation ; les nuds voisins, qui sont dj affects la mme zone, reoivent ces paquets mais ne rpondent pas et ne rediffusent pas ces paquets. Donc ils reoivent plus de paquets quils en envoient. Le cot nergtique qui en dcoule est moins pnalisant que dans le cas dun nombre denvois suprieur au nombre de rceptions, car le cot denvoi dun paquet est gnralement plus coteux (3 4 fois) que le cot de rception pour un capteur. En conclusion, les graphes de simulations montrent clairement que lalgorithme de partitionnement gnre un faible surcot. Ceci est d au nombre faible des paquets de contrle envoys et reus afin de raliser le partitionnement du rseau en zones. Ce faible surcot engendre aussi une faible consommation nergtique de la batterie.

b) Phase de construction des tables de routage

Dans cette sous-section, nous valuerons le surcot d la construction des tables de routage intra-zone et inter-zones dans les nuds aprs la phase de partitionnement du rseau en zones. Les rseaux utiliss dans nos simulations sont composs de 400, 500 et 600 nuds. Ils ont la mme distribution de nuds lors de la phase de partitionnement dont nous avons montr les rsultats dans la sous-section prcdente. Les figures (Figure 4.13, Figure 4.14, et Figure 4.15) montrent le nombre de paquets envoys par chaque nud du rseau durant la phase de construction des tables de routage pour 400, 500 et 600 nuds respectivement en fonction du nombre de zones et du nombre de nuds. Nous remarquons que les courbes, dans les trois figures, sont quasiment confondues lorsque le nombre de zones est fixe et le rayon de la zone (R) varie. Ceci sexplique par le fait que lorsque le le nombre de zones est fixe, les zones ont presque la mme taille (en termes de nombre de nuds). De ce fait, les tables de routage ont presque la mme taille et exigent presque le mme nombre de paquets de contrle (envoys dans ces figures) pour la construction des tables de routage. Nous remarquons aussi, dans ces figures, que la moyenne augmente proportionnellement mais faiblement avec le nombre de zones et le rayon de la zone (R) mais elle ne dpasse pas 50 paquets/nud. Cette augmentation faible est due au fait que la taille de la zone est inversement proportionnelle avec le nombre de zones et proportionnelle avec le rayon de la zone (R). Ainsi ce sont deux paramtres de lalgorithme qui samortissent dans cette phase. Et puisque la taille des tables de zones dpend de la taille de la zone, alors le nombre de paquets envoyer pour la construction de ces tables dpend de la taille de la zone.

102

Evaluation du protocole de routage propos

50

Nombre de paquets envoys

45

40

R=5 R=10

35

R=15 R=20

30

R=25

25 5 10 15 Nombre de zones 20 25

Figure 4.13 : Nombre de paquets envoys durant la phase de construction des tables de routage pour 400 nuds

51 49 47

Nombre de paquets envoys

45 R=5 43 41 39 37 35 5 10 15 Nombre de zones 20 25 R=10 R=15 R=20 R=25

Figure 4.14 : Nombre de paquets envoys durant la phase de construction des tables de routage pour 500 nuds

103

Exprimentations et rsultats
49

48

47
Nombre de paquets envoys

46 R=5 45
R=10

R=15 44 R=20 R=25 43

42

41

10

15 Nombre de zones

20

25

Figure 4.15 : Nombre de paquets envoys durant la phase de construction des tables de routage pour 600 nuds

Les figures (Figure 4.16, Figure 4.17 et Figure 4.18) montrent le nombre de paquets reus par nud durant la phase de construction des tables de routage intra-zone et inter-zones pour 400, 500 et 600 nuds respectivement en fonction du nombre de zones et du rayon de la zone (R). Depuis ces figures, la mme remarque que dans les graphes des paquets envoys peut tre extraite : les courbes, dans les trois figures, sont quasiment confondues lorsque le nombre de zones est fixe et le rayon de la zone (R) varie. Ceci sexplique aussi par le fait que lorsque le nombre de zones est fixe, les zones ont presque la mme taille. De ce fait, les tables de routage ont presque la mme taille et exigent presque le mme nombre de paquets de contrle (reus dans ces figures) pour la construction des tables de routage. Dans ces trois figures et pour les diffrentes valeurs du rayon de la zone (R), nous remarquons aussi que les courbes dcroisent rapidement lorsque le nombre de zones est petit (5 10) et augmentent lentement lorsque le nombre de zones est suprieur 15. La dcroissance rapide des courbes sexplique par le fait que lorsque le nombre de zones augmente, le nombre de nuds dans chaque zone diminue car le nombre de nuds est fixe. Par consquent, les nuds dune zone auront besoin de moins dchanges de paquets de contrle pour construire les tables de routage et notamment la table intra-zone. Dans le cas o le nombre de zones est faible (5 10), le nombre de paquets de contrle pour construire la table inter-zones est petit par rapport celui pour la construction les tables intra-zones car la table inter-zones est de petite taille. Dailleurs, lorsque le nombre de zones devient plus important (suprieur 15), la construction de la table inter-zones induit un surcot plus lev quavant mme si celui-ci reste raisonnable. Ce surcot explique la croissance faible des courbes lorsque le nombre de zones est suprieur 15.

104

Evaluation du protocole de routage propos

110 105

Nombre de paquets reus

100 95 90 85 80 75 70 65 60 5 10 15 Nombre de zones 20 25 R=5 R=10 R=15 R=20 R=25

Figure 4.16 : Nombre de paquets reus durant la phase de construction des tables de routage pour 400 nuds
125

120 115
Nombre de paquets reus

110 105 100 95 90 85 80 5 10 15 Nombre de zones 20 25 R=5 R=10 R=15 R=20 R=25

Figure 4.17 : Nombre de paquets reus durant la phase de construction des tables de routage pour 500 nuds

105

Exprimentations et rsultats
155

145

Nombre de paquets reus

135 R=5
125

R=10 R=15

115

R=20 R=25

105

95 5 10 15 Nombre de zones 20 25

Figure 4.18 : Nombre de paquets reus durant la phase de construction des tables de routage pour 600 nuds

En conclusion, les graphes de simulations montrent le faible surcot durant la phase de construction des tables de routage. En fait, cette phase dpend directement de la taille des zones qui influe la taille des tables de routage. Ainsi, le nombre de paquets de contrle pour la construction de ces tables dpend de la taille des zones. Les graphes montrent bien que les deux paramtres de lalgorithme, le nombre de zones (zN) et le rayon de la zone (R), samortissent concernant la taille des zones. Ce qui aboutit un faible surcot.

c) Consommation de la batterie
Consommation CPU Consommation rception radio Consommation transmission radio Energie initiale de la batterie Voltage Taux de transfert de donnes Porte de communication 8 mAh 10 mAh 27 mAh 2900 mAh 3V 38400 bits/s 500 ft

Tableau 9 : Caractristiques dun capteur MICA2

106

Evaluation du protocole de routage propos En se basant sur le modle nergtique des capteurs MICA2 (23), nous avons calcul la consommation nergtique de la batterie. Les caractristiques dun capteur MICA2 sont illustres dans le Tableau 9. Nous avons fait varier le nombre de nuds de 400 600 et avons pris les valeurs intermdiaires du nombre de zones et du rayon de la zone (10, 15 et 20).
3,44E-04

Consommation de la batterie (%)

3,24E-04
3,04E-04

2,84E-04
2,64E-04 2,44E-04

R=10, zN=15
R=15, zN=15 R=20, zN=15

2,24E-04
400 500 600

Nombre de noeuds - N

Figure 4.19 : Pourcentage de la consommation nergtique de la batterie en variant le rayon de la zone R

La Figure 4.19 montre le pourcentage de la consommation nergtique de la batterie dun capteur MICA2 en fonction du rayon de la zone et du nombre de nuds dans le rseau durant lexcution du protocole de routage propos en fixant le nombre de zones 15. De mme, la Figure 4.20 montre ce pourcentage en fonction du nombre de zones et du nombre de nuds dans le rseau en fixant le rayon de la zone 15.
3,64E-04

Consommation de la batterie (%)

3,44E-04 3,24E-04 3,04E-04 2,84E-04 2,64E-04 2,44E-04

R=15, zN = 10
R=15, zN = 15 R=15, zN = 20

2,24E-04
400 500 Nombre de noeuds - N 600

Figure 4.20 : Pourcentage de la consommation nergtique de la batterie en variant le nombre de zones zN

Ces deux figures montrent clairement la faible consommation nergtique du protocole. Elle ne dpasse pas le 3,5*10-4 % de la batterie dans le pire des cas (600 nuds) dans les deux figures.
107

Exprimentations et rsultats En conclusion, nous pouvons remarquer que le nombre de paquets reus est plus important que celui des paquets envoys. Cette diffrence est due principalement au modle de communication utilis dans les rseaux de capteurs : un paquet envoy par un nud peut tre reu par plusieurs nuds dans sa porte de communication. Comme nous lavons dit, cette diffrence nest pas gnante car le cot nergtique denvoi dun paquet est gnralement plus important (trois quatre fois) que celui de la rception dans les rseaux sans fil. Lensemble des graphes dcrits dans cette section montre lefficacit nergtique de notre protocole.

4.4.3 Evaluation de la dure de vie

Dans le but de montrer lefficacit nergtique du protocole ZHRP durant le routage des donnes, nous avons effectu des simulations dchange de donnes entre les diffrents nuds du rseau. Les simulations ont t excutes dans un espace de 300m*300m, le rayon maximal de transmission est gal 50m, le nombre de nuds N est gal 100, le nombre de zones zN est gal 5, le rayon de la zone R est gal 5. La simulation a t ralise durant 6 minutes. Le nombre dvnements a vari de 5 12 chaque 60 ms (voir le Tableau 10). Un vnement est un envoi dun paquet de donnes dun certain nud un autre nud, les deux tant choisis dune manire alatoire. A noter que nous navons pas pu aller plus loin dans les simulations cause du simulateur J-Sim (bas sur Java) qui exigeait des ressources puissantes (mmoire, CPU, ets.) pour des simulations grande chelle.
Evnements chaque 60 ms Evnements durant 6 minutes 5 6 7 8 9 10 11 12

30000 36000 42000 48000 54000 60000 66000 72000

Tableau 10 : Nombre d'vnements durant la simulation

Consommation CPU Consommation rception radio Consommation transmission radio Energie initiale de la batterie Voltage Taux de transfert de donnes Porte de communication

1,5 mAh 23 mAh 21 mAh 2900 mAh 3V 250000 bits/s 50 m

Tableau 11 : Caractristiques dun capteur Tmote SKY

En se basant sur le modle nergtique des capteurs Tmote SKY (87) illustr dans le Tableau 11,

108

Evaluation du protocole de routage propos nous avons calcul la moyenne de la consommation nergtique par chaque nud du rseau.
Consommation de la batterie (%) 4,0E-03 3,5E-03 3,0E-03 2,5E-03 2,0E-03 1,5E-03 1,0E-03 5,0E-04 0,0E+00 30000 36000 42000 48000 54000 60000 66000 72000 Nombre d'vnements durant 6 minutes

Figure 4.21 : Pourcentage de la consommation nergtique de la batterie

Les fgures (Figure 4.21 et Figure 4.22) montrent les rsultats des simulations. Dans la Figure 4.21, le pourcentage de la consommation de la batterie ne dpasse pas 4*10-3 % de lnergie initiale de la batterie dun nud lorsquon atteint le maximum denvois (72000 vnements durant 6 minutes). Ceci prouve lefficacit nergtique du protocole ZHRP durant le routage de donnes. Dautre part, la Figure 4.22 montre la dure de vie du systme en nombre de jours en effectuant des vnements priodiques chaque 6 minutes. La dure de vie du systme est dfinie par la mort du premier nud dans le rseau. Cette figure montre le systme peut durer longtemps en utilisant le protocole ZHRP malgr le grand nombre dchange de donnes.
300

Dure de vie du systme (jours)

250
200 150

100
50 0 30000 36000 42000 48000 54000 60000 66000 72000

Nombre d'vnements chaque 6 minutes

Figure 4.22 : Dure de vie du systme avec des vnements priodiques

109

Exprimentations et rsultats

4.4.4 Evaluation de la taille de lespace de stockage

Un des points critiques dans le fonctionnement dun rseau de capteurs concerne lespace de stockage ncessaire la fois pour le systme dexploitation et pour le stockage ventuel des donnes rcoltes. Nous nous sommes intresss, pour la premire fois dans la littrature notre connaissance, la taille exige par les structures de donnes intervenant dans le protocole de routage. Cette mtrique traduit une complexit espace pour les algorithmes drouls dans un capteur. Une estimation thorique de la taille de lespace est montre dans le Tableau 12, en fonction du nombre de nuds dans le rseau N, du nombre de zones zN, et du nombre de nuds BORDER dans le rseau nB. La structure utilise est de type short dont la taille est 2 octets. Cet espace est allou principalement par les attributs dun nud qui dfinissent son identification global, son type, sa zone, le rayon de la zone, les tables de routage intra-zone, les tables inter-zones et les tables-frontires. Dans la phase de partitionnement en zones, un nud NORMAL possde quatre attributs de type short : NodeId, ZoneId, NodeType, et R (rayon de la zone). Les nuds BORDER possdent en plus la table BorderTable. Cette table est implmente comme un vecteur de taille estime (nB/zN)*6 short. La valeur nB/zN est la moyenne du nombre de nuds BORDER dans une zone. Dautre part, tous les nuds du rseau possdent lattribut ZoneM (mtrique de la zone) et une table de routage intra-zone. La taille estime pour cette table qui possde six champs de type short dpend du nombre de nuds dans le rseau N et du nombre de zones zN. Les nuds BORDER possdent en plus la table de routage inter-zones qui a trois champs de type short dont les tailles sont dpendantes de N et zN.

Partitionnement en zones Nud NORMAL Nud BORDER 4*2 (4+6*(nB/zN))*2

Construction des tables de routage 1 + 6 2

( + + ) 2

Tableau 12 : Taille thorique de lespace de stockage (en octets) de la structure de donnes de routage

Nous avons galement valu exprimentalement la taille de lespace de stockage demand pour la structure de donnes utilise pour le routage. Le rsultat illustr dans le Tableau 13 est donn pour un rseau de 600 nuds (N), R = 15 et zN=15. Ce rsultat dexprimentation confirme lestimation donne dans le cas gnral. Une moyenne de 4 Kb par nud est ncessaire pour stocker les informations de donnes pour le routage. Cette capacit reprsente 15 % de la mmoire totale dun capteur MICA2.

110

Evaluation du protocole de routage propos

Partitionnement en zones Nud NORMAL Nud BORDER Construction des tables de routage 480 572 Taille totale de lespace de stockage 488 octets = 3,82 Kb 604 octets = 4,71 Kb

8 32

Tableau 13 : Taille exprimentale de lespace de stockage (en octets) pour la structure de donnes de routage dans un rseau de 600 nuds

4.4.5 Evaluation de la scalabilit

La scalabilit dun protocole de routage est son aptitude conserver ses proprits fonctionnelles malgr le changement en taille du rseau. Les rsultats illustrs dans les sous-sections prcdentes (taux derreur, surcot et complexit de stockage) montrent la scalabilit de notre protocole de routage car nous remarquons que les graphes sont quasiment stables et ne gnrent pas un cart entre les rsultats quand la taille du rseau varie entre 400 et 600 nuds. En ce qui concerne les taux derreur, nous avons vu que le taux derreur atteint zro dans la plupart des cas. Dans le rseau le plus large (600 nuds) le protocole est trs efficace. Dautre part, le nombre de messages de contrle (surcot) dans un rseau large (600 nuds) est trs raisonnable et ne montre pas un cart surprenant avec un petit ou un moyen rseau (400 et 500 nuds). Ceci est montr clairement dans les figures du pourcentage de la consommation nergtique de la batterie (Figure 4.19 et Figure 4.20) ; la consommation nergtique du protocole de routage dans un rseau de 600 nuds est raisonnable et ne sloigne pas beaucoup des valeurs de consommation des rseaux composs de 400 et 500 nuds. Si nous regardons les quations des estimations gnrales de lespace de stockage, surtout celles de la construction des tables de routage, on voit quelles dpendent linairement du nombre de nuds. Et par suite, laugmentation du nombre de nuds ninflue pas fortement sur la taille de lespace de stockage. Notons que nous ne pouvions pas simuler un rseau compos de plus de 600 nuds avec le simulateur J-Sim et les ressources matrielles que nous possdons. Ces simulations (partitionnement et construction des tables des zones) du protocole sarrtaient cause dun bug de mmoire insuffisante produit par la machine virtuelle Java. Dailleurs, nous avons russi simuler la phase de partitionnement du rseau en zones pour 800 nuds. A titre dexemple, la Figure 4.23 montre le partitionnement dun rseau de 800 nuds en 10 zones avec R = 10. Dans cet exemple, nous avons simul les obstacles (J-Sim original). Nous remarquons quil ny a que 3 nuds non affects une zone. Ceci sexplique par le fait quils nont pas reu de paquets dinvitation cause des obstacles ou de la petite valeur du rayon de la zone R.

111

Exprimentations et rsultats

Figure 4.23 : Partitionnement dun rseau de 800 nuds en 10 zones

4.5

Conclusion

Dans ce chapitre, nous avons dcrit brivement le simulateur J-Sim utilis pour valuer le protocole de routage propos dans ce document. J-Sim est programm en Java. Le langage TCL est utilis pour crire des scnarios de simulation en utilisant un systme appel RUV. Ensuite, nous avons montr lefficacit du protocole de routage suivant les mtriques suivantes : taux derreur, le surcot, lespace de stockage et la scalabilit. Les rsultats de simulations ont montr un taux derreur qui est voisin de zro. Dautre part, une consommation nergtique trs faible a t montre par les rsultats pour un rseau de capteurs MICA2. Ceci est d au faible surcot du protocole. Nous avons galement montr lefficacit du protocole durant le routage de donnes, ce qui prolonge la vie du systme. Nous avons aussi estim lespace de stockage requis pour la structure de donnes du protocole. Cet espace est faible et ne reprsente que 15% de la mmoire dun capteur MICA2. Pour terminer, nous avons montr la scalabilit du protocole en se basant sur des simulations faites pour des rseaux de taille importantes.

112

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Chapitre 5. Mise en uvre du protocole de routage

5.1

Introduction

Le rle dun systme dexploitation est de permettre le dveloppement fiable dapplications en fournissant une abstraction commode et sre des ressources matrielles. Dans les PCs et les serveurs, le systme dexploitation permet lapplication de traiter les tches sur les processeurs, dresse la carte dadresses virtuelles des emplacements dans la mmoire, manipule les disques, gre les rseaux et les priphriques. La sparation entre systme dexploitation et applications dans le calcul conventionnel est moins flagrant dans le monde des systmes embarqus, o les applications utilisent ncessairement du matriel particulier. De plus, les ressources matrielles sont trs contraintes. Les rseaux de capteurs sans fil (WSNs) doivent supporter une varit dapplications utilisant des composants htrognes et capables de se dployer rapidement dans de nouveaux environnements. La gestion de rseaux sans fil exige un traitement simultan plus important que les rseaux cbls. Lorsquun nud WSN effectue son acquisition de donnes normale, il doit aussi effectuer des vnements de routage et des transferts de paquet qui surgissent dune manire asynchrone dans le rseau. Dans ce chapitre, nous prsenterons tout dabord brivement deux plateformes dexploitation pour les capteurs. Ensuite, nous dcrirons la mise en place dun systme rseau de capteurs bas sur notre proposition de routage. Nous montrerons aussi le fonctionnement du systme lors de lacquisition de donnes. Enfin, nous dtaillerons deux applications relles pour montrer lutilit de notre protocole.

113

Mise en uvre du protocole de routage

5.2

Plateformes dexploitation pour les capteurs

5.2.1 TinyOS
TinyOS (88) est un systme dexploitation intgr, modulaire, destin aux rseaux de capteurs. Cette plate-forme logicielle open-source est compose dune srie doutils dvelopps par lUniversit de Berkeley. En effet, TinyOS est le plus rpandu des OS (Operating System) pour les rseaux de capteurs sans fil (89). Il est utilis dans les plus grands projets de recherche sur le sujet. Un grand nombre de ces groupes de recherche ou entreprises participent activement au dveloppement de cet OS en fournissant de nouveaux modules, de nouvelles applications, etc. La librairie TinyOS comprend les protocoles rseaux, les services de distribution, les drivers pour capteurs et les outils dacquisition de donnes (90). Le systme TinyOS, ses librairies et ses applications sont crits en nesC (91), un nouveau langage pour le dveloppement dapplications orientes composants. Le langage nesC est principalement ddi aux systmes embarqus comme les rseaux de capteurs. NesC a une syntaxe proche du langage C mais supporte le modle concurrent de TinyOS ainsi que des mcanismes pour la structuration, le nommage et lassemblage de composants logiciels en des systmes rseaux embarqus fiables. Lobjectif principal est de permettre aux concepteurs dapplications de construire des composants qui peuvent tre composs rapidement en des systmes complets, concurrents, tout en permettant une vrification profonde la compilation (91). TinyOS dfinit un nombre important de concepts qui sont exprims dans nesC. Premirement, les applications nesC sont construites partir de composants ayant des interfaces bidirectionnelles bien dfinies. Deuximement, nesC dfinit un modle de concurrence bas sur les notions de tches, les "handlers" dvnements matriels, et la dtection des conditions daccs concurrent aux donnes au moment de la compilation.

5.2.2 SPOT (Small Programmable Object Technology)

SUN Miscrosystems a ralis une plateforme logicielle et matrielle homogne, appele SPOT ( (92), (93)), qui permet de programmer des capteurs en Java. SPOT est lassemblage dune carte avec le processeur central, une carte rassemblant les diffrents capteurs ou une station dmission de base, un socle pour accueillir les batteries, et une coque pour contenir le tout (voir la Figure 5.1). Cette plateforme comprend une machine virtuelle Java adapte aux capteurs ainsi que des outils de dveloppement et de dbogage. SPOT permet aux dveloppeurs de concevoir des applications pour les capteurs directement en Java, donc de ne plus utiliser un langage de bas niveau complexe comme nesC.

114

Plateformes dexploitation pour les capteurs

Figure 5.1 : Capteur SPOT fabriqu par SUN Microsystems (94)

SPOT utilise une machine virtuelle de type J2ME mais de taille rduite appel Squawk Virtual Machine (95) crite en Java. Lavantage de Squawk VM est sa capacit utiliser de manire plus performante le peu despace mmoire que possdent les capteurs. Cette machine virtuelle fonctionne sans OS et permet une communication directe avec lunit de traitement (CPU), ce qui augmente les performances des applications (96).

5.3

Description et mise en place du systme

Dans la suite de cette section, nous dcrirons lutilit et le fonctionnement de notre systme bas sur le protocole ZHRP. Nous dcoupons cette opration en plusieurs tapes.

5.3.1 Premire tape : injection du protocole dans le capteur

Cette premire tape consiste injecter le protocole de routage dans le capteur. Comme nous lavons dit prcdemment, chaque capteur possde un systme dexploitation pour grer les ressources matrielles. Ce systme doit tre open-source afin que nous puissions modifier le code source ou y intgrer notre propre implmentation. En utilisant les capteurs MICA2 fabriqus par Crossbow, le protocole de routage doit tre cod en langage nesC afin de linjecter dans ce genre de capteurs possdant le systme dexploitation TinyOs. NesC est un langage orient composant, conu pour incarner les concepts de structuration et dexcution du systme TinyOS. Il propose une architecture base sur des composants, permettant de rduire la taille mmoire du systme TinyOS et de ses applications. Un composant peut tre un concept abstrait ou un lment matriel tel que des LEDs ou un timer, il peut tre rutilis dans diffrentes applications. Ces applications sont des ensembles de composants associs entre eux dans un but prcis. En nesC, les composants prsentent des similarits avec des objets. Les tats sont encapsuls et on peut y accder par des interfaces. Limplmentation des composants est ralise par la dclaration des tches, des commandes ou des vnements. En outre, lensemble des composants et leurs interactions sont fixs la compilation ce qui permet doptimiser lapplication pour une excution plus performante. NesC permet de dclarer deux types de fichiers : les configurations et les modules. Le fichier configuration est la dfinition du ou des composants

115

Mise en uvre du protocole de routage qui seront utiliss par lapplication dploye sur le capteur. Les modules constituent les briques lmentaires du code et implmentent une ou plusieurs interfaces. Les interfaces spcifient un ensemble de fonctions mettre en application par le fournisseur de linterface (commandes) et par lutilisateur de linterface (vnements). Ceci permet une interface simple de reprsenter une interaction complexe entre les composants (par exemple, enregistrement dun vnement pertinent, suivi dun rappel de service quand cet vnement se produit). En outre, les interfaces permettent de lier statiquement les composants entre eux. Ceci augmente lefficacit dexcution, favorise la robustesse de lapplication, et permet une meilleure analyse statique du programme de lapplication. TinyOS est prvu pour fonctionner sur diverses plateformes. En effet, TinyOS peut aussi bien tre install sur Windows, Linux, Mac OS ou sur un capteur. Cependant il nest pas possible de faire des allocations dynamiques ni utiliser des pointeurs. Linstallation du protocole de routage ncessite la mise en place de TinyOS et du langage nesC. Pour cela il faut installer : MoteWorks qui est un ensemble de logiciels permettant de dvelopper facilement des programmes pour les capteurs sous Windows, MoteView qui est un logiciel permettant de visualiser et analyser les donnes envoyes par les capteurs, Cygwin qui permet lmulation dun systme Unix sous Windows (inclus dans MoteWorks). TinyOS 2.x inclut un outil de liaison entre les nuds et une application Java : SerialForwarder (voir la Figure 5.2 ). Celui-ci rcupre les messages reus par le nud et les transmet lapplication Java. Linverse est aussi possible, lapplication Java peut envoyer des messages au nud, par exemple le Sink, qui va les transmettre aux autres nuds.

Figure 5.2 : Capture dcran de loutil SerialForwarder

116

Description et mise en place du systme Une fois le systme dexploitation et les outils ncessaires installs sur les capteurs, le protocole de routage peut y tre inject facilement. Nous aurions pu utiliser la plateforme SPOT car il est tout fait possible dy intgrer notre implmentation puisquelle est code en Java. Le choix des types de capteur dpend de lapplication vise.

5.3.2 Deuxime tape : dploiement des capteurs

La deuxime tape dans la mise en place dun tel systme de rseau de capteurs est le dploiement des nuds ou linstallation matrielle. Selon lapplication vise de ce systme, le dploiement aura lieu dune manire alatoire ou organise. Certaines applications exigent une distribution des nuds dune manire prcise. Les nuds doivent tre dploys dans des positions pralablement dtermines pour le bon fonctionnement du systme car lapplication dpend de leurs positions. Nous citons quelques applications : surveillance mdicale dun patient domicile, surveillance des routes, surveillance de fonctionnement des machines industrielles, etc. Dautres applications nexigent pas une distribution prcise des nuds du rseau. Cest le cas des applications o nous pouvons dployer les nuds de capteurs alatoirement. Ceci est d aux difficults (gographiques, climatiques, etc.) dans lenvironnement surveiller. Nous citons quelques applications : surveillance militaire de la zone de lennemie, surveillance des forts contre le feu, etc. Dautre part, un rseau de capteurs peut contenir des centaines, voire des milliers, de nuds selon lapplication. Ainsi, la gestion (routage, panne, etc.) du rseau devient plus difficile. Do lide de partitionner virtuellement le rseau en zones. Le but est de minimiser le surcot et la taille des informations stockes dans chaque nud du rseau et par suite prolonger la vie du systme. Notre protocole de routage est utile et efficace dans les rseaux de capteurs de taille importante. Il ny a pas de contraintes sur le dploiement des nuds (alatoire ou organis). Une fois les nuds dploys, ltape de partitionnement du rseau en zones peut dmarrer.

5.3.3 Troisime tape : partitionnement du rseau en zones

Dans notre systme, nous dsignons quelques nuds pour lancer lalgorithme distribu de partitionnement. Ces nuds, appels nuds-invitant, dfinissent initialement les zones. A un temps donn t, chaque nud-invitant envoie un paquet dinvitation ses nuds voisins afin quils joignent sa zone. Les nuds qui reoivent ces paquets dinvitation saffectent une zone et rediffusent le paquet leurs voisins. Ainsi, les paquets se propagent dans le rseau (voir la Figure 5.3). Les nuds qui sont aux frontires des zones (les nuds BORDER) possdent des informations concernant les autres nuds BORDER dans les zones voisines. Ces informations sont stockes dans une table afin de lutiliser dans ltape de construction des tables de routage inter-zones.

117

Mise en uvre du protocole de routage

Figure 5.3 : Propagation des paquets dinvitation dans le rseau

A la fin de cette tape, chaque nud devrait tre affect une certaine zone. En consquence, le rseau devient virtuellement partitionn en plusieurs zones, se constituant en une structure hirarchique deux niveaux. Une fois le rseau stabilis, ltape suivante, de construction des tables de routage aura lieu. La stabilit du rseau est atteinte lorsquil ny a plus de paquets de contrle changs pour le partitionnement en zones. Dans un simulateur, il est facile de prciser le point de stabilit et de connatre le temps requis pour finir une tape. Cependant, pour une application relle, ce dlai ne peut pas tre prvu ; pour cette raison, nous donnons lalgorithme de partitionnement en excution une marge de temps suffisante avant de passer ltape suivante.

5.3.4 Quatrime tape : construction des tables de routage intra-zone

Dans cette tape, les nuds, dans chaque zone, changent des paquets de contrle entre eux afin de construire des tables de routage intra-zone. Cette table servira au routage entre des nuds qui appartiennent la mme zone. Cette tape commence sexcuter aprs ltape de partitionnement du rseau en zones. Chaque nud dans une zone possdera la fin une table de routage intra-zone qui contient des informations utiles pour router un paquet dun nud un autre de la mme zone. Cette tape, comme ltape prcdente, sarrte lorsque le rseau atteint le point de stabilit, cest-dire lorsquil ny a plus dchanges de paquets de contrle pour la construction de ces tables. Ce point peut tre galement estim dans la simulation et utilis rellement.

5.3.5 Cinquime tape : construction des tables de routage inter-zones

Durant cette tape, les tables inter-zones sont construites en se basant sur les informations stockes chez les nuds BORDER pour le partitionnement du rseau en zones. Cette table interzones sert router les paquets de donnes entre les zones du rseau. A la fin de cette tape, le

118

Description et mise en place du systme systme sera oprationnel. Chaque nud du rseau possde un tableau de routage intra-zone qui aide router les paquets de donnes lintrieur des zones. Les nuds BORDER possdent de plus une table de routage inter-zones qui permet de router les paquets de donnes entre les zones. Par la suite, nous dcrirons le fonctionnement de notre systme lors de lenvoi et de la rception des donnes entre les nuds du rseau.

5.4

Fonctionnement du systme

Avant de dcrire le fonctionnement du systme, nous dcrirons deux types dchanges de donnes utiliss gnralement entre les nuds dun rseau de capteurs : change entre les diffrents nuds dans le rseau o les capteurs communiquent entre eux les informations collectes. Ces communications seffectuent en multi-sauts entre le nud metteur et le nud destinataire.

Capteur
Figure 5.4 : Echange de donnes entre les nuds du rseau

envoi des informations collectes la station de base (ou Sink) qui est le centre de collecte de donnes (voir la Figure 5.5). La station de base est gnralement une machine puissante en ressources (alimentation, mmoire, etc.) et peut tre mobile. Les nuds qui collectent des informations de lenvironnement surveill envoient les donnes la station de base directement ou via dautres nuds ; cela dpend de la position de la station de base si elle est loin ou pas du champ surveill o se trouvent les capteurs. De la mme manire, la station de base peut envoyer ventuellement des requtes aux nuds du rseau.

119

Mise en uvre du protocole de routage

Station de base

Capteur
Figure 5.5 : Collecte des informations et envoi la station de base

Dans la suite, nous dcrirons comment les nuds ragissent lors de lchange de donnes entre eux dans les deux types dchanges de donnes dcrits prcdemment.

5.4.1 Echange de donnes sans station de base

Dans la premire politique dchange de donnes o nous navons pas une station de base identifie, les nuds changent les donnes entre eux. Nous avons deux cas : le nud metteur connat ou ne connat pas lidentification (ID et zone) du nud destinataire. En effet, la connaissance de lidentification dpend de lapplication vise, du systme surtout si le dploiement des nuds est ralis manuellement. Nous dtaillerons ces deux cas par la suite. Pour simplifier et viter la rptition, nommons le nud metteur E et le nud destinataire D. Dans le premier cas o le nud E ne dispose pas de lidentification du nud D, E collecte des donnes de lenvironnement et diffuse un paquet, contenant son identification (son ID et sa zone) et des mtadonnes dcrivant le type de donnes collectes dans le rseau pour savoir sil y a des nuds intresss par ces donnes collectes. Le nud intress D rpond au nud E par un paquet contenant son identification ; D utilise sa table de routage intra-zone afin de router le paquet de rponse. Si le nud E appartient la mme zone que D, un routage lintrieur de la zone aura lieu : D envoie le paquet au nud NextHop pour atteindre E ; de mme, le paquet est transfr entre les nuds intermdiaires afin datteindre E. Dautre part, si le nud intress D nappartient pas la mme zone que E, il envoie le paquet un nud BORDER qui est voisin de la zone de E (information extraite de la table intra-zone) ou nimporte quel nud BORDER sil ny en a pas un qui est voisin de la zone de E. Ainsi, le paquet sera transfr en utilisant la table inter-zones chez les nuds BORDER pour atteindre la zone de E et par suite atteindre le nud E en routage intrazone. De cette manire, les deux nuds E et D connaissent lidentification de lun et de lautre. Ainsi, le routage a lieu en utilisant les tables de routage intra-zone et inter-zones. Dans le deuxime cas, nous supposons que le nud metteur E connat pralablement lidentification du nud D. Le routage est le mme que dans le premier cas sans que le nud E diffuse un paquet de mtadonnes au dbut. La connaissance de lidentification des nuds

120

Fonctionnement du systme destinataires peut tre dfinie durant la mise en place du systme. Par exemple, nous pouvons dsigner des nuds du rseau appels nuds destinataires vers lesquels les donnes sont achemines surtout si le dploiement des nuds est non alatoire, donc nous connaissons leur emplacement.

5.4.2 Echange de donnes avec station de base

Dans cette politique dchange, nous supposons quil existe une station de base (Sink) vers laquelle toutes les donnes collectes de lenvironnement doivent tre envoyes. Donc, le Sink est le destinataire final de tous les paquets de donnes crs par les nuds du rseau. Lexistence dun Sink dans le rseau de capteurs est trs rpandue. Un Sink peut tre une machine puissante qui possde des ressources matrielles importantes. Tout dpend de lapplication, ainsi nous traiterons plusieurs cas. Cas 1 : nous supposons que le Sink ne connat pas les identifications des nuds dploys. Dans ce cas, le Sink diffuse un paquet requte tout le rseau travers les nuds qui lentourent (voisins du Sink un seul saut). Nous avons deux choix afin de mettre le Sink en contact avec le rseau : le sink communique avec un seul nud ou avec plusieurs nuds. Dans le premier cas, le Sink choisit alatoirement un nud parmi ses voisins pour se mettre en contact avec le rseau. Ce nud voisin rajoute son identification la requte et la rediffuse ses nuds voisins qui, leur tour, rediffusent le paquet, une seule fois. Ainsi, le paquet requte atteint tous les nuds du rseau. Les nuds qui collectent des donnes satisfaisant la requte du Sink rpondent par des paquets en mettant comme destinataire final le nud en contact avec le Sink. A la rception de ces paquets, ce nud les transfre au Sink. Dans le deuxime cas, les nuds voisins du Sink (ou une partie de ces nuds) diffusent la requte dans le rseau en rajoutant leurs identifications. Ainsi, les nuds qui collectent les donnes envoient les paquets ces nuds voisins, qui leur tour les transfrent au Sink. Ceci vite lencombrement dun seul nud et permet de partager les tches entre eux. Concernant le routage de ces paquets, entre les nuds du rseau, cest exactement comme le cas dchange de donnes sans station de base : un routage lintrieur de la mme zone en utilisant la table inra-zone, et un routage entre les zones en utilisant la table inter-zones. Cas 2 : si nous supposons que le Sink connat pralablement lidentification des nuds et leurs positions dans lenvironnement surveill, il peut alors sadresser ces nuds dans le champ qui lintresse de la mme faon que dans le cas 1 mais sans besoin de diffuser la requte tous les nuds du rseau. Ainsi, lchange de donnes se fait entre les nuds collectant les donnes et ceux qui entourent le Sink en utilisant les tables intra-zones et inter-zones. Cas 3 : il concerne les nuds du rseau qui possdent lidentification du Sink. Celui-ci sera trait comme un nud du rseau. Les nuds qui dtectent des vnements envoient les donnes au Sink par un simple routage en utilisant le protocole propos comme vu dans la section prcdente. Notons que dans la plupart des cas que nous avons cits, il est possible de mettre en veille les nuds des zones non utilises dans le routage des donnes. La mise en veille conomise lnergie des nuds, ce qui prolonge la vie du systme.

121

Mise en uvre du protocole de routage Dans la suite nous dcrirons le comportement du systme lors dune panne, de lapparition, et la mobilit dun nud dans le rseau.

5.4.3 Panne, apparition, et mobilit dun nud

Il est possible quun nud tombe en panne durant le fonctionnement du systme. A la suite de ce changement, le systme doit ragir pour mettre jour les informations de routage chez les nuds concerns par ce changement. Supposons dabord que le nud tomb en panne ne soit pas utilis pour un certain change de donnes durant le fonctionnement du systme. Lenvoi priodique des messages HELLO permet aux voisins de ce nud de dtecter sa panne. Ainsi, ils mettent jour leurs tables intra-zone et cette mise jour se propage dans la zone. Si ce nud est BORDER, alors les nuds BORDER des autres zones mettent jour leurs tables BorderTable aussi que les tables inter-zones si besoin. Durant ces mises jour, les nuds non concerns peuvent continuer fonctionner normalement. Dailleurs, les nuds qui sont en cours de fonctionnement (collecte de donnes, routage des donnes) et qui doivent mettre jour leurs tables, peuvent choisir une priorit dpendant de lapplication : continuer fonctionner ou suspendre le fonctionnement pour mettre jour les informations de routage. Lapparition dun nouveau nud a aussi une certaine influence sur la topologie du rseau. Le nouveau nud qui apparat dans une certaine zone, envoie un paquet NEW_NODE annonant sa prsence. Les nuds recevant ce paquet rpondent par un paquet dinvitation leurs zones. Ainsi, ce nud rejoint la zone. Ensuite, une mise jour des tables de routage (intra-zone et inter-zones) est lance comme dans le cas de panne dun nud. De cette faon, le systme sera mis jour et prt fonctionner avec le nouveau nud. En ce qui concerne la mobilit dun nud, notre systme la traite comme une panne de ce nud dans son premier emplacement et son apparition dans le nouvel emplacement. Mais comment un nud peut-il savoir quil est en dplacement si on suppose quil ne possde pas un capteur de vitesse. En effet, dans notre systme, il est possible de dtecter la mobilit dun nud travers les messages priodiques changs entre les nuds. Le nud constate quil en dplacement lorsquil reoit des messages HELLO de la part des nouveaux nuds (leur nombre peut tre dfini comme paramtre) non enregistrs dans sa table intra-zone. Ces nouveaux nuds, quils soient dans la mme zone ou non, seront les nouveaux voisins du nud en mobilit aprs le lancement de la mise jour des tables. Dans la suite du document, nous prsenterons deux applications spcifiques utilisant notre systme o le Sink est en mobilit : guidage des vhicules (ou des personnes mal voyantes) dans un espace urbain et une dtection de feu dans une fort.

5.5

Applications utilisant notre systme

Gnralement, les applications dans les rseaux de capteurs peuvent tre classifies en trois classes : Collecte priodique de donnes dans ce type dapplication, les nuds du rseau envoient

122

Applications utilisant notre priodiquement leurs donnes collectes du champ dintrt la station de base ou au Sink. Rponse un vnement dans ce type dapplication, les nuds ne ragissent que lors de la dtection dun vnement dans le rseau (par exemple dtection de feu) et puis ils envoient les donnes au Sink ou la station de base. Poursuite dune cible les nuds du rseau poursuivent une cible en changeant des signaux avec la cible. Dans cette section nous dcrirons deux applications qui peuvent sappuyer sur notre systme dcrit prcdemment. Une application est utilise pour aider un vhicule (ou personne mal voyante) atteindre une certaine cible. Lautre application concerne la dtection de feu dans une fort.

5.5.1 Guidage dun vhicule

Dans cette application, nous supposons que le Sink est le vhicule et quil possde pralablement les identifications des nuds destinataires. Le vhicule est quip dun systme de traitement dinformation qui est capable de recevoir les donnes collectes, les traiter, et communiquer avec des nuds du rseau. Le guidage peut tre galement utilis pour aider les personnes mal voyantes se dplacer (97).
Z1 Z2 Z3

Z4

Z5

Z6

Requte

Z7

Z8

Z9

Dest.

Figure 5.6 : Systme de guidage dun vhicule

La Figure 5.6 montre un systme de guidage de vhicule en se basant sur un rseau de capteurs partitionn virtuellement en zones selon notre proposition. Rappelons que chaque nud dune zone possde une table de routage intra-zone. Les nuds BORDER possdent les tables inter-

123

Mise en uvre du protocole de routage zones. Dans la Figure 5.6, les liens entre les nuds BORDER qui relient les zones sont illustres par des flches. A noter que dans un tel partitionnement les zones ne sont pas forcment de formes rectangulaires comme le montre la Figure 5.6, mais cest juste pour simplifier lexemple et pour quil soit plus claire. Voyons le fonctionnement de ce systme. Tout dabord, le Sink (vhicule) diffuse un paquet requte autour de lui demandant un chemin vers un nud destinataire. Dans notre exemple (Figure 5.6), le vhicule envoie la requte quelques nuds de la zone Z4 afin de lui trouver un chemin vers le nud destinataire dans la zone Z9 (par exemple la gare). Un seul nud suffit parmi ces nuds pour rpondre la requte et ainsi tre en contact avec le vhicule. Le vhicule choisit un seul nud de la zone Z4 pour lui trouver le chemin (par exemple, le premier nud qui rpond est choisi). Nommons-le nud metteur et supposons quil est un nud NORMAL. Le vhicule doit attendre une rponse de ce nud avant quil commence se dplacer. Cette attente est utilise pour tre sr quil y a un chemin vers la destination (nud multi-couleur dans la zone Z9). Ensuite, le nud metteur utilise sa table de routage afin de router le paquet requte vers le nud destinataire. En utilisant le protocole de routage hirarchique que nous avons propos, un chemin vers le nud destinataire est construit travers les nuds du rseau (voir la Figure 5.7). Les identifiants des nuds peuvent tre enregistrs dans ce paquet afin de les utiliser dans le chemin emprunter par le vhicule.
Z1 Z2 Z3

Z4

Z5

Z6

Emett.

Z7

Z8

Z9

Dest.

Figure 5.7 : Construction du chemin vers la destination

Lorsque le nud destinataire reoit la requte, il rpond au nud metteur (en contact avec le

124

Applications utilisant notre vhicule) par un paquet de rponse contenant le chemin emprunter. Ce paquet de rponse passe par les mmes nuds du chemin mais en sens inverse. De cette faon, nous pouvons garder en veille les nuds des zones non empruntes par le chemin, voire les nuds non utiliss dans les zones empruntes. Ceci conomise leur nergie et prolonge la vie du systme. Une fois que le vhicule reoit le chemin de la part du nud metteur, il commence se dplacer suivant le chemin construit par les nuds. Au cours du dplacement le vhicule est en contact avec les nuds du chemin qui collectent et envoient en temps rel des donnes au vhicule qui, son tour, les traite. Supposons que le vhicule reoive une information dun tel nud sur le chemin lui indiquant quil ne peut plus passer par le reste du chemin (par exemple, un nouvel obstacle est survenu). Comment le Sink doit-il se comporter ?
Z1 Z2 Z3

Z4

Z5

Z6

Emett.

Z7

Z8

Z9

Dest.

Figure 5.8 : Dplacement du vhicule sur le chemin

La Figure 5.8 montre un exemple du dplacement du vhicule sur un certain chemin pour atteindre la destination dans la zone Z9 (la gare dans notre exemple). Cette figure montre aussi quun nud (nomm A) de ce chemin informe le vhicule quil ne peut pas continuer sur ce chemin pour atteindre le nud suivant (nomm B) car il existe un nouvel obstacle. Le vhicule doit sarrter et demande aux nuds qui lentourent si cest possible de passer travers eux pour atteindre le nud B. Ensuite, les nuds qui ont B comme destination dans leur table de routage intra-zone rpondent par un paquet avec le cot du chemin. Le vhicule choisit le nud qui a le

125

Mise en uvre du protocole de routage cot minimal pour complter son chemin. Ainsi, un chemin est construit entre ce nud et le nud B par une simple requte. Ce chemin est retourn au vhicule qui pourra reprendre son dplacement suivant le nouveau chemin (chemin vers B + chemin de B vers la destination dans la zone Z9) pour atteindre la destination. Sil ny a pas de chemins pour atteindre le nud B, alors le vhicule cre une nouvelle requte (comme au dpart) et la diffuse pour demander un chemin vers la destination. De cette faon, le systme est capable de dtecter les obstacles fixes (nomms statiques) et mobiles (nomms dynamiques) et informer le vhicule de ces donnes en temps rel.

5.5.2 Dtection de feu dans une fort

Z1 Z2 Z3

Z4

Z5

Z6

Internet, satellite,

Z7

Z8

Z9

Figure 5.9 : Systme de dtection de feu dans une fort

La Figure 5.9 montre un systme de dtection de feu dans une fort. Comme lapplication prcdente, le rseau de capteurs est partitionn en zones. Chaque nud possde une table de routage intra-zone pour le routage lintrieur de la zone. Les nuds BORDER possdent les tables inter-zones pour le routage entre les zones. Dautre part, dans cette application, on demande le chemin vers la station de base lors dun tel vnement (dtection de feu). Les nuds du rseau doivent connatre pralablement o se situe la station de base (ou son identification si elle est considre comme un nud). Cette figure montre aussi une dtection dun feu par un nud du rseau dans la zone Z8. Ce nud envoie linformation dalerte, via les nuds du rseau, la station de base qui informera lutilisateur final du systme (personnes intervenir comme les pompiers) de cet vnement. Ce nud envoie galement son identification afin de prciser le lieu du feu. Aprs

126

Applications utilisant notre lintervention des personnes concernes, nous supposons quelles possdent galement des systmes par lesquels elles peuvent communiquer directement avec la station de base. Cette communication directe est indispensable afin de les alerter rapidement dun nouveau feu sur le champ dintervention. La Figure 5.10 montre le comportement du systme la dcouverte dun nouvel vnement dans la zone Z4 lors de lintervention des pompiers. Le nud qui dtecte le nouveau feu envoie linformation dalerte la station de base qui, son tour, informe directement les pompiers se trouvant sur le champ afin des les avertir du nouveau danger.
Z1 Z2 Z3

Z4

Z5

Z6

Z7

Z8

Z9

Figure 5.10 : Dtection dun nouveau feu lors de lintervention des pompiers

Comme dans lapplication prcdente, les zones o il ny a pas de feu peuvent garder leurs nuds en veille afin dconomiser lnergie, ainsi que les nuds non utiliss pour le routage des informations dans les zones du feu.

5.6

Conclusion

Nous avons dcrit dans ce chapitre comment notre protocole de routage peut tre mis en place et comment un tel systme utilisant ce protocole fonctionne. Nous avons aussi dcrit globalement la faon dinjecter le protocole dans des capteurs MICA2 fabriqus par CrossBow en utilisant le systme dexploitation TinyOS et le langage nesC. Ensuite, nous avons montr comment le systme peut tre install : le dploiement des nuds, le partitionnement du rseau en zones, la construction des tables de routage (intra-zone et inter-zones). Nous avons dcrit galement deux

127

Mise en uvre du protocole de routage types de fonctionnement du systme lors de lchange de donnes avec ou sans station de base. A la fin, nous avons montr deux applications relles qui utilisent le protocole de routage propos : guidage dune vhicule et dtection de feu dans une fort.

128

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Chapitre 6. Conclusion

Dans cette thse nous avons trait le problme du routage dans les rseaux da capteurs. Cet aspect est fondamental pour ce genre de rseau caractris par labsence dinfrastructure. Le routage se ralise en collaboration entre les diffrents nuds du rseau. Un protocole de routage doit prendre en compte les contraintes matrielles dun capteur : une batterie faible, un capacit de stockage modeste, une bande passante faible, etc. Lorsque la taille du rseau devient de plus en plus importante, les protocoles de routage plat ne se comportent pas de faon optimale. Do vient lide de partitionner le rseau en zones. Pour atteindre cet objectif, nous avons propos un nouveau protocole hirarchique de routage nomm ZHRP (Zone-based Hierarchical Routing Protocol) bas sur une topologie structure en zones. La construction de cette topologie est constitue de deux phases : le partitionnement du rseau en zones et la construction des tables de routage. En effet, nous avons propos un algorithme distribu de partitionnement dun rseau de capteurs en zones. Le but de cet algorithme est davoir une structure hirarchique pour le rseau. Contrairement la plupart des algorithmes de structuration du rseau de la littrature, notre algorithme nexige pas dinformations sur le rseau (nergie de nuds, position des nuds, tat des liens, etc.). Il est bas sur le nombre de sauts. Le nombre de zones est paramtrable et prdfini. La distribution des nuds est alatoire. A la fin de lexcution de cet algorithme, chaque nud du rseau devrait tre affect une seule zone. Les nuds qui sont aux frontires des zones, appels nuds BORDER, possdent une table-frontire utile pour la phase de construction des tables de zones. Nous avons galement dfini une mtrique de zone, qui est le nombre de sauts maximal pour traverser la zone. Cette mtrique est calcule durant cette phase et utilise dans la phase suivante. Durant la deuxime phase du protocole, les nuds de chaque zone construisent dabord leurs tables de routage intra-zone. Ces tables servent router les donnes entre les nuds dune mme zone. La construction est faite en se basant sur lalgorithme Distance Vector qui est simple et efficace dans les petits rseaux. Puis, les nuds BORDER de chaque zone changent leurs tables-

129

Conclusion frontires pour construire une table partielle de routage inter-zones. Les tables compltes de routage inter-zones sont ensuite construites par les nuds BORDER qui ont le plus grand ID dans leurs zones en se basant sur lalgorithme Distance Vector. A la fin de cette construction, ces nuds diffusent la table complte tous les nuds BORDER de leurs zones. Cette table est utile pour le routage entre les zones. Nous avons ensuite propos un algorithme de routage de donnes entre les nuds du rseau partitionn en zones. Dans cet algorithme, le routage est dcision locale, cest-dire, chaque nud qui reoit un paquet de donnes transfre le paquet suivant les informations de routage quil possde (table intra-zone, table inter-zones). Aussi, nous avons propos galement des algorithmes pour la maintenance du systme bas sur le protocole ZHRP lors dune panne, dune apparition ou dune mobilit dun nud dans le rseau. Afin de montrer le bon comportement du protocole propos, nous avons ralis des simulations. Nous avons utilis le simulateur open source J-Sim qui contient un package pour les rseaux de capteurs. J-Sim est cod en Java et utilise le langage TCL pour crire le scnario de la simulation. Le protocole a t valu selon cinq mtriques : le taux derreur dfini comme le nombre de nuds non affects aucune zone (nuds isols), le surcot dfini par le nombre de messages de contrles envoys et reus pour partitionner le rseau et construire les tables de routage, la consommation nergtique calcule suivant le surcot en se basant sur les caractristiques matrielles dun capteur MICA2, lespace de stockage calcule par le nombre doctets ncessaires pour stocker les informations de routage dans un capteur, la scalabilit ladaptabilit du systme garder ses fonctionnalits lorsquon passe un rseau grande chelle. Les simulations ont montr un taux derreur gal zro dans la plupart des cas, un faible surcot, une consommation nergtique trs modeste, et un petit espace de stockage ncessaire pour les informations de routage. Ces simulations ont galement montr le bon comportement du protocole dans les rseaux grande chelle. A la fin de cette thse, nous avons dcrit comment mettre en uvre le protocole de routage propos. Ainsi, nous avons dcrit la manire de construire un rseau de capteurs oprationnel en se basant sur une architecture hirarchique et en utilisant notre protocole de routage.

Perspectives
Afin de continuer le travail, nous proposons de dvelopper notre approche pour traiter le problme de la mobilit du Sink sur un chemin non prdfini. En effet, dans notre approche, les nuds qui collectent les donnes envoient les donnes au Sink (il a une position connue ou un chemin prdfini) ou ses voisins. Dautre part, lorsque le Sink est mobile, les nuds ne pourront plus connatre sa position. La solution basique est de diffuser les paquets de donnes dans tous le rseau. De cette manire, le Sink sera forcement atteint. Mais, cette solution nest pas efficace car le rseau est inond par lenvoi et la rception des paquets, ce qui consomme lnergie des nuds et

130

Conclusion par suite diminue la vie du systme. Une autre perspective est de proposer une technique de mise en veille des nuds qui ne sont pas utiliss durant un tel acheminement de donnes. Dans notre protocole hirarchique, certaines zones peuvent ne pas tre concernes par le fonctionnement du systme un certain moment. Pour cela, il est indispensable de mettre les nuds de ces zones en mode veille afin de conserver leur nergie et par suite prolonger la vie du systme. Enfin une dernire ide concernant une mthode dagrgation de donnes. En effet, dans cette mthode, plusieurs nuds qui sont proximit dun certain vnement communiquent dans le but de fusionner les donnes collectes. Lagrgation permettrait de minimiser le nombre denvois des donnes collectes identiques par plusieurs nuds voisins afin de les acheminer vers la destination finale. Ainsi, on prolonge la vie du systme en minimisant lenvoi et la rception des paquets.

131

[CONCEPTION DUN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS]

Bibliographie
1. S. Macker, J. Corsen. Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Consideration. RFC2501. [En ligne] January 1999. http://www.ietf.org/rfc/rfc2501.txt. 2. Jacquet, P. Muhlethaler, P. Clausen, T. Laouiti, A. Qayyum, A. Viennot, L. Optimized link state routing protocol for ad hoc networks. Multi Topic Conference IEEE INMI, Technology for the 21st Century. 2001, pp. 62- 68. 3. T. Clausen, P. Jacquet. Optimized Link State Routing Protocol. RFC3626. [En ligne] October 2003. http://www.ietf.org/rfc/rfc3626.txt. 4. Mario Gerla, Xiaoyan Hong, Guangyu Pei. Fisheye State Routing Protocol (FSR) for Ad Hoc Networks. INTERNET-DRAFT . [En ligne] 17 June 2002. http://tools.ietf.org/html/draft-ietf-manet-fsr03. 5. Pei, Guangyu, Gerla, M. and Chen, Tsu-Wei. Fisheye state routing : a routing scheme for ad hoc wirelessnetworks. IEEE International Conference on Communication. 2000, Vol. 1, pp. 70-74. 6. C. E. Perkins, E. M. Royer, S. R. Das. Ad hoc on demand distance vector (aodv ) routing. In IETF, Internet Draft, draft-ietf-manet-aodv-05.txt. [En ligne] 2000. 7. David B. Johnson, David A. Maltz. Protocols for adaptive wireless and mobile computing. IEEE Personal Communications. February 1996, Vol. 3, 1. 8. David B. Johnson, David A. Maltz, and Josh Broch. DSR: The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc Networks. [d.] Tomasz Imielinski and Hank Korth. Kluwer Academic Publishers . 1996. pp. 153-181. 9. M. Jiang, J. Li & Y. C. Tay. Cluster Based Routing Protocol (CBRP). Internet draft 1, IETF-

MANET Working Group. [En ligne] 1999.

10. Malkin, G. RFC 2453-RIP http://tools.ietf.org/html/rfc2453. Version 2.

IETF.

[En

ligne]

November

1998.

11. Lindqvist, J. Counting to Infinity. Sjkull : Helsinki Telecommunications Software and Multimedia Laboratory, 2004.

University

of

Technology,

12. Holger Karl, Andreas Wilig. Protocols and Architectures for Wireless Sensor Networks. Wiley. 2006. 13. Walden, D. The Bellman-Ford Algorithm and Distributed Bellman-Ford. [En ligne] 2009.

133

Bibliographie
http://www.walden-family.com/public/bf-history.pdf. 14. Charles E. Perkins, Pravin Bhagwat. Highly dynamic Destination-Sequenced Distance-Vector routing (DSDV) for mobile computers. ACM SIGCOMM Computer Communication Review. October 1994, Vol. 24, 4. 15. Adjih, C., Baccelli, E. et Jacquet, P. Link state routing in wireless ad-hoc networks. Military Communications Conference, MILCOM 2003. IEEE. 2003, Vol. 2, pp. 1274 - 1279. 16. Dijkstra, E. W. A note on two problems in connexion with graphs. [d.] Springer Berlin Heidelberg. Numerische Mathematik. dcembre 1959, Vol. Volume 1, pp. 269-271. 17. Moy, J. OSPF, Anatomy of an Internet Routing Protocol. Addison-Wesley. 1998. 18. Moy, J. OSPF version 2. RFC 2328. [En ligne] April 1998. http://ietf.org/rfc/rfc2328.txt. 19. Georges, Asch. Les capteurs en instrumentation industrielle. Dunod. 1998. 20. Noury, Norbet. Du signal l'information : le capteur intelligent Exemples industriels et en mdecine. Grenoble : TIMC-IMAG, 2002. 21. S.J., Pister Kristofer. http://webs.cs.berkeley.edu/tos/. TinyOS. [En ligne] 2009. 22. Kristofer, Pister. http://robotics.eecs.berkeley.edu/~pister/SmartDust/. SmartDust. [En ligne] 2001. 23. Crossbow. MICA2 Data sheet. [Online] http://www.xbow.com/products/Product_pdf_files/Wireless_pdf/MICA2_Datasheet.pdf. 2009.

24. Antoine Gallais, Franois Ingelrest, Jean Carle, David Simplot-Ryl. Maintien de la couverture de surface dans les rseaux de capteurs avec une couche physique non idale. CFIP, Colloque Francophone sur l'Ingnierie des Protocoles. 2006. 25. Gallais, Antoine. Ordonnancement dactivit dans les rseaux de capteurs : lexemple de la couverture de surface. Universit des sciences et technologies de Lille. 2007. Rapport de thse. 26. Cheng, K. Field and Wave Electromagnetics. s.l. : Addison-Wesley, 1989. p. 639. 27. CrossBow. Sensor Boards. https://www.xbow.com/Products/productdetails.aspx?sid=158. [En ligne]

28. I. F. Akyildiz, W. Su , Y. Sankarasubramaniam , E. Cayirci. Wireless sensor networks: a survey. 2002, Vol. 38, pp. 393-422. 29. C.Y. Chong, S.P. Kumar. Sensor Networks : Evolution, Opportunities, and Challenges.

Proceedings of the IEEE. 2003, Vol. 91, pp. 1247-1256.

30. T.B. Gosnell, J.M. Hall, C.L. Ham, D.A. Knapp, Z.M. Koenig, S.J. Luke, B.A. Pohl, A.Schach von Wittenau, and J.K. Wolford. Gamma-Ray Identification of Nuclear Weapon Materials. Lawrence Livermore National Lab. Livermore CA, USA : s.n., February, 1997. Technical repport DE97053424.

134

Bibliographie
31. Brown, M. J. Users Guide Developed for the JBREWS Project. Los Alamos National Laboratory of California University. 1999. Technical repport LA-UR-99-4676. 32. Andrews, P. Johnson and D.C. Remote continuous monitoring in the home. Telemedicine and Telecare. June 1996, Vol. 2, 2, pp. 107-113. 33. E.M. Petriu, N.D. Georganas, D.C. Petriu, D. Makrakis, and V.Z. Groza. Sensor-based information appliances. IEEE Instrumentation Measurement Magazine. December 2000, Vol. 3, 4, pp. 31-35. 34. Michael Fitzgerald. Technnology Review : Tracking a Shopper's Habits. Technology Review. [En ligne] 04 August 2008. http://www.technologyreview.com/computing/21161/. 35. Chen, Tsu-Wei et Gerla, M. Global state routing: a new routing scheme for ad-hoc wirelessnetworks. IEEE International Conference on Communications. 1998, Vol. 1, pp. 171-175. 36. Stevens, L. Kleinrock and K. Fisheye: A Lenslike Computer Display Transformation. s.l. : UCLA, Computer Science Department, 1971. Technical report. 37. Josh Brosh, David B. Johnson, David A. Maltz. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks. Internet Draft. [En ligne] 13 March 1998. http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-manet-dsr-00.txt. 38. Anis Laouiti, Cdric Adjih. Mesures de performances du protocole OLSR. Projet Hipercom. 2003. Rapport technique. 39. Amir Qayyum, Laurent Viennot, Anis Laouiti. Multipoint relaying : An efficient technique for flooding in mobile wireless networks. s.l. : INRIA, 2000. Reaserch report. 40. S. Woo, S. Singh. Scalable Routing Protocols for Ad Hoc Networks. [d.] Kluwer Academic Publishers. Wireless Network. January 2001, Vol. 7, pp. 513-529. 41. C. Cheng, H. Lemberg, S. Philip, E. Van Den Berg et T. Zhang. SLALoM: Scalable Location Management Scheme for Large Mobile Ad Hoc Networks. Wireless Communications and Networking Conference. March 2002, Vol. 2, pp. 574 - 578. 42. Philip, Sumesh J. and Qiao, Chunming. Hierarchical grid location management for large wireless Ad hoc networks. SIGMOBILE Mob. Comput. Commun. Rev. 2003, Vol. 7, 3, pp. 33--34. 43. Li, Jinyang, et al. A scalable location service for geographic ad hoc routing. 6th annual

international conference on Mobile computing and networking. 2000, pp. 120-130.

44. B. Karp, H.T. Kung. GPSR: Greedy Perimeter Stateless Routing for Wireless Networks. ACM/IEEE Mobicom. August 2000, pp. 243 - 254. 45. Jiang, Zhen, et al. An Information Model for Geographic Greedy Forwarding in Wireless Ad-Hoc Sensor Networks. INFOCOM 2008. The 27th Conference on Computer Communications, IEEE. 2008, pp. 825 - 833.

135

Bibliographie
46. Lee, K.C. Haerri, J. Uichin Lee Gerla, M. Enhanced Perimeter Routing for Geographic Forwarding Protocols in Urban Vehicular Scenarios. Globecom Workshops, 2007 IEEE. 2007. 47. W. Heinzelman, J. Kulik, and H. Balakrishnan. Adaptive protocols for information dissemination in wireless sensor networks. 5th annual ACM/IEEE international conference on Mobile computing and networking . August 1999, pp. 174 - 185. 48. Kemal Akkaya, Mohamed Younis. A survey on routing protocols for wireless sensor networks. Ad

Hoc Networks. May 2005, Vol. 3, 3, pp. 325-349.

49. Heinzelman, M. et Perillo, W. Wireless Sensor Network Protocols. [d.] CRC Hall. 2005. 50. Lindsey, S. Raghavendra, C.S. PEGASIS: Power-efficient gathering in sensor information systems.

IEEE Aerospace Conference Proceedings. 2002, Vol. 3, pp. 3-1130.

51. Hamma, T. Katoh, T. Bista, B.B. Takata, T. An Efficient ZHLS Routing Protocol for Mobile Ad Hoc Networks. 17th International Conference on Database and Expert Systems Applications. 2006, pp. 66-70. 52. Ching-Chuan Chiang, Hsiao-Kuang Wu, Winston Liu, Mario Gerla. Routing in clustered multihop, mobile wireless, networks with fading channel. IEEE SICON. 1997, pp. 197-211. 53. A. Ephremides, J.E. Wieselthier and D.J. Baker. A design concept for reliable mobile radio networks with frequency hopping signaling. IEEE 75. 1987, pp. 56-73. 54. Tsai, Mario Gerla and Jack Tzu-Chieh. Multicluster, mobile, multimedia radio network. ACM-

Baltzer Journal of Wireless Networks. 1995, Vol. 1, 3, pp. 255-265.

55. W.R. Heinzelman, A. Chandrakasan, H. Balakrishnan. Energy-efficient Communication Protocol for Wireless Microsensor Networks. Proceedings of the IEEE Hawaii International Conference on System Sciences. 2000, Vol. 2, p. 10. 56. W.R. Heinzelman, A.P. Chandrakasan , and H. Balakrishnan. An application-specific protocol architecture for wireless microsensor networks. IEEE Transactions Wireless Communications. October 2002, Vol. 1, 4, pp. 660-670. 57. Seema Bandyopadhyay, Coyle E.J. An energy efficient hierarchical clustering algorithm for wireless sensor networks. INFOCOM. 2003, pp. 1713-1723. 58. Lindsay, S., Raghavendra, C. S., and Sivalingam, K. M. Data Gathering in SEnsor Networks using the Energy Delay Metric. [d.] IEEE COmputer Society. 15th international Parallel & Amp; Distributed Processing Symposium. April 23 - 27, 2001 2001, p. 188. 59. Huynh, Trong Thua and Hong, Choong Seon. An Energy* Delay Efficient Multi-Hop Routing Scheme for Wireless Sensor Networks. IEICE - Transactions on Information and Systems. 2006, Vol. E89-D, 5. 60. A. Manjeshwar, D.P. Agrawal. TEEN: a routing protocol for enhanced efficiency in wireless sensor networks. Proceedings 15th International Parallel and Distributed Processing Symposium. 2001,

136

Bibliographie
pp. 2009-2015. 61. Manjeshwar, Arati and Agrawal, Dharma P. APTEEN: A Hybrid Protocol for Efficient Routing and Comprehensive Information Retrieval in Wireless Sensor Networks. IPDPS '02, 16th International Parallel and Distributed Processing Symposium. 2003, p. 48. 62. Al-Karaki, Jamal N. and Ul-Mustafa, Raza and Kamal, Ahmed E. Data aggregation and routing in Wireless Sensor Networks: Optimal and heuristic algorithms. Computer Networks: The International Journal of Computer and Telecommunications Networking. 2009, Vol. 53, 7, pp. 945-960. 63. Al-Karaki, Jamal N. and Ul-Mustafa, Raza and Kamal, Ahmed E. Data aggregation in wireless sensor networks - exact and approximate algorithms. High Performance Switching and Routing, HPSR 2004. 2004, pp. 241-245. 64. A. Savvides, C.C. Han, and M. Srivastava. Dynamic fine-grained localization in Ad-Hoc networks of sensors. 7th ACM Annual International Conference on Mobile Computing and Networking (MobiCom). July 2001, pp. 166-179. 65. J.N. Al-Karaki, Kamal A.E. On the Correlated Data Gathering Problem in Wireless Sensor Networks. Ninth IEEE Symposium on Computers and Communications (ISCC04). July 2004, Vol. 1, pp. 226-231. 66. Lin H., Chu Y. A clustering technique for large multihop mobile wireless networks. Vehicular

Technology Conference Proceedings. 2000, Vol. 7, pp. 1545-1549.

67. O. Younis, S. Fahmy. Heed: A hybrid, energy-efficient, distributed clustering approach for ad hoc sensor networks. IEEE Transactions on Mobile Computing 03 (4). 2004, pp. 366379. 68. M. Lehsaini, H. Guyennet, M. Feham. A novel cluster-based self-organization algorithm for wireless sensor networks. IEEE International Symposium on Collaborative Technologies and Systems (CTS 2008). May 2008, pp. 19-26. 69. Mohamed, LEHSAINI. Diffusion et couverture bases sur le clustering dans les rseaux de capteurs : application la domotique. s.l. : UFC, Juillet 2009. Thse de doctorat. 70. M. Lehsaini, H. Guyennet and M. Feham. An Efficient Cluster-based Self-organization Algorithm for Wireless Sensor Networks. IJSN, International Journal of Sensor Networks. 2008. 71. Q. Fang, F. Zhao, and L. Guibas. Lightweight Sensing and Communication Protocols for Target Enumeration and Aggregation. 4th ACM International Symposium on Mobile Ad hoc Networking and Computing (MOBIHOC 2003). June 2003, pp. 165-176. 72. Luo, H., Ye, F., Cheng, J., Lu, S., and Zhang, L. TTDD: two-tier data dissemination in large-scale wireless sensor networks. Wireless Networks. January 2005, Vol. 11, pp. 161-175. 73. Hui Chen, Jannong Cao. A Design Framework and Taxonomy for Hybrid Routing Protocols in Mobile Ad Hoc Networks. IEEE Communications Surveys & Tutorials, 3rd quater 2008. 2008, Vol. 10, 3.

137

Bibliographie
74. Jamal N. Al Karaki, Ahmed E. Kamal. Routing techniques in wireless sensor networks : A survey. Wireless Communications, IEEE. Dec 2004, 6, pp. 6-28. 75. Kamal Beydoun, Violeta Felea, and Herv Guyennet. Energy-Efficient WSN Infrastructure. DCSN'08, IEEE Int. Workshop on Distributed Collaborative Sensor Networks. May 2008, pp. 58--65. 76. Kamal Beydoun, Violeta Felea, and Herve Guyennet. Wireless Sensor Network Infrastructure: Construction and Evaluation. ICWMC'09, IEEE Int. Conf. on Wireless and Mobile Communications. August 2009, pp. 279-284. 77. Karp, R. M. Reducibility Among Combinatorial Problems. [d.] J. W. Thatcher R. E. Miller.

Complexity of Computer Computations. 1972, pp. 85-103.

78. J-Sim Home page. [Online] 2009. http://sites.google.com/site/jsimofficial/. 79. Ahmed Sobeih, Wei-Peng Chen, Jennifer C. Hou, Lu-Chuan Kung, Ning Li, Hyuk Lim, HungYing Tyan, Honghai Zhang. J-Sim: A Simulation and Emulation Environment for Wireless Sensor Networks. IEEE Wireless Communications magazine . 2005, Vol. 13, p. 2006. 80. Tyan, Hung-ying. Design, realization and evaluation of a component-based compositional software architecture for network simulation. 2002. Thesis repport. 81. Tcl Developper Site. [En ligne] July 2009. http://www.tcl.tk/. 82. About GlomoSim. [Online] http://pcl.cs.ucla.edu/projects/glomosim/. 83. OMNeT++ Community Site. [En ligne] 12 2008. http://www.omnetpp.org/. 84. OPNET Technologies. [En ligne] 12 2008. http://www.opnet.com/. 85. The Network Simulator. [Online] http://www.isi.edu/nsnam/ns/. 86. Raghunathan, V., et al. Energy-aware wireless microsensor networks. Signal Processing Magazine, IEEE. March 2002, Vol. 19, pp. 40--50. 87. Group, TIK WSN Research. Tmote Sky. The Sensor Network Museum. [En ligne] http://www.snm.ethz.ch/Projects/TmoteSky. 88. TinyOS. TinyOS. [En ligne] 2009. http://www.tinyos.net/. 89. Hill, J.L. System architecture for wireless sensor networks. University of California. Berkeley : s.n., 2003. PhD Thesis. 90. TinyOS. www.tinyos.net/tinyos-1.x/doc/. [En ligne] 2003. 91. Berkeley, UC. nesC: A Programming Language for Deeply Networked Systems . nesC. [En ligne] http://nescc.sourceforge.net/. 92. Sun SPOT System. Sun Microsystem. http://research.sun.com/spotlight/SunSPOTSJune30.pdf. [En ligne] 2009.

138

Bibliographie
93. Bernard Horan, Bill Bush, John Nolan, and David Cleal. A Platform for Wireless Networked Transducers. s.l. : SUN, 2007. 94. Sun SPOT. The Sensor http://www.snm.ethz.ch/Projects/SunSPOT.

Network

Museum.

[En

ligne]

2009.

95. The Squawk Virtual Machine . SUN. http://research.sun.com/projects/squawk/squawk-rjvm.html.

[En

ligne]

Septembre

2009.

96. Sun SPOT World. [En ligne] 2009. http://www.sunspotworld.com/. 97. Kamal Beydoun, Violeta Felea, and Herv Guyennet. Wireless sensor network system helping navigation of the visually impaired. ICTTA'08, IEEE int. conf. on Information and Communication Technologies: from Theory to Applications. April 2008, pp. 1--5.

139

141