Système de supervision des réseaux de capteurs sans fil

République Algérienne Démocratique et Populaire Ministère de l’Enseignement Supérieure et de la Recherche Scientifique

Université Tahri Mohamed de Béchar

Faculté des Sciences Exactes

Département de Mathématique et Informatique

Mémoire de fin d’études

En vue de l’obtention du diplôme de Master en Informatique

Option : Systèmes Informatiques et Réseaux

THEME

Présenté par : Encadré par :

HADJADJI Samia Mr. BELAGUID M

Année universitaire 2014/2015

Système de supervision

des réseaux de capteurs sans fil

Remerciements Tout d’abord grâce à dieu le tout puissant et miséricordieux de m’avoir

donné la foi et m’avoir permis d’apprendre et à réaliser ce travail. Je tiens à remercier mes très chère parent pour le sacrifice qu’ils ont

constitué pendant la durée de mes études et qui mon fournis au quotidien soutien et une confiance sans faille et de ce fait, je ne saurais exprimer ma gratitude seulement par des mots.

Ensuite je tiens à remercier l’ensemble des enseignants auxquels nous exprimons toute notre gratitude et notre sympathie et que sans leur collaboration et soutient de ce travail n’aurait pu être réalisé.

Je remercier en particulier Mr Belaguid Mustapha pour son s’avoir et culture ainsi que la confiance qu’il à placer en moi durant toute la durée de ce travail.

Ainsi j’adresse mes remerciements les plus chaleureux à toutes les personnes qui m’ont aidé de près ou de loin par le fruit de leurs connaissances.

J’exprime également ma gratitude à tous les consultants et internautes rencontré lors de la recherche effectuée et qui ont accepté de répondre à mes questions.

Je tiens à remercier l’université TAHRI-Mohamed-Béchar qui m’a donné l’opportunité de vivre une expérience aussi enrichissante tout sur le plan humain que professionnel.

J’exprime également ma gratitude aux membres du Jurys qui m’ont honoré en acceptant de juger ce travail.

Enfin, j'adresse mes plus sincères remerciements à tous mes proches et amis, qui m'ont toujours soutenu et encouragé au cours de la réalisation de ce travail. Merci à tous et à toutes.

Dédicace

Je dédie ce travail à :

Mes enseignants du cycle primaire jusqu’au cycle universitaire dont les conseils précieux m’ont guidé ; qu’ils trouvent ici l’expression de ma reconnaissance.

En particulier, l'ensemble des enseignants de l'université TAHRI-

Mohamed de Béchar. Mes très chère parent « Bachir » et « Fadila » qui se sont dévolus pour que j’apprenne. Ce travail est le fruit de vos sacrifices que vous avez consentis pour mon éducation et ma formation. Mes deux frère « Abdlatif » et « Mounir » Mes oncles, tantes, cousin et cousine. Mes camarades et toutes Mes amies. A tous ceux ou celles qui me sont chers et que j’ai omis involontairement de citer.

La promotion MSIR-2015

Résumé

Les Réseaux de Capteurs Sans Fil (RCSFs), technologie clé du 21ème siècle, sont basés sur

des systèmes embarqués à faibles ressources et sont fortement contraints (énergie, ressources,

interférences, etc.). Leur domaine d’applications est très vaste. Une application type peut

contenir plusieurs dizaines voire plusieurs milliers de nœuds capteurs. Le but que se propose

ce projet de relever est de fournir des méthodes simples pour administrer ces réseaux et de

fournir des méthodes permettant de connaitre l’état des nœuds. Cela est réaliser à l’aide d’un

protocole inspiré du protocole SNMP, ainsi l’utilisation des méthodes de théorie des graphes

(la redondance et les points d’articulation).

Ce système a donc pour but de superviser à distance les différents éléments des réseaux de

capteurs sans fil, de permettre de visualiser et modifier leurs configurations ainsi que

d'accéder aux différentes valeurs des capteurs.

Mots clés : Réseaux de Capteurs Sans Fil, Supervision, Protocol SNMP, Théorie des

graphes, Redondance, Points d’articulation.

Summary

The Wireless Sensor Networks (WSNs), a key technology of the 21st century are based on

embedded systems with limited resources and are heavily constrained (energy, resources,

interference, etc.). Their range of applications is vast. A typical application may contain tens

to thousands of nodes sensors. The goal that this project intends to address is to provide

simple methods to manage these networks and provide methods to know the state of the

nodes. This is achieving by using a protocol based on the SNMP protocol, and the use of

graph theory methods (redundancy and the articulation points).

This system is designed to remotely monitor the various elements of wireless sensor

networks, allowing you to view and edit their configurations and to access the various sensor

values.

Keywords: Wireless Sensor Networks, Supervision, Protocol SNMP, Graph Theory,

redundancy, articulation points.

TABLE DES MATIERES

Système De Supervision Des Réseaux De Capteurs Sans Fil Page i

Table des matières

LISTE DES FIGURES ................................................................................................................. vi

LISTE DES TABLEAUX ............................................................................................................... x

LISTE DES ABREVIATIONS ..................................................................................................... xi

INTRODUCTION GENERAL ET PROBLEMATIQUE ............................................................. 1

Chapitre I : GENERALITE SUR LES RESEAUX DE CAPTEURS SANS FIL

I.1. Introduction ............................................................................................................................ 4

I.2. Définition des réseaux sans fil ............................................................................................... 4

I.3. Les catégories des réseaux sans fil ....................................................................................... 5

I.3.1. Le réseau personnel sans fil (WPAN) ..................................................................... 5

I.3.1.1. La technologie Bluetooth ................................................................................. 5

I.3.1.2. La technologie ZigBee ..................................................................................... 5

I.3.1.3. Les liaisons infrarouges ................................................................................... 6

I.3.2. Le réseau local sans fil (WLAN) ............................................................................. 6

I.3.2.1. Les réseaux Wi-Fi (Wireless-Fidelity) ............................................................ 6

I.3.2.2. Les réseaux HiperLAN 2 (High Performance LAN 2.0) ................................ 6

I.3.3. Le réseau métropolitain sans fil (WMAN) .............................................................. 6

I.3.3.1. les réseaux Wimax (Worldwide interoperability for Microwave Access) ....... 6

I.3.4. Le réseau étendu sans fil (WWAN) ......................................................................... 7

I.4. Définition d’un réseau Ad Hoc .............................................................................................. 7

I.5. Capteur sans fil ...................................................................................................................... 7

I.5.1. Unité de captage ...................................................................................................... 8

I.5.2. Unité de traitement .................................................................................................. 8

I.5.3. Unité de communication ......................................................................................... 8

I.5.4. Unité d’alimentation énergétique ........................................................................... 9

I.6. Réseau des capteurs sans fil ................................................................................................. 10

I.7. Le réseau des capteurs mobiles ............................................................................................ 11

I.8. Les états opérationnels d’un nœud capteur .......................................................................... 12

I.9. Architecture de réseau de capteurs sans fil .......................................................................... 12

I.9.1. Les réseaux de capteurs sans-fil plats .................................................................... 12

I.9.2. Les réseaux de capteurs sans-fil hiérarchiques ...................................................... 13

I.10. Les principales caractéristiques et contraintes des RCSFs .................................................. 14

I.10.1. La consommation réduite d’énergie ..................................................................... 14

I.10.2. L’auto-configuration des nœuds capteurs ............................................................. 14

I.10.3. L’évolutivité .......................................................................................................... 14

I.10.4. La tolérance aux pannes ....................................................................................... 14

I.10.5. Une densité importante des nœuds ....................................................................... 15

I.10.6. La Surveillance ...................................................................................................... 15

TABLE DES MATIERES

Système De Supervision Des Réseaux De Capteurs Sans Fil Page ii

I.10.7. La capacité de communication ............................................................................. 16

I.10.7.1. Les types de communication ......................................................................... 16

I.10.8. Une architecture « data-centric » .......................................................................... 17

I.10.9. Une collaboration entre les nœuds ........................................................................ 18

I.10.10. La bande passante (ou capacité du canal) .......................................................... 18

I.10.11. Notion de cluster ................................................................................................ 18

I.10.12. La qualité de service ............................................................................................ 18

I.10.13. La topologie de réseau ......................................................................................... 19

I.11. La mise en œuvre des réseaux sans fil ................................................................................. 19

I.11.1. Le mode de fonctionnement centralisé ................................................................ 19

I.11.2. Le mode de fonctionnement ad hoc .................................................................... 20

I.12. Domaines d’application des réseaux de capteurs ................................................................ 21

I.12.1. Applications militaires ........................................................................................ 21

I.12.2. Applications à la surveillance ............................................................................. 21

I.12.3. Applications environnementales ......................................................................... 21

I.12.4. Applications médicales ....................................................................................... 22

I.12.5. Applications domestiques ................................................................................... 22

I.12.6. Applications commerciales ................................................................................. 22

I.13. Le stockage des données ...................................................................................................... 23

I.14. La collection d’information ................................................................................................. 24

I.14.1. À la demande ....................................................................................................... 24

I.14.2. Suite à un évènement ........................................................................................... 24

I.15. Systèmes embarqués ............................................................................................................ 25

I.16. La pile protocolaire des RCSF ............................................................................................. 25

I.16.1. La couche physique ............................................................................................. 26

I.16.2. La couche liaison de données .............................................................................. 26

I.16.3. La couche réseau ................................................................................................. 27

I.16.4. La couche transport ............................................................................................. 27

I.16.5. La couche application .......................................................................................... 27

I.17. Classification des protocoles de routages pour les réseaux de capteur sans fil ................... 28

I.17.1. Selon la topologie du réseau ................................................................................ 29

I.17.2. Selon le fonctionnement du protocole ................................................................. 29

I.17.2.1. Routage basé sur les multi-chemins ........................................................... 29

I.17.2.2. Routage basé sur les requêtes .................................................................... 29

I.17.2.3. Routage basé sur la négociation ................................................................. 29

I.17.2.4. Routage basé sur la qualité de service ....................................................... 29

I.17.3. Selon le Paradigme de communication ............................................................... 30

I.17.3.1. Centré-nœud (Node centric) ..................................................................... 30

I.17.3.2. Centré-données (Data centric) .................................................................. 30

I.17.3.3. Basé-localisation (Position centric) .......................................................... 30

I.17.4. Selon le mode de l’établissement de chemins .................................................... 30

I.17.4.1. Les protocoles proactifs ............................................................................. 30

I.17.4.2. Les protocoles réactifs ............................................................................... 30

TABLE DES MATIERES

Système De Supervision Des Réseaux De Capteurs Sans Fil Page iii

I.17.4.3. Les protocoles hybrides ............................................................................. 31

I.18. Conclusion ........................................................................................................................... 31

Chapitre II : L’ADMINISTRATION DES RESEAUX

II.1. Introduction ............................................................................................................................ 32

II.2. La gestion de réseau ............................................................................................................... 32

II.3. Principe général ...................................................................................................................... 33

II.4. Le concept de supervision du réseau ..................................................................................... 34

II.5. Structure d’un système d’administration ............................................................................... 35

II.6. Fonctions de base de la gestion de réseau .............................................................................. 36

II.7. Structure des informations d’administration de réseaux (SMI) ............................................. 37

II.7.1. Définitions formelles utilisant ASN.1 ...................................................................... 37

II.8. Les différents aspects de la supervision des réseaux ............................................................ 37

II.8.1. L’analyse de flux ..................................................................................................... 38

II.8.2. La supervision applicative : état des services .......................................................... 38

II.8.3. La supervision SNMP : l’état des équipements ....................................................... 39

II.9. Les protocoles de gestion réseau ............................................................................................ 39

II.9.1. Historique des protocoles d’administration .............................................................. 39

II.10. L’administration vue par la norme ISO ............................................................................... 40

II.10.1. Les différents modèles ........................................................................................ 40

II.10.1.1. Le modèle architectural ............................................................................. 40

II.10.1.2. Le modèle informationnel .......................................................................... 41

II.10.1.3. Le modèle fonctionnel ............................................................................... 42

II.11. L’administration dans l’environnement TCP/IP .................................................................. 43

II.11.1. Présentation générale de protocole SNMP ............................................................... 43

II.11.2. Les différentes versions de SNMP ............................................................................ 44

II.11.3. Architecture globale .................................................................................................. 45

II.11.4. Principe de fonctionnement ...................................................................................... 46

II.11.5. Trame SNMP ............................................................................................................ 49

II.11.5.1. Format des PDUs ................................................................................................ 49

II.11.6. Les MIBS (Management Information base) ............................................................. 50

II.11.7. La sécurité sur SNMP ............................................................................................... 52

II.11.7.1. Les faiblesses de SNMPv1 .................................................................................. 52

II.11.7.2. Les améliorations de SNMPv2c .......................................................................... 52

II.11.7.3. La sécurité sur SNMPv3 ..................................................................................... 52

II.12. Conclusion ........................................................................................................................... 53

Chapitre III : GESTION ET SUPERVISION DES RCSFs-Etat de l’art

III.1. Introduction ...................................................................................................................... 54

III.2. Objectifs de gestion des RCSFs ...................................................................................... 54

III.3. Critères de conception de systèmes de gestion de RCSF ................................................. 55

III.4. Les fonctions principales de gestion des RCSFs ............................................................. 56

III.5. Les systèmes de gestion de RCSF .................................................................................... 58

III.5.1. Cadre de gestion de réseau de capteurs sans fil ........................................................ 59

TABLE DES MATIERES

Système De Supervision Des Réseaux De Capteurs Sans Fil Page iv

III.5.1.1. BOSS ................................................................................................................... 59

III.5.1.2. MANNA .............................................................................................................. 60

III.5.2. Protocoles de gestion des réseaux de capteurs sans fil ............................................. 62

III.5.2.1. RRP ..................................................................................................................... 62

III.5.2.2. SNMS .................................................................................................................. 63

III.5.2.3. WinMS ................................................................................................................ 63

III.5.3. Gestion par délégation .............................................................................................. 64

III.5.3.1. Agilla ................................................................................................................... 64

III.5.3.2. Mobile Management Agent Policy-Based ......................................................... 65

III.5.3.3. sectorielle Sweeper .............................................................................................. 65

III.5.3.4. Intelligent Agent-Based Power Management .................................................... 65

III.5.4. Outils de débogage .................................................................................................... 65

III.5.4.1. Sympathy ............................................................................................................. 65

III.5.5. Visualisation Outil .................................................................................................... 66

III.5.5.1. Mote-View .......................................................................................................... 66

III.5.6. Systèmes de gestion d'énergie................................................................................... 66

III.5.6.1. Senos ................................................................................................................... 66

III.5.6.2. AppSleep ............................................................................................................. 67

III.5.6.3. Node-energy level management ......................................................................... 67

III.5.7. Systèmes de gestion de la circulation ....................................................................... 67

III.5.7.1. Siphon .................................................................................................................. 67

III.5.7.2. Gestion des ressources DSN ............................................................................... 68

III.6. L’organisation du système de gestion des RCSF ............................................................. 68

III.6.1. Gestion de réactivité ................................................................................................ 69

III.6.2. Architecture de gestion ............................................................................................. 69

III.6.2.1. Les systèmes de gestion centralisés .................................................................... 69

III.6.2.2. Les systèmes de gestion distribués ...................................................................... 70

III.6.2.3. Les systèmes de gestion hiérarchique ................................................................. 71

III.7. Comparaison des systèmes existants pour la gestion d’un RCSF .................................... 72

III.8. Le protocole SNMP pour les RCSFs ............................................................................... 74

III.9. Conclusion ....................................................................................................................... 75

Chapitre IV : MODELISATION ET CONCEPTION

IV.1. Introduction ...................................................................................................................... 76

IV.2. Etude Préliminaire ............................................................................................................ 76

IV.2.1. Présentation du projet à réaliser .................................................................................... 76

IV.2.1.1. Le modèle formel de présentation ............................................................................ 76

IV.2.1.2. Les fonctionnalités de protocole SWSNMP ............................................................ 78

IV.2.2. Choix techniques .......................................................................................................... 79

IV.2.3. Identification des acteurs .............................................................................................. 79

IV.2.4. Identification des messages .......................................................................................... 80

IV.2.5. Modélisation du contexte .............................................................................................. 81

IV.3. Capture des besoins Fonctionnels ................................................................................... 82

IV.3.1. Déterminer les cas d’utilisations ................................................................................... 82

TABLE DES MATIERES

Système De Supervision Des Réseaux De Capteurs Sans Fil Page v

IV.3.1.1. Identification des cas d’utilisation ...................................................................... 82

IV.3.2. Description préliminaire des cas d’utilisations ............................................................. 84

IV.3.3. Description détaillée des cas d’utilisations ................................................................... 85

IV.4. Développement du modèle dynamique ............................................................................ 89

IV.4.1. Identification des scénarios ....................................................................................... 89

IV.4.1.1. Scénarios de l’Administrateur .............................................................................. 90

IV.4.1.2. Scénarios du Sink ................................................................................................. 90

IV.4.1.3. Scénarios du Capteur ............................................................................................ 91

IV.4.1.4. Scénarios de l’Agent SWSNMP ............................................................................ 91

IV.4.1.5. Scénarios de la Cible ............................................................................................ 92

IV.4.2. Construction des diagrammes d’états ........................................................................ 92

IV.5. Développement du modèle statique ................................................................................. 94

IV.6. Conclusion ....................................................................................................................... 96

Chapitre V : IMPLEMENTATION ET REALISATION

V.1. Introduction ....................................................................................................................... 97

V.2. Langage utilisé................................................................................................................... 97

V.3. Algorithme ......................................................................................................................... 98

V.4. Scénario utilisé .................................................................................................................. 98

V.5. Implémentation ................................................................................................................ 100

IV.5.1. Structure des messages utilisés ................................................................................. 100

IV.5.2. L’activation des capteurs .......................................................................................... 101

IV.5.3. La redondance .......................................................................................................... 102

IV.5.4. Les points d’articulation ........................................................................................... 102

IV.5.4.1. Principe ............................................................................................................. 102

IV.5.4.2. Etapes de détection des points d’articulation ................................................... 103

IV.5.4.3. A O (V + E) algorithme pour trouver tous les points d'articulation (AP) ......... 103

V.6. La supervision avec le protocole SWSNMP ................................................................... 105

V.7. La réalisation de la plateforme ........................................................................................ 105

V.8. Déroulement du projet ..................................................................................................... 108

V.9. Résultats et discussion ..................................................................................................... 112

V.10. Conclusion ....................................................................................................................... 115

CONCLUSION GENERAL ET PERSPECTIVE ..................................................................... 116

BIBLIOGRAPHIE .................................................................................................................... 118

Liste des figures

Système De Supervision Des Réseaux De Capteurs Sans Fil Page vi

Liste des figures

Figure I.1 : Les catégories des réseaux sans fil .............................................................................. 5

Figure I.2 : Les composants d’un nœud capteur ............................................................................ 8

Figure I.3 : Rayons de communication et de détection d'un capteur ............................................. 9

Figure I.4 : Architecture d’un nœud capteur .................................................................................. 9

Figure I.5 : TelosB ....................................................................................................................... 10

Figure I.6 : Exemple de réseau de capteurs ................................................................................. 11

Figure.I.7 : Les états possibles d’un nœud capteur ..................................................................... 12

Figure I.8 : Architecture plat des RCSF ....................................................................................... 13

Figure I.9 : Architecture hiérarchique des RCSF ......................................................................... 13

Figure I.10 : Architecture de communication d’un réseau d’un RCSF ....................................... 16

Figure I.11 : Le routage data-centric ............................................................................................ 17

Figure I.12 : Cluster d'un RCSF ................................................................................................... 18

Figure I.13 : Un exemple de Scatternet composé de trois Piconet .............................................. 20

Figure.I.14 : Quelques applications des RCSFs........................................................................... 23

Figure I.15 : Collecte à la demande ............................................................................................ 24

Figure I.16 : Collecte suite à un événement ................................................................................. 24

Figure I.17 : La pile protocolaire d’un RCSF .............................................................................. 26

Figure I.18 : Classification des protocoles de routage pour les Réseaux de capteurs sans fil ..... 28

Figure II.1 : Structure fonctionnelle d’administration du réseau ................................................. 33

Figure II.2 : Accès à un service distant ........................................................................................ 38

Figure II.3 : Le modèle architectural d’administration par l’ISO ................................................ 40

Figure II.4 : Les fonctions d’administration ................................................................................ 42

Figure II.5 : L’environnement SNMP ......................................................................................... 45

Figure II.6 : Base de SNMP ......................................................................................................... 46

Figure II.7 : Les deux méthodes de supervision SNMP .............................................................. 47

Figure II.8 : Echange de message ................................................................................................ 48

Figure II.9 : Résumé des commandes SNMPv2 ......................................................................... 49

Figure II.10 : Les trames SNMP .................................................................................................. 49

Figure II.11 : Les identificateurs d’objets de La MIB ................................................................. 51

Figure II.12 : Le mécanisme d'authentification ........................................................................... 52

Figure II.13 : Le chiffrement avec DES ..................................................................................... 53

Liste des figures

Système De Supervision Des Réseaux De Capteurs Sans Fil Page vii

Figure III.1 : Architecture de BOSS .......................................................................................... 59

Figure.III.2 : L’ensemble des fonctions de gestion définies dans MANNA ............................... 61

Figure.III.3 : Les relations, les fonctions et les modèles de système MANNA .......................... 61

Figure IV.1 : Diagramme de cas d’utilisation .............................................................................. 84

Figure IV.2 : Diagramme d’activité- s’authentifier ..................................................................... 86

Figure IV.4 : Diagramme d’activité- superviser .......................................................................... 89

Figure IV.5 : Diagramme de séquences – Administrateur .......................................................... 90

Figure IV.6 : Diagramme de séquences – Sink ........................................................................... 90

Figure IV.7 : Diagramme de séquences – Capteur ...................................................................... 91

Figure IV.8 : Diagramme de séquences – Agent SWSNMP ...................................................... 91

Figure IV.9: Diagramme de séquences – Cible ........................................................................... 92

Figure IV.10 : Diagramme d’état ................................................................................................ 93

Figure IV.11 : Diagramme de classe ............................................................................................ 95

