Universit dAvignon

master 1 informatique

Implmentation dun protocole de routage dans un rseau de capteurs sans-fils

L.Daumas, O.Uberti Encadrants : A.Benslimane 15 juin 2008

1

Remerciements
Nous tenons remercier nos encadrants F.FEZZI et A.BENSLIMANE pour toute laide apporte. Nous tenons galement remercier lIUP dAvignon de nous avoir prt le matriel ncessaire ainsi quune salle pour pouvoir faire notre projet.

Table des matires

Universit dAvignon................................................................1

Remerciements..............................................................2 Table des matires.........................................................3 Introduction...................................................................5 Chapitre 1......................................................................7 Prsentation des Rseaux de capteurs sans-fil...............7 TinyOS et NesC............................................................9
Les capteurs ............................................................................9 Architecture dun capteur.......................................................10 Le systme dexploitation TinyOS ..........................................11 Prsentation.........................................................................11 Proprits.............................................................................11 Allocation de la mmoire........................................................12 Allocation des ressources :......................................................12 Simulation : TOSSIM et TinyViz .............................................13 Le simulateur TOSSIM ...........................................................13 TinyViz.................................................................................13 Outils dintgration Crossbow................................................14 MoteWorks...........................................................................14 Mote config...........................................................................16 MoteView.............................................................................17 Xsniffer ...............................................................................17 NesC.......................................................................................18 Les Principales caractristiques de NesC....................................18

Chapitre 2.................................................................... 22 Gestion du projet......................................................... 22 Contraintes................................................................ 22

Cot........................................................................................22 Matriels.................................................................................22 3. Travail de groupe................................................................22

Prsentation des acteurs et de leurs responsabilits. .23 Mthodologie de conception de suivie........................24 Prvisions et ralit.................................................. 25
Prvision ................................................................................25 Ralit....................................................................................26

Chapitre 3.................................................................... 27 Protocoles de routages et techniques de localisation dans un rseau de capteurs..........................................27 Protocole AODV .........................................................27 Protocoles de localisation ..........................................30
RSSI ...................................................................................30 Time Of Arrivals ...................................................................31 3

Angle of Arrival.....................................................................31

Chapitre 4.................................................................... 32 Algorithme et phase de test.........................................32 Conclusion................................................................... 35 Diagramme de Gantt.................................................... 37 Bibliographies.............................................................. 38

Introduction
Le groupe travaillant sur le projet Capteur est compos de deux tudiants, DAUMAS Laurent et UBERTI Olivier. Le groupe est supervis par le tuteur Mr BENSLIMANE Abderrahim. Nous souhaitions aborder un sujet orient tlcom et rseaux dans lequel nous pouvions aborder beaucoup daspect diffrents, que cela soit la technologie sans fil, les protocoles de routages, les systmes de transmissions,... Dans la vie courante, lutilisation des capteurs sans fil est de plus en plus demande pour la supervision et la scurit. Les industries proposent alors des capteurs sans fil qui peuvent renseigner lutilisateur sur plusieurs donnes. Ces capteurs peuvent aussi tre relis ensemble pour former un rseau sans fil se basant sur des protocoles pour se communiquer et proposant des programmes et des rseaux embarqus. Les capteurs fonctionnent donc basse tension et ceci est gr par un systme dexploitation spcialis : TinyOS. Il est le systme actuellement le plus utilis dans les applications ncessitant des capteurs. Enfin, pour le dveloppement des applications lgres, il nexiste actuellement quun langage de programmation capable dinteragir avec le systme d'exploitation TinyOs : NesC. Ce langage ddi est proche du C traditionnel mais il est orient composants. Les capteurs sont des dispositifs de taille extrmement rduite avec des ressources trs limites, autonomes, capable de traiter des informations et de les transmettre, via les ondes radio, une autre entit (capteurs, unit de traitements...) sur une distance limite quelques mtres. Les rseaux de capteurs utilisent un trs grand nombre de ces capteurs pour former un rseau sans infrastructure tablie. Un capteur analyse son environnement, et propage les donnes rcoltes aux capteurs appartenant sa zone de couverture. Chaque capteur relayant l'information sur sa propre zone de couverture, le rseau se trouve entirement couvert. Nous prenons en charge la suite des projets portant sur les capteurs sur lequel les tudiants des annes prcdents ont travaill. Ils ont cr un espace de travail dans les locaux de l'IUP avec des postes de travail configurs pour travailler directement sur les capteurs. Ils ont ainsi mis en place un programme permettant de localiser les capteurs environnants et dvelopp une interface JAVA permettant de localiser les capteurs sans fils.

Le but du projet capteur est darriver crer un rseau de capteur sans fil, et si possible d'identifier des capteurs rentrant dans notre rseau et de retracer une route de manire automatique. Les capteurs devront donc communiquer entre eux afin de schanger des donnes travers un protocole de routage que nous dvelopperons. Nous prsenterons dans un premier temps les outils ncessaires pour faire de lintgration de protocole dans un rseau de capteurs et dans un deuxime temps le protocole mis en place ainsi que son implmentation en langage NesC.

Chapitre 1
Prsentation des Rseaux de capteurs

