Ad-hoc On-demand Distance Vector

AODV[6] définit cinq types de messages distincts, référencés à l'Internet Assigned Numbers Authority (IANA), transmis via le port UDP 654. Parmi ces messages ce sont les requêtes RREQ[7](route request) et les réponses RREP[8] (route reply) qui permettent de construire ses routes utilisées pour relayer les informations sur le réseau.

Lorsqu’un nœud source veut établir une route vers une destination pour laquelle il ne possède pas encore de chemin, il diffuse en broadcast un paquet RREQ. Si une réponse RREP est reçue alors l’opération de découverte de route est terminée. Dans le cas contraire, au bout d’un délai d’attente NET_TRANVERSAL_TIME[9], il rediffuse le message RREQ et attend une période supérieure à la première. En l'absence de réponse RREP, ce processus peut être répété jusqu'à RREQ_RETRIES fois (par défaut RREQ_RETRIES = 2[10]). S'il n’y a toujours pas de réponse au bout des trois (ou RREQ_RETRIES + 1) tentatives, le processus de recherche de route est abandonné. Une nouvelle demande de route sera initiée au bout d’un délai de 10 s. Un nœud recevant un paquet RREQ émettra alors un paquet RREP (route reply) s'il est la destination ou s'il possède une route vers la destination avec un numéro de séquence supérieur ou égal à celui du paquet RREQ sinon il rediffuse le paquet RREQ. Les nœuds conservent chacun une trace des IP sources et des identifiants de diffusion des paquets RREQ. Dans le cas où ils reçoivent un paquet RREQ qu’ils ont déjà traité, ils le suppriment.

Une fois que la source a reçu les paquets RREP, elle peut commencer à émettre des paquets de données vers la destination. Si, ultérieurement, la source reçoit un RREP contenant un numéro de séquence supérieur ou égal, mais avec un nombre de sauts plus petits, elle mettra à jour son information de routage vers cette destination et commencera à utiliser la meilleure route. Une route est maintenue aussi longtemps qu’elle continue à être active, c'est-à-dire tant que des données transitent entre la source et la destination. Le lien expire quand il n’y a plus de données en transit sur le lien et au bout d'un délai appelé ACTIVE_ROUTE_TIMEOUT[11]. En cas de coupure du lien, le nœud extrémité émet un paquet RERR[12] (Route Error) vers le nœud source pour le prévenir que la destination est désormais injoignable. Si le nœud source veut toujours obtenir une route vers cette destination, il doit recommencer le processus de découverte de route.

La figure ci-dessous illustre une recherche de route à l’initiative du nœud ${\displaystyle {\mathcal {A}}}$ et en direction de ${\displaystyle {\mathcal {J}}}$ et les différentes tables de routages constituées. La diffusion du message RREQ à partir de ${\displaystyle {\mathcal {A}}}$ se fait en broadcast vers tous ses voisins. Lorsque ${\displaystyle {\mathcal {J}}}$ reçoit le message il retourne un message RREP à ${\displaystyle {\mathcal {A}}}$ en passant par ${\displaystyle {\mathcal {H}}}$, ${\displaystyle {\mathcal {G}}}$ et ${\displaystyle {\mathcal {D}}}$.

Synoptique de détection de route possible par AODV entre deux nœuds A et J avec les tables de routages.

La figure ci-dessous illustre le flux de requêtes lors de l'établissement d'une connexion entre deux nœuds. La fin du schéma représente la rupture des échanges entre des nœuds en cours de transmission des données.

Flux de requêtes pour la découverte de routes et lors de la rupture de lien

Le message RREQ[13] de demande de route, est le message d'interrogation des routes disponibles. Il est constitué d'une trame de 24 octets :

• Les quatre premiers octets sont constitués du champ Type sur 8 bits forcé à 1 indiquant qu'il s'agit d'un message RREQ. Les bits suivants : J, R, G, D, U décrits plus bas indiquent les différentes utilisations du message. Un champ reserved sur 11 bits mis à 0 laisse la possibilité d'évolution ultérieurs. Puis un champ de 8 bits indique le nombre de sauts.
• Les quatre octets suivants portent l'identification du message.
• Les quatre suivants l'adresse IP de la destination.
• Les quatre suivants le numéro de séquence de la destination. Les deux suivants l'adresse IP d'origine.
• Les quatre derniers sont destinés à l'identification de la transaction par la source IP.

Message RREQ

• Le champ Type est forcé à 1.
• Le bit J : est positionné à 1 sur le message sortant en cas d'utilisation de multicast.
• Le bit R : est positionné à 1 sur le message retour en cas d'utilisation de multicast.
• Le bit G : Drapeau RREP gratuite, indique si un RREP gratuite doit être envoyé en unicast vers le nœud spécifiée dans le champ Adresse IP destination.
• Le bit D : Drapeau de destination seulement, indique que la destination seul peut répondre à cette RREQ.
• Le bit U : Numéro de séquence inconnue, indique à la destination que le numéro de séquence est inconnu.
• Reserved : Envoyés à 0, ignoré à la réception.
• Hop count : Le nombre de sauts à partir de l'adresse IP origine jusqu'au nœud de traitement de la demande.
• RREQ ID : Un numéro de séquence unique permet d'identifier les RREQ notamment lorsqu'elle est prise en association avec l'adresse IP d'origine.
• Destination IP Address : L'adresse IP destinataire pour laquelle une route est souhaitée.
• Destination Sequence Number : Le dernier numéro de séquence reçu par l'émetteur pour toute route vers le destinataire.
• Originator IP Address : L'adresse IP du nœud à l'origine de la demande de route.
• Originator Sequence Number : le numéro de séquence actuelle utilisée dans l'itinéraire pointant vers l'initiateur de la route demandée.

Le message RREP[14] de réponse à la demande de route, est le message indiquant au demandeur les routes disponibles. Il est constitué d'une trame de 20 octets :

• Les quatre premiers octets sont constitués du champ Type sur 8 bits forcé à 2 indiquant qu'il s'agit d'un message RREP. les deux bits R et A décrits plus bas indiquent pour le premier qu'une route défectueuse est réparée, le deuxième pour sa part indique que ce message sera suivi d'un RREP-ACK. Puis 12 bits réservés pour évolution mis à 0. 5 bits de préfixe référençant le nœud pour les routages. Puis un champ de 8 bits indique le nombre de saut.

• Les quatre octets suivants portent l'identification du message.
• Les quatre suivants l'adresse IP de la destination.
• Les quatre suivants le numéro de séquence de la destination. Les deux suivants l'adresse IP d'origine.
• Les quatre derniers sont destinés à l'identification de la transaction par la source IP.

Message RREP

• Le champ Type : forcé à 2.
• Le bit R : Indicateur de réparation; utilisée pour le multicast.
• Le bit A : acquittement requis.
• Reserved : Envoyé à 0, ignoré à la réception.
• Prefix Size : Si non nul, la taille de préfixe à 5 bits indique que le saut suivant peut être utilisé pour tous les nœuds avec le même préfixe de *routage (tel que défini par le préfixe Taille) pour la destination demandée.
• Hop Count : Le nombre de sauts à partir de l'adresse IP origine à l'adresse IP de destination. Pour une route de multicast demandée, indique le *nombre de sauts à effectuer à chaque membre de l'arbre en envoyant l'RREP.
• Destination IP : L'adresse IP de la destination pour laquelle une route est fournie.
• Destination Sequence Number : Le numéro de séquence de la destination associée à l'itinéraire.
• Originator IP Address : L'adresse IP du nœud à l'origine du RREQ pour laquelle l'itinéraire est fourni.
• Lifetime : Le temps en millisecondes pendant lequel les nœuds recevant l'RREP peuvent considérer la route comme étant valide.

Le message RERR[15] indiquant une route en erreur est le message retour signalant au demandeur les routes en erreur. Il est constitué d'une trame de 20 octets :

