simulateur : omnet++theses.univ-oran1.dz/document/th3828.pdf · remerciement mes remerciements...

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur de la Recherche Scientifique

Mémoire Magister : Informatique,option : Analyse, Commande et Surveillance des Systemes

Thème :

Analyse Graphique pour la surveillance dans unréseau de capteurs sans fils (RCSF )Simulateur : OMNET++

Par : Leila Imane NIAR

Soutenue en ..JUILLET 2012 ..devant le jury composé de

Mr. Mustapha Kamel RAHMOUNI PrésidentMr. Bouabdellah KECHAR ExaminateurMr. Mejdi KADDOUR ExaminateurMr. Mohammed FEHAM ExaminateurMr. Hafid HAFFAF Encadreur

Remerciement

Mes remerciements s’adressent à mon encadreur H.HAFFAF , pourson aide, ses encouragements, et ses critiques constructifs qui m’ontbeaucoup aidé à apprécier ce travail et à mieux éclairer mes perspec-tives. Je suis reconnaissante à lui, particulièrement pour la confiancequ’il m’a fait.

Je tiens à remercier les membres du jury pour m’avoir fait le plaisird’accepter d’examiner ce travail.

Je tiens à remercier également ma famille et mes amis(es), ce tra-vail n’aurait certainement jamais vu le jour sans leurs aides, et leurssoutiens, je tiens vivement à les remercier.

ii

Dédicace

Pour Père, Mère, Sœur et frères

Table des matières

Résumé : xiii

Introduction Générale xiv

1 Présentation des Réseaux de capteurs sans fil 21.1 Les Réseaux sans fil . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Le réseau personnel sans fil . . . . . . . . . . . . 41.1.2 Le réseau local sans fil (WLAN) . . . . . . . . . 51.1.3 Le réseau métropolitain sans fil (WMAN) . . . 61.1.4 Le réseau étendu sans fil (WWAN) . . . . . . . . 6

1.2 Les réseaux Ad Hoc . . . . . . . . . . . . . . . . . . . . 71.2.1 Caractéristiques des réseaux Ad Hoc . . . . . . 7

1.3 Les réseaux de capteurs sans fil (RCSF) . . . . . . . . . 71.3.1 Architecture d’un nœud capteur . . . . . . . . . 81.3.2 Organisation d’un nœud capteur . . . . . . . . . 91.3.3 Architecture d’un réseau de capteurs . . . . . . 121.3.4 Les types d’architectures des RCSF . . . . . . . . 131.3.5 Les differentes topologies des RCSF : . . . . . . 14

1.3.5.1 La Topologie en étoile : . . . . . . . . . 141.3.5.2 La topologie en grille : . . . . . . . . . 141.3.5.3 La topologie hybride : . . . . . . . . . . 15

1.3.6 La collection d’information : . . . . . . . . . . . 151.3.6.1 À la demande : . . . . . . . . . . . . . . 151.3.6.2 Suite à un évènement : . . . . . . . . . 15

TABLE DES MATIÈRES iv

1.3.7 Les principales caractéristiques des RCSF . . . 171.3.8 Les domaines d’application . . . . . . . . . . . . 181.3.9 La consommation d’énergie dans les RCSF . . . 19

1.3.9.1 Les principaux opérations dûes à laconsommation d’énergie . . . . . . . . 19

1.3.9.2 Modèle de consommation d’énergie . . 211.3.9.3 Les facteurs intervenants dans la consom-

mation d’énergie . . . . . . . . . . . . . 221.3.10 Le routage dans les RCSF . . . . . . . . . . . . . 24

1.3.10.1 Exemples de protocoles de routage . . 241.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28

2 La surveillance des Réseaux de Capteurs Sans Fil 312.1 La supervision des RCSF . . . . . . . . . . . . . . . . . 33

2.1.1 Les Pannes . . . . . . . . . . . . . . . . . . . . . 332.1.1.1 Classification des pannes . . . . . . . . 33

2.1.2 Solution architecturale tolérante aux pannes dansles RCSF . . . . . . . . . . . . . . . . . . . . . . . 35

2.1.3 Aspect de surveillance d’un RCSF . . . . . . . . 372.1.3.1 Méthodologie de déploiement : . . . . 372.1.3.2 Connectivité du réseau . . . . . . . . . 382.1.3.3 La couverture . . . . . . . . . . . . . . 392.1.3.4 Longévité du réseau . . . . . . . . . . 39

2.1.4 La redondance . . . . . . . . . . . . . . . . . . . 402.1.4.1 La redondance Matérielle . . . . . . . 402.1.4.2 La redondance analytique . . . . . . . 42

2.2 Systèmes Multi-agents . . . . . . . . . . . . . . . . . . . 432.2.1 Caractéristiques des Systèmes Multi-Agents . . 43

2.3 Les Travaux Antérieurs . . . . . . . . . . . . . . . . . . 442.4 Description de l’approche distribuée (décentralisée) . . 47

2.4.1 Topologie du réseau . . . . . . . . . . . . . . . . 47

TABLE DES MATIÈRES v

2.4.2 Définition des rôles . . . . . . . . . . . . . . . . 472.4.2.1 Algorithme d’attribution de rôle . . . . 49

2.5 Le protocole de routage adopté . . . . . . . . . . . . . . 502.5.1 Les Diagrammes UML . . . . . . . . . . . . . . . 51

2.5.1.1 La détection du voisinage . . . . . . . 522.5.2 Changement de rôles : . . . . . . . . . . . . . . . 532.5.3 Détection des groupes voisins . . . . . . . . . . 542.5.4 Vérification de la cohérence des groupes : . . . . 542.5.5 Résolution de conflits entre représentants . . . 552.5.6 Gestion de la redondance . . . . . . . . . . . . . 56

2.5.6.1 Le principe suivi pour gérer la redon-dance : . . . . . . . . . . . . . . . . . . . 57

2.5.6.2 Mécanisme de détection des pannes . 582.5.7 Collecte d’information . . . . . . . . . . . . . . . 59

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3 Simulation de la surveillance en RCSF 623.1 Généralités sur la simulation . . . . . . . . . . . . . . . 643.2 Types de simulation . . . . . . . . . . . . . . . . . . . . . 64

3.2.1 Systèmes de simulation discret : . . . . . . . . . 643.2.2 Systèmes de simulation continue : . . . . . . . . 65

3.3 Les simulateurs de réseau éxistant . . . . . . . . . . . . 653.3.1 NS2 : . . . . . . . . . . . . . . . . . . . . . . . . . 653.3.2 GloMoSim . . . . . . . . . . . . . . . . . . . . . 663.3.3 OMNET++ . . . . . . . . . . . . . . . . . . . . . 68

3.4 Comparaison entre les simulateurs . . . . . . . . . . . . 683.5 Le Simulateur OMNET++(Objective Modular Network

Testbed in C++) . . . . . . . . . . . . . . . . . . . . . . . 703.5.1 Choix du simulateur OMNET++ . . . . . . . . . 703.5.2 Présentation d’OMNET++ . . . . . . . . . . . . 703.5.3 Desciption architecturale d’OMNET++ . . . . . 71

TABLE DES MATIÈRES vi

3.5.4 Installation du simulateur OMNET++ . . . . . . 723.5.5 Les principaux fichiers d’OMNET++ . . . . . . 73

3.5.5.1 Fichier (.Ned) : . . . . . . . . . . . . . . 733.5.5.2 Fichier (.ini) : . . . . . . . . . . . . . . . 753.5.5.3 Fichier (.msg) : . . . . . . . . . . . . . . 75

3.6 Les plates formes d’OMNET++ . . . . . . . . . . . . . . 763.6.1 Mobility FrameWork . . . . . . . . . . . . . . . . 76

3.6.1.1 La structure d’une hôte mobile . . . . . 773.6.2 Mixim . . . . . . . . . . . . . . . . . . . . . . . . 783.6.3 Castalia . . . . . . . . . . . . . . . . . . . . . . . 78

3.7 Détails sur Castalia . . . . . . . . . . . . . . . . . . . . . 803.7.1 Le module MAC . . . . . . . . . . . . . . . . . . 813.7.2 Le module Radio . . . . . . . . . . . . . . . . . . 813.7.3 Canal sans fil . . . . . . . . . . . . . . . . . . . . 823.7.4 Le module Routage . . . . . . . . . . . . . . . . . 823.7.5 Le module Application . . . . . . . . . . . . . . 82

3.8 Outils de Simulation . . . . . . . . . . . . . . . . . . . . 833.8.1 Installation d’OMNET++ Version 4 . . . . . . . . 833.8.2 Installation de Castalia3.1 . . . . . . . . . . . . . 84

3.8.2.1 Les Commandes Castalia . . . . . . . . 843.9 Implémentation d’un réseau . . . . . . . . . . . . . . . . 843.10 Conculsion . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4 Implémentation et Simulation 884.1 Environnement de travail . . . . . . . . . . . . . . . . . 90

4.1.1 Environnement matériel . . . . . . . . . . . . . 904.1.2 Environnement logiciel . . . . . . . . . . . . . . 90

4.2 Processus de simulation . . . . . . . . . . . . . . . . . . 904.3 Réalisation du projet . . . . . . . . . . . . . . . . . . . . 91

4.3.1 Objectif . . . . . . . . . . . . . . . . . . . . . . . . 914.3.2 Description de la conception d’un nœud . . . . 91

TABLE DES MATIÈRES vii

4.3.3 Description du réseau . . . . . . . . . . . . . . . 944.4 Implémentation . . . . . . . . . . . . . . . . . . . . . . . 96

4.4.1 Structure des messages utilisés . . . . . . . . . . 964.4.1.1 Au niveau de la couche Application . . 964.4.1.2 Au niveau de la couche Réseau . . . . 96

4.4.2 Aperçu des Codes Sources . . . . . . . . . . . . 984.4.2.1 Envoi Periodique du Message HELLO

984.4.2.2 Attribution Des Rôles . . . . . . . . . . 994.4.2.3 Gestion de la redondance . . . . . . . . 1004.4.2.4 Rediffusion du Hello . . . . . . . . . . 102

4.4.3 Le fichier .ini . . . . . . . . . . . . . . . . . . . . 1024.5 Résultats Obtenus . . . . . . . . . . . . . . . . . . . . . 104

4.5.1 Deployement du Réseau . . . . . . . . . . . . . . 1044.5.1.1 Initialisation des nœuds . . . . . . . . 1054.5.1.2 Reconnaissance de voisinage . . . . . . 1064.5.1.3 Table de voisinage et Affectation des

rôles . . . . . . . . . . . . . . . . . . . . 1084.5.1.4 Passage en Etat Sleep . . . . . . . . . . 109

4.5.2 Exemple d’un fichier Resume . . . . . . . . . . . 1094.5.3 Paramètres de Simulations . . . . . . . . . . . . 111

4.5.3.1 La Radio CC1000 . . . . . . . . . . . . . 1114.6 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4.6.1 Organisation du Réseau . . . . . . . . . . . . . . 1124.6.1.1 Les positions des nœuds . . . . . . . . 1124.6.1.2 Le voisinage . . . . . . . . . . . . . . . 113

4.6.2 Redondance Des Nœuds . . . . . . . . . . . . . . 1144.6.3 Reconfiguration Du Réseau . . . . . . . . . . . . 1154.6.4 Energie Consommée au niveau du réseau . . . . 1164.6.5 Energie Consommée Avec et sans surveillance . 1174.6.6 Energie restante d’un nœud Représentant . . . . 118

TABLE DES MATIÈRES viii

4.6.7 Nombre de packets moyens des différents nœuds1194.6.8 Energie Consomée des différents nœuds . . . . 1194.6.9 Influence de la Mobilité des nœuds sur le Réseau1204.6.10 Influence du Temps De Simulation . . . . . . . . 122

4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Conclusion Générale 124

TABLE DES MATIÈRES ix

Table des figures

1.1 Les catégories des réseaux sans fil. [MAT08] . . . . . . 41.2 le nœud capteur [CAS08]. . . . . . . . . . . . . . . . . . 81.3 les composants d’un nœud capteur [MOA08]. . . . . . 81.4 La pile protoclaire [CSS04]. . . . . . . . . . . . . . . . . 101.5 Architecture de commnication d’un RCSF [KEC07]. . . 121.6 Architecture Plat des RCSF[ROM07]. . . . . . . . . . . 131.7 Architecture hierarchique des RCSF[ROM07]. . . . . . 141.8 Collecte à la demande . . . . . . . . . . . . . . . . . . . 161.9 Collecte suite à un événement . . . . . . . . . . . . . . . 161.10 Les différentes applications des RCSF [CHE08]. . . . . 201.11 Modéle de consommation d’énergie . . . . . . . . . . . 211.12 La surécoute [MOA08]. . . . . . . . . . . . . . . . . . . 231.13 Classification des protocoles de routage[BEN09]. . . . 251.14 Les étapes du protocole SPIN[CHE08]. . . . . . . . . . 261.15 Etapes décrivantes le protocole DirectedDiffusion [CHE08].

28

2.1 Classification des pannes [CHE08]. . . . . . . . . . . . . 342.2 Stratégies de déploiement des noeuds dans un RCSF[YAK].

382.3 La redondance matérielle[RIP99]. . . . . . . . . . . . . 412.4 Organisation en régions des nœuds capteurs [ALL09]. 482.5 Affectation des rôles dans un RCSF. . . . . . . . . . . . 502.6 Diagramme Etat Transition. . . . . . . . . . . . . . . . . 51

TABLE DES FIGURES xi

2.7 Diagramme De Séquence. . . . . . . . . . . . . . . . . . 522.8 Introduction d’un nouveau nœud. . . . . . . . . . . . . 532.9 Détection des groupes adjacents. . . . . . . . . . . . . . 542.10 Correction du problème d’incohérence. . . . . . . . . . 552.11 Résolution de conflit entre Représentants. . . . . . . . . 562.12 Redondance des nœuds simples. . . . . . . . . . . . . . 572.13 Changement d’état d’un nœud. . . . . . . . . . . . . . . 58

3.1 Description architecturale du simulateur NS2. . . . . . 663.2 Transfert des paquets dans GloMoSim. . . . . . . . . . . 673.3 Le lancement du simulateur Omnet++. . . . . . . . . . . 713.4 Architecture modulaire du simulateur Omnet++. . . . . 723.5 Fichier NED en mode graphique. . . . . . . . . . . . . . 743.6 Fichier NED en mode texte. . . . . . . . . . . . . . . . . 743.7 Exemple d’un Fichier *.Ini. . . . . . . . . . . . . . . . . 753.8 Exécution d’une simulation sous OMNeT++.[?] . . . . . 763.9 Architecture de Mobility et Channel Control. . . . . . . 773.10 Architecture interne d’un nœud dans MF. . . . . . . . . 783.11 Les connections des modules sous Castalia. . . . . . . . 793.12 Les principaux composants d’un nœud . . . . . . . . . . 803.13 La machine à état fini du module Radio. . . . . . . . . . 81

4.1 Processus de Simulation. . . . . . . . . . . . . . . . . . . 914.2 Fichier graphique ".ned" du nœud. . . . . . . . . . . . . 934.3 Fichier graphique ".ned" du réseau. . . . . . . . . . . . . 954.4 Fichier ".msg" du message Data. . . . . . . . . . . . . . 964.5 Le structure du message Hello et HelloRep. . . . . . . . 974.6 Le structure du message "Passe Représentant" et "Ré-

solution de conflit". . . . . . . . . . . . . . . . . . . . . . 974.7 Le structure du message Verification de cohérence et

Changement de rôle. . . . . . . . . . . . . . . . . . . . . 984.8 Organigramme de redondance des nœuds simples. . . 101

TABLE DES FIGURES xii

4.9 Deployement des nœuds. . . . . . . . . . . . . . . . . . 1044.10 Exécution avec le Deployement . . . . . . . . . . . . . . 1054.11 Déployement Aléatoire. . . . . . . . . . . . . . . . . . . 1134.12 Organisation des Nœuds. . . . . . . . . . . . . . . . . . 1144.13 Gestion De La Redondance. . . . . . . . . . . . . . . . . 1154.14 Reconfiguration suite à une défaillance. . . . . . . . . . 1154.15 Energie Consommée en Réseau. . . . . . . . . . . . . . . 1164.16 Energie Consommée au niveau des deux Méthodes . . 1174.17 Energie Moyenne Consommée par 50 nœuds . . . . . . 1174.18 Energie Moyenne Consommée par 100 nœuds . . . . . 1184.19 L’énergie restante au niveau d’un nœud Représentant . 1184.20 Packets Moyens envoyés et reçus par nœuds. . . . . . . 1194.21 Energie Consommée Avec Surveillance. . . . . . . . . . 1204.22 Energie Consommée Sans Surveillance. . . . . . . . . . 1204.23 Influence de la Mobilité sur le Réseau. . . . . . . . . . . 1214.24 Influence de la Mobilité sur le Réseau(Energie Moyenne).1214.25 Energie Restante par-rapport au temps de Simulation. . 1224.26 Energie Moyenne Restante. . . . . . . . . . . . . . . . . 122

Résumé :

Les réseaux de capteurs sans fil attirent plus l’attention de la com-munauté de recherches. Ainsi la simulation est une démarche fré-quemment utilisée pour tester et valider des approches, les environ-nements de simulation doivent pouvoir soutenir les différents mo-dèles des réseaux de capteurs sans fil. Notre article s’intéresse plusprécisément au cas de surveillance des réseaux de capteurs. Le proto-cole testé est un protocole basé sur la reconfiguration des noeuds avecle principe de redondance pour garder une couverture de la zone etassurer une longue vie du réseau. La validation de l’approche estconsidéré suite à l’utilisation du simulateur OMNeT++ puisque lesrésultats obtenus ont montré que le concept de l’approche au niveaude la tolérance aux pannes (avec le principe de réveiller les noeudsendormi en cas de panne ou d’épuisement d’énergie d’un noeud ac-tif) assure un bon fonctionnement ainsi une longévité du réseau.

Mots Clés : Réseau de capteurs sans fil, Surveillance, Redon-dance, Reconfiguration, Simulation, OMNET++, Castalia

Introduction Générale

L’avancement des technologies dans les infrastructures de réseauet de minuscules capteurs du réseau permet à de nombreuses ap-plications de réseau de capteurs allant de civils aux militaires, de lamaison à l’environnement et de la nature de l’industriel au domainecommercial de s’accroitre, car de nos jours le besoin d’observer desphénomènes physiques tel que la température, la pression ou encorela luminosité est devenu essentiel. Exemples sont la surveillance del’habitat des animaux, observation de l’environnement et de prévi-sion, le corp humain le suivi, le champ de bataille de détection etd’analyse, etc

Cependant, La taille réduite des capteurs nécessite l’utilisation d’unebatterie comme source d’énergie ce qui implique une durée limité duréseau. Suite à ça la collaboration d’un nombre de ces nœuds, donnenaissance à un réseau de capteurs sans fil. Ce dernier est déployé demanière aléatoire dans un champ.

Les capteurs sont prévus pour la collecte d’information selon descritères bien précis. Ainsi la consommation d’energie est devenue unaxe majeur dans les recherches d’où plusieurs protocoles de routageont été proposés dans le but d’optimiser la consommation énergi-tique et de prolonger la durée de vie du réseau.

