DEPARTEMENT D'INFORMATIQUE MEMOIREtheses.univ-oran1.dz/document/TH3233.pdfRésumé iii Résumé Maximiser la durée de vie d ˇun réseau de capteurs sans fil (RCSF) est un défi de

1

DEPARTEMENT D'INFORMATIQUE

MEMOIRE

Présenté par

B AHN E S Nacé ra

Pour obtenir

LE DIPLOME DE MAGISTER

Spécialité Informatique

Option : Méthodes et Outils pour la sécurité des systèmes d ’informations

Intitulé : Soutenu le :……………… à la salle de conférences de la Faculté des Sciences

Devant les membres du jury :

Président du jury BELDJILLALI Bouziane Professeur - Université d’Oran

Encadreur HAFFAF Hafid Professeur - Université d’Oran

Co-Encadreur KECHAR Bouabdellah MA-A - Université d’Oran

Examinateur KOUNINEF Belkacem MC-A – ITO Oran

Examinateur BELALEM Ghalem MC-A - Université d’Oran

Gestion et supervision d’un réseau de capteurs sans fil à l’aide d’un protocole à économie d’énergie WSN-SNMP

http://www.pdfcomplete.com/cms/hppl/tabid/108/Default.aspx?r=q8b3uige22

A ma grande mère


Remerciements

ii

Remerciements

Je tiens à remercier en premier lieu Monsieur le Professeur

BELDJILLALI Bouziane de me faire l’honneur et le plaisir de présider mon

jury.

Je remercie très sincèrement Monsieur KOUNINEF Belkacem maître de

conférence à l’institut de télécommunication d’Oran ainsi que Monsieur

BELALEM Ghalem maître de conférence à l’université d’Oran Es-Sénia, pour

l’immense honneur qu’ils me font en acceptant d’évaluer ce modeste travail et

de faire partie de ce jury.

Je remercie particulièrement mes encadreurs Monsieur HAFFAF Haffid

et Monsieur KACHER Bouabdellah qui m’ont accueilli, accompagné et

conseillé tout au long de cette thèse. Merci pour vos disponibilités et vos

gentillesses.

Je remercie également mes parents pour leur support et leur croyance en

moi et qui m’ont poussé à dépasser tous les problèmes et aller jusqu’au bout,

ma grand-mère pour leur soutien indéfectible durant mes années d’études.

Merci à mes sœurs, mon frère, mes amies, mes collègues et tous les

membres de l’équipe de «Méthodes et outils pour la sécurité des systèmes

d’information » à leur tête Monsieur M. K. RAHMOUNI qui m’ont toujours

soutenue tous au long de mon parcours.

Une grande reconnaissance à Madame T. AIT SAADI, enseignante à

l’université Abdelhamid Ibn Badis de mostaganem.


Résumé

iii

Résumé

Maximiser la durée de vie d’un réseau de capteurs sans fil (RCSF) est un défi de

conception réseau très important. Par conséquent, concevoir des techniques efficaces qui

préservent les ressources énergétiques est un problème critique pour ce genre de réseaux.

Cette thèse s’intéresse au développement d’un nouveau protocole de surveillance de topologie

du RCSF et de gestion visant à optimiser la dépense énergétique des batteries. Celles-ci sont

limitées et ne peuvent pas être changées ou rechargées dans beaucoup d’applications dont le

champ de déploiement est inaccessible où la présence d’être humain est quasi impossible.

Nous avons tout d’abord étudié et analysé certaines approches dans le domaine de

recherche lié à la surveillance des RCSF. Nous avons également présenté le protocole SNMP

sur lequel repose notre contribution présentée dans ce mémoire. Nous avons conçu un

protocole de gestion WSN-SNMP basé sur le standard SNMP et deux approches basées sur la

théorie des graphes à savoir la détection des points d’articulation et le graphe biparti. En

effet, nous avons implémenté l’algorithme de détection des points d’articulation pour traiter

les problèmes de connectivité par le moyen de déplacement de nœuds capteurs mobiles. Un

autre algorithme est proposé pour faciliter la sélection de(s) nœud(s) redondant(s) pour un

objectif d’économie d’énergie. Ces deux solutions nous ont permis de minimiser la

consommation d’énergie tout en assurant la 2-connectivité et la couverture désirée du réseau.

Nous avons évalué notre contribution à l’aide du simulateur J-Sim. Les résultats obtenus

sont encourageants en termes de préservation d’énergie et l’extension de la durée de vie du

réseau.

Mots clés : surveillance et gestion des réseaux, SNMP, RCSF, connectivité, couverture,

consommation d’énergie, point d’articulation, graphe biparti.


Abstract

iv

Abstract

Energy efficiency is critical issue in wireless sensor network (WSN). Consequently,

development of energy management techniques is a critical problem for WSN. This thesis

deals with the design of now WSN topology management protocol seeing to conserve the

energy for battery. This one is limited and can not be changed or reload in several

applications, whose deployment field is inaccessible in which the user presence is quasi

impossible.

First, we studied and analyzed various approaches in a research domain related to

monitoring in WSN. We also presented the protocol SNMP on which our contribution,

presented in this thesis, is based. We designed a management protocol WSN-SNMP based on

SNMP standard and two approaches based on the graph theory: detection of articulation

points and the bipartite graph. Indeed, we implemented the algorithm of detection of

articulation points to deal with the problems of connectivity by moving mobile sensor nodes.

Another algorithm is proposed to facilitate the selection of redundant nodes for an energy

saving objective. These two solutions enabled us to minimize the energy consumption while

ensuring the 2-connectivity and the desired coverage of the network.

We evaluated our contribution using the J-Sim simulator. The results obtained are

interesting in terms of energy saving and the prolongation of network lifetime.

.

Keywords: network monitoring and management, SNMP, WSN, connectivity, coverage,

energy consumption, articulation point, bipartite graph.


Table des matières

v

Table des matières Remerciements………………………………………………………..………………………..Résumé…………………………………………………………………….…………………..Abstract…………………………………………………………………….………….………..Table des matières …………………………………………………………………………..…Liste des figures………………………………………………………………………….….…Liste des tableaux…………………………..………………………………….………….……Liste des abréviations………………………………………………..………………...........… Introduction générale…………………………………………………………………………

ii iii iv v

viii ix x

1

Chapitre I : Les réseaux de capteurs sans fil - Représentation I.1. Introduction …………………………………………………………………………..… I.2. Définition…………………………………………………………………………………1.3. Le réseau Ad hoc ……………………………………………………………..…………1.4. RCSF vs réseau Ad-hoc………………………………………………………………….1.5. Le réseau des capteurs mobiles …………………………………………..…………….. 1.6. Les domaines d’applications ……………………………………………...……………. 1.7. Les unités d’un nœud capteur ……………………………………………………………1.8. Les nouveautés de la technologie des capteurs ……………………….…………………I.9. La pile protocolaire des RCSF …………………………………………………..……….I.10. Les états opérationnels d’un nœud capteur …………………………………..…………I.11. Les caractéristiques et les problèmes liés aux RCSFs………………………………..… I.12. La localisation des nœuds dans le RCSF ………………………………………………..I.13. Le stockage des données ……………………………………………………...…………I.14. La Couverture ……………………………………………………………….…………..I.15. La connectivité ………………………………………………………………………….I.16. Système d’exploitation pour les RCSFs ……………………….……………………...….I.17. La classification des protocoles de routage ……………………………………..…….…I.18. Conclusion ……………………………………………………………………..........….

4 4 6 6 6 7 8

10 11 13 13 18 19 19 20 21 21 24

Chapitre II : Protocole SNMP (Simple Network Management Protocol) II.1. Introduction …………………………..………………………………………………….II.2. Présentation générale…………………………………………………………………..….II.3. Les différentes versions de SNMP ……………………………………..………………..II.4. Les implémentations existantes du SNMP…………………………………………….….II.5. Architecture de SNMP ………………………………………...…………………………II.6. Principe de fonctionnement …………………………………………………...…………II.7. Les applications……………………………………………………………………….… II.8. Les MIBS : Management Information base …………………………………................. II.8.1. MIB-II …………………………………………………….………………….…..II.9. Le Langage ASN.1 ……………………………………………….………………….….II.10. La structure d’information de gestion : SMI ……………………..………….…………

25 25 27 29 29 31 31 33 35 36 37


Table des matières

vi

II.10.1. La première version de SMI …………………………………………..……… II.10.2. SMI version 2 …………………………………………………………..….… II.11. Les primitives de protocole SNMP …………………………………………..…… II.11.1. Les requêtes SNMP ………………………………………………………..… II.11.2. Les réponses de SNMP ………………………………………………………. II.11.3. Les alertes ………………………………………………………………..……II.12. Trame SNMP ………………………………………………………………………….. II.12.1. PDU SNMPv1 ………………………………………………………………… II.12.2. PDU SNMPv2 ………………………………………………………………… II.12.3. La trame de SNMPv3 ………………………………………………….…….. II.12.4. Les Tailles des messages SNMP ………………………………………………II.13. La sécurité du protocole SNMP ……………………………………………………….. II.13.1. Les faiblesses de SNMPv1 ……………………………………………………. II.13.2. Les améliorations de SNMPv2 ……………………………………………….. II.13.3. La sécurité avec SNMP v3 ……………………………………………………. II.13.4. IPSec avec SNMPv2 ……………………………………………..……………II.14. Conclusion ………………………………………………………………………………

38 39 39 40 40 40 42 42 43 45 46 47 47 47 47 48 48

Chapitre III : Gestion & Supervision Des RCSFs III.1. Introduction ………………………………………………………………………….….III.2. Les fonctions de gestion ………………………………………………………………...III.3. Les métriques de RCSF ……………………………………………………………..….III.4. Architecture de RCSF …………………………………………………….…………….III.5. Les modèles de délivrance des données dans les réseaux de capteurs………….………. III.5.1. Le modèle continue…………..…………..………….…………..………..…... III.5.2. Le modèle driven event…………………………………………….………….. III.5.3. Le modèle query driven……………………………………………..….……… III.5.4. Le modèle Hybride……………………………………………………..…….....III.6. Classification des travaux existants pour la gestion de RCSF …………………………. III.6. 1. La détection des fautes ………………………………………………..…….… III.6. 2. Les outils de visualisation ……………………………………………..…….… III.6. 3. Les fonctions de gestion de trafic …………………………………………..… III.6. 4. Les systèmes de gestion d’énergie …………………………………….………III.5. L’utilisation de protocole SNMP pour les RCSFs …………………………………...…III.6. Conclusion ……………………………………………………………….………….…..

49 49 52 53 54 54 54 55 55 55 57 60 60 61 63 66

Chapitre IV: Conception d’un Protocole de gestion centralisé

WSNSNMP IV.1. Introduction ………………………………………………………………………….….IV.2. Modélisation d’un réseau de capteur..………………………………………………….IV.3. Présentation de notre contribution ………………………………………………..……IV.4. Les fonctionnalités de protocole WSN-SNMP …………………………………..…… IV.4.1. Détection des points d'articulation ……………………………………………. IV.4.2. Reconfiguration de topologie ………………………………………….……… IV.4.3. La consommation de l’énergie ………………………………………………..

67 67 68 69 70 72 73


Table des matières

vii

IV.4.3.1. Graphe biparti………………………………..………………….…… IV.4.3.2. Mécanisme de minimisation de consommation d’énergie …….……IV.5. La base des données …………………………………………………………..………. IV.5.1. Structure de la MIB ………………………………………………………..… IV.5.2. La structure générale des objets de la MIB …………………………………… IV.5.3. L'accès à l'information de gestion ……………………………….…………….IV.6. La structure des messages SNMP…………………………………………..………….. IV.6.1. Les requêtes ……………………………………………………………..……. IV.6.2. Les réponses ………………………………………………………….……….

IV.6.3. Structure de message de type Trap…………………………………….…..…. IV.7. Conclusion ……………………………………………………………………..……….

74 74 76 76 77 77 78 79 81 82 83

Chapitre V : Mise en œuvre du protocole WSNSNMP à l’aide de

simulateur J_Sim V.1. Introduction ………………………………………………………………………..….. V.2. Environnement de simulation J-Sim ……………………………………………...…… V.3. Implémentation de protocole de gestion WSN-SNMP ……………………….…….…. V.3.1. Les paramètres et les variables des simulations ……………………………… V.3.2. Vue globale de l’application …………………………………………………. V.3.3.. Présentation de notre application …………………………………………..… V.3.4. Le modèle de topologie …………………………………………………….…

V.3.4.1. Modèle de transmission dans J-Sim ……………………………….… V.3.4.2. La représentation de notre modèle de communication ………………

V.3.5. Le modèle d’énergie ……………………………………………………….…. V.3.6. Distribution des nœuds ……………………………………………………….. V.3.7. La structure des données MIB …………………………………………..……. V.3.8. Structure/ taille des messages …………………………………………..……

V.3.9. La reconfiguration …………………………….……………….…………..…. V.3.10. Mécanismes de conservation d’énergie .…………………………………….…

V.3.11. Les scénarios utilisés ……………………………………………………….…. V.3.12. Générateur d’un fichier Script et initialisation de ces variables…………….….V.4. Evaluations des résultats obtenus ……………………………………………………..…

V.4.1. L’influence de la densité de réseau ……………………………………..……. V.4.2. L’impact de nombre des points d’articulation …………………………..…… V.4.3 L’influence de degré de mobilité sur la durée de vie de réseau ……..…….… V.4.4. L’influence de nombre des messages générés.…………………..……………

V.5. Conclusion ……………………………………………………………………….……

84 84 85 85 86

87 88 89 90 92 94 94 95 95 95 96 96 98 99

100 100 101 102

Conclusion générale …………………………………………………………………… …….

Annexe A : La théorie des graphes………………………………………………… ….….….

Annexe B : Représentation de J-Sim……………………………………………… ..…..….

Bibliographie…………………………………… ………………………………………… ….

103

105

111

119


Liste des figures

viii

Liste des figures

Figure I.1 Figure I.2 Figure I.3 Figure I.4 Figure I.5 Figure I.6 Figure 1.7 Figure I.8 Figure II.1 Figure II.2 Figure II.3 Figure II.4 Figure II.5 Figure II.6 Figure II.7 Figure II.8 Figure II.9 Figure III.1 Figure III.2 Figure III.3 Figure III.4 Figure III.5 Figure IV.1 Figure IV.2 Figure IV.3 Figure IV.4 Figure IV.5 Figure IV.6 Figure IV.7 Figure IV.8 Figure IV.9 Figure V.1 Figure V.2 Figure V.3 Figure V.4 Figure V.5 Figure V.6

Des exemples de nœud capteur …………………………..………………Architecture d’un RCSF …………………………………………………. Quelques applications des RCSFs ……………………..…………………Les composants d’un nœud capteur …………………..…….……………La structure de canal de IEEE.802.15.4 ………………….……….………Les états possibles d’un nœud capteur …………………………………..Modèle géométrique des deux régions d’un capteur: couverture/communication ….................................................................... Les différents protocoles de routages dédiés pour les RCSFs …............... Architecture de SNMP ………………………………………………..… Ensemble des messages de SNMPv2 ………………………………….…Entité de SNMP ……………………………………………………...…..Description d’objet de MIB ………………………………………………La représentation des éléments de MIB-II …………………………….…La structure d’une Trap …………………………………………………..Structure d’un message SNMPv1 ………………………………..……... La structure de message Get-Bulk-Request ……………………...............Structure de message SNMPv3 ………………………………………….. L’ensemble des fonctions de gestion définis dans MANNA……..……….Les relations, des fonctions et les modèles de système MANNA……..…Le diagramme d’états des nœuds en utilisant le protocole BESM…….....Un système de gestion utilisant SNMP….…………………….……….….Architecteur d’un RCSF pour la surveillance de la santé……...…………. L’algorithme de point d’articulation …...……...……...……...…………..L’algorithme de reconfiguration …...……...……...……...……...………..Graphe biparti …...……...……...……...……...……...……...……………L’algorithme d’un mécanisme conservation d’énergie …...……...............L’arborescence des données dans la MIB …...……...……...……………..Le format des requêtes …...……...……...……...……...……......………..Le format des messages de réponse …...……...……...……...………..… Structure de message de type Trap …...……...……...……...……............Structure de message de type Report …...……...……...……...………….. Le principe général de notre application …...……...……...………..…… Fenêtre principale du logiciel …...……...……...……...……...……..…... Fenêtres d’initialisation de modèle de topologie …...……...………..…...Comparaison entre deux modèles de communication sous J-SIM..……...Procédure modifiée pour implémenter le modèle de communication des noeuds capteurs …...……...……...……...……...……...……................... Visualisation de topologie de réseau …...……...……...………..………...

05 05 08 09 12 13

20 22

30 31 32 34 35 40 42 44 45

58 59 63 65 66

71 73 74 75 77 80 81 82 83

86 88 89 90

92 92


Liste des figures

ix

Figure V.7 Figure V.8 Figure V.9 Figure V.10 Figure V.11 Figure V.12 Figure V.13 Figure V.14 Figure V.15

La représentation d’une matrice d’adjacente …...……...………...……….Procédure ajoutée pour calculer la matrice d’adjacente …...………….….Initialisation de modèle d’énergie …...……...……...……...………..........Topologie de réseau après l’exécution du mécanisme de conservation d’énergie ………………………………………….. …………………..... La représentation de l’énergie résiduelle de quelques nœuds de capteurs en fonction de temps de simulation pour le scénario 1………………….….. La durée de vie vs la densité de réseau……………………………………L’influence de nombre des points d’articulation sur la duré de vie…L’impact de degré de mobilité des nœuds sur sa durée de vie ………...... Comparaison de la durée de vie avec la variation de degré de reconfiguration Rmax et le taux de mobilité. …………………….…….

93 93 94

95

98 99

100 101

101


Liste des tableaux

x

Liste des Tableaux

Tableau 1.1 Tableau 1.2 Tableau I.3 Tableau I.4 Tableau 1.5 Tableau 1.6 Tableau II.1 Tableau II.2 Tableau II.3 Tableau II.5 Tableau II.6 Tableau II.7 Tableau II.8 Tableau II.9 Tableau III.1 Tableau IV.1 Tableau IV.2 Tableau IV.3 Tableau IV.4

Comparaison entre deux types de réseaux : Ad-hoc et RCSF ……......Caractéristiques opérationnelles de deux processeurs différents …….Les paramètres de modulation d’IEEE 802.15.4 ………………….... L’énergie consommée suivant l’état de capteur ………………….…. Le modèle énergétique de Mica2 ………………………………….. Comparaison entre quelques protocoles de routage pour les RCSFs … Quelques RFCs pour le protocole SNMP ………………………….. La structure d’objet de protocole SNMP et de CMIP …………….. La description des éléments de MIB-II …………………………….. Ensemble des types pour les deux versions de SMI ………………... Description des champs qui constitue le message Trap ……………. Les types de Trap ………………………………………………….. Type PDU de SNMP ……………………………………………….. Type d’erreurs de SNMP …………………………………………… Les systèmes de gestion de réseau …...……...……...……...….…...… La description des objets de la base MIB-Sensor …...……...……...…Différents type de PDU pour WSNSNMP …...……...……...……...…Les différentes erreurs …...……...……...……...……...……...….…...Les différents champs qui constituent les messages de type Trap …...

06 10 12 16 16 23 27 34 36 39 41 41 43 43 56 76 79 82 83


Liste des abréviations

xi


AODV

APTEEN ASN.1 AT CMIP CMIS DES DSR EGP FSR GAF GEAR ICMP IEEE IETF IP IPSEC ISO JSIM OID OLSR PDU

PEGASIS QOS LEACH MAC MECN MEMS MNMP MIB MTU RCSF SAR SGMP SMECN SMI SNMP

AD HOC ON-DEMAND DISTANCE VECTOR ADAPTED THRESHOLD SENSITIVE ENERGY EFFICIENT SENSOR NETWORK PROTOCOL ABSTRACT SYNTAX NOTATION NUMBER ONE ADDRESS TRANSLATION COMMON MANAGEMENT INFORMATION PROTOCOL COMMON MANAGEMENT INFORMATION SERVICES DATA ENCRYPTION STANDARD DYNAMIC SOURCE ROUTING EXTERIOR GATEWAY PROTOCOL FISHEYE STATE ROUTING GEOGRAPHIC ADAPTIVE FIDELITY GEOGRAPHIC AND ENERGY AWARE ROUTING INTERNET CONTROL MESSAGE PROTOCOL INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS INTERNET ENGINEERING TASK FORCE INTERNET PROTOCOL INTERNET PROTOCOL SECURITY INTERNATIONAL STANDARD ORGANIZATION JAVA SIMULATOR OBJECT IDENTIFIER OPTIMIZED LINK STATE ROUTING PROTOCOL DATA UNIT POWER-EFFICIENT GATHERING IN SENSOR INFORMATION SYSTEMS QUALITY OF SERVICE LOW-ENERGY ADAPTIVE CLUSTERING HIERARCHY MAGIC ACCESS CONTROL MINIMUM ENERGY COMMUNICATION NETWORK Micro Electro-Mechanical Systems MANNA NETWORK MANAGEMENT PROTOCOL MANAGEMENT INFORMATION BASE MAXIMUM TRANSMISSION UNIT RESEAU DE CAPTEUR SANS FIL SEQUENTIAL ASSIGNMENT ROUTING SIMPLE GATEWAY MANAGEMENT PROTOCOL SMALL MINIMUM ENERGY COMMUNICATION NETWORK STRUCTURE MANAGEMENT INFORMATION SIMPLE NETWORK MANAGEMENT PROTOCOL



xii

SPIN TEEN UPnP

WSN ZRP

SENSOR PROTOCOLS FOR INFORMATION VIA NEGOTIATION Threshold sensitive Energy Efficient sensor Network protocol UNIVERSAL PLUG AND PLAY WIRELESS SENSOR NETWORK ZONE ROUTING PROTOCOL


Introduction générale

1

INTRODUCTION GENERALE

Les réseaux de communication sans fil ont connu un succès sans cesse croissant au sein des

communautés scientifiques et industrielles. Grâce à ses divers avantages, cette technologie a

pu s'instaurer comme acteur incontournable dans les architectures des réseaux actuelles. Le

paradigme sans fil a vu naître diverses architectures dérivées, telles que : les réseaux

cellulaires, les réseaux locaux sans fils et autres. Durant cette dernière décennie, une

architecture nouvelle a vu le jour : les réseaux de capteurs sans fil (RCSF), ou Wireless

Sensor Network (WSN). Ce type de réseau résulte d'une fusion de deux pôles de

l'informatique moderne : les systèmes embarqués et les communications sans fil.

RCSF est considéré comme un type spécial de réseau Ad-hoc, sans infrastructure. Ses

nœuds consistent en un grand nombre des capteurs capable de récolter et de transmettre des

données environnementales telles que la température, la présence d’un gaz d’une manière

autonome communicant généralement par les ondes radios; ils sont dispersés dans une zone

géographique qui définit la zone de surveillance pour un phénomène. RCSFs sont destinés à

relever des informations dans des environnements parfois hostiles auxquels l'homme n'a pas

toujours avoir l’accès. C'est pourquoi on considère qu'une fois qu'ils sont déployés, les

capteurs sont autonomes. Les données collectées sont acheminées grâces à un routage multi

sauts à un nœud considéré comme un point de collecte appelée station de base (en anglais

sink). Ce dernier peut être connecté à l’utilisateur du réseau via l’Internet ou un satellite.

Ainsi, l’usager peut adresser des requêtes aux autres nœuds du réseau précisant le type des

données requises et récolter les données capturées par le biais de la station de base. Ils ont des

applications dans nombreux domaines, dont l’observation de la nature et de l’environnement,

la sécurité des bâtiments et la domotique, la gestion du trafic routier, la surveillance médicale,

et les opérations militaires.

Un nœud capteur est muni de quatre unités principales : l’unité de capture pour détecter

les événements environnementaux, l’unité de calcul pour traiter ces données collectées et

exécuter des différentes procédures, l’unité de radio et l’unité d’énergie pour la répartition de

l’énergie disponible aux autres unités. La ressource énergétique d’un nœud capteur est limitée



2

et généralement irremplaçable. Dans certain cas, Il est nécessaire de surveiller de manière

contenu l’état des noeuds afin d’éviter le disfonctionnement de réseau. Dans la littérature, la

majorité des solutions existantes s’adaptent mal aux propriétés des contraintes nombreuses de

ce type de réseau.

Les caractéristiques particulières des WSNs modifient les critères de performance par

rapport aux réseaux sans fil traditionnels. Dans les réseaux locaux filaires ou les réseaux

cellulaires, les critères les plus pertinents sont le débit, la latence et la qualité de service car

les nouvelles activités telles que le transfert d’images, de vidéos, et la navigation sur Internet

requièrent un débit important, une faible latence, et une bonne qualité de service. En

revanche, dans les réseaux de capteurs conçus pour surveiller une zone d’intérêt, la longévité

du réseau est fondamentale. De ce fait, la conservation d’énergie est devenue un critère de

performance prépondérant et se pose en premier lieu tandis que les autres critères comme le

débit ou l’utilisation de la bande passante sont devenus secondaires.

L’objectif de cette thèse est de traiter le problème de gestion et de supervision des RCSFs

en ce basant sur le protocole SNMP 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 dont le remplacement d’un nœud peut s’avérer impossible.

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. Donc, l’unité de contrôle

d’énergie constitue l’un des systèmes les plus importants. Elle est responsable de répartir

l’énergie disponible aux autres modules. Le coût des communications radio est élevé en terme

de consommation d’énergie donc il est très important de réduire la charge des

communications. 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’articulation et le graphe

biparti.

Le simulateur choisi pour la mise en œuvre de notre solution est le simulateur J-Sim

programmé en java. Nous avons développé une interface graphique pour automatiser la

généralisation des fichiers Scripts « .tcl » en initialisant les paramètres d’entrée.



3

Ce mémoire est organisé en cinq chapitres :

En commençant par une représentation de RCSF, nous décrivons l’architecture d’un capteur

et nous présentons les facteurs et les caractéristiques qui influencent la conception de ce type des

réseaux aussi que ses domaines d’application. Nous introduisons quelques contraintes critiques

telles que la couverture, la connectivité et l’énergie résiduelle.

Le deuxième chapitre est consacré à la description de protocole SNMP en rappelant les

différentes notions et principes de fonctionnement de ce protocole.

Dans le troisième chapitre, nous donnons un état de l’art en résumant les méthodes et les

approches proposées dans le domaine de gestion et de supervision d’un RCSF.

Le quatrième chapitre présente notre protocole de gestion WSN-SNMP en montrant les

algorithmes proposés. On décrit en détail les différentes formes des messages de contrôle et

structures des données. Nous allons voir aussi comment utiliser et manipuler les aspects de la

théorie des graphes dans notre domaine.

Le dernier chapitre est destiné à la partie mise en œuvre de notre contribution. Nous

présentons le simulateur choisi et nous détaillons aussi les modifications qui sont faites dans son

code source. Une représentation de quelques expérimentations est également exposée dans ce

chapitre. Les résultats obtenus montrent que notre protocole se comporte bien.

Finalement, on donnera une conclusion générale que nous avons tirée du travail effectué

et quelques perspectives.

Deux annexes sont ajoutées à la fin de ce support, le premier explique en bref les

différents aspects et mécanismes de la théorie des graphes et le deuxième présente une

introduction sur le simulateur J-Sim et détaille les étapes d’installation.


Chapitre I Représentation des RCSFs

4

Chapitre I RESEAUX DES CAPTEURS SANS FIL

- PRESENTATION -

1.1. Introduction

Les progrès réalisés ces dernières années dans les domaines des microsystèmes

électromécaniques (MEMS) ainsi que des techniques de communication sans fil ont permis

d’apparaître un nouveau type de réseau : le réseau de capteurs sans fil (RCSF). RCSF est

composé d'un ensemble d'unités de traitements embarquées, appelées "capteurs",

communiquant via des liens sans fil. 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.

Dans ce chapitre, nous présentons les RCSF, leur architecture de communication, leurs

différentes contraintes ainsi que leurs diverses applications.

I.2. RCSF -Définition

Le RCSF est un ensemble de capteurs variant de quelques dizaines d’éléments à plusieurs

centaines et parfois plus. Les capteurs remplissent deux rôles: source d’informations et/ou

relais pour le reste du réseau. Ils sont équipés d’une unité de mesure, d’une unité de calcul,

d’une mémoire et d’une interface radio [1,17]. Ils possèdent aussi une batterie ou un système

de récupération d’énergie dans l’environnement. Cette énergie est consommée par les

différents modules qui composent ces nœuds. Comme montre la figure I.2, les capteurs 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 (la figure I.1).



5

Figure.I.1 Des exemples de nœud capteur

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 [7], 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 noeuds. Ils doivent pouvoir

s’auto-gé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 [4], les routes

possibles pour communiquer avec d’autres noeuds donnés [5]. Les communications multi-

sauts sont privilégiées par rapport aux transmissions directes au sink. Le sink est un noeud

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.

Figure.I.2 Architecture d’un RCSF

Capteurs Gateway (Sink)

Utilisateur



6

1.3. Le réseau Ad hoc

Le terme « ad hoc » est une locution d’origine latine qui signifie « qui convient au sujet, à la

situation. » On parle donc de réseaux auto adaptatifs. Une autre lecture de la définition peut

signifier une propriété d’universalité de ce moyen de communication, comme si ce procédé

pouvait satisfaire tous les besoins en terme de communication entre les objets mobiles [1]. Un

réseau Ad-hoc est un réseau sans fil à contrôle décentralisé. C-à-d que les opérations de la

découverte et de la maintenance du réseau se font localement dans chaque nœud.

1.4. RCSF vs réseau Ad-hoc

Les RCSF sont souvent considérés comme étant les successeurs des réseaux ad hoc. Les