Figure V.1: Notre algorithme (Scénario de la simulation( ........................................................... 99

Figure V.2 : Exemple des points d’articulation ......................................................................... 103

Figure V.3 : La plateforme principale ........................................................................................... 105

Figure V.4 : Les légendes ........................................................................................................... 106

Figure V.5 : Légende de SWSNMP ........................................................................................... 106

Figure V.6 : La fenêtre d’authentification .................................................................................. 106

Figure V.7 : La fenêtre de déploiement .................................................................................... 107

Figure V.8 : Déploiement aléatoire de 50 nœuds ....................................................................... 107

Figure V.9 : La couverture et la connectivité des nœuds .......................................................... 108

Figure V.10 : Activation des capteurs et découverte de voisinage ........................................... 108

Figure V.11 : La redondance et les points d’articulation (49 capteur) ....................................... 109

Figure V.12 : Les points d’articulation (34 capteurs) ............................................................... 109

Figure V.13 : L’activation de SWSNMP ................................................................................... 110

Figure V.14 : La fenêtre de supervision ..................................................................................... 110

Figure V.15 : Les opérations ..................................................................................................... 111

Figure V.16 : Les identificateurs des capteurs .......................................................................... 111

Figure V.17 : Quelque état capter par des capteurs .................................................................. 111

Figure V.18 : Exemple d’état de la batterie .............................................................................. 111

Figure V.19 : Exemple d’une table de voisinage d’un capteur ................................................. 112

Figure V.20 : Les liens du RCSF .............................................................................................. 112

Figure V.21 : Histogramme de l’énergie du réseau .................................................................. 113

Liste des figures

Système De Supervision Des Réseaux De Capteurs Sans Fil Page viii

Figure V.22 : Histogramme de l’énergie de chaque capteur ..................................................... 114

Figure V.23 : Histogramme de la totalité des nœuds ................................................................ 115

Liste des tableaux

Système De Supervision Des Réseaux De Capteurs Sans Fil Page x

Liste des tableaux

Tableau III.1: Organisation du système de gestion de réseau .................................................... 68

Tableau III.2 : Système de gestion de réseau évalué par rapport aux critères de conception .... 72

Tableau IV.1 : Les rôles des acteurs ............................................................................................ 81

Tableau IV.2 : Les fonctionnalités des cas d’utilisation .............................................................. 82

Abréviations

Système De Supervision Des Réseaux De Capteurs Sans Fil Page xi

Liste des abréviations

6LoWPAN IPv6 Low Power Wireless Area Networks

ADC Analog to Digital Converter

APTEEN Adapted Threshold sensitive Energy Efficient sensor Network

ASN.1

BFS

Abstract Syntax Notation 1

Breadth First Search

BLR Boucle Locale Radio

BOSS Bridge Of the SenSors

CMIP Common Management Information Protocol

CMIS Common Management Information Service

CMISE Common Management Information Service Element

CPU Central Processing Unit

CRC Cyclic Redundancy Check

DARPA Defense Advanced Research Projects Agency

DD Directed Diffusion

DEC Digital Equipment Corporation

DFS Depth First Search

DLL Dynamic Link Library

DNS Domain Name System

DPM Data Protection Manager

DSN Distributed Sensor Network

DSN RM Distributed Sensor Network Resource Manager

ETSI Européen Télécommunications Standards Institute

FDI Fault Detection and Isolation

FEC Forward Error Correction

FTC Fault Tolerance

FTP File Transfer Protocol

GAF Geographic Adaptive Fidelity

GEAR Geographic and Energy Aware Routing

GHT Geographic Hash Table

http://fr.wikipedia.org/wiki/Dynamic_Link_Library

http://fr.wikipedia.org/wiki/Domain_Name_System

http://fr.wikipedia.org/wiki/System_Center_Data_Protection_Manager

http://fr.wikipedia.org/wiki/File_Transfer_Protocol

Abréviations

Système De Supervision Des Réseaux De Capteurs Sans Fil Page xii

GHz GigaHertz

GPRS General Packet Radio Service

GSM Global System for Mobile communication

HP Hewlett-Packard

HiperLAN High performance radio Local Area Network

IABP International Arctic Buoy Program

IARP Intra-Zone Routing Protocol

IBM International Business Machines

ICMP Internet Control Message Protocol

IEEE Institute of Electrical and Electronics Engineers

IERP InterzonE Routing Protocol

IETF Internet Engineering Task Force

ISO International Standard Organization

LAN Local Area Network

LEACH Low-Energy Adaptive Clustering Hierarchy

MAC Magic Access Control

MANET Mobile Ad hoc NETwork

MANNA MANagemeNt Architecture

MbD Management by Delegation

Mbits Mégabit

MECN Minimum Energy Communication Network

MIB Management Information Base

RF Radio Frequency

NMS Network Management Station

OID Object IDentifier

OS Operating System

OSI Open System Interconnexion

PC Personal Computer

PDA Personal Digital Assistant

PEDAP Power Efficient Data Aggregation Protocol

PEGASIS Power-Efficient Gathering in Sensor Information Systems

QoS Quality of Service

http://fr.wikipedia.org/wiki/International_Business_Machines

http://fr.wikipedia.org/wiki/M%C3%A9gabit

http://www.cisco.com/c/en/us/products/ios-nx-os-software/quality-of-service-qos/

Abréviations

Système De Supervision Des Réseaux De Capteurs Sans Fil Page xiii

RCSF Réseau de Capteur Sans Fil

RFC Request for Comments

RGT Réseau de Gestion des Télécommunications

RR Radio Resource

SAR Single-Aliquot Regenerative-dose

SenOS Sensor Operating System

SMAE System Management Application Entity

SMAP System Management Application Process

SMI Structure of Management Information

SNMP Simple Network Management Protocol

SNMP4J Simple Network Management Protocol for Java

SNMS Sensor Network Management System

SOS Sensor Operating System

SPIN Sensor Protocols for Information via Negotiation

SQL Structured Query Langage

STEM System Tracking wirEless Motion

SWSNMP Simple Wireless Sensor Network Management Protocol

TCP Transmission Control Protocol

IP Internet Protocol

TDMA Time Division Multiple Access

TEEN Threshold Sensitive Energy Efficient Sensor Network

TMN Telecommunications Management Network

UDP User Datagram Protocol

UIT-T Union Internationale des Télécommunications

UML Unified Modeling Language

UMTS Universal Mobile Telecommunication System

UP Unified Process

UPnP Universal Plug and Play

USM User-based Security Model

VACM View- based Access Control Model

VSs Virtual Sinks

Wi-Fi Wireless Fidelity

http://fr.wikipedia.org/wiki/Request_for_comments

http://en.wikipedia.org/wiki/Radio_resource_location_services_protocol

http://fr.wikipedia.org/wiki/Transmission_Control_Protocol

http://fr.wikipedia.org/wiki/Internet_Protocol

http://fr.wikipedia.org/wiki/User_Datagram_Protocol

http://www.uml.org/

http://fr.wikipedia.org/wiki/Unified_Process

Abréviations

Système De Supervision Des Réseaux De Capteurs Sans Fil Page xiv

WLAN Wireless Local Area Network

WMAN Wireless Metropolitan Area Network

Wimax Worldwide interoperability for microwave access

WinMS Wireless sensor network Management System

WPAN Wireless Personal Area Network)

WWAN Wireless Wide Area Network

xDSL x Digital Subscriber Line

INTRODUCTION GENERAL ET PROBLEMATIQUE

Système De Supervision Des Réseaux De Capteur Sans Fil Page 1

Introduction général et problématique

Les progrès technologiques dans les domaines de la microélectronique, des communications

sans fil, couplé aux efforts de miniaturisation et de réduction des coûts de production des

composants électroniques, ont permis le développement de nouvelles générations de petits

appareils électroniques, autonomes, équipés de capteurs et capables de détecter, de calculer, de

stocker et communiquer entre eux sans fil. Ces petits dispositifs sont appelés des nœuds capteurs.

Ensemble, ils forment un réseau appelé réseau de capteurs sans fil (RCSF) qui fournir des

informations utiles prises par les différents capteurs et de les communiquées ensuite via le

support sans fil à un point de collecte appelé "Sink" qui les communique aussi à un poste de

contrôle distant.

L’avancement des technologies dans les infrastructures de réseau et de minuscules capteurs

du réseau permet à de nombreuses applications de réseau de capteurs allant du civils aux

militaires, de la maison à l’environnement et de la nature de l’industriel au domaine commercial

de s’accroitre, car de nos jours le besoin d’observer des phénomènes physiques tel que la

température, la pression ou encore la luminosité est devenu essentiel. Exemples : la surveillance

de l’habitat des animaux, observation de l’environnement et de prévision, le corps humain le

suivi, le champ de bataille de détection et d’analyse, etc.

Les capteurs sont déployé aléatoirement ou d’une manière bien définit dans une zone

géographique, appelée champ de captage, qui définit le terrain d'intérêt pour les phénomènes

ciblés. Ainsi, L’administrateur est besoin d’adresser des requêtes aux capteurs du réseau, en

précisant le type de données requises et récolter les données captées telles que les données

environnementales ou physiologiques par le biais de la station de base.

Une des solutions qui s’annonce prometteuse dans les RCSFs est l’utilisation d’un système

qui est capable de superviser les capteurs et une région ou un phénomène dans une zone

d’intérêt, La gestion de réseau correspond aux actions qui permettent de prendre en charge la

configuration, la sécurité, les pannes. La prise en charge de toutes ces fonctions n’est pas un

mince problème, de nombreux travaux de normalisation ont été effectués dans ce domaine, mais

tous n’ont pas encore abouti à cause de ça difficulté et ça complexité, pour cela le domaine de

supervision et de gestion des RCSFs est encore ouvert.



L’objectif de ce projet est d’étudier le problème de gestion et de supervision des RCSFs en

s’inspirant et en se basant sur les solutions des réseau filaire afin de minimiser la consommation

d’énergie pour chaque capteur en garantissant la continuité de bon fonctionnement du réseau et

assurant le prolongement de son durée de vie.

L’énergie est la ressource la plus précieuse dans un réseau de capteurs puisqu’elle influe

directement sur la durée de vie des capteurs et du réseau en entier. L’arrêt de fonctionnement

d’un ou de plusieurs nœuds peut provoquer la répartition de réseau en plusieurs parties et la dé-

connectivité d’un sous ensemble des nœuds capteurs. Pour cela, nous avons proposé des

mécanismes de gestion en utilisant des aspects de la théorie des graphes spécifiquement la

détection des points d’articulations. Notre mémoire sera organisé comme suit:

Chapitre I : Généralité sur les réseaux de capteurs sans fil

Donne un aperçu sur les réseaux de capteurs sans fil. On commence d’abord par décrire

un nœud capteur et ses caractéristiques, ensuite on expose les réseaux de capteurs sans fil

et leurs architectures puis nous présentons les facteurs et les caractéristiques qui

influencent la conception de ce type des réseaux. Nous introduisons aussi quelques

caractéristiques et métriques des RCSFs.

Chapitre II: L’administration des réseaux

Ce chapitre est consacré à l’administration des réseaux où nous avons présenté les

principaux concepts de gestion et plus précisément la structure d’un système de gestion

et les fonctions de base pour gérer un réseau, puis en parle sur les protocole de gestion

utilisé au niveau de la norme ISO et au niveau de la norme TCP/IP par la description de

protocole SNMP en rappelant les différentes notions et principes de fonctionnement de ce

protocole qui est le plus répandu actuellement.

Chapitre III : Gestion et supervision des RCSFS-état de l’art

Ce chapitre présente les travaux existant dans le domaine de la gestion et la supervision

des réseaux de capteur sans fil, ainsi une petite comparaison des caractéristiques de ces

dernières.

Chapitre IV : Modélisation et conception

Ce chapitre constitue le noyau de ce travail, où en va proposer la modélisation et la

conception afin de réaliser un système de supervision du RCSF, en utilisant le langage

UML.



Chapitre V : Implémentation et réalisation

Ce chapitre présente notre implémentation en montrant les algorithmes proposés pour

réaliser le système de supervision des RCSFs avec l’utilisation de quelque outil de la

théorie des graphes. Les résultats de l’implémentation seront également présentés pour

justifier la validité de notre projet.

Enfin, on conclue notre travail en donnant une conclusion générale que nous avons tirée

de notre travail effectué avec quelques perspectives.

Chapitre I GENERALITE SUR LES RESEAUX DE CAPTEURS SANS FIL

Système De Supervision Des Réseaux De Capteurs Sans Fil Page 4

I.1. Introduction

Les récentes avancées dans le domaine des technologies sans-fil et électronique ont permis

le développement à faible coût de minuscules capteurs consommant peu d'énergie. Ces capteurs

ont trois fonctions ; la capture des données, le calcul des informations à l'aide des valeurs

collectées et l'envoi des résultats de calcul à travers un réseau de capteurs sans-fil.

Les RCSFs présentent un intérêt considérable et une nouvelle étape dans l’évolution des

technologies de l’information et de la communication. Le but général d'un RCSF est la collecte

d'un ensemble de paramètres de l'environnement entourant les capteurs, telles que la température

ou la pression de l'atmosphère, afin de les acheminer vers des points de traitement.

De nombreux domaines d’application sont alors envisagés tels que la détection et la

surveillance des désastres, le contrôle de l’environnement, la surveillance et la maintenance

préventive des machines, etc.

Dans ce chapitre, nous présenterons les réseaux de capteurs sans fil, leurs architectures de

communication, leurs applications. Nous discuterons également les principaux caractéristiques et

contraintes qui influencent la conception des réseaux de capteurs sans fil ainsi que des protocoles

de routage utilisé pour l’acheminement.

I.2. Définition des réseaux sans fil

Un réseau informatique est un ensemble d’équipement informatique relié entre eux grâce à

des supports de communication permettant la communication et le partage de ressources [1].

Selon le type de supports de communication, on distingue : les réseaux filaires qui utilisent

un canal de transmission matériel (le câble coaxial, les paires torsadées, la fibre optique) et les

réseaux sans fils [1].

Un réseau sans fil est un réseau de machines qui n'utilisent pas de câbles. C'est une

technique qui permet aux particuliers, aux réseaux de télécommunications et aux entreprises de

limiter l'utilisation de câbles entre diverses localisations [2].

Les réseaux sans fil recours à des ondes radioélectriques (radio et infrarouges) en lieu et

place des câbles habituels. L'utilisation des réseaux sans fil procure plusieurs avantages,

notamment [2]:

· Facilité de déploiement ;

· Faible coût d’appartenance ;

· L'augmentation de la connectivité ;

· Mobilité et la flexibilité génératrices de gains de productivité, etc.

http://www.fnac.com/seau.html



I.3. Les catégories des réseaux sans fil

Il existe plusieurs catégories de réseaux sans fil qui diffèrent par le périmètre géographique

qu’ils couvrent ainsi que par les types d’applications supportées. Le schéma suivant illustre les

catégories des réseaux sans fil [3].

Figure I.1 : Les catégories des réseaux sans fil [3]

I.3.1. Le réseau personnel sans fil (WPAN)

Il concerne les réseaux sans fil d'une faible portée : de l'ordre de quelques dizaines

de mètres. Ce type de réseau sert généralement à relier des périphériques (imprimante,

téléphone portable, appareils domestiques, …) [3]. Il existe plusieurs technologies

utilisées pour les WPAN :

I.3.1.1. La technologie Bluetooth

Elle est connue aussi sous le nom de la norme IEEE 802.15.1, elle a été

lancée par Ericsson en 1994, proposant un débit théorique de 1 Mbps lui permettant

une transmissions de la voix, des données et des images [3], d’une portée maximale

d'une trentaine de mètres [4]. Bluetooth est une technologie peu onéreuse, grâce à sa

forte intégration sur une puce unique de 9 mm sur 9 mm ; Elle présente également

l’avantage de fonctionner sur des appareils à faible puissance d’où une faible

consommation d’énergie [3].

I.3.1.2. La technologie ZigBee

Elle est connue aussi sous le nom de la norme IEEE 802.15.4 et permet

d'obtenir des liaisons sans fil à bas prix et avec une très faible consommation

d'énergie, ce qui la rend particulièrement adaptée pour être directement intégrée dans

de petits appareils électroniques (capteurs, appareils électroménagers...) [4].

Réseaux personnels sans fil (WPAN)

Réseaux métropolitains sans fil (WMAN)

Réseaux locaux sans fil (WLAN) Réseaux étendu sans fil (WWAN)

GSM

UMTS

GPRS



Les réseaux ZigBee permettent d’offrir des débits jusqu’à 250 Kbits/s dans la

bande classique des 2,4GHz. Les RCSF constituent une des applications que cette

norme peut couvrir [3].

I.3.1.3. Les liaisons infrarouges

Elles permettent de créer des liaisons sans fil de quelques mètres avec des

débits pouvant monter à quelques mégabits par seconde. Cette technologie est

largement utilisée dans la domotique (télécommandes), elle souffre toutefois des

perturbations dues aux interférences lumineuses [5].

I.3.2. Le réseau local sans fil (WLAN)

C’est un réseau permettant de couvrir une portée d'environ une centaine de

mètres. Il permet de relier entre eux les terminaux présents dans la zone de couverture

[3]. Il existe deux technologies concurrentes :

I.3.2.1. Les réseaux Wi-Fi (Wireless-Fidelity)

Ils proviennent de la norme IEEE 802.11, qui définit une architecture

cellulaire. On y trouve principalement deux types de réseaux sans fil : Ceux qui

travaillent à la vitesse de 11 Mbits/s à 2.4 GHz (IEEE 802.11b) et ceux qui montent à

54 Mbits/s à 5 GHz (IEEE 802.11 a/g) [3].

I.3.2.2. Les réseaux HiperLAN 2 (High Performance LAN 2.0)

Ils découlent de la norme européenne élaborée par l'ETSI (Européen

Télécommunications Standards Institute). HiperLAN 2 permet d'obtenir un débit

théorique de 54 Mbps sur une zone d'une centaine de mètres dans la gamme de

fréquence comprise entre 5 150 et 5 300 MHz [5]. Ce type de réseau n’a pas reçu

autant de succès que la technologie Wi-fi.

I.3.3. Le réseau métropolitain sans fil (WMAN)

Il est connu aussi sous le nom de Boucle Locale Radio (BLR). Il convient de

rappeler que la BLR permet, en plaçant une antenne parabolique sur le toit d'un bâtiment,

de transmettre par voie hertzienne de la voix et des données à haut débit pour l'accès à

l'internet et la téléphonie [6]. Il existe plusieurs types de réseaux WMAN dont le plus

connu est :

I.3.3.1. les réseaux Wimax (Worldwide interoperability for Microwave Access)

Ils émanent de la norme IEEE 802.16 et ont pour but de développer des

liaisons hertéziennes concurrentes aux techniques xDSL terrestres et offrent un débit

utile de 1 à 10 Mbit/s dans la bande 10-66 GHz pour une portée de 4 à 10 kilomètres,



ce qui destine principalement cette technologie aux opérateurs de télécommunication

[6].

I.3.4. Le réseau étendu sans fil (WWAN)

Il est connu sous le nom de réseau cellulaire mobile et il est le plus répandu de tous

puisque tous les téléphones mobiles sont connectés à un réseau étendu sans fil. Les

principales technologies sont les suivantes : GSM (Global System for Mobile

Communication), GPRS (General Packet Radio Service), UMTS (Universal Mobile

Telecommunication System) [4].

I.4. Définition d’un réseau Ad Hoc

Un réseau mobile Ad Hoc appelé généralement MANET (Mobile Ad hoc Network), peut

être défini comme une collection d’entrés mobiles interconnectées par une technologie sans fil,

formant un réseau temporaire sans l’aide d’une infrastructure préexistante ou d’administration

centralisée [7]. Ce sont les entités mobiles elles-mêmes qui forment, d’une manière Ad Hoc, une

infrastructure du réseau [3].

Les entités qui composent ce réseau possèdent un dispositif de communication sans fil leur

permettant de communiquer avec les entités situées dans leur voisinage. Chaque nœud peut

joindre directement ses voisins en utilisant son interface radio. Un nœud a la possibilité

d’atteindre n’importe quel autre nœud à l’intérieur du réseau en utilisant les nœuds intermédiaire

(situés entre la source et la destination) qui agissent en tant que nœud relais [3].

Avec ce mode de fonctionnement, il est possible d’utiliser des protocoles de routage

proactifs, réactifs ou hybrides [7].

Les réseaux Ad Hoc sont idéaux pour les applications caractérisées par une absence ou la

non fiabilité d’une infrastructure préexistante, telles que les applications militaires, les opérations

de secours (incendies, tremblement de terre, etc.) et les missions d’exploration [8].

I.5. Capteur sans fil

Un capteur sans fil est un petit dispositif à un coût raisonnable, de quelques millimètres

cubes en volume. Il a pour but de relever des grandeurs physiques comme l’humidité, l’intensité

de la luminosité, la température et les vibrations, suivant l’environnement dans lequel il est

déployé et l’objectif pour lequel il est conçu. Un capteur sans fil est doté, principalement, de

quatre unités [9] (Figure I.2).



Figure I.2 : Les composants d’un nœud capteur [9]

I.5.1. Unité de captage

Elle est constituée de deux composants, un dispositif qui intercepte les données du

monde physique et les transforme en signaux analogiques, et un convertisseur

analogique/numérique (ADC) qui transforme ces signaux analogiques en un signal

numérique compréhensible par l’unité de traitement [10].

I.5.2. Unité de traitement

Elle est composée d’un microprocesseur ou d’un microcontrôleur associe

généralement à une unité de stockage [11]. Elle est chargée d’exécuter les protocoles de

communication, comme elle peut aussi effectuer des semi traitements sur les données

captées. Cette unité est également composée de deux interfaces, une interface pour l'unité

d'acquisition et autre pour l'unité de transmission. Elle acquiert les informations en

provenance de l'unité d'acquisition et les envoie à l'unité de transmission [12].

I.5.3. Unité de communication

Elle est responsable des émissions et réceptions des données sur un medium sans

fil. Elle se base sur les technologies sans fil à faible portée de communication, Zigbee

IEEE 802.15.4, Bluetooth IEEE 802.15.1 ou WiFi IEEE 802.11 [11].

Chaque capteur possède un rayon de communication (Rc) et un rayon de sensation

(Rs). La Figure I.3 montre les zones définies par ces deux rayons pour le capteur A. La

zone de communication est la zone où le capteur A peut communiquer avec les autres

capteurs. Dans cet exemple, le capteur A peut communiquer avec un capteur B. D’autre

part, la zone de détection est la zone où le capteur A peut capter l’événement. Dans cet

exemple, il s’agit de la zone dans laquelle se trouve le capteur C [10].

Emetteur/Récepteur

Radio

Batterie Processeur Mémoir

e

Module de

captage

Capteur



Figure I.3 : Rayons de communication et de détection d'un capteur [10]

Par ailleurs, pour qu’un capteur ait une portée de communication suffisamment

grande, il est nécessaire d’utiliser un signal assez puissant. Cependant, l’énergie

consommée serait importante [10].

I.5.4. Unité d’alimentation énergétique

Elle est responsable de la gestion de l’énergie et de l’alimentation de tous les

composants du capteur. Elle consiste, généralement, en une batterie qui est limitée et

irremplaçable, ce qui a rendu l’énergie comme principale contrainte pour un capteur [13].

Figure I.4 : Architecture d’un nœud capteur [13]



Il existe dans le monde plusieurs fabricants de capteurs. On cite Crossbow, Cisco, Dalsa,

EuroTherm et Sens2B. Parmi ces capteurs fabriqués, il existe quelques-uns qui sont capables de

varier la puissance du signal émis afin d’élargir/réduire le rayon de communication et en

conséquence la zone de communication. La Figure I.4 montre un capteur intelligent qui fait

partie à la famille des Telos, il s’agit d’un capteur TelosB [9].

La figures suivantes illustrent les composants d'un noeud capteur TelosB de

CrossBow [9]:

Figure I.5 : TelosB [9]

I.6. Réseau des capteurs sans fil

Un réseau des capteurs sans fil (RCSF) est un type particulier des réseaux ad hoc [14] qui

partage beaucoup de caractéristiques avec les réseaux embarques sans fil [15]. Il est constitué

d’un grand nombre de capteurs, coopérant pour réaliser une tache commune et disperses sur une

zone géographique, appelée champ de captage. Il est conçu dans le but de surveiller, détecter et

traiter des phénomènes physiques captées au niveau local, ou de les envoyer à l’aide de la

communication sans fil a un ou plusieurs points de collecte, appelés station de base [14].

Les capteurs remplissent deux rôles: source d’informations et/ou relais pour le reste du

réseau. Ils sont habituellement dispersés dans un champ de capteurs où chacun de ces derniers a

la possibilité de collecter des données et de les transmettre au sink. Les récentes avancées dans

les domaines des technologies sans-fil et électroniques ont permis le développement à faible coût

de minuscules capteurs consommant peu d'énergie [4].



Les capteurs ne sont pas intégrés à une quelconque architecture préexistante de réseau.

C’est pourquoi ils communiquent à l’aide d’un réseau ad hoc sans fil [16], tout d’abord dans un

souci de simplicité d’installation, mais aussi et surtout dans le souci de permettre au réseau de

rester opérationnel même après des défaillances ponctuelles des nœuds. Ils doivent pouvoir

s’autogérer, en utilisant des protocoles permettant d’apprendre des éléments tels que la topologie

du réseau, le positionnement relatifs des capteurs au sein du réseau, les routes possibles pour

communiquer avec d’autres nœuds donnés [4]. Les communications multi sauts sont privilégiées

par rapport aux transmissions directes au sink. C’est un nœud particulier doté d’une puissance de

calcul supérieure et d’une quantité d’énergie potentiellement infinie. Il récupère les informations

remontées par les différents capteurs et les transmet à l’utilisateur. Il peut y avoir plusieurs puits

mobiles ou fixes dans un réseau [16].

Figure I.6 : Exemple de réseau de capteurs [16]

I.7. Le réseau des capteurs mobiles

La mobilité est une question clé pour les réseaux de capteurs où chaque nœud peut se

déplacer à l’intérieur du site, seul ou avec un groupe. Par exemple, quand les capteurs sont

embarqués sur des dispositifs mobiles tels que les véhicules, ou sur des animaux. Lorsque la

mobilité est trop fréquente, elle ne peut être considérée comme un problème secondaire. Ainsi, la

détection des voisins et la reconfiguration du réseau exigent habituellement un nombre important

de messages de contrôle de la topologie, donc une dépense importante d’énergie [17].



I.8. Les états opérationnels d’un nœud capteur

Le diagramme suivant présente les différents états possibles lors de fonctionnement d’un

nœud capteur. Nous voyons dans la figure I.7 que l’état du capteur dépend de son niveau

d’énergie. Le capteur peut avoir cinq états : en transmission, en réception, en écoute, en sleep ou

inactif [5].

Figure.I.7 : Les états possibles d’un nœud capteur [5]

I.9. Architecture de réseau de capteurs sans fil

Un Réseau de Capteurs Sans-Fil (RCSF) est un ensemble de capteurs variant de quelques

dizaines d'éléments à plusieurs centaines, parfois plus, utilisant des liens sans-fil pour la

communication [18].

Chaque réseau de capteurs a la capacité de collecter des données à partir d'un champ de

captage, qui définit la zone d'intérêt pour le phénomène capté. A l'aide d'une architecture multi-

sauts, un RCSF transmet les données collectées à un nœud (Plusieurs à un). Ce dernier est

considère comme un point de collecte et peut transférer les données collectées via internet ou

satellite à un ordinateur central " gestionnaire de tâche " pour leur traitement [18].

Il existe deux types d'architectures pour les réseaux de capteurs sans-fil :

I.9.1. Les réseaux de capteurs sans-fil plats

Un réseau de capteurs sans-fil plat est un réseau homogène, où tous les nœuds

sont identiques en termes de batterie et de complexité du matériel, excepté le sink qui

joue le rôle d'une passerelle et qui est responsable de la transmission de l'information

collectée à l'utilisateur final. Selon le service et le type de capteurs, une densité de

capteurs élevée (plusieurs nœuds capteurs/m2) ainsi qu'une communication multi-sauts

peut être nécessaire pour l'architecture plate. En présence d'un très grand nombre de



nœuds capteurs, le passage à l'échelle devient critique. Le routage et le contrôle d'accès

au médium (MAC) doivent gérer et organiser les nœuds d'une manière très efficace en

termes d'énergie [18].

Figure I.8 : Architecture plat des RCSF [18]

I.9.2. Les réseaux de capteurs sans-fil hiérarchiques

Une architecture hiérarchique a été proposée pour réduire la complexité de la

plupart des nœuds capteurs et leur déploiement, en introduisant un ensemble de nœuds

capteurs plus puissants. Ceci permet de décharger la majorité des nœuds simples à faible

coût de plusieurs fonctions du réseau. L'architecture hiérarchique est composée de

plusieurs couches : une couche de capteurs, une couche de transmission et une couche de

point d'accès. Cette architecture sans-fil est influencée par un certain nombre de facteurs

et contraintes tels que la tolérance aux fautes, le redimensionnement, les couts de

production, l'environnement, la topologie du réseau, les contraintes matérielles, les

médias de transmission et la consommation d'énergie [19].

Figure I.9 : Architecture hiérarchique des RCSF [19]



I.10. Les principales caractéristiques et contraintes des RCSFs

I.10.1. La consommation réduite d’énergie

Les nœuds capteurs utilisent des batteries de taille minuscule comme ressources

en énergie, ce qui limite leur durée de vie. La spécificité des applications des RCSFs

(militaires, et autres) fait que la recharge ou le remplacement de ces batteries est une tâche

difficile ou presque impossible, ce qui nous mène à déduire que la durée de vie d’un nœud

est essentiellement dépendante de la durée de vie de la batterie. Ainsi, la méthode de

gestion de consommation d’énergie constitue une contrainte majeure dans ce type de

réseau [5].

I.10.2. L’auto-configuration des nœuds capteurs

Dans un RCSF, les nœuds sont déployés soit d’une manière aléatoire (missile,

avion…), soit placés nœud par nœud par un humain ou un robot, et ceci à l’intérieur ou

autour du phénomène observé (champ de guerre, surface volcanique, patient malade…).

Ainsi, un nœud capteur doit avoir des capacités d’une part, pour s’auto-configurer dans le

réseau, et d’autre part pour collaborer avec les autres nœuds dans le but de reconfigurer

dynamiquement le réseau en cas de changement de topologie du réseau [20].

Dans un RCSF, chaque nœud X possède une unité émettrice/réceptrice qui lui

permet de communiquer avec les nœuds qui lui sont proches; En échangeant des

informations avec ces derniers, le nœud X pourra alors découvrir ses nœuds voisins et ainsi

connaître la méthode de routage qu’il va adopter selon les besoins de l’application. L’auto-

configuration apparaît comme une caractéristique nécessaire dans le cas des RCSF étant

donné que d’une part, leur déploiement s’effectue d’une manière aléatoire dans la majorité

des applications, et d’autre part le nombre des nœuds capteurs est très grand. En revanche,

avec une approche aléatoire, les capteurs sont éparpillés [21].

I.10.3. L’évolutivité

Contrairement aux réseaux sans fil traditionnels (personnel, local ou étendu), un

RCSF peut contenir un très grand nombre de nœuds capteurs (des centaines, des

milliers…). Un réseau de capteur est évolutive parce qu’il a la faculté d’accepter un très

grand nombre de nœuds qui collaborent ensemble afin d’atteindre un objectif commun [9].

I.10.4. La tolérance aux pannes

La tolérance aux pannes est la capacité de maintenir un réseau de capteurs et

d’assurer les fonctionnalités sans aucune interruption due aux échecs des nœuds [9].



Dans le cas de dysfonctionnement d’un nœud (manque d’énergie, interférences

avec l’environnement d’observation…) ou aussi en cas d’ajout de nouveaux nœuds

capteurs dans le réseau, ce nœud doit continuer à fonctionner normalement sans

interruption. Ceci explique le fait qu’un RCSF n’adopte pas de topologie fixe mais plutôt

dynamique [9].

Un premier défi sera donc d’identifier et de modéliser formellement les modes de

défaillances des capteurs, puis de repenser les techniques de tolérance aux fautes à mettre

en œuvre. La fiabilité Rk(t) ou la tolérance de panne d'un capteur est modélisé à l'aide de la

distribution de poisson pour déterminer les probabilités de ne pas avoir de défaillance dans

l’intervalle de temps (0, T): (I.1)

Où λ est le taux de défaillance du nœud capteur k, et t est un période de temps [21].

I.10.5. Une densité importante des nœuds

Les RCSF sont caractérisés par leur forte densité. Cette densité peut atteindre,

selon le type d’application [9].

La densité peut varier de quelques nœuds à quelques centaines de nœuds dans une

région. Il doit également utiliser une densité des nœuds capteurs élevée. La densité μ peut

être calculée par la formule suivante [22] : ( ) ( ) (I.2)

Où N est le nombre des nœuds dispersés dans la région A et R représente le rayon

de transmission.

Les algorithmes de routage doivent être capables de fonctionner efficacement

avec un grand nombre de capteurs. De plus, ces algorithmes doivent traiter un grand

nombre d’évènements sans être saturés [9].

I.10.6. La Surveillance

Pour l’augmentation de la fiabilité, de la disponibilité et de la sûreté de

fonctionnement des processus, des systèmes de surveillance sont mise en œuvre dont

l’objectif est d’être capable à tout instant, de fournir l’état de fonctionnement des différents

équipements constitutifs d’un processus technologiques. Tant au niveau de la détection et

de l’isolation des fautes (FDI) qu’au niveau de la tolérance aux fautes (FTC). L’opérateur

de supervision gère deux types d’information, le premier concerne la détection et

l’isolation des défauts survenus, et le deuxième indique les possibilités de laisser

fonctionner ou non le processus [21].



I.10.7. La capacité de communication

Elle peut prendre deux aspects : Le multi-saut ou à un seul saut. Parce que le

multi-saut est moins énergivore, il reste le type de communication le plus sollicité par les

applications de RCSF qui requièrent une faible consommation d’énergie [20].

Les nœuds capteurs sont habituellement dispersés dans un environnement comme

le montre la figure (I.10). Les capteurs ont des possibilités de rassembler des données et de

les acheminer vers le Sink, par une architecture multi-saut. Le sink peut communiquer avec

l’utilisateur final ou le décideur par l’intermédiaire d’un réseau de transport tel que

l’internet ou le satellite [20].

Figure I.10 : Architecture de communication d’un réseau d’un RCSF [20]

I.10.7.1. Les types de communication

Il existe différents types de communication utilisée dans les RCSFs :

Unicast : ce type de communication est utilisé pour échanger des

informations entre deux nœuds sur le réseau [9].

Broadcast : le Sink transmet des informations vers tous les nœuds du

réseau. Ces informations peuvent être des requêtes de données bien

précises (ex : la température dans la région A) [9].

Local Gossip : ce type de communication est utilisé par des nœuds situés

dans une région bien déterminée qui collaborent ensemble afin d’avoir une

meilleure estimation de l’évènement observé et d’éviter l’émission du

même message vers le nœud « Sink » ce qui contribue à consommer moins

d’énergie [9].



Convergecast : il est utilisé dans les communications entre un groupe de

nœuds et un nœud bien spécifique (qui peut être le « Sink »). L’avantage

de ce type de communication est la diminution de contrôle d’entête des

paquets (« control overhead ») ce qui économise l’énergie au niveau du

nœud récepteur [20].

Multicast : il permet une communication entre un nœud et un groupe de

nœuds. Ce type de communication est utilisé dans les protocoles qui

incluent le « clustering » dans lesquels, le « Clusterhead » s’intéresse à

communiquer avec un groupe de nœuds [9].

I.10.8. Une architecture « data-centric »

Du fait que le remplacement ou la recharge des batteries des nœuds capteurs est

une tâche non pratique et difficile à réaliser, alors il est d’usage normal qu’on trouve des

nœuds capteurs redondants (effectuant la même tâche dans la même région) ; L’importance

d’un nœud particulier est, par conséquent, réduite par rapport à l’importance attribuée aux

données observées par les nœuds [20].

Ce type d’architecture diffère des architectures « node-centric » adoptées par les

réseaux traditionnels où les nœuds possèdent une place importante (Exemple : un

utilisateur qui veut connecter son laptop au serveur web X) [20].

Comme la montre l’exemple d’une approche data-centric dans la figure I.11, les

données provenant des deux sources sont agrégées au noeud B. Ensuite, la donnée

combinée (1+2) est envoyée de B vers la destination [20].

Figure I.11 : Le routage data-centric [20]



I.10.9. Une collaboration entre les nœuds

Les contraintes strictes de consommation d’énergie mènent les nœuds capteurs à

détecter et traiter les données d’une manière coopérative afin d’éviter le traitement

redondant d’une même donnée observée, source de la perte d’énergie [22].

I.10.10. La bande passante (ou capacité du canal)

C’est une caractéristique beaucoup plus importante dans les réseaux cellulaires

(GSM) et les réseaux locaux sans fils (WLAN), que dans les RCSF ; le débit étant en effet

un objectif secondaire pour les RCSF [23].

I.10.11. Notion de cluster

