Vous êtes sur la page 1sur 221

Réseaux de capteurs

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 réparties

Objectif : qualité et continuité de service, adaptation au contexte

Moyens : ajout/suppression/migration de composants logiciels

2
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Les dispositifs
• Capteurs sans fils

• Drones
• RFID
• Smartphones

• Objets connectés

3
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Domaines d’utilisation
• Surveillance / contrôle d’espace
– Environnement et habitat
– Agriculture
– Climat
– Surveillance militaire
– Alarmes Intelligentes
• Surveillance / contrôle d’objets
– Eco physiologie
– Maintenance
– Médical
• Surveillance / contrôle d’interactions entre objets et espace
– Vie sauvage
– Surveillance de catastrophes
– Processus de production

4
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Types d’applications (1)
• Capteurs en collecte de données
– Les capteurs collectent des mesures
– Ils les envoient à un serveur (directement ou pas)
– Le serveur les traite

Lien indirect

Lien direct

5
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Types d’applications (2)
• Capteurs en collecte de données + traitement
– Les capteurs collectent des mesures
– Ils les traitent
– Ils n’envoient au serveur que des données synthétiques ou
pertinentes

capture
envoi

traitement

6
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Types d’applications (3)
• Capteurs en collecte de données + traitement local
– Les capteurs collectent des mesures
– Ils les échangent avec les capteurs proches
– Ils n’envoient au serveur que des données synthétiques

Traitement local

7
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Types d’applications (4)
• Capteurs autonomes
– Les capteurs collectent des mesures
– Ils les échangent avec les capteurs proches
– Ils prennent les décisions eux-mêmes

Traitement local

8
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple
• Chauffage électrique (gestion classique)
– Chaque radiateur est doté :
• D’un capteur de température
• D’un actionneur permettant de régler la puissance du radiateur
• D’un processeur (microcontrôleur)
• D’une radio

– Une centrale permet de piloter les radiateurs par radio :


• Les régler à une température donnée
• Les éteindre
• Les mettre en mode hors gel

9
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple
• Chauffage électrique (gestion évoluée)
– Comme les radiateurs ont un processeur, ils peuvent :
• Mesurer la consommation sur les dernières 24h, la semaine, le mois
… Et transmettre tout ça à la station centrale  affichage
• Changer la réglage de température en fonction du jour et de l’heure
• Etc.

– Comme ils peuvent communiquer entre eux, ils peuvent :


• Comparer leur température avec ceux de la même pièce, du même
étage … et l’ajuster
• Comparer leur consommation avec ceux de la même pièce, du même
étage … et l’ajuster
• Se synchroniser avec les autres pour faire les réglages de
température en fonction du jour et de l’heure
• Etc.

10
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple
• Chauffage électrique (gestion intégrée)
– Si on a une alarme avec des capteurs d’ouverture aux fenêtres et des
capteurs de présence, les radiateurs peuvent communiquer avec ces
capteurs et avec la centrale d’alarme pour :
• Couper le chauffage si une fenêtre de la pièce est ouverte
• Baisser le chauffage quand l’alarme est mise en marche
• Monter le chauffage quand une présence est détectée et l’alarme coupée

– Si cette alarme peut communiquer en 3G :


• Elle peut être pilotée par une application sur smartphone
• Le chauffage sera également piloté par cette application

• Conclusion :
– D’une utilisation classique de type commande centralisée on peut évoluer
à moindre coût vers une maison intelligente en :
• Utilisant les processeurs des capteurs
• Mettant les capteurs en réseau

11
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Quelques domaines d’application
• 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
(Californie – Arizona)
• Environnement
– PODS (université de Hawai) surveillance de plantes menacées
– Corie : surveillance de pollution sur l’estuaire de la rivière Columbia
– AirParif
• Santé
– Surveillance de patients (glucose, température , ….)
– SSIM (Smart Sensors and Integrated Microsystems) : rétine artificielle (100 micro-capteurs)
• Distribution d’énergie
• Alarming (catastrophes)
• Militaire
– ExScal : surface de 1.3km sur 300m contrôlée par 1000 capteurs pour détection d’intrusion
• Domotique (internet of the things)
• Villes intelligentes

• Autres domaines à trouver …

12
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple : Santé
• CPU à ultra faible consommation
• Communication par induction (portée
extrêmement faible : 2m)
• Bande passante limitée (400Kb/s)

• Remarque : les systèmes actuels


n’ont aucun système de sécurité
informatique ! Mais :
• Courte portée => il faut être très
près
• Coût en énergie de la sécurité

13
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple : Contrôle de structures
(alarming)

• Golden Gate
Bridge
Batterie

Nœud de mesure de déformation WSN-3214


Capteur
National Instrument
Antenne

14
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple : Contrôle de l’environnement
(Great Duck Island )
• But: surveillance de l’environnement des oiseaux marins
• 32 capteurs déployés en 27 points de l’île : température,
pression, humidité, lumière
• 1 dispositif central
• Données accessibles à partir d’Internet par lien satellitaire