sans-fil
Lobjectif du projet de master est donc dimplmenter sur des capteurs un protocole de routage qui fera de la localisation dans un rseau de capteurs de type ad-hoc. Les capteurs sont des objets lectroniques capables de mesurer une grandeur physique (au sens large) : temprature, pression, pH, etc. Les modules MICAz sont des transmetteurs sans fil fonctionnant avec la technologie ZigBee, sorte de WiFi adapt aux appareils disposant de peu dnergie. Cest le cas de ces modules car ils sont aliments par piles. Les rseaux de capteurs sont utiliss dans de nombreux domaines tels que lindustrie, le btiment (capteurs sismiques), lcologie (contrle des polluants, du climat et des dsastres), le domaine mdical ou bien encore le militaire (surveillance). Cest une technologie en plein essor et qui a de trs nombreux dbouchs. Par exemple, si une organisation forestire sintresse la surveillance de son domaine forestier afin de dtecter le dpart dun incendie, les capteurs disperss dans le domaine savrent trs utiles pour faire remonter linformation jusquau point de contrle (voir figure 1.1). Le capteur X diffuse un message dalerte avec sa position qui est relay de proche en proche par les capteurs jusquau point de collecte des informations o lalerte peut tre donne. On estime le lieu de lincendie par rapport la position du capteur qui a lanc lalerte. Comme les ressources dun capteur sont trs limites, la ralisation dune application dpend entirement de la collaboration entre tous les capteurs qui excutent des tches simples.

Fig. 1.1 Un rseau de capteurs surveillant une fort

Un rseau de type ad-hoc est un rseau sans hirarchie entre les nuds et o les informations transitent de nud en nud pour atteindre leur destination. Il est modlis par un graphe (non orient) o chaque nud est ici un capteur et o chaque arte correspond un lien de communication ZigBee. En effet ZigBee est un protocole de haut niveau permettant la communication de petites radios, consommation rduite, base sur le standard IEEE 802.15.4 pour les rseaux dimension personnelle (Wireless Personal Area Networks : WPANs). Cette technologie a pour but la communication de courte distance telle que le propose dj la technologie Bluetooth, tout en tant moins chre et plus simple. titre dexemple, les nuds ZigBee classiques ncessitent environ 10 % du code ncessaire la mise en uvre de nuds Bluetooth ou de rseaux sans fil, et les nuds ZigBee les plus lmentaires peuvent ainsi descendre jusqu 2 %. Pour les rseaux de capteurs, les mesures doivent atteindre un nud particulier appel point de collecte (le centre forestier de la figure 1.1). Autrement dit, de tout nud du rseau, il doit exister un chemin vers le point de collecte. La localisation permet de construire une cartographie complte du rseau partir de la connaissance de la position de quelques nuds du rseau. Ces nuds particuliers portent le nom dancre. La cartographie complte dun rseau de capteurs est ncessaire car une mesure reprsente ltat dun point particulier. Or la localisation systmatique, par GPS ou manuellement, est une solution beaucoup trop coteuse. Quand il y a un vnement on veut savoir o il sest produit. De plus certains algorithmes de communication (routage, broadcast) utilisent aussi les positions. Trois techniques de localisations existent, deux algorithmes sont des volutions de la triangulation. La programmation ne peut pas tre effectue directement sur le module. Ils sont donc interfacs au PC via un port COM grce un autre module sur lequel ils senfichent : le MIB510CA (Crossbow). Les modules MICAz sont dots dun systme dexploitation, appel TinyOS, ainsi quun langage de programmation spcifique orient composant, le NesC. Il sont adapts au contexte capteur cest--dire un environnement industriel, avec des faibles capacits de traitement et une faible nergie embarque. Les outils de programmation (compilateur, chargeur, simulateur, etc.) sont bien entendu spcifiques. Loutil fourni avec les modules sappelle MoteWorks. Il existe galement des outils libres, sous forme dune distribution Ubuntu ddie : XubuntOS.

TinyOS et NesC
Les capteurs
Prsentation des capteurs utiliss :

MIB510CA : Carte dinterface srie pour la programmation de toutes les plates formes MICA. Elle possde deux connecteurs de 51 pins pour raccorder la carte aux capteurs.

MCS410 : Systme de localisation, destin surtout pour usage intrieur, fournis des informations de positionnement prcises, identification des espaces, coordonnes de position et dorientation. Cest un produit de recherches et dtudes. Sa prcision varie entre 1cm et 3 cm. Combine les technologies RF et dultrason, se monte sur les murs ou les plafonds et peut tre utilis en mission comme en rception.

Architecture dun capteur

Larchitecture des capteurs, en gnral, est commune pour tous. On peut voir sur la les diffrents composants qui constituent un capteur. o Mote, Processeur, RAM, Flash : On appelle Mote la carte physique utilisant le systme dexploitation. Le processeur est la base des calculs binaires. Les mmoires RAM et Flash servent pour le stockage, dfinitif ou non, des donnes. o Radio, Antenne : Afin dmettre, un capteur a besoin dune antenne et dune radio pour ajuster les frquences hertziennes. o LED, interfaces, capteur : Composants prvus pour mettre en place un rseau de capteurs. o Batterie : Indispensable pour lautonomie du capteur.

10

Le systme dexploitation TinyOS

Prsentation
TinyOS est le systme dexploitation open source pour les rseaux de capteurs sans-fil conu par luniversit amricaine de BERKELEY. Sa conception a t entirement ralise en NesC, langage orient composant qui se rapproche syntaxiquement du langage le plus connu : le C. TinyOS a t cr pour rpondre aux caractristiques et aux ncessits des rseaux de capteurs, telles que : Une taille de mmoire rduite. Une basse consommation dnergie. Des oprations dassistance intensive. Des oprations robustes. Il est optimis en termes dusage de mmoire et dnergie.

