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 / R2D2 ENSSAT Lannion cartron@irisa.fr, sentieys@irisa.fr, berder@enssat.fr Conférence FTFC 2005

Introduction (1/5) Les réseaux de capteurs Caractéristiques 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 Plateforme Aphycare Notre objectif : maximisation de la durée de vie

Introduction (2/5) Augmenter l’autonomie : sur quels paramètres est-il possible d’agir ? Point de vue « traitement » Algorithmes distribués efficaces Application Réseau Algorithmes de routage énergétiquement efficaces Système de détection/correction d’erreurs, Système de répétition automatique, Taille des paquets Liaison Modulation, Puissance d’émission, Débit binaire par canal, Nombre de canaux disponibles, Largeur de bande utilisée Accès au média / Physique

Introduction (3/5) Augmenter l’autonomie : sur quels paramètres est-il possible d’agir ? Point de vue « circuit » Générateur Batterie DC/DC conv. DVS (f, Vdd) RAM Flash Capteur A/D Processeur Coprocesseur Radio

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 Si on augmente la puissance d’émission

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

Étude de scénarios applicatifs (2/7) Exemple de réseau de capteurs (1,8) (8,8) (5,6) (1,5) Simple répéteur (8,4) (11,3) (4,2) Capteur/Répéteur (source de données) (0,0) Station de base (puits de données) Type de nœuds Identifiants des nœuds = position géographique

