Vous êtes sur la page 1sur 107

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 Mr. Mustapha LALAM, Professeur au Département d’Informa-
tique 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 remer-
cie 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 à Mr. 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 à Mr. Azeddine BILAMI, professeur à l’Université de BATNA,
à Mr. Amar BALLA, professeur à l’ESI et à Mr. Mohamed BENMOHAMED , professeur
à l’Université de Constantine pour avoir accepté de participer dans le jury de soutenance.
Je remercie chaleureusement Mr. 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.
1

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.

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 v1 . . . . . . . . . . . . . . . . . . 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 Ad hoc On Demand Vector


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

OLSR Optimezed Link State Routing


OSPF Open Shortest Path First
PHB Per Hop Behavior
QdS Qualité de Service
QoS Quality of Service
QOLSR OLSR with Quatity of service
RIP Routing Information Protocol
RREQ Route REQuest
RREP Route REPlay
RERR Route ERRor
RFC Request For Comments
RSVP Resource ReSerVation Protocol
RLGAMAN Reinforcement Learning and Gentic Algorithm for MANets
RTO Retransmission Time Out
RTHC Round Trip Hop Count
RTS Request To Send
RFN Route Failure Notification
RRN Route Re-establshment Notification
RTT Round Trip Time
SWAN Service differentiation in Wireless Ad hoc Networks
SAANT Simulated Annealing and ANT colonny algorithm based qos route for manets
SS Slow Start
SSThreshold Slow Start Threshold
TCP Transport Control Protocol
TC Topology Control
TWND Transmission WiNDow
TCPDOOR TCP Detection of Out Of Order
TPSN TCP Packets Sequence Number
TORA Temporally Ordered Routing Algorithm
TCPF TCP Feedback
TPA Transpor Protocol for Ad hoc network
UDP User Datagram Protocol
Wi-Fi Wireless Fidelity
WXCP Wireless eXplicit Congestion control Protocol
XCP eXplicit Congestion control Protocol
ZRP 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 che-
min 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 com-
munications 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 desti-
nation 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 infor-
mations 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 change-
ments 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 suf-
fisantes 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 sous-
ensemble 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 no-
tera é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 mainte-
nance 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 Rou-
ting 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 appli-
cations 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 applica-
tions 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 communica-
tion 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’en-
semble 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 >) = [w1 (< u, v >), w2 (< u, v >), . . . , wn (< 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 = (v0 , v1 ,. . ., vk ) peut alors suivre une des règles de composition suivantes :
– Métrique additive : une métrique f est dite additive si :
k
X
f (R) = f (vi−1 , vi ) (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 :

k
Y
f (R) = f (vi−1 , vi ) (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
Y
=1− Stp(vi−1 , vi ) (1.4)
i=1
k
Y
=1− (1 − Ltp(vi−1 , vi )) (1.5)
i=1

– Métrique concave : Mathématiquement, une fonction f est dite concave sur un inter-
valle 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 (vi−1 , vi ), i = 1, 2, ..., k} (1.6)

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 individuel-
lement à 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 main-
tenir 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 cinquan-
taine 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 hy-
bride : 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 in-
termé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 of-
ferts 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 (Midd-
leware). Dans chaque noeud, ces deux couches partagent les informations et com-
muniquent 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 location-
based) 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’ob-
servation) 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 in-
formations 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é, se-
lon 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’ap-
plication 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 infor-
mations à 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 va-
riable 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 pro-
tocoles 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 fia-
bilité, 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 conges-
tion 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 rou-
teurs 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 indi-
cation 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 fai-
blesses, 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 rou-
teur, 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 pa-
quets 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 lors-
qu’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 du-
pliqué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 (T1 ) 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 (T2 ), l’émetteur
devrait se remettre immédiatement à l’état avant l’invocation du contrôle de conges-
tion. En effet, les auteurs donnent les périodes du temps T1 et T2 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 L1 , L2 ,
Chapitre 2. Contrôle de flux dans les MANETs 42

et L3 tel que : 

 1 Si N < L1

2 Si L1 ≤ N < L2
d= (2.1)

 3 Si L2 ≤ N < L3

4 Si N ≥ L3
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 :

avg retry − min th


mark prob = M in( , 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 in-
termé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 augmen-
tant 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 Unrea-
chable”. 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, celui-
ci 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 influen-
cer le débit de transmission des noeuds mobiles. M.Chiang [74] a proposé un al-
gorithme 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 puis-
sance 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 re-
cherchée. Une fois celle-ci est trouvée, les transmissions sont basculées sur cette nou-
velle 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 au-
teurs 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 trans-
mission 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 = Qt + Tt ) représente la somme du délai moyen d’attente du paquet dans la
file du nœud (Qt ) et le délai moyen de transmission (Tt ). 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’appli-
cation, 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 proto-
cole 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 col-
lectifs 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 en-
semble 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) :

(τi ,j (t))α · (ηi ,j )β


Pi ,j (t) = P α β
(3.1)
(i,k)∈C (τi ,k (t)) · (ηi ,k )
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 ,aj . 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) :

m
X
a
τi ,j (t + 1) = σ · τi ,j (t) + ∆τi,j (3.2)
a=1