L’organisation des nœuds en clusters permet de réduire la complexité des

algorithmes de routage, d’optimiser la ressource medium en la faisant gérer localement par

un chef de cluster, de faciliter l’agrégation des données, de simplifier la gestion du réseau

et en particulier l’affectation des adresses, d’optimiser les dépenses d’énergie, et enfin de

rendre le réseau plus scalaire. L’utilisation de clusters permet aussi de stabiliser la

topologie et la gestion du réseau si les tailles de clusters sont grandes par rapport aux

vitesses de nœuds mais cela ne fonctionne que dans le cas d’une faible mobilité [5].

Figure I.12 : Cluster d'un RCSF [5]

I.10.12. La qualité de service

Dans diverses applications, la donnée doit être transmise dans une certaine plage

de temps. Son objectif est d’évaluer la QoS délivrée par le réseau et de la maintenir grâce à

des opérations de contrôle. Elle comprend les opérations de surveillance qui permettent de

déterminer l’état de fonctionnement du réseau à travers des différents critères de qualité

telles que le traitement des sources de puissance, de mémoire, de bande passante et de

puissance, mais aussi les opérations de prévention et de correction qui permettent de



garantir le niveau de performances désiré. Mais dans la plupart des applications, la durée

de vie du réseau est favorisée au détriment de la qualité d’émission des données. Les

protocoles de routage qui assurent une qualité de service prenant en compte la gestion de

l’énergie, représentent un défi nouveau et stimulant [23].

I.10.13. La topologie de réseau [24]

Les capteurs sont déployés dans un champ de surveillance d’où trois phases de

déploiements sont représentées :

Pré-déploiement: les nœuds capteurs peuvent être soit jeté dans une masse ou

placés un par un dans le champ de déploiement.

Post-déploiement: après le déploiement, des changements topologiques sont

dues au changement des positions des nœuds, l'accessibilité, le bruit, des

obstacles mobiles, niveau d'énergie et des dysfonctionnements. Une défaillance

énergétique d’un capteur peut changer significativement la topologie du réseau

et imposer une réorganisation coûteuse de ce dernier.

Redéploiement des nœuds supplémentaires: d'autres nœuds peuvent être

redéployé à tout moment, de remplacer les nœuds en panne ou adapter les

changements d’une tache dynamique.

I.11. La mise en œuvre des réseaux sans fil

Les WPAN et les WLAN disposent de deux modes de fonctionnement : le mode

centralisé et le mode distribué ou ad hoc.

I.11.1. Le mode de fonctionnement centralisé

Le mode de fonctionnement centralisé est basé sur la présence d'un nœud maître

au sein du réseau qui administre les communications.

Dans le cas des WPAN (comme Bluetooth), c'est un nœud qui prend en charge ce

rôle de chef d'orchestre du réseau. Les autres nœuds du réseau sont alors les esclaves du

