Modélisations et analyses de réseaux de capteurs

HAL Id: tel-00283716

https://tel.archives-ouvertes.fr/tel-00283716

Submitted on 30 May 2008

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Ludovic Samper

To cite this version:

Ludovic Samper. Modélisations et analyses de réseaux de capteurs. Réseaux et télécommunications

[cs.NI]. Institut National Polytechnique de Grenoble - INPG, 2008. Français. �tel-00283716�

INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE

N°attribu ´e par la biblioth `eque

| | | | | | | | | | |

T H ` E S E pour obtenir le grade de

DOCTEUR DE L’INPG

Sp ´ecialit ´e : « INFORMATIQUE : SYST ` EMES ET LOGICIELS » pr ´epar ´ee au laboratoire V

dans le cadre de l’ Ecole doctorale ´ « MATH ´ EMATIQUES, SCIENCES ET TECHNOLOGIES DE L’INFORMATION, INFORMATIQUE »

pr ´esent ´ee et soutenue publiquement

par

Ludovic SAMPER le 7 avril 2008

Titre :

Mod ´elisations et Analyses de R ´eseaux de Capteurs

Directeurs de th `ese :

Florence Maraninchi Laurent Mounier

JURY

Marc Pouzet Pr ´esident

Isabelle Gu ´erin-Lassous Rapporteure

Robert de Simone Rapporteur

Dominique Barthel Examinateur

Florence Maraninchi Directrice de th `ese

Laurent Mounier Directeur de th `ese

Remerciements

Premi erement, je tiens ` a remercier Marc Pouzet de m’avoir fait l’honneur de bien vouloir pr´ ` esider le jury de ma th`ese.

Je remercie Isabelle Gu´ erin-Lassous et Robert de Simone d’avoir accept´ e d’ˆ etre rapporteurs de ma th`ese.

Merci a tous les trois pour l’int´ ` erˆ et que vous avez port´ e a ce travail, pour vos remarques qui m’ont ` permis de voir plus loin.

Bien entendu, sans mes encadrants rien de tout cela n’aurait ´ et´ e possible. Tous les doctorants n’ont pas un directeur de th` ese disponible et motiv´ e par leurs travaux. Je sais la chance que j’ai d’en avoir eu trois !

Je remercie Dominique Barthel, Florence Maraninchi et Laurent Mounier d’avoir entrepris ensemble des recherches sur la mod´ elisation des r´ eseaux de capteurs. Dominique Barthel a tr` es vite compris l’int´ erˆ et des mod` eles formels. Cet enthousiasme a et´ ´ e tr` es b´ en´ efique pour mes travaux. Dominique m’a egalement beaucoup aid´ ´ e par ses explications en ´ electronique. J’ai eu la chance de b´ en´ eficier du recul de Florence Maraninchi qui m’a toujours propos´ e des perspectives de recherche pertinentes. Je remercie Laurent Mounier pour sa grande disponibilit´e et sa gentillesse.

Je tiens a remercier Abdelmalik Bachir et Louis Mandel pour les travaux de recherche fructueux que ` nous avons men´ es ensemble. Je remercie egalement Louis Mandel d’avoir toujours ´ et´ ´ e tr` es r´ eactif aux probl`emes que j’ai pu rencontrer avec son langage de programmation.

Wassim Znaidi, Kevin Baradon et Antoine Vasseur ont particip´ e a ce travail pendant leurs stages ` respectifs. Je les remercie sinc`erement.

Je remercie egalement Mischa Dohler, Christophe Dugas, Olivier Bezet ainsi que tous les membres du ´ projet ARESA.

Merci `a Hugo, Guillaume et Mathias pour ces ann´ees de th`ese que nous avons surmont´ees ensemble.

Les laboratoires de Verimag et de France T´ el´ ecom fournissent un cadre de travail privil´ egi´ e, merci a ` tous. Vivent les s´eminaires th´esards pendant lesquels on apprend plein de choses !

Je remercie Abdelmalik, Thomas, Laetitia, Laurent et Cyril pour la bonne ambiance qui r´ egnait dans nos bureaux.

La r´ ealisation de ce travail n’aurait pas et´ ´ e possible sans des moments de d etente (et r´ ´ eciproquement), donc merci aux vttistes, aux randonneurs, aux footballeurs et aux autres.

Je remercie ma famille pour son soutien et la bonne organisation du pot de th`ese.

Je remercie les auteurs des th`eses desquelles j’ai copi´e les remerciements.

Je vous remercie par avance, lecteurs, de ne pas vous int´eresser qu’au chapitre des remerciements.

Enfin, je remercie Am´elie pour tout et le reste.

3

Table des mati`eres

1 Introduction 9

1.1 L’essor des r´eseaux de capteurs . . . . 9

1.2 Difficult´es de conception . . . . 10

1.3 Techniques de conception existantes . . . . 11

1.4 Notre approche pour la mod´elisation . . . . 12

1.5 Cadre de la th`ese . . . . 13

1.6 Contenu du document . . . . 14

1.6.1 R´esum´e des contributions . . . . 14

1.6.2 Plan du document . . . . 15

I Contexte, travaux li´es 17 2 Les r´eseaux de capteurs 19 2.1 Contexte des r´eseaux de capteurs . . . . 19

2.1.1 Applications . . . . 19

2.1.2 Protocoles de routage . . . . 22

2.1.3 Protocoles d’acc`es au m´edium . . . . 25

2.1.4 Mat´eriel . . . . 28

2.2 Besoins pour la conception de ces syst`emes . . . . 31

2.3 M´ethodes usuelles de mod´elisation pour les r´eseaux de capteurs . . . . 33

2.3.1 Les simulateurs de r´eseaux . . . . 34

2.3.2 Mod´elisation pour l’´evaluation de performance . . . . 37

2.3.3 Mod´elisation pour la v´erification formelle . . . . 38

2.4 Notre approche : du prototypage rapide r´ealiste et analysable . . . . 39

II Mod´elisation, ´evaluation de performance 43 3 Evaluation de protocoles MAC `a ´echantillonnage de pr´eambule ´ 45 3.1 Protocoles `a ´echantillonnage de pr´eambule . . . . 46

3.1.1 Protocoles classiques `a ´echantillonnage de pr´eambule . . . . 46

3.1.2 Am´elioration des protocoles `a ´echantillonnage de pr´eambule . . . . 46

3.1.3 Transmission : MFP ou DFP . . . . 46

3.1.4 R´eception : persistant ou non-persistant . . . . 47

3.2 Mod´elisation et ´evaluation des diff´erents protocoles . . . . 48

3.2.1 Mod´elisation du syst`eme . . . . 48

5

3.2.2 Evaluation ´ . . . . 50

3.3 R´esultats num´eriques . . . . 53

3.4 Conclusion . . . . 56

III Mod`eles r´ealistes et mod`eles analysables 57 4 M´ethodes de mod´elisation formelles 59 4.1 Mod`eles `a automates . . . . 60

4.1.1 Les automates . . . . 60

4.1.2 Composition d’automates . . . . 62

4.1.3 Produit asynchrone . . . . 66

4.1.4 Produit synchrone . . . . 68

4.1.5 Syst`eme globalement asynchrone, localement synchrone . . . . 72

4.2 Extensions pour la mod´elisation de l’´energie . . . . 72

4.2.1 Les techniques de mod´elisation de l’´energie . . . . 72

4.2.2 Discussions . . . . 76

4.3 Techniques d’analyse formelle . . . . 78

4.4 Les impl´ementations . . . . 78

4.4.1 IF . . . . 78

4.4.2 L

. . . . 80

4.4.3 R

ML . . . . 83

4.4.4 L

. . . . 86

5 Mod´elisation dans l’approche synchrone : le simulateur G

89 5.1 Le simulateur de r´eseaux de capteurs, G

. . . . 90

5.1.1 Exemple . . . . 90

5.1.2 Formalisme du mod`ele . . . . 90

5.1.3 Un mod`ele global : d´emonstration sur notre exemple . . . . 91

5.1.4 Interface graphique . . . . 98

5.2 Exp´erience G

: importance de l’environnement . . . . 100

5.2.1 Un autre mod`ele d’environnement : loi de Poisson . . . . 100

5.2.2 Comparaison des deux mod`eles . . . . 101

5.2.3 R´esultats . . . . 101

5.2.4 Conclusion . . . . 105

5.3 L

. . . . 105

5.3.1 Un mod`ele en L

. . . . 105

5.3.2 Structure de L

. . . . 106

5.3.3 Diff´erences entre G

et L

. . . . 107

5.4 R

ML, un langage efficace pour la programmation de simulateurs . . . . 108

5.4.1 Deux types de simulateurs : `a ´ev´enements discrets ou `a pas fixe . . . . 109

5.4.2 Int´erˆet de l’approche `a ´ev´enements discrets . . . . 110

5.4.3 Int´erˆets de l’approche r´eactive synchrone . . . . 111

5.4.4 Confort de programmation . . . . 112

5.4.5 Autres qualit´es de R

ML . . . . 112