• Les quatre premiers octets sont constitués du champ Type sur 8 bits forcé à 3 indiquant qu'il s'agit d'un message RERR. le bit N décrit plus bas indique qu'une route défectueuse est réparée.
• Puis 15 bits réservés pour évolution mis à 0. Les 8 bits suivants indiquent le numéro de destination inaccessible.
• Puis sur quatre octets l'adresse IP de destination inaccessible.
• Les huit suivants indiquent si besoin le complément d'adresse.

Message RERR

• Le champ Type : forcé a 3.
• le bit N : Indicateur de non-suppression. Quand un nœud a effectué une réparation locale d'un lien. Les nœuds amont ne doivent pas supprimer la route.
• Reserved : Envoyé à 0, ignoré à la réception.
• DestCount : Le nombre de destinations inaccessibles inclus dans le message, doit être d'au moins de un.
• Unreachable Destination IP Address : L'adresse IP destinatrice qui est devenue inaccessible en raison d'une coupure de liaison.
• Unreachable Destination Sequence Number : Le numéro de séquence dans l'entrée de la table de routage pour la destination indiquée dans le champ précédent Destination IP inaccessible.

Le message RREP-ACK[16] d'accusé de réception de route de repli, est le message indiquant la prise en compte d'une autre route disponible. Il est constitué d'une trame de 2 octets. Le premier octet est constitué du champ Type sur 8 bits forcé à 4 indiquant qu'il s'agit d'un message RREP-ACK. Les 8 bits suivant mis à 0 sont réservés pour évolution.

Message RREP-ACK

• Le champ Type : forcé à 4.
• Reserved : forcé à 0, ignoré à la réception.

En octobre 2010 une étude[22] a été publiée sur les réseaux de capteurs ainsi que sur les différents protocoles de routage dont AODV. Cette étude aborde les contraintes liées aux capteurs sans fil (consommation énergétique[23], la qualité de service[24], etc ), les perspectives[25] futures d’utilisation de ces réseaux dans les domaines comme le médical, le militaire, dans des applications commerciales, mais aussi dans le domaine environnemental.

Cette étude cite des utilisations des réseaux de capteurs dans plusieurs milieux[26], tels que la maison intelligente, le milieu hospitalier, le milieu industriel, le milieu militaire...

En décembre 2010 le projet RISK[27] (Réseaux hétérogènes intelligents pour Situation de Crise) a été proposé. Ce projet présente un réseau de crise pour la sécurité civile (pompiers) ayant pour support des capteurs sans fils constituant un réseau Ad hoc avec AODV comme routage réactif de référence.

Lors d’événements exceptionnels comme une catastrophe naturelle, ou d'événement culturel, sportif ou autre, il est envisageable de pallier rapidement l’absence d’infrastructures de communication.

Des capteurs qui embarquent le logiciel AODV peuvent être utilisés dans divers autres domaines[28].

Le protocole AODV a été implémenté sur des systèmes d'exploitation. En 2004 le National Institute of Standards and Technology (NIST)[Note 1] adapte AODV sur le système d'exploitation Linux (Kernel 2.4)[20].

Pour le système d'exploitation Windows XP, en 2005 ComNets de l'Université de Bremen crée une version UoBWinAODV[21] version 0.15.

UoBJAdhoc[29] version 0.21 est une implémentation de AODV sur JAVA développé par l'Universite de Bremen.

Une adaptation de AODV : FB-AODV[30] (Flow-Based AODV) a été utilisé sur des mobiles avec Android comme système d'exploition pour former un réseau Ad hoc. Des tests[31] ont été réalisés pour transmettre sur des liens Wi-Fi[Note 2] des SMS[Note 3] et de la VoIP (Voice over IP)[Note 4] entre les différents équipements mobiles.

Le protocole AODV a été adapté et testé sur différents types de support de transmission, sur des réseaux WPAN (Wireless Personal Area Network)[Note 5] a base de ZigBee/802.15.4 en utilisant AODV-UU.

R-AODV[17] a été développé pour les réseaux Wi-Fi norme IEEE 802.11.

Des tests ont été menés sur des réseaux 4G (IMT-2000)[19], sur des ondes électromagnétiques en milieu sous-marin[32] mais aussi pour les réseaux WiMAX[18].

D'autres développements ont été réalisés sur des réseaux CDMA[33](Code Division Multiple Access)[Note 6], sur des réseaux 6LoWPAN[34].

En 2007 une expérimentation est réalisée sur un réseau utilisant la technologie Bluetooth. Pour cela une variante de AODV est créée : ADT-AODV[35].

Le protocole de routage AODV peut être installé sur différents équipements comme les micro-capteurs de Réseau de capteurs sans fil[28] mais aussi sur des PDA (Personal Digital Assistant)[Note 7], des ordinateurs portables...

Les équipements Qnode+[36] sont des points d’accès sans fil connectés à internet et font répéteurs pour les réseaux Mesh. Ils sont Auto configurable. En natif AODV est implémenté sur ces équipements.

L’ensemble de ces développements permettent de déployer des réseaux en mode Ad hoc sur des équipements (PDA, ordinateurs portables, réseaux de capteurs[28]) munis des caractéristiques citées ci-dessus.

Des constructions en grandeur réelle ont été réalisées dans plusieurs pays comme en Belgique avec le « Réseau Citoyen »[3]. Ce réseau expérimental a été déployé dans la ville de Bruxelles sur des technologies sans fil (Wi-Fi, Wireless). La réalisation de ce réseau a démontré la facilité d’implémentation de ce type de réseau pour un coût inférieur à l’implémentation d’un réseau traditionnel.

En Inde dans la région de Madurai et du Tamil Nadu, le projet SARI[4](Sustainable Access in Rural India)[Note 8] a été inauguré en 2001.

En 2004 au Cameroun, « Cameroun Sans-Fil »[37] permet de construire des réseaux dans des villages sans infrastructure de télécommunication. Chaque individu installe chez lui un PC avec une carte réseau Wi-Fi.

En 2009 une expérimentation de pilotage de robots[38] est faite en utilisant AODV comme protocole de routage de message entre les machines. La transmission de ces messages se fait au moyen de capteurs Wi-Fi équipant chaque automate.

La société LocustWorld[39] commercialise des solutions de réseau à base de Wi-Fi et utilise le protocole de routage AODV dans son offre commerciale « LocustWorld MeshAP Pro Clustering ». Le village de Cilcennin[40] en Angleterre a choisi cette technologie pour raccorder ses habitants à Internet en l'absence d'infrastructure.

Le protocole AODV est basé sur les algorithmes DSDV[60] et DSR. AODV a un routage potentiellement moins couteux que DSR[61].

Le protocole DSR (Dynamic Source Routing[Note 13]) est similaire à AODV dans le sens où il forme une route à la demande quand un ordinateur veut transmettre. Cependant, il utilise le routage à la source au lieu de se baser sur la table de routage de chaque routeur intermédiaire. Le protocole DSR n'est pas très efficace dans les grands réseaux étant donné que chaque source doit avoir la vision du réseau. Le coût de maintenance des tables de routage est important. Mais pour les petits et moyens réseaux, il prend un avantage sur AODV, RMT ou TORA[62].

Le protocole ABR[63] (Associativity-Based Routing)[Note 14] est un autre protocole de routage à la source[60] Cependant, ABR est basée sur la stabilité, il ne prend pas en compte rapidement les ruptures de lien. Il n'utilisera pas forcément le plus court chemin vers la destination. Les chemins alternatifs ne seront pas immédiatement utilisés[60].

Le protocole DSDV garantit les routes sans boucle. Il fournit un seul chemin vers une destination, qui est sélectionné en utilisant le vecteur de distance du plus court chemin dans l'algorithme de routage. DSDV introduit une charge importante sur le réseau en raison de la mise à jour périodique des messages, et la surcharge augmente en fonction de sa taille. Il n'est pas adapté à un réseau de grande échelle[59].