Étude de scénarios applicatifs (3/7) Application 1 : "Mesures sur une zone d'intérêt" 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 (7,7) (7,7) ?(7,7) (1,5) (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 (7,7) (1,5) (5,6) (7,7) (5,6) (8,8) Conférence FTFC 2005

Étude de scénarios applicatifs (4/7) Application 1 : "Mesures sur une zone d'intérêt" (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 (7,7) (5,6) (8,8) (7,7) (1,5) (5,6) (4,2) (4,2) ré-émet le résultat à (0,0) (0,0) reçoit le résultat (7,7) (4,2) (0,0) Conférence FTFC 2005

Étude de scénarios applicatifs (5/7) Application 2 : "Positionnement d'une cible active" 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 Cible 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 Conférence FTFC 2005

Mise en évidence de 5 modes de transmission (6/7) « Multi-sauts (acquitté) » « Inondation » Conférence FTFC 2005

Mise en évidence de 5 modes de transmission (7/7) « Saut unique acquitté » « Saut unique non acquitté » « Diffusion locale » Conférence FTFC 2005

PLAN 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

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 Conférence FTFC 2005

PLAN 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

Architecture logicielle d’un capteur (1/14) Gestion des timers Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Niveau application Routage géographique Routage par inondation Niveau réseau Dispatch Contrôle d'erreurs Niveau liaison Driver du composant de communication Niveau physique Conférence FTFC 2005

Architecture logicielle d’un capteur (version simulation) (2/14) d'une horloge interne Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Niveau application Routage géographique Routage par inondation Niveau réseau Dispatch Contrôle d'erreurs Niveau liaison Canal de communication par file de messages Unix Niveau physique Conférence FTFC 2005

Structure des trames (3/14) mode_transmission type Trame générique

Structure des trames (4/14) Multi-sauts (acquitté) Inondation mode_transmission type Num ack Destinataire Source Suivant Mode multi saut mode_transmission type ID_trame source Mode inondation

Structure des trames (5/14) Saut unique acquitté Saut unique non acquitté mode_transmission type Num ack Destinataire Source Mode saut unique acqu. mode_transmission type Destinataire Source Mode saut unique non acqu.

Structure des trames (6/14) Diffusion locale mode_transmission type Source Mode diffusion locale

Structure des trames (7/14) 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 ;

Gestion des buffers (8/14) timers Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Niveau application Routage géographique Routage par inondation Niveau réseau Dispatch Contrôle d'erreurs Niveau liaison Niveau physique Driver du composant de communication Conférence FTFC 2005

Gestion des buffers (9/14) Indique le nombre de tentatives d'envoi max. restant à réaliser Historique de fabrication du message Heure limite pour recevoir un acquittement Trame brute deadline historique Nombre d'envois crc source destinataire type mode autre données ETAPE1 ETAPE2 ETAPE3 PRET Buffer d’émission Distance estimée de l'émetteur Trame brute distance crc source destinataire type mode autre données Buffer de réception Conférence FTFC 2005

Gestion optimisée des buffers (10/14) Gestion des timers Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Routage géographique Routage par inondation Buffer Émission Dispatch Buffer Réception Contrôle d'erreurs Driver du composant de communication Conférence FTFC 2005

Utilisation d’un ordonnanceur (11/14) ordonnancement fixe non préemptif très portable Tache 1 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 2 Tache 3 etc. [Dunkels, Schmidt, Voigt, “Using Protothreads for Sensor Nodes Programming”, 2005] Conférence FTFC 2005

Optimisation de la mémoire (12/14) Module Kernel Program loader Multi-threading library Timer library Memory manager Event log replicator µIP TCP/IP stack Code MSP430 (taille en octets) 810 658 582 60 170 1656 4146 Code AVR (taille en octets) 1044 - 678 90 226 1934 5218 RAM (taille en octets) 10 + 2*e + 2*p 8 8 + s 200 18+b e : nombre d'évènements p : nombre de protothreads Conférence FTFC 2005

Driver du composant de communication (13/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 Diagramme d'état du modèle MAPLAP Émetteur Récepteur MN/AQ/RX TX Réactivation IL Conférence FTFC 2005

Driver du composant de communication (14/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 Buffer Émission Buffer Réception Planificateur d'accès au média Contrôleur bas niveau Conférence FTFC 2005

PLAN 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

Driver du composant de communication Station de base (1/2) Tâche interface Serveur web dynamique IEEE 802.3 Ethernut Carte Réseau local Liaison Ethernet Liaison série Gestion des timers Tâche interface Tâche applicative 2 Auto- position- nement Connaissance du voisinage Routage géographique Routage par inondation Plateforme AphyCare Dispatch Contrôle d'erreurs Driver du composant de communication Conférence FTFC 2005

Station de base (2/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 Conférence FTFC 2005

PLAN 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

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és Nombre de messages échangés Probabilité de collisions Etc…

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

Évaluation d’un gain en performance (5/12) 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

Évaluation d’un gain en performance (6/12) Phase 1 : inondation initiale 3 5 5 5 5 5 3 5 8 8 8 8 8 5 5 8 8 8 8 8 5 3 5 5 5 5 5 3 Sommes cumulées d’émissions de paquets

Évaluation d’un gain en performance (7/12) Phase 2 : requête pour la connaissance du voisinage 6 10 10 10 10 10 6 10 16 16 16 16 16 10 10 16 16 16 16 16 10 6 10 10 10 10 10 6

Évaluation d’un gain en performance (8/12) Phases 3 et 3 bis : réponse à la requête sur le voisinage 12 20 20 20 20 20 12 20 32 32 32 32 32 20 20 32 32 32 32 32 20 12 20 20 20 20 20 12

Évaluation d’un gain en performance (9/12) Phases 4 et 4 bis : enregistrement de chaque nœud auprès de la station de base 13 21 21 21 21 21 13 21 35 39 35 35 35 21 21 39 59 55 47 39 21 13 21 21 21 21 21 13

Évaluation d’un gain en performance (10/12) Phases 4 et 4 bis : enregistrement de chaque nœud auprès de la station de base 13 21 21 21 21 21 13 21 35 39 35 35 35 21 21 39 59 55 47 39 21 13 21 21 21 21 21 13 Capteur le plus sollicité

Évaluation d’un gain en performance (11/12) Max. Moy. 55 26,1 Nombre de nœuds en fonction du nombre d’émissions

Évaluation d’un gain en performance (12/12) Énergie dépensée par trame 5.2 mJ 2.048 mJ 1.6 mJ 5.2 mJ 2.048 mJ 2.048 mJ Méthode indexée sur la puissance d'émission de 0 dBm Méthode indexée sur le pire cas 406 % de temps en plus avant l'épuisement du premier nœud Méthode d'optimisation globale adaptative 475 % de temps en plus avant l'épuisement du premier nœud

PLAN 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

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 capteurs Coprocesseur Architecture 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.