THÈSE DE DOCTORAT. Contrôle intelligent de flux capable de

MINISTÈRE DE L ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE SCIENTIFIQUE UNIVERSITÉ MOULOUD MAMMERI DE TIZI OUZOU FACULTÉ DE GÉNIE ÉLECTRIQUE ET D INFORMATIQUE DÉPARTEMENT D INFORMATIQUE THÈSE DE DOCTORAT SPÉCIALITÉ : INFORMATIQUE Présentée par Malika BELKADI Ep SAAD Sujet Contrôle intelligent de flux capable de s adapter à l état d un MANET Devant le jury d examen composé de : HAMADOUCHE Djamel Professeur UMMTO Président LALAM Mustapha Professeur UMMTO Rapporteur M ZOUGHI Abdellaziz Professeur IRIT TOULOUSE Co-Rapporteur BENMOHAMMED Mohamed Professeur U. Constantine Examinateur BILAMI Azzedine Professeur U. BATNA Examinateur BALLA Ammar Professeur ENSI, Oued Smar Examinateur AHMED OUAMER Rachid M. C. A UMMTO Invité Soutenu le

Remerciements Je remercie profondément M r. Mustapha LALAM, Professeur au Département d Informatique de l UMMTO, pour son soutien, ses encouragements, ses conseils, sa patience et son aide précieuse durant ces années de thèse. Je tiens également à exprimer ma reconnaissance pour sa qualité d enseignement et pour m avoir formée durant tout mon cursus universitaire (en graduation et en post-graduation : Magister et Doctorat). Mes plus sincères et chaleureux remerciements sont adressés à Mr Abdelaziz M ZOU- GHI, Professeur à l Institut de Recherche en Informatique de Toulouse (IRIT). Je le remercie fortement pour son soutien, ses remarques précieuses, ses orientations et pour toutes les séances de travail au laboratoire de l IRIT. Je lui exprime mes remerciements pour m avoir accueillie à plusieurs reprises dans son laboratoire, pour son hospitalité, et pour avoir mis à notre disposition tous les moyens du laboratoire. Un grand merci à tous les membres de son équipe, en particulier François thiebolt. Mes sincères remerciements vont également à M r. Djamel HAMADOUCHE, Professeur au département de Mathématique de l UMMTO pour avoir accepté de présider le jury de soutenance. J exprime ma gratitude à M r. Azeddine BILAMI, professeur à l Université de BATNA, à M r. Amar BALLA, professeur à l ESI et à M r. Mohamed BENMOHAMED, professeur à l Université de Constantine pour avoir accepté de participer dans le jury de soutenance. Je remercie chaleureusement M r. Rachid AHMED-OUAMER, maître de conférence et directeur du LAboratoire de Recherche en Informatique de Tizi-Ouzou (LARI) pour avoir mis à notre disposition tous les moyens du laboratoire, pour son enseignement durant ma graduation et ma première post-graduation ainsi que pour avoir accepté de participer dans le jury d examen. Merci à tous ceux qui m ont apporté de l aide, chacun à sa manière tout au long de ma thèse. Mes remerciements sont également adressés à mes parents et aux membres de ma famille qui ont toujours été là pour m encourager et soutenir. Un grand merci à mon mari pour ses encouragements et sa compréhension.

Résumé Les réseaux sans fil constituent de plus en plus une technologie émergente offrant à ses utilisateurs de nombreux avantages en termes de coût et de facilité d utilisation. Cependant, ils sont soumis à une multitude de challenges, en particulier la mobilité des nœuds, le routage et le problème de ressources limitées comme l énergie et la bande passante. Pour satisfaire les besoins croissants en ressources, tout en évitant les congestions et les pertes de paquets, de nouvelles solutions en terme de routage et de contrôle de flux s imposent. En effet, les solutions qui ont été introduites dans l environnement filaire deviennent inadaptées pour des réseaux sans fil ad hoc. Dans cette thèse, nous proposons une nouvelle solution permettant de répondre à ces besoins. Cette solution repose en premier lieu sur un protocole de routage avec qualité de services. Elle utilise les systèmes fourmis pour la recherche de meilleures routes ; celles qui offrent plus de bande passante, qui minimisent le délai et qui ont une plus grande stabilité. Ensuite, nous rajoutons à cette solution un mécanisme de contrôle de flux explicite pour ajuster et adapter à chaque fois le débit de transmission de l émetteur aux capacités des liens formant la route trouvée. L utilisation des systèmes fourmis est motivée par leur intelligence, leur capacité d adaptation aux changements de leur environnement dans la recherche de routes et leur aptitude à réduire le flux de contrôle dans le réseau. Mots clés : Réseaux mobiles Ad Hoc, Protocole de routage, Qualité de Service (QdS), Contrôle de flux, Contrôle de congestion, Systèmes fourmis. 1 Abstract The wireless networks constitute increasingly an emergent technology that offers many advantages such as cost and usability to users. However, they are subject to a multitude of challenges, in particular the nodes mobility, the routing and the problem of limited resources like energy and bandwidth. To satisfy the increasing needs of the resources by avoiding the congestions and the packets losses, new solutions of routing and flow control stand out. Indeed, the solutions which were introduced in the wired environment become inadequate for wireless ad hoc networks. In this thesis, we propose a new solution permitting to answer to these needs. This solution consists first of all on a routing protocol with quality of services. It uses the ants systems for the research of better routes ; those that offer more bandwidth, less delay and more stability. Then, we add to this solution an explicit flow control mechanism to adjust and adapt the transmission rate of the transmitter to the capacities of the links forming the found route. The use of the ants systems is motivated by their intelligence, their capacity of adaptation to the changes of their environment in the research of routes and their aptitude to reduce the traffic of control in the network. Key words : Mobile Ad Hoc networks, Routing Protocol, Quality of Service (QoS), flow Control, Congestion Control, Ants Systems.

Table des matières Résumé 1 Abstract 1 Table des matières 2 Liste des figures 5 Liste des acronymes 6 Introduction générale 9 Organisation de la thèse............................ 11 1 Routage et qualité de services dans les MANETs 12 1.1 Introduction................................... 12 1.2 Protocoles de routage pour les réseaux ad hoc................ 13 1.2.1 Les protocoles proactifs......................... 13 1.2.2 Les protocoles réactifs......................... 15 1.2.3 Les protocoles hybrides......................... 17 1.3 Définition de la qualité de services....................... 19 1.4 Interconnexions et graphes........................... 20 1.5 Métriques de qualité de services........................ 20 1.6 Modèles de qualité de services......................... 22 1.6.1 Modèles de qualité de services pour MANETs............ 23 1.7 Routage avec qualité de services dans les MANETs............. 25 1.8 Conclusion.................................... 29 2

Table des matières 3 2 Contrôle de flux dans les MANETs 32 2.1 Introduction................................... 32 2.2 Contrôle de flux et contrôle de congestion.................. 32 2.3 Classification des techniques de contrôle de flux............... 33 2.4 Le contrôle de flux implicite dans les MANETs................ 35 2.4.1 Description générale du protocole TCP................ 36 2.4.1.1 Fiabilité de transmission de TCP.............. 36 2.4.1.2 Régulation du débit dans TCP............... 36 2.4.2 Les défaillances de TCP dans les réseaux MANETs......... 38 2.4.3 Amélioration des performances TCP dans les MANETs....... 39 2.4.3.1 Propositions utilisant une seule couche........... 39 2.4.3.2 Propositions inter-couches.................. 43 2.5 Protocoles de contrôle de flux alternatifs................... 49 2.6 Conclusion.................................... 52 3 Présentation de la solution 53 3.1 Introduction................................... 53 3.2 Motivations................................... 54 3.3 Les systèmes fourmis (The Ant Systems)................... 55 3.4 Description de la solution........................... 58 3.4.1 Les paramètres de QoS utilisés..................... 59 3.4.1.1 La bande passante...................... 59 3.4.1.2 Le délai............................ 61 3.4.1.3 La stabilité des routes.................... 62 3.4.2 Type et structure des paquets..................... 64 3.4.3 Structure des tables........................... 66 3.5 Description de l algorithme........................... 67 3.6 Comportement de l algorithme au niveau des différents noeuds...... 73 3.6.1 Au niveau du nœud source....................... 73 3.6.2 Au niveau du nœud intermédiaire................... 75 3.6.3 Au niveau du nœud destinataire.................... 75 3.7 Conclusion.................................... 76 4 Simulations et Résultats 77 4.1 Introduction................................... 77

Table des matières 4 4.2 Présentation de Network Simulator...................... 78 4.3 Implémentation de la solution......................... 79 4.4 Environnement de simulations......................... 80 4.5 Les métriques de performance......................... 81 4.6 Simulation : résultats et interprétations.................... 81 4.6.1 Ajustement des paramètres du protocole............... 82 4.6.1.1 Impact de α et β sur le taux de réception de paquets... 82 4.6.1.2 Impact du facteur d évaporation ρ sur le taux de réception de paquets.......................... 83 4.6.1.3 Impact du nombre de fourmis sur le taux de réception de paquets............................ 84 4.6.2 Etude des performances de notre protocole.............. 85 4.6.2.1 Impact du nombre de noeuds sources sur le taux de réception de paquets.......................... 85 4.6.2.2 Impact de la mobilité des noeuds sur l énergie moyenne consommée.......................... 86 4.6.2.3 Effet du temps de pause sur le taux de réception de paquets 87 4.6.2.4 Effet du temps de pause sur le délai de bout en bout... 88 4.7 Conclusion.................................... 90 Conclusion et perspectives 91 Bibliographie 94

Table des figures 1.1 Exemple de graphe associé à un réseau.................... 21 2.1 Classification des mécanismes de contrôle de flux............... 35 2.2 Comportement de la fenêtre de congestion de TCP............. 37 2.3 TCP Split.................................... 46 3.1 Comportement des fourmis lors de la recherche de nourriture........ 56 3.2 Exemple de representation d un MANET avec les trois paramètres de QoS 58 3.3 Le rendement par paquet et dans une fenêtre de 32 paquets........ 61 3.4 Schématisation du mouvement d un noeud.................. 64 3.5 Structure des Forward ants........................... 65 3.6 Structure des Backward ants.......................... 66 3.7 Structure des tables au niveau du noeud v 1.................. 67 3.8 Suppression d un cycle de la liste des nœuds visités............. 69 3.9 Organigramme de recherche de route..................... 71 3.10 Les différentes fonctions de l algorithme au niveau des différents noeuds.. 74 4.1 Variation du taux de réception de paquets en fonction de α et β...... 83 4.2 Variation du taux de réception de paquets en fonction de ρ......... 84 4.3 Effet du nombre de fourmis sur le taux de réception de paquets....... 85 4.4 Impact du nombre de noeuds sources sur le taux de réception de paquets.. 86 4.5 Impact de la mobilité sur l énergie moyenne consommée........... 87 4.6 Simulation de 60 noeuds avec 1m/s vitesse 2m/s............ 88 4.7 Simulation de 60 noeuds avec 3m/s vitesse 10m/s........... 89 4.8 Délai moyen de bout en bout vs Temps de pause............... 90 5

Liste des acronymes 6 Liste des acronymes

Liste des acronymes 7 AODV AWND ADSN ABR ATP ACK ADV BDP BER CBRP CCITT CEDAR CLMCQR CA CWND CWL CTS DSR DSDV DiffServ DS DCF ECN EARA-QoS ELFN EXACT FQMM GAMAN IETF IARP IERP IntServ IP imaq ICMP JOCP LRED LACK MAC MANET MPR NS Ad hoc On Demand Vector Allowed WiNDow ACK Duplication Sequence Number Associativity Based Routing Ad hoc Transport Protocol ACKnowledgment Adaptive Distance Vector Bandwidth Delay Product Bit Error Rate Cluster Based Routing Protocol Comité Consultatif International Télégraphique et Téléphonique Core-Extraction Distributed Ad hoc Routing algorithm Cross Layer Multi-Constraint QoS Routing Congestion Avoidance Congestion WiNDow Congestion Window Limit Clear To Send Dynamic Source Routing Destination Sequenced Distance Vector Differenciated Service Dominating Set Distributed Coordination Function Explicit Congestion Notification Emergent Ad hoc Routing Algorithm with QoS provision Explicit Link Failure Notification EXplicit rate flow ConTrol Flexible Quality of service Model for Manets Genetic Algorithm based routing method for Mobile Ad hoc Networks Internet Engineering Task Force IntrAzone Routing Protocol IntErzone Routing Protocol Integrated Service Intenet Protocol integrated Mobile Ad hoc QoS framework Internet Control Message Protocol Jointly Optimal Congestion-Control and Power Control Link Random Early Detection Local ACK Medium Access Controller Mobile Ad hoc NETwok Multi-Points Relays Network Simulator

Liste des acronymes 8 OLSR OSPF PHB QdS QoS QOLSR RIP RREQ RREP RERR RFC RSVP RLGAMAN RTO RTHC RTS RFN RRN RTT SWAN SAANT SS SSThreshold TCP TC TWND TCPDOOR TPSN TORA TCPF TPA UDP Wi-Fi WXCP XCP ZRP Optimezed Link State Routing Open Shortest Path First Per Hop Behavior Qualité de Service Quality of Service OLSR with Quatity of service Routing Information Protocol Route REQuest Route REPlay Route ERRor Request For Comments Resource ReSerVation Protocol Reinforcement Learning and Gentic Algorithm for MANets Retransmission Time Out Round Trip Hop Count Request To Send Route Failure Notification Route Re-establshment Notification Round Trip Time Service differentiation in Wireless Ad hoc Networks Simulated Annealing and ANT colonny algorithm based qos route for manets Slow Start Slow Start Threshold Transport Control Protocol Topology Control Transmission WiNDow TCP Detection of Out Of Order TCP Packets Sequence Number Temporally Ordered Routing Algorithm TCP Feedback Transpor Protocol for Ad hoc network User Datagram Protocol Wireless Fidelity Wireless explicit Congestion control Protocol explicit Congestion control Protocol Zone Routing Protocol

Introduction générale Depuis que les communications sans fil se sont imposées dans notre vie quotidienne et que les réseaux sans fil ont connu un grand succès, de nouvelles perspectives de ces technologies ne cessent d apparaître. En effet, avec la prolifération de ces réseaux sans fil, l utilisateur peut y accéder et manipuler ses données là où il soit et à tout instant. Donc la transmission d informations peut fort bien s accomplir sans qu il est nécessaire d être devant son ordinateur de bureau. Muni d un laptop doté de la technologie sans fil, il peut y accéder à ses données de l aéroport, de la gare, de la compagne... Comme pour les réseaux sans fil et mobiles, l intégration de tout type d applications dans les réseaux ad hoc suscite de plus en plus un grand intérêt. En effet, les problématiques et les contraintes imposées dans le contexte particulier des réseaux MANETs (Mobile Ad hoc NETworks) sont nombreuses et plus complexes que celles rencontrées dans les réseaux filaires. En effet, plusieurs caractéristiques de ces réseaux comme, la topologie dynamique, la bande passante variable et limitée, les fréquentes déconnexions et la contrainte d énergie ne peuvent être négligées. Pour cela, plusieurs travaux permettant de réduire les effets indésirables résultés par ces dernières ont été proposés. Le domaine de recherche dans les réseaux ad hoc reste toujours fertile et beaucoup de défis restent à relever. Dans le cadre de notre travail, nous nous sommes intéressés aux problèmes de routage et de contrôle de flux. Le routage est une fonction importante et difficile dans ces environnements mobiles. Les premiers protocoles de routage définis pour les MANETs consistent à trouver un chemin entre une source et une destination en se basant seulement sur le plus court chemin. Ces protocoles ne considèrent aucun paramètre de Qualité de Services (QdS ou QoS). Ce- 9

Introduction générale 10 pendant, router sans tenir compte d aucune contrainte que présente les MANETs dégrade considérablement les performances et peut aggraver fortement les congestions. Le contrôle de flux quant à lui vise à adapter le débit de transmission d une source aux capacités des ressources du réseau pour éviter les congestions. Dans les réseaux filaires, TCP (Transport Control Protocol) est le protocole permettant de contrôler le flux. Il est implicite car il se base sur les pertes de paquets pour déterminer un état de congestion dans le réseau. Malheureusement, les MANETs soufrent de beaucoup de pertes de paquets qui ne sont pas forcément dues aux congestions. Pour cela importer directement ce protocole aux réseaux ad hoc s est avéré inadapté. Pour l adapter aux MANETs, plusieurs améliorations ont été proposées [1, 2, 3]. Cependant, le contrôle de flux explicite, qui consiste à informer explicitement la source du débit adéquat reste la meilleure alternative [4, 5, 6]. L objectif de notre travail est la proposition d une solution combinant un protocole de routage avec qualité de services et un mécanisme de contrôle de flux explicite pour éviter les congestions et réduire les pertes de paquets. La majorité des protocoles de routage avec qualité de services proposés ne tient compte que d un seul paramètre comme le délai, la bande passante, ou l énergie...mais d autres considèrent plusieurs paramètres tels que le nombre de sauts et l énergie résiduelle, la bande passante et le délai... Nous, nous proposons un nouveau protocole de routage tenant compte de trois paramètres essentiels de qualité de services : la bande passante, le délai et la stabilité des liens. Le choix des routes offrant plus de bande passante contribue à la réduction des congestions et des pertes de paquets. Le choix du paramètre délai est important pour les applications temps réel. Le choix du dernier paramètre nous offre des routes plus stables. Ce qui réduit les fréquentes déconnexions qui engendrent beaucoup de pertes de paquets. Dans [7, 8], la stabilité (durée de vie) d un lien est calculée en fonction de la direction et de la vitesse des deux nœuds formant ce lien. Ils considèrent que ce lien est toujours maintenu si ces deux nœuds sont à une distance inférieure ou égale au rayon de couverture. Cela, nous parait insuffisant. Il ne suffit pas que deux nœuds soit proches l un de l autre pour dire que le lien entre eux est maintenu. Nous pensons que l énergie des nœuds a une grande influence sur la durée de vie d un lien. Imaginons qu un des deux

Introduction générale 11 nœuds ait épuisé son énergie. Ces deux nœuds ne peuvent communiquer. Pour remédier à cela, nous avons proposé une nouvelle formule de calcul de la durée de vie d un lien. Cette formule tient compte de la direction, de la vitesse et de l énergie des nœuds. Bien que les protocoles de routage avec QoS considérant la bande passante comme paramètre, permettent d offrir des routes plus larges et réduisent ainsi les congestions, ils ne retournent aucune information à la source sur le débit adéquat de transmission. Dans notre travail nous ajoutons au protocole de routage avec QoS le mécanisme de contrôle de flux explicite. Ce dernier permet d informer l émetteur du débit avec lequel il doit transmettre ces paquets. Dans le processus de recherche de routes offrant plus de bande passante, moins de délai et une plus grande stabilité nous avons utilisé les systèmes fourmis qui permettent entre autres la réduction des congestions. En effet, les systèmes fourmis se basent sur une sélection intelligente de routes au lieu de la diffusion qui charge le réseau par les paquets de contrôle. Nous les avons aussi utilisés pour leur grande adaptation aux MANETs. Organisation de la thèse Pour mener à terme cette thèse, nous l avons organisée en quatre principaux chapitres. Les deux premiers chapitres sont consacrés à l état de l art sur les thématiques relatives au travail effectué. Les autres sont réservés à notre solution. Le chapitre 1 présente un ensembles de concepts sur le routage et la qualité de services dans les réseaux mobiles ad hoc (MANETs). Le chapitre 2 donne un état de l art sur le problème de contrôle de flux. Le chapitre 3 présente notre solution qui consiste à combiner un protocole de routage avec qualité de services et un mécanisme de contrôle de flux explicite pour une meilleure réduction des congestions et de pertes de paquets. Enfin le chapitre 4 est consacré au modèle de simulation et à l évaluation des résultats de notre solution.

Chapitre 1 Routage et qualité de services dans les MANETs 1.1 Introduction Le domaine des réseaux ad hoc est très prometteur. Il permet la création spontanée d un réseau sans avoir besoin d aucune infrastructure. Ces réseaux ad hoc sont définis comme étant un ensemble de nœuds autonomes capable de se déplacer et de communiquer librement. Ceci résulte en une topologie dynamique et imprévisible dans le temps. Les communications sont faites via le médium radio où la portée des transmissions est limitée. Le relais est ainsi rendu obligatoire, et les nœuds doivent coopérer pour acheminer les données d une source vers une destination. La recherche d une route entre une source et une destination est assurée par un protocole de routage. Le but principal des protocoles de routage est l établissement et la maintenance des routes pour que les messages (données) soient correctement acheminés dans le réseau. Les caractéristiques des réseaux ad hoc rendent l utilisation des protocoles filaires classiques [9, 10] inadéquate. En effet, ces protocoles se basent sur des topologies statiques. Par contre, les protocoles de routage conçus pour les réseaux ad hoc opèrent dans des réseaux dynamiques dont la topologie change fréquemment et de manière imprévisible. En plus, ils sont soumis à plusieurs contraintes de ressources limitées (énergie, bande passante...) et à la nature du lien sans fil. Pour faire face à toutes les contraintes spécifiques aux réseaux MANETs, de nombreux algorithmes de routage ont été mis en place. 12