Le protocole WRP garantit également les routes sans boucles. grâce à des tables de routage temporaires en utilisant les informations reçues. Toutefois, WRP exige pour chaque nœud le maintien de quatre tables de routage. Ceci introduit une quantité de données importante en mémoire pour chaque nœud lié à la taille du réseau[59].

Le protocole CGSR est un protocole de routage hiérarchique où les nœuds sont regroupés en grappes. L'avantage de ce protocole est que chaque nœud maintient les routes de son cluster source, ce qui signifie que les coûts généraux de routage sont faibles. Cependant, il y a des surcoûts importants liés à l'entretien des grappes[64].

Le protocole TORA[42] Temporally-ordered routing algorith[Note 9] est basé sur le protocole LMR. L'avantage de TORA est qu'il réduit la portée des messages de contrôle des nœuds voisins, où le changement de topologie est survenue. Un autre avantage de TORA est qu'il supporte aussi le multicast.

L'inconvénient de TORA est que l'algorithme peut aussi produire temporairement des itinéraires invalides comme dans RMT.

Le protocole ZRP[43] Zone Routing Protocol[Note 10]Les nœuds sont dans une zone de routage, qui définit une plage (en saut) que chaque nœud doit maintenir pour assurer la connectivité du réseau de façon proactive.

Pour les nœuds de la zone de routage, les routes sont immédiatement disponibles. Pour ceux hors de la zone de routage, les itinéraires sont déterminés à la demande (soit réactive). L’avantage de ce protocole est qu'il a considérablement réduit les échanges par rapport aux protocoles purement proactifs.

C'est le nœud frontière qui d'une façon proactive maintient les routes vers la destination.
L'inconvénient est qu'en cas de nombre de zone de routage important, le protocole peut se comporter comme un protocole proactif pur, tandis que pour de petites valeurs, il se comporte comme un protocole réactif.

Le protocole HECTOR[65] : Energy effiCient Tree-based Optimized Routing protocol for wireless networks[Note 15] HECTOR est un protocole hybride efficace à base d'arbre de routage optimisé, basé sur deux jeux de coordonnées virtuelles. Un jeu est basé sur les coordonnées d'origine, et l'autre est basée sur les distances en nombre de saut des destinataires.
L'algorithme qui transmet des paquets à son voisin optimise le ratio puissance/distance. Si le nœud n'existe plus, alors la transmission est faite au voisin qui réduit la distance des arbres et optimise les coûts.
La supériorité de l'algorithme sur les alternatives existantes est qu'il y a une garantie de la livraison.

Le protocole MMDV[66] : MMDV est un protocole de type hybride qui s'appuie sur AODV et est une amélioration[59] du protocole AODV qui utilise les trajets multiples et l’inondation par la technique MPR. MMDV (Multipath and MPR based AODV). Dans sa phase proactive, les nœuds calculent leurs listes MPR et maintiennent des routes vers les voisins à deux sauts. Dans sa phase réactive, les nœuds maintiennent "deux" chemins pour chaque destination. Cette solution permet de minimiser la charge de routage et réduire la consommation de la bande passante tout en résolvant le problème de changements de topologie. Les performances de MMDV dépassent celles des protocoles AODV, OLSR et DSR.

Pour les études précédemment citées des outils de simulations ont été utilisés, parmi lesquels on peut citer :

• Network Simulator[Note 16] NS-2[67]. Le logiciel NS, logiciel libre de simulation à événements discrets est fourni avec une interface graphique (NAM) permettant de démontrer le fonctionnement des réseaux, ce qui en fait un outil à la valeur pédagogique très intéressante.

Il est considéré par beaucoup de spécialistes des télécommunications comme le meilleur logiciel de simulation à événements discrets.

• OPNET[68] (0ptimized Tool Engineering Network)[Note 17] fournit une environnement de développement complet pour l'analyse de spécification, de simulation et de la performance des réseaux de communication. Il est très proche de NS-2 comme le montre la conclusion de cette étude[69].

• OMNEST[70] est utilisé pour étudier divers scénarios et alternatives de conception : conception architecturale, sans fil / filaire protocoles et de réseaux, basée sur file d'attente et d'autres systèmes. Ce logiciel permet de construire et d'évaluer des simulations dans un IDE intégré de simulation.

• JiST/MobNet[71]: Combined Simulation, Emulation, and Real-world Testbed for Ad hoc Networks[Note 18] .
  Ce simulateur permet de tester une modélisation sur plusieurs plans.

Modélisation analytique, simulation de réseau, émulation de réseau et intégration des expériences du monde réel.

Le mémoire de Nouha Baccour[72] de 2004 compare deux simulateurs pouvant traiter jusqu'à 10 000 nœuds.

• GloMoSim[73]: a library for parallel simulation of large-scale wireless networks[74].
• NCTUns[75]: The design and implementation of the NCTUns 1.0 network simulator[76]

Le projet Senslab est un projet du programme « Télécommunications » de l’Agence nationale de la recherche (ANR) sur les « Very large open wireless sensor networks » initié en 2008 concernant les réseaux de capteurs à grandes échelles. Il s’inscrit dans le contexte des réseaux de capteurs sans fils et utilise des nœuds réels fixes ou mobiles. Ce programme a pour objectif de faciliter l’expérimentation de très grands réseaux de capteurs sans fils.

Le logiciel Wireshark Wireshark networkt Protocol Analyser[Note 19] (anciennement Ethereal) est un logiciel libre d'analyse de protocole, ou « packet sniffer », utilisé dans le dépannage et l'analyse de réseaux informatiques, le développement de protocoles, l'éducation et la rétro-ingénierie, mais aussi le piratage.

Wireshark reconnait 759 protocoles.

En 2010, une étude comparative[77] a été menée entre DSR et AODV dans les réseaux VANET (Vehicular Ad-Hoc Network)[Note 20]. Cette étude a démontré qu'AODV est plus adaptée que DSR pour une utilisation dans des voitures. En effet, les résultats montrent qu'en faisant varier la vitesse des véhicules le nombre de paquets perdus est moins important avec le protocole AODV qu'avec DSR.

En 2011 une étude comparative[78] a été menée entre DSR, AODV et DSDV sur un réseau WiMAX. Lorsque les nœuds sont peu mobiles AODV est le protocole qui obtient les meilleurs résultats alors que DSR est supérieur lorsque la mobilité augmente. DSDV obtient dans tous les cas des résultats inférieurs aux deux autres protocoles.

En 2007, l'étude de Maamar[79] montre l'impact de la mobilité, le nombre de nœuds (ou densité), l’énergie consommée par les nœuds et la variation de l’échelle, sur le taux de perte pour les protocoles (DSR, DSDV et L’AODV). De cette simulation effectuée avec NS-2[67], il en ressort entre autres que pour un protocole de transport TCP, la quantité d’énergie[80] consommée est petite pour DSR, moyenne pour DSDV et importante pour l’AODV. Alors que pour le protocole UDP AODV prend la tête du classement. Concernant la mobilité[80] c'est DSR qui est le plus efficace en utilisant TCP. L'augmentation du nombre[81] de nœuds quant à lui permet de faire décroître le taux de perte en utilisant UDP. De ce fait la perte sur un réseau moins dense est énorme par rapport à un réseau contenant de plus en plus de nœuds, quel que soit le protocole utilisé (AODV, DSDV ou DSR). Enfin, concernant la variation de l'échelle[81] c'est DSR qui s'en sort le mieux et concernant DSDV et AODV leur classement dépend de l'échelle. Il conclut que le choix de l’algorithme de routage dépend des contraintes précédemment citées et qu’il est intéressant de considérer et de combiner le maximum d’entre elles pour tirer les meilleurs profits.

En définitive, il est très difficile de comparer des protocoles de routage[82]. Par exemple, dans le cas de OLSR et AODV, Hsu[83] conclut que AODV est le plus performant tandis que Gauthier[84] affirme que OLSR surpasse le protocole AODV. Bien évidemment, les deux résultats sont corrects mais le contexte d'étude est différent. En effet, dans son étude, Gauthier prend en compte l'impact des interférences radio ce que ne fait pas Hsu.

