THESE CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS. Kamal BEYDOUN. Année 2009

Transcription

1 Année 2009 THESE présentée à L U.F.R DES SCIENCES ET TECHNIQUES DE L UNIVERSITE DE FRANCHE-COMTE pour obtenir GRADE DE DOCTEUR DE L UNIVERSITE DE FRANCHE-COMTE Spécialité : Informatique CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS par Kamal BEYDOUN Soutenue le 16 décembre 2009 devant la commission d examen : Directeurs de thèse Hervé GUYENNET Professeur, Université de Franche-Comté Violeta FELEA Maître de conférences, Université de Franche-Comté Rapporteurs Abdelhamid MELLOUK Michael KRAJECKI Professeur, Université de Paris XII Professeur, Université de Reims Champagne-Ardenne Examinateur Mohamed NAIMI Professeur, Université de Cergy-Pontoise Jean-Christophe LAPAYRE Professeur, Université de Franche-Comté

2 2

3 Remerciements Je tiens à remercier en premier lieu Mr. Hervé GUYENNET et Mlle Violeta FELEA, mes directeurs de thèse pour leur encouragement, leur disponibilité, leurs idées, leurs conseils et leur sympathie qui m ont permis de mener à bien cette thèse. J adresse aussi mes très sincères remerciements à Mr. Jean-Christophe LAPAYRE pour l honneur qui nous a été accordé en présidant le jury. J exprime ensuite ma plus profonde gratitude à Mr. Abdelhamid MELLOUK et Mr. Michael KRAJECKI qui ont accepté de rapporter cette thèse. Je tiens à remercier également Mr Mohamed NAIMI d avoir examiné la thèse. J ai beaucoup apprécié leur participation au jury de cette thèse malgré le long voyage. Ce travail a été réalisé au sein du Laboratoire d Informatique de l Université de Franche-Comté (LIFC). Je tiens donc à remercier les responsables de ce laboratoire de m avoir accueilli et donné l opportunité de réaliser ce travail de thèse. Un grand merci à tous les membres du Laboratoire d Informatique de l Université de Franche- Comté qui m ont procuré une ambiance chaleureuse pour effectuer mon travail ainsi qu un séjour extrêmement agréable. Merci à tous mes collègues de l équipe Réseaux de Capteurs : Hung-Cuong LE, Pamba CAPO- CHICHI, 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 réseaux de capteurs. Merci également à mon cher ami Dr Jalal JOMAAH pour son soutien indéfectible dans les moments difficiles. Merci à tous mes amis libanais, français et de toute nationalité qui m ont énormément soutenu aux moments les plus difficiles et qui étaient toujours près de moi. Je n oublierai jamais les moments qu on a passés ensemble. Un merci sans égal à ma famille au Liban pour son soutien, son encouragement et d être le pilier de ma réussite, merci à eux d avoir été à mon côté en France malgré mon absence prolongée surtout ma mère que j aime et j adore. Enfin et avant tout, le grand et le vrai merci à Dieu qui m a donnée la force et la vie pour accomplir cette tache. 3

4

5 Dédicace A celui que j aime 5

6

7 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] TABLE DES MATIÈRES Introduction Chapitre 1. Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques Introduction Les réseaux Ad-hoc Classification des protocoles de routage Ad-hoc Méthodes utilisées par les protocoles de routage Ad-hoc Distance Vector vs Link State Les réseaux de capteurs Le capteur Architecture physique d un capteur intelligent Caractéristiques principales d un capteur Définition d un réseau de capteurs sans fil Enjeux particuliers dans les réseaux de capteurs Conclusion Chapitre 2. Protocoles de routage dans les réseaux de capteurs Introduction Protocoles de routage non hiérarchiques Introduction DSDV (Destination Sequenced Distance Vector) GSR (Global State Routing) FSR (Fisheye State Routing) AODV (Ad-hoc On Demand Distance Vector) DSR (Dynamic Source Routing) OLSR (Optimized Link State Routing) GPSR (Greedy Perimeter Stateless Routing) SPIN (Sensor Protocol for Information via Negotiation) Protocoles de routage hiérarchiques

8 2.3.1 Introduction ZHLS (Zone-based Hierarchical Link State Protocol) CGSR (Clusterhead Gateway Switch Routing) CBRP (Cluster Based Routing Protocol) LEACH (Low Energy Adaptive Clustering Hierarchy) PEGASIS (Power-Efficient Gathering in Sensor Information Systems) TEEN (Threshold-sensitive Energy Efficient sensor Network protocol) APTEEN (Adaptive Threshold-sensitive Energy Efficient sensor Network protocol) VGA (Virtual Grid Architecture routing) CTLMN (Clustering Technique for Large multihop Mobile wireless Networks) HEED (Hybrid, Eenergy-Efficient, Distributed approach) CSOS (Cluster-based Self-Organization algorithm for wireless Sensor networks) SAR (Sensor Aggregates Routing) TTDD (Two-Tier Data Dissemination) Conclusion Chapitre 3. Protocole hiérarchique de routage basé sur les zones (ZHRP - Zonebased Hierarchical Routing Protocol) Introduction Algorithme distribué de partitionnement d un réseau de capteurs en zones Structure du paquet de contrôle échangé Description de l algorithme distribué de partitionnement en zones Maintenance de la topologie Construction de la table de routage intra-zone Construction de la table de routage inter-zones Structure du paquet échangé Algorithme distribué de construction des tables inter-zones Exemple de table inter-zones Scénario de routage de données Structure du paquet de données Détails de l application du scénario de routage Maintenance des tables de routage Conclusion

9 Chapitre 4. Expérimentations et résultats Introduction Le simulateur J-Sim L architecture détaillée de J-Sim Le composant Le port Le contrat Langage utilisé pour définir un scénario de simulation Modèle de transmission dans J-Sim Evaluation du protocole de routage proposé Evaluation du taux d erreur Evaluation du surcoût Evaluation de la durée de vie Evaluation de la taille de l espace de stockage Evaluation de la scalabilité Conclusion Chapitre 5. Mise en œuvre du protocole de routage Introduction Plateformes d exploitation pour les capteurs TinyOS SPOT (Small Programmable Object Technology) Description et mise en place du système Première étape : injection du protocole dans le capteur Deuxième étape : déploiement des capteurs Troisième étape : partitionnement du réseau en zones Quatrième étape : construction des tables de routage intra-zone Cinquième étape : construction des tables de routage inter-zones Fonctionnement du système Echange de données sans station de base Echange de données avec station de base Panne, apparition, et mobilité d un nœud Applications utilisant notre système

10 5.5.1 Guidage d un véhicule Détection de feu dans une forêt Conclusion Chapitre 6. Conclusion Perspectives Bibliographie

11 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Table des illustrations Figure 1.1: Réseau mobile Ad-hoc Figure 1.2 : Classification des réseaux Figure 1.3 : Fonctionnement d un capteur Figure 1.4 : Architecture physique d un capteur intelligent Figure 1.5 : Rayons de communication et de sensation d un capteur Figure 1.6 : Exemple de capteur intelligent MICA2 de Crossbow Figure 1.7 : Exemple de réseau de capteurs Figure 2.1 : Communication multi-sauts entre A et D Figure 2.2 : Technique "œil de poisson" dans le protocole FSR Figure 2.3 : Fonctionnement de la procédure de demande de route dans AODV Figure 2.4 : Diffusion pure et diffusion en utilisant les MPRs dans OLSR Figure 2.5 : Fonctionnement du protocole SPIN (48) Figure 2.6 : Architecture en cluster Figure 2.7 : Décomposition du réseau en zones dans ZHLS Figure 2.8 : Formation de clusters dans LEACH (55) Figure 2.9 : Classification des principales structures hiérarchiques d un réseau Figure 3.1 : Réseau de capteurs partitionné en zones Figure 3.2 : Taux des nœuds-invitant à proximité (Tr= 150m) Figure 3.3 : Taux des nœuds-invitant à proximité (Tr= 300m) Figure 3.4 : Partitionnement d un réseau en zones Figure 3.5: Algorithme de partionnement d un réseau en zones virtuelles Figure 3.6 : Exemple d une répartition de nœuds dans trois zones Figure 3.7 : Algorithme d envoi de la table inter-zones par le noeud-chef

12 Figure 3.8 : Algorithme de construction de la table inter-zones Figure 3.9 : Réseau découpé en 9 zones Figure 3.10 : Algorithme appliqué par le noeud source lors de l envoi d un paquet de données Figure 3.11: Algorithme appliqué lors de la réception d un paquet de données Figure 4.1 : Connexions entre composants dans J-Sim Figure 4.2 : Architecture interne d un noeud sensor dans J-Sim (78) Figure 4.3 : Champs de voisinage dans J-Sim Figure 4.4 : Taux d erreur pour 400 nœuds Figure 4.5 : Taux d erreur pour 500 nœuds Figure 4.6 : Taux d erreur pour 600 noeuds Figure 4.7 : Nombre de paquets envoyés durant la phase de partitionnement en zones pour 400 nœuds Figure 4.8 : Nombre de paquets envoyés durant la phase de partitionnement en zones pour 500 nœuds Figure 4.9 : Nombre de paquets envoyés durant la phase de partitionnement en zones pour 600 nœuds Figure 4.10 : Nombre de paquets reçus durant la phase de partitionnement en zones pour 400 nœuds Figure 4.11 : Nombre de paquets reçus durant la phase de partitionnement en zones pour 500 nœuds Figure 4.12 : Nombre de paquets reçus durant la phase de partitionnement en zones pour 600 nœuds Figure 4.13 : Nombre de paquets envoyés durant la phase de construction des tables de routage pour 400 nœuds Figure 4.14 : Nombre de paquets envoyés durant la phase de construction des tables de routage pour 500 nœuds Figure 4.15 : Nombre de paquets envoyés durant la phase de construction des tables de routage pour 600 nœuds Figure 4.16 : Nombre de paquets reçus durant la phase de construction des tables de routage pour 400 nœuds

13 Figure 4.17 : Nombre de paquets reçus durant la phase de construction des tables de routage pour 500 nœuds Figure 4.18 : Nombre de paquets reçus durant la phase de construction des tables de routage pour 600 nœuds Figure 4.19 : Pourcentage de la consommation énergétique de la batterie en variant le rayon de la zone R Figure 4.20 : Pourcentage de la consommation énergétique de la batterie en variant le nombre de zones zn Figure 4.21 : Pourcentage de la consommation énergétique de la batterie Figure 4.22 : Durée de vie du système avec des événements périodiques Figure 4.23 : Partitionnement d un réseau de 800 nœuds en 10 zones Figure 5.1 : Capteur SPOT fabriqué par SUN Microsystems (94) Figure 5.2 : Capture d écran de l outil SerialForwarder Figure 5.3 : Propagation des paquets d invitation dans le réseau Figure 5.4 : Echange de données entre les nœuds du réseau Figure 5.5 : Collecte des informations et envoi à la station de base Figure 5.6 : Système de guidage d un véhicule Figure 5.7 : Construction du chemin vers la destination Figure 5.8 : Déplacement du véhicule sur le chemin Figure 5.9 : Système de détection de feu dans une forêt Figure 5.10 : Détection d un nouveau feu lors de l intervention des pompiers

14

15 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Liste des tableaux Tableau 1 : Bilan des protocoles de routage hiérachique dans les réseaux Ad-hoc et de capteurs Tableau 2 : Champs du paquet ConstructZonesPacket Tableau 3 : Exemple de table-frontière BorderTable Tableau 4 : Table de routage intra-zone chez le nœud N Tableau 5 : Structure du paquet de contrôle InterZonesPacket Tableau 6 : Table inter-zones chez N6 appartenant à la zone Z Tableau 7 : Table de routage inter-zones des nœuds BORDER da la zone Z Tableau 8 : Structure d un paquet DataPacket Tableau 9 : Caractéristiques d un capteur MICA Tableau 10 : Nombre d'événements durant la simulation Tableau 11 : Caractéristiques d un capteur Tmote SKY Tableau 12 : Taille théorique de l espace de stockage (en octets) de la structure de données de routage Tableau 13 : Taille expérimentale de l espace de stockage (en octets) pour la structure de données de routage dans un réseau de 600 nœuds

16

17 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Introduction L évolution récente de la société s appuie sur des techniques de plus en plus tournées vers la communication, l image et la mobilité. Le téléphone portable et Internet sont les vecteurs principaux de cette révolution technologique. A côté de ces techniques plutôt liées aux loisirs se développent également des dispositifs pour améliorer notre connaissance du monde extérieur. Les informations recueillies dans la nature par exemple, vont être récupérées pour être intégrées au processus de décision. Le besoin d échange rapide d informations et le développement des communications ont abouti à la création d Internet qui rend accessible au monde entier une grande quantité de données et de services. Internet suscite une passion croissante, tant dans le domaine de la recherche, de l éducation que celui des affaires. Ainsi le nombre de personnes qui accèdent à Internet pour leur travail, leurs études ou leurs loisirs augmente sans cesse, de même que les services offerts sur ce réseau (messagerie électronique, moteur de recherche, e-commerce, e-learning, etc.). Dans un avenir proche, Internet va enrichir ses bases de données avec des informations temps réel directement issues de phénomènes naturels. De plus, Internet ne va plus relier seulement les hommes, mais également les objets. Toute cette évolution ne pourrait se réaliser sans une évolution dans le domaine de la communication principalement sans fil et l informatique mobile gagne de plus en plus de popularité. Les dispositifs mobiles deviennent de plus en plus nombreux (PDA, laptops, etc.), ceci permettant l apparition de réseaux locaux sans fil dans les entreprises et même chez les particuliers. La communication au sein de l environnement non-filaire se base essentiellement sur la transmission radio. Cependant cet environnement engendre de nouveaux problèmes tels que les déconnexions fréquentes, les débits variables, et la quantité d énergie limitée des clients mobiles. Mais ces environnements sans fil offrent une grande flexibilité d emploi, et permettent la mise en réseau de sites dont le câblage eut été difficile et coûteux à réaliser, ou même impossible. Les progrès technologiques dans les domaines de la microélectronique, des communications sans 17

18 Introduction fil, couplés aux efforts de miniaturisation et la réduction des coûts de production des composants électroniques, ont permis le développement de nouvelles générations de réseaux sans fils. Ces derniers offrent beaucoup d avantages notamment en termes de déploiement. Cependant, de nouveaux problèmes surgissent qui rendent les réseaux sans fils moins fiables que les réseaux filaires. Aussi de nouvelles techniques doivent être mises en œuvre pour pallier ces problèmes. Des réseaux pour téléphones mobiles aux réseaux locaux sans fil en passant par les réseaux adhoc, la recherche aujourd hui s est beaucoup focalisée sur les réseaux de capteurs sans fil (Wireless Sensor Network - WSN). Ceux-ci sont composés d un grand nombre de nœuds communicants et distribués sur une zone donnée afin de mesurer une grandeur physique ou surveiller un évènement. Dans un tel réseau, chaque nœud est un dispositif électronique qui possède une capacité de calcul, de stockage, de communication et d énergie. Les caractéristiques particulières des WSNs modifient les critères de performances par rapport aux réseaux sans fil traditionnels. Dans les réseaux locaux filaires ou les réseaux cellulaires, les critères les plus pertinents sont le débit, la latence et la qualité de service car les nouvelles activités telles que le transfert d images, le transfert de vidéos, et la navigation sur Internet requièrent un débit important, une faible latence, et une bonne qualité de service. En revanche, dans les réseaux de capteurs conçus pour surveiller une zone d intérêt, la longévité du réseau est fondamentale. De ce fait, la conservation de l énergie est devenue un critère de performance prépondérant et se pose en premier lieu tandis que les autres critères comme le débit ou l utilisation de la bande passante sont devenus secondaires. La technique des WSNs peut être appliquée dans de nombreux domaines : surveillance des déplacements des véhicules en zone hostile, observation de la vie des espèces rares, surveillance de la structure des infrastructures, optimisation de traitement pour les patients etc. Le routage est fondamental dans ce type de réseau car il n existe pas d infrastructure qui gère les informations échangées entre les différents nœuds du réseau (comme par exemple les routeurs dans les réseaux filaires). En effet, c est à chaque nœud du réseau de jouer le rôle d un routeur. Ainsi, tous les nœuds collaborent afin de router une information vers une certaine destination. L objectif de cette thèse est de traiter le problème du routage dans les réseaux de capteurs, surtout ceux à taille importante. Le souci principal est de prolonger la vie du système en économisant l énergie dépensée par chaque capteur du réseau. Pour cela, nous avons proposé un algorithme de partitionnement du réseau en zones (ensemble de nœuds), un algorithme de construction des tables de routage à l intérieur de la zone (intra-zone) et entre les zones (interzones), et un algorithme de routage de données entre les nœuds basé sur la topologie en zones. Le partitionnement du réseau est basé sur le nombre de sauts. Contrairement à la plupart des algorithmes de partitionnement (par exemple la clusterisation), cet algorithme n exige aucune information sur le réseau (position géographique des nœuds, état des liens, énergie des nœuds, etc.). L algorithme de construction des tables de routage (intra-zone et inter-zones) est basé sur l algorithme Distance Vector (DV) qui a été modifié pour répondre aux hypothèses et contraintes. L algorithme de routage de données se base sur l architecture en zones. Le routage se réalise à deux niveaux : à l intérieur de la zone et entre les zones. Ces algorithmes, constituant un protocole de routage appelé ZHRP (Zone-based Hierarchical Routing Protocol), a été évalué à l aide du 18

19 simulateur J-Sim. Les résultats obtenus ont montré l efficacité du protocole surtout dans les réseaux de capteurs à grande échelle. Cette thèse est organisée en 6 chapitres. Le premier chapitre introduit la thèse et positionne le sujet dans la thématique des réseaux sans fil. Nous décrivons l architecture d un capteur et nous présentons les principes et les caractéristiques des réseaux Ad-hoc et des réseaux de capteurs (sous classes des réseaux Ad-hoc) aussi que ses domaines d application. Dans le deuxième chapitre, nous donnons un état de l art sur les protocoles de routage dans les réseaux Ad-hoc et nous focalisons notre présentation sur les protocoles de routage dans les réseaux de capteurs. Le troisième chapitre présente notre protocole de routage ZHRP. Nous montrons d abord en détail un algorithme distribué de partitionnement d un réseau de capteur en zones, basé sur le nombre de sauts. Dans cet algorithme, nous n utilisons aucune information du réseau pour la construction de la topologie hiérarchique. Nous essayons de minimiser les échanges entre les nœuds afin d économiser leur énergie. Ensuite, nous détaillons les phases de construction des tables de routage en se basant sur l algorithme DV qui est simple et efficace dans les petits réseaux. A la fin de ce chapitre, nous montrons l algorithme de routage des données entre les nœuds du réseau en se basant sur l architecture hiérarchique ainsi que la maintenance du réseau lors d une panne, de l apparition ou de la mobilité d un nœud. Dans le quatrième chapitre nous présentons le simulateur que nous avons choisi J-Sim. L avantage de ce simulateur par rapport aux autres est qu il est open source. Les résultats obtenus montrent que notre algorithme se comporte bien. En effet, nous avons évalué le protocole en utilisant cinq métriques : le taux d erreur, le surcoût, la consommation énergétique, la scalabilité, et l espace de stockage. Les résultats des simulations ont montré que le taux d erreur, défini comme le nombre de nœuds non affectés à aucune zone, est égal à zéro dans la plupart des cas. Ces résultats montrent aussi un faible surcoût pour construire la topologie hiérarchique et les tables de routage, d où la faible consommation énergétique. De même, nous avons montré que notre protocole se comporte bien dans les réseaux à grande échelle (500 et 600 nœuds). Enfin, nous avons calculé l espace 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é d une implémentation de notre proposition dans le chapitre 5 à l aide de capteurs MICA2 et du système d exploitation Tiny-OS. Nous décrivons le comportement du système et nous détaillons deux applications réelles. Nous concluons cette thèse dans le chapitre 6 et donnons quelques perspectives de travail. En particulier, nous proposons de continuer ce travail en une approche de routage qui s adapte aux applications où le Sink est mobile sur un chemin non défini préalablement. Une autre perspective consiste à proposer une technique pour mettre en veille un ensemble de nœuds ou une zone afin de prolonger la vie du système. Nous proposons également d intégrer dans notre protocole une méthode pour l agrégation des données collectées. 19

20

21 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Chapitre 1. Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques 1.1 Introduction Comme nous l avons vu dans les pages précédentes, l apparition récente des communications sans fil accessibles sur des portables, l évolution des dispositifs de calcul et les progrès dans l infrastructure de communication ont abouti à la croissance rapide des réseaux sans fil. Ceux-ci sont géographiquement étendus (GSM, Wimax), locaux (802.11, Zigbee) ou personnels (Bluetooth). On trouve également les NFC (Near Field Communication) utilisés pour de nouveaux services (paiement des transports, affichage d informations contextuelles ) et des RFID qui permettent d optimiser le fonctionnement des processus internes de l entreprise, comme la logistique, la traçabilité ou la production par exemple. On assiste à la croissance exponentielle des réseaux cellulaires qui sont basés sur la combinaison de technologies câblées et sans fil. Dans les réseaux cellulaires, comme les GSM, chaque antenne couvre un territoire défini et lors des déplacements de l utilisateur le téléphone mobile change de cellule. On dit que ce type de réseau a une infrastructure fixe bien définie. Lorsque cette infrastructure pour gérer le réseau n existe pas, on parle alors de réseau Ad-hoc. Un tel réseau se caractérise donc par l absence d infrastructure pour les nœuds qui le composent. Les nœuds jouent donc un rôle primordial dans le transfert des informations et la gestion du routage de celles-ci, devant entre autre gérer les reconfigurations topologiques. Cette caractéristique, couplée à la forte implication des nœuds dans le transfert des informations via des technologies sans fil, rendent la qualité de service, le routage et la sécurité beaucoup plus complexes à réaliser. 1.2 Les réseaux Ad-hoc Un réseau sans fil (ou non filaire) est un réseau informatique qui connecte les différents équipements entre eux par ondes radio. La norme la plus utilisée actuellement pour les réseaux 21

22 Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques sans fil privés est la norme IEEE Le réseau filaire relie les équipements par des câbles classiques. Ainsi, il est possible de créer un réseau mixte qui utilise la communication filaire et non filaire. Le principal défi d un réseau filaire ou non filaire est sa gestion qui se complique suivant que l on est en mode sans infrastructure ou en mode avec infrastructure. Deux types de dispositifs composent un réseau : d une part, il s agit des équipements qui utilisent le réseau afin de pouvoir communiquer de l information et d autre part, des équipements qui aident à la communication. On parle d appareils téléphoniques vs les commutateurs (switch), dans la téléphonie, ou d ordinateurs, de serveurs vs les routeurs, les commutateurs ou les concentrateurs (hub) dans l internet ou encore de téléphones portables vs les points d accès dans les réseaux cellulaires. Ces types de réseaux utilisent le mode avec infrastructure puisque les équipements ont besoin d une base architecturale pour gérer le réseau. Dans le réseau sans infrastructure, il n y a pas besoin d une infrastructure préexistante (point d accès par exemple) pour gérer le réseau : chaque membre du réseau peut recevoir et envoyer ses informations mais il agit aussi comme un routeur pour transférer d autres données aux autres membres du réseau. Ce type de réseau est appelé réseau Ad-hoc. Actuellement, le nombre d utilisateurs du réseau cellulaire approche des quatre milliards dans le monde. Bien que les efforts de recherche et de développement consacrés aux réseaux sans fil traditionnels soient toujours considérables, l intérêt de la communauté scientifique et industrielle dans le domaine des télécommunications a récemment changé avec des scénarios plus stimulants dans lesquels un groupe d unités mobiles équipées d émetteurs-récepteurs de radio communiquent sans aucune infrastructure fixe. Figure 1.1: Réseau mobile Ad-hoc Plusieurs systèmes utilisent déjà le modèle cellulaire et connaissent une très forte expansion à l heure actuelle mais requièrent une importante infrastructure logistique et matérielle fixe. La contrepartie des réseaux cellulaires sont les réseaux mobiles Ad-hoc 1. Un réseau mobile Ad-hoc peut être défini comme une collection d entités mobiles interconnectées par une technologie sans fil formant un réseau temporaire sans l aide de toute administration ou de tout support fixe (voir la 1 Appelé généralement MANET (Mobile Ad hoc NETwork) 22

23 Les réseaux Ad-hoc Figure 1.1). Une définition de ces réseaux est donnée formellement dans RFC2501 (1) : «Un réseau mobile Ad-hoc comprend des plates-formes mobiles (par exemple, un routeur interconnectant différents hôtes et équipements sans fil) appelées nœuds qui sont libres de se déplacer sans contrainte. Un réseau mobile Ad-hoc est donc un système autonome de nœuds mobiles. Ce système peut fonctionner d une manière isolée ou s interfacer à des réseaux fixes au travers de passerelles». C est la caractéristique qui distingue les réseaux mobiles Ad-hoc des réseaux sans fil plus traditionnels comme les réseaux cellulaires et les réseaux locaux sans fil. Aucune supposition ou limitation n est faite sur la taille du réseau. Cela veut dire qu il est possible que ce type de réseau ait une taille très importante. La Figure 1.2 résume, de façon hiérarchique, les types des réseaux avec leurs noms (les feuilles de l hiérarchie). Nous citons un exemple pour chaque type de réseau : LAN (Local Area Network) et WAN (Wired Area Network) plusieurs équipements (ordinateurs, imprimantes, serveurs, etc.) connectés ensemble via des câbles, Ad-hoc filaire deux ordinateurs connectés via un câble, WLAN (Wireless Local Area Network) le réseau cellulaire (GSM) composé de téléphones mobiles sans fil et des stations fixes, MANET (Mobile Ad-hoc NETwork) plusieurs équipements mobiles connectés via le radio, Ad-hoc non filaire plusieurs équipements fixes connectés via le radio. réseau 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 réseaux 23