Chapitre 1. Routage et QoS dans les MANETs 13 1.2 Protocoles de routage pour les réseaux ad hoc Les protocoles de routage conçus pour les réseaux ad hoc sont classés selon plusieurs critères [11, 12]. Dans cette section, nous les différencions par la méthode utilisée pour découvrir la route entre le nœud source et le nœud destination. Ils s appuient sur trois modèles de fonctionnement : les protocoles proactifs, les protocoles réactifs et les protocoles hybrides. 1.2.1 Les protocoles proactifs Les protocoles de cette classe tentent de maintenir à jour dans chaque noeud les informations de routage concernant tous les autres noeuds du réseau. Ils nécessitent ainsi que chaque noeud maintienne une ou plusieurs tables pour stocker les informations de routage. Pour maintenir la consistance de ces tables, les protocoles propagent les mises à jours des routes à travers le réseau. Le principal intérêt de ce type de protocole est qu un noeud sait directement comment communiquer avec n importe quelle destination ce qui évite des temps de latence lors de l établissement d une communication. Leur inconvénient majeur c est qu ils atteignent rapidement leurs limites avec l accroissement du nombre de noeuds et de leur mobilité. Ainsi les tables deviennent volumineuses et la mobilité cause des changements fréquents de la topologie du réseau. Le réseau sera ainsi constamment inondé par les paquets de contrôle qui ne se propagent pas assez vite pour que chaque noeud soit informé à temps des changements. Il en résulte des incohérences dans les tables, un problème de convergence du réseau et une bande passante réduite par la surcharge des paquets de mise à jour. Ces protocoles sont limités à des réseaux de petites tailles, avec une faible mobilité. Parmi les protocoles de cette classe on peut citer : DSDV : Le protocole Destination Sequenced Distance Vector (DSDV) [13] repose sur l adaptation à l environnement mobile du protocole de routage classique de Bellman Ford utilisé par le protocole Routing Information Protocol (RIP [9]). La principale amélioration apportée par rapport à l algorithme de Bellman Ford est l utilisation de numéros de séquence permettant aux noeuds mobiles de faire la distinction entre

Chapitre 1. Routage et QoS dans les MANETs 14 une nouvelle route et une ancienne. DSDV est un protocole à vecteur de distance ; c est-à-dire chaque noeud mobile maintient une table de routage où chacune des lignes caractérise une des destinations possibles. Cette table contient le nombre de sauts qu il y a entre la source et la destination souhaitée, le noeud mobile voisin qu il faut traverser ainsi que le numéro de séquence qui est affecté à cette route. Lors d un changement de topologie dans le réseau, les tables sont mises à jour et les modifications sont propagées aux autres noeuds du réseau. On peut propager soit la ligne modifiée, soit la table de routage toute entière. Le choix de la méthode dépend du nombre de mises à jour à faire dans la table à un instant donné : si le nombre de modifications est trop important il est préférable de transmettre toute la table de façon à ne pas surcharger le réseau. OLSR : Le protocole Optimized Link State Routing (OLSR) [14] est un protocole à état de lien standardisé par l IETF qui peut être vu comme une adaptation du protocole filaire Open Shortest Path First (OSPF) [10] aux réseaux sans fil. Afin de maintenir à jour les tables de routage, chaque noeud implémentant OLSR diffuse régulièrement des informations sur son propre voisinage. Ces informations sont suffisantes pour permettre à chaque noeud de reconstruire une image du réseau et de trouver une route vers n importe quelle destination. Mais contrairement à d autres protocoles comme OSPF, dans OLSR cette diffusion ne se fait pas par une simple inondation ; Mais il optimise la diffusion grâce au système des relais multi-points (Multi-Points Relays : MPR). Chaque noeud choisit dans ses voisins directs un sousensemble minimal de noeuds qui lui permettent d atteindre tous ses voisins à deux sauts (l ensemble des MPRs). La diffusion des informations sur les liens utilisés pour le routage se fait ensuite uniquement par les relais multi-points ; la couverture totale du réseau est assurée tout en limitant sensiblement le nombre de ré-émissions. Afin de choisir ses relais multipoints, un noeud a besoin de connaître complètement la topologie de son voisinage à deux sauts. Cela est réalisé grâce à l envoi périodique de paquets Hello contenant la liste des voisins connus à un saut. Cette technique prometteuse réduit considérablement l overhead généré par le trafic de contrôle.

Chapitre 1. Routage et QoS dans les MANETs 15 1.2.2 Les protocoles réactifs L approche utilisée dans cette classe est totalement différente de celle des protocoles proactifs. En effet, une route n est établie qu à la demande du noeud source. Quand un noeud veut initier une communication avec un autre noeud, il lance un processus de découverte de route (Route Discovery). Une fois la route trouvée, elle est maintenue par une procédure de maintenance de route, jusqu à ce qu elle ne soit plus utilisée ou que le destinataire ne soit plus joignable. Cette approche offre une nette amélioration dans cette famille quant à la surcharge du réseau et à la consommation d énergie. Les routes ne sont créées et maintenues que lorsqu elles sont demandées et le processus d inondation est ponctuel, il n a lieu que lors de l initialisation de la route. Les incohérences dans les tables sont beaucoup réduites car les mises à jour des informations de routage se font localement, restreintes aux voisins directs et non plus propagées dans tout le réseau par des sources distinctes. L inconvénient des protocoles de cette classe c est qu ils engendrent un délai pour l établissement d une route avant de pouvoir émettre les paquets de données. On notera également qu il faudra une inondation du réseau pour s apercevoir qu un destinataire n est pas joignable. Cette famille de protocoles convient mieux pour des scénarii à forte mobilité, où les communications entre noeuds sont plus ponctuelles et ne nécessitant pas une connexion permanente avec tous les noeuds du réseau. Parmi les protocoles de cette classe on cite : DSR : Le protocole DSR (Dynamic Source Routing) [15] est basé sur le principe de diffusion à la demande pour calculer une route vers une destination. Il utilise la technique routage par la source. Dans cette technique la source des données détermine la séquence complète des noeuds à travers lesquelles, les paquets de données seront envoyés. DSR se base principalement sur deux mécanismes : la découverte de route et la maintenance de route. Il permet aussi l existence de plusieurs routes vers la destination. A partir des informations de routage qui sont incluses dans les paquets de données comme les noeuds appartenant à la route, leurs noeuds voisins peuvent les collecter et les mettre dans leurs caches pour une utilisation ultérieure. Chaque noeud

Chapitre 1. Routage et QoS dans les MANETs 16 dans le réseau envoyant ou relayant un paquet doit confirmer son acheminement vers le prochain noeud en recevant un acquittement. Si un noeud détecte une rupture de route, un message d erreur de route est retourné à la source. Lors de la réception d un message d erreur de route, la source supprime la route défaillante de son cache. Si un chemin alternatif est disponible, il peut être employé pour acheminer les données restantes vers la destination, autrement, une nouvelle découverte de route est lancée. AODV : le protocole AODV (Ad hoc On Demand Vector) [16] est aussi un algorithme de routage à la demande ; il ne construit de routes entre noeuds que lorsqu elles sont demandées par les noeuds sources, et ce pour réduire le nombre de diffusions de messages. AODV met en oeuvre différentes opérations pour réaliser et maintenir le routage : gestion de la connectivité locale, phase de découverte des routes et maintenance des routes. La gestion de la connectivité locale est assurée par tous les noeuds du réseau. Chaque noeud émet périodiquement un paquet, nommé Hello. A la réception de ce paquet, les noeuds apprennent la présence de noeuds voisins. La connectivité locale est modifiée dans les cas suivants : Un noeud reçoit un paquet Hello transmis par un nouveau voisin Un noeud ne reçoit plus de paquets Hello durant un laps de temps défini. La phase de découverte des routes : à la réception d un paquet de données par la source, elle vérifie dans sa table de routage si une route existe jusqu à la destination. Si elle existe, le paquet est transmis vers le prochain noeud sinon le paquet est mis en file d attente et la phase de découverte des routes est déclenchée. Dans cette phase, la source diffuse une requête de création de routes, nommée RREQ. A la réception d un paquet RREQ, un noeud met à jour la route inverse en direction de la source. Ensuite, ce noeud vérifie s il connaît une route vers la destination. S il en possède une, il envoie une requête de réponse nommée RREP en direction de la source. Sinon, il diffuse la requête RREQ à ses voisins. Lorsque le paquet RREP transite vers la source, chaque noeud sur le chemin inverse met à jour sa table de routage avec, comme prochain noeud, l adresse du noeud qui a émis RREP. Le temporisateur de

Chapitre 1. Routage et QoS dans les MANETs 17 cette entrée dans la table de routage est mis à jour. Ce temporisateur indique qu une route est toujours active s il est non nul. Pour chaque destination donnée, un noeud maintient une unique entrée dans sa table de routage qui contient les champs suivants : Adresse de la destination, Numéro de séquence de la destination, Prochain noeud sur le chemin vers la destination, Nombre de sauts et d autres paramètres relatifs à la route. L utilisation du numéro de séquence permet de dater la route et d éviter la présence de boucles. Si deux routes existent entre un noeud et une destination, le noeud conserve la route la plus récente (plus fraîche). Si les deux routes sont découvertes simultanément, la route avec le plus faible nombre de sauts est conservée. La phase de maintenance des routes est réalisée en deux étapes. La première étape consiste en la détection de la perte d une route. Quand un noeud sur un chemin établi se déplace, les routes passant par ce noeud peuvent être rompues. Les noeuds en amont, détectant la perte de connectivité, préviennent les sources affectées en émettant une requête d erreur, notée RERR. A la réception de ce paquet, le noeud source engage la deuxième étape de la maintenance des routes. Il entame ensuite, une nouvelle phase de découverte des routes si un chemin est toujours nécessaire. 1.2.3 Les protocoles hybrides La combinaison des approches réactives et proactives constitue les protocoles de routage hybrides. Le principe est qu une approche proactive est utilisée dans un certain périmètre autour de la source (jusqu à trois ou quatre sauts par exemple) et une approche réactive est utilisée pour les noeuds les plus éloignés (à l extérieur de la zone définie pour le proactif). On cite à titre d exemple : CBRP : Le protocole CBRP (Cluster Based Routing Protocol) [17] utilise un mécanisme de routage hiérarchique à deux niveaux. Il définit la notion de cluster de nœuds : c est un groupe de nœuds formé de membres et d un chef de cluster (clusterhead), chaque

Chapitre 1. Routage et QoS dans les MANETs 18 membre du cluster étant à portée radio directe du clusterhead. Les clusterheads doivent maintenir une connectivité entre eux, ce qui assure la connectivité de tout le réseau. Les nœuds du réseau passe par les clusterheads pour la transmission de leurs données à travers le réseau. ZRP : Le protocole ZRP (Zone Routing Protocol)[18] spécifie une zone de routage autour de chaque nœud avec un certain nombre de sauts. A l intérieur de cette zone, les protocoles proactifs sont utilisés pour acheminer les paquets. Mais, en dehors de cette zone se sont les protocoles réactifs qui sont employés. Pour cela, il est basé sur deux procédures : IARP (IntrAzone Routing Protocol) et IERP (IntErzone Routing Protocol). En se basant sur ZRP beaucoup d autres protocoles hybrides ont été proposés [19, 20, 21] Le routage qui consiste à déterminer par quels nœuds faire transiter les données, est considéré comme une des difficultés des réseaux ad hoc. De nombreux autres protocoles de routage ont été développés pour ces réseaux [22, 23]. Néanmoins, la plupart de ces protocoles se base sur un critère qui est la minimisation du nombre de sauts entre la source et la destination et ne tiennent pas compte de la Qualité de Services (QdS). La qualité de services est très importante dans les réseaux ad hoc, car elle peut en améliorer le rendement et permettre à l information essentielle de circuler malgré des conditions difficiles. Pour mettre en place de la qualité de services dans les réseaux ad hoc, le calcul des routes doit se baser sur d autres critères que le nombre de sauts. Plusieurs métriques peuvent être considérées, seules ou combinées : comme le délai, la bande passante, l énergie, la connectivité... Dans ce qui suit, avant de présenter quelques protocoles de routage avec qualité de services, nous définirons d abord la notion de qualité de services et nous donnerons quelques concepts relatifs à cette notion.

Chapitre 1. Routage et QoS dans les MANETs 19 1.3 Définition de la qualité de services La Qualité de Services (QoS) est une notion très utilisée dans le domaine des réseaux que ce soit filaire ou sans fil, mais elle n a pas une définition précise. Elle est définie dans [24] comme le degré de satisfaction d un utilisateur des services fournis par le réseau. Dans [25] la QoS est définie comme la capacité d un élément du réseau (ex : routeur, nœud ou une application) de fournir un niveau de garantie pour un acheminement des données. Dans [26], le RFC 2386 caractérise la qualité de services comme étant un ensemble de besoins à assurer par le réseau pour le transport d un trafic d une source à une destination. Ces besoins peuvent être traduits par des paramètres mesurables tels que : Délai de bout en bout. Variation de délai (gigue) Bande passante. Pertes de paquets. Dans les recommandations E.800, le CCITT (Comité Consultatif International Télégraphique et Téléphonique) a défini la QoS comme un ensemble des effets portant sur les performances d un service de communication et qui détermine le degré de satisfaction d un utilisateur de ce même service. Les besoins en QoS diffèrent selon le type de l application. Par exemple, pour les applications temps réel, comme la voix et la vidéo, le délai de bout en bout d un paquet doit être limité, autrement le paquet est inutile. Les applications non temps réel, comme le transfert de fichier ou la messagerie, quant à elles, se focalisent sur la fiabilité des communications. Avec l émergence des services multimédia temps réel, et les champs variés des applications des réseaux ad hoc, la qualité de services dans ces réseaux est devenue un domaine de recherche qui a suscité beaucoup d intérêts. Dans ce contexte, beaucoup de travaux pour l introduction de la QoS dans les réseaux ad hoc ont été proposés. Cependant, il est très difficile de garantir une quelconque qualité de services dans un réseau ad hoc, car il faut prendre en considération les spécificités de ces réseaux, à savoir : la bande passante limitée, l instabilité des liens, le changement dynamique de la topologie, la source d énergie

Chapitre 1. Routage et QoS dans les MANETs 20 limitée, ainsi que le manque d informations sur l état du réseau. En outre, la communication entre les nœuds mobiles étant par voix radio, la qualité du lien sans fil reste peu fiable et susceptible à des variations suivant la configuration et l état du réseau. 1.4 Interconnexions et graphes L interconnexion de réseau peut être représentée par un graphe, dont les arêtes sont les liaisons et les noeuds sont les équipements (stations et/ou routeurs). Les liaisons sont affectées d une ou plusieurs fonctions de poids positives. Ces poids pourront représenter les métriques de la QoS, comme le délai de transmission des données sur la liaison, le débit, le coût, etc... Les poids de ces liaisons sont exploités pour déterminer la meilleure route entre deux noeuds quelconques du graphe (la source et la destination). Un réseau MANET peut être modélisé par un graphe G(V, E) où V représente l ensemble des noeuds du réseau et E l ensemble des arcs liant deux noeuds entre eux. Chaque arc < u, v > est muni d un poids noté w(< u, v >) exprimé à l aide d une ou plusieurs métriques de QoS. Le poids w(< u, v >) est un vecteur de n composantes (n est le nombre de métriques de QoS) : w(< u, v >) = [w 1 (< u, v >), w 2 (< u, v >),..., w n (< u, v >)]. Soit l exemple de la (Fig. 1.1) illustrant la représentation d un graphe associé à un réseau avec deux métriques de QoS : le délai et la bande passante. Donc, sur chaque lien sont représentées la valeur du délai et celle de la bande passante. Le protocole de routage doit déterminer au moins une route entre les noeuds S et D. Sur ce réseau, il y a plusieurs routes entre S et D. Mais, une seule (la route S, A, B, D) sera choisie comme meilleure ou garantissant les contraintes posée par l application sur le délai et la bande passante. 1.5 Métriques de qualité de services Les métriques de routage [27] sont la représentation des liens d un réseau, elles ont une implication majeure non seulement sur la complexité des chemins à trouver, mais également sur la portée des conditions de QoS qui peuvent être supportées. Pour représenter la qualité d un chemin, l algorithme de routage calcule le poids de la

Chapitre 1. Routage et QoS dans les MANETs 21 Fig. 1.1 Exemple de graphe associé à un réseau métrique du chemin chaque fois qu un lien lui est ajouté. La façon de calculer ce poids diffère selon le type de la métrique qui est employée. Les métriques de QoS peuvent être additives, concaves ou multiplicatives [27, 28]. Soit f(u, v) l une des métriques associées à l arc (u, v). La valeur f de cette métrique sur un chemin R = (v 0, v 1,..., v k ) peut alors suivre une des règles de composition suivantes : Métrique additive : une métrique f est dite additive si : f(r) = k f(v i 1, v i ) (1.1) i=1 Le délai, la gigue, le nombre de sauts ainsi que le coût sont des exemples de métriques additives. Métrique multiplicatives : une métrique f est dite multiplicative si : f(r) = k f(v i 1, v i ) (1.2) i=1

Chapitre 1. Routage et QoS dans les MANETs 22 La probabilité de transmission avec succès (Stp) est une métrique multiplicative, par contre la probabilité de perte (Ltp) est un peu plus complexe à qualifier. Cette dernière est souvent transformée en une métrique multiplicative équivalente comme suit : Ltp(p) = 1 Stp(p) (1.3) k = 1 Stp(v i 1, v i ) (1.4) i=1 k = 1 (1 Ltp(v i 1, v i )) (1.5) Métrique concave : Mathématiquement, une fonction f est dite concave sur un intervalle I, si pour toute paire de points sur le graphe de f(x), le segment de droite qui relie ces deux points passe en dessous de la courbe de f(x). Dans le contexte des graphes pondérés, une métrique f est concave si : f(r) = min{f(v i 1, v i ), i = 1, 2,..., k} (1.6) i=1 La bande passante est un exemple typique des métriques concaves, en fait, la bande passante du lien le moins performant qui est attribuée au chemin tout entier. On peut aussi classer la durée de vie d une route comme étant une métrique concave. 1.6 Modèles de qualité de services Deux approches majeures se sont distinguées. Les architectures à intégration de services (IntServ) et les architectures à différenciation de services (DiffServ). Ces deux architectures emploient des stratégies différentes. L intégration de services (IntServ) [29] définie par l IETF vise à garantir une qualité de services aux applications la demandant. L IntServ vise à assurer une QoS individuellement à chaque flot indépendamment de l application à laquelle appartient ce flot. Cette architecture permet aux applications de spécifier leurs demandes en ressources. Pour la garantie de la QoS, cette architecture utilise la réservation de ressources. Le protocole de

Chapitre 1. Routage et QoS dans les MANETs 23 réservation le plus utilisé est le RSVP (Ressource ReSerVation Protocol) [30]. Ce protocole permet aux terminaux de signaler explicitement au réseau leurs demandes en ressources. Il permet également aux routeurs d échanger les informations de demande en ressources en vu d établir un chemin entre l émetteur et le récepteur avec la qualité de services requise. L intégration de services pose des contraintes lourdes notamment l obligation de maintenir des informations pour chaque session individuelle. De plus, le protocole RSVP est complexe et nécessite d être implémenté sur tous les noeuds (routeurs) intermédiaires. La différenciation de services (DiffServ) [31, 32] proposée aussi par l IETF utilise un modèle plus pratique dans lequel les paquets sont répartis en classes. Le nombre de ces classes est relativement restreint (trois ou quatre classes en général) et sont gérées par la couche réseau du noeud émetteur. Les informations de réservation sont maintenues uniquement au niveau de la couche réseau pour tous les flux et non dans les routeurs intermédiaires. Contrairement à IntServ, DiffServ n utilise aucun protocole de signalisation entre les noeuds intermédiaires. Ces deux modèles IntServ et DiffServ sont peu adaptés aux réseaux ad hoc ; IntServ requiert un grand volume de traitements et la signalisation RSVP est trop volumineuse par rapport à la bande passante limitée offerte par les réseaux ad hoc. De plus le processus de maintenance de routes devient moins performant vu le caractère dynamique de ce type de réseaux. D autre part, DiffServ a été proposé pour des réseaux à topologie relativement statique, avec un coeur disposant d une bande passante importante. Pour tenir compte des caractéristiques des MANETs, des modèles spécifiques à ces réseaux ont été proposés. 1.6.1 Modèles de qualité de services pour MANETs FQMM(Flexible Quality of service Model for Manets) : Le modèle FQMM fut le premier modèle de qualité de services proposé pour les réseaux ad hoc. FQMM [33] repose sur une architecture réseau plate (non hiérarchique), constituée d une cinquantaine de noeuds mobiles, formant un domaine DiffServ. Il combine les propriétés des modèles filaires IntServ et DiffServ, en offrant une méthode d approvisionnement hybride : par flux, pour les trafics prioritaires, et par classe pour les autres trafics. Dans

Chapitre 1. Routage et QoS dans les MANETs 24 le réseau, les noeuds peuvent avoir des rôles différents suivant les trafics existants : noeud d entrée du trafic, intermédiaire ou de sortie. Les noeuds d entrée permettent de marquer et de classifier les paquets, qui seront ensuite relayés par les noeuds intermédiaires suivant leurs PHB (Per Hop Behavior) [34], jusqu à arriver au noeud destinataire. Ce modèle repose essentiellement sur la couche IP, où les fonctionnalités sont séparées en deux grands plans [35] : le plan relais de données et le plan contrôle et gestion. Dans ce modèle, le protocole de routage est supposé fournir des routes ayant suffisamment de ressources. L avantage d une telle approche est la possibilité d interfacer le réseau avec l Internet, vu les mécanismes de qualité de services offerts qui sont proches des protocoles filaires. Cependant, plusieurs mécanismes ainsi que l interaction avec la couche MAC restent à définir pour s adapter aux conditions variables du réseau ad hoc. SWAN(Service differenciation in Wireless Ad hoc Networks) : SWAN [36] est un modèle réseau basé sur des algorithmes de contrôle distribués dans le but d assurer une différenciation de services dans les réseaux ad hoc. Il offre la priorité (au niveau paquet) aux trafics temps réel en contrôlant la quantité de trafics aux mieux (best effort) acceptée par noeud. Pour accepter un nouveau trafic temps réel, le contrôle d admission sonde la bande passante minimale disponible sur la route (valide et obtenue par un protocole de routage). Une décision à la source est alors prise suivant la bande passante obtenue. Pour maintenir la qualité de services des trafics déjà acceptés, le débit des trafics best effort est régulé en utilisant les mesures de délais au niveau MAC comme paramètre. En cas de congestion, les bits ECN (Explicit Congestion Notification) de l entête des paquets IP sont positionnés pour permettre à la source de re-initier le contrôle d admission. Si la route ne dispose pas d assez de bande passante, le trafic est supprimé. Un flux prioritaire admis n est pas sûr d avoir des garanties pour l entière durée de la communication, et peut à tout moment être violé par d autres demandes de trafics. Un mécanisme de contrôle de débit des flux best effort n est pas à lui seul suffisant pour offrir des garanties aux applications temps réel. En outre, dans cette approche,