D'autres études se préoccupent des performances spécifiques à AODV[85]. Cette évaluation est réalisée dans une approche comparative à la suite de la simulation de trois configurations réseau différentes en termes de dimensions du réseau (m²), nombre de nœuds (N) et densité de nœuds (N/km²). En entrée on utilise un modèle de trafic à débit constant et un modèle de mobilité aléatoire en augmentant la vitesse. Il en ressort les résultats suivants :

• 
  Figure 1 - Graphique issu de l'étude de Nabil Tabbane en 2004[86]
• 
  Figure 2 - Graphique issu de l'étude de Nabil Tabbane en 2004[87]
• 
  Figure 3 - Graphique issu de l'étude de Nabil Tabbane en 2004[86]
• 
  Figure 4 - Graphique issu de l'étude de Nabil Tabbane en 2004[86]
• 
  Figure 5 - Graphique issu de l'étude de Nabil Tabbane en 2004[86]

La figure 1 représente le taux des paquets livrés avec succès. Quand les nœuds sont presque immobiles ce taux est très proche des 100 %. Par contre on voit clairement l'influence négative de la vitesse de déplacement des nœuds et de la taille du réseau et du nombre de nœuds. Les réseaux 1 et 2 ont un taux très semblable jusqu'à une vitesse de déplacement de 10 m/s. Au-dessus, ce taux va chuter pour le réseau 2 alors que pour le réseau 1, il est toujours supérieur à 90 %. Pour le réseau 3 le taux se dégrade dès l'augmentation de la mobilité des nœuds. Ceci est dû à une augmentation de la longueur des routes et par conséquent, les HELLO_MESSAGE échangés sont plus nombreux. En cas de coupure de liaison, le nœud source, pour qu'il en soit informé, doit attendre pendant un certain temps durant lequel les paquets de données en cours de route vont être perdus. Si nous réduisons la période d’émission des HELLO_MESSAGE pour détecter plus rapidement les liaisons cassées, il y aura alors plus de paquets de contrôle (HELLO_MESSAGE) aux dépens des paquets de données.

La figure 2 représente le trafic de contrôle. Il existe toujours une différence entre le trafic de contrôle pour chacun des 3 réseaux. C’est essentiellement les HELLO_MESSAGE qui font cette différence qui s'explique par les routes assez longues dans le réseau 2 et encore plus longues dans le réseau 3. Lorsque les nœuds sont peu mobiles le trafic de contrôle est quasiment le même pour les 3 réseaux. Cette propriété est due au fait que le protocole AODV est un protocole réactif qui n’agit qu’en cas de demande d’établissement de route. Le trafic de contrôle augmente avec la mobilité des nœuds. Cette augmentation est due à la fréquence des liaisons cassées provoquant l’émission des paquets RERR. Lorsque la vitesse de déplacement des nœuds augmente considérablement (15 m/s et 20 m/s), Nabil Tabbane observe que le trafic de contrôle devient de plus en plus indépendant de cette augmentation de mobilité et tend vers une valeur presque constante. Ceci montre que le protocole AODV est bien adapté aux changements fréquents de la topologie du réseau. Néanmoins, il faut trouver un compromis entre la dégradation du taux de livraison des paquets (figure 1) et le trafic de contrôle pour les réseaux fortement mobiles ; c’est-à-dire trouver les valeurs optimales des paramètres HELLO_INTERVAL et ALLOWED_HELLO_LOSS qui minimisent le taux de perte des paquets sans trop augmenter le trafic de contrôle sur le réseau.

La figure 3 représente le temps d'établissement d'une route. Elle montre globalement une bonne aptitude du protocole AODV à trouver une route dans le réseau. La vitesse de déplacement des nœuds a peu d'influence sur cette valeur qui tend vers une constante. Également, plus il y a de nœuds plus le temps d'établissement d'une route diminue.

La figure 4 nous donne le délai moyen pour acheminer un paquet de données depuis le nœud source jusqu’au nœud destination. Pour les 3 réseaux et pour les différentes vitesses de déplacement, le délai d’un paquet reste presque constant. En effet, si la mobilité des nœuds augmente, ceci va engendrer trop de liaisons rompues et donc les paquets qui sont déjà dans le buffer depuis un certain temps, sont directement éliminés ce qui fait que le délai n’est comptabilisé que pour les paquets ayant atteint leur destination. Cette suppression des paquets mis dans le buffer est la principale cause de l’augmentation du taux de perte des paquets lorsque la mobilité des nœuds augmente. La durée maximale pendant laquelle un paquet est autorisé à rester dans un buffer ne doit être trop longue car ceci va augmenter la consommation des ressources mémoire disponibles pour les buffers et augmenter le délai de bout en bout d’un paquet. Donc la fixation de cette durée varie selon que l’application exige un taux de perte faible sans grande importance pour le délai (transfert de fichier, base de données, etc.) ou bien que l’application exige un délai très court sans grande importance pour le taux de perte (vidéo, téléphonie, etc.). La figure 5 représente la longueur moyenne des routes. La première constatation est que le nombre de sauts que doit effectuer un paquet pour être acheminé du nœud source au nœud destination augmente avec la taille du réseau et du nombre de nœuds dans le réseau. Cependant, pour une configuration donnée (réseau 1 ou 2 ou 3), ce nombre augmente très faiblement avec la vitesse de déplacement des nœuds. Ceci vient confirmer la figure 4 puisqu'un nombre constant de sauts donne un délai de transmission d'un paquet constant. L'adaptabilité du protocole AODV vis-à-vis de la mobilité du réseau est au prix d’un taux de perte des paquets qui augmente avec cette mobilité.

À la suite de cette étude[85], Tabbane constate que le protocole AODV offre une bonne adaptabilité vis-à-vis de la mobilité des nœuds dans un réseau en termes de délai, de temps d’acquisition de route, de trafic de contrôle et de longueur de route[87]. D’autre part, AODV présente un taux de livraison des paquets avec succès qui se dégrade avec l’augmentation de la mobilité des nœuds du réseau[87]. Il ajoute qu’un autre travail de simulation reste nécessaire avant de conclure d’une manière définitive sur les performances de ce protocole. Ces simulations devront porter cette fois sur l’effet précis des paramètres internes du protocole AODV comme RREQ_RETRIES[88], HELLO_INTERVAL[88] ou DELETE_PERIOD[88].

AODV fait partie des protocoles MANET les plus connus[89]. Il a suscité et suscite encore de nombreux articles scientifiques. Son choix par rapport à d'autres protocoles MANET, qu'ils soient proactifs, hybrides ou même par rapport à d'autres protocoles réactifs doit être guidé par le réseau sur lequel il doit être mis en œuvre. Jean-Pierre Chanet[90] propose un classement avec les avantages et les inconvénients des différentes catégories de protocoles de routage :