nœud maître : ce sont des "Piconet" (par exemple dans le cas du Bluetooth un maître peut

avoir jusqu'à 7 esclaves en mode actifs et 255 esclaves en mode passif ou esclaves parked).

Les esclaves ne peuvent pas communiquer entre eux. Des réseaux plus étendus peuvent

être créés, dits "Scatternet", où un esclave peut avoir plusieurs maîtres, ce qui permet de

relier entre eux des Piconet (voir la Figure I.13) [20].



Figure I.13 : Un exemple de Scatternet composé de trois Piconet [20]

Dans le cas des WLAN, un équipement spécifique se voit attribuer cette fonction,

c'est le point d'accès. Ce mode de fonctionnement permet d'avoir un réseau relativement

stable et de gérer la QoS. Le point d'accès permet de contrôler l'accès des stations au réseau

et de leur attribuer des ressources. En revanche, tous les nœuds du réseau doivent être à 25

portées radio du point d'accès. Si le réseau doit être plus grand que cette portée, il faut

multiplier les points d'accès : c'est le type de fonctionnement utilisé dans les bureaux, les

aéroports, les gares, les hôtels, etc [20].

I.11.2. Le mode de fonctionnement ad hoc

Les réseaux sans fil ont également un mode de communication distribué dit ad

hoc. Ce mode correspond au cas où tous les nœuds du réseau ont le même rôle et

dialoguent deux à deux sans relation maître-esclave ou sans point d'accès. Ce mode est

intégré dans le fonctionnement de base des WLAN et dans certains WPAN comme le

ZigBee Mais ce mode, tel que défini dans les standards, est limité : en été, pour dialoguer

entre eux, les nœuds doivent être à portée radio, ce qui limite la couverture de tels réseaux

[8].

Ce mode de fonctionnement de base peut être étendu par l'ajout au niveau des

nœuds d'un protocole de routage qui permet aux nœuds de propager les informations dans

le réseau même s'ils ne sont pas destinataires. Cela permet au nœud de se déplacer tout en

gardant une connectivité avec les autres membres du réseau : ce sont des MANET (Mobile

Ad hoc Network) [7].

Les travaux de recherche sur ces protocoles de routage sont fédérés au sein de

l'IETF17 (Internet Engineering Task Force), organisation de normalisation d'Internet. Ce

type de réseaux permet d'envisager de nombreuses applications comme la domotique, les

réseaux de capteurs, les services d'urgence en cas de destruction des infrastructures, la

coopération entre des machines de manière spontanée [3].



I.12. Domaines d’application des réseaux de capteurs

La miniaturisation des capteurs, le coût de plus en plus faible, la large gamme des types

de capteurs disponibles ainsi que le support de communication sans fil utilisé, permettent aux

réseaux de capteurs de se développer dans plusieurs domaines d’application. Ils permettent aussi

d’étendre les applications existantes [25].

Les réseaux de capteurs peuvent se révéler très utiles dans de nombreuses applications

lorsqu’il s’agit de collecter et de traiter des informations provenant de l’environnement. Parmi

les domaines où ces réseaux peuvent offrir les meilleures contributions, on cite les domaines:

militaire, surveillance, environnemental, médical, domestique, etc [25].

I.12.1. Applications militaires

Le faible coût et le déploiement rapide sont des caractéristiques qui ont rendu les

réseaux de capteurs efficaces pour les applications militaires. Plusieurs projets ont été

lancés pour aider les unités militaires dans un champ de bataille et protéger les villes

contre des attaques, telles que les menaces terroristes. Le projet DSN (Distributed Sensor

Network) au DARPA (Defense Advanced Research Projects Agency) était l’un des

premiers projets dans les années 80 ayant utilisé les réseaux de capteurs pour rassembler

des données distribuées [25].

I.12.2. Applications à la surveillance

L’application des réseaux de capteurs dans le domaine de la sécurité peut

diminuer considérablement les dépenses financières consacrées à la sécurisation des lieux

et des êtres humains. Ainsi, l’intégration des capteurs dans de grandes structures telles

que les ponts ou les bâtiments aidera à détecter les fissures et les altérations dans la

structure suite à un séisme ou au vieillissement de la structure. Le déploiement d’un

réseau de capteurs de détection de mouvement peut constituer un système d’alarme qui

servira à détecter les intrusions dans une zone de surveillance [26].

I.12.3. Applications environnementales

Le contrôle des paramètres environnementaux par les réseaux de capteurs peut

donner naissance à plusieurs applications. Par exemple, le déploiement des thermo-

capteurs dans une forêt peut aider à détecter un éventuel début de feu et par suite faciliter

la lutte contre les feux de forêt avant leur propagation. Le déploiement des capteurs

chimiques dans les milieux urbains peut aider à détecter la pollution et analyser la qualité

d’air. De même leur déploiement dans les sites industriels empêche les risques industriels



tels que la fuite de produits toxiques (gaz, produits chimiques, éléments radioactifs,

pétrole, etc.) [13].

I.12.4. Applications médicales

Dans le domaine de la médecine, les réseaux de capteurs peuvent être utilisés

pour assurer une surveillance permanente des organes vitaux de l’être humain grâce à des

micro-capteurs qui pourront être avalés ou implantés sous la peau (surveillance de la

glycémie, détection de cancers à l’étape précoce, etc.). Ils peuvent aussi faciliter le

diagnostic de quelques maladies en effectuant des mesures physiologiques telles que: la

tension artérielle, battements du cœur, etc. à l’aide des capteurs ayant chacun une tâche

bien particulière. Les données physiologiques collectées par les capteurs peuvent être

stockées pendant une longue durée pour le suivi d’un patient. D’autre part, ces réseaux

peuvent détecter des comportements anormaux (chute d’un lit, choc, cri, etc.) chez les

personnes dépendantes (handicapées ou âgées) [25].

I.12.5. Applications domestiques

Avec le développement technologique, les capteurs peuvent être embarqués dans

des appareils, tels que les aspirateurs, les fours à micro-ondes, les réfrigérateurs, les

magnétoscopes, etc. Ces capteurs embarqués peuvent interagir entre eux et avec un

réseau externe via internet pour permettre à un utilisateur de contrôler les appareils

domestiques localement ou à distance. Le déploiement des capteurs de mouvement et de

température dans les futures maisons dites intelligentes permet d’automatiser plusieurs

opérations domestiques telles que : la lumière s’éteint et la musique s’arrête quand la

chambre est vide, l’alarme est déclenchée par le capteur anti-intrusion quand un étranger

veut pénétrer dans la maison [25].

I.12.6. Applications commerciales

Il est possible d’intégrer des capteurs au processus de stockage et de livraison

dans le domaine commercial. Le réseau ainsi formé pourra être utilisé pour connaître la

position, l’état et la direction d’un paquet. Il devient alors possible pour un client qui

attend la réception d’un paquet, d’avoir un avis de livraison en temps réel et de connaître

la localisation actuelle du paquet [26].

Pour les entreprises manufacturières, les réseaux de capteurs permettront de

suivre le procédé de production à partir des matières premières jusqu’au produit final

livré. Grâce aux réseaux de capteurs, les entreprises pourraient offrir une meilleure

qualité de service tout en réduisant leurs coûts.



Figure.I.14 : Quelques applications des RCSFs [26]

I.13. Le stockage des données [27] [28]

Le stockage des données présents un défi unique pour les développeurs. Les données

collectées doivent être stocké dans quelques nœuds : localement ou aux nœuds voisins. On a

trois paradigmes de stockage des données pour les RCSFs:

Stockage externe: dans ce modèle, quand un nœud détecte un événement, les données

correspondantes sont transmises à quelques entrepôts externes, tel que la station de base.

Stockage local: quand un nœud détecte un événement, l’information détectée est

stockée localement dans le nœud capteur. L’avantage de cette approche est qu’elle n’implique

pas des coûts de communication initiaux.

Stockage des données central: l’information collectée est routée à une location

prédéfinie, spécifiée par GHT (geographic hash function) à l’intérieur du RCSF. Des requêtes

sont adressées au nœud, contenant l’information pertinente, lequel transmit une réponse au Sink.



I.14. La collection d’information [17]

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

I.14.1. À la demande

Lorsque l’on souhaite avoir l’état de la zone de couverture à un moment T, le

sink (puits) émet des messages vers la zone pour que les capteurs remontent leur dernier

relevé vers le sink. Les informations sont alors acheminées par le biais d’une

communication multi-sauts.

Figure I.15 : Collecte à la demande [17]

I.14.2. Suite à un évènement

Un évènement se produit en un point de la zone de couverture

(changement brusque de température, mouvement...), les capteurs situés à proximité

remontent alors les informations relevées et les acheminent jusqu’au puit.

Figure I.16 : Collecte suite à un événement [17]



I.15. Systèmes embarqués

Les systèmes embarqués sont des systèmes d'exploitation prévus pour fonctionner sur des

machines de petite taille, telles que des nœuds de capteurs. Les systèmes d'exploitation pour les

nœuds de RCSF sont généralement moins complexes que les autres systèmes d'exploitation.

Ceci à cause des exigences particulières des applications de réseau de capteurs et des

contraintes de ressources des nœuds de capteurs. Plusieurs systèmes d'exploitation sont conçus

pour les nœuds de RCSF. Parmi ces systèmes nous citons TinyOS, SOS etc [14].

TinyOS est le plus répondu des systèmes d'exploitation pour les RCSF. TinyOS est un

système d'exploitation open source développé par l'université de Berkeley. Sa conception a été

entièrement réalisée en NesC, langage orienté composant syntaxiquement proche du C. La

bibliothèque des composants de TinyOS est particulièrement complète puisqu'on y retrouve des

protocoles réseaux, des pilotes de capteurs et des outils d'acquisition de données. Un programme

s'exécutant sur TinyOS est constitué d'une sélection de composants systèmes et de composants

développés spécifiquement pour l'application à laquelle il sera destiné (mesure de température,

du taux d'humidité, etc.) [29]. TinyOS s'appuie sur un fonctionnement événementiel, c'est-à-dire

qu'il ne devient actif qu'à l'apparition de certains événements ; par exemple, l'arrivée d'un

message radio. Le reste du temps, le capteur se trouve en état de veille, garantissant une durée de

vie maximale connaissant les faibles ressources énergétiques des capteurs. Cependant,

l'allocation statique de la mémoire et la perte des composants lors de la génération de

l'exécutable, constituent les limites de ce système et rendent la reconfiguration dynamique de

l'image présente sur le capteur impossible [30].

I.16. La pile protocolaire des RCSF

Il est à noter qu’aucune pile protocolaire destinée aux RCSF n’a été standardisée.

Cependant, la majorité des articles scientifiques, qui traitent la thématique des RCSF, se basent

sur la pile protocolaire qui a été proposée par [9].

Cette pile se compose de [9] :

- Une couche physique

- Une couche de liaison de données

- Une couche réseau

- Une couche transport

- Une couche application

- Un plan de gestion d’énergie

- Un plan de gestion de mobilité



- Un plan de gestion de tâches

Figure I.17 : La pile protocolaire d’un RCSF [9]

I.16.1. La couche physique

Elle est responsable de la sélection de fréquence, la génération de la fréquence

porteuse, la détection du signal, la modulation/démodulation et le cryptage/décryptage

des informations. La consommation d’énergie au niveau de la couche physique peut être

affectée par l’environnement de l’application, le choix du type de la modulation ou la

bande de fréquence utilisée. Il est avantageux en matière d’économie d’énergie que le

concepteur de la couche physique choisisse une transmission à multi-sauts plutôt qu’une

transmission directe qui nécessite une puissance de transmission très élevée [9].

I.16.2. La couche liaison de données

Elle est responsable de la détection des trames de données, le contrôle d’accès au

support (MAC) et le contrôle d’erreurs. Elle maintient aussi la fiabilité des connections

point à point ou multipoints dans les RCSF [9].

La couche liaison de données contient deux sous-couches qui sont :

- La sous-couche MAC : Dans un RCSF, la couche MAC doit accomplir deux

principales tâches qui sont celles de :

- établir des liaisons de communication entre les nœuds capteurs pour effectuer

le transfert des données et permettre au réseau la capacité de s’auto-organiser.

- décider du moment et de la manière dont les nœuds capteurs peuvent accéder

au canal avec un minimum de perte d’énergie [9].

- La sous-couche de contrôle d’erreurs : La technique de contrôle d’erreurs la

plus utilisée dans les RCSF est le « Forward error correction » (FEC) ; Cette technique

comporte de simples mécanismes de codage et de décodage (codes de contrôle d’erreurs

simples) [9].



I.16.3. La couche réseau

La couche réseau gère les échanges (et éventuellement les connexions) au

travers du RCSF. Elle gère entre autre l’adressage et l’acheminement des données. Les

applications des RCSF requièrent le plus souvent des protocoles de routage à multi sauts

entre le nœud émetteur, le ou les nœuds relais et le nœud « Sink ». Les protocoles de

routage traditionnels des réseaux ad hoc ne peuvent pas être utilisés dans les RCSF

puisqu’ils ne satisfont pas les critères de conservation d’énergie et de scalabilité [31].

Les métriques considérées par les chercheurs pour déterminer la route la plus

optimisée dans les réseaux RCSF sont [31]:

- L’énergie nécessaire pour transmettre le paquet d’une manière fiable.

- L’énergie disponible dans chaque nœud capteur.

Les algorithmes de routage peuvent alors sélectionner les routes entre le nœud

émetteur et le nœud «Sink» en se basant soit sur le maximum d’énergie disponible au

niveau des nœuds intermédiaires, soit sur la route qui consomme le moins d’énergie pour

transmettre d’un nœud vers un autre. Le type d’adressage le plus utilisé dans les RCSF

est l’adressage géographique, c'est-à-dire que chaque nœud capteur est identifié dans le

réseau par sa localisation [31].

I.16.4. La couche transport

Le rôle de cette couche intervient essentiellement lorsqu’on va accéder à partir

de notre RCSF vers un autre RCSF ou vers l’internet [31].

Le protocole de transport utilisé entre le nœud émetteur et le nœud « Sink » peut

être UDP. Il importe de mentionner que l’utilisation du protocole TCP est impossible vu

la taille limitée des mémoires des nœuds capteurs qui ne leur permet pas d’enregistrer de

grandes quantités d’informations pour la gestion des communications (mécanismes de

fenêtres) [31].

I.16.5. La couche application

Il existe plusieurs protocoles applicatifs qui ont été proposés et qui permet à

l’utilisateur d’exécuter des tâches administratives telles que la configuration du RCSF, la

mise en marche/fermeture des nœuds, la synchronisation entre les nœuds, le déplacement

des nœuds capteurs [9].

En plus il y a des protocoles qui permet à l’utilisateur à travers des interfaces

d’interroger le réseau en se basant non pas sur un système d’adressage particulier



(interroger un nœud bien particulier) comme tel est le cas des réseaux sans fil classiques

mais plutôt sur la localisation des nœuds [9].

I.17. Classification des protocoles de routages pour les réseaux de

capteur sans fil

Figure I.18 : Classification des protocoles de routage pour les Réseaux de capteurs sans fil [5]

Classification

des protocoles

de routage pour

les RCSFs

Topologie du

Réseau

Fonctionnement

du protocole

Paradigme de

communication

Etablissement

de la route

Plat

Hiérarchique

Basé-QoS

Basé-

négociation

Multi-

chemins

Basé-

requêtes

Centré-

données

Centré-

nœuds

Basé-

localisation

Réactif

Proactif

Hybride

SPIN, DD, RR

LEACH, PEGASIS,

MECN, SMECN,

TEEN, APTEEN

SAR

DD

SPIN

DD, RR

SPIN, DD

LEACH, PEDAP

GAF, GEAR

SPIN , DD,

LEACH, PEGASIS

APTEEN



I.17.1. Selon la topologie du réseau

La topologie détermine l'organisation des capteurs dans le réseau. Comme on a

dit précédemment Il existe deux principales topologies dans les protocoles de routage

pour les RCSF : Plate et hiérarchique [18].

I.17.2. Selon le fonctionnement du protocole

C’est la manière avec laquelle les données sont propagées dans le réseau. Selon

ce critère, les protocoles de routage peuvent être classifiés en quatre catégories :

I.17.2.1. Routage basé sur les multi-chemins

Dans cette catégorie, les protocoles de routage utilisent des chemins

multiples plutôt qu’un chemin simple afin d’augmenter la performance du réseau. La

fiabilité d’un protocole peut être mesurée par sa capacité à trouver des chemins

alternatifs entre la source et la destination en cas de défaillance du chemin primaire.

Pour cette raison, certains protocoles requièrent plus de ressources énergétiques et

plus de messages de contrôle [5].

I.17.2.2. Routage basé sur les requêtes

Dans ce type de routage, le puits génère des requête afin d’interroger les

capteurs. Ces requêtes sont exprimées soit par un schéma valeur-attribut ou bien en

utilisant un langage spécifique (par exemple SQL : Structured Query Langage). Les

nœuds qui détiennent les données requises doivent les envoyer au nœud demandeur à

travers le chemin inverse de la requête. Les requêtes émises par le puits peuvent

aussi être ciblées sur des régions spécifiques du réseau [6].

I.17.2.3. Routage basé sur la négociation

En détectant le même phénomène, les nœuds capteurs inondent le réseau

par les mêmes paquets de données. Ce problème de redondance peut être résolu en

employant des protocoles de routage basés sur la négociation. En effet, avant de

transmettre, les nœuds capteurs négocient entre eux leurs données en échangeant des

paquets de signalisation spéciales, appelés métadonnées. Ces paquets permettent de

vérifier si les nœuds voisins disposent déjà de la donnée à transmettre. Cette

procédure garantit que seules les informations utiles seront transmises et élimine la

redondance des données [5].

I.17.2.4. Routage basé sur la qualité de service

Dans les protocoles de routage basés sur QoS, le réseau doit équilibrer

entre la consommation d’énergie et la qualité de données. En particulier, le réseau



doit satisfaire certaines métriques de QoS, par exemple, retard, énergie, largeur de

bande passante, etc. Les protocoles de cette approche sont très recommandés pour les

applications de surveillance (Centre nucléaires, application militaires, etc) [5].

I.17.3. Selon le Paradigme de communication [20]

Dans les RCSF, il existe trois paradigmes de communication :

I.17.3.1. Centré-nœud (Node centric)

Ce paradigme est celui employé dans les réseaux conventionnels, où les

communications se basent sur l'identification des nœuds participants.

I.17.3.2. Centré-données (Data centric)

Dans un RCSF, la donnée est plus importante que le nœud lui-même, ce

qui rend son identification inutile. Dans le paradigme data centric, les communicants

sont identifiés par leurs données, et donc tout le système (routage, interrogation, . . .

etc.) doit être régit par cette propriété. Ainsi, le système peut être vu comme une base

de données distribuée, où les nœuds forment des tables virtuelles, alimentées par les

données captées.

I.17.3.3. Basé-localisation (Position centric)

Dans cette approche, les positions des nœuds représentent le moyen

principal d'adressage et de routage. Dans certaines applications, il est plus intéressant

d'interroger le système en utilisant les positions des nœuds. Dans ce cas, le routage

s'effectue grâce à des techniques géométriques afin d'acheminer l'information d'une

zone géographique vers une autre.

I.17.4. Selon le mode de l’établissement de chemins

I.17.4.1. Les protocoles proactifs

Dans les protocoles proactifs les routes sont établies à l'avance. Pour cela

chaque nœud relais envoie périodiquement à tous ses nœuds voisins, sa table de

routage contenant l'état de tous ses liens. Les sous ensemble du réseau possèdent

alors assez d'information pour trouver le meilleur chemin jusqu'à tout autres éléments

dans le réseau [32].

I.17.4.2. Les protocoles réactifs

Contrairement aux protocoles proactifs, les tables de routages des nœuds

ne sont plus envoyés périodiquement, mais seulement à la demande, lorsque du trafic

utilisateur doit être acheminé vers une destination vers laquelle un chemin n'est pas

connu à ce moment-là. Dans ce cas, une requête pour établir un tel chemin est diffusé



dans tout le réseau [32]. La destination (ou un nœud connaissant un chemin vers la

destination) recevra alors cette requête diffusée, et pourra y répondre pour établir un

chemin, envoyant une réponse prenant le chemin pris depuis la source de la requête.

La connaissance de ce chemin sera maintenue dans le réseau tant que le trafic

utilisateur l'empruntera, puis disparaîtra une fois les informations transmises [5].

I.17.4.3. Les protocoles hybrides

Ils exploitent les avantages des deux protocoles évoqués ci-dessus. Ils

fonctionnent le mode proactif pour garder la connaissance locale de la topologie :

l'Intra-zone Routing Protocol (IARP). Ils utilisent le mode réactif pour les nœuds

lointains : l'Interzone Routing Protocol (IERP). On a donc un routage à deux niveaux

avec l'utilisation de zones qui permet d'optimiser la diffusion des requêtes de

demande de « route » [32].

I.18. Conclusion

Les RCSF possèdent des caractéristiques particulières qui les différencient des autres

types de réseaux sans fil. La réalisation des réseaux de capteurs ou la mise en place d'une

application de réseau de capteurs doit satisfaire les contraintes qui caractérisent les nœuds

capteurs tel que: la consommation d'énergie, les contraintes physiques, le changement de la

topologie et l'adaptation à l'environnement, etc. Ces contraintes exigent que de nouvelles

techniques d’administration de réseau sans-fil soient mises au point c'est-à-dire des approches de

supervision pour maintenir le réseau opérationnelle plus longtemps possible tout en gardant une

connectivité dans le réseau (réseau connexe) et une meilleur couverture de la zone.

Chapitre II L’ADMINISTRATION DES RESEAUX


II.1. Introduction

Vers la fin des années 70, les petits réseaux isolés évoluèrent vers des grands réseaux

inter connectés [5]. Ils deviennent de plus en plus difficiles à gérer.

Une machine informatique, quelle que soit sa fonction, a généralement beaucoup de choses à

dire. Elle le dit le plus souvent discrètement, si bien que peu de gens l'entendent. Par exemple,

lorsqu'elle est en surchauffe, un écran bleu pour Windows, Le reste du temps, elle chuchote

divers indicateurs d'état, et certaines remarques, qu'elle consigne généralement dans les "logs",

sorte de journaux intimes, que, finalement, assez peu de gens consultent.

Les administrateurs sont les seuls à s'y intéresser. Vous serez peut-être surpris de voir à

quel point votre machine vous parle. Il y a une foule d'informations qui intéressent les

administrateurs et dont ils aimeraient disposer à distance via le réseau. Il est clair que lorsque le

parc contient plusieurs centaines de machines, c'est tout de même plus agréable de disposer de

toutes les informations en temps réel et de façon centralisée. De plus, l'administrateur peut

apprécier de pouvoir régler tel ou tel paramètre sans avoir à se déplacer sur le site de la machine

concernée. Un protocole de gestion est nécessaire pour exercer les fonctions de gestion sur un

réseau, c’est exactement conçu pour répondre à tous ces besoins.

II.2. La gestion de réseau La gestion des réseaux informatiques constitue un problème dont l’enjeu est de garantir

au meilleur coût non seulement la qualité du service global rendu aux utilisateurs mais aussi la

réactivité face aux besoins de changement et d’évolution. La gestion des réseaux informatiques

se définit comme étant l’ensemble des moyens mis en œuvre (connaissances, techniques,

méthodes, outils) pour superviser, exploiter des réseaux informatiques et planifier leur évolution

en respectant les contraintes de coût et de qualité [33]. La qualité de service se décline sur

plusieurs critères, du point de vue de l’utilisateur final, notamment la disponibilité, la

performance (temps de réponse), la fiabilité et la sécurité [34]. Les activités d’administration sont communément classées en activités de :

Supervision qui consiste à surveiller les systèmes et à récupérer les informations sur

leur état et leur comportement, ce qui peut être fait par interrogation périodique ou

par remontée non sollicitée d’informations de la part des équipements de réseaux

eux-mêmes.

Administration qui désigne plus spécifiquement les opérations de contrôle du réseau

avec la gestion des configurations et de la sécurité,



Exploitation qui désigne l’ensemble des activités permettant de traiter les problèmes

opérationnels sur le réseau : maintenance, assistance technique [34].

II.3. Principe général

Sur le point de l’administration, un système de réseau informatique se compose d’un

ensemble d’objets qu’un système d’administration surveille et contrôle. Chaque objet est géré

localement par un processus appelé agent qui transmet régulièrement ou sur sollicitation les

informations de gestion relatives à son état et aux événements qui le concernent au système

d’administration [34].

Le système d’administration comprend un processus (manager ou gérant) qui peut

accéder aux informations de gestion de la MIB locale via un protocole d’administration comme

SNMP ou CMIP qui le met en relation avec les divers agents [33].

Le principe se repose donc sur les échanges :

D’une part, entre une base d’informations appelée MIB(Management

Information Base) et l’ensemble des éléments administrés (objets) ;

D’autre part, entre les éléments administrés et le système d’administration [33].

Figure II.1 : Structure fonctionnelle d’administration du réseau [33]

Une grande majorité des logiciels de supervision sont basés sur le protocole SNMP qui

existe depuis de nombreuses années [34].

La plupart de ces outils permettent de nombreuses fonctions dont voici les principales :

Surveiller le système d’information

Visualiser l’architecture du système



Analyser les problèmes

Déclencher des alertes en cas de problèmes

Effectuer des actions en fonction des alertes [33]

La tâche de l’administrateur est alors simplifiée. Il n’a plus qu’à faire une vérification ou

réaliser une action en fonction d’une alerte déclenchée. Chaque outil doit aussi lui donner une

vision globale du système d’information pour localiser les problèmes le plus rapidement possible

[34].

II.4. Le concept de supervision du réseau

La supervision du réseau a pour but de surveiller le bon fonctionnement.

Ce concept est né au début des années 1980, lors de l’explosion de la mise en place de

réseaux informatiques dans les entreprises. La taille grandissante de ceux-ci ainsi que leur

hétérogénéité posaient un réel problème de gestion et d’administration, multipliant les besoins en

main d’œuvre d’experts administrateurs [33].

C’est donc à cette époque qu’ont été menées les premières réflexions sur un nouveau

concept, celui de la supervision.

La supervision devait être capable de s’adapter à des milieux hétérogènes, d’automatiser

le contrôle des réseaux et de générer un ensemble de statistiques donnant une meilleure vision du

réseau, permettant par là-même d’anticiper les besoins de celui-ci.

La supervision peut ainsi se définir comme étant l’utilisation de ressources réseaux

adaptées (matérielles ou logicielles) afin d’obtenir des informations sur l’utilisation et sur l’´état

des réseaux et de leurs composants (logiciels, matériels) [33] [35].

Ces informations peuvent alors servir d’outils pour gérer de manière optimale

(automatique si possible) le traitement des pannes ainsi que la qualité des réseaux (problèmes de

surcharge). Elles permettent également de prévoir toute future d’évolution nécessaire.

La supervision est capable de diagnostiquer et bien souvent de réparer les pannes. Si ce

n’est pas le cas, elle se charge d’alerter immédiatement les personnes concernées par l’incident.

Elle est donc extrêmement réactive et représente un gain important en temps [35]. De plus, par sa

vision continue du réseau, elle anticipe souvent sur des problèmes ultérieurs. On parle alors de

proactivité. Ainsi, la supervision est à la fois réactive et proactive. C’est pourquoi, petit à petit, la

supervision s’impose dans la plupart des entreprises possédant un parc informatique conséquent

[34].



II.5. Structure d’un système d’administration

Un réseau comporte un grand nombre de composants (objets) que le système

d’administration surveille. Dans chaque objet, un programme en tâche de fond transmet

régulièrement, ou sur sollicitation, les informations relatives à son état [3].

Les échanges s’effectuent à deux niveaux : entre le composant administré (Processus

agent) et sa base d’information (MIB, Management Information Base) d’une part, et d’autre part,

entre le composant et le programme d’administration (Processus manager).

Le modèle de référence OSI a contribué au développement de réseaux hétérogènes. Cette

hétérogénéité se traduit par l’interconnexion de matériels issus de constructeurs différents (Bull,

IBM, DEC, HP, etc.) et par l’interconnexion de réseaux de différents types, par exemple un

réseau grande distance (X.25 ou autre) relié à un réseau local (Ethernet, etc.).

L’échange d’informations entre les systèmes hétérogènes a été rendu possible par

l’intermédiaire de la normalisation de l’ISO. De plus, dans son rôle de transporteur de

l’information, un réseau doit garantir une certaine qualité de service (débit, temps de réponse,

etc.) à ses utilisateurs. Afin d’assurer une qualité de service, il est nécessaire de gérer

convenablement de multiples composants (nœud, ligne, abonné, application, etc.) [36].

Cette gestion est à la charge des entités de gestion. L’ensemble de ces entités et leurs

activités constituent la gestion de réseau. Chaque fournisseur de réseau propose des outils

permettant de mettre en place une telle gestion. Toutefois, la répartition de ces fonctions par

rapport aux sept couches du modèle OSI est entièrement à l’appréciation du constructeur.

Les deux architectures qui se sont développées en premier, il y a une vingtaine d’années,

proviennent du modèle internet, avec SNMP, et du modèle de référence OSI (Open System

Interconnexion) normalisé par l’ISO. Le modèle OSI est aujourd’hui en chute libre, mais il reste

un modèle au même titre que le modèle de référence. Au contraire, SNMP a pris totalement le

devant de la scène [37] en se présentant sous diverses formes que nous allons étudier dans ce

chapitre.



II.6. Fonctions de base de la gestion de réseau

Suivant le type de système, les tâches de gestion varient et doivent donc être identifiées et

analysées. Des services et des protocoles de gestion sont nécessaires pour gérer les ressources

logicielles et matérielles d’un réseau [34].

L’identification et la mise en œuvre des tâches de gestion sont complexes en raison de la

nature distribuée du système. On peut citer les fonctions suivantes :

• Démarrage et arrêt du réseau : fonction de base liée à la configuration du réseau et à

l’initialisation des paramètres [34].

• Traitement des alarmes : permet au réseau de réagir à n’importe quel

dysfonctionnement, comme la perte du contrôle d’accès [34].

• Redémarrage du réseau : nécessaire à la reprise d’activité suite à une panne du

coupleur, d’une liaison, etc [34].

• Reconfiguration du réseau : fonction liée à l’ajout ou à la suppression de points

d’accès de terminaux. Par exemple, des éléments du réseau doivent pouvoir être mis hors

circuit en cas de mauvais fonctionnement [33].

• Contrôle de la qualité : fonction liée aux techniques de contrôle, aux caractéristiques

opérationnelles du réseau et à la gestion des rapports de changement d’états.

Les moniteurs de gestion peuvent être matériels ou logiciels. Les moniteurs matériels

s’occupent des phénomènes rapides, tandis que les moniteurs logiciels sont plutôt

orientés application [33].

Les moniteurs de gestion doivent prendre en charge les fonctions suivantes :

• Tests et diagnostics : les erreurs du système doivent être détectées. Un message de

diagnostic peut être émis pour signaler qu’une erreur s’est produite et qu’un traitement

peut avoir lieu. On doit pouvoir mettre un élément du système en état de diagnostic afin

d’exécuter des séquences de tests.

• Compte rendu d’alarmes : fonction destinée à notifier à l’opérateur du système tout

mauvais fonctionnement.

• Contrôle du réseau : fonction liée à l’allocation et à la désallocation des ressources et à

leur contrôle (prévention des abus et des famines, manque de ressource, etc.). Le système

de gestion peut contrôler tous les changements. Il est aussi responsable des allocations de

noms et d’adresses et des associations entre elles [37].



II.7. Structure des informations d’administration de réseaux (SMI)

En complément du standard MIB qui définit les informations spécifiques

d’administration réseaux et leur signification, un standard séparé spécifie l’ensemble des règles

utilisées pour définir et identifier les variables MIB. Ce sont les règles de gestion des

informations d’administration, SMI (Structure of Management Information) [36]. Pour que le

protocole d’administration de réseaux reste simple, SMI pose des restrictions sur les types de

variables autorisées dans la MIB, spécifie les règles de nommage de ces variables et crée les

règles de définition des types de variables. Par exemple: SMI comprend des définitions de termes

comme IpAddress (défini comme une chaîne de 4 octets) et Counter (entier appartenant à

l’intervalle [0,2e32-1]) et indique que ce sont les termes utilisés pour définir les variables MIB.

De plus, SMI décrit la façon dont la MIB référence les tables de valeurs (les tables de routage IP,

par exemple) [3].

II.7.1. Définitions formelles utilisant ASN.1

Le standard SMI indique que toutes les variables MIB doivent être définies et

référencées à l’aide de la notation ISO de syntaxe abstraite ASN.1 (Abstract Syntax

Notation 1). ASN.1 est un langage formel qui présente 2 caractéristiques principales: une

notation utilisée dans les documents manipulés par les humains et une représentation codée

et concise de la même information, utilisée dans les protocoles de communication [38].

Dans les 2 cas, la notation formelle élimine toutes les ambiguïtés possibles, tant du point

de vue de la représentation que de la signification. Au lieu de dire par exemple, qu’une,

variable contient une valeur entière, un concepteur qui utilise ASN.1 doit définir la forme

exacte et le domaine des valeurs prises par cet entier [36].

II.8. Les différents aspects de la supervision des réseaux

Un utilisateur qui accède à un service informatique, comme par exemple une simple

consultation d’une page web de l’intranet, met en œuvre de nombreux mécanismes et doit réunir

toutes les bonnes conditions. Tout d’abord les lignes de communications ne doivent pas être

engorgées. Les éléments actifs établissant le chemin ainsi que la machine fournissant le service

doivent être opérationnels et le service concerné doit être disponible. Le schéma ci-dessous

retrace les différents points clés, garants de l’accessibilité d’un service [37].



Figure II.2 : Accès à un service distant [37]

Nous voyons donc se distinguer deux axes majeurs de la supervision de réseau au sens

général : L’analyse de flux et la supervision des équipements et des services.

II.8.1. L’analyse de flux

L’analyse de flux consiste à connaître l’activité en temps réel sur les lignes

réseaux. Les buts sont à la fois d’identifier les liaisons saturées et d’identifier l’origine de

ce dernier sur l’utilisation des ressources [37]. De plus, à travers des statistiques, les

dirigeants peuvent décider de l’augmentation des débits des lignes qui sont trop faibles.

Tout cela joue un rôle déterminant dans la stratégie de développement de l’entreprise.

En général les informations recherchées sont des classements par nombre de

paquets transmis par les utilisateurs ou par application et par protocoles. Ceci permet

d’identifier les causes principales de la saturation constatée [3].

II.8.2. La supervision applicative : état des services

La supervision applicative, longtemps ignorée, et aujourd’hui au cœur des

préoccupations d’entreprises. Le principe de cette supervision est différent de celui vu

avec SNMP. La supervision applicative consiste surveiller en testant régulièrement les

services qui tournent sur les machines serveurs des réseaux. La nouveauté est de se placer

du point de vue de l’utilisateur final du service. En effet, même si tous les liens réseau

sont en bon état de fonctionnement, le programme responsable d’un service peut en

revanche être interrompu ou perturbé [3]. SNMP ne permet pas de savoir par exemple, si

le FTP est ouvert, si le serveur web renvoie bien la page. C’est ce que propose de faire les

outils de supervision applicative. La station d’administration va régulièrement tester et

mesurer la qualité des services en les sollicitant comme le ferait un utilisateur. Nous

pouvons connaître ainsi le temps que met le serveur web à nous retourner la page, savoir

si le serveur DNS traite bien les requêtes qui lui parviennent, le temps de réponse aux



pings des différents routeurs. Là encore une interface permet d’administrer le tout, de

visualiser l’état des services ou encore de remonter des alertes aux administrateurs [37].

II.8.3. La supervision SNMP : l’état des équipements

SNMP est le protocole de référence en matière de supervision. Il permet à un

serveur central de communiquer avec tous les équipements et les serveurs pour connaître

l’état de très nombreux paramètres tels que la température dans le châssis de la machine,

l’état des interfaces, des ports, le taux d’utilisation CPU… Ce protocole permet

également au serveur central (appelé station d’administration SNMP), de récupérer toutes

les alertes SNMP (les traps) émises par les éléments actifs ou serveurs supervisés. Une

interface permet généralement d’administrer l’ensemble des machines et de visualiser

leurs états en temps réel [39].

II.9. Les protocoles de gestion réseau

Pour interconnecter deux systèmes de gestion, une norme doit être respectée, qu’elle que

soit le droit ou le fait. Dans les normes de droit, on retrouve la normalisation provenant de l’ISO,

que l’on appelle CMIS/CMIP, et celle de l’UIT-T, qui porte le nom de TMN

(Telecommunications Management Network), en français RGT (réseau de gestion des

télécommunications). Ces deux normes ne sont pas vraiment concurrentes mais plutôt

complémentaires [40]. La norme la plus utilisée est SNMP (Simple Network Management

Protocol), qui provient de l’environnement de l’internet. Les grands constructeurs ont, quant à

eux, développé des plates-formes qui permettent d’avoir :

• un service de transport entre les différents processus applicatifs ;

• des adaptateurs de protocoles traduisant les messages échangés ;

• des piles de protocoles de communication ;

• des services supplémentaires internes, comme les annuaires [41].

II.9.1. Historique des protocoles d’administration

Avant 1987/1988 il n'y a rien d'autre que ICMP pour recevoir les informations

entres routeurs et hôtes. Le couple ('' echo request,echo reply '') est le plus utilisé pour

maintenir un état des machines accessibles [42].

Le point de départ est SGMP ('' Simple Gateway Monitoring Protocol '' RFC 1028

de novembre 1987) mais trop orienté sur la gestion des routeurs. Du côté de l'OSI d'autres

tentatives avec CMIS et CMIP ('' Common Management Information Service & Protocol '') ;

Le CMIP est un protocole proposé par l’ISO supérieur au SNMP tant aux niveaux design et



sécurité, mais il est très difficile à mettre en œuvre et sa complexité exige des appareils assez

performants, il est trop lourdes à mettre en œuvre [35].

SNMP est sorti en 1988, comme une version améliorée de SGMP. Les RFCs

fondatrices sont les 1155, 1156 et 1157 conservées actuellement au rang d'historiques bien

que tous les équipements soient théoriquement encore compatibles SNMPv1 (même s'ils

répondent à un niveau de version SNMP plus récent, c'est à dire 2 ou 3). SNMP est un

protocole très populaire et ces paquets de données sont assez simples. Pourtant l'ensemble de

ses fonctionnalités est suffisamment puissant pour permettre la gestion des réseaux

hétérogènes complexes [43] [44].

II.10. L’administration vue par la norme ISO

L’ISO ne spécifie aucun système d’administration de réseau, elle définit un cadre

architectural général (ISO 7498-4, OSI Management Framework) et un aperçu général des

opérations de gestion des systèmes (ISO 10040, OSI System Management) [40].

II.10.1. Les différents modèles

II.10.1.1. Le modèle architectural

Le modèle architectural définit trois types d’activité : la gestion du

système (System Management), la gestion de couche (Layer management) et les

opérations de couche (Layer Operation) [3]. La gestion du système (SMAE, System

Management Application Entity) met en relation deux processus : un processus

gérant et un processus agent. L’agent gère localement un ensemble de ressources

locales (équipements, protocoles...) sous le contrôle de l’agent gérant [40].

Figure II.3 : Le modèle architectural d’administration par l’ISO [40]



La gestion système repose sur des échanges verticaux entre couches

(CMIS, Common Management Information Service). CMIS (ISO 9595) définit les

primitives d’accès aux informations. Ces primitives assurent le transfert

d’information vers les applications de gestion (SMAP, System Management

Application Process) non spécifiées par l’ISO [41].

La gestion de couche, ou protocole de gestion de couche, fournit les

moyens de transfert des informations de gestion entre les sites administrés, c’est un

dialogue horizontal (CMIP, Common Management Information Protocol, ISO 9596).

Les opérations de couche (N), ou protocole de couche (N), supervisent une

connexion de niveau N. Ces opérations utilisent les protocoles OSI classiques pour le

transfert d’information. CMIP utilise les primitives de service suivantes (CMISE,

Common Management Information Service Element) :

Get : cet élément de service est utilisé par le gérant pour lire la valeur d’un

attribut ;

Set : fixe la valeur d’un attribut ;

Event : permet à un agent de signaler un événement ;

Create : génère un nouvel objet ;

Delete : permet à l’agent de supprimer un objet [33].

II.10.1.2. Le modèle informationnel

Le standard OSI décrit une méthode de définition des données

d’administration qui modélise la représentation des informations et qui fournit un

ensemble de directives pour garantir la cohérence de la base (SMI, Structure of

Management Information) [40].

La représentation des éléments gérés (objets gérés) est orientée objet, les

classes et occurrences d’objets sont représentées selon un arbre. Les classes sont

rattachées à un arbre d’héritage (Inheritance tree), les occurrences d’objets à un arbre

dit contenance (Containment tree). Un objet est décrit par sa classe d’appartenance,

son nom, ses attributs et les types d’opération qu’il supporte.

L’ensemble des objets gérés constitue la MIB (ISO 10165). La MIB

contient toutes les informations administratives sur les objets gérés (ponts, routeurs,

cartes...). La norme ne spécifie aucune organisation particulière des données. Celles-

ci peuvent y être organisées selon une structure en ligne, une base de données. Seul,



le processus agent a accès à la MIB. Le processus manager accède aux données via le

processus agent [41].

II.10.1.3. Le modèle fonctionnel

Ce modèle, plus concret que les précédents, définit des domaines

fonctionnels d’administration et leurs relations. Cinq domaines ou fonctions (aires

fonctionnelles) y sont décrits [3] :

Figure II.4 : Les fonctions d’administration [3]

Gestion des performances (Performance Management) :

La gestion des performances analyse de manière continue les performances du réseau

afin de le maintenir dans un état de performance acceptable. Cette gestion s’opère en

trois étapes. Tout d’abord, des variables contenant des informations significatives

quant aux performances du réseau sont récupérées. Parmi celles-ci on peut citer le

temps de réponse d’une station utilisateur ou encore le taux d’occupation d’un

segment réseau. Une fois ces variables obtenues, elles sont analysées. Si elles

dépassent un seuil de performance fixé préalablement, une alarme est tout de suite

envoyée à l’administrateur du réseau, pour régler le problème au plus vite. Ces

variables de gestion de performances sont réactualisées à court intervalle de temps

dans le but d’être le plus réactif possible au moindre embryon de baisse de

performance. La gestion des performances permet donc une évaluation du

comportement des ressources et un contrôle de l’efficacité des activités de

communication.

Gestion des configurations (Management Configuration) :

La gestion des configurations effectue un suivi des différentes configurations des

éléments présents sur le réseau. Elle stocke dans une base de données les versions

des systèmes d’exploitation et des logiciels installés sur chaque machine du parc

réseau. Par exemple pour un ordinateur du réseau, la base contiendra la version de



son OS, du protocole TCP/IP, etc. La gestion des configurations permet donc une

identification et un contrôle des systèmes ouverts. Elle collecte et fournit des

informations sur les différents systèmes du réseau.

Gestion de la comptabilité (Accounting Management) :

La gestion des comptabilités a pour but de mesurer l’utilisation des ressources afin de

réguler les accès et d’instaurer une certaine équité entre les utilisateurs du réseau.

Ainsi des quotas d’utilisation peuvent être fixes temporairement ou non sur chacune

des ressources réseaux. De plus, la gestion des comptabilités autorise la mise en

place de systèmes de facturation en fonction de l’utilisation pour chaque utilisateur.

Elle donc un établissement des coûts d’utilisation ainsi qu’une facturation de

l’utilisation des ressources.

Gestion des anomalies (Fault Management) :

La gestion des anomalies détecte les problèmes réseaux (logiciels ou matériels). Elle

essaie d’isoler le plus précisément le problème en effectuant divers tests. Quand cela

est possible, elle règle elle-même automatiquement l’anomalie. Si non, elle alerte les

personnes concernées par le type du problème afin de solliciter leur intervention. La

gestion des anomalies garde dans une base de données l’ensemble des problèmes

survenus ainsi que leur solution, de manière à être encore plus efficace face à un

incident récurrent. Cette fonction de la norme ISO7498/4 demeure de loin la fonction

la plus implémentée à ce jour. Elle détecte donc et corrige les fonctionnements

anormaux des éléments du réseau.

Gestion de la sécurité (Security Management) :

La gestion de la sécurité contrôle l’accès aux ressources en fonction des politiques de

droits d’utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne

puissent accéder à certaines ressources protégées. Elles mettent donc en application

les politiques de sécurité.

II.11. L’administration dans l’environnement TCP/IP

II.11.1. Présentation générale de protocole SNMP

SNMP (Simple Network Management Protocol) est le protocole de gestion de

réseaux proposé par l'IETF (Internet Engineering Task Force) dans la RFC 1157 . Il

fonctionne à la couche d'application pour échanger des informations de gestion entre les

périphériques réseau. , Il représente une méthode de communication entre les différents

http://www.ietf.org/rfc/rfc1157.txt



dispositifs de réseautage et un gestionnaire central pour une utilisation avec la surveillance et

la gestion de ces dispositifs [35] [36].

SNMP est un protocole de la famille TCP/IP (Internet protocol), et peut donc être

utilisé sur tous les réseaux de type Internet et exploite les capacités du protocole de transport

UDP [39].

II.11.2. Les différentes versions de SNMP

SNMPv1 (ancien standard): Ceci est la première version du protocole. On dit

que la sécurité de cette version est triviale, car la seule vérification qui est faite est

basée sur la chaîne de caractères " community ". SNMPsec (historique): Cette

version ajoute de la sécurité au protocole SNMPv1. La sécurité est basée sur des

groupes. Très peu ou aucuns manufacturiers n'a utilisé cette version qui est

maintenant largement oubliée [45].

SNMPv2p (historique): Beaucoup de travaux ont été exécutés pour faire une

mise à jour de SNMPv1. Ces travaux ne portaient pas seulement sur la sécurité. Le

résultat est une mise à jour des opérations du protocole, des nouvelles opérations,

des nouveaux types de données. La sécurité est basée sur les groupes de SNMPsec

[46].

SNMPv2c (expérimental): Cette version du protocole est appelé " community

stringbased SNMPv2 ". Ceci est une amélioration des opérations de protocole et

des types d'opérations de SNMPv2p et utilise la sécurité par chaîne de caractères

"community " de SNMPv1 [47].

SNMPv2u (expérimental): Cette version du protocole utilise les opérations, les

types de données de SNMPv2c et la sécurité basée sur les usagers.

SNMPv2* (expérimental): Cette version combine les meilleures parties de

SNMPv2p et SNMPv2u[47].

SNMPv3 (standard actuel): Cette version comprend une combinaison de la

sécurité basée sur les usagers et les types et les opérations de SNMPv2p, avec en

plus la capacité pour les " proxies ". La sécurité est basée sur ce qui se trouve dans

SNMPv2u et SNMPv2* [48] [49].

Actuellement, les versions les plus utilisées sont (par importance d'utilisation) :

SNMPV1, SNMPV3 et SNMPV2c. Le fait que la version 1 de SNMP perdure de nos jours

s'explique par plusieurs facteurs : d'une part, les infrastructures déployées en version 1 ne sont

plus modifiées sous prétexte que l'on ne modifie pas quelque chose qui fonctionne ; d'autre

http://www.frameip.com/rfc/rfc1155.php





part, les nouvelles versions de SNMP ont été implémentées avec beaucoup de retard par les

différents équipementiers ; et enfin, le protocole SNMPv1 est un protocole très simple qui

demande peu de ressources lors de son implantation sur un petit équipement (une imprimante

ou un hub par exemple) [49].

II.11.3. Architecture globale

Les buts du protocole SNMP sont de :

• connaître l'état global d'un équipement (actif, inactif, partiellement

opérationnel...);

• gérer les évènements exceptionnels (perte d'un lien réseau, arrêt brutal d'un

équipement...);

• analyser différents métriques afin d'anticiper les problèmes futurs (engorgement

réseau...);

• agir sur certains éléments de la configuration des équipements [48].

• Les différents éléments que l'on peut identifier avec le protocole SNMP sont

synthétisés par le schéma ci-dessous [49].

Figure II.5 : L’environnement SNMP [49]

• Les agents SNMP : ce sont les équipements (réseau ou serveur) qu'il faut

superviser.

• Le superviseur SNMP : c'est une machine centrale appelée Network Management

Station (NMS), à partir de laquelle un opérateur humain peut superviser en temps

réel toute son infrastructure, diagnostiquer les problèmes et finalement faire

intervenir un technicien pour les résoudre.



• Le protocole SNMP : c'est le protocole utilisé par les agents SNMP et leur

superviseur pour communiquer entre eux.

• La MIB : ce sont les informations dynamiques instanciées par les différents agents

SNMP et remontées en temps réel au superviseur.

• Les outils SNMP. Ce sont les différents utilitaires utilisés par le superviseur pour

l'aider à diagnostiquer un problème. Ces différents outils sont aussi utilisés lors de

la configuration du superviseur pour prendre en compte les spécificités de

l'infrastructure [44].

II.11.4. Principe de fonctionnement

Le protocole SNMP se base sur le fait qu’il existe une station de gestion réseau, le

manageur, dont le rôle est de contrôler le réseau et de communiquer via ce protocole avec un

agent. L’agent est de manière générale une interface SNMP embarquée sur le matériel destiné

à être administré à distance [36].

Figure II.6 : Base de SNMP [36]

Le protocole UDP fonctionne en mode non connecté, c’est-à-dire qu’il n’existe pas

de lien persistant entre la station d’administration et l’agent administré. Cela oblige les deux

parties à s’assurer que leurs messages soient bien arrivés à la destination, ce qui apporte

également un important gage de fiabilité pour la gestion de réseau [36].

D’une manière générale nous distinguons deux modes de fonctionnement

complémentaires mais aux principes bien distincts [36] :

Le mode « poll SNMP » : La station d’administration demande à un agent

SNMP de lui retourner la valeur de telle ou telle variable. Cela se passe donc en

deux étapes : la requête du serveur pour interroger le client, et la réponse du

client. Le serveur (ou station d’administration SNMP) peut ainsi connaître à des



intervalles réguliers les informations qu’il souhaite. Nous venons de citer à titre

d’exemple la température interne d’un élément actif, mais on peut aussi

connaître le taux d’utilisation du processeur en temps réel, l’espace disque libre

d’une machin, etc. Le serveur est donc chargé d’interroger une liste

d’informations bien précise pour connaître l’état de la machine. Le problème qui

se pose est que l’on ne peut pas connaître à l’avance la nature des incidents.

Ainsi, si l’un des deux processeurs d’un élément actif est en panne, le second

prend le relais automatiquement et personne ne s’aperçoit de rien, jusqu’au jour

où le deuxième tombe en panne à son tour.

Le mode « Trap SNMP » : un trap SNMP est un message informatif qui est

envoyé par l’agent SNMP en cas d’incident à destination du serveur qui est

toujours en écoute de ces messages. Pour reprendre notre exemple du

processeur, si le premier venait à griller, un message indiquant la nature de

l’incident est envoyé automatiquement à la station d’administration pour

prévenir l’administrateur que le processeur n°1 de tel élément est hors service.

La station d’administration se contente donc d’être à l’écoute de ces traps

SNMP.

Figure II.7 : Les deux méthodes de supervision SNMP [36]

Ces deux modes permettent donc de superviser l’état des différents équipements du

réseau. C’est ici que se trouve la limite de ce protocole SNMP. Il ne peut pas connaître les

applications qui tournent sur la machine. Le protocole SNMP ne supervise que les premières

couches du modèle OSI. On peut ainsi connaître l’état d’une machine, si elle est active et en

bonne santé ou non, mais on ne sait pas si les services eux sont bien actifs et accessibles. Or,

cela n’est rien moins que le point de vue de l’utilisateur, qui est au centre des intérêts de ce

projet de supervision. [37]



Le protocole SNMP est un protocole réseau qui comporte différentes requêtes. Ces

requêtes sont regroupées en 3 familles : [6]

les messages du superviseur SNMP vers l'agent SNMP ;

les messages de l'agent SNMP vers le superviseur SNMP ;

les messages entre agents SNMP.

Le protocole SNMP est un protocole supporté par UDP. Traditionnellement, les

ports suivants sont utilisés [44]:

l'agent SNMP utilise le port UDP 161 pour recevoir les messages "Get Request",

"Get Next Request" et "Set Request" ;

le superviseur SNMP utilise le port UDP 162 pour recevoir les messages "Trap",

"Notification" et "Inform".

Figure II.8 : Echange de message [44]

Les requêtes « get » servent à obtenir des informations

Les requêtes « set » servent à modifier la valeur des variables des Mib.

Les requêtes « get reponse » servent à obtenir la réponse de l’agent distant [44].



Figure II.9 : Résumé des commandes SNMPv2 [6]

Lorsqu’une commande est expédiée à un agent, on attend de celui-ci une

réponse. Plusieurs cas peuvent se produire :

· Aucune réponse (Temps d’attente dépassé)

· Erreur dans la requête

· La requête a réussi [6].

II.11.5. Trame SNMP

II.11.5.1. Format des PDUs

Figure II.10 : Les trames SNMP [50]



Description des champs :

version : Version de SNMP.

community : Nom de la communauté (agit comme un mot de passe).

request-id : Utilisé pour différencier les messages.

error-status : Utilisé pour signaler une erreur (0 si pas d'erreur).

error-index : Indique la sous-catégorie d'erreur.

variablebindings : Nom des variables avec leurs valeurs.

enterprise : Type de l'objet générant l'alarme.

agent-addr : Adresse de l'émetteur de l'alarme.

generic-trap : Identificateur de l'alarme.

specific-trap : Identificateur d'alarme spécifique.

time-stamp : Temps écoulé depuis la dernière réinitialisation de l'entité [50].

Le champ communauté (community) est une chaîne de caractère qu’il faut voir

comme un mot de passe de validation d’une requête SNMP par l’agent ou par le manager.

Si la communauté est incorrecte, la requête est rejetée. La communauté passe en clair sur

le réseau [51].

II.11.6. Les MIBS (Management Information base)

Une MIB se présente comme une base de données normalisée, qui permettra de

lire et d'écrire sur les équipements distants, de façon également normalisée. Ce sera à

l'agent lui-même de faire l'interface entre les informations récupérables sur la plateforme

où il est installé et le jargon utilisé par SNMP [37]. C’est un ensemble structuré

d'informations organisé sous la forme d'un arbre hiérarchisé de la même manière que

l'arborescence des domaines Internet. Chaque information dans cette hiérarchie est

identifiée par son OID (Object Identifier).Un OID est une séquence de nombres séparés

par le caractère "." (Point) [52].



Le début de l'arborescence des OID défini dans les différentes RFC est le

suivant :

Figure II.11 : Les identificateurs d’objets de La MIB [52]

Deux MIB publics ont été normalisées: MIB I et MIB II (dite 1 et 2). Elles décrivent

l’ensemble des variables TCP/IP [52]. La MIB II est utilisée par la version SNMPv2. Elle est

riche en termes de variables. Les entreprises peuvent de leur côté définir leur propre MIB. La

MIB est un arbre hiérarchisé très dense. Il existe plusieurs milliers d'OID dans la MIB. Il est par

conséquent impossible de décrire tous ces OID dans un seul fichier MIB. De même que pour le

DNS, les différentes parties de la MIB sont définies dans différents fichiers MIB. Chaque fichier

MIB a la responsabilité d'une branche particulière de la MIB [6].



II.11.7. La sécurité sur SNMP

II.11.7.1. Les faiblesses de SNMPv1

Une des plus grandes faiblesses du protocole SNMPv1 est l'absence d'un

mécanisme adéquat pour assurer la confidentialité et la sécurité des fonctions de gestion.

Les faiblesses comprennent aussi l'authentification et le chiffrement, en plus de l'absence

d'un cadre administratif pour l'autorisation et le contrôle d'accès [45].

II.11.7.2. Les améliorations de SNMPv2c

Le groupe de travail de l'IETF qui a œuvré sur SNMPv2 a voulu inclure la

sécurité dans la nouvelle version. Malheureusement, ce groupe n'a pas pu atteindre un

consensus sur le fonctionnement du mécanisme de sécurité. Partant de là, deux

propositions ont été développées (SNMPv2u et SNMPv2*). La plupart des experts

s'entendent pour dire que deux standards SNMP ne peuvent pas coexister, et que ceci

n'est pas une solution à long terme [46].

II.11.7.3. La sécurité sur SNMPv3

Cette nouvelle version du protocole SNMP vise essentiellement à inclure la

sécurité des transactions. La sécurité comprend l'identification des parties qui

communiquent et l'assurance que la conversation soit privée, même si elle passe par un

réseau public. Cette sécurité est basée sur 2 concepts :

USM (User-based Security Model): [53]

Trois mécanismes sont utilisés. Chacun de ces mécanismes a pour but d'empêcher

un type d'attaque.

- L'authentification :

?

Figure II.12 : Le mécanisme d'authentification [53]

Emetteur Récepteur

Data Password

MD5

Hash code

Data Hash code

Data Password

MD5

Hash code 2

Data Hash code




- Le chiffrement :

Figure II.13 : Le chiffrement avec DES [53]

- L'estampillage du temps : Empêche la réutilisation d'un paquet SNMPv3

valide a déjà transmis par quelqu'un.

VACM (View- based Access Control Model): [54]

Permet le contrôle d'accès au MIB. Ainsi on a la possibilité de restreindre l'accès

en lecture et/ou écriture pour un groupe ou par utilisateur.

II.12. Conclusion

Le système d’administration d’un réseau doit permettre à son administrateur

d’intervenir à partir d’une station sur tout son parc indépendamment des différents systèmes ou

matériels, cela nécessite un certain protocole de gestion.

Dans le modèle OSI, Il existe un protocole connu pour la gestion de réseaux (CMIP)

L’avantage principal du CMIP est la sécurisé, il peut fonctionner sur des réseaux hétérogènes

mais leur inconvénient est la complexité. À cause du problème, il n’est pas utilisé largement dans

la réalité. Donc SNMP est devenu un protocole d’administration à part entière, qui sert à

s’assurer une pérennité durable de par sa simplicité, son efficacité et son ouverture vers les

évolutions techniques et les contraintes économiques.

Une solution d’administration doit répondre à certains critères, à certaines attentes de la

part de l’administrateur, et ceci de façon stable et durable. Il ne s’agit en aucun cas d’être

handicapé dans sa gestion par un nouveau matériel ou une nouvelle application, c’est pourquoi

afin de garantir une pérennité dans l’administration de tous les éléments d’un réseau, surtout si

nous parlons des éléments qui ont peu d'énergie (les capteurs sans fil), il est préférable d’adopter

une plate-forme d’administration qui prend en compte les limites qui caractérisent ce type de

réseau.

Key Data Key Coded

DES DES

Coded Data

Emetteur Récepteur

Chapitre III GESTION ET SUPERVISION DES RCSFs-Etat de l’art


III.1. Introduction

Récemment, Les réseaux de capteurs sans fil ont, particulièrement, retenu l'attention.

La capacité des réseaux de capteurs pour détecter, communiquer et traiter des données a conduit

à la mise au point rapide de ces réseaux. De nombreux chercheurs ont tenté d'améliorer

l'efficacité de gestion de réseau de capteurs sans fil. Les RCSFs peuvent détecter et surveiller les

informations du monde physique. Les nœuds de capteurs peuvent fonctionner de façon autonome

pour recueillir et échanger des informations dans un environnement particulier. Les RCSFs,

avec de grands nombre de nœuds, vont acquérir de très grandes quantités de données. La gestion

du réseau devient alors très difficile.

Les RCSFs représentent une nouvelle approche pour contrôlé pour des applications

telles que : la surveillance de l'environnement, la gestion des infrastructures, la sécurité publique,

le transport, etc.

La gestion des réseaux de capteurs sans fil est un nouveau domaine de recherche qui

doit susciter l’intention des chercheurs.

III.2. Objectifs de gestion des RCSFs

L'objectif des réseaux de capteurs sans fil est de surveiller, de contrôler un

environnement physique et d’atteindre des objectifs spécifiques.

La gestion du réseau est le processus de suivi et de contrôle du comportement d'un

réseau. Ce dernier pose des défis uniques pour la gestion de réseau qui font des techniques de

gestion de réseau traditionnelles impraticables. Dans les réseaux traditionnels les principaux

objectifs sont :

minimiser le temps de réaction ;

fournir des informations complètes [55].

Mais dans les réseaux de capteurs, l'objectif principal est de minimiser la

consommation d'énergie et le moyen principal pour y parvenir est de réduire la quantité de

communication entre les nœuds [55].

Optimiser les propriétés opérationnelles et fonctionnelles de RCSFs peut exiger une

solution unique pour chaque problème d'application [56]. Les RCSFs sont très dynamiques et

sujettes à des défauts, principalement en raison de la pénurie d'énergie, les interruptions de

connectivité et les obstacles environnementaux. Les défaillances de réseau sont des événements

communs plutôt que des exceptionnelles [57].



Ainsi, dans les réseaux de capteurs, nous sommes principalement concernés par la

surveillance et le contrôle de la communication des nœuds afin de :

optimiser l'efficacité du réseau ;

assurer que le réseau fonctionne correctement ;

maintenir la performance du réseau ;

contrôler un grand nombre de nœuds sans intervention humaine [57].

III.3. Critères de conception de systèmes de gestion de RCSF

L'observateur est une entité du réseau ou de l'utilisateur final qui veut avoir des

informations sur les données recueillies par nœuds de capteurs. Selon le type d'application,

l'observateur peut envoyer une requête et recevoir une réponse de celui-ci. L’élément capteur

génère des données d'un phénomène donné [58].

Un RCSF Peut recueillir des données de capteurs différents, telles que la température, la

pression, le champion Electromagnétique, etc. Les RCSFs ont d'autres caractéristiques

importantes en fonction de l'application. Certains d'entre eux sont la couverture, l'exactitude, la

fidélité, la densité, l'auto-organisation, l'adaptation et l'emplacement [57].

Un système de gestion de réseau conçu pour les réseaux de capteurs doit prendre en

compte les propriétés uniques des réseaux de capteurs. Les critères suivants sont utilisés pour

évaluer les systèmes de gestion de réseaux de capteurs :

Longévité / énergie: l'énergie est une ressource critique dans les RCSFs, toutes les

opérations effectuées dans le réseau doivent être économiques en énergie. La

disponibilité du réseau peut être mesurée comme la quantité de temps où tous les

nœuds de capteurs dans le réseau continuent d'obtenir et de transmettre des

données de détection, donc un système devrait être capable de courir sur des nœuds

de capteurs sans consommer trop d'énergie ou d'interférer avec le fonctionnement

des nœuds de capteurs. Une opération légère prolonge la durée de vie du réseau.

Latence: Il s’agit de l'intervalle de temps entre l'instant où le capteur reçoit les

données et le moment où ils sont livrés à la destination, et il a deux composantes : à

l'intérieur du réseau, du capteur aux sink et du sink à observateur. Selon le type

d'application et la latence du réseau, les données reçues par l'observateur peuvent

être sans valeur et doivent être jetés [58].



Précision: Celle-ci n’indique ni la fiabilité ni l'exactitude d'un résultat. elle peut

être définie comme la fraction de la validité des résultats obtenus. Des facteurs tels

que les conditions de l’environnement, lorsque les données sont obtenues de la

communication du nœud de capteurs peuvent aussi dégrader la précision.

L'application joue un rôle important dans cette mesure, car elle est chargée d'établir

la quantité d'énergie à dépenser dans l'obtention des données. En conséquence, le

réseau doit s’adapter à la mesure de la précision définie par l'application et en

fonction d'une limite supérieure de temps de latence.

La tolérance de panne: Dans un RCSF, les nœuds peuvent échouer à cause de

l'énergie, de la destruction physique, des problèmes de la communication, ou de

l'inactivité (un nœud devient suspendu). Même si ces situations se produisent, elles

peuvent être souhaitables que le réseau continue à fonctionner correctement. Un

système de gestion doit être élastique à la dynamique de réseau par sa

reconfiguration selon les besoins [57].

Goodput: C’est le rapport du nombre total de paquets reçus par l'observateur et le

nombre total de paquets envoyés par tous les capteurs pendant une période de

temps.

Adaptabilité et réactivité : Un système devrait être en mesure de récupérer et de

s’adapter à l'état actuel du réseau ou à l'évolution de ses conditions, y compris des

changements dans la topologie du réseau, au niveau d'énergie de nœud, dans la

couverture et dans les limites d’exposition de réseaux de capteurs.

Minimale de stockage de données : Un modèle de données utilisé pour

représenter celles de gestion doit être extensible et capable d'accueillir les

informations nécessaires pour effectuer les fonctions de gestion, mais doit

également respecter les contraintes de mémoire de réseaux de capteurs.

Evolutivité : Un système devrait fonctionner efficacement dans n’importe quelle

taille du réseau [58].

III.4. Les fonctions principales de gestion des RCSFs

Un système de gestion de réseau conçu pour les capteurs sans fil devrait fournir un

ensemble de fonctions de gestion qui intègrent la configuration, l'exploitation, l'administration, la

sécurité, et la maintenance de tous les éléments et les services d'un réseau de capteurs [57].

La tâche principale de la surveillance de RCSF est de recueillir des informations sur les

paramètres suivants:



Etats de nœud (par exemple, le niveau de la batterie) ;

La topologie du réseau ;

La bande passante sans fil ;

L'état des liens, de la couverture et des limites d'exposition de réseaux de capteurs

[57].

Un système de gestion de réseau de capteurs peut effectuer une variété de tâches de

contrôle de la gestion axées sur les états du réseau collectés tels que :

Le contrôle fréquent d'échantillonnage ;

Nœud de commutation on / off (gestion de l'alimentation)

Contrôle de l'utilisation de la bande passante sans fil (gestion du trafic) ;

Effectuer la reconfiguration du réseau pour récupérer les défauts des nœuds et de la

communication (gestion des pannes) [59].

Le suivi des nœuds individuels dans un grand réseau de capteurs peut être difficile. Il

suffit de contrôler le réseau en assurant une couverture de réseau spécifique. En outre, les nœuds

de détection sont généralement déployés dans des conditions sévères ou à distance et la

configuration des nœuds dans les réseaux de capteurs change dynamiquement [59]. Ainsi, un

système de gestion de réseau de capteurs devrait permettre au réseau de s’auto-former, de s’auto-

organiser, et, idéalement, de s’auto-configure en cas de défaillances sans connaissance préalable

de la topologie du réseau [60].

Malgré l'importance de la gestion de RCSF, Il n’existe aucune solution généralisée

existante pour elle. Cependant, la plupart des applications de réseaux de capteurs sont conçues

avec la gestion de réseau à l'esprit et donc il n’y a pas de couche de gestion de réseau

supplémentaire qui est nécessaire [58].

Les fonctions de gestion peuvent être automatiques, lorsqu'elles sont exécutées par un

logiciel invoqué comme des renseignements obtenus à partir d'un modèle; semi-automatiques,

lorsqu'elles sont exécutées par un opérateur humain assisté par un système qui fournit un modèle

de réseau ou invoqué par un système de gestion ; Et manuel, lorsqu'elles sont exécuté à

l'extérieur du système de gestion [59].

Cinq états possibles sont définis pour une fonction: prêts, lorsque les conditions

nécessaires pour exécuter une fonction sont remplies; non prêt, lorsque les conditions nécessaires

pour exécuter une fonction ne sont pas remplies; exécutés, lorsque la fonction est en cours

d'exécution; faits, quand la fonction à exécuter est en succès; et en échec, en cas de panne

pendant l'exécution de la fonction [60].



Une liste partielle des fonctions de gestion, sans aucun ordre particulier, est donnée ci-

dessous [61]:

La fonction de surveillance de l'environnement ;

La fonction de surveillance de la zone de couverture ;

La fonction de définition de déploiement des nœuds ;

La fonction d'acquisition des exigences environnementales ;

La fonction de configuration des paramètres de fonctionnement du réseau ;

La fonction de découverte de la connectivité du réseau ;

La fonction horaire de l'exploitation de gestion ;

La fonction de découverte de la synchronisation de coopération ;

La fonction de l’énergie par la carte de génération ;

La fonction d’interface de l’utilisateur ;

La fonction du nœud de découverte de la localisation ;

La fonction du nœud de l’exploitation du contrôle d’état ;

La fonction de découverte de niveau d'énergie ;

Nous définissons certaines fonctions, énumérées ci-dessous, qui permettent d'obtenir

des caractéristiques liées à l'efficacité d'un RCSF. Certaines de ces fonctions quantitatives sont

définies pour obtenir des paramètres présentés dans [61]:

Régler le réseau en fonction de temps

heure de départ du réseau

La fonction de la fréquence des mises à jour (de overhcad)

La fonction de l'exigence de mémoire

La fonction de l'évolutivité du réseau

La fonction de la consommation d’énergie

III.5. Les systèmes de gestion de RCSF

Après avoir identifié : une partie des fonctionnalités prises en charge dans les systèmes

de gestion du réseau existant, le choix pour le fonctionnement du système, et les critères pour un

fonctionnement efficace dans un réseau de capteurs, nous examinons, maintenant, l’état

individuel des systèmes de gestion existant de réseau de capteurs.



III.5.1. Cadre de gestion de réseau de capteurs sans fil

III.5.1.1. BOSS

Song et al. [62] proposent une architecture de gestion de découverte de service

pour les réseaux de capteurs. L'architecture est basée sur UPnP (le protocole de découverte

de service standard pour la gestion de réseau). Cependant, UPnP ne fonctionne que sur les

appareils avec une puissance de calcul élevée et une grande mémoire. Ainsi, les nœuds de

capteurs à ressources limitées sont incapables de traiter le protocole UPnP. Song et al ont

résolu ce problème en mettant en œuvre un agent UPnP dans la station de base, appelé pont

des capteurs (BOSS), qui fournit un pont entre un réseau de capteurs géré et un réseau

UPnP.

Figure III.1 : Architecture de BOSS [62]

La figure III.1 est une abstraction de l'architecture de BOSS en détail dans [62].

Le point de contrôle et BOSS utilisent le protocole UPnP pour la communication, tandis

que les non-UPnP nœuds de capteurs et BOSS utilisent un protocole propriétaire de réseau

de capteurs pour la communication.

Les services de gestion de réseau fournis par le BOSS comprennent des

informations : de base du réseau, de localisation, de synchronisation et de gestion de

l'alimentation. BOSS peut récupérer les informations d'état du réseau de capteurs, y

compris la description de l'appareil de nœud de capteur, le nombre de noeuds de capteurs

dans le réseau, et la topologie du réseau.

L'avantage d'utiliser BOSS est que les différentes applications de réseaux de

capteurs (par exemple la surveillance des structures, la détection d'incendie et le contrôle

d'éclairage automatique) peuvent être gérées par de multiples points de contrôle UPnP (par

exemple PC et PDA). En outre, BOSS permet à un réseau de capteurs de s’adapter aux

changements de topologie, ainsi soutenir la gestion proactive du réseau.



III.5.1.2. MANNA

MANNA (une architecture de gestion de réseaux de capteurs sans fil) [58], est

un système de gestion basé sur des règles qui recueille des informations de gestion

dynamique, et exécute les fonctions et les services de gestion basés sur des modèles de

RCSF. La politique de gestion de MANNA détermine les fonctions de gestion qui

devraient être exécutées si certaines conditions sont remplies. Les modèles de RCSF

maintiennent les informations sur l'état du réseau. MANNA définit la relation entre les

modèles de RCSF dans la base de données de gestion (MIB).

Quelques exemples de modèles de RCSF comprennent:

La carte de topologie représentant la connectivité du nœud et l'accessibilité

du réseau.

La carte de l'énergie résiduelle montrant le niveau de la batterie des nœuds

dans le réseau.

La carte de la couverture de la zone de détection décrivant la zone couverte

par des éléments de capteur.

La carte de la zone de couverture de communication présentant la portée de

communications de nœuds dans un réseau.

Plan de vérification décrivant l'état de sécurité des nœuds de capteurs dans

un réseau [63].

La figure.III.1 regroupe l’ensemble des fonctions sur les trois dimensions

mentionnées. L’architecture fonctionnelle de MANNA donne la distribution des

fonctionnalités de gestion dans le réseau entre le manager, l’agent et la MIB. Les

emplacements de ces derniers dépendent du type de RCSF et de l’approche de gestion.

L’architecture physique de MANNA définit un protocole de gestion, les positions

physiques des agents, les fonctionnalités de l’agent, le service de gestion et les interfaces

supportés [58].

L’architecture de MANNA considère que les quatre domaines fonctionnels (les

anomalies, la sécurité, les performances et la comptabilité) dépendent extrêmement de la

configuration. Cette architecture d’information est basée sur le modèle d’information

orienté objet qui fournit la représentation des ressources gérées et le support des classes

d’objet [58].



Communication

Traitement

Détection Fonctionnalités d’RCSF

Entretien

Domaines Configuration

Fonctionnels

De gestion

Gestion d'entreprise

Faute La gestion des services les niveaux

Configuration La gestion du réseau de gestion

Performance La gestion des éléments de réseau

Sécurité Elément de réseau

Comptabilité

Figure.III.2 : L’ensemble des fonctions de gestion définies dans MANNA [58]

Un service consiste à trouver l’ensemble des activités ou des fonctions qui

doivent être exécutés dans un moment donné, en précisant les données. La figure.III.2

présente des relations entre ses services, ses fonctions et ses modèles. Cette architecture

définit juste les modèles qui représentent les aspects de RCSF où on peut avoir une vision

abstraite de système.

Utilisations Utilisations Utilisations

Utilisations Utilisations Utilisations

Figure.III.3 : Les relations, les fonctions et les modèles de système MANNA [58]

Dans un RCSF, les conditions du réseau peuvent varier considérablement dans le

temps. Dans ce cas, l'utilisation de modèles établis par MANNA est d'une importance

fondamentale pour la gestion, bien que son cycle de mise à jour peut-il être extrêmement

dynamique et complexe. En se basant sur les informations obtenues avec ces modèles, les

services et les fonctions sont exécutés conformément aux politiques de gestion [58].

Service Y Service X

Fonction 1 Fonction 2 Fonction 3 Fonction 4

Modèle de RCSF Modèle de RCSF



III.5.2. Protocoles de gestion des réseaux de capteurs sans fil

III.5.2.1. RRP

Liu et al. [64] proposent un cadre de diffusion des données hybride, RRP, basée

sur le concept de chaîne d'approvisionnement pour la gestion des applications de collecte

de données telles que la surveillance de l'habitat et le champ de bataille. Dans ce projet, la

gestion de la chaîne d'approvisionnement est un système coordonné des entités et des

activités pour délivrer un produit ou un service du fournisseur au client.

L'objectif principal de la gestion de la chaîne d'approvisionnement est de

répondre aux demandes des clients grâce à l'utilisation efficace des ressources en autorisant

les entités telles que le fabricant, les distributeurs et les points de vente pour avoir leurs

propres activités internes et des stratégies de gestion, mais aussi pour collaborer, pour

parvenir à une gestion d’objective commune. Liu et al. [64] appliquent :

Le concept de chaîne d'approvisionnement dans la conception de RRP en

divisant un réseau de capteurs en plusieurs régions fonctionnelles, en

appliquant différents systèmes de routage pour différentes régions ;

La conception de la coopération entre les différentes régions pour assurer une

meilleure performance du réseau en termes de fiabilité et de l'utilisation

d'énergie.

Liu et al. [64] aussi proposent une nouvelle zone de programme d'inondation qui

est une combinaison d'inondations et de techniques de routage géométriques.

Les principaux avantages de RRP sont cette zone-inondation qui assure de

faibles overhead de message, et en ajustant la taille de la zone-inondation qui assure une

grande fiabilité. RRP permet à l'utilisateur final de prédéfinir la taille des entrepôts et des

zones inondables afin d'atteindre une consommation d'énergie désiré, délai de bout en bout,

et le routage des overhead, tout en maintenant la livraison de paquets élevés (de fiabilité).

En général, chaque fois que la zone-inondation est grande, les nœuds de transport sont plus

impliqués dans la transmission de paquets, ce qui donne une plus grande fiabilité, mais un

délai supérieur [64]. Les inconvénients de RRP sont qu'il nécessite des nœuds GPS-joint,

afin de mettre en œuvre le protocole zone-inondations et il nécessite un gestionnaire

humain pour placer des nœuds de capteurs dans le domaine stratégique à la configuration

initiale du réseau afin de soutenir la gestion de réseau hiérarchique RRP. Le manager

humain doit décider quels nœuds et où il les devrait situer pour les zones de fabrication, le

transport, le stockage et le service [64].



III.5.2.2. SNMS

Tolle et Culler [65] proposent SNMS, un système de gestion de réseau de

capteurs sans fils. SNMS est un système interactif pour la surveillance de la performance

des réseaux de capteurs. SNMS fournit deux principales fonctions de gestion: Une requête

fondée par la collecte de données sur la performance du réseau et la journalisation des

événements. Le système d'interrogation permet à l'utilisateur de collecter et de contrôler les

paramètres physiques de l'environnement des noeuds. Par exemple, la valeur de la

puissance restante de la batterie d'un nœud peut être utilisée pour prédire les défaillances

du nœud. En outre, la température et l'humidité entourant le nœud de capteur peuvent être

des indicateurs de panne à venir. Le système de journalisation événementielle permet à

l'utilisateur de définir les paramètres de l'événement et les nœuds du réseau communiquent

leurs données s’ils satisfont aux seuils des événements spécifiés.

Le principal avantage du SNMS est qu'il introduit en tête seulement les requêtes

humaines, donc il a un impact minimal sur la mémoire et le trafic réseau. SNMS minimise

encore la consommation d'énergie en regroupant les résultats de plusieurs requêtes en un

seul message au lieu de renvoyer les résultats individuellement.

Les principaux inconvénients du SNMS sont que la fonction de gestion du

réseau est limitée à la surveillance passive seulement, exigeante que les gestionnaires des

droits soumettent des requêtes et effectuent une analyse post-mortem de données de

gestion. En outre, l'approche centralisée du traitement du SNMS nécessite une

interrogation continue des données de performance du réseau à partir des nœuds gérés à la

station de base, et cela peut être un fardeau sur le capteur alors qu’on devrait minimiser les

transmissions afin de prolonger la durée de vie du réseau [65].

III.5.2.3. WinMS

Louis Lee et al. [66] proposent un système de gestion adaptatif basé sur des

règles pour les réseaux de capteurs, appelé Wireless Sensor Network Management System

(Les WinMS). Les utilisateurs finaux redéfinissent le paramètre seuil de gestion sur les

nœuds de capteurs qui est utilisés comme déclencheur d'événement, et précisent les tâches

de gestion à exécuter lorsque les événements se produisent. WinMS s’adapte aux

conditions changeantes du réseau en permettant au réseau de se reconfigurer en fonction de

l'actualité ainsi que de prédire des événements futurs, afin de maintenir la performance du

réseau et réaliser des opérations efficaces des nœuds du réseau.



Un avantage de WinMS est que son protocole TDMA est léger, il fournit une

gestion efficace de l'énergie, un transport de données et une réparation locale. Il fournit

également des auto-configurations automatiques et l'auto-stabilisation à la fois localement

et globalement en permettant au réseau de s’adapter aux conditions actuelles sans

intervention humaine. Un inconvénient de WinMS est que le coût de la configuration

initiale pour construire un calendrier de l'arbre de collecte de données est proportionnel à la

densité du réseau. Toutefois, ce coût ponctuel peut être toléré parce que les nœuds

maintiennent les informations recueillies durant toute leur vie dans le réseau [66].

III.5.3. Gestion par délégation

Gestion par délégation (MbD) permet la gestion des rôles pour être distribués entre

les nœuds dans le réseau pour alléger le fardeau sur un gestionnaire central. La délégation est

réalisée par des agents intelligents ou des agents mobiles. Un agent mobile est une section de

code qui peut répartir les tâches de gestion pour être exécuté sur les nœuds localement et

renvoie les données résultantes au gestionnaire central [58]. Plusieurs protocoles utilisent des

systèmes de délégation pour fournir des fonctions de gestion de réseau, y compris Agilla [67],

balayeuses sectorielles (SS) [68], mobile agent-based policy management [69], et intelligent

agent-based power management [70].

III.5.3.1. Agilla

Agilla [67] est un middleware qui permet aux utilisateurs de déployer des agents

mobiles dans un réseau pour effectuer des tâches d’application spécifique. Par exemple,

dans une application de suivi de feu, quand un incendie se produit dans une région d'un

réseau de capteurs, les agents suivront le feu car il se propage, et feront le périmètre de la

zone d'incendie. Dans Agilla, chaque nœud de capteur peut être contrôlé par de multiples

agents. Agilla fournit un système qui permet aux agents mobiles de se déplacer vers des

endroits désirés lorsqu’il y a un changement dans les conditions du réseau. Chaque nœud

de capteur dans le réseau maintient un espace de tuple qui contient un ensemble de

descripteurs prédéfinis sur ce nœud. L'espace de tuple d'un nœud peut être partagée par les

agents et les agents locaux peuvent enregistrer leur intérêt pour des événements particuliers

en insérant un tuple de modèle dans l'espace de tuple. Lorsqu'un nœud détecte les

événements correspondants, il met à jour son espace tuple en conséquence et rapporte les

événements à l'agent. Ainsi, les agents n’ont pas besoin d'interroger en permanence les

états des nœuds du réseau de capteurs [67].



III.5.3.2. Mobile Management Agent Policy-Based

Une gestion de la politique hiérarchique mobile à base d'agents pour la gestion

des réseaux de capteurs est proposée dans [69]. Il permet à l'utilisateur final de pré-

spécifier les politiques de gestion, les règles pour l'utilisation de l'énergie et la puissance de

calcul, qui sont appliquées par les agents mobiles. Chaque règle se compose d’un ensemble

de conditions et les opérations de gestion sont effectuées lorsque les conditions sont

remplies [69].

III.5.3.3. sectorielle Sweeper

Erdogan et al. [68] proposent balayeuses sectorielles pour la gestion d'un réseau

de capteurs sans fil. Une balayeuse sectorielle est placée dans le réseau pour gérer une

région du réseau. Une balayeuse agit comme un gestionnaire distribuée qui diffuse

directement des tâches aux nœuds de capteur dans sa région de la responsabilité par

radiodiffusion. Cette approche réduit la consommation d'énergie du réseau en éliminant la

nécessité pour les transmissions multi-sauts pour livrer une tâche à un nœud cible. Les

nœuds de capteurs qui ne sont pas impliqués dans la diffusion d'une tâche, peuvent dormir

pour conserver leur énergie [68].

III.5.3.4. Intelligent Agent-Based Power Management

Tynan et al. [70] ont conçu un système intelligent à base d’agent de gestion

d'énergie en utilisant le paradigme de la croyance, le désir et l’intention [71]. Dans IABP,

les croyances représentent des états de nœuds de capteurs que l'agent détient pour être vrai.

Les règles d'engagement (ou désirs) sont des conditions prédéfinies pour évaluer les

croyances. Si les croyances correspondent aux règles d'engagement, la fonction de gestion

d'engagement correspondante (intention) sera exécutée. Cette approche basée sur l'agent

est conçu pour les applications où seule une vue partielle de l'état du réseau dans son

ensemble peut être connu à tout un lieu ou de temps [70].

III.5.4. Outils de débogage

III.5.4.1. Sympathy

Sympathy, est un système de débogage développé pour identifier et localiser la

cause de défaillance dans les applications des réseaux de capteurs en recueillant des

mesures de performance de réseau avec un minimum de surcharge de la mémoire, l'analyse

des mesures pour détecter des événements, et l'identification contexte spatio-temporelle



des événements [72].Les défaillances dans les réseaux de capteurs peuvent être dues à des

interactions entre plusieurs nœuds. Sympathy fournit un schéma de débogage pour détecter

ce type de défaillance en analysant la corrélation entre les événements. Sympathy recueille

les mesures qui représentent les états du réseau et sont réunis directement depuis

l'application. Sympathy définit les mesures pour déduire la performance du réseau,

détection de défaut (par exemple la route de battement, la sélection de saut suivant et la

perte de paquets) et d'autres événements spécifiques aux réseaux de capteurs [72].

III.5.5. Visualisation Outil

III.5.5.1. Mote-View

Mote-View [73] est un outil de visualisation conçu pour le suivi et la gestion de

réseaux de capteurs. Les objectifs de Mote-View sont pour aider les utilisateurs à analyser

les grandes quantités de données générées par les réseaux de capteurs, de surveiller l'état de

performance de nœuds de capteurs individuels et du réseau dans son ensemble, et de

présenter des informations utiles à l'utilisateur final. Mote-view utilise une approche de

gestion centralisée dans lequel toutes les données et traitement de la gestion est réalisée de

manière centralisée par le serveur [73].

III.5.6. Systèmes de gestion d'énergie

L'énergie est l'une des ressources les plus importantes à être gérés dans un réseau de

capteurs parce que les nœuds de capteurs sont principalement alimentés par batterie et dans de

nombreux cas, il est impossible de recharger ces batteries [74]. Plusieurs chercheurs

proposent des systèmes de gestion de capteur qui visent à fournir le contrôle de la

consommation d'énergie dans les réseaux de capteurs afin de parvenir à l'efficacité

énergétique, y compris Senos [75], AppSleep [76], et node-energy level management [77]. Il

y a aussi d'autres protocoles qui intègrent des méthodes pour réduire la consommation

d'énergie. Span [78] et STEM [79] permettent aux nœuds de dormir s’ils ne sont pas

impliqués dans une tâche de transfert. LEACH [80] utilise une méthode d'agrégation de

données pour filtrer les données redondantes dans un réseau de capteurs dense et ainsi réduire

le nombre de transmissions.

III.5.6.1. Senos

Senos est un système d'exploitation sur la base de la machine à états finis qui

intègre un protocole de gestion de puissance dans les nœuds de capteurs [75]. Senos

suppose que les nœuds redondants sont placés dans un cluster pour le fonctionnement en



alternance afin de prolonger la durée de vie des grappes. Il maintient en vie un seul nœud

dans un cluster pour une période de temps, tandis que les autres nœuds sont mis en

sommeil pour économiser l'énergie. Pour ce faire, Senos utilise la gestion dynamique de

l'alimentation (DPM) [81], une technique de gestion de puissance algorithmique complète,

arrêter les nœuds lorsqu'il n’est pas nécessaire et se réveiller si nécessaire [81].

III.5.6.2. AppSleep

AppSleep est un protocole de gestion de l'alimentation orienté flux qui s’étend

de la période de sommeil des nœuds de capteurs basés sur la connaissance de

communications réguliers dans un réseau, tout en apportant des réponses à faible latence

pour les communications non prioritaires lorsque cela est nécessaire [76]. App-sleep est

conçu pour les applications de réseaux de capteurs de cycle de service faible avec rafales,

insensible au retard de transmission de données [76].

III.5.6.3. Node-energy level management

De nombreuses tâches d'application différentes peuvent être injectées dans un

réseau de capteurs. Il est souhaitable que le réseau soit en mesure d'accepter ou de rejeter

une tâche en fonction des coûts de l'énergie [77]. Dans une approche du niveau du système,

chaque application doit avoir une connaissance complète de toutes les autres applications,

ce qui se traduit par une surcharge importante du trafic pour les communications du nœud.

Pour résoudre ce problème, Boulis et Srivastava [77] proposent un mécanisme qui permet

de résoudre le problème de la gestion de l'énergie au niveau du nœud au lieu du niveau du

système, dans lequel les nœuds peuvent prendre des décisions locales sur les tâches

acceptées. Les applications n’ont pas besoin de communiquer directement les uns avec les

autres [77].

III.5.7. Systèmes de gestion de la circulation

III.5.7.1. Siphon

Siphon est un système à la demande de gestion du trafic de surcharge [82].

Siphon propose des algorithmes permettant la découverte de puits virtuels, la sélection, la

détection de la congestion, la redirection du trafic, et éviter la congestion dans le réseau de

radio secondaire distribué. Virtuels Sinks (VSs) sont des intermédiaires entre les nœuds de

capteurs et stations de base du réseau et sont responsables pour rediriger les données des

régions du réseau de capteurs qui ont des pics de trafic [82].



III.5.7.2. Gestion des ressources DSN

Zhang et al. [83] proposent une technique de gestion des ressources pour les

réseaux de capteurs distribués de tâches orienté (DSN) qui évite la congestion du réseau

tout en répondant aux objectifs globaux du réseau. Ils proposent une méthode «perflow »

pour analyser les flux des données entre les nœuds à différents niveaux hiérarchiques de la

DSN. Dans DSN, les stations de décision agissent comme gestionnaires pour chaque

niveau hiérarchique. Chaque gestionnaire recueille des données à partir des nœuds à son

niveau, traite leurs données, et envoie les informations résultantes à la prochaine

gestionnaire de niveau pour un traitement ultérieur. Ainsi, l'information produite à des

niveaux inférieurs affecte le processus de prise de décision de gestion à des niveaux plus

élevés, et l'information de bas niveau peut être utilisée pour atteindre les objectifs

mondiaux fixés par le plus haut niveau [83].

III.6. L’organisation du système de gestion des RCSF Il y a deux principaux choix pour l'organisation du système de gestion de réseaux de

capteurs: l’architecture et la réactivité.

Le tableau III.1 résume les états des systèmes de gestion du réseau de capteurs en

fonction des choix du système.

Système de gestion de RCSF Réactivité Architecture

WinMS

DSN RM

Mobile agent-based policy management

Intelligent agent-based power management

Siphon

BOSS

Sympathy

Proactive

Proactive

Proactive

Proactive

Proactive

Proactive

Proactive

Hiérarchique

Hiérarchique

Hiérarchique

Distribué

Distribué

Centralisé

Centralisé

SenOS

Agilla

Node-energy level management

Réactive

Réactive

Réactive

Hiérarchique

Distribué

Distribué

Two-phase monitoring system détection de

défaut

Distribué

TopDisc

AppSleep

RRP

STREAM

Sectoral Sweeper

TinyDB

Mote-View

SNMS

Passive

Passive

Passive

Passive

Passive

Passive

Passive

Passive

Hiérarchique

Hiérarchique

Hiérarchique

Hiérarchique

Distribué

Centralisé

Centralisé

Centralisé



MANNA N /A

(non attribué)

N/A

Tableau III.1: Organisation du système de gestion de réseau [57]

III.6.1. Gestion de réactivité

Les systèmes de gestion de RCSF peuvent être classés en fonction de l'approche

adoptée pour la surveillance et le contrôle:

La surveillance passive : Le système recueille des renseignements sur les

états du réseau. Il peut effectuer une analyse post-mortem des données.

surveillance de détection de défaut : Le système recueille des renseignements

sur les états du réseau afin de déterminer si les défauts ont eu lieu [84].

Le suivi réactif : Le système recueille des renseignements sur les états du

réseau pour détecter si des événements d'intérêt ont eu lieu, puis reconfigurer

le réseau adaptatif.

surveillance proactive : Le système recueille et analyse activement les états

du réseau pour détecter les événements passés et à prédire des événements

futurs afin de maintenir la performance du réseau [57].

III.6.2. Architecture de gestion

Les systèmes de gestion du réseau de capteur peuvent également être classés en

fonction de leur architecture de réseau [85]: centralisé, distribué, ou hiérarchique.

III.6.2.1. Les systèmes de gestion centralisés

Dans les systèmes de gestion centralisés, comme BOSS [62], Mote-View [73],

SNMS [65], et la sympathie [72], la station de base agit comme la station de gestionnaire

qui recueille les renseignements de tous les nœuds et contrôle l'ensemble du réseau. Le

gestionnaire central avec des ressources illimitées peut effectuer des tâches complexes de

gestion, en réduisant la charge de traitement sur les nœuds de ressources limitées dans le

réseau de capteurs. Le gestionnaire central a également la connaissance globale du

réseau, il peut fournir des décisions de gestion précises. Mais, cette approche a quelques

problèmes. Premièrement, il encourt un haut message tête (de la bande passante et de

l'énergie) à partir des sondages de données, ce qui limite son évolutivité. Deuxièmement,

le serveur central est un point de concentration du trafic de données et de l'échec potentiel



unique. Enfin, si un réseau est partitionné, les nœuds qui sont incapables d'atteindre le

serveur central sont laissés sans aucune fonction de gestion [57].

III.6.2.2. Les systèmes de gestion distribués

Les systèmes de gestion distribués emploient les stations de gestionnaire

multiples. Chaque gestionnaire contrôle un sous-réseau et peut communiquer directement

avec d'autres stations de gestionnaire d'une manière coopérative afin d'exécuter des

fonctions de gestion. Le système distribué a des coûts de communication plus bas que la

gestion centralisée, et fournit ainsi une meilleure efficacité de la fiabilité et de l'énergie.

Mais il est complexe et difficile à gérer. Les algorithmes de gestion distribués peuvent

être de calcul trop cher pour les nœuds de réseaux de capteurs de ressources limitées [57].

Les systèmes de gestion distribués comprennent DSN RM [83], la gestion de niveau

d'énergie du nœud [77], App-sleep [76], et l'optimisation de la gestion des capteurs [86].

Un autre inconvénient des systèmes distribués est les coûts de mémoire. Par

exemple :

L'entretien de diagramme de transition pour l'état de voisinage dans la TP

[87] ; un mécanisme d'auto-surveillance distribuée efficace, appelé un

système de surveillance de l'auto en deux phases (TP) qui est conçu pour le

contrôle et la surveillance de réseaux de capteurs.

La tâche de profil d'utilisation dans la maintenance du niveau de gestion

d’énergie du nœud [77].

L'entretien de l'espace tuple dans Agilla [67]

Tous ces exemples nécessitent des ressources de mémoire importantes.

Un cadre à base d'agent mobile est un exemple de mise en œuvre du système

distribué de gestion. Les systèmes de gestion de réseau qui utilisent cette approche sont

Agilla, sectorielle Sweeper [68], Mobile Agent-Based Policy Management [69],

Intelligent Agent-Based Power Management [70], et MANNE [58]. Les principaux

avantages de ces approches sont que la transformation locale réduit les besoins en bande

passante réseau et empêche l’étranglement des goulets du réseau en réduisant le

traitement au serveur central [69]. En outre, les agents peuvent être conçus pour répartir

les tâches dans le réseau. Par exemple, les agents peuvent relayer certaines tâches de

nœuds surchargés à d'autres nœuds avec faibles charges de travail. En outre, les agents

peuvent être déplacés de manière flexible pour couvrir une zone d'intérêt [58] et les



agents peuvent changer le débogage et le fonctionnement de transmission des nœuds de

capteurs de faible puissance pour prolonger la durée de vie du réseau [58].

Il y a plusieurs inconvénients des approches à base d'agents. Premièrement, il y

a un besoin pour les nœuds spéciaux pour effectuer des tâches de gestion. Deuxièmement,

le gestionnaire humain a besoin pour localiser 'intelligemment' ces agents afin de couvrir

tous les nœuds du réseau. Ainsi, cette approche nécessite un réseau pour être configuré

manuellement et le gestionnaire humain doit avoir une expertise sur le nombre optimal

d'agents ainsi que l'emplacement de l'agent pour une application de réseau de capteur

particulier. Troisièmement, l'approche agent-based introduit des retards quand un

gestionnaire veut récupérer les états du réseau d'un nœud parce que le gestionnaire doit

attendre un agent pour visiter le nœud [88]. Quatrièmement, l'approche basée sur l'agent

ne s’adapte pas pour les grands réseaux de capteurs parce que le nombre de nœuds de

capteurs augmente, d’où le nombre d'agents déployés doit être augmenté. En variante, la

réduction du nombre d'agents augmente le temps requis pour la visite des nœuds dans un

réseau. Enfin, puisque l'agent envoie généralement des informations de gestion agrégé

parmi un ensemble de nœuds gérés dans un réseau, les informations à grain fin de nœuds

individuels sont compromises [58].

III.6.2.3. Les systèmes de gestion hiérarchique

La gestion du réseau hiérarchique est un hybride entre l'approche centralisée et

distribuée. Les gestionnaires intermédiaires sont utilisés pour distribuer des fonctions de

gestion, mais ne communiquent pas directement entre elles [69].

Chaque gestionnaire est responsable de la gestion des nœuds dans son sous-

réseau. Il transmet les informations à partir de son sous-réseau à son gestionnaire de

niveau supérieur, et diffuse également des fonctions de gestion reçues du gestionnaire de

niveau supérieur à son sous-réseau [69]. Par exemple, dans AppSleep [76], TopDisc [57],

STREAM [88], et Senos [75], certains nœuds communes sont élus de manière sélective

en tant que chefs de cluster à agir en tant que gestionnaires distribués. Il y a une

surcharge d'énergie non négligeable pour la sélection des têtes de munitions.

Agent-based policy management [69] utilise des agents mobiles en tant que

gestionnaires distribués. Dans RRP [64], les nœuds individuels ont des rôles distincts:

soit l'acquisition de données brutes du capteur, le transport de données, ou le filtrage des

données. Contrairement à d'autres systèmes, DSN RM [83] et WinMS [66] qui permettent



aux nœuds individuels d'agir comme agents et exécutent des tâches de gestion autonome

en fonction de leurs états de quartier.

III.7. Comparaison des systèmes existants pour la gestion d’un

RCSF

Le tableau III.2 compare les systèmes de gestion du réseau de capteurs en fonction de

ces critères de gestion du réseau.

Système de

gestion de RCSF

Principales fonctionnalités de

gestion

Consom-

mation

d'énergie

Robus-

tesse

Adapt-

abilité

L'effica-

cité de la

mémoire

Evol-

utivité

WinMS Récupération de l'état du

réseau, la synchronisation,

la réparation local, et le

transfert systématique des

ressources

Oui Oui Oui Oui Oui

BOSS La récupération de l'état du

réseau, la localisation, la

synchronisation et gestion

de l'alimentation

Oui Oui Oui Oui Non

Mobile Agent-

Based Policy

Management

Cadre de gestion basée sur

des stratégies

Oui Oui Oui Oui Non

AppSleep Gestion de l'alimentation

(étendu les horaires de

sommeil)

Oui Oui Non Oui Oui

Intelligent

Agent-

Based Power

Management

Gestion de l'alimentation

locale et l'échantillonnage

de contrôle de fréquence

Oui No Oui Oui Non

Sympathy Débogage de défaut Oui Oui Oui Oui Non

Two-Phase

Monitoring

System

Les systèmes de détection

de défauts locaux

Oui Oui Non Oui

SNMS La collecte de données de

performance fondé sur une

Oui Oui Oui Oui Non



requête réseau et la

journalisation des

événements

Mote-View visualisation et

récupération de l'état de

réseau

Oui Non Oui Non

Agilla La détection de

l'événement

Oui Non Non Oui Non

STREAM Extraction de la topologie

du réseau

Oui Non Non Oui Oui

TopDisc La récupération de l'état du

réseau (par exemple, la

topologie du réseau et de

l'énergie de niveau de

nœud)

Oui Non Oui Oui Oui

RRP L'agrégation des données

et régime de la zone-

inondations

Oui Non Non Oui Non

Sectoral

Sweeper

Noeud de commutation on

/ off

Oui Non Non Oui Non

Node-Level

Management

Gestion de l'alimentation

(rejet de la tâche)

Oui Non Non Oui Non

SenOS Noeud de commutation on

/ off

Oui Non Non Oui Non

DSN RM La gestion du trafic en

fonction des priorités et de

la congestion stratagème

d'évitement

Oui Non Oui Non Non

Siphon La gestion du trafic à la

demande multi-radio

No Non Oui Oui Non

MANNA Cadre fondé sur la

politique de gestion, la

récupération de l'état du

Na Na Na Na Na



réseau, contrôle de la

fréquence

d'échantillonnage,

l'entretien de la couverture,

et la détection de défaut

Tableau III.2 : Système de gestion de réseau évalué par rapport aux critères de conception [57]

III.8. Le protocole SNMP pour les RCSFs

Simple Network Management Protocol (SNMP) est le cadre de gestion de réseau

standard pour les réseaux IP traditionnels, mais il ne peut pas être déployé directement sur les

réseaux de capteur en raison de diverses caractéristiques du RCSF:

En contraint de ressource et de bande passante limitée en RCSF, on ne peut pas

mettre un message SNMP.

SNMP n’aborde pas spécifiquement le problème d’échec-nœud comme

phénomène commun, qui est courant dans les réseaux de capteurs.

SNMP nécessite d'énormes une base de donnée de gestion (MIB) et les nœuds

de capteurs ne peuvent généralement pas soutenir une telle exigence de stockage

[89].

Une implémentation de SNMP sur 6LoWPAN est présentée dans [90] où les auteurs ont

utilisé la compression d'en-tête et de transitaire proxy pour que le 6LoWPAN supporte le

SNMP.

Dans [91], les auteurs proposent la surveillance de la performance des patients mobiles

et éloignés à l'aide des capteurs de type Micaz connectés à l’internet. L’implémentation de

Proxy-SNMP assure la disponibilité des données, réduit la consommation d’énergie et la

puissance de calcul et améliore l’interface graphique. La lecture de fichier « logfile » nécessite

l’intégration de SNMP4J [92]. L’architecture de ce système comporte deux types de capteur : un

pour les données sanitaires et l’autre pour l’environnement (mesure de température). Les

capteurs sont connectés à un PC à travers un gateway.



III.9. Conclusion

Les réseaux de capteurs sans fil représentent une nouvelle frontière dans le

développement de la technologie pour être utilisés dans une variété d'applications de notre vie

quotidienne à l'avenir.

Comme un nouveau domaine de recherche, il y a plusieurs problèmes ouverts qui

doivent être étudiés. L'un d'eux est la gestion de ces réseaux. En se basant sur la collecte de

différentes informations comme le contrôle de l’énergie .La tâche de construire des systèmes de

gestion dans les environnements où il y aura des dizaines de milliers d'éléments de réseau avec

des fonctionnalités et des organisations particuliers est très complexe.

Comme indiqué précédemment, il existe plusieurs différences importantes dans la

gestion des RCSFs. Par conséquent, nous avons proposé un système de gestion des RCSFs afin

de maximiser la durée de vie de réseaux.

Chapitre IV MODELISATION ET CONCEPTION


IV.1. Introduction

Notre objectif dans ce chapitre consiste à traiter le problème de supervision des RCSFs

et à développer un nouveau protocole de gestion basé sur le protocole SNMP, afin de réaliser un

système de supervision, capable d'accéder aux différents paramètres d'un nœud pour une gestion

centralisé.

Pour cela on a utilisé le langage UML pour modéliser le problème de façon standard et

aussi la théorie des graphes pour effectuer des méthodes de gestion du réseau de capteurs sans

fil, il ne s’agit ni d’un modèle d’analyse ni d’un modèle d’exécution mais juste une spécification

formelle pour faciliter la rédaction des algorithmes proposés afin d’homogénéiser leur

présentation. Notre modélisation avec l’UML peuvent être enrichies et réutilisés pour répondre à

d’autres objectifs dans d’autres études relatives aux RCSF.

IV.2. Etude Préliminaire

IV.2.1. Présentation du projet à réaliser

Le système de supervision a pour objectif d’assurer le bon déroulement d’une

mission en présence des problèmes et de gérer le meilleur fonctionnement possible. De ce

principe, les objectives principale de notre approche sont maximiser la durée de vie de réseau

par la minimisation de la consommation d’énergie ainsi la gestion de réseau par le concept de

supervision à l’aide d’un protocole de gestion, on sait que le standard SNMP est le protocole de

gestion le plus répondu actuellement qui permet de gérer a distant c’est pour ça on a proposé le

protocole SWSNMP qui est basé sur le SNMP, mais qui prend en considération les contraintes

de capteur.

IV.2.1.1. Le modèle formel de présentation

Nous proposons de modéliser explicitement le système de supervision des capteurs

en fonction des activités effectuées : la collecte d’informations, la réception de données,

l’envoi de données, le traitement d’informations, la détection et en fonction des états du

capteur : la veille, la redondance, etc. Nous modélisons notre RCSF par un graphe non orienté

G (V, E) où V est l’ensemble des nœuds et E l’ensemble des liens entre les nœuds dont

chaque nœud a des liens seulement avec leur voisin selon le rayon de connectivité. Nous

supposons un fonctionnement synchronisé du réseau, i.e. tous les capteurs sont actifs aux

mêmes intervalles de temps. Nous supposons également que le réseau est homogène (capteurs



identiques), que le niveau de charge initial est identique pour tous les capteurs et que la

décharge des batteries est linéaire.

Dans ce contexte, nous définissons la durée de vie du réseau comme la première

fois qu’un groupe de capteurs ne peut plus transmettre d’informations au(x) sink(s).

Nous avons jugé utile de donner en premier lieu quelques définitions :

Définition 1 :

Dans le contexte de cette mémoire, nous définissons théoriquement la durée de

vie du réseau comme étant la durée entre l’instant de déploiement du RCSF et

l’instant à partir duquel le réseau ne devient plus travaillé de façon optimal.

Notons qu’il existe d’autres définitions du concept ‘durée de vie du réseau’ qui

peuvent être consultées dans [93].

Définition 2 :

La distance euclidienne entre deux points u et v dans un espace 2D est notée

d (u, v) avec ( ) √( ) ( ) (IV.1)

où (x1, y1) et (x2, y2) désignent les coordonnés des nœuds u et v dans un espace

2D respectivement, cela nous aides de détecter les voisins par le calcules des

distances, ainsi cela donne la couverture de chaque capteur et la connectivité

entre les capteurs [3].

Définition 3 :

En mathématiques, et en particulier en théorie des graphes, un point

d'articulation est un sommet (nœud) d'un graphe non orienté que si on le retire

du graphe le nombre de composantes connexes augmente. Si le graphe était

connexe avant de retirer ce sommet, il devient donc non connexe [3].

Maintenant on va donner les suppositions sur lequel notre travail a était réalisé:

Supposition 1 :

L’application de RCSF considérée est celle du monitoring environnemental où

chaque nœud du RCSF capte une grandeur physique brute (température,

humidité relative, luminosité) de type scalaire pouvant prendre des valeurs

réelles, entières.

Supposition 2 :

Tous les nœuds capteurs sont déployés aléatoirement dans un espace à 2

dimensions 2D appelé champ de captage caractérisé par la hauteur et la largeur.

http://fr.wikipedia.org/wiki/Math%C3%A9matiques

http://fr.wikipedia.org/wiki/Th%C3%A9orie_des_graphes

http://fr.wikipedia.org/wiki/Th%C3%A9orie_des_graphes

http://fr.wikipedia.org/wiki/Graphe_connexe



Supposition 3:

Dans notre RCSF on possède un seul sink caractérisé par son position (x, y).

Supposition 4 :

Le capteur est caractérisé par les paramètres suivant : l’identificateur, l’énergie

initiale, la zone de couverture radio qui est une région circulaire centrée en ce

nœud avec un rayon r appelé le rayon de couverture et le seuil redondant qui est

la valeur minimal pour définir le capteur redondant en fonction de son

identificateur.

Supposition 5:

La zone de capture d’un nœud capteur est un espace circulaire centré en ce nœud

avec un rayon r appelé le rayon de couverture.

Supposition 6 :

Deux nœuds capteurs ne peuvent être déployés exactement dans une même

position (x,y) de l’espace 2D. On utilise un déploiement qui est effectué de façon

aléatoire mais qui prendre les conditions qu’on a proposé au-dessus.

Supposition 7 :

Tous les nœuds capteurs sont identiques ou homogènes. Par exemple, ils ont le

même rayon de couverture radio r, le même rayon de connexité R et la même

source d’énergie (batterie). Chaque nœud possède une alimentation électrique

limitée dans le temps.

Supposition 8 :

Chaque nœud est capable de déterminer à tout instant sa position dans l’espace

2D.

Supposition 9 :

Chaque nœud prend une variable binaire ayant deux valeurs possibles (point

d’articulation ou non), pour trouver tous les points d'articulation dans notre

graphique (RCSF), une approche simple consiste à supprimer un par un tous les

sommets (capteur) et de voir si la suppression d'un sommet entraîne graphique

déconnecté (des capteurs isolé du réseau).

IV.2.1.2. Les fonctionnalités de protocole SWSNMP

Notre travail est destiné à la gestion et la supervision d’un RCSF à l’aide d’un

nouveau protocole de gestion SWSNMP. Les fonctionnalités principales de ce protocole

sont :



Réception des requêtes envoyées par l’administrateur.

Le traitement des requêtes qui sont un ensemble des messages de demande d’état

comme :

L’ensemble des voisins d’un capteur avec l’identificateur, l’énergie, et la

position de ces voisins, et ses voisins.

Tandis qu’on travaille dans une espace d’agriculture, on peut envoyer des

requêtes pour savoir la température, l’humidité ou la luminosité qui est capté

par le capteur.

Le pourcentage de l’énergie d’un capteur.

Envoie des réponses associes aux requêtes.

La sauvegarde des informations liées au capteur dans la MIB.

IV.2.2. Choix techniques

Cette application nécessite des outils logiciels.

On a choisi le langage de programmation Borland c++ builder versions 6 qui utilise

l’environnement Windows pour divers raisons (complexité d’implémenter un système de

supervision dans les simulateurs), et on a modélisé cette approche a l’aide de l’UML (en

utilisant le logiciel cadifra) et aussi la théorie des graphes.

IV.2.3. Identification des acteurs

Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le système,

mais d’abord nous donnons une définition de ce que c’est un acteur.

Définition : un acteur représente l'abstraction d'un rôle joué par des entités externes

(utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système

étudié [94].

Les acteurs du système identifiés sont :

Administrateur : l’administrateur peut s’authentifié, effectuer le déploiement,

donner l’ordre d’activation, activer/désactiver SWSNMP et superviser.

Sink : il peut faire les transmissions des messages.

Capteur : il peut capter par des fonctionnalités de sensation avancées (sensible

à des grandeurs physiques : température, l’humidité et la luminosité, aussi des

grandeurs d’influence : cible), recevez des messages d’information, envoyer

des messages d’information, signaler, convertir des messages de demande



d’état à une requête SWSNMP ou convertir les réponses SWSNMP à un

message de réponse d’état.

Agent SWSNMP: il peut recevoir des requêtes SWSNMP, interroger les

ressources, mettre à jour la table MIB et répondre le capteur.

Cible : elle peut influencer.

IV.2.4. Identification des messages

On va détailler les différents messages échangés entre le système et l’extérieur.

Définition : un message représente la spécification d’une communication

unidirectionnelle entre les objets qui transporte de l’information avec l’intention de déclencher

une activité chez le récepteur [94].

Le système émet les messages suivants :

L’authentification de l’administrateur soit acceptée ou refusé.

Capteurs soit liés au Sink.

les messages d'information soit reçus.

Les messages de réponse d'état soit reçus.

Supervisions soit effectuée.

Signalisation soit reçue.

Requête SWSNMP soit valide.

Réponse soit obtenue.

Détection soit signalée.

Ressource ne soit pas endommagée.

Cible détectée par le capteur.

Le système reçoit les messages suivants :

Le système reçoit un message d’authentification effectué par l'Administrateur.

Le système reçoit un message de déploiement effectué par l'Administrateur.

Le système reçoit un message d’exécution de l’activation effectué par

l'Administrateur.

Le système reçoit un message d’activation/désactivation de SWSNMP effectué

par l'Administrateur.

Le système reçoit un message de supervision effectué par l'Administrateur.



Le système reçoit un message de l’envoie d’un message de demande d'état

effectué par l'Administrateur.

Le système reçoit un message d’activation des capteurs effectué par le Sink.

Le système reçoit un message de la transmission des données effectué par le

Sink.

Le système reçoit un message de conversion d’un message de demande d’état

à une requête SWSNMP effectué par le Capteur.

Le système reçoit un message de l’envoi de la réponse vers l'administrateur

effectué par le Capteur.

Le système reçoit un message de signalisation effectué par le Capteur.

Le système reçoit un message d’interrogation de la ressource effectué par

L’Agent SWSNMP.

Le système reçoit un message de réponse vers le capteur effectué par l’Agent

SWSNMP.

Le système reçoit un message d’ajout d’un nouvel capteur effectué par

l’administrateur.

Le système reçoit un message d’influence effectué par la Cible.

IV.2.5. Modélisation du contexte

A partir des informations obtenues lors des deux précédentes étapes, nous allons

modéliser le contexte de notre système.

Ceci va nous permettre dans un premier temps, de définir les rôles de chaque acteur

dans le projet :

Utilisateurs finaux

Description des besoins fonctionnels

Administrateur Le projet doit permettre à l’Administrateur de :

S’authentifier

Effectuer le déploiement

Exécuter l’activation

Activer/désactiver le SWSNMP

superviser

Contrôler la simulation

Analyser et visualiser les résultats du système

Sink Le projet doit permettre au Sink de :

Activer les capteurs

Transmettre les données



Tableau IV.1 : Les rôles des acteurs

IV.3. Capture des besoins Fonctionnels

Cette phase représente un point de vue « fonctionnel » de l’architecture du système. Par

le biais des cas d’utilisation, nous serons en contact permanent avec les acteurs du système en

vue de définir les limites de celui-ci, et ainsi d'éviter de s’éloigner trop des besoins réels de

l’utilisateur final.

IV.3.1. Déterminer les cas d’utilisations

Définition : Un cas d’utilisation représente un ensemble de séquences d’actions

réalisées par le système et produisant un résultat observable intéressant pour un acteur

particulier. Un cas d’utilisation modélise un service rendu par le système. Il exprime les

interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur concerné. [94]

IV.3.1.1. Identification des cas d’utilisation

L’identification des cas d’utilisation une première fois, nous donne un aperçu

des fonctionnalités futures que doit implémenter le système.

Cas d’utilisation

Acteur principal

Messages émis/reçus par les acteurs

S'authentifier Administrateur Reçoit : Entrer le nom et le mot de passe,

valider ou refuser ces derniers

Emet : le nom et le mot de passe

Effectuer le déploiement Administrateur Reçoit : Entrer les caractéristique de

déploiement, valider ces derniers

Emet : les caractéristiques de déploiement

Capteur Le projet doit permettre au capteur de :

Capter par des fonctionnalités de sensation

avancées

Recevoir et envoyer les informations

Traiter les données

Détecter les cibles selon le rayon de couverture

Signaler

Agent SWSNMP Le projet doit permettre à l’Agent SWSNMP de :

Recevoir les requêtes SWSNMP

Valider les requêtes SWSNMP

Interroger les ressources

Mis à jour la MIB

Envoyer les réponses SWSNMP

Cible Le projet doit permettre au Cible de :

Influencer sur le capteur selon le rayon de

couverture de ce dernier



Donner l’ordre

d’activation

l'activation

Administrateur Emet : Donner l’ordre d’activation

Superviser Administrateur Reçoit : l’ensemble des opérations de

supervision et les identificateurs des

capteurs

Emet : Choisir l’opération désignés et le

capteur Spécifié que vous voulez superviser

Envoyer le message de

demande d’état

Administrateur Emet : Transmettre un message de

demande d’état d’un capteur ou de tous les

capteurs

Recevoir le message de

réponse d'état

Administrateur Reçoit : Recevoir un message de la

réponse de demande d’état

Activer les capteurs Sink Reçoit : faire la transmission de message

d’activation de tous les capteurs

Recevoir le message

d'activation

Capteur Reçoit : Recevoir un message qui va le

Faire marcher

Envoyer le message

d'informations

Capteur Emet : envoyer un message pour informer

une chose spécifique


demande d'état

Capteur Reçoit : recevoir un message de voir l’état

d’une ressource

Convertir et envoyer Capteur Emet : changer le message en une requête

SWSNMP et donner à l’agent SWSNMP

Recevoir une requête

SWSNMP

Agent SWSNMP Reçoit : questionner par une requête

SWSNMP

Mettre à jour MIB et

répondre Agent SWSNMP Emet : renouveler les valeurs de la table

MIB et donner la réponse de la requête

SWSNMP

Recevoir et convertir Capteur Reçoit : prendre la réponse de la requête

Emet : Changer la requête SWSNMP en

un message de réponse


réponse d'état

Capteur Emet : Donner la réponse de demande

d’état à l’administrateur

Influer Cible Emet : faire un effet sur le capteur

Détecter et signaler Capteur Reçoit : découvrir un événement

malveillant

Emet : transmettre un message de

signalisation

Tableau IV.2 : Les fonctionnalités des cas d’utilisation



System

S'authentifier Effectuer le déploiment Donner l'ordre

d'activation


Recevoir le message d'activation


demande d'état

Recevoir le message de demande d'état

Envoyer le message de réponse d'état

Superviser

Envoyer le message d'informations

Detecter et signaler

Influer


réponse d'état

Admin

Sink

Capteur

Créer une requêtte SWSNMP

Interogation de la ressource

Recevoir une requêtte SWSNMP

Agent SWSNMP

La route soit valide

Admin soit présent

Cible

<<include>>

<<include>>

Convertir et envoyer

Recevoir et convertir

Recevoir une requête SWSNMP

Mettre à jour MIB et

Répondre

Capter de l'environnement

Ressource ne soit pas endommagée

<<extend>>

Figure IV.1 : Diagramme de cas d’utilisation

IV.3.2. Description préliminaire des cas d’utilisations

Voici une description préliminaire des cas d’utilisations énumérés précédemment :

S'authentifier

Intention: Activer les menus.

Actions: Entrer le nom et le mot de passe de l’administrateur.

Effectuer le déploiement:

Intention: Effectuer les fonctionnalités qui concernent cette étude.

Actions: Entrer les caractéristiques de déploiement.


Intention: Changer l’état du capteur de l’état inactif à l’état écoute pour qu’il soit

en marche.

Actions: Faire marcher les capteurs par l’envoie de message d’activation.

Envoyer le message d'informations

Intention: Connaitre tous les événements qui se produisent dans le RCSF



Actions: Informer les capteurs ou l’administrateur d’un événement produit.

Superviser:

Intention: Gérer notre RCSF.

Actions: Effectuer des opérations sur les capteurs.

Mettre à jour MIB et Répondre

Intention: Construire l’information de la réponse SWSNMP et écraser la valeur

ancien de cette information par la nouvel.

Actions: Renouveler la table MIB et envoyer la réponse.

Détecter et signaler

Intention : Capter les cibles et informer l’administrateur pour cette cible.

Actions: Découvrir les cibles et envoyer un message de signalisation.

IV.3.3. Description détaillée des cas d’utilisations

Nous allons maintenant détailler un ensemble des cas d’utilisation qui doit faire l’objet

d’une définition a priori qui décrit l’intention de l’acteur lorsqu’il utilise le système et les

séquences d’actions principales qu’il est susceptible d’effectuer. Ces définitions servent à fixer

les idées et n’ont pas pour but de spécifier un fonctionnement complet et irréversible.

Remarque : les descriptions vont être organisées de la façon suivante :

Une description détaillée : des Pré-conditions au déclenchement du cas d’utilisation

doivent être spécifiées, un scénario nominal décrivant celui-ci additionné à des

scénarios alternatifs et d’exceptions.

Les diagrammes (optionnelle): plusieurs diagrammes vont apparaitre (mais pas

nécessairement) pour apporter une compréhension additive au cas d’utilisation.

1. S'authentifier

Descriptions des enchaînements :

Pré-conditions :

Le système est exécuté.

Scénario nominal :

Ce cas d’utilisation commence lorsque l’administrateur pense à activer le menu

pour faire quelques opérations spécifiques.

Enchaînement (a) : s’authentifier

o L’administrateur entre son nom, il entre aussi le mot de passe, il click

ensuite sur ok.

o Si le nom ou le mot de passe n’est pas juste alors déclencher:



[Exception 1]

Ce cas d’utilisation se termine lorsque l'administrateur ait de résultat (nom et

mot de passe valider ou refuser).

Exception :

Un message est affiché à l’écran avisant l’administrateur que le nom ou le mot

de passe est incorrecte.

Diagramme d’activités:

Voici un diagramme d’activités représentant l’enchainement des événements

pour le cas d’utilisation : s’authentifier.

Figure IV.2 : Diagramme d’activité- s’authentifier

2. Envoyer le message d'informations


Pré-conditions :

Le capteur reçoit un message ou bien une exception produit dans ce capteur

lui-même.



Scénario nominal :

Ce cas d’utilisation commence lorsque le capteur pense à répondre à un

message reçus par un message d’information ou lorsque son énergie est

épuisée.

Enchaînement (a) : Envoyer un message d'alerte

o L’énergie de ce capteur est épuisée, le capteur crée un message d’alerte, il

envoie ce message à leur voisin et à l’administrateur.

o Si un des voisins de ce capteur est redondant donc ce message d’alerte est

considérer comme un message de commutation qui va changer l’état de capteur

redondant à l’état écoute.

o Le message d’alerte ou de commutation est considéré comme un message

d’information

Enchaînement (b) : Envoyer un message d’information

o Le capteur reçoit un message, il traite leur contenu s’il par exemple touve

que le contenu est un message d’activation, il envoie un message a leur voisin

pour informer et détecter leur voisins.

Ce cas d’utilisation se termine lorsque le capteur termine l’envoie de message.

3. Superviser:


Pré-conditions :

Le protocole SWSNMP est activé.

Scénario nominal :

Ce cas d’utilisation commence lorsque l’administrateur pense à superviser et

surveillé le réseau pour gérer et contrôler le RCSF.

Enchaînement (a) : Energie du capteur

o L’administrateur clique sur superviser, il choisit «Energie du capteur» et il

choisit l’identificateur du capteur ou bien tous les capteurs puis il envoie le

message de demande d’état.

o le dialogue ente l’administrateur et le capteur ce fait à l’aide de l’Agent

SWSNMP, ce dernier qui va créer la réponse qui est l’énergie se forme

pourcentage.



Enchaînement (b) : Température mesurée par le capteur

o L’administrateur clique sur superviser, il choisit «Température mesurée

par le capteur» et il choisit l’identificateur du capteur ou bien tous les capteurs

puis il envoie le message de demande d’état.


SWSNMP, ce dernier qui va créer la réponse qui est la température par l’unité

de mesure.

Enchaînement (c) : Humidité mesurée par le capteur

o L’administrateur clique sur superviser, il choisit «Humidité mesurée par le

capteur» et il choisit l’identificateur du capteur ou bien tous les capteurs puis il

envoie le message de demande d’état.


SWSNMP, ce dernier qui va créer la réponse qui est l’humidité par l’unité de

mesure.

Enchaînement (d) : Luminosité mesurée par le capteur

o L’administrateur clique sur superviser, il choisit «Luminosité mesurée par

le capteur» et il choisit l’identificateur du capteur ou bien tous les capteurs puis

il envoie le message de demande d’état.


SWSNMP, ce dernier qui va créer la réponse qui est la luminosité par l’unité

de mesure.

Enchaînement (e) : Voisinage du capteur

o L’administrateur clique sur superviser, il choisit «Voisinage du capteur» et

il choisit l’identificateur du capteur puis il envoie le message de demande

d’état.

o Le dialogue ente l’administrateur et le capteur ce fait à l’aide de l’Agent

SWSNMP, ce dernier qui va créer la réponse qui est les voisin de ce capteur.

Enchaînement (e) : l’arrête du capteur

o L’administrateur clique sur superviser, il choisit «Arrêter le capteur» et il

choisit l’identificateur du capteur puis il envoie le message de demande d’état.





Enchaînement (e) : l’activation du capteur

o L’administrateur clique sur superviser, il choisit «Activer le capteur» et il

choisit l’identificateur du capteur puis il envoie le message de demande d’état.



Ce cas d’utilisation se termine lorsque l’administrateur reçoit la réponse.

Diagramme d’activités:

Voici un diagramme d’activités représentant l’enchainement des événements

pour le cas d’utilisation : Superviser.

Figure IV.4 : Diagramme d’activité- superviser

IV.4. Développement du modèle dynamique

Le développement du modèle dynamique constitue la troisième activité de l’étape

d’analyse. Il s’agit d’une activité itérative, fortement couplée avec la modélisation statique [95].

IV.4.1. Identification des scénarios

Un cas d’utilisation décrit un ensemble de scénarios. Un scénario décrit une

exécution particulière d’un cas d’utilisation du début à la fin.il correspond à une

sélection d’enchainements du cas d’utilisation [95].

Nous avons plusieurs scénarios à étudier du même cas d'utilisation au

diagramme de séquence classé par Acteur.

Cliquer sur

activer

SWSNMP

Cliquer sur

superviser

choisir un des options à

effectué

choisir un des capteur ou tous les capteur

Cliquer sur

message de

controle



IV.4.1.1. Scénarios de l’Administrateur

:Admin :System

S'authentifier

Authentification réussie

:Sink

Donner l'ordre d'activation

Capteurs soitent liés au Sink Reception de

messages d'information

Envoyer le message de demande d'état

[Protocole SWSNMP soit prix en charge]

Reception de message de réponse d'état

Recevoir le message de signalisation

Signalisation reçue

Superviser

Supervision effectuée

Figure IV.5 : Diagramme de séquences – Administrateur

IV.4.1.2. Scénarios du Sink

:Sink :System

Recevoir l'ordre d'activation

:Capteur


Capteur soit lié au Sink

Reception de messages d'informations

Transmettre les données

Figure IV.6 : Diagramme de séquences – Sink



IV.4.1.3. Scénarios du Capteur

Noeud :Capteur :System

Recevoir le message d'activation

Message d'informations reçu

Recevoir un message de demande d'état

[SWSNMP soit prix en charge]

Requête soit valide

Réponse obtenue

:Cible

Detecter

[Cible soit couverte]

Signaler

Detection signallée

Envoyer vers l'administrateur

[Convertir la requêtte]

Message reçu

Convertir le message à une requête SWSNMP

:Agent_SWSNMP

Figure IV.7 : Diagramme de séquences – Capteur

IV.4.1.4. Scénarios de l’Agent SWSNMP

:Agent_SWSNMP :System

[Requêtte soit valide]

Interroger la ressource

Ressource ne soit pas endommagée

Réponse obtebue

[Mettre à jour la table MIB]

Repondre le capteur

Réponse obtenue par le capteur

Recevoir une requêtte SWSNMP

Figure IV.8 : Diagramme de séquences – Agent SWSNMP



IV.4.1.5. Scénarios de la Cible

:Cible :System

Influencer

Cible détectée par le capteur

Figure IV.9: Diagramme de séquences – Cible

IV.4.2. Construction des diagrammes d’états

On recourt au concept de machine à états finis, qui consiste à s’intéresser au cycle de

vie d’un objet générique d’une classe particulière au fil de ses interactions avec les autres

classes, dans tous les cas possibles. Cette vue locale d’un objet, décrivant comment il réagit à

des événements en fonction de son état courant et passe dans un nouvel état, est représentée

graphiquement sous forme d’un diagramme d’états.



8

1

3

2

4

5 6

8

11

12

3

2

4

10 6

7 9

1. Recevoir le message d'activation

2. Reception

3. Periode d'attente ecoulée

13 13

4. Fin de la reception

5. Fin de traitement

6. Fin d'envoie

7. Reponse à la detection

8. Epuisement d'énergie

9. Transition vers envoie oligatoire

10. Transition vers envoie probable

11. l'Administrateur active le protocole SWSNMP

12. l'Administrateur désactive le protocole SWSNMP

7

2 2

13. Recevoir le message de commutation

14. Influence

14

14

14

Redondant

Inactif

Redondant

More

En ecoute

idle

En Reception

En traitement

En envoie

En detection

En ecoute

idle

En Reception

En traitement

En envoie

En detection

Mode Capteur Inactif

Mode SWSNMP activé

Mode SWSNMP Désactivé

Mode CapteurActif

14

Mode CapteurActif

Figure IV.10 : Diagramme d’état



IV.5. Développement du modèle statique

Le développement du modèle statique constitue la deuxième étape d’analyse. Les

diagrammes de classes établis sommairement dans le diagramme de classe. Il s’agit d’une

activité itérative, fortement couplée avec la modélisation dynamique [95].



Admin

Capteur

«Identificateur» Position Energie Rayon

+Recevoir() -Convertir() -Envoyer() -Signaler() #Donner() #Prendre()

Agent_SWSNMP

«Identificateur» Occupe

#Recevoir() #Interroger() #MAJ_MiB() #Envoyer()

Cible

«id» Position

Influer()

Sink

«Identificateur» Position

Activer_les_capteur() Transmettre()

id=0

Table_MIB

«Identificateur» M_a_jour

Ressource

«Identificateur»

Reseau

n

1

1 Gerer ler reseau 1

Detecter Sauthentifier() Effectuer_le_deploiement() Donner_lOrdre_dActivation() Lancer_le_systeme() Activer/Désactiver SWSNMP Superviser() Envoyer_msg_demande_etat() Recevoir_Message()

Hauteur Largeur Nombre_Capteurs SWSNMP _Actif Seuil_Redondance Energie Rayon

Figure IV.11 : Diagramme de classe



IV.6. Conclusion

Avec la modélisation tous deviendra clair, et la réalisation de quelques diagramme, tel

que ceux de la modélisation dynamique exige la compréhension abstraite de système à réaliser,

et d’une autre partie la modélisation statique permet de bien articuler la structuration des objets

ainsi leurs associations.

Cela simplifie la tâche de développement et d’implémentation de notre approche et

facilite notre travail pour maitre en pratique notre système de supervision de RCSF.

Chapitre V IMPLEMENTATION ET REALISATION


V.1. Introduction

L'idée principale de notre travail est la réalisation d’une application qui permettra de

superviser et gérer notre RCSF.

La conception des réseaux de capteurs nécessite un investissement très important,

matériel et logiciel. Ainsi la moindre erreur dans la conception peut coûter cher. Il est donc

impératif de passer par la simulation qui permet de réduire les coûts de fabrication en réduisant

les risques d’erreurs.

Notre objectif est donc double : concevoir une plateforme capable de superviser un réseau

avec toutes ces caractéristiques, et de simuler le processus de gestion du réseau, tout en

visualisant son comportement.

V.2. Langage utilisé

Nous avons développé notre application de simulation à l’aide du langage Borland C++

Builder qui utilise l’environnement Windows.

Borland C++ builder est un environnement de programmation visuel orienté objet

permettant le développement d’applications en vue de leur déploiement sous Windows ou Linux.

La programmation orientée objet (POO) répond à ces besoins. Elle fournit les techniques

permettant de traiter des applications très complexes, exploite des composants logiciels

réutilisables et associe les données aux tâches qui les manipulent [96].

La caractéristique essentielle de la programmation orientée objet est de modéliser des

"objets" (c’est-à-dire des concepts) plutôt que des "données". Ces objets peuvent être des

éléments graphiques affichables, comme des boutons ou des zones de liste, ou des objets réels,

comme des capteurs [96].

Les objets possèdent des caractéristiques, également appelées propriétés ou attributs,

comme identificateur, énergie. Le rôle de la programmation orientée objet est de représenter ces

objets dans le langage de programmation.

Borland C++ builder repose sur un ensemble très complet de composants visuels prêts à

l’emploi. La quasi-totalité des contrôles de Windows (boutons, boîtes de saisies, listes

déroulantes, menus et autres barres d’outils) y sont représentés. Les caractéristiques du C++ en

font un langage idéal pour certains types de projets. Il est incontournable dans la réalisation des

grands programmes. Il dispose d’un grand nombre de fonctionnalités (par exemple, un

générateur pseudo-aléatoire). Son contrôle d’erreurs est accru, basé sur un typage très fort, qui



permet de signaler un grand nombre d’erreurs à la compilation. Il permet aussi de créer des

exécutables et des DLL. Il est à la fois facile à utiliser et très efficace [97].

V.3. Algorithme

Notre algorithme est représenté dans la figure V.1.

V.4. Scénario utilisé

L’approche utilisée se base sur l’utilisation des capteurs qui collectent : les informations

de l’environnement (la température, l’humidité et la luminosité), Les informations concernant le

capteur lui-même et ses voisins (état de la batterie, position des voisins) et également le nombre

de voisins des voisins. Le sink diffuse et transmet les messages. Les capteurs répondent aux

requêtes en envoyant la requête à l’agent SWSNMP qui interroge les ressources et construit la

réponse de façon qu’il soit compréhensible par l’administrateur.

Le réseau conçu est de taille 600*1000 m2. La distribution des nœuds capteurs dans le

réseau est aléatoire. Le nombre maximal de nœuds est de 55 déployés aléatoirement. Les

coordonnées du sink sont (400, 80). Dans notre cas, nous avons utilisé la distance euclidienne

entre les nœuds et le sink. Chaque nœud du réseau a une portée de signal de 80 mètres. Le seuil

de redondance est ajusté par 50 mètre et l’énergie initiale par 1000nJ.



Figure V.1: Notre algorithme (Scénario de la simulation(

Début Lancer le projet S'authentifierEffectuer le

déploiment

Les capteurs échangent les messages d'information et

prennent l'état écoute

Donner l'ordre

d'activation

Choisir le capteur

Découvrir les

points

d'articulation

Les capteurs detectent

les cibles selon le rayon

de couverture

Ajouter des capteurs a coté de chaque

point d'articulation et mettre en etat

redandant

Choisir

l'opération a

efféctué

Envoyer le message

de demade d'état

Recevoire le

message de réponse

d'état

Analyser et suivre

les résultats

Placer des cibles

dans le réseaux

Fin

récrire les

informations

Oui Authentification valide

Non

les capteurs superflu prennent l'état redondant

Les capteurs envoient

un message de

signalisation

les capteurs

bascule en mode

veille

Régler le probléme

de la cible

Activer

SNMP-Sensor

Oui

SuperviserUtiliser les

messages de

controle

Activation

SNMP-Sensor

efféctue

Non

Système de supervision des réseaux



V.5. Implémentation

Nous allons commencer à donner un aperçu sur les messages implémentés, ensuite nous

entrons dans le cœur des algorithmes implémentés.

V.5.1. Structure des messages utilisés

Les messages utilisés sont structurés comme suit :

Tel que :

Identificateur c’est l'identifiant de message

Emetteur c’est l’identificateur de l’émetteur

Récepteur c’est l’identificateur du récepteur

Contenu c’est la teneur de message.

Flag c’est le type de message, dans notre cas on a les flags suivant :

Les messages de type flag activation basculent le capteur de l’état inactif à

l’état écoute.

Les messages de type flag information sont les messages qui circule entre les

capteurs pour remplir la table de voisinage.

Les messages de type SWSNMP sont les messages utilisés pour superviser le

réseau.

Les messages de type Flag REQ Flag REP sont les messages de contrôles

utilisés pour minimiser la consommation d’énergie.

Les messages de type flag détection sont les messages de détection des cibles.

Les messages de type flag alerte sont les messages d’épuisement de l’énergie.

Message (Identificateur, Emetteur, Récepteur, Flag, Contenu)

Flag Activation

Flag Informations

Flag SWSNMP

Flag Détection

Flag Alerte

Flag REQ

Flag REP



Procédure de l’envoie d’un message :

V.5.2. L’activation des capteurs

Le premier message qui est envoyé vers les capteurs est le message d’activation. Ce

dernier permet aux nœuds de connaitre ses voisins et de remplir leur table.

L’algorithme de détection des voisins et d’activation :

Si le message est de type message influence (Flag Influence) alors

Obtenir la position (x,y) de la cible

Obtenir la position (x,y) du capteur

Si non

Si l’identificateur de l’émetteur est égal à l’identificateur du sink alors

Obtenir la position (x,y) du sink

Si non

Obtenir la position (x,y) du capteur qui va émettre

Fin si

Si l’identificateur du récepteur est égal à l’identificateur du sink alors

Obtenir la position (x,y) du sink

Si non

Obtenir la position (x,y) du capteur qui va recevoir

Fin si

Fin si

Comparer le x de l’émetteur avec le x du récepteur et comparer le y de

l’émetteur avec le y du récepteur pour trouver la direction du message (on

a 8 cas de direction)

Pour chaque capteur qui reçoit le message d’activation faire

Calculer la distance euclidienne entre ce capteur et les autres capteurs

Si la distance est inférieure au rayon de couverture alors

Insérer le capteur à la table de voisinage

Fin si



V.5.3. La redondance

La redondance d’une façon générale est utilisée pour prévenir un dysfonctionnement

dans un système. Dans le cas des RCSFs, la redondance est établie pour étendre la durée de

vie du réseau, surtout que cette dernière se rapporte au surnombre des nœuds.

La valeur du seuil redondant entré au début de déploiement est la valeur qu’on va

utiliser pour trouver si un capteur est redondant ou non.

On peut formuler l’algorithme en utilisant le principe de Gabriel [98].

L’algorithme de détection des capteurs redondant :

V.5.4. Les points d’articulation

V.5.4.1. Principe

Un sommet dans un graphe connexe non orienté est un point d'articulation si et

seulement si on le retire déconnecte le graphe. Les points d'articulation représentent les

vulnérabilités dans un réseau, le lien entre deux points d’articulation est appelé un pont, ces

Pour chaque capteur faire

Calculer la distance euclidienne entre ce capteur et les autres

capteurs

Si la distance est inférieure au seuil redondant alors

Comparer les identificateurs des deux capteurs

Fin si

Le capteur qui a l’identificateur le plus grand est celui qui va

prendre l’état redondant

Fin pour

Calculer la distance euclidienne entre le sink et les autres capteurs

Si la distance est inférieure au rayon de couverture alors

Prendre ce capteur comme voisin de sink

Fin si

Envoyer un message d’information

Fin pour

Transition de l’état inactif à l’état écoute



ponts pourrait diviser le réseau en deux ou plusieurs composants déconnectés. Leurs

connaissances est utile pour la conception des réseaux fiables [99].

Pour un graphe non orienté connexe, voici quelques exemples de graphe avec

des points d'articulation encerclés par la couleur rouge.

Figure V.2 : Exemple des points d’articulation [99]

V.5.4.2. Etapes de détection des points d’articulation [99]

Voici les étapes d’une approche simple pour un graphe connexe :

1) Pour chaque sommet v :

A) Retirez le sommet v du graphe

B) Voir si le graphe reste connecté (Nous pouvons soit utiliser BFS ou DFS

[99])

C) Ajouter v et retourner au graphe

V.5.4.3. A O (V + E) algorithme pour trouver tous les points d'articulation (AP) [99]

L'idée est d'utiliser DFS (Depth First Search). Dans DFS, nous suivons les

sommets sous forme d'arbre appelé arborescence DFS. Dans l’arborescence DFS, un

sommet u est le parent d'un autre sommet v, si v est découvert par u (évidemment v est un

côté de u dans le graphique). Dans l’arborescence DFS, un sommet u est un point

d'articulation si l'une des deux conditions suivantes est remplie :

1) si u est la racine d'un arbre DFS et il a au moins deux enfants.