15
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protection de plantes (Pods)
Objectif :
– Protection de variétés de plantes en danger à Hawaï (silènes).
– Le climat d’Hawaï 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

16
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Forêt
Silènes

Observatoire des
volcans d’Hawaii

Zone d’étude

Désert
17
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Les capteurs sont placés dans des
faux rochers …
lumière

vent
température
CPU +
humidité Radio

Batteries

18
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
… ou des fausses branches
lumière

CPU +
Radio

température

19
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Puis disséminés dans la zone
d’étude

20
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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

21
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Villes connectées (smartcities)

• Santander (« Pulsa de la ciudad » )


– 2000 capteurs (trafic, pollution ,bruit, stationnement, irrigation,
collecte des déchets, …)
– 20 000 objets communicants (fixes et mobiles dont smartphones)
– Réalité augmentée
22
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le crowdsourcing
(« The Rise of Crowdsourcing », Jeff Howe, Wired N° 14.06 juin 2006)

Principe : Demander à des volontaires de participer à une collecte (via


les capteurs des smartphones ou d’autres dispositifs) ou à des
traitements (informatiques ou non) d’informations.

• Domaines :
– Sciences
– Démocratie participative
– …

• Modèle économique :
– Volontariat
– Cadeaux
– Partage de rémunération
– Rémunération selon les résultats
– Mise en concurrence
23
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Quelques exemples d’applications
• Mojave Desert Turtoise (MDEP)
Permet aux chercheurs du Mojave Desert Ecosystem Program (MDEP) et aux amateurs de
rassembler des informations pour préserver les tortues du désert situé entre la Californie,
le Nevada, l’Utah et l’Arizona. Lorsqu’un visiteur aperçoit une tortue, il lui suffit de
prendre une photo qui est automatiquement géolocalisée. Lorsque la connexion
redevient possible, la photo est transmise pour alimenter une base de données qui
permet de suivre les mouvements et de mieux connaître les habitudes de ces espèces.

• OakMapper (université de Berkeley)


Permet aux randonneurs de signaler les chênes de Californie atteints de la maladie appelée
«la mort subite du chêne».

• WeatherSignal (OpenSignal)
Permet de recueillir les données issues des capteurs de température présents dans les
smartphones pour dresser une cartographie hyperlocale de la température

• Santander (Pulsa de la ciudad)


Les usagers signalent des incidents, mesurent du bruit, des températures, …
Ils bénéficient des services associés : trafic, stationnement, réalité augmenté, guides …

24
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Drones

Expertise visuelle
Agriculture
Chantiers

Carrières Audit énergétique


Urbanisme

25
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
L’Internet des objets
• Proposer des objets courants connectés
consultables et pilotables par un PC, un smartphone

26
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
L’Internet des objets

27
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Questions
• Ecologie (recyclage, énergie)
• Sécurité (fiabilité, attaques, qui contrôle ?)
• Vie privée, anonymat
• Quantité de données (« Les datacenters utiliseraient près
de 30 milliards de watts d'électricité, soit l'équivalent de la puissance
de 30 centrales nucléaires » New York Times )

• Economie (« passage du coût d’un bien au coût d’usage »


Philippe GAUTIER directeur de Business2Any )

• Utilité
28
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

30
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

31
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Architecture générale
Un capteur est essentiellement composé de :
– Unités de capture et actionneurs
– Processeur et mémoire
– Émetteur/récepteur
– Alimentation

capteurs communication
processeur
physiques

actionneurs
physiques gestion de l'alimentation sécurité

32
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Composants d’un capteur
• Processeur : microcontrôleur faible consommation.
• Mémoire : RAM + Flash (pour programme embarqué et stockage)

• Connecteurs : USB, série, cartes d'extension


• Périphs : timers, lignes d'E/S, PWM, CA/N, DMA
horloge chien de garde, …
Possibilité de mise en veille pour consommation

• Capteurs :
– Intégrés
– Externes
• Actionneurs :
– 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, vibration, vent …
Remarque : le nombre de cycles de charge / décharge est limité.
33
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Capteurs
• Principes
– Transforme une grandeur physique en :
• Une grandeur électrique : tension ou courant
ou
• Un temps : durée ou fréquence
– La transmet sous forme numérique (binaire) ou analogique (tension)

• Moyens :
– Mécanique (contact, résistance ou capacité variable)
– Piézoélectrique (tension induite par déformation d’un cristal)
– Effet Hall (tension induite par un champ magnétique)
– Capacitif (tactile ou chimique)
– Rayonnement (radio, infrarouge, laser)
– Ultra sons (puissance, temps de propagation)
– Lumière (phototransistor ou photorésistance)
– Chimique (électrodes)

