Conception d’un prototype de plateforme pour l’étude d’aspects haut niveau dans un réseau de capteurs Mickaël Cartron, Olivier Sentieys, Olivier Berder

Conception d’un prototype de plateforme pour l’étude d’aspects haut niveau dans un réseau de capteurs

Mickaël Cartron, Olivier Sentieys,Olivier Berder

IRISA / R2D2ENSSAT Lannion

[email protected], [email protected], [email protected]

mailto:[email protected]



2Projet Réseau de Capteurs

Introduction (1/5)

Les réseaux de capteurs• Objets communicants• Intégrés dans une zone d’intérêt• But : surveillance de zones

Caractéristiques• Ad hoc• Multi sauts• Débit faible• Très forte autonomie

Plateforme MICA2

Notre objectif : maximisation de la durée de vie

Plateforme Aphycare


Introduction (2/5)

Augmenter l’autonomie : sur quels paramètres est-il possible d’agir ?• Point de vue « traitement »

Modulation, Puissance d’émission, Débit binaire par canal, Nombre de canaux disponibles, Largeur de bande utilisée

Système de détection/correction d’erreurs,Système de répétition automatique, Taille des paquets

Algorithmes de routage énergétiquement efficaces

Accès au média / Physique

Liaison

Réseau

Algorithmes distribués efficaces

Application


Introduction (3/5)

Augmenter l’autonomie : sur quels paramètres est-il possible d’agir ?• Point de vue « circuit »

(f, Vdd)

Capteur A/D Processeur Coprocesseur Radio

RAM Flash

Générateur BatterieDC/DCconv.

DVS


Introduction (4/5)

Interdépendance des paramètres est un casse-tête pour réaliser une optimisation (en se limitant à bas niveau)• Si on augmente le taux de transmission

La probabilité de collision diminue Le taux d’erreur augmente La consommation augmente

• Si on augmente la puissance de la correction d’erreur Le taux d’erreur diminue La probabilité de collision augmente La consommation augmente

• Si on augmente la puissance d’émission Le taux d’erreur diminue La probabilité de collision augmente La consommation augmente


Introduction (5/5)

On a énormément de paramètres qui ne sont pas « orthogonaux »• Optimisation difficile

Classification des paramètres• Paramètres liés au scénario applicatif• Paramètres liés aux choix technologiques• Paramètres non définis a priori

Il est nécessaire de faire des conjectures sur certaines valeurs de paramètres qui doivent être les plus réalistes possibles

Pour faire des conjectures correctes, il faut bien connaître les applications• Information échangée• Débits réellement nécessaires• Etc…


PLAN DE LA PRÉSENTATION

I - Étude de scénarios applicatifs II - Plateforme Aphycare III - Architecture logicielle du prototype

• Nœud quelconque du réseau• Station de base

IV - Application à un problème concret V - Conclusion et perspectives


Étude de scénarios applicatifs (1/7)

2 scénarios précis• « Mesures sur une zone d’intérêt »• « Détection et positionnement d’une cible

active »

Évaluation des besoins• Quantité d’informations échangées• Puissance de calcul nécessaire• Quantité de mémoire nécessaire au traitement


(0,0)

(1,5)

(1,8)

(4,2)

(5,6)

(8,4)

(8,8)

(11,3)

Identifiants des nœuds = position géographique

Station de base (puits de données)

Simple répéteur

Capteur/Répéteur(source de données)

Type de nœuds

Exemple de réseau de capteurs



Application 1 : "Mesures sur une zone d'intérêt"

(7,7) (7,7)

?(7,7)

(1,5)

(7,7)

(1,5)(5,6)

(7,7)(5,6)

(8,8)

• La station de base (0,0) veut connaître la température en (7,7)

• Le point (7,7) n'est pas à portée radio de la station de base • La station de base émet "temp(7,7)?"• Le répéteur (1,5) reçoit la requête

• (1,5) n'est pas à proximité de (7,7)• (1,5) ré-émet "temp(7,7)?" dans la "bonne direction", vers (5,6)• Le capteur (5,6) reçoit la requête

