Vous êtes sur la page 1sur 77

Centre Universitaire de Bordj Bou Arrridj

Etude de stabilit de nud


dans le protocole OLSR
Ben Mazouz Nabil
10/10/2010

REMERCIEMENTS

Je tiens remercier trs chaleureusement mon promoteur Mr Moussaoui Ali de mavoir propos ce sujet, de leur disponibilit, leur sollicitude, leur gentillesse et leur simplicit et pour avoir tout mis en uvre pour que je puisse donner le meilleur de moi-mme.

Je remercie galement les enseignants : Mr M.Abbas enseignant CUBBA, Mr M.joudi et Mr Moukhtari (de luniversit Amar Thlidji Laghouat) et Mr N.Bouchama (de luniversit de Bejaa) pour les conciles et les orientations.

Sans j'oublie les enseignants de Centre Universitaire EL Bachir El Ibrahimi de Bordj Bou Arrridj.

Enfin, mes remerciements vont ceux qui ont particips, plus ou moins indirectement ma thse.

Nabeel

ii

Ddicaces

"A tous ceux que jaime et qui maiment"

Nabeel

iii

Table des matires

Table des matires ............................................................................................................................i Liste des tableaux ...........................................................................................................................iv Table des figures .............................................................................................................................. v Introduction Gnrale .....................................................................................................................vi

I. Les Rseaux Sans Fils Ad hoc

I.1 Bref historique des tlcommunications ............................................................................. 1 I.1.1 La premire transmission arienne "moderne" .................................................... 1 I.1.2 Le fil comme support de communication ............................................................ 1 I.1.3 La communication sans fil ................................................................................... 2 I.2 Les rseaux sans fils Ad Hoc .............................................................................................. 2 I.2.1 Dfinition ............................................................................................................. 2 I.2.2 Modlisation dun rseau ad hoc ......................................................................... 3 I.2.3 Les caractristiques des rseaux Ad Hoc ............................................................. 4 I.2.4 Applications des rseaux ad hoc............................................................................ 6 I.3 Conclusion ......................................................................................................................... 6

II. Les protocoles de routage MANET

I.1 Introduction ......................................................................................................................... 7 I.2 Dfinition ............................................................................................................................ 7 I.3 Classification des protocoles de routage ............................................................................. 7 I.3.1 Les protocoles proactifs ....................................................................................... 8 I.3.2 Les protocoles ractifs ......................................................................................... 8 I.3.3 Les protocoles hybrides ........................................................................................ 8 I.4 Description de quelques protocoles de routage MANET ................................................... 9 I.4.1 Le protocole TBRPF (Topologie Dissmination Based on Reverse-Path Forwarding) ... 10 I.4.2 Le protocole DSR (Dynamic Source Routing) ..................................................... 10 I.4.3 Le protocole AODV (Ad hoc On demand Distance Vector) ................................. 11 I.4.4 Autres protocoles ................................................................................................ 11

iv

I.5 Conclusion ........................................................................................................................ 11 III. Optimized Link Stat Routing Protocol 13

III.1 Introduction .................................................................................................................... 13 III.2 Paquet OLSR .................................................................................................................. 14 III.3 Fonctionnement de protocole ......................................................................................... 15 III.3.1 Dtection de voisinage .................................................................................... 15 III.3.1.1 Message Hello .................................................................................. 16 III.3.1.2 Base d'information de voisinage ...................................................... 17 III.3.2 Technique de Relais MultiPoint (MPR) ......................................................... 17 III.3.2.1 Algorithme de calcul des MPRs ....................................................... 18 III.3.3 Gestion de topologie ........................................................................................ 19 III.3.3.1 Message TC (Topology Control) .................................................... 19 III.3.3.2 Base d'information Topologique ...................................................... 20

III.3.4 Dclaration des interfaces multiples................................................................ 20 III.3.5 Gestion de sous rseaux .................................................................................. 21 III.3.6 Calcul de routage ............................................................................................. 21 III.4 Conclusion ..................................................................................................................... 23

IV. Qualit de service dans les rseaux mobiles ad hoc

24

IV.1 Dfinition ....................................................................................................................... 24 IV.2 Objectif de routage QoS ................................................................................................. 24 IV.3 Stratgies de routage avec QoS ...................................................................................... 25 IV.4 Algorithmes de routage avec QoS.................................................................................. 26 IV.4.1 Algorithme de Wang-Crowcroft ..................................................................... 26 IV.4.2 Algorithme de Ma-Steenkiste ......................................................................... 26 IV.4.3 Algorithme de Guerin-Orda ............................................................................ 26 IV.4.4 Algorithme de Chen-Nahrsted ........................................................................ 26 IV.4.5 Algorithme d'Awerbuch et Al ......................................................................... 26 IV.5 Modle de qualit de service .......................................................................................... 26 IV.5.1 Dfinition ........................................................................................................ 26 IV.5.2 Les modles standard existants ...................................................................... 27 III.5.2.1 IntServ (Services Intgrs) .............................................................. 27 III.5.2.2 DiffServ (Services Diffrencis) ..................................................... 29 III.5.2.3 FQMM (Flexible Quality of service Model for MANETs) .................... 31 III.5.2.4 SWAN(Service differentiation in Stateless Wireless AdHoc Networks) . 33 III.5.2.5 iMAQ ............................................................................................... 33
v