24 Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques Dans la suite de notre document, lorsque nous parlons d un réseau Ad-hoc nous sous-entendons un réseau Ad-hoc non filaire. En effet, un réseau Ad-hoc filaire (des équipements connectés avec fils) n a pas beaucoup d intérêt et par conséquent, son utilisation est très rare. Une application très importante des réseaux Ad-hoc est celle de la mise en place rapide d un réseau de communication dans le cas de catastrophe majeure sur des zones dépourvues d infrastructures ou encore dans le cas où l infrastructure existante est hors service, voire complètement détruite. Les exemples les plus réalistes 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 réseau de communication pour coordonner les recherches, les informations logistiques, voire désenclaver les populations isolées en leur offrant rapidement un moyen de communication. Une autre application concerne le domaine militaire, puisqu un tel réseau peut être utilisé pour assurer la liaison entre les différentes unités d une armée. Vu les caractéristiques et les limitations qu engendre un réseau Ad-hoc, plusieurs problèmes ont été posés pour ce type de réseaux : problème d acheminement de l information, problème de sources d énergies (capacité des batteries), l interopérabilité avec d autres types de réseaux, etc. Nous nous sommes intéressés aux problématiques posées par le routage dans ce type de réseaux et aux solutions proposées Classification des protocoles de routage Ad-hoc Suivant la méthode de création et la maintenance des routes lors de l acheminement des paquets, les protocoles de routage dans les réseaux Ad-hoc peuvent être classés en trois catégories : proactifs, réactifs et hybrides. a) Protocoles de routage proactifs Ils sont basés sur le même principe de routage que les réseaux filaires. Les routes dans ce type de routage sont calculées à l avance. Chaque nœud met à jour plusieurs tables de routage par échange de paquets de contrôle entre voisins. En effet, si un nœud veut communiquer avec un autre, il a la possibilité de consulter localement la table de routage et de créer le chemin dont il a besoin. Le besoin de conserver et de contrôler la validité des tables de routages en permanence (comprenant en outre des informations qui ne seront sans doute pas utilisées) est le principal inconvénient des protocoles proactifs. Par contre, ils présentent l important avantage de ne nécessiter aucun délai avant de transmettre un paquet puisque la route est déjà connue. OLSR [ (2), (3)] et FSR [ (4), (5)] sont deux exemples de protocoles proactifs que nous décrirons plus tard. b) Protocoles de routages réactifs Contrairement aux protocoles proactifs, les protocoles réactifs ne calculent la route que sur demande. Si un nœud source a besoin d envoyer un message à un nœud destination, alors il envoie une requête à tous les membres de réseau. Après la réception de la requête, le nœud destination envoie un message réponse qui remonte vers la source (méthode Backward Learning (6)). Cependant, le routage à la demande génère une lenteur à cause de la recherche des routes. Cela 24

25 Les réseaux Ad-hoc peut entraîner une dégradation des performances des applications. Ce type de protocole présente l inconvénient d être très coûteux en transmission de paquets lors de la détermination des routes mais a l avantage de ne pas avoir à maintenir des informations inutilisées dans les tables de routage. AODV (6) et DSR [ (7), (8)] sont deux exemples de protocoles réactifs qui seront décrits ultérieurement. c) Protocoles de routage hybrides Les protocoles de routages hybrides ou «mixtes» combinent les deux types de routages précédents (proactif et réactif). Le protocole proactif est appliqué dans un périmètre réduit autour de la source (nombre limité de voisins), tandis que le protocole réactif est appliqué au delà de ce périmètre (les voisins lointains). Cette combinaison est réalisée dans le but d exploiter les avantages de chaque méthode et de contourner leurs limitations. ZRP et CBRP (9), sont deux exemples de protocoles hybrides que nous décrirons plus tard Méthodes utilisées par les protocoles de routage Ad-hoc Le protocole de routage doit garder la trace des changements sur le réseau et doit partager ces changements avec des nœuds dans le réseau. La plupart des protocoles de routage Ad-hoc utilise deux méthodes majeures : vecteur de distance (Distance Vector) et état de lien (Link State). Par la suite, nous détaillerons chaque méthode, présentant ses avantages et ses inconvénients, et nous réaliserons une comparaison entre les deux. a) Distance Vector (DV) Les protocoles de routage à base de la méthode DV [ (10), (11)] établissent une table de routage recensant le «coût» de chacune des routes du réseau puis transmettent cette table périodiquement aux nœuds voisins. Au début, chaque nœud détecte 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 reçues (ajout et modification d une entrée) et convergent jusqu à ce que la structure du réseau à travers ces tables se stabilise. Chaque entrée de la table de routage est un triplet (nœud destinataire, nœud suivant, métrique) où la métrique est le coût de la route pour atteindre le nœud destinataire en passant par le nœud suivant. La métrique utilisée peut être le nombre de sauts, le délai d acheminement, le nombre total de paquets en file d attente pour ce parcours, ou un critère semblable (12). Les mises à jour régulières entre les nœuds permettent de communiquer les modifications de topologie. Les protocoles de routage à vecteur de distance sont conçus pour être exécutés sur de petits réseaux (en général moins de 100 nœuds). DV utilise l algorithme Bellman-Ford (13) pour calculer le meilleur chemin. Ces protocoles sont généralement plus faciles à configurer et exigent moins de maintenance que les protocoles utilisant la méthode d état de lien. Si un nœud tombe en panne, il n émet plus périodiquement. Ses voisins s en rendent compte et mettent leur métrique pour ce nœud à l infini. La construction des tables de routage est réalisée par vagues, de manière distribuée, ce qui peut 25

26 Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques entraîner des boucles de routage. Une boucle de routage est une route diffusée pour des paquets qui n atteignent jamais leur destination : ils passent de façon répétée par la même série de nœuds du réseau. Des boucles de routage peuvent se produire si la convergence lente d un réseau avec une nouvelle configuration entraîne des entrées de routage incohérentes. Les tables de routage ne peuvent plus assurer alors leur fonction pour une ou plusieurs destinations, et ainsi tous les paquets destinés à une entrée erronée seront transmis mais ne parviendront jamais au nœud destination et circuleront sur une boucle constituée de plusieurs nœuds (11). Une métrique de mesure infinie est le résultat d une boucle de routage qui engage les nœuds à incrémenter à l infini la métrique de mesure. Pour résoudre ce problème, plusieurs méthodes ont été proposées (11) : Sequence number chaque entrée de la table de routage possède un numéro de séquence. Par conséquent, chaque nœud peut rapidement distinguer l ancienne route de celle nouvelle, ce qui évite la génération de la boucle de routage (14). Maximum Count si ce compteur maximum est défini, cela veut dire que le bouclage à l infini s arrête à ce nombre maximum. RIP (10) définit le compteur maximum à 16. Route Poisoning Les nœuds envoient des mises à jour avec une métrique 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 prévenir contre les mauvaises mises à jour des routes invalidées. Le «holddown timer» est déclenché lorsqu un «timer» d une route particulière est expiré ou il n est plus atteint. Lorsque le «holddown timer» atteint le zéro, la route est supprimée et le nœud est considéré défaillant. Triggered Update normalement, les tables de routages sont envoyées périodiquement mais un «triggered update» sera immédiatement envoyé en réponse à un changement de topologie du réseau. Dès qu un nœud détecte un changement sur le réseau il envoie immédiatement une mise à jour aux nœuds voisins qui à leur tour notifient immédiatement leurs voisins adjacents de ce changement. RIP (10), DSDV (14) et AODV (6) sont des protocoles de routage qui utilisent la méthode DV. b) Link State (LS) Les protocoles de routage utilisant la méthode LS (15) écoutent le réseau en continu afin de recenser les différents éléments qui l entourent. Chaque nœud a une vue globale du réseau représenté par un graphe. A partir de ces informations (temps, nombre de sauts, distance réelle, délai de transmission, fiabilité, etc.), chaque nœud calcule le plus court chemin (à l aide de l algorithme de Dijkstra (16)) vers les nœuds du réseau et diffuse cette information sous forme de paquets de mise à jour. Les protocoles à état de lien ont été conçus pour pallier les limitations des protocoles de routage utilisant le vecteur de distance. Ils ont pour avantage de répondre rapidement aux moindres changements sur le réseau en envoyant des mises à jour déclenchées uniquement après qu une modification soit survenue. 26

27 Les réseaux Ad-hoc Dès qu un nœud détecte la modification d une liaison ou d une route, il crée une mise à jour de routage à état de lien (LSA, link-state advertisement) concernant cette liaison. Cette mise à jour LSA est ensuite transmise à tous les nœuds voisins. Chacun d eux en prend une copie, met à jour sa base de données (graphe) à état de lien et transmet la mise à jour LSA aux autres nœuds voisins. Cette diffusion de mises à jour LSA est nécessaire afin que tous les nœuds puissent créer des bases de données transcrivant de manière précise la topologie du réseau et mettre à jour leur table de routage. Les algorithmes à état de lien se servent généralement de leurs bases de données (graphe) pour créer des entrées dans la table de routage qui privilégient le chemin le plus court. Chaque nœud construit enfin sa table de routage en calculant les plus courts chemins vers tous les autres nœuds (à l aide de l algorithme de Dijkstra). OSPF [ (17), (18)] et OLSR [ (2), (3)] sont deux protocoles de routage basés sur LS Distance Vector vs Link State Il y a deux grandes différences entre DV et LS. La première est que DV échange les mises à jour de routage périodiquement même s il n y a pas de changements de topologie. Cela maximise le temps de convergence et augmente les risques de boucles de routage. D autre part, LS ne déclenche pas d envois de mises à jour de routage que lors du changement de topologie. Après la première inondation, des mises à jour d état des liens seront envoyées à tous les autres nœuds. Ceci permet de minimiser le temps de convergence et c est la raison pour laquelle il n y a aucune chance de boucles de routage. La deuxième différence est que dans DV, un nœud se base sur les informations de ses voisins connectés directement afin de calculer et d accumuler des informations sur les routes. Au contraire, dans LS, un nœud ne se base pas uniquement sur l information de ses voisins pour calculer l information sur la route. LS a un système de bases de données qui est utilisé afin de calculer le meilleur chemin pour des destinations dans le réseau en utilisant l algorithme de Dijkstra. Pour cela, DV nécessite très peu de chargements depuis la mémoire et de puissance du processeur par rapport à LS. Dans la section suivante, nous décrirons un réseau Ad-hoc particulier : le réseau de capteurs dont les nœuds possèdent de faibles capacités d énergie, de stockage et de bande passante. 1.3 Les réseaux de capteurs Le capteur a) Modèle d un instrument de mesure Dans son ouvrage sur l instrumentation industrielle, l électronicien Georges Asch (19), a modélisé très précisément la notion d instrument de mesure, et donc celle de capteur (Figure 1.3). La grandeur physique objet de la mesure, nommée mesurande (m), est appréhendée par diverses opérations expérimentales, que l on regroupe sous le terme de mesurage, qui dans un grand 27

28 Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques 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 à l action du mesurande, non électrique, produit la caractéristique électrique : s=f(m). Or toutes les lois physiques interagissent au sein des matériaux, donc le capteur est obligatoirement sensible à d autres grandeurs physiques, secondaires, dites grandeurs d influence (20). La caractéristique devient alors, en tenant compte des grandeurs d influence g1, g2, : s=f(m, g1, g2,...). Les principales grandeurs d influence sont la température, l accélération, les vibrations, l humidité, les champs magnétiques (20). m s Mesurande (m) t Capteur Grandeur électrique (s) t Figure 1.3 : Fonctionnement d un capteur Donc, un capteur est un dispositif équipé de fonctionnalités de sensation avancées. Il mesure ou détecte un événement réel, comme le mouvement, la chaleur ou la lumière et convertit la valeur mesurée dans une représentation analogique ou numérique. Il prélève des informations et élabore à partir d une grandeur physique (information d entrée), une autre grandeur physique de nature électrique. b) Le capteur intelligent Les capteurs intelligents (Smart Sensors) sont des dispositifs matériels dans lesquels coexistent le(s) capteur(s) et les circuits de traitement et de communication. Leurs relations avec des couches de traitement supérieures vont bien au-delà d une simple «transduction de signal». Les capteurs intelligents sont des «capteurs d informations» et non pas simplement des capteurs et des circuits de traitement du signal juxtaposés. De plus, les «Smart Sensors» ne sont pas des dispositifs banalisés car chacun de leurs constituants a été conçu dans l objectif d une application bien spécifique (20) Architecture physique d un capteur intelligent Un capteur intelligent est composé de 4 unités (voir la Figure 1.4) : l unité d acquisition composée d un capteur qui obtient des mesures sur les paramètres environnementaux et d un convertisseur Analogique/Numérique qui convertit l information relevée et la transmet à l unité de traitement. l unité de traitement composée d un processeur et d une mémoire intégrant un système d exploitation spécifique (TinyOS (21), par exemple). Cette unité possède deux interfaces, une interface pour l unité d acquisition et une interface pour l unité de communication. Elle 28

29 Les réseaux de capteurs acquiert les informations en provenance de l unité d acquisition et les envoie à l unité de communication. Cette unité est chargée aussi d exécuter les protocoles de communications qui permettent de faire collaborer le capteur avec d autres capteurs. Elle peut aussi analyser les données captées. l unité de communication unité responsable de toutes les émissions et réceptions de données via un support de communication radio. Elle peut être de type optique (comme dans les capteurs Smart Dust (22)), ou de type radiofréquence (MICA2 (23), par exemple). la batterie un capteur est muni d une batterie pour alimenter tous ses composants. Cependant, à cause de sa taille réduite, la batterie dont il dispose est limitée et généralement irremplaçable. Pour cela, l énergie est la ressource la plus précieuse puisqu elle influe directement sur la durée de vie des capteurs. Il existe des capteurs qui sont dotés d autres composants additionnels comme le système de positionnement GPS (Global Positioning System) et un mobilisateur lui permettant le déplacement. Dans le reste de notre rapport, lorsque nous parlerons de capteur nous sous-entendrons capteur «intelligent» avec un système de capture et les circuits de traitement et de communication. Unité d acquisition Processeur Mémoire Unité de traitement Unité de communication Batterie Figure 1.4 : Architecture physique d un capteur intelligent Caractéristiques principales d un capteur Deux entités sont fondamentales dans le fonctionnement d un capteur : l unité d acquisition qui est le cœur physique permettant la prise de mesure et l unité de communication qui réalise la transmission de celle-ci vers d autres dispositifs électroniques. Ainsi, fonctionnellement chaque capteur possède un rayon de communication (Rc) et un rayon de sensation (Rs). La Figure 1.5 montre les zones définies 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). D autre part, la zone de sensation est la zone où le capteur A peut capter l événement ( (24), (25)). 29

30 Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques Rs B Rc A C Zone de communication Zone de sensation Figure 1.5 : Rayons de communication et de sensation d un capteur En effet, pour qu un capteur ait une portée de communication suffisamment grande, il est nécessaire d utiliser un signal assez puissant. Cependant, l énergie consommée 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 d élargir/réduire le rayon de communication et en conséquence 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

31 Les réseaux de capteurs Définition d un réseau de capteurs sans fil Les réseaux de capteurs sans fil (WSNs 2 ) sont un type particulier de réseau Ad-hoc, dans lesquels les nœuds sont des «capteurs intelligents». Ils se composent généralement d un grand nombre de capteurs communicants entre eux via des liens radio pour le partage d information et le traitement coopératif. Dans ce type de réseau, les capteurs échangent des informations par exemple sur l environnement pour construire une vue globale de la région contrôlée, qui est rendue accessible à l utilisateur externe par un ou plusieurs nœud(s). Les données collectées par ces capteurs sont acheminées directement ou via les autres capteurs de proche en proche à un «point de collecte», appelé station de base (ou SINK s il s agit d un nœud). Cette dernière peut être connectée à une machine puissante via internet ou par satellite. En outre, l utilisateur peut adresser ses requêtes aux capteurs en précisant l information d intérêt. Internet, satellite, Station de base Zone d intérêt Utilisateur Station de base Capteur Figure 1.7 : Exemple de réseau de capteurs Un exemple de réseaux de capteurs est fourni dans la Figure 1.7 : les capteurs sont déployés d une manière aléatoire dans une zone d intérêt, et une station de base, située à l extrémité de cette zone, est chargée de récupérer les données collectées par les capteurs. Lorsqu un capteur détecte un événement pertinent, un message d alerte est envoyé à la station de base par le biais d une communication entre les capteurs. Les données collectées sont traitées et analysées par des machines puissantes. Les réseaux de capteurs viennent en soutien de l environnement et de l industrie grâce aux récents développements réalisés dans le domaine des techniques sans fils. Depuis quelques décennies, le besoin d observer et de contrôler des phénomènes physiques tels que la température, la pression ou encore la luminosité est essentiel pour de nombreuses applications industrielles et scientifiques. 2 Wireless Sensor Networks 31

32 Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques a) Domaines d application des réseaux de capteurs La miniaturisation des capteurs, le coût de plus en plus faible, la large gamme des types de capteurs disponibles ainsi que le support de communication sans fil utilisé, permettent aux réseaux de capteurs de se développer dans plusieurs domaines d application. Ils permettent aussi d étendre les applications existantes. Les réseaux de capteurs peuvent se révéler très utiles dans de nombreuses applications lorsqu il s agit de collecter et de traiter des informations provenant de l environnement. Parmi les domaines où ces réseaux peuvent offrir les meilleures contributions, nous citons les domaines : militaire, surveillance, environnemental, médical, domestique, commercial, etc. (28). Applications militaires Le faible coût et le déploiement rapide sont des caractéristiques qui ont rendu les réseaux de capteurs efficaces pour les applications militaires. Plusieurs projets ont été lancés pour aider les unités militaires dans un champ de bataille et protéger 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 l un des premiers projets dans les années 80 ayant utilisé les réseaux de capteurs pour rassembler des données distribuées. Les chercheurs du laboratoire national Lawrence Livermore ont mis en place le réseau WATS (Wide Area Tracking System) (30). Ce réseau est composé de détecteurs des rayons gamma et des neutrons pour détecter et dépister les dispositifs nucléaires. Il est capable d effectuer la surveillance constante d une zone d intérêt. Il utilise des techniques d agrégation de données pour les rapporter à un centre intelligent. Ces chercheurs ont mis en place ensuite un autre réseau appelé JBREWS (Joint Biological Remote Early Warning System) (31) pour avertir les troupes dans le champ de bataille des attaques biologiques possibles. Un réseau de capteurs peut être déployé dans un endroit stratégique ou hostile, afin de surveiller les mouvements des forces ennemies, ou analyser le terrain avant d y envoyer des troupes (détection des armes chimiques, biologiques ou radiations). L armée américaine a réalisé des tests dans le désert de Californie. Applications à la surveillance L application des réseaux de capteurs dans le domaine de la sécurité peut diminuer considérablement les dépenses financières consacrées à la sécurisation des lieux et des êtres humains. Ainsi, l intégration des capteurs dans de grandes structures telles que les ponts ou les bâtiments aidera à détecter les fissures et les altérations dans la structure suite à un séisme ou au vieillissement de la structure. Le déploiement d un réseau de capteurs de détection de mouvement peut constituer un système d alarme qui servira à détecter les intrusions dans une zone de surveillance. Applications environnementales Le contrôle des paramètres environnementaux par les réseaux de capteurs peut donner naissance à plusieurs applications. Par exemple, le déploiement des thermo-capteurs dans une forêt peut aider à détecter un éventuel début de feu et par suite faciliter la lutte contre les feux de forêt avant leur propagation. Le déploiement des capteurs chimiques dans les milieux urbains peut aider à 32

33 Les réseaux de capteurs détecter la pollution et analyser la qualité d air. De même leur déploiement dans les sites industriels empêche les risques industriels tels que la fuite de produits toxiques (gaz, produits chimiques, éléments radioactifs, pétrole, etc.). Dans le domaine de l agriculture, les capteurs peuvent être utilisés pour réagir convenablement aux changements climatiques par exemple le processus d irrigation lors de la détection de zones sèches dans un champ agricole. Cette expérimentation a été réalisée par Intel Research Laboratory and Agriculture and Agri-Food Canada sur une vigne à British Columbia. Applications médicales Dans le domaine de la médecine, les réseaux de capteurs peuvent être utilisés pour assurer une surveillance permanente des organes vitaux de l être humain grâce à des micro-capteurs qui pourront être avalés ou implantés sous la peau (surveillance de la glycémie, détection de cancers, etc.). Ils peuvent aussi faciliter le diagnostic de quelques maladies en effectuant des mesures physiologiques telles que : la tension artérielle, battements du cœur, etc. à l aide des capteurs ayant chacun une tâche bien particulière. Les données physiologiques collectées par les capteurs peuvent être stockées pendant une longue durée pour le suivi d un patient (32). D autre part, ces réseaux peuvent détecter des comportements anormaux (chute d un lit, choc, cri, etc.) chez les personnes dépendantes (handicapées ou âgées). Applications domestiques Avec le développement technologique, les capteurs peuvent être embarqués dans des appareils, tels que les aspirateurs, les fours à micro-ondes, les réfrigérateurs, les magnétoscopes, etc. (33). Ces capteurs embarqués peuvent interagir entre eux et avec un réseau externe via Internet pour permettre à un utilisateur de contrôler les appareils domestiques localement ou à distance. Le déploiement des capteurs de mouvement et de température dans les futures maisons dites intelligentes permet d automatiser plusieurs opérations domestiques telles que : la lumière s éteint et la musique s arrête quand la chambre est vide, la climatisation et le chauffage s ajustent selon les points multiples de mesure, l alarme est déclenchée par le capteur anti-intrusion quand un étranger veut pénétrer dans la maison. Applications commerciales Il est possible d intégrer des capteurs au processus de stockage et de livraison dans le domaine commercial. Le réseau ainsi formé pourra être utilisé pour connaître la position, l état et la direction d un paquet. Il devient alors possible pour un client qui attend la réception d un paquet, d avoir un avis de livraison en temps réel et de connaître la localisation actuelle du paquet. Pour les entreprises manufacturières, les réseaux de capteurs permettront de suivre le procédé de production à partir des matières premières jusqu au produit final livré. Grâce aux réseaux de capteurs, les entreprises pourraient offrir une meilleure qualité de service tout en réduisant leurs coûts (34). b) Caractéristiques des réseaux de capteurs sans fil Un réseau de capteurs présente les caractéristiques suivantes : 33

34 Réseaux Ad-hoc et réseaux de capteurs : principes et caractéristiques absence d infrastructure les réseaux Ad-hoc en général, et les réseaux de capteurs en particulier se distinguent des autres réseaux par la propriété d absence d infrastructure préexistante et de tout genre d administration centralisée. taille importante un réseau de capteurs peut contenir des milliers de nœuds. interférences les liens radio ne sont pas isolés, deux transmissions simultanées sur une même fréquence, ou utilisant des fréquences proches, peuvent interférer. topologie dynamique les capteurs peuvent être attachés à des objets mobiles qui se déplacent d une façon libre et arbitraire rendant ainsi la topologie du réseau fréquemment changeante. sécurité physique limitée les réseaux de capteurs sans fil sont plus touchés par le paramètre de sécurité que les réseaux filaires classiques. Cela se justifie par les contraintes et limitations physiques qui font que le contrôle des données transférées doit être minimisé. bande passante limitée une des caractéristiques primordiales des réseaux basés sur la communication sans fil est l utilisation d un médium de communication partagé. Ce partage fait que la bande passante réservée à un nœud est limitée. contrainte d énergie, de stockage et de calcul - la caractéristique la plus critique dans les réseaux de capteurs est la modestie de ses ressources énergétiques car chaque capteur du réseau possède de faibles ressources en termes d énergie (batterie). Afin de prolonger la durée de vie du réseau, une minimisation des dépenses énergétiques est exigée chez chaque nœud. Ainsi, la capacité de stockage et la puissance de calcul sont limitées dans un capteur Enjeux particuliers dans les réseaux de capteurs Dans cette section, nous décrirons deux enjeux fondamentaux dans les réseaux de capteurs : le routage et la structuration des réseaux. Le routage permet l acheminement des informations vers une destination donnée à travers un réseau de connexion. Le problème de routage consiste à déterminer un acheminement optimal des paquets à travers le réseau au sens d un certain critère de performance comme la consommation énergétique. Le problème consiste à trouver l investissement de moindre coût qui assure le routage du trafic nominal et garantit la qualité de service. Le problème qui se pose dans le contexte des réseaux de capteurs est l adaptation de la méthode d acheminement utilisée avec le grand nombre de nœuds existant dans un environnement caractérisé par de changements de topologies, de modestes capacités de calcul, de sauvegarde, et d énergie. Toute conception de protocole de routage implique l étude des problèmes suivants : Minimiser la charge du réseau en optimisant le nombre d envois et de réceptions des paquets. Cette minimisation aboutit à une consommation énergétique minimale et une longue durée de vie du réseau. Offrir un support pour pouvoir effectuer des communications multi-sauts fiables. 34