Il est dit explicitement que chaque famille de protocole de routage est plus ou moins adaptée à un type de réseau. Il convient donc de définir précisément les caractéristiques du réseau (taille, mobilité des nœuds, ressources des nœuds, volume d'information à échanger...) afin de bien choisir un protocole de routage adapté.

De même, la sécurité que l'on verra dans un paragraphe dédié est désormais une réflexion qu'il est nécessaire de mener parallèlement.

Enfin, si AODV est le plus adapté, comme l'évoque Nabil Tabbane[87] dans sa conclusion, l'ajustement du paramétrage doit faire l'objet d'une étude à part entière.

Les recherches récentes sur les réseaux ad-hoc ne se focalisent que très peu sur les aspects sécurité[91]. Pourtant leurs spécificités montrent à quel point les réseaux ad hoc sont vulnérables[92]. Parmi ces vulnérabilités figurent :

• la transmission en milieu ouvert ;
• les problématiques de topologies dynamiques ;
• l'absence d’autorité centrale ;
• la nécessité d'une bonne coopération des nœuds ;
• l'hétérogénéité des participants avec pour certains des capacités restreintes.

Pour donner un exemple de vulnérabilité sur une transmission en milieu ouvert (sans fil), on peut mettre en avant l'exposition des nœuds à des problèmes d'intégrité physique[93]. Une surveillance sismique[94] par exemple, nécessite de lâcher des capteurs dans la nature. Ils deviennent alors physiquement accessibles. Un moyen de contourner ce problème est de mettre en évidence une attaque physique sur un élément. Autre exemple concret, le fait que les nœuds utilisent une transmission sans fil les rend également très sensibles une à Attaque par déni de service[92] sur le canal radio.

Les autres vulnérabilités précédemment citées nous amènent à faire un focus sur le routage des réseaux ad hoc. Il est identifiée comme particulièrement sensible[95]. Son fonctionnement nécessite entre autres, la bonne coopération de tous les nœuds, ce qui présente un risque s'il n'y a aucun contrôle des participants. Par conséquent l'authentification, l'intégrité, la confidentialité et la disponibilité doivent faire l'objet d'une attention particulière. Parmi les attaques liées aux problèmes d'authentification on peut citer le trou noir[96] (blackhole). Cette attaque consiste à insérer un nœud malicieux ayant la capacité d'usurper l'identité d'un nœud valide. Le nœud en question pourra ainsi ignorer les données qu'il est censé faire transiter. L'attaque «grey hole», qui en est une variante, pourra ignorer seulement certains types de paquets. La figure ci-dessous décrit une attaque de type blackhole.

Description d'une attaque BlackHole issue de l'étude de Gayrault[96]

Dès lors qu'un nœud malicieux est intégré au réseau il devient possible de créer des boucles infinies ou de détourner du trafic pour consommer de l'énergie.

De même, si l'authentification est mal gérée, un attaquant peut s'attacher au réseau sans fil et injecter des messages erronées. L'intégrité des messages échangées est donc une exigence importante pour ces réseaux. Si l'intégrité physique des nœuds est également mal gérée un attaquant peut subtiliser un appareil, le corrompre avec un cheval de Troie par exemple, avant de le restituer discrètement à son propriétaire.

Enfin, la disponibilité reste un point difficile à gérer dans les réseaux sans fil ad hoc étant donné les contraintes qui pèsent sur ces réseaux. Notamment la topologie dynamique, les ressources limitées sur certains nœuds de transit et les communications sans fil.

L’absence d’infrastructure centralisée[97] dans les réseaux sans fil ad hoc compromet l’utilisation directe des systèmes d’authentification basés sur la cryptographie à clé publique. En effet, ces systèmes d’authentification supposent l’utilisation de certificats établis par une autorité centrale. Le certificat, signé par l’autorité centrale, permet de garantir qu’une clé publique appartient bien à son propriétaire et non à un usurpateur. L’opération de vérification de certificat ne se limite pas à contrôler la signature de l’autorité centrale. Il est aussi nécessaire de s’assurer que le certificat est toujours en cours de validité́ et qu’il n’a pas été révoqué. Une révocation de certificat est indispensable si la clé privée du propriétaire a été volée ou divulgué. Il existe trois grands courants dans le domaine de l’authentification pour les réseaux sans fil ad hoc. Deux de ces orientations se basent sur l'établissement d’une clé secrète permettant par la suite l’authentification des participants. Toute la complexité réside en la manière d’établir cette clé. Les deux modèles basés sur une clé secrète sont:

• The key agreement[97] : les participants s’entendent sur une clé secrète.

Concrètement, des solutions proposent l'utilisation de la méthode de Diffie-Hellman généralisée aux multiples participants. Chaque nœud possédant une partie de la clé résultante[98]. Cette solution s'avère finalement compliquée à mettre en œuvre sur des réseaux ad hoc.

• The Duckling Security Policy Model[99] : le modèle d’authentification élaboré par Ross Anderson et al.[100] est basé sur une relation de type maître-esclave. Lors de sa première utilisation, un objet doit être marqué par son propriétaire. Lors de cette opération une clé secrète est échangée entre les deux entités via un canal supposé sûr. Néanmoins ce modèle n'est pas complètement satisfaisant notamment pour la gestion des clés qui ne peut être centralisée sans risque[93].
• Le troisième axe de recherche pour l’authentification au sein de réseaux sans fil ad hoc, se base sur une infrastructure à clés publiques (PKI) et cherche à s’affranchir du besoin d’une entité centrale de certification[93]. Ce modèle proposé par Hubaux et al.[101] se base sur une infrastructure à clés publiques auto-organisée. Chaque nœud en réseau établit des certicats pour les nœuds en qui il a confiance. Lorsque deux nœuds d'un réseau veulent communiquer sans connaissance au préalable l'un de l'autre, ils s'échangent leur liste de certificats et vont essayer de créer une chaîne de confiance entre eux. Supposons qu'un élément A veuille communiquer avec un nœud C, si A fait confiance à un troisième élément B et C fait aussi confiance à B, alors une chaîne de confiance entre A et C pourra être établie via B.

Il s'agit là d'utiliser des signatures numériques ou des MACs[102]. Une signature électronique ou un MAC (Message Authentication Code) apposé à un message a pour double objectif de permettre au destinataire d'authentifier l'origine de ce message et de lui prouver son intégrité. Leur implémentation fait appel aux fonctions de hachage et aux clés symétriques ou asymétriques. Dans le cas de l'usage de la cryptographie symétrique, on emploie exclusivement le terme de MAC, tandis que dans l’usage de la cryptographie asymétrique, on peut parler de MAC, mais on préférera le terme de signature électronique.

La confidentialité[103] quant à elle peut être est gérée grâce à une cryptographie symétrique peu gourmande en calcul et donc en énergie.

Cette liste de solutions n'est pas exhaustive, en effet Beghriche[104] cite également des Mécanismes basés sur la réputation, des Mécanismes de micro-paiement, des Mécanismes basés sur la confiance ou bien encore des Systèmes de détection d'intrusion.

• SAODV[105] Ce protocole est dédié à la sécurisation du protocole AODV. L’idée principale de SAODV[105] consiste à utiliser des signatures afin d’authentifier la plupart des champs des paquets Route_Request et Route Reply et d’utiliser des chaines de hachage pour protéger l’intégrité du compteur de sauts. Ainsi, SAODV constitue-t-il une extension d’AODV avec des signatures, afin de contrer les attaques de type «usurpation d’identité».

• ARAN[106] Ce protocole utilise la cryptographie à clés publiques pour sécuriser les routes. ARAN[106] est un protocole à la demande, qui fournit un service d’authentification de saut en saut par le biais d’une infrastructure à clés publiques. Le principe d’ARAN[106] est sécuriser le mécanisme de découverte de routes de nœuds en nœud. Ainsi lorsqu’un nœud désire envoyer un message, il génère, signe puis diffuse un paquet de type RDP (Route Discover Packet). Par la suite, chaque nœud intermédiaire recevant ce paquet vérifie le certificat du nœud précédent, appose son propre certificat et rediffuse le paquet. Une fois ce paquet arrivé au nœud destination, celui-ci vérifie à son tour le certificat et répond en unicast, par un message de type REP (reply packet) qui est à son tour vérifié de nœuds en nœuds.

• SEC-AODV[55] utilisent également des certificats et une infrastructure de gestion de clés publiques.

• SAR[107] Le protocole SAR[107] (Security-aware Ad hoc Routing protocol) se base lui sur des procédés de chiffrement symétrique. Il a été élaboré à l’origine pour prévenir les attaques de type blackhole[Note 21]. SAR[107] est conçu pour être employé conjointement avec des protocoles réactifs tels qu’AODV ou DSR. Il utilise la notion de “niveaux de confiance” pour établir la sécurité d’un chemin. Ainsi, lorsqu’un nœud désire établir une route avec un certain niveau de sécurité, il génère un nouveau paquet RREQ indiquant le niveau requis. Par la suite, le mécanisme de découverte de routes diffère légèrement du schéma classique des protocoles réactifs en ce sens que seuls les nœuds satisfaisant le niveau de sécurité requis peuvent rediffuser la requête à ses voisins.

• RIDAN[108] (Real-time Intrusion Detection for Ad hoc Networks) qui propose une architecture initialement basée sur une recherche de détections d'attaques sur le protocole de routage OSPF. Cette solution est destinée à détecter des intrusions en temps réel (Système de détection d'intrusion).

