COLE DE TECHNOLOGIE SUPRIEURE UNIVERSIT DU QUBEC

MMOIRE PRSENT LCOLE DE TECHNOLOGIE SUPRIEURE

COMME EXIGENCE PARTIELLE LOBTENTION DE LA MATRISE EN GNIE CONCENTRATION : RSEAUX DE TLCOMMUNICATIONS M.Ing

PAR YOUNES, Nadine

LA QUALIT DE SERVICE DES SERVICES MULTIMDIA SUR LES RSEAUX AD HOC SANS FIL MULTI-SAUTS

MONTRAL, LE 7 AOT 2009 Younes Nadine, 2009

PRSENTATION DU JURY CE MMOIRE A T VALU PAR UN JURY COMPOS DE

M. Michel Kadoch, directeur de mmoire Dpartement de gnie lectrique lcole de technologie suprieure M. Pierre Bourque, prsident du jury Dpartement de gnie logiciel et TI lcole de technologie suprieure Mme Nadjia Kara, membre du jury Dpartement de gnie logiciel et TI lcole de technologie suprieure

IL A FAIT LOBJET DUNE SOUTENANCE DEVANT JURY ET PUBLIC LE 27 JUILLET 2009 LCOLE DE TECHNOLOGIE SUPRIEURE

REMERCIEMENTS Je souhaiterais remercier les personnes qui ont contribu de prs et de loin la ralisation de ce mmoire. Cet ambitieux travail naurait pu se matrialiser sans leur support constant dans les moments difficiles et me servir de phare lorsque je naviguais. Merci Monsieur Michel Kadoch, le directeur de mon mmoire, qui a jou non seulement le rle du directeur du mmoire mais galement de mentor tout au long de la rdaction du mmoire. Ses conseils, ses expriences et son support ont t grandement apprcis. Merci Monsieur Pierre Bourque, professeur dans le dpartement de gnie logiciel et des TI lcole de technologie suprieure de me faire lhonneur de prsider le jury de soutenance. Je tiens remercier Madame Nadjia Kara, professeure dans le dpartement de gnie logiciel et des TI lcole de technologie suprieure davoir accept de faire partie du jury. Je profite de cette occasion pour remercier tous les membres du LAGRIT, spcialement Chafika, pour ses commentaires et ses aides qui ont permis de rehausser la qualit de cet ouvrage. Jaimerais remercier aussi les personnes qui m'ont support, surtout mon mari et mes enfants pour leurs encouragements. Une dernire pense tous les membres de ma famille, surtout mon cher pre pour son encouragement, sa confiance et son soutien moral malgr la distance. Finalement, je ddie ce travail lme de ma mre.

LA QUALIT DE SERVICE DES SERVICES MULTIMDIA SUR LES RSEAUX AD HOC SANS FIL MULTI-SAUTS YOUNES, Nadine RSUM Notre objectif est damliorer la performance dun rseau mobile Ad Hoc multi-sauts en essayant davoir une meilleure qualit de service en contrlant le dlai de bout en bout, la gigue des services multimdia et de plus rduire les pertes. En fait, nous ajouterons un correcteur derreurs de type FEC (Forward Error Correction), le Reed Solomon, au rseau MANET afin de minimiser le nombre derreurs causes par les diffrents problmes tels que les problmes des nuds cachs et la rduction de la puissance. En outre, nous appliquerons le mode EDCA (Enhanced Distributed Channel Access) qui est un protocole d'accs au medium utilis dans la norme IEEE 802.11e qui permet dappliquer une diffrenciation de services sur les rseaux sans fils afin davoir une certaine QoS dans le rseau. Vu que les stations dun rseau MANET sont rduites dans leur capacit de traitement, il est important dutiliser le minimum de mthodes, savoir la QoS seule, le FEC seul ou les deux de faon combine qui apporteront la QoS requise. La simulation a t utilise pour analyser le rseau MANET sous les conditions requrant la QoS et nous avons appliqu les mthodes mentionnes prcdemment pour mesurer notre approche. Le logiciel utilis est lOPNET 14.0. Les rsultats montrent une amlioration dans la performance du rseau. Mots cls : Rseaux mobiles Ad hoc (MANET), la correction derreurs FEC, La qualit de service QoS, EDCA, OPNET

QUALITY OF SERVICE OF MULTIMEDIA SERVICES IN MUTIHOP AD HOC WIRELESS NETWORK YOUNES, Nadine ABSTRACT Multimedia applications audio/video won popularity during the last years. The adaptation of these services in MANET requires a quality of service. The objective of this research is to improve the performance of a multi hop mobile Ad Hoc Network by having a better quality of service via controlling the end to end delay, the jitter of the multimedia services and moreover reducing the losses. In fact, we will add the Reed Solomon, a type of FEC (Forward Error Correction), to the MANET network in order to minimize the number of errors caused by the various problems such as the problems of the hidden nodes and power reduction. Moreover, we will apply the EDCA (Enhanced Distributed Channel Access) which is a medium Access Protocol in the IEEE 802.11e standard to apply the differentiation services in the wireless networks to have a QoS in the network. Considering the fact that the stations of a MANET network have a reduced capacity of treatment, it is important to use the minimum of methods such as FEC alone or QoS alone or both which insure the required QoS. Using simulation, we analyzed the MANET network under conditions that require QoS and we applied the methods mentioned previously to measure our approach. We used the software OPNET 14.0. The results show an improvement in the performance of the network. Key Words: Mobile Ad hoc Networks (MANET), Forward Error Correction FEC, Quality of Service QoS, EDCA, OPNET

TABLE DES MATIRES Page INTRODUCTION .....................................................................................................................1 CHAPITRE 1 LES RESEAUX MOBILES AD HOC (MANET) ..........................................4 1.1 Rseau mobile Ad Hoc (MANET) ................................................................................4 1.2 Caractristiques des rseaux Ad hoc mobiles ................................................................6 1.3 Rseau Ad hoc sans fil : Principes de fonctionnement ..................................................7 1.3.1 Le problme des stations caches ................................................................. 10 1.3.2 Le problme des stations exposes ............................................................... 12 1.4 Les applications des rseaux Ad hoc mobiles..............................................................12 1.5 Le routage dans les rseaux Ad hoc .............................................................................13 1.5.1 Protocoles de routage proactifs ..................................................................... 14 1.5.2 Protocoles de routage ractifs ....................................................................... 16 1.5.3 La puissance .................................................................................................. 19 1.5.4 La qualit de service dans MANET .............................................................. 20 CHAPITRE 2 LA QUALIT DE SERVICE (QoS) .............................................................21 2.1 Qu'est ce que la QoS ? .................................................................................................21 2.1.1 La bande passante ......................................................................................... 21 2.1.2 Le dlai.......................................................................................................... 22 2.1.3 La gigue ........................................................................................................ 23 2.1.4 La perte ......................................................................................................... 24 2.2 Que se passe t-il sans QoS ...........................................................................................25 2.3 Exemples des files dattente pour le traitement diffrenci des paquets .....................25 2.4 Les multimdias ...........................................................................................................26 2.5 Contraintes associes aux applications ........................................................................27 2.6 Contraintes spcifiques au multimdia ........................................................................28 2.6.1 Les caractristiques du trafic vido............................................................... 29 2.6.2 Les contraintes de QoS de la vido ............................................................... 29 2.7 Les modles darchitecture de QoS .............................................................................30 2.7.1 Le modle IntServ ......................................................................................... 30 2.7.2 Le modle DiffServ....................................................................................... 31 2.7.3 Le modle FQMM ........................................................................................ 34 2.8 Protocoles de la couche MAC pour les rseaux WLAN..............................................35 2.8.1 Le mode EDCA............................................................................................. 37 2.8.2 Le mode HCCA ............................................................................................ 38 2.9 Le contrle derreurs dans les applications Vido .......................................................39 2.10 Les codes Reed-Solomon .............................................................................................40 2.10.1 Introduction ................................................................................................... 40 2.10.2 Applications des codes Reed-Solomon ......................................................... 41 2.10.3 Le dcodage Reed Solomon.......................................................................... 42 2.10.4 Architectures pour encoder et dcoder les codes Reed Solomon ................. 43

VII

2.11

2.10.5 Larchitecture dencodeur ............................................................................. 44 2.10.6 Larchitecture de dcodage ........................................................................... 44 Les entrelacements .......................................................................................................46

CHAPITRE 3 REVUE DE LA LITTRATURE .................................................................47 3.1 Les protocoles de la couche MAC ...............................................................................47 3.2 Les protocoles de routage ............................................................................................48 3.3 La qualit de service dans les rseaux Ad Hoc ............................................................50 3.4 La correction derreurs FEC ........................................................................................52 CHAPITRE 4 SIMULATIONS DES DIFFRENTS MODLES .......................................55 4.1 Problmatique et objectifs de projet ............................................................................55 4.2 Modles de tests et configuration de rseaux ..............................................................56 4.2.1 Les modles de tests...................................................................................... 57 4.3 Implmentation du code Reed-Solomon dans OPNET ...............................................60 4.3.1 Loutil de simulation OPNET ....................................................................... 61 4.3.2 Description des tapes des pipelines de transmission dans OPNET............. 61 4.3.3 Le code Reed Solomon dans OPNET ........................................................... 64 4.4 Les modles de simulation OPNET .............................................................................65 4.4.1 MOD 1 : Modle de rfrence ...................................................................... 65 4.4.2 MOD 2 : Modle de la mobilit .................................................................... 67 4.4.3 MOD 3 : Modle de la rduction de la puissance ......................................... 69 4.4.4 MOD 4 : Modle de la mobilit et de rduction de la puissance en mme temps ...................................................................................................................... 70 CHAPITRE 5 RSULTATS ET ANALYSES .....................................................................71 5.1 Les mtriques de performance .....................................................................................71 5.2 Les critres de la qualit de service de la voix et de la vido ......................................72 5.3 Les rsultats et les analyses des modles avec background traffic bas .......................73 5.3.1 Les modles des simulations de niveau de Background traffic bas .............. 74 5.3.2 Le modle de rfrence ................................................................................. 77 5.3.3 Notation des graphes simuls........................................................................ 77 5.3.4 Les rsultats du dlai de bout en bout de la vido confrence en secondes.. 78 5.3.5 Les rsultats du dlai de bout en bout de la voix en secondes ...................... 79 5.3.6 Les rsultats de la gigue de la voix en secondes ........................................... 81 5.3.7 La perte des paquets des stations locales sans fil en bits/secondes............... 82 5.4 Les rsultats et les analyses des modles avec background trafic moyen ...................83 5.4.1 Les modles des simulations de niveau de Background traffic moyen ........ 83 5.4.2 Les rsultats du dlai de bout en bout de la vido confrence en secondes.. 85 5.4.3 Les rsultats du dlai de bout en bout de la voix en secondes ...................... 86 5.4.4 Les rsultats de la gigue de la voix en secondes ........................................... 87 5.4.5 La perte des paquets des stations locales sans fil en bits/secondes............... 88 5.5 Les rsultats et les analyses des modles avec background trafic haut .......................89 5.5.1 Les modles des simulations de niveau de Background traffic haut ............ 89 5.5.2 Les rsultats du dlai de bout en bout de la vido confrence en secondes.. 91

VIII

5.6

5.7

5.5.3 Les rsultats du dlai de bout en bout de la voix en secondes ...................... 92 5.5.4 Les rsultats de la gigue de la voix en secondes ........................................... 93 5.5.5 La perte des paquets des stations locales sans fil en bits/secondes............... 94 Les rsultats de la simulation de la mobilit et la rduction de la puissance en mme temps .................................................................................................................95 5.6.1 Les rsultats des simulations pour le background traffic de faible niveau. .. 96 5.6.2 Les rsultats des simulations pour le background traffic de niveau moyen . 98 5.6.3 Les rsultats des simulations pour le background traffic de niveau haut ... 100 Conclusion .................................................................................................................101

CONCLUSION .....................................................................................................................103 RECOMMANDATIONS ......................................................................................................106 BIBLIOGRAPHIE .................................................................................................................107

LISTE DES TABLEAUX Page Tableau 1.1 La table de routage du nud R1 ...........................................................................16 Tableau 2.2 La bande passante requise de quatre codeurs de vido .........................................30 Tableau 2.3 Compatibilit entre les valeurs DSCP et lIP precedence ....................................32 Tableau 4.1 Les paramtres de lapplication vido confrence ................................................67 Tableau 4.2 Les paramtres de lapplication voix ....................................................................67 Tableau 4.3 Les paramtres par dfaut dEDCA utiliss dans Opnet.......................................68 Tableau 5.1 Les paramtres utiliss dans la simulation ............................................................73 Tableau 5.2 Les paramtres utiliss dans la simulation ............................................................90

LISTE DES FIGURES Page Figure 1.1 Figure 1.2 Figure 1.3 Figure 1.4 Figure 1.5 Figure 1.6 Figure 1.7 Figure 1.8 Figure 1.9 Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 2.5 Figure 2.6 Figure 2.7 Figure 2.8 Figure 2.9 Figure 4.1 Figure 4.2 Figure 4.3 Figure 4.4 Le mode Ad hoc. .....................................................................................................4 Le principe de transmission dans Ad hoc. ..............................................................6 Exemple dun rseau Ad hoc. .................................................................................8 Bringing up an Ad hoc network. .............................................................................9 Exemple du problme des stations caches. .........................................................11 Exemple du problme des stations exposes. .......................................................12 Exemple de rseau mobile Ad hoc........................................................................15 La dtermination dune route selon DSR..............................................................18 Le renvoi du chemin calcul. ................................................................................18 Exemple de la gigue. .............................................................................................24 Rsum des DSCP. ...............................................................................................33 Diagramme des conditionneurs et des classificateurs. ..........................................34 Larchitecture de lIEEE 802.11e. ........................................................................36 La station legacy 802.11 et la station 802.11e ......................................................38 Mot cod typique de RS. .......................................................................................41 Architecture des codeurs systmatiques. ..............................................................44 Diagramme de dcodage. ......................................................................................45 Lentrelacement. ...................................................................................................46 Leffet du niveau de puissance sur la connectivit du rseau. .............................58 La latence. .............................................................................................................59 Les pipelines de transmission. ..............................................................................62 Le rseau Ad hoc simul dans OPNET. ................................................................66

XI

Figure 4.5 Figure 5.1 Figure 5.2 Figure 5.3 Figure 5.4 Figure 5.5 Figure 5.6 Figure 5.7 Figure 5.8 Figure 5.9

Le background traffic prsent sur le rseau Ad hoc simul. ...............................69 PEED video du modle de la mobilit avec background traffic bas. ...................78 PEED video du modle de diminution de la puissance avec background traffic bas. ...........................................................................................................78 PEED voice du modle de la mobilit avec background traffic bas. ....................79 PEED voice du modle de diminution de la puissance avec background traffic bas. ...........................................................................................................79 Gigue de la voix du modle de la mobilit avec background traffic bas. .............81 Gigue de la voix du modle de diminution de la puissance avec background traffic bas. ...........................................................................................................81 La perte des paquets du modle de la mobilit et background traffic bas. ...........82 La perte des paquets du modle de diminution de la puissance avec background traffic bas. .......................................................................................82 PEED video du modle de la mobilit avec background traffic moyen. ..............85

Figure 5.10 PEED video du modle de diminution de la puissance avec background traffic moyen.......................................................................................................85 Figure 5.11 PEED voice du modle de la mobilit avec background traffic moyen. ..............86 Figure 5.12 PEED voice du modle de diminution de la puissance avec background traffic moyen.......................................................................................................86 Figure 5.13 Gigue de la voix du modle de la mobilit avec background traffic moyen. .......87 Figure 5.14 Gigue de la voix du modle de diminution de la puissance avec background traffic moyen.......................................................................................................87 Figure 5.15 La perte des paquets du modle de la mobilit avec background traffic moyen .................................................................................................................88 Figure 5.16 La perte des paquets du modle de diminution de la puissance avec background traffic moyen. ..................................................................................88 Figure 5.17 PEED video du modle de la mobilit avec background traffic haut. ..................91 Figure 5.18 PEED video du modle de diminution de la puissance avec background traffic haut. ....................................................................................................................91

XII

Figure 5.19 PEED voice du modle de la mobilit avec background traffic haut. ..................92 Figure 5.20 PEED voice du modle de diminution de la puissance avec background traffic haut. ....................................................................................................................92 Figure 5.21 Gigue de la voix du modle de la mobilit avec background traffic haut. ...........93 Figure 5.22 Gigue de la voix du modle de diminution de la puissance avec background traffic haut...........................................................................................................93 Figure 5.23 La perte des paquets du modle de la mobilit avec .............................................94 Figure 5.24 La perte des paquets du modle de diminution de la puissance avec background traffic haut. ......................................................................................94 Figure 5.25 Les rsultats des simulations pour le background traffic de niveau faible. ..........96 Figure 5.26 Les rsultats des simulations pour le background traffic de niveau moyen..........98 Figure 5.27 Les rsultats des simulations pour le background traffic de niveau haut............100

LISTE DES ABRVIATIONS, SIGLES ET ACRONYMES ABR ADSL AF AIFS AIFSN AODV AP AQM ARQ BA BCH BER CBQ CFP CGSR CP CS CSMA CSMA/CA CTS CW CWmin Associativity-Based Routing Asymmetric Digital Subscriber Line Assured Forwarding Arbitration InterFrame Space Arbitration InterFrame Space Number Ad hoc On-Demand Distance Vector Routing Access Point Ad Hoc QoS Multicast Automatic Repeat Request Behavior Aggregate Hocquenghem, Bose et Ray-Chaudhuri Bit Error Ratios Class Based Queuing Contention Free Period Clusterhead Gateway Switch Routing Contention Period Class Selector Carrier Sense Multiple Access Carrier Sense Multiple Access with Collision Avoidance Clear-To-Send Contention Window Minimum Contention window

XIV

CWmax DCAP DCF DiffServ DIFS DRNP DSDV DSR DS-SWAN DVB DVD EDCA EDCF EF FEC FIFO FQMM FQM FTP HCCA HCF IEEE IntServ

Maximum Contention Window Distributed Channel Assignment Protocol Distributed Coordination Function Differentiated Service Distributed (coordination function) InterFrame Space Distributed Resource Negotiation Protocol Destination Sequenced Distance Vector Routing Dynamic Source Routing Differentiated Services-Stateless Wireless Ad hoc Networks Digital Video Broadcasting Digital video Disc Enhanced Distributed Coordination Access Enhanced Distributed Coordination Function Expedited Forwarding Forward Error Correction First In First Out A Flexible QoS Model for MANETs FEC QoS Multimedia File Transfer Protocol HCF Controlled Channel Access Hybrid Coordination Function Institute of Electrical and Electronics Engineers Integrated Service

XV

ITU LLQ MAC MANET MF MHVC MPEG MPEG4-AVC MPR MPT OFDM-CDMA OLSR OPNET PCDC PCF PDA PDR PEED PHB PQ QoS QoSR

International Telecommunication Union Low Latency Queue Media Access Control Mobile Ad hoc NETwork Multi-Field Multiple Heterogeneous Virtual Channels Moving pictures Experts Group MPEG4- Advanced Video Coding MultiPoint Relays Multi PaTh Orthogonal Frequency Division Multiplexing Code Division Multiple Access Optimized Link State Routing OPen NETwork Power Controlled Dual Channel Point Coordination Function Personal Digital Assistant Packet Delivery Rate Packet End to End Delay Per-Hop Behavior Priority Queuing Quality of Service QoS Routing

XVI

QRMP QSTAs RED RFC RLT RREQ RS RSVP RTP RTS SIFS SNR SSR SVC TDMA TORA ToS TXOP UP UWB VoIP WFQ WiMAX

QoS Routing with Mobility Prediction protocol Quality enhanced STAtion Random Early Detection Request for Comments Route Life Time Route Request Reed Solomon Resource ReSerVation Protocol Real Time Protocol Request to Send Short InterFrame Space Signal to Noise Ratio Signal Stability Routing Scalable Video Coding Time Division Multiple Access Temporally-Ordered Routing Algorithm Type of Service Transmit Opportunity User Priority Ultra Wideband Voice over IP Weighted Fair Queuing Worldwide Interoperability for Microwave Access

XVII

WLAN WM WRP WRR XDSL ZRP

Wireless Local Area Network Wireless Medium Wireless Routing Protocol Weighted Round Robin Queuing Digital Subscriber Line Zone Routing Protocol

travers ce document, pour viter les fausses traductions et pour la clart, les termes en anglais ont souvent t utiliss, ils sont alors en caractres italiques.

INTRODUCTION Au cours des dernires annes, plusieurs types des communications sans fils ont t dvelopps tels que les rseaux tlphoniques cellulaires, les rseaux Bluetooth, les rseaux locaux sans fils WLAN, les WiMAX, les rseaux Ultra Wideband (UWB), les rseaux Ad hoc mobiles (MANET). La plupart de ces rseaux sont des rseaux centraliss et ont besoin dadministrations centralises et dinfrastructures coteuses. Cependant, le rseau Ad hoc mobile, qui est un rseau distribu, auto-organis et multi sauts est un type diffrent de rseau qui a attir une attention particulire ces dernires annes (Chen, 2006). Un rseau Ad hoc mobile (MANET) est un systme autonome constitu de nuds mobiles relis par des liens sans fils. Les nuds du MANET jouent le rle de routeurs, se dplaant dune faon alatoire, et s'organisant arbitrairement. En consquence, la topologie du rseau MANET peut changer rapidement et de manire imprvisible. Ce type de rseau est sans infrastructure et reprsente une option attractive pour connecter spontanment des terminaux mobiles. MANET est appliqu dans le domaine militaire ou dans des situations de secours parce quil permet l'tablissement d'un rseau de transmission trs court terme et un cot trs bas. Cependant, le rseau MANET est limit par diffrentes contraintes telles que la largeur de bande, le dlai, la mobilit, etc. Les applications multimdia (voice communication, video-on-demand, video conferencing, etc..) deviennent, de plus en plus, un besoin essentiel dans la vie quotidienne et leur popularit augmente rapidement, ce qui rend le support de la qualit de service (QoS) dans les rseaux MANET une tche ncessaire. Parce que sans QoS, le multimdia fait concurrence aux donnes pour la bande passante, ce qui rend mauvaise la qualit de limage et de la voix. Afin de supporter la QoS dans MANETs, le rseau doit optimiser un ensemble de mtriques, tel que le dlai, la gigue, la largeur de bande, le taux de livraison de paquet, etc. Cependant, dans MANET, le problme de nud cach, la ncessit de partager les ressources de canal,

l'organisation distribue du rseau et la topologie dynamique apportent des dfis importants loffre de la QoS. Actuellement, il ny a pas encore de protocole standard de qualit de service adapt aux spcificits du MANET, malgr tous les travaux qui ont t effectus. Par ailleurs, la garantie de la QoS dans un rseau mobile comme MANET est trs dlicate. En outre, la nature active des stations MANETs, cause des pertes de paquet ce qui influence la fiabilit des communications. Alors, la rduction de ces pertes devient un dfi pour supporter des services multimdia dans les rseaux Ad hoc mobile. Comme le signal multimdia est bien sensible au dlai, la perte de linformation et aux erreurs de bit de canal sans fil, notre objectif est damliorer la performance dun rseau mobile Ad Hoc multi-sauts en essayant davoir une meilleure qualit de service en contrlant le dlai de bout en bout, la gigue des services multimdia et de plus de rduire les pertes. En fait, nous ajouterons un correcteur derreurs de type FEC (Forward Error Correction), le Reed Solomon, au rseau MANET afin de minimiser le nombre des erreurs, dans le rseau, causes par les diffrents problmes tels que les problmes des nuds cachs et la rduction de la puissance. Le code Reed Solomon a des proprits de correction derreurs excellente et il est robuste contre les pertes des squences des erreurs des bits. En outre, nous appliquerons lEDCA qui est un protocole d'accs au medium utilis dans la norme IEEE 802.11e qui permet dappliquer une diffrenciation de services sur les rseaux sans fils afin davoir une certaine QoS dans le rseau. Vu que les stations sont rduites dans leur capacit de traitement, il est important dutiliser le minimum de mthodes qui apporteront la QoS requise. En dautres termes, de voir si toujours il faut utiliser les deux mthodes (FEC et QoS) la fois ou lune dentre elles suffira dans certain cas.

La simulation a t utilise pour analyser le rseau MANET sous les conditions requrant la QoS et nous avons appliqu les mthodes mentionnes pour mesurer notre approche. Afin dtudier la QoS des services multimdia dans le rseau Ad hoc mobile MANET, nous comparerons les rsultats obtenus des diffrents scnarios simuls sous le logiciel OPNET dun rseau MANET avec ou sans lajout de la correction derreurs (Forward Error Correction: FEC) et avec ou sans lapplication de la QoS (lEDCA). La comparaison va se faire en variant, chaque fois, un paramtre tel que la mobilit ou la puissance, et en ajoutant un background traffic de diffrents niveaux. Le premier chapitre de ce mmoire dfinit les rseaux mobiles Ad hoc (MANET), ses caractristiques et les diffrents protocoles de routage. Le deuxime chapitre abordera la qualit de service, les applications multimdia et les codes Reed Solomon. La revue de la littrature sera traite dans le troisime chapitre. Dans le quatrime, nous dcrirons les diffrents scnarios simuler, alors que le cinquime prsentera les rsultats et les analyses des simulations.

CHAPITRE 1 LES RESEAUX MOBILES AD HOC (MANET) Au cours de ce chapitre, nous ferons une brve description du rseau Ad hoc Mobile (MANET), ses caractristiques, ses problmes et ses protocoles de routage. 1.1 Rseau mobile Ad Hoc (MANET)

MANET ou Mobile Ad-hoc NETworks, est le nom d'un groupe de travail de l'IETF (Internet Engineering Task Force) qui a t cr en 1998/99 et se charge de standardiser des protocoles de routage bass sur la technologie IP pour les rseaux Ad hoc, mobiles ou non. Une dfinition formelle de ce rseau MANET est donne dans le RFC 2501 (Corson et Macker, 1999).

Figure 1.1 Le mode Ad hoc.

Un rseau mobile Ad hoc (MANET) est constitu dun groupe de nuds mobiles sans fil, qui peut former un rseau dynamique et changer des donnes sans aucune infrastructure antrieure. Ces nuds peuvent tre dans des avions, des bateaux, des camions, des voitures, et mme sur des personnes ou sur des trs petits lments. La Figure 1.1 montre un exemple du mode Ad hoc. Le but des MANET est d'taler la mobilit aux domaines mobiles, sans fil et autonomes, o l'ensemble des nuds (qui peuvent tre soit des routeurs, soit des htes), forment eux-mmes une infrastructure de routage dans un rseau Ad hoc.

Les nuds de MANET sont constitus des metteurs et des rcepteurs sans fil munis des antennes qui peuvent tre omnidirectionnelles (diffusion), strictement directionnelles (point-point), possiblement orientables, ou une combinaison de tout a. un moment donn, dpendamment de la position des nuds, de la configuration de leur metteur-rcepteur, des niveaux de la puissance de transmission et de linterfrence entre les canaux, une connectivit sans fil existe entre les nuds sous forme de graphe multi-sauts alatoire ou de rseau Ad hoc.

La Figure 1.2 montre le principe de la transmission dans un contexte des rseaux Ad hoc o les informations passent du nud N1 N3 travers le nud intermdiaire N2. Le cercle est la zone de la couverture du nud.

Figure 1.2 Le principe de transmission dans un rseau Ad hoc. 1.2 Caractristiques des rseaux Ad hoc mobiles

Daprs (Corson et Macker, 1999), les rseaux mobiles Ad hoc sont caractriss par des proprits particulires. Chaque proprit est considre dans la littrature comme tant une problmatique en soi : a- Labsence de linfrastructure : les rseaux Ad hoc se distinguent des autres rseaux mobiles par labsence de linfrastructure fixe et par leurs contrles dcentraliss. b- Les topologies dynamiques : les nuds sont libres de se dplacer alatoirement, alors la topologie du rseau prcisment le multi-saut peut changer dune faon brusque et rapide, et peut tre constitue de liaisons unidirectionnelles et bidirectionnelles en mme temps. c- La bande passante limite et des liens dbits variables : les liens sans fil possderont toujours une capacit infrieure leurs homologues cbls. Lutilisation des mthodes de partage du canal radio (accs multiple) influence directement la bande passante rserve un terminal Ad hoc. d- Utilisation limite de lnergie : lalimentation des nuds se reposent sur des batteries ou dautres sources dnergie limites. Cette alimentation limite demande de prendre en considration loptimisation de la conservation de l'nergie.

e- Scurit physique limite : les rseaux sans fil mobiles sont gnralement plus vulnrables des attaques que les rseaux cbls fixes. En effet, la scurit est ncessaire la dmocratisation des rseaux MANET. f- Qualit des liaisons variables : cause du bruit et des interfrences entre les nuds, la qualit des liaisons peut varier. 1.3 Rseau Ad hoc sans fil : Principes de fonctionnement

Dans ce paragraphe, nous prsenterons le principe de fonctionnement du rseau Ad hoc mobile selon (Chakrabarti et Mishra, 2004). La Figure 1.3 reprsente un rseau Ad hoc multi-sauts. Le nud mobile A communique avec un autre nud B directement (simple-saut) lorsqu'un canal radio avec des caractristiques de propagation suffisantes est disponible entre eux. Autrement, la communication multi-sauts, dans laquelle au moins un nud intermdiaire doit ncessairement agir comme un routeur entre la source et la destination. Par exemple, il n'y a pas un canal radio direct (montr par les lignes) entre A et C ou A et E dans la Figure 1.3. Les nuds B et D doivent servir comme des routeurs intermdiaires la communication entre A - C, et A - E, respectivement. En effet, les rseaux Ad hoc se distinguent par la capacit de tous ces nuds fonctionner comme des routeurs sur demande. Afin dempcher que les paquets traversent les chemins infiniment longs, une condition essentielle pour choisir un chemin est que ce dernier doit tre sans boucle (loop-free). Un chemin loop-free entre une paire de nuds s'appelle une route.

Figure 1.3 Exemple dun rseau Ad hoc. Tir de Chakrabarti et Mishra (2004, p. 132)

Un rseau Ad hoc commence par au moins deux nuds annonant leur prsence (beaconing) avec leur information d'adresses respectives. Si le nud A peut tablir une communication directe avec le nud B (Figure 1.3), vrifie en changeant les messages appropris de commande entre eux, les deux mettent jour leurs tables de routage. Quand un troisime nud C joint le rseau avec son signal beacon, deux scnarios sont possibles. Dans le premier, A et B dterminent que la communication simple-saut avec C est possible. Dans le deuxime, seulement un des nuds, soit B, identifie le signal beacon de C et tablit la communication directe avec C. Ensuite, les mises jour distinctes de la topologie, qui sont constitues des mises jour des adresses et des routes, sont faites dans chacun des trois nuds immdiatement. Dans le premier cas, toutes les routes sont directes. Dans le deuxime scnario, tel quillustr dans la Figure 1.4, la mise jour de la route se produit d'abord entre B et C, puis entre B et A, et ensuite de nouveau entre B et C, confirmant la connexion mutuelle entre A et C par l'intermdiaire du B.

Figure 1.4 Bringing up an Ad hoc network. Tir de Chakrabarti et Mishra (2004, p. 133) La mobilit des nuds peut changer les connexions en temps rel, exigeant des mises jour des routes. Supposons que pour quelque raison, le lien entre B et C n'est plus disponible suivant la Figure 1.4. Les nuds A et C sont encore accessibles entre eux, bien que cette fois seulement par l'intermdiaire des nuds D et E (Figure 1.3). D'une manire quivalente, la route loop-free originale [A B C] est maintenant remplace par la nouvelle route loopfree [A D C]. Tous les nuds dans le rseau doivent mettre jour ses tables de routage appropries pour reflter ce changement de la topologie, qui sera dtect d'abord par les nuds B et C, puis transmis A et E, ensuite D. La connexion entre les nuds peut tre encore change pour d'autres raisons. Par exemple, un nud peut errer trop loin hors de la porte de transmission, sa batterie peut tre puise, ou il peut tre susceptible au mal fonctionnement de logiciel ou de matriel. Comme plus de nuds joignent le rseau ou quelques nuds existants quittent, les mises jour de la topologie deviennent plus nombreuses, complexes, et plus frquentes, ce qui diminue les ressources du rseau disponibles pour changer l'information d'utilisateur. La dcouverte d'un chemin loop-free comme une route lgitime entre une source et une destination peut devenir impossible si la topologie du rseau change trop frquemment. Ici,

10

trop frquemment signifie qu'il n'y avait pas assez de temps pour faire propager, tous les nuds pertinents, toutes les mises jour de la topologie rsultantes des derniers changements, ou plus mauvais, avant la dtermination de tous les chemins loop-free qui sadaptent aux derniers changements de la topologie. La capacit de la communication dgrade avec lacclration de la vitesse, cause de la connaissance de la topologie du rseau qui devient de plus en plus inconsistante. L'environnement sans fil partag des rseaux Ad hoc mobiles exige l'utilisation des protocoles appropris du MAC (Medium Access Control) pour attnuer les issues de contention de medium, permettre l'utilisation de la largeur de bande limite, et rsoudre les problmes des terminaux cachs et exposs (Chakrabarti et Mishra, 2004).

1.3.1

Le problme des stations caches

Il sagit dun problme trs connu dans les protocoles bass sur la contention comme Pure ALOHA, Slotted ALOHA, CSMA1, IEEE 802.11, etc. Lorsque deux nuds cachs lun de lautre (hors de la porte de la transmission) essaient de transmettre de linformation au mme nud de rception, par consquent une collision de donnes se produit la rception (Toh, 2002). Soit le scnario de la Figure 1.5, o une barrire empche le nud B de recevoir la transmission de D, et vice versa, ou, B et D ne peuvent pas sentendre. La barrire ne doit pas tre physique; la distance assez grande sparant deux nuds est la barrire qui peut se produire frquemment dans les rseaux Ad hoc. Le nud C peut entendre B et D. Quand B transmet C, D qui ne peut pas entendre B, peut aussi transmettre C, ce qui entrane une collision et expose le problme du terminal cach. Dans ce cas-ci, B et D sont cachs lun de lautre (Chakrabarti et Mishra, 2004).

CSMA Carrier Sense Multiple Access

11

Figure 1.5 Exemple du problme des stations caches. Tir de Chakrabarti et Mishra (2004, p. 134) Pour viter la collision, tous les nuds voisins au rcepteur doivent tre informs que le canal est occup. Ce qui peut tre atteint par un protocole simple d'change de message. Quand D souhaite transmettre C, il envoie d'abord un message RTS (Request to Send) C. Dans la rponse, C annonce un message CTS (Clear-To-Send) qui est reu par B et D. Puisque B a reu le message de CTS non sollicit, B sait que C accorde la permission d'envoyer une borne cache et par consquent s'abstient la transmission. Lors de la rception du message CTS de C en rponse son message RTS, D transmet son propre message. Notons que la mthode RTS-CTS nest pas une solution parfaite pour le problme de nud cach. Parce quil y aura des cas o des collisions se produisent quand les messages de contrle RTS et CTS sont envoys par des nuds diffrents. Pour plus de dtails voir (Toh, 2002).

12

1.3.2

Le problme des stations exposes

La transmission des donnes des nuds voisins peut empcher un nud de transmettre aux autres nuds. Il sagit dun problme des nuds exposs. Un nud expos est un nud dans la porte de transmission de lmetteur mais hors de la porte du rcepteur (Toh, 2002). Soit lexemple de la Figure 1.6, quand C transmet D. Puisque B peut entendre C et B na aucun moyen de savoir que la transmission quelle veut engager avec A nentrainerait pas de collision, alors B ne peut pas risquer de transmettre A par crainte de causer une collision C, alors B est expos au C.

Figure 1.6 Exemple du problme des stations exposes. La solution du problme de nud expos est lutilisation des canaux de contrle et de donnes de faon spare ou lutilisation des antennes directionnels (Toh, 2002). 1.4 Les applications des rseaux Ad hoc mobiles

Quelques applications de la technologie MANET peuvent inclure des applications industrielles et commerciales, entranant des changes de donnes. En plus, des applications lors de catastrophes naturelles (tremblement de terre, dsastre naturel, etc) pour la mise en communication d'units de secours sur des zones larges. Il y a aussi des applications militaires pour assurer la liaison entre les diffrentes units d'une arme. Les rseaux

13

MANET peuvent tre utiliss au niveau local pour faire un rseau multimdia autonome instantan l'aide des ordinateurs portables ou des PDA (Personal Digital Assistant) dans une confrence ou une salle de classe (par exemple). Les rseaux Ad hoc sont utilisables aussi comme des rseaux de capteurs (sensor-networks) o les nuds dtiennent des capteurs, par exemple de temprature, et une autre application des MANET est dans les rseaux domestiques (home networks). 1.5 Le routage dans les rseaux Ad hoc

Le routage est une mthode d'acheminement des informations la bonne destination travers un rseau donn. Le rle de routage est de dterminer un acheminement optimal des paquets travers le rseau selon un certain critre de performance. La zone de couverture radio est limite, par consquent les informations dans les rseaux Ad hoc peuvent exiges plusieurs sauts pour tre transportes. Alors, le routage devient un mcanisme indispensable pour supporter la transmission radio multi-sauts. Les nuds des rseaux Ad hoc changent frquemment de position dune faon alatoire et imprvisible, ce qui aboutit des interruptions et des ruptures brusques des liaisons. Pourtant, les changements rapides de la topologie dans les rseaux Ad hoc demandent des protocoles de routage spciaux qui sadaptent facilement. En fait, des protocoles de routage pour les rseaux Ad hoc ont t dvelopps dans le cadre du groupe de recherche MANET de IETF (Internet Engineering Task Force). Pour valuer les performances d'un protocole de routage, nous avons besoin des mesures qualitatives et quantitatives simultanment. Ces mtriques doivent tre indpendantes de tous les protocoles de routage existants. Les proprits qualitatives souhaitables sont : le traitement distribu, la libert de bouclage, le traitement bas sur la demande, le traitement proactif dans certains contextes, la scurit, le traitement des priodes de "sommeil" et le support des liaisons unidirectionnelles. Cependant, les units quantitatives requises sont : le flux et le dlai de donnes de bout en bout, le temps d'acquisition d'itinraires, le pourcentage de rception dans le mauvais ordre, lefficacit. De plus, il faut considrer le contexte du

14

rseau dans lequel les performances du protocole sont mesures. Les paramtres essentiels sont : la taille du rseau, la connectivit du rseau, le taux de changement de topologie, la capacit des liaisons, le taux de liaisons unidirectionnelles, le type de trafic, la mobilit, et le ratio et la frquence des priodes de sommeil des nuds. En outre, il apparat important que toute conception de protocole de routage doit tudier les problmes suivants : Minimiser la charge du rseau ; Offrir un support pour pouvoir effectuer des communications multi-sauts fiables ; Assurer un routage optimal ; Offrir une bonne qualit concernant le dlai (Corson et Macker, 1999).

Selon la faon de la cration et de la maintenance des routes lors de l'acheminement des donnes, ces protocoles sont diviss en deux catgories : Les protocoles proactifs ; Les protocoles ractifs.

1.5.1

Protocoles de routage proactifs

Les protocoles de routage proactifs sont bass sur la mme philosophie des protocoles de routage utiliss dans les rseaux cbls traditionnels tels que les protocoles dtat de lien (Link State) et ceux du vecteur de distance (Distance Vector). Ce type de protocoles exige une mise jour priodique des tables de routage. Exemples de ces protocoles: DSDV (Destination Sequenced Distance Vector Routing), OLSR (Optimized Link State Routing), CGSR (Clusterhead Gateway Switch Routing) et WRP (Wireless Routing Protocol). Les deux premiers protocoles DSDV et OSLR seront dtaills dans les paragraphes suivants. Le protocole de routage DSDV Le protocole DSDV ou (Destination Sequenced Distance Vector), dvelopp en 1994 par C. Perkins, est bas sur l'algorithme distribu de Bellman-Ford en rajoutant quelques

15

amliorations. Chaque station mobile maintient une table de routage qui contient toutes les destinations possibles, le nombre de sauts ncessaire pour atteindre la destination et le numro de squences qui correspond un nud destination. La mise jour de la table de routage dpend des deux paramtres qui sont la priode de transmission et les vnements. La mise jour du paquet contient le nouveau numro de squence incrment du nud metteur ainsi que l'adresse de la destination, le nombre de sauts et le numro de squence tels qu'ils ont t crits par la destination pour chaque nouvelle route. Le DSDV limine les deux problmes de boucle de routage "routing loop", et celui du "counting to infinity". Le DSDV prouve quelques dsavantages : il demande une mise jour rgulire de ses tables de routage, ce qui rduit l'efficacit de la largeur de bande. Toutefois, dans ce protocole, le nud mobile doit attendre jusqu' ce qu'il reoive la prochaine mise jour initie par la destination, afin de mettre jour la table de routage. De plus, il n'est pas appropri au trs grand rseau cest dire quil nest pas mis lchelle. Ainsi, il n'est pas adapt pour les rseaux fortement dynamiques. La Figure 1.7 illustre un exemple dun rseau Ad hoc constitu de 5 nuds (de R1 R5) et le Tableau 1.1 montre la table de routage du nud R1.

Figure 1.7 Exemple de rseau mobile Ad hoc.

16

Tableau 1.1 La table de routage du nud R1

Destination R1 R2 R3 R4 R5

Nombre de sauts 0 1 2 1 1

Prochain nud R1 R2 R2 R4 R5

Numro de squence 1 4 5 6 3

Le protocole OLSR Le protocole OLSR (Optimized Link State Routing), dvelopp pour les rseaux MANETs, est le sujet du RFC 3626. Il est bas sur la mthode "tat de lien" et permet d'ch anger des informations sur la topologie du rseau avec les autres nuds. OLSR utilise le principe du relais multipoints MPR (MultiPoint Relays). Tous les nuds du rseau envoient des messages "HELLO" pour dterminer la nature des liens qui les relient et dcouvrir lensemble du rseau. Ensuite, ces messages HELLO transmettent l'tat et le type de lien entre l'expditeur et chaque nud voisin puis ils spcifient le MPR choisi par l'expditeur. Ces nuds particuliers MPR expdient des messages de diffusion pendant le processus d'inondation et produisent les messages dtat de lien.

1.5.2

Protocoles de routage ractifs

Les protocoles de routage ractifs crent et maintiennent les routes selon les besoins. Lorsquune route est demande, une procdure de dcouverte globale est lance par la source afin de trouver le meilleur chemin. Exemples des protocoles ractifs : Dynamic Source Routing (DSR), Ad hoc On-Demand Distance Vector Routing (AODV), Temporally-Ordered Routing Algorithm (TORA), Associativity-Based Routing (ABR) et Signal Stability Routing (SSR). Dans ce qui suit, nous crivons en dtails les deux protocoles DSR et AODV.

17

Le protocole de routage DSR Le protocole "Routage Source Dynamique" (DSR : Dynamic Source Routing protocol), est bas sur la technique de routage par la source, sujet du RFC 4728 (Fvrier 2007). La source des donnes dtermine la squence complte des nuds intermdiaires par lesquels les informations vont transiter. Quand un nud veut envoyer des donnes, il diffuse un paquet requte route request qui contient un champ permettant denregistrer tous les nuds quil va visiter jusqu latteinte de la destination. En cas de dcouverte dune route, la source reoit un paquet rponse de la route route reply qui contient la squence des nuds traverss. Ensuite, la source insre la squence de nuds de la route reconnue dans lentte de tous les paquets quil dsire transmettre. Dans ce cas, les nuds intermdiaires jouent un rle de simple relayeur dinformation. la rception dun paquet, chaque nud supprime son adresse de la squence de nuds contenue dans lentte, puis lachemine au nud suivant dans la squence. Figure 1.8 et la Figure 1.9 illustrent le fonctionnement de la dcouverte de route, notons que le nud R1 est la source et le nud R6 est la destination.

18

Figure 1.8 La dtermination dune route selon DSR.

Figure 1.9 Le renvoi du chemin calcul.

Le protocole DSR excute une procdure de maintenance de routes afin d'assurer la validit des chemins utiliss. Un message erreur de route route error est envoy l'metteur original du paquet, lors de la dtection dun problme majeur. Ce message contient l'adresse du nud qui a dtect l'erreur et celle du nud suivant dans le chemin. Lorsque le nud source reoit ce message derreurs, le nud concern par l'erreur est supprim du chemin sauvegard, et tous les chemins contenant ce nud sont coups ce point l. Ensuite, l'metteur initie une nouvelle opration de dcouverte de routes vers la destination. Les paquets de donnes contiennent toutes les dcisions de routage ce qui rsulte que les nuds intermdiaires n'aient pas besoin de maintenir les informations de mise jour pour envoyer les paquets de donnes. Dans ce protocole, il ny a pas de boucle de routage, parce que la route entre la source et la destination est une partie des paquets de donnes envoys. Le protocole de routage AODV Le protocole AODV (Ad-hoc On Demand Vector Distance), sujet du RFC 3561, reprsente une amlioration de l'algorithme DSDV (dj discut) et il peut tre aussi vu comme un hybride des protocoles DSDV et DSR. Il est prvu pour tre utilis par les rseaux Ad hoc mobiles. Lamlioration par rapport au DSDV rside dans le fait que, le protocole AODV permet de mettre jour la table de routage dun nud sans que celui-ci ait communiquer

19

avec tous ses voisins ce qui diminue considrablement le nombre de paquets diffuss dans le rseau. L'AODV utilise le principe des numros de squence pour maintenir la consistance des informations de routage. Comme dans le DSR, l'AODV utilise le principe dinondation pour trouver une route vers une certaine destination en envoyant un paquet RREQ route request . Cependant, contrairement au DSDV, chaque nud recevant ce paquet prpare une entre dans sa table de routage afin de pouvoir rediriger plus tard les paquets quils recevront. Le paquet RREQ contient dans le champ numro de squence destination le dernier numro de squence associ la destination. Ce numro est recopi de la table de routage. Si ce numro nest pas connu, la valeur nulle ne sera prise par dfaut. Afin de maintenir des routes consistantes, une transmission priodique du message "HELLO" est effectue. Un lien est considr dfaillant, si trois messages "HELLO" ne sont pas reus conscutivement partir d'un nud voisin. Le protocole AODV ne prsente pas de boucle de routage et vite le problme "counting to infinity" de Bellman-Ford, ce qui offre une convergence rapide quand la topologie du rseau Ad hoc varie.

Notons quil existe aussi des protocoles hybrides qui utilisent lune ou lautre des deux types des protocoles selon le cas comme le protocole ZRP (Zone Routing Protocol).

1.5.3

La puissance

La distance maximale de communication entre deux nuds de WLAN est une fonction de trois paramtres: la puissance de transmission de lmetteur, le modle de propagation de perte de route path-loss, et le seuil de la puissance de rception (sensibilit du rcepteur) du nud de rception. La norme IEEE 802.11 limite la distance entre les nuds de WLAN 300 mtres. Par consquent, les rseaux de WLAN qui se prolongent au del de 300 mtres pourraient encourir une dgradation de performance dans l'algorithme de MAC de WLAN (OPNET documentation).

20

Afin de crer des problmes dans le rseau de simulation, nous avons loign la destination de la source et nous avons diminu la puissance des stations pour affaiblir le signal entre la source et la destination et produire des situations derreurs dans le rseau pour bien montrer leffet de FEC. 1.5.4 La qualit de service dans MANET

cause de ses topologies dynamiques, ses capacits de traitement et ses bandes passantes limites, les MANET exigent des contraintes additionnelles celles des rseaux filaires. Laccroissement des services multimdia dans les rseaux mobiles Ad hoc, les forts besoins de garantir la qualit de service et les contraintes particulires de ces rseaux ont amen dvelopper des protocoles et des modles de qualit de service (QoS) ddis pour les rseaux Ad hoc. Avant daborder la qualit de service dans les rseaux Ad hoc, il faut, tout dabord, dfinir la qualit de service qui sera le sujet du prochain chapitre.

CHAPITRE 2 LA QUALIT DE SERVICE (QoS) Dans ce chapitre, nous dfinirons la notion de la qualit de service et les contraintes quelle affronte dans les rseaux mobiles Ad hoc. Nous prsenterons aussi les modles darchitecture de la QoS qui sont le DiffServ et lIntServ et le FQMM. De plus, nous exposerons quelques protocoles de la couche MAC dans WLAN. En outre, nous dcrirons les services multimdia et ses diffrentes contraintes. la fin de ce chapitre, nous aborderons le code Reed Solomon qui est un type de correction derreurs FEC (Forward Error Correction). Ce code sera utilis dans nos simulations comme vous pouvez le constater dans les chapitres qui suivent. 2.1 Qu'est ce que la QoS ?

La qualit de service ou QoS (quality of service) est une expression qui na pas toujours t clair. Son but, selon www.cisco.com, est de fournir le meilleur et le plus prvisible service de rseau en fournissant une bande passante rserve, une gigue et un dlai contrls, et en amliorant les caractristiques des pertes de paquets. Nous pouvons donc dire que la QoS est un ensemble d'outils qui permet de mieux grer et contrler le rseau en rglant la bande passante, le dlai, la gigue et la perte de paquets. En gnral, la qualit de service nappartient pas une couche particulire mais elle demande des efforts coordonns de toutes les couches. 2.1.1 La bande passante

Laugmentation de la capacit de la bande passante rsout les problmes de congestion mais cest une solution court terme, trs couteuse et ne garantit pas une qualit de service QoS pour le trafic exigeant comme la VoIP et la vidoconfrence. De plus, elle permet que toutes les applications reoivent le mme traitement ce qui ne protge pas le trafic critique de l'entreprise contre des nouvelles applications.

22

Les outils de QoS qui affecte la bande passante La compression amliore la bande passante en comprimant les enttes ou les donnes significatives et en rduisant le nombre de bits total requis pour transmettre des donnes. Le contrle dadmission affecte aussi la bande passante en diminuant la charge introduite dans le rseau en rejetant les nouveaux appels de la voix et de la vido. En outre, la mise en file dattente affecte la bande passante en rservant une quantit minimale de bande passante pour des types particuliers de paquets. 2.1.2 Le dlai

Il y a deux sortes de dlais qui sont les dlais fixes et les dlais variables : Les dlais fixes Dlai de srialisation : cest le temps pris pour encoder les bits dun paquet sur le lien physique. La formule utilise pour calculer ce dlai est :
le nombre des bits envoys la vitesse du lien

Dlai de propagation : cest le temps pris pour quun bit passe de la fin dun routeur lautre routeur. La formule utilise pour calculer ce dlai est :
longueur de lien la vitesse de la lumire

Il est important de noter que la vitesse de la lumire utilise dans les rseaux sans fil est rduite et cette rduction est due lattnuation cause par le conduit transportant le signal. Dlai de codage : cest le temps de conversion Analogique/numrique par le codeur, et vice-versa.

23

Les dlais variables Dlai de queue : cest le temps dattente dans les queues des quipements. Dlai de traitement (processing) : cest le temps requis ds la rception du paquet jusqu la mise en file dattente pour transmettre. Dlai de compression : cest le temps pris pour faire la compression. Dlai de shaping : le dlai produit par lutilisation du shaping. Dlai du rseau : cest le dlai cr par le trafic traversant les composants du rseau.

Les outils de QoS qui affecte le dlai : Lordonnancement de la file dattente affecte le dlai en arrangeant les paquets selon leur priorit. Ceux qui sont plus sensibles seront servis en premier. La fragmentation aussi affecte le dlai en divisant les grands paquets en petits paquets pour ne pas retarder le trafic sensible au dlai aprs la transmission des grands paquets car le routeur ne peut pas arrter un paquet une fois commenc transmettre. La compression et le shaping affectent aussi le dlai. Le shaping retarde les paquets en les mettant dans des files dattente mme quand une bande passante relle est disponible. 2.1.3 La gigue

La gigue est la variation des dlais travers le rseau. La Figure 2.1 illustre un exemple de la gigue lors de la transmission de trois paquets dun appel tlphonique o nous remarquons qu la transmission le dlai entre les deux premiers paquets transmis est de 20 msec alors quil varie la rception. Les outils de QoS qui affecte la gigue La mise en file dattente, la fragmentation, la compression et le shaping sont les outils qui affectent la gigue.

24

Figure 2.1 Exemple de la gigue. Tir de Odom et Cavanaugh (2004, p. 27)

2.1.4

La perte

Les routeurs perdent ou jettent les paquets pour plusieurs raisons. La plupart dentre eux ne peuvent pas tre rsolus par les outils de QoS. Les outils de QoS qui affecte la perte: Quelques outils de QoS peuvent affecter la perte des paquets, tels que la mise en file dattente qui a pour effet de crer de grandes files d'attente ce qui augmente le dlai. Le RED (Random Early Detection) permet de jeter les paquets alatoirement quand les queues commencent tre pleines.

25

2.2

Que se passe t-il sans QoS

Dans des rseaux sans qualit de service, les trafics de la voix, de la vido et des donnes sont assujettis aux problmes de performance: Dans un rseau IP, les quipements et les stations dextrmit qui portent les donnes et la voix ensemble ne peuvent pas diffrencier le trafic qui a besoin dune priorit leve du trafic qui ne demande pas un service prioritaire. Mais, la voix exige des garanties de QoS plus grandes que le trafic de donnes. Alors, sans QoS, la voix pourrait ne pas tre comprise, elle pourrait tre entrecoupe, d aux dlais importants et aux dconnexions. Sans QoS, la vido fait concurrence aux donnes pour la bande passante ce qui influe sur la qualit de service et cause une image trs saccade, la non synchronisation avec la voix et un mouvement lent. Par consquent, les paquets multimdia arrivent en retard lorsquelles ne sont plus utiles. 2.3 Exemples des files dattente pour le traitement diffrenci des paquets

Voici des diffrents exemples de file dattente pour le traitement diffrenci des paquets : Priority Queuing (PQ) : les files d'attentes privilgies ont la priorit la plus leve, le taux des arrives plus petit que le taux de dpart. Weighted Round Robin Queuing (WRR) : files d'attente entretenues dans la mode round robin, le temps de service proportionnels au poids. Weighted Fair Queuing (WFQ) : cest la mthode la plus juste. Le taux minimum garanti par classe. Le temps de service de chaque paquet dans chaque file d'attente est une fonction de la longueur de paquet et du poids de file d'attente. Le temps de service courant est mis jour chaque fois qu'un paquet est envoy. Class Based Queuing (CBQ): le taux maximum par classe est configur.

26

Tous les mcanismes des files dattente ont leurs avantages et inconvnients. La file dattente FIFO est bonne pour les grandes files d'attente et les environnements fast_switching avec des rsultats prvisibles. Mais ils ne mettent en application aucune politique de service. Dans la file dattente priorit le trafic prioritaire reoit une faible gigue et une basse perte de paquet. Ce type de file dattente met en application des politiques de service. La diffrence principale entre la file dattente base sur classe (CBQ) et la file d'attente priorit (PQ) est que CBQ offre au moins un certain niveau de service la file dattente basse priorit. WFQ offre une rpartition dynamique des ressources toutes les files d'attente bases sur les poids configurs. Pour plus de dtails sur la QoS et les diffrents outils des files dattentes voir (Odom et Cavanaugh, 2004) et la page de site web : http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS.html. 2.4 Les multimdias

Les systmes multimdias sont des systmes de traitement d'information traitant une combinaison des donnes de multimdia telle que le texte, les graphiques, les images, l'audio et la vido. Les applications des multimdias sont classes selon les critres suivants (Mahbubur Rahman, 2002): a) Le degr dinteractivit : certaines applications telles que la vidoconfrence, teleworking et les jeux ont besoin de plus d'interactivit et dun petit dlai de transmission que d'autres applications comme l'accs aux bases de donnes, la vido sur demande et le courriel. b) Le type de distribution: les applications de diffusion comme la tlvision et les services d'information sont distribus par multicast tandis que d'autres applications comme l'accs aux bases de donnes, groupware, la vidoconfrence et les jeux transmettent par des communications point--point ou point--groupe.

27

c) La complexit informatique: les terminaux mobiles sont limits par des ressources qui doivent tre prises en considration par des applications mobiles de multimdia : Mmoire limite Alimentation de CPU limite Batteries limites La connexion de la bande passante limite Lerreur de transmission

d) Les besoins d'entre-sortie : quelques applications ont besoin de diffrents dispositifs d'entre-sortie. Dans les terminaux mobiles d'aujourd'hui, on peut trouver des dispositifs dentre tels que le microphone, les blocs de touches, les claviers, les crans contact et des dispositifs de sortie tels que les haut-parleurs, les crans et les signaux audio. e) Sans dispositifs dentre ou de sortie. Les applications multimdias ont besoin de la transmission de diffrents types de trafics sous des contraintes variables (largeur de bande, dlai etc.). 2.5 Contraintes associes aux applications

Les contraintes des applications multimdias mettent laccent sur le dlai et les erreurs de transmission qui sont supports par une application spcifique. De telles contraintes s'appellent la qualit du service (QoS). En tlphonie, les erreurs peuvent tre tolres alors qu'un dlai de plus de quelques centaines de millisecondes est dj perceptible. Pendant la transmission de la vido, les erreurs dans les parties critiques de donnes, telles que linformation sur le mode de codage ou les voies de compensation de mouvements mnent des artefacts2 trs inquitants. Do la synchronisation entre la voix et la vido devient importante lorsque ces deux sont transmises ensemble. Enfin, la transmission de donnes graphiques soutient habituellement un grand dlai.
2

Artefact : Perturbation artificielle de l'image ou du son, qui se manifeste de manire inattendue, lorsque ces

derniers sont reproduits par un appareil selon www.granddictionnaire.com.

28

2.6

Contraintes spcifiques au multimdia

Sans qualit de service, les flots de la vido se dgradent: limage devient trs saccade, la voix n'est plus synchronise avec la vido et le mouvement apparat lent. Alors, les applications ont des besoins varis en termes de la bande passante, le dlai, la gigue et la perte des paquets. La qualit de service QoS permet au rseau de mieux (best-effort) de fournir les besoins appropris des ressources de QoS pour chaque application. Le Tableau 2.1, ci-dessous, montre quelques applications avec leurs besoins typiques de QoS. Tableau 2.1 Quelques applications avec leurs besoins de QoS

Donnes Vido Voix interactive (2 voies) Flot de vido (1 voie) Donnes (interactive et mission critique) Bande passante Perte Dlai Gigue Variable Basse haute haute typiquement moyenne Basse Bas Basse Basse Bas Basse Basse Haut Haute Moyenne Moyen Moyenne (non interactive et non mission critique) Variable typiquement haute Haute Haut Haute

29

On constate daprs le Tableau 2.1 que la voix na pas besoin dune grande bande passante mais elle ne tolre pas le dlai, ni la gigue, ni la perte (parfois elle tolre un peu de perte). La vido interactive (2 voies) telle que la vidoconfrence a les mmes caractristiques que la voix mais elle demande une grande bande passante. Nanmoins, le flot de vido (1 voie) telle que la vido e-learning peut accepter le dlai et la gigue mais ne tolre pas la perte.

2.6.1

Les caractristiques du trafic vido

Les codeurs vido convertissent laudio et la vido analogiques en numriques. La voix est envoye comme un flot spar de la vido. Les codeurs tels que les G.711 et G.729 sont utiliss pour la voix tandis quune grande varit de codeurs incluant lITU3 H.261 et le MPEG (Moving pictures Experts Group) convertissent le flux de la vido. 2.6.2 Les contraintes de QoS de la vido

La vido demande une bande passante plus grande que celle de la voix, parce quelle utilise une varit de taille et de taux de paquets pour supporter un simple flot de vido. La moyenne de la bande passante requise pour une section de vido dpend de la complexit et de la quantit du mouvement de la vido. Le Tableau 2.2 suivant cite quatre codeurs de vido et leur bande passante requise.

ITU International Telecommunication Union

30

Tableau 2.2 La bande passante requise de quatre codeurs de vido

Codeur vido MPEG-1 MPEG-2 MPEG-4 H.261

Marge de la bande passante requise 500 1500 kbits/sec 1.5 10 Mbits/sec 28.8 400 kbits/sec 100 400 kbits/sec

En outre, la vido (1 voie) tolre un peu de dlai mais le dlai dans la vido (2 voies) a vraiment un impact sur la qualit. Le dlai pour la vidoconfrence de haute qualit est de 0 200 msec. De mme, la gigue peut tre tolre dans la vido (1 voie) plus que dans celle de 2 voies. La mise en file dattente et la fragmentation rduisent la gigue. La vido ne tolre pas bien la perte des paquets. Le contrle dadmission, le RED et laugmentation de la file dattente peuvent diminuer la perte dans la vido. 2.7 Les modles darchitecture de QoS

LIEFT (Internet Engineering Task Force) propose deux approches de QoS pour les rseaux filaires qui sont les services intgrs (IntServ) et les services diffrencis (DiffServ). 2.7.1 Le modle IntServ

IntServ (Integrated Service) est un modle diffrent du DiffServ. Dans IntServ, chaque application est libre de demander une qualit de service spcifique ses besoins. Pour fournir des garanties par flux, le RFC 1633 dIntServ dcrit deux mcanismes : la rservation des ressources et le contrle dadmission.

31

La rservation des ressources s'agit d'offrir un service de type garanti tel quil existe dans les rseaux circuits en utilisant le protocole RSVP (Resource ReSerVation Protocol). Chaque routeur IntServ maintient les informations sur les tats de tous les flux comme la bande passante requise, le dlai et le cot. Le contrle dadmission dcide quand la demande de rservation doit tre rejete. IntServ possde quelque dsavantages, le RSVP ne passe pas lchelle (scalability) parce que le routeur du cur doit maintenir les tats de rservation de tous les flux qui le traversent et les messages de rafrachissement de RSVP doivent tre mis priodiquement pour chaque flux.

2.7.2

Le modle DiffServ

Le modle DiffServ (Differenciated Service) a t propos pour viter le problme de mise lchelle impos par IntServ. Il consiste diffrencier les flux dans des classes offrant chacune une qualit de service diffrente et dans lesquelles sont agrgs plusieurs flux. Le classement se fait par les routeurs de bordure grce un code prsent dans lentte du paquet IP. Les routeurs du cur de rseau utilisent ce code pour dterminer la qualit de service requise par le paquet. Tous les flux appartenant une mme classe reoivent le mme traitement. Ensuite, des traitements diffrencis seront appliqus aux diffrentes classes de trafic. DiffServ dfinit chaque classe ou catgorie de paquets comme un BA (Behavior Aggregate). Le fait dassocier un outil de QoS un BA sappelle PHB (Per-Hop Behavior). En gnral, lIP dfinit un octet (8 bits : PPPDTRC0) qui est le type de service ToS4 . Les trois premiers bits (PPP) sappellent IP precedence dfinissent la priorit du datagramme (111= la plus grande priorit). Les autres bits sont :
4

ToS Type of Service

32

D (Delay) pour le dlai sil est mis 1 c'est--dire que le service ncessite un faible dlai, T (Throughput) pour le dbit sil est mis 1 c'est--dire que le service ncessite un haut dbit, R (Reliability) pour la fiabilit sil est mis 1 c'est--dire que le service ncessite une grande fiabilit et C (Cost) pour le cot sil est mis 1 c'est--dire que le service ncessite un faible cot et le dernier bit est inutilis. Les six premiers bits de loctet ToS seront le champ DSCP (Differentiated Services Code Point) cr par DiffServ, ce qui permet 64 combinaisons diffrentes de classifications. Donc, une compatibilit avec lIP prcdence est ncessaire. Le Tableau 2.3, ci-dessous, montre la compatibilit entre les valeurs DSCP et lIP prcdence.

Tableau 2.3 Compatibilit entre les valeurs DSCP et lIP precedence

Noms des class selector Par dfaut CS1 CS2 CS3 CS4 CS5 CS6 CS7

Marge des valeurs DSCP 0-7 8-15 16-23 24-31 32-39 40-47 48-55 56-63

Valeur en binaire 000xxx 001xxx 010xxx 011xxx 100xxx 101xxx 110xxx 111xxx

Compatible avec IP precedence 0 1 2 3 4 5 6 7

PHB Best effort Classe 1 (AF) Classe 2 Classe 3 Classe 4 Express forwarding Contrle Contrle

33

DiffServ suggre deux autres ensembles de PHB et de valeurs DSCP en plus des slecteurs de classes (CS) : Assured Forwarding (AF), dfinit dans le RFC 2597, permet l'utilisateur de choisir une des 4 classes AF pour chaque flux afin de garantir un acheminement de paquets IP avec une haute probabilit. Chaque classe obtient une quantit diffrente de ressources dans les routeurs du cur du rseau. Dans chaque classe, un algorithme de rejet slectif diffrencie entre trois niveaux de probabilits de rejets. En cas de congestion, les paquets de basse priorit seront rejets en premier. Expedited Forwarding (EF) ou premium service, dfinit dans le RFC 2598 ; il a pour but de minimiser la perte, le dlai et la gigue et de garantir une bande passante. Pour cela, le RFC de EF propose deux actions de QoS : la mise en file dattente et le policing.

Figure 2.2 Rsum des DSCP. Tir de (www.cisco.com) Dans DiffServ, il y a deux types de routeurs : les routeurs de bordure (boundary) qui sont responsables de la classification, le conditionnement (Conditionner) et les routeurs du cur du rseau (interior) qui servent acheminer les paquets selon le marquage.

34

En fait, La classification se fait par le classificateur BA qui regarde seulement le champ DSCP ou par le classificateur MF (MultiField) qui regarde plusieurs champs de lentte du paquet. Les critres de classification des paquets doivent reflter les besoins rels de l'information qu'ils transportent en termes de bande passante, sensibilit aux pertes de paquets, aux dlais et aux gigues. Le conditionnement est utilis afin dempcher le trafic de dpasser le contrat. Pour arriver ce but, plusieurs types de conditionneurs sont utiliss selon les besoins : le metering qui mesure le taux de trafic, le policing qui jette des paquets, le shaping qui ralentit le trafic en le mettant en queue, le marking qui re-marque le DSCP par une autre valeur si le trafic excde le contrat. La Figure 2.3 donne un rsum des DSCP. La figure 2.3 illustre le diagramme des conditionneurs et des classificateurs cit dans le RFC 2475.

Figure 2.3 Diagramme des conditionneurs et des classificateurs.

2.7.3

Le modle FQMM

Le modle FQMM (A Flexible QoS Model for MANETs) selon (Hannan, Kee Chaing et Guan Winston, 2003), est un modle de QoS qui est conu spcialement pour des rseaux MANETs constitus de moins de 50 nuds. Ce modle utilise une architecture plate non hirarchique et dfinit trois types de nuds comme dans DiffServ : le nud dentre (ingress node) est un nud mobile qui envoie les donnes, les nuds intermdiaires qui renvoient les

35

donnes aux autres nuds, et le nud de sortie (egress node) qui est la destination. Cest un systme hybride qui combine les proprits des deux modles filaires : par flux de lIntServ et par classe de DiffServ. Dans ce systme, le par flux est utilis pour les trafics prioritaires et le par classe pour les autres trafics. Le nud dentre permet de marquer et classifier les paquets qui seront ensuite relays par les nuds intermdiaires suivant leurs PHB jusquils arrivent la destination. Pour plus de dtails sur ce modle veuillez consulter larticle (Hannan, Kee Chaing et Guan Winston, 2003). 2.8 Protocoles de la couche MAC pour les rseaux WLAN

Le mdium de contrle d'accs (MAC : Medium Access Control) de IEEE 802.11 ne possde pas la diffrenciation de service. Tous les types du trafic tels que les paquets de donnes, de la voix et de la vido, sont traits de la mme faon. Ce qui provoque une dtrioration de la qualit de la voix et de la vido quand le rseau est congestionn. La norme IEEE 802.11 dfinit deux modes de fonctionnement qui sont la fonction de coordination distribue (DCF : Distributed Coordination Function) et la fonction de coordination par point (PCF : Point Coordination Function). Dune part, DCF utilise le mcanisme CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) afin dviter les collisions et il nest utilisable qu la mode Infrastructure parce que le point daccs (AP) est le directeur. Il fournit seulement la livraison de best-effort et ne possde pas la priorit daccs au medium, ni le support au dlai, ni les exigences moyennes de la bande passante des diffrentes applications. Pour les rseaux Ad Hoc, la norme dfinit deux types despaces inter-trames qui sont le SIFS (Short Inter Frame Space) et le DIFS (Distributed Inter Frame Space). D'autre part, PCF est un systme sans contention (contention free) et il peut soutenir des applications sensibles au temps telles que la voix et la vido. Cependant, PCF ne supporte pas les mcanismes pour diffrencier les types du trafic afin davoir la qualit du service

36

(QoS), et il ny a aucuns mcanismes pour que les stations communiquent leurs exigences de QoS au point d'accs (AP). cause du manque de service de QoS fourni par la norme 802.11, lIEEE a constitu le groupe de travail E (TGe) qui a un but de concevoir une nouvelle norme connue sous le nom 802.11e afin de fournir une QoS suffisante au WLAN pour supporter des services comme la voix, la vido et d'autres, permettant au WLAN de soutenir toutes les applications et fonctions comme un rseau filaire. La norme 802.11e dfinit le HCF (Hybrid Coordination Function) qui introduit deux nouveaux systmes qui sont : EDCA et HCCA. LEDCA est une extension de DCF et le HCCA est une extension de PCF. Larchitecture de 802.11e est illustre dans la Figure 2.4.

Figure 2.4 Larchitecture de lIEEE 802.11e. Tir de Chen et Ma (2006, p. 1)

37

2.8.1

Le mode EDCA

LEDCA (Enhanced Distributed Coordination Function) est un systme d'accs bas sur la contention. Cest une extension du mcanisme DCF pour fournir un support des priorits du trafic diffrenci. La fentre de contention et les temps backoff sont ajusts pour augmenter ou diminuer la probabilit daccs au medium afin de favoriser ou dfavoriser la transmission de donnes aux flux de donnes de priorits faibles ou leves. En fait, le trafic priorit leve a une chance plus grande dtre transmis que le trafic moins prioritaire. De plus, un TXOP (Transmit Opportunity) est assign chaque niveau de priorit. Un TXOP est un intervalle de temps durant lequel une station qui a obtenu laccs au mdium peut transmettre le plus possible de trames venant du niveau suprieur. Le mcanisme EDCA fournit un accs diffrenci et distribu au milieu sans fil (WM: Wireless Medium) pour les stations de qualits amliores (QSTAs : Quality enhanced STAtion) en utilisant huit niveaux diffrents de priorits dutilisateur (UPs : User Priority) qui sont disponibles en basant sur la dsignation de la norme d'IEEE 802.1D. EDCA dfinit quatre catgories d'accs (ACs) qui sont AC_BK, AC_BE, AC_VI et AC_VO pour le trafic temps non rel (background), temps rel (Best-effort), la vido et la voix respectivement. Les ACs sont drivs dUPs tels que prsent dans la Figure 2.5.

38

Figure 2.5 La station legacy 802.11 et la station 802.11e avec quatre ACs dans une seule station. Tir de Mangold et al.(2003, p. 44)

2.8.2

Le mode HCCA

Dans le mode HCCA (HCF Controlled Channel Access), l'intervalle entre deux trames de balise (beacon frame) est divis en deux priodes CFP (Contention Free Period) et de CP (Contention Period), le HCCA permet aux CFP de transmettre n'importe quel temps pendant CP. Ce mode ne peut tre utilis que dans un mode Infrastructure o il y a un point daccs AP (Access Point). En ce qui concerne notre mmoire, nous utiliserons le mode EDCA afin dajouter la QoS notre rseau.

39

2.9

Le contrle derreurs dans les applications Vido

Les paquets vido transmis sur les canaux sans fil sont corrompus par deux types derreurs (Wang, 2005) : les erreurs alatoires stationnaires qui dpendent de la force moyenne de londe reue ou de la distance entre la station et le terminal sans fil; l'erreur variable provoque par le mouvement du terminal portable ou l'vanouissement Rayleigh. Comme le terminal portable se dplace rapidement, la frquence de la distorsion provoque par des erreurs des rafales est haute et la dtrioration dans la qualit de vido augmente. Puisque le signal vido comprim est fortement sensible la perte de l'information et les erreurs de bit de canal sans fil, la qualit de vido dcode se dtriore dune faon radicale au niveau des taux d'erreurs de bit (BER : Bit Error Ratios) du canal suprieur. Certains mcanismes de contrle d'erreurs utilisent les techniques de recouvrement de donnes qui permettent aux dcodeurs de dissimuler les effets des erreurs en prvoyant les signaux vido perdus ou corrompus des informations sans erreur prcdemment reconstruite. Ces techniques ne placent aucune redondance sur les flux de vido comprims et sont dsignes par les techniques de dissimulation des erreurs de zro-redondance. D'autres mcanismes de contrle derreurs fonctionnent au niveau du codeur et appliquent une srie de techniques pour augmenter la robustesse des signaux vido cods aux erreurs de canal. Ceux-ci sont connus comme des techniques derreurs de rsilience. Forwarded Error Correction (FEC) et Automatic Repeat Request (ARQ) sont deux catgories de base des techniques de rsilience derreurs. FEC utilise les codes correcteurs d'erreurs pour combattre les erreurs de bit en ajoutant la redondance (bits de parit) aux paquets de l'information avant qu'elles soient transmises. Cette redondance est utilise par le rcepteur pour dtecter et corriger les erreurs. Dans une situation o le dcodeur narrive pas corriger les erreurs partir les bits derreurs, ARQ est utilis et l'information incorrecte est retransmise.

40

Dans ce mmoire, nous implmenterons un type de FEC qui est le Reed Solomon dans le logiciel OPNET afin de corriger les erreurs dans le rseau simul. 2.10 2.10.1 Les codes Reed-Solomon Introduction

Les codes Reed Solomon sont des codes cycliques et ont t dcouverts par Reed et Solomon en 1960. Ces codes sont des codes correcteurs d'erreurs bass sur des blocs avec une large gamme des applications dans des communications numriques et de stockage. Les codes Reed Solomon sont utiliss pour corriger des erreurs dans beaucoup de systmes tels que: les dispositifs de stockage (disque compact CD, DVD5, codes barres, etc.), les communications sans fil ou mobiles (tlphones cellulaires, liaisons hertziennes, etc.), les communications par satellites, la tlvision numrique (DVB6), les modems grande vitesse tels que l'ADSL7, le XDSL8, etc. Le codeur Reed Solomon prend un bloc de donnes numriques et ajoute des bits redondants supplmentaires. Les erreurs se produisent pendant la transmission ou le stockage pour un certain nombre de raisons comme par exemple le bruit ou linterfrence, les raflures sur un CD, etc. Le dcodeur Reed Solomon traite chaque bloc et essaye de corriger les erreurs et de rcuprer les donnes originales. Le nombre et le type d'erreurs qui peuvent tre corriges dpend des caractristiques du code Reed Solomon.

5 6

DVD DVB 7 ADSL 8 XDSL

Digital Video Disc Digital video Broadcasting Asymmetric Digital Subscriber Line Digital Subscriber Line

41

2.10.2

Applications des codes Reed-Solomon

Les codes Reed Solomon sont un sous-ensemble de codes BCH9 et sont des codes de bloc linaires. Un code Reed Solomon est spcifi comme RS (n, k) avec des symboles s-bit. Ceci signifie que le codeur prend k symboles de donnes de s bits et ajoute des symboles de parit pour faire un mot cod de n symboles. Il y a des symboles de parit de n-k de s bits chacun. Un dcodeur de Reed Solomon peut corriger jusqu'aux t symboles qui contiennent des erreurs dans un mot cod, o 2t = n-k. Le diagramme suivant montre un mot cod typique de Reed-Solomon:

Figure 2.6 Mot cod typique de RS. Tir de Riley et Richardson (1998)

Exemple : Un code populaire Reed Solomon est RS (255,231) avec des symboles de 8 bits. Chaque mot cod contient 255 octets de mot de code, dont 231 octets sont ddis aux donnes et 24 octets sont des parits. Pour ce code: n = 255, k = 231, s = 8 alors 2t = 255 - 231 = 24, t= 12. Le dcodeur peut corriger nimporte quels 12 symboles dans le mot cod : c.--d. des erreurs jusqu' 12 octets peu importe leur place dans le mot cod peuvent tre automatiquement corriges. Soit s une taille de symbole, la longueur maximale de mot cod (n) pour un code Reed Solomon est n = 2s 1. Par exemple, la longueur maximale d'un code avec des
9

BCH Hocquenghem, Bose et Ray-Chaudhuri

42

symboles de 8 bits (s=8) est de 255 octets. Des codes Reed Solomon peuvent se raccourcir (conceptuellement) en mettant un certain nombre de symboles de donnes zro au codeur, en ne les transmettant pas, et puis en les rinsrant au dcodeur. Erreur de symboles : une erreur de symbole se produit quand au moins un bit dans le symbole est erron ou quand tous les bits dans un symbole sont errons. Par exemple: RS(255,231) peut corriger 12 erreurs de symboles. Dans le pire cas, 12 bits derreurs peuvent tre produit, chacun dans un symbole diffrent (octet) alors le dcodeur corrige 12 bits derreurs seulement. Dans le meilleur des cas, pour 12 erreurs dans un octet complet le dcodeur corrige 12 x 8 bits derreurs. Dans notre projet, nous utiliserons le code Reed Solomon pour corriger les erreurs, avec n = 255 octets et k = 231 octets. 2.10.3 Le dcodage Reed Solomon

Daprs (Riley et Richardson, 1998), les procdures algbriques de dcodage Reed Solomon peuvent corriger des erreurs et des effacements. Un effacement se produit quand la position d'un symbole err est connue. Un dcodeur peut corriger jusqu'aux t erreurs ou jusqu'aux 2t effacements. L'information d'effacement peut souvent tre fournie par le dmodulateur dans un systme de communication numrique, c.--d. le dmodulateur flags les symboles reus qui sont probable contenir des erreurs. Quand un mot cod est dcod, il y a trois rsultats possibles : 1. 2. 3. Si 2s + r < 2t ; (s erreurs, r effacements) alors le mot original transmis de code sera toujours rcupr, Sinon, le dcodeur dtectera qu'il ne peut pas rcuprer le mot cod original de code et il indique ce fait. Ou, le dcodeur dcodera mal et rcuprera un mot cod incorrecte sans aucune indication.

43

La probabilit de chacune des trois possibilits dpend du code particulier de Reed Solomon et du nombre et de la distribution d'erreurs. 2.10.4 Architectures pour encoder et dcoder les codes Reed Solomon

Les architectures pour encoder et dcoder les codes Reed Solomon sont expliqus dans (Riley et Richardson, 1998) par : Arithmtique finie de champ (de Galois) Les codes Reed Solomon sont bass sur un principe mathmatique connu sous le nom des champs de Galois ou champs finis. De plus, une des proprits du champ fini est que les oprations arithmtiques (+, -, x/etc.) relatives aux lments du champ ont toujours un rsultat dans le champ. Un codeur ou un dcodeur de Reed Solomon doit effectuer ces oprations arithmtiques. De plus, ces oprations exigent davoir des fonctions spciales de matriel ou de logiciel pour les appliquer. Le polynme de gnrateur La forme gnrale du polynme de gnrateur est :

g(x)= (x i )(x i+1 )...(x i+2t )

Et le mot cod est construit en utilisant : c (x) = g (x).i (x) Avec g (x) est le polynme de gnrateur, i (x) est le bloc de l'information, c (x) est un mot cod valide et est dsign sous le nom d'un lment primitif du champ. Exemple: le gnrateur de RS(255,231)
0 2 1 3 4 5 6 7 8 9 10 11 g ( x) = ( x )( x )( x )( x )( x )( x )( x )( x )( x )( x )( x )( x )

g( x) = x12 + g11x11 + g10 x10 + g9 x9 + g8 x8 + g7 x7 + g6 x6 + g5 x5 + g4 x 4 + g3 x3 + g2 x 2 + g1 x1 + g0

44

2.10.5

Larchitecture dencodeur

Les 2t symboles de parit dans un mot cod systmatique de Reed Solomon sont donns par:

p(x) = i(x).x

nk

modg(x)

Le diagramme suivant montre une architecture pour des codeurs systmatiques RS(255,249):

Figure 2.7 Architecture des codeurs systmatiques. Tir de Riley et Richardson (1998) Chacune des six registres contient un symbole (8 bits). Les oprateurs arithmtiques effectuent l'addition ou la multiplication de champ fini sur un symbole complet.

2.10.6

Larchitecture de dcodage

Une architecture gnrale pour le dcodage des codes Reed Solomon est montre dans le diagramme suivant.

45

Figure 2.8 Diagramme de dcodage. Tir de Riley et Richardson (1998) Avec r(x) Si L(x) Xi Yi c(x) v Le mot cod reu Syndromes Le polynme de position derreurs Les locations derreurs Les magnitudes des erreurs Le mot cod rcupr Le nombre des erreurs

Le mot cod reu r(x) est le mot cod original (transmis) c(x) plus des erreurs: r(x) = c(x) + e(x) Un dcodeur Reed Solomon essaye d'identifier la position et la magnitude de t erreurs (ou 2t effacements) et de corriger les erreurs ou les effacements. Calcul de syndrome : c'est un calcul semblable au calcul de parit. Un mot cod de Reed Solomon a 2t syndromes qui dpendent seulement des erreurs (pas sur le mot cod transmis). Les syndromes peuvent tre calculs en substituant les racines 2t du polynme de gnrateur g(x) dans r (x). Les positions derreurs de symbole : ncessitent la rsolution des quations simultanes avec t inconnus. Plusieurs algorithmes rapides sont disponibles pour faire a. Ces algorithmes

46

profitent de la structure de matrice spciale des codes Reed Solomon et rduisent beaucoup l'effort informatique exig. En gnral deux tapes sont impliques : Le polynme de position derreurs : peut tre calcul en utilisant l'algorithme de BerlekampMassey ou l'algorithme d'Euclid. L'algorithme d'Euclid tend tre plus utilis gnralement dans la pratique parce qu'il est plus facile implmenter: cependant, l'algorithme de Berlekamp-Massey tend mener des implmentations plus efficaces de matriel et de logiciel. Les racines de ce polynme : peuvent tre trouvs en utilisant l'algorithme de recherche de Chien. Les valeurs de symbole derreurs : ncessitent de rsoudre des quations simultanes de t inconnus. Un algorithme rapide qui est souvent utilis est l'algorithme de Forney. 2.11 Les entrelacements

Lentrelacement est utilis pour augmenter la capacit de correction derreurs dans les paquets. Lentrelacement consiste permuter une squence de bits de manire ce que deux symboles proches lorigine soient le plus possible loigns lun de lautre. C'est--dire, au lieu de transmettre directement les mots du code, le premier symbole de chacun des mots sera transmis, suivi par le deuxime, puis par le troisime et ainsi de suite.

Figure 2.9 Lentrelacement.

CHAPITRE 3 REVUE DE LA LITTRATURE Le support de la qualit de service sur MANET fait le sujet de plusieurs articles dans la littrature. La majorit des approches sont sur le modle de la QoS, la signalisation de rservation de ressource de la QoS, le routage de la QoS et le contrle daccs MAC (Medium Access Control) (Sarma et Nandi, 2006). Nous avons choisi quelques articles qui traitent ces sujets pour les prsenter dans ce chapitre. La plupart des articles prsents cidessous utilisent les services multimdia. En outre, nous prsenterons des articles qui sagissent de la correction derreurs FEC dans MANET. 3.1 Les protocoles de la couche MAC

Dans la littrature, les auteurs proposent diffrents protocoles pour certains problmes tels que les protocoles de la couche MAC comme EDCF10 dans (Hsu et al., 2004) et le protocole propos dans (Ogawa, Shimojima et Hattori, 2002) qui ont amlior le rapport de la livraison de paquet et la moyenne du dlai de bout en bout et ont rduit le nombre de collision de paquet. Dans larticle (Shklyaeva, Kubanek et Novotny, 2007), les auteurs analysent les amliorations dans 802.11e et comparent sa performance la norme 802.11. La nouvelle fonction hybride de coordination (HCF) de la couche MAC dIEEE 802.11e avec ses deux protocoles contention-based et contention free sont valus. Les mcanismes de fournir la QoS dans les rseaux wireless LAN bass sur la norme 802.11e sont aussi dcrits. Dans (Krunz, Muquattash et Lee, 2004), les auteurs proposent un protocole de la couche MAC qui contrle la puissance canal double PCDC (Power Controlled Dual Channel) pour les rseaux Ad hoc sans fil. En effet, ce protocole permet la couche MAC dinfluencer

10

EDCF Enhanced Distributed Coordination Function

48

indirectement la dcision de routage la couche rseau en contrlant le niveau de la puissance des paquets RREQ11 diffuss. De plus, PCDC12 utilise la force du signal de lentte de commande (RTS/CTS) pour tablir une topologie de rseau avec une puissance efficace. 3.2 Les protocoles de routage

Des solutions pour les problmes de routage ont t aussi proposes dans (Bur et Ersoy, 2004), (Wang et al., 2001), (Hsu, Sheu et Tung, 2006), (Sheikh et al., 2003), et (Taing et al., 2005). Dans ces derniers articles, les auteurs traitent les difficults de routage de diffrentes manires : Dans (Sheikh et al., 2003), les auteurs proposent un protocole de routage de QoS (QoSR : QoS Routing) bas sur la prvision du profile de la mobilit des utilisateurs afin dobtenir une transmission des services multimdia travers un rseau mobile Ad hoc avec une garantie de QoS. Ce systme tablit et maintient des MHVCs13 avec une garantie de QoS entre la source et la destination durant la dure de vie de la route RLT (Route Life Time). Mais, ce protocole ntait pas simul et par consquent, il ny avait pas des rsultats pratiques. Larticle (Hsu et al., 2004) tale un protocole de routage de QoS pour des services multimdia dans les rseaux mobiles ad-hoc (MANETs) qui est lEDCF. Ce protocole a t adopt afin de rpondre aux exigences de la QoS telles que la bande passante requise et le dlai de bout en bout pour diffrentes paires de transmission source-destination. Et de plus, pour rsoudre le nouveau problme appel le problme des routes caches. EDCF montre des bons rsultats en ce qui concerne le rapport de la livraison de paquet et la moyenne du dlai de bout en bout dEDCF. Dans (Taing et al., 2005), les auteurs prsentent un systme de routage pour des services multimdia, qui choisit le chemin le plus court en utilisant le niveau de puissance. Ce
11 12 13

RREQ PCDC MHVC

Route Request Power Controlled Dual Channel Multiple Heterogeneous Virtual Channels

49

protocole ne fournit pas seulement la plus petite moyenne du nombre des sauts de route de la source la destination, mais aussi un dbit plus lev que le systme conventionnel. Ce protocole permet de rduire le dlai de transmission de trafic de multimdia en minimisant le nombre de sauts de ce trafic. En plus, ce protocole fournit un grand dbit pour le trafic multimdia. Dans (Hsu, Sheu et Tung, 2006), les auteurs proposent un protocole de routage sur demande An On-demand Bandwidth Reservation QoS routing pour les MANETS de multi-sauts bas sur TDMA14. Ils proposent un algorithme pour guider la destination choisir la route qui est la plus susceptible de satisfaire les besoins de QoS et un algorithme pour rserver le time slot appropri et garde aussi plus des time slots libres pour d'autres besoins. Ce protocole propos donne des bons rsultats en ce qui concerne ltablissement de la route et le taux de perte de paquet. En outre, il peut atteindre une probabilit dtablissement de route leve et une probabilit de perte de paquet faible. Larticle (Bur et Ersoy, 2004) dfinit les modules d'un protocole Ad hoc de multicast de QoS (AQM15), qui ralise l'efficacit de multicast par la disponibilit de routage de ressource dans le voisinage d'un nud bas sur des rservations prcdentes, et annonce les conditions de QoS la session dinitiation. LAQM a obtenu des meilleurs rsultats en ce qui concerne le degr de satisfaction et il a amlior lefficacit de multicasting des sessions. Dans (Wang et al., 2001), les auteurs proposent un protocole de routage QoS par la prvision de la mobilit (QRMP)16. Ce protocole choisit le chemin le plus stable bas sur la prvision de la mobilit et les besoins de QoS sur la largeur de bande et le dlai. La simulation de QRMP montre une rduction dans le temps d'installation de la route et les enttes de contrles ainsi quune augmentation dans le rapport de la livraison de paquet.

14 15

TDMA AQM 16 QRMP

Time division multiple access Ad Hoc QoS Multicast QoS Routing with Mobility Prediction protocol

50

Dans (Boshoff et Helberg, 2008), les auteurs tendent le protocole de routage AODV de MANET un protocole de chemin multiple multi-path qui utilise le dlai de bout en bout, la place du compte des sauts, comme une mtrique pour la slection de la route. Les chemins multiples et le dlai de bout en bout fourni par chaque route sont enregistrs dans les tables de routage. En cas de bri de route, la table de la route est recherche pour une route alternative la destination avant que la procdure de dcouverte dune nouvelle route est initie. Ce qui rduit lentte de routage et le dlai de bout en bout. Dans les deux documents (Emin et Roger, 2006) et (Gabrielyan et Hersch, 2006a), les auteurs introduisent un algorithme capillaire de routage offrant un large ventail de topologies de routage par trajets multiples partir d'une solution simple (max-flow multipath) vers des plans plus fiables et plus fixes obtenus en cartant le flot secondaire individuel. 3.3 La qualit de service dans les rseaux Ad Hoc

Dans larticle (Domingo et Remondo, 2004), les auteurs offrent un nouveau protocole, appel DS-SWAN (Differentiated Services-Stateless Wireless Ad hoc Networks), pour supporter la qualit de service QoS de bout en bout dans les rseaux Ad hoc relis aux domaines fixes de DiffServ. DS-SWAN avertit des nuds dans le rseau Ad hoc quand la congestion est excessive pour le bon fonctionnement des applications en temps rel. Ces nuds ragissent en ralentissant le trafic best-effort. Ce protocole propos a donn des bons rsultats au niveau du dlai de bout en bout et de la perte de paquet de trafic VoIP (Voice over IP). Dans (Chen et Ma, 2006), les auteurs prsentent la performance d'un mcanisme d'accs spcifi dans la norme IEEE 802.11e, qui est le EDCA (Enhanced Distributed Coordination Access) quand le trafic multimdia est servi dans le WLANs. Ils valuent la performance en changeant les paramtres du systme. Nous utiliserons ce mme mcanisme dans notre mmoire comme nous verrons dans les chapitres suivants.

51

Dans (Hannan, Kee Chaing et Guan Winston, 2003), les auteurs proposent un modle flexible de QoS qui sappelle FQMM (A Flexible QoS Model for MANET). Nous avons prsent ce modle dans le paragraphe 2.7.3 de ce mmoire. Larticle (Yang et Kim, 2003) traite le problme de la garantie de la QoS en proposant un protocole nomm DCAP (Distributed Channel Assignment Protocol ) qui combine la gestion de ressource distribue et les techniques d'OFDM-CDMA17. Ce nouveau systme rend l'architecture de nud moins complexe que celle du DRNP (Distributed Resource Negotiation Protocol) original et le systme plus robuste pour des multimdia de dbit de donnes levs. Ce protocole DCAP garantit la QoS dans les petits rseaux qui ne sont pas trs chargs. Les auteurs Dekeris, Adomkus et Budnikas (2006) traitent le sujet de lassurance de la vido confrence en utilisant le modle de la qualit de service WFQ (Weighted fair Queuing) combinment avec LLQ (Low Latency Queue). Dans larticle (Lee et al.1999), les auteurs prsentent le conception, limplmentation et lvaluation dINSIGNIA qui est une approche IP pour lintgration de la qualit de service dans les rseaux Ad Hoc mobile. INSIGNIA (In-band Signaling Support for QoS) combine la signalisation dans la bande (In-band), le contrle dadmission et lordonnancement des paquets (Packet Scheduling). Il utilise lapproche de gestion des ressources soft state qui permet une libration rapide des ressources durant la configuration du chemin. Un niveau plus bas de service (Best-effort) peut tre donn lapplication si les ressources ne sont plus disponibles. Comme les informations des flow state doivent tre rserves pour chaque flow dans chaque routeur, INSIGNIA peut avoir le problme de mise lchelle (scalability). Le support dune solution complte de QoS pour les rseaux Ad hoc exige l'interaction et la coopration de plusieurs composants. Ces composants incluent un protocole de cheminement de QoS, un systme de rservation de ressource et un protocole de QoS de la Couche MAC.
17

OFDM-CDMA

Orthogonal Frequency Division Multiplexing - Code Division Multiple Access

52

Dans (Perkins et Hughes, 2002), les auteurs prsentent une tude de la recherche courante qui parle de ces composants pour supporter la QoS dans le contexte des rseaux Ad hoc. Ceci est fait pour fournir une vue large et complte des diffrents composants et protocoles requis pour supporter la QoS dans les rseaux Ad hoc. Larticle (Munaretto et al., 2004) traite le problme de la synchronisation en proposant un nouveau protocole qui limine le besoin dune horloge de synchronisation dure en implmentant un systme virtuel qui se fonde sur la dsynchronisation entre les nuds. Ce protocole propos atteint un niveau lev de synchronisation sous un bas cot de communication. Dans (Bheemarjuna Reddy, John et Murthy, 2007), les auteurs prsentent un systme compos de trois parties : ReAP (ReAllocative Priority), A-TXOP (Adaptive-TXOP), et TXOP sharing (transmission opportunity) afin damliorer la performance du trafic multimdia dans des rseaux Ad Hoc sans fil multi-sauts. Son avantage est qu'il exige des modifications minimales au protocole 802.11e existant. Les amliorations sont bases sur la rduction du dlai de bout en bout, ce qui amliore le taux de transmission du paquet (PDR : Packet Delivery Rate) de trafic multimdia. 3.4 La correction derreurs FEC

La correction derreurs (Forward Error Correction : FEC) a t aborde dans plusieurs articles de la littrature. Dans (Bo et al., 2005), les auteurs prsentent un nouveau systme hybride de contrle derreurs qui introduit lentrelacement entre FEC et ARQ pour diminuer les erreurs et les effets de pertes rencontrs dans MANET. Les rsultats numriques de lanalyse mathmatique montrent que ce nouveau systme hybride de contrle derreurs a le dlai de transmission de donnes le plus court et quil a moins de perte de paquet que lalgorithme multicast de MANET qui utilise seulement lARQ.

53

Dans larticle (Ouyang, Hong et Yi, 2005), les auteurs classifient les protocoles qui transmettre les paquets multicast avec fiabilit en trois catgories selon la mthode de rcupration utilise : le premier est bas sur lARQ, le deuxime est bas sur gossip18 et le troisime est bas sur la correction derreurs FEC et ils comparent ses avantages et ses dsavantages ainsi que ses performances. Les flux temps rel mettent des restrictions dures sur la taille du tampon et donc ne permettent pas au FEC de traiter de longues interruptions de lien sur une seule route. Cependant, le routage par trajets multiples (multi-path) peut rendre FEC efficace pour les flots temps rel. Le document (Rui et Ilow, 2003) propose une nouvelle structure dans les rseaux Ad hoc mobile (MANET) pour le routage par trajets multiples fiable avec les dlais fixes bass sur le contrle derreurs du niveau de paquet (FEC: Forward Error Control). Linnovation de ce travail provient de l'optimisation intgre de la redondance la route et aux niveaux de paquet de FEC pour arriver au concept des nuds rgnrs. Les nuds rgnrs peuvent rduire le taux de perte de paquet (PLR : Packet Loss Rate) entre la source et les nuds intermdiaires, par la suite, le PLR entre la source et la destination sera rduit au minimum. Dans larticle (Schierl et al., 2006), une approche de flot multi source est prsente pour augmenter la robustesse de la transmission vido temps rel dans MANETs. Pour cela, le codage vido aussi bien que les techniques de codage de canal sont prsents sur la couche application, en exploitant la reprsentation multi source des mdias transfrs. Le codage de source est bas sur le SVC (Scalable Video Coding) de H.264/MPEG4-AVC19 avec diffrentes couches pour attribuer l'importance la transmission. Le codage du canal est bas sur les codes de correction d'erreurs (Raptor FEC). Dans (Chen et al., 2004), les auteurs prsentent une nouvelle technique qui sert limiter les effets derreurs et de perte rencontres dans des applications Internet avec et sans fil en
18

Dans gossip les paquets multicast sont transmis dune faon rptitive sur quelques reprises par certains membres multicast dans un mode Peer to Peer. 19 MPEG4-AVC Moving pictures Experts Group 4 - Advanced Video Coding

54

incorporant lentrelacement de mots, la correction derreurs directe (FEC) et la demande automatique de rptition (ARQ) aux sessions de multidiffusion de vido. La performance du concept est analyse et une comparaison entre des rsultats en laboratoire et des rsultats analytiques est faite. Dans le document (Abd El Al, Saadawi et Lee, 2007) , les auteurs proposent un mcanisme qui combine la retransmission base sur le contrle derreurs avec le transport par des chemins multiples (Multi-PaTh) (MPT), pour fournir une protection de diffrents niveaux la vido temps rel dans les rseaux Ad hoc. Le mcanisme factorise dans l'importance des paquets retransmis la qualit de la vido reconstruite aussi bien que les contraintes de la latence de bout en bout pour minimiser les enttes et pour maximiser la qualit de la vido reconstruite au rcepteur. Les rsultats de la simulation prouvent que le mcanisme de la retransmission propos maintient la qualit de la vido sous des taux de perte diffrents et sous des vitesses de mobilit, avec moins denttes en comparaison aux mthodes de contrle d'erreurs qui dpendent du contrle de taux d'intra-update. La synthse Daprs la littrature, nous constatons quil y a plusieurs faons dajouter de la qualit de service au rseau MANET soit travers un protocole daccs au medium, soit partir des mcanismes des files dattente, soit par lintroduction de la correction derreurs. Pour cela, nous avons dcid, dans notre mmoire, de faire une comparaison entre la correction derreurs FEC savoir le Reed Solomon et un outil de QoS en appliquant un protocole daccs au mdium comme le protocole EDCA.

CHAPITRE 4 SIMULATIONS DES DIFFRENTS MODLES 4.1 Problmatique et objectifs de projet

Les applications multimdia vido/voix deviennent rapidement trs populaires. Ladaptation de ces services dans MANET exige un support de la qualit de service. Afin de supporter la QoS dans MANETs, le rseau doit optimiser un ensemble de mtriques mesurables, tels que le dlai, la gigue, la largeur de bande, le taux de livraison de paquet, etc. Cependant, dans MANET, le problme de nud cach, la ncessit de partager les ressources de canal, l'organisation distribue du rseau et la topologie dynamique apportent des dfis importants loffre de la QoS. De plus, les pertes et les erreurs de paquets causes par la mobilit des nuds MANET, ncessitent un mcanisme de rduction derreurs. Notre objectif est damliorer la performance dun rseau mobile Ad Hoc multi-sauts en essayant davoir une meilleure qualit de service en contrlant le dlai de bout en bout, la gigue des services multimdia et de plus rduire les pertes des paquets. En fait, nous ajouterons un correcteur derreurs de type FEC (Forward Error Correction), le Reed Solomon, au flux multimdia afin de minimiser le nombre des erreurs dans le rseau causes par les diffrents problmes tels que les problmes des nuds cachs et exposs. En outre, nous appliquerons lEDCA qui est un protocole d'accs au medium utilis dans la norme IEEE 802.11e qui permet de faire de la qualit de service sur les rseaux sans fils. Vu que les stations sont rduites dans leur capacit de traitement, il est important dutiliser le minimum de mthodes qui apporteront la QoS requise. C'est--dire, de voir sil est toujours ncessaire dutiliser les deux mthodes (FEC et QoS) en mme temps ou lune dentre elles suffira dans certain cas.

56

La simulation a t utilise pour analyser le rseau MANET sous les conditions requrant la QoS et nous avons appliqu les mthodes mentionnes pour mesurer notre approche. 4.2 Modles de tests et configuration de rseaux

Le support des services multimdia Audio/Vido dans un rseau mobile Ad hoc rencontre plusieurs problmes, tels que ceux relis au routage, la congestion, la synchronisation des rseaux multimdia Ad hoc, la difficult de garantir de la QoS dans MANET, la collision et la correction derreurs. Ces problmes peuvent tre causs par la mobilit des rseaux MANETs ou par les besoins des applications multimdia. La littrature a trait ces problmes de plusieurs manires (voir chapitre 3 de ce mmoire pour plus de dtails). De tous ces problmes, cest celui de la qualit de service que nous allons traiter au sein de notre projet. La correction derreurs a t le sujet de plusieurs articles, tel quil a t mentionn dans la revue de littrature. Chaque auteur lavait tudie dune faon diffrente. En ce qui nous concerne, nous modlerons la correction derreurs en utilisant le type de Forward Error Correction FEC, le Reed Solomon. En fait, nous allons ajouter n-k paquets additionnels sur la charge utile k . Ceci va produire n paquets transmettre travers le rseau (n, est le nombre de symboles transmis qui correspond la somme de la charge utile et la correction derreurs). Pour rsoudre notre problmatique et atteindre nos objectifs, il faut tout dabord constituer un rseau MANET, compos de plusieurs stations. Par la suite, essayer de crer des situations derreurs dans ce rseau. Celles-ci seront gnres par des diffrents scnarios et en utilisant plusieurs niveaux de charge dans le rseau. Cette approche va nous permettre de savoir si ce rseau a besoin des deux mthodes, la qualit de service QoS (la diffrentiation des services DiffServ) et la correction derreurs FEC, conjointement, ou bien une seule dentre elles suffira.

57

4.2.1

Les modles de tests

Afin de voir leffet du FEC et de la QoS, maintes situations seront cres dans le rseau MANET. Pour ce faire, plusieurs scnarios peuvent tre excuts: Scnario du problme du terminal cach Ce scnario consiste crer une barrire dans le rseau, entre la source et la destination. Ceci se fait en loignant la destination considrablement de la source. Cette mthode est nomme le problme du terminal cach (paragraphe 1.3.1). Pour mieux comprendre ce phnomne, considrons trois nuds A, B et C dans un rseau MANET, tels que B communique avec les deux autres nuds, alors que A et C sont cachs lun par rapport lautre. Cette situation peut gnrer une collision, dans le cas o A et C veulent transmettre des paquets B en mme temps. Scnario de la rduction de la puissance Ce scnario consiste rduire la puissance de transmission des stations du rseau MANET. La puissance de transmission dtermine la porte dans laquelle le signal peut tre reu. Elle est cruciale en dterminant la performance du rseau en termes de dbit, dlai, et consommation d'nergie. Dautre part, cette puissance dtermine les nuds qui peuvent entendre le signal. En outre, sa rduction peut dfavorablement influencer la connectivit du rseau. Ceci en rduisant le nombre de liens actifs et, potentiellement, en divisant le rseau (Figure 4.1). Par consquent, la diminution de la puissance de transmission cre des erreurs dans le rseau (Krunz, Muquattash et Lee, 2004).

58

Figure 4.1 Leffet du niveau de puissance sur la connectivit du rseau. Tir de Krunz, Muquattash et Lee (2004, p. 3)

Scnario de latence La latence est le temps que prend lapplication, la rception, avant de faire playback (Figure 4.2). Plus la latence est grande, plus nous avons besoin daugmenter la taille du buffer. Ceci peut augmenter les dlais et influencer la qualit de service dsire. Alors, nous pouvons augmenter la latence afin de crer des situations derreurs dans le rseau. Par consquence, nous arriverons voir leffet de la correction derreurs et la QoS DiffServ.

59

Figure 4.2 La latence. Scnario du dbit Ce scnario consiste diminuer le dbit data rate . Ce dernier dsigne le taux auquel l'information est transporte sur le canal de transmission. Le ralentissement du dbit cre des situations dans le rseau MANET qui peuvent dterminer leffet de notre approche. Concernant notre projet, nous implmenterons, dans le logiciel OPNET 14.0, le Reed Solomon qui est un type de correction derreurs FEC. De plus, nous utiliserons le mode EDCA afin de faire de la qualit de service sur le rseau MANET. Ensuite, nous considrerons les deux premiers scnarios du paragraphe prcdent qui sont le problme du terminal cach et la rduction de la puissance, pour crer des situations derreurs dans le rseau. Ces situations permettront de montrer leffet de la correction derreurs FEC combine ou pas avec la qualit de service. Pour ce faire, nous effectuerons des simulations des situations cites ci dessus, sur le logiciel OPNET 14.0. Dans la section 4.3, nous expliquerons notre approche pour implmenter le code ReedSolomon dans notre solution. Quant la section 4.4, elle englobe les simulations.

60

4.3

Implmentation du code Reed-Solomon dans OPNET

Le code Reed Solomon sagit dun code de correction derreurs (FEC) appartenant au groupe des codes de mdia indpendants. Ce dernier utilise des codes de bloques en produisant des paquets additionnels afin dviter la perte des paquets. Il est important de souligner que chaque code prend un nombre de symboles dinformation, appel charge utile k et produit n-k paquets additionnels, qui sont utiliss dans la transmission de n paquets travers le rseau. Notons que n est le nombre de symboles transmis : la charge utile et la correction derreurs. Le rle principal du code ReedSolomon (RS) est la dtection et la correction des erreurs dans des flots de bits. Dans ce projet, il a t adapt pour faire le mme travail pour les flots des paquets. Dans le prsent mmoire, nous avons fait appel au code RS cause de ses avantages par rapport dautres codes, tel que son niveau de fiabilit correspondant la correction derreurs et aussi sa robustesse contre les pertes dans les squences des bits. La procdure du codage est base sur un systme de codage utilisant des polynmes et des algorithmes disponibles facilement, ce qui rduit le cot du calcul. Toutefois, le code RS a des inconvnients ventuels, telles que la possibilit davoir un dlai, une augmentation de la bande passante et une difficult dans limplmentation (Chow, Chan et Khushal, 2002). Afin dtudier lavantage de lutilisation du code RS dans des rseaux Ad hoc mobiles (MANET), nous avons fait la modlisation du comportement de ce type de FEC laide du logiciel. Pour cela, nous avons modifi le modle de WLAN intgr dans OPNET en ajoutant le code Reed Solomon au pipeline dmetteur rcepteur de la liaison hertzienne (Radio Link Transceiver Pipeline) (Chow, Chan et Khushal, 2002).

61

4.3.1

Loutil de simulation OPNET

OPNET Modeler (Optimized Network Engineering Tool) dOPNET Technologies INc. est un outil de dveloppement permettant la conception et ltude des rseaux numriques, et des protocoles de communication avec une grande flexibilit. Son approche est orient objet et il possde une interface graphique simple dans laquelle on place les diffrents composants du rseau tudier. Il comprend plusieurs protocoles, technologies et applications incluant WLAN (IEEE 802.11). Nous avons utilis la version 14.0 dans notre simulation.

4.3.2

Description des tapes des pipelines de transmission dans OPNET

OPNET est un simulateur base de paquet, lmetteur, les rcepteurs et les proprits du canal radio sont models dans 14 tapes des pipelines de transmission (Radio Link Transceiver Pipeline Stage) (documentation dOPNET). Les 14 tapes des pipelines de transmission sont prsentes dans la Figure 4.3:

62

Figure 4.3 Les pipelines de transmission. Tir de Documentation OPNET (chapitre Radio Transceiver Pipeline dans Overview) Ltape 0 : Receiver Group, est appele une fois au dbut de la simulation. Elle fournit une technique d'acclration en optimisant le temps de simulation par llimination des rcepteurs non ligibles. Son but est de crer un premier groupe de rcepteur pour chaque canal d'metteur. Le noyau de simulation vrifie chaque paire possible du canal de l'metteur-rcepteur, et cre un groupe de rcepteur pour chaque canal d'metteur. Ltape 1 : Transmission Delay, excute ds le dbut de la transmission, appele une seule fois pour tous les canaux de destination. Elle value le temps ncessaire pour la transmission dun paquet entier. Cest le rsultat de la diffrence de temps entre le dbut et la fin de la transmission du paquet. Par dfaut, le dlai de transmission =

63

longueur du paquet / taux de donnes. Cette tape rajoute un vnement de fin de transmission et signale le dbut de transmission du paquet suivant. Ltape 2 : Closure, appele pour chaque destination et immdiatement aprs ltape 1. Elle dtermine si le signal physique peut atteindre la destination et permet de grer dynamiquement le voisinage radio. Ses rsultats sont une transmission ou une obstruction. Ltape 3 : Channel Match, son but est de classifier la transmission en basant sur la frquence, bande passante, dbit, codage, etc. Ce qui rsulte caractriser la transmission: valide, bruite ou ignore. Si les paquets ignors, seront dtruits (fin du pipeline). Ltape 4 : Transmitter Antenna Gain, calcul du gain de l'antenne mettrice (dB) en tenant compte de la direction du rcepteur. Ltape 5 : Propagation Delay, calcul du temps de propagation metteur et rcepteur. Ce dlai de propagation dpend de la distance et la vlocit de la propagation (dlai = distance / vlocit). Ltape 6 : Receiver Antenna Gain, pour chaque rcepteur, cest la premire tape aprs le dbut de la rception, calcul du gain de l'antenne rceptrice (dB) en tenant compte de l'orientation de l'antenne mettrice. Ltape 7 : Received Power. Calcul du niveau de la puissance du signal reu, elle est base sur la puissance d'mission, la frquence, la distance, les gains des antennes, et calcule pour tous les paquets valides ou bruits. Ltape 8 : Interference Noise, en cas de transmissions simultanes. Cette tape tient compte des transmissions concurrentes et calcule les effets du bruit sur les paquets valides. Elle est utilise dans ltape 10 pour calculer le taux signal sur bruit (SNR). Les tapes 9 12 du pipeline sont appeles pour valuer la performance dun lien en rponse aux changements de l'tat du signal. Il y a toujours au moins une invocation des tapes 10 12 pour valuer la performance au-dessus de la pleine dure d'un paquet valide. Cependant, une invocation additionnelle se produira pour chacune de ces tapes (9-12) chaque fois qu'un paquet dinterfrence arrive, pour calculer les conditions du nouveau signal.

64

Ltape 9 : Background Noise, intgre les diffrentes sources de bruit (background). Elle prend en compte : Bruit thermique (et bruit galactique); missions lectroniques du voisinage; Possibilit de rajouter autres sources de bruit. Ce bruit est utilis dans ltape 10 pour calculer le taux signal sur bruit (SNR).

Ltape10 : Signal-to-Noise Ratio, uniquement pour les paquets valide. Cette tape calcule le taux signal sur bruit (SNR), elle est base sur la puissance de rception et le bruit.

Ltape 11 : Bit Error Rate, uniquement pour les paquets valides. Cette tape calcule la probabilit des bits errons et est calcule pour chaque segment de paquet ( SNR constant).

Ltape 12 : Error Allocation, cette tape estime les bits errons pour un segment de paquet et est utilise dans ltape13 pour la correction d'erreurs. Ltape 13 : Error Correction, uniquement pour les paquets valides. Cette tape dtermine si un paquet est acceptable ou non.

Puisque les liaisons hertziennes n'existent pas en tant qu'objets physiques, les tapes de pipeline utilises pour soutenir une transmission radio particulire doivent tre associes l'metteur radio et au rcepteur radio qui forment le lien. Les six premires tapes (groupe de rcepteurs, dlai de transmission, tablissement du lien, compatibilit des canaux, gain de lantenne mettrice et les dlais de propagation) sont associes lmetteur. Et les autres huit tapes (gain de lantenne rceptrice, puissance reue, bruit background, bruit d aux interfrences, rapport signal sur bruit, taux derreurs bits, modle derreurs et la correction derreurs) sont associes au rcepteur. 4.3.3 Le code Reed Solomon dans OPNET

Pour implmenter le code Reed Solomon, deux nouveaux attributs sont utiliss : le nombre de symboles transmis (n), et le nombre de symboles dinformation (k). Le nombre derreurs de bits corrigeable (t) qui est calcul partir de n et k, o 2t = n-k. Selon le code RS, afin de

65

corriger les erreurs, lmetteur attachera n-k bits de parit pour chaque k bits de donnes. Ce comportement a t modlis en changeant la premire tape de pipeline responsable de calculer le dlai de transmission. Pour chaque paquet, nous avons calcul les bits de parit supplmentaires exigs de RS. Ensuite, nous avons ajout les bits supplmentaires la longueur du paquet, qui est utilis pour calculer le dlai de transmission. Dans le ct du rcepteur, ltape 12 qui est ltape dattribution des erreurs dtermine le nombre des bits erron dans le paquet basant sur les BER calculs dans ltape 11. Dans ltape 13, qui est pour la correction derreurs, le modle original dcide sil accepte ou rejette le paquet selon lattribut de seuil ecc_thresh. Cette tape a t remplac par notre modle qui rejette tous les paquets avec le nombre de bit erron plus grand que 2t (Chow, Chan et Khushal, 2002). 4.4 Les modles de simulation OPNET

Afin de mieux prsenter leffet de la correction derreurs FEC et de la qualit de service QoS (DiffServ), des simulations dun rseau MANET et avec diffrentes conditions ont t effectues. Nous avons class les simulations dans quatre modles diffrents, le premier est sans problme et les trois autres sont avec des situations derreurs. 4.4.1 MOD 1 : Modle de rfrence

La simulation a t faite laide du logiciel OPNET version 14.0. Tout dabord, nous avons cr un rseau ad hoc mobile multi-sauts. Ce rseau Ad hoc mobile est constitu de 100 stations WLAN (Workstation LAN) qui sont distribues dans une aire de la forme dun carr (grid) de 1000 x 1000 m2 (Figure 4.4). La topologie de carr a t utilise afin daugmenter les chances de trouver des diffrentes routes entre la source et la destination. La porte de transmission de chaque nud est presque 430 m. La source et la destination sont prsentes sur la Figure 4.4, et elles sont t choisies de faon que lune soit lextrieur de la porte de transmission de lautre. Nous avons utilis deux applications : la vido confrence et la voix. Le protocole de routage utilis est lAODV. Le temps de simulation est de 5 minutes. Afin de prendre ce modle comme rfrence, la simulation a t faite pour le rseau sans aucune

66

variation dans les paramtres des stations. En dautres termes, il ny a pas de background traffic, toutes les stations sont fixes et la puissance nest pas rduite. Le Tableau 4.1 et le Tableau 4.2 reprsentent les paramtres de la vido confrence et de la voix respectivement.

Figure 4.4 Le rseau Ad hoc simul dans OPNET.

Nous avons utilis les paramtres par dfaut des profils des applications. Les profils de ces deux applications sont excuts en srie et le temps de dpart de ces profiles est uniforme (100,110) secondes et la dure est jusqu la fin de la simulation et elles se rptent une fois

67

au dbut. Le temps de dpart de chaque application dans son profile est uniforme (5,10) secondes et la dure est jusqu la fin du profile et sa rptition est illimite.

Tableau 4.1 Les paramtres de lapplication vido confrence Information du temps entre arrives de la trame 12.5 trames/sec Taille de la trame entrante Taille de la trame sortante Nom de la destination Type de service 640 octets 640 octets Vido destination Multimdia Interactive (5)

Tableau 4.2 Les paramtres de lapplication voix Nom de la destination Systme dencodage Trames de voix par paquet Type de service Voice destination G.711 20 Interactive voix (6)

4.4.2

MOD 2 : Modle de la mobilit

Dans ce modle, nous avons simul le mme rseau dcrit prcdemment (MOD1) mais, en dplaant la source et la destination avec une vitesse de 10 m/s sans temps de pause afin de crer des situations derreurs dans le rseau (le problme de nud cach dj expliqu) pour voir leffet de la correction derreurs FEC et de la QoS au rseau. Il est important de souligner que nous avons utilis les paramtres par dfaut de lEDCA afin dappliquer la QoS dans notre rseau (Tableau 4.3).

68

Dans tous les scnarios simuls dans ce modle, il y a un background traffic qui nest pas temps rel, le FTP (File Transfer Protocol). Ce background traffic se trouve entre plusieurs stations du rseau et cela pour rendre le rseau plus rel. Ses stations ont t choisies dune faon de bloquer les routes entre la source et la destination et les obliger de passer toujours travers le rseau o il y a un background traffic (Figure 4.5). Nous avons choisi trois niveaux du trafic background: bas, moyen et haut. Ceci est pour voir linfluence du trafic sur les rsultats des deux applications tudies (voix et vido confrence). Pour chaque niveau de trafic background, nous avons vari la taille des paquets. Les valeurs de ces trois niveaux sont prsentes ci-dessous : Le niveau de background traffic faible est : 1000 octets chaque 1 seconde. Le niveau de background traffic moyen est : 22000 octets chaque 1 seconde. Le niveau de background traffic lev est : 50000 octets chaque 1 seconde.

Tableau 4.3 Les paramtres par dfaut dEDCA utiliss dans Opnet Application Voix Vido Best-Effort Background AC AC-VO AC-VI AC-BE AC-BK CWmin (PHY CWmin + 1)/ 4-1 (PHY CWmin +1)/ 2-1 PHY CWmin PHY CWmin CWmax (PHY CWmin +1)/ 2-1 PHY CWmin PHY CWmax PHY CWmax AIFSN 2 2 3 7

69

Figure 4.5 Le background traffic prsent sur le rseau Ad hoc simul.

4.4.3

MOD 3 : Modle de la rduction de la puissance

Dans ce modle, nous avons simul le mme rseau dcrit prcdemment (le paragraphe 4.4.2) mais maintenant la source seule qui se dplace et la puissance des stations a t diminue de sorte que chaque station ne couvre quune seule station (presque 150 m). Nous avons fait cela afin daffaiblir le signal et de crer des situations (des pertes et des

70

erreurs) dans le rseau pour voir linfluence de la qualit de service et la correction derreurs FEC. 4.4.4 MOD 4 : Modle de la mobilit et de rduction de la puissance en mme temps

Dans ce modle, nous avons combin les deux derniers modles exposs ci-dessus. C'est-dire que, la source et la destination se dplacent alatoirement selon le modle Random Waypoint et la puissance est rduite. La simulation a t ralise, pour chacun des modles prcdents, sous forme de quatre scnarios diffrents : avec et sans lintgration de la correction derreurs FEC (le Reed Solomon) et avec et sans lutilisation de la qualit de service. En outre, les simulations des trois modles de cration derreurs (MOD 2, MOD 3 et MOD4) avec les quatre scnarios (avec et sans FEC, avec et sans QoS) ont t rptes, pour les trois niveaux de background traffic. Daprs la simulation, nous esprons savoir ce quajoute la QoS un tel rseau. Si la QoS et la correction derreurs FEC optimisent les ressources du rseau et si elles garantissent de bonnes performances aux applications en minimisant le dlai de bout en bout et la gigue et en diminuant le nombre des pertes. Et nous souhaitons savoir si lapplication de lune de ces deux mthodes seule, suffira dans certain cas.

CHAPITRE 5 RSULTATS ET ANALYSES Dans ce chapitre, nous prsenterons les rsultats et les analyses des simulations relatives notre travail, qui sont effectues avec le logiciel OPNET 14.0. 5.1 Les mtriques de performance

Avant de prsenter les rsultats et les analyses des simulations ralises, nous dfinirons quelques termes qui seront abords dans ce chapitre. Ces dfinitions, tires de la documentation dOPNET, sont: Dlai de bout en bout de la vido confrence ou PEED (Packet End to End Delay) video: le temps que prend un paquet vido partant de la couche application de la source et arrivant la couche application de la destination. Cette statistique enregistre des donnes relatives tous les nuds du rseau. Dlai de bout en bout de la voix ou PEED (Packet End to End Delay) voice: Le dlai total dun paquet de voix, nomm le dlai "mouth-to-ear". Cette valeur est donne par la formule : Dlai "mouth-to-ear" = dlai du rseau + dlai de codage + dlai de dcodage + dlai de compression + dlai de dcompression. Les termes ci-haut mentionns se dfinissent ainsi : Le dlai du rseau est le temps pendant lequel lmetteur cde le paquet au RTP (Real Time Protocol) jusquau temps o le rcepteur le reoit du RTP. Le dlai de codage (sur le nud metteur) est calcul par lencodeur. Notons que le dlai de dcodage (sur le nud de rcepteur) est gal au dlai de codage.

72

Les dlais de compression et de dcompression deviennent des attributs correspondants dans la configuration de lapplication voix. Cette statistique enregistre des donnes de tous les nuds dans le rseau.

La gigue mesure les carts entre les dlais de transmission. Par exemple soit deux paquets conscutifs qui sont mis de la source aux instants t1 et t2 et ils sexcutent la rception aux instants t3 et t4, ce qui donne lquation suivante : La gigue = (t4 - t3) - (t2 - t1). La gigue ngative indique que la diffrence entre les temps de rception des deux paquets ( la destination) est infrieure celle relative aux temps de leurs missions ( la source).

Les paquets perdus correspondent la taille totale des paquets de donnes perdus de la couche suprieure (en bits/seconde) par tous les MAC de WLAN dans le rseau cause des insuccs de retransmissions.

5.2 1.

Les critres de la qualit de service de la voix et de la vido La qualit de service pour un flux voix sur IP ncessite les critres suivants (Moawad, 2004) : Le dlai de bout en bout unidirectionnel est excellent sil est entre 100 et 150 ms et acceptable sil est entre 150 ms et 250 ms. De plus, il peut tre tolrable sil est strictement infrieur 400 msec. La gigue de dlai est excellente si elle est infrieure 40 ms et acceptable si elle est entre 40 ms et 75 ms. Le taux de pertes de paquets est excellent sil est infrieur 5%. Le dlai de bout en bout de 200 msec peut tre tolr. La gigue de la vido de mauvaise qualit est de 5 msec. La tolrance des erreurs et la perte des paquets est peu prs 0.01%.

2.

Les paramtres de la qualit de service requise pour la vido sont daprs (UNM, 1997) :

73

Pour chaque niveau de background trafic (bas, moyen et haut), nous avons simul quatre scnarios diffrents : scnario de base, scnario avec FEC, scnario avec QoS et scnario avec FEC et QoS en mme temps. Les rsultats de ces simulations sont prsents cidessous. 5.3 Les rsultats et les analyses des modles avec background traffic bas

Le background traffic utilis, dans les scnarios suivants, est de niveau bas. En dautres termes, nous envoyons 1000 octets chaque 1 seconde. Les paramtres utiliss dans ce modle sont prsents dans le tableau suivant :

Tableau 5.1 Les paramtres utiliss dans la simulation Nombre des stations Terrain Le dplacement de la source et la destination Applications considres 100 Carr de 1000 m x 1000 m Modle Random waypoint vido confrence de type interactive multimedia voix de type interactive voice Taille des paquets vido Le codeur de la voix Temps de simulation Protocole de routage Les valeurs de Reed Solomon utilises WLAN Data rate 640 octets entrants et 640 octets sortants G.711 5 minutes AODV RS (255,231) 802.11g 11 Mbps

74

5.3.1

Les modles des simulations de niveau de Background traffic bas

Scnario 1.bas Modle de base Cest le modle de base o la qualit de service et la correction derreurs ne sont pas utilises. Scnario 1.1 bas Modle de la mobilit Dans ce modle, la destination et la source sont mise en mouvement afin de crer des situations derreurs dans le rseau. Ce scnario est simul sans lajout de FEC et sans lutilisation de la QoS afin de voir la situation du rseau avant lajout de la qualit de service. Scnario 1.2 bas Modle de la rduction de la puissance Dans ce modle, la source est mobile et la puissance des stations a t diminue pour affaiblir le signal. Et par consquence, gnrer de situations derreurs dans le rseau. Ce scnario sera pris comme un modle de base parce quil est simul sans lutilisation de FEC et de la QoS. Scnario 1.3 bas Modle de la mobilit et de la rduction de la puissance Dans ce modle, nous associons les deux modles dcrivaient prcdemment. C'est--dire que la source et la destination sont en mouvement, de plus la puissance est rduite.

Scnario 2. bas Modle avec FEC seulement Dans ce scnario, nous appliquons seulement le Reed Solomon qui est un type de FEC. Scnario 2.1 bas Modle de mobilit avec FEC seulement Dans ce scnario, la correction derreurs FEC a t ajoute pour corriger les erreurs cres par le dplacement de la source et la destination.

75

Scnario 2.2 bas Modle de rduction de la puissance avec FEC seulement La rduction de la puissance des stations sans fil gnre des situations derreurs qui peuvent tre corriges par lajout de la correction derreurs FEC. Scnario 2.3 bas Modle de la mobilit et de la rduction de la puissance avec FEC seulement La correction derreurs FEC seule est utilise dans ce modle afin de corriger les erreurs prouves par la mobilit de la source et de la destination et par la rduction de la puissance.

Scnario 3. bas Modle avec QoS Dans ce scnario, nous avons introduit la QoS. Pour ce faire, le protocole EDCA a t appliqu. Lobjectif est de voir si la QoS est apte amliorer la situation du rseau ou non. Scnario 3.1 bas Modle de la mobilit avec QoS seulement En dplaant la destination et la source, des situations derreurs seront cres. Alors, la QoS est utilise pour obtenir des rsultats optimaux dans ce modle. Scnario 3.2 bas Modle de rduction de la puissance avec QoS seulement Tout comme la mobilit, la rduction de la puissance cre elle aussi des situations derreurs dans le rseau. En consquence, la QoS est utilise, dans ce scnario, afin de minimiser les erreurs dans le rseau. Scnario 3.3 bas Modle de la mobilit et de la rduction de la puissance avec la QoS seulement La qualit de service seule est utilise, dans ce modle, afin de corriger les erreurs prouves par la mobilit de la source et de la destination et par la rduction de la puissance.

76

Scnario 4. bas Modle avec FEC et QoS Telle que son nom lindique, la correction derreurs FEC corrige les erreurs dans un rseau. La qualit de service, quant elle, amliore la situation du rseau. Ainsi, ces deux mthodes permettent doptimiser ltat du rseau. Cela entrane faire des simulations, laide des deux mthodes, ce qui nous permet de confirmer sil est toujours intressant dutiliser les deux mthodes combines ou si lune dentre elles suffira, dans tous ou certains cas. Scnario 4.1 bas Modle de la mobilit avec FEC et QoS Les deux mthodes : FEC et QoS doivent, en principe, amliorer la situation dun rseau. Afin de savoir jusqu quel point cette affirmation est juste et si ce principe est applicable dans tous les cas ou dans des cas spciaux seulement, nous gnrerons des situations derreurs dans un rseau MANET en dplaant la destination et la source, tout en appliquant les deux mthodes prsentes ci dessus. Scnario 4.2 bas Modle de rduction de la puissance avec FEC et QoS Dans ce scnario, les deux mthodes FEC et QoS seront appliques de faon combine pour voir si elles corrigent la situation dun rseau MANET ayant des problmes, en diminuant les puissances des stations sans fil. Scnario 4.3 bas Modle de la mobilit et de la rduction de la puissance avec FEC et QoS Dans ce modle, la correction derreurs FEC est utilise dune faon combine avec la QoS afin damliorer la situation du rseau.

77

5.3.2

Le modle de rfrence

Ce scnario prsente le modle que nous utiliserons comme rfrence dans nos simulations. Dans ce scnario, nous simulons le mme rseau sans background traffic ni mobilit, ni rduction de la puissance c'est--dire que toutes les stations du rseau sont fixes et la puissance utilise est la mme que celle utilise dans le modle de la mobilit. De plus, ni la correction derreurs FEC ni la QoS ne sont utilises dans ce scnario. Il est important de noter que les rsultats de ce modle apparaissent dans tous les graphes prsents ci-dessous.

Dans ce qui suit, nous prsenterons les rsultats des simulations faites pour tous les scnarios prsents prcdemment.

5.3.3

Notation des graphes simuls

Afin de simplifier la comprhension des rsultats et des graphes obtenus dans les prochains paragraphes, nous prsenterons quelques notes : FQM est le nom de notre approche qui dsigne FEC QoS pour Multimdia. Nous avons nomm les scnarios simuls de la manire suivante : niveau de background traffic, modle de cration derreurs utilis, la mthode utilise (FEC, QoS ou les deux ensembles). Par exemple : Low Mobility Power QoS FEC pour dsigner que le background traffic utilis est de niveau faible, le modle de cration derreurs utilis est la mobilit avec la rduction de la puissance, la QoS et le FEC sont utiliss. Tous les scnarios qui nutilisent pas la correction derreurs FEC ni la QoS sont prsents en bleu clair. Tous les scnarios qui utilisent la correction derreurs FEC seule sont prsents en bleu fonc. Tous les scnarios qui utilisent la qualit de service seule sont prsents en vert.

78

Tous les scnarios qui utilisent la correction derreurs FEC de faon combine avec la QoS sont prsents en rouge. Le modle de rfrence est le mme qui existe dans toutes les figures et il est prsent en jaune.

5.3.4

Les rsultats du dlai de bout en bout de la vido confrence en secondes

Figure 5.1 PEED video 20 du modle de la mobilit avec background traffic bas.

Figure 5.2 PEED video du modle de diminution de la puissance avec background traffic bas.

La Figure 5.1 et la Figure 5.2 montrent que le dlai de bout en bout de la vido confrence, en utilisant de faon combine la correction derreurs FEC et la qualit de service (en rouge) et celui qui intgre le FEC seul (en bleu fonc) sont proches, dans un contexte de problmes dans le rseau. Bien que, dans les deux cas, la qualit de service seule donne de bons rsultats c'est--dire moins de 150 msec (en vert), mais lutilisation de FEC et de QoS combine reste la meilleure solution.
20

PEED Video pour dsigner le dlai de bout en bout de la vido confrence.

79

Nous remarquons aussi que le PEED video du modle de rfrence (en jaune) est un peu plus grand que celui qui utilise le FEC et la QoS chacun seul ou dune faon combine dans le modle de mobilit tandis que ces derniers sont un peu plus levs que le modle de rfrence dans le modle de la rduction de la puissance.

5.3.5

Les rsultats du dlai de bout en bout de la voix en secondes

Figure 5.3 PEED voice du modle de la mobilit avec background traffic bas.

Figure 5.4 PEED voice du modle de diminution de la puissance avec background traffic bas.

Dans le cas dun rseau MANET avec un background traffic de niveau faible, nous remarquons que les dlais de bout en bout de la voix en utilisant FEC seul ou avec la QoS sont proches surtout dans le cas de la mobilit (les graphes en bleu fonc et en rouge dans la Figure 5.3 et la Figure 5.4). Dans la Figure 5.4, nous remarquons que le dlai de bout en bout en intgrant la correction FEC et la QoS dune faon combine (en rouge) est meilleur que celui qui utilise le FEC seul (en bleu fonc).

80

En outre, dans les deux cas de cration derreurs, le dlai de bout en bout utilisant la QoS seule a des valeurs acceptables c'est--dire plus petites que 250 msec. Ce qui nous permet de conclure que lutilisation de la correction derreurs FEC et de la QoS chacune seule ou dune manire combine se montre trs acceptable. Or, afin dobtenir de meilleurs rsultats, il serait prfrable dutiliser le FEC et la QoS en mme temps. Il est bon de souligner que les graphes en bleu clair reprsentent le rseau sans lutilisation de la QoS ni de la correction derreurs FEC, afin de voir sa situation avant lajout de la qualit de service. Dailleurs, nous remarquons que les valeurs obtenues de nos solutions proposes (les graphes en verts, rouge et bleu fonc dans la Figure 5.3 et la Figure 5.4) ne sont pas loin de celles du modle de rfrence (en jaune).

81

5.3.6

Les rsultats de la gigue de la voix en secondes

Figure 5.5 Gigue de la voix du modle de la mobilit avec background traffic bas.

Figure 5.6 Gigue de la voix du modle de diminution de la puissance avec background traffic bas.

La Figure 5.5 et la Figure 5.6 montrent que dans un contexte de cration derreurs, il ny a pas une grande diffrence entre la gigue de la voix en utilisant le FEC et la qualit de service ensemble et celle en introduisant chacune dentre elles la fois. Ce qui permet de conclure que les trois solutions donnent des valeurs acceptables (proches de zro) et stables en ce qui concerne la gigue.

82

5.3.7

La perte des paquets des stations locales sans fil en bits/secondes

Figure 5.7 La perte des paquets du modle de la mobilit et background traffic bas.

Figure 5.8 La perte des paquets du modle de diminution de la puissance avec background traffic bas.

Dans le cas de dplacement de la destination et avec lutilisation de FEC et de la QoS chacune seule ou combine, nous remarquons, daprs la Figure 5.7 que les pertes des paquets dans les stations du rseau relatives au Retry Theshold Exceeded en utilisant le FEC seul sont les plus faibles tandis que celles en intgrant le FEC et la QoS dune faon combine sont les plus petites dans la Figure 5.8. Cependant, dans le cas de la QoS seule, nous remarquons une quantit considrable de pertes de donnes dues aux retransmissions excessives indiquant des tats durs de contention et probablement une trop-petite fentre de contention utilise en contestant des stations. Dailleurs, la Figure 5.7 illustre que la quantit des pertes obtenue en intgrant le FEC seul ou en mme temps avec la QoS est plus petite que celle obtenue avec le modle de rfrence.

83

Pourtant, dans le cas de la rduction de la puissance (Figure 5.8), nous remarquons que les pertes dans le modle de rfrence sont proches de celles obtenus en utilisant le FEC et la QoS en mme temps. Finalement, malgr que les rsultats obtenus avec lintgration de la correction derreurs FEC et la QoS chacune seule sont appropris et proches de ceux obtenus en utilisant le FEC et la QoS ensemble. Nous pouvons conclure que, dans le cas dun rseau MANET prsentant des problmes et en utilisant un background traffic de niveau bas, lutilisation de la correction derreurs FEC conjointement avec la QoS donne de meilleurs rsultats en ce qui concerne les dlais de bout en bout de la vido confrence et de la voix, ainsi que pour la gigue de la voix et la perte des paquets. 5.4 Les rsultats et les analyses des modles avec background trafic moyen

Pour ce niveau de background trafic, nous rpterons les mmes scnarios que nous avons dcrits prcdemment pour le background traffic bas, mais en fixant, cette fois ci, la taille des paquets 22000 octets chaque 1 seconde. Pour chacun des scnarios suivants, les deux modles de cration des situations derreurs seront utiliss qui sont le modle de dplacement de la destination et le modle de la rduction de la puissance. 5.4.1 Les modles des simulations de niveau de Background traffic moyen

Scnario 1. moyen Modle de base Ce scnario reprsente le modle de base o la qualit de service et la correction derreurs ne sont pas utilises. Scnario 2. moyen Modle avec FEC seulement Dans ce scnario, nous nappliquons que le Reed Solomon, qui est un type de FEC.

84

Scnario 3. moyen Modle avec QoS Dans ce scnario, le modle de QoS choisi, savoir lEDCA a t ajout afin de voir sil est apte amliorer la situation du rseau ou non. Scnario 4. moyen Modle avec FEC et QoS Comme nous lavons dj mentionn, la correction derreurs FEC corrige les erreurs dans un rseau et la qualit de service amliore la situation du rseau. Ce qui permet doptimiser ltat du rseau. Or, est-il toujours primordial et indispensable dutiliser les deux mthodes cites ci-dessus? Pour rpondre cette question nous raliserons des simulations, dans lesquelles la mthode de correction derreurs et celle dutilisation de la QoS seront ajoutes et examines afin de dcouvrir dans quels cas nous devons avoir recours aux deux mthodes conjointement, et dans quels autres cas lutilisation dune seule dentre elles suffira. Dans ce dernier cas, nous aimerions connatre laquelle des deux solutions est meilleure.

85

5.4.2

Les rsultats du dlai de bout en bout de la vido confrence en secondes

Figure 5.9 PEED video du modle de la mobilit avec background traffic moyen.

Figure 5.10 PEED video du modle de diminution de la puissance avec background traffic moyen.

La Figure 5.9 montre que le dlai de bout en bout pour la vido, en utilisant la mthode de correction derreurs FEC seule (en bleu fonc), est proche de celui utilisant le FEC et la QoS ensemble (en rouge) dans le modle de la mobilit tandis que dans le modle de la rduction de la puissance le FEC montre une petite amlioration que dans le cas de FEC et QoS conjointement (en bleu fonc dans la Figure 5.10). Lincorporation de la qualit de service seule donne des valeurs acceptables qui sont infrieures 120 msec mais elles sont plus leves par rapport celles obtenues en incorporant la correction derreurs FEC seul ou avec la QoS dans les deux modles de crations derreurs (en vert). Nous pouvons, donc, conclure que lorsque la charge du rseau est moyenne et quil existe des problmes dans le rseau, la correction derreurs FEC seule suffira pour obtenir un meilleur dlai de bout en bout pour la vido confrence. Notons aussi que les valeurs

86

obtenues en intgrant le FEC seul et dune faon combine avec QoS sont proche de celles du modle de rfrence.

5.4.3

Les rsultats du dlai de bout en bout de la voix en secondes

Figure 5.11 PEED voice du modle de la mobilit avec background traffic moyen.

Figure 5.12 PEED voice du modle de diminution de la puissance avec background traffic moyen.

De mme que pour la vido confrence, la Figure 5.11 et la Figure 5.12 montrent que, malgr que la QoS donne des rsultats appropris, lutilisation de la mthode FEC seule suffira pour obtenir un meilleur dlai de bout en bout de la voix dans le cas dun rseau avec problmes et avec une charge de rseau moyenne.

87

5.4.4

Les rsultats de la gigue de la voix en secondes

Figure 5.13 Gigue de la voix du modle de la mobilit avec background traffic moyen.

Figure 5.14 Gigue de la voix du modle de diminution de la puissance avec background traffic moyen.

La correction derreurs FEC seule ou combine avec la qualit de service donne de bonnes valeurs qui sont proches du zro et stables pour la gigue de la voix dans les deux mthodes de cration des situations derreurs (en bleu fonc et en rouge dans les figures 5.13 et 5.14). La qualit de service seule (en vert) donne aussi des valeurs trs acceptables en ce qui concerne la gigue de la voix mais les deux autres solutions (FEC seul ou avec QoS) restent meilleures surtout quand on rduit la puissance (Figure 5.14).

88

5.4.5

La perte des paquets des stations locales sans fil en bits/secondes

Figure 5.15 La perte des paquets du modle de la mobilit avec background traffic moyen

Figure 5.16 La perte des paquets du modle de diminution de la puissance avec background traffic moyen.

La Figure 5.15 et la Figure 5.16 montrent que les pertes des paquets dues au Retry Threshold Exceeded en utilisant le FEC seul ou dune manire combine avec la QoS sont faibles ce qui montre la fiabilit de la correction derreurs au lieu de retransmettre les paquets errons. Cependant nous remarquons, que le rseau subit des pertes considrables en intgrant la QoS seule ceci est cause de lutilisation dune petite fentre de contention. Pour conclure, les graphes prcdents (de 5.9 5.16) montrent lefficacit de la correction derreurs FEC. Il est clair que lutilisation de FEC seul est prfrable dans le cas dun rseau avec problmes, ayant un background traffic moyen qui serait gnr entre les stations, car les rsultats obtenus pour les dlais de bout en bout relatifs la vido confrence et la voix ainsi que pour les rsultats correspondants la gigue de la voix et la perte des paquets sont meilleurs.

89

5.5

Les rsultats et les analyses des modles avec background trafic haut

De mme que pour les deux niveaux de background traffic bas et moyen. Dans ce cas, nous utiliserons le background traffic de niveau haut, en fixant la taille des paquets 50000 octets chaque 1 seconde.

5.5.1

Les modles des simulations de niveau de Background traffic haut

Nous allons simuler les scnarios suivants. Chacun de ces scnarios sera simul dans les deux cas de cration derreurs savoir la mobilit et la rduction de la puissance. Scnario 1. haut Modle de base Scnario 2. haut Modle avec FEC seule Scnario 3. haut Modle avec QoS seule Scnario 4. haut Modle avec FEC et QoS de faon combine.

90

Un rappel des paramtres utiliss dans la simulation est prsent dans le Tableau 5.2:

Tableau 5.2 Les paramtres utiliss dans la simulation Nombre des stations Terrain Le dplacement de la source et de la destination Applications considres 100 Carr de 1000 m x 1000 m Modle Random waypoint vido confrence de type interactive multimedia voix de type interactive voice Taille des paquets vido Le codeur de la voix Temps de simulation Protocole de routage Les valeurs de Reed Solomon utilises WLAN Data rate 640 octets entrants et 640 octets sortants G.711 5 minutes AODV RS (255,231) 802.11g 11 Mbps

91

5.5.2

Les rsultats du dlai de bout en bout de la vido confrence en secondes

Figure 5.17 PEED video du modle de la mobilit avec background traffic haut.

Figure 5.18 PEED video du modle de diminution de la puissance avec background traffic haut.

Dans le but de crer des situations derreurs dans le rseau, nous avons mis en mouvement la source et la destination. En effet, la Figure 5.17 montre que lutilisation de la correction derreurs FEC de faon combine avec la QoS (en rouge) donne un meilleur dlai de bout en bout pour la vido confrence quand le background traffic utilis est lev. Mais, ce nest pas le cas dans la Figure 5.18, lorsquon diminue la puissance, o on remarque que lutilisation de la QoS seule (en vert) donne un meilleur dlai de bout en bout pour la vido confrence. Pourtant la correction derreurs FEC seule montre des rsultats convenables c'est--dire moins de 200 msec (en bleu fonc) dans le contexte de cration derreurs. Notons que le PEED du modle de rfrence est infrieure (en jaune) celui obtenu en utilisant la QoS et la FEC chacune seule ou dune faon combine.

92

5.5.3

Les rsultats du dlai de bout en bout de la voix en secondes

Figure 5.19 PEED voice du modle de la mobilit avec background traffic haut.

Figure 5.20 PEED voice du modle de diminution de la puissance avec background traffic haut.

Les rsultats du dlai de bout en bout de la voix sont proches de ceux obtenus pour la vido confrence, o nous remarquons que la correction derreurs FEC utilise de faon combine avec la QoS donne le meilleur PEED dans le cas de la mobilit (en rouge dans la Figure 5.19) tandis que dans le cas de la diminution de la puissance cest la QoS seule qui offre le meilleur PEED (en vert dans la Figure 5.20). Nous remarquons aussi que la correction derreurs FEC utilise seule donne un dlai de bout en bout un peu plus lev que celui dans les autres cas savoir la QoS seule ou combine avec FEC mais il reste acceptable parce quil est infrieur 400 msec qui est la valeur limite qui peut tre tolrer pour un trafic de la voix.

93

5.5.4

Les rsultats de la gigue de la voix en secondes

Figure 5.21 Gigue de la voix du modle de la mobilit avec background traffic haut.

Figure 5.22 Gigue de la voix du modle de diminution de la puissance avec background traffic haut.

Lorsque la source et la destination se dplacent, lutilisation de la correction derreurs FEC ou la QoS chacune seule donne des excellents rsultats pour la gigue de la voix (les graphes en bleu fonc et en vert dans la Figure 5.21 et la Figure 5.22). En revanche, la qualit de service utilise dune manire combine avec la FEC donne des valeurs qui ne sont pas trs appropries de la gigue lorsque nous diminuons la puissance (en rouge dans la Figure 5.22).

94

5.5.5

La perte des paquets des stations locales sans fil en bits/secondes

Figure 5.23 La perte des paquets du modle de la mobilit avec background traffic haut.

Figure 5.24 La perte des paquets du modle de diminution de la puissance avec background traffic haut.

Selon la Figure 5.23, lutilisation de FEC de faon combine avec la QoS subit des pertes dues au dpassement du seuil de tentative de la retransmission (Retry Threshold Exceeded) qui sont infrieures celles que connat le rseau dans les deux autres cas, savoir lutilisation de la QoS et la FEC chacune seule (en vert et en bleu fonc respectivement). Pourtant, nous voyons bien, dans la Figure 5.23 et la Figure 5.24, que la quantit des paquets perdus prouve dans le rseau, dans le cas de FEC seul (en bleu fonc), nest pas trs grande et ceci grce la correction derreurs qui diminue le nombre de retransmission dans le rseau. Cependant, lapplication de la QoS seule subit dune grande quantit de perte parce quelle essaye toujours damliorer la situation du rseau en retransmettant les paquets lorsquil est congestionn.

95

En conclusion, dans le cas de background traffic lev, les rsultats obtenus en utilisant les trois mthodes (la correction derreurs FEC et la QoS chacune seule ou dune faon combine) semblent acceptables. 5.6 Les rsultats de la simulation de la mobilit et la rduction de la puissance en mme temps

Dans ce paragraphe, nous allons prsenter les rsultats des simulations des scnarios en intgrant la mobilit et la diminution de la puissance ensemble pour les trois niveaux de background traffic (Bas, moyen et haut). En dautres termes, la source et la destination se dplacent une vitesse de 10 m/sec sans temps de pause et la puissance est rduite de sorte que la porte de transmission de la station ne couvre quune seule station. Les paramtres utiliss dans ses simulations sont le mmes que ceux prsents dans le Tableau 5.2.

96

5.6.1

Les rsultats des simulations pour le background traffic de niveau faible

a. PEED video.

b. PEED voice.

c. La gigue de la voix.

d. La perte des paquets.

Figure 5.25 Les rsultats des simulations pour le background traffic de niveau faible.

97

La Figure 5.25 montre que les rsultats des simulations du rseau qui intgre la mobilit et la rduction de la puissance en mme temps et le background traffic est de niveau faible, en utilisant la correction derreurs FEC seule ou combine avec la QoS sont proches et ils semblent trs acceptables (en bleu fonc et en rouge). Bien que les valeurs obtenues en incorporant la QoS soient appropries (en vert), nous prfrons celles obtenues quand le FEC seul, qui se montrent meilleures. Ceci dit, nous constatons que lutilisation de FEC seul suffira pour lobtention de rsultats performants (en bleu fonc). Ce qui vite de surcharger inutilement le rseau en utilisant les deux mthodes combines. Dailleurs, les rsultats du modle de rfrence (en jaune) sont trs proches de ceux obtenus par nos solutions savoir le FEC seul ou combin avec la QoS.

98

5.6.2

Les rsultats des simulations pour le background traffic de niveau moyen

a. PEED video.

b. PEED voice.

c. La gigue de la voix.

d. La perte des paquets.

Figure 5.26 Les rsultats des simulations pour le background traffic de niveau moyen.

99

La Figure 5.26 montre que les rsultats des simulations du rseau, qui intgre la mobilit et la rduction de la puissance en mme temps quand le background traffic est de niveau moyen, en utilisant la correction derreurs FEC combine avec la QoS sont les plus petits. Malgr que les rsultats obtenus par lincorporation de la correction derreurs FEC et la qualit de service chacune seule paraissent satisfaisants, la mthode de les utiliser dune faon combine reste la meilleure solution. Dailleurs, les rsultats du modle de rfrence (en jaune) sont plus petits que ceux obtenus par lintgration de FEC ou de QoS chacune seule ou combines.

100

5.6.3

Les rsultats des simulations pour le background traffic de niveau haut

a. PEED video.

b. PEED voice.

c. La gigue de la voix.

d. La perte des paquets.

Figure 5.27 Les rsultats des simulations pour le background traffic de niveau haut.

101

Dans ce scnario, le background trafffic utilis est de niveau lev, la puissance est rduite et la source et la destination sont mobiles ce qui mne des collisions et des congestions dans le rseau. Malgr cela, la correction derreurs et la qualit de service chacune seule ou combine amliorent la situation du rseau en rduisant les dlais et les pertes des paquets (Figure 5.27) Toutefois, le FEC ajoute des informations supplmentaires ce qui permet de saturer la bande passante alors il est prfrable dutiliser la QoS seule. 5.7 Conclusion

Les rsultats des simulations montrent une amlioration dans le rseau, en incorporant nimporte quelle mthode des trois savoir la correction derreurs FEC et la QoS chacune seule ou de faon combine, par rapport sa situation lorsquil nadopte aucune mthode (tous les graphes des simulations en bleu clair). Toutefois, dans tous les scnarios simuls, nous remarquons que la diffrence entre les rsultats obtenus en intgrant la correction derreurs FEC ou la QoS chacune seule et ceux obtenus en utilisant le FEC en mme temps que la QoS nest pas trs significative. De plus, tous les trois sont acceptables. Cependant, nous remarquons toujours la performance de certains rsultats par rapport aux autres. Par exemple, lorsque le background traffic utilis est de niveau faible, lintgration de la QoS de faon combine avec le FEC donne des rsultats optimaux, alors nous prfrons lutilisation de cette mthode afin davoir des rsultats idaux, dans ce cas, car le rseau nest pas trs congestionn et il y a assez de bande passante. Pourtant que dans le cas de background traffic de niveau moyen, malgr que la QoS et la FEC combines donne des meilleurs rsultats lorsque la mobilit et la diminution de la puissance sont appliques, il est prfrable dintgrer la correction derreurs FEC seule parce

102

que les rsultats obtenus par cette mthode sont trs acceptables et nous vitons de surcharger inutilement le rseau en utilisant les deux mthodes combines. Lorsque le background traffic est de niveau lev, nous remarquons quil ny a pas une seule mthode parfaite qui peut tre utilise dans tous les cas. En dautres termes, la QoS combine avec la FEC donne des meilleurs rsultats dans le cas de la mobilit tandis quelle donne seule des bons rsultats dans le cas de la diminution de la puissance. Il faut souligner aussi que lutilisation de la correction FEC seule donne des dlais de bout en bout pour la voix et la vido un peu plus leves (mais moins de 400 msec) que ceux obtenus par les deux autres mthodes savoir la QoS seule ou combine avec le FEC, tandis que la perte des paquets est rduite. Mais, afin dviter de saturer la bande passante en utilisant la correction derreurs FEC qui ajoute des bits supplmentaires, la QoS seule semble la meilleure solution dans ce cas. En conclusion, nous notons que lorsque le background traffic utilis est bas, la correction derreurs FEC et la QoS chacune seule donne des rsultats appropris, seulement, dans le but davoir des rsultats optimaux, il faut utiliser la correction derreurs et la qualit de service en mme temps. Dautre part, il devient indispensable dappliquer la correction derreurs FEC seule, quand le background traffic augmente au niveau moyen et la QoS seule au niveau lev, ce qui permet dobtenir des rsultats performants.

CONCLUSION Les services multimdia deviennent trs importants et trs populaires dans la vie quotidienne. Cependant, ces applications sont sensibles au dlai et la perte des informations. Par ailleurs, les rseaux Ad hoc mobiles MANET ont une bande passante limite et susceptible davoir des erreurs. Alors, lutilisation des services multimdia sur MANET exige un support de qualit de service. Dans le prsent mmoire, nous avons tudi le support de la QoS dans un rseau MANET qui utilise des services multimdia (voix et vido confrence). En fait, nous avons essay dobtenir une meilleure qualit de service en contrlant le dlai de bout en bout et la gigue des applications multimdia ainsi quen diminuant les pertes des paquets. Afin datteindre notre objectif, nous avons ajout au rseau simul sous OPNET, le Reed Solomon, qui est un correcteur derreurs de type FEC, et avons appliqu lEDCA qui est un protocole d'accs au medium utilis dans la norme IEEE 802.11e qui permet dappliquer une diffrenciation de services sur les rseaux sans fils afin davoir une certaine QoS dans le rseau. Daprs les simulations que nous avons faites, nous concluons que lorsque le background traffic est faible et moyen le FEC seul donne des valeurs trs acceptables mais si on veut amliorer la qualit de la voix nous pouvons introduire la QoS qui donne la priorit la voix. Toutefois, quand le background traffic est moyen, le FEC donne un semblant de QoS, ce qui est trs appropri pour le trafic best effort. En fait, les dlais de bout en bout relatifs la voix et la vido confrence en incorporant la correction derreurs FEC et le background traffic moyen, sont trs convenables, ainsi que la quantit des paquets perdus due la faible retransmission, ce qui montre une trs grande fiabilit de la correction derreurs non pas pour le trafic temps rel seulement mais pour tous les trafics qui existent dans le rseau. En dautres termes, les utilisateurs de la voix et de la vido confrence en plus de ceux de background traffic, savoir le FTP, sont satisfaits parce que les dlais obtenus de ces travaux sont appropris avec le moins de pertes possibles.

104

Lorsque le background traffic est lev, nous remarquons que les dlais de bout en bout obtenus par la QoS seule sont meilleurs en les comparant ceux obtenus par le FEC car la qualit de service reprsente par EDCA dans le prsent travail, donne la priorit la voix puis la vido ensuite aux trafics best effort et background traffic respectivement, ce qui cause des consquences ngatives sur les utilisateurs de background traffic cause du faible trafic quils vont recevoir. Tandis que le FEC corrige les erreurs de tous les trafics, incluant le background trafic, ce qui permet dobtenir un dbit important pour ce dernier en plus de celui de la voix et de la vido. Aussi, il est important de noter que le FEC est meilleur que lARQ parce quil corrige les erreurs au lieu de faire simplement des retransmissions des paquets perdus. Nous pouvons remarquer clairement cette conclusion dans tous nos graphes de pertes de paquets o le FEC donne toujours une quantit de pertes assez faible devant celle obtenue en intgrant la QoS. Il est important de souligner que dans tous nos scnarios, nous avons procd la comparaison de nos rsultats avec ceux du modle de rfrence qui a t simul sans aucune modification dans le rseau, autrement dit, on na introduit ni la QoS ni le FEC dans ce modle. Alors, les rsultats des simulations montrent une grande amlioration dans le rseau au niveau des dlais de bout en bout des services vido confrence et voix, de la gigue de la voix et de la perte relatifs aux stations sans fil lorsquon introduit la correction derreurs FEC et la QoS chacune seule et lorsquon les utilise de faon combine, dans les cas o le rseau est congestionn ou non. Enfin, nous concluons que nos rsultats des simulations rpondent aux objectifs que nous avons fixs au dbut. Parce que grce notre approche, la qualit de service dans un rseau qui prouve des situations critiques est amliore en rduisant les dlais, la gigue de la voix et les pertes des paquets. Ce qui donne une certaine satisfaction aux utilisateurs des services

105

multimdia dans un tel rseau en comparaison avec le service quils pouvaient avoir sans lincorporation de cette qualit de service.

RECOMMANDATIONS Nous recommandons de concevoir un mcanisme dynamique qui peut diffrencier les mthodes (FEC seul et QoS seule, et FEC avec QoS ensemble) pour activer seulement lune ou lautre des deux mthodes selon la situation dans laquelle se trouve le rseau. Par exemple, si le trafic utilis dans le rseau est critique, alors nous choisirons dutiliser le FEC et la QoS simultanment. Autrement, nous utiliserons le FEC seul ou la QoS seule. Lutilisation de Reed Solomon comme correcteur derreurs de type FEC a donn de bons rsultats. Nous suggrons dessayer, pour un futur travail, un autre type de la correction FEC tel que le code turbo et de voir sil donnera de meilleurs rsultats que ceux obtenus avec Reed Solomon. Comme le Reed Solomon cause un trafic supplmentaire au rseau en ajoutant les donnes redondantes, il serait intressant de concevoir un algorithme de compression dentte. Dans notre mmoire, nous avons utilis les communications unicast. Comme nous utilisons les applications vido et voix, il serait important dessayer les communications multicast. La simulation est une premire tape de vrification et de validation et elle est proche du modle naturel. Comme les rsultats de simulation sont jugs satisfaisants, alors ils peuvent tre vrifis par une implmentation pratique de la correction derreurs et la QoS sur des ordinateurs portables et des assistants personnels PDA qui utilisent un trafic temps rel bas sur la voix et la vido et en faisant un rseau congestionn ou non, selon le nombre des utilisateurs qui participent au rseau. Ce qui assure une valuation de notre approche dans un systme rel.

BIBLIOGRAPHIE Abd El Al, Ahmed, Tarek Saadawi et Myung Lee. 2007. Unequal error protection for realtime video in mobile ad hoc networks via multi-path transport . Computer Communications, vol. 30, no 17, p. 3293-3306. Basalamah, A, et T Sato. 2007. A Comparison of Packet-Level and Byte-Level Reliable FEC Multicast Protocols for WLANs . In Global Telecommunications Conference, 2007. GLOBECOM '07. IEEE, sous la dir. de Sato, T. p. 4702-4707. Bernsen, James, et D. Manivannan. 2009. Unicast routing protocols for vehicular ad hoc networks: A critical comparison and classification . Pervasive and Mobile Computing, vol. 5, no 1, p. 1-18. Bheemarjuna Reddy, T., John P. John et C. Siva Ram Murthy. 2007. Providing MAC QoS for multimedia traffic in 802.11e based multi-hop ad hoc wireless networks . Computer Networks, vol. 51, no 1, p. 153-176. Bo, Rong, Kais Mnif, Michel Kadoch et Ahmed K. Elhakeem. 2005. A hybrid error control scheme for MANET reliable multicast . In. Vol. 2005, p. 1086-1089. Coll. Canadian Conference on Electrical and Computer Engineering . Saskatoon, SK, Canada: Institute of Electrical and Electronics Engineers Inc. <http://dx.doi.org/10.1109/CCECE.2005.1557165>. Boshoff, J. N., et A. S. J. Helberg. 2008. Improving QoS for real-time multimedia traffic in Ad-hoc networks with delay aware multi-path routing . In., p. 1-8. Coll. 7th Annual Wireless Telecommunications Symposium, WTS 2008 . Ponoma, CA, United states: Inst. of Elec. and Elec. Eng. Computer Society. <http://dx.doi.org/10.1109/WTS.2008.4547536>. Bur, Kaan, et Cem Ersoy. 2004. Multicast routing for ad hoc networks with a quality of service scheme for session efficiency . In. Vol. 2, p. 1000-1004. Coll. IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC . Barcelona, Spain: Institute of Electrical and Electronics Engineers Inc. Carsenat, David 2003. Contribution l'tude de rseaux de communication sans fil: application au LMDS . Thse de doctorat en ligne Limoges, Universit de Limoges, 230 p. <www.unilim.fr/theses/2003/sciences/2003limo0039/carsenat.pdf >. Cetinkaya, Coskun. 2009. Service differentiation mechanisms for WLANs . Ad Hoc Networks, vol. In Press, Corrected Proof.

108

Chakrabarti, Satyabrata, et Amitabh Mishra. 2004. Quality of service challenges for wireless mobile ad hoc networks . Wireless Communications and Mobile Computing, vol. 4, no 2, p. 129-153. Chen, Donghui, Bo Rong, N. Shayan, M. Bennani, J. Cabral, M. Kadoch et A. K. Elhakeem. 2004. Interleaved FEC/ARQ coding for QoS multicast over the internet . Canadian Journal of Electrical and Computer Engineering, vol. 29, no 3, p. 159-166. Chen, F. K. L., et M. D. Ma. 2006. Supporting Quality of Services in Wireless LANs by EDCA Access Scheme . In www.opnet.com. <https://enterprise1.opnet.com/tsts/4dcgi/Biblio_FullAbstract?BiblioID=1159>. Chen, L. 2006. Protocols for Supporting Quality of Service in Mobile Ad Hoc Networks . University of Rochester. Chow, Ivy, Horace Yat-Hong Chan et Sameer Khushal. 2002. Forward Error Control in Wireless Local Area Networks . Corson, S., et J. Macker. 1999. RFC 2501 . Mobile Ad hoc networking (MANET): routing protocol performance issues and evaluation considerations. Dekeris, B., T. Adomkus et A. Budnikas. 2006. Analysis of QoS assurance using weighted fair queueing (WFQ) scheduling discipline with low latency queue (LLQ) . In., p. 507-12. Coll. ITI 2006 Proceedings of the 28th International Conference on Information Technology Interfaces . Zagreb, Croatia: University of Zagreb. Domingo, M. C., et D. Remondo. 2004. An interaction model between ad-hoc networks and fixed IP networks for QoS support . In., p. 188-194. Coll. ACM MSWiM 2004 - Proceedings of the Seventh ACM Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems . Venezia, Italy: Association for Computing Machinery. Emin, Gabrielyan, et D. Hersch Roger. 2006. Rating of Routing by Redundancy Overall Need . In ITS Telecommunications Proceedings, 2006 6th International Conference on, sous la dir. de Roger, D. Hersch. p. 786-789. Gabrielyan, E., et R. D. Hersch. 2006a. Fault-Tolerance of Capillary Multi-Path Routing for Real-Time Multimedia Streaming with Forward Error Correction . In Information and Communication Technologies, 2006. ICTTA '06. 2nd, sous la dir. de Hersch, R. D. Vol. 2, p. 3198-3203.

109

Gabrielyan, E., et R. D. Hersch. 2006b. Reducing the Requirement in FEC Codes via Capillary Routing . In Computer and Information Science, 2006 and 2006 1st IEEE/ACIS International Workshop on Component-Based Software Engineering, Software Architecture and Reuse. ICIS-COMSAR 2006. 5th IEEE/ACIS International Conference on, sous la dir. de Hersch, R. D. p. 75-82. Gong, Michelle X., Scott F. Midkiff et Shiwen Mao. 2009. On-demand routing and channel assignment in multi-channel mobile ad hoc networks . Ad Hoc Networks, vol. 7, no 1, p. 63-78. Hannan, Xiao , Chua Kee Chaing et Seah Khoon Guan Winston. 2003. Quality of Service Models for Ad Hoc Wireless Networks . In The handbook of ad hoc wireless networks Ilyas, M. CRC press. Hsu, Chia-Hao, Yu-Liang Kuo, Eric Hsiao-Kuang Wu et Gen-Huey Chen. 2004. QoS routing in mobile ad hoc networks based on the enhanced distributed coordination function . In, 4. Vol. 60, p. 2663-2667. Coll. IEEE Vehicular Technology Conference . Los Angeles, CA, United states: Institute of Electrical and Electronics Engineers Inc. Hsu, Chih-Shun, Jang-Ping Sheu et Shen-Chien Tung. 2006. An on-demand bandwidth reservation QoS routing protocol for mobile ad hoc networks . In. Vol. 2006 I, p. 198-207. Coll. Proceedings - IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing . Taichung, Taiwan: Institute of Electrical and Electronics Engineers Computer Society. <http://dx.doi.org/10.1109/SUTC.2006.39>. IEEE Standard for Information technology, Telecommunications and information exchange between systemsLocal and metropolitan area networksSpecific requirements. 2007. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Std 802.11-2007. IEEE, 3 Park Avenue, New York, NY 10016-5997, USA: IEEE. Consult le 25 juin 2009. ITU, ITU-T Telecommunication Standardization Sector Of. 2001. Series G: Transmission Systems and Media Digital Systems and Networks, Quality of service and performance; End-user multimedia QoS categories. ITU-T Rec. G.1010 (11/2001). G.1010. Ivascu, Gabriel Ioan, Samuel Pierre et Alejandro Quintero. 2009. QoS routing with traffic distribution in mobile ad hoc networks . Computer Communications, vol. 32, no 2, p. 305-316. Jabri, Issam, Nicolas Krommenacker, Thierry Divoux et Adel Soudani. 2008. IEEE 802.11 load balancing: An approach for QoS enhancement . International Journal of Wireless Information Networks, vol. 15, no 1, p. 16-30.

110

Kantorovitch, Julia, Zach Shelby et Tommi Saarinen. 2003. Wireless Adaptation Techniques for Heterogeneous Multihop Networking Coll. Wireless Adaptation Techniques for Heterogeneous Multihop Networking . 24 p. Krunz, M, A Muquattash et SJ Lee. 2004. Transmission power control in wireless ad hoc networks: challenges, solutions and open issues . Network, IEEE, vol. 18, no 5, p. 814. Lahlou, Omar. 2005. Routage multi-chemin bas sur la fiabilit des routes dans les rseaux mobiles Ad Hoc . Maitrise en sciences appliques, Sherbroooke, Universit de sherbrooke, 101 p. Mahbubur Rahman, Syed 2002. "Chapter 19 - Mobile Multimedia over Wireless Network". Multimedia Networking: Technology, Management and Applications. . Idea Group Publishing In www.books24x7.com. <http://common.books24x7.com/book/id_4070/book.asp>. Majkowski, J., et F. Casadevall. 2005. Admission control in IEEE 802.11 e EDCA . International Wireless Summit. Mangold, S., S. Choi, G. R. Hiertz, O. Klein, B. Walke, P. Res et G. Aachen. 2003. Analysis of IEEE 802.11 e for QoS support in wireless LANs . IEEE Wireless Communications, vol. 10, no 6, p. 40-50. Moawad, Rabih. 2004. QoS dans les WPAN, WLAN et WMAN . Mmoire en ligne de DEA Rseaux et tlcommunications, Liban, Universit Libanaise, EAF et Universit St Joseph, 64 p. <www.lb.refer.org/memoires/560895RabihMOAWAD.pdf >. Mohammad Ilyas, Boca Raton. 2003. The handbook of ad hoc wireless networks Boca Raton London New York Washington, D.C. Munaretto, Anelise, Mauro Fonseca, Khaldoun Al Agha et Guy Pujolle. 2004. Virtual time synchronization for multimedia ad hoc networks . In, 4. Vol. 60, p. 2587-2590. Coll. IEEE Vehicular Technology Conference . Los Angeles, CA, United states: Institute of Electrical and Electronics Engineers Inc. Muqattash, Alaa, et Marwan M. Krunz. 2004. A distributed transmission power control protocol for mobile ad hoc networks . IEEE Transactions on Mobile Computing, vol. 3, no 2, p. 113-128. Odom, Wendell, et Michael J. Cavanaugh. 2004. IP Telephony Self-Study Cisco DQOS Exam Certification Guide. USA: Cisco Press.

111

Ogawa, Masakatsu, Ikumi Shimojima et Takeshi Hattori. 2002. CoS guarantee control for wireless LAN . In. Vol. 1, p. 50-54. Coll. IEEE Vehicular Technology Conference . Birmingham, AL, United states: Institute of Electrical and Electronics Engineers Inc. <http://dx.doi.org/10.1109/VTC.2002.1002662>. Ouyang, Beini, Xiaoyan Hong et Yunjung Yi. 2005. A comparison of reliable multicast protocols for mobile ad hoc networks . In., p. 339-344. Coll. Conference Proceedings - IEEE SOUTHEASTCON . Piscataway, NJ 08855-1331, United States: Institute of Electrical and Electronics Engineers Inc. Perkins, C. E., et P. Bhagwat. 1994. Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers . Computer Communications Review, vol. 24, no 4, p. 234-234. Perkins, Dmitri D., et Herman D. Hughes. 2002. A survey on quality-of-service support for mobile ad hoc networks . Wireless Communications and Mobile Computing, vol. 2, no 5, p. 503-513. Riley, Martyn, et Iain Richardson. 1998. Reed Solomon codes, an introduction to ReedSolomon codes: principles, architecture and implementation . <http://www.cs.cmu.edu/afs/cs.cmu.edu/project/pscicoguyb/realworld/www/reedsolomon/reed_solomon_codes.html>. Consult le 7 mai 2009. Rui, Ma, et J. Ilow. 2003. Reliable multipath routing with fixed delays in MANET using regenerating nodes . In., p. 719-25. Coll. Proceedings 28th Annual IEEE International Conference on Local Computer Networks - LCN 2003. Held in conjunction with the Workshop on High-Speed Local Networks (HSLN) and Workshop on Wireless Local Networks (WLN 2003) . Los Alamitos, CA, USA: IEEE Comput. Soc. <http://dx.doi.org/10.1109/LCN.2003.1243205>. Sarma, Nityananda, et Sukumar Nandi. 2006. QoS support in mobile ad hoc networks . In. Coll. 2006 IFIP International Conference on Wireless and Optical Communications Networks . Bangalore, India: Inst. of Elec. and Elec. Eng. Computer Society. Schierl, Thomas, Karsten Ganger, Cornelius Hellge, Thomas Wiegand et Thomas Stockhammer. 2006. SVC-based multisource streaming for robust video transmission in mobile Ad Hoc Networks . IEEE Wireless Communications, vol. 13, no 5, p. 96-103. Sheikh, W., B. Shafiq, R. A. Paul et A. Ghafoor. 2003. Provision of multimedia services in a mobile ad hoc network . In., p. 87-93. Coll. Proceedings. Ninth IEEE International Workshop on Object-Oriented Real-Time Dependable Systems . Los Alamitos, CA, USA: IEEE Comput. Soc. <http://dx.doi.org/10.1109/WORDS.2003.1267494>.

112

Shklyaeva, A., D. Kubanek et V. Novotny. 2007. Analysis of IEEE 802.11e for Delay Sensitive Traffic in Wireless LANs . In Networking, 2007. ICN '07. Sixth International Conference on, sous la dir. de Kubanek, D. p. 38-38. Taing, Nguon, Sakchai Thipchaksurat, Ruttikorn Varakulsiripunth et Hiroshi Ishii. 2005. Routing scheme for multimedia services in mobile Ad hoc network . In. Vol. 2005, p. 11-15. Coll. 2005 Fifth International Conference on Information, Communications and Signal Processing . Bangkok, Thailand: Inst. of Elec. and Elec. Eng. Computer Society. Toh, C K. 2002. Ad Hoc Mobile Wireless Networks Protocols and systems : Age of Pervasive Mobile Networks and Computing Upper Sadde River: Prentice Hall UNM. 1997. Networking Futures: QoS Parameters . In <http://www.unm.edu/~network/presentations/course/chapters.html> <http://www.unm.edu/~network/presentations/course/appendix/appendix_b/tsld033.h tm>. Consult le 25 juin 2009. Valois, Fabrice. 2005. Simulation de rseaux radio sous OPNET Modeler. INSA , Lyon. <fvalois.insa-lyon.fr/hdr/HDR_CV_F_Valois_112007.pdf >. Varposhti, Marzieh, et Naser Movahhedinia. 2009. Supporting QoS in IEEE 802.11e wireless LANs over fading channel . Computer Communications, vol. 32, no 5, p. 985-991. Wang, H. 2005. Algorithms and QoS of video streaming over wireless networks . The University Of Texas At Dallas, 133 p. Wang, J., Y. Tang, S. G. Deng et J. Chen. 2001. QoS routing with mobility prediction in MANET . In. Vol. II, p. 357-360. Coll. IEEE Pacific RIM Conference on Communications, Computers, and Signal Processing - Proceedings . Victoria, BC, Canada: Institute of Electrical and Electronics Engineers Inc. Wu, Hsiao-Kuang, et Pei-Hung Chuang. 2001. Dynamic QoS allocation for multimedia ad hoc wireless networks . Mobile Networks and Applications, vol. 6, no 4, p. 377-384. Wu, K., et J. Harms. 2001. QoS support in mobile ad hoc networks . Crossing Boundaries-the GSA Journal of University of Alberta, vol. 1, no 1, p. 92-106. Xiao, Hannan, Chaing Chua Kee et Winston Seah Khoon Guan. 2003. Quality of service models for ad hoc wireless networks . In The handbook of ad hoc wireless networks, sous la dir. de Ilyas, Mohammad. p. 467-482. Boca Raton, Fla.: CRC Press, Inc.

113

Yang, Hyunho, et Kiseon Kim. 2003. Multimedia Ad Hoc Wireless LANs with Distributed Channel Allocation Based on OFDM-CDMA . IEICE Transactions on Communications, vol. E86-B, no 7, p. 2112-2118. Zhu, Hua, et Imrich Chlamtac. 2006. Admission control and bandwidth reservation in multi-hop ad hoc networks . Computer Networks, vol. 50, no 11, p. 1653-1674.

(ITU, 2001)