2) si non u n’est pas racine de l'arbre DFS et il a un enfant de v tel qu'aucun

sommet dans le sous arbre enraciné avec v a un bord arrière d'un des ancêtres (en

arborescence DFS) de u.

L’algorithme de détection des points d’articulation de Tarjan:

Debut:

Pour chaque capteur faire

Obtenir ses voisins

Obtenir son niveau



La fonction pour faire DFS:

Marquer tous les sommets comme non visité

Créer la liste pour stocker les points d'articulation

Appeler la fonction d'aide récursive pour trouver des points d'articulation dans l'arbre

enraciné DFS avec le sommet v

Imprimer la liste des points d’articulation

Voir s’il est lié au sink ou non

S’il a des voisins et il n’est pas le sink et non lié au sink alors

Incrémenté une valeur

Fin si

Fin pour

Si cette valeur est supérieure à zéro alors

Pour chaque capteur

Si son niveau est égal au niveau obtenu alors

Lier ce capteur au sink

Si son niveau est le premier niveau alors

Appliquer la fonction qui ajoute un bord dans le graphe

Fin si

Pour chaque voisin de ce capteur faire

Si ce voisin n’est pas lié au sink et n’est pas voisin du sink alors

Appliquer la fonction qui ajoute un bord dans le graphe