34
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
• Déplacement
Types de capteurs
– Interrupteur, potentiomètre, joystick (contact ou résistance mécanique)
– Tactile (contact ou décharge capacitive par contact)
– Pression, Force, Flexion (résistance variable ou effet piézoélectrique)
• Présence
– Passage, mouvement, vibration (laser, IR ou radar)
– Proximité, distance (laser, IR ou ultra sons par mesure de temps)
• Position
– Roue codeuse (contact)
– GPS (réception de satellites)
– Accélération (capacitif mécanique ou effet piézoélectrique)
– Inclinaison (capacitif mécanique)
• Rayonnement
– Magnétisme (effet Hall)
– Ondes (radio, IR)
– Lumière, couleur et UV (phototransistor, photorésistance)
• Environnement
– Température (résistance variable)
– Humidité (capacitif chimique)
– Anémomètre (mécanique + magnétique)
– Caméra (phototransistors)
– Son, US (capacitif mécanique ou effet piézoélectrique)
– Chimique (électrodes pour gaz ou liquides)
35
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Communication
Par radio : Zigbee (IEEE 802.15.4) , Bluetooth
(IEEE 802.15.1) , WI-FI (IEEE 802.11) , 3G
Technologie Vitesse Consommation Temps de
max démarrage

Zigbee 250 KB/s faible Court

Bluetooth 1 MB/s moyenne Moyen

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

36
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Anatomie d'un capteur

Carte à microcontrôleur

+ Capteurs

+ Emetteur récepteur radio (zigbee)

39
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Anatomie d'un smartphone
• Les smartphones peuvent être utilisés comme capteurs :
– Lumière
– Température
– Champ magnétique
– Accélération
– Gyroscope
– GPS
– Microphone
– Caméra
• Processeurs type Cortex (ARM) 1 à 8 cœurs.
• Connectivité élevée (Bluetooth, wifi, GSM) mais :
– connexion en GSM à sens unique, bluetooth portée faible
– Consommation élevée
• Mais peu autonomes (écran, wifi, GSM)

40
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

41
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Les processeurs
On trouve divers types de microcontrôleurs, les plus utilisés sont les Cortex.
Intel PXA, ATMEL, ST Microelectronics, Microchip, …

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


de type RISC.

42
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Les processeurs (ARM)
Les processeurs ARM sont des RISC 32 bits ou 64 bits
• CORTEX A (architecture ARMv8)
– Smartphones, tablettes
– Multiprocesseurs (1 à 8 processeurs)
– 300 MHz à 2,8 GHz.

• CORTEX R (architecture ARMv7)


– Automobile, modems, …
– Orienté temps réel
– 200 MHz à 1 GHz.

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


et les instructions Thumb 16 bits pour la compatibilité avec les StrongARM.

44
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Les Microcontrôleurs (ARM)
• Cortex M0 et M0+ (architecture ARMv6)
– Faible consommation
– Horloge : 48 MHz
– RAM : 4 à 32 Ko, Flash : 32 à 256 Ko

• Cortex M3 (architecture ARMv7)


– Usage général
– Horloge : 20 à 120 MHz
– RAM : 4 à 128 Ko, Flash : 8 à 1024 Ko

• Cortex M4 (architecture ARMv7E)


– Evolution des M3
– Horloge : 48 à 120 MHz
– RAM : 64 à 384 Ko, Flash : 512 à 2048 Ko

• Cortex M7 (architecture ARMv7E)


– Hautes performances
– Horloge : 300 MHz
– RAM : 256 à 384 Ko, Flash : 512 à 2048 Ko
45
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

51
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le problème de l’énergie
• La consommation d’un processeur dépend de sa vitesse
d’horloge
– Les CPU classiques fonctionnent entre 1 et 3 GHz (consommation
entre 10 et 100 W)
– Les microcontrôleurs fonctionnent entre 16 et 300 MHz
(consommation entre 50 et 300 mW)

• Les microcontrôleurs ont un mode veille :


– Arrêt des contrôleurs de périphériques
– Mise en basse consommation du CPU

• Les capteurs sans fils sont généralement construits autour


de microcontrôleurs
54
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le problème de l’énergie (exemple)
• Consommation de la carte à microcontrôleur :
– Processeur faisant des calculs : 15 mA
– Processeur en attente : 7 mA
– Processeur en veille : 200 μA

• Consommation de l’émetteur Zigbee :


– En réception : 50 mA
– En émission (puissance 10 mW) : 210 mA
– En veille : 10 μA

• Comparaison avec un smartphone :


– Processeur actif : 120 mA
– Processeur en veille : 6 mA
– En réception ou émission (wifi ou 3G) : +300 mA
55
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le problème de l'énergie (exemple)
Rappel consommations :
Actif : 15 mA, en attente : 7 mA, en veille : 200 μA
En émission : +50 mA , en réception : +210 mA
Batterie de type smartphone : 3 Ah

Utilisation du capteur :
– Le capteur envoie chaque 10 secondes le résultat d'un calcul fait à
partir de mesures (50 octets) mais sert aussi de relai sur le réseau.
• Le calcul dure 2 ms,
• A la fin de ce calcul il envoie les 50 octets à 250 Kb/s et doit en
relayer 250 vers d'autres nœuds.