Introduction Générale xv

Un protocole de routage permet l’acheminement des informationsau sein du réseau avec l’envoie des messages entre nœuds capteurspour la collecte du phénomène. Ce qui s’avère couteux en energie quiengendre l’épuisement des batterie, encore plus la perte des donnéeset la diminution de vie du réseau.

Dans ce contexte, la fonction de surveillance en continue est uneméthode basée sur la détection et la localisation des anomalies quipeuvent survenir dans le réseau.Suite à ca, une des solutions qui s’annonce prometteuse est l’utilisa-tion d’un système multi-Agents avec le principe de la surveillance.L’objectif de notre travail est de créer dans l’environnement de simu-lation OMNeT++, un modèle de surveillance du réseau. Ce modèleest basé sur la gestion distribuée avec le concept de redondance.Comme conséquences de cette surveillance : La diminution des mes-sages communiqués, L’hiérarchie du réseau, La réduction d’énergieconsommée et ainsi la longévité du réseau.

Suite à ça notre Document est organisé en 4 Chapitres :– Chapitre 1 : Donne un aperçu sur les réseaux de capteurs sans

fils et leurs caractéristiques. Un état de l’art est présenté.

– Chapitre 2 : Est consacré à la surveillance des réseaux où nousavons présenté les principaux concepts de surveillance et plusprécisémment au niveau des réseaux de capteurs sans fils. Lestravaux dans ce domaine sont cités en références.

– Chapitre 3 : Présente l’apprort de la simulation pour la valida-tion des résultats. Un comparatif entre les différents simulateursenrichira le contenu du chapitre. Notre choix qui sera justifiésest pointé sur OMNeT++ et Castalia.

Introduction Générale xvi

– Chapitre 4 : Constitue le cœur de cette contribution en propo-sant un modèle de surveillance du réseau ainsi que son implé-mentation. Les résultats de simulation seront également présen-tés pour justifier la validité de notre approche.

Introduction Générale 1

Chapitre 1

Présentation des Réseaux de capteurssans fil

Au cours de son évolution, le paradigme sans fil a vu naître di-verses architectures dérivées, telles que :

– les réseaux cellulaires,– les réseaux locaux sans fil,– etc..

Durant cette dernière décennie, une nouvelle architecture est apparu :– les réseaux de capteurs sans fil(RCSF).

Ces derniers ont été utilisés dans de nombreuses applications tellesque la surveillance des forêts, la gestion des catastrophes, l’explora-tion spatiale, l’automatisation industrielle, l’installation des serrures,la protection des frontières, et la surveillance des champs de bataille[ASS08][CKU03].

Dans ces applications, les nœuds de capteurs miniaturisés sont dé-ployés à fonctionner de façon autonome dans des environnementssans surveillance. En plus de la capacité d’explorer son environne-ment, chaque capteur possède une radio à bord utilisée pour l’envoides données recueillies à une station de base, soit directement, soit à

Présentation des Réseaux de capteurs sans fil 3

travers un chemin multi-saut. Ces capteurs ont 3 fonctions :

1. Capter des données (de type son, vibration, lumière,...),

2. Calculer des informations à l’aide de ces valeurs collectées,

3. Les communiquer à travers un réseau de capteurs.

Ce dispersement aléatoire des capteurs nécessite un protocole basésur des algorithmes d’auto-organisation. Afin de résister aux déploie-ments, ces capteurs doivent être très solides et de plus, ils doiventaussi pouvoir survivre dans les conditions les plus extrêmes dictéespar leur environnement d’utilisation (feu ou eau par exemple). Enplus des contraintes environnementales, une contrainte très impor-tante est l’économie de batterie. En effet, un réseau de capteurs nepeut survivre si la perte de nœuds est trop importante car ceci en-gendre des pertes de communication dûes à une grande distanceentre les capteurs. Donc il est très important que les batteries durentle plus longtemps possible étant donné que dans la plupart des ap-plications les capteurs sont placés aléatoirement.


1.1 Les Réseaux sans fil

Il existe plusieurs catégories de réseaux sans fil qui diffèrent par lepérimètre géographique qu’ils couvrent ainsi que par les types d’ap-plications supportées. Le schéma suivant illustre les catégories desréseaux sans fil.

FIG. 1.1 – Les catégories des réseaux sans fil. [MAT08]

1.1.1 Le réseau personnel sans fil

Il concerne les réseaux sans fil d’une faible portée : de l’ordre dequelques dizaines de mètres. Ce type de réseau sert généralement àrelier des périphériques (imprimante, téléphone portable, appareilsdomestiques, PDA...). Il existe plusieurs technologies utilisées pourles WPAN tel que :

1. La technologie Bluetooth : Est connue aussi sous le nom de lanorme IEEE 802.15.1, elle a été lancée par Ericsson en 1994, pro-posant un débit théorique de 1 Mbps lui permettant une trans-mission de la voix, des données et des images [2], d’une portée


maximale d’une trentaine de mètres[1].Bluetooth est une technologie peu onéreuse, grâce à sa forte in-tégration sur une puce unique de 9 mm sur 9 mm [3] ; Elle pré-sente également l’avantage de fonctionner sur des appareils àfaible puissance d’où une faible consommation d’énergie [1].

2. La technologie ZigBee : Est connue aussi sous le nom de la normeIEEE 802.15.4, permet d’obtenir des liaisons sans fil à bas prixavec une très faible consommation d’énergie, ce qui la rend par-ticulièrement adaptée pour être directement intégrée dans depetits appareils électroniques (capteurs, appareils électroména-gers...) [1].Les réseaux ZigBee permettent d’offrir des débits jusqu’à 250Kbits/s dans la bande classique des 2,4GHz. Les RCSF consti-tuent une des applications que cette norme peut couvrir [1].

3. Les liaisons infrarouges : Permettent de créer des liaisons sans filde quelques mètres avec des débits pouvant monter à quelquesmégabits par seconde. Cette technologie est largement utiliséedans la domotique (télécommandes), et souffre toutefois des per-turbations dûes aux interférences lumineuses.

1.1.2 Le réseau local sans fil (WLAN)

C’est un réseau permettant de couvrir une portée d’environ unecentaine de mètres. Il permet de relier les terminaux entre-eux pré-sents dans la zone de couverture. Il existe deux technologies concur-rentes :

1. Les réseaux Wi-Fi (Wireless-Fidelity) : Proviennent de la normeIEEE 802.11, qui définit une architecture cellulaire. On y trouveprincipalement deux types de réseaux sans fil : Ceux qui tra-vaillent à la vitesse de 11 Mbits/s à 2.4 GHz (IEEE 802.11b) etceux qui montent à 54 Mbits/s à 5 GHz (IEEE 802.11 a/g).


2. Les réseaux HiperLAN 2 (High Performance LAN 2.0) : Découlentde la norme européenne élaborée par l’ETSI (European Telecom-munications Standards Institute). HiperLAN 2 permet d’obtenirun débit théorique de 54 Mbps sur une zone d’une centaine demètres dans la gamme de fréquence comprise entre 5 150 et 5 300MHz [1]. Ce type de réseau n’a pas reçu autant de succès que latechnologie Wi-fi.

1.1.3 Le réseau métropolitain sans fil (WMAN)

Connu aussi sous le nom de Boucle Locale Radio (BLR). Il convientde rappeler que la BLR permet, en plaçant une antenne paraboliquesur le toit d’un bâtiment, de transmettre par voie hertézienne de lavoix et des données à haut débit pour l’accès à l’internet et la télépho-nie. Il existe plusieurs types de réseaux WMAN dont le plus connuest :

Le réseau Wimax (Worldwide interoperability for Microwave Ac-cess) :Ils émanent de la norme IEEE 802.16 et ont pour but de dévelop-per des liaisons hertéziennes concurrentes aux techniques xDSL ter-restres et offrent un débit utile de 1 à 10 Mbit/s dans la bande 10-66GHz pour une portée de 4 à 10 kilomètres, ce qui destine principale-ment cette technologie aux opérateurs de télécommunication.

1.1.4 Le réseau étendu sans fil (WWAN)

Il est connu sous le nom de réseau cellulaire mobile et il est le plusrépandu puisque tous les téléphones mobiles sont connectés à un ré-seau étendu sans fil. Les principales technologies sont les suivantes :GSM (Global System for Mobile Communication), GPRS (GeneralPacket Radio Service), UMTS (Universal Mobile TelecommunicationSystem).


1.2 Les réseaux Ad Hoc

Un réseau ad hoc, ou MANET (Mobile Ad hoc NETwork), est unréseau formé dynamiquement par un ensemble arbitraire de nœudsindépendants. Aucune préinstallation relative au rôle que devraitjouer chaque nœud n’est requise.Dans un réseau ad hoc, les nœuds sont supposés se comportés commedes routeurs et des clients à la fois, aussi, chaque nœud est libre dese déplacer et de s’organiser aléatoirement. Ainsi, la topologie du ré-seau peut changer rapidement et de manière imprévisible [HER05].

1.2.1 Caractéristiques des réseaux Ad Hoc

– Mobilité des nœuds : Dans un réseau ad hoc, la topologie du ré-seau est dynamique, et peut donc changer assez rapidement.

– Liaisons sans fil : Le seul moyen de communication dans les ré-seaux ad hoc est l’utilisation d’interfaces sans fil. Ces liaisonssans fil auront toujours des performances inférieures à leurs ho-mologues câblés [CAM99] .

– Equivalence des nœuds : Dans les réseaux Ad Hoc il n’existe pasde différence entre nœuds tel que les autres réseaux(hôte et sta-tion)car tous nœuds peuvent être amenés à assurer des fonctionsde routage.

1.3 Les réseaux de capteurs sans fil (RCSF)

Les réseaux de capteurs sont considérés comme un type spécialdes réseaux Ad hoc. En conséquence, ils héritent des caractéristiquesde ces réseaux, y compris l’architecture sans infrastructure établie etla communication sans fil. Les RCSF forment une nouvelle généra-tion de réseaux aux propriétés spécifiques, Ils présentent un champ


d’application très vaste et couvrent plusieurs domaines à caractèrescientifique, logistique, militaire ou de santé.

Un RCSF est composé de plusieurs centaines et parfois des mil-liers de nœuds capteurs, chaque nœud est capable de surveiller sonenvironnement et de réagir en cas de besoin en envoyant l’infor-mation collectée à un ou plusieurs points de collecte, à l’aide d’uneconnexion sans fil [BAB06].

FIG. 1.2 – le nœud capteur [CAS08].

1.3.1 Architecture d’un nœud capteur

Un nœud capteur est composé de quatre unités principales, quisont présentées dans la figure ci-dessous[CSS04][KHA06].

FIG. 1.3 – les composants d’un nœud capteur [MOA08].

a. Unité de capture (Sensing unit) : Elle est composée de deux sousunités, un dispositif de capture physique qui prélève l’informa-


tion de l’environnement local et un convertisseur analogique/numérique appelé ADC (Analog to Digital Converters).

b. Unité de traitement (Processing unit) : Les données captées sontcommuniquées au processeur où elles sont stockées dans la mé-moire.

c. Unité de communication (Transceiver unit) : Elle est composéed’un émetteur/récepteur (module radio) permettant la commu-nication entre les différents nœuds du réseau.

d. Unité d’énergie (Power unit) : C’est la batterie qui, n’est généra-lement ni rechargeable ni remplaçable. La capacité d’énergie li-mitée au niveau des capteurs représente la contrainte principalelors de la conception de protocoles pour les réseaux de capteurs.Les unités d’énergie peuvent être supportées par des photopilesqui permettent de convertir l’énergie lumineuse en courant élec-trique.

1.3.2 Organisation d’un nœud capteur

les réseaux de capteurs utilisent une pile protocolaire de commu-nication composée de cinq couches : une couche application, unecouche transport, une couche réseau, une couche liaison de donnéeset une couche physique. Cette pile est également caractérisée par troisniveaux qui intègrent dans les protocoles des différentes couches laprise en compte de l’énergie consommée, de la mobilité des nœuds,et de la gestion de la distribution des tâches sur les différents nœudsdu réseau [DOH06].

a. La couche physique : Elle est responsable de la sélection de fré-quence, la génération de la fréquence porteuse, la détection dusignal, la modulation/ démodulation et le cryptage/décryptagedes informations. Il est avantageux en matière d’économie d’éner-


FIG. 1.4 – La pile protoclaire [CSS04].

gie que le concepteur de la couche physique choisit une trans-mission à multi-sauts plutôt qu’une transmission directe qui né-cessite une puissance de transmission très élevée [CSS04].

b. La couche liaison de données : La couche liaison de données estprincipalement responsable de :– Multiplexer le flux de données.– Détecter et verrouiller les trames de données.– Contrôler l’accès au support de transmission (Media Access

Control).– Contrôler les erreurs.– Et d’assurer une connexion fiable (point-à-point ou point-à-

multipoints) selon la topologie du réseau de capteurs.

c. La couche réseau : Gère les échanges (et éventuellement les connexions)au travers du RCSF. Sachant que le positionnement des nœudsétant aléatoire et dense, les protocoles de routage traditionnelsdeviennent inadéquats. Pour cela, la communication multi-sautsest la mieux adaptée. Cette couche prend en charge la décou-


verte du voisinage, l’allocation des ressources et le routage.

d. La couche transport : Dans les réseaux de capteurs, la couchetransport est essentiellement présente pour constituer une inter-face entre la couche application et la couche réseau [HAM07].Ses principaux objectifs sont :– Multiplexer et démultiplexer les messages entre les applica-

tions et la couche réseau.– Contrôler les données à haut niveau.– Réguler la quantité des données injectées dans le réseau.Le rôle de cette couche intervient essentiellement lorsqu’on vaaccéder à partir de notre RCSF vers un autre RCSF ou vers Inter-net.

e. La couche application : La couche application constitue l’en-semble des applications implémentées sur un réseau de capteurs.Ces applications devraient fournir des mécanismes permettant àl’utilisateur d’intéragir avec le réseau de capteurs à travers dif-férentes interfaces, et éventuellement, par l’intermédiaire d’unréseau étendu (par exemple : Internet).Cette couche est responsable par exemple sur la collecte, le co-dage, l’agrégation et la compression des données collectées.


En plus les 3 niveaux(plans) :

a. Le niveau de gestion d’énergie : Chargé de contrôler la manièredont un nœud utilise son énergie.

b. Le niveau de gestion des tâches : Assure l’équilibrage de la dis-tribution des tâches sur les différents nœuds pour accomplir untravail coopératif.

c. Le niveau de gestion de la mobilité : Détecte et enregistre toutles mouvements des nœuds capteurs.

1.3.3 Architecture d’un réseau de capteurs

Les nœuds capteurs sont habituellement dispersés dans une zonede capture. Chacun de ces nœuds à la possibilité de collecter les don-nées et de les router vers une ou plusieurs stations de base (sinknode). Ce dernier est un point de collecte de données capturées. Ilpeut communiquer les données collectées à l’utilisateur final à tra-vers un réseau de communication, éventuellement l’Internet[MOA08].

FIG. 1.5 – Architecture de commnication d’un RCSF [KEC07].

Comme le montre la (Figure 1.5), un RCSF est composé d’un grandnombre de nœuds capteurs éparpillés sur le champ de captage [ELK].


A un niveau plus élevé un RCSF peut être vu comme étant unecombinaison de deux entités de réseaux :

– Le réseau d’acquisition de données : C’est l’union des nœudscapteurs et du sink, son rôle consiste à collecter les données àpartir de l’environnement et de les rassembler au sink.

– Le réseau de distribution de données : Son rôle est de connec-ter le réseau d’acquisition des données à un utilisateur.

1.3.4 Les types d’architectures des RCSF

1. Les réseaux de capteur sans fil plat : Un réseau de capteur sansfil plat est un réseau homogène, où tous les nœuds disposentdes même capacités dans la communication, captage d’informa-tions... Et un sink différent puisque il joue le rôle de passerellechargée à transmettre les informations colléctées à l’utilisateur.

FIG. 1.6 – Architecture Plat des RCSF[ROM07].

2. Les réseaux de capteurs sans fil hiérarchique : C’est un réseauhétérogène où les nœuds peuvent disposés d’une source énèr-gitique, d’une portée de communication ou d’une puissance decalcul différente les uns des autres.


FIG. 1.7 – Architecture hierarchique des RCSF[ROM07].

1.3.5 Les differentes topologies des RCSF :

1.3.5.1 La Topologie en étoile :

Dans cette topologie une station de base peut envoyer ou recevoirun message à un certains nombre de nœuds. Ces nœuds peuventseulement envoyer ou recevoir un message de l’unique station debase, il ne leur est pas permis de s’échanger des messages.L’avantage de cette topologie est sa simplicité, sa capacité à minimi-ser la consommation d’énergie des nœuds et la minimisation de la-tence de la communication entre les nœuds et la station de base. Soninconvénient est que la station de base n’est pas robuste puisque toutle réseau est géré par un seul nœud .

1.3.5.2 La topologie en grille :

Dans ce type de topologie, n’importe quel nœud peut envoyer àn’importe quel autre nœud dans le réseau qui est dans la portée detransmission. Ceci est appelé la communication multi-sauts, dans la-quelle, si un nœud veut transmettre un message à un autre nœud quiest en dehors de sa portée de transmission, il utilise un nœud inter-médiaire pour envoyer son message au nœud destinataire. L’avan-


tage de cette topologie est la possibilité du passage à l’échelle, la re-dondance et la tolérance aux fautes, L’inconvénient de cette topologieest la consommation d’énergie dans la communication multi-sauts etla latence qui sont créés par le passage des messages entre nœudsavant d’arriver à la station de base.

1.3.5.3 La topologie hybride :

Une topologie hybride entre celle en étoile et en grille fournit descommunications réseau robustes et diverses, en assurant la minimi-sation de la consommation d’énergie dans les réseaux de capteurs.Dans ce type de topologie, les nœuds capteur à faible puissance neroutent pas les messages, mais il y a d’autres nœuds qui ont la pos-sibilité de faire le routage des messages. En général, ces nœuds ontune puissance élevée.

1.3.6 La collection d’information :

Il existe deux méthodes pour collecter les informations d’un réseaude capteurs :

1.3.6.1 À la demande :

Lorsque l’on souhaite avoir l’état de la zone de couverture à unmoment T, le puit émet des brodcasts vers toute la zone pour que lescapteurs remontent leur dernier relevé vers le puit. Les informationssont alors acheminées par le biais d’une communication multi-sauts.

1.3.6.2 Suite à un évènement :

Un évènement se produit en un point de la zone de couverture(changement brusque de température, mouvement...), les capteurs si-


FIG. 1.8 – Collecte à la demande .

tués à proximité remontent alors les informations relevées et les ache-minent jusqu’au puit.

FIG. 1.9 – Collecte suite à un événement .


1.3.7 Les principales caractéristiques des RCSF

– La consommation réduite d’énergie : Chaque nœud dispose d’unebatterie de taille réduite, et se trouve donc éxposé à « la mort »une fois tout son stock d’énergie épuisé.

