départem ent d’in formatique - univ-oran1.dz · 2015. 5. 25. · mouni m.k faf hafid am moham...

S

PrésidenDirecteuExaminaExaminaExaminaExamina

Surveicapt

Sout

nt : ur de thèse : ateur : ateur : ateur : ateur :

DEPA

D

illancteurs

utenue pub

Mr RAHMr HAFMr FEHMr BENMr KECMr BEN

Départem

ARTEME

PBEC

Pour oOCTOR

Spéci

ce dissans

bliquemen

HMOUNI M.KFFAF Hafid AM Moham

NYETTOU MoHAR Bouabd

NAHMED Khe

ment d’In

ENT D’IN

THESEPrésentée pCHAR R

obtenir le dRAT EN alité : Info

Thème

stribufil à

nt le 22/0

Kamel

med ohamed dellah elifa

nformatiq

NFORM

E par : Rachid

diplôme deSCIENC

ormatique

me

uée d’à base

04/2015 d

Professeur àProfesseur àProfesseur àProfesseur àMaitre de coMaitre de co

que

ATIQUE

CES

un rée d’ag

devant le l

à l’Universitéà l’Universitéà l’Universitéà l’USTO onférences àonférences à

E

éseau gents

le jury:

é d’Oran é d’Oran é de Tlemcen

à l’universitéà l’université

de

n

é d’Oran é de Béchar

Remerciements Je voudrais tout d’abord exprimer ma profonde gratitude à mon directeur de thèse

Monsieur HAFFAF Hafid, professeur à l’université d’Oran et directeur du laboratoire LRIIR pour son encadrement et sa conduite de ce travail. Je lui remercie pour le partage de son expertise scientifique, son aide à tous les niveaux, sa disponibilité et sa patience ainsi que la mise à ma disposition tout ce qui est nécessaire pendant la recherche et la rédaction de la présente thèse.

Mon second grand Merci ira aux professeurs qui ont accepté d’être membres de mon

jury de thèse. En particulier Monsieur RAHMOUNI Mustapha Kamel, professeur à l’université d’Oran, qui m’a fait l’honneur d’être président du jury.

Merci à Monsieur FAHEM Mohamed, professeur à l’université de Tlemcen,

Monsieur BENYETTOU Mohamed, professeur à l’université des sciences et technologie d’Oran, Monsieur KECHAR Bouabdellah, maitre de conférences à l’université d’Oran et Monsieur BENAHMED Khelifa, maitre de conférences à l’université de Béchar d’avoir accepté d’évaluer ce travail et faire partie du jury de ma thèse en qualité d’examinateurs.

J’exprime aussi tous mes sincères remerciements à Monsieur PHAM Congduc,

professeur à l’université de Pau et des pays de l’Adour en France, de m’avoir accueilli au laboratoire LIUPPA, pour son aide et tous ses précieux conseils et orientations. Sans oublier Monsieur GOUARDERES Eric du même laboratoire.

Je tiens à remercier infiniment tous les membres du laboratoire LRIIR de

l’université d’Oran et les collègues de l’université de Chlef pour leur soutien.

Mes profonds remerciements à ma femme de son aide et soutien tout au long de la réalisation de ce travail.

Merci à tous.

Je dédié ce travail à l’âme de mon père,

à ma mère,

à mes frères et sœurs,

à ma femme et mes enfants,

et à tous mes amis.

Rachid.B

i

Résumé Dans cette thèse, on présente un état de l'art sur les travaux de surveillance des

réseaux de capteurs sans fil en particulier ceux qui sont basés sur la technologie multi-agent où l'objectif principal est l'adaptation de l'architecture logicielle et l'organisation du réseau pour optimiser ses performances et sa surveillance. Nous explorons ensuite les problèmes liés au contrôle de topologie qui est un aspect relevant de la surveillance, ainsi que les travaux dans ce domaine et l'apport d'exploitation des systèmes multi-agent.

Comme contribution dans ce domaine, on propose un algorithme distribué de tolérance aux pannes par contrôle de topologie dans les réseaux de capteurs sans fil. Notre proposition consiste à utiliser un mécanisme de sélection du parent de chaque nœud capteur ou le saut suivant vers la station de base lors d'un transfert de paquets. Le procédé de changement de parent est basé sur un degré de tolérance aux pannes calculé à chaque fois par le nœud lui même en coopération avec ses voisins et en se basant sur plusieurs paramètres tels que le nombre de sauts, l'énergie et la qualité du lien en question. Les résultats de simulation montrent que cette méthode de changement de parent permet d'avoir un réseau tolérant aux pannes avec une durée de vie optimisée comparé avec le protocole dit arbre de collecte de données.

Vu le principe distribué de l’algorithme proposé et les avantages offerts par les systèmes multi-agents en termes de fonctionnement coopératif et émergent, on propose aussi une architecture multi-agent avec mise en ouvre sur une plateforme multi-agent pour réseau de capteurs sans fil. Ce qui nous a permis d’étudier l’apport de l’exploitation de cette technologie qui permet de faciliter le déploiement des applications sur ce type de réseaux avec un comportement dynamique.

Mots clés : Réseaux de capteurs sans fil, Systèmes multi-agents, Surveillance, Contrôle de topologie.

ii

Abstract

In this thesis, we present a state of the art on wireless sensor networks monitoring and in particular works which are based on multi-agent technology where the main objective is to have adapted software architecture and best network organization in order to optimize its performance and monitoring. Then, we explore the topology control issues which is an aspect related to monitoring, related works and advantage of using multi-agent systems.

As contribution in this area, we propose a distributed fault tolerance algorithm for topology control in wireless sensor networks. Our proposal is to use a mechanism of parent’s node selection or the next hop to the base station when transferring packets. The parent change process is based on a degree of fault tolerance calculated each time by the node itself in cooperation with its neighbors and based on several parameters such as the number of hops, energy and quality of the link in question. Simulation results show that this method of parent change gives a fault tolerant network with optimized lifetime compared with the collection tree protocol.

As soon as the proposed algorithm has a distributed principle and multi-agent systems offer many advantages in terms of cooperative and emergent operation, we also propose a multi-agent architecture with implementation in a multi-agent platform for wireless sensor networks which allowed us to study the contribution of using this technology to facilitate the applications deployment with dynamic behavior.

Keywords : Wireless sensor networks, Multi-agent systems, Monitoring, Topology control.

iii

Table des matières Introduction générale 1. Introduction ............................................................................................................... 1 2. Mise en contexte ........................................................................................................ 2 3. Organisation de la thèse ............................................................................................ 2

Chapitre 1 : Surveillance distribuée des RCSF

1. Introduction ............................................................................................................... 4 2. Les réseaux de capteurs sans fil ................................................................................. 4

2.1 Le nœud capteur ................................................................................................. 5 2.2 Réseau de capteurs sans fil ................................................................................. 6 2.3 Architecture en couches des réseaux de capteurs sans fil ................................... 7 2.4 Applications des RCSF ....................................................................................... 8 2.5 Caractéristiques des RCSF ................................................................................. 9 2.6 Problèmes étudiés en RCSF ............................................................................. 11

3. Surveillance des réseaux de capteurs sans fil ........................................................... 12 3.1 Définitions ........................................................................................................ 12 3.2 Aspects relevant de la surveillance d’un RCSF ................................................ 14

3.2.1 Déploiement d'un RCSF ............................................................................ 14 3.2.2 Localisation ................................................................................................ 15 3.2.3 La connectivité ........................................................................................... 16 3.2.4 La couverture ............................................................................................. 17 3.2.5 Couverture et connectivité ......................................................................... 17 3.2.6 Tolérance aux pannes ................................................................................ 18 3.2.7 Durée de vie ............................................................................................... 19 3.2.8 La redondance des nœuds .......................................................................... 19 3.2.9 Contrôle de la topologie ............................................................................. 20

4. Techniques utilisées pour la surveillance des RCSF ................................................ 20 4.1 Techniques de surveillance centralisée .............................................................. 21 4.2 Techniques de surveillance distribuée ............................................................... 22

5. Modélisation d’un RCSF ......................................................................................... 24 5.1 Nécessité d’un modèle ....................................................................................... 24 5.2 Définitions et notations .................................................................................... 25 5.3 Réduction du degré d'un graphe ...................................................................... 26

5.3.1 Graphe RNG .............................................................................................. 26 5.3.2 Graphe de Gabriel ..................................................................................... 27

6. Conclusion ............................................................................................................... 28

iv

Chapitre 2 : Contrôle de topologie des RCSF

1. Introduction ............................................................................................................. 29 2. Définitions ............................................................................................................... 30 2.1 Topologie ....................................................................................................... 30 2.2 Contrôle de topologie .................................................................................... 30

2.3 Objectifs de contrôle de topologie .................................................................... 31 2.4 Défis du contrôle de topologie .......................................................................... 31

3. Déférentes topologies des RCSF .............................................................................. 32 3.1 Topologie plate ................................................................................................. 33 3.2 Topologie par clusters ....................................................................................... 35

3.2.1 Définition ................................................................................................... 35 3.2.2 Formation de clusters ................................................................................ 36 3.2.3 Communication intra-cluster et inter-cluster ............................................. 36 3.2.4 Maintenance des clusters ........................................................................... 36 3.2.5 Quelques algorithmes de clustering pour RCSF ........................................ 36

3.3 Topologie à base de chaines .............................................................................. 37 3.4 Topologie à base d’arbre ................................................................................... 38

4. Techniques de contrôle de topologie des RCSF ...................................................... 39 4.1 Ajustement de la portée radio .......................................................................... 40 4.2 Changement d'états des nœuds ........................................................................ 41 4.3 Structures en hiérarchie .................................................................................... 42 4.4 Approches hybrides .......................................................................................... 44

5. Travaux existants .................................................................................................... 44 6. Conclusion ............................................................................................................... 47

Chapitre 3 : Utilisation des SMA dans les RCSF

1. Introduction ............................................................................................................. 48 2. Les systèmes multi-agents ....................................................................................... 49

2.1 Définitions ........................................................................................................ 49 2.1.1 Un agent .................................................................................................... 49 2.1.2 Un système multi-agent ............................................................................. 51

2.2 Caractéristiques des SMA ................................................................................. 51 2.3 Types d’agents .................................................................................................. 54

3. Plateformes logicielles pour les SMA ....................................................................... 54 3.1 Qu’est ce qu’une plateforme SMA .................................................................... 54 3.2 Quelques plateformes SMA ............................................................................... 55

4. Application des SMA pour les RCSF ...................................................................... 56 4.1 Motivations ....................................................................................................... 56 4.2 Différentes Manièresd’introduire un SMA dans un RCSF ............................... 57

4.2.1 Nœuds capteurs comme agents .................................................................. 57

v

4.2.2 Agents fonctionnels .................................................................................... 58 4.2.3 Agents mobiles ........................................................................................... 58

5. Travaux SMA pour les RCSF ................................................................................. 58 5.1 Architecture logicielle des applications et services ........................................... 58 5.2 Organisation du réseau, clustering et coopération ............................................ 60 5.3 Routage ............................................................................................................. 61 5.4 Monitoring et mobilité ...................................................................................... 62 5.5 Sécurité ............................................................................................................. 63

6. Travaux SMA pour le contrôle de topologie ........................................................... 64 7. Plateformes SMA pour les RCSF ............................................................................ 65 8. Conclusion ............................................................................................................... 68

Chapitre 4 : Proposition d’une approche distribuée pour le contrôle de topologie d’un RCSF

1. Introduction ............................................................................................................. 69 2. La problématique .................................................................................................... 69 3. Travaux existants .................................................................................................... 71 4. Détails sur le protocole CTP ................................................................................... 72

4.1 Définition .......................................................................................................... 72 4.2 Structure du protocole CTP ............................................................................. 72

4.2.1 Routing Engine (RE) ................................................................................. 72 4.2.2 ForwardingEngine(FE) .............................................................................. 72 4.2.3 Link Estimator (LE) .................................................................................. 73

4.3 Structure des donnée en CTP .......................................................................... 73 4.3.1 La trame de données .................................................................................. 73 4.3.2 Structure de routage CTP ......................................................................... 74

5. Proposition d’une amélioration du CTP ................................................................. 76 5.1 Modèle du réseau .............................................................................................. 76 5.2 Construction de topologie ................................................................................. 77 5.3 Contrôle de topologie ........................................................................................ 77 5.4 Structure des trames ......................................................................................... 79

6. Etude de performances par simulation .................................................................... 81 6.1 Pour quoi simuler ............................................................................................. 81

6.1.1 Le simulateur J-Sim ................................................................................... 81 6.1.2 Le simulateur NS ....................................................................................... 81 6.1.3 OPNET ...................................................................................................... 82 6.1.4 OMNET++ ............................................................................................... 82

6.2 Choix d’un simulateur ...................................................................................... 82 7. Environnementde simulation ................................................................................... 83

7.1 Présentation ...................................................................................................... 83 7.2 Méthodologied’utilisation ................................................................................. 83 7.3 Modèle de Castalia ........................................................................................... 85

8. Détails de l'implémentation ..................................................................................... 86

vi

9. Paramètres d’évaluation .......................................................................................... 88 9.1 La durée de vie ................................................................................................. 88 9.2 Changement de parent ..................................................................................... 88 9.3 Energie consommée ........................................................................................... 89 9.4 Hypothèses ........................................................................................................ 89

10. Résultats et analyse ................................................................................................. 89 11. Conclusion ............................................................................................................... 94

Chapitre 5 : Proposition d’une architecture multi-agent pour le contrôle de topologie d’un RCSF

1. Introduction ............................................................................................................. 95 2. Cycle de vie d’un nœud capteur à base d’agent ...................................................... 95 3. Modèle du système multi-agent proposé ................................................................. 96

3.1 Déploiement des agents .................................................................................... 96 3.2 L’agent de contrôle de topologie ATCagent ..................................................... 97

4. Les outils utilisés ..................................................................................................... 97 4.1 Aperçu sur les capteurs Sun Spots ................................................................... 97

4.1.1 Les capteurs ............................................................................................... 97 4.1.2 La machine virtuelle Squawk ..................................................................... 98 4.1.3 Manipulation des SunSpots ....................................................................... 99

5. Indications sur l’implémentation de notre algorithme en java .............................. 100 6. Intégration du fonctionnement multi-agent .......................................................... 101

6.1 Choix de la plateforme multi-agent ................................................................ 101 6.2 Structure d’un projet MAPS .......................................................................... 102

7. Implémentation du SMA ....................................................................................... 102 7.1 Scénario de déploiement ................................................................................. 102 7.2 Le plan d’exécution ........................................................................................ 103 7.3 Implémentation de l’agent ATCagent ............................................................ 103 7.4 Implémentation de la MIDlet ......................................................................... 105 7.5 Déploiement et exécution ............................................................................... 105

8. Résultats ................................................................................................................ 106 9. Conclusion ............................................................................................................. 109

Conclusion générale …………..………………………………….…..…………….………………. 110 Références bibliographiques……………….…..……………………….….……………………. 112

vii

Liste des figures Figure I.1 : Les composants d’un nœud capteur sans fil. ................................................ 5 Figure I.2 : Architecture globale d'un réseau de capteurs sans fil [AKY-02] .................. 7 Figure I.3 : La pile protocolaire des RCSF ...................................................................... 8 Figure I.4 : Une taxonomie des applications RCSF [RAU-14] ........................................ 9 Figure I.5. Approche unifiée pour la surveillance ........................................................... 13 Figure I.6 : Principe de surveillance d'un RCSF ........................................................... 14 Figure I.7 : Triangulation en 3 dimensions [PARR-05]. ................................................ 15 Figure I.8 : Connectivité d'un RCSF ............................................................................ 16 Figure I.9 : Influence de la valeur du rayon de transmission sur la connectivité d'un RCSF .............................................................................................................................. 16 Figure I.10 : Couverture de région (a) et couverture de point (b) ............................... 17 Figure I.11 : Modèle géométrique des deux régions caractéristiques d’un capteur ........ 18 Figure I.12 : Décomposition des approches tolérantes aux pannes................................ 18 Figure I.13 : Diagramme de réduction du degré d'un graphe ........................................ 26 Figure I.14 : Principe des voisins RNG ......................................................................... 27 Figure I.15 : Le graphe GDU d'un RCSF et son graphe RNG correspondant .............. 27 Figure I.16 : Principe d'élimination pour construire un graphe de Gabriel. ................. 27 Figure II.1 : Une taxonomie des travaux de contrôle de topologie des RCSF selon leurs objectifs [LI-13]. ............................................................................................................. 31 Figure II.2 : Topologie plate .......................................................................................... 34 Figure II.3 : Topologie à base de clusters ...................................................................... 35 Figure II.4 : Une topologie à base de chaine ................................................................. 38 Figure II.5 : Topologie à base d’arbre ........................................................................... 39 Figure II.6 : Classification des techniques de contrôle de topologie [SAN-05]............... 40 Figure II.7 : Contrôle de topologie par ajustement de la portée radio .......................... 41 Figure II.8: Transitions d’état d’un nœud dans GAF .................................................... 42 Figure II.9 : Structure hiérarchique en clusters ............................................................. 43 Figure II.10 : Structure hiérarchique en chaines ........................................................... 43 Figure II.11: Structure hiérarchique en clusters et en chaines ....................................... 44 Figure II.12 : Principe de l’algorithme CLUSTERPOW .............................................. 44 Figure III.1: Principe général d’un agent ....................................................................... 50 Figure III.2 : Emergence dans les SMA ......................................................................... 53 Figure III.3 : Le modèle du SMA utilisé dans [Xue-07-a] .............................................. 61

viii

Figure III.4: Un SMA pour l’allocation des tâches [HUA-09] ........................................ 63 Figure III.5: Construction de route entre deux nœuds S et D [MUR-12] ...................... 65 Figure III.6 : Architecture d’Agilla ................................................................................ 66 Figure III.7 : Architecture d’ActorNet .......................................................................... 67 Figure III.8 : Architecture de la plateforme MAPS ....................................................... 67 Figure IV.1: Flux des messages et interactions des modules dans le protocole CTP..... 73 Figure IV.2: Structure d’un paquet de données en CTP ............................................... 74 Figure IV.3: Le format de la trame de routage dans CTP ............................................ 75 Figure IV.4: Structure des paquets en CTP .................................................................. 75 Figure IV.5: Modèle du réseau ....................................................................................... 76 Figure IV.6: Le format de la nouvelle trame de routage ................................................ 79 Figure IV.7: Principe de fonctionnement de la solution proposée .................................. 80 Figure IV.8 : Description NED d‘un réseau avec Ompnet++ ...................................... 84 Figure IV.9: Architecture du module SensorNetwork de Castalia ................................. 85 Figure IV.10: Arborescence de Castalia ......................................................................... 86 Figure IV.11: Illustration de fonctionnement ................................................................. 90 Figure IV.12. Relation entre la densité du réseau et le processus d'initialisation .......... 91 Figure IV.13: Impact sur la consommation d’énergie .................................................... 92 Figure IV.14: Impact sur la durée de vie ....................................................................... 92 Figure IV.15: Changement de parents dans le temps .................................................... 93 Figure IV.16: Changement de parents selon la taille du réseau ..................................... 93 Figure V.1 : Diagramme d’états de l’agent ATCagent.................................................. 97 Figure V.2 : Capteurs Sun Spot .................................................................................... 98 Figure V.3 : Le tableau de bord SunSpotManager ........................................................ 99 Figure V.4 : L’émulateur de réseau Solarium ................................................................ 99 Figure V.5 : Interaction entre les composants d’un RCSF dans Solarium .................. 100 Figure V.6 : les Classes principales adaptées ............................................................... 101 Figure V.7 : Structure typique d’un projet MAPS ...................................................... 102 Figure V.8 : Architecture logicielle après déploiement du SMA ................................. 103 Figure V.9 : Diagramme de plan de l’agent ATCagent............................................... 103 Figure V.10 : Coût de l’opération du déploiement SMA ............................................. 107 Figure V.11 : Impact du paramètre de contrôle .......................................................... 107 Figure V.12 : Suivi de la consommation d’un capteur ................................................ 108

ix

Liste des tableaux

Tableau II.1 : Exemples de protocoles et leurs topologies correspondantes .................. 33 Tableau III.1 : Comparaison entre les capteurs Mica2 et TelosB ................................. 66 Tableau IV.1: paramètres de simulation ........................................................................ 89 Tableau V.1: Quelques paramètres de simulation ........................................................ 106

Introduction générale

1


1. Introduction

Depuis quelques années, l’observation et le contrôle de phénomènes physiques ont été rendus possibles grâce à l’apparition de Réseaux de Capteurs Sans Fil (RCSFs). Ces derniers suscitent un grand intérêt vus les nombreux avantages qu’ils apportent mais souffrent, néanmoins pour l’instant, de diverses limitations. De plus, il est difficile, voire même impossible, de remplacer les nœuds ou leurs batteries car l’environnement de déploiement est soit souvent hostile ou inaccessible, soit que le réseau lui-même est très dense (comprenant des milliers de nœuds).

La nature ad hoc des réseaux de capteurs sans fil et le coût qui est en diminution continue ainsi que la facilité de déploiement et d’utilisation sont des facteurs qui ont contribué à l'apparition d'une multiplicité d'applications exploitant cette technologie.

La recherche dans ce domaine est active puisque les RCSF posent aussi des problèmes faisant impliquer plusieurs disciplines pour les résoudre. En plus des problèmes étudiés dans les réseaux informatiques habituels (filaires et sans fil) qui s’intéressent généralement au routage, localisation, transfert, contrôle, surveillance et sécurité, les RCSF présentent le problème de la consommation énergétique qui doit être optimisée afin d’avoir des réseaux fiables, tolérants aux pannes et avec une meilleure qualité de service.

Les systèmes multi-agents (SMA) ont un principe de fonctionnement qui peut être facilement adapté et intégré dans les systèmes complexes grâce à leur démarche totalement décentralisée. Ils peuvent être utilisés dans la modélisation des phénomènes dont le comportement global émerge des comportements locaux des entités composantes du système en question. Ces composantes ont la capacité de percevoir, traiter, agir et réagir dans leur environnement.

La structure des réseaux de capteurs sans fil, leur capacité en traitement distribué et leur complexité quand le nombre de nœuds augmente sont tous des facteurs qui nous conduisent à penser d’exploiter les évolutions faites dans le domaine des systèmes multi-agents pour améliorer les performances de ces réseaux et simplifier leur conception.

En effet ces dernières années, plusieurs travaux de recherche s’intéressent à cette technique. Les approches multi-agents pour les RCSF interviennent dans plusieurs niveaux et aspects de fonctionnement. On trouve donc des travaux qui proposent des architectures logicielles des applications et des services, d’autres s’intéressent à l’organisation du réseau et la coopération entre les nœuds. Le clustering présente une préoccupation dominante pour cette catégorie. Un nombre important de travaux basés


2

sur les agents traitent les problèmes de routage dans les RCSF avec différents domaines d’application. Enfin le monitoring et la mobilité font aussi objet de plusieurs travaux où l’utilisation des principes bio-inspirés semble intéressante avec les systèmes multi-agents pour résoudre les problèmes liés à la mobilité et le scheduling des tâches.

2. Contribution

La surveillance ou le monitoring est un ensemble de techniques utilisées pour augmenter les performances d’un RCSF, optimiser la durée de vie et garantir une tolérance aux pannes en exploitant tous les paramètres réseaux qui permettent d'éviter ou détecter les anomalies de fonctionnement.

Les limites matérielles du nœud et la variation de la qualité des liaisons sans fil sont des grands défis pour fournir une haute disponibilité des services, en particulier dans les applications des RCSF, où il est nécessaire de créer des mécanismes qui permettent d'identifier et d'atténuer ou de résoudre le problème du trou de l'énergie. Le trou de l'énergie peut être causé par la congestion ou la sur-utilisation de chemin menant à la mort prématurée des nœuds.

Le contrôle de topologie consiste à exploiter des paramètres réseau pour générer ou maintenir une topologie qui garantit un bon fonctionnement et une meilleure durée de vie au réseau. On trouve dans la littérature plusieurs travaux sur le contrôle de topologie des réseaux de capteurs, mais peu de travaux qui utilisent la technologie agent dans ce domaine. Pour cela, nous proposons dans cette thèse une approche distribuée pour le contrôle de topologie dans un réseau de capteurs sans fil afin d’optimiser la durée de vie et la tolérance aux pannes en plus d’une architecture multi-agent pour la mise en œuvre de cette méthode.

Notre travail consiste à utiliser plusieurs paramètres réseau qui concernent le nœud et son voisinage pour donner à chaque nœud une métrique que nous appelons degré de tolérance. Cette métrique est calculée par le nœud lui-même en coopération avec ses voisins. Lors d’un transfert de paquets, ce degré de tolérance sera utilisé pour choisir les nœuds qualifiés à ce transfert afin de garantir une meilleure durée de vie avec tolérance aux pannes sans affecter la qualité de service. Ces nœuds sont dits aussi parents des nœuds qui ont effectué la sélection. Le calcul de ce degré est basé principalement sur la densité du réseau c'est-à-dire le nombre et la disposition des nœuds, l'énergie disponible, la cadence et la taille des données échangées, et enfin la fiabilité du canal de transmission.

3. Organisation de la thèse

Cette thèse qui s’intéresse à l’utilisation des systèmes multi-agents pour la surveillance d’un réseau de capteurs sans fil est constituée de cinq chapitres. Dans le premier chapitre, on détaillera les aspects de la surveillance d’un réseau de capteurs, les techniques utilisées et les travaux existants pour chaque type. Le deuxième chapitre sera consacré à un type particulier de monitoring, c’est le contrôle de topologie qui est un facteur clé pour l’optimisation de la durée de vie des RSCFs. Le troisième chapitre en relation directe avec notre contribution, est un état de l’art sur l’utilisation des systèmes multi-agents pour la surveillance des RCSFs, en particulier dans le domaine de ses applications en topologie.


3

Après une étude bibliographique détaillée, on proposera dans le quatrième chapitre une nouvelle approche pour le contrôle de topologie des RCSF avec étude et évaluation des performances. Cette première évaluation est basée sur une implémentation dans un simulateur de réseaux de capteurs sans considération de l’aspect multi-agents. Enfin, on détaillera dans le cinquième chapitre la proposition d’une architecture multi-agents comme mise en œuvre de l’algorithme distribué proposé avec l’utilisation d’une plateforme dédiée à cette technologie. Enfin, une conclusion générale synthétise l’ensemble de ce travail, tout en ouvrant la voie à de travaux futurs.

Chapitre 1 Surveillance distribuée des RCSF 1. Introduction ............................................................................................................... 4 2. Les réseaux de capteurs sans fil ................................................................................. 4

2.1 Le nœud capteur ................................................................................................. 5 2.2 Réseau de capteurs sans fil ................................................................................. 6 2.3 Architecture en couches des réseaux de capteurs sans fil ................................... 7 2.4 Applications des RCSF ....................................................................................... 8 2.5 Caractéristiques des RCSF ................................................................................. 9 2.6 Problèmes étudiés en RCSF ............................................................................. 11

3. Surveillance des réseaux de capteurs sans fil ........................................................... 12 3.1 Définitions ........................................................................................................ 12 3.2 Aspects relevant de la surveillance d’un RCSF ................................................ 14

3.2.1 Déploiement d'un RCSF ............................................................................ 14 3.2.2 Localisation ................................................................................................ 15 3.2.3 La connectivité ........................................................................................... 16 3.2.4 La couverture ............................................................................................. 17 3.2.5 Couverture et connectivité ......................................................................... 17 3.2.6 Tolérance aux pannes ................................................................................ 18 3.2.7 Durée de vie ............................................................................................... 19 3.2.8 La redondance des nœuds .......................................................................... 19 3.2.9 Contrôle de la topologie ............................................................................. 20

4. Techniques utilisées pour la surveillance des RCSF ................................................ 20 4.1 Techniques de surveillance centralisée .............................................................. 21 4.2 Techniques de surveillance distribuée ............................................................... 22

5. Modélisation d’un RCSF ......................................................................................... 24 5.1 Nécessité d’un modèle ....................................................................................... 24 5.2 Définitions et notations .................................................................................... 25 5.3 Réduction du degré d'un graphe ...................................................................... 26

5.3.1 Graphe RNG .............................................................................................. 26 5.3.2 Graphe de Gabriel ..................................................................................... 27

6. Conclusion ............................................................................................................... 28


4

1. Introduction

Depuis plusieurs décennies et avec l’arrivée d’internet, les technologies des télécommunications ont connu une réelle révolution qui a porté des progressions importantes dans le domaine des infrastructures des réseaux. Dans ce contexte, plusieurs applications ont passé du monde câblé à celui sans fil vu les avantages offerts tels que la diminution du coût et la facilité de déploiement.

Les réseaux Ad hoc forment une famille de cette technologie sans fil qui a enregistré une préoccupation remarquable du grand public et notamment le domaine de la recherche scientifique. Cela a conduit à l’apparition de plusieurs groupes de recherche spécialisés dans ce domaine tels que l'IETF (Internet Engineering Task Force) qui a créé un groupe dénommé MANET (Mobile Ad hoc Networks) ainsi que le grand nombre des domaines d’applications.

Pour la collecte d’information, il existe un type particulier de réseaux Ad hoc, se sont les réseaux de capteurs sans fil qui utilisent des capteurs de nouvelles générations dotés de circuits radio leur permettant de transmettre et de recevoir de l'information. De plus, ils disposent de capacité de mémorisation et d'une puissance de calcul permettant de réaliser quelques traitements sur les informations captées ou sur la topologie du réseau. Ainsi, des réseaux de capteurs peuvent se former avec une capacité de s'auto-configurer. En conséquence, un grand nombre d'applications ont pu se développer en tirant profit de ce nouvel environnement de capteurs.

La surveillance en continu de l'évolution d’un réseau de capteurs sans fil à travers des données quantifiables et qualifiables permet ainsi de prévenir un dysfonctionnement avant qu'il n'arrive et d'écarter les fausses alarmes qui peuvent empêcher ou au moins ralentir le bon fonctionnement surtout dans le cas des applications en temps réel. Pour un réseau de capteurs sans fil, il s’agit de mettre en œuvre des méthodes automatiques et sans intervention humaine qui permettent d’avoir un réseau opérationnel en contenu.

Il existe deux manières d’implanter un mécanisme de surveillance dans un réseau de capteurs : les approches centralisées qui sont basées sur une seule station pour contrôler tout le réseau quelque soit sa taille et les approches décentralisées ou distribuées qui exploitent les capacités de chaque capteur pour contribuer au contrôle du réseau d’une manière locale ce qui présente un gain au sens de la bande passante et du temps nécessaire.

Dans ce chapitre, on présente un aperçu sur les réseaux de capteurs sans fil et leurs problèmes et en particulier ceux liés à la surveillance dont une importance est donnée aux techniques de surveillance distribuée avec un état de l’art sur les travaux existants dans ce domaine.

2. Les réseaux de capteurs sans fil

Les réseaux de capteurs sans fil (RCSF) – en anglais Wireless Sensor Networks (WSN) - sont considérés comme un type spécial de réseaux ad hoc. Ils sont basés sur l'effort collaboratif d'un grand nombre de nœuds qui opèrent d'une manière autonome et complètement transparente pour l'utilisateur. Ces nœuds, communément appelés capteurs, sont des dispositifs de petite taille qui intègrent principalement des unités de calcul et de communication sans fil en plus des unités de captage et de gestion d’énergie. Cette dernière est une ressource critique vu que le capteur sans fil est


5

alimenté par une batterie à autonomie limitée dont la recharge est souvent impossible. Le rôle de ces capteurs consiste à détecter un phénomène dans l’environnement adjacent, de traiter les données captées et enfin envoyer le résultat de l'analyse via un support de transmission sans fil. La position de ces nœuds n'est pas obligatoirement prédéterminée. Ils sont dispersés aléatoirement à travers une zone géographique, appelée champ de captage ou zone d’intérêt, qui définit le terrain d'intérêt pour le phénomène à observer. Les données captées sont acheminées grâce à un routage multi-saut à un nœud considéré comme un "point de collecte", appelé nœud puits (ou Sink) ou encore station de base. Ce dernier peut être connecté à l'utilisateur du réseau via Internet ou via un satellite. Ainsi, l'usager peut adresser des requêtes aux autres nœuds du réseau, précisant le type de données requises et récolter les données environnementales captées par le biais du nœud puits.

2.1 Le nœud capteur

Un capteur sans fil, « wireless sensor » en anglais, est fabriqué de telle sorte qu'il peut à lui seul assurer les tâches d'acquisition et de traitement de l'information en plus de la communication avec les autres capteurs. C’est un petit dispositif électronique composé de quatre unités comme le monte la figure ci après:

Figure I.1 : Les composants d’un nœud capteur sans fil.

Unité de captage (Sensing unit) : elle est composée de deux sous-unités, le capteur proprement dit et un convertisseur analogique/numérique appelé ADC (Analog to Digital Converter). Le capteur est chargé de détecter les caractéristiques et les variations du milieu ambiant. Ils sont utilisés pour une grande variété de phénomènes physiques (magnétiques, thermiques, visuels, acoustiques ...). Ils répondent à une variation des conditions d'environnement par une variation de caractéristiques électriques. Ce sont ces variations d'ordre électrique qui sont par la suite converties par

Unité d'énergie (Batterie)

ADC

Capteur Processeur

Mémoire

Transceiver

Module (RF)

Unité de captage unité de traitement

Système de localisation de l’environnement

Système de mobilité

Générateur de puissance


6

le convertisseur analogique/numérique pour pouvoir être traitées par l'unité de traitement [KAC-09].

Unité de traitement (Processing unit) : les données captées sont communiquées au processeur et stockées dans la mémoire. L’unité de traitement est composée d'un processeur et d'un système d'exploitation spécifique. Elle acquiert les informations en provenance de l'unité d'acquisition et les envoie à l'unité de transmission. Pour cela, elle possède deux interfaces : une avec le module d'acquisition et une autre avec le module de transmission [CIS-12].

Unité de communication (Transceiver unit) : C'est un composant classique utilisé dans les réseaux sans fil. Elle est composée d’un émetteur/récepteur qui est un module radio responsable de toutes les émissions et réceptions de données.

Unité d’énergie (Power unit) : un capteur est muni d'une ressource énergétique, souvent une batterie. Cependant, en conséquence de sa taille réduite, la batterie dont il dispose est limitée et généralement irremplaçable. L'unité de contrôle d'énergie constitue donc l'un des systèmes les plus importants. Elle est responsable de répartir l'énergie disponible aux autres modules et de réduire les dépenses en mettant en veille les composants inactifs par exemple. D’autre part, les unités d’énergie peuvent être supportées par des photopiles qui permettent de convertir l’énergie lumineuse en courant électrique. Sinon et le plus souvent, il s'agit d'une pile AA d'environ 2.2 - 2.5 Ah fonctionnant à 1.5 V.

En plus de ces composants de base, il existe des nœuds capteurs qui sont dotés d'autres unités supplémentaires comme un système de localisation (GPS : Global Positioning System) ou une unité de mobilité, etc. On trouve dans l’annexe A un tableau qui montre quelques exemples de modèles de capteurs sans fil et leurs caractéristiques.

Cette configuration permet à un nœud capteur d'acquérir le type d'information pour le quel il est conçu et de la transmettre vers la station de contrôle à travers ses voisins. La présence d'une unité de traitement permet d'effectuer un nombre considérable d'opérations qui sont nécessaires pour la préparation de l'information avant sa transmission (agrégation, compression, sécurité,…), calcul des chemins optimaux en fonction des nœuds capteurs voisins (le routage), traitements relatifs à l'optimisation de la consommation énergétique, comme on peut imaginer d'autres protocoles exploitant ces capacités de traitement d'un capteur sans fil.

Donc un capteur est un composant physique, capable d'accomplir trois tâches complémentaires: le relevé d'une grandeur physique, le traitement éventuel de cette information, et la communication avec d’autres capteurs [THOM-05].

2.2 Réseau de capteurs sans fil

Un réseau de capteurs sans fil est constitué de plusieurs nœuds appelés nœuds capteurs ou tout simplement capteurs, permettant de capter et collecter des événements, d’effectuer des traitements et de transmettre les informations recueillies dans différents environnements. Ces nœuds peuvent avoir des positions fixes ou bien être déployés aléatoirement pour surveiller l’environnement. Les communications dans un réseau de capteurs se font souvent d’une manière multi-saut. L’écoulement des données se termine vers des nœuds spéciaux appelés nœuds-puits ou stations de base


7

(Sink). Ces nœuds-puits sont des bases de contrôle qui possèdent plus de ressources matérielles et permettent de collecter et stocker les informations issues des capteurs [MAK-08].

Le nœud puits est responsable, en plus de la collecte des rapports, de la diffusion des demandes sur les types de données requises par les capteurs via des messages de requêtes. Notons qu’un réseau de capteurs peut contenir plusieurs nœuds puits diffusant des intérêts différents. Ainsi, l'usager peut adresser des requêtes aux autres nœuds du réseau, précisant le type de données requises et récolter les données environnementales captées par le biais du nœud puits.

Dans un réseau de capteurs sans fil, des points d'agrégation peuvent être introduits. Cela a pour but de résoudre le problème de la consommation d'énergie [MAK-08]. En effet, la communication entre les nœuds consomme beaucoup d'énergie. Ainsi ceci a pour but de réduire cette communication entre les nœuds en privilégiant celle entre les points d'agrégation. Un type de regroupement appelé "clustering" peut aussi être appliqué dans ce cas. Un chef de cluster joue le rôle d'un point d'agrégation. La communication au sein d'un groupe doit passer à travers le chef, qui ensuite la transmet à un autre chef du cluster voisin jusqu'à ce qu'il atteigne sa destination. La figure I.2 présente une architecture simple de réseau de capteurs sans fil.

Figure I.2 : Architecture globale d'un réseau de capteurs sans fil [AKY-02]

2.3 Architecture en couches des réseaux de capteurs sans fil

Vu le grand nombre de fonctionnalités implémentées dans les réseaux de capteurs, l'architecture de ces derniers est particulièrement complexe. L'architecture en couches dans les RCSF comme dans les réseaux en général, permet de réduire cette complexité en décomposant les processus qui y sont mis en œuvre. Un tel découpage permet au réseau de traiter en parallèle les fonctions attribuées aux différentes couches.

Cette architecture qui est représentée sur la figure I.3 tient compte des contraintes liées au routage et à la consommation d'énergie. Il est clair que c'est une architecture qui met en œuvre le modèle de référence des communications réseau dit OSI (Open System Interconnexion) avec une réduction de couches selon le type et les caractéristiques des réseaux de capteurs sans fil.


8

Figure I.3 : La pile protocolaire des RCSF

Le découpage consiste en une couche physique, une couche liaison de données, une

couche réseau, une couche transport, une couche application en plus d’un plan de gestion de l'énergie, un plan de gestion de mobilité et un plan de gestion des tâches. En fonction de l'usage du réseau de capteurs, différents types d'outils exploitant la couche application peuvent être développés. La couche transport permettra de maintenir le flux de données. La couche réseau pourra s'occuper du routage des données qui lui seront présentées par la couche transport. Puisque, les nœuds capteurs sont aussi déployés en grand nombre, la couche liaison de données se chargera d'éviter les collisions qui peuvent être dues aux communications simultanées. La couche physique, quant à elle, assurera les besoins non moins importants de modulation, de réception et d'émission. En plus de ces couches, les plans de gestion de l'énergie, de la mobilité et des tâches gèrent la consommation d'énergie, les déplacements et la distribution des tâches entre les nœuds capteurs. Ils aident les nœuds capteurs à coordonner les tâches de détection et de limiter la consommation d'énergie [CIS-12].

2.4 Applications des RCSF

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, multimédia, ...) ainsi que le support de communication sans fil utilisé, permettent aux réseaux de capteurs sans fil d'envahir plusieurs domaines d'application. Ils permettent aussi d'étendre les applications existantes et de faciliter la conception d'autres systèmes tels que le contrôle et l'automatisation des chaînes de montage. Les réseaux de capteurs ont le potentiel de révolutionner la manière même de comprendre et de construire les systèmes physiques complexes. Ils peuvent se révéler très utiles dans de nombreuses applications lorsqu'il s'agit de collecter et de traiter des informations provenant de l'environnement. Parmi les domaines où ces réseaux peuvent offrir les meilleures contributions, nous citons les domaines militaire, environnemental, domestique, santé, sécurité, etc.


9

Certaines applications militaires utilisent les RCSF afin de contrôler les différentes troupes, de surveiller toutes les activités des forces ennemies ou d’analyser le terrain avant d’y envoyer des troupes (détection d’agents chimiques, biologiques ou des radiations). Les applications pour l’environnement incluent la poursuite du mouvement des animaux, et des insectes ainsi que le contrôle des conditions de l’environnement qui affectent les produits agricoles, l’irrigation, l’exploration planétaire, etc.

L’utilisation des réseaux de capteurs dans le domaine de la médecine pourrait apporter une surveillance permanente des patients et une possibilité de collecter des informations physiologiques de meilleure qualité, facilitant ainsi le diagnostic de quelques maladies.

Il est clair que ces domaines d’applications des RCSF ont des spécifités déférentes en ce qui concerne la nature des données captées où les nœuds utilisés qui doivent être dotés par de tels capteurs (capteur de pression, température, mouvement, image et vidéo, …). D’un autre coté, il y a des exigences en ce qui concerne le fonctionnement comme le débit nécessaire, les délais de transmission, la qualité de service, la sécurité, etc. On trouve dans [RAU-14] une classification des applications RCSF sous forme de taxonomie avec les performances demandées par chaque type ou domaine d’applications comme le monte la figure I.4 ci-après.

Figure I.4 : Une taxonomie des applications RCSF [RAU-14]

2.5 Caractéristiques des RCSF

L’intégration des réseaux de capteurs avec le monde physique a rendu leur mode de fonctionnement différent de celui des réseaux informatiques traditionnels. Ils possèdent des caractéristiques particulières qui rendent le développement d’applications non-trivial [MAK-08]. Leurs principales caractéristiques sont :

Domaine médical Environnement et Agriculture

Sécurité publique et syst. militaires

Industrie Systèmes de transport

- Irrigation - Prédiction maladie

- Localis. d’animaux- Détection maladie

- Cont. qualité d’air - Contrôle d’eau

- Cont. de véhicule - Signalisation

Evitement et détection accidents

Déférents services d’information

- Catastrophes - Superv. de soldats

- Détection de feu - Cont. de structures

Contrôle d’état de santé

Surveillance de santé à distance

- Pipeline monitoring - Chaine de product.

- Cont. d’énergie - Mesures

Réseaux de capteurs sans fil sous-marins

Réseaux de capteurs sans fil souterrains


10

Taille et coût réduits: Le déploiement à grande échelle des nœuds de capteurs pour les applications à contraintes spatiales, exige la réduction en taille et coût des nœuds. Par conséquent, les capacités de traitement et de mémorisation sont réduites. Ceci influe indirectement sur l'architecture de protocole utilisée pour de tels réseaux.

Consommation énergétique réduite : Puisque les nœuds capteurs fonctionnent avec des batteries, et utilisés dans les applications où ils ne peuvent pas être facilement remplacés ou rechargés (ou le fait de les recharger n'est plus rentable), il y a un seuil critique de la consommation d'énergie à ne pas dépasser. Les protocoles de RCSF essayent de réduire les dépenses énergétiques de toute façon.

Topologie dynamique : La topologie du réseau de capteurs sans fil est un facteur important vu sa dynamique. En effet, le grand nombre de capteurs qui sont dans des milieux inaccessibles et donc sans maintenance ou intervention humaine ce qui présente un risque de fréquentes défaillances. Cela entraine une modification périodique de la topologie du réseau de capteurs.

Auto configuration et auto curatif: les nœuds sont déployés d'une façon Ad hoc. Par conséquent, les nœuds doivent avoir la capacité de s’auto-configurer au sein du réseau. En outre, les nœuds doivent collaborer ensemble pour modifier dynamiquement le réseau face à un changement topologique.

Traitement collaboratif: L’utilisation rigoureuse d'énergie exige de la part des nœuds un traitement coopératif de données, avant leurs transmissions. Ceci implique l'agrégation et la compression des données au sien des nœuds du réseau en plus de la coopération lors de la formation ou maintenance de la topologie.

Architecture centrée données: Les réseaux de capteurs apportent une variation dans le paradigme de la gestion de réseau à partir des architectures centrées nœuds aux architectures centrées données. Puisqu'il est difficile de remplacer les capteurs, les nœuds sont déployés d’une manière redondante. En tant que tels, l'accent est mis sur l'information rassemblée, plutôt que les nœuds eux-mêmes.

Scalabilité et adaptabilité: À la différence des réseaux traditionnels, les réseaux de capteur sans fil ont un nombre par fois très grand de nœuds fonctionnant en alternatif. Ceci réclame la scalabilité du réseau, on dit aussi passage à l’échelle. En outre, si des nœuds meurent, le réseau devrait continuer à fonctionner. La densité des nœuds peut dépasser les 20 nœuds/m3selon l’application et le budget investi.

Bas débit avec possibilité de trafic interrompu: Puisque les réseaux de capteurs sont habituellement utilisés pour surveiller certaines caractéristiques, leur trafic peut être interrompu, fonctionnant à des bas débits.

Supporter l’interrogation: Une certaine forme de communication Sink-nœud devrait permettre l’interrogation des nœuds. C'est-à-dire envoi de requêtes en demande d’une information concernant le nœud ou son environnement.


11

2.6 Problèmes étudiés en RCSF

Les problèmes étudiés dans ce domaine sont multiples, on rappelle ci dessous les principaux axes de préoccupation de la communauté scientifique.

Changement d’échelle : L’augmentation du nombre de nœuds ou la taille du réseau peut entraîner des diminutions de performances au niveau des protocoles. Il peut être intéressant de voir le comportement des protocoles dans de telles conditions. Le défi des réseaux de capteurs soulève une question intéressante quant à leur fiabilité. Comme un réseau de capteurs est conçu pour s’adapter à un environnement en évolution, il émettra plus de paquets de contrôle face à un changement environnemental. À un certain point, le réseau ne pourra plus maintenir la surcharge, et la transmission de données deviendra de moins en moins fiable. En effet, le passage à l’échelle et la fiabilité sont étroitement couplés et typiquement agissent l’un contre l’autre.

Problèmes de routage: Plusieurs algorithmes et protocoles ont été proposés dans les dernières années, dont le but est d'optimiser la dissémination de données dans les réseaux de capteurs sans fils. Le plus évident est de faire une diffusion de paquets pour arriver d'un nœud au Sink, mais sans aucune maintenance ou découverte de routes, ainsi que la redondance de messages dans le réseau ce qui le charge et réduit sa durée de vie en terme d'énergie. Les stratégies de routage qui fonctionnent principalement en se basant sur des informations locales sont plus appropriées, car elles peuvent être réactives aux changements locaux. De plus, les tables de routage sont distribuées et ne nécessitent pas beaucoup de transfert de données de contrôle.

Problème d’énergie : Chaque entité du réseau consomme de l’énergie, surtout l’émission et la réception des messages. De nombreux travaux s’intéressent à la réduction de cette consommation. Une des idées est d’offrir une politique d’alternance des communications entre les nœuds. Une autre idée est de réduire la portée radio des nœuds, tout en maintenant une connexité complète du réseau.

Sécurité : Comme dans le cas des réseaux Internet, le problème de la sécurité se pose pour les RCSF vu le modèle totalement décentralisé de ce type de réseaux, la sécurité devient un facteur très important. Elle peut se situer au niveau des données échangées, où il est nécessaire d’établir un système qui assure l'arrivé des données sans être espionnées ou modifiées. Ceci consiste à concevoir des protocoles pour assurer la sécurité des communications. La difficulté du problème vient de nombreuses limitations dont le déploiement aléatoire.

Extensibilité : Une fois mise en place les protocoles de bas niveau (routage, découverte de voisinage, …), il existe aussi l’installation de protocoles au niveau application, dans le but d’exploiter les capacités du réseau. Le but est de pouvoir offrir certaines possibilités comme la qualité de service, l’utilisation d’applications distribuées et la distribution de services à l’intérieur du réseau.

Surveillance et tolérance aux pannes : C’est la capacité de garantir les fonctionnalités d'un réseau de capteurs sans fil sous n'importe quelle interruption due aux échecs des nœuds de capteurs. Il faut donc identifier et modéliser formellement les modes de défaillances des capteurs, puis de rechercher les techniques de tolérance aux pannes à utiliser. Les réseaux de capteurs sont des


12

systèmes particuliers vu leurs contraintes et environnement de fonctionnement. En effet les approches classiques de tolérance aux pannes supposent une forte connectivité du système et que ses entités ont des connaissances globales sur la configuration de leur ensemble. Les dégradations énergétiques et la mobilité des nœuds qui sont des caractéristiques principales de ce type de réseaux sont par fois ignorées par ces approches. Les approches de tolérance aux pannes dans les RCSF doivent penser à ces défis.

Codage et stockage de données : avec la multiplicité des applications utilisant les RCSFs comme par exemple les applications multimédias, les données traitées et/ou transmises par les capteurs sont de taille importante et donc elles sont particulièrement gourmandes en énergie puisque les nœuds engagent des volumes de données très largement supérieurs aux mesures scalaires classiques. Dans ce contexte, et afin de prolonger la durée de vie du capteur multimédia et du réseau entier, le développement de méthodes de compression tenant compte de l’efficacité énergétique est nécessaire pour que le déploiement de réseaux de capteurs puisse être envisagé en pratique.

3. Surveillance des réseaux de capteurs sans fil

3.1 Définitions La surveillance : De manière générale, la surveillance ou la supervision

correspond à l’action de contrôler un système, afin de prendre des actions nécessaires si le système est hors de l’objectif de commande [NARV-07]. De manière simple, la surveillance consiste à détecter le comportement présent du système en différenciant entre plusieurs états (normal et défaillant) du processus. Le diagnostic est une opération d’identification de la nature d’un dysfonctionnement, ce qui fait appel à des techniques de surveillance [KEMP-04].

La surveillance est une tâche continue, réalisée en temps réel, de détermination de l'état d'un système physique qui consiste en l'enregistrement des informations ainsi qu'en la reconnaissance et l'indication des anomalies du comportement [ZETA-04]. C’est un dispositif passif, informationnel, qui analyse l'état du système et fournit des indicateurs. La surveillance consiste notamment à détecter et classer les défaillances en observant l’évolution du système, puis à les diagnostiquer en localisant les éléments défaillants et en identifiant les causes premières [RACO-06].La surveillance se compose donc de deux fonctions principales qui sont la détection et le diagnostic.

Pour surveiller en continu l'évolution d'un système et déterminer les causes des événements indésirables, il semble donc intéressant d'utiliser au mieux toutes les informations disponibles, qu'elles soient numériques ou symboliques (données capteurs, historiques, réparations effectuées,…). On trouve dans la littérature le terme "d'approche unifiée" pour la surveillance, qui caractérise les systèmes de surveillance prenant en compte ces informations englobant deux approches analytique et heuristique comme indiqué sur la figure I.5.


13

Figure I.5. Approche unifiée pour la surveillance

Avec l'approche analytique, on considère les informations quantifiables issues d'un modèle numérique fournissant des symptômes analytiques. L'approche heuristique permet de compléter la première en prenant en compte les informations qualitatives sur les systèmes surveillés tirées de l'expertise humaine.

Surveillance prédictive : La surveillance prédictive (ou dynamique) comme pour la surveillance classique est un dispositif passif, informationnel, qui analyse l'état présent et passé du système et fournit des indicateurs sur les tendances d’évolution future du système. La surveillance prédictive se compose de la détection prédictive et le diagnostic prédictif, appelé aussi pronostic.

La surveillance d'un réseau de capteurs sans fil consiste à détecter les pannes et les défauts de tous types ensuite trouver des remèdes pour palier à leurs conséquences. Ceci doit être fait en temps réel. L'origine de ces défauts peut être physique ou logique qui affecte le processus de la conception, la fabrication et même le fonctionnement des dispositifs produits.

Les défauts de conception sont commis par les humains ou par les logiciels utilisés dans cette phase. Les défauts de fabrication résultent des imperfections dans les procédés de production. Enfin les défauts de fonctionnement affectant un système en opération sont causés par la surcharge ou l'épuisement des composants et aux contraintes imposées par l'environnement dans lequel est déployé le réseau de capteurs. Dans ce contexte, on peut citer les interférences électromagnétiques, les reliefs et les températures extrêmes.

Les défauts dans un réseau de capteurs sans fil peuvent entrainer des erreurs et des défaillances affectant le comportement normal du système, ce qui présente un risque de déviation, déconnexion ou mauvaise collecte d'informations.

Pour assurer ses fonctions, la tâche principale d’un système de surveillance des RCSF est de collecter toutes les informations qui concernent le réseau et ses composantes comme le nombre des nœuds, la topologie du réseau, le rayon de transmission, le rayon de couverture, l’état des nœuds comme par exemple le niveau de batterie, l’état des liens de communication ...etc. Ensuite, ces paramètres peuvent être exploités pour prédire et éviter des défaillances possibles ou bien reconfigurer le réseau en cas de détection d’une défaillance [BENH-07].

Mesures

Modèles

Observation

Expertise

Symptômes analytiques

Symptômes heuristiques In

tégr

atio

n de

s sym

ptôm

es

Approche heuristique

Approche analytique

Mac

hine


14

Diagnostic dans un RCSF : Le diagnostic joue un rôle très important dans n'importe quel système, c'est un atout de surveillance et de sureté de fonctionnement. Il est basé sur des tests effectués sur tout ou partie du système dans le but d'avoir toujours un ensemble opérationnel et de mettre en question les défauts de conception et de fonctionnement des composants. Pour un réseau de capteurs sans fil, l'objectif du diagnostic est d'avoir un réseau qui remplit ses taches avec un rendement optimal.

D'une manière générale, on distingue deux catégories de tests suivant la manière dont ils sont exercés sur le système. On a donc les tests en ligne et les tests hors ligne. Pour surveiller un réseau de capteurs sans fil, on s’intéresse généralement aux tests en ligne afin d'améliorer les performances.

La nature et les missions d'un réseau de capteurs sans fil nécessitent des opérations de détection et de reconfiguration en temps réel et par un module automatique (sans intervention humaine). C'est-à-dire il doit être doté d'un mécanisme de test et de réaction aux défauts qui est intégré dans le réseau, ce principe fait appelle aux termes d'auto-organisation ou d'auto-reconfiguration.

Les tests en ligne permettent de reconfigurer le réseau en un temps restreints en cas de détection de défaillances, la figure I.6 résume ce principe.

Figure I.6 : Principe de surveillance d'un RCSF

3.2 Aspects relevant de la surveillance d’un RCSF

3.2.1 Déploiement d'un RCSF

Le déploiement des capteurs est la première phase dans le cycle de vie d’un réseau de capteurs. On peut envisager plusieurs formes de déploiements selon les besoins des applications. Les nœuds peuvent être déployés aléatoirement d’un avion par exemple, ou bien ils peuvent être placés un par un d’une manière déterministe par un humain ou un robot. Le placement d'un nombre élevé de capteurs dans un champ de capture exige une manipulation d'entretien soigneuse de la topologie. Une problématique liée à la localisation est celle du placement des nœuds dans un réseau de capteur sans fil, c’est à dire comment positionner les nœuds les uns par rapport aux autres. Il existe plusieurs types de déploiement des nœuds:

RCSF IdentificationTests et diagnostic Reconfiguration

Reprise du fonctionnement

Arrêt du système

Défaut


15

Le déploiement uniforme, cette configuration n’est pas réaliste, par exemple en cas de lancement des capteurs par avion.

Le déploiement dense, qui pose des problèmes de coût et d’interférences entre les signaux.

Le déploiement incrémental [HMS-02], il s’agit de ne pas faire de calcul global, seulement une estimation de la place optimale pour chaque nouveau capteur intégré au réseau. Ce mécanisme est utile pour adaptation après l’installation,

L’Auto-déploiement [WCP-04], l’objectif est de maximiser l’aire couverte par le réseau, et assurer la prise en compte des obstacles. Le placement par auto-déploiement doit pouvoir être réalisé de manière autonome par les nœuds.

3.2.2 Localisation

La localisation des nœuds capteurs est nécessaire pour identifier l’origine de l’information. La majorité des applications exige la connaissance de la position physique des nœuds pour pouvoir localiser les événements. Les solutions de positionnement et localisation se basent sur l’estimation des coordonnées absolues ou relatives de chaque nœud [ABD-06]. Pour cela, les nœuds peuvent exploiter les informations échangées pour calculer la position physique les uns par rapport aux autres. Cette position peut être utilisée par différents algorithmes de surveillance et de routage basés sur la localisation.

Les deux techniques de base pour la localisation sont la trilatération et la triangulation. Elles reposent sur des propriétés très simples et bien connues des triangles. La trilatération consiste à s’appuyer sur trois points de référence, c’est à dire des nœuds dont on connaît la position, et sur les distances qui les séparent du nœud dont on cherche à estimer la position. Cette dernière correspond alors au point d’intersection des trois cercles. La triangulation est semblable à la trilatération puisqu’elle s’appuie également sur trois nœuds de référence (voir figure I.7). La position est calculée à partir de leurs angles d’incidence. La plupart des systèmes de localisation pour les réseaux sans fil reposent sur au moins une de ces deux techniques. Afin de calculer les distances ou les angles, plusieurs paramètres de communications sans fil sont utilisés. Le premier paramètre est le temps de propagation des signaux. En effet, si on connaît l’instant d’émission d’un paquet, en regardant à quel instant celui-ci a été reçu, on peut calculer la distance qui sépare l’émetteur du destinataire grâce au temps et la vitesse de propagation. Lorsque les entités sont parfaitement synchronisées, ce procédé s’appelle Time Of Arrival (TOA). En revanche, lorsqu’il n’y a pas de synchronisation forte, on parle de Time Difference Of Arrival (TDOA) et il s’agit alors d’effectuer le calcul sur plusieurs paquets. Le Global Positioning System (GPS) repose sur cette technique [MEG-07].

Figure I.7 : Triangulation en 3 dimensions [PARR-05].


16

3.2.3 La connectivité

Un réseau de capteurs sans fil est dit connecté si et seulement s'il existe au moins une route entre chaque paire de nœuds mobiles [MER-03]. 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.

Généralement un RCSF est représenté par un graphe G de n sommets (un sommet représente un nœud de capteur), les liens entre les sommets sont appelés des arcs (ou arêtes). Le graphe G est dit k-connexe s'il existe entre chaque deux sommets distincts au moins k chemins différents. La connectivité est un facteur essentiel pour la tolérance aux pannes dans un réseau de capteurs, la k-connectivité exprime le degré de sureté de fonctionnement d'un tel réseau. Cette mesure était étudiée par Kleinrock et Sylvester en 1978 qui ont conclu que le nombre 6 (avoir un réseau 6-connexe) est suffisant pour dire que la probabilité pour qu'un nœud quelconque ne soit pas isolé tend vers la valeur 1, c'est-à-dire que le réseau devient un graphe connexe, des détails sur la démonstration faite par Kleinrock et Sylvester se trouve dans [RSM-01]. C'est un résultat important pour le déploiement des réseaux. Rappelons que le but de la connectivité est d'assurer l'acheminement des informations d'un nœud source à une destination comme par exemple le Sink quand il s'agit de la collecte d'informations.

Figure I.8 : Connectivité d'un RCSF

Les capteurs peuvent communiquer directement si et seulement si chaque capteur se trouve dans le cercle de communication défini par le rayon de transmission d'un autre nœud de capteur. Dans [ILMA-04], on trouve la formulation suivante:

Pour une communication directe, deux capteurs a de rayon de transmission Ra et b de rayon Rb peuvent se communiquer directement si et seulement si :

d(a,b) ≤Rbet d(b,a)≤Ra (1.1)

Figure I.9 : Influence de la valeur du rayon de transmission sur la connectivité d'un RCSF

R


17

3.2.4 La couverture

Un réseau de capteurs sans fil forme un graphe où les sommets sont des nœuds de capteurs. Un nœud peut se trouver dans l'état actif (émetteur ou récepteur), l'état de sommeil quand la radio est éteinte ou l'état à idle quand le transceiver est en repos (ni émission ni réception). Soit un réseau de n nœuds capteurs 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 R. de cette manière, chaque nœud capteur c couvre une région sous forme de disque de centre c et rayon r. Un point p est couvert par c s'il se trouve dans ce disque de capture. La couverture dans un réseau de capteurs sans fil dépend fortement de la densité des nœuds. Cette densité est donnée par l'équation extraite de [ASC-01]:

µ.(R) = (N.π.R2) / A (1.2)

Où R est le rayon de transmission d’un nœud, A l’aire de captage et N le nombre de nœuds situé dans l’aire A.

On distingue la couverture de région et celle de point, le problème de couverture le plus étudié est celui de la couverture de région, où l'objectif principal du réseau de capteurs sans fil est de couvrir ou surveiller un champ. Le schéma ci dessous montre qu'un exemple d'un déploiement aléatoire de capteurs couvrant une région sous forme de carré. Les nœuds en noir reliés forment l'ensemble des nœuds qui restent actifs pour assurer la couverture de la région déterminée [CAW-05].

Figure I.10 : Couverture de région (a) et couverture de point (b)

La couverture de point consiste à couvrir un ensemble de points, appelés aussi cibles. On dit qu'un capteur c couvre un point p si et seulement si la distance entre c et p est inférieure au rayon de couverture (d(c,p)≤ r ) où la fonction d exprime la distance et peut être exprimée en utilisant la distance euclidienne.

3.2.5 Couverture et connectivité

L’objectif fixé lors de la création d’un réseau de capteurs sans fil, est de récupérer des données relatives à une zone géographique dans laquelle le réseau est placé. Dans ce contexte, deux problèmes peuvent être posés: d’une part comment peut-on récupérer les données, et d’autre part comment acheminer ces données ? [CLA-05]. Cela signifie qu'il y a une relation entre la couverture et la connectivité dans un réseau de capteurs.


18

Figure I.11 : Modèle géométrique des deux régions caractéristiques d’un capteur

En examinant la figure I.11, on distingue les cas suivants:

Couverture des meilleurs cas où les événements peuvent être captés dans tout le secteur désiré.

Couverture en pires des cas où on trouve des secteurs en basse observabilité et des régions d'inflation [BENH-07], ce qui diminue la qualité de service.

Si on a donc R≥ 2.r, on aura une région couverte et les nœuds de capteurs seront connectés dans un réseau bien déployé.

3.2.6 Tolérance aux pannes

Elle consiste à protéger l'utilisateur externe des conséquences de défaillances des composants internes d'un système [FMJ-06]. Pour un RCSF, c’est la capacité de garantir les fonctionnalités d'un réseau de capteurs sans fil sous n'importe quelle interruption due aux échecs des nœuds de capteurs [BENH-07]. Il faut donc identifier et modéliser formellement les modes de défaillances des capteurs, puis de rechercher les techniques de tolérance aux pannes à utiliser. Les réseaux de capteurs sont des systèmes particuliers vu leurs contraintes et environnement de fonctionnement. En effet les approches classiques de tolérance aux pannes supposent une forte connectivité du système et que ses entités ont des connaissances globales sur la configuration de leur ensemble. Les dégradations énergétiques et la mobilité des nœuds qui sont des caractéristiques principales de ce type de réseaux sont par fois ignorées par ces approches. Les approches de tolérance aux pannes dans les RCSF doivent penser à ces défis. Ces méthodes sont divisées en deux classes, comme le montre la figure I.12 [PATT-97].

Figure I.12 : Décomposition des approches tolérantes aux pannes

Tolérance aux pannes

Redesign/Adaptation

Détection et Isolation + Reconfiguration Contrôle robuste

Passive Silence sur défaillance

R r r : Rayon de couverture

R : Rayon de transmission


19

3.2.7 Durée de vie

La durée de vie est un élément essentiel pour tout réseau de capteurs sans fil. Le but de n’importe quelle application est d’avoir un réseau fonctionnel pour une longue durée. Le principal facteur limitant la durée de vie d’un réseau de capteurs est l’énergie. En effet les nœuds ne sont pas entretenus pendant des mois et des années pour des raisons de sécurité et d’environnement. Chaque nœud est conçu pour contrôler sa propre alimentation afin de prolonger la durée de vie de tout le réseau. Il y a plusieurs considérations pour déterminer cette métrique [BENH-07]. Selon l'objectif ou les hypothèses pris en compte, il y'a plusieurs définitions de la durée de vie. Elle est souvent considérée comme la durée qui s'écoule depuis la mise en place du réseau jusqu'à l'épuisement de la source d'énergie d'un premier nœud. Bien que la redondance des nœuds peut, dans ce cas, permettre au système de continuer à fonctionner. Une autre définition est la durée qui s'écoule jusqu'au moment où le nombre de capteurs épuisés atteint un seuil déterminé. Il est important de rappeler ici ces déférentes définitions qui sont largement utilisées dans l’évaluation des algorithmes de surveillance des RCSF et qui sont:

a. Le premier nœud qui meurt (first node to die): Le premier nœud qui échoue dans le réseau est utilisé pour définir la durée de vie du réseau [JIE-01]. Le nœud défaillant est souvent appelé un nœud critique.

b. Le nombre de nœuds vivants: le nombre de nœuds vivants en fonction du temps [LI-01], est pris comme mesure de la durée de vie. Un nombre plus élevé de nœuds vivants exprime une longue durée de vie pour le réseau en question.

c. La fraction de nœuds vivants: La durée de vie du réseau est décrite par la fraction de nœuds restants ou vivants en fonction du temps par rapport au nombre total des nœuds [YA-01]. Le réseau est considéré vivant tandis que cette fraction reste au-dessus d'un seuil défini.

d. Jusqu’à la diminution du temps de livraison de paquets: Cette définition évalue la durée de vie sur la base de temps nécessaire pour la livraison des paquets [YA-01] qui est typiquement comparée à une valeur de seuil prédéfinie. Le réseau meurt quand le taux de livraison de paquets descend en dessous du seuil.

e. Le nombre de nœuds qui restent rattachés à la station de base: Le taux de survie du réseau est évalué sur la base du nombre de nœuds connectés à la station de base [LI-01]. Il capture la question de la connectivité du réseau à la station de base. Le nombre de nœuds qui doivent rester connectés à la station de base peut être prédéterminé.

Plusieurs solutions, à la fois matérielles et logicielles, ont été proposées afin d’optimiser la durée de vie des réseaux de capteurs. Les approches de surveillance s’intéressent au niveau logiciel dont le but est de concevoir des algorithmes pour minimiser la consommation d’énergie, et des protocoles à moindre communication. Une autre solution proposée pour économiser l’énergie des capteurs consiste à les mettre en état de veille quand le nombre de nœuds est suffisant, c’est le cas d’un déploiement avec redondance.


20

3.2.8 La redondance des nœuds

La redondance, d'une manière générale, se rapporte à la qualité ou à l'état d'être en surnombre comme c’est le cas pour les nœuds d’un RCSF, par rapport à la normale. Ce qui peut avoir la connotation négative de superflu, mais aussi un sens positif quand cette redondance est voulue afin de prévenir un dysfonctionnement. Selon les circonstances elle est utile :

• Pour augmenter la capacité totale ou les performances d’un système. • Pour réduire le risque de panne. • Pour combiner ces deux effets.

3.2.9 Contrôle de la topologie La dynamicité du réseau de capteurs résulte des défaillances des nœuds ou des

ruptures de liens entre ceux-ci. Il a une forte dynamicité de topologie surtout lorsqu’il s’agit d’un réseau mobile. La moindre défaillance énergétique d’un capteur peut donc changer significativement la topologie et imposer une réorganisation coûteuse de ce dernier [MAK-08]. La topologie du réseau joue un rôle principal dans le fonctionnement de n’importe quel protocole, sur la capacité du réseau ainsi que sur ses performances d’une manière générale. Il existe plusieurs topologies comme la topologie étoile, topologie point à point et les topologies complexes comme la topologie arbre par exemple.

La principale approche pour l'équilibrage de charge et de tolérance aux pannes dans les réseaux de capteurs est la maintenance d'une topologie qui garanti des bonnes conditions de transfert. En effet, l'utilisation de plusieurs chemins permet d'équilibrer la consommation d'énergie des nœuds et diviser le flux des paquets sur l'ensemble des chemins possibles. Ce mécanisme permet aussi de réduire les délais et les pertes de paquets dont la topologie utilisée joue un rôle important pour atteindre ces objectifs.

Le contrôle de topologie consiste à exploiter des paramètres réseau pour générer ou maintenir une topologie qui garanti un bon fonctionnement et une meilleure durée de vie au réseau. On trouve dans la littérature plusieurs travaux sur le contrôle de topologie des réseaux de capteurs dont ils seront détaillés plus loin dans cette thèse.

4. Techniques utilisées pour la surveillance des RCSF

La surveillance ou le monitoring est un ensemble de techniques utilisées pour augmenter les performances d’un RCSF, optimiser la durée de vie et garantir une tolérance aux pannes en exploitant tous les paramètres réseau qui permettent d'éviter ou détecter les anomalies de fonctionnement.

Les limites matérielles du nœud et la variation de la qualité des liaisons sans fil sont des grands défis pour fournir une haute disponibilité des services, en particulier dans les applications des RCSF, où il est nécessaire de créer des mécanismes qui permettent d'identifier et d'atténuer ou de résoudre le problème du trou de l'énergie qui peut être causé par la congestion ou la sur utilisation de chemins menant à la mort prématurée des nœuds.

Du point de vue fonctionnement, les méthodes de surveillance utilisées pour les RCSF peuvent être classées en deux catégories qui sont les méthodes centralisées et celles distribuées.


21

4.1 Techniques de surveillance centralisée

Dans les approches centralisées, la tâche de surveillance est assurée par un nœud dédié ou bien le Sink. Les premiers travaux sur la surveillance des RCSF étaient de cette classe dont on peut citer quelques uns dans cette section. Un nombre considérable de travaux est orienté vers le routage. D'autres travaux ont été intéressés par le découpage des réseaux de capteurs sans fils en Clusters (algorithmes de Clustering) pour concevoir des protocoles de routage hiérarchiques. Ces travaux se basent sur des clusters d'un seul saut, d’autres se basent sur des clusters de k-sauts. Plusieurs travaux sur les RCSF s'orientent vers l'économie de l'énergie, la surveillance, la qualité de service et la sécurité dans ce type de réseaux. En ce qui concerne la surveillance centralisée, on trouve plusieurs travaux dont on peut citer:

Cardei et al. [CAR-02] présentent une approche centralisée qui regroupe les nœuds dans des ensembles dominants. Un RCSF de n nœuds est modélisé par un graphe non orienté formé de n sommets. Une liaison entre deux sommets u et v existe si et seulement si u se trouve dans la zone de couverture de v et vice versa. Les auteurs ont prouvé que le problème est NP-complet, et ils ont utilisé une heuristique pour trouver les ensembles disjoints dominant. Cette heuristique est basée sur la méthode de coloration des graphes. En première étape, les ensembles dominants sont formés en coloriant tous les nœuds et en utilisant l’algorithme de coloration séquentiel. Dans une seconde étape, un ensemble non-dominant est transformé en un ensemble dominant en recolorant le nombre minimal des sommets de couleur dominante ou la plus répandue. Lorsque ce processus est terminé et il n’y a plus d’ensembles dominants à former, les nœuds restants sont ajoutés aux ensembles dominants selon le pourcentage de la couverture de la zone d’intérêt.

Un projet de C.Pham [PHAM-07] s’intéresse aux protocoles de transport pour les réseaux de capteurs sans fil qui doivent identifier et résoudre les congestions et la gestion des pannes d’un certain nombre de capteurs pour garantir la fiabilité de la transmission.

L’auteur de [BENH-07] propose une approche pour surveiller un RCSF. Elle se base sur la théorie des graphes pour garantir la couverture maximale en utilisant un graphe bipartie et la connexité maximale en utilisant la détection des nœuds critiques dans le réseau.

[ANDR-08] et [HERB-07] proposent un algorithme pour le contrôle des défaillances qui peuvent arriver au niveau des nœuds. Ce contrôle est assuré par l'utilisation des nœuds observateurs qui peuvent signaler au Sink en cas de défaut. Le Sink prend la décision convenable pour reconfigurer l'ensemble.

[SHA-14] traite la complexité du problème de construction d’un arbre de collecte et d’agrégation de données mais d’une manière globale, c'est-à-dire centralisée. En se basant sur les caractéristiques du graphe définissant le RCSF, les auteurs proposent un algorithme qui essaye de construire un arbre des plus courts chemins à efficacité énergétique afin de maximiser la durée de vie du réseau (MLST : maximum lifetime shortest path tree), ce qui revient à trouver un arbre de charges minimales (MinST : minimum load shortest path tree). L’étude conclut que le problème en question peut être résolu en un temps polynomial.

La centralisation des opérations de surveillance dans un seul module (le Sink en général) présente des inconvénients majeurs:


22

- Surcharge du module de surveillance par les traitements de contrôle. - Surcharge de tous les nœuds d'un réseau par les messages de contrôle et de

reconfiguration, ce qui augmente considérablement la consommation énergétique surtout en présence de réseaux à grande échelle. Ceci permettra évidemment de réduire leurs durées de vie.

- La détection des défauts peut être retardée à cause des délais de transmission. - La défaillance du module de surveillance paralyse le fonctionnement de tout le

réseau.

Ces observations ont conduit à penser d'exploiter les capacités de traitement des nœuds capteurs pour développer des approches décentralisées ou distribués pour la surveillance des réseaux de capteurs sans fil.

4.2 Techniques de surveillance distribuée

Avec la révolution des réseaux publics et spécialisés, filaires et sans fil et en particulier les réseaux de capteurs sans fil, la tendance actuelle consiste à appliquer les techniques utilisées dans les systèmes distribués temps qu'il est possible. Ces techniques sont généralement inspirées des phénomènes des systèmes naturels. On trouve donc les termes systèmes émergents, coopératifs et systèmes à colonie de fourmis dans lesquels les tâches sont distribuées sur l'ensemble des composants pour coopérer afin d'accomplir une mission précise.

En effet, un réseau de capteurs sans fil est un ensemble d'entités capables d'effectuer un certain type de traitement sans passer par un module spécialisé. Donc les nœuds d'un réseau de capteurs peuvent former un système émergent pour atteindre un objectif de fonctionnement.

L’algorithme SPT (Shortest Path Tree) [KRI-02] est l'un des plus simples algorithmes de routage distribué. Quand un événement est détecté, les nœuds sources envoient leurs données à travers le plus court chemin vers le Sink. C’est un algorithme qui est capable d'agréger les données dans le cas où deux ou plusieurs chemins se chevauchent. Il présente un faible coût de construction de la topologie, mais les chemins ne sont pas optimisés pour favoriser l'agrégation.

Un algorithme distribué a été proposé dans [ZHO-03] pour le problème d’ordonnancement. Le principe est simple, au début, tous les nœuds se trouvent en mode veille. Après, un nœud en mode veille s’active et diffuse un message de sondage dans sa zone de communication puis il attend une réponse. Si aucune réponse n’est reçue durant une période de temps définie, il reste actif jusqu’à l’épuisement de son énergie. Sinon, et si un voisin répond à l’émetteur, cela lui permet de repasser en mode veille. La valeur du rayon de communication est choisie en fonction de la densité des nœuds désirée (nombre de capteurs dans une surface), ou bien sur la couverture redondante désirée, alors que la période pour qu’un nœud s’active et émet le message dépend de la période de détection. Cette approche distribuée a une faible complexité et résiste aux pannes au cas de disparition des nœuds. Par contre, elle ne garantit pas la couverture de toute la zone d’intérêt.

Le protocole MWAC proposé dans [JAM-06] est une méthode d'intégration d'un système multi agent sur un réseau de capteurs sans fil. L'agent est un programme implanté sur chaque nœud, il décide d'auto-organiser les nœuds en leurs attribuer des rôles chacun suivant un protocole par messages et un algorithme d'attribution de rôles. La solution proposée ne traite pas la redondance pour la reconfiguration.


23

Dans [BAAR-06], Barrenetxea a conçu un algorithme décentralisé simple et efficace pour transmettre les données d’une source unique à une destination unique. Dans ce but, il a reformulé le problème du routage en celui d’imposer les contraintes appropriées à des chemins aléatoires sur des graphes. En suite il a dérivé des algorithmes distribués pour trouver les paramètres locaux de marche aléatoire qui induiront une certaine propriété de distribution de la charge dans le réseau. La caractéristique principale de cette formulation est que les nœuds seront capables de transmettre des messages entre une source et une destination par tous les chemins possibles, sans une connaissance du chemin au préalable, et sans devoir tenir à jour une information sur l’état des chemins à chaque nœud. L'auteur considère aussi les aspects pratiques de l’utilisation des techniques de codage par descriptions multiples dans des réseaux de capteurs à grande échelle, où le nombre de chemins disponibles entre une source et une destination est grand.

L'auteur de [FAB-06] propose un algorithme distribué pour le contrôle de la topologie et l'auto-organisation basée sur une connaissance locale pour la construction d'un backbone virtuel sur les réseaux ad-hoc et les réseaux de capteurs sans fil. Il considère que les nœuds d'un tel réseau peuvent se trouver en un des états suivants: isolé, actif, dominant ou dominé. De cette manière, il arrive à construire des clusters dans le réseau. Chaque cluster est dominé par un cluster head (ou dominant). La notion de dominance utilise une propriété de l'ensemble connecté dominant (CDS) qui permet de former des clusters de k-sauts, on parle donc des k-cds.

L'article [COHU-06] propose l'approche appelée DMAC (Distributed and Mobility-Adaptive Clustering algorithm). C'est un algorithme d'auto-stabilisation qui ressemble à celui proposé dans [FAB-06] pour la partition des nœuds en dominants et dominés mais en utilisant d'autres métriques comme le poids des nœuds, c'est-à-dire le nombre de voisins. Les auteurs formulent le problème avec des règles et des prédicats logiques et quelques propriétés de la théorie des graphes. En fin, ce travail généralise le principe et propose le GDMAC (Generalized DMAC).

Un algorithme de couverture distribué a été proposé par Gallais et al. [GAL-08]. L’idée est de maintenir à la fois la connectivité et la couverture, quel que soit le rapport entre les rayons de communication et de couverture, tout en réduisant le nombre de messages entre les nœuds. Pour cela, cette méthode évite la phase d’initialisation et de la découverte des voisins comme par exemple l’utilisation des messages Hello. Chaque nœud attend un temps aléatoire avant de prendre une décision d’activité. Une fois le temps d’attente écoulé, si sa région de couverture est totalement couverte alors il décide d’être passif sans envoyer aucun message. En revanche, s’il décide de rester actif, un message annonçant son activité est envoyé pour informer les nœuds voisins de sa présence. L’inconvénient de cette approche est la synchronisation des nœuds, qui est coûteuse en termes d’énergie.

Dans [BEC-09], les auteurs s’intéressent aux approches de la tolérance aux pannes dans un réseau de capteurs sans fil basées sur la reconfiguration. Ils proposent une approche de surveillance d’un RCSF par reconfiguration distribuée centrée autour du concept de la redondance. Celle-ci permet aux nœuds capteurs de s’auto-organiser en groupes où chaque nœud aura un rôle bien précis à jouer dans son groupe où un nœud peut être un coordinateur par le quel passe tout le trafic transmis par les nœuds membres de son groupe désirant transmettre des données vers le Sink, un nœud peut être aussi une source de données capturées appelé nœud simple ou un nœud passerelle de liaison, participant à plusieurs groupes à la fois, dont le rôle principal est d’assurer


24

la communication entre ces groupes. Le principe permet également de gérer la redondance en ne laissant active que certains nœuds. Les autres membres redondants sont mis en mode veille et seront réveillés à l’aide d’une opération de reconfiguration en cas de panne de nœuds actifs.

Pratyay K. et Prasanta K. traitent dans [PRA-14] le problème du routage dans un RCSF en se basant sur des clusters dont le but est de prolonger la durée de vie du réseau en minimisant sa consommation d’énergie. Les auteurs proposent deux algorithmes qui utilisent le principe du PSO (Particule Swarm Optimisation) ou d’une manière générale le swarm intéligence [CEL-10], le premier pour optimiser le procédé de routage et le deuxième pour la construction des clusters. Dans les deux algorithmes, une formulation mathématique est utilisée pour résoudre ces deux problèmes d’optimisation. D’après les auteurs, la programmation linéaire est la meilleure solution en proposant des systèmes linéaires et non linéaires pour la maximisation de la durée de vie des clusters heads et leurs membres (ou bien la minimisation de la consommation d’énergie par un problème dual).

Afin d’améliorer la durée de vie d’un RCSF, Jacques Bahi et al. proposent dans [BAH-14] une méthode d’auto-stabilisation en considérant un certain nombre de nœuds comme critiques (ou nœuds de secours) et qui seront utilisés en cas de besoin. La détermination des nœuds critiques est basée sur une modélisation de la durée de vie par un formalisme mathématique dit distribution de Weibull [DAN-05].

5. Modélisation d’un RCSF

5.1 Nécessité d’un modèle

De grands défis ont apparu pour la recherche vu la multiplicité des applications qui utilisent les réseaux de capteurs sans fil. Les différences dans ces applications impliquent que les chercheurs doivent prendre en considérations les différentes caractéristiques des RCSF. Par exemple, dans le cas de la modélisation de la topologie, il s'agit de mettre en évidence le placement de nœuds, la mobilité, les infrastructures, l'environnement de déploiement, etc…

Par conséquent, on doit définir un ensemble spécifique de caractéristiques et les exigences que le modèle et les algorithmes sont conçus pour fonctionner avec, d'autre part, il est important de maintenir les algorithmes génériques que possible de telle sorte qu'ils peuvent être utilisés dans un grand nombre d'applications avec des petites modifications. Les modèles utilisés doivent être adaptés à l'environnement, qui présente les caractéristiques suivantes:

Le déploiement des nœuds est souvent aléatoire et irrégulier : les nœuds sont soient volontairement placés à des endroits qui sont les meilleurs pour la surveillance et l’entretien, ou bien ils sont dispersés au hasard pour remplir une exigence de densité, ce qui est le cas dans la plupart des applications. Cependant, l’aspect aléatoire est le plus généal pour un modèle. En plus, l'espace de déploiement peut être à une dimension (le long d’une auto-route par exemple), deux dimensions (sur un champ agricole plat), ou en trois dimensions (sur les arbres et les poteaux).


25

Le degré de mobilité des nœuds : Ceci est très différent dans les applications où les nœuds sont attachés à des entités qui sont mobiles au contraire des applications de surveillance de l'environnement dont les nœuds eux-mêmes ne présentent pas un élément de mobilité. Il est nécessaire d’intégrer un modèle de mobilité le cas échéant.

Le modèle n'assume aucune infrastructure et la plupart des déploiements sont supposés être à l'extérieur et à distance de l’utilisateur. Souvent, tous les nœuds sont équipés d’un matériel identique. Mais parfois les passerelles peuvent posséder plus de capacités au sens de la puissance de traitement, la mémoire et aussi la puissance radio de l’émetteur/récepteur ce qui peut conduire à revoir le modèle radio utilisé.

5.2 Définitions et notations

L'étude de n'importe quel type de système implique sa modélisation sous une forme convenable au problème étudié en se servant des formalismes mathématiques et logiques, des représentations graphiques et des méthodes de conception. Pour un réseau, tel qu'un réseau de capteurs, le plus évident et de le représenter par un graphe G(V,E) où:

V: est l'ensemble des nœuds (sommets ou Vertexes) du réseau en nombre de n. E: est l'ensemble des connexions (arcs ou Edges) notées e(u,v) pour désigner une connexion bidirectionnelle entre les deux nœuds u et v appartenant à V. formellement, on écrit:

E = { e(u,v) / u ∈ G, v ∈ G, d(u,v) ≤ R } (1.3)

Où R est le rayon de transmission et d la distance euclidienne calculée par:

d= ( )221

221 )( yyxx −+− (1.4)

Cette représentation permet d'exploiter les techniques et les algorithmes de la théorie des graphes, par exemple l'algorithme du plus court chemin pour le routage.

Le graphe formé par toutes les interconnexions possibles entre les nœuds est appelé graphe disque unitaire GDU (ou UDG pour Unit Disc Graph).

A partir de cette modélisation, quelques définitions sont nécessaires, nous les avons tirées de [HAUS-05] et qui sont:

Définition 1: voisinage

On appelle voisinage (Neighborhood) d'un nœud u l'ensemble N(u) contenant les nœuds que u peut joindre directement [BENH-07]. La relation binaire représentant le lien de communication entre deux nœuds est supposée symétrique, c'est-à-dire :

u' ∈N(u) ⇔ u ∈N(u') (1.5)


26

Définition 2 : route

Soient u et v deux nœuds du réseau. Une route (ou un chemin) p entre u et v est une suite de nœuds :

n1,n2, . . . ,nmtelle que n1 = u, nm = v et quel que soit i entier, 1≤ i ≤ n, et ni+1 ∈ N(ni).

On note ⎯P l'ensemble des nœuds appartenant au chemin p et |P| le nombre de sauts de p (|P|=n −1). L'ensemble des routes reliant u à v est notée P(u,v).

Il est évident que toutes les routes disponibles ne sont pas forcément intéressantes pour la communication. Par exemple, les routes très longues ou les routes contenant des boucles. Les routes optimales en nombre de sauts sont quant à elles peu nombreuses et sensibles aux changements de topologie [BENH-07].

5.3 Réduction du degré d'un graphe

Afin d'optimiser les résultats et la gestion des ressources d'un réseau de capteurs, il est intéressant de réduire le degré du graphe représentant un réseau. Pour cela il existe plusieurs structures de graphes réduisant le nombre de liens utilisés par différents algorithmes. Le schéma ci-dessous montre ces structures et leur classification:

Figure I.13 : Diagramme de réduction du degré d'un graphe

5.3.1 Graphe RNG

Un graphe est dit RNG (Relative Neighborhood Graph) si, quels que soient les points A et B, il n'existe aucun point C dans l'intersection des cercles centrés sur A et B et de rayon AB. Un graphe RNG est planaire et présente un degré faible. La propriété de planarité peut être utilisée par nombreuses applications [THEO-06]. Autrement dit, si u et v sont deux voisins relatifs, il est impossible de trouver un autre nœud voisin w tel que la distance entre u et w et la distance entre v et w soit inférieur à la distance entre u et v. la figure ci-dessous montre cette configuration.

Graphe GDU du réseau

Structure plates Structure hiérarchiques

CDS MST, RNG, GG


27

Figure I.14 : Principe des voisins RNG

L'ensemble des voisins RNG d'un nœud u est un sous ensemble de tous ses voisins

c'est-à-dire RNG(u) ⊆ N(u) tels que :

RNG(u) = {(u, v) E(u) /∃ w E(u) / d (u,w)< d (u,v) Λ d (v,w) < d (u,v)} (1.6) Où E(v) est l'ensemble des arcs reliant le nœud u à tous ses voisins v.

Figure I.15 : Le graphe GDU d'un RCSF et son graphe RNG correspondant

5.3.2 Graphe de Gabriel

La construction d'un graphe de Gabriel GG consiste à éliminer les liens entre deux nœuds si et seulement si le cercle tracé entre eux contient d'autre nœuds. Dans la figure si dessous à gauche le lien (a,b) est éliminé puisque le nœud c appartient au cercle tracé. Par contre, le deuxième cas à droite le lien (a,b)ne peut être éliminé puisque le nœud c est hors le cercle tracé entre a et b.

Figure I.16 : Principe d'élimination pour construire un graphe de Gabriel.

c

aa b b

c

La présence du nœud w implique que le lien (u,v) ne soit pas dans l'ensemble des liens entre nœuds RNG.


28

Formellement, dans un graphe de Gabriel, il existe un lien entre les deux nœuds u et v si et seulement si:

d2 (u,v) < d

2 (u,w) + d

2(v,w), ∀ w ≠ u,v (1.7)

6. Conclusion Dans ce premier chapitre, nous avons présenté les réseaux de capteurs sans fil et

leurs architectures ainsi que les fondements de surveillance de ce type de système. Le développement des recherches sur les RCSF a engendré plusieurs domaines en fonction des problèmes envisagés par ce type de réseau. Commençant par la localisation des capteurs et les protocoles de communication, ensuite les problèmes de routage et la collecte de l'information et enfin les limites des RCSF en terme de la consommation énergétique par les capteurs qui sont alimentés par des batteries autonomes. Ces limités ont conduit à la proposition de plusieurs approaches centralisées et distribuées de surveillance des RCSF dont l'objectif principal de ces dernières est de maintenir un RCSF opérationnelle pour une longue durée, c'est-à-dire que le réseau reste capable de couvrir la zone d’intérêt (problème de la couverture maximale) et de délivrer les données captées à la station de contrôle (problème de la connexité maximale). Sans oublier les problèmes liés à la topologie dynamique des RCSF. Il est clair que la topologie utilisée est l’épine dorsale de fonctionnement d’un système pareil. Le contrôle de topologie est l’un des préoccupations principales du domaine de la surveillance des réseaux de capteurs. Dans le prochain chapitre, nous allons étudier cette problématique du contrôle de topologie en détaillant ses différentes techniques et les travaux réalisés dans ce domaine.

Chapitre 2 Contrôle de topologie des RCSF

1. Introduction ............................................................................................................. 29 2. Définitions ............................................................................................................... 30 2.1 Topologie ....................................................................................................... 30 2.2 Contrôle de topologie .................................................................................... 30

2.3 Objectifs de contrôle de topologie .................................................................... 31 2.4 Défis du contrôle de topologie .......................................................................... 31

3. Déférentes topologies des RCSF .............................................................................. 32 3.1 Topologie plate ................................................................................................. 33 3.2 Topologie par clusters ....................................................................................... 35

3.2.1 Définition ................................................................................................... 35 3.2.2 Formation de clusters ................................................................................ 36 3.2.3 Communication intra-cluster et inter-cluster ............................................. 36 3.2.4 Maintenance des clusters ........................................................................... 36 3.2.5 Quelques algorithmes de clustering pour RCSF ........................................ 36

3.3 Topologie à base de chaines .............................................................................. 37 3.4 Topologie à base d’arbre ................................................................................... 38

4. Techniques de contrôle de topologie des RCSF ...................................................... 39 4.1 Ajustement de la portée radio .......................................................................... 40 4.2 Changement d'états des nœuds ........................................................................ 41 4.3 Structures en hiérarchie .................................................................................... 42 4.4 Approches hybrides .......................................................................................... 44

5. Travaux existants .................................................................................................... 44 6. Conclusion ............................................................................................................... 47


29

1. Introduction

Le contrôle de topologie est un domaine de recherche très important pour les RCSF. En effet, l’amélioration de la connectivité par un bon choix de topologie peut augmenter les performances du réseau et étendre sa durée de vie. C’est un domaine de recherche qui vise à maintenir une topologie adéquate en maîtrisant les liens à inclure dans le réseau. Le but est d’atteindre un ensemble d’objectifs comme la réduction des interférences, la réduction de la consommation d’énergie et l’augmentation de la capacité du réseau. Vu les capacités limitées des nœuds capteurs en terme de batterie, les premiers travaux sur le contrôle de topologie dans les réseaux de capteurs sans fils utilisent la consommation d’énergie comme métrique, et sont basés sur l’ajustement de la puissance de transmission radio des nœuds.

La principale approche pour l'équilibrage de charge et la tolérance aux pannes dans les réseaux de capteurs est la maintenance d'une topologie qui garanti des bonnes conditions de transfert. En effet, l'utilisation de plusieurs chemins permet d'équilibrer la consommation d'énergie des nœuds et diviser le flux des paquets sur l'ensemble des chemins possibles. Ce mécanisme permet aussi l’amélioration de la qualité de service en réduisant les délais et les pertes de paquets. En plus de l’apparition de plusieurs techniques dans ce domaine, les recherches récentes tendent vers l’aspect distribué des réseaux de capteurs au lieu d’un fonctionnement centralisé. L’utilisation de ce type de réseau est souvent corrélée avec l’absence d’infrastructure. Ainsi leur fonctionnement exige l’utilisation de protocoles collaboratifs. Pour gérer au mieux ces réseaux, il faut trouver un compromis entre les contraintes inhérentes aux capteurs et les besoins exprimés par les applications. La littérature décrit deux approches principales dans ce domaine, soit considérer le réseau à plat dans lequel on déploie directement des protocoles de communication adaptés, soit concevoir une structure auto-organisée qui offrira un support efficace pour une grande variété de protocoles comme le routage, la localisation, la découverte de services, etc.

Dans un très grand RCSF, il n’est pas possible ni d’organiser la structure selon une approche centralisée qui est trop coûteuse en énergie ni de préserver une structure de communication à plat (topologie adaptée aux petits réseaux dans laquelle tous les nœuds ont le même rôle et les mêmes caractéristiques) car plusieurs problématiques sont encore plus critiques avec le passage à l’échelle. Il s’agit entre autre de réduire la taille de la table de routage, le nombre de retransmissions, l’occupation de la bande passante et la consommation d’énergie pour chaque nœud. Le rôle de chaque nœud ne pouvant être défini a priori, la structure de communication que l’on veut définir doit s’auto-organiser afin de rendre le service escompté. Il s’agit donc d’introduire une hiérarchie dans le réseau en créant une structure virtuelle sur la topologie physique du réseau. Une structure virtuelle est le plus souvent formée à partir d’interactions ou de règles locales. Une solution partielle à la résolution des problèmes évoqués ci-dessus, est très bien résumée dans [SAN-05], qui est le contrôle de topologie.

Ce chapitre est un état de l’art sur le contrôle de topologie dans les réseaux de capteurs dont on explorera les différents types de topologies qui peuvent être utilisées dans les RCSF ainsi que les techniques de contrôle de ces topologies et leur classification selon objectifs et principes. Enfin, on donnera un aperçu sur les travaux récents dans ce domaine.


30

2. Définitions

2.1 Topologie

Une topologie de réseau est en général la définition de l'architecture physique ou logique d'un tel réseau. L'arrangement physique, c'est-à-dire la configuration spatiale du réseau est appelé topologie physique. Par contre, la topologie logique représente la façon dont les données transitent les liens de communication. Dans les réseaux de capteurs sans fil, une topologie fournit des informations sur un ensemble de nœuds et les liens de connectivité entre chaque paire de nœuds. Elle joue un rôle principal dans le fonctionnement de n’importe quel protocole, sur la capacité du réseau ainsi que sur ses performances d’une manière générale. Une topologie est souvent représentée par un graphe dont les sommets modélisent les nœuds et les arcs modélisent les liens de communications.

2.2 Contrôle de topologie

Le contrôle de topologie consiste à exploiter des paramètres réseau pour générer ou maintenir une topologie qui garantit un bon fonctionnement. C’est une technique importante utilisée dans les réseaux de capteurs pour économiser leur énergie et étendre leur durée de vie sans affecter les autres performances telles que la connectivité et l’utilisation de la bande passante. L'idée de contrôle de topologie est de permettre aux nœuds capteurs d’exercer un contrôle sur certains paramètres qui sont manipulés d'une manière à optimiser le fonctionnement. En particulier, les nœuds de capteurs ont la capacité d'ajuster la puissance de transmission de leur module radio ou changer leurs modes de fonctionnement ou encore choisir les liens de communication à utiliser ce qui entraine des modifications topologiques.

Pour construire une topologie, chaque nœud capteur découvre ses voisins et des liens relatifs à l'aide de sa puissance d'émission maximale. Sur la base des informations recueillies, le nœud peut prendre des décisions pour construire le réseau. L'inconvénient de cette approche est que le réseau créé peut-être trop dense avec trop d’interférences. Pour éviter ce problème, un contrôle de topologie approprié doit être utilisé pour éliminer les liaisons inutiles dans le réseau dense, sans diminuer les autres performances [AZR-12].

On considère ici toutes les techniques qui utilisent un ou plusieurs paramètres pour configurer la topologie d’un réseau afin d’optimiser ses performances comme méthodes de contrôle de topologie. Ainsi, une technique de clustering répond à cette considération du fait qu’un ensemble de nœuds appelés cluster heads sont capables de contrôler l'ensemble de leurs voisins.

On trouve dans la littérature d’autres définitions pour le contrôle de topologie dont la plus part visent les techniques de contrôle de puissance [MUQ-04], [SIA-06], [WAN-06]. Bien que cette technique consiste à contrôler la puissance d'émission des nœuds, elle ne vise pas à atteindre l'efficacité énergétique de l'ensemble du réseau. On trouve dans [SAN-05] un exemple de technique qui vise à sélectionner le meilleur niveau de puissance de transmission pour une transmission sans fil unique même à plusieurs sauts. Dans ce cas, il a une perspective de large canal.


31

2.3 Objectifs de contrôle de topologie

Après le déploiement d’un réseau de capteurs sans fil, on obtient une topologie physique qui ne peut être changée surtout si la nature du réseau utilisé empêche la possibilité de déplacer ou d’ajouter des nœuds ou encore changer leur portée radio. La solution est de faire modifier quelques paramètres pour avoir une topologie logique selon les besoins. Dans tous les cas, l’objectif principal d’une technique de contrôle de topologie est de garantir la connectivité du réseau ou la couverture de certains points, zones ou cibles. Il est aussi intéressant de voir les deux aspects ensemble, c'est-à-dire connectivité et couverture en même temps.

Une taxonomie des travaux sur le contrôle de topologie est définie par Mo Li et al. dans [LI-13]. Cette taxonomie est une classification des travaux selon leurs objectifs qui visent la connectivité ou bien la couverture comme le montre la figure suivante :

Figure II.1 : Une taxonomie des travaux de contrôle de topologie des RCSF selon leurs

objectifs [LI-13].

2.4 Défis du contrôle de topologie

Bien que le contrôle de topologie dans un réseau de capteurs sans fil permette d'améliorer la performance globale du réseau, il ya un certain nombre de facteurs qui rendent la conception et la mise en œuvre d’un algorithme de ce type difficile. Parmi ces facteurs on peut citer :

Le paramètre de contrôle : Le défi majeur d’un algorithme de contrôle de topologie est de trouver le bon paramètre mesurable pour l'algorithme. Cependant, parfois certains paramètres ne sont pas disponibles au niveau des nœuds comme la position par exemple ou nécessitent une connaissance globale ou un transfert de données comme le nombre de sauts vers le Sink par exemple.

Objectifs de contrôle de topologie

Connectivité du réseau Couverture du réseau

Couverture globale

Couverture de zones

Couverture de cibles

Contrôle temporel

Contrôle spatial

Contrôle de puissances

Gestion de modes


32

Limitation matérielle du module radio : Ceci est une considération pratique et une question de possibilité ou pas de contrôler le module radio d’un nœud capteur. Dans certains modules radio la puissance d'émission n'est pas un paramètre ajustable, tandis que dans d'autres il ya seulement quelques réglages au niveau de la transmission, de sorte qu'il est difficile pour un algorithme de contrôle de topologie de faire une différence significative sur la performance de la connectivité et de l'énergie.

Les frais généraux : Le coût d'un algorithme de contrôle de topologie distribué comprend la puissance de traitement nécessaire et les frais généraux d'échange de messages entre voisins. Par conséquent, il est préférable de développer un algorithme simple de contrôle de topologie qui donne de bons résultats plutôt qu'un algorithme compliqué qui donne les meilleurs résultats. En outre, un algorithme simple peut être facilement mis en œuvre avec moins de besoins en traitement et en mémoire, ce qui est un facteur très important pour un RCSF.

Adaptabilité : Le contrôle de topologie est nécessaire pour opérer dans différents lieux géographiques et environnementaux. Un grand nombre d'algorithmes de contrôle de topologie ont été testés dans un espace symétrique de deux dimensions (2D).Cependant, Les environnements réels sont les plus susceptibles de ne pas être symétriques et peuvent être 1D, 2D ou 3D. De plus, les changements environnementaux et les changements même de la zone de déploiement qui peut être par exemple l'océan, dans lequel les nœuds peuvent être déplacés ou emportés par les vagues et les marées. Il est donc nécessaire de reconnaître ces changements et de réagir en conséquence pour maintenir la connectivité.

3. Déférentes topologies des RCSF

A la déférence des réseaux classiques, la topologie d’un RCSF dépend du protocole et/ou l’application utilisés et qui définit la manière dont les nœuds sont interconnectés, tels que les protocoles de routage, collecte de données, agrégation de données, suivi de cibles, la diffusion de données, etc… En général, on peut classifier ces topologies logiques en quatre principales catégories : topologie plate, topologie en grappe, topologie basée sur une chaîne et la topologie arborescente. Le tableau II.1 ci après issue de [QUA-12] montre quelques exemples de protocoles pour chaque type de topologie.


33

Protocole de Références Topologie utilisée

Collecte de données

[KAI-07] Plate [YE-05] A base de cluster [WU-09] A base d’arbre [TAB-06], [YUA-08] A base de chaine

Suivi de cible

[OLU-07] Plate[CHE-04] A base de cluster [TSA-07] A base d’arbre [KAN-07] A base de chaine

Routage

[LEE-06] Plate[KAR-04-b] A base de cluster [FAR-09] A base d’arbre [CHEN-09] A base de chaine

Agrégation de données

[XU-11] Plate[JUN-05] A base de cluster [FUN-08] A base d’arbre [WU-09] A base de chaine

dissémination de données

[KHAN-08] Plate[WAN-05] A base de cluster [XIN-09] A base d’arbre [HUAN-09] A base de chaine

Synchronisation [BEL-100] Plate[DON-06] A base de cluster HE-08] A base d’arbre

Tableau II.1 : Exemples de protocoles et leurs topologies correspondantes

Dans ce qui suit, on donne un aperçu sur chaque type de topologie avec leurs avantages et inconvénients ainsi que les principaux protocoles qui représentent chaque catégorie.

3.1 Topologie plate

La topologie plate est dite aussi topologie non structurée, en effet, c’est le cas où aucune topologie logique n’est définie. Les nœuds capteurs jouent tous un rôle identique pour la formation du réseau. Une communication multi-saut peut être nécessaire pour l’architecture plate. En présence d’un très grand nombre de nœuds capteurs, la scalabilité devient critique. Le routage et le contrôle d’accès au médium doivent gérer et organiser les nœuds d’une manière efficace.

Cette architecture est caractérisée par un coût de maintien réduit, une grande tolérance aux pannes ainsi qu’une habilité à construire de nouveaux chemins suite aux changements de topologie. Cependant, les nœuds proches de la station de base vont participer plus que les autres aux tâches de routage, ce qui présente un risque de trou d’énergie autour du Sink. De plus, cette architecture présente une faible sociabilité due au fonctionnement identique des nœuds et d’une manière distribuée nécessitant ainsi un grand nombre de messages de contrôle. La figure ci-dessous montre une topologie plate ou les sommets sont les nœuds capteurs et les arcs représentent les liens de communication radio.


34

Figure II.2 : Topologie plate

Plusieurs protocoles ont été proposés sur la base d’une topologie plate. Par exemple des protocoles d'agrégation des données [XU-11], de collecte de données [KAI-07] et les protocoles de routage [HUS-07]. Ces protocoles qui utilisent une topologie plate, essayent de trouver des routes optimales du nœud source vers la destination en se basant sur une certaine forme d'inondation (flooding) répétée jusqu'à atteindre le nœud de destination. Il est clair que cette technique ne prend pas en compte les contraintes énergétiques imposées par les réseaux de capteurs. Par conséquent, et lorsque ceci est utilisé pour le routage de données, il posera à la suite des problèmes de chevauchement et de duplication des paquets. Pour minimiser ces problèmes de diffusion, des améliorations ont été proposées comme par exemple restreindre la diffusion à une région bien localisée ou utiliser des méthodes probabilistes pour choisir une route dont on peut citer le protocole SPIN (Sensor Protocols for Information via Negotiation) [HEI-99], Directed-Diffusion [INT-02] et Rumor-Routing [SEM-09].

Principalement, il y a deux avantages quand on utilise une topologie plate, elle offre une bonne qualité des routes vers le Sink et ne demande aucune maintenance de topologie. Tant dit que les inconvénients sont nombreux :

‐ L’inondation est une opération couteuse qui doit être évitée par les réseaux de capteurs.

‐ Pas d’équilibrage de charges entre les nœuds ce qui conduit à diminuer leur durée de vie.

‐ Plusieurs messages redondants circulent dans le réseau ce qui consomme l’énergie et la bande passante aussi.

‐ Les transmissions sont souvent retardées par les chevauchements.


35

3.2 Topologie par clusters

Figure II.3 : Topologie à base de clusters

L’approche de clustering consiste à partitionner le réseau en un certain nombre de groupes appelés clusters, plus homogènes selon un principe bien déterminé, et former une topologie virtuelle. Les clusters sont généralement identifiés par un nœud particulier appelé cluster-head, ou chef de groupe. Ce dernier permet de coordonner entre les membres de son cluster, d’agréger leurs données collectées et de les transmettre à la station de base. Il est sélectionné pour jouer ce rôle selon une métrique bien particulière ou une combinaison de métriques. Avant de présenter quelques algorithmes basés sur le clustering, il est nécessaire de présenter les principaux concepts liés à cette technique.

3.2.1 Définition

Soit un réseau sans fil modélisé par un graphe connexe non orienté G = (V,E) où les sommets V sont les nœuds et les arêtes E représentent les liens de communication. Le processus de clustering consiste à un découpage virtuel de V en un ensemble de groupes proches géographiquement {V1, V2,...,Vk} tels que:

(2.1)

Où chaque sous-ensemble Vi induit un sous-graphe connexe ou une composante connexe du graphe G. L’ensemble de ces composantes peuvent former un graphe réduit ou un graphe de composantes G′ = (V ′ ,E′) de G, où : • Les sommets v′i Є V′ correspondent aux composantes connexes Vi du graphe G; • E′ contient l’arête (vi, vj) si et seulement si il existe dans le graphe G une arête

d’un sommet ui Є Vi vers un sommet uj Є Vj .

Ces groupes sont appelés "Clusters" et ils ne sont pas nécessairement disjoints. Chaque cluster est identifié par un nœud particulier appelé cluster-head "CH". Le choix du cluster-head est une opération d’élection appelée aussi la phase Set-up, elle se fait sur la base d’une métrique spécifique ou d’une combinaison de métriques telles que : l’identifiant, le degré ou le poids, l’énergie, la k-connectivité, la mobilité,...

L’efficacité d’un algorithme de clustering est évaluée en termes du nombre de clusters formés et de la stabilité de ces derniers en fonction de la mobilité des nœuds. Le processus de clustering vise principalement à optimiser la maintenance des informations de la topologie du réseau et de réduire l’overhead de la diffusion pour la découverte des chemins.


36

3.2.2 Formation de clusters Il existe plusieurs méthodes de formation de clusters. Les plus répandues comme

[BAS-01], [CHA-02] et [LIN-97] utilisent le principe suivant : 1. Chaque nœud devra connaître son voisinage par le biais des messages Hello, 2. Chaque nœud prend la décision selon sa connaissance locale de la topologie pour

être cluster-head ou non, 3. Le nœud choisi comme cluster-head diffuse son statut dans son voisinage et

invite ses voisins qui ne sont pas encore affiliés à d’autres clusters de le rejoindre.

3.2.3 Communication intra-cluster et inter-cluster Chaque cluster-head se charge des communications à l’intérieur de son cluster et

maintient les informations de routage lui permettant de joindre les autres cluster-heads. De plus, comme les cluster-heads ne sont pas directement reliés, des nœuds passerelles sont aussi élus et utilisés pour les communications entre cluster-heads.

3.2.4 Maintenance des clusters Dans le but de s’adapter aux changements de la topologie du réseau, une mise à jour

des clusters est dynamiquement réalisée dans le cas où un cluster-head ou un membre migre d’un cluster Ci à un autre Cj. D’autre part, si le cluster-head garde son statut le plus longtemps possible, même s’il ne possède pas le poids maximum dans son propre cluster alors il perdra son rôle une fois qu’il s’éteindra (quand sa batterie est épuisée par exemple). Un mécanisme de maintenance de la topologie par réélection est donc nécessaire.

3.2.5 Quelques algorithmes de clustering pour RCSF Les réseaux de capteurs sans fil sont des réseaux ad hoc particuliers de point de vue

infrastructure, architecture, autonomie d’énergie et utilisation des ondes radio pour communiquer. Cependant, leurs spécificités, leurs objectifs et leurs besoins sont différents. Le clustering dans les réseaux de capteurs est une manière efficace pour minimiser la consommation d’énergie dans un cluster en exécutant les fonctions d’agrégation et de fusion de données dans le but de diminuer le nombre de messages transmis à la station de base.

Récemment, plusieurs techniques de clustering ont été proposées pour traiter les principaux défis dans les réseaux de capteurs. Ces techniques visent à maintenir les informations de la topologie du réseau, réduire l’overhead généré par la découverte de routes, et minimiser la consommation d’énergie en tenant compte de la spécificité de ces réseaux. Elles sont dans la plupart des cas orientées énergie dont le but est de prolonger la durée de vie du réseau, et dans certains cas elles sont orientées qualité de service. On donne ici deux protocoles de clustering à savoir LEACH [HEI-00] et VGA [KAR-04] qui sont les plus connus, d’autres algorithmes seront discutés plus loin.

Le protocole LEACH (Low-Energy Adaptive Clustering Hierarchy) est l’un des premiers protocoles de routage hiérarchiques proposés pour les réseaux de capteurs sans fil. Dans ce protocole, les chefs de groupe sont choisis de manière arbitraire et par alternance de ce rôle afin de mieux distribuer l'utilisation d'énergie dans le réseau. Le chef de groupe synchronise les capteurs de son groupe en leur indiquant un intervalle de transmission de données. Hors de cet intervalle les capteurs peuvent se mettre en veille et économiser leur énergie. Les chefs agrègent et compressent les données et réduisent ainsi la taille des données à transmettre au Sink afin d'empêcher une


37

dissipation excessive de l'énergie. Cependant, ce protocole a certains défauts. Par exemple, il suppose que chaque capteur est capable de communiquer directement avec le Sink ce qui peut être difficile à réaliser pour les réseaux déployés à grande échelle. De plus, le choix et l'alternance dynamique des chefs nécessitent des échanges de messages et des traitements supplémentaires [ALKA-04].Des améliorations de LEACH ont été proposées pour augmenter ses performances comme LEACH-C [WU-10]qui est une variante centralisée de LEACH afin d’optimiser le choix des nœuds qualifiés en cluster heads d’une manière globale. Une autre amélioration dite MH-LEACH [HEN-14] pour Multihop LEACH qui sélectionne une route entre le cluster head source et la station de base à travers d’autres clusters heads. Ou encore K-LEACH [PAR-13] qui utilise la distance euclidienne et l’énergie maximale pour affiner le processus de clustering.

VGA (Virtual Grid Architecture routing) [KAR-04] est une méthode de clustering pour maximiser la durée de vie dans les réseaux de capteurs dont les nœuds sont immobiles ou se déplacent avec une faible vitesse. L’approche GPS-free est utilisée pour construire des clusters fixes, disjoints, et homogènes en taille avec des formes symétriques. L’agrégation de données est réalisée en deux niveaux local et global. L’agrégation locale est réalisée par l’ensemble des cluster-heads appelés aussi Local Aggregators (LAs), alors que l’agrégation globale est réalisée par un sous ensemble de LAs appelés Master Aggregators (MAs). Cependant, la détermination de l’ensemble MAs est un problème NP-difficile. Les heuristiques qui ont été proposées pour former l’ensemble MAs à partir de l’ensemble LAs, avaient comme objectif la maximisation de la durée de vie des réseaux de capteurs. Par exemple, dans l’heuristique CBAH [KAR-04-a] (Cluster-Based Aggregation Heuristic), l’ensemble MAs est choisi selon la capacité des éléments de LAs. Les membres d’un même cluster surveillent le même phénomène, et leurs données captées sont corrélées par leur LA correspondant. Ce dernier à son tour transmet ces données corrélées à son MA correspondant.

Une topologie à base de clusters présente les avantages suivants: • La consommation d'énergie des nœuds par rapport aux protocoles de

topologie plate est réduite, ce qui conduit à prolonger la durée de vie du réseau avec une meilleure utilisation de la bande passante du canal.

• Elle offre plusieurs paradigmes de communication qui sont répandues dans les réseaux de capteurs.

Toutefois, le regroupement non-uniforme est le principal problème pour cette topologie. Ce qui présente les inconvénients suivants :

• Le taux de dissipation de l'énergie est très différent d'un capteur à un autre, même si ils sont dans le même cluster.

• Les clusters heads sont les nœuds qui meurent le plus rapidement. • La connectivité du réseau ne peut pas être garantie.

3.3 Topologie à base de chaines

Dans ce type de topologie, une chaîne de transmission est construite en reliant tous les nœuds de capteurs déployés afin d’économiser leurs énergie. Un nœud leader est choisi dans la chaîne, ce leader peut être une station de base. Tous les nœuds communiquent les uns avec les autres le long de la chaîne. Un nœud envoie ses paquets au nœud suivant, qui est appelé aussi successeur qui mène vers le nœud leader. Dans ce mode, tous les nœuds envoient leurs données au nœud leader. Ce principe est utilisé pour faciliter l'agrégation de données.


38

Figure II.4 : Une topologie à base de chaine

PEGASIS [WOO-03] est un exemple de protocole basé sur une topologie par chaîne où chaque nœud dans la chaîne reçoit les données de son prédécesseur puis les transmet au nœud suivant dans la chaîne. A chaque saut une agrégation de données est faite par fusion des paquets provenant des différents nœuds de la chaine ce qui permet de réduire le nombre de transmissions. Notons que les transmissions se font par tour au long de la chaine, un nouveau tour est lancé quand on arrive au Sink. PEGASIS a deux objectifs principaux. Tout d'abord, augmenter la durée de vie de chaque nœud à l'aide d’une technique de collaboration et permettre la coordination locale entre les nœuds qui sont proches afin de réduire l’utilisation de la bande passante.

En plus de PEGASIS, il existe d'autres protocoles basés sur les chaines tels que CHIRON [KUO-09] et COSEN [NAH-06] qui est la première topologie orientée chaîne qui utilise plusieurs chaînes au lieu d'une seule.

Ce type de topologie offre les avantages suivants:

• Economiser plus d'énergie que les topologies en clusters (Par exemple, PEGASIS consomme 50% d'énergie moins que LEACH [QUA-12]).

• Equilibrage de charge bien géré. • Plus longue durée de vie pour le réseau.

D’autres part, les topologies basées sur les chaines ont quelques inconvénients tels que :

• Trop de retard pour la collecte des données. • La gestion de la topologie est un peu couteuse.

3.4 Topologie à base d’arbre Dans une topologie à base d’arbre (ou topologie hiérarchique), une arborescence

logique est construite par tous les capteurs déployés où chaque nœud doit connaitre son parent. Les données sont transmises à partir d'un nœud fils à son nœud parent, qui à son tour, renvoie les données reçues après agrégation avec ses propres données jusqu’à atteindre le Sink. L’idée principale derrière la construction d’un arbre est d’éviter les inondations comme dans une topologie plate. La figure II.5 montre une formation typique d’une arborescence logique.


39

Figure II.5 : Topologie à base d’arbre

Il y a plusieurs protocoles qui utilisent une topologie arborescente dont la plus part visent à optimiser le routage [WOO-03] et la collecte de données comme le protocole CTP [OMP-09]. Ce dernier protocole sera détaillé plus lion dans cette thèse. En plus des avantages connus de cette topologie surtout la qualité des routes vers le Sink, dans [ZHA-10], Zhanget al. prouve que pour l'acquisition des données, la topologie arborescente économise plus d'énergie que la topologie en clusters. Un réseau de capteurs sans fil sous forme d’arborescence présente les inconvénients suivants:

• Le processus de formation de l’arbre est couteux. • En absence d’un mécanisme de maintenance, la défaillance d’un parent isole

toute une partie de l’arbre. • Le problème du trou d’énergie qui touche les nœuds proches du Sink. En effet,

ces derniers doivent supporter tout le trafic en provenance de la profondeur du réseau.

On trouve dans [QUA-12] une comparaison entre les quatre types de topologie des

réseaux de capteurs sans fil à savoir la topologie plate, à base de clusters, à base de chaines et la topologie hiérarchique ou arborescente. Cette étude prend en considération plusieurs points de comparaison comme l’efficacité énergétique, la fiabilité, la scalabilité, l’auto-organisation et la latence.

4. Techniques de contrôle de topologie des RCSF

Comme le contrôle de topologie d’un RCSF fait appel à plusieurs domaines de modélisation et d’optimisation, de nombreuses techniques peuvent être classées comme des mécanismes de contrôle de la topologie. Pour cela, on trouve dans la littérature des travaux qui proposent des classifications de telles techniques. La figure ci après montre l’une de ces classification tiré du livre « Topology control in wireless ad hoc and sensor networks » de P.Santi [SAN-05] et qui divise le domaine en contrôle de topologie homogène et non homogène. Dans le premier cas, les nœuds utilisent la même puissance radio, donc le problème est réduit à la détermination de la puissance minimale dite Critical Transmitting Range (CTR). Dans le cas du contrôle de topologie non homogène, ces techniques sont classées en trois catégories, en fonction du type d'informations utilisées pour calculer la topologie à savoir la localisation, la direction et le voisinage.


40

Figure II.6 : Classification des techniques de contrôle de topologie [SAN-05].

On s’intéresse ici aux techniques de contrôle de topologie dans un RCSF qui exploitent tout type d’informations pour optimiser les performances. De ce point de vue, il existe trois principales techniques pour effectuer un contrôle de topologie dans un réseau de capteurs sans fil. Ces techniques sont basées sur l’ajustement de la portée radio, le changement d'états des nœuds et les structures en hiérarchie. Des combinaisons entre plusieurs techniques sont également possibles, c’est ce qu’on appelle les méthodes hybrides de contrôle de toplogie.

4.1 Ajustement de la portée radio

Ce type de contrôle de topologie offre un mécanisme qui permet aux nœuds de faire varier leur plage de transmission qui réduit potentiellement la consommation d'énergie mise en jeu lors de la transmission. En conséquence, les liaisons de communication à longue distance sont supprimées, alors que les liaisons de communication à courte distance sont choisies. Du point de vue de la consommation d'énergie, une communication directe sur de courtes distances est plus économique en énergie que la communication à longue distance [SAN-05]. Par conséquent, la réduction de la puissance de transmission permettra d'éliminer les liaisons longues distances qui peuvent gaspiller des ressources énergétiques. Le contrôle de topologie à deux principaux objectifs. Le premier objectif est d'économiser l'énergie et prolonger la durée de vie du nœud de capteur et par conséquent de tout le réseau. Le deuxième objectif est d’éviter les collisions. Autres que les liens inefficaces, l'utilisation de la gamme de transmission minimale élimine avec succès plusieurs liens distants, conduisant ainsi à un réseau clairsemé et une réduction des retransmissions de paquets et les interférences et une amélioration de la capacité du réseau.

Pour communiquer avec ses voisins, un nœud capteur utilise un signal de puissance adaptée à la densité du réseau et le degré de connectivité désiré. Une puissance réduite assure une topologie facile à gérer avec économie d’énergie et moins d’interférences radio. La stabilité d’un nouveau réseau de capteur utilisant cette technique demande une coopération entre les nœuds pour trouver la configuration adéquate. Par exemple dans la figure II.7, les liens N1-N4 et N2-N4 sont inutilisés en réduisant la portée radio des nœuds concernés.

Contrôle de topologie

Basé sur la direction

Homogène Basé sur le CTR

Basé sur le voisinage

Non homogène

Basé sur la

Energy-efficient communication

Range Assignment et variantes


41

Figure II.7 : Contrôle de topologie par ajustement de la portée radio

Les protocoles représentant cette technique sont Minimum Energy Communication Network (MECN) [ROD-99], et son extension SMECN [LIA-01] pour Small SMECN et COMPOW [NAR-02] qui conserve l’énergie des nœuds en utilisant le niveau minimum de puissance qui garantit la connectivité de tout le réseau.

4.2 Changement d'états des nœuds

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. Quand le nombre de nœuds déployés est suffisant, la redondance des nœuds peut être exploitée pour avoir une meilleure topologie en faisant changer l’état d’un nœud entre actif et en veille pour éviter les échanges inutiles entre nœuds. D’une manière générale, on distingue quatre états des composants radio (transmetteur et récepteur) : actif, réception, transmission et sommeil [MOAD-08].

• Etat actif : La radio est allumée, mais elle n’est pas employée. En d’autres termes, le nœud capteur n’est ni en train de recevoir ni de transmettre. 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.

• Etat sommeil : La radio est mise hors tension. • Etat transmission : La radio transmet un paquet. • Etat réception : La radio reçoit un paquet.

Il est aussi à noter que le passage fréquent de l’état actif à l’état sommeil peut avoir comme conséquence une consommation d’énergie plus importante que de laisser le module radio en mode actif. Ceci est dû à la puissance nécessaire pour la mise sous tension du module radio. Cette énergie est appelée l’énergie de transition. Il est ainsi souhaitable d’arrêter complètement la radio plutôt que de transiter dans le mode sommeil. Le changement d’état du module radio doit être géré par un protocole de la couche MAC. Ils existent plusieurs protocoles de cette catégorie dont on peut citer:

GAF (Geographical Adaptive Fidelity) [HEI-01] est un exemple de protocole qui utilise un principe de nœuds équivalents permettant à un nœud de basculer entre les états sleep, discovery et active pour mettre en œuvre cette technique comme illustre la figure II.8. GAF conserve l'énergie par la mise en veille des nœuds inutiles dans le réseau sans affecter le niveau de fidélité du routage. Il forme une grille virtuelle pour le domaine couvert. Chaque nœud emploie sa position indiquée par le GPS pour s'associer à un point dans la grille virtuelle. Des nœuds liés au même point sur la grille sont considérés équivalents en termes de coût de routage. Une telle équivalence est exploitée en maintenant quelques nœuds situés dans un secteur particulier de la grille dans l'état de sommeil afin d’économiser de l’énergie.

N1

N2

N3 N4

110

100

25

30 25

55


42

Figure II.8: Transitions d’état d’un nœud dans GAF

De même dans STEM (Sparse Topology and Energy Management) [SCH-02], un maximum de nœuds est mis à l’état sleep pour économiser l’énergie du réseau. Cette approche est adaptée aux applications avec un transfert de données faible. Enfin, ASCENT (Adaptive Self-Configuring Sensor Network Topologies) [CER-04] est un algorithme auto reconfigurable permettant aux nœuds de décider de participer ou pas au transfert de données en se basant sur des conditions mesurées localement. Cet algorithme permet à un nœud de choisir un des états test, passive, sleep et active.

4.3 Structures en hiérarchie

Cette technique consiste à trouver une structure en clusters hiérarchiques pour le réseau. Le choix des clusters head présente un problème pour cette technique. Plusieurs contributions ont essayé de proposer des approches de clustering plus performantes. La plupart des algorithmes construisent un backbone virtuel en se basant sur le concept connected dominating set (CDS) ou l’ensemble connecté dominant [DU-04]. Parmi ces algorithmes, on peut citer PACDS ou Power Aware Connected Dominating Set [BUR-04], ECDS ou Energy Efficient Distributed Connecting Dominating Sets [YUA-06] et TMPO ou Topology Management by Priority Ordering [BAO-03].

Du point de vue des routes et du nombre de niveaux qui constituent la hiérarchie, il y a trois manières de le faire comme le montrent les trois figures ci-après (figures II.9, II.10 Et II.11) extraites de [ALI-12].

La première approche est basée sur les groupes (cluster-based approach), LEACH est considéré comme étant le premier protocole de routage hiérarchique basé sur la première approche. Il est aussi l’un des algorithmes de routage hiérarchiques les plus populaires pour les RCSF. L’idée est de former des clusters de nœuds capteurs en se basant sur la puissance du signal reçu et d'employer le cluster- head (CH) local comme routeur vers la station de base. Cela économisera de l’énergie puisque seul les cluster-heads effectueront une transmission vers la station de base. Le nombre optimal de cluster-Head dans un réseau de capteurs est de 5% par rapport au nombre total de nœuds. Tous les processus de données tel que la fusion et l’agrégation sont locaux aux clusters. Le cluster-head est élu périodiquement en fonction de son niveau d’énergie pour équilibrer la consommation d’énergie des nœuds [ALI-12].

Sleep

Discovery

Active

Nœud équivalent trouvé

Après Ta

Après Td

Nœud équivalent trouvé

Après Ts


43

LEACH est totalement distribué et n’a besoin d’aucune connaissance globale du réseau. Cependant il utilise un routage à saut unique ou chaque nœud peut transmettre directement au cluster-head et au puits. Mais il n’est pas applicable aux réseaux qui sont déployés sur une grande surface. De plus, le clustering dynamique ajoute une grande surcharge comme le changement des cluster-head ce qui peut diminuer le gain en énergie [LIR 02].

Figure II.9 : Structure hiérarchique en clusters

La deuxième approche présentée sur la figure II.10, est basée sur les chaînes (chaine-based approach) dont l’idée de formation de chaînes à été proposée pour la première fois dans l’algorithme PEGASIS [AKC 01], [SHN 10], [ISH 10] comme amélioration du protocole LEACH. Cette approche présente une latence extrême pour le nœud le plus éloigné sur la chaîne. Contrairement à LEACH, PEGASIS évite la formation des clusters et permet à un seul nœud dans la chaîne, l’envoi de données à la station de base [AKY 05].

Figure II.10 : Structure hiérarchique en chaines

Il existe également des protocoles qui combinent les deux approches, ils sont basés sur les clusters et les chaînes. La figure II.11 monte le principe de fonctionnement d’un protocole de ce type appelé PEGASSIS-HM proposé dans [ALI-12].


44

Figure II.11: Structure hiérarchique en clusters et en chaines

4.4 Approches hybrides

La technique de contrôle de topologie hybride utilise généralement une combinaison entre une méthode de clustering et les autres techniques comme l’algorithme CLUSTERPOW [VIK-03] qui est une amélioration de COMPOW cité précédemment. Cet algorithme définit plusieurs niveaux de clusters avec des puissances radios différentes pour des communications intra et inter clusters comme le montre la figure II.12ci après. Par exemple les nœuds d’un cluster utilisent la puissance 1 pour communiquer avec leurs voisins, les cluster-heads utlisent une puissance de 10 pour communiquer avec leurs homologues et la puissance 100 pour communication entre les cluster-head de niveau supérieur et ainsi de suite.

Figure II.12 : Principe de l’algorithme CLUSTERPOW

5. Travaux existants

Les travaux sur le contrôle de topologie qui nous intéressent ici sont ceux qui se basent sur des paramètres locaux afin de prédire ou estimer d’autres valeurs ou états ou de prendre une décision afin d’optimiser les performances. Parmi les travaux existants, nous allons citer ici les plus récents et qui proposent des techniques hybrides et distribuées afin d’optimiser la gestion de la topologie avec tolérance aux pannes.

[ARS-11 ] de Arslan Munir et al. est un travail qui utilise les modèles de Markov, il discute la modélisation markovienne des réseaux de capteurs tolérant aux pannes où le degré de tolérance d’un nœud est estimé en fonction du nombre de nœuds déployés et la probabilité de remplacement de chacun en cas de panne.

Les pannes dans un réseau de capteurs peuvent être détectées par application d’une « fuzzy inference » selon [SAF-12] de Safdar Abbas Khan et al. où les mesures d'un

Cluster1 Cluster2

P3(100)

P2(10)

P1(1)


45

nœud capteur sont comparées à des valeurs attendues par un réseau de neurones. La différence de comportement permet de détecter les anomalies.

La durée de vie d’un réseau de capteurs hiérarchique est étudiée par Bo-Chao Cheng et al. dans [CHEN-12]. Il propose un algorithme de prédiction de la durée de vie en meilleure et pire des cas dans un réseau de capteurs avec clusters à un saut où les cluster-heads doivent communiquer directement avec le sink. L’objectif est de trouver le meilleur déploiement pour ce type de topologie.

Dans [KAR-13], Karasabun et al. considère le problème de sélection d’un sous-ensemble de capteurs actifs et connectés afin de corréler la collecte de données entre ces derniers, les autres capteurs sont mis en veille. Ceci est très utile dans certaines applications, comme la surveillance de l'environnement, lorsque les données requises dépendent de l'emplacement et les données des nœuds inactifs peuvent être déduites de celles des nœuds actifs en se basant sur une fonction de corrélation spatiale.

[BEN-13] est un article dans lequel on trouve la proposition d’un algorithme d’auto-stabilisation distribuée qui réduit la puissance de transmission des capteurs, tout en garantissant une topologie qui facilite l'acheminement des paquets. Il commence par construire un arbre de recouvrement de telle sorte que le chemin dans l'arbre entre un nœud source et le Sink est caractérisé par un poids minimum. Chaque nœud mémorise le poids du chemin optimal vers la racine. Ensuite, ce poids est utilisé pour construire un backbone. Enfin la minimisation des puissances radio des nœuds permet d’obtenir un ensemble dominant en se basant sur une distance euclidienne entre chaque nœuds et ceux qui forment le backbone.

[GIR-13] traite le problème d’implémentation d’un protocole MAC basé sur le contrôle des canaux utilisés pour la communication radio. C'est-à-dire un protocole à canaux multiples. En particulier, il met le point sur la déférence entre les résultats de simulation et l’utilisation réelle d’un tel protocole vu les interférences et l’influence de l’environnement. Les limites d’une communication par canaux multiples sont discutées en développant un algorithme générique pour l’allocation des canaux radio. Cet algorithme est basé sur une technique de coloriage connue en théorie des graphes.

De même Xiaodong Wang et al. propose dans [WAN-13] une solution pour l’allocation de canaux multiples. Les auteurs donnent un certain nombre de critiques sur les solutions antérieurs dont la majorité utilise un nombre limité de canaux orthogonaux, ce qui dégrade les performances des grands réseaux avec de grands flux de données à transmettre sur les différents canaux à cause des interférences. Leurs solutions consiste à utiliser un principe de simulated annealing [JAN-96] et [LAA-86] pour trouver une solution partielle du problème d’allocation de canal radio à chaque nœud selon les canaux de ses voisins et les flux de données à transmettre. Notons ici que ce problème d’allocation de canaux est NP-complet.

Dans le même contexte, un état de l’art sur la relation entre la tolérance aux pannes et la gestion de la topologie dans un RCSF se trouve dans [MOH-14]. Les auteurs classent ces techniques en deux catégories à savoir les méthodes réactives et les méthodes proactives faisant une analyse détaillée avec comparaison entre les deux catégories.

Dans [BUC-14], les auteurs présentent une nouvelle méthodologie pour analyser les performances d’un protocole de routage dans les RCSF. La nouvelle méthodologie


46

utilise une technique d’optimisation stochastique basée sur un algorithme évolutionnaire qui consiste à générer un ensemble de topologies aléatoires qui seront analysées par la suite selon plusieurs considérations. Une étude de cas est faite sur les deux protocoles multi-hop link quality indicator et collection tree protocol. Sur la base de cette analyse, les auteurs essayent de proposer des métriques topologiques indépendantes des protocoles pour l’évaluation des performances.

Le principe de centralité (ou Betweenness centrality) est introduit dans [RAM-14] comme métrique d’évaluation des performances d’une topologie de RCSF. C’est un indicateur de la centralité d'un nœud dans un réseau. Il est égal au nombre de plus courts chemins reliant un nœud avec tous les autres nœuds du réseau. L’article fournit un algorithme distribué pour calculer cette métrique, puis montre son applicabilité pour un réseau de capteurs suivant deux scénarios à savoir la fusion des données dans un réseau orienté événement et le problème de l’équilibrage de charges afin de palier au phénomène du trou d’énergie au tour du Sink.

Une autre technique de contrôle de topologie est proposée dans [VAZ-14]. Elle utilise un principe simple pour minimiser le phénomène des interférences et overheads dus aux messages de contrôle. Pour cela, il suffit de désactiver les fonctionnalités de routage pour certains nœuds. Les performances de la méthode proposée sont évaluées en se basant sur les trois mesures de centralité les plus courantes (degree, closeness and betweenness) développées par les analystes des réseaux sociaux. Les résultats obtenus confirment la contribution de la topologie utilisée dans l’amélioration des performances.

Selon [HAI-14], on peut obtenir une bonne topologie si on arrive à déterminer le nombre optimal de Sinks à utiliser et leurs positions. Ceci est un problème NP-complet. Pour trouver une solution, les auteurs proposent d’utiliser une méta-heuristique basée sur le principe de Swarm Inteligence [CEL-10] avec un algorithme dit DPSO (Distributed Particle Swarm Optimization) basé sur une recherche locale afin de décentraliser le problème d’analyse du flux de trafic en faisant une adaptation de ce dernier pour le cas d’un réseau multi-Sink. L’analyse de flux consiste à maximiser le délai de traffic pour trouver le pire des cas, ce qui permet de calculer le nombre optimal des Sinks et leurs positions.

Enfin, dans [DEG-14], les auteurs considèrent le problème de maximiser la durée de vie d’un RCSF orienté requête dans lequel tous les nœuds capteurs sont à la fois producteurs et consommateurs de paquets. En particulier le problème de sélection d'une plage de transmission radio commune pour l'ensemble des nœuds couplé avec le choix d’un calendrier actif / sommeil de nœuds tout en assurant la connectivité et la qualité de service. Pour cela, les auteurs utilisent un modèle de programmation par entiers afin de déterminer les paramètres optimaux pour chaque période d'un horizon fini de planification.


47

6. Conclusion

Le contrôle de topologie dans les réseaux de capteurs sans fil permet une importante réduction de la consommation d’énergie et une amélioration de la qualité de service. Il est souvent associé à la problématique d’assignation de puissance de transmission. Dans les dernières années, plusieurs techniques sont apparues dans ce domaine à savoir le contrôle de puissance, le contrôle des modes de fonctionnement, les structures hiérarchiques et enfin la combinaison des techniques précédentes donnant des techniques hybrides. Ces techniques sont souvent couplées avec les capacités des réseaux de capteurs en termes de traitement distribué et coopératif afin de donner aux opérations de contrôle un aspect local. Dans ce contexte, on s’intéresse dans le chapitre suivant à l’utilisation des systèmes multi-agents pour la surveillance d’un réseau de capteurs sans fil et en particulier le contrôle de sa topologie.

Chapitre 3 Utilisation des SMA dans les RCSF

1. Introduction ............................................................................................................. 48 2. Les systèmes multi-agents ....................................................................................... 49

2.1 Définitions ........................................................................................................ 49 2.1.1 Un agent .................................................................................................... 49 2.1.2 Un système multi-agent ............................................................................. 51

2.2 Caractéristiques des SMA ................................................................................. 51 2.3 Types d’agents .................................................................................................. 54

3. Plateformes logicielles pour les SMA ....................................................................... 54 3.1 Qu’est ce qu’une plateforme SMA .................................................................... 54 3.2 Quelques plateformes SMA ............................................................................... 55

4. Application des SMA pour les RCSF ...................................................................... 56 4.1 Motivations ....................................................................................................... 56 4.2 Différentes Manièresd’introduire un SMA dans un RCSF ............................... 57

4.2.1 Nœuds capteurs comme agents .................................................................. 57 4.2.2 Agents fonctionnels .................................................................................... 58 4.2.3 Agents mobiles ........................................................................................... 58

5. Travaux SMA pour les RCSF ................................................................................. 58 5.1 Architecture logicielle des applications et services ........................................... 58 5.2 Organisation du réseau, clustering et coopération ............................................ 60 5.3 Routage ............................................................................................................. 61 5.4 Monitoring et mobilité ...................................................................................... 62 5.5 Sécurité ............................................................................................................. 63

6. Travaux SMA pour le contrôle de topologie ........................................................... 64 7. Plateformes SMA pour les RCSF ............................................................................ 65 8. Conclusion ............................................................................................................... 68


48

1. Introduction

Les réseaux d’une manière générale imposent une vision distribuée. En particulier, dans un réseau de capteurs sans fil où toute l’information est répartie sur un nombre considérable de nœuds capteurs qui font eux mêmes la source de toute action. Donc il est nécessaire de cesser de penser globalement comme l’indique C. Hewitt (Hewitt 1985), il faut penser en termes de systèmes ouverts, c’est-à-dire en termes d’interopérabilité des systèmes distribués loin de la notion séquentielle, fixe et qui gère de façon individuelle toute l’information.

Dans le domaine des RCSF, les premiers travaux de surveillance étaient dans leur majorité centralisés dans les stations de contrôle vu leurs capacités de traitement importantes et les limites de celles des nœuds capteurs. Mais avec le développement de la technologie des capteurs qui a permis une progression importante de ces derniers en termes de traitement et de stockage, un RCSF devient un vrai système distribué dans lequel tout nœud, qu’il soit fixe ou mobile, a la possibilité de coopérer avec les autres nœuds via une communication plus intelligente.

La complexité des problèmes liés au RCSF impose une vision locale. Lorsque les problèmes deviennent difficiles à être analysés globalement ou bien les solutions centralisées sont simples mais sont très couteuses en termes de communication surtout avec l’augmentation de la taille des réseaux ou le passage à l’échelle, les solutions fondées sur des approches locales ou distribuées permettent souvent de les résoudre plus rapidement.

Les systèmes multi-agent (SMA) [FER-95] se présentent ainsi comme des candidats pour la construction d’architectures ouvertes, distribuées, hétérogènes et souples, capables d’offrir une grande qualité de service dans un travail collectif, sans imposer une structure a priori, comme dit Jacques Ferber dans son ouvrage sur les SMA. En effet, la structure et le principe de fonctionnement d’un RCSF qui consiste en un ensemble de nœuds capables de capter les données et communiquer avec leurs voisins afin d’agir ou réagir suite à une situation donnée. Cela permet aux nœuds capteurs d’offrir une forte coopération et émergence avec la possibilité de s’organiser dans des structures locales qui fonctionnent avec une certaine intelligence collective. On trouve ces caractéristiques quand on parle des SMA d’une manière générale. Cela veut dire que la nature des RSCF pourrait mettre en place des protocoles conçus sur la base d’agents de différents types : intelligents, mobiles, ...etc. Les SMA ont donc pour but de simplifier la conception et l’implémentation en réduisant le raisonnement global en un raisonnement local. Cependant, certaines lourdeurs de mise en place dans des infrastructures réelles ne plaident pas favorablement pour le mixage de ces deux technologies.

Dans ce chapitre, on donnera un état de l’art sur l’utilisation des SMA dans les RCSF d’une manière générale avec une classification selon leurs objectifs. Ainsi que les motivations et avantages offerts par ces techniques. Enfin, nous focalisons notre étude sur la surveillance distribuée et le contrôle de topologie basées sur une technologie par agents.


49

2. Les systèmes multi-agents

Les systèmes multi-agents sont issus du domaine de l’intelligence artificielle distribuée. Ils représentent une approche privilégiée et adaptée aux systèmes complexes. En effet, cette approche se base sur un paradigme simplificateur qui permet de considérer un système comme un ensemble d’individus ayant des capacités d’interactions et de raisonnement.

2.1 Définitions

2.1.1 Un agent

Il n’existe pas, une définition de l’agent qui fasse foi dans le monde de l’intelligence artificielle distribuée. Il est donc nécessaire, pour avoir une bonne vision de ce concept, de confronter plusieurs de ces définitions [JAM-05]. Nous allons exploiter ici trois définitions les plus citées dans la littérature :

Jacques Ferber [FER-95] : On appelle agent une entité physique ou virtuelle qui :

a. Est capable d’agir dans un environnement, b. Peut communiquer directement avec d’autres agents, c. Est mue par un ensemble de tendances (sous la forme d’objectifs individuels ou

d’une fonction de satisfaction, voire de survie, qu’elle cherche à optimiser), d. Possède des ressources propres, e. Est capable de percevoir (mais de manière limitée) son environnement, f. Qui ne dispose que d’une représentation partielle de cet environnement, g. Possède des compétences et offre des services, h. Peut éventuellement se reproduire, i. Son comportement tend à satisfaire ses objectifs, en tenant compte des

ressources et des compétences dont elle dispose, et en fonction de sa perception, de ses représentations et des communications qu’elle reçoit.

Yves Demazeau [DEM-96]: un agent est une entité réelle ou virtuelle dont le comportement est autonome, évoluant dans un environnement qu’il est capable de percevoir et sur lequel il est capable d’agir, et d’interagir avec les autres agents. Cette définition introduit l’interaction qui est le moteur des systèmes multi-agents. En effet, l’interaction suppose la présence d’agents capables de se rencontrer, de communiquer, de collaborer et d’agir.

Mickael Wooldridge [WOO-99] : un agent est un système informatique capable d’agir de manière autonome et flexible dans un environnement. Par flexibilité on entend :

‐ Réactivité : un système réactif maintient un lien constant avec son environnement et répond aux changements qui y surviennent,

‐ Pro-activité : un système proactif (aussi appelé téléonomique) génère et satisfait des buts, son comportement n’est donc pas uniquement dirigé par des événements,


50

‐ Capacités sociales : un système social est capable d’interagir ou coopérer avec d’autres systèmes.

Les trois définitions sont basées sur des termes importants. Une entité physique est quelque chose qui agit dans le monde réel: un robot, un avion ou une voiture sont des exemples d’entités physiques. En revanche, un composant logiciel ou un module informatique sont des entités virtuelles, car elles n’existent pas physiquement.

Les agents sont capables d’agir, et non pas seulement de raisonner comme dans les systèmes classiques. L’action, qui est un concept fondamental pour les systèmes multi-agents, repose sur le fait que les agents accomplissent des actions qui vont modifier l’environnement des agents et donc leurs prises de décision futures. Ils peuvent aussi communiquer entre eux, et c’est d’ailleurs l’un des modes principaux de l’interaction existant entre les agents. Ils agissent dans un environnement, sauf pour les agents purement communicants pour lesquels toutes les actions se résument à des communications.

Les agents sont dotés d’autonomie. Cela signifie qu’ils ne sont pas dirigés par des commandes venant de l’utilisateur (ou d’un autre agent), mais par un ensemble de tendances qui peuvent prendre la forme de buts individuels à satisfaire ou de fonctions de satisfaction ou de survie que l’agent cherche à optimiser. On pourrait dire ainsi que le moteur d’un agent, c’est lui-même. C’est lui qui est actif.

Les agents n’ont qu’une représentation partielle de leur environnement, c’est-à dire qu’ils n’ont pas de vision globale de tout ce qui se passe. C’est d’ailleurs ce qui se passe dans les réalisations humaines d’envergure dans lesquelles personne ne connait tous les détails de la réalisation, chaque spécialiste n’ayant qu’une vue partielle correspondant à son domaine de compétence.

L’agent est ainsi une sorte d’organisme vivant dont le comportement, qui se résume à communiquer, à agir et, éventuellement, à se reproduire, vise à la satisfaction de ses besoins et de ses objectifs à partir de tous les autres éléments (perceptions, représentations, actions, communications et ressources) dont il dispose [FER-95].

Figure III.1: Principe général d’un agent

Un agent

Raisonnement

Perception Action

Environnement


51

2.1.2 Un système multi-agent

On appelle système multi-agent (ou SMA), un système composé des éléments suivants:

1. Un environnement E, c’est-à-dire un espace disposant généralement d’une métrique.

2. Un ensemble d’objets O. Ces objets sont situés, c’est-à-dire que, pour tout objet, il est possible, à un moment donné, d’associer une position dans E. Ces objets sont passifs, c’est-à-dire qu’ils peuvent être perçus, créés, détruits et modifiés par les agents.

3. Un ensemble A d’agents, qui sont des objets particuliers (A O), lesquels représentent les entités actives du système.

4. Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux.

5. Un ensemble d’opérations Op permettant aux agents de A de percevoir, produire, consommer, transformer et manipuler des objets de O.

6. Des opérateurs chargés de représenter l’application de ces opérations et la réaction du monde à cette tentative de modification.

7. Il existe un cas particulier de systèmes dans lequel A = O, et E est égal à l’ensemble vide. Dans ce cas, les relations R définissent un réseau où chaque agent est lié directement à un ensemble d’autres agents [FER-95].

Selon [HOA-12], On peut définir la structure et le fonctionnement émergents d’un SMA sous forme de deux principes : Principe 1 : Un système multi-agents se compose d’un ensemble d’agents (A), de l’environnement (E) où ils habitent, d’un ensemble d’interactions possibles (I), et d’une organisation (O) dans laquelle ils évoluent.

SMA = Agent + Environnement + Interaction + Organisation Principe 2 : L’intelligence collective est associée à une fonction résultant de l’émergence issue de la succession des interactions déroulées entre des agents et leur environnement. Ce principe montre que la fonction collective du système multi-agents est égale à la somme des fonctionnalités individuelles de chaque agent additionnée à l’intelligence collective engendrée par l’émergence.

Fonction (SMA) = ∑ fonction (Agent) + émergence

2.2 Caractéristiques des SMA

Le caractère ouvert : Les systèmes multi-agents partagent les caractéristiques des systèmes ouverts. Les entités élémentaires du système, que sont les agents, n’ont pas la possibilité d’avoir une représentation complète de l’environnement. Le système dans sa globalité, doit être modulaire et extensible. La modularité concerne le fait que le système multi-agent est composé de plusieurs sous systèmes mis en relation. Ces sous-systèmes ont chacun leur propre mode de fonctionnement. L’extensibilité se traduit par le fait que le système multi-agent supporte l’ajout et le retrait dynamique d’éléments. Ces éléments peuvent bien sûr être des agents, mais aussi des rôles, des connaissances ou des liens [JAM-06].


52

L’autonomie : La définition d’un système multi-agent aborde une notion essentielle qui est l’autonomie. En effet, ce concept est au centre de la problématique des agents. L’autonomie est la faculté d’avoir ou non le contrôle de son comportement sans l’intervention d’autres agents ou d’êtres humains.

La communication : Une autre notion importante abordée par cette définition concerne la capacité d’un agent à communiquer avec d’autres. La communication est toujours considérée comme un sujet très important pour un système multi-agent. Elle permet aux agents d’échanger les différentes informations et de coopérer afin d’atteindre un but commun. Cette importance a permet l’apparition de plusieurs langages spéciaux pour la communication connus par les ACLs (Agent Communication Language) comme par exemple KQML (Knowledge Query and Manipulation Language) et le langage de communication d’agent de FIPA (Foundation for Intelligent Physical Agents : http://www.fipa.org).

L’apprentissage : C’est une opération qui permet au système multi-agent d’acquérir de nouvelles connaissances ou lorsqu’il réorganise ses connaissances actuelles pour en faire un meilleur usage.

L’émergence : Comme nous l’avons constaté précédemment, de la mise en relation des agents situés dans un même environnement et qui interagissent, peuvent émerger différents phénomènes. L’émergence traite de l’apparition soudaine non programmée et irréversible de phénomènes dans un système (éventuellement multi-agent). On peut classer en trois catégories les phénomènes émergents: l’émergence structurelle, l’émergence de comportements et l’émergence de propriétés.

Il est difficile de qualifier la caractéristique émergente d’un phénomène. Selon la littérature, on peut affirmer qu’un phénomène est émergent si :

• On a un ensemble d’agents interagissant via un environnement dont l’état et la dynamique ne peuvent pas être exprimés dans les termes du phénomène émergeant à produire mais dans un vocabulaire ou une théorie D.

• La dynamique des agents en interaction produit un phénomène global comme par exemple une trace d’exécution ou un invariant.

• Le phénomène global est observable soit par les agents (sens fort) soit par un observateur extérieur (sens faible) en des termes distincts de la dynamique sous-jacente D c’est-à-dire un autre vocabulaire ou une théorie D’.

Pour fournir à un système multi-agent une fonctionnalité particulière, on peut donc avoir recours à une autre méthode que celle utilisée traditionnellement et qui consiste à procéder à une décomposition fonctionnelle du problème en un ensemble de primitives qui seront implantées dans les agents. L’alternative proposée par l’approche «fonctionnalité émergente» [PIC-04] a pour objectif de faire émerger les fonctionnalités à partir des interactions entre les agents (ou sous-systèmes multi-agents dans le cadre de systèmes multi-agents imbriqués). Les avantages sont un renforcement de la robustesse du système qui devient très adaptatif, et une simplification de la conception, il n’est pas nécessaire que le concepteur envisage toutes les possibilités pour chaque situation [JAM-06].


53

Figure III.2 : Emergence dans les SMA

La figure précédente montre que l’ensemble forme une organisation caractérisée par une forte émergence par interaction et coopération pour atteindre certains objectifs.

L’auto-organisation : L’auto-organisation est articulée autour de trois points [CAL-97] et [JAM-05] qui sont :

• Un mécanisme qui permet de détecter les meilleures conditions d’apparition du phénomène d’auto-organisation, de décrire la sensibilité des différents paramètres qui l’influencent. Cette tâche est distribuée sur les différents composants des organisations. Cette opération consiste, au niveau de l’organisation, à trouver les agents qui sont dans un état dit instable (l’agent ne sera stable que si ses aspirations, fixées par le rôle qu’il tient dans l’organisation, sont satisfaites). Les agents ayant en commun certaines caractéristiques sont regroupés et signalent, aux autres agents de la société, par un message de recomposition qu’ils peuvent participer au phénomène émergent.

• L’apparition du phénomène : ce mécanisme est chargé d’agréger les agents et d’assurer la persistance de la structure. L’interprétation des messages de recomposition conduira à la constitution de la société, l’établissement des relations entre les agents et la création des groupes.

• L’arrêt du développement du phénomène nécessite de repérer les agents qui sont stables, il est donc nécessaire de procéder à des observations.

La coordination: La coordination est un aspect important pour assurer un travail collectif efficace entre les différents agents. Plusieurs approches de coordination sont distinguées [WOO-02]:

• Coordination par planification: Le principe est d’échanger les informations entre les agents coopérants afin d’atteindre des conclusions communes sur le processus de résolution du problème. Effectivement, chaque agent génère un plan local pour le problème en question. Ces plans vont être échangés entre les différents agents afin d’atteindre une vue globale du problème.


54

• Coordination par modélisation mutuelle: Le principe est que chaque agent se met à la place de l’autre et essaye de savoir ses croyances et ses intensions afin de prédire les actions à faire.

• Coordination basée sur des lois sociales: Pour assurer une coordination efficace et cohérente, les agents utilisent des normes, comparables à nos normes sociales de coordination, qui peuvent être prédéfinies ou définies au cours de la vie du système.

• Coordination à travers les buts communs : Quand un groupe d’agent est engagé dans une activité de coopération, ils ont un but commun en plus de leurs buts individuels. Dans ce cadre, Levesque et al. [LEV-90] ont défini la notion de but persistant commun (JPG: Joint Persistent Goal).

2.3 Types d’agents

Dans le domaine des SMA, il existe en fait plusieurs types d’agents, qui selon les capacités qu’ils possèdent, seront qualifiés de réactifs, cognitifs ou hybrides.

Agents cognitifs : Les agents à capacités cognitives proviennent d’une métaphore du modèle humain. Ces agents possèdent une représentation explicite de leur environnement, des autres agents et d’eux-mêmes. Ils sont aussi dotés de capacités de raisonnement et de planification ainsi que de communication. Ces agents sont structurés en société où il règne donc une véritable organisation sociale. Le travail le plus représentatif de cette famille d’agents porte sur le modèle BDI (Believe Desir Intention) [RAO-95]. Les sources de ces travaux sont les sciences humaines et sociales.

Agents réactifs : Les agents à capacités réactives ne possèdent pas de moyen de mémorisation et n’ont pas de représentation explicite de leur environnement, ils fonctionnent selon un modèle stimuli/ réponse. En effet, dès qu’ils perçoivent une modification de leur environnement, ils répondent par une action programmée. L’exemple le plus célèbre est celui de la fourmilière étudié par Alexis Drogoul [DRO-93]. Les sources des travaux sur ce type d’agents sont les sciences de la nature et de la vie.

Agents hybrides : Les agents hybrides sont des agents ayant des capacités cognitives et réactives. Ils conjuguent en effet la rapidité de réponse des agents réactifs ainsi que les capacités de raisonnement des agents cognitifs. Cette famille regroupe des agents dont le modèle est un compromis autonomie/coopération et efficacité/complexité. Pour illustrer cette famille, on peut citer l’architecture ARCO [ROD-94] créé dans le cadre de la robotique collective, l’architecture ASIC [BOI-96] utilisée pour le traitement numérique d’images et l’architecture ASTRO [OCC-98] développée pour être utilisée dans les systèmes multi-agents soumis à des contraintes temporelles.

3. Plateformes logicielles pour les SMA

3.1 Qu’est ce qu’une plateforme SMA

Avec l’apparition de l’intelligence distribuée et en particulier les systèmes multi-agents, plusieurs produits logiciels sont développés pour le développement et l’exécution des programmes qui utilisent cette technologie. Ces outils sont souvent appelés


55

plateformes multi-agents et mettent en œuvre le principe distribué, collaboratif et intelligent des SMA avec le niveau d’abstraction et d’encapsulation nécessaire. D’une manière générale, un outil est qualifié en environnement ou plateforme de développement des systèmes multi agents s’il possède les caractéristiques suivantes:

• Permettre la diminution de l’effort de l’implémentation et par conséquent accélérer le processus de production des systèmes.

• Simplifier le processus de conception et d’implémentation des systèmes relativement complexes.

• Mettre en œuvre en abstraction les principaux paradigmes des SMA comme l’interaction, la communication et la coordination.

• Fournir un environnement de déploiement et d’exécution des systèmes multi-agents.

• Offre des systèmes adaptables et extensibles selon les besoins.

On peut remarquer qu'une bonne partie des langages portent sur les approches BDI (Belief-Desire-Intentions). D'autre part, les langages d'interaction comme FIPA et KQML sont le plus souvent définis indépendamment des modèles ou des types d'agents utilisés, ce qui permet aux concepteurs de choisir leurs propres architectures d'agents. Pourtant, on se trouve face à un dilemme : soit on laisse le modèle d'agent totalement libre et on garde un niveau d'abstraction très élevé et peu opérationnel pour le langage soit on fournit un langage opérationnel mais qui contraint fortement le modèle et la programmation des agents.

Afin de réaliser une opérationnalisation plus accessible des systèmes multi-agents, des travaux ont tenté de réutiliser des architectures et des langages existants pour construire des environnements de développement de ces systèmes. Ces outils sont nécessaires pour renforcer le succès de la technologie multi-agents. Ils permettent aux développeurs de concevoir et réaliser leurs applications sans perdre de temps à réaliser des fonctions de base pour la création et l'interaction entre agents et éliminent, dans la plupart des cas, la nécessité d'être familiarisé avec les différents concepts théoriques des systèmes multi-agents.

3.2 Quelques plateformes SMA

Dans cette section, on donne un aperçu sur les plateformes multi-agents les plus répondues. Et cela sans entrer dans les détails qui font déférences entre un environnement et une plateforme. Un environnement est utilisé pour le développement tendit qu’une plateforme sert à l’exécution des SMA.

AgentBuilder [AGB] est un environnement de développement complet basé sur une modélisation orientée-objet avec une partie ontologie. L’élaboration du comportement des agents se fait à partir du modèle BDI et le langage KQML pour la communication entre les agents. AgentBuilder est un outil complexe qui demande des efforts d’apprentissage importants et de bonnes connaissances dans le domaine des systèmes multi-agents.

AgentTool [AGT] qui est actuellement à la version 3 (aT3) est un environnement de développement graphique en Java pour aider les utilisateurs à analyser, concevoir et implémenter des systèmes multi-agents. Il utilise la nouvelle méthodologie basée sur l’organisation O-MaSE (Organization-based Multiagent Systems Engineering) qui suit un processus purement orienté objet.


56

Jack [JAC] est décrit comme étant un environnement pour construire, exécuter et intégrer des systèmes multi-agents commerciaux, écrits en Java et utilisant une approche orientée composants. La particularité de Jack est sa forte orientation vers la programmation agent, ce qui mène à une grande versatilité, l'architecture des agents pouvant aller du comportement simplement réactif au BDI complet.

JADE [JAD] (Java Agent DEvelopement framework) est une plate-forme multi-agent open source créée par Telecom ItaliaLab, un laboratoire italien de télécommunication. Elle permet le développement des systèmes multi-agents et d'applications conformes aux normes FIPA. Elle est implémentée en JAVA et possède trois modules principaux : DirectorFacilitor qui fournit un service de tableau de bord pour présenter l’architecture du système d’une manière simple, Agent Communication Channel pour la gestion des communications entre les agents et Agent Management System pour la supervision de l'enregistrement des agents, leur authentification, leur accès et l'utilisation du système.

MadKit (Mutlti-agents Developpement Kit) [MDK] est un environnement écrit en Java basé sur la méthodologie Aalaadin ou AGR (agent/ groupe / rôle). Un agent joue des rôles à l’intérieur du groupe. MadKit a été lancé en 1996 au laboratoire d’Informatique, de Robotique et de Microélectronique de Montpellier (LIRMM). L’outil fournit un éditeur permettant le déploiement et la gestion des SMA (G-box). Il offre aussi un utilitaire pour effectuer des simulations à grande échelle.

4. Application des SMA pour les RCSF

4.1 Motivations

Un réseau de capteurs sans fil est un système ouvert composé d’un ensemble de nœuds qui sont capables d’acquérir les données de leur environnement, d’effectuer un certain nombre de traitements et de communiquer avec leurs voisins. C’est une structure de réseau informatique qui est candidate de faire dérouler des protocoles assez complexes mais adaptés à la nature réduite des capteurs et surtout leurs ressources limitées. Les systèmes multi-agents ont prouvé leur efficacité dans les systèmes complexes et distribués. Pour cela, ces dernières années, plusieurs chercheurs dans le domaine des RCSF ont pensé à coupler la technologie capteurs sans fil avec celle des agents. Ces travaux consistent à utiliser des systèmes multi-agents dans les RCSF, c'est-à-dire un certain nombre d’agents portant chacun un code pouvant être exécuté par un nœud avec la possibilité de se déplacer entre les nœuds pour faire un traitement ou ramener une information. Les auteurs de [FOR-12] donnent les motivations pour ceci. Selon [RIJ-09], les avantages de cette approche sont :

• C’est une manière efficace pour supporter la scalabilité des réseaux. • Le système devient flexible et offre d’avantage d’extensibilité et d’adaptation des

tâches. • Efficacité énergétique. • Système curatif et progressif. • Dans le cas des réseaux hétérogènes, cette technique permet la construction des

composantes ou groupes indépendants et supporte l’interaction entre ces derniers via des interfaces personnalisées selon les besoins.


57

• Interopérabilité avec les systèmes existants. C'est-à-dire faciliter l’intégration avec les logiciels classiques.

D’un point de vue programmation et fonctionnement, l’utilisation de la technologie agent dans les RCSF a plusieurs avantages par rapport à l'approche classique. Premièrement, le contrôle est totalement distribué c'est à dire qu'il y'a pas de centralisation de décision. En plus, il y a une distinction de deux niveaux qui sont le niveau individuel, c'est-à-dire le fonctionnement du capteur en lui-même avec le code qui définit son comportement local, et le niveau collectif obtenu lors de l’intégration de plusieurs agents qui vont définir le comportement global du système qui est le réseau de capteurs. Le comportement global est obtenu par émergence. Finalement, et pour l’implémentation, un agent est vu comme un objet qui encapsule un état qui représente les paramètres et les données du capteur et un comportement qui est traduit par les algorithmes qui manipulent ces données. Mais l'agent a toujours le contrôle sur son environnement de différentes manières (réactif, dirigé par des buts ou social) tout en restant autonome.

En ce qui concerne la mobilité des agents, elle offre un apport important aux RCSFs qui fonctionnent en multi-agents. En effet, le réseau devient évolutif et adaptatif dans le sens où on peut changer son comportement simplement en faisant migrer l’agent correspondant vers le nœud en question. Cette fonctionnalité est très utile pour le chargement d’une application dans un RCSF même si les nœuds sont déjà déployés ou encore envoyer le code de traitement d’une grande masse de données au lieu de faire un transfert de cette dernière.

4.2 Différentes Manières d’introduire un SMA dans un RCSF

L’aspect décentralisé des algorithmes utilisés dans les RCSFs a fait que les solutions basées sur des systèmes multi-agents sont appréciées dans ce domaine. Dans cette section, on présentera quelques exemples de travaux qui ont été proposés dans ce cadre afin de montrer une distinction entre ces travaux en termes d’aspect distribué qui a conduit à l’utilisation d’un SMA. En quelque sorte, c’est une classification selon la manière dont le SMA est introduit dans un RCSF. Pour chaque catégorie, on donne une illustration des contributions dans le même contexte. Une autre classification par objectifs de ce type de contributions sera donnée en détails plus loin dans ce chapitre.

4.2.1 Nœuds capteurs comme agents

Chaque nœud est considéré comme une entité autonome dans un système distribué qui est le RCSF, il est représenté par un agent capable de prendre des décisions locales qui par émergence auront un impact sur le comportement du système en entier. Plusieurs contributions ont été proposées dans ce contexte. Par exemple, dans [MER-05] de Mertsock et Stawski, le réinforcement des routes qui est le principal problème du protocole Directed Diffusion est traité. Pour cela, ils ont proposé une solution considérant le RCSF comme un ensemble d’agents autonomes dont chacun exécute un système expert avec une base de connaissances et des règles d’inférence relatives à son environnement. La décision incrémentale donne à l’agent un certain degré de flexibilité lui permettant d’adapter ses décisions au changement de l’environnement, comme par exemple le changement de position en cas de défaillance d’un voisin.


58

4.2.2 Agents fonctionnels

Dans ce type d’approche chaque nœud capteur peut contenir un ou plusieurs agents fonctionnels qui ne sont pas forcément identiques dans les autres nœuds, chacun d’eux est responsable d’accomplir une tâche spécifique et collabore avec les autres agents afin d’améliorer les performances du nœud. Comme illustration des travaux adoptant ce principe, on peut citer [HUS-06] qui propose une architecture basée SMA pour faciliter la conception, la mise en œuvre et la maintenance des RCSFs hiérarchiques. Le principe est simple, il s’agit d’affecter un agent à chaque niveau du Sink au nœud simple passant par les différents niveaux de clusters.

4.2.3 Agents mobiles

Les agents mobiles sont des agents capables de se déplacer à travers le réseau, et se ré- exécuter sur un site distant. Dans le cas des réseaux de capteurs, on peut relever deux catégories d’agents:

Le message de données est un agent mobile: Dans ce cas de figure, chaque message de données allant de la source vers la destination est un agent mobile qui tente de construire le chemin le plus efficace en énergie selon l’état de chaque nœud traversé. Dans l’article [GAN-03], on introduit une approche de routage dans les réseaux de capteurs sans fil basée sur des agents mobiles autonomes capables de prendre leurs propres décisions en se basant sur leurs informations locales pour créer et maintenir des routes à efficacité énergétique.

Le code de traitement est un agent mobile: Dans ce cas, au lieu de faire

circuler une grande quantité de données des nœuds vers la station de base comme dans le paradigme client-serveur, des agents mobiles sont envoyés depuis la station de base vers les nœuds pour réaliser les traitements nécessaires. Cette approche est illustrée dans les articles [KET-05] et [QI-03].

5. Travaux SMA pour les RCSF

Un nombre considérable de recherches est intéressé ces dernières années par les traitements distribués dans les RCSF basés sur la technologie agent. Nous donnons ici une classification non exhaustive de ces travaux de contribution selon leurs objectifs et niveaux d’intégration dans un RCSF, un travail peut être aussi multi-objectif. Une autre classification se trouve aussi dans [FOR-12].

5.1 Architecture logicielle des applications et services

Se sont des travaux à un niveau d’abstraction élevé dont le but est de concevoir des architectures à base d’agents adaptées aux caractéristiques d’un RCSF. Dans l’article [QI-03], on vise à développer une solution collaborative basée sur les agents mobiles pour répondre aux besoins particuliers des réseaux de capteurs sans fil. Les auteurs ont mis en évidence le conflit qui peut exister en essayant d’assurer l’optimisation d’énergie et la tolérance aux pannes. En général, les approches visant à augmenter l’efficacité énergétique ont tendance à limiter les redondances dans les algorithmes. Par contre, la redondance est nécessaire pour assurer la tolérance aux pannes. Un équilibre doit être trouvé entre ces deux objectifs. Ils estiment que l’approche basée sur des agents mobiles est la meilleure solution pour résoudre ce genre de conflits. Dans cette approche, chaque agent comprend quatre attributs :


59

• L’identificateur : Il est défini exclusivement pour un agent donné. • L’itinéraire : C’est la route à emprunter par l’agent lors de sa migration. Elle

peut être prédéfinie ou dynamique selon l’état du réseau. • Le code : Il doit être transformé et intégré sur le nœud capteur à l’arrivée de

l’agent. • Les données globales : Elles sont mises à jour à chaque migration.

Ces agents sont créés au niveau de la station de base. Ils parcourent un certain nombre de nœuds en collectant les informations et en suivant un itinéraire bien défini avec la possibilité de l’adapter en cas de défaillance, pour retourner à la station de base. Ceci permet à la fois d’augmenter la tolérance aux pannes et d’optimiser la consommation d’énergie.

L’article [KET-05] propose un paradigme agents mobiles pour les RCSFs dans le but

est de réduire la consommation énergétique et d’augmenter ainsi la durée de vie des capteurs. Au lieu d’envoyer directement les données des capteurs vers la station de base, les auteurs de cet article optent pour une autre stratégie. Elle consiste à envoyer des agents mobiles à partir de la station de base vers les capteurs pour parcourir l’ensemble du réseau et collecter les données. Les auteurs estiment que le fait d’utiliser uniquement les agents mobiles et éliminer les autres messages propagés dans le réseau peut réduire la latence, la bande-passante et la vulnérabilité des communications réseau.

Le modèle MWAC [JAM-05] cité précédemment peut faire partie de cette catégorie aussi. En effet, c’est un protocole à base d’agents qui organise les agents en groupes ayant une structure hiérarchique semblable à la technique de clustering. Les agents, c’est à dire les nœuds sont rassemblés en groupes constitués d’un seul agent représentant qui gère les communications au sein de son groupe et à l’extérieur. Un ou plusieurs agents de liaison ou gateway qui sont des intermédiaires entre le représentant du groupe et ceux des groupes voisins. Et éventuellement des agents simples membres qui sont chargés seulement de capter l’information et traiter les messages qui sont leurs destinés.

Dans [MEK-06], S.Mekid introduit la notion du capteur intelligent dans le cas général, il propose une architecture d’un tel capteur et explique ses fonctionnalités nécessaires quand il est intégré dans un environnement multi agent et la manière dont ces agents sont regroupés.

Pratik K. Biswas et al. présentent dans [PRA-07] une architecture multi-agent interopérable à travers des couches. Les auteurs prouvent l’efficacité de leur méthode par une comparaison entre l’approche client/serveur et celle multi-agent en terme de temps d’exécution et l’énergie consommée. Le travail est une extension d’un modèle existant dit modèle agent interopérable (Interoperable agent model) de [PRA-06], enfin le SMA du nouveau modèle comprend huit types d’agents :

Sensor agent (SA), Agent management system (AMS), Directory facilitator (DF) qui aide les autres agents à la coopération, Agent communication channel (ACC), Controller synthesizer (CS), Data manager (DM), Application agent (AA) et Interface agent (IA). Ces agents sont distribués dans un réseau de capteurs qui peut contenir des nœuds filaires et IP. Dans ce modèle, les communications entre agents sont assurées par des messages XML.


60

Dans [KAY-11], Kay Smarsly et al. propose une conception d’un système basé sur des agents migrants pour définir un fonctionnement dynamique dans un RCSF selon les besoins des nœuds, ce système a été testé réellement sur une plateforme pour le traitement des variations thermiques dans un environnement expérimental, les performances de fonctionnement sont améliorées par rapport aux approches classiques.

L’article [ROM-11] propose un modèle formel basé sur une logique temporelle (Real-time temporal logic) pour la spécification et l’évaluation d’un système multi-agent quand il est intégré dans un environnement de RCSF. Des agents réactifs décisionnels (Reactive Decisional Agent) sont utilisés avec étude de leurs capacités de coopération, réaction aux événements, communication et concurrence dont les performances sont encourageantes.

5.2 Organisation du réseau, clustering et coopération

Dans [SHA-05], la surveillance en continue est assurée par un réseau de capteurs hiérarchique en clusters à base d’agents. Les agents ont une capacité d’apprentissage en utilisant des algorithmes génétiques et en tenant compte de certains paramètres notamment la consommation d’énergie, le nombre et la taille des clusters. Quatre types d’agents sont définis: query agent, routing agent qui sont implantés sur la station de base, en plus de proxy query agent et proxy routing agent implantés sur les capteurs. Ces agents assurent les deux principales fonctions à savoir la gestion des requêtes et le routage.

Les auteurs de [HUS-06] considèrent le RCSF comme un SMA hiérarchique où le plus haut niveau est un agent représentant l’interface acceptant les requêtes de l’utilisateur et distribue les tâches aux agents du niveau inférieur suivant qui sont définis selon des critères géographiques et autres facteurs, ces agents sont gérés par des agents régionaux, chaque région est devisée en sous régions appelées clusters gérés par des agents de clusters, à la fin de cette hiérarchie, se sont les agents de requêtes qui sont les nœuds capteurs proprement dits.

Afin de faciliter la conception et l’implémentation des RCSF, Xue Wang et al. propose dans [Xue-07-a] un modèle comme combinaison entre agents mobiles et un SMA. L’architecture proposée est hiérarchique structurée selon les rôles joués par chaque capteur dans le réseau. Le SMA est utilisé pour la collaboration tendit que les agents mobiles pour l’échange de données. Ce modèle est utilisé pour la localisation et la classification des cibles acoustiques.


61

Figure III.3 : Le modèle du SMA utilisé dans [Xue-07-a]

Un modèle logique de clustering adapté au fonctionnement multi agent est présenté dans [JAB-08]. Il divise les nœuds en une hiérarchie de quatre niveaux : atome qui est le nœud proprement dit, micro qui représente un groupe de nœuds gérés par un cluster head, meso qui est le niveau supérieur de clustring regroupant un nombre de clusters de même zone et enfin un cluster virtuel représente tout le réseau. Cette structure logique peut changer suite à un événement. A chaque niveau est affecté un type d’agent en coopération avec l’agent du niveau supérieur pour accomplir le fonctionnement du réseau.

Dans [YAUN-10], l’optimisation de la consommation d’énergie et le délai de réponse est basée sur un SMA appliqué à un algorithme de collection de données pour la surveillance d’événements émergents dont le RCSF est structuré en clusters dynamiques, cette dynamique est définie par la gravité d’événement qui détermine la taille et la durée de vie d’un cluster. Les agents mobiles traversent le réseau via les clusters heads où la planification d'itinéraire pour les agents mobiles est déterminée par l’énergie résiduelle et le degré de perte dans le chemin. Les résultats de simulation montrent que le modèle multi-agent a de meilleures performances en ce qui concerne la consommation d'énergie et le délai de réponse.

5.3 Routage

Min Liu et al. s'intressent au routage dans [MIN-11]. L'article propose un nouvel algorithme de routage basé agent avec qualité de service pour les RCSF. Le SMA est utilisé pour gérer les changements de topologie et le flux de communication en participant au routage et à la maintenance des routes. La méthode est basée sur un principe de Swarm Intelligence (inspiré du système d’intelligence collective des insectes et d’autres animaux). Les facteurs de qualité de service sont les délais de latence, la perte de paquets et la conservation d’énergie. Le SMA utilisé comporte des agents de types : Forward agent FA (pour établir une connexion avec un voisin à la recherche d’une route) et Reverse agent (en réponse du FA pour construire une route).

Comme [MIN-11], les auteurs de [DAR-11] proposent une méthode dite MAM (Markovian Agent Model) basée sur le Swarm intelligence mais en utilisant un modèle markovien. Le fonctionnement des agents repose sur les transitions locales d’un nœud


62

d’un coté et les transitions des autres nœuds d’un autre coté (local transitions and induced transitions).

5.4 Monitoring et mobilité

L’article [KIM-03] propose un algorithme de routage basé sur les agents pour résoudre le problème d’avoir plusieurs stations de base mobiles. L’idée est de substituer les stations de base par des agents : quand une station de base change sont emplacement, on désigne un nœud voisin sur lequel sera implémenté un agent qui va jouer le rôle de cette station. Cet agent reçoit les données des autres nœuds (agents) et les dérige vers la station de base réelle. Ce mécanisme permet d’éviter l’adaptation des nœuds, à chaque fois, à une nouvelle position de la station de base et réduire ainsi la consommation énergétique.

Les auteurs de [GAN-03] proposent une approche de routage dans les RCSF basée sur des agents mobiles autonomes et capables de prendre leurs propres décisions en se basant sur leurs informations locales. Le routage se fait en trois étapes à savoir la diffusion d’intérêts et la création de tables de routage, le transfert de données et enfin la maintenance des routes et mise à jour des tables de routage. Les agents mobiles sont appelés dans cet article « agents de données » qui sont créés lors de la phase de transmission de données par les nœuds sources. Une fois créé, l’agent se charge de transmettre les données à la station de base en sélectionnant un itinéraire optimal en termes d’énergie.

Massaguer estime dans [MAS-05] que l’efficacité des solutions à base d’agents mobiles dans les RCSFs dépend de leur déploiement, de leur nombre et des chemins qu’ils empruntent. Pour cela, il propose que les agents mobiles suivent les chemins proposés par un algorithme génétique et les adaptent de façon dynamique selon l’état des nœuds traversés pour éviter les défaillances inattendues.

Xue Wang et al. reprennent leurs modèle de [Xue-07-a] dans [Xue-07-b] pour mettre en œuvre un système de négociation et de partage de taches dans les RCSF multimédias afin d’optimiser la gestion des ressources et le résultat de classification.

L'article [MAT-09] de Matthew D. Coles et al. s’intéresse aux RCSFs mobiles et propose un modèle bayésien dit BNGRAZ pour la gestion de cette mobilité (Bayesian network GRAZing algorithm). C’est un modèle bio-inspiré (par analogie au principe de recherche de nourriture par un groupe d’herbivores). Le RCSF considéré comporte quelques nœuds mobiles pour ajuster la couverture et la connectivité. Le choix d’itinéraire pris par un nœud mobile est basé sur la probabilité de déconnexion ou de non couverture, cette probabilité est calculée en exploitant les informations fournies par les voisins.

De même que [MAT-09], Saamaja Vupputuri et al. proposent dans [SAA-10] un fonctionnement similaire mais avec le but d’optimiser la durée de vie et satisfaire un certain degré de qualité de service demandé en utilisant des collecteurs de données qui forment des clusters en changeant de position, les mouvements sont effectués selon objectif et non pas par probabilité.

Pour optimiser le problème de scheduling de tâches et la transmission de données dans un RCSF vidéo, le travail présenté par Huang Hai-ping et al. dans [HUA-09] introduit une série d’algorithmes intelligents associés à des agents basés sur des algorithmes génétiques, colonie de fourmis ou des algorithmes mixtes.


63

Figure III.4: Un SMA pour l’allocation des tâches [HUA-09]

Chaque agent représentant un nœud décide de participer ou pas à la détection d’une cible en se basant sur les facteurs suivants:

- S: état du nœud {busy, free}. - E: le nœud possède ou pas suffisamment d’énergie pour accomplir la tâche en

cours. - α: angle de vision du caméra sur l’axe des x (de droite à gauche). - β: angle de vision sur l’axe des y (de haut en bas). - q: détermine la qualité d’image requise par le processus de surveillance.

Les résultats montrent que les algorithmes utilisés consomment moins d’énergie comparés aux performances du protocole AODV.

Une stratégie d’auto adaptation pour le scheduling des taches dans un RCSF est présentée dans [GUO-11] en se basant sur un SMA, en plus un modèle mathématique est proposé pour l’allocation dynamique des tâches. L’algorithme a un fonctionnement d’intelligence collective dite PSO (particle swarm optimization algorithm). Selon cet article, les avantages d’utiliser une approche SMA sont:

- Contribuer à analyser et concevoir formellement les activités et l’organisation du réseau.

- Etendre l’intelligence et donner une certaine autonomie au système. - Permettre de réduire la redondance des données captées et transmises. - Economiser l’énergie et étendre la durée de vie du réseau. - Permettre un fonctionnement dynamique et une flexibilité d’allocation de

tâches.

5.5 Sécurité

Liu et Wang [LIU-03] proposent une architecture basée sur les agents actifs et intégrants des mécanismes de sécurité pour les réseaux de capteurs sans fils dont l’objectif est d’assurer la flexibilité et la sécurité. Cette architecture se base essentiellement sur des agents appelés agents de gestion et de contrôle implémenté sur les nœuds du réseau. Elle comprend également un moteur d’évaluation et d’exécution, un système de chiffrement à clés symétriques et un système de gestion. Avant de créer les agents, un administrateur d’agents distribué sur le réseau est lancé par la station de base. Cet administrateur se charge de valider, vérifier et certifier les codes utilisés pour l’authentification en se basant sur les systèmes de gestion et de chiffrement et en assurant une distribution de clés. Ensuite, les applications sécurisées et les capteurs peuvent être autorisés à créer leurs propres agents qui seront utilisés pour la gestion et le contrôle.


64

J.P Jamont et al. propose dans [JAM-11] une extension du protocole MWAC [JAM-05], cette extension est nommée trust MWAC, qui utilise un modèle léger de gestion de la confiance afin d’assurer une auto-organisation sécurisée. C’est une nouvelle approche adaptée aux systèmes multi-agents ne pouvant bénéficier d’infrastructure d’authentification et dans lesquels l’identité des agents est incertaine ce qui est mieux adapté aux RCSF. La notion de confiance est utilisée pour estimer la fiabilité d’un voisinage dans son ensemble, cette fonction est dite trust est initialisée à 1 et prend des valeurs entre 0 et 1. Un voisinage indigne de confiance doit être interprété comme incluant au moins un agent malveillant ou défaillant. Un agent malveillant peut être détecté de manière sûre et seulement suspecté en analysant les messages émis par ce dernier conduisant à une valeur trust abaissée. Lorsqu’un agent croit que son voisinage n’est pas digne de confiance, il adopte un fonctionnement dégradé n’effectuant que les tâches minimales attendues de lui. En effet, la mobilité, même faible, du réseau fait qu’un nœud malveillant peut être amené à quitter un voisinage. Il peut aussi être tout simplement retiré du réseau ou ne plus fonctionner faute d’énergie.

[HAM-13] propose un nouvel algorithme pour la détection des attaques de type Sinkhole en se basant sur des agents mobiles. Le principe est simple et utilise des tables pour suivre les agents valides. Un message provenant d’un agent non inscrit sur ces tables est considéré comme malveillant.

6. Travaux SMA pour le contrôle de topologie

L’équipe du projet [TYN-05] propose une solution basée sur un SMA et des algorithmes utilisant les techniques d’interpolation qui consistent à estimer la valeur d’une fonction entre deux valeurs connues pour augmenter la durée de vie d’un réseau de capteurs sans fil. En effet, si une information contenue dans un nœud peut être estimée en utilisant la fonction d’interpolation avec une certaine exactitude, ce dernier est mis en veille permettant ainsi de réduire le nombre de nœuds intervenant au processus de captage. Cette solution peut être résumée comme suit :

• Des agents dits coordinateurs sont désignés selon certains critères de capacité. Ils se chargent de l’agrégation de données et de la distribution de tâches en désignant les nœuds qui doivent être mis en veille.

• Le coordinateur envoie des requêtes à un sous ensemble d’agents appelés agents capteurs pour calculer les paramètres de la fonction dite d’interpolation.

• Dès la réception des réponses, le coordinateur, en tenant compte de l’emplacement spécifique de chaque agent, calcule les marges d’erreur entre les différents capteurs. S’il y a des marges tolérables, certains nœuds vont être mis en veille.

Ces opérations vont être répétées périodiquement et les nœuds en veille vont être réveillés pour vérifier s’ils sont toujours redondants.

Afin de prolonger la durée de vie d’un RCSF, le problème du trou d’énergie est traité dans [MUR-12] en se basant sur un SMA fondé sur le principe du Swarn Intelligence. Il propose un algorithme de routage à la demande et multi-chemin qui utilise un principe inspiré de l’intelligence de colonies qui supporte la mobilité des Sinks. La sélection des routes est faite par un algorithme de colonie de fourmis (dit aussi Soldiers) qui calcule une probabilité de saut d’un nœud à un autre sur la base de phéromone qui exprime la fréquence d’utilisation d’un chemin.


65

Figure III.5: Construction de route entre deux nœuds S et D [MUR-12]

7. Plateformes SMA pour les RCSF

En général, et pour la programmation des systèmes multi-agents, il existe plusieurs plateformes dont nous avons cité les plus importantes dans la troisième section de ce chapitre. Par contre, pour l’intégration des SMA dans le domaine des RCSF et vu que ce couplage des deux technologies vient d’être introduit, on trouve un certain nombre de plateformes ou environnements multi-agents destinées aux RCSF. Leurs objectifs est de permettre la programmation sélective des capteurs. Il est à noter que ces travaux sont généralement développés au sein de laboratoires de recherche et ils sont exposés aux améliorations et adaptations, donc ne sont pas encore standardisés. Dans ce qui suit, on donne un aperçu sur trois plateformes qui sont les plus connues dans ce domaine, les deux premières sont conçues pour TinyOS donc basées sur le langage NesC et la troisième basée sur le langage Java. D’autres plateformes ne sont pas détaillées ici comme WISEMAN [GON-06], AgentScape [KAN-04] et Shakshuki [SHA-08].

7.1 Agilla

Agilla [FOK-09] est un environnement multi agent pour un RCSF qui fonctionne en TinyOS. Développé en 2008 par C.L FOK et al. Au laboratoire MobiLab (Mobile Computing Laboratory) de l’université de Washington (http://www.mobilab.wustl.edu/projects/agilla/). Le package Agilla contient générallement trios modules qui sont Agilla's mote firmware écrit en langage NesC et permet de chager les agents sur un capteur, Agilla's AgentInjec écrit en Java qui permet d’injecter un agent dans l’environnement et enfin le module Agilla mobile agents qui contient des exemples d’agents intégrés dans Agilla. La principale caractéristique de cet environnement est qu’il supporte un fonctionnement en plusieurs agents sur le même nœud avec la possibilité de migration. La figure ci-après montre l’architecture de base d’Agilla. Pour chaque nœud, il fournit deux types de ressources qui sont l’espace de tuples (tuple space) et la liste des voisins. L’éspace de tuples est un éspace mémoire partagé où sont structurées les données qui peuvent être déposées ou retirées ce qui permet aux nœuds d’échanger des informations. Agilla supporte aussi la migration des agents. C'est-à-dire qu’un agent peut se déplacer d’un nœud à un autre portant son état et son code en utilisant des paquets de petite taille.


66

Figure III.6 : Architecture d’Agilla

Principalement, Agilla a été testé par son développeur avec trois applications qui sont le suivi des feux de forets, le suivi des marchandises et la navigation des robots. Dans les deux premières applications, il utilisait des réseaux constitués de capteurs Mica2 et TelosB. Selon [FOK-09] cet environnement multi-agent offre les performances montrées dans le tableau suivant :

Capteurs Mémoire Code

Mémoire Données

Temps de migration à

un saut

Temps d’accés distant aux

tuplesMica2 57 KB 3.3 KB 0.3 sec 55 msTelosB 45 KB 3.4 KB - -

Tableau III.1 : Comparaison entre les capteurs Mica2 et TelosB

7.2 ActorNet ActorNet [KWO-06] est une plateforme multi-agent conçue spécialement pour les

capteurs Mica2/TinyOs. Afin de palier aux difficultés de migration d’agents et d’interopérabilité dues au fort couplage entre les applications et l’architecture des nœuds capteurs, ActorNet offre plusieurs services comme la mémoire virtuelle, le changement de contexte, la communication asynchrone et le fonctionnement multitâche comme le montre la figure III.7 ci-après. C’est une machine virtuelle qui supporte l’intégration de plusieurs acteurs, qui sont ici des agents, dans le même nœud comme Agilla. Par contre ActorNet ne permet pas l’interopérabilité entre les réseaux hétérogènes. ActorNet utilise un langage de haut niveau dit actorNet language pour la programmation des agents avec une syntaxe spéciale.


67

Figure III.7 : Architecture d’ActorNet

7.3 MAPS

MAPS (Mobile Agent Platform for Sun SPOTs)[AIE-11] est un environnement basé sur Java pour le développement et l’intégration des applications de réseaux de capteurs sans fil qui utilisent la technologie multi-agent grâce à un certain nombre de services qui sont nécessaires pour les agents mobiles comme la transmission de messages, la création d’agents, le clonage d’agents, la migration d’agents et la gestion de timers avec un accès facile aux ressources du capteurs. MAPS permet la programmation d’application à travers trois paradigmes importants dans la programmation des RCSF à savoir le paradigme basé événement, basé état et orienté agent. La figure ci-après montre les composants MAPS pour un nœud capteur.

Figure III.8 : Architecture de la plateforme MAPS


68

La figure III.8 montre les déférentes composantes de la plateforme MAPS et qui sont chargés de :

- L’agent mobile proprement dit MA (Mobile Agent). - L’exécution des agents après migration par le module MAEE (Mobile Agent

Execution Engine). - La gestion de la mobilité des agents par MAMM (Mobile Agent Migration

Manager). - La gestion des communications entre les agents par le module MACC (Mobile

Agent Communication Chanel). - L’identification des agents par le module MAN (Mobile Agent Naming). - La gestion des timers par le module TM (Timer Manager). - La gestion des ressources par la composante RM (Ressource Manager).

8. Conclusion

Malgré les difficultés qui entourent la tâche d’intégration des systèmes multi-agents dans les réseaux de capteurs sans fil surtout le caractère limité des capteurs en terme de ressources comme l’espace mémoire, la bande passante et l’énergie, selon la littérature, c’est une technique prometteuse qui peut donner une autre dynamique aux RCSFs avec plus d’intelligence collective et coopérative. En effet le paradigme agent permet de créer des entités autonomes mais coopérantes qui à partir d’un raisonnement simple peuvent donner un fonctionnement émergent.

Dans le chapitre suivant, nous allons détailler une contribution dans ce contexte en particulier l’utilisation d’un système multi-agent pour le contrôle de topologie d’un réseau de capteurs sans fil.

Chapitre 4 Proposition d’une approche distribuée pour le contrôle de topologie d’un RCSF 1. Introduction ............................................................................................................. 69 2. La problématique .................................................................................................... 69 3. Travaux existants .................................................................................................... 71 4. Détails sur le protocole CTP ................................................................................... 72

4.1 Définition .......................................................................................................... 72 4.2 Structure du protocole CTP ............................................................................. 72

4.2.1 Routing Engine (RE) ................................................................................. 72 4.2.2 ForwardingEngine(FE) .............................................................................. 72 4.2.3 Link Estimator (LE) .................................................................................. 73

4.3 Structure des donnée en CTP .......................................................................... 73 4.3.1 La trame de données .................................................................................. 73 4.3.2 Structure de routage CTP ......................................................................... 74

5. Proposition d’une amélioration du CTP ................................................................. 76 5.1 Modèle du réseau .............................................................................................. 76 5.2 Construction de topologie ................................................................................. 77 5.3 Contrôle de topologie ........................................................................................ 77 5.4 Structure des trames ......................................................................................... 79

6. Etude de performances par simulation .................................................................... 81 6.1 Pour quoi simuler ............................................................................................. 81

6.1.1 Le simulateur J-Sim ................................................................................... 81 6.1.2 Le simulateur NS ....................................................................................... 81 6.1.3 OPNET ...................................................................................................... 82 6.1.4 OMNET++ ............................................................................................... 82

6.2 Choix d’un simulateur ...................................................................................... 82 7. Environnementde simulation ................................................................................... 83

7.1 Présentation ...................................................................................................... 83 7.2 Méthodologied’utilisation ................................................................................. 83 7.3 Modèle de Castalia ........................................................................................... 85

8. Détails de l'implémentation ..................................................................................... 86 9. Paramètres d’évaluation .......................................................................................... 88

9.1 La durée de vie ................................................................................................. 88 9.2 Changement de parent ..................................................................................... 88 9.3 Energie consommée ........................................................................................... 89 9.4 Hypothèses ........................................................................................................ 89

10. Résultats et analyse ................................................................................................. 89 11. Conclusion ............................................................................................................... 94

Chapitre 4: Proposition d’une approche distribuée pour le contrôle de topologie d’un RCSF

69

1. Introduction

Dans un réseau de capteurs sans fil, la topologie choisie joue un rôle très important pour les performances du réseau surtout la qualité de service et l’utilisation des ressources. Il y a une relation directe entre la topologie utilisée et la durée de vie comme nous l’avons évoqué dans le chapitre précédent. Les approches hybrides de contrôle de topologie exploitent tous les paramètres du nœud lui-même et son voisinage pour construire et maintenir une topologie optimale et tolérante aux pannes.

Plusieurs travaux basés sur le calcul d'une ou plusieurs métriques pour contrôler la topologie existent. [YIN-12] calcule une probabilité de défaillance d'un nœud, [CHEN-12] utilise un algorithme de prédiction de la durée de vie de chaque nœud, tandis que [GNA-09] penche vers l'évaluation de la qualité d'une liaison entre deux nœuds capteurs. La principale différence entre ces travaux réside dans le choix des paramètres réseau, et la manière de calculer les valeurs de ces paramètres en question.

Dans ce contexte, nous proposons au cours de ce chapitre une autre approche de contrôle de topologie d’un RCSF en se basant sur une nouvelle métrique pour laquelle nous utiliserons l'évaluation de la qualité des liens inspirée de [OMP-09] en ajoutant l'état de la batterie du nœud ainsi que le nombre de sauts vers le Sink qui est considéré aussi au moment d'un changement de topologie. Ce principe permet d'exprimer en même temps la durée de vie et la tolérance aux pannes par exploitation de l'état de la batterie, la qualité du lien, et le choix du meilleur chemin par intégration de la mesure du nombre de sauts. Un mécanisme de seuillage doit être mis en œuvre pour éviter les changements fréquents suite à des différences minimes au niveau topologique. L’implémentation et l’évaluation des performances de l’algorithme proposé sera faite en utilisant un simulateur dédié aux réseaux de capteurs sans fil.

Ce chapitre sera consacré aux détails de notre contribution dans le domaine du contrôle de topologie des RCSFs en se basant sur un système distribué. On commence par la problématique exacte de notre travail, puis nous citerons les travaux qui existent, en particulier on détaillera le protocole CTP vu que nous allons réutiliser son estimation de la qualité des liens entre les nœuds. Ensuite, les détails de notre proposition à savoir le principe de fonctionnement et la modélisation sous forme d’un système distribué comme préparation à une implémentation multi-agent qui sera discuté dans le dernier chapitre de cette thèse. Nous parlerons aussi du choix de l’outil de simulation et son principe de fonctionnement ainsi que la discutions des résultats obtenus.

2. La problématique

Notre contribution consiste à proposer une méthode hybride et distribuée pour le contrôle de topologie d’un réseau de capteurs sans fil en se basant sur des décisions locales par le nœud lui-même en fonction de plusieurs paramètres: énergie résiduelle, nombre de voisins, qualité des liens, etc. L’objectif principal est d’avoir à tout moment un réseau connexe, homogène et tolérant aux pannes, c'est-à-dire il faut prévoir et éviter le maximum possible des défaillances. Cela demande une forte coopération entre les nœuds puisqu’une décision d’un nœud dépend aussi de celles de ses voisins et leurs paramètres.


70

Lors d’une transmission de données, le principe proposé doit permettre de choisir les nœuds les plus tolérants aux pannes pour avoir un transfert plus sûr et garantir un réseau connexe pour longtemps. Puisque le système va être intégré par la suite dans un environnement multi-agent, il est impératif de prendre en considération le principe distribué, coopératif et émergent qui caractérise ce fonctionnement.

Le rôle du système utilisé est de calculer pour chaque nœud un paramètre déterminant l’état de ce dernier et ses capacités de continuer à fonctionner sans risque de défaillance liée par exemple à l’épuisement de l’énergie ou à la congestion avant qu’un transfert de données ne se termine. Nous appelons ce paramètre calculé le degré de tolérance d’un nœud.

Le choix du parent d’un nœud est un problème fréquemment posé dans les topologies arborescentes. En effet, quand un nœud veut envoyer des paquets, il doit choisir le chemin à emprunter par ces derniers. La construction de ce chemin commence généralement par le choix du nœud suivant à un saut appelé aussi parent du nœud en question.

Si on traduit le sens du meilleur chemin comme le plus court chemin en termes de nombre de sauts menant à la destination, ce qui est le cas le plus simple, il est clair et logique que le meilleur choix est connu tant qu’il n’y a pas de changements physiques dans la topologie. Un protocole qui fonctionne de cette manière et surtout quand il s’agit de grands réseaux, peut conduire rapidement aux situations suivantes :

‐ Le meilleur chemin entre une source et une destination devient fixe. ‐ Ces chemins considérés meilleurs soufrent d’une sur-utilisation. ‐ Dans les réseaux à base d’événements, l’apparition fréquente d’événement sur

une zone peut épuiser les nœuds intermédiaires.

En réalité, ce principe n’est pas toujours suffisant pour choisir le meilleur parent d’un nœud. D’autres paramètres doivent être pris en considération, ces paramètres sont liés à l’état du nœud et son environnement qui peut changer dynamiquement à cause des phénomènes suivants :

‐ La sur-utilisation d’un parent diminue rapidement son énergie. ‐ Un parent pour plusieurs nœuds soufre de la congestion et des interférences et

donc des retransmissions. ‐ La distance entre le nœud et son parent est un paramètre clé pour économiser

l’énergie et éviter les interférences, c'est-à-dire que la considération du nombre de sauts seul n’est pas toujours la bonne solution.

‐ Des trous peuvent apparaitre dans le réseau (mort de certains nœuds après épuisement).

‐ Les délais de transmissions sont fortement liés à l’activité d’un parent et la qualité du lien.

Un bon protocole de contrôle de topologie doit prendre en considération tous ces paramètres. Dans ce contexte, notre travail consiste à proposer une approche distribuée pour la construction et la maintenance de la topologie d’un réseau de capteurs sans fil dynamiquement afin de garantir un équilibrage de charges avec qualité de service. En plus, l’aspect distribué et coopératif d’une telle solution, nous a conduit à penser de l’implémenter sous forme d’un système multi-agent simple.


71

Avant de détailler notre proposition, et outre ceux déjà cités au chapitre III, nous donnons une brève description des travaux dans le contexte des topologies à tolérance aux pannes et qui sont basées sur des paramètres locaux pour la maintenance de la topologie. Notons que ces travaux n’utilisent pas la technologie agent.

3. Travaux existants

Les travaux sur le contrôle de topologie qui nous intéressent ici sont ceux qui se basent sur des paramètres locaux afin de prédire ou estimer d’autres valeurs ou états ou de prendre une décision afin d’optimiser les performances en agissant sur la topologie.

Commençons par [YIN-12] de Yin Rong-rong et al. qui propose une méthode adaptative de contrôle de topologie avec tolérance aux pannes par calcul de la probabilité de défaillance PD d’un nœud en se basant sur le rapport entre l’énergie consommée Ec et l’énergie initiale Einit ainsi qu’une autre probabilité P de défaut liée au composants matériels et logiciels, c'est-à-dire :

PD = P. Ec / Einit (4.1)

Dans [DAR-12], Dario Bruneo et al. montre que l’introduction des techniques markoviennes permettent d’estimer la durée de vie d’un nœud prenant le cycle active-sleep comme modèle de transitions avec des probabilités pour chaque transition. Ce qui permet de prédire les défauts. Mais en réalité, la durée de vie dépend aussi des activités du nœud quand il est à l’état actif.

Un autre travail utilisant les modèles de Markov, [ARS-11] de Arslan Munir et al. discute la modélisation markovienne des réseaux de capteurs tolérant aux pannes où le degré de tolérance d’un nœud est estimé en fonction du nombre de nœuds déployés et la probabilité de remplacement de chacun en cas de panne.

Les pannes dans un réseau de capteurs peuvent être détectées par application d’une « fuzzy inference » selon [SAF-12] de Safdar Abbas Khan et al. où les mesures d'un nœud capteur sont comparées à des valeurs attendues par un réseau de neurones. La différence de comportement permet de détecter les anomalies.

La durée de vie d’un réseau de capteurs hiérarchique est étudiée par Bo-Chao Cheng et al. dans [CHEN-12]. Il propose un algorithme de prédiction de la durée de vie en meilleure et pire des cas dans un réseau de capteurs avec clusters à un saut où les cluster-heads doivent communiquer directement avec le sink. L’objectif est de trouver le meilleur déploiement pour ce type de topologie.

Une approche coopérative pour le contrôle de topologie est proposée par Paolo Costa et al. dans [PAO-09]. La construction de la topologie consiste à choisir des nœuds de telle sorte qu’un degré de k-connectivité est garanti en utilisant une portée radio minimale. La stabilité de la topologie est obtenue par coopération entre les nœuds qui doivent se mettre d’accord sur le niveau de la radio sous la contrainte de k-connectivité.


72

Le protocole CTP (Collecte Tree Protocol) [OMP-09] est aussi un protocole distribué qui maintient une topologie arborescente d’un RCSF en se basant sur la qualité des liens entre les nœuds et vu l’importance de ce protocole pour notre contribution dont nous allons réutiliser sa méthode d’estimation de la qualité des liens, des détails concernant le CTP sont donné ci-après.

4. Détails sur le protocole CTP

Comme il a été évoqué au par avant, notre travail utilise un principe d’estimation de la qualité des liens similaire à celui du protocole de collecte de données dit CTP (Collection Tree Protocol) du fait qu’il est basée sur une topologie arbre. Avant d’entamer les détails sur notre proposition, on explique ici le principe de fonctionnement de ce protocole.

4.1 Définition

CTP est un protocole de collecte de données dans un réseau de capteurs à topologie arborescente où certains nœuds sont considérés comme racines, les nœuds forment un ensemble de chemins vers ces racines à l'aide d'un gradient de routage. CTP utilise le routage à travers des messages, également appelés beacons pour la construction et l'entretien de la topologie, et des messages pour rapporter les données de l'application en question vers le Sink.

Du point de vue implémentation, le protocole CTP décrit et évalué dans [OMP-09] est constitué de trois principales composantes logicielles qui sont Routing Engine (RE), Forwarding Engine (FE), et Link Estimator (LE).

4.2 Structure du protocole CTP

4.2.1 Routing Engine (RE)

Le RE, comme son nom l’indique, est une instance qui s'exécute sur chaque nœud, permettant d’envoyer et de recevoir des beacons ainsi que la création et la mise à jour de la table de routage. Cette table contient une liste de voisins à partir de laquelle le nœud peut choisir son parent dans l'arborescence de routage. Cette table est remplie en utilisant les informations extraites des beacons. Elle contient les identifiants des nœuds voisins ainsi que d’autres informations, comme la métrique qui indique la qualité d'un nœud en tant que parent potentiel. Dans le cas du CTP, cette métrique est connue par ETX (Expected Trransmissions ou transmissions attendus).Un nœud ayant une valeur ETX égale à n devrait être en mesure de fournir un paquet de données au Sink avec un total de n transmissions en moyenne. L'ETX d'un nœud est défini comme le ETX de son parant ainsi que le ETX de son lien avec son parant.

4.2.2 Forwarding Engine(FE)

Le module FE s'occupe de l'expédition des paquets de données qui peuvent provenir soit de la couche application du même nœud ou des nœuds voisins dont il fait partie du chemin choisi. Le FE est également responsable de la détection et la réparation des boucles de routage ainsi que la suppression des paquets dupliqués.


73

4.2.3 Link Estimator (LE)

Le module LE s'occupe de la détermination de la qualité des liens entrants et sortants de communication. Nous détaillerons après la méthode de calcul de cette métrique qui exprime la qualité des liens. Le LE calcule la valeur ETX 1-saut par la collecte des statistiques sur le nombre de beacons reçus et le nombre de paquets de données transmis avec succès. À partir de ces statistiques, le LE calcule cette métrique en entrée comme étant le rapport entre le nombre total de beacons envoyés par le voisin sur la fraction de beacons reçus.

Les trois composantes RE, FE, et LE ne fonctionnent pas de manière indépendante mais interagissent à travers un ensemble d'interfaces bien définies. Par exemple, le RE a besoin des fonctionnalités offertes par le LE pour avoir la métrique ETX 1-saut pour calculer celle multi-sauts. De l'autre côté, le FE doit obtenir l'identifiant du parent actuel à partir de la composante RE et vérifier l'état de congestion des voisins avec le RE. La figure IV.1 montre ce principe de fonctionnement à travers des interactions qui sont gérées par des interfaces spécifiques.

Figure IV.1: Flux des messages et interactions des modules dans le protocole CTP

4.3 Structure des donnée en CTP

4.3.1 La trame de données

Lors d’une transmission de données, la trame utilisé véhicule en plus des informations de l’application d’autres valeurs qui permettent le contrôle de la topologie du réseau et la gestion des opérations de routage et cela en fur et à mesure d’échange de données entre voisins. La figure ci-après montre la structure d’un tel paquet.

Forwarding Engine

Link Estimator

Routing Engine

Mac Layer

Routing Frames

+ LE header + LE footer

Routing Frames

Data Frames

Interfaces

Routing Layer


74

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

P| C| Reserved THL

ETX

Origin

Seqno Collect_id

Data

Figure IV.2: Structure d’un paquet de données en CTP

Le champ P : est un bit qui permet aux nœuds de demander des informations de routage à partir d'autres nœuds. Si la destination unicast de la trame de données avec une route valide entend un paquet avec le bit P à 1, il devrait transmettre une trame de routage dans un proche avenir. Les nœuds autres que la destination de la couche liaison de la trame de données peuvent répondre au bit P dans la trame de données.

Le champ C: qui exprime la congestion. Si un nœud soufre du phénomène de la congestion vu le grand nombre de trames, il doit fixer le champ C à 1 sur la trame de données suivante pour exprimer ce problème.

THL: qui signifie Time Has Lived et détermine la durée de vie d’une trame. Quand un nœud génère une trame de données, il doit initialiser la valeur THL à 0 et elle sera incrémentée à chaque réception de cette trame de données par des nœuds intermédiaires, elle peut atteindre la valeur 255.

ETX: L'ETX est une métrique de routage de l'expéditeur. Lorsqu'un nœud transmet une trame de donnée, il doit mettre la valeur ETX de son itinéraire dans le champ ETX.

Origin: contient l'adresse qui est l’identificateur de l'expéditeur du paquet. Un nœud intermédiaire transmettant une trame de données ne doit pas modifier le champ Origin.

Seqno: numéro de séquence d'origine. Le nœud d'origine définit ce champ, les nœuds intermédiaires n’ont pas le droit de le modifier.

Collect_id: cet identificateur est aussi défini par l’origine et ne doit pas être modifié lors des transmissions par d’autres nœuds, il représente une identification des données collectées.

Le champ data: qui contient des données propres à l’application et qui sont collectées par le nœud originaire, elles peuvent aller de quelques octets à plusieurs octets.

4.3.2 Structure de routage CTP

Le routage dans le protocole CTP est assuré à travers des trames contenant principalement l’identité du parent et la valeur ETX comme le montre la figure suivante:


75

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

P| C| Reserved Parent

Parent ETX

ETX

Figure IV.3: Le format de la trame de routage dans CTP

Le champ P: Comme la trame de données avec une seule différence: les trames de routage sont diffusées à plusieurs nœuds avec le bit P au lieu d’être unicast.

Le champ C: la même signification comme le cas de la trame de données.

Parent: l’identificateur du parent actuel du nœud.

ETX: valeur de la métrique de routage actuelle du nœud.

Ces deux types de trames qui sont la trame de données et celle de routage sont utilisées pour transmettre les données utiles de l’application vers le Sink tout en permettant le contrôle et la maintenance de la topologie en cas de congestion et en se basant sur la seule métrique dite ETX. Ces trames sont encapsulées à travers les différentes couches protocolaires comme indiqué sur la figure ci-dessous.

Figure IV.4: Structure des paquets en CTP

Entête PHY

Entête MAC

Trame de données FinMAC

6 octets 10 octets 8 + n octets 2 octets

Trame de données

Entête PHY

Entête MAC

EntêteLE

FinMAC

6 octets 10 octets 2 octets 5 octets 0 à 45 octets 2 octets

Trame de routage

Fin LE

Trame de routage

Entête PHY

Entête MAC

FinMAC

6 octets 3 octets 2 octets

Acquitement


76

5. Proposition d’une amélioration du CTP

Cette amélioration [BEC-14] et [HAF-14] consiste à utiliser la même architecture logicielle mais avec introduction de nouvelles métriques et formules de calcul des paramètres nécessaires pour le contrôle de topologie en plus des modifications sur la structure des trames. Ce qui est nouveau dans notre proposition est la manière de calculer la métrique qui sert à l’adaptation de la topologie selon l’état et l’activité des nœuds et même en cas de panne ou risque de panne. Enfin le but principal de ce travail et d’exploiter ce fonctionnement distribué pour l’implémenter sous forme d’un système multi-agent. Pour cela, nous allons détailler cette proposition avec les modifications apportées puis nous allons étudier ses performances à l’aide d’un simulateur de RCSF.

Pour l’implémentation multi-agent de notre proposition, nous allons proposer plus loin dans cette thèse une architecture multi-agent avec adaptation et implémentation à l’aide d’une plateforme dédiée puisque les simulateurs de réseaux de capteurs disponibles pour le moment n’offrent pas réellement l’intégration de la technologie agent.

5.1 Modèle du réseau

Les nœuds du réseau de capteurs sont déployés aléatoirement dans un champ déterminé pour capter certains types d’informations relatives à une application et les transmettre enfin à une station de contrôle ou Sink. En plus on suppose que le réseau déployé est stationnaire avec une topologie connexe. Lors d’un transfert de données le choix du chemin est basé sur le choix du nœud suivant ou le parent à partir du nœud actuel. Le parent est choisi parmi les voisins en se basant sur une métrique que nous appelons le degré de tolérance au moment du transfert, c'est-à-dire que le nœud qui a le meilleur degré de tolérance sera qualifié pour ce transfert. La méthode de calcul du degré de tolérance sera détaillée par la suite. Cette tâche est assurée par chaque nœud capteur lui même. La figure IV.5 montre ce principe où le nœud initiateur de transfert de données est responsable de choisir son parent parmi les voisins candidats, ce choix va déterminer le chemin à emprunter par les paquets envoyés. Certains nœuds peuvent devenir critiques suite à une sur-utilisation par exemple, donc ils ne peuvent pas être parents d'autres nœuds.

Figure IV.5: Modèle du réseau


77

5.2 Construction de topologie

Après le déploiement des nœuds, le Sink diffuse un message d’initialisation Init basé sur le nombre de sauts HC (Hop Count) qui est nul pour le Sink. Chaque nœud n qui reçoit le message Init considère l’émetteur de ce message comme nœud suivant pour les prochaines transmissions si la valeur HC de ce dernier est inférieure à celle du nœud récepteur n. c'est-à-dire il fait :

Si HC(n)>HC(init)alors 1 :HC(n)=HC(init) 2 :Next_Hop = Emetteur(Init)

Puis il rediffuse le message Init. Notons qu’au début, les valeurs HC sont initialisées à l’infini pour tous les nœuds sauf le Sink où cette valeur est fixée à zéro. Ce principe permet de construire à la fin une topologie logique sous forme d’un arbre avec le Sink ou la station de base comme racine.

5.3 Contrôle de topologie

Après la stabilité de la topologie obtenue par initialisation (il y a aucun nœud qui rediffuse le message Init), les nœuds calculent leurs degrés de tolérance de la manière suivante:

Soient:

- Einit : énergie initiale d'un nœud; - Ev : énergie résiduelle du nœud v; - Nv : ensemble des voisins de v,Ni Є Nv un voisin de v; - Pin(Ni) : nombre de paquets reçus par v à partir de Ni pendant une certaine

période t; - Pout(Ni) : nombre de paquets diffusés par Ni pendant une certaine période t; - Poutc(Ni) : nombre de paquets correctement reçus par les voisins (avec

acquittement); - HC(v) : nombre de sauts vers le sink à travers v ; - NH(v) : le prochain saut de v vers le sink dit aussi parent de v;

Pour le calcul du degré de tolérance TD, nous proposons d'utiliser la qualité du lien

et l'état de la batterie du nœud. Le calcul du premier paramètre, c'est-à-dire la qualité du lien est inspiré de l'estimation utilisée dans [OMP-09] par le protocole CTP définit précédemment. Pour l'état de la batterie nous proposons de considérer le rapport entre l'énergie résiduelle et celle initiale. C'est-à-dire l’état de la batterie d’un nœud v, notée Etat_bat(v), est donnée par :

(4.2)

On définit la qualité des liaisons sortantes QS entre un nœud v et son voisin Ni comme suit:

/ (4.3)


78

De même la qualité des liaisons entrantes QE entre un nœud v et son voisin Ni:

/ (4.4)

Le nœud v calcule son degré de tolérance TD en fonction de la qualité Q d'une liaison sortante QS ou entrante QE et l'état de la batterie du nœud en question comme suit:

. . . . (4.5)

Où αTD est une constante de pondération qui peut prendre des valeurs entre 0 et 1. Ce facteur exprime l’importance d’un paramètre réseau par rapport à un autre. Dans notre cas, on donne une grande importance à la qualité Q actuelle soit 90% qui se traduit par αTD = 0.9 devant l’ancienne valeur de TD qui aura au maximum un facteur de 10%.

La procédure de changement de parent est basée sur les valeurs de paramètres de l'ancien parent et les voisins candidats, on utilise principalement l'énergie E, le degré de tolérance TD et le nombre de saut vers le sink HC. Pour éviter le changement de parents suite à des différences minimes de ces paramètres, un principe de seuillage est utilisé pour chaque paramètre. Par conséquent, le nœud v décide de choisir un voisin Ni comme son nouveau parent NH si les conditions suivantes sont vérifiées:

HC(Ni) ≤ HC(v) + Seuil_HC

E(Ni) >E(NH(v)) + Seuil_E

DT(Ni) >DT(NH(v)) + Seuil_TD

Il est nécessaire de signaler ici que l'ordre de vérification de ces conditions est très important, il dépend aussi de la nature de l'application qui utilise notre approche. Ici, nous avons choisi le nombre de sauts en premier avec un seuil qui dépend de la taille du réseau pour ne pas avoir des longs chemins et par conséquent retarder le trafic. Cela peut ne pas être utile si l'application n'a pas la contrainte de temps.

L’algorithme 4.1 ci-dessous montre le processus de sélection de parent selon les conditions précédentes. SE, STD et SHC représentent des seuils pour les valeurs d'énergie, du degré de tolérance et du nombre de sauts respectivement. La fonction Changer_Parent représente un interrupteur de changement entre le parent actif et le parent candidat, la fonction TD(Ni) représente l’estimation du degré de tolérance d’un nœud Ni.

Dans cet algorithme, l'utilisation de ces paramètres est présentée comme un système de réglage capable de configurer la manière dont le protocole fonctionne en conformité avec les buts et objectifs de l'application de RCSF.


79

Cet algorithme permet à un nœud de modifier son parent quand un meilleur parent est détecté, c'est-à-dire un voisin qui a un degré de tolérance meilleur que le parent actuel ou bien il estime qu’il y avait des changements qui dépassent le seuil déterminé sur les valeurs de l’énergie et HC d’où vient les conditions sur TD(Ni) + STD, Energy(Ni) + SE et HC(NH) + SHC.

En outre, l’algorithme est utilisé pour sélectionner un nouveau parent parmi les voisins candidats lors de la détection d'un défaut (par exemple, le parent meure ou se déplace). Ce défaut de parent peut être déclaré après avoir enregistré un échec de transfert de paquets.

5.4 Structure des trames

Le fonctionnement de notre protocole de contrôle de topologie est basé sur la coopération des nœuds pour créer un mécanisme d’équilibrage de charges. Les informations nécessaires pour la maintenance de la topologie sont incluses dans les trames de routage. Pour cela, la structure des beacons utilisés dans le protocole CTP a été modifiée en ajoutant le paramètre énergie et HC et en remplaçant le paramètre ETX par la valeur de notre nouvelle métrique qui est le degré de tolérance TD. Cette structure est montrée dans la figure IV.6 ci-après.

Figure IV.6: Le format de la nouvelle trame de routage

Nouvelle trame de routage

P|C|Reserved Parent Energie

1 octet 2 octets 2 octets 2 octets 2 octets

HC TD

Algorithme 4.1: Selection de parent

1: NH = Current Parent (Next Hop) 2: Ni = Candidate neighbor 3: If HC(Ni) < HC (NH) + SHC then 4: if Energy(NH) = Energy (Ni) then 5: if TD (NH) < TD (Ni) + STD then 6: Change_Parent(Ni) 7: end if 8: else if Energy (NH) < Energy (Ni) then 9: if TD (NH) ≥ TD(Ni) + STD then 10:Change_Parent (Ni) 11:end if 12:else if Energy (NH) > Energy (Ni) and Energy (NH) ≤ Energy (Ni) + SEthen 13: if TD (NH) ≤ TD (Ni) then 14: Change_Parent (Ni) 15: end if 16: end if


80

On remarque ici que sur la structure de la trame de routage les valeurs des paramètres Parent et HC sont représentées sur deux octets. C’est une taille que nous l’avons estimé suffisante pour représenter ces valeurs pour les raisons suivantes:

- Le paramètre Parent est l’identificateur du nœud parent, donc sur deux octets on peut adresser tous les nœuds d’un réseau de capteurs dont la taille peut atteindre les 65536 nœuds.

- De même le paramètre HC qui représente le nombre de saut qui est toujours largement inférieur par rapport au nombre total des nœuds dans le réseau.

Mais pour les valeurs des paramètres énergie et TD qui sont en réalité des valeurs de type réel donc représentées en virgule flottante, nous avons opté à les transmettre sur deux octets chacun pour économiser la bande passante de la manière suivante :

- Le paramètre énergie est exprimé en pourcentage avec négligence de la partie décimale puisque un seuil des déférences d’énergie sera utilisé ce qui rend cette partie sans effet sur la topologie. Par exemple pour un nœud avec un état de batterie à 50%, la valeur 50.8% n’a pas d’importance pour les changements topologiques.

- La valeur TD est traitée avec le même principe que l’énergie vu le principe de seuillage utilisé aussi.

En plus de ces modifications sur la trame de routage, on propose aussi d’enlever la partie « Fin LE » ou bien « Footer LE » de la même trame du protocole CTP. Les autres trames nécessaires pour le fonctionnement de notre solution restent inchangées par rapport au CTP à savoir la trame de données et la trame d’acquittement.

5.5 Illustration du fonctionnement

Notre algorithme distribué sera implanté sur chaque nœud capteur. L'ensemble des capteurs forment un système distribué dont la coopération est assurée par l'échange de messages au moment d'un transfert pour choisir les nœuds les plus tolérants aux pannes et cela à chaque saut. Il est clair que le principe de l'algorithme nécessite que les capteurs doivent communiquer à chaque fois les informations nécessaires à savoir les dernières valeurs du degré de tolérance, l'énergie et le nombre de sauts vers le Sink. Le schéma de la figure IV.7 ci-dessous montre que le nœud 3 par exemple a le choix de transférer ses paquets à travers les nœuds 2, 6 ou 7 selon l'état de chacun de ces derniers qui est exprimé par leur degré de tolérance.

Figure IV.7: Principe de fonctionnement de la solution proposée

Liens à l’initialisation

Liens candidats


81

6. Etude de performances par simulation

6.1 Pour quoi simuler

Pour étudier les performances d'un protocole on a recours souvent à la simulation. En effet il serait coûteux de mettre en place un réseau de capteurs sans fil dans le but de tester certains critères d'évaluation.

A la fin des années 90, avec l’élaboration de plusieurs normes pour les réseaux sans fil à portée limitée, un certain nombre de simulateurs ont été développés. Par exemple Network Simulator 2 [NS2] et ses extensions, OPNET [DES-93], Omnet [AND-08], Jsim [JSM] ou encore GloMoSim [ZEN-98] et Qualnet [QLT].

Tous ces simulateurs permettent d'évaluer les performances des systèmes avant leur déploiement. Dans le cas de la simulation des réseaux de capteurs sans fil, les objectifs de base sont très diversifiés tels que la validation des protocoles ou bien l’étude de quelques facteurs de fonctionnement.

De nombreux outils de simulation sont utilisés par les chercheurs dans le domaine des réseaux de capteurs. Il existe des outils d’émulation comme Avrora et TOSSIM et des environnements de simulation comme J-Sim, OPNET et NS2 et Omnet++. Les simulateurs les plus utilisés sont:

6.1.1 Le simulateur J-Sim

J-Sim, connu aussi par Java-Sim (http://www.j-sim.org/), est un simulateur gratuit et open source développé à l’origine par des chercheurs à l’université de West Bohemia aux Etas unis, basé sur un principe orienté objet sous forme de composants autonomes écrits en Java. Il était initialement prévu pour les réseaux filaires, une extension de ce simulateur est dédiée pour les réseaux sans fil et propose une implémentation du protocole MAC 802.11. Cette extension permet d’utiliser J-Sim pour la simulation de MANET (Mobile Ad-hoc NETwork). Le point fort de J-Sim est qu’il facilite l’ajout et la suppression des modules d’une manière dynamique ou plug-and-play. Il permet aussi la simulation des réseaux allant jusqu’à des milliers de nœuds. Le passage à l’échelle peut toutefois être amélioré. J-Sim donne la possibilité d’utiliser n’importe quelle application Java comme générateur de trafic. Il gére aussi les aspects relatifs à la consommation d’énergie dans les réseaux sans fil.

6.1.2 Le simulateur NS

C’est un simulateur à événements discrets, gratuit et open-source, son noyau est écrit en C++ avec une possibilité de configuration à travers de scripts OTCL. D’une manière générale, il est utilisé dans le domaine des recherches sur les réseaux. Des améliorations sur la version NS2 ont conduit au développement de la version NS3. Les nœuds dans le simulateur NS2 modélisent des piles protocolaires OSI complètes qui ne sont pas nécessaires pour représenter des nœuds de capteurs. En effet, un ensemble de protocoles de routage fixe, des protocoles de transport et des modèles d’application (comme des services web) sont fournis mais ils ne sont pas utilisés par les réseaux de capteurs sans fil. Enfin, la simulation des réseaux de capteurs n’est pas facilement supportée par NS2 même si plusieurs travaux sont actuellement en cours pour faciliter ce type de simulations. Dans ce contexte, une étude a été faite par Y. Xue et al. dans [Xu-07] afin d’évaluer la performance et l’utilité du simulateur NS2 dans le domaine des


82

RCSF. Elle montre que NS2 ne simule pas très bien les RCSFs. Pour cela, les auteurs ont proposé des modifications pour améliorer les modèles RCSFs sous NS2.

6.1.3 OPNET

OPNET Modeler (Optimized Network Engineering Tools) est un simulateur de réseaux commercialisé par Opnet Technologies. C’est un simulateur utilisé surtout par les industriels pour la modélisation et la simulation des réseaux. Il permet de dessiner et d’étudier des réseaux de communications, des équipements, des protocoles et des applications avec facilité et évolutivité. OPNET est utilisé par les entreprises technologiques les plus performantes pour accélérer leurs procédés de recherches et développements. L’approche orientée objet associée à des éditeurs graphiques intégrés de Modeler simplifie la composition des réseaux et des équipements. Ceci permet de réaliser facilement une correspondance entre le modèle et le système à simuler.

Pour la configuration d’un réseau, trois niveaux hiérarchiques sont définis: le niveau réseau qui consiste à créer la topologie, le niveau nœud qui définit le comportement du nœud et qui contrôle le passage des données entre les différents éléments fonctionnels à l’intérieur du nœud, et enfin le niveau processus qui décrit les protocoles représentés par des machines à état finis. Le code est écrit en C/C++. L’analyse des données résultats est effectuée avec un ensemble de fonctions intégrées. Le simulateur OPNET comporte plusieurs fonctionnalités adaptées et performantes pour la simulation des réseaux de capteurs mais c’est un produit commercial.

6.1.4 OMNET++

OMNET++ (http://www.Omnetpp.org) est un simulateur à événement discret inspiré d’OPNet. Il a une architecture modulaire et hiérarchique avec un environnement de simulation qui a une interface graphique (GUI: Graphical User Interface). Les modules sont implémentés en C++, le GUI est crée en utilisant la librairie Tk. Les modules sont assemblés sous forme de composants et modules en utilisant un langage de haut niveau appelé NED. Les composants communiquent entre eux en envoyant des messages. La configuration d’une simulation est gérée par des fichiers .ini.

Aujourd’hui, il y a plusieurs modèles de réseaux de capteurs basés sur Omnet comme par exemple Mobility Framework qui implémente un support pour la mobilité des nœuds et la gestion dynamique des connexions et un autre modèle pour le canal sans fil. Dans les dernières années, des modèles complets sont développés en se basant sur Omnet pour la simulation des protocoles destinés aux RCSF. Castalia est le modèle le plus connu dans ce cadre.

6.2 Choix d’un simulateur

La nature des RCSF rend leur simulation plus difficile. Pour cela, et durant ces dernières années, les simulateurs dédiés à ce type de réseaux essayent d’améliorer leurs capacités en termes de rapidité, précision, sociabilité, facilité d’utilisation,… etc. Ces améliorations sont faites soit à travers des nouvelles versions et dans la plus part des cas à travers des frameworks spécifiques à certains types de réseaux comme nous allons le voir par la suite.


83

Pour la simulation de notre approche, le choix est fait sur le simulateur Castalia/Omnet++ vu les caractéristiques et avantages de ce dernier dont on peut citer:

Il offre un modèle de mobilité. Son modèle radio adapté au réseau de capteurs sans fil. Il gère correctement la consommation d’énergie. Possibilité de simuler des réseaux de taille plus ou moins importante. Il met on œuvre des mécanismes de parallélisme et de traitement distribué issus

d’Omnet++. Gratuité et donc disponibilité du produit

Le groupe Australien NICTA (Networks and Pervasive Computing program of National ICT Australia) [CAST] a développé le modèle Castalia pour la simulation des réseaux de capteurs mais en se basant sur le simulateur Omnet++.Par la suite Castalia est considéré lui-même un simulateur de réseaux de capteurs sans fil. Comme nous l’avons annoncé. Pour ces raisons, la simulation de notre approche sera faite sous Castalia.

7. Environnement de simulation

7.1 Présentation

OMNET++ (Objective Modular Network Test-bed in C++) est un simulateur open source à événements discrets développé par András Varga. Il comporte différents modules écrits en C++ qui s'intègrent dans un framework général écrit en NED. Il est essentiellement utilisé pour les communications dans un réseau. Cependant, grâce à son architecture générique et flexible, il est utilisé avec succès dans les autres domaines, tels que la simulation de systèmes complexes de traitement et de communication de données, les réseaux de files d’attente ou encore la modélisation des systèmes multiprocesseurs.

L’avantage et le succès d’Omnet++ réside dans son architecture modulaire et flexible. Ainsi, un modèle Omnet++ consiste en un ensemble de modules hiérarchiquement encapsulés communiquant entre eux par échange de messages. Le niveau hiérarchique des modules n’étant pas limité, l’utilisateur est capable de représenter la structure réelle de son système grâce aux modules de base de ce simulateur. Le module de plus haut niveau est appelé le module système ou le module réseau. L’unité élémentaire d’exécution est dite module simple. Un module composé peut contenir un ou plusieurs modules simples et/ou composés. Cette vue modulaire donne la possibilité d’implémenter des modules indépendants et de les intégrer par la suite dans la même architecture en définissant les interfaces de communication entre les modules.

7.2 Méthodologie d’utilisation

La construction d’un programme de simulation sous Omnet++ consiste en quatre principales étapes:

Décrire la topologie avec le langage NED à travers les fichiers de description de topologie «.ned». Ces fichiers contiennent quatre parties optionnelles : déclaration des paramètres, déclarations des ports de communication, déclaration des sous-


84

modules et définition des connexions entre les sous-modules. Cette description peut se faire en mode texte ou bien en mode graphique grâce à l’interface graphique GNED qui générera automatiquement la description NED.

Définir la structure des messages échangés à travers des fichiers «.msg ». On peut définir plusieurs types de messages avec des champs de données pour chacun. Ces définitions de messages doivent être écrites en C++.

Associer à chaque module simple des fichiers source « .h » et « .cc » afin d’implémenter le comportement spécifique du module. L’implémentation se fait en langage C++ et en utilisant la bibliothèque de simulation d’OMNET++ qui fournit des classes prédéfinies.

Créer le fichier de configuration ou d’initialisation des modèles qui est un fichier « .ini » dont le rôle est d’initialiser les paramètres des différents modules.

Voici un petit exemple pour illustrer la création d’un projet de simulation d’un petit réseau avec Omnet++:

1. La description du réseau et ses composantes à l’aide du langage NED, on crée donc un fichier .ned à l’aide de l’interface graphique IDE ou bien écrire directement le script NED. Pour notre exemple, le fichier RCSF.ned définit un réseau nommé Rcsf composé de deux nœuds (Noeud1 et Noeud2) de type Nœud qui est un module simple comme le montre la figure IV.8 :

Figure IV.8 : Description NED d‘un réseau avec Ompnet++

2. Implémentation des classes définissant le fonctionnement des modules définis en .ned qui doivent être écrites en C++. Ici, les fichiers Noeud.h et Noeud.cc implémentent la classe Noeud définie comme module simple dans le fichier .ned. il est important de noter ici que le fichier .cc doit porter le même nom que le module simple dans le fichier .ned (ici Noeud).

package RCSF; simple Noeud { @display("bgb=350,,rect"); gates: input in; output out; } networkRcsf { @display("bgb=335,236"); submodules: Noeud1: Noeud { @display("p=95,59"); } Noeud2: Noeud { @display("p=266,182"); } connections: Noeud1.out --> Noeud2.in; Noeud2.out -->Noeud1.in; }


85

L’implémentation doit redéfinir essentiellement les deux méthodes définies par Omnet qui sont initialize() pour initialiser le module et handleMessage(cMessage *msg) pour définir le comportement du protocole en réaction à des messages. La directive Define_Module() permet de faire le lien avec la bibliothèque d’Omnet, on dit qu’elle enregistre la classe.

3. Initialisation de la simulation dans le fichier Omnetpp.ini, il sert à donner le nom du réseau et d’autres paramètres comme le temps de simulation, délais, … par exemple :

7.3 Modèle de Castalia

Le simulateur Omnet++ n’étant pas dédié aux réseaux de capteurs sans fil, Castalia est une interface pour cet objectif. Cette plateforme permet de tester les algorithmes et les protocoles de communication avec des modèles réalistes du canal sans fil. Castalia est une mise en œuvre d’un module composé appelé SensorNetwork qui est lui même composés des modules simples "Physical Process" représentant les processus physiques et/ou les objets cibles à contrôler et "Wireless Channel" représentant le canal de transmission sans fil ainsi que le module composé "Node" représentant les capteurs et la station de base. La figure IV.9 montre l’architecture du réseau de capteurs sans fil selon le modèle de Castalia:

Figure IV.9: Architecture du module SensorNetwork de Castalia

Processus physiqque (Physical Process)

Canal radio (Wireless Chanel)

Nœud 1 Nœud 2 Nœud n Sink …

[General] network = RCSF.Rcsf

#include <string.h> #include <omnetpp.h> Class Noeud : publiccSimpleModule { protected: virtual void initialize(); virtual void handleMessage(cMessage *msg); }; Define_Module(Noeud); Void Noeud::initialize() { } Void Noeud::handleMessage(cMessage *msg) { }


86

Dans cette architecture, les nœuds ne communiquent pas directement les uns avec les autres mais à travers le module Wireless Channel. Lorsqu’un nœud envoie un paquet, il passe par le canal sans fil. Celui-ci décide vers quels nœuds le message va être acheminé et avec quelle puissance. Afin de simuler la capture de données, tous les nœuds sont connectés au module Physical Process.

Pour intégrer un modèle de simulation sous Castalia il faut localiser la ou les couches à modifier dans le modèle de base. La figure IV.10 montre la structure des packages Castalia dont les principaux répertoires sont:

- Simulations: ce répertoire contient les fichiers de configuration des différents modèles simulés où il faut créer un dossier qui porte le nom de l’apllication dans le quel on doit définir les paramètres de simulation dans le fichier Omnetpp.ini.

- src/node: c’est le répertoire principal dans lequel on peut définir ou modifier le comportement d’un nœud capteur, il est composé de plusieurs modules qui représentent la structure en couches d’un réseau. Nous nous intéressons pour notre étude à la composante application et communication qui est elle-même composée de deux couches qui sont Routing et MAC.

Figure IV.10: Arborescence de Castalia

8. Détails de l'implémentation

Pour l’évaluation de notre proposition d’un point de vue fonctionnement RCSF en utilisant le simulateur Castalia, il est impératif de faire une comparaison avec un autre protocole. Pour cela, notre proposition peut être considérée comme une amélioration du protocole CTP [OMP-09] de collecte de données. Et comme il a été évoqué au par avant, nous avons réutilisé sa formule d’estimation de la qualité des liens. Nous essayons de garder le même contexte de simulation afin de faciliter l’implémentation de la nouvelle méthode et surtout donner un sens à la comparaison faite dans cette étude.


87

Il est important de suivre la consommation d'énergie par les nœuds capteurs. Dans le simulateur Castalia le module de gestion des ressources (Resource Manager) garde la trace de l'énergie dépensée par le nœud et détient également certaines valeurs spécifiques au nœud comme la dérive de l'horloge et la consommation d'énergie. Le gestionnaire de ressources calcule l'énergie consommée chaque fois que nous avons un changement de puissance ou périodiquement. Le calcul périodique de la consommation d'énergie se fait sur la base de quelques paramètres qu’il faut initialiser au début:

La méthode updateRouteTask () dans le module CtpRoutingEngine inspiré de CTP permet de modifier le parent d’un nœud en se basant sur le degré de tolérance (noté TD): Void CtpRoutingEngine::updateRouteTask() { //variables pour déterminer la qualité de lien uint8_t i; routing_table_entry* entry; routing_table_entry* best; uint16_t minDT; uint16_t currentDT; uint16_t linkDT, pathDT; // calcul de l’énergie double spentEnergy = resMgrModule->getSpentEnergy (); double initialEnergy = resMgrModule-> par ("initialEnergy"); double remainingEnergy = initialEnergy-spentEnergy; entry->info.energie = remainingEnergy; if (state_is_root)return; best = NULL; minDT = MAX_METRIC; currentDT = MAX_METRIC; trace()<<"updateRouteTask" ; for (i = 0; i<routingTableActive; i++) { entry = &routingTable[i]; if (entry->info.parent == INVALID_ADDR || entry->info.parent == my_ll_addr) { trace()<<"routingTable["<<(int)i<<"]: neighbor: [id: "<<(int)entry->neighbor<<" parent: "<<entry->info.parent<<" DT: NO ROUTE]" ; continue; linkDT = evaluateDT(le->command_LinkEstimator_getLinkQuality(entry->neighbor) ; pathDT = linkDT + entry->info.DT; // pour le parent actuel if (entry->neighbor == routeInfo.parent) { trace()<<"already parent"; currentDT = pathDT; routeInfo.DT = entry->info.DT; routeInfo.congested = entry->info.congested; // routeInfo.energie = entry->info.energie; continue; } // ignorer le lien avec congestion if (entry->info.congested) continue; /* Ignorer les mauvais liens */

Double periodicEnergyCalculationInterval = default (1000); Double baselineNodePower = default (6); // Consommation d'énergie de base Double initialEnergy = défaut (18720); // L’énergie initial d'un nœud


88

if (!passLinkDTThreshold(linkDT)) { trace()<<"did not pass threshold."; continue; } // ignorer le voisin qui a une énergie résiduelle < 10% if (entry->info.energie<= energyThreshould){ continue; } if (pathDT<minDT) { minDT = pathDT; best = entry; } } // les conditions de changement de parent if (minDT != MAX_METRIC) { if (currentDT == MAX_METRIC || (routeInfo.congested&& (minDT< (routeInfo.DT + 10))) || (minDT + PARENT_SWITCH_THRESHOLD <currentDT) || (entry->info.energie<= energyThreshould)) { parentChanges++; trace()<<"Changed parent. from "<<(int)routeInfo.parent<<" to "<<(int)best->neighbor; routeInfo.parent = best->neighbor; routeInfo.DT = best->info.DT; routeInfo.congested = best->info.congested; routeInfo.energie = best->info.energie; } } }

9. Paramètres d’évaluation

9.1 La durée de vie

Les nœuds capteurs sont des équipements sans contrôle avec une durée de vie limitée. Le réseau peut rapidement cesser de fonctionner normalement à cause d'une déviation ou d'un manque de planning et puisqu'un réseau de capteurs est généralement utilisé pour une longue durée sans possibilité de recharge, prolonger sa durée de vie revient primordial. L’évaluation de la capacité d'un réseau de capteurs à prolonger sa durée de vie est généralement liée à la définition de cette dernière. Les différentes définitions ont été citées dans le premier chapitre de cette thèse. Pour l’étude des performances de notre approche en termes de la durée de vie, nous allons considérer le réseau vivant temps qu’il est connexe. C'est-à-dire sa durée de vie est déterminée par le temps entre son initialisation et le moment où le réseau devient non connexe.

9.2 Changement de parent

L’algorithme proposé dans ce travail vise à contrôler la topologie d’un RCSF afin d’optimiser sa durée de vie par équilibrage de charges. Cela est assurée par le changement de parent d’un nœud si le degré de tolérance de ce dernier le qualifier à être le nouveau parent. Il est clair que l’opération de changement de parent joue un rôle important pour notre approche. Le nombre de fois dont le nœud a changé son parent sera considéré comme un paramètre d’évaluation de performances pour étudier l’impact du degré de tolérance proposé sur l’évolution de la topologie du réseau.


89

9.3 Energie consommé L’état de la batterie d’un nœud est un facteur principal qui a une influence directe

sur la durée de vie. Il est exprimé en pourcentage de l’énergie restante par rapport à l’énergie initiale. Ces valeurs sont fournit par le gestionnaire de ressources définit par Castalia et plus précisément avec les méthodes suivantes:

9.4 Hypothèses

Afin de réaliser des simulations, nous considérons les hypothèses suivantes:

1. Au début, chaque nœud a une énergie initiale. 2. Tous les nœuds capteurs sont alimentés par batterie à énergie limitée, sauf le Sink. 3. La taille du réseau est spécifiée au début de chaque simulation, le nœud 0 est choisi

comme Sink. Le tableau ci-dessous montre les autres paramètres de simulation:

Paramètre Valeur

Nombre de nœuds Jusqu'à 300

Champ de déploiement 250 x 250 mètres

Type de déploiement Aléatoire

Modèle radio CC2420

Puissance radio 0dBm

Energie initiale 18720 joulesTemps de simulation 100, 200, 300, ...1000 sec

Seuils: SHC, SE et SDT 10% de différence chacun

Tableau IV.1: paramètres de simulation

10. Résultats et analyse

Pour démontrer les performances de notre approche qui consiste à utiliser un RCSF basé sur un système multi agent par la suite avec tolérance aux pannes et qualité de service, nous faisons une comparaison avec le protocole CTP [OMP-09].

La figure IV.11 illustre le fonctionnement de notre protocole et montre que le trafic est distribué sur l'ensemble des nœuds. Cela est assuré par le changement des parents selon les paramètres de chaque nœud. Par exemple dans:

ResourceManager *resMgrModule; double spentEnergy = resMgrModule->getSpentEnergy (); double initialEnergy = resMgrModule-> par ("initialEnergy"); doubleremainingEnergy = initialEnergy-spentEnergy;


90

(a): Construction de l'arbre initial (b): le nœud 7 devient parent de 3 (c): le nœud 3 devient parent de 2 (d): le nœud 2 devient parent de 3 et 1 devient parent de 2 (e): le nœud 9 devient parent de 5

(a) (b)

(c) (d)

(e)

Figure IV.11: Illustration de fonctionnement

C

Asur lCTPmomnon incap

Lmétrjusqude lanœudensmonnomc’est

F

Unœul'initrécurimpode nleursêtre états

Chapitre 4:

Avant de déles graphes

P, et pour ment de l'in

connexe opables d’ac

'initialisatirique nombu'à la staba densité dds en plussité en utilitré dans labre de cha le momen

Figure IV.

Une relationd dans l'entialisation. rsif. Cela eortante pounœuds maiss durées demis en œus des nœud

: Propositio

étailler les s DTC (pola définit

nitialisationou déconnecheminer le

on commebre de sautbilisation ddu réseau s de la zonisant le noma figure IVangements

nt où il n’y

12. Relatio

n proportionsemble duAvoir bea

exprime quur avoir uns par contre vie eux-muvre qui estds.

0

5

10

15

20

25

30

35

40

45

Nom

bre total de chan

gemets

on d’une ap

résultats eour Distribtion de lan du réseauecté. C'est-eurs paquet

ence par ds (HC poue la topoloqui est dé

ne d’intérêtmbre moye

V.12 qui repde parent

a pas de n

on entre la

onnelle est réseau et

aucoup de ue l’étude dne topologiere il faut amêmes. Sint aussi une

1 2

Change

pproche dis

91

et les perforbuted Topdurée de

u de capteu-à-dire, quts de donné

diffuser le ur Hop Couogie. La duéfinie part ou de déen de voisinprésente la ts nécessai

nœuds qui c

densité du

remarquéle nombre voisins imp

de la densite tolérante aussi éviternon un méce sorte de c

3 4

Nombre m

ement de p

stribuée po

rmances deology Convie, nous

urs sans fil uelques nœées vers le

messageunt) les nœurée de l'opsa taille e

éploiement.ns des nœurelation e

ires pour achangent d

u réseau et

e entre le moyen de plique souvté du réseaaux panne les réseaucanisme decontrôle de

5 6

moyen de voi

parents à l'in

our le contr

e notre appntrol) par r

considéronjusqu'au muds dans Sink.

'init' et eœuds vont cpération det le rayon. Nous pouuds dans lentre la deatteindre u

de parents à

le processu

nombre mchangemenvent un chau à déployes par augmux denses qe gestion de topologie

7 8 9

isins

nitialisation

rôle de top

proche qui rapport auns la durémoment oùle réseau d

en se basachanger leu’initialisatin de transmuvons expre réseau coensité du Rune topoloà cette init

us d'initial

moyen de vnts de parehangement yer est unementation dqui peuventde la redon par chang

9 10

n

ologie d’unRCSF

sera notéeu protocoleée entre leù il devientdeviennent

ant sur laurs parentsion dépendmission derimer cettemme il est

RCSF et leogie stable,ialisation.

lisation

voisins parents lors de

de parente opérationdu nombret diminuerdance doitgement des

n F

e e e t t

a s d e e t e ,

r e t n e r t s


92

Figure IV.13: Impact sur la consommation d’énergie

La figure IV.13 montre une amélioration en ce qui concerne l’énergie consommée par un réseau avec notre approche notée DTC par rapport au protocole CTP. Cela est justifié par l’introduction de la métrique HC lors du choix d’un chemin, cela permet à notre approche de faire des transferts à travers des chemins par fois mieux que ceux choisis en CTP qui est basé seulement sur la qualité des liens. La déférence n’est pas importante mais la distribution de cette énergie économisée sur les différents nœuds surtout ceux qui jouent le rôle de parent va donner une meilleure durée de vie comme le montre la figure IV.14.

Figure IV.14: Impact sur la durée de vie

Les courbes de la figure IV.14 montrent une divergence remarquable dans le cas des RCSF de grande taille. En effet, la densité élevée des nœuds capteurs permet à notre approche DTC de trouver d'autres itinéraires pour conserver l'énergie de ceux utilisés. Par contre, dans CTP, la congestion ou la sur-utilisation d'un chemin conduit à la mort prématurée des nœuds. En cas des réseaux avec faible densité, il n'y a pas une grande différence entre les deux méthodes parce que la topologie est presque figée avec un petit nombre de nœuds.

01020304050607080

50 100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

850

Energie totale (m

Joules)

Temps (Unités)

Consommation d'énergie CTP

DTC

02000400060008000

1000012000140001600018000

0 50 100 150 200 250 300

Durée

de vie (Unités)

Nombre de noeuds

Durée de vie du réseau DTC

CTP


93

Figure IV.15: Changement de parents dans le temps

On remarque dans la figure IV.15 que la différence dans le nombre de changements de parents pour les deux cas n'est pas importante au début, et avec le temps une divergence est bien remarquable, ça s'explique par la diminution des degrés de tolérance calculés par notre protocole, ce qui nécessite des changements de parents afin d'équilibrer les charges.

Figure IV.16: Changement de parents selon la taille du réseau

La figure IV.16 montre aussi les courbes de changement de parent mais cette fois en fonction de la taille du réseau. Par augmentation de la taille, on remarque une différence entre le nombre de changement de parent pour les deux protocoles. Ce dernier est plus élevé pour les réseaux à grande échelle qui assurent l’existence d’autres chemins dont le meilleur sera sélectionné. L'utilisation de plusieurs paramètres dans notre protocole donne plus d'opportunités que le CTP qui utilise seulement la qualité des liens.

0

500

1000

1500

2000

2500

3000

3500

4000

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700nombre total de chan

gemen

ts de

parents

Temps (Unités)

Changements de parents DTC

CTP

0

200

400

600

800

1000

1200

0 7 50 100 150 200 250 300

nombre total de chan

gemen

ts de

parents

Nombre de noeuds

Changement de parents DTC

CTP


94

11. Conclusion

Nous avons proposé dans ce chapitre une nouvelle approche pour le contrôle distribué de la topologie d’un réseau de capteurs sans fil. Cette approche utilise une nouvelle métrique que nous avons appelé degré de tolérance d’un nœud. Ce degré est évalué à chaque fois qu’un paquet de contrôle est reçu. Chaque nœud est chargé de calculer localement les degrés de tolérance de ses voisins et il décide de changer son parent si un autre voisin de meilleur degré de tolérance est détecté.

L’utilisation du simulateur Omnet++/Castalia nous a permet d’expérimenter notre approche et extraire quelques résultats afin d’évaluer ses performances. Ces résultats montrent l’avantage des protocoles distribués pour le fonctionnement des RCFSs. En effet, dans notre protocole, chaque nœud est chargé de sélectionner son parent et cela au moment du transfert ce qui garantit la distribution des charges sur tous les voisins et donc optimiser la durée de vie. Les nœuds dans notre approche sont autonomes et capables de détecter et changer leurs parents mais en coopération avec les autres. Inspirée de cette autonomie et de ce principe coopératif et émergent, nous allons proposer une architecture multi-agent qui sera utilisée pour implémenter notre algorithme sur un RCSF qui supporte cette technologie. C’est l’objectif du chapitre suivant.

Chapitre 5 Proposition d’une architecture multi-agent pour le contrôle de topologie d’un RCSF 1. Introduction ............................................................................................................. 95 2. Cycle de vie d’un nœud capteur à base d’agent ...................................................... 95 3. Modèle du système multi-agent proposé ................................................................. 96

3.1 Déploiement des agents .................................................................................... 96 3.2 L’agent de contrôle de topologie ATCagent ..................................................... 97

4. Les outils utilisés ..................................................................................................... 97 4.1 Aperçu sur les capteurs Sun Spots ................................................................... 97

4.1.1 Les capteurs ............................................................................................... 97 4.1.2 La machine virtuelle Squawk ..................................................................... 98 4.1.3 Manipulation des SunSpots ....................................................................... 99

5. Indications sur l’implémentation de notre algorithme en java .............................. 100 6. Intégration du fonctionnement multi-agent .......................................................... 101

6.1 Choix de la plateforme multi-agent ................................................................ 101 6.2 Structure d’un projet MAPS .......................................................................... 102

7. Implémentation du SMA ....................................................................................... 102 7.1 Scénario de déploiement ................................................................................. 102 7.2 Le plan d’exécution ........................................................................................ 103 7.3 Implémentation de l’agent ATCagent ............................................................ 103 7.4 Implémentation de la MIDlet ......................................................................... 105 7.5 Déploiement et exécution ............................................................................... 105

8. Résultats ................................................................................................................ 106 9. Conclusion ............................................................................................................. 109

Chapitre 5: Proposition d’une architecture multi-agent pour le contrôle de topologie d’un RCSF

95

1. Introduction La mise en œuvre d’un système multi-agent nécessite l’existence d’une plateforme

logicielle qui supporte la technologie agent. Une telle plateforme joue le rôle d’intermédiaire entre le dispositif cible qui est un capteur sans fil dans notre cas et plus précisément son système d’exploitation d’un côté, et le code à exécuter qui est porté par les agents eux-mêmes de l’autre. En particulier, ce type de plateforme fournit les fonctionnalités qui rendent possible la migration ou la mobilité des agents entre les différents nœuds et dans les deux sens en entrée et en sortie, en plus de leur déploiement dans le capteur cible et leur exécution. De cette manière, l’implantation d’une plateforme multi-agent sur un réseau de capteurs sans fil donne aux capteurs la capacité de changer leur comportement et rend dynamique leur intelligence. En effet, pour changer le comportement d’un nœud capteur sans fil sans le reprogrammer (chose qui est parfois impossible), il suffit de déployer un nouvel agent qui met en œuvre le nouveau raisonnement à condition que le capteur en question supporte la technologie agent.

Dans ce contexte, on étudie dans le présent chapitre la possibilité d’exploiter ces avantages offerts par les systèmes multi-agents afin de gérer le comportement d’un réseau de capteurs sans fil. Pour cela, on propose l’architecture d’un système multi-agent qui sera responsable du contrôle de la topologie du réseau en se basant sur l’algorithme proposé et évalué dans le chapitre précédent. L’architecture proposée vise à simplifier l’implémentation et le déploiement de cet algorithme de contrôle de topologie en plus de l’adaptation de la structure logicielle aux principes des systèmes multi-agents exigés par la plateforme utilisée. Pour ce but, nous avons choisi de travailler avec la plateforme MAPS (Mobile Agent Platform for Sun spots).

On donnera dans ce chapitre les détails de la conception et l’implémentation de l’architecture multi-agent proposée avec quelques résultats obtenus par simulation et qui montrent l’adaptation et l’apport de la technologie agent pour un réseau de capteurs sans fil avec un fonctionnement totalement distribué.

2. Cycle de vie d’un nœud capteur à base d’agent

L’objectif principal de la proposition d’une architecture multi-agent dans le domaine des RCSF est de rendre ce dernier dynamique, extensible et évolutif du point de vue de son monitoring. Au début, l’exploitation d’un réseau de capteurs sans fil ne nécessite que son déploiement dans la zone d’intérêt avec quelques fonctionnalités de base comme par exemple la détection de voisinage mais à condition que les capteurs soient dotés d’une plateforme qui supporte l’exécution d’un système multi-agent. Ensuite, l’utilisateur ou le développeur du réseau peut suivre et modifier le comportement de son réseau à travers une station de contrôle qui permet la gestion d’un système multi-agent à travers tous les capteurs. Il aura donc la possibilité de déployer, exécuter, migrer ou retirer des agents.

Pour notre architecture, chaque capteur, après son déploiement aura le cycle de vie:

- Détection de voisinage. - Déploiement d’un agent de contrôle de topologie. - Initialisation du réseau et construction de la topologie initiale. - Contrôle de topologie. - Terminaison sur état critique ou défaillance.


96

Notons ici qu’en réalité ces fonctionnalités concernent seulement le monitoring du réseau de capteurs afin de prolonger sa durée de vie et optimiser la qualité de service d’une manière distribuée. Les fonctionnalités relatives à la collecte de données et les autres tâches ne sont pas sujet de cette étude.

3. Modèle du système multi-agent proposé

Afin d’intégrer un système multi-agent comme mise en œuvre de la solution de contrôle de topologie proposée précédemment, on propose d’utiliser un système simple et adapté aux caractéristiques d’un réseau de capteurs sans fil. Ce dernier comporte un ensemble d’agents mobiles et identiques que nous appelons agents de contrôle de topologie notés ATCagent et qui sont chargés de construire la topologie initiale puis maintenir le bon fonctionnement du réseau en permettant aux nœuds capteurs de déterminer le meilleur parent à tout moment.

3.1 Déploiement des agents

La détection de voisinage est la première opération à effectuer par un RCSF qui vient d’être activé. Cette opération permet de fournir la liste des voisins de chaque nœud capteur. Notre solution proposée pour le contrôle de topologie commence par la construction de la topologie initiale en se basant sur le nombre de sauts optimal. La mise en œuvre de cette opération d’initialisation peut être faite à travers un agent d’initialisation lancé par la station de base vers tous les nœuds. Du fait que la migration des nœuds peut augmenter le cout de l’opération de l’initialisation en plus des messages échangés pour cet objectif, nous avons pensé à concevoir un seul agent qui regroupe la procédure de l’initialisation et celle du contrôle de topologie puisque les deux procédures se basent sur des décisions suite à des paramètres échangés localement. De cette manière, le déploiement de notre solution à base d’agents se fera donc à travers la migration d’un seul type d’agent et on optimisera par conséquent le surcoût de cette opération.

Afin de mettre en œuvre le fonctionnement défini précédemment, l’agent ATCagent sera déployé dans tous les nœuds en exploitant la capacité de migration des systèmes multi-agent. En effet, la station de base ou bien le Sink commence à reproduire par migration l’agent ATCagent vers les voisins proches, c'est-à-dire à un seul saut avec une valeur HC (nombre de sauts) nulle. Tout capteur qui va recevoir cet agent pour la première fois, met à jour sa valeur HC en choisissant la meilleure entre sa valeur actuelle et celle portée par l’agent ATCagent puis il renvoie cet agent avec la nouvelle valeur HC et ainsi de suite. A la fin de ce procédé, c'est-à-dire au moment où tous les nœuds ont reçu l’agent avec mise à jour des valeurs HC, on obtiendra une topologie initiale sous forme d’arbre construite sur la base du meilleur nombre de sauts vers le Sink. Donc chaque nœud a un parent et éventuellement des fils.

On remarque ici que la migration de l’agent ATCagent joue presque le même rôle que l’échange de message Init dans une implémentation classique. En effet, le déploiement de cet agent a deux objectifs dont le premier est de mettre à jour les valeurs HC nécessaires pour la construction de l’arbre. Le deuxième objectif est de fournir aux nœuds capteurs le code définissant le comportement selon notre solution qui est l’agent lui-même puisque les nœuds sont supposés ici vide, c'est-à-dire n’ont aucun raisonnement chargé sauf la détection des voisins.


97

3.2 L’agent de contrôle de topologie ATCagent

Les agents qui constituent notre système multi-agent ont généralement un fonctionnement réactif. En effet, à chaque moment un agent de type ATCagent se trouve dans un état déterminé. Le passage d’un état à un autre est provoqué par un évènement externe qui vient du voisinage du nœud portant l’agent en question ou bien interne dans le même nœud capteur. Les états possibles d’un agent et les évènements associés sont montrés dans le diagramme d’états de la figure ci-dessous.

Figure V.1 : Diagramme d’états de l’agent ATCagent

Au début du fonctionnement de notre système, seule la station de base possède un agent de type ATCagent. Le lancement de ce dernier est un évènement en lui-même qui provoque sa reproduction sur les nœuds voisins par migration. L’exécution avec succès de la migration va conduire à un autre état qui est l’attente de l’opération d’initialisation. Cet état d’attente est imposé par le fait que le déploiement de l’agent sur l’ensemble des nœuds prendra un certain temps, il est donc impossible de faire coopérer un agent stable avec un autre agent en migration. A la fin de cette attente, les agents passent à la construction de la topologie initiale que nous l’avons appelée initialisation. Enfin, l’ensemble des agents doivent prendre leur tâche principale qui est le contrôle de topologie du réseau par coopération entre eux jusqu’à épuisement d’énergie.

4. Les outils utilisés

Comme nous l’avons évoqué dans l’introduction de ce chapitre, et pour la mise en œuvre de l’architecture multi-agent proposée, la plateforme MAPS a été choisie. C’est une plateforme multi-agent conçu pour des capteurs de type Sun Spot. Pour cela et avant de détailler l’implémentation de notre solution, on donne ici un aperçu sur les capteurs en question ainsi que les outils qui permettent de programmer, manipuler et gérer des applications dans le monde Sun Spot.

4.1 Aperçu sur les capteurs Sun Spots

4.1.1 Les capteurs

La technologie SPOT (Small Programmable Object Technology) (http://www.sunspotworld.com) qui signifie technologie pour petits objets programmables a été initiée par SUN en 2006 compte tenu des enjeux commerciaux que suscitent les réseaux de capteurs sans fil. Un réseau de capteurs Sun Spot est fourni sous forme d’un kit matériel avec les logiciels nécessaires. La partie matérielle qui

Début

Migration En attente

d’nitialisation

Contrôle de topologie

Lancement Fin de migration

Epuisement Fin

Attente terminée

Construction de topologie

Topologie établie

repréarchproc3.7Vphysun cprog

Laaux progniveade Jtotal

4.1.2

SqSunSd'expaugmstandet peen œconsréifiéapplmachl’espappa

EInterréseaopérapplsembl’exp

Chapitre 5

ésente les itectures resseurs AR

V avec la psiques princcapteur degrammation

a partie logcapteurs a

grammationau complex2ME mais lité en java

2 La mac

quawk [SIMSpots. Elle ploitation mente les dards en uermet l'exéœuvre un idérées comés). Cette ications à hine virtue

pace mémoareils.

n termes drface) relataux de capations de ications sublent adaptploitation d

5: Propositi

capteurs répandues, RM. Les capossibilité dcipalemente lumière n.

gicielle est insi que den des captexe comme de taille ré

a.

chine virt

M-06]est upeut fonctet permet performan

un code intécution efficmécanismemme des oisolation dla fois. La

elle sur leoire, chose

de déveloptives au mpteurs sans

connexionur les apptées pour l

de la platefo

ion d’une a

et la statels que

apteurs dede recharget un accélavec huit

Figure

un ensembes outils deeurs directeNesC par éduite nom

uelle Squ

une petite mtionner surune commces des aperne précocace du bye d'isolatioobjets de pd'applicatioa combinaies ressourc

qui est t

pement, Smonde sanss fil, cette n, authentiareils sansla mise en orme MAP

architecture

98

ation de l'interface

e SUN sonte. Ils sont léromètre t

LEDs tri

V.2 : Capt

ble qui come développeement en jexemple. S

mmée Squaw

awk

machine vdes capteu

munication pplicationsmpilé dont

yte code. Eon d'applicpremière con permet ison de ceses du disptrès adapt

quawk fous fil permeAPI est uification ds fil. Tout

œuvre de PS.

e multi-age

base repose réseau st alimentédotés de p

tri-dimensiocolores qu

teurs Sun S

mprend uneement et deava, donc

SPOT utiliswk Virtual

irtuelle javurs sans fil directe ave. Squawkt le format

En outre, lacations danclasse (ce qégalement s caractéripositif ciblée pour u

urnit une Aettant d'éc

une extenside fichiers es ces carnotre solu

ent pour le

se sur desans fil IEs par des plusieurs caonnel, un c

ui peuvent

Spot

e machine ve débogagene plus utse une macl Machine q

va embarqusans avoir

ec l’unité dtraduit le est indépe

a machine vns lequel lqui signifieà Squawk

istiques rédle surtout un déploiem

API (Applicrire des aon des fondéployés

actéristiquution multi

contrôle dd

es standardEEE 802.1batteries lapteurs de capteur theêtre man

virtuelle jave afin de petiliser un lachine virtuqui est écri

uée sur lesr besoin d’ude traitemees fichiers endant de virtuelle Sqles applicae qu'ils pek d'exécuteduit l’influen ce qu

ment sur

ication Proapplicationnctionnalitéet l’intégr

ues et fonci-agent en

de topologied’un RCSF

ds et des5.4 et leslithium-iongrandeurs

ermique etnipulés par

va adaptéeermettre laangage basuelle à baseite dans sa

s appareilsun systèmeent, ce quide classesla positionquawk metations sontuvent êtrer plusieursence de lai concernedes petits

ogrammings pour lesés pour lesration desctionnalitésparticulier

e F

s s n s t r

e a s e a

s e i s n t t e s a e s

g s s s s r


99

4.1.3 Manipulation des SunSpots

Les programmeurs et les utilisateurs des capteurs Sun Spot peuvent contrôler et manipuler leurs réseaux de capteurs sans fil à travers un tableau de bord appelé SunSpotManager. C’est un outil qui permet de reconnaitre des capteurs physiques actifs à travers la station de base ou bien connectés à un port USB de la machine exécutant cet outil. Sinon, et si le programmeur ne dispose pas de capteurs physiques comme notre cas, SunSpotManager offre la possibilité d’utiliser des capteurs virtuels avec les mêmes fonctionnalités que ceux physiques. On peut même faire interagir des capteurs physiques avec des capteurs virtuels de la même manière.

Figure V.3 : Le tableau de bord SunSpotManager

Le déploiement des capteurs virtuels peut être fait manuellement ou bien à travers un fichier XML et ceci en utilisant un émulateur appelé Solarium associé à l’outil SunSpotManager. C’est un vrai émulateur qui offre plusieurs fonctionnalités comme le déploiement des capteurs sur la Map ou la carte géographique de la zone d’intérêt en plus de la manipulation de l’environnement des capteurs à travers des Leds (température, lumière, …) comme il est montré dans la figure V.4.

Figure V.4 : L’émulateur de réseau Solarium


100

Un schéma typique du fonctionnement de l’émulateur Solarium est montré dans la figure V.5. La composante SharedBasestation représente l’application de gestion et d’exploitation du réseau de capteurs à travers une station de base ou un Sink. Les autres composants du réseau peuvent être des capteurs réels (Real Sun Spot) ou bien des capteurs virtuels (Virtual Spot) dont les deux fonctionnent avec la machine virtuelle Squawk pour l’exécution du code java.

Figure V.5 : Interaction entre les composants d’un RCSF dans Solarium

A travers cet outil, on peut aussi charger sur un capteur l’application à exécuter sous forme d’un fichier java archive. Cette opération est appelée déploiement de l’application à travers une MIDLet (classe java assurant le dialogue entre le système et l'application). Si l’application est bien déployée, on peut lancer son exécution. Cette opération s’effectue au niveau de la couche User Application montrée dans la figure précédente.

5. Indications sur l’implémentation de notre algorithme en java Comme nous l’avons cité, et afin de déployer notre protocole sur des capteurs

SunSpot, il doit être écrit sous forme d’un projet java. Pour cela, nous avons réutilisé la même architecture logicielle utilisée pour la simulation de notre algorithme de contrôle de topologie avec Castalia dans le chapitre précédent qui était inspirée du protocole CTP. Mais cette fois-ci avec un code java au lieu de C++.

En particulier, les changements que nous avons apportés concernent le module LinkEstimator qui fait le calcul de la métrique « degré de tolérance » et le module Routing qui est responsable du contrôle de la topologie proprement dit. C'est-à-dire le suivi des changements de parent selon le degré de tolérance de chaque nœud.

Real Sun Spot

User Application

Spot Library

Squawk VM

Desktop

Solarium

Virtual Spot

Virtual Spot

Discovery code

User Application

Spot Library

Emulator

Squawk VM

User Application

Spot Library

Emulator

Squawk VM

Shared Basestation

Radio


101

La figure V.6 montre les principales classes adaptées et leurs constituants nécessaires pour notre solution.

Figure V.6 : les Classes principales adaptées

6. Intégration du fonctionnement multi-agent

6.1 Choix de la plateforme multi-agent

Pour l’évaluation des performances de notre approche dans un environnement multi-agent, nous avons exploité la plateforme MAPS (Mobile Agent Platform for Sunspot) [AIE-09](http://maps.deis.unical.it/)qui est une plateforme permettant l’exécution d’un protocole à base d’agent sur des capteurs sans fil de type Sun Spot. C’est un environnement java qui fournit des APIs nécessaires à l’exécution et la mobilité des agents sur ce type de capteurs.

Le choix de cette plateforme est justifié par son caractère libre et la bonne intégration dans des réseaux de capteurs de type Sun spots pour lesquels il existe un kit de développement, le SDK (Sun Spot Developement Kit) en l’occurrence qui peut être installé comme plugins pour Eclipse ou Netbeans. Il suffit donc d’ajouter le package MAPS à cet environnement puis développer le SMA désiré. Un aperçu sur la structure logicielle de la plateforme MAPS a été donné dans le troisième chapitre de cette thèse. On reprend cette architecture quand on détaillera l’intégration de notre SMA par la suite.

Puisque notre solution consiste à intégrer un système multi-agent pour le contrôle de topologie d’un RCSF selon l’approche proposée, et afin de permettre la migration et l’exécution d’agents sur les capteurs, nous exploitons la plateforme MAPS pour permettre la création, la migration et l’exécution des agent sous forme de code java sur les capteurs Sun spots.


102

6.2 Structure d’un projet MAPS

Figure V.7 : Structure typique d’un projet MAPS

Un projet développé à l’aide de la plateforme MAPS a une structure similaire des projets Sun Spot. Typiquement, cette structure doit comprendre les répertoires et les fichiers montrés dans la figure V.7 et qui sont :

- Le répertoire src : contient le code source du projet. - Le répertoire ext-lib : contient toutes les bibliothèques externes qui sont utilisées

pour le développement du code source. Principalement, on doit inclure les packages Sun Spot (multihop_common.jar, spotlib_common.jar, spotlib_device.jar, squawk_device.jar, transduce_device.jar) et aussi la bibliothèque MAPS (MAPS_1.1.jar que nous avons utilisé pour notre cas).

- Le répertoire ressources : qui est utilisé pour définir les paramètres de l’application MIDlet à travers le fichier MANIFEST.MF. Ces paramètres précisent par exemple le nom de l’application, sa version et la classe principale dite midlet.

- Le fichier build.properties : qui contient un ensemble de paramètres nécessaires pour construire le fichier .jar de l’application en question.

- Le fichier build.xml : c’est un fichier important pour le module Ant qui est responsable de la construction, le déploiement et l’exécution de l’application finale.

7. Implémentation du SMA

7.1 Scénario de déploiement

Selon le fonctionnement défini précédemment, les nœuds capteurs peuvent être déployés seulement avec la plateforme MAPS sans aucun autre agent relatif à notre solution. Après la détection de voisinage, le comportement des nœuds sera défini par migration de l’agent ATCagent qui met en œuvre notre solution à partir de l’application principale (implantée sur la station de base). A l’arrivée de chaque nœud, l’agent ATCagent se reproduit sur les nœuds voisins, il attend un certain temps avant de procéder à l’initialisation de la topologie puis le contrôle de topologie proprement dit. La figure ci-après montre l’architecture logicielle des nœuds après le déploiement de l’agent ATCagent.


103

Figure V.8 : Architecture logicielle après déploiement du SMA

7.2 Le plan d’exécution

Selon la méthodologie de développement MAPS, il faut définir un plan d’exécution pour chaque agent, un tel plan peut être modélisé par un diagramme de plan qui montre les déférents états de l’agent en réaction avec les événements possibles. Le plan d’exécution de notre agent ATCagent est présenté dans la figure V.9 conformément au diagramme d’états tracé précédemment.

Figure V.9 : Diagramme de plan de l’agent ATCagent

7.3 Implémentation de l’agent ATCagent

Le développement d’un système multi-agent avec la plateforme MAPS nécessite la définition des états prévus pour chaque agent. Le changement d’un état à un autre vient comme résultat d‘un événement qui peut être relatif à la réception d’un message ou la valeur d’un timer par exemple. Donc le comportement d’un tel agent est défini par les actions à exécuter en réponse de chaque événement bien sur après changement d’état. On appelle un plan cette définition d’actions selon états et événements. L’implémentation des plans doit être faite dans la méthode eventHandler() dont les portions de code relatifs à chaque événement sont détaillés dans ce qui suit. Au début du fonctionnement, c'est-à-dire l’activation de la station de base par l’utilisateur, un agent ATCagent est lancé, c’est l’événement AGN_START. Comme réponse à cet évènement, l’agent change son état vers MIGRATION et se reproduit sur les nœuds voisins.

Agent ATC

Start Migration Wait_Init

Execute_ATC

START MG_EXECUTE

CRITICAL End

Timer Expir

Topo_ConstTOPO_ESTA

MAEE

RM TM MAN MACC

Sun Spot / Squawk VM

MAA

ATCagent Nœud

MAEE

RMTMMAN MACC

Sun Spot / Squawk VM

MAA

ATCagentNœud


104

AGN_START :

Si la migration est exécutée avec succès, ce qui est évoqué par l’événement MGR_EXECUTED, l’agent qui a été l’initiateur de sa reproduction sur les nœuds voisins se met en attente pour certain temps pour que les voisins reçoivent la copie de l’agent avant de commencer l’initialisation. Nous avons noté cet état WAIT_INIT. Après cette durée d’attente, l’agent passe à la construction de la topologie initiale, c’est ce que nous avons noté l’état TOPO_CONST.

La stabilisation de la topologie initiale définie dans notre solution est notifiée par

l’événement TOPO_ESTAB. Si un agent reçoit cet évènement il passe à l’étape de contrôle de topologie qui est notée par l’état EXECUTE_ATC. A cette étape l’agent aura un comportement défini par notre algorithme de contrôle de topologie.

Enfin, si un nœud arrive à un état critique par épuisement de son énergie par exemple, l’agent associé met fin à son exécution. Ceci est traduit par la réception de l’événement CRITICAL.

Il reste maintenant à définir le code de l’agent lui-même. Pour MAPS, tous les agents ont presque le même code. La différence entre un agent et un autre réside dans les plans utilisés et qui déterminent le comportement de chacun. Donc le code d’un agent consiste à instancier ou choisir un plan pour l’agent en question puis lancer son exécution comme le montre la portion du code ci-après :

if (event.getName() == Event.CRITICAL { this.terminateAgent(); }

if (event.getName() == Event.TOPO_ESTAB) { this.currentState = EXECUTE_ATC; // lancer le package ATC }

if (event.getName() == Event. MGR_EXECUTED) { this.currentState = WAIT_INIT; Thread.sleep(10000); // attendre 10 secondes par exemple this.currentState = TOPO_CONST; // Lancerl’initialisation }

if (event.getName() == Event.AGN_START) { this.currentState = MIGRATION; Vector neighbors = this.agent.getNeighbors(); for (i=0, i<neighbors.size(), i++) { String address = (String)neighbors.elementAt(i); this.agent.askForMigration(address); } }


105

7.4 Implémentation de la MIDlet

Le lancement du réseau de capteurs sans fil doit se faire au niveau de la station de base. Cela est implémenté à travers la classe ATCApp qui est une extension de la classe MIDlet utilisée généralement par les capteurs Sun Spots. On s’intéresse principalement à la méthode startApp() qui est responsable du lancement de l’application qui se traduit par la création d’un SMA avec un agent ATCagent.

7.5 Déploiement et exécution

Avec l’émulateur Solarium de Sun Spots et à travers un certain nombre de capteurs virtuels dotés de la plateforme MAPS, on peut lancer à partir de la station de base notre solution multi-agent. Les paramètres choisis pour la simulation du fonctionnement dans un réseau de capteurs virtuel sont montrés dans le tableau V.1 ci-après.

public class ATCApp extends MIDlet { protected void destroyApp(booleanarg0) throws MIDletStateChangeException {} protected void pauseApp() {} protected void startApp() throws MIDletStateChangeException { try{ IMobileAgentServer mas = Factory.getIMobileAgentsServer("120"); if(!mas.addAgent("ATC.ATCAgent", null)) System.out.println("Agent non intege dans le SMA"); } catch(InvalidCommunicationPortException e) { e.printStackTrace(); } } }

Public ATCAgent(String id, String executionAgentAddress) throws NoSuchMailboxException { super(id, executionAgentAddress); ATCPlane tap = new ATCPlane(this); multiplaneStateMachine.addElement(tap); } public static void main (String [] args) { try { ATCAgentatcAgent = new ATCAgent(args[0], args[1]); while(!atcAgent.isTerminated()) { atcAgent.waitForEvents(); atcAgent.run(); } } catch(Exception e) { LedsManager.error(); e.printStackTrace(); } }


106

Paramètre Valeur

Nombre de nœuds Jusqu'à 100

Champ de déploiement 250 x 250 mètres

Type de déploiement Aléatoire

Modèle radio CC2420

Energie initiale 18720 joules

Temps d’attente d’initialisation

Selon la taille du réseau (choix d’une seconde par nœud en moyenne)

Seuils: SHC, SE et SDT 10% de différence chacun

Tableau V.1: Quelques paramètres de simulation

8. Résultats

En plus des résultats discutés dans le chapitre précédent sur les performances de l’algorithme de contrôle de topologie proposé, on donne ici quelques résultats de simulation dans un environnement multi-agent. Ces résultats concernent l’algorithme lui-même et aussi l’impact et le coût de l’utilisation de la technologie agent dans un RCSF.

En premier lieu, on s’intéresse au cout de l’intégration d’un SMA et son déploiement dans un RCSF. La figure V.10 montre le coût énergétique de l’opération de déploiement de la solution. Il est exprimé par le taux ou le pourcentage de l’énergie nécessaire à cette étape en fonction de la taille du réseau. Il est clair que ce coût dépend de la taille du réseau et aussi de la taille de l’agent à déployer. Ici, on remarque que cette opération nécessite plus d’énergie dans le cas des réseaux de grande taille par rapport à ceux de petite taille mais toujours dans la même zone de déploiement des capteurs. Mais si on pense en termes de densité, cela ne dépend pas de la taille du réseau mais du nombre de voisins de chaque nœud puisque les migrations d’agent se font localement. Donc le taux obtenu par simulation et qui avoisine les 0.02 % est jugé acceptable et n’a pas une grande influence sur la durée de vie du RCSF.

Eévalurésul

Lafil enprécicomm

Chapitre 5

n ce qui cué précédeltats en fai

a figure V.n faisant vaisément le me métriq

0

0

0

Pourcentage (%

)

0

10

20

30

40

50

60

70

80

Energie totale (m

Joules)

5: Propositi

Figure V

concerne leemment, nsant varier

Figur

11 montre arier la méprocédé d

que de con

0

,005

0,01

,015

0,02

,025

0,03

0

0

0

0

0

0

0

0

0

50 100

150

ion d’une a

V.10 : Coût

es performanous avonsr les param

re V.11 : I

la consométrique utilide changemntrôle de t

10

200

250

300

350

T

Consom

architecture

107

t de l’opéra

ances de l’s exploité

mètres des r

Impact du p

mmation de isée par le

ment de partopologie e

30

Taill

350

400

450

500

Temps (Unité

mmation d'é

e multi-age

ation du dép

algorithmele SMA

réseaux.

paramètre

l’énergie dprotocole drent. L’utien ignoran

50

e du réseau

550

600

650

700

és)

énergie rése

ent pour le

éploiement

e de contrôdéployé p

de contrôl

dans un résde contrôlelisation de

nt la quali

0

700

750

800

850

eau

contrôle dd

SMA

ôle de topopour retire

e

seau de cape de topoloe l’état de té des lien

100

850

Ene

ATC

Qu


ologie déjàer d’autres

pteurs sansogie et plusla batteriens conduit

ergie

C

alité

e F

à s

s s e t

parfoqui pconsseulesans de qet dochemglobanomd’écosur ll’éne

Pde superm

OpA

B

C

Chapitre 5

ois à des trprovoque dommation ement sur lcongestion

quelques chonc des opémins plus aal des tranbre de sautonomiser ula durée dergie et la q

our examinuivre ses d

mis de trace

On remarqphases : A. Une co

rôle de B. Après c

devientaugmen

C. Par la sun autr

333

3333

3

Energie (m

Joules)

5: Propositi

ransferts dedes erreursde l’énergila qualité dn et évite phemins peuérations deu moins lonsferts de ts pour la

un peu l’énee vie du rqualité des

ner cette codépones ener le diagra

Figure V

que que le

onsommatioparent de

certains temt leur parente ses dépesuite, le nœre parent o

35,435,635,836

36,236,436,636,837

37,2

50 100

A

ion d’une a

e paquets ss et des retie. En outrdes liens pepar conséqut conduire e reconfigurongs en termpaquets. L

a maintenanergie du rééseau et saliens sont

onsommati termes d’

amme de la

V.12 : Suiv

e nœud en

on stable squelques nmps, d’autrent et preenses.

œud en queptimal, ce

150

200

250

300

30

Consom

A

architecture

108

sur des lientransmissiore, un procéermet un tuent les retà l’épuise

rations serme de nomLa combinnce de la téseau. Les ra qualité dpris en con

ion au niveénergie da

a figure V.1

vi de la con

n question

selon la stnœuds. res nœuds nd en cha

estion est requi impliq

350

400

450

500

550

Temps

mmation d'é

B

e multi-age

ns congestioons qui onédé de charansfert detransmissioment de qont nécessa

mbre de sauaison de copologie darésultats obde service nsidération

eau d’un nœans un inte12 ci-après.

nsommation

et durant

ructure to

voisins rejarges leurs

elâché par ue un relâc

550

600

650

700

750

s (Unités)

énergie d'un

ent pour le

onnés ou det des influngement de paquets àons, par conuelques nœaires et qu

uts en faisaces deux mans notre sbtenus ici parce que .

œud capteuervalle de t.

n d’un cap

cette pér

pologique

oignent nos transferts

quelques vchement de

750

800

850

900

950

n noeud

C

contrôle dd

e mauvaiseuences direcde parent qà travers dentre la sur-œuds sur cei donnent nt augmen

métriques esolution ATont un impla consom

ur, nous avtemps, ce q

teur

riode passe

initiale où

otre capteus de paqu

voisins qui e sa consom

950

1000

1050

1100

Energie de


e qualité cectes sur laui est basées chemins-utilisationes derniersparfois des

nter le coûten plus duTC permetpact direct

mmation de

vons essayéqui nous a

e par trois

ù il joue le

ur étudié, ilets ce qui

ont trouvémmation.

e noeud

e F

e a é s n s s t u t t e

é a

s

e

l i

é


109

9. Conclusion

Après avoir proposé et évalué une solution distribuée pour le contrôle de topologie d’un RCSF dans le chapitre précédent, nous avons détaillé l’implémentation d’un système multi-agent en exploitant la plateforme MAPS vu qu’elle est gratuite, open source et basée sur la programmation java. Nous avons proposé une architecture multi-agent qui consiste à faire migrer un agent de contrôle de topologie vers tous les nœuds capteurs après leur déploiement. Cette manière d’implantation du fonctionnement après le déploiement des nœuds est intéressante du fait qu’elle permet à tout moment de faire injecter des nouveaux capteurs dans le réseau ou encore changer totalement leur comportement si l’utilisateur veut changer de protocole ou d’application sans avoir besoin d’une intervention physique au niveau des capteurs. Le RCSF devient donc plus adaptatif, émergent et extensible à travers les capacités des SMA en termes de coopération et de migration. En plus, la technologie multi-agent semble très adaptée à la nature distribuée des RCSF et leurs applications.

Les résultats obtenus par simulation montrent l’impact de la formule proposée pour le calcul du degré de tolérance utilisé lors du changement de parent d’un capteur ce qui confirme les résultats obtenus dans le chapitre précédent. En particulier, nous avons étudié le coût de la migration des agents lors du déploiement de la solution. On estime que ce coût est acceptable puisqu’il est largement inférieur à 1 % de l’énergie du réseau et il est fortement lié à sa densité. Dans ce contexte, la prise en considération de la redondance des capteurs en combinaison avec une solution à base d’agents peut encore diminuer le coût.

Conclusion générale

110


Dans cette thèse, nous avons tout d’abord, présenté un état de l'art sur la surveillance des réseaux de capteurs sans fil, notamment les travaux qui s’intéressent aux traitements distribués. Les techniques de contrôle de topologie qui visent à développer des protocoles capables de construire et de maintenir des topologies tolérantes aux pannes tout en garantissant une qualité de service avec une durée de vie optimisée sont synthétisées.

L'utilisation des systèmes multi-agents dans les réseaux de capteurs sans fil a été traitée par la suite avec une classification des travaux réalisés récemment dans ce contexte. Notre classification est faite selon les objectifs de chaque travail comme la proposition des architectures logicielles innovantes pour les applications et les services, l’organisation du réseau de capteurs de telle sorte que la structure soit coopérative. On cite notamment les techniques de clustering, le routage qui est le problème le plus traité vu son importance, le monitoring en relation avec la mobilité, et récemment les techniques de la sécurité.

Nous avons constaté qu’il y a peu de travaux basés sur une technologie multi-agent traitent les problèmes liés au contrôle de la topologie et que la gestion d’une topologie nécessite une forte coopération entre les nœuds capteurs. Pour ces raisons nous avons proposé dans le même contexte une approche distribuée pour la surveillance et le contrôle de topologie d’un RCSF à travers une architecture multi-agent simple. L'objectif principal est d'avoir un réseau tolérant aux pannes et d'étendre sa durée de vie.

Le principe proposé consiste à contrôler la topologie du réseau localement, c'est-à-dire à travers des traitements distribués sur les nœuds en coopération avec leurs voisins. Les nœuds sont chargés de calculer à tout moment une métrique que nous avons appelée degré de tolérance. Ce degré est le principal facteur sur lequel se base le choix du parent de n’importe quel nœud quand il veut transmettre des paquets vers le Sink. Pour le calcul de ce degré, nous avons proposé d’utiliser l’état de la batterie, c'est-à-dire l’énergie du nœud, la qualité des liens et le nombre de sauts vers la station de base. L'implémentation de notre proposition a montré la pertinence de l’exploitation du principe multi-agent qui est bien adapté au fonctionnement distribué et coopératif comme il permet d’avoir un réseau évolutif avec un comportement dynamique selon les besoins.

En termes de simulation, des difficultés ont été rencontrées pour choisir une plateforme de test malgré le nombre important des simulateurs disponibles dans le domaine des RCSF. Cette difficulté est due à la nature de la problématique qui consiste à optimiser le fonctionnement d’un système réduit en termes de ressources en utilisant une technologie agent. Généralement, les simulateurs s’intéressent à l’évaluation des protocoles au sens d’énergie, latence, congestion etc. L’implémentation d’un système multi-agent dédié à un réseau de capteurs nécessite une vraie plateforme qui prend en charge les caractéristiques des deux types de systèmes qui sont le réseau de capteur et le système multi-agent lui-même. Pour ce but, nous avons adapté la


111

conception de notre solution à la méthodologie exigée en choisissant la plateforme MAPS.

Les résultats obtenus par simulation montrent que le degré de tolérance utilisé joue le rôle de régulateur et permet d’équilibrer les charges entre un ensemble de nœuds à travers une topologie basée sur un arbre qui devient tolérante aux pannes et à la congestion. En plus l’utilisation d’un système multi-agent pour l’implémentation de cette proposition est justifiée par le principe coopératif et émergent de la proposition. Ces résultats nous encouragent à orienter nos travaux de recherches futurs en favorisant l’aspect distribué dans un réseau de capteurs sans fil. Enfin, la conception des systèmes distribués facilite la tâche au concepteur et rend les traitements plus simples.

Perspectives futures

Dans cette thèse, nous avons essayé d’exploiter les avantages offerts par les systèmes multi-agents dans le domaine des réseaux de capteurs sans fil qui sont deux technologies qui peuvent être considérées comme complémentaires. En effet, les SMA permettent de concevoir des systèmes émergents et coopératifs, chose qui caractérise le fonctionnement des RCSF mais avec des ressources limitées imposant des contraintes multiples. Cette expérience ouvre plusieurs perspectives pour les travaux futures dans ce domaine. Ces perspectives concernent l’algorithme lui-même, l’architecture multi-agent et sa réalisation.

• Optimisation de l’algorithme: Les performances de notre algorithme peuvent être renforcées sur les axes suivants :

- Proposer une formule qui utilise d'autres paramètres réseau afin de calculer le degré de tolérance avec étude de l’importance donnée à chaque paramètre.

- Utiliser un principe probabiliste pour prédire les activités d'un nœud capteur notamment celles relatives au trafic des paquets.

- La prise en considération de la redondance des nœuds semble intéressante afin de minimiser les interférences et augmenter par conséquent la qualité des liens.

• L’architecture multi-agent : L’architecture multi-agent proposée comporte un seul agent. Elle peut être restructurée pour permettre plus de dynamique et paramétrage comme par exemple :

- La décomposition en plusieurs agents d’initialisation, de contrôle, etc. - Associer le protocole proposé à une application de réseau de capteurs qui est

elle aussi basée sur un SMA. - Ajouter un mécanisme de sécurité comme la signature des agents ou

carrément utiliser des agents de détection de comportement malveillant ou des mesures de confiance.

- Etudier d’autres plateformes multi-agents pour permettre l’implémentation sur d’autres types de capteur.

Enfin, et dans un environnement aujourd’hui dominé par l’internet of things et les SmArtgrids dans les villes intelligentes, les capteurs sont appelés à devenir de plus en plus « intelligents ». Nous pensons que les SMA est l’une des pistes pour y arriver.

Références bibliographiques

112


1. [ABD-06]: M.Achir, F.Benbadis, M.Dias de Amorim, "Architecture ambiante de réseaux de capteurs pour la sécurisation des travailleurs en zone portuaire", Journées scientifiques et techniques du CETMEF, Paris, 5-7 décembre 2006.

2. [AIE-09] : F. Aiello, G Fortino, R. Gravina, A. Guerrieri, "MAPS: a Mobile Agent Platform for Java Sun SPOTs, " In Proceedings of the 3rd International Workshop on Agent Technology for Sensor Networks (ATSN-09), jointly held with the 8th International Joint Conference on Autonomous Agents and Multi-agent Systems (AAMAS-09), 12th May, Budapest, Hungary, 2009.

3. [AKY-02] : I.F. Akyildiz, W. Su, Y. Sankarasubramaniam and E. Cayirci, «Wireless sensor networks: a survey», Computer Networks, Vol 38, 2002, Pp. 393–422.

4. [ALI-12] : Z. ALIOUAT et M. ALIOUAT, « Gestion Efficace du Budget Energétique dans le Protocole PEGASIS», On proceedings of the IEEE Conference on Sciences of Electronics, Technologies of Information and Telecommunications. Sousse, Tunisia, 2012.

5. [ALKA-04]: Jamal N. Al-Karaki et Ahmed E. Kamal, "Routing techniques in wireless sensor networks: a survey" - IEEE Wireless Communications, Vol 11, Issue 6, 2004, Pp. 6-28.

6. [AND-08]: V. András, R. Hornig, "An overview of the Omnet++ simulation environment", Proceedings of the 1st International Conference on Simulation Tools and Techniques for Communications, Networks and Systems Workshop, Marseille, France, 2008.

7. [ANDR-08] : M. Andreas, M. Motani, H. Siquan, and S. Künzli "DiMo: Distributed Node Monitoring in Wireless Sensor Networks", In Proceedings of International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems, Vancouver, 2008.

8. [ARS-11] : M. Arslan and A. Gordon-Ross "Markov Modeling of Fault-Tolerant Wireless Sensor Networks", Proceedings of 20th International Conference on Computer Communications and Networks (ICCCN), Maui HI, July 31 Aug. 4 2011.

9. [ASC-01]: I.F. Akyildiz, W.Su, Y. Sankarasubramaniam, E. Cayirci, " Wireless sensor networks: a survey" - Broadband and Wireless Networking Laboratory, School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta, USA, December 2001.

10. [BAAR-06] : G. barrenetxea, "Distributed routing algorithms for sensor networks" - Ecole polytechnique fédérale de Lausanne - 2006.

11. [BAH-14] : J. Bahi, M. Haddad, M. Hakem and H. Kheddouci, "Efficient distributed lifetime optimization algorithm for sensor networks ", Ad Hoc Networks Vol 16, 2014, Pages : 1–12.

12. [BAS-01]: P. Basu, N. Khan, and T. Little, "A mobility Based Metric for Clustering in Mobile and Ad Hoc Networks", In Proceedings of International Conference of Distributed Computing Systems Workshop (ICDCSW’01), Phoenix, Arizona, USA, April 2001.

13. [BEC-09] : R. Bechar, "Théorie de la redondance pour la reconfiguration des systèmes - Application aux réseaux de capteurs sans fil" Mémoire de magister en informatique dirigé par H. Haffaf et B. Kechar, Université de Mostaganem 2009.

14. [BEC-14] : R. Bechar and H. Haffaf, "Distributed Monitoring for Wireless Sensor Networks: a Multi-Agent Approach", International Journal of Computer Network and Information Security, Vol. 6, No. 10, Sept 2014, Pages : 13-23.


113

15. [BEL-10] : T. Beluch, D. Dragomirescu, F. Perget and R. Plana, "Cross-Layered Synchronization Protocol for Wireless Sensor Networks", In Proceedings of the Ninth International Conference on Networks(ICN), Menuires, France, 11–16 April 2010.

16. [BENH-07] : K. Benahmed, "Approche thérie des graphes pour la surveillance des RCSF", Mémoire de Magister en informatique à l’niversité d’Oran Es-senia, Fevrier 2007.

17. [BOI-96] : O. Boissier, and Y. Demazeau, "Asic: An architecture for social and individual control and its application to computer vision”, 6th European Workshop on Modelling Autonomous Agents, Denmark, 1996.

18. [BUC-14] : D. Bucur, G. Iacca, G. Squillero and, A. Tonda, "The impact of topology on energy consumption for collection tree protocols: An experimental assessment through evolutionary computation ", Applied Soft Computing Vol 16, 2014, pp. 210–222.

19. [CAL-97] : S. Calderoni, R. Courdier, S. Leman and P. Marcenac, "Construction expérimentale d’un modèle multi-agents", 5èmes Journées Francophones sur l’Intelligence Artificielle Distribuée et les Systèmes Multi-Agents, Hermès Science, Nice, Avril, 1997.

20. [CAR-02] : M. CARDEI, D. MACCALLUM, X. CHENG, " Wireless sensor networks with energy efficient organization ", Interconnection networks, vol. 3, no 3-4, dec 2002, pp. 213–229.

21. [CAW-05]: M. Cardei and J. Wu, "Coverage in Wireless Sensor Networks"- In Handbook of Sensor Networks, CRC Press, 2005.

22. [CEL-10] : F. Celik, A. Zengin, and S.Tuncel, "A survey on swarm intelligence based routing protocols in wireless sensor networks", International Journal of the Physical Sciences, vol. 5, no. 14, 2010, Pp. 2118-2126.

23. [CHA-02]: M. Chatterjee, S. K. Das, and D. Turgut "WCA : A weighted clustering algorithm for mobile ad hoc networks", Journal of Cluster Computing (Special Issue on Mobile Ad hoc Networks), vol.5, no.2, April 2002, pp.193-204.

24. [CHE-04] : W.P. Chen, J. Hou, L. Sha, "Dynamic clustering for acoustic target tracking in wireless sensor networks". IEEE Transactions on Mobile Computing, Vol 3, Issue 3, July 2004, Pp. 258–271.

25. [CHEN-09] : K.H. Chen, J.M. Huang and C.C. Hsiao, "CHIRON: An Energy-Efficient Chain-Based Hierarchical Routing Protocol in Wireless Sensor Networks". In Proceedings of the Wireless Telecommunications Symposium, Prague, Czech, 22–24 April 2009, pp. 1–5.

26. [CHEN-12] : B.C. Cheng, G.T. Liao, R.Y. Tseng and P. H. Hai, "Network lifetime bounds for hierarchical wireless sensor networks in the presence of energy constraints," Journal of Computer Networks, Vol 56, 2012, pp. 820-831.

27. [CIS-12] : P. C. Cisse, "Optimisation centralisée et distribuée de la durée de vie des réseaux de capteurs sans fil", DEA en informatique, Université Gaston Berger de Saint-Louis, 2012.

28. [CLA-05] : F. Claerhout, "Suivi de cible dans un réseau de capteurs", Etude bibliographique de Master recherche en informatique - IRISA / INRIA Rennes 2005.

29. [COHU-06]: C. Johnen and L. H. Nguyen, "Self-Stabilizing weight-based Clustering Algorithm for Ad hoc sensor Networks", in Proceedings of Proceedings of the Second international conference on Algorithmic Aspects of Wireless Sensor Networks, Berlin 2006, pp. 83-94.

30. [DAN-05] : N. Daniel, R. Wolski and J. Brevik, "Model-based checkpoint scheduling for volatile resource environments", in Proceedings of Cluster 2005, September 2005.


114

31. [DAR-11]: B. Dario, M. Scarpa, A.a Bobbio, D. Cerotti and M. Gribaudo "Markovian agent modeling swarm intelligence algorithms in wireless sensor networks", Performance Evaluation, Vol 69, Issues 3, 2011, pp. 135-149.

32. [DAR-12] : B. Dario, Salvatore D., F. Longo, A. Puliafito and M. Scarpa "Evaluating wireless sensor node longevity through Markovian techniques," Journal of Computer Networks, Vol 56, 2012, pp. 521-532.

33. [DEG-14] : G. Degirmenci, J. P. Kharoufeh and O. A. Prokopyev, "Maximizing the lifetime of querybased wireless sensor networks". ACM Transactions on Sensor Networks, Vol. 10, Issue 4, June 2014.

34. [DEM-96] : Y. Demazeau, and A. R. Costa, "Populations and organisations in open multi-agent systems". In Proceedings of the 1st Symposium on Parallel and Distributed AI, Hyderabad, India, 1996.

35. [DES-93] : F. Desbrandes, S. Bertolotti and L. Dunand , "Opnet 2.4 : An environment for communication network modeling and simulation", In Proceedings of European Simulation Symposium. Society for Computer Simulation, 1993.

36. [DON-06] : S.L. Dong and X. Tao, "Cluster-Based Power Efficient Time Synchronization in Wireless Sensor Networks", In Proceedings of the IEEE International Conference on Electro/information Technology, East Lansing, MI, USA, 7–10 May 2006; pp. 147–151.

37. [DRO-93] : A. Drogoul, "De la Simulation Multi-agents à la Résolution Collective de Problèmes", Thèse de doctorat en informatque, Université Paris VI, 1993.

38. [FAB-06]: V. Fabrice, "Auto-organisation dans les réseaux ad hoc et les réseaux de capteurs", INSA de Lyon, Décembre 2006.

39. [FAR-09] : H. Fariborzi and M. Moghavvemi, "EAMTR: Energy aware multi-tree routing for wireless sensor networks". Journal of Communications IET, Vol 3, 2009, pp. 733–739.

40. [FER-95] : J. Ferber, "Les Systèmes Multi-Agents : vers une intelligence collective", InterEditions 1995.

41. [FMJ-06] : T. François, O.K. Marc and J. Charles Fabre, "Intergiciels pour la tolérance aux fautes Etat de l'art et défis" RSTI série TSI. Vol 25, Issue 5, 2006.

42. [FOK-09] : C.L Fok, G.C Roman and C. Lu, "Agilla: A mobile agent middleware for self-adaptive wireless sensor networks", ACM Transactions on Autonomous and Adaptive Systems (TAAS), Vol 4 Issue 3, July 2009.

43. [FOR-12] : G. Fortino, S. Galzarano, R. Gravina and A. Guerrieri, "Agent-based Development of Wireless Sensor Network Applications", DEIS University of Calabria, supported by CONET, the Cooperating Objects Network of Excellence, funded by the European Commission, 2012.

44. [FUN-08] : K.W. Fan, S. Liu and P. Sinha, "Dynamic forwarding over tree-on-DAG for scalable data aggregation in sensor networks". IEEE Transactions on Mobile Computing, Vol. 7, Issue 10, pp. 1271–1284.

45. [GAL-08] : A. Gallais, J. Carle, D. Simplot-ryl and I. Stojmenovic, "Localized sensor area coverage with low communication overhead", IEEE Transactions on Mobile Computing, Vol. 7, Issue 5, 2008, pp. 661–672.

46. [GAN-03] : L. Gan, J. Liu, and X. Jin, "Agent-Based Energy Efficient Routing in Sensor Networks", In Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems, EEE Computer Society Washington, DC, USA, 2004.


115

47. [GIR-13] : P. Gireesan Namboothiri and M. Krishna Sivalingam, "Throughput analysis of multiple channel based wireless sensor networks ", Wireless Networks, Vol 19 , 2013, pp. 461–476.

48. [GON-06] S. Gonzales, S. Vuong, and L. C. M. Leung, "A mobile code platform for distributed task control in wireless sensor networks", In ACM Workshop on Data Engineering for Wireless and Mobile Access, Chicago, June 2006, pp. 83-86.

49. [GUO-11]: W. Guo, N. Xiong, H. C. Chao, S. Hussain and G. Chen, "Design and Analysis of Self-Adapted Task Scheduling Strategies in Wireless Sensor Networks", Journal of Sensors, Vol. 11, 2011, pp. 6533-6554.

50. [HAF-14] : H. Haffaf, R. Bechar and C. Pham, "Multi-agent Topology Approach for Distributed Monitoring in Wireless Sensor Networks" , In Proceedings of The Tenth International Conference on Wireless and Mobile Communications, Seville, Spain, June 22-26, 2014.

51. [HAI-14]: S. Haidar, W. El-Hajj and H. Zoubian, "A robust topology control solution for the sink placement problem in WSNs ", Journal of Network and Computer Applications, Vol. 39, 2014, pp.70–82.

52. [HAM-07] : A. HAMZI, "Plateforme pour l’aide à la conception et à la simulation des réseaux de capteurs sans fil", Mémoire de magister en informatique, Institut National de formation en Informatique d’Alger, 2007.

53. [HAM-13] : S. Hamedheidari and R. Rafeh, "A novel agent-based approach to detect sinkhole attacks in wireless sensor networks ", Computers & Security , Vol. 37, 2013, pp. 1-14.

54. [HAUS-05]: M. Hauspie, "Contributions à l'étude des gestionnaires de services distribués dans les réseaux ad hoc", Thèse de doctorat en informatique à l'Université des Sciences et Technologies de Lille, France - 2005.

55. [HE-08] : L.M. He, "Time Synchronization Based on Spanning Tree for Wireless Sensor Networks". In Proceedings of the 4th International Conference on Wireless Communications, Networking and Mobile Computing, Dalian, China, 12–14 October 2008.

56. [HEI-00]: W.R. Heinzelman, A. Chandrakasan, and H. Balakrishnan, "Energy-Efficient Communication Protocol for Wireless Micro Sensor Networks" In proceedings of the IEEE Proceedings of the Hawaii International Conference on System Sciences HICSS ’00, 2000.

57. [HEI-99] : W.R. Heinzelman, J. Kulik and H. Balakrishnan, "Adaptive Protocols for Information Dissemination in Wireless Sensor Networks". In Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, Washington, DC, USA, 15–19 August 1999; pp. 174–185.

58. [HEN-14] : B.N. José Henrique, D.R. Antoniel, André R.C. and C.J. Joaquim, "MH-LEACH: A Distributed Algorithm for Multi-Hop Communication in Wireless Sensor Networks", In proceedings of the Thirteenth International Conference on Network, Nice, France 2014.

59. [HERB-07]: D. Herbert, V. Sundaram, Y. Hsiang Lu, S. Bagchi, and Z. Li, "Adaptive Correctness Monitoring for Wireless Sensor Networks Using Hierarchical Distributed Run-Time Invariant checking", ACM Transactions on Autonomous and Adaptive Systems Vol. 2, no. 3, article 8, September 2007.

60. [HMS-02]: A. Howard, M. Mataric and G.S. Sukhatme, "An Incremental Self-Deployment Algorithm for Mobile Sensor Networks", Journal of Autonomous Robots, Vol. 13, Issue 2, September 2002, pp. 113 – 126.


116

61. [HOA-12] : T.H. Hoang, "Un modèle multi-agent récursif générique pour simplifier la supervision de systèmes complexes artificiels décentralisés ", Thèse de doctorat en informatique, Université de Grenoble, 2012.

62. [HUA-09]: H. Huang, W. Ru-chuan, S. Li-juan, W. Hai-yuan and X. Fu, "Research on tasks schedule and data transmission of video sensor networks based on intelligent agents and intelligent algorithms", The Journal of China Universities of Posts and Telecommunications , Vol. 16, Issue 6, December 2009, pp. 84–91.

63. [HUAN-09] : Y. Huang, W. He and K. Nahrstedt, "ChainFarm: A Novel Authentication Protocol for High-rate Any Source Probabilistic Broadcast", In Proceedings of the IEEE 6th International Conference on Mobile Adhoc and Sensor Systems, Macau, 12–15 October 2009; pp. 264–273.

64. [HUS-06]: S. Hussain, E. Shakshuki and A.W. Matin, "Agent-based system architecture for wireless sensor networks". In Proceedings of The 20th International Conference on Advanced Information Networking and Applications Vienna University of Technology, Vienna, Austria 2006, pp. 18-20.

65. [HUS-07] : S. Hussain and O. Islam, "An Energy Efficient Spanning Tree Based Multi-Hop Routing in Wireless Sensor Networks". In Proceedings of the Wireless Communications and Networking Conference, Hong Kong, 11–15 March 2007, pp. 4383–4388.

66. [INT-02] : C. Intanagonwiwat, "Directed Diffusion: An Application-Specific and Data-Centric Communication Paradigm for Wireless Sensor Networks", Ph.D. Thesis, University of Southern California, Los Angeles, CA, USA, 2002.

67. [JAB-08] : N. Jabeur and P.A. Graniero, "Agent-Based Clusters to Virtually Manage Spatially Distributed Sensors", Proceedings of the 9th International Conference on Geo Computation National Centre for Geocomputation, National University of Ireland, Maynooth, 2008.

68. [JAM-05]: J. P. Jamont, "Diamond: une approche pour la conception de systèmes multi-agents embarqués ", Thèse de doctorat en informatique, Laboratoire de conception et d’intégration des systèmes, Institut National Polytechnique de Grenoble, 2005.

69. [JAM-06] : J.P. Jamont, "MWAC: Multi-Wireless-Agent Communication", Technique et science informatiques, Série TSI. Vol. 25, Issue 5, 2006, pp. 661- 688.

70. [JAM-11] : J.P. Jamont, L. Vercouter and A. Balanela, "Mécanismes légers de gestion de la confiance pour des réseaux de capteurs sans fil", Journées Francophones sur les Systèmes Multi-Agents, Valenciennes : France, 16 Novembre 2011.

71. [JAN-96] : D. Janakiram, T. H. Sreenivas and and K.G. Subramaniam, "Parallel simulated annealing algorithms ", journal of Parallel and Distributed Computing, Vol.37, 1996, pp. 207–212.

72. [JIE-01] : W. Jie, G. Ming, and I. Stojmenovic, "On calculating power-aware connected dominating sets for efficient routing in ad hoc wireless Networks", In Proceedings of the International Conference on Parallel Processing, Valencia, Spain, Sept 2001.

73. [JUN-09] : W.S. Jung, K.W. Lim, Y.B. Ko and S.J. Park, "A Hybrid Approach for Clustering-Based Data Aggregation inWireless Sensor Networks", In Proceedings of the Third International Conference on Digital Society, Cancun, Mexico, 1–7 February 2009, pp. 112–117.

74. [KAC-09] : R. Kacimi, "Techniques de conservation d'énergie pour les réseaux de capteurs sans fil", Thèse de doctorat en informatique, Institut National Polytechnique de Toulouse, Juillet 2009.


117

75. [KAI-07] : F. Kai-Wei, S. Liu and P. Sinha, "Structure-free data aggregation in sensor networks", IEEE Transactions on Mobile Computing, Vol. 6, Issue 8, 2007, pp. 929–942.

76. [KAN-04] P. Kang, C. Borcea, G. Xu, A. Saxena, U. Kremer, and L. Iftode, "Smart messages: a distributed computing platform for networks of embedded systems", The Computer Journal, Special Focus-Mobile and Pervasive Computing, Vol. 47, Issue 4, 2004, pp. 475-494.

77. [KAN-07] : H. Kang, X. Li, P. Moran, "Power-Aware Markov Chain Based Tracking Approach for Wireless Sensor Networks", In Proceedings of the IEEE Wireless Communications and Networking Conference, Hong Kong, 11–15 March 2007, pp. 4209–4214.

78. [KAR-04] : J. Al-Karaki, A. Kamal, "Routing techniques in wireless sensor networks: A survey", IEEE Wireless Communications, Vol. 11, Issue 6, 2004, pp. 6–28.

79. [KAR-04-a]: J. Al-Karaki, R. Mustafa, and A.E. Kamal, "Data Aggregation in Wireless Sensor Networks - Exact and Approximate Algorithms", In Proceedings of IEEE Workshop on High Performance Switching and Routing, Arizona, USA, April 2004, pp.241-245.

80. [KAR-04-b]: J. Al-Karaki and A.E. Kamal, "On the Correlated Data Gathering Problem in Wireless Sensor Networks”, In Proceedings of The Ninth IEEE Symposium on Computers and Communications, Vol.1, Alexandria, Egypt, July 2004, pp.226-231.

81. [KAR-13] : E. Karasabun, I. Korpeoglu and C. Aykanat, "Active node determination for correlated data gathering in wireless sensor networks", Computer Networks, Vol. 57, Issue 5, April 2013, pp. 1124-1138.

82. [KAY-11]: S. Kay, H.L. Kincho and M. König, “Resource-Efficient Wireless Monitoring based on Mobile Agent Migration", In Proceedings of International Conference on Health Monitoring of Structural and Biological Systems, San Diego, California, USA, March 06, 2011.

83. [KEMP-04]: Tatiana KEMPOWSKY - "Surveillance de procédés à base de méthode de classification: conception d'un outil d'aide pour la détection et le diagnostic des défaillances" - Thèse de doctorat / laboratoire CNRS de l'institut national de Toulouse 2004.

84. [KRI-02] : B. Krishnamachari, D. Estrin, and S. B. Wicker, "The impact of data aggregation in wireless sensor networks", In Proceedings of the 22nd International Conference on Distributed Computing Systems, IEEE Computer Society, 2002, pp. 575–578.

85. [KET-05] : M. Ketel, N.S. Dogan and H. Abdollah, "Distributed Sensor Networks based on Mobile Agents Paradigm", In Proceedings of the Thirty-Seventh Southeastern Symposium on System Theory, 2005, pp. 411 - 414.

86. [KHAN-08] : S. Khan, E.N.Huh and I.Rao, "Reliable Data Dissemination with Diversity Multi-Hop Protocol for Wireless Sensors Network", In Proceedings of the 10th International Conference on Advanced Communication Technology, Gangwon-Do, South Korea, 17–20 February 2008, pp. 9–13.

87. [KIM-03]: J. Kim, J. In, S. Hong, B. Kim, H. Lee, and D. Eom, "An Efficient Agent-based Routing Algorithm For Multiple Mobile Sinks in Wireless Sensor Networks", Department of Electronics and Computer Engineering, Korea University Research Center, Korea, 2003.

88. [KUO-09] : C. Kuong-Ho, J.M. Huang and C.C. Hsiao, "CHIRON: An energy-efficient chain-based hierarchical routing protocol in wireless sensor networks", In Proceedings of the 2009 Conference on Wireless Telecommunications Symposium, IEEE Press Piscataway, NJ, USA 2009, pp. 183-187.


118

89. [KWO-06]: Y.M. Kwon, S. Sundresh, K. Mechitov and G. Agha, "ActorNet: an actor platform for wireless sensor networks", In Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems AMAS '06, New York, USA 2006.

90. [LAA-86] : P.J. Laarhoven and E.H. Aarts, "Simulated Annealing: Theory and Applications", Kluwer Academic Publishers 1986.

91. [LEE-06] : S.B. Lee, K.J. Kwak and A. Campbell, "Solicitation-Based Forwarding for Sensor Networks", In Proceedings of the 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston VA, USA, 28 Sept 2006, pp. 90–99.

92. [LEV-90]: J. Hector Levesque, R. Philip Cohen, H. T. José, "On Acting Together", In Proceedings of Eighth National Conference on Artificial Intelligence, Boston 1990.

93. [LI-01] : L. Li and J. Y. Halpern, "Minimum-energy mobile wireless networks revisited", In IEEE International Conference on Communications, 2001, pp. 278–283.

94. [LI-13] : M. Li, Z. Li and V. Athanasios, "A Survey on Topology Control in Wireless Sensor Networks: Taxonomy, Comparative Study, and Open Issues", In Proceedings of the IEEE, Vol. 101, Issue 12, December 2013, pp. 2538 - 2557.

95. [LIN-97]: C.R. Lin and M. Gerla, "Adaptive clustering for mobile wireless networks", IEEE Journal of Selected Areas in Communications, Vol.15, Issue7, September 1997, pp.1265-1275.

96. [LIU-03]: Z. Liu, Y. Wang, "A Secure Agent Architecture for Sensor Networks", In Proceedings of the International Conference on Artificial Intelligence, June 23 - 26, 2003, Las Vegas, Nevada, USA, 2003.

97. [MAK-08] : Abdallah Makhoul, "Réseaux de capteurs : localisation, couverture et fusion de données. Thèse de doctorat en informatique, Laboratoire d'Informatique de l'Université de Franche-Comté, Ecole Doctorale Sciences Pour l'Ingénieur et Microtechniques, November 2008.

98. [MAS-05] : D. Massaguer, "Multi Mobile Agent Deployment in Wireless Sensor Networks », Thesis Master of science in Electrical and Computer Engineering, University of California, Irvine, 2005.

99. [MAT-09]: D.C. Matthew, D. Azzi, P.H. Barry and A. Hewitt, "A Bayesian network approach to a biologically inspired motion strategy for mobile wireless sensor networks", Ad Hoc Networks, Vol. 7, 2009, pp. 1217-1228.

100. [MEG-07]: B. Mathieu, E. Erwan and P. Guy, "Performances d'une méthode de localisation dans les réseaux sans fil mobiles", DIR 2007, Marne la Vallée, France, 2007, pp. 1-7.

101. [MEK-06] : S. Mekid, "Further Structural Intelligence for Sensors Cluster Technology in Manufacturing ", Journal of Sensors, Vol. 6, 2006, pp.557-577.

102. [MER-03]: R. Meraihi, "Gestion de la qualité de service et contrôle de topologie dans les réseaux ad hoc", Thèse de doctorat de l'Ecole nationale supérieure des télécommunications de Paris 2003.

103. [MER-05] M. Mertsock and D. Stawski, "Wireless Sensor Nodes as Intelligent Agents: Using Expert Systems with Directed Diffusion", Rochester, Institute of Technology, November 10, 2005.


119

104. [MIN-11]: L. Min, S. Xu, S. Sun, "An agent-assisted QoS-based routing algorithm forwireless sensor networks", Journal of Network and Computer Application, Vol. 35, Issue 1, January 2012, pp. 29–36.

105. [MITT-06]: N. Mitton, "Auto-organisation des réseaux sans fil multi sauts à grande échelle", Thèse de doctorat en informatique, INSA de Lyon 2006.

106. [MOH-14] : Y. Mohamed, I.F. Senturk, K. Akkaya, S. Lee and F. Senel, "Topology management techniques for tolerating node failures in wireless sensor networks: A survey", Computer Networks, Vol. 58, 2014, pp. 254–283.

107. [MUR-12] : A. Murtala Zungeru, L. Minnang and K. Seng, "Termite-hill: Performance optimized swarm intelligence based routing algorithm for wireless sensor networks", Journal of Network and Computer Applications, Vol. 35, 2012, pp.1901–1917.

108. [MUQ-04] : A. Muqattash and M. Krunz, "A single-channel solution for transmission power control in wireless ad hoc networks". In Proceedings of the 5th ACM International Symposium on Mobile Ad Hoc Networking and Computing, ACM, 2004, pp. 210–221.

109. [NAH-06] : T. Nahdia, Q.E.K. Mamun and Y. Urano, "COSEN: A Chain Oriented Sensor Network for Efficient Data Collection", In Proceedings of the Third International Conference on Information Technology: New Generations, IEEE Computer Society Washington, DC, USA 2006, pp. 262-267.

110. [NARV-07] : C.V.I. Narvaez, "Diagnostic par techniques d'apprentissage floues : Conception d'une méthode de validation et d'optimisation des partitions", Thèse de doctorat en informatique à l'université de Toulouse CNRS 2007.

111. [OCC-98]: M. Occello, and Y. Demazeau, " Modelling decision making systems using agents for cooperation in a real time constraints". In Proceedings of 3rd IFAC Symposium on Intelligent Autonomous Vehicles, Vol. 1, Madrid, Spain, 1998, pp. 51–56.

112. [OLU-07] : E. Olule, G. Wang, M. Guo, M. Dong, "RARE: An Energy-Efficient Target Tracking Protocol for Wireless Sensor Networks", In Proceedings of the International Conference on Parallel Processing Workshops, Xian, China, 10–14 September 2007.

113. [OMP-09] : G. Omprakash, F. Rodrigo, J. Kyle, M. David, and L. Philip, "Collection Tree Protocol", In proceedings of the 7th ACM Conference on embedded networked sensor systems, Berkeley, CA, USA, Nov. 2009, pp. 1-14.

114. [PAO-09] : C. Paolo, M. Cesana, S. Brambilla and L. Casartelli, "A Cooperative Approach for Topology Control in Wireless Sensor Networks", Pervasive and Mobile Computing, Vol. 5, Issue 5, October 2009, pp. 526–541.

115. [PAR-13] : B. Parul, S. Meht, " K-LEACH: An improved LEACH Protocol for Lifetime Improvement in WSN", International Journal of Engineering Trends and Technology (IJETT) Vol. 4 Issue 5, May 2013.

116. [PATT-97]: R.J. Patton, "Fault-tolerant control systems: the 1997 situation", in IFAC Symposium on Fault Detection Supervision and Safety for Technical Processes 1997.

117. [PHAM-07]: C. Pham, "Contrôle de la congestion dans les réseaux de capteurs", UFR Sciences et Techniques Université de Pau et des Pays de l'Adour, 2007.

118. [PIC-04] : G. Picard and M.P. Gleizes, "The ADELFE Methodology - Designing Adaptive Cooperative Multi-Agent Systems", Methodologies and Software Engineering for Agent Systems. The Agent-Oriented Software Engineering handbook, Kluwer Publishing, 2004, pp. 157-176.

119. [PRA-07]: K. Pratik Biswas, Q. Hairong, X. Yingyue, "Mobile-agent-based collaborative sensor fusion", Information Fusion , Vol.9, 2007, pp. 399–411.


120

120. [PRA-14] : K. Pratyay and J. Prasanta, "Energy efficient clustering and routing algorithms for wireless sensor networks: Particle swarm optimization approach", Engineering Applications of Artificial Intelligence, Vol. 33, 2014, pp.127–140.

121. [QI-03] : H. Qi, Y. Xu, X. Wang, "Mobile-Agent-Based Collaborative Signal and Information Processing in Sensor Networks", In Proceedings of the IEEE, Vol. 91 , Issue 8, 2003, pp. 1172 - 1183.

122. [QUA-12] : M. Quazi, "A Qualitative Comparison of Different Logical Topologies for Wireless Sensor Networks", journal of Sensors, Vol. 12, 2012, pp. 14887-14913.

123. [RACO-06] : D. Racoceanu, "Contribution à la surveillance des Systèmes de Production en utilisant les Techniques de l'Intelligence Artificielle" HDR au Laboratoire d'automatique de Besançon, 2006.

124. [RAM-14] : H.S. Ramos, A.C. Frery, A.Boukerche, E.M.R. Oliveira, and A.A.F. Loureiro, "Topology-related metrics and applications for the design and operation of wireless sensor networks ", ACM Transactions on Sensor Networks, Volume 10 Issue 3, April 2014.

125. [RAO-95]: Rao, A. and Georgeff, M. (1995). Bdi agents: from theory to practice. In conference of 1st International Conference on Multi-Agent Systems ICMAS, pages 312–319. AAAI Press.

126. [RAU-14] : T. Rault, A. Bouabdallah and Y. Challal, "Energy efficiency in wireless sensor networks: A top-down survey ", Computer Networks, Vol. 67, 2014, pp. 104–122.

127. [ROD-94] : M. Rodriguez, "Modélisation d’un agent autonome: Approche constructiviste de l’architecture de contrôle et de la représentation de connaissances", Thèse de doctorat en informatique, Université de Neufchâtel, Suisse, 1994.

128. [ROM-11] : R. Romadi, H. Berbia and B. Bounabat, "Wireless Sensor Network Simulation Of The Energy Consumption By A Multi Agents System” Journal of Theorical and Applied Information Technology, Vol. 25, Issue 1, 2011.

129. [RSM-01]: E.M. Royer, P.M.M.Smithy and L.E. Mosery, "An Analysis of the Optimum Node Density for Ad hoc Mobile Networks", University of California, Publication IEEE, Vol. 3 Year 2001, pp. 857-861.

130. [SAA-10]: V. Saamaja, K.K. Rachuri, C.S. Ram Murthy, "Using mobile data collectors to improve network lifetime of wireless sensor networks with reliability constraints", Journal of Parallel and Distributed Computing, Vol. 70, Issue 7, July 2010, pp. 767–778.

131. [SAF-12] : A. Safdar, B. Daachi and K. Djouani, "Application of fuzzy inference systems to detection of faults in wireless sensor networks", Journal of Neurocomputing, Vol. 94, 2012, pp. 111-120.

132. [SAM-08]: L. SAMPER, "Modélisations et Analyses de Réseaux de Capteurs", Thèse de doctorat dans le cadre de l'Ecole doctorale " mathématiques, sciences et technologies de l'information, informatique ", institut national polytechnique de Grenoble, Soutenue en Avril 2008.

133. [SAN-05] : P. Santi, "Topology Control in Wireless Ad Hoc and Sensor Networks", chapter 9 "Distributed Topology Control: Design Guidelines", John Wiley and Sons, Ltd, 2005.

134. [SEM-09] : T. Semong, S. Anokye, Q. Li and Q. Hu, "Rumor as an Energy-Balancing Multipath Routing Protocol for Wireless Sensor Networks". In Proceedings of the International Conference on New Trends in Information and Service Science, Beijing, China, 30 June–2 July 2009; pp. 754–759.

135. [SHA-05]: E. Shakshuki, S. Hussain, A.R. Matin and A.W. Matin, "Routing Agent for Wireless Sensor Networks", Jodrey School of Computer Science, Acadia University, 2005.


121

136. [SHA-08] E. Shakshuki, H. Malik, and M. K. Denko, "Software agent-based directed diffusion in wireless sensor networks", Telecommunication Systems, Vol. 38, 2008.

137. [SHA-14] : M. Shan, G. Chen, D. Luo, X. Zhu, and X. Wu, "Building maximum lifetime shortest path data aggregation trees in wireless sensor networks". ACM Transactions on Sensor Networks, Vol. 11, Issue 1, June 2014.

138. [SIA-06] : M. Z. Siam, M. Krunz, A. Muqattash, and S. Cui, "Adaptive multiantenna power control in wireless networks", In Proceedings of International Conference on Wireless Communications and Mobile Computing, New York, NY, USA, 2006, pp. 875–880.

139. [SIM-06] : D. Simon, C. Cifuentes, D. Cleal, J. Daniels and D. White, "JavaTM on the Bare Metal of Wireless Sensor Devices - The Squawk Java Virtual Machine", In the proceeding of the Second International Conference on Virtual Execution Environments VEE’06, June 14–16, Ottawa, Ontario, Canada, 2006.

140. [TAB-06] : N. Tabassum, Q. Mamun and Y. Urano, "COSEN: A Chain Oriented Sensor Network for Efficient Data Collection", In Proceedings of the Third International Conference on Information Technology: New Generations, Las Vegas, NV, USA, 10–12 April 2006; pp. 262–267.

141. [THEO-06]: F. Theoleyre, "Une auto-organisation et ses applications pour les réseaux ad hoc et hybrides", Thèse de doctorat à l'institut national des sciences appliquées de Lyon - soutenue le 29 septembre 2006.

142. [THOM-05] : W. Thomas, "Proposition et validation formelle d'un protocole MAC temps réel pour réseaux de capteurs linéaires sans fils", Mémoire de Master Recherche Informatique Spécialité Réseaux, Télécommunications et Services - l'INSA de Lyon 2005.

143. [TSA-07] : H.W. Tsai, C.P. Chu, T.S. Chen, "Mobile object tracking in wireless sensor networks", Computer Communications, Vol. 30, 2007, pp. 1811–1825.

144. [TYN-05]: R. Tynan, D. Marsh, D. O’Kane and G.M.P. O’Hare, "Intelligent Agents for Wireless Sensor Networks", In Proceedings of the Fourth International Joint Conference on Autonomous Agents and Multiagent Systems, Utrecht, Netherlands, July 25-29, 2005.

145. [VAZ-14] : A. Vázquez-Rodas and L.J. de la Cruz Llopis, "A centrality-based topology control protocol for wireless mesh networks ", Ad Hoc Networks, In press, Available online 7 August 2014.

146. [WAN-05] : K. Wang, S. Ayyash, T. Little and P. Basu, "Attribute-Based Clustering for Information Dissemination in Wireless Sensors Network", In Proceedings of the Second Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, Santa Clara, CA, USA, 26–29, Sept 2005.

147. [WAN-06]: A.Y. Wang and C.G. Sodini, "On the energy efficiency of wireless transceivers", In IEEE International Conference on Communications, Istanbul Turkish, June 2006, pp. 3783-3788.

148. [WAN-13] : X. Wang, X. Wang, G. Xing, and Y. Yao, "Minimum transmission power configuration in real-time sensor networks with overlapping channels", ACM Transactions on Sensor Networks, Vol 9, Issue 2, March 2013, pp. 10-28.

149. [WCP-04]: G.Wang, G.Cao, and T.La Porta, "Movement-Assisted Sensor Deployment", IEEE Transactions on Mobile Computing, Vol.5 , Issue 6, June 2006, pp. 640 -652.

150. [WOO-99]: M. Wooldridge, "Multiagent systems :A modern approach to Distributed Artificial Intelligence", Edited by Gerhard Weiss, 1999.


122

151. [WOO-02] : M. Wooldridge, "An Introduction to Multiagent Systems", John Wiley & Sons, LTD 2002.

152. [WOO-03]: A. Woo, T. Tong, D. Culler, "Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks", In Proceedings of the 1st International conference on Embedded Networked Sensor Systems, Los Angeles, CA, USA, 5–7 November 2003, pp. 14–27.

153. [WU-09] : F.J. Wu, Y.C. Tseng, "Distributed wake-up scheduling for data collection in tree-based wireless sensor networks", Communications Letters IEEE, Vol. 13 , Issue 11, 2009, pp. 850–852.

154. [WU-09] : H. Wu, Y. Ming Ding, Z. Zhong, "A Chain-Based Fast Data Aggregation Algorithm Based on Suppositional Cells for Wireless Sensors Network", In Proceedings of the 2nd International Conference on Power Electronics and Intelligent Transportation System, Shenzhen, China, 19–20 Dec 2009; pp. 106–109.

155. [WU-10] : X. H. Wu, S. Wang, "Performance comparison of LEACH and LEACHC protocols by NS2", In Proceedings of the 9th International Symposium on Distributed Computing and Applications to Business, Engineering and Science. Hong Kong, China, 2010, pp. 254-258.

156. [XIN-09] : G. Xing, M. Li, H. Luo and X. Jia, "Dynamic multiresolution data dissemination in wireless sensor networks." IEEE Transactions on Mobile Computing, Vol. 8, 2009, pp. 1205–1220.

157. [XU-11] : X. Xu, X.Y. Li, X. Mao, S. Tang and S. Wang, "A delay-efficient algorithm for data aggregation in multihop wireless sensor networks", IEEE Transaction on Parallel and Distributed Systems, Vol. 22, 2011, pp. 163-175.

158. [XU-07]: Y. Xue, H. Sung Lee, M. Y. Kumarawadu, P. Ghenniwa and H.H. Weiming Shen, "Performance Evaluation of NS-2 Simulator for Wireless Sensor Networks", In Proceedings of Canadian Conference on Electrical and Computer Engineering , 2007, pp. 1372-1375.

159. [Xue-07-a]: W. Xue, D. Bi, L. Ding and S. Wang, "Agent Collaborative Target Localization and Classification in Wireless Sensor Networks", Journal of Sensors, Vol 7, 2007, pp. 1359-1386.

160. [Xue-07-b]: W. Xue, D. Bi, L. Ding and S. Wang, "Multi-agent Negotiation Mechanisms for Statistical Target Classification in Wireless Multimedia Sensor Networks", Journal of Sensors, Vol 7, 2007, pp. 2201-2237.

161. [YA-01] : X. Ya, J. Heidemann, and D. Estrin, "Geography-informed energy conservation for ad hoc routing", In Proceedings of Annual International Conference on Mobile Computing and Networking, ACM New York, NY, USA, 2001, pp. 70–84.

162. [YAUN-10]: L. Yuan, X. Wang, J. Gan and Y. Zhao, "Data Gathering Algorithm Based on Mobile Agent and Emergent Event-Driven in Cluster- Based WSN", Journal of Networks, Vol. 5, Issue 10, Oct 2010, pp. 1160-1168.

163. [YE-05] : M. Ye, C Li, G. Chen, J.Wu, "EECS: An Energy Efficient Clustering Scheme in Wireless Sensor Networks", In Proceedings of the 24th IEEE International Performance, Computing, and Communications Conference, Phoenix, AZ, USA, 7–9 April 2005; pp. 535–540.

164. [YIN-12] : R. YIN, B. Liu, Y. Li and X. Hao, "Adaptively fault-tolerant topology control algorithm for wireless sensor networks", The Journal of China Universities of Posts and Telecommunications, October 2012 , Vol. 19, Issue Suppl. 2, pp. 13-18.

165. [YUA-08] : L. Yuan, Y.Zhu, T. Xu, "A Multi-Layered Energy-Efficient and Delay-Reduced Chain-Based Data Gathering Protocol for Wireless Sensor Network". In Proceedings of the


123

IEEE/ASME International Conference on Mechtronic and Embedded Systems and Applications, Beijing, China, 12–15 October 2008, pp. 13–18.

166. [ZEN-98] : X. Zeng, R. Bagrodia and M. Gerla, " GloMoSim: a library for parallel simulation of large-scale wireless networks ", In Proceedings of the Twelfth Workshop on Parallel and Distributed Simulation, PADS 98, Banff, Alta, May 1998.

167. [ZETA-04]: L. Zetao,"Contribution à l'élaboration d'algorithmes d'isolation et d'identification de défauts dans les systèmes non linéaires"- Thèse de Doctorat à l’Institut national des sciences appliquées de Toulouse, 2004.

168. [ZHA-10]: Z. Zhang, F. Yu, "Performance Analysis of Cluster-Based and Tree-Based Routing Protocols for Wireless Sensor Networks", In Proceedings of the International Conference on Communications and Mobile Computing (CMC), Shenzhen, China, 12–14 April 2010; pp. 418–422.

169. [ZHO-03] : F.Y. Zhong, G. Cheng, S. Lu et L.Zhang, "Peas : a robust energy conserving protocol for long-lived sensor networks", In Proceedings of the 23rd International Conference on Distributed Computing Systems, Providence, Rhode Island, USA, 2003, pp. 28-37.

Sites web 1. [AGB] : Agent Builder home page : http://www.agentbuilder.com, consulté le

12/06/2014.

2. [AGT] : Agent Tool home page : http ://www.agenttool.cis.ksu.edu, consulté le 12/06/2014.

3. [JAC] : Jack home page : http://www.agent-software.com.au/products/jack/, consulté le 12/06/2014.

4. [JAD] : Jade home page : http://www.jade.tilab.com, consulté le 22/05/2014.

5. [JSM] : http://j-sim.cs.uiuc.edu/, consulté le 13/07/2014.

6. [OMN] : OMNeT++ Network Simulation Framework home page http://www.omnetpp.org/

7. [CAST] : Castalia Simulator home page https://castalia.forge.nicta.com.au/index.php/en/

8. [MDK] : MadKit home page : http://www.madkit.org, consulté le 22/05/2014.

9. [NS2] :NS-2 home page : http://www.isi.edu/nsnam/ns/, consulté le 13/07/2014.

10. [QLT] : Scalable networks qualnet user manual, http://www.scalablenetworks.com/products/qualnet.php, consulté le 15/07/2014.

Annexes

A.1

Annexe A Quelques types de capteurs sans fil

1. Anatomie du capteur TelosB

Figure A.1 : Anatomie du capteur TelosB (extraite de [CIS-12])

2. Comparaison des fonctionnalités de quelques capteurs

Fonctionnalités MTS300 MTS310 MTS400 MTS420Accéléromètre X X X Lumière ambiante X X Baromètre X X Vibreur X X GPS X Champ magnétique X Micro X X Photosensible X X Photorésistant X X Humidité et température X X Thermistance X X

Tableau A.1 : Quelques capteurs et leurs fonctionnalités

Annexes

A.2

3. Caractéristiques techniques de quelques capteurs

XM2110 M2110

MPR2400 MPR400

Champ de fréquence

2.4GHz ISM Band

2.4GHz ISM Band

2.4GHz ISM Band

868-870 ; 902-928MHz

Processeur Atmel Atmel Atmel Atmel ATMega

1281 ATMega

1281ATMega

128LATMega

128L Transceiver RF230 RF230 TI TI Radio Atmel Atmel CC2420 CC1000 Atmel Atmel Atmel Atmel Serial Flash AT45DB41B AT45DB41B AT45DB41B AT45DB41B (512 kB) (512 kB) (512 kB) (512 kB)RAM 8 KBytes 8 KBytes 4 KBytes 4 KBytes

Tableau A.2 : Quelques capteurs et leurs caractéristiques techniques

4. Les capteurs Sun Spot 4.1. Structure matérielle

Figure A.2 : Composants d’un capteurs Sun Spot

Annexes

A.3

4.2. Caractéristiques techniques

Module Type et configuration

Processeur ARM920T cadencé à 180 MHz, 32 bits

Mémoire vive 512Ko

Mémoire Flash 4Mo

Interface radio "Zigbee" (basée sur le standard IEEE 802.15.4, 2.4 GHz)

Antenne Intégrée

Autres interfaces USB 6 entrées analogiques 5 broches d'entrées/sorties et 4 broches de sortie pour courant élevés

Capteurs Accéléromètre tri-dimensionnel 2G/6GCapteur thermique Capteur de lumière

LEDs 8 LED, chacune pouvant afficher 3 couleurs différentes

Alimentation Batteries rechargeable lithium-ion, 3.7V, 750 mAh (de simples batteries type R6 peuvent être utilisées)

Consommation d’énergie

30 µA en mode de sommeil prolongé (« deep sleep mode »)Gestion automatique des batteries par la couche logicielle

Spécifications logicielles

machine virtuelle Java "Squawk" qui prend en charge les fonctions de système d'exploitation

Développement Tout environnement de développement Java peut être utiliséConnexion avec ordinateur via le port USB

Compatibilité Windows XP, Mac OS X 10.4 et la plupart des distributions Linux

Tableau A.2 : Quelques caractéristiques d’un capteur de type Sun Spot

Annexes

B.1

Annexe B

Liste des acronymes utilisés

ADC Analog to Digital Converter AODV Ad hoc On Demand Distance Vector

API Application Programming Interface

ASCENT Adaptive Self-Configuring Sensor Network Topologies BDI Believe Desir Intention CDS Connected Dominating Set CTP Collection Tree Protocol CTR Critical Transmitting Range DMAC Distributed and Mobility-Adaptive Clustering algorithm DPSO Distributed Particle Swarm Optimization ECDS Energy Efficient Distributed Connecting Dominating Sets ETX Expected Transmissions FIPA Foundation for Intelligent Physical Agents GAF Geographical Adaptive Fidelity GDMAC Generalized DMAC GG Gabriel Graphe GPS Global Positioning System GUI Graphical User Interface HC Hop Count IETF Internet Engineering Task Force JADE Java Agent DEvelopement framework JAL Jack Agent Language KQML Knowledge Query and Manipulation Language LEACH Low-Energy Adaptive Clustering Hierarchy MAC Media Access Control MACR Multiagent & Cooperative Robotics MANET Mobile Ad hoc Networks MAPS Mobile Agent Platform for Sun SPOTs MH-LEACH Multihop LEACH MWAC Multi-Wireless-Agent Communication O-MaSE Organization-based Multiagent Systems Engineering OSI Open System Interconnexion PACDS Power Aware Connected Dominating Set

Annexes

B.2

PSO Particle Swarm Optimization RCSF Réseau de Capteurs Sans Fil RNG Relative Neighborhood Graph SDK Sun Spot Developement Kit SMA Système Mufti-Agent SPIN Sensor Protocols for Information via Negotiation SPOT Small Programmable Object Technology SPT Shortest Path Tree STEM Sparse Topology and Energy Management TDOA Time Difference Of Arrival TOA Time Of Arrival UDG Unit Disc Graph VGA Virtual Grid Architecture routing WSN Wireless Sensor Network

départem ent d’in formatique - univ-oran1.dz · 2015. 5. 25. · mouni m.k faf hafid am moham...

Documents