• Le capteur (5,6) va participer au calcul de la température, car il est près de (7,7)• (5,6) fait également participer (8,8) au calcul en lui envoyant la requête• (8,8) reçoit la requête



Application 1 : "Mesures sur une zone d'intérêt"

(7,7)(5,6)

(8,8)(7,7)

(1,5)(5,6)

(4,2)

(7,7)

(4,2)

(0,0)

• (8,8) va participer au calcul de la température, car il est près de (7,7)• (8,8) transmet sa valeur locale de température à (5,6)• (5,6) reçoit la valeur de (8,8)

• (5,6) calcule la valeur en (7,7) en faisant une moyenne pondérée• (5,6) génère une réponse et l'envoie à (4,2) pour ne pas épuiser (1,5)• (4,2) reçoit la requête

• (4,2) ré-émet le résultat à (0,0)• (0,0) reçoit le résultat



Application 2 : "Positionnement d'une cible active"

Cible

• On cherche à connaître la position instantanée d'une cible mobile active

• La cible émet une trame en mode « diffusion locale »• infos : cohérence temporelle, numéro de cible, puissance d'émission

• Les nœuds du voisinage estiment la distance avec la cible• Ils émettent chacun une trame en mode direct vers la cible• infos : cohérence temporelle, numéro de cible, distance, coordonnées locales

• Dans un deuxième temps, les mêmes nœuds routent ces mêmes infos vers la station de base



« Multi-sauts (acquitté) »

« Inondation »

Mise en évidence de 5 modes de transmission (6/7)


« Saut unique acquitté »

« Saut unique non acquitté »

« Diffusion locale »

Mise en évidence de 5 modes de transmission (7/7)


PLAN





La plateforme Aphycare (1/2)

Microcontrôleur 16 bits Texas Instrument MSP430• Faible consommation / faible coût• 2 Ko de RAM, 60 Ko de flash

Tête de communication Deltadore ou Chipcon CC1020• Half duplex• Modulations FSK / GFSK / OOK, 860 Mhz• Taux de transmission bit maximum 3,6 Ko/s• Broche RSSI• Contrôle de la puissance (uniquement sur la version CC1020)


Architecture du réseau (2/2)

N nœuds :Cartes Aphycare

1 station de base :Carte Aphycare +Carte Ethernut


PLAN





Niveau physique

Niveau liaison

Niveau réseau

Niv

eau a

pplic

ati

on

Gestion destimers

Tâcheapplicative

1

Tâcheapplicative

2

Auto-position-nement

Connaissancedu voisinage

Routagegéographique

Routage parinondation

Dispatch

Contrôle d'erreurs

Driver du composant de communication

Architecture logicielle d’un capteur (1/14)


Niveau physique

Niveau liaison

Niveau réseau

Niv

eau a

pplic

ati

on

Simulationd'une

horlogeinterne

Tâcheapplicative

1

Tâcheapplicative

2





Dispatch

Contrôle d'erreurs

Canal de communication par file de messages Unix

Architecture logicielle d’un capteur (version simulation) (2/14)


mode_transmission type

Structure des trames (3/14)

Trame générique




Mode multi saut

Multi-sauts (acquitté)

Inondation


Mode inondation

ID_tramesource

Num ackDestinataireSourceSuivant



Saut unique acquitté

Saut unique non acquitté


Mode saut unique acqu.

Num ackDestinataireSource


Mode saut unique non acqu.

DestinataireSource



Diffusion locale


Mode diffusion locale

Source


Les différents types de trames sont reliées par une union, ce qui permet de supprimer les recopies inutiles dans les buffers.

Les trames sont interprétées différemment en fonction du champ Type.

typedef union{

info_ACK Ack ;info_Cible Cible ;info_REQvois REQvois ;info_REPvois REPvois ;info_Signal Signal ;info_Distance_base Distance_base ;info_Distance_cible Distance_cible ;info_Vague Vague ;

} u_info ;



Niveau physique

Niveau liaison

Niveau réseau

Niv

eau a

pplic

ati

on

Gestion destimers

Tâcheapplicative

1

Tâcheapplicative

2





Dispatch

Contrôle d'erreurs


Gestion des buffers (8/14)