– L’auto-configuration des nœuds capteurs : Dans un RCSF, lesnœuds sont déployés d’une manière aléatoire (missile, avion...),[CSS04]. Ainsi, un nœud capteur doit avoir des capacités d’unepart, pour s’auto-configurer dans le réseau, et d’autre part pourcollaborer avec les autres nœuds dans le but de reconfigurer dy-namiquement le réseau en cas de changement de topologie duréseau [HOW03].

– La scalabilité : Un réseau de capteur est scalable parce qu’il a lafaculté d’accepter un très grand nombre de nœuds.

– La tolérance aux pannes : Dans le cas de dysfonctionnementd’un nœud (manque d’énergie, interférences avec l’environne-ment d’observation...) ou aussi en cas d’ajout de nouveaux nœudscapteurs dans le réseau, ce nœud doit continuer à fonctionnernormalement sans interruption. Ceci explique le fait qu’un RCSFn’adopte pas de topologie fixe mais plutôt dynamique.

– Une densité importante des nœuds : La forte densité des nœudsest dûe au mode de placement des nœuds (le mode aléatoire).

– Une collaboration entre les nœuds : Les contraintes strictes deconsommation d’énergie mènent les nœuds capteurs à détecteret traiter les données d’une manière coopérative afin d’éviter letraitement redondant d’une même donnée observée, source de


la perte d’énergie [4].

1.3.8 Les domaines d’application

La taille de plus en plus réduite des micro-capteurs, le coût deplus en plus faible, la large gamme des types de capteurs disponibles(thermique, optique, vibrations,...) ainsi que le support de communi-cation sans fil utilisé, permettent aux réseaux de capteurs d’envahirplusieurs domaines d’applications.Parmi lesquelles, on peut citer :

Applications Militaires : Comme dans le cas de plusieurs technolo-gies, le domaine militaire a été un moteur initial pour le déve-loppement des réseaux de capteurs. Le déploiement rapide, lecoût réduit, l’auto-organisation et la tolérance aux pannes desréseaux de capteurs sont des caractéristiques qui rendent ce typede réseaux un outil appréciable dans un tel domaine.Comme exemple : La détection et collecte d’informations sur laposition de l’ennemi, la surveillance des zones hostiles (conta-minées), la détection d’agents chimiques, bactériologiques...

Applications Environnementales : Une grande quantité de capteurspeut être déployée en forêt ou dans un environnement de conser-vation de la faune afin de recueillir des informations diversessur l’état du milieu naturel et sur les comportements de dépla-cement.Parmi ces applications, on trouve : Détection des feux de fo-rêt, précision de l’agriculture, Le suivi des mouvements d’oi-seaux,d’animaux et d’insectes...

Applications Médicales : On pourrait imaginer que dans le futur, lasurveillance des fonctions vitales de l’être humain serait possible


grâce à des micro-capteurs qui pourront être avalés ou implan-tés sous la peau. Actuellement, des micro-caméras qui peuventêtre avalées existent.Par exemple : Le contrôle à distance des données physiologiquesde l’être humain, l’administration des médicaments à l’intérieurdes hôpitaux, le suivi et la surveillance des médecins et des pa-tients au sein de l’hôpital...

Applications Commerciales : Il est possible d’intégrer des nœuds cap-teurs au processus de stockage et de livraison. Le réseau ainsiformé, pourra être utilisé pour connaître la position, l’état et ladirection d’un paquet ou d’une cargaison. Il devient alors pos-sible pour un client qui attend la réception d’un paquet, d’avoirun avis de livraison en temps réel et de connaître la positionactuelle du paquet. On trouve dans ce domaine : La détectionet la surveillance des vols de voiture, les musées interactifs, Lecontrôle environnemental dans les bureaux et les entreprises...

1.3.9 La consommation d’énergie dans les RCSF

Les capteurs sont conçu avec un module d’énergie limité. Ainsi,cette derniére doit être utilisés efficacement afin de maximiser la du-rée de vie du réseau. A noter qu’une fois que l’énergie d’un nœud estépuisé, il est considéré défaillant ce qui provoque une forte probabi-lité de perdre la connectivité du réseau.

1.3.9.1 Les principaux opérations dûes à la consommation d’énergie

a. Energie de capture : L’énergie de capture est dissipée pour ac-complir les tâches suivantes : échantillonnage, traitement de si-gnal, conversion analogique/numérique et activation de la sonde


FIG. 1.10 – Les différentes applications des RCSF [CHE08].

du capture.En général, l’énergie de capture représente un faible pourcen-tage de l’énergie totale consommé par un nœud.

b. Energie de traitement : L’énergie de traitement se divise en deuxparties : l’énergie de commutation et l’énergie de fuite. L’énergiede commutation est déterminée par la tension d’alimentation etla capacité totale commutée au niveau logiciel (en exécutant unlogiciel).Par contre l’énergie de fuite correspond à l’énergie consomméelorsque l’unité de calcul n’effectue aucun traitement. En général,l’énergie de traitement est faible par rapport à celle nécessairepour la communication.

c. Energie de communication : L’énergie de communication se dé-cline en deux parties : l’énergie de réception et l’énergie de l’émis-sion. Cette énergie est déterminée par la quantité des données àcommuniquer et la distance de transmission, ainsi que par lespropriétés physiques du module radio. L’émission d’un signal


est caractérisée par sa puissance. Quand la puissance d’émissionest élevée, le signal aura une grande portée et l’énergie consom-mée sera plus élevée. Notons que l’énergie de communicationreprésente la portion la plus grande de l’énergie consommée parun nœud capteur.

1.3.9.2 Modèle de consommation d’énergie

Heinzelman et al. [HCB00] proposent un modèle radio de consom-mation d’énergie (Figure 1.11). Ainsi, les énergies nécessaires pourémettre ETx(s, d) et recevoir ERx(s) des messages sont données commesuit :

– Pour émettre un message de s bits vers un récepteur loin de d

mètres, l’émetteur consomme :

ETx(s, d) = ETxelec(s) + ETxamp(s, d)

ETx(s, d) = (Eelec ∗ s) + (Eamp ∗ s ∗ d2)

– Pour recevoir un message de s bits, le récepteur consomme :ERx(s) = ERxelec(s)

ERx(s) = Eelec ∗ s

Eelec et Eamp représentent respectivement l’énergie de transmissionélectronique et d’amplification.

FIG. 1.11 – Modéle de consommation d’énergie .


1.3.9.3 Les facteurs intervenants dans la consommation d’énergie

La consommation d’énergie dépend de plusieurs facteurs qui sontexpliqués ci-dessous :

a. Etat du module radio : Le module radio est le composant dunœud capteur qui consomme le plus d’énergie, puisque c’est luiqui assure la communication entre les nœuds. On distingue lesquatres états suivants :

– Etat sommeil :La radio est mise hors tension.– Etat transmission : La radio transmet un paquet.– Etat réception : La radio reçoit un paquet.– Etat idle : Cet état provoque une perte de l’énergie suite à

l’écoute inutile du canal de transmission. Pour éviter cette perted’énergie, un capteur doit s’activer qu’en cas de nécessitée, etle reste du temps il doit se mettre dans l’état sommeil.

b. Accès au medium de transmission : Puisque les nœuds partagentle même médium de transmission, la sous-couche MAC joue unrôle important pour la coordination entre les nœuds et la mini-misation de la consommation d’énergie. En effet, minimiser lescollisions entre les nœuds permet de réduire la perte d’énergie.Ainsi les principales causes de perte d’énergie sont :

– La retransmission : Les nœuds capteurs possèdent en généralune seule antenne radio et partagent le même canal de trans-mission. Par ailleurs, la transmission simultanée des donnéesprovenant de plusieurs capteurs peut produire des collisionset ainsi une perte de l’information transmise. La retransmis-sion des paquets perdus peut engendrer une perte significa-tive de l’énergie.

– La surécoute : Le phénomène de surécoute (overhearing) seproduit quand un nœud reçoit des paquets qui ne lui sont pas


destinés, Comme illustré dans la figure suivante :

FIG. 1.12 – La surécoute [MOA08].

– L’écoute active : L’écoute active (idle listening) du canal pourune éventuelle réception de paquet qui ne sera pas reçu peutengendrer une perte importante de la capacité des nœuds enénergie.

– La surcharge : Plusieurs protocoles de la couche MAC fonc-tionnent par échange de messages de contrôle (overhead) pourassurer différentes fonctionnalités : signalisation, connectivité,établissement de plan d’accès et évitement de collisions. Tousces messages nécessitent une énergie additionnelle.

– La sur-émission : Le phénomène de sur-émission (overemit-ting) se produit quand un nœud capteur envoi les données àun destinataire qui n’est pas prêt à les recevoir.

– La taille des paquets : La taille des messages échangés dansle réseau a un effet sur la consommation d’énergie des nœudsémetteurs et récepteurs.

c. Modèle de propagation radio : Le modèle de propagation repré-sente une estimation de la puissance moyenne reçue du signalradio à une distance donnée d’un émetteur. La propagation dusignal radio est généralement soumise à différents phénomènes :la réflexion, la diffraction et la dispersion par divers objets.

d. Routage des données : Le routage dans les réseaux de capteursest un routage multi-sauts. L’acheminement des paquets d’une


source donnée à une destination se fait à travers plusieurs nœudsintermédiaires.Dans ce contexte, une mauvaise politique de routage peut avoirdes conséquences graves sur la durée de vie du réseau.

1.3.10 Le routage dans les RCSF

Les protocoles de routage au sein des RCSF sont influencés parun facteur déterminant à savoir : La minimisation d’énergie sans uneperte considérable de l’éfficacité.Pour cela de nombreuses stratégies de routage ont été crées pour lesréseaux de capteurs. Certaines sont des adaptations de stratégies quiexistaient pour d’autre types de réseaux (réseaux sans fil au sens leplus large) tandis que d’autres ont été conçues spécialement pour lesréseaux de capteurs sans fil.

Les protocoles de routage proposés pour les RCSF peuvent êtreclassifiés selon quatres manières : Selon la topologie, l’établissementde la route, les paradigmes de communication et le fonctionnementdu protocole.Cette classification est conçu comme suit :

1.3.10.1 Exemples de protocoles de routage

a) SPIN :Heinzelman et al. ont proposé une famille de protocole appelée SPIN(Sensor Protocols for Information via Negotiation), reposant sur unmodèle de négociation afin de propager l’information dans un réseaude capteurs.Les communications dans SPIN se font en trois étapes [CHE08] :

– Lorsqu’un nœud veut émettre une donnée, il émet d’abord unmessage ADV contenant une description de la donnée en ques-


FIG. 1.13 – Classification des protocoles de routage[BEN09].

tion.– Un nœud recevant un message ADV, consulte sa base d’intérêt.

S’il est intéressé par cette information, il émet un message REQvers son voisin.

– En recevant un message REQ, l’émetteur transmet à l’intéresséla donnée sous forme d’un message DATA.


FIG. 1.14 – Les étapes du protocole SPIN[CHE08].

b) MCFA :Ye et al. ont proposé l’algorithme MCFA (Minimum Cost ForwardingAlgorithm), recherchant un chemin minimal entre la source et le puit,tout en considérant les limites des réseaux de capteurs. Le protocolevise à atteindre trois principaux buts :+ L’optimalité : En acheminant les données sur des chemins à coûtminimum.+ La simplicité : Qui se traduit par une faible consommation en mé-moire, et la non nécessité d’une identification des nœuds.+ La scalabilité : Étant donnée la faible consommation en mémoireet l’absence d’identificateur de nœuds, le protocole peut être utilisépour un grand nombre de nœuds. En plus, la phase de constructiondes routes ne consomme qu’un message par capteur.

Son principe est le suivant :Chaque nœud maintient une variable de coût, qui détermine le coûtminimal vers le puit sur le chemin optimal. Plusieurs mesures peuvent


être employées, suivant l’application voulue : nombre de sauts, consom-mation d’énergie, . . . etc.

c) Directed Diffusion :Directed Diffusion est un protocole de propagation de données, per-mettant d’utiliser plusieurs chemins pour le routage d’information.Le puit diffuse un intérêt sous forme de requête, afin d’interrogerle réseau sur une donnée particulière. Il se base sur le modèle pu-blish/subscribe. DD repose sur quatre éléments : nomination desdonnées, propagation des intérêts et l’établissement des gradients,propagation des données et renforcement des chemins.DD emploi l’inondation globale du réseau. Chaque nœud maintientlocalement un cache d’intérêt contenant les informations suivantes :

– La description de l’intérêt, en utilisant le schéma de nomina-tion : Lorsqu’un puits requiert une donnée du réseau, il propageun intérêt, contenant sa description ainsi que le débit d’informa-tion désirée.

– Un ensemble de gradients : Lorsqu’un nœud recoit un intérêt,il parcourt son cache :+ Si le cache ne contient aucune entrée relative a l’intérêt recu,une nouvelle entrée est créee avec un gradient vers le voisinémetteur.+ Dans le cas contraire, le nœud recherche un gradient vers levoisin émetteur, et met à jour en conséquence l’entrée en ques-tion. Aprés le traitement du cache, le nœud relai l’intérêt vers sesvoisins. La méthode la plus simple est d’utiliser l’inondation.


FIG. 1.15 – Etapes décrivantes le protocole DirectedDiffusion [CHE08].

1.4 Conclusion

Ce chapitre a donner une vue globale sur le domaine desréseaux de capteurs sans fil qui sont apparentés aux réseau Adhoc.

Les réseaux de capteurs sans fil présentent un intérêt consi-dérable et une nouvelle étape dans l’évolution des technologiesde l’information et de la communication. Cette nouvelle techno-logie suscite un intérêt croissant vu la diversité de ces applica-tions : santé, environnement, industrie et même dans le domainesportif.

Cependant, la réalisation des réseaux de capteurs doit sa-tisfaire quelques contraintes tel que la consommation d’éner-gie, le changement de la topologie, la densité importante du ré-seau,...etc. Ces limites ont menées les chercheurs à suggérer des


approches de surveillance pour maintenir le réseau opération-nel le plus longtemps possible tout en gardant une connectivitédans le réseau (réseau connexe) et une meilleur couverture de lazone.

De ce fait, Le prochain chapitre sera consacré à la surveillancedes RCSF ainsi la présentation de l’approche distribué que nousavons choisie.

Chapitre 2

La surveillance des Réseaux deCapteurs Sans Fil

La surveillance est un dispositif utilisé pour analyser l’état du sys-tème. Elle consiste à détécter et classer les défaillances tout en ob-servant l’état du système en temps réel, puis diagnostiquer [GVA07]pour pouvoir localiser les éléments défaillants et déteminer les causes.En général, La conception d’une supervision performante repose surla combinaison des techniques de surveillance et de diagnostic.

De ce fait dans les RCSF, Certains nœuds capteurs peuvent êtrebloqués ou tomber en panne à cause d’un manque d’énergie, d’un dé-gât matériel ou d’une interférence environnementale. La panne d’unnœud capteur ne doit pas affecter le fonctionnement global de sonréseau. C’est le problème de fiabilité ou de tolérance aux pannes.

Pour la résolution de ces problèmes, plusieurs approches centra-lisées ont été proposées qui se base sur le diagnostic et la reconfigu-ration au niveau du sink ce qui provoque plusieurs inconvénients telque : La surcharge du module, La surcharge du réseau par les mes-sages de contrôle , les délais de transmission qui peuvent retardés ladétection des défauts, et le plus grand désavantage est la défaillancedu module sink.

La surveillance des Réseaux de Capteurs Sans Fil 32

Dans ces circonstances, on présentera dans ce chapitre une mé-thode décentralisée qui visent la reconfiguration du réseau en cas dedéfaillance en se fondant sur le principe de redondance avec quelquepropriétés de la théorie des graphes afin de maintenir le réseau connexetout en couvrant la totalité de la zone de capture.


2.1 La supervision des RCSF

Un superviseur a pour objectif d’assurer le bon déroulement d’unemission en présence de problèmes et de gérer le meilleur fonctionne-ment possible. De ce principe, la surveillance des réseaux de capteursconsiste à détécter les défaults et les pannes ensuite générer des solu-tions en temps réel pour gardé la longévité du réseau.Les pannes peuvent se produire à cause d’un défaut au niveau lo-giciel ou d’une erreur humaine. Dans les RCSF, la panne est géné-ralement déclanchée à cause de l’épuisement d’énergie d’un nœudqui est provoqué par la surcharge du réseau avec les messages decontrôles et même à cause des contraintes dans lequel le réseau estdéployé.

2.1.1 Les Pannes

Une faille (ou panne) du système se produit lorsque son compor-tement devient inconsistant et ne fournit pas le résultat voulu. Lapanne est une conséquence d’une ou plusieurs erreurs. Une erreurreprésente un état invalide du système du à une faute (défaut). Lafaute est donc la première cause de l’erreur, cette dernière provoquela faille du système.

2.1.1.1 Classification des pannes

Le schéma suivant montre une classification générale selon la du-rée, la cause ou le comportement d’une panne :

A. Pannes selon durée :

a1. [Transitoire :] Conséquence d’un impact environnementaltemporaire, elle peut éventuellement disparaître sans au-


FIG. 2.1 – Classification des pannes [CHE08].

cune intervention.

a2. [Intermittente :] Variante de la panne transitoire, elle se pro-duit occasionnellement et de façon imprévisible. Elle est gé-néralement dûe à l’instabilité de certaines caractéristiquesmatérielles ou à l’exécution du programme dans un espaceparticulier de l’environnement.

a3. [Permanente :] continue et stable dans le temps, la pannepermanente persiste tant qu’il n’y a pas d’intervention ex-terne pour l’éliminer. Un changement physique dans un com-posant provoque une panne matérielle permanente.

B. Pannes selon la cause :

b1. [Panne de design :] Dûe à une mauvaise structuration du ré-seau ou du composant en particulier. En pratique, ce genrede panne ne devrait pas exister grâce aux tests et simula-tions avant la réalisation finale du réseau ;

b2. [Panne opérationnelle :] Qui se produit durant le fonction-


nement du système.Elle est généralement dûe aux causes physiques. En outre,on peut distinguer, spécialement pour les réseaux de cap-teurs, trois principales causes : L’énergie, Sécurité et Trans-mission.

C. Pannes selon le comportement résultant :

c1. [Panne accidentelle (Crash) :] Le composant soit, il s’arrêtecomplètement de fonctionner ou bien continue mais sans re-tourner à un état stable (valide).

c2. [Panne d’omission :] Le composant n’est plus capable d’amé-liorer son service (échec total).

c3. [Panne de synchronisation (Timing) :] Le composant effec-tue son traitement mais fournit le résultat en retard.

C4. [Panne Byzantine :] Cette panne est de nature arbitraire ; lecomportement du composant est donc imprévisible. Dû àdes attaques très malicieuses, ce type de pannes est consi-déré le plus difficile à gérer.

2.1.2 Solution architecturale tolérante aux pannes dans les RCSF

La solution peut être classifiée en 3 catégorie :§ Gestion de la batterie : Cette catégorie est considérée comme

