Brevet FR3082380A1 — publié le 20191213

Arrière-plan de l'invention L'invention se rapporte au domaine général des communications entre plusieurs dispositifs ou terminaux, tels que par exemple des ordinateurs, des téléphones mobiles, des tablettes numériques, etc. Elle concerne plus particulièrement les communications pair-à-pair (ou P2P pour « Peer-to-Peer » en anglais) entre plusieurs dispositifs ou terminaux, désignés plus généralement par « noeuds » par la suite. On entend par communication pair-à-pair entre deux noeuds, l'échange de données entre ces deux noeuds sans passer typiquement par un serveur central. Aucune limitation n'est attachée au type de données échangées entre les noeuds (voix, texte, etc.) lors d'une communication pair-à-pair. Cette communication peut consister en un échange direct de données entre les deux noeuds (on parle alors de communication D2D ou « Device-to-Device » en anglais), ou d'un échange via un ou plusieurs noeuds intermédiaires mettant en oeuvre deux à deux des communications D2D, ces noeuds intermédiaires formant une route entre les deux noeuds cherchant à communiquer ensemble. L'ensemble des noeuds ainsi connectés pair-à-pair forment un réseau maillé ou réseau mesh sans hiérarchie centrale, aussi appelé réseau ad hoc. Quand des noeuds du réseau ad hoc sont mobiles, on parle de réseau MANET pour Mobile Adhoc NETwork en anglais. Les noeuds au sein d'un même réseau ad hoc peuvent utiliser différentes technologies de connectivité pour détecter la présence de noeuds voisins, identifier les applications ou les services mis à disposition par ces noeuds voisins, et se connecter entre eux en vue de communiquer pair-à-pair. Ils peuvent notamment s'appuyer indifféremment sur les technologies Bluetooth, WiFi (Wireless Fidelity), WiFi Direct, LTE (Long Term Evolution) Direct, etc. Ils peuvent en outre être connectés à des éléments externes au réseau ad hoc, comme par exemple à d'autres dispositifs appartenant à des réseaux d'opérateurs (ex. réseaux 3G, 4G, 5G, etc.) ou à des réseaux privés, etc., pour accéder par exemple au réseau public Internet. Si les réseaux ad hoc et plus particulièrement les réseaux MANET possèdent la propriété de s'auto-organiser rapidement, ils sont également particulièrement instables : les noeuds qui les composent sont en effet pour certains mobiles, et donc susceptibles de disparaître ou d'apparaître brusquement dans le réseau au gré de leurs déplacements. Le routage des messages entre deux noeuds d'un réseau ad hoc peut donc s'avérer une tâche complexe. Plusieurs protocoles de routage proposés par le groupe de standardisation MANET ont été normalisés au sein de l'IETF (Internet Engineering Task Force). Ces protocoles de routage peuvent être classés en trois catégories principales. Une première catégorie regroupe les protocoles de routage dits proactifs. Ces protocoles s'attachent à ce que chaque noeud du réseau ad hoc tienne à jour sa connaissance de la topologie du réseau afin d'être en mesure de déterminer rapidement les routes disponibles au sein du réseau pour échanger des données avec d'autres noeuds. A cet effet, les protocoles de routage 2 proactifs prévoient la diffusion périodique sur tout le réseau ad hoc, par chaque noeud du réseau, de messages de contrôle (messages « Hello »), en parallèle des messages de transmission de données, déclarant l'état des liens que chaque noeud entretient avec ses noeuds voisins. La diffusion de ces messages de contrôle permet à chaque noeud du réseau ad hoc de découvrir 5 toutes les routes valides (i.e. disponibles) vers tous les noeuds du réseau, et donc de tenir à jour une table de routage identifiant ces routes et tenant compte des changements de topologie susceptibles d'affecter le réseau. Des exemples de protocoles de routage proactifs sont les protocoles DSDV (pour Dynamic destination Sequences Distance Vector), GSR (pour Global State Routing) ou encore OLSR 10 (pour Optimized Link State Routing Protocol). Ces protocoles présentent l'avantage de permettre un routage efficace des messages de données au sein de réseaux ad hoc de petites dimensions, en raison des tables de routage maintenues à jour par chaque noeud du réseau. Toutefois, en raison des nombreux messages de contrôle (pour certains inutiles) diffusés périodiquement sur le réseau et du maintien de toutes les routes possibles sur le réseau même si celles-ci ne sont pas utilisées, 15 leur efficacité diminue à mesure que la taille du réseau ad hoc augmente. Une deuxième catégorie de protocoles comprend les protocoles de routage dits réactifs. Par opposition aux protocoles de routage proactifs, les protocoles de routage réactifs déterminent et maintiennent à jour les routes disponibles au sein du réseau ad hoc en fonction des besoins des noeuds désireux de transmettre des données sur le réseau. Des messages de contrôle 20 visant à découvrir les routes disponibles sur le réseau (messages « Route Request ») sont envoyés par un noeud uniquement lorsque celui-ci a besoin d'identifier une route pour émettre des données à destination d'un autre noeud, et qu'il ne dispose pas d'une telle route déjà stockée dans sa table de routage. Les tables de routage maintenues par les noeuds du réseau ne sont donc remplies qu'à la demande de ces derniers. Chaque noeud du réseau n'a qu'une connaissance partielle de la 25 topologie du réseau se limitant aux noeuds avec lesquels il a déjà communiqué. Des exemples de protocoles de routage réactifs sont les protocoles DSR (pour Dynamic Source Routing) et AODV (pour Ad Hoc On-Demand Distance Vector). L'avantage majeur de ces protocoles de routage réactifs est qu'ils ne résultent pas en une inondation excessive du réseau avec des messages de contrôle diffusés de manière intempestive. Ils sont donc particulièrement 30 bien adaptés pour des réseaux denses. En revanche, le temps mis par un noeud pour déterminer une route peut s'avérer long, y compris lorsque le noeud destinataire du message se trouve dans son voisinage. Une troisième catégorie de protocoles mixe les approches proactive et réactive : il s'agit des protocoles de routage dits hybrides. Ces protocoles s'appuient sur l'approche proactive 35 pour déterminer les routes dans le voisinage des noeuds (i.e. situés à quelques sauts des noeuds, par exemple deux ou trois sauts). Au-delà de ce voisinage, ils utilisent l'approche réactive pour la recherche des routes (i.e. recherche à la demande, seulement en cas de besoin spécifique des 3 noeuds). Un exemple de protocole de routage hybride est le protocole ZRP (Zone Routing Protocol). Les protocoles de routage hybrides sont les protocoles qui sont privilégiés dans le cadre des réseaux comprenant des noeuds mobiles : ils permettent d'éviter l'inondation excessive 5 des réseaux avec des messages de contrôle, et s'adaptent à la taille variable et potentiellement importante des réseaux ad hoc. Toutefois, s'ils permettent d'optimiser le routage des données à courte distance, le temps mis par un noeud pour découvrir une route permettant de joindre un autre noeud qui ne se trouve pas dans son voisinage peut s'avérer long (comme pour les protocoles de routage réactifs). 10 Il existe donc un besoin d'améliorer les mécanismes de routage proposés dans l'état de la technique, en particulier dans le contexte des réseaux impliquant des noeuds mobiles. Objet et résumé de l'invention L'invention répond notamment à ce besoin en proposant un procédé de sélection d'une 15 route dans un réseau ad hoc destiné à être mis en oeuvre par un noeud de ce réseau, dit « premier noeud », ce procédé de sélection comprenant : - une étape de maintien à jour d'une table de routage contenant au moins une route disponible au sein du réseau ad hoc, chaque route comprenant au moins un segment de route reliant directement entre eux deux noeuds du réseau ad hoc par un lien de connectivité dont un type 20 est identifié dans la table de routage, ladite table de routage comprenant en outre, pour chaque noeud différent du premier noeud appartenant à un dit segment de route, une indication concernant un degré de mobilité de ce noeud, la table de routage étant maintenue à jour à partir d'informations extraites de messages de contrôle émis sur le réseau ad hoc destinés au premier noeud et de messages de contrôle émis sur le réseau transitant par le 25 premier noeud ; lors de l'envoi d'un message de données par le premier noeud à destination d'un deuxième noeud du réseau ad hoc : o une étape d'identification en utilisant la table de routage d'au moins une route disponible entre le premier noeud et le deuxième noeud pour envoyer le message de 30 données ; et o si plusieurs routes disponibles sont identifiées : ^ une étape de détermination, pour chaque route disponible identifiée, d'un niveau de stabilité à partir des indications concernant le degré de mobilité des noeuds de la route et du type des liens de connectivité des segments de la 35 route contenus dans la table de routage ; et ^ une étape de sélection de la route disponible identifiée correspondant au meilleur niveau de stabilité déterminé. 4 Corrélativement, l'invention vise aussi un noeud d'un réseau ad hoc, dit « premier noeud », comprenant : un module de maintien à jour d'une table de routage contenant au moins une route disponible au sein du réseau ad hoc, chaque route comprenant au moins un segment de route reliant 5 directement entre eux deux noeuds du réseau ad hoc par un lien de connectivité dont un type est identifié dans la table de routage, ladite table de routage comprenant en outre, pour chaque noeud différent du premier noeud appartenant à un dit segment de route, une indication concernant un degré de mobilité de ce noeud, la table de routage étant maintenue à jour à partir d'informations extraites de messages de contrôle émis sur le réseau ad hoc 10 destinés au premier noeud et de messages de contrôle émis sur le réseau transitant par le premier noeud ; des modules activés lors de l'envoi d'un message de données par le premier noeud à destination d'un deuxième noeud du réseau ad hoc, et comprenant : o un module d'identification, configuré pour identifier au moins une route disponible 15 entre le premier noeud et le deuxième noeud en utilisant la table de routage maintenue à jour par le module de maintien à jour ; 0 des modules activés si plusieurs routes disponibles entre le premier noeud et le deuxième noeud sont identifiées par le module d'identification, ces modules comprenant un module de détermination, configuré pour déterminer pour chaque 20 route disponible identifiée, un niveau de stabilité à partir des indications concernant le degré de mobilité des noeuds de la route et du le type des liens de connectivité des segments de la route contenus dans la table de routage, et un module de sélection configuré pour sélectionner la route disponible identifiée correspondant au meilleur niveau de stabilité déterminé. 25 Aucune limitation n'est attachée à la nature des noeuds auxquels s'applique l'invention. En effet, l'invention s'applique à tout type de dispositif susceptible de communiquer pair-à-pair avec un autre dispositif, et muni d'une interface de connectivité lui permettant d'établir un lien de connectivité avec cet autre dispositif. Cette interface de connectivité peut être de différents types il peut s'agir d'une interface filaire telle que par exemple une interface Ethernet, xDSL (Digital 30 Subscriber Line), fibre optique, etc. ou sans fil, de type WIFI, Bluetooth, 2G, 3G, 4G, LTE, etc. En outre, l'invention s'applique avantageusement à des réseaux ad hoc pouvant comporter des noeuds fixes comme des noeuds mobiles. Pour améliorer le routage au sein de tels réseaux, l'invention propose, lorsque plusieurs routes vers un noeud (deuxième noeud au sens de l'invention) sont disponibles au sein du réseau ad hoc (c'est-à-dire sont actives au sein du réseau), 35 de sélectionner la route qui semble la plus stable en termes de connectivité. Cette stabilité de la route est évaluée en tenant compte, de préférence : - d'une part, de la stabilité supposée des liens de connectivité reliant les noeuds de la route entre eux. Cette stabilité supposée des liens de connectivité dépend du type de ces liens et 5 notamment de la nature des interfaces de connectivité utilisées sur ces liens (tel que par exemple s'il s'agit d'une liaison WiFI, Bluetooth, Ethernet, etc.) ; et d'autre part, de la stabilité des noeuds à proprement parler traversés par la route. La stabilité des noeuds est estimée en fonction de leur degré de mobilité (par exemple « fixe » ou 5 « mobile »). En effet, plus un noeud est mobile, plus sa pérennité au sein du réseau risque d'être limitée (il présente une probabilité d'apparaître et de disparaître soudainement évidemment supérieure à celle d'un noeud fixe), et donc plus sa stabilité est menacée. En choisissant la route la plus stable comme proposé par l'invention pour router les messages de données échangés au sein du réseau ad hoc, on favorise la pérennité des routes 10 empruntées, ce qui permet de diminuer le risque d'avoir des routes qui deviennent soudainement indisponibles et des échanges rompus ou retardés. La qualité des échanges au sein du réseau ad hoc et l'expérience utilisateur en résultant sont ainsi améliorées grâce à l'invention. Pour permettre une sélection de la route la plus stable au sein du réseau, l'invention s'appuie sur un maintien à jour des tables de routage hébergées par les noeuds du réseau 15 exploitant les informations de routage contenues dans tous les messages de contrôle diffusés sur le réseau et qui transitent par ces noeuds. De tels messages de contrôle sont typiquement des messages de contrôle classiquement diffusés dans le cadre d'un protocole de routage proactif et/ou des messages de contrôle classiquement diffusés dans le cadre d'un protocole de routage réactif, et comprennent notamment des messages d'annonce, des messages de découverte de 20 routes, des messages de réponse aux messages de découverte ainsi que des messages d'erreur signalant une indisponibilité d'un noeud ou d'un lien du réseau ad hoc détectée par un autre noeud. Ainsi, contrairement à l'état de la technique, pour maintenir à jour la table de routage d'un noeud du réseau ad hoc, on ne se contente pas de tenir compte uniquement des messages d'annonce destinés à ce noeud et émis par ses voisins ou des messages envoyés en réponse aux messages de 25 découverte de routes émis par le noeud, mais on tient compte de tous les messages de contrôle transitant (i.e. relayés) par ce noeud et qui ne lui sont pas directement destinés. En exploitant de façon continue ces messages de contrôle destinés ou transitant par le noeud, la pertinence et la validité des informations contenues dans sa table de routage sont améliorées. Ceci permet à chaque noeud du réseau d'identifier plus rapidement les changements de topologie de 30 configuration du réseau, tant au niveau des noeuds qui le composent que des liens de connectivité existant entre ces noeuds. Dans un mode particulier de réalisation, le procédé de sélection comprend en outre : une étape d'attribution d'un score de stabilité dit local à chaque type de lien de connectivité et à chaque type de degré de mobilité susceptibles d'être contenus dans la table de routage ; et 35 - une étape de calcul d'un score de stabilité dit global pour chaque route disponible identifiée reflétant le niveau de stabilité de cette route, ce score de stabilité global étant calculé à partir d'une somme pondérée des scores de stabilité locaux attribués aux liens de connectivité des 6 segments de cette route en fonction de leur type et aux noeuds de cette route en fonction des indications concernant leur degré de mobilité contenues dans la table. Ce mode de réalisation offre une manière simple et efficace d'évaluer la stabilité d'une route. Elle permet une différenciation facile, via les scores de stabilité locaux attribués, des 5 différents liens de connectivité des segments de chaque route ainsi que des degrés de mobilité des noeuds de cette route. Par exemple, lors de l'étape d'attribution : - le score de stabilité local attribué à un lien de connectivité de type filaire est meilleur que le score de stabilité local attribué à un lien de connectivité de type sans fil ; et/ou 10 le score de stabilité local attribué à un degré de mobilité de type fixe est meilleur que le score de stabilité local attribué à un degré de mobilité de type mobile. Ceci permet de privilégier les liens de connectivité et les noeuds qui ont une meilleure stabilité par nature, à savoir les connectivités de type filaire et les noeuds fixes. On peut en outre, pour un même type de lien de connectivité (par exemple, un lien de 15 connectivité de type sans fil), attribuer des scores de stabilité locaux différents selon l'interface de connectivité utilisée (par exemple WiFI, Bluetooth, WiFi-Direct, etc.). Ainsi par exemple, on peut attribuer un score de stabilité local supérieur à une liaison WiFi qu'à une liaison Bluetooth (de portée inférieure), ou par rapport à une liaison WiFI-Direct (plus instable par expérience qu'une liaison WiFi). 20 Dans une variante de réalisation, le score de stabilité local attribué à un type de lien de connectivité peut dépendre d'une interface de connectivité utilisée sur ce lien et d'un débit théorique atteignable sur ce type de lien. Ceci permet d'ajouter une granularité supplémentaire aux scores de stabilité locaux attribués en fonction du type de lien de connectivité utilisé. Par exemple, pour un même type de 25 lien de connectivité (ex. pour une interface de type WiFI), on peut attribuer un score de stabilité local qui diffère en fonction du débit théorique atteignable sur ce type de lien, et notamment attribuer un meilleur score de stabilité local à un lien sur lequel le débit théorique est plus fort. De façon similaire, on peut ajuster la granularité des scores de stabilité locaux attribués en fonction du degré de mobilité des noeuds de sorte à tenir compte de la nature de ces 30 noeuds (i.e. s'agit-il d'une box, d'une station de base associée à une antenne relai d'un réseau de télécommunications mobile, d'un téléphone intelligent, d'une tablette numérique, etc.). De cette sorte, il est possible d'avoir une estimation plus fiable de la stabilité d'une route en tenant compte des caractéristiques des liens de connectivité de ses segments et de ses noeuds. 35 Dans un mode particulier de réalisation, lors de l'étape de sélection, la route est sélectionnée en tenant compte en outre : - d'un type des données transportées par le message ; et/ou 7 - d'une contrainte en termes de temps de propagation, de latence et/ou de débit entre le premier noeud et le deuxième noeud ; et/ou - d'une absence ou d'une présence d'au moins un type de lien de connectivité pour les segments de la route. 5 Ce mode de réalisation permet non seulement de choisir la route qui semble être la plus stable (et donc la plus pérenne) dans le réseau, mais également la route dont les caractéristiques techniques répondent le mieux aux exigences fonctionnelles (par exemple contraintes en terme de temps de propagation, de débit, etc.) de l'application hébergée par le noeud et qui souhaite échanger des données sur le réseau (par exemple, application de 10 visioconférence en temps réel) et d'améliorer ainsi encore davantage l'expérience utilisateur. En outre, cela permet d'optimiser l'utilisation des routes au sein du réseau ad hoc et de réguler le trafic sur ces routes. Dans un mode particulier de réalisation, lors de l'étape de maintien à jour, la table de routage est maintenue à jour en outre à partir d'informations de routage extraites de messages de 15 données émis sur le réseau ad hoc destinés au premier noeud et/ou de messages de données émis sur le réseau transitant par le premier noeud. Ceci permet d'une part, d'améliorer la pertinence des informations contenues dans la table de routage, et d'autre part, de faciliter la mise en oeuvre du mode de réalisation évoqué précédemment dans lequel la sélection de la route est réalisée en tenant compte également des 20 exigences fonctionnelles des applications hébergées par les noeuds du réseau et qui souhaitent échanger des données sur ce réseau. En effet, les messages de données véhiculés sur le réseau peuvent contenir des informations sur les caractéristiques des noeuds et des segments de route empruntés par ces messages (ex. temps de propagation sur ces segments, latences, durées de vie, etc.) qui permettent d'avoir une connaissance plus précise de ces derniers et permettent une 25 sélection plus pertinente d'une route stable appropriée pour transmettre des données. On note que l'invention s'applique quel que soit le protocole de routage mis en oeuvre au sein du réseau. Elle a toutefois une application privilégiée lorsque ce protocole de routage est un protocole de routage hybride, qui est particulièrement bien adapté lorsque tout ou partie des noeuds du réseau ad hoc sont des noeuds mobiles. 30 Par exemple, dans un mode particulier de réalisation : - le réseau ad hoc est organisé en clusters ; la table de routage comprend également pour chaque noeud différent du premier noeud appartenant à un dit segment de route, un identifiant d'au moins un cluster du réseau ad hoc auquel appartient ce noeud ; 35 le premier noeud utilise un protocole de routage réactif pour émettre des messages de découverte de route à destination de noeuds n'appartenant pas à un cluster auquel il appartient. 8 Dans ce mode particulier de réalisation, le premier noeud peut en outre utiliser un protocole de routage proactif pour mettre à jour sa table de routage avec des routes lui permettant de joindre les noeuds du cluster auquel il appartient. Dans un mode particulier de réalisation, les différentes étapes du procédé de sélection 5 sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un noeud du réseau ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de sélection tel que décrit ci-dessus. 10 Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-15 dessus. Le support d'informations ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. 20 D'autre part, le support d'informations ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations ou d'enregistrement peut être un circuit 25 intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. L'invention vise également un réseau de communication ad hoc comprenant une pluralité de noeuds conformes à l'invention. Le réseau de communication ad hoc selon l'invention présente les mêmes avantages 30 cités précédemment que le procédé de sélection et le noeud conformes à l'invention. En outre, dans un mode particulier de réalisation, les noeuds sont organisés en une pluralité de clusters, ces noeuds étant configurés pour mettre en oeuvre un protocole de routage proactif au sein des clusters auxquels ils appartiennent respectivement et un protocole de routage réactif en dehors de ces clusters, chaque cluster comprenant un noeud dit maître désigné pour le 35 cluster apte à émettre des messages de contrôle selon le protocole de routage réactif à destination des noeuds maître des autres clusters, le noeud maître désigné pour un cluster correspondant au noeud parmi les noeuds du cluster qui est le plus stable en termes de connectivité et/ou d'activité au sein du réseau ad hoc. 9 Une telle désignation des noeuds maîtres pour les clusters permet d'accroître encore davantage la pérennité des routes sélectionnées par les noeuds. On peut également envisager, dans d'autres modes de réalisation, que le procédé de sélection, le noeud du réseau ad hoc, et le réseau de communication ad hoc selon l'invention 5 présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de 10 réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente, de façon schématique, un réseau de communication ad hoc conforme à l'invention, dans un mode particulier de réalisation ; la figure 2 représente l'architecture matérielle d'un noeud conforme à l'invention appartenant au réseau de communication ad hoc de la figure 1, dans un mode particulier de réalisation ; 15 la figure 3 illustre un exemple de table de routage maintenue par un noeud du réseau de communication ad hoc de la figure 1 ; et la figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de sélection selon l'invention tel qu'il est mis en oeuvre par chaque noeud du réseau de communication ad hoc de la figure 1. 20 Description détaillée de l'invention La figure 1 représente, dans son environnement, un réseau de communication ad hoc 1 conforme à l'invention, dans un mode particulier de réalisation. Le réseau ad hoc 1 comporte une pluralité de noeuds (référencés de manière générale 25 par N), conformes à l'invention (représentés par des cercles sur la figure 1). Aucune limitation n'est attachée à la nature de ces noeuds à proprement parler : il peut s'agir de n'importe quels dispositifs de communication aptes à communiquer avec d'autres dispositifs comme par exemple des terminaux tels que des tablettes numériques, des téléphones intelligents (ou smartphones), des ordinateurs portables ou fixes, ou des passerelles résidentielles aussi appelées plus 30 couramment « box », des serveurs, etc. Evidemment, l'exemple représenté sur la figure 1 n'est donné qu'à titre illustratif et un nombre différent de noeuds peut être envisagé. Conformément à l'invention, on distingue les noeuds du réseau ad hoc 1 en fonction de leur degré de mobilité : il peut s'agir de noeuds mobiles, qui sont amenés à se déplacer au cours du temps, comme par exemple un téléphone mobile, une tablette numérique, etc., ou de noeuds 35 fixes qui au contraire ne sont pas destinés à être en mouvement une fois installés (ou seulement de façon exceptionnelle), comme par exemple un point d'accès à un réseau de communication tel un point d'accès WiFI ou une station de base d'un réseau de communication mobile, une passerelle résidentielle ou encore un serveur sédentaire. On note que le caractère fixe ou mobile d'un noeud 10 peut dépendre de sa nature (téléphone portable, ordinateur fixe, box, etc.), mais également de son contexte d'utilisation ; de ce fait, on s'intéresse ici au degré de mobilité supposé ou déclaré de ce noeud (cf. exemples précédents) ou au degré de mobilité constaté de ce noeud. Par exemple, si le noeud n'est pas déplacé pendant une période de temps supérieure à un seuil prédéterminé, ce 5 noeud peut être considéré au sens de l'invention comme étant fixe. Ce peut être le cas par exemple d'un ordinateur portable fixé sur une station d'accueil et utilisé comme un ordinateur fixe. Les noeuds du réseau ad hoc 1 peuvent communiquer entre eux via différentes technologies permettant d'assurer leur connectivité, comme par exemple des technologies sans fil de type WiFI, WiFI Direct, Bluetooth, Bluetooth Low Energy, cellulaire de type 3G, 4G, 5G, etc. ou 10 filaire de type Ethernet, ADSL, etc. Aucune limitation n'est attachée aux technologies implémentées sur lesquels s'appuient les liens de connectivité établis entre les noeuds au sein du réseau ad hoc 1. Chaque noeud peut utiliser une ou plusieurs de ces technologies d'accès pour communiquer avec ses noeuds voisins ; par exemple un même noeud peut avoir avec un noeud voisin plusieurs liens utilisant chacun des technologies différentes. Dans la suite de la description, on désigne par 15 « noeuds voisins » d'un noeud, les noeuds avec lesquels il dispose d'un lien de connectivité actif. On note que la notion de voisinage n'est pas nécessairement liée à une proximité géographique selon la technologie utilisée sur le lien de connectivité, mais est liée à la portée de cette technologie. Dans le mode de réalisation décrit ici, chaque noeud N du réseau ad hoc 1 a l'architecture matérielle d'un ordinateur, telle que représentée à la figure 2. Il comprend 20 notamment un processeur 2, une mémoire morte 3, une mémoire vive 4, une mémoire non volatile 5, et des moyens de communication 6. Ces moyens de communication 6 permettent au noeud N de communiquer avec les autres noeuds du réseau ad hoc 1, via au moins une interface de connectivité utilisant l'une des technologies évoquées ci-avant (WiFI, WiFI Direct, Bluetooth, Bluetooth Low Energy, 3G, 4G, 5G, Ethernet, ADSL, fibre optique, etc.). 25 La mémoire morte 3 du noeud N constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 2 et sur lequel est enregistré un programme d'ordinateur PROG conforme à l'invention, comportant des instructions pour l'exécution d'un procédé de sélection d'une route selon l'invention. Le programme PROG définit de façon équivalente divers modules fonctionnels et logiciels du noeud N (à savoir ici, un module de maintien à jour 7, un module 30 d'identification 8, un module de détermination 9 et un module de sélection 10), aptes à mettre en oeuvre les étapes du procédé de sélection d'une route selon l'invention, et s'appuyant sur les éléments matériels 2-6 du noeud N décrits précédemment. Ce procédé de sélection est utilisé par chaque noeud N pour sélectionner une route au sein du réseau ad hoc 1 pour router les messages de données qu'il souhaite envoyer aux autres noeuds du réseau ad hoc 1, comme décrit davantage 35 ultérieurement en référence à la figure 4. Dans l'exemple envisagé à la figure 1, les noeuds du réseau ad hoc 1 sont regroupés en sous-ensembles aussi appelés « clusters ». Plus particulièrement, sur la figure 1, le réseau ad hoc 1 comprend quatre clusters A, B, C, D. Chaque cluster agrège des noeuds situés dans un 11 périmètre géométrique donné et partageant des caractéristiques communes : dans l'exemple de la figure 1, les noeuds appartenant à un même cluster sont reliés entre eux par le même type de lien de connectivité. Par exemple : les noeuds Al, A2B2, A3, A4, A5 et A6 appartenant au cluster A sont reliés le cas échéant par 5 un lien de connectivité utilisant la technologie WiFI ; - les noeuds Bl, A2B2, B3, B4C4 et B5 appartenant au cluster B sont reliés le cas échéant par un lien de connectivité utilisant la technologie WiFI Direct ; les noeuds C1D4, C2, C3 et B4C4 appartenant au cluster C sont reliés le cas échéant par un lien de connectivité utilisant une technologie radio mobile telle que par exemple une 10 technologie 3G, 4G ou 5G ; et les noeuds Dl, D2, B3D3, C1D4 et D5 appartenant au cluster D sont reliés le cas échéant par un lien de connectivité utilisant la technologie Bluetooth Low Energy. Bien entendu, cet exemple n'est donné qu'à titre illustratif et on peut considérer un nombre de clusters différent, un nombre différent de noeuds par cluster, des interfaces de 15 connectivité différentes au sein de chaque cluster, ainsi que des critères différents pour regrouper les noeuds au sein d'un même cluster (par exemple les noeuds regroupés au sein d'un même cluster peuvent partager une même application pair-à-pair, appartenir à une même zone géographique, etc.). On note en outre qu'un même noeud peut appartenir à différents clusters. C'est le cas 20 par exemple sur la figure 1 des noeuds A2B2 (qui appartient au cluster A et au cluster B), B4C4 (qui appartient au cluster B et au cluster C), C1D4 (qui appartient au cluster C et au cluster D) et B3D3 (qui appartient au cluster B et au cluster D). Dans chaque cluster A, B, C, D, un noeud est désigné comme noeud maître (aussi appelé « cluster-head » en anglais) (représenté par un cercle hachuré sur la figure 1) : Al pour le 25 cluster A, B1 pour le cluster B, C1D4 pour le cluster C et D1 pour le cluster D. Dans le mode de réalisation décrit ici, les noeuds maîtres sont désignés au sein de chaque cluster en tenant compte de la stabilité (déclarée, supposée ou constatée) des différents noeuds du cluster. Plus particulièrement, on désigne comme noeud maître d'un cluster, le noeud qui présente la meilleure stabilité en termes de connectivité (en raison notamment de son degré de mobilité (« fixe » ou 30 « mobile ») ou du type de liens de connectivité qu'il entretient avec les autres noeuds du réseau ad hoc) et/ou de son activité au sein du réseau ad hoc (est-ce que des messages sont envoyés sur le réseau ad hoc via ce noeud, etc.). Cette stabilité peut être évaluée à partir de différents critères, comme par exemple : un noeud peut déclarer de lui-même aux autres noeuds du cluster qu'il est fixe (et donc a priori 35 plus stable qu'un noeud mobile) ; un noeud peut être considéré comme stable car il est relié à d'autres noeuds du réseau ad hoc 1 par un lien de connectivité filaire (utilisant par exemple une technologie ADSL ou fibre optique) ; 12 un noeud peut être considéré comme stable car il appartient à une route dont la pérennité (c'est-à-dire son ancienneté ou sa durée de vie) est avérée, c'est-à-dire qu'elle perdure et est active depuis une durée de temps supérieure à un seuil prédéterminé, un noeud peut être considéré comme stable par définition en raison de sa nature ou de ses 5 fonctions, par exemple il s'agit d'un point d'accès WiFI ou il est attaché à une antenne d'un réseau mobile d'opérateur ou encore il s'agit du chef de groupe (ou « group owner » en anglais) d'un groupe WiFI Direct par exemple, etc. Une combinaison pondérée de tout ou partie de ces critères (et/ou d'autres critères traduisant la stabilité ou l'absence de stabilité d'un noeud) peut être considérée pour désigner le 10 noeud maître de chaque cluster : cette combinaison pondérée est alors évaluée pour chaque noeud du cluster considéré, puis le noeud qui correspond à la combinaison traduisant la plus grande stabilité est retenu comme noeud maître du cluster. La liste des critères à évaluer et le mécanisme de pondération ne sont pas décrits plus en détail ici. Dans une variante de réalisation ou s'il s'avère impossible de déterminer le noeud le 15 plus stable du cluster au vu des critères considérés, le noeud maître d'un cluster peut être choisi de manière empirique : il peut être choisi par exemple de manière aléatoire ou encore le premier noeud à l'origine de la constitution du cluster peut être désigné comme noeud maître. On note que les critères retenus pour désigner le noeud maître, et la combinaison pondérée de ces critères le cas échéant, sont de préférence réévalués à différents instants, par 20 exemple périodiquement, et le noeud maître peut être amené à être modifié si un autre noeud du cluster s'avère être devenu plus stable que le noeud maître courant. Dans le mode de réalisation décrit ici, les noeuds du réseau ad hoc 1 sont configurés pour mettre en oeuvre un protocole de routage hybride basé sur un protocole de routage proactif au sein de leurs clusters et un protocole de routage réactif en dehors de leurs clusters, décrits 25 succinctement ci-après. A cet effet, chaque noeud du réseau ad hoc 1 est configuré pour envoyer régulièrement (périodiquement) à ses noeuds voisins (i.e. avec lesquels il dispose d'un lien de connectivité actif) dans chaque cluster auquel il appartient, des messages de contrôle et plus particulièrement des messages d'annonce (désignés ici par « Hello ») pour signaler sa présence à 30 ses noeuds voisins. De tels messages d'annonce sont classiquement utilisés dans les protocoles de routage proactifs de l'état de la technique comme par exemple dans les protocoles de routage OLSR et OSPF (Open Shortest Path First). La diffusion et la réception de ces messages « Hello » au sein du cluster permettent à chaque noeud N du cluster de maintenir à jour une table de routage RT(N) répertoriant les routes actives pour joindre chacun des autres noeuds de son cluster. Un 35 exemple d'une telle table de routage RT est illustré à la figure 3, pour le noeud N=A2B2 appartenant au cluster A et au cluster B. Elle est par exemple stockée dans la mémoire non volatile 5 du noeud A2B2. 13 Dans le mode de réalisation décrit ici, la table de routage RT(N) d'un noeud N comprend une pluralité de lignes, chaque ligne étant associée à un noeud « destinataire » du réseau ad hoc 1 (plusieurs lignes pouvant être associées à un même noeud), et une pluralité de colonnes répertoriant : 5 l'identifiant du noeud destinataire correspondant à la ligne considérée (cf. référence ID dans la table de routage de la figure 3), la nature (ex. « box », « antenne », « PC », « tablette ») ou le degré de mobilité de ce noeud destinataire (ex. fixe ou mobile) (cf. référence « TYPE » sur la figure 3), sachant que comme indiqué précédemment, la nature du noeud destinataire fournit une indication sur son degré de 10 mobilité ; le ou les clusters auxquels appartient le noeud destinataire (cf. référence « CLUSTERS » sur la figure 3), et la route permettant d'atteindre ce noeud destinataire depuis le noeud N (cf. référence « ROUTE » sur la figure 3) : chaque route comprend un ou plusieurs segments de route, 15 chaque segment de route reliant directement deux noeuds du réseau ad hoc 1 (autrement dit représentant un lien de connectivité entre deux noeuds du réseau ad hoc 1). Elle se présente dans l'exemple de la table de routage RT(N) sous la forme d'une liste de couples, chaque couple correspondant à un segment de la route auquel sont associées des caractéristiques du lien de connectivité mis en oeuvre sur ce segment (Wifi, WifiDirect (WFD), LTE Direct (LTE) et 20 Bluetooth Low Energy (BLE) dans l'exemple envisagé sur la figure 3). Ces caractéristiques identifient notamment le type de lien de connectivité existant entre les deux noeuds reliés par le segment (c'est-à-dire ici à la nature de l'interface de connectivité utilisée par les deux noeuds pour communiquer entre eux pair-à-pair). En variante, elles peuvent comprendre d'autres indications comme par exemple un temps de propagation constaté sur ce segment, un débit 25 théorique, une bande passante, une durée de vie dans le réseau ad hoc 1, etc. Ainsi, dans l'exemple de la table de routage RT (N=A2B2) illustré à la figure 3, le noeud A2B2 est un voisin direct du noeud Al qui appartient au cluster A et est une box, et dispose d'un lien de connectivité de type « WiFI » avec ce voisin. De façon similaire, d'après la table de routage RT(A2B2), le noeud A2B2 peut joindre le noeud A3 appartenant au cluster A et qui est un 30 ordinateur personnel (PC pour « Personal Computer ») en deux sauts via le noeud Al, les noeuds Al et A2B2 étant en connexion directe via un lien connectivité de type WiFI, de même que les noeuds Al et A3, etc. La table de routage RT(N) maintenue par un noeud N contient donc différentes routes actives au sein du réseau ad hoc 1 permettant au noeud N de joindre d'autres noeuds de ce réseau. 35 On note qu'aucune limitation n'est attachée à la forme à proprement parler de la table de routage RT(N) maintenue par chaque noeud N du réseau ad hoc 1. Cette table de routage peut prendre des formes différentes de celle illustrée à la figure 3. Par exemple, au lieu de référencer directement les routes permettant au noeud N de joindre un noeud du réseau ad hoc 1, elle peut 14 ne contenir que des segments de route actifs au sein du réseau ad hoc (et pour chaque segment contenir son noeud d'origine, son noeud de fin, et les caractéristiques du lien de connectivité établis entre ces deux noeuds (notamment son type)), charge ensuite au noeud N, via un algorithme approprié, d'identifier les routes composées d'un ou de plusieurs segments actifs répertoriés dans 5 la table de routage lui permettant d'atteindre un noeud donné du réseau ad hoc 1. Si un noeud appartient en même temps à plusieurs clusters, comme par exemple le noeud A2B2, celui-ci est configuré pour envoyer des messages « Hello » à tous ses voisins de tous les clusters auxquels il appartient (clusters A et B dans l'exemple du noeud A2B2). Ces messages « Hello » sont relayés de pair en pair dans le cluster de sorte à se 10 propager dans le cluster et atteindre ainsi tous les noeuds du cluster. Dans le mode de réalisation décrit ici, les messages « Hello » diffusés par les noeuds au sein de leur(s) cluster(s) comprennent les champs suivants : un champ « deviceId » contenant un identifiant du noeud à l'origine du message « Hello » ; un champ « clusterld » contenant un identifiant du cluster auquel appartient le noeud à 15 l'origine du message « Hello » ; un champ « fromId » contenant un identifiant du dernier noeud par lequel a transité le message « Hello », ce champ étant mis à jour à chaque réexpédition du message « Hello » par un noeud du cluster ; - un champ « hopCount » indiquant le nombre de sauts déjà effectués par le message « Hello » 20 (i.e. noeuds traversés dans le cluster) ; un champ « TTL » pour « Time-to-Live » représentant le nombre de sauts restant avant l'arrêt de la propagation du message « Hello » dans le cluster ; un champ « deviceType » contenant le type du noeud à l'origine du message « Hello » ; ce champ traduit ici la nature (ex. « box », « antenne », « PC », « tablette », « mobile ») ou le 25 degré de mobilité (fixe ou mobile) du noeud en question ; un champ « fromType » contenant le type du dernier noeud par lequel a transité le message « Hello » ; ce champ traduit ici la nature (ex. « box », « antenne », « PC », « tablette ») ou le degré de mobilité (fixe ou mobile) du noeud en question, ce champ étant mis à jour à chaque réexpédition du message « Hello » par un noeud du cluster ; 30 un champ « linkType » contenant le type du lien de connectivité du dernier segment de route traversé, ce champ étant mis à jour à chaque réexpédition du message « Hello » par un noeud du cluster. Dans l'exemple illustratif envisagé ici, le type du lien de connectivité peut être Wifi, WifiDirect (WFD), LTE Direct (LTE) ou Bluetooth Low Energy (BLE). Les champs « deviceType », « fromType », « linkType » permettent aux noeuds du 35 cluster de renseigner leurs tables de routage avec des informations représentatives de la nature ou du degré de mobilité des noeuds du cluster ainsi que du type des liens de connectivité établis au sein du cluster. 15 Les champs indiqués ci-dessus sont donnés à titre illustratif. En variante, le message « Hello » peut comprendre d'autres champs (en plus ou en moins) que ceux indiqués ci-dessus et permettant aux noeuds de renseigner leurs tables de routage de façon adéquate pour mettre en oeuvre l'invention (par exemple le champ « linkType » peut être omis si tous les liens au sein d'un 5 même cluster utilise le même de connectivité, etc.). Ainsi, dans l'exemple de la figure 1, pour le cluster A et le noeud A6, le noeud A6 est configuré pour envoyer un message « Hello » à son noeud voisin A5 dont le contenu des champs est reproduit ci-dessous : deviceId clusterld fromId hopCount TTL deviceType fromType linkType A6 A A6 0 10 Mobile Mobile Wifi Dans un autre mode de réalisation, le message « Hello » peut contenir un champ 10 additionnel contenant les caractéristiques de la route empruntée par le message depuis le noeud à l'origine du message jusqu'au noeud courant (par exemple le noeud A4 peut recevoir un message Hello provenant du noeud A6 et ayant transité par les noeuds A5 et Al contenant dans ce champ la route (Wifi, A6), (Wifi, A5), (Wifi, Al)). Quand le noeud A5 reçoit le message « Hello » du noeud A6, il commence par mettre à 15 jour sa table de routage RT(A5) avec les informations contenues dans le message « Hello ». Dans le mode de réalisation décrit ici, chaque route répertoriée dans la table de routage d'un noeud est associée à un attribut temporel « Timestamp » qui permet de stocker l'heure de réception d'un message impactant cette route (non représenté sur la figure 3). Lorsqu'un message « Hello » est reçu par un noeud, celui-ci détermine si ce message contient une 20 route ou un segment de route correspondant aux informations véhiculées par le message (dans l'exemple décrit ici segment de route lui permettant d'atteindre le noeud A6). Le cas échéant, il met à jour l'attribut temporel associé à cette route ou à ce segment de route avec l'heure de réception du message « Hello ». Sinon, il créée une nouvelle entrée dans la table répertoriant la route ou le segment de route indiqué(e) dans le message « Hello » et lui associe l'heure de réception du 25 message « Hello ». Puis comme indiqué dans la table ci-dessous, il insère la valeur A5 dans le champ « fromId» du message « Hello », décrémente de 1 le champ « TTL » et incrémente le champ « hopCount » de 1. Le noeud A5 transfère alors le message « Hello » ainsi mis à jour à ses voisins dans le cluster A (i.e. noeuds Al et A4 dans l'exemple considéré). deviceId clusterld fromId hopCount TTL deviceType fromType linkType A6 A A5 1 9 Mobile Mobile WiFi 30 De façon analogue, le noeud Al reçoit le message « Hello » en provenance du noeud A5, et met à jour sa table de routage RT(A1) comme indiqué ci-avant. Puis, comme indiqué dans la table ci-dessous, il insère la valeur Al dans le champ « fromId» du message « Hello », décrémente de 1 le champ « TTL », incrémente le champ « hopCount » de 1, et transmet le message ainsi mis à jour vers ses voisins A3, A4 et A2B2 dans le cluster A. 16 deviceId clusterld fromId hopCount TTL deviceType fromType linkType A6 A Al 2 8 Mobile box WiFi De son côté, le noeud A4 reçoit le message « Hello » en provenance du noeud A5 et en provenance du noeud Al. Il met à jour sa table de routage RT à partir des messages « Hello » reçus. Mais comme il a déjà reçu ces messages de ses deux seuls voisins dans le cluster A, il ne les retransmet pas. 5 Enfin les noeuds A3 et A2B2 reçoivent le message « Hello » en provenance de Al, mettent à jour leurs tables de routage respectives à partir des informations contenues dans le message, mais ne le retransfèrent pas : en effet, le noeud A3 n'a pas d'autre voisin dans le cluster A que le noeud Al dont il a reçu le message « Hello », et le noeud A2B2 a bien un autre voisin (le noeud B1) mais celui-ci n'appartient pas au cluster A. 10 On note qu'un mécanisme destiné à éviter la retransmission en boucle des messages « Hello » au sein du cluster peut être mis en oeuvre ; un tel mécanisme est connu en soi (déjà utilisé dans certains protocoles de routage proactifs) et n'est pas décrit ici. Il utilise par exemple le champ TTL du message « Hello ». Ce champ peut également être utilisé pour éviter que le message « Hello » ne soit propagé trop loin dans le réseau ad hoc 1, et que trop de messages 15 « Hello » inondent le réseau ad hoc 1. Par ailleurs, il est possible dans une variante de réalisation d'utiliser un protocole de routage proactif différent de celui qui vient d'être décrit au sein de chaque cluster pour remplir les tables de routage des noeuds de chaque cluster, tel que par exemple un protocole de routage proactif connu comme le protocole DSDV, GSR, OLSR, etc. 20 Comme mentionné précédemment, les noeuds du réseau ad hoc 1 sont configurés pour utiliser un protocole réactif pour échanger des informations avec les noeuds n'appartenant pas à leur cluster. Plus précisément ici, à cet effet, chaque noeud maître noté MN d'un cluster dispose d'une table de clusters CT(MN) répertoriant les clusters qu'il connaît et les noeuds maîtres de ces 25 clusters. En outre, chaque noeud maître MN d'un cluster est configuré pour envoyer régulièrement (périodiquement) des messages de contrôle, que l'on appellera ici messages « InfoCluster », aux noeuds maîtres des clusters dont il connaît l'existence, autrement dit, répertoriés dans sa table de clusters CT(MN), pour partager notamment avec ces noeuds maîtres les informations dont il dispose sur les clusters dont il connaît l'existence et notamment les noeuds maîtres de ces clusters. 30 Dans le mode de réalisation décrit ici, les messages « InfoCluster » diffusés par les noeuds maîtres à destination des noeuds maîtres des autres clusters comprennent les champs suivants : - un champ « deviceId » contenant un identifiant du noeud maître à l'origine du message « InfoCluster » ; 35 - un champ « clusterld » contenant un identifiant du cluster auquel appartient le noeud maître à l'origine du message « InfoCluster » ; 17 un champ « fromDeviceId » contenant un identifiant du dernier noeud maître par lequel a transité le message « InfoCluster », ce champ étant mis à jour à chaque réexpédition du message « InfoCluster » par un noeud maître d'un cluster ; - un champ « fromClusterld » contenant un identifiant du cluster du dernier noeud maître par 5 lequel a transité le message « InfoCluster », ce champ étant mis à jour à chaque réexpédition du message « InfoCluster » par un noeud maître d'un cluster ; un champ « knownClusters » contenant la liste des couples (identifiant de cluster, noeud maître correspondant) connus par le noeud maître à l'origine du message « InfoCluster » ; un champ « TTL » pour « Time-to-Live » représentant le nombre de sauts restant (i.e. noeuds 10 maîtres par lesquels transite le message) avant l'arrêt de la propagation du message « InfoCluster ». Les champs indiqués ci-dessus sont donnés à titre illustratif. En variante, le message « InfoCluster » peut comprendre d'autres champs (en plus ou en moins) que ceux indiqués ci-dessus. 15 Ainsi, dans l'exemple illustré à la figure 1, si on considère le noeud maître C1D4 du cluster C, celui-ci connaît les clusters B et D, et envoie un message « InfoCluster » au noeud maître B1 et au noeud maître D1 dont le contenu du message est indiqué dans la table ci-dessous : deviceld clusterld fromDeviceld fromClusterld knownClusters TTL C1 D4 C C1D4 C (B, B1), (D, Dl) 3 20 Quand le noeud maître B1 reçoit le message « InfoCluster » du noeud maître C1D4, il commence par mettre à jour sa table de clusters CT(B1) avec les informations contenues dans le message. Par exemple, il met à jour sa table de clusters CT(B1) si le message « InfoCluster » qu'il reçoit contient de nouveaux clusters qu'il ne connaissait pas précédemment (par exemple ici, avec le cluster D et le noeud maître D1 du cluster D, si le noeud maître Bi ne connaissait pas déjà le 25 cluster D) ou si les noeuds maîtres de clusters qu'il connaît ont été modifiés par rapport aux noeuds maîtres identifiés dans sa table de clusters. Puis il modifie les champs « fromDeviceId», « fromClusterld» et TTL du message « InfoCluster » comme indiqué dans la table ci-dessous et transfère le message aux autres noeuds maîtres de cluster qu'il connaît à l'exception du noeud maître C1D4 dont il a reçu le message, à 30 savoir ici aux noeuds maîtres Al et Dl. deviceld cl usterld fromDeviceld fromClusterld knownClusters TTL C1D4 C B1 B (B, B1), (D, D1) 2 Le noeud maître Dl procède de la même façon que le noeud maître Bi à partir du message « InfoCluster » reçu du noeud maître C1D4. Le noeud maître Al reçoit le message « InfoCluster » en provenance du noeud maître 35 B1 et met à jour sa table de cluster CT(A1) en procédant de façon similaire à ce qui a été décrit précédemment pour Bi. Il a désormais connaissance de l'existence des clusters B, C, et D, et des noeuds maîtres désignés pour ces clusters. 18 On note que comme pour les messages « Hello », un mécanisme anti-bouclage peut être mis en oeuvre, notamment grâce au champ TTL pour stopper la retransmission d'un message « InfoCluster » en boucle. Par ailleurs, dans le mode de réalisation décrit ici, on a considéré que chaque noeud 5 maître maintient à jour une table de clusters CT contenant les clusters et les noeuds maîtres des clusters qu'il connaît. Dans une variante de réalisation, non seulement les noeuds maîtres des clusters maintiennent une telle table, mais également les autres noeuds du cluster, cette table contenant les clusters connus du noeud. Grâce à la table de clusters maintenue par les noeuds maîtres, il est possible comme 10 mentionné précédemment de mettre en oeuvre un protocole de routage réactif à l'extérieur de chaque cluster. On suppose ici que chaque noeud au sein d'un cluster connaît le noeud maître de son propre cluster (par exemple via une table de clusters telle que décrite ci-dessus, gérée par le noeud). Lorsqu'un noeud origine, par exemple le noeud A3 du cluster A, souhaite envoyer un 15 message contenant des données à destination d'un autre noeud du réseau ad hoc 1, par exemple à destination du noeud D2 appartenant au cluster D, celui-ci examine sa table de routage RT(A3) pour déterminer s'il connaît le noeud destinataire D2 et une route permettant d'atteindre ce noeud. Si le noeud D2 est répertorié dans sa table de routage (i.e. il existe au moins une ligne correspondant à ID=D2 dans la table), le noeud A3 identifie la route permettant d'atteindre le 20 noeud D2 (dans l'exemple de la table de routage illustré à la figure 3, il récupère la ou les routes contenues dans la colonne « ROUTE » de sa table et correspondant à un champ « ID » égal à D2), et envoie son message de données au prochain noeud indiqué par la route. Le cas où plusieurs routes sont déterminées est décrit plus en détail ultérieurement en référence à la figure 4. Si en revanche, le noeud D2 n'est pas répertorié dans sa table de routage, autrement 25 dit, le noeud A3 ne connaît pas de route pour joindre le noeud D2, il envoie un message de contrôle au noeud maître Al de son cluster conformément à un protocole de routage réactif. Ce message de contrôle est ici une requête RREQ de découverte de route, comprenant une pluralité de champs, à savoir : - un champ « sequenceNumber » contenant un numéro de séquence permettant de différencier 30 les requêtes RREQ lors de leur passage par un noeud commun ; un champ « sourceDeviceId » contenant un identifiant du noeud à l'origine de la requête RREQ ; - un champ « sourceClusterld » contenant un identifiant du cluster du noeud à l'origine de la requête RREQ ; 35 un champ « destDeviceId » contenant un identifiant du noeud destinataire de la requête RREQ (par exemple D2 dans l'exemple envisagé ici de la route pour joindre le noeud D2) ; 19 un champ « destClusterld » contenant un identifiant du cluster du noeud destinataire de la requête RREQ (par exemple D dans l'exemple envisagé ici de la route pour joindre le noeud D2) ; un champ « hops » contenant la liste des noeuds relayant la requête RREQ ainsi que les 5 caractéristiques des liens de connectivité qu'ils entretiennent avec les noeuds les précédant directement dans la liste. Ces caractéristiques comprennent notamment le type du lien de connectivité, mais peuvent également inclure d'autres caractéristiques du lien comme par exemple le débit théorique de ce lien, le temps de propagation sur le lien, la bande passante disponible, etc. ; 10 un champ « hopsCount » indiquant le nombre de sauts déjà effectués par la requête RREQ (i.e. nombre de noeuds intermédiaires traversés) ; et - un champ « 1TL » pour « Time-to-Live » représentant le nombre de sauts restant (i.e. noeuds) avant l'arrêt de la propagation de la requête RREQ. Les champs indiqués ci-dessus sont donnés à titre illustratif. En variante, le message 15 de contrôle « RREQ » peut comprendre d'autres champs (en plus ou en moins) que ceux indiqués ci-dessus. On note toutefois que le champ « hops » décrit ci-dessus est particulièrement avantageux dans le cadre de l'invention puisqu'il véhicule des informations sur les caractéristiques des liens de connectivité existant entre les noeuds (et notamment sur le type de ces liens de connectivité). 20 Si le noeud A3 appartient à plusieurs clusters, il envoie une requête RREQ à tous les noeuds maîtres des clusters auxquels il appartient. Le noeud maître Al sur réception de la requête RREQ, examine sa table de routage pour déterminer s'il connaît une route jusqu'au noeud D2. Si le noeud D2 est répertorié dans sa table de routage (i.e. il existe au moins une ligne correspondant à ID=D2 dans la table), le noeud 25 maître Al identifie la route permettant d'atteindre le noeud D2 et l'indique en réponse à la requête RREQ émise par le noeud A3 via un message de contrôle, en l'occurrence ici un message de réponse RREP. Sinon, le noeud maître Al examine sa table de clusters et transmet alors la requête RREQ aux noeuds maîtres des clusters qu'il connait (ou en variante de ses clusters voisins) après avoir mis à jour les champs « hop », « hopsCount » et « TTL » de la requête, autrement dit dans 30 l'exemple envisagé ici au noeud maître B1 du cluster B, au noeud maître D1 du cluster D et au noeud maître C1D4 du cluster C via les routes indiquées dans sa table de routage pour joindre ces noeuds maîtres. Sur réception de la requête RREQ provenant du noeud maître Al, le noeud maître B1 examine sa table de routage RT(B1) pour déterminer s'il connaît le noeud D2. Si D2 est répertorié 35 dans une ligne de sa table de routage RT(B1), il récupère la ou les routes correspondantes et la ou les retourne au noeud maître Al via un message de contrôle, en l'occurrence ici un message de réponse RREP. 20 Si le noeud maître 51 ne connaît pas de route pour joindre le noeud D2 (D2 n'est pas répertorié dans sa table de routage), le noeud maître B1 transmet la requête RREQ de découverte de route aux noeuds maîtres des clusters qu'il connaît à l'exception du noeud maître Al (obtenus de sa table de clusters), en l'occurrence ici aux noeuds maîtres D1 et C1D4. 5 Le noeud maître Dl, sur réception de la requête RREQ provenant du noeud maître Bi, examine sa table de routage RT(D1) pour déterminer s'il connaît le noeud D2. Comme c'est le cas (D2 appartient à son cluster), il renvoie la ou les routes permettant d'atteindre D2 au noeud maître B1 dans un message de réponse RREP (message de contrôle au sens de l'invention). On suppose ici que le message de réponse RREP a le même format et contient les mêmes champs décrits 10 précédemment que la requête RREQ. On note que le noeud maître D1 reçoit la requête RREQ de deux noeuds maîtres différents à savoir du noeud maître B1 et du noeud maître Al. Cela peut avantageusement lui permettre de découvrir plusieurs routes ayant des caractéristiques différentes. Le message de réponse RREP est donc également envoyé au noeud maître Al qui le relaye à son tour jusqu'au 15 noeud A3. Le noeud maître B1 fait suivre le message de réponse au noeud maître Al, qui le relaye à son tour jusqu'au noeud A3. Par ailleurs, le noeud maître C1D4 qui a aussi reçu la requête RREQ, connaît également une route pour joindre le noeud D2 (puisqu'il appartient au même cluster D ici). Le noeud maître 20 C1D4 renvoie donc lui aussi la route correspondante au noeud maître B1 dans un message de réponse RREP. Le noeud maître B1 retransmet le message de réponse au noeud maître Al qui le relaye à son tour vers le noeud A3. Conformément à l'invention, chaque noeud maître par lequel transite un message de réponse RREP extrait les informations de routage contenues dans ce message et met 25 avantageusement à jour sa table de routage avec ces informations avant de retransmettre le message de réponse vers le noeud (maître) suivant. Sur réception des deux messages de réponse envoyés respectivement par les noeuds maîtres D1 et C1D4, le noeud A3 met à jour sa table de routage RT(A3). Plus particulièrement il ajoute deux lignes dans sa table de routage RT(A3) (si chacun des messages contient une seule 30 route, sinon autant de lignes que de routes contenues dans les messages de réponse) dans lesquelles il indique les routes communiquées par les noeuds maîtres Cl et C1D4 permettant de joindre le noeud D2. La façon dont le noeud A3 sélectionne l'une de ces routes est décrite plus en détail ultérieurement en référence à la figure 4. On note qu'il est possible dans une variante de réalisation d'utiliser un protocole de 35 routage réactif différent de celui qui vient d'être décrit pour découvrir des routes en dehors de chaque cluster et remplir les tables de routage des noeuds du réseau ad hoc, tel que par exemple un protocole de routage réactif connu comme le protocole DSR, AODV, etc. 21 Conformément à l'invention, la table de routage RT(N) d'un noeud N est mise à jour, comme décrit précédemment, grâce aux messages de contrôle « Hello » échangés dans le cadre du protocole de routage proactif mis en oeuvre au sein de chaque cluster pour découvrir les routes actives au sein de ce cluster, grâce aux requêtes RREQ et aux réponses RREP à ces requêtes 5 échangées dans le cadre du protocole réactif à l'extérieur des clusters, mais également plus généralement à partir d'informations véhiculées par chaque message de contrôle émis au sein du réseau ad hoc 1 pour permettre le routage des données au sein de celui-ci. Ces messages de contrôle incluent notamment tous les messages de contrôle échangés dans le cadre des protocoles de routage proactif et réactif décrits précédemment, c'est-à-dire, non seulement les messages 10 visant à s'annoncer à ses noeuds voisins (messages « Hello »), les requêtes de découverte de route RREQ et les réponses à ces requêtes RREP, mais également, les messages d'erreur RRER remontés par les noeuds du réseau lorsque par exemple ils détectent qu'un noeud intermédiaire sur une route est devenu injoignable ou qu'un lien de connectivité s'est rompu, etc. De façon connue au sein d'un réseau ad hoc tel que le réseau ad hoc 1, lors d'un 15 échange de données entre un noeud origine et un noeud destinataire via une route déterminée par le noeud origine grâce à sa table de routage, si l'un des noeuds intermédiaires de la route devient injoignable (par exemple un noeud intermédiaire se déconnecte du réseau ad hoc 1) et un autre noeud de la route détecte le problème, celui-ci est configuré pour envoyer vers le noeud origine un message d'erreur désigné ici par message RERR. A titre illustratif, supposons dans l'exemple de la 20 figure 1 que le noeud A3 échange des données avec le noeud C3 via la route constituée des noeuds A3-A1-A2B2-B1-B4C4-C1D4-C3, et que le noeud B4C4 sorte du réseau ad hoc 1 (par exemple il est déconnecté). La route empruntée par les données échangées entre les noeuds A3 et 0 devient invalide. De ce fait, lorsque le noeud A3 émet un nouveau message de données à destination du noeud C.3, quand le message de données arrive sur le noeud Bl, le lien vers le noeud B4C4 n'est 25 plus disponible. Le noeud B1 détecte ce problème et renvoie un message d'erreur RERR vers le noeud A3 pour lui signaler le problème. Dans le mode de réalisation décrit ici, le message d'erreur RERR comprend une pluralité de champs, à savoir : un champ « sourceDeviceId » contenant un identifiant du noeud qui a détecté un problème 30 affectant la connectivité de l'un des noeuds du réseau ad hoc 1 (noeud devenu injoignable) et donc qui est à l'origine du message d'erreur RERR ; un champ « sourceClusterld » contenant un identifiant du cluster du noeud à l'origine du message d'erreur RERR ; - un champ « errorDeviceId » contenant un identifiant du noeud devenu injoignable ; 35 un champ « errorClusterld » contenant un identifiant du cluster du noeud devenu injoignable ; - un champ « errorLink » contenant le type du lien de connectivité vers le noeud devenu injoignable qui n'est plus utilisable (pour gérer les cas où un noeud peut être joignable via plusieurs interfaces de connectivité et que seulement l'une d'elles n'est plus utilisable) ; 22 - un champ « route » qui contient tous les noeuds intermédiaires appartenant à la route devenue invalide ainsi que les caractéristiques des liens de connectivité entre ces noeuds (par exemple sous la forme d'une série de couples comprenant l'identifiant des noeuds et les caractéristiques des liens de connectivité telles que décrites précédemment pour la table de routage). 5 Les champs indiqués ci-dessus sont donnés à titre illustratif. En variante, le message d'erreur « RRER » peut comprendre d'autres champs (en plus ou en moins) que ceux indiqués ci-dessus. On note toutefois que le champ « errorLink » décrit ci-dessus est particulièrement avantageux dans le cadre de l'invention puisqu'il véhicule des informations sur les caractéristiques du lien de connectivité vers le noeud devenu injoignable. 10 Tous les noeuds intermédiaires traversés sur la route entre les noeuds B1 et C3, à savoir dans cet exemple les noeuds A2B2 et A1, relaient le message d'erreur RERR émis par le noeud B1 pour signaler la non disponibilité du noeud B4C4 : conformément à l'invention, avant de relayer le message d'erreur vers le noeud suivant sur la route, les noeuds traversés extraient du message d'erreur l'information reflétant la non-disponibilité du noeud B4C4 (contenue dans les 15 champs errorDeviceId, errorClusterld, errorLink notamment, et en profitent pour mettre à jour leurs tables de routage respectives. Cette mise à jour consiste ici à invalider toutes les routes qui transitent par le noeud B4C4 dans leurs tables de routage, autrement dit à supprimer de leurs tables de routage les routes passant par le noeud B4C4. Dans la variante où les tables de routage comprennent uniquement des segments de route reliant directement deux noeuds, cette mise à 20 jour consiste à supprimer des tables de routage les segments dont le noeud origine ou le noeud de fin du segment est le noeud devenu injoignable c'est-à-dire ici le noeud B4C4. Dans le mode de réalisation décrit ici, les noeuds du réseau ad hoc 1 mettent également à jour leurs tables de routage à partir d'informations de routage véhiculées par les messages de données échangés sur le réseau ad hoc 1 et qui leur sont destinés ou transitent par 25 eux. On pourrait envisager dans un autre mode de réalisation que lorsqu'un noeud maître d'un cluster reçoit un message de contrôle de type message d'erreur, il le propage vers les noeuds de son cluster pour que ceux-ci mettent à jour leurs tables de routage en conséquence. Dans le mode de réalisation décrit ici, les noeuds du réseau ad hoc 1 mettent également à jour leurs tables de routage à partir d'informations de routage véhiculées par les 30 messages de données échangés sur le réseau ad hoc 1 et qui leur sont destinés ou transitent par eux. De façon connue, une fois qu'une route a été déterminée dans un réseau ad hoc entre un noeud origine d'un message de données et un noeud destinataire, il existe deux stratégies classiquement mises en oeuvre pour s'assurer que le message de données emprunte cette route : 35 - le message de données contient, par exemple dans un champ de son entête, la liste des identifiants de tous les noeuds intermédiaires de la route à emprunter, ainsi que les caractéristiques des liens de connectivité reliant ces noeuds intermédiaires entre eux (par exemple sous la forme d'une liste de couples comprenant l'identifiant de chaque noeud 23 intermédiaire associé aux caractéristiques du lien de connectivité à utiliser avec ce noeud). Quand un noeud intermédiaire reçoit le message de données, il se contente de le transférer au noeud suivant identifié dans la liste via le lien de connectivité indiqué ; ou le message de données contient, par exemple dans un champ de son entête, uniquement 5 l'identifiant du prochain noeud intermédiaire par lequel il doit passer. Quand un noeud intermédiaire reçoit le message de données, celui-ci consulte sa table de routage et détermine le noeud suivant vers lequel envoyer le message. La première stratégie présente l'avantage d'un temps de traversée des noeuds réduit, car il n'est pas nécessaire à ceux-ci de consulter leurs tables de routage pour relayer le message 10 de données. L'inconvénient toutefois est qu'en cas de route devenue invalide (suite par exemple à la déconnexion d'un noeud intermédiaire), il est nécessaire d'envoyer un message d'erreur RERR au noeud à l'origine du message de données pour que celui-ci choisisse une nouvelle route pour son message de données et le signale en réémettant son message de données avec la nouvelle route choisie. La première stratégie a donc un intérêt privilégié lorsque les noeuds du réseau ad hoc 1 15 sont stables et que les liens de connectivité entre les noeuds ne sont pas amenés à varier trop souvent dans le temps. La deuxième stratégie permet en revanche à un noeud intermédiaire qui détecte un problème de connectivité sur la route de la changer en temps réel, et donc de s'adapter à la nouvelle topologie du réseau ad hoc. Le temps de traversée de chaque noeud intermédiaire est 20 toutefois plus long que suivant la première stratégie, car celui-ci doit consulter sa table de routage. Dans le mode de réalisation décrit ici, on suppose que la première stratégie est mise en oeuvre par les noeuds du réseau ad hoc 1 lors de l'envoi de messages de données : chaque noeud à l'origine d'un message de données sélectionne une route dans le réseau ad hoc 1 pour ce message, comme indiqué plus en détail ultérieurement et la signale dans son intégralité dans 25 l'entête du message de données. On note que l'invention en préconisant le choix d'une route maximisant la stabilité des noeuds intermédiaires et des liens de connectivité liant ces noeuds améliore l'efficacité de la première stratégie. Comme évoqué précédemment, les noeuds du réseau ad hoc 1 mettent également à jour ici leurs tables de routage respectives à partir des informations de routage véhiculées par les 30 messages de données échangés sur le réseau ad hoc 1 et qui leur sont destinés ou transitent par eux. En effet, dans le mode de réalisation décrit ici, chaque message de données contient dans son entête, la liste des noeuds intermédiaires de la route choisie par le noeud à l'origine du message de données, ainsi que le type de lien de connectivité de chaque segment emprunté. Le message de données contient également des informations sur le noeud origine et/ou destination du message. 35 Les noeuds intermédiaires empruntés par le message de données peuvent donc avantageusement exploiter ces informations pour rafraîchir leurs tables de routage. Typiquement les noeuds intermédiaires peuvent utiliser les informations de routage contenues dans les messages de données qui transitent par eux pour découvrir l'existence de 24 nouveaux noeuds au sein du réseau et les routes pour atteindre ces nouveaux noeuds, étendant ainsi leur connaissance des éléments du réseau ad hoc 1. Mais ils peuvent également mettre à jour leurs tables de routage avec des informations complémentaires permettant d'évaluer la stabilité des routes et/ou leurs activités (par exemple en stockant dans leurs tables de routage des 5 informations complémentaires caractérisant les routes ou les segments répertoriés, comme notamment un paramètre correspondant à la dernière utilisation d'une route ou encore, en mettant à jour un paramètre de durée de vie caractérisant le temps depuis lequel une route existe. Les noeuds intermédiaires peuvent aussi supprimer de leurs tables de routage les routes devenues invalides quand ils transfèrent un message d'erreur émis en réponse à un message de données. 10 On note que dans le mode de réalisation décrit ici, chaque noeud N du réseau ad hoc 1 maintient une unique table de routage RT(N) référençant tous les noeuds du réseau qu'il connaît. En variante, chaque noeud peut gérer plusieurs tables de routage, par exemple une table de routage pour les noeuds de son cluster et une autre table de routage pour les noeuds externes à son cluster. 15 Nous allons maintenant décrire, en référence à la figure 4, les principales étapes mises en oeuvre par un noeud dit d'origine, référencé par N-ORIG, pour sélectionner une route dans le réseau ad hoc 1 lorsqu'il désire échanger des données avec un noeud dit destinataire, référencé par N-DEST, appartenant au réseau ad hoc 1. Ces étapes sont les étapes d'un procédé de sélection selon l'invention telles qu'elles sont mises en oeuvre par les modules de maintien à 20 jour 7, d'identification 8, de détermination 9 et de sélection 10 du noeud d'origine N-ORIG conformément à l'invention. On suppose donc ici qu'un noeud du réseau ad hoc 1 N-ORIG, par exemple le noeud NORIG=A2B2, souhaite envoyer un message de données à un noeud destinataire N-DEST du réseau ad hoc 1, par exemple au noeud N-DEST=D1 (étape E10). A cet effet, il consulte, par 25 l'intermédiaire de son module d'identification 8, sa table de routage RT(N-ORIG) dont un exemple pour le noeud A2B2 est illustré à la figure 3 (étape test E20), pour déterminer si celle-ci contient une ou plusieurs routes lui permettant de joindre le noeud destinataire N-DEST. Comme mentionné précédemment, les noeuds du réseau ad hoc 1, et notamment le noeud N-ORIG, sont configurés pour maintenir à jour leurs tables de routage respectives à partir 30 des informations remontées dans les messages de contrôle et dans les messages de données transitant par eux ou qui leur sont destinés. Ils peuvent à tout moment, si celles-ci ne contiennent pas les routes requises pour atteindre un noeud destinataire avec lequel ils souhaitent échanger des données, les compléter en envoyant un message de découverte de route (requête RREQ) tel que décrit précédemment. Ces différentes mises à jour constituent une étape de maintien à jour au 35 sens de l'invention (étape E00), mise en oeuvre par le module de maintien à jour 7 de chaque noeud du réseau ad hoc 1. On comprend bien que les mises à jour de la table de routage d'un noeud ne sont donc pas nécessairement corrélées avec l'envoi d'un message de données par celui-ci, mais elles peuvent être réalisées de manière asynchrone en fonction des messages de contrôle 25 et de données circulant au sein du réseau ad hoc 1 et transitant par le noeud en question ; une mise à jour de la table de routage d'un noeud peut toutefois être déclenchée en relation avec l'envoi d'un message de données par ce noeud à destination d'un noeud destinataire si le noeud ne contient pas dans sa table de routage de route identifiée lui permettant d'atteindre le noeud 5 destinataire (réponse non à l'étape test E20). Dans l'exemple de la table de routage RT(N-ORIG=A2B2) du noeud N-ORIG=A2B2 donné à la figure 3, il existe deux routes disponibles (i.e. actives) identifiées dans la table qui permettent de joindre le noeud destinataire D1 (réponse oui à l'étape E20) : - une première route R1 passe par les noeuds B1 et B3D3, avant d'arriver au noeud destinataire 10 D1 ; une deuxième route R2 passe par les noeuds B1, B4C4, C1D4 et D2 avant d'arriver au noeud destinataire Dl. La consultation de sa table de routage RT(N-ORIG) permet donc au noeud origine NORIG, et plus particulièrement à son module d'identification 8, d'identifier X routes R1,...,RX 15 disponibles pour atteindre le noeud destinataire N-DEST (X désignant un entier supérieur ou égal à 1), avec X=2 dans l'exemple de la figure 3, les deux routes identifiées étant les routes R1 et R2 précitées (étape E30). Si une seule route R1 est identifiée (X=1, réponse oui à l'étape test E40), le noeud NORIG indique ici dans l'entête du message de données qu'il souhaite envoyer au noeud destinataire 20 N-DEST la route R1 ainsi identifiée, et envoie son message de données via cette route au noeud destinataire N-DEST (étape E50), de façon connue en soi et non décrite en détail ici. Le message de données est relayé par les noeuds intermédiaires de la route comme mentionné précédemment, jusqu'au noeud destinataire N-DEST. Chaque noeud intermédiaire met à jour le cas échéant sa table de routage à partir des informations de routage indiquées par le noeud origine N-ORIG dans 25 l'entête du message de données. Si plusieurs routes disponibles R1,...,RX ont été identifiées par le module d'identification 8 dans la table de routage RT(N-ORIG=A2B2) (i.e. X>1, réponse non à l'étape test E40), conformément à l'invention le noeud N-ORIG, via son module de détermination 9 et son module de sélection 10, sélectionne la route disponible la plus stable au sein du réseau ad hoc 1. 30 A cet effet, le module de détermination 9 du noeud N-ORIG détermine, pour chaque route disponible Rx, x=1,...,X identifiée dans la table de routage, un niveau de stabilité de la route noté STAB-LEV(Rx) reflétant ici le niveau de stabilité des noeuds de cette route et des liens de connectivité reliant ces noeuds entre eux (étape E60). Dans le mode de réalisation décrit ici, pour déterminer le niveau de stabilité STAB- 35 LEV(Rx), il a été attribué au préalable à chaque type de lien de connectivité possible, un score de stabilité dit local. Ce score de stabilité local est, dans l'exemple envisagé ici, d'autant plus faible que le lien de connectivité est considéré comme stable. Cette convention n'est bien entendu aucunement limitative et la convention inverse peut être utilisée. 26 Plus particulièrement, dans le mode de réalisation décrit ici, le score de stabilité local attribué à un lien de connectivité de type filaire est plus faible que le score de stabilité local attribué à un lien de connectivité de type sans fil : le score de stabilité local d'un lien de connectivité de type filaire, au sens de la convention adoptée, est donc meilleur que le score de 5 stabilité local d'un lien de connectivité de type sans fil. On considère par exemple à titre illustratif ici l'attribution des scores de stabilité locaux suivants aux différents liens de connectivité susceptibles d'être utilisés dans le réseau ad hoc 1 : liens de connectivité de type filaire : o score local de 1 pour un lien optique, 10 o score local de 2 pour un lien Ethernet, o score local de 3 pour un lien xDSL (Digital Subscriber Line), etc. ; - liens de connectivité de type sans fil : o score local de 10 pour un lien utilisant un réseau mobile (de type 2G, 3G, 4G,...), o score local de 11 pour un lien LTE Direct, 15 o score local de 20 pour un lien WiFI, o score local de 21 pour un lien WiFI Direct, o score local de 30 pour un lien Bluetooth, etc. Bien entendu cet exemple n'est donné qu'à titre illustratif. On note que le score de stabilité local peut en outre dépendre d'un débit théorique associé au lien de connectivité et 20 atteignable sur ce lien. On peut à cet effet définir différentes tranches de débit, par exemple, une tranche DR1 allant de 0 à 1 Mbits/s, une tranche DR2 allant de 1 à 30 Mbit/s, une tranche DR3 allant de 30 à 100 Mbit/s et une tranche DR4 pour les débits supérieurs à 100 Mbit/s et associer un score local à chacune de ces tranches (par exemple, plus le débit est fort sur un lien, plus le score associé est faible), qui vient s'ajouter au score de stabilité local associé aux différents types de 25 liens de connectivité précités pour caractériser le score d'un lien de connectivité. De façon similaire, un score de stabilité local est associé en fonction du degré de mobilité de chaque noeud du réseau ad hoc 1. A cet effet, un score de stabilité local peut être associé de façon binaire selon si le noeud est considéré comme mobile ou fixe, mais une granularité plus importante peut être obtenue en attribuant, au sein de chaque catégorie 30 (correspondant à un degré de mobilité « fixe » ou à un degré de mobilité de type « mobile »), des scores de stabilité locaux en fonction du type de noeud considéré (ex. selon s'il s'agit d'un téléphone portable, d'une box, d'une station de base associée à une antenne d'un réseau mobile, etc.). On considère ici que les noeuds fixes sont plus stables que les noeuds mobiles, et donc un score de stabilité local plus faible (i.e. meilleur au regard de la convention adoptée) est attribué à 35 un noeud fixe par rapport à un noeud mobile. Par exemple, à titre illustratif : - pour les noeuds fixes, un score local compris entre 1 et 3 est attribué selon la répartition suivante : 27 o un score local de 1 est attribué à une station de base associée à une antenne radio d'un réseau mobile, o un score local de 2 est attribué à une box d'un opérateur, o un score local de 3 est attribué à un terminal tel qu'un ordinateur fixe ou portable ou 5 un objet connecté type objet IoT (Internet of Things) ; pour les noeuds mobiles, un score local de 10 est attribué quel que soit la nature du noeud considéré (téléphone intelligent, tablette numérique, etc.). Bien entendu cet exemple n'est donné qu'à titre illustratif. A partir des scores de stabilité locaux attribués aux différents types de liens et aux 10 différents degrés de mobilité possibles des noeuds du réseau ad hoc 1, le module de détermination 9 calcule un score de stabilité global pour chaque route Rx, x=1,...,X disponible identifiée par le module d'identification 8. Ce score de stabilité global reflète le niveau de stabilité STAB-LEV(Rx) de chaque route Rx. Il est calculé ici en sommant les scores de stabilité locaux attribués aux liens de connectivité des segments de la route en fonction de leur type et aux noeuds de cette route en 15 fonction de leur degré de mobilité. Ainsi, dans l'exemple envisagé ici des deux routes R1 et R2 : STAR-LEV(R1) = 21 + 10 + 21 + 10 + 30+3 segment (A2B2 ,I31) segment (B1 ,133D3) segment (B3D3 ,D1) soit STAB-LEV(R1)=95, et : STAR - LEV(R2) = 21 + 10 + 21 + 10 + 11+1 + 21 + 10 segment (A2B2 ,I31) segment (B1 ,B4C4) segment (B4C4 ,C1D4) segment (C1D4,1n) + 30+3 segment (D2 ,D1) soit STAB-LEV(R2)=138. En variante, une somme pondérée des scores locaux attribués aux liens et aux noeuds peut être envisagée avec des poids différents de l'unité (par exemple pour distinguer l'importance 20 de la stabilité des liens par rapport à celles des noeuds, etc.). Une fois ces deux niveaux de stabilité calculés, le module de sélection 10 du noeud NORIG sélectionne la route parmi les routes R1 et R2 présentant la meilleure stabilité (i.e. le meilleur niveau de stabilité), autrement dit avec la convention considérée ici, celle qui correspond au niveau de stabilité calculé le plus faible (étape E70). C'est donc ici la route R1 qui est 25 sélectionnée par le module de sélection 10 pour envoyer le message de données à destination du noeud destinataire N-DEST=D1. Le noeud N-ORIG indique cette route dans son message de données et l'émet via ses moyens de communication sur le réseau ad hoc 1 à destination du noeud Dl, de façon conventionnelle et connue en soi (étape E80). 30 Dans le mode de réalisation décrit ici la sélection de la route se fait de sorte à maximiser sa stabilité et plus particulièrement la stabilité de ses segments et de ses noeuds. Dans un autre mode de réalisation, outre la stabilité de la route, le module de sélection 10 tient compte 28 également d'autres facteurs pour sélectionner la route sur laquelle envoyer les données destinées au noeud N-DEST ; il peut notamment tenir compte du type des données que le noeud N-ORIG souhaite envoyer au noeud N-DEST et des contraintes temps réel que ce type de données impose. Ces facteurs peuvent être pris en compte lors par exemple du calcul du niveau de stabilité en 5 affectant à chaque route un score d'aptitude à véhiculer ce type de données (destiné à être ajouté au score global de stabilité calculé pour la route). Ce score d'aptitude additionnel peut être fixé en fonction par exemple : de la latence attendue sur la route par rapport à une latence minimum à garantir pour les données ; 10 - du débit offert par la route ; du temps de propagation sur la route par rapport à un temps de propagation maximal fixé pour les données (contrainte importante pour les applications temps réel) ; de la présence sur la route d'un certain type de connectivité (par exemple, on peut souhaiter privilégier une route stable n'utilisant pas de connectivité Bluetooth). 15 Ces critères sont évalués par exemple à partir des caractéristiques des liens de connectivité stockées dans la table de routage de chaque noeud. En tout état de cause, les contraintes précitées sont prises en compte en plus de la stabilité de la route, autrement dit, on favorise conformément à l'invention REVENDICATIONS1. Procédé de sélection d'une route dans un réseau ad hoc (1) destiné à être mis en oeuvre par un noeud de ce réseau, dit « premier noeud », ledit procédé de sélection comprenant : une étape (E00) de maintien à jour d'une table de routage contenant au moins une route disponible au sein du réseau ad hoc, chaque route comprenant au moins un segment de route reliant directement entre eux deux noeuds du réseau ad hoc par un lien de connectivité dont un type est identifié dans la table de routage, ladite table de routage comprenant en outre, pour chaque noeud différent du premier noeud appartenant à un dit segment de route, une indication concernant un degré de mobilité de ce noeud, la table de routage étant maintenue à jour à partir d'informations extraites de messages de contrôle émis sur le réseau ad hoc (1) destinés au premier noeud et de messages de contrôle émis sur le réseau transitant par le premier noeud ; lors de l'envoi (E10) d'un message de données par le premier noeud (N-ORIG) à destination d'un deuxième noeud (N-DEST) du réseau ad hoc : o une étape d'identification (E30) en utilisant la table de routage d'au moins une route disponible entre le premier noeud et le deuxième noeud pour envoyer le message de données ; et o si plusieurs routes disponibles sont identifiées (E40) : - une étape de détermination (E60), pour chaque route disponible identifiée, d'un niveau de stabilité à partir des indications concernant le degré de mobilité des noeuds de la route et du type des liens de connectivité des segments de la route contenus dans la table de routage ; et ^ une étape de sélection (E70) de la route disponible identifiée correspondant au meilleur niveau de stabilité déterminé. 2. Procédé de sélection selon la revendication 1 comprenant en outre : - une étape d'attribution d'un score de stabilité dit local à chaque type de lien de connectivité et à chaque type de degré de mobilité susceptibles d'être contenus dans la table de routage ; et une étape de calcul (E60) d'un score de stabilité dit global pour chaque route disponible identifiée reflétant le niveau de stabilité de cette route, ce score de stabilité global étant calculé à partir d'une somme pondérée des scores de stabilité locaux attribués aux liens de connectivité des segments de cette route en fonction de leur type et aux noeuds de cette route en fonction des indications concernant leur degré de mobilité contenues dans la table. 3. Procédé de sélection selon la revendication 2 dans lequel, lors de l'étape d'attribution : 30 le score de stabilité local attribué à un lien de connectivité de type filaire est meilleur que le score de stabilité local attribué à un lien de connectivité de type sans fil ; et/ou - le score de stabilité local attribué à un degré de mobilité de type fixe est meilleur que le score de stabilité local attribué à un degré de mobilité de type mobile. 5 4. Procédé de sélection selon la revendication 2 ou 3 dans lequel le score de stabilité local attribué à un type de lien de connectivité dépend d'une interface de connectivité utilisée sur ce lien et/ou d'un débit théorique atteignable sur ce type de lien. 10 5. Procédé de sélection selon l'une quelconque des revendications 1 à 4 dans lequel lors de l'étape de sélection (E80), la route est sélectionnée en tenant compte en outre : - d'un type des données transportées par le message ; et/ou - d'une contrainte en termes de temps de propagation, de latence et/ou de débit entre le premier noeud et le deuxième noeud ; et/ou 15 - d'une absence ou d'une présence d'au moins un type de lien de connectivité pour les segments de la route. 6. Procédé de sélection selon l'une quelconque des revendications 1 à 5 dans lequel les messages de contrôle à partir desquels la table de routage est maintenue à jour sont des 20 messages de contrôle d'un protocole de routage réactif comprenant des messages d'annonce, des messages de découverte de routes, des messages de réponse aux messages de découverte et des messages d'erreur signalant une indisponibilité d'un noeud ou d'un lien du réseau ad hoc. 7. Procédé de sélection selon l'une quelconque des revendications 1 à 6 dans lequel 25 lors de l'étape (E00) de maintien à jour, la table de routage est maintenue à jour en outre à partir d'informations de routage extraites de messages de données émis sur le réseau ad hoc destinés au premier noeud et/ou de messages de données émis sur le réseau transitant par le premier noeud. 8. Procédé de sélection selon l'une quelconque des revendications 1 à 7 dans lequel : 30 le réseau ad hoc (1) est organisé en clusters (A,B,C,D) ; - la table de routage comprend également pour chaque noeud différent du premier noeud appartenant à un dit segment de route, un identifiant d'au moins un cluster du réseau ad hoc auquel appartient ce noeud ; le premier noeud utilise un protocole de routage réactif pour émettre des messages de 35 découverte de route à destination de noeuds n'appartenant pas à un cluster auquel il appartient. 31 9. Programme d'ordinateur (PROG) comportant des instructions pour l'exécution des étapes du procédé de routage selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté par un ordinateur. 5 10. Support d'enregistrement (3) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PROG) selon la revendication 9. 11. Noeud (N-ORIG) d'un réseau ad hoc, dit « premier noeud », comprenant : un module (7) de maintien à jour d'une table de routage contenant au moins une route 10 disponible au sein du réseau ad hoc, chaque route comprenant au moins un segment de route reliant directement entre eux deux noeuds du réseau ad hoc par un lien de connectivité dont un type est identifié dans la table de routage, ladite table de routage comprenant en outre, pour chaque noeud différent du premier noeud appartenant à un dit segment de route, une indication concernant un degré de mobilité de ce noeud, la table de routage étant maintenue à 15 jour à partir d'informations extraites de messages de contrôle émis sur le réseau ad hoc (1) destinés au premier noeud et de messages de contrôle émis sur le réseau transitant par le premier noeud ; des modules (8,9,10) activés lors de l'envoi d'un message de données par le premier noeud à destination d'un deuxième noeud (N-DEST) du réseau ad hoc, et comprenant : 20 o un module d'identification (8), configuré pour identifier au moins une route disponible entre le premier noeud et le deuxième noeud en utilisant la table de routage maintenue à jour par le module de maintien à jour ; o des modules (9,10) activés si plusieurs routes disponibles entre le premier noeud et le deuxième noeud sont identifiées par le module d'identification, ces modules 25 comprenant un module (9) de détermination, configuré pour déterminer pour chaque route disponible identifiée, un niveau de stabilité à partir des indications concernant le degré de mobilité des noeuds de la route et du type des liens de connectivité des segments de la route contenus dans la table de routage, et un module de sélection (10) configuré pour sélectionner la route disponible identifiée correspondant au 30 meilleur niveau de stabilité déterminé. 12. Réseau (1) de communication ad hoc comprenant une pluralité de noeuds (N) selon la revendication 11. 35 13. Réseau (1) de communication ad hoc selon la revendication 12 dans lequel les noeuds sont organisés en une pluralité de clusters (A,B,C,D), lesdits noeuds étant configurés pour mettre en oeuvre un protocole de routage proactif au sein des clusters auxquels ils appartiennent respectivement et un protocole de routage réactif en dehors de ces clusters, chaque cluster 32 comprenant un noeud dit maître désigné pour le cluster apte à émettre des messages de contrôle selon le protocole de routage réactif à destination des noeuds maître des autres clusters, le noeud maître désigné pour un cluster correspondant au noeud parmi les noeuds du cluster qui est le plus stable en termes de connectivité et/ou d'activité au sein du réseau ad hoc.