Malcolm Parsons[109] montre l'effet négatif sur les performances des réseaux ad hoc soumis à des attaques de type blackhole[110] ou encore de type wormhole[111] en fonction de leur nombre. Pour ces tests il utilise le protocole AODV[110].

Graphique issu du travail de Pearson[112]

Sur le graphique ci-dessus, lorsque AODV est soumis à des attaques de type blackhole[Note 21] par exemple[113] son PLR[Note 22] subit une augmentation importante.

La protection contre ces attaques n'est pas gratuite pour autant. Des recherches concernant la sécurisation du protocole AODV se préoccupent donc parallèlement de l'impact sur les performances. C'est le cas d'une étude datant de 2010[114] qui montre le coût[115] engendré par la sécurisation de SAODV[105] par rapport à AODV notamment. Les résultats de Balakrishna montrent que SAODV met 2,35 fois plus de temps que AODV pour obtenir une réponse RREP à une requête RREQ. Ceci est dû entre autres à la cryptographie qui augmente la taille des messages.

SRS_AODV[116] utilise des fonctions cryptographiques robustes tout en minimisant la charge du calcul complexe. Cette étude montre entre autres que SRS_AODV[117] établi ses routes plus rapidement que ARAN[106].

• 
  Nombre de paquets reçus par la victime - Graphique issu de l'étude de Nesrine[118]
• 
  Temps moyen de bout en bout - Graphique issu de l'étude de Nesrine[117]
• 
  Overhead du routage - Graphique issu de l'étude de Nesrine[118]

Les graphiques ci-dessus illustrent la comparaison qu'a effectué Nesrine[116] et montrent que SRS_AODV est plus performant que AODV sur le temps moyen de bout en bout, l'overhead de routage et le nombre de paquets de données reçues par le nœud victime.

• (en) Charles E. Perkins et Elizabeth M. Royer, « Ad-hoc On-Demand Distance Vector Routing », 2nd IEEE workshop on mobile computing systems and applications,‎ 26 février 1999, p. 90-100 (DOI 10.1109/MCSA.1999.749281, lire en ligne)

• (en) David B. Johnson et David A. Maltz, « Dynamic Source Routing in Ad Hoc Wireless Networks », The Kluwer International Series in Engineering and Computer Science: Mobile Computing, vol. 353,‎ 1996, p. 153-181 (ISBN 978-0-585-29603-6, DOI 10.1007/978-0-585-29603-6_5, lire en ligne)

• (en) Marcel C. Castro et Laura Gallucio, « Opportunistic P2P Communications in Delay-Tolerant Rural Scenarios », EURASIP Journal on Wireless Communications and Networking, vol. 2011,‎ 2011 (DOI 10.1155/2011/892038, lire en ligne)
• Lionel Barrère, « Étude et proposition de services dans les réseaux mobiles militaires de type MANet », Thèse Université Bordeaux 1,‎ 9 juillet 2009, p. 1-17 (lire en ligne)
• (en) Charles Perkins et Elizabeth Royer, « Ad hoc On-Demand Distance Vector (AODV) Routing », RFC 3561[1],‎ 2003, p. 1-37 (lire en ligne)
• (en) Joseph P. Macker et M Scott Corson, « Mobile Ad Hoc Networking and the IETF », ACM SIGMOBILE Mobile Computing and Communications Review, vol. 2, n^o 2,‎ avril 1998, p. 9-12 (ISSN 1559-1662, DOI 10.1145/584017.584023, lire en ligne)
• Valérie Gayraud et Loufti Nuaymi, « La Sécurité dans les Réseaux Sans Fil Ad Hoc », Symposium sur la sécurité des technologies de l'information et des communications,‎ 2003, p. 1-20 (lire en ligne)
• (en) Ioanna Stamouli et Patroklos G. Argyroudis, « Real-time Intrusion Detection for Ad hoc Networks », Sixth IEEE International Symposium on a World of Wireless Mobile and Multimedia Networks,‎ 27 juin 2005, p. 1-7 (DOI 10.1109/WOWMOM.2005.85, lire en ligne)
• (en) Nadia Qasim, Said Fatin et Hamid Aghvami, « TORA », 2008 World Congress on Engineering, vol. 1,‎ 2 juillet 2008 (ISBN 978-988-98671-9-5, lire en ligne)

• (en) Haas Zygmunt, « A new routing protocol for the reconfigurable wireless networks », 6th International Conference on Universal Personal Communications - ICUPC 97,‎ 6 août 1997, p. 1-5 (ISBN 0-7803-3777-8, DOI 10.1109/ICUPC.1997.627227, lire en ligne)
• (en) M.S. Corson, S. Papademetriou, V. Park et A. Qayyum, « IMEP », An Internet MANET Encapsulation Protocol (IMEP) Specification, vol. draft-ietf-manet-imep-spec-01.txt,‎ 7 août 1999, p. 1-36 (lire en ligne)
• (en) Mehran Abolhasan et Tadeusz Wysocki, « A review of routing protocols for mobile ad hoc networks », Ad hoc networks, vol. 2,‎ 1^er janvier 2004, p. 1-22 (DOI 10.1016/S1570-8705(03)00043-X, lire en ligne)
• (en) J. Hsu et S. Bhatia, « Performance of mobile ad hoc networking routing protocols in realistic scenarios », 2003 IEEE Military Communications Conference, vol. 2,‎ octobre 2003, p. 1268-1273 (ISBN 0-7803-8140-8, DOI 10.1109/MILCOM.2003.1290408, lire en ligne)
• (en) S-J Lee et M. Gerla, « AODV-BR: backup routing in ad hoc networks », IEEE Wireless Communications and Networking Conference, WCNC'2000, vol. 3,‎ 28 septembre 2000, p. 1311-1316 (ISBN 0-7803-6596-8, DOI 10.1109/WCNC.2000.904822, lire en ligne)
• (en) Charles E. Perkins et Elizabeth M. Royer, « AODV Routing for IPV6 », Mobile Ad Hoc Networking Working Group, INTERNET DRAFT, vol. 3,‎ 10 novembre 2000, p. 1311-1316 (ISBN 0-7803-6596-8, DOI 10.1109/WCNC.2000.904822, lire en ligne)
• (en) Elizabeth M Royer et Charles E. Perkins, « Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing », Mobile Ad Hoc Networking Working Group,‎ juillet 2000, p. 1-22 (lire en ligne)
• (en) Jaehoon Jeong, Jungsoo Park et Hyoungjun Kim, « Name directory service based on MAODV and multicast DNS for IPv6 MANET », 60th IEEE Vehicular Technology Conference, VTC2004-Fall, vol. 7,‎ 29 septembre 2004, p. 4756-4753 (ISBN 0-7803-8521-7, DOI 10.1109/VETECF.2004.1404994, lire en ligne)
• (en) M.K. Marina et S.R. Das, « On-demand multipath distance vector routing in ad hoc networks », Ninth International Conference on Network Protocols,‎ 3 août 2002 (ISBN 0-7695-1429-4, DOI 10.1109/ICNP.2001.992756, lire en ligne)
• (en) J-C Cano et P. Manzoni, « A performance comparison of energy consumption for Mobile Ad Hoc Network routing protocols », 8th International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems,‎ 6 août 2002, p. 57-64 (ISBN 0-7695-0728-X, DOI 10.1109/MASCOT.2000.876429, lire en ligne)
• (en) Joo-Han Song, Vincent W.S Wong et Victor C.M Leung, « Efficient On-Demand Routing for Mobile Ad-Hoc Wireless Access Networks », IEEE Global Telecommunications Conference, GLOBECOM'03,‎ 2003 (ISBN 0-7803-7974-8, DOI 10.1109/GLOCOM.2003.1258299, lire en ligne)
• (en) Chia-Ching Ooi et N Fisal, « Implementation of geocast-enhanced aodvbis routing protocol in MANET », TENCON 2004. 2004 IEEE Region 10 Conference,‎ 2004 (ISBN 0-7803-8560-8, DOI 10.1109/TENCON.2004.1414682, lire en ligne)
• (en) Stephan Eichler et Christian Roman, « Challenges of Secure Routing in MANETs: A Simulative Approach using AODV-SEC », 2006 IEEE International Conference on Mobile Adhoc and Sensor Systems (MASS),‎ 15 janvier 2007 (ISBN 1-4244-0507-6, DOI 10.1109/MOBHOC.2006.278589, lire en ligne)
• (en) A.-G Malek, « New energy model: Prolonging the lifetime of Ad-hoc On-Demand Distance Vector Routing Protocols (AODV) », 2nd International Conference on Future Computer and Communication (ICFCC), vol. 2,‎ 21-24 mai 2010, p. 426-429 (ISBN 978-1-4244-5821-9, DOI 10.1109/ICFCC.2010.5497468, lire en ligne)
• (en) E.A. Panaousis et C. Politis, « A game theoretic approach for securing AODV in emergency Mobile Ad Hoc Networks », 34th IEEE Conference on Local Computer Networks, LCN 2009.,‎ 20-23 octobre 2009 (ISBN 978-1-4244-4488-5, DOI 10.1109/LCN.2009.5355020, lire en ligne)
• (en) Zhongyu Cao et Gang Lu, « S-AODV: Sink Routing Table over AODV Routing Protocol for 6LoWPAN », Second International Conference on Networks Security Wireless Communications and Trusted Computing (NSWCTC),‎ 24-25 avril 2010, p. 340-343 (ISBN 978-0-7695-4011-5, DOI 10.1109/NSWCTC.2010.213, lire en ligne)
• (en) M. Usha, S. Jayabharathi et R.S.D. Wahida Banu, « RE-AODV: An enhanced routing algorithm for QoS support in wireless ad-hoc sensor networks », 2011 International Conference on Recent Trends in Information Technology (ICRTIT),‎ 3-5 juin 2011, p. 567 - 571 (ISBN 978-1-4577-0588-5, DOI 10.1109/ICRTIT.2011.5972449, lire en ligne)
• Abderrahmen Mtibaa, « Étude des performances du protocole MMDV : Multipath and MPR based AODV », HAL-INRIA archive ouverte,‎ 2006, p. 4 (lire en ligne)