une approche préventive, où les protocoles définissent une dis-tribution uniforme pour la dissipation d’énergie entre les dif-férents nœuds capteurs ; afin de mieux gérer la consommationd’énergie et l’augmentation de la durée de vie de réseau. Enoutre, le mécanisme de mise en veille est une technique de ges-tion de batterie. En effet, les protocoles déterminent des délaisde mise en veille des nœuds capteurs inactifs pour une meilleure


conservation d’énergie[FEL07].

§ Gestion de flux : Cette catégorie regroupe les techniques quidéfinissent des protocoles de gestion de transfert des données(routage, sélection de canal de transmission...etc.). Nous pou-vons trouver des approches préventives ou curatives sur les dif-férentes couches (réseau, liaison de données...etc.) telles que :Routage multi-chemin : Utilise un algorithme préventif pour dé-terminer plusieurs chemins depuis chaque capteur vers le nœudcollecteur. Ceci garantit la présence de plus d’un chemin fiablepour la transmission et offre une reprise rapide du transfert encas de panne sur le premier chemin sélectionné (choisir un deschemins qui restent).Recouvrement de route : Après détection de panne, une techniquecurative permet de créer un nouveau chemin plus fiable pourretransmettre les données.Allocation de canal : Cette solution, implémentée au niveau MAC,effectue une allocation du canal de transmission d’une manièreà diminuer les interférences entre les nœuds voisins et éviter lescollisions durant le transfert.Mobilité : Certains protocoles proposent comme solution tolé-rante aux pannes la sélection d’un ensemble de nœuds mobileschargés de se déplacer entre les capteurs et collecter les donnéescaptées. Ceci réduira l’énergie consommée au niveau de chaquecapteur en éliminant sa tâche de transmission. Un nœud mobileest généralement doté d’une batterie plus importante que celled’un nœud capteur.

§ Gestion des données : Les protocoles classés dans cette catégo-rie offrent une meilleure gestion de données et de leur traite-ment. Deux principales sous-catégories sont déterminées :


Agrégation : Considérée comme approche préventive, l’opérationd’agrégation effectue un traitement supplémentaire sur les don-nées brutes captées depuis l’environnement. Un nœud agréga-teur combine les données provenant de plusieurs nœuds en uneinformation significative ; ce qui réduit considérablement la quan-tité de données transmises, demande moins d’énergie et aug-mente ainsi la durée de vie du réseau.Clustering : Une des importantes approches pour traiter la struc-

ture d’un réseau de capteurs est le clustering. Il permet la for-mation d’un backbone virtuel qui améliore l’utilisation des res-sources rares telles que la bande passante et l’énergie. Par ailleurs,le clustering aide à réaliser du multiplexage entre différents clus-ters. En outre, il améliore les performances des algorithmes deroutage. Plusieurs protocoles utilisent cette approche préventive[FEL07].

2.1.3 Aspect de surveillance d’un RCSF

2.1.3.1 Méthodologie de déploiement :

Les capteurs peuvent généralement être placés dans une zone d’inté-rêt, soit déterministe ou aléatoire. Le choix de la stratégie de déploie-ment dépond du type de capteurs, l’application et l’environnementde fonctionnement du capteur. Le déploiement contrôlé des nœudsest viable, et souvent nécessaire lorsque les capteurs sont chers, oulorsque leur fonctionnement est sensiblement affecté par leur posi-tion. Dans certaines applications, la distribution aléatoire des nœudsest la seule option possible. Cela est particulièrement vrai pour lesenvironnements difficiles tels que le champ de bataille ou une régionde catastrophe. Selon la distribution des nœuds et le niveau de redon-dance, le déploiement aléatoire des nœuds peut atteindre les objectifs


de performance.

FIG. 2.2 – Stratégies de déploiement des noeuds dans un RCSF[YAK].

2.1.3.2 Connectivité du réseau

Un réseau de capteur sans fil est dit connecté si et seulement s’ilexiste au moins une route entre chaque paire de nœuds [MER03]. Laconnectivité dépend essentiellement de l’existence des routes. Elle estaffectée par les changements de topologie causés par la mobilité oula défaillance des nœuds [BEC09].Le principe est que la bonne couverture sera rendue lorsque Tr est unmultiple de Sr. Cependant, si la portée de communication est limitée,par exemple, Tr = Sr, la connectivité devient un problème important,sauf si la redondance en matière de couverture est provisionnée.

L’une des méthodes utilisées a été proposée par "J. Bredin, E. De-maine, M. Taghi Hajiaghayi, and D. Rus" en 2005 qui se base sur laformulation des RCSFs K-connectés [CSS04]. K-connectivité supposequ’il existe K chemins indépendants entre chaque paire de nœuds.Pour K> 1, le réseau peut tolérer certains défaillances de liens et ga-rantie une certaine capacité de communication entre les nœuds. Lesauteurs étudient le problème du placement des nœuds pour atteindreK-connectivité au moment de configuration du réseau ou de répa-rer un réseau déconnecté formulent le problème comme un modèle


d’optimisation qui cherche à minimiser le nombre de nœuds supplé-mentaires requis pour maintenir la K-connectivité.

2.1.3.3 La couverture

Le problème de la couverture dans les réseaux de capteurs vidéon’est pas récent [MSP09]. Plusieurs travaux ont déjà traité ce pro-blème de plusieurs manières. Cependant, il éxiste deux catégories decouverture :- Couverture des cibles pré- déterminées : Consiste à trouver un sous-ensemble de nœuds connexes et qui assure la surveillance d’un en-semble de cibles dont la position est connue à priori.- Couverture d’une zone : consiste à trouver un sous-ensemble denœuds connexes et qui assure la surveillance de toute la zone de dé-ploiement.

Soit un réseau de n nœuds déployés pour surveiller une régiond’intérêt, un nœud est caractérisé par son rayon de couverture r etson rayon de transmission. La couverture dans un réseau de capteursans fil dépend de la denité des nœuds. Cette densité est donnée parl’équation extraite de [CSS04] :

µ(R) = (NΠR2)/A

Où :- R le rayon de transmission d’un nœud,- A l’air de calcul,- N le nombre de nœuds situé dans l’air A

2.1.3.4 Longévité du réseau

Prolonger la durée de vie du réseau a été l’objectif d’optimisationpour la plupart des protocoles de communication publié pour les ré-seaux de capteurs. Les positions des nœuds significatives impact sur


la durée de vie du réseau. Par exemple, les variations de densité desnœuds dans toute la région peuvent mener à la charge de trafic dés-équilibré et provoquer des goulets d’étranglement [HWT05].Un Réseau de capteur sans fil devient inexploitable quand la connec-tivité entre ses nœuds est perdue, on dit que le réseau est mort.

2.1.4 La redondance

La redondance d’une façon générale est utilisée pour prévenir undysfonctionnement dans un sytème. Comme dans le cas des RCSF, laredondance est établie pour étendre la durée de vie du réseau, sur-tout que cette dernière se rapporte au surnombre des nœuds.La redondance se divise en deux catégories :a) La redondance matérielle ou physique.b) La redondance analytique.

2.1.4.1 La redondance Matérielle

La redondance physique consiste à utiliser plusieurs capteurs, ac-tionneurs, processeurs et logiciels pour mesurer et/ou contrôler unevariable particulière. Un principe de vote est appliqué sur les valeursredondantes pour décider si une faute est présente ou non. Cette ap-proche entraîne un coût important en instrumentation mais s’avèreextrêmement fiable et simple à implanter. Elle est mise en œuvre es-sentiellement sur des systèmes à hauts risques tels que les centralesnucléaires ou les avions.Cette approche est appliquée pour les RCSF, puisque c’est le moyenle plus facile d’obtenir plusieurs informations sur une même variableet de disposer de plusieurs capteurs mesurant la grandeur de cettevariable.

La redondance physique souffre d’un désavantage majeur : son


FIG. 2.3 – La redondance matérielle[RIP99].

coût. Doubler le nombre de capteur revient au moins à doubler leprix de l’organe de mesure. De plus, les contraintes ergonomiquesliées à l’installation de ces capteurs peuvent limiter leur utilisation.Les modes qui peuvent être appliqués aux différents niveaux d’unsystèmes sont :

1. La redondance active : Elle est adapté pour les systèmes critiquesà cause de son principe qui tolère la faute d’un ou de plusieurscomposants.

2. La redondance passive : Basé sur la redondance en utilisant uneseule copie, appelée "copie primaire" ; alors que les autres copiessont utilisées seulement en cas de défaillance.

3. La redondance hybride : Comme son nom l’indique c’est une com-binaison entre les deux redondances cites précédemment.

Le choix de la stratégie de redondance se fait en fonction des contrainteset des besoins applicatifs. Dans le cas des réseaux de capteurs sansfil, la réplication active est préférable pour tolérer aux défaillancesfréquentes des nœuds capteurs.


2.1.4.2 La redondance analytique

Un complément à la redondance physique est d’exploiter lescontraintes liant les différentes variables du système. Ces contraintespeuvent souvent s’exprimer sous la forme de relations analytiquesliant les variables connues (relations d’entrée/sortie ou de sortie/sortie).Ces relations sont appelées des relations de redondance analytique.Le principe de la surveillance consiste à vérifier si ces relations sontégales à zéro (dans un sens statistique précisé plus loin) en utilisantles mesures prélevées en ligne sur le système. Le concept de redon-dance analytique repose sur l’utilisation d’un modèle mathématiquedu système à surveiller.

Définition 1 la structure d’une relation de redondance analytique est laliste minimale des contraintes devant être satisfaites pour que celle-ci le soitégalement. Chaque contrainte étant associèe à un composant, la structured’une RRA sera notée en utilisant l’ensemble des composants correspon-dants. [MAQ03]

L’approche utilisant la redondance analytique se décompose gé-néralement en deux phases distinctes :- La première concerne la génération de résidus caractéristiques de lapanne.- La seconde étape concerne la prise de décision qui a trait à la dé-tection et éventuellement à la localisation d’un élément défaillant.Elle met en œuvre des techniques de détection de ruptures et de testsd’hypothèses.Ce principe est souvent difficile à exploiter comme dans le cas desRCSF à cause du changement fréquent de la topologie du réseau liéeà l’épuisement de la batterie ou même la mobilité des capteurs. Pour


ces raison, la redondance matérielle est utilisée surtout que le coûtdes capteurs sans fils devient de plus en plus réduit.

2.2 Systèmes Multi-agents

Un système multi-agent (SMA) est un système composé d’un en-semble d’agents, situés dans un certain environnement et interagis-sant selon certaines relations. Un agent est une entité caractérisée parle fait qu’elle est, au moins partiellement, autonome. Ce peut être unprocessus, un robot, un être humain, etc. Objet de longue date derecherches en intelligence artificielle distribuée, les systèmes multi-agents forment un type intéressant de modélisation de sociétés, et ontà ce titre des champs d’application larges, allant jusqu’aux scienceshumaines.En d’autre termes,c’est de faire coopérer un ensemble d’entités (agents)dotées d’un comportement intelligent , coordonner leurs buts et leursplans d’actions pour résoudre un problème.

2.2.1 Caractéristiques des Systèmes Multi-Agents

– Chaque agent a des informations ou des capacités de résolutionde problèmes incomplètes, donc chaque agent a un point de vuelimité ;

– Il n’y a pas de contrôle global du système ;– Les données sont décentralisées ;– Les calculs sont asynchrone


2.3 Les Travaux Antérieurs

Dans le domaine des RCSF(s) plusieurs approches ont été propo-sées pour remédier aux problèmes trouvés suite au fonctionnementdes RCSF(s). Dans ce contexte, les méthodes ou les solutions propo-sées sont classées en deux catégories :

– Les Méthodes Centralisées ;– Les Méthodes Décentralisées.

Sachant que les chercheurs s’orientent vers la deuxième catégorie àcause des problèmes de centralisation qui peuvent se résumé en :

– Surcharge du module de traitement ;– Surcharge des nœuds par les messages de contrôles.....etc.

De ce fait, les travaux concernant les RCSF(s) s’orientent plus versl’économie d’énergie, la qualité de service et dernièrement vers lasurveillance des RCSF(s). En ce qui concerne ce dernier point, on peutciter ce qui suit :

Dans " SELF ORGANIZED SENSOR"[YCC05], l’auteur à conçuson protocole de surveillance basé sur la construction d’ un arbre hié-rarchique en utilisant le modèle mathématique tels que la théorie desgraphes ou d’un diagramme de Voronoi qui s’appliquer à une vastezone en raison de l’utilisation de la communication multi-sauts ainsiLes données pourraient être agrégées au niveau des nœuds intermé-diaires.Il se base sur les points suivants :

– Collecter les positions des nœuds ;– Nettoyer les nœuds Redondants et détecter les nœuds frontière ;– Détecter et suivre les objets d’intrusions ;– Réorganiser les nœuds lorsque un nœud meurt.

Le nœud redondant est détecter selon sa zone de couverture avec uneimage binaire.


Le Protocole de EEP proposé par SAYAD MAYA [SAY09] apportedes améliorations telles que l’augmentation de la durée de fonction-nement du réseau ainsi que la diminution du delai de transmission.Par conséquent il y’a l’économie d’énergie car la creation des routesest dynamique et se base sur une fonction de coût qui prend en comptele niveau d’énergie des nœuds et leur distance par rapport a la sta-tion de base.

Les auteurs [BAI10] ont étudiés la surveillance en utilisant l’aidemulticritère à la décision en formulant des spécifiques qui sont lesressources limitées en termes de charge et de capacités de stockageet de calcul, ainsi que l’absence d’infrastructure fixe (la mobilité),connectivité, et la distance entre les capteurs faire face aux mauvaiscomportements qui peuvent le cibler.

Dans CFIP09 [MSP09]les auteurs s’intéressent à la surveillance desvidéos des Réseaux De Capteurs Sans Fil ou ils adoptent une ap-proche pour ordonnancer de manière adaptatif l’activité des nœudsvidéo en fonction de la couverture. Ils ce sont dirigés vers un al-gorithme distribué où chaque nœud organise ses voisins en un en-semble de nœuds disjoint ensuite en se basant sur l’activité, chaquenœud décide s’il reste actif ou non. Simulation s’est établie a based’un modèle multi-niveaux.

Samira ALLAM dans [ALL09] s’interesse au protocole de routagebasé sur une approche distribué avec un contexte multi-agent ba-sée sur l’Auto-organisation pour but de ballier d’un système centra-lisé à un système descentralisé pour garantir la réduction d’énergieconsommée.

Dans [BEC09] l’auteur à proposé un modéle descentralisé pour lasurveillance d’un RCSF en utilisant un simulateur personnel conçu


avec C++ pour la validation des tests.

Aprés plusieurs recherches, nous avons constaté que la surveillancedes RCSF(s) est un domaine qui s’élargie d’où les chercheurs s’inté-resse de plus en plus vers cette porte qui a ouvert un autre concept derecherche. De ce fait nous nous sommes basé sur l’application d’uneapproche distribuée pour les Réseaux De Capteurs Sans Fil et de si-mulé cette approche sur un simulateur exisant et Open Source.L’approche distribuée ou à Multi-Agents pour :

– L’adaptation à la réalité ;– La coopération ;– La résolution de problèmes complexes ;– L’efficacité ;– La fiabilité.


2.4 Description de l’approche distribuée (décentrali-sée)

L’approche suivie consiste à la définition d’un réseau de capteursans fil avec le principe d’agents : différents rôles attribués aux nœudspour formé des groupes (zones ou clusters), Ce même algorithme estutilisé pour la réorganisation du réseau en cas de défaillance en utili-sant le principe de redondance avec la théorie de graphe.

2.4.1 Topologie du réseau

Le réseau de capteur sans fil est déployé aléatoirement dans unezone, ces nœuds suivent une topologie dynamique c.à.d que les cap-teurs peuvent bougés ou même l’ajout ou la disparaission des cap-teurs peut être envisageable.Le réseau est divisé en groupes de capteurs où chaque nœud a unrôle affécté en fonction de ses voisins lors de l’organisation du ré-seau. Ce principe est suivi pour faire coopérer un ensemble d’entitésdotés d’un comportement, cordonner leurs buts et leurs plans d’ac-tions pour résoudre un problème [LEB].

2.4.2 Définition des rôles

Les rôles peuvent être définis comme suit :a) Nœud Représentant : C’est le nœud qui administre les com-

munications au sein du groupe de capteur. Il assume toutes lesrequêtes d’envoies de messages des membres de sa région. C’estle nœud qui s’encharge de la communication du groupe avecl’extérieur. Notons qu’un représentant ne peut jamais avoir unvoisin du même rôle.


b) Nœud Liaison : Permet aux nœuds représentant de communi-quer (il est aux frontières de plusieurs groupes de capteurs). Ilest chargé d’assumer les communications entre les régions.

c) Nœud Simple : N’est autre qu’un simple capteur, il capture del’information demandée et la faire communiquer au Sink via sonreprésentant.

d) Nœud Sink : C’est la station principale qui peut communiqueravec tout les nœuds afin de collecter les informations voulues.

FIG. 2.4 – Organisation en régions des nœuds capteurs [ALL09].


2.4.2.1 Algorithme d’attribution de rôle