Indique le nombre de tentatives d'envoi max. restant à réaliser

Heure limite pour recevoir un acquittement

Historique de fabrication du message

Trame brutedeadline historique Nombre d'envois

crcsourcedestinatairetypemode autre données

ETAPE1

ETAPE2

ETAPE3

PRET

Trame brutedistance

crcsourcedestinatairetypemode autre données

Distance estimée de l'émetteur

Gestion des buffers (9/14)

Buffer d’émission

Buffer de réception


Gestion destimers

Tâcheapplicative

1

Tâcheapplicative

2





Dispatch

Contrôle d'erreurs


Buffer Réception

Buffer Émission

Gestion optimisée des buffers (10/14)


Utilisation d'un ordonnanceur• ordonnancement

fixe• non préemptif• très portable

main(){ initialisations(); while(1){ PT_planificateur_d’accès(); PT_réception(); PT_émission(); PT_liaison(); PT_réseau(); PT_appli(); PT_gestion_timers(); }}

Tache 1

Tache 2

Tache 3

etc.

Utilisation d’un ordonnanceur (11/14)

[Dunkels, Schmidt, Voigt, “Using Protothreads for Sensor Nodes Programming”, 2005]


Module

KernelProgram loaderMulti-threading

libraryTimer library

Memory manager

Event log replicatorµIP TCP/IP stack

Code AVR(taille en

octets)1044

-678

90226

19345218

Code MSP430(taille en octets)

810658582

60170

16564146

RAM(taille en

octets)10 + 2*e + 2*p

88 + s

00

20018+b

e : nombre d'évènements p : nombre de protothreads

Optimisation de la mémoire (12/14)


Basé sur une amélioration du modèle MAPLAP• TX: Transmit• RX: Receive• AQ: Acquire• MN: Monitor• IL: Idle• [Lin, Rabaey, Power-Efficient Rendez-vous Schemes

for Dense Wireless Sensor Networks, ICC, 2004]

TX AQ

MN

IL RX

Émetteur

Récepteur

MN/AQ/RX

Réactivation

TX

IL

Diagramme d'étatdu modèle MAPLAP

Driver du composant de communication (13/14)


Contrôleur bas niveau• Prend en charge une

procédure de réception ou d'émission

• Contrôle l'activation et la désactivation du composant

• Sa cohérence est contrôlée par la machine d’état décrite précédemment

Planificateur d'accès au média• Analyse le buffer d'émission

et les horloges• Planifie les réveils de

réception et d'émission• Simule la diffusion

Planificateurd'accès au média

Contrôleur bas niveau

Buffer Réception

Buffer Émission

Driver du composant de communication (14/14)


PLAN





Gestion destimers

Tâcheinterface

Tâcheapplicative

2





Dispatch

Contrôle d'erreurs


Pla

tefo

rme A

phyC

are

Cart

eEth

ern

ut

Liaison série

Tâcheinterface

Serveurweb

dynamiqueIEEE 802.3 Réseau local

LiaisonEthernet

Station de base (1/2)


Liaison série carte Ethernut / plateforme Aphycare Serveur web dynamique Possibilité d’interroger le réseau Possibilité de récupérer les réponses

Station de base (2/2)


PLAN





Exemples d’utilisation du prototype (1/12)

Étude de contraintes à bas niveau• La modélisation réaliste des contraintes haut

niveau est difficile.• La précision des paramètres doit être aussi

grande que possible, car l’optimisation des paramètres à bas niveau les présuppose connus.

• Paramètres clésNombre de messages échangésProbabilité de collisionsEtc…


Exemple : évaluation d’un gain en performance (2/12)

Considérons l’ensemble constitué des niveaux liaison, MAC et physique d’un système de communication

Modèle de l’énergie par bit transmis avec succès• BPSK, canal AWGN, codage canal Hamming ou convolutif• retransmission SACK, longueur de paquets lp


Exemple : évaluation d’un gain en performance (3/12)

Mise en évidence d'un point optimal de fonctionnement• D=10 m, Pbruit=-90 dBm, Paquets de 53 octets, ré-émission