• (en) Sun-Ho Lee et Dong-Ho Cho, « On-demand energy-efficient routing for delay-constrained service in power-controlled multihop cellular network », 60th IEEE Vehicular Technology Conference, VTC2004-Fall, vol. 5,‎ 26-29 septembre 2004, p. 5 (ISBN 0-7803-8521-7, DOI 10.1109/VETECF.2004.1404632, lire en ligne)

• (en) P. Sankar et V. Lakshmi, « Study on the performance of Ad-hoc routing protocols on vehicles », 2011 IEEE Recent Advances in Intelligent Computational Systems (RAICS),‎ 22-24 septembre 2011, p. 1-6 (ISBN 978-1-4244-9478-1, DOI 10.1109/RAICS.2011.6069392, lire en ligne)

• (en) R. AbRahman et M. Kassim, « Performance analysis of routing protocol in WiMAX network », 2011 IEEE International Conference on System Engineering and Technology (ICSET),‎ 27-28 juin 2011, p. 1-5 (ISBN 978-1-4577-1256-2, DOI 10.1109/ICSEngT.2011.5993440, lire en ligne)
• Jean-Pierre Chanet, « Algorithme de routage coopératif à qualité de service pour des réseaux ad hoc agri-environnementaux », Thèse Université Blaise Pascal - Clermont II,‎ 2007, p. 1-138 (lire en ligne)
• (en) Vincent Gauthier et Romain De Rasse, « On a Comparison of four Ad-hoc Routing Protocols when taking into account the Radio Interferences », 3rd International working Conference on performance modeling and evaluation of heterogeneous networks, HET-NET'05,‎ 2005 (lire en ligne)
• Nabil Tabbane et Sami Tabbane, « Simulation et mesure des performances du protocole de routage AODV », JTEA'2004,‎ 21-22 mai 2004, p. 1-5 (lire en ligne)
• (en) Young Zhang et Yifei Wei, « R-AODV: Rate aware routing protocol for WiFi mesh networks », 2006 IET International Conference on Wireless, Mobile and Multimedia Networks,‎ 6-9 novembre 2006, p. 1-4 (ISBN 0-86341-644-6, lire en ligne)
• (en) Ming-Tuo Zhou Harada et H. Peng-Yong, « A method to deliver AODV routing messages using WiMAX mesh MAC control messages in maritime wireless networks », 2009 IEEE 20th International Symposium on Personal, Indoor and Mobile Radio Communications,‎ 13-16 septembre 2009, p. 1537 - 1541 (ISBN 978-1-4244-5122-7, DOI 10.1109/PIMRC.2009.5449888, lire en ligne)
• (en) Wu Youjun et Nie Jingnan, « Performance Evaluation for Cross-Layer AODV Protocol in CDMA-Based Ad-Hoc Networks », International Conference on Communication Technology, ICCT '06.,‎ 27-30 novembre 2006, p. 1 - 4 (DOI 10.1109/ICCT.2006.341758, lire en ligne)
• (en) Xiang-Guo Yang et Hao Chen, « Simulation of the Routing Protocol of Mobile Ad Hoc Networks at the Rate of 4G », 4th International Conference on Wireless Communications, Networking and Mobile Computing, WiCOM'08,‎ 12-14 octobre 2008, p. 1 - 3 (ISBN 978-1-4244-2107-7, DOI 10.1109/WiCom.2008.631, lire en ligne)
• (en) Xianhui Che Wells et I. Kear, « A Static Multi-hop Underwater Wireless Sensor Network Using RF Electromagnetic Communications », 29th IEEE International Conference on Distributed Computing Systems Workshops, ICDCS Workshops'09,‎ 22-26 juin 2009, p. 460-463 (ISBN 978-0-7695-3660-6, DOI 10.1109/ICDCSW.2009.36, lire en ligne)
• Rachid Abdellaoui, « SU-OLSR une nouvelle solution pour la sécurité du protocole OLSR », Mémoire de maîtrise, école de technologie supérieure université du Québec,‎ 2009, p. 126 p. (lire en ligne)
• (en) Yih-Chun Hu et Adrian Perrig, « Ariadne: a secure on-demand routing protocol for ad hoc networks », Wireless Networks, vol. 11, n^os 1-2,‎ janvier 2005, p. 1-18 (DOI 10.1007/s11276-004-4744-y, lire en ligne)
• (en) Yih-Chun Hu et Adrian Perrig, « SEAD: secure efficient distance vector routing for mobile wireless ad hoc networks », Ad Hoc Networks, vol. 1, n^o 1,‎ juillet 2003, p. 175-192 (DOI 10.1016/S1570-8705(03)00019-2, lire en ligne)
• (en) Yih-Chun Hu et Adrian Perrig, « Packet Leashes: A Defense against Wormhole Attacks in Wireless Ad Hoc Networks », Twenty-Second Annual Joint Conference of the IEEE Computer and Communications Societies, INFOCOM 2003, vol. 3,‎ 3 avril 2003, p. 1976-1986 (ISBN 0-7803-7752-4, DOI 10.1109/INFCOM.2003.1209219, lire en ligne)
• (en) K. Sanzgiri et B. Dahill, « A secure routing protocol for ad hoc networks », 10th IEEE International Conference on Network Protocols,‎ 12-15 novembre 2002, p. 78-87 (ISSN 1092-1648, DOI 10.1109/ICNP.2002.1181388, lire en ligne)
• (en) Manel Guerrero Zapata, « Secure ad hoc on-demand distance vector routing », ACM SIGMOBILE Mobile Computing and Communications Review, ACM, vol. 6, n^o 3,‎ juillet 2002, p. 106-107 (DOI 10.1145/581291.581312, lire en ligne)
• (en) An Liu et Cliff Wang, « Defending DSSS-based broadcast communication against insider jammers via delayed seed-disclosure », 26th Annual Computer Security Applications Conference, ACSAC'10,‎ 2010, p. 1-10 (ISBN 978-1-4503-0133-6, DOI 10.1145/1920261.1920315, lire en ligne)
• (en) S.S. Ramaswami et S. Upadhyaya, « Smart Handling of Colluding Black Hole Attacks in MANETs and Wireless Sensor Networks using Multipath Routing », 2006 IEEE Information Assurance Workshop,‎ 21-23 juin 2006, p. 253 - 260 (ISBN 1-4244-0130-5, DOI 10.1109/IAW.2006.1652103, lire en ligne)
• (en) P. Papadimitratos et Z.J. Haas, « Secure data communication in mobile ad hoc networks », IEEE Journal on Selected Areas in Communications, vol. 24,‎ février 2006, p. 343-356 (DOI 10.1109/JSAC.2005.861392, lire en ligne)
• (en) Guibadj Nesrine et Mehar Sara, « SRS_AODV (Secure Routing Scheme for AODV) », 20th International Symposium on Software Reliability Engineering (ISSRE'2009),‎ 2009 (lire en ligne)
• (en) N. Mitton et T. Razafindralambo, « Hector is an Energy Efficient Tree-Based Optimized Routing Protocol for Wireless Networks », 4th International Conference on Mobile Ad-hoc and Sensor Networks,‎ 22 décembre 2008, p. 31-38 (ISBN 978-0-7695-3457-2, DOI 10.1109/MSN.2008.24, lire en ligne)
• (en) Malcolm Parsons et Peter Ebinger, « Performance Evaluation of the Impact of Attacks on Mobile Ad hoc Networks », 28th International Symposium on Reliable Distributed Systems,‎ 2009 (lire en ligne)

• (en) H. A. Esmaili et M. R. Khalili Shoja, « Performance Analysis of AODV under Black Hole Attack through Use of OPNET Simulator », World of Computer Science and Information Technology Journal (WCSIT), vol. 1, n^o 2,‎ 2011, p. 49-52 (lire en ligne)
• (en) R. Balakrishna et U. Rajeswar Rao, « Comparisons of SAODV and TAODV, DSR Mobile ad hoc network Routing Protocols », International Journal of Advanced Networking and Applications, vol. 2,‎ 2010, p. 445 - 451 (lire en ligne)
• (en) Baruch Awerbuch et David Holmer, « An on-demand secure routing protocol resilient to byzantine failures », 1st ACM workshop on Wireless security, WiSe'02,‎ 2002, p. 21 -30 (ISBN 1-58113-585-8, DOI 10.1145/570681.570684, lire en ligne)
• (en) Baruch Awerbuch et Reza Curtmola, « Mitigating Byzantine Attacks in Ad Hoc Wireless Networks », Technical Report, Department of Computer Science, Johns Hopkins University,‎ 2004, p. 1-16 (lire en ligne)
• Sedrati Maamar et Aouragh Lamia, « Étude des Performances des Protocoles de Routage dans les Réseaux Mobiles Ad-Hoc », 4th International Conference on Computer Integrated Manufacturing, CIP’2007,‎ 3-4 novembre 2007, p. 1-7 (lire en ligne)
• (en) Gilberto Flores Lucio et Marcos Paredes-Farrera, « OPNET Modeler and Ns-2: Comparing the Accuracy Of Network Simulators for Packet-Level Analysis using a Network Testbed », WSEAS Transactions on Computers, vol. 2, n^o 3,‎ juillet 2007, p. 700-707 (lire en ligne)
• (en) Xinjie Chang, « Network simulations with OPNET », 1999 Winter Simulation Conference, vol. 1,‎ 1999, p 307-314 (DOI 10.1109/WSC.1999.823089, lire en ligne)
• (en) Chai-Keong Toh, « A Novel Distributed Routing Protocol To Support Ad-Hoc Mobile Computing », 1996 IEEE Fifteenth Annual International Phoenix Conference on Computers and Communications,‎ 27-29 mars 1996, p. 1-7 (DOI 10.1109/PCCC.1996.493675, lire en ligne)
• (en) Miguel Catalan-Cid et Jose Luis Ferrer, « Contention- and Interference-Aware Flow-Based Routing in Wireless Mesh Networks: Design and Evaluation of a Novel Routing Metric », EURASIP Journal on Wireless Communications and Networking, n^o 1,‎ avril 2010, p. 1-20 (DOI 10.1155/2010/313768, lire en ligne)
• (en) Oscar Guerra et Moisés Sanchez-Adam, « Network AD HOC Routing Algorithm: An Application with Bluetooth », 17th International Conference on Electronics, Communications and Computers, CONIELECOMP'07.,‎ 26/28 février 2007, p. 1-6 (DOI 10.1109/CONIELECOMP.2007.26, lire en ligne)
• (en) Tronje Krop, Michael Bredel, Matthias Holick et Ralf Steinmetz, « JiST/MobNet: combined simulation, emulation, and real-world testbed for ad hoc networks », Second ACM international workshop on Wireless network testbeds, experimental evaluation and characterization, WinTECH '07,‎ 2007 (ISBN 978-1-59593-738-4, DOI 10.1145/1287767.1287774, lire en ligne)
• (en) X. Zeng, R. Bagrodia et M. Gerla, « GloMoSim: a library for parallel simulation of large-scale wireless networks », Twelfth Workshop on Parallel and Distributed Simulation, PADS'98,‎ mai 29 1998, p. 154-161 (ISBN 0-8186-8457-7, DOI 10.1109/PADS.1998.685281, lire en ligne)

• (en) S.Y. Wang, C.L. Chou et C.H. Huang, « The design and implementation of the NCTUns 1.0 network simulator », Computer networks, vol. 42, n^o 2,‎ 2003, p. 175-197 (DOI 10.1016/S1389-1286(03)00181-6, lire en ligne)
• Abdesselem Beghriche, « De la Sécurité à la E-Confiance basée sur la Cryptographie à Seuil dans les Réseaux sans fil Ad hoc », Thèse de doctorat, Université de L’Hadj Lakhdar-Batna, Faculté des sciences de l’ingénieur Département d’informatique,‎ 2010, p. 1-128 (lire en ligne)
• (en) Jean-Pierre Hubaux et Levente Buttyán, « The quest for security in mobile ad hoc networks », 2nd ACM international symposium on Mobile ad hoc networking & computing, MobiHoc'01,‎ 2001, p. 146-155 (ISBN 1-58113-428-2, DOI 10.1145/501436.501437, lire en ligne)
• (en) F. Stajano et R. Anderson, « The Resurrecting Duckling: security issues for ubiquitous computing », IEEE Computer, vol. 35,‎ 7 avril 2002, p. 22-26 (DOI 10.1109/MC.2002.1012427, lire en ligne)
• (en) Seung Yi et Prasad Naldurg, « Security-aware ad hoc routing for wireless networks », 2nd ACM international symposium on Mobile ad hoc networking & computing, MobiHoc'01,‎ 2001, p. 299 - 302 (ISBN 1-58113-428-2, DOI 10.1145/501449.501464, lire en ligne)

• (en) « RFC 3561 »
• « L'implémentation d'AODV-UU par l'université d'Uppsala (Suède) »
• « capteurs sans fils »

• « The Network Simulator - ns-2 »

• Portail des télécommunications