cours rÃ©seaux de capteurs [mode de compatibilitÃ©]dalmau/documents/cours/capte… · 0...

$: Cours RÃ©seaux de capteurs [Mode de compatibilitÃ©]dalmau/documents/cours/capte… · 0 'dopdx ,87 gh %d\rqqh 5pvhdx[ gh fdswhxuv 1rp 0duf 'dopdx 3djh kwws zzz lxwed\rqqh xqly$
M. Dalmau - IUT de Bayonne : Réseaux de capteurs1

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


Les dispositifs

• Capteurs sans fils

• Drones

• Smartphones

• Objets connectés

• RFID


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


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



• 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

traitement

captureenvoi



• 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


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


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


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.


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


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 …


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é


Exemple : Contrôle de structures(alarming)

• Golden Gate Bridge

Antenne

Capteur

Batterie

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


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


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


Zone d’étude

Observatoire des volcans d’Hawaii

Désert

ForêtSilènes


Les capteurs sont placés dans des faux rochers …

température

humidité

lumière

vent

CPU +Radio

Batteries


… ou des fausses branches

température

lumière

CPU +Radio


Puis disséminés dans la zone d’étude


Suivi des déplacements de zèbres au Kenya

Donnéescollecte de données (avion ou voiture)

Données

Donnéescommunications par stockage et envoi

Données

capteur avec CPU, FLASH, radio et GPS


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


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


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 …


Drones

Expertise visuelleAgriculture

Chantiers

Carrières UrbanismeAudit énergétique


L’Internet des objets• Proposer des objets courants connectés

consultables et pilotables par un PC, un smartphone …


L’Internet des objets


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é


Plan du cours• Les capteurs

– Architecture générale– Étude d’un processeur

(ARM)– Problème de l’énergie

• Le logiciel– Systèmes d’exploitation

• TinyOS• Squawk et Android

– Applications• nesC (TinyOS)• Java (Squawk)

• Les réseaux de capteurs– La radio

– Accès au médium• Problèmes

• protocoles utilisés

– Positionnement et localisation

– Routage• Routage à plat

• Routage basé sur la localisation

• Routage multi-chemins

– Découpage d’un réseau

– Agrégation de données

– Sécurité

















– Sécurité


Architecture généraleUn capteur est essentiellement composé de :

– Unités de capture et actionneurs– Processeur et mémoire– Émetteur/récepteur– Alimentation

capteursphysiques

processeur communication

actionneursphysiques gestion de l'alimentation sécurité


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


Capteurs• Principes

– Transforme une grandeur physique en :• Une grandeur électrique : tension ou courantou• 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)


Types de capteurs• Déplacement

– 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)


Communication

Par radio : Zigbee (IEEE 802.15.4) , Bluetooth (IEEE 802.15.1) , WI-FI (IEEE 802.11) , 3G

Technologie Vitesse

max

Consommation Temps de démarrage

Zigbee 250 KB/s faible Court

Bluetooth 1 MB/s moyenne Moyen

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


Carte à microcontrôleur

+ Capteurs

+ Emetteur récepteur radio (zigbee)

Anatomie d'un capteur


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)

















– Sécurité


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.


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.


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

















– Sécurité


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


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


Le problème de l'énergie (exemple)

Rappel consommations :Actif : 15 mA, en attente : 7 mA, en veille : 200 μAEn émission : +50 mA , en réception : +210 mABatterie 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.



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



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

















– Sécurité


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.

















– Sécurité


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.


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.


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.


Modules et interfacesmodule truc {

provides {interface C;

}uses {

interface Ainterface B

}

implementation {// code à implémenter :// commandes de l'interface C// +// traitement des événements des interfaces A et B

}}interface C {

command resultat1 cmd1(paramètres);command resultat2 cmd2(paramètres);…event resultat3 evt1();event resultat3 evt2();…}

Truc

A

B

C

event

command


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.


Liaisons :Fabriquer le composant C3 à partir de C1 et C2.

configuration C3 {provides {

interface A;interface B

}

implementation {components C1,C2;A = C1.A;B = C1.B;B = C2.B;C1.C -> C2.C;

}}

C3

C1 CA

B

C2C

A

BB


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.


Modèle d'exécutionTinyOS 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.


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.


ConcurrenceComme 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 …


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.


Bloc atomicLe 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

















– Sécurité


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.


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.


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


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();



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();



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);


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)


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 …)

• …



Des bibliothèques (C et C++) – pas obligatoires

• Graphisme

• Médias

• Web

• …



Une machine virtuelle java

• Dalvik (une JVM par application)

• Code spécifique 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



Les applications(Activités)


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


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 onPictureTakende 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

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

Android : Géolocalisation par GPS


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

















– Sécurité


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 codeTravaux de recherche (Kalimucho)


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) :

Signauxen entrée

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


Application en NESC

On va ensuite interconnecter cescomposants entre eux.En électronique on a un schéma decâ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.


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


Un petit exemple simpleOn 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;

Main.StdControl -> ClignoteM.StdControl;Main.StdControl -> SingleTimer.StdControl;ClignoteM.Timer -> SingleTimer.Timer;ClignoteM.Leds -> LedsC;

}

On va le détailler


Explications

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.



LedsC;


}


ExplicationsLe 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 :

interface StdControl {command result_t init();command result_t start();command result_t stop();

}

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.



LedsC;


}


Explications

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.



LedsC;


}


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



LedsC;


}

Remarque : comme on n'utilise ici que des interfaces déjà connues de nesC (StdControl, Timer et Leds) on n'a pas a en écrire les fichiers. Si on avait créé un composant avec ses propres interfaces on les aurait décrites dans des fichiers .nc portant le nom de l'interface.


L’application Clignote (vue partielle)

On arrive au schéma de câblage suivant :

Clignote

StdControl

Timer

Leds

SimpleTimer

StdControl

Timer

LedsC

Leds

Main

StdControlH

WClock

Ordonnanceur

StdControl


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.


Le fichier du module ClignoteM.ncmodule ClignoteM {

provides {interface StdControl;

}uses {

interface Timer;interface Leds;

}

implementation {bool etat;command result_t StdControl.init() {

call Leds.init();return SUCCESS;}

command result_t StdControl.start() {return call Timer.start(TIMER_REPEAT, 1000) ;}

command result_t StdControl.stop() {return call Timer.stop();}

event result_t Timer.fired() {etat = ! etat;if (etat) call Leds.redOn();else call Leds.redOff();return SUCCESS;}

}}

La partie provides indique les interfaces fournies par ce composant. On y retrouve StdControl puisque ce composant la fournit à Main.

La partie uses indique les interfaces utilisées par ce composant. On y retrouve Timer (fournie par le composant SimpleTimer) et Leds (fournie par le composant LedsC).




}uses {


}






}}

La partie implementation de Clignote va contenir les codes pour les commandes et la prise en compte des événements. On y trouve donc les 3 commandes de l'interface fournie StdControl et celle de l'événement du SimpleTimer (fired).•La commande init se limite à appeler init de LedsC.•La commande start lance le timer en mode continu pour une durée répétitive de 1 sec.•La commande stop arrête le timer.•L'événement fired provenant du timer se limite à basculer la led rouge (on/off) en utilisant les commandes redOn et redOff de LedsC.




}uses {


}






}}

L'interface Leds fournit redOn, redOff, redToggle, greenOn …. qui peuvent être appelées par Clignote pour piloter les LEDs.

L'interface Timer contient les commandes et événements suivants :

interface Timer {command result_t start(char type,

uint32_t interval);command result_t stop();event result_t fired();

}start et stop sont des commandes qui seront appelées par Clignote. En revanche fired est un événement càd fournit un signal et n'est pas appelée de façon explicite par clignote. Ce signal étant relié au composant Clignote, il déclenchera automatiquement l'exécution du code prévu à cet effet dans Clignote.

















– Sécurité


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.


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éesimport 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;


Un petit exemple simpleL’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 capteurITriColorLED cligontant = leds[0]; // la Led utiliséeclignotant.setRGB(200,0,0); // led en rougemarche = true;while (marche) {

clignotant.setOn(); // allumer la LEDUtils.sleep(500); // attendre 1/2 de secondeclignotant.setOff(); // éteindre la LEDUtils.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

}}

C’est tout !

















– Sécurité


Rappel des couches OSI

Les 7 couches du modèle OSI

Physique

Liaison

Réseau

Transport

Session

Présentation

Application

Couche Physique• Transmission des données sous

forme de signaux• Conversion entre bits et signaux

Couche Liaison• Constitution des informations en

trames• Détection et parfois correction des

erreurs de transmissionCouche Réseau

• Définition d’adresses uniques• Routage

Couche Transport• Gestion de la transmission

Couche Session• Synchronisation des communications

Couche Présentation• Utilisation d’un format normalisé

Couche Application


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.

















– Sécurité


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


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.


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


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.

















– Sécurité


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


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)


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.


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.


Accès au medium (MAC)

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.

B A

C

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 émis peut être capté par tout nœud à portée (diffusion) mais la visibilité des nœuds est différente, par exemple :


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 émettreOn 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.


Problème de visibilité des stations

Cas pratique : on a 4 nœuds A, B, C et D

• B émet vers A• C veut émettre vers D. C capte ce

que B émet donc conclut le médium 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.

B

AC

D

Rappel : La puissance du signal radio décroît comme le carré de la distance.




• B émet vers A• D veut émettre vers C. D ne capte pas

ce que B émet donc conclut le médium 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.

B

AC

D





• B émet vers A• C veut émettre vers D. C capte ce que

B émet donc conclut le médium 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.

B

AC

D




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.


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 …


Problème de visibilité des stations Exemple d'illustration :

C A B DE 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 !



C A B DE F


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.



C A B DE F


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)

















– Sécurité


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


PAMASRé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.


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.


SMACRé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.


SMACQuestion : 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.


SMAC

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.

Synchronisateur Synchronisateur

Nœud frontalier

Nœud frontalier


SMACRemarque : 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.


T-MACRéférence : T. van Dam and K. Langendoen. An adaptive energy-efficient mac protocolfor 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.


T-MACSolutions 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.


T-MACSolutions 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.


WiseMACRéférence : A. El-Hoiydi, J.-D. Decotignie, C. Enz, and E. Le Roux. wisemac, an ultralow 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).


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


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


AMRIS

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.

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


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.


Multi fréquencesRé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.


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.


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.


Multi fréquencesMobilité (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.


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.


Correction d'erreurs • On peut corriger à la couche 2 par des codes correcteurs ou aux

couches supérieures par retransmission.

• Certains types d'erreurs (parasites) rendent des trames entières non lisibles, d'autres (signal faible) ne modifient que quelques bits. Les seconds sont facilement traitables par des codes correcteurs mais pas les premiers.

• Codes correcteurs connus : Hamming, CRC : – CRC-8 (ATM) : X8 + X2 + X + 1

– CRC-12 (HDLC) : X12 + X11 + X3 + X2 + X + 1

– CRC-16 (CCITT) : X16 + X12 + X5 + 1 (utilisé par bluetooth, zigbee)

– CRC-32 (Ethernet) : = X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 + X4 + X2 + X + 1

– CRC-64 (ISO) : X64 + X4 + X3 + X + 1

















– Sécurité


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.


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.


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


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)


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


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 distances aux voisins

Topologie complète en coordonnées géographiques

Topologie complète en coordonnées relatives

Impossible de connaître les distances aux voisins

Positionnement approximatif Matrice de connectivité


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.



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.

Zone commune à A1 , A2 et β

Zone commune à B1 et B2

Zone commune à A1 et A2



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.


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 :


Positionnement global avec estimation de distances

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.

Triangulation


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 :

On peut alors calculer des positions relatives de p et q par rapport à i.

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

On pourra lever l'ambiguïté du signe de la seconde coordonnée en utilisant les autres voisins et la portée de la radio comme vu précédemment.

i

p

q

i p

q

A

















– Sécurité


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


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


Routage

Lorsqu'un message circule sur une route, il est possible de lui agrégerdes 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.

















– Sécurité


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.


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.



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.

SPIN (Sensor Protocol for Information via Negociation)


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.



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 :Type = températureIntervalle = 10msZone = [100, 100, 120, 120]date : 11:31:25Durée = 1 mn

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

Exemple de réponse :Type = températurePosition = [108, 115]Date : 11:32:12Température = 23



Il faut maintenant choisir une route parmi les routes possibles ainsi déterminées :

• Méthode dite de Gradient-Based RoutingRé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.



Il faut maintenant choisir une route parmi les routes possibles ainsi déterminées :

Méthode basée sur l'énergieRé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%.



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



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



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


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.



Routage par rumeur

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.

Evénement

Demande

Remarque : Rien ne prouve que les 2 trajectoires (l'événement et la demande) vont se croiser mais :

• Dans une zone rectangulaire la 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%



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.


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.

















– Sécurité


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.



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

F’



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

DHFEt on tourne en rond !



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


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 enfaces puis de se déplacer de face en face vers l'objectif. Le graphe obtenu ne doit pasavoir d'arêtes qui se coupent, on peut toujours se débrouiller pour y arriver. On peutmontrer que si on a des arrêtes qui se coupent l'algorithme peut tourner en rond.

Graphe initial Découpage en faces



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.

X



On change de face on repart donc du nœud X pour recommencer ce quel'on avait fait depuis S c’est à dire que l'on trace la ligne directe entre X ett et que l'on fait circuler le message sur la nouvelle face jusqu'au nœuddont le voisin est sur la ligne d'intersection (Y).

YX



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

YX X

YZ

Z



Chemin parcouru

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

YX Zs t



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.

















– Sécurité


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.


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.


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.

















– Sécurité


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.


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.


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.


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.


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é

est si on considère que chaque carré a 4 voisins

et si on considère que chaque carré a 8 voisins.

L'objectif est de maintenir le plus possible les nœuds non centraux en veille.

Découpage d'un réseau

5

R

8

R


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.

















– Sécurité


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


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.



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.



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.



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



Réseaux à plat : Mode PullLe 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.

Source1

Source2

demandeur

N2

N1

N3

a

f

e

c

g

b

d

Par exemple, dans le dessin ci-contre prendre les chemins :

Source1 destination par a b c

Et Source 2 destination par f g:Est moins intéressant que de prendre

Source1 destination par a b c

Et Source 2 destination par e cCar le nœud N2 peut faire l'agrégation des infos de source1 et de source2.

Il en serait de même en prenant

Source1 destination par a d g

Et Source 2 destination par f gAvec N3 qui fait l'agrégation



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



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.


Agrégation basée sur l'architecture du réseauRé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.



Réseaux hiérarchisés : Agrégation par arbreRé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.


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.


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.

















– Sécurité


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


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


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


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’informations2. Envoi d’informations fausses3. Brouillage des communications4. É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.


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


Méthodes de cryptage1. Avec clé secrète

Les algorithmes ne sont pas secrets, seules les clés le sont

2. Avec clés privée/publiques

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.

Algorithme de chiffrage

Algorithmede

Décodage

Message MessageMessage

Chiffré

Clé Clé

A B

Algorithmede chiffrage

Algorithmede

Décodage

Message MessageMessage

Chiffré

Clé publique de B Clé privée de B

A B


A Bp , g , TA

TB

TA= ga mod p

TB= gb mod p

KA= TBa mod p KB= TA

b mod p

Sécurité : cryptage

1) A choisit un nombre premier p et un nombre g<p

2) A prend un nombre aléatoire a et envoie à B les valeurs p, g et TA = ga 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

5) A calcule KA = TBa mod p

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 :

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


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


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 : ?


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

cours rÃ©seaux de capteurs [mode de compatibilitÃ©]dalmau/documents/cours/capte… · 0...

Documents