Mesures expérimentales

0.3.1.1 Plate-forme PowWow

PowWow (Power Optimized hardWare and software frameWOrk for Wireless motes) [23,

63, 106] est une plateforme matérielle et logicielle conçue pour mettre en ÷uvre des réseaux de capteurs fortement contraints en énergie. Elle est basée sur des protocoles MAC optimisés (cf. section suivante), un routage géographique simple et un code logiciel très compact (pile protocolaire d'environ 6 ko et application typique entre 4 et 5 ko). Des réductions en consommation avec des facteurs de plus de 15 ont été relevées par

Résumé étendu 7 rapport à une couche 802.15.5/Zigbee libre de chez Texas Instruments (TIMAC) pour des collectes régulières de température dans un réseau d'une dizaine de n÷uds.

D'un point de vue du matériel, la plate-forme PowWow possède également quelques originalités. Si elle est bien sûr basée sur des composants standards (microcontrôleur, transceiver radio) comme nombre de plateformes, sa conception modulaire et son faible facteur de forme lui permetent d'empiler plusieurs couches de cartes selon les besoins applicatifs. L'architecture globale et les interactions entre les unités de traitement et de calcul sont illustrées par la Figure 3, tandis que la Figure 4 montre une photo de la plate-forme PowWow avec trois cartes (calcul, radio et collectage d'énergie). Quatre modules sont actuellement disponibles.

ˆ La carte mère intègre tous les composants nécessaires à l'exécution de la pile pro- tocolaire PowWow, excepté le composant radio. En particulier, celle ci intègre un microcontrôleur faible consommation MSP430 de Texas Instruments [119] qui est le composant central du système et fait oce de contrôleur principal et de com- posant de calcul. Il s'agit de la version MSP430F1612 (55ko de mémoire ash et 5ko de RAM). Il consomme 330µA à 1 MHz et 2.2 V en mode actif et 1.1µA en mode veille. La carte intègre aussi le gestionnaire d'horloge (par défaut à 8 MHz) et d'alimentation (par défaut à 3V) permettant une gestion dynamique de la fréquence et de la tension d'alimentation. Des interfaces JTAG, RS232 et I2C sont disponibles sur cette carte pour interfacer avec un ordinateur ou des capteurs. ˆ La carte radio intègre un composant radio CC2420 [55] compatible Zigbee/802.15.4 et une connexion pour une antenne. Son association à la carte mère crée le système minimum permettant à PowWow de fonctionner.

ˆ Entre ces deux cartes, il est possible de connecter une carte FPGA qui permet une accélération matérielle pour certains traitements de PowWow. Actuellement la version de la plate-forme intègre un FPGA faible consommation Actel Igloo [7]. Le composant, un AGL125 (125000 portes equivalentes, 32 kbits de mémoire RAM, 1 kbits de mémoire ash), consomme 2.2µW, 16µW et de 1 à 30mW respectivement dans les modes veille, freeze et actifs selon le taux d'utilisation.

ˆ Enn, une dernière carte lle est dédiée aux techniques de récupération d'énergie. Basée sur un composant de gestion de l'énergie LTC3108 de chez Linear Technology,

Résumé étendu 8

Figure 3: Architecture matérielle de la plate-forme PowWow

Figure 4: Photo de la plate-forme PowWow avec trois cartes: calcul, récupération d'énergie et radio

elle permet d'être congurée avec plusieurs types de stockage d'énergie (batteries, micro-batteries, super-capacités) et plusieurs types de sources d'énergie: un petit panneau solaire pour récupérer l'énergie photovoltaique, un capteur piézoélectrique pour l'énergie mécanique et un capteur d'énergie thermique de type Peltier.

0.3.1.2 Couche MAC asynchrone

La couche d'accès au Medium (MAC pour Medium Access Control) a pour rôle de per- mettre aux n÷uds d'un réseau de partager de la manière ecace le ou les canaux sans l disponibles. Son principal objectif dans le contexte des réseaux de capteurs est de minimiser la consommation d'énergie en éteignant les modules radios aussi souvent que possible. Les principales sources de consommation au niveau MAC sont l'écoute passive inutile (ou idle listening), les en-têtes parfois trop longues (ou overheads), la réception de

Résumé étendu 9 paquets destinés à un autre n÷ud (ou overhearing) et bien sûr les collisions. Ces dernières peuvent avoir lieu lors de l'émission de n'importe quel paquet, que ce soit une trame de réveil (WUB pour Wake-up Beacon) ou l'envoi de données (DT pour Data Transmission). Pour atteindre la meilleure ecacité, ces artéfacts doivent être minimisés, mais pas tous simultanément. Si l'on cherche à diminuer l'écoute inutile et les collisions, il va falloir augmenter les processus de synchronisation et les overheads. Inversement diminuer les overheads et la synchronisation résultera en des collisions plus nombreuses.

Figure 5: Les paquets de contrôle (WUB et ACK) comprennent l'adresse géographique du n÷ud qui les émettent, un code de redondance cyclique (CRC) et le dernier octet contient le type de paquet (3 bits) et le mode de communciation (5 bits). Le paquet de données contient les adresses de la source, de la destination, du dernier et du prochain n÷ud en cas de multi-étapes, ainsi que quelques octets pour le numéro d'ACK, les informations des capteurs, telle la température, le niveau de batterie et le numéro de

trame.

Figure 6: Protocole RICER optimisé ajustable à l'application et diminution de l'écoute inutile.

La famille à échantillonnage de préambule est une option intéressante pour les réseaux de capteurs et son mécanisme peut être initié soit par l'émetteur soit par le récepteur [19].

Résumé étendu 10 Dans le premier cas le préambule est envoyé par l'émetteur, directement suivi par les données. Le récepteur se réveille à intervalle régulier pour sonder le canal, et se rendort immédiatement s'il ne détecte aucun préambule. Si la communication est initiée par le récepteur, c'est ce dernier qui va envoyer régulièrement un préambule ou trame de réveil (WUB), restera en écoute pendant un instant et l'émetteur répondra en envoyant ses données. Les performances énergétiques de cette dernière stratégie nous ont séduites [82], et c'est ce processus asynchrone que nous avons choisi pour notre plate-forme PowWow. Pour le rendre plus ecace, nous avons optimisé le protocole RICER3 en diminuant la taille des paquets et les overheads, comme le montre les Figures3.3et 3.4, qui représen- tent respectivement les compositions des paquets et le protocole lui-même. Par rapport à la version d'origine de RICER, il faut noter l'absence de plusieurs slots temporels après l'intervalle de réveil, mais ceci n'augmente pas le taux de collision.