ROSEAU : RObots en réseau

ROSEAU : RObots en réseau Projet LAAS Rapport d étude préliminaire Nicolas PERONY Maître de stage : Rachid Alami LAAS CNRS Groupe RIS Robotique et Interactions

2

Résumé Ce rapport se situe dans le cadre du projet ROSEAU (Robots en réseau), qui vise à étudier les enjeux du déploiement de réseaux communicants de robots, capteurs et relais de communication, dans un environnement sujet à de fortes contraintes d évolution. Les applications sont très diverses, la plupart reposant totalement sur un réseau utilisant une architecture dite ad-hoc (élaborée spécifiquement en fonction des besoins de l application et évoluant dynamiquement pour répondre aux nouvelles contraintes contextuelles). Ce document est une étude préalable au développement et à l implémentation de méthodes et d outils répondant aux contraintes du projet ROSEAU. Nous dresserons ici un premier état de l art des technologies existantes, ceci allant des plate-formes robotiques existant actuellement aux spécifications des protocoles de routage ad-hoc, en passant par les normes de communication sans-fil utilisables dans le cadre du projet. Nous ferons ensuite deux études de scénario, l une dans le cas d une application de recherche et de sauvetage (search & rescue) dans un contexte d accident/catastrophe, la seconde dans le cas de la surveillance active d une zone forestière pour prévenir les risques d incendie. Nous nous pencherons également sur d autres applications potentielles des réseaux ad-hoc de robots et de capteurs, avant de présenter des interrogations et des problèmes connexes soulevés par les études réalisées dans le domaine.

Table des matières I État de l art 4 1 Historique des réseaux sans-fil 5 2 Notions 6 2.1 Informatique pervasive...................... 6 2.2 Réseaux maillés : Mesh networks................ 7 3 Les réseaux MANET 9 3.1 Présentation............................ 9 3.2 Contraintes, limitations...................... 10 3.3 Les enjeux du routage dans les réseaux ad-hoc......... 11 3.3.1 La conception des stratégies de routage......... 11 3.3.2 Notions importantes................... 12 3.4 Différents protocoles de routage pour les réseaux ad-hoc.... 14 3.4.1 Les protocoles à routage proactif............ 14 3.4.2 Les protocoles à routage réactif............. 21 3.5 Hétérogénéité et hiérarchisation des réseaux ad-hoc...... 25 3.6 La gestion de l énergie dans les réseaux ad-hoc......... 28 3.7 La couche MAC dans les réseaux ad-hoc............ 30 3.7.1 Le problème des stations cachées et la solution RTS/CTS 33 3.7.2 Le problème des stations exposées............ 33 3.7.3 Un mécanisme de priorités pour 802.11......... 34 3.7.4 Routage avec Qualité de Service............. 35 4 Technologies de communication sans-fil 37 4.1 La norme IEEE 802.15.4, ou ZigBee............... 37 4.1.1 Présentation........................ 38 4.1.2 Le routage dans les réseaux ZigBee........... 39 4.2 La norme IEEE 802.15.1, ou Bluetooth............. 41 4.3 La norme IEEE 802.11, ou Wi-Fi................ 42 4.4 Intérêts respectifs des technologies étudiées........... 42 2

5 Réseaux de capteurs 45 6 Réseaux de robots 48 II Scénarios d étude 50 7 Scénario de search & rescue 51 7.1 Contexte.............................. 51 7.2 Aspect matériel.......................... 52 7.3 Aspect réseau........................... 57 8 Scénario de surveillance active 60 8.1 Contexte.............................. 60 8.2 Aspect matériel.......................... 61 8.3 Aspect réseau........................... 65 9 Autres scénarios 69 9.1 Exploration et surveillance sous-marines............ 69 III Champs de recherche et interrogations 71 9.2 Simulation de réseaux...................... 72 9.3 Le problème des interférences radio............... 73 9.4 Localisation relative et absolue de capteurs........... 74 9.5 Utilisation de TCP dans les réseaux ad-hoc........... 75 9.6 Sécurité dans les réseaux ad-hoc................. 75 Conclusion 77 Bibliographie 78 3

Première partie État de l art 4

Chapitre 1 Historique des réseaux sans-fil Les bases de télécommunications modernes sont jetées en 1832, lorsque le baron Paul Schilling Von Canstadt présente au tsar Nicolas 1 er le premier prototype de télégraphe électrique, amélioré ensuite par le peintre américain Samuel Morse en 1837. En 1893, le croate Nikola Tesla s appuie sur les travaux du physicien Maxwell et montre que des courants à haute fréquence peuvent être utilisés pour véhiculer des informations à distance. L ingénieur russe Popov améliore le système en le dotant d une antenne en 1894, et c est le physicien italien Guglielmo Marconi qui met au point le premier appareil de télégraphie sans fil en 1896. En décembre 1901, une communication radio relie Terre-Neuve aux îles Cornouaille, distantes de 3400 km. Une communication TSF émise depuise le Titanic et reçue par le navire Carpathia en 1912 sauve 705 passagers. Il faudra attendre 1970 pour que les premières communications numériques transitent par les ondes radio, lorsque l équipe hawaïenne de Norman Abramson met au point le protocole Aloha, assurant des transmissions de paquets par ondes radio UHF entre les îles de l archipel. En 1973, la DARPA (Defense Advanced Research Projects Agency) américaine lance le projet PRNet (Packet Radio Networks), afin d étudier les communications radio en mode paquet dans les réseaux autonomes non-centralisés : les premiers réseaux ad-hoc. 5

Chapitre 2 Notions Il est important tout d abord de définir le cadre de travail du projet, et par-là les notions importantes pour la manipulation des problèmes soulevés. Ces notions essentielles sont : l informatique pervasive (pervasive computing) et l architecture maillée d un réseau dit mesh network. 2.1 Informatique pervasive Pervasive computing, ou ubiquitous computing : l informatique comme partie intégrante de notre environnement. L informatique dite pervasive intègre la notion de traitement de l information à l environnement courant, sans considérer les ordinateurs (et dérivés) comme des unités de calcul à part. Les termes désignant cette technologie sont également Things That Think et Everyware. Les partisans de cette vision de l informatique espèrent qu à terme l informatique integrée dans l environnement et dans les objets de tous les jours permettra aux utilisateurs d interagir avec les machines et le traitement de l information en général de façon plus facile et plus naturelle que cela n est possible maintenant, et ce quelles que soient les circonstances ou le lieu dans lequel se trouve l utilisateur. Ce concept a été initié dès 1988 par Mark Weiser, chercheur au Xerox PARC (CA, USA). Weiser fut influencé par le romancier Philip K. Dick dans son roman Ubik, qui envisageait un futur où tout les objets, des poignées de portes aux distributeurs de boissons, étaient intelligents et reliés entre eux. On peut trouver aujourd hui de nombreux exemples de cette technologie, notamment dans toutes les applications reliées à la domotique, où c est l environnement d un foyer qui est assimilé à un réseau intelligent et communicant. La société Ambient Devices 1, par exemple, commercialise des objets 1 http ://www.ambiantdevices.com 6

tels qu un globe lumineux qui informe des variations du marché des changes, ou un cube lumineux assez similaire changeant de couleur en fonction de la météo prévue. Ces objets reçoivent l information d un réseau sans-fil relié à l Internet, ce qui en fait des passerelles d information totalement integrées à l environnement quotidien. Il existe encore beaucoup d autres exemples de l intégration croissante du concept d informatique pervasive dans la société actuelle, et il est intéressant de constater que le fait d implanter des capteurs au sein d un environnement naturel (tel qu une forêt), ou des robots qui agissent de façon autonome dans notre environnement (même une situation de crise) pour solutionner le problème posé par le contexte, sont un bon exemple d informatique pervasive. 2.2 Réseaux maillés : Mesh networks Le concept du Mesh networking s oppose à celui des réseaux centralisés classiques : les réseaux maillés sont un moyen de transmettre de l information, des données et des instructions entre les entités constituantes du réseau, les nœuds (nodes). Un réseau maillé permet des connexions/déconnexions continues et une reconfiguration constante en utilisant le système de «sauts»(hops) de nœud en nœud jusqu à ce qu une connexion puisse être établie. Les réseaux maillés sont auto-régénérants : le réseau reste fonctionnel dans le cas où un nœud tombe en panne ou si une connexion devient inutilisable. Le réseau résultant est très fiable est robuste, et s appuie sur des nœuds à faible coût pour convoyer de l information pouvant nécessiter une grande quantité de ressources et des contraintes de qualité de service (Quality of Service, QoS). Ce concept est utilisé par exemple dans le projet de PC à 100 dollars du MIT, en vue de développer une infrastructure robuste et économique pour les élèves qui utiliseront ces terminaux. La technologie qui nous intéresse ici est celle des réseaux maillés sans-fil (Wireless Mesh Networks), en d autres termes les réseaux sans-fil implémentés sur l architecture d un LAN (Local Area Network). Ce type de réseau offre une très grande modularité et souplesse d utilisation, et présente le grand avantage de pouvoir s étendre sur une bien plus grande surface (notamment sur des terrains accidentés et difficiles d accès) qu un réseau centralisé classique, puisque pour être connecté au réseau un nœud a seulement besoin d être à portée d un autre nœud. Ce type de réseau peut inclure des stations fixes ou mobiles (c est le cas des MANET, dont le fonctionnement sera décrit plus loin). Les applications sont diverses et peuvent inclure des communications en environnements difficiles, dans des tunnels ou des oléoducs, jusqu à la surveillance de champs de bataille ou 7

d exploitations agricoles. Le choix des technologies radio est ici crucial : dans un réseau traditionnel où chaque client se connecte à un point d accès unique, chaque station doit partager une certaine quantité de bande passante disponible. Ici, étant donné que chaque nœud se connecte uniquement aux nœuds qui lui sont attenants, plus il y a de nœuds dans le réseau plus la bande passante disponible est importante, à condition que le nombre de sauts dans chaque transmission reste faible. Les réseaux maillés, et principalement les réseaux maillés sans-fil, sont donc très adaptés au cadre de communication requis par les applications du projet ROSEAU. 8

Chapitre 3 Les réseaux MANET 3.1 Présentation Les réseaux ad-hoc (en latin, qui va vers ce vers quoi il doit aller, c est-à-dire formé dans un but précis ) sont des réseaux sans-fil capables de s organiser sans infrastructure définie au préalable. Lorsque ces les nœuds de ces réseaux sont mobiles, ils prennent le nom de MANet (Mobile Ad-Hoc Networks). Ils se différencient notablement des réseaux traditionnels, construits sur un principe centralisé, en mode architecture (cf. Fig. 3.1). Fig. 3.1 Principe de l architecture d un réseau ad-hoc Ces réseaux s appuient sur la notion de réseau maillé évoquée précédemment, incluant de plus une architecture formée à la volée, pour répondre aux contraintes de l application présente. L étape essentielle de la constitution d un réseau ad-hoc est celle du routage : chaque nœud du réseau, pour communiquer directement avec son ou ses voisins, doit au préalable se situer par rapport 9

à ces voisins, et construire des routes de communication : c est le rôle du protocole de routage. 3.2 Contraintes, limitations Les réseaux MANET sont avant toute chose des réseaux basés sur la technologie radio, avec tous les aléas de transmission qu elle comporte. Le protocole IEEE 802.11 (dans le cas des réseaux basés sur la norme Wi-Fi) et ses dérivés se comporte pour la couche supérieure comme le protocole Ethernet, mais il faut prendre en compte les caractéristiques qui lui sont propres : le taux d erreur par bit est bien plus important dans l air, ceci étant du aux fluctuations naturelles du milieu : si dans un protocole Ethernet classique le taux d erreurs bit est de l ordre de 10 12 (une erreur binaire tous les 10 12 bits reçus), en milieu aérien il peut atteindre des valeurs supérieures à 10 6. Il faut donc inclure des mécanismes de correction d erreur performants, ce qui génère un overhead important. la propagation radio dans l air est bien plus sujette aux contraintes de l environnement que la propagation d un signal sur un réseau filaire : le simple fait de fermer une fenêtre dans un bâtiment peut suffire pour altérer grandement la qualité d un lien, voire le couper. Il en va de même pour un déplacement d un des nœuds de l ordre de quelques mètres dans le cas de terminaux mobiles. Il est donc important de définir des protocoles de routage adaptés et robustes (cf. 3.4), ainsi que des contraintes de qualité de service sur les transmissions (cf. 3.7.4). par définition, le médium radio est partagé entre tous les clients qui l exploitent : lorsqu un nœud émet un signal, tous les nœuds se situant dans son périmètre d émission ne pourront pas émettre, sous peine de provoquer des interférences brouillant le signal. Si l on considère cette contrainte dans un contexte mobile, on se rend compte que la modification de l environnement immédiat d un mobile peut faire fortement varier la qualité des liens de ce mobile avec les nœuds qui lui sont voisins. Les réseaux MANET sont donc contraints par la versatilité et la bande passante limitée du médium radio qu ils utilisent, des délais et du volume de données supplémentaires générés par les protocoles d accès au médium et de routage (couches 2 et 3 du modèle OSI), ainsi que de la difficulté d implémenter des techniques de détection de collision efficaces. On peut ajouter à ces contraintes réseau deux limitations supplémentaires qui seront 10

considérées plus loin dans ce rapport : tout d abord, les réseaux ad-hoc sont en général confrontés à des ressources énergétiques limitées, ce qui amène en mettre en place des politiques efficaces de gestion de l énergie sur les protocoles de routage (cf. 3.6). Ensuite, les réseaux ad-hoc possèdent de par leur nature une sécurité physique très limitée, d autant plus qu il n existe pas d architecture centralisée pour restreindre l accès au réseau. Ceci est à considérer dès lors que l on met en place des réseaux véhiculant des données sensibles, et fera l objet d une interrogation en fin de document (cf. 9.6). 3.3 Les enjeux du routage dans les réseaux ad-hoc On peut définir le routage en général comme étant la méthode d acheminement d une information ou d un produit à la bonne destination à travers un réseau de connexion donné. L enjeu principal du routage consiste, pour un réseau dont les nœuds et les arcs les reliant possèdent chacun des capacités propres et des contraintes spécifiques, en la détermination du chemin d acheminement optimal des paquets contenant des informations ou des produits. Ceci doit être fait en respectant un certain critère de performance, généralement désigné comme le coût de routage, qui peut être le temps nécessaire à l acheminement, la dépense énergétique engendrée, la minoration du risque de perte ou d endommagement, ainsi que de nombreux autres facteurs et leurs combinaisons : globalement, le coût de routage est la dépense en termes de capacités nominales et de réserve en ressources sur le réseau. Enfin, il peut y avoir une notion de qualité de service qui intervient : on désire souvent que l acheminement soit effectué avec succès, même en dépit des éventuelles pannes pouvant survenir sur les différents arcs et nœuds. Par exemple, en supposant que les coûts des liens sont identiques, le chemin indiqué dans la figure 3.2 est le chemin optimal reliant le nœud source et le nœud destination. Une bonne stratégie de routage utilise ce chemin dans le transfert des données entres les deux nœuds. 3.3.1 La conception des stratégies de routage L étude et la mise en œuvre d algorithmes de routage pour assurer la connexion des réseaux ad hoc au sens classique du terme (n importe quel nœud doit pouvoir communiquer avec n importe quel autre) est un problème complexe. L environnement est dynamique et évolue donc au cours du temps, la topologie du réseau peut changer fréquemment. Il semble donc important 11

Fig. 3.2 Un chemin optimal entre deux nœuds du réseau que toute conception de protocole de routage doive étudier les problèmes suivants : la minimisation de la charge du réseau. L optimisation de l utilisation des ressources disponibles renferme deux sous-problèmes : l évitement des boucles de routage, et l empêchement de la concentration du trafic autour de certains nœuds ou liens. la fourniture d un support pour pouvoir effectuer des communications multi-points fiables : le fait que les chemins utilisés pour router les paquets de données puissent évoluer ne doit pas avoir d incidence sur le bon acheminement des données. L élimination d un lien, pour cause de panne ou pour cause de mobilité devrait, idéalement, augmenter le moins possible le temps d acheminement. l assurance d un routage optimal : la stratégie de routage doit créer des chemins optimaux et pouvoir prendre en compte différentes métriques de coûts (bande passante, nombre de liens, ressources du réseau, délais de bout en bout, etc.). La maintenance de ces chemins optimaux doit être ensuite assurée avec un coût le plus faible possible. La minimisation du temps de latence : l acheminement effectif des données doit toujours se faire en considérant le facteur temporel. Plus la taille du réseau augmente, plus la prise en compte de ce facteur doit être importante dans la conception des stratégies de routage. 3.3.2 Notions importantes 3.3.2.1 Multi-saut (Multi hoping) : Les stratégies de routage utilisées dans les réseaux ad hoc sont caractérisées par le fait de pouvoir acheminer les paquets de données sans l aide des sta- 12

tions de base utilisées dans un modèle d infrastructure centralisée. Dans le modèle classique, la communication entre deux nœuds est faite en utilisant les stations de base et le réseau filaire : aucune unité mobile n est utilisée comme routeur intermédiaire, le modèle cellulaire est dit alors single hop (le nombre de routeurs mobiles intermédiaires est nul). Dans un modèle dit, par opposition, multi hop, plusieurs nœuds peuvent participer au routage. C est le cas des réseaux ad-hoc, dans lesquels chaque nœud fait office de routeur intermédiaire. 3.3.2.2 Inondation : L inondation, ou diffusion pure, consiste à faire propager un paquet (de données ou de contrôle) dans le réseau entier. Un nœud qui initie l inondation envoie le paquet à tous ses voisins directs. De même, si un nœud quelconque du réseau reçoit le paquet, il le rediffuse à tous ses voisins. Ce comportement se répète jusqu à ce que le paquet atteigne tous les nœuds du réseau. Les nœuds peuvent être amenés à appliquer durant l inondation des traitements de contrôle dans le but d éviter certains problèmes tels que le bouclage et la duplication des messages. Le mécanisme d inondation est utilisé généralement dans la phase initiale de découverte des routes, lorsque le nœud source ne connaît pas encore la localisation exacte de la destination. L inondation est très coûteuse, notamment lorsque le réseau est volumineux : elle engendre des problèmes de latence, de surcharge des nœuds, etc. C est pour cela les protocoles de routage essaient de minimiser au maximum la propagation des paquets inondés en rajoutant d autres paramètres de diffusion. La figure 3.3 illustre le principe du mécanisme d inondation. Fig. 3.3 Le mécanisme d inondation 13

3.4 Différents protocoles de routage pour les réseaux ad-hoc En 1997, l IEEE a standardisé le protocole d accès au médium radio 802.11 [1] visant à assurer la communication entre ordinateurs personnels utilisant les ondes radio pour communiquer. Il existe aujourd hui plus de 70 projets de normalisation pour des protocoles de routage de paquets dans les réseaux maillés et plus particulièrement les réseaux ad-hoc. Le groupe MANET de l IETF (Internet Engineering Task Force) tente actuellement de standardiser un ou plusieurs protocoles de routage pour les réseaux ad-hoc. Parmi toutes les propositions, deux approches sont proposées : le routage proactif, et le routage réactif. Les protocoles proactifs établissent les routes à l avance en se basant sur un échange de paquets entre les nœuds pour connaîtres la topologie du réseau, tandis que les protocoles réactifs établissent les routes à la demande pour les besoins d une communication donnée. 3.4.1 Les protocoles à routage proactif L approche proactive est la plus proche des protocoles de routage classiques utilisés dans les réseaux filaires : chaque noeud du réseau dispose d une table de routage indiquant, pour chaque destination du réseau, le routeur suivant que le paquet doit emprunter. 3.4.1.1 Vue rapide de l architecture de routage dans l Internet : Dans l architecture Internet et celle des réseaux filaires classiques en général, la maintenance des tables de routage est assurée par une combinaison de protocoles : entre deux terminaux d un même domaine, un protocole de type état de lien (cf. plus bas) comme OSPF (Open Shortest Path First) [2] établit la notion de qualité de lien. Cet attribut est généralement exprimé comme l inverse de la bande passante du lien considéré et, communiqué à tous les routeurs du domaine, leur permet ainsi de représenter par un graphe la cartographie complète du réseau afin de calculer l arbre des plus courts chemins reliant une destination à une autre, par exemple par l algorithme de Dijkstra. Entre domaines, le routage est assuré par le protocole BGP (Border Gateway Protocol) [3], de type vecteur de distance (cf. plus bas) : il repose sur la communication entre les routeurs des chemins préconisés pour atteindre chaque domaine ainsi que du coût associé à ce chemin (exprimé en hops). 14

L utilisation conjointe de ces protocoles est efficace et viable dans le cas d Internet, mais elle nécessite d être adaptée dans le cas des réseaux ad-hoc : en effet, la mise à jour des tables de routage requiert un temps et un volume de données échangées important. Si l approche est valable dans le cas d un réseau à topologie fixe (mise à jour périodique de fréquence faible), elle ne l est plus dans le cas des réseaux ad-hoc. 3.4.1.2 Deux approches : Link State et Distance Vector : On distingue deux méthodes principales de routage proactif : la méthode Etat de Lien (Link State) et la méthode Vecteur de Distance (Distance Vector). Les deux méthodes exigent une mise à jour périodique des données de routage qui doit être diffusée par les différents nœuds de routage du réseau. Les algorithmes de routage basés sur ces deux méthodes utilisent la même technique, dite des plus courts chemins, pour permettre à un hôte donné de trouver le prochain hôte pour atteindre la destination en utilisant le trajet le plus court existant dans le réseau. Généralement le calcul du plus court chemin entre deux stations est basé sur le nombre de sauts que comportent les différents chemins qui existent entre les deux stations. Mais on peut aussi associer des coûts aux liens de communication, pour caractériser d autres attributs comme l énergie disponible, la bande passante du lien, son taux d utilisation, etc. Ces coûts viendront ensuite pondérer le calcul du chemin optimal (qui n est donc pas nécessairement le plus court) avec prise en compte des nouvelles contraintes. L approche Etat de Lien : Dans l approche de routage Link State, chaque nœud de routage maintient sa propre vision de la topologie du réseau. Pour que cette vision soit à jour, chaque nœud diffuse périodiquement (en général par inondation) l état des liens de ses voisins à tous les nœuds du réseau. Cela est fait aussi quand il y a un changement d état de liens. Un nœud qui reçoit des informations concernant l état des liens d un autre nœud met à jour sa vision de la topologie du réseau et applique un algorithme de calcul des chemins optimaux afin de choisir le nœud suivant pour une destination donnée. L algorithme le plus couramment utilisé dans ce type de calcul est l algorithme de Dijkstra. Il est à noter que pour que le calcul du chemin optimal ait un sens, il faut que les nœuds du réseau disposent tous des mêmes mises à jour de routage au même moment ; dans le cas contraire, et si l évolution du réseau est forte, le chemin d un paquet peut devenir erratique et désordonné. L approche Vecteur de Distance : Dans l approche de routage Distance Vector, tous les nœuds de routage calculent la distance qui les séparent des 15

autres nœuds du réseau et stockent ces informations dans une table. Chacun d eux diffuse ensuite cette table à ses voisins. En se basant sur les informations reçues par ses voisins, un nœud de routage applique l algorithme de distribué de Bellman-Ford [4] pour trouver le chemin le plus court vers n importe quelle destination. Le processus de calcul se répète dès qu il y a un changement de la distance minimale séparant deux nœuds, et cela jusqu à ce que le réseau atteigne un état stable. La principale différence avec une approche Link State est que les nœuds ici n ont pas une vision globale de la topologie du réseau. Le problème de performance majeur de l algorithme de Bellman-Ford est qu un changement brusque de topologie du réseau entraîne un grand nombre de mises à jour des tables individuelles de routage, et le temps nécessaire à la digestion d une telle modification par les tables de routage est important. Un autre problème de cet algorithme est l absence de coordination entre les nœuds dans les modifications des tables de routage qui peuvent être faites en se basant sur des données erronées : on parle de boucle de routage (routing loop) lorsqu un paquet n arrive jamais à destination car il est redirigé sans cesse vers une boucle infinie. Dans un contexte ad-hoc, ces inconvénients sont très pénalisants, et le principe de l approche Link State est en général favorisé. Cependant, cela exige que chaque nœud conserve une version à jour de la topologie complète du réseau, ce qui nécessite une allocation mémoire plus importante et un grand nombre d échange de données de contrôle dans le cas de réseaux très dynamiques (typiquement, les MANET). Les protocoles de routage proactifs rassemblent les idées des deux approches présentées, en tentant de les adapter au contexte d environnements mobiles. On exposera ici les principaux protocoles de routage à mécanisme proactif reconnus par l IETF, en terminant par le protocole OLSR qui est en cours de standardisation par l IETF et d adoption par la communauté scientifique et les industriels. 3.4.1.3 Le protocole FSR (Fisheye State Routing) : Ce protocole est basé sur l utilisation de la technique oeil de poisson, proposée par Kleinrock et Stevens [5] et adaptée au routage dans les réseaux informatiques [6]. Cette approche considère qu un oeil de poisson capture avec d autant plus de précision les points dans son champ de vision qu ils sont proches du point focal. Dans le contexte du routage, l approche fisheye consiste, pour un nœud considéré comme le point focal (le centre du plan), à diminuer la fréquence 16

de rafraîchissement de la route vers un nœud en fonction de la distance qui sépare ce nœud du centre. Le calcul de la distance peut se baser sur la mesure du nombre de sauts séparant les deux nœuds, ou sur une localisation géographique (type GPS par exemple), procurant une information rigoureusement plus précise mais pas nécessairement plus utile au point de vue routage (deux nœuds séparés de quelques mètres peuvent avoir plus de difficultés à maintenir un lien que deux autres séparés de plusieurs dizaines de mètres). La variation de la fréquence de mise à jour des routes est effectuée en utilisant des périodes différentes de rafraîchissement pour les entrées de la table de routage, en considérant l attribut distance qui leur est associé : les entrées qui correspondent aux nœuds les plus proches sont envoyées aux voisins avec une fréquence élevée, et vice-versa. La figure 3.4 illustre ce fonctionnement. Fig. 3.4 La technique fisheye On utilise ici une vue globale de la topologie du réseau, qui présente l avantage de l absence d inondation dans la recherche de route. 3.4.1.4 Le protocole DSDV (Dynamic Destination-Sequenced Distance Vector) : Ce protocole, utilisant l algorithme de routage dit de Perkins, est appelé Vecteur de Distance à Destination Dynamique Séquencée ou DSDV [7]. Il est basé sur l idée classique de l algorithme distribué de Bellman-Ford [4] en rajoutant quelques améliorations. Chaque nœud contient une table de routage comportant : 17

toutes les destinations possibles. le nombre de sauts nécessaire pour atteindre chaque destination. Le numéro de séquence (SN, Sequence Number) : pour chaque nœud i, le numéro de séquence de la destination j est associé à chaque entrée de distance D i jk, pour chaque voisin k. Le NS est utilisé pour faire la distinction entre les anciennes et les nouvelles routes, ce qui évite la formation des boucles de routage. Afin de maintenir la validité des tables de routage dans une topologie en évolution constante et rapide, chaque nœud du réseau transmet périodiquement sa table de routage à ses voisins directs. Le nœud peut aussi transmettre sa table de routage si le contenu de cette dernière subit des changements significatifs par rapport au dernier contenu envoyé : la transmission est alors dite event-driven. Ces évenements peuvent être l apparition d un nœud, la détection d un nouveau voisin, etc. La mise à jour doit permettre à une unité mobile de pouvoir localiser, dans la plupart des cas, une autre unité du réseau. La mise à jour de la table de routage peut se faire de deux façons : complète ou incrémentale. Lors d une mise à jour complète, la station transmet la totalité de la table de routage aux voisins, ce qui nécessite l envoi de plusieurs paquets de données ; tandis que lors d une mise à jour incrémentale, seules les entrées ayant subi un changement par rapport à la dernière mise à jour sont transmises. On utilisera les mises à jour incrémentales dans les réseaux présentant une topologie relativement stable (et éventuellement une faible bande passante), et les mises à jour complètes dans les réseaux à topologie très dynamique (et éventuellement disposant d une large bande passante). Un paquet de mise à jour contient : le nouveau numéro de séquence incrémenté, du nœud émetteur Et pour chaque nouvelle route : l adresse de la destination. le nombre de sauts séparant le nœud de la destination. le numéro de séquence (des données reçues de la destination) tel qu il a été estampillé par la destination. Les données de routage reçues par un nœud sont comparées avec les données déjà dans la table : la route utilisée sera celle qui aura le plus grand numéro de séquence (donc la plus récente). Si deux routes portent le même numéro de séquence, la route utilisée sera celle qui possède la meilleure métrique (dans le cas du calcul du plus court chemin, la métrique sera le nombre de sauts du chemin). Ensuite les métriques des routes sont incrémentées (puisque le récepteur représente un nœud, donc un saut supplémentaire dans le chemin), et les modifications faites sur les données de routage locales sont diffusées à l ensemble courant des voisins. Lorsqu un lien est rompu, sa métrique est fixée à une valeur infinie, c est-à-dire supérieure à la valeur 18

maximum permise. L inconvénient de DSDV est qu un nœud doit attendre de recevoir les mises à jour d une destination, ce qui rend le protocole relativement lent. De plus, de par son caractère proactif, il génère un surplus de données de contrôle, peu appréciable dans les réseaux sujets à congestion. 3.4.1.5 Le protocole OLSR : Les spécifications complètes du protocole par l IETF sont disponibles en ligne sous forme de RFC 1. OLSR est un protocole basé sur une approche Link State, très adapté aux réseaux larges et denses : plus le réseau sera dense et plus OLSR sera avantageux par rapport à un protocole à état de liens classique, de par ses optimisations dans le processus d inondation. Chaque nœud maintient une table de routage complète, comprenant une entrée pour tous les autres nœuds du réseau. OLSR est basé sur UDP, et nécessite que tous les nœuds soient sur le même sous-réseau IP. OLSR utilise deux types de paquets de contrôles : les paquets Hello et les paquets TC (Topology Control). Les paquets Hello sont utilisés pour construire le voisinage d un nœud, ainsi que pour déterminer les relais Multipoint (MPR, Multi-Point Relays) qui lui sont affectés. Les MPR sont des nœuds choisis qui sont les seuls à expédier des messages de diffusion pendant le processus d inondation. Cette technique réduit sensiblement la surcharge due aux messages par rapport à un mécanisme classique d inondation, où chaque nœud retransmet chaque message reçu au moins une fois. De plus, dans OLSR, l information d état de lien est produite seulement par ces MPR, ce qui constitue une deuxième optimisation en réduisant au minimum le nombre des messages de contrôle inondés dans le réseau. Enfin, un nœud défini comme MPR rapporte uniquement des informations d état de lien entre lui-même et ses sélecteurs. Les MPR d un nœud sont choisis comme étant l ensemble des voisins proches (à un saut) de ce nœud lui permettant d atteindre tous ses voisins à 2 sauts. Le problème de la sélection des MPR par un nœud est en réalité complexe (NP-complet), qui revient à trouver un ensemble dominant dans un graphe (ensemble de nœuds tel que tout sommet du graphe est soit dans l ensemble, soit voisin d un nœud de l ensemble). Il ne sera pas explicité ici ; on peut en voir un exemple d application en figure 3.5. Ici, N(u) est l ensemble des voisins à un saut de u. On remarque que a est nécessairement MPR de u car il est le seul moyen d atteindre f en deux 1 http ://tools.ietf.org/html/rfc3626 19

Fig. 3.5 La sélection des MPR sauts. Revenons sur les deux types de message de contrôle : 1. les messages Hello : Ces messages sont transmis à tous les voisins (par le biais d une adresse de broadcast) à intervalle régulier. Ils contiennent des informations sur les voisins connus et létat des liens avec ceux-ci. Leur utilité est donc de permettre la découverte de l ensemble du réseau. Ils transmettent également l état et le type de lien (asymétrique, symétrique ou MPR) entre l expéditeur et chaque nœud voisin. Enfin, ils spécifient le MPR choisi par l expéditeur. 2. les Messages TC (Topology Control) : Les messages TC sont émis seulement par les MPR, et permettent à chacun d entre eux de transmettre la liste de ses voisins qui l ont choisi comme MPR. Ces messages comportent un champ ANSN (Advertised Neighbor Sequence Number), qui est un entier incrémenté à chaque changement de topologie. Il permet de ne pas tenir compte des informations obsolètes, pour tenir les tables le plus à jour possible. A partir des informations transmises par les paquets de contrôle, chaque nœud calcule une route vers chacun des autres nœuds en utilisant un algorithme du plus court chemin (ici, Dijkstra). A noter qu il existe un protocole proactif assez proche de OLSR actuellement en cours d étude par l IETF, dénommé TBRPF (Topology Broadcast Based on Reverse-Path Forwarding). TBRPF utilise l algorithme de Dijkstra pour la détermination du plus court chemin, et peut prendre en compte la qualité du lien considéré, par exemple la puissance du signal reçu. 20

L une de ses particularités est de se décomposer en deux modules distincts : l un pour la découverte des voisins, et l autre pour le routage, ce qui le rend moins gourmand en termes de calcul et donc d énergie utilisée par le CPU/microcontrôleur. Il possède aussi la caractéristique de ne communiquer que les modifications de routes par rapport à la configuration précédente, ce qui le rend plus économe également en terme de consommation d énergie par émission de paquets. Ce protocole, bien que moins mature qu OLSR ou AODV, offre des performances sensiblement supérieures RFC 2 dans des environnements à faible mobilité. 3.4.2 Les protocoles à routage réactif Le routage réactif repose sur un mécanisme à la demande : les routeurs ne stockent aucune information sur les routes tant que ces routes ne supportent pas de communication active. C est seulement lorsqu un nœud désire communiquer avec un autre qu une requête de recherche de route est lancée. Ce mécanisme offre l avantage de ne pas encombrer le réseau avec des messages de maintenance de route inutiles lorsque les routes sont inactives. En revanche, les paquets mettent un temps plus long à être acheminé en général, car d une part il faut compter le temps d établissement de la route, celui-ci pouvant être elevé lorsque le réseau est chargé ou lorsque le nœud destinataire est à une distance importante, et d autre part, en fonction du protocole de routage employé, la route utilisée ne sera pas nécessairement optimale en terme de distance comme en terme de bande passante disponible. On exposera ici les deux principaux protocoles de routage à mécanisme réactif reconnus par l IETF, en terminant par le protocole AODV qui est en cours de standardisation par l IETF et d adoption par la communauté scientifique et les industriels. 3.4.2.1 Le protocole DSR (Dynamic Source Routing) : Le protocole DSR, appelé aussi Routage à Source Dynamique, est basé sur l utilisation de la technique routage source. Dans cette technique, la source des données détermine la séquence complète des nœuds à travers lesquels les paquets de données seront envoyés. Afin d envoyer un paquet de données à un autre nœud, l émetteur construit une route source et l inclut en tête du paquet. La construction se fait en spécifiant l adresse de chaque nœud à travers lequel le paquet va passer pour atteindre la destination. Par la suite, l émetteur transmet le paquet, à l aide de son interface, au premier 2 http ://tbrpf.erg.sri.com/docs/ns2-comp5.ppt 21

nœud spécifié dans la route source. Un nœud qui reçoit le paquet, et qui est différent de la destination, supprime son adresse de l entête du paquet reçu le transmet au nœud suivant identifié dans la route source. Ce processus se répète jusqu à ce que le paquet atteigne sa destination finale. L opération de base du protocole DSR est la découverte de routes : elle permet à n importe quel nœud du réseau de découvrir dynamiquement un chemin vers un nœud quelconque du réseau. Un nœud initiateur de l opération de découverte diffuse un paquet requête de route qui identifie la destination. Si l opération de découverte est réussite, l hôte source reçoit un paquet réponse de route qui liste la séquence de nœuds à travers lesquels la destination peut être atteinte. En plus de l adresse de la source, le paquet requête de route contient un champ enregistrement de route, dans lequel est accumulée la séquence des nœuds visités durant la propagation de la requête de route dans le réseau (figure 3.6). Le paquet requête de route contient aussi un identificateur unique de la requête. Dans le but de détecter les duplications de réception de la requête de route, chaque nœud du réseau maintient une liste de couples {adresse de la source, identificateur de requête} des requêtes récemment reçues. Lors de la réception d un paquet requête de route par un nœud p du réseau, le traitement suivant est effectué : dans le cas où le couple {adresse de l initiateur, identificateur de requête} du paquet reçu existe déjà dans la liste des requêtes récemment reçues, le paquet est ignoré. Dans le cas contraire : si l adresse de p existe dans le champ enregistrement de route du paquet de la requête, le paquet est ignoré. si l adresse de p est la même que l adresse de la destination, l enregistrement de route (contenu dans le paquet de la requête) contient le chemin à travers lequel le paquet de la requête est passé avant d atteindre le nœud p. Une copie de ce chemin est envoyée dans un paquet réponse de route à l initiateur ( figure 3.6. sinon, l adresse de p est rajoutée dans l enregistrement de route du paquet reçu, et le paquet est rediffusé. De cette manière, la requête de route est propagée dans le réseau, jusqu à ce qu elle atteigne l hôte destination qui va répondre à la source. Le fait d ignorer la requête dans le cas où l adresse du récepteur existe dans l enregistrement de route garantit que la propagation d une même requête ne peut pas se produire cycliquement à travers des boucles de nœuds (route looping). 22

Fig. 3.6 Le processus de decouverte de chemins de DSR 3.4.2.2 Le protocole AODV (Ad-Hoc On-Demand Distance Vector) Les spécifications complètes du protocole par l IETF sont disponibles en ligne sous forme de RFC 3. Le protocole AODV représente essentiellement une amélioration, dans le contexte réactif, de l algorithme DSDV présenté en 3.4.1.4. Il réduit le nombre de diffusions de messages en créant les routes uniquement sur demande, contrairement au DSDV qui maintient la totalité des routes. Il intègre des messages de type Hello (notification au voisinage), RREQ (requête de route, Route REQuest), RREP (réponse de route, Route REPly), et RRER (annulation de route, Route ERRor). De la même manière que DSR, AODV utilise une requête de route dans le but de créer un chemin vers une certaine destination. Cependant, AODV maintient les chemins d une façon distribuée en gardant une table de routage au niveau de chaque noeud de transit appartenant au chemin cherché. Quand une application a besoin d envoyer des paquets sur le réseau et qu une route est disponible dans la table de routage, AODV ne joue aucun rôle. S il n y a pas de route disponible, il va par contre en rechercher une. Cette recherche commence par une inondation de paquets RREQ. Chaque 3 http ://tools.ietf.org/html/rfc3561 23

noeud traversé par un RREQ en garde une trace dans son cache et le retransmet. Quand les paquets de recherche de route arrivent à la destination (ou à un noeud intermédiaire qui a une route valide jusqu à la destination), alors un paquet de réponse RREP est généré et envoyé par le chemin inverse, grâ ce aux informations maintenues dans le cache des noeuds traversés par les RREQ. AODV dispose d un certain nombre de mécanismes optimisant son fonctionnement. Par exemple, l inondation se fait au premier essai dans un rayon limité autour de la source, et c est seulement dans le cas ou aucun chemin n est trouvé qu elle sera étendue à une plus grande partie du réseau. En cas de rupture d un lien, AODV va essayer de reconstruire localement les routes affectées en trouvant des noeuds de remplacement. La détection de rupture se fait grâ ce aux messages de type Hello envoyés uniquement aux voisins à un saut : une transmission périodique du message Hello est effectuée. Si trois messages Hello ne sont pas reçus consécutivement d un voisin, le lien en question est considéré défaillant. AODV utilise également le principe des numéros de séquence, afin de maintenir la validité des informations de routage en fonction du temps et d éviter les problèmes de type route looping et counting to infinity : certaines parties du réseau se trouvent isolées du reste, et les noeuds situés dans ces zones croient qu ils peuvent atteindre les noeuds desquels ils sont coupés en passant par leurs voisins. Il s ensuit un phénomène de bouclage dans lequel les noeuds injoignables se voient attribuer des distances de plus en plus grandes. Le fonctionnement du protocole AODV est exposé en détail dans [8]. Une fois les différents mécanismes de routage examinés, on peut être tenté de privilégier une approche systématique du problème. Une étude comparative menée sur les deux méthodes de routage, proactive d une part et réactive d autre part [9], montre qu il n y a pas une approche qui prévaut systématiquement sur l autre dans l optimisation des coûts de transmission. La performance de chacune des deux dépend de façon primordiale de l application dans laquelle elle est implémentée et des conditions d utilisation. Il faut simplement retenir : d une part que le principal argument pesant dans le choix d un protocole de routage sera le surplus de données généré par l implémentation de ce protocole. d autre part que pour optimiser ce paramètre il faut considérer la taille du réseau : lorsqu elle est modérée, il est plus judicieux en général de choisir une technique d inondation (réactive) alors lorsque le réseau devient plus étendu la construction des routes à l avance (proactive) 24

résultera en de meilleures performances. C est seulement après avoir eu un aperçu des mécanismes de routage dans les réseaux ad-hoc qu il sera bon de s interroger sur l approche à appliquer en fonction des contraintes dictées par le contexte et des résultats souhaités. 3.5 Hétérogénéité et hiérarchisation des réseaux ad-hoc La plupart des protocoles de routage proposés pour les réseaux MANET partent du principe que le réseau est homogène, c est-à-dire que tous les noeuds ont les mêmes capacités en termes de traitement de l information, de bande passante, d autonomie, de puissance d émission, ou encore de mobilité. Cette assertion ne peut que desservir la performance du routage, car il arrive fréquemment que des mobiles très différents soient réunis au sein d un même réseau, ce qui est tout à fait le cas de notre étude, notamment dans le scénario de search & rescue (cf. 7) et l efficacité de celui-ci en est affectée au même titre, par exemple, qu une communication filaire est restreinte par la largeur de bande de la plus limitée des portions de chemins empruntées. Une autre caractéristique des réseaux ad-hoc qui a un impact majeur sur les performances d un protocole de routage est l extensibilité (scalability). Elle peut être définie par la capacité d un réseau à ajuster ou maintenir ses performances lorsque le nombre de noeuds augmente (et par là-même la charge imposée à chacun d eux). Un réseau ad-hoc implémentant un protocole de routage traditionnel, dit plat, tend à voir sa performance se dégrader à mesure que le nombre de mobiles augmente, car le protocole ne tient pas compte des différences entre les noeuds du réseau (c est-à-dire de son hétérogénéité, quasi-systématique à grande échelle). De plus, avec un protocole traditionnel le surplus (overhead) de données de routage augmente généralement à chaque saut et ainsi qu avec le nombre d interfaces réseau que possède le noeud (il peut ainsi être intéressant de diminuer ce nombre en définissant des relais, voir plus bas). Considérant les deux problèmes posés par l extension des réseaux ad-hoc que sont l hétérogénéité et l extensibilité, on peut s interroger sur l utilité de mettre en place une hiérarchisation au niveau réseau afin d optimiser les communications au sein de celui-ci. Tout d abord, il est envisageable de définir la notion de groupe de mobiles, un groupe étant un ensemble de noeuds de même niveau pouvant communiquer librement. Ceci rend plus aisée l implémentation de communica- 25

tions sécurisées : les communications d un groupe peuvent être rendues incompréhensibles par le biais de techniques cryptographiques pour les groupes de niveau inférieur ou même tous les groupes d un niveau différent. On peut également envisager la mise en place de relais de communication permettant à un groupe sécurisé de communiquer avec le groupe de niveau supérieur. Cependant, il est à noter que ce type d architecture remet en cause le fonctionnement ad-hoc du réseau, et rend principalement sa structure plus fragile car la destruction d un relais de haut niveau rend tous les groupes subordonnés incapables de communiquer avec le groupe supérieur. Le protocole de hiérarchisation doit donc prévoir l échange, voire la duplication des relais de communication sécurisés. Ce type de structure peut se révéler particulièrement adapté dans le déploiement de réseaux ad-hoc militaires sur le terrain d opérations ( [10]), ou une hiérarchisation et une sécurisation des communications apparaissent primordiales, comme l illustre la figure 3.7. Fig. 3.7 Gestion sécurisée dans les réseaux ad-hoc militaires 3.5.0.1 Le protocole HOLSR (Hierarchical OLSR) Le protocole HOLSR est une évolution du protocole OLSR, destinée à améliorer son extensibilité, le rendant plus adapté aux réseaux hétérogènes de grande taille. 26

En général, les protocoles de routage ad hoc, y compris le protocole OLSR, ne sont pas spécialement conçus pour les réseaux hétérogènes ; par conséquent, ils n exploitent pas efficacement les liens à haute capacité présents dans ces réseaux ou les noeuds possèdent diverses capacités de communication. De même, ils peuvent provoquer rapidement une surexploitation des liens qui présentent des caractéristiques inférieures. OLSR ne propose pas de support des noeuds à interfaces multiples, et des problèmes d extensibilité peuvent survenir lorsqu ils est implémenté dans un réseau hétérogène. Par exemple, les messages de contrôle sont envoyés à toutes les interfaces, ce qui engendre une surcharge très importante. HOLSR tente de répondre à ce problème en proposant plusieurs modifications : tout d abord, les noeuds sont organisés en plusieurs niveaux topologiques, comme indiqué en figure 3.8 : les noeuds de niveau 1, à faible capacité (par exemple, faible puissance d émission ou faible réserve énergétique), représentés par des cercles sur la figure, sont équipés d une seule interface radio, de débit et de portée limités. Ce niveau pourrait rassembler, dans le cas de notre scénario de search & rescue (cf. 7), les sauveteurs humains par exemple. Les noeuds de niveau 2, représentés par des carrés sur la figure, peuvent être équipés de deux interfaces radio, l une d elles au moins capable de communiquer avec les unités de niveau 1. Ces noeuds peuvent également transmettre des messages au niveau 2 en utilisant une bande de fréquences ou une stratégie d accès au médium (MAC) qui diffère de celles utilisées pour communiquer avec les noeuds de niveau 1. Ces noeuds pourraient dans notre scénario être les robots relais de communication assistant les sauveteurs. Les noeuds de niveau 3, représentés par des triangles sur la figure, sont des noeuds de grande capacité (par exemple le camion ayant amené sur site les sauveteurs et leur matériel). Ces noeuds peuvent être équipés de trois interfaces radio, pour communiquer de la même façon que les noeuds de niveau 2 avec leurs semblables au niveau 3 (communications large-bande et longue portée), ainsi qu avec une capacité moins élevée avec les unités de niveau 2 et de niveau 1. Les noeuds peuvent ensuite être rassemblés en groupes (clusters) à différents niveaux, le protocole HOLSR incluant la gestion de messages CIA (Cluster ID Annoucement), équivalent aux messages Hello entre les groupes. Le fonctionnement du protocole HOLSR est exposé en détail dans [11] et ses performances sont testées dans [12], montrant tout l intérêt de l ajout d une considération d ordre hiérarchique dans l utilisation d OLSR. 27

Fig. 3.8 Un exemple de réseau organisé hiérarchiquement avec des éléments hétérogènes 3.6 La gestion de l énergie dans les réseaux ad-hoc On a vu précédemment que les protocoles de routage dans les réseaux ad-hoc proposent différentes méthodes d achemination des paquets vers les noeuds destinataires, et qu on peut choisir entre ces différents protocoles en fonction de l application désirée. Pourtant, il est une caractéristique fondamentale des réseaux ad-hoc qui est à prendre en compte : le facteur énergétique. Il n existe pas à ce jour de norme standardisée par l IETF (cf. figure 3.9) visant à limiter la consommation d énergie dans les réseaux ad-hoc, ce qui est un aspect essentiel de la conception notamment dans le cas des réseaux de capteurs (cf. 5) dont le but est d avoir la plus grande autonomie de fonctionnement possible. Les terminaux mobiles qui constituent les MANET sont alimentés dans une très grande majorité des cas par des batteries qui possédent une durée de vie finie. Cette limitation est primordiale dans les réseaux ad-hoc, car même lorsqu un noeud ne communique pas des données qui lui sont propres (en émission ou en réception), il doit utiliser son circuit radio comme vecteur de transmission des communications des autres mobiles du réseau. Les protocoles de routage orientés économie d énergie doivent ainsi prendre en compte 28

Fig. 3.9 Manque de protocoles standardisés dans la gestion de l énergie en mode ad-hoc une métrique basée sur la consommation d énergie lors des différentes transmissions intervenant dans le processus de découverte et de maintien de route. On pourra distinguer les politiques de limitation de la puissance d émission du circuit radio d une part, et le calcul de route pondéré entre la performance du routage et son coût énergétique d autre part. Les algorithmes de routage spécifiquement orientés économie d énergie peuvent être classés en différentes catégories : contrôle de la puissance dissipée du circuit radio (Network Device Power Control) retard induit dans le transit, TDOR (Time Delay On-Demand Routing) optimisation du chemin parcouru pour économiser l énergie consommée (Optimal Path Discovery on Demand Vector), comme dans le cas d EAODV (cf. 3.6.0.1). Par exemple, dans le cas de TDOR (appliqué à AODV), chaque noeud possède un attribut supplémentaire : son énergie de batterie résiduelle, normalisée de 1 (le minimum) à 10 (le maximum). A la réception d un paquet RREQ, un noeud le maintiendra pour une période inversement proportionnelle à sa batterie résiduelle. Ainsi, la route la plus rapide sera celle traversant les noeuds possédant la plus grande charge de batterie. 3.6.0.1 Le protocole EAODV (Enhanced AODV ) Pour le concept EAODV, l idée est un peu différente : dans AODV, le noeud destination émet un paquet réponse RREP immédiatement après la réception d un RREQ. Il peut en résulter une erreur de route à cause d une 29

collision lorsque le paquet RREQ traverse une route optimale, et les noeuds intermédiaires impliqués dans la route peuvent être déjà fortement chargés ou en fin de charge batterie. Une information complémentaire est alors incluse dans le RREQ, donnant au noeud destinataire la possibilité de trouver un chemin optimal en lui permettant d attendre plusieurs RREQ à l intérieur d une fenêtre d attente : l analyse des paramètres de la route, et notamment de la charge batterie des noeuds intermédiaires, permet de choisir le chemin optimal pour le critère économie d énergie (cf. figure 3.10). Fig. 3.10 Le principe du fonctionnement de EAODV 3.7 La couche MAC dans les réseaux ad-hoc Les spécificités du médium radio par rapport au médium filaire rendent primordiale l application d une politique efficace de contrôle d accès (MAC, Medium Access Control) : tout d abord, les ondes radio se propagent à une vitesse inférieure à celle de la lumière : les réseaux radio sont par conséquent moins rapides que les réseaux filaires. De plus, la propagation des ondes radio est extrêmement sensible à l environnement : un obstacle suffit à atténuer fortement un signal radio : on a donc une fiabilité moins grande sur le médium radio que sur son homologue filaire. De la même façon, deux paires de stations 30

radio, même sans appartenir au même réseau, peuvent voir leurs communications brouillées du fait des collisions intervenant sur le médium si leurs zones d émission sont mêlées. Il faut donc partager la bande passante entre les différentes communications dans une même zone. Le contexte ad-hoc rend plus complexe encore la gestion du médium, car l absence de centralisation des transmissions rend difficiles à implémenter les techniques traditionnelles de multiplexage de type FDMA, CDMA, etc. De plus, l environnement étant dynamique, un des noeuds peut quitter le réseau ou le rejoindre à tout moment, et ces modifications doivent être intégrées équitablement dans la stratégie MAC pour rendre l utilisation du réseau optimale. Dans un réseau filaire classique, une station peut lire la valeur effectivement présente sur le médium câble en même temps qu il y écrit : si cette valeur est différente de celle qu il veut y écrire, il y a collision : ce principe est à la base de la détection de collisions par écoute de la porteuse (CSMA/CD, Carrier Sense Multiple Access / Collision Detection) utilisée notamment dans les réseaux Ethernet. Cependant, dans le cadre des communications radio, l atténuation en fonction de la distance parcourure est très supérieure à celle observée sur un médium filaire : l émetteur radio ne détecte donc en général pas qu il y a collision lorsque cela arrive. Le rôle de la couche MAC est d éviter les collisions, d assurer le partage de la bande passante entre tous les utilisateurs du réseau en tenant compte des niveaux de priorité, et de résoudre un problème spécifique des transmissions radio : celui des stations cachées. La première disposition prise va donc être la mise en place d un sytème d acquittement des paquets envoyés, pour s assurer que la transmission n a pas été brouillée par une autre intervenant en même temps sur le médium. En mode ad-hoc, la couche MAC utilise le mode de fonctionnement DCF (Distributed Coordination Function), car la gestion de l accès n est pas centralisée comme dans le cas du mode PCF (Point Coordination Function). Nous avons vu qu il est impossible de détecter directement les collisions sur le médium radio : l idée va donc être pour un émetteur d attendre que le médium soit libre. Lorsque le canal devient libre, il faut attendre avant tout un temps appelé DIFS (DCF Inter-Frame Space) pour recommencer à émettre. Seulement, cette approche est invalide pour la raison suivante : si plusieurs émetteurs attendent que le médium soit libre, ils vont commencer à émettre simultanément dès que cette condition sera satisfaite, entraînant des collisions et donc des pertes de paquets. Il faut donc ajouter un temps 31

aléatoire avant le début de l émission, appelé backoff. Le backoff est choisi au hasard dans une fenêtre [0..CW ], CW pour Contention Window. Dès que le DIFS est écoulé, les noeuds décrémentent leur backoff. Dès que l un d eux arrive à 0 (dans la figure 3.11), le mobile 1), il commence à émettre et les autres stoppent la décrementation de leur backoff pour passer en période de defering, comme indiqué sur la figure 3.11. Fig. 3.11 Le backoff et le defering Il est à noter que le temps de pause qui sépare un paquet de données de son acquittement est appelé SIFS (Short Inter-Frame Space) et qu il est plus court que DIFS, car l acquittement possède une priorité supérieure à celle des paquets de données. Le mobile en période de defering ne pourra reprendre la décrémentation de son backoff que si le canal est à nouveau libre pendant DIFS. Le fait que SIFS soit plus court empêche que la décrémentation ne reprenne de manière inopportune entre les données et leur acquittement. Lorsque les données du mobile 1 ont été acquittées et que DIFS s est écoulé sans activité sur le canal, le mobile 2 peut reprendre la décrémentation de son backoff. Ici, aucun autre mobile ne vient l empêcher de terminer et il peut donc finalement envoyer ses données. Le mécanisme de backoff limite les risques de collision mais ne les supprime pas complètement. Aussi, si une collision se produit quand même (détectée grâce à l absence d acquittement), un nouveau backoff va être tiré au hasard. Mais à chaque collision consécutive, la taille de la fenêtre va doubler afin de diminuer les chances que de telles collisions se répètent : la fenêtre de contention s adapte en fait au nombre de mobiles actifs dans la zone d émission. 32

3.7.1 Le problème des stations cachées et la solution RTS/CTS Nous avons vu que la méthode d écoute du médium semble garantir une gestion efficace du contrôle d accès et l évitement des collisions, pourtant il y a des cas où elle n est pas suffisante : il s agit de la situation des noeuds cachés (figure 3.12) où deux émetteurs qui ne peuvent pas du tout se détecter cherchent à communiquer avec la même station : Fig. 3.12 Le problème des stations cachées Comme dans cette configuration un émetteur ne détecte jamais l activité de l autre, il croit que le canal est toujours libre et émet dès qu il a des données disponibles. Les chances de collisions à répétition au niveau du récepteur sont très élevées. 802.11 propose un mécanisme utilisant des paquets de controle appelés Request To Send (RTS) et Clear To Send (CTS). Un mobile qui veut émettre ne va plus directement envoyer un paquet de données, mais d abord un petit paquet RTS pour lequel les chances de collision sont plus faibles. A ce paquet RTS, le destinataire va répondre par un petit paquet CTS qu il diffuse à tout son voisinage. Les paquets RTS et CTS contiennent des informations qui permettent de réserver le canal pour la durée de transmission des données qui vont suivre. Un mobile qui reçoit un CTS alors qu il n a pas envoyé (ni même détecté) de RTS sait que quelqu un d autre va émettre et qu il doit donc attendre. Le mobile qui a envoyé le RTS sait, quand il reçoit le CTS correspondant, que le canal a été réservé pour lui et qu il peut émettre. 3.7.2 Le problème des stations exposées Le problème des noeuds exposés apparaît dans des configurations comme celle présentée sur la figure 3.14. Ici, les noeuds B et C voudraient émettre respectivement vers A et D. En suivant le principe DCF exposé plus haut, celui qui a le plus petit backoff va accéder au canal et envoyer son paquet, 33

Fig. 3.13 L échange RTS/CTS alors que l autre détectera la porteuse du premier, et entrera en période de defering. Pourtant, si B et C émettaient en même temps, le signal de B au niveau de A serait largement supérieur à celui de C et suffisant pour une réception correcte. La situation serait inversée au niveau du noeud D, qui recevrait correctement le paquet de C, malgré le léger bruit venant de B. Dans cette situation, la DCF limite donc inutilement la bande passante totale du réseau. Il n existe pas à ce jour de solution standardisée à ce problème, même si des travaux comme [13] proposent l utilisation d un mécanisme de parallel RTS pour le résoudre en partie. Fig. 3.14 Le problème des stations exposées 3.7.3 Un mécanisme de priorités pour 802.11 Des travaux comme [14] proposent d adapter la fonction DCF pour y inclure un système de priorités entre les trames, ce qui pourrait être utile dans des applications où le réseau doit être en mesure de véhiculer certains messages très prioritaires quel que soit son utilisation par les voisins directs (par exemple un signal d alerte dans un scénario de search & rescue). Comme il a été dit plus haut, avant d émettre sur le medium, tout noeud doit s assurer que le canal radio est libre depuis un certain temps DIFS, afin de privilégier certains paquets de signalisation comme les ACK et les 34

RTS/CTS, dont la transmission peut s effectuer dès que le medium a été libre durant un temps SIFS plus court que le DIFS. On ajoute au DIFS, constant, un délai supplementaire backoff aléatoire permettant d éviter que deux mobiles ne commencent a émettre au même moment. Un certain nombre de ces paramètres peuvent être adaptés dynamiquement dans le but d offrir un mécanisme de priorités au protocole 802.11 : lorsqu une collision survient, les délais avant retransmission sont allonges aléatoirement ; il est possible d incrémenter ces délais differemment selon le niveau de priorité. il est possible d utiliser différentes valeurs du délai de silence avant une transmission DIFS selon le niveau de priorité de la transmission. enfin, il est possible de limiter la longueur des trames selon le niveau de priorité, les trames peu prioritaires occupant le canal moins longtemps. Les trois principes ont ete testés sur des flots UDP et TCP. De ces trois méthodes, la deuxième, consistant à jouer sur le délai DIFS, semble la plus stable et la plus performante. 3.7.4 Routage avec Qualité de Service Claude Shannon a démontré en 1948 dans son ouvrage A Mathematical Theory of Communication [15] qu il y avait un débit maximum atteignable sur une bande de fréquences radio, et ce indépendamment de la technologie utilisée. Depuis lors, il est clair que l utilisation des fréquences du spectre alloué aux radiocommunications doit être la plus efficace possible, car à la différence des réseaux filaires le débit des communications radio ne peut pas augmenter indéfiniment. Aujourd hui, les débits atteints sur les réseaux ad-hoc rendent possible le transfert de flux multimédia soumis à de fortes contraintes (par exemple dans notre application de search & rescue, cf. 7). Dès lors, il est légitime de chercher à fournir aux applications des garanties sur le délai, sur les taux de perte ou encore sur la bande passante. Les solutions utilisées dans le monde filaire sont inadaptées aux transmissions radio, et ceci est plus complexe encore dans le cas des réseaux MANET par l absence d administration centralisée. Le principe du routage avec qualité de service est de rechercher un chemin entre deux noeuds satisfaisant certaines contraintes. Plusieurs critères peuvent être utilisés, comme le délai, la bande passante, ou le coût énergétique de transmission. En général, le routage avec qualité de service ajoute aux protocoles usuels une fonction de contrôle d admission pour déterminer quelles sont les routes qui satisfont les contraintes requises par un flux. 35

Il existe deux architectures de qualité de service normalisées par l IETF : IntServ pour Integrated Services, qui date de la fin des années 80 et dans lequel tout flux de données, identifié par l adresse de la source, et le couple adresse, port de la destination, peut bénéficier de garanties individuelles sur le délai de bout en bout, le débit, etc., à condition que le réseau puisse assurer le niveau de service demandé. IntServ, utilisé en général avec le protocole de réservation de ressources RSVP 4 (Resources Reservation Protocol), définit une architecture orientée connexion, ce qui implique un volume de stockage de données important au niveau de chaque noeud du réseau. Pour cette raison, ce n est pas le modèle le plus adapté au contexte ad-hoc. L architecture DiffServ pour Differentiated Services, propose elle une gestion plus légère de la qualité de service : c est celle qui est majoritairement utilisée dans l Internet. Elle définit plusieurs classes de trafic, comme la classe Premium Service qui donne des garanties sur le délai, la gigue et le taux de pertes tout en assurant une bande passante minimale : elle est adaptée aux applications temps réel telles que la voix et la vidéo sur IP. De même, il existe une classe Assured Service, qui permet aux applications de définir avec précision le taux de pertes admissible dans une transmission. Pourtant, ce modèle est également inadapté aux réseaux ad-hoc : il ne permet pas de privilégier aisément un flux par rapport à un autre, et se montre déficient lorsque la topologie du réseau évolue rapidement. Il existe des études visant à définir de nouvelles architectures plus adaptées au contexte ad-hoc, comme FQMM (Flexible Quality of Service Model for Mobile ad hoc networks), présenté dans [16], ou 2LQoS (Two-Layered Quality of Service model reactive routing protocols for mobile ad hoc networks) encore au stade embryonnaire. L étude des mécanismes de qualité de service dans les réseaux ad-hoc est complexe et ne rentre pas formellement dans le cadre du projet, mais il pourra être intéressant de se pencher sur la question pour être en mesure de répondre aux contraintes dictées par les applications étudiées. 4 http ://tools.ietf.org/html/rfc2205 36

Chapitre 4 Technologies de communication sans-fil Un réseau sans fil est un réseau dans lequel au moins deux terminaux (ordinateur, PDA, station embarquée, etc.) peuvent communiquer en l absence de liaison filaire. On associe souvent la notion du sans-fil à celle de mobilité, puisque, lorsqu il est connecté à un réseau sans-fil, un utilisateur peut se déplacer tout en restant connecté, dans un périmètre et à une vitesse plus ou moins importants en fonction des technologies. Les réseaux sans fil utilisent le médium radio à la place du médium câble traditionnel. Les technologies existantes se distinguent principalement par leur caractéristiques : le débit offert, la portée des transmissions, et le coût énergétique de transmission. Elles sont regroupées usuellement en plusieurs catégories en fonction de leur zone de couverture (figure 4.1) : Nous nous intéresserons ici aux réseaux de type WPAN (Wireless Personal Area Network) et WLAN (Wireless Local Area Network), dont la portée varie de quelques mètres (Bluetooth, ZigBee) à quelques centaines de mètres maximum (Wi-Fi), et qui par là sont adaptés aux applications du projet ROSEAU. 4.1 La norme IEEE 802.15.4, ou ZigBee ZigBee est le nom standardisé d une suite de protocoles de communication de haut niveau, utilisant des dispositifs de petite taille et de faible consommation basés sur le standard 802.15.4 1. La norme ZigBee 1.0 a été définie 1 http ://www.ieee802.org/15/pub/tg4.html 37

Fig. 4.1 Différentes technologies de communication sans-fi le 14 décembre 2004 et est disponible pour tous les membres de la ZigBee Alliance 2. 4.1.1 Présentation ZigBee opère dans la bande des fréquences industrielles, scientifiques et médicales (ISM) : 868 MHz en Europe, 915 Mhz aux Etats-Unis et 2.4 Ghz dans le reste du monde. ZigBee est réputée plus simple et moins coûteuse que d autres tecnhologies WPAN comme Bluetooth (cf. 4.2) : le noeud ZigBee le plus complet logiciellement est présenté comme nécessitant uniquement 10% du code nécessaire pour faire fonctionner un noeud Bluetooth ou Wi-Fi, tandis que les plus simples nécessitent environ 2% de ce volume logiciel. Ceci est une déclaration ayant un objectif essentiellement publicitaire, puisque les distributions ZigBee actuellement disponibles représentent environ la moitié du volume des distributions logicielles Bluetooth. Le coût estimé d un composant ZigBee descend à environ 1$ lorsqu ils sont produits en grande quantité. Cependant, la plupart des implémentations requièrent également l utilisation d un micro contrôleur, ce qui augmente le prix global d un noeud : à l heure actuelle, celui-ci vaut environ 5$. Le standard IEEE 802.15.4 est étudié pour être utile dans une grande variété d applications : le contrôle et le suivi industriel, la sécurité publique 2 http ://www.zigbee.org 38

(utilisation sur des sites de catastrophe notamment), la détection automatique (suivi de pression des pneumatiques par exemple), les badges et tags actifs, ou les réseaux de capteurs (cf. 5). Toutes les applications qui ne requièrent pas un débit important mais ont des contraintes énergétiques fortes, et à ce sens ne peuvent pas manipuler une pile de protocoles lourde ou utiliser des ressources de calcul importante, sont concernées par l utilisation de ZigBee. 4.1.2 Le routage dans les réseaux ZigBee Il existe trois types différents de noeuds ZigBee : ZigBee Coordinator (ZC) : c est le noeud le plus abouti. Il forme la racine du réseau et peut jouer le rôle de pont vers d autres réseaux. Il y a exactement un ZC dans chaque réseau ; celui-ci peut stocker des informations concernant le réseau, comme les clefs de sécurisation des communications. ZigBee Router (ZR) : les routeurs peuvent agir en tant que noeuds intermédiaires, en transmettant des données à d autres noeuds. ZigBee End Device (ZED) : le type de noeud le plus courant, qui présente juste assez de fonctions pour communiquer avec le noeud parent (coordonnateur ou routeur) ; il ne peut pas jouer le rôle de relais d informations pour d autres noeuds ; c est le noeud le moins cher à fabriquer, car la quantité de mémoire nécessaire à son fonctionnement est faible. Le routage au niveau réseau est basé sur un protocole propriétaire de la ZigBee Alliance, proche d AODV (cf. 3.4.2.2) pour les réseaux IP. On ajoute à ce protocole une architecture multi-cluster, où des grappes de ZED et de ZR sont reliés entre eux par des ZR autour d un unique ZC. On peut ainsi obtenir plusieurs types d architecture, selon que le réseau est maillé, en étoile, ou encore hiérarchisé (figure 4.2). Il y a deux modes de fonctionnement : beacon enabled et non-beacon enabled. en mode non-beacon (un beacon est une balise, un flash radio), un système d écoute de porteuse type CSMA est utilisé : typiquement, la plupart des noeuds écoutent en permanence le réseau, ce qui nécessite une plus grande robustesse d alimentation à ce niveau. Mais cela autorise également la constitution de réseaux hétérogènes ou certains noeuds se réveillent uniquement sur stimulus externe : on peut prendre par exemple le cas d un interrupteur télécommandé pour une lampe : le noeud raccordé à la lampe est toujours actif, puisqu il a une source d alimentation importante. En revanche, le noeud raccordé à l interrupteur 39

Fig. 4.2 La structure d un réseau basé sur la technologie ZigBee passe en mode actif uniquement lorsque l interrupteur est enclenché, émet un signal court, attend l acquittement puis repasse en mode veille. Ici, le noeud raccordé à la lampe serait au moins un ZigBee Router, sinon le ZigBee Coordinator ; et le noeud raccordé à l interrupteur serait un ZigBee End Device. en mode beacon, les noeuds du réseau envoient des flashs périodiques pour signaler leur présence aux autres noeuds. La fréquence peut varier de 15 ms à plus de 13 minutes. Les noeuds sont actifs uniquement lorsqu un beacon est transmis. Ce mode de fonctionnement est utile lorsque tous les noeuds du réseau ont la même fonction (par exemple dans un réseau de capteurs) et que l application est orientée économie d énergie. Lorsqu un noeud voulant transmettre des données connaît l adresse réseau du destinataire, le routage est dit direct. L adresse cible est transmise dans la trame et relayée par les ZR jusqu à la destination. Dans le cas contraire, le routage est dit indirect : le paquet est transmis au noeud de niveau supérieur (ZR ou ZC), qui fait la relation avec le vrai destinataire d après la table de routage et la table de découvertes des routes. Un noeud ZED, qui n a pas de capacités de routages, doit toujours envoyer les paquets qu il veut transmettre au noeud directement supérieur. La table de routage contient les données sur les destinataires, c est-àdire l adresse de destination de la route et le prochain noeud (ZR ou ZC) à atteindre pour se rapprocher du destinataire. 40

La table de découverte d une route contient les informations sur les sources du message. Elle stocke l adresse d origine du noeud qui a fait la demande et l adresse du noeud qui va transmettre les données en tant qu intermédiaire (entre la source et la destination). Elle contient aussi les coûts de transmission entre la source jusqu au nœud actuel et du nœud jusqu au destinataire. Elle peut donc être utilisée pour optimiser la route en mettant à jour les adresses des noeuds à traverser. Le choix d une route, lorsque plusieurs sont disponibles, est toujours fait dans le but de minimiser le critère de routage choisi : en général la distance, auquel on peut ajouter un facteur de pondération en fonction de l énergie disponible sur un noeud. 4.2 La norme IEEE 802.15.1, ou Bluetooth Bluetooth est une spécification créée à l origine par l industriel suédois Ericsson, auquel se sont joints ensuite les grandes firmes Agere, IBM, Intel, Microsoft, Motorola, Nokia et Toshiba) pour former le Bluetooth SIG (Special Interest Group). La technologie utilise également une bande de fréquences ISM, s étendant sur 83.5 Mhz (de 2.4 à 2.4835 Ghz). Les modules Bluetooth sont divisés en 3 classes en fonction de leur puissance d émission et par conséquent de leur portée : la classe 3, la plus fréquente, émet à une puissance de 1 mw pour une portée de 10 mètres environ. Bluetooth implémente une couche équivalente à la couche MAC du modèle OSI appelée bande de base (baseband), qui gère une adresse physique sur 48 bits et deux types de paquets, selon que le transfert est synchrone ou asynchrone : les paquets SCO, pour Synchronous Connection-Oriented les paquets ACL, pour Asynchronous Connection-Less Le standard Bluetooth est basé sur un mode de fonctionnement maîtreesclave, comme ZigBee. La différence principale ici est qu un picoréseau (piconet), rassemblant un maître et 7 esclaves maximum, n est pas conçu à l origine pour communiquer avec d autres picoréseaux. Deux piconets peuvent cependant cohabiter et échanger des informations, mais en raison de la conception non-adaptée de la technologie, au-delà d un certain nombre de picoréseaux les interférences deviennent trop importantes et altèrent les performances du réseau : on considère qu une dizaine environ de picoréseaux peuvent cohabiter dans une même zone de couverture. Il y a donc une limitation stricte au nombre de périphériques Bluetooth présents dans un réseau. Cependant, il existe une façon de contourner cette 41

limitation : un maître peut être connecté simultanément à 7 esclaves en mode actif, mais également à 255 autres en mode parked : ces périphériques appartiennent au réseau mais ne possèdent pas d adresse logique (sur 8 bits) au sein de celui-ci. Ils peuvent s en voir affecter une à tout instant par le maître à condition qu une autre soit libérée, et ce basculement constant permet, s il est fait à une fréquence suffisante, de considérer un piconet virtuel de 7 + 255 périphériques reliés ensemble. La pile de protocoles Bluetooth est plus complexe que la pile ZigBee (cf. 4.1), et bâtie autour de différents profils qui permettent l interopérabilité de tous les périphériques Bluetooth, mais rendent l implémentation logicielle plus complexe et plus lourde que dans le cas de ZigBee. 4.3 La norme IEEE 802.11, ou Wi-Fi La norme IEEE 802.11 est un standard international décrivant les caractéristiques d un réseau local sans fil (WLAN). Le nom Wi-Fi correspond initialement au nom donné à la certification délivrée par la WECA (Wireless Ethernet Compatibility Alliance), l organisme chargé de maintenir l interopérabilité entre les matériels répondant à la norme 802.11. La norme 802.11 permet de relier des périphériques sans-fil à haut débit, le tout en utilisant les modèles classiques des réseaux Ethernet, car elle ne définit que les couches basses du modèle OSI : la couche physique et la couche liaison (LLC + MAC). Il est donc possible d utiliser n importe quel protocole de réseau, de transport et de niveau supérieur au-dessus de ces deux couches. Le grand intérêt de la norme Wi-Fi est donc d être facilement implémentable dans des réseaux locaux sans-fil, qui peuvent être administrés comme des réseaux Ethernet classiques. Le standard propose deux modes de fonctionnement différents : le mode architecture et le mode ad-hoc, dont les différences ont été exposées précedemment. De même, les mécanismes de routage ont été abordés en section 3. 4.4 Intérêts respectifs des technologies étudiées Il est légitime de s interroger sur le choix des technologies à employer dans les applications qui nous intéressent. Si l on regarde tout d abord un premier récapitulatif très sommaire des 3 standards (figure 4.3), il est clair qu ils ne sont pas destinés à la même utilisation : Les communications qui requièrent un débit important (typiquement les communications audio/vidéo : de l ordre de plusieurs Mbit/s) vont nécessairement 42

Fig. 4.3 Différents standards pour différentes utilisations utiliseront de préférence le standard 802.11, tandis que les transmissions radio n ayant pas les mêmes contraintes de débit mais s inscrivant dans un contexte d économie d énergie (typiquement, des capteurs autonomes ou des balises de signalisation) s orienteront plutôt vers les normes ZigBee ou Bluetooth. Les principaux élémentes à considérer sont : la technologie Bluetooth est conçue pour transmettre des paquets de grande taille à travers un réseau relativement petit (généralement, 8 noeuds au maximum), tandis que la technologie ZigBee est plus adaptée à des paquets de taille réduite circulant dans un réseau comportant un grand nombre de noeuds. ZigBee est de façon évidente préférable lorsque les batteries ne peuvent pas être remplacées ou rechargées fréquemment. le débit maximum offert par ZigBee est de l ordre de 250 kb/s, alors qu il est 4 fois plus élevé pour Bluetooth ; cest valeurs ne sont que théoriques et rarement atteintes en pratique. Les temps d accès sont différents : dans le cas de ZigBee, typiquement 30ms pour l intégration dans un réseau, 15ms de basculement veille/marche, et 15ms de recherche d un noeud esclave. Dans le cas de Bluetooth, typiquement 5 secondes d accès au réseau, 3 secondes de basculement veille/marche et 2ms de recherche d un esclave : ZigBee est conçue pour les applications à temps critique. la portée est du même ordre de grandeur pour les deux normes, mais une communication peut rester efficace à plusieurs dizaines de mètres avec ZigBee tandis que Bluetooth perdra la liaison après typiquement 10 mètres. Enfin, la pile protocolaire est moins variée mais également moins complexe 43

pour le standard ZigBee (figure 4.4) : il est ainsi plus aisé de développer le driver d un composant ZigBee, mais les possibilités offertes sont moins riches en diversité. Fig. 4.4 La pile de protocoles avec Zigbee et Bluetooth Dans la plupart des applications (étudiées au chapitre II) nécessitant la création d un réseau de type WPAN, il s avèrera que l utilisation de ZigBee est préférable à celle de Bluetooth. 44

Chapitre 5 Réseaux de capteurs Un réseau de capteurs sans-fil (Wireless Sensor Network) est constitué d un certain nombre de capteurs (sensors) étendus sur une zone géographique plus ou moins vaste. Chaque capteur (noeud) possède une interface de communication sans-fil et un certain niveau d intelligence pour le traitement du signal et la transmission réseau des données collectées. Ces réseaux de capteurs peuvent avoir des applications très diverses, parmi lesquelles : les réseaux de capteurs déployés en environnement naturel pour surveiller les changements climatiques, géologiques, éthologiques, etc. les réseaux de capteurs militaires, dont l objectif est de collecter autant d information que possible sur les mouvements de l ennemi, les explosions, et tous les phénomènes dignes d intérêt, les réseaux de capteurs déployés dans le but de recueillir des informations et de caractériser le niveau de menace en cas d accident chimique, nucléaire, écologique, et de caractériser les substances détectées, les réseaux de surveillance du trafic automobile d une ville dans le but d éviter les embouteillages, les réseaux de surveillance destinés à assurer la sécurité dans des grands magasins, parkings souterrains, etc. Les possibilités d utilisation de ce type de réseaux sont innombrables. On peut classer les réseaux de capteurs existants suivant deux critères : si les capteurs sont adressables individuellement ou non, et si les données collectées sont fusionnées ensemble ou non. Par exemple, un réseau de capteurs destiné à rendre compte de la disponibilité des places d un parking doit être individuellement adressable, tandis qu un réseau de mesure de température peut demander une information à une zone (une grappe de capteurs) sans cibler un élément en particulier. Le but précis de l implémentation d un réseau de capteurs dépend de l application, mais les tâches suivantes se retrouvent souvent dans le cahier 45

des charges : déterminer la valeur d un certain paramètre (souvent un paramètre de l environnement) à un endroit donné : température, pression atmosphérique, quantité de lumière reçue, humidité, etc. détecter l occurrence d un évènement précis et estimer les paramètres de celui-ci : par exemple, on pourrait souhaiter connaître la vitesse exacte d un véhicule qui se dirige vers une intersection encombrée. classifier un objet ou un événement détecté : le véhicule est-il une voiture, une fourgonnette, un autobus? item suivre un objet : dans un contexte militaire par exemple, suivre les déplacements d un char ennemi à mesure qu il évolue dans la zone couverte par le réseau (de capteur en capteur, donc). Dans chaque application, une exigence primordiale est que l information soit distribuée au bon utilisateur, souvent avec une contrainte de temps stricte : par exemple, une intrusion dans un lieu suveillé doit être signalée immédiatement à l unité de police en charge de la zone. Les réseaux de capteurs présentent souvent des besoins spécifiques : support d un grand nombre de capteurs : certaines applications peuvent requérir le déploiement de plusieurs milliers ou dizaines de milliers de noeuds du réseau, c est la raison pour laquelle l extensibilité est un besoin essentiel. On peut noter que dans la plupart des cas, les capteurs sont stationnaires, ce qui enlève les contraintes liées à un réseau ad-hoc à topologie très dynamique. économie d énergie : il arrive souvent que les capteurs sont déployés dans des environnements distants ou difficiles d accès, et la durée de vie d un noeud peut devenir celle de sa batterie. Il devient évident que la consommation d énergie d un noeud doit être minimisée à tout prix. auto-organisation du réseau : étant données la taille du réseau et sa localisation potentielle dans un environnement hostile, l intervention humaine sur l organisation du réseau doit être réduite au minimum, idéalement nulle : on retrouve ici les caractéristiques d un réseau adhoc, qui doit pouvoir faire face à la panne ou la disparition d un noeud sans que l efficience des transmissions soit affectée. traitement collaboratif de l information : une caractéristique qui distingue les réseaux de capteurs des réseaux MANET est que leur but est la détection et la caractérisation de certains événements, pas uniquement la communication de données : il peut souvent être utile de fusionner les données recueillies par plusieurs capteurs à un certain niveau. Ceci requiert l emploi par exemple de messages de contrôle, qui sont une contrainte supplémentaire sur l architecture réseau. 46

Avec l avènement de technologies de communication sans-fil courte portée à bas prix et orientées économie d énergie, de larges réseaux ad-hoc de capteurs seront bientôt déployés. Ces réseaux pourront être organisés en sousréseaux (clusters) semi-indépendants fusionnant les informations recueillies. Et chaque noeud ou groupe de noeuds devra avoir suffisamment de capacité de traitement pour analyser certains paramètres et prendre des décisions. L équipe RESL 1 (Robotic Embedded Systems Laboratory) de l USC (University of Southern California) travaille sur des projets intéressants dans ce domaine, comme l utilisation de capteurs mobiles pour améliorer l efficacité du réseau ou le rétablissement autonome de la connexité par un drone hélicoptère. L étude d un scénario de surveillance forestière mettant en oeuvre un réseau de capteurs est présenté en partie 8. 1 http ://www.robotics.usc.edu/ embedded/research/ 47

Chapitre 6 Réseaux de robots Un des objectifs du projet ROSEAU est de faire cohabiter des robots au sein d un même environnement, et de les faire coopérer dans la réalisation d une même tâche. Il existe beaucoup de cas dans lesquels une coopération de ce type peut se révéler très utile : l exploration d un environnement inconnu et le partage d informations diverses sur cet environnement, la construction de structures, les applications de search & rescue (cf. 7), etc. Les défis sont multiples : définir une stratégie de déplacements coordonnés en fonction des paramètres dynamiques de l environnement et de l état des autres robots, intégrer les données de tous les éléments du réseau et leur donner un poids en fonction de l implication dans l évènement à analyser, partager la prise de décision entre les différents acteurs, définir un cadre précis de communication réseau robuste et efficace, etc. Toutes ces tâches font appel une notion commune : la distribution de la perception, de la planification et de l action. Un bon exemple de cette coopération est celui des swarm-bots, les robotsessaim 1 : ceux-ci, lorsque l exécution d une tâche tout seul est impossible ou trop longue, coopèrent pour la mener à bien : le franchissement d un obstacle par exemple [17], ou le déplacement sur terrain accidenté [18], ou encore la répartition du travail par imitation d une colonie de fourmis [19]. On peut citer également le projet TRESTLE, qui vise à rendre possible la coopération d une population de robots hétérogènes dans le cadre de l assemblage de larges structures [20] en environnement hostile, comme dans l espace [21]. Dans ce cadre où la probabilité d échec d un robot en autonomie est importante, la notion d autonomie glissante (Sliding Autonomy) est introduite ( [22]). Tous ces travaux montrent que, dans de nombreux cas de figure, il peut 1 http ://www.swarm-bots.org 48

être intéressant de favoriser la coopération inter-robots, mais que cela implique un cadre de planification et de décision très complexe, dont le développement n est pas encore achevé. Un exemple de scénario de search & rescue, dans lequel la coopération des robots entre eux et avec les humains est primordiale, est exposé en 7. 49

Deuxième partie Scénarios d étude 50

Chapitre 7 Scénario de search & rescue 7.1 Contexte Dans la présentation des réseaux ad-hoc effectuée précedemment on a évoqué le déploiement d une équipe d intervention dans une situation de crise. Ce scénario, fictif, est l illustration d une situation de ce type, où les robots remplissent une fonction de recherche et de sauvetage (search & rescue). Contexte : Une ville de taille moyenne à importante a subi un tremblement de terre de forte magnitude dans les heures précédentes. L environnement est instable et rend la progression dangereuse. La majorité des routes sont coupées, les moyens de communication traditionnels sont inutilisables et l alimentation électrique fait défaut. L équipe de secours sur laquelle nous nous focalisons est chargée d intervenir sur un bâtiment de plusieurs étages qui s est effondré, piégeant une certaine partie de ses occupants. Plusieurs personnes sont blessées et incapables de se déplacer pour chercher une sortie. L accès à l endroit où elles se trouvent peut être impossible à des sauveteurs ainsi qu à leurs chiens, à cause de l exigüité du passage. Les victimes ont un besoin immédiat d assistance médicale, psychologique et alimentaire (le secours médical ayant une priorité accrue). Les sauveteurs doivent acquérir avec la plus grande précision possible la connaissance de la topologie des lieux, du nombre et de l état des victimes présentes à l intérieur du bâtiment, de la présence ou non de matériaux dangereux/inflammables/explosifs, ainsi que de tout risque potentiel pouvant menacer leur intervention comme des départs d incendie ou des zones d effondrement potentielles. Chacun d eux doit pouvoir être contacté à tout moment par n importe lequel des robots d exploration/sauvetage, ainsi qu être en mesure de demander des informations sur les données recueillies par les capteurs qu ont déposés ces mêmes robots. Les robots peuvent également avoir un rôle de maintien de la connexité 51

réseau, de façon transparente pour les utilisateurs de ce réseau. Ce scénario se veut représentatif d un cas assez classique de search & rescue, montrant toutes les tâches possibles qui peuvent incomber aux robots assistant ou remplaçant l équipe d intervention humaine. Les sections qui suivent traitent parfois de fonctions peu envisageables pour des robots aujourd hui (par exemple, celle de secouriste), mais le scénario lui-même exige de se projeter de quelques années dans le futur pour être à même d envisager rationnellement les applications possibles des technologies dont il est question dans ce rapport. 7.2 Aspect matériel Spécifications des robots d intervention On définira ici les contraintes de conception pouvant s appliquer aux robots d intervention (les intervenants polyvalents les plus ordinaires ), ceci n incluant pas les intervenants plus spécialisés qui seront évoqués dans la section suivante. Contraintes d ordre pratique Le robot doit pouvoir être transporté avec son matériel dans un seul sac, idéalement un sac à dos. Le sac doit contenir le robot en assurant une protection minimale et un certain confort pour l utilisateur, sans le gêner dans ses mouvements. Le robot doit pouvoir fonctionner dans un intervalle de température assez large (la contrainte concerne l électronique embarquée mais surtout ici la coque qui protège les composants), car en tant que système modulable le robot peut avoir à intervenir dans des environnements très froids (on retient le cas de l accident de Tchernobyl, qui si il avait eu lieu durant l hiver aurait contraint les équipes d intervention à travailler dans des températures descendant plusieurs dizaines de degrés celsius au-dessous de zéro) à très chauds (dans le cas d opérations dans des bâtiments en flammes par exemple, la température d intervention peut atteindre plusieurs centaines de degrés celsius). La coque du robot doit autant que possible isoler l électronique embarquée de ces variations de température. Le robot doit pouvoir subir un nettoyage complet et rapide, notamment après une intervention dans un milieu présentant un risque d exposition 52

à des substances toxiques, radioactives, ou à du sang pour les robots de secours médical. Idéalement, le robot devrait être totalement étanche (notamment dans le cas où l exploration d un bâtiment passe par la traversée d une flaque plus ou moins étendue et plus ou moins profonde d eau ou d autres liquides). Si la satisfaction de cette contraite n est pas envisageable, l étanchéité doit au minimum se limiter à la protection contre les projections d eau (pour le nettoyage par exemple) et le ruissellement (toujours dans le cadre d une activité d exploration d un bâtiment endommagé). La coque du robot et tous ses composants externes doivent être de couleur vive pour des raisons simples : ceci garantit plus une grande visibilité notamment dans l obscurité (on peut également penser à des surfaces réflechissantes), et une identification plus aisée autant pour les secouristes que pour les victimes (ex : un robot-secouriste doit pouvoir rapidement être identifié comme tel par la personne qui va être soignée). Contraintes d ergonomie sur l interface homme-machine Comme le montrent les expériences menées par les équipes des docteurs Kumar/Rus/Singh [23], il est important que la surface d affichage soit relativement conséquente : on retient que la taille d un écran de PDA (au maximum 3.7 ) est jugée insuffisante par les secouristes. L affichage doit être clairement visible en plein jour comme dans l obscurité, sans toutefois gêner la visibilité globale dans le second cas (adaptation de luminosité nécessaire). L affichage ne doit pas être perturbé par les conditions extérieures, ceci pouvant inclure : des variations importantes et rapides de température, des projections de liquides divers et de neige, des collisions avec de petits objets potentiellement en feu ou encore des rayonnements électromagnétiques. L interaction entre le robot et l opérateur humain doit tenir compte de l équipement potentiel porté par ce dernier : gants, casque, lunettes de vision nocturne ou masque respiratoire. Autres contraintes : Le MTBF (Mean Time Before Failure) de chaque robot doit être de plusieurs dizaines d heures pour garantir un faible taux de panne en mission lorsque que plusieurs robots participent à l opération. A titre de comparaison, une étude menée par le Ft. Leonard Wood (Missouri) stipule un MTBF minimal de 96 heures pour des robots militaires. 53

Equipement embarqué Contrainte sur les composants : malgré les mesures prises dans la conception de la coque du robot pour minimiser les interactions entre le milieu extérieur et l équipement électronique, les composants peuvent avoir à fonctionner dans des conditions difficiles : présence de fumée, de poussière, de vapeur ou goutelettes d eau en suspension, de radiations électromagnétiques ou nucléaires, ou encore de vapeurs explosives à l intérieur même de la coque. De même, la protection externe ne peut pas complètement isoler les composants des variations brusques de température ainsi que du vide. Le robot doit embarquer un haut-parleur de façon à pouvoir transmettre des informations à une personne ou à un groupe de personnes sur le site d intervention qui ne seraient pas équipés de leur propre système de communication (des victimes ou des secouristes ne possédant pas d équipement radio). Le robot doit posséder un dispositif d éclairage puissant et à large balayage mais non-éblouissant ; on préfèrera aux ampoules à incandescence ou halogènes traditionnelles, les technologies d éclairage par LED haute luminosité car celles-ci ont une plus grande durée de vie, sont plus résistantes et minimisent le risque d ignition. Chacun des robots doit intégrer un système de boîte noire qui enregistrera les données mesurées par le robot, les actions entreprises, etc. pour autoriser une reconstitution de l opération a posteriori. A noter qu un système similaire de sauvegarde en temps réel peut être envisagé à distance par le biais de l équipement de communication sans-fil du robot, mais il faut considérer les contraintes de bande passante et de couverture réseau. Le robot doit offrir une baie de connexion pour capteurs offrant un nombre de slots sufffisant, une interface de communication standardisée (type USB, RS232) permettant une connexion/déconnexion à chaud et une bande passante globale suffisante pour répondre aux besoins simultanés de communication de l ensemble des capteurs. A noter que si cette baie gère de façon indépendante la priorité des données transmises à l UC en fonction du type de capteurs, ceci décharge l unité de traitement en aval. Les robots peuvent avoir à placer des capteurs autonomes (caméras, micros, capteurs de température, etc.) à certains endroits. Ils doivent en conséquence être équipés d un dispositif leur permettant de déposer ces capteurs avec une certaine précision et sans choc violent, ainsi que de les récupérer ensuite si nécessaire ; on peut penser par exemple à un 54

système de fixation magnétique. Capteurs importants Cette contrainte varie évidemment en fonction des missions. Globalement, les capteurs doivent pouvoir tirer leur alimentation de la batterie centrale du robot, sauf en cas de besoin particulier. Ces capteurs doivent pouvoir être branchés et débranchés à chaud. Ils doivent être, au moins dans une certaine mesure, standardisés pour s adapter à la baie de connexion évoquée plus haut. Un capteur de température est strictement indispensable, car il dispense une information primordiale sur la viabilité de l endroit pour les intervenants humains comme robotisés. Tout aussi importante, une caméra vidéo (couleur de préférence) doit être embarquée sur la plupart sinon la totalité des robots. La présence d un zoom optique puissant peut être primordiale dans certaines missions. Un micro peut compléter cet équipement élementaire, son rôle sera de fournir des informations supplémentaires sur l environnement aux secouristes. On peut songer à un système de localisation stéréophonique simple avec plusieurs micros pour obtenir un positionnement des sources sonores retransmises. Dans les environnements très sombres, les robots peuvent également embarquer des dispositifs de vision nocturne, éventuellement à rajouter sur la caméra de l équipement standard. Pour les missions de recherche de victimes, un capteur infrarouge de type FLIR peut être employé. A noter qu il n existe pas à l heure actuelle de solution efficace de navigation se basant uniquement sur la vision infrarouge pour des robots terrestres. Les robots peuvent également embarquer des capteurs plus spécialisés, comme le capteur de sélection (Triage Sensor) de Radiance Tech 1 dont le rôle est de conclure rapidement quant à l état d une victime : vivante ou morte. Autres robots En plus des robots polyvalents évoqués dans la section précédente, les besoins de l application peuvent amener à recourir à d autres machines présentant des caractéristiques différentes, notamment pour ce qui est du moyen de locomotion : 1 http ://www.radiancetech.com/products/triage sensor.htm 55

Les robots-serpents Il est généralement admis par les secouristes que le délai avant le dégagement des victimes coincées sous les décombres d un sinistre ne doit pas dépasser 48h sous peine de voir leurs chances de survie s approcher dangerereusement de zéro. Fréquemment, les robots traditionnels ne sont pas plus aptes que les secouristes ou leurs chiens à s engager sur la zone d intervention car soit les orifices sont trop petits, soit le terrain est trop accidenté. Les robots serpents résolvent ce problème car, en plus de posséder une section transversale très réduite, ils ont un grand nombre de degrés de liberté. Ceci leur permet de se mouvoir dans des environnements très difficiles d accès, y compris des tuyaux de ventilation par exemple. De plus, leur mode de propulsion (pneumatique ou hydraulique) réduit le risque d ignition et leur construction hyper-redondante leur permet de fonctionner même si des modules sont endommagés ou en panne. Le robot Moccasin II [24] a été développé dans le but de progresser de façon autonome dans un réseau de tuyaux complexes incluant des virages à 90 o et des sections verticales tout en portant un nombre de capteurs suffisant pour transmettre des informations importantes sur l environnement et les victimes éventuelles découvertes. Le projet SnakeFighter 2 [25] initié en 2003 par le groupe SINTEF a amené à la création d un prototype de serpent-robot incluant une puissante lance à incendie pour combattre les flammes. Le robot, nommé Anna Konda, est avant tout une sorte d extincteur très sophistiqué mais ceci montre bien que les technologies actuellement étudiées sont prometteuses et peuvent aboutir à des intervenants autonomes jouant un rôle réellement crucial dans les opérations de search & rescue en milieu très hostile. Les drones-hélicoptères Il est fréquent que les secouristes arrivent sur les lieux du sinistre sans connaître précisément la topographie exacte du site ni l état de dommage des bâtiments. Dans ce cas, il peut être très utile d utiliser de petits drones de reconnaissance dont le but sera d établir une carte de l environnement, de transmettre des informations sur celui-ci et éventuellement d effectuer diverses actions comme la récupération ou la dépose d objets à des endroits précis. Un hélicoptère autonome dont le déplacement sera basé sur un système de guidage GPS et/ou un odomètre visuel couplés à une centrale inertielle, 2 http ://www.sintef.no/content/page1 5501.aspx 56

pourra remplir ce rôle. Le projet HELI (autonomous HELIcopter) 3 du Robotics Institute de l université Carnegie Mellon a abouti à la création d un petit hélicoptère qui a la capacité de décoller et d atterrir seul, de suivre une trajectoire définie, mais également d établir une carte en 3D de l environnement qu il surplombe ainsi que d identifier et manipuler des objets avec une précision accrue. 7.3 Aspect réseau Une fois présentés les différents types de robots pouvant intervenir dans le scénario évoqué, il convient de se rapprocher de la partie réseau du problème, et de considérer l architecture et les besoins du réseau que constitueront les différents intervenants. Dans le cas présent, les robots ont plusieurs fonctions : ils doivent recueillir les données recueillies par les capteurs, (les traiter) et communiquer des informations découlant directement ou indirectement de leur analyse à des opérateurs humains, d autres robots ou une station de base. Ils peuvent aussi avoir à assurer le maintien de la connexité du réseau de façon transparente pour les intervenants humains, ou à les alerter lorsque cette connexité est menacée. La section suivante expose les communications typiques qui peuvent transiter par le réseau dans le scénario étudié. L indication du choix des technologies employées est simplement indicatif et vise seulement à rendre compte concrètement des besoins de chacune des transmissions. Le choix proposé se base principalement sur les spécificités des technologies en ce qui concerne (dans cet ordre) la portée, le débit, la consommation et la sécurité. Communications entre les robots sur site et les intervenants humains Description : transmission d ordres et de requêtes de données des secouristes vers les robots, transmissions d images et de données issues des capteurs des robots (sous forme de cartes dynamiques) vers les secouristes. Contraintes : beaucoup d obstacles, forte mobilité Technologie : 802.11g Architecture : ad-hoc Des secouristes vers les robots Protocoles : AODV, TCP 3 http ://www.cs.cmu.edu/afs/cs/project/chopper/www/capability.html 57

QoS : fiabilité totale, ordre total, délai faible, gigue moyenne Débit : quelques dizaines de kbit/s Des robots vers les secouristes Protocoles : AODV, TCP, UDP QoS (cartes dynamiques) : fiabilité totale, ordre total, délai faible, gigue moyenne QoS (transmission audio/vidéo) : fiabilité partielle, ordre total, délai moyen, gigue nulle Débit : de quelques centaines de kbit/s (cartes) à quelques Mbit/s (vidéo) Communications entre les capteurs et les robots Description : transmission des données reçues par les capteurs pour traitement par des unités de calcul plus puissantes (robots) avant la transmission aux intervenants humains sous une forme plus fonctionnelle. Contraintes : application pouvant être temps-réel, flux de données constant, transmission orientée économie d énergie Technologie : Zigbee Architecture : ad-hoc Protocoles : AODV simplifié (protocole de routage retenu par la Zigbee Alliance), protocole de transport propriétaire (pas de support de TCP/IP) QoS : fiabilité totale, ordre total, délai faible, gigue très faible ou nulle Débit : quelques dizaines de kbit/s au plus (limité par la technologie). A noter que ce cas ne concerne que les capteurs fournissant des informations à très faible débit comme les capteurs de température ou de radiations ; ces capteurs peuvent être déjà en place lorsque les robots arrivent sur les lieux, c est pourquoi ils doivent adopter une politique d économie d énergie. Mais on peut aussi vouloir déposer à un endroit précis une caméra de surveillance par exemple, qui devra donner un aperçu de l évolution de la situation à l endroit où elle a été déposée. Ce type d application ne rentrant pas dans le cadre de cette section, on peut considérer qu une caméra vidéo est similaire à un robot restant stationnaire, et donc utilisant 802.11g. Analyse Il convient ici de justifier les choix qui ont été faits : Tout d abord, le choix de 802.11g, c est-à-dire le Wi-Fi de deuxième génération, dans le cas des communications entre les robots et les se- 58

couristes : si 802.11b et g ont en théorie la même portée, la norme g offre un débit supérieur (en pratique, au moins une dizaine de Mbit/s en environnement assez encombré) pour une consommation sensiblement égale ; et si c est cette consommation qui est le principal inconvénient des technologies Wi-Fi, il existe aujourd hui de nombreux chipsets destinés aux périphériques portables (notamment les ordinateurs) assez peu gourmands en énergie. De plus, les robots ou secouristes peuvent embarquer des batteries suffisantes pour assurer des communications pendant plusieurs heures. A noter que la norme 802.11n constituerait un excellent remplacement dans ce cas, puisque les débits peuvent atteindre plusieurs dizaines de Mbit/s en environnement très encombré grâce aux algorithmes de prise en compte des réflexions sur les obstacles, tout en augmentant la portée et en assurant une rétrocompatibilité avec le matériel 802.11 b/g. Mais à l heure actuelle ce standard est en cours de normalisation et il n existe pas d équipement fiable disponible. Ensuite, le choix du protocole de routage : on a affaire ici à un réseau adhoc de taille limitée (quelques dizaines de noeuds maximum, puisque les capteurs utilisant Zigbee ne font pas partie du même réseau) et fortement mobile. Comme l indique la comparaison de l étude (ref. F22), c est le contexte dans lequel un protocole de routage réactif tel qu AODV donnera les résultats les plus probants. Enfin, on peut s interroger sur l absence de l emploi d un protocole de sécurisation des communications sur le réseau IP. L inconvénient principal d un protocole comme IPSec 4 est le surcoût qu il génère en termes de bande passante utilisée et de chiffrement/déchiffrement des données. On lui préfèrera un standard de sécurisation des communications 802.11 comme WPA ou WPA2. Le réseau Zigbee pourra utiliser de son côté un algorithme courant de chiffrement des données comme DES ou 3-DES (cf. section sur la sécurité, 9.6). 4 http ://tools.ietf.org/html/rfc2401 59

Chapitre 8 Scénario de surveillance active 8.1 Contexte Une autre application envisageable des réseaux ad-hoc, évoquée plus haut, est la mise en place d un réseau de capteurs communiquants dans un but de surveillance et de prévention. Ici, le cas étudié est celui de la surveillance d une zone forestière. Contexte : Une zone non-urbaine géographiquement étendue est le théâtre potentiel de feux de forêts désastreux pour son écosystème. La surface importante, ou l impénétrabilité et l hostilité du milieu ambiant rendent très difficiles la surveillance efficace de la zone par des moyens classiques. Un nombre important de capteurs est donc largué par avion sur la zone, chacun embarquant assez de logiciel et de matériel pour assurer les fonctions suivantes : création d un réseau ad-hoc reliant tous (ou une grande majorité si la dispersion géographique est trop grande par endroits) les capteurs, très robuste de par sa capacité à s auto-organiser et à faire face à la défaillance/disparition d un ou plusieurs noeuds. gestion par le protocole d accès au médium (couche MAC) de la priorité entre des paquets de types différents. possibilité pour chacun des capteurs de se localiser d une part par rapport aux autres capteurs, et d autre part de façon absolue par un système de positionnement global type GPS. emploi d une technologie de communication sans-fil permettant d une part, la transmission rapide et sûre d un volume de données relativement restreint (mesures périodiques) et d autre part, une autonomie suffisante pour des missions longue durée (plusieurs mois voire plusieurs années sans intervention humaine). 60

communication du réseau avec un ou plusieurs noeuds disposant d une capacité de traitement plus importante, et capables d analyser les données reçues des capteurs et d en tirer des informations exploitables par un logiciel de surveillance local ou distant et/ou un opérateur humain distant. Ces noeuds particuliers doivent être capables de communiquer des alertes avec une portée beaucoup plus grande (plusieurs dizaines ou centaines de kilomètres), ceci ne devant pas affecter l autonomie globale du système. Cependant, il est envisageable que ces stations particulières et peu nombreuses (une seule étant nécessaire au sein de chaque réseau) soient sujettes à une maintenance un peu plus fréquente (typiquement quelques semaines ou quelques mois). item possibilité pour un de ces relais de demander une mesure instantanée à n importe lequel des capteurs, dans un souci d information simple ou de confirmation d alerte. Dans ce cas de figure, on a affaire à un traitement de l information qualifié d informatique diffuse, ou pervasive computing (cf. 2). 8.2 Aspect matériel Il y a ici deux types d intervenants : les capteurs, et le ou les relais utilisant une double interface de communication. Spécifications des capteurs Si l on considère tout d abord les contraintes de conception, la première qui vient à l esprit est qu il s agit d électronique endurcie, puisque les capteurs doivent fonctionner à l extérieur, 24h/24, et quelles que soient les conditions météorologiques. Un package très résistant est donc nécessaire, totalement étanche et relativement isolant. Si l antenne n est pas incorporée dans le boîtier, celle-ci doit également être renforcée pour résister à l usure, à la corrosion ou même au passage d un animal sauvage. Une autre contrainte forte existe quand au mode de déploiement du réseau : les capteurs étant largués par avion, il y a deux solutions : soit le boîtier est conçu pour résister et surtout protéger l electronique embarquée contre un choc à plusieurs dizaines de mètres par seconde, soit chacun des boîtiers intègre un petit parachute biodégradable en quelques jours (à noter que cette solution augmente le risque de voir un grand nombre de capteurs stoppés par le feuillage des arbres). 61

Spécifications des relais de communication Ce ou ces relais étant déposés à la main, il n y a pas les mêmes contraintes de résistance aux chocs que sur les capteurs. Cependant, on retrouve les mêmes contraintes d isolation et d étanchéité, d autant plus importantes ici que le relais peut intégrer des prises d entrée/sortie pour intervention ou mise à jour manuelle, et qu il existe une trappe permettant d accéder aux batteries pour les remplacer. Equipement embarqué 8.2.0.1 Capteurs Du côté des capteurs, l accent est mis sur le faible coût de production. La carte présentée ici est celle du système MICAz, produit par la société Crossbow 1. Ce système est destiné à équiper des réseaux de capteurs sans fil et embarque une puce Zigbee. Le capteur peut être conçu comme indiqué en figure 8.1. Fig. 8.1 Composition d un mote MICAz basé sur Zigbee Le coeur du capteur est constitué par un microcontrôleur, épaulé par de la mémoire Flash en quantité très limitée. Sa consommation électrique est très faible : de l ordre de 10mA, avec un mode veille à 15µA. Ce microcontrôleur fait tourner TinyOS, système développé par l université 1 http ://www.xbow.com/products/productsdetails.aspx?sid=101 62

de Berkeley spécialement pour les réseaux de capteurs sans fil, regroupant un panel de bibliothèques très complet : protocoles réseau, pilotes de capteurs et outils d acquisition, tout en minimisant le volume de code embarqué. La quantité de mémoire nécessaire est très faible, ceci contribuant à diminuer les coûts de production : si la pile protocolaire Zigbee complète nécessite 32 Ko de mémoire pour être implémentée, 4 ko sont nécessaires à un simple noeud. TinyOS, quant à lui, ne pèse que 300 octects dans les distributions minimales, ajoutés à 4 Ko de mémoire vive pour l exécution. A titre d exemple, le système MICAz embarque uniquement 128 Ko de mémoire flash plus 512 ko pour l enregistrement des mesures effectuées. L émetteur-récepteur radio présente une consommation très faible en émission/réception et posséde un mode veille beaucoup plus économique encore où le circuit ne fait que surveiller le médium en attente d une communication. La consommation est de l ordre de 15mA en émission, 20mA en réception, et quelques µa en mode attente (idle). Ces besoins énergétiques sont assurés par deux piles AA (2500mAh environ), assurant une autonomie pouvant aller jusqu à plusieurs années en fonction de la fréquence d utilisation du réseau. Le capteur embarqué peut être de plusieurs types : détecteur de chaleur, détecteur de fumée ou détecteur de flammes. Dans le cas présent, les capteurs possédant le meilleur rapport fiabilité/coût sont certainement les capteurs utilisant la technologie IR 2. Ces capteurs présentent également l avantage d avoir une consommation très faible, adaptée à une utilisation sur batterie. 8.2.0.2 Relais de communication Ce ou ces noeuds particuliers du réseau ont un rôle double : d une part, ils traitent l information transmise par les capteurs pour en dégager une représentation intelligible des données collectées. D autre part, ils jouent le rôle d intermédiaire entre le réseau de capteurs et les opérateurs humains, en offrant une interface de connexion (avec ou sans fil) avec un PC pour intervention en local ainsi qu un dispositif de communication sans-fil à longue portée de type radio ou cellulaire. Ce relais peut être différent architecturalement des capteurs car il doit embarquer plus de puissance de calcul, de façon à traiter efficacement 2 http ://www.ineris.fr/badoris/pdf/substances combustibles en entrepots/entrepots - detection incendie V2.htm 63

toutes les données reçues, ainsi qu une interface supplémentaire lui permettant de communiquer avec la station distante. Le relais intègre une interface Zigbee identique ou compatible avec celle des capteurs. Le relais doit possède une interface standard (USB, RS232, Ethernet, WiFi) de connexion pour un opérateur, de manière à permettre les opérations de maintenance comme la réparation logicielle ou la mise à jour du firmware. L interface WiFi présente l avantage de pouvoir être utilisée également pour les transmissions interrelais. Le chipset de celleci doit impérativement présenter un mode veille (le circuit est passif et se réveille uniquement sur réception d un paquet ou sur requête interne) par souci d économie d énergie. Le relais doit être capable de transmettre les données issues du traitement des mesures au central de surveillance situé à une distance d au moins quelques dizaines de kilomètres. Ces communications peuvent reposer sur deux technologies distinctes : la transmission radio sur ondes UHF, offrant une portée de l ordre de quelques dizaines de kilomètres en terrain dégagé, avec des débits relativement faibles (au maximum quelques dizaines de kbit/s). La société Comatis par exemple propose des solutions adaptées à ce type d applications 3. les communications cellulaires, reposant sur les réseaux de téléphonie mobile : GSM/GPRS/UMTS/HSDPA. Cependant, l emploi de ce mode de communication repose totalement sur la couverture de la zone de surveillance. Etant donné que l application considérée concerne des zones situées loin des agglomérations et donc peu susceptibles d être couvertes par les réseaux de nouvelle génération, il faudra donc en général opter pour une connexion GSM offrant un débit maximum de 9,6 kbit/s ou au mieux une connexion GPRS (40 kbit/s). De plus, ces moyens de communication sont soumis aux aléas techniques des opérateurs les fournissant, et ne sont donc pas forcément adaptés à une application dans laquelle il faut parfois transmettre des alertes extrêmement prioritaires, et ceci en temps réel. A noter qu il serait théoriquement possible de supprimer l interface de connexion locale pour effectuer toutes les opérations à distance, mais il n est pas envisageable de faire une mise à jour ou une intervention en utilisant un débit aussi faible. 3 www.comatis.com/pdf/fh1g4 fr.pdf 64

8.3 Aspect réseau Actualisation de la mesure par un capteur Description : transmission, à intervalle de temps fixe, des données perçues par les capteurs de point à point jusqu au relais qui les rassemble sous une forme exploitable pour un opérateur distant. Contraintes : Le paquet relayé doit contenir l identification du capteur émetteur. La communication a une priorité faible et obéit à une contrainte d économie d énergie forte. Technologie : Zigbee Architecture : ad-hoc Protocoles : (E)AODV, protocole de transport propriétaire. QoS : seule la fiabilité compte ici, il n y a pas de réelle contrainte sur le délai. Débit : quelques kbit/s pour l émission ou le relais d un paquet, sur une durée très courte (exemple : 2 1s d émission toutes les heures pour chaque capteur). Transmission d une alerte d un capteur à un relais Description : en cas de donnée jugée anormale par le capteur (comparaison à une valeur de référence, ou opération arithmétique simple comme calcul du taux d accroissement instantané), il peut envoyer un message d alerte à un relais pour que celui-ci transmette l alerte. Contraintes : pas de contrainte énergétique, priorité très forte. Technologie : Zigbee Architecture : ad-hoc Protocoles : (E)AODV, protocole de transport propriétaire. QoS : fiabilité totale, délai faible. Débit : quelques kbit/s Requête de transmission d information d un relais à un capteur Description : sur demande d un opérateur humain par exemple, le relais fait une demande d actualisation de la donnée fournie par un capteur. Le relais peut aussi demander une confirmation de valeur anormale à un capteur proche de celui qui l a signalée pour vérification. Contraintes : contrainte énergétique faible, priorité forte. Technologie : Zigbee Architecture : ad-hoc Protocoles : (E)AODV, protocole de transport propriétaire. QoS : fiabilité totale, délai faible. 65

Débit : quelques kbit/s Transmission interrelais Description : dans le cas où il existe plusieurs relais qui centralisent chacun les informations d une zone, ces relais peuvent communiquer entre eux, par exemple pour transmettre des informations sur leurs zones de surveillances respectives. Contraintes : contrainte énergétique plus faible que dans le cas de la transmission d une donnée à un relais, priorité assez faible. Technologie : Wi-Fi (voir plus bas) Architecture : ad-hoc (routage proactif) Protocoles : AODV, TCP QoS : fiabilité totale, ordre total. Débit : quelques dizaine de kbit/s à intervalles réguliers. Remarque : le choix de Wi-Fi pour la norme de communication sans fil peut paraître étonnant en raison des distances pouvant séparer les relais (au moins quelques centaines de mètres), mais il existe des solutions pour étendre la portée des réseaux Wi-Fi sans pour autant augmenter drastiquement la consommation, comme la construction d antennes longue portée artisanales (la fameuse antenne Ricoré 4 ). Des sociétés telles que RadioLabs 5 proposent également des produits spécialement étudiés pour répondre à ce besoin d extension de portée. Il est ainsi possible d obtenir une portée de plusieurs kilomètres très facilement avec un débit soutenu (le record dans le domaine est de 200 kilomètres 6 ). Ceci, associé à l utilisation d un mode veille (les chips de la société Nanoradio 7 par exemple ont une consommation en veille de 0.09mA) permettrait une communication moyen débit efficace à moyenne portée entre les relais. Communications entre opérateur distant et relais Description : ici, l objectif est de transmettre les informations provenant du réseau à ou aux stations de surveillance (par exemple, une antenne régionale du réseau de lutte contre le feu) situées à une distance dépassant la portée des technologies employées jusqu à maintenant dans ce scénario (Zigbee et WiFi). 4 http ://yves.maguer.free.fr/wifi/page wifi yves.html#peut-on faire une mauvaise - antenne ricore 5 http ://www.radiolabs.com/products/antennas/2.4gig/2.4grid.php 6 http ://www.wifiworldrecord.com 7 http ://www.nanoradio.com/?navid=273 66

Contraintes : communication ne devant pas interférer avec les transmissions évoquées précedemment, à longue portée et nécessitant un certain niveau de sécurité (notamment par exemple pour prévenir les fausses alertes dues à une mauvaise utilisation du canal). Technologie : communications UHF QoS : fiabilité totale, ordre total, délai faible Débit : jusqu à quelques dizaines de kbits/s Analyse : Il convient ici de justifier les choix qui ont été faits ; le choix des technologies a été simple ici : le scénario de surveillance (appelé aussi télémesure ) en environnement isolé est quasiment un cas d école pour Zigbee, puisque c est un cadre qui permet d exploiter pleinement le potentiel de la technologie, tant au niveau architecture que consommation d énergie. Dans ce cas aussi c est un protocole de routage réactif qui a été retenu car le surcoût généré par le mécanisme d inondation est faible par rapport à celui engendré par le maintien des routes. Ici, les émissions d information sont én général (sauf en cas d alerte) périodiques de période relativement faible : la température est une grandeur qui évolue à faible vitesse. On peut même envisager que les émissions initiées par les capteurs se fassent uniquement en cas d alerte, ce qui réduit encore très largement la quantité de paquets échangés dans le réseau, au profit de la durée de vie des noeuds. Il est ici intéressant de constater qu une architecture en sous-réseaux de quelques centaines de capteurs autour d un relais communiquant (le master node), peut être un réel atout : l architecture cluster tree de ZigBee montre ses avantages dans ce cas ; on remarque qu il est nécessaire de conserver l identification unique de chaque noeud, pour être apte à demander confirmation d une mesure inhabituelle à un capteur en particulier, par exemple. Cette architecture est également plus robuste : si tous les relais sont identiques, l un d entre eux peut prendre sa place lorsqu un autre subit une défaillance, et la grappe de capteurs reliés au noeud en panne peut se distribuer sur d autres noeuds. Concernant le choix de la technologie UHF pour les communications longue distance, celle-ci est clairement la plus adaptée car même en optimisant l utilisation d un signal Wi-Fi comme cela est fait dans le record présenté plus haut, la portée est insuffisante en terrain boisé et potentiellement vallonné. Quant aux technologies de type WiMAX, les implémentations en sont encore au stade de test en général, les normes ne sont pas réellement claires et surtout, l émission sur la bande de fréquences 2-66 GHz est soumise à l acquisition d une licence très onéreuse. 67

Estimation du coût de déploiement d un réseau de ce type : Il peut être intéressant de calculer le coût approximatif des équipements constituant un tel réseau : pour couvrir une zone de 20 20 kilomètres, à raison d un capteur tous les 20 mètres environ, en incluant un facteur de dispersion de 1.2 (du fait du largage par avion de capteurs), on obtient un nombre de capteurs nécessaire égal à 1.200.000. Si l on retient la solution des sous-réseaux et que l on place des relais de communication tous les 200 mètres, cette fois sans dispersion, 10.000 d entre eux sont nécessaires. A raison de 5$ par capteur (composant Zigbee + batterie + microcontrôleur + coque et matériaux divers) et 50$ par relais (double interface de communication + calculateur + batterie + coque et matériaux divers), on obtient un coût total de 6.500.000$ pour une surface relativement limitée à l échelle des grandes zones forestières pouvant nécessiter une surveillance de ce type. Ceci n inclue pas le coût de l installation, de la maintenance, etc. L estimation est arbitraire mais montre clairement qu il faut réfléchir à des solutions d optimisation des dépenses nécessaires à l installation de réseaux de capteurs à grande échelle. 68

Chapitre 9 Autres scénarios 9.1 Exploration et surveillance sous-marines Certaines applications utilisent dans le même contexte des réseaux de robots et des réseaux de capteurs, chacun ayant une tâche différente. On peut prendre comme exemple le projet de réseau de surveillance distribuée par des capteurs (DSSN, Distributed Suveillance Sensor Network) 1 financé par l armée américaine et basé sur le concept de collecte autonome d informations océaniques du MIT (AOSN, Autonomous Oceanic Sampling Network) 2. Le but du programme est de prouver que l utilisation de petits véhicules sous-marins à faible coût est adaptée aux applications de suveillance et d exploration sous-marines. Il est basé sur une flotte de sous-marins qui recueillent des informations sur leur environnement et communiquent par ondes sonores. Chacun d eux vient périodiquement se connecter à une station de raccordement pour décharger de l information, recharger ses batteries et recevoir de nouvelles instructions de mission. La station d accueil est énergétiquement indépendante et n est pas connectée à la rive ou à un bateau par câble : les informations qu elle contient sont transmises en différé aux stations en surface par l intermédiaire d un lien fibre optique à haut débit relié à un robot télécommandé (le Flying Plug), venant se connecter lui aussi à la station d accueil. L architecture est très générale, mais l association de véhicules de type AUV (Autonomous Underwater Vehicle) et de leur charge embarquée (capteurs et équipements divers) permet un large éventail d applications possibles, rendant le concept à la fois très puissant et très flexible. L intérêt dans le cadre du projet est qu à cette flotte mobile peuvent être 1 http ://www.nosc.mil/robots/undersea/dssn/dssn.html 2 http ://auvlab.mit.edu 69

ajoutés un certain nombre de capteurs statiques, dont le but est de recueillir des informations en continu (par exemple le sens et la force du courant autour d une zone sismique). Ces capteurs peuvent éventuellement être déployés hors de portée non seulement de la base, mais également des autres capteurs : c est aux robots sous-marins qu incombe la tâche de servir de relais. Par exemple, lorsqu un sous-marin reçoit l ordre de mission d aller collecter les informations recueillies par les capteurs de toute une zone, il se déplace jusqu à la zone, envoie un stimulus à chacun des capteurs et reçoit les données par une interface de type ZigBee. Ensuite ces données sont rapportées à la station de base, compilées avec le reste des informations et préparées pour analyse en surface. Le principe est exposé en figure 9.1. Fig. 9.1 Le concept du projet DSSN L exemple de DSSN est destiné à prouver la grande diversité d application des concepts concernés par le projet ROSEAU. Aujourd hui, de nombreux projets de recherche sont en cours, mettant à l oeuvre des robots et des capteurs formant un réseau pervasif dont le but est de se substituer à l homme ou de l assister dans des tâches fastidieuses ou dangereuses ; et la liste des applications envisagés ne fait que s allonger. 70

Troisième partie Champs de recherche et interrogations 71

Les concepts et les exemples abordés dans ce rapport soulèvent un grand nombre de questions d ordre pratique : le but de cette partie est de mettre en valeur certaines d entre elles et d y apporter des éléments de réponse. 9.2 Simulation de réseaux Avant l implémentation réelle des protocoles choisis dans les scénarios étudiés, la performance et la fiabilité de ceux-ci doivent être évalués. L utilisation d un réseau ad-hoc réel dans une évaluation est difficile et coûteuse, et de telles expérimentations donnent rarement des résultats significatifs : un réseau réel n offre pas la possibilité de faire varier aisément les différents paramètres de l environnement et pose le problème supplémentaire de la mesure efficace et sans biais des performances obtenues. Pour ces raisons, la majorité des procédures de test utilisent des logiciels de simulation. NS (pour Network Simulator) est une plate-forme de simulation de réseaux TCP/IP. Le logiciel est libre et les sources ainsi que les instructions de compilation sont accessibles en téléchargement sur le site officiel du projet 3. A partir d une configuration (noeuds et liens), on peut simuler un grand nombre d applications réseau et suivre les paquets IP le long de leur trajet. NS se programme avec une version orientée objet de tcl (Tool Command Language), déjà utilisé dans le cadre de développement sur des robots, et qui permet de définir des contextes complexes de simulation. L avantage de ce logiciel est qu un grand nombre de protocoles possèdent une déjà une implémentation tcl conçue pour les simuler (c est le cas d OLSR (cf. 3.4.1.5) et d AODV (cf. 3.4.2.2) par exemple) et qu il convient aussi bien aux réseaux radio qu aux réseaux filaires traditionnels. La fonctionnalité la plus intéressante de ce logiciel est son jumelage avec son frère nam (Network AniMator), qui permet d exploiter graphiquement les résultats des simulations effectuées sous NS et ainsi de suivre facilement tout le trafic du réseau, avec les débits des liens, les congestions, le comportement des noeuds, les pertes de paquets, etc. Ces deux logiciels, sous licence GNU, constituent la référence de simulation dans l étude des réseaux (tout particulièrement des réseaux ad-hoc), notamment dans le milieu académique. Un autre outil très puissant de simulation, commercial celui-ci, est OPNet 4. 3 http ://nsnam.isi.edu/nsnam 4 http ://www.opnet.com 72

9.3 Le problème des interférences radio La possibilité d utiliser dans une même application la technologie Wi-Fi et la technologie ZigBee a été évoquée précedemment. Or, il a été également dit que ces deux standards sont basés sur l exploitation de fréquences autour de 2.4 Ghz : qu en est-il des interférences éventuellement induites? Pour répondre à la question, considérons le diagramme des canaux utilisés par les deux normes : Fig. 9.2 Les canaux utilisés par WiFi et ZigBee Des tests 5 menés par la société Crossbow, fabricant des composant ZigBee MICAz présentés en 8, montrent que lorsque les canaux de communication choisis par les deux types de dispositifs sont confondus (exemple : émission Wi-Fi autour des 2.422 GHz et réception ZigBee sur le canal 15, 2.450 GHz), les pertes de paquets atteignent parfois jusqu à 20%. Il est donc important, dans le cadre d un déploiement réel de ces deux technologies dans la même zone, de choisir scrupuleusement les fréquences d émission et de réception. 5 www.xbow.com/products/product pdf files/wireless pdf/zigbeeandwifiinterference.pdf 73

9.4 Localisation relative et absolue de capteurs Dans le scénario présenté en 8, il est indiqué que les données recueillies par les capteurs peuvent servir à créer une carte de l environnement dans le but de déterminer avec précision d où vient une alerte lorsque celle-ci est déclenchée. Or, il faut pour cela que la position exacte de chaque capteur soit connue, ce qui n est pas évident dans le cas d un largage aérien : pour cela, un système mêlant localisation relative et absolue après largage pourrait être employé. Il suffit en théorie de deux coordonnées géographiques pour définir et orienter un repère. A cet effet, certains des noeuds du réseau (par exemple certains des relais) pourraient embarquer un équipement GPS ; pour prendre en compte également le relief et l imprécision des mesures, il peut être utile d utiliser plus de deux points. Ensuite, chacun des noeuds du réseau pourrait se situer par rapport à ses voisins par l émission d un signal et la mesure du temps mis pour le renvoyer : une fois soustraite à ce temps la durée (mesurable) de rétention du paquet dans le noeud cible, on a accès à la distance séparant les deux noeuds. Cette méthode exige cependant que le microcontrôleur embarqué dispose d un signal d horloge à une fréquence suffisante pour une mesure précise et augmente également la quantité de mémoire embarquée nécessaire pour utiliser l algorithme. Il existe une autre méthode, moins précise mais qui a l avantage de ne pas nécessiter de dispositif supplémentaire sur les capteurs : lorsqu un relais envoie un paquet ZigBee à destination d un autre relais, l algorithme de routage enregistre la route utilisée. Si le critère à satisfaire est la minimalisation du nombre de sauts effectués, on peut considérer que le paquet va emprunter une ligne droite approximative. Ensuite, il suffit de faire transiter les paquets par chacun des noeuds situés entre les deux relais et de mesurer à chaque fois le nombre de sauts effectués : en considérant que la répartitition des capteurs est homogène, on arrive à une représentation approximative de l environnement, suffisante si les capteurs sont peu éloignés. Avec un algorithme efficace utilisant les données recueillies par plusieurs paires de routeurs, la précision de la méthode peut être grandement améliorée. 74

9.5 Utilisation de TCP dans les réseaux adhoc Une large partie du trafic généré dans les réseaux évoqués se base sur les critères de qualité de service de TCP : fiabilité totale, ordre total. On peut logiquement s interroger sur l emploi de celui-ci dans le cadre des réseaux ad-hoc. Le protocole TCP présente les propriétés suivantes : il est orienté connexion, fiable (la délivrance de la totalité des informations envoyées est assurée avec un ordre respecté), c est un protocole bout-à-bout (end-to-end : les seuls contrôles sont effectués par la source et le destinataire), il est indépendant des données, et intègre un mécanisme de contrôle de flux et de contrôle de congestion. De ces cinq propriétés, seule la dernière est dépendante du réseau. Des simulations menées ( [26], [27]) montrent que le mécanisme régulation de débit du protocole cause une large diminution du débit par rapport à l utilisation d UDP, par exemple, dans le même contexte. Les solutions proposées peuvent passer par l emploi non-systématique de l algorithme d évitement de la congestion, la révision des couches MAC et réseau afin de diminuer les pertes, ou la diminution forcée de la charge du réseau afin d éviter les problèmes de compétition d accès. Le rapport [28] présente un résumé du fonctionnement de TCP et le test de certaines solutions à travers un mécanisme de contrôle de la fenêtre de congestion, TCPToK. 9.6 Sécurité dans les réseaux ad-hoc Dans les scénarios évoqués précedemment, la sécurisation des communications peut représenter un enjeu majeur : dès lors que des informations, quelles qu elles soient, sont recueillies sur un environnement et véhiculées sur une certaine distance, elles présentent une vulnérabilité. Ceci est propre au médium radio, qui possède la faculté d être bien plus facilement écoutable que son homologue filaire ; des problèmes de détection d intrusion et de cryptage des transmissions se posent alors. Le traitement de la question passe par l analyse du risque : détermination du contenu sensible, recherche des exigences de sécurité, étude des vulnérabilités, études des menaces et mesure du risque encouru. De nombreuses menaces apparaissent : dénis de service par brouillage du canal radio, par débordement des tables de routage, par refus de fonctionner de certains noeuds, par gaspillage d énergie d un noeud, ou attaque passive par écoute du trafic, usurpation de l identité d un noeud, attaque physique d un noeud isolé, etc. 75

L étude de la sécurité des réseaux ad-hoc ne rentrant pas réellement dans le cadre de cette étude, on pourra se référer aux articles très complets [29] et [30], qui présentent un inventaire des menaces liées au contexte, des attaques potentielles ainsi que des solutions existantes. 76

Conclusion Les réseaux ad-hoc sont aujourd hui au centre de nombreuses recherches et ouvrent la voie à des applications très diverses, dans notre vie quotidienne comme dans des circonstances moins usuelles : les réseaux déployés en cas de catastrophe ou sur un champ de bataille en sont de bons exemples. Le but de ce rapport n était pas de conclure quant à la faisabilité ou la validité des scénarios envisagés, mais de fournir une base de réflexion sur les problèmes qui seront à résoudre dans le cadre du projet ROSEAU : c est dans cette optique que nous avons présenté des concepts et des technologies qui seront abordés et employés dans les études et les réalisations du projet. D une façon similaire, les exemples d application qui ont été présentés ont été imaginés par le rédacteur du rapport dans l intention de cerner et de soulever des problématiques qui leur sont rattachées, et à ce titre ne se réclament pas d une exactitude parfaite. La plus grosse partie du travail reste maintenant à faire : utiliser les informations fournies, et en rassembler de nouvelles, pour développer et créer des réseaux de robots et de capteurs réellement fonctionnels, qui assisteront efficacement leurs utilisateurs dans la réalisation des tâches leur étant attribuées. 77

Bibliographie [1] IEEE Computer Society LAN-MAN Standards Committee. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Strandard 802.11-1997, New York, NY, 1997,. [2] F. Baker and R. Coltun. Ospf version 2 management information base, 1991. [3] A border gateway protocol 4 (bgp-4), 1994. [4] Dimitri P. Bertsekas and Robert G. Gallager. Distributed asynchronous bellman-ford algorithm. In Data Networks, chapter 5.2.4, pages 325 333. Prentice Hall, Englewood Cliffs, 1987. [5] L. Kleinrock and K. Stevens. Fisheye : A lenslike computer display transformation, 1971. [6] Guangyu Pei, Mario Gerla, and Tsu-Wei Chen. Fisheye state routing : A routing scheme for ad hoc wireless networks. In ICC (1), pages 70 74, 2000. [7] Charles Perkins and Pravin Bhagwat. Highly dynamic destinationsequenced distance-vector routing (DSDV) for mobile computers. In ACM SIGCOMM 94 Conference on Communications Architectures, Protocols and Applications, pages 234 244, 1994. [8] Charles E. Perkins and Elizabeth M. Royer. Ad-hoc on-demand distance vector routing. 1999. [9] P. Jacquet and L. Viennot. Overhead in mobile adhoc network protocols, 2000. [10] Jérôme Lebegue. Vers une gestion de groupe sécurisée dans les réseaux ad hoc militaires, 2006. [11] L. Lamont L. Villasenor-Gonzalez, Ying Ge. Holsr : a hierarchical proactive routing mechanism for mobile ad hoc networks. In Communications Magazine, IEEE, volume 43, issue 7, pages 118 125, Res. Center, Ottawa, Ont., Canada, jul 2005. 78

[12] L. Lamont Ying Ge, L. Villasenor-Gonzalez. Hierarchical olsr - a scalable proactive routing protocol for heterogeneous ad hoc networks. In IEEE International Conference on Wireless And Mobile Computing, Networking And Communications 2005 (WiMob 2005), 22-24 Aug., Volume 3, pages 17 23, Res. Center, Ottawa, Ontario, Canada, aug 2005. [13] Haoli Wang Aravind Velayutham. Solution to the exposed node problem of 802.11 in wireless ad-hoc networks. 2003. [14] Imad Aad and Claude Castelluccia. Differentiation mechanisms for IEEE 802.11. In INFOCOM, pages 209 218, 2001. [15] Claude E. Shannon. A Mathematical Theory of Communication. CSLI Publications, 1948. [16] Hannan Xiao, W. Seah, A. Lo, and K. C. Chua. A flexible quality of service model for mobile ad-hoc networks. In Vehicular Technology Conference Proceedings, pages 445 449, Tokyo, 2000. [17] V. Trianni, S. Nolfi, and M. Dorigo. Hole avoidance : Experiments in coordinated motion on rough terrain. In F. Groen, N. Amato, A. Bonarini, E. Yoshida, and B. Kröse, editors, Intelligent Autonomous Systems 8, pages 29 36. IOS Press, Amsterdam, The Netherlands, 2004. [18] R. O Grady, R. Groß, F. Mondada, M. Bonani, and M. Dorigo. Selfassembly on demand in a group of physical autonomous mobile robots navigating rough terrain. In M.S. Capcarrere, A.A. Freitas, P.J. Bentley, C.G. Johnson, and J. Timmis, editors, Advances in Artificial Life : 8th European Conference, ECAL 2005. Proceedings, volume 3630 of LNAI, pages 272 281. Springer-Verlag, 2005. [19] T.H. Labella, M. Dorigo, and J.-L. Deneubourg. Division of labour in a group of robots inspired by ants foraging behavior. ACM Transactions on Autonomous and Adaptive Systems, 1(1) :4 25, 2006. [20] Brennan Peter Sellner, Frederik Heger, Laura Hiatt, Reid Simmons, and Sanjiv Singh. Coordinated multi-agent teams and sliding autonomy for large-scale assembly. Proceedings of the IEEE - Special Issue on Multi- Robot Systems, 94(7), jul 2006. [21] Frederik Heger, Laura Hiatt, Brennan Peter Sellner, Reid Simmons, and Sanjiv Singh. Results in sliding autonomy for multi-robot spatial assembly. In Proceedings of the 8th International Symposium on Artificial Intelligence, Robotics and Automation in Space, sep 2005. [22] Frederik Heger and Sanjiv Singh. Sliding autonomy for complex coordinated multi-robot tasks : Analysis and experiments. In In Proceedings, Robotics : Systems and Science, aug 2006. 79

[23] Vijay Kumar, Daniela Rus, and Sanjiv Singh. Robot and sensor networks for first responders. PERVASIVE computing, pages 24 33, oct 2004. [24] College Engineering News, editor. NC State engineers design pipecrawling robot to help save lives, pages 1,4. NC State University, 2000. [25] P. Liljebäck. Snakefighter - intelligent slangerobot for krevende intervensjoner. Servomøtet, NFA, Trondheim, oct 2005. [26] Al Hanbali Ahmad, Altman Eitan, and Nain Philippe. A survey of tcp over mobile ad hoc networks. Technical report, INRIA maestro, May 2004. [27] Thomas D. Dyer and Rajendra V. Boppana. A comparison of tcp performance over three routing protocols for mobile ad hoc networks. MobiHoc, 2001. [28] Mathias Péron. Tcp et réseaux ad hoc, l évitement de la congestion. 2004. [29] J. LUNDBERG. Routing security in ad hoc networks, 2000. [30] Arun Kumar Bayya, Siddhartha Gupte, Yogesh Kumar Shukla, and Anil Garikapati. Security in ad-hoc networks. [31] Tayeb Lemlouma and Nadjib Badache. Routing in Mobile Ad-hoc Networks. PhD thesis, University of USTHB : Université des Sciences et Technologies Houari Boumediene, Algiers, Algeria, 2000. 80