35 Assurer un routage optimal si possible. Offrir une bonne qualité concernant les temps de latence. Les réseaux de capteurs Auto organiser le réseau ceci peut être nécessaire dans plusieurs cas. Un réseau comportant un grand nombre de nœuds placés dans des endroits hostiles où la configuration manuelle n est pas faisable doit être capable de s auto-organiser. Un autre cas est celui où un nœud est inséré ou retiré (à cause d un manque d énergie ou destruction physique). Ainsi le réseau doit être capable de se reconfigurer pour continuer son fonctionnement. En général, le routage dans les réseaux de capteurs peut être classé, selon la structure du réseau, en routage à plat et routage hiérarchique. Dans le routage à plat, tous les nœuds ont typiquement les mêmes rôles et fonctionnalités. Cependant, le routage hiérarchique est réalisé à plusieurs niveaux dans le sens où la vision du réseau est réduite. Certains nœuds peuvent jouer des rôles particuliers dans le réseau afin de router les informations. Notre intérêt s est focalisé sur les protocoles hiérarchiques. Ces protocoles, proposés à l origine pour les réseaux filaires, sont des techniques bien connues avec des avantages particuliers liés à la scalabilité 3 et la communication efficace. Le concept de routage hiérarchique est aussi utilisé pour assurer une efficacité énergétique dans les WSNs. Dans une architecture hiérarchique, les nœuds qui disposent d une ressource énergétique importante peuvent être utilisés pour traiter et envoyer les informations tandis que les nœuds d énergie basse peuvent être utilisés pour exécuter la capture d information dans la proximité de la cible. Le routage hiérarchique est une façon de minimiser la consommation énergétique du système en réduisant la vision globale du réseau en une vision locale dans chaque nœud. Ceci aboutit à une prolongation de la vie du réseau en entier. 1.4 Conclusion Dans ce chapitre, nous avons défini et décrit brièvement ce qu est un réseau Ad-hoc et ses caractéristiques ainsi qu un réseau de capteurs sans fil qui est un type particulier de réseau Ad-hoc. Nous avons décrit le capteur, ses fonctionnalités et son architecture. Nous avons cité les caractéristiques d un réseau de capteurs et présenté quelques applications. Nous avons aussi mis l accent sur le routage et la structuration virtuelle d un réseau qui sont des points essentiels que nous développerons dans la suite de ce document. La classification des protocoles de routage Ad-hoc a été également décrite ainsi que des méthodes utilisées par ces protocoles (Distance Vector et Link State). Dans la suite, nous présenterons plusieurs protocoles de routage utilisés dans les réseaux Ad-hoc et de capteurs qui partagent des caractéristiques identiques. 3 Aptitude d un système de conserver ses propriétés fonctionnelles malgré un changement de taille 35

36

37 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Chapitre 2. Protocoles de routage dans les réseaux de capteurs 2.1 Introduction Le routage est une méthode d acheminement des informations vers une destination donnée dans un réseau de connexion. Comme nous l avons déjà vu, l architecture des réseaux Ad-hoc est caractérisée par l absence d infrastructure fixe préexistante, à l inverse des réseaux de télécommunication classiques. Un réseau Ad-hoc doit s organiser automatiquement de façon à être déployé rapidement et pouvoir s adapter aux conditions du trafic et aux différents mouvements pouvant intervenir au sein des nœuds mobiles. Dans le but d assurer la connectivité du réseau, malgré l absence d infrastructure fixe, chaque nœud est susceptible d être mis à contribution pour participer au routage et pour retransmettre les paquets d un nœud qui n est pas en mesure d atteindre sa destination directement ; tout nœud joue ainsi le rôle de poste de travail et de routeur. C est le cas du réseau de capteurs qui est un réseau Ad-hoc avec des contraintes plus fortes d énergie, de capacité, de calcul et de stockage. Chaque nœud participe donc au routage ce que lui permet de découvrir les chemins existants afin d atteindre les autres nœuds du réseau. Le fait que la taille d un réseau puisse être importante, surtout dans le cas des réseaux de capteurs, souligne que les techniques de routage dans les réseaux classiques nécessitent des modifications. Le problème qui se pose dans le contexte de ces réseaux est l adaptation de la méthode d acheminement utilisée à un grand nombre de nœuds possédant de modestes capacités de calculs et de sauvegarde et parfois présentant des changements de topologie. Il est impossible qu un nœud puisse garder les informations de routage concernant tous les autres nœuds, car le réseau peut être volumineux. Ce problème ne se pose pas dans le cas des réseaux de petites tailles, car l inondation (la diffusion pure qui fait propager un paquet dans le réseau entier) 37

38 Protocoles de routage dans les réseaux de capteurs faite pour ce but dans ces réseaux n est pas coûteuse ; par contre dans un réseau volumineux, le manque de données de routage concernant les destinations peut impliquer une large diffusion dans le réseau. Cela si on considère seulement la phase de découverte des routes - peut dégrader considérablement les performances du système caractérisé principalement par une faible bande passante et une capacité énergétique limitée. Dans le cas où le nœud destination se trouve dans la portée de communication du nœud source, le routage devient évident et aucun protocole de routage n est initié, ce qu on appelle envoi direct ou à un seul saut. Mais ce cas est généralement rare dans les réseaux Ad-hoc et les réseaux de capteurs. Un nœud source peut avoir besoin de transférer des données à un autre nœud qui ne se trouve pas dans sa portée de communication. La Figure 2.1 montre un exemple d un réseau constitué de quatre nœuds. Le nœud A envoie directement un paquet à B sans besoin de routage puisque B est dans la portée de communication de A (envoi direct). D ailleurs, si le nœud A veut envoyer un paquet au nœud D, il doit utiliser les «services» des nœuds intermédiaires B et C puisque le nœud D n est pas dans la portée de A. A envoie le paquet à B ; B transmet le paquet à C ; C, à son tour, transmet le paquet au nœud D. Cette technique est appelée routage multi-sauts (multi-hops). A B C D Figure 2.1 : Communication multi-sauts entre A et D Dans la suite, nous décrirons des protocoles de routage dans les réseaux Ad-hoc et de capteurs. Nous les présenterons sous deux catégories : hiérarchique et non hiérarchique (ou à plat). 2.2 Protocoles de routage non hiérarchiques Introduction L objectif principal d un protocole de routage pour un réseau Ad-hoc est l établissement correct et efficace d itinéraires entre une paire de nœuds afin que des messages puissent être acheminés. Le protocole de routage permet aux nœuds de se connecter directement les uns aux autres pour 38

39 Protocoles de routage non hiérarchiques relayer les messages par des sauts multiples. Par la suite, nous présenterons un état de l art des principaux protocoles de routage à plat (non hiérarchique) dans les réseaux Ad-hoc car la présentation de ces protocoles nous permettra de mieux analyser l avantage de l approche hiérarchique surtout dans les grands réseaux. Malgré que notre intérêt se focalise sur les protocoles hiérarchiques, nous avons rédigé cet état de l art parce qu un réseau de capteurs partage forcément des caractéristiques et des contraintes des réseaux Ad-hoc qu il faut prendre en compte lors d une proposition d un protocole de routage DSDV (Destination Sequenced Distance Vector) DSDV (14) est un protocole proactif de routage à vecteur de distance. Chaque nœud du réseau maintient une table de routage contenant le saut suivant et le nombre de sauts pour toutes les destinations possibles. Des diffusions de mises à jour périodiques tendent à maintenir la table de routage complètement actualisée à tout moment. Afin d éviter le bouclage (loop-freedom), DSDV utilise les numéros de séquence (Sequence Number, voir la section a) ) pour indiquer la «nouveauté» d une route. Une route R est considérée plus favorable qu une autre R, si R a un numéro de séquence plus grand ; si ces deux routes ont le même numéro de séquence, alors R est plus favorable s il possède un nombre inférieur de sauts. Le numéro de séquence pour une route est initialisé par le nœud émetteur et incrémenté pour chaque nouvel avertissement de route. Quand un nœud détecte un lien brisé vers une destination D, il met à jour le nombre de sauts pour l entrée de la destination D dans sa table avec la valeur infini et incrémente son numéro de séquence. Les boucles de routes peuvent survenir lorsque des informations incorrectes de routage sont présentes dans le réseau après un changement dans la topologie du réseau (lien brisé par exemple). Dans ce contexte, l utilisation des numéros de séquence adapte DSDV à une topologie dynamique de réseau comme dans un réseau Ad-hoc. DSDV utilise des mises à jour étiquetées lorsque la topologie change. La transmission des mises à jour est retardée afin d introduire un effet d amortissement quand la topologie change rapidement. Ainsi DSDV permet une adaptation aux réseaux Ad-hoc mobiles (MANET) GSR (Global State Routing) Le protocole GSR (35) est un protocole similaire au protocole DSDV décrit précédemment. Ce protocole utilise les idées du routage basé sur l état des liens (Link State, LS), et les améliore en évitant le mécanisme inefficace d inondation des messages de routage. GSR utilise une vue globale de la topologie du réseau, comme c est le cas dans les protocoles basés sur LS. Le protocole utilise aussi une méthode, appelée la méthode de dissémination, utilisée dans le DBF (Distributed Bellman-Ford (13)). Dans ce protocole, chaque nœud ni maintient : une liste de voisins Vi, une table de topologie TTi, une table des nœuds suivants NEXTi (Next Hop), et une table de distance Table_Di. La table de la 39

40 Protocoles de routage dans les réseaux de capteurs topologie TTi, contient pour chaque destination, l information de l état des liens telle qu elle a été envoyée par la destination, et une estampille de l information. Pour chaque nœud destination j, la table NEXTi contient le nœud vers lequel les paquets destinés à j seront envoyés. La table de distance contient la plus courte distance pour chaque nœud destination. De la même manière que les protocoles LS, les messages de routage sont générés suivant les changements d états des liens. Lors de la réception d un message de routage, le nœud met à jour sa table de topologie (représentée par un graphe dans LS) et cela dans le cas où le numéro de séquence du message reçu est supérieur à la valeur du numéro de séquence sauvegardé dans la table (exactement comme le fait le protocole DSDV). Par la suite, le nœud reconstruit sa table de routage et diffuse les mises à jour à ses voisins. Le calcul des chemins peut se faire avec n importe quel algorithme de recherche des plus courts chemins. Par exemple, dans (35), l algorithme du GSR utilise l algorithme de Dijkstra modifié de telle façon qu il puisse construire la table des nœuds suivants (NEXT HOP) et la table de distance Table_D, en parallèle avec la construction de l arbre des plus courts chemins (l arbre dont la racine est le nœud source). La principale modification de GSR sur l algorithme LS traditionnel, est la façon de diffusion des informations de routage qui circulent dans le réseau. Dans LS, si on détecte des changements de topologie, les paquets d états de liens sont générés et diffusés par inondation dans tout le réseau. Par contre, GSR maintient la table - la plus récente - d état des liens reçus à travers les voisins, et l échange uniquement avec ses voisins locaux, d une façon périodique FSR (Fisheye State Routing) Le protocole FSR [ (4), (5)] peut être vu comme une amélioration du protocole GSR présenté précédemment. Le nombre élevé de messages de mise à jour échangés implique une grande consommation de la bande passante, ce qui a un effet négatif dans les réseaux Ad-hoc caractérisés par une bande passante limitée. Le protocole FSR est basé sur l utilisation de la technique "œil de poisson" (fisheye), proposée par Kleinrock et Stevens (36) qui l ont utilisée dans le but de réduire le volume d information nécessaire pour représenter les données graphiques. L œil de poisson capture, avec précision, les points proches du point focal. La précision diminue quand la distance séparant le point vu et le point focal augmente (36). Dans le contexte du routage, l approche du «fisheye» matérialise, pour un nœud, le maintien des données concernant la précision de la distance et la qualité du chemin d un voisin direct, avec une diminution progressive, du détail et de la précision, quand la distance augmente. Le protocole FSR est similaire à LS, dans sa sauvegarde de la topologie au niveau de chaque nœud. La modification principale réside dans la manière avec laquelle les informations de routage circulent. Dans FSR, la diffusion par inondation de messages n existe pas. L échange se fait uniquement avec les voisins directs. Les données de mise à jour, échangées périodiquement dans FSR, ressemblent au vecteur échangé dans le protocole DSDV, où les distances sont modifiées suivant l estampille du temps ou le numéro de séquence associé au nœud qui a été à l origine de la mise à jour. Dans FSR (comme dans LS) les états de liens sont échangés, l image complète de la topologie du réseau est gardée au 40

41 Protocoles de routage non hiérarchiques niveau de chaque nœud, et les meilleurs chemins sont échangés en utilisant cette image. Comme nous l avons déjà dit, l état des liens change fréquemment dans les réseaux Ad-hoc. FSR effectue la mise à jour de ces changements de la même manière que le protocole GSR; ce qui résout les problèmes de LS concernant le volume de paquets de contrôle. Avec GSR, et quand la taille du réseau devient très grande, les messages de mise à jour peuvent consommer une bande passante considérable. Afin de réduire le volume de messages échangés sans toucher à la consistance et à la précision des données de routage, FSR utilise la technique «œil de poisson» vue précédemment. La Figure 2.2 illustre cette technique. Dans cette figure, on définit la portée, ou le champ de vision de l œil de poisson, avec un nœud du centre d identificateur égal à 1. La portée est définie en termes de nœuds qui peuvent être atteints en passant par un certain nombre de sauts. Dans la Figure 2.2, trois portées sont montrées pour 1, 2 et supérieures à 2 respectivement. En conséquence, les nœuds sont colorés en noir, gris et blanc. Le nombre de niveaux et le rayon de chaque portée va dépendre de la taille du réseau. Le nœud de centre (le nœud 1) maintient les données les plus précises des nœuds appartenant au cercle le plus proche ; la précision diminue progressivement, pour les cercles moins proches du centre. Saut = Saut = 2 Saut > Figure 2.2 : Technique "œil de poisson" dans le protocole FSR La réduction du volume des données de mise à jour est obtenue en utilisant des périodes d échanges différentes pour les différentes entrées de la table. Les entrées qui correspondent aux nœuds les plus proches sont envoyées aux voisins avec une fréquence élevée (donc avec une période d échange relativement petite). Par exemple, les entrées des nœuds en gras (voir la Figure 2.2) sont échangées fréquemment. Le reste des entrées est échangé avec une fréquence moins élevée. De cette manière, un grand nombre d échanges de données de routage est évité, ce qui réduit le volume des messages qui circulent dans le réseau. 41

42 Protocoles de routage dans les réseaux de capteurs Cette stratégie fournit périodiquement des mises à jour pour les nœuds proches mais elle crée de grandes latences pour celles des nœuds éloignés. Cependant, l imprécision sur le meilleur chemin vers une destination lointaine est minimisée par le fait que la route devient plus précise lorsque le paquet s approche de la destination. Le protocole FSR peut être utilisé dans les réseaux Ad-hoc dont le nombre de nœuds est grand. Le protocole utilise un volume raisonnable de messages de contrôle. En outre, il évite le travail énorme de recherche de chemins, effectué dans les protocoles réactifs ; ceci accélère la transmission. De plus, FSR maintient des calculs précis concernant les destinations proches. Malgré ses avantages, FSR ne répond pas aux contraintes des réseaux de capteurs (surtout la contrainte d énergies) AODV (Ad-hoc On Demand Distance Vector) AODV (6) est un protocole à vecteur de distance, comme DSDV, mais il est réactif plutôt que proactif comme DSDV. En effet, AODV ne demande une route que lorsqu il en a besoin. AODV utilise les numéros de séquence d une façon similaire à DSDV pour éviter les boucles de routage et pour indiquer la «nouveauté» des routes. Une entrée de la table de routage contient essentiellement l adresse de la destination, l adresse du nœud suivant, la distance en nombre de sauts (i.e. le nombre de nœuds nécessaires pour atteindre la destination), le numéro de séquence destination, le temps d expiration de chaque entrée dans la table. Lorsqu un nœud a besoin de trouver une route vers une destination dont l entrée dans la table de routage n existe pas ou est expirée, il diffuse un message de demande de route (Route Request message, RREQ) à tous ses voisins. Le message RREQ est diffusé à travers le réseau jusqu à atteindre la destination. Durant son parcours à travers le réseau, le message RREQ réalise la création des entrées temporaires des tables de routage pour la route inverse des nœuds à travers lesquels il passe. Si la destination, ou une route vers elle, est trouvée, une route est rendue disponible en envoyant un message réponse de route (Route Reply, RREP) au nœud source. Cette réponse de route traverse le long du chemin temporaire inversé du message RREQ. Dans son chemin de retour vers la source, RREP introduit la création des entrées pour la destination dans les tables de routage des nœuds intermédiaires. Les entrées de routage expirent après une certaine période (time-out). Précisons que le protocole AODV ne supporte que les liens symétriques dans la construction des chemins inverses. 42

43 Protocoles de routage non hiérarchiques Figure 2.3 : Fonctionnement de la procédure de demande de route dans AODV La Figure 2.3 illustre le mécanisme de création des routes d AODV. Il y a d abord diffusion de la demande de route. Ensuite, la destination envoie une réponse, qui, grâce aux informations recueillies par les nœuds lors de la diffusion de la demande de route, crée une route de la destination vers la source. A noter que le protocole de routage AODV n assure pas la détection du meilleur chemin existant entre la source et la destination. Les nœuds voisins sont détectés par des messages périodiques HELLO (un message particulier de RREP). Si un nœud x ne reçoit pas un message HELLO d un voisin y par lequel il envoie des données, ce lien est considéré brisé et une indication de défaillance de lien est envoyée à ses voisins actifs. Ces derniers propagent l indication à leurs voisins qui utilisaient le lien entre x et y. Lorsque le message du lien brisé atteint finalement les sources affectées, celles-ci peuvent choisir d arrêter l envoi des données ou de demander une nouvelle route en envoyant un nouveau message RREQ DSR (Dynamic Source Routing) DSR [ (7), (8)] est un protocole de routage réactif qui utilise le routage de source afin d envoyer des paquets de données. Dans ce type de routage, les entêtes des paquets de données portent la séquence des nœuds à travers lesquels le paquet doit passer. Ceci signifie que les nœuds intermédiaires ont juste besoin de garder des traces de leurs voisins intermédiaires afin de transférer les paquets de données. Le nœud source a besoin de savoir l ordre complet des nœuds jusqu à la destination. Comme dans AODV, la demande d une route dans DSR exige une inondation avec des paquets Route Request. Un nœud recevant ce paquet cherche dans sa «cachette de route» (similaire à la table de routage dans AODV), où toutes ses routes connues sont stockées, une route contenant la destination demandée. S il n y a pas de route trouvée, le nœud transfère le paquet Route Request plus loin après avoir ajouté sa propre adresse à la séquence de nœuds stockée dans le paquet Route Request. Le paquet se propage dans le réseau jusqu à l arrivée à destination ou à un nœud possédant une route vers cette destination. Si une route est trouvée, un paquet Route Reply contenant la séquence de nœuds appropriée pour atteindre la destination est renvoyé en unicast au nœud source. DSR ne prend pas en compte la bidirectionnalité des liens puisque le paquet Route Reply est envoyé au nœud source selon une route déjà stockée dans la «cachette de routes» d un 43

44 Protocoles de routage dans les réseaux de capteurs nœud intermédiaire ou à l aide d une réponse du nœud destinataire. Afin d éviter des inondations inutiles du réseau avec des messages Route Request, la procédure de demande de route commence d abord à questionner les nœuds voisins s ils ont une route disponible dans le voisinage direct. Ceci est fait en envoyant le premier paquet Route Request avec une limite de sauts égale à zéro, afin que celui-ci ne soit pas transféré ensuite aux voisins. S il n y a pas de réponses obtenues lors de cette demande initiale, un nouveau paquet Route Request est diffusé dans le réseau entier. Un nœud DSR est capable de connaître des routes en lisant des paquets qui ne lui sont pas adressés (promiscuous mode) (37). Cependant, cette technique exigeant un récepteur actif dans le nœud, peut être plutôt consommatrice d énergie. Dans les réseaux où les nœuds ont une capacité énergétique limitée, le but est de mettre en veille l émetteur-récepteur afin de conserver l énergie le plus possible OLSR (Optimized Link State Routing) Comme son nom l indique, OLSR est un protocole proactif à état des liens optimisé ; il permet d obtenir aussi des routes de plus court chemin. Alors que dans un protocole à état des liens, chaque nœud déclare ses liens directs avec ses voisins à tout le réseau, dans le cas d OLSR, les nœuds ne déclarent qu une sous-partie de leur voisinage grâce à la technique des relais multipoints (MultPoint Relaying, MPR) (38) décrite par la suite. a) Relais multipoints Cette technique consiste essentiellement, pour un nœud donné, à ignorer un ensemble de liens et de voisins directs, qui sont redondants pour le calcul des routes de plus court chemin. Plus précisément, dans l ensemble des voisins d un nœud, seul un sous-ensemble de ses voisins est considéré comme pertinent. Il est choisi de façon à pouvoir atteindre tout le voisinage à deux sauts (tous les voisins des voisins) ; cet ensemble est appelé l ensemble des relais multipoints. L algorithme de calcul de relais multipoints est donné dans (39). Ces relais multipoints sont utilisés de deux façons : pour diminuer le trafic dû à la diffusion des messages de contrôle dans le réseau, et aussi pour diminuer la taille du sous-ensemble des liens diffusés à tout le réseau puisque les routes sont construites à base des relais multipoints (38). L idée de MPR est de minimiser l inondation du trafic de contrôle dans un réseau en réduisant les retransmissions dupliquées dans la même région. Chaque nœud dans le réseau sélectionne un ensemble de nœuds de son voisinage auxquels ses messages seront transmis. Un nœud sélectionne ses MPRs parmi ses voisins à un saut avec un lien symétrique. Cet ensemble est choisi de manière à couvrir tous les nœuds qui sont à deux sauts. Les nœuds sélectionnés comme MPRs annoncent régulièrement leur condition de MPR dans les messages de contrôle envoyés à son voisinage. De cette façon, un nœud annonce au réseau qu il est capable d atteindre les nœuds qui l ont élu comme MPR. Dans le calcul de la route, les MPR sont utilisés pour la mise en place des routes vers toutes les destinations du réseau. Ainsi, en sélectionnant la route par l intermédiaire des MPRs, 44

45 Protocoles de routage non hiérarchiques on évite les problèmes liés à la transmission de paquets sur des liens unidirectionnels. Chaque nœud maintient l information sur ses voisins qui ont été sélectionnés comme MPR. Un nœud obtient cette information par les messages de contrôle reçus périodiquement de ses voisins (39). La Figure 2.4 montre la différence entre une diffusion pure et la diffusion en utilisant les MPRs. Par exemple, afin d atteindre tous les nœuds à 3 sauts, la diffusion pure a besoin de 24 retransmissions du paquet envoyé par la source (voir la Figure 2.4, côté gauche). En utilisant les MPRs ou les relais multipoints (nœuds en gras dans le côté droit de la Figure 2.4), il suffit de retransmettre le paquet de la source 11 fois pour atteindre les nœuds à 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 très bien adapté aux réseaux larges et denses. Tous les nœuds du réseau serviront de routeur et OLSR maintient sur chaque nœud une table de routage complète (comprenant une entrée pour tous les autres nœuds du réseau). Le protocole est complètement distribué, il n y a pas d entité centrale. Chaque nœud choisit la route la plus adaptée en fonction des informations qu il a reçues. Pour maintenir à jour toutes les informations nécessaires au choix des relais multipoints (MPRs) et au calcul de la table de routage, les nœuds OLSR ont besoin de s échanger des informations périodiquement. Pour s informer du proche voisinage, les nœuds OLSR envoient périodiquement des messages dits HELLO contenant la liste de leurs voisins. Ces messages permettent à chacun de choisir son ensemble de relais multipoints. Le deuxième type de message d OLSR est le message TC (Topology Control). Par ce message les sous-ensembles de voisinage que constituent les relais multipoints sont déclarés périodiquement dans le réseau. Ils sont diffusés en utilisant une diffusion optimisée par relais multipoints. Ces informations offrent une carte du réseau contenant tous les nœuds et un ensemble partiel de liens, mais suffisant pour la construction de la table de routage. 45

