Brevet FR2878674A1 — publié le 20060602

PROCÉDÉ ET SYSTÈME D'ADAPTATION DYNAMIQUE DE MÉTRIQUE DE QUALITÉ DE SERVICE DANS UN RÉSEAU AD HOC Domaine de l'invention et art antérieur La présente invention concerne le domaine du routage avec qualité de service dans les réseaux dits "ad hoc". Les réseaux ad hoc sont des réseaux de communication, utilisant le medium radio. Ils sont consti :ués de noeuds mobiles et/ou fixes ayant la propriété de constituer automatiquement et dynamiquement un réseau capable d'acheminer des paquets d'un point quelconque du réseau à un autre dès lors qu'une communication radio s'établit entre un noeud et ses voisins. Dans un réseau ad hoc, les paquets sont transmis directement entre le noeud source et le noeud destinataire si ce dernier est dans la zone de connectivité du noeud source ou via des noeuds intermédiaires voisins si le noeud destinataire est hors de portée du noeud source. Par conséquent, les réseaux ad hoc permettent le déploiement instantané de réseaux de communication sans infrastructure préexistante ni gestion centralisée. La formation du réseau se fait d'une manière dynamique, l'ensemble des tâches de gestion étant réparti entre l'ensemble des noeuds du réseau. La caractéristique principale des réseaux ad hoc est que les noeuds appartenant à ce réseau jouent, ou peuvent jouer, le rôle de routeurs. Les noeuds sont donc responsables eux-mêmes de l'établissement et du maintien de la connectivité du réseau d'une manière continue. Cela est réalisé par l'utilisation de protocoles de routage spécifiques qui permettent aux noeuds d'échanger des informations de routage entre noeuds voisins et de calculer des chemins de communication vers tous les autres noeuds du réseau. Ces protocoles de routage émettent des messages périodiquement pour actualiser la topologie du réseau ad hoc (i.e. pour identifier les noeuds et les liens entre les noeuds). Il existe deux familles de protocoles de routage: les protocoles proactifs et les protocoles réactifs. 2878674 2 Pour la famille des protocoles proactifs, chaque noeud a une vision sur tout le réseau grâce à un échange périodique des tables de routage. Tous les chemins sont disponibles directement via la table de routage. Pour la famille des protocoles réactifs, les chemins ne sont disponibles qu'à la demande. En effet, si un chemin vers une destination n'est pas disponible via la table de routage, on lance une requête de recherche de chemin, le résultat de cette requête permettant de récupérer un chemin, s'il en existe un. Dans le cadre de la présente invention, on s'intéresse plus 10 particulièrement aux protocoles de routage proactifs et notamment au protocole OLSR (Optimized Link State Routing). La figure 1 représente les composants du protocole de routage proactif OLSR. Dans ce protocole, on peut distinguer deux composants principaux: un composant de maintenance de la topologie 10 comprenant un module de contrôle de topologie 11 en liaison avec un module de sélection des noeuds du routage 12 et un composant de sélection de chemin 20 comprenant un module ou algorithme de calcul de chemin 21. Le composant de maintenance de la topologie 10 assure, grâce à un échange périodique de messages de contrôle, la construction du graphe de topologie du réseau qui sera par la suite utilisée pour le calcul des chemins. Ce mécanisme permet également de minimiser le surcoût: en trafic réseau en utilisant un mécanisme de sélection des noeuds routeurs, appelés noeuds Multipoint Relais (MPR). Le composant de sélection de chemin 20 calcule, à partir des informations recueillies sur la topologie, les meilleures routes entre les noeuds du réseau en utilisant un algorithme de calcul de chemin sur un graphe (par exemple: algorithme de Dijkstra), le critère de choix des chemins étant le nombre de sauts. Les protocoles de routage proactif ad hoc ont été conçus à la base sans considération explicite de la qualité de service pour le calcul des chemins. Le nombre de sauts est généralement le critère adopté par ces protocoles. Il est clair qu'un tel critère est inadéquat pour des applicat ons en temps réel telles que la vidéoconférence ou la téléphonie. La prise en compte de la qualité de service dans le protocoles de 35 routage passe par la prédéfinition, lors de sa conception, au niveau du 2878674 3 processus de sélection des chemins, de nouveaux critères, appelés métriques de qualité de service. Dans ce cas, comme illustré sur la figure 1, le composant de sélection de chemin 20 comprend en outre un module de gestion de métrique(s) de qualité de service 22 associé à l'algorithme de calcul de chemin 21. Des exemples de ces métriques sont les métriques de délai, de bande passante, de gigue, etc. Les informations concernant les métriques de qualité de service sont injectées au niveau du graphe de topologie. Un nouveau graphe enrichi par ces informations de qualité de service est donc reconstruit et le calcul des chemins est fait en prenant en compte ces métriques. Selon l'art connu, la décision concernant le choix de métrique de qualité de service, qui sert de critère de sélection des chemins, est programmée de manière statique. En conséquence, il est impossible de changer ces critères une fois que le protocole de routage est mis en oeuvre. On observe aussi que les solutions connues préconisent l'usage d'une seule métrique ou d'une combinaison de métriques prédéfinie clans un souci d'optimisation pour un cas donné (bande passante ou délai, fiabilité, énergie, etc.). Cependant, on remarque rapidement les limitations qui résultent d'une telle gestion statique de ces métriques. En effet, lorsqu'une ou plusieurs applications s'exécutant dans un réseau ad hoc sont utilisées conjointement à une détermination des routes basée sur un algorithme de routage utilisant une métrique non adéquate, la qualité de service rendue à ces applications n'est pas la meilleure. Ceci est d'autant plus vrai que les contraintes des applications en terme de métriques de qualité sont généralement différentes les unes des autres. Afin de pallier ces limitations, une solution consiste à mettre en oeuvre une sélection des chemins multi-métriques (ou multi-critères),, ce qui implique la définition d'un algorithme capable de trouver les meilleurs chemins pour toutes les métriques possibles. Cependant, mettre en oeuvre un tel algorithme est impossible et correspond à la situation appelée "problème NP-Complet" en théorie de la complexité des problèmes de décision en informatique (un problème est dit NP-Complet s'il est dans la classe des problèmes de décision pour lesquels la réponse oui peut être décidée par un algorithme non-déterministe en un temps polynomial par 2878674 4 rapport à la taille de l'instance, et si n'importe quel problème NP-Corrplet peut se réécrire à l'aide d'un algorithme polynomial comme un sous-ensemble d'instance de ce problème). Des techniques d'approximation de calcul (à base d'heuristiques) existent, mais elles se limitent à un nombre prédéfini de métriques et leur mise en oeuvre est par ailleurs statique. En conséquence, les mêmes limitations que celles évoquées dans la première situation seront présentes. Obiet et description succincte de l'invention La présente invention vise à remédier aux inconvénients précités et à proposer une solution technique pour adapter un protocole de routage en particulier de type proactif (comme OLSR) de manière à permettre un changement et une mise en oeuvre dynamique des métriques de qualité de service utilisées pour le calcul des chemins dans les réseaux ad hoc, et ce en tenant compte des caractéristiques du réseau et/ou des ressoul-ces nécessaires aux applications utilisées. Ce but est atteint grâce à un procédé d'adaptation dynamique de la métrique de qualité de service qui comprend les étapes suivantes: a) détermination d'au moins une métrique de qualité de service à appliquer à un instant donné basée sur la qualité de service disponible sur le réseau et/ou sur la qualité de service demandée par une ou plusieurs applications, b) transmission à au moins une partie des noeuds du réseau de la métrique instantanée de qualité de service à appliquer, ce qui inclut les modules de calcul et d'insertion des métriques de qualité de service au niveau des paquets de contrôle du protocole de routage, et c) mise à jour de la table de routage des noeuds en fonction de la métrique instantanée de qualité de service à appliquer reçue. Ainsi, ce procédé permet d'appliquer dynamiquement au niveau du protocole de routage la métrique de qualité de service qui correspond au mieux à la fois aux contraintes de l'environnement (nombre de noeuds, densité, degré de mobilité,...) et/ou à l'état du réseau (ressources disponibles et/ou applications en cours d'exécution). 2878674 5 En appliquant dynamiquement la métrique de qualité de service la plus pertinente à un instant donné, la mise en oeuvre des mécanismes décrits dans la présente invention permet de répondre de manière efficace au comportement intrinsèquement dynamique des réseaux ad hoc. A cet effet, dans l'étape a), deux alternatives sont possibles. Dans la première chaque noeud analyse les échanges avec ses voisins et décide par lui-même du choix de métrique, à la manière des réseaux auto-organisés. Dans la seconde, on utilise un gestionnaire de réseau qui supervise l'état des ressources de chaque noeud et/ou des ressources demandées par les applications en cours sur le réseau. Il décide et met en oeuvre les modules nécessaires pour la gestion des métriques de qualité de service adéquates. Dans l'étape b), les métriques de qualité de service à appliquer sont insérées dans des messages de contrôle du protocole de routage. De cette façon, toute nouvelle métrique de qualité de service à appliquer est propagée dans le réseau via des messages génériques de contrôle, les données relatives à cette métrique étant extraites au niveau de chaque noeud grâce à un gestionnaire de métrique. On évite ainsi d'avoir à réécrire le protocole de routage à chaque changement de métrique de qualité de service. Dans l'étape c), le calcul du chemin et la mise à jour de la table de routage en fonction des métriques de qualité de service reçues peuvent se faire directement à partir du module de calcul de chemin du protocole de routage ou à partir d'un module de calcul de chemin externe au protocole. Dans ce dernier cas, le procédé comprend en outre une étape de déploiement dynamique, par exemple par téléchargement, d'un module de calcul de chemin. Le module est alors dit re-programmable. Les étapes du procédé précédemment décrit sont exécutées par un dispositif informatique, en l'espèce au moins un noeud du réseau, sous la commande d'instructions logicielles. Par conséquent, l'invention concerne également un programme d'ordinateur ou module logiciel destiné à être stocké dans ou transmis par un support de données comprenant des instructions logicielles pour faire exécuter le procédé par un dispositif informatique. Le support de données peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un 2878674 6 disque dur, ou bien un support transmissible tel qu'un signal électrique, optique ou radio. L'invention a également pour objet un système de gestion dynamique de la métrique de qualité de service dans un réseau ad hoc, le système comprenant une pluralité de noeuds destinés à former une infrastructure de routage pour l'acheminement de paquets de données, caractérisé en qu'il comprend en outre un gestionnaire de réseau pour déterminer les métriques de qualité de service à appliquer à un instant donné basée sur la qualité de service disponible sur le réseau et sur la qualité de service demandée par une ou plusieurs applications, et des moyens pour diffuser la métrique de qualité de service à appliquer aux noeuds du réseau et en ce que chaque noeud comprend un gestionnaire de métrique pour mettre à jour la table de routage des noeuds en fonction de la métrique de qualité de service à appliquer reçue. Ainsi, le système de l'invention comprend des moyens pour assurer la supervision (Monitoring) du réseau afin d'avoir à tout instant une vision cohérente sur son état, à savoir le taux de ressources disponibles ainsi que les ressources requises par les applications qui sont en cours d'exécution. A partir de ces données, la métrique de qualité de service à appliquer est déterminée et déployée au niveau du protocole de routage via un échange périodique des informations concernant les métriques de qualité de service entre les noeuds du réseau. Cet échange périodique est réalisé au moyen de messages de contrôle du protocole de routage dans lesquels on insert la métrique à prendre en compte. Le gestionnaire de réseau peut être intégré à un ou plusieurs noeuds du réseau, ou être mis en oeuvre dans un terminal spécifique mobile ou filaire disposant d'une connexion au réseau. Le calcul des routes au niveau des noeuds en fonction de la métrique de qualité de service diffusée peut être réalisé par le module de calcul de chemin propre au protocole de routage ou bien être géré de façon externe par un module externe re-programmable de calcul de chemin mutualisé entre plusieurs applications ayant les mêmes exigences de qualité de service ou bien encore externalisé dans les applications pour que chaque application puisse sélectionner les chemins les plus pertinents vis-à-vis de ses contraintes de qualité de service. 2878674 7 L'invention a encore pour objet un terminal mobile ou fixe destiné à former un noeud dans un réseau ad hoc, caractérisé en ce qu'il comprend un gestionnaire de métrique pour mettre à jour la table de routage dudit noeud en fonction d'une métrique de qualité de service instantanée à appliquer. Un tel terminal peut comprendre aussi des moyens pour prendre en compte périodiquement tout changement de métrique de qualité de service déterminé en fonction d'événements survenant dans le réseau et au niveau des applications. Brève description des dessins D'autres caractéristiques et avantages de l'invention ressortiron. : de la description suivante de modes particuliers de réalisation de l'invention, donnés à titre d'exemples non limitatifs, en référence aux dessins annexés, sur lesquels: - la figure 1 représente schématiquement les composants du protocole de routage proactif OLSR; - la figure 2 représente un mode de réalisation d'une architec:ure conformément à l'invention; - la figure 3 illustre un exemple de topologie de réseau ad hoc utilisé pour tester le procédé de l'invention; Description détaillée des modes de réalisation de l'invention La présente invention est destinée à permettre l'externalisation de la gestion des métriques de qualité de service au protocole du routage dans un réseau ad hoc et, par ailleurs, la détermination, la diffusion et la prise en compte de tout type de métrique de qualité de service. A cet effet, l'invention propose une solution technique qui met en oeuvre deux composants principaux, l'un au niveau réseau (gestionnaire de réseau) et l'autre au niveau des noeuds (gestionnaire de métrique), ainsi qu'une extension des paquets de contrôle du protocole de routage. L'invention utilise et adapte (i.e. ajout d'extension) un protocole de routage proactif et notamment un des protocoles de routage proactif les plus connus: le protocole OLSR. Ce protocole est notamment référencé et 2878674 8 décrit sous la dénomination OLSR RFC3626 (Request for Comments) (cf. en particulier le document "Optimized Link State Routing Protocol (OLSR)", Network Working Group, T. Clausen et al., octobre 2003) du Groupe de Travail Manet (pour Mobile Ad hoc Networks) de l'IETF (Inter- net Engineering Task Force). Pour permettre le déploiement et l'application de tout type de métrique de qualité de service au niveau du protocole de routage sans avoir à redéfinir le protocole à chaque changement de métrique, la présente invention propose de réutiliser les messages existants du protocole de routage et non de définir de nouveaux messages. Les messages utilisés sont de préférence des messages échangés périodiquement entre les noeuds du réseau tels que les messages de contrôle TC (Topology Control) dans le protocole OLSR. Toutefois, on peut aussi utiliser des nouveaux messages pour le transport des métriques; de qualité de service. Ainsi, conformément à l'invention, on utilise des messages génériques de contrôle pour transporter toute métrique de qualité de service ainsi qu'une fonction de traitement qui construit au niveau de chaque noeud un graphe sur la topologie réseau; chaque élément du graphe est représenté par un n-tuplet de la forme . Cette topologie sera utilisée ultérieurement par le calcul de route. La diffusion de toute métrique de qualité de service aux noeuds du réseau se fait via de tels messages. Au niveau de chaque noeud, un gestionnaire de métrique propre à l'invention est connecté au protocole de routage. Plus précisément, comme illustré sur la figure 2, un noeud 100 comprend une prem ère couche 110 qui, de façon connue, correspond à la couche du protocole de routage 110 qui utilise notamment une table de routage 1121 et un module ou algorithme de calcul de chemin 1122. La table de routage 1121 est maintenue (i.e. mise à jour) localement dans chaque noeud à l'aide du module de calcul de chemin 1122. C'est la table de routage qui doline l'adresse du noeud voisin auquel il faut transmettre les paquets ou la trame pour que ceux-ci atteignent leur destination selon les métriques de qualité de service définies. 2878674 9 Conformément à l'invention, on ajoute dans la couche 110 un gestionnaire de métrique 111 qui transmet au protocole de routage 112 la métrique (ou la combinaison de métriques) à appliquer au réseau. Le calcul de chemin est alors effectué à partir de cette métrique en utilisant un algorithme de recherche de chemin dans un graphe, tel que par exemple l'algorithme de Dijkstra où les valeurs (ou poids) associées aux arrêtes sont alors données par les valeurs des métriques sélectionnées. Le gestionnaire de métrique est un composant distribué à l'ensemble des noeuds du réseau. Il met en oeuvre, au niveau du noeud, la métrique de qualité de service choisie par le gestionnaire de réseau. Dans ce but, le gestionnaire de métrique installe dans une couche 120 les composants 121 nécessaires à l'insertion de la métrique de qualité de service dans le processus de calcul des chemins. Le gestionnaire de métrique 111 permet également d'indiquer l'existence des modales externes de calcul de chemin 131 au protocole de routage 112. Le protocole de routage pourra donc transférer aux modules externes de calcul de chemin une vue topologique du réseau contenant les métriques sur lesquelles portera le calcul de chemin spécifique au module externe. Ce transfert peut se faire directement ou via un composant spécifique tel que décrit en détail dans la demande de brevet déposée sous le numéro FR 03 12869 et intitulée "Procédé de notification de changements d'état des ressources d'un réseau à destination d'au moins une application, programme d'ordinateur et système de notification de changements d'état pour la mise en oeuvre du procédé". Deux modes sont toutefois possibles: - le mode push: Le protocole de routage transmet périodiquement une vue de topologie aux modules intéressés. - le mode pull: uniquement à l'initiative des modules intéressés pour que le protocole de routage leur transfère les données de topologie. Ces composants de métrique de qualité de service, qui peuvent être déployés dynamiquement ou bien déployés sur chaque noeud lors de son entrée dans le réseau, sont utilisés par le gestionnaire de métrique pour adapter pour le voisinage direct la valeur de la métrique instantanée. 2878674 -10- Par ailleurs, le système de l'invention comprend des moyens pour déterminer la ou les métriques de qualité de service qui doivent être prises en compte par les noeuds pour le routage. Le gestionnaire de réseau 200 est une entité qui peut être intégrée à un ou plusieurs noeuds du réseau, ou être mis en oeuvre dans un terminal spécifique mobile ou filaire disposant d'une connexion au réseau. Comme illustré sur la figure 2, un gestionnaire de réseau 200 comprend un module de détermination de métrique de qualité de service 210 en liaison avec un module de supervision 220 qui a pour fonction de superviser l'état des ressources du réseau vis-à-vis des évènements qui surviennent (disparition/apparition noeud, diminution/augmentation capacité bande passante, énergie, etc.) et les ressources requises par les applications en cours. Pour ce faire, toute nouvelle application doit s'inscrire auprès du gestionnaire de réseau avec son requis de qualité de service (par exemple une application de voix sur IP s'enregistre avec: un délai maximum de 250 msec). Le gestionnaire a ainsi une vision sur l'ensemble des requis applicatifs. Les informations concernant l'état des ressources réseau sont remontées au module 220 grâce à des sondes installées au niveau de chaque noeud (i.e. chaque terminal utilisateur). Une base de règles d'échange d'informations peut être définie au niveau du module de supervision pour lui permettre de traiter les événements remontés. Le module de détermination 210 intègre la logique de décision de la métrique à appliquer dans le réseau en fonction de l'état des ressources du réseau et/ou des exigences des applications indiqué par le module de supervision 220. En effet, à la réception d'une nouvelle notification du module de supervision, le module de détermination est invoqué, et les métriques de qualité de service à déployer seront déterminées. La décision concernant les métriques de qualité de service, une fois prise, sera diffusée par le gestionnaire réseau aux gestionnaires de métrique de tous les noeuds du réseau pour qu'ils la mettent en oeuvre. Toutefois, un protocole d'échange assurant la transmission des ordres de configuration en provenance du gestionnaire réseau vers le gestionnaire du métrique est défini. Cet échange se fait via des mécanismes de 2878674 -11- transmission fiable et atomique. Ce protocole inclut les fonctions suivantes: DeployerMetriqueQoS (métrique) : elle permet de déployer une métrique de qualité de service (QoS) donnée sur le réseau, à savoir les modules de calcul et d'insertion au niveau des paquets de contrôle. - SupprimerMetriqueQoS (métrique) : l'invocation de cette fonction permet de ne plus considérer la métrique en question. - DeployerChemin (module) : permet de mettre en oeuvre un module de calcul de chemin externe SupprimerChemin (module) : permet de désactiver un module de calcul de chemin mis en oeuvre précédemment. Afin de ne pas altérer le bon fonctionnement du réseau, compte tenu qu'un réseau ad hoc est un réseau à ressources variables dans le temps, des seuils de tolérance peuvent être fixés au niveau des noeuds du réseau (niveau d'énergie minimal, niveau de charge maximum, etc.). Selon une variante de réalisation, il est possible d'avoir une gestion externe du processus de routage via un module de calcul de chemin 131 qui est déployé dynamiquement dans une couche 130. Dans ce cas, le protocole de routage existant 112 utilise le module de calcul de chemin 131 à la place de son module interne 1122. Le protocole de routage 112 transmet au module 131 le graphe de topologie enrichi par les informations de qualité de service fournies par le module de calcul de métrique 132 au niveau de chaque noeud. Les applications doivent être modifiées pour prendre en compte ce nouveau module, qui peut être soit propre à chaque application, soit mutualisé par plusieurs applications. Dans le second cas, le module est transparent à l'application puisque le résultat du calcul de métriques est réinjecté dans le protocole de routage avec lequel communique l'application. Dans les deux cas, ce nouveau calcul de route n'impose pas ou très peu de modification sur le protocole de routage initial. De plus, ce module externe est re-programmable à tout instant, ce qui lui permet d'intégrer de nouvelles métriques dynamiquement sur initiative du gestionnaire de métrique. On réalise ainsi une gestion externe des métriques de qualité de service et de calcul de 2878674 -12- chemin. Cela permet de gérer la topologie de routage avec métriques de qualité de service au niveau des applications de manière à ce qu'elles puissent appliquer le calcul de chemin le plus optimal vis-à-vis de leur besoin en qualité de service Dans ce qui suit, on décrit d'abord les interactions entre les composants de la figure 2 par un exemple fictif. On décrit ensuite un second exemple qui illustre une mise en oeuvre possible de la présente invention. Description des interactions: On considère par exemple un réseau ad hoc spontané se formant dans une zone dépourvue d'infrastructure. Par défaut, le protocole de découverte de topologie inclus dans le protocole de routage 130 ne comprend aucune métrique de qualité de service spécifique. Lorsqu'un noeud dans le réseau est sollicité par une application de VoIP (voix sur IP), qui nécessite des caractéristiques de trafic CBR (à débit constant, "Constant Bit Rate") , une nouvelle métrique doit être alors échangée entre les noeuds et un calcul de chemin spécifique basé sur cette métrique mis en place pour définir un chemin optimisé pour l'application VoIP. Une première étape consiste à choisir la métrique disponible dans le réseau qui est la plus proche de celle attendue par l'application. Cela peut-être par exemple la gigue, le délai ou par défaut le nombre de sauts. Cette décision peutêtre locale au noeud qui va la propager aux autres noeuds (selon l'approche bien connue de réseaux "auto-organisés") ou bien globale par le gestionnaire de réseau 200 qui va la transmettre aux noeuds via un message de contrôle spécifique comme décrit précédemment. Le module de calcul externalisé 131 associé à la métrique choisie, par exemple le délai, est alors activé sur chaque noeucl ou éventuellement déployé dynamiquement depuis le gestionnaire réseau. La métrique choisie, ici le délai, est alors également ajoutée dans les messages de contrôle échangées entre les noeuds par le protocole de routage pour découvrir et maintenir la topologie. Lorsque l'application de VoIP cherchera à établir une communication, elle invoquera le module de calcul de chemin externalisé spécifique à la métrique choisie, en l'occurrence le délai. Ce module peut être présent sur tous les noeuds ou 2878674 -13- déployé dynamiquement. Ce module récupère à partir du protocole de routage le graphe de topologie disposant de la métrique délai (les informations concernant la métrique sont calculées par le module de calcul de métrique au niveau de chaque noeud et transportées par les paquets de contrôle du protocole de routage). Par ailleurs, les autres applications utilisent le module de calcul de chemin par défaut, à savoir le nombre de sauts. L'application VoIP dispose alors de routes adaptées à sa contrainte de délai, alors que les autres applications ont des chemins peut-être glus courts mais peut-être aussi plus chargés. Ce qui n'est pas gênant par exemple pour une application d'échange de données. Exemple de mise en oeuvre: Un exemple particulier de mise en oeuvre de l'invention est décrit en relation avec la figure 3 qui présente unexemple de topologie de réseau ad hoc avec une configuration qui permet de montrer les limitations des solutions actuelles à base de métrique fixe et les avantages de l'invention en matière d'adaptation dynamique aux changements des conditions de qualité de service dans l'environnement du réseau (état réseau et applications). Le réseau illustré sur la figure 3 comprend sept noeuds formés par sept terminaux de deux types: trois terminaux haute capacité (ordinateurs PC) TH1, TH2 et TH3r d'une part, formant une première route R1 et, d'autre part, quatre terminaux à faible capacité (assistant PDA) T5, TF1, TF2, TD, les terminaux TF1 et TF2 formant une deuxième route R2 entre un noeud source et un noeud destination formés respectivement par les terminaux TS et TD. Tous les noeuds utilisent des interfaces sans fil 802.11b avec un débit de 11 Mb/s. La route R1 composée de trois ordinateurs PC favorise un routage meilleur si la métrique "délai" est utilisée alors cille la route R2 composée de deux assistants PDA favorise un routage basé sur la métrique "bande passante". Dans cet exemple particulier, on considère deux applications impliquant deux types de trafic différents, chacun avec des requis différents: la première application fonctionne sur TCP (Transfert Cortrol Protocol) et requiert de la bande passante (par exemple transfert de fichiers, http, etc.), la seconde sur UDP (User Datagram Protocol), plutôt 2878674 - 14 temps réel, et qui privilégie le délai (par exemple transmission multimédia). Les règles de "basculement" des métriques pour ce réseau de test sont par ailleurs définies selon l'algorithme suivant: Début Si (Evènement = Altération des ressources noeuds faible capacités) a/ors métrique = Noeuds fiables. Sinon (autres événements) Si (pas de conflit entre applications) a/ors métrique = métrique par défaut des applications. /*môme métrique pour l'ensemble des applications*/ Sinon métrique = dé/ai. /*métrique privilégiée*/ Fin. Ces données permettent de choisir la métrique à appliquer dans le réseau selon les règles définies dans le gestionnaire réseau. Selon la décision, les données vont être acheminées soit via la route R1 (métrique délai) ou la route R2 (métrique bande passante). Le tableau suivant montre le comportement de l'approche selon 25 l'invention. Plus précisément, il décrit la métrique à appliquer dans le réseau en fonction des évènements qui surgissent dans le réseau. 2878674 -15- Instants (secondes) Evènements Métrique choisie et utilisée TO Démarrage de l'application 1 Bande passante (requis: bande passante) (Route 2) Ti Altération des ressources Noeuds fiables CPU des PDA (Route 1) T2 Démarrage de l'application 2 Délai (Route 1) (requis: délai) T3 ' Fin de l'application 1 Délai (Route 1) T4 Fin de l'application 2 Noeuds fiables (Route 1) Au vu de ces résultats, il est clair que le choix de la métrique 5 appliquée dans le réseau ad hoc a une influence primordiale sur la qualité de service fournie à l'application, en fonction de ces requis. Au niveau des résultats, on remarque que l'application de la métrique de bande passante permet d'obtenir de bonnes performances au niveau bande passante, au détriment du délai qui augmente de façon très significative. Cela est avantageux pour les applications qui nécessitent une bande passante importante, néanmoins les applications sensibles au délai sont fortement pénalisées. On peut observer le phénomène complémentaire pour la métrique de délai: le délai est inférieur mais la bande passante est inférieure à celle obtenue avec la métrique de la bande passante. Néanmoins, l'innovation permet d'obtenir le meilleur comprcmis pour appliquer la métrique instantanée qui répond le mieux au besoin des applications compte tenu des contraintes de l'environnement. Les résultats obtenus sur cet exemple démontrent l'efficacité d'une d'une gestion dynamique de la métrique de qualité de service. Contrairement à une approche rigide à métrique fixe, cette gestion dynamique de métrique de qualité de service offre suffisamment de flexibilité pour répondre au mieux aux politiques de qualité de service définies dans le réseau. -16-REVENDICATIONS 1. Procédé d'adaptation dynamique de la métrique de qualité de service pour le routage dans un réseau ad hoc comprenant une pluralité de noeuds de routage (100) pour un acheminement optimal des paquets de données entre ces noeuds suivant la topologie du réseau à un instant donné, ledit procédé comprenant les étapes suivantes: a) détermination d'au moins une métrique de qualité de service à appliquer à un instant donné basée sur la qualité de service disponible sur le réseau et/ou sur la qualité de service demandée par une ou plusieurs applications, b) transmission à au moins une partie des noeuds du réseau de la métrique de qualité de service à appliquer, c) mise à jour de la table de routage (1121) des noeuds en fonction 15 de la métrique instantanée de qualité de service à appliquer reçue. 2. Procédé selon la revendication 1, caractérisé en ce que, dans l'étape a), un gestionnaire de réseau re-programmable (200) supervise l'état des ressources de chaque noeud (100) sur la base des métriques de qualité de service applicables à un instant donné, ainsi que les ressources demandées par les applications en cours sur le réseau. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que, dans l'étape b), la métrique de qualité de service à appliquer est insérée 25 dans des messages de contrôle du protocole de routage. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il comprend en outre une étape de gestion externe des métriques de qualité de service et de calcul de chemin par des modules gérés par une application donnée ou par des modules re-programmables (131) mutualisés par plusieurs applications. 5. Programme d'ordinateur comprenant des instructions pour exécuter le procédé selon l'une des revendications 1 à 4. 2878674 -17- 6. Support d'enregistrement sur lequel est stocké le prograrme selon la revendication 5. 7. Système de gestion dynamique de la métrique de qualité de service dans un réseau ad hoc, le système comprenant une pluralité de noeuds de routage (100) pour l'acheminement de paquets de donnés, caractérisé en ce qu'il comprend en outre un gestionnaire de réseau (200) pour déterminer et calculer une métrique de qualité de service à appliquer à instant donné basée sur la qualité de service disponible sur le réseau et sur la qualité de service demandée par une ou plusieurs applications et des moyens pour diffuser la métrique de qualité de service à appliquer aux noeuds du réseau et en ce que chaque noeud comprend un gestionnaire de métrique (111) pour mettre à jour la table de routage (1121) des noeuds en fonction de la métrique de qualité de service à appliquer reçue. 8. Système selon la revendication 7, caractérisé en ce que le gestionnaire de réseau comprend des moyens (220) pour superviser l'état des ressources de chaque noeud ainsi que les ressources demandées par les applications en cours sur le réseau. 9. Système selon la revendication 7 ou 8, caractérisé en ce qu'il comprend des moyens pour calculer et insérer la métrique de qualité de service dans des messages de contrôle du protocole de routage. 10. Système selon l'une quelconque des revendications 7 à 9, caractérisé en ce que le gestionnaire de réseau (200) est intégré à au moins un noeud du réseau ou en ce que le système comprend en outre un terminal mobile ou filaire connecté au réseau et intégrant le gestionnaire de réseau. 11. Système selon l'une quelconque des revendications 7 à 10, caractérisé en ce qu'il comprend en outre des moyens pour transmettre aux noeuds du réseau des modules logiciels re-programmables de calcul de chemin et de gestion de métrique de qualité de service (131, 132). 2878674 -18- 12. Système selon l'une quelconque des revendications 7 à 10, caractérisé en ce qu'il comprend en outre des moyens pour gérer la topologie de routage avec métriques de qualité de service au niveau des applications de manière à ce qu'elles puissent appliquer le calcul de chemin le plus optimal vis-à-vis de leur besoin en qualité de service. 13. Terminal mobile ou fixe destiné à former un noeud (100) dans un réseau ad hoc, caractérisé en ce qu'il comprend un gestionnaire de métrique (111) pour mettre à jour la table de routage (1121) dudit noeud en fonction d'une métrique de qualité de service transmise dans le réseau.