Chapitre 1. Routage et QoS dans les MANETs 25 le protocole de routage ainsi que la couche d accès au médium sont de type best effort. Modèle imaq (integrated Mobile Ad hoc QoS framework) : Le modèle imaq [37] fournit le support des transmissions de données multimédia dans un MANET. Le modèle inclut une couche ad hoc de routage et une couche de services logiciel (Middleware). Dans chaque noeud, ces deux couches partagent les informations et communiquent afin de fournir les garanties de QoS aux trafics multimédia. Le protocole de routage est basé sur la prédiction de la position des noeuds (predictive locationbased) et orienté QoS. La couche Middleware communique également avec la couche application et la couche réseau et essaie de prévoir le partitionnement du réseau. Pour fournir une meilleure accessibilité aux données, elle duplique les données entre les différents groupes du réseau avant d effectuer le partitionnement. 1.7 Routage avec qualité de services dans les MA- NETs Le routage avec QoS est un élément clé pour réaliser une architecture de QoS pour les MANETs. Un protocole de routage peut bien tenir compte des conditions QoS du réseau. Généralement, dans un réseau le routage permet d établir une route de plus court chemin en terme de distance ou de délai entre deux noeuds source et destination. Dans le cadre d une qualité de services, le but du protocole de routage est de trouver la meilleure route selon les critères précis de la qualité de services souhaitée (délai, taux de perte, quantité de bande passante, stabilité des liens...). Intégrer une QoS dans un protocole de routage est à la fois important et difficile à assurer dans le cas des réseaux ad hoc, en raison de leur topologie dynamique et de leurs ressources limitées. En effet, un protocole de routage ad hoc permettant la QoS doit pouvoir réagir très rapidement aux changements de ces topologies et aux ressources limitées sans que les applications ne soient atteintes. Le but de ce type de protocole est donc de trouver une route dans le réseau qui puisse satisfaire de bout en bout les besoins en QoS demandés par une application. C est une alliance

Chapitre 1. Routage et QoS dans les MANETs 26 entre un protocole de routage classique et un mécanisme de gestion des ressources. Ces caractéristiques inhérentes aux réseaux MANETs rendent le maintien et le calcul de l état précis des liens très difficile et très coûteux. De plus, la mobilité ou le manque d énergie peuvent causer des ruptures dans les chemins établis, le manque de la bande passante peut causer de sérieuses congestions du réseau. Pour pallier à ces problèmes le protocole de routage avec QoS doit être capable de réagir très vite en recalculant de nouvelles routes. Un état de l art sur les protocoles de routage avec QoS dans les MANETs a été donné dans [38]. Dans la section ci-dessous, nous citerons quelques uns de ces protocoles : Plusieurs extensions en qualité de services ont été proposées pour AODV [39, 40]. Dans [39] l extension en QoS d AODV repose sur l ajout de champs aux paquets RREQ (Route REQuest) et RREP (Route REPlay). Ces champs sont associés aux paramètres : bande passante et délai. Chaque nœud recevant RREQ, vérifie s il est en mesure de satisfaire cette demande en service, avant d acheminer ce paquet. S il détecte que cette QoS n est pas satisfaite, il informe la source par l envoi de RREP. Après l établissement d une route, si un noeud intermédiaire ne peut pas maintenir la demande de QoS exigée, un message ICMP QoS-LOST sera initié et envoyé vers la source. La table de routage de chaque nœud est aussi étendue par ces informations : Bande passante minimale, délai maximum et la liste des nœuds ayant demandé le service. Dans [40] le paramètre de qualité de services utilisé est la bande passante.donc, si une route satisfaisant la quantité de bande passante demandée est retrouvée, les données seront envoyées sinon un nouveau processus de route sera déclenché. QOLSR [41, 42] étend le protocole OLSR par la QoS. Il utilise aussi le délai et la bande passante comme paramètres de la qualité de services. Ces informations de qualité de services (bande passante et délai) sur les liens sont ajoutées aux paquets de contrôle TC (Topology Control). A l aide de ces informations, les nœuds calculent les routes ayant la meilleure qualité de services. Le but de se protocole n est pas de trouver des routes admissibles, mais de choisir parmi les routes disponibles celle offrant la meilleure qualité. Le protocole CEDAR (Core-Extraction Distributed Ad hoc Routing algorithm) [43] est un protocole de routage réactif avec qualité de services réagissant au dynamisme des

Chapitre 1. Routage et QoS dans les MANETs 27 MANETs. Il est basé sur une élection dynamique d un coeur de réseau. Des informations sur les liens disposant d une grande bande passante sont propagées entre les noeuds du coeur. Ces derniers forment l ensemble dominant ou le Dominating Set (DS). Deux cas peuvent se présenter pour chaque noeud du réseau : 1) il fait partie de DS, c est donc un noeud du coeur ; 2) l un de ses voisins fait partie du DS. Les noeuds du DS sont les représentants de leurs zones. Chaque noeud n appartenant pas au DS dépend d un noeud de DS. Un chemin entre deux noeuds du coeur est appelé lien virtuel. L un des objectifs principaux de ce protocole est de limiter au maximum l inondation du réseau pour la découverte de route. CEDAR est divisé en trois composants : extraction d un coeur du réseau, propagation d état de lien et calcul de route : Extraction d un coeur du réseau : un ensemble de noeuds est dynamiquement choisi pour calculer les routes et maintenir l état des liens du réseau. L avantage d une telle approche est qu avec un ensemble réduit de noeuds les échanges d informations d état et de route seront minimisés, évitant ainsi des messages supplémentaires circulant dans le réseau. Ce qui permet la réduction dans la consommation des ressources rares. Propagation d état de lien : le routage avec qualité de services est réalisé grâce à la propagation des informations sur les liens avec une grande bande passante. L objectif est d informer les noeuds distants sur les liens de grande capacité, alors que les liens de faible capacité reste connus au niveau local (les noeuds n ont pas une information sur la topologie globale du réseau). Calcul de route : celui-ci est basé sur la découverte et l établissement d un plus court chemin vers la destination satisfaisant la bande passante demandée. Ticket-Based QoS Routing [44] est un protocole de routage distribué. Il permet de réduire la quantité de messages de routage diffusés pour la découverte de la route, en publiant un certain nombre de tickets logiques. Chaque message de découverte (ou d observation) de route doit avoir au moins un ticket. Quand un message arrive à un noeud, il peut être divisé en plusieurs messages d observation, qui sont relayés vers les prochains sauts. Chaque message fils contiendra un sous ensemble de tickets de son message père.

Chapitre 1. Routage et QoS dans les MANETs 28 Évidemment, un message ayant un seul ticket ne peut être divisé. Lors de l arrivée d un message de découverte de route à la destination, le chemin saut par saut est connu et les informations de délai ou de bande passante peuvent être utilisées pour effectuer la réservation de ressources pour la route répondant aux besoins de QoS. Le nombre de tickets générés est fonction de la précision des informations d états disponibles à la source et les besoins de QoS de la communication. Plus de tickets sont publiés dans le but d augmenter la chance de trouver un chemin désiré. Dans les réseaux filaires, une distribution de probabilité, selon des informations sur le délai ou la bande passante, peut être calculée. Cependant, cela reste inapproprié dans les réseaux ad hoc où les liens sans fil sont sujets à des cassures, où les informations d états sont imprécises. Pour cela, un modèle simple a été proposé pour l algorithme Ticket Based. Il utilise l historique et l estimation des variations du délai, et une formule de lissage pour calculer le délai courant. Pour s adapter aux changements de topologie, l algorithme autorise différents niveaux de redondance de route. Il utilise aussi des techniques de réparation et de reroutage pour la maintenance des routes. La réparation des routes se fait en utilisant des reconstructions locales. Dans [8], contrairement aux protocoles précédents qui ne cherchent qu une seule route de la source à la destination, les auteurs ont proposé un protocole cherchant plusieurs routes. Les données à transmettre de la source vers la destination sont fragmentées de façon à exploiter chacun de ces liens. Leur but était de réduire les congestions et le délai de bout en bout. Ce protocole se base sur la stabilité des liens (durée de vie des liens) pour anticiper la recherche d une route avant son expiration. Le protocole GAMAN (Genetic Algorithm based routing method for Mobile Ad-hoc Networks) [45] utilise l algorithme génétique pour rechercher des routes. Cet algorithme utilise une fonction objective exprimée en fonction de deux paramètres : le délai (le temps de transmission d un paquet d un nœud vers un autre) et le taux de transmission avec succès de paquets. L algorithme génétique suit un cycle composé des opérations suivantes : génération d une population, évaluation des performances, sélection des individus et l application d opérations génétiques (croisement et mutation). Un tel algorithme converge rapidement vers une route optimale dans un environnement peu peuplé mais devient peu

Chapitre 1. Routage et QoS dans les MANETs 29 efficace dans de larges réseaux. Dans [46] et [47], Fu peng et Zhang deyun ont proposé deux protocoles de routage à QoS utilisant une combinaison d heuristiques. Dans [46], le protocole SAANT est basé sur un algorithme fourmis et un algorithme de recuit simulé. Le premier s exécute sur tous les nœuds mobiles et consiste en la recherche de routes à QoS. Le deuxième s exécute seulement sur le nœud source et utilise les solutions trouvées par le premier pour trouver la meilleure route possible. Ce protocole utilise quatre paramètres de qualité de services : le délai de transmission, la bande passante, le coût et le taux de perte de paquets. Dans [47], le protocole RLGAMAN utilise en premier lieu l heuristique de Reinforcement Learning pour trouver un ensemble de routes admissibles auxquelles il applique un algorithme génétique pour se rapprocher le mieux possible de la solution optimale. Dans cet algorithme deux paramètres de QoS sont considérés : le délai et la bande passante. EARA-QoS (Emergent Ad hoc Routing Algorithm with QoS provision) [48] est un autre protocole à QoS utilisant le système fourmis pour la recherche de routes. Ce protocole est un protocole à la demande et mutltichemins. Le protocole CLMCQR (Cross Layer Multi-Constraint QoS Routing) [49] propose à partir d une vue du réseau de déterminer les chemins respectant des contraintes de bande passante, de délai et de fiabilité. Pour cela, un algorithme est appliqué au réseau avec une fonction poids intégrant ces trois paramètres. Les liens du réseau ayant une bande passante disponible inférieure à la bande passante requise sont retirés du réseau (donc ils ne sont pas considérés lors du calcul d une route). La fiabilité d un lien est transformée en métrique additive puis combinée au délai. La combinaison de ces deux métriques permet la sélection du chemin. 1.8 Conclusion Les réseaux MANETs permettent aux utilisateurs d accéder et de manipuler des informations à travers des unités mobiles indépendamment de leur localisation. Cependant, vu leurs contraintes, de très nombreux défis restent à relever tels que : le problème d accès au

Chapitre 1. Routage et QoS dans les MANETs 30 médium, problème de routage, problème de congestion... Le routage est le domaine de recherche qui a reçu, et reçoit toujours, le plus d attentions de la part de la communauté des chercheurs dans les réseaux MANETs. Une multitude de protocoles (proactifs, réactifs ou hybrides) ont été déjà proposés. De par la nature variable du médium, la mobilité des nœuds et la limitation de ressources de ces réseaux, les protocoles de routage best effort (routage au mieux), actuellement mis en place dans les MANETs, ne sont pas suffisants pour garantir une certaine qualité de services (QoS) aux utilisateurs. Pour y remédier, l introduction de la qualité de services aux protocoles de routage a été plus que nécessaire, bien que, la gestion de la qualité de services dans les réseaux MANETs, ne soit pas chose aisée. Ces protocoles de routage aux mieux doivent alors évoluer et prendre en compte les contraintes imposées par les applications. Les protocoles de routage à QoS ont ainsi fait leur apparition dans les réseaux MANETs prenant en compte de nombreuses contraintes de QoS tels que le délai, la bande passante, la fiabilité, l économie d énergie, la stabilité... Certains protocoles de routage avec qualité de services utilisent des heuristiques dans leurs développements. Le recours à ces heuristiques est exprimé pour deux raisons. En premier lieu, pour réduire la complexité de routage car des études ont montré que trouver une route optimale qui tient compte de deux métriques ou plus, représente un problème NP-complet [26, 27, 50]. En second lieu, pour la capacité de certaines heuristiques à réduire le taux de trafic de contrôle qui a un impact négatif sur les performances du réseau. Bien que beaucoup d efforts soient fournis pour améliorer la performance des MANETs en améliorant les protocoles de routage, ces réseaux soufrent toujours d autres problèmes ayant également une grande influence sur leur performance, tels que le problème de congestion ou de contrôle de flux. Dans notre travail, nous proposons un nouveau protocole de routage tenant compte d un certain nombre de paramètres de QoS dont l objectif est de réduire les pertes de paquets et les congestions. A ce protocole, nous intégrons un mécanisme de contrôle de flux pour mieux raffiner notre solution. Ce mécanisme consiste à adapter le débit de transmission de la source aux capacités des ressources disponibles dans le réseau. Avant de décrire la

Chapitre 1. Routage et QoS dans les MANETs 31 solution proposée, le chapitre suivant donnera un état de l art sur le problème de contrôle de flux.

Chapitre 2 Contrôle de flux dans les MANETs 2.1 Introduction Les réseaux MANETs enregistrent de plus en plus un nombre important d utilisateurs. Le succès de ces réseaux est, essentiellement, dû au grand intérêt et à l attention particulière de la part des particuliers, des entreprises et du milieu industriels. Par conséquent, cette croissance en nombre d utilisateurs sature et congestionne ces réseaux caractérisés par des ressources limitées. De ce fait, la mise en place de protocoles de contrôle de flux est plus que nécessaire afin de permettre une meilleure utilisation des ressources, tout en évitant les congestions. Le contrôle de flux est donc une stratégie importante que nous ne pouvons pas éviter pour la transmission d informations dans n importe quel type de réseau (filaires ou sans fil). Il permet une utilisation efficace de la bande passante disponible sans causer de contention. Bien que le problème de contrôle de flux ait été adressé avec succès dans les réseaux filaires où TCP est le protocole garantissant un réseau non congestionné, il reste encore un domaine ouvert à explorer dans les réseaux sans fil. 2.2 Contrôle de flux et contrôle de congestion Pour toute communication sur un réseau se posera le problème de l adaptation du débit des données issues de la source aux contraintes de capacités de traitement des récepteurs. Le contrôle de flux vise à mettre en correspondance le débit des informations transmises 32

Chapitre 2. Contrôle de flux dans les MANETs 33 à un récepteur aux capacités de réception de ce dernier. Lorsque l agrégation des trafics transitant dans un point du réseau excède les capacités de traitement des routeurs, des phénomènes de congestion se produisent. Ceci aboutit à la saturation du réseau puis à la perte de paquets de données. Le contrôle de congestion a pour but de réguler la source afin d éviter ces phénomènes de congestion. Le principe sur lequel repose ces mécanismes de contrôle est un processus adaptatif de rétroaction entre une source de données et un récepteur, qui permet de réguler le débit d émission. En d autres termes, Le contrôle de flux est défini comme étant l ensemble des actions entreprises par le réseau pour éviter les congestions et le contrôle de congestion quant à lui est défini comme étant l ensemble des actions entreprises par le réseau pour minimiser l intensité, l expansion et la durée de la congestion. Le contrôle de flux est aussi considéré comme une fonction de contrôle de congestion. C est à dire qu une mauvaise régulation du flux émis va provoquer une congestion sur le chemin de la connexion. En effet, si la source émet plus vite que le récepteur ne reçoit, les paquets vont s accumuler dans le réseau, d abord dans le noeud de sortie, puis dans le précédent, etc. La terminologie entre ces deux types de contrôle n est pas du tout fixée. C est que, en réalité, ces deux contrôles font appel à des outils assez semblables. En toute rigueur, le terme de contrôle de flux désigne les mécanismes par lesquels le récepteur régule le flux de l émetteur, alors que le contrôle de congestion fait référence aux actions du réseau sur la source. La distinction contrôle de flux / contrôle de congestion est souvent omise. 2.3 Classification des techniques de contrôle de flux Les techniques de contrôle de flux peuvent être classées selon plusieurs critères [6, 51]. Dans [51] la classification est faite selon trois techniques : Explicite/implicite : on distingue les techniques de rétroaction (feedback) explicite et les techniques de feedback implicite. Dans les premières techniques, les éléments du réseau utilisent des messages de contrôle explicite pour informer l émetteur de l état

Chapitre 2. Contrôle de flux dans les MANETs 34 de congestion du réseau. Elles permettent de contrôler les sources de façon précise car la source a de meilleures informations. Dans les deuxièmes techniques, les éléments du réseau se basent sur des mesures de performance telles que le délai et la perte de paquets pour déduire l état de congestion du réseau. Dans ce cas, le contrôle est effectué au niveau des nœuds des extrémités. Les limites des techniques implicites ont fait recours aux techniques explicites. Fenêtre dynamique/débit dynamique : le débit de la source est contrôlé indirectement par sa fenêtre de transmission dans la technique par fenêtre dynamique. Par contre, dans la technique à débit dynamique, le contrôle se fait directement sur le débit instantané de la source. Hop-by-Hop/End-to-End : le contrôle se fait soit au niveau du réseau, entre les routeurs adjacents, dans ce cas il s agit d un contrôle saut à saut (hop-by-hop), soit au niveau des sources dans ce cas le contrôle est de bout en bout (end-to-end). Kai chen et al [6] proposent une autre classification (Fig. 2.1). Selon que les nœuds intermédiaires acceptent ou non d acheminer les paquets des autres nœuds. Ils distinguent deux types de contrôle de flux : le contrôle de flux coopératif et le non coopératif. Contrôle de flux coopératif : Il est dit coopératif quand tous les nœuds du réseau participent dans l acheminement des paquets. Cette classe regroupe deux grands types de contrôle de flux (Le contrôle de flux implicite et le contrôle de flux explicite). Contrôle de flux non coopératif : Il est dit non coopératif si les nœuds du réseau se comporte de manière égoïste. C est-à-dire que les nœuds n acceptent pas d acheminer les paquets des autres nœuds pour ne pas épuiser leurs ressources. Pour encourager les nœuds à accepter les demandes d acheminement des paquets des autres nœuds plusieurs techniques ont été utilisées telles que la théorie des jeux ou le payement pour le service fourni.

Chapitre 2. Contrôle de flux dans les MANETs 35 Fig. 2.1 Classification des mécanismes de contrôle de flux 2.4 Le contrôle de flux implicite dans les MANETs Le protocole TCP (Transport Control Protocol) est le protocole le plus utilisé dans Internet assurant un contrôle de flux implicite. Il utilise la perte de paquets comme indication d une congestion dans le réseau. Comparativement aux réseaux filaires où presque toutes les pertes sont effectivement dues aux congestions, les réseaux sans fil quant à eux souffrent de plusieurs types de pertes, rendant ainsi TCP non adapté à cet environnement. En effet, des études [52, 53] ont défini plusieurs raisons pour lesquelles TCP se comporte très mal dans les réseaux sans fil et par conséquent pourquoi sa performance se dégrade dangereusement dans cet environnement. Pour y remédier, différentes améliorations sont déjà proposées. Ces améliorations sont faites dans les réseaux sans fil avec infrastructure [54, 55] et dans les réseaux satellitaires [56]. En plus des caractéristiques de ces réseaux, les MANETs sont exposés à d autres problèmes causés principalement par la mobilité et les phénomènes de propagation (plusieurs sauts) tels que les déconnexions fréquentes, le

Chapitre 2. Contrôle de flux dans les MANETs 36 problème des nœuds cachés (ou exposés) et la rupture de routes. Pour recouvrir ces faiblesses, plusieurs solutions sont aussi proposées pour les MANETs [2, 3, 57, 58]. Avant de décrire quelques solutions apportées pour l amélioration du comportement de TCP dans les MANETs, on donnera en premier lieu, une vue globale de ce protocole suivie de ses défaillances dans ces réseaux. 2.4.1 Description générale du protocole TCP Le protocole TCP est un protocole de transport de bout en bout et fiable proposé dans les années 80. Il utilise une fenêtre glissante pour réguler et limiter le débit de transmission. Dans cette section, nous donnons une description générale de son fonctionnement. Pour plus de détails nous pouvons consulter les références suivantes : [59, 60]. 2.4.1.1 Fiabilité de transmission de TCP La fiabilité dans TCP s appuie sur l utilisation d acquittements et des numéros de séquence des paquets envoyés. A chaque réception d un paquet par le récepteur, celui-ci renvoie un acquittement précisant le numéro de séquence du prochain paquet à transmettre. Lorsque TCP transmet un paquet de données, il garde une copie dans une pile de réémission et active une temporisation dite Retransmission Time Out (RTO) ; une fois l accusé de réception est reçu, la copie est supprimée de la pile de retransmission. Dans le cas contraire ; c-à-d que l accusé de réception non reçu au bout de RTO ou trois Acks dupliqués sont reçus, le paquet est réémis de nouveau. 2.4.1.2 Régulation du débit dans TCP TCP utilise une fenêtre coulissante (sliding window) pour la régulation de son débit de transmission. Cette fenêtre dite fenêtre de transmission (TWND : Transmission WiNDow) définit le nombre de paquets pouvant être transmis sans être acquittés. Sa valeur est définie comme étant le minimum entre deux autres fenêtres. La première dite la fenêtre permise (AWND : Allowed WiNDow), elle permet au récepteur d indiquer le nombre de paquets qu il peut recevoir en fonction de l occupation de ses tampons et de la vitesse de traitement

Chapitre 2. Contrôle de flux dans les MANETs 37 des paquets reçus. L envoi de cette valeur dans chaque paquet constitue le contrôle de flux dans TCP. La deuxième fenêtre dite fenêtre de congestion (CWND : Congestion WiNDow) est maintenue par le processus de contrôle de congestion au niveau de l émetteur. Pour estimer la taille de la fenêtre de congestion, TCP suppose que les pertes de paquets sont dues à la congestion. La variation de la taille de cette fenêtre est faite en deux phases : la phase de démarrage lent (Slow Start) et la phase d évitement de congestion (Congestion Avoidance). A la première phase, lorsqu une transmission débute ou reprend après une congestion, la fenêtre CWND est limitée à un paquet, puis elle est incrémentée de un à chaque réception d un acquittement. Mais, pour éviter d augmenter trop rapidement la taille de cette fenêtre et de provoquer une nouvelle congestion, lorsque CWND a atteint un certain seuil dit seuil du slow start (SSThreshold : Slow Start Threshold), TCP entre dans la deuxième phase et ralentit le rythme d augmentation du débit. Pendant cette phase, à chaque réception d un acquittement la fenêtre est incrémentée de 1/CWND. Donc elle est augmentée de 1 si tous les paquets de la fenêtre ont été acquittés. La figure Fig. 2.2 illustre ce mécanisme. Fig. 2.2 Comportement de la fenêtre de congestion de TCP