46 Protocoles de routage dans les réseaux de capteurs La table de routage est calculée par chacun des nœuds et le routage des données s effectue saut par saut sans l intervention d OLSR dont le rôle s arrête à la mise à jour de la table de routage (38) GPSR (Greedy Perimeter Stateless Routing) La topologie a un caractère relativement provisoire dû à la mobilité des nœuds dans les réseaux Ad-hoc et de capteurs mobiles. Pour cette raison, les protocoles de routage les plus étudiés pour ce type de réseaux sont les protocoles de routage géographique car ils permettent d éviter la surcharge d informations échangées entre les nœuds qui cherchent à obtenir la topologie du réseau ou à construire les tables de routage. Ces protocoles de routage géographique se basent sur le fait que tous les nœuds connaissent leur position, par exemple, grâce à un équipement GPS (Global Positioning System) ou encore par un système de positionnement distribué. Il existe plusieurs protocoles qui définissent différentes manières d obtenir la localisation d un nœud : 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 géographique sont à l étude, comme le protocole réactif GPSR (44) qui a été conçu pour les réseaux ad hoc mobiles et les réseaux de capteurs. Du fait de la mobilité des nœuds, certains protocoles de routage qui se basent sur la topologie du réseau lancent une phase de découverte de routes pour acheminer des données. De ce fait, ils utilisent la position géographique des nœuds pour l acheminement des paquets de données ou de contrôle. GPSR en fait parti. Dans un réseau mobile, les nœuds sont susceptibles de se déplacer. Il faut ainsi un mécanisme permettant à chaque nœud de savoir la position de ses voisins. Afin de signaler leur présence et leur localisation, les nœuds dans GPSR inondent le réseau en envoyant un paquet de signalement (messages beacon) contenant la position et un identifiant (par exemple, son adresse IP). L échange périodique de ces paquets de contrôle permet aux nœuds de construire leur table de position. La période d émission des messages beacon dépend du taux de mobilité dans le réseau ainsi que de la portée radio des nœuds. En effet, lorsqu un nœud ne reçoit pas de message beacon d un voisin après un temps T, il considère que le voisin en question n est plus dans sa zone de couverture et l efface de sa table de position. Il faut donc adapter le temps d émission des paquets de contrôle. Un des avantages du BP (Beaconing Protocol) (44) est que chaque nœud n a besoin que des informations sur ses voisins directs, ce qui nécessite peu de mémoire. Alternativement, le protocole GPSR permet au nœud d encapsuler sur quelques bits sa position dans les paquets de données qu il envoie. Dans ce cas, tous les nœuds doivent être en mode promiscuité afin de recevoir les paquets s ils se trouvent dans la zone de couverture de l émetteur. L acheminement des paquets par GPSR se fait selon deux modes suivant la densité du réseau : le «Greedy Forwarding» (45) et le «Perimeter Forwarding» (46). 46

47 Protocoles de routage non hiérarchiques SPIN (Sensor Protocol for Information via Negotiation) Le protocole SPIN (47) permet de disséminer des informations sur le réseau de manière ciblée. Le fonctionnement du protocole SPIN permet de réduire la charge du réseau par rapport aux méthodes de diffusion traditionnelles telles que l inondation ou l algorithme de Gossiping 4. Figure 2.5 : Fonctionnement du protocole SPIN (48) Le protocole SPIN utilise essentiellement trois types de paquets ADV/REQ/DATA. Un nœud voulant émettre une donnée commence par envoyer un paquet ADV. Ce paquet ADV consiste d une méta-données sur les données à émettre. Les méta-données peuvent décrire plusieurs aspects comme le type des données et la localisation de son origine. Les nœuds qui reçoivent ce paquet vérifient si les données les intéressent. Si oui, ils répondent par un paquet REQ. Le nœud qui a initié la communication envoie alors un paquet DATA pour chaque réponse REQ reçue (voir la Figure 2.5). Un nœud peut parfaitement ne pas répondre aux messages ADV, par exemple dans le but d économiser son énergie. Ensuite chaque nœud qui fait office de relais peut très bien agréger ses propres données aux données qui sont déjà contenues dans le paquet (49). 4 Technique de dissémination d information dans laquelle chaque nœud qui reçoit un paquet à relayer, envoie le paquet reçu à un de ses voisins tiré aléatoirement 47

48 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] 2.3 Protocoles de routage hiérarchiques Introduction Lorsque la taille du réseau devient de plus en plus importante, sa gestion devient plus difficile. Les protocoles de routage à plat fonctionnent bien quand le réseau ne comprend pas un grand nombre de nœuds. La structuration d un réseau est un des outils principaux pour sauvegarder l énergie dans chaque nœud du réseau, ce qui aboutit à prolonger la vie du système. Une des structures les plus connues est la hiérarchie. La technique de hiérarchisation sert à partitionner le réseau en sous ensembles afin de faciliter la gestion du réseau surtout le routage, qui se réalise à plusieurs niveaux. Dans ce type de protocoles, la vue du réseau devient locale ; des nœuds spéciaux peuvent avoir des rôles supplémentaires. La littérature comprend plusieurs contributions dans les techniques de hiérarchisation du réseau, que nous avons classifiées, dans l intérêt de faciliter leur comparaison. Cette classification brièvement décrite ici, dans l introduction, sera présentée de manière détaillée dans la conclusion du chapitre. Nous distinguons deux types de groupes de nœuds : la zone et le cluster. Un cluster est défini par un ensemble de nœuds et possède un nœud nommé nœud-chef ou Cluster Head (CH). Le rôle du CH est de faire le relais entre les nœuds du cluster et la station de base directement ou via d autres CHs. Le CH possède généralement des ressources énergétiques supérieures aux autres nœuds du réseau. Cette technique est appelée clusterisation (voir la Figure 2.6). Le CH est élu suivant différents critères et informations sur le réseau : le niveau de l énergie d un capteur, la connexion avec les autres capteurs, la position géographique, etc. Une zone est définie par un ensemble de nœuds mais ne possède pas un nœud-chef (ou CH). Ainsi, un cluster est une sous-classe d une zone. La construction des groupes (zones ou clusters) s appuie sur des informations sur le réseau, exigeant donc son instrumentation. Cette prise de mesures peut être, dans certaines circonstances, statique (comme la position des capteurs dans un système immobile) ou dynamique (comme le niveau énergétique des capteurs). Une autre structure utilisée est la chaîne (50). Le principe d une chaîne est qu un nœud ne peut communiquer qu avec deux voisins. Nous trouvons aussi des structures qui combinent les groupes et les chaînes. En se basant sur une architecture hiérarchique, plusieurs protocoles de routage pour les réseaux Ad-hoc de grande taille ont été proposés. Dans la suite nous en détaillerons quelques uns. 48

49 Protocoles de routage hiérarchiques Cluster #1 Cluster #3 Station de base Capteur Cluster Head Figure 2.6 : Architecture en cluster ZHLS (Zone-based Hierarchical Link State Protocol) Zone 5 Zone 1 Lien entre nœuds Lien entre zones Zone 2 Zone 4 Zone 3 Figure 2.7 : Décomposition du réseau en zones dans ZHLS Le protocole ZHLS (51) est basé sur la décomposition du réseau en un ensemble de zones disjointes. Dans ce protocole, les membres d une zone n élisent pas de représentants contrairement 49

50 Protocoles de routage dans les réseaux de capteurs à d autres protocoles hiérarchiques. ZHLS utilise la technique GPS 5 afin que chaque nœud sache sa position et la zone dans laquelle il se trouve. Avec cette décomposition, on a deux niveaux de topologies : le niveau nœud, et le niveau zone. La topologie basée sur le premier niveau renseigne sur la manière dans laquelle les nœuds d une zone donnée sont connectés physiquement. Un lien virtuel peut exister entre deux zones, s il existe au moins un nœud de la première zone, qui soit physiquement connecté à un nœud de l autre zone (voir la Figure 2.7). La topologie basée sur le niveau zone, donne le schéma de la connexion des différentes zones. La taille de la zone dépend de la mobilité des nœuds, la densité du réseau, la puissance de transmission et les caractéristiques de propagation. Le protocole est proactif quand le nœud destinataire est dans la même zone que le nœud émetteur. D autre part, il est réactif si le nœud destinataire n appartient pas à la même zone que le nœud émetteur. Dans ce protocole, les paquets qui contiennent les états des liens ou les LSPs (Link State Packet) peuvent être divisés en deux classes : les LSPs orientés nœuds (NodeLSP) et les LSPs orientés zones (ZoneLSP). Pour un nœud donné, un paquet NodeLSP contient l information d un nœud voisin tandis qu un paquet ZoneLSP contient l information de la zone et il est échangé d une manière globale. De cette façon, chaque nœud du réseau possède une connaissance complète concernant les nœuds de sa propre zone, et seulement une connaissance partielle du reste du réseau. Cette connaissance partielle est matérialisée par l état de la connexion des différentes zones du réseau. a) Construction des tables de routage intra-zone Chaque nœud diffuse une demande de vérification de liens (Link Request). Les noeuds appartenant à sa portée de communication répondent par un paquet contenant l ID du nœud et sa zone. Après avoir reçu toutes les réponses, le nœud génère son paquet NodeLSP. Ce paquet NodeLSP contiendra les IDs des nœuds voisins dans sa zone et l ID de la zone de ses voisins dans les différentes zones. Le paquet NodeLSP d un nœud est transféré à tous les nœuds de la même zone. Les informations de l ensemble de ces paquets NodeLSP seront stockées chez chaque nœud de la zone. Les informations des paquets venant des autres zones ne sont pas stockées puisqu elles ne sont propagées que dans leurs propres zones. De cette façon, un nœud connaît la topologie basée sur le niveau nœud de sa zone (graphe LS). L algorithme 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 nœuds peuvent recevoir des réponses sur leurs demandes de vérification de liens (Link Request) des nœuds qui ne sont pas dans sa zone. Ces nœuds sont appelés des nœuds «gateway». Après l échange des paquets NodeLSP dans la phase intra-zone, chaque nœud connaît les zones connectées à sa zone. A ce moment, chaque nœud de la même zone génère le même paquet ZoneLSP. Les nœuds «gateway» envoient le paquet ZoneLSP à tous les nœuds du réseau. Chaque zone exécute la même procédure. Une liste de paquets ZoneLSP est stockée par chaque nœud du réseau. Par la suite, chaque nœud du réseau connaîtra la topologie du réseau (niveau zone). Une 5 Global Positioning System 50

51 Protocoles de routage hiérarchiques table de routage inter-zone est construite et SPF est utilisé pour trouver le plus court chemin. Les tables sont mises à jour périodiquement. Les nœuds «gateway» ne diffuseront pas les paquets ZoneLSP si les nouvelles valeurs sont les mêmes que les anciennes. Le ZoneLSP n est mis à jour qu à la création ou lors de la cessure d un lien virtuel entre les zones. Ainsi, si un nœud «gateway» reçoit deux copies du même ZoneLSP, il ne transfère qu une seule, ce qui réduit le surcoût dans le réseau. Par conséquent, l acheminement des données se fait de deux façons : le routage inter-zones, et le routage intra-zone. Pour une destination donnée, les données sont envoyées entres les zones en utilisant les identificateurs de zones jusqu à ce que les données atteignent la zone finale de destination. Par la suite, les paquets de données circulent à l intérieur de la zone finale, en utilisant l identificateur du nœud destination. L adresse < ID zone, ID nœud >, est suffisante pour atteindre n importe quelle destination même si le réseau change de topologie CGSR (Clusterhead Gateway Switch Routing) Le protocole CGSR (52) utilise principalement l algorithme de routage DSDV, décrit précédemment. Le réseau est décomposé en groupes appelés clusters. Dans chaque cluster un nœud, appelé ClusterHead (CH), est élu. Ce nœud est responsable de contrôler le cluster. Le cluster est formé des nœuds appartenant à la portée de communication d un CH. Un nœud qui appartient à la portée de communication de plus d un CH est un nœud de liaison (appelé gateway). Comme les changements de topologie dans les réseaux Ad-hoc sont fréquents, CGSR utilise un algorithme appelé LCC (Least Cluster Change). L élection du CH se fait en utilisant un des deux algorithmes : lowest-id algorithm (53) ou highest-connectivity (degree) algorithm (54). Dans l algorithme LCC, un changement de CHs intervient seulement dans le cas d une fusion de deux clusters (les deux clusters se transforment en un nouveau cluster), ou dans le cas où un nœud sortirait complètement de la portée de tous les CHs. Chaque nœud possède deux tables. La première est la table de membres du cluster, qui associe à chaque nœud du réseau l identificateur d un CH. Chaque nœud diffuse cette table d une façon périodique et met à jour sa propre table en utilisant l algorithme DSDV. La deuxième est la table de routage (vecteur de distance). Elle détermine le nœud suivant à emprunter dans le cluster correspondant au cluster destinataire. Le routage des informations dans CGSR se fait de la façon suivante : le nœud source transmet ses paquets de données à son CH. Le CH envoie les paquets au nœud de liaison, qui relie ce CH avec le CH suivant dans le chemin qui existe vers la destination. Le processus se répète, jusqu à ce que ces paquets atteignent le CH du cluster dans lequel se trouve la destination. Ce CH transmet alors les paquets reçus vers le nœud destination. Notons que cette manière de routage assure un procédé déterministe et efficace pour l acheminement des informations. Cependant un chemin choisi peut ne pas être optimal. 51

52 Protocoles de routage dans les réseaux de capteurs CBRP (Cluster Based Routing Protocol) Dans le protocole réactif CBRP (9), l ensemble des nœuds du réseau est décomposé en clusters. Le principe de formation des clusters est le suivant : un nœud n qui n est pas encore un membre du cluster ou CH, active un timer avant de diffuser un message HELLO. Lorsqu un CH reçoit le message HELLO, il répond immédiatement. Lors de la réception de réponse, le nœud n rejoint le cluster. Si le timeout est atteint sans aucune réponse et dans le cas où n possède un lien bidirectionnel vers au moins un nœud voisin, il se considère lui-même CH. Dans le cas contraire, n répète la même procédure. Chaque nœud maintient une table des voisins. Chaque entrée de cette table est associée à un voisin ; elle indique l état 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 possède aussi une table des clusters adjacents. Chaque entrée de cette table contient : l identificateur du cluster, l identificateur du nœud de liaison à travers lequel le cluster peut être atteint. Comme CBRP est un protocole réactif, quand un nœud source veut envoyer des données à un nœud destination, il diffuse une requête demandant un chemin uniquement aux CHs des clusters voisins. Chaque CH vérifie l existence du nœud destination dans son cluster (en utilisant la table de membres). Le CH de cluster qui contient le nœud destination, y envoie directement la requête. Dans le cas contraire, la requête est rediffusée aux CHs des clusters voisins. Les adresses des CHs sont incluses dans cette requête. Le CH ignore toute requête déjà traitée. Quand la destination reçoit la requête, elle répond par l envoi du chemin qui a été sauvegardé dans le paquet de la requête. Dans le cas où le nœud source ne reçoit pas de réponse après une certaine période, il envoie de nouveau une requête de demande de chemin. Lors du routage des données, si un nœud détecte qu un lien est défaillant, il envoie un message d erreur à la source et il applique un mécanisme de réparation locale. Dans ce mécanisme, si un nœud n trouve qu un nœud suivant m ne peut pas être atteint, il essaie de vérifier si le nœud m ou le nœud suivant m dans le chemin peut être atteint à travers un autre nœud voisin. Si l un des deux cas est vérifié, les données sont envoyées en utilisant le chemin réparé 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 réseaux de capteurs homogènes. LEACH choisit aléatoirement les nœuds cluster-heads et attribue ce rôle aux différents nœuds selon la politique de gestion Round-Robin (c est-à-dire tourniquet) pour garantir une dissipation équitable d énergie entre les nœuds. Dans le but de réduire la quantité d informations transmises à la station de base, les cluster-heads agrègent les données capturées par les nœuds membres qui appartiennent à leur propre cluster, et envoient un paquet agrégé à la station de base. LEACH est exécuté en deux phases : la phase «set-up» et la phase «steady-state» suivant la Figure 2.8. Dans la première phase, les cluster heads sont sélectionnés et les clusters sont formés, et dans la seconde phase, le transfert de données vers la station de base aura lieu. Durant la première 52

53 Protocoles de routage hiérarchiques phase, le processus d élection des cluster heads est déclenché pour choisir les futurs cluster heads. Ainsi, une fraction prédéterminée de nœuds s élisent comme cluster heads selon le schéma d exécution suivant : durant une période T, un nœud n choisit un nombre aléatoire nb dont la valeur est comprise entre 0 et 1 (0 < nb < 1). Si nb est inférieur à une valeur seuil alors le nœud n deviendra cluster head durant la période courante, sinon le nœud 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 durée de vie du réseau, il présente certaines limitations. LEACH suppose que tous les nœuds puissent transmettre des données avec une grande puissance pour atteindre la station de base et que chaque nœud a une puissance de calcul lui permettant de supporter différentes couches MAC. Par conséquent, LEACH ne convient pas aux réseaux déployés dans de vastes régions. En outre, LEACH choisit aléatoirement la liste des cluster heads et il ne pose aucune contrainte sur leur distribution ainsi que sur leur niveau d énergie. Ainsi, les cluster heads peuvent se concentrer dans un même endroit et par conséquent, il pourrait exister des nœuds isolés (sans cluster head) pouvant se déclarer. D autre part, dans LEACH, l agrégation des données est centralisée et est exécutée périodiquement. Or, dans certains cas, la transmission périodique des données pourrait ne pas être nécessaire, ce qui épuise rapidement l énergie limitée des capteurs. Une variante de LEACH appelée LEACH-C (56) a été conçue pour améliorer les performances de LEACH. Cette variante utilise une architecture centralisée pour choisir les cluster heads tout en impliquant la station de base et l information de localisation des capteurs. Cependant, elle augmente considérablement le surcoût du réseau puisque tous les capteurs devront envoyer leurs informations de localisation à la station de base en même temps pendant chaque phase d élection de cluster heads. Plusieurs travaux présentés (49) dans la littérature ont prouvé qu une telle architecture centralisée ne supporte pas le passage à l échelle, étant plus particulièrement appropriée à des réseaux de petite taille. Dans (57), les auteurs ont proposé un protocole hiérarchique basé sur LEACH. Les cluster heads formés dans LEACH sont groupés et organisés en une hiérarchie. Ils ont montré que la consommation énergétique diminue lorsque le nombre de niveaux de l hiérarchie augmente. 53

54 Protocoles de routage dans les réseaux de capteurs PEGASIS (Power-Efficient Gathering in Sensor Information Systems) Dans (50), Lindsey et Raghavendra ont proposé une version améliorée de LEACH appelée PEGASIS. L idée principale de PEGASIS est de former une chaîne entre les nœuds de sorte que chaque nœud reçoive de et communique à un voisin proche. Les données collectées sont transmises d un nœud à un autre qui les agrège jusqu à ce qu elles arrivent à un nœud particulier qui les transmet à la station de base. Les nœuds qui transmettent les données à la station de base, sont choisis tour à tour selon une politique round-robin dans le but de réduire l énergie moyenne dépensée par un nœud durant une période (round). Contrairement à LEACH, PEGASIS évite la formation des clusters et procure à un seul nœud dans la chaîne l envoi de données à la station de base. D ailleurs, PEGASIS suppose que les nœuds sont capables de modifier leur puissance de transmission. Les résultats de simulation ont montré que PEGASIS peut prolonger de deux à trois fois la durée de vie d un réseau de capteurs relativement à LEACH en fonction du critère choisi pour évaluer la durée de vie d un réseau i.e. quand 1%, 20%, 50% ou 100% des nœuds épuisent leurs batteries. Un tel gain de performance est réalisé par l élimination du surcoût causé par le processus de formation de clusters dans LEACH, et par la réduction du nombre de transmissions et de réceptions en agrégeant de données. Bien que le surcoût du clustering soit évité, PEGASIS exige toujours un ajustement dynamique de la topologie puisqu un nœud devrait connaître le niveau d énergie de ses voisins avant de relayer ses données. Cependant, un tel ajustement de la topologie pourrait causer un surcoût important en particulier dans les réseaux les plus utilisés. En outre, PEGASIS suppose que tout nœud communique directement avec la station de base qui gère la topologie d une manière centralisée. Or, cette supposition est loin de la réalité car les capteurs communiquent généralement en mode multi-sauts pour atteindre la station de base. D autre part, PEGASIS suppose que tous les nœuds maintiennent une table contenant les localisations de tous les autres nœuds dans le réseau. En résumé, PEGASIS est adapté seulement aux capteurs sans fil dont les nœuds sont immobiles. Son évaluation dans des environnements mobiles pourrait dégrader considérablement ses performances. Une variante de PEGASIS appelée Hierarchical PEGASIS (58) a été conçue afin d améliorer PEGASIS. Dans Hierarchical PEGASIS, la chaîne est divisée en groupes de la sorte que chaque nœud communique avec un seul nœud voisin de niveau plus bas de la hiérarchie. Les transmissions simultanées en parallèle dans des groupes différents minimisent le délai de transmission. Un autre protocole similaire à PEGASIS, appelé C 2 E 2 S, a été proposé dans (59). Il est basé sur les clusters et les chaînes. C est un protocole centralisé où la station de base organise le réseau en se basant sur l information de l énergie des nœuds TEEN (Threshold-sensitive Energy Efficient sensor Network protocol) Manjeshwar et Agrawal (60) ont proposé une technique de clustering appelée TEEN pour les 54

55 Protocoles de routage hiérarchiques applications critiques où le changement de certains paramètres peut être brusque. L architecture du réseau est basée sur un groupement hiérarchique à plusieurs niveaux où les nœuds les plus proches forment des clusters. Puis ce processus de clustering passe au deuxième niveau jusqu à ce que la station de base soit atteinte. Après la formation des clusters, chaque cluster-head transmet à ses membres deux seuils : un seuil Hard HT (hard threshold), qui est la valeur seuil du paramètre contrôlé (surveillé) et un seuil Soft ST (soft threshold) représentant une petite variation de la valeur du paramètre contrôlé. L occurrence de cette petite variation ST permet au nœud qui la détecte de la signaler à la station de base en transmettant un message d alerte. Par conséquent, le seuil Soft réduira le nombre de transmissions puisqu il ne permet pas la transmission s il y a peu ou pas de variation de la valeur du paramètre contrôlé. Au début, les nœuds écoutent le médium continuellement et lorsque la valeur captée du paramètre contrôlé dépasse le seuil Hard, le nœud transmet l information. La valeur captée est stockée dans une variable interne appelée SV. Puis, les nœuds ne transmettront des données que si la valeur courante du paramètre contrôlé est supérieure au seuil hard HT ou diffère du SV d une quantité égale ou plus grande que la valeur du seuil Soft ST. Puisque la transmission d un message consomme plus d énergie que la détection des données, alors la consommation d énergie dans TEEN est moins importante que dans les protocoles proactifs ou ceux qui transmettent des données périodiquement tels que LEACH. Cependant, l inconvénient principal de ce protocole est que, si les seuils HT et ST ne sont pas reçus, les nœuds ne communiqueront jamais, et aucune donnée ne sera transmise à l utilisateur, ainsi la station de base ne connaît pas les nœuds qui ont épuisé leur énergie. TEEN ne convient pas aux applications qui nécessitent des envois périodiques de données APTEEN (Adaptive Threshold-sensitive Energy Efficient sensor Network protocol) Pour remédier aux limitations du protocole TEEN, les auteurs ont proposé une extension de TEEN appelée APTEEN (61). APTEEN est un protocole hybride qui change la périodicité et les valeurs seuils utilisées dans TEEN selon les besoins de l utilisateur et le type d application. Dans APTEEN, les cluster-heads transmettent à leurs membres les paramètres suivants : l ensemble de paramètres physiques auxquels l utilisateur est intéressé pour obtenir des informations (A), les seuils : seuil Hard HT et seuil Soft ST, un Schedule TDMA permettant d assigner à chaque nœud un intervalle fini de temps appelé slot, un compteur de temps (CT) : c est la période de temps maximum entre deux transmissions successives d un nœud. Dans APTEEN, les nœuds surveillent en continu l environnement. Ainsi, les nœuds qui détectent une valeur d un paramètre qui dépasse le seuil HT, transmettent leurs données. Une fois qu un nœud détecte une valeur qui dépasse HT, il ne transmet les données au cluster head que si la 55

56 Protocoles de routage dans les réseaux de capteurs valeur de ce paramètre change d une quantité égale ou supérieure à ST. Si un nœud ne transmet par de données pendant une période de temps CT, il devrait faire une capture de données et les retransmettre. APTEEN offre une grande flexibilité qui permet à l utilisateur de choisir l intervalle de temps CT, et les valeurs seuils HT et ST pour que la consommation d énergie soit contrôlée par la variation de ces paramètres. Cependant, APTEEN nécessite une complexité supplémentaire pour implémenter les fonctions de seuils et de périodes de temps CT. Ainsi, le surcoût et la complexité associés à la formation des clusters à plusieurs niveaux par TEEN et APTEEN sont assez élevés VGA (Virtual Grid Architecture routing) Dans [ (62), (63)], les auteurs ont proposé une approche de clustering pour maximiser la durée de vie dans les réseaux de capteurs dont les nœuds sont immobiles ou se déplacent avec une faible vitesse. Ils ont utilisé l approche GPS-free (64) pour construire des clusters fixes, disjoints, et homogènes en taille avec des formes symétriques. Dans [ (62), (63)], la zone de déploiement des réseaux de capteurs est divisée en une topologie virtuelle rectiligne contenant des petites zones ayant la forme d un carré, et dans chacune, un nœud est choisi comme cluster head. L agrégation de données est réalisée à deux niveaux : local et global. L agrégation locale est réalisée par l ensemble des cluster heads appelés aussi Local Aggregators (LAs), alors que l agrégation globale est réalisée par un sous ensemble de LAs appelés Master Aggregators (MAs). Cependant, la détermination de l ensemble MAs est un problème NP-difficile. Les heuristiques qui ont été proposées pour former l ensemble MAs à partir de l ensemble LAs, avaient comme objectif la maximisation de la durée de vie des réseaux de capteurs. Par exemple, dans l heuristique CBAH (65) (Cluster-Based Aggregation Heuristic) proposée par les mêmes auteurs, l ensemble MAs est choisi selon la capacité des éléments de LAs. Les membres d un même cluster surveillent le même phénomène, et leurs lectures (détections) sont corrélées par leur LA correspondant. Ce dernier à son tour transmet ces données corrélées à son MA correspondant CTLMN (Clustering Technique for Large multihop Mobile wireless Networks) Lin et Chu (66) proposent une technique pour un large réseau Ad hoc. La structure de cluster est contrôlée par la distance égale au nombre de sauts. Cette technique repose sur la manière dont les nœuds sont regroupés dans un cluster en utilisant le nombre maximum de sauts R qui indique le rayon du cluster. Chaque nœud contient les informations (i, Ci, di, ni) dites informations de cluster qui sont respectivement : l ID de nœud, l ID de son cluster, le nombre de sauts à partir de CH, l ID du prochain nœud sur le chemin de cluster. Le maintien du cluster se fait comme suit : lorsqu un nœud se déplace au-delà de R, il quitte son cluster et peut rejoindre un autre cluster s il se retrouve à une distance égale à R sauts du CH (du nouveau cluster). Si la distance entre deux CHs est inférieure ou égale à un nombre prédéterminé de sauts D (Distance de cluster écartant), le CH qui a le plus grand ID est écarté, et les nœuds dans 56