5.4.6 Passage `a l’´echelle : exemple de G

. . . . 113

Table des mati`eres

6 Mod´elisation haut niveau avec l’approche asynchrone 115

6.1 Cas d’´etude . . . . 116

6.2 Mod´elisation en IF . . . . 116

6.3 Calcul de la dur´ee de vie pire cas . . . . 118

6.4 R´esultats exp´erimentaux . . . . 120

6.4.1 Crit`ere de dur´ee de vie . . . . 120

6.4.2 Exp´erimentations . . . . 120

6.4.3 Importance du pire cas . . . . 122

6.5 Conclusion . . . . 123

7 Cadre formel pour des abstractions modulaires prenant en compte l’´energie 125 7.1 Motivations et exemples . . . . 126

7.1.1 Quelques exemples de mod`eles de radios . . . . 127

7.1.2 Un mod`ele de protocole MAC . . . . 129

7.2 Formalisation de la notion d’abstraction . . . . 131

7.2.1 D´efinitions g´en´erales et notations . . . . 131

7.2.2 Mod`eles `a coˆuts . . . . 132

7.2.3 Composants `a coˆuts . . . . 134

7.2.4 Abstraction . . . . 135

7.3 Retour sur l’exemple . . . . 138

7.3.1 Les mod`eles de radio . . . . 138

7.3.2 Composition MAC et Radio . . . . 139

7.3.3 Un contre exemple . . . . 140

7.4 Autres remarques . . . . 141

7.4.1 D’autres fonctions de combinaison des coˆuts . . . . 141

7.4.2 Propagation automatique des contraintes ? . . . . 141

7.4.3 L’´energie n’est pas fonctionnelle . . . . 142

8 Conclusion et perspectives 145 8.1 Bilan . . . . 145

8.1.1 Mod´elisation analytique de protocoles MAC . . . . 145

8.1.2 Simulation . . . . 146

8.1.3 Mod´elisation formelle . . . . 146

8.2 Travaux en cours utilisant G

. . . . 147

8.3 Perspectives . . . . 148

8.3.1 Mod´elisation analytique de protocoles MAC . . . . 148

8.3.2 Mod´elisation formelle . . . . 149

Bibliographie 156

Ludovic Samper Th`ese de Doctorat 7/158

Chapitre 1

Introduction

Sommaire

1.1 L’essor des r´eseaux de capteurs . . . . 9

1.2 Difficult´es de conception . . . . 10

1.3 Techniques de conception existantes . . . . 11

1.4 Notre approche pour la mod´elisation . . . . 12

1.5 Cadre de la th`ese . . . . 13

1.6 Contenu du document . . . . 14

1.6.1 R´esum´e des contributions . . . . 14

1.6.2 Plan du document . . . . 15

1.1 L’essor des r´eseaux de capteurs

De nombreuses avanc´ ees techniques et technologiques dans les domaines de la micro-´ electronique, de la micro-m´ ecanique, et des technologies de communication sans fil permettent de cr´ eer de petits objets communicants equip´ ´ es de capteurs a un co ` ut raisonnable. Ces nouveaux objets appel´ ˆ es nœuds ou capteurs sont equip´ ´ es d’une unit´ e de mesure (le ou les capteurs), d’une unit´ e de calcul, de m´ emoires et d’une radio pour communiquer. Enfin, pour l’alimentation, ces nœuds poss` edent une pile ou un syst`eme de r´ecup´eration d’´energie dans l’environnement.

Cette technologie rend possible le d´ eploiement de r´ eseaux de capteurs sans fil. Les r´ eseaux de capteurs ont de nombreuses perspectives d’application dans des domaines tr` es vari´ es : applications militaires, domotique, surveillance industrielle ou de ph´enom`enes naturels, relev´e de compteurs.