Proprits
Le plus gros avantage de TinyOS est quil est bas sur un fonctionnement vnementiel, cest--dire quil ne devient actif qu lapparition de certains vnements. Le reste du temps, le capteur se trouve en tat de veille afin de garantir une dure de vie maximale aux faibles ressources nergtiques du capteur. TinyOS se distingue aussi par son caractre non premptif, cest--dire quil ne gre pas les interruptions entre tches. Par contre il donne une priorit aux interruptions matrielles qui peuvent tout moment stopper lexcution dune tche. Pour terminer, TinyOS ne gre pas de temps rel car il nest pas prvu pour manipuler des niveaux de priorit, pour mieux respecter les chances, dans les tches. TinyOS est donc bas sur une structure `a deux niveaux de planification : Les vnements : ils sont utiliss pour raliser de petits processus (par exemple quand le compteur du ((timer)) arrive son terme). De plus ils peuvent interrompre les tches qui sont excutes. Les tches : les tches sont penses pour raliser une plus grande quantit de traitements et elles ne sont pas critiques dans le temps. Les tches sont excutes compltement, mais linitialisation et la terminaison dune tche sont des fonctions spares. 11

Allocation de la mmoire
Il est trs important daborder la faon avec laquelle un systme dexploitation gre la mmoire et plus spcialement quand celui-ci travaille dans un espace restreint. TinyOS ne ncessite pas beaucoup de place mmoire puisquil na besoin que de 300 `a 400 octets dans le cadre dune distribution minimale. Il est primordial davoir 4 Ko de mmoire libre qui se rpartissent entre les diffrents besoins suivant : La Pile : Elle sert de mmoire temporaire pour lempilement et le dpilement des variables locales. Les variables globales : Elles rservent un espace mmoire pour stocker des valeurs pouvant tre accessibles depuis diffrentes tches. La mmoire libre : Pour tout le reste du stockage temporaire. La notion dallocation dynamique de mmoire nest pas prsente dans le systme, ce qui simplifie limplmentation mais, par ailleurs, il nexiste pas de mcanisme de protection de la mmoire, ce qui rend le systme plus vulnrable au crash et aux corruptions de mmoire.

Allocation des ressources :

Lordonnanceur

Le choix dun ordonnanceur dtermine le fonctionnement global du systme et le dote de proprits telles que la capacit fonctionner en temps rel. Lordonnanceur TinyOS se compose de : 2 niveaux de priorits (bas pour les tches, haut pour les vnements). 1 file dattente FIFO (disposant dune capacit de 7).

On a un niveau de priorit entre les tches leur permettant de se classer. Lors de larrive dune nouvelle tche, celle-ci sera place dans la file dattente en fonction de sa priorit. Dans le cas o la file dattente est pleine, la tche dont la priorit est la plus faible est enleve de la file FIFO. Les tches

Elles sont utilises pour effectuer la plupart des blocs dinstructions dune application. A lappel dune tche, celle-ci va prendre place dans une file dattente de type FIFO (First In First Out) pour y tre excute. Une 12

tche active sexcute entirement car il ny a pas de mcanisme de premption. Lorsque la file est vide, le systme met en veille le dispositif jusquau lancement de la prochaine interruption. Les vnements

Ils sont prioritaires par rapport aux tches et peuvent interrompre la tche en cours dexcution. Ils permettent de faire le lien avec les interruptions matrielles. Plates-formes sous TinyOS TinyOS est prvu pour fonctionner sous plusieurs plates-formes comme Windows (2000 et XP) ou bien GNU/Linux. Deux principales versions de TinyOS sont disponibles : la version stable (V. 1.1.15) et La version en dveloppement (V. 2.0.2) qui ncessite linstallation de lancienne version pour fonctionner.

Simulation : TOSSIM et TinyViz

Le simulateur TOSSIM
Afin de simuler le comportement des capteurs, un outil trs puissant a t dvelopp et propos sous le nom de TOSSIM. Ce dernier est souvent utilis avec une interface graphique (TinyViz) pour une meilleure comprhension et visualisation de ltat du rseau. Lutilisation de ces deux logiciels est immdiate ds lors que TinyOS est oprationnel.

TinyViz
Loutil TinyViz est une application graphique qui nous permet davoir un aperu de notre rseau sans avoir dployer les capteurs dans la nature. Une conomie deffort et une prservation du matriel sont possibles grce cet outil. Lapplication permet une analyse tape par tape en activant les diffrents modes disponibles.

13

Outils dintgration Crossbow

Afin de travailler de faon optimale sur les capteurs il est ncessaire davoir une plate forme de travail Windows accueillant les outils de travails ddis aux capteurs. Le fabricant Crossbow fournit ces logiciels

MoteWorks
MoteWorks possde comme environnement de dveloppement pour le NesC une version simplifie de Programmers Notepad. Cet environnement permet de crer, compiler et charger des applications en NesC sur les Motes. Cet environnement utilise une interface Cygwin comme console de commande. La compilation et le chargement dapplications se font par des commandes standardises simples. Pour toutes les applications on utilise les mmes commandes. Pour la compilation, en fonction de la plateforme processeur/radio que lon on a disposition, il suffit de slectionner dans la barre doutils make <platform>. Dans notre cas : make mica2 Lors du chargement dune application sous lenvironnement MoteWorks, aprs avoir lanc un Shell, on utilise une commande simplifie dans laquelle on prcise la plateforme Processeur/radio, la carte dinterface de programmation du mote et le port de communication. Dans notre cas cela donne : make mica2 install mib520,com7 Cette simplicit des commandes de compilation et de chargement permet un accs facile pour des personnes peu habitues la programmation. Ceci est intressant car un grand nombre dapplications est fourni par Crossbow. Il suffit de slectionner lapplication souhaite et de la traiter comme vu prcdemment. Par contre, cette simplicit des commandes ncessite un format pour les applications strict. A savoir, chaque application possde un rpertoire compos de 4 fichiers ncessaires : 1 2 1. Makefile 3 2. Makefile.component 4 3. Un fichier de configuration de lapplication 5 4. Un fichier contenant le module de lapplication

14

Makefile est le fichier qui est compil lors de la commande make, il fait appel dautres fichiers