57 Protocoles de routage hiérarchiques le cluster écarté cherchent un autre cluster pour le rejoindre HEED (Hybrid, Eenergy-Efficient, Distributed approach) Younes et Fahmy (67) ont proposé un algorithme de clustering distribué appelé HEED pour les réseaux de capteurs. Contrairement aux techniques précédentes, HEED ne fait aucune restriction sur la distribution et la densité des nœuds. Il ne dépend pas de la topologie du réseau ni de sa taille mais il suppose que les capteurs ont la possibilité de modifier leur puissance de transmission. HEED sélectionne les cluster-heads selon un critère hybride regroupant l énergie restante des nœuds et un second paramètre tel que le degré des nœuds. Il vise à réaliser une distribution uniforme des cluster heads dans le réseau et à générer des clusters équilibrés en taille. Un nœud u est élu comme cluster head avec une probabilité Pch égale à En Pch = Cprob ETotal où En est l énergie restante du nœud n, ETotal est l énergie globale dans le réseau et Cprob est le nombre optimal de clusters. Cependant, l évaluation de ETotal présente une certaine difficulté, à cause de l absence de toute commande centrale. Un autre problème réside dans la détermination du nombre optimal de clusters. De plus, HEED ne précise pas de protocole particulier à utiliser pour la communication entre les cluster heads et le sink. A l intérieur du cluster, le problème ne se pose pas car la communication entre les membres du cluster et le cluster head est directe (à un saut). D autre part, avec HEED, la topologie en clusters ne réalise pas de consommation minimale d énergie dans les communications intra-cluster et les clusters générés ne sont pas équilibrés en taille CSOS (Cluster-based Self-Organization algorithm for wireless Sensor networks) Les auteurs dans [ (68), (69), (70)] ont proposé une technique d auto-organisation basée sur l approche de clustering pour optimiser la consommation de l énergie dans ces réseaux. Cette technique consiste à regrouper les nœuds proches géographiquement en clusters. Elle implique des paramètres déterminants pour produire un nombre réduit de clusters homogènes en taille et en rayon, et que les clusters soient stables. Le poids de chaque capteur est calculé en fonction des paramètres suivants : la 2-densité, l énergie 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 générés est comprise entre deux seuils ThreshLower et ThreshUpper, qui représentent respectivement le nombre minimal et maximal de capteurs dans un cluster. Ces deux seuils sont choisis arbitrairement ou dépendent de la topologie du réseau. Dans un cluster, chaque capteur membre est au plus à deux sauts de son cluster-head correspondant. Le processus d élection des cluster heads est périodique après l écoulement d une certaine période t afin de distribuer équitablement la consommation de l énergie parmi les capteurs durant la durée de vie du réseau. 57

58 Protocoles de routage dans les réseaux de capteurs Dans leur technique proposée, les capteurs sont supposés avoir une connaissance topologique à deux sauts, ils peuvent modifier leur puissance de transmission, et opèrent d une manière asynchrone et sans contrôle centralisé. Chaque capteur utilise le critère poids pour élire un cluster head dans son voisinage à 2 sauts. Ce poids est calculé en fonction de la k-densité, l énergie résiduelle 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 affiliés à d autres clusters, est choisi comme cluster head pour la période courante SAR (Sensor Aggregates Routing) Fang et al. (71) ont proposé une approche de clustering pour l agrégation des données dans les réseaux de capteurs surveillant plusieurs cibles. Ces cibles peuvent être stationnaires ou se déplaçant à n importe quel moment indépendamment des états des autres cibles. L objectif de cet algorithme est de déterminer le nombre de cibles et les localisations approximatives des clusters associés aux cibles dans la zone d intérêt. Puis on surveille quand les cibles se déplacent, joignent, ou quittent la zone d intérêt. Au début, les nœuds examinent les caractéristiques spatiales des signaux associés aux cibles quand plusieurs cibles sont dans la proximité les unes des autres. Puis, ils sont groupés en clusters selon la puissance du signal détecté de sorte qu il y ait un seul pic par cluster. Un pic pourrait représenter une cible, plusieurs cibles proches, ou aucune cible quand le pic serait produit par les atténuations du signal. Le processus d élection des cluster heads se fait dans un voisinage à un seul saut et le nœud ayant le plus grand paysage de champ de signal parmi ses voisins à un seul saut se déclarera cluster-head. Ainsi, le choix des cluster heads (Sensor Aggregates) se fait selon l allocation des ressources aux tâches de détection et de communication. Dans (71), Fang et al. ont proposé trois algorithmes pour la création des nœuds qui agrègent les données (Node Aggregates) : DAM (Distributed Aggregate Management) est un protocole distribué conçu pour surveiller une cible. Il comporte un prédicat de décision P pour chaque nœud afin qu il décide s il devrait participer à l agrégation de données et un arrangement d échange de message M concernant la façon d appliquer le prédicat de groupement aux nœuds. Le but de DAM est d élire les cluster heads et maintenir les informations locales sur le paysage du signal. Dans DAM, seuls les nœuds avec une puissance de signal dépassant le seuil ThresholdElection peuvent participer au processus d élection de cluster head. EBAM (Energy-Based Activity Monitoring) est une extension de DAM. Il fournit une solution pour déterminer le nombre de cibles dans un cluster. Il suppose que chaque cible a la même puissance. Ainsi, lorsque la puissance d une cible dans un cluster est connue, le nombre de cibles peut être déduit de la puissance totale du signal dans le cluster. EMLAM (Expectation-Maximization Like Activity Monitoring) enlève la supposition que chaque cible a la même puissance. EMLAM estime les positions des cibles et l énergie du signal à travers les signaux reçus et utilise les évaluations résultantes pour prévoir comment les signaux des cibles peuvent être fusionnés dans chaque capteur. Ce processus est réitéré, jusqu à ce que l évaluation soit suffisamment bonne. 58

59 TTDD (Two-Tier Data Dissemination) Protocoles de routage hiérarchiques Dans TTDD (72), chaque nœud source crée une grille virtuelle sur le réseau. Cette grille est par la suite utilisée par le protocole de routage pour acheminer les requêtes et les données entre la source et le sink mobile. Dans TTDD, un système de localisation (comme GPS) est utilisé pour que les nœuds homogènes sachent leurs positions fixes. Une fois un événement est détecté dans le réseau, les nœuds qui l entourent traitent le signal de cet événement et un de ces nœuds devient la source et génère les rapports de données. Ce nœud source crée virtuellement la grille pour le réseau afin de préciser les nœuds de dissémination responsables de router les données vers le sink. 2.4 Conclusion Nous avons décrit dans les sections précédentes quelques protocoles de routage non hiérarchique dans les réseaux Ad-hoc et de capteurs. Lorsque le réseau visé est plus étendu, la gestion devient plus difficile lorsqu un protocole non hiérarchique est utilisé pour la gestion des communications. Chaque nœud doit stocker plus d informations concernant le réseau et ses voisins. Les exigences en taille des réseaux de capteurs, dues aux déploiements généralement étendus, rendent le stockage des informations de topologie très coûteux par rapport aux ressources disponibles dans ces dispositifs. De même, le surcoût de communications entre les nœuds devient plus important dû aux échanges additionnels de paquets. Toute communication se traduit en consommation énergétique, qui constitue un objectif de minimisation dans les réseaux de capteurs. La bande passante limitée est ainsi influée par l étendue du réseau. Nous avons aussi décrit des protocoles de routage hiérarchique dans les réseaux Ad-hoc et de capteurs. Les travaux actuels concernant le routage hiérarchique nous ont permis l identification de trois structures principales d organisation : les zones, les clusters et les chaînes (voir la Figure 2.9). Celles-ci sont à la base de la classification proposée à la fin de cette conclusion, qui résume également les caractéristiques des algorithmes de routage hiérarchique. Les zones définissent généralement un sous-ensemble de nœuds capteurs sans contrôleur central. Une forme particulière présente dans la littérature est la grille, zone bien identifiée par des surfaces carrées de taille donnée. La structure du cluster est la plus répandue : elle identifie, en plus du périmètre de la zone, un nœud particulier, le cluster head, ayant la fonction de gestionnaire de la construction et de l appartenance. Le choix des cluster heads est souvent dépendant de facteurs divers comme le niveau énergétique, les positions géographiques ou la connectivité. Les approches cluster présentent les inconvénients classiques similaires aux systèmes centralisés, car le cluster heads sont source de concentration d information et sont donc susceptibles de défaillance rapide pour des raisons de consommation énergétique. La caractéristique «point-à-point» des partitionnements en zones, dans lesquels les nœuds ont tous le même rôle, permet d éviter le goulot d étranglement dans le trafic, les points de défaillance et simplifie la gestion de la mobilité. Les chaînes, structure dans laquelle un nœud ne peut pas communiquer qu avec deux nœuds voisins, sont le résultat de la recherche des schémas 59

60 WSN Ad-hoc Protocoles de routage dans les réseaux de capteurs d agrégation qui fournissent un équilibrage de la consommation énergétique. Ce type de structure est utilisé conjointement avec les clusters, afin d améliorer les délais de transmission. Figure 2.9 : Classification des principales structures hiérarchiques d un réseau La hiérarchisation répond aux besoins d un réseau étendu, notamment un réseau de capteurs. Pour ce faire, certains protocoles exigent des informations concernant le réseau. Nous citerons la position géographique des nœuds, l énergie résiduelle des nœuds, l état des liens, etc. La position géographique peut être obtenue en utilisant des techniques de localisation ou le GPS. L information concernant l énergie des nœuds et des états des liens ne peut pas être obtenue qu à travers la communication entre les nœuds. D autres protocoles exigent des contraintes matérielles comme la possibilité de varier la puissance de transmission du nœud, une capacité de traitement adéquate, une capacité énergétique importante, une vaste mémoire, etc. Certains protocoles se basent sur la structure en cluster, d autres sur la structure en zone, et d autres sur la structure en chaîne. Un bon état de l art sur ces protocoles est décrit dans ( (73), (74)). Le Tableau 1 résume les caractéristiques principales de chaque protocole. Type hiérarchie de Information exigée sur le réseau Variation de la puissance de transmission Nombre prédéfini de clusters/zones/chaînes ZHLS Zone Position des noeuds NON NON CGSR Cluster Connectivité nœuds des NON NON CBRP Cluster Etat des liens NON NON LEACH Cluster Energie des nœuds OUI NON PEGASIS Chaîne Energie des nœuds OUI NON Hierarchical PEGASIS Chaîne + cluster Energie des nœuds OUI NON 60

61 Conclusion C 2 E 2 S Chaîne + cluster Energie des nœuds OUI NON TEEN Cluster Position des noeuds NON NON APTEEN Cluster Position des noeuds NON NON VGA Cluster Position des noeuds NON NON CTMN Cluster Position des noeuds NON NON HEED Cluster Energie des nœuds OUI NON CSOS Cluster Position des noeuds OUI NON SAR Cluster Etat des liens NON NON TTDD Zone Position des noeuds NON NON Tableau 1 : Bilan des protocoles de routage hiérachique dans les réseaux Ad-hoc et de capteurs Dans les approches de routage pour les réseaux de capteurs, les efforts ont été concentrés sur la définition d une topologie hiérarchique à deux ou plusieurs niveaux basée sur les clusters. Ces nœuds exigeant une capacité de calcul et de communication plus importante, leur choix nécessite l instrumentation du réseau, permettant d appliquer des critères de sélection. Un autre point critique est le besoin de décentralisation des décisions, surtout dans les réseaux de grande taille. En vue de ces besoins, notre objectif est de proposer un protocole de routage hiérarchique, basé sur une topologie de zone, s appuyant sur des décisions et calculs distribués. Ceux-ci ne dépendront que d informations statiques, car la mise à jour exigée par des informations dynamiques serait trop couteuse. Les réseaux visés par notre proposition de protocole de routage basé sur les zones comprennent des nœuds capteurs qui ne disposent pas d information de localisation. Ils sont fixes et ont un rayon de communication constant durant leur durée de vie. Ce nouveau protocole est décrit et détaillé dans le chapitre suivant. 61

62

63 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Chapitre 3. Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) 3.1 Introduction Un réseau de capteurs est un ensemble de capteurs qui collaborent pour contrôler et surveiller l environnement. Le nombre de capteurs peut atteindre des centaines, voire des milliers, suivant l application. L énergie et l espace de stockage dans les réseaux de capteurs sont deux caractéristiques critiques. Dans un réseau composé de milliers de capteurs, la gestion du routage et l échange de données entre les capteurs sont coûteux en termes d énergie et de capacité de stockage. Un capteur doit stocker beaucoup d informations (table de routage de taille importante dans les protocoles proactifs) afin d effectuer le routage de données. Des recherches et des travaux essayent de minimiser la consommation de l énergie en découpant le réseau en groupes afin de router les informations capturées à des niveaux différents. Dans les approches heuristiques proposées pour les réseaux de capteurs, basées sur la technique de clustering, les membres d un cluster ne transmettent pas leurs données collectées directement à la station de base mais à leur cluster head correspondant. En conséquence, les cluster heads sont responsables pour coordonner les membres du cluster, agréger leurs données capturées, 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 reçoivent plus de paquets et consomment plus d énergie pour les transmettre avec une longue portée, ils sont donc ceux dont l énergie sera épuisée le plus rapidement dans les clusters s ils sont élus pour une longue période. Par conséquent, d autres techniques devraient éviter le processus d élection des cluster heads, parce que ces derniers sont contraints par l énergie, et peuvent rapidement épuiser leurs batteries à cause de leur forte 63

64 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) utilisation. Ainsi, cela peut causer des goulots d étranglement dans les clusters et déclencher par le suite le processus de réélection des cluster heads. Dans ce chapitre, nous proposerons une nouvelle technique de partitionnement d un réseau de capteurs en zones basée sur le nombre de sauts [ (75), (76)]. La structure en zones résultante de ce partitionnement sera à la base d un nouveau protocole de routage hiérarchique à deux niveaux. Les nœuds d une zone posséderont une table de routage utilisée pour acheminer des données à l intérieur de la zone. Une deuxième table de routage est utilisée pour router des données entre les zones du réseau. Cette deuxième table n existera que chez les nœuds qui sont aux frontières des zones. Ces nœuds joueront le rôle de relais entre les zones. La Figure 3.1 montre un exemple d un réseau de capteurs partitionné en zones et d un acheminement de données entre deux nœuds de zones différentes. Figure 3.1 : Réseau de capteurs partitionné en zones Par la suite, nous détaillerons notre approche de partitionnement d un réseau de capteurs en zones. 3.2 Algorithme distribué de partitionnement d un réseau de capteurs en zones Dans notre proposition de partitionnement du réseau en zones, nous ne nous intéressons pas à l élection d un cluster head (CH), comme dans la clusterisation, car l approche visée est complètement distribuée. Les clusters présentent un fonctionnement centralisé à cause des rôles de gestionnaire de cluster et de relais de communication accordés aux CHs. Nous supposons que nous ne disposons d aucune information d instrumentation sur le réseau (par exemple, les positions des nœuds). Cette hypothèse est induite par le coût d installation exigé pour équiper les capteurs de système de géo-localisation. Dans la surveillance de grands espaces, le nombre de capteurs nécessaires pour la couverture est trop important, pour que les solutions de géo-localisation, totales 64

65 Algorithme distribué de partitionnement d un réseau de capteurs en zones ou partielles, conjointement aux techniques de triangularisation, soient économiques, efficaces et fiables. Dans ce contexte, nous considérons un déploiement aléatoire des nœuds, sans perte de généralité. Ainsi, tout autre déploiement peut être pris en compte, même celui dirigé par l utilisateur, pour lequel les positions pourraient être connues à l avance. Dans ce dernier cas, l information de localisation sera ignorée par notre protocole. Pour cela, nous avons déployé aléatoirement les nœuds. C est un déploiement sans aucune contrainte. Nous supposons que les nœuds ont une identification globale NodeId. Cette technique est basée sur le nombre de sauts (hops). Le nombre de zones est donné au départ (paramètre de l algorithme). A la fin de l exécution de l algorithme, les nœuds devraient être affectés à une seule zone. En conséquence, les zones sont disjointes. Le découpage en zones proposé est un processus distribué et a comme acteurs de déclenchement certains nœuds appelés nœuds-invitant. Ces nœuds particuliers n ont pas les fonctionnalités des cluster-heads dans les techniques de clusterisation, grâce au fait qu ils sont seulement à l initiative du lancement de la construction des zones. Ce mécanisme exige que les nœuds-invitant soient au départ assignés chacun à une zone différente et qu ils envoient des messages d invitation aux autres nœuds par propagation de proche en proche. Les nœuds recevant ces messages peuvent soit accepter, soit décliner l offre d invitation, construisant ainsi les zones. Une fois les messages initiaux d invitation envoyés, les nœuds-invitant perdent leur propriété particulière car ils n opèrent aucune gestion ultérieurement. Les points critiques dans cette phase d organisation virtuelle concernent deux aspects : le nombre de nœuds-invitant et leur choix parmi les nœuds du réseau. La définition du nombre de nœudsinvitant dépend directement du nombre total de nœuds et de la taille voulue pour chaque zone. Si la première information est disponible, la seconde ne peut pas être déduite facilement : plus il y a des nœuds-invitant, plus petite est la taille moyenne des zones et inversement. Et ceci pour un placement bien réparti des nœuds-invitant. Le choix des nœuds-invitant est donc un autre point clé pour une bonne organisation des nœuds en zones. En l absence de contrôle centralisé, ce choix est rendu encore plus difficile : comment s assurer que deux nœuds-invitant ne soient pas choisis trop proche l un de l autre? S ils sont proches, les messages d invitation risquent de ne pas arriver à tous les nœuds et par conséquent des nœuds peuvent rester en dehors de toute zone. L espace de déploiement serait ainsi que pareillement couvert par les zones. Déterminer le nombre optimal (minimal) de nœuds-invitant pour que la surface de déploiement soit entièrement couverte, sans avoir d interférence, entre les nœuds-invitant est un problème NP-complet (77). Dans un système distribué, le choix le plus simple et souvent efficace qui limite le nombre de messages échangés et réduit la perte d énergie est de désigner aléatoirement les nœuds-invitant. Dans ce contexte, nous nous sommes intéressés au pourcentage de présence des nœuds-invitant dans la proximité d autres nœuds-invitant. Nous appelons cette valeur taux des nœuds-invitant à proximité. Ce calcul s appuie sur la définition de proximité de deux nœuds-invitant. Une des pires situations serait d avoir deux nœuds-invitant avec un présent dans la portée de communication de l autre (donc ils seraient voisins à un saut). Nous définissons donc la notion de proximité de la façon suivante : un nœud v est à proximité d un nœud u si et seulement si v appartient à la portée de communication de u. 65

66 Taux Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) Le calcul de ce taux dépend du nombre de nœuds-invitant, du nombre de nœud total des nœuds et de leurs positions. Le taux est défini comme le nombre de liens de longueur inférieure à la portée de communication entre les nœuds-invitant divisé par le nombre total des liens entre tous les nœuds. Les simulations ont été faites pour des nœuds capteurs ayant une portée de communication 150m 6 et 300m dans un champ de déploiement de taille 1500m*1500m. Le nombre de nœuds est varié de 400, 500 (réseau de faible densité) à 600, 700, et 800 (réseau de forte densité). Le nombre de nœuds-invitant a été varié de 5 jusqu à 25 nœuds. Nous avons effectué 1000 itérations par simulation. Comme le montre la Figure 3.2, le taux des nœuds-invitant à proximité (avec une portée de communication Tr = 150m) ne dépasse pas 2,7* ,5E-04 3,0E-04 2,5E-04 2,0E-04 1,5E-04 1,0E-04 Tr=150, 800 nodes Tr=150, 700 nodes Tr=150, 600 nodes Tr=150, 500 nodes Tr=150, 400 nodes 5,0E-05 0,0E Nombre de noeuds invitant Figure 3.2 : Taux des nœuds-invitant à proximité (Tr= 150m) Si on double la portée (Tr = 300 m), le taux ne dépasse pas 1,2*10-3 (voir la Figure 3.3). Dans les deux cas, nous remarquons que le taux est très faible par rapport au pire de cas où tous les nœuds du réseau sont des nœuds-invitant communicant entre eux. Dans ce cas, le graphe des liens entre les nœuds est connexe et donc le taux est égal à 1. 6 La portée d un nœud capteur MICA2 66

67 Taux Algorithme distribué de partitionnement d un réseau de capteurs en zones 1,2E-03 1,0E-03 8,0E-04 6,0E-04 4,0E-04 Tr=300, 800 nodes Tr=300, 700 nodes Tr=300, 600 nodes Tr=300, 500 nodes Tr=300, 400 nodes 2,0E-04 0,0E Nombre de noeuds invitant Figure 3.3 : Taux des nœuds-invitant à proximité (Tr= 300m) Ce faible taux obtenu expérimentalement nous encourage à utiliser une distribution aléatoire des nœuds-invitant dans l algorithme de partitionnement du réseau en zones. Le choix aléatoire des nœuds-invitant est une technique qui présente l avantage d être moins coûteuse que celle utilisant un algorithme distribué d élection comme dans la clusterisation. La minimisation du nombre de messages de contrôle qui en découle permet d économiser l énergie des nœuds, et par conséquent, de prolonger la durée de vie du système. Après ce partitionnement virtuel du réseau, chaque nœud est affecté à une seule zone. Les zones sont disjointes. Les paramètres de l algorithme sont les suivants : R (rayon de la zone) - la distance maximale, en termes de nombre de sauts, entre le nœudinvitant et les nœuds invités. Par conséquence, chaque nœud à une distance (nombre de sauts) du nœud-invitant inférieure ou égale à R devrait joindre sa zone. N - le nombre de nœuds dans le réseau, zn - le nombre de zones, correspondant au nombre de nœuds-invitant. Chaque nœud spécifie durant l exécution de l algorithme les valeurs suivantes : ZoneId - l identification de la zone à laquelle le nœud appartient. Au début, cette variable a comme valeur ZONE_NodeId pour les nœuds-invitant. 67

68 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) NodeType - le type du nœud qui pourrait être NORMAL ou BORDER. Tous les nœuds ont initialement le type NORMAL. Le nœud devient de type BORDER lorsqu il est à la frontière avec une ou plusieurs zones. Ainsi, il est voisin de ces zones. BorderTable - la table-frontière dans laquelle le nœud de type «BORDER» sauvegarde les informations concernant des nœuds de type «BORDER» des zones voisines à lui. Z1 Z2 Z3 Z4 Z5 Z6 A Nœud BORDER Nœud NORMAL Figure 3.4 : Partitionnement d un réseau en zones La Figure 3.4 montre un exemple d un réseau partitionné en zones virtuelles (la forme rectangulaire est donnée à titre d exemple). Les nœuds BORDER (en blanc) joueront le rôle de relais entre les zones. Lorsqu un paquet de données passe d une zone à une autre, il parcourt ces nœuds BORDER qui peuvent être voisins de plusieurs zones (le nœud A, dans la Figure 3.4, est voisin des zones Z5 et Z3) Structure du paquet de contrôle échangé Le partitionnement d un réseau de capteurs en zones virtuelles requiert l échange des informations spécifiques. Pour cela, un paquet de contrôle particulier a été conçu. Les champs de ce paquet, appelé ConstructZonesPacket, échangé durant l exécution de l algorithme de partitionnement sont illustrés dans le Tableau 2. 68