Chapitre 2. Contrôle de flux dans les MANETs 38 2.4.2 Les défaillances de TCP dans les réseaux MANETs La stratégie adoptée pour la détection de congestion par TCP constitue le maillon faible de ce protocole dans les MANETs. En effet, dans ces derniers TCP doit faire face à de nouveaux challenges [1, 61, 62, 63] posés par les caractéristiques de ces réseaux à savoir : La mobilité : La mobilité des nœuds est un facteur contribuant négativement sur la performance de TCP. A tout moment, un nœud peut changer de position causant ainsi une rupture de route et par conséquent beaucoup de paquets seront perdus. La perte de ces paquets, notamment les paquets ACKs va engendrer de nombreux timeouts consécutifs, ce qui conduit à une réduction inutile de la fenêtre de congestion et par conséquent à une sous utilisation de la bande passante. Énergie : La durée de vie des nœuds mobiles est limitée, vu qu ils sont alimentés par des batteries de capacités limitées. Puisque chaque nœud joue le rôle d un routeur, les retransmissions inutiles des paquets TCP engendrent une consommation supplémentaire de l énergie de ces nœuds. TCP doit alors utiliser cette énergie de manière efficace. La recherche de routes : La durée de rétablissement d une nouvelle route dans les MA- NETs dépend fortement du protocole de routage utilisé. Si la recherche d une route de rechange dure longtemps (durée supérieure à RTO), l émetteur TCP déclenchera inutilement le processus de contrôle de congestion. Ce qui conduira à une dégradation des performances de TCP. Le multi-chemin : Certains protocoles de routage utilise plusieurs routes pour une même destination pour réduire la fréquence de recherche de routes et améliorer la connectivité, surtout dans un environnement très dynamique. Néanmoins, les paquets envoyés sur différentes routes seront reçus en désordre par le récepteur. Ce qui générera des acquittements dupliqués, qui sont des indices de congestion. La zone grise : dans les MANETs, les protocoles qui se basent sur l émission des messages Hello pour détecter les noeuds voisins, peuvent souffrir du problème de la zone grise. Dans ces zones, les paquets de données ne peuvent pas être échangés bien

Chapitre 2. Contrôle de flux dans les MANETs 39 que l émission des messages Hello et les paquets de contrôle indiquent tous les voisins. L origine de ce problème vient du fait que les paquets diffusés (Hello par exemple) sont envoyés avec une vitesse inférieure à celle des paquets envoyés en unicast (les paquets de données). Du fait que la portée du signal décroît avec l augmentation de la vitesse, le protocole de routage détecte des routes qui ne seront pas accessibles par les paquets de données. Les retransmissions : La couche MAC effectue des retransmissions de paquets lorsqu elle ne reçoit pas d acquittements. Cette stratégie ayant comme but l amélioration de la fiabilité rentre en conflit avec celle des retransmissions de TCP. En effet, TCP et la couche MAC peuvent retransmettre le même paquet. Ceci conduira à la génération d acquittements dupliqués. 2.4.3 Amélioration des performances TCP dans les MANETs Beaucoup de solutions ont été proposées [2, 3, 57, 58] pour améliorer les performances de TCP dans les MANETs. Ces propositions peuvent être classées en deux catégories : Celles utilisant une seule couche et celles faisant appel à plusieurs couches (inter-couches) du modèle OSI. 2.4.3.1 Propositions utilisant une seule couche On distingue des propositions où l adaptation est faite au niveau de la couche TCP et celles faites au niveau de la couche liaison. Les propositions pour la couche TCP RTO Fixe : Cette proposition [57] est une technique à l initiative de l émetteur qui n utilise pas le retour d information (feedback) du réseau. Les auteurs emploient une heuristique pour distinguer entre les échecs de la route et les congestions. Quand deux timeout consécutifs expirent et que l ACK manquant n est toujours pas reçu avant l expiration du deuxième RTO (Retransmission Time Out), l émetteur conclut que la route est rompue. Le paquet non accusé réceptionné est retransmis, mais le RTO n est pas doublé une deuxième fois. Donc à l opposé du TCP standard où le

Chapitre 2. Contrôle de flux dans les MANETs 40 RTO est doublé à chaque fois que l ACK attendu n est pas reçu, Le RTO demeure fixe jusqu à ce que la route se rétablisse et que le paquet est accusé réceptionné. Les auteurs ont évalué cette proposition en considérant différents protocoles de routage (AODV, DSR et ADV). Ils ont rapporté que des améliorations considérables sont accomplies en fixant le RTO. Mais cette proposition reste limitée, puisqu elle se base sur la supposition que deux timeouts consécutifs est un résultat exclusif d une rupture de route. En effet, cela nécessite plus d analyse surtout dans le cas d une congestion. TCP DOOR : Dans [2] une nouvelle approche est explorée pour réduire l impact des changements fréquents de routes sur la performance TCP. Cette approche nommée TCP Detection of Out Of Order and Response ne nécessite pas la coopération des noeuds intermédiaires ; c est une approche de bout en bout. Elle se base sur une arrivée désordonnée (Out Of Order) des paquets pour détecter des changements de route. Donc,cette approche permet de distinguer entre les pertes de paquets dues aux changements de routes et celles dues aux congestions du réseau. Dans le protocole TCP, les paquets envoyés par une source sont reçus dans l ordre par le récepteur. Cependant, dans les réseaux ad hoc les paquets ne sont pas toujours reçus dans l ordre de leurs envois. La violation de cet ordre peut avoir lieu dans deux cas différents : le premier cas peut avoir lieu suite aux retransmissions des paquets perdus. Un paquet ayant un numéro de séquence plus petit peut arriver à la destination après les paquets ayant des numéros de séquences plus grands. Ce qui est appelé le Out Of Sequence des paquets. Le deuxième cas peut être constaté quand un paquet envoyé plutôt arrive en retard par rapport aux paquets envoyés après. Cela est dû au fait que les routes empruntées par les différents paquets ne sont pas équivalentes en terme de délai ni de compétition d accès au canal. Dans ce cas on a un Out Of Order (OOO) des paquets. La détection d un OOO est accomplie soit par l émetteur ou par le récepteur. L émetteur utilise la propriété de la non décroissance des numéros de séquence des ACKs pour détecter des OOO. A l arrivée d un ACK, son numéro de séquence est comparé à celui

Chapitre 2. Contrôle de flux dans les MANETs 41 de l ACK précédent, si celui-ci est plus petit un OOO est détecté. En cas d ACKs dupliqués, ces ACKs ont tous un même numéro de séquence, afin que l émetteur puisse détecter un OOO il lui faut une information supplémentaire. Cette information se concrétise par l ajout d un octet aux ACKs, appelé numéro de séquence d ACKs dupliqués (ACK Duplication Sequence Number : ADSN). L ADSN est incrémenté et transmis dans chaque ACK. Cependant, le récepteur a besoin de deux octets supplémentaires pour détecter les OOO, appelé TCP Packets Sequence Number (TPSN). Le TPSN est incrémenté et transmis avec chaque paquet TCP y compris les paquets retransmis. Si le récepteur détecte OOO, il doit avertir l émetteur en positionnant un bit spécifique, appelé OOO bit, dans l entête de l ACK. En réponse à un OOO détecté, l émetteur entreprend les deux actions suivantes : il désactive temporairement le contrôle de congestion, et/ou récupère l état avant le déclenchement du processus de contrôle de congestion. Dans la première action, l émetteur désactive l algorithme de congestion pour une période de temps (T 1 ) après la détection d un OOO. Dans la deuxième action, si l algorithme du contrôle de congestion avait été invoqué pendant la période du temps passée (T 2 ), l émetteur devrait se remettre immédiatement à l état avant l invocation du contrôle de congestion. En effet, les auteurs donnent les périodes du temps T 1 et T 2 en fonction du RTT (Round Trip Time). Les simulations présentées dans [2] montrent que TCP DOOR améliore de 50% les performances de TCP. Néanmoins, la supposition que les événements OOO sont les résultats exclusifs de rupture de routes nécessite beaucoup plus d analyse. En effet, les protocoles de routage multi-chemins tel que TORA [64] peut produire des OOO qui ne sont pas dus aux ruptures de routes. Ack dynamique différé : Cette approche [3] vise à réduire la contention sur le canal sans fil, en réduisant le nombre d ACKs transmis par le récepteur. Elle consiste à envoyer un ACK pour chaque d paquets bien reçus. La valeur de d varie selon les numéros de séquence N des paquets TCP. Les auteurs ont défini trois seuils L 1, L 2,

Chapitre 2. Contrôle de flux dans les MANETs 42 et L 3 tel que : 1 Si N < L 1 2 Si L d = 1 N < L 2 (2.1) 3 Si L 2 N < L 3 4 Si N L 3 La version originale de TCP différé (Delayed ACK) [65], consiste à envoyer un ACK pour chaque deux paquets bien reçus (le coefficient d qui désigne le nombre de paquets bien reçus auquel un ACK est transmis est donc fixé à 2). Les résultats de simulations dans [3] sont obtenus sur une topologie en chaîne. Ils ont amélioré le TCP standard aussi bien que TCP avec ACK différé pour des coefficients d fixés à 2, 3 et 4. CWL adaptatif : Dans [66], un algorithme permettant de limiter la taille de la fenêtre de congestion de manière adaptative (Adaptative Congestion Window Limit) a été proposé. Pour cela, les auteurs se sont intéressés au produit délai bande passante (BDP : Bandwidth-Delay-Product) des routes dans les MANETs. Ils ont montré que, indépendamment du protocole MAC utilisé, la valeur de BDP ne peut pas dépasser le nombre de sauts en aller retour (Round-Trip Hop-Count ; RTHC) de la route. Dans le cas d une chaîne multi-sauts qui utilise IEEE 802.11, ils ont constaté que le BDP est approximativement égal à 1/5 RTHC. En se basant sur ce résultat, ils ont proposé un algorithme qui ajuste la taille maximale de la fenêtre de congestion (Congestion Window Limit) en fonction du nombre de sauts de la route. Ils ont constaté qu en utilisant cet algorithme une amélioration de 16% peut être accomplie. Les propositions de la couche liaison Link RED : Les auteurs [67] ont proposé l algorithme LRED (Link Random Early Detection) dont l objectif est la réduction de la contention sur le canal sans fil. Cette stratégie consiste à réagir avant la surcharge du lien. Pour cela, la couche liaison maintient le nombre moyen d essais de transmission d un paquet. Le paquet à l entête du buffer est marqué/supprimé (dropped/marked) avec une probabilité basée sur ce nombre. Au niveau de chaque nœud, si le nombre moyen d essais (avg retry) est inférieur au seuil (min th), les paquets dans le buffer ne sont ni marqués ni sup-

Chapitre 2. Contrôle de flux dans les MANETs 43 primés. Mais, quand ce nombre devient grand la probabilité de suppression/marquage (dropping/marking) est calculée comme suit : mark prob = Min( avg retry min th, max P ) (2.2) max th min th Adaptive pacing : Cet algorithme est aussi proposé dans [67], son but est l amélioration de la réutilisation spatiale du canal, en distribuant le trafic entre les nœuds intermédiaires de manière plus équilibrée. Dans le protocole IEEE 802.11, un noeud est contraint de lutter pour acquérir le canal par une période du backoff aléatoire plus le temps de transmission d un paquet qui est déterminé par RTS/CTS (Request To Send/Clear To Send). Cependant, le problème du noeud exposé persiste, vu le manque de coordination entre les noeuds qui sont à deux sauts l un de l autre. Cet algorithme résoud ce problème en augmentant la période du backoff par un temps égal à celui de transmission d un paquet supplémentaire. 2.4.3.2 Propositions inter-couches L influence entre deux couches (ou plus) a suscité une forte envie que ces couches puissent s échanger entre elles des informations qui aideront à la résolution d un problème donné. C est l objectif de ces propositions pour améliorer les performances de TCP. TCP et couche réseau TCP-F : TCP Feedback [68] est une approche basée sur les feedbacks. Cette approche permet à l émetteur TCP de distinguer entre les pertes de paquets dues aux ruptures de routes et celles dues aux congestions du réseau. A chaque fois qu une rupture de route est détectée, une notification de rupture de la route (RFN : Route Failure Notification) est explicitement envoyée à la source par l agent de routage. En recevant la RFN, l émetteur TCP bloque son fonctionnement et gèle toutes ses variables telles que les temporisateurs et la taille de la fenêtre de congestion. L émetteur reste dans cet état jusqu à ce qu il soit notifié du rétablissement de la route par un paquet RRN (Route Re-establishement Notification). A ce moment, à partir des anciennes

Chapitre 2. Contrôle de flux dans les MANETs 44 valeurs (la taille de la fenêtre de congestion et les temporisateurs) l émetteur reprend l émission des paquets. Pour éviter le blocage dans l état de gel l émetteur TCP, en recevant RFN, déclenchera un temporisateur. Quand ce dernier expire, l algorithme du contrôle de congestion est normalement invoqué. Technique ELFN : La technique de la notification explicite de la rupture d une route (ELFN : Explicit Link Failure Notification) [69] est semblable à TCP-F. Cependant, à l opposé de TCP-F qui considère la couche réseau comme une boite noire qui émule le comportement d un réseau ad hoc, l évaluation de cette technique est basée sur une vraie interaction entre TCP et le protocole de routage. Cette interaction permet d informer l agent TCP au sujet de la rupture d une route quand elle se produit. En recevant ELFN, l émetteur désactive ses temporisateurs de retransmission et entre en état de veille standby. Pendant cette période, l émetteur TCP surveille par l envoi de paquets spéciaux le rétablissement de la route. Si un ACK correspondant à un de ces paquets est reçu, l émetteur TCP réactive ses temporisateurs de retransmission et continue à transmettre ses données. Les auteurs [69] ont montré que pour CWND (Congestion WiNDow) et RTO (Retransmission Time Out), utiliser les valeurs antérieures avant la rupture de la route est mieux qu initialiser CWND à 1 paquet et/ou RTO à 6 secondes (valeur initiale par défaut de RTO dans le TCP Reno et TCP New Reno [70]). ATCP : Ad hoc TCP [1] utilise aussi, le feedback de la couche réseau. En plus du problème de rupture de routes, ATCP s intéresse également au problème du fort taux d erreurs par bit (BER :Bit Error Rate). Ce protocole insère une nouvelle couche appelée ATCP entre la couche TCP et la couche réseau. L émetteur TCP peut se retrouver dans l un des états suivants : état d attente, état de contrôle de congestion ou l état de transmission. ATCP écoute l information sur l état du réseau fournie par les messages ECN (Explicit Congestion Notification) et ICMP Destination Unreachable. Ensuite, il met l agent TCP dans l état approprié. En recevant le message Destination Unreachable, l agent TCP entre dans l état d attente. Pendant cet état, l émetteur TCP est gelé et aucun paquet n est envoyé jusqu à ce qu une nouvelle route

Chapitre 2. Contrôle de flux dans les MANETs 45 soit trouvée en sondant le réseau. A la réception d ECN, le contrôle de congestion TCP est invoqué normalement sans attendre l expiration du timeout (RTO). Pour détecter des pertes de paquets dues aux erreurs du canal, ATCP contrôle les ACKs reçus. Quand ATCP compte trois réceptions d ACKs dupliquées, il met TCP dans l état d attente et retransmet rapidement le paquet TCP perdu. Après réception du prochain ACK, ATCP remet TCP à son état normal. Ce protocole est considéré comme l un des protocoles inter-couches les mieux conçus. TCP-BuS : TCP Buffering capability and Sequence information [71], utilise un feedback pour détecter une rupture de route. La nouveauté de cette approche réside dans le fait que les nœuds du réseau font une bufferisation des paquets en cours de transmission lorsqu ils reçoivent une notification de rupture d une route. Ainsi, ces paquets ne seront pas perdus. Le protocole de routage utilisé est ABR (Associativity- Based Routing)[72], qui est un protocole à la demande. Les auteurs ont trouvé que cette proposition présente de meilleurs résultats par rapport à TCP et TCP-F. Split TCP : Les connexions TCP qui ont un grand nombre de sauts souffrent de fréquentes ruptures de routes dues à la mobilité. Pour améliorer le débit de ces connexions et résoudre ce problème, Split TCP [73] a été introduit. Il défragmente les longues connexions TCP en segments plus courts comme le montre la figure Fig. 2.3. Le protocole élit un ensemble de proxys (nœud entre deux segments). L agent de routage décide si son noeud a le rôle d un proxy en se basant sur un paramètre de distance dit inter-proxy. A chaque réception d un paquet par un proxy, celuici envoie un acquittement local (LACK pour LocalACK) au proxy précédent. Un proxy est responsable de délivrer les paquets au débit auquel il reçoit les LACK du proxy successeur. Suite à la réception d un LACK (du proxy successeur ou de la dernière destination), le proxy supprime le paquet de son buffer. Pour assurer une meilleure fiabilité et pour garder la sémantique de bout en bout, un ACK est envoyé du récepteur vers l émetteur. Ce protocole sépare aussi les fonctionnalités de la couche transport, en celles qui assurent la fiabilité de bout en bout et celles qui contrôlent la congestion. Cela en

Chapitre 2. Contrôle de flux dans les MANETs 46 Fig. 2.3 TCP Split utilisant deux fenêtres de transmission à la source : La fenêtre de congestion et la fenêtre de bout en bout. Pendant que la fenêtre de congestion change conformément au taux d arrivée des LACKs du proxy successeur, la fenêtre de bout en bout quand à elle, change conformément au taux d arrivée des ACKs de bout en bout. Chaque proxy est doté d une fenêtre de congestion qui contrôle le taux d émission de paquets entre les proxys. Les auteurs confirment une amélioration de 5 à 30% du débit par rapport à TCP. L inconvénient majeur de Split TCP est le trafic généré par les acquittements supplémentaires (LACKs) et par l élection des proxys, surtout dans un environnement avec une forte mobilité. Son avantage, c est qu il ne bloque pas TCP mais régule son débit selon les LACKs qu il reçoit. Couche transport et couche physique JOCP : Le contrôle de la puissance au niveau de la couche physique peut influencer le débit de transmission des noeuds mobiles. M.Chiang [74] a proposé un algorithme distribué qu il a nommé JOCP (Jointly Optimal Congestion-Control and Power-Control) pour améliorer les performances de TCP en utilisant conjointement

Chapitre 2. Contrôle de flux dans les MANETs 47 la couche physique et la couche transport. L idée principale de cet algorithme est que, pendant les périodes de congestion, les noeuds essaieront de transmettre des paquets de façon plus rapide aux niveaux des liens constituant un goulet d étranglement en modifiant leurs puissances de transmission. L algorithme qu il a proposé, combinant le contrôle de congestion et le contrôle de la puissance, consiste à maximiser une fonction objective avec les contraintes de capacité sur tous les liens. La fonction utilité est en fonction du débit des sources. Le but est donc de trouver le couple (x*, p*), sachant que x* est la valeur optimale du débit de transmission d une source donnée et que p* les valeurs optimales de puissance de transmission sur tous les liens formant la route. p* est donc un vecteur de cardinal égal au nombre de liens de la route. Couche réseau et couche physique Routage préventif dans les réseaux ad hoc : Le but de cette technique est de réduire le nombre d échecs de routage [75]. Cela est assuré en utilisant une nouvelle route quand il y a une prédiction de rupture de la route en cours. Cette technique est combinée aux protocoles de routage AODV [16] et DSR [15]. Le mécanisme de détection d une rupture est basé sur la puissance du signal. En effet, quand la puissance du signal est au-dessous d un seuil préventif donné, l agent de routage de la source est notifié. A la réception de cette notification, une nouvelle route est recherchée. Une fois celle-ci est trouvée, les transmissions sont basculées sur cette nouvelle route. Dans cet algorithme, la valeur du seuil préventif est critique. En effet, il n y aura pas assez de temps pour découvrir une route alternative avant la rupture de la route en cas où la valeur du seuil est trop petite. De même, la notification sera produite trop tôt dans le cas où la valeur est grande. Pour surpasser les fluctuations de la puissance du signal reçu dues à l affaiblissement du canal et aux effets du multi chemins qui peuvent déclencher inutilement un avertissement de la route préventive et causent inutilement des inondations de la demande d une nouvelle route, les auteurs ont utilisé un message permettant de sonder le réseau pour vérifier la validité du message de l avertissement.

Chapitre 2. Contrôle de flux dans les MANETs 48 Gestion du lien basée sur la puissance du signal : Cette proposition [76] est similaire à la précédente. Cependant, dans cet algorithme chaque noeud enregistre les puissances des signaux reçus qui sont envoyés par les noeuds voisins à un saut. Ensuite en utilisant ces puissances, le protocole de routage peut prédire une rupture d un lien dans le futur immédiat. Cette prédiction est appelée la gestion proactive du lien (Proactive link Management). En détectant cet événement, l agent de routage de la source est notifié par un message Going Down. En recevant ce message, à l opposé de [75], il cesse d envoyer des paquets et entame une procédure de la découverte de route. La nouveauté de cette proposition est aussi le mécanisme de la gestion réactive d un lien. Ce mécanisme augmente momentanément la puissance de transmission pour rétablir un lien rompu. Cela permet de réduire les pertes de paquets en transit. Les mécanismes de la gestion réactive et proactive du lien peuvent être combinés de la manière suivante : A la prédiction de la rupture d un lien, la source sera notifiée pour arrêter l envoi (gestion proactive), et ce noeud augmente sa puissance de transmission pour assurer un bon acheminement des paquets en transit sur ce lien (gestion réactive). Beaucoup d autres travaux ont été effectués pour améliorer les performances du contrôle de congestion de TCP dans les réseaux mobiles ad hoc [77, 78, 79]. Cela ne témoigne que du grand intérêt et d importants efforts dans ce domaine. Malheureusement, malgré tous ces travaux qui ont essayé d apporter des solutions aux faiblesses de TCP et qui ont étudié l impact de plusieurs paramètres sur ses performances, il reste toujours vulnérable aux caractéristiques inhérentes aux réseaux sans fil ad hoc. En conséquence d autres études, au lieu de proposer des solutions améliorant le comportement de TCP se sont intéressées au développement de nouveaux protocoles assurant un contrôle de flux pour éviter toute congestion du réseau en tenant compte des caractéristiques de ces réseaux. Ces protocoles sont dits protocoles de contrôle de flux alternatifs ou contrôle de flux explicite à l opposé des protocoles de contrôle de flux implicite. Il a été montré [5, 6] qu un contrôle de flux