automatique : SACK, correction d'erreurs (viterbi, hamming)• couche physique adaptée• amplificateurs efficaces• modulation BPSK

• fort intérêt à se situer à la puissance d’émission optimale

• QUESTION : Quel gain de durée de vie gagne t’on réellement à être au point optimal ?


Évaluation d’un gain en performance (4/12)

Considérons un exemple de réseau formé de 27 nœuds disposés régulièrement, et d'une station de base

Simulation réalisée à l'aide de notre prototype de réseau de capteurs (version simulation) Pas du réseau : 7 mètres



Protocole d'exemple : mise à jour d'un réseau de capteurs• Phase 1 : inondation pour lancer la phase d'initialisation• Phase 2 : requête pour la connaissance du voisinage• Phase 3 : réponse à la requête• Phase 3 bis : acquittements de cette réponse• Phase 4 : enregistrement de chaque nœud auprès de la station de base• Phase 4 bis : acquittements du mode multi-hop



3 5

5 8

5

8

5

8

5

8

5

8

3

5

5 8 8 8 8 8 5

3 5 5 5 5 5 3

Phase 1 : inondation initiale

Sommes cumulées d’émissions de paquets



6 10

10 16

10

16

10

16

10

16

10

16

6

10

10 16 16 16 16 16 10

6 10 10 10 10 10 6

Phase 2 : requête pour la connaissance du voisinage



12 20

20 32

20

32

20

32

20

32

20

32

12

20

20 32 32 32 32 32 20

12 20 20 20 20 20 12

Phases 3 et 3 bis : réponse à la requête sur le voisinage



13 21

21 35

21

39

21

35

21

35

21

35

13

21

21 39 59 55 47 39 21

13 21 21 21 21 21 13

Phases 4 et 4 bis : enregistrement de chaque nœud auprès de la station de base



13 21

21 35

21

39

21

35

21

35

21

35

13

21

21 39 59 55 47 39 21

13 21 21 21 21 21 13

Phases 4 et 4 bis : enregistrement de chaque nœud auprès de la station de base

Capteur le plus sollicité



0

2

4

6

8

10

12

14

16

<10 <20 <30 <40 <50 <60

Nombre denœuds

Max.Moy.

5526,1

Nombre de nœuds en fonction du nombre d’émissions



Énergie dépensée par trame

1.6 mJ

2.048 mJ2.048 mJ

2.048 mJ

Méthode d'optimisation globale adaptative

475 % de temps en plus avant

l'épuisement du premier nœud

Méthode indexée sur le pire cas

406 % de temps en plus avant

l'épuisement du premier nœud

5.2 mJ

5.2 mJ

Méthode indexéesur la puissance

d'émission de 0 dBm


PLAN





Conclusion et perspectives

Analyse fine des besoins applicatifs• Meilleure évaluation des contraintes

qu’exercent les niveaux supérieurs sur les couches basses de la pile de protocole réseau

• Bases pour une architecture adaptée à des réseaux de capteursCoprocesseurArchitecture mémoire intelligente


Bibliographie

R. Min, M. Bhardwaj, S.-H. Cho, E. Shih, A. Sinha, A. Wang, and A. Chandrakasan. “Low-Power Wireless Sensor Networks”. VLSI Design, 2001.

J. Rabaey, M. Ammer, J. da Silva, D. Patel, and S. Roundy. “PicoRadio supports ad hoc ultra-low power wireless networking”. In Computer, IEEE, 2002.

I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci. “Wireless Sensor Networks: a survey”. In Computer Networks, IEEE, 2002.

A. Dunkels, B. Grönvall, and T. Voigt. “Contiki – a lightweight ans flexible operating system for tiny networked sensors”. In Proc. of the first IEEE Workshop on embedded Networked Sensors, Tampa, Florida, November 2004.

E.-Y.A Lin, J. Rabaey, and A. Wolisz. “Power-Efficient Rendez-vous Schemes for Dense Wireless Sensor Networks”, In Proc. of the ICC, 2004.

Documents

Conception d’un prototype de plateforme pour l’étude d’aspects haut niveau dans un réseau de capteurs Mickaël Cartron, Olivier Sentieys, Olivier Berder