L’algorithme suivant explique la procédure d’affectation de rôles.AffectationRole{if(NombreVoisin !=0){if(NbreVoisinRepresentant == 0)//Aucun Représentant voisin alors le capteur le devient.RoleAffecté = Representant ;else{if(NbreVoisinRepresentant == 1)& &(RoleAffecté != Representant){//il existe un seul représentant lié aux nœuds ce//qui oblige les autres capteurs a devenir des nœuds simpleRoleAffecté = Simple ;}else{//plusieurs représentant autour du nœud alors ce//capteur ne peut être qu’un noeud de liaisonRoleAffecté = Liaison ;}}}}L’application de tel algorithme mène le réseau a se représenté de la

façon suivante :


FIG. 2.5 – Affectation des rôles dans un RCSF.

2.5 Le protocole de routage adopté

Le protocole de routage suivant se base sur le principe d’attribu-tion de rôles qui se compose en plusieurs étape résumées dans lespoints suivant :• La détection du voisinage ;• Changement de rôles ;• Détection des groupes voisins ;• Résolution de conflits entre représentants ;• Gestion de la redondance.• Mécanisme de détection des pannes.

Sachant que les nœuds de ce système intéragissent par envois demessages. Les intéractions entre les 3 agents permettent de comprendrele fonctionnement de ce protocole. Ces intéractions sont définies parrapport au rôle attribué.


2.5.1 Les Diagrammes UML

Les Diagrammes suivant la méthode UML, plus précisément lediagramme Etat-Transition et Diagramme de Séquence sont élaboréspour présenter les différents états d’un nœud et pour donner uneidée générale et plus claire sur le principe de l’approche suivie.

FIG. 2.6 – Diagramme Etat Transition.


FIG. 2.7 – Diagramme De Séquence.

2.5.1.1 La détection du voisinage

Le voisinage d’un nœud est détécté pour assurer la connexiondu réseau. Dans ce contexte, Chaque capteur diffuse un message dit"Message HELLO" (à tout les nœuds d’un seul saut). Ce message estdéfini comme suit :

Type Source Destination NSaut


Chaque nœuds recevant ce message (HELLO) répond par un mes-sage à destination (non rediffusable) structuré ainsi :

Type Source Destination Rôle Groupe Position NSaut[BEC09]

Par l’envoie de ces messages, tout les nœuds peuvent mettre à jourleurs table de voisinage et de ce principe le changement de rôle peutaffécté les nœuds capteur.

2.5.2 Changement de rôles :

Lors de la détection de changement dans la table de voisinage parun nœud. Ce dernier éxécute l’algorithme de changement de rôle ex-pliqué précédemment en envoyant un message "ChangeRole" qui ala structure présenté ci-dessous. Sachant que chaque nœud recevantce message sera obligé à éxécuté l’algorithme d’attribution de rôlestout en modifiant sa table de voisin.

Type Source Destination Rôle Groupe [BEC09]

FIG. 2.8 – Introduction d’un nouveau nœud.


2.5.3 Détection des groupes voisins

Les nœuds Représentants sont définis avec une table contenantles groupes voisins. Cette dernière doit être mise à jour suivant laconnaissance des nœuds liaisons entre les groupe en se servant dumessage HELLO.Cette figure présente le fonctionnement cité sur la détection des groupesadjacents.

FIG. 2.9 – Détection des groupes adjacents.

2.5.4 Vérification de la cohérence des groupes :

Le problème d’incohérence peut être détécté par un nœud simple.Parce que ce problème peut être causé si et seulement s’il existe deuxgroupes disjoint c.à.d les nœuds simples se voient mais leurs repré-sentant ne peuvent pas commnuniquer (Manque d’un nœud liaison).Le schéma suivant illustre ce problème :

À l’instant où un nœud détecte l’incohérence, il propage un mes-sage "VérifCohérence" qui est formé de :

Type Source Destination Rôle Groupe GrpVoisin [BEC09]

La réception du message "VérifInconhérence" déclanche la procé-dure d’attribution de rôle. Aprés l’éxécution de cette procédure etsi l’incohérence est confirmée, un nœud Représentant peut changerson rôle en affectant à un autre nœud le rôle Représentant en lui en-


FIG. 2.10 – Correction du problème d’incohérence.

voyant le message "PasseReprésentant" comme le montre la structuresuivante :

Type Source Destination Groupe [BEC09]

2.5.5 Résolution de conflits entre représentants

Un réseau de capteur suit une topologie dynamique, c-à-d la to-pologie peut changer à cause de la mobilité d’un nœud (épuisementd’énèrgie....). Cette configuration peut produire un conflit entre lesgroupes dans le cas où deux représentants deviennent voisins.

Ce problème peut être résolu à l’aide du message "ResConflit" quia le format suivant :

Type Source Destination Score [BEC09]

Sachant que le "Score" défini l’énergie restante de chaque Repré-sentant pour pouvoir désigner le meilleur nœud au niveau d’énèrgie.De ce fait, Le nœud Représentant qui reçoit ce message peut soit restéReprésentant si son score est élevé en renvoyant le message "ResCon-flit", ou devenir un nœud Simple en diffusant le message "Change-Rôle".


FIG. 2.11 – Résolution de conflit entre Représentants.

2.5.6 Gestion de la redondance

Un nœud est dit redondant si et seulement s’il existe un autrenœud possédant le même rôle apte d’assurer précisément les mêmestâches du nœud condidat.Ce mécanisme de gestion de redondance est utilisé pour maintenirune longue du fonctionnement du vie au réseau avec un minimumde nœuds collaborant pour pouvoir réveiller les autres nœuds en casde défaillance d’un capteur.Ce processus est appliqué sur tous les nœuds dont leurs rôles est soitSimple ou Liaison de la façon suivante :

a. NŒUD SIMPLE :Un nœud Simple "S1" est dit redondant s’il existe un autre nœudSimple "S2" appartenant au même groupe que S1 tel que :

distance(S2,R) >= distance(S1,R)R : Nœud Représentant,d : Distance.

On peut formuler ce principe en utilisant la propriété de Ga-briel :


Redondant(S1)/S1εGi ⇒ ∃S2εGietS1εCercle(S2, Ri)[BEC09]

FIG. 2.12 – Redondance des nœuds simples.

b. NŒUD LIAISON :Un nœud liaison L1 est considéré redondant si et seulement s’ilexiste un autre nœud de liaison L2 tel que les représentants Ri

couvert par le nœud L1 sont inclus ou égal à l’ensemble desnœuds représentants couvert par L2.On peut formuler ça de la façon suivante :

Redondant(L1)/L1εGi ⇒ ∃L2εGi/Grp(L1) ⊆ Grp(L2) [BEC09]

- Gi un groupe de nœuds ayant Ri comme représentant.- Lj un nœud liaison dans le groupe Gi.- Grp(Lj) l’ensemble des groupes adjacents accessibles par Ri àtravers le nœud liaison Lj.- Le prédicat Redondant(Lj) valant "Vrai" quand le nœud Lj estdéclaré redondant.

2.5.6.1 Le principe suivi pour gérer la redondance :

La redondance des nœuds est gérer par l’échange des messages.Sachant que seulement le Représentant a l’habilité de changer l’étatd’un nœud qui fait partie de son groupe en se basant sur un message"ChangeEtat" qui est envoyé à un nœud précis pour soit le réveiller


ou l’endormir.La composition du message est comme suit :

Type Source Destination NS [BEC09]

Sachant que :

- NS "NEW STATE" est le nouveau état destiné à un nœud par sonreprésentant.Le mécanisme est présenter dans la (Figure 2.13) :

FIG. 2.13 – Changement d’état d’un nœud.

2.5.6.2 Mécanisme de détection des pannes

Le mécansime de détection de pannes est éxploité au niveau decette approche. Dans ce contexte, l’échange pèrdiodique du message"HELLO" permet au nœud Représentant de découvrir la défaillancedes autres nœuds appartenant à son groupe.Le principe peut être décrit dans ces points :

? Le nœud Représentant diffuse pèriodiquement le message "HELLO"aux nœuds actifs.

? Tous nœuds recevant ce message répond par le message "HEL-LORep" c.à.d que ces nœuds collaborent toujours dans le réseau.

? Le nœud qui ne répond pas, est considéré défaillant par le Re-présentant, ce dernier réveille tous les nœuds voisins et lance le


processus d’affectation des rôles en diffusant le message "Chan-geEtat".

2.5.7 Collecte d’information

Un réseau de capteur est configuré pour la collection d’informa-tion, tel que la température, la pression, ou des informations multi-média.L’approche utilisée se base sur l’utilisation de deux messages simplesde type scalaire Data et DataReq défini comme suit :

Type Source Destination Mesure

Type Source Destination

Le sink diffuse sa requête en utilisant DataReq à tous les nœuds,Ces derniers exploite ce message selon leurs rôles .

. Nœud Liaison : Passe la requête à tous ses représentants voisins.

. Nœud Simple : Envoie la valeur mesuré à son représentant.

. Nœud Représentant : Répond à la requête en envoyant l’infor-mation captée par son groupe en utilisant le chemin optimal quiest connu par l’envoi périodique du message "HELLO" avec lechamp "HC"(Hop Count).


2.6 Conclusion

Ce chapitre à présenter le protocole utilisé et proposé par [BEC09]pour la gestion de la redondance et la tolérance aux pannes.

La nécessité de la longue durée d’un réseau de capteur sans filpousse les chercheurs a proposés différents mécanismes de consom-mation d’énergie, surveillance aux niveau de ces réseau. De ce fait, laconfiguration en groupes permet l’auto-organisation des nœuds sansfaire appel au sink.

Le déploiment aléatoire des nœuds implique la présence des cap-teurs redondants, Ces derniers sont mis en veilles afin de minimiserla consommation énergitique des nœuds sachant que ces capteurssont réveillés en cas de besoin.

Dans les chapitres suivant, nous présenterons les outils de simu-lations existants tout en justifiant notre choix, ainsi on va montrer lesrésultats de simulation pour valider l’approche étudiée et proposerd’autre suggéstions.

Chapitre 3

Simulation de la surveillance en RCSF

Les technologies informatiques s’étendent de plus en plus ce quimène à l’apparition de plusieurs systèmes et ainsi différentes mé-thodes de gestion.Dans le modèle réseau, l’étude passe essentiellement par l’étude deses composants atomiques. Ce principe est forcément appliqué pourles réseaux de capteurs sans fil, les différentes propositions des cher-cheurs pour remédier aux problèmes des RCSF tel que la consomma-tion d’énergie, la durée de fonctionnement du réseau, les contraintesde collecte d’informations... nécessite une phase de test avant la miseen place. Pour cela, la solution la plus fiable et la moins coûteuseconsiste en " La Simulation ".

La simulation des réseaux de capteurs consiste principalement enla reproduction du comportement et du fonctionnement des nœudscapteurs dans un environnement informatique ; pour des raisons telque :La répétition d’expérience, L’adressage des systèmes complexes, Legain de temps et la variation des paramètres de simulation alors quela simulation réelle s’avère coûteuse, voir impossible dans quelquecas.

Dans ce qui suit, nous parlerons brièvement des simulateurs de

Simulation de la surveillance en RCSF 63

réseaux éxistants, du simulateur choisi pour nos simulations "OM-NET++" et de la plate forme des simulations de réseaux de capteursans fil "CASTALIA".


3.1 Généralités sur la simulation

Dans nos jours, la simulation connaît un essor considérable, et cegrâce à l’intérêt que présente les modèles informatiques des systèmessimulés ;

Définition 2 La simulation consiste à la modélisation informatique d’unsystème quelconque, en offrant une représentation de toutes les entités de cesystème, leurs comportements propres, ainsi que leurs interactions. Elle metà la disposition de l’utilisateur un environnement d’expérimentation donton peut faire varier les paramètres.

Grâce aux progrès réalisés dans le domaine du développement etdes techniques de programmation, nous disposons aujourd’hui delangages de programmation trés puissants. Ainsi, il devient possiblede réaliser un simulateur dans un environnement de programmationexistant.

3.2 Types de simulation

En fonction du type d’évènements dans la simulation, nous distin-guons deux types de systèmes de simulation : les systèmes discretset les systèmes continus.

3.2.1 Systèmes de simulation discret :

Sont des systèmes pour lesquels les variables concernées par la si-mulation ne changent d’état qu’en un nombre fini de points sur l’axedu temps. On appelle également ces systèmes : systèmes de simula-


tion à évènements discrets.

3.2.2 Systèmes de simulation continue :

Ce sont des systèmes pour lesquels les variables peuvent changerd’état à n’importe quel instant pendant la simulation.

3.3 Les simulateurs de réseau éxistant

Il existe plusieurs simulateurs de réseau tel que : NS2, OMNET++,OPNET, GLOMOSIM, JSIM...etc. [TBL08][CET05]Parmi ceux, on va cité quelques simulateurs comme NS2, GLOMO-SIM et bien sur notre simulateur OMNET++.

3.3.1 NS2 :

NS est un simulateur à évènements discrets trés répandu dans ledomaine de la recherche pour tout ce qui se refère aux réseaux.L’utilisation de l’appéllation "NS2" précise la version du simulateurNS.Il constitue un support important pour la simulation de protocolesTCP, protocoles de routage, protocoles de multicast.Le developpement de NS suit une approche orientée objet qui utilisedeux langages de programmation : C++ et TCL. Les modules de basedu simulateur et les protocoles sont implémentés en C++ avec unecouche TCL au-dessus, qui fournit une interface flexible et facile àutiliser [5].La figure suivante illustre les différents composants internes du si-mulateur :


FIG. 3.1 – Description architecturale du simulateur NS2.

3.3.2 GloMoSim

GloMoSim (Global Mobile information system Simulator) a étéconçu selon une architecture orientée « couche » similaire que celledes sept couches OSI pour les réseaux [MAK08].Il a été développé au laboratoire UCLA Parallel Computing Labora-tory en utilisant le langage PARSEC.PARSEC (PARallel Simulation Environnement for Complex system)est un langage de programmation dérivé du langage MAISIE. Tousdeux sont destinés à la simulation à évènements discrets. Ils ont étédéveloppés à partir du langage C à l’université UCLA (UniversityCaliforinia Los Angeles).


Le transfert de paquets dans GloMoSim se fait selon le schéma sui-vant :

FIG. 3.2 – Transfert des paquets dans GloMoSim.


3.3.3 OMNET++

OMNeT++ IDE (Integrated Development Environment ) est basésur la plateforme Eclipse. C’est un environnement open source quifournit des outils pour la création et la configuration des modèles deréseaux (les fichiers NED et INI) et des outils pour l’éxécution d’unlot de programmes ainsi que pour l’analyse des résultats de simula-tion [MSK05].OMNeT++ semble être le meilleur parmi les solutions open source etfreeware. OMNeT++ semble séduire de plus en plus la communautéscientifique et un nombre croissant de modèles sont disponibles.Dans ce qui suit, il aura une vue plus détaillée sur le simulateur ainsiles raisons du choix de ce simulateur.

3.4 Comparaison entre les simulateurs

La simulation est souvent moins chère que l’expérimentation etcomporte beaucoup moins de risques lorsque l’homme fait partie dusystème étudié. Les résultats peuvent être obtenus beaucoup plusrapidement. La simulation (surtout numérique) est basée sur uneconnaissance des phénomènes qui ne peut être obtenue que par l’ex-périmentation.Une simulation ne peut donc être réalisée que si on dispose d’un ac-quis de connaissances suffisant obtenues par des expérimentationssur des phénomènes antérieurs et analogues. Quelle que soit la qua-lité de la simulation, elle ne remplace pas totalement l’expérimen-tation. Voici un tableau général décrivant les avantages et inconvé-nients des simulateurs décrit auparavant [RSA09] :


Simulateurs Avantages InconvénientsNS2 ◦ Utilise l’Orienté Objet, ◦ Conçu pour les réseaux

filaires,◦ Permet la simulation descomportements des proto-coles standard,

◦ Difficulté d’ajout denouveau modèles à causedes dépendances entremodules,

◦ Nombreux protocolesdisponibles,

◦ Intégration difficile àd’autres applications,

◦ Simulateur Multi-Couches.

◦ La faible performancedes simulations de réseauximportants,◦ Scénario de simulationdécrit en Otcl.

GloMoSim ◦ Initialement conçu pourles réseaux sans fil (Surtoutles réseaux Ad Hoc),

◦ Nécessité de maitriserle Parsec pour toute per-sonnalisation autour dunoyau,

◦ Exécution des simula-tions relativement rapide,

◦ Installation assez com-plexe.

◦ Environnement de simu-lation parallélisable.

OMNET++ ◦ Architecture modulairepermettant l’intégration denouveaux modèles,

◦ Ne prend pas en chargele cas des réseaux de cap-teurs.

◦ Utilisation du C++ (et ré-cemment du C#) pour ledéveloppement du noyau,

◦ Peu de modèles pour lesréseaux sans fils,

◦ Les classes de base dusimulateur peuvent êtreétendues et personnali-sées,

◦ Description des modèlesen langage NED.

◦ Conception de modèlesse rapprochant de la réalitégrâce à une hiérarchie gra-nulaire très flexible,◦ Diverses interfaces utili-sateurs pour l’exécution dela simulation.


3.5 Le Simulateur OMNET++(Objective Modular Net-work Testbed in C++)

3.5.1 Choix du simulateur OMNET++

Le déploiement d’un réseau de capteurs exige une étape de simu-lation avant son installation sur site. La simulation permet de testerà moindre coût les performances d’une solution.OMNeT++ est un environnement de simulation à événements dis-crets basé sur le langage C++, une application open source et souslicence GNU [IDE04]. Il est totalement programmable, paramétrableet modulaire ainsi grâce à son architecture flexible et générique, il aété utilisé avec succès dans divers domaines, notamment [OMN04][?] :

– La modélisation de réseaux de file d’attente,– La modélisation de protocoles de communication,– La validation des architectures hardware,– L’évaluation de performances pour des systèmes software com-

plexes.

OMNET++ sera notre environnement de simulation, grâce à son ar-chitecture modulaire, il s’agira d’étendre le simulateur en implémen-tant un nouveau modèle spécifique aux réseaux de capteurs.

3.5.2 Présentation d’OMNET++

OMNET++ est un environnement de simulation à évènements dis-crets. Utilisé pour la simulation des réseaux de communication, etd’autres systèmes distribués [ABD09].Grâce à son architecture modulaire, OMNET++ est très largement ré-pandu dans divers domaines d’applications tel que :


FIG. 3.3 – Le lancement du simulateur Omnet++.

– La modélisation des protocoles de communications,– La modélisation des réseaux filaires et sans fils,– La modélisation des systèmes répartis,– Les architectures HardWare,– En général, il peut être utilisé pour n’importe quel système à

évènements discrets pouvant être modélisé selon des entités com-muniquant par envoient de messages.

OMNET++ est basé sur la plateforme Eclipse. [?] Il fournit des ou-tils pour la création et la configuration des modèles de réseaux (lesfichiers NED et INI) et des outils pour l’exécution d’un lot de pro-grammes ainsi que pour l’analyse des résultats de simulation.

3.5.3 Desciption architecturale d’OMNET++

Les modèles OMNET++ constituent en un ensemble de moduleshiérarchiquement emboités tel qu’il est montré dans la (Figure 3.4) :


Les modules Simples sont écrits en C++ en utilisant la librairie de

FIG. 3.4 – Architecture modulaire du simulateur Omnet++.

simulation d’OMNET++, Ces derniers contiennent des algorithmesrelatifs au modèle implémenté. Le groupement des modules simplesconstitue des modules composés sachant que leurs communicationssont gérées grâce à des connexions entre les modules via des " gates(ports) ".Au niveau plus élevé, le module système est crée par l’utilisateur.C’est un module spécial qui n’a pas de connexions avec l’environ-nement extérieur, mais plutôt avec ses composants internes(Modulessimples et composés) [IDE04].Les modules peuvent s’attribuer des paramètres assignés aux mo-dules dans les fichiers de description de réseaux (fichiers NED) ouencore dans le fichier de configuration « omnetpp.ini ». Ces para-mètres sont utiles pour la personnalisation du comportement desmodules simples ou encore pour le paramétrage de la topologie dumodèle.

3.5.4 Installation du simulateur OMNET++

L’installation d’OMNET++ se fait en différentes étapes suivant uneprocédure d’installation décrite dans le package téléchargé selon lesystème d’éxploitation installé [OMN10]. Les éléments installés sur


l’ordinateur seront les suivants :

. Une bibliothèque de simulation interne.

. Un compilateur du langage descriptif de la topologie NED (nedc).

. Un éditeur de réseaux graphiques pour les fichiers NED (GNED).

. Un éxécutable Omnet++.

. Une Interface graphique de simulation IDE.

. Un outil de documentation de modèle (opp_neddoc).

. Autres utilitaires (l’outil de création makefile, etc.).

. Une documentation, des simulations types, etc.

3.5.5 Les principaux fichiers d’OMNET++

Les différents fichiers sont [OMN04] :

3.5.5.1 Fichier (.Ned) :

Utilise le langage NED de description de réseau. Il peut être uti-lisé en 2 modes : Mode Graphique ou Mode Texte qui permettent dedécrire les paramètres et les ports du module. Les erreurs comisentsont indiquées en temps réel par un point rouge situé à la gauche ducode.Un exemple de fichier Ned en mode "Source" & "Graphique" sontprésentés dans la(Figure 3.5) et (Figure 3.6).


FIG. 3.5 – Fichier NED en mode graphique.

FIG. 3.6 – Fichier NED en mode texte.


3.5.5.2 Fichier (.ini) :

Est lié étroitement avec le fichier NED. Permet à l’utilisateur d’ini-tialisé les paramètres des différents modules ainsi la topologie du ré-seau.Voici un exemple présenté ci-dessous :

FIG. 3.7 – Exemple d’un Fichier *.Ini.

3.5.5.3 Fichier (.msg) :

Les modules communiquent en échangeant des messages. Ces dér-niers peuvent être déclarés dans un fichier dont l’extension est (.msg)où l’on peut ajouter des champs de données. OMNeT++ traduira lesdéfinitions de messages en classes C++.

Le diagramme suivant peut donner une idée plus détaillé sur ledéveloppement d’éxécution d’une simulaion sous Omnet.


FIG. 3.8 – Exécution d’une simulation sous OMNeT++.[?]

3.6 Les plates formes d’OMNET++

Le simulateur OMNeT++ n’est pas spécilisé pour les réseaux decapteurs sans fils, Pour cela il existe plusieurs extentions, plate formeet simulateurs basés sur OMNET++ qui essayent d’introduire ce manquecomme "Mobility FrameWork", "Mixim", "Castalia" ...etc

3.6.1 Mobility FrameWork

Cette plate forme assure la mobilité des hôtes dans le réseau, leursconnectivité ainsi un canal sans fil. Elle supporte la simulation desréseaux sans fil, les réseaux mobiles et même les réseaux de capteurssans fil [LWI07]. Pour information, Mobility FrameWork 2005 était laplate forme préférée pour la simulation des réseaux Ad Hoc.

Elle est réalisée avec des modules de base, donc l’utilisateur peutles utilisés afin de créer et d’implémenter de nouveaux protocolespour la simulation.


Le cœur de Mobility FrameWork est composé de [DSR03] :– Mobility Controller (Gestion de la mobilité).– Channel Control (La gestion dynamique de connexion entre les

hôtes.

FIG. 3.9 – Architecture de Mobility et Channel Control.

La simulation d’un réseau avec une tel plate forme est basé sur lacompréhension du principe et des propriétés de fonctionnement deMobility FrameWork (détaillé dans ce qui suit).

3.6.1.1 La structure d’une hôte mobile

La structure interne d’un nœud (Hôte) en Mobility FrameWork estschématisé dans la figure suivante [LWI07] :


FIG. 3.10 – Architecture interne d’un nœud dans MF.

3.6.2 Mixim

Mixim [ABD09] est un simulateur qui intègre et développe plu-sieurs cadres existants pour les simulations sans fil et mobiles dansOMNeT++. Bien que OMNeT++ n’a pas un soutien clair des mo-dèles de simulation pour la communication sans fil, Mixim fournitdes modèles détaillés de canal sans fil (décoloration, etc), la connec-tivité sans fil, la mobilité, les obstacles et les protocoles MAC commeIEEE 802.11b et IEEE 802.15.4. Mixim propose des modules pour unemise en œuvre facile de nouvelles protocoles MAC comme Time Di-vision Multiple Access (TDMA) ou en fonction des protocoles hy-brides (p. ex Z-MAC). Mixim est écrit avec le langage C++ commeCastalia et OMNeT++.

3.6.3 Castalia

Castalia [ABD09] [LIL09] est également un simulateur de niveaupour les réseaux de capteurs basé sur OMNeT++. Il s’agit d’un simu-lateur générique avec un canal sans fil et un modèle de radio basé sur


des données mesurées . Comme il est illustré à la (Figure 3.11), Cas-talia définit trois modules principaux : le nœud, Processus physiqueset les canaux sans fil. Castalia est développé avec le C + +.

FIG. 3.11 – Les connections des modules sous Castalia.

Le module nœud est en fait un composite.La (Figure 3.12) montrela structure interne du module nœud. Les flèches pleines signifient lepassage de message et les flèches en pointillés signifient une interfaceentre les modules et les appels fonctions.Par exemple, la plupart des modules font appele au gestionnaire deressources pour signaler la consommation d’énergie. Le Module d’ap-plication est le plus touché par l’utilisateur, le plus souvent par lacréation d’un nouveau module pour mettre en œuvre un nouvel al-gorithme. Les modules MAC, Routage, ainsi que le module de mo-bilité, sont également modifiés, généralement la création d’un nou-veau module est en cause pour la création d’un nouveau protocole.Tous les modules existants sont très accordés par de nombreux para-mètres.

Remarque 1 D’aprés la description des 3 plates formes précédentes, onpeux facilement conclure que la plate forme "Castalia" est la plus appro-


FIG. 3.12 – Les principaux composants d’un nœud .

priée pour notre projet. Son cadre de "Wsn" nous facilite le traitement denotre application ainsi que l’évaluation du nouveau protocole.En plus Castalia est basé sur OMNeT++ l’un des simulateurs les plus po-pulaires pour les Réseaux de capteurs sans fils.

3.7 Détails sur Castalia

Comme il est décrit précédemment Castalia est une plate formesous OMNeT++ conçue particulièrement pour les RCSF [SAY09] .La structure de Castalia [BOU10] est également reflétée dans l’hiérar-chie avec un code source. Chaque module contient un dossier "ned"qui définit le module lui même. Si le module est composé, les sous-répertoires existant définissent les sous-modules avec un code deC++ (cc, dossiers de h) qui définit son comportement. Cette hiérar-chie complète des dossiers "ned" définit la structure globale du simu-lateur de Castalia.Les principaux modules de Castalia sont :


3.7.1 Le module MAC

La couche MAC joue un rôle trés important en infectant les diffé-rents états aux nœuds pour améliorer l’efficacité énergétique : nœuden état de transmission (Transmit), d’écoute (Idle),ou en sommeil (Sleep).Le module "Radio" modifie ces états en fonctions des cas particuliers.Les utilisateurs peuvent modifiés les paramètres aux exemples illus-trés au niveau de Castalia pour la couche MAC en utilisant le fichierde configuration OMNeT++ (. ini). Par un simple réglage de certainsparamètres des fichiers MAC "CSMA/CA", "TMAC", et "l’AMCC" dedifférents simulations seront gérés.

3.7.2 Le module Radio

Il est conçu sur la base des réseaux de capteurs sans fil avec troisétats : le sommeil, la transmission et l’écoute. En outre, la consomma-tion d’énergie sera différentes dans chaque Etat. C’est la caractéris-tique principale de ce module. La figure a état fini peux donner uneidée générale sur le changement d’état.

FIG. 3.13 – La machine à état fini du module Radio.


3.7.3 Canal sans fil

Le module du canal sans fil est conçu pour modéliser l’environne-ment sans fil, qui est une évolution dynamique de l’environnementpour le nœud statique et mobile. Il ya quatre principaux modèles decanal sans fil qui sont conçus :1) la modélisation moyenne de perte de trajet ;2) la modélisation des variations temporelles ;3) les interférences ;4) la modélisation simple .Castalia utilise certaines formules pour estimer chacun des quatremodèles selon de nombreuses expériences réalistes.