Chapitre 2. Contrôle de flux dans les MANETs 49 explicite spécifiant à l émetteur le débit de transmission à l aide d un feedback est une meilleure alternative pour le contrôle de flux dans les MANETs. 2.5 Protocoles de contrôle de flux alternatifs Le premier protocole représentatif de cette catégorie de protocoles est le protocole EXACT (EXplicit rate flow ConTrol), proposé par Chen et al. [4, 6]. EXACT est basé sur le retour de l information sur le débit et il est supporté par tous les nœuds du réseau. Chaque noeud envoie sa bande passante courante à ses voisins et calcule la bande passante locale partagée entre tous les flux. L information explicite sur le débit est insérée dans tous les paquets passant par les noeuds intermédiaires pour transmettre la bande passante minimale au récepteur du flux. En effet, chaque noeud vérifie si le débit qu il peut offrir pour le flux est inférieur au débit spécifié actuellement dans l en-tête du paquet qu il a reçu. Dans ce cas, la plus petite valeur du débit est mise dans l en-tête du paquet avant de l acheminer au nœud suivant. De ce fait, le plus petit débit qui peut constituer un goulet d étranglement est propagé jusqu au récepteur. Un autre protocole ayant des propriétés similaires à celles d EXACT est présenté dans [5]. Ce protocole nommé ATP (Adhoc Transport Protocol), régule ses envois en se basant sur un débit de transmission et non pas sur une fenêtre de transmission comme dans TCP. A l opposé de ce dernier où juste les nœuds source et destination interviennent dans le processus de contrôle de congestion, ATP fait intervenir tous les nœuds du réseau. ATP regroupe toutes les fonctionnalités de TCP mais il sépare le processus de congestion de celui de la fiabilité. Tous les nœuds calculent un délai moyen pour tous les paquets les traversant. Ce délai (D = Q t + T t ) représente la somme du délai moyen d attente du paquet dans la file du nœud (Q t ) et le délai moyen de transmission (T t ). Comme l information sur le débit dans EXACT, la valeur de ce délai est insérée dans les paquets. Au passage d un paquet à travers un nœud, cette valeur est remplacée par le délai calculé si celui-ci est plus grand. De ce fait, le délai maximum sur tout le chemin est communiqué au récepteur. Ce dernier,

Chapitre 2. Contrôle de flux dans les MANETs 50 à son tour renvoie cette information délai à l émetteur. En se basant sur cette information, la source adapte son débit de transmission. Pour trouver un débit adéquat au début d une nouvelle connexion, ATP envoie des paquets de sondage de la source jusqu à la destination. A chaque fois qu un paquet passe par un nœud le délai est calculé. Liu et Singh [80] proposent un protocole de transport appelé aussi ATP (Application controlled Transport Protocol) basé sur les exigences de certaines applications dans les réseaux mobiles ad hoc. Le protocole TCP n est pas approprié pour certaines applications demandant une qualité de services du fait qu il soufre d un faible rendement (throughput) dans les MANETs. Par contre, UDP peut bien satisfaire ces demandes en qualité de services s il ne soufre pas d un grand taux de perte de paquets. ATP est alors conçu de sorte à répondre aux demandes de ces applications. ATP est plus léger comparativement à TCP et plus fiable comparativement à UDP. Il s appuie sur les paquets ACKs. En effet, un feedback est toujours envoyé à l application, soit que l ACK correspondant à un paquet donné est reçu ou non par la couche transport. Ensuite, c est à l application utilisant le protocole ATP de prendre la décision de retransmettre ce paquet dans l immédiat ou de reporter sa retransmission pour plus tard. Confier cette tâche à l application est une approche intéressante dans la mesure où elle permet la réduction du nombre de retransmissions de paquets. Cependant, aucun autre composant de la couche transport n est implémenté, en particulier le contrôle de congestion qui devrait aussi être assuré par l application elle même. De ce fait, utilisé ATP tout seul peut ne pas être suffisant pour protéger les réseaux MANETs du problème de congestion. WXCP (Wireless explicit Congestion control Protocol) [81] est une extension du protocole XCP (explicit Congestion control Protocol)[82] conçu pour les réseaux filaires. Cette solution utilise un feedback explicite et trois métriques pour évaluer le niveau de congestion dans le réseau. Ces métriques sont la bande passante disponible, la taille de la file d attente et le nombre moyen de retransmissions au niveau de la couche liaison. Elles sont estimées au niveau de chaque nœud intermédiaire. Le feedback global est alors en fonction de ces trois paramètres. WXCP est une approche basée sur la fenêtre de transmission mais utilise

Chapitre 2. Contrôle de flux dans les MANETs 51 aussi le principe basé sur le débit. L émetteur peut basculer de l utilisation de la fenêtre de transmission par défaut au mécanisme de contrôle par débit. Anastasi et al [83] ont développé un protocole de transport pour les réseaux Ad Hoc, qu ils ont baptisé TPA (Transport Protocol for Ad hoc networks). Le mécanisme de contrôle de congestion de TPA s inspire de celui de TCP. Le but de ce nouveau protocole est de réduire le nombre de retransmissions de paquets. Les paquets sont transmis par blocs utilisant le modèle de fenêtrage. Les paquets sont regroupés en bloc de taille fixe, ensuite chaque bloc est transmis de manière fiable à la destination avant la transmission d aucun paquet du bloc suivant. La retransmission des paquets n est faite qu une fois que tous les paquets du bloc soient transmis ainsi un bloc est transmis plusieurs fois : en premier tous les paquets d un bloc sont transmis, ensuite les paquets auxquels des accusés de réception ne sont pas reçus sont à chaque fois retransmis jusqu à ce que tous les paquets du bloc soient bien arrivés à la destination. Le protocole TPA peut fonctionner seul comme il peut utiliser le mécanisme ELFN (Explicit Link Failure Notification). Si ce dernier est utilisé, TPA entre dans l état de gel à la réception de cette notification et réduit la fenêtre de congestion à un. Si par contre, ELFN n est pas utilisé, TPA détecte les ruptures de routes en constatant un certains nombres de timeouts. Comme TCP, le protocole TPA utilise une estimation du RTT pour calculer le RTO. En cas de changements de route, les nouvelles valeurs de RTT sont recalculées. Pour le contrôle de la congestion, TPA utilise le mécanisme basé sur la fenêtre avec une taille maximale limitée. Réellement, seulement deux valeurs du CWND sont utilisées : 2 ou 3 paquets et cette fenêtre est remise à 1 chaque fois qu une congestion est détectée. Les résultats de simulations de TPA le révèlent meilleur que TCP. Mais, ces simulations sont faites que pour une topologie en chaîne et dans un environnement statique. Cependant, ces améliorations peuvent ne pas être maintenues dans des environnements plus complexes et dynamiques.

Chapitre 2. Contrôle de flux dans les MANETs 52 2.6 Conclusion Nous avons présenté dans ce chapitre un état de l art sur le contrôle de flux dans les réseaux mobiles ad hoc. TCP qui a gagné un grand succès dans les réseaux filaires, présente un handicap majeur dans les MANETs. Le principal problème de TCP dans cet environnement est son incapacité à distinguer entre les pertes dues aux congestions et celles dues aux caractéristiques inhérentes aux réseaux ad hoc. TCP suppose que les pertes surviennent toujours suite à des situations de congestion dans le réseau. Mais, bien que cette supposition soit souvent valide dans les réseaux filaires ce n est pas du tout vrai dans les réseaux sans fil. Dans les MANETs, plusieurs types de pertes sont constatées telles que : les pertes causées par les ruptures de routes, par les partitions du réseau, par les interférences, etc... Considérer le même processus de contrôle de congestion de TCP dans ces réseaux conduit à une dégradation importante des performances. Pour cela beaucoup de propositions ont été faites pour améliorer son comportement dans les MANETs. Bien que chacune de ces dernières contribue à une augmentation des performances du réseau utilisant TCP, mais il présente toujours des limites. Pour cela, d autres solutions alternatives ont été proposées pour assurer un meilleur contrôle de flux dans les réseaux ad hoc. Dans cet ordre d idées nous proposons une nouvelle solution pour le contrôle de flux pour les MANETs. Notre solution consiste en premier lieu en la proposition d un nouveau protocole de routage avec QoS permettant de trouver des routes évitant la congestion du réseau. En deuxième lieu, un mécanisme de contrôle de flux explicite est ajouté à ce protocole de routage. Pour assurer ce contrôle, un feedback est renvoyé de la destination à la source. A la réception de ce feedback qui véhicule le débit adéquat de transmission, la source adapte son débit de transmission. Le chapitre suivant est réservé à la description de cette solution.

Chapitre 3 Présentation de la solution 3.1 Introduction Dans ce chapitre, nous présentons notre solution qui consiste à mettre en place un nouveau protocole de routage avec qualité de services, intégrant un mécanisme de contrôle de flux. Cette solution permettra une meilleure prise en charge des congestions et des pertes de paquets. Elle est composée de deux principales parties. Dans la première, nous avons développé un protocole de routage avec Qualité de Services (QoS) dans le but de réduire les congestions et d exploiter au mieux les ressources rares d un réseau ad hoc. Elle consiste à trouver la meilleure route assurant une bonne qualité de services : celle qui nous offre une plus grande bande passante, un délai minimal et une plus grande stabilité. Bien que cette partie soit déjà une solution permettant la réduction des congestions causées par la contrainte de ressources limitées, elle reste toutefois incapable de les éliminer. Imaginons, le cas où l émetteur transmet à un débit supérieur à celui, d au moins, un lien de la route trouvée. Ce lien constituera un goulet d étranglement. Pour cela, dans la seconde partie, nous avons ajouté un mécanisme de contrôle de flux explicite. Ce dernier consiste à informer l émetteur du débit de transmission adéquat sur la route trouvée par le protocole de routage. A la réception de cette information, l émetteur adapte son débit de transmission pour éviter les congestions et les pertes de paquets. Ce débit correspond à la plus petite valeur de la bande passante sur tous les liens constituant la route de la source jusqu à la destination. 53

Chapitre 3. Présentation de la solution 54 3.2 Motivations Le problème de congestion a une grande influence sur les performances des réseaux mobiles ad hoc. Ce problème peut être résolu par une technique de routage et/ou par un mécanisme de contrôle de flux. Dans la plupart des travaux précédents, le routage et le contrôle de flux sont traités séparément. Pour atteindre de meilleures performances et mieux résoudre le problème de congestion, nous avons considéré conjointement le routage et le contrôle de flux. Dans les réseaux ad hoc, les travaux portant sur le problème de routage au mieux ont essentiellement pris le dessus. Toutefois, de nombreux paramètres importants telles que la bande passante, la durée de vie d un lien, l énergie des nœuds...etc, ne sont pas considérés en même temps dans le routage. De même, certains de ces paramètres sont pris avec des niveaux de détails insuffisants. En effet, par exemple, dans [84] les auteurs ont calculé la durée de vie d un lien sans tenir compte d un paramètre que nous considérons important et déterminant. Il s agit bien de l énergie des nœuds formant le lien. Pour pallier à cette insuffisance, nous avons proposé une nouvelle formule calculant la durée de vie d un lien en tenant compte de l énergie des nœuds en plus de leurs vitesses et de leurs directions. Pour cela notre nouveau protocole de routage utilise la bande passante, le délai et la durée de vie d un lien comme paramètre de qualité de services. Les caractéristiques des réseaux mobiles ad hoc, comme la topologie dynamique et le manque de ressources occasionnent de fréquentes ruptures des routes déjà trouvées. Dans de telles situations, des solutions de rechange doivent être disponibles. Cela nous a motivé pour l application d une heuristique basée sur le système fourmis dans le développement de notre solution. Ce système doté d une intelligence dite l intelligence en essaim [85] est de plus en plus étudié en informatique pour la résolution de problèmes complexes [86, 87, 88, 89, 46, 90]. Il offre un moyen de concevoir des systèmes capables de s adapter rapidement à des conditions changeantes. C est sur ce point que les comportements collectifs ont de plus grandes puissances. Imaginons que pour une raison ou une autre, les paramètres du problème à résoudre changent : un obstacle tombe sur la route des fourmis

Chapitre 3. Présentation de la solution 55 par exemple. La colonie de fourmis va tout de même continuer sa tâche à partir de cette nouvelle configuration. En effet, les fourmis explorent continuellement différentes voies ; les différentes pistes de pheromone fournissent des plans de secours. Ainsi lorsqu une voie est coupée des solutions de rechange sont déjà prêtes. Cette propriété d exploration de solutions de rechange nous a motivée à utiliser un algorithme fourmis dans les MANETs. Avant de décrire en détail notre solution, nous donnons dans la section suivante quelques concepts de base des systèmes fourmis. 3.3 Les systèmes fourmis (The Ant Systems) Les systèmes fourmis (Ants Systems) sont apparus vers la fin des années 90 grâce aux travaux de M. Dorigo et A. Colorni qui présentent leur théorie dans [91]. Dans cet article fondateur, ils proposent une nouvelle approche pour l optimisation stochastique combinatoire et mettent en avant la rapidité de leur méthode à trouver des solutions acceptables tout en évitant les convergences prématurées. L optimisation par colonie de fourmis s inspire du comportement des fourmis lorsqu elles sont à la recherche de nourriture. Elles indiquent le chemin grâce à une substance chimique volatile (qui s évapore avec le temps) dite pheromone. Une fourmi isolée se déplace généralement de manière aléatoire. En se déplaçant, elle dépose une quantité de pheromone que les autres fourmis suivent avec une grande probabilité. Quand une fourmi suit un chemin, elle renforce l intensité de pheromone qui se trouvent sur ce dernier en y déposant les siennes. Il en résulte un comportement collectif au bout duquel plus un chemin est attractif, plus il y a un grand nombre de fourmis qui le suivent. Pour illustrer ce comportement, considérons l expérience de la figure Fig. 3.1. Un ensemble de fourmis se déplacent le long d un chemin droit entre leur fourmilière A et une source de nourriture B (figure Fig. 3.1.a). A un moment donné, un obstacle est mis au travers de ce chemin de façon à ce qu un coté soit plus loin qu un autre (Figure Fig. 3.1.b). Les fourmis allant du sens A vers B et celles allant de B vers A vont choisir une direction à prendre entre C et D. Les premières fourmis vont choisir une direction aléatoire et déposer

Chapitre 3. Présentation de la solution 56 Fig. 3.1 Comportement des fourmis lors de la recherche de nourriture de la pheromone le long de leur chemin, mais celles qui prendront le chemin ADB (ou BDA) arriveront les premières au bout de l obstacle déposant ainsi plus de pheromone que ne le feront celles qui ont pris le chemin ACB ou BCA. Le choix des autres fourmis est alors influencé par l intensité des pheromones, ce qui les stimule à choisir le chemin ADB plutôt que le chemin ACB (figure Fig.3.1.c). Les fourmis auront alors trouvé le chemin le plus court entre la fourmilière et la source de nourriture. Ce système est modélisé par des fourmis artificielles qui sont des agents simples et autonomes. Dans ce système artificiel, le temps est considéré comme discret et les fourmis ne sont pas complètement aveugles. Elles ont un champ de visibilité qui peut jouer un rôle dans leurs déplacements. En général, une fourmi se trouvant à un instant t à un point i choisit le point j (c est à dire prendre le chemin (i, j)) selon la probabilité de l équation (3.1) : P i, j (t) = (τ i, j (t)) α (η i, j ) β (i,k) C (τ i, k (t)) α (η i, k ) β (3.1)