69 Algorithme distribué de partitionnement d un réseau de capteurs en zones SrcId DestId ZoneId Subject NodeType TTL identificateur global ID du nœud émetteur du paquet identificateur global ID du nœud destinataire identificateur de la zone du nœud émetteur du paquet sujet du paquet type du nœud émetteur du paquet Time To Live, durée de vie du paquet Tableau 2 : Champs du paquet ConstructZonesPacket Le champ Subject d un paquet ConstructZonesPacket définit son sujet. Ce champ peut avoir trois valeurs différentes : INVITATION : Il s agit d un paquet d invitation à une certaine zone. Ce paquet est initialement envoyé par les nœuds-invitant. Il est rediffusé par les nœuds qui rejoignent cette zone selon leur situation. Le premier paquet diffusé par le nœud-invitant a un TTL égal à R (Rayon de la zone). DISAGREEMENT : il s agit d un paquet de refus d invitation. Ce paquet est envoyé quand un nœud, déjà attribué à une certaine zone, reçoit un paquet d invitation à une autre zone. Il sert aussi à définir les nœuds BORDER et à compléter la table BorderTable. BORDER : ce paquet est utilisé, typiquement par un nœud BORDER, pour informer ses voisins de son type. Ce paquet sert également à définir les nœuds BORDER et à compléter la table BorderTable. NEW_NODE : ce type de paquet est échangé à l apparition d un nouveau nœud dans le réseau. Il sert à attribuer ce nouveau nœud à une certaine zone. A noter que lorsqu un nœud diffuse ou envoie un message dans un réseau sans-fil, tous les nœuds dans sa portée de communication reçoivent ce message. Nous les désignerons par les nœuds voisins (à un seul saut). Par exemple, si un nœud veut envoyer un message à un destinataire spécifique, il diffuse le message en spécifiant le destinataire concerné par le message ; tous les nœuds qui sont dans la portée de communication de ce nœud reçoivent le message mais seul le nœud destinataire le traite. Donc, il ne s agit pas d un vrai unicast dans les réseaux sans fils comme dans les réseaux filaires. 69

70 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) Description de l algorithme 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 d un réseau en zones virtuelles Dans notre algorithme distribué proposé, des informations concernant les nœuds du réseau (l énergie, l état des liens, la position géographique, etc.) ne sont pas nécessaires. Chaque nœud possède un identificateur global NodeId. L algorithme exécuté par chaque nœud du réseau, d une manière distribuée, est illustré en pseudo-code dans la Figure

71 Algorithme distribué de partitionnement d un réseau de capteurs en zones Initialement, les zones sont formées des nœuds-invitant (un nœud par zone 7 ). Ces nœuds-invitant diffusent un paquet d invitation une seule fois à leurs voisins (voir la Figure 3.5, partie A). Ce paquet d invitation a un TTL égal à R (rayon de la zone). Cette partie de code n est exécutée que par les nœuds-invitant. Dans le but de spécifier le type de chaque nœud NodeType et de compléter la table-frontière BorderTable (stockant des informations utiles dans la phase de construction de la table de routage entre les zones), les nœuds échangent également des paquets dont les sujets sont DISAGREEMENT ou BORDER. La partie B de la Figure 3.5 décrit le comportement d un nœud lorsqu il reçoit un de ces deux paquets. Quand un nœud reçoit un paquet d invitation (voir la Figure 3.5, partie B.1), il le traite selon sa situation (s il est déjà affecté à une certaine zone ou pas). S il n est pas affecté, il rejoint la même zone du nœud émetteur du paquet. Si le TTL du message est égal à zéro, le nœud est alors un nœud BORDER, il diffuse à ses voisins un paquet de type BORDER de TTL égal à 1. Sinon, il rediffuse le message après avoir décrémenté son TTL de 1. Quand un nœud, déjà affecté à une certaine zone, reçoit un paquet d invitation d un nœud appartenant à une autre zone, il change son type à BORDER, puis il répond en diffusant un paquet de type DISAGREEMENT de TTL égal à 1. Lorsqu un nœud reçoit un paquet de type DISAGREEMENT ou de type BORDER d un nœud 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 nœud émetteur du paquet dans sa table BorderTable s ils n y existent pas. Si la table BorderTable a été modifiée, le nœud diffuse un paquet de type BORDER de TTL égal à 1. De cette façon, l échange des paquets BORDER s arrête lorsqu il n y a plus de nouvelles informations à insérer dans la table BorderTable. Lorsqu un nœud reçoit un paquet de type NEW_NODE (voir la Figure 3.5, partie C), ceci signifie qu il y a un nouveau nœud qui apparaît dans son voisinage. Pour cela, le nœud répond par un paquet d invitation (de type INVITATION) de TTL égal à 1 afin de joindre sa zone. A la fin de l exécution de cet algorithme, chaque nœud doit être attribué à une certaine zone et avoir défini son type. Pourtant, certains nœuds pourraient rester sans aucune affectation. Ceci dépend, en effet, des paramètres de l algorithme : le nombre de zones (zn), le rayon de la zone (R), le nombre de nœuds (N) et leurs positions. Les nœuds aux frontières (de type BORDER) possèdent une table-frontière (BorderTable) utilisée plus tard dans la phase de construction de la table de routage entre les zones. Chaque entrée de la table BorderTable contient les informations suivantes : NeighZoneId - l identification de la zone voisine avec le nœud, BorderNodesIds - la liste des nœuds appartenant à la zone voisine et qui sont en communication directe (à un seul saut) avec le nœud BORDER possédant la table BorderTable. Ces nœuds sont également des nœuds de type BORDER dans leur zone. 7 A rappeler que le nombre de nœuds-invitant est égal au nombre de zones zn (paramètre de l algorithme) 71

72 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) TimeOut la durée de vie de l entrée de la table. Cette information est utilisée pour la maintenance de la table BorderTable. Le Tableau 3 montre un exemple d une table-frontière (BorderTable) pour un certain nœud BORDER N1 qui est voisin de deux zones Z2 et Z5. N1 est en communication directe avec les nœuds N30, N18 et N17 qui appartiennent à la zone Z2 et avec les nœuds N13 et N14 qui appartiennent à la zone Z5 (voir le Tableau 3). Chaque entrée possède un TimeOut qui définit la durée de vie de l entrée. Ce champ est utile pour la maintenance des tables BorderTable expliquée plus tard. NeighZoneId BorderNodesIds TimeOut Z2 Z5 N30 N18 N17 N13 N14 T1 T2 T3 T4 T5 Tableau 3 : Exemple de table-frontière BorderTable Maintenance de la topologie La structuration du réseau en zones est réalisée lors du déploiement des nœuds sur la surface à explorer. Cependant, cette infrastructure n est pas figée à cause des événements particuliers qui sont : l apparition d un nœud, la panne d un nœud ou la mobilité d un nœud. Ceux-ci doivent être pris en compte dans la maintenance de la structure. Cette maintenance requiert généralement des informations de mise à jour des nœuds voisins lorsqu un nœud rejoint ou quitte le réseau (dû à une défaillance), et/ou lorsqu un nœud se déplace. Dans notre algorithme de partitionnement, si un nouveau nœud rejoint le réseau il doit envoyer un paquet de type NEW_NODE pour qu il se signale dans le réseau et qu il demande à être affecté à une certaine zone qui est normalement la zone de ses voisins. Le nœud qui reçoit ce paquet (voir la Figure 3.5, partie C) répond par un paquet d invitation à la zone à laquelle il appartient. Par suite, le nouveau nœud rejoindra cette zone. Supposons que le nouveau nœud reçoit plusieurs paquets d invitation à 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 défaillance des nœuds, seuls les nœuds BORDER envoient régulièrement des paquets de découverte 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 nœud émetteur et sa zone ZoneId. Il n y a pas besoin d une réponse pour ce paquet comme tous les nœuds 72

73 Algorithme distribué de partitionnement d un réseau de capteurs en zones BORDER l échangent périodiquement. Par exemple, si le nœud BORDER (possédant le Tableau 3) ne reçoit pas un paquet HELLO du nœud N30 après un TimeOut T1, l entrée sera supprimée du tableau. La défaillance d un nœud NORMAL n a aucun effet dans la topologie actuelle du réseau. Elle sera traitée plus tard dans la partie de routage où la panne d un nœud NORMAL influe la topologie. Dans les réseaux dynamiques, la mobilité des nœuds est un défi à traiter. A la fin de cette phase de partitionnement du réseau, la mobilité ne peut être gérée que si on suppose que les nœuds peuvent détecter eux-mêmes leur déplacement (par exemple en possédant un capteur vitesse). Par la suite, la mobilité d un nœud peut être interprétée dans la maintenance de la topologie comme une défaillance de ce nœud et son apparition dans le réseau à un autre emplacement géographique. Cette mobilité peut être reflétée dans notre topologie de réseau basée sur les zones de la manière suivante : un nœud se déplaçant d un endroit à un autre dans le réseau réinitialise ses attributs BorderTable et ZoneID, puis il diffuse un paquet de type NEW_NODE. Les nœuds qui reçoivent ce paquet répondent par un paquet d invitation à leurs zones. Le nœud mobile, à la réception du paquet d invitation, le traite suivant l algorithme décrit dans la Figure 3.5, partie B.1. Les protocoles de routage à base de tables utilisent des tables chez chaque nœud afin d effectuer le routage des données dans le réseau. Les protocoles hiérarchiques (à deux niveaux) à base de tables exigent des tables à deux niveaux : tables pour le routage à l intérieur d une zone et tables pour le routage entre les zones. La construction de ces deux types de tables est détaillée dans les sections suivantes, en se basant sur la topologie hiérarchique partitionnant le réseau en zones virtuelles. 3.3 Construction de la table de routage intra-zone Afin d effectuer la communication entre les nœuds d un réseau, chaque nœud doit posséder des informations sur d autres nœuds. Par exemple, il doit connaître ses nœuds voisins, d autres nœuds plus loin et le coût de communication (nombre de sauts, quantité d énergie, 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 réseau en zones, nous construirons une table de routage dans chaque zone. Chaque nœud possèdera cette table appelée dans la suite, la table intra-zone. Afin d accomplir cette phase, nous avons utilisé l algorithme Distance Vector (Bellmand-Ford) d une manière distribuée. Comme nous l avons vu précédemment, DV est simple et efficace pour les petits réseaux. Il n exige pas beaucoup de calculs, ni de communications, ni de stockage. La métrique utilisée est le nombre de sauts (hop). La méthode «Maximum Count» a été utilisée afin d éviter les boucles de routage (comme dans le protocole RIP (10)). En profitant des paquets échangés, appelés par la suite IntraZonePacket, durant la construction des tables de routage intra-zone, nous avons modifié l algorithme DV afin de définir dans la table de routage intra-zone les informations suivantes : 73

74 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) le type de chaque nœud - BORDER pour les nœuds qui sont à la frontière d une ou de plusieurs zones, NORMAL pour les autres, la/les zone(s) avec laquelle un nœud BORDER est voisin. Nous avons pu calculer également, durant l échange de ces paquets, ce que nous avons défini la métrique de la zone : c est le coût de passage à travers cette zone en termes de nombre de sauts. Cette métrique utilisée dans la phase suivante servira à la construction des tables de routage entre les zones. Nous avions six choix possibles pour calculer cette métrique. Quatre choix se basent sur le calcul de la moyenne des métriques dans chaque table intra-zone : 1. la moyenne des moyennes des métriques dans chaque table intra-zone, 2. le maximum des moyennes des métriques dans chaque table intra-zone, 3. la moyenne des moyennes des métriques des nœuds BORDER dans chaque table intrazone, 4. le maximum des moyennes des métriques des nœuds BORDER dans chaque table intrazone. et deux autres choix se basant sur le maximum des métriques dans chaque table intra-zone : 5. le maximum des maximums des métriques dans chaque table de routage intra-zone, 6. la moyenne des maximums des métriques dans chaque table de routage intra-zone. En d autres termes, c est la moyenne des plus longs chemins chez chaque nœud de la zone. Nous avions jugé que le dernier choix est le meilleur. En effet, emprunter le plus long chemin caractérise le pire des cas ; ce chemin est généralement un chemin entre deux nœuds BORDER de la zone comme ils sont à l extrémité de la zone. Si nous calculons la moyenne des métriques d une table de routage (choix 1 et 2), alors les métriques des chemins entre les nœuds NORMAL sont prises en compte dans ce calcul. Ceci ne nous intéresse pas car nous ne voulons que les métriques des chemins entre les nœuds BORDER. D ailleurs, les choix 3 et 4 ont été éliminés car le calcul de la métrique de la zone prend en compte des chemins entre des nœuds BORDER, qui ne sont pas les plus longs chemins. Les choix 5 et 6 répondent à nos attentes puisque les maximums des métriques dans toutes les tables intra-zone (les plus longs chemins) sont extraits et le calcul de la métrique est basé seulement sur ces métriques. D ailleurs nous avons préféré le choix 6 dans le but d avoir des métriques de valeurs proches pour les différentes zones. Ainsi, le passage sera équitable à travers les zones comme nous allons se baser sur ces métriques pour choisir une zone à traverser. Ainsi les petites zones ayant une faible métrique seront moins sollicitées. 74

75 Construction de la table de routage intra-zone Chaque entrée de la table de routage intra-zone est composée de quatre champs : DestNodeId l ID du nœud destinataire, NextHopId le nœud suivant à emprunter afin d atteindre la destination. C est le nœud auquel le message sera transféré, Metric la métrique du chemin. C est le coût en termes de nombre de sauts pour atteindre la destination DestNodeId, NodeType le type du nœud (BORDER ou NORMAL), ZoneIds la liste des IDs des zones auxquelles le nœud destinataire DestNodeId est voisin, TimeOut la durée de vie de l entrée dans la table. Z 1 Z2 Nœud BORDER Z3 Nœud NORMAL N2 N4 N3 N0 N8 N9 N6 N1 N5 N7 Figure 3.6 : Exemple d une répartition de nœuds dans trois zones Le Tableau 4 montre une table de routage intra-zone chez le nœud BORDER N6 qui appartient à la zone Z2 illustrée dans la Figure 3.6. Comme nous le remarquons, les entrées des nœuds BORDER N1 et N4 contiennent la zone (Z1) avec laquelle ces nœuds sont voisins. 75

76 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) DestNodeId NextHopId Metric NodeType ZoneIds TimeOut N0 N7 2 NORMAL T0 N1 N7 4 BORDER Z1 T1 N2 N9 2 NORMAL T2 N3 N7 3 NORMAL T3 N4 N7 3 BORDER Z1 T4 N5 N7 3 NORMAL T5 N6 N6 0 BORDER Z3 T6 N7 N7 1 NORMAL T7 N8 N7 2 NORMAL T8 N9 N9 1 NORMAL T9 Tableau 4 : Table de routage intra-zone chez le nœud N6 La section suivante décrit la phase de construction de la table entre les zones. Cette table sert à router les données d une zone à une autre à travers les nœuds BORDER. 3.4 Construction de la table de routage inter-zones Après avoir partitionné le réseau en zones et avoir construit les tables de routage intra-zone (IntraZoneRoutingTable) dans chaque nœud, une table est nécessaire pour le routage entre les zones. Le principe de l algorithme distribué Distance Vector (Bellman Ford) est aussi appliqué pour la construction de cette table. Seuls les nœuds BORDER la posséderont car ils feront le relais entre les zones durant l échange des paquets de données. A la fin de cette phase de construction, les nœuds BORDER de la même zone auront la même table. D ailleurs, elle est différente d une zone à une autre. Cette table est appelée par la suite table inter-zones Structure du paquet échangé La construction des tables inter-zones requiert, comme pour les tables intra-zone, des paquets de contrôle particuliers. La structure de ce paquet de contrôle échangé durant cette phase, appelé InterZonesPacket, est illustrée dans le Tableau 5. 76

77 Construction de la table de routage inter-zones SrcId NextHopId FinalDestId ZoneId Subject ZoneTable identificateur global ID du nœud émetteur du paquet identificateur global ID du nœud suivant à emprunter afin d atteindre la destination identificateur global ID du nœud destinataire final du paquet identificateur de la zone du nœud émetteur du paquet sujet du paquet table inter-zone échangée Tableau 5 : Structure du paquet de contrôle InterZonesPacket La table inter-zones échangée dans le champ ZoneTable du paquet peut être une partie de la table (des mises à jour de la table). Le nœud destinataire du paquet (FinalDestId) peut savoir si la table est complète ou non à partir de la valeur du champ Subject Algorithme distribué de construction des tables inter-zones Afin d éviter la redondance des calculs et pour ne pas charger le réseau par l échange des paquets de contrôle (InterZonesPacket), un nœud BORDER est désigné comme le chef des nœuds BORDER dans une même zone. Ce nœud, appelé nœud-chef, sera le représentant de la zone durant cette phase. Les nœuds-chef des zones s échangent des paquets afin d établir la table interzones. Ce sont les nœuds qui ont le plus grand identificateur parmi les nœuds BORDER de leurs zones. Les nœuds peuvent extraire cette information à partir de la table de routage intra-zone (par exemple, N6 est le nœud-chef de la zone Z1 dans la répartition illustrée dans la Figure 3.6). Par ce fait, nous avons réduit le nombre de messages échangés dans le réseau. Normalement, tous les nœuds BORDER devront participer à la construction de la table de routage inter-zones comme ils en auront besoin durant le routage de données. Pourtant, un seul nœud BORDER a été désigné pour faire ce travail. Puis, à la fin de la construction de cette table, il la diffuse aux autres nœuds BORDER dans sa zone. Par la suite, le type du nœud-chef sera CHIEF-BORDER. L algorithme est constitué de deux phases : phase d initialisation et phase d échange des tables inter-zones. a) Phase d initialisation Rappelons que chaque nœud-chef possède pour l instant deux tables : une table frontière (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 nœud-chef extrait une nouvelle structure de données, la table inter-zones. Une entrée dans cette table contient trois champs : DestZoneId - la zone destination, 77

78 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) NextZoneId - la zone suivante à emprunter, ZoneM - la métrique pour atteindre la zone destination DestZoneId. Au début, la table inter-zones contient des informations de base. Reprenons l exemple du nœudchef N6 qui appartient à la zone Z2 et qui dispose d une table de routage intra-zone (voir le Tableau 4) et d une table-frontière (voir le Tableau 3). Supposons que la métrique de la zone Z2 est égale à 7. La table inter-zones chez le nœud-chef N6 est illustrée dans le Tableau 6. DestZoneId NextZoneId ZoneM Z1 Z1 7 Z3 Z3 7 Tableau 6 : Table inter-zones chez N6 appartenant à la zone Z2 Nous remarquons dans le Tableau 6 que les métriques pour toutes les zones destinations ont la même valeur. En fait, cette métrique, déjà calculée dans la phase de construction de la table intrazone, est le coût de passage à travers la zone Z2. Comme toutes les zones destinations dans cette table sont initialement des zones voisines à la zone Z2, alors leurs métriques sont les mêmes : le coût de passage à travers la zone Z2. Nous remarquons aussi que la zone suivante à emprunter NextZoneId a la même valeur que DestZoneId, ceci est dû au fait que ces zones destinatrices sont des zones voisines à Z2. En d autres termes, cette table inter-zones contient, dans la phase d initialisation, les informations concernant les zones voisines de la zone courante. b) Phase d échange des tables inter-zones Avant de détailler l algorithme distribué de construction des tables de routage inter-zones (InterZoneRoutingTable), nous citerons la structure de données existante jusqu à cette étape dans les nœuds du réseau. Chaque nœud possède : NodeId, NodeType, ZoneId et la table de routage intra-zone (IntraZoneRoutingTable). Si le nœud est un noeud BORDER, il possède de plus la table-frontière BorderTable. Si le nœud est un nœud-chef (de type CHIEF-BORDER), il dispose de plus de la table inter-zones (InterZoneRoutingTable). Le nœud-chef, dans chaque zone, lance l exécution de l algorithme distribué. Cette première étape est illustrée en pseudo-code dans la Figure 3.7. Il envoie au départ (Figure 3.7, partie A) sa table inter-zones aux nœuds BORDER de sa zone d une manière optimisée (un seul nœud par zone). Puis, il l envoie aux nœuds BORDER des zones voisines à lui (Figure 3.7, partie B) de la même manière optimisée (un seul nœud par zone). 78

79 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 d envoi de la table inter-zones par le noeud-chef Ces paquets envoyés par les nœuds-chef de chaque zone seront traités par les nœuds du réseau suivant l algorithme illustré dans la Figure 3.8. A noter que durant l exécution de l algorithme, les métriques pour atteindre les zones destinations sont également calculées. Décrirons l algorithme. Lorsqu un nœud NORMAL n reçoit un paquet (Figure 3.8, partie A), il le transfère au nœud suivant pour atteindre le destinataire final par un routage intra-zone. Si n est le nœud-chef (Figure 3.8, partie B), il met à jour sa table InterZoneRoutingTable. Si cette table n est pas encore complète, n envoie les mises à jour aux nœuds BORDER de sa zone (un nœud par zone) et des zones voisines à lui (un nœud par zone). Si la table est complète, n l envoie à tous les nœuds BORDER de sa zone. Si n n est pas le nœud-chef mais un nœud BORDER (Figure 3.8, partie C) et que le paquet reçu arrive d une autre zone, il le transfère au nœud-chef par un routage intra-zone. Si le paquet a été reçu de sa zone et qu il lui est destiné (paquet envoyé par le nœud-chef), n le transfère aux nœuds BORDER des zones voisines à lui (un nœud par zone) lorsqu il s agit d un paquet de mise à jour de la table inter-zones (UPDATE_TABLE). Sinon, n sauvegarde la table de routage complète inter-zones. Si le paquet n est pas destiné au noeud n (il n est pas le destinataire final), il transfère le paquet au nœud suivant pour atteindre le destinataire final par un routage intra-zone. 79

80 Protocole hiérarchique 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

81 Construction de la table de routage inter-zones A la fin de l exécution de l algorithme distribué, tous les nœuds BORDER dans le réseau possèdent une table inter-zones qui servira au routage entre les zones. Cette table inter-zones est évidemment la même chez les nœuds BORDER de la même zone et différente de celles des autres zones Exemple de table inter-zones Dans cette section, nous montrons un exemple de table inter-zones. La Figure 3.9 illustre un réseau découpé en 9 zones virtuelles (zones en rectangle à titre d exemple). Chaque zone a une métrique (valeurs entre parenthèses). Nous nous intéressons dans cet exemple aux liens entre les zones (désignés par des flèches entre les nœuds BORDER) et aux tables inter-zones. S il y a une ou plusieurs flèches entre deux zones, ceci veut dire que ce sont deux zones voisines. Z 1(4) Z2(7) Z3(8) Nœud BORDER Z4(5) Z5(7) Z6(5) Nœud NORMAL Z7(3) Z8(4) Z9(5) Figure 3.9 : Réseau découpé en 9 zones La table inter-zones chez les nœuds BORDER de la zone Z1 de la Figure 3.9 est illustrée dans le Tableau 7. Nous remarquons que la métrique des zones voisines de Z1 (Z2 et Z4) est égale à la métrique de la zone Z1. Un chemin d une zone courante (dans notre exemple Z1) à une zone destination a un coût égal à la somme de la métrique de la zone courante et des métriques des zones intermédiaires 81

82 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) DestZoneId NextZoneId ZoneM Z2 Z2 4 Z3 Z2 11 Z4 Z4 4 Z5 Z4 9 Z6 Z4 16 Z7 Z4 9 Z8 Z4 12 Z9 Z4 16 Tableau 7 : Table de routage inter-zones des nœuds BORDER da la zone Z1 3.5 Scénario de routage de données Le routage efficace des données entre les nœuds d un réseau est le but des protocoles de routage. Dans cette section, nous décrirons algorithmiquement comment les nœuds échangent les donnés en se basant sur notre approche hiérarchique décrite précédemment Structure du paquet de données SrcId LocalDestId NextHopId FinalDestId DestZoneId Data identificateur global ID du nœud émetteur du paquet identificateur global ID du nœud destinataire local identificateur global ID du nœud suivant à emprunter afin d atteindre la destination locale identificateur global ID du nœud destinataire final du paquet identificateur de la zone destinataire données transmises Tableau 8 : Structure d un paquet DataPacket Lorsque les nœuds veulent échanger des données, ils génèrent un paquet de données, appelé 82

83 Scénario de routage de données DataPacket, dont la structure est illustrée dans le Tableau 8. Le champ FinalDestId définit le dernier nœud qui doit recevoir les données Data. Ce champ a toujours la même valeur dans le paquet échangé entre la source et la destination. D ailleurs, le champ LocalDestId définit le champ du nœud destinataire local, c est-à-dire le destinataire à l intérieur d une zone. En effet, afin de router un paquet, le routage est réalisé par le routage interne (dans la zone) et le routage externe (entre les zones). Le champ LocalDestId est utilisé pour router le paquet à l intérieur d une zone. FinalDestId et LocalDestId ont la même valeur lorsque le paquet arrive à la zone destination, définie par DestZoneId, qui contient le nœud destinataire final (FinalDestId) Détails de l application du scénario de routage Rappelons que chaque nœud du réseau possède la structure suivante : NodeId, NodeType, ZoneId, IntraZoneRoutingTable. S il est un nœud BORDER, il possède de plus les deux tables BorderTable et InterZoneRoutingTable. Un nœud source n voulant émettre un paquet de données à un nœud destinataire n applique l algorithme illustré dans la Figure Si les deux nœuds appartiennent à la même zone, un routage intra-zone aura lieu (Figure 3.10, partie A). Dans le cas contraire, le nœud source envoie le paquet selon son type. Si le nœud source n est un nœud NORMAL (Figure 3.10, partie B), il cherche dans sa table de routage intra-zone s il y a un nœud voisin de la zone d appartenance du nœud destinataire. S il en trouve un, il lui transfère son paquet de données. S il n en trouve pas, cela signifie que la zone destination n est pas une zone voisine de sa zone. Dans ce cas, il transfère son paquet de données à un des nœuds BORDER. Si le nœud source n est un nœud BORDER (Figure 3.10, partie C) et voisin de la zone destination, il transfère le paquet de données à un des nœuds BORDER de la zone destination. S il n est pas voisin de la zone destination, mais un autre nœud BORDER de sa zone l est, il lui transfère le paquet de données. Le cas échéant, le nœud n cherche dans la table inter-zones la zone suivante pour atteindre la zone destination. S il est voisin de la zone suivante trouvée, il transfère le paquet de données à un des nœuds BORDER de cette zone. S il ne l est pas, il transfère le paquet à un nœud BORDER de sa zone mais qui est voisin de la zone suivante trouvée dans la table interzones. Après l envoi du premier paquet par le nœud source, chaque nœud du réseau, afin d acheminer le paquet jusqu au nœud destinataire, transfère le paquet suivant les données de routage dont il dispose. Le comportement de chaque nœud du réseau, à la réception d un paquet de données, est détaillé dans la Figure