Parcourir le prochain niveau

Fin si

Fin pour

Aller au début

Fin si

Appliquer La fonction pour faire DFS

Obtenir l’ensemble des points d’articulation trouvés



V.6. La supervision avec le protocole SWSNMP

L’envoie des messages de demande d’état et la réception des messages de réponse d’état

se font à l’aide de l’agent SWSNMP, qui est le responsable du traitement des requêtes

SWSNMP.

Dans chaque capteur il y a un agent SWSNMP et dans l’ordinateur de la station de base il

y a le superviseur SWSNMP.

Quand le capteur reçoit un message de demande d’état, il convertit ce message en une

requête SWSNMP et la donne à l’agent, ce dernier traite la requête et construit la réponse de

manière compréhensible par l’administrateur. Le capteur prend la réponse SWSNMP, la converti

en une réponse de demande d’état et l’envoie à l’administrateur.

Le flag de ce type de message est un flag SWSNMP.

V.7. La réalisation de la plateforme La Figure V.2 résume l’architecture générale de la plateforme réalisée avant

l’authentification de l’administrateur.

Figure V.3 : La plateforme principale

Cette interface se compose de :

Champ de captage où le Sink et les capteurs vont être placés.

Les légendes de notre réseau de capteurs contiennent les états du capteur, les

