La communication radio entre les capteurs

La communication radio entre les capteurs

Selon le Mode de transmission

Routage proactif

Le calcul de routes se fait à priori ce qui facilite l‟acheminement des données. Les informations des chemins à suivre par chaque donnée source vers une destination sur le réseau sont stockées dans une table de routage. Les tables de routage doivent être mises à jour régulièrement afin de corriger certains chemins coupés en raison du changement de topologie dus aux défaillances ou à la mobilité de certains noeuds capteurs. Cette mise à jour est assurée par la diffusion périodique des paquets de contrôle sur le réseau, ce qui n‟est pas évident pour des réseaux de grande taille comme les réseaux de capteurs sans fil. L‟établissement de routes se fait indépendamment des besoins réels de l‟application et un bon nombre de ces routes est sauvegardé pour ne jamais être utilisées. Une autre limite concerne la taille des tables de routage, notamment pour des réseaux de grande taille, qui pourrait dépasser les capacités de stockage des noeuds capteurs.

Routage réactif

Egalement appelé routage à la demande, le routage réactif permet de créer les routes selon les besoins de l‟application. Lorsqu‟une requête est diffusée sur le réseau, la procédure de découverte des routes est lancée par les noeuds concernés par cette requête, et les réponses sont acheminées sur les routes créées. Cette procédure est lancée également pour des applications orientées événements, pour chaque événement intéressant détecté. L‟avantage d‟établir des routes à la demande est la conservation d‟énergie par rapport au routage proactif. La recherche de routes peut causer des lenteurs pour l‟acheminement des données ce qui n‟est pas approprié aux applications interactives et temps-réel [20].

Routage hybride (à la fois proactif et réactif)

C‟est une combinaison des deux concepts de routage proactif et réactif. Des tables de routage sont stockées sur les noeuds capteurs de façon à établir des routes sur leur voisinage proche (généralement en deux sauts maximums). Au-delà de leur voisinage, le routage devient réactif et des procédures de recherche de routes sont lancées. Cette approche combine les avantages des deux autres approches proactive et réactive et réduit considérablement la taille des tables de routage ainsi que les délais d‟établissement de routes.

Selon Les fonctions du protocole

Protocole de routage multi-chemin

Il se base sur l’adoption de plus qu’un chemin menant vers la destination, et ce, pour avoir des chemins de secours si jamais le chemin principal serait rompu.

Protocole de routage basé sur la négociation des données

En détectant le même phénomène, les noeuds capteurs inondent le réseau par les mêmes paquets de données. Ce problème de redondance peut être résolu en employant des protocoles de routage basés sur la négociation. En effet, avant de transmettre, les noeuds capteurs négocient entre eux leurs données en échangeant des paquets de signalisation spéciales, appelés META-DATA. Ces paquets permettent de vérifier si les noeuds voisins disposent des mêmes données à transmettre. Cette procédure garantit que seules les informations utiles seront transmises et élimine la redondance des données.

Protocole de routage basé sur la QoS

Ce type de protocoles tend à satisfaire certaines métriques, pendant la transmission des données vers la destination finale. Parmi ces métriques, nous citons : le délai de bout en bout, la gigue, PDR (Paquet Delivery Ratio), et l‟énergie consommée.

Les protocoles de routage proposé pour les RCSF

Nous citons dans cette section quelques protocoles de routage proposés pour les réseaux de capteurs sans fil :

LEACH (Low-Energy Adaptive Clustering. Hierarchy)

Son principe est de former des zones communes de calcul et de traitements en se basant sur la puissance du signal et le niveau d‟énergie des noeuds capteurs. Chaque zone est dirigée par un chef de zone, jouant le rôle d‟agrégateur et de routeur, en effectuant des traitements sur les données reçues de son cluster et leur expédition vers la prochaine destination. Ce rôle de chef de zone est échangé entre les noeuds d‟un cluster afin de répartir équitablement la consommation d‟énergie entre eux.

TEEN et APTEEN (Threshold sensitive Energy Efficient sensor Network protocol)

TEEN est un protocole hiérarchique conçu pour être sensible aux changements improviste des attributs détectés tels que la température. L’architecture du réseau est basée sur un groupement hiérarchique où les noeuds les plus proches forment des clusters. Après la construction des clusters, le cluster head diffuse deux seuils aux noeuds. Qui sont la valeur minimale d’un attribut pour pouvoir être transmis et le degré minimale du changement de cet attribut. Le TEEN adaptatif (APTEEN) est une extension du TEEN basée sur la capture périodique des données et la réaction aux événements temps-réel. Quand la station de base forme les clusters, les cluster-heads diffusent les attributs, les seuils et le plan de transmission à tous les noeuds et effectuent également l’agrégation des données afin d’économiser l’énergie.

Les protocoles de routage «PEGASIS & Hierarchical-PEGASIS»

Power-Efficient GAthering in Sensor Information Systems (PEGASIS) est une version améliorée du protocole LEACH. PEGASIS forme des chaînes plutôt que des clusters de noeuds de capteurs afin que chaque noeud transmette et reçoive uniquement des données d’un voisin. Un seul noeud est sélectionné à partir de cette chaîne pour transmettre à la station de base. L’idée de PEGASIS est qu’il utilise tous les noeuds pour transmettre ou recevoir des données avec ses plus proches voisins. Il déplace les données reçues de noeud à noeud, puis les données seront agrégées jusqu’à ce qu’elles atteignent tous la station de base. Donc, chaque noeud du réseau est tour à tour un chef de file de la chaîne, ainsi que responsable pour transmettre l’ensemble des données recueillies et fusionnées par la chaîne de noeuds au niveau de la station de base.

Le protocole de routage SPIN

SPIN (Sensor Protocols for Information via Negociation) est un protocole de routage qui se base sur le principe de métadonnées lors du processus de diffusion de requêtes sur le réseau. Le récepteur de la requête a la possibilité de choisir d‟accepter la donnée ou non. C‟est le principe de la négociation. SPIN est considéré comme le premier protocole data centric destiné aux RCSF. Tous les noeuds du réseau sont traités comme des noeuds de destination dont la tâche principale est de recueillir un point de vue globale sur leur environnement. Egalement, SPIN s‟attaque à la redondance de données transmises sur un réseau de capteurs sans fil.

Directed Diffusion (DD)

Directed Diffusion ou diffusion dirigée est un protocole de propagation de données. C‟est l‟un des protocoles les plus intéressants dans le routage data Centric des RCSF. Son utilité réside dans sa capacité à réduire considérablement le nombre d‟opérations de la couche réseau par la création de plusieurs chemins pour le routage d‟informations et ainsi permettre une économie d‟énergie conséquente aux capteurs. Cette réduction d‟opération passe par une mise en place de quatre éléments : i) la nomination des données (décrire les intérêts) ; ii) propagation des intérêts ; iii) propagation des données ; iv) renforcement des chemins de transport de données. Le protocole DD à travers ces quatre éléments définit au préalable la nature de la donnée à capter, décrit cette donnée sous forme d‟intérêt et diffuse cette requête sur le réseau. Les noeuds concernés commencent à capter et propager les données sur des chemins différents. A la réception des premières données par la station de base, elle procède au choix puis au renforcement des meilleurs chemins.

Rumour Routing

Le protocole Rumour Routing utilise un procédé probabiliste, similaire au gossiping, afin de trouver un compromis entre l‟inondation des intérêts et la propagation de données. Ce procédé probabiliste repose sur la méthode Monté-Carlo qui suppose que la probabilité que deux lignes se croisant au sein d‟une région rectangulaire est de 0.69, et si on utilise cinq lignes passant par un point, la probabilité qu‟une autre ligne se croise avec l‟une des cinq lignes est de 0.997. Par conséquent, si on considère la source et le puits deux points distincts, on établit un certain nombre de mi-chemin depuis la source et d‟autres mi-chemin depuis le puits et on aura une forte probabilité que deux mi-chemin se joignent créant ainsi un chemin complet entre la source et la destination. Ce procédé permet d‟éviter l‟inondation de données.

Le protocole de routage «GEAR »

Le protocole de routage GEAR (Geographic and Energy Aware Routing) a été suggéré par Y. Yu, D. Estrin. Il consiste à utiliser l’information géographique lors de la diffusion des requêtes aux régions cibles car les requêtes contiennent souvent des données géographiques. L’idée est de restreindre le nombre de données dans la diffusion dirigée en prenant en considération uniquement une certaine région, plutôt que d’envoyer les données à l’ensemble du réseau. Avec le protocole GEAR, chaque noeud maintient le coût pour atteindre la destination en passant par ses voisins. Ce coût est divisé en deux parties : un coût estimé et un coût d’apprentissage. Le coût estimé est une combinaison de l‟énergie résiduelle et de la distance jusqu’à destination. Le coût d’apprentissage est un raffinement du coût estimé qu‟un noeud dépense pour le routage autour des trous dans le réseau [2].

Le protocole MECN (Minimum Energy Communication Network

C‟est un protocole de routage géographique conçu pour des noeuds capteurs équipés d‟un GPS à basse puissance. L‟idée est de trouver un sous réseau composé d‟un nombre minimum de noeuds, proches entre eux, afin d‟avoir une puissance de transmission faible et moins couteuse en énergie entre deux noeuds particuliers du réseau.

Le protocole AODV (Ad-hoc On Demand Distance Vector)

C‟est un protocole de routage conçu par Charles E.Perkins et Elizabeth M. Royer basé sur le principe des vecteurs de distance et appartient à la famille des protocoles réactifs. Il représente essentiellement une amélioration de l’algorithme proactif DSDV mais réduit l’overhead (nombre de diffusions de messages) en ne calculant les routes que sur demande(AODV). Ce protocole utilise les deux mécanismes « découverte de route » et « maintenance de route », en plus du routage « noeud par noeud  » et construit les routes par l’emploi d’un cycle de requête « route request/route reply « .

La sécurité dans les RCSF

Exigences en sécurité

Un réseau de capteur est un type spécial de réseaux. Il partage quelques vulgarisations avec un réseau informatique typique, mais pose également des conditions uniques de ses propres caractéristiques. Par conséquent, un protocole de sécurité pour un RCSF, doit satisfaire une ou plusieurs conditions de sécurité, à savoir :

La confidentialité

Elle consiste à s‟assurer que personne ne pourra interférer dans la communication entre deux noeuds afin de récupérer les données lors de leur transfert. Les algorithmes cryptographiques de nos jours peuvent assurer une confidentialité suffisante en utilisant des clés de grande taille. Cependant, ces algorithmes sont lourds en termes de mémoire et de calcul, de plus pour les RCSF il faut considérer le temps et l‟énergie qu‟ils consomment. Il est nécessaire d‟adapter ces algorithmes pour qu‟ils puissent être un bénéfice et non pas un handicap pour les RCSF [1].

Intégrité des données 

Un noeud intrus (adversaire) peut modifier les données transférées. Par exemple, un noeud malveillant peut ajouter quelques fragments ou manoeuvrer les données dans un paquet. Ce nouveau paquet peut alors être envoyé au récepteur original. La perte ou les dommages de données peut même se produire sans présence d’un noeud malveillant dû à l’environnement dur de communication. Ainsi, l‟intégrité des données s’assure qu’aucune donnée reçue n’a été changée en transit [23].

L’authentification d’un noeud

C‟est le fait de pouvoir vérifier et connaître avec une grande certitude l‟identité d‟un noeud. Elle pourra être assurée implicitement dans un système à chiffrement symétrique, car dans un tel système, deux entités partagent d‟une façon sûre une seule clé secrète. Alors, seule l‟entité qui possède la clé secrète pourra chiffrer/déchiffrer les données. Dans les systèmes asymétriques, l‟authentification pourra être assurée lors de l‟utilisation d‟un certificat d‟identification. C‟est une relation sûre entre la clé publique et l‟identité de l‟entité. Le destinataire doit être capable d‟identifier l‟expéditeur en contactant un tiers de confiance qui a la responsabilité de signer, délivrer et vérifier la validité des certificats.

La non-répudiation

C‟est le fait qu‟aucun noeud ne pourra nier (désavouer) le fait d‟avoir échanger des informations. Autrement dit, la non-répudiation de l’origine prouve que les données ont été envoyées, et la non-répudiation de l’arrivée prouve qu’elles ont été reçues.

Fraîcheur De Données

Même si la confidentialité et l‟intégrité des données sont assurées, il est nécessaire d‟assurer la fraîcheur de chaque message. Officieusement, la fraîcheur de données suggère que les données soient récentes, et elles s’assurent qu’aucun vieux message n’a été rejoué. Cette condition est particulièrement importante quand il y a des stratégies de partage des clefs utilisées dans la conception. Des clefs typiquement partagées doivent être changées avec le temps. Cependant, cela prend du temps pour de nouvelles clefs partagées d’être propagées au réseau entier. Dans ce cas-ci, il est facile pour l’adversaire d’employer une attaque de rejouer. Pour résoudre ce problème un compteur relatif au temps différent, peut être ajouté dans le paquet pour assurer la fraîcheur de données [23].

Table des matières

INTRODUCTION GENERALE
CHAPITRE I : RCSF et les protocoles de routage et de sécurité dédies
I.1. Introduction
I.2. Réseaux de capteurs sans fil
I.2.1. Définition de RCSF
I.2.2. Architecture physique d’un capteur
I.2.3. Architecture d’un RCSF
I.2.4. Fonctionnement des RCSF
I.2.5. Contraintes de conception des RCSF
I.2.6. Applications des RCSF
I.3. Protocole de routage des RCSF
I.3.1. Définition de routage
I.3.2. Contraintes de routage dans les réseaux de capteurs sans fil
I.3.3. Les critères de performance des protocoles de routage en RCSF
I.3.4. Types de routage
I.3.5. Les protocoles de routage proposé pour les RCSF
I.4. La sécurité dans les RCSF
I.4.1. Exigences en sécurité
I.4.2. Vulnérabilités de la sécurité dans les RCSF
I.4.3. Solutions adaptées aux communications des RCSF
I.5. Conclusion
Chapitre II : Sécurisation et optimisations du protocole AODV
II.1. Introduction
II.2. Le protocole AODV
II.2.1. Présentation
II.2.2. Table de routage
II.2.3. Mécanismes de création des routes
II.2.4. Génération et acheminement des réponses RREP
II.2.5. Les messages « Hello»
II.2.6. Mécanismes de maintenance des routes
II.2.7. Génération et acheminement des erreurs RERR
II.3. Le protocole AODV optimisé pour RCSF
II.3.2. La Table de routage
II.3.3. Maintenance des routes
II.4. Sécurisation des données dans le RCSF
II.4.1. Algorithme de chiffrement symétrique implémenté RC4
II.4.2. Algorithme de chiffrement ECC (Elliptic Curve Cryptography)
II.5. Conclusion
CHAPITRE III : implémentation du protocole OAODV sur capteurs telosb
III.1. Introduction
III.2. Systèmes d’exploitation et langage de programmation utilisés
III.2.1. Le système d‟exploitation TinyOS
III.2.2. Le langage NESC
III.3. Outilles utilisés dans l’implémentation et la simulation
III.3.1. VMware Workstation version 10.0.1
III.3.2. Ubuntu version 14.04
III.3.3. Java Jdk version 1.8.0
III.3.4. Eclipse neon.2 et yeti2
III.3.5. Port série
III.4. Cartes TelosB
III.4.1. Composants du capteur CM5000
III.4.2. Microcontrôleur TI MSP430F1611
III.4.3. Module RF 2.4 GHz IEEE 802.15.4
III.4.4. Les capteurs d‟humidité et de température Sensirion® SHT11
III.4.5. Détecteur de lumière Hamamatsu® S1087 / S1087-01
III.4.6. Interfaces USB
III.4.7. Mémoire flash ST® M25P80
III.4.8. Bottons d‟utilisation
III.4.9. Alimentation du capteur
III.5. Interfaces et composants du NESC utilisés
III.5.1. Initialisation
III.5.2. Compteurs
III.5.3. Emission et réception
III.5.4. Utilisation des LEDs
III.5.5. Lecture des données captées
III.5.6. La communication radio entre les capteurs
III.6. Implémentation des protocoles de routage (AODV et OAODV)
III.6.1. Fonctions principales utilisées
III.6.2. Programmation
III.7. Implémentation des algorithmes de cryptage (RC4 et ECDSA)
III.7.1. Algorithme RC4
III.7.2. Algorithme ECDSA
III.8. Conclusion
CHAPITRE IV : implémentation et résultats
IV.1. Introduction
IV.2. Test et résultats
IV.2.1. Paramètres de test
IV.2.2. Architecture de réseau
IV.2.3. Tests sur le fonctionnement des protocoles de routages
IV.2.4. Tests sur le taux de perte des paquets
IV.2.5. Testes sur l‟effet de la taille de réseau sur la recherche de la route
IV.2.6. Testes sur l‟effet de la taille de réseau sur la consommation de l‟énergie
IV.2.7. Tests sur le fonctionnement des algorithmes de cryptages
IV.3. Conception d’une application Web pour le contrôle de la température
IV.3.1. Langage PHP
IV.3.2. Base des données
IV.3.3. Conception de site
IV.4. Conclusion
CONCLUSION GENERALE ET PERSPECTIVES
BIBLIOGRAPHIE
Résume
Abstract

Télécharger le rapport complet