RCSF partagent avec Ad-hoc plusieurs propriétés en commun, telles que l'absence

d'infrastructure, les communications sans fil, l’architecture décentralisée, l’autonomie.

Néanmoins l'une des différences clés entre les deux architectures est le domaine d'application.

Le tableau I.1 donne une petite comparaison entre les RCSF et les réseaux Ad-hoc.

Tableau 1.1. Comparaison entre deux types de réseaux : Ad-hoc et RCSF

RCSF Ad hoc

Objectif ciblé Générique/communication Les nœuds collaborent pour remplir un objectif Chaque nœud a son propre objectif

Plusieurs à un Un à un Energie est un facteur déterminant Débit / Qualité de service

Broadcast Communication ppp Très grand nombre de nœuds n’ayant pas Identification unique

Grand nombre de nœuds Relativement réduite Déploiement très dense Beaucoup moins dense

Enclin aux défaillances/pannes Plus résistant Processeurs limité en calcul CPU très performant

Mémoire de quelques Kilo-octets Méga-octets

1.5. 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 [14]. Par exemple, quand les capteurs



7

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. En outre, un autre type de mobilité pourrait être pris en

compte, qui est la mobilité de la station de base ou les deux types de dispositifs peuvent être

mobiles simultanément.

1.6. Les domaines d’applications

Les RCSF ont su attirer un nombre croissant d'industriels, vu leur réalisme et leur apport

concret. En effet, le besoin d'un suivie continu d'un environnement donné est assez courant

dans diverses activités de la société. Les processus industriels, les applications militaires, le

monitoring d'habitat, ainsi que l'agriculture de précision ne sont que quelques exemples d'une

panoplie vaste et variée d'applications possibles du suivi continu offert par les RCSF (voir la

figure. I.3). Parmi elles, nous citons :

• Le domaine militaire : les RCSFs sont utilisés dans le domaine militaire pour avoir une

meilleure connaissance de la zone de combat en particulier l'état des troupes et de

l'armement, les changements de topographie du terrain, la détection et le collecte

d'informations sur la position de l'ennemi, la reconnaissance des attaques nucléaires ou

chimiques, surveillance des zones hostiles, détection d’attaques nucléaires, biologiques,

chimiques et bactériologiques...

• L’environnement : les capteurs peuvent être déployé pour la détection et la

localisation des événements environnementaux, tel que les séismes, des feux de forêt,

des inondations, de polluants dans l’air ou dans le sol. D’autres études incluent la Bio-

complexité de l’environnement, la radioactivité et l’agriculture.

• Domotique : on peut citer l’'automatisation de la maison par la communication des

différents éléments comme le four, le lave-vaisselle, la télévision, etc. On peut aussi les

utiliser pour l'étude de l'environnement de la maison et créer des systèmes plus

ergonomiques et esthétiques.

• Le domaine médical : les RCSFs servent la chirurgie, la détection des cellules

cancéreuses, la télésurveillance des données physiologiques, la localisation des patients



8

et des médecins à l'intérieur d'un hôpital ainsi que pour l'administration des doses

précises de médicaments.

• Le domaine des transports : Gestion du trafic routier, ferroviaire, Radars…etc.

Figure.I.3 Quelques applications des RCSFs

Il est aussi envisageable d’intégrer les aspects multimédia dans certaines applications

mobiles mélangeant les données simples avec les images. Les domaines d'applications de

cette technologie sont multiples. De plus, le développement de nouveaux capteurs permettra

d'étendre les domaines d'applications nombreux [12][16][17][18]. En général, les RCSFs sont

rencontrés partout puisqu’ils supportent des nouvelles opportunités d’interaction entre

l’utilisateur final et les équipements. Les RCSF ne sont pas parfaits à cause de leur coût et

leur déploiement dans des zones parfois hostiles, les capteurs sont assez fragiles et

vulnérables à diverses formes de défaillances : cassure, faible énergie, etc. Dans les RCSFs,

plus qu’ailleurs, la nature des applications va influencer sur les protocoles à implanter.

1.7. Les unités d’un nœud capteur

Un nœud capteur se compose de quatre composants de base, illustré dans la figure 1.4. Il

existe des capteurs qui sont dotés d’autres composants additionnels comme le système de

Surveillance médicale

Domaine militaire



9

positionnement GPS (Global Positioning System), un générateur d’alimentation et une unité de

mobilité lui permettant le déplacement. Ces composants additionnels peuvent être implantés

dans un nœud capteur pour certains environnements.

Figure.I.4 Les composants d’un nœud capteur

• L'unité d'acquisition: capteur+ADC

L'unité d'acquisition est composée de deux sous unités : un capteur qui va obtenir des

mesures numériques sur les paramètres environnementaux et un convertisseur

Analogique/Numérique (ADC) qui va convertir l'information relevée en signaux numériques

et la transmettre à l'unité de traitement.

• L'unité de transmission : Émetteur/Récepteur radio

L’unité de transmission est responsable de toutes émissions et réceptions de données via

un support de communication radio.

• L'unité de traitement : Processeur +Mémoire

L’unité de traitement est composée d'un processeur et d'un système d'exploitation

spécifique. 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



10

provenance de l'unité d'acquisition et les envoie à l'unité de transmission. Le tableau suivant

donne quelques caractéristiques pour deux processeurs différents : ATmega128L et PXA271.

Tableau 1.2. Caractéristiques opérationnelles de deux processeurs ATmega128L et PXA271

ATmega128L PXA271 Courant pour l’état actif Courant pour l’état inactif Bits Fréquence d’horloge Cycle de Temps Voltage

8mA 15uA

8 8MHz 124ns

3V

31mA 390uA

32 13MHz 76.92ns

4.5V

• L’unité d’énergie: Batterie+Générateur d’énergie

L’alimentation électrique de chaque capteur est assurée par une batterie individuelle dont

l’énergie est consommée pour la communication, le calcul et le traitement de l’information.

Le facteur d’énergie est donc au centre de toutes les préoccupations sur les capteurs :

protocoles de routage économiques, technologie sans fil adaptée, redondance des

équipements. L'énergie est une contrainte principale pour RCSFs[13] où il faut minimiser les

dépenses énergétiques. Le générateur d’énergie peut être un système de rechargement

d’énergie à partir de l’environnement tel que le système solaire.

1.8. Les nouveautés de la technologie des capteurs

Les tendances actuelles de développement des systèmes embarqués suivent de près les

technologies rendues disponibles par les avancées rapides de la micro-électronique. Ces

tendances sont particulièrement visibles pour les microcontrôleurs et les microprocesseurs

utilisés dans les systèmes embarqués. Les processeurs 32 bits de consommation électrique et

de volume physique moyens peuvent être refondus en utilisant les dernières technologies

disponibles pour devenir des modèles très basses en consommation avec des empreintes

physiques extrêmement réduites (ATmegal28L utilisé pour les modèles MicaZ et Mica2, et

MSP430 de modèles Telosb). Les modèles des nœuds actuels utilisent des microcontrôleurs

16 bits de haute gamme et il y a de fortes chances pour que les prochains modèles utilisent des

processeurs 32 bits comme brique de base. La société Xbow propose actuellement un des



11

premiers modèles de nœud capteur utilisant un processeur 32 bits : PXA271 sur le modèle

xbow Imote2. Le PXA271 est basé sur un XScale, un processeur à jeu d’instruction ARM [6].

La plateforme Imote2 est équipée de 256Ko SRAM locale, 32Mo de Flash et 32Mo SDRAM.

Les auteurs [23] ont conçu un modèle des éléments automatiques nommé AEs, en anglais

Automatic Element, qui sont des petites parties de système automatique, contiennent des

ressources et fournissent des services au manager ou aux autres AEs. Le modèle d’ASE

(Automatic Sensor Element) est basé sur la forme des éléments automatiques (AEs) défini

par Kephart [24] sur l’architecture de gestion nommé MANNA [73]. Ces AEs sont intégré

aux capteurs. L’intégration de ces modules est considérée comme un complément de

systèmes de gestion. Une instance de ce modèle est testée avec des capteurs de type Mica2.

Les capteurs Sunspot : Principaux éléments de la carte de son processeur

SPOT, Sun Small Programable Object Technology, est une nouvelle technologie de

capteur développée dans le laboratoire de SUN [25]. Il est de 180 Mhz de processeur

ARM950 de 32 bits avec RAM 512 Ko et mémoire Flash de 4 Mo. Il utilise la technologie

Zigbee (IEEE 802.15.4 2.4Ghz), une antenne intégrée et une interface USB.

I.9. Pile protocolaire des RCSFs

La pile protocolaire des RCSF comprend la couche physique, la couche liaison des données,

la couche réseau, la couche transport, la couche application et trois plans : plan de gestion de

puissance, plan de gestion de mobilité et plan de gestion des taches [16].

MAC est un protocole de routage et d’accès au medium, conçu pour fonctionner avec peu

d’énergie et qui permet d’éviter un certain nombre de collisions grâce à un système

d’émission après un délai aléatoire. La norme IEEE 802.15.4 a été spécialement définie en

fonction des caractéristiques des réseaux de capteurs (faible débit, faible consommation

électrique) pour la couche physique, et la couche MAC. La spécification ZigBee propose une

pile protocolaire propriétaire et légère, déclinable dans plusieurs versions. Elle s’appuie sur la

norme IEEE 802.15.4 pour deux couches (physique et liaison de données) [15].



12

Tableau.I.3. Les paramètres de modulation d’IEEE 802.15.4 [22]

Physique Bande de fréquence

GHz

Paramètres des donnes Paramètres de l’étalement

Bit rate (kb/s)

Symbol rate (kBaud) modulation Chip rate

MChips/s modulation

868/915 0.868-0.8686 20 20 BPSK 0.3 BPSK

Mhz PHY 0.902-0.928 40 40 BPSK 0.6 BPSK

2.4 Ghz PHY 2.4-2.4935 250 62.5 16-ary

orthogonal 2.0 O-QPSK

Elle propose ses propres couches supérieures et réalise des fortes économies d’énergie

grâce à une optimisation des périodes de mise en veille de nœud. La technologie

IEEE.802.15.4 peut typiquement être utilisée pour des RCSFs à fortes contraintes

temporelles. Cette norme définit trois modèles transactionnels possibles: le transfert de

données du sink vers un capteur, transfert de données d’un noeud de réseau vers le

coordinateur et transfert de données de deux noeuds du réseau entre eux.

Figure.I.5 La structure de canal d’IEEE.802.15.4 [22]

Deux topologies sont supportées par le protocole 802.15.4 ; la topologie en étoile et la

topologie point à point. Dans la topologie en étoile, les communications s’établissent

directement entre le coordinateur et les capteurs, le coordinateur étant le nœud central qui

initie et gère les communications dans le réseau. La topologie point à point se rapproche alors

plus de mode de communication tel qu’il est structuré dans le réseau Ad-hoc. La topologie

point à point nécessite l’utilisation d’un protocole de routage (routage mech, ad hoc…etc).



13

I.10. 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.6 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.

Figure.I.6 Les états possibles d’un nœud capteur

I.11. Les caractéristiques et les problèmes liés aux RCSFs

La conception du réseau de capteur est influencé par beaucoup de facteurs comme la

tolérance aux pannes, la scalabilité, l’environnement de capture, la topologie de réseau, le

coût de production, les contraintes de matériel, le média de transmission, la sécurité de

réseau, la communication et l’agrégation d’information, prendre en compte la mobilité, la

dégradation d’énergie de chaque nœud participant au réseau, la connectivité du réseau,

l’intelligence de groupe et l’auto-organisation [16]. Les réseaux de capteurs sont limités dans

leurs performances par des phénomènes physiques. Il convient de répertorier les spécificités

des RCSFs: les capacités de traitement et de mémoire, faible débit (10 Kbit/s pour chaque

noeud), l’auto-configuration, changement fréquent de topologie, forte densité des nœuds, la

redondance et la collaboration, tolérant aux erreurs, les nœuds capteurs peuvent ne pas avoir



14

d’identification globale, l’inévitabilité des interférences, la congestion[10], la sécurité faible,

l’auto organisation, sans infrastructure, l’alimentation par batterie, transmission multi sauts,

les noeuds sont de petites dimension (< 1cm3) et coût faible .

Ø Déploiement des nœuds capteurs

Le déploiement peut être déterministe ou aléatoire. Dans la première stratégie, les capteurs

sont placés manuellement et les données peuvent donc être acheminées via des chemins

prédéterminés. En revanche, avec une approche aléatoire, les capteurs sont éparpillés.

Ø La densité de réseau

La densité peut varier de quelques noeuds à quelques centaines de noeuds 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 :

(1)

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.

Ø 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.

Ø La tolérance aux fautes

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 en cas de manque de

puissance, dommage physique de nœud ou des interférences. 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



15

tolérance de panne d'un capteur. Elle 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):

teR t

k λλ *−= (2)

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

Ø La configuration

Elle comprend le recensement des ressources du réseau ainsi que leur configuration

physique et logicielle. Elle intervient notamment lors de l’intégration de nouveaux

équipements ou lors du déploiement de nouveaux services à travers les différentes opérations.

Ø L’hétérogénéité des noeuds

Dans de nombreuses études, tous les capteurs sont considérés homogènes, i.e. même

capacité de calcul, de communication et d’énergie…etc. Néanmoins, en fonction de

l’application, certains capteurs peuvent avoir des rôles différents, générant une architecture

hétérogène. Pour un RCSF hiérarchique, certains capteurs sont déclarés « Head » pour leur

groupe. Le routage vers les stations de base est alors traité par ces derniers.

Ø Notion de cluster [21]

L’organisation des noeuds 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 noeuds mais cela ne

fonctionne que dans le cas d’une faible mobilité.

Ø L’agrégation de donnée

L’agrégation des données similaires en provenance de différents noeuds permet de réduire

le nombre de transmissions par fusion des données. Les protocoles d’agrégation permettent

de réduire la consommation d’énergie [31].

Ø Consommation énergétique

Les capteurs utilisent leur réserve d’énergie à des fins de calcul et de transmission de

données. La durée de vie d’un nœud capteur dépend essentiellement de celle de sa batterie. Le

dysfonctionnement d'un nœud peut modifier la topologie de réseau et nécessite le

réacheminement des paquets et de la réorganisation du réseau. Par conséquent, la gestion de



16

consommation d’énergie est devenue un nouvel axe de recherche où plusieurs chercheurs ont

pensé à la conception des nouveaux protocoles et algorithmes pour les RCSFs. La tâche

principale d'un noeud est de détecter des événements, effectuer les traitements locaux des

données rapidement, puis transmettre les données. La consommation d'énergie peut donc être

divisée en trois parties: détection de signal, communication et traitement des données.

Ä Un modèle classique; Heinzelman et al [30] propose un modèle de

consommation d’énergie pour les noeuds capteurs. Le tableau.I.4 reproduit ce modèle.

Tableau.I.4. L’énergie consommée suivant l’état de capteur [30]

Mode de Radio Energie Consommé

ETx-elec / TRx-elec 50 nj/bit

ETx-amp 100 pj/bit/m2

Eidle 40 nj/bit Sleep 0

Ä Un modèle spécifique pour Mica2 ; Polastre et. al [11] propose un modèle de

dissipation d’énergie pour Mica2 dans les différentes opérations comme la transmission, la

réception et l’écoute. Les valeurs sont calculées en mesurant la consommation de CPU et de

radio. Le tableau suivant donne le coût des différentes opérations pour le modèle de Mica2.

Tableau 1.5 Le modèle énergétique de Mica2 [11]

Opération Temps (s) Initialisation de radio 350E-6 Ouverture de radio (c) 1.5E-3 Passage de RX au TX (d) 250E-6 Time to sample radio 350E-6 Evaluate radio sample 100E-6 Réception d’un byte 416E-6 Transition d’un byte 416E-6 Collecte de données 1.1

Les causes de surconsommation sont les suivants:

− L’écoute libre, lorsqu’un nœud a sa radio allumée parce qu’il attend un paquet.



17

− Les collisions entre les trames causent des consommations inutiles. Parfois les

collisions entraînent des retransmissions des paquets.

− Quand un nœud reçoit une trame qui ne lui est pas destinée, il dépense de l’énergie

inutilement. Ce cas est appelé sur-écoute “overhearing”.

− Le protocole MAC lui-même peut avoir besoin des messages de contrôle qui

contribuent à des pertes d’énergie. Les acquittements sont des paquets envoyés par le

récepteur pour confirmer qu’il a bien reçu les données. RCSF devient inutilisable

lorsque la connectivité entre les noeuds est perdue ou lorsque le rôle de collecte ne peut

pas être assuré pour toutes les cibles à couvrir. Une méthode efficace pour réduire la

consommation d'énergie consiste à éteindre les nœuds lorsqu'ils ne sont pas utilisés [2]

mais les nœuds capteurs doivent être synchronisés.

La conservation d'énergie reste est un problème critique pour les RCSFs, et nécessite la

proposition des solutions optimales qui minimisent la consommation d’énergie dans tous les

niveaux de la pile protocolaire.

Ø La sécurité

Elle vise la protection du réseau en empêchant l’ensemble des activités frauduleuses qui

peuvent avoir un impact sur l’intégrité et le bon usage des services. Elle comprend les

mécanismes d’authentification, de contrôle d’accès et de confidentialité ainsi que

l’administration des infrastructures de sécurité. TinySec [27] est un package générique qui

peut être intégré dans les applications de réseaux de capteurs. Il est incorporé dans le système

TinyOS officiel et donne une couche de liaison sécurisée.

Ø Média de transmission

Dans un réseau de capteur à multi sauts, les liens peuvent être formés par radio,

infrarouge, ou de supports optiques. La communication infrarouge est sans permis et robuste

aux interférences provoquées par les appareils électriques. L’infrarouge est basé sur des

émetteurs moins chers et plus faciles à construire.

Ø 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 monitoring qui permettent de

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



18

que la disponibilité de service, 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.

Ø La topologie de réseau

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

déploiements sont figuré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.

Les réseaux de capteurs peuvent être mobiles ; le déploiement d’un réseau de capteurs

pour la surveillance du déplacement d'animaux. Il faut donc s'attendre à ce que la topologie du

réseau soit en permanente modification. Cela signifie qu'il faut trouver des protocoles de

routage adaptés, efficaces, tout en étant économiques.

Ces facteurs sont importants pour la conception d'un protocole ou l’implémentation d'un

algorithme pour les réseaux de capteurs. Ces facteurs influençant peuvent être employés pour

comparer différentes solutions.

I.12. La localisation des nœuds dans le RCSF

La détection des emplacements nécessite la dérivation des informations de position des nœuds

capteurs, énoncé aussi des coordinateurs globaux où à l’intérieur des systèmes de définition

des coordonnées. La localisation des nœuds fait référence au problème d’estimation de leurs



19

coordonnées. Bien que le GPS puisse potentiellement fournir un positionnement précis, la

complexité des récepteurs exigés peut être trop coûteuse pour des capteurs peu coûteux [3].

I.13. Le stockage des données

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.

Ratnasamy et al. [34][35] décrit trois paradigmes de stockage des données pour les RCSFs:

• Stockage externe : dans ce modèle, quand un noeud 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 noeud capteur. L’avantage de cette approche est qu’elle

n’implique pas des coûts de communication initiaux. Les requêtes envoyées au RCSFs

sont inondées à tous les nœuds. Les noeuds transmissent ces données à la station de base

pour d’autre traitement.

• 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 Couverture

Chaque nœud perçoit une vue locale de son environnement, limitée par ses deux rayons. La

couverture d’un vaste espace déterminé est donc composée de l’union de nombreuses

couvertures de petite taille. La redondante matérielle peut être utilisée pour garantir une

couverture maximale d’une région où des points dans la région. Trois types de couvertures

sont définit [28] : la couverture d’une zone, la couverture d’une point et la couverture d’une

barrière. Les capteurs fonctionnent avec un modèle à seuil, c'est à dire qu'un capteur possède

deux zones : une zone de couverture avec un rayon de couverture noté « r » et une zone de

communication avec rayon de transmission noté « R ». Pour schématiser, on considère que

ces zones sont représentées par deux cercles qui ont pour centre le capteur comme le montre

la figure.I.7. En influant sur le rapport entre les deux rayons r et R, on va modifier les

contraintes. Pour qu'une zone soit complètement couverte, il faut que la densité de capteurs



20

soit suffisante. Si elle est trop importante et que la zone que l'on veut surveiller est trop

couverte, alors des capteurs vont fonctionner inutilement.

r R

s

Figure.I.7 Modèle géométrique des deux régions d’un capteur: couverture/communication.

Les applications auxquelles sont dédiés les réseaux de capteurs imposent des exigences

supplémentaires de fiabilité et surtout d’économie d’énergie afin de ne pas gaspiller l'énergie,

les capteurs qui fonctionnent inutilement vont se mettre en veille (le mode Sleep). Ce

mécanisme va devenir une stratégie à part entière pour augmenter la durée de vie du réseau.

En effet, en choisissant une densité volontairement élevée de capteurs, on va multiplier le

nombre de capteurs redondants. Ainsi de nombreux capteurs seront en mode veille et pourront

se substituer aux capteurs défaillants si nécessaire. Pour cela, on distingue deux modèles de

couverture :

• Couverture de zone par seuil, un noeud reste actif si aucun autre n'est actif dans un

rayon r autour de lui. Un noeud actif peut rester jusqu'au bout. Cette méthode est simple

mais pas fiable.

• Couverture de zone par intersection, si tous les points d'intersection de la zone de

couverture d'un noeud A et d'un noeud B sont compris dans une troisième zone de

couverture, alors le noeud A peut se mettre en veille.

I.15. La connectivité

Le réseau de capteurs est dit connecté si et seulement s’il existe au moins une route entre

toute paire des nœuds. Le changement de la topologie de réseau est dû à la mobilité des

nœuds, défaillance de quelques nœuds, manque de sécurité. La connectivité est une mesure de

tolérance aux fautes ou de diversité de chemin dans le réseau.

r : Rayon de couverture

R : Rayon de Transmmission



21

• Définition 1 - Un graphe symétrique est connexe si et seulement si pour toute paire de

noeuds du réseau, il existe au moins un chemin, permettant d'aller d'un noeud à l'autre.

• Définition 2 - Soit « x » un nœud, on appelle voisinage de x l’ensemble N(x) contenant

les nœuds que x peut joindre directement. La relation binaire représente un lien de

communication et supposée symétrique. Toute route disponible n’est pas forcement une

route intéressante pour la communication, il peut être une route très longue, route avec

des nœuds de faible énergie ou contenant des boucles.

• Définition 3 - K-connectivité : s’il y a au moins K disjoints chemins. 1-connectivité est

une condition fondamentale pour que le réseau soit opérationnel mais pas suffisante [36].

Mise en œuvre des systèmes de surveillance dont l’objectif d’être capable de fournir

fréquemment les états de fonctionnement des nœuds et des mesures.

I.16. Système d’exploitation pour les RCSFs

TinyOS est un système d’exploitation open source le plus répondu dans la littérature, conçu

pour les RCSFs [32][33]. Il met une architecture basé sur les composantes pour

l’implémentation des applications de RCSFs. TinyOS présente une bibliothèque qui inclut des

protocoles, des services distribué et les outils d’acquisition des données et porte des

plateformes divers. Il propose à l’utilisateur une gestion très précise de la consommation et

permet de mieux s’adapter à la nature aléatoire de la communication sans fil entre les

interfaces physiques [12].

I.17. La classification des protocoles de routage

La problématique du routage est essentielle dans ce type de réseau et il doit être efficace en

énergie. Pour cela, il faut être capable de trouver une route pas trop longue et sans dépenser

trop d’énergie. Les protocoles dans lesquels on maintient à jour des tables de routage à l’aide

d’envois périodiques de paquets “Hello” ont un coût constant non négligeable. Ce coût

constant est particulièrement pénalisant puisque l’on a des trafics très sporadiques : maintenir

une table de routage, pour avoir des routes très efficaces, n’est pas intéressant si l’on n’utilise

que très rarement ces routes. La figure I.8 classifié des différents solutions qui ont été

proposées pour résoudre ce problème [26][37][38][39][40][48].



22

Figure.I.8 Les différents protocoles de routages dédiés pour les RCSFs.

Nous présentons ici des protocoles de routages répartis en quatre catégories:

hiérarchiques, basés sur la localisation, centrés données et avec considération du flux réseau.

Ø Les protocoles centralisés : fonctionnent sur des réseaux de petite taille. Or, même si

les RCSFs sont apparentés aux réseaux Ad-hoc, les spécificités, les objectifs et les besoins

sont différents.

Ø Les protocoles hiérarchiques : le principal du routage hiérarchique est de maintenir

efficacement la consommation d’énergie des nœuds capteurs en les impliquant dans une

communication multi-sauts dans un cluster particulier et en exécutant l’agrégation et la fusion

des données afin de diminuer le nombre de messages transmis au sink.

Ø Les protocoles basés sur la localisation : dans la plupart des protocoles de routage basé

sur la localisation des nœuds, il est nécessaire afin de calculer la distance entre deux nœuds

particuliers de sorte que la consommation d'énergie puisse être estimée.

Ø Protocoles avec considération du flux du réseau et de QoS : Les protocoles de routage

décrits par la suite adoptent des approches d’établissement de chemins en considérant

l’agrégation des données, le flux de réseau et la qualité de service (QoS).



23

Tableau 1.6. Comparaison entre quelques protocoles de routage pour les RCSFs.

Protocole de routage Données centralisées Hiérarchique Basé sur la

localisation QoS flux du réseau

Agrégation des données

Gossiping/Inondation [111] FSR [125]

OLSR [113] DSR [124]

AODV [105] ZRP [127]

Diffusion dirigée [26] SPIN [104] Routage par rumeur [45]

LEACH [47] PEGASIS[86]

TEEN [29] APTEEN[126]

Younis [44]

MECN[128] SMECN[118]

GAF[46] GEAR [20]

-Routage a énergie pour

une durée de vie maximale [96]

-Collecte de données de durée de vie maximale [8]

-Transmission à coût minimal [9]

SAR[16]

SPEED[108]

+ + + + + + + + +

+ +

+ + + + +

+

+

+

+

+ + + +

+

+

+

+ +

+

+

+

+ + +

+ + + +

Le tableau I.6 donne une comparaison entre plusieurs protocoles de routage classés

suivant les quatre catégories citées. Certaines utilisent les informations de localisation des

capteurs pour effectuer le routage [37-39]. Ces méthodes supposent que chaque capteur a la

connaissance exacte de sa position, soit grâce à la technologie GPS, soit grâce à des méthodes

de localisation telles que de [41-43] comme ça été décrit dans la section I.12. De telles

méthodes de localisation utilisent soit une estimation de la distance séparant deux capteurs, en

fonction des propriétés du signal reçu, soit en fonction de l’angle d’arrivée du message. Les

méthodes de localisation utilisent ces connaissances afin d’en déduire la position estimée des



24

noeuds du réseau. Les protocoles de routage pour les réseaux Ad-hoc doivent vérifier des

propriétés et assurer certaines fonctions comme la distribution des opérations, où chaque

nœud agisse tout seul suite à un événement, le protocole doit générer des routes sans cycle.

Les protocoles dédiés pour les réseaux de capteurs, sont peu nombreux. Les noeuds

demandent une gestion soigneuse des ressources. Les multiples capteurs peuvent produire les

mêmes données à proximité d'un évènement. Les protocoles de routage spécifiques aux RCSF

doivent tenir compte du type de communications induit par l’application. Outre le fait que la

quantité de données échangées est très faible par rapport aux applications de types réseaux

Ad-hoc. Les RCSFs empruntent les protocoles de routage des réseaux Ad-hoc sur des réseaux

de petite taille.

I.18. Conclusion

Depuis quelques années, les réseaux de capteurs ont suscité un intérêt croissant dans le monde

des télécommunications, du traitement de signal et des réseaux sans fil. Les progrès de

miniaturisation et d'allongement de durée de vie des batteries, annoncent un futur prometteur

à cette technologie. La recherche dans le domaine des capteurs subit actuellement une

révolution importante, ouvrant des perspectives d’impacts significatifs dans de nombreux

domaines d’applications. Les progrès dans le domaine des communications numériques sans

fil nous permettent d’imaginer des réseaux de capteurs totalement autonomes avec des durées

de vie importantes. Les réseaux de capteurs, tout comme les réseaux Ad Hoc, souffrent de

nombreuses limitations en termes de performance, de fait du manque d’infrastructure et de la

nature du medium sans fil. La minimisation d'énergie est en général le vrai problème qui doit

être considéré à tous les niveaux de la pile de communication. Un des éléments clés d'une

telle optimisation repose sur la mise en place de protocole de gestion.


Chapitre II Protocole SNMP

25

Chapitre II

PROTOCOLE

SIMPLE NETWORK MANAGEMENT PROTOCOL

II.1. Introduction

Le matériel informatique est de plus en plus sophistiqué et permet d’être contrôler à distance;

c’est là un des points fondamentaux de la gestion de réseau, il est aujourd’hui nécessaire,

étant donnée l’étendue des réseaux, de pouvoir le gérer à distance depuis son poste de travail

et n’avoir pas à se déplacer qu’en dernier recours, lorsqu’une opération physique est

nécessaire. La centralisation de la gestion d’un réseau permet également d’effectuer

simultanément des mêmes opérations sur plusieurs matériels. Avec l’absence de poste central,

il aurait fallu se déplacer pour chaque matériel afin d’y appliquer ladite modification: la

centralisation offre un gain de temps considérable. Des nombreuses composantes peuvent être

à surveiller: l'utilisation de la largeur de bande, l'état de fonctionnement des liens, les

problèmes de câblage, le cheminement de l'information entre les machines, etc. Un des

moyens les plus répandus permettant d'administrer un réseau est l'utilisation du protocole

SNMP qui est uniquement destiné à cette tâche.