Le fichier MakeXbowlocal contient les options de la carte de programmation, lidentifiant de groupe permettant de diffrencier des motes appartenant des rseaux diffrents, la slection de la bande radio et des canaux ainsi que la puissance dmission. Makefile.component dcrit haut niveau le composant de lapplication et le nom de la carte de capture. Ceci permet simplement dannoncer au compilateur que lon va utiliser les composants NesC prcompils de la carte afin dinitialiser ses capteurs.

Le fichier contenant la configuration de lapplication est le fichier Nom_application.nc. Dans ce fichier sont implments les composants qui interagissent entre eux dans lapplication, puis on dfinit comment ces composants sont lis :

Chaque application doit au moins contenir le composant Main et son module Nom_applicationM. Le composant Main est le premier tre excut et cest lui qui contrle les autres via les mthodes init(), start(), stop() communes chaque composant. Enfin on cre le module dans le fichier Nom_application.nc. Ce dernier contient le code de lapplication.

15

Mote config

Local Program : Le local programme est utilis pour uploader des progiciels sur les Motes travers la Gateway et la MIB520. La Gateway doit tre connect au PC par port USB ou port srie dans notre cas nous avons utilis la MIB520 port COM. Les motes devraient tre attach la Gateway et devraient tre tourn en OFF avant la programmation. Remote program : Cette option nous permet duploader une application sur les Motes distance.

La station de base (Gateway) doit tre programme par lapplication XMeshBase, Les autres Motes devront tre programms par le type de sensors board attache la mica2 travers la MIB520.

16

MoteView
Loutil MoteView fourni avec le kit Crossbow nous fournit en temps rel les Informations ncessaires suivant une topologie du rseau des capteurs reprogrammables.

On peut rcuprer des diffrents capteurs les informations transfres la station de base, qui envoie les donnes travers le port srie du PC connect. On rcupre alors la temprature, la luminosit, la position, lhumidit, les acclrations (suivant laxe des abscisses x et des ordonnes y) ainsi que ltat de la batterie. Chaque capteur est repr par un numro de Node et on peut slectionner diffrents capteurs pour avoir les informations et le mode de travail de chaque capteur connect.

Xsniffer
Xsniffer est un outil dvelopp par Crossbow qui permet aux utilisateurs de superviser la communication multi-sauts sous Xmesh. Ce programme sexcute sur un PC et utilise un MICAz pour la surveillance du trafic des paquets radio. Xsniffer peut tre utilis pour observer le comportement du rseau. Il affichera tous les messages radio transmis au sein du rseau. Xsniffer peut tre utilis pour vrifier si un mote a rejoint le rseau. Quand ceci arrive les paquets de vie et de donnes modifieront leur adresse de broadcast pour ladresse de la station de base ou celle dun autre lment du rseau.

17

NesC
Le langage NesC (network embedded system C) est un dialecte de C bas sur des composants. NesC est orient pour satisfaire les exigences des systmes embarqus. De plus, il supporte un modle de programmation qui agrge ladministration des communications, les concurrences provoquant les tches et les vnements ainsi que la capacit de ragir par rapport ces vnements. NesC ralise aussi une optimisation dans la compilation du programme, en dtectant les carrires possibles de donnes qui peuvent produire des modifications concurrentes au mme tat, lintrieur du processus dexcution de lapplication. Une carrire de donnes se produit quand plus dun fils peuvent simultanment accder la mme section de mmoire (concurrence daccs mmoire entre threads), et quand au moins lun des accs est un write. NesC simplifie aussi le dveloppement dapplications et rduit la taille du code un critre important dans limplmentation de code dans un capteur tant donn sa capacit de mmoire.

Les Principales caractristiques de NesC

NesC est constitu dinterfaces et de composants. Une interface peut tre utilise ou peut tre fournie. Les composants sont des modules ou des configurations. Architecture dune application NesC :

18

o Interface : Une interface peut tre utilise ou peut tre fournie. Les composants sont des modules ou des configurations. Une application est reprsente comme un ensemble de composants, regroups et rattachs entre eux. Les interfaces sont utilises pour les oprations qui dcrivent linteraction bidirectionnelle. Le fournisseur de linterface doit mettre en application des commandes, alors que lusager de linterface doit mettre en application des vnements. o Composant : Deux types de composants existent : Les modules, qui mettent en application des spcifications dun composant. Les configurations, qui se chargeront dunir diffrents composants en fonction des interfaces (commandes ou vnements). La figure suivante montre un diagramme de blocs dans lequel est dcrit le processus de compilation pour une application TinyOS crite en NesC : Processus de compilation :

19

Interface :

Ce type de fichier dclare les services fournis et les services qui seront utiliss. Ils se trouvent dans le rpertoire /tos/interface. Module :

Le type Module contient le code de lapplication, en mettant en uvre une ou plusieurs interfaces. Configuration :

Dans ces fichiers on dclare la manire dunir les diffrents composants et comment effectuer le contrle des flux. (exemple : Blink.nc). Composants :

TinyOS dfinit un nombre important de concepts qui sont exprims dans NesC. Dabord, les applications NesC sont construites par des composants avec des interfaces bidirectionnelles dfinies. Aussi, NesC dfinit un modle bas sur les tches et les captures dvnements matriels, et dtecte des clatements dinformation pendant la compilation. Un composant, du point de vue de la programmation, est compos de plusieurs sections et lensemble de toutes ces sections donne lieu la cration de ce composant. Implmentations :