Chaque application a ses propres contraintes. Dans tous les domaines, le rˆ ole d’un r´ eseau de capteurs est cependant a peu pr` ` es toujours le mˆ eme, voir figure 1.1. Les nœuds doivent surveiller certains ph´ enom` enes grˆ ace a leurs capteurs puis envoient les informations ` a un puits. Le puits (ou ` sink en anglais) est un nœud particulier dot´ e d’une puissance de calcul sup´ erieure et d’une quantit´ e d’´ energie potentiellement infinie. Ce puits peut etre connect´ ˆ e a Internet ou poss` ` ede un lien radio de type GSM ou GPRS qui lui permet d’envoyer les informations (donn ees ou alertes) ´ a un centre de ` contrˆ ole pour l’utilisateur final. Il peut y avoir plusieurs puits mobiles ou fixes dans un r´ eseau mais pour des raisons de coˆ ut, il y a de toutes fac¸ons beaucoup moins de puits que de nœuds. Les r´ eseaux de capteurs qui sont l’objet de notre etude sont les syst ´ emes constitu´ ` es des nœuds et des eventuels puits, il ´ ne s’agit pas d’´etudier comment le puits est connect´e `a l’utilisateur final.

9

message

Evènement

PUITS

Zone à controler

F

. 1.1 – Sch´ema d’un r´eseau de capteur

Ce type d’application implique des contraintes communes a de nombreux r´ ` eseaux de capteurs.

Les capteurs sont d eploy´ ´ es sur la zone a contrˆ ` oler. Comme celle-ci est etendue et potentiellement ´ difficile d’acc` es, ils doivent s’auto-organiser pour envoyer de proche en proche les messages jusqu’au puits. On ne remplace pas les nœuds qui ne fonctionnent pas ou qui n’ont plus d’´ energie, il faut donc qu’ils vivent le plus longtemps possible avec une quantit´ e d’´ energie tr` es faible etant donn´ ´ ee le coˆ ut

´

elev´ e des piles. Pour certaines applications de surveillance o u le trafic est tr` ` es sporadique, on souhaite plusieurs dizaines d’ann´ ees d’autonomie pour le r´ eseau. Enfin, ces r´ eseaux sont compos´ es d’un tr` es grand nombre de nœuds, plusieurs centaines voire plusieurs milliers de nœuds.

1.2 Difficult´es de conception

Les acteurs industriels impliqu´ es dans le domaine des r´ eseaux de capteurs doivent etre capables de ˆ d evelopper rapidement des solutions fiables. Les entreprises qui conc¸oivent et d´ ´ eploient des r´ eseaux de capteurs doivent le faire le plus rapidement possible pour faire face ` a la concurrence. L’enjeu

´economique li´e `a la conception des r´eseaux de capteurs est tr`es important.

Cependant, concevoir un r´ eseau de capteurs n’est pas une chose facile parce que ce sont des syst` emes complexes qui combinent des caract eristiques propres aux syst` ´ emes distribu´ es et aux syst` emes embarqu´ es. Les syst` emes distribu´ es sont difficiles a concevoir pour plusieurs raisons. Les communica- ` tions entre les nœuds ne sont pas fiables, par exemple les nœuds d’un r eseau communiquent ´ a l’aide de ` radios. On peut difficilement d´ efinir l’´ etat global du syst` eme, et enfin l’ex´ ecution des processus (ici les nœuds) est asynchrone. Quant aux syst` emes embarqu es, ils ont des ressources (calcul, m´ ´ emoire) tr` es contraintes parce qu’ils doivent respecter des contraintes de coˆ ut. Et pour concevoir les syst` emes embarqu´es, il faut prendre en compte les interactions fortes entre le logiciel et le mat´eriel.

En plus des contraintes cumul´ ees des syst` emes distribu´ es et embarqu´ es, les applications auxquelles

sont d edi´ ´ es les r eseaux de capteurs imposent des exigences suppl´ ´ ementaires de fiabilit´ e et surtout

d’´ economie d’´ energie. A cause des difficult´ ` es d’acc` es aux nœuds, un probl` eme mat´ eriel ou logiciel

sera plus difficile a r´ ` egler dans les r´ eseaux de capteurs. Pour ces syst` emes, publier une mise a jour en `

1.3. Techniques de conception existantes

cas de probl eme est beaucoup plus difficile que pour les logiciels destin´ ` es aux ordinateurs de bureau. Et quand bien mˆ eme celle-ci serait faisable, elle aurait un coˆ ut ´ energ´ etique p´ enalisant pour la dur´ ee de vie du r´ eseau. Aujourd’hui, de nombreux syst` emes embarqu´ es sont d´ ej` a contraints en energie (t´ ´ el´ ephones, appareils photo), mais pour ces objets il s’agit simplement de maximiser le temps entre deux recharges de la batterie. Cette contrainte est beaucoup plus forte dans les r´ eseaux de capteurs. Premi` erement, on ne recharge pas un nœud qui n’a plus d’´ energie parce c¸a co uterait aussi cher que de le remplacer par un ˆ nouveau nœud. Et deuxi emement, les clients demandent des garanties sur la dur´ ` ee de vie du r´ eseau allant de 10 `a 15 ans d’autonomie.

Voici, pour appuyer le besoin de m´ ethodes de conception d´ edi´ ees, quelques choix auxquels sont confront es les concepteurs de r´ ´ eseaux de capteurs. Tout d’abord, il faut choisir les diff´ erents composants mat´ eriels qui constituent un nœud. Par exemple, il faut choisir un microcontrˆ oleur basse consommation qui soit suffisamment puissant pour subvenir aux besoins de l’application. Le choix de la radio d´ ependra de la fr´ equence d’´ emission choisie qui, elle-mˆ eme, est fonction de la port ee souhait´ ´ ee. Il faut egalement ´ choisir ou concevoir les logiciels. Les protocoles de communication, le protocole d’acc` es au m´ edium (MAC) ou celui de routage, influencent beaucoup la consommation. Le domaine de recherche qui consiste ` a inventer des protocoles d´ edi´ es aux r´ eseaux de capteurs est tr` es actif. De ces protocoles d´ epend directement le temps pendant lequel la radio emet ou rec¸oit et donc la consommation d’´ ´ energie.

Pour tous les protocoles, il y a egalement souvent des param` ´ etres a d´ ` efinir et ces param etres peuvent ` interagir.

Tous ces choix d´ ependent bien s ur de l’application. Le choix du protocole de routage d´ ˆ epend du type de communication le plus couramment utilis´ e. Il est inutile de concevoir un protocole efficace point- a-point si ce mode de communication n’est jamais utilis´ ` e. Les choix de conception d’un r´ eseau de capteurs d´ependent naturellement de l’environnement physique dans lequel il est d´eploy´e.

Dans ce contexte, trouver une m´ ethode pour atteindre la solution optimale en energie est ´ probablement hors de port´ ee. Trouver des m´ ethodes et outils d’aide a la conception des r´ ` eseaux de capteurs, semble plus accessible. Un point important que doivent prendre en compte ces m´ ethodes est la consommation d’´energie.

Une m´ ethode de conception pourrait consister a construire le syst` ` eme complet puis ` a l’´ evaluer.

Certes cette solution serait fiable puisqu’on evaluerait une solution compl` ´ ete mais, vu les contraintes de temps, elle paraˆ ıt difficilement faisable. En effet, un r eseau de capteurs peut n´ ´ ecessiter des solutions mat´ erielles d´ edi ees coˆ ´ uteuses a d´ ` evelopper. Pour ex´ ecuter la mˆ eme fonction, une solution mat erielle ´ d´ edi´ ee peut etre plus efficace en ˆ energie. En contrepartie, elle est moins reconfigurable et sa conception ´ conception est plus co uteuse. Ce coˆ ˆ ut elev´ ´ e de conception ne permet pas de tester la solution mat´ erielle pour d´ ecider si elle remplace avantageusement le logiciel. Il n’est pas envisageable non plus de comparer, en les testant, deux implantations mat´erielles diff´erentes.

1.3 Techniques de conception existantes

On s’int´ eresse a une d´ ` emarche de type prototypage virtuel. Elle consiste a construire un mod` ` ele du syst`eme pour pouvoir l’analyser d`es les premi`eres phases de conception.

Dans les r´ eseaux, cette solution est d ej` ´ a largement r´ epandue. Les analyses utilis´ ees sont princi- palement la simulation et des ´ etudes utilisant des mod` eles math´ ematiques. Il apparaˆ ıt cependant que les simulateurs de r eseaux classiquement utilis´ ´ es dans les r´ eseaux ad hoc ne sont pas suffisants pour permettre une evaluation pr ´ ecise de la consommation d’´ ´ energie. Une des limitations est qu’ils ne prennent pas en compte la mod´ elisation pr ecise du mat´ ´ eriel. Concernant les analyses math´ ematiques,

Ludovic Samper Th`ese de Doctorat 11/158

elles n´ ecessitent des abstractions tr` es fortes pour obtenir des r´ esultats. Ces mod` eles ne mod´ elisent donc pas de fac¸on pr ecise tous les comportements. Si les simulateurs permettent une mod´ ´ elisation pr´ ecise des couches protocolaires puisqu’elles peuvent etre simul´ ˆ ees telles quelles en ex´ ecutant le code

`

a embarquer sur les capteurs, il est beaucoup plus difficile de mod´ eliser leurs comportements a l’aide ` de math´ ematiques. De telles analyses peuvent donc permettre de comprendre des probl` emes locaux de collisions, ou de probl` emes globaux en regardant le graphe form´ e par le r´ eseau, mais il est hasardeux d’en d´eduire des informations sur la dur´ee de vie du r´eseau.

Pour concevoir des syst` emes embarqu´ es critiques dans lesquels une erreur de conception peut avoir des cons´ equences dramatiques, on peut dans certains cas utiliser la v´ erification formelle. Cette technique permet de prouver des propri´ et´ es sur un mod ele disposant d’une s´ ` emantique bien d´ efinie.

L’avantage par rapport a d’autres techniques comme la simulation est l’exhaustivit ` e. Par contre, une ´ des limitations est le probl` eme d’explosion d’´ etats : les techniques de v´ erification exhaustive sont coˆ uteuses et ne permettent donc pas de v´ erifier des syst` emes de grande taille. Un autre probl` eme pour le contexte des r´ eseaux de capteurs est que la plupart de ces techniques ne prennent pas en compte les propri´et´es non fonctionnelles comme la consommation d’´energie.

L’objectif de la th` ese est de proposer des m´ ethodes de mod´ elisation qui permettent de garantir la dur´ee de vie d’un r´eseau d`es les premi`eres phases de conception.

1.4 Notre approche pour la mod´elisation

Pour r´ epondre aux difficult´ es de conception des r´ eseaux de capteurs, nous proposons de construire des mod` eles qui puissent etre analys´ ˆ es. Nous avons d’abord propos´ e un mod` ele probabiliste. Repr´ esenter un syst` eme en utilisant des mod` eles probabilistes permet d’analyser l’´ evolution de diff´ erents indicateurs (consommation, collisions) en fonction de param` etres (taux d’erreur de transmission, nombre de messages). Nous avons mod´ elis´ e et compar´ e diff´ erentes solutions d’un composant de r´ eseau de capteurs a l’aide de ces mod` ` eles math´ ematiques. Un inconv´ enient de ces analyses est que le mod` ele est tellement simplifi´e qu’il est difficile de le relier `a la r´ealit´e.

Nous proposons donc de construire des prototypes virtuels r´ ealistes. Le but d’un prototype virtuel est d’´ evaluer d es que possible la solution que l’on souhaite d´ ` eployer en utilisant un mod` ele op´ erationnel donc ex´ ecutable. Les mod eles op´ ` erationnels sont conc¸us pour reproduire le comportement du vrai syst` eme, ils sont donc plus facilement proches de la r´ ealit´ e. Dans le cas des r´ eseaux de capteurs o u ` la difficult´ e principale est de concevoir des syst emes ` economes en ´ energie, le prototype virtuel doit ´ permettre d’´evaluer la dur´ee de vie du r´eseau en calculant la consommation de chacun des nœuds.

Le formalisme du mod` ele que nous d´ ecrivons permet de mod´ eliser finement la consommation d’´ energie. De plus, notre mod` ele est global et pr´ ecis. Il est global parce que nous ne savons pas, a ` l’avance, quels el´ ´ ements doivent imp´ erativement etre mod´ ˆ elis es et quels sont ceux qui sont superflus. A ´ priori, tous les el´ ´ ements ont une influence sur le comportement. Nous pensons, par exemple, que pour un r´ eseau de capteurs l’environnement physique doit etre pris en compte. Notre mod` ˆ ele est pr´ ecis parce que les composants, notamment mat´ eriels, doivent ˆ etre mod´ elis´ es pr´ ecis´ ement pour que l’estimation de la consommation soit fiable. Pour ce faire, il contient des mod` eles op´ erationnels des composants mat´eriels enrichis avec les consommations instantan´ees.

Pour construire ce prototype, nous avons mod´ elis´ e les diff´ erents composants d’un r´ eseau de capteurs

puis nous les avons assembl´ es. C’est un des atouts de notre mod` ele, les composants sont une m ethode ´

de conception naturelle et efficace : pour concevoir un syst` eme complexe, on conc¸oit d’abord les

diff´ erents composants puis on les assemble. De mˆ eme, les composants sont pratiques pour construire

des mod` eles globaux de syst` emes complexes. Enfin, comparer deux solutions globales o u seul un `

1.5. Cadre de la th`ese

composant diff` ere permet de comparer les deux choix possibles pour ce composant dans un contexte r´ealiste.

Grˆ ace a un formalisme efficace, notre mod` ` ele est capable de simuler des r´ eseaux de capteurs de plusieurs milliers de nœuds. La simulation est une analyse int´ eressante puisqu’elle permet de visualiser quelques exemples de comportements du r´ eseau. On peut ainsi rapidement d´ etecter des erreurs de conception ou de mod elisation. Cependant, les simulations ne permettent de garantir aucune propri´ ´ et´ e.

Afin de proposer des analyses exhaustives, notre mod` ele dispose d’une s´ emantique formellement d´efinie. Cependant, les techniques de v´erification formelle ne peuvent s’appliquer sur des mod`eles de grande taille. Pour proposer ce type d’analyse et pouvoir garantir une dur´ ee de vie minimale du r´ eseau, nous avons dˆu r´eduire la taille de notre mod`ele.

Nous avons invent´ e des mod` eles moins d´ etaill´ es en nous servant de nos exp´ eriences de simulation de mod` eles complets. Grˆ ace aux mod` eles de taille r eduite ainsi construits, nous avons exhib´ ´ e des sc´ enarios de dur´ ee de vie pire-cas et montr´ e que ce type d’analyse apporte bien des informations suppl´ ementaires par rapport aux simulations. Nous avons prouv´ e des propri´ et´ es pour un mod` ele abstrait mais nous ne pouvons encore rien conclure pour le mod ele initial plus proche de la r´ ` ealit´ e. En effet, mˆ eme si nous avons utilis´ e le mod ele d´ ` etaill´ e pour construire le mod` ele abstrait, formellement aucun lien n’existe entre ces deux mod`eles.

Nous souhaiterions etre s ˆ urs que si la propri´ ˆ et´ e est vraie sur le mod` ele abstrait alors elle est forc´ ement vraie sur le mod` ele d´ etaill´ e. Pour cela, les abstractions doivent satisfaire certaines contraintes.

Comme les propri´ et´ es que nous souhaitons v´ erifier concernent la dur´ ee de vie pire-cas du r´ eseau, il faut que le mod ele abstrait consomme au moins autant que le mod` ` ele d´ etaill´ e. De plus, nous avons construit un mod` ele global a partir de composants et un moyen d’abstraire ce mod` ` ele est d’abstraire certains de ces composants. Il faut alors s’assurer qu’en abstrayant un composant dans un mod ele d´ ` etaill´ e, on obtient bien un mod` ele plus abstrait. Nous proposons donc un cadre formel dans lequel on sait d efinir ´ des abstractions qui satisfont ces deux contraintes.

Pour r´ esumer, la technique de mod´ elisation que nous proposons consiste a construire ` a l’aide de ` composants un mod` ele global et d´ etaill´ e d’un r´ eseau de capteurs. Le formalisme de ce mod` ele repose sur une s´emantique formellement d´efinie qui permet la mod´elisation de la consommation. Ce mod`ele est ex´ ecutable et donc simulable. Pour que des techniques de validation exhaustive soient r´ ealisables, il est possible de faire des abstractions conservatives pour valider des propri´ et´ es faisant intervenir la dur´ee de vie du r´eseau.

1.5 Cadre de la th`ese

Ce document pr´ esente les travaux de th` ese effectu´ es dans le cadre d’un contrat CIFRE

entre l’entreprise France T el´ ´ ecom R&D et le laboratoire Verimag. A France T´ ` el´ ecom R&D, nous travaillions au sein de l’´ equipe TECH/IDEA (anciennement TECH/ONE devenue par la suite TECH/MATIS).

C’est la premi` ere collaboration entre cette equipe de France T´ ´ el´ ecom et Verimag, ces deux partenaires ne se connaissaient pas avant le d´ ebut de la th` ese mais ont choisi de travailler ensemble pour profiter de leur compl´ementarit´e.

La recherche effectu´ ee dans l’´ equipe TECH/IDEA de France T el´ ´ ecom R&D vise a pr´ ` evoir et construire les objets communicants de demain. Dans cette ´equipe, certains conduisent des recherches exploratoires, par exemple sur les techniques de communication sans fil, d’autres ´ evaluent les terminaux existants et disponibles sur le march´ e. Cette equipe s’est naturellement int´ ´ eress´ ee aux r´ eseaux de capteurs a partir de 2003. Abdelmalik Bachir a soutenu en 2007 sa th` ` ese portant sur les protocoles

1Convention Industrielle de Formation par la Recherche

Ludovic Samper Th`ese de Doctorat 13/158

MAC et routage pour r´ eseaux de capteurs, d’autres th` eses sont en cours notamment sur les protocoles d’auto-organisation pour r´ eseaux de capteurs. Pour aborder la question de la mod´ elisation des r´ eseaux de capteurs, France T´el´ecom R&D a choisi de collaborer avec Verimag.

Le laboratoire Verimag propose des outils th´ eoriques et techniques pour le d´ eveloppement de syst` emes embarqu´ es. Les techniques de mod elisation d´ ´ evelopp´ ees a Verimag s’appuient sur une ` s´ emantique formelle qui permet de prouver des propri´ et´ es afin de garantir la s uret´ ˆ e de syst` emes embarqu´ es critiques. Parmi les domaines d’application des th´ eories d´ evelopp´ ees a Verimag, on peut ` citer l’avionique, le spatial ou les protocoles de communication. Avant le commencement de nos travaux de th` ese, Verimag ne s’´ etait jamais int eress´ ´ e aux r´ eseaux de capteurs. A Verimag, notre travail a ` et´ ´ e suivi par deux equipes : l’´ ´ equipe Synchrone et l’´ equipe DCS (Distributed and Complex Systems). Comme son nom l’indique, l’´ equipe Synchrone est sp´ ecialis´ ee dans les langages et outils de mod´ elisation synchrones. L’´ equipe DCS conc¸oit, elle, des outils de mod´ elisation asynchrone. B´ en´ eficier de cette double comp´ etence est particuli` erement int´ eressant pour etudier les r´ ´ eseaux de capteurs qui sont des syst` emes globalement asynchrones et localement synchrones, des GALS (pour Globally Asynchronous, Locally Synchronous).

Peu apr` es le d´ ebut de la th` ese, France T´ el´ ecom R&D, Verimag et d’autres partenaires ont r´ epondu

`

a un appel a projet RNRT `

. Le projet ARESA [1] a et´ ´ e labellis´ e en juin 2006. Notre travail de th` ese s’est donc naturellement inscrit dans le contexte de ARESA. Les autres partenaires sont les laboratoires Tima, LIG et le CITI qui travaillent respectivement sur le mat´ eriel, les protocoles de communication et l’auto-organisation dans les r´ eseaux de capteurs ; et l’entreprise Coronis Systems. Coronis Systems d eploie des r´ ´ eseaux de capteurs, sa pr´ esence dans le projet est donc tr` es enrichissante puisqu’elle apporte une exp´erience industrielle des r´eseaux de capteurs.

1.6 Contenu du document

1.6.1 R´esum´e des contributions

Nous r´esumons ici les contributions pr´esent´ees dans cette th`ese.

– Nous avons propos e une mod´ ´ elisation math´ ematique pour analyser les performances de diff´erentes variantes d’un protocole MAC, chapitre 3. Nous avons mod´elis´e le syst`eme `a l’aide de probabilit es puis l’avons ´ evalu´ ´ e, en fonction du taux d’erreur sur le canal, selon deux crit eres : ` la fiabilit´ e et la consommation. Ce travail a et´ ´ e r´ ealis´ e avec Abdelmalik Bachir pour mieux comprendre le fonctionnement de nouveaux protocoles MAC. Nous insistons ici sur notre contribution : la mod´elisation.

– Pour construire nos mod` eles a l’aide d’une s´ ` emantique formellement d´ efinie, nous avons etudi ´ e ´ les techniques de mod´ elisation de la consommation d’´ energie utilisant le formalisme des auto- mates. Nous avons compar´e les diff´erentes approches `a la section 4.2.

– Nous avons conc¸u un simulateur d´ edi´ e aux r´ eseaux de capteurs. Ce simulateur, appel e G ´

, r epond aux contraintes que nous nous ´ etions fix´ ´ ees : il est global, pr´ ecis et ecrit dans un langage ´ formellement d´ efini, R

ML. R

ML est un langage conc¸u par Louis Mandel qui a ´egalement contribu´e `a la r´ealisation G

. Ce travail est d´etaill´e `a la section 5.1.

– Nous avons montr´ e qu’il est indispensable d’avoir un mod` ele d’environnement pour simuler un r´eseau de capteurs de mani`ere r´ealiste. Section 5.2.

– Par la r´ ealisation de ce simulateur, il nous est apparu que le langage synchrone R

ML est particuli` erement bien adapt´ e a la programmation de simulateurs. Nous d´ ` etaillons pourquoi

2R´eseau National de Recherche en T´el´ecommunications

1.6. Contenu du document

section 5.4.

– Nous avons propos´ e un mod` ele tr` es abstrait qui permet de v´ erifier des propri et´ ´ es de dur ee de vie ´ d’un r´ eseau de capteurs. Ce travail montre la faisabilit´ e des techniques de v erification formelle ´ sur un mod` ele abstrait de r´ eseau de capteurs en supposant que l’on sache obtenir de fac¸on correcte un tel mod` ele. Plusieurs contributions ici : la mod´ elisation d’un r´ eseau a l’aide du ` formalisme asynchrone IF (section 6.2), la modification des outils d’exploration du graphe d’´ etat pour obtenir les dur´ees de vie pire cas (section 6.3).

– Nous avons transform e G ´

en L

pour avoir des mod` eles d´ etaill´ es ecrits en L ´

ce qui nous rapproche de la v´erification formelle. Section 5.3.

– Nous avons propos´ e, section 7.2, une formalisation de la notion d’abstraction pour des mod` eles qui consomment de l’´ energie. Notre formalisme permet de d´ efinir des abstractions de composants qui d´ ependent du contexte d’ex´ ecution. Si le mod` ele global garantit ce contexte d’ex´ ecution, il est alors possible de remplacer dans le mod` ele global un mod` ele d´ etaill´ e d’un composant par un mod` ele abstrait pour obtenir un mod` ele global plus abstrait. Nous illustrons notre formalisme avec un exemple issu des r´ eseaux de capteurs : composition d’un mod` ele de MAC avec des mod`eles plus ou moins abstraits de radios, section 7.1.

1.6.2 Plan du document

– Le chapitre 2 pr´ esente les r´ eseaux de capteurs de fac¸on plus pr´ ecise que cette introduction. Il contient egalement les principales r´ ´ ef´ erences bibliographiques concernant les travaux sur la mod´elisation de r´eseaux de capteurs

– Le chapitre 3 est une etude analytique qui nous a permis de comparer diff´ ´ erents protocoles MAC.

– Le chapitre 4 synth´ etise les diff´ erentes techniques et th´ eories de mod´ elisation d evelopp´ ´ ees, entre autre, a Verimag. Section ` 4.2, nous etudions les diff´ ´ erents moyens d’´ etendre ces techniques pour prendre en compte la consommation. La section 4.4 pr´ esente rapidement les outils de mod elisation que nous utilisons par la suite. Apr` ´ es le chapitre 4, la partie III constitue le cœur de notre travail de th`ese.

– Le chapitre 5 est d´ edi´ e a nos travaux sur la simulation de r´ ` eseaux de capteurs. Il d´ etaille notre simulateur G

, puis montre l’importance d’inclure un mod` ele d’environnement dans un simulateur de r´ eseaux de capteurs. La section 5.3 d´ ecrit la transformation de G

en un mod` ele L

. Section 5.4, nous montrons que R

ML convient ` a la programmation de simulateurs en insistant sur les diff´ erences entre le mode de simulation a pas fixes de ` R

ML et celui a ` ´ ev´ enements discrets utilis´ e le plus souvent dans les simulateurs de r´eseaux.

– Le chapitre 6 d´ ecrit la mod´ elisation et la v´ erification d’algorithmes de routage en IF. La sec- tion 6.2 explique comment nous avons mod´ elis´ e de fac¸on assez abstraite un r´ eseau de capteurs

`

a l’aide des primitives de communication asynchrone. La section 6.3 d´ etaille l’algorithme de recherche du sc´enario de dur´ee de vie pire cas.

– Le chapitre 7 introduit, via un exemple issu des r´ eseaux de capteurs, un cadre formel qui permet d’´ecrire des relations d’abstraction prenant en compte l’´energie.

– Le chapitre 8 conclut cette th`ese et pr´esente les perspectives de recherche `a ce travail.

Ludovic Samper Th`ese de Doctorat 15/158

Premi`ere partie

Contexte, travaux li´es

17

Chapitre 2

Les r´eseaux de capteurs

Sommaire

2.1 Contexte des r´eseaux de capteurs . . . . 19

2.1.1 Applications . . . . 19

2.1.2 Protocoles de routage . . . . 22

2.1.3 Protocoles d’acc`es au m´edium . . . . 25

2.1.4 Mat´eriel . . . . 28

2.2 Besoins pour la conception de ces syst`emes . . . . 31

2.3 M´ethodes usuelles de mod´elisation pour les r´eseaux de capteurs . . . . 33

2.3.1 Les simulateurs de r´eseaux . . . . 34

2.3.2 Mod´elisation pour l’´evaluation de performance . . . . 37

2.3.3 Mod´elisation pour la v´erification formelle . . . . 38

2.4 Notre approche : du prototypage rapide r´ealiste et analysable . . . . 39 Nous pr´ esentons ici les enjeux li es ´ a la conception des r´ ` eseaux de capteurs. Pour bien comprendre les difficult es de mod´ ´ elisation auxquelles doivent faire face les concepteurs de tels r´ eseaux, la section 2.1 donne quelques exemples de r´ eseaux de capteurs. Elle commence par l’introduction de quelques applications types puis explique les solutions protocolaires et mat´ erielles que l’on trouve dans la litt´erature.

Nous en d´ eduisons dans la section 2.2 quels sont les besoins pour le d´ eveloppement des r´ eseaux de capteurs. Dans la section 2.3 nous pr´ esentons les diff´ erentes solutions existantes pour la mod´ elisation des r´ eseaux de capteurs. Pour chaque type de solutions, nous donnons quelques r´ ef´ erences bibliogra- phiques. Etant donn´ ´ e le grand nombre de simulateurs par exemple, celles-ci ne seront pas exhaustives.

Apr` es cet etat de l’art, nous expliquerons notre approche pour aider ´ a la conception des r´ ` eseaux de capteurs : du prototypage rapide, r´ealiste et analysable, section 2.4.

2.1 Contexte des r´eseaux de capteurs

2.1.1 Applications D´etection de feux de forˆet

Comme nous l’avons soulign´ e en introduction, les r´ eseaux de capteurs se prˆ etent particuli` erement bien a des applications de remont ` ees d’alarmes o` ´ u la zone a surveiller est difficile d’acc` ` es. Les r´ eseaux

19

de capteurs sont notamment pressentis pour aider a la surveillance et ` a la pr ` evention des feux de ´ forˆ et. L’application consiste a d´ ` eployer un r´ eseau de capteurs qui permet, d’alerter les secours en cas d’incendie, et d’ evaluer le risque de d´ ´ epart de feux grˆ ace ` a des relev´ es p´ eriodiques (temp´ erature, humidit´ e ...). Les nœuds d’un tel r´ eseau sont donc equip´ ´ es de capteur de temp´ erature, d’humidit´ e et infrarouge.

Sans les nouvelles solutions apport´ ees par les r´ eseaux de capteurs, une personne, plac´ ee sur un mirador, est charg´ ee de surveiller la forˆ et en continu. Non seulement cette m´ ethode n’est pas toujours faisable suivant la configuration de la forˆ et mais en plus la d´ etection des premi` eres flammes est tardive.

Dans cette application, le r´ eseau a deux tˆ aches. Une tˆ ache consiste a envoyer p´ ` eriodiquement l’´ etat de ses capteurs pour permettre la pr´ evention. Il faut d´ ecider de la p´ eriode n´ ecessaire, envoyer trop souvent une information sur la temp´ erature peut s’av´ erer inutile et co uteux en ˆ energie. L’autre tˆ ´ ache consiste a envoyer une alarme en cas de d´ ` etection de feux. Cette tˆ ache est plus critique : il faut que l’alarme arrive au puits et qu’elle ne mette pas trop longtemps a arriver. Un puits est un nœud non ` contraint en energie qui collecte les donn´ ´ ees et les envoie (via Internet par exemple) au centre de traitement.

Comme les nœuds sont inaccessibles, ou du moins on ne sait pas les localiser pr´ ecis´ ement, ils ne sont pas recharg´ es en energie. Donc, une fois qu’un nœud a ´ epuis´ ´ e son energie, il disparaˆ ´ ıt du r´ eseau, et quand tous les nœuds n’ont plus d’´ energie, le r´ eseau est mort. En fait, le r´ eseau est de moins en moins op´ erationnel au fur et a mesure que les nœuds disparaissent. Pour prolonger la vie du r´ ` eseau, on peut vouloir ajouter de nouveaux nœuds, mais dans ce cas il faut un m´ ecanisme d’auto-association pour que ces nouveaux nœuds int`egrent le r´eseau.

Dans une telle application de surveillance d’environnement, il paraˆ ıt tr` es probable que les donn´ ees des capteurs soient corr´ el´ ees en temps et en espace. En effet, si un feux se d´ eclenche, il va se propager ; donc lorsqu’un capteur d´ etecte un incendie, il est fort probable que ses voisins aient egalement des ´ alarmes a envoyer. Cette corr´ ` elation des stimuli pose plusieurs probl` emes. Tout d’abord, les nœuds vont envoyer la mˆ eme information plusieurs fois, ils vont donc d´ epenser inutilement leur energie. De ´ plus, plusieurs messages emis en mˆ ´ eme temps peuvent cr´ eer des collisions. Celles-ci sont souvent coˆ uteuses en energie puisqu’elles impliquent des retransmissions, elles peuvent mˆ ´ eme empˆ echer le message d’arriver a sa destination. Pour ` eviter ces probl` ´ emes de redondance et donc limiter les d´ epenses

´

energ´ etiques des capteurs, certains evoquent la possibilit´ ´ e de n’activer que certains nœuds. L’id´ ee est de n’activer simultan´ ement que le nombre de nœud n´ ecessaire pour surveiller la forˆ et. Un roulement doit s’effectuer pour que les nœuds actifs ne soit pas toujours les mˆemes. C’est un challenge de concevoir de tels algorithmes de couverture de surface pour lequel des outils sont n´ecessaires.

Une autre application avec des contraintes semblables est celle qui consiste a contrˆ ` oler les secousses sismiques dans les bˆ atiments. L’id´ ee est de doter les bˆ atiments de capteurs d` es la construction. Ceux-ci sont enfouis dans les fondations et d´etectent les diff´erents efforts. Ils permettent donc de pr´evenir des affaiblissements de la structure du bˆ atiment d` es les premiers effets. Ainsi, on pourra consolider le bˆ atiment avant que les fissures ne soient irr´ eparables. Au vu du trafic, cette application a des contraintes semblables a la pr´ ` ec edente, le trafic est tr` ´ es sporadique. De mˆ eme, on peut difficilement remplacer les nœuds morts.

T´el´e-gestion de compteurs d’´energie, une application phare pour Coronis Systems

La rel` eve automatique d’index de compteurs d’eau, de gaz d’´ electricit´ e et de chaleur est une application qui emerge en Europe tandis que tr ´ es largement exploit´ ` ee depuis de nombreuses ann ees ´ aux USA en raison de la r´ eglementation.qui a impos´ e un paiement mensuel des consommations r´ eelles.

La t´ el´ e-rel` eve (ou “metering” en anglais) consiste a doter les compteurs d’une fonction communicante `

2.1. Contexte des r´eseaux de capteurs

(PLC, radio, bus s´ erie) qui permet une supervision automatis´ ee, au moyen d’´ equipements de rel` eve mobiles (PDA, TSP, v ehicule) ou bien grˆ ´ ace a des r´ ` eseaux fixes, et ce, afin d’´ eviter une lecture manuelle des index.

Coronis Systems est une jeune soci´ et´ e Montpelli´ eraine cr´ e´ ee en 2000, sp´ ecialis´ ee dans les technolo- gies radio ultra basse consommation, longue port´ ee et bas co ut. Fort de l’exp´ ˆ erience de ses fondateurs, Coronis Systems a elabor´ ´ e et d´ evelopp´ e la technologie Wavenis.Avec les plateformes OEM d´ evelopp´ ees sur la base du cœur de cette technologie, Coronis Systems se positionne en fournisseur de solutions radio-communicantes pour toutes les applications qui requi` erent un faible volume d’information ` a transmettre, un faible trafic radio, et qui, pour les plus critiques, pr´ esentent de tr` es fortes contraintes

´

energ´ etiques associ´ ees a des conditions d’acc` ` es radio difficiles. L’un des march´ es les plus matures dans ce domaine est la t´ el´ e-rel` eve des compteurs d’´ energie avec des demandes consid´ erables dans le secteur des particuliers mais aussi des industriels. La technologie Wavenis a et´ ´ e conc¸ue et optimis´ ee pour automatiser la supervision de r´ eseaux radio de capteurs, encore d´ esign´ e sous le terme g´ en´ erique de Machine-to-Machine (M2M).

Dans le cadre du projet ARESA, c’est avec Coronis Systems que le partenariat a ´et´e ´etabli.

Prenons l’exemple de la ville des Sables d’Olonnes qui a et´ ´ e la premi ere ville ` ´ equip´ ee de la technologie Wavenis coupl ee au r´ ´ eseau GSM pour assurer la supervision a distance des 25,000 ` compteurs d’eau. En partenariat etroit avec la SAUR, le r´ ´ eseau surveille 100% des compteurs d’eau de la ville depuis 2004. Il permet en toute priorit´ e de relever p´ eriodiquement et plus fr´ equemment la consommation en eau des foyers sans avoir a mobiliser un technicien. Cette automatisation permet ` notamment d’´ etablir des profils de consommateur grˆ ace a des rel` ` eves quotidiennes au besoin, au lieu d’une a deux fois par an. Grˆ ` ace a cette technologie radio bi-directionnelle et une gestion des alarmes ` spontan´ ees, elle permet, en outre, de d´ etecter des fuites d’eau dans le r´ eseau ou chez les particuliers, dans le cas d’une consommation anormale.

Ce cas d’´ etude comporte de nombreuses contraintes que l’on retrouve dans les r´ eseaux de capteurs.

Essentiellement, les nœuds sont autonomes en energie. En effet, m ´ eme si l’on peut imaginer que les ˆ nœuds soient aliment´ es par une connexion au r´ eseau electrique, pour limiter le coˆ ´ ut du d´ eploiement d’un tel r´ eseau, ils sont autonomes. La solution consiste a remplacer les anciens compteurs purement ` m ecaniques par un ensemble compos´ ´ e d’un compteur d’eau ” nouvelle g´ en´ eration ” capable de d´ elivrer des informations (impulsions, bus s´erie) et d’un ´emetteur-r´ecepteur radio aliment´e sur pile.

Cette limitation du budget energie implique une autre contrainte typique des r´ ´ eseaux de capteurs : les nœuds envoient leurs messages en multi-sauts jusqu’au point de collecte quand ils ne sont pas ` a port´ ee radio directe. Ils sont coop´ eratifs : un compteur d’eau peut avoir a relayer les consommations ` d’autres compteurs bien que des ´equipements r´ep´eteurs soient pr´ef´er´es pour remplir cette fonction.

G´ en´ eralement dans le metering, l’autonomie d’un r´ eseau autonome doit atteindre plusieurs ann´ ees pour en assurer la rentabilit e. Les nouvelles exigences du march´ ´ e portent d´ esormais sur des autonomies de 10, 15 voire 20 ans. L’autonomie se calcule g´ en´ eralement au travers d’une analyse pouss´ ee du MTBF (Mean Time Between Failure) sur les cartes et les composants, avec des tests de vieillissement acc´ el´ er´ e en laboratoire, une emulation du comportement radio (et donc de consommation d’´ ´ energie), et des tests de qualification pouss ee sur les piles en partenariat avec les fabricants de pile (SAFT par ´ exemple).

Pour arriver `a cette autonomie, pour ´eviter d’impacter significativement l’autonomie des modules radio coupl es aux compteurs d’eau, Coronis Systems a ´ elabor´ ´ e un deuxi eme type de nœuds radio, ` disposant de plus d’autonomie energ´ ´ etique (pile plus grosse, donc modules plus coˆ uteux) et plus puissants (puissance radio 500mW) qui sont install es en ext´ ´ erieur sur des points hauts (lampadaires, pyl ones ˆ electriques) pour favoriser la couverture radio ´ a l’´ ` echelle d’un quartier, d’une ville. Ces nœuds sont uniquement exploit es pour assurer la fonction de relais radio, leur rˆ ´ ole est donc de relayer les

Ludovic Samper Th`ese de Doctorat 21/158

messages des compteurs jusqu’`a la Gateway Wavenis - GSM/GPRS.

Cette collaboration avec Coronis Systems nous a permis d’avoir une etude de cas concr` ´ ete d’un r´eseau d´ej`a d´eploy´e.

En juin 2007, Elster Group, le 1er fabricant mondial des compteurs d’´ energie (1,6 milliards EUR de CA) a rachet e Coronis Systems pour devenir le leader mondial des solutions metering AMI (Advanced ´ Monitoring Infrastructure), ce qui illustre bien la pertinence de la technologie radio Wavenis de Coronis Systems pour les r´eseaux de capteurs.

Domotique

Un autre type d’application dans lequel les r´ eseaux de capteurs ´ emergent est la domotique. Dans ces applications, le r eseaux de capteurs est d´ ´ eploy´ e dans l’habitation. Le principe est que le r´ eseau de capteur forme un environnement, dit environnement pervasif. Son but est de fournir toutes les informations n´ ecessaires aux applications de confort, de s ecurit´ ´ e et de maintenance dans l’habitat. Les capteurs sont des capteurs de pr esence, de son, ils peuvent mˆ ´ eme etre ˆ equip´ ´ es de cam´ eras. Un tel r´ eseau d´ eploy´ e doit permettre de cr´ eer une maison intelligente capable de comprendre des situations suivant le comportement des occupants et d’en d´eduire des actions.

Ces r´ eseaux sont donc tr` es h´ et´ erog` enes, des el´ ´ ements d’´ electrom´ enager peuvent faire partie du r´ eseau aussi bien que les ordinateurs personnels ou le routeur. Il se peut que certains el´ ´ ements aient besoins d’ˆ etre economes en ´ ´ energie mais c¸a n’est pas le cas de tout le r´ eseau. Il ne s’agit pas pour ces applications de r´ eseaux grande echelle. Ces r´ ´ eseaux doivent etre hautement reconfigurable : d’une part ˆ la topologie du r´ eseau peut changer d’un jour a l’autre avec l’am´ ` enagement, d’autre part on peut avoir besoin de changer le type d’application pendant la vie du r´eseau.

Le consortium Zigbee, s’appuyant sur les couches 1 et 2 standardis´ ees IEEE802.15.4, r´ epond assez bien aux contraintes de ces r´ eseaux qui sont finalement assez eloign´ ´ es des cas d’´ etude que l’on propose.

Cependant, nos travaux sur la mod´ elisation de syst` emes economes en ´ energie pourront certainement ´ servir ´egalement `a ce genre d’application.

2.1.2 Protocoles de routage

Le routage consiste a trouver un chemin pour envoyer le message de la source ` a la destination. ` Dans le cadre des r´ eseaux de capteurs, le routage doit etre efficace en ˆ energie. Pour cela, il faut bien sˆ ´ ur ˆ

etre capable de trouver une route qui ne coˆ ute pas trop d’´ energie, une route pas trop longue. Mais il faut aussi etre capable de trouver ou de maintenir les routes sans d´ ˆ epenser trop d’´ energie. Les protocoles dans lesquels on maintient a jour des tables de routage ` a l’aide d’envois p´ ` eriodiques de paquets “hello”

ont un coˆ ut constant non n´ egligeable. Ce coˆ ut constant est particuli` erement p´ enalisant puisque l’on a des trafics tr`es sporadiques : maintenir une table de routage, pour avoir des routes tr`es efficaces, n’est pas int´eressant si l’on n’utilise que tr`es rarement ces routes.

Les protocoles de routage sp´ ecifiques aux r´ eseaux de capteurs doivent tenir compte du type de communications induit par l’application. Outre le fait que la quantit´ e de donn´ ees echang ´ ees est tr` ´ es faible par rapport aux applications de types r´ eseaux ad hoc, notons que le trafic est particuli` erement pr´evisible puisqu’il va des nœuds vers le puits ou du puits vers les nœuds.

Nous ne faisons pas ici un etat de l’art des protocoles de routages. Nous voulons seulement ´

pr´ esenter des protocoles types des r´ eseaux de capteurs. Nous d´ etaillons ceux que nous avons choisis

dans nos diff erents exemples de mod´ ´ elisation. Nous les avons choisi parce qu’ils sont repr´ esentatifs

des protocoles de routage pour r´eseaux de capteurs.

2.1. Contexte des r´eseaux de capteurs

Sink Source

Source

Source

(a) Envoi de l’int´erˆet

Sink Source

Source Source

(b) Installation des gradients

Event

Sink Source

Source

Source

(c) Envoi des alarmes

F

. 2.1 – Sch´ema du m´ecanisme de routage diffusion dirig´ee

Inondation

L’inondation (“flooding”, en anglais) consiste ` a envoyer un message a tout le r´ ` eseau. L’´ emetteur envoie le message a tous ses voisins. Chaque voisin envoie ` a son tour le message ` a tous ses voisins ` et ainsi de suite. Les nœuds vont donc recevoir le mˆ eme message plusieurs fois de diff´ erents voisins.

Pour eviter que le message ne se multiplie dans le r´ ´ eseau, chaque nœud ne le renvoie qu’une seule fois.

Pour ce faire, chaque message envoy´ e en inondation a un identifiant unique. Les nœuds qui r´ e- emettent ´ le message notent l’identifiant. S’ils rec¸oivent a nouveau un message avec cet identifiant, ils ne le ` renvoient pas.

Diffusion dirig´ee

L’algorithme de diffusion dirig´ ee (“directed diffusion”, en anglais) a et´ ´ e propos´ e en 2000 ( [42]).

Depuis, de nombreuses am´eliorations ont ´et´e propos´ees. Nous pr´esentons rapidement son principe, le lecteur int´eress´e est encourag´e `a lire le papier [43].

Le principe de l’algorithme est le suivant : le puits envoie une requˆ ete a tout le r ` eseau. Cette requˆ ´ ete est envoy´ ee a l’aide du m´ ` ecanisme de routage pr´ ec´ edent, l’inondation. Les nœuds concern´ es par cette requˆ ete r´ epondent au puits en envoyant un message qui emprunte la route inverse. Pour cet algorithme, on suppose que les liens radio sont bidirectionnels. Il s’agit d’un algorithme local, les noeuds n’ont que la connaissance de leur voisinage. Pour joindre le puits, un noeud envoie son message au nœud duquel il a rec¸u en premier le message du puits. Chaque noeud a seulement besoin de savoir par quel voisin il pourra joindre le puits. Ce voisin ayant egalement connaissance d’un nœud grˆ ´ ace auquel il pourra joindre le puits, de proches en proches, le message arrivera `a destination.

Le puits envoie donc sa requˆ ete a tous les nœuds du r´ ` eseau a l’aide de l’inondation, voir figure ` 2.1.

Les nœuds rec¸oivent alors le mˆ eme message de plusieurs de leurs voisins. Ils m´ emorisent quel nœud leur a envoy´ e l’int´ erˆ et en premier. C’est a ce nœud qu’ils enverront les donn´ ` ees (rec¸ues ou mesur ees ´ localement) destin´ ees au puits. Avoir des liens radio bidirectionnels est essentiel : on consid` ere que

Ludovic Samper Th`ese de Doctorat 23/158

3 Collecteur

Niveau 1

2 0

Lien rompu

A B

C

Compteurs d’eau

F

. 2.2 – Routage utilis´e par Coronis Systems pour un r´eseau de compteurs d’eau

le chemin le plus rapide du nœud au puits est aussi le chemin le plus rapide du nœud au puits. On dit que les nœuds installent des gradients, figure 2.1(b). Sur l’exemple repr´ esent´ e figure 2.1, l’int´ erˆ et ne concerne que les nœuds “Source”, a gauche du r´ ` eseau. La requ ete demande que l’on envoie une ˆ alarme si un ev´ ´ enement est d´ etect´ e. L’´ ev´ enement est ensuite d´ etect´ e par trois capteurs (figure 2.1(c)).

Mais seuls les deux nœuds concern es par l’int´ ´ erˆ et vont envoyer un message. Le message est envoy´ e en suivant le gradient, c’est-` a-dire au voisin par lequel le nœud a rec¸u la requˆ ete du puits. Celui-ci, mˆ eme s’il n’est pas concern´ e par la requˆ ete, a etabli un gradient et sait ´ a quel nœud il doit envoyer le message. ` Et ainsi de suite, de voisin en voisin, jusqu’au puits.

Il existe aussi des m´ ecanismes dit de renforcement pour consolider certaines routes. Diff´ erents m´ecanismes sont propos´ees, on ne les d´etaillera pas ici.

Le but de cet algorithme est donc de fournir un protocole de routage et d’organisation pour des applications dans lesquelles un puits pilote le r´ eseau en envoyant des requˆ etes et en r´ ecup´ erant les donn´ ees. Les requˆ etes peuvent etre ponctuelles, par exemple pour demander le relev´ ˆ e de mesure ` a l’instant courant. Elles peuvent etre p´ ˆ eriodiques, exemple : “envoyez-moi la temp´ erature tous les jours”.

Enfin, elles peuvent d´ ependre des capteurs : “si la temp´ erature exc` ede un certain seuil, envoyez une alarme”. Les auteurs appellent les paquets emis par le puits des int´ ´ erˆ ets ce qui montre bien que le puits est int´eress´e par une certaine information disponible `a l’aide de son r´eseau.

La solution de Coronis Systems

Bas´ ee sur sa forte exp´ erience du terrain, et afin d’optimiser la consommation d’´ energie, Coronis Systems a elabor´ ´ e une proc´ edure semi-automatique d’installation des compteurs d’eau. En effet, selon la topologie et la g´ eographie du terrain, les techniciens sp´ ecifient des conditions initiales qui peuvent varier d’un quartier a l’autre. De ce fait, l’algorithme de routage automatique pourra ” court-circuiter ” ` les 1eres it´ erations et converger plus rapidement vers l’appairage optimal en r´ eduisant de ce fait le bilan

´

energ´ etique li´ e a l’installation. Il faut noter qu’un m´ ` ecanisme de routage et d’auto-organisation comme le pr´ ec´ edent n ecessite un certain nombre de messages lors des phases d’initialisation. Ces messages ´ d´ epensent de l’´ energie et impactent naturellement l’autonomie d’´ energie des nœuds du r´ eseau et du r´eseau dans sa globalit´e.

N´ eanmoins, grˆ ace a une tr` ` es grande sensibilit´ e des r´ ecepteurs radio et une qualit´ e de service (QoS)

2.1. Contexte des r´eseaux de capteurs

d efinie avec les param` ´ etres suivants (niveau dans le r´ eseau, RSSI, energie restante dans la pile, nb ´ de devices attach´ es, Class of Device), le broadcast des messages est non seulement tr` es s´ electif pour restreintre les communications non d esirables mais aussi permet d’´ ´ elablir un lien radio robuste (avec 10dB de marge au dessus du seuil de sensibilit´e des r´ecepteurs qui atteint -113dBm.

A ce stade de maturit´ e des algorithmes d’auto-routage, sachant que les sites pilotes devront etre ˆ

´

eprouv es avant d’envisager des d´ ´ eploiements de masse a l’´ ` echelle de plusieurs centaines de milliers de points, la solution a ce jour pr´ ` econis´ ee par Coronis Systems consiste ` a installer et configurer l’infrastructure (gateway et r´ ep´ eteurs) du r´ eseau ” a la main ” tout comme le font les op´ ` erateurs de t´ el´ ecom pour leur r´ eseau GSM pour l’installation des ” base stations ”. Pour ce faire, l’agent d´ eploie le r eseau en configurant d’abord les nœuds (r´ ´ epteurs et capteurs a port´ ` ee radio) pr` es du point d’acc` es collecteur (gateway ou puits). C’est lui qui va, ` a l’aide d’un PC-portable (PDA avec compact flash Wavenis), donner l’ordre au capteur d’initialiser son routage. C’est ici que la connexion du capteur au r´eseau suit la proc´edure automatique selon l’algorithme de routage automatique Wavenis.

Le but de l’algorithme de Wavenis est d’avoir un routage en arbre dont la racine est le collecteur, voir figure 2.2. Wavenis d´ efinit un niveau de profondeur de l’arbre. Le puits est donc de niveau 0.

Le nœud qui s’appaire a un niveau 0 devient un niveau 1. Le nœud qui s’appaire avec un niveau 1 ` devient un niveau 2 , etc. La profondeur maximale d´ efinie par Wavenis est 4, soit 4 sauts au maximum.

L’algorithme evolue par it´ ´ eration. Le nœud que l’on veut configurer dans le r´ esau envoie une requˆ ete du type : ”Qui est de niveau X avec une QoS meilleure que Y ?”. Seules les stations de niveau X qui rec¸oivent le message et qui offrent une meilleure qualit´ e de service (QoS) que Y, r´ epondent. Tous les autres modules s’interdisent de r´ epondre. Si plusieurs stations r´ epondent, le nœud va coisir son meilleur parent en fonction de la QoS (d´ ependant en toute premi` ere approximation de la puissance du signal rec¸u (RSSI, Receiver Signal Strength Indicator). A la premi` ere it´ eration, soit X=0, ce qui revient

`

a chercher en priorit´ e le puits du r´ eseau, soit le technicien aura ” forc e ” un niveau inf´ ´ erieur selon sa connaissance de l’infrastructure locale du r eseau. Si le nœud ne trouve pas d’´ ´ el´ ement de niveau X avec la bonne QoS, il peut soit rechercher un ´ el´ ement de niveau X-1 (sans d´ egrader la QoS), ou bien relancer une recherche plus risqu´ee en d´egradant la QoS etc...

En cas de rupture d’un lien radio, si un nœud n’arrive plus a joindre le puits (ou collecteur), comme ` c’est le cas du nœud A sur la figure2.2, le nœud va chercher une nouvelle route. Cette op´ eration se fait cette fois-ci automatiquement sans intervention humaine. Le nœud connaˆ ıt son ancien rang, il ne va donc pas partir de z´ ero. Il va tout de suite rechercher un terminal de mˆ eme niveau que celui auquel il etait enr ´ ol´ ˆ e auparavant, ici un terminal de niveau 1. S’il n’en trouve pas il cherchera un nœud de niveau sup´erieur.

La table de routage compl` ete est m´ emoris´ ee par la station de base dans un tableau. Ce nœud n’´ etant pas limit´ e en energie et m´ ´ emoire, c¸a n’est pas un probl` eme. Les compteurs ne m´ emorisent que leur route jusqu’au collecteur.

2.1.3 Protocoles d’acc`es au m´edium

Le rˆ ole du protocole d’acc es au m´ ` edium (MAC pour “Medium Access Control”, en anglais) est d’organiser l’acc` es au canal de communication. Pour les r´ eseaux sans fil, cette tˆ ache est difficile.

Principalement deux raisons a cela : premi` ` erement, le canal de communication est partag´ e entre les nœuds voisins ; et deuxi` emement, le canal radio n’est pas fiable. En effet, un four a micro-ondes en ` marche ou un nouvel obstacle comme un camion peuvent changer compl` etement la topologie en cr´ eant des interf´erences ou en r´eduisant la port´ee des nœuds.

De mˆeme que pour les protocoles de routage, l’´etude de nouveaux protocoles d’acc`es au m´edium d edi´ ´ es aux r´ eseaux de capteurs est un domaine de recherche tr` es actif. Pour les r´ eseaux de capteurs, il

Ludovic Samper Th`ese de Doctorat 25/158

faut compter avec les difficult´ es traditionnelles tout en minimisant la consommation d’´ energie. Nous reviendrons plus loin sur les sources de consommation des nœuds, mais il faut noter qu’une radio de faible puissance consomme a peu pr` ` es autant en emission, en r´ ´ eception et en ecoute passive, c’est- ´ a-dire ` quand elle est allum´ee pour sonder le canal. Par contre elle ne consomme pas si elle est ´eteinte.

Les causes de surconsommation sont donc :

– L’´ ecoute libre (“idle listening”), lorsqu’un nœud a sa radio allum´ ee parce qu’il attend un paquet o`u pour voir s’il y a du trafic alors qu’il n’y a rien.

– Les collisions entre trames causent des consommations inutiles. Les r´ ecepteurs et les emetteurs ´ ont d´epens´e de l’´energie pour rien. Parfois les collisions entraˆınent des retransmissions.

– Quand un nœud rec¸oit une trame qui ne lui est pas destin´ ee, il d´ epense de l’´ energie inutilement.

Ce cas de figure est appel´e sur-´ecoute (“overhearing”).

– Le protocole MAC lui-mˆ eme peut avoir besoin de messages de contrˆ ole qui contribuent a des ` pertes d’´ energie. Les acquittements, par exemple, sont des paquets envoy´ es par le r´ ecepteur pour confirmer qu’il a bien rec¸u les donn´ees. Envoyer et recevoir ce paquet a un coˆut.

Pour r´ eduire la consommation, le protocole MAC doit permettre de garder la radio eteinte le plus ´ longtemps possible. Le cas parfait est de n’allumer la radio que pour recevoir et emettre le paquet de ´ donn ees utiles. Les nœuds ne communiquant que via leurs radios, c’est impossible en pratique. D` ´ es lors, il existe principalement deux approches.

La premi` ere consiste a synchroniser les nœuds. SMAC [89] est typiquement un de ces proto- ` cole. Tous les nœuds s’allument en mˆ eme temps, s’envoient les paquets n ecessaires ´ a maintenir leur ` synchronisation puis, si besoin, envoient les donn´ ees. Ce protocole permet donc d’´ eteindre la radio r´ eguli` erement mais c¸a n’est peut- etre pas encore suffisant s’il y a tr` ˆ es peu de trafic. Dans ce cas, les nœuds s’allument p´ eriodiquement pour n’´ echanger que des paquets de contrˆ ole afin de rester synchronis es, mais n’envoient pas de donn´ ´ ees. Le nombre de paquets emis contenant de l’information ´ utile pour l’application devient faible par rapport au nombre total de paquets ´emis.

Nous d´ etaillons plus la seconde m´ ethode dite a ` echantillonnage de pr´ ´ eambule parce que c’est celle que l’on a utilis ee comme exemple. Mais tout d’abord, nous expliquons rapidement le m´ ´ ecanisme d’acquittement qui est utilis´e dans de nombreux protocoles MAC.

M´ecanisme d’acquittement

Le canal radio n’est pas fiable, des erreurs dues a des collisions ou ` a du bruit peuvent engendrer la ` perte d’un paquet ´ emis. Pour eviter que trop de paquets soient perdus, les protocoles MAC impl´ ´ ementent souvent un m´ ecanisme d’acquittement. Apr` es avoir envoy´ e un paquet de donn´ ees, le nœud r´ ecepteur attend un paquet d’acquittement (not´ e ACK pour acknowledgment) que son destinataire doit envoyer a ` la r´ eception d’un paquet de donn´ ees. Le paquet ACK est un tout petit paquet qui est emis juste apr` ´ es la r´ eception du paquet de donn´ ees. Comme le paquet de donn´ ees a et´ ´ e rec¸u et que le paquet ACK est court, il a tr` es peu de chances d’entrer en collision. Si l’´ emetteur ne rec¸oit pas l’acquittement, il consid` ere donc que son paquet n’a pas et´ ´ e rec¸u. Il peut le cas ´ ech´ eant r´ e-´ emettre le paquet, apr` es un certain d elai par exemple. Ce m´ ´ ecanisme ne fonctionne plus lorsqu’un paquet est destin´ e a plusieurs ` r´ ecepteurs. En effet, dans ce cas, les multiples acquittements envoy´ es simultan´ ement entreraient en collisions et le nœud ´emetteur du paquet ne pourrait en recevoir correctement aucun.

Protocoles `a ´echantillonnage de pr´eambule

Dans les protocoles a ` echantillonnage de pr´ ´ eambule (“preamble sampling MAC protocols”) les

nœuds ne se synchronisent pas a l’aide de paquets de contr ` ole. ˆ A la place, ils sondent le canal `