types de messages, quelques exemples d’état de la batterie du capteur et l’état de

l’environnement capté.



Figure V.4 : Les légendes

Une zone qui affiche la phase effectué actuellement.

Une zone qui affiche les identificateurs des capteurs points d’articulation.

Une zone qui affiche si le SWSNMP est activé ou désactivé.

Figure V.5 : Légende de SWSNMP

Un bouton permettant d’ajouter un capteur et un autre pour ajouter une cible.

L’interface principale se compose de plusieurs parties :

La figure V.6 illustre l’authentification de l’administrateur.

Figure V.6 : La fenêtre d’authentification

Après l’authentification l’administrateur effectue le déploiement.

Nous pouvons générer des topologies de réseaux contenant N (=35,40,…. ,55) capteurs à

l’intérieur d’un carré de largeur inférieur ou égal à 600*1000. Un seul sink est placé en haut à la

position (400,80). Des options sont ajoutées et implémentées pour la simulation pour faciliter la

modification de ces paramètres, où nous pouvons augmenter ou diminuer la charge de réseau,

changer le rayon initial, etc. La boite de dialogue illustré dans la figure. V.7 nous permet d’entrer

ces paramètres.



Figure V.7 : La fenêtre de déploiement

Figure V.8 : Déploiement aléatoire de 50 nœuds



Nous illustrons dans la figure V.9 la couverture de la portée du signal de chaque nœud et

la connectivité entre les capteurs.

Figure V.9 : La couverture et la connectivité des nœuds.

V.8. Déroulement du projet

Tout d’abord nous allons donner une vue globale sur le comportement des nœuds au sein

du réseau et leurs organisation, ensuite on détaillera les résultats obtenus graphiquement.

Figure V.10 : Activation des capteurs et découverte de voisinage.



Après l’activation des capteurs et la découverte du voisinage, deux fonctions vont être

effectuées : la première pour détecter les capteurs redondants et les bascule à l’état redondant, la

deuxième pour trouver les capteurs qui sont des points d’articulation.

Les capteurs qui sont en orange sont des points d’articulation et ceux qui sont en bleu

sont des capteurs redondants.

Figure V.11 : La redondance et les points d’articulation (49 capteur)

Figure V.12 : Les points d’articulation (34 capteurs)



La supervision qui doit être effectué par l’administrateur débutera par l’activation de

SWSNMP.

Figure V.13 : L’activation de SWSNMP

Fenêtre qui permet de choisir l’opération de supervision et le capteur :

Figure V.14 : La fenêtre de supervision



Figure V.15 : Les opérations. Figure V.16 : Les identificateurs des capteurs.

Figure V.17 : Quelque état capter par des capteurs.

Figure V.18 : Exemple d’état de la batterie.



Figure V.19 : Exemple d’une table de voisinage d’un capteur.

V.9. Résultats et discussion

Après la démarche du scénario utilisé, nous voyons que l’administrateur peut gérer son

réseau par la surveillance des états et les points faibles du réseau pour prendre des décisions

correctes.

Par exemple dans cette figure nous voyons que si un des capteurs points d’articulation

(coloré en orange) meurt, le réseau perdre sa connexité.

Figure V.20 : Les liens du RCSF.



L’histogramme suivant montre l’énergie du réseau global.

Figure V.21 : Histogramme de l’énergie du réseau.

La partie (1) est la partie où l’administrateur active les capteurs, chaque capteur envoie un

message d’information à ses voisins, l’énergie perdue (Ep) dans cette partie est égale à 1,934nJ

dans 2 unités de mesure :

Ep= 48997,637- 48995,703

Ep= 1,934nJ

Les parties (2) et (3) sont des parties où l’administrateur a produit des événements

malveillants de degrés différents, l’énergie perdue (Ep) dans ces parties est respectivement