56
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le problème de l'énergie (exemple)
Il doit rester à l'écoute du réseau en permanence pour pouvoir
accomplir sa fonction de relai.
Sur 10 secondes on a :
– Calcul et écoute : 2 ms à 15+50 mA
– Réception : 250*8/250000 s = 8 ms à 7+50 mA
– Emission : (250+50)*8/250000 s = 9,6 ms à 7+210 mA
– Le reste du temps (9980,4 ms) il est en attente et écoute à 7+50 mA
Consommation moyenne : 57,15 mA

A ce régime, avec sa batterie de 3 Ah, il pourra fonctionner


pendant 3000/57,15 = 52 heures (un peu plus de 2 jours).

57
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le problème de l'énergie (exemple)
S'il n'écoutait pas le réseau tout le temps mais passait en mode veille
quand il est inactif :

Sur 10 secondes on aurait :


– Calcul : 2 ms à 15 mA
– Réception : 250*8/250000 s = 8 ms à 57 mA
– Emission : (250+50)*8/250000 s = 9,6 ms à 217 mA
– Le reste du temps (9980,4 ms) processeur et Zigbee en veille à 200+10 μA
Consommation moyenne : 0,446 mA

A ce régime, avec sa batterie de 3 Ah, il pourra fonctionner pendant


3000/0,446 = 6431 heures (environ 9 mois).

Remarque : le même type de calcul avec un smartphone en 3G donnerait


une autonomie de moins de 2 jours (écran éteint).

58
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

59
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

Trois approches sont utilisées :


– Pas de SE (tout est contenu dans le programme et les bibliothèques incluses)
– Un SE réduit (par exemple Squawk est une MV java très allégée qui joue le rôle de SE)
– Un SE modulaire dont on ne charge que les parties utiles (TinyOS)

Dans le deuxième 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 dispositifs qui ont 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 (Android = Linux réduit + MVJ + API).
Dans le dernier 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 ou pas.
Il faut un langage de programmation permettant de le faire 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.

60
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

62
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

63
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

64
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

65
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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();

}
66
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Liaisons
Un composant en nesC est constitué de modules et d'une
configuration.

– Les modules contiennent le code et utilisent 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.

67
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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;
}
}

68
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 du 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.

69
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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. Cette


approche est classique en temps réel où tout doit être faisable dans
un temps donné.

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 (priorités). 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.

70
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

71
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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) ne pouvant pas être
interrompues.

Le compilateur nesC détecte les éventuels 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.

En conclusion : nesC suppose que le programmeur sait écrire des programmes


corrects …

72
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Tâches
Rappel : 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 d’une tâche peut se trouver dans n'importe quelle partie
du code (commande ou événement) du composant.
73
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

C’est l’implémentation la plus simple de la gestion de la concurrence


qui est normalement bannie dans les SE pour éviter les blocages

74
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

75
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 (garbage collector).

• 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.

76
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
77
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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

78
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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();

79
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple d'utilisation de
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();

80
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Exemple d'utilisation de
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);

81
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Android
• Système Linux allégé + machine virtuelle java + couche Android + API

• Initialement destiné aux smartphones et tablettes mais de plus en plus


utilisé sur d’autres dispositifs embarqués (objets connectés, boxes,
automobile, …)

• Bibliothèques pour :
– Capteurs
– Communications par réseau (GSM, wifi, bluetooth)

• Les applications sont des activités qui s’exécutent en temps partagé. Elles
peuvent lancer des threads java qui s’exécutent en temps partagé mais
dont on peut définir la priorité.

• Remarques :
– Android peut arrêter une activité par manque de ressources
– Android est très centré interface (activité visible, en arrière plan) mais peut gérer
des activités sans interface (services)

82
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Architecture d’Android

83
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Architecture d’Android
Un noyau linux
• Gestion de la mémoire
• Gestion des processus
• Gestion du matériel (écran clavier …)
• Gestion des capteurs (appareil photo, GPS, accéléromètre …)
•…

84
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Architecture d’Android
Des bibliothèques (C et C++) – pas obligatoires
• Graphisme
• Médias
• Web
•…

85
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Architecture d’Android

Une machine virtuelle java


• Dalvik (une JVM par application)
• Code spécifique Android

86
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Architecture d’Android

Des gestionnaires pour les applications + une API en java


• Gestion des fenêtres, des activités, des ressources …

• API pour développement des programmes

87
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Architecture d’Android

Les applications
(Activités)

88
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Android : accès aux capteurs
• Classe SensorManager dont une instance est obtenue par :
SensorManager gestionnaireCapteurs =
(SensorManager)getSystemService(Context.SENSOR_SERVICE);

• Récupération d’un capteur par :


Sensor monCapteur = gestionnaireCapteurs.getDefaultSensor(type_de_capteur);