84 Protocole hiérarchique 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 l envoi d un paquet de données 84

85 Scénario de routage de données 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 réception d un paquet de données 85

86 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) Si un nœud n reçoit un paquet de données dont il est le destinataire final, il traite les données du paquet (Figure 3.11, partie A). S il ne l est pas, le nœud n vérifie s il appartient à la même zone que le nœud destinataire final du paquet afin de lui transférer le paquet par un routage intra-zone (Figure 3.11, partie B). S ils se trouvent dans deux zones différentes, le comportement du nœud est implémenté dans la partie C de la Figure Si le nœud n est NORMAL, il transfère le paquet au nœud destinataire local (Figure 3.11, partie C.1). Si le nœud n est BORDER et voisin de la zone destination du paquet, il transfère le paquet à un nœud BORDER de cette zone (Figure 3.11, partie C.2). Si le nœud n n est pas voisin de la zone destination du paquet, mais un autre nœud BORDER de sa zone l est, il lui transfère le paquet par un routage intra-zone (Figure 3.11, partie C.3). Si aucun nœud de sa zone n est voisin de la zone destination du paquet, il cherche dans sa table inter-zones la zone suivante à emprunter afin d atteindre la zone destination. Il transfère le paquet à un nœud BORDER de cette zone suivante, s il en est voisin (Figure 3.11, partie C.4). Sinon, il transfère le paquet à un nœud 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 nécessaire lorsqu il y a une défaillance, une apparition ou une mobilité d un nœud. L algorithme Distance Vector (DV) permet aux nœuds d envoyer périodiquement les mises à jour de la table de routage afin de connaître les modifications de la topologie. D ailleurs, dans notre protocole et contrairement à DV, après avoir fini la construction de la table intra-zone (IntraZoneRoutingTable), nous utilisons des messages de contrôle périodiques 8, appelés HELLO, afin de détecter une défaillance ou une apparition d un nœud et par la suite de mettre à jour les tables. Si un nœud détecte un lien brisé (dû à la non réception d un message HELLO d un nœud voisin après l expiration de son TimeOut), il met à jour sa table et envoie ces mises à jour à ses voisins qui appliquent, à leur tour, la même procédure. Ainsi, l information du lien brisé se propage dans la zone sous forme des mises à jour des tables intra-zone. Si ce nœud défaillant était un nœud BORDER, les nœuds BORDER des zones voisines peuvent connaître cette nouvelle (lien brisé) lors de l échange périodique des paquets de contrôle (comme HELLO). Par la suite ils mettent à jour leurs tables-frontière BorderTable. L intérêt de l envoi périodique, durant la maintenance des tables, des messages - de petite taille - HELLO est de minimiser la quantité de données échangées (table entière dans DV) entre les nœuds. Par conséquent, la consommation énergétique des nœuds est minimisée et la vie du système est prolongée. Ainsi la convergence de la nouvelle information (nouveau nœud, défaillance, mobilité) est plus rapide surtout lorsque le délai entre les envois réguliers est court. 8 Paquets avec un intervalle de temps paramétrable 86

87 Maintenance des tables de routage Si un nouveau nœud apparaît dans le réseau, il envoie un paquet de type NEW_NODE afin d être affecté à une certaine zone (comme mentionné précédemment dans la section de partitionnement du réseau en zones). Une fois ce nœud affecté à une zone, il échange des paquets de contrôle 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 l algorithme Distance Vector. Si ce nouveau nœud constate qu il est un nœud BORDER (suite à une réception de paquets d invitation de différentes zones), sa table-frontière BorderTable qu il possède est aussi mise à jour par les paquets de contrôle échangés entre lui et les nœuds à un seul saut des zones voisines. De la même manière que dans la phase de partitionnement en zones, la mobilité d un nœud peut être traitée comme une défaillance du nœud dans l emplacement où il était et son apparition dans le nouvel endroit. Donc, il envoie un paquet de type NEW_NODE afin d être affecté à une certaine zone après avoir réinitialisé ses attributs (à l exception de NodeId) comme s il est un nouveau nœud. Puis il échange des paquets de contrôle DV pour construire sa table intra-zone. De même, s il devient un nœud BORDER il construit sa table-frontière BorderTable en échangeant des paquets avec les nœuds à un seul saut des zones voisines. Notons que dans les trois cas précédents, la métrique de la zone (coût de passage à travers la zone) est recalculée en utilisant les paquets DV. En ce qui concerne les tables inter-zones (InterZoneRoutingTable), si la métrique d une certaine zone a changé d une manière significative (l écart entre l ancienne valeur et la nouvelle valeur est grand), alors la procédure de construction des tables inter-zones est relancée par le nœud-chef de la zone. Ainsi, les tables inter-zones dans toutes les zones seront mises à jour. La détection du déplacement d un nœud par le nœud lui-même reste un point clé pour enclencher la gestion de la mobilité. Les capteurs peuvent ne pas disposer de mécanismes physiques permettant d identifier le mouvement (comme par exemple les détecteurs de vitesse ou les équipements permettant la localisation géographique). Dans ces cas, une solution logicielle devrait être employée. Dans notre approche, un nœud peut constater qu il a été déplacé s il ne reçoit plus des messages périodiques HELLO d un certain nombre de ses voisins et en reçoit des nœuds non listés dans sa table intra-zone. D ailleurs l envoi et la réception des paquets ConstructZonePacket, IntraZonePacket, InterZonePacket, et DataPacket ne peuvent pas indiquer la mobilité d un nœud. 3.7 Conclusion Dans ce chapitre, nous avons décrit un protocole distribué de routage dans un réseau de capteurs étendu. Ce protocole est basé sur une topologie hiérarchique issue d un découpage du réseau en zones virtuelles. L algorithme distribué de partitionnement du réseau en zones que nous avons proposé ne requiert pas préalablement d informations sur le réseau (par exemple, énergie des nœuds, états des 87

88 Protocole hiérarchique de routage basé sur les zones (ZHRP - Zone-based Hierarchical Routing Protocol) liens, positions géographiques des nœuds, etc.). Ce partitionnement est basé sur le nombre de sauts. Les zones sont disjointes. A la fin du découpage du réseau en zones virtuelles, chaque nœud devrait être affecté à une certaine zone. Nous classifions les nœuds en deux types : BORDER si le nœud est à la frontière d une ou plusieurs zones et NORMAL dans le cas contraire. Les nœuds BORDER jouent le rôle de relais entre les zones. Nous n effectuons pas de clusterisation et nous ne nous intéressons pas à l élection des clusters head qui exige généralement des informations sur le réseau et provoque de la consommation énergétique. Contrairement aux protocoles basés sur la clusterisation qui exigent généralement plus de ressources matérielles pour certains nœuds (comme les cluster heads), nous n imposons pas cette contrainte pour l utilisation de notre protocole de routage. Le routage des données, dans notre protocole, se réalise à deux niveaux : intra-zone et interzones. Nous parlons de routage intra-zone lorsque le paquet de données est acheminé à l intérieur d une zone. Lorsqu il s agit du passage du paquet d une zone à une autre, nous parlons de routage inter-zones. Le routage se réalise d une manière complètement distribuée et ne dispose pas d une centralisation comme dans la clusterisation (les nœuds envoient leurs paquets aux cluster heads qui les transmettent à la station de base). Chaque nœud du réseau possède une table de routage dont la construction est basée sur l algorithme Distance Vector (Bellman-Ford). Cette table sert au routage intra-zone. Les entrées de cette table, chez un tel nœud, contiennent les informations de routage vers tous les autres nœuds de la même zone. Durant la phase de construction de la table intra-zone, des informations concernant les nœuds (s ils sont NORMAL ou BORDER, leurs zones voisines, etc..) ont pu être découvertes et la métrique de chaque zone a été calculée. Cette métrique est définie comme le coût de passage à travers la zone. Cette information est utile pour le routage inter-zones. Comme les nœuds BORDER servent de relais entre les zones, ils possèdent une table utilisée pour le routage interzones. Cette table est également construite en se basant sur l algorithme Distance Vector. Chaque entrée de cette table contient les informations de routage de la zone courante vers les autres zones. Nous avons décrit aussi, dans ce chapitre, des algorithmes de maintenance des tables de routage (intra-zone et inter-zones) utiles lors d une défaillance, d une apparition ou d un déplacement d un certain nœud. Cette maintenance est basée sur l envoi périodique des paquets de contrôle HELLO entre les nœuds. Notre protocole de routage se distingue de la plupart des autres protocoles hiérarchiques par les caractéristiques suivantes : notre protocole est complètement distribué, l algorithme de partitionnement du réseau en zones n exploite aucune information sur le réseau (position des nœuds, niveau énergétique, etc.), le protocole s appuie sur l algorithme Distance Vector qui est simple et non coûteux pour la construction des tables de routage, adapté aux larges réseaux de capteurs, 88

89 Conclusion la maintenance des tables de routage s effectue par des envois périodiques de petits messages HELLO, ce qui est une amélioration de l algorithme Distance Vector qui transmet régulièrement toute la table. 89

90

91 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Chapitre 4. Expérimentations et résultats 4.1 Introduction Dans ce chapitre, nous évaluons le protocole de routage proposé précédemment. Une des caractéristiques principales des réseaux de capteurs visés est la taille de ces réseaux. Le nombre important de capteurs nécessaires pour la couverture de l espace surveillé et les principes du protocole de routage proposé constituent les arguments pour l utilisation d un simulateur afin d évaluer notre proposition. Cependant, une analyse de fiabilité de l implémentation sur un système réel sera également présentée dans le dernier chapitre, déclinée en deux types d applications. Nous commencerons par une description du simulateur J-Sim que nous avons utilisé pour établir les simulations. Ensuite, nous montrerons les résultats de simulations et évaluerons notre protocole suivant quatre métriques : le taux d erreur, le surcoût, la durée de vie du système, l espace de stockage et la scalabilité. Nous définissons le taux d erreur par le pourcentage de nœuds isolés restant sans affectation à aucune zone. Le surcoût sera évalué par le nombre de messages de contrôle envoyés et reçus durant l exécution du protocole. Une évaluation du niveau énergétique de la batterie des nœuds sera réalisée également. La durée de vie du système sera calculée par rapport au nombre d événements qui pourront être effectués. Nous estimerons aussi l espace de stockage requis pour la structure de données utilisée pour le routage (tables et attributs). Enfin, nous montrerons le bon comportement de notre protocole de routage dans des réseaux 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 pseudoparallèles. Dans J-Sim c est à l utilisateur (programmeur) de créer la simulation. Le simulateur est programmé en Java. Pour modifier le comportement du simulateur, il est nécessaire de compléter ou de modifier ses fichiers sources. J-Sim repose sur une structure 91

92 Expérimentations et résultats logicielle basée sur des composants, appelée «Autonomous Component Architecture» (ACA). Le code source est organisé en paquetages relatifs à un type de composants. Un composant est une entité indépendante représentant un objet physique (une batterie, un module radio, une couche logicielle, etc.) ou logique (un protocole de routage, un modèle de mobilité, etc.). Ces composants seront ensuite connectés à l aide de ports afin de générer un réseau simulé. La simulation du fonctionnement d un réseau de capteurs, qui exige la définition des composants et leur mise en relation, est réalisée grâce à un langage spécifique, TCL (81). Il s agit d un langage de script dans lequel on spécifie l architecture du réseau ainsi que les paramètres de simulation et d analyse. Les commandes de script peuvent également être fournies en ligne de commande, instruction par instruction. A l aide de TCL, on définit les composants puis on les connecte. Tous les composants sont hébergés dans un conteneur, qui est à son tour un composant. La définition des composants est en fait la création des objets. Cette création est réalisée par la commande TCL mkdir. Chaque composant est d une entité indépendante (la couche MAC par exemple) qui fonctionne indépendamment des autres entités. Les composants possèdent des ports par défaut pour qu ils puissent communiquer entre eux. D autres ports peuvent être créés pour un composant. Une connexion entre deux composants est réalisée par l intermédiaire de deux ports dédiés, un dans chaque composant (voir la Figure 4.1). Cette connexion est matérialisée par la commande TCL connect. Il suffit de suivre un schéma qui indique l interconnexion entre les différents types de composants que l on veut utiliser. On obtient ainsi l architecture du nœud. Toujours dans ce script TCL, on y définit les paramètres globaux (par exemple la taille du champ de simulation), les outils de visualisation des résultats et l ordonnancement de la simulation. composant port connexion Figure 4.1 : Connexions entre composants dans J-Sim On distingue trois types de nœuds : target, sink et sensor. Les nœuds target ont pour fonction de générer des signaux (stimuli) qui peuvent être, par exemple, une secousse sismique, un bruit, etc. Le nœud sink est quant à lui le nœud cible, celui où les informations doivent arriver. Le reste du réseau est formé par les nœuds sensor qui acheminent les paquets jusqu au nœud sink. Lorsqu un nœud target envoie un stimulus et qu il est capté par un nœud sensor, ce dernier crée un paquet contenant l information de mesure pour la faire parvenir au nœud sink via le réseau. 92

93 Le simulateur J-Sim La Figure 4.2 (partie en pointillé) montre l architecture interne d un nœud sensor dans J-Sim. On y distingue notamment les composants CPU et Radio qui définissent les modèles de la consommation énergétique du microcontrôleur et de l antenne radio. Le composant CPU décrit en principe le coût de traitement des instructions. Le composant Radio décrit le coût de l envoi et la réception des signaux et la mise en veille. Le composant Battery définit le modèle de la batterie d un nœud. Ce composant calcule la consommation énergétique due au traitement des instructions, envois et réceptions des signaux en se basant sur les modèles du CPU et de Radio. Un programmeur peut facilement créer ses propres modèles (CPU, Radio, Battery) et les insérer dans un scénario de simulation afin de les tester. A noter que seuls les nœuds sensor sont dotés d une batterie. La Figure 4.2 montre aussi que les composants des différentes couches d un nœud sont séparés (Network layer, Mac Layer, Physical Layer). Ils communiquent entre eux via des ports. Les connexions (désignées par des flèches) entre les composants peuvent être unidirectionnelles ou bidirectionnelles. Une connexion unidirectionnelle d un composant C1 vers un composant C2 signifie que les informations peuvent être envoyées dans une seule direction (de C1 à C2). D autre part, une connexion bidirectionnelle signifie un échange d information dans les deux directions. Le composant Wireless Channel est le composant commun pour tous les nœuds sensor du réseau. Il fait communiquer tous les nœuds sensor entre eux. Chaque nœud sensor du réseau doit avoir une connexion, réalisée par le programmeur, avec ce composant. Le cas échéant, le nœud ne peut pas communiquer avec les autres nœuds. Le composant Sensor Channel est responsable de la communication entre les nœuds target et les nœuds sensor. De même, chaque nœud (sensor ou target) doit avoir une connexion avec ce composant. Si, par exemple, un tel événement est créé par un nœud target, ce composant envoie l information à tous les nœuds sensor qui entourent le target (la distribution des nœuds et leurs positions dans le champ de simulation sont définies dans le fichier TCL). Notons qu il existe plusieurs simulateurs dans la littérature tels que GlomoSim (82), OMNET++ (83), OPNET (84), NS-2 (85). Figure 4.2 : Architecture interne d un noeud sensor dans J-Sim (78) 93

94 Expérimentations et résultats 4.3 L architecture détaillée de J-Sim Le composant L entité de base dans l architecture logicielle de J-Sim est le composant. Nous définissons une application en réalisant une composition de composants. La notion des composants n est pas nouvelle et a été employée dans plusieurs normes composant telles que JavaBeans, CORBA et COM/DCOM/COM+. A la différence des JavaBeans, de CORBA, et de COM/DCOM, les composants dans J-Sim sont faiblement connectés (loosely coupled). Ils communiquent entre eux en connectant leurs ports ensemble, et sont liés par des contrats. Les contrats indiquent la causalité des informations envoyées/reçues entre les composants, mais n indiquent pas les composants qui participent à la communication Le port Un composant communique avec les autres composants par l intermédiaire de ses ports. Il peut posséder plus d un port. L interface de programmation entre un composant et son port est bien définie. Un composant peut être développé sans la présence d autres composants (il se doit d être autonome). En outre, le mécanisme réel de communication qu un composant emploie pour communiquer avec le reste du monde est complètement caché par la notion de port Le contrat La communication entre composants est décrite par les contrats. Le contrat impose les conditions sur les ports d entrée/sortie des composants afin de les faire communiquer. Un contrat indique comment un initiateur (visiteur) et un réacteur (appelé) accomplissent une certaine communication. Il décrit comment un composant répond aux données qui arrivent à chacun de ses ports (par exemple, comment le composant traite les données, certaines structures de données de mises à jour, et produit des sorties à certains ports) Langage utilisé pour définir un scénario de simulation Bien que J-Sim soit écrit en Java, les scénarios de simulation ne sont pas décrits en Java (car ce processus serait trop complexe). La combinaison des langages Java et TCL ne facilite pas cette tâche. Pour développer un grand projet, il peut devenir encombrant d employer des commandes TCL/Java parce que les références des objets Java doivent être stockées dans des variables TCL afin d y accéder. Pour simplifier la syntaxe des simulations il existe un système appelé RUntime Virtual (RUV). Ce système s appuie sur la similitude entre les systèmes composants et les systèmes de fichiers d UNIX. L analogie entre un composant/port et un chemin de fichier permet d accéder au composant de la même manière que l on accède à un dossier dans un système de fichiers. 94

95 L architecture détaillée de J-Sim D ailleurs des commandes systèmes UNIX, telles que ls, cd, pwd, mkdir, cp, mv, et rm peuvent être utilisées pour manœuvrer des composants et des ports dans le système. Les ports ont une utilisation particulière pour le nommage : a@b (où a est le nom du port et b le groupe du port). En résumant, des composants peuvent être créés et ils peuvent être liés grâce à une interface de commande qui utilise la syntaxe des invités de commandes (shells) Modèle de transmission dans J-Sim Comme la plupart des simulateurs de réseau, J-Sim possède un modèle propre de transmission. L utilisateur peut à tout moment implémenter son propre modèle 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 côté gauche). Un nœud définit sa portée de transmission comme suit : il peut communiquer seulement avec les nœuds appartenant à son sous-champ et avec ceux dans les sous-champs voisins. La Figure 4.3 (côté gauche) montre un nœud A et ses nœuds voisins qu il peut atteindre en un seul saut. Il peut communiquer avec les nœuds appartenant aux neuf sous-champs grisés : 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 nœuds communicants. Selon le modèle de transmission de J-Sim, ce rayon est la diagonale du carré formé par quatre sous-champs (voir la Figure 4.3, côté droit). Ainsi, ce rayon peut être calculé en utilisant la formule Tr = 2 (dx²+dy²). Le côté droit de la Figure 4.3 décrit le comportement de trois nœuds communicants dans J-Sim en se basant sur le modèle de transmission décrit précédemment. Le nœud A ne peut pas communiquer avec le nœud C qui n appartient à aucun sous-champ des neuf en gris (portée de transmission de A) même si la distance d entre eux est inférieure à Tr. Cependant, le nœud A peut communiquer avec le nœud B qui appartient à un des neuf sous-champs en gris. Ce modèle de 95

96 Expérimentations et résultats propagation est spécifique à J-Sim, qui n utilise donc ni le modèle théorique sphérique ni celui de voisinage qui en découle et est indépendant d une distance constante entre l émetteur et le récepteur. Ceci peut traduire une simulation de l atténuation du signal à cause des obstacles ou d autres facteurs (par exemple antenne unidirectionnelle). Dans nos simulations, nous avons modifié le code d implémentation de J-Sim de façon à avoir un rayon de transmission sphérique pour les nœuds du réseau car la gestion des obstacles dans le simulateur J-Sim n est pas simple et les simulations se font généralement dans les conditions idéales. 4.4 Evaluation du protocole de routage proposé Dans J-Sim, un module dédié aux réseaux de capteurs est incorporé dans le paquetage drcl.inet.sensorsim. On y retrouve les classes concernant les composants suivants : les nœuds (sensor, target et sink), le canal des nœuds sensor (sensor channel), le modèle de propagation des signaux radio (le canal radio, la couche physique, la couche Mac), le modèle de batterie, le modèle de CPU, le modèle radio pour chaque nœud et le protocole de routage. Nous utiliserons le simulateur J-Sim, afin d évaluer l efficacité du protocole de routage proposé dans ce rapport. Quatre métriques ont été prises en compte : le taux d erreur, le surcoût (overhead), l espace de stockage exigé et la scalabilité. Le partitionnement du réseau en zones affecte les nœuds à une zone particulière. Idéalement, chaque nœud du réseau devrait être membre d une zone. Suivant les paramètres du protocole et le déploiement des nœuds dans le réseau, nous évaluons l efficacité de notre protocole proposé en termes de pourcentage des nœuds non affectés à aucune zone (nœuds isolés), défini comme le taux d erreur. Une autre métrique particulière d évaluation est le surcoût généré. Nous l estimons par le nombre de paquets envoyés et reçus et le niveau énergétique de la batterie (86). Une des métriques d évaluation principales pour un protocole de routage dans un réseau de capteurs est l espace de stockage. Nous l évaluons par le nombre de bits occupés par la structure de données intervenant dans les algorithmes (tables de routage et attributs). Les trois métriques précédentes dépendent de la taille du réseau. La scalabilité d un protocole de routage est une des caractéristiques importantes pour un réseau de capteurs de grande taille. Pour cela, nous évaluons aussi le comportement du protocole proposé lors de la variation de la taille du réseau de capteurs. Les simulations ont été exécutées dans un espace de 1500m*1500m. Le rayon maximal de transmission est de 150m. Dans nos simulations nous avons fait varier la taille du réseau de 400 à 600 nœuds Evaluation du taux d erreur Cette évaluation montre l efficacité de la phase de partitionnement du réseau en zones. Le but est de savoir combien de nœuds du réseau restent sans affectation à aucune zone. Pour cela, nous avons défini le taux d erreur comme le pourcentage des nœuds non affectés à aucune zone (nœuds isolés) après le partitionnement du réseau. Il est évalué en fonction de deux paramètres de l algorithme : le rayon de la zone (R) et le nombre de zones (zn). 96

97 Taux d'erreur (%) Taux d'erreur (%) Evaluation du protocole de routage proposé R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.4 : Taux d erreur pour 400 nœuds Les figures (Figure 4.4, Figure 4.5, et Figure 4.6) montrent les taux d erreur pour des réseaux constitués respectivement de 300, 400 et 600 nœuds. Les graphes montrent que le taux d erreur atteint zéro sauf dans le cas où le rayon de la zone R a la valeur 5. Ceci s explique par le fait qu il y a des nœuds dans le réseau qui n ont pas reçu un paquet d invitation car le rayon R est petit. 4,5 4 3,5 3 2,5 2 1,5 1 R=5 R=10 R=15 R=20 R=25 0, Nombre de zones Figure 4.5 : Taux d erreur pour 500 nœuds 97

98 Taux d'erreur (%) Expérimentations et résultats 3,5 3 2,5 2 1,5 1 R=5 R=10 R=15 R=20 R=25 0, Nombre de zones Figure 4.6 : Taux d erreur pour 600 noeuds Evaluation du surcoût Dans cette sous-section nous présentons le surcoût dû au partitionnement du réseau en zones et la construction des tables intra-zone et inter-zones. Comme nous l avons déjà défini, le surcoût est évalué par le nombre moyen de paquets de contrôle reçus et envoyés durant l exécution des algorithmes (de partitionnement et de construction des tables). La moyenne est réalisée sur le nombre de nœuds du réseau. Nous présenterons les graphes selon les deux phases : le partitionnement du réseau en zones et la construction des tables de routage. a) Phase de partitionnement du réseau en zones Figure 4.7, Figure 4.8 et Figure 4.9 montrent le nombre de paquets envoyés par chaque nœud du réseau durant la phase de partitionnement en zones pour 400, 500 et 600 nœuds respectivement en fonction du nombre de zones et du rayon de la zone (R). Les figures montrent que le nombre de paquets envoyés est faible et ne dépasse pas 16 paquets/nœud 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 nœuds ; ceci s explique par le fait que l augmentation du nombre de nœuds-invitant (nombre de zones) aboutit à une augmentation du nombre de paquets d invitation envoyés. De même, lorsque le rayon de la zone et le nombre de nœuds sont plus grands, les paquets d invitation sont rediffusés plus largement pour atteindre des nœuds plus éloignés du nœud invitant. 98

99 Nombre de paquets envoyés Nombre de paquets envoyés Evaluation du protocole de routage proposé 5,5 5 4,5 4 3,5 3 2,5 2 1,5 R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.7 : Nombre de paquets envoyés durant la phase de partitionnement en zones pour 400 nœuds 6 5,5 5 4,5 4 3,5 R=5 R=10 R=15 R=20 R=25 3 2, Nombre de zones Figure 4.8 : Nombre de paquets envoyés durant la phase de partitionnement en zones pour 500 nœuds 99