IV.6 Systmes de Signalisation pour la QoS dans MANETs ................................................ 33 IV.6.1 INSIGNIA ....................................................................................................... 34 IV.6.2 Dynamic Qos /dRSVP..................................................................................... 34 IV.6.3 Signalisation In-Band ET Out-of-Band ........................................................ 35 IV.6.4 Maintient des rservations Soft-State Et Hard-State....................................... 35 IV.6.5 Le protocole Bruit ........................................................................................... 36 IV.7 Routage avec Qos dans MANETs.................................................................................. 37 IV.7.1 ADQR (AD hoc QoS on-demand Routing) .................................................... 37 IV.7.2 CEDAR (a Core Extraction Distributed AdHoc Routing Algorithm .................... 37 IV.7.3 LAR (Location Aided Routing) ...................................................................... 37 IV.8 Conclusion...................................................................................................................... 38

V. Introduction au la Qualit de service dans OLSR

39

V.1 Introduction ..................................................................................................................... 39 V.2 Stabilit d'itinraire .......................................................................................................... 39 V.3 Mtriques bases sur la fonction de stabilit de nud .................................................... 39 V.3.1 Stabilit de nud (SdN) .................................................................................. 39 V.3.1.1 Dfinition ........................................................................................... 39 V.3.1.2 Calcule de SdN .................................................................................. 40 V.3.1.2.1 Ingalit de Bienaym-Chebychev ..................................... 40 V.3.1.2.2 Exemple (Application numrique) .................................... 40 V.3.1.2.3 Analyse ............................................................................... 41 V.3.2 Fidlit d'un nud (FdN) ................................................................................ 41 V.3.2.1 Dfinition ........................................................................................... 41 V.3.2.2 Calcule de FdN .................................................................................. 41 V.4 Intgration dans OLSR .................................................................................................... 42 V.4.1 Extension Hello ................................................................................................ 42 V.4.2 Mcanisme de routage S_OLSR ...................................................................... 42 V.4.3 Traitement de message Hello ........................................................................... 43 V.4.3.1 Amlioration de lalgorithme de slection dMPR ........................... 43 V.4.4 Etablissement de chemin (propagation des messages TC) .............................. 44 V.4.4.1 Extension TC .................................................................................... 44 V.4.4.2 Traitement de message TC ............................................................... 44 V.5 Conclusion ....................................................................................................................... 45

VI: Simulation et discussion des rsultants


vi

46

VI.1 Introduction .................................................................................................................... 46 VI.2 Qu'est-ce que la simulation? ......................................................................................... 46 VI.3 Quand et pourquoi simuler? ........................................................................................... 47 VI.4 Les mthodes de simulation ........................................................................................... 47 VI.5 Simulation des rseaux sans fil ..................................................................................... 48 VI.6 OPNET Modeler ........................................................................................................... 49 VI.6.1 Introduction .................................................................................................... 49 VI.6.2 Pourquoi OPNET? ........................................................................................ 50 VI.6.3 La simulation sur le Modeler ......................................................................... 51 VI.6.4 Les Interfaces Principales du OPNET............................................................. 51 VI.6.5 Excution de la simulation .............................................................................. 53 VI.6.5.1 Spcification des Donnes collecter ............................................. 54 VI.6.5.2 Construction et Excution De Simulation ....................................... 54 VI.6.6 Simulation dOLSR dans OPNET ................................................................. 54 VI.6.6.1 Mtrique de performances mesures ............................................... 56 VI.6.6.2 OPNET Model Paramtres .............................................................. 56 VI.6.6.3 Complments pratiques sur Modeler .............................................. 56 VI.7 Analyse des rsultats de simulation .................................................................................... 57 VI.7.1 Mtrique de MPR Calcs ................................................................................ 57 VI.7.2 Mtrique de Route Table Calcs ...................................................................... 58 VI.7.3 Mtrique de MPR Count ................................................................................ 59 VI.8 Conclusion.................................................................................................................................. 59

Liste des tableaux


Tableau II.1: Les principaux protocoles MANET ............................................................................. 9 Tableau IV.1: Protocoles de routage avec QoS ................................................................................ 38 Tableau V.1: Calcule de stabilit de nud. ...................................................................................... 40 Tableau VI.1: Les simulateurs de rseau .......................................................................................... 51 Tableau VI.2: Les interfaces d'OPNET ............................................................................................ 53 Tableau VI.3: Les paramtres du Simulation .................................................................................. 56

vii

viii

Introduction Gnrale
ans les rseaux filaires, les ordinateurs sont connects par des cbles et se caractrisent par leurs puissances en termes de capacit de traitement et de stockage. De plus, de tels rseaux offrent une bande passante stable, de bonne qualit et peu coteuse. Au dbut des annes 90 lvolution consquente ralise dans les rseaux sans fil a fait crotre lintrt de linformatique mobile. Cette dernire offre un mcanisme de communication flexible entre les utilisateurs et un accs lensemble des services disponibles dans un environnement classique (fixe) travers un rseau Indpendant de la localisation physique (gographique) et de la mobilit de lutilisateur. Les rseaux sans fil les plus couramment dploys aujourdhui sappuient sur des infrastructures fixes : sites accueillant des stations de base dans le cas des rseaux cellulaires ou cbles pour les infrastructures filaires. La connectivit entre les diffrents lments du rseau y est organise et centralise. Les rseaux ad hoc sont des rseaux sans fil forms par des personnes ou des appareils, appels nuds, qui communiquent entre eux sans passer par une quelconque infrastructure et sans que les communications ne ncessitent une administration centrale. Les appareils en question peuvent tre aussi varis que des ordinateurs, des tlphones mobiles, des tlvisionsetc. Chaque nud du rseau est quip dune interface radio qui peut tre diffrente dun nud lautre (Bluetooth, Wifi, UWB, etc.) et reste libre dintgrer ou de quitter le rseau, condition quil y ait suffisamment de nuds dans une zone. Pour rpondre un besoin, le rseau sadapte d'une manire spontane do vient la terminologie ad hoc (en latin : pour cela) et se configure de faon compltement autonome et dynamique en fonction des possibilits de connexions existantes. Lorsque les nuds des rseaux ad hoc sont mobiles, on parle de MANET (Mobile Ad hoc NETwork). La gestion de l'acheminement de donnes ou le routage, consiste assurer une stratgie qui garantit, n'importe quel moment, la connexion entre n'importe quelle paire de nuds appartenant au rseau. La stratgie de routage doit prendre en considration les changements de la topologie ainsi que les autres caractristiques du rseau ad hoc (bande passante, nombre de liens, ressources du rseauetc). En outre, la mthode adopte dans le routage, doit offrir le meilleur acheminement des donnes en respect des diffrentes mtriques de cots utilises. Le prsent travail entre dans le cadre damliore la qualit de service dans les protocoles de routage ad hoc. Notre tude offre principalement une tude prcise de protocole OLSR, puis faire une extension nomme S_OLSR dans le but doffrir la qualit de service dans ce type des protocoles.

ix

Organisation du mmoire
Le premier chapitre prsente des gnralits sur les rseaux sans fil ad hoc, leurs caractristiques, ainsi applications. Le deuxime chapitre dcrit les classifications des protocoles de routages les plus connus ainsi que les caractristiques de chaque classe. Dans le troisime chapitre nous prsenterons un tat de lart sur le protocole OLSR. Dans le quatrime chapitre nous prsenterons la notion de qualit de service, puis le routage avec la qualit de service.

Le cinquime chapitre dcrit les dtails de notre proposition. Le dernier chapitre dcrit les rsultats de simulation, comparant le protocole standard OLSR avec notre protocole S_OLSR.

Les Rseaux Sans Fils Ad hoc

Chapitre: I

Les rseaux sans fils ad hoc

I.1 Bref historique des tlcommunications I.1.1 La premire transmission arienne "moderne"
L'histoire de la tlcommunication dbute bien avant l're de l'informatique. De nombreuses civilisations ont tent de proposer des solutions permettant de communiquer au-del de la porte de la voix. On peut penser aux signaux de fume des amrindiens, aux pigeons voyageurs utiliss par les Arabes ou les Chinois avant les Europens. Cependant, ce n'est que vers la fin du XVIIIe sicle que le premier dispositif que l'on peut qualifier de " technologique " fit son apparition. Dans les annes 1790, aprs la rvolution franaise, la guerre gronde aux portes du pays et la ncessit de pouvoir communiquer sur de longues distances plus rapidement qu'en envoyant un coursier cheval se fait sentir. Un ingnieur franais, Claude Chappe (1763-1805), propose une solution qui sera baptis " tachygraphe " puis " tlgraphe " du grec TELE (loin) et GRAPHEIN (crire). La machine propose par Chappe est compose de deux bras (ou voyants) articuls autour d'un troisime. En fonction de la position de ces trois voyants, on dduit diffrents signaux qui forment un code permettant de communiquer 10 kilomtres grce une lunette longue porte. Ces voyants peuvent dcrire 196 signaux diffrents qui, utiliss dans un code connu de l'metteur et du rcepteur du message, permettent de communiquer des ordres, des vnements et toutes sortes d'informations. En 1794, plusieurs de ces dispositifs sont rpartis entre Paris et Lille afin de permettre ces deux villes de communiquer. Chaque signal est donc rpt de proche en proche de Paris Lille par les oprateurs de ce dispositif (appels les stationnaires). La premire ligne de tlgraphie arienne tait ne. Le 1er septembre 1794, la premire dpche tlgraphique est transmise avec succs entre ces deux villes [01].

I.1.2 Le fil comme support de communication


Dans les annes 1840, l'amricain Samuel Morse invente un tlgraphe lectrique simple: des piles, un interrupteur, un lectro-aimant et des fils suffisent. L'appareil de Morse, qui transmit le premier tlgramme public en 1844, ressemblait un simple commutateur lectrique. Il permettait le passage d'un courant pendant une dure prdfinie puis l'interrompait, le tout tant command avec la pression d'un doigt. Le premier rcepteur Morse tait quip d'un crayon contrl lectro magntiquement. Ce crayon imprimait des marques sur une bande de papier, fixe sur un cylindre anim par un mouvement d'horlogerie. Les marques variaient en longueur suivant la dure des impulsions du courant lectrique passant travers les fils d'un lectro-aimant et prenaient la forme visuelle de points et de traits. Par la suite, les oprateurs apprirent reconnatre directement l'oreille les traits et les points qui leur taient transmis. Son appareil fut adopt par la plupart des pays europens et des rseaux nationaux bass sur le tlgraphe de Morse virent le jour aux tats Unis, en France, en Angleterre ... En 1866, aprs plusieurs essais infructueux, le premier cble transatlantique fut install et avec lui, le premier vritable rseau mondial de tlcommunication se
1

Chapitre: I

Les rseaux sans fils ad hoc

dveloppa. Aux environs de 1940, la premire re de l'informatique moderne fit son apparition. Rapidement, l'adaptation des technologies de tlcommunications l'informatique fut rapidement incontournable. En 1957, le ministre de la dfense amricain cre l'agence pour les projets de recherche avance (ARPA). Dans ce cadre, le besoin de faire communiquer les diffrentes quipes de recherche aux quatre coins des tats Unis se fait ressentir. Ce besoin a men les chercheurs de l'ARPA crer l'ARPANET, rseau destin relier entre elles les diffrentes universits du pays, qui grce la standardisation du modle TCP /IP [02, 03], voluera vers l'Internet que nous connaissons actuellement.

I.1.3 La communication sans fil


Jusqu' la fin des annes 1980, la technologie sans fil a surtout t utilise dans le cadre de la radio, de la tlvision ou des communications rservs d'importants organismes comme l'arme. L'arrive des tlphones cellulaires GSM [04] (Global System for Mobile communication) a offert tous la possibilit de communiquer de n'importe o, avec n'importe qui. Cependant, un tel dispositif ncessite le dploiement d'une infrastructure coteuse devant assurer le relais entre les tlphones portables et le rseau tlphonique filaire.

I.2 Les rseaux sans fils Ad Hoc I.2.1 Dfinition


L'volution rcente de la technologie dans le domaine de la communication sans fil et l'apparition des units de calculs portables (les lap_tops par exemple), poussent aujourd'hui les chercheurs faire des efforts afin de raliser le but des rseaux : "Laccs l'information n'importe o et n'importe quand" Un rseau ad hoc est une collection dunits mobiles, chacune quipe dune ou plusieurs interfaces de communication sans fil. Il est aussi communment nomm MANET (Mobile Adhoc NETwork). Les rseaux ad hoc (en latin : qui va vers ce vers quoi il doit aller , cest--dire form dans un but prcis , telle quune commission ad-hoc, forme pour rgler un problme particulier) sont des rseaux sans fil capables de sorganiser sans infrastructure dfinie pralablement. Un rseau ad hoc doit tre facilement dploy, les nuds peuvent joindre ou quitter le rseau de faon totalement dynamique sans informer le rseau, et si possible sans effet de bord sur les communications des autres membres.

Chapitre: I

Les rseaux sans fils ad hoc

Un rseau ad hoc est un rseau point point (P2P), il permet deux nuds qui sont chacun porte dondes lun de lautre (condition approprie de propagation dondes radio) de rentrer en communication directement. Si les nuds dsirants communiquer ne sont pas porte dondes lun de lautre, la mise en uvre dun routage multi sauts est ncessaire afin dacheminer les paquets jusqu' leurs destinations finales [05].

Figure I.1: exemple dun rseau ad hoc.

I.2.2 Modlisation dun rseau ad hoc


Un rseau ad hoc peut tre modlis par un graphe Gt = (Vt, Et). O : Vt reprsente l'ensemble des nuds (i.e. les units ou les htes mobiles) du rseau et Et modlise l'ensemble de connexions qui existent entre ces nuds. Si e = (u,v) appartient Et, cela veut dire que les nud u et v sont en mesure de communiquer directement l'instant t .La Figure I.2 reprsente un rseau ad hoc de 8 units mobiles sous forme dun graphe.

Figure I.2: Modlisation d'un rseau ad hoc.

I.2.3 Les caractristiques des rseaux Ad Hoc


Comparativement aux rseaux fixes traditionnels, les rseaux ad-hoc permettent de rduire considrablement les cots aussi bien de dploiement que de maintenance des infrastructures grce une auto-organisation du rseau. Ils prsentent en contre partie des contraintes additionnelles :
3

Chapitre: I

Les rseaux sans fils ad hoc

topologie dynamique : les rseaux ad-hoc sont forms spontanment partir de nuds mobiles sans ncessiter lappui dune infrastructure fixe. Un nud ad-hoc est susceptible de quitter ou de rejoindre le rseau tout instant. La topologie du rseau peut donc tre fortement changeante au grs des dplacements des nuds et de leur tat de fonctionnement. Ceci a un impact sur le protocole de routage qui doit assurer une maintenance rgulire des chemins. htrognit des nuds : les nuds ad-hoc peuvent correspondre une multitude dquipements : de lordinateur portable au capteur intelligent en passant par le tlphone mobile. Ces quipements ne disposent pas des mmes proprits physiques et logicielles, mais elles doivent pourtant inter oprer pour tablir un rseau commun. bande passante limite : le support physique sans fil offre une bande passante limite qui doit tre partage entre les nuds dun mme voisinage .La bande passante disponible dpend la fois du nombre de nuds prsents dans le voisinage et du trafic de donnes transporter, indpendamment des perturbations physiques qui peuvent intervenir. contraintes dnergie : les quipements mobiles sont fortement contraints par la dure de vie limite de leurs batteries. Malgr les amliorations des batteries et des technologies de plus en plus conomes en nergie, les nuds ad-hoc sont particulirement sollicits notamment lorsquils relayent le trafic rseau pour le compte dautres nuds. Taille du rseau : Elle est souvent de petite ou moyenne taille (une centaine de nuds).Le rseau est utilis pour tendre temporairement un rseau filaire, comme pour une confrence ou en cas de catastrophes naturelles. Cependant, quelques applications de rseaux ad-hoc ncessitent une utilisation allant jusqu des dizaines de milliers de nuds, comme dans les rseaux de capteurs. scurit limite : la nature du support physique ainsi que labsence de coordination centrale rendent les rseaux ad-hoc plus vulnrables que les infrastructures fixes. Les transmissions sans fil peuvent tre aisment captures par un nud ad-hoc dans le voisinage local. Une attaque par dni de service peut tre facilement ralise par un nud malicieux en sappropriant la bande passante ou en surchargeant un nud voisin avec une quantit importante de trafic router. Dautres contraintes, concernent laccs au support, peuvent tre rajout dans le cas dun rseau mobile ad hoc bas sur un protocole daccs avec dtection de porteuse comme le Wi-Fi, savoir : le problme de la station cache et celui de la station expose. Problme de la station cache : Il sarrive que deux stations A et C se trouvent hors de portes respectives mais leurs zones de transmission ne sont pas disjointes Figure.1.3. Quand ces deux stations A et C envoient des informations la station B simultanment ceci provoque, bien videmment, une collision. Ce problme est appel problme de la station cache.
4

Chapitre: I

Les rseaux sans fils ad hoc

Figure I.3: Problme de la station cache.

Problme de la station expose : La figure suivante (Figure. 1.4) prsente un scnario typique de ce problme. En effet, supposons que les deux stations A et C peuvent entendre les transmissions de B, mais que la station A nentend pas C (et vice-versa). Supposons aussi que B est en train denvoyer des donnes vers A et que, au mme moment, C veut communiquer avec D. Selon la technique CSMA, la station C va commencer par dterminer si le support est libre. A cause de la communication entre B et A, C trouve le support occup et il retarde son envoie bien que celui-ci naurait pas caus de collision.

Figure I.4: Problme de la station expose.

Le dveloppement des rseaux ad-hoc repose essentiellement sur la standardisation de protocoles de routage ad-hoc adapts ces caractristiques.

I.2.4 Applications des rseaux ad hoc


Les rseaux ad hoc prsentent un intrt important dans des environnements sans infrastructure. Les militaires les utilisent sur des champs de batailles pour tablir des connexions entre les diffrentes units mobiles. Ils peuvent galement tre utiliss par les organisations des secours aprs une catastrophe naturelle o toutes les infrastructures de communication ont t dtruites, etc. Cependant, les rseaux Ad Hoc commencent tre dploys pour des applications plus classiques comme les confrences, ainsi ltablissement de petits rseaux sans fil de bon march... . On peut conclure que plus les performances des rseaux ad hoc samliorent, plus leur utilisation pourrait se dvelopper et les
5

Chapitre: I

Les rseaux sans fils ad hoc

applications de ce type de rseau se diversifier [06].

Conclusion
Lvolution rapide de la technologie de tlcommunication sans fil, a permet la manipulation de linformation travers des units de calculs portables. Ces units ont des Caractristiques particulires et accdent au rseau travers une interface de communication sans fil. La mobilit et le nouveau mode de communication utilis, engendrent de nouvelles caractristiques propres lenvironnement mobile. Ces caractristiques nous obligent changer la vision classique aux problmes lis aux diffrentes stratgies de routage proposes pour les rseaux filaires, ces stratgies deviennent plus en plus complexes quand il sagit dun rseau ad hoc. Dans ce chapitre Nous avons spcifi les rseaux ad hoc en termes de dfinition, modlisation, caractristique, application Dans le chapitre suivant nous allons tudier le concept de routage dans les rseaux ad hoc, description et classification des quelques protocoles de routage.

II

Les protocoles de routage MANET

Chapitre: II

Les protocoles de routage ad hoc

II.1 Introduction
Les rseaux ad hoc se caractrisent par une absence d'infrastructure et de gestion centralise. Dans ce type de rseaux, chaque lment peut bien videmment mettre et recevoir des messages, mais assure galement un rle de relais de l'information afin que les messages circulent dans le rseau de proche en proche. Chaque nud du rseau doit donc possder des capacits de routage, c'est le routage dit ad hoc. Grce ce routage, la porte radio d'un nud peut tre virtuellement tendue en utilisant ses voisins comme relais de l'information.

II.2 Dfinition
Le routage est une mthode d'acheminement des informations la bonne destination travers un rseau de connexion donn. Le problme de routage consiste dterminer un acheminement optimal des paquets travers le rseau au sens d'un certain critre de performance. Le problme consiste trouver l'investissement de moindre cot en capacits nominales et de rserves qui assure le routage du trafic nominal et garantit sa serviabilit en cas de dfaillance de lien ou de nud.

Figure II.1: Le routage dans les MANETs.

II.3 Classification des protocoles de routage


Les propositions de routage ad hoc peuvent tre classes en deux grandes catgories: le routage proactif et le routage ractif. A ces deux familles, on ajoutera d'autres propositions plus ou moins hybrides impliquant par exemple la cration de structure interne au rseau, ou s'appuyant sur la supposition que chaque nud du rseau connat sa position dans un plan.

Chapitre: II

Les protocoles de routage ad hoc

II.3.1 Les protocoles proactifs


La particularit des protocoles proactifs est qu'ils disposent des routes immdiatement vers les destinations joignables du rseau lorsqu'ils sont sollicits. Dans un environnement mobile, ceci ncessite un maintien continuel d'informations de topologie. Cette tache est accomplie par des changes de message de contrle qui permettent de reprer tous les nuds du rseau afin de calculer les chemins selon des critres prdfinis. Parmi ces critres on peut citer le nombre de sauts sparant les nuds, le dlai, ou encore la bande passante disponible sur le chemin calcul.
La collecte des informations de topologie permet de construire une carte de rseau. Sur la base de cette carte, les nuds disposent de plusieurs routes vers la m me destination. Ceci permet de diversifier le routage et acclre une re-routage ventuel. L'inconvnient de ce type de protocole est le cot du maintien des informations de topologie et de routage mme lorsqu'il n'yen pas besoin et en absence de trafic de donnes. Le cot de maintien des informations de routage gnre une consommation continuelle de bande passante.

II.3.2 Les protocoles ractifs


Les protocoles ractifs, quant eux, ne gardent que les routes en cours d'utilisation pour le routage. A la demande, le protocole va chercher travers le rseau une route pour atteindre une nouvelle destination. La mthode classique de recherche de route consiste inonder le rseau avec une requte. Cette inondation perturbe tout le rseau puisque tous les nuds doivent rpter la requte. De plus, un problme supplmentaire se pose lors de changement de topologie : ce type de protocole est oblig de ragir rapidement pour trouver une autre alternative la route endommage. En consquence, ces mcanismes de maintenance sont lourds grer et crent des sursauts de trafic de contrle chaque tentative de recherche ou de rparation de route. Ces mcanismes entranent un dlai d'attente et une buffrisassions des paquets de donnes dus au dfaut de route.

II.3.3 Les protocoles hybrides


Les protocoles hybrides combinent les deux ides des protocoles proactifs et ractifs. Ils utilisent un protocole proactif, pour apprendre le proche voisinage (par exemple voisinage deux ou trois sauts) ; ainsi ils disposent des routes immdiatement dans le voisinage. Au-del de cette zone prdfinie, le protocole hybride fait appel aux techniques des protocoles ractifs pour chercher des routes. Avec ce dcoupage, le rseau est partag en plusieurs zones, et la recherche de route en mode ractif peut tre amliore. A la rception d'une requte de recherche ractive, un nud peut indiquer immdiatement si la destination est dans le voisinage ou non, et par consquent savoir s'il faut aiguiller ladite requte vers les autres zones sans dranger le reste de sa zone. Ce type de protocole s'adapte bien aux grands rseaux, cependant, il cumule aussi les inconvnients des protocoles ractifs et proactifs : messages de contrle priodiques, plus, le cot d'ouverture d'une nouvelle route.
8

Chapitre: II

Les protocoles de routage ad hoc

Protocoles de Routage Proactif DSDV Ractif AODV CBRP DSR SSR ABR LAR TORA RDMAR Hybride ZRP ZHLS SHARP CAMA Localisation LAR DREAM GRID CAMA GRA

WRP
GSR OLSR HSR ZHLS CGSR DREAM

GDSR

Figure II.2 : Les protocoles de routage ad hoc.

Il est possible de classer les protocoles de routage suivant trois critres [07]: le type de dissmination de linformation de contrle, la hirarchie utilise et lutilisation dinformation de localisation.

II.4 Description de quelques protocoles de routage MANET


De nombreux protocoles de routage ont t proposs pour les rseaux mobiles ad hoc. Les protocoles dcrits dans ce qui suit sont issus du groupe de travail MANET de lIETF. C es protocoles sont reprsentatifs de diverses techniques et sont les plus avancs sur la voie dune normalisation [8]. Ils font dsormais lobjet dune Request For Comment (RFC) au niveau de lIETF. Les protocoles concerns (table II.1) sont : et TBRPF (RFC 3684, fvrier 2004) [9], ainsi que les protocoles ractifs : DSR (RFC 4728, fvrier 2007) [10] et AODV (RFC 3561, juillet 2003) [11], OLSR (RFC 3626, octobre 2003) [12], ce dernier sera tudi en dtails dans le prochain chapitre. Nom Catgorie Architecture Algorithme DSR Ractifs plat Routage source plat Vecteur de distance AODV OLSR TBRP

Proactifs Hirarchique hirarchique Etat de Etat de liens liens

Tableau II.1 : les principaux protocoles MANET. 9

Chapitre: II

Les protocoles de routage ad hoc

II.4.1 TBRPF (Topologie Dissmination Based on Reverse-Path Forwarding) [9]


est un protocole de routage proactif tat de liens. Chaque nud maintient en permanence un arbre dont il est la racine et qui fournit les chemins les plus courts pour tous les autres nuds .TBRPF est constitu de deux parties complmentaires : la dcouverte des voisins et le routage proprement dit. La dcouverte des voisins est assure par un mcanisme de paquets hello diffuss rgulirement au voisinage direct. Ces paquets hello contiennent la liste des voisins du nud, et permettent ainsi de connatre rapidement la topologie complte du rseau deux sauts. Il faut noter que TBRPF emploie une technique de hello diffrentiels o seuls les changements de topologie sont notifis (diminuant ainsi la taille moyenne des paquets et autorisant leur envoi une plus grande frquence). La partie routage quant elle est base sur un change des arbres de routage entre nuds voisins, conduisant progressivement la diffusion de linformation dans lensemble du rseau. L encore seules des parties darbres sont changes. Normalement, un nud ne diffuse quun sous-arbre deux niveaux dont il est la racine. Au premier niveau apparaissent les liens vers tous les voisins directs du nud, et au deuxime niveau un unique lien vers chaque voisin deux sauts (on peut noter ici une certaine similitude avec le mcanisme des relais multi-points dOLSR). En conjonction avec ce systme de base, TBRPF peut galement ajouter des informations sur dautres liens larbre diffus, avant de ragir plus vite en cas de changement de la topologie. A noter enfin que dans un souci dconomie de bande passante, les sous -arbres et les paquets hello sont regroups autant que possible dans un mme paquet (on parle dagrgation ou piggybacking puisque lon profite des paquets hello pour envoyer en mme temps les sous- arbres) [8].

II.4.2 DSR (Dynamic Source Routing) [10] est un autre protocole ractif. Il se diffrencie
des autres en particulier parce quil pratique la source routing : lmetteur prcise dans len-tte de chaque paquet la liste des nuds quil devra traverser pour atteindre sa destination. Ce type de routage prsente certains avantages particulirement intressants ; il autorise en particulier la source conserver dans sa table de routage plusieurs chemins valides vers une mme destination. Le choix du chemin emprunt pourra donc tre fait indpendamment pour chaque paquet, et permettre un meilleur quilibrage de la charge du rseau ou une meilleure ractivit aux changements de topologie. Dans la pratique, DSR est structur en deux sous-parties complmentaires : la recherche de route et la maintenance de route. La recherche de route se fait par inondation : un paquet de recherche est diffus de proche en proch e jusqu la destination. Au fur et mesure, les identifiants des nuds traverss sont ajouts dans le paquet de recherche de route. Quand elle reoit ce paquet, la destination sait donc dj quel chemin il a emprunt, et obtient ainsi (en linversant) la route pour retourner la source. A la rception, les paquets de recherche ayant suivi des chemins diffrents, la destination rpond sur les chemins inverses, et la source aura ainsi finalement plusieurs chemins valides pour latteindre.

11

Chapitre: II

Les protocoles de routage ad hoc

II.4.3 AODV (Ad hoc On demand Distance Vector) est un protocole de routage conu
par Charles E. Perkins et Elizabeth M. Royer et spcifi dans le RFC 3561 [11]. C'est un protocole bas sur le principe des vecteurs de distance et appartient la famille des protocoles ractifs. Il reprsente essentiellement une amlioration de l'algorithme proactif DSDV [15] mais rduit l'overhead (nombre de diffusions de messages) en ne calculant les routes que sur demande (AODV). Ce protocole utilise les deux mcanismes "dcouverte de route" et "maintenance de route", en plus du routage " nud par nud " et construit les routes par l'emploi d'un cycle de requte "route request/route reply" [13]. AODV utilise le principe des numros de squence afin de maintenir la consistance des informations de routage. A cause de la mobilit des nuds dans les rseaux mobiles ad hoc, les routes changent frquemment ce qui fait que les routes maintenues par certains nuds, deviennent invalides. Les numros de squence permettent d'utiliser les routes les plus nouvelles ou autrement dit les plus fraches (fresh routes) [14].

II.4.4Autres protocoles
De nombreux autres protocoles de routage ont t proposs pour les rseaux mobiles ad hoc. Dans la catgorie des protocoles hirarchique on peut citer Cluster- Head Gateway Switcher Routing (CGSR) prsent dans [16]. Certains autres protocoles ncessitent lemploi de matriels externes, Par exemple Temporaly-Ordered Routing Algorithm (TORA) [17] a besoin que les mobiles soient synchroniss. Dautres utilisent le systme GPS pour estimer la direction gographique de la destination et ne faire intervenir quune sous -partie du rseau dans la phase de construction des routes. Alors que beaucoup de protocoles cherchent minimiser le nombre de sauts (minimum shortest path), certains protocoles enfin sattachent prendre dautres critres en considration. ABR [18] (Associativity-Based Routing) par exemple privilgie les liens les plus stables (mobiles qui restent longtemps dans le voisinage les uns des autres). SSR [19] (Signal Stability Routing) travaille partir des informations de niveau de signal et cherche maximiser la dure de vie du rseau en agissant sur la puissance dmission de chaque mobile sparment [8].

Conclusion
Si le routage dans son contexte gnral est une tche complexe, les caractristiques des MANETs rendent la conception dun protocole de routage efficace plus complexe. De nombreux protocoles de routage ont t dvelopps pour les MANETs faisant face aux contraintes spcifiques de ce type de rseaux. Ces protocoles peuvent tre classs selon plusieurs critres : leur architecture, les algorithmes utiliss, les politiques de routages, etc.

11

Chapitre: II

Les protocoles de routage ad hoc

Ltablissement des routes par ces protocoles se fait seulement suivant le critre classique : le plus court chemin ; il suffit dassurer la connectivit entre une source et une destination. Cependant ce critre nest pas du tout suffisant pour des applications comme le multimdia par exemple qui exigent des garanties particulires (la bande passante, le dlaietc.). En effet, il est ncessaire de penser dautres solution de routage optimales en termes de certains critres si nous voulons dployer de telles application dans un environnement ad hoc, on parle alors de la notion du routage avec qualit de service. Nous avons prsent dans ce chapitre un tat de lart sur les classifications des protocoles et les caractristiques spcifiques chaque classe. Dans le prochain chapitre, nous allons dtailler le protocole de routage OLSR, ces fonctionnements, les Algorithmes de (routage, de slection des MPRetc).

12

Chapitre: II

Les protocoles de routage ad hoc

III

Optimized Link Stat Routing Protocol

Chapitre: III

Optimized Link Stat Routing Protocol

III.1 Introduction
Le protocole OLSR (Optimized Link State Routing) [12] est propos au groupe de standardisation MANET de l'IETF. Le protocole OLSR appartient la famille des protocoles tat de liens. La particularit d'OLSR par rapport sa famille d'origine est l'utilisation de la topologie partielle. En d'autres termes, les nuds ne diffusent pas tous les liens qu'ils ont avec leurs voisins, mais seulement un sous-ensemble de ces liens qui permettent de les joindre. Ceci implique une rduction de la taille des paquets de contrle diffuss dans le rseau. Le protocole OLSR se base sur la technique des relais multipoint. Cette technique permet d'optimiser les diffusions des messages de contrle dans le rseau et la consommation de la bande passante. La perturbation du rseau moindre compare celle de la diffusion par inondation.

OLSR appartient la famille des protocoles proactifs. Afin de maintenir la connaissance de topologie, les nuds OLSR s'changent de des paquets de contrles priodiquement. La dtection du voisinage se fait l'aide de paquets de HELLO. La dissmination des informations de topologie quant elle se fait par la diffusion des paquets TC (Topology Control) en utilisant la diffusion optimise avec les relais multipoint. Les messages TC contiennent une liste de liens du voisinage du nud qui gnre le paquet. Ceci, permet aux autres nuds d'avoir une connaissance partielle de la topologie, mais qui est suffisante pour construire et router les paquets de n'importe quelle source vers n'importe quelle destination prsente dans le rseau, et ce, sur un plus court chemin.

Figure III.1: Exemple d'information de voisinage maintenue par OLSR.

OLSR est conu pour fonctionner dans un environnement mobile distribu sans aucune entit centrale le contrlant. Chaque nud envoie ses paquets de contrle priodiquement. Les informations extraites de ses paquets sont maintenues pendant une dure de vie limite. De cette faon, le protocole tolre d'ventuelles pertes de paquets de contrle de temps en temps. L'environnement radio y est trs vulnrable, et malgr la sophistication des protocoles d'accs la couche physique, des pertes de paquets sont toujours observes cause notamment des problmes de transmission radio et les collisions. Les expriences dans un environnement rel ont montr que les liens entre les nuds sont vulnrables aux facteurs suivants: mobilit, vanouissement de la transmission radio, obstacles, collisions dues aux nuds cachs. Ces pertes qui en rsultent, n'altrent pas le fonctionnement du protocole qui ne requiert pas le squencement et l'ordonnancement des paquets de contrle. En effet, chaque paquet de contrle possde un numro de squence. Les paquets ayant un numro de squence plus ancien que le
13

Chapitre: III

Optimized Link Stat Routing Protocol

dernier paquet reu sont simplement rejets. Le deuxime effet nocif au fonctionnement du protocole est l'existence des liens intermittents qui ne sont pas exploitables et ne permettent pas une communication entre les nuds. Ce problme a t trait avec soin et le protocole a t dot d'un mcanisme contrlant la qualit des liens avec les voisins (Link Hysteresis).

Le routage des donnes se fait saut par saut. Sur la base des informations collectes partir des paquets de contrle reus, chaque nud calcule sa table de routage. Le protocole ne manipule pas directement les paquets de donnes. C'est la couche IP qui prend en charge les paquets de donnes et les route suivant les informations contenues dans sa table de routage.

III.2 Paquet OLSR


OLSR utilise le format standard des paquets IP, et donc aucune modification n'est requise pour les piles IP. Il peut fonctionner avec toute pile IP du commerce. OLSR utilise un format de paquet unifi pour les messages de contrle. Ces paquets sont envoys dans des datagrammes UDP. Chaque paquet encapsule un ou plusieurs messages la fois. Ceci permet d'optimiser l'accs au canal physique en pargnant sur le surcot de la couche physique.

Figure III.2: Datagramme OLSR.

Les champs dans le paquet OLSR sont : Packet Length : la Taille du paquet (en-tte en octets). Packet Sequence Number : est un nombre de squence augment chaque un nouveau message OLSR est transmis par cet hte. Message type : un nombre entier identifiant le type de ce message. Les types de message de 0-127 sont rservs par OLSR pendant que le 128-255 espace est considr "priv" et peut tre utilis pour les extensions personnalises du protocole, ex (Hello_Message, TC__Message, MID_Message, HNA_Message). Vtime : Ce champ indique combien de temps aprs la rception un nud considrera l'information contenue dans le message comme valide. Message Size : la taille de ce message, en incluant l'en-tte de message (en octets). Originator Address : l'adresse Principale du crateur de ce message.
14

Chapitre: III

Optimized Link Stat Routing Protocol

Time To Live : nombre de sauts avant abandon du paquet : cette valeur est dcrmente chaque saut pour viter que les paquets ne circulent indfiniment dans des boucles de routage. Hop Count : le nombre de fois le message a t envoy. Message Sequence Number : un nombre de squence augment chaque un nouveau paquet OLSR est transmis par cet hte.

Le protocole OLSR prend en compte aussi toutes les interfaces relies un mobile. Ainsi, les nuds profitent de toutes les routes disponibles indpendamment du type d'interface utilise chaque saut. Le nud OLSR choisit une de ses adresses d'interface comme une adresse principale qu'il utilisera comme rfrence dans ses messages de contrle.

III.3 Fonctionnement de protocole


OLSR est compos essentiellement de deux entits complmentaires: La dtection du voisinage: Chaque nud procde la dcouverte de ses voisins directs et ses voisins deux sauts. Chaque nud doit aussi dsigner ses relais multipoint. La gestion de topologie: cette deuxime entit, s'occupe de l'apprentissage de la topologie globale du rseau. Cet apprentissage se fait par l'analyse des paquets de contrle contenant des informations sur la topologie locale deux sauts. Il s'agit d'une connaissance totale de tous les nuds prsents dans le rseau et une connaissance partielle des liens entre ces derniers.

Ces informations collectes sont largement suffisantes pour calculer et router les paquets de donnes vers toutes les destinations prsents dans le rseau un instant donn. OLSR utilise quatre types de messages: HELLO, TC, MID et HNA. Les messages HELLOs sont utiliss pour la dtection de voisinage. Les messages TCs servent diffuser les informations de topologie dans tout le rseau. Les messages MIDs permettent de publier la liste des interfaces de chaque nud. Quant aux messages HNAs, ils sont utiliss pour dclarer les sous-rseaux et htes (hors MANET) joignables par un nud jouant le rle de passerelle.

III.3.1 Dtection de voisinage


Chaque nud doit dtecter toutes les interfaces de ses voisins possdant un lien symtrique direct avec l'une de ses interfaces. La propagation des ondes radio peut subir des perturbations, ce qui peut rendre les liens entre deux nuds asymtriques. Afin d'viter ces cas de figure, les liens sont vrifis dans les deux sens avant de les considrer comme valides.

15

Chapitre: III

Optimized Link Stat Routing Protocol

Figure III.3: Dtection de voisinage.

Pour dcouvrir son voisinage, chaque nud doit diffuser autour de lui un message HELLO contenant les informations relatives aux interfaces que ce nud entend, ainsi que leur tat de lien. Un lien entre deux nuds peut avoir l'un des tats suivants: "symtrique ", "entendu" (asymtrique), "MPR"(relais multipoint) ou "perdu". "Symtrique", signifie que le lien a t vrifi dans les deux sens, par consquent bidirectionnel, et qu'il est possible d'envoyer des donnes en unicast sur ce lien. "Entendu" indique que le nud reoit les messages HELLO venant de cette interface voisine, mais, que le lien n'est pas encore valide dans l'autre sens. "MPR" indique que ce nud a choisi ce voisin comme relais multipoint. Implicitement, cet tat indique aussi que le lien est symtrique. "Perdu" quant lui signifie que le lien correspondant est perdu et n'est plus valide.

III.3.1.1 Message Hello:

Figure III.4: Message Hello.

Reserved" : Ce champ doit contenir "0000000000000000". Htime : Intervalle d'mission des messages Hello. Willingness : Permet de forcer le passage d'un nud en MPR. Link Message Size : La taille de ce message. Link code : Code identifiant le type de lien (pas l'information Symtrique, Asymtrique, etc.) entre l'expditeur et les interfaces listes (Neighbor Interface Address).

16

Chapitre: III

Optimized Link Stat Routing Protocol

III.3.1.2 Base d'informations de voisinage


Chaque nud maintient une base d'information pour toutes les interfaces voisines, les voisins deux sauts et les relais multipoint. Pour chaque interface voisine dtecte, le nud enregistre le tuple suivant (N_if_id, N_if_addr, N_main_addr, N_SYM_time, N_ASYM_time, N_time).

N_if_id est l'identificateur de l'interface du nud local par laquelle on a reu le message HELLO; tandis que N_if_addr et N_main_addr sont respectivement l'adresse de l'interface mettrice et l'adresse principale du voisin. N_SYM_time spcifie le temps au bout duquel ce lien n'est plus considr comme symtrique. N_ASYM_time spcifie le temps au bout duquel ce lien n'est plus considr comme asym. N_time sert liminer le tuple l'expiration. Le lien sera considr comme symtrique tant N_SYM_time est valide; au-del, si le deuxime timer N_ASYM_time est valide, alors le lien sera dclar comme asymtrique; sinon il sera annonc au voisinage ayant l'tat "perdu" jusqu' expiration du troisime timer. L'ensemble des interfaces ayant un lien symtrique avec un voisin symtrique distantes de deux sauts sont stockes dans un ensemble de tuples de la forme suivante (N_main_addr, N_if_addr, N_2hop_addr, N_time). N_main_addr et N_if_addr sont respectivement l'adresse principale et l'adresse de l'interface du voisin possdant un lien symtrique avec l'interface N_2hop_addr du voisin du deux sauts. A l'expiration du timer N _ time, ce tuple doit tre dtruit.

Le nud maintient aussi l'ensemble de ses relais multipoint MPRset. Ces relais multipoint sont choisis parmi les voisins directs un saut couvrant toutes les interfaces du second saut. Le nud tient jour aussi une autre liste dans laquelle il garde les voisin s qui l'ont choisi comme relais multipoint MPRselectorset. Le contenu de cette liste sera dclar dans les messages TC. Ces bases de voisinage sont alimentes et mises jour priodiquement par les changes des messages de HELLO.

III.3.2 La technique des relais multipoint


Le concept des relais multipoint vise rduire le nombre de retransmissions inutiles, lors de diffusion gnralise d'un message. La transmission radio est par dfaut une inondation tous les voisins. Les voisins du second niveau peuvent tre couverts par un ou plusieurs nuds du premier niveau. L'ide se rsume alors choisir le nombre de rpteurs ncessaires pour
17

Chapitre: III

Optimized Link Stat Routing Protocol

atteindre tous les nuds du second niveau d'un nud. Cet ensemble forme un arbre recouvrant et s'appelle l'ensemble des relais multipoint MPRset. Cet ensemble permet d'conomiser la bande passante et rduit le nombre de messages reus en plusieurs copies par un nud.

Figure III.5: Inondation classique et technique de Relais Multipoint.

Pour diffuser un message dans tout le rseau, chaque nud dsigne ses voisins relais multipoint qui joueront le rle de premiers rpteurs du nud central. Rcursivement et en rptant ce processus, le message diffus atteint la totalit des nuds. La particularit de cette technique est qu'elle fonctionne d'une manire totalement indpendante et distribue; chaque nud calcule ses relais multipoint en se basant sur la connaissance de son voisinage deux sauts.

Figure III.6: Exemple de diffrents tableaux maintenus par OLSR.

III.3.2.1 Algorithme de Calcul des MPRs


Le nud doit informer ses voisins de leur nouveau rle. Dans un environnement mobile avec une topologie changeante d'une manire imprvisible, l'ensemble des relais multipoint doit tre recalcul chaque fois qu'on dtecte une modification dans le voisinage deux sauts. C'est pour cette raison que le statut de relais multipoint est conditionn par le voisinage pour une dure limite. L'algorithme de slection des relais multipoint se prsente comme suit: On dsigne par N(x) l'ensemble des voisins directs de x, par N (x) l'ensemble des voisins du second niveau, et MPRset(x) tant l'ensemble des relais multipoint de x. Dbut
18
2

Chapitre: III

Optimized Link Stat Routing Protocol

{ 1. Commencer par un ensemble de relais multipoint vide MPRset (x)=. 2. Calculer le degr D(y) de chaque nud dans N(x). Le degr pour un nud (y) est le nombre des voisins du second niveau couverts par celui-ci prsent dans N (x). 3. Choisir les nuds de l'ensemble des voisins N(x) qui sont les seuls ayant un lien avec un voisin du second niveau. Ajouter ces nuds slectionns de N(x) l'ensemble MPRset (x), et liminer tous les nuds du second niveau couverts par ces derniers de 2 l'ensemble N (x). 4. Tant que N (x) n'est pas vide refaire { (a) Calculer reachability (accessibilit) R(y) de chaque nud dans N(x). "Reachability" pour un nud (y) est le nombre des voisins du second niveau couverts par celui-ci prsent dans N (x). Et qui ne sont pas encore couverts par aucun lment dans MPRset (x). (b) Ajouter le nud (y) de N(x), ayant R(y) maximal l'ensemble des MPRset (x), Si les valeurs sont le mme prend alors le nud avec le plus grand degr D(y). Enlever tous les nuds du second niveau couverts par ce nud. } Fin Tant que. } Fin.
2 2 2

III.3.3 Gestion de topologie


La dtection de voisinage permet chaque nud de communiquer avec ses voisins directs et de choisir ses relais multipoint qui lui permettent de dissminer ses informations de contrle dans le rseau. Si un nud possde plusieurs interfaces, alors, il doit envoyer ces informations de contrle sur toutes ses interfaces. Les routes sont construites en utilisant les relais multipoint et les liens directs avec les voisins.

III.3.3.1 Message TC (Topology Control):

Figure III.7: Message TC.

Reserved : Ce champ doit contenir " 0000000000000000 "

19

Chapitre: III

Optimized Link Stat Routing Protocol

ANSN (Advertised Neighbor Sequence Number) : Entier incrment chaque changement de topologie. Il permet de ne pas tenir compte des informations obsoltes, pour tenir les tables le plus jour possible. Advertised Neighbor Main Address: Adresse IP de nuds un saut. L'ensemble des nuds publis dans les messages TC est un sous-ensemble des voisins un saut. La version par dfaut recommande de publier les MPRselectorset, c'est--dire les voisins pour lesquels le nud courant est un relai MPR.

III.3.3.2 Base d'informations topologiques


Chaque nud dans le rseau maintient une base d'informations de la topologie du rseau. Ces informations sont collectes par l'analyse des messages TC reus par ce nud, qui seront utilises plus tard pour le calcul de la table de routage essentiellement. Pour chaque destination dans le rseau, le nud maintient le tuple suivant (T_dest, T_last, T_seq, T_time). T_dest est l'adresse principale de la destination, qui est un saut du nud avec l'adresse principale T_last. Autrement dit, T_last est un relais multipoint du T_dest. T_seq, est un numro de squence, et T_time est le temps au bout duquel ce tuple expire et doit tre dtruit. Tous les nuds choisis comme relais multipoint doivent diffuser priodiquement dans le rseau un message TC contenant la liste des voisins de ce dernier qui l'ont dsign. Le numro de squence associ cette liste est aussi envoy dans le message TC. La liste des adresses contenue dans le message peut tre partielle cause des limitations imposes par le rseau. Dans ce cas, plusieurs messages sont envoys pour diffuser la liste complte au cours d'une priode de rafrachissement appel TC_INTERVAL. Un nud qui n'a t choisi par aucun de ses voisins, ne devrait pas envoyer de message TC vide dans le rseau. Par ailleurs, un nud peut envoyer des messages TC supplmentaires pour ragir plus rapidement aux changements de topologie. C'est--dire quand l'ensemble des nuds ayant choisi le nud local comme relais multipoint change. Les messages TC sont diffuss dans tout le rseau en utilisant la diffusion optimise d'OLSR par l'intermdiaire des relais multipoint.

III.3.4 Dclaration des interfaces multiples


Chaque nud dans le rseau doit se souvenir des diffrentes interfaces relatives un mme nud. Ces informations sont collectes par l'analyse des messages MID mis par tout nud possdant plus d'une interface participant dans le rseau sans fil MANET.

Le nud maintient un ensemble de tuples de la forme suivante (1_if_addr, 1_main_addr,


21

Chapitre: III

Optimized Link Stat Routing Protocol

I_time) pour chaque destination possdant plus d'une seule interface. 1_if_addr est l'adresse de l'interface du nud dont l'adresse principale est I_main_addr. Ce tuple doit tre dtruit l'expiration de l'I_time. Priodiquement, les nuds possdant plusieurs interfaces, diffusent dans le rseau un message MID contenant la liste des adresses des interfaces rattaches ce nud ainsi que l'adresse principale associe. Les nuds ayant une seule interface participant un rseau MANET et d'autres interfaces relies des rseaux filaires ne doivent pas gnrer ce type de message, mais, en revanche ils doivent annoncer les adresses des sous-rseaux auxquels ils sont connects. Comme tous les messages de contrle d'OLSR, la diffusion se fait l'aide des relais multipoint. De plus, la liste complte des interfaces doit tre annonce au moins une fois au cours de la priode (MID _ INTERVAL).

III.3.5 Gestion des sous-rseaux


Un nud participant un rseau MANET peut aussi tre connect d'autres types de rseaux, tels que les rseaux filaires. Dans ce cas-ci, le nud peut jouer le rle d'une passerelle offrant l'accs aux diffrentes sources d'un type de rseau l'autre. Pour ce faire, ce nud doit pouvoir informer le reste du rseau MANET, du fait qu'il est possible de joindre tel rseau ou bien tel ou tel hte rattach ce nud. Ce cas de figure est diffrent de la dclaration des interfaces associes un nud. En effet, toutes les interfaces dclares dans les messages MID participent un rseau MANET (les nuds font tourner un protocole de routage tel qu'OLSR), tandis que dans le cas actuel, les interfaces ne participent pas un rseau MANET. Pour permettre l'accs ces rseaux et htes de l'autre ct du rseau MANET, les nuds passerelles, doivent dclarer ces associations via un autre type de message (message HNA) priodiquement. Chaque nud dans le rseau MANET doit maintenir un ensemble de tuple pour tous les nuds passerelle. Ces tuples ont de la forme suivante (GW_main_addr, NET_addr, NET_mask, GS_time). GW_main_addr est l'adresse principale du nud passerelle. NET_addr est l'adresse du sous rseau ou l'hte connect au nud passerelle suivant la valeur du masque rseau NET_mask. Ce tuple est invalid l'expiration du GS_time.

III.3.6 Calcul du routage


Chaque nud maintient une table de routage qui permet de router les donnes vers toutes les destinations prsentes dans le rseau. Le calcul de la table de routage est bas sur les informations contenues dans la base d'informations de voisinage ainsi que celui de la base de topologie tout en les combinant avec les associations des interfaces. De ce fait, chaque fois que l'une de ces bases d'informations change, la table de routage doit tre recalcule. La table de
21

Chapitre: III

Optimized Link Stat Routing Protocol

routage possde le format suivant: - R_dest1 R_next1 R_dist1 R_if _id1 - R_dest2 R_next2 R_dist2 R_if _id2 - R_destn R_nextn R_distn R_if _idn Chaque entre dans la table correspond un tuple de quatre lments: R_dest, R_next, R_dist et R_if_id. R_next est l'identifiant du prochain saut prendre pour atteindre le nud identifi par R_dest. R_if_id est l'identifiant de l'interface locale par laquelle le nud peut atteindre R_dest. R_dist est la distance estime en nombre de sauts sparant R_dest du nud local. Les entres dans la table de routage correspondent tous les nuds dont le nud local peut calculer une route valide. Les autres destinations dont la route est partiellement connue, ou possdant un lien cass, ne sont pas enregistres dans la table de routage. La table de routage est mise jour chaque fois qu'on dtecte un changement dans la base de voisinage ou de la topologie. Plus prcisment, quand on dtecte l'apparition ou bien la disparition d'un nud dans le voisinage, ou la disparition ou l'apparition d'un tuple dans la base de topologie. Cette mise jour n'entrane aucune gnration de message dans le rseau; il s'agit d'un simple re-calcul local. Le calcul de la table de routage se fait conformment la procdure suivante : Dbut { 1. Dtruire toutes les entres ultrieures de la table. 2. On insre dans la table tous les voisins directs qui sont les voisins symtriques un saut. Ces informations sont extraites de la base de voisinage. Pour chaque entre on ajoute: R_dest correspondant l'adresse principale du voisin N_main_addr dans la base de voisinage, R_next correspondant l'interface voisine N_if_addr, et R_if_id correspondant N_if_id. R_dist est naturellement initialis 1. 3. Ensuite, on insre les destinations plus de un saut (h+1). La procdure suivante est excute pour chaque valeur de h, en commenant par h=1 et en incrmentant h par 1, chaque itration. Cette boucle s'arrte lorsqu'il n'y a plus de nouvelles entres dans la table de routage. - Pour chaque tuple dans la base d'informations de topologie, si T_dest ne correspond aucun R_dest des entres de la table de routage, et T_last, correspond l'un des R_dest avec un R_dist gale h, alors, on insre une nouvelle entre dans la table de routage tel que : R_dest gale T_dest. R_next gale au R_next de l'entre dont le R_dest est gale T_last. R_dist gale h+1. } Fin. Par la suite, la table de routage est complte par l'ensemble des associations des interfaces en ajoutant des entres pour toutes les interfaces non prsentes dans la table de routage mais dont l'adresse principale associe y figure dj. Finalement, on termine par l'insertion des routes vers
22

Chapitre: III

Optimized Link Stat Routing Protocol

l'ensemble des associations des rseaux et les htes rattachs. Bien videment, l'adresse du Next_hop et la distance sont les mmes que celle de l'adresse principale qui permet de joindre ces interfaces et sous-rseaux, dans la figure suivante nous montrons les tables de routage des nuds A et E de lexemple prcdent.

Figure III.8: Table de routage des nuds A et E.

Conclusion
OLSR est le rsultat de six annes de travail dHIPERCOM, quipe de recherche de lINRIA Rocquencourt, qui a t retenu rcemment par lIETF comme un RFC [12]. OLSR se rapproche du protocole OSPF (Open Shortest Path First), tous deux sont des protocoles de type tat des liens o chaque nud diffuse son voisinage dans le rseau. Mais OLSR est tout fait adapt aux rseaux ad hoc : il peut contrler les liens entre les quipements par des paquets spciaux, les Hellos, et il est optimis pour la diffusion. Cette optimisation conomise une grande partie de la bande passante du rseau, ce qui est trs important dans des rseaux denses. Il sappuie sur le concept de relais multipoint (MPR Multipoint Relay). OLSR prsente aussi lavantage de sadapter parfaitement aux protocoles de lInternet et il autorise chaque quipement connatre la topologie du rseau tout instant. Dans le chapitre suivant nous allons tudier la notion de qualit de service, notamment le routage avec qualit de service, dans le but de faire une extension du protocole OLSR pour garantir la qualit de service.

23

IV

Qualit de service dans les rseaux mobiles ad hoc


13

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

IV.1 Dnition
QoS est un terme largement utilis ces dernires annes dans le domaine des rseaux laires, mais en vrit il ya beaucoup de dbats sur sa signication exacte. La plupart des fournisseurs mettent en uvre leurs protocoles de QoS sous des scnarios ou des hypothses bien spcis comme la topologie du rseau, le modle de mobilit, le modle de trac, etc. Limplmentation rsultante nest pas gnrale et elle peut ne pas fonctionner pour certains scnarios. Dans les recommandations E.800, le CCITT (United Nations Consultative Committee for International Telephony and Telegraphy) a dfini la QoS comme : Ensemble des effets portant sur les performances dun service de communication et qui dtermine le degr de satisfaction dun utilisateur de ce mme service. Cette dnition est la plus largement accepte puisquelle ne rfrence aucune mtrique comme la bande passante, le dlai, etc. ou un mcanisme comme le contrle dadmission, protocole de signalisation, etc. [20].

IV.2 Objectifs de routage QoS


La fonction basique du routage avec qualit de service est de chercher un tel chemin faisable qui satisfait les contraintes QoS de flux de donnes. De plus, loptimisation dutilisation des ressources de rseaux est un autre objectif important du routage avec QoS. Le problme doptimisation. Lexigence de QoS dune connexion est donne comme un ensemble de contraintes qui peuvent tre soit les contraintes de lien, soit les contraintes de chemin. Par exemple avec les contraintes de lien, la contrainte de la bande passante dun unicast connexion demande que les liens se composant le chemin doivent avoir certaines qualits de bande passante disponible, la contrainte de dlai dune multicast connexion est la contrainte de chemin. La Qos correspond des critres de performances que doit avoir le rseau pour satisfaire les besoins des utilisateurs. Ces performances correspondent diffrents paramtres mesurables sur le rseau tels que [21]: Le dlai de bout en bout: c'est le temps mis pour transfrer un paquet entre deux nuds. La gigue: c'est la variation de l'intervalle de temps entre deux paquets durant leur acheminement entre la source et la destination. La bande passante: c'est le volume total d'informations que peut absorber un lien entre deux nuds sans crer de file d'attente. La perte de paquets: c'est le nombre de paquets perdu par rapport au nombre de paquets mis.

24

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

En fonction des applications considres, le paramtre prendre en compte varie : par exemple, pour de la vido [22], les paramtres importants sont la bande passante, la gigue et le dlai ; pour un change de fichiers, il vaut mieux limiter la perte de paquets.

IV.3 Stratgies de routage avec QoS


Selon la faon de maintenir les informations de ltat du rseau et la faon de recherche des faisables chemins, le routage peut tre divis en trois catgories : 1. Le routage source. 2. Le routage distribu. 3. Le routage hirarchique. Dans le routage source, chaque nud maintient une image de ltat global du rseau, en basant sur laquelle, un chemin faisable est calcul localement chez source. Un protocole dtat des liens (link-state protocol) est utilis pour mettre jour ltat global chez chaque nud. Le routage source est facile mettre en uvre, valuer, dboguer et mettre niveau parce quil obtient la simplicit par transformer un problme distribu en celui-ci centralis. Cependant, ce type de routage a aussi ses inconvnients. La communication surcot est leve excessivement pour les rseaux grande chelle, limprcision dtat global peut causer lchec du routage avec qualit de service, le calcul de surcot la source est trop lev en particulier lorsque multiples contraintes sont demandes.

Dans le routage distribu, le calcul dun chemin est distribu parmi les nuds intermdiaires entre la source et la destination. Certains algorithmes demandent chaque nud de maintenir ltat global du rseau, en basant sur lequel la dcision du routage est faite par sautpar-saut basique. Le temps de rponse du routage peut tre plus court et plus volutive. La recherche de multiples chemins en parallle pour un faisable chemin augmente la chance de succs. Le routage distribu a le mme problme que le routage source en raison de la ncessit de partager ltat global, lorsque les tats globaux des nuds diffrents sont incompatibles, les boucles peuvent se produire. Dans le routage hirarchique, les nuds sont regroups en plusieurs niveaux de hirarchie. Chaque nud physique possde un tat agrg global. Lavantage le plus pratique du routage hirarchique est lvolutivit, parce que chaque nud maintient un tat global partiel o des groupes de nuds sont regroups en nuds logiques. Les algorithmes de routage source sont appliqus directement chaque niveau hirarchique. Le routage hirarchique contient des avantages de routage source et certains avantages de routage distribu. Mais, ltat agrg introduit limprcision qui est un impact ngatif significatif sur le routage avec qualit de service.

25

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

IV.4 Algorithmes de routages avec QoS


Nous allons prsenter des algorithmes de routage avec QoS actuels, surtout des algorithmes de routage source parce quils sont trs touchs lalgorithme choisi dans notre proposition. Les algorithmes sont abords sous le nom des auteurs. IV.4.1 Algorithme de Wang-Crowcroft : cet algorithme base sur lalgorithme Dijkstra de chemin le plus court pour chercher un chemin avec la contrainte de la bande passante et du dlai. Premirement, tous les chemins avec la bande passante qui est plus bas que celle dexigence sont limins. Donc, tous les chemins dans larbre de rsultat satisfont la contrainte de la bande passante. Deuximement, le dlai est utilis pour chercher le chemin le plus court.

IV.4.2 Algorithme de Ma-Steenkiste: au lieu de traiter toutes les contraintes, cet algorithme prend une fonction qui transforme toutes les contraintes en une seule valeur et utilise une version modlis de Bellman-Ford pour chercher un faisable chemin.

IV.4.3 Algorithme de Guerin-Orda: cet algorithme rsout le problme de routage de la bande passante et le dlai contraints dans le cas o ltat de rseau est imprcis. Le but de lalgorithme est de chercher un chemin qui a la probabilit la plus leve pour satisfaire les contraintes de bout-en-bout. Cet algorithme convient routage hirarchique.

IV.4.4 Algorithme de Chen-Nahrstedt: on a propos un algorithme heuristique pour le problme NP-complet de routage de multiples contraintes. Lide est que les cots des liens en nombre rel sont transforms aux cots en nombre entier dlimit. Puis, on utilise lalgorithme de Dijkstra ou Bellman Ford tendus. IV.4.5 Algorithme d'Awerbuch et Al: on a propos un algorithme de routage de sortiecomptitive pour des connexions de bande passante contraint. Lide gnrale est de combiner la fonction dadmission contrle avec le routage [24].

IV.5 Modle de qualit de service IV.5.1 Dfinition


Un modle de qualit de service dcrit un ensemble de services bout-en-bout, qui permettent aux clients de slectionner un nombre de garanties qui gouvernent des proprits telles que le temps, lordonnancement et la fiabilit. Le modle de qualit de service spcifie larchitecture qui va nous permettre doffrir un service meilleur que celui offert par le modle best effort traditionnel. Cette architecture doit prendre en considration les dfis imposs par les
26

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

rseaux ad hoc, comme le changement de la topologie et les contraintes de dlai et de fiabilit. Cependant, des modles tels que Intserv /RSVP proposs pour les rseaux filaires, ne prennent pas en compte les contraintes de limitation de ressources imposes par les rseaux ad hoc [27].

IV.5.2 Les modles standards existants IV.5.2.1 IntServ


Le premier modle s'appelle " Services Intgrs " ou IntServ [25]. Il utilise un concept bas sur la rservation ou chaque application transmet ses conditions tous les nuds de rseau traverss jusqu'au nud de destination. Quand tous les nuds ont accepts les conditions, l'application commence l'acheminement de ses donnes. IntServ aborde la qualit de service en reprenant le concept du " meilleur effort " et en y rajoutant le support du trafic en temps rel. Le modle IntServ est donc un modle incluant le concept du " best effort ", un service en temps rel, et un partage de lien contrl. Le modle de service gre deux sortes de trafic en temps rel garanti et prvisible. Les services intgrs ncessitent des routeurs capables de rserver des ressources (telles qu'une quantit fixe de bande passante) pour diffrents flux de trafic.

Figure IV.1: Principe de Fonctionnement du protocole IntServ.

Cependant, IntServ, en rendant possible la rservation de ressources, permet des requtes trs prcises en termes de qualit de service. Les clients obtiennent donc soit exactement ce qu'ils ont demand soit leur requte choue. La rservation de ressources est demande par le rcepteur, il met une requte de QoS correspondant ses besoins. Celle-ci parvient l'metteur sous forme d'un message RSVP. Ce mode d'attribution de ressources l'avantage d'tre effectu par le rcepteur qui, ainsi, peut demander une QoS adapte ses besoins et la consommation dsire. Pour assurer un chemin unique au cours d'une communication, il faut que les systmes terminaux fonctionnent en mode connect. Cependant, RSVP n'assure pas un mode connect avec les routeurs et une mise jour dynamique de la rservation est ncessaire. Les rcepteurs sont donc obligs de d'envoyer priodiquement des messages RSVP aux routeurs assurant le chemin.

27

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

Les requtes RSVP sont des messages de diffrentes natures permettant l'metteur comme au rcepteur d'avoir un chemin ddi de transfert.

Figure IV.2: Routeur intgration de service.

Notons que RSVP fournit une qualit de service tenant compte des modifications de ressources. En revanche, le problme majeur du modle IntServ/RSVP est celui du facteur dchelle car il maintient des tats par flux, ce qui pose certains problmes lors du passage lchelle. En effet plus le nombre de flux grer est important plus la charge de traitement devient insupportable. Les Integrated Services (IntServ) vont permettre de grer des flux entiers de donnes. Les routeurs implmentant ce modle sont capables de sparer les flux pour les traiter individuellement. Il apparat tout de suite que des mcanismes complexes vont tre ncessaires pour isoler et traiter chaque flux. Ce modle propose deux classes de service en plus du Best Effort:

Le Guaranteed Service: propos aux applications ayant des contraintes sur les dlais. Le Controlled Load : service propos aux applications requrant un service Best Effort amlior, plus fiable.

IntServ se compose de plusieurs composants: la signalisation, le contrle d'admission, la classification des flux, et l'ordonnancement des paquets. La signalisation permettant la rservation de ressources est assure par le protocole RSVP (Resource ReSerVation Protocol).

La fonction du contrle d'admission est de bloquer les flux dont les ressources demandes ne sont pas disponibles. Ce contrle est opr par chaque routeur sur le chemin. Chacun d'entre eux va accepter ou rejeter la demande de service suivant l'tat actuel du rseau. Les routeurs indiquent l'application, via RSVP, si le besoin de QoS peut tre satisfait ou non. Ensuite la classification des flux est, elle aussi, effectue par chaque routeur. Cette phase complexe permet de sparer les flux et d'insrer les paquets entrant dans les files d'attente appropries. Enfin, l'ordonnanceur gre l'ordre de sortie des paquets des files d'attente afin d'assurer la QoS demande.

28

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

Figure IV.3: le modle Intserv.

Ce modle n'est pas applicable aux MANETs car:

Les informations sur les flux augmentent proportionnellement au nombre de flux grs. Il n'y a pas d'agrgation. Ce problme de passage l'chelle n'est pas spcifique au MANETs, on le retrouve aussi dans l'internet. La maintenance de cette quantit d'information par des terminaux mobiles dont les ressources sont limites n'est pas envisageable. Mme si aujourd'hui les MANETs restent de petite taille et ne sont destins grer qu'un nombre restreint de flux, cette solution n'est pas viable long terme, puisqu'il est probable que les MANETs vont tre amens se dvelopper. Les paquets de signalisation RSVP utilisent une quantit non ngligeable de bande passante sur des liens dj limits. Chaque nud doit se charger de grer le contrle d'accs, la classification et l'ordonnancement des flux. C'est une charge trop importante pour des terminaux aux ressources limites.

IV.5.2.2 DiffServ
Le deuxime modle, " Services Diffrencis " ou DiffServ [26], utilise une technique de marquage des paquets (chaque paquet est tagu d'un code dans son entte IP pour indiquer quelle classe de trafic il appartient. Les commutateurs traverss sur le chemin manipulent donc les paquets diffremment en fonction de la classe de service laquelle ils appartiennent. Le comportement chaque nud du rseau est en effet choisi en se basant sur la classe de chaque paquet. DiffServ emploie le champ ToS dans l'en-tte d'IP pour dterminer quelle classe un paquet spcifique appartient.

Figure IV.4:Principe de Fonctionnement du protocole DiffServ. 29

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

L'metteur de flux spcialis, au travers du champ "Type Of Service", spcifie une classe de service qu'il souhaite donner ses paquets. Au cours de son voyage dans le rseau, ce paquet traverse des modules (routeurs) qui, quips d'algorithmes (Packet Classifier), lisent le champ TOS. Ensuite un rpartiteur de paquet (Packet Scheduler) met en uvre le traitement diffrenci en lui affectant une discipline de service adapte (file d'attente spcialise). Rappelons que les routeurs sont soumis de grands nombres de demandes qui les obligent grer des files d'attente. La stratgie des services diffrencis (DiffServ) est apparue pour faire face la complexit et au cot de l'approche " Services Intgrs ". Cette approche est diffrente d'IntServ par son concept de classification des flux. Le Differenciated Service (DiffServ) est destin combler les dfauts d'IntServ. On cherche supprimer le problme de passage l'chelle en dfinissant des classes permettant d'agrger plusieurs flux. Ainsi, tous les flux appartenant une mme classe reoivent le mme service. Deux types de routeurs sont donc dfinis:

Les routeurs de bord (Edge Routers), chargs de la classification, du marquage et du maintient de l'tat des flux. Les routeurs de cur (Core Routers), chargs uniquement de l'acheminement des paquets selon le marquage.

La complexit de ce dispositif se trouve donc dans les bords, puisque l'acheminement par les routeurs de cur est trs simple et rapide. C'est un bon compromis entre complexit et garantie de service dans l'internet.

Figure IV.5:modle DiffServ.

31

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

Lavantage de ce modle est quil offre des classes de QoS sans modifications en terme de gestion du trafic et il fournit des solutions de continuit par rapport au service au mieux ( best effort) traditionnel. En plus, il permet le passage lchelle pour les donnes. Par rapport IntServ, on perd en termes de flexibilit et de fermet des garanties. Le problme du plan de contrle reste entier (comment raliser un contrle dadmission sans maintenir dtat par flux ?). Dans le cas du multicast, les choses se compliquent davantage, en effet aucune approche na t propose sur la faon de dimensionner le rseau et de conditionner un trafic de multicast. Malheureusement, ce modle ne convient pas aux MANETs car la question de la dfinition des routeurs de bord et des routeurs de cur reste trs ambigu dans ces rseaux. Intuitivement, la source fait parti des routeurs de bords et les nuds du chemin font parti des routeurs de cur. Mais dans les MANETs, chaque nud doit pouvoir jouer les deux rles la fois, puisqu'il peut tre source d'une communication et relais pour une autre. Cela engendrerait donc une charge trop importante sur tous les nuds du rseau.

IV.5.2.3 FQMM (Flexible Quality of service Model for MANETs)


Le modle FQMM [28] est le premier modle de QoS propos pour MANETs en 2000 par Xiao et al. Les concepteurs du modle FQMM prennent en compte le fait que les rseaux ad hoc pourraient, terme, tre connects des rseaux filaires de type Internet. Il apparat ds lors ncessaire doffrir un mcanisme de qualit de service suffisamment proche des protocoles filaires afin de sinterfacer avec ces derniers. Le modle repose sur une architecture rseau plate (non hirarchique), constitue dune cinquantaine de nuds mobiles. Il combine les proprits des modles filaires IntServ et DiffServ, en offrant une mthode dapprovisionnement hybride :

par flux, pour les trafics prioritaires. par classe, pour les autres trafics.

Afin dobtenir les deux types de granularit (par flot ou par classe) des modles filaires, FQMM dfinit plusieurs classes de service dont la plus haute permet chaque flux de spcifier Les contraintes qui lui sont propres. A limage de DiffServ, FQMM dfinit trois types de nuds :

Les nuds dentre (metteurs). Les nuds intermdiaires. Les nuds de sortie (rcepteurs).

Les nuds dentre permettent de marquer et classifier les paquets, qui seront ensuite relays par les nuds intermdiaires suivant leurs PHB (Per Hop Behavior), jusqu arriver au nud destinataire. Ce modle repose essentiellement sur la couche IP, o les fonctionnalits sont spares en deux grands plans : le plan relayage de donnes et le plan contrle et gestion. Compte tenu du fait que dans un rseau ad hoc, chaque nud assure la fonction de routeur,
31

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

chaque mobile joue diffrents rles pour diffrents flux. Le conditionnement du trafic (lissage, marquage, etc.) est la charge des metteurs. FQMM requiert lutilisation dun protocole de routage capable doffrir une certaine qualit de service, c'est--dire capable de rechercher des routes satisfaisant certaines contraintes. Dans ce modle, le protocole de routage est suppos fournir des routes ayant suffisamment de ressources. Par son approche hybride, FQMM entend rsoudre certains problmes lis aux modles filaires. De plus, la rsolution de la plupart des problmes lis au fonctionnement AdHoc (volume de signalisation, consommation dnergie, bande limite et difficile estimer) est laisse la charge du protocole de routage sous-jacent. Lavantage dune telle approche est la possibilit dinterfacer le rseau avec lInternet, vu les mcanismes de qualit de services offerts qui sont proches des protocoles filaires. Cependant, plusieurs mcanismes ainsi que linteraction avec la couche MAC restent dfinir pour sadapter aux conditions variables du rseau ad hoc.

Figure IV.6: Le modle FQMM.

En revanche, ce modle souffre de plusieurs problmes : Labsence de tout contrle explicite du nombre de services par flux offerts pose un problme de scalabilit, comme dans le cas du modle IntServ. Dans DiffServ, les nuds intermdiaires expdients les paquets selon leurs PHB dans le champ DS. Il est donc difficile de coder le PHB dans le champ DS sil contient une granularit par flux (taille limite du DS gale un octet sans extension). Il est trs difficile de faire un profil dynamiquement ngoci du trafic. La rsolution de la plupart des problmes lis au fonctionnement ad hoc (tels que le volume de signalisation, la consommation dnergie et la bande passante limite) est laisse la charge du protocole de routage sous-jacent.

32

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

IV.5.2.4 SWAN (Service differentiation in Stateless Wireless Ad Hoc Networks)


Le modle SWAN [29] [30] met en uvre un contrle d'admission des paquets. Un paquet est accept si la bande passante de la route qu'il doit emprunter est suffisante pour assurer son transit sans occasionner de congestion du rseau. Cependant, ce modle n'apporte aucune garantie quant au maintien de la communication entre deux entits pour un trafic en cours : en fonction des variations de la bande passante, le trafic est maintenu ou coup. De plus, le protocole de routage utilis est de type Best Effort, ce qui signifie que lorsqu'un paquet est envoy, il n'y a aucune vrification quant son arrive destination et donc aucune assurance vis--vis de la "livraison" d'un paquet.

IV.5.2.5 Modle iMAQ


IMAQ [31] fournit le support des transmissions des donnes multimdia dans un MANET. Il inclut une couche ad hoc de routage et une couche de service logiciel (Middleware). Dans chaque nud, ces deux couches partagent les informations et communiquent afin de fournir les garanties de QoS aux trafics multimdia. Le modle est bas sur la prdiction de la position des nuds (predictive location-based) et orient QoS.

Figure IV.7: Le modle iMAQ.

La couche Middleware communique galement avec la couche application et la couche rseau et essaye de prvoir le partitionnement du rseau. Pour fournir une meilleure accessibilit aux donnes, il rplique les donnes entre les diffrents groupes du rseau avant deffectuer le partitionnement.

IV.6 Systmes de Signalisation pour la QoS dans MANETs


La signalisation constitue un autre lment essentiel de la qualit de service dans les rseaux. Elle permet de rserver et librer des ressources du rseau, et de diffuser des informations de contrle au travers du rseau. Une signalisation efficace repose sur la fiabilit du transfert des signaux entre les routeurs et sur la bonne interprtation de ces signaux par les routeurs. Il s'agit d'un point dlicat dans les

33

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

rseaux ad hoc puisque ce sont les nuds qui jouent alatoirement le rle de routeur selon les besoins.

IV.6.1 Systme de signalisation QoS ad hoc (INSIGNIA)


Le systme de signalisation INSIGNIA [32] est un systme de signalisation qui s'adapte relativement bien la structure des rseaux ad hoc. En premier lieu, il s'agit d'un systme in-band, c'est dire que les donnes de contrle sont incluses dans les enttes des paquets et donc transmises avec les paquets de donnes au lieu d'tre transmises dans des paquets de contrle spcifiques. Cela est adapt aux rseaux ad hoc car il y a optimisation de l'utilisation de la bande passante. De plus, INSIGNIA permet de dterminer la quantit de bande passante attribuer chaque paquet et de rserver cette bande passante, assurant ainsi une certaine qualit de service.

Figure IV.8: Larchitecture du protocole INSIGNIA. Cette rservation est de type soft-state, ce qui implique que les ressources sont libres automatiquement si elles ne sont pas utilises durant un certain laps de temps paramtrable. L encore, cette caractristique est adapte aux MANETs puisque les ressources seront libres sans demande spcifique et sans besoin notamment du lien d'allocation, ce qui est pratique dans un rseau o les liens sont peu fiables et la topologie dynamique.

IV.6.2 Dynamic Qos / dRSVP


Dans les protocoles usuels, les applications demandent une quantit prcise de bande passante. Trs souvent, le mme niveau de service est conserv durant toute la transmission. Les auteurs de Dynamic QoS remettent en cause cet aspect statique de la rservation de bande passante. Lors de la demande de rservation, les applications ne spcifient pas une valeur prcise
34

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

mais un intervalle de valeurs. La borne infrieure reprsente le dbit ncessaire au fonctionnement de lapplication et la borne suprieure le dbit maximal qui pourra tre atteint.

Lors de la confirmation de rservation, le rseau indique lmetteur la quantit de bande passante qui lui a t effectivement alloue. Dautre part, on considre souvent quun lien a une capacit fixe mais sur le canal quest lair, cette capacit est variable. Dans Dynamic QoS, la quantit de bande passante rserve par les applications peut tre modifie en cours de transmission, soit linitiative du rseau dans le cas o les ressources deviennent rares ou se librent, soit linitiative de lapplication mettrice elle-mme afin de librer des ressources dans le rseau. Si cette approche est originale et peut permettre de diminuer la probabilit de rejet des demandes de rservation, elle ncessite un accord entre les diffrents metteurs sil ny a pas dadministration centralise. Elle pourrait tre trs efficace dans des rseaux avec AP.

IV.6.3 Signalisation in-band ET out-of-band


On peut distinguer deux types de signalisation : in-band : les informations de contrle de ux sont vhicules avec les paquets de donnes. out-of-band : on utilise des paquets de contrle spciques La signalisation in-band est plus lgre que la signalisation out-of-band. En effet, le surcot engendr par les messages out-of-band spciques la signalisation est trs important et consomme de la bande passante supplmentaire. De plus les paquets de signalisation doivent avoir une priorit suprieure celle des paquets de donnes an de garantir la QoS tout moment. Cela mne un systme complexe et dont les performances vont devenir assez faibles. Mais cette approche (out-of-band) supporte le passage lchelle puisque les messages de contrle ne dpendent pas de la transmission de paquets de donnes. RSVP est un exemple de ces protocoles de signalisation out-of-band. Les contraintes en ressources des MANETs ne permettent pas la mise en place dun mcanisme complexe. Le but est doffrir un protocole aussi lger et simple que possible. Mais comme RSVP na pas t mis au point en prenant en compte les contraintes des MANETs, il nest pas efficace dans ce domaine.

IV.6.4 Maintient des rservations soft-state ET hard-state


On distingue deux mthodes pour le maintien des rservations dans le rseau. Dabord la mthode soft-state o les ressources rserves sont libres si elles ne sont pas utilises pendant un certain laps de temps. Par opposition, il existe aussi des mthodes efcaces et plus simple, appeles hard-state o les ressources ne sont libres que lorsque cela est explicitement demand. Dans ce deuxime cas, il ny a pas besoin de signalisation ni de gestion de temporisateurs. La solution soft-state est plus adapte aux MANETs car les liaisons ne sont pas ables et sont susceptibles dtre casses. Dans certain cas o un nud se retrouve isol de la source pour
35

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

laquelle il avait rserv des ressources, ce nud ne recevra jamais de message de libration et rservera donc des ressources jamais utilises. Il est donc important que les ressources soient libres automatiquement si elles ne sont pas utilises.

IV.6.5 Le protocole Bruit


BRuIT (Bandwidth Reservation Under InTerferences inuence) [33] a pour but dapporter un contrle de la bande passante an dempcher au maximum lapparition de congestion dans le rseau et de fournir la bande passante demande pour certains types de ux. Pour cela, il considre deux types de ux : les ux best-effort qui nauront aucune garantie sur leur dbit et les ux privilgis qui on peut rserver une certaine bande passante. Pour effectuer ces rservations et ce contrle, BRuIT tente dapporter suffisamment de connaissance chaque mobile sur la bande passante qui est utilise dans son voisinage tendu (lensemble de ses voisins un et deux sauts) et ce rgulirement. Avec cette connaissance, il peut estimer la bande passante utilise pour les ux privilgis dans son voisinage tendu. partir de l, chaque mobile peut dcider de ladmission ou du rejet dun ux privilgi qui ncessite une certaine bande passante. Ceci permet donc aux mobiles de naccepter que les ux dont ils seront initialement en mesure dhonorer leur dbit et donc dempcher, trs souvent, lapparition de congestion. BRuIT effectue une rservation de bande passante en se basant sur un protocole de routage avec qualit de service. BRuIT ne permet pas de prendre en compte les ux transitant sur des mobiles en zone de dtection de porteuse de certains autres mobiles, mais non connects ceux-ci par au plus deux sauts radio. Il reste encore du travail concernant lutilisation de la bande passante, an dallouer une partie adaptative au trac best effort fonction de la topologie et de lutilisation du rseau.

Un systme de signalisation est ncessaire mais pas suffisant. Il est associer un protocole de routage pour la dtection et la mise jour des changements de topologie du rseau. L'association de systmes de signalisation et de protocoles de routage permet l'laboration de modles appliquer un type de rseau pour assurer une qualit de service particulire.

Figure IV.9: Modle de Qualit de service.

36

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

Dans le cas des rseaux ad hoc, il reste encore beaucoup de travail pour tablir une solution de qualit de service. En effet, cette tche est trs difficile en raison de la complexit de ce type de rseau par rapport ce qu'il est possible d'influencer actuellement dans les rseaux pour obtenir de la qualit de service.

IV.7 Routage avec QoS dans MANETs


Le routage avec QoS est un lment cl pour raliser une architecture de QoS pour les MANETs. Le protocole de routage peut informer une source sur les conditions QoS du rseau. Cette connaissance va permettre ltablissement de connexions avec qualit de service. Il existe de nombreux protocoles de ce type.

IV.7.1 ADQR (AD hoc QoS on-demand Routing)


Le protocole AQOR [34] est un protocole de routage ractif utilisant un accs au canal distribu. Il propose une mthode pour dterminer la bande passante disponible et le dlai de bout en bout dun chemin. A partir de ces informations, le protocole dtermine les routes respectant les contraintes de bande passante et de dlai imposes par un flux.

IV.7.2 CEDAR (a Core Extraction Distributed AdHoc Routing Algorithm)


Le protocole CEDAR [35] est un protocole hirarchique. Les nuds du rseau forment un rseau backbone. Lors de la recherche dune route QoS, le nud backbone du nud source cherche une route vers le nud backbone du nud destination. Pour cela, un protocole ractif est utilis. Des informations dtat sur la topologie du rseau sont propages seulement quand des seuils sont atteints. Quand la bande passante crot, linformation traverse lentement le rseau. Par contre, lorsque la bande passante dun lien dcrot, linformation traverse rapidement le rseau vitant ainsi des nuds de choisir un tel lien alors que la bande passante nest plus disponible.

IV.7.3 IAR (Location Aided Routing)


Le protocole IAR [36] est un protocole de routage hybride permettant dassurer un flux une certaine quantit de bande passante. Chaque nud met priodiquement un tat des liens qui est propag sur la totalit du rseau. Ainsi, chaque nud possde une vue du rseau. Lorsquune route a besoin dtre trouve, le nud source utilise diffrents algorithmes (avec des contraintes diffrentes) dterminant un ensemble de routes de bout en bout. Un paquet dallocation est envoy sur chacun de ces chemins. Un tel paquet est propag seulement si un nud peut rserver la bande passante requise. A la rception de tels paquets, la destination choisit la meilleure route suivant lun des critres suivants : la route ayant le plus de bande passante ou la route avec le plus faible cot.

37

Chapitre: IV

Qualit de service dans les rseaux mobile ad hoc

Le tableau suivant prsente une petite comparaison entre un chantillon des protocoles de routage qui supportent la QoS selon le type de routage, Mtrique de QoS, Rservation de ressource, Modles de Mtrique de Qos, et Interfrence 2 sauts.

Protocole

Type

Mtrique de Qos BP et dlai Garantie BP Garantie BP Garantie BP Garantie BP Garantie BP Garantie BP Garantie BP

AQOR CEDAR IAR LS-MPR MCNRP CACP CCBR CAAODV

Ractif Hira-Ractif Hybride Ractif Hira-Ractif Ractif Proactif Ractif

Rservation de ressource Oui Oui Oui Oui Oui Oui Oui Oui

Modles de mtriques de QoS Oui Non Non Oui Oui Oui Oui Oui

Interfrences 2 sauts Non Non


Oui/(Non pourTDMA)

Non concern Non concern Oui Non concern Oui

Tableau IV.1:Protocoles de routage avec QoS.

Conclusion
Dans ce chapitre, nous avons prsent le concept de qualit de service dans son cadre gnral, ainsi que dans le cadre des rseaux ad hoc. Nous avons donn quelques exemples des direntes techniques utilises pour le support de qualit de service dans les rseaux ad hoc qui peuvent tre intgres dans dirents niveaux du modles OSI: routage avec qualit de service, modle de qualit de service. Dans le chapitre suivant, nous dtaillons notre amlioration du protocole OLSR (Stable_OLSR).

38

Introduction au la Qualit de service dans OLSR

Chapitre: V

Stable Optimized Link Stat Routing Protocol

V.1 Introduction
L'objectif de notre travail est l'amlioration des communications dans les rseaux mobile ad hoc. Le problme de cette approche cest que les chemins deviennent instables dans des courtes dures impliquant une perte de paquets aux niveaux des applications exigeants en matire de qualit de services (qui ne tolre pas cette perte). Pour ce faire, nous nous sommes bass sur le protocole OLSR, et nous avons travaill sur l'environnement Opnet utilisant des mtriques pour fournir la qualit de service dans ce type des rseaux.

V.2 Stabilit ditinraire:


Dans le cadre damliorer la Qos dans MANET, on se basant sur ltude de la stabilit des nuds. Nous proposons une mtrique de stabilit ditinraire. On dit quun itinraire est stable sil se compose par des nuds stables. Dans cette section nous allons dfinir la notion de nud stable (SdN), puis on montre la mthode de calcule de cette notion, ensuit nous dcrivons laspect de fidlit du nud (FdN). Cette approche (SDN et FDN) est utilise pour amliorer Lalgorithme de slection dMPR et modifier lalgorithme de Choix ditinraire.

V.3 Mtriques bases sur la fonction de stabilit de nud


Aujourdhui, la plupart des protocoles de routage proposs par le groupe MANET de lIETF ne prennent pas en compte la Qos. Dans la majorit des cas, les messages sont achemins travers le plus court chemin disponible, qui ne pas tre adapt pour les applications qui exigent des garanties de Qos, par exemple le protocole OLSR choisi les itinraires en termes de plus bref chemin par la mthode de dijkstra, cette dernire garanti un nombre minimal de sauts, ce choix est trs importent, mais nest pas le meilleur pour viter le problme de liens vulnrable. Pour soigner ce problme, nous avons propos une nouvelle mtrique pour opter les itinraires durable et stable.

V.3.1 Stabilit des nuds (SdN) V.3.1.1 Dfinition


La stabilit des nuds est un nouveau concept quand vas essayer dintroduire dans les protocoles de routage ad-hoc. Ce concept consiste Collecte des informations sur la puissance du signal entre un nud et son voisin, avec ces donnes on peut faire une statistique qui nous permet dappliquer lingalit de Bienaym-chebychev pour dterminer La stabilit entre ce couple (nud-voisin).

39

Chapitre: V

Stable Optimized Link Stat Routing Protocol

Figure V.1: stabilit de nud.

V.3.1.2 Calcule du SdN V.3.1.2.1 ingalit de Bienaym-chebychev :


Dans la thorie des probabilits, Lingalit de Bienaym-chebychev, dclare que dans nimporte quel chantillon de donnes ou distribution de probabilit que :
( ) ( ). On a lingalit suivant: .

*|

( )|

( )

( )| + est toujours vraie tant que la variance tend vers zro, cela La probabilit *| signifi que la probabilit dtre la valeur du variable alatoire X reste toujours proche a son esprance (peu de changement dans le futur) tend vers la ralit si et seulement si son variance tend vers zro. En dautre terme, un nud est dans un tat de stabilit tant que ces valeurs de puissance de signale mesurs dans ces messages mis sont trs proche que lesprance mathmatique de ces valeurs. Dans un cas particulier si la variance mathmatique gale zro, on peut dire maintenant que ce nud est strictement stable. Exemple : Soit X1, X2, X3, X4, X5 cinq nuds voisins dun nud N, et P1, P2, P3, P4, P5 Sont des mesures des puissances dans les messages reus par ces voisins.
X1 X2 X3 X4 X5 P1 2.152 1.206 3.007 3.700 3 P2 P3 P4 P5 2.101 2.356 2.370 2.220 0.152 0.116 0.256 0.114 3.100 3.102 3.750 3.700 3.750 3.102 3.100 3.007 3 3 3 3 Tableau V.1: Calcule de stabilit de nud. 41 V(Xi) 0,01156416 0,17789216 0,10449936 0,10449936 0

Chapitre: V

Stable Optimized Link Stat Routing Protocol

V.3.1.2.3 Analyse de lexemple:


Le nud N, et aprs rception des massages de chaque voisin Xi, calcule V(Xi) et dcide que ce voisin est dans un tat de stabilit ou non (le degr de stabilit de ce voisin). - Parmi les trois premiers voisins, daprs le thorme prcdent, le nud X1 est le plus stable par port aux autres. - Si on trouve deux nuds de mme valeur V(x), comme X3 et X4, le plus stable est le nud qui sa dernire valeur de puissance P est la plus grande. - dautre part, X5 est totalement stable (ex : nud fixe).

V.3.2 Fidlit dun nud (FdN) V.3.2.1 Dfinition


Dans le rseau ad hoc, Les nuds changent les messages entre eux. A partir de ces derniers, chaque nud doit savoir les liens durables et les voisins fidles. Cette notion de fidlit est calcule comme suite :

Figure V.2: fidlit de nud.

V.3.2.2 Calcul de FdN :


Pour mesurer le FdN, chaque voisin deux sauts ayant plusieurs voisins dans le groupe de voisinage dun seul saut, donne un jeton au nud qui a le SdN minimal, le nud de FdN maximal est le nud le plus stable au niveau de plusieurs voisins. Le choix de ce nud comme MPR est trs important pour lire des chemins trs stables.

41

Chapitre: V

Stable Optimized Link Stat Routing Protocol

V.4 Intgration dans OLSR


Pour garantir la Qos dans le protocole OLSR, il est ncessaire dadmis un contrle savre indispensable pour contrler les trafics et viter ainsi la rupture des itinraires. Lide repose sur linsertion dun champ dans les paquets Hellos et TC. Ce champ contient des informations qui permettent de faciliter le contrle dadmission effectu lors de ltablissement des chemins. Dans la suite, nous appelons le protocole OLSR amlior dans notre proposition : S_OLSR (Stable Optimized Link State Routing).Avant de dtaill le protocole amlior, nous prsentons le format de paquet Hello modifier.

V.4.1 Extension Hello :


Dans le cadre damlioration de protocole OLSR, nous proposons une modification dans le format des paquets de contrle Hello, Ce paquet reste le mme mais une petite volution par lajoute a chaque @ dinterface voisin le SdN correspondant. La structure de ce message est dtaille dans la figure suivante qui prsente un message Hello mis par le nud 3 au 1 de lexemple prcdent.

Figure V.3: Message Hello de S_OLSR.

Les champs (Reserved, Htime, Willingness, Link Code, Link Message Size, Neighbor Interface Address) sont dtaills dans (III.3.1.1). Stabilit (SdN) : la stabilit de nud voisin (Neighbor Interface Address) par--port lmetteur.

V.4.2 Mcanisme de routage S_OLSR


Le routage se compose de deux tches principales. La premire tche est de collecter et mettre jours des informations de ltat du rseau. La deuxime tche est de chercher un chemin faisable pour une nouvelle connexion en basant sur les informations collectes. La performance dun algorithme de routage dpend directement de comment la premire tche est rsolue. chaque nud maintient son tat qui contient les tables de (voisinage, deux sauts, MPRset, MPRselectorset), et les mesures (SdN, FdN) En basant sur ces informations, les paramtres de Qos peuvent tre calculs.
42

Chapitre: V

Stable Optimized Link Stat Routing Protocol

Chaque nud maintient ltat global du rseau qui change priodiquement les tats locaux parmi les nuds [23]. Ltat global est la combinaison des tats locaux. la rception dun paquet, la couche physique dun nud mesure la puissance du signal reu, met cette valeur dans une structure ICI et remonte le couple (Paquet, ICI) la couche rseau. Cette dernire dcapsule le paquet IP et collectes des informations sur ce message (Source@, Dest @, ...), injecter ces information dans lICI puis retransmettre les datagrammes au couche suprieur. Au niveau de la couche transport, un processus de rassemblage de donnes (blocs) avant de les envoyer vers lapplication ou le service de destination. Quand larrive de paquet (datagramme) dans le port (n689) ou lOLSR t cout, le dclenchement de processus de traitement de message fait selon le type de message (Hello, Tc). Avant de ce dclenchement, on obtient l@ de linterface, @ IP de la source, et La valeur de signale a partir de ICI, puis dcapsuler le message OLSR inclus dans le Datagramme. Parmi les situations que doit dtruire ce message : si on trouve l@ de lmetteur est mme de cette interface qui est en cours de traitement. Aussi, si la valeur de TTL gale zro pour viter le problme de bouclage des messages.

V.4.3 Traitement de message Hello :


Dabord, ce processus collecte des informations sur le message OLSR (@ de linitiateur, taille de message, Nseq, etc.), puis retirer le message Hello de le message OLSR, et tient jour les tables de (voisinage, deux sauts). A partir de la valeur de signale mesur dans ce message, le processus peut mesurer la stabilit de lmetteur (SdN), retirer les SdN correspondant aux voisins de deux sauts inclus dans ce message, et enfin re-calculer les MPR sil ya changement dans le voisinage.

V.4.3.1 Amlioration de lalgorithme de slection dMPR:


Lalgorithme standard de slection des MPR est modifi comme suit : Dbut { 5. Commencer par un ensemble de relais multipoint vide MPRset (x)=. 6. Calculer le degr D(y) de chaque nud dans N(x). 7. Calculer la fidlit F(y) de chaque nud dans N(x).f(y) est le nombre de jetons obtenus. 8. Choisir les nuds de l'ensemble des voisins N(x) qui sont les seuls ayant un lien avec un voisin du second niveau. Ajouter ces nuds slectionns de N(x) l'ensemble MPRset (x), et liminer tous les nuds du second niveau couverts par ces derniers de 2 l'ensemble N (x).
43

Chapitre: V

Stable Optimized Link Stat Routing Protocol


2

9. Tant que N (x) n'est pas vide refaire { (a) Calculer reachability (accessibilit) R(y) de chaque nud dans N(x). (b) Ajouter le nud (y) de N(x), ayant F(y) maximal l'ensemble des MPRset (x), Si les valeurs sont les mmes prend le nud qui le plus grand degr de reachability R(y). Si ces derniers sont gaux on prend alors le nud avec le plus grand degr D(y). Enlever tous les nuds du second niveau couverts par ce nud de lensemble N (x). } Fin Tant que. } Fin.
2

V.4.4 Etablissement de chemin (propagation des messages TC)


Le calcul de la table de routage est bas sur les informations contenues dans la base d'informations de voisinage ainsi que celui de la base de topologie tout en les combinant avec les associations des interfaces. De ce fait, chaque fois que l'une de ces bases d'informations change, la table de routage doit tre re-calcule. Daprs le standard, les chemins sont lus par la mthode de Dijkstra, nous dveloppons une nouvelle mthode pour lire les chemins avec de garantir la Qos, cette mthode est base sur linjection dun champ dans les messages de contrle TC, ce champs permet de dtermine la stabilit entre les MPR pour fournir des itinraires stable et durable.

V.4.4.1 Extension TC

Figure V.4: Message TC de S_OLSR.

V.4.4.2 Traitement de message TC :


Le processus de traitement de message TC vrifie lordre de message reu, et le dtruire si le n de squence est inferieur de dernier N de seq de mme metteur. Autrement, la table de routage est mise jour chaque fois qu'on dtecte un changement dans la base de voisinage ou de la topologie. Plus prcisment, quand on dtecte l'apparition ou bien la disparition d'un nud dans le voisinage, ou la disparition ou l'apparition d'un tuple dans la base de topologie.

44

Chapitre: V

Stable Optimized Link Stat Routing Protocol

Conclusion
Dans un environnement dynamique (ex : les rseaux ad hoc), il est difficile de garantir une qualit de service pour les applications. Le protocole standard OLSR fournit un chemin entre toute paire de nuds des rseaux mais son se proccuper des exigences en matire de qualit de services. Dans ce chapitre nous avons propos une amlioration de ce protocole pour quil garanti des chemins stable et durable. Elle sagit des mcanismes de stabilit et de fidlit de nuds. Pour voire lefficacit de cette proposition nous lavons implment sur le simulateur des rseaux OPNET, ainsi les rsultats de simulation seront discuts dans le chapitre suivant.

45

VI

Simulation et discussion des rsultants

Conclusion et perspectives

VI.1 Introduction
La simulation constitue actuellement l'outil le plus pratique pour valuer le comportement d'un systme complexe dont la formalisation l'aide de mthodes analytiques est difficile .Pour tester les performances dun rseau mobile on a souvent recours la simulation. En effet il serait trop coteux, voire impossible, de mettre en place un rseau des fins de test pour certains critres. Par exemple, tester des applications sur des rseaux de grande envergure nest possible en ralit que si lon dispose de moyens matriels importants. Cependant, dans le cadre dune simulation, il suffit de changer les paramtres de simulation correspondant la taille du rseau.

Plusieurs simulateurs pour rseaux sans fil ont t proposes ces dernires annes, parmi lesquels NS-2 [37], GloMoSim [38], JiST/SWANS [39], GTSNetS [40], OMNeT++ [41], Opnet [42], etc. Ces simulateurs offrent tous un environnement avarice de programmation pour l'implmentation et I' valuation des performances des protocoles de communication. Aprs avoir dcrit larchitecture gnrale de la SDDS CTH dans MANET, nous prsentons, dans ce chapitre, lenvironnement de simulation conu, les outils techniques ncessaire pour mettre en uvre le systme, la description des tests effectus et les rsultats obtenus.

VI.2 Qu'est-ce que la simulation?


Simuler, c'est modliser un systme complexe, afin de prvoir son comportement dans le monde rel. Il s'agit d'une approche permettant de reprsenter le fonctionnement d'un systme rel constitue de plusieurs entits, de modliser les diffrentes interactions entre elles, et enfin valuer le comportement global du systme et son volution dans le temps [43].

Figure VI.1: modalisation d'un systme.

46

Conclusion et perspectives

Le recours la simulation permet de contourner les limites de la complexit des modles analytiques. Toutefois, il est ncessaire de bien identifier les caractristiques du systme afin de le reprsenter, le plus finement possible, par des modles abstraits. Si la reprsentation du systme rel par des modles abstraits est suffisamment raliste et prcise, il est alors possible de reporter les rsultats obtenus avec ces modles sur le systme rel. Le cycle correspondant aux tapes de modlisation, simulation et report des rsultats est illustre sur la Figure VI.1.

VI.3 Quand et pourquoi simuler?


La simulation d'un systme rel devient ncessaire des lors que les modles analytiques deviennent, soit trop complexes en termes de calcul et de temps de rsolution, soit trop simplifies vis--vis de la ralit rendant, par ce fait, les rsultats obtenus non reprsentatifs du comportement du systme dans un environnement rel [44]. Ainsi, la simulation peut s'avrer ncessaire dans les cas suivants:

Le systme n'est pas dcomposable en sous-systmes simples et indpendants l'un de l'autre, rendant une modlisation analytique trs complexe. Le systme n'existe pas encore. Dans ce cas, la simulation peut constituer une phase prliminaire, permettant aux concepteurs de prvoir le fonctionnement du systme afin d'optimiser le dimensionnement de ses diffrents paramtres.

Les expriences sur systme rel sont trop couteuses en termes de ressources matrielles et humaines. Les expriences sur systme rel ne sont pas reproductibles ni reprsentatives de tous les environnements possibles. Dans ce cas, la simulation permet de caractriser le comportement global du systme pour diffrents environnements.

VI.4 Les mthodes de simulation:


Lorsque la simulation s'avre ncessaire pour valuer un systme rel, quatre principales mthodes de simulation peuvent tre utilises en fonction de la nature du systme cible :

La simulation de Monte-Carlo qui se base sur la gnration de nombres alatoires afin de reproduire les rsultats d'un calcul pour lequel les donnes sont incertaines. La simulation continue qui permet d'analyser de manire continue le comportement
47

Conclusion et perspectives

d'un systme, reprsente sous la forme d'quations diffrentielles, au cours du temps. La simulation analytique qui permet d'analyser des processus stochastiques travers lesquels le systme peut passer par diffrents tats, comme par exemple les chaines de Markov. La simulation discrte qui grce la gnration d'ventrent permet l'valuer le comportement d'un systme au cours du temps.

VI.5 Simulation des rseaux sans fil


La simulation constitue actuellement la mthode la plus rpandue et la plus pratique pour valuer les performances des rseaux sans fil. Plusieurs simulateurs ont t dveloppes et sont actuellement utilises dans les environnements acadmiques et industriels pour valuer les performances des systmes sans fil. Nous prsentons dans ce qui suit les simulateurs les plus populaires et nous discutons leurs spcificits, avantages et inconvnients.

NS2 [36] (Network Simulator) est le simulateur le plus populaire pour la modlisation des rseaux filaires et sans fil. NS2 est dveloppe en C++ et utilise le langage OTcl pour l'criture des scripts et des fichiers de configuration. Vu la popularit de cet outil, plusieurs modles de simulation ont t dveloppes et sont actuellement disponibles : couche MAC (CSMA, CDMA, MPLS, etc.), couche rseau (IP, AODV, DSR, etc.), Couche transport (TCP et UDP), etc. Cependant, le grand inconvnient de ce simulateur est le passage l'chelle qui se limite la simulation de quelques centaines de nuds, Plus rcemment, certains travaux d'optimisation ont permis d'amliorer le passage l'chelle pour la modlisation de quelques milliers de nuds [45]. Il est noter qu'une nouvelle refonte de ce simulateur, appele NS3, est en cours de dveloppement [46]. GloMoSim [37] est un environnement de simulation crit en langage Parsec [47]. Ce langage permet la mise en uvre de simulation squentielle et parallles ventrent discrets. Grace la paralllisassions, GloMoSim est capable de simuler des rseaux constitues de quelques dizaines de milliers de nuds [48]. Plusieurs modles de simulation ont t implmentes au sein de ce simulateur. Par ailleurs, GloMoSim offre une modlisation de la couche physique un peu plus raliste que celle de NS2. Cependant, ce simulateur ne semble plus supporte. Il est galement noter qu'une version commerciale et drive de GloMoSim, appele QualNet, t dveloppe [49].

48

Conclusion et perspectives

JiST/SWANS [39] est un simulateur vnements discrets crit en Java. Ce simulateur repose sur Jist, un moteur gnraliste permettant l'implmentation de simulateurs vnements discrets. Ce moteur fonctionne au-dessus de la machine virtuelle de Java et il t dmontre comme tant plus efficace que NS2 et GloMoSim en termes d'utilisation mmoire et rapidit d'excution [39]. Le grand inconvnient de ce simulateur est le manque de modularit et la difficult d'implmenter de nouveaux modles de simulation.

GTSNeTS [40] (Georgia Tech Sensor Network Simulator) est un simulateur crit en C++ et ddie la simulation des rseaux de capteurs sans fil. Ce simulateur est capable de simuler plusieurs centaines de milliers de nuds. Cependant, le plus gros inconvnient de ce simulateur est l'absence de modlisation raliste de la couche physique... Cet tat de l'art des simulateurs de rseaux sans fil est loin d'tre exhaustif. En effet, plusieurs autres simulateurs sont galement disponibles en version commerciale (OPNET [42], etc.) ou gratuite (OMNeT++ [41], J-Sim [50], SSFNet [51], etc.).

VI.6 OPNET Modeler VI.6.1 Introduction


OPNET (Optimum Network Performance) [42] est un outil de simulation de rseaux trs puissant et trs complet. Bas sur une interface graphique intuitive permet de dessiner et dtudier des rseaux de communications, des quipements, des protocoles et des applications avec facilit et volutivit. Modeler est utilis par les entreprises technologiques les plus performantes pour acclrer leurs procds de recherches et dveloppements.

Lapproche oriente objet associe des diteurs graphiques intgrs de Modeler simplifie la composition des rseaux et des quipements. Ceci permet de raliser facilement une correspondance entre votre systme dinformations et votre modle. Modeler est bas sur une srie dditeurs hirarchiss qui paralllisent la structure du rseau rel, des quipements est des protocoles.

49

Conclusion et perspectives

Figure VI.2: Liens hirarchiques entre les diffrentes interfaces.

VI.6.2 Pourquoi OPNET?


Un bon outil de modlisation devrait reflter de prs le vrai comportement d'un rseau ou d'un ordinateur systme. Il devrait soutenir une large gamme de protocoles de rseau et d'applications. Cela doit tre facile utiliser et matriser, surtout pour les dbutants. D'autre part, un bon outil de modlisation devrait fournir le soutien technique complet et l'assistance d'entretien. Dans le rsum, un bon outil de modlisation devrait avoir des proprits suivantes : Flexible : capable de simuler des protocoles de rseau diffrents / les applications sous une large gamme de conditions de fonctionnement. Robuste : fournissez aux utilisateurs puissant de modlisation, la simulation et l'analyse de donnes quipement. Facile utiliser : facile utiliser et matriser. Clair : facile identifier des problmes de modlisation et des fautes de simulation.

51

Conclusion et perspectives

OPNET est acclam par les professionnels de rseau parce qu'il toutes ces proprits. OPNET est l'assortiment de logiciels qui t conu avec un ensemble tendu des traits. Il peut tre adapt pour aller presque chaque besoin de crateurs de protocole de rseau, mettez en rseau des fournisseurs de service, aussi comme mettent en rseau des fabricants d'quipement.

OPNET soutient la plupart des protocoles de rseau dans l'existence, tant la ligne mtallique que la radio. Il peut tre utilis pour modeler et analyser un complexe le systme en excutant des simulations d'vnement distinctes.

Tableau VI.1: Les simulateurs de rseau.

VI.6.3 La simulation sur le Modeler


Une simulation OPNET Modeler c'est: Un projet. Un ou plusieurs scnarios. Des modles de nuds. Des modles de processus. Des descripteurs de statistiques. Plusieurs simulations excutes avec des valeurs de Random Number Seed (graine) diffrentes.
Figure VI.3 : Cycle de modlisation et de simulation.

VI.6.4 Les Interfaces Principales:


Parmi les nombreuses interfaces que propose OPNET au dmarrage, on distingue les interfaces suivantes :

51

Conclusion et perspectives

Rdacteur de Projet

Le Rdacteur de Projet est la rgion de mise en scne principale pour crer une simulation de rseau. De ce rdacteur, vous pouvez construire un modle de rseau on utilisant les modles de la bibliothque standard, choisir la statistique du rseau, diriger une simulation et voir les rsultats.

Rdacteur de Nud

Le Rdacteur de Nud vous permet de dfinir le comportement de chaque objet de rseau. Le comportement est dfini en utilisant de diffrents modules, dont chacun modle un peu d'aspect intrieur de comportement de nud tel que la cration de donnes, le stockage de donnes, etc. Les modules sont raccords par les ruisseaux de paquet ou les fils statistiques. Un objet de rseau est compos des modules typiquement multiples qui dfinissent son comportement.

vous permet de crer des modles contrlent de la processus, qui

fonctionnalit

Rdacteur de Modle de Processus

sous-tendante des modles de nud crs dans le Rdacteur de Nud. Les oprations

excutes dans chaque tat ou pour une transition sont dcrites dans C incorpor ou C ++ blocs codes.

52

Conclusion et perspectives

L'ICI (l'Information de Contrle d'Interface) Rdacteur vous

Rdacteur ICI

permet de dfinir la structure intrieure utiliss d'ICIs. pour ICIs sont

formaliser

l'interconnexion de processus base sur l'interruption

Le Rdacteur de Format de Paquet vous permet de dfinir la structure intrieure d'un paquet comme un ensemble de champs.

Rdacteur de Format de Paquet

Un format de paquet contient un ou plusieurs champs, reprsents dans coloris le rdacteur des comme botes

rectangulaires. La dimension de la bote est proportionnelle au nombre de bits spcifis comme la dimension du champ.
Tableau VI.2: Les interfaces d'OPNET.

VI.6.5 Excution de la simulation


Aprs avoir dfini tous les modles du systme de rseau, Nous pouvons le valider par la simulation afin d'tudier les performances et le comportement du systme. Gnralement, il y a deux tapes pour l'excution de simulation et la collection de l'information :

53

Conclusion et perspectives

VI.6.5.1 Spcification des Donnes collecter


Les modles dvelopps doivent toujours dcider quelle information devrait tre extraite partir de la simulation. Ceux-ci peuvent prendre diffrentes formes comprenant des animations visuelles, sries dpendantes de valeurs de temps (vecteur), et des rapports paramtrs (scalaires).

VI.6.5.2 Construction et Excution De Simulation


L'excution de la simulation est l'tape finale dans une "itration" d'une exprience modulante. En gnral, en se basant sur les rsultats observs pendant cette tape, des changements sont faits aux spcifications du modle ou aux paramtres de la simulation. OPNET [42] fournit un certain nombre d'options pour excuter les simulations, y compris l'excution interne et externe, et la capacit de configurer les attributs qui affectent le comportement de la simulation.

VI.6.6 Simulation dOLSR dans OPNET


La solution OPNET est capable danalyser et doptimiser la topologie du rseau (i.e. analyse des configurations routeurs, switches, firewalls) ainsi que de faire du capacity planning partir de matrices de flux captures sur le rseau rel. Modeler dispose donc dun environnement de dveloppement complet qui va permettre de modifier/enrichir les protocoles dj fournis en standard mais galement dajouter de nouveaux protocoles de communications non fournis par dfaut. Le modle original dOLSR dans OPNET est dvelopp par NRL (Naval Research Laboratory) des tats unis, La Figure VI.5 est un Modle de processus OLSR.

Figure VI.4: Modle de nud (Manet Station). 54

Figure VI.5: Le modle processus.

Conclusion et perspectives

Le code source des tous les modles de protocoles est disponible dans Modeler. Il est donc tout fait possible de modifier/ajouter des protocoles de communication. Larchitecture de modlisation dans Modeler comporte trois niveaux :

- Modle de rseau: C'est le niveau le plus lev de la hirarchie d'OPNET. Il permet de dfinir la topologie du rseau en y installant des routeurs, des htes, des quipements tels que des Switchs, relis entre eux par des liens. Chaque entit de communication (appele nud) est entirement configurable et est dfinie par son modle. Le modle de rseau que nous avons conu pour simuler et valuer notre proposition se compose de 20 nuds plac alatoirement dans une zone de simulation de 2000M sur 2000M. Le modle de mobilit que nous avons choisi est le modle RWP (Random WayPoint), avec la vitesse des mobiles varies entre 0 et 25 m/s, temps de simulation est de 900 seconde.

- Modle de nud : Il va permettre de dfinir larchitecture interne dun nud particulier. Par exemple, la Figure VI.4 prsente le modle interne dun utilisateur Manet station.

On retrouve une architecture qui suit la pile OSI. Si lon dsire accder au code source des protocoles, il faut alors atteindre le troisime niveau de modlisation, appel le "Process Model" dans lequel le fonctionnement dun protocole particulier est ralis sous forme de machine tats finis. Par exemple, la Figure VI.5 prsente des machines tats qui codent le protocole OLSR : Etat Init : Pour initialiser ltat et les paramtres (valeurs des variables) du nud dans un tat initial (initialiser toutes les valeurs des statistiques rcolter au cours de la simulation zro, cration de table de routage vide, table de voisinage vide, etc.). Etat wait : Cet tat contient quatre transitions vers lui-mme : TC_TIMER_EXPIRY: a chaque intervalle de temps (TC_TIMER) cet tat fait appel la fonction olsr_rte_tc_expiry_handle (); pour renouveler la table de topologie. Les transitions suivantes: HELLO_PROCESSING_TIMER_EXPIRY, RTE_CALC_TIME_EXPIRY, HELLO_TIMER_EXPIRY Font appel aux fonctions (olsr_hello_processing_expiry(), olsr_rte_calc_expiry_handle(), olsr_rte_hello_expiry_handle()) l'order.
55

Conclusion et perspectives

VI.6.6.1 Mtrique de performances mesures


Dans le but de tester le protocole S_OLSR, La simulation est faite par rapport mtriques suivantes: Le nombre de fois de recalcule de MPRset (MPR CALC) Le nombre de fois de calcul de table de routage (Route Table Calc) Le nombre des MPR calcul par chaque nud (MPR Count)

VI.6.6.2 OPNET Model Paramtres

AD-HOC Routing Paramtres

AD-HOC Routing Protocol

OLSR
2.0s 5.0 s 15.0 s

Hello Interval

OLSR Paramtres

TC Interval Topology Hold Time

Wireless LAN Paramtres

Transmit Power
Tableau VI.3: Les paramtres du Simulation.

0.001 w

VI.6.6.3 Complments pratiques sur Modeler


Dans cette section on va prsenter la liste des fichiers qui constitue le protocole OLSR sur OPNET. olsr_rte.pr.m (le modle de processus principal): Produit/traite des paquets de contrle d'OLSR. Maintient des tables OLSR et actualise IP la table de routage commune.

olsr.h : dfinit des structures des tables OLSR. olsr_pkt_support.h : dfinit des formats de paquet OLSR. olsr_support.h/ex.c : dfinit des fonctions de soutien d'OLSR.

56

Conclusion et perspectives

VI.7 Analyse des rsultats de simulation


Dans ce qui suit, nous allons prsenter les rsultats de simulation de notre proposition SOLSR, en les comparants avec le protocole standard OLSR.

VI.7.1 Mtrique de MPR Calcs

Figure VI.6 : MPR Calc.

Nous pouvons constater aprs analyse de ce graphe que notre protocole S-OLSR donne les mmes rsultats (Le nombre de fois de recalcule de MPRset) que le protocole OLSR dans le dbut de la simulation ce qui est expliqu par la rcolte des informations concernant la stabilit des nuds dans cette phase. Apres cette phase on peut remarquer clairement que notre protocole minimise la recalculation des MPRset par a port au protocole OLSR, cela est due au choix des MPR stable.

57

Conclusion et perspectives

VI.7.2 Mtrique de Route Table Calcs

Figure VI.7 : Route Table Calc.

Daprs La figure VI.6 le protocole S_OLSR a le mme comportement que le protocole OLSR dans la premire phase (rcolte des informations concernant la stabilit de nud), ce qui explique que le recalcule des tables de routage (Route Table Calcs) est identique dans les deux protocoles comme il est illustr sur la figure VI.7. Apres cette phase le protocole S_OLSR diminue clairement le recalcule des tables de routage, cela dmontre que les chemins installs sont plus stables et durables par a port le protocole standard.

58

Conclusion et perspectives

VI.7.3 Mtrique de MPR Count

Figure VI.8 : MPR Count.

Ce graphe montre que notre protocole lit plus de MPR par port au protocole OLSR car il se base sur la stabilit des MPR et non pas sur le degr de rechabilit qui minimise ce nombre, mais cette diffrence est trs minimale (un MPR en moyenne sur le graphe).

Conclusion Dans ce chapitre on a dcrit en premier lieu les diffrents concepts de la simulation des rseaux. Apres on a dtaille la simulation sous OPNET Modeler. Enfin on a prsent et expliqu les rsultats de la simulation du protocole S_OLSR.

59

Conclusion et perspectives

Conclusion et perspectives "En toute chose il faut considrer la fin."


Jean de La Fontaine, Le Renard et le Bouc (III, 5)

Un rseau AdHoc est un ensemble autonome et coopratif de nuds mobiles qui se dplacent et communiquent par une transmission sans fil qui ne suppose pas d'infrastructure prexistant. Le rseau AdHoc se forme de manire spontane et provisoire ds que plusieurs nuds mobiles se trouvent porte radio les uns des autres. Les nuds communiquent, selon la distance qui les sparent, par deux modes de communication: soit les nuds mobiles peuvent directement communiquer (en transmission AdHoc) car ils sont porte de transmission, soit ils doivent utiliser d'autres nuds mobiles comme des relais pour acheminer les paquets destination Le choix des lments relais dans un rseau AdHoc mobile (nomm galement par l'instance de standardisation internet (IETF), Mobile Adhoc Network MANET), s'effectue par un protocole de routage. Plusieurs protocoles de routage sont standardiss l'IETF, savoir: AODV, DSR, OLSR, TBRF

Cette thse c'est focalis sur ces rseaux AdHoc sans fils. Elle a tudi en particulier le protocole de routage OLSR et sa technique de diffusion par relais multipoint. Dans cette thse, nous avons propos aussi un nouveau protocole de routage pour OLSR nomme (S_OLSR). Une implmentation ainsi que des mesures de performances l'chelle relle sont prsentes en fin de ce manuscrit. Autre point, l'tude par simulation, sous OPNET en considrants des scnarios proche la ralit pour des solutions de dploiement en entreprise. Nous avons montr l'efficacit de notre proposition (Stabilit de nud) dans le protocole OLSR par a port le protocole standard.

Ce travail est organis comme un article pour soumissionner dans une confrence internationale, dans un journal