Simulateur : OMNET++ - Thèses et Mémoires

Transcription

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 un
ré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
Mr. Bouabdellah KECHAR
Mr. Mejdi KADDOUR
Mr. Mohammed FEHAM
Mr. Hafid HAFFAF
Président
Examinateur
Examinateur
Examinateur
Encadreur
Remerciement
Mes remerciements s’adressent à mon encadreur H.HAFFAF , pour
son aide, ses encouragements, et ses critiques constructifs qui m’ont
beaucoup aidé à apprécier ce travail et à mieux éclairer mes perspectives. Je suis reconnaissante à lui, particulièrement pour la confiance
qu’il m’a fait.
Je tiens à remercier les membres du jury pour m’avoir fait le plaisir
d’accepter d’examiner ce travail.
Je tiens à remercier également ma famille et mes amis(es), ce travail n’aurait certainement jamais vu le jour sans leurs aides, et leurs
soutiens, 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
1.1 Les Réseaux sans fil . . . . . . . . . . . . . . . . . . . . .
1.1.1
2
4
Le réseau personnel sans fil . . . . . . . . . . . .
4
1.2
1.1.2 Le réseau local sans fil (WLAN) . . . . . . . . .
1.1.3 Le réseau métropolitain sans fil (WMAN) . . .
1.1.4 Le réseau étendu sans fil (WWAN) . . . . . . . .
Les réseaux Ad Hoc . . . . . . . . . . . . . . . . . . . .
5
6
6
7
1.3
1.2.1 Caractéristiques des réseaux Ad Hoc . . . . . .
Les réseaux de capteurs sans fil (RCSF) . . . . . . . . .
7
7
1.3.1
1.3.2
Architecture d’un nœud capteur . . . . . . . . .
Organisation d’un nœud capteur . . . . . . . . .
8
9
1.3.3
1.3.4
1.3.5
Architecture d’un réseau de capteurs
Les types d’architectures des RCSF . .
Les differentes topologies des RCSF :
1.3.5.1 La Topologie en étoile : . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
13
14
14
1.3.5.2 La topologie en grille :
1.3.5.3 La topologie hybride : .
La collection d’information : . .
1.3.6.1 À la demande : . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
15
15
15
1.3.6
1.3.6.2
.
.
.
.
.
.
.
.
.
.
.
.
Suite à un évènement : . . . . . . . . . 15
TABLE DES MATIÈRES
iv
1.3.7
Les principales caractéristiques des RCSF
1.3.8
1.3.9
Les domaines d’application . . . . . . . . . . . . 18
La consommation d’énergie dans les RCSF . . . 19
1.3.9.1 Les principaux opérations dûes à la
consommation d’énergie . . . . . . . . 19
1.3.9.2
. . . 17
Modèle de consommation d’énergie . . 21
1.3.9.3
Les facteurs intervenants dans la consommation d’énergie . . . . . . . . . . . . . 22
1.3.10 Le routage dans les RCSF . . . . . . . . . . . . . 24
1.4
2
1.3.10.1 Exemples de protocoles de routage . . 24
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28
La surveillance des Réseaux de Capteurs Sans Fil
2.1
La supervision des RCSF
2.1.1
2.1.2
2.1.3
2.3
2.4
. . . . . . . . . . . . . . . . . 33
Les Pannes . . . . . . . . . . . . . . . . . . . . . 33
2.1.1.1 Classification des pannes . . . . . . . . 33
Solution architecturale tolérante aux pannes dans
les RCSF . . . . . . . . . . . . . . . . . . . . . . . 35
Aspect de surveillance d’un RCSF . . . . . . . . 37
2.1.3.1 Méthodologie de déploiement : . . . . 37
2.1.3.2 Connectivité du réseau . . . . . . . . . 38
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
40
2.1.4.2
La redondance analytique . . . . .
Systèmes Multi-agents . . . . . . . . . . . . . . . . .
2.2.1 Caractéristiques des Systèmes Multi-Agents
Les Travaux Antérieurs . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
42
43
43
44
2.1.4
2.2
31
2.1.3.3 La couverture . . . . . . .
2.1.3.4 Longévité du réseau . . .
La redondance . . . . . . . . . . . .
2.1.4.1
La redondance Matérielle
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
2.5
Définition des rôles . . . . . . . . . . . . . . . . 47
2.4.2.1 Algorithme d’attribution de rôle . . . . 49
Le protocole de routage adopté . . . . . . . . . . . . . . 50
2.5.1
Les Diagrammes UML . . . . . . . . . . . . . . . 51
2.5.2
2.5.3
2.5.4
2.5.1.1 La détection du voisinage . . .
Changement de rôles : . . . . . . . . . . .
Détection des groupes voisins . . . . . .
Vérification de la cohérence des groupes :
2.5.5
2.5.6
2.6
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Résolution de conflits entre représentants . . . 55
Gestion de la redondance . . . . . . . . . . . . . 56
2.5.6.1 Le principe suivi pour gérer la redondance : . . . . . . . . . . . . . . . . . . . 57
2.5.6.2 Mécanisme de détection des pannes . 58
2.5.7 Collecte d’information . . . . . . . . . . . . . . . 59
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Simulation de la surveillance en RCSF
3.1 Généralités sur la simulation . . . . . . . . . . . . . . .
3.2 Types de simulation . . . . . . . . . . . . . . . . . . . . .
3.2.1 Systèmes de simulation discret : . . . . . . . . .
3.3
3.4
3.5
52
53
54
54
3.2.2 Systèmes de simulation continue :
Les simulateurs de réseau éxistant . . . .
3.3.1 NS2 : . . . . . . . . . . . . . . . . .
3.3.2 GloMoSim . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
64
64
64
65
65
65
66
3.3.3 OMNET++ . . . . . . . . . . . . . . . . . . . . . 68
Comparaison entre les simulateurs . . . . . . . . . . . . 68
Le Simulateur OMNET++(Objective Modular Network
Testbed in C++) . . . . . . . . . . . . . . . . . . . . . . . 70
3.5.1
3.5.2
3.5.3
Choix du simulateur OMNET++ . . . . . . . . . 70
Présentation d’OMNET++ . . . . . . . . . . . . 70
Desciption architecturale d’OMNET++ . . . . . 71
TABLE DES MATIÈRES
3.5.4
3.5.5
Installation du simulateur OMNET++ . . . . . . 72
Les principaux fichiers d’OMNET++ . . . . . . 73
3.5.5.1 Fichier (.Ned) : . . . . . . . . . . . . . . 73
3.5.5.2
3.6
3.7
Fichier (.ini) : . . . . . . . . . . . . . . . 75
3.5.5.3 Fichier (.msg) : . . . . . . . . . .
Les plates formes d’OMNET++ . . . . . . . . . .
3.6.1 Mobility FrameWork . . . . . . . . . . . .
3.6.1.1 La structure d’une hôte mobile .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
76
76
77
3.6.2 Mixim . . . . . .
3.6.3 Castalia . . . . .
Détails sur Castalia . . .
3.7.1 Le module MAC
3.7.2
3.7.3
3.7.4
3.7.5
3.8
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
78
80
81
Le module Radio . . . .
Canal sans fil . . . . . .
Le module Routage . . .
Le module Application
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
82
82
82
Outils de Simulation . . . . . . . . . . . . . . . . . . . . 83
3.8.1
3.8.2
Installation d’OMNET++ Version 4 . . . . . . . . 83
Installation de Castalia3.1 . . . . . . . . . . . . . 84
3.8.2.1 Les Commandes Castalia . . . . . . . . 84
3.9 Implémentation d’un réseau . . . . . . . . . . . . . . . . 84
3.10 Conculsion . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4
Implémentation et Simulation
4.1
4.2
4.3
Environnement de travail . . . . . . .
4.1.1 Environnement matériel . . .
4.1.2 Environnement logiciel . . . .
Processus de simulation . . . . . . . .
88
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
90
90
90
90
Réalisation du projet . . . . . . . . . . . . . . . . . . . . 91
4.3.1 Objectif . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3.2 Description de la conception d’un nœud . . . . 91
TABLE DES MATIÈRES
4.4
4.3.3 Description du réseau . . . . . . . . . . . . . . . 94
Implémentation . . . . . . . . . . . . . . . . . . . . . . . 96
4.4.1 Structure des messages utilisés . . . . . . . . . . 96
4.4.1.1
4.4.2
Au niveau de la couche Application . . 96
4.4.1.2 Au niveau de la couche Réseau . . . . 96
Aperçu des Codes Sources . . . . . . . . . . . . 98
4.4.2.1 Envoi Periodique du Message HELLO
98
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
100
102
102
Résultats Obtenus . . . . . . . . . . . . . . .
4.5.1 Deployement du Réseau . . . . . . . .
4.5.1.1 Initialisation des nœuds . .
4.5.1.2 Reconnaissance de voisinage
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
104
104
105
106
4.4.3
4.5
vii
4.4.2.2 Attribution Des Rôles . .
4.4.2.3 Gestion de la redondance
4.4.2.4 Rediffusion du Hello . .
Le fichier .ini . . . . . . . . . . . .
.
.
.
.
4.5.1.3
4.5.2
4.5.3
4.6
Table de voisinage et Affectation des
rôles . . . . . . . . . . . . . . . . . . . . 108
4.5.1.4 Passage en Etat Sleep . . . . . . . . . . 109
Exemple d’un fichier Resume . . . . . . . . . . . 109
Paramètres de Simulations . . . . . . . . . . . . 111
4.5.3.1 La Radio CC1000 . . . . . . . . . . . . . 111
Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.6.1 Organisation du Réseau . . . . . . . . . . . . . . 112
4.6.2
4.6.3
4.6.1.1 Les positions des nœuds
4.6.1.2 Le voisinage . . . . . . .
Redondance Des Nœuds . . . . . .
Reconfiguration Du Réseau . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
113
114
115
4.6.4
4.6.5
4.6.6
Energie Consommée au niveau du réseau . . . . 116
Energie Consommée Avec et sans surveillance . 117
Energie restante d’un nœud Représentant . . . . 118
TABLE DES MATIÈRES
4.6.7
4.6.8
4.6.9
viii
Nombre de packets moyens des différents nœuds119
Energie Consomée des différents nœuds . . . . 119
Influence de la Mobilité des nœuds sur le Réseau 120
4.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
1.2
Les catégories des réseaux sans fil. [MAT08] . . . . . .
le nœud capteur [CAS08]. . . . . . . . . . . . . . . . . .
4
8
1.3
les composants d’un nœud capteur [MOA08].
8
1.4
1.5
1.6
1.7
La pile protoclaire [CSS04]. . . . . . . . . . . . . . .
Architecture de commnication d’un RCSF [KEC07].
Architecture Plat des RCSF[ROM07]. . . . . . . . .
Architecture hierarchique des RCSF[ROM07]. . . .
.
.
.
.
.
.
.
.
10
12
13
14
1.8
1.9
1.10
1.11
Collecte à la demande . . . . . . . . . . . . . . . . . .
Collecte suite à un événement . . . . . . . . . . . . . .
Les différentes applications des RCSF [CHE08]. . . .
Modéle de consommation d’énergie . . . . . . . . . .
.
.
.
.
16
16
20
21
. . . . .
1.12 La surécoute [MOA08]. . . . . . . . . . . . . . . . . . . 23
1.13 Classification des protocoles de routage[BEN09]. . . . 25
1.14 Les étapes du protocole SPIN[CHE08]. . . . . . . . . . 26
1.15 Etapes décrivantes le protocole DirectedDiffusion [CHE08].
28
2.1
Classification des pannes [CHE08]. . . . . . . . . . . . . 34
2.2
2.3
2.4
Stratégies de déploiement des noeuds dans un RCSF[YAK].
38
La redondance matérielle[RIP99]. . . . . . . . . . . . . 41
Organisation en régions des nœuds capteurs [ALL09].
48
2.5
2.6
Affectation des rôles dans un RCSF. . . . . . . . . . . . 50
Diagramme Etat Transition. . . . . . . . . . . . . . . . . 51
TABLE DES FIGURES
2.7
2.8
2.9
xi
Diagramme De Séquence. . . . . . . . . . . . . . . . . . 52
Introduction d’un nouveau nœud. . . . . . . . . . . . . 53
Détection des groupes adjacents. . . . . . . . . . . . . . 54
2.10 Correction du problème d’incohérence. . . . . . . . . . 55
2.11 Résolution de conflit entre Représentants. . . . . . . . . 56
2.12 Redondance des nœuds simples. . . . . . . . . . . . . . 57
2.13 Changement d’état d’un nœud. . . . . . . . . . . . . . . 58
3.1
3.2
Description architecturale du simulateur NS2. . . . . . 66
Transfert des paquets dans GloMoSim. . . . . . . . . . . 67
3.3
Le lancement du simulateur Omnet++. . . . . . . . . . . 71
3.4
3.5
3.6
Architecture modulaire du simulateur Omnet++. . . . . 72
Fichier NED en mode graphique. . . . . . . . . . . . . . 74
Fichier NED en mode texte. . . . . . . . . . . . . . . . . 74
3.7
3.8
3.9
Exemple d’un Fichier *.Ini. . . . . . . . . . . . . . . . . 75
Exécution d’une simulation sous OMNeT++.[?] . . . . . 76
Architecture de Mobility et Channel Control. . . . . . . 77
3.10 Architecture interne d’un nœud dans MF. . . . . . . . . 78
3.11 Les connections des modules sous Castalia. . . . . . . . 79
3.12 Les principaux composants d’un nœud . . . . . . . . . . 80
3.13 La machine à état fini du module Radio. . . . . . . . . . 81
4.1
4.2
4.3
Processus de Simulation. . . . . . . . . . . . . . . . . . . 91
Fichier graphique ".ned" du nœud. . . . . . . . . . . . . 93
Fichier graphique ".ned" du réseau. . . . . . . . . . . . . 95
4.4
4.5
4.6
Fichier ".msg" du message Data. . . . . . . . . . . . . . 96
Le structure du message Hello et HelloRep. . . . . . . . 97
Le structure du message "Passe Représentant" et "Résolution de conflit". . . . . . . . . . . . . . . . . . . . . . 97
4.7
Le structure du message Verification de cohérence et
Changement de rôle. . . . . . . . . . . . . . . . . . . . . 98
Organigramme de redondance des nœuds simples. . . 101
4.8
TABLE DES FIGURES
xii
4.9 Deployement des nœuds. . . . . . . . . . . . . . . . . . 104
4.10 Exécution avec le Deployement . . . . . . . . . . . . . . 105
4.11 Déployement Aléatoire. . . . . . . . . . . . . . . . . . . 113
4.12 Organisation des Nœuds. . . . . . . . . . . . . . . . . . 114
4.13
4.14
4.15
4.16
Gestion De La Redondance. . . . . . . . . . . . . . .
Reconfiguration suite à une défaillance. . . . . . . .
Energie Consommée en Réseau. . . . . . . . . . . . .
Energie Consommée au niveau des deux Méthodes
.
.
.
.
.
.
.
.
115
115
116
117
4.17
4.18
4.19
4.20
Energie Moyenne Consommée par 50 nœuds . . . . .
Energie Moyenne Consommée par 100 nœuds . . . .
L’énergie restante au niveau d’un nœud Représentant
Packets Moyens envoyés et reçus par nœuds. . . . . .
.
.
.
.
117
118
118
119
4.21
4.22
4.23
4.24
Energie Consommée Avec Surveillance. . . . . . . . . . 120
Energie Consommée Sans Surveillance. . . . . . . . . . 120
Influence de la Mobilité sur le Réseau. . . . . . . . . . . 121
Influence de la Mobilité sur le Réseau(Energie Moyenne).121
4.25 Energie Restante par-rapport au temps de Simulation. . 122
4.26 Energie Moyenne Restante. . . . . . . . . . . . . . . . . 122
Résumé :
Les réseaux de capteurs sans fil attirent plus l’attention de la communauté de recherches. Ainsi la simulation est une démarche fréquemment utilisée pour tester et valider des approches, les environnements de simulation doivent pouvoir soutenir les différents modèles des réseaux de capteurs sans fil. Notre article s’intéresse plus
précisément au cas de surveillance des réseaux de capteurs. Le protocole testé est un protocole basé sur la reconfiguration des noeuds avec
le principe de redondance pour garder une couverture de la zone et
assurer une longue vie du réseau. La validation de l’approche est
considéré suite à l’utilisation du simulateur OMNeT++ puisque les
résultats obtenus ont montré que le concept de l’approche au niveau
de la tolérance aux pannes (avec le principe de réveiller les noeuds
endormi en cas de panne ou d’épuisement d’énergie d’un noeud actif) assure un bon fonctionnement ainsi une longévité du réseau.
Mots Clés : Réseau de capteurs sans fil, Surveillance, Redondance, Reconfiguration, Simulation, OMNET++, Castalia
L’avancement des technologies dans les infrastructures de réseau
et de minuscules capteurs du réseau permet à de nombreuses applications de réseau de capteurs allant de civils aux militaires, de la
maison à l’environnement et de la nature de l’industriel au domaine
commercial de s’accroitre, car de nos jours le besoin d’observer des
phénomènes physiques tel que la température, la pression ou encore
la luminosité est devenu essentiel. Exemples sont la surveillance de
l’habitat des animaux, observation de l’environnement et de prévision, le corp humain le suivi, le champ de bataille de détection et
d’analyse, etc
Cependant, La taille réduite des capteurs nécessite l’utilisation d’une
batterie comme source d’énergie ce qui implique une durée limité du
réseau. Suite à ça la collaboration d’un nombre de ces nœuds, donne
naissance à un réseau de capteurs sans fil. Ce dernier est déployé de
manière aléatoire dans un champ.
Les capteurs sont prévus pour la collecte d’information selon des
critères bien précis. Ainsi la consommation d’energie est devenue un
axe majeur dans les recherches d’où plusieurs protocoles de routage
ont été proposés dans le but d’optimiser la consommation énergitique et de prolonger la durée de vie du réseau.
xv
Un protocole de routage permet l’acheminement des informations
au sein du réseau avec l’envoie des messages entre nœuds capteurs
pour la collecte du phénomène. Ce qui s’avère couteux en energie qui
engendre l’épuisement des batterie, encore plus la perte des données
et la diminution de vie du réseau.
Dans ce contexte, la fonction de surveillance en continue est une
méthode basée sur la détection et la localisation des anomalies qui
peuvent survenir dans le réseau.
Suite à ca, une des solutions qui s’annonce prometteuse est l’utilisation 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 simulation OMNeT++, un modèle de surveillance du réseau. Ce modèle
est basé sur la gestion distribuée avec le concept de redondance.
Comme conséquences de cette surveillance : La diminution des messages communiqués, L’hiérarchie du réseau, La réduction d’énergie
consommé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ù nous
avons présenté les principaux concepts de surveillance et plus
précisémment au niveau des réseaux de capteurs sans fils. Les
travaux dans ce domaine sont cités en références.
– Chapitre 3 : Présente l’apprort de la simulation pour la validation des résultats. Un comparatif entre les différents simulateurs
enrichira le contenu du chapitre. Notre choix qui sera justifiés
est pointé sur OMNeT++ et Castalia.
xvi
– Chapitre 4 : Constitue le cœur de cette contribution en proposant un modèle de surveillance du réseau ainsi que son implémentation. Les résultats de simulation seront également présentés pour justifier la validité de notre approche.
1
Chapitre 1
Présentation des Réseaux de capteurs
sans fil
Au cours de son évolution, le paradigme sans fil a vu naître diverses 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 telles
que la surveillance des forêts, la gestion des catastrophes, l’exploration 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 environnements
sans surveillance. En plus de la capacité d’explorer son environnement, chaque capteur possède une radio à bord utilisée pour l’envoi
des données recueillies à une station de base, soit directement, soit à
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éploiements, ces capteurs doivent être très solides et de plus, ils doivent
aussi pouvoir survivre dans les conditions les plus extrêmes dictées
par leur environnement d’utilisation (feu ou eau par exemple). En
plus des contraintes environnementales, une contrainte très importante est l’économie de batterie. En effet, un réseau de capteurs ne
peut survivre si la perte de nœuds est trop importante car ceci engendre des pertes de communication dûes à une grande distance
entre les capteurs. Donc il est très important que les batteries durent
le plus longtemps possible étant donné que dans la plupart des applications les capteurs sont placés aléatoirement.
1.1
4
Les Réseaux sans fil
Il existe plusieurs catégories de réseaux sans fil qui diffèrent par le
périmètre géographique qu’ils couvrent ainsi que par les types d’applications supportées. Le schéma suivant illustre les catégories des
réseaux sans fil.
F IG . 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 de
quelques dizaines de mètres. Ce type de réseau sert généralement à
relier des périphériques (imprimante, téléphone portable, appareils
domestiques, PDA...). Il existe plusieurs technologies utilisées pour
les WPAN tel que :
1. La technologie Bluetooth : Est connue aussi sous le nom de la
norme IEEE 802.15.1, elle a été lancée par Ericsson en 1994, proposant un débit théorique de 1 Mbps lui permettant une transmission de la voix, des données et des images [2], d’une portée
5
maximale d’une trentaine de mètres[1].
Bluetooth est une technologie peu onéreuse, grâce à sa forte inté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 norme
IEEE 802.15.4, permet d’obtenir des liaisons sans fil à bas prix
avec une très faible consommation d’énergie, ce qui la rend particulièrement adaptée pour être directement intégrée dans de
petits appareils électroniques (capteurs, appareils électroménagers...) [1].
Les réseaux ZigBee permettent d’offrir des débits jusqu’à 250
Kbits/s dans la bande classique des 2,4GHz. Les RCSF constituent une des applications que cette norme peut couvrir [1].
3. Les liaisons infrarouges : Permettent de créer des liaisons sans fil
de quelques mètres avec des débits pouvant monter à quelques
mégabits par seconde. Cette technologie est largement utilisée
dans la domotique (télécommandes), et souffre toutefois des perturbations 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 une
centaine de mètres. Il permet de relier les terminaux entre-eux présents dans la zone de couverture. Il existe deux technologies concurrentes :
1. Les réseaux Wi-Fi (Wireless-Fidelity) : Proviennent de la norme
IEEE 802.11, qui définit une architecture cellulaire. On y trouve
principalement deux types de réseaux sans fil : Ceux qui travaillent à la vitesse de 11 Mbits/s à 2.4 GHz (IEEE 802.11b) et
ceux qui montent à 54 Mbits/s à 5 GHz (IEEE 802.11 a/g).
6
2. Les réseaux HiperLAN 2 (High Performance LAN 2.0) : Découlent
de la norme européenne élaborée par l’ETSI (European Telecommunications Standards Institute). HiperLAN 2 permet d’obtenir
un débit théorique de 54 Mbps sur une zone d’une centaine de
mètres dans la gamme de fréquence comprise entre 5 150 et 5 300
MHz [1]. Ce type de réseau n’a pas reçu autant de succès que la
technologie Wi-fi.
1.1.3
Le réseau métropolitain sans fil (WMAN)
Connu aussi sous le nom de Boucle Locale Radio (BLR). Il convient
de rappeler que la BLR permet, en plaçant une antenne parabolique
sur le toit d’un bâtiment, de transmettre par voie hertézienne de la
voix et des données à haut débit pour l’accès à l’internet et la téléphonie. Il existe plusieurs types de réseaux WMAN dont le plus connu
est :
Le réseau Wimax (Worldwide interoperability for Microwave Access) :
Ils émanent de la norme IEEE 802.16 et ont pour but de développer des liaisons hertéziennes concurrentes aux techniques xDSL terrestres et offrent un débit utile de 1 à 10 Mbit/s dans la bande 10-66
GHz pour une portée de 4 à 10 kilomètres, ce qui destine principalement 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 plus
ré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 (General
Packet Radio Service), UMTS (Universal Mobile Telecommunication
System).
1.2
7
Les réseaux Ad Hoc
Un réseau ad hoc, ou MANET (Mobile Ad hoc NETwork), est un
réseau formé dynamiquement par un ensemble arbitraire de nœuds
indépendants. Aucune préinstallation relative au rôle que devrait
jouer chaque nœud n’est requise.
Dans un réseau ad hoc, les nœuds sont supposés se comportés comme
des routeurs et des clients à la fois, aussi, chaque nœud est libre de
se 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 liaisons
sans fil auront toujours des performances inférieures à leurs homologues câblés [CAM99] .
– Equivalence des nœuds : Dans les réseaux Ad Hoc il n’existe pas
de différence entre nœuds tel que les autres réseaux(hôte et station)car tous nœuds peuvent être amenés à assurer des fonctions
de routage.
1.3
Les réseaux de capteurs sans fil (RCSF)
Les réseaux de capteurs sont considérés comme un type spécial
des réseaux Ad hoc. En conséquence, ils héritent des caractéristiques
de ces réseaux, y compris l’architecture sans infrastructure établie et
la communication sans fil. Les RCSF forment une nouvelle génération de réseaux aux propriétés spécifiques, Ils présentent un champ
8
d’application très vaste et couvrent plusieurs domaines à caractère
scientifique, logistique, militaire ou de santé.
Un RCSF est composé de plusieurs centaines et parfois des milliers de nœuds capteurs, chaque nœud est capable de surveiller son
environnement et de réagir en cas de besoin en envoyant l’information collectée à un ou plusieurs points de collecte, à l’aide d’une
connexion sans fil [BAB06].
F IG . 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, qui
sont présentées dans la figure ci-dessous[CSS04][KHA06].
F IG . 1.3 – les composants d’un nœud capteur [MOA08].
a. Unité de capture (Sensing unit) : Elle est composée de deux sous
unités, un dispositif de capture physique qui prélève l’informa-
9
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 sont
communiquées au processeur où elles sont stockées dans la mémoire.
c. Unité de communication (Transceiver unit) : Elle est composée
d’un émetteur/récepteur (module radio) permettant la communication entre les différents nœuds du réseau.
d. Unité d’énergie (Power unit) : C’est la batterie qui, n’est généralement ni rechargeable ni remplaçable. La capacité d’énergie limitée au niveau des capteurs représente la contrainte principale
lors de la conception de protocoles pour les réseaux de capteurs.
Les unités d’énergie peuvent être supportées par des photopiles
qui permettent de convertir l’énergie lumineuse en courant électrique.
1.3.2
Organisation d’un nœud capteur
les réseaux de capteurs utilisent une pile protocolaire de communication composée de cinq couches : une couche application, une
couche transport, une couche réseau, une couche liaison de données
et une couche physique. Cette pile est également caractérisée par trois
niveaux qui intègrent dans les protocoles des différentes couches la
prise 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œuds
du 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 du
signal, la modulation/ démodulation et le cryptage/décryptage
des informations. Il est avantageux en matière d’économie d’éner-
10
F IG . 1.4 – La pile protoclaire [CSS04].
gie que le concepteur de la couche physique choisit une transmission à 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 est
principalement 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 traditionnels
deviennent inadéquats. Pour cela, la communication multi-sauts
est la mieux adaptée. Cette couche prend en charge la décou-
11
verte du voisinage, l’allocation des ressources et le routage.
d. La couche transport : Dans les réseaux de capteurs, la couche
transport est essentiellement présente pour constituer une interface entre la couche application et la couche réseau [HAM07].
Ses principaux objectifs sont :
– Multiplexer et démultiplexer les messages entre les applications 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 va
accéder à partir de notre RCSF vers un autre RCSF ou vers Internet.
e. La couche application : La couche application constitue l’ensemble 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 différentes interfaces, et éventuellement, par l’intermédiaire d’un
réseau étendu (par exemple : Internet).
Cette couche est responsable par exemple sur la collecte, le codage, l’agrégation et la compression des données collectées.
12
En plus les 3 niveaux(plans) :
a. Le niveau de gestion d’énergie : Chargé de contrôler la manière
dont un nœud utilise son énergie.
b. Le niveau de gestion des tâches : Assure l’équilibrage de la distribution des tâches sur les différents nœuds pour accomplir un
travail coopératif.
c. Le niveau de gestion de la mobilité : Détecte et enregistre tout
les 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 zone
de capture. Chacun de ces nœuds à la possibilité de collecter les données et de les router vers une ou plusieurs stations de base (sink
node). Ce dernier est un point de collecte de données capturées. Il
peut communiquer les données collectées à l’utilisateur final à travers un réseau de communication, éventuellement l’Internet[MOA08].
F IG . 1.5 – Architecture de commnication d’un RCSF [KEC07].
Comme le montre la (Figure 1.5), un RCSF est composé d’un grand
nombre de nœuds capteurs éparpillés sur le champ de captage [ELK].
13
A un niveau plus élevé un RCSF peut être vu comme étant une
combinaison de deux entités de réseaux :
– Le réseau d’acquisition de données : C’est l’union des nœuds
capteurs 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 connecter 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 sans
fil plat est un réseau homogène, où tous les nœuds disposent
des même capacités dans la communication, captage d’informations... Et un sink différent puisque il joue le rôle de passerelle
chargée à transmettre les informations colléctées à l’utilisateur.
F IG . 1.6 – Architecture Plat des RCSF[ROM07].
2. Les réseaux de capteurs sans fil hiérarchique : C’est un réseau
hétérogène où les nœuds peuvent disposés d’une source énèrgitique, d’une portée de communication ou d’une puissance de
calcul différente les uns des autres.
14
F IG . 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 recevoir
un message à un certains nombre de nœuds. Ces nœuds peuvent
seulement envoyer ou recevoir un message de l’unique station de
base, il ne leur est pas permis de s’échanger des messages.
L’avantage de cette topologie est sa simplicité, sa capacité à minimiser la consommation d’énergie des nœuds et la minimisation de latence de la communication entre les nœuds et la station de base. Son
inconvénient est que la station de base n’est pas robuste puisque tout
le 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 de
transmission. Ceci est appelé la communication multi-sauts, dans laquelle, si un nœud veut transmettre un message à un autre nœud qui
est en dehors de sa portée de transmission, il utilise un nœud intermédiaire pour envoyer son message au nœud destinataire. L’avan-
15
tage de cette topologie est la possibilité du passage à l’échelle, la redondance et la tolérance aux fautes, L’inconvénient de cette topologie
est la consommation d’énergie dans la communication multi-sauts et
la latence qui sont créés par le passage des messages entre nœuds
avant d’arriver à la station de base.
1.3.5.3
La topologie hybride :
Une topologie hybride entre celle en étoile et en grille fournit des
communications réseau robustes et diverses, en assurant la minimisation de la consommation d’énergie dans les réseaux de capteurs.
Dans ce type de topologie, les nœuds capteur à faible puissance ne
routent pas les messages, mais il y a d’autres nœuds qui ont la possibilité de faire le routage des messages. En général, ces nœuds ont
une puissance élevée.
1.3.6
La collection d’information :
Il existe deux méthodes pour collecter les informations d’un réseau
de capteurs :
1.3.6.1
À la demande :
Lorsque l’on souhaite avoir l’état de la zone de couverture à un
moment T, le puit émet des brodcasts vers toute la zone pour que les
capteurs remontent leur dernier relevé vers le puit. Les informations
sont 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-
16
F IG . 1.8 – Collecte à la demande .
tués à proximité remontent alors les informations relevées et les acheminent jusqu’au puit.
F IG . 1.9 – Collecte suite à un événement .
1.3.7
17
Les principales caractéristiques des RCSF
– La consommation réduite d’énergie : Chaque nœud dispose d’une
batterie 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, les
nœ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’une
part, pour s’auto-configurer dans le réseau, et d’autre part pour
collaborer avec les autres nœuds dans le but de reconfigurer dynamiquement le réseau en cas de changement de topologie du
réseau [HOW03].
– La scalabilité : Un réseau de capteur est scalable parce qu’il a la
faculté d’accepter un très grand nombre de nœuds.
– La tolérance aux pannes : Dans le cas de dysfonctionnement
d’un nœud (manque d’énergie, interférences avec l’environnement d’observation...) ou aussi en cas d’ajout de nouveaux nœuds
capteurs dans le réseau, ce nœud doit continuer à fonctionner
normalement sans interruption. Ceci explique le fait qu’un RCSF
n’adopte pas de topologie fixe mais plutôt dynamique.
– Une densité importante des nœuds : La forte densité des nœuds
est dûe au mode de placement des nœuds (le mode aléatoire).
– Une collaboration entre les nœuds : Les contraintes strictes de
consommation d’énergie mènent les nœuds capteurs à détecter
et traiter les données d’une manière coopérative afin d’éviter le
traitement redondant d’une même donnée observée, source de
18
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 de
plus en plus faible, la large gamme des types de capteurs disponibles
(thermique, optique, vibrations,...) ainsi que le support de communication sans fil utilisé, permettent aux réseaux de capteurs d’envahir
plusieurs domaines d’applications.
Parmi lesquelles, on peut citer :
Applications Militaires : Comme dans le cas de plusieurs technologies, le domaine militaire a été un moteur initial pour le développement des réseaux de capteurs. Le déploiement rapide, le
coût réduit, l’auto-organisation et la tolérance aux pannes des
réseaux de capteurs sont des caractéristiques qui rendent ce type
de réseaux un outil appréciable dans un tel domaine.
Comme exemple : La détection et collecte d’informations sur la
position de l’ennemi, la surveillance des zones hostiles (contaminées), la détection d’agents chimiques, bactériologiques...
Applications Environnementales : Une grande quantité de capteurs
peut être déployée en forêt ou dans un environnement de conservation de la faune afin de recueillir des informations diverses
sur l’état du milieu naturel et sur les comportements de déplacement.
Parmi ces applications, on trouve : Détection des feux de forêt, précision de l’agriculture, Le suivi des mouvements d’oiseaux,d’animaux et d’insectes...
Applications Médicales : On pourrait imaginer que dans le futur, la
surveillance des fonctions vitales de l’être humain serait possible
19
grâce à des micro-capteurs qui pourront être avalés ou implantés sous la peau. Actuellement, des micro-caméras qui peuvent
être avalées existent.
Par exemple : Le contrôle à distance des données physiologiques
de l’être humain, l’administration des médicaments à l’intérieur
des hôpitaux, le suivi et la surveillance des médecins et des patients au sein de l’hôpital...
Applications Commerciales : Il est possible d’intégrer des nœuds capteurs au processus de stockage et de livraison. Le réseau ainsi
formé, pourra être utilisé pour connaître la position, l’état et la
direction d’un paquet ou d’une cargaison. Il devient alors possible pour un client qui attend la réception d’un paquet, d’avoir
un avis de livraison en temps réel et de connaître la position
actuelle du paquet. On trouve dans ce domaine : La détection
et la surveillance des vols de voiture, les musées interactifs, Le
contrô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 duré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 probabilité 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 accomplir les tâches suivantes : échantillonnage, traitement de signal, conversion analogique/numérique et activation de la sonde
20
F IG . 1.10 – Les différentes applications des RCSF [CHE08].
du capture.
En général, l’énergie de capture représente un faible pourcentage de l’énergie totale consommé par un nœud.
b. Energie de traitement : L’énergie de traitement se divise en deux
parties : l’énergie de commutation et l’énergie de fuite. L’énergie
de commutation est déterminée par la tension d’alimentation et
la capacité totale commutée au niveau logiciel (en exécutant un
logiciel).
Par contre l’énergie de fuite correspond à l’énergie consommée
lorsque l’unité de calcul n’effectue aucun traitement. En général,
l’énergie de traitement est faible par rapport à celle nécessaire
pour 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’émission. Cette énergie est déterminée par la quantité des données à
communiquer et la distance de transmission, ainsi que par les
propriétés physiques du module radio. L’émission d’un signal
21
est caractérisée par sa puissance. Quand la puissance d’émission
est élevée, le signal aura une grande portée et l’énergie consommée sera plus élevée. Notons que l’énergie de communication
représente la portion la plus grande de l’énergie consommée par
un nœud capteur.
1.3.9.2
Modèle de consommation d’énergie
Heinzelman et al. [HCB00] proposent un modèle radio de consommation d’énergie (Figure 1.11). Ainsi, les énergies nécessaires pour
émettre ET x (s, d) et recevoir ERx (s) des messages sont données comme
suit :
– Pour émettre un message de s bits vers un récepteur loin de d
mètres, l’émetteur consomme :
ET x (s, d) = ET xelec (s) + ET xamp (s, d)
ET x (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.
F IG . 1.11 – Modéle de consommation d’énergie .
1.3.9.3
22
Les facteurs intervenants dans la consommation d’énergie
La consommation d’énergie dépend de plusieurs facteurs qui sont
expliqués ci-dessous :
a. Etat du module radio : Le module radio est le composant du
nœud capteur qui consomme le plus d’énergie, puisque c’est lui
qui assure la communication entre les nœuds. On distingue les
quatres é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 perte
d’énergie, un capteur doit s’activer qu’en cas de nécessitée, et
le reste du temps il doit se mettre dans l’état sommeil.
b. Accès au medium de transmission : Puisque les nœuds partagent
le même médium de transmission, la sous-couche MAC joue un
rôle important pour la coordination entre les nœuds et la minimisation de la consommation d’énergie. En effet, minimiser les
collisions 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éral
une seule antenne radio et partagent le même canal de transmission. Par ailleurs, la transmission simultanée des données
provenant de plusieurs capteurs peut produire des collisions
et ainsi une perte de l’information transmise. La retransmission des paquets perdus peut engendrer une perte significative de l’énergie.
– La surécoute : Le phénomène de surécoute (overhearing) se
produit quand un nœud reçoit des paquets qui ne lui sont pas
23
destinés, Comme illustré dans la figure suivante :
F IG . 1.12 – La surécoute [MOA08].
– L’écoute active : L’écoute active (idle listening) du canal pour
une éventuelle réception de paquet qui ne sera pas reçu peut
engendrer une perte importante de la capacité des nœuds en
énergie.
– La surcharge : Plusieurs protocoles de la couche MAC fonctionnent par échange de messages de contrôle (overhead) pour
assurer différentes fonctionnalités : signalisation, connectivité,
établissement de plan d’accès et évitement de collisions. Tous
ces messages nécessitent une énergie additionnelle.
– La sur-émission : Le phénomène de sur-émission (overemitting) 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 dans
le 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 signal
radio à une distance donnée d’un émetteur. La propagation du
signal 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 capteurs
est un routage multi-sauts. L’acheminement des paquets d’une
24
source donnée à une destination se fait à travers plusieurs nœuds
intermédiaires.
Dans ce contexte, une mauvaise politique de routage peut avoir
des 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 par
un facteur déterminant à savoir : La minimisation d’énergie sans une
perte considérable de l’éfficacité.
Pour cela de nombreuses stratégies de routage ont été crées pour les
réseaux de capteurs. Certaines sont des adaptations de stratégies qui
existaient pour d’autre types de réseaux (réseaux sans fil au sens le
plus large) tandis que d’autres ont été conçues spécialement pour les
réseaux de capteurs sans fil.
Les protocoles de routage proposés pour les RCSF peuvent être
classifiés selon quatres manières : Selon la topologie, l’établissement
de la route, les paradigmes de communication et le fonctionnement
du 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 un
modèle de négociation afin de propager l’information dans un réseau
de capteurs.
Les communications dans SPIN se font en trois étapes [CHE08] :
– Lorsqu’un nœud veut émettre une donnée, il émet d’abord un
message ADV contenant une description de la donnée en ques-
25
F IG . 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 REQ
vers son voisin.
– En recevant un message REQ, l’émetteur transmet à l’intéressé
la donnée sous forme d’un message DATA.
26
F IG . 1.14 – Les étapes du protocole SPIN[CHE08].
b) MCFA :
Ye et al. ont proposé l’algorithme MCFA (Minimum Cost Forwarding
Algorithm), recherchant un chemin minimal entre la source et le puit,
tout en considérant les limites des réseaux de capteurs. Le protocole
vise à atteindre trois principaux buts :
+ L’optimalité : En acheminant les données sur des chemins à coût
minimum.
+ 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émoire
et l’absence d’identificateur de nœuds, le protocole peut être utilisé
pour un grand nombre de nœuds. En plus, la phase de construction
des 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ût
minimal vers le puit sur le chemin optimal. Plusieurs mesures peuvent
27
être employées, suivant l’application voulue : nombre de sauts, consommation d’énergie, . . . etc.
c) Directed Diffusion :
Directed Diffusion est un protocole de propagation de données, permettant d’utiliser plusieurs chemins pour le routage d’information.
Le puit diffuse un intérêt sous forme de requête, afin d’interroger
le réseau sur une donnée particulière. Il se base sur le modèle publish/subscribe. DD repose sur quatre éléments : nomination des
donné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 maintient
localement un cache d’intérêt contenant les informations suivantes :
– La description de l’intérêt, en utilisant le schéma de nomination : Lorsqu’un puits requiert une donnée du réseau, il propage
un intérêt, contenant sa description ainsi que le débit d’information 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 le
voisin émetteur, et met à jour en conséquence l’entrée en question. Aprés le traitement du cache, le nœud relai l’intérêt vers ses
voisins. La méthode la plus simple est d’utiliser l’inondation.
28
F IG . 1.15 – Etapes décrivantes le protocole DirectedDiffusion [CHE08].
1.4
Conclusion
Ce chapitre a donner une vue globale sur le domaine des
réseaux de capteurs sans fil qui sont apparentés aux réseau Ad
hoc.
Les réseaux de capteurs sans fil présentent un intérêt considérable et une nouvelle étape dans l’évolution des technologies
de l’information et de la communication. Cette nouvelle technologie suscite un intérêt croissant vu la diversité de ces applications : santé, environnement, industrie et même dans le domaine
sportif.
Cependant, la réalisation des réseaux de capteurs doit satisfaire quelques contraintes tel que la consommation d’énergie, le changement de la topologie, la densité importante du réseau,...etc. Ces limites ont menées les chercheurs à suggérer des
29
approches de surveillance pour maintenir le réseau opérationnel le plus longtemps possible tout en gardant une connectivité
dans le réseau (réseau connexe) et une meilleur couverture de la
zone.
De ce fait, Le prochain chapitre sera consacré à la surveillance
des RCSF ainsi la présentation de l’approche distribué que nous
avons choisie.
30
Chapitre 2
La surveillance des Réseaux de
Capteurs Sans Fil
La surveillance est un dispositif utilisé pour analyser l’état du système. Elle consiste à détécter et classer les défaillances tout en observant 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 sur
la combinaison des techniques de surveillance et de diagnostic.
De ce fait dans les RCSF, Certains nœuds capteurs peuvent être
bloqué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’un
nœud capteur ne doit pas affecter le fonctionnement global de son
réseau. C’est le problème de fiabilité ou de tolérance aux pannes.
Pour la résolution de ces problèmes, plusieurs approches centralisées ont été proposées qui se base sur le diagnostic et la reconfiguration au niveau du sink ce qui provoque plusieurs inconvénients tel
que : La surcharge du module, La surcharge du réseau par les messages de contrôle , les délais de transmission qui peuvent retardés la
détection des défauts, et le plus grand désavantage est la défaillance
du module sink.
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 de
défaillance en se fondant sur le principe de redondance avec quelque
propriétés de la théorie des graphes afin de maintenir le réseau connexe
tout en couvrant la totalité de la zone de capture.
2.1
33
La supervision des RCSF
Un superviseur a pour objectif d’assurer le bon déroulement d’une
mission en présence de problèmes et de gérer le meilleur fonctionnement possible. De ce principe, la surveillance des réseaux de capteurs
consiste à détécter les défaults et les pannes ensuite générer des solutions en temps réel pour gardé la longévité du réseau.
Les pannes peuvent se produire à cause d’un défaut au niveau logiciel 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œud
qui est provoqué par la surcharge du réseau avec les messages de
contrôles et même à cause des contraintes dans lequel le réseau est
déployé.
2.1.1
Les Pannes
Une faille (ou panne) du système se produit lorsque son comportement devient inconsistant et ne fournit pas le résultat voulu. La
panne est une conséquence d’une ou plusieurs erreurs. Une erreur
représente un état invalide du système du à une faute (défaut). La
faute est donc la première cause de l’erreur, cette dernière provoque
la faille du système.
2.1.1.1
Classification des pannes
Le schéma suivant montre une classification générale selon la durée, la cause ou le comportement d’une panne :
A. Pannes selon durée :
a1. [Transitoire :] Conséquence d’un impact environnemental
temporaire, elle peut éventuellement disparaître sans au-
34
F IG . 2.1 – Classification des pannes [CHE08].
cune intervention.
a2. [Intermittente :] Variante de la panne transitoire, elle se produit occasionnellement et de façon imprévisible. Elle est généralement dûe à l’instabilité de certaines caractéristiques
matérielles ou à l’exécution du programme dans un espace
particulier de l’environnement.
a3. [Permanente :] continue et stable dans le temps, la panne
permanente persiste tant qu’il n’y a pas d’intervention externe pour l’éliminer. Un changement physique dans un composant 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 genre
de panne ne devrait pas exister grâce aux tests et simulations avant la réalisation finale du réseau ;
b2. [Panne opérationnelle :] Qui se produit durant le fonction-
35
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 capteurs, trois principales causes : L’énergie, Sécurité et Transmission.
C. Pannes selon le comportement résultant :
c1. [Panne accidentelle (Crash) :] Le composant soit, il s’arrête
complètement de fonctionner ou bien continue mais sans retourner à 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 effectue son traitement mais fournit le résultat en retard.
C4. [Panne Byzantine :] Cette panne est de nature arbitraire ; le
comportement du composant est donc imprévisible. Dû à
des attaques très malicieuses, ce type de pannes est considé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 distribution uniforme pour la dissipation d’énergie entre les différents nœuds capteurs ; afin de mieux gérer la consommation
d’énergie et l’augmentation de la durée de vie de réseau. En
outre, le mécanisme de mise en veille est une technique de gestion de batterie. En effet, les protocoles déterminent des délais
de mise en veille des nœuds capteurs inactifs pour une meilleure
36
conservation d’énergie[FEL07].
§ Gestion de flux : Cette catégorie regroupe les techniques qui
définissent des protocoles de gestion de transfert des données
(routage, sélection de canal de transmission...etc.). Nous pouvons trouver des approches préventives ou curatives sur les diffé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œud
collecteur. Ceci garantit la présence de plus d’un chemin fiable
pour la transmission et offre une reprise rapide du transfert en
cas de panne sur le premier chemin sélectionné (choisir un des
chemins qui restent).
Recouvrement de route : Après détection de panne, une technique
curative permet de créer un nouveau chemin plus fiable pour
retransmettre 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 les
collisions durant le transfert.
Mobilité : Certains protocoles proposent comme solution tolérante aux pannes la sélection d’un ensemble de nœuds mobiles
chargés de se déplacer entre les capteurs et collecter les données
captées. Ceci réduira l’énergie consommée au niveau de chaque
capteur en éliminant sa tâche de transmission. Un nœud mobile
est généralement doté d’une batterie plus importante que celle
d’un nœud capteur.
§ Gestion des données : Les protocoles classés dans cette catégorie offrent une meilleure gestion de données et de leur traitement. Deux principales sous-catégories sont déterminées :
37
Agrégation : Considérée comme approche préventive, l’opération
d’agrégation effectue un traitement supplémentaire sur les données brutes captées depuis l’environnement. Un nœud agrégateur combine les données provenant de plusieurs nœuds en une
information significative ; ce qui réduit considérablement la quantité de données transmises, demande moins d’énergie et augmente ainsi la durée de vie du réseau.
Clustering : Une des importantes approches pour traiter la structure d’un réseau de capteurs est le clustering. Il permet la formation d’un backbone virtuel qui améliore l’utilisation des ressources rares telles que la bande passante et l’énergie. Par ailleurs,
le clustering aide à réaliser du multiplexage entre différents clusters. En outre, il améliore les performances des algorithmes de
routage. 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éploiement dépond du type de capteurs, l’application et l’environnement
de fonctionnement du capteur. Le déploiement contrôlé des nœuds
est viable, et souvent nécessaire lorsque les capteurs sont chers, ou
lorsque leur fonctionnement est sensiblement affecté par leur position. Dans certaines applications, la distribution aléatoire des nœuds
est la seule option possible. Cela est particulièrement vrai pour les
environnements difficiles tels que le champ de bataille ou une région
de catastrophe. Selon la distribution des nœuds et le niveau de redondance, le déploiement aléatoire des nœuds peut atteindre les objectifs
38
de performance.
F IG . 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’il
existe au moins une route entre chaque paire de nœuds [MER03]. La
connectivité dépend essentiellement de l’existence des routes. Elle est
affectée par les changements de topologie causés par la mobilité ou
la défaillance des nœuds [BEC09].
Le principe est que la bonne couverture sera rendue lorsque Tr est un
multiple 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. Demaine, M. Taghi Hajiaghayi, and D. Rus" en 2005 qui se base sur la
formulation des RCSFs K-connectés [CSS04]. K-connectivité suppose
qu’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 garantie une certaine capacité de communication entre les nœuds. Les
auteurs étudient le problème du placement des nœuds pour atteindre
K-connectivité au moment de configuration du réseau ou de réparer un réseau déconnecté formulent le problème comme un modèle
39
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éo
n’est pas récent [MSP09]. Plusieurs travaux ont déjà traité ce problème de plusieurs manières. Cependant, il éxiste deux catégories de
couverture :
- Couverture des cibles pré- déterminées : Consiste à trouver un sousensemble de nœuds connexes et qui assure la surveillance d’un ensemble de cibles dont la position est connue à priori.
- Couverture d’une zone : consiste à trouver un sous-ensemble de
nœ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égion
d’intérêt, un nœud est caractérisé par son rayon de couverture r et
son rayon de transmission. La couverture dans un réseau de capteur
sans fil dépend de la denité des nœuds. Cette densité est donnée par
l’é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’optimisation
pour la plupart des protocoles de communication publié pour les réseaux de capteurs. Les positions des nœuds significatives impact sur
40
la durée de vie du réseau. Par exemple, les variations de densité des
nœ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 connectivité 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 un
dysfonctionnement dans un sytème. Comme dans le cas des RCSF, la
redondance est établie pour étendre la durée de vie du réseau, surtout 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, actionneurs, processeurs et logiciels pour mesurer et/ou contrôler une
variable particulière. Un principe de vote est appliqué sur les valeurs
redondantes pour décider si une faute est présente ou non. Cette approche entraîne un coût important en instrumentation mais s’avère
extrêmement fiable et simple à implanter. Elle est mise en œuvre essentiellement sur des systèmes à hauts risques tels que les centrales
nucléaires ou les avions.
Cette approche est appliquée pour les RCSF, puisque c’est le moyen
le plus facile d’obtenir plusieurs informations sur une même variable
et de disposer de plusieurs capteurs mesurant la grandeur de cette
variable.
La redondance physique souffre d’un désavantage majeur : son
41
F IG . 2.3 – La redondance matérielle[RIP99].
coût. Doubler le nombre de capteur revient au moins à doubler le
prix de l’organe de mesure. De plus, les contraintes ergonomiques
liées à l’installation de ces capteurs peuvent limiter leur utilisation.
Les modes qui peuvent être appliqués aux différents niveaux d’un
systè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 plusieurs
composants.
2. La redondance passive : Basé sur la redondance en utilisant une
seule copie, appelée "copie primaire" ; alors que les autres copies
sont utilisées seulement en cas de défaillance.
3. La redondance hybride : Comme son nom l’indique c’est une combinaison entre les deux redondances cites précédemment.
Le choix de la stratégie de redondance se fait en fonction des contraintes
et des besoins applicatifs. Dans le cas des réseaux de capteurs sans
fil, la réplication active est préférable pour tolérer aux défaillances
fréquentes des nœuds capteurs.
2.1.4.2
42
La redondance analytique
Un complément à la redondance physique est d’exploiter les
contraintes liant les différentes variables du système. Ces contraintes
peuvent souvent s’exprimer sous la forme de relations analytiques
liant 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 utilisant
les mesures prélevées en ligne sur le système. Le concept de redondance analytique repose sur l’utilisation d’un modèle mathématique
du système à surveiller.
Définition 1 la structure d’une relation de redondance analytique est la
liste minimale des contraintes devant être satisfaites pour que celle-ci le soit
également. Chaque contrainte étant associèe à un composant, la structure
d’une RRA sera notée en utilisant l’ensemble des composants correspondants. [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 la
panne.
- 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 tests
d’hypothèses.
Ce principe est souvent difficile à exploiter comme dans le cas des
RCSF à 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
43
ces raison, la redondance matérielle est utilisée surtout que le coût
des 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 ensemble d’agents, situés dans un certain environnement et interagissant selon certaines relations. Un agent est une entité caractérisée par
le fait qu’elle est, au moins partiellement, autonome. Ce peut être un
processus, un robot, un être humain, etc. Objet de longue date de
recherches en intelligence artificielle distribuée, les systèmes multiagents forment un type intéressant de modélisation de sociétés, et ont
à ce titre des champs d’application larges, allant jusqu’aux sciences
humaines.
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 leurs
plans 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ésolution
de problèmes incomplètes, donc chaque agent a un point de vue
limité ;
– 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
44
Les Travaux Antérieurs
Dans le domaine des RCSF(s) plusieurs approches ont été proposées pour remédier aux problèmes trouvés suite au fonctionnement
des RCSF(s). Dans ce contexte, les méthodes ou les solutions proposé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 vers
l’économie d’énergie, la qualité de service et dernièrement vers la
surveillance des RCSF(s). En ce qui concerne ce dernier point, on peut
citer ce qui suit :
Dans " SELF ORGANIZED SENSOR"[YCC05], l’auteur à conçu
son protocole de surveillance basé sur la construction d’ un arbre hiérarchique en utilisant le modèle mathématique tels que la théorie des
graphes ou d’un diagramme de Voronoi qui s’appliquer à une vaste
zone en raison de l’utilisation de la communication multi-sauts ainsi
Les 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 une
image binaire.
45
Le Protocole de EEP proposé par SAYAD MAYA [SAY09] apporte
des améliorations telles que l’augmentation de la durée de fonctionnement 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 routes
est dynamique et se base sur une fonction de coût qui prend en compte
le niveau d’énergie des nœuds et leur distance par rapport a la station de base.
Les auteurs [BAI10] ont étudiés la surveillance en utilisant l’aide
multicritère à la décision en formulant des spécifiques qui sont les
ressources limitées en termes de charge et de capacités de stockage
et de calcul, ainsi que l’absence d’infrastructure fixe (la mobilité),
connectivité, et la distance entre les capteurs faire face aux mauvais
comportements qui peuvent le cibler.
Dans CFIP09 [MSP09]les auteurs s’intéressent à la surveillance des
vidéos des Réseaux De Capteurs Sans Fil ou ils adoptent une approche pour ordonnancer de manière adaptatif l’activité des nœuds
vidéo en fonction de la couverture. Ils ce sont dirigés vers un algorithme distribué où chaque nœud organise ses voisins en un ensemble de nœuds disjoint ensuite en se basant sur l’activité, chaque
nœud décide s’il reste actif ou non. Simulation s’est établie a base
d’un modèle multi-niveaux.
Samira ALLAM dans [ALL09] s’interesse au protocole de routage
basé sur une approche distribué avec un contexte multi-agent basée sur l’Auto-organisation pour but de ballier d’un système centralisé à un système descentralisé pour garantir la réduction d’énergie
consommée.
Dans [BEC09] l’auteur à proposé un modéle descentralisé pour la
surveillance d’un RCSF en utilisant un simulateur personnel conçu
46
avec C++ pour la validation des tests.
Aprés plusieurs recherches, nous avons constaté que la surveillance
des 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 de
recherche. De ce fait nous nous sommes basé sur l’application d’une
approche distribuée pour les Réseaux De Capteurs Sans Fil et de simulé 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
47
Description de l’approche distribuée (décentralisée)
L’approche suivie consiste à la définition d’un réseau de capteur
sans fil avec le principe d’agents : différents rôles attribués aux nœuds
pour formé des groupes (zones ou clusters), Ce même algorithme est
utilisé pour la réorganisation du réseau en cas de défaillance en utilisant 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 une
zone, ces nœuds suivent une topologie dynamique c.à.d que les capteurs peuvent bougés ou même l’ajout ou la disparaission des capteurs peut être envisageable.
Le réseau est divisé en groupes de capteurs où chaque nœud a un
rô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és
dotés d’un comportement, cordonner leurs buts et leurs plans d’actions 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 communications au sein du groupe de capteur. Il assume toutes les
requêtes d’envoies de messages des membres de sa région. C’est
le nœud qui s’encharge de la communication du groupe avec
l’extérieur. Notons qu’un représentant ne peut jamais avoir un
voisin du même rôle.
48
b) Nœud Liaison : Permet aux nœuds représentant de communiquer (il est aux frontières de plusieurs groupes de capteurs). Il
est chargé d’assumer les communications entre les régions.
c) Nœud Simple : N’est autre qu’un simple capteur, il capture de
l’information demandée et la faire communiquer au Sink via son
représentant.
d) Nœud Sink : C’est la station principale qui peut communiquer
avec tout les nœuds afin de collecter les informations voulues.
F IG . 2.4 – Organisation en régions des nœuds capteurs [ALL09].
2.4.2.1
49
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 simple
RoleAffecté = Simple ;
}
else
{
//plusieurs représentant autour du nœud alors ce
//capteur ne peut être qu’un noeud de liaison
RoleAffecté = Liaison ;
}
}
}
}
L’application de tel algorithme mène le réseau a se représenté de la
façon suivante :
50
F IG . 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’attribution de rôles qui se compose en plusieurs étape résumées dans les
points 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 de
messages. Les intéractions entre les 3 agents permettent de comprendre
le fonctionnement de ce protocole. Ces intéractions sont définies par
rapport au rôle attribué.
2.5.1
51
Les Diagrammes UML
Les Diagrammes suivant la méthode UML, plus précisément le
diagramme Etat-Transition et Diagramme de Séquence sont élaborés
pour présenter les différents états d’un nœud et pour donner une
idée générale et plus claire sur le principe de l’approche suivie.
F IG . 2.6 – Diagramme Etat Transition.
52
F IG . 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 connexion
du réseau. Dans ce contexte, Chaque capteur diffuse un message dit
"Message HELLO" (à tout les nœuds d’un seul saut). Ce message est
défini comme suit :
Type Source Destination NSaut
53
Chaque nœuds recevant ce message (HELLO) répond par un message à 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 à jour
leurs table de voisinage et de ce principe le changement de rôle peut
affécté les nœuds capteur.
2.5.2
Changement de rôles :
Lors de la détection de changement dans la table de voisinage par
un nœud. Ce dernier éxécute l’algorithme de changement de rôle expliqué précédemment en envoyant un message "ChangeRole" qui a
la structure présenté ci-dessous. Sachant que chaque nœud recevant
ce message sera obligé à éxécuté l’algorithme d’attribution de rôles
tout en modifiant sa table de voisin.
Type Source Destination Rôle Groupe [BEC09]
F IG . 2.8 – Introduction d’un nouveau nœud.
2.5.3
54
Détection des groupes voisins
Les nœuds Représentants sont définis avec une table contenant
les groupes voisins. Cette dernière doit être mise à jour suivant la
connaissance des nœuds liaisons entre les groupe en se servant du
message HELLO.
Cette figure présente le fonctionnement cité sur la détection des groupes
adjacents.
F IG . 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 deux
groupes 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 message "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 et
si l’incohérence est confirmée, un nœud Représentant peut changer
son rôle en affectant à un autre nœud le rôle Représentant en lui en-
55
F IG . 2.10 – Correction du problème d’incohérence.
voyant le message "PasseReprésentant" comme le montre la structure
suivante :
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 topologie peut changer à cause de la mobilité d’un nœud (épuisement
d’énèrgie....). Cette configuration peut produire un conflit entre les
groupes dans le cas où deux représentants deviennent voisins.
Ce problème peut être résolu à l’aide du message "ResConflit" qui
a 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 "ResConflit", ou devenir un nœud Simple en diffusant le message "ChangeRôle".
56
F IG . 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 autre
nœud possédant le même rôle apte d’assurer précisément les mêmes
tâches du nœud condidat.
Ce mécanisme de gestion de redondance est utilisé pour maintenir
une longue du fonctionnement du vie au réseau avec un minimum
de nœuds collaborant pour pouvoir réveiller les autres nœuds en cas
de défaillance d’un capteur.
Ce processus est appliqué sur tous les nœuds dont leurs rôles est soit
Simple ou Liaison de la façon suivante :
a. N ŒUD S IMPLE :
Un nœud Simple "S1" est dit redondant s’il existe un autre nœud
Simple "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 Gabriel :
57
Redondant(S1)/S1Gi ⇒ ∃S2Gi etS1Cercle(S2, Ri )[BEC09]
F IG . 2.12 – Redondance des nœuds simples.
b. N ŒUD L IAISON :
Un nœud liaison L1 est considéré redondant si et seulement s’il
existe 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 des
nœuds représentants couvert par L2.
On peut formuler ça de la façon suivante :
Redondant(L1)/L1Gi ⇒ ∃L2Gi /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 est
dé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’état
d’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
58
ou l’endormir.
La composition du message est comme suit :
Type Source Destination NS [BEC09]
Sachant que :
- NS "N EW S TATE " est le nouveau état destiné à un nœud par son
représentant.
Le mécanisme est présenter dans la (Figure 2.13) :
F IG . 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 de
cette approche. Dans ce contexte, l’échange pèrdiodique du message
"HELLO" permet au nœud Représentant de découvrir la défaillance
des 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 "HELLORep" 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 Représentant, ce dernier réveille tous les nœuds voisins et lance le
59
processus d’affectation des rôles en diffusant le message "ChangeEtat".
2.5.7
Collecte d’information
Un réseau de capteur est configuré pour la collection d’information, tel que la température, la pression, ou des informations multimédia.
L’approche utilisée se base sur l’utilisation de deux messages simples
de 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’information captée par son groupe en utilisant le chemin optimal qui
est connu par l’envoi périodique du message "HELLO" avec le
champ "HC"(Hop Count).
2.6
60
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 fil
pousse les chercheurs a proposés différents mécanismes de consommation d’énergie, surveillance aux niveau de ces réseau. De ce fait, la
configuration en groupes permet l’auto-organisation des nœuds sans
faire appel au sink.
Le déploiment aléatoire des nœuds implique la présence des capteurs redondants, Ces derniers sont mis en veilles afin de minimiser
la consommation énergitique des nœuds sachant que ces capteurs
sont réveillés en cas de besoin.
Dans les chapitres suivant, nous présenterons les outils de simulations existants tout en justifiant notre choix, ainsi on va montrer les
résultats de simulation pour valider l’approche étudiée et proposer
d’autre suggéstions.
61
Chapitre 3
Les technologies informatiques s’étendent de plus en plus ce qui
mè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 de
ses composants atomiques. Ce principe est forcément appliqué pour
les réseaux de capteurs sans fil, les différentes propositions des chercheurs pour remédier aux problèmes des RCSF tel que la consommation d’énergie, la durée de fonctionnement du réseau, les contraintes
de collecte d’informations... nécessite une phase de test avant la mise
en place. Pour cela, la solution la plus fiable et la moins coûteuse
consiste en " La Simulation ".
La simulation des réseaux de capteurs consiste principalement en
la reproduction du comportement et du fonctionnement des nœuds
capteurs dans un environnement informatique ; pour des raisons telque :
La répétition d’expérience, L’adressage des systèmes complexes, Le
gain de temps et la variation des paramètres de simulation alors que
la simulation réelle s’avère coûteuse, voir impossible dans quelque
cas.
Dans ce qui suit, nous parlerons brièvement des simulateurs de
63
réseaux éxistants, du simulateur choisi pour nos simulations "OMNET++" et de la plate forme des simulations de réseaux de capteur
sans fil "CASTALIA".
3.1
64
Généralités sur la simulation
Dans nos jours, la simulation connaît un essor considérable, et ce
grâce à l’intérêt que présente les modèles informatiques des systèmes
simulés ;
Définition 2 La simulation consiste à la modélisation informatique d’un
système quelconque, en offrant une représentation de toutes les entités de ce
système, leurs comportements propres, ainsi que leurs interactions. Elle met
à la disposition de l’utilisateur un environnement d’expérimentation dont
on peut faire varier les paramètres.
Grâce aux progrès réalisés dans le domaine du développement et
des techniques de programmation, nous disposons aujourd’hui de
langages de programmation trés puissants. Ainsi, il devient possible
de réaliser un simulateur dans un environnement de programmation
existant.
3.2
Types de simulation
En fonction du type d’évènements dans la simulation, nous distinguons deux types de systèmes de simulation : les systèmes discrets
et les systèmes continus.
3.2.1
Systèmes de simulation discret :
Sont des systèmes pour lesquels les variables concernées par la simulation ne changent d’état qu’en un nombre fini de points sur l’axe
du temps. On appelle également ces systèmes : systèmes de simula-
65
tion à évènements discrets.
3.2.2
Systèmes de simulation continue :
Ce sont des systèmes pour lesquels les variables peuvent changer
d’é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, GLOMOSIM et bien sur notre simulateur OMNET++.
3.3.1
NS2 :
NS est un simulateur à évènements discrets trés répandu dans le
domaine 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 simulateur
NS.
Il constitue un support important pour la simulation de protocoles
TCP, protocoles de routage, protocoles de multicast.
Le developpement de NS suit une approche orientée objet qui utilise
deux langages de programmation : C++ et TCL. Les modules de base
du simulateur et les protocoles sont implémentés en C++ avec une
couche TCL au-dessus, qui fournit une interface flexible et facile à
utiliser [5].
La figure suivante illustre les différents composants internes du simulateur :
66
F IG . 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 celle
des sept couches OSI pour les réseaux [MAK08].
Il a été développé au laboratoire UCLA Parallel Computing Laboratory en utilisant le langage PARSEC.
PARSEC (PARallel Simulation Environnement for Complex system)
est un langage de programmation dérivé du langage MAISIE. Tous
deux sont destinés à la simulation à évènements discrets. Ils ont été
développés à partir du langage C à l’université UCLA (University
Califorinia Los Angeles).
67
Le transfert de paquets dans GloMoSim se fait selon le schéma suivant :
F IG . 3.2 – Transfert des paquets dans GloMoSim.
3.3.3
68
OMNET++
OMNeT++ IDE (Integrated Development Environment ) est basé
sur la plateforme Eclipse. C’est un environnement open source qui
fournit des outils pour la création et la configuration des modèles de
réseaux (les fichiers NED et INI) et des outils pour l’éxécution d’un
lot de programmes ainsi que pour l’analyse des résultats de simulation [MSK05].
OMNeT++ semble être le meilleur parmi les solutions open source et
freeware. 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 ainsi
les raisons du choix de ce simulateur.
3.4
Comparaison entre les simulateurs
La simulation est souvent moins chère que l’expérimentation et
comporte beaucoup moins de risques lorsque l’homme fait partie du
système étudié. Les résultats peuvent être obtenus beaucoup plus
rapidement. La simulation (surtout numérique) est basée sur une
connaissance des phénomènes qui ne peut être obtenue que par l’expérimentation.
Une simulation ne peut donc être réalisée que si on dispose d’un acquis de connaissances suffisant obtenues par des expérimentations
sur des phénomènes antérieurs et analogues. Quelle que soit la qualité de la simulation, elle ne remplace pas totalement l’expérimentation. Voici un tableau général décrivant les avantages et inconvénients des simulateurs décrit auparavant [RSA09] :
69
Simulateurs Avantages
NS2
Inconvénients
◦ Utilise l’Orienté Objet,
◦ Conçu pour les réseaux
filaires,
◦ Permet la simulation des ◦ Difficulté d’ajout de
comportements des proto- nouveau modèles à cause
coles standard,
des dépendances entre
modules,
◦ Nombreux protocoles ◦ Intégration difficile à
disponibles,
d’autres applications,
◦
Simulateur
Couches.
Multi- ◦ La faible performance
des simulations de réseaux
importants,
◦ Scénario de simulation
décrit en Otcl.
GloMoSim
◦ Initialement conçu pour ◦ Nécessité de maitriser
les réseaux sans fil (Surtout le Parsec pour toute perles réseaux Ad Hoc),
sonnalisation autour du
noyau,
◦ Exécution des simula- ◦ Installation assez comtions relativement rapide, plexe.
◦ Environnement de simulation parallélisable.
OMNET++
◦ Architecture modulaire
permettant l’intégration de
nouveaux modèles,
◦ Utilisation du C++ (et ré-
◦ Ne prend pas en charge
le cas des réseaux de capteurs.
◦ Peu de modèles pour les
cemment du C#) pour le réseaux sans fils,
développement du noyau,
◦ Les classes de base du ◦ Description des modèles
simulateur peuvent être en langage NED.
étendues et personnalisées,
◦ Conception de modèles
se rapprochant de la réalité
3.5
70
Le Simulateur OMNET++(Objective Modular Network Testbed in C++)
3.5.1
Choix du simulateur OMNET++
Le déploiement d’un réseau de capteurs exige une étape de simulation 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 discrets basé sur le langage C++, une application open source et sous
licence GNU [IDE04]. Il est totalement programmable, paramétrable
et 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 complexes.
OMNET++ sera notre environnement de simulation, grâce à son architecture modulaire, il s’agira d’étendre le simulateur en implémentant 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 discrets. Utilisé pour la simulation des réseaux de communication, et
d’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 :
71
F IG . 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 communiquant par envoient de messages.
OMNET++ est basé sur la plateforme Eclipse. [?] Il fournit des outils pour la création et la configuration des modèles de réseaux (les
fichiers NED et INI) et des outils pour l’exécution d’un lot de programmes 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 modules
hiérarchiquement emboités tel qu’il est montré dans la (Figure 3.4) :
72
Les modules Simples sont écrits en C++ en utilisant la librairie de
F IG . 3.4 – Architecture modulaire du simulateur Omnet++.
simulation d’OMNET++, Ces derniers contiennent des algorithmes
relatifs au modèle implémenté. Le groupement des modules simples
constitue des modules composés sachant que leurs communications
sont 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’environnement extérieur, mais plutôt avec ses composants internes(Modules
simples et composés) [IDE04].
Les modules peuvent s’attribuer des paramètres assignés aux modules dans les fichiers de description de réseaux (fichiers NED) ou
encore dans le fichier de configuration « omnetpp.ini ». Ces paramètres sont utiles pour la personnalisation du comportement des
modules simples ou encore pour le paramétrage de la topologie du
modèle.
3.5.4
Installation du simulateur OMNET++
L’installation d’OMNET++ se fait en différentes étapes suivant une
procédure d’installation décrite dans le package téléchargé selon le
système d’éxploitation installé [OMN10]. Les éléments installés sur
73
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 utilisé en 2 modes : Mode Graphique ou Mode Texte qui permettent de
décrire les paramètres et les ports du module. Les erreurs comisent
sont indiquées en temps réel par un point rouge situé à la gauche du
code.
Un exemple de fichier Ned en mode "Source" & "Graphique" sont
présentés dans la(Figure 3.5) et (Figure 3.6).
F IG . 3.5 – Fichier NED en mode graphique.
F IG . 3.6 – Fichier NED en mode texte.
74
3.5.5.2
75
Fichier (.ini) :
Est lié étroitement avec le fichier NED. Permet à l’utilisateur d’initialisé les paramètres des différents modules ainsi la topologie du réseau.
Voici un exemple présenté ci-dessous :
F IG . 3.7 – Exemple d’un Fichier *.Ini.
3.5.5.3
Fichier (.msg) :
Les modules communiquent en échangeant des messages. Ces dérniers 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 les
définitions de messages en classes C++.
Le diagramme suivant peut donner une idée plus détaillé sur le
développement d’éxécution d’une simulaion sous Omnet.
76
F IG . 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 de
capteurs sans fils, Pour cela il existe plusieurs extentions, plate forme
et simulateurs basés sur OMNET++ qui essayent d’introduire ce manque
comme "Mobility FrameWork", "Mixim", "Castalia" ...etc
3.6.1
Mobility FrameWork
Cette plate forme assure la mobilité des hôtes dans le réseau, leurs
connectivité ainsi un canal sans fil. Elle supporte la simulation des
réseaux sans fil, les réseaux mobiles et même les réseaux de capteurs
sans fil [LWI07]. Pour information, Mobility FrameWork 2005 était la
plate 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 peut
les utilisés afin de créer et d’implémenter de nouveaux protocoles
pour la simulation.
77
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.
F IG . 3.9 – Architecture de Mobility et Channel Control.
La simulation d’un réseau avec une tel plate forme est basé sur la
compréhension du principe et des propriétés de fonctionnement de
Mobility 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 est
schématisé dans la figure suivante [LWI07] :
78
F IG . 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 plusieurs cadres existants pour les simulations sans fil et mobiles dans
OMNeT++. Bien que OMNeT++ n’a pas un soutien clair des modèles de simulation pour la communication sans fil, Mixim fournit
des modèles détaillés de canal sans fil (décoloration, etc), la connectivité sans fil, la mobilité, les obstacles et les protocoles MAC comme
IEEE 802.11b et IEEE 802.15.4. Mixim propose des modules pour une
mise en œuvre facile de nouvelles protocoles MAC comme Time Division Multiple Access (TDMA) ou en fonction des protocoles hybrides (p. ex Z-MAC). Mixim est écrit avec le langage C++ comme
Castalia et OMNeT++.
3.6.3
Castalia
Castalia [ABD09] [LIL09] est également un simulateur de niveau
pour les réseaux de capteurs basé sur OMNeT++. Il s’agit d’un simulateur générique avec un canal sans fil et un modèle de radio basé sur
79
des données mesurées . Comme il est illustré à la (Figure 3.11), Castalia définit trois modules principaux : le nœud, Processus physiques
et les canaux sans fil. Castalia est développé avec le C + +.
F IG . 3.11 – Les connections des modules sous Castalia.
Le module nœud est en fait un composite.La (Figure 3.12) montre
la structure interne du module nœud. Les flèches pleines signifient le
passage de message et les flèches en pointillés signifient une interface
entre les modules et les appels fonctions.
Par exemple, la plupart des modules font appele au gestionnaire de
ressources pour signaler la consommation d’énergie. Le Module d’application est le plus touché par l’utilisateur, le plus souvent par la
création d’un nouveau module pour mettre en œuvre un nouvel algorithme. Les modules MAC, Routage, ainsi que le module de mobilité, sont également modifiés, généralement la création d’un nouveau module est en cause pour la création d’un nouveau protocole.
Tous les modules existants sont très accordés par de nombreux paramètres.
Remarque 1 D’aprés la description des 3 plates formes précédentes, on
peux facilement conclure que la plate forme "Castalia" est la plus appro-
80
F IG . 3.12 – Les principaux composants d’un nœud .
priée pour notre projet. Son cadre de "Wsn" nous facilite le traitement de
notre application ainsi que l’évaluation du nouveau protocole.
En plus Castalia est basé sur OMNeT++ l’un des simulateurs les plus populaires 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 forme
sous OMNeT++ conçue particulièrement pour les RCSF [SAY09] .
La structure de Castalia [BOU10] est également reflétée dans l’hiérarchie avec un code source. Chaque module contient un dossier "ned"
qui définit le module lui même. Si le module est composé, les sousrépertoires existant définissent les sous-modules avec un code de
C++ (cc, dossiers de h) qui définit son comportement. Cette hiérarchie complète des dossiers "ned" définit la structure globale du simulateur de Castalia.
Les principaux modules de Castalia sont :
3.7.1
81
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œud
en é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 illustrés au niveau de Castalia pour la couche MAC en utilisant le fichier
de configuration OMNeT++ (. ini). Par un simple réglage de certains
paramètres des fichiers MAC "CSMA/CA", "TMAC", et "l’AMCC" de
diffé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 consommation d’énergie sera différentes dans chaque Etat. C’est la caractéristique principale de ce module. La figure a état fini peux donner une
idée générale sur le changement d’état.
F IG . 3.13 – La machine à état fini du module Radio.
3.7.3
82
Canal sans fil
Le module du canal sans fil est conçu pour modéliser l’environnement sans fil, qui est une évolution dynamique de l’environnement
pour le nœud statique et mobile. Il ya quatre principaux modèles de
canal 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 quatre
modè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 recevoir
le message de MAC module, et envoyer un message à la demande. Il
dépend des informations d’entête, Il existe deux types d’algorithmes
de routage dans Castalia : simpleTreeRouting et multipathRingsRouting.
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émentaires
aux paquets d’application,
3) netBufferSize indique la taille de l’amortisseur trouvé dans le module.
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
83
radio. Ainsi ce module utilise également le mécanisme de message
pour effectuer des actions différentes.
3.8
Outils de Simulation
L’installation du simulateur OMNET++ et la plate forme Castalia
est comme suit :
3.8.1
Installation d’OMNET++ Version 4
Avant de commencer l’installation, il faut tout d’abord télécharger le code source omnetpp4 du site (http://www.omnetpp.org/)
sans oublié de vérifié la version Linux, ensuite copier la source dans
le dossier voulue et se positionner avec l’invite de commande dans
ce 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
84
Installation de Castalia3.1
Les étapes sont les suivantes [BOU10] :
1. Décompression de l’archive Castalia déja télecharger à partir du
site (http://castalia.npc.nicta.com.au/download.php)avec
la commande :
xzf castalia.tgz ;
2. Importation du projet dans OMNeT++ ide : Aprés avoir lancer
Omnet++, l’importation du projet se fait avec un clique droit sur
"General->Exiting project into workspace" et en choisir la racine
du 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 exemple
lance la simulation et génére un fichier *.txt qui se définit comme
le 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 configuration. 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 nouveaux
protocoles au sein de cette plate forme. Dans ce contexte, les fichiers
template facilite la création d’un nouveau réseau avec les différents
85
couches.
Pour l’implémentation il suffit de copier les fichiers nécéssaires
dans un nouveau répertoire de votre choix.
Nous avons adopté ce principe et créer un nouveau répertoire appelé "RCSF" ensuite copier les fichiers "yourNetwork.ned", "yourApplication.ned", "yourHost.ned", "omnetpp.ini". Ces derniers contiennent
des racines de procédures, où chacun peut modifié et élaboré son
protocole.
Le programme sera complet que par l’ajout et la programmation
des fichiers ".cc", ".h", ".msg" des différents modules.
Une fois que tous les fichiers sont complet, la plateforme Castalia
prendra en considération ce nouveau réseau seulement en éxécutant
les é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 nouveau
fichier "youNetwork" sera créer, en l’éxécutant la simulation commencera.
3.10
86
Conculsion
Dans ce chapitre nous avons présentés les différents simulateurs
existant pour les réseaux de capteur sans fil. Parmi ces simulateurs,
notre choix a été fixé sur OMNET++ essentiellement à cause de sa
construction modulaire et sa fléxibilté.
Le manque du simulateur OMNET++ au niveau des prtocoles de
ré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 programmation
du protocole proposé dans le chapitre 2, le plus intégré au sein du
simulateur OMNeT++ et Castalia au niveau des différentes couches
ainsi on analysera les résultats de simulation d’un réseau avec et sans
redondance.
87
Chapitre 4
L’évolution de l’informatique a été marquée par l’apparition de
systèmes microélectromécaniques miniaturisés : les réseaux de capteurs sans fil. De nombreuses applications nouvelles émergent chaque
jour 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éseaux
de capteurs, il est impératif de passer par la simulation de ces réseaux. Cependant, de tels réseaux ne sont jamais complètement pris
en 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 a
conduit à choisir un simulateur en particulier : OMNET++.
Il a fallu peser les avantages et inconvénients présentés par chacun
des 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 des
réseaux de capteurs.
Dans ce chapitre , il aura une présentation détaillée sur l’implé-
89
mentation de notre méthode de surveillance ainsi les résultats obtenus qui seront discutés dans ce même chapitre.
4.1
90
Environnement de travail
Nous allons détaillés les outils utilisés dans la réalisation de notre
simulation.
4.1.1
Environnement matériel
La simulation a été réalisée sur un ordinateur Acer dont la configuration est :
Processeur
Core2Duo 2.0 GHz
Mémoire
2GB DDR2
Disque dur
160 GO
Carte Memoire 2 Go
4.1.2
Environnement logiciel
Notre simulation a été réalisée dans l’environnement logiciel suivant :
– 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’élaboration de notre projet résumé dans la (Figure 4.1)
91
F IG . 4.1 – Processus de Simulation.
4.3
4.3.1
Réalisation du projet
Objectif
Notre objectif est d’ajouter au niveau du simulateur Castalia une
nouvelle 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 de
nouveaux concepts aux niveau des autres couches pour pouvoir atteindre notre but.
Pour cela, nous avons tout d’abord créer un module "nœud" avec tout
ses sous modules, ensuite implémenter les différents messages utilisés et ensuite programmer le module de la couche Réseau et enfin
simuler 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 deployement
aléatoire des nœuds.
92
Pour notre simulation, la 1ere chose qu’on devait modélisé est le module nœud avec ses différents sous modules (La pile protocolaire).
Pour une vue mieu explicatif, le fichier graphique ".Ned" illustre
les 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œud
battery : 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 :
}
93
F IG . 4.2 – Fichier graphique ".ned" du nœud.
D’aprés les 2 fichiers, on peut résumé que le nœud dans notre simulation a été conçu de sorte a ce qu’il contient les différentes couches
décrites par les sous modules comme suit (Du haut en bas) :
Couche Réelle
sous Module décrivant la couche
Couche Application WsnApplLayer
Couche Réseau
WsnNetwLayer
Couche 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é par
une batterie au niveau de chaque capteur.
"mobility" : Pour pouvoir définir la topologie du réseau ainsi pour
connaitre la position de chaque capteur.
Dans les section suivantes, on détailera la programmation de chaque
couches avec leurs code ".cc" et leurs fichier ".ned" sachant que ces
94
dernieres sont implémentées à partir des modules de base de Castalia.
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 : La
partie Graphique et la partie Source (Figure 4.3).
Un réseau de capteur sans fil est composé du module nœud décrit
précedemment ainsi d’un canal pour la communication entre nœud
et processus physique pour la gestion des données capturées par les
capteurs.
Les connections entre nœuds sont gérées au niveau de cette structure dans "Connections" mais nous avons choisis de laisser une génération aléatoire pour se rapprocher plus aux concepts des Réseaux
De 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
}
F IG . 4.3 – Fichier graphique ".ned" du réseau.
95
4.4
96
Implémentation
Nous allons commencé à donner un aperçu sur les messages implémentés, ensuite entrer dans le cœur des codes sources implémenté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 notre
Approche 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 cette
couche est comme suit :
F IG . 4.4 – Fichier ".msg" du message Data.
Nous avons tésté notre Approche avec un module existant sous
Castalia, juste nous avons modifié l’acheminement du message de
donné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 commencera par illustré les différents messages implémentés au sein de
la 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
97
de remplir la tables des voisins.
F IG . 4.5 – Le structure du message Hello et HelloRep.
Le message HelloRep a les même champs que Hello et comme plus
les 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és
sous Castalia (OMNeT++).
F IG . 4.6 – Le structure du message "Passe Représentant" et "Résolution de conflit".
98
F IG . 4.7 – Le structure du message Verification de cohérence et Changement de
rôle.
4.4.2
Aperçu des Codes Sources
Tout d’abord, nous avons implémentés l’envoi periodique du message hello suite à un temps ou à un évènement qui peut se gérer selon
le Schedule.
4.4.2.1
Envoi Periodique du Message HELLO
void WsnSurvey : : sendhello()
{
WsnHello *msg=new WsnHello("WsnHello",NETWORK_LAYER_PACKET) ; //Création du message
msg ->setSrcAdress(SELF_NETWORK_ADDRESS) ;
msg->setDestAdress(BROADCAST_NETWORK_ADDRESS) ;
msg->setHelloKind(HELLO) ; // Remplir les paramètres du message
trace() « "broadcast ["«msg->getName()« "] initialisation from "«
msg->getSrcAdress()« " to "« msg->getDestAdress() ;
scheduleAt(simTime(),msg) ; //Programmer l’envoi pèridique
toMacLayer(msg,BROADCAST_MAC_ADDRESS) ; // Envoi du message a la couche MAC
}
Une fois le Message HELLO est diffusé, chaque nœud recevant ce
Message doit répondre en envoyant un Message HELLO-Rep pour
confirmer sa présence comme étant voisin. Et de ce principe que la
table des voisins se remplies selon le Code suivant :
99
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 existe
if (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 Voisin
trace()«"vois"«nbvois ;
trace()«"nveau voisin" «newEntry.Address«"et"«newEntry.source ;
}
else
Voisin existe, MAJ du rôle {
Neighbor Entry=pos->second ;
Entry.Address=d ;
Entry.srcRole=r ;
trace()«"voisin existe deja" ;
}
role =RoleAttribute() ; //Attribution des Rôles
WsnHello * 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 Commence à attribué les rôles selon les conditions de distribution des capteurs. Tout ça peut être résumer dans ce Code :
100
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 representants
nbRep++ ;}
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’algoritme
if(nbRep == 0) IchRole = 3 ;//noeud de liaison
else
{
if (nbLiaison== 0) IchRole=2 ;//représentant
else
{
if (nbRep > 1) IchRole = 1 ; //noeud simple
}
}
//fin
trace()«IchRole ; // Afficher le rôle du nœud
return IchRole ;
4.4.2.3
Gestion de la redondance
En utilisant la propriété du graphe de Gabriel, la couverture du
réseau peut être assurer seulement avec le Représentant et les nœuds
actifs. 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 prend
la main et commence la procédure de mettre en veilles les nœuds
redondants.
101
F IG . 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œud
for(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 SLEEP
toMacLayer(state,resolveNetworkAddress(des)) ;
if ((aNeighbor.srcRole == 1)&&(nbSimple !=0)) { state = new cPacket("state",STATE) ;
toMacLayer(state,resolveNetworkAddress(des)) ;
}
}
}}
4.4.2.4
102
Rediffusion du Hello
Aprés chaque periode de temps le nœud Représentant envoi un
Message 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 simulation pour l’exécution. L’éditeur est en connaissance de toutes
les déclarations NED (modules simple ou modules composés).
103
[General]
#=============================================# Always include the
main Castalia.ini file
#============================================= include
../Parameters/Castalia.ini
sim-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 manually
SN.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"
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 couches
SN.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
//La couche MAC
4.5
4.5.1
104
Résultats Obtenus
Deployement du Réseau
L’inconvénient de Castalia c’est qu’il ne permet pas d’avoir une
vue du réseau au cours de l’éxécution sachant que les chercheurs y
travaillent dessus pour enréchir le Simulateur surtout aprés son évaluation parmi les Simulateurs les plus sûr.
˙ Pour cela, Ces figures montre le graphique du deployement des
nœuds au niveau du réseau à l’état Initial.
F IG . 4.9 – Deployement des nœuds.
105
F IG . 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 comme
cité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 du
processus parcouru de chaque nœud durant la simulation.
– Fichier Resume : Ce dernier affiche l’état du nœud en résumant
par exemple le nombre de packets reçus, perdus, et la consommation d’énergie.
4.5.1.1
Initialisation des nœuds
Un aperçu du fichier lors de l’initialisation ou le deployement des
nœuds au niveau du réseau.
106
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 et
envoie un message Hello pour la reconnaissance de voisinage dont
107
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
108
Table de voisinage et Affectation des rôles
Une fois les nœuds recoivent le message HELLO, chaque nœud
rempli sa table de voisinage et à ce moment là, chaque nœud prend
un 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 voisinage et l’attribution des rôles.
En cas de changement de rôle à cause de la mort d’un nœud, c’est
le capteur Représentant qui devient responsable de ce changement
et affecte un rôle aux autres nœuds aprés consultation de sa table de
voisinage.
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
109
Passage en Etat Sleep
Voici un extrait de code qui donne un aperçu sur l’état d’un nœud
lorsque ce dernier reçoit le Message Changement d’état pour passer
du mode Réveillé en mode Sleep pour but "Gain d’énergie" comme
cité 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 la
fin de l’éxéctution de la simulation. Par exemple, l’energie consommée, le nombre de paquets envoyés, reçus et même perdus de chaque
nœud présent dans le réseau.
Castalia| module :SN.node[0].ResourceManager
Castalia| simple output name :Consumed Energy
Castalia| 0.604138
Castalia| module :SN.node[0].Communication.Radio
Castalia| simple output name :RX pkt breakdown
Castalia| 1 Failed, below sensitivity
Castalia| 115 Failed, non RX state
Castalia| 17 Received with NO interference
Castalia| simple output name :TXed pkts
Castalia| 15 TX pkts
Castalia| module :SN.node[1].ResourceManager
Castalia| simple output name :Consumed Energy
Castalia| 2.82057
Castalia| module :SN.node[1].Communication.Radio
Castalia| simple output name :RX pkt breakdown
Castalia| 1 Failed with NO interference
Castalia| 10 Failed, below sensitivity
Castalia| 86 Failed, non RX state
Castalia| 20 Received with NO interference
Castalia| simple output name :TXed pkts
Castalia| 17 TX pkts
110
4.5.3
111
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é de
communication ainsi que la valeur initiale de l’énergie sont fixes pour
tous les nœuds.
Les deux tableaux suivants donnent plus de détails :
Rayon de transmission 20 m
Enèrgie Initiale
18720 Joules(corresond a 2 batterie AA)
Antennes
Bidirectionnelles
Durée de Simulation
Varie selon le nombre de noeuds
Couche Application Bridge Test
Couche Réseau
WsnSurvey
Couche Phy + MAC ByPassMac
Radio
4.5.3.1
CC1000
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
Sleep
RX
-
0,01 0,2
TX
0,01 -
0,2
Sleep 0,05 0,05 -
4.6
112
Résultats
Tout d’abord nous allons donnés une vue globale sur le comportement des nœuds au sein du réseau et de leurs organisation, ensuite
on 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 la
partie visuelle du comportement du réseau. Nous avons opté à travailler plus sur les données colléctées dans les fichiers trace pour
pouvoir illustré une idée sur l’organisation des capteurs au sein du
réseau pour au moins valider les algorithmes utilisés.
Nous avons simulé un réseau composé de 50 nœuds, déployés
aléatoirement. Suite à ça, Nous avons étudié en détails le fichier trace
gé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 à partir du fichier trace généré.
Nœuds
0
1
2
3
4
5
6
Positions
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
26
Positions
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
113
.
.
Nœuds
43
44
45
46
47
48
49
Positions
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 tel
que :
- Nœuds Représentant : 22,47
- Nœuds Liaison : 5, 43
Nœuds
Voisins
22
4,7,8,9,12,17,20,21,24,26,27,30,38,40,43,44,47,48
47
1,2,3,7,11,13,14,15,18,21,24,26,27,29,37,41,43,45
43
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,
F IG . 4.11 – Déployement Aléatoire.
114
F IG . 4.12 – Organisation des Nœuds.
D’aprés le shéma, on peux voir l’organisation des nœuds au sein
du réseau aprés le Déployement et suite à la reconnaissance du voisinage par l’échange des messages Hello et HelloRep, ainsi avec l’éxécution de l’algorithme "AttribeRole" cité précedemment pour la structuration 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 redondance commence son éxecution.
Suite à ça, les nœuds redondant deviennent innactifs tout en gardant
une couverture du réseau.
Le shéma suivant est la succession des 2précédents, d’où on remarque
que les nœuds redondants sont devenus en mode Sleep.
115
F IG . 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œud
Simple 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 disparaition de ce nœud actif et le réveil d’un autre nœud Simple pour couvrir la zone qui étais couverte auparavant par ce capteur défaillant.
F IG . 4.14 – Reconfiguration suite à une défaillance.
4.6.4
116
Energie Consommée au niveau du réseau
Résultat d’énergie consomée selon La méthode de surveillance adoptée par la distribution d’un nombre différents de nœuds pour une
même topologie ;
– surface de 100*100,
– Energie de 5 mJoule,
– Nombre des nœuds : 20, 50 jusqu’a 100
.
F IG . 4.15 – Energie Consommée en Réseau.
On remarque que la consommation d’enèrgie se double jusqu’à le
triple en augmentant le nombre de nœuds et c’est dûe principalement
aux messages échangés pour la stabilité du réseau.
Les messages de contrôle s’augmentent au profit d’augmentation des
capteurs au réseau pour la bonne organisation du système.
4.6.5
117
Energie Consommée Avec et sans surveillance
D’aprés les histogrammes relevés pour les différents nombre de
nœuds dans un réseau, on peut conclure que l’énèrgie moyenne consommé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 les
nœuds redondants.
Cas 1 : 20 noeuds
F IG . 4.16 – Energie Consommée au niveau des deux Méthodes
Cas 2 : 50 nœuds
F IG . 4.17 – Energie Moyenne Consommée par 50 nœuds
118
Cas 3 : 100 nœuds
F IG . 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èrgie de ce nœud.
F IG . 4.19 – L’énergie restante au niveau d’un nœud Représentant
119
Ces Deux courbes démontre que l’énergie restante au niveau d’un
nœ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 que
la méthode normale dûe a l’envoie des messages inter-clusters avec
un 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çus
par différents nœuds selon leurs rôles où on résume que les nœuds
représentant ont une moyenne plus élevés puisque ils responsable
sur l’organisation du réseau.
F IG . 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’énergie au niveau de quelque nœuds pour les 2 configuration pour une
comparaison d’où on peut conclure que la consommation d’energie
différent et que dans le cas "Avec Surveillance" est beaucoup plus optimale que le cas "Sans Surveillance".
120
F IG . 4.21 – Energie Consommée Avec Surveillance.
F IG . 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 mobilité des nœuds pour voir l’influence du déplacement a l’interieur
du réseau de quelques capteurs sur le réseau.
Notre test concerne la mobilité des nœuds 0,5 et 10. La mobilité se
fait a l’instant 100 pour des distances différentes pour chaque nœuds
avec une vitesse de déplacement de 15. Ainsi nous avons obtenus le
Résultat suivant :
121
F IG . 4.23 – Influence de la Mobilité sur le Réseau.
À travers ce test, on remarque que la mobilité des nœuds à une trés
grande influence sur le réseau dans le cas du taux d’énergie, d’où on
constate que la consommation d’énergie dans un réseau avec mobilité est boucoup plus élevé que dans un réseau sans mobilité est c’est
dûe principalement à cause de la reconfiguration du réseau et l’envoi des messages pour la découverte du nouveau voisinage jusqu’a
la stabilité du réseau.
F IG . 4.24 – Influence de la Mobilité sur le Réseau(Energie Moyenne).
4.6.10
122
Influence du Temps De Simulation
Le temps de simulation joue un rôle important sur le comportement des capteurs, pour cela nous avons joués sur le temps de simulation pour évaluer la durée de fonctionnement du réseau parrapport au taux d’energie.
F IG . 4.25 – Energie Restante par-rapport au temps de Simulation.
F IG . 4.26 – Energie Moyenne Restante.
4.7
123
Conclusion
Notre but, à travers les simulation éffectuées était de tester les performances de notre Approche "Surveillance d’un Réseau" d’où nous
avons pû montrer l’avantage de la méthode distribuée pour assurer
la Tolérance aux pannes avec le traitement de la redondance.
D’un autre côté, cette expérience nous a poussé à connaitre le nouveau Simulateur OMNeT++ et sa plate forme Castalia et nous a permis d’intégré notre approche et d’enrichir le Simulateur avec de nouveaux protocoles.
Suite aux Résultats obtenus, nous avons constater que la méthode
simulé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 recherches
futures sont plus favorisées vers l’approche distribuée avec l’aspect
de la redondance au sein du réseau pour la gestion de la Surveillance.
La consommation énergitique au niveaux des Réseaux de Capteurs est un point sensible, ce qui a motivé les chercheurs a se focaliser plus sur cette problématique pour pouvoir allonger la durée
de 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 surveillance auto-configurable au niveau des nœuds capteurs. Nous avons
simulé un système d’organisation basé sur le principe des Agents
"Nœuds Représentants", "Nœuds Laisions" et "Nœuds Simple". Ces
derniers se ré-organise selon la distribution du réseau d’où nous avons
introduit le concept de Surveillance par Redondances des nœuds et
ce 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 concept
de redondance dans le réseau.
Les résultats de Simulation assez satisfaisants suite à l’utilisation
du nouveau Simulateur OMNeT++ avec la plate forme "Castalia" qui
est plus dédiée au Réseaux de Capteurs. Ce dernier se base sur le
principe des modules. D’aprés nos différents tests éffectués, nous
avons remarqué la diminution d’énergie consommé auprés des nœuds
ce qui donne une longévité du réseau.
125
Tirant profit de l’approche Multi-Agents, Comme perspective de
notre travail, nous envisageons d’étudier l’impact de l’utilisation de
d’autres métriques de consommation d’énergie qui prennent en compte
des informations globales sur le réseau.
Bibliographie
[ABD09] Azadeh Abdolrazaghi, "Unifying Wireless Sensor Network
Simulators", Master’s Degree Project Stockholm, Sweden,2009.
[ALL09] Samira Allam, "Approche multi-agents pour contrôler l’inondation dans un réseau de capteurs", Mémoire de fin d’étude pour
l’obtention du diplôme d’ingénieur d’état en informatique, Ecole
national 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 test
et d’expérimentation", Projet de Master Technologie de l’Internet
1ere année, Université Pau et des pays de l’Adour. 2006.
[BAI10] Nadia Bounegta ,Nacira Aici" Approche déscentralisé pour la
sécurité d’un RCSF", Memoire de fin d’étude pour l’obtention d’un
Diplome d’ingénieur en informatique,Université de BECHAR,
Juin 2010.
[BEC09] Rachid Bechar, "Théorie de la redondance pour la reconfiguration des systèmes - Application aux réseaux de capteur sans fil", Mémoire de magister Ecole doctorale STIC, Université Abdelhamid
Ibn Badis de Mostaganem. Département d’informatique, 2009.
BIBLIOGRAPHIE
127
[BEN09] Djawhara Benchaira, Ahlem Bencheikh, "Sécurité de la déssimination de données dans un réseau de capteur sans fil : cas du protocole
Tiny Diffusion", 2009.
[BDH05] J. Bredin, E. Demaine, M. Taghi Hajiaghayi, and D. Rus,
"Deploying Sensor Networks with Guaranteed Capacity and Fault Tolerance", in the Proceedings of the 6th ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHOC’05), Urbana-Champaign, Illinois, 2005.
[BOU09] Athanassios Boulis. " Castalia : a simulator for Wireless Sensor Networks and Boby Area Networks User’s Manual version 2.1 ",
NICTA, July 2009.
[BOU10] A. Boulis, "Castalia, a simulator for wireless sensor networks
and body area networks, version 3.1", User’s manual, NICTA, December 2010.
C:
[CAM99] Scott Carson, Joseph Macker, "Mobile ad hoc Networking
(MANET) : Routing Protocol Performance Issues and Evaluation
Considerations", RFC 2051, 1999.
[CAS08] Claude Castelluccia, "La sécurité des capteurs et réseaux de capteur", INRIA, 2008.
[CET05] Bilge Cetin, "SIMULATION ENVIRONMENT", Novembre
2005
[CHE08] Yacine Chellal, "Réseaux de capteurs sans fils", Systèmes inté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 survey 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’obtention du diplôme d’ingénieur d’état : "Routage dans les réseaux
de capteurs : Optimisation du protocole Directed Diffusion", Institut
National de formation en Informatique (INI).2006.
[DSR03] Witold Drytkiewicz, Steffen Sroka, Vlado Handziski, Andreas Köpke, Holger Karl, "A Mobility Framework for OMNeT++",
Telecommunication Networks Group Technische Universität Berlin, 2003.
E:
[ELK] N.J El Karaki, A.E Kamel, "Routing technique in wireless sensor
network : a survey", dept. of electrical and computer engineering,
IoWA State University.
F:
[FAV08] Kevin Fall, Kannan Varadhan,"The ns Manual (formerly ns
Notes and Documentation)", The VINT Project May 3, 2008
[FEL07] Rabah Fellouah, "Contribution au Diagnostic de Pannes pour
les Systèmes Différentiellement Plats", THESE présentée en vue de
l’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 analytical 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 diagnostic
pour les systèmes à événements discret-vers la prise en compte des erreurs de modélisation", Thèse de doctorat à l’institut national des
sciences appliquées de Toulouse, Laboratoire CNRS,2007. H :
[HAM07] A.Hamzi, Mémoire de magistère : "Plateforme basée agents
pour l’aide à la conception et la simulation des réseaux de capteurs sans
fil", Institut National de formation en Informatique (INI), 2007.
[HCB00] W. Heinzelman, A. Chandrakasan, H. Balakrishnan, "
Energy-Efficient Communication Protocol for Wireless Micro sensor
Networks", In proc of the Hawaii International Conférence on Systems Science, vol. 8, pp. 8020, January 2000.
[HER05] Uwe Herzog, "Ad hoc Networks :New Life For An Old
Concept", www.eurescom.de, 2005.
[HOB08] Ghaleb Hoblos, "Diagnostic et surveillance des complexes",
Spécialité : Automatique, Docteur de l’université des sciences et
technologies de Lille ;Enseignant : Chercheur à L’ESIGELEC,2008.
[HOW03] Holger K., Willig A., " A short survey of wireless sensor
networks ", Technical university Berlin, Telecommunication Networks Group, 2003.
[HWT05] K. Xu, H. Hassanein, G. Takahara and W. Wang, "Relay
node deployment strategies in heterogeneous wireless sensor networks :
single-hop communication case", in the Proceedings of the IEEE
Global 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 consommation
d’é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 et
le diagnostic des défaillances", Thèse préparée au laboratoire d’analyse et d’architecture des systèmes du CNRS, En vue de l’obtention du titre de docteur de l’institut national des sciences appliqué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 artificielle distribuée et les systèmes multi-agent".
[LIL09] LIANG LI," Implementing Transport Protocol PSFQ in Sensor
Network in Castalia", School of Computer Science, 2009
[LWI07] Marc Löbbers, Daniel Willkomm, "A Mobility Framework for
OMNeT++ User Manual Version 1.0a4", 2007.
M:
[MAK08] Abdallah Makhoul, "Réseaux de capteurs : localisation, couverture et fusion de données.",THÈSE pour obtenir le grade de
DOCTEUR de l’Université de Franche-Comté Spécialité : Informatique préparée au Laboratoire d’Informatique de l’Université de Franche-Comté (LIFC) dans le cadre de l’École Doctorale
Sciences 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", Diplôme d’Etudes Approfondies Contrôle, Signaux et
CommunicationsVanduvre-les-Nancy, février2003.
[MER03] R.Meraihi, "Gestion de la qualité de service et contrôle de topologie dans les réseaux ad hoc", Thèse préstentée pour l’obtention le
grade de docteur de l’Ecole nationale supérieure des télécommunications de paris, 2003.
[MOA08] Sofiane MOAD,Encadrant : Nizar Bouabdallah, "La
consommation d’énergie dans les réseaux de capteurs sans fil" Master
Recherche 2 en Informatique IFSIC-Rennes1, 2008.
[MSK05] C. Mallanda, A. Suri, V. Kunchakarra, S.S. Iyengar*,R. Kannan* and A. Durresi "Simulating Wireless Sensor Networks with
OMNeT++", S. Sastry The University of Akron, Akron, Ohio.
[MSP09] Abdallah Makhoul, Rachid Saadi, Congduc Pham, "Surveillance vidéo sur réseaux de capteurs sans-fils : ordonnancement adaptatif avec prise en compte de la criticité", LIUPPA, Université de Pau
et 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 appliqué au moteur automobile", pour obtenir le grade de Docteur de
L’université de Savoie (Spécialité Electronique, Electrotechnique
et Automatique), 1999.
BIBLIOGRAPHIE
132
[ROM07] Yasser Romdhane, "Evaluation des performances des protocoles SMAC et directed diffusion dans les réseaux de capteurs", Rapport de fin d’étude, Ecole superieure de communication de Tunis,
2007.
S:
[SAY09] Maya Sayad "Energy Efficient Protocol (EEP) : un protocole de
routage efficace en énergie pour réseaux de capteurs sans fil", Mémoire
de fin d’études Pour l’obtention du diplôme d’ingénieur d’état en
informatique ; 2008/2009.
T,U,V :
[TBL08] Andreas TIMM-GIEL, Ken MURRAY, Markus BECKER,
Ciaran LYNCH, Carmelita GÖRG, Dirk PESCH, "Comparative Simulations of WSN", ICT-MobileSummit 2008.
W,X :
[XPM91] Ding X., Frank P.M., "Frequency domain approach and threshold 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 for
Node Placement in Wireless Sensor Networks : A Survey". Article
Dept. of Computer Sc. et Elec. Eng.
[YCC05] T. A. Yang Chair,L. Shih,G. C. Collins, "Applying Image Processing Techniques To Simulate a Self-organized Sensor Network For
Tracking Objects", Master Thesis Defense, Computer Engineering
2005.
BIBLIOGRAPHIE
133
Webographie
[1] http ://www.commentcamarche.net, site de documentation informatique, Septembre 2005.
[2] http ://www.francetelecom.com/rd, site de la division R et D de
Francetelecom, Septembre 2005.
[3] http ://www.epfl.ch, site de l’école polytechnique fédérale de
Lausanne, Septembre 2005.
[4] http ://compilers.cs.ucla.edu/avrora, site d’informations sur le
simulateur 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é de
recherches. Ainsi la simulation est une démarche fréquemment utilisée pour tester et
valider des approches, les environnements de simulation doivent pouvoir soutenir les
diffé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 de
capteurs. Le protocole testé est un protocole basé sur la reconfiguration des nœuds avec
le principe de redondance pour garder une couverture de la zone et assurer une longue
vie du réseau.
La validation de l’approche est considéré suite à l’utilisation du simulateur
OMNeT++ puisque les résultats obtenus ont montré que le concept de l’approche au
niveau de la tolérance aux pannes (avec le principe de réveiller les nœuds endormi en
cas de panne ou d’épuisement d’énergie d’un nœud actif) assure un bon fonctionnement
ainsi 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++ - Thèses et Mémoires

Transcription

Documents pareils

To OLIVER - Seatronic

Pas à pas bracelet brésilien

Collettori solari FR

shenandoah vers la baltique (2)

Catalogue - Mark-10

CHAUFFE-EAU SOLAIRES

Ces vêtements intelligents qui vaincront notre stress

Beechcraft 1900C

Fiche technique de SensorRAE 4R+