Système d’exploitation des réseaux de capteurs sans fil

Plusieurs systèmes d’exploitation ont été développés pour répondre aux contraintes particulières des réseaux de capteurs, ils sont les suivants :

a. TinyOS TinyOS est un système d’exploitation open source conçu pour les capteurs sans fils et développé par Université de Berkeley. Il est basé sur une architecture à base de modules. Les composants sont programmés en NesC, un langage de programmation dérivé du C adapté aux faibles ressources physiques des capteurs. Un certain nombre de plateformes sont directement programmables comme par exemple les tmote ou les MicaZ (ces deux modèles sont compatibles avec ZigBee). TOSSIM est un simulateur de capteurs pour les programmes TinyOS, tout programme en NesC peut être compilé de manière à être exécuté dans TOSSIM, ce qui permet de simuler le comportement d‟un ou plusieurs capteurs ainsi de les programmer.

b. Mantis OS Mantis OS (MOS) est un système d‟exploitation multi threading open-source pour les capteurs développés par le MANTIS group à l‟université du Colorado en 2005. MOS est développé en C, langage choisi pour son efficacité et sa portabilité. Il supporte les plateformes de la famille MICA et de la famille Telosb. Il dispose d‟un environnement de développement Linux et Windows.

c. Nano-RK C‟est un système d’exploitation temps réel multitâches préemptif. Il supporte le multi-hoping. Il possède une faible empreinte mémoire, Nano-RK utilise 2 kb de RAM et 18 kb de ROM. Nano-RK fournit des APIs pour la gestion d‟énergie des capteurs.

d. Lite OS Lite OS fournit un environnement comparable à Unix adapté aux capteurs en réseau. Lite OS possède un système de gestion des fichiers et des commandes en mode terminal distante semblable au commandes Unix pour gérer les capteurs. Le noyau supporte le chargement dynamique et l‟exécution multitâche d’applications. Il est basé sur le langage de programmation orienté objet C++ pour le développement des programmes et permettre leur déploiement sur les capteurs.

e. SOS SOS est un système d‟exploitation open-source pour les réseaux de capteurs développés par le laboratoire réseaux et systèmes embarqués de l‟université de Los Angeles, il est basé sur une architecture modulaire. SOS est écrit en langage C, il supporte les plateformes de la famille MICA. Avrora est un simulateur pour les programmes SOS. SOS à l‟avantage de posséder une implémentation complète de la topologie en étoile. En conclusion, TinyOS est le système d‟exploitation le plus utilisé pour les réseaux de capteurs sans fils car il a l‟avantage par rapport à autre systèmes d‟exploitation d‟être écrit dans un langage spécifique optimisé pour les capteurs.

Classification des RCSF

En fonction des exigences imposées par chaque type d‟application, il existe plusieurs critères pour classifier les réseaux de capteurs En effet, pour chaque type d‟application, ces réseaux ont des caractéristiques différentes. Ils se distinguent par le mode d‟acquisition et de livraison des données au puits, la distance entre les noeuds capteurs et le puits, le modèle de mobilité dans le réseau, les capacités des noeuds du réseau, etc.

3. Selon le modèle de mobilité dans le réseau L‟intérêt de la mobilité dans les RCSF est multiple dans la mesure ou les capteurs mobiles peuvent permettre d‟étendre la couverture d‟un réseau ou encore obtenir des résultats plus précis. La classification selon le modèle de mobilité consiste en une combinaison entre la mobilité des noeuds capteurs et celle du puits. Par cette combinaison, nous pouvons distinguer deux grandes catégories de réseaux : réseaux statiques et réseaux dynamiques ou mobiles. On peut par exemple avoir un réseau constitué d‟un ensemble de noeuds capteurs mobiles et d‟un puits fixe. Le but de tels réseaux est la plupart du temps l‟exploration de zones inaccessibles ou dangereuses.

4. Selon les capacités des noeuds du réseau Dans cette classification, on distingue les réseaux homogènes des hétérogènes. Dans un réseau de capteurs homogène, tous les noeuds du réseau sont identiques en termes d‟´énergie et de complexité du matériel. Il est ´évident que les noeuds leaders des clusters sont surchargés avec des taches supplémentaires et nécessaires, comme l‟agrégation des données et la coordination du protocole de routage, par conséquent, leur durée de vie expire avant celle de ses autres noeuds. Pour cela les noeuds tournent le rôle du leader du cluster périodiquement entre elles. Dans le cas d‟un réseau de capteurs hétérogène il y a quelques noeuds sophistiqués qui ont plus de capacité de traitement et de communication que les noeuds normaux. Cela amélioré l‟efficacité énergétique et prolonge la vie de réseau.

Le Protocoles DSR

DSR (Dynamic Source Routing) est basé sur l’utilisation du technique « routage à la source » c’est- à-dire c‟est à la source de déterminer la séquence complète des noeuds selon lesquelles, les paquets de données seront envoyés. Les noeuds n‟ont pas besoin de tables de routage. Les deux opérations de base de DSR sont : la découverte de routes (route discovery) et la maintenance de routes (route maintenance). La découverte de routes se fait par diffusion d‟un paquet requête de route pour identifier la cible. En cas de réussite, le noeud initiateur reçoit un paquet réponse de route qui liste la séquence de noeuds à travers lesquels la destination peut être atteinte. Dès que la destination est localisée, une copie de ce chemin est envoyée dans un paquet réponse de route à l’initiateur. De cette manière, la requête de route est propagée dans le réseau, jusqu’à ce qu’elle atteigne la destination qui va répondre à la source. Afin de réduire le coût et la fréquence de la découverte de routes, chaque noeud garde trace des chemins trouvés à l’aide des paquets de réponses. Ces chemins sont utilisés jusqu’à ce qu’ils soient invalides. Le protocole DSR n’intègre pas l’opération de découverte de routes avec celle de la maintenance, comme le fait les protocoles de routage conventionnels et évite le problème de boucle de routage.

Protocoles de routage Réactifs AODV

L‟AODV (Ad-hocOn-demandDistanceVector) est considéré comme la combinaison de DSR et de DSDV. Il combine les mécanismes de découverte et de maintenance de routes de DSR en y associant le numéro de séquence (pour le maintien de la consistance des informations de routage) et les mises à jour périodiques de DSDV. La découverte de route se fait par diffusion du message RREQ (Route Request). AODV utilise le numéro de séquence pour éviter les boucles et être sûr d‟utiliser les routes les plus récentes (les plus fraîches). Quand un noeud de transit envoi le paquet de la requête à un voisin, il sauvegarde aussi l’identificateur du noeud dans la table de routage à partir duquel la première copie de la requête est reçue. Cette information est utilisée pour construire le chemin inverse. Si un noeud reçoit plusieurs copies d‟un même RREQ, seule la première est conservée. Une fois que le message atteint la destination, elle retransmet un message RREP (Route Reply) vers la source par le chemin inverse. Etant donné que le RREP est envoyé par le même chemin que le RREQ. AODV ne supporte que des liens symétriques. Le protocole de routage AODV n’assure pas l’utilisation du meilleur chemin existant entre la source et la destination mais il ne présente pas de boucle de routage et évite le problème «counting to infinity  » de Bellman-Ford, ce qui offre une convergence rapide quand la topologie du réseau change.

b) Découverte d’une route Un noeud diffuse une requête de route (RREQ) pour connaître la route vers une certaine destination si celle-ci n’est pas connue au préalable, ou si le chemin existant vers la destination a expiré sa durée de vie ou il est devenu défaillant. Le champ numéro de séquence de destination du paquet RREQ, contient la dernière valeur connue du numéro de séquence, recopiée de la table de routage. Si le numéro de séquence n’est pas connu, la valeur nulle sera prise par défaut. Le numéro de séquence source du paquet RREQ contient la valeur du numéro de séquence du noeud source. Après la diffusion du RREQ, la source attend le paquet réponse de route (RREP). Si ce dernier n’est pas reçu durant une certaine période (appelée RREP_WAIT_TIME), la source peut rediffuser une nouvelle requête RREQ. Quand un noeud de transit (intermédiaire) envoie le paquet de la requête à un voisin, il sauvegarde aussi l’identificateur du noeud à partir duquel la première copie de la requête est reçue. Cette information est utilisée pour construire le chemin inverse, qui sera traversé par le paquet réponse de route de manière unicast. Puisque le paquet RREP va être envoyé à la source, les noeuds appartenant au chemin de retour vont modifier leurs tables de routage suivant le chemin contenu dans le paquet de réponse (temps d’expiration, numéro de séquence e prochain saut). Afin de limiter le coût dans le réseau, AODV propose d’étendre la recherche progressivement. Initialement, la requête est diffusée à un nombre de sauts limité. Si la source ne reçoit aucune réponse après un délai d’attente déterminé, elle retransmet un autre message de recherche en augmentant le nombre maximum de sauts.

En cas de non réponse, cette procédure est répétée un nombre maximum de fois avant de déclarer que cette destination est injoignable. A chaque nouvelle diffusion, le champ Broadcast ID du paquet RREQ est incrémenté pour identifier une requête de route particulière associée à une adresse source. Si la requête RREQ est rediffusée à un certain nombre de fois (RREQ_RETRIES) sans la réception de réponse, un message d’erreur est délivré à l’application. La destination renvoie un message RREP, ce message peut donc être acheminé vers la source. Chaque noeud traversé incrémentera le nombre de sauts. Et ajoutera une entrée à sa table pour la destination. Une réponse adéquate peut aussi être donnée par un noeud situé entre la source et la destination. Dans ce cas l’obtention de routes bidirectionnelles est néanmoins possible grâce au drapeau  » Gratuitous RREP ». Le noeud intermédiaire enverra alors en plus un RREP vers la destination. Les noeuds entre le noeud intermédiaire et la destination ajouteront donc à leur table une entrée vers la source du RREQ. Cette disposition permettra à la destination d’envoyer directement des paquets à la source sans devoir procéder à la recherche d’une route.

Conclusion générale

Les réseaux de capteurs sont composés d‟un très grand nombre de dispositifs de communication ultra petits, autonomes avec des ressources de calcul et d‟énergie limitées. Ils sont actuellement considérés comme l‟une des technologies qui bouleverse notre façon de vivre, grâce à leur utilisation dans différents domaines d‟application. Cependant, les réseaux de capteurs sans fil rencontrent plusieurs problèmes qui affectent leur bon fonctionnement dû à leurs caractéristiques ; tels que les limitations de batterie, le type de communication, les environnements hostiles où sont déployés les capteurs ou encore leur faible coût. Dans ce mémoire nous avons proposé un protocole de routage adapté à ce genre de réseaux afin d‟acheminer les données récoltées vers la station de base. Le facteur le plus important qui a été pris en considération c‟est la consommation des ressources, où ces dernières sont considérées comme une ressource critique. Alors l‟algorithme proposé assure aussi une garantie de grande vie de réseau.

L’algorithme proposé a été mise en place en apportant des modifications et des améliorations sur le protocole AODV. Dans le premier chapitre, nous avons présenté les capteurs, leurs composants et leurs classifications, Nous avons discuté également des réseaux de capteurs sans fi, leurs architectures de communication, leurs caractéristiques et leurs domaines d‟applications. Par la suite, nous avons introduire la classification des protocoles de routage utilisés pour les réseaux Ad hoc, leur fonctionnement, en décrivant aussi les contraintes de routage dans les réseaux de capteur. Dans le troisième chapitre, nous avons présenté le protocole AODV et AODV optimisé, qui prend en considération le modèle de trafic de RCSF, la nature du milieu et les contraintes de bande passante … etc. Les résultats obtenus par la comparaison entre ces deux protocoles, montrent l‟efficacité du protocole AODV optimisé proposé pour les RCSF, qui peut assurer une garantie de grande vie de réseau et une exploitable raisonnable des ressources des capteurs, et il permet d‟avoir une consommation d‟énergie plus faible. Enfin, comme perspectives nous envisageons d‟implémenter le protocole de routage AODV optimisé sur des capteurs réels, et développé une solution de sécurité adaptés aux RCSF.