Avec type_de_capteur :
– Sensor.TYPE_ACCELEROMETER 3 valeurs en m/s²
– Sensor.TYPE_GRAVITY 3 valeurs en m/s²
– Sensor.TYPE_GYROSCOPE 3 valeurs en radiant/s
– Sensor.TYPE_LIGHT 1 valeur en lux
– Sensor.TYPE_MAGNETIC_FIELD 3 valeurs en tesla
– Sensor.TYPE_ORIENTATION 3 valeurs en °
– Sensor.TYPE_PRESSURE 1 valeur en psi (1 psi  6894,76 Pa)
– Sensor.TYPE_PROXIMITY 1 valeur en cm
– Sensor.TYPE_TEMPERATURE 1 valeur en °Celcius

89
M. Dalmau - IUT de Bayonne : Réseaux de capteurs

Android : Photo
La classe Camera permet la prise de photo par takePicture en associant un écouteur
d’événement pour récupérer la photo en raw ou JPEG. La méthode onPictureTaken
de cet écouteur est appelé quand la photo est faite, l’image est reçue en tableau
d’octets.

• On peut enregistrer le tableau d’octets reçu par onPictureTaken dans un fichier ou


utiliser BitmapFactory pour le convertir en image

Android : Géolocalisation par GPS


1. Acces au GPS par : getSystemService(Context.LOCATION_SERVICE)
2. Associer un écouteur d’événements par : requestLocationUpdate en
précisant :
– Le mode (GPS ou réseau)
– Le rythme
– La distance minimale
3. Récupérer les informations dans un objet de classe Location
– Latitude, longitude, altitude
– Précision
4. Possibilité de calculer une distance
90
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Android : Communication
• En wifi et GSM
– Socket et ServerSocket pour TCP
– DatagramSocket pour UDP
– Client HTTP pour URL

• En bluetooth
– Bibliothèque pour :
• Découvrir les autres périphériques
• Appairer les périphériques (code de sécurité)
• Etablir des canaux de communication
• Se connecter par découverte de services
• Transférer des données
• Gérer des connexions multiples

91
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

92
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Taille des applications
• Complexité des applications (de plus en plus car le temps de calcul est faible
par rapport aux temps réseau et aux temps des systèmes physique).

• Fiabilité des applications (reprises d’erreurs, redondance, algorithmes


alternatifs). Les microcontrôleurs sont prévus pour la reprise d’erreur (chien
de garde + sauvegarde de registres)

• Solutions
– Minimiser (TinyOS)
– Déporter les traitements (Android)
• Type services web
•  Transport des données
– Télécharger les traitements à la demande
• Pratiquement jamais utilisé
•  Transport du code
Travaux de recherche (Kalimucho)

93
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Application en nesC
• nesC est lié à TinyOs et permet de créer des applications comme des
composants en 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).

94
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
95
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 des processeurs => il y
a peu ou pas de parallélisme tandis que les composants électroniques
fonctionnent en parallélisme total (entre composants et souvent dans le
composant lui-même).
96
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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;
}
97
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Explications
configuration Clignote {
}

implementation {
components Main, ClignoteM, SingleTimer,
LedsC;

Main.StdControl -> ClignoteM.StdControl;


Main.StdControl -> SingleTimer.StdControl;
ClignoteM.Timer -> SingleTimer.Timer;
ClignoteM.Leds -> 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.
98
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 {


components Main, ClignoteM, SingleTimer,
command result_t start(); LedsC;
command result_t stop(); Main.StdControl -> ClignoteM.StdControl;
} Main.StdControl -> SingleTimer.StdControl;
ClignoteM.Timer -> SingleTimer.Timer;
ClignoteM.Leds -> LedsC;
}

Ces commandes correspondent à l’initialisation, le lancement et l’arrêt


du composant. La commande init n'est exécutée qu'une seule fois
alors que les autres peuvent l'être de multiples fois.

99
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Explications
configuration Clignote {
}

implementation {
components Main, ClignoteM, SingleTimer,
LedsC;

Main.StdControl -> ClignoteM.StdControl;


Main.StdControl -> SingleTimer.StdControl;
ClignoteM.Timer -> SingleTimer.Timer;
ClignoteM.Leds -> 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.

100
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Explications
On a la même chose entre Main et le composant SingleTimer par la ligne :
Main.StdControl -> SingleTimer.StdControl;
Donc le init de Main appellera celui de Clignote ET celui de SimpleTimer.

La ligne ClignoteM.Timer -> SingleTimer.Timer;


indique que l’interface Timer de Clignote est liée à celle de 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 de Clignote est liée à celle de 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).
configuration Clignote {
}
Remarque : comme on n'utilise ici que des
implementation {
interfaces déjà connues de nesC (StdControl, components Main, ClignoteM, SingleTimer,
Timer et Leds) on n'a pas a en écrire les fichiers. LedsC;
Si on avait créé un composant avec ses propres
Main.StdControl -> ClignoteM.StdControl;
interfaces on les aurait décrites dans des fichiers Main.StdControl -> SingleTimer.StdControl;
.nc portant le nom de l'interface. ClignoteM.Timer -> SingleTimer.Timer;
ClignoteM.Leds -> LedsC;
} 101
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
L’application Clignote
(vue partielle)
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

102
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