Dans ce chapitre, nous nous intéresserons tout d'abord aux concepts fondamentaux de

l'administration en utilisant le protocole SNMP, nous verrons à plus précisément sur SNMP et

ses améliorations, les versions qui suivent la première version, puis nous nous pencherons à la

représentation de la MIB qui est largement utilisée avec le protocole SNMP.

II.2. SNMP : Présentation générale

SNMP est un protocole de la famille TCP/IP proposé par l'IETF: Internet Engineering Task

Force, et peut donc être utilisé sur tous les réseaux de type Internet. Il exploite les capacités

du protocole de transport UDP [49][51][60]. Il est actuellement le protocole le plus utilisé

pour la gestion des équipements de réseaux. Pourtant l'ensemble de ses fonctionnalités est



26

suffisamment puissant pour permettre la gestion des réseaux hétérogènes complexes

[114][115]. Il est aussi utilisé pour la gestion à distance des applications : les bases de

données, les serveurs, les logiciels, etc.

En 1988, alors que SNMP en était à ses débuts, la norme ISO CMIP (Common

Management Information Protocol) était considérée comme la solution d’avenir pour la

gestion des réseaux : plus puissante, plus sûre et plus fiable. CMIP définit le format des

messages et les procédures utilisées pour échanger des informations de gestion et

d'administration de façon à administrer, à exploiter, à maintenir un réseau. Il repose sur

l'utilisation des bases de données contenant les informations utiles à l'administration de réseau

[54]. La transition au CMIP n’était pas matérialisée, SNMP est vu comme un protocole

standard de l’industrie utilise pour gérer les réseaux IP actuels. Le CMIP est un protocole

supérieur au SNMP tant aux niveaux design et sécurité, mais il est très difficile à mettre en

oeuvre et sa complexité exige des appareils assez performants.

CMIS (Common Management Information Services) est un ensemble de services définis

par l'ISO, constitués de primitives décrivant comment doivent être consignés les événements

survenant sur le réseau [54]. Ces services permettent de normaliser l'ensemble des services.

Le protocole SGMP (Simple Gateway Management Protocol) est proposé pour la gestion

des routeurs. Actuellement, le protocole SNMP est le plus utilisé pour la gestion des

équipements de réseaux (routeurs, switchers, serveurs, imprimantes, modems…etc).

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. Il permet de gérer l’exécution des taches de réseau, la

détection et le diagnostic des problèmes. Il est aussi utilisé pour la gestion à distance des

applications : les bases de données, les serveurs, les logiciels, etc. D’où l’existence des

logiciels basés sur ce protocole: NetView (IBM-Tivoli), OpenView (HP), SunNet Manager,

SNMPc …

Ä Comme pour tout protocole, les références essentielles sont les RFCs (Request For

Command) ; des nombreuses documentations sont disponibles sur Internet, notamment

sur le site web d’IETF [49].



27

II.3. Les différentes versions de SNMP

La première version de SNMP, SNMPv1, a été conçue à la fin des années 80 et standardisée

dans l’année 1990 [51]. Sa conception permettait de gérer la plupart des contraintes de

gestion, mais un certain nombre de lacunes persistaient : manque de l’hiérarchie, peu de codes

d’erreur et de notifications, faibles performances, absence de sécurité, etc… L’ensemble de

ces problèmes a entraîné le développement d’une nouvelle version de SNMP, nommée

SNMPv2, et dont la conception a commencé en 1993. Le tableau suivant présente quelques

standards et drafts de RFCs publiés pour les différentes versions de protocole SNMP.

Tableau.II.1. Quelques RFCs pour le protocole SNMP

Version Année RFCs Titre Statut V1 1990 1155 La structure et l’identification des

informations de gestion pour TCP/IP basé Internets

Standard

1156 La base d’information de gestion pour la gestion de réseau de TCP/IP basé internets

Historique

1157 Protocole simple de gestion de réseau Historique V2 1996 1901 Introduction de SNMPv2 à base Community historique, proposé

comme expérimental 1902 Structure de gestion d’information pour la

Version 2 de SNMPv2 standard, remplacé par RFC-2578

V3 1999 2571 An Architecture for Describing SNMP Management Frameworks

standard, remplacé par RFC-3411

2000 2576 Coexistence entre les Version 1, 2, 3 pour une plateforme standard de gestion de réseau Internet

Standard proposé

2002 3411 Un Architecture pou la description de plateforme de gestion SNMP.

standard

3418 Base d’information de gestion (MIB) de SNMP

standard

D'une manière générale, vous pouvez consulter le site de rfc-editor pour retrouver d’autres

RFC, avec des informations sur leur statut (expérimental, obsolète, actif...)

SNMPv2p: 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. SNMPv2

est capable de gérer de manière distribuée un réseau: des opérations entre les stations



28

d'administration, la sécurité renforcée. Cette version est décrite dans les RFCs suivants : RFC

1441, RFC 1445, RFC 1446, RFC 1448 et RFC 1449.

SNMPv2c (expérimental): Cette version est appelée «community string based 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 des caractères « community » de SNMPv1. Cette version est

définie dans les RFCs suivantes: RFC 1901, RFC 1905 et RFC 1906. Avec la version 1, la

plate forme est obligée de faire un GETNEXT et d'attendre la réponse pour chaque variable

de gestion. Ceci règle un problème majeur de performance dans SNMPv1.

SNMPv2u (expérimental): Cette version utilise les opérations, les types de données de

SNMPv2c et la sécurité basée sur les usagers. Cette version est décrite dans RFC 1905, RFC

1906, RFC 1909 et RFC 1910.

SNMPv2* (expérimental): Le groupe de travail SNMPv2 de l'IETF a terminé ses travaux

en publiant une version de SNMPv2 (SNMPv2c) où il combine les meilleures parties de

SNMPv2p et SNMPv2u. Le groupe IETF 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. La

version la plus utilisée actuellement est SNMPv2c, mais la tendance s’inverse avec

l’introduction de la 3ème version en 1997.

SNMPv3 : Cette version, trop récente, ajoute à la précédente la sécurité, ainsi qu’une

gestion hiérarchisée, mais sa complexité accrue entraîne des difficultés d’implémentation et

une charge de mise en œuvre plus délicate que sur les versions précédentes. La constitution de

la trame SNMPv3 est très différente de celle de SNMPv1. La dite version 3, RFC2576 [63]

donne une description de coexistence entre les trois versions.

SNMP version 6, étant indépendant de l'architecture du protocole IP, son évolution vers

IPv6 n'a pas représenté un problème majeur. La première implémentation de SNMP pour le

protocole IPv6 a été réalisée par l'équipe du Loria de l'université de Nancy et a été disponible

dans la version 5.0.3 de net-snmp, en 2002[61]. Avant cette première version, l'administration

des réseaux IPv6 était possible du fait que les équipements avaient une double pile configurée



29

IPv4 et IPv6. En effet, il n'était possible d'accéder en SNMP sur un équipement qu'en IPv4 et

de récupérer des champs de la MIB concernant IPv6. L'évolution des MIBs est plus complexe.

Depuis les spécifications initiales du protocole IPv6, la définition de la MIB-2 pour

l'administration des réseaux IPv6 a été modifiée deux fois, en 1998 et en 2000. En 1996, une

représentation initiale du champ ‘IP ADDRESS’ est décrite dans le RFC 1902 où la longueur

réservée pour ce champ est de 4 octets. Avec ce champ ne peuvent être représentées que les

adresses IPv4 puisque les adresses IPv6 ayant une longueur de 128 bits. C'est pourquoi, en

1998, le RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.

II.4. Les implémentations existantes du SNMP

Il existe des différentes implémentations du SNMP, de part le fait qu’il s’agit d’un protocole

parfaitement bien défini et qu’il est de plus en plus exploité au sein des réseaux. Certaines

fournissent des applications de gestion SNMP, d’autres fournissent des bibliothèques de

fonctions (API) pour la gestion SNMP, l’API SNMP4J [67] est fondé sur la technologie

Orienté Objet sous java. Certaines fournissent les deux, comme la distribution net-snmp [65]

du domaine libre. Celle-ci propose les applications de base pour débuter et utiliser

efficacement SNMP. Adventnet[66] est une équipe de développeurs américains connu pour

ces SNMP-APIs (la 1er version est sortie en 1996). On note dans la plupart des distributions

le même ensemble d’applications de base pour la gestion du matériel via SNMP. La plupart

des matériels réseaux administrables d’aujourd’hui embarquent dans leur système

d’exploitation un agent SNMP pour gérer le matériel à distance.

II.5. Architecture de SNMP

L'environnement de gestion SNMP est constitué de la station de supervision, les éléments

actifs du réseau, les variables MIB et un protocole (voir la figure II.1). Les différentes

composantes du protocole SNMP sont les suivantes :

• Les éléments actifs du réseau sont les équipements ou les logiciels que l'on cherche à

gérer. Cela va d'une station de travail à un concentrateur, un routeur, un pont, etc.

Chaque élément du réseau dispose d'une entité dite agent qui répond aux requêtes de la

station de supervision. Ils cherchent l'information de gestion.



30

• La station de supervision, appelée manager, exécute les applications de gestion qui

contrôlent les éléments réseaux.

• La MIB est une collection d'objets résidant dans une base d'information virtuelle. Ces

collections d'objets sont définies dans des modules MIB spécifiques.

• Le protocole permet à la station de supervision d'aller chercher les informations sur les

éléments de réseaux et de recevoir des alertes provenant de ces mêmes éléments.

Figure.II.1 Architecture de SNMP.

Deux ports sont désignés pour l'utilisation de SNMP : le port 161 est utilisé par l'agent

pour recevoir les requêtes de la station de gestion et le port 162 pour l'écoute des alarmes

destinées à la station d'administration.

Trap



31

II.6. Principe de fonctionnement

Pour que SNMP fonctionne, il n'y a pas qu'un protocole d'échange à définir. Le protocole

SNMP est basé sur un fonctionnement asymétrique, il est constitué d'un ensemble de requêtes,

de réponses et d'un nombre limité d'alertes (Figure II.2). Le manager envoie des requêtes à

l'agent qui doit retourner des réponses. Lorsqu'un événement anormal surgit sur l'élément dans

le réseau, l'agent envoie une alerte au manager.

Figure.II.2 Ensemble des messages de SNMPv2

Il y a aussi une standardisation des informations que ce protocole peut transporter. C'est

pour cette raison que l'on parlera de MIB et de SMI. Le protocole SNMP se base sur le fait

qu’il existe une station de gestion, 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.

I1.7. Les applications

Une application est un sous-système propre aux fonctions de l’entité SNMP concernée. La

figure suivante schématise ces différentes applications et modules. La collection

d’information de gestion est accessible par les entités SNMP. L’objet de l’information de

gestion peut exister dans plus d’un contexte.



32

Figure.II.3 Entité de SNMP

• Proxy : l’utilisation de SNMP nécessite que tous les agents supportent un protocole

commun, tel que UDP et IP, ce qui limite l'utilisation à certaines machines en excluant les

PC et les stations de travail, ces dernières pouvant implémenter TCP/IP mais pour lesquelles

il serait indésirable d'ajouter SNMP. Afin de palier ce problème, le concept de proxy a été

développé. Ces proxies suppléent les machines inadaptées car ils connaissent les objets de la

MIB nécessaires pour la gestion du système mandaté. La communication entre le proxy et la

machine suppléée ne peut utiliser SNMP pour dialoguer.

• Retransmission de requête [52] : pour tous les types de requête de ce protocole, le

récepteur de requête doit générer et transmettre une réponse à la source de demande. Si

aucune réponse correspondante n’est reçue dans un intervalle de temps donné, le manager

SNMP entity NOTIFICATION ORIGINATOR

applications

NOTIFICATION RECEIVER application

COMMAND GENERATOR

application

Security Subsystem

Other Security

Model

User-based Security

Model

UDP IPX other

Network

Message Processing Subsystem

v1MP

v3MP

otherMP

PDU Dispatcher

Message Dispatcher

Transport Mapping (e.g. RFC1906)



33

doit transmettre à nouveau la requête. Toutefois, une telle application doit agir de façon

responsable en ce qui concerne la fréquence et la durée de re-transmissions.

II.8. Les MIBS : Management Information base

La MIB est une base de données qui décrit les informations de gestion maintenue par l'agent,

auprès de laquelle le manager va venir pour s'informer. Un fichier MIB est un document texte

écrit en langage ASN.1 (Abstract Syntax Notation 1) qui décrit les variables, les tables et les

alarmes gérées au sein d'une MIB:

NOMDUMODULE DEFINITIONS ::=

BEGIN

Relations avec les autres modules (clauses IMPORT et EXPORTS)

Définition des objets

END

La MIB est une structure arborescente dont chaque noeud est défini par un nombre ou

OID (Object Identifier). En général, Elle contient une partie commune à tous les agents

SNMP d'un même type de matériel et une partie spécifique à chaque constructeur. Chaque

équipement à superviser possède son propre MIB. Non seulement la structure est normalisée,

mais également des appellations sont présentées dans un souci de lisibilité. En réalité, chaque

niveau de la hiérarchie est repéré par un index numérique et SNMP n'utilise que celui-ci pour

y accéder. Ainsi, pour interroger les différentes variables sur un appareil, il faudra explorer

son arborescence MIB. Celle-ci est généralement fournie par le constructeur mais il est aussi

possible d'utiliser un explorateur de MIB. Sans la MIB, le message est juste une chaîne des

nombres. Pour accéder aux variables souhaitées, on utilisera l'OID qui désigne l'emplacement

de la variable à consulter dans la MIB. La description répondant à la norme ASN.1 est

indépendante de la plate-forme. ASN1 est une norme internationale dont la vocation première

est la spécification de données utilisées dans les protocoles de communication. Il s'agit d'un

langage informatique à la fois puissant et complexe: ses traits ont été conçus pour que le

langage modélise efficacement la communication entre les systèmes hétérogènes. Les

versions 1 et 2 de SNMP collectaient toutes les variables dans une seule et même base MIB



34

(MIB-I), définie par une volumineuse RFC-1156[55]. La MIB II (RFC 1158 rendue obsolète

par RFC 1213) s'avère être une base robuste pour la gestion TCP/IP.

Figure.II.4 Description d’objets MIB [58]

L'IETF publie plusieurs RFCs indépendantes détaillant chacune les variables MIB d'un

type de périphérique. Il existe aujourd'hui plus de 100 MIB différentes, chacune pour un

périphérique particulier, regroupant au total quelques 10000 variables. RFC 3433 [68]

collecte hiérarchiquement des paramètres physiques d’un nœud capteur. BRIDGE-MIB

[50] fournit l’information des états de passerelle Ethernet, qui est utilisé pour l’expédition

des paquets entre les différentes parties de LAN. La partie intéressant de cette MIB est

« forwarding database », qui stocke le port utilisé pour enrichir chaque passerelle; car les

ponts fonctionnent d’une manière transparent, construire des requêtes à partir de cette MIB

sur chaque pont est seulement un chemin pour obtenir l’information utile à fin de construire la

topologie de LAN Ethernet.

SNMPv2-MIB DEFINITIONS::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, TimeTicks, Counter32, snmpModules, mib-2 FROM SNMPv2-SMI DisplayString, TestAndIncr, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-

GROUP FROM SNMPv2-CONF; snmpMIB MODULE-IDENTITY LAST-UPDATED "200210160000Z" ORGANIZATION "IETF SNMPv3 Working Group" CONTACT-INFO "WG-EMail: [email protected] Subscribe: [email protected] Co-Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300

Rockville, MD 20850-4601 USA EMail: [email protected]



35

IP ICMP EGP AT

TCP UDP

INTERFACES

Transmission

S NM P

SYSTEM

Tableau II.2. La structure d’objet de protocole SNMP et de CMIP

SNMP CMIP

Identificateur: sysUpTime ou 1.3.6.1.2.1.1.3 – Syntaxe: TimeTicks – Accès: read-only – Statut: mandatory Description : temps en 1/100 s depuis dernier reboot

- Object class: packetCounter - Attributes: single-valued - Operations: get, set - Comportement : récupérer ou remettre les valeurs. - Notification : produire des notifications sur des nouvelles valeurs.

II.8.1. MIB-II

La RFC 1213 (STD 17) [53] décrit le module MIB-2 qui recense les objets devant absolument

être présents sur un agent SNMP ; cette MIB groupe dix éléments (voir figure II.5). Le

tableau suivant dénote les composantes de la MIB II.

Figure.II.5 La représentation des éléments de MIB-II



36

Tableau II.3. La description des éléments de MIB-II

Nom du groupe Description

System Correspond au nom de l'agent, n° de version, type de la machine, nom du système d'exploitation, type de logiciel réseau en ASCII imprimable.

Interface Interface de données dynamiques ou statiques d'une machine (nombre d'interface, type des interfaces et nom du fabricant, vitesse des interfaces, nombre de paquets entrants, sortants, en erreur,...)

Address

Translation

Table d’adresses IP pour les correspondances d’adresses MAC conservé pour des raisons de compatibilité avec MIB-I. il gère une table de translation entre des adresses réseau IP et adresses spécifiques.

IP

Statistiques du protocole IP, adresse cache et table de routage, des différents paramètres : durée de vie par défaut des paquets IP, nombre de paquets reçus ou envoyés, nombre de paquets réassemblés avec succès ainsi que le nombre de fragments crées, etc.

ICMP Statistiques du protocole ICMP : 26 compteurs, 2 compteurs pour compter les messages reçus et émis, 4 compteurs pour compter le nombre total de messages icmp reçus, reçus par erreur ou non envoyé.

TCP

Statistiques et table de connexion tcp : rend compte des connexions TCP en cours et des paramètres de type nombre max de connexions simultanées permises, nombre d'ouverture active,...et l'état de chaque connexion (écoute, time wait,...).

UDP Statistiques UDP, 4 compteurs renseignent sur le nombre de datagramme UDP envoyés, reçus, en erreur, ...

EGP gère le protocole EGP, le nombre de paquets entrants, sortants, en erreur, la table des routeurs adjacents, des infos sur les routeurs...

Transmission ne contient que type Object Identifier ::={transmission number} qui permet d'identifier le type de media utilisé pour la transmission.

SNMP

Requis pour chaque entité mettant en oeuvre le protocole SNMP, contient le nombre de message SNMP entrants et sortants, le nombre des mauvaises versions reçues ou de nom de communauté invalide, la répartition du type de requêtes reçues et envoyées.

II.9. Le Langage ASN.1

ASN.1 est connu comme un standard international depuis 1984, destiné à l'origine pour

décrire les données échangées (courriers électroniques) dans les protocoles de

télécommunication. Il fournit une notation formelle qui décrit le format des messages. Il est



37

mis en œuvre dans un grand nombre d'applications (gestion de réseaux, messagerie, sécurité,

téléphonie, Internet, etc.). Il se localise au niveau de la couche présentation dans le modèle

OSI. La norme initiale est daté en 1988 (CCITT Recommendation X.208 : Spécification

de ASN1), une nouvelle version « ISO/CEI 8824-1 / UIT-T X.680 » a été émise en 1993

[69][70].

Ø Le module : Un module ASN.1 décrit une collection d’objets :

NOMDUMODULE DEFINITIONS ::= BEGIN Relations avec les autres modules (clauses IMPORT et EXPORTS) Définition des objets END

Ø Les objets définis avec ASN.1 peuvent être des types, des valeurs ou des macros.

- Le type : peut être un type simple comme INTEGER ou BOOLEAN, type construit

permettant de définir des listes (SEQUENCE) et des tableaux (SEQUENCE OF);

- Des valeurs, c-à-d des objets ayant un type précédemment défini ;

- Des macros, qui permettent d’étendre les définitions et définir de nouveaux types.

Ø Par convention, les types commencent par une majuscule, les valeurs par une minuscule

et les macros sont tout entières en majuscules. Les commentaires sont précédés de deux

tirets. Il effectue la correspondance entre les OID et les noms.

II.10. La structure d’information de gestion : SMI

Au complément de standard MIB qui définit les informations spécifiques d'administration de

réseaux et leur signification, un standard séparé appelé SMI spécifie l'ensemble des règles de

gestion des informations d'administration, utilisées pour définir et identifier les variables

MIB. La première version de SMI est décrite dans : RFC 1155 (STD 16), RFC 1212 (STD 16)

et RFC 1215 et la deuxième version : SMIv2 (RFC1902, RFC 2578 (STD58), RFC 2579

(STD58) et RFC 2580 (STD58))[62,64]. Toutefois, la MIB est définie par des scalaires et des

tableaux à deux dimensions uniquement, cela permet de rester dans un environnement assez

simple, ce qui contraste avec les structures de l'administration OSI. SMI permet de décrire les



38

objets de la MIB, avec leur syntaxe, leurs opérations autorisées et leur état de

standardisation. Pour permettre une standardisation de SNMP et de la MIB, il a fallu

implémenter dans SMI la possibilité de :

ü Fournir une méthode standard de définition des structures d'une MIB particulière.

ü Fournir une méthode standard de définition d'objets individuels, incluant la syntaxe et

les valeurs de chaque objet.

ü Fournir une méthode d'encodage standard des valeurs des objets.

Il pose des restrictions sur les types de variables autorisées dans la MIB, spécifie les règles

d'appellation de ces variables et crée les règles de définition des types de variables. Comme

exemple, il comprend des définitions de termes comme IpAddress (chaîne binaire de 4

octets). De plus, SMI décrit la façon dont la MIB référence les tables de valeurs (tables de

routage IP). 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. C’est un langage formel

qui élimine toute ambiguïté de forme ou de contenu au niveau des variables.

II.10.1. La première version de SMI

SNMPv1 SMI définie dans la RFC 1155[56] contient la spécification des types de données

ASN.1, des types de données spécifiques SMI et des tables MIB-SNMP. Trois types de

données ASN.1 sont requis : nom, syntaxe et encodage. Le nom est l'identificateur de l'objet,

la syntaxe définit le type de données de l'objet.

Ø Les types, les données spécifiques SMI sont :

− Les types de base : INTEGER, OCTET, STRING, OBJECT IDENTIFIER OID,

IpAddress, Counter, Gauge, Time Ticks et Opaque …etc.

− Les types conventionnels : DisplayString, DateAndTime, MacAddress, PhysSamp,

TimeInterval, TruthValue et VariablePointer.

− Les types construits :

Alias Seuil ::= INTEGER

Type limité à un domaine Seuil ::= INTEGER (1..3)

Type énuméré Seuil ::=INTEGER {bas (1), normal(2), haut(3)}



39

Une structure IntList ::= SEQUENCE { intV1 INTEGER,

intV2 INTEGER ,

intV3 INTEGER }

Un tableau Echantillon ::= OCTET STRINGF (SIZE (10))

II.10.2. SMI version 2

Le tableau II.5 montre que cette version définit des nouveaux types de données spécifiques :

chaînes de bits, adresses réseaux (non limitées à 32 bits), compteurs (32 et 64 bits). SNMPv2

SMI spécifie aussi des modules d'information, qui contiennent des groupes de définitions

liées: modules de MIB, statuts de conformité, statuts de capacité.

Les statuts de conformité (compliance statements) fournissent un mode systématique pour

décrire un groupe d'objets gérés qui doivent être implémentés en conformité avec un standard.

Les statuts de capacité (Capability statements) indiquent que le niveau de support qu'un

agent peut réclamer par rapport à un groupe MIB. Une station de gestion ajuste le langage qui

sert à définir un objet géré par une MIB [56].

Tableau.II.5. Ensemble des types de deux versions de SMI

Types SMIv1 SMIv2

Types simples

Integer Octet String Object Identifier -

Integer Octet String Object Identifier Integer32

Types d’applications

- Gauge Counter - TimeTicks IpAddress Opaque NetworkAddress

Unsigned32 Gauge32 Counter32 Counter64 TimeTicks IpAddress Opaque -

Pseudo types - BITS

II.11. Les primitives de protocole SNMP [57]

Le protocole SNMP regroupe les requêtes, les réponses et les messages d’alertes.



40

II.11.1. Les requêtes de SNMP

Quatre requêtes différentes sont définies :

• La requête GetRequest permet la recherche d'une variable sur un agent.

• La requête GetNextRequest permet la recherche de la variable suivante.

• La requête GetBulkRequest permet la recherche d'un ensemble de variables regroupées,

cela évite d’effectuer plusieurs requêtes Get en série, améliorant les performances

(implémenté dans SNMPv2) et minimisant le nombre d'échange à travers le réseau.

• La requête SetRequest permet de changer la valeur d'une variable sur un agent. Cela

permet d’effectuer des modifications sur le matériel.

II.11.2. Les réponses de SNMP

À la suite de requête, l'agent répond toujours par GetResponse. Toutefois si la variable

demandée n'est pas disponible, le GetResponse sera accompagné d'une erreur noSuchObject.

II.11.3. Les alertes/notifications

Lorsqu’un événement particulier survient chez l’agent, celui-ci est susceptible d’envoyer ce

que l’on appelle une « Trap » : celle-ci pourra alors la traiter et éventuellement agir en

conséquence. S’il s’agit par exemple de la coupure d’un lien réseau, cela permet à

l’administrateur réseau d’en être immédiatement informé. Ce mécanisme évite de devoir

régulièrement interroger l’équipement pour savoir son état. La figure II.5 donne la structure

générale d’un paquet de type Trap qui est constitué avec un ensemble des champs décrit ci-

dessous dans le tableau II.6.

Entreprise Agent Address

Generic trap type

Specific trap type

Time stamp

Variable Bindings

Figure.II.6 La structure d’une Trap



41

Tableau II.6. Description des champs qui constitue le message Trap

Champ Description Entreprise Identifie le type d'équipement qui a signalé la TRAP.

Agent address Adresse de l'agent ayant généré Trap.

Generic trap type Définit le type de problème survenu.

Specific trap code Identifie une Trap spécifique à l'Entreprise.

Timestamp Temps écoulé depuis le dernier envoi de TRAP.

Variable bindings Associe une valeur à chaque objet transmis.

Pour une trap générique, le type du trap peut avoir une valeur de 0 à 5. Si le type du trap

est de 6, le trap est spécifique d’une entreprise et il est défini dans la MIB privé.

Tableau II.7. Les types de Trap

Ø Inform, dans certains cas, il peut être intéressant pour un agent d’avoir une réponse à

une Trap qu’il a émise, afin d’obtenir une confirmation que celle-ci a bien été reçue:

c’est l’objectif de cette commande. Ceci est implémenté dans la 2ème version de

SNMP [52].

Ø SNMP-Report, le rapport de fonctionnement a été défini dans la version draft

snmpv2 mais jamais mis en oeuvre. Elle fait maintenant partie de la spécification et

la 3ème version de SNMP est destinée à permettre aux machines SNMP de

communiquer les uns avec les autres, à rendre compte des problèmes de traitement

des messages SNMP.

Type de Trap Description

coldStart(0) l'émetteur se réinitialise et sa configuration va peut être changer

warmStart(1) l'émetteur se réinitialise et sa configuration ne va pas changer

linkDown(2) il y a un disfonctionnement dans une des connections de l'agent

linkUp(3) une des connections de l'agent re-fonctionne

authentificationFailure(4) l'agent indique qu'il a reçu un message authentifié de manière incorrecte

egpNeighborLoss(5) signifie qu’un voisin EGP observé par l’entité protocolaire est marqué perdue et que l’observation de ce dernier est arrêtée.



42

II.12. Trame SNMP

Chaque trame possède une adresse source et une adresse destination qui permettent aux

protocoles de niveaux supérieurs comme SNMP de pouvoir adresser leurs requêtes. Le

protocole UDP peut utiliser un checksum optionnel qui couvre l'en-tête et les données de la

trame. En cas d'erreur, la trame UDP reçue est ignorée. 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 sont bien

arrivés à la destination, ce qui apporte également un important gage de fiabilité pour la

gestion de réseau.

II.12.1. PDU SNMPv1

La trame SNMPv1 est complètement encodée en ASN.1. Les requêtes et les réponses ont le

même format. La figure II.6 montre la structure générale d’un paquet SNMPv1.

version communauté PDU

Type PDU Request ID Error Status Error Index OID Value

Figure.II.7 Structure d’un message SNMPv1

• Le champ version indique la version de SNMP utilisé, on place la valeur « 0 » dans le

champ version pour SNMPv1, et la valeur 3 pour SNMPv3. Plusieurs versions de

SNMPv2 ont été proposées par des documents de travail, mais malheureusement,

aucune d'entre elles n'a jamais été adoptée comme standard. La version 3 est

actuellement en voie d'être adoptée mais la version 1 est encore la plus utilisée.

• La communauté SNMP est une relation entre un agent et les stations d'administration

qui définit l'authentification, le contrôle d'accès et les caractéristiques des proxies. La

communauté est décrite par une chaîne de caractères,. Par défaut, la communauté est «

PUBLIC».

• Le PDU (Packet Data Unit) : est constitué de :



43

Le PDU type décrit le type de requête, de réponse ou d'alerte. Le tableau. II.8 donne les

valeurs associées à ce champ.

Tableau .II.8. Type PDU de SNMP

Type de PDU Nom 0 Get-request 1 Get-Next-request 2 Set-request 3 Get-response 4 Trap

Le Request ID est numéro séquentiel de requête, permet à la station de gestion d'associer

des réponses à ses requêtes et de compter les requêtes envoyées.

L’Error Status est l'indicateur du type d'erreur, si aucune erreur ne s'est produite, ce

champ est mis à zéro. Les réponses négatives possibles sont décrites dans le tableau suivant.

Tableau.II.9. Type d’erreurs de SNMP

Réponses Description NoAccess Accès non permis WrongLengh Erreur de longueur WrongValue Valeur erronée WrongType Type erroné WrongEncoding Erreur d’encodage Nocreation Objet non créé ReadOnly Pas de permission d’écrire NoWritable Pas de permission d’écrire AutorisationError Erreur d’autorisation

Error Index : indique quelle est la variable associée à l’erreur.