100 Nombre de paquets reçus Nombre de paquets envoyés Expérimentations et résultats 7,5 7 6,5 6 5,5 5 4,5 4 R=5 R=10 R=15 R=20 R=25 3, Nombre de zones Figure 4.9 : Nombre de paquets envoyés durant la phase de partitionnement en zones pour 600 nœuds 16,00 15,00 14,00 13,00 12,00 11,00 R=5 R=10 R=15 R=20 R=25 10, Nombre de zones Figure 4.10 : Nombre de paquets reçus durant la phase de partitionnement en zones pour 400 nœuds Les figures (Figure 4.10, Figure 4.11, et Figure 4.12) montrent le nombre de paquets reçus par chaque nœud du réseau durant la phase de partitionnement du réseau pour 400, 500 et 600 nœuds respectivement. Ce nombre ne dépasse pas 24 paquets/nœud dans le pire des cas (Figure 4.12, R = 25, nombre de zones = 25, N=600). 100

101 Nombre de paquets reçus Nombre de paquets reçus Evaluation du protocole de routage proposé 19, , , ,5 R=5 R=10 R=15 R=20 R= , Nombre de zones Figure 4.11 : Nombre de paquets reçus durant la phase de partitionnement en zones pour 500 nœuds 24 23, , , ,5 20 R=5 R=10 R=15 R=20 R=25 19, Nombre de zones Figure 4.12 : Nombre de paquets reçus durant la phase de partitionnement en zones pour 600 nœuds La même remarque que dans les graphes des paquets envoyés 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 nœuds. Ceci s explique par le fait que l augmentation du nombre de nœuds-invitant (nombre de zones) aboutit à une augmentation du nombre de paquets d invitation envoyés dans le 101

102 Expérimentations et résultats réseau, et par suite cela augmente le nombre de paquets reçus. De même, lorsque le rayon de la zone et le nombre de nœuds sont plus grands, les paquets d invitation sont rediffusés plus largement pour atteindre des nœuds plus éloignés du nœud invitant. Ceci engendre l augmentation du nombre de paquets reçus. D ailleurs si nous comparons les graphes des paquets envoyés et ceux des paquets reçus pour un même nombre de nœuds, nous remarquons que le nombre de messages reçus ne dépasse pas quatre fois le nombre de ceux envoyés. Ceci s explique par le fait que les nœuds, après l affectation à la zone, rediffusent les paquets d invitation ; les nœuds voisins, qui sont déjà affectés à la même zone, reçoivent ces paquets mais ne répondent pas et ne rediffusent pas ces paquets. Donc ils reçoivent plus de paquets qu ils en envoient. Le coût énergétique qui en découle est moins pénalisant que dans le cas d un nombre d envois supérieur au nombre de réceptions, car le coût d envoi d un paquet est généralement plus coûteux (3 à 4 fois) que le coût de réception pour un capteur. En conclusion, les graphes de simulations montrent clairement que l algorithme de partitionnement génère un faible surcoût. Ceci est dû au nombre faible des paquets de contrôle envoyés et reçus afin de réaliser le partitionnement du réseau en zones. Ce faible surcoût engendre aussi une faible consommation énergétique de la batterie. b) Phase de construction des tables de routage Dans cette sous-section, nous évaluerons le surcoût dû à la construction des tables de routage intra-zone et inter-zones dans les nœuds après la phase de partitionnement du réseau en zones. Les réseaux utilisés dans nos simulations sont composés de 400, 500 et 600 nœuds. Ils ont la même distribution de nœuds lors de la phase de partitionnement dont nous avons montré les résultats dans la sous-section précédente. Les figures (Figure 4.13, Figure 4.14, et Figure 4.15) montrent le nombre de paquets envoyés par chaque nœud du réseau durant la phase de construction des tables de routage pour 400, 500 et 600 nœuds respectivement en fonction du nombre de zones et du nombre de nœuds. 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 s explique par le fait que lorsque le le nombre de zones est fixe, les zones ont presque la même taille (en termes de nombre de nœuds). De ce fait, les tables de routage ont presque la même taille et exigent presque le même nombre de paquets de contrôle (envoyés 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 dépasse pas 50 paquets/nœud. 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 paramètres de l algorithme qui s amortissent dans cette phase. Et puisque la taille des tables de zones dépend de la taille de la zone, alors le nombre de paquets à envoyer pour la construction de ces tables dépend de la taille de la zone. 102

103 Nombre de paquets envoyés Nombre de paquets envoyés Evaluation du protocole de routage proposé R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.13 : Nombre de paquets envoyés durant la phase de construction des tables de routage pour 400 nœuds R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.14 : Nombre de paquets envoyés durant la phase de construction des tables de routage pour 500 nœuds 103

104 Nombre de paquets envoyés Expérimentations et résultats R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.15 : Nombre de paquets envoyés durant la phase de construction des tables de routage pour 600 nœuds Les figures (Figure 4.16, Figure 4.17 et Figure 4.18) montrent le nombre de paquets reçus par nœud durant la phase de construction des tables de routage intra-zone et inter-zones pour 400, 500 et 600 nœuds respectivement en fonction du nombre de zones et du rayon de la zone (R). Depuis ces figures, la même remarque que dans les graphes des paquets envoyés 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 s explique aussi par le fait que lorsque le nombre de zones est fixe, les zones ont presque la même taille. De ce fait, les tables de routage ont presque la même taille et exigent presque le même nombre de paquets de contrôle (reçus dans ces figures) pour la construction des tables de routage. Dans ces trois figures et pour les différentes valeurs du rayon de la zone (R), nous remarquons aussi que les courbes décroisent rapidement lorsque le nombre de zones est petit (5 à 10) et augmentent lentement lorsque le nombre de zones est supérieur à 15. La décroissance rapide des courbes s explique par le fait que lorsque le nombre de zones augmente, le nombre de nœuds dans chaque zone diminue car le nombre de nœuds est fixe. Par conséquent, les nœuds d une zone auront besoin de moins d échanges de paquets de contrôle 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 contrôle 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. D ailleurs, lorsque le nombre de zones devient plus important (supérieur à 15), la construction de la table inter-zones induit un surcoût plus élevé qu avant même si celui-ci reste raisonnable. Ce surcoût explique la croissance faible des courbes lorsque le nombre de zones est supérieur à

105 Nombre de paquets reçus Nombre de paquets reçus Evaluation du protocole de routage proposé R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.16 : Nombre de paquets reçus durant la phase de construction des tables de routage pour 400 nœuds R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.17 : Nombre de paquets reçus durant la phase de construction des tables de routage pour 500 nœuds 105

106 Nombre de paquets reçus Expérimentations et résultats R=5 R=10 R=15 R=20 R= Nombre de zones Figure 4.18 : Nombre de paquets reçus durant la phase de construction des tables de routage pour 600 nœuds En conclusion, les graphes de simulations montrent le faible surcoût durant la phase de construction des tables de routage. En fait, cette phase dépend directement de la taille des zones qui influe la taille des tables de routage. Ainsi, le nombre de paquets de contrôle pour la construction de ces tables dépend de la taille des zones. Les graphes montrent bien que les deux paramètres de l algorithme, le nombre de zones (zn) et le rayon de la zone (R), s amortissent concernant la taille des zones. Ce qui aboutit à un faible surcoût. c) Consommation de la batterie Consommation CPU Consommation réception radio Consommation transmission radio Energie initiale de la batterie Voltage Taux de transfert de données Portée de communication 8 mah 10 mah 27 mah 2900 mah 3 V bits/s 500 ft Tableau 9 : Caractéristiques d un capteur MICA2 106

107 Consommation de la batterie (%) Consommation de la batterie (%) Evaluation du protocole de routage proposé En se basant sur le modèle énergétique des capteurs MICA2 (23), nous avons calculé la consommation énergétique de la batterie. Les caractéristiques d un capteur MICA2 sont illustrées dans le Tableau 9. Nous avons fait varier le nombre de nœuds de 400 à 600 et avons pris les valeurs intermédiaires du nombre de zones et du rayon de la zone (10, 15 et 20). 3,44E-04 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 Nombre de noeuds - N Figure 4.19 : Pourcentage de la consommation énergétique de la batterie en variant le rayon de la zone R La Figure 4.19 montre le pourcentage de la consommation énergétique de la batterie d un capteur MICA2 en fonction du rayon de la zone et du nombre de nœuds dans le réseau durant l exécution du protocole de routage proposé en fixant le nombre de zones à 15. De même, la Figure 4.20 montre ce pourcentage en fonction du nombre de zones et du nombre de nœuds dans le réseau en fixant le rayon de la zone à 15. 3,64E-04 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 Nombre de noeuds - N Figure 4.20 : Pourcentage de la consommation énergétique de la batterie en variant le nombre de zones zn Ces deux figures montrent clairement la faible consommation énergétique du protocole. Elle ne dépasse pas le 3,5*10-4 % de la batterie dans le pire des cas (600 nœuds) dans les deux figures. 107

108 Expérimentations et résultats En conclusion, nous pouvons remarquer que le nombre de paquets reçus est plus important que celui des paquets envoyés. Cette différence est due principalement au modèle de communication utilisé dans les réseaux de capteurs : un paquet envoyé par un nœud peut être reçu par plusieurs nœuds dans sa portée de communication. Comme nous l avons dit, cette différence n est pas gênante car le coût énergétique d envoi d un paquet est généralement plus important (trois à quatre fois) que celui de la réception dans les réseaux sans fil. L ensemble des graphes décrits dans cette section montre l efficacité énergétique de notre protocole Evaluation de la durée de vie Dans le but de montrer l efficacité énergétique du protocole ZHRP durant le routage des données, nous avons effectué des simulations d échange de données entre les différents nœuds du réseau. Les simulations ont été exécutées dans un espace de 300m*300m, le rayon maximal de transmission est égal à 50m, le nombre de nœuds 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é réalisée durant 6 minutes. Le nombre d événements a varié de 5 à 12 chaque 60 ms (voir le Tableau 10). Un événement est un envoi d un paquet de données d un certain nœud à un autre nœud, les deux étant choisis d une manière aléatoire. A noter que nous n avons pas pu aller plus loin dans les simulations à cause du simulateur J-Sim (basé sur Java) qui exigeait des ressources puissantes (mémoire, CPU, ets.) pour des simulations à grande échelle. Evénements chaque 60 ms Evénements durant 6 minutes Tableau 10 : Nombre d'événements durant la simulation Consommation CPU Consommation réception radio Consommation transmission radio Energie initiale de la batterie Voltage Taux de transfert de données Portée de communication 1,5 mah 23 mah 21 mah 2900 mah 3 V bits/s 50 m Tableau 11 : Caractéristiques d un capteur Tmote SKY En se basant sur le modèle énergétique des capteurs Tmote SKY (87) illustré dans le Tableau 11, 108

109 Durée de vie du système (jours) Consommation de la batterie (%) Evaluation du protocole de routage proposé nous avons calculé la moyenne de la consommation énergétique par chaque nœud du réseau. 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 Nombre d'événements durant 6 minutes Figure 4.21 : Pourcentage de la consommation énergétique de la batterie Les fgures (Figure 4.21 et Figure 4.22) montrent les résultats des simulations. Dans la Figure 4.21, le pourcentage de la consommation de la batterie ne dépasse pas 4*10-3 % de l énergie initiale de la batterie d un nœud lorsqu on atteint le maximum d envois (72000 événements durant 6 minutes). Ceci prouve l efficacité énergétique du protocole ZHRP durant le routage de données. D autre part, la Figure 4.22 montre la durée de vie du système en nombre de jours en effectuant des événements périodiques chaque 6 minutes. La durée de vie du système est définie par la mort du premier nœud dans le réseau. Cette figure montre le système peut durer longtemps en utilisant le protocole ZHRP malgré le grand nombre d échange de données Nombre d'événements chaque 6 minutes Figure 4.22 : Durée de vie du système avec des événements périodiques 109

110 Expérimentations et résultats Evaluation de la taille de l espace de stockage Un des points critiques dans le fonctionnement d un réseau de capteurs concerne l espace de stockage nécessaire à la fois pour le système d exploitation et pour le stockage éventuel des données récoltées. Nous nous sommes intéressés, pour la première fois dans la littérature à notre connaissance, à la taille exigée par les structures de données intervenant dans le protocole de routage. Cette métrique traduit une complexité espace pour les algorithmes déroulés dans un capteur. Une estimation théorique de la taille de l espace est montrée dans le Tableau 12, en fonction du nombre de nœuds dans le réseau N, du nombre de zones zn, et du nombre de nœuds BORDER dans le réseau nb. La structure utilisée est de type short dont la taille est 2 octets. Cet espace est alloué principalement par les attributs d un nœud qui définissent 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-frontières. Dans la phase de partitionnement en zones, un nœud NORMAL possède quatre attributs de type short : NodeId, ZoneId, NodeType, et R (rayon de la zone). Les nœuds BORDER possèdent en plus la table BorderTable. Cette table est implémentée comme un vecteur de taille estimée à (nb/zn)*6 short. La valeur nb/zn est la moyenne du nombre de nœuds BORDER dans une zone. D autre part, tous les nœuds du réseau possèdent l attribut ZoneM (métrique de la zone) et une table de routage intra-zone. La taille estimée pour cette table qui possède six champs de type short dépend du nombre de nœuds dans le réseau N et du nombre de zones zn. Les nœuds BORDER possèdent en plus la table de routage inter-zones qui a trois champs de type short dont les tailles sont dépendantes de N et zn. Partitionnement en zones Construction des tables de routage Nœud NORMAL 4* N zn 2 Nœud BORDER (4+6*(nB/zN))*2 (3 zn N zn) 2 Tableau 12 : Taille théorique de l espace de stockage (en octets) de la structure de données de routage Nous avons également évalué expérimentalement la taille de l espace de stockage demandé pour la structure de données utilisée pour le routage. Le résultat illustré dans le Tableau 13 est donné pour un réseau de 600 nœuds (N), R = 15 et zn=15. Ce résultat d expérimentation confirme l estimation donnée dans le cas général. Une moyenne de 4 Kb par nœud est nécessaire pour stocker les informations de données pour le routage. Cette capacité représente 15 % de la mémoire totale d un capteur MICA2. 110

111 Evaluation du protocole de routage proposé Partitionnement en zones Construction des tables de routage Taille totale de l espace de stockage Nœud NORMAL octets = 3,82 Kb Nœud BORDER octets = 4,71 Kb Tableau 13 : Taille expérimentale de l espace de stockage (en octets) pour la structure de données de routage dans un réseau de 600 nœuds Evaluation de la scalabilité La scalabilité d un protocole de routage est son aptitude à conserver ses propriétés fonctionnelles malgré le changement en taille du réseau. Les résultats illustrés dans les sous-sections précédentes (taux d erreur, surcoût et complexité de stockage) montrent la scalabilité de notre protocole de routage car nous remarquons que les graphes sont quasiment stables et ne génèrent pas un écart entre les résultats quand la taille du réseau varie entre 400 et 600 nœuds. En ce qui concerne les taux d erreur, nous avons vu que le taux d erreur atteint zéro dans la plupart des cas. Dans le réseau le plus large (600 nœuds) le protocole est très efficace. D autre part, le nombre de messages de contrôle (surcoût) dans un réseau large (600 nœuds) est très raisonnable et ne montre pas un écart surprenant avec un petit ou un moyen réseau (400 et 500 nœuds). Ceci est montré clairement dans les figures du pourcentage de la consommation énergétique de la batterie (Figure 4.19 et Figure 4.20) ; la consommation énergétique du protocole de routage dans un réseau de 600 nœuds est raisonnable et ne s éloigne pas beaucoup des valeurs de consommation des réseaux composés de 400 et 500 nœuds. Si nous regardons les équations des estimations générales de l espace de stockage, surtout celles de la construction des tables de routage, on voit qu elles dépendent linéairement du nombre de nœuds. Et par suite, l augmentation du nombre de nœuds n influe pas fortement sur la taille de l espace de stockage. Notons que nous ne pouvions pas simuler un réseau composé de plus de 600 nœuds avec le simulateur J-Sim et les ressources matérielles que nous possédons. Ces simulations (partitionnement et construction des tables des zones) du protocole s arrêtaient à cause d un bug de mémoire insuffisante produit par la machine virtuelle Java. D ailleurs, nous avons réussi à simuler la phase de partitionnement du réseau en zones pour 800 nœuds. A titre d exemple, la Figure 4.23 montre le partitionnement d un réseau de 800 nœuds en 10 zones avec R = 10. Dans cet exemple, nous avons simulé les obstacles (J-Sim original). Nous remarquons qu il n y a que 3 nœuds non affectés à une zone. Ceci s explique par le fait qu ils n ont pas reçu de paquets d invitation à cause des obstacles ou de la petite valeur du rayon de la zone R. 111

112 Expérimentations et résultats Figure 4.23 : Partitionnement d un réseau de 800 nœuds en 10 zones 4.5 Conclusion Dans ce chapitre, nous avons décrit brièvement 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 scénarios de simulation en utilisant un système appelé RUV. Ensuite, nous avons montré l efficacité du protocole de routage suivant les métriques suivantes : taux d erreur, le surcoût, l espace de stockage et la scalabilité. Les résultats de simulations ont montré un taux d erreur qui est voisin de zéro. D autre part, une consommation énergétique très faible a été montrée par les résultats pour un réseau de capteurs MICA2. Ceci est dû au faible surcoût du protocole. Nous avons également montré l efficacité du protocole durant le routage de données, ce qui prolonge la vie du système. Nous avons aussi estimé l espace de stockage requis pour la structure de données du protocole. Cet espace est faible et ne représente que 15% de la mémoire d un capteur MICA2. Pour terminer, nous avons montré la scalabilité du protocole en se basant sur des simulations faites pour des réseaux de taille importantes. 112

113 [CONCEPTION D UN PROTOCOLE DE ROUTAGE HIERARCHIQUE POUR LES RESEAUX DE CAPTEURS] Chapitre 5. Mise en œuvre du protocole de routage 5.1 Introduction Le rôle d un système d exploitation est de permettre le développement fiable d applications en fournissant une abstraction commode et sûre des ressources matérielles. Dans les PCs et les serveurs, le système d exploitation permet à l application de traiter les tâches sur les processeurs, dresse la carte d adresses virtuelles des emplacements dans la mémoire, manipule les disques, gère les réseaux et les périphériques. La séparation entre système d exploitation et applications dans le calcul conventionnel est moins flagrant dans le monde des systèmes embarqués, où les applications utilisent nécessairement du matériel particulier. De plus, les ressources matérielles sont très contraintes. Les réseaux de capteurs sans fil (WSNs) doivent supporter une variété d applications utilisant des composants hétérogènes et capables de se déployer rapidement dans de nouveaux environnements. La gestion de réseaux sans fil exige un traitement simultané plus important que les réseaux câblés. Lorsqu un nœud WSN effectue son acquisition de données normale, il doit aussi effectuer des événements de routage et des transferts de paquet qui surgissent d une manière asynchrone dans le réseau. Dans ce chapitre, nous présenterons tout d abord brièvement deux plateformes d exploitation pour les capteurs. Ensuite, nous décrirons la mise en place d un système «réseau de capteurs» basé sur notre proposition de routage. Nous montrerons aussi le fonctionnement du système lors de l acquisition de données. Enfin, nous détaillerons deux applications réelles pour montrer l utilité de notre protocole. 113

114 Mise en œuvre du protocole de routage 5.2 Plateformes d exploitation pour les capteurs TinyOS TinyOS (88) est un système d exploitation intégré, modulaire, destiné aux réseaux de capteurs. Cette plate-forme logicielle open-source est composée d une série d outils développés par l Université de Berkeley. En effet, TinyOS est le plus répandu des OS (Operating System) pour les réseaux 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 développement de cet OS en fournissant de nouveaux modules, de nouvelles applications, etc. La librairie TinyOS comprend les protocoles réseaux, les services de distribution, les drivers pour capteurs et les outils d acquisition de données (90). Le système TinyOS, ses librairies et ses applications sont écrits en nesc (91), un nouveau langage pour le développement d applications orientées composants. Le langage nesc est principalement dédié aux systèmes embarqués comme les réseaux de capteurs. NesC a une syntaxe proche du langage C mais supporte le modèle concurrent de TinyOS ainsi que des mécanismes pour la structuration, le nommage et l assemblage de composants logiciels en des systèmes réseaux embarqués fiables. L objectif principal est de permettre aux concepteurs d applications de construire des composants qui peuvent être composés rapidement en des systèmes complets, concurrents, tout en permettant une vérification profonde à la compilation (91). TinyOS définit un nombre important de concepts qui sont exprimés dans nesc. Premièrement, les applications nesc sont construites à partir de composants ayant des interfaces bidirectionnelles bien définies. Deuxièmement, nesc définit un modèle de concurrence basé sur les notions de tâches, les "handlers" d événements matériels, et la détection des conditions d accès concurrent aux données au moment de la compilation SPOT (Small Programmable Object Technology) SUN Miscrosystems a réalisé une plateforme logicielle et matérielle homogène, appelée SPOT ( (92), (93)), qui permet de programmer des capteurs en Java. SPOT est l assemblage d une carte avec le processeur central, une carte rassemblant les différents capteurs ou une station d émission 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 adaptée aux capteurs ainsi que des outils de développement et de débogage. SPOT permet aux développeurs de concevoir des applications pour les capteurs directement en Java, donc de ne plus utiliser un langage de bas niveau complexe comme nesc. 114

115 Plateformes d exploitation pour les capteurs Figure 5.1 : Capteur SPOT fabriqué par SUN Microsystems (94) SPOT utilise une machine virtuelle de type J2ME mais de taille réduite appelé «Squawk Virtual Machine» (95) écrite en Java. L avantage de Squawk VM est sa capacité à utiliser de manière plus performante le peu d espace mémoire que possèdent les capteurs. Cette machine virtuelle fonctionne sans OS et permet une communication directe avec l unité de traitement (CPU), ce qui augmente les performances des applications (96). 5.3 Description et mise en place du système Dans la suite de cette section, nous décrirons l utilité et le fonctionnement de notre système basé sur le protocole ZHRP. Nous découpons cette opération en plusieurs étapes Première étape : injection du protocole dans le capteur Cette première étape consiste à injecter le protocole de routage dans le capteur. Comme nous l avons dit précédemment, chaque capteur possède un système d exploitation pour gérer les ressources matérielles. Ce système doit être open-source afin que nous puissions modifier le code source ou y intégrer notre propre implémentation. En utilisant les capteurs MICA2 fabriqués par Crossbow, le protocole de routage doit être codé en langage nesc afin de l injecter dans ce genre de capteurs possédant le système d exploitation TinyOs. NesC est un langage orienté composant, conçu pour incarner les concepts de structuration et d exécution du système TinyOS. Il propose une architecture basée sur des composants, permettant de réduire la taille mémoire du système TinyOS et de ses applications. Un composant peut être un concept abstrait ou un élément matériel tel que des LEDs ou un timer, il peut être réutilisé dans différentes applications. Ces applications sont des ensembles de composants associés entre eux dans un but précis. En nesc, les composants présentent des similarités avec des objets. Les états sont encapsulés et on peut y accéder par des interfaces. L implémentation des composants est réalisée par la déclaration des tâches, des commandes ou des événements. En outre, l ensemble des composants et leurs interactions sont fixés à la compilation ce qui permet d optimiser l application pour une exécution plus performante. NesC permet de déclarer deux types de fichiers : les configurations et les modules. Le fichier configuration est la définition du ou des composants 115

116 Mise en œuvre du protocole de routage qui seront utilisés par l application déployée sur le capteur. Les modules constituent les briques élémentaires du code et implémentent une ou plusieurs interfaces. Les interfaces spécifient un ensemble de fonctions à mettre en application par le fournisseur de l interface (commandes) et par l utilisateur de l interface (événements). Ceci permet à une interface simple de représenter une interaction complexe entre les composants (par exemple, enregistrement d un événement pertinent, suivi d un rappel de service quand cet événement se produit). En outre, les interfaces permettent de lier statiquement les composants entre eux. Ceci augmente l efficacité d exécution, favorise la robustesse de l application, et permet une meilleure analyse statique du programme de l application. TinyOS est prévu pour fonctionner sur diverses plateformes. En effet, TinyOS peut aussi bien être installé sur Windows, Linux, Mac OS ou sur un capteur. Cependant il n est pas possible de faire des allocations dynamiques ni utiliser des pointeurs. L installation du protocole de routage nécessite la mise en place de TinyOS et du langage nesc. Pour cela il faut installer : MoteWorks qui est un ensemble de logiciels permettant de développer facilement des programmes pour les capteurs sous Windows, MoteView qui est un logiciel permettant de visualiser et analyser les données envoyées par les capteurs, Cygwin qui permet l émulation d un système Unix sous Windows (inclus dans MoteWorks). TinyOS 2.x inclut un outil de liaison entre les nœuds et une application Java : SerialForwarder (voir la Figure 5.2 ). Celui-ci récupère les messages reçus par le nœud et les transmet à l application Java. L inverse est aussi possible, l application Java peut envoyer des messages au nœud, par exemple le Sink, qui va les transmettre aux autres nœuds. Figure 5.2 : Capture d écran de l outil SerialForwarder 116