CoursReseauxdecapteurs 2 PDF

Réseaux de capteurs
MICA 2 MICA2 DOT
SUN SPOT
TMOTE
1
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Nom : Marc Dalmau
Page : http://www.iutbayonne.univ-pau.fr/~dalmau
Localisation : IUT de Bayonne – Pays Basque (Montaury)
Laboratoire : LIUPPA
Recherche : Architectures logicielles pour applications sur
dispositifs hétérogènes (postes fixes, mobiles, capteurs)
Principe : plate-forme de déploiement et de reconfiguration
dynamique d’applications (qualité de service) :
• Règles d’usage
• Pérennité
• Continuité de service
2
Utilisation des réseaux de capteurs
• Surveillance d’espace
– Environnement et habitat
– Agriculture
– Climat
– Surveillance militaire
– Alarmes Intelligentes
• Surveillance d’objets
– Eco physiologie
– Maintenance
– Médical
• Surveillance d’interactions entre objets et espace
– Vie sauvage
– Surveillance de catastrophes
– Processus de production
3
Quelques exemples d’applications
• Climat
– Intel : réseau de capteurs pour surveiller le comportement des oiseaux (Great
Duck Island , Maine)
– ALERT (Automated Local Evaluation in Real-Time) surveillance des risques
d’innondation
• Environnement
– PODS (université de Hawai) surveillance de plantes menacées
– Corie : surveillance de pollution sur l’estuaire de la rivière Columbia
– Alert : surveillance de risques d’inondation (Californie – Arizona)
• Santé
– Surveillance de patients (glucose, température , ….)
– SSIM (Smart Sensors and Integrated Microsystems) : rétine artificielle (100
micro-capteurs)
• Distribution d’énergie
• Militaire
– ExScal : surface de 1.3km sur 300m contrôlée par 1000 capteurs pour détection
d’intrusion
• Autres domaines à trouver …
4
Suivi des déplacements de zèbres
au Kenya
capteur avec CPU,
FLASH, radio et GPS
Données
communications par
stockage et envoi Données
collecte de données
(avion ou voiture)
Données
Données
5
Protection de plantes (Pods)
Objectif :
– Protection de variétés de plantes en danger à Hawai (silènes).
– Le climat d’Hawai'i varie fortement d’un lieu à l’autre => une
station météo ne suffit pas => utiliser un réseau de capteurs.
Collecte d’informations
– Vent, pluie, température, lumière, humidité
– Images sur certains capteurs
– Sur chaque capteur avec une périodicité de 5 minutes à 1 heure
Problèmes
– Durée de vie des batteries
– Collecte sans perte d’information
– Traitement de ces informations
6
Forêt
Observatoire des
volcans d’Hawaii
Silènes
Zone d’étude
Désert
7
Les capteurs sont placés dans des
faux rochers …
lumière
vent
température
CPU +
humidité Radio
Batteries
8
… ou des fausses branches
lumière
CPU +
Radio
B
at
te
rie
s
température
9
Puis disséminés dans la zone
d’étude
10
Références
Quelques constructeurs :
– Intel (http://www.intel.com/research/exploratory/motes.htm) : Intel Motes
– XBow Corp (http://www.xbow.com) : Mica2 mote, Micaz, Dot mote et Stargate Platform
– Moteiv (http://www.moteiv.com) : TMote
– Millenial Net (http://www.millenial.com) : iBean sensor nodes
– Dust Inc (http:// www.dustnetworks.com/) : Smart Dust
– Cogent Computer (http://www.cogcomp.com) : XYZ Node (CSB502) en collaboration
avec ENALAB@Yale
– Sensoria Corporation (http://www.sensoria.com) : WINS NG Nodes
– Sun (https://www.sunspotworld.com/) : sunspot
Quelques composants (processeurs, radio) :

– Atmel (http://www.atmel.com)
– ARM (http://www.arm.com/products/CPUs/families.html)
– ChipCon CC1000 DataSheet (http://www.chipcon.com)
– RFM TR1000 DataSheet (http://www.rfm.com)
– Ember (http://www.ember.com) : Integrated IEEE 802.15.4 stack and radio on a single
chip
11
Plan du cours
• Les capteurs • Les réseaux de capteurs
– Architecture générale – La radio
– Étude d’un processeur – Accès au médium
(ARM) • Problèmes
– Problème de l’énergie • protocoles utilisés
– Positionnement et localisation
• Le logiciel – Routage
– Systèmes d’exploitation • Routage à plat
• TinyOS
• Routage basé sur la localisation
• Squawk
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité
12
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
13
Architecture générale
Un capteur est essentiellement composé de :
– Unités de capture et actionneurs
– Processeur et mémoire
– Émetteur/récepteur
capteurs communication
processeur
physiques
actionneurs
physiques gestion de l'alimentation sécurité
14
Composants d’un capteur
• Processeur : faible consommation, vitesse d'horloge faible (<400MHz),
puissance de calcul faible (300 MIPS).
• Mémoire : RAM (qques dizaines de Mo) + EEPROM (pour programme
embarqué) + Flash (de l'ordre du Go)
• Connecteurs : USB, série, cartes d'extension (ethernet, …)
• Périphs : timers, lignes d'E/S, PWM, CA/N, horloge chien de garde
• Capteurs :
– Environnement : pression, humidité, lumière, température …
– Force et déplacement : rotation, position, accélération
– Electromagnétique : antenne, magnétisme
– Chimique : composition de gaz
– Autres : son, image, infrarouge
Constitution : capteur + conditionnement de signal + conversion A/N + DMA parfois
Possibilité de mise en veille pour consommation
• Actionneurs : LEDS, buzzer, optocoupleurs pour connexions externes …
• Alimentation : par batteries rechargeables + régulateur + contrôle de niveau
de batterie + contrôle de mise en veille et de vitesse d'horloge (baisse pour
baisser la conso) et de tension d'alim du processeur (mode faible conso).
Parfois ajout de chargement par solaire ou vibration ou vent …
Remarque : le nombre de cycles de charge / décharge est limité.
15
Communication
Par radio : Zigbee (IEEE 802.15.4) , Bluetooth
(IEEE 802.15.1) , WI-FI (IEEE 802.11)
Technologie Vitesse Consommation Temps de
max démarrage
Zigbee 250 KB/s faible Court
Bluetooth 1 MB/s moyenne Moyen
802.11 11 - 54 Mb/s élevée Long
16
Anatomie d'un capteur
exemple du SunSpot
antenne
Émetteur / récepteur sans fil

CC2420 à 2,4GHz
Processeur ARM et mémoire
256Ko RAM et 2Mo flash
Connecteur pour carte

capteur
17
Anatomie d'un capteur
exemple du SunSpot
boutons
leds
tricolores Accéléromètre 3 axes
Capteur de température
Capteur de lumière
18
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
19
Les processeurs
On trouve divers types de processeurs, les plus utilisés sont les Intel
PXA, les ARM et les ATMEGA.
Il s'agit de processeurs à faible consommation donc à vitesse d'horloge

faible (quelques centaines de MHz) de type RISC.
Certains comme l'ATMEGA 128 sont plutôt des microcontrôleurs.
20
Etude d'un processeur (ARM)
Les processeurs ARM7 et ARM9 sont des RISC 32 bits
• Famille ARM7
(130MIPS) le modèle 720T a un cache unifié
(instructions+données) de 8Ko et une MMU.
• Famille ARM9
– Le 922T a deux caches de 8Ko qui passent à 16Ko sur le 920T.
L'horloge est à 190, 200, 230 ou 250MHz.
– Le ARM 920T est celui qui équipe les capteurs Sunspots. C’est
celui que l’on détaillera par la suite.
Le jeu d'instruction est constitué de 2 jeux : les instructions ARM 32

bits et les instructions Thumb 16 bits pour la compatibilité avec
les StrongARM.
21
Les registres
Il y a 31 registres de 32 bits dont 16 sont visibles à la fois
par le programmeur, les autres sont des synonymes
utilisés lors des exceptions.
Parmi ces 16 registres 3 ont un rôle particulier tandis
que les 13 autres sont d'usage général :
• R15 est le CO
• R14 contient l'adresse de retour de procédure
• R13 est le pointeur de pile
Il y a 2 registres d'état
– CPSR est le registre d'état classique
– SPSR qui sert de sauvegarde de CPSR quand une exception
est traitée
22
Les exceptions
Les types d'exception sont :
– Interruption rapide : FIQ (Fast Interrupt Request)
– Interruption normale : IRQ (Interrupt ReQuest)
– Erreurs de mémoire (protection ou défaut de page de mémoire virtuelle)
– Instruction non définie
– Interruptions logicielles : SWI (SoftWare Interrupt)
R14 contient l'adresse de retour.
Les registres R13, R14 et SPSR sont changés (banque de registres)

pour éviter d'avoir à les sauvegarder.
Dans le cas de l'interruption rapide (FIQ) les registres R8 à R12 sont

également changés
23
Les modes
Il existe deux modes de fonctionnement en dehors des exceptions :
– système
– utilisateur
• En mode utilisateur les modifications du registre d'état sont limitées

aux indicateurs de l'UAL.
• En mode système on peut modifier la totalité du registre d'état

(autorisation d'interruptions et mode du processeur).
On quitte le mode utilisateur lors d'une exception et on y retourne à la fin.
Les exceptions logicielles peuvent permettre de passer du mode

utilisateur au mode système (appel d'API).
Quand on est en mode système on revient au mode utilisateur en

modifiant le registre d'état.
24
Les instructions
Il y a 4 classes d'instructions :
– Traitement de données
– Transferts de données
– Ruptures de séquence
– Instructions pour coprocesseur
Toutes les instructions peuvent être conditionnées suivant les

conditions suivantes :
condition Avec signe Sans signe
Egal EQ EQ
Différent NE NE L'évaluation de la condition se
> GT HI
> ou égal GE HS fait à partir des indicateurs du
< LT LO registre d'état qui ont été
< ou égal LE LS positionnés lors d'une instruction
Positif PL précédente.
Négatif MI
Débordement VS VS
Non débordement VC VC
25
Format du code d’opération des
instructions
• Pour utiliser une instruction conditionnelle on ajoute les 2 lettres

extraites du tableau précédent après le COP.
• Puis on ajoute les extensions du COP s'il y en a (par exemple taille

des opérandes).
• Les indicateurs sont positionnés par les instructions de comparaison

mais on peut faire suivre le COP des instructions traitement par un
S pour qu'elles positionnent les indicateurs.
• Par exemple : LDREQBS est le code de l'instruction "load" (LDR)

conditionné par l'égalité (EQ), se faisant sur 8 bits avec complétion
par des 0 à gauche (B) et positionnant les indicateurs du registre
d’état (S).
26
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
27
Le problème de l'énergie sur les
capteurs
28
capteurs (exemple)
Exemple de consommation :
De base : 12mA, en veille : 8 µA
+ 12mA en émission
+ 4,5 mA en réception
Batterie de 2300 mAh
Exemple de calcul pour une utilisation :

– Un capteur envoie chaque seconde le résultat d'un calcul fait à
partir d'une mesure.
– On suppose que le calcul dure 2ms, qu'à la fin de ce calcul il envoie
50 octets à 19200 b/s et doit en relayer 250 vers d'autres nœuds et
enfin qu'il est inactif le reste du temps.
29
capteurs (exemple)
Il doit rester à l'écoute du réseau en permanence pour
pouvoir accomplir sa fonction de relai.
Sur 1 seconde on a :
– Calcul et écoute : 2ms à 12 mA
– Réception : 250/19200 s = 13 ms à 16,5 mA
– Emission : (250+50)*8/19200 s = 15,6 ms à 24 mA
– Le reste (969,4 ms) est en écoute à 12 mA
Consommation : 12,25 mA
A ce régime, avec sa batterie de 2300mAh, il pourra

fonctionner pendant 2300/12.25=188 heures (un peu moins
de 8 jours).
30
capteurs (exemple)
S'il n'écoutait pas le réseau tout le temps mais passait en
mode veille quand il est inactif :
Sur 1 seconde on aurait :

– Calcul : 2ms à 12 mA
– Réception : 250/19200 s = 13 ms à 16,5 mA
– Emission : (250+50)*8/19200 s = 15,6 ms à 24 mA
– Le reste (969,4 ms) est en veille à 8 µA
Consommation : 0,62 mA
A ce régime, avec sa batterie de 2300mAh, il pourra

fonctionner pendant 2300/0,62=3710 heures (un peu plus
de 5 mois).
31
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
32
Systèmes d'exploitation
Dans un capteur les ressources sont limitées (mémoire, puissance de calcul). Il faut donc
que le SE soit le plus léger possible.
Deux approches sont utilisées :

– Un SE réduit au minimum (par exemple Squawk est une MV java très allégée)
– Un SE modulaire dont on ne charge que les parties utiles (TinyOS)
Dans le premier cas on mise sur la puissance du langage associé (java) pour pallier la
légèreté du SE.
Ce type de solution est plutôt adapté aux futurs capteurs qui auront plus de mémoire
et plus de puissance de calcul. Elle est d'ores et déjà très utilisée sur les systèmes
mobiles moins contraints (téléphones portables, PDA).
Dans le second cas on part de l'idée que dans un SE tout n'est pas utilisé et qu'on peut
se contenter, pour une application donnée, d'une partie du SE. Pour permettre cela il
faut identifier un noyau minimal du SE puis découper le reste en modules
(composants) que le programmeur pourra intégrer à son application.
Il faut un langage de programmation permettant de faire ça facilement, c'est pourquoi
TinyOS est lié au langage nesC qui définit une application comme un ensemble de
composants et de liens entre eux. Les composants du SE sont alors traités comme
ceux de l'application et intégrés à la demande.
33
Quelques SE utilisés sur des
capteurs
• Berkeley motes, TinyOS
– Mica2, Mica2Dot : microcontrôleur 8-bit, 7.37/4.0 Mhz, 128 KB
flash, 4 KB SRAM, radio : CC1000, 512 KB flash externe, 2
batteries AA 3V lithium.
• Intel Mote
– Zeevo : microcontrôleur ARM7, mémoire SRAM et flash,
Bluetooth, TinyOS
– Mote 2: microcontrôleur 32-bit Xscale PXA 271, Linux et
machine virtuelle Java.
• Sun SPOT
– microcontrôleur 32-bit ARM920T à 180 Mhz, 512K RAM/4M
ROM, radio : ChipCon 2420 et 2.4 GHz IEEE 802.15.4, interface
USB, batterie 750 mAh lithium ion, MV Java Squawk
34
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
35
TinyOS est écrit en nesC qui un langage dérivé du C qui
inclut des notions :
– de composants,
– d'interfaces bidirectionnelles,
– de tâches
– de gestion des interruptions.
TinyOS et nesC sont liés : les applications pour TinyOS

doivent être écrites en nesC.
36
Principes de TinyOS
• Un composant est constitué d'au moins un module utilisant et fournissant
des interfaces. S'il contient plusieurs modules les liens entres eux sont
décrits par un fichier de configuration.
• Une application complète est un composant contenant plusieurs modules

liés entre eux dont un module Main qui permet de démarrer.
• Le SE offre une centaine de composants que l'on peut utiliser pour écrire
des applications. Quand le programme est généré par le compilateur, seuls
les composants utilisés (y compris ceux du système) sont présents.
Main est lui-même connecté à certains composants du système (comme
l'ordonnanceur par exemple) qui seront donc chargés en mémoire puis
lancés par Main
On va décrire dans des fichiers portant le suffixe .nc les modules, les interfaces
et les configurations.
Une application comporte donc plusieurs de ces fichiers.
37
Modules et interfaces
• Les modules offrent et utilisent des interfaces.
• Une interface déclare un ensemble de fonctions

appelées commands qui peuvent être utilisées par les
autres composants et un ensemble de fonctions
appelées events qui réagissent à des événements en
provenance d'autres composants.
• Toutes ces fonctions doivent être implémentées.
38
Modules et interfaces
module truc {
provides {
interface C;
}
uses {
interface A
interface B
} A
C Truc
implementation {
// code à implémenter : B
// commandes de l'interface C
// +
// traitement des événements des interfaces A et B
} event
} command
interface C {
command resultat1 cmd1(paramètres);
command resultat2 cmd2(paramètres);
…
event resultat3 evt1();
event resultat3 evt2();
…
}
39
Liaisons
Un composant en nesC est constitué de modules et d'une
configuration.
– Les modules contiennent le code et implémentent une ou

plusieurs interfaces.
– Les configurations servent à assembler les composants entre

eux en connectant les interfaces utilisées par certains
composants à celles fournies par d'autres pour fabriquer de
nouveaux composants (composites).
– L’application est elle-même un composant n’offrant aucune

interface.
40
Liaisons :
Fabriquer le composant C3 à partir de C1 et C2.
configuration C3 {
provides {
interface A;
interface B
} A
A C1 C
B
implementation {
components C1,C2; C3
A = C1.A;
B = C1.B; B
B C2
B = C2.B; C
C1.C -> C2.C;
}
}
41
Application NESC
• Une application est un assemblage dans lequel apparaît le
composant système Main qui sert à démarrer.
Elle est décrite par une configuration "de premier niveau".
La partie configuration d'un fichier d'une application est vide car
elle n'offre et ne requiert aucune interface, la partie
implémentation décrit le schéma de câblage de plus haut
niveau (assemblage des composants de l'application).
• L'ensemble des configurations permet de savoir quels composants

sont utiles pour que l'application fonctionne.
Il suffit de regarder le fichier de configuration de l'application pour
savoir quels composants elle utilise (components) puis de faire
la même chose récursivement pour chacun de ces
composants.
42
Modèle d'exécution
TinyOS n'exécute qu'une application à la fois.
Il y a deux types de processus d'exécution :
– les tâches
– les pilotes d'interruptions.
Les tâches s'exécutent l'une après l'autre sans préemption.
Les pilotes d'IT sont exécutés en réponse à une IT mais

peuvent préempter les tâches et les autres pilotes d'IT.
Les commandes et les événements qui sont exécutés
par un pilote d'IT doivent être définis avec le mot clé
async.
43
Problème de temps réel
• Les commandes écrites dans les composants doivent être de
courte durée car TinyOS ne fait pas de préemption donc si une
commande peut durer longtemps le programmeur doit utiliser une
tâche pour l'exécuter et cette tâche retournera un événement pour
indiquer qu'elle est terminée.
C'est par exemple le cas des commandes d'envoi sur liaison radio.
L'exécution de cette tâche est différée puisqu'elle sera mise en file
d'attente et exécutée à son tour quand les tâches précédentes
seront terminées.
• Les traitements d'événements sont, par nature, de courte durée.
44
Concurrence
Comme les tâches et les pilotes d'IT peuvent être préemptés par des
pilotes d'IT, il peut se produire des problèmes de concurrence.
Traditionnellement on les résout par l'utilisation de sémaphores.
nesC utilise des parties de code atomiques (mot clé atomic).
Le compilateur nesC détecte les problèmes de concurrence et les

indique au programmeur par une erreur de compilation. Lorsqu'il est
sûr que le problème ne se pose pas, le programmeur peut demander
au compilateur (par le mot clé norace) d'accepter une construction
apparemment douteuse. Bien entendu il faut utiliser cela avec
circonspection.
45
Tâches
TinyOS connaît les tâches et les pilotes d'IT.
– Les commandes associées aux pilotes d'IT sont déclarées async pour
pouvoir être exécutées en préemption des autres => elles doivent être
rapides.
– Les tâches représentent le reste de l'application et peuvent durer
longtemps dans ce cas, la règle est de créer une tâche qui retourne un
signal lorsqu'elle est terminée.
– Les tâches sont mises dans une file d'attente et exécutées l'une après
l'autre sans temps partagé.
Une tâche est déclarée par : task void nomdetache() { ... }

elle n'a pas de paramètres et ne retourne rien.
Elle sera mise dans la file d'attente des tâches à exécuter par :
post nomdetache();
Le lancement de cette tâche peut se faire dans n'importe quel code
(commande ou événement) du composant.
46
Bloc atomic
Le bloc atomic permet de définir du code qui ne
sera pas interrompu par un pilote d'IT :
atomic {
for (i=0; i < size; i++) sum = sum + rdata[i];
}
Toute la boucle ci-dessus est exécutée sans

interruption possible. Il ne faut pas en abuser
et y mettre le minimum nécessaire sinon les IT
ne seront pas prises en compte à temps.
47
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
48
Squawk
• La MV Squawk est à la norme Java ME CLDC 1.1 (Connected Limited
Device Configuration) et est en grande partie elle-même écrite en java.
– Elle fonctionne sur processeur ARM sans SE.
– La prise en compte des interruptions et les pilotes de périphériques sont en java.
En moyenne une interruption est prise en compte dans un délai de 0,15 ms mais
ce délai peut être plus long lorsque la MV exécute des tâches internes comme la
récupération de mémoire libre.
• Une application est une Midlet qui peut contenir des Isolates qui sont des
programmes qui s'exécutent en temps partagé.
– Une application peut être constituée de un ou plusieurs Isolates.
– De plus les Midlets et les Isolates peuvent lancer des threads qui s'exécutent
également en temps partagé.
• Squawk offre aussi un mécanisme de migration des Isolates qui permet de

lancer un Isolate sur un capteur, puis de l'arrêter, de l'envoyer sur un autre
capteur et de le reprendre là où il en était sur ce nouvel hôte.
49
Architecture générale
• La MV exécute du byte-code qui est obtenu par compilation du source java. Le byte-
code est très compact et occupe peu de mémoire.
• Lorsqu'un objet est créé, la mémoire est automatiquement allouée. Lorsqu'il n'est
plus utilisé, un processus de la MV – le ramasse miettes – libère la mémoire. Ce
processus est sans doute le plus fort handicap au temps réel car il est assez long à
s'exécuter et les IT ne sont pas prises en compte pendant ce temps. Par exemple il
lui faut 13ms pour nettoyer une zone mémoire de 100Ko.
50
Bibliothèques
Squawk propose les bibliothèques suivantes :
– Bibliothèques standard CLDC 1.1
– Bibliothèques pour le matériel (capteurs)
– Bibliothèques pour la radio
51
Exemple d'utilisation de
bibliothèques
Pour accéder au matériel (par exemple à l'accéléromètre).
La classe principale est EdemoBoard :
import com.sun.spot.sensorboard.EDemoBoard;
import com.sun.spot.sensorboard.IAccelerometer3d;
import com.sun.spot.util.Utils;
….
IAccelerometer3D acc = EdemoBoard.getInstance().getAccelerometer();
double ax = acc.getAccelX();
52
bibliothèques
Pour utiliser la radio (émettre vers un spot dont l'adresse est
connue)
La classe principale est Connector :
On utilise des flux (DataOutputStream et DataInputStream ) :
//Ouvrir un flux sur la radio

StreamConnection connecteur = (StreamConnection) Connector.open("radio://"+
adresseAutreSpot +":100");
DataOutputStream sortie = connecteur.openDataOutputStream();
sortie.writeInt(entierAEnvoyer);
sortie.flush();
53
bibliothèques
Pour utiliser la radio (émettre en broadcast)
On utilise des trames (Datagram) :
RadiogramConnection connecteurBroadcast = (RadiogramConnection)

Connector.open("radiogram://broadcast:114");
Datagram dg =
connecteurBroadcast.newDatagram(broadcastConn.getMaximumLength());
dg.writeUTF("Je suis un message en broadcast");
broadcastConn.send(dg);
54
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
55
Application en nesC
• nesC est lié à TinyOs et permet de créer des applications comme des
composants incluant les composants du SE utiles et seulement ceux-là.
• Une application consiste en des composants reliés entre eux exactement
comme un montage électronique.
• Un composant électronique a des entrées (des signaux qu'il utilise) et des
sorties (des signaux qu'il fournit) :
Signaux Signaux
en entrée en sortie
On fera de même pour un composant logiciel. Les signaux en entrée

sont utilisés par ce composant (donc fournis par d'autres) tandis que
les signaux en sortie sont fournis par ce composant (donc utilisées
par d'autres).
56
Application en NESC
On va ensuite interconnecter ces
composants entre eux.
En électronique on a un schéma de
câblage du type :
Il faut savoir quelles pattes d'un composant relier à quelles autres.

Pour les composants logiciels on va constituer les pattes
(commandes/événements) en groupes (interfaces) et relier directement des
groupes entres eux.
Toutes les pattes d'un groupe sont reliées à toutes les pattes d'un autre groupe
(leur nom permet de savoir lesquelles sont reliées auxquelles).
Avec nesC on distingue dans une interface les commandes (sorties) et les
événements (entrées). Les liaisons établies entre interfaces sont donc
bidirectionnelles car certaines pattes sont des entrées et d'autres des sorties.
Les commandes seront utilisées par un appel explicite (comme un appel de
fonction) tandis que les événements provoqueront automatiquement l'exécution
du code approprié dans le composant qui les reçoit.
57
Application en NESC
Les différences essentielles entre un assemblage de composants

électroniques et un assemblage nesC sont les suivantes :
– nesC offre des commandes et des événements, un composant
électronique ne traite que des événements (réagit à un signal d'entrée)
et produit des événements (signal de sortie)
– Les composants nesC sont du code exécuté par un processeur unique
=> il n'y a aucun parallélisme tandis que les composants électroniques
fonctionnent en parallélisme total (entre composants et souvent dans le
composant lui-même).
58
Un petit exemple simple
On va prendre comme exemple un petit programme qui fait clignoter
une LED sur un capteur. Il est composée d'un module
(ClignoteM.nc) et une configuration (Clignote.nc) qui va lier ce
composant aux autres (ici ceux du SE c’est à dire Main, un timer et
les leds).
Le fichier de configuration Clignote.nc :

configuration Clignote {
}
implementation {
components Main, ClignoteM, SingleTimer,
LedsC; On va le
détailler
Main.StdControl -> ClignoteM.StdControl;
Main.StdControl -> SingleTimer.StdControl;
ClignoteM.Timer -> SingleTimer.Timer;
ClignoteM.Leds -> LedsC;
}
59
Explications
}
implementation {
LedsC;

}
Au début on a un bloc configuration qui ici est vide puisqu'il s'agit

d'une application. Ce bloc contient normalement les interfaces
fournies et requises par le composant.
Ici le fichier Clignote.nc étant la configuration de premier niveau elle ne
requiert ni ne fournit rien. Il en serait différemment s'il s'agissait d'un
fichier de configuration de niveau inférieur (composant constitué
d'autres composants).
Ensuite vient le bloc implementation qui indique les composants

utilisés et les liens entre eux. Ici on indique que les composants
utilisés sont : Main, ClignoteM, SingleTimer et LedsC.
60
Explications
Le composant Main est exécuté en premier par TinyOS (c'est comme
le main en C) => toute application doit avoir un composant Main
dans sa configuration sinon ça ne démarre pas.
Main utilise une interface appelée StdControl qui contient 3
commandes : init, start et stop : configuration Clignote {
interface StdControl { }
command result_t init(); implementation {
command result_t start();

LedsC;
command result_t stop(); Main.StdControl -> ClignoteM.StdControl;
} Main.StdControl -> SingleTimer.StdControl;
}
Ces commandes sont utilisées par le système pour initialiser, lancer et

arrêter le composant. La commande init n'est exécutée qu'une seule
fois alors que les autres peuvent l'être de multiples fois.
61
Explications
}
implementation {
LedsC;

}
La ligne : Main.StdControl -> ClignoteM.StdControl;

indique que l'on relie l'interface StdControl du composant main à celle
du composant Clignote. Ceci signifie que les appels à init start et stop
de Main provoqueront des appels à init, start et stop de Clignote.
La flèche doit être comprise comme suit : le composant à gauche utilise

une interface que celui de droite fournit. Donc ici on indique que
l'interface StdControl utilisée par le composant Main lui est en fait
fournie par le composant Clignote ce qui correspond bien au fait que
les commandes init, start et stop utilisées par Main lui sont fournies
par Clignote.
62
Explications
On a la même chose entre Main et le composant SingleTimer par la ligne :
Donc le init de Main appelera celui de Clignote ET celui de SimpleTimer.
La ligne ClignoteM.Timer -> SingleTimer.Timer;

indique que l’interface Timer utilisée par Clignote est celle fournie par
SingleTimer qui est un composant de TinyOS. Ainsi dans Clignote on pourra
appeler les commandes de SimpleTimer et réagir à ses événements.
De même la ligne : ClignoteM.Leds -> LedsC;

indique que l'interface Leds utilisée par Clignote lui est fournie par LedsC qui
est aussi un composant de TinyOS. Ainsi dans Clignote on pourra appeler
les commandes de LedsC (LedsC ne produit pas d'événements).
}
Remarque : comme on n'utilise ici que des
interfaces déjà connues de nesC (StdControl, implementation {
Timer et Leds) on n'a pas a en écrire les fichiers. LedsC;
Si on avait créé un composant avec ses propres
interfaces on les aurait décrites dans des fichiers Main.StdControl -> SingleTimer.StdControl;
.nc portant le nom de l'interface. ClignoteM.Timer -> SingleTimer.Timer;
} 63
L’application Clignote
On arrive au schéma de câblage suivant :
L S
L e t
e d d
LedsC d
s
C
s o
Clignote n
T
i
t
m r
e o S
r l t
d
C
o
n
Main
t
r
S o
t l
H
W d
C
C
o
l n
o t
c r
k SimpleTimer o S
l t
d
C
T Ordonn o
i anceur n
m t
e r
r o
l
64
Syntaxe
• On appelle une commande d'une interface par :
call nom_interface.nom_commande(paramètres)
• On signale un événement par :

signal nom_interface.nom_événement(paramètres)
dans ce cas les paramètre seront transmis à la
fonction qui est associée à ce signal.
Dans l'exemple de Clignote l'événement du timer n'a
pas de paramètres.
65
Le fichier du module ClignoteM.nc
module ClignoteM {
provides {
}
interface StdControl;
La partie provides indique les
uses {
interface Timer;
interfaces fournies par ce
interface Leds; composant.
}
On y retrouve StdControl puisque
implementation {
bool etat;
ce composant la fournit à Main.
command result_t StdControl.init() {
call Leds.init();
return SUCCESS; La partie uses indique les
}
interfaces utilisées par ce
command result_t StdControl.start() {
return call Timer.start(TIMER_REPEAT, 1000) ;
composant.
} On y retrouve Timer (fournie par
command result_t StdControl.stop() { le composant SimpleTimer) et
return call Timer.stop();
} Leds (fournie par le composant
event result_t Timer.fired() { LedsC).
etat = ! etat;
if (etat) call Leds.redOn();
else call Leds.redOff();
return SUCCESS;
}
} 66
}M. Dalmau - IUT de Bayonne : Réseaux de capteurs
module ClignoteM {
La partie implementation de
provides { Clignote va contenir les codes pour
interface StdControl;
} les commandes et la prise en compte
uses {
interface Timer; des événements.
}
interface Leds; On y trouve donc les 3 commandes
de l'interface fournie StdControl et
implementation {
bool etat; celle de l'événement du SimpleTimer
call Leds.init();
(fire).
return SUCCESS; •La commande init se limite à appeler
}
init de LedsC.
command result_t StdControl.start() {
return call Timer.start(TIMER_REPEAT, 1000) ; •La commande start lance le timer en
}
mode continu pour une durée
command result_t StdControl.stop() {
return call Timer.stop();
répétitive de 1 sec.
} •La commande stop arrête le timer.
event result_t Timer.fired() { •L'événement fire provenant du timer
etat = ! etat;
se limite à basculer la led rouge
else call Leds.redOff(); (on/off) en utilisant les commandes
return SUCCESS;
} redOn et redOff de LedsC.
} 67
}M. Dalmau - IUT de Bayonne : Réseaux de capteurs
module ClignoteM { L'interface Leds fournit redOn, redOff,
provides { redToggle, greenOn …. qui peuvent être
interface StdControl; appelées par Clignote pour piloter les
}
uses { LEDs.
interface Timer;
interface Leds;
} L'interface Timer contient les commandes
implementation { et événements suivants :
bool etat; interface Timer {
call Leds.init(); command result_t start(char type,
return SUCCESS; uint32_t interval);
}
command result_t stop();
command result_t StdControl.start() { event result_t fired();
return call Timer.start(TIMER_REPEAT, 1000) ;
} }
command result_t StdControl.stop() {
start et stop sont des commandes qui
return call Timer.stop(); seront appelées par Clignote. En
}
revanche fired est un événement càd
event result_t Timer.fired() { fournit un signal et n'est pas appelée de
etat = ! etat;
façon explicite par clignote. Ce signal
else call Leds.redOff(); étant relié au composant Clignote, il
return SUCCESS; déclenchera automatiquement l'exécution
}
} du code prévu à cet effet dans Clignote.
} 68
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
69
Application en Java Squawk
• Une application est un objet qui hérite de la classe Midlet, elle peut
créer plusieurs Isolates et utiliser des threads.
• L'ensemble des fichiers compilés (.class) est placé dans un fichier

archive (.jar) puis téléchargé sur le sunSpot pour y être exécuté. Le
fichier .jar contient l'arborescence des fichiers .class et un fichier
texte (le manifeste) qui indique comment lancer l'application.
• Pour développer de telles applications et constituer le fichier jar

ainsi que pour télécharger le tout sur le spot on peut utiliser
Netbeans qui propose une extension spéciale pour cela ou ant qui
permet de lancer des commandes.
70
On va prendre comme exemple le même petit programme
qui fait clignoter une LED sur un capteur.
Les bibliothèques à inclure :
package org.sunspotworld; // paquetage du programme

// bibliothèques utilisées
import com.sun.spot.peripheral.Spot;
import com.sun.spot.sensorboard.EDemoBoard;
import com.sun.spot.sensorboard.peripheral.ITriColorLED;
import com.sun.spot.util.*;
import java.io.*;
import javax.microedition.io.*;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;
71
L’application est définie par une classe qui hérite de MIDlet et surcharges les
méthodes :
– protected void startApp() throws MIDletStateChangeException
– protected void pauseApp()
– protected void destroyApp(boolean arg0) throws MIDletStateChangeException
public class ClignoteApplication extends MIDlet {
protected void startApp() throws MIDletStateChangeException {

ITriColorLED [] leds = EDemoBoard.getInstance().getLEDs(); // les Leds du capteur
ITriColorLED cligontant = leds[0]; // la Led utilisée
clignotant.setRGB(200,0,0); // led en rouge
while (true) {
clignotant.setOn(); // allumer la LED
Utils.sleep(500); // attendre 1/2 de seconde
clignotant.setOff(); // éteindre la LED C’est tout !
Utils.sleep(500); // attendre 1/2 de seconde
}
}
protected void pauseApp() { // Normalement jamais utilisée

}
protected void destroyApp(boolean arg0) throws MIDletStateChangeException {

// appelé en cas d'exception autre que MIDletStateChangeException
}
72
M. Dalmau
} - IUT de Bayonne : Réseaux de capteurs
Fichier de manifeste
Le fichier manifeste associé à cette application est le
suivant :
MIDlet-Name: LED clignotante
MIDlet-Version: 1.0.0
MIDlet-Vendor: Sun Microsystems Inc
MIDlet-1: , , org.sunspotworld.ClignoteApplication
MicroEdition-Profile: IMP-1.0
MicroEdition-Configuration: CLDC-1.1
La ligne importante est la ligne MIDlet-1 qui indique que

l'application est dans la classe ClignoteApplication elle-
même placée dans le paquetage org.sunspotworld (voir
1ère ligne du fichier précédent).
73
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
74
Rappel des couches OSI
• Couche physique : radio
• Couche liaison : accès au médium + organisation en paquets et
contrôle d'erreurs + ajustement de la puissance d'émission.
• Couche réseau : routage par multi hop + problème des récepteurs
en veille
• Couche transport : découpage en paquets + remise en ordre +
acquittement. Couche moins utile dans les réseaux de capteurs car
on ne fait pas du contrôle bout à bout mais plutôt entre voisins =>
traité par la couche précédente.
• Couche session : pas encore utilisée
• Couche présentation : inutile en général pour le moment
• Couche application : prend souvent elle-même en charge les rôles
de toutes les couches à partir de la 3 incluse car le routage peut être
optimisé en sachant ce que fait l'appli.
Rq : le modèle OSI est pour le moment souvent bousculé pour des

raisons d'optimisation et d'énergie.
75
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
76
Couche Physique (radio)
Les systèmes les plus utilisés sont le Bluetooth, le
Zigbee qui fonctionnent sur la bande de
fréquence de 2,4 GHz.
Le wifi est trop consommateur d'énergie.
Protocole Zigbee Bluetooth Wi-Fi
IEEE 802.15.4 802.15.1 802.11a/b/g
Besoins mémoire 4 – 32 Ko 250 Ko 1 Mo
Energie nécessaire faible moyenne Elevée
Nombre de nœuds Non limité 7 32
Vitesse de transfert 250 KB/s 720 Kb/s 11-54-108 Mb/s
portée 100m 1-100m 300m
77
Bluetooth (IEEE 802.15.1)
• Créé en 1994 création par Ericsson
• Débit maximal 720 Kb/s
• trois classes :
– classe 1 : puissance 100mW portée 100m
– classe 2 : puissance 2,4mW portée 10m
– classe 3 : puissance 1mW portée 1m
• Fréquence porteuse : 2,4 GHz
• Partage temporel du média sous le contrôle d’un
maître pilotant jusqu’à 7 esclaves.
78
Bluetooth (IEEE 802.15.1)
Mode de transmission FHSS (Frequency Hopping Spread Spectrum) :
• On découpe la bande de fréquence en 79 canaux de 1MHz de
largeur. On passe de l'un à l'autre 1600 fois/s (quanta de temps de
0,625ms) selon une séquence de bandes prévues à l'avance entre
émetteur et récepteur (calculée en fonction des adresses physiques).
Ceci permet de résoudre les problèmes de mauvaise réception : si on
a un problème a un moment sur un canal on réémettra les données
mal reçues au saut suivant donc sur un autre canal.
• L'émission se fait sur 1, 3 ou 5 quanta de temps et l'acquittement sur
le quantum suivant.
• La taille des données max dans un paquet (de 5 quanta) est de 339
octets.
• On a donc 339 octets utiles pour une durée de 5+1 quanta (5
d'émission + 1 d‘ACK) donc sur une durée de 6*0,625ms. Ce qui fait
un débit maximum de (339*8)/(6*0,625) = 723 Kb/s (d'où le 720 Kb/s
annoncé).
79
Zigbee (IEEE 802.15.4)
• Créé en 2005 pour être une version allégée de Bluetooth
(consommation moindre et quantité de code très inférieure).
• Vitesses : 250Kbps à 2,4 GHz, 40Kbps à 915MHz ou 20Kbps à
868MHz.
• portée 10 à 100 m mais faible consommation.
• 16 canaux de 5MHz en 2.4GHz, 10 canaux de 2MHz en 915MHz et
un canal en 868MHz.
• Pas de garantie de délivrance de messages
• Authentification et cryptage aux niveaux MAC, réseau et application.
• Mode de transmission DSSS (Direct Sequence Spread Spectrum) :
On émet les infos sur plusieurs canaux simultanément => le récepteur reçoit
la même chose plusieurs fois et il peut fonctionner malgré les problèmes
de réception. Pour plus de sécurité on utilise des codages redondants :
chaque groupe de 4 bits est transmis sous la forme d'une séquence de
32 bits mais on n'utilise que 16 mots possibles pour pouvoir détecter les
erreurs.
80
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
81
Accès au medium (MAC)
• Le premier problème est que pour économiser l'énergie
les capteurs sont mis en veille dès qu'ils n'ont plus
d'activité. Lorsqu'un nœud émet il est fort possible que le
récepteur ou certains des récepteurs soient en veille
• Le second problème est que le réseau de capteurs a

une topologie quelconque. Les réseaux habituels ont
des topologies connues et souvent régulières (bus,
anneau …). De plus cette topologie n'est en général pas
connue à l'avance. Enfin, la puissance du signal radio
décroît comme le carré de la distance et les capteurs ont
des portées de quelques dizaines de mètres.
82
Accès au medium (MAC)
Dans un réseau classique si B et C reçoivent les messages de A alors B
reçoit ceux de C (ils sont sur le même sous-réseau). De plus, selon la
topologie (par exemple en étoile) quand A et B dialoguent C ne reçoit rien
tandis que sur un bus C reçoit tout et l'ignore.
Dans un réseau de capteurs tout message

C
émis peut être capté par tout nœud à
B A
portée (diffusion) mais la visibilité des
nœuds est différente, par exemple :
B et C reçoivent les messages de A mais B ne reçoit pas ceux de C.
Conséquence : quand A et B dialoguent C reçoit ce que A émet mais pas

ce que B répond. Si C émet en même temps il perturbe A mais pas B
donc B continue à recevoir les messages de A mais A ne reçoit plus les
réponses de B.
83
Problème des nœuds en veille
Pour résoudre le problème des nœuds récepteurs en veille on peut utiliser un
système de préambule càd que le nœud émet une trame sans informations
utiles qui sert à alerter les autres nœuds.
Chaque nœud en veille se réveille à intervalles réguliers pour écouter le

médium. Il suffit que le préambule dure suffisamment longtemps pour que
tous les nœuds se réveillent pendant ce temps.
A la fin du préambule le nœud peut émettre ses infos, il est sûr que le ou les
récepteurs sont à l'écoute.
En retour il reçoit un acquittement.
Exemple : si un nœud met 1ms à se réveiller et passer en écoute et que le

préambule dure 1s, lorsqu'il n'y pas de transmission les nœuds peuvent
rester en veille 99,9% du temps.
Un préambule trop court => se réveiller souvent (et souvent pour rien)
Un préambule trop long => perte d'énergie pour émettre
On trouve un compromis par une étude statistique en prenant une durée de
préambule de l'ordre de 4 à 6 fois la durée d'une trame. 84
Problème de visibilité des stations
Rappel : La puissance du signal radio décroît comme le carré de la distance.
Cas pratique : on a 4 nœuds A, B, C et D
B émet vers A
A
C veut émettre vers D. C capte ce que B C
émet donc conclut le médium est B D
occupé et ne commence pas son
émission.
Pourtant il pourrait émettre car son signal
brouillerait la réception de B mais pas
celle de A, or B n'est pas récepteur,
tout au plus il ne pourrait pas écouter
sa propre émission mais ce n'est pas
gênant.
85
Rappel : La puissance du signal radio décroît comme le carré de la distance.
Cas pratique : on a 4 nœuds A, B, C et D
B émet vers A
C veut émettre vers D. C capte ce que B A
émet donc conclut le médium est C
B D
occupé et ne commence pas son
émission.
Pourtant il pourrait émettre car son signal
brouillerait la réception de B mais pas
celle de A, or B n'est pas récepteur,
tout au plus il ne pourrait pas écouter
sa propre émission mais ce n'est pas
gênant.
86
Solution possible : protocole RTS/CTS ou MACA
(Medium Access with Collision Avoidance)
adopté dans 802.11
– Quand A veut émettre vers B, il envoie un message

RTS avec le nombre d'octets qu'il veut émettre
– B répond par un message CTS avec ce même
nombre. Puis l'envoi a lieu avec un retour ACK ou
NACK.
87
Exemple d'illustration :
C A B D
E F
Étude de cas (1) : A veut communiquer avec B => il lui envoie un RTS et B
répond par un CTS
Les nœuds à portée de A (C et E) voient le RTS => ils savent être à portée de
l'émetteur => ils attendent pour voir s'ils reçoivent le CTS de B.
– S'ils le reçoivent (c’est le cas de E) ils savent être à portée de l'émetteur ET du

récepteur => ils ne peuvent rien faire. Le nombre d'octets indiqué dans le CTS
leur permet de savoir combien de temps ils doivent attendre.
– Sinon (c’est le cas de C) ils savent être à portée de l'émetteur mais pas du
récepteur => ils pourraient émettre en même temps. Mais leur émission peut
brouiller le ACK de B en retour ! De plus l'émission de A peut brouiller le CTS en
réponse à leur propre RTS !
88
C A B D
E F
répond par un CTS
Les nœuds à portée de B mais pas de A (c’est le cas de D) voient le CTS mais
pas le RTS => ils ne peuvent pas émettre. Le nombre d'octets indiqué dans
le CTS leur permet de savoir combien de temps ils doivent attendre.
Les nœuds qui ne sont à portée ni de A ni de B (par exemple F) ne voient ni le
RTS ni le CTS, ils peuvent donc émettre sans gêner personne.
Un nœud à portée de B (par exemple D) peut ne pas voir le CTS de B parce
que F émet et le brouille => il ne sait pas que A et B communiquent.
89
C A B D
E F
répond par un CTS
Collision du RTS de A avec un autre (par exemple E) => ni A ni E ne reçoivent

de CTS => ils réessaieront plus tard (délai aléatoire type CSMA/CD)
90
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
91
Protocoles utilisés
• Les principes de préambule et de RTS/CTS
restent utilisés mais on définit des protocoles
spéciaux pour en résoudre les problèmes de
fonctionnement :
• PAMAS
• SMAC
• T-MAC
• WiseMAC
• AMRIS
• Multi-fréquences
92
PAMAS
Référence : S. Singh, M. Woo, and C. S. Raghavendra. Power-aware routing in
mobile ad hoc networks. In ACM SIGCOMM Computer Communication
Reviewarchive, volume 28 (3), pages 5–26, 1998.
PAMAS (Power Aware Multi-Acces protocol with Signaling for ad-hoc

networks), utilise un canal différent pour les messages RTS/CTS de celui
utilisé pour les communications.
On peut envoyer un RTS n'importe quand, si le récepteur est disponible il

répondra par CTS sinon on réessaiera.
Une station en cours de communication qui voit passer un RTS sait qu'elle
risque d'être brouillée pour l'éviter elle envoie un message "busy" qui
brouille le CTS qui viendrait en réponse à ce RTS => l'autre ne le recevra
pas, elle réessaiera plus tard.
On peut améliorer ça en mettant dans le busy le nombre d'octets restant à
émettre => celui qui avait tenté un RTS sait combien de temps il doit
attendre avant de réessayer.
93
PAMAS
Diagramme d’état de PAMAS. C’est presque le même que

celui du protocole RTS/CTS. Il ne diffère que par la prise en
compte de nouvelles communications (RTS) pendant
l’émission ou la réception.
94
SMAC
Référence : W. Ye, J. Heidemann, and D. Estrin. An energy-
efficient mac protocol for wireless sensor networks. In IEEE
Infocom New York, New York (NY), USA, June 2002.
SMAC (Sensor MAC), on divise le temps en périodes de

veille ou de traitement et périodes de communication =>
tous les nœuds entrent en période de communication en
même temps.
Si cette période est assez longue ils parviennent tous à
envoyer tout ce qu'ils ont à envoyer
sinon ils mémorisent le reste pour la prochaine période mais
les capteurs n'ont pas beaucoup de mémoire => ils ne
doivent pas mémoriser trop de choses.
95
SMAC
Question : Comment synchroniser ces périodes sur les capteurs ?
Réponse : on utilise un timer aléatoire à l'init de chaque capteur. Pendant ce

délai il écoute si à la fin du délai il n'a rien entendu il émet un message
SYNC => celui qui a eu le plus petit délai émet le SYNC et devient le
synchronisateur, les autres l'entendent et savent qu'ils sont suiveurs.
Le message SYNC indique qu'il faut attendre un délai t => tous les suiveurs
savent qu'il vont commencer leur cycle veille/communication après ce délai
t => ils seront synchro. Ils répondent au synchronisateur qu’ils se sont
synchronisés avec lui.
Pour éviter que les réponses des suiveurs n'entrent en collision, chacun
répond après un délai aléatoire d < t en indiquant qu'il va commencer son
cycle dans t-d.
On peut avoir plusieurs synchronisateurs s'ils ne se captent pas entre-eux =>

on a un synchronisateur par zone de couverture. Tout nœud est à portée
d'au moins un synchronisateur mais peut l'être de plusieurs.
96
SMAC
Synchronisateur Synchronisateur
Nœud frontalier
Nœud frontalier
Les nœuds en gras constituent les nœuds centraux des groupes

(synchronisateurs).
A l’intersection, des nœuds (nœuds frontaliers) connaissent plusieurs
groupes et peuvent faire la jonction.
97
SMAC
Remarque : Chaque synchronisateur crée une sorte de réseau virtuel
contenant tous ceux qui le suivent. Les nœuds qui sont à portée de
plusieurs synchronisateurs peuvent appartenir à plusieurs réseaux
virtuels et donc servir de passerelles entre ces réseaux virtuels.
Pour ce faire ils vont adopter un cycle veille/transmission
correspondant aux 2 (ou plus) synchronisateurs qu'ils captent.
Pour éviter les dérives d'horloges à long terme on peut faire des
phases de re-synchronisation de temps en temps en début de
période de transmission.
Pendant les périodes de transmission on utilise un "virtual carrier

sense" càd que un nœud qui reçoit un RTS qui n'est pas pour lui va
initialiser un NAV (Network Allocation Vector) avec la durée
correspondant au nombre d'octets indiqués dans le RTS. Il peut
alors arrêter son récepteur radio. Le NAV est décrémenté
automatiquement à chaque période correspondant à l'émission d'un
octet. Tant qu'il n'est pas à 0 on sait que le médium est occupé sans
avoir à mettre en marche le récepteur pour écouter.
98
T-MAC
Référence : T. van Dam and K. Langendoen. An adaptive energy-efficient mac protocol
for wireless sensor networks. In Proceedings of the 1st international conference on
Embedded networked sensor systems, pages 171–180, Los Angeles (CA), USA,
November 2003.
L'inconvénient de SMAC est que la période de transmission doit être assez longue pour
écouler tous les messages. Mais quand il y en a moins elle dure inutilement. On peut
penser à proposer que, lorsque le médium reste libre pendant une certaine durée θ,
ça signifie qu'il n'y a plus rien et les nœuds passent en veille. Mais cette solution
pose le problème suivant :
On part de la topologie suivante : A B C D

Où C voit B et D mais pas A.
A communique avec B et C veut communiquer avec D.

A envoie un RTS à B et B répond par CTS => C sait que c'est occupé en recevant ce
CTS => il va attendre un délai correspondant à la durée de la communication A/B
D n'a rien vu de tout ça (il ne capte que C) => il croit que le médium est libre et passe en
veille après le délai θ et il ne recevra pas le message de C pour ce cycle ! Si ce
phénomène se répète souvent C devra garder beaucoup de messages pour D au
risque de ne pas avoir assez de mémoire.
99
T-MAC
Solutions possibles à ce problème :
• Solution 1 :
A envoie un RTS à B et B répond par CTS => C sait que c'est occupé en
recevant ce CTS mais pour empêcher D de se mettre en veille il
pourrait lui envoyer un message spécial FRTS (Future RTS) dès que B
a envoyé son CTS.
Mais ce message entrerait en collision avec le début de la communication

A/B. Pour éviter ça on impose que toute communication commence par
un message inutile qui peut être brouillé et dont B ne tiendra pas
compte.
Dans son message FRTS, C va inclure la taille de la communication A/B

qu'il a récupérée dans le CTS de B pour que D sache combien de
temps il peut se mettre en veille.
A la fin de la communication A/B, C n'est pas sûr d'obtenir l'accès au

média mais si ce n'est pas le cas il pourra toujours réémettre un FRTS.
100
T-MAC
Solutions possibles à ce problème :
• Solution 2 :
La décision de terminer la période de transmission est prise par
chaque nœud en fonction de la taille de ses buffers.
Donc dans l'exemple précédent D ne terminera pas sa période de

transmission s'il a des messages à émettre sinon tant pis.
Pour éviter la saturation des buffers un nœud peut refuser une

réception. Ainsi, pendant la communication A/B si le buffer de B
devient plein il ne répond plus au RTS de A refusant ainsi la
communication A/B. Il pourra par contre émettre un RTS vers un
autre nœud pour entrer en communication avec lui et vider ses
buffers afin de pouvoir, plus tard, recevoir ce que A voulait lui
envoyer.
101
WiseMAC
Référence : A. El-Hoiydi, J.-D. Decotignie, C. Enz, and E. Le Roux. wisemac, an ultra
low power mac protocol for the wisenet wireless sensor network. In Proceedings of the
1st international conference on Embedded networked sensor systems, pages 302–
303, Los Angeles (CA), USA, November 2003.
On a vu au début que le problème de base d'accès au médium était le suivant :

Lorsqu'un nœud veut émettre il est fort possible que le récepteur ou certains des
récepteurs soient en veille.
On utilise un système de préambule càd que le nœud émet une trame sans informations
utiles qui sert à alerter les autres nœuds. Chaque nœud en veille se réveille à
intervalles réguliers pour écouter le médium. Il suffit que le préambule dure
suffisamment longtemps pour que tous les nœuds se réveillent pendant ce temps.
A la fin du préambule le nœud peut émettre ses infos, il est sûr que le ou les récepteurs
sont à l'écoute.
On a vu aussi qu'il fallait que le préambule soit suffisamment long pour être sûr que tous
les nœuds se réveillent pendant qu'il est émis. On peut réduire cette durée si on sait
d'avance quand les autres nœuds vont se réveiller (ou en tout cas à très peu près
quand).
102
WiseMAC
SMAC et T-MAC utilisaient un système assez compliqué de synchronisateurs pour faire
en sorte que les nœuds se réveillent au même moment. On peut éviter ça : chaque
nœud a son propre rythme veille/transmission mais les autres le connaissent => ils
savent quand émettre pour trouver ce nœud éveillé.
Principe de WiseMAC : quand un récepteur envoie un ACK il y joint les infos sur son
rythme => l'émetteur le connaît. De plus tous les nœuds qui étaient à l'écoute à ce
moment le connaissent aussi.
Petit à petit chaque nœud complète une table indiquant les rythmes des autres => il peut
communiquer avec eux.
Quand un émetteur n'a pas l'info de rythme du récepteur il peut utiliser un long
préambule comme avant mais dès qu'il aura joint le récepteur (reçu le ACK) il aura
l'info de rythme.
Quand il l'a il suffit qu'il émette son préambule (court) un petit peu avant la date de réveil
de l'autre. Ce délai est calculé en fonction de la dérive maximale des horloges θ (en
général de l'ordre de 10-5), et du temps L écoulé depuis qu'il n'a pas communiqué
avec ce récepteur par la formule : délai = 4 L θ.
L'avantage c'est qu'on n'a pas besoin de synchro et pas de risque de désynchronisation
des horloges.
103
WiseMAC
Etude de cas sur ce protocole
L'estimation du délai par 4 L θ est fausse car θ est
surestimé (en réalité les horloges de A et B peuvent par
hasard être très synchro).
– L'émetteur ne peut pas être en retard car le délai choisi

4 L θ correspond au cas pire de dérive des horloges.
– Par contre l'émetteur peut être en avance : Il faut que le

préambule soit assez long pour attraper quand même le
récepteur en fait il faut qu'il dure au moins 4 L θ.
104
AMRIS
Référence : C. Wu and Y. Tay. Amris: A multicast protocol for ad hoc wireless networks.
In In Proceedings of IEEE MILCOM’99, Atlantic City (NJ), USA,
November 1999.
Protocole adapté au cas où certains nœuds sont mobiles. Il consiste en la création de groupes
de multicast. Ces groupes peuvent correspondre à des positions géographiques, à des types
de capteurs etc. AMRIS constitue un ou plusieurs arbres correspondant au(x) groupe(s).
Principe : Le nœud racine de l'arbre émet un message Por

NEW_SESSION, tous ceux qui le reçoivent lancent un délai t
nœ ée du
ud
aléatoire. Quand ce délai se termine le nœud conserve dans r ac
ine
une table les nœuds qu'il a reçu et choisit celui qui sera son
père. Le premier qui termine son délai choisit évidemment le
nœud racine.
Puis il émet lui-même un message de NEW-SESSION => ceux
qui le recevront et auront aussi reçu celui du nœud racine
choisiront leur père entre le nœud racine et celui-ci. Petit à Port
é
nœu e du
petit tous les nœuds ont choisi un père. d5
Ensuite chaque nœud indique s'il rejoint ou pas ce groupe en répondant JOIN-ACK ou JOIN-
NACK. On peut ainsi constituer plusieurs groupes ayant chacun un nœud racine différent.
105
AMRIS
Maintenance : Comme certains nœuds peuvent bouger, à intervalles régulier
chaque nœud vérifie qu'il peut toujours contacter son père.
S'il n'y parvient pas après 3 essais il supprime ce lien de sa table. Les
éventuels nouveaux nœuds utilisent ces messages pour mettre leur propre
table à jour => on détecte les nœuds perdus, arrivés ou s'étant déplacés.
Quand un nœud a perdu son père (après 3 essais) il émet un message BJOIN-
REQ à tous ces voisins. Ceux qui font partie de son groupe y répondent par
un message JOIN-ACK tandis que les autres se contentent de le
retransmettre (en utilisant un TTL comme avec TCP/IP). Avec ces
réponses, s'il en a, le nœud pourra se choisir un nouveau père.
106
Multi fréquences
Référence : K. Sohrabi, J. Gao, V. Ailawadhi, and G.J. Pottie. Protocols
for selforganization of a wireless sensor network. IEEE Personal
Communications, 7(5):16–27, October 2000.
PAMAS propose d'utiliser une fréquence différente pour les messages

RTS/CTS. Lorsque l'on dispose de plusieurs fréquences on peut
utiliser le protocole SMACS (Self-organizing Medium Acces Control
for Sensor networks) pour communiquer entre nœuds statiques et
son extention EAR (Eavesdrop And Register) pour les nœuds
mobiles.
Principe : Comme dans SMAC ou T-MAC on crée des groupes de

nœuds adjacents qui partagent le même cycle veille/transmission.
Mais comme on peut utiliser des fréquences différentes certaines
communications peuvent se faire en parallèle sans se brouiller.
107
Multi fréquences
Auto-configuration (SMACS) :
Cette partie du protocole ne concerne que les nœuds fixes.
– Au départ tous les nœuds fixes attendent un délai aléatoire
avant d'envoyer un message d'offre sur une fréquence fixée à
l'avance.
– Pendant ce délai ils écoutent sur cette fréquence s'ils reçoivent
un message d'offre d'un autre nœud.
– Les nœuds fixes qui reçoivent cette offre attendent un délai
aléatoire puis y répondent sur la même fréquence par un
message d'acceptation.
– L'émetteur choisit un candidat parmi toutes les réponses (on
peut par exemple choisir celui dont le signal est le plus fort) et lui
envoie un message d'invitation.
– Les autres nœuds qui avaient répondu reçoivent ce message
d'invitation et ainsi savent qu'ils n'ont pas été choisis ils
attendent donc une autre offre.
108
Multi fréquences
Auto-configuration (SMACS) :
Cette partie du protocole ne concerne que les nœuds fixes.
– Le message d'invitation contient la table des fréquences
disponibles sur celui qui invite.
• Le récepteur en choisit une en fonction de ses propres possibilités
et des fréquences déjà utilisées par ses voisins (s'il le sait).
• Le récepteur renvoie la fréquence qu'il a choisie à l'émetteur (ils
dialogueront à l'avenir sur cette fréquence) dans un message de
confirmation. La connexion entre ces 2 nœuds est établie.
– A la fin tous les nœuds ont fait une offre et éventuellement invité
quelqu'un qui a accepté l'invitation => la connectivité est établie
avec des fréquences de dialogue négociées 2 à 2.
109
Multi fréquences
Mobilité (EAR) :
– Quand tous les nœuds fixes ont établi leurs communications (SMAC), ils
émettent de nouvelles offres sur la fréquence prévue pour ça. Les nœuds
mobiles surveillent ces messages. La réception de ces messages leur permet de
mesurer la qualité du signal et de détecter leurs nouveaux voisins (fixes). Ils
répondent à l'invitation en indiquant les fréquences qu'ils peuvent utiliser et les
nœuds fixes contactés acceptent ou pas cette réponse. S'ils acceptent ils
envoient un message de confirmation.
– Quand un nœud mobile trouve de nouvelles connexions il peut choisir de ne plus
utiliser certaines qu'il avait avant si elles sont de moins bonne qualité. Pour cela
il envoie aux nœuds dont il veut se couper un message de déconnexion.
– Comme il est toujours possible qu'un message de déconnexion ne parvienne pas
à son destinataire (puisqu'il a été envoyé par un nœud mobile qui perdait la
connexion), les nœuds fixes peuvent eux aussi se déconnecter si la qualité de la
connexion devient trop mauvaise. Ils n'envoient rien car ils supposent que ça ne
marcherait pas et que le nœud mobile a lui aussi détecté la perte de connexion.
Remarque : le message de déconnexion est utile car un nœud mobile peut se

déconnecter d'un fixe qu'il reçoit bien en faveur d'un qu'il reçoit mieux. En
revanche un nœud fixe ne se déconnecte d'un mobile que si la qualité est
rédhibitoire.
110
Multi fréquences
• Problèmes possible : On n'a pas une quantité de fréquences
utilisables infinie donc il se peut que 2 nœuds voisins ne
parviennent pas à trouver dans leurs tables de fréquence de
dialogue commune.
Ça peut ne pas être grave sauf si ces 2 nœuds sont les seuls qui
permettraient d'établir des communications entre deux groupes.
• Améliorations possibles : Chaque groupe a son propre cycle

veille/transmission qui démarre en fonction de délais aléatoires
utilisés au démarrage (cf. SMAC). Deux groupes voisins peuvent
avoir des périodes de transmission qui se chevauchent => certaines
fréquences ne peuvent pas être utilisées car elles se brouilleraient.
Si on choisissait des périodes sans chevauchement chaque groupe
disposerait de plus de fréquences utilisables.
111
Correction d'erreurs
• On peut corriger à la couche 2 par des codes correcteurs ou aux
couches supérieures par retransmission.
• Certains types d'erreurs (parasites) rendent des trames entières non

lisibles, d'autres (signal faible) ne modifient que quelques bits. Les
seconds sont facilement traitables par des codes correcteurs mais pas
les premiers.
• Codes correcteurs connus : Hamming, CRC :

– CRC-8 (ATM) : X8 + X2 + X + 1
– CRC-12 (HDLC) : X12 + X11 + X3 + X2 + X + 1
– CRC-16 (CCITT) : X16 + X12 + X5 + 1 (utilisé par bluetooth, zigbee)
– CRC-32 (Ethernet) : = X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 +
X4 + X2 + X + 1
– CRC-64 (ISO) : X64 + X4 + X3 + X + 1
112
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
113
Positionnement et localisation
• Il est en général important de savoir d'où viennent les informations émises
par les capteurs.
• Positionnement : chaque nœud a des coordonnées connues

• Localisation : on peut situer chaque nœud relativement aux autres (en
distance) mais on ne sait pas où ils sont en terme de coordonnées
géographiques.
• Si un nœud connaît sa position réelle la localisation peut être transformée

en positionnement à une rotation près puisqu'on connaît des distances mais
pas des angles.
• Si on a au moins 2 nœuds qui connaissent leurs coordonnées on peut
passer à un positionnement avec une incertitude qui est que toute la carte
des nœuds peut être en effet miroir par rapport à la ligne reliant ces 2
nœuds.
• Actuellement on utilise le GPS (précision de 15 mètres) avec Galileo on

aura (5 à 8 mètres), c'est en général suffisant.
114
(GPS)
Le GPS est constitué de 28 satellites à 20200
Km (24 actifs et 4 de secours) qui émettent
des trames de 1023 bits (chacun émet une
trame différente). En chaque point du globe
on peut capter 4 satellites. Les trames servent
à calculer la distance du satellite.
Les satellites de la constellation, équipés d'une

horloge atomique d'une extrême précision,
émettent des messages indiquant leur heure
de départ du satellite et la position du satellite.
Le récepteur au sol possède en mémoire les
coordonnées précises des orbites de tous les
satellites. Il reçoit le signal d'un satellite et
chronomètre le temps qu'il a mis pour arriver.
Multiplié par la vitesse du signal, il obtient sa
distance par rapport à lui.
115
(GPS)
La distance d'un satellite permet de tracer la
sphère dans laquelle il se situe.
Avec un deuxième satellite on a les points
d'intersections de 2 sphères càd un cercle.
Avec un troisième satellite on à une autre

sphère qui coupe le cercle en 2 points.
Normalement il en faudrait un 4éme mais
en général l'un des 2 points n'est pas sur
la terre mais dans l'espace donc on sait
qu'on est à l'autre.
En fait le 4ème satellite est utile pour

compenser les erreurs dans les calculs de
distances (=> correction de l’horloge du
récepteur).
116
• Équiper tous les capteurs de GPS est trop cher et ne sert qu'au
démarrage si les capteurs sont fixes. On peut se contenter de
n'en avoir que quelques uns ou même de mettre à la main les
coordonnées géographiques de quelques capteurs fixes.
Bien entendu le problème reste entier pour les capteurs mobiles.
• Solutions possibles selon les cas :

Quelques positions connues Aucune position connue
Possibilité de connaître les Topologie complète en Topologie complète en
distances aux voisins coordonnées géographiques coordonnées relatives
Impossible de connaître les Positionnement approximatif Matrice de connectivité
distances aux voisins
117
Positionnement global sans
estimation de distances
Référence : T. Adebutu, L. Sacks, and I. Marshall. Simple position
estimation for wireless sensor networks. In London Communications
Symposium 2003, London, United Kingdom, September 2003.
Principe : Un nœud N qui capte k nœuds voisins

connaissant leur position mais qui n'a aucun moyen de
connaître leur distance vis-à-vis de lui peut estimer sa
distance comme le centre géographique de ces k nœuds.
Plus k est grand plus cette valeur est exacte.
Un nœud qui a déterminé sa position de cette façon peut lui

aussi aider d'autres nœuds à préciser la leur.
118
Zone Zone commune à
commune à A1 , A2 et β
A1 et A2
Zone commune à
B1 et B2
Sur l'exemple de la figure ci-dessus, le nœud α s'est positionné par

rapport aux nœuds A1 et A2 donc dans la zone grisée.
Le nœud β peut faire de même avec B1 et B2.
Mais le fait que α et β se voient montre qu'ils sont plutôt aux extrémités
(sud pour α et nord pour β) de ces zones.
119
Méthode utilisée : sur ce principe on peut mettre
en place un processus itératif :
1. chaque nœud non positionné prend pour coordonnées le
milieu géographique de ses voisins positionnés
2. On recommence cette opération mais en y incluant tous les
voisins (même ceux positionnés en 1. => on corrige sa
position (nouveau centre géographique)
3. On réitère l'étape 2. jusqu'à ce que la position calculée ne
change plus (ou trop peu).
Cet algorithme converge vers des positions pas
trop mauvaises.
120
Positionnement global avec
Référence : L. Doherty, K. S. J. Pister, and L. El Ghaoui. Convex
position estimation in wireless sensor networks. In Proc. IEEE
Infocom 2001, Anchorage, AK, USA, April 2001.
On utilise une méthode itérative comparable à la

précédente mais en tenant compte de la distance
mesurée avec les voisins (fixes ou pas) ce qui permet
d'améliorer le résultat. C'est un problème de
programmation linéaire qui suppose des calculs
relativement compliqués mais pour lesquels on connaît
des méthodes (algorithme du simplexe).
Le principe de base est la triangulation :

121
Positionnement global avec
Triangulation
Sur le dessin ci-dessus les nœud i et j sont positionnés mais pas le nœud n
mais il connaît sa distance à i et à j.
Le nœud n est donc à l'intersection du cercle de rayon dn,i centré sur i et du
cercle de rayon dn,j centré sur j.
En réalité on a 2 points d'intersection de ces cercles mais en général un seul
peut être retenu en utilisant les autres voisins de n même s'ils sont non
positionnés avec précision car sur l'un des 2 points certain d'entre eux
seraient hors de portée de n.
122
Positionnement sans positions
connues
• Le but est d'obtenir des coordonnées relatives entre les nœuds.
• Le principe est que si on connaît la distance entre un nœud i et 2 nœuds p
et q et celle entre p et q on peut calculer l'angle A (piq). On utilise pour cela
les propriétés géométriques du triangle suivantes :
i
p
q
On peut alors calculer des positions relatives de p et q par
rapport à i. q
On considère que i a les cordonnées (0,0) et que p a les
coordonnées (dip,0) on en déduit que q a les coordonnées
(diq cos(A), ± diq sin(A)). A
On pourra lever l'ambiguïté du signe de la seconde
coordonnée en utilisant les autres voisins et la portée de i p
la radio comme vu précédemment.
123
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
124
Routage
Les approches de type TCP/IP supposent que chaque machine joue un
rôle spécial et que l'on s'adresse à elle pour un service particulier.
Ce n'est pas le cas des réseaux de capteurs.
En effet, un capteur est :
– soit utilisé pour les données qu'il possède
– soit pour sa localisation.
On distingue 3 catégories de protocoles de routage :

– Routage à plat : tous les nœuds jouent un rôle identique
– Routage hiérarchique : les nœuds ont des rôles différents
– Routage basé sur la localisation : la route est calculée en fonction de la
position des nœuds
Par ailleurs la façon de trouver une route peut elle-même être divisée
en 3 catégories :
– Proactive : les routes sont calculées avant d'être utilisées
– Réactives : les routes sont calculées à la volée
– Hybrides : on mélange les deux méthodes précédentes
125
Routage
Lorsqu'un message circule sur une route, il est possible de lui agréger
des données récupérées sur son passage de façon à constituer une
information complète.
Si la route n'a pas été prévue dans ce but il se peut qu'à l'arrivée
l'information ne contienne pas toutes les données qui auraient pu y
être agrégées mais seulement celles qui ont été glanées sur la
route.
On peut vouloir mettre en place des protocoles de routage qui trouvent

des routes passant par tous les points où il y a une partie d'info à
récupérer.
126
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
127
Protocoles de routage à plat
Inondation et inondation aléatoire
Référence : HEDETNIEMI, S., HEDETNIEMI, S., AND LIESTMAN, A.

"A Survey of Gossiping and Broadcasting in Communication
Networks". Networks 18 (1988).
• Inondation (flooding) : Chaque nœud envoie l'info à tous ses

voisins sauf celui d'où il l'a reçue.
• Inondation aléatoire (gossiping) : Chaque nœud envoie l'info à

certains de ses voisins choisis au hasard y compris à celui qui la lui
a envoyée.
Il faut qu'un nœud puisse renvoyer l'info à son émetteur pour qu'elle
puisse arriver partout. En effet, lorsqu'il la reçoit pour la deuxième
fois, l'émetteur peut choisir d'autres voisins au hasard et par
conséquent faire en sorte qu'elle arrive à bon port alors que son
premier choix ne le permettait pas.
128
SPIN (Sensor Protocol for Information via Negociation)
Références : W. Heinzelman, J. Kulik, and H. Balakrishnan, "Adaptive Protocols for
Information Dissemination in Wireless Sensor Networks," Proc. 5th ACM/IEEE
Mobicom Conference (MobiCom '99), Seattle, WA, August, 1999. pp. 174-85.
J. Kulik, W. R. Heinzelman, and H. Balakrishnan, "Negotiation-based protocols for
disseminating information in wireless sensor networks," Wireless Networks, Volume: 8,
pp. 169-185, 2002.
Il s'agit d'une famille de protocoles en 3 étapes qui utilise 3 types de messages.

– Quand un nœud veut envoyer une information, pour éviter de consommer trop
d'énergie, il envoie à tous ses voisins un message ADV qui contient une
description de cette information. Cette description est plus brève que l'information
elle-même (par exemple si l'info est une image) et coûte moins cher à diffuser. Le
protocole ne définit pas le contenu de cette description, il dépend de l'application.
– Si le voisin n'a pas déjà reçu cette information il répond par un message REQ. Il
recevra alors cette information dans un message DATA.
– Après quoi chacun des nouveaux nœuds détenteurs de l'information recommence
ce processus jusqu'à ce que tout le réseau ait pu prendre connaissance de cette
information.
129
SPIN (Sensor Protocol for

Information via Negociation)
Sur l'exemple ci-dessus l'un des voisins de B ne répond pas au ADV de B parce qu'il a déjà eu l'info.
Remarque : L'intérêt de cette méthode est qu'elle permet de faire de l'agrégation d'information. Ainsi si B
qui a reçu l'info de A veut y ajouter une info qu'il a, il lui suffit de transmettre à ses voisins un
nouveau descriptif plus complet dans son message REQ.
Une version amélioré de ce protocole est appelée SPIN-2 pour économiser l'énergie. Le principe est que
si un nœud n'a pas assez d'énergie pour aller au bout des 3 étapes du protocole, il n'y participe pas.
130
Diffusion dirigée
Référence : C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed diffusion: A scalable and robust
communication paradigm for sensor networks. In Proceedings of MobiCOM, Boston (MA), USA,
August 2000.
Il s'agit d'établir des communications régulières entre nœuds, bien entendu on peut l'utiliser pour une
communication ponctuelle mais c'est un peu lourd dans ce cas.
Une demande prend la forme suivante :

– Type : type d'information demandée
– Fréquence : chaque combien de temps cette information doit être transmise
– Zone : peut être utilisé pour définir, quand c'est possible, la zone géographique (rectangle)
dans laquelle l'émetteur de l'information doit se situer
– Date de demande : date à laquelle la demande est faite
– Date d'expiration : date à partir de laquelle la demande n'est plus maintenue
Un nœud qui est intéressé pour recevoir un certain type d'information diffuse une telle demande à tous
ses voisins et chaque nœud la rediffuse à tous ses voisins. Même s'il la reçoit plusieurs fois,
chaque nœud ne la diffuse qu'une seule fois. Le ou les nœuds qui détiennent l'information
demandée la diffusent de la même façon.
Avec ces échanges les nœuds vont déterminer la ou les routes possibles.
131
Diffusion dirigée
Il faut maintenant choisir une route parmi les routes possibles ainsi déterminées :
• Méthode dite de Gradient-Based Routing

Référence : C. Schurgers and M.B. Srivastava, "Energy efficient routing in wireless
sensor networks", in the MILCOM Proceedings on Communications for Network-
Centric Operations: Creating the Information Force, McLean, VA, 2001.
On va choisir la route la plus courte en nombre de hops :

chaque nœud détermine sa distance en hops au destinataire final, comme ses
voisins ont fait la même chose, le gradient du lien entre 2 nœuds A et B est la
différence entre la distance de B au destinataire et celle de A.
A choisira d'envoyer sur le lien de plus fort gradient (celle qui rapproche le plus).
On peut fignoler ce procédé pour tenir compte de l'énergie en augmentant le poids
d'un nœud quand son énergie baisse (pour éviter de passer pas là). Quand 2
liens ont le même poids on en prend un au hasard mais on peut aussi essayer
de répartir la charge en faisant en sorte de ne pas choisir le même voisin pour
plusieurs routes si le gradient est le même.
132
Diffusion dirigée
Il faut maintenant choisir une route parmi les routes possibles ainsi
déterminées :
Méthode basée sur l'énergie

Référence : R. C. Shah and J. Rabaey, "Energy Aware Routing for
Low Energy Ad Hoc Sensor Networks", IEEE Wireless
Communications and Networking Conference (WCNC), March
17-21, 2002, Orlando, FL.
Au lieu de choisir une route optimale on conserve un ensemble de

routes possibles. Puis on choisit la route qui minimise l'énergie.
L'énergie consommée par chaque route est calculée lors de la
diffusion de la requête. Cette méthode permet d'augmenter la
durée de vie du réseau jusqu'à 40%.
133
Diffusion dirigée
• Après quoi les nœuds (demandeur et répondeurs) utiliseront, pour ces
échanges, les routes ainsi déterminées.
• Chaque nœud doit donc maintenir une table pour savoir, pour chaque type
de demande, à qui il doit faire passer. Cette table lui permet en outre
d'éviter de retransmettre une demande qu'il a déjà transmise.
• Le principe utilisé pour les demandes (diffusion totale) fait que chaque
nœud a connaissance de toutes les demandes du réseau.
• Lorsqu'elle est utilisé l'information de zone permet de limiter ça à une partie

du réseau c'est-à-dire qu'un nœud qui est hors zone et dont tous les voisins
le sont aussi peut oublier cette demande. Attention un nœud hors zone dont
un voisin est dans la zone peut servir de relais à la communication, il doit
donc conserver la demande.
134
Diffusion dirigée
• Quand une demande est diffusée, tout nœud dans la zone qui obtiendra
une information correspondant à cette demande la transmettra par la route
optimale au demandeur. Il arrêtera de transmettre quand la date limite sera
atteinte.
• Un nœud qui reçoit une telle info consulte sa table de demandes pour
savoir si elle correspond à une réponse à une demande ou pas. Dans le
premier cas il la fait passer par le chemin optimal tandis que dans le second
il la diffuse à tous ses voisins (ce qui correspond à la diffusion totale utilisée
avant d'avoir déterminé la route optimale).
Remarque : l'utilisation de la date d'expiration peut permettre de traiter la

mobilité. On suppose qu'une route reste utilisable jusqu'à cette date puis
on recommencera la recherche de route optimale en émettant une nouvelle
demande. Ceci permet aussi de prendre en compte le fait que l'information
demandée peut concerner un nouveau nœud par exemple un nœud qui
s'est déplacé à l'intérieur de la zone d'intérêt alors qu'il n'y était pas quand
la route a été établie.
135
Diffusion dirigée
• Avantages :
Marche même dans des conditions difficiles ou mouvantes : si une route existe on la trouve. Si
le réseau est stable une fois les routes trouvées on minimise les chemins donc les
consommations.
Permet de faire de l'agrégation de données en choisissant une route qui passe par les nœuds
qui doivent compléter l'information. Ceci permet d'envoyer des requêtes complexes dont la
réponse doit être apportée par plusieurs nœuds. Par exemple les protocoles COUGAR ou
ACQUIRE (Active QUery forwarding In sensoR nEtworks) permettent, lors de la diffusion de
la requête, que les nœuds traversés apportent une partie de la réponse avant de diffuser la
requête. Dès que la totalité de la réponse est trouvée, cette réponse revient au demandeur.
Références :
COUGAR : Y. Yao and J. Gehrke, "The cougar approach to in-network query processing in
sensor networks", in SIGMOD Record, September 2002.
ACQUIRE : N. Sadagopan et al., "The ACQUIRE mechanism for efficient querying in sensor
networks", in the Proceedings of the First International Workshop on Sensor Network
Protocol and Applications, Anchorage, Alaska, May 2003.
• Inconvénient :
la topologie peut faire que certains nœuds servent de relais à beaucoup d'informations (ils sont
sur beaucoup de routes optimales) => ils épuisent leur énergie. On aurait pu choisir une
route différente (même un peu plus longue) pour certaines infos de façon à répartir la
charge.
136
Routage par rumeur
Référence : D. Braginsky and D. Estrin, "Rumor Routing Algorithm For Sensor Networks",
International Conference on Distributed Computing Systems (ICDCS'01), November 2001.
Part du principe que certains nœuds connaissent des événements que d'autres veulent
connaître : quelqu'un demande une info à quelqu'un d'autre mais sans savoir qui ni où il
est. Par rapport au protocole précédent celui-ci cherche à éviter la diffusion totale des
demandes.
Question : faut-il diffuser les événements ou les demandes ?
S'il y a beaucoup d'événements, en les diffusant on risque de diffuser des infos qui
n'intéressent personne. Mais s'il y a beaucoup de demandes il vaut mieux diffuser les
événements que les demandes.
Solution retenue : Le nœud origine d'un événement l'envoie à un des ses voisins au hasard
et chaque nœud qui les reçoit fait de même. Les événements se promènent ainsi sur le
réseau mais avec une durée de vie de type TTL (nombre de hops) ou durée réelle en
temps qui dépend de la taille du réseau et du nombre de nœuds. Chaque nœud qui reçoit
l'événement connaît le nœud d'origine de cet événement et le chemin qu'il a parcouru et
en garde trace.
On diffuse de la même façon les demandes. Quand une demande arrive sur un nœud on
regarde si l’on a, sur ce nœud, une trace de l'événement qu'elle demande. Si c'est le cas
on sait d'où vient l'événement et on a le chemin pour atteindre son nœud d'origine.
137
Routage par rumeur
Evénement
Demande
Remarque : Rien ne prouve que les 2 trajectoires (l'événement et la

demande) vont se croiser mais en pratique la probabilité est très forte.
On peut toujours prévoir, dans le cas où on n'aboutirait pas, à faire une
diffusion totale de la demande ou de l'événement.
138
Routage par rumeur
Améliorations possibles :
1. Quand un événement arrive sur un nœud au lieu de le retransmettre tel quel

on peut retransmettre cet événement ET tous ceux qui sont déjà passés sur
ce nœud => le nœud suivant reçoit N événements au lieu d'un seul et la
probabilité que les routes se croisent augment beaucoup. On peut d'ailleurs
faire la même chose pour les demandes.
Enfin on peut mixer ces 2 approches en disant que l'on retransmet
l'événement ou la demande accompagnée de TOUS les événements et
demandes connues sur ce nœud.
L'inconvénient de cette solution est que la taille des messages croît au fur et
à mesure qu'ils avancent.
139
Routage par rumeur
Améliorations possibles :
2. Référence : T. Haenselmann andW. Effelsberg. Forking agents in sensor networks. In
3. Deutscher Workshop über Mobile Ad-Hoc Netzwerke (WMAN 2005), Bonn,
Germany, September 2005.
Le nœud origine de l'événement ou de la demande émet un ou plusieurs forking

messages. Lorsqu'il arrive sur un nœud le forking message est transmis à un voisin
tandis qu'une copie sous forme de message normal est envoyée à un autre voisin =>
au démarrage on n'a plus qu'une seule trajectoire mais plusieurs qui partent. En fait il
est préférable que ce phénomène de duplication ne se produise pas au début de la
trajectoire mais après un certain nombre N de hops pour avoir plus de chances de
couvrir le réseau. On obtient de bons résultats en prenant pour N environ ¼ de ce qui
est pris pour le TTL càd quand la trajectoire déjà parcourue est à ¼ de sa longueur
maxi.
Problème possible : un message peut se perdre au cours de sa trajectoire. Pour détecter

ça on peut capter le message lorsqu'il est retransmis par le récepteur (A envoie à B qui
envoie à C comme A capte B il voit que B a retransmis le message donc qu'il l'a bien reçu
sinon il le lui ré-envoie). Mais en raison de l'utilisation de cycles veille/transmission il est
possible que A soit en veille lorsque B émet vers C. Une solution raisonnable est d'utiliser
un acquittement au moins pour les forking messages.
140
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
141
Protocoles de routage basés sur la
localisation
Most Forward Within Radius (MFR)
Référence : H Takagi, L Kleinrock : "Optimal Transmissions ranges for
Ramdomly Distributed Packet Radio Terminals", IEEE transaction on
communication, vol 32 n°3, pp 246-257, 1984
Principe : Chaque nœud connaît sa position et celle de ses voisins, il peut donc
calculer sa distance et celle de ses voisins à la destination. Il envoie l'info
à son voisin qui le rapproche le plus de la destination finale.
Le nœud S qui veut envoyer à D
choisira A car, sur l'axe SD, le nœud A
est celui dont la projection (A') est la
plus proche de D.
On considère l'axe SD comme l'axe
des x et on cherche le nœud dont la
coordonnée en x est la plus grande.
Cette méthode peut ne pas aboutir en
raison de minima locaux mais elle ne
crée pas de boucles. 142
localisation
Greedy
Référence : G. G. Finn, “Routing and addressing problems in large metropolitan-scale
internetworks,”Institute for Scientific Information, Tech. Rep. ISU/RR-87-180, March 1987.
C'est une variante de MFR qui donne en général sensiblement les mêmes résultats.
Principe : Chaque nœud connaît sa position et celle
de ses voisins, il peut donc calculer sa distance et
celle de ses voisins à la destination. Il envoie l'info à
son voisin qui est le plus proche de la destination
F’
finale. Ce n'est pas équivalent à MFR car le nœud le
plus proche de la destination n'est pas forcément celui
qui a la coordonnée la plus grande en x sur l'axe SD.
Sur la figure ci-contre le nœud placé en F' est plus près de D que A alors que sa
coordonnée en x est inférieure. Donc sur un tel exemple MFR choisirait A tandis
que greedy choisirait F'.
Comme MFR, cette méthode peut ne pas aboutir en raison de minima locaux mais elle
ne crée par de boucles
143
localisation
Compas (DIR)
Référence : E. Kranakis, H. Singh, and J. Urrutia, "Compass Routing on Geometric
Networks". Proceedings of 11th Canadian Conference on Computational Geometry,
CCCG-99, pages 51-54, Vancouver Aug. 15-18, 1999.
L'idée de départ est que chaque nœud S calcule l'angle dont il est le sommet qui est délimité
par un voisin V et la destination D. Il choisit le voisin pour lequel cet angle est minimal.
On peut montrer (voir exemple ci-dessous) que cette méthode peut tourner en rond.
Explication du cas ci-contre :
D ne voit pas les nœuds H et F, E et G ne se voient pas.
L'info arrive en E :
• E envoie à F car l'angle DEF est plus petit que DEH et E ne
connaît pas G
• F envoie à G car l'angle DFG est plus petit que DFE et que DFH
• G l'envoie à H car l'angle DGH est plus petit que DGF et que G
ne voit pas E
• H l'envoie à E car l'angle DHE est plus petit que DHG et que
DHF
Et on tourne en rond !
144
localisation
Synthèse des méthodes précédentes
Sur l'exemple ci-dessus où un message doit être transmis par le nœud S au nœud D :
• MFR choisira le nœud B (projection sur l'axe SD la plus proche de D)
• Greedy choisira le nœud A (c'est le plus proche de D : voir le cercle centré sur D)
• DIR choisira le nœud E (l'angle ESD est minimal).
145
localisation
Routage par faces
Référence : P. Bose, P. Morin, I. Stojmenovic, and J. Urrutia, “Routing with guaranteed
delivery in ad hoc wireless networks,” in International Workshop on Discrete
Algorithms and Methods for Mobile Computing and Communications (DIALM), 1999,
pp. 48–55.
Le principe est de découper le graphe constitué par les nœuds du réseau et leurs voisins en
faces puis de se déplacer de face en face vers l'objectif. Le graphe obtenu ne doit pas
avoir d'arêtes qui se coupent, on peut toujours se débrouiller pour y arriver. On peut
montrer que si on a des arrêtes qui se coupent l'algorithme peut tourner en rond.
Graphe initial Découpage en faces

146
localisation
Routage par faces
On veut aller du nœud S vers le nœud t.
Depuis S on trace une ligne droite en direction de t puis S envoie à son voisin direct sur
la face à laquelle il appartient. On tourne toujours dans le même sens sur les
faces. Ce nœud fera la même chose jusqu'à ce que le message arrive à un nœud
(X) dont l'arête qui le relie à son voisin coupe la droite St.
147
localisation
Routage par faces
On repart donc du nœud X. On recommence, depuis le nœud X ce que l'on
avait fait depuis S c’est à dire que l'on trace la ligne directe entre X et t et
que l'on fait circuler le message sur la nouvelle face jusqu'au nœud dont
le voisin est sur la ligne d'intersection (Y).
Y
X
148
localisation
Routage par faces
On arrive en Y et on continue jusqu'à arriver en t.
Y Y
X X
Z
Z
149
localisation
Routage par faces
Chemin parcouru
Y
X Z
s t
Le routage est totalement géré localement par chaque nœud.
On est sûr d'arriver mais le chemin n'est pas optimal (par exemple
il nous est arrivé de revenir en arrière).
150
localisation
Méthodes hybrides
Greedy Perimeter Stateless Routing (GPSR)

et
Adaptative Face Routing (AFR)
Utilisent greedy mais si greedy ne marche pas parce qu'on

arrive à un minima local, ils basculent sur le routage par
faces.
151
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
152
Routage multi chemin
Les méthodes présentées précédemment cherchent un seul chemin. On peut
améliorer les performances en utilisant plusieurs chemins. Le choix de l'un
des chemins possible peut être ensuite guidé par différentes raisons.
• Référence : J.-H. Chang and L. Tassiulas, "Maximum Lifetime Routing in

Wireless Sensor Networks", Proc. Advanced Telecommunications and
Information Distribution Research Program (ATIRP2000), College Park, MD,
Mar. 2000.
Dans cette méthode on choisit le chemin sur lequel se trouvent les nœuds
disposant de plus d'énergie. A chaque utilisation du chemin on calcule
l'énergie restante, lorsqu'elle devient inférieure à celle d'un autre
chemin disponible on change de route.
153
• Référence : C. Rahul, J. Rabaey, "Energy Aware Routing for Low Energy
Ad Hoc Sensor Networks", IEEE Wireless Communications and Networking
Conference (WCNC), vol.1, March 17-21, 2002, Orlando, FL, pp. 350-355.
Dans cette méthode on choisit le chemin en fonction d'un calcul

concernant la consommation d'énergie que provoque l'utilisation de ce
chemin. En effet dans le cas précédent on peut prendre un chemin où
l'énergie résiduelle est élevée mais dont l'utilisation la fait rapidement
chuter.
• Référence : S. Dulman, T. Nieberg, J. Wu, P. Havinga, "Trade-Off between

Traffic Overhead and Reliability in Multipath Routing for Wireless Sensor
Networks", WCNC Workshop, New Orleans, Louisiana, USA, March 2003.
Dans cette méthode on découpe le paquet à transmettre en autant de

morceaux que de chemins possibles et on envoie chaque morceau par
un chemin différent. On peut mettre en place un découpage tel que, s'il
manque un seul morceau, on puisse reconstituer le message original.
154
• Référence : K. Sohrabi, J. Pottie, "Protocols for self-organization of a
wireless sensor network", IEEE Personal Communications, Volume 7, Issue
5, pp 16-27, 2000.
Méthode basée sur la qualité de service : Sequential Assignment
Routing (SAR) choisit le chemin en fonction de 3 critères :
• Ressources en énergie
• Qualité de service sur chaque chemin
• Niveau de priorité du message
SAR utilise une somme pondéré de ces 3 critères pour faire le choix. Les
chemins possibles sont ré-évalués à intervalles réguliers pour la
mobilité. C'est très efficace mais lourd car il faut maintenir des tables de
routes et d'états sur chaque noeud
• Référence : T. He et al., "SPEED: A stateless protocol for real-time

communication in sensor networks", in the Proceedings of International
Conference on Distributed Computing Systems, Providence, RI, May 2003.
Méthode basée sur le temps réel : SPEED choisit le chemin en fonction du
délai de transmission entre nœuds voisins. Ce délai est mesuré par le
temps mis pour recevoir le ACK après envoi d'un message mais tient
aussi compte du taux d'erreurs de transmission entre voisins.
155
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
156
Découpage d'un réseau
L'idée de base est de créer des parties dans le réseau et de désigner
un nœud comme centre de chaque partie.
C'est surtout bien si on peut trouver dans chaque partie un nœud non
limité en énergie (poste fixe).
De plus ce nœud peut faire de l'agrégation de données.
Le routage entre ces nœuds centraux peut alors utiliser l'un des
algorithmes décrits précédemment.
157
LEACH (Low Energy Adaptative Clustering Hierarchy)
Référence : W. Heinzelman, A. Chandrakasan and H. Balakrishnan, "Energy-

Efficient Communication Protocol for Wireless Microsensor Networks,"
Proceedings of the 33rd Hawaii International Conference on System Sciences
(HICSS '00), January 2000.
LEACH est orienté vers un fonctionnement de type collecte de données du réseau

de capteurs vers un ou plusieurs points fixes.
Principe de base : des nœuds sont choisis au hasard pour être centre de parties
et ces rôles tournent à intervalles réguliers pour répartir la charge. Un nœud
centre a pour rôle de collecter l'info et de la transmettre vers un point fixe.
158
LEACH (Low Energy Adaptative Clustering Hierarchy)
On a 2 phases : une pour choisir les centres et une pour utiliser le réseau. La dernière a
une durée au bout de laquelle on refait la 1ère (cette durée est bien plus élevée que celle
de la 1ère sinon ça ne vaut pas le coup).
– Phase 1 : Chaque nœud tire un nombre au hasard, si ce nombre est inférieur à un seuil calculé
en tenant compte du pourcentage de centres par rapport au nombre total de nœuds et du
nombre de nœuds non sélectionnés lors des précédentes phases 1, le nœud devient centre
pour ce tour.
Chaque nœud centre diffuse un message pour indiquer qu'il est centre et chaque nœud non
centre choisit, en fonction des messages qu'il a reçus, à quel centre il se rattache en utilisant la
puissance du signal reçu. Puis il informe le centre qu'il a choisi du fait qu'il s'est rattaché à lui.
Enfin le centre indique aux nœuds qui lui sont rattachés quelle période de temps leur est assigné
(le média est partagé en temps).
– Phase 2 : Les nœuds envoient leurs données au nœud central auquel ils sont liés qui, si
nécessaire, fait de l'agrégation puis transmet.
– Après un certain délai on revient à la phase 1.
Commentaires :
– On suppose que les nœuds centraux peuvent communiquer avec ce point fixe. En fait leur rôle
est plutôt de faire de l'agrégation de données que du vrai routage.
– De plus on suppose que les données sont agrégées entre nœuds ayant le même nœud central
(ce qui n'est pas évident).
– Enfin le choix aléatoire de nœuds centraux ne garantit pas la couverture.
159
PEGASIS (Power Efficient Gathering in Sensor Information
Systems)
Référence : S. Lindsey, C. Raghavendra, "PEGASIS: Power-Efficient Gathering

in Sensor Information Systems", IEEE Aerospace Conference Proceedings,
2002, Vol. 3, 9-16 pp. 1125-1130.
C’est une amélioration de LEACH :

Elle permet de choisir des nœuds centraux qui ne sont pas directement
accessibles par tous les nœuds de la zone qu'ils contrôlent donc de faire
des zones plus grandes.
La route entre un nœud d'une partie et le nœud central de cette partie est
établie en n'utilisant que des communications avec le voisin le plus proche.
On le détermine par la puissance du signal reçu puis chaque nœud règle
son émetteur pour n'atteindre que ce voisin. On peut trouver ces routes par
une méthode de type greedy. Les nœuds centraux ont en charge de
transmettre l'info vers le point de collecte.
160
Geographic Adaptative Fidelity (GAF)
Référence : Y. Xu, J. Heidemann, D. Estrin, "Geography-informed Energy Conservation

for Ad-hoc Routing," In Proceedings of the Seventh Annual ACM/IEEE International
Conference on Mobile Computing and Networking 2001, pp. 70-84.
Le réseau est divisé en zones par un quadrillage virtuel. La règle de constitution

de ces zones est la suivante :
Pour 2 zones A et B adjacentes, tout nœud de A doit pouvoir communiquer avec

tout nœud de B. Si on considère que les nœuds ont une portée de R la taille du
quadrillage ainsi formé
R
est si on considère que chaque carré a 4 voisins
5
R
et si on considère que chaque carré a 8 voisins.
8
L'objectif est de maintenir le plus possible les nœuds non centraux en veille.
161
Geographic Adaptative Fidelity (GAF)
Les nœuds ont 3 états : en veille, découverte et actif
– Au départ un nœud est en mode découverte pour trouver ses voisins et déterminer la
zone à laquelle il appartient
– Lorsqu'il commence sa découverte il lance un timer pour un délai aléatoire Td, à la fin de
ce délai il émet un message en broadcast et passe en mode actif. Si pendant ce délai il
reçoit le message de découverte d'un autre, il arrête son timer et passe directement en
mode veille. Donc celui qui tire le plus court délai devient actif càd représentant de la zone.
Le rôle du nœud central est de recueillir les infos des nœuds de sa zone et de les
transmettre sur le réseau. On considère que le coût en énergie de communication avec ce
nœud central est le même pour tous les nœuds de la même zone.
– Quand un noeud rentre en mode actif, il lance un timer pour un délai Ta au bout duquel il
reviendra en mode découverte pour permettre à d'autre nœuds de prendre sa place de
représentant de la zone.
– Pendant qu'il est actif il réémet un message de découverte tous les Td.
– Si pendant qu'il est actif il reçoit un message de découverte il passe en veille puisqu'il y
a un autre représentant.
– Un nœud reste en veille pour un temps Ts au bout duquel il passe en mode découverte.
Pour gérer la mobilité chaque nœud estime combien de temps il va rester dans la zone et transmet
cette information à ses voisins dans le message de découverte. Les voisins programment alors un
réveil un peu avant cette date de façon à pouvoir prendre le relais de ce nœud.
162
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
163
Agrégation de données
Principe : regrouper les informations liées provenant de plusieurs

nœuds pour former une information complète. On parle aussi de
fusion de données.
Permet aussi d'enlever les données redondantes ou très corrélées.
Les points clés sont :

– Économiser l'énergie
– Augmenter la durée de vie du réseau de capteurs
– Obtenir des données fiables
– Réduire les délais de constitution des données agrégées
164
Agrégation basée sur
l'architecture du réseau
Réseaux à plat
Tous les nœuds jouent un rôle identique dans le réseau.

La méthode d'agrégation de données est très liée au protocole de
routage utilisé.
On peut alors distinguer deux modes d'agrégation de données :

• push
• pull
– Dans le premier ce sont les nœuds qui ont l'info qui initient sa
transmission.
– Dans le second ce sont les nœuds qui ont besoin de l'info qui en
demandent la transmission.
165
Réseaux à plat : Mode Push
Le protocole de routage SPIN (déjà vu) correspond à ce type de

fonctionnement. Il définit des méta données spécifiques à
l'application. Par exemple les capteurs d'une même zone
géographique utilisent le même ID dans la méta donnée.
Quand un nœud a une info il en avertit ses voisins par envoi de la méta
donnée (ADV). Le ou les voisins intéressés par ce type d'info lui
répondent (REQ) qu'ils veulent recevoir cette info. Et le nœud la leur
envoie (DATA).
De plus chaque nœud tient le compte de sa consommation d'énergie et
s'en sert pour décider d'envoyer ou pas des données. Ainsi
certaines tâches peuvent ne pas être faites si l'énergie est trop
faible.
L'inconvénient majeur de SPIN est qu'il ne garantit pas que l'info arrive.
166
Réseaux à plat : Mode Pull
Le protocole de routage par diffusion dirigée (déjà vu) peut permettre ce type de
fonctionnement.
Principe : le nœud demandeur diffuse (broadcast) sa demande dans laquelle il indique

quelle information il désire (nom). Chaque nœud qui la reçoit met à jour un "gradient"
qui indique de quel nœud voisin lui est parvenue la demande. Lorsque la demande
parviendra au ou aux nœuds sources, le demandeur recevra l'info demandée. Il
pourra, par la suite, renforcer certains chemins par lesquels lui sera transmise
l'information.
La demande contient, en plus du nom de l'info requise, des attributs liés à l'application
comme par exemple les coordonnées géographiques de la zone dans laquelle doit se
trouver la source, la périodicité d'envoi de l'info (toutes les 10ms), la date d'expiration
(ne plus envoyer périodiquement après cette date), etc.
Un nœud qui reçoit cette demande peut la diffuser à tous ses voisins ou seulement à
certains (en tenant compte de la localisation précisée dans la demande) ou pas du
tout s'il l'a déjà diffusée. De plus chaque nœud tient à jour une table de toutes les
demandes en cours.
167
• Les gradients sont mis à jour sur chaque nœud qui a reçu la demande (de qui ça lui
est venu) on peut aussi leur associer des infos de qualité, délai, erreurs de
transmission avec ce voisin.
• L'envoi de l'information sera fait par les nœuds détenant (soit parce qu'il l'ont
acquise, soit parce qu'il l'ont reçue) une information correspondant à lune des
demandes qui sont dans leurs tables. Ce ne sont pas forcément les nœuds source
de cette information, ce peuvent être des nœuds qui ont reçu cette info auparavant et
l'ont gardée en cache.
Pour savoir s'ils doivent envoyer les nœuds tiennent compte des paramètres de la
demande comme la périodicité. Ils utilisent les gradients liés à cette demande pour
faire passer l'info (en fait comme ces gradients ont été établis lors de la demande ils
constituent un chemin pour arriver au demandeur). Un nœud qui reçoit une telle
information la fera passer en utilisant ses gradients mais il vérifiera qu'il ne l'a pas
déjà fait (en tenant également compte de la périodicité) pour éviter les duplications
liées au système de diffusion de la demande (on a plusieurs chemins et, a priori, on
va les utiliser tous).
168
Le renforcement de chemins peut être mis en place par un demandeur qui constate
que l'info lui parvient plus vite par un chemin que par un autre. Les nœuds de ce
chemin seront informés de faire plutôt passer l'info par tel voisin que par tel autre. De
plus, lorsqu'il y a plusieurs sources d'info, le choix d'un chemin permettant
l'agrégation de données est intéressante.
Par exemple, dans le dessin ci-contre prendre les
Source
1 chemins :
a Source1 -> destination par a b c
N1
b Et Source 2 -> destination par f g:
N2
Est moins intéressant que de prendre
c Source1 -> destination par a b c
e deman
deur
Et Source 2 -> destination par e c
d
Sourc e
Car le nœud N2 peut faire l'agrégation des infos de
2 g source1 et de source2.
f
N3
Il en serait de même en prenant
Source1 -> destination par a d g
Et Source 2 -> destination par f g
Avec N3 qui fait l'agrégation
169
Réseaux hiérarchisés
Lorsque l'on découpe un réseau en sous parties (comme on a déjà vu), chaque
partie possède un nœud central qui peut faire l'agrégation de données pour
sa partie.
Ensuite il fait passer l'information au demandeur par un chemin qui peut

emprunter plusieurs autres nœuds centraux d'autres parties du réseau.
Des systèmes comme LEACH ou GAF permettent ce genre de chose surtout

lorsque l'on a des circulations périodiques de données (surveillance
écologique, etc.).
170
Réseaux hiérarchisés : Agrégation par clusters
Référence : S. Chatterjea and P.Havinga, “A Dynamic data aggregation

scheme for wireless sensor networks,” Proc. Program for Research
on Integrated Systems and Circuits, Veldhoven, The Netherlands,
Nov. 2003.
Clustered Diffusion with Dynamic Data Aggregation (CLUDDA)

utilise des messages de demande contenant les traitements à
effectuer lors de l'agrégation.
CLUDDA utilise la méthode de diffusion dirigée pour propager ces

demandes. Seuls les nœuds centraux de parties et ceux assurant le
routage entre parties reçoivent ces demandes. Ce sont eux qui
effectueront l'agrégation de données.
171
Réseaux hiérarchisés : Agrégation par chaîne
Référence : S. Lindsey, C. Raghavendra, and K.M. Sivalingam, “Data gathering

algorithms in sensor networks using energy metrics,” IEEE Trans. Parallel
and Distributed Systems, vol. 13, no. 9, September 2002, pp. 924-935.
Cette méthode est basée sur PEGASIS (vu précédemment) qui établit les liens
entre nœuds sur le principe de ne communiquer qu'avec le nœud le plus
proche (en utilisant la force du signal comme mesure).
On constitue alors des chaînes de nœuds qui aboutissent au nœud central

de la partie. Lorsque les données circulent sur cette chaîne chaque nœud
qui les transmet peut y agréger ses propres données.
A la fin, le nœud central terminera l'agrégation avant d'envoyer au

demandeur.
172
Réseaux hiérarchisés : Agrégation par arbre
Référence : M. Ding, X. Cheng and G. Xue, “Aggregation tree construction in sensor
networks,” 2003 IEEE 58th Vehicular Technology Conference, vol.4, no.4, October 2003,
pp 2168-2172.
Le principe est de constituer un arbre dont les feuilles sont les sources de l'information et la
racine le demandeur. A chaque nœud de l'arbre on peut faire de l'agrégation de données
au fur et à mesure que l'information remonte.
Le principe de constitution de l'arbre est le suivant :
– Le demandeur envoie un message à ses voisins.
– Tout nœud qui reçoit un tel message pour la 1ère fois lance un timer. Pendant la durée de ce timer
il reçoit d'autres messages de ce type d'autres voisins. Ces messages contiennent le nombre de
hops depuis le demandeur et l'énergie disponible sur le nœud qui a envoyé ce message. Quand
le délai est terminé, il choisit son père dans l'arbre parmi tous ceux qui lui ont envoyé ce message
et le lui signale. Ce choix se fait sur le nombre de hops et l'énergie de l'émetteur.
– Enfin il diffuse à son tour à ces voisins un message du même type en augmentant de 1 le nombre
de hops et en indiquant sa propre énergie.
– Chaque nœud sait alors s'il est nœud ou feuille de l'arbre en fonction du fait que, lorsqu'il a
diffusé son message, il a reçu des réponses de nœuds l'ayant choisi comme père ou pas.
– Le processus continue et se termine naturellement lorsque tous les nœuds ont été atteints.
173
Agrégation basée sur les flux dans
le réseau
Principe :
On part d'une vision du réseau sous forme de graphe. Chaque nœud

est un nœud du réseau, chaque arc est une liaison directe possible.
• On value chaque arc par la quantité d'énergie consommée pour un
paquet qui passe par cet arc.
• On cherche ensuite l'arbre permettant de transmettre les infos en en
faisant l'agrégation qui consomme le moins d'énergie.
Ce problème est en général NP complet => il faut trouver des
heuristiques.
Ce type de solution suppose d'avoir une vision complète du réseau au

moins en terme de connexions directes.
174
Agrégation basée sur la qualité de
service
Dans ce cas on s'intéresse plus à la qualité de service qu'à l'énergie. C'est-à-
dire soit :
– Trouver le modèle d'agrégation qui collecte le plus de données pertinentes
– Trouver le modèle d'agrégation qui limite la congestion du réseau
Dans le 1er cas on part du % d'info que chaque nœud apporte à l'info finale. On
pondère chaque transmission par l'énergie consommée. L'objectif est de
trouver une route qui collecte le plus fort % et consomme le moins
d'énergie. En fait on utilise un système de bonus pour le % et malus pour
l'énergie et on cherche la route qui obtient le meilleur résultat en cumulant
les bonus/malus.
Dans le second cas on utilise l'agrégation plutôt comme outil d'optimisation que
pour constituer des infos complètes. En fait on agrège des infos lorsqu'elles
passent par la même liaison (du nœud A vers le nœud B) ceci permet de
regrouper plusieurs paquets et de les compresser pour gagner du temps et
de l'énergie. Mais les paquets regroupés n'ont aucun lien entre eux sinon
qu'ils passent au même endroit. C'est surtout bien si on a beaucoup de
transmissions de paquets plutôt petits.
175
Plan du cours
• TinyOS
• Squawk
– Applications
• nesC (TinyOS)
– Sécurité
176
Sécurité : faiblesses
Faiblesses des réseaux de capteurs
– Ressources limitées (mémoire, batterie)
– Qualité de communication
• erreurs, pertes fréquentes
• conflits d’accès au médium
• délais importants (multi hop)
– Exposition aux attaques
• réseau ouvert facilement accessible
• pilotage à distance des capteurs (téléchargement de code)
• pas de point de contrôle central
177
Sécurité : besoins
Besoins en sécurité :
– Confidentialité des données
– Intégrité des données
– Datation des données (savoir si elles sont récentes)
– Authentification des données
Les solutions doivent :

– être viables (puissance et temps de calcul compatibles avec les
capteurs)
– permettre l’auto-organisation du réseau
– permettre la synchronisation des nœuds (temps de veille)
– permettre l’auto-localisation des noeuds
178
Sécurité : Attaques
Méthodes d’attaques
– Déni de service (brouillage de signal, violation
de protocole, perturbation du routage)
– Camouflage : un nœud prend plusieurs
identités ou usurpe celle d’un nœud existant
– Trafic : identifier les nœuds servant de relais
et les saturer
– Introduction de code sur les capteurs
179
Problèmes de sécurité
Un réseau de capteurs est facilement attaquable car tout est diffusé par radio :
Il suffit d’introduire des nœuds parasites.
Les principales attaques possible sont :

1. Capture d’informations
2. Envoi d’informations fausses
3. Brouillage des communications
4. Épuisement des batteries des capteurs en les tenant en éveil par des messages
inutiles
Remarque : L'agrégation aggrave le problème de la sécurité puisque des infos

plus complètes circulent et qu'un nœud espion verra donc passer beaucoup
plus de choses que si on ne faisait pas d'agrégation.
On peut utiliser des méthodes de cryptage.

– Résout bien les cas 1 et 2 mais pas le 3 ni totalement le 4
– Induit du temps de calcul sur les capteurs qui devient vite rédhibitoire si les clés
utilisées sont longues.
– Rend difficile l’agrégation des données qui doit se faire sans les décoder
puisque seul le destinataire final sait décoder.
180
Méthodes de cryptage :
1. Avec clé secrète

Algorithme
Message Algorithme Message de Message
A de chiffrage Décodage B
Chiffré
Clé Clé
Les algorithmes ne sont pas secrets, seules les clés le sont
2. Avec clés privée/publiques
Algorithme
Message Message Message
A Algorithme de
B
de chiffrage Décodage
Chiffré
Clé publique de B Clé privée de B
B choisit une clé privée avec laquelle il peut décoder et que lui seul connaît.
B calcule, à partir de cette clé privée, une clé publique qu’il donne à A (calcul simple)
A ne connaît que la clé publique de B, il l’utilise pour chiffrer ses messages à destination de B.
Le calcul clé publique -> clé privée est impossible.
181
Sécurité : cryptage
Méthodes défensives par cryptage :
• Le cryptage par clés publiques pose le problème de la distribution des clés publiques.
• distribution avant déploiement
• utilisation d’un tiers sûr pour distribuer les clés (certificats)
• Le cryptage par clés secrètes peut utiliser l’algorithme de Diffie-Hellman pour échanger les
clés secrètes :
A B
1) A choisit un nombre premier p et un
nombre g<p p , g , TA
TA= g a mod p
2) A prend un nombre aléatoire a et
envoie à B les valeurs p, g et TB
TA = ga mod p
T B= g b mod p
3) B prend un nombre aléatoire b et
envoie à A la valeur TB = gb mod p
4) B calcule KB = TAb mod p KA= T Ba mod p K B= TAb mod p
5) A calcule KA = TBa mod p
KA = TBa mod p = (gb mod p)a mod p = gab mod p car g mod p = g puisque g<p
KB = TAb mod p = (ga mod p)b mod p = gba mod p
donc KA= KB c’est la clé secrète K partagée par A et B
Quelqu’un qui lit sur le réseau p, g, TA et TB
ne peut pas calculer K car il ne connaît ni a ni b
182
Sécurité : routage
Méthodes défensives concernant le routage :
• Un mode de routage qui évite les chemins trop
consommateurs d’énergie permet de limiter les
dénis de service
• Un routage multichemins avec redondance peut
permettre de recevoir les messages malgré les
attaques
• Un mode de routage qui change souvent de
chemin peut limiter les dégâts
183
Conclusion
• Domaine de recherche et développement très actif
– Surtout sur les problèmes de réseau
– Moins sur ceux des applications (pour l’instant)
• L’équipe Alcool (Architectures Logicielles Composants et protocoles) du

LIUPPA travaille sur les applications mêlant capteurs et machines
classiques :
– Plate-forme de déploiement et reconfiguration automatique
– La reconfiguration ajoute/supprime/déplace des composants pour :
• minimiser la consommation d’énergie
• gérer la mobilité
• s’adapter aux besoins
– La plate-forme gère le routage en fonction de l’application
– Partenariat avec Sun Microsystems (capteurs SunSpot)
– Contrats ANR, Conseil Régional, Conseil Général, entreprises
Les personnes intéressées peuvent prendre contact avec cette équipe (à l’IUT
de Montaury, département informatique : P Roose ou moi même).
184

CoursReseauxdecapteurs 2 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CoursReseauxdecapteurs 2 PDF

Загружено:

Авторское право:

Доступные форматы

Réseaux de capteurs

MICA 2 MICA2 DOT

Quelques composants (processeurs, radio) :

Zigbee 250 KB/s faible Court

Bluetooth 1 MB/s moyenne Moyen

802.11 11 - 54 Mb/s élevée Long

Émetteur / récepteur sans fil

Connecteur pour carte

Il s'agit de processeurs à faible consommation donc à vitesse d'horloge

Certains comme l'ATMEGA 128 sont plutôt des microcontrôleurs.

Le jeu d'instruction est constitué de 2 jeux : les instructions ARM 32

R14 contient l'adresse de retour.

Les registres R13, R14 et SPSR sont changés (banque de registres)

Dans le cas de l'interruption rapide (FIQ) les registres R8 à R12 sont

• En mode utilisateur les modifications du registre d'état sont limitées

• En mode système on peut modifier la totalité du registre d'état

On quitte le mode utilisateur lors d'une exception et on y retourne à la fin.

Les exceptions logicielles peuvent permettre de passer du mode

Quand on est en mode système on revient au mode utilisateur en

Toutes les instructions peuvent être conditionnées suivant les

• Pour utiliser une instruction conditionnelle on ajoute les 2 lettres

• Puis on ajoute les extensions du COP s'il y en a (par exemple taille

• Les indicateurs sont positionnés par les instructions de comparaison

• Par exemple : LDREQBS est le code de l'instruction "load" (LDR)

Exemple de calcul pour une utilisation :

A ce régime, avec sa batterie de 2300mAh, il pourra

Sur 1 seconde on aurait :

A ce régime, avec sa batterie de 2300mAh, il pourra

Deux approches sont utilisées :

TinyOS et nesC sont liés : les applications pour TinyOS

• Une application complète est un composant contenant plusieurs modules

• Une interface déclare un ensemble de fonctions

• Toutes ces fonctions doivent être implémentées.

– Les modules contiennent le code et implémentent une ou

– Les configurations servent à assembler les composants entre

– L’application est elle-même un composant n’offrant aucune

• L'ensemble des configurations permet de savoir quels composants

Les tâches s'exécutent l'une après l'autre sans préemption.

Les pilotes d'IT sont exécutés en réponse à une IT mais

• Les traitements d'événements sont, par nature, de courte durée.

Traditionnellement on les résout par l'utilisation de sémaphores.

nesC utilise des parties de code atomiques (mot clé atomic).

Le compilateur nesC détecte les problèmes de concurrence et les

Une tâche est déclarée par : task void nomdetache() { ... }

Toute la boucle ci-dessus est exécutée sans

• Squawk offre aussi un mécanisme de migration des Isolates qui permet de

//Ouvrir un flux sur la radio

RadiogramConnection connecteurBroadcast = (RadiogramConnection)

On fera de même pour un composant logiciel. Les signaux en entrée

Il faut savoir quelles pattes d'un composant relier à quelles autres.

Les différences essentielles entre un assemblage de composants

Le fichier de configuration Clignote.nc :

Main.StdControl -> ClignoteM.StdControl;

Au début on a un bloc configuration qui ici est vide puisqu'il s'agit

Ensuite vient le bloc implementation qui indique les composants

command result_t init(); implementation {

command result_t start();

Ces commandes sont utilisées par le système pour initialiser, lancer et

Main.StdControl -> ClignoteM.StdControl;

La ligne : Main.StdControl -> ClignoteM.StdControl;

La flèche doit être comprise comme suit : le composant à gauche utilise

La ligne ClignoteM.Timer -> SingleTimer.Timer;

De même la ligne : ClignoteM.Leds -> LedsC;