3.7.4 Le module Routage

La fonction la plus importante du module de réseau est de recevoirle message de MAC module, et envoyer un message à la demande. Ildépend des informations d’entête, Il existe deux types d’algorithmesde routage dans Castalia : simpleTreeRouting et multipathRingsRou-ting.Tous les modules de routage partagent 3 paramètres sont :1) maxNetFrameSize :détermine la taille maximum de paquet.2) le netDataFrameOverhead : place les frais généraux supplémentairesaux paquets d’application,3) netBufferSize indique la taille de l’amortisseur trouvé dans le mo-dule.

3.7.5 Le module Application

Le module Application est le module principal utilisé pour contrô-ler d’autres modules tels que le module de gestion des ressources,module de traitement physique, le module de routage, et le module


radio. Ainsi ce module utilise également le mécanisme de messagepour effectuer des actions différentes.

3.8 Outils de Simulation

L’installation du simulateur OMNET++ et la plate forme Castaliaest comme suit :

3.8.1 Installation d’OMNET++ Version 4

Avant de commencer l’installation, il faut tout d’abord téléchar-ger le code source omnetpp4 du site (http://www.omnetpp.org/ )sans oublié de vérifié la version Linux, ensuite copier la source dansle dossier voulue et se positionner avec l’invite de commande dansce dossier et suivre les étapes suivantes :1. sudo tar zxf omnetpp-4.0b2-src.tgz -C /usr/local/ ;2. cd /usr/local ;3. sudo ln -s omnetpp-4.0b2 omnetpp ;4. sudo apt-get install bison, flex, blt, lmodern, giftrans, doxygen,libxml2-dev, graphviz, imagemagick ;5. sudo apt-get install tcl8.4, tk8.4, tcl8.4-dev, tk8.4-dev ;6. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH :/usr/local/omnetpp/lib ;7. export TCL_LIBRARY=/usr/share/tcltk/tcl8.4 ;8. export PATH=$PATH :/usr/local/omnetpp/bin ;9. cd /usr/local/omnetpp ;10. sudo ./configure ;11. sudo make .

Remarque 2 Les étapes 6, 7, 8 doivent être ajouté dans le fichier "∼/.bashrc"pour de futur convenance.


3.8.2 Installation de Castalia3.1

Les étapes sont les suivantes [BOU10] :

1. Décompression de l’archive Castalia déja télecharger à partir dusite (http://castalia.npc.nicta.com.au/download.php )avecla commande :

xzf castalia.tgz ;

2. Importation du projet dans OMNeT++ ide : Aprés avoir lancerOmnet++, l’importation du projet se fait avec un clique droit sur"General->Exiting project into workspace" et en choisir la racinedu projet.

3. Exécution d’un exemple : Une fois l’importation est en complet,un click droit sur le fichier omnetpp.ini de n’importe quel exemplelance la simulation et génére un fichier *.txt qui se définit commele fichier trace de la simulation.

3.8.2.1 Les Commandes Castalia

Faut se situé dans le répertoire voulu :

1. ../../bin/Castalia Affiche la liste des fichiers et des configurations.

2. ../../bin/Castalia -c General Commencer l’éxécution de la confi-guration. Ce qui donne un fichier trace.

3. CastaliaResults Affiche les résultats obtenus lors de l’éxécution.

4. CastaliaPlot Affiche le graphe des simulations.

3.9 Implémentation d’un réseau

Castalia a pris en considération le développement de nouveauxprotocoles au sein de cette plate forme. Dans ce contexte, les fichierstemplate facilite la création d’un nouveau réseau avec les différents


couches.

Pour l’implémentation il suffit de copier les fichiers nécéssairesdans un nouveau répertoire de votre choix.

Nous avons adopté ce principe et créer un nouveau répertoire ap-pelé "RCSF" ensuite copier les fichiers "yourNetwork.ned", "yourAppli-cation.ned", "yourHost.ned", "omnetpp.ini". Ces derniers contiennentdes racines de procédures, où chacun peut modifié et élaboré sonprotocole.

Le programme sera complet que par l’ajout et la programmationdes fichiers ".cc", ".h", ".msg" des différents modules.

Une fois que tous les fichiers sont complet, la plateforme Castaliaprendra en considération ce nouveau réseau seulement en éxécutantles étapes de compilation suivante :

1. Créer le fichier Makefile en éxécutant " opp_makemake -f"

2. Compiler en utilisant "make".

Aprés ces étapes, et seulement s’il n’existe pas d’erreurs un nouveaufichier "youNetwork" sera créer, en l’éxécutant la simulation com-mencera.


3.10 Conculsion

Dans ce chapitre nous avons présentés les différents simulateursexistant pour les réseaux de capteur sans fil. Parmi ces simulateurs,notre choix a été fixé sur OMNET++ essentiellement à cause de saconstruction modulaire et sa fléxibilté.

Le manque du simulateur OMNET++ au niveau des prtocoles deréseaux de capteur à été sollutionné avec l’implémentation des diffé-rentes plates formes tel que : Castalia.

Dans le chapitre suivant, on décrira nos étapes de programmationdu protocole proposé dans le chapitre 2, le plus intégré au sein dusimulateur OMNeT++ et Castalia au niveau des différentes couchesainsi on analysera les résultats de simulation d’un réseau avec et sansredondance.

Chapitre 4

Implémentation et Simulation

L’évolution de l’informatique a été marquée par l’apparition desystèmes microélectromécaniques miniaturisés : les réseaux de cap-teurs sans fil. De nombreuses applications nouvelles émergent chaquejour de ces systèmes, mais il reste encore de nombreux défis à relever.

Pour résoudre les problèmes posés par la conception des réseauxde capteurs, il est impératif de passer par la simulation de ces ré-seaux. Cependant, de tels réseaux ne sont jamais complètement prisen charge par les simulateurs de réseaux existants.

La nécessité de passer par la simulation a déjà été démontrée pré-cédemment. Notre étude sur quelques simulateurs réseaux nous aconduit à choisir un simulateur en particulier : OMNET++.Il a fallu peser les avantages et inconvénients présentés par chacundes simulateurs et faire des compromis dans ce sens.

Notre travail consiste, à la base, à adapter un simulateur de ré-seaux (OMNET++) avec l’utilisation de Castalia au cas particulier desréseaux de capteurs.

Dans ce chapitre , il aura une présentation détaillée sur l’implé-

Implémentation et Simulation 89

mentation de notre méthode de surveillance ainsi les résultats obte-nus qui seront discutés dans ce même chapitre.


4.1 Environnement de travail

Nous allons détaillés les outils utilisés dans la réalisation de notresimulation.

4.1.1 Environnement matériel

La simulation a été réalisée sur un ordinateur Acer dont la confi-guration est :

Processeur Core2Duo 2.0 GHzMémoire 2GB DDR2Disque dur 160 GOCarte Memoire 2 Go

4.1.2 Environnement logiciel

Notre simulation a été réalisée dans l’environnement logiciel sui-vant :

– Système d’exploitation : Linux Distribution Ubuntu.– Le simulateur OMNet++ 4.0 ;– Le Simulateur Castalia 3.1.

4.2 Processus de simulation

Voici le processus de simulation que nous avons adopté pour l’éla-boration de notre projet résumé dans la (Figure 4.1)


FIG. 4.1 – Processus de Simulation.

4.3 Réalisation du projet

4.3.1 Objectif

Notre objectif est d’ajouter au niveau du simulateur Castalia unenouvelle approche et ainsi de tester la validité de cette dernière.Suite à ça, nous nous sommes trouvés face à implémenter complè-tement un nouveau module dans la couche réseau et d’ajouter denouveaux concepts aux niveau des autres couches pour pouvoir at-teindre notre but.Pour cela, nous avons tout d’abord créer un module "nœud" avec toutses sous modules, ensuite implémenter les différents messages utili-sés et ensuite programmer le module de la couche Réseau et enfinsimuler notre approche.

4.3.2 Description de la conception d’un nœud

Un réseau de capteur sans fil est caractérisé par le deployementaléatoire des nœuds.


Pour notre simulation, la 1ere chose qu’on devait modélisé est le mo-dule nœud avec ses différents sous modules (La pile protocolaire).

Pour une vue mieu explicatif, le fichier graphique ".Ned" illustreles différents modules utilisés.

module WsnNode{

parameters :double numHosts ;@display("bgb=250,250,white ;bgp=10,10 ;i=misc/node_vs,gold") ;

gates :input radio @directIn ;

submodules : Les modules qui compose le nœudbattery : Battery @display("p=200,65,i=block/bucket") ;basicMobility : BasicMobility

{@display("p=206,174") ;}

nic : Nic {@display("p=94,190 ;i=device/card") ;}

wsnNetwLayer : WsnNetwLayer {@display("p=103,117") ;}

wsnApplLayer : WsnApplLayer {@display("p=94,41") ;}

connections :}


FIG. 4.2 – Fichier graphique ".ned" du nœud.

D’aprés les 2 fichiers, on peut résumé que le nœud dans notre si-mulation a été conçu de sorte a ce qu’il contient les différentes couchesdécrites par les sous modules comme suit (Du haut en bas) :

Couche Réelle sous Module décrivant la coucheCouche Application WsnApplLayerCouche Réseau WsnNetwLayerCouche Phy + MAC Nic

En plus de ces sous modules, il existe les sous modules suivants :

"Battery" : un réseau de capteur est nécéssairement modélisé parune batterie au niveau de chaque capteur.

"mobility" : Pour pouvoir définir la topologie du réseau ainsi pourconnaitre la position de chaque capteur.

Dans les section suivantes, on détailera la programmation de chaquecouches avec leurs code ".cc" et leurs fichier ".ned" sachant que ces


dernieres sont implémentées à partir des modules de base de Casta-lia.

4.3.3 Description du réseau

La structure du Réseau est définit dans le fichier (WsnNetwork.ned).Ce dernier comme cité auparavant se compose de deux parties : Lapartie Graphique et la partie Source (Figure 4.3).Un réseau de capteur sans fil est composé du module nœud décritprécedemment ainsi d’un canal pour la communication entre nœudet processus physique pour la gestion des données capturées par lescapteurs.

Les connections entre nœuds sont gérées au niveau de cette struc-ture dans "Connections" mais nous avons choisis de laisser une gé-nération aléatoire pour se rapprocher plus aux concepts des RéseauxDe Capteurs Sans Fil.


module WsnNetwork{

parameters :double playgroundSizeX ;double playgroundSizeY ;double numNodes ;

@display("bgb=playgroundSizeX,playgroudSizeY,white„ ;bgp=0,0") ;submodules :

channelControl : ChannelControl{parameters :playgroundSizeX = playgroundSizeX ;playgroundSizeY = playgroundSizeY ;@display("p=33,27") ;

}node[numNodes] : WsnNode ;

{@display("p=201, 47") ;}

connections allowunconnected ://all connections and gates are to be generated dynamically

}

FIG. 4.3 – Fichier graphique ".ned" du réseau.


4.4 Implémentation

Nous allons commencé à donner un aperçu sur les messages im-plémentés, ensuite entrer dans le cœur des codes sources implémen-tés au niveau des différentes couches.

4.4.1 Structure des messages utilisés

4.4.1.1 Au niveau de la couche Application

Les messages utilisés sont des messages simples parce que notreApproche s’intéresse plutôt aux autres couches.

Dans OMNeT++ les messages peuvent être déclaré dans un fichier".msg". La structure du message "DATA" utilisé au niveau de cettecouche est comme suit :

FIG. 4.4 – Fichier ".msg" du message Data.

Nous avons tésté notre Approche avec un module existant sousCastalia, juste nous avons modifié l’acheminement du message dedonnées qui se passe entre nœuds Simple et nœud Représentant.

4.4.1.2 Au niveau de la couche Réseau

C’est cette couche qui nous intéresse le plus, De ce fait on com-mencera par illustré les différents messages implémentés au sein dela couche Réseau.Le premier message qui est envoyé par les nœuds est le message"Hello". Ce dernier permet au nœuds de connaitre leurs voisins et


de remplir la tables des voisins.

FIG. 4.5 – Le structure du message Hello et HelloRep.

Le message HelloRep a les même champs que Hello et comme plusles 3champs décrit.

Message d’affectation de rôle, Résolution de conflits (Figure 4.6),Vérification de cohérence et Changement de rôle (Figure 4.7)généréssous Castalia (OMNeT++).

FIG. 4.6 – Le structure du message "Passe Représentant" et "Résolution de conflit".


FIG. 4.7 – Le structure du message Verification de cohérence et Changement derôle.

4.4.2 Aperçu des Codes Sources

Tout d’abord, nous avons implémentés l’envoi periodique du mes-sage hello suite à un temps ou à un évènement qui peut se gérer selonle Schedule.

4.4.2.1 Envoi Periodique du Message HELLO

void WsnSurvey : : sendhello(){WsnHello *msg=new WsnHello("WsnHello",NETWORK_LAYER_PACKET) ; //Création du messagemsg ->setSrcAdress(SELF_NETWORK_ADDRESS) ;msg->setDestAdress(BROADCAST_NETWORK_ADDRESS) ;msg->setHelloKind(HELLO) ; // Remplir les paramètres du messagetrace() « "broadcast ["«msg->getName()« "] initialisation from "«msg->getSrcAdress()« " to "« msg->getDestAdress() ;scheduleAt(simTime(),msg) ; //Programmer l’envoi pèridiquetoMacLayer(msg,BROADCAST_MAC_ADDRESS) ; // Envoi du message a la couche MAC}

Une fois le Message HELLO est diffusé, chaque nœud recevant ceMessage doit répondre en envoyant un Message HELLO-Rep pourconfirmer sa présence comme étant voisin. Et de ce principe que latable des voisins se remplies selon le Code suivant :


void WsnSurvey : :updateTable(string s,string d, int r) {int role=1 ;NTable : :iterator pos ; pos = table.find(s) ; //Parcourir la table pour détécter si le voisin existeif (pos == table.end()) //Ajouter un nouveau Voisin{

Neighbor newEntry ;newEntry.Address=d ;newEntry.source=s ;newEntry.srcRole=r ;nbvois=nbvois+1 ;table.insert(make_pair(s,newEntry)) ; //Insérer le Voisintrace()«"vois"«nbvois ;trace()«"nveau voisin" «newEntry.Address«"et"«newEntry.source ;}

elseVoisin existe, MAJ du rôle {

Neighbor Entry=pos->second ;Entry.Address=d ;Entry.srcRole=r ;trace()«"voisin existe deja" ;

}role =RoleAttribute() ; //Attribution des RôlesWsnHello * msg=new WsnHello("WsnHello", NETWORK_LAYER_PACKET) ;msg->setRole(role) ;}

4.4.2.2 Attribution Des Rôles

Une fois la table remplie par un nouveau voisin, Ce nœud Com-mence à attribué les rôles selon les conditions de distribution des cap-teurs. Tout ça peut être résumer dans ce Code :


intWsnSurvey : :RoleAttribute(){trace()«"attribution" ;int nbLiaison=0 ;int nbRep=0 ;int nbSimple=0 ;for(NTable : :iterator pos=table.begin() ;pos !=table.end() ;++pos){Neighbor aNeighbor= pos->second ;if(aNeighbor.srcRole == 3){// Compter le nombre de representantsnbRep++ ;}if (aNeighbor.srcRole == 2) nbLiaison++ ;if (aNeighbor.srcRole == 1) nbSimple++ ;}trace()«"nbre repr"«nbRep«"et nbre liai "«nbLiaison«"et simple"«nbSimple ;//Debut exacte de l’algoritmeif(nbRep == 0) IchRole = 3 ;//noeud de liaisonelse{if (nbLiaison== 0) IchRole=2 ;//représentantelse{if (nbRep > 1) IchRole = 1 ; //noeud simple}}//fintrace()«IchRole ; // Afficher le rôle du nœudreturn IchRole ;

4.4.2.3 Gestion de la redondance

En utilisant la propriété du graphe de Gabriel, la couverture duréseau peut être assurer seulement avec le Représentant et les nœudsactifs. Chaque représentant du groupe déroule le processus résumédans (Figure 4.8).

Une fois les rôles ont été afféctés, Le nœud Représentant prendla main et commence la procédure de mettre en veilles les nœudsredondants.


FIG. 4.8 – Organigramme de redondance des nœuds simples.

L’algorithme suivi est comme suit :

void WsnSurvey : :redondant(){if(IchRole==3) {// IchRole est une//variable affecté au rôle du nœudfor(NTable : :iterator pos=table.begin() ;pos !=table.end() ;++pos){Neighbor aNeighbor = pos->second ;string* des=pos->second.Address ;if ((aNeighbor.srcRole == 1)&&(nbRep !=0)) { state = new cPacket("state",STATE) ;// Paquet//défini que le mode est SLEEPtoMacLayer(state,resolveNetworkAddress(des)) ;if ((aNeighbor.srcRole == 1)&&(nbSimple !=0)) { state = new cPacket("state",STATE) ;toMacLayer(state,resolveNetworkAddress(des)) ;}}} }


4.4.2.4 Rediffusion du Hello

Aprés chaque periode de temps le nœud Représentant envoi unMessage Hello pour re-découvrir ses voisins :La variable START définie l’interval de temps de la Rediffusion.

voidWsnSurvey : :timerFiredCallback(int index){if (index !=START) {trace()«"erreur" ;return ;}if(index==START){setTimer(START,interval) ;sendhello() ;}}

4.4.3 Le fichier .ini

Ce fichier permet à l’utilisateur de configurer ces modèles de si-mulation pour l’exécution. L’éditeur est en connaissance de toutesles déclarations NED (modules simple ou modules composés).


[General]#=============================================# Always include the

main Castalia.ini file#============================================= include

../Parameters/Castalia.inisim-time-limit = 100s //Temps de Simulation

SN.field_x = 80 # meters

SN.field_y = 80 # meters

# These tests include 3 nodes each,

coordinates will be specified manuallySN.numNodes = 100 //Nombre de nœuds

SN.deployment = "uniform"

//Type de Deployement # important wireless channel switch to allow mobility

#SN.wirelessChannel.onlyStaticNodes = true //Gestion de la Mobilité

#SN.wirelessChannel.sigma = 0

#SN.wirelessChannel.bidirectionalSigma = 0

# Choose a radio and set the Tx power to a low value so

# that node’s mobility has a better effect on connectivity

SN.node[*].Communication.Radio.RadioParametersFile ="../Parameters/Radio/CC1000.txt"

SN.node[*].Communication.Radio.TxOutputPower = "-5dBm"

#SN.node[*].Communication.Radio.mode = "IDEAL" //Type du Canal Radio

SN.node[*].Communication.Radio.collisionModel = 0

# These tests use big packets (2kb) to show interference clearly

#This requires to set the max pkt size in all communication layers

SN.node[*].Communication.RoutingProtocolName = "WsnSurvey" //La couche Réseau

SN.node[*].Communication.Radio.maxPhyFrameSize = 2500

# Throughput test application is used to send 2000-byte

# packets to node 0 (which by default is the receiving

# node for this app).5packets per second will be send

SN.node[*].ApplicationName = "BridgeTest" //La couche Application

SN.node[*].Communication.MACProtocolName = "BypassMAC" //La couche MAC

SN.node[*].Application.packet_rate = 5

SN.node[*].Application.constantDataPayload = 2000

# application’s trace info for node 0 (receiving node)

# is turned on, to show some interesting patterns

//Préciser la Collecte d’information au niveau des couchesSN.node[*].Application.collectTraceInfo = true

SN.node[*].Communication.Routing.collectTraceInfo = true

SN.node[*].Communication.MAC.collectTraceInfo = true

SN.node[*].Communication.Radio.collectTraceInfo = true

SN.node[*].ResourceManager.collectTraceInfo = true

SN.node[*].MobilityManager.collectTraceInfo = true


4.5 Résultats Obtenus

4.5.1 Deployement du Réseau

L’inconvénient de Castalia c’est qu’il ne permet pas d’avoir unevue du réseau au cours de l’éxécution sachant que les chercheurs ytravaillent dessus pour enréchir le Simulateur surtout aprés son éva-luation parmi les Simulateurs les plus sûr.˙ Pour cela, Ces figures montre le graphique du deployement desnœuds au niveau du réseau à l’état Initial.

FIG. 4.9 – Deployement des nœuds.


FIG. 4.10 – Exécution avec le Deployement .

subsectionFichier Trace Aprés une correcte compilation (sans dé-tection d’erreur) de Castalia avec les nouveaux paramétres commecitée précédemment, La génération de deux fichiers se crées :

– Fichier Trace : Ce dernier donne une vue générale et détaillée duprocessus parcouru de chaque nœud durant la simulation.

– Fichier Resume : Ce dernier affiche l’état du nœud en résumantpar exemple le nombre de packets reçus, perdus, et la consom-mation d’énergie.

4.5.1.1 Initialisation des nœuds

Un aperçu du fichier lors de l’initialisation ou le deployement desnœuds au niveau du réseau.


0 SN.node[0].MobilityManager initial location(x :y :z) is 43.9051 :47.4276 :0

0 SN.node[0].Communication.Radio Initialized RX mode to normal

0 SN.node[0].Communication.Radio Initialized TX power output to -5 dBm, consuming 26.7 mW

0 SN.node[0].Communication.Radio Default sleep level initialized to idle

0 SN.node[0].Communication.Radio completing transition to 0 (RX)
















0 SN.node[4].MobilityManager initial location(x :y :z) is 35.007 :23.8028 :0 0 .

.

.

.

.

.

4.5.1.2 Reconnaissance de voisinage

Dans cette periode tous les capteurs deviennent en mode RX etenvoie un message Hello pour la reconnaissance de voisinage dont


on peut le voir dans le fichier trace :

0.000937365 SN.node[11].Communication.Routing broadcast [WsnHello] in initialisation from 11 to -1

0.000937365 SN.node[11].Communication.MAC passage du message a la couche Mac avec dest -1et source 11

0.000937365 SN.node[11].Communication.Radio Buffered [BypassRouting packet] from MAC layer

0.000937365 SN.node[11].Communication.Radio SET STATE to TX, delay=1e-05, power=22.2

0.000947365 SN.node[11].Communication.Radio completing transition to 1 (TX)

0.000947365 SN.node[11].Communication.Radio Sending Packet, Transmission will last 0.00583333 secs

0.000947365 SN.node[10].Communication.Radio START signal from node 11 , received power -92.9274dBm



0.000947365 SN.node[7].Communication.Radio Failed packet (WC_SIGNAL_START) from node 11,






0.002031581 SN.node[13].Communication.Routing broadcast [WsnHello] in initialisation from 13 to -1

0.002031581 SN.node[13].Communication.MAC passage du message a la couche Mac avec dest -1et source 13



0.002041581 SN.node[13].Communication.Radio completing transition to 1 (TX)

0.002041581 SN.node[13].Communication.Radio Sending Packet, Transmission will last 0.00583333 secs



.

.

.

.


4.5.1.3 Table de voisinage et Affectation des rôles

Une fois les nœuds recoivent le message HELLO, chaque nœudrempli sa table de voisinage et à ce moment là, chaque nœud prendun rôle lui convenant selon sa position au sein du réseau.Ce processus est exécuté au début aprés la reconnaissance du voisi-nage et l’attribution des rôles.En cas de changement de rôle à cause de la mort d’un nœud, c’estle capteur Représentant qui devient responsable de ce changementet affecte un rôle aux autres nœuds aprés consultation de sa table devoisinage.

0.01620540 SN.node[14].Communication.Radio TX finished (no more pkts in the buffer) changing to RX

0.01620540 SN.node[14].Communication.Radio SET STATE to RX, delay=1e-05, power=22.2

0.01621540 SN.node[14].Communication.Radio completing transition to 0 (RX)

0.01621540 SN.node[1].Communication.MAC reception du message avec dest 1 et source 14

0.01621540 SN.node[1].Communication.MAC Delivering [WsnHello] to Network layer

0.01621540 SN.node[1].Communication.Routing Received [WsnHello] from MAC layer

0.01621540 SN.node[1].Communication.Routing debut d’envoie du message HELLRep avec source 1 et dest 14

0.01621540 SN.node[1].Communication.Routing remplissage de la table avec source 14 et dest 1 et role 1

0.01621540 SN.node[1].Communication.Routing nveau voisin 1 et 14

0.01621540 SN.node[1].Communication.Routing nbre repr 0 et nbre liai 0 et simple1

0.01621540 SN.node[1].Communication.Routing role est 3

0.01621540 SN.node[1].Communication.Routing avant l’envoie le role est 3

0.01621540 SN.node[1].Communication.MAC passage du message a la couche Mac avec dest -1 et source 1




.

.

.


4.5.1.4 Passage en Etat Sleep

Voici un extrait de code qui donne un aperçu sur l’état d’un nœudlorsque ce dernier reçoit le Message Changement d’état pour passerdu mode Réveillé en mode Sleep pour but "Gain d’énergie" commecité précédemment.

0.129737196712 SN.node[2].Communication.MAC reception du message avec dest 2et source 0

0.129737196712 SN.node[2].Communication.MAC Delivering [etat] to Network layer

0.129737196712 SN.node[2].Communication.Routing Received [etat] from MAC layer




0.129737196712 SN.node[3].Communication.Radio SET STATE to SLEEP, delay=5e-05, power=0.5







0.129787196712 SN.node[3].Communication.Radio completing transition to 2 (SLEEP)

4.5.2 Exemple d’un fichier Resume

Ce fichier donne un résumé sur les informations colléctées a lafin de l’éxéctution de la simulation. Par exemple, l’energie consom-mée, le nombre de paquets envoyés, reçus et même perdus de chaquenœud présent dans le réseau.


4.5.3 Paramètres de Simulations

Le dépoilement des capteurs est aléatoire dans un terrain carrédont sa dimension se varie selon le nombre de nœuds. La porté decommunication ainsi que la valeur initiale de l’énergie sont fixes pourtous les nœuds.

Les deux tableaux suivants donnent plus de détails :

Rayon de transmission 20 mEnèrgie Initiale 18720 Joules(corresond a 2 batterie AA)Antennes BidirectionnellesDurée de Simulation Varie selon le nombre de noeuds

Couche Application Bridge TestCouche Réseau WsnSurveyCouche Phy + MAC ByPassMacRadio CC1000

4.5.3.1 La Radio CC1000

Définis la Matrice De Transition. Cette dernière spécifie les délais(en ms)pour basculer entre les 3 états principales de Radio(Rx, Tx,Sleep )

RX TX SleepRX - 0,01 0,2TX 0,01 - 0,2Sleep 0,05 0,05 -


4.6 Résultats

Tout d’abord nous allons donnés une vue globale sur le compor-tement des nœuds au sein du réseau et de leurs organisation, ensuiteon détaillera les résultats obtenus graphiquement.

4.6.1 Organisation du Réseau

Suite au manque du simulateur Castalia qui se présente dans lapartie visuelle du comportement du réseau. Nous avons opté à tra-vailler plus sur les données colléctées dans les fichiers trace pourpouvoir illustré une idée sur l’organisation des capteurs au sein duréseau pour au moins valider les algorithmes utilisés.

Nous avons simulé un réseau composé de 50 nœuds, déployésaléatoirement. Suite à ça, Nous avons étudié en détails le fichier tracegénéré en 1er temps par les points suivants :

– Les positions de chaque nœuds ;– Les voisins découverent ;– Les rôles définis.

4.6.1.1 Les positions des nœuds

Le tableau suivant donne les positions des nœuds extraitent à par-tir du fichier trace généré.

Nœuds 0 1 2 3 4 5 6Positions 43.9,47.4 67.5,48.2 43.5,67.7 49.8,51.6 35.0,23.8 4.53,77.0 30.6,38.2

.

.

Nœuds 20 21 22 23 24 25 26Positions 21.1,14.9 58.9,36.4 45.4,10.8 25.9,49.4 48.9,17.7 30.9,75.4 54.5,35.9


.

.

Nœuds 43 44 45 46 47 48 49Positions 75.9,29.4 65.6,1.08 49.8,67.0 7.68,77.7 70.2,37.4 78.1,4.45 36.0,59.1

4.6.1.2 Le voisinage

Le tableau illustre les voisins de quelques nœuds essentiels telque :

- Nœuds Représentant : 22,47- Nœuds Liaison : 5, 43

Nœuds Voisins22 4,7,8,9,12,17,20,21,24,26,27,30,38,40,43,44,47,4847 1,2,3,7,11,13,14,15,18,21,24,26,27,29,37,41,43,4543 1,3,8,9,14,15,17,18,21,22,24,26,27,29,30,35,37,41,47,15 0,2,3,5,6,8,21,23,24,25,26,27,32,33,34,36,38,41,43,45,

FIG. 4.11 – Déployement Aléatoire.


FIG. 4.12 – Organisation des Nœuds.

D’aprés le shéma, on peux voir l’organisation des nœuds au seindu réseau aprés le Déployement et suite à la reconnaissance du voisi-nage par l’échange des messages Hello et HelloRep, ainsi avec l’éxé-cution de l’algorithme "AttribeRole" cité précedemment pour la struc-turation du réseau en systèmes Multi-Agents.

4.6.2 Redondance Des Nœuds

Une fois l’organisation du réseau se stabilise, l’algorithme de re-dondance commence son éxecution.Suite à ça, les nœuds redondant deviennent innactifs tout en gardantune couverture du réseau.Le shéma suivant est la succession des 2précédents, d’où on remarqueque les nœuds redondants sont devenus en mode Sleep.


FIG. 4.13 – Gestion De La Redondance.

4.6.3 Reconfiguration Du Réseau

Dans ce cas, nous avons provoqués une défaillance d’un nœudSimple pour voir la Reconfiguration du réseau.À un instant "T" nous avons mis un nœud en mode "Sleep" pour gé-nérer un arrêt de ce capteur par "l’épuisement d’énergie" par exemple.Suite à ça, on peux voir la reconfiguartion du réseau aprés la dispa-raition de ce nœud actif et le réveil d’un autre nœud Simple pour cou-vrir la zone qui étais couverte auparavant par ce capteur défaillant.

FIG. 4.14 – Reconfiguration suite à une défaillance.


4.6.4 Energie Consommée au niveau du réseau

Résultat d’énergie consomée selon La méthode de surveillance adop-tée par la distribution d’un nombre différents de nœuds pour unemême topologie ;

– surface de 100*100,– Energie de 5 mJoule,– Nombre des nœuds : 20, 50 jusqu’a 100.

FIG. 4.15 – Energie Consommée en Réseau.

On remarque que la consommation d’enèrgie se double jusqu’à letriple en augmentant le nombre de nœuds et c’est dûe principalementaux messages échangés pour la stabilité du réseau.Les messages de contrôle s’augmentent au profit d’augmentation descapteurs au réseau pour la bonne organisation du système.


4.6.5 Energie Consommée Avec et sans surveillance

D’aprés les histogrammes relevés pour les différents nombre denœuds dans un réseau, on peut conclure que l’énèrgie moyenne consom-mée suivant la méthode de Suveillence est basse par-rapport à la mé-thode sans surveillance et c’est dûe aux états inactifs que prend lesnœuds redondants.

Cas 1 : 20 noeuds

FIG. 4.16 – Energie Consommée au niveau des deux Méthodes

Cas 2 : 50 nœuds

FIG. 4.17 – Energie Moyenne Consommée par 50 nœuds


Cas 3 : 100 nœuds

FIG. 4.18 – Energie Moyenne Consommée par 100 nœuds

4.6.6 Energie restante d’un nœud Représentant

D’aprés l’organisation des nœuds, on peux déduire que le nœud"Représentant" consomme plus d’enèrgie que tous les autres nœuds,ce qui devient intéréssant d’étudier u plutôt de simuler l’état d’enèr-gie de ce nœud.

FIG. 4.19 – L’énergie restante au niveau d’un nœud Représentant


Ces Deux courbes démontre que l’énergie restante au niveau d’unnœud Représentant différe au niveau des deux méthode. et plus pré-cisémment dans la méthode en surveillance l’énergie dure plus quela méthode normale dûe a l’envoie des messages inter-clusters avecun rayon plus petit et un nombre de nœuds plus réduits.

4.6.7 Nombre de packets moyens des différents nœuds

Cette courbe présente une moyennes des packets envoyés et reçuspar différents nœuds selon leurs rôles où on résume que les nœudsreprésentant ont une moyenne plus élevés puisque ils responsablesur l’organisation du réseau.

FIG. 4.20 – Packets Moyens envoyés et reçus par nœuds.

4.6.8 Energie Consomée des différents nœuds

Les deux résultats donnent un aperçu sur la consommation d’éner-gie au niveau de quelque nœuds pour les 2 configuration pour unecomparaison d’où on peut conclure que la consommation d’energiedifférent et que dans le cas "Avec Surveillance" est beaucoup plus op-timale que le cas "Sans Surveillance".


FIG. 4.21 – Energie Consommée Avec Surveillance.

FIG. 4.22 – Energie Consommée Sans Surveillance.

4.6.9 Influence de la Mobilité des nœuds sur le Réseau

Nous avons effectués un autre cas de simulation concernant la mo-bilité des nœuds pour voir l’influence du déplacement a l’interieurdu réseau de quelques capteurs sur le réseau.

Notre test concerne la mobilité des nœuds 0,5 et 10. La mobilité sefait a l’instant 100 pour des distances différentes pour chaque nœudsavec une vitesse de déplacement de 15. Ainsi nous avons obtenus leRésultat suivant :


FIG. 4.23 – Influence de la Mobilité sur le Réseau.

À travers ce test, on remarque que la mobilité des nœuds à une trésgrande influence sur le réseau dans le cas du taux d’énergie, d’où onconstate que la consommation d’énergie dans un réseau avec mobi-lité est boucoup plus élevé que dans un réseau sans mobilité est c’estdûe principalement à cause de la reconfiguration du réseau et l’en-voi des messages pour la découverte du nouveau voisinage jusqu’ala stabilité du réseau.

FIG. 4.24 – Influence de la Mobilité sur le Réseau(Energie Moyenne).


4.6.10 Influence du Temps De Simulation

Le temps de simulation joue un rôle important sur le comporte-ment des capteurs, pour cela nous avons joués sur le temps de si-mulation pour évaluer la durée de fonctionnement du réseau par-rapport au taux d’energie.

FIG. 4.25 – Energie Restante par-rapport au temps de Simulation.

FIG. 4.26 – Energie Moyenne Restante.


4.7 Conclusion

Notre but, à travers les simulation éffectuées était de tester les per-formances de notre Approche "Surveillance d’un Réseau" d’où nousavons pû montrer l’avantage de la méthode distribuée pour assurerla Tolérance aux pannes avec le traitement de la redondance.

D’un autre côté, cette expérience nous a poussé à connaitre le nou-veau Simulateur OMNeT++ et sa plate forme Castalia et nous a per-mis d’intégré notre approche et d’enrichir le Simulateur avec de nou-veaux protocoles.

Suite aux Résultats obtenus, nous avons constater que la méthodesimulée est plus efficace en consommation enèrgitique au sein du ré-seau ce qui augmente la durée de vie du réseau.

Suite à tout ces avantages réalisés avec cette approche, les recherchesfutures sont plus favorisées vers l’approche distribuée avec l’aspectde la redondance au sein du réseau pour la gestion de la Surveillance.

Conclusion Générale

La consommation énergitique au niveaux des Réseaux de Cap-teurs est un point sensible, ce qui a motivé les chercheurs a se fo-caliser plus sur cette problématique pour pouvoir allonger la duréede vie des capteurs ainsi des Réseaux.De ce fait, plusieurs modèles pour différents types de topologies ontété proposés et traités par l’outil de simulation dans le but d’aquérirà une meilleurs configuration en consommation d’énergie.

Suite à ceci, nos idées se sont basés à la proposition d’une sur-veillance auto-configurable au niveau des nœuds capteurs. Nous avonssimulé un système d’organisation basé sur le principe des Agents"Nœuds Représentants", "Nœuds Laisions" et "Nœuds Simple". Cesderniers se ré-organise selon la distribution du réseau d’où nous avonsintroduit le concept de Surveillance par Redondances des nœuds etce afin d’améliorer la consommation enèrgitique au sein du réseaux.La théorie des graphes nous a permis de mettre en œuvre ce conceptde redondance dans le réseau.

Les résultats de Simulation assez satisfaisants suite à l’utilisationdu nouveau Simulateur OMNeT++ avec la plate forme "Castalia" quiest plus dédiée au Réseaux de Capteurs. Ce dernier se base sur leprincipe des modules. D’aprés nos différents tests éffectués, nousavons remarqué la diminution d’énergie consommé auprés des nœudsce qui donne une longévité du réseau.

Conclusion Générale 125

Tirant profit de l’approche Multi-Agents, Comme perspective denotre travail, nous envisageons d’étudier l’impact de l’utilisation ded’autres métriques de consommation d’énergie qui prennent en comptedes informations globales sur le réseau.

Bibliographie

[ABD09] Azadeh Abdolrazaghi, "Unifying Wireless Sensor NetworkSimulators", Master’s Degree Project Stockholm, Sweden,2009.

[ALL09] Samira Allam, "Approche multi-agents pour contrôler l’inon-dation dans un réseau de capteurs", Mémoire de fin d’étude pourl’obtention du diplôme d’ingénieur d’état en informatique, Ecolenational supérieur d’informatique(ESI), Oued-Smar Alger, 2009.

[ASS08] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci,"Wireless sensor networks : a survey", Computer Networks, Vol. 38,pp. 393-422, 2002.

B :

[BAB06] M. Badet, W. Bonneau. " Mise en place d’une plateforme de testet d’expérimentation", Projet de Master Technologie de l’Internet1ere année, Université Pau et des pays de l’Adour. 2006.

[BAI10] Nadia Bounegta ,Nacira Aici" Approche déscentralisé pour lasécurité d’un RCSF", Memoire de fin d’étude pour l’obtention d’unDiplome d’ingénieur en informatique,Université de BECHAR,Juin 2010.

[BEC09] Rachid Bechar, "Théorie de la redondance pour la reconfigura-tion des systèmes - Application aux réseaux de capteur sans fil", Mé-moire de magister Ecole doctorale STIC, Université AbdelhamidIbn Badis de Mostaganem. Département d’informatique, 2009.

BIBLIOGRAPHIE 127

[BEN09] Djawhara Benchaira, Ahlem Bencheikh, "Sécurité de la déssi-mination de données dans un réseau de capteur sans fil : cas du protocoleTiny Diffusion", 2009.

[BDH05] J. Bredin, E. Demaine, M. Taghi Hajiaghayi, and D. Rus,"Deploying Sensor Networks with Guaranteed Capacity and Fault To-lerance", in the Proceedings of the 6th ACM International Sym-posium on Mobile Ad Hoc Networking and Computing (Mobi-HOC’05), Urbana-Champaign, Illinois, 2005.

[BOU09] Athanassios Boulis. " Castalia : a simulator for Wireless Sen-sor Networks and Boby Area Networks User’s Manual version 2.1 ",NICTA, July 2009.

[BOU10] A. Boulis, "Castalia, a simulator for wireless sensor networksand body area networks, version 3.1", User’s manual, NICTA, De-cember 2010.

C :

[CAM99] Scott Carson, Joseph Macker, "Mobile ad hoc Networking(MANET) : Routing Protocol Performance Issues and EvaluationConsiderations", RFC 2051, 1999.

[CAS08] Claude Castelluccia, "La sécurité des capteurs et réseaux de cap-teur", INRIA, 2008.

[CET05] Bilge Cetin, "SIMULATION ENVIRONMENT", Novembre2005

[CHE08] Yacine Chellal, "Réseaux de capteurs sans fils", Systèmes in-télligents pour le transport, Version1 SIT60, 2008.

[CKU03] C-Y. Chong and S.P. Kumar, "Sensor networks : Evolution,opportunities, and challenges" Proceedings of the IEEE, Vol. 91, No.8, pp. 1247- 1256, 2003.

BIBLIOGRAPHIE 128

[CSS04] Akyildiz, W. Su, E. Cayirci, Y. Sankarasubramaniam. "A sur-vey on sensor networks", IEEE Communications Magazine, vol. 40,no. 8, pp. 102-114, Georgia Institute of Technology, Atlanta, USA.2004.

D :

[DOH06] N.Doufène, H.Hadjammar, Projet de fin d’étude pour l’ob-tention du diplôme d’ingénieur d’état : "Routage dans les réseauxde capteurs : Optimisation du protocole Directed Diffusion", InstitutNational de formation en Informatique (INI).2006.

[DSR03] Witold Drytkiewicz, Steffen Sroka, Vlado Handziski, An-dreas Köpke, Holger Karl, "A Mobility Framework for OMNeT++",Telecommunication Networks Group Technische Universität Ber-lin, 2003.

E :

[ELK] N.J El Karaki, A.E Kamel, "Routing technique in wireless sensornetwork : a survey", dept. of electrical and computer engineering,IoWA State University.

F :

[FAV08] Kevin Fall, Kannan Varadhan,"The ns Manual (formerly nsNotes and Documentation)", The VINT Project May 3, 2008

[FEL07] Rabah Fellouah, "Contribution au Diagnostic de Pannes pourles Systèmes Différentiellement Plats", THESE présentée en vue del’obtention du grade de Docteur de l’Université de Toulouse, dé-livré par l’INSA de Toulouse, 2007.

[FRA90] PM. Frank. "Fault diagnosis in dynamic systems using analyti-cal and knowledge-based redundancy - a survey and some new result".In Automatica, volume 26, pages 479-474, 1990.

G :

BIBLIOGRAPHIE 129

[GVA07] Carmen Guadalupe, Lopez Varela, "Détection et diagnosticpour les systèmes à événements discret-vers la prise en compte des er-reurs de modélisation", Thèse de doctorat à l’institut national dessciences appliquées de Toulouse, Laboratoire CNRS,2007. H :

[HAM07] A.Hamzi, Mémoire de magistère : "Plateforme basée agentspour l’aide à la conception et la simulation des réseaux de capteurs sansfil", Institut National de formation en Informatique (INI), 2007.

[HCB00] W. Heinzelman, A. Chandrakasan, H. Balakrishnan, "Energy-Efficient Communication Protocol for Wireless Micro sensorNetworks", In proc of the Hawaii International Conférence on Sys-tems Science, vol. 8, pp. 8020, January 2000.

[HER05] Uwe Herzog, "Ad hoc Networks :New Life For An OldConcept", www.eurescom.de, 2005.

[HOB08] Ghaleb Hoblos, "Diagnostic et surveillance des complexes",Spécialité : Automatique, Docteur de l’université des sciences ettechnologies de Lille ;Enseignant : Chercheur à L’ESIGELEC,2008.

[HOW03] Holger K., Willig A., " A short survey of wireless sensornetworks ", Technical university Berlin, Telecommunication Net-works Group, 2003.

[HWT05] K. Xu, H. Hassanein, G. Takahara and W. Wang, "Relaynode deployment strategies in heterogeneous wireless sensor networks :single-hop communication case", in the Proceedings of the IEEEGlobal Telecommunication Conference (Globecom’05), St. Louis,MO, 2005.

I,J :

[IDE04] " A Quick OverView of the OMNeT++4.0 IDE"

K :

BIBLIOGRAPHIE 130

[KEC07] Bouabdellah Kechar, "Problématique de la consommationd’énergie dans les réseaux de capteurs sans fils", LIUPA, Universitéd’oran, 2007.

[KEM04] Tatiana Kempowsky, "Surveillance de procédé à base de mé-thode de classification : Conception d’un outil d’aide pour la détection etle diagnostic des défaillances", Thèse préparée au laboratoire d’ana-lyse et d’architecture des systèmes du CNRS, En vue de l’obten-tion du titre de docteur de l’institut national des sciences appli-quées de Toulouse. 2004

[KHA06] B. Khalifa. " La sécurité dans les réseaux de capteurs sans fil",conférence à l’université de Bechar. 2006.

L :

[LEB] Tayeb Lemlouma, Abdelmadjid Boudina, "L’inteligence artifi-cielle distribuée et les systèmes multi-agent".

[LIL09] LIANG LI," Implementing Transport Protocol PSFQ in SensorNetwork in Castalia", School of Computer Science, 2009

[LWI07] Marc Löbbers, Daniel Willkomm, "A Mobility Framework forOMNeT++ User Manual Version 1.0a4", 2007.

M :

[MAK08] Abdallah Makhoul, "Réseaux de capteurs : localisation, cou-verture et fusion de données.",THÈSE pour obtenir le grade deDOCTEUR de l’Université de Franche-Comté Spécialité : Infor-matique préparée au Laboratoire d’Informatique de l’Univer-sité de Franche-Comté (LIFC) dans le cadre de l’École DoctoraleSciences Pour l’Ingénieur et Microtechniques (SPIM), 2008.

[MAT08] Pantélis Matsos,"Réseaux Sans Fil et de Mobiles RSFM", 2008.

BIBLIOGRAPHIE 131

[MAQ03] Didier Maquin "Surveillance des processus", Di-plôme d’Etudes Approfondies Contrôle, Signaux etCommunicationsVanduvre-les-Nancy, février2003.

[MER03] R.Meraihi, "Gestion de la qualité de service et contrôle de topo-logie dans les réseaux ad hoc", Thèse préstentée pour l’obtention legrade de docteur de l’Ecole nationale supérieure des télécommu-nications de paris, 2003.

[MOA08] Sofiane MOAD,Encadrant : Nizar Bouabdallah, "Laconsommation d’énergie dans les réseaux de capteurs sans fil" MasterRecherche 2 en Informatique IFSIC-Rennes1, 2008.

[MSK05] C. Mallanda, A. Suri, V. Kunchakarra, S.S. Iyengar*,R. Kan-nan* and A. Durresi "Simulating Wireless Sensor Networks withOMNeT++", S. Sastry The University of Akron, Akron, Ohio.

[MSP09] Abdallah Makhoul, Rachid Saadi, Congduc Pham, "Sur-veillance vidéo sur réseaux de capteurs sans-fils : ordonnancement adap-tatif avec prise en compte de la criticité", LIUPPA, Université de Pauet des Pays de l’Adour (UPPA).

N,O :

[OMN04] "OMNeT++, Discrete Event Simulation System Version 4.0",User Manual

[OMN10] " OMNeT++ Installation Guide Version 4.1",2010 P,Q :

[PUJ05] Pujolle G., " Les réseaux Editions 2005 ", éditions Eyrolles,2005.

R :

[RIP99] Patrick Ripoll, "Conception d’un système de diagnostic flou ap-pliqué au moteur automobile", pour obtenir le grade de Docteur deL’université de Savoie (Spécialité Electronique, Electrotechniqueet Automatique), 1999.

BIBLIOGRAPHIE 132

[ROM07] Yasser Romdhane, "Evaluation des performances des proto-coles SMAC et directed diffusion dans les réseaux de capteurs", Rap-port de fin d’étude, Ecole superieure de communication de Tunis,2007.

S :

[SAY09] Maya Sayad "Energy Efficient Protocol (EEP) : un protocole deroutage efficace en énergie pour réseaux de capteurs sans fil", Mémoirede fin d’études Pour l’obtention du diplôme d’ingénieur d’état eninformatique ; 2008/2009.

T,U,V :

[TBL08] Andreas TIMM-GIEL, Ken MURRAY, Markus BECKER,Ciaran LYNCH, Carmelita GÖRG, Dirk PESCH, "Comparative Si-mulations of WSN", ICT-MobileSummit 2008.

W,X :

[XPM91] Ding X., Frank P.M., "Frequency domain approach and thre-shold selector for robust model-base fault detection and isolation", Proc.of IFAC Symp. SAFEPROCESS 91, Baden Baden, Germany, vol. 1,pp.307-312, 1991.Y,Z :

[YAK] Mohamed Younis, Kemal Akkaya,"Strategies and Techniques forNode Placement in Wireless Sensor Networks : A Survey". ArticleDept. of Computer Sc. et Elec. Eng.

[YCC05] T. A. Yang Chair,L. Shih,G. C. Collins, "Applying Image Pro-cessing Techniques To Simulate a Self-organized Sensor Network ForTracking Objects", Master Thesis Defense, Computer Engineering2005.

BIBLIOGRAPHIE 133

Webographie

[1] http ://www.commentcamarche.net, site de documentation in-formatique, Septembre 2005.

[2] http ://www.francetelecom.com/rd, site de la division R et D deFrancetelecom, Septembre 2005.

[3] http ://www.epfl.ch, site de l’école polytechnique fédérale deLausanne, Septembre 2005.

[4] http ://compilers.cs.ucla.edu/avrora, site d’informations sur lesimulateur Avrora, Novembre 2005.

[5] http ://www.isi.edu/nsnam/ns/

Résumé

Les Réseaux de capteurs sans fil attirent plus l’attention de la communauté derecherches. Ainsi la simulation est une démarche fréquemment utilisée pour tester etvalider des approches, les environnements de simulation doivent pouvoir soutenir lesdifférents modèles des réseaux de capteurs sans fil.

Notre Thèse s’intéresse plus précisément au cas de surveillance des réseaux decapteurs. Le protocole testé est un protocole basé sur la reconfiguration des nœuds avecle principe de redondance pour garder une couverture de la zone et assurer une longuevie du réseau.

La validation de l’approche est considéré suite à l’utilisation du simulateurOMNeT++ puisque les résultats obtenus ont montré que le concept de l’approche auniveau de la tolérance aux pannes (avec le principe de réveiller les nœuds endormi encas de panne ou d’épuisement d’énergie d’un nœud actif) assure un bon fonctionnementainsi une longévité du réseau.

Mots Clés

Réseau de capteurs sans fil; Surveillance; Redondance; Reconfiguration; Simulation;OMNET++; Castalia; Routage; Couche Réseau; Voisinage.

simulateur : omnet++theses.univ-oran1.dz/document/th3828.pdf · remerciement mes remerciements...

Documents