Chapitre 3. Présentation de la solution 57 Où : τ i, j (t) : est l intensité de pheromones du chemin (i, j) à l instant t déposées par les fourmis qui ont déjà pris ce chemin. η i, j : est la visibilité du chemin (i, j) par la fourmi à l instant t (la fourmi suppose qu il y a de la nourriture au bout de ce chemin. α et β : sont des paramètres qui contrôlent respectivement l importance relative de l intensité de la pheromone par rapport à la visibilité de la fourmi. C : représente l ensemble des chemins possibles à partir du point i. ((i, k) est un chemin de C). Chaque fourmi a qui suit le lien (i, j) ajoute une quantité de pheromone représentée par τ i, a j. La pheromone étant une substance qui s évapore, l intensité de pheromone du lien (i, j) à l instant (t + 1) est égale à ce qui reste après évaporation, plus la somme des quantités laissées par toutes les fourmis ayant pris ce lien à l instant t. Elle est représentée par l équation (3.2) : τ i, j (t + 1) = σ τ i, j (t) + Où : m τi,j a (3.2) σ : est un coefficient représentant l évaporation de la pheromone entre t et t + 1. Ce coefficient doit appartenir à l intervalle ]0.. 1[ pour éviter l accumulation de la pheromone et la convergence prématurée [91]. a : représente une fourmi ayant déposé une quantité de pheromone sur le lien (i, j). m : représente le nombre de fourmis ayant pris le lien (i, j). En règle générale, la pheromone représente la tendance à s approcher de la solution optimale. Son évaporation donne un dynamisme à la méthode et évite la convergence prématurée. La visibilité nous permet d orienter l algorithme pour mieux converger vers la solution optimale. Plusieurs problèmes ont été traités par cette méthode. Ces problèmes appartiennent à des domaines très variés et leurs modélisations diffèrent d un problème à un autre [46] [86] a=1

Chapitre 3. Présentation de la solution 58.. [90] [92, 93, 94]. En particulier, les systèmes fourmis ont été utilisés dans nos travaux sur la prédiction et la réservation de ressources [95, 96]. Dans ce présent travail, nous appliquons les systèmes fourmis au problème de routage avec qualité de services dans les MANETs. 3.4 Description de la solution Nous avons représenté le réseau par un graphe G(V, E) où V est l ensemble des nœuds mobiles dans le réseau et E est l ensemble de ses liens. Nous avons noté (v i, v j ) V 2, le lien formé par les deux nœuds v i et v j. Notre solution prend en compte trois paramètres de QoS : la Bande passante B, le Délai de transfert D et la stabilité T (ou durée de vie d un lien). Nous avons donc associé à chaque lien (v i, v j ) un triplet : B(v i, v j ), D(v i, v j ) et T (v i, v j ). La figure FIG. 3.2 illustre un exemple de cette représentation. Une route R est définie par une séquence de nœuds de V allant d un nœud source v s et arrivant à un nœud de destination v d, ne contenant pas de cycle. Fig. 3.2 Exemple de representation d un MANET avec les trois paramètres de QoS

Chapitre 3. Présentation de la solution 59 3.4.1 Les paramètres de QoS utilisés Trois paramètres de qualité de services sont utilisés par le protocole de routage proposé, à savoir : La bande passante, Le délai, La stabilité. Ils sont définis ci-dessous : 3.4.1.1 La bande passante La bande passante est une des ressources critiques et limitées des réseaux mobiles. Actuellement, les demandes en bande passante par des applications ne cessent d accroître. Mais transmettre des données à une capacité supérieure à celle d un chemin dans le réseau peut entraîner de graves congestions conduisant à l écroulement du système. Donc, la mise en place d une solution permettant la régulation du débit de transmission, en fonction de la bande passante disponible sur les différents liens d une route, est une nécessité incontournable. Le calcul de la bande passante est un problème très difficile. Il constitue un sujet de recherche dans les réseaux ad hoc. Plusieurs approches ont été proposées pour le calcul de la bande passante [42, 97, 98]. Nous avons opté pour l approche décrite dans [42] et [98]. Le choix de cette méthode est motivé par le fait qu elle ne nécessite aucun trafic supplémentaire qui peut consommer plus de bande passante et d énergie ou même surcharger le réseau et causer ainsi des congestions. Cette approche est basée sur la méthode d accès au support de communication DCF d IEEE 802.11. Elle fournit à la couche réseau un ensemble de mesures issues de la couche MAC et LLC. La bande passante disponible sur un lien formé de deux noeuds v i et v j, notée Bd (i,j) est donnée par la formule (3.3) suivante : Bd (i,j) = (1 u) BpE (i,j) (3.3)

Chapitre 3. Présentation de la solution 60 Où u : est le facteur d utilisation du canal. (1 u) représente donc le taux de repos du canal (canal libre). BpE (i,j) : est la bande passante effective des transmissions sur le lien (v i, v j ). La bande passante effective d un paquet (BpE packet ), de taille S bits, est calculée par la formule (3.4) comme suit : où : BpE packet = S T reception T transmission (3.4) T transmission : est l instant de transmission du paquet par le noeud v i T reception : est l instant de réception de ce paquet par le noeud v j. Au niveau de la couche MAC 802.11, la formule (3.4) est exprimée comme suit : S BpE packet = t q + (t s + t CA + t Overhead ) R + R r=1 B (3.5) T avec t q est le temps d attente dans les files d attente au niveau MAC, t s est le temps de transmission des S bits, t CA est le temps de la phase d évitement des congestions (Congestion Avoidance phase), t Overhead est le temps ajouté par le surcoût (ex. RT S/CT S, ACK, entête et délai de propagation), R est le nombre de retransmissions et B T est le temps de Backoff pour la rème retransmission. Si chaque nœud v j mesure la bande passante pour chaque paquet envoyé par v i, il va y avoir des variations importantes dans ses mesures de la bande passante disponible. Pour éviter cette instabilité et obtenir une valeur représentative de la bande passante sur un lien, une fenêtre de paquets est utilisée. Une fenêtre de 16 ou 32 paquets donne de meilleures performances comme le montre la figure FIG. 3.3 [42]. La durée de transmission de ces paquets est notée window-duration et la durée pendant laquelle le canal est libre durant ces transmissions est notée idle-time-in-window. Ces deux valeurs sont utilisées pour calculer le taux de repos du canal (1 u) par la formule (3.6) suivante :

Chapitre 3. Présentation de la solution 61 Fig. 3.3 Le rendement par paquet et dans une fenêtre de 32 paquets 1 u = idle-time-in-window window-duration (3.6) Au final, la bande passante disponible du lien (v i, v j ) donnée par l équation (3.3), sera reformulée par l équation (3.7) suivante : Bd i, j = idle-time-in-window window-duration BpE w (3.7) Sachant que BpE w est la bande passante effective moyenne des paquets transmis dans la fenêtre w. 3.4.1.2 Le délai Certaines applications nécessitent souvent le respect d un délai. Dans ce cas, l estimation du délai entre noeuds voisins ou de bout en bout d un chemin est nécessaire. Dans les réseaux filaires, les implementations de TCP effectuent des mesures du RTT (Round Trip Time) qui correspond à l intervalle de temps entre l émission d un paquet et la réception de l ACK correspondant. Dans les réseaux sans fil, plusieurs méthodes ont été proposées. Certaines estiment le délai de bout en bout tels que [44] et [99]. D autres

Chapitre 3. Présentation de la solution 62 estiment le délai d un lien (entre nœuds voisins)[42] et [100]. Des méthodes probabilistes sont aussi proposées [101, 102, 103]. Nous nous intéressons au modèle d estimation du délai d un lien par sonde [42, 100]. Ce modèle estime le délai d un lien en calculant la différence de temps s écoulant entre la création d un paquet Hello et la réception de ce dernier par le destinataire. L émission d un tel paquet Hello ne doit pas être prioritaire sur les paquets de données. Cela permet d estimer le temps passé en file d attente par un paquet de données et de ne pas se limiter au temps de transmission et de propagation du paquet. Ce modèle ne peut être appliqué dans le cas où les horloges des différents nœuds ne sont pas synchronisées. Plusieurs travaux ont étudié ce problème de synchronisation [104, 105] dans les réseaux ad hoc. Nous avons utilisé la technique présentée dans [42] et [100] qui suppose que les horloges sont synchronisées. Notre choix pour ce modèle est justifié par le fait que cette méthode n augmente pas la charge du trafic dans le réseau. Cela, permet de réduire les congestions et la consommation de ressources telles que : la bande passante et l énergie. 3.4.1.3 La stabilité des routes Le déplacement des noeuds dans le réseau et la limitation de la ressource énergétique entraînent des ruptures sur les routes déjà établies. L accroissement de la vitesse de déplacement et l épuisement des batteries de certains noeuds rendent les routes particulièrement instables. Cela, engendre une augmentation de flux de contrôle pour la recherche de nouvelles routes. En conséquence, de graves congestions peuvent apparaître et une importante quantité d énergie peut être consommée. Pour remédier à ce problème, plusieurs travaux proposent des estimations différentes de la durée de vie des liens (routes). Dans [7] et [8] les auteurs ont calculé la durée de vie d un lien entre deux nœuds en se basant sur leurs vitesses et leurs directions de déplacement. Mais, ils ont considéré le cas extrême où les deux nœuds s éloignent l un de l autre. Cependant, il peut y avoir des situations où les deux nœuds mobiles se rapprochent ou se déplacent dans la même direction et avec la même vitesse. Dans ce cas le lien peut être maintenu pour une longue durée. Dans [84] les auteurs ont défini la durée de vie d un lien

Chapitre 3. Présentation de la solution 63 entre deux noeuds comme étant la durée pour laquelle ces nœuds restent toujours connectés (durée pour laquelle ces deux nœuds sont à une distance inférieure ou égale au rayon de couverture). Elle est calculée en fonction des directions et des vitesses des nœuds formant le lien. La formule (3.8) donne la durée de vie d un lien (appelée aussi stabilité d un lien) entre les nœuds v i et v j ayant respectivement (x i, y i ) et (x j, y j ) comme coordonnées, S i, S j comme vitesses et θ i, θ j comme direction (l angle que choisit un nœud pour se déplacer)avec 0 < θ i, θ j < 2Π. où, T (v i, v j ) = (ab + cd) + (a 2 + c 2 )r 2 (ad bc) 2 a 2 + c 2 (3.8) r = rayon de couverture de chaque noeud. a = S i cos θ i S j cos θ j b = x i x j c = S i sin θ i S j sin θ j d = y i y j D après ces auteurs quand S i = S j et θ i = θ j ; ce qui signifie que, quand les deux nœuds se déplacent avec une même vitesse et dans la même direction, la durée de vie du lien qu ils forment devient infinie ( ). Cependant, cela ne peut être vrai en considérant un autre paramètre très important dans les réseaux mobiles qui est la ressource énergétique. Pour cela, nous avons proposé une nouvelle formule qui calcule la durée de vie d un lien tout en considérant les vitesses, les directions de déplacement des nœuds et leurs énergies [106]. Nous définissons alors, la durée de vie d un lien (v i, v j ) comme étant la durée minimale entre sa durée de vie selon l équation précédente et la durée minimale en autonomie des deux noeuds v i, v j formant le lien. Nous proposons donc la nouvelle formule (3.9) ci-dessous pour le calcul de la durée de vie : T (v i, v j ) = Min[ (ab + cd) + (a 2 + c 2 )r 2 (ad bc) 2 a 2 + c 2, Min(E(v i ), E(v j ))] (3.9) où,

Chapitre 3. Présentation de la solution 64 Fig. 3.4 Schématisation du mouvement d un noeud E(v i ) et E(v j ) représentent l autonomie en énergie des noeuds v i et v j respectivement. La figure FIG. 3.4 montre la direction θ i que choisit à chaque fois le nœud n pour se déplacer d un point vers un autre dans un espace à deux dimensions. 3.4.2 Type et structure des paquets Les paquets utilisés dans la solution proposée peuvent être divisés en trois classes : les paquets de données : ils représentent les informations échangées entre les noeuds du réseau. Pour arriver à destination, ces paquets suivent à chaque fois, la meilleure route trouvée par le protocole de routage. Les paquets Hello : se sont des paquets de contrôle chargés de définir à chaque fois le voisinage d un nœud. Chaque paquet contient l adresse du nœud qui le diffuse. Ce qui permet aux nœuds le recevant de le déclarer comme voisin. Ils sont diffusés périodiquement. Puis chaque noeud recevant un Hello déclare le noeud émetteur

Chapitre 3. Présentation de la solution 65 comme son voisin. Chaque paquet Hello contient aussi un champ contenant l instant de sa création permettant ainsi le calcul du délai entre le nœud l ayant diffusé et le nœud l ayant reçu. Les paquets fourmis : ce sont des paquets de contrôle chargés de la recherche de routes et de la mise à jour des différentes tables de routage. On distingue les Forward ants qui sont des paquets envoyés par la source pour la recherche de routes vers une destination donnée et les Backward ants qui sont des paquets retournés par la destination en guise de réponse pour les forward ants sur la route trouvée. Pour chacun de ces types de paquets nous lui avons défini une structure, que nous présentons ci-dessous : Structure des paquets Forward ant Les paquets forward ant sont représentés par une structure à plusieurs champs comme l illustre la figure FIG. 3.5. Fig. 3.5 Structure des Forward ants SourceNode : désigne l adresse du nœud source DestinationNode : désigne l adresse du nœud destinataire Visite : contient la liste des nœuds qui sont au fur et à mesure visités par la fourmi. Cette liste forme la route R de la source à la destination. Debit : contient le débit minimum sur la route qui se forme au fur et à mesure que la fourmi avance. C est le minimum des B i, j (formule 3.7 de la page 61) de la route R. Une fois la fourmi arrivée à la destination, ce champ aura la valeur minimale du débit sur toute la route. Cette valeur sera retournée à la source pour réguler son débit. Stab : contient la durée de vie minimale de la route (stabilité de la route). C est le minimum des T (v i, v j ) de la route R (formule 3.9 de la page 63). Delai : c est la somme des délais sur tous les liens parcourus (Délai sur la route). Somphero : c est la quantité de pheromone accumulée sur toute la route. Cette quan-

Chapitre 3. Présentation de la solution 66 tité divisée par le nombre de sauts de la route détermine sa qualité. TTL : c est la durée de vie de la Forward ant. Structure des paquets Backward ant Les paquets Backward ant sont aussi représentés par une structure à plusieurs champs comme le montre la figure FIG. 3.6. Fig. 3.6 Structure des Backward ants SourceNode : désigne l adresse du nœud source de ce paquet. Donc c est le noeud destinataire du paquet Forward ant. DestinationNode : désigne l adresse du nœud destinataire de ce paquet. Donc c est le noeud source du paquet Forward ant. Visite : c est la liste des noeuds visités par la Forward ant que la Backward ant va parcourir dans le sens inverse. Débit : c est le débit minimal trouvé par la Forward ant sur la route qu elle a traversée. C est le débit adéquat avec lequel il faut transmettre sur la route trouvée. τ :c est la quantité de pheromone à ajouter sur chacun des arcs traversés 3.4.3 Structure des tables Chaque nœud du réseau maintient deux tables : la table de routage et la table des voisins comme le montre la figure Fig 3.7 : La table de routage : consiste à indiquer à chaque nœud le saut suivant pour acheminer les données vers la destination voulue, en tenant compte de la qualité de la route (quantité de la pheromone sur la route). Elle est composée de champs suivants : Destination : indique toutes les destinations fournies par notre protocole à partir du nœud actuel. Saut suivant : indique le nœud suivant à prendre pour une destination donnée.

Chapitre 3. Présentation de la solution 67 Fig. 3.7 Structure des tables au niveau du noeud v 1. Pheromone : indique la qualité de la route. La table des voisins : c est dans cette table que chaque nœud enregistre la liste de tous ses voisins identifiés à la réception des paquets Hello. Elle contient les différents paramètres caractérisant tous les liens entre ce nœud et ses voisins. Ses champs sont : Voisins : indique tous les voisins du nœud. Délai : indique le délai du lien entre ce nœud et son voisin. Pheromone : indique la quantité de la pheromone sur le lien. Stabilité : indique la durée de vie d un lien. Bande passante : indique la bande passante disponible sur le lien. 3.5 Description de l algorithme La description détaillée de notre algorithme est donnée par les différentes phases suivantes : Phase1 : Découverte de voisins

Chapitre 3. Présentation de la solution 68 Tous les noeuds du réseau diffusent périodiquement des parquets Hello contenant leurs adresses. Le noeud qui reçoit ce paquet déclare le noeud émetteur comme voisin et l ajoute à la table des voisins. Phase2 : Découverte de route A chaque fois qu un nœud source v s désire transmettre des données à un nœud destinataire v d, il envoie périodiquement un nombre de fourmis de type Forward ant à la recherche d une route. L envoi périodique de ces paquets nous permet d une part de trouver des routes meilleures qui seront utilisées dans l envoi des paquets de données, d autre part permet la maintenance de route. Au fur et à mesure que la forward ant avance vers la destination, elle enregistre l adresse du nœud visité, la bande passante minimale, le délai de la route et sa stabilité. Chaque forward ant choisit un nouveau nœud à visiter parmi ses voisins en se basant sur une probabilité dite probabilité de transition. Cette probabilité de transition du noeud v i vers un noeud v j est en fonction d une part, de la quantité de pheromone se trouvant sur l arc (v i, v j ) et d autre part, de la visibilité locale. Cette probabilité est définie par l équation (3.10). avec : P i, j = [τ(v i, v j )] α [η i, j ] β k M [τ(v i, v k )] α [η i, k ] β (3.10) α et β : sont des paramètres qui contrôlent l importance de l intensité de la pheromone par rapport à la visibilité de la fourmi. M : est l ensemble de tous les nœuds voisins v k. τ(v i, v j ) : est la quantité de pheromone se trouvant sur l arc (v i, v j ). Elle est calculée par l équation (3.11) : Avec ρ le facteur d évaporation (0 < ρ < 1 ) τ(v i, v j ) = ρ τ(v i, v j ) + τ(v i, v j ) (3.11)

Chapitre 3. Présentation de la solution 69 η i, j : est la qualité locale d un arc. Elle représente le facteur de visibilité de la fourmi. Il est donné par l équation (3.12) : η i, j = B(v i, v j ) α B + T (v i, v j ) α T D(v i, v j ) α D (3.12) où α B, α T et α D sont des poids montrant l importance relative de chacune des métriques prises en compte dans le choix de la route R. Pour chaque nœud k choisi, la fourmi vérifie si elle l a déjà visité. Si c est le cas, alors il y a un cycle qu il faut éviter en supprimant tous les noeuds successeurs de k dans la liste des noeuds visités (Champ Visite du paquet Forward ant), comme le montre la figure FIG. 3.8. Ensuite, la Forward ant choisit un nouveau noeud intermédiaire en se basant sur la probabilité de transition (équation 3.10). Fig. 3.8 Suppression d un cycle de la liste des nœuds visités Si le nœud n est pas encore visité, elle vérifie si ce noeud est la destination recherchée. Si ce n est pas le cas, c est-à-dire que c est un nœud intermédiaire non déjà visité, le protocole effectue les tâches suivantes : Ajouter ce nœud à la liste des nœuds visités. Vérifier si le débit de ce lien traversé est inférieur à celui du champ Débit de la Forward ant. Affecter cette valeur à ce champ si c est le cas (Debit débit du lien). Ajouter au champ délai la valeur du délai de ce lien (Delai Delai + délai du lien). Vérifier si la stabilité de ce lien est inférieure à celle du champ Stab. Affecter cette valeur à ce champ si c est le cas (Stab stabilité du lien).

Chapitre 3. Présentation de la solution 70 Si la Forward ant atteind la destination recherchée, elle donne naissance à la Backward ant et lui transfère toutes les informations qu elle a véhiculées (débit, délai, stabilité, la liste des nœuds visités, la somme des pheromones de tous les liens). Enfin, cette Forward ant sera tuée. Pour une meilleure description de cette phase, nous donnons l organigramme de la figure FIG.3.9.

Chapitre 3. Présentation de la solution 71 Fig. 3.9 Organigramme de recherche de route Phase3 : Calcul de la quantité de pheromone à ajouter sur les liens Rappelons qu à chaque fois qu un nœud v i détecte un nouveau voisin v j, il l ajoute à sa table des voisins et initialise la valeur de la pheromone du lien (v i, v j ) à une constante C. Ensuite, cette valeur est mise à jour à chaque passage d une Backward ant, en lui ajoutant une quantité de pheromone calculée en fonction de la qualité de la route traversée par la Forward ant. Cette quantité notée τ(v i, v j ) est exprimée par l équation (3.13) :

Chapitre 3. Présentation de la solution 72 où : τ(v i, v j ) = B(R)β B + T (R)β T D(R) β D (3.13) B(R) : est la bande passante de la route R. C est la bande passante minimale de tous les liens formant R car c est une métrique concave. D(R) : est le délai de la route R. C est la somme des délais de tous les liens formant R car c est une métrique additive. T (R) : La stabilité de la route R. C est la stabilité minimale de tous les liens formant R car c est une métrique concave. β B, β T et β D sont des poids montrant l importance relative de chacune des métriques durant la mise à jour de la phéromone sur les liens de la route R. Notons que, pour respecter le principe d évaporation de la pheromone, la quantité de la pheromone sur tous les liens du réseau est périodiquement multipliée par le facteur d évaporation ρ telle que 0 < ρ < 1. La quantité de la pheromone spécifiant la qualité de la route trouvée (Somphero/nombre de sauts) est également calculée à l arrivée de la Forward ant au noeud destinataire. Cette quantité est enregistrée dans le champ Pheromone de la table de routage (FIG. 3.7 de la page 67). Phase 4 : Réponse à la Forward ant La Backward ant prend le chemin inverse de celui emprunter par la Forward ant. Elle utilise pour cela la liste des nœuds visités par la forward ant en sens inverse. Au fur et à mesure que la backward ant avance vers le noeud source, elle met à jour les tables des nœuds traversés. Une fois la Backward ant arrivée au nœud source, ce qui signifie que la route est trouvée, l émetteur peut commencer l envoi des données avec le débit adéquat de cette route.

Chapitre 3. Présentation de la solution 73 3.6 Comportement de l algorithme au niveau des différents noeuds Notre protocole est implémenté sous forme d un agent de routage s exécutant sur tous les noeuds du réseau. Plusieurs fonctions y sont implémentées comme décrit sur la figure FIG. 3.10. L invocation de ses fonctions s effectue selon la nature du noeud (nœud source, nœud destination ou nœud intermédiaire). 3.6.1 Au niveau du nœud source Selon la figure FIG. 3.10, le nœud source v s peut être demandeur de route pour envoyer des données à un nœud destinataire v d. Il peut également recevoir des Backward ants de ce dernier suite à la réception de Forward ants préalablement envoyées. L algorithme suivant décrit le comportement du nœud source dans chacun de ces deux cas : Si v s veut envoyer des données vers v d qui n est pas dans la table de routage Alors Finsi Créer des Forward ants et les envoyer à la recherche de route. Si nœud v s reçoit un Backward ant envoyé par v d Alors Finsi Mettre à jour les tables (de routage et de voisins) Tuer la Backward ant Envoyer les données

Chapitre 3. Présentation de la solution 74 Fig. 3.10 Les différentes fonctions de l algorithme au niveau des différents noeuds

Chapitre 3. Présentation de la solution 75 3.6.2 Au niveau du nœud intermédiaire Le nœud intermédiaire se comporte différemment selon la nature du paquet reçu : Si paquet reçu est un Forward ant Alors Si ce nœud Visite (noeud non déjà visité) Alors Ajouté ce nœud à la liste des nœuds visités Mettre à jour les champs de la Forward ant : Debit min(debit, débit du lien) Delai Delai + délai du lien Stab min(stab, stabilité du lien) Envoyer la Forward ant à un notre noeud choisi en fonction de la probabilité de transition (équation 3.10) Sinon Supprimer le cycle et envoyer la fourmis vers un autre nœud selon la probabilité de transition Finsi Sinon Si paquet reçu est un Backward ant Alors Mettre à jour les tables (table des voisins et table de routage) Envoyer la Backward ant vers le prochain noeud de la liste Visite. Finsi Finsi 3.6.3 Au niveau du nœud destinataire A chaque fois qu un nœud reçoit un paquet Forward ant, il teste s il est le nœud destinataire. Si c est le cas, il procédera comme suit : Si paquet reçu est un Forward ant Alors Calculer la quantité de pheromone à ajouter aux arcs (formule 3.13). Créer une Backward ant

Chapitre 3. Présentation de la solution 76 Envoyer la Backward ant au noeud qui est à l entête de Visite Tuer la Forward ant Finsi 3.7 Conclusion Dans ce chapitre nous avons présenté notre solution combinant un protocole de routage avec qualité de services et un mécanisme de contrôle de flux explicite dans le but de réduire les congestions et les pertes de paquets. En premier lieu nous avons mis en place un protocole de routage avec qualité de services en utilisant un système fourmis ayant la capacité de s adapter à l environnement mobile. Ce protocole consiste à rechercher des routes et à trouver le débit adéquat sur chacune de ces routes. A la réception de cette information par la source, un processus de contrôle de flux est déclenché pour envoyer les données avec un débit qui ne dépasse pas la capacité de la route trouvée. Cette solution devra améliorer les performances du réseau en réduisant les congestions et les pertes de paquets. L évaluation de la solution est faite par des simulations en utilisant le simulateur de réseau NS (Network Simulator) [107]. Le chapitre suivant présente les résultats obtenus.

Chapitre 4 Simulations et Résultats 4.1 Introduction Après avoir décrit notre solution dans le chapitre précédent, nous passons maintenant à son évaluation. La majorité des travaux d évaluation de performances utilisent le principe de la simulation vu les avantages qu il offre. En effet, l utilisation d un réseau réel dans une évaluation est difficile et coûteuse. Le réseau réel n offre pas la souplesse de varier les différents paramètres de l environnement et pose en plus le problème d extraction des résultats. Pour ces différentes raisons, nous avons choisi d implémenter notre solution sous un simulateur de réseaux. De nombreux simulateurs de réseaux ont été développés. Nous citons, par exemple, OPNET [108], GloMoSim [109], Qualnet [110] et Network Simulator 2 (NS2) [107]. Ce dernier, est le simulateur de réseaux le plus utilisé par la communauté ad hoc. Il est gratuit et son code source est disponible. Beaucoup d autres avantages le rendent le simulateur le plus largement mis à contribution par les chercheurs désireux d évaluer les performances des protocoles de routage ou d autres types de protocoles qu ils développent. NS2 est donc le simulateur de réseaux que nous avons utilisé. Dans ce chapitre, nous présentons d abord le simulateur NS2. Ensuite, nous définissons les paramètres choisis pour l évaluation de notre solution. Enfin, nous exposons les résultats obtenus ainsi que leurs interprétations. 77

Chapitre 4. Simulations et Résultats 78 4.2 Présentation de Network Simulator Network Simulator (NS2) [107] est un simulateur à événements discrets développé par le département des techniques informatiques à l Université de Berkeley en Californie. NS2 offre un moteur de simulation de réseaux pour permettre à l utilisateur de décrire un réseau et de simuler des communications entre ses différents noeuds. Il s agit d un simulateur d événements discrets orienté objet écrit en C++ avec une interface utilisateur en OTCL (Object Tool Command Language). A travers ces deux langages, il est possible de modéliser tout type de réseau et de décrire les conditions de simulation : la topologie du réseau, le type de trafic qui circule, les protocoles utilisés, les communications qui ont lieu, etc... OTCL, dérivé de TCL, est un langage interprété qui ne demande pas de compilation. Il est principalement utilisé pour accéder aux objets à partir de l interpréteur et pour configurer des simulations (début et arrêt des évènements par exemple). Il permet une utilisation facile du simulateur, son utilisation est rapide et assez conviviale. Le langage de programmation C++ est utilisé pour créer les classes de base et pour traiter un grand nombre de données (tel que le calcul des tables de routage, mouvement des mobiles, protocoles...). La dualité entre ces deux langages s explique par le fait que NS2 doit être d une part efficace dans la manipulation et la gestion de grandes quantités de données et d autre part rapide pour le changement de scénarii de simulation. Network Simulator offre plusieurs avantages comme : Il est open source et gratuit. Il englobe les contributions de nombreux chercheurs. Il peut être étendu à d autres modèles grâce à sa conception orientée objet et son implémentation en C++. Il est riche en modèles et en protocoles pour les deux environnements de réseaux : le filaire et le sans fil. Les résultats de simulation sont générés dans un fichier trace que l utilisateur peut exploiter.

Chapitre 4. Simulations et Résultats 79 Toute simulation sous NS2 se base sur un modèle de réseau constitué des composants suivants : Noeuds du réseau : nœuds d extrémités où le trafic est généré ou consommé, ainsi que les noeuds de routage (nœuds intermédiaires). Liens de communication entre ces noeuds. Agents de communication, représentant les protocoles de niveau transport (TCP, UDP). Ces agents sont attachés aux noeuds et connectés l un à l autre pour permettre l échange de données. Applications qui génèrent le trafic de données et se servent des agents de transport. 4.3 Implémentation de la solution Pour l implémentation de notre solution, nous nous sommes inspirés des étapes décrites dans [111] permettant l ajout d un nouveau protocole de routage au simulateur NS2. Nous nous sommes aussi inspirés du code source du protocole AODV [16] implémenté sous ce simulateur. Notre nouveau protocole est implémenté sous la version 2.31 du simulateur NS2 autour d un certains nombre de fichiers : 1. Le fichier principal nommé antrouting.cc contient l implémentation des timers, des Tclhooks (code qui permet de créer des liens entre les composants C++ et ceux d OTCL) et toutes les fonctionnalités (procédures) de l agent de routage telles que : send hello pkt() et recv hello pkt() : permettant l envoi et la réception des paquets hello entre les voisins. send pkt request route() et recv pkt request route() : permettant l envoi et la réception des paquets fourmis à la recherche d une route (Forward ant). send pkt reply() et recv pkt reply() : permettant l envoi et la réception des paquets fourmis en réponse aux Forward ants (Backward ants). Forward data() : permettant l envoi des données d une source à la destination une fois qu une route est trouvée.

Chapitre 4. Simulations et Résultats 80 2. Les structures des différents paquets utilisés (Forward ant, Backward ant et Hello) sont définies dans le fichier antrouting pkt.h. 3. L implémentation de la table de routage et de la table des voisins est faite dans antrouting rtable.cc. 4. Enfin dans le fichier Bandwidthestimation.cc nous avons implémenté les différentes fonctions qui permettent l estimation de la bande passante. Pour obtenir le paramètre de l occupation du canal (formule 3.6), nous avons été amenés à modifier les fichiers mac-802.11.cc et mac-802.11.h du répertoire mac de NS2. 5. Pour l estimation de la stabilité nous avons ajouté une fonction dans le fichier mobilenode.cc. Une fois les fonctions du protocole implémentées, des changements sont nécessaires pour intégrer ce nouveau protocole dans le simulateur. Ces changements concernent plusieurs fichiers : common/packet.h, trace/cmu-trace.h, trace/cmu-trace.cc, tcl/lib/ns-packet.tcl, tcl/lib/ns-default.tcl, tcl/lib/ns-lib.tcl, queue/priqueue.cc. Enfin, on doit ajouter à Makefile tous les fichiers objets (.o) correspondant aux fichiers que nous avons implémenté pour pouvoir compiler le code de NS2 en tenant compte de toutes ces ajouts et modifications. 4.4 Environnement de simulations Toutes nos simulations sont effectuées dans un réseau formé de 60 noeuds où chaque noeud est placé initialement d une manière aléatoire dans une surface de 1000m X 1000m. Tous ces noeuds sont coopératifs et disposent d horloges synchronisées. Initialement, ces noeuds ont tous la même quantité d énergie (100 J) qui diminue à chaque réception et transmission de paquets (l énergie de transmission d un paquet est de 0.9 W et l énergie de réception d un paquet est de 0.7 W). Initialement tous les nœuds sont supposés complètement chargés et ont une autonomie d une heure. Le trafic utilisé est un trafic CBR où chaque paquet a une taille de 512 octets. La durée des simulations est de 300s.

Chapitre 4. Simulations et Résultats 81 4.5 Les métriques de performance Nous avons évalué notre solution en utilisant les métriques de performance suivantes : Le délai moyen de bout-en-bout : c est la moyenne des différences entre le temps d arrivée d un paquet de données à sa destination et le temps de son émission par le nœud source, pour tous les paquets de données bien reçus dans le réseau. Taux de réception de paquets : c est le rapport entre le nombre total de paquets bien reçus par les destinations et le nombre total de paquets envoyés par les sources. L énergie moyenne consommée : c est l énergie moyenne consommée par tous les nœuds du réseau. 4.6 Simulation : résultats et interprétations Après cette phase d implémentation de la solution sous NS2.31, nous avons développé un script TCL permettant de configurer et d exécuter les différentes simulations. Les résultats de chaque simulation sont enregistrés dans un fichier trace (.tr) spécifié dans le script TCL. Pour exploiter et filtrer les résultats voulus nous avons écrit des scripts AWK. Pour évaluer notre protocole nous l avons comparé à AODV [16] et QoS-AODV [40]. Pour étudier l effet de l ajout du processus de contrôle de flux au protocole QoS que nous avons développé, nous avons simulé les deux cas suivants : Le protocole sans la procédure de contrôle de flux et, Le protocole avec la procédure de contrôle de flux. Nos simulations sont réalisées en utilisant IEEE802.11 pour la couche MAC et Random Waypoint Model [112] comme modèle de mobilité des nœuds. Dans ce dernier, un nœud mobile commence par séjourner dans un endroit pendant une certaine période de temps dite temps de pause. Une fois cette période terminée, le nœud se déplace vers une destination choisie aléatoirement et avec une vitesse de déplacement choisie dans l intervalle [minspeed, maxspeed]. Une fois cette destination atteinte, il reste immobile pendant le temps de pause spécifié, puis réitère le processus.

Chapitre 4. Simulations et Résultats 82 4.6.1 Ajustement des paramètres du protocole Les premières simulations ont pour but d ajuster les paramètres de l algorithme. Parmi ces paramètres nous avons : Les paramètres Alpha (α) et Beta (β) qui contrôlent l importance relative de la phéromone par rapport à la visibilité des fourmis (Forward ant) dans le choix du saut suivant. Le taux d évaporation de la phéromone rho (ρ). Le nombre de fourmis à la recherche de routes. 4.6.1.1 Impact de α et β sur le taux de réception de paquets Les premières simulations ont pour but d ajuster les paramètres α et β qui contrôlent respectivement l importance relative des traces de phéromones et la visibilité des fourmis. Dans ces simulations, la valeur du paramètre ρ est fixée à 0,5. Nous avons varié ces deux paramètres entre 0.1 et 0.9. Ces paramètres étant opposés, nous avons calculé le taux de réception de paquets en fonction de (α β). La figure FIG. 4.1, montre que plus ces valeurs sont proches l une de l autre, plus on a de meilleurs taux de réception. Le meilleur taux obtenu avoisine les 81 %. Pour cela, dans les simulations suivantes on fixe les valeurs de α et β à 0.5.

Chapitre 4. Simulations et Résultats 83 Fig. 4.1 Variation du taux de réception de paquets en fonction de α et β 4.6.1.2 Impact du facteur d évaporation ρ sur le taux de réception de paquets Les deuxièmes simulations ont pour but de trouver une valeur optimale pour le facteur d évaporation ρ ; La valeur pour laquelle on aura un meilleur taux de réception de paquets. Pour cela nous avons pris les valeurs de ρ dans l intervalle [0.. 1]. Les valeur de α et β sont fixées aux meilleures trouvées dans les simulations précédentes (soit α = β = 0,5). La figure FIG. 4.2, montre que le meilleur taux de réception de paquets est obtenu quand les valeurs du paramètre ρ se situe entre 0.2 et 0.4. Soit un taux de réception de 84,99 %. Une valeur plus petite induit une évaporation rapide de la phéromone. Dans ce cas les fourmis n auront pas le temps d exploiter les meilleures routes trouvées. Par contre une valeur plus grande induit accumulation trop rapide des phéromones (évaporation lente de la phéromone). Dans ce cas il y a le risque d une convergence prématurée. Pour cela, nous avons fixé ρ à 0.3.

Chapitre 4. Simulations et Résultats 84 Fig. 4.2 Variation du taux de réception de paquets en fonction de ρ 4.6.1.3 Impact du nombre de fourmis sur le taux de réception de paquets Dans ces simulations, nous avons varié le nombre de fourmis à la recherche de routes et nous avons calculé à chaque fois le taux de réception de paquets correspondant. Selon la figure FIG. 4.3 nous remarquons qu au début avec la croissance du nombre de fourmis de 1 à 5, le taux de réception de paquets augmente. Entre 5 et 7 fourmis on a une légère stabilité du taux de réception de paquets. Mais au-delà, de 7 fourmis le taux de réception de paquets décroît au fur et à mesure que ce nombre de fourmis augmente. Cela s explique par le fait que ces fourmis surcharge le réseau, ce qui entraîne toutes ces pertes de paquets.

Chapitre 4. Simulations et Résultats 85 Fig. 4.3 Effet du nombre de fourmis sur le taux de réception de paquets. 4.6.2 Etude des performances de notre protocole 4.6.2.1 Impact du nombre de noeuds sources sur le taux de réception de paquets Dans ces simulations, nous étudions l impact de la charge du réseau (nombre de sources) sur le taux de réception de paquets. Pour cela, nous avons varié le nombre de sources de 1 à 60 dans un réseau de 60 nœuds se déplaçant à une vitesse inférieure à 10 m/s. La figure FIG. 4.4 montre les résultats obtenus. D après cette figure, nous remarquons que les trois protocoles donnent un meilleur taux de réception de paquets quand le nombre de sources est inférieur à 20. Mais au-delà de cette valeur, le taux de réception de paquets diminue. Cela peut s expliquer par le fait que quand le nombre de sources excède 20, le réseau devient de plus en plus surchargé provoquant ainsi des pertes de paquets. Toutefois, nous constatons que notre protocole présente un meilleur taux de réception comparativement à AODV. Ce que nous pouvons expliquer par le fait que notre protocole réduit les congestions et les changements fréquents de routes car il choisit les routes ayant une plus grande bande passante, un délai minimum et une plus grande stabilité (une longue durée de vie). En

Chapitre 4. Simulations et Résultats 86 Fig. 4.4 Impact du nombre de noeuds sources sur le taux de réception de paquets. conséquence, les pertes sont réduites donc le taux de réception augmente. La figure FIG. 4.4 montre également que les résultats sont meilleurs dans le cas où le processus de contrôle de flux est appliqué. Cela s explique par le fait que les débits de transmission ne dépassent jamais la capacité des liens ce qui évite les goulets d étranglement causant de pertes de paquets. 4.6.2.2 Impact de la mobilité des noeuds sur l énergie moyenne consommée D après les résultats de la figure FIG.4.5 nous constatons que plus les noeuds se déplacent avec une grande vitesse, plus l énergie consommée devient importante pour tous les protocoles (AODV et notre protocole, avec ou sans le contrôle de flux). Cependant, AODV consomme plus d énergie comparativement à notre protocole. Cela s explique par le fait que plus les noeuds se déplacent rapidement plus les ruptures de routes sont fréquentes et cela induit beaucoup de pertes de paquets. La retransmission de ces paquets et la diffusion des paquets de contrôle pour la recherche d une nouvelle route consomment beaucoup d énergie. Par contre, notre protocole ne se base pas sur la diffusion de paquets pour la recherche de route ; chaque paquet de contrôle est envoyé vers un seul voisin choisi selon

Chapitre 4. Simulations et Résultats 87 la probabilité de transition. En plus, notre protocole choisit à chaque fois les routes les plus stables, ce qui conduit à moins de pertes de paquets, donc moins de retransmissions de paquets de données. Puisque le protocole avec contrôle de flux adapte son débit de transmission aux capacités des routes, les pertes de paquets sont réduites. Ce qui réduit les retransmissions de paquets et par conséquent moins d énergie sera consommée. Fig. 4.5 Impact de la mobilité sur l énergie moyenne consommée. 4.6.2.3 Effet du temps de pause sur le taux de réception de paquets Dans ces simulations nous avons calculé le taux de réception de paquets en fonction du temps de pause des nœuds. Ce dernier prend ces valeurs comme suit : 0, 25, 50, 100, 150, 200, 250 et 300s. Deux ensembles de simulations sont effectués sur un réseau de 60 nœuds dans une surface de 1000m 1000m. Dans le premier ensemble nous avons varié la vitesse de déplacement des nœuds entre 1m/s et 2m/s et dans le deuxième ensemble la vitesse des nœuds varie entre 3m/s et 10m/s. Les deux figures FIG.4.6 et FIG.4.7 illustrent les résultats obtenus. La figure FIG.4.6 montre que plus le temps de pause augmente, ce qui signifie que les nœuds se déplacent peu, le taux de réception de paquets augmente pour les trois protocoles.

Chapitre 4. Simulations et Résultats 88 Fig. 4.6 Simulation de 60 noeuds avec 1m/s vitesse 2m/s Pour QoS-AODV ce taux est aux environ de 82 %. Notre protocole (avec et sans le contrôle de flux) présente de meilleurs résultats. Le protocole sans le contrôle de flux a un taux de presque 85 % et celui avec le contrôle de flux est aux environ de 90 %. Cette amélioration est due au fait que dans notre protocole les routes choisies sont celles qui offrent plus de bande passante et ayant une grande stabilité (une longue durée de vie). Cela réduit les congestions et les fréquentes déconnexions. En conséquence, les pertes sont réduites, donc le taux de réception augmente. Les résultats sont encore meilleurs dans le cas où le processus de contrôle de flux est intégré car les débits de transmission ne dépassent pas la capacité des liens formant la route en terme de débit La figure FIG.4.7 montrent les résultats de simulations dans le cas où la vitesse des nœuds est choisie entre 3m/s et 10m/s. Les courbes de cette figure prennent la même allure que ceux de la figure FIG.4.6 ; plus le temps de pause augmente, le taux de réception de paquets augmente aussi pour les trois protocole. Mais comparativement aux résultats de la figure FIG.4.6, nous notons dans la figure FIG.4.7 une dégradation de performance. Cela est principalement dû à l augmentation de la vitesse de déplacement des nœuds. 4.6.2.4 Effet du temps de pause sur le délai de bout en bout La figure FIG.4.8 montre que le délai de bout en bout augmente avec l augmentation de la mobilité (diminution du pause time). Pour un pause time nul, c est-à-dire que les

Chapitre 4. Simulations et Résultats 89 Fig. 4.7 Simulation de 60 noeuds avec 3m/s vitesse 10m/s nœuds sont en mouvement continuel, le délai atteint ses plus grandes valeurs pour les trois protocoles. Mais quand les nœuds prennent plus de pause, ce délai diminue jusqu à atteindre des valeurs minimales quand les nœuds ne bougent plus (pause time =300sec). La figure FIG.4.8 montre que le délai moyen de bout en bout de QoS-AODV est plus important que celui de notre protocole. Cela s explique par le fait que QoS-AODV ne dispose que d une seule route à un moment donné. Donc en cas de rupture de cette route, les paquets attendent jusqu à ce qu une nouvelle route soit trouvée. Notre protocole (avec ou sans le contrôle de flux) améliore ce délai pour diverses raisons : A tout moment une fourmi peut revenir avec une nouvelle route, Les routes choisies sont à chaque fois celle ayant un délai minimum sur tous les liens formant la route, Les routes choisies sont celles ayant une durée de vie plus importante, ce qui évite le temps recherche d une nouvelle route. Nous constatons aussi que le délai de notre protocole avec contrôle de flux est légèrement meilleur, cela revient au fait que les sources transmettent toujours à un débit ne dépassant pas les capacités des liens ; ce qui évite la saturation des files d attentes.

Chapitre 4. Simulations et Résultats 90 4.7 Conclusion Fig. 4.8 Délai moyen de bout en bout vs Temps de pause Après avoir implémenté la solution proposée sous le simulateur de réseau NS2, nous avons effectué un ensemble de simulations. Les premières nous ont permis l ajustement des paramètres de l algorithme proposé. Ensuite, nous avons consacré un ensemble de simulations pour l évaluation des performances de cette solution. A travers ces simulations, nous avons remarqué que notre protocole de routage avec qualité de services permet une augmentation de performance par rapport à Qos-AODV. Nous avons, ensuite, effectué d autres simulations en ajoutant le processus de contrôle de flux explicite au protocole précédent. Ces simulations montrent que l intégration de ce mécanisme de contrôle de flux donne de meilleurs résultats.

Conclusion et perspectives Dans cette thèse nous avons étudié le problème de contrôle de flux dans les réseaux mobiles ad hoc. L idée fondamentale a été de proposer une solution adaptative permettant de réduire les congestions et les pertes de paquets. Dans les MANETs, le routage a été le problème le plus largement traité. Néanmoins, d autres problèmes suscitent l intérêt des chercheurs car ils peuvent avoir de grandes influences sur le bon fonctionnement de ces réseaux. Parmi ces problèmes la congestion qui peut causer l écroulement total du système. Cette congestion est principalement dûe au manque de ressources telle que la bande passante. Dans les réseaux filaires, le protocole TCP garantissant le contrôle de flux a prouvé son efficacité. Il régule implicitement le débit de transmission suite aux pertes de paquets, généralement résultées par des congestions. Malheureusement, dans les réseaux sans fil notamment les MANETs, plusieurs défis lui font face. Il se trouve incapable de distinguer entre les pertes qui sont dues aux congestions et celles dues aux caractéristiques de ces réseaux. Pour cela, beaucoup de travaux ont été proposés pour améliorer son comportement et l adapter à l environnement sans fil. Dans cette thèse notre objectif n est pas de suivre la même direction, mais plutôt de proposer une nouvelle solution permettant de réduire les congestions et les pertes de paquets en régulant de manière explicite le débit de transmission. Ce choix a été motivé par le fait que certains chercheurs ont prouvé que le contrôle de flux explicite est le mieux adapté aux environnements sans fil. Après l état de l art sur les réseaux mobiles ad hoc, nous avons constaté qu il y a plusieurs facteurs permettant de réduire les congestions et les pertes de paquets. En effet le routage, par exemple, peut être un bon remède aux congestions. Pour cela, la solution 91

Conclusion et perspectives 92 que nous avons proposée consiste en premier lieu en un protocole de routage avec qualité de service. Ce dernier utilise trois paramètres : la bande passante, le délai de transmission et la stabilité. Nous avons choisi la bande passante car elle est de plus en plus demandée par les applications et constitue une ressource rare pouvant causer de lourdes congestions si elle n est pas bien exploitée. En plus, ce paramètre nous permettra de réguler explicitement le débit de transmission d une source donnée. Nous avons aussi considéré le délai qui nous permettra de choisir les routes constituées par des nœuds non surchargés. Enfin, le dernier paramètre est la stabilité des routes. Ce dernier nous permet de choisir des routes avec une plus longue durée de vie, ce qui évite les fréquentes déconnexions et par conséquent les pertes de paquets. Pour le calcul de la durée de vie d un lien, nous avons proposé une nouvelle formule tenant compte de l énergie. Donc de manière implicite, on choisit les nœuds ayant plus d énergie, ce qui donnera une plus longue durée de vie pour tout le réseau. Ensuite, nous avons raffiné la solution en intégrant à ce protocole un mécanisme de contrôle de flux explicite permettant d ajuster le débit de transmission de paquets en fonction de la capacité de la route trouvée en terme de bande passante. Le processus de recherche de routes de ce protocole est basé sur l utilisation de système fourmis. Ce dernier est une heuristique inspirée d un domaine biologique s intéressant à l étude du comportement des fourmis. Notre solution utilise ce système pour son intélligence et sa capacité de s adapter aux changements d environnement. Cette solution proposée pour contrôler de manière explicite et intelligente le flux dans les MANETs présente les avantages suivants : le contrôle est préventif et s adapte rapidement aux changements qui surviennent. Elle fait en sorte que le débit de transmission colle toujours à la capacité disponible sur tous les liens de la route. Notre contribution dans ce travail a porté essentiellement sur deux points : le premier point porte sur l intégration du concept de routage avec celui du contrôle de flux pour assurer la réduction des congestions et les pertes de paquets au sein d un réseau ad hoc. le deuxième point porte sur la proposition d une nouvelle formule permettant le calcul de la durée de vie d un lien.

Conclusion et perspectives 93 Pour évaluer ce travail, nous avons implémenté la solution sous le simulateur de réseaux NS2. Ensuite, nous avons effectué un ensemble de simulations et nous avons présenté et interprété les résultats obtenus. Ces derniers montrent une amélioration de performances comparativement à QoS-AODV. Bien que cette solution apporte une contribution dans les réseaux ad hoc, plus particulièrement au routage avec qualité de service et au contrôle de flux, de nombreuses perspectives peuvent être tracées : Notre solution peut être améliorée en tenant compte d autres paramètres de qualité de service comme la taille de la fil d attente au niveau de chaque nœud. Il serait très intéressant d appliquer une heuristique (algorithmes génétiques par exemple) pour l ajustement des différents paramètres de simulation. Le protocole de routage avec qualité de service proposé ne cherche pas des routes admissibles, mais plutôt choisit parmi les routes disponibles, celle offrant la meilleure qualité. Alors il serait intéressant d ajouter des contraintes sur les paramètres de QoS considérés pour ne trouver que les routes admissibles. Au lieu de choisir la meilleure route parmi celles trouvées. La solution peut être améliorée en répartissant le trafic sur l ensemble de ces routes.

Bibliographie [1] Jian Liu and Suresh Singh. Atcp : Tcp for mobile ad hoc networks. IEEE Journal on Selected Areas in Communications, 19(7) :1300 1315, July 2001. [2] F.Wang and Y.Zhang. Improving tcp performance over mobile ad hoc networks with out of order detection and response. In Proceedings of 3rd ACM international symposium on Mobile ad hoc networking, MOBIHOC 02, pages 217 225, New York, NY, USA, June 2002. [3] Eitan Altman and Tania Jiménez. Novel delayed ack techniques for improving tcp performnce in multihop wireless networks. IEEE Percsonnal Wireless Communications, pages 237 250, September 2003. [4] K. Chen and K. Nahrstedt. Exact : An explicit rate-based flow control framework in manet. Technical report, Departement of Computer Science, University of Illinois at Urbana-Champaign, 2002. [5] K. Sundaresan, V. Anantharaman, H. Hsieh, and R. Sivakumar. Atp : A reliable transport protocol for ad hoc networks. In ACM Intenational Symposium on Mobile Ad hoc Networking and Computing, MOBIHOC, pages 64 75, June 2003. [6] K.Chen, K. Nahrstedt, and N. Vaidya. The utility of explicit rate-based flow control in mobile ad hoc networks. In Wireless Communications and Networking Conference, WCNC. 2004 IEEE, volume 3, pages 1921 1926, July 2004. [7] K. Wu and J. Harms. Location trace aided routing in mobile ad hoc networks. In Proceedings of the 9th Int. Conf. On Computer Communications and Networks, pages 354 359, Las Vegas, NV, USA, October 2000. 94

Bibliographie 95 [8] S.K. Das, A. Mukherjee, S. Bandyopadhyay, K. Paul, and D. Saha. Improving qualityof-service in ad hoc wireless networks with adaptive multi-path routing. In Proceeding of IEEE GLOBECOM, volume 1, pages 261 265, San Francisco,CA, USA, november 2000. [9] G. Malkin. RIP Version 2. RFC2453, IETF, Novembre 1998. [10] J. Moy. OSPF Version 2. RFC2328, IETF, April 1998. [11] Pettri Kuosmanen. Classification of ad hoc routing protocols. Finnish Defence forces, Naval Academy, Finland, Jun 2002. [12] Beigh Bilal Maqbool and M.A. Peer. Classification of current routing protocols for ad hoc networks - a review. International Journal of Computer Application, 7(8) :26 32, October 2010. [13] C. E. Perkins and P. Bhagwat. Highly dynamic destination sequenced distance vector routing (dsdv) for mobile computers. ACM SIGCOMM, page 234 244, 1994. [14] T. Clausen and P. Jacquet. Optimized Link State Routing Protocol (OLSR). RFC 3626, Octobre 2003. [15] David B. Johnson, David A. Maltz, and Yih chun Hu. The Dynamic source routing Protocol for mobile Ad Hoc Networks (DSR). IETF MANET Working Group, July 2004. [16] C.E. Perkins, E.M. Belding-Royer, and S. Das. Ad Hoc On-Demand Distance Vector (AODV) Routing. IETF RFC 3561, July 2003. [17] Jinyang Li and Y.C. Tay. Cluster Based Routing Protocol (CBRP). IETF MANET Internet Draft, August 1999. [18] Zygmunt J.Haas, Marc R. Pearlman, and Prince Samar. The Zone Routing Protocol (ZRP) for Ad Hoc Networks. IETF MANET Internet-Draft, July 2002. [19] Venugopalan Ramasubramanian, Zygmut J. Hass, and Emin Gun Sirer. Sharp : a hybrid adaptive routing protocol for mobile ad hoc networks. In Proceedings of

Bibliographie 96 the 4th ACM international symposium on mobile ad hoc networking and computing, MobiHoc 03, pages 303 314, Annapolis, Maryland, USA, 2003. ACM. [20] Prince Samar, Mark R. Perlman, and Zygmut J. Hass. Independent zone routing : an adaptive hybrid routing framework for ad hoc wireless networks. IEEE/ACM transactions on Networking, 12(4) :595 608, August 2004. [21] Ben Liang and Zygmut J. Hass. Hybrid routing in ad hoc networks with a dynamic backbone. IEEE Transactions on Wireless communications, 5(6) :1 14, 2006. [22] Elizabeth M. Royer and Chai-Keong Toh. A review of current routing protocols for ad hoc mobile wireless networks. In IEEE Personal Communications, pages 46 55, April 1999. [23] Mehran Abolhasan, Tadeusz Wysocki, and Eryk Dutkiewicz. A review of routing protocols for mobile ad hoc networks. Ad Hoc Networks, 2(1) :1 22, 2004. [24] Rabah MERAIHI. Gestion de la qualité de service et contrôle de topologie dans les réseaux ad hoc. PhD thesis, Ecole nationale supérieure des télécommunications, France, 2004. [25] QoS Forum. QoS protocols and architectures. White paper of QoS Forum, http ://www.qosforum.com, July 1999. [26] E. Crawley, R. Nair, B. Rajagopalan, and H. Sandick. A Framework for QoS-based Routing in the Internet. IETF RFC2386, August 1998. [27] Zheng wang and Jon Crowcroft. Quality-of-service routing for supporting multimedia applications. IEEE Journal On Selected Areas In Communications, 14(7) :1228 1234, September 1996. [28] B. Wang and J. C Hou. Multicast routing and its qos extension : Problems, algorithms, and protocols. IEEE Network, 14(1) :22 36, January-February 2000. [29] R. Braden, D. Clark, and S. Shenker. Integrated services in the Internet architecture : an overview. IETF RFC 1633, June 1994.

Bibliographie 97 [30] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource reservation protocol (RSVP). IETF RFC 2205, September 1997. [31] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the differentiated services field (DS field) in the IPv4 and IPv6 headers. IETF RFC 2474, December 1998. [32] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An architecture for differentiated services. IETF RFC 2475, December 1998. [33] H. Xiao, K. G. Seah, A. Lo, and K. C. Chua. A flexible quality of service model for mobile ad-hoc networks. In Vehicular Technology Conference Proceedings,2000, VTC 2000-Spring Tokyo, IEEE : 51st, volume 1, pages 445 449, Tokyo (Japan), May 2000. [34] J.Heinanen, F. Baker, W. Weiss, and J. Wroclawski. Assured Forwarding PHB Group. IETF RFC 2597, June 1999. [35] H. Xiao, K.C. Chua, and K.G. Seah. Quality of Service Models for Ad-Hoc Wireless Network., chapter 28. ECE-ICR, Wireless Communications Laboratory, Appeared in Handbook of Ad hoc Wireless Networks, published in late 2002 by CRC Press, FL, USA, 2002. [36] Gahng-Seop Ahn, Andrew T. Campbell, Andras Veres, and Li-Hsiang Sun. Swan : Service differentiation in stateless wireless ad hoc networks. In Proc. IEEE INFO- COM 2002, pages 457 466, New York, 2002. [37] K. Chen, S. H. Shah, and K. Nahrstedt. Cross layer design for data accessibility in mobile ad hoc networks. Journal on Wireless Communications, 21(1) :49 76, April 2002. [38] Lei Chen and Wendi B. Heinzelman. A survey of routing protocols that support qos in mobile ad hoc networks. IEEE Network, 21(6) :30 38, December 2007. [39] C.E. Perkins and E.M. Belding-Royer. Quality of Service for Ad hoc Distance Vector Routing. IETF Internet Draft, November 2001. [40] Yihai Zhang and T. Aaron Gulliver. Quality of service for ad hoc on-demand distance vector routing. In Proceedings of WiMob 2005, volume 3, pages 192 196, Aug 2005.

Bibliographie 98 [41] Hakim Badis and Khaldoun A. Agha. Quality of Service for Ad hoc Optimized Link State Routing Protocol (QOLSR). IETF Internet Draft, March 2007. [42] H. Badis and K. Al Agha. Qos for ad hoc networking based on multiple-metrics : Bandwidth and delay. In IFIP MWCN 03 : Mobile and Wireless Communications Networks, Singapore, October 2003. [43] R.Sivakumar, P. Sinha, and V. Bharghavan. Cedar : a core-extraction distributed ad hoc routing algorithm. In INFOCOM 99, Eighteenth Annual Joint Conference of the IEEE Computer and Communication Societies Proccedings, IEEE, volume 1, pages 202 209, New York, NY, USA, March 1999. [44] S. Chen and K. Nahrstedt. Distributed quality-of-service routing in ad hoc networks. IEEE Journal on Selected Areas in Communications, 17(8) :1488 1505, August 1999. [45] L. Barolli, A. Koyama, and N. Shiratori. A qos routing method for ad-hoc networks based on genetic algorithm. In in Proc. 14th Int. Wksp. Database and Expert Systems Applications (DEXA 03), pages 175 179, September 2003. [46] Peng. Fu and Deyun Zhang. A heuristic and distributed qos route discovery method for mobile ad hoc networks. In 6th international conference, WAIM2005, volume 3739, pages 428 439, China, October 2005. [47] Peng. Fu and Deyun Zhang. Hybrid optimize strategy based qos route algorithm for mobile ad hoc networks. Journal of Computer Science, 2(2) :160 165, 2006. [48] Zhenyu Liu, M Z. Kwiatkowska, and C. Constantinou. A biologically inspired qos routing algorithm for mobile ad hoc networks. Internationnal Journal of Wireless and Mobile Computing (IJWMC), 2006. [49] Z. Fan. Qos routing using lower layer information in ad hoc networks. In Personal, Indoor and Mobile Radio Communications,PIMRC 2004. 15th IEEE International Symposium, volume 1, pages 135 139, September 2004. [50] J.M. Jaffe. Algorithms for finding paths with multiple constraints. Networks, 14(1) :95 116, 1984.

Bibliographie 99 [51] S. Keshav. An engineering approch to computer networking, chapter 13, page 688. adison-wesley Longman Publishing Co,Inc, Boston, Ma, USA., 1 edition, May 1997. [52] Zhenghua Fu, Xiaoqiao Meng, and Songwu Lu. How bad tcp can perform in mobile ad hoc networks. In Proceedings of the Seventh International Symposium on Computers and Communications (ISCC 02), pages 298 303, July 2002. [53] Zhenghua Fu, Benjamin Greenstein, Xiaoqiao Meng, and Songwu Lu. Design and implementation of a tcp-friendly transport protocol for ad hoc wireless networks. In Proceedings of the 10 th IEEE International Conference on Network Protocols (ICNP 02), pages 216 225, 2002. [54] Kevin Brown and Suresh Singh. M-tcp : Tcp for mobile cellular networks. ACM SIGCOMM, Computer Communications Review, 27(5) :19 43, October 1997. [55] Hari Balakrishnan, Srnivasan Seshan, Randy H.Katz, and Y.H.Katz. Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks, 1(4) :469 481, December 1995. [56] Thomas Henderson and Randy H. Katz. Transport protocols for internet-compatible satellite networks. IEEE Journal on Selected Areas in Communications, 17(2) :326 344, February 1999. [57] Thomas D. Dyer and Rajendra V. Boppana. A comparison of tcp performance over three routing protocols or mobile ad hoc networks. In Procedings of the 2nd ACM Symposium on Mobile Ad Hoc Networking and Computing (Mobihoc), pages 56 66, New York, NY, USA, October 2001. [58] M. Belkadi, M. Lalam, A. M zoughi, R. Aoudjit, M. Daoui, and K. Ait Ali. Amlioration des performances de tcp dans les manets par la technique xon/xoff. In 9me Confrence Magrbine sur les Technologies de l information, MCSEAI 06, pages 86 90, 2006. [59] J. Postel. Transmission control Protocol (TCP)-Specification. DARPA INTERNET POGRAM PROTOCOL SPECIFICATION, September 1981.

Bibliographie 100 [60] Douglas.E.Comer. Internetworking with TCP/IP : Principles, Protocols and Architectures, volume 1, chapter 13, pages 209 251. Prentice Hall, 2000. [61] Xiang Chen, Hong Zhai, jianfeng Wang, and yuguang fang. Tcp performance over mobile ad hoc networks. Electrical and Computer Engineering, 29(1) :129 134, Jnuary/April 2004. [62] H. M. El-sayed. Performance evaluation of tcp in mobile ad hoc networks,. In The Second International Conference on Innovations in Information technology (IIT05), 2005. [63] Subir Kumar Sarkar, T.G.Basavaraju, and C.Puttamadappa. Ad Hoc Mobile Wireless Networks : Principles, Protocoles, and Applications, chapter 5, pages 141 170. Taylor Francis Group, 2008. [64] V. Park and M. Corson. Temporally-ordered routing algorithm (TORA). Internet Draft draft-ietf-manet-tora-spec-04.txt, Internet Engineering Task Force, July 2001. [65] R. Braden. Requirements for Internet Hosts - Communications Layers. Internet Engineering Task Force, October 1989. [66] Kai Chen, Yuan Xue, and Klara Nahrstedt. On setting tcp s congestion window limit in mobile ad hoc networks. In Communications, ICC 03. IEEE International Conference, pages 1080 1084, Anchorage, Alaska, USA, May 2003. [67] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang, and M. Gerla. The impact of multihop wireless channel on tcp throughput and loss. In IEEE Infocom, volume 3, pages 1744 1753, San Francisco, California, USA, April 2003. [68] Kartik Chandran, Sudarshan Raghunathan, S. Venkatesan, and Ravi Prakash. A feedback based scheme for improving tcp performance in ad-hoc wireless networks. In Proc of the International Conference on Distributed Computing Systems, pages 472 479, Amsterdam, Netherland, May 1998. [69] Gavin Holland and Nitin Vaidya. Analysis of tcp performance over mobile ad hoc networks. ACM Wireless Networks, 8(2) :275 288, March 2002.

Bibliographie 101 [70] Beomjoon Kim, Yong-Hoon Choi, and Jaesung Park. Lost retransmission detection for tcp part1 : Tcp reno and newreno. In Proceedings of ECUMN 04, pages 165 174, 2004. [71] Dongkyun Kim, C.-K. Toh, and Yanghee Choi. Tcp-bus : Improving tcp performance in wireless ad hoc networks. Journal of Communications and Networks, 3(3) :1707 1713, June 2001. [72] C.-K. Toh. Associativity based routing for ad hoc mobile networks. Wireless Personal Commun. J.,(Special Issue on Mobile Networking and Computing System, 4(2) :103 139, Mars 1997. [73] S. Kopparty, S. Krishnamurthy, M. Faloutous, and S. Tripathi. Split tcp for mobile ad hoc networks. In Proceedings of the IEEE Global Communications Conference (GLOBECOM), pages 138 142, Taipei, Taiwan, November 2002. [74] Mung Chiang. Balancing transport and physical layers in wireless multihop networks : Jointly optimal congestion control and power control. IEEE Journal on Selected Areas in Communications, 23(1) :104 116, January 2005. [75] T.Goff, N.Abu-Ghazaleh, D.Phatak, and R. Kahvcioglu. Preemptive routing in ad hoc networks. In Procedings of ACM MOBICOM, pages 43 52, Rome, Italy, 2001. [76] Fabius Klemm, Srikanth V.Krishnamurthy, and Satish K. Tripathi. Alleviate effects of mobility on tcp performance in ad hoc networks using signal strength based link management. In Proceedings of the Personal Wireless Communications, pages 611 624, Venise, Italy, September 2003. [77] Alaa Ghaleb-Seddik. TCP Performance Study and Enhancements within Wireless Multi-hop Ad Hoc Network Environments. PhD thesis, Université d EVRY-VAL D ESSONNE, March 2009. [78] Beizhong Chen, Marsic. I, Huai-Rong Shao, and Miller.R. Improved delayed ack for tcp over multi-hop wireless networks. In Wireless Communications and Networking Conference, WCNC 2009. IEEE, pages 1 5, April 2009.

Bibliographie 102 [79] Foez ahmed, Sateesh Kumar Pradhan, Nayeema Islam, and Sumon Kumar Debnath. Performance evaluation of tcp over mobile ad-hoc networks. International Journal of Computer Science and Information security, 7(1) :140 146, 2010. [80] Jian Liu and Suresh Singh. Atp : Application controlled transport protocol for mobile ad hoc networks. In WCNC 99 :Proceedings of the IEEE Wireless Communications and Networking Conference, volume 3, pages 1318 1322, September 1999. [81] Yang Su and Thomas Gross. Wxcp : Explicit congestion control for wireless multihop networks. In IWQoS 05 : Proceedings of the 12th of the International Workshop on Quality of Service, pages 309 322, June 2005. [82] D. Katabi, M. Handley, and C. Rohrs. Congestion control for high bandwidth-delay product networks. In Proccedings of the ACM SIGCOMM, pages 89 102, Pitsburgh, PA, USA, August 2002. [83] G. Anastasi, E. Ancillotti, M. Conti, and A. Passarella. Tpa : a transport protocol for ad hoc networks. In Proceedings of the 10th IEEE Symposium on Computer and Communications (ISCC 2005), pages 51 56, June 2005. [84] William Su, Sung-Ju Lee, and Mario Gerla. Mobility prediction in wireless networks. In IEEE MILCOM, volume 1, pages 491 495, Los Angeles, CA, October 2000. [85] E. Bonabeau and G. Théraulaz. L intelligence en essaim. Pour la science N 271, pages 66 73, May 2000. [86] M. Dorigo and L.M Gambardella. Ant colony system : a cooperative learning approach to the travelling salesman problem. IEEE Transaction on Evolutionary Computation, 1(1), 1997. [87] I. Alaya, C. Solnon, and K. Ghedira. Optimisation par colonies de fourmis pour le problème du sac à dos multi-dimentionnel. Techniques et Sciences Informatiques (TSI), 26(3-4) :371 390, 2007. [88] Y. Tian, J. Song, D. Yao, and J. Hu. Dynamic vehicle routing problem using hybrid ant system. In In IEEE Intelligent Transportation Systems, volume 2, pages 970 974, 2003.

Bibliographie 103 [89] Zhenyu Liu, Marta Z. Kwiatkowska, and Costas Constantinou. A biologically inspired qos routing algorithm for mobile ad hoc networks. Internationnal Journal of Wireless and Mobile Computing (IJWMC), 2006. [90] Shaveta Malik. Performance comparison between ant algorithm and modified ant algorithm. International Journal of Advanced Computer Science and Application (IJACSA), 1(4) :42 46, October 2010. [91] M. Dorigo and A. Colorni. The ant system : Optimisation by a colony of cooperating agents. IEEE Transactions on Systems, Man, and Cybernitics-part B, 26(1) :29 41, 1996. [92] C. E. Bichot. Optimisation du découpage de l espace aérien par colonie de fourmis. Technical report, Ecole Doctorale Systèmes (EDSYS, CENA/ENAC), 2004. [93] P. Deepalakshmi and S. Radhakrishnan. Ant colony based qos routing algorithm for mobile ad hoc networks. International Journal of Recent trends in Engineering, 1(1) :459 462, May 2009. [94] K. Saleem, N. Fisal, S. Hafizah, S. Kamilah, and Rozeha A. Rashid. Ant based self-organized routing protocol for wireless sensor networks. International Journal of Communication Networks and information security (IJCNIS), 1(2) :42 46, August 2009. [95] M. Daoui, M. Lalam, A. M zoughi, M. Belkadi, and R. Aoudjit. Mobility prediction based on an ant systemes. Elsevier Computer Communication, 31(14), September 2008. [96] M. Daoui, M. Lalam, A. M zoughi, B. Djamah, M. Belkadi, and R. Aoudjit. Forcasting Models Methods and Applications, chapter Mobility Prediction in Cellular Networks, pages 221 232. i-concepts press, 2010. [97] Samarth H.Shah, Kai Chen, and Klara Nahrstedt. Available bandwidth estimation in ieee 802.11 based wireless networks. In Proceedings of the first ISMA/CAIDA Bandwidth Estimation workshop(best 2003), SansDiego, California, USA, December 2003.

Bibliographie 104 [98] M. Kazantzidis and M. Gerla. End-to-end versus explicit feedback measurement in 802.11 networks. In Proceedings of the Seventh IEEE Symposium on Computers and Communications, ISCC 02, pages 429, Washington, DC, USA, July 2002. [99] Q. Xue and A. Ganz. Ad hoc qos on-demand routing (aqor) in mobile ad hoc networks. ACDEMIC PRESS : Journal of Parallel and Distributed Computing, 41 :120 124, June 2003. [100] A. Munaretto, H. Badis, K. AL agha, and G. Pujolle. A link-state qos routing protocol for ad hoc networks. In In IEEE MWCN 02 : International Workshop On Mobile and Wireless Communications Networks, pages 222 226, Sweden, September 2002. [101] S.-T. Sheu and J. Chen. A novel delay-oriented shortest path routing protocol for mobile ad hoc networks. In IEEE International Conference on Communications, pages 1930 1934, Helsinki, Finland, August 2001. [102] Amina Meraihi Naimi. Délai et Routage dans les réseaux ad hoc 802.11. Phd, Université de Versaille Saint-Quentin-En-Yvelines, 2005. [103] Omesh Tickoo and Biplab Sikdar. Queueing analysis and delay mitigation in ieee 802.11 random access mac based wireless networks. In INFOCOM 2004, Twentythird AnnualJoint conference of the IEEE Computer and Communications Societies, volume 2, pages 1404 1413, November 2004. [104] Kay Römer. Time synchronization in ad hoc networks. In Proceedings of the 2nd ACM international symposium on Mobile ad hoc networking and computing, Mobi- Hoc O1, pages 173 182, Long Beach, CA, USA, October 2001. ACM. [105] Bibliography on computer network time synchronization. www.ece.udel.edu/ mills/biblio.html. [106] M. Belkadi, M. Lalam, A. M zoughi, N. Tamani, M. Daoui, and R. Aoudjit. Intelligent routing and flow control in manets. Journal of Computing and Information Technology (CIT), 18(3) :233 243, September 2010.

Bibliographie 105 [107] Network simulator 2. http ://www.isi.edu/nsnam/ns/. [108] Opnet modeler. http ://www.mil3.com. [109] Global mobile information systems simulation library (glomosim). http ://pcl.cs.ucla.edu/projects/glomosim/. [110] Qualnet. http ://www.qualnet.com. [111] Francisco J. Ros and Pedro M. Ruiz. Implementing a New Manet Unicast Routing Protocol in NS2, December 2004. [112] T. Camp, J. Boleng, and V. Davies. A survey of mobility models for ad hoc network research. Wireless Communications and Mobile Computing (WCMC), 2(5) :483 502, 2002.