Où :
– σ : 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]
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é (vi , vj ) ∈ V 2 , le
lien formé par les deux nœuds vi et vj . 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 (vi , vj ) un triplet : B(vi , vj ), D(vi , vj ) et
T (vi , vj ). 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 vs et arrivant à un nœud
de destination vd , 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. Ac-
tuellement, 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é incon-
tournable.
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 vi et vj ,
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 (vi , vj ).
La bande passante effective d’un paquet (BpEpacket ), de taille S bits, est calculée par
la formule (3.4) comme suit :

S
BpEpacket = (3.4)
Treception − Ttransmission
où :
– Ttransmission : est l’instant de transmission du paquet par le noeud vi
– Treception : est l’instant de réception de ce paquet par le noeud vj .
Au niveau de la couche MAC 802.11, la formule (3.4) est exprimée comme suit :

S
BpEpacket = PR (3.5)
tq + (ts + tCA + tOverhead ) × R + r=1 BT
avec tq est le temps d’attente dans les files d’attente au niveau MAC, ts est le temps de
transmission des S bits, tCA est le temps de la phase d’évitement des congestions (Conges-
tion Avoidance phase), tOverhead 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 BT est le temps de
Backoff pour la rème retransmission.
Si chaque nœud vj mesure la bande passante pour chaque paquet envoyé par vi , 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

idle-time-in-window
1−u= (3.6)
window-duration
Au final, la bande passante disponible du lien (vi , vj ) donnée par l’équation (3.3), sera
reformulée par l’équation (3.7) suivante :

idle-time-in-window
Bdi ,j = ∗ BpEw (3.7)
window-duration
Sachant que BpEw 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’estima-
tion 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 en-


traı̂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 in-
stables. Cela, engendre une augmentation de flux de contrôle pour la recherche de nou-
velles 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. Ce-
pendant, 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 vi et vj ayant respectivement (xi , yi ) et (xj , yj ) comme coordonnées, Si , Sj
comme vitesses et θi , θj comme direction (l’angle que choisit un nœud pour se déplacer)avec
0 < θi , θj < 2Π.

p
−(ab + cd) + (a2 + c2 )r2 − (ad − bc)2
T (vi , vj ) = (3.8)
a 2 + c2
où,
– r = rayon de couverture de chaque noeud.
– a = Si cos θi − Sj cos θj
– b = xi − xj
– c = Si sin θi − Sj sin θj
– d = yi − yj
D’après ces auteurs quand Si = Sj 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 (vi , vj ) 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 vi , vj formant le lien. Nous proposons donc la nouvelle formule (3.9) ci-dessous
pour le calcul de la durée de vie :

p
−(ab + cd) + (a2 + c2 )r2 − (ad − bc)2
T (vi , vj ) = M in[ , M in(E(vi ), E(vj ))] (3.9)
a2 + c2
où,
Chapitre 3. Présentation de la solution 64

Fig. 3.4 – Schématisation du mouvement d’un noeud

E(vi ) et E(vj ) représentent l’autonomie en énergie des noeuds vi et vj 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 Bi ,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 (vi , vj ) 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 ache-
miner 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 v1 .

– 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 sui-
vantes :
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 vs désire transmettre des données à un nœud destina-
taire vd , 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
vi vers un noeud vj est en fonction d’une part, de la quantité de pheromone se trouvant
sur l’arc (vi , vj ) et d’autre part, de la visibilité locale. Cette probabilité est définie par
l’équation (3.10).

[τ (vi , vj )]α · [ηi ,j ]β


Pi ,j = P α β
(3.10)
k∈M [τ (vi , vk )] · [ηi ,k ]

avec :
– α 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 vk .
– τ (vi , vj ) : est la quantité de pheromone se trouvant sur l’arc (vi , vj ). Elle est calculée
par l’équation (3.11) :

τ (vi , vj ) = ρ · τ (vi , vj ) + ∆τ (vi , vj ) (3.11)

Avec ρ le facteur d’évaporation (0 < ρ < 1 )


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) :

B(vi , vj )αB + T (vi , vj )αT


ηi ,j = (3.12)
D(vi , vj )αD
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 vi détecte un nouveau voisin vj , il l’ajoute à sa
table des voisins et initialise la valeur de la pheromone du lien (vi , vj ) à 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 ∆τ (vi , vj ) est exprimée par l’équation (3.13) :
Chapitre 3. Présentation de la solution 72

B(R)βB + T (R)βT
∆τ (vi , vj ) = (3.13)
D(R)βD
où :
– 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 vs peut être demandeur de route pour envoyer
des données à un nœud destinataire vd . 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 vs veut envoyer des données vers vd qui n’est pas dans la table de routage Alors
Créer des Forward ants et les envoyer à la recherche de route.
Finsi
Si nœud vs reçoit un Backward ant envoyé par vd Alors
Mettre à jour les tables (de routage et de voisins)
Tuer la Backward ant
Envoyer les données
Finsi
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 6∈ 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 an-
trouting 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 mobile-
node.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 diffu-
sion 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

Fig. 4.8 – Délai moyen de bout en bout vs Temps de pause

4.7 Conclusion
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 in-
fluences 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 par-
ticuliè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 Communica-
tions, 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 quality-
of-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, algo-
rithms, 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 re-
liable 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. Amlio-
ration 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 Archi-
tectures, 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 multi-
hop 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 ap-
proach to the travelling salesman problem. IEEE Transaction on Evolutionary Com-
putation, 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 net-
works. 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, Twenty-
third 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. Intel-


ligent 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.