0,809nJ dans 2 unités de mesure et 4,242 nJ dans 5 unités de mesure :

Partie (1) :

Ep= 48995,582- 48994,773

Ep= 0,809nJ

Partie (2) :

Ep= 48993,297- 48989,055

Ep= 4,242 nJ

Les parties entre (1) et (2), (2) et (3) sont des parties qui sont presque stables parce qu’il

n’y a pas d’événements dans le réseau ou des transmissions de messages, l’énergie perdue (Ep)

1

2

3



dans ces parties est respectivement 0,121nJ dans 4 unités de mesure et 0,203nJ dans 8 unités de

mesure.

La partie qui est après la partie (3) est une partie où le réseau fait des transmissions de

messages (l’administrateur interroge des capteurs de temps à autre), l’énergie perdue (Ep) dans

cette partie est égale à 0,844nJ dans 28 unités de mesure.

Donc, on voit d’après ces résultats que l’énergie consommé est concevable.

Cet histogramme montre l’énergie de chaque nœud capteur.

Figure V.22 : Histogramme de l’énergie de chaque capteur.

Les capteurs du groupe numéro (1) sont les capteurs redondants donc en voit que leur

énergie se minimise avec de très petite valeur.

Les capteurs du groupe (3) reçoivent et envoient des messages car l’administrateur

interroge se groupe de capteurs ; les capteurs de groupe (4) détectent des cibles, donc on voit que

la détection des cibles et la signalisation prend plus d’énergie que l’envoie et la réception des

messages de type SWSNMP, mais dans les deux cas, l’énergie est consommée d’une manière

concevable.

Les capteurs du groupe (2) sont des capteurs qui ne font aucune opération c’est pour cela

on voit que leur énergie est presque stable après les redondant.

1

2

3

4



L’histogramme suivant montre la totalité des nœuds en fonction du nombre de voisins :

Figure V.23 : Histogramme de la totalité des nœuds.

À travers ces résultats, nous constatons que le réseau est bien équilibré.

V.10. Conclusion

Dans ce chapitre, nous avons détaillé notre solution qui a comme but de maximiser la

durée de vie de réseaux par la gestion et la supervision des capteurs sans fil.

La gestion des capteurs dans notre solution se fait par le principe de redondance, de

point d’articulation et par l’utilisation du protocole SWSNMP. Notre solution est évaluée avec le

langage de programmation c++ qui permet de visualiser le comportement de notre réseau ainsi

que le transfert des requêtes.

Les résultats obtenus sont satisfaisants, le réseau reste connecté même si un des

capteurs a épuisé son énergie.

CONCLUSION GENERAL ET PERSPECTIVE


Conclusion générale et perspective

L’avènement récent de la technologie des réseaux de capteurs sans-fil, conjugué au progrès

de miniaturisation des composants et à l'allongement de la durée de vie des batteries, annoncent

un futur prometteur a cette technologie. De plus, le développement de nouveaux capteurs plus

performants permettra d'étendre d’avantage les domaines d'applications déjà important.

Les RCSFs constituent des domaines de recherche innovants pour diverses disciplines des

sciences et techniques de l'information et de la communication. Toutefois, avec des contraintes

spécifiques qui s’érigeant comme défis de certains problèmes à relever, parmi les problèmes

posé à l’heure actuelle dans ce type de réseaux est la supervision des RCSFs. Afin de pouvoir

administrer efficacement l'ensemble des réseaux de capteurs sans fil, nous avons étudié et classé

différents mécanismes de supervision et de gestion proposés dans la littérature spécialisée, à

travers ces études, nous avons pu dégager une solution de supervision pour les RCSFs.

Dans le cadre de notre projet, on s’est intéressé aux applications orientées événements. Cette

applications consiste principalement aux événements pertinents qui peuvent survenir dans la

zone de déploiement, on utilise les deux type de collecte d’information : la collecte à la demande

et suite à un événement.

La collecte a la demande se fait lorsque l’administrateur veut voir l’état de l’environnement

(température, humidité, luminosité), soit du capteur (énergie, son voisin avec les caractéristique

de son voisin) pour surveiller, contrôler, et analyser la zone. Ceci est réalisé à l’aide du protocole

SWSNMP inspiré du protocole SNMP pour les réseaux filaires. De plus, le protocole SWSNMP

prend en considération la problématique de la consommation d’énergie dans les capteurs.

Dans notre travail la gestion n’est pas limitée de l’utilisation du protocole SWSNMP mais

aussi on a utilisé le principe de la redondance et des points d’articulation afin de maximiser la

durée de vie des capteurs et assurer la connexité du réseau de capteur sans fil.

Nous avons tenté de mettre en lumière la manière de concevoir et de réaliser une plateforme

d’aide à la supervision des réseaux de capteur sans fil.

La simulation est fondamentale avant le déploiement en environnement réel, en raison

des avantages qu’elle offre et plus particulièrement en matière de coût et de tests qui peuvent être

réalisés dans les conditions extrêmes. Notre solution est évaluée avec le langage de

CONCLUSION GENERAL ET PERSPECTIVE


programmation c++ qui permet de visualiser le comportent de notre réseau ainsi que le transfert

des requêtes.

Comme perspective on peut dire qu’on a besoin de sécuriser notre système de supervision

ainsi que les communications de notre RCSF afin de reposer sur des échanges sûrs, confidentiels

et fiables. Par ailleurs de la maximisation de la durée de vie, la sécurité permet de garantir et de

maintenir des communications sécurisées durant toute la durée de vie de RCSF.

Finalement, nous devons dire que nous avons eu beaucoup de plaisir pour traiter ce sujet qui

nous a motivés à bien ce type de réseaux.

Système De Supervision Des Réseaux De Capteurs Sans Fils Page 118

BIBLIOGRAPHIE

Bibliographie

[1] F. LEMAINQUE, Tout sur les réseaux sans fil, France, Jean-François Pillou, avril

2009.

[2] A. DESSUREAULT, "Les réseaux sans fil", in icriq.com, http://www.icriq.com/fr/

productique_tfp.html/-/asset_publisher/MeX1/content/les-reseaux-sans-fil/maximized,

07/02/2015 16:07.

[3] G.PUJOLLE, Les réseaux, Paris, Eyrolles, 2008.

[4] J. ZHENG, M. LEE, “Will IEEE 802.15.4 make ubiquitous networking a reality?” in

IEEE Communications Magazine, juin 2004, numéro 6, pages 140-146.

[5] H. Karl, A. Willig, Protocols and architectures for wireless sensor networks, Wiley,

Angleterre, 2005.

[6] C. Servin, Réseaux & Télécoms, Paris, Dunod, 2006.

[7] I. AKYILDIZ, T. MELODIA, K. R CHOWDURY, “Wireless Multimedia Sensor

Networks: A SURVEY” in IEEE Communications Magazine, December 2007, numéro

6, pages 32-39.

[8] D. MARTINS, H. GUYENNET, “Etat de l’art-Sécurité dans les réseaux de capteurs

sans fil” in SAR-SSI : 3rd conference on Security of Network Architectures and

Information Systems, 2008, pages 167-181.

[9] I. AKYILDIZ, W. SU, Y. SANKARASUBRAMANIAM, E. l CAYIRCI, “ A Survey

on Sensor Networks ” in IEEE Communications Magazine, Aout 2002, numéro 8, pages

102-114.

[10] F. BRISSAUD, D. CHARPENTIER, A. BARROS, C.BERENGUER, “Capteurs

intelligents : nouvelles technologies et nouvelles problématiques pour la sureté de

fonctionnement ” in Lambda-Mu 16 : conférence Maîtrise des Risques et de Sûreté de

Fonctionnement, France, 2008, pages 3A-2.

[11] Q. WANG, I. BALASINGHARN, Wireless Sensor Networks-An Introduction, Norvège,

InTech, 2010.

[12] B. TITZER, J. PALSBERG, “Nonintrusive Precision Instrumentation of

Microcontroller Software” in ACM SIGPLAN Notices, juillet 2005 ‚volume 40 numéro

7, pages 59-68.

http://www.icriq.com/fr/%20productique

http://www.icriq.com/fr/%20productique


BIBLIOGRAPHIE

[13] A. MONTOYA, D. RESTREPO, D. OVALLE, Artificial Intelligence for Wireless

Sensor Nevorks Enhancement, Colombie, InTech, 2010.

[14] J. ELSON, K. ROMER “WSN A New regime for Time Synchronisation” in

Proceedings of the First Workshop on Hot Topics in Network, janvier 2003, volume 33,

numéro 1, pages 149-154.

[15] E. PETRIU, N. GEORGANAS, D. PETRIU, D. MAKRAKIS, V. GROZA, “Sensor-

based information appliances” in IEEE Instrumentation Measurement Magazine,

décembre 2000, numéro 1, pages 149-154

[16] M. CHIANG, Z. ZILIC, K. RADECKA, J. CHENARD, “Architectures of Increased

Availability WSN nodes” in IEEE on ITC international test confirence, , octobre 2004,

Pages 1232-1241.

[17] L. YUA, W. CHEN, Y. XI, “A Review of Control and Localization for Mobile Sensor

Networks” in Proceedings of the 6th World Congress on Intelligent Control and

Automation, volume 2 , juin 2006, Pages 9164-9168.

[18] I. CHLAMTAC, I. CARRERAS, H. WOESNER, From internet to bionets: biological

kinetic service oriented networks, Italie, Springer US, 2005.

[19] S. LINDSEY, C. RAGHAVENDRA, “PEGASIS: Power-efficient gathering in sensor

information systems” in IEEE Aerospace conference proceedings, 2002, volume 3,

pages 1125-1130.

[20] H. KARL, A. WILLIG, “A short survey of wireless sensor networks” in

Telecommunication Networks Group, Octobre 2003.

[21] M. TUBAISHAT, S. MADRIA, “Sensor networks: an overview” in IEEE Potentials,

avril 2003, volume 22, numéro2, Pages 20-23.

[22] L. DEHNI, Y. BEENNABI, F. KRIEF, “Une nouvelle approche de routage dans les

réseaux de capteurs pour l’optimisation de la consommation d’énergie” in LEA2C,

2003, volume 13.

[23] I. DEMIRKOL, C. ERSOY, F. ALAGOZ, “MAC Protocols for Wireless Sensor

Networks: a Survey ” in IEEE Communications Magazine, avril 2006, numéro 4, pages

115-121.

[24] E. SHIH, S.CHO, N. ICKES, R. MIN, A. SINHA, A. WANG, A. CHANDRAKASAN,

“Physical Layer Driven Protocol and Algorithm Design for Energy- Efficient Wireless

Sensor Networks” in Proceedings of the 7th annual international conference on Mobile

computing and networking, juillet 2001, pages 272-287.

http://cdn.intechopen.com/pdfs-wm/12444.pdf

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1035242



http://lipn.univ-paris13.fr/~bennani/Publis/LEA2C_Gres_2005.pdf

http://lipn.univ-paris13.fr/~bennani/Publis/LEA2C_Gres_2005.pdf


BIBLIOGRAPHIE

[25] J. A BURKE, D. ESTRIN, M. HANSEN, A. PARKER, N. RAMANATHAN, S.

REDDY, M.SRIVASTAVA, “Participatory Sensing” in Center for Embedded Network

Sensing, mai 2006, volume 22.

[26] C. GARCIA-HERNANDEZ, P. IBARGUENGOYTIA-GONZALEZ, J. GARCIA-

HERNNDEZ, J. PEREZ-DÍAZ, “Wireless Sensor Networks and Applications: a

Survey” in IJCSNS International Journal of Computer Science and Network Security,

mars 2007, numéro 3, pages 264-273.

[27] S. RATNASAMY, B. KARP, L. YIN, F. YU, D. ESTRIN, R. GOVINDAN, S.

SHENKER, “Ght: A Geographic hash table for data-centric storage” in Roceedings of

the 1st ACM International Workshop on Wireless Sensor Networks and Applications,

septembre 2002, pages 78–87.

[28] E. CALLAWAY, P. GORDAY, L. HESTER, J. GUTIERREZ, M. NAEVE, B. HEILE,

V. BAHL, “Home Networking with IEEE 802.15.4: A Developing Standard for Low-

Rate Wireless Personal Area Networks” in IEEE Communications Magazine, aout

2002, numéro 8, pages 70-77.

[29] J. HILL, R. SZEWCZYK, A. WOO, S. HOLLAR, D. CULLER, K. PISTER, "System

architecture directions for networked sensors", in ACM SIGOPS operating systems

review, novembre 2000, volume 34, numéro 5, pages 93-104.

[30] C. HAN, E. KOHIER, N. SRIVASTAVA, R. KUMAR, R. SHEA, “A Dynamic

Operating System for Sensor Nodes”, in ACM Proceedings of the 3rd international

conference on Mobile systems, applications, and services, Juin 2005, Pages 163-176.

[31] C.CHONG, S. KUMAR, “Sensor Networks: Evolution, Opportunities, and Challenges”

in IEEE Proceedings, 2003, volume 91, numéro 8, pages 1247-1256.

[32] C. INTANAGONWIWAT, “Directed diffusion: A scalable and robust conununication

paradigm for sensor networks” in Proeeedings of the Sixth Annual International

Conference on Mobile Computing and Networking, août 2000.

[33] J. ARNAUD, Réseaux & Télécoms, Paris, Dunod, 2006.

[34] W. STALLINGS, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 , Wesley Longman

Publishing Co., États-Unis d'Amérique, 1998.

[35] T. BRICHE, M. VOLAND, Les outils d’administration et de supervision réseau

L’exemple de Nagios, France, Compte rendu, 2004.

[36] M. ROSE, An introduction to management of TCP/IP-based internets, Prentice Hall,

États-Unis d'Amérique, 2002.

http://dl.acm.org/citation.cfm?id=521036

http://ccr.sigcomm.org/archive/1990/oct90/satz.ps


BIBLIOGRAPHIE

[37] D. IMANACHE, N. JOUBERT, O. MAYAUD, Nouvelles Technologies-Réseau

Nagios, édition niversité, 2000.

[38] CCITT Recommendation, “Specification of Abstract Syntax Notation One (ASN.1)” in

International Organization for Standardization (ISO-8824), 2001, volume 208.

[39] J. CASE, M. FEDOR, M. SCHOFFSTALL, J. DAVIN, “A Simple Network

Management Protocol (SNMP)-RFC 1157”, in The Internet Engineering Task Force

(IETF), https://tools.ietf.org/html/rfc1157, 16/02/2015 15:40.

[40] H. ZOTTMANN, “CMIP/CMIS - Object Oriented Network Management”, in cellsoft,

http://www.cellsoft.de/telecom/cmip.htm, 11/03/2015 15:13.

[41] T. SHELDON, “CMIP (Common Management Information Protocol) ”, in Linktionary,

http://www.linktionary.com/c/cmip.html, 11/03/2015 15:26.

[42] Y. Bertsch, F. Stmarcel, “Administration Réseau-système SNMPv1, SNMPv2,

SNMPv3 et http ” in Technologies réseaux avancées, 2001.

[43] J. SCHONWALDER, A. PRAS, M. HARVAN, J. SCHIPPERS, R. VAN, “SNMP

traffic analysis: Approaches, tools, and first results” in 10th IFIP/IEEE International

Symposium on Integrated Network Management, mai 2005, Pages 323-332.

[44] D. MAURO, K. SCHMIDE, Essential SNMP, États-Unis d'Amérique, Michael

Loukides et Debra Cameron, 2005.

[45] M. ROSE, K. MCCLOGHRIE, “Structure and Identification of Management

Information for TCP/IP-based Internets-RFC 1155”, in The Internet Engineering Task

Force (IETF), https://tools.ietf.org/html/rfc1155, 15/04/2015 15:49.

[46] R. PRESUHN, J. CASE, K. MCCLOGHRIE, M. ROSE, S. WALDBUSSER, “Version

2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)-

RFC 3416”, in The Internet Engineering Task Force (IETF), https://tools.ietf.org/html

/rfc3416, 15/04/2015 15:17.

[47] J. Case, K. MCCLOGHRIE, M. ROSE, S. WALDBUSSER, “Structure of Management

Information for Version 2 of the Simple Network Management Protocol (SNMPv2)-

RFC 1902” , in The Internet Engineering Task Force (IETF), https://tools.ietf.org/html

/rfc1902 , 15/04/2015 15:19.

[48] D. HARRINGTON, B. WIJNEN, “An Architecture for Describing Simple Network

Management Protocol (SNMP) Management Frameworks-RFC 3411”, in The Internet

Engineering Task Force (IETF), https://tools.ietf.org/html/rfc3411 , 16/02/2015 16:10.

mailto:[email protected]

http://www.cellsoft.de/telecom/cmip.htm

http://www.linktionary.com/linktionary.html

http://www.linktionary.com/c/cmip.html



https://tools.ietf.org/html

https://tools.ietf.org/html


BIBLIOGRAPHIE

[49] R. FRYE, D. LEVI S. ROUTHIER ,“Wijnen Coexistence between Version 1, Version

2, and Version 3 of the Internet-standard Network Management Framework-RFC

2576”, in The Internet Engineering Task Force (IETF), https://tools.ietf.org/html/

rfc2576 , 15/04/2015 15:39.

[50] J. Case, D. HARRINGTON, B. WIJNEN, R. PRESUHN, “Message Processing and

Dispatching for the Simple Network Management Protocol (SNMP) RFC-3412”, in The

Internet Engineering Task Force (IETF), https://tools.ietf.org/html/rfc3412 , 15/02/2015

23:09.

[51] R. CHAPARADZA, “On designing SNMP based monitoring systems supporting

ubiquitous access and real-time visualization of traffic flow in the network, using low

cost tools” in IEEE 7th Malaysia International Conference on Communication, 2005,

volume 2, pages 6.

[52] R. PRESUHN, J. CASE, M. ROSE, S. WALDBUSSER, “Management Information

Base (MIB) for the Simple Network Management Protocol (SNMP)-RFC 3418”, in The

Internet Engineering Task Force (IETF), https://tools.ietf.org/html/rfc3418, 17/02/2015

09:31.

[53] U. BLUMENTHAL, B. WIJNEN, “User-based Security Model (USM) for version 3 of

the Simple Network Management Protocol (SNMPv3)-RFC 3414”, in The Internet

Engineering Task Force (IETF), https://tools.ietf.org/html/rfc3414, 17/02/2015 18:23.

[54] B. WIJNEN, R. PRESUHN, K. MCCLOGHRIE, “View-based Access Control Model

(VACM) for the Simple Network Management Protocol (SNMP)-RFC 3415”, in The

Internet Engineering Task Force (IETF), https://tools.ietf.org/html/rfc3415, 17/02/2015

18:45.

[55] M. WELSH, G. MAINLAND, “Programming Sensor Networks Using Abstract

Regions” in NSDI, mars 2004, volume 4, Pages 3.

[56] A. BOULIS, C. HAN, M. SRIVASTAVA, “Design and implementation of a framework

for efficient and programmable sensor networks” in Proceedings of the 1st international

conference on Mobile systems, applications and services, mai 2003, Pages 187-200.

[57] W. LEE, A. DATTA, R. CARDELL-OLIVER, “Network management in wireless

sensor networks” in Handbook of Mobile Ad Hoc and Pervasive Communications,

Décembre 2006, pages 1-20.

https://tools.ietf.org/

http://static.usenix.org/legacy/events/nsdi04/tech/full_papers/welsh/welsh_html/

http://static.usenix.org/legacy/events/nsdi04/tech/full_papers/welsh/welsh_html/



https://scholar.google.com/scholar?oi=bibs&cluster=15446688976905631837&btnI=1&hl=fr



BIBLIOGRAPHIE

[58] L. RUIZ, J. NOGUEIRA, A. LOUREIRO, “Manna: A management architecture for

wireless sensor networks ” in IEEE Communications Magazine, Février 2003, numéro

2, pages 41.

[59] M. BARACHI, A. KADIWAL, R. GLITHO, F. KHENDEK, R. DSSOULI, “The design

and implementation of architectural components for the integration of the IP multimedia

subsystem and wireless sensor networks” in IEEE Communications Magazine, Avril

2010, numéro 4, pages 42-50.

[60] Y. HUANG, M. HSIEH, H. CHAO, S. HUNG, J. PARK, “secure access to a

hierarchical sensor-based healthcare monitoring architecture in wireless heterogeneous

networks” in IEEE Journal on Selected Areas in Communications, mai 2009, numéro 4,

pages 400-411.

[61] L. ZHOU, B. GELLER, B. ZHENG, A. WEI, J. CUI, “System scheduling for multi-

description video streaming over wireless multi-hop networks” in IEEE Transactions on

Broadcasting, Décembre 2009, numéro 4, pages 731-741.

[62] H. SONG, D. KIM, K. LEE, J. SUNG, “UPnP-based sensor network management

architecture” in Proc. ICMU Conférence, Avril 2005, pages 6.

[63] L. RUIZ, I. SIQUEIRA, H. WONG, J. NOGUEIRA, A. LOUREIRO, “Fault

management in event-driven wireless sensor networks” in Proceedings of the 7th ACM

international symposium on Modeling, analysis and simulation of wireless and mobile

systems, Octobre 2004, pages 149-156.

[64] W. LIU, Y. ZHANG, W. LOU, Y. FANG, “Managing wireless sensor networks with

supply chain strategy ” in First International Conference on Quality of Service in

Heterogeneous Wired/Wireless Networks, Octobre 2004, pages 59-66.

[65] G. TOLLE, D. CULLER, “Design of an application-cooperative management system

for wireless sensor networks” in EWSN, Janvier 2005, volume 5, pages 121-132.

[66] W. LEE, A. DATTA, R. CARDELL-OLIVER, “Winms: Wireless sensor network-

management system, an adaptive policy-based management for wireless sensor

networks ” in Technical Report UWA-CSSE-06-001The University of Western

Australia, juin 2006.

[67] C. FOK, G. ROMAN, C. LU, “Mobile agent middleware for sensor networks: An

application case study ” in Fourth International Symposium on Information Processing

in Sensor Networks, Avril 2005, pages 382-387.

























BIBLIOGRAPHIE

[68] A. ERDOGAN, E. CAYIRCI, V. COSKUN, “Sectoral sweepers for sensor node

management and location estimation in adhoc sensor networks ” in IEEE Military

Communications Conference, Octobre 2003, volume 1, pages 555-560.

[69] Z. YING, X. DEBAO, “Mobile agent-based policy management for wireless sensor

networks ” in IEEE International Conference on Wireless Communications,

Networking and Mobile Computing, Septembre 2005, volume 2, pages 1207-1210.

[70] R. TYNAN, D. MARSH, D. OKANE, G. OHARE, “Agents for wireless sensor network

power management ” in IEEE International Conference Workshops on Parallel

Processing, juin 2005, pages 413-418.

[71] H. ZHANG, J. HOU, “Maintaining sensing coverage and connectivity in large sensor

networks ” in Ad Hoc & Sensor Wireless Networks, mars 2005, volume 1, numéro 1-2,

pages 89-124.

[72] N. RAMANATHAN, E. KOHLER, D. ESTRIN, “Towards a debugging system for

sensor networks ” in International Journal of Network Management, juillet 2005,

volume 15, numéro 4, pages 223-234.

[73] M. TURON, J. SUH, “Mote-view: A sensor network monitoring and management tool ”

in Proceedings of the 2nd IEEE workshop on Embedded Networked Sensors, mai 2005,

pages 11-17.

[74] U. CETINTEMEL, A. FLINDERS, Y. SUN, “Power-efficient data dissemination in

wireless sensor networks ” in Proceedings of the 3rd ACM international workshop on

Data engineering for wireless and mobile access, septembre 2003, pages 1-8.

[75] T. KIM, S. HONG, “Sensor network management protocol for state-driven execution

environment ” in International Conference on Ubiquitous Computing, octobre 2003,

pages 197-199.

[76] N. RAMANATHAN, M. YARVIS, J. CHHABRA, N. KUSHALNAGAR, L.

KRISHNAMURTHY, D. ESTRIN, “A stream-oriented power management protocol for

low duty cycle sensor network applications ” in IEEE Center for Embedded Network

Sensing, mai 2005, pages 1-9.

[77] A. BOULIS, M. SRIVASTAVA, “Node-level energy management for sensor networks

in the presence of multiple applications ” in Proc. IEEE PerCom Conf., novembre 2004,

volume 10, numéro 6, pages 737-746.





















BIBLIOGRAPHIE

[78] B. CHEN, K. JAMIESON, H. BALAKRISHNAN, R. MORRIS, “Span: An energy-

efficient coordination algorithm for topology maintenance in ad hoc wireless networks ”

in Proc. ACM MobiCom Conf., septembre 2002, volume 8, numéro 5, pages 481-494.

[79] C. SCHURGERS, V. TSIATSIS, S. GANERIWAL, M. SRIVASTAVA, “Optimizing

sensor networks in the energy-latency-density design space ” in IEEE Transactions on

Mobile Computing, janvier 2002, volume 1, numéro 1, pages 70-80.

[80] W. HEINZELMAN, A. CHANDRAKASAN, H. BALAKRISHNAN, “An application-

specific protocol architecture for wireless microsensor networks ” in IEEE Transactions

on Wireless Communications, octobre 2002, volume 1, numéro 4, pages 660-670.

[81] A. SINHA, A. CHANDRAKASAN, “Dynamic power management in wireless sensor

networks ” in IEEE Design & Test of Computers, mars 2001, volume 18, numéro 2,

pages 62-74.

[82] C. WAN, S. EISENMAN, A. CAMPBELL, J. CROWCROFT, “Siphon: overload

traffic management using multi-radio virtual sinks in sensor networks ” in Proceedings

of the 3rd international conference on Embedded networked sensor systems, novembre

2005, pages 116-129.

[83] J. ZHANG, E. KULASEKERE, K. PREMARATNE, P. BAUER, “Resource

management of task oriented distributed sensor networks ” in IEEE International

Symposium on Circuits and Systems, mai 2001, volume 3, pages 513-516.

[84] Y. MA, J. CHEN, Y. HUANG, M. LEE, “An efficient management system for wireless

sensor networks ” in ISSN Sensors, décembre 2010, volume 10, numéro 12, pages

11400-11413.

[85] I. AKYILDIZ, W. SU, Y. SANKARASUBRAMANIAM, E. CAYIRCI, “Wireless

sensor networks: a survey ” in Computer networks, mars 2002, volume 38, numéro 4,

pages 393-422.

[86] M. PERILLO, W. HEINZELMAN, “Providing application QoS through intelligent

sensor management ” in IEEE International Workshop on Sensor Network Protocols

and Applications, mai 2003, pages 93-101.

[87] C. HSIN and M. LIU, “A Two-Phase Self-Monitoring Mechanism for Wireless Sensor

Networks” in Journal of Computer Communications special issue on Sensor Networks,

2006, volume 29, numéro 4, pages 462–476.




















BIBLIOGRAPHIE

[88] B. DEB, S. BHATNAGAR, B. NATH, “STREAM: Sensor topology retrieval at

multiple resolutions ” in Telecommunication Systems, juin 2004, volume 26, numéro 2-

4, pages 285-320.

[89] S. CHAUDHRY, G. BOYLE, W. SONG, C. SREENAN, “EMP: A Network

Management Protocol for IP-Based Wireless Sensor Networks” in IEEE International

Conference on Communication in Wireless Environments and Ubiquitous Systems,

octobre 2010, pages 1-6.

[90] A. PAVENTHAN, S. ALLU, S. BARVE, V. GAYATHRI, N. RAM, “Soil Property

Monitoring using 6LoWPAN-enabled Wireless Sensor Networks ” in Third National

Conference on Agro-Informatics and Precision Agriculture (AIPA), aout 2012, pages

278-282.

[91] Y. LIM, M. MESSINA, F. KARGL, L. GANGULI, M. FISCHER, T. TSANG,

“SNMP-Proxy for Wireless Sensor Network” in IEEE computer society firth

international conference on information technology, Avril 2008, pages 738-743.

[92] J. RASK , “Introduction to snmp4j”, in Jayway, http://www.jayway.com/2010/05/21/

introduction-to-snmp4j/, 16/03/2015 12:09.

[93] Y. CHEN, Q. ZHAO, “On the lifetime of wireless sensor networks” in IEEE

Communications Letters, novembre 2005, volume 9, numéro 11, pages 976-978

[94] O. SIGAUD, Introduction à la modélisation orientée objets avec UML, Paris, Edition

2005-2006.

[95] L. AUDIBERT, UML 2.0, Paris, 2006.

[96] FAQ C++ Builder, “Programmation”, in Developpez.com. http://c.developpez.com/faq

/bcb/, 12/05/2015 15:08.

[97] C. DELANNOY, Exercices en langage C++, Paris, Éditions eyrolles, 2007.

[98] R. BECHAR, “Théorie de la redondance pour la reconfiguration des systèmes-

Application aux réseaux de capteur sans fil “, Mémoire de magister Ecole doctorale

STIC, Université Abdelhamid Ibn Badis de Mostagane, Département d’informatique,

2009.

[99] A computer science portal for geeks, “Articulation Points (or Cut Vertices) in a

Graph”, in geeksforgeeks, https://courses.cs.washington.edu/courses/ , 28/02/2015

18:35.





http://www.jayway.com/author/johanrask/

http://www.jayway.com/2010/05/21/%20introduction-to-snmp4j/

http://www.jayway.com/2010/05/21/%20introduction-to-snmp4j/

http://scholar.google.com/scholar?oi=bibs&cluster=17948461551441932140&btnI=1&hl=fr

http://c.developpez.com/faq

https://courses.cs.washington.edu/courses/cse421/04su/slides/artic.pdf

Education

Système de supervision des réseaux de capteurs sans fil