OID : chaque variable définie dans une MIB est référencée de manière unique par son

OID, ce dernier indique l’emplacement de la variable dans un arbre comparable à celui

constitué par les fichiers et les répertoires d’un ordinateur.

II.12.2. PDU SNMPv2

La signification des champs des PDU est la même que pour leur homologue SNMPv1, à

l'exception des messages de type Get-bulk-request, tous les PDUs ont un format identique.



44

PDU Type

Request ID

Non repeaters

Max-repetitions

Object 1 Value 1

…… Object n Value n

Variable bindings

Figure.II.8 La structure de message Get-Bulk-Request

Les champs contenus dans le message get-bulk-request sont les suivants :

• PDU Type : spécifie le type de PDU transmis.

• Request ID : permet d'associer, à l'aide d'un numéro séquentiel, les requêtes du

manager avec les réponses de l'agent.

• Non Repeates : spécifie le nombre d'instances d'objet dans les champs variables qui ne

devraient être reçus qu'une seule fois depuis le début de la requête. Ce champ est

utilisé quand des instances sont des objets scalaires avec une seule variable.

• Max Repetitions : définit le nombre maximal de fois que les variables, autres que

celles spécifiées par le champ Non Repeaters, devraient être reçues.

• Variable: sert de champ de données. Ces variables sont l'association d'une instance

d'un objet particulier avec sa valeur courante.

Structure de “get-bulk-request”

BulkPDU ::= -- MUST be identical in SEQUENCE { -- structure to PDU request-id Integer32, non-repeaters INTEGER (0..max-bindings), max-repetitions INTEGER (0..max-bindings), variable-bindings -- values are ignored VarBindList }

Liste de “variable-binding”

VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind

Variable binding

VarBind ::= SEQUENCE { Name ObjectName, CHOICE { Value ObjectSyntax, unSpecified -- in retrieval requests



45

NULL, -- exceptions in responses noSuchObject[0] IMPLICIT NULL, noSuchInstance[1] IMPLICIT NULL, endOfMibView[2] IMPLICIT NULL } } END

II.12.3. La trame de SNMPv3

Le format de la trame SNMPv3 est très différent du format de SNMPv1. Elles sont toutefois

codées dans le même format sous ASN.1. Ceci assure la compatibilité des données entre les

différents types d’ordinateurs. Pour rendre plus facile la distinction entre les versions, le

numéro de la version SNMP est placée tout au début du paquet. La figure II.8 schématise le

format de cette trame.

version Header Data Security Scopted Data

Figure.II.9 Structure de message SNMPv3

Suivant le type de message envoyé (requête, réponse, ou message d'erreur), les

informations placées dans le paquet respectent des règles bien définies dans le standard.

Version SNMP: ce champ contient « 3 » pour un paquet de type SNMPv3.

Identificateur de message: ce champ est laissé à la discrétion du moteur SNMP. On

retrouve souvent des algorithmes, où le premier message de requête est envoyé avec un

nombre aléatoire et les suivants avec les incréments de 1. Les paquets qui sont émis en

réponse à une requête portent la même identification que le paquet de la requête.

Context Engine ID

Context Name

PDU Data MsgID Max Flags Security

model



46

• Taille maximale: le moteur choisit la taille maximale d'une réponse à une requête selon

ses capacités en mémoire tampon et ses limites à décoder de longs paquets. Quand on

envoie une réponse à une requête, on doit veiller à ne pas dépasser la taille maximale.

• Drapeaux : Trois bits sont utilisés pour indiquer :

- Si une réponse est attendue à la réception de ce paquet. (Reportable Flag)

- Si un modèle de cryptage a été utilisé (Privacy Flag)

- Si un modèle d'authentification a été utilisé (Authentification Flag)

• Le modèle de sécurité: ce module identifie le type de sécurité qui est utilisé pour

encrypter le reste du paquet. Cet identificateur doit identifier de façon unique chaque

module de sécurité. Actuellement, l'algorithme de cryptage DES (Data Encryption

Standard) et l'algorithme d'authentification HMAC-MD5-96 ont été choisis pour

SNMPv3. HMAC-SHA-96 est optionnel.

II.12.4. Les Tailles des messages SNMP [52]

La taille maximale d'un message SNMP est limitée soit au minimum de la taille maximale

d'un message dont la destination peut accepter, soit de la taille maximale d'un message dont la

source peut générer. Chaque instrument de transport de SNMPv2 indique une taille minimale

de message dont une implémentation de SNMPv2 doit avoir la capacité de le produire ou de

l’utiliser. Bien que les implémentations soient invitées à supporter plus grandes valeurs

possibles, une implémentation conforme ne doit jamais générer plus de messages que celui

autorisés par les entités de SNMPv2.

L'un des objectifs du GetBulkRequest-PDU est de réduire le nombre des échanges

nécessaires pour récupérer une grande quantité d'information de gestion. Ce type de PDU

permet au manager de demander des données aussi grandes que possible compte tenu des

contraintes sur les tailles des messages. Ces contraintes comprennent des limites sur la taille

des messages communiqués entre le manager et l’agent. Toutefois, il est possible que la taille

maximale des messages puisse être plus grande que le MTU. Dans cette situation, ces

messages sont soumis à la fragmentation qui est généralement considérée comme nuisible

puisqu’elle diminué la fiabilité du transfert des messages. Ainsi, une entité SNMPv2 qui



47

envoie un GetBulkRequest-PDU doit prendre soin de fixer ses paramètres en conséquence, de

manière à réduire le risque de fragmentation.

II.13. La sécurité du protocole SNMP

II.13.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 cryptage, en plus de l'absence d'un cadre

administratif pour l'autorisation et le contrôle d'accès, on utilise SNMP pour l'acquisition des

données de gestion. L'inconvénient majeur est qu'avec SNMPv1, qui est actuellement la seule

version vraiment stabilisée et reconnue par tous, ce mot de passe circule en clair sur le réseau,

ce qui rend dans ce cas SNMP plus que dangereux.

II.13.2. Les améliorations de SNMPv2

Le groupe de travail de l'IETF qui a oeuvré 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é. Tous les consensus du groupe de travail ont été

rassemblés (uniquement les améliorations qui ne portaient pas sur la sécurité), et le groupe de

travail de l'IETF a terminé ses travaux en publiant une version de SNMPv2 sans sécurité.

II.13.3. la sécurité avec SNMP v3

Cette nouvelle version du protocole SNMP existe depuis 2002, vise essentiellement à inclure

la sécurité des transactions : la vérification de l'identité de l'utilisateur lequel au nom un

message reçu prétend avoir été produit, la détection qu’il a reçu les messages qui contiennent

l'information de gestion, dont le temps de la génération n'était pas récente et l’assurance de la

protection du contenu de chaque message reçu contre la révélation.

La sécurité comprend l'identification des parties qui communiquent et l'assurance que la

conversation soit privée, même s’elle passe par un réseau public (vérification du non

modification de message reçu de SNMP pendant sa transmission). Elle est basée sur 2

concepts : USM (User-based Security Model) et VACM (View Access Control Model).



48

• USM, trois mécanismes sont utilisés : l'authentification, le cryptage et l'estampillage du

temps; chacun de ces mécanismes a pour but d'empêcher un type d'attaque.

• VACM 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.13.4. IPSec avec SNMPv2

Midkif & al [59] abordent le problème de gestion de sécurité de réseau en utilisant le

protocole SNMP ou ils ont comparé la sécurité des deux versions de SNMP (version 2 et 3) :

l'authentification incorporée et les caractéristiques privée de la version 3 et la sécurité avec

IPSec en utilisant SNMP version 2 (SNMPv2c). Ces résultats indiquent qu'une plateforme

basée sur IPSec offre des avantages fonctionnels et exécutifs.

II. 14. Conclusion

Nous avons décrit dans les sections précédentes la représentation du protocole SNMP. Ce

protocole permet de collecter diverses informations stockées dans la MIB. Les équipements

sont aussi capables de faire remonter des traps au collecteur SNMP via ce protocole. Même

s’il comporte plusieurs faiblesses, il se révèle utile de par sa simplicité en plus de par son

interopérabilité entre différentes plates-formes. Manque de sécurité dans les deux premières

versions de SNMP a été corrigé par la 3ème version de ce protocole. Celle-ci est devenue un

standard mais SNMPv1 reste encore le plus utilisé. Le protocole SNMP à beaucoup

d’avantages indéniables que nous avons pu mettre en avant. Le SNMP demeure donc le

protocole de gestion le plus utilisé puisqu’il est simple à implanter et configurer, malgré qu’il

entraîne un trafic plus élevé sur le réseau. L’étude de protocole SNMP nous a donné un

nouveau concept essentiel pour l’administration des réseaux et nous servira probablement à

approcher ce protocole à la gestion des réseaux particuliers comme les RCSF.


Chapitre III GESTION & SUPERVISION DES RCSFS

49

Chapitre III

GESTION & SUPERVISION DES RCSFs

- Etat de l’art

III.1. Introduction

L’administration de réseau est un processus de gestion, de surveillance et de contrôle de

fonctionnement de réseau. Les RCSFs présentent un défi qui met les techniques de gestion de

réseau traditionnel peu pratique. Dans les réseaux traditionnels, le but principal est de

minimiser le temps de réponse et de fournir des informations compréhensives. Par contre, les

réseaux de capteur s’intéressent au routage des données capturées avec une consommation

minimale d’énergie en réduisant le nombre des communications entre les nœuds. La

supervision et le contrôle des communications d’un nœud optimisent l’efficacité de réseau et

assurent le bon fonctionnement. D’autres protocoles exigent des contraintes matérielles

comme la possibilité de varier la puissance de transmission du nœud [129], une capacité de

traitement adéquate, une vaste mémoire, etc.

Boulis [83] exprime que la surveillance d’un RCSF est basée sur la gestion de trois

facteurs: le niveau d’énergie de chaque nœud capteur, la couverture de région et les

caractéristiques de connectivité entre les nœuds. Les valeurs cherchés doit être trouvé et

transmis avec une consommation d’énergie réduite.

Dans ce chapitre, nous présenterons les différentes familles de protocoles de gestion et de

contrôle destinés aux RCSFs en citant les différents critères et métriques de gestion.

III.2. Les fonctions de gestion

La gestion des réseaux et de ses services regroupe l’ensemble des activités qui permettent de

les mettre en oeuvre, maintenir et mettre à jour afin qu’ils répondent aux exigences spécifiées

des usagers. Des modèles dédiés permettent d’organiser les infrastructures de supervision de

manière structurée. La dynamique croissante des réseaux et la diversification des services ont



50

contribué à augmenter la complexité de cette tache. L’ISO a cerné les taches d’administration

du réseau en cinq domaines fonctionnels : anomalies, configuration, comptabilité,

performance, sécurité.

Ø La gestion des anomalies (Fault Management), l’objectif de l’administration de réseau

est d’avoir un réseau opérationnel sans rupture de service, ce qui définit une certaine QoS

offerte. On doit être en mesure de localiser le plus rapidement possible toute panne ou

défaillance. Pour cela, on surveille les alarmes émises par le réseau, localise un incident par

un diagnostic des alarmes et journalise les problèmes... Il y a beaucoup de dispositifs et de

logiciels hétérogènes, les entités qui composent le réseau, et certains risquent d'échouer. C'est

la responsabilité de localiser et de déterminer le temps et la cause d’une faute et la manière

de restaurer ces entités.

Ø La gestion des performances (Performance Management), il convient de contrôler à

tout moment le réseau pour voir s’il est en mesure d’écouler le trafic pour lequel il a été conçu

l’optimisation de la performance du système. Dans certains réseaux, le contrôle de congestion

se fait par le biais de contrôle d'admission, en modifiant itinéraires ou par le biais de

dispositifs de mise à niveau survient par les fonctions de gestion.

Ø La gestion de la sécurité (Security Management) consiste à gérer les contrôles d’accès

au réseau, la confidentialité des données qui y transitent, leur intégrité et leur authentification.

Plusieurs environnements nécessitent un protocole de sécurité. La sécurité doit être appliquée

au niveau de transmission/réception des messages et de traitement de ces contenus.

Ø La gestion de la comptabilité (Accounting Management), pour la plupart des réseaux,

les fonctions de gestion peuvent être utilisées pour recueillir et analyser le comportement de

l'interaction avec l'utilisateur, ce qui est très important dans la planification de l'évolution à

long terme de la capacité du réseau et de ses performances. De manière générale, la gestion du

réseau consiste en un ensemble des fonctions : surveillance de l’état du réseau, détection des

défauts et des anomalies du réseau, contrôle et configuration des composants du réseau,

maintenance de fonctionnement, et amélioration d’efficacité de réseau et des performances

des applications. Le Manager doit collecter et analyser les informations. Il applique un

contrôle fondé sur les informations collectées. L'information est souvent organisée dans une

MIB pour chaque élément.



51

Ø La gestion de la configuration (Configuration Management), il convient de gérer la

configuration matérielle et logicielle du réseau pour en optimisant l’utilisation des ressources.

Il est important que chaque équipement, chaque compteur soit parfaitement identifié de façon

unique à l’aide d’un nom ou d’un identificateur d’objet OID.

En fait, l’administration du réseau sera faite sans trop de problème mais les difficultés

s’amoncellent dès que la taille du réseau devient importante. S’ils permettent un déploiement

rapide et au faible coût, ces réseaux présentent en contre partie des contraintes liées à une

topologie dynamique, une bande passante réduite et surtout à une durée de vie restreinte due

aux limites énergétiques. Les fonctions de gestion peuvent être automatique, semi-

automatique où bien manuel [73], une liste des fonctions est définit pour la surveillance

d’environnement: définition de la zone de surveillance, supervision de la zone de couverture,

déploiement des nœuds, acquisition des données, configuration des paramètres opérationnels,

découverte de topologie, découverte de connectivité de réseau, agrégation des données,

contrôle de densité des nœuds, définition des priorités des actions, coopération,

synchronisation, génération de modèle d’énergie, interface graphique, localisation des nœuds,

contrôle d’état opérationnel de nœud, découvrir le niveau d’énergie des nœuds…etc.

Suivant l’application et les spécifications des nœuds capteurs, un sous ensemble des

fonctions est choisi avec la possibilité d’ajouter d’autre fonction. La gestion de réseau est

définit par l’ensemble des taches exécutées interactivement par le manager pour fixer les

problèmes liés au réseau et collecter les données distribuées qui décrivent l’état des nœuds

capteurs [83]. Les applications des réseaux de capteurs utilisent les données centrales où

chaque capteur peut router, collecter et traiter les données. De plus, les nœuds intermédiaires

peuvent réaliser des agrégations des données afin de réduire le nombre des communications.

La surveillance individuelle des nœuds est non demandée, il est suffisant de contrôler le

réseau par l’assurance de couverture de la zone et de connectivité des nœuds.

Donc, la tâche principale de surveillance des RCSF est de collecter des informations sur

les paramètres suivantes : le nombre des nœuds, la topologie de réseau, le rayon de

transmission, le rayon de couverture, l’état des nœuds (niveau de batterie, énergie de

communication), la largeur de bande passante, l’état de lien de communication …etc. La

position géographique peut être obtenue en utilisant des techniques de localisation ou le GPS.



52

III.3. Les métriques de RCSF [73,75]

On a eu la conviction que la meilleure façon pour bien assimiler est de commencer par les

métriques de gestion puisque chaque approche est associée à un sous ensemble de ses

métriques :

• La fiabilité : est l’aptitude d’un système à accomplir une fonction requise dans des

conditions données et cependant une durée donnée. Une mesure de fiabilité concerne le temps

entre deux défaillances consécutives (MTBF : Mean Time Between failure). Pour une période

de temps t, la MTBF est lié à la fiabilité par la relation suivante :

Fiabilité=1-t/MTBF ( 1 )

• La disponibilité : est l’aptitude d’un système à être en état d’accomplir une mission

dans des conditions données, à un instant donnée. Elle caractérise les risques de

dysfonctionnement d’un système et sa capacité à y faire face. La disponibilité regroupe les

notions de fiabilité et de maintenance. La disponibilité d’un système est donc étroitement liée

à la fiabilité, puisqu’elle est définie comme une probabilité pour laquelle le système

fonctionne correctement à un moment donnée. Elle est liée à la MTBF et à l’heure moyenne

de réparer MTTR. Disponibilité =MTBF / (MTBF+MTTR) ( 2 )

Une disponibilité élevée peut être obtenue par un long MTBF ou par une durée moyenne de

reprise MTTR courte.

• La surveillabilité est la probabilité pour qu’un système échoué récupère l’opération

correcte. L’utilité est étroitement liée au taux de réparation et à la durée moyenne de reprise

MTTR, Surveillabilité =1-exp(-t / MTTR) ( 3 )

• La maintenabilité est l’aptitude d’un système à être maintenu ou rétabli dans un mode

de fonctionnement normal, lui permette de fournir un service, lorsque la maintenance est

effectuée dans des conditions données et avec des moyens prescrits.

• La crédibilité précise le comportement en cas d’anomalies du système. Elle repose sur

la notion d’intégrité et de sécurité.

• L’intégrité représente l’assurance du système à accomplir correctement la mission pour

laquelle il a été conçu. Cette assurance implique bien entendu sa capacité à reconnaître le



53

mode de fonctionnement dans lequel se trouve le système et à signaler ce mode de

fonctionnement.

• La sécurité est l’aptitude du système à éviter de faire apparaître dans des conditions

données, des événements catastrophiques ou l’assurance du système à résister à des entrées

non autorisées ou incorrectes et à pouvoir les signaler.

• Ration de réception des paquets, c’est le rapport entre le nombre des paquets reçus par

l’observateur et le nombre des paquets envoyé par les nœuds.

• Latence, c’est l’intervalle de temps entre le temps de réception et de délivrance des

données.

• Les contraintes d’énergie, un nœud capteur est muni d’une ressource énergétique pour

alimenter ses composants. Cependant, en raison de sa taille réduite, la ressource énergétique

dont il dispose limité et généralement irremplaçable. L’énergie est la ressource la plus

précieuse dans un réseau de capteur, puisqu’elle influe directement sur la durée de vie des

nœuds capteurs et du réseau en entier.

• La duré de vie, le défi d’une conception d'un RCSFs est la maximisation de sa durée de

vie. Les recherches actuelles sont autour de minimisation de consommation d’énergie et des

nombreux protocoles sont être établis pour réaliser ce but [95]. Puisque l’énergie reste

toujours une ressource critique il doit être consommé d’une manière optimale.

• La connectivité est un facteur déterminant dans les réseaux ad hoc et de capteurs. Elle

permet d’assurer que tout nœud destinataire est joignable par tout nœud source du réseau. En

particulier, dans les réseaux de capteurs, il devrait exister au moins un chemin entre tout

capteur et la station de base pour garantir l’acheminement de l’information en tout moment et

que tous les nœuds soit joignable à partir de la station de base.

• La couverture : tout algorithme conçu pour les réseaux de capteurs devrait assurer que

l’occurrence d’un tel événement dans la zone de déploiement des capteurs pourrait être

détectée par au moins un capteur.

III.4. L’architecture de RCSF

Des nouveaux modèles et architectures sont requis pour pouvoir intégrer les RCSFs dans une

démarche de gestion. Il est possible de classifier les approches de gestion de RCSF suivant



54

son architecture: centralisée, distribuée ou bien hiérarchique. Le manager central peut avoir

des connaissances globales sur le réseau. Le serveur central est un point de concentration des

données et des pannes potentielles. La topologie dynamique conduit à réorganiser le plan de

gestion, typiquement sous forme de clusters et introduire des mécanismes de délégation pour

répartir les activités de gestion. La gestion distribuée a un coût minimal de communication

par rapport à la gestion centralisée et permet une sûreté et une gestion efficace d’énergie.

Plusieurs travaux de recherches sont trouvés pour les RCSFs hiérarchiques (voir le tableau

III.1). Dans le réseau hiérarchique, les nœuds capteurs sont organisés en clusters [93]. Chaque

cluster-head est responsable à l’envoie des données au sink et son agent applique une

fonction d’agrégation aux données afin de minimiser la taille des paquets transmis et la

consommation d’énergie. En plus, les données envoyés doivent vérifier certain condition

définit par le manager. Donc le filtrage des données est largement utilisé dans des différentes

applications puisque elle réduit le nombre des messages envoyés.

L’absence d’infrastructure fixe favorise les échanges directs de nœud à nœud.

L’hétérogénéité des équipements pousse à établir un socle commun des protocoles et des

services en s’appuyant sur des approches à base d’intergiciel « middleware ». Ces

caractéristiques ont également un impact direct sur les applications de la gestion.

III.5. Les modèles de délivrance des données dans les réseaux de capteurs

Dans les RCSF, les approches du collection des informations peuvent être classifiées selon

différents modèles: en fonction du temps « Surveillance périodique », des évènements

« réaction à l’occurrence d’un évènement particulier », des requêtes « réponse à une demande

d’une station de base » ou de manière hybride (combinaisons des approches précédentes)[83].

III.5. 1. Le modèle continue

Avec la délivrance continue, chaque nœud capteur envoie périodiquement les données au

nœud « sink » suivant un volume de trafic prédéterminé.

III.5.2. Le modèle driven event

La génération et la transmission des paquets DATA est commandé par l’apparition d’un

événement, Evénementiel est dit aussi réactif si le collecte et l’envoie des données est lié à la



55

vérification de quelques conditions définit par l’application. Il permet de diminuer le nombre

des messages communiqués. La plupart des applications driven event [75] sont des

applications intolérantes aux délais (temps réel), critiques, interactives et de non bout en bout.

La réussite de ces applications, pour ce modèle, repose essentiellement sur la détection de

l’événement et la rapidité des prises des réactions nécessaires pour assurer l’aspect temps réel

des applications. L’inconvénient majeur de ce modèle est la redondance des données. En fait,

les noeuds excités par le même événement envoient la même information au sink. Pour cela,

un protocole de routage basé sur la négociation des données est recommandé.

III.5. 3. Le modèle query driven

Le modèle query driven est semblable au modèle driven event sauf que la collecte des

informations sur l’état de l’environnement est initiée par des interrogations envoyées par le

sink, alors que, pour le modèle précédant, elle est déclenchée suite à un événement détecté.

La plupart des applications query driven sont interactives, critiques, de non bout en bout et

leur tolérance aux délais dépend de l’urgence de l’interrogation. Notons que ce modèle peut

être utilisé pour contrôler et reconfigurer les noeuds. Par exemple, le sink peut envoyer des

commandes au lieu des interrogations pour modifier le programme d’un noeud capteur,

modifier son taux de trafic ou son rôle.

III.5. 4. Le modèle Hybride

Quelques applications maintiennent le modèle hybride en combinant les trois modèles de

délivrance des données. Le protocole de routage est influencé par le modèle de délivrance

utilisé, spécialement pour la minimisation de consommation d’énergie. Pour les applications

de surveillance d’habitat où les données sont transmis périodiquement au sink, un protocole

de routage hiérarchique est plus efficace [79]. Ceci est dû au fait que plusieurs applications

génèrent des données redondantes qui peuvent être agrégé, ainsi la réduction de trafic et

l’économie de l’énergie. Pour l’envoie périodique, le réseau est dit continu où il est possible

d’estimer l’état de fonctionnement du réseau.

III.6. Classification des travaux existants pour la gestion d’un RCSF

Cette section présente les différentes approches et travaux réalisés pour la gestion et la

supervision des RCSFs. Dans la référence [75], on trouve la description d’un certain nombre



56

des recherches récentes. Les systèmes de la gestion sont classifiés en termes de ces

fonctionnalités : Des systèmes proches aux systèmes traductionnels de gestion, des protocoles

de routage, des systèmes de tolérance aux fautes, la gestion des ressources énergétiques, les

fonctions de gestion des trafics et à base des requêtes.

Tableau III.1. Les systèmes de gestion de réseau

Système de gestion de réseau

Réactivité

Arch

Energie

Détection

PA

K-conn

K-couv

reconf

Mtce

WinMS[71] DSN RM[101] Mobile agent based policy management[103] Intelligent agent based

power management[130] Siphon[30] BOSS[72] Sympathy[89]

Active Active Active Active Active Active Active

H H H D D C C

+ + +

+

+ +

+

SenOS [82] Agilla[74] Node-energy level management[87]

Réactive Réactive Réactive

H D D

+ + +

Two-phase monitoring system[112]

Détection des fautes

D + + +

TopDisc[98] AppSleep[85] STREAM[99] Sectoral Sweeper[113] TinyDB[97] MOTE-VIEW[84] SNMS[132] MANNA[73] WSNMP[133]

Passive Passive Passive Passive Passive Passive Passive N/A

H H H D C C C N/A H

+ + + +

+ +

+

+

+

Le tableau III.1 classifie des travaux constatées pour la gestion des réseaux de capteur

suivant plusieurs critères: la réactivité, l’architecture (Arch : Architecture, H : Hiérarchique,

D : Distribué, C : Centralisé), détection de point d’articulation (Détection PA), k-

connectivité (k-conn), k-couverture (k-couv), la gestion d’énergie, la reconfiguration



57

dynamique (Reconf) et la maintenance (Mtce). Les systèmes BOSS [72] et MANNA [73]

sont basés sur des systèmes de gestion de réseau traductionnels comme le protocole SNMP. Il

existe aussi des outils pour la représentation graphique des états des noeuds à l’utilisateur

comme MOTE-VIEW [84], NetTopo [88] et TINY-DB[97].

III.6. 1. La détection des fautes

WinMS[71], TP[76], Sympathy[89] et MANNA[73] se focalisent sur la détection des

anomalies. Dans TP [76], chaque nœud surveille son fonctionnement et les états de ces

voisins. Sympathy [89] fournit une technique de debugging pour détecter et localiser les

fautes qui peuvent se produire entre les noeuds. MANNA [73] implémente une détection

centralisée basée sur l’analyse des données collectées par contre WinMS[71] exécute un

programme périodique quand les nœuds écoutent à ces activités environnementales avec

l’auto-configuration, en cas d’un événement de défaillance sans connaissance préalable de

topologie complet. WinMS fournit un schéma de détection des fautes, analyse l’état de réseau,

détecte et prédit aux défaillances potentielles. D’autres recherches proposent des nouveaux

protocoles de routages comme TopDisc[98], STREAM[99].

Song et al [72] propose BOSS (Bridge Of the SensorS), une architecture de gestion basée sur

UPnP qui permet à des périphériques de se connecter aisément et de simplifier

l'implémentation des différents taches (le partage des fichiers, des communications…etc).

Néanmoins, UPnP s’exécutent sur des machines avec une grande puissance de calcul et une

mémoire suffisante. Donc, les nœuds capteurs sont incapables d’exécuter ce protocole.

Ø Ce système consiste trois composants : le point de contrôle UPnP, BOSS et les nœuds

capteur. L’implémentation de l’agent UPnP au niveau de la station de base fournit un

médiateur entre le réseau de capteurs et le réseau UPnP.

Ø BOSS est un médiateur entre les nœuds capteurs et le point de contrôle d'UPnP. Il

transmit les messages entre le réseau de capteur et le point de contrôle. Il interprète les

messages transférés et rassemble les informations de gestion de réseau. Les services

fournis par BOSS incluent certaines informations de base comme la description des

nœuds, la topologie de réseau, la localisation, la synchronisation, la gestion d’énergie.



58

Ø La gestion d’énergie : permet à l’utilisateur de gérer la consommation d’énergie avec le

contrôle de niveau de batterie et le changement de mode de fonctionnement.

Ø Les différentes applications de réseau peuvent être gérées avec des points de contrôle

UPnP multiples mais l’observation de l’utilisateur doit être toujours obligatoire.

Ruiz & al [73] proposent une architecture de gestion, nommé MANNA, sur trois dimensions:

le fonctionnement, le niveau de gestion et les fonctionnalités des RCSF qui prennent en

compte les caractéristiques de ce type de réseau. 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 de type de RCSF et de l’approche de

gestion. Son architecture physique 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.

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.

Figure.III.1 L’ensemble des fonctions de gestion définies dans MANNA [73]



59

L’observateur envoie des requêtes au RCSF pour récolter les données. Les modèles

proposés dirigent les activités de gestion. Avant de définir ces modèles de réseau, il est

indispensable de décrire l’ensemble des services et des fonctions de gestion. Un service

consiste à trouver l’ensemble des activités ou des fonctions qui doivent être exécuté 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 RCSF où on peut avoir une vision abstraite de système.

Figure.III.2 Les relations, les fonctions et les modèles de système MANNA [73].

Contrairement aux informations statiques, les informations dynamiques sont obtenues

fréquemment. Étant donné que l’acquisition de ces données consomme l’énergie, il faut

déterminer le moment adéquat et l’intervalle optimal pour la mise à jour de ces informations.

L’architecture de MANNA ne donne aucune spécification de la pile protocolaire. L’exécution

des services de gestion dépend de l’information obtenue dynamiquement (modèle de

topologie, modèle d’énergie, modèle de couverture et modèle de vérification….). Cependant,

ils proposent l’utilisation d’agent pour distribuer les fonctions de gestion où chaque agent

collecte et transmis l’information à la station de base.

Un schéma de détection des pannes est proposé pour la surveillance de l’environnement

comme un ensemble des services et des fonctions de gestion automatique exécutés par le

manager et les agents. MNMP [93] implémente des agents de gestion sur les cluster-heads où

chaque cluster-head est considéré comme un manager dans un cluster. La station de base est

en communication avec l’observateur par l’envoie des traps : Location_Trap, Energy_Trap en

définissant six modèles d’information: le modèle de topologie, le modèle d’énergie résiduel,

Service Y Service X

Function 3

WSN model

Function 2 Function 1 Function 4

WSN model

Uses

Uses Uses Uses

Uses



60

le modèle de couverture, le modèle de communication, le modèle de coût et le modèle de

vérification. Le Manager envoi un requête GET et utilise GET-RESPONSE pour construire le

modèle de vérification. Si le manager ne reçoit aucune réponse, le manager consulte le

modèle d’énergie résiduel. Si le manager détecte une panne, il doit être notifié à l'observateur.

Ils ont utilisé SNMP entre la station de base et le cluster-head mais entre les nœuds capteurs

et le cluster-head : le protocole MNMP. L’expérimentation de ce protocole prouve

l’augmentation de nombre des messages transmis et la consommation énergétique. Donc, il

peut être utilisé dans certaines applications critiques où la détection des pannes est

indispensable.

III.6. 2. Les outils de visualisation

MOTE-VIEW [84] donne un support de visualisation des analyses de nombre important de

données générées dans une architecture centrale. Cette architecture consiste quatre couches :

la couche d’abstraction d’accès aux données, la couche d’abstraction de mode, la couche

d’abstraction de conversion et la couche d’abstraction de visualisation. La dernière couche

permet à l’utilisateur de chercher à travers l’historique des données temporel. Cette approche

de supervision passive ne doit pas permettre l’auto-configuration des réseaux en cas d’une

défaillance d’un nœud. L’utilisateur final doit gérer manuellement le réseau et interprète la

représentation des données collectées.

III.6. 3. Les fonctions de gestion de trafic

Cette approche est validée dans plusieurs systèmes tel que Siphon [100], DSN-RM[101],

WinMS[71]. La congestion peut être éliminée par la réduction de vitesse de transmission et le

nombre des paquets transmis dans le réseau. WinMS configure les nœuds pour reporter les

données rapidement suivant l’importance des données par contre Siphan[100] utilise des

nœuds multi-radio pour agir comme des stations de base virtuelles.

• Protocole sNMP [102] s’établit en deux taches : la définition des modèles de

représentation d’état courant des nœuds et d’ensemble des algorithmes et des outils de

recherche d’état de réseau. L’usage des patterns pour la description des attributs de réseau.

• Sympathy [89] est un outil de détection et de localisation des pannes basé sur la

collection périodique des métriques; la transmission périodique des tables des voisins est



61

proposé dans MinRoute[90]. Ces métriques sont classés en trois catégories : connectivité

(table de routage, liste de voisinage), flux transmis (nombre des paquets transmis, dernier

Timestamp) et nœud (nombre des paquets bien reçus, nombre des paquets reçus avec

erreurs). Chaque nœud envoie périodiquement des données au sink. Si le sink n’a pas reçu des

données d’un certain nœud après une durée donnée, il prédit qu’il y a un problème au niveau

de ce noeud où dans ces liens de connectivité. La taille des données transmises doivent être

réduite. La transmission des données volumineuses comme les chemins de routage nécessite

la fragmentation des données. Ce système peut avoir la congestion, la dégradation de qualité

de lien radio, le nombre des erreurs élevé, le gaspillage d’énergie des nœuds…etc. Ce

système est tolérant aux pannes et donne des résultats acceptables mais il n’implémente pas

un algorithme qui minimise la consommation d’énergie.

• TinyDB est un système de traitement des requêtes envoyées aux nœuds capteurs pour

l’extraction d’information de la topologie, la couverture de la zone géographique, la

connectivité, le niveau d’énergie et le dysfonctionnement des quelques nœuds.

III.6. 4. Les systèmes de gestion d’énergie

La gestion d’énergie est visée pour minimiser la consommation totale d’énergie vu que les

batteries sont en générale limitée, non remplaçable, non rechargeable. Plusieurs travaux

gèrent la consommation d’énergie des noeuds capteurs par la mise en œuvre des agents

(Agent-Based Power Management [130], SenOS[82], AppSleep[85] et Node-Energy Level

Management[87]). Ils utilisent un nœud commun pour l’exécution de la gestion d’énergie.

Plusieurs travaux représentent le contrôle de consommation d’énergie: PEAS [81], SenOS

[82], AppSleep [85], Node Energy Level Management [87]. L'approche de [130] utilise un

agent mobile pour gérer un sous réseau et exécute un traitement local de gestion d’énergie.

L’implémentation des agents nécessite des nœuds spéciaux pour couvre tout les nœuds de

réseaux. Puisque la reconfiguration est manuelle, le manager doit avoir une expertise sur le

nombre optimal des agents de même que l’emplacement pour des applications particulières.

La réduction des agents déployés augmente le temps requis pour visiter les nœuds dans le

réseau. Autre utilise un nœud capteur commun qui exécute la procédure de gestion d’énergie.

SenOS [82], AppSleep [85] mit les nœuds inutiles en mode Sleep… LEACH [47] favorise

l’agrégation des données et la suppression des données redondantes.



62

• SenOS[82] assure que les nœuds redondants dans un cluster sont mis en mode sleep

dans le but de prolonger la duré de vie de cluster. Dans chaque cluster, seulement un nœud

capteur est laissé actif, les autres nœuds sont mis en mode Sleep. La gestion dynamique

d’énergie détermine l’état en se basant sur l’évènement d’observation.

• AppSleep [85] est un protocole de gestion d’énergie qui étend la période d’inactivité

des nœuds basé sur les informations d’ordonnancement des communications. Des requêtes

sont souvent envoyées après l’analyse des données collectées. Il implémente une fonction de

gestion d’énergie sur la couche application qui doit permettre la gestion d’ordonnancement

basé sur le paquet courant. Quand une route active est changée, le protocole de routage doit

être capable de rétablir un nouveau chemin.

L’approche de gestion de consommation d’énergie pour un nœud capteur [87] dont

l’acceptation ou le refus d’une tâche est liée à trois attributs : énergie, re-compensation et la

politique d’administration. Le stockage des données et le coût de calcul peuvent être élevé.

• Algorithme PEAS [81] est un autre protocole pour la conservation d’énergie qui permet

de prolonger la duré de vie des nœuds capteurs. Cet algorithme consiste deux parties : Probing

environnement qui peut résoudre les problèmes de panne des nœuds, et la mise en veille

adaptative. Premièrement tous les nœuds sont mis en mode veille pour une durée aléatoire.

Quand un capteur mise en veille, il envoie un probe message. Chaque nœud actif dedans le

rayon de probing doit envoyer une réponse. Un nœud en mode Sleep commence à travailler

sans interruption, seulement s’il n’étendre aucun message de réponse sinon il éteint son radio

pour un temps aléatoire. « Adaptative sleeping » permet de conserver le nombre de

« wakeup » mais les nœuds capteur qui travaillent tout le temps, consomment plus d’énergie.

Dans ce protocole, on calcule l’énergie des nœuds au moment de sélection wakeup/sleep.

Avec la possibilité de consommation totale d’énergie, couverture non préservée et délivrance

des données non assurées, le réseau s’arrête.

• BESM est proposé par Wei Liang.al [80] à la base de PEAS |81]. BESM est un

protocole de gestion qui assure l’équilibre de consommation d’énergie en mettant les nœuds

qu’ils ont moins d’énergie en mode sleep, surtout les nœuds qui sont déployé dans les

frontières de la région. Cela assigne la consommation d’énergie équilibrée entre tous les

nœuds capteurs et augmente la durée de vie de réseau en assurant la couverture. Cet

algorithme minimise la consommation d’énergie et le taux de couverture en mettant au



63

maximum possible les noeuds inutiles et qui ont moins d’énergie en mode Sleep à l’aide

d’une stratégie de négociation basée sur une méthode de conservation d’énergie dans les

frontières. La génération aléatoire de période de mise en sommeil des nœuds est modélisée

par une proportion inverse de nombre de ces nœuds adjacents. Les nœuds qui seront dans les

frontières peuvent être désactivés pour des durées plus longues. Chaque nœud estime le

nombre de ces voisins. La figure suivante illustre les transactions possibles entre les cinq

états : initial, Sleep, test, active ou mort.

1. Etat initiale : à cet instant chaque nœud doit installer d’infrastructure, la

synchronisation et la localisation.

2. Sleeping : le nœud attend pour un temps aléatoire.

3. Etat d’écoute : le nœud envoie un message de probing.

4. Etat active : le nœud peut capturer, calculer et communiquer.

5. Etat mort : consommation total d’énergie de nœuds ou bien un défaut aura lieu.

Figure.III.3 Le diagramme d’états d’un capteur en utilisant le protocole BESM [80]

III.5. L’utilisation de protocole SNMP pour la gestion des RCSF

Le protocole SNMP est un protocole d'administration de réseaux qui repose sur le modèle

TCP/IP et sur le concept Client / Serveur. Il gère les réseaux et ses applications en permettant

la supervision et le diagnostique les problèmes à distance [77,78]. Il regroupe un ensemble de

standards incluant, une spécification de la structure de la base de données et un ensemble



64

d'objets. Il peut être utilisable sur des plates-formes hétérogènes. Mais puisque ce protocole

est extensible, plusieurs chercheurs ont pensé d’adapter ce protocole [73, 78, 91] pour gérer et

collecter les états des nœuds capteurs à distance et donne des statistiques d’usage du réseau.

1. Le plus important de protocole SNMP est la capacité de décrire un grand nombre de

composant de façon standard,

2. Communication simple où l’adresse de l’agent et le type d’information seront nécessaire

pour trouver une information,

3. Compatibilité de communication et flexibilité de transmission des informations,

4. Efficacité de stockage et de recherche des informations,

5. Accéder facilement aux informations sauvegardées,

6. SNMP est vu comme un standard pour la gestion des réseaux depuis longtemps,

7. Outil graphique pour cartographier le réseau,

8. Découvre automatiquement les équipements qui incluent dans le réseau,

9. Mesurer les performances d'une application,

10. Signaler les dysfonctionnements des nœuds,

11. Gérer une masse considérable des données qui sont souvent interfacées à une base de

données permettant une recherche élaborée,

12. permettre une gestion à distance des différentes machines,

13. indépendant de l'architecture des machines administrées,

14. La transmission des messages en mode asynchrone se fait via le biais le protocole UDP.

• Délivrance et stockage dans des RCSFs basé sur le protocole SNMP[78]

Le contexte de l’ensemble des outils et l’espace sémantique prouvent la séparation entre

les capteurs et l’application de gestion. Malgré la simplicité d’application, mais il a des

problèmes de communication, compatibilité et flexibilité. Dans [78], ils ont proposé une

structure de stockage et de délivrance d’information capturée en utilisant le protocole SNMP.

SNMP Manager ----------------Administration

MIB ---------------- Sauvegarde d’information

La communication ---------------2.4 GHZ IEEE802.15.4



65

Figure.III.4 Un système de gestion en utilisant SNMP[78]

Ils ont prouvé la possibilité de délivrance et de sauvegarde des informations à travers ce

protocole. On voit clairement l’indépendance entre le nœud capteur et l’application. La

manipulation de SNMP peut résoudre des différents problèmes liées aux technologies des

ordinateurs, découverte l’incompatibilité des ressources, un seul type de communication,

flexibilité.

• L'utilisation de Proxy-SNMP pour les RCSF

Dans [91], les auteurs proposent la surveillance de la santé des patients mobiles et

éloignés à l'aide des capteurs de type Micaz connectés à l’Internet. L’implémentation de

ProxySNMP assure la disponibilité des données, réduit la consommation d’énergie et la

puissance de calcule et améliore l’interface graphique. La lecture de fichier « logfile »

nécessite l’intégration de SNMP4J [92]. L’architecture de se système comporte deux type de

capteur : un pour les données sanitaires autre pour l’environnement (mesure de température).

Les capteurs sont connectés à un PC à travers un gateway.

La ligne suivante indique une forme standard des données dans le fichier « logfile ».

<Date stamp> < time stamp > : < patient ID number, type of sensor=data from the sensor>

Agent SNMP

Serveur Manager SNMP

Trap

Requete

reponse Capteurs



66

Figure.III.5 Architecture d’un RCSF pour la surveillance de la santé[91].

III.6. Conclusion

Dans ce chapitre, nous avons classifiés les différentes approches et travaux existants dans le

domaine de supervision et de gestion des RCSFs. La gestion d’un RCSF nécessite l'exécution

d'un ensemble des tâches de contrôle en se basant sur la collecte de différentes informations

comme le contrôle de fréquence, d’énergie et de trafic. Pour cela, certaines procédures exigent

des informations sur le réseau. Le chapitre suivant est consacré à notre contribution, nous

décrivons le protocole proposé en détail.


Chapitre IV Conception d’un Protocole de gestion WSN-SNMP

67

Chapitre IV

CONCEPTION D’UN PROTOCOLE DE GESTION

CENTRALISE - WSNSNMP -

IV.1. Introduction

Dans ce chapitre, nous abordons la problématique de supervision de l’ensemble des capteurs

ainsi que l’élaboration d’un nouveau protocole de gestion, sous la base de standard SNMP et

les aspects de la théorie des graphes dont l'objectif principal de ce travail est de minimiser la

consommation d’énergie afin de prolonger la durée de vie de réseau en entier. Les nœuds

capteurs recueillent et stockent ses données dans une base de données de gestion nommée

MIB pour faciliter leur accès via le protocole proposé WSN-SNMP. Les échanges

d’informations de gestion s’effectuent par le biais des messages. La reconfiguration de réseau

est effectuée en respectant des contraintes liées à la topologie du RCSF, à savoir la

connectivité et la couverture.

IV.2. Modélisation d’un réseau de capteur

Nous modélisons le RCSF par un graphe non orienté G / G = (V, E), dont V est l’ensemble

des sommets représentant les nœuds capteurs et VVE ×⊂ , l’ensemble des arêtes donnant les

communications directes entre les nœuds de réseau. Avant de détailler notre approche, nous

considérons quelques suppositions sur lequel notre travail a était réalisé:

• Un RCSF est composé d’un ensemble des nœuds capteurs et possède un seul Sink.

• La zone de déploiement est représentée sous la forme d’un espace à deux

dimensions de largeur L.

• Chaque capteur est paramétré par l’identificateur, la position (x, y), le niveau de son

batterie, l’état d’activité, l’énergie de transmission, l’énergie de réception.

• Les nœuds capteurs sont considérés homogènes, c-à-d que tous les nœuds capteurs

ayant les mêmes capacités, possèdent un rayon de communication notée R, ainsi

qu’un rayon de couverture r.



68

• Pour minimiser le cout de déploiement, seulement quelques nœuds capteurs sont

dotés d’un système supplémentaire celui de la mobilité.

• L'implémentation d’une base de données MIB associée à chaque nœud capteur,

• La couverture de quelques points est prise en considération et non pas toute la zone.

• Au départ, le réseau déployé doit être connexe et couvert.

• Il existe une paire ordonnée E v(u, ∈) , si le noeud u est physiquement capable de

transmettre des messages à v. La Communication entre les capteurs est symétrique,

c-à-d l’un est localisé dans la portée radio de l’autre. Autrement dit, de tout noeud

du réseau, il doit exister un chemin vers le Sink. R} v)d(u, |V v){(u,E 2 ≤∈= ; Où

d(u,v) est la distance physique qui sépare les nœuds u(x1,y1) et v(x2,y2). La distance

euclidienne « d » est donnée par la formule suivante:

2

122

12 )()( yyxxd −+−= (1)

• On suppose aussi que chaque capteur peut déterminer sa position et ces voisins.

L’ensemble de voisins N(u) d’un noeud « u » est défini par:

}∈ )(≠∈{ = ) E vu, u, v| V vN(u (2).

IV.3. La présentation de notre contribution

La technologie particulière des capteurs implique des contraintes de fonctionnement non

négligeable tel que la durée de vie limitée en conséquence de leurs tailles limitées, de la

multiplicité des composants et de leurs performances. Les capteurs sont éparpillés dans une

zone de largeur L. Comme celle-ci est étendue et potentiellement difficile en accès, ils doivent

s’auto-organiser pour envoyer les messages jusqu’au Sink. Si on ne peut pas remplacer les

nœuds qui n’ont plus d’énergie, il faut donc qu’ils vivent le plus longtemps possibles. Chaque

nœud de réseau peut consommer totalement son énergie ou tomber en panne, entraînant ainsi

un isolement de quelques parties du réseau, l’intégration des mécanismes de supervision aux

services des RCSF est donc indispensable à leur utilisation.

Donc, notre travail est destiné à la gestion et la supervision d’un RCSF à l’aide d’un

nouveau protocole de gestion à économie d’énergie. Le souci principal est de prolonger la vie

du réseau en optimisant les dépenses de chaque nœud capteur. Comme le protocole SNMP est



69

un protocole permettant la gestion de la configuration, des performances, des fautes, de la

sécurité et des coûts, il peut donc aider l'administrateur en facilitant son travail d'audit et

d'analyse. De plus il permet une gestion à distance des équipements réseaux.

En se basant sur ce standard, on propose le protocole WSN-SNMP qui manipule un

ensemble des requêtes, des réponses et d'un nombre limité des notifications. Les

fonctionnalités de protocole développé peuvent être résumées comme suit :

• Surveillance des nœuds avec l'optimisation de nombre de messages communiqué,

• Configuration/Reconfiguration de l’ensemble des nœuds du réseau,

• Prédiction à la déconnection d’un sous ensemble des capteurs et la répartition de

réseau en plusieurs parties,

• Collection dynamique des données,

• Assurance de couverture de la totalité des points cibles en construisant le graphe

biparti pour détecter les nœuds redondants,

• Utilisation de la redondance matériel afin d’assurer la surveillance.

Nous développons dans les sections qui suivent notre solution proposée pour la gestion de

RCSF, à savoir la structure de la MIB, les différentes primitives de protocole WSN-SNMP, et

un ensemble d’algorithmes.

IV.4. Les fonctionnalités de protocole WSN-SNMP

Au niveau du Sink

• Des requêtes sont envoyées aux noeuds périodiquement ou après des analyses des

informations obtenues selon les besoins de surveillance, où il demande les états des

nœuds ainsi que les dernières valeurs mesurées pour plusieurs occurrences.

L’intervalle de test peut être varié.

• Le sink peut activer ou désactiver des nœuds par l’envoie de message de type Set

en mettant les nœuds redondants en mode Sleep et laisser les autres en mode active

à condition d’assurer la connectivité entre les nœuds et la couverture des points

cibles en évitant qu’un nœud consomme plus que les autres. Les décisions de

changement d’état peuvent être prises par l’entité centrale avec une connaissance

globale du réseau, ou par les nœuds eux-mêmes qui se basent alors uniquement sur

des informations de voisinage.



70

• L’implémentation d’un algorithme de prédiction des états des nœuds en utilisant les

informations collectées.

• Le sink peut avoir une vue globale de réseau représentant les états des noeuds.

Suivant les positions des nœuds, le Sink doit déterminer le graphe de connectivité,

c-à-d les nœuds intermédiaires, et l’ensemble des nœuds qui donne la couverture

maximale. La supervision permet de connaître à tout moment la disponibilité et la

performance du réseau.

• Mobilisé quelques nœuds pour augmenter le degré de connectivité.

Au niveau des nœuds

• La sauvegarde des informations liées au capteur dans sa MIB.

• L’envoie d’un Trap ou d’une notification dans des cas bien précis: le capteur doit

reporter au sink son état lorsqu’il détecte un évènement spécifique.

• Les nœuds capteurs aussi reportent les mesures périodiquement ou à la demande.

Dans le premier cas, les mesures sont prises chaque période suivant le type

d’application.

• Réception des requêtes envoyées par la station de base,

• Envoie des réponses associes aux requêtes de types GET,

• Etiqueter les paquets envoyés, chaque paquet est identifié par numéro,

• Et ceci est valable si les noeuds capteurs peuvent déplacer.

Pour bien comprendre le fonctionnement et le comportement du protocole proposé, on

montre ici les aspects de la théorie des graphes utilisés et les différents algorithmes de base

qui implémentent le principe de notre approche.

IV.4.1. Détection des points d'articulation [106]

Définition -Etant donné un graphe connexe non-orienté G = (V, E), un point d’articulation est

un sommet dont la suppression de se sommet augmente le nombre de composantes connexes

de graphe G. Un isthme de G est une arête « e » de E dont le retrait augmente le nombre de

composantes connexes de G.



71

Graphe 2- connexe - le graphe G est dit 2-connexe si et seulement s’il est connexe, d’ordre

n ≥ 3 et, n’admet pas de points d’articulation. Si G représente un réseau de communication, le

fait que G soit non séparable nous assure que le réseau fonctionnera malgré l’apparition d’une

panne de quelque nœud.

L’algorithme de détection des points d’articulation

Dans notre cas, on peut se limiter à la 2-connectivité, puisque il est suffisant d‘avoir aux

moins deux chemins entre la source et la destination pour garantir une connectivité.

Implémentation d’algorithme de détection des points d’articulation

private static int doFindArticulation (int s, int pere) { int lowpt ; boolean found = false ; ++numOrder ; lowpt = num[s] = numOrder ; for (List p = succ[s] ; p != null ; p = p.next) { int n = p.val ; if (num[n] == 0) { int lowN = doFindArticulation(n, s) ; lowpt = Math.min(lowN,lowpt) ; if (lowN >= num[s]) { System.out.println("Articulation : " + s) ; } } else if (num[n] < num[s] && n != pere) { lowpt = Math.min(num[n],lowpt) ; } } return lowpt ; } static void findArticulations(int s) { numOrder = 0 ; num = new int[succ.length] ; int nfils = 0 ; numOrder++ ; num[s] = numOrder ; for (List p = succ[s] ; p != null ; p = p.next) { int n = p.val ; if (num[n] == 0) { doFindArticulation(n, s) ; nfils++ ; } } if (nfils > 1) System.out.println("La racine " + s + " est un point d'articulation") ; }

Figure.IV.1 L’algorithme de détection des points d’articulation



72

La perte d'un sommet pour un graphe non séparable ne provoque pas la perte de la

connexité. De façon plus générale, on se pose la question pour un graphe connexe du nombre

minimum de sommets à retirer pour perdre la connexité de ce graphe. Plus ce nombre n’est

important, plus un réseau représenté par un tel graphe est robuste vis à vis des pannes.

L’algorithme de détection des points d’articulation possède une complexité de l’ordre de

O(N+M) et est considéré comme une spécification du parcours en profondeur.

IV.4.2. Reconfiguration de topologie

Comme nous avons expliqué dans les chapitres I et III, les réseaux de capteur forment un

nouveau environnement différent des réseaux traditionnels et bien adapté au service des

applications critiques tel que les alertes des catastrophes naturelles ou bien les applications

militaires (la détection des intrusions, la surveillance des champs de bataille…). Pour

répondre aux exigences des applications pareilles, il a fallu développer de nouveaux

mécanismes de support de la QoS. Ces mécanismes doivent à la fois optimiser la fiabilité

temps réelle de ses réseaux et respecter leurs spécifications (la densité des nœuds, leurs durées

de vie limitées, la topologie instable due à la mobilité, l’ajout ou la défaillance des nœuds….).

Ensuite, la dégradation des fonctionnalités de RCSF, comme la non couverture d’un sous

zone de surveillance, la répartition de réseau sont apparu imprévisibles. De ce fait, le

développement de nouveaux protocoles de surveillance et de gestion pour les réseaux de

capteurs s’avère indispensable.

Pour notre proposition, la procédure de reconfiguration sera lancée périodiquement ou

juste après l’apparition d’un ou de plusieurs point(s) d’articulation dans le réseau qui sont

considéré comme des points critiques. Ce qui nécessite une reconfiguration du réseau par le

changement topologique dans le champ de déploiement où il y a des points d’articulation. En

favorisant le déplacement de certains capteurs mobiles parmi les nœuds redondants, ces

déplacements permettent d'assurer la continuité de connectivité. La 2-connectivité sera

suffisante puisque ce seuil nous permit d’avoir au mois deux chemins entre les différents

nœuds capteurs du réseau, cela assure la connectivité. Ce principe de reconfiguration est

résumé dans l’algorithme suivant. Il s’agit de la reconfiguration périodique et/ou

événementielle.



73

L’algorithme de reconfiguration AP : liste des points d’articulation Début

Pour chaque point d’articulation s

Faire

Chercher un nœud s’ : s’ redondant, mobile, plus proche et s’ est un voisin de l’un des voisins de s

Calculer la nouvelle position (‘x’,y’) pour le nœud s’ Si (le nombre des points d’articulation dans le graphe

démunie) alors

Envoyer un requête de type Set qui ordonne le nœud s’

à se déplacer vers (x’,y’) FinSi

FinPour

Fin Figure.IV.2 L’algorithme de reconfiguration

IV.4.3. La consommation d’énergie

La consommation d’énergie est une contrainte importante qui doit être respecté. La définition

de la durée de vie n’est pas unique, elle peut être définie comme étant le temps investit à partir

du déploiement jusqu’à ce que le réseau devient incapable de rapporter correctement un

évènement par manque de ressources énergétiques ou répartition de réseau en plusieurs

parties. D'autres considèrent que la durée de vie d'un réseau est la durée entre le début de

fonctionnement et le moment où le premier nœud tombe en panne ou suite à l'épuisement de

son énergie.

Par la suite, on propose la modélisation de la couverture des cibles avec le graphe biparti

défini ci-dessous qui nous facilite la détection de la redondance des capteurs pour chaque

nœud cible.



74

IV.4.3.1. Le graphe biparti

Définition - On rappelle qu’un graphe biparti G = (A, B, E) est un graphe composé de deux

ensemble de sommets distincts A et B où BA E ×⊂ .

Le graphe biparti retenu schématise les relations de couverture entre les cibles et les nœuds

capteurs. La figure suivante illustre un exemple de graphe biparti, les nœuds capteurs en vert

sont des nœuds actifs et les autres en jaunes sont en mode sleep.

Figure.IV.3 Graphe Biparti

IV.4.3.2. Mécanisme de minimisation de consommation d’énergie

La batterie d’un capteur étant difficilement rechargeable, une solution de choix pour

économiser l’énergie consiste à mettre les nœuds redondants en mode veille. C’est de mettre

le capteur en mode sommeil le maximum possible [107] où la radio est éteinte et consomme

presque ‘0’. Dans l’état Idle, la radio consomme autant qu’en réception, mais il n’y a aucun

signal sur le canal. Cet état correspond à l’écoute inutile. Au moment de transmission, le

nœud émet un signal sur le canal radio. La consommation associée dépend de la puissance de

transmission. Ce modèle implique donc que les nœuds émettent tout le temps à la même

puissance. Il est possible qu’un nœud puisse changer dynamiquement sa puissance de

transmission [129][131].



75

L’algorithme de conservation d’énergie AP : liste des noeuds redondants Début

Pour chaque nœud redondant s

Faire

Mettre le nœud redondant en mode sleep

(Envoyer une requête Set)

FinPour

Fin Figure.IV.4 L’algorithme d’un mécanisme de Sleeping



76

IV.5. La base des données

Comme nous l'avons vu dans le chapitre. II, la MIB est considéré comme une collection

d'objets résidant dans une base d'information virtuelle. Ces collections d'objets sont définies

dans des modules MIB spécifiques. Cette base représente des informations sur l’application et

l’administration. La MIB locale doit être dynamique et optimal [109].

IV.5. 1. Structure de la MIB

A la base du langage ASN.1, la SMI donne la définition des modules, des objets et des

notifications. Le tableau ci-dessous donne en détails les caractéristiques de chaque

information portée dans la MIB à savoir le nom du champ, son type, sa taille et

éventuellement les valeurs possibles. Le tableau suivant donne une description des différents

objets liés au noeud capteur pour la définition de sa MIB.

Tableau. IV.1. La description des objets de la base MIB-Sensor

Nom Type Mode d’accès Description

1 ID Entier R Identificateur d’un nœud

2 TYPE OCTET R

Les nœuds peuvent être hétérogènes ou avec multifonction

3 (POSx,POSy) Long, Long R/W Position (x, y) 4 E Réel R/W Niveau d’énergie

5 Articulation_Pt booléen R/W Suivant le graphe de connectivité, le manager peut définir un noeud comme un Point d'articulation ou non

6 K Octet R/W K degré de connectivité d’un nœud 7 VOISIN_Actif TABLE R/W Liste des voisins actifs 8 Routing_Table TABLE R Table de routage 9 PERIODE Octet R/W Période_active 10 LAST_TIME Octet R Time _last _mesure 11 LAST_VALUE Long R Value_last_mesure 12 N_GetRequest1 Counter R Nombre des requêtes du 1er type 13 N_GetRequest2 Counter R Nombre des requêtes du 2ème type 14 N_response Counter R Nombre des réponses envoyées 15 N_trap Counter R Nombre de traps envoyées 16 N_Report Counter R Nombre de ‘Report’ envoyé aux voisins

17 N_response _demandé octet R Le nombre des réponses demandées pour

le 2ème type de Get

R/W : Read/ Write (lecture/ecriture).



77

IV.5.2. La structure générale des objets de la MIB

Les objets de ce type de base des données sont représentés sous la forme d’un arbre, où

chaque nœud est un objet.

L’arborescente de données dans la MIB |_Sensor info(1) _id(1) | |_type (2) | |_location (3) _ X (1) | |_ Y (2) | |_ network (2) _ E_residuel(1) | |_critic (2) |_network (3) _ degree de connectivity (1) | |_Ar_P (2) | |_Radio (4) _ Rc(1) | |_ Rt(2) | |_ Time_activation(3) | |_routing(5)_ Table_routage(1) _voision (1) _id (1) | |_ etat(2) |_mesure (6) _ Tlast(1) | |_ Last_mesure (2) | |_SNMP(7) _ N_ reponose _demandé(1) | |_ N_GetRequest1(2) | |_ N_GetRequest2(3) | |_ N_response(4) | |_ N_Trap(5) | |_ N_Report(6) |_Security (8) _ Key (1) - - paramètres de sécurité

Figure.IV.5 L’arborescence de données dans la MIB

IV.5.3. L'accès à l'information de gestion

Comme ça été expliqué dans le chapitre II, le protocole SNMP [49] assure trois types d'accès

aux informations. Le premier est de type interactif ; requête/réponse, dans lequel l’entité

agissant dans un rôle de gestionnaire, envoie une requête à des agents et celui-ci répond à la

requête. Ce type est utilisé pour récupérer l’information associée à la gestion de réseau de

capteurs. Un deuxième type est également comme le précédent, dans lequel le gestionnaire

envoie une requête à une entité SNMP, il va répondre à la demande. Le troisième type d'accès

est sans interaction, dans lequel un agent envoie un message non sollicité, appelé Trap au



78

nœud central. Ce type est utilisé pour notifier une entité, agissant dans un rôle de gestionnaire,

d'une situation exceptionnelle, qui a conduit à des changements à la gestion des informations.

IV.6. La structure des messages WSN-SNMP

Tout les messages de communication contient deux parties l’entête de message et PDU, nous

allons voir de manière succincte les champs qui composent un message SNMP [51] :

§ Version : Version de SNMP (version 1, 2, 3).

§ Community : Nom de la communauté, agit comme un mot de passe.

§ Type de PDU : décrit le type de ce message, il s’agit soit une requête, une réponse ou

bien une notification.

§ request-id : utilisé pour différencier et identifier les messages.

§ error-status : utilisé pour signaler une erreur, la valeur 0 signifie l’absence d'erreur.

§ error-index : indique la sous-catégorie d'erreur.

§ Variable bindings : noms des variables avec leurs valeurs. En cas ou le message est

de type « Get », les valeurs sont NULL.

§ 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é

Dans chaque capteur, la majorité d’énergie consommée est pour la communication, c-à-d

dépensé en émission ou en réception des paquets de tailles différents. Donc, on essaye de

garder la taille de message transmis entre les nœuds assez réduit que possible. Dans notre

solution, les deux champs (version et communauté) de l’en-tête seront ignorés.

Ø Type de PDU : nous définissons quatre formes de requête, deux réponses et un

ensemble des traps, en donnant la possibilité d’envoie des messages entre les nœuds voisins.

Notons que ce champ a un nombre précis de valeurs donc il peut être codés sur quelques bits

pour minimiser la taille des paquets échangés et par conséquence optimiser la consommation

énergétique pour l’émission et la réception d’un tel message, notamment quand il s’agit d’une



79

implémentation sur une plate forme réelle. Le tableau IV.2 résume l’ensemble des messages

définis.

Tableau.IV.2. Différents type de PDU pour WSN-SNMP

Type de PDU Nom 0 Get_request1 1 Get_Request2 2 Set_request 3 Get_Response1 4 Get_Response2 5 Trap 6 Report 7 Inform

Remarque : le PDU qui est associé à la valeur 7, nommé « Inform », est échangé entre

deux stations de base. Ce message peut être utilisé dans les systèmes hiérarchiques où on

trouve plusieurs managers.

Selon les besoins de fonctionnement, on obtient huit types de messages dont nous

exposons ici leur structure.

IV.6.1. Les requêtes

Le protocole SNMP permet de consulter les valeurs de la variables en exécutent une des

commandes suivantes: GetRequest, GetNextRequest et GetBulkRequest. GetRequest permet

la recherche d'une variable sur un agent, GetNextRequest permet la recherche de la variable

suivante et GetBulkRequest pour la recherche d'un ensemble des variables regroupées.

GetBulkRequest nous permet de demander en bloc plusieurs variables consécutives dans la

MIB. Généralement, on demande autant de variables que l'on peut mettre dans un paquet

SNMP, cela minimise le nombre des messages de contrôle communiqués. Elle permet à une

station d'administration de solliciter de la part d'un agent une réponse contenant le maximum

d'information pouvant être contenu dans un message qui ne dépasse pas la taille maximale de

paquet. Cette primitive groupe des requêtes équivalentes dans une même requête. Pour notre

solution, nous proposons deux formes de requête GET : Get_request1 et get_request2.



80

Ø Requête Get_request1, des messages de type Get sont envoyés périodiquement aux

noeuds capteurs pour récupérer les différents paramètres de gestion. Cette requête est

constituée de trois champs : type_PDU, Id_request et une suite de variables.

TypePDU = 0 Id_Request Variable1 ……………

(a) La requête Get_request1

Type_PDU=1 Id_request variable ……………

(b) La requête Get_request2

TypePDU=4 Id_request variable valeur

(c) La 3eme requête : Set_request

Figure.IV.6 Les formats des requêtes de WSN-SNMP

- TypPDU, ce champ vaux la valeur 0.

- ID_Request, chaque requête est identifiée par un nombre, en commençant par 1, qui est

incrémenté de 1 après l’émission d’une requête. Les paquets qui sont émis en

réponse à une requête portent le même identificateur que le paquet de la

requête. Il permet à la station de gestion d'associer les réponses à ses

requêtes. ID_Request sera codé sur quatre octets.

- Variables, toutes les versions de SNMP utilisent les variables « binding » représentant le

nom de variable avec sa valeur. Puisque le champ valeur est "null" et ne

donne aucune information pour les requêtes de type Get, en ignorant ce

morceau pour réduire la taille de paquet. Le champ « variables » présente

une liste finie de variable ou chaque variable soit codé sur quatre octets.

Donc, la taille de ce champ est égale à n*4 octets, où n représente le nombre

des variables choisis. La taille de champ valeur reçue en réponse est variée

selon le type de variable.



81

Ø Requête Get_Request2, le manager a le choix de demander une série de réponses pour

les mêmes variables. Il est possible d’utilisé un autre champ, noté N_req qui définit le nombre

des réponses souhaités, comme il correspond à l’envoie de N requêtes pour la/les même

variable(s).

Ø Set_request, cette requête est composée de quatre champs ; le premier champ définit le

type de requête suivi par un identificateur de la requête, le troisième est l’ID de variable et le

quatrième représente la nouvelle valeur associée à ce variable. Chaque requête SNMP est

suivie par une réponse envoyée par un agent qui donne au manager des informations sur

l’exécution de requête Set, avec ou sans erreur. Dans notre cas, nous évitons l’envoie de

réponse pour ne pas gaspiller l’énergie et éviter la congestion de réseau causé par

l’accroissement de nombre des paquets circulés dans le réseau à un moment donnée.

IV.6.2. Les réponses

Ø Get_Response : suite à une requête Get, l'agent répond par GetResponse. Toutefois si

la variable demandée n'est pas disponible, le GetResponse sera accompagné d'une erreur.

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

où succès. Lorsque la réception de la requête est réussit, celui-ci envoie la valeur de la

variable à laquelle on a accédé.

Type_PDU=2 ID_request Valeur1 ………

(a) message Get_response1

(b) Paquet Get_response2

Figure.IV.7 Format des messages de réponses

Plusieurs cas sont susceptibles de conduire au renvoi d’une erreur : l’écriture sur une variable

en lecture seule comme le niveau de l’énergie, une variable non existant, la trame SNMP est

incorrecte (corruption, longueur non valide, attaque …), l’authentification échoué. Dans ce

cas, l’agent répond à la requête par Get_Response2 en décrivant le type d’erreur et l’index

sur un octet (Error_Statut sur 4 bits, Error_Index sur 4 bits).

TypePDU=3 ID_Request Error_Status Error_Index



82

Le « Error Status » est l'indicateur du type d'erreur. Les réponses négatives possibles

sont décrites dans le tableau suivant.

Tableau.IV.3. Les différentes erreurs

Réponse valeur Description NoAccess 0 Accès non permis WrongLenth 1 Erreur de longueur WrongValue 2 Valeur erronée Wrongtype 3 Type erroné WrongEncoding 4 Erreur d’encodage NoCreation 5 Objet non crée ReadOnly 6 Pas de permission d’écrire NoWritable 7 Pas de permission d’écrire

AuthorisationError 8 Erreur d’autorisation

Error Index : indique quelle est la variable associée à l’erreur.

IV.6.3. Structure de Trap/Notification

Il est évident qu'une machine d'administration ne peut constamment demander aux éléments

surveillés quel est leur état, c'est pourquoi il est possible de demander aux stations d'émettre

(une fois tous les n unités de temps) un rapport sur son état. Les alertes sont envoyées quand

un événement non attendu se produit dans un élément à gérer. Celui-ci en informe la station

de supervision via une notification. Pour le PDUtrap ordinaire, six champs sont nécessaires :

Entreprise, Agent address, Generic trap type, Specific trap code, Timestamp, Variable

bindings. Dans notre proposition, les champs qui constituent ce message sont : Type_PDU,

ID_Trap, Type_Trap, Valeur. Le tableau suivant donne la description des champs qui figurent

dans les messages de type Trap présenté dans la figure IV.8.

Type_PDU=5 ID_Trap Type_Trap Valeur

Figure.IV.8 Structure d’un paquet de type TRAP



83

Tableau.IV.4. Les différents champs qui constituent les messages de type Trap

Champ Taille Description

ID_Trap 4 octets Identificateur de paquet

Type_Trap 1 octet

L’ensemble des traps est donné par la liste suivante : Trap d’énergie, Trap de gestion, Trap de mesure, Trap de communication, Trap de topologie et Trap d’erreur,

Valeur 4 Suivant le type de trap le manager peut traduire la valeur.

Report : Ce type de message est envoyé à un nœud voisin

Type_PDU=6 Type_Trap Valeur

Figure.IV.9 Structure de message de type Report

IV.7. Conclusion

Les RCSFs apportent une perspective intéressant celle de réseaux capables de s’auto-

configurer, sans qu’il y ait besoin d’interventions humaines. De plus, les critères de

performance pour un réseau de capteurs diffèrent de ceux des réseaux classiques et donc les

solutions à apporter sont nouvelles. En effet, les capteurs sans fils ont une vocation à devenir

des objets "banaux" et donc doivent pouvoir s’utiliser facilement. Le réseau doit devenir

transparent pour l’utilisateur. Les chercheurs dans le domaine de gestion et de supervision vue

que l’implémentation des protocoles de gestion de réseaux classiques tel que SNMP est

pratiquement impossible mais avec le développement technologique, ces standards peuvent

avoir une nouvelle tendance de recherche où le traitement des inconvénients de SNMP peut

augmenter la fiabilité de ce protocole.

Dans ce chapitre, nous avons présenté notre contribution pour la gestion des RCSF en se

basant sur ce standard et quelques propriétés de la théorie des graphes. Pour ce fait, nous

avons cité les principaux algorithmes, les paramètres et enfin la structure des messages

échangés entre les noeuds.


Chapitre V. Mise en œuvre du protocole WSNSNMP à l’aide de simulateur J_Sim

84

Chapitre V Mise en œuvre du protocole WSNSNMP à l’aide de

simulateur J_Sim

V.1. Introduction

Nous avons décrit dans ce chapitre la mise en œuvre de protocole WSN-SNMP présenté

précédemment et nous avons montré l’apport d’une approche centralisé à ce genre de réseau.

On commence par une description du simulateur J-Sim que nous avons utilisé pour établir nos

simulations. Notons que nous avons mis en oeuvre le protocole WSN-SNMP au niveau de la

couche application à l’aide de ce simulateur. Ensuite, nous montrerons les résultats des

simulations et évaluerons notre protocole WSN-SNMP suivant différents métriques. Une

évaluation du niveau énergétique de la batterie des nœuds sera réalisée également. La durée de vie

du réseau sera aussi calculée. Nous estimerons aussi l’espace de stockage requis pour la structure

de la MIB. Nous avons généré et étudie des topologies des réseaux contenant N nœuds

capteurs à l’intérieur d’un carré de largeur 1000m.

V.2. La représentation de simulateur J-Sim

Contrairement au NS-2[11], J-Sim est un outil programmé en langage Java, utilisé pour simuler

le comportement des processus pseudo parallèles, contient un package pour la simulation des

RCSFs et définit un modèle d’énergie [110]. Il repose sur une structure logicielle basée sur des

composants, appelée «Autonomous Component Architecture » (ACA). Le code source est

organisé en paquetages relatifs à un type de composants. Un composant est une entité

indépendante représentant un objet physique (une batterie, un module radio, une couche logicielle,

etc.) ou logique (un protocole de routage, un modèle de mobilité, etc.). Ces composants seront

ensuite connectés à l’aide des ports afin de générer un réseau simulé (voir Annexe B). Ces

répertoires sont structurés comme suit :

src/ fichiers source (*.java, *.gif, *.tcl...)



85

classes/ fichiers compilé (*.classes, *.gif, *.tcl...)

jars/ fichiers jar third-party

script/ fichiers scripts représentent les exemples et les simulation de teste

make/ common makefile, make log...

Chaque sous répertoire dans ./src corresponds à un paquetage Java. Le makefile est juste une

liste des fichiers sources dans le paquetage qui est utilisé pour placé les fichiers dans le même

nom de fichier. C’est à l’utilisateur de créer la simulation. Pour modifier le comportement du

simulateur J-sim, il est nécessaire d'accéder au code source (repertoire /src), et compléter ou

modifier ses fichiers sources.

V.3. Implémentation de protocole de gestion WSN-SNMP

V.3.1. Les paramètres et les variables des simulations

Avant de lancer une simulation, nous devons définir les paramètres du RCSF à configurer (le

modèle de topologie, la propagation du signal radio, le trafic des données, la mobilité des

nœuds et le modèle d’énergie pour les nœuds de capteurs). Ces informations sont utilisées

pour le déploiement et le fonctionnement d’un tel réseau. Le temps de la simulation est aussi

paramétrable. Pour bien analyser nos algorithmes dans différentes conditions, nous avons

choisi les paramètres suivants :

• Distribution des nœuds : uniforme/aléatoire/manuelle

• Taille du réseau : déploiement de N-1 nœuds capteurs et un seul Sink.

• Nombre des cibles : M points à couvrir.

• Dimension du champ de déploiement (en mètre).

• Type de réseau : homogène

• Rayon de connectivité R et Rayon de couverture r de chaque nœud (donné en mètres).

• Energie Initial d’un capteur en joules.

• L’accès s’effectue à travers le protocole MAC IEEE.802.11.

• Algorithme de routage : AODV

• Position de chaque nœud est définit par xi,yi / i=1..N.

• Fréquence d’envoi des messages de contrôles.

• Taux de mobilité des nœuds du réseau : Mmax et le dégrée de reconfiguration Rmax.



86

• Opérations de gestion : Get-Resqeust1, Get_Request2, Set_Request, Get_response1,

Get_Response2, Trap, Report.

V.3.2. Vue globale de l’application

Notre application consiste à modéliser, surveiller et gérer un RCSF suivant un scénario choisi

par l’utilisateur. Une interface graphique représente des informations sur les capteurs et ses

états de fonctionnement. La figure ci-dessous illustre le principe général de notre application.

Non Oui

Figure.V.1 Le principe général de notre application

Début

Saisir les paramètres du RCSF

Choisir le scénario de gestion

Introduire le Modèle d’énergie

Déploiement des nœuds (sink/capteur/cible)

Lancement de la simulation

L’exécution périodique d’un mécanisme de

gestion (reconfiguration)

Extraction des résultats

Représentation de Graphe du RCSF

Scénarios de reconfiguration

Données tabulaires et graphiques

Fin

Réseau Connexe



87

Le travail que nous avons réalisé offre une interface simple, facile à utiliser et qui permet

à l’utilisateur d’introduire les paramètres et suivre les simulations d’un réseau de capteurs

dont les principales fonctionnalités sont :

• Définition des variables de gestion et Initialisation des paramètres,

• Choix d’un scénario de gestion à simuler,

• Génération automatique des fichiers script,

• Déploiement d’un nouveau RCSF avec des paramètres personnalisés,

• Choix d’un noeud pour voir son état,

• Représentation graphique du réseau et des résultats de simulation,

• Visualisation des changements d’un RCSF,

• Test périodique par l’envoie des requêtes et réception des réponses/Trap,

• Détection des nœuds critique (point d’articulation),

• Reconfiguration de topologie pour assurer la 2-connectivité et 1-couverture,

• Application d’un mécanisme de conservation d’énergie en utilisant le graphe biparti,

pour sélectionner les nœuds redondants,

Premièrement, l’utilisateur doit saisir les paramètres liés au RCSF définis précédemment,

tel que la largeur de champ de déploiement, rayon de transmission, rayon de couverture,

niveau énergétique, scénario de gestion, le taux des nœuds capteurs mobiles, etc. On génère

un fichier « .tcl » pour qu’il soit soumis à J-Sim. Le déploiement du réseau est suivi par

l’affichage de la topologie en visualisant des nœuds cibles couverts et la connectivité de

l’ensemble des nœuds capteurs. Une fois l’exécution est lancée, les résultats sont soit

représentés avec des courbes soit sauvegardés dans des fichiers « .result ».

V.3.3. Présentation de notre application

Dans la première phase de préparation, les variables des simulations sont initialisés à travers

d’une interface que nous avons implémenté en java. La figure ci-dessous montre la fenêtre

d’accueil qui donne à l’utilisateur la possibilité de saisir les paramètres, choisit le type de

déploiement et le scénario de monitoring.



88

Figure.V.2 Fenêtre principale du logiciel.

Une fois la simulation est lancé, elle prend comme entré un fichier Script et génère des

courbes ou bien des fichiers journaux appelés aussi des traces qui décrit des informations sur

la simulation et les transactions effectués à travers le temps au sien du réseau. Notons que le

simulateur construit en fur et à mesure les graphes représentant le réseau de capteurs tels que

le graphe qui illustre la distribution de la totalité des noeuds, graphe biparti et la matrice

d’adjacente.

V.3.4. Le modèle de topologie

Nous pouvons générer des topologies de réseaux contenant N (=50, 100, 150….) capteurs à

l’intérieur d’un carré de largeur inférieur à 2000 mètres. Un seul sink est placé à gauche, au

coin le plus haut à la position (10,10). Des options sont ajouté et implémenté pour la

simulation en facilitant la modification de ces paramètres, où nous pouvons augmenter où

diminuer la charge de réseau, changer la façon de déplacement des nœuds, …. La boite de

dialogue illustré dans la figure. V.3 nous permet d’entrer ces paramètres.



89

Figure.V.3 Fenêtre d’initialisation de modèle de topologie

V.3.4.1. Modèle de transmission dans J-Sim

Comme la plupart des simulateurs de réseau, J-Sim possède un modèle propre de transmission.

L’utilisateur peut à tout moment implémenter son propre modèle ou modifier celui de J-Sim. Le

champ de simulation est divisé en plusieurs sous-champs à deux dimensions. Chaque sous-champ

est un rectangle de taille dx*dy. Un nœud définit sa portée de transmission comme suit : il peut

communiquer seulement avec les nœuds appartenant à son sous-champ et avec ceux dans les sous-

champs voisins. La Figure ci-desous (la partie a) montre que le nœud ‘A’ et ses voisins qu’il peut

atteindre en un seul saut. Il peut communiquer avec les nœuds appartenant aux neuf sous-champs

gris : le sous-champ où il appartient et les huit sous-champs voisins au sien.

Le rayon maximal de transmission R est la distance maximale entre deux nœuds

communicants. Selon le modèle de transmission de J-Sim, ce rayon est la diagonale du carré

formé par quatre sous-champs (voir la Figure.V.4, côté gauche). Ainsi, ce rayon peut être

calculé en utilisant la formule suivante : R = 2√(dx²+dy²).



90

Figure.V.4 Comparaison entre deux modèles de communication sous J_SIM

Le côté gauche de la figure ci-dessus décrit le comportement des nœuds communicants

dans J-Sim en se basant sur le modèle de transmission décrit précédemment. Le nœud ‘A’ ne

peut pas communiquer avec le nœud ‘D’ qui n’appartient à aucun sous-champ des neuf en

gris (portée de transmission de ‘A’) même si la distance ‘d’ entre eux est inférieure à R.

Cependant, le nœud ‘A’ peut communiquer avec le nœud ‘B’ qui appartient à un des neuf

sous-champs en gris.

V.3.4.2. La représentation de notre modèle de communication

Mais ce modèle de propagation est spécifique à J-Sim, qui n’utilise donc ni le modèle

théorique sphérique ni celui de voisinage qui en découle et est indépendant d’une distance

constante entre l’émetteur et le récepteur. Ceci peut traduire une simulation de l’atténuation

du signal à cause des obstacles ou d’autres facteurs.

Pour nos simulations, nous avons modifié le code d’implémentation de modèle de

propagation décrit ci-dessus de façon à avoir un rayon de communication pour les nœuds du

réseau comme il est illustré dans la figure V.2 (b). On a corrigé le modèle implémenté dans

jsim en modifiant son code source comme présenter dans la figure V.5.

(b) Champ de voisinage en considérant le rayon de transmission (a) Champ de voisinage dans J_SIM



91

Procédure modifiée pour implémenter le modèle de communication des noeuds capteurs /** Handles query and replies with a list of neighbors */ protected synchronized void processQuery(Object data_, Port inPort_) { if ( !(data_ instanceof NeighborQueryContract.Message) ) { error(data_, "processQuery()", inPort_, "unknown object"); return; } NeighborQueryContract.Message msg = (NeighborQueryContract.Message) data_; long nid; double X, Y, Z; double sqmnr ; long[] nodeList; int i, j, il, ir, jl, jr,adj; X = msg.getX(); Y = msg.getY(); Z = msg.getZ(); nid = msg.getNid(); // Radius = msg.getRadius(); sqmnr=Radius*Radius; adj= (int)(Math.ceil(Radius)); if(X!=-1 ){ i = (int)(X-minX); j = (int)(Y-minY); il = Math.max(0, i-adj); ir = Math.min(m-1, i+adj); jl = Math.max(0, j-adj); jr = Math.min(n-1, j+adj); int nn = 0; int ki, kj, kk, kv; for ( ki = il; ki <= ir; ki ++ ) for ( kj = jl; kj <= jr; kj ++ ) if(Math.pow((ki-i),2)+Math.pow((kj-j),2)<= sqmnr) nn = nn + g[ki][kj].size(); nodeList = new long[nn]; kk = 0; for ( ki = il; ki <= ir; ki ++ ) { for ( kj = jl; kj <= jr; kj ++ ) { for ( kv = 0; kv < g[ki][kj].size(); kv ++ ) if(Math.pow((ki-i),2)+Math.pow((kj-j),2)<= sqmnr) {



92

nodeList[kk]=((Long)(g[ki][kj].elementAt(kv))).longValue(); kk = kk + 1; } } } i = (int)(X-minX); j = (int)(Y-minY); channelPort.doSending(new NeighborQueryContract.Message(nodeList)); } else }}

Figure.V.5 Procédure modifiée pour implémenter le modèle de communication des noeuds capteurs

V.3.5. Distribution des nœuds

Si le déploiement est aléatoire, les nœuds sont positionnés dans la zone de déploiement. Dans

le cas de déploiement structuré, on calcule le pas: la distance minimale entre les nœuds

capteurs en fonction de L et N. En cas de déploiement déterministe, l’utilisateur doit cliquer

pour placer chaque nœud capteur en assurant toujours les conditions suivantes: le nombre des

nœuds capteurs placés doit être inférieur au nombre total des nœuds indiqués et les nœuds ne

seront pas positionnés hors de la zone de déploiement. A titre d’exemple, on utilise un RCSF

de 100 nœuds de (R, r)=(250,125) dans un champ de 1000 * 1000 m.

Figure.V.6 Visualisation de topologie de RCSF.



93

La visualisation d’ensemble des nœuds dessine leurs rayons de couverture et de

communication, ainsi que l’affichage de la taille de grille, et aussi avec zoom pour mieux voir

le graphe. La matrice d’adjacente est trouvé en fonction des positions des nœuds à l’aide du

calcule de la distance euclidien entre tout les deux noeuds. Nous remarquons dans la figure

suivante la matrice d’adjacente A[N,N] qui représente l’existence des liens entre chaque paire

des nœuds.

Figure.V.7 La représentation d’une matrice d’adjacente

Calcule de la matrice d’adjacente de graphes des noeuds capteurs public void MatAdj(){ double distance=0; for (int i = 0; i < N ; i++) { A[i][i]=0; for (int j=i+1;j<N;j++) { distance=Math.abs(Math.sqrt( Math.pow((topology[i][0]-topology[j][0]),2)+ Math.pow((topology[i][1]-topology[j][1]),2))); if(distance<=25.0) { A[i][j]=A[j][i]=1; } } } }

Figure.V.8 Procédure ajouté pour remplir calculé la matrice d’adjacente



94

V.3.6. Le modèle d’énergie

Le modèle d’énergie utilisé est celui implémenté dans J-Sim avec quelques modifications.

L’énergie consumée dans ces différents états:

- Pr_Tx = 0.660 W pour la transmission, - Pr_Rx = 0.395 W pour la réception, - Pr_Idle = 0.130 W en mode écoute, - Pour les deux modes ‘sleep’ et ‘off’, la consommation égale à 0.

Figure.V.9 Initialisation de modèle d’énergie

V.3.7. La structure des données MIB

public int id ; /* id of the sensor node. */ public byte type; public int sink_nid; /* id of the sink node to which collected data about target nodes should be sent along the wireless protocol stack */ public double LocX ; public double LocY; public boolean Ar_P; public double E_residuel;//12572 // public boolean critic; public byte degree_connectivity; public int Rc; public int Rt; public double Time_activation; public Vector RT=new Vector();// id etat(actif/sllep) public double Tlast; public double last_mesure; public int N_rep_ondemande; public int N_GetRequest1; public int N_GetRequest2; public int N_SetRequest; public int N_Response; public int N_Trap; public int N_Report; public int Key ; public boolean actif, sensing, moving;//12576 12575



95

V.3.8. Structure/ taille des messages

Pour plus de détails sur la conception, il est recommandé de montrer les principales structures

de données utilisées pour l’implémentation d’un tel protocole et calculer ces tailles. Le format

du message dépend des informations portées par ce dernier. L’interprétation d’un message

après sa réception par un nœud (capteur/sink) est assurée par la valeur du champ type (huit

valeur possibles : de 0 à 7). Les champs qui portent le même nom dans plusieurs type de

message ont les mêmes caractéristiques (type de données, taille, …) pour chaque type.

IV.3.9. La reconfiguration

Dans notre contexte, seulement la mobilité de quelques nœuds capteurs est prise en

considération. En favorisant certains déplacements des nœuds capteurs. Donc, nous avons

implémenté également l’algorithme de reconfiguration en choisissant des nœuds mobiles à

déplacer et en estimant les nouvelles positions optimales pour éviter la déconnectivité du

réseau et assurer toujours la 2-connectivité et la couverture des points cibles. Dans le cas d’un

nœud stationnaire, sa position reste fixe.

IV.3.10. Mécanismes de conservation d’énergie

L’exploitation de la redondance des nœuds permet de mettre en veille un ensemble de nœuds

en utilisant les principes proposés dans le chapitre précédent, nous rappelons que nous avons

appuyé sur la construction de graphe biparti dans le but d’économiser l’énergie du réseau de

capteurs (voir la figure suivante)

Figure.V.10 Topologie de réseau après l’exécution du mécanisme de conservation d’énergie.

Apres



96

V.3.11. Les scénarios de simulations

Nous pouvons varier quelques paramètres des différents scénarios proposés, pour voir

l’impact des critères de configuration sur les résultats obtenus et surtout sur nos aspects de

gestion. L’utilisateur a le choix de dérouler des différents scénarios de gestion. Pour mieux

simuler notre approche proposée, nous concevions quatre scénarios définis comme suit :

1. simulation sans utilisation de protocole de gestion

2. Simulation avec détection et la réparation des points d’articulation

3. Simulation avec la mise en oeuvre d’un mécanisme à économie d’énergie

4. simulation avec implémentation complet de protocole WSNSNMP

V.3.12. Générateur d’un fichier Script et initialisation de ces variables

Nous rappelons ici que le processus de simulation est composé de deux phases essentielles :

- La phase de génération : s’occupe de la génération d’un seul fichier d’entrée « .tcl ».

- La phase de simulation : lancer une simulation et générer des courbes où

sauvegarder les traces de simulations dans des fichiers « .result ».

Fichiers script est reconstitué par l’instanciation des classes, initialisations des variables,

création de la topologie de réseau, récupérations des valeurs, ajout des ports,

sauvegarde/désignation des données simulé.

Ø Création des ports

on peut simuler un des scénarios définis précédemment pendant une durée fixée où jusqu’à la

fin de la durée de vie de réseau. Une redirection des résultats de ces simulations est possible et

aussi recommandé pour les filtrer d’avantage. En fait, J-Sim permet la création d’autant de

fichier trace que vous désirez et vous permet aussi de diriger le résultat, que vous

sélectionnez, vers le fichier trace choisie. Tout d’abord, nous devons créer un port de

redirection au niveau d’un fichier source ".java" qui fournit le résultat que nous cherchons. À

travers ce port, nous redirigeons les résultats vers le fichier trace déjà créé. Nous expliquons

plus cette procédure suivant un exemple décrivant la procédure d’affichage d’énergie

résiduelle de chaque capteur au niveau du noeud « Sink ».



97

public static final String ENERGIE_PORT_ID=".energieresiduel"; protected Port EnergiePort = addPort(ENERGIE_PORT_ID);

Au niveau du code source ‘N_WirelessPhy .java’ :

• Création du port de redirection des résultats:

• La mise à jour d’énergie résiduelle d’un capteur: Dans la classe WirelessPhy, on fait par l’appellation de un de ces fonctions implémentés dans

la classes EnergieModel.java : updateIdleEnergy, updateTxEnergy, updateRxEnergy,

updateSleepEnergy, updateMovingEnergy

• Redirection des résultats vers le port « energie »:

Au niveau du script TCL: • Création du fichier trace et redirection des résultats :

void logEnergy() { if(nid>0){ mibPort.doSending(new DoubleObj(em.energy)); Port EresiduPort=(Port)getPort(E_Residuelle_PORT_ID + (int)nid); if ( EresiduPort.anyOutConnection() ) EresiduPort.exportEvent(Eresidu_EVENT, new DoubleObj((double)em.energy), null); } }

set filename_ energie.result set file_ [mkdir drcl.comp.io.FileComponent .file] $file_ open $filename_ for {set i 1} {$i < [expr $node_num - $target_node_num]} {incr i} { connect -c n$i/wphy/.energieResiduelle$i@ -to $file_/in@ }



98

V.4. Evaluation des résultats obtenus

Les résultats retournés seront également affiché par l’application sous la forme des courbes ou

stocker dans des fichiers textes. Dans cette partie, nous avons présenté les résultats des

simulations effectués. Ces différents résultats sont présentés sous forme des courbes. Les

métriques que nous avons calculées dans nos simulations sont la durée de vie de réseau……..,

nous avons mieux conclure les performances des nos algorithmes suivant les différents

scénarios. L’utilisation des réseaux de densité supérieure permet alors de réduire la dépense

totale d’énergie.

• L = 1000 mètres

• r = 125.0 mètres

• R = 250.0 mètres

• E = 1000 joules

La consommation d’énergie pour les différentes simulations On trace le graphe d’énergie résiduel pour un sous ensemble des capteurs en simulant le

premier scénario.

Figure.V.11 La représentation de l’énergie résiduelle de quelques nœuds de

capteurs en fonction de temps de simulation pour le scénario 1.



99

La durée de vie du réseau

Un autre facteur utilisé pour évaluer l’efficacité d’un protocole est la durée de vie de RCSF.

On considère que la durée de vie est la période entre le début de fonctionnement et le moment

où le réseau devient non connexe (déconnexion d’une ou plusieurs parties du réseau).

Après la simulation, nous aurons le fichier trace nommé « energie.result » créé sous le répertoire courante $JSIM/ Ce fichier contient l’énergie résiduelle de chaque capteur à des instances périodiques comme suit:

V.4.1. Influence de la densité de réseau

Pour cela, on trace le graphe obtenu après des différentes simulations et représentant la

variation de la durée de vie en fonction de la densité de réseau de capteurs pour les quatre

scénarios proposés dans la section V.3.11.

Figure.V.12 La durée de vie vs la densité de réseau.

02000400060008000

1000012000140001600018000

10 20 50 100 200

Network density

Sens

or N

etw

ork

Life

time

Scenario 1 Scenario 2Scenario 3 Scenario 4

Dur

ée d

e vi

e de

rése

au

Densité du réseau

… EVENT--410.001001--/monitor/n1/wphy/[email protected] EVENT--410.00100199999997--/monitor/n2/wphy/[email protected] EVENT--410.00100299999997--/monitor/n3/wphy/[email protected] EVENT--410.00100399999997--/monitor/n4/wphy/[email protected] EVENT--410.00100499999996--/monitor/n5/wphy/[email protected] ….



100

On voit bien dans la figure ci-dessus, l'influence de la redondance sur la consommation

énergétique. En effet, chaque nœud endormi permet d’économiser son énergie en évitant la

communication avec les autres nœuds actifs. Le réseau de capteurs devient inexploitable

quand la connectivité entre ses nœuds est perdue, on dit que le réseau est mort. L’allure de la

courbe de la durée de vie dans le cas de redondance permet de prévoir une bonne durée de vie

pour les réseaux à grande échelle. Par contre, un réseau sans redondance de grande taille

risque d’épuiser rapidement l’énergie de ses nœuds à cause des communications inutiles des

nœuds qui restent actifs.

V.4.2. L’impact de nombre des points d’articulation

Les résultats de simulation sur un réseau de capteurs de 50 et 100 nœuds qui sont déployés

d’une manière aléatoire montrent l’efficacité de l’approche notamment avec la présence des

nœuds redondants.

Figure.V.13 L’influence de nombre des points d’articulation sur la duré de vie.

V.4.3. L’influence de degré de mobilité sur la durée de vie de réseau

Noté que Mmax est le degré de mobilité des nœuds capteurs dans le réseau. On définit

aussi le degré de la reconfiguration comme le nombre maximal des points d’articulation

détectés dans le réseau, c’est le nombre de fois maximal que le protocole WSN-SNMP peut le

reconfigurer.

5000 7000 9000

11000 13000 15000 17000 19000

1 2 3 4 5Number of Articulation point

50 100

Dur

ée d

e vi

e de

rése

au

Nombre des points d'articulation

Noeuds Noeuds



101

5000

7000

9000

11000

13000

15000

10% 50% 100%

Pmax=Mmax/(N-1)*100

Netw

ork

Life

time

50 nodes100 nodes

Figure.V.14 L’impact de degré de mobilité des noeuds de réseau sur sa durée de vie

En observant le graphe de la figure V.14, nous retirons les remarques suivantes :

Ø Par augmentation de la taille des réseaux, on remarque une différence entre la durée de vie

d’un réseau avec grand de gré de mobilité est supérieure à celle d’un réseau moins mobiles.

6000

8000

10000

12000

14000

16000

18000

1 2 3 4 5Number of Art iculation point

Netw

ork L

ifetim

e

N= 50, Pmax = 50%N= 50, Pmax =100%N=100, Pmax = 50%N=100, Pmax =100%

Figure.V.15 Comparaison de la durée de vie avec la variation de degré de reconfiguration Rmax et le taux de mobilité.

Comme résultat, on peut dire que la mobilité peut donner plus de vie au réseau avec le

déplacement des nœuds mobiles qui sont redondants.

V.4.4. L’influence de nombre des messages générés

Le choix de la fréquence d’envoie messages de contrôle périodiquement est un paramètre

critique parce que cette fréquence a une grande influence sur la consommation d’énergie dans

Noeuds Noeuds

Dur

ée d

e vi

e de

rése

au

Dur

ée d

e vi

e de

rése

au

Nombre des points d'articulation



102

le réseau: une fréquence élevée consomme beaucoup d’énergie et provoque la congestion

dans notre réseau mais permet d’avoir des informations supplémentaires et détecter des

anomalies en temps réel, une faible période permet au réseau d’économiser l’énergie et donc

prolonger la durée de vie de réseau mais les données de contrôle peuvent être retardée un peu

selon la fréquence choisie.

V.5. Conclusion

Dans le cadre de cette étude, nous nous intéressons à la conception d’un nouveau protocole de

surveillance et de gestion pour les RCSF qui permet de récupérer des informations de chaque

nœud capteur. L’implémentation de protocole WSN-SNMP sous le simulateur J-SIM, nous a

permet d’extraire quelques résultats par simulation et évaluer l’efficacité de l’approche

développé. Ces résultats exposent l’avantage de la modélisation à l’aide de théorie des

graphes pour assurer la tolérance aux pannes dans un réseau de capteurs sans fil qui est un

ensemble de dispositifs capables de traiter les informations et même prendre des décisions

comme il est le cas quand un point d’articulation est détectée. L’exploitation de la redondance

des nœuds permet d’étendre la durée de vie d’un RCSF, ce traitement se fait d’une manière

centrale.

Ce but est atteint par la mise en œuvre d’un mécanisme de reconfiguration de topologie,

déplacement de quelques nœuds mobiles est indispensable. Pour conclure, nous pouvons

noter, grâce à ces simulations, que les résultats obtenus montrent le bon comportement de

protocole WSN-SNMP et nous encouragent à orienter nos travaux de recherches futurs en

favorisant l’utilisation de standard SNMP dans un réseau de capteurs.


Conclusion générale

103

CONCLUSION & PERSPECTIVES

Ce mémoire présente un protocole de gestion et de supervision centralisé pour les RCSFs

en se basant sur la théorie des graphes prenant en compte les principes de fonctionnement de

protocole SNMP. Ce dernier est largement utilisé pour l’administration des réseaux. La

gestion des RCSFs avec ce standard est vue par plusieurs chercheurs, qui une solution

coûteuse et compliqué et même impossible a réalisé. Mais il reste possible de le converger

dans un environnement différent au TCP/IP et éliminer ces inconvénients.

Nous avons étudié la problématique de gestion et de supervision de RCSF afin de

minimiser la consommation totale d’énergie pour chaque nœud capteur. Nous avons mis

l’accent sur des critères liées à la topologie du réseau : couverture des points cibles,

connectivité des nœuds capteurs, par conséquent le prolongement de la duré de vie de réseau.

En fait, les protocoles de gestion basés sur l’optimisation des dépenses énergétiques doit

prendre en compte les contraintes matérielles d’un capteur : une batterie faible, une capacité

de stockage modeste, un bande passante faible. C’est l’objectif du protocole proposé, nommé

WSN-SNMP dans ce domaine.

Afin de montrer le bon comportement du WSN-SNMP, nous avons réalisé des simulations

sous J-Sim. Celle-ci contient un package pour les RCSFs et définit un modèle d’énergie. Le

simulateur J-Sim est codé en java et utilise le langage TCL pour écrire les scénarios de

simulation. Les simulations ont montré une consommation énergétique optimale et un petit

espace de stockage est nécessaire pour la MIB. Suivant les résultats qu’on a atteint, on peut

confirmer la faisabilité d’utiliser une version de SNMP pour les RCSFs.

Notre travail peut être amélioré par d’autres travaux de prolongation. Une première

perspective consistera à l’étude des performances de WSN-SNMP au sein des réseaux de

capteurs mobiles. Nous proposons de développer notre approche pour traiter le problème de la

mobilité des nœuds capteurs et/ou un ou plusieurs sink.


Conclusion générale

104

Une deuxième perspective visera l’optimisation de la consommation d’énergie par ce

protocole pour des réseaux formés en cluster.

Enfin une dernière idée concernant une méthode d’agrégation de données. En effet, dans cette

méthode, plusieurs nœuds qui sont à proximité d’un certain événement communiquent dans le but

de fusionner les données collectées. L’agrégation permettrait de minimiser le nombre d’envois des

données identiques collectées par plusieurs nœuds voisins afin de les acheminer vers la station de

base. Il nous permettrait aussi de minimiser le nombre des messages de contrôle communiqués

entre les nœuds capteurs et le sink. Ainsi, on prolonge la vie du réseau en minimisant l’envoi et la

réception des paquets.


Annexe. A Généralités sur la Théorie des Graphes

105

ANNEXE A

GENERALITES SUR LA THEORIE DES GRAPHES

La théorie des graphes constitue un outil puissant pour schématiser les modèles des liens et

des relations entre les objets. L’étude des graphes a commencé depuis le 18ième siècle par un

problème de curiosité mathématique lorsqu’Euler a posé le célèbre problème du pont de

Konigsberg. Ces dernières décennies, la théorie des graphes a suscité un intérêt exponentiel

essentiellement grâce a son rôle comme des modèles d’optimisation et de calculs explicites

nécessitants la conception et l’analyse de plusieurs algorithmes. En outre de son rôle éminent

dans l’informatique, les mathématiques appliquées, la biologie, la physique, la chimie ..., la

théorie des graphes est devenue l’un des instruments les plus efficaces pour résoudre de

nombreux problèmes discrets que posent de nombreuses théories très utiles telles que la

recherche opérationnelle[116][117][119].

A.1. Graphes : définition et propriétés

Définition - Un graphe est un schéma constitué par un ensemble des points et par un

ensemble des flèches reliant chacune deux de ceux ci. Les points sont appelés les sommets du

graphe, et les flèches les arcs du graphe.

1. Un graphe non orienté G est modélisé par un doublet ( )EV , , où V représente l’ensemble

des sommets et E l’ensemble des arêtes.

Figure A.1. Graphe non orienté.



106

2. De même, un graphe orienté G est modélisé par un doublet ( )AV , , où V représente

l’ensemble des sommets et A l’ensemble des arcs.

Figure A.2. Graphe orienté

3. L’ordre d’un graphe est le nombre de sommets.

4. Un graphe symétrique est connexe si et seulement si pour toute paire de noeuds du réseau,

il existe au moins un chemin, permettant d'aller d'un noeud à l'autre. Cette définition est

plus intéressante pour les réseaux de capteur. Le réseau de capteur est dit connecté si et

seulement s’il existe au moins une route entre tous paire de nœuds.

5. Considérons un graphe ( )EVG ,= non orienté. Soit Vv ∈ . On note ( )vΓ l’ensemble des

voisins de v, ( ) ( ){ }Ewvwv ∈=Γ ,/ . On définit le degré de v par ( ) ( )vv Γ=deg . Pour un

graphe orienté, on parle des degrés entrant et sortant. Le degré d’un sommet est alors la

somme des degrés entrant et sortant.

6. Un graphe est complet si et seulement si { }nvvV K1= et ( ){ }jivvE ji ≠= /, . On note Kn

le graphe complet d’ordre n. On a alors ( )2

1−=

nnE .

7. Un graphe G est biparti si on peut le partitionner en deux classes telles que

( )EVVG ,21 ∪= et que les sommets de Vi ne soient pas liés entre eux.

Figure A.3. Graphe biparti



107

8. Un graphe G est bipartie complet si et seulement s’il est bipartie et que tous les sommets

de V1 sont reliés à tous les sommets de V2. On note 21 , VVK . Un graphe est bipartie si et

seulement s’il ne contient pas de cycle de longueur impaire.

9. Etant donné un graphe ( )EVG ,= , VV ⊂′ , on appelle sous-graphe de G engendré par V’

le graphe ( )EVG ′′=′ , dans lequel EE ⊂′ et tout élément de E’ relie deux éléments de V’.

10. Un graphe orienté ou non est connexe si et seulement si pour tout couple de sommets, il

existe une suite d’arêtes reliant ces sommets.

11. La composante connexe d’un sommet est l’ensemble des sommets que l’on peut atteindre

avec des chemins ayant pour origine ce sommet.

12. Un graphe orienté est fortement connexe si pour tout couple de sommets, il existe un

chemin reliant ces sommets.

13. Soit G= ( )EV , un graphe connexe :

- Soit Vvu ∈, , la distance entre u et v est l’entier ( ) ( )( ) ( )( )vucvuclvud ,,,min, = avec

« c » le chemin et « l » la longueur de ce chemin.

- On appelle excentricité d’un sommet ( ) ( )( )vuduexcVv

,max∈

= .

- On appelle rayon d’un graphe ( ) ( )( )uexcGrVu∈

= min .

- On appelle diamètre d’un graphe l’entier ( ) ( )( )vudGdiamVvu

,max, ∈

= .

- On appelle centre de G un sommet tel que ( ) ( )Gruexc = .

- Un sommet est médian si la somme des distances aux autres sommets est minimale.

Posons ( ) ( )∑∈

=Vu

vudv ,σ . L’ensemble des médians est tel que ( ){ }min/ =vv σ .

14. Un sommet est un point d’articulation si, en retirant ce sommet, on augmente le nombre

des composantes connexes (voir la figure A.4, le noeud qui appartient au cercle).

Figure A.4. Graphe avec un point d’articulation

X



108

15. Une arête est un isthme si, en retirant cette arête, on augmente le nombre des composantes

connexes. Une arête n’est pas un isthme si cette arête appartient à un cycle. La réciproque

est vraie.

16. Etant donné un graphe connexe G, on dit que G est k-connexe s’il faut retirer au moins k -

arêtes pour augmenter le nombre des composantes connexes.

17. Un graphe est 2-connexe si et seulement si pour toute arête appartient à un cycle. Etant

donné un graphe G, il est possible en donnant une orientation à chaque arête d’en faire un

graphe fortement connexe si et seulement s’il est 2-connexe.

Figure A.5. Graphe 2-connexe

A.2. Représentations des graphes

Chaque graphe peut être représenté par trois manières différentes en vue de leurs

manipulations algorithmiques, en utilisant un tableau des listes ou une matrice ou bien la

matrice d’incidence. Cette représentation dépend de la solution algorithmique retenue.

a) La représentation par un tableau des listes

L’idée est de représenter un graphe par un tableau qui associé à chaque sommet une liste

chaînée des arcs sortants ou des arêtes incidentes. Un graphe orienté simple ([1, n], E) peut

être représenté par un tableau T à indices dans [1, n] et à valeurs des listes de sommets. Un tel

tableau doit vérifier pour tout couple de sommets (i, j) : J<- T[i] ó (i, j) ∈ E (1).

Dans ce cas, l’espace mémoire est linéaire, la cardinalité du nombre de sommets et du

nombre d’arêtes : Ө (n+m).



109

b) Représentation par matrice d’adjacence

Cette représentation concerne les graphes dans lesquels seuls les sommets sont nommés

(pas de noms pour les arêtes ou arcs). Tout graphe orienté simple ([1, n], E) peut être

représenté par sa matrice d’adjacente M de booléens de taille n x n définie par :

1 si (i, j) ∈ E (2)

0 sinon

La taille de la représentation est élevée : Ө (n*n). Un graphe peu « dense » (avec peu

d’arcs) a une représentation de même taille qu’un graphe dense.

c) Représentation par matrice d’incidence

Tout graphe non orienté à arêtes multiples ([1, n], [1, m], F) peut être représenté par sa

matrice d’incidence, c'est-à-dire la matrice M de booléens de taille n x m définit par :

1 si (i, j) ∈ F (3)

0 sinon

A.3. Les graphes planaires

1. Définition - Un graphe est planaire s’il admet une représentation dans laquelle

aucune de ses arêtes n’en croise une autre.

2. Définition - Etant donné un graphe planaire, on appelle face toute portion du plan

connexe.

3. Proposition - On peut s’arranger en dessinant le graphe pour que n’importe quelle face

soit la face infinie (projection stéréographique).

4. Formule d’Euler : Soit G un graphe planaire, simple, connexe et sans boucle. Le

nombre de face f ne dépend pas de la représentation et 2+−= saf avec a le nombre

d’arêtes et s le nombre de sommets.

5. Proposition - Dans un graphe planaire, il existe au moins un sommet de degré

inférieur ou égal à 5.

M[i, j] =

M[i, j] =



110

A.4. Couplage et couverture

Définition - Soit G = (V; E) un graphe. Un ensemble K < V est une couverture de E si toute

arête de G est incidente à un sommet de K.

Théorème (Berge 1957) : Soit M un couplage dans un graphe G. M est maximum si et

seulement s’il n'existe pas de chemin M-augmentant.

Algorithme de recherche d’un couplage maximum dans un graphe G quelconque :

1) Choisir un couplage initial C ;

2) S’il y a moins de deux sommets insaturés, alors STOP : le couplage C est maximum

Sinon, soit x un sommet insaturé : construire un arbre alterne de racine x ;

3) Si l’algorithme de construction d’un arbre alterne détecte une chaîne augmentant dans G’,

alors poser C égal au couplage obtenu par transfert le long de cette chaine augmentant,

reconstituer le couplage correspondant dans G en décontractant les cycles impairs, poser C

égal a ce nouveau couplage et retourner à 2)

4) Sinon supprimer de G tous les sommets marques. Et retourner a 2)

A l’étape 3, lorsqu’il s’agit de reconstituer un couplage dans G à partir d’un couplage C’ dans

G’, on s’y prend comme suit. Soit W une orbite de racine r qui a été transformée en un

sommet w. Soit CW l’ensemble des arêtes de C qui sont dans G[W]. Le couplage CW sature

tous les sommets de G[W] sauf la racine r. Si C’ ne passe pas par w alors on peut décontracter

le cycle et rajouter CW a C’. Sinon, C’ contient une arête (z,w). Si en décontractant le cycle,

le sommet z est relie à r, alors on peut remplacer (z,w) par (z,r) et rajouter CW à C’. Sinon, on

peut remplacer (z,w) par une arête (z,y) où y est un voisin de z dans W, et on effectue un

transfert de CW le long de l’unique chaine paire qui mène de ‘y’ à ‘r’ dans G[W] (en d’autres

termes, on remplace le couplage maximum CW dans G[W] par un couplage maximum

laissant y insaturé au lieu de r).


Annexe. B Simulateur J-Sim

111

ANNEXE B

SIMULATEUR J-SIM

B.1. Introduction

Dans le monde de simulation des réseaux, beaucoup de contributions ont participé à

l’enrichissement de ce domaine. Plusieurs axes de recherches se basent sur ces simulateurs.

La majorité des travaux effectués et élaborés par des laboratoires informatiques à travers le

monde. En fonction des particularités de chacun, les chercheurs choisissent le simulateur le

plus approprié. Les simulateurs les plus répondus sont OMNET++, OPNET, QualNet,

SensorSim, Shox, NS-2, J-SIM…etc.

Ø Omnet++ est utilisé sur la plate-forme MicroSoft Windows, Unix. Sa licence est

gratuite pour les universitaires et pour toutes utilisations non lucratives. Il ne semble pas

particulièrement prévu pour les réseaux sans fil. Il n’existe pas des modèles spécifiques aux

capteurs indiqués sur le web. Cependant, Omnet++ semble séduire de plus en plus la

communauté scientifique et un nombre croissant des modèles est disponible.

Ø NS-2 est très utilisé pour les réseaux Ad-hoc et les réseaux filaires sur Linux,

Solaris, Mac OS, Windows, avec une licence gratuite. Toutefois les modèles des couches

physiques sont simplistes. Le développement des protocoles s’effectue en C++ et en OTcl

(évolution objet de TCL). Les scénarios sont décrits en OTcl. La prise en main est peu aisée;

en effet OTcl est peu connu et la programmation en C++ nécessite de comprendre l’interface

entre les deux langages. Le résultat de la simulation étant essentiellement composé d’un

fichier retraçant l’ensemble des envoies, réceptions et suppressions des paquets. Du fait de sa

popularité, de nombreux protocoles sont a priori disponibles pour NS-2. Quelques protocoles

spécifiques aux réseaux de capteurs sont disponibles aussi dans NS-2.

Ø SensorSim est utilisé aussi avec une licence gratuite sur les différentes plateformes.

Il s’agit d’un projet de l’université de Californie de Los Angeles. Visant un simulateur

spécifique aux réseaux de capteurs sur la base de NS-2. Les sources ont d’ailleurs été retirées

de la page du projet du fait de l’absence de support.



112

Ø QualNet est un simulateur payant, utilisé sur la plateforme Microsoft Windows,

Linux, Solaris. Il est la version commerciale de GlomoSim. Une documentation plus fournie

que GlomoSim et un support technique sont fournis. Une interface graphique est aussi

intégrée au logiciel.

Ø TOSSIM est un simulateur des réseaux des capteurs pour les programmes TinyOS

qui n’implémente pas le Standard IEEE802.15.4 en entier[123]. Tout programme en NesC

peut être compilé avec TOSSIM. Il existe d’autre comme Mos et SOS, écrits en langage C.

Ø J-Sim [120] permet de simuler des réseaux de grand ordre, sa licence est gratuite.

L’architecture et le code sont suffisamment bien structurés pour permettre une prise en main

relativement aisée. J-Sim permet d'utiliser, comme générateur de trafic, n'importe quelle

application Java. J-Sim souffre peut être de sa jeunesse et quelques corrections s’avère

nécessaires. La simulation du fonctionnement d’un réseau de capteurs, qui exige la définition

des composants et leur mise en relation, est réalisée grâce à un langage spécifique, TCL. Il

s’agit d’un langage de script dans lequel on spécifie l’architecture du réseau ainsi que les

paramètres de simulation et d’analyse. Les commandes de script peuvent également être

fournies en ligne de commande, instruction par instruction.

L’architecture détaillée de J-Sim

J-Sim repose sur une structure logicielle basée sur des composants, appelée « Autonomous

Component Architecture » (ACA). Dans J-Sim, chaque entité est appelée un composant et

chaque composant peut avoir plusieurs ports qui sont utilisés pour communiquer avec d'autres

composants [121, 122]. Le code source est organisé en paquetages relatifs à un type de

composants.

Figure.B. 1 Connexions entre composants dans J-Sim



113

Un composant est une entité indépendante représentant un objet physique (une batterie, un

module radio, une couche logicielle, etc.) ou logique (un protocole de routage, un modèle de

mobilité, etc.). Ces composants seront ensuite connectés à l’aide de ports afin de générer un

réseau simulé (voir la figure précédente).

1. Le composant La notion des composants n’est pas nouvelle et a été employée dans plusieurs normes composant

telles que JavaBeans, CORBA et COM/DCOM/COM+. A la différence des JavaBeans, de

CORBA, et de COM/DCOM, les composants dans J-Sim sont faiblement connectés. Ils

communiquent entre eux en connectant leurs ports ensemble, et sont liés par des contrats. Les

contrats indiquent la causalité des informations envoyées/reçues entre les composants, mais

n’indiquent pas les composants qui participent à la communication. En résumant, des composants

peuvent être créés et ils peuvent être liés grâce à une interface de commande qui utilise la syntaxe

des invités de commandes (shells).

2. Le port

Un composant communique avec les autres composants par l’intermédiaire de ses ports. Il

peut posséder plus d’un port. L’interface de programmation entre un composant et son port

est bien définie. Un composant peut être développé sans la présence d’autres. En outre, le

mécanisme réel de communication qu’un composant emploie pour communiquer avec le reste

du monde est complètement caché par la notion de port.

3. Le contrat La communication entre composants est décrite par les contrats. Le contrat impose les conditions

sur les ports d’entrée/sortie des composants afin de les faire communiquer. Un contrat indique

comment un initiateur (visiteur) et un réacteur (appelé) accomplissent une certaine

communication. Il décrit comment un composant répond aux données qui arrivent à chacun de ses

ports (par exemple, comment le composant traite les données, certaines structures de données de

mises à jour, et produit des sorties à certains ports).

4. Langage utilisé pour définir un scénario de simulation

Bien que J-Sim soit écrit en Java, les scénarios de simulation ne sont pas décrits en Java. Pour

développer un grand projet, il peut devenir encombrant d’employer des commandes TCL/Java



114

parce que les références des objets Java doivent être stockées dans des variables TCL afin d’y

accéder. Pour simplifier la syntaxe des simulations, il existe un système appelé RUntime Virtual

(RUV). Ce système s’appuie sur la similitude entre les systèmes composants et les systèmes de

fichiers d’UNIX. L’analogie entre un composant/port et un chemin de fichier permet d’accéder au

composant de la même manière que l’on accède à un dossier dans un système de fichiers.

A l’aide de TCL (Tool Command Language), on définit les composants puis on les connecte.

Tous les composants sont hébergés dans un conteneur, qui est à son tour un composant. La

définition des composants est en fait la création des objets. Cette création est réalisée par la

commande TCL mkdir. Chaque composant est d’une entité indépendante qui fonctionne

indépendamment des autres entités. Les composants possèdent des ports par défaut pour qu’ils

puissent communiquer entre eux. D’autres ports peuvent être créés pour un composant. Une

connexion entre deux composants est réalisée par l’intermédiaire de deux ports dédiés, un dans

chaque composant (voir la Figure). Cette connexion est matérialisée par la commande TCL

connect. Il suffit de suivre un schéma qui indique l’interconnexion entre les différents types de

composants que l’on veut utiliser. On obtient ainsi l’architecture du nœud. Toujours dans ce script

TCL, on y définit les paramètres globaux (par exemple la taille du champ de simulation), les outils

de visualisation des résultats et l’ordonnancement de la simulation.

Tcl a été conçu dès le début pour être un langage de commandes réutilisable. Ses auteurs

avaient créé un ensemble d'outils interactifs, chacun nécessitant son propre langage de

commandes. Comme ils étaient plus intéressés par les outils eux même que le langage des

commandes utilisé par les outils, ces langages de commandes furent mis au point rapidement,

sans porter attention à leurs cohérences. Dans la plupart des cas, Tcl est utilisé de concert avec

la librairie Tk (Tool Kit), un ensemble des commandes et des procédures qui permet de

programmer très facilement des interfaces graphiques. Un des aspects le plus intéressant de

Tcl est sa capacité d'extension. Si une application a besoin des fonctionnalités absentes en Tcl,

des nouvelles commandes Tcl peuvent être ajoutées à l'aide du langage C et intégrées

facilement. Puisque Tcl est si facile à étendre, beaucoup de personnes ont écrit des paquets

d'extensions en les rendant disponibles sur internet.

La différence principale entre Tcl et des langages comme le C est que Tcl est un langage

interprété et non un langage compilé. Les programmes écrits en Tcl sont en fait des fichiers

texte constitués des commandes Tcl qui sont traitées par un interpréteur Tcl au moment de



115

l'exécution. Un avantage que cela offre est qu'un programme Tcl peut générer lui-même des

fichiers de commandes Tcl qui peuvent être évaluées à un autre moment. Par exemple, lors de

la création d'une interface graphique avec un bouton qui accomplit différentes actions.

Exemple 1 : set msg "puts salut"

eval $msg

Résultat : salut

Etude comparative Le tableau suivant montre une comparaison entre les différents

simulateurs cités précédemment.

Tableau. B.1. Comparaison entre des simulateurs différents [120]

Aspect J-Sim OMNet++ Ns-2 Shox Modèle

d’énergie + - + +

802.11 power save

+ - + -

CompSPAN + - + - AODV + + + + DSR - - + -

GPSR + - + + Visualisation -Fichier de

trace NAM -Manque de propre outil

-En ligne avec modèle d’inspection, retour arrière -Répétition de simulation

-Fichier de trace peut être vue avec nam

-Fichier trace, vue internal

Statistiques -Plot enligne -Exporté au fichier donné par utilisateur

-Fichier trace -Affiché avec plove

-Fichier log est affiché avec xgraph

-Fichier des statistiques -Vue internal -Exporter gnuplot

Points forts - Flexibilité - Basé sur java

-Maturité -Support graphique -Modèle d’inspection

-Base de modèle -Base d’utilisateur

-Support graphique visualisation Architecture

Faiblesse -Support graphique - visualisation des capacités

- modèle d’énergie - concurrent Mac

-OTcl -Architecture

- Documentation - Manque des modèles



116

Package Sensorsim

Pour un réseau des capteurs, un nœud peut être : une cible, un capteur ou un sink. Des nœuds

cibles sont des nœuds sources qui génèrent les événements dans le réseau. Un nœud cible

livre un événement produit dans le canal de capture « Sensor channel » utilisant sa pile de

capture « Sensor Stack ». Les nœuds capteurs ont deux piles: une pile protocolaire sans fil

« Wireless Stack » et une pile de capture « Sensor Stack ». Un nœud capteur reçoit n'importe

quel événement du « Sensor channel » en utilisant « Sensor Stack », traite l'information et le

transmis par «Wireless channel». Un nœud de sink a seulement la pile « wireless protocols

stack », qui reçoit toutes les données de capteurs du canal sans fil.

Tableau. B.2. les différents composants de package sensorsim [122]

Nœud cible Canal de capture Propagation de

capteur Nœud capteur

Target channel

Target packet

Sensor mobility model

Sensor physique

Sensor position report

contract

Sensor node

Position tracket

Sensor channel

Accoustic channel

Sensor neighbor

query contract

Sensor propogation

model

Seismic propagation

Accostic propagation

Modèle de batterie

Modèle de CPU

Installation du simulateur JSIM

Dans cette dernière section de l’annexe, nous présentons les étapes d’installation du simulateur J-Sim.

Etape 1 - Pour installer le simulateur JSIM, il faut avoir Java Development Kit (JDK)

téléchargé depuis le site web de la société Sun Microsystems. La version utilisée

pendant la réalisation de notre projet est JDK 1.4.

Etape 2 - Téléchargement de J-SIM version1.3 en utilisant le lien : http://j-sim.cs.uiuc.edu

Etape 3 - L’installation du JSIM se fait sur deux sous étapes:

1. On décompresse le package J-Sim_v1.3.tar. On obtient par la suite le dossier jsim-1.3.

2. On modifie le fichier « setcpath.bat » trouvé dans racine J-Sim comme suit :

- On affecte à la variable %J_SIM% le chemin d’installation du simulateur JSIM



117

- On affecte à la variable % JAVA_HOME % le chemin d’installation de JDK 1.4

- On initialise % ANT_HOME % au chemin d’installation du compilateur Apache Ant mais

si on a choisit de compiler les codes sources du simulateur JSIM avec la commande « make »,

on doit donc ajouter le chemin d’installation de à la variable %PATH%.

- On ajoute à la variable %CLASSPATH% le chemin vers les classes du simulateur JSIM.

Figure.B. 2 Le contenu de fichier « setcpath.bat »

Etape 4 - La compilation de code source de JSIM sera faite soit par Apache Ant, soit par la

commande « make »

Tableau. B.3. les deux compilateurs utilisé avec J-Sim : Apache Ant et make

Apache Ant make

- Télécharger en consultant le site suivant:

http://ant.apache.org/

- Les commandes utilisées :

ant compile compile le sources modifiés.

ant clean supprime les fichiers compilé.

ant run lance le simulateur

- On doit installer l’utilitaire GNU-Make

makefiles in Java. Cet utilitaire permet

d’installer des commandes propres aux

LINUX sous WINDOWS :

make compile les sources modifiées.

make clean supprime les fichiers compilé.

Etape5 – Lancer une simulation

Vous devez avoir une fenêtre pop up intitulé TCL0 qui apparait en tapant la commande

suivante: java drcl.ruv.System.

@echo off set JAVA_HOME=C:\JBuilder8\jdk1.4 set J_SIM=c:\jsim-1.3\jsim-1.3 set ANT_HOME=c:\jsim-1.3\jsim-1.3\apache-ant-1.7.0 set classpath=%J_SIM%\classes;%J_SIM%\jars\tcl\tcl\lang;%J_SIM%

\jars\jython.jar;%java_home%\bin;%ANT_HOME%\lib;%J_SIM%\jsim-1.3\jacxp;%J_SIM%\jsim-1.3\crisom;%J_SIM%\jsim-1.3\jacxp;

ant run


http://ant.apache.org/


118

Figure.B. 3 Fenêtre principale de JSIM

Si on a utilisé Ant Apache, le simulateur et lancé par l’appel de commande « ant run » qui

doit être tapé dans l’invité de commande ou bien inséré à la fin de fichier « setcpath.pat »

comme illustré dans la figure B.2.

Etape 6 – simulé un fichier script

Chaque fois que vous désirez simuler un script TCL, vous devez soit changer le chemin

courant vers où est placé votre script, puis vous tapez la commande suivante : java

drcl.ruv.System «nom_fichier_script.tcl », ou bien parcourir le chemin de fichier script en

utilisant le menu de TCL0 « File/ Open»


119

Bibliographie

[1] Ian F. Akyilidiz,Tommaso Melodia, Kaushik R. Chowdury, « Wireless Multimedia

Sensor Networks: A SURVEY » IEEE Wireless Communications, December 2007 [2]. Giuseppe Anastas, Marco Conti, Mario Di Francesco, Andrea Passarella “An adaptive

and low-latency power management protocol for wireless sensor networks” pp 67 - 74 ACM 2006.

[3]. Radu Stoleru, Tian He, John A. Stankovic “Walking GPS: A Practical Solution for Localization in Manually Deployed Wireless Sensor Networks”University of Virginia

[4]. Mo Li, Baijian Yang “ A Servey On topology issues in Wireless Sensor Network” [5]. Jeremy Elson, Kay Romer “WSN A New regime for Time Synchronisation” In

processing of the first Workshop on Hot Top4ics in Networks 28-29 Oct 2002 . [6]. www.xbow.com [7]. Man Wah Chiang, Zeljko Zilie, Katarzyna Radeckja & Jean-Samuel Chernard”

Architectures of Increased Availability WSN nodes”. ITC INTERNATIONAL TEST CONFIRENCE IEEE 2004.

[8] K. Kalpakis, K. Dasgupta and P. Namjoshi, “Maximum lifetime data gathering and aggregation in wireless sensor networks,” in the Proceedings of IEEE International Conference on Networking (NETWORKS '02), Atlanta, GA, August 2002.

[9] K. Akkaya and M. Younis, “An Energy-Aware QoS Routing Protocol for Wireless Sensor Networks,” in the Proceedings of the IEEE Workshop on Mobile and Wireless Networks (MWN 2003), Providence, Rhode Island, May 2003.

[10]. Mohammad Z Ahmad and Damla Turgut, “ Congestion avoidance and fairness in wireless sensor networks” School of Electrical Engineering and Computer Science, University of Central Florida Orlando, Florida 32816-23620.

[11]. A. Mainwaring, Polastre, Robert Szewczyk, David Culler et John Andersom “ Wireless Sensor Networks for Habitat Monitoring”, ACM 2002.

[12]. Site Web: fr.wikipedia.org [13]. M. Cardei, D. MarCallum, M. Xiaoyan, M. Min, X. Jia, D. Li & Ding-Zhu Du,

“Wireless Sensor Networks with Energy Efficient Organization”, Journal of Interconnection Networks, Vol. 3 (2002) p2 13-229.

[14]. Liang Yuan Weidong Chen Yugeng Xi « A Review of Control and Localization for Mobile Sensor Networks » Proceedings of the 6th World Congress on Intelligent Control and Automation, June 21 - 23, 2006, Dalian, China. IEEE 2006

[15]. LAN-MAN Standards Committee of the IEEE Computer Society, 802.15.4 IEEE Standard for Information technology, Part 15.4: Wireless Medium Access Control & Physical Layer. Specifications for Low-Rate Wireless Personal Area Networks, Std 802.15.4-2003.

[16]. Ian F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci "A Survey on Sensor Networks ", IEEE Communications Magazine, Vol. 40, pp. 102-116, Août 2002.

[17]. I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci “Wireless sensor networks: a survey” Computer Networks 38 (2002) 393–422

[18]. J. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, M. B. Srivastava “ Participatory Sensing” SenSys ’06, 2006 ACM.


http://www.xbow.com/

120

[19]. E. Shih et al., “Physical Layer Driven Protocol and Algorithm Design for Energy-Efficient Wireless Sensor Networks,” Proc. ACM MobiCom ’01, Rome, Italy, Juillet 2001.

[20]. Y. Yu, R. Govindan & D. Estrin, « Geographical and Energy Aware Routing A Recusive Dta Dissemination Protocol for Wireless sensor Networks », Computer Science Departement UCLA 2001.

[21] Alexandre Delye de Mazieux, Vincent Gauthier, Michel Marot, and Monique Becker. État de l’art sur les réseaux de capteurs. INT 05001RST, avril 2005

[22]. S. Ratnasamy, B. Karp, S. Shenker, D. Estrin, R. Govindan, L. Yin, and F. Yu. “Data centric storage in sensornets with a geographic hash table”. Mobile Networks and Applications, 8(4):427–442, 2003.

[23]. T. R. M. Braga, F. A. Silva, L. B. Ruiz, J. Marcos S. Nogueira, A. A. F. Loureiro “ Design and Evaluation of an Autonomic Sensor Element” 1st Latin American Autonomic Computing Symposium, LAACS 2006

[24]. Kephart, J. O. and Chess, D. M. « The vision of autonomic computing ». IEEE Computer 2003.

[25]. www.sunspotworld.com/docs/ [26]. C. Intanagonwiwat, R. Govindan, D. Estrin, “Directed Diffusion: A Scalable and

Robust Communication Paradigm for Sensor Networks”. Proceedings of the SixthAnnual International Conference on Mobile Computing and Networking, Boston, MA, USA, 2000, pp. 56–67.

[27]. C. Karlof, N. Sastry, D. Wagner. « TinySec: A Link Layer Security Architecture for Wireless Sensor Networks ». ACM SenSys , Nov 2004.

[28]. Mihaela Cardei, Jie Wu. “Energy-efficient coverage problems in wireless ad-hoc sensor networks”. Computer Communications 29 (2006) 413–420.

[29]. A. Manjeshwar and D. P. Agrawal, "TEEN : A Protocol for Enhanced Efficiency in wireless Sensor Networks," 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing, San Francisco, CA, April 2001.

[30]. W. R. Heinzelman, A. Chandrakasan, and H. Balakrishnan “Energy-efficient communication protocol for wireless microsensor networks” in IEEE Hawaii International Conference on Systems Sciences, 2000.

[31]. J. Heidemann, F. Silva, C. Intanagonwiwat, R. Govindan, D. Estrin, and D. Ganesan. Building efficient wireless sensor networks with low-level naming. In Proceedings of the 18th ACM Symposium on Operating Systems Principles, pages 146–159, ACM Press, 2001.

[32]. http://www.tinyos.net [33]. J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture

directions for network sensors. In Proceedings of the 9th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOSIX), pages 93–104, Cambridge, Massachusetts, November 2000.

[34]. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan, and S. Shenker. Ght: A Geographic hash table for data-centric storage. In Proceedings of the 1st ACM International Workshop on Wireless Sensor Networks and Applications, pages 78–87, ACM Press, 2002.

[35]. Ed Callaway, Paul Gorday, Lance Hester, Jose A. Gutierrez , Marco Naeve, Bob Heile, Venkat Bahl “Home Networking with IEEE 802.15.4:A Developing Standard for Low-Rate Wireless Personal Area Networks” IEEE Communications Magazine, Aout 2002.


121

[36]. X. Bai, S. Kumar, D. Xuan, Z Yun, Ten H. Lai “Deploying Wireless Sensors to Achieve Both Coverage and Connectivity” MobiHoc ACM2006.

[37]. Prosenjit Bose, Pat Morin, Ivan Stojmenovic, and Jorge Urrutia. Routing with guaranteed delivery in ad hoc wireless networks. Wireless Networks, 7(6) :609–616, 2001.

[38] Ivan Stojmenovic and Xu Lin. Power-aware localized routing in wireless networks. IEEE Transactions on Parallel and Distributed Systems, 12(11) :1122–1133, 2001.

[39]. Kuruvila, Nayak, and Stojmenovic. Progress based localized power and cost aware routing algorithms for ad hoc and sensor wireless networks. International Journal of Distributed Sensor Networks, 2(2) :147–159, 2006.

[40]. P. Jacquet, P. Mühlethaler, T. Clausen, A. Laouiti, A. Qayyum, and L. Viennot. Optimized link state routing protocol for ad hoc networks. In Proceedings of the 5th IEEE Multi Topic Conference (INMIC 2001).

[41]. Clément Saad, Abderrahim Benslimane, Jean-Claude Konig, and Jacques Turbert. At-free : A preliminary method for localization techniques in sensor networks. 7th International Conference on New Technologies of Distributed Systems, 2007.

[42]. Clément Saad, Abderrahim Benslimane, and Jean-Claude König. At-dist : A distributed method for localization with high accuracy in sensor networks. Special Issue on "Wireless Ad Hoc and Sensor Networks" in the international journal Studia Informatica Universalis (To Appear), 2007.

[43]. D. Niculescu and B. Nath. « Ad hoc positioning system ». In Proc. IEEE GlobeCom, San Antonio, AZ, November 2001.

[44]. Gaurav Jolly, Mustafa C. Kuçu, Pallavi Kokate, and Mohamed Younis “Low-Energy Key Management Protocol for Wireless Sensor Networks” Proceedings of the Eighth IEEE International Symposium on Computers & Communication (ISCC’03) 1530-1346/03 2003.

[45]. D. Brinsky, D. Estin, « Rumor routing algorithm for sensor networks », Proceeding of the First workshop on Sensor Network and Applications (WSNA) , Atlanta, GA, October 2002.

[46]. Xu, X., Heidemann, D. Estrin. « Geography informed Energy Conservation for Ad Hoc Routing ». In Proceeeding of MobiCom 01, Rome (2001) 16-21.

[47]. W. Heinzelman, A. Chandrakasan, & H.Barakrishman, “An application specific protocol architecture for wireless microsensor networks” IEEE Transactions on wireless communications, vol 1, no 4 2002.

[48]. Julien Cartigny “ Contribution à la diffusion dans les réseaux ad-hoc ”, thèse de doctorat, université des sciences et technologies Lille 2003.

[49]. Site web de RFC :http://rfc-editor.org. [50]. E. Decker, P. Langille, A. Rijsinghani. and K. McCloghrie. “Definitions of managed

objects for bridges”. RFC1493, July 1993 [51]. J. Case, M. Fedor, M. Schoffstall, J. Davin “A Simple Network Management Protocol

SNMP” RFC 1157, Network Working Group SNMPv2. may 1990. [52]. J. Case, K. McCloghrie, M. Rose, S. Waldbusser “Protocol Operations for V2 of the

Simple Network Management Protocol (SNMPv2)”. RFC1905, Janvier 1996. [53]. RFC 1213 , K. McCloghrie, M. Rose “ Management Information Base for Network

Management of TCP/IP-based internets: MIB-II “ Mars 1991. [54]. U. Warrier, L. BesawL. LaBarre, B. Handspicker The Common Management

Information Servicesand Protocols for the Internet (CMOT and CMIP) RFC 1189. October 1990.


122

[55]. K. McCloghrie, M. Rose “Management Information Base for Network Management of TCP/IP-based internets” RFC 1156, May 1990.

[56]. M. Rose, K. McCloghrie « Structure and identification of Management information for TCP/IP-based internets » STD 16, RFC 1155, May 1990.

[57]. D. Harrington, R. Presuhn, B. Wijnen “An Architecture for Describing SNMP Management Frameworks” RFC 2271, January 1998.

[58]. R. Presuhn, J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “ Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) RFC3418, December 2002.

[59]. H. E. Hia , S.F. Midkiff, "Securing SNMP Across Backbone Networks," International Conference on Communications and Computer Networks, Scottsdale, AZ, Oct. 2001, pp. 190 -196.

[60]. Juirgen Schdnwdlder, Aiko Prast, MatWs Harvan, Jorrit Schipperst, Remco van de Meentt. “SNMP Trafic Analysis: Approaches, Tools, and First results” IEEE 2007.

[61]. Mongi Abdelmoula, Neha Jha, Ashok Anand —Isabelle Astic “Implementation of IP-MIB Modules for IPv4 and IPv6 Protocol” INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE. Octobre 2002.

[62] K. McCloghrie, D. Perkins, J. Schoenwaelder, TU Braunschweig “Structure of Management Information Version 2 (SMIv2) “RFC: 2578 - STD: 58 April 1999.

[63]. R. Frye, D. Levi, S. Routhier, B. Wijnen “Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework” RFC: 2576, mars 2000.

[64]. F. Strauss, TU Braunschweig, J. Schoenwaelder “Next Generation Structure of Management Information (SMIng), Mappings to the Simple Network Management Protocol (SNMP) RFC 3781, Mai 2004.

[65]. Site web: www.net-snmp.org. [66]. Site web: www.Adventnet.com. [67]. SNMP4J. www.sunspotworld.com/docs/ [68]. A. Bierman, D Romascanu and K.C. Norseth “Entity Sensor Management Information

Base“ RFC 3433 December 2002. [69]. John Larmouth “ASN.1 Complete”, Open Systems Solutions, May 1999. [70]. Ranganai Chaparadza “On designing SNMP based monitoring systems supporting

ubiquitous access and real-time visualization of traffic flow in the network, using low cost tools” IEEE 2005.

[71]. W. Louis Lee, A. Datta, R. Cardell-Oliver « Network Management in WSN » university of Software Engineering 2006.

[72]. H. Song, D. Kim, K. Lee, J. Sung, “Upnp-Based Sensor Network Management Architecture,” in Proc. ICMU Conf., Avril 2005.

[73]. L.B. Ruiz, L.B. Oliveira, J.M. Nogueira, A.F. Loureiro « MANNA: A Management Architecture for Wireless sensor Networks » IEEE Communication Magazine. Février. 2003.

[74]. C. Fok, G. Roman, and C. Lu, “Mobile Agent Middleware for Sensor Networks: An Application Case Study,” in Proc. IEEE ICDCS Conf., June 2005.

[75]. M.W. Chiang, Zeljko Zilie, Katarzyna Radeckja & Jean-Samuel Chernard” Architectures of Increased Availability WSN nodes”. ITC INTERNATIONAL TEST CONFIRENCE. 2004.

[76]. C IIzsin and Mliu “ A Two-Phase self –Monioring Mechanism for WSN” Journal of computer Communications special issue on sensor Network . vol 29 N°1 pp462-476, 2006.


http://www.net-snmp.org/

http://www.adventnet.com/

http://www.sunspotworld.com/docs/

123

[77]. Syed Shariyar, Murtaza, syed, Obaid Amin, Choon Seon Hong. “Application of SNMP in Ubiquitous Environment” KNOM Review. Vol. 8, No2 Fevrier 2006.

[78]. Hongseok Jang, Kugsang Jeong , Deokjai Choi. “Delivery & Storage Architecture for sensing information using SNMP”. IJCSNS International Journal of Computer Science & Network Security, VOL 6 N°4. Avril 2006.

[79]. W. Heinzelman, “Application specific protocol architectures for wireless networks”, PhD Thèse, MIT, 2000.

[80] W.Liang, Haibin Yu, Penz Zeng & Chang Che, « BESM : A Balancing Energiy-aware Sensor Management Protocol for Wireless Sensor Network. International Journal of Information, Vol 12 No4, 2006.

[81] Ye f G. Zeng, J Cheng, S. Lu & L. Zhang. “PEAS: A Robust Energy Conserving Protocol for Long-lived Sensor Network”, proceedings of the Tenty Third International Conference on Distributed Computing System 2003.

[82] T.H Kim & S. Hong, “ Sensor Network Management Protocol for State Driven Execution Environment” in proc. ICUC CONF, Octobre 2003.

[83]. A.Boulis “Network management in realms: wireless sensor network” International Journal of Network Management, 2005.

[84]. M. Turon, “MOTE-VIEW: A Sensor Network Monitoring and Management Tool”, In Proc. IEEE EmNetS-II Workshop, mai 2005.

[85]. N. Ramanathan & M. Yarvis, “A Stream oriented Power Management Protocol for low duty cycle sensor network applications”; In Proc.IEEE emnetS-II Workshop, Mai 2005.

[86]. S. Lindsey and C. S. Raghavendra, "PEGASIS: Power Efficient GAthering in Sensor Information Systems", IEEE Aerospace Conference, Big Sky, Montana, USA, pp. 1125-1130, Mars 2002.

[87]. A. Boulis & M.B. Srivastava “Node level Energy Management for Sensor Networks in the Presence of Multiple Applications”, IEEE2003.

[88]. Lei Shu, Chun Wu, Yan Zhang, Jiming Chen, Lei Wang, Manfred Hauswirth “ NetTopo: Beyond Simulator and Visualizer for Wireless Sensor Networks”, Second International Conference on Future Generation Communication and Networking, pp17-20, 2008.

[89]. N. Ramanthan, K. Chang, R. Kapur, L. Girod, E. Kohlor and D. Estrin “Sypmathy for the Sensor Network Debugger” ACM, Sensys 05 Novembre 2005.

[90]. A. Woo, T. Tong, D. Culler. “Taming the underlying challenges of reliable multihop routing in sensor networks”. In Proc. senSys, 2003.

[91]. Y. Yang Lim, M. Messina, F. Kargl, L. Ganguli, M. Fischer, T. Tsang “SNMP-proxy For Wireless Sensor Network” IEEE computer society 2008.

[92]. SNMP4J, “SNMP API for Java Managers & Agents” www.snmp4j.org. [93]. L.B. Ruiz, I.G. Siqueira, L.B. Oliveira, J.M. S. Nogueira, A.A.F. Loureiro « Fault

Management in Event-driven Wireless sensor Networks » ACM 2004. [94]. W. Chen N.Jain, S. Singh. “ANMP Ad hoc network management protocol”, 1999. [95]. Raquel A.F. Mini, Antonio A.F. Loureiro, Badri Nath “The distinctive design

characteristic of a wireless sensor network: the energy map”. Elsevier Computer Communications 27 (2004) p935–945.

[96] J.-H. Chang and L. Tassiulas, "Maximum Lifetime Routing in Wireless Sensor Networks," in the Proceedings of the Advanced Telecommunications and Information Distribution Research Program (ATIRP'2000), College Park, MD, March 2000.

[97]. siteweb :www.berkeley.edu.


http://www.berkeley.edu/

124

[98]. B. Deb, S. Bhatnagar & B. Nath, “A Topology Discovery Algorithm for Sensor Networks with Applications to Network Management”, Tech. Rep. DCS-TR-111, Rutgers University, Mai 2001.

[99]. B. Deb, S. Bhatnagar, B. Nath, “STREAM: Sensor Topology Retrieval at Multiple Resolutions”, Kluwer Journal of Telecommunications Systems, vol.26, no.2, pp 285-320, 2004.

[100]. C-Y. Wan, S.B. Eisenman, A.T. Campbell, and J. C rowoerof, “Siphon: Overload Traffic Management using Multi-radio Virtual Sinks in Sensor Networks”. In Proc. ACM SenSys Conf, Nov 2005.

[101]. J. Zhang, E.C Kulasekere, K. Premaratne, and P.H. Bauer, “Ressource Management of Task Oriented Distributed Sensor Networks”, InProc. IEEE ICASSP Conf. Mai 2001.

[102]. B.Deb, S. Bhatnagar, and B. Nath, “Wireless Sensor Networks Management” http://www.Research.rutgers.edu/ bdeb/sensor_networks.html, 2005.

[103]. Z. Ying and X. Debao, “Mobile Agent-based Policy Management for Wireless Sensor Networks,” In Proc. IEEE WCNM Conf., Sep. 2005.

[104]. W. Heinzelman, J. Kulik, and H. Balakrishnan, "Adaptive protocols for information dissemination in wireless sensor networks", 5th Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom’99), Seattle, USA, pp.174-185, Août 1999.

[105]. C. Perkins, E. Belding-Royer, S. Das, Ad hoc On-Demand Distance Vector (AODV) Routing, RFC3561, IETF, Juillet 2003.

[106]. B. Khélifa. « Approche Théorie des Graphes pour la Surveillance d’un Réseau de Capteurs sans fil » thèse de magistère université d’Oran Es-sénia 2007.

[107]. A. Ghosh & T. Givargis “LORD: A Localized, Reactive and Distributed Protocol for Node Scheduling in Wireless Sensor Networks” Proceedings of the Design, Automation and Test in Europe Conference and Exhibition 2005.

[108]. T. He, J. A. Stankovic, C. Lu, T. F. Abdelzaher., "SPEED: A stateless protocol for realtime communication in sensor networks", International Conference on Distributed Computing Systems (ICDCF’03), Providence, Rhode Island, USA, pp.533-532, Mai 2003.

[109]. T. R. M. Braga, F. A. Silva, L. B. Ruiz, J. Marcos S. Nogueira, A. A. F. Loureiro “Design and Evaluation of an Autonomic Sensor Element” 1st Latin American Autonomic Computing Symposium, LAACS 2006.

[110]. Kephart, J. O. & Chess, D. M. “The vision of autonomic computing”. IEEE Computer 2003.

[111] S. Hedetniemi and A. Liestman, “A survey of gossiping and broadcasting in communication networks,” Networks, Vol. 18, No. 4, pp. 319-349, 1988.

[112]. C. Hsin and M. Liu, “A Two-Phase Self-Monitoring Mechanism for Wireless Sensor Networks,” Journal of Computer Communications special issue on Sensor Networks, vol. 29, no. 4, pp. 462–476, 2006.

[113] A. Erdogan, E. Cayirci, and V. Coskun, “Sectoral Sweepers for Sensor Node Management and Location Estimation in Adhoc Sensor Networks,” in Proc. IEEE MILCOM Conf., Oct. 2003.

[114]. You-Sun Hwang, Eung-bae Kim “An Architecture of SNMP-based Network Management of the Broadband Wireless Access System” p1163- 1166. IEEE - 2003.

[115]. J. Kantorovitch, P. Mähönen “Case studies and experiments of SNMP in wireless networks” IEEE – 2002.

[116]. Denis Lapoire « cours de graphes et algorithmes » janvier 2007.


125

[117]. P. Bose, A. Chan, F. Dehne, and M. Latzel “ Coarse Grained Parallel Maximum Matching In Convex Bipartite Graphs” , in Proc . 13th International Parallel Processing Symposium (IPPS’99), Puerto Rico, 1999, 99. 125-129.

[118]. L. Li and J. Y Halpern, “Minimum energy mobile wireless networks revisited,” in the Proceedings of IEEE International Conference on Communications (ICC’01), Helsinki, Finland, June 2001.

[119]. Michel Habib. « Notes de cours Algorithmique de graphes: Magistère Informatique, Cachan » http://www.liafa.jussieu.fr/~habib. 26 novembre 2009

[120]. J. Lessmann, P. Janacik, L. Lachev, D. Orfanus « Comparative Study of Wireless Sensors simulators » 7th International Conference on Networking 2008 IEEE.

[121] A. Sobeih, W.P. Chen, J. C. Hou, Lu.C. Kung, N. Li H.Y. Tyan, H. Zhang “J-Sim: A Simulation and Emulation Environment for Wireless Sensor Network” 2004.

[122] J-Sim Home page : http://sites.google.com/site/jsimofficial/. [123]. Esteban Egea-Lopez, Javier Vales-Alonso, Alejandro Martinez-Sala, Pablo Pavon-

Mariño, Joan Garcia-Haro "Simulation Scalability Issues in Wireless Sensor Networks". IEEE Communications Magazine, July 2006.

[124]. D. B. Johnson, D. A. Maltz, "Dynamic Source Routing in Ad Hoc Wireless Networks", Mobile Computing, Imielinski and Korth, Eds, Kluwer Academic Publishers, Vol. 353, pp. 153–181, 1996.

[125]. Pei, Guangyu, Gerla, M. and Chen, Tsu-Wei. “Fisheye state routing : a routing scheme for ad hoc wirelessnetworks”. IEEE International Conference on Communication 00, Vol.1, pp 70-74.

[126]. A.M. D. Agrawal. “APTEEN : A Hybrid Protocol for Efficient Routing and Comprehensive Information Retrieval in Wireless Sensor network” In IEEE Proceeding 15th International, pages 195-202, April 2002.

[127].Z. Haas, M. Pearlman, “ The Zone Routing Protocol (ZRP) for Ad Hoc Networks ”,IETF MANET working group Internet draft, 1999.

[128]. V. Rodoplu and T.H. Ming, "Minimum energy mobile wireless networks," IEEE Journal of Selected Areas in Communications, Vol. 17, No. 8, pp. 1333-1344, 1999.

[129]. N. Ramanathan , Rosales-Hain , “Topology Control of Multihop Wireless Networks Using Transmit Power Adjustment”, Proceedings IEEE Infocom 2000, Tel-Aviv, Israel, p. 404-413, 26-30 mars, 2000.

[130] R. Tynan, D. Marsh, D. OKane, and G. M. P. OHare, “Agents for Wireless Sensor Network Power Management,” in Proc. IEEE ICPPW Conf., June 2005.

[131] E. Lloyd, Liu R. M. Marathe, R.Ramanathan , S. Ravi, Algorithmic Aspects of Topology Control Problems for Ad Hoc Networks, Proceedings ACM International Symposium on Mobile Ad Hoc Networking and Computing MOBIHOC 2002), Lausanne, Switzerland, p. 123-134, 9-11 juin, 2002.

[132] G. Tolle and D. Culler, “Design of an Application- Cooperative Management System for Wireless Sensor Networks,” In proceedings . EWSN, Feb. 2005.

[133] Muhammad Mahbub Alam, Md. Mamun-Or-Rashid and Choong Seon Hong, “WSNMP: A Network Management Protocol for Wireless Sensor Networks”, In the proceedings In the proceedings of 10th ICACT, pp. 742-744, Feb 17-20, 2008.


http://www.liafa.jussieu.fr/~habib

126


Documents

DEPARTEMENT D'INFORMATIQUE MEMOIREtheses.univ-oran1.dz/document/TH3233.pdfRésumé iii Résumé Maximiser la durée de vie d ˇun réseau de capteurs sans fil (RCSF) est un défi de