Cette section dfinit les connections entre les diffrents composants quutilise lapplication. Dans cette section ((implmentation)) sont donc principalement dfinis quels sont les composants qui fournissent les interfaces `a notre application (ils seront gnralement des composants primitifs). Gnralement nous devons utiliser les interfaces que nous fournissent dautres composants primitifs ou non primitifs, et en dfinitive pour chacune de ces interfaces, que nous utiliserons dans la cration de notre composant, on doit obligatoirement dfinir des relations avec les composants qui fournissent ces interfaces. Le processus dfinissant ces relations sappelle ((wiring)). Exemple :
1 2 3

implementation { components Main , MonAppliM ; Main . StdControl -> MonAppliM . StdControl ;

20

} Configurations

Cest cet endroit que lon dclare les autres composants dont se servira lapplication. Cette possibilit offerte par le langage permet de faire de la programmation modulaire et de rutiliser des composants pralablement dfinis.

21

Chapitre 2
Gestion du projet
Contraintes
Cot Concernant le projet Capteur tout le matriel ncessaire est dj notre disposition (microcapteurs, logiciels, postes de travail...), aucun cot n'a t prendre en compte. Sachant que c'est notre tuteur qui s'est charg d'acheter les quipements, il est normal que nous en respections le matriel. Nos ordinateur ne disposant pas de port de connexion srie, nous avons cependant, pour nous permettre de travailler indpendamment des heures daccs la salle lectronique, du nous fournir dun connecteur USB-DB9. Cette ncessit na pas t formule au premier semestre. Matriels Le matriel ncessaire est situ en salle d'lectronique de l'IUP. Cette salle est accessible qu'en dehors des heures de travaux pratiques. Cependant pour plus dautonomie, la grve rendant la salle inaccessible, nous avion du nous contraindre changer de direction concernant la plate forme de travail utilis. Linstallation de TinyOS sur nos ordinateurs personnels se soldant par un chec, nous avons opt pour un choix diffrent celui envisag lors de la rdaction du cahier des charges. Nous avons utilis un ordinateur personnel quip des outils Crossbow pour travailler. 3. Travail de groupe Afin de faire avancer le travail, nous devons nous rencontrer des horaires diffrents de ceux de l'IUP. Nous devions nous mettre d'accord sur le travail effectuer chacun de notre cot afin de faire avancer le projet.

22

Prsentation des acteurs et de leurs responsabilits

Le groupe de travail est compos de 2 personnes : Laurent Daumas, et Olivier Uberti et d'un tuteur de projet Mr Abderahim Benslimane. Laurent Daumas est en charge de l'volution du site internet, il sst galement occup de linstallation des quipements de travaux et des premiers tests sur les capteurs. Olivier Uberti sera en charge de rdiger les diffrents documents pour le projet. Il se chargera galement du dveloppement sous NesC, le langage spcifique au capteur. Aucun de nous n'aura cependant une tche spcifique durant ce projet, la charge de travail dont chacun est responsable aura pour but de collecter des informations pour pouvoir les expliquer au second membre du groupe de travail, le travail tant commun au binme, toutes avances quelconques sera partag au groupe de travail. Mr Benslimane est notre responsable de projet. Il nous donne les axes de travail pour notre recherche et nous cadre par rapport aux choix que nous prendrons.

23

Mthodologie de conception de suivie

Trois types de runions de travail ont t mis en place : Runion de travail en prsence de tous les membres de groupes, Travail individuel selon la rpartition du travail, Runion de bilan avec les personnes enseignantes en charge dencadrer notre projet.

Les runions de travail ont lieu de manire apriodique selon lavancement de chacun. Elles ont lieu pour la plupart du temps lIUP, aux horaires librs pour notre application. Durant ces runions, nous valuons le travail accomplis, ltat davancement du projet, puis nous rpartissons le travail en mini-groupe. Les runions de travail en mini-groupe ont pour objectif de remplir les objectifs que nous nous sommes fixs lors des runions de groupes. Les travaux sont alors envoy aux autres membres du groupes de travail afin quils en fassent une revue. Lvaluation globale se fera lors de la runion de groupe. Les runions de bilans ont lieu avec le tuteur du projet. Les runions de bilan ont pour objectif de comprendre ce que le tuteur attend de nous concernant le projet et de nous fixer les axes de travail. Nous changeons galement les informations que nous avons collectes durant les dernires semaines et nous posons les questions qui nous permettraient de faire avancer le projet, ces dernires reprsentent le contenu prsent dans les fiches de compte rendus. Une communication par mail a t mise en place entre tous les membres du groupe de travail. Cela permettait de schanger des informations quelque soit la distance gographique. Notre mthode de travail est donc la suivante, runion des membres du groupe de travail pour discuter du travail faire, rpartition du travail, revue intermdiaire du travail par mail, valuation global du travail lors dune runion qui dfinira les tapes suivantes ncessaire llaboration du projet.

24

Prvisions et ralit
Prvision Afin de pouvoir de travailler dans les meilleurs conditions possibles sur notre projet, nous devions nous familiariser avec les technologies associes aux Capteurs afin d'y implmenter un protocole de routage. Nos premiers objectifs taient donc purement thoriques. S'informer sur les Capteurs et les technologies associes, S'informer sur la communication entre les Capteurs, Savoir changer des donnes entre capteurs, Se documenter sur le systme d'exploitation des micro-capteurs (TinyOS),

Dans un premier temps, et avant toute manuvre pratique, il est primordial de connatre l'environnement des Capteurs. Mme si cela c'est avr abstrait en raison de l'absence pratique, nous nous sommes informer sur les technologies utilises lors de la mise en place d'un rseau de Capteur. Le tout a pour but d'implmenter un protocole de routage entre les diffrents Capteurs. Notre objectif principal durant ce projet est donc celui-ci : Implmenter un protocole de routage de localisation dans un rseau de capteur sans fil.

Afin d'implmenter un protocole de routage il fallait bien videmment se poser les bonnes questions. Nous avons dfinis un axe de rflexion sur ce dernier point : o Dfinir ce qu'est un protocole de routage o Comment se fait le calcul des distances Pour commencer laspect pratique de notre projet, nous implanterons un protocole de routage trs basique reposant sur le broadcast. Une source demandera ce localis et les nuds lui enverront leur position par broadcast. Nous partons dune architecture statique ou chaque nud connait sa position. Dans un second temps, nous implanterons un protocole bien plus volu qui aura pour but que lorsquune source demande ce localis, les nuds lui rpondent en mode source/destination.

25

Cette rflexion a t base dans un systme base de Capteurs sans fil bien videmment.

Ralit Nos prvisions, que cela soit en termes de comprhension techniques, en termes de volume horaire et de choix dorientation, ont souvent t mauvaises. En ce qui concerne la comprhension technique, nous avions sous estim la charge dinformation acqurir pour travailler sur les capteurs. Nous savions quil fallait nous familiariser avec un nouveau systme dexploitation et un nouveau langage de programmation. Nous avons malheureusement omis certaines subtilits de ces derniers, mthode de compilation spcifique, outils dintgration spcifique. Concernant le protocole de routage nous avions choisit de nous lancer dans le protocole OLSR en fin de premier semestre, aprs une runion avec notre tuteur, celui ce nous a fortement conseill de nous orient plutt vers le protocole AODV qui avait dj montr des rsultats dans les rseaux de capteurs. La grve a galement entraine de nombreux changements. Laccs la salle tant bloqu et linstallation logicielle de lOS TinyOS tant impossible sur nos machines, nous avons perdus de nombreuses heures de travailles. Une fois laccs la salle autorise (une fois la grve termine), la charge en termes de volume horaire hebdomadaire nous rendant la salle lectronique inaccessible, donc le travail sur les capteurs impossible, nous avons pris linitiative de changer daxe de travail. Nous nous sommes rendu compte que lors de la cration dun cahier des charges, beaucoup de scnario que nous navions pas envisags se sont produits. Afin davoir malgr tout un travail correct fournir notre tuteur, nous devions prendre des initiatives. Nous avons galement fait le choix de fournir en plus du travail demand des guides et des processus dinstallation et de tests sur les diffrentes plates formes utilisant les capteurs. Cette dernire vocation aura uniquement pour but de normaliser un peu plus certains aspects autours des capteurs et ainsi de faire grandir la communaut qui sen retourne. Car tant un domaine de travail tout rcent et ayant des spcificits particulires, beaucoup de personnes se posent des questions sur ce sujet. Nous essayons donc avec ces guides dapporter une partie des rponses en souhaitant que la communaut sen servent et en apportent davantage lavenir.

26

Chapitre 3
Protocoles de routages et techniques de localisation dans un rseau de capteurs
Protocole AODV
Qu'est ce que le protocole AODV et comment fonctionne il ? Est il adapter au rseau de capteur ? AODV Le protocole AODV (Ad-hoc On-Demand Distance Vector) est lun des protocoles les plus tudis par les chercheurs, ce qui ce traduit par une maturit dans les implmentations disponibles ainsi que dans les diffrents comparatifs lopposant de nombreuses autres solutions. Ce protocole a donn naissance une RFC actuellement au stade exprimental (RFC3561) et gre par le groupe de travail de lIETF spcialis dans le domaine des rseaux ad hoc. Lorsquun nud dsire envoyer un message une destination pour laquelle il ne possde pas de route, la procdure de construction est initie par lenvoi dun message RREQ tous ses voisins physiques par diffusion (broadcast). A la rception dun tel message, les nuds insrent dans leurs tables de routage, une route vers le nud lorigine de la requte passant par le nud ayant envoy le message qui devient le prochain pas (next hop) vers le nud lorigine de la requte. Cette dmarche permet de crer une route de retour (reverse path) pour les futurs messages transitant de la destination la source. En insrant cette route, les nuds font lhypothse que les liens physiques sont symtriques et quils pourront atteindre le nud ayant envoy le message. Chaque nud recevant ce message va le retransmettre de la mme manire ce qui terme va inonder le rseau. Ces messages sont identifiables par chacun des nuds ce qui leur permet de les traiter quune seule fois et empche quune requte transite indfiniment dans le rseau. Les principales informations de la table de routage du nud 7 27

sont reprsentes en guise dexemple, tel que le prochain nud vers la destination, le numro de squence de la destination ainsi quune mtrique (nombre de sauts jusqu la destination). Dans ce protocole, les nuds intermdiaires ainsi que le nud recherch peuvent rpondre ces requtes par lenvoi dun message RREP qui va transiter jusquau nud lorigine de la requte. Ce nouveau type de message ninonde pas le rseau mais est envoy en empruntant la route cre lors du passage de la requte. Les nuds intermdiaires peuvent rpondre uniquement sils possdent une route assez fraiche vers la destination recherche. Cette caractristique permet de construire plusieurs routes vers la destination. Ainsi, le nud lorigine de la construction va potentiellement recevoir plusieurs messages RREP. Ce dernier va slectionner la route la plus courte en fonction du nombre de pas physiques. Le niveau de fraicheur des routes est tabli sur la base dun numro de squence maintenu par chaque nud et est compar avec la fraicheur minimale dsire par le nud lorigine de la requte dans le message RREQ. Ce numro de squence permet de garantir la construction de routes dpourvues de boucles et dimposer la reconstruction dune route. A la rception dun message RREP, les nuds insrent dans leurs tables de routage la route directe (forward route) vers le nud recherch. Ainsi, lalgorithme a cr la route bidirectionnelle reliant le nud lorigine de la requte et le nud recherch. Lorsquune route est cre, une procdure de maintenance est initie, visant garantir une route exploitable et consistant dtecter les liens briss. Dans la version originale du protocole, cette procdure est mise en uvre par lchange priodique de messages entre les voisins physiques des nuds constituant la route. Un nud ne recevant pas de message de maintenance durant un certain nombre de priodes va considrer la route comme tant brise. Le processus de gestion des erreurs offre deux possibilits aux nuds dtectant une route brise. La premire consiste rparer localement la route en initiant une nouvelle requte de construction et stocker dans un tampon les ventuels messages ncessitant la route brise an de les retransmettre plus tard. La deuxime solution consiste avertir tous les nuds jusquau nud source de ltat de la route. Pour chaque destination contenue dans la table de routage dun nud, une liste des prdcesseurs est cre. Cette liste contient les nuds susceptibles dutiliser ce nud pour transfrer de linformation vers la destination. Le nud dtectant une route brise se base sur ces listes pour envoyer des messages RRER aux nuds cibls, contenant la destination du nud qui nest plus atteignable. Les nuds recevant un tel message se comportent de la mme manire ce qui va faire transiter linformation 28

jusquau nud source. Le nud source va reconstruire la route uniquement lorsquil en aura nouveau besoin. Les routes ont une dure de vie limite qui est mise jours aprs chaque utilisation. Une route inutilise durant une longue priode (3 secondes par dfaut) nest plus valide et le processus de maintient de la route est stopp ce qui permet dviter des changes de messages de maintenance inutiles.

Recherche de la destination par la requte RREQ

Rponse de la destination par la requte RREP

29

Protocoles de localisation
On utilise 3 techniques pour calculer la distance entre les capteurs.

Angles of arrivals, Calcul de la distance par la puissance mise (RSSI), Utilisation de la vitesse de propagation du signal (TOA),

RSSI
En tlcommunication, le Received Signal Strength Indication ou RSSI est une sortie d'un systme de rception d'un signal sans fil (classiquement un signal radio). Son utilit est de fournir un signal li l'intensit du signal reu. Ainsi, la sortie est en courant continu, souvent en 0/5V (ou 0/+V) (le niveau le plus lev est 5V, le plus bas est 0V). La signification du signal est la suivante: si la tension de sortie est nulle, le rcepteur ne peroit pas de signal. Si la tension est leve (proche de +V), le signal est maximal. Cela permet donc d'ajuster la qualit de la rception. Le RSSI est la mesure de la puissance d'un signal reu par un quipement. La perte de puissance entre lmetteur et le rcepteur est proportionnelle la distance parcourue. La mesure RSSI (Received Signal Strength Identification) propose une estimation de la distance mais pas de son axe directeur. La localisation dun quipement implique la dtection et la mesure du signal de celui-ci par trois autres quipements dont on connait les positions. La prcision de cette mthode de triangulation des frquences radio dpend de deux facteurs : 30

1. La prcision de chaque mesure. Il existe de nombreux facteurs qui psent sur la prcision des distances lors des mesures RSSI. Cette mesure peut savrer correcte en elle-mme. En revanche lorientation de lantenne, la prsence de murs, parois, objets mtalliques peuvent modifier la puissance du signal, la distance relle savre ainsi peu fiable. 2. Le degr de prcision est inversement proportionnel la distance mesure.

Time Of Arrivals
Le TOA (Time Of arrival) est un systme de localisation bas, sur le temps mesure, sur les points daccs linstant darrive du signal mis par le mobile. Si les horloges du mobile et du point daccs ne sont pas synchronises, il faut ajouter une inconnue de temps lquation. Contrairement aux quipements de localisation utilisant la puissance, la prcision du systme peut tre amliore en augmentant le rapport signal sur bruit ou la largeur effective de la bande. Comme il est possible datteindre une trs grande prcision de localisation, par exemple 2 3 cm avec une largeur de bande de 1.5 GHz et un SNR de 0 dB, la qualit de la mesure du temps et la synchronisation de tous les nuds influent fortement sur les performances. Il est possible de saffranchir du problme de synchronisation des horloges entre le mobile et les points daccs en travaillant avec des diffrences de temps darrive (TDOA). Dans ce cas, la diffrence de temps darrive dun signal mis par un mobile sur deux points daccs est calcule. Dans lespace, le lieu gomtrique des positions possibles du mobile est dcrit par un hyperbolode dont les foyers sont les deux points daccs utiliss. Trois mesures de TDOA, rsultant de la rception simultane du signal sur trois points daccs distincts, sont ncessaires pour calculer la position du mobile. Etant donn la complexit de lenvironnement construit, seule une trs forte densit de points daccs, permet denvisager une telle configuration.

Angle of Arrival

31

L'Angle of arrival est un systme de localisation bas sur les angles dincidence mesure langle entre la direction de propagation du rayonnement lectromagntique incident et la normale aux dioptres des points daccs, le tout laide de ranges dantennes spcifiques. Il est difficile de dterminer avec prcision, langle dincidence dans un ensemble de signaux rflchis. Deux rfrences suffisent pour calculer un point dans un espace plan. Le systme mesure les angles dincidence des signaux mis par lmetteur mobile. Ainsi les angles de direction apparente et dlvation apparente du mobile dans le rfrentiel attach au point daccs sont fournis. Afin dexprimer ces mesures dans le rfrentiel de la pice/btiment dans lequel on se trouve, il faut tenir compte de lorientation du point daccs. Cette orientation est dfinie par les angles dinclinaison et dorientation. Envoie dun Chapitre 4 message Algorithme et phase de test Temporisation Afin de pouvoir coder le protocole AODV en NesC nous avons rsum le protocole en deux algorithmes, un dcrivant la cration dune route le second dcrivant la structure denvoi des messages qui entrainera une chaine de maintenance. non Envoi dun message : Acquittement reut ? oui Renvoi du message

Stocker dans le cache les nuds dfectueux

Temporisation

Fin Envoie du message

oui Acquittement reut ? non Dtection dun nud bris

Envoi dun message RRER jusquau nud source

32

Demande de Route Demande de routes : Diffusion dun message RREQ

Message RREQ arriv destination ? oui

non

Insertion du numro de nuds dans la table de routage

Diffusion de la requte au prochain saut

Insertion du numro de nuds dans la table de routage

Envoi dun message RREP au prochain hop

non Origine de la requte RREQ ?

oui

Choix de la route la plus rapide

Route connue dans la table ? oui

non

Mise jour de la table

33 FIN

De ces algorithmes nous en tirerons des fonctions principales que nous implmenterons : Envois des messages : SendRREQ() SendRREP() SendRRER() resendMSG Inscription des valeurs dans la table de routage : Get_route_table Add_route_table Messages de fin de transmission : SendRREQ.sendDone SendRREP.sendDone SendRRER.sendDone Vrification des messages lintrieur du noeud : ReceiveRREQ.receive ReceiveRREP.receive Correction des paquets: Split_Control

34

Conclusion
Nous navons pas travaill comme nous lavions prvus, la grve a entraine un changement de plate forme de travail, un changement dans la rpartition des tches, tant donn que nous habitons respectivement plus dune heure de lespace de travail, nous avons opt pour un travail personnel sur la programmation. Nous avions opt pour lOS XubuntOS au dpart pour finalement changer et utilis les utilitaires Crossbow pour Windows, faute aux multiples problmes dinstallations de lOS XubuntOS sur nos ordinateurs personnels. Ce dernier choix nous rendant plus autonome, nous tions moins indpendant de la salle lectronique o nous travaillions jusqu' lors. Nous avions galement sous estim la complexit de lenvironnement de travail. Limplmentation de programme dans un capteur requiert des connaissances qui ne sont pas faciles trouver. En effet en plus de devoir se familiariser avec un nouveau systme dexploitation, nous devons en connatre ses subtilits, savoir son langage de programmation propre, le NesC, les mthodes de compilation, mais nous devions galement apprendre utiliser les outils lis aux technologies Crossbow. Pour palier ce problme et ainsi viter dautres personnes des recherches inutiles, nous avons pris linitiative de faire des guides expliquant les marches suivre pour installer et utiliser les outils ncessaires aux travaux sur les capteurs. Nous navons malheureusement pas atteint les exigences de notre tuteur de projet, en effet il souhaitait incorporer un protocole de routage faisant de la localisation dans un rseau de capteur. Seul le protocole de

35

routage a t implant. Lintgration de la localisation dans la table de routage na pas put se faire. Nous nous sommes lancs dans la programmation du protocole de routage AODV, un routage plus simple aurait permis une meilleure approche de la problmatique. Nanmoins nous retenons des aspects positifs dans ce projet. Travailler dans un nouvel environnement de travail, les rseaux de capteurs tant un univers nouveaux pour nous deux. Etant donn la communaut autours des rseaux de capteurs est trs pauvre, nous avons fait le choix de faire des guides autours des diffrents outils afin dapporter un aspect plus pdagogique et permettre un travail plus direct aux futurs tudiants travaillant sur des projets en relation avec les capteurs. Au-del de laspect nouveaut, cest toute la richesse, que peut apporter les capteurs en termes de mesures, de dveloppement dapplication qui nous a intresss. Nous pensons quil serait de bonne augure dinclure au sein dune Unit dEnseignement une UCE rseau de capteur. Cette dernire permettrait de connatre les spcificits de TinyOS et de faire des petites applications au sein dun rseau de capteurs. Un domaine davenir.

36

Diagramme de Gantt

37

Bibliographies
[TOS00] Tinos official website: http://www.tinyos.net/ [AT00] ATEMU Sensor network emulator http://www.cshcn.umd.edu/research/atemu/ [TOS01] TinyOS mote simulator: http://www.cs.berkeley.edu/~pal/research/tossim.html [SPOT00] Sun SPOT description: http://research.sun.com/spotlight/SunSPOTSJune30.pdf [NesC00] A programming language for deeply networked systems : http://nescc.sourceforge.net/ [Arch07] Bouillaguet Mathieu et Valero Mathieu, OS pour rseaux de capteurs, 2005 : http://wwwmaster.ufrinfop6.jussieu.fr/2005/IMG/pdf/presentationZigBeeTin yOS.Pdf [NesC01] D. Gay, P. Levis, R. von Berehn, M. Welsh, E. Brewer, and D.Culler, The NesC language: A hoalistic approach to networked embedded systems. in SIGPLAN Conference on Programming Language Design and Implementation, June 2003. [WEB06] M. Badet, W.Bonneau, Rseaux de capteurs sans fils, Mise en place d'une plateforme de test et d'exprimentation : http://membres.lycos.fr/faucheur/reseauxdecapteurs/index.htm [TOS02]C.L Fok TinyOS tutorialCS521 Fall 2004

38

[WEB07] H. Alatrista, S. Aliaga, K. Gouaich, J. Mathieu, Implmentation de protocole sur une plateforme de rseaux de capteurs sans-fils : http://hugo.alatristasalas.free.fr/Archivos/rapportCapteurs.pdf [RES00] M.CARTRON, Vers une plate-forme efficace en nergie pour les rseaux de capteurs sans fil [RES01] Applications des rseaux de capteurs intelligents et de la communication sans fil linstrumentation des structures de gnie civil http://hal.archives-ouvertes.fr/hal-00376774/en/ [RES02] L.SAMPER, Modlisations et Analyses de Rseaux de Capteurs , Mai 2008

39