103
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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;
}
} 104
}M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le fichier du module ClignoteM.nc
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
command result_t StdControl.init() {
call Leds.init(); (fired).
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 fired provenant du
etat = ! etat;
if (etat) call Leds.redOn();
timer se limite à basculer la led rouge
else call Leds.redOff(); (on/off) en utilisant les commandes
return SUCCESS;
} redOn et redOff de LedsC.
} 105
}M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Le fichier du module ClignoteM.nc
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 {
command result_t StdControl.init() {
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
if (etat) call Leds.redOn();
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.
} 106
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

107
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 le faire en ligne de commandes.

108
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Un petit exemple simple
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;

109
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Un petit exemple simple
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 {
private boolean marche;

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
marche = true;
while (marche) {
clignotant.setOn(); // allumer la LED
Utils.sleep(500); // attendre 1/2 de seconde C’est tout !
clignotant.setOff(); // éteindre la LED
Utils.sleep(500); // attendre 1/2 de seconde
}
}

protected void pauseApp() {} // Normalement jamais utilisée

protected void destroyApp(boolean arg0) throws MIDletStateChangeException {


marche = false; // appelé en cas d'exception autre que MIDletStateChangeException
} 110
M. Dalmau
} - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

112
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Rappel des couches OSI
Couche Physique
• Transmission des données sous
Les 7 couches du modèle OSI forme de signaux
• Conversion entre bits et signaux
Application Couche Liaison
• Constitution des informations en
Présentation
trames
Session
• Détection et parfois correction des
erreurs de transmission
Transport
Couche Réseau
• Définition d’adresses uniques
Réseau • Routage
Couche Transport
Liaison • Gestion de la transmission
Couche Session
Physique • Synchronisation des communications
Couche Présentation
• Utilisation d’un format normalisé
Couche Application

113
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Couches OSI dans les réseaux de
capteurs
• 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 : non utilisée
• Couche présentation : inutile en général
• 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'application.

Rq : le modèle OSI est parfois bousculé pour des raisons d'optimisation


et d'énergie.
114
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

115
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Couche Physique (radio)
Les systèmes les plus utilisés sont le Bluetooth et le Zigbee
qui fonctionnent sur la bande de fréquence de 2,4 GHz.
Le wifi est plus consommateur d'énergie.
Le bluetooth a une portée faible

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 65 000 7 Elevé
Vitesse de transfert Illimité 720 Kb/s 11-54-108 Mb/s
Portée 100 m 1-10 m 300 m

116
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Bluetooth (IEEE 802.15.1)
• Créé en 1994 création par Ericsson
• Débit maximal 720 Kb/s
• Trois classes :
– classe 1 : puissance 100 mW portée 100m
– classe 2 : puissance 2,4 mW portée 10m
– classe 3 : puissance 1 mW 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.

117
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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é).

118
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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).
• Portée 100 m.
• Vitesses : 250Kbps à 2,4 GHz, 40Kbps à 915MHz ou 20Kbps à
868MHz.
• 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.
119
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

120
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Quels sont les problèmes ?
• Réseau incomplet
• Routes non connues à l’avance
• Disparition de certains nœuds
• Mobilité de certains nœuds
• Localisation des nœuds
• Maîtrise de l’énergie
• Redondance/agrégation des données
• Fiabilité et complétude des données
• Sécurité des matériels
• Confidentialité des données

121
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Adressage des nœuds
• Adresses figées
– MAC
– IEEE
• Adresses fixées
– IP
• Adresses dynamiques
– DHCP (IP)
– Bluetooth
• Pas d’adresses
– Réseaux industriels (adressage par contenu)

122
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Désignation du destinataire
• Point à point
– L’émetteur indique l’adresse du récepteur, seul ce récepteur
traite le message
• Multicast (pas toujours possible)
– L’émetteur indique une adresse de groupe, tous les récepteur
faisant partie de ce groupe traitent le message
• Broadcast
– L’émetteur n’indique aucune adresse, tous les récepteurs à
portée traitent le message (éventuellement selon son contenu)
• Par contenu
– L’émetteur n’indique aucune adresse mais identifie le contenu,
tous les récepteurs intéressés par ce contenu traitent le
message.

123
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 donc ne reçoivent pas.

• 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 et peut changer au cours du
temps (mobilité, pannes). 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.

124
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 émet.
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 ceux de B.
125
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

126
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 C
que B émet donc conclut le médium B D
est 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.

127
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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
• D veut émettre vers C. D ne capte pas C
ce que B émet donc conclut le médium B D
est libre et commence son émission.
Son signal ne brouille pas le dialogue
entre A et B. Mais si C répond à D, il
brouillera la réception de B mais il se
peut que B ne soit pas récepteur.

128
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 C
B é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.

129
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Problème de visibilité des stations
Solution possible : protocole RTS/CTS ou MACA (Medium Access with
Collision Avoidance) adopté dans 802.11

Idée :
1. Permettre aux autres nœuds de savoir s’ils sont à portée de
l’émetteur/du récepteur ou des deux (pour savoir s’ils peuvent gêner).
2. Permettre aux autres nœuds de savoir combien de temps durera la
communication (s’ils doivent attendre)

Principe :
– Quand A veut émettre vers B, il envoie un message RTS (Request To
Send) avec le nombre d'octets qu'il veut émettre
– B répond par un message CTS (Clear To Send) avec ce même nombre.
Puis l'envoi a lieu avec un retour par ACK ou NACK.

130
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
RTS/CTS (MACA)
• Un nœud qui reçoit un RTS sait qu’il est à portée de
l’émetteur
– Il peut émettre sans gêner la réception

• Un nœud qui reçoit un CTS sait qu’il est à portée du


récepteur
– Il ne peut pas émettre

• Un nœud qui reçoit un RTS et un CTS sait qu’il est à


portée de l’émetteur et du récepteur
– Il ne peut pas émettre

Mais ce n’est pas si simple …


131
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Problème de visibilité des stations
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 !

132
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Problème de visibilité des stations
Exemple d'illustration :
C A B D
E F

Étude de cas (2) : A veut communiquer avec B  il lui envoie un RTS et B


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.
Mais 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.

133
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Problème de visibilité des stations
Exemple d'illustration :
C A B D
E F

Étude de cas (3) : A veut communiquer avec B  il lui envoie un RTS et B


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)

134
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

135
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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

136
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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, et 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.

137
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
138
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

139
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

140
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

141
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
142
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
143
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
144
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

145
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

Rappel : 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).
146
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
147
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
WiseMAC
Etude de cas sur ce protocole :

L'estimation du délai par 4 L θ est surévaluée car θ est une valeur


maximale (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 θ.

148
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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


NEW_SESSION, tous ceux qui le reçoivent lancent un délai
aléatoire. Quand ce délai se termine le nœud conserve dans
une table les nœuds qu'il a reçus 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 à
petit tous les nœuds auront choisi un père.

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.

149
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et envoie un
message pour le signaler.
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.

150
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

151
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 voient passer ce
message d'invitation et ainsi savent qu'ils n'ont pas été choisis ils
attendent donc une autre offre.
152
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

153
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
154
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
155
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 + X 2 + X + 1
– CRC-64 (ISO) : X64 + X4 + X3 + X + 1

156
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

157
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

158
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Positionnement et localisation
(GPS)
Le GPS est constitué de 28 satellites à 20 000 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 contenant leur heure de départ du satellite
et la position du satellite à cet instant.

Le récepteur au sol reçoit donc les positions précises


des satellites et connaît l’heure exacte d’émission
des messages. Quand il reçoit les signaux des
satellites, il sait à quel moment il les a reçus et doit
pouvoir calculer sa distance aux satellites.

159
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
GPS : approche mathématique
• Lorsque l’on reçoit un message du satellite S1 il contient :
– Les coordonnées de S1 : x1, y1 et z1
– L’heure d’émission du message te1
• Ce message est reçu à l’heure tr1
• La distance qui nous sépare de ce satellite devrait être :
d1 = C(tr1- te1) où C est la vitesse de la lumière.
• Mais notre horloge n’est pas synchrone de celle du satellite S1 : elle
est décalée de e1 donc : d1 = C(tr1+ e1 - te1)
• Lorsque l’on reçoit un message du satellite S2 on a de même :
d2 = C(tr2+ e2 – te2)
• Comme les satellites ont des horloges atomiques synchronisées le
décalage de notre horloge est le même pour tous donc e2 = e1 = e

160
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
GPS : approche mathématique
• On a donc maintenant :
d1 = C(tr1+ e - te1) et d2 = C(tr2+ e – te2)
D’où d2 - d1 = C(tr1- te1 - tr2+ te2) où toutes les valeurs sont connues
• Par ailleurs on sait que :
d1 = (x1-x)² + (y1–y)² + (z1-z)² et
d2 = (x2-x)² + (y2–y)² + (z2-z)² où (x,y,z) est notre position
Donc C(tr1- te1 - tr2+ te2) = (x2-x)² + (y2–y)² + (z2-z)² - (x1-x)² + (y1–y)² + (z1-z)²
Ce qui donne 1 équation à 3 inconnues (x, y et z)
• La réception d’un troisième satellite S3 apportera une nouvelle équation
par l’expression de d3 - d1 ou de d3 – d2 (ces 2 équations sont liées donc une
seule suffit l’autre n’apporte rien de plus)
• On voit donc qu’il faudra 4 satellites pour avoir 3 équations et calculer les
3 inconnues (notre position)

161
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
GPS : approche géométrique
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. C’est là
qu’intervient le 4éme satellite 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.

Le 4ème satellite est malgré tout utile parce que


l’horloge du récepteur n’étant pas synchrone
de celles des satellites, les sphères et leurs
intersection ont une épaisseur due au décalage
d’horloge qui est levée par ce 4ème satellite.
Le système a 4 inconnues : x, y, z et e

162
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Positionnement et localisation
• É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

163
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

164
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Positionnement global sans
estimation de distances
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.
165
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Positionnement global sans
estimation de distances
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.
166
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Positionnement global avec
estimation de distances
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 :


167
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Positionnement global avec
estimation de distances

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.
168
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
169
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

170
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
171
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Routage
La façon de trouver une route peut être :
• Proactive :
– Les routes sont calculées avant d'être utilisées  mises à jour continue des tables
– Avantage :
• Route disponible immédiatement
– Inconvénients :
• Maintenance de routes non utilisées
• Surcharge due aux mises à jour

• Réactive :
– Les routes sont calculées à la volée, le demandeur lance la recherche de route
– Avantage :
• Adaptable car la route trouvée est actuellement utilisable
– Inconvénients :
• Temps de recherche de route
• Risque de surcharges ponctuelles lors des recherche de route

• Hybride :
– Mélange des deux méthodes précédentes dans le but d’équilibrer leurs avantages
et leurs inconvénients.

172
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

173
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

174
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
175
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.

176
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat

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 n’est intéressé par
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.
177
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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 (inondation). 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.

178
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.

Exemple de demande : Exemple de réponse :


Type = température Type = température
Intervalle = 10ms Position = [108, 115]
Zone = [100, 100, 120, 120] Date : 11:32:12
date : 11:31:25 Température = 23
Durée = 1 mn

Avec ces échanges les nœuds vont déterminer la ou les routes possibles.

179
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.

180
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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%.

181
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.

182
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.
183
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.

184
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.

185
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
Routage par rumeur
Remarque : Rien ne prouve que les 2
Evénement trajectoires (l'événement et la
demande) vont se croiser mais :
• Dans une zone rectangulaire la
Demande probabilité que 2 lignes prises au
hasard se croisent est de 69%.
• Si on prend 5 lignes passant par 1
point la probabilité qu’une ligne prise
au hasard en croise une des 5 est de
99,7%

On peut toujours prévoir, dans le cas où ça n'aboutirait pas, à faire une


diffusion totale de la demande ou de l'événement.

186
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.

187
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage à plat
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.
188
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

189
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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. 190
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
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
191
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
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 !

192
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
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).

193
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
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


194
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
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.

195
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
localisation
Routage par faces
On change de face  on repart donc du nœud X pour recommencer 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

196
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
localisation
Routage par faces

On arrive en Y et on continue jusqu'à arriver en t.

Y Y
X X
Z
Z

197
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
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).
198
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Protocoles de routage basés sur la
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.

199
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

200
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

201
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Routage multi chemin
• 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.

202
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Routage multi chemin
• 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.
203
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

204
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

205
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Découpage d'un réseau
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.

206
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Découpage d'un réseau
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.
207
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Découpage d'un réseau
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.

208
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Découpage d'un réseau
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.

209
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Découpage d'un réseau
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.

210
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

211
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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

212
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

213
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
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.

214
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
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.
215
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
Réseaux à plat : Mode Pull

• 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).

216
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
Réseaux à plat : Mode Pull
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
chemins :
1 Source1  destination par a b c
a
N1
Et Source 2  destination par f g:
b Est moins intéressant que de prendre
Source1  destination par a b c
N2
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
217
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
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.).

218
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
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.

219
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
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.

220
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Agrégation basée sur
l'architecture du réseau
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.
221
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.

222
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
223
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 et Android
• Routage multi-chemins
– Applications
• nesC (TinyOS)
– Découpage d’un réseau
• Java (Squawk) – Agrégation de données
– Sécurité

224
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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

225
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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

226
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Sécurité : Attaques
Méthodes d’attaques
– Surcharge : émettre beaucoup de message 
épuiser les batteries des récepteurs
– 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
– Données : introduire de fausses données
– Introduction de code sur les capteurs

227
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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.
228
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Solution : cryptage avec clés
Opérations possibles :
– Génération de clés
– Distribution de clés
– Révocation de clés
– Renouvellement de clés
Pour limiter les risques :
– Une clé a une durée de vie limitée (temps estimé
d’une attaque)
– La même clé n’est utilisé que par quelques noeuds

229
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 Chiffré Décodage

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.

230
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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
231
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
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 multi-chemins 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

232
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Sécurité : agrégation de données
• Fragilité de l’agrégation :
1. Un nœud peut modifier les données provenant des autres
2. Un nœud peut falsifier le résultat (ajout d’infos fausses)

• Solution :
– Pour 1 : Cryptage homomorphe : cryp(x+y) = cryp(x)+cryp(y) 
ajout d’infos sans devoir décrypter les autres
– Pour 2 : ?

233
M. Dalmau - IUT de Bayonne : Réseaux de capteurs
Conclusion
• Domaine de recherche et développement actif
– Les problèmes (réseau, énergie, applications) sont les mêmes sur les
capteurs et les mobiles

• L’équipe T2I 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

Les personnes intéressées peuvent prendre contact avec cette équipe


(à l’IUT de Montaury, département informatique : P Roose ou moi
même).

234
M. Dalmau - IUT de Bayonne : Réseaux de capteurs