Mise en contexte des travaux

La méthode d’évaluation présentée dans ce chapitre constitue une contribution substantielle à la recherche. En effet, l’évaluation du protocole de routage AODV qui y a été présentée a été ciblée spécifiquement pour une application de voix sur IP (VoIP). Habituellement, les chercheurs se contentent d’un ensemble de métriques génériques pour évaluer la performance de leur protocole de routage « ad hoc » . La plupart du temps, ces métriques font partie de celles énoncées dans le RFC 2501 décrivant les principales caractéristiques d’un réseau « ad hoc » [Corson et Macker,

1999]. Par exemple, lors de ses travaux sur le routage préemptif, Boukerche s’est arrêté aux métriques de taux de livraison, de délai et de bande passante [Boukerche et Zhang, 2004]. Srinath a utilisé les mêmes métriques, mais s’est de plus intéressé à la charge de contrôle [Srinath et al., 2002].

Or, un précepte bien admis à propos des réseaux « ad hoc » est le suivant :

« Il n’y a aucun protocole de routage qui fonctionne bien dans une grande variété d’environnements de réseaux. » (Traduction libre) [Boleng et al., 2002]

Donc, pour bien évaluer le comportement d’une application donnée, il faut fournir un environne- ment représentatif de cette application. De plus, il a déjà été énoncé à la section 2.6.1 que chaque application a des requis différents pour assurer sa Qualité de Service (QoS). Par exemple, pour la voix sur IP, qui a des besoins spécifiques en termes de délai et de gigue, l’évaluation de la bande passante serait futile. Ceci dit, l’évaluation effectuée dans ce chapitre se démarque donc par deux volets principaux : l’utilisation de métriques d’évaluation spécialisées pour la VoIP et l’utilisation de scénarios de simulation comportant des flux apparentés à la VoIP.

Dans le premier cas, les métriques ont été choisies par rapport à la perception de l’utilisateur. Qu’est-ce que ressent un utilisateur de VoIP ? Bien sûr, il y a premièrement la qualité sonore de la conversation. Toutefois, le réseau utilisé n’a que peu d’effet sur cette perception, celle-ci étant surtout influencée par le codec utilisé pour transmettre la voix. Ensuite, vient la sensation d’éloignement, qui est engendrée par le délai de transmission et la gigue, métriques décrites aux sections 3.1.1 et 3.1.2. De plus, lorsque la fiabilité du réseau laisse à désirer, la perte de paquets viendra causer des coupures dans la conversation. L’impact de ces coupures peut être estimé par les métriques de temps et de fréquence d’interruption respectivement définies aux sections 3.1.3 et 3.1.4. Ces métriques sont fondamentalement différentes de ce que l’on retrouve dans la littérature.

Deuxièmement, les scénarios utilisés pour les simulations utilisent des flux à petits paquets pour mieux concorder avec l’environnement d’une application VoIP, tel que mentionné au début de la section 3.2. Dans la littérature existante, les flux à débit constant utilisent généralement des paquets plus gros, de l’ordre de 512 octets, à intervalle plus long pour un débit égal.

Conséquemment, l’utilisation de nouvelles métriques vient compliquer la comparaison quantita- tive de ces travaux avec ceux retrouvés dans la littérature. Néanmoins, il est possible d’effectuer des comparaisons plus larges sur les observations de ce chapitre. Principalement, les simulations concernant la mobilité des nœuds ont démontré que celle-ci n’avait pas d’influence sur les mé- triques de temps et de nombre d’interruptions. C’est contraire aux observations retrouvées dans la littérature car habituellement la mobilité a un effet sur les métriques [Boleng et al., 2002]. Or,

en investiguant plus longuement, l’analyse a démontré que cet effet n’est pas disparu, mais est plutôt noyé dans l’effet de congestion engendré par les flux à petits paquets (voir section 3.2.3). La congestion additionnelle engendrée par les flux à petits paquets induit un mauvais compor- tement de la sous-couche MAC IEEE 802.11. Ce mauvais comportement est déjà documenté en long et en large dans la littérature, notamment par les travaux de Chaudet, Dhoutaut et Las- sous [Chaudet et al., 2005]. Cependant, l’évaluation présentée dans ce chapitre démontre que l’effet de la congestion est d’autant plus marqué lors de l’utilisation de flux à petits paquets.

D

EUXIÈME

PARTIE

D

ÉVELOPPEMENT DU MÉCANISME DE

DÉVELOPPEMENT DE L’ALGORITHME PRÉVENTIF

L’étude du comportement des réseaux « ad hoc » , réalisée au chapitre 3, a confirmé le besoin de développer un protocole de routage pouvant réagir plus rapidement à la perte de route dans les conditions spécifiques à la transmission du VoIP. Les interruptions de route sont fréquentes lorsqu’on combine un réseau aussi dynamique à des flux de données caractérisés par de petits paquets transmis à fréquence élevée. Bien qu’une bonne partie de la faute incombe à la sous- couche MAC, qui n’a clairement pas été conçue pour une utilisation aussi dynamique, un nombre non négligeable de paquets est perdu lorsque des liens entre nœuds sont brisés à cause de la mobilité.

L’hypothèse envisagée dans la définition de ce projet (voir section 1.1), soit de tenter de prédire la perte de route afin de corriger une situation d’interruption avant qu’elle ne survienne, reste donc viable. De plus, il est possible d’envisager l’utilisation de ce mécanisme préventif afin de rejeter les fausses pertes de lien détectées par la sous-couche MAC empêchant ainsi un protocole de routage de déclencher une recherche de route inutilement.

Ce chapitre est consacré à l’élaboration de l’algorithme de prévention de la perte de route. Tout d’abord, les besoins reliés à cet algorithme seront définis. Ensuite, la théorie derrière le mé- canisme utilisé pour le développer sera présentée. Puis, la conception du filtre elle-même sera abordée. Finalement, un aperçu préliminaire des performances de l’algorithme sera dévoilé.

4.1

Définition des besoins

Avant d’aller plus loin, il serait bon de rappeler les quelques conditions préliminaires qui ont été énoncées lors de la définition du projet de recherche (voir section 1.1). L’algorithme doit avoir ces objectifs principaux :

- Prévenir la perte de route

- S’intégrer à un protocole de routage existant - Délai unidirectionnel sous 400 ms.

- Fiabilité élevée

Les détails précisant chacun des objectifs seront exposés dans les sections suivantes. 65

4.1.1

Prévenir la perte de route

Faisant l’objet du titre de cette thèse, la prévention de la perte de route est le cœur du projet de recherche présenté dans ce texte. La raison d’être de l’algorithme présenté dans ce chapitre est de prévenir la perte de route causée par la mobilité des nœuds des réseaux « ad hoc » .

Le concept de routage « préemptif » a déjà été abordé dans l’état de l’art à la section 2.6.3. Les travaux qui y sont présentés constituent déjà un avant goût de ce que doit être la prévention de perte de route. Le terme « préemptif » y est utilisé pour montrer que la recherche de route est déclenchée avant qu’une perte de route soit détectée, lorsqu’il est jugé qu’un lien approche de la fin de sa durée de vie utile. Il est important de ne pas confondre le routage « préemptif » avec le routage proactif ; en effet, ce dernier ne fait que maintenir en permanence une table de routage vers tous les nœuds du réseau, en contraste avec le routage réactif qui recherche les routes à la demande (voir la section 2.3). Ces deux types de routage peuvent être assortis d’un mécanisme de routage « préemptif » lorsqu’une route est en utilisation. Le principe de base du routage « préemptif » est le même que celui qui mena à l’élaboration de ce projet.

Néanmoins, le mécanisme de détection présenté à la section 2.6.3, basé sur des seuils de puis- sance, ne tient pas compte de deux facteurs importants à ne pas négliger. Tout d’abord, le seuil de déclenchement de la recherche de route a une valeur fixe. Ainsi, plus les nœuds du réseau se déplacent rapidement, plus courte sera la durée permettant d’établir une route alternative sans in- terruption dans le flux de données. Le seuil doit donc être fixé en fonction d’une vitesse arbitraire de déplacement des nœuds. Cette vitesse peut être fixée en fonction de la mobilité maximale que l’on anticipe pour le réseau. Un nœud se déplaçant à une vitesse significativement différente de ce choix arbitraire pourrait fausser l’algorithme et déclencher une recherche de route prématuré- ment ou, pire encore, trop tard. Deuxièmement, la lecture directe de la puissance reçue ne tient pas compte des erreurs possibles de lecture. En effet, la lecture de puissance reçue entre 2 nœuds peut varier de plus de 10 dB entre chaque échantillon, ce qui est énorme [Zrno et al., 2004].

Pour arriver à ces fins et surpasser ces deux difficultés, l’algorithme devra être de nature proba- biliste. Ainsi, il devra évaluer la durée de vie restante d’un lien et tenter de prévoir le moment le plus opportun pour déclencher la recherche de route. De plus, à la lumière des résultats de l’étude préliminaire du chapitre 3 démontrant les faiblesses de la sous-couche MAC, l’algorithme devra aussi pouvoir servir d’outil de quantification de la qualité d’une route afin de s’immuniser contre le mauvais fonctionnement des couches inférieures.

Figure 4.1 Schéma-bloc de l’algorithme de prévention de perte de route

4.1.2

Intégration à un protocole existant

À la section précédente, les besoins fonctionnels de l’algorithme ont été énoncés. Du point de vue structurel, le mécanisme développé devra s’interfacer avec un ou des protocoles de routage existants. Pour ce faire, il est prévu que l’algorithme soit de type « boîte noire », selon le schéma illustré à la figure 4.1.

Ainsi, l’algorithme recevra en entrée des lectures de puissance reçue de chacun des nœuds voi- sins de la sous-couche MAC pour chaque trame reçue. L’algorithme traitera individuellement pour chacun des voisins détectés ces lectures. Si un lien en voie de disparition est détecté, le protocole de routage sera averti qu’un lien qu’il utilise est maintenant faible par une nouvelle interface qui y sera implémentée. De plus, le protocole disposera d’une interface sur l’algo- rithme par où il pourra s’informer de l’état d’une route. Ainsi, l’impact sur le ou les protocoles de routage sera relativement limité parce que le cœur du mécanisme probabiliste sera isolé du protocole original.

4.1.3

Cibles de performance

Finalement, la définition du projet mentionnait deux cibles de performances principales. Tout d’abord le délai unidirectionnel, devant être gardé sous la barre des 400 ms. Il a été énoncé précédemment que le délai ne dépendait pas vraiment du protocole de routage utilisé. Celui-ci

sera tout de même analysé à des fins de comparaison des performances, mais il est peu probable que l’élaboration de l’algorithme ait un effet significatif sur cette mesure de performance. Par contre, en ce qui a trait à la fiabilité élevée, si l’algorithme parvient à prévenir adéquatement les pertes de lien, moins de pertes de routes surviendront et ainsi, moins d’interruptions seront ressenties. La fiabilité sera par conséquent évaluée à l’aide des métriques développées pour l’étude préliminaire du protocole AODV, à la section 3.1.