QoS dans les WPAN, WLAN et WMAN

UNIVERSITE AUF UNIVERSITE LIBANAISE SAINT JOSEPH MEMOIRE DE DEA RESEAUX ET TELECOMMUNICATIONS QoS dans les WPAN, WLAN et WMAN Réalisé par : Rabih MOAWAD Responsable : Rima ABI FADEL Decembre 2004 1

TABLE DES MATIERES REMERCIEMENTS...5 SOMMAIRE...5 1-IEEE 802.15...7 1.1 -IEEE 802.15.1: BLUETOOTH... 7 1.1.1- La vue d'ensemble de Bluetooth... 7 1.1.2- Couche PHY... 7 1.1.3- Couche MAC... 8 1.1.4 - QoS dans Bluetooth... 9 1.2 -IEEE 802.15.3: WIMEDIA... 10 1.2.1 Applications... 10 1.2.2 Couche MAC... 10 1.2.3 Couche PHY... 12 1.2.4-802.15.3a : UWB (Ultra Wide Band)... 13 1.3- IEEE 802.15.4 : ZIGBEE... 14 1.3.1-Caractéristiques générales [5]... 14 2-IEEE 802.11...15 2.1- INTRODUCTION... 15 2.2- ARCHITECTURE WLAN... 16 2.2.1 - Réseaux WLAN à Infrastructure... 16 2.2.2 Réseau WLAN Ad Hoc... 16 2.3- LA COUCHE MAC... 17 2.3.1-802.11... 17 2.4 - COUCHE PHY... 22 2.4.1 - IEEE 802.11.b: WiFi...22 2.4.2 - IEEE 802.11.a/h... 22 2.4.3 - IEEE 802.11.g... 22 2.5 - IEEE 802.11E... 23 2.5.1- Limitations de la QoS dans 802.11... 23 2.5.2- QoS dans 802.11e... 23 2.5.3- EDCF : Enhanced DCF... 23 2.5.4 - HCF : Hybrid Coordination Function... 26 2.6 PACKET FRAME GROUPING (PFG)... 28 3 - IEEE 802.16...30 3.1 - INTRODUCTION... 30 3.2 GROUPES DE TRAVAUX DU IEEE 802.16 :... 31 3.3 - COUCHE MAC... 31 3.3.1- Service-Specific Convergence Sublayer... 32 3.3.2- Common Part Sublayer... 33 3.3.3- Privacy sublayer... 39 3.4 - QOS DANS IEEE 802.16... 40 2

3.4.1- Demande et attribution de bande passante... 40 3.4.2- Services dans 802.16 [11]... 40 3.4.3- Mécanismes de QoS... 42 3.5- COUCHE PHY 802.16.1... 43 3.6 - IEEE 802.16A... 45 3.6.1 - Couche PHY 802.16a...45 3.6.2- Couche MAC dans 802.16a... 45 II- SIMULATION...46 1- CONTEXTE ET PARAMETRES...46 1.1 INTRODUCTION... 46 1.2 VOIX SUR IP... 46 1.3 ENVIRONNEMENT ET CONTEXTE DE LA SIMULATION... 47 1.3.1 Modèle de simulation... 47 1.3.2 Topologie du réseau et routage... 49 1.3.3 Scenarii et paramètres de simulation... 50 2 - RESULTATS DES SIMULATIONS ET COMMENTAIRES..51 2.1 - DEBITS MAXIMAUX... 51 2.2 MODELE DE FLUX VOIP... 52 2.3 - SCENARII A DEUX STATIONS EMETTRICES... 53 2.3.1 Délai... 53 2.3.2 Gigue... 54 2.3.3 Perte de paquets... 54 2.4 - SCENARII A PLUSIEURS STATIONS EMETTRICES... 55 2.4.1 Délai... 55 2.4.2 Gigue... 56 2.4.3 Perte de paquets... 57 3 CONCLUSION...58 ANNEXE...60 1- INTEROPERABILITE AVEC UMTS...60 1.1- CONNEXION AU SGSN :... 60 1.2- CONNEXION AU GGSN :... 61 1.3- APPROCHE MOBILE IP :... 61 BIBLIOGRAPHIES...63 3

TABLE DES FIGURES ET TABLEAUX FIGURE 1- PICONETS ET SCATERNETS DANS BLUETOOTH... 8 FIGURE 2 - MÉCANISME POLLING DE LA COUCHE MAC... 9 FIGURE 3 - TOPOLOGIE DU WIMEDIA 802.15.3... 11 FIGURE 4 - STRUCURE DE LA SUPERTRAME 802.15.3... 11 FIGURE 6- RESEAU INFRASTRUCTURE 802.11B... 16 FIGURE 7- RESEAU AD HOC 802.11B... 17 FIGURE 9- ALTERNANCE DE CFP ET CP... 19 FIGURE 10 PRINCIPE DE FONCTIONNEMENT DE PCF... 20 FIGURE 11- PROBLEME DE LA STATION CACHEE... 21 FIGURE 12 - TRANSMISSION DES FRAGMENTS D'UN MSDU SÉPARÉS PAR SIFS... 21 FIGURE 13 - STATION 802.11 ET STATION 802.11E AVEC QUATRE AC PAR STATION... 25 FIGURE 14 - PARAMÈTRES POUR DIFFÉRENTES PRIORITÉS DANS EDCA... 26 FIGURE 15 -SUPERTRAME 802.11E. UTILISATION DES TXOP. LES POLLED-TXOP EXISTENT DANS CP ET CFP... 27 FIGURE 16 - LA STRUCTURE DE LA SUPERTRAME UTILISEE DANS L'ALGORITHME D'ORDONNANCEMENT DU... 28 FIGURE 17 - PRINCIPE DE PFG (SOURCE: [ 8 ])... 29 FIGURE 18 - LE STANDARD IEEE 802.16 PERMET DES SOLUTIONS QUI RÉPONDENT AUX BESOINS D'UNE... 30 FIGURE 19 - DIFFÉRENTES SOUS-COUCHES MAC ET COUCHE PHY DANS 802.16... 32 FIGURE 20 - FORMAT D'UN ENTÊTE GÉNÉRIQUE D'UN PDU MAC... 34 FIGURE 21- FRAGMENTATION ET AGREGATION DANS LA COUCHE MAC... 35 FIGURE 22- STRUCTURE DE LA SOUS-TRAME DU LIEN DESCENDANT... 37 FIGURE 23 - CORRESPONDANCE MINIMALE DU UL-MAP AVEC LA TRAME MONTANTE DANS FDD... 37 FIGURE 24- STRUCTURE DE LA SOUS-TRAME DU LIEN MONTANT... 38 FIGURE 25- TRAME TDD (10-66GHZ)... 43 FIGURE 26- BURSTS DANS FDD... 44 FIGURE 30 - STRUCTURE DU PAQUET DE LA COUCHE PHYSIQUE DU 802.11G... 48 FIGURE 31 - TOPOLOGIE DU RÉSEAU AD HOC 802.11G... 49 FIGURE 32 - DEBITS MAXIMAUX EN MBPS, DU 802.11G, EN FONCTION DU NOMBRE DE BONDS... 52 FIGURE 27 - APPROCHE DE LA CONNEXION AU SGSN... 60 FIGURE 28 - APPROCHE DE LA CONNEXIONAU GGSN... 61 FIGURE 29 - APPROCHE MOBILE IP... 62 TABLE 1 - PARAMÈTRES DE EDCA SELON [6]... 25 TABLE 2 - CODECS VOIP... 47 TABLE 3 PARAMÈTRES DE LA SIMULATION... 48 TABLE 4 - PARAMÈTRES DES DIFFÉRENTES PRIORITÉS... 48 TABLE 5 - DEBITS MAXIMAUX EN MBPS, DU 802.11G, EN FONCTION DU NOMBRE DE BONDS... 51 TABLE 6 - VALEURS DES DÉLAIS (EN MS) ENTRE 1 ET 4 POUR UN FLUX VOIP BIDIRECTIONNEL... 53 TABLE 7 - VALEURS DE LA GIGUE (EN MS) AUX NOEUDS 1 ET 4, POUR UN FLUX VOIP BIDIRECTIONNEL... 54 TABLE 8 - VALEURS DES DÉLAIS (EN MS) ENTRE 1 ET 4 POUR DES FLUX VOIP BIDIRECTIONNELS MULTIPLES... 56 TABLE 9- DÉLAI GLOBAL (EN MS) POUR DES FLUX VOIP BIDIRECTIONNELS MULTIPLES... 56 TABLE 10 -VALEURS DE LA GIGUE (EN MS) AUX NOEUDS 1 ET 4, POUR DES FLUX VOIP BIDIRECTIONNELS MULTIPLES...57 TABLE 11 - TAUX DE PERTES DE PAQUETS, EDCF, FLUX MULTIPLES... 57 TABLE 12 - TAUX DE PERTES DE PAQUETS, EDCF+ CFB, FLUX MULTIPLES.... 58 4

Remerciements Je désire avant tout remercier la responsable du mémoire Dr. Rima Abi Fadel, ainsi que Dr. Samir Tohmé responsable du DEA et président du jury pour l'aide et l'assistance qu'ils m'ont fourni, durant tout ce mémoire, ainsi que toute personne m'ayant soutenu dans mon travail. Sommaire Les télécommunications jouent un rôle très important dans la vie des hommes. Ils ont de plus en plus besoin de communiquer, d'échanger des informations, de n'importe quel lieu, à n'importe quel moment, avec des exigences accrues sur la rapidité et la qualité des transmissions. Avec le boom des multimédias et l'événement de l'internet le besoin de transmettre des flux de voix, de vidéo, d'images fixes ou autres types d'informations, en plus des données, monte en flèche. De plus pour pouvoir communiquer librement sans le besoin d'infrastructures coûteuses, ou l'encombrement du câblage, ou dans des zones d'accès difficile, la solution est le sans-fils. En outre pour transmettre des flux temps-réel, voix ou vidéo, ou pour des services à contraintes temporelles, avec la qualité requise pour chaque flux, la solution était l'introduction de la QoS dans les WPAN, WLAN, WMAN. En effet ce mémoire est divisé en deux grandes parties: la première comprend l'étude bibliographique de la QoS dans les réseaux sans-fils personnels WPAN, locaux WLAN et métropolitains WMAN; et la deuxième comprend une simulation pour étudier la QoS dans un réseau Ad Hoc 802.11, supportant des flux voix sur IP (VoIP). L'étude a débutée avec les WPAN qui sont divisés en trois types de réseaux ayant chacun un standard IEEE. Bluetooth, qui a été standardisé sous IEEE 802.15.1, s'applique à des réseaux personnels et était utilisé à ses débuts comme moyen de connexion sans câble de matériel informatique (ordinateurs, imprimante, ) donc pour transmettre des données. Par la suite il s'est répandu à d'autres applications plus contraignantes en QoS, mais le support de cette QoS dans Bluetooth reste relativement limité. Le WiMedia standardisé sous IEEE 802.15.3 et par la suite avec son amélioration le "Très large bande" UWB ou IEEE 802.15.3a, vont permettre à des flux nécessitant des débits importants de transiter à travers ce réseau, mais pour de courtes distances, comme par exemple un signal vidéo émis d'une caméra vers un écran plasma. La QoS est assurée dans ce cas par l'allocation d'intervalles temporels garantis les GTS pour fournir à chaque flux les ressources nécessaires. Le troisième des standards est le IEEE 802.15.4 ou ZigBee, qui a pour domaine d'application les réseaux de senseurs de différents types qui la plupart de temps ne nécessitent pas de QoS, et si le besoin se présente, une certaine QoS est fournie en utilisant une méthode presque identique à celle du WiMedia. La deuxième grande famille de réseaux sans-fils est WLAN avec le fameux standard IEEE 802.11 qui s'applique aux réseaux locaux sans-fils. Au début avec 802.11b l'objectif était de couvrir une certaine cellule d'un rayon maximal de 250m, pour la transmission de données informatiques. Par la suite à cause du succès de cette expérience surtout avec la prolifération des ordinateurs portables le besoin de transmission de flux à contraintes temporelles s'est fait sentir, et un nouveau standard qui permettait d'ajouter la QoS au niveau de la couche MAC du 802.11, a vu le jour : le IEEE 802.11e. Deux nouvelles méthodes d'accès au réseau ont été ajoutées dans 802.11e, EDCF et HCF. Avec EDCF qui est une amélioration de DCF (utilisée avec 802.11), 5

quatre classes de priorité ont été définies pour différencier les flux avec l'utilisation de la contention pour accéder au canal. Avec HCF qui est une amélioration de PCF (utilisée avec 802.11), c'est la méthode de vote "polling" qui est utilisée, et qui permet de faire voter les stations pour connaître leurs besoins, et selon les ressources disponibles essayer de répartir ces ressources sur les stations. HCF pouvant fonctionner pendant les durées de contention et celles de non contention est prioritaire sur EDCF et est utilisé pour les flux à contraintes temporelles importantes. On arrive enfin aux réseaux métropolitains sans-fil, les WMAN. Le WiMAX qui est conforme au standard 802.16, permet la couverture de larges zones pouvant atteindre 50 Km de rayon. Il est utilisé pour desservir des zones urbaines ou rurales, connecter des Hotspots 802.11, et fournir des hauts débits avec une QoS importante qui a été implémentée dans 802.16 dés sa conception. Le Wimax qui utilise la TDD et FDD pour la transmission, va établir pour chaque flux unidirectionnel une connexion même pour les flux qui ne sont pas en mode connecté, et va utiliser les bursts à profils adaptatifs, ç.à.d. des bursts dont la modulation et le FEC sont adaptés au conditions de transmission. Ainsi dans 802.16 quatre services de QoS sont définis: UGS où les allocations de bande sont faites périodiquement par la station de base sans être sollicitée, utile avec ATM par exemple; ensuite on passe à rtps qui permet aux stations de demander périodiquement des allocations de bande, il est utile pour les flux temps-réel; le troisième service, le nrtps ne diffère pas beaucoup du précédent mais il est utilisé avec les flux non temps-réel. le dernier service est le Best Effort. Ainsi toute la panoplie de services avec QoS est présente dans 802.16. Après la partie bibliographique, on passe à la simulation d'un réseau Ad hoc comprenant un routeur et quatre stations connectées par du 802.11. Le but de la simulation est d'étudier les performances en QoS de ce réseau. Au début j'ai commencé par étudier le débit maximal que peut écouler ce réseau, pour différents scenarii et priorités, en fonctions du nombre de bonds traversés, pour connaître les capacités du réseau. Ensuite une transmission bidirectionnelle de flux de voix sur IP est établie entre les stations d'extrémité. Ces flux vont traverser quatre bonds en passant par le routeur, avant d'atteindre leurs destinations respectives. Un flux FTP en background existe aussi dans le réseau. Avec cette topologie on a réalisé plusieurs scénarii, avec DCF (802.11), EDCF (802.11e), et EDCF+CFB, où CFB est une amélioration ajoutée au 802.11. Les résultats obtenus nous ont permis de connaître les performances de chacune des méthodes d'accès, et de savoir si les contraintes de QoS, à savoir le délai de bout en bout, la gigue, et le taux de pertes de paquets, sur les flux temps-réel VoIP sont vérifiés. Enfin dans la dernière partie de la simulation le but était de connaître le nombre maximal de stations émettrices/réceptrices aux deux extrémités du réseau qui permettait de respecter les contraintes de QoS. On a ainsi atteint six stations à chaque extrémité avec EDCF et EDCF+CFB, alors que avec DCF on n'a pas pu dépasser le seuil d'une seule station. De même on a pu tirer certaines conclusions intéressantes sur les performances de CFB surtout concernant le nombre de paquets rejetés, ainsi que sur le délai. Enfin je vous invite cher lecteur à commencer la lecture de ce rapport de mémoire en espérant que vous serez intéressé par le contenu. N.B: - Un annexe sur l'interopérabilité de 802.16 avec UMTS est fourni à la fin de ce document. -Un fichier "Read me" contenant quelques détails techniques sur le programme de simulation est présent sur le CD avec évidement la version électronique du rapport ainsi que le programme de simulation. 6

1-IEEE 802.15 Le 802.15 comprend effectivement trois standards pour les réseaux personnels sans-fil WPAN (Wireless Personal Area Network). Les propriétés générales sont : -Réseaux optimaux pour les faibles zones de couverture (10m) -Faible puissance d émission (1 à 10mW) -Faible consommation de puissance. -Réseaux dynamiques sans infrastructures (Ad Hoc) 1.1 -IEEE 802.15.1: BLUETOOTH 1.1.1- La vue d'ensemble de Bluetooth Formé en février 1998 par les géants de la téléphonie mobile et l'informatique Ericsson, IBM, Intel, Nokia, et Toshiba, le groupe d'intérêt spécial de Bluetooth (SIG) conçoit des spécifications de technologie à redevances libres, dans le but de permettre la communication sans couture de voix et de données par l'intermédiaire des liens à courte portée et de permettre à des utilisateurs de relier une gamme étendue des dispositifs, facilement et rapidement, sans besoin de câbles. Ainsi, Bluetooth qui a été standardisé par la suite avec IEEE 802.15.1 est une norme qui s'applique bien aux réseaux d'accès sans-fil avec une connectivité personnelle, les WPAN (Wireless Personnal Area Network). Il est effectivement utilisé avec les réseaux Ad-Hoc. 1.1.2- Couche PHY La couche physique du Bluetooth a les caractéristiques suivantes : -Elle fonctionne dans la bande 2,4GHz (ISM : Industrielle, Scientifique et Médicale) avec un débit de 720Kb/s -Utilise le FHSS Frequency Hopping spread spectrum (saut de fréquences suivant une séquence pseudo aléatoire déterminée par le maître), qui divise la bande de fréquence (2,402-2,408 GHz) en 79 canaux. - Supporte jusqu'à 8 terminaux par piconet (1maitre et 7 esclaves) dans un rayon De 10 à 50m. - Les piconets (picocellules) peuvent être combinées pour former des scaternets 7

Figure 1- Piconets et Scaternets dans Bluetooth 1.1.3- Couche MAC Au début d'une connexion, l'unité d'initialisation se proclame comme maître. Une picocellule est le réseau constitué par un maître et un ou plusieurs esclaves, mais seulement jusqu'à 7 esclaves actifs (participant à l'échange de données). Les transmissions peuvent avoir lieu du maître à l'esclave ou inversement. La première méthode utilisée pour la transmission de paquets est la méthode par vote (polling) qui utilise TDD (Time Division Duplex), pour fonctionner en full duplex. On a un maximum de 1600 slots/s (1 slot: 0.625msec), où les slots maître/esclave sont numérotés en pair/impair. La transmission d'un paquet MAC couvre habituellement un slot unique mais elle peut occuper jusqu'à cinq slots de temps consécutifs. Par conséquent, le maître commande entièrement le trafic dans la picocellule; en effet, on permet à un esclave de transmettre un paquet MAC seulement si dans le slot précédent le maître lui a déjà envoyé un paquet. Par conséquent, quand le maître envoie des données à un esclave, il donne à l'esclave l'occasion de transmettre des données en retour. Quand le maître n'a aucune donnée à envoyer, il peut voter l'esclave avec un paquet sans charge utile (appelée un paquet de vote, POLLING). Puis, l'esclave doit répondre en renvoyant des données, si disponibles, ou en envoyant un paquet sans charge utile (appelée un paquet NUL). Ce mécanisme est illustré dans la figure 2. L'allocation de la bande passante limitée dans Bluetooth constitue un point critique pour l'algorithme d'ordonnancement, en l'occurrence le mécanisme de polling, qui doit gérer la répartition de bande sur les différentes stations dans la picocellule. Pour de meilleures performances deux autres mécanismes seront utilisés SCO et ACL (voir QoS) 8

Figure 2 - Mécanisme Polling de la couche MAC 1.1.4 - QoS dans Bluetooth Deux types de services sont supportés par Bluetooth pour permettre la transmission de communications simultanées de voix et de données, mais avec une QoS limitée : les liens synchrones orientés connexion (SCO) et les liens asynchrones non orientés connexion (ACL), qui ont des caractéristiques communes avec des services respectivement à commutation de circuits et à commutation de paquets. Le lien de SCO vise à porter le trafic en temps-réel tel que le trafic de voix. Il emploie un mécanisme de réservation de slot qui permet la transmission périodique des données de SCO avec des délais et bande passante garantis. Cependant, il n'est pas flexible et peut seulement fournir une largeur de bande symétrique fixe (tout au plus 64 kb/s). Un tel service n'est pas efficace pour le temps-réel et les applications sensibles au délai comme les flux streaming audio et vidéo qui peuvent exiger la largeur de bande variable et asymétrique. D'ailleurs, le SCO a des possibilités de détection et de correction d'erreur limitées, et aucun mécanisme de retransmission, ce qui le rend inefficace quand les erreurs sur les bits se produisent dans les bursts. D'autre part, le lien ACL a été à l'origine conçu pour les applications de données. Il est basé sur un algorithme de vote entre un maître et jusqu'à sept esclaves actifs. La largeur de bande du ACL est déterminée par le type de paquet du ACL (paquet de taille variable 1, 3 ou 5 slots) et la fréquence avec laquelle la station est votée. Elle peut fournir une largeur de bande symétrique (108.8-432 kb/s) et asymétrique (jusqu'à 721 kb/s, avec 57.6 kb/s pour le canal de retour). D'ailleurs, elle peut fournir une communication fiable en présence d'interférences (même lorsque les erreurs de bits se produisent dans les bursts) en utilisant les deux les mécanismes FEC (Forward Error Correction) et la retransmission d'erreur. Comme le délai des retransmissions est relativement faible ( 1.25ms) dans ce type de réseau, le lien ACL pourrait également être employé pour transmettre des applications temps-réel. Pour des mécanismes plus performants pour vérifier les contraintes de QoS voir [1]et [2] 9

1.2 -IEEE 802.15.3: WiMedia La plupart des informations présentes dans cette partie proviennent de [3] et [4]. 1.2.1 Applications Les applications possibles du WiMedia sont 1- Multimédia - Streaming vidéo et audio - vidéo et audio Interactifs 2- Données : PDA, PC, imprimantes. 3- Images numériques : images fixes et vidéo, 1.2.2 Couche MAC 1.2.2.1 - Caractéristiques générales La couche MAC du 802.15.3 a les caractéristiques suivantes: - La topologie suit le modèle Coordinateur (PNC-PicoNet Coordinator) appareil (DEV- Device).Le PNC va synchroniser la picocellule en spécifiant le temps de chaque connexion, et les commandes vont être échangées entre PNC et DEV. - La communication est en peer-to-peer entre PNC et DEV. - La sécurité et l'authentification font partie intégrante du standard. - Le fonctionnement sécurisé en Ad Hoc est possible. - La QoS est assurée par l'utilisation de la TDMA avec les GTS (Guaranteed Time Slots) dans le cas d un flux Stream 10

Figure 1 - Topologie du WIMEDIA 802.15.3 1.2.2.2 - Structure de la supertrame La structure de base est la supertrame divisée en trois parties Figure 2 - Strucure de la supertrame 802.15.3 - Balise (Beacon) utilise TDMA, est envoyée seulement par le PNC pour synchroniser la picocellule - Période d accès par contention (CAP) pendant laquelle on utilise CSMA/CA pour la transmission de données et de commandes dont certains types peuvent être interdits par le PNC. Le PNC peut remplacer la CAP avec des time slots de gestion MTS, utilisant le slotted-aloha. - Période accès sans contention (CFP) pendant laquelle le PNC alloue les time slots garantis GTS (guaranteed time slots) unidirectionnels, en utilisant la TDMA. Le slotted aloha est utilisé pour les MTS (management time slots) 11

1.2.2.3 - Fonctionnement et QoS Pour pouvoir sélectionner le PNC, chacune des stations appelées coordinateurs alternatifs AC va émettre ses capacités, et en se basant sur un certain critère, le "meilleur" AC est choisi et devient le PNC. Ce dernier commence par émettre une balise pour synchroniser la picocellule. Le PNC va remettre sa fonction à un autre AC plus capable, s'il se présente, à condition que la police de sécurité soit vérifiée. Pour joindre la picocellule la DEV doit envoyer une commande d'association. Le PNC va le lui permettre en se basant sur les ressources disponibles. La DEV va donc s'authentifier si nécessaire, et peut ensuite soit envoyer des données pendant CAP si elle a la permission, ou de faire une requête d'un GTS pour une connexion spécifique. Les GTS qui peuvent être soit des données stream (connexion avec QoS), soit non (connexion sans QoS) sont de deux types: - Les GTS dynamiques : leur position dans la supertrame peut changer d'une supertrame à une autre. - Les GTS pseudo-statiques: Le PNC peut changer leur position mais à condition de le communiquer et d'avoir les confirmations des deux DEV concernées. Les MTS sont utilisés pour la gestion des communications entre PNC et DEV. Elles sont présentes dans la CFP, mais peuvent aussi remplacer la CAP. Quatre types de trames existent: Balise (pour la synchronisation de la picocellule), Immediate ACK (accusé de réception immédiat), les commandes qui peuvent être groupées dans une trame unique et qui sont codées en TLV(Type Longueur Valeur), et les données qui peuvent être cryptées. 1.2.3 Couche PHY - Fonctionne dans la bande 2.4 GHz (sans licence) - Bande passante de 15 MHz - 3 ou 4 canaux disjoints 5 débits possibles - 11 Mbaud - Modulation QPSK, DQPSK, QAM 16, QAM 32, QAM 64. - 11 Mb/s (QPSK) -55 Mb/s (QAM 64) avec un codage de 1 à 5 bits/symbole. - Utilisation du TCM, modulation par codage en treillis. - Puissance TX : 10 à125 mw (avec contrôle de puissance) - Couverture: 10m 12

1.2.4-802.15.3a : UWB (Ultra Wide Band) Le 802.15.3 va présenter de nouvelles caractéristiques. Des débits plus importants 110 Mbps (10m) et 480 Mbps (<10m) seront possibles. Ces performances sont dues à l'utilisation du UWB (Ultra Wide Band) dans la bande 3.1 a 10.7 GHz. Mais il faut avant résoudre les problèmes d interférence possibles avec le satellite et le GPS. Malgré ce qui précède,uwb est en voie de développement car il permet des transmissions rapides, avec des débits très importants permettant des transmissions sans câble, à faible distance (car interférences), de flux tels que par exemple le flux vidéo entre une camera et un écran plasma. Ceci ouvre la porte grande ouverte pour le UWB au domaine très lucratif du "Home Media". 13

1.3- IEEE 802.15.4 : ZigBee 1.3.1-Caractéristiques générales [5] - Le domaine d application : les différents types de senseurs, de télémétrie, - Les débits sont de 250 Kb/s, 40 Kb/s, 20Kb/s - Architecture en étoile ou peer-to-peer - Méthode d accès CSMA-CA. - Adressage dynamique - Faible consommation - Rayon d action 10 m à 80 m - Bandes de fréquence - 16 canaux dans la bande 2.4 GHz - 10 canaux dans la bande 915 MHz - 1 canal dans la bande 868 MHz (Europe) La structure de la supertrame dans ZigBee ainsi que les différents types de trames sont presque identiques à ceux du WIMEDIA. La possibilité de fournir une certaine QoS, si elle est nécessaire, pourra être réalisé en utilisant les GTS comme dans WIMEDIA. Figure 5 - Espace d'applications du 802.15.4 Réseaux Résidentiels Réseaux Automatisés Réseaux Industriels Jouets Interactifs Télémétrie Réseaux en étoile ou Peer-to-Peer 14

2-IEEE 802.11 2.1- INTRODUCTION Les «Wireless Local Area Network» alias WLAN ou Réseaux locaux sans-fil cherchent à offrir les mêmes prestations que les LAN d entreprises avec l avantage de la suppression du câblage et le déplacement à l'intérieur d'un immeuble ou même l'extérieur, dans certaines zones, sans interruption de la session en cours. Plusieurs spécifications du WirelessLAN existent à l heure actuelle. Elles seront exposées ultérieurement dans ce document. Pour définir la norme WirelessLAN, les concepteurs ont pris en considération les points suivants : Robustesse et simplicité de la technologie contre les défauts de communication, afin de pouvoir transmettre dans les meilleures conditions, tenant compte des considérations que le canal de transmission, en l'occurrence l'air, n'est pas aussi fiable que le câble, et qu'il est plus difficile à gérer. Ces caractéristiques ont été vérifiées par l'utilisation d'une approche distribuée du protocole de la couche MAC. Utilisation du WirelessLAN mondialement. C'est-à-dire le respect des différentes règles en usage dans les différents pays du monde. Totale compatibilité avec les anciens produits et les produits actuels qui composent les réseaux LAN. C'est-à-dire que le passage du WirelessLAN au LAN et vice-versa devra être transparent à l utilisateur. Une sécurité acceptable pour le passage de l information dans l air. (WEP). Gestion intelligente de la puissance afin de garantir une durée accrue des batteries composant les différents systèmes Cette technologie très intéressante pourra prendre la relève des LAN au sein des entreprises, mais seulement le principal problème vient de la qualité de transmission, puisque le problème de capacité tend de plus en plus à être réduit, par l'augmentation des débits de transmission. Ce problème vient du fait que le canal de transport du WirelessLAN n est autre que l air. De ce fait, en raison des phénomènes d interférence, de réflexions multiples, de stations cachées, etc., la qualité de la transmission à travers l air donne des taux d erreurs de BER = 10-4. Ce taux d erreurs est bien plus important que celui des fibres optiques par exemple (BER = 10-12 ). Mais avec la prolifération actuelle des systèmes sans-fil, (ie.wpan WLAN et WMAN) qui perturbent et sont perturbés, une nouvelle contrainte s'ajoute réduisant le taux de qualité. Ceci se fait de plus en plus sentir, et le problème de cohabitation entre les différents systèmes sans-fil entre autre les WirelessLAN demande à être résolu. 15

2.2- ARCHITECTURE WLAN Deux types de réseaux WirelessLAN sont définis. Les réseaux à Infrastructure et les réseaux Ad Hoc. 2.2.1 - Réseaux WLAN à Infrastructure Le réseau à infrastructure comprend des points d accès ou Access Point (AP) qui gèrent l ensemble des communications dans une même zone géographique sous la forme de cellule. Ce mode de gestion géographique ressemble un peu au modèle GSM ou UMTS. D ailleurs il fonctionne de façon presque similaire, car les stations munies de carte WirelessLAN peuvent se déplacer dans la zone de couverture de l AP et effectuer un roaming entre les différents AP si la topologie le permet (chevauchement des cellules). Il faut remarquer que chaque AP possède une connexion LAN, ou un autre type de connexion lui assurant la connexion avec le réseau fixe. Figure 6- Réseau Infrastructure 802.11b Dans un réseau à infrastructure, chaque station ayant une carte wirelesslan est appelée STA (Station). Un AP avec des STA présentes dans la couverture de l AP s appelle un BSS (Basic Service Set). A remarquer que dès qu il y a plus qu un BSS, le regroupement s appelle un ESS (Extended Service Set). Quand au DS (Distribution System), il sert à connecter le réseau WirelessLAN à un autre type de réseau. 2.2.2 Réseau WLAN Ad Hoc Un réseau Ad Hoc ou encore IBSS (Independent Basic Service Set) est un ensemble de stations possédant une carte WirelessLAN sans la présence d un AP. Contrairement au réseau à infrastructure, les stations dans un réseau Ad Hoc communiquent directement entre elles. 16

Figure 7- Reseau Ad Hoc 802.11b 2.3- La couche MAC 2.3.1-802.11 Dans 802.11 deux fonctions de base existent pour l'accès au medium: - DCF : Distributed Coordination Function - PCF : Point Coordination Function Le DCF est responsable des services asynchrones, alors que PCF a été développé pour les services à contraintes temporelles. Le PCF est utilisé pendant la contention-free period (CFP) période de non contention, alors que DCF utilise la contention period (CP).Une CFP et une CP forme une supertrame. Les supertrames sont séparées par des trames périodiques de gestion appelées Beacon ou balise. 802.11 utilise trois intervalles de temps différents, nommés interframe spaces (espaces inter trames) pour contrôler l'accès au médium, ç.à.d. pour donner aux stations dans des cas bien spécifiques une plus ou moins importante priorité: - Short Interframe Space (SIFS) - PCF Interframe Space (PIFS) - DCF Interframe Space (DIFS) SIFS est le plus court intervalle. Il est utilisé pour les accusés de réception ACK, les trames CTS (Clear to Send) et les différents fragments du paquet d' information MPDU, ainsi que pour la réponse d'une station au AP dans le mode Polling (mode vote) dans PCF. SIFS représente la plus 17

haute priorité et assure qu'une station est capable de finir la séquence de transmission de trame avant qu'une autre station puisse accéder au médium. PIFS est plus long que SIFS. Après l'expiration de cet intervalle, n'importe quelle trame du mode PCF peut être transmise. DIFS est plus long que PIFS. Après l'expiration de cet intervalle, n'importe quelle trame du mode DCF peut être transmise, de façon asynchrone selon le mécanisme du backoff de la CSMA/CA. Donc DIFS a la plus faible priorité. 2.3.1.1- DCF: Distributed Coordination Function Dans DCF les stations utilisent le mode de contention pour accéder au canal. Pour cela elles utilisent le "carrier sense multiple access with collision avoidance" (CSMA/CA) pour que plusieurs stations puissent accéder le médium en utilisant la méthode de détection de porteuse à accès multiples et évitement de collision. DCF ne fonctionne que durant la période CP. Chaque station, après que le médium devient libre, attend une durée fixe DIFS suivie d une durée aléatoire appelée backoff time, avant de commencer à émettre, si le canal est toujours libre. Effectivement la durée backoff time est donnée par la formule : Backoff time = Random( 0, CW ) x SlotTime où Random( 0, CW ) est une valeur aléatoire entière uniformément distribuée sur [0, CW] avec CW (Contention Window) la fenêtre de contention vérifiant CW min CW CW max =1023. Initialement on a CW= CW min = 15 dans 802.11. SlotTime est une durée fixe (9µs dans 802.11a) Figure 8 - Méthode d'accès au medium Si le médium devient occupé avant l expiration de la durée du backoff, la station attend de nouveau la libération du médium puis attend DIFS et le reste du backoff précédent avant d émettre de nouveau. Au cas où deux stations émettent en même temps, ce qui entraîne une collision détectée par la non-réception d un ACK la nouvelle fenêtre de contention CW est augmentée pour réduire la probabilité de collision, et devient CWnew = 2*CW old + 1 (15, 31, 63, 127, 255, 511, 1023) 18

2.3.1.2- PCF: Point Coordination Function Le PCF peut être uniquement utilisé dans les réseaux à infrastructure, car il nécessite la présence d'un AP (access point). Le PC (Point Coordinator) normalement installé sur le AP, contrôle l accès au médium par la méthode du Polling. Il faut noter que PCF est optionnel, et peut donc être implémenté avec DCF. Le PC après un temps PIFS pendant lequel le canal est libre envoie la balise " Beacon " qui marque le début de la supertrame, divisée en deux parties: la CFP et la CP. Initialement la durée maximale de la CFP CFPMaxDuration, ainsi que sa fréquence sont données; mais cette dernière n'est pas respectée la plupart du temps car le beacon peut être retardé, à cause d'une longue transmission d'une trame à la fin de la CP. Ce problème ne permet pas d'avoir une séquence rigoureusement périodique de la balise. Comme PCF a été développée au dessus de DCF toutes les stations doivent activer leur NAV (Network Allocation Vector) au début de la CFP à la valeur CFPMaxDuration pour bloquer toute transmission parasite (contention) pendant la durée CFP, car aucune station n a le droit d émettre que si on le lui demande pendant la CFP. Pendant la durée du CFP le PC attend une durée SIFS après le beacon avant d'envoyer une trame de données ou le CF-Poll ou faire du piggybacking (une trame de données qui contient aussi un message de polling). Le PC va séquentiellement faire du polling, pendant la durée CFP, pour toutes les stations déjà enregistrées dans sa liste. La station concernée va répondre au PC ou à une autre station dans le réseau par des trames de données ou un ACK séparés par SIFS. Si une station ne répond pas, le PC passe à la suivante après PIFS. Si le PC ou les stations n'ont plus de trames a transmettre, la CFP se termine par l'envoi de la trame CF-end par le PC. Toutes les stations vont alors remettre a zéro leur NAV, et la CP va débuter, et on repasse alors au mode DCF. Il faut noter qu'aucune station n a le droit d émettre que si on le lui demande pendant la CFP. Si le PCF est utilisé pour les applications à contraintes temporelles, le PC doit établir une liste de polling. Chaque station doit être votée au moins une fois par CFP. Les stations peuvent demander une place dans la liste de polling avec des trames de gestion d'associations. Le PC peut avoir un modèle de priorité pour les différentes stations. Figure 9- Alternance de CFP et CP 19

Figure 10 Principe de fonctionnement de PCF 2.3.1.3- Première extension: RTS/CTS Un problème crucial pendant la CP est celui de la station cachée. Celui-ci a lieu lorsqu'une station ne peut pas entendre toutes les communications entre deux stations car l'une des deux est éloignée d'elle, et considère alors que le medium est libre. Une collision va avoir lieu si cette station va essayer d'émettre. Pour résoudre ce problème on a dû ajouter deux paquets de contrôle à la DCF: RTS (Request To Send) demande d'émission, et CTS (Clear to Send) permission d'émission. Lorsqu une station a accès au médium elle commence à émettre un RTS (après la libération du canal pendant au moins DIFS) reçoit un CTS (Clear to Send) transmet sa trame (ou ses fragments) et reçoit l ACK (ou les ACK).La durée qui sépare ces messages est SIFS (Short IFS), avec SIFS< DIFS pour ne pas interrompre la transmission par une autre station. Le RTS contient un champ de durée qui donne la durée totale du CTS, des données, et ACK ainsi que les SIFS. Toutes les stations réceptrices vont mettre leur NAV à cette valeur, spécifiant alors la durée d'occupation du canal. Un champ de durée existe aussi dans CTS comprenant la durée totale des données, ACK et SIFS. De cette manière les stations qui reçoivent RTS ou CTS mettent leurs NAV à la valeur correspondante, ce qui résout le problème des stations cachées. Comme la collision ne peut avoir lieu que seulement avec RTS, ce mécanisme fournit une excellente protection contre les collisions pour les grandes trames. Le désavantage majeur est l'overhead de RTS/CTS avec une perte de bande passante et un délai plus important. 20

Figure 11- Problème de la station cachée 2.3.1.4- Deuxième extension: Fragmentation A cause du BER important dans les WLAN dû aux interférences, les petites trames ont une probabilité plus importante que les grandes trames d'être émises sans erreurs. En utilisant cette propriété, la fragmentation a été ajoute au mécanisme de la couche MAC 802.11 (fig. 12). Les grandes trames sont ainsi divisées en de petits fragments lorsque leur taille dépasse un certain seuil. Chaque fragment est émis et acquitté séparément. Une fois que la station a accès au medium elle peut émettre plusieurs séquences Data/ACK séparées par SIFS, ce qui lui assure de ne pas être interrompue par une autre station avant de compléter sa transmission. Figure 12 - Transmission des fragments d'un MSDU séparés par SIFS 21

2.4 - Couche PHY 2.4.1 - IEEE 802.11.b: WiFi - Fonctionne dans la bande 2.4-2.4835 GHz - Utilise la DSSS.(étalement de spectre par séquence directe) - Supporte les débits : 1, 2, 5.5, 11 Mbps - Bande passante de 22 MHz - 13 canaux séparés de 5 MHz (4 canaux disjoints) - Puissance maximale du TX : 100mW (ETSI) - Distance nominale @ 11Mbps - Intérieur, pas d antenne externe, NLOS : 30m - Extérieur, antennes externes, LOS : 500m 2.4.2 - IEEE 802.11.a/h La différence avec IEEE 802.11.b est surtout dans la couche physique - Fonctionne dans la bande 5.150-5.350 GHz (intérieur), 5.470-5.725 GHz (ETSI, extérieur), 5.725-5.825 GHz (US, extérieur) - Utilise la OFDM (Orthogonal Frequency Division Modulation), idéale pour un environnement interne et urbain. - Supporte les débits : 6, 9, 12, 18, 24, 36, 48, 54 Mbps - Bande passante de 20 MHz - Canaux disjoints : 8 (intérieur), 11(ETSI, extérieur), et 4 (US, extérieur) - Puissance maximale du TX : 200mW (intérieur) et 1W (extérieur) - Distance nominale @ 24Mbps - Intérieur, pas d antenne externe, NLOS : 30m - Extérieur, antennes externes, LOS : 500m 2.4.3 - IEEE 802.11.g IEEE 802.11.g est rétrocompatible avec 802.11.b - Fonctionne dans la bande 2.4-2.4835 GHz - Utilise la OFDM (Orthogonal Frequency Division Multiplex), idéale pour un environment interne et urbain. - Supporte les débits : 6, 9, 12, 18, 24, 36, 48, 54 Mbps - Bande passante de 20 MHz - Meilleure couverture que 802.11a 22

2.5 - IEEE 802.11e Le standard IEEE 802.11e a introduit la QoS dans la couche MAC du 802.11. Voir [6] 2.5.1- Limitations de la QoS dans 802.11 - DCF - Supporte uniquement le Best effort BE - Pas de garantie de bande, de délai et de gigue - Dégradation du débit a forte charge - PCF - Système de vote (polling) central inefficace. - Temps de transmission des stations votées est inconnu, car la taille d'une trame est arbitraire et peut atteindre 2312 octets. - Délai imprévisible du beacon dû à un medium occupé à TBTT (l'instant où le PC commence un nouveau CFP en envoyant un nouveau Beacon), ceci a lieu si on a une transmission d'une longue trame à la fin de la CP. - Pas de différentiation des trafics. VoIP, vidéo, données, utilise la même file. 2.5.2- QoS dans 802.11e - le but est de supporter IntServ et DiffServ - Wireless Multimedia Enhancement (WME) - Nouveaux mécanismes de QoS - EDCF (Enhanced DCF) - HCF (Hybrid Coordination Function) - Rétrocompatible avec le DCF et PCF 2.5.3- EDCF : Enhanced DCF EDCF est une version améliorée de DCF utilisant aussi le CSMA/CA. La méthode d'accès par contention au canal est appelée EDCA (Enhanced Distributed Channel Access) Les améliorations apportées par EDCF sont les suivantes: - EDCF permet la différentiation de services en introduisant 4 classes d accès AC (Access Category) représentant 4 priorités avec des paramètres différents, qui seront vues en détail ultérieurement. - 8 priorités, TC (Trafic Category) selon IEEE 802.1D sont mappées sur les 4 AC (fig. 13). 23

- Aucune station (plus précisément une entité AC) ne peut occuper le canal pendant une durée supérieure à une certaine limite. En introduisant la notion de TXOP [AC] (Transmission Opportunity) qui représente un intervalle de temps pendant lequel une entité backoff (correspondant à un AC) a le droit d'émettre. Le TXOP appelé EDCA-TXOP est défini par son instant initial et par sa durée. Sa durée maximale TXOPlimit est distribuée régulièrement dans la QBSS (QoS BSS) dans chaque Beacon. Le TXOP permet donc de limiter les délais de transmission pour pouvoir fournir une certaine QoS. - Aucune entité n'a le droit de dépasser la valeur du TBTT. Ceci signifie que pendant le CP une transmission d'une trame ne peut avoir lieu que si la transmission complète peut se faire avant l'arrivée du beacon suivant (séparé de TBTT du précédent). De cette manière les retards du beacon seront contrôlés et les contraintes temporelles des flux mieux vérifiées. - Si dans une même station les débuts de transmission de deux flux de deux entités coïncident, on a une collision virtuelle et c est le flux prioritaire qui est émis. - Possibilité d'échange de trames directement entre deux stations sans passer par l'ap, en utilisant le protocole DLP (Direct Link Protocol) 2.5.3.1 - Paramètres des AC dans EDCA - Quatre AC avec des paramètres différents existent avec EDCA, ils sont désignés par les flux qui les utilisent: AC_VO (voix), AC_VI (vidéo), AC_BE (Best Effort), et AC_BK (Background). - Remplace DIFS par AIFS [AC] (Arbitration IFS), avec AIFS [AC] =SIFS + AIFSN [AC] x SlotTime où AIFSN [AC] 2, Avec AIFS [AC] DIFS, et AIFSN [AC] a la valeur la plus faible pour la priorité la plus importante (Audio = vidéo < données. ) (fig. 14 ) - CWmin [AC] et CWmax [AC] varient avec les AC (Audio < Vidéo < Données). (table 1) - Facteur de Persistance PF différent par AC au début, puis fixé à la valeur 2 par la suite, avec CW new = (CW old +1) x PF -1. 24

Figure 13 - Station 802.11 et Station 802.11e avec quatre AC par station CWmin CWmax AIFSN AC_VO 3 7 2 AC_VI 7 15 2 AC_BE 15 1023 3 AC_BK 15 1023 7 Table 1 - Paramètres de EDCA selon [6] 25

Figure 14 - Paramètres pour différentes priorités dans EDCA 2.5.4 - HCF : Hybrid Coordination Function HCF est une version améliorée du principe du PCF. Elle a les propriétés supplémentaires suivantes: - PCF fonctionne uniquement pendant la CFP, alors que HCF fonctionne dans la CFP et la CP, d'où l'appellation d'hybride. - Fournit une gestion de politiques et un accès de canal déterministe en contrôlant le canal par le coordinateur hybride HC (Hybrid Coordinator) - Détectant le canal comme étant libre pendant PIFS, plus court que AIFS, accorde au HC une priorité élevée sur EDCF, ce qui lui permet d'émettre même pendant la CP. - Le modèle de HCF peut fournir à des services garantis une probabilité beaucoup plus élevée que EDCF pur. - Un protocole de signalisation peut être employé pour faciliter le contrôle d'admission et pour spécifier les besoins du débit nécessaire au service. - Comme le TXOP est limité pour EDCA (EDCF access) donc HCCA (HCF access) peut fournir un meilleur service à forte contrainte temporelle. La TXOP dans 26

HCCA est appelée polled-txop, elle est allouée par le HC, et est limitée par TXOPlimit. Figure 15 -Supertrame 802.11e. Utilisation des TXOP. Les polled-txop existent dans CP et CFP 2.5.4.1 - Une proposition d'algorithme d'ordonnancement du HCF Un algorithme d'ordonnancement simple a été proposé comme modèle de référence [7] pour que HCF puisse prendre en compte des contraintes de QoS de différents types de trafic. Chaque QSTA (Station avec QoS) nécessitant des conditions strictes de QoS est allouée à envoyer des paquets de requête au QAP, et ce dernier peut allouer les intervalles d'émission de chaque station selon les requêtes. La HCF pouvant fonctionner pendant CFP mais aussi pendant CP va entamer l'émission de bursts sans contention appelés CAP (Controlled Access Periods) pendant la durée CP pour contrôler le canal (fig 16). En utilisant le concept du TXOP pendant lequel une QSTA donnée a le droit d'envoyer des paquets, une QSTA peut lancer les transmissions multiples aussi longtemps que son TXOP n'a pas expiré. Le but de présenter TXOP est de limiter l'intervalle de temps pendant lequel on permet à une QSTA de transmettre des trames. Chaque QSTA peut avoir jusqu'à 8 flux différents TS (Traffic Streams) mappés sur 4 classes de priorité, les AC. Fondamentalement, chaque TS envoie d'abord une trame de requête de QoS au QAP contenant le débit moyen de l'application correspondante, la taille du MSDU (MAC Service Data Unit) et de l'intervalle de service exigé maximal RSI (Required Service Interval). En utilisant ces demandes de QoS, le QAP détermine d'abord la valeur minimale de tous les RSI exigés par les différents trafics, puis il choisit la valeur du sous-multiple la plus élevée de la durée d'intervalle du beacon 802.11e (durée entre deux beacon) comme intervalle de service choisi SI (Service Interval), qui est inférieur au minimum de tous les RSI maximum. Ainsi, un intervalle du beacon 802.11e est coupé en plusieurs SIs et les QSTA sont votées en conséquence pendant chaque SI choisi. Le SI choisi se rapporte au temps entre les débuts des TXOP successifs assignés à une QSTA, qui est le même pour toutes les stations. Dès que le SI choisi sera déterminé, le QAP évalue tout les TXOP assignés aux différents TS de la QSTA qui s'appliquent pour HCCA. Le TXOP devrait correspondre à la durée exigée pour transmettre tous les paquets arrivant pendant un SI dans une file d'attente de TS. 27

Figure 16 - La structure de la supertrame utilisée dans l'algorithme d'ordonnancement du HCF [ 7 ] 2.6 Packet Frame Grouping (PFG) PFG a été introduit dans [8] pour améliorer les performances pour les petits paquets (pour les services à contraintes temporelles) dans WLANs en diminuant l'overhead et le délai et en augmentant le débit. PFG emploie fondamentalement l'idée d'un burst fragmenté (de 802,11 DCF) où une station envoie de petits fragments d'un grand MSDU comme burst si elle accède au médium (fig.17). Avec PFG, ce ne sont pas des fragments d'un grand MSDU, mais une série de petits MSDU qui sont transmis dans un burst. Il est possible d'envoyer des paquets à différentes destinations dans un burst. Entre un ACK et le paquet suivant seulement un intervalle de temps de SIFS est exigé. Par conséquent les stations conservent le contrôle du medium pour la totalité du burst. L'envoi de petits paquets multiples dans un burst évite la contention pour chaque paquet. Ceci a comme conséquence un efficacité plus élevée et un délai plus faible selon [8]. Comme décrit dans [8] WLAN n'est pas équitable envers les petits paquets, à cause de leur taille. L'équitabilité dans 802,11 DCF est réalisée par la contention pour les paquets, c.-à-d. chaque station a la même probabilité pour envoyer un paquet. Les stations qui envoient seulement des paquets relativement petits, sont injustement traitées, contrairement aux stations qui envoient la plupart du temps de grandes trames 28

Figure 17 - Principe de PFG (source: [ 8 ]) Aujourd'hui, CFB est désigné également sous le nom de TXOP Bursting. Le dernier draft [9] contient le mécanisme de CFB dans "Obtaining a Continuation of EDCA TXOP".802.11e Il propose la fragmentation/défragmentation seulement pour un MSDU unique. 29

3 - IEEE 802.16 3.1 - INTRODUCTION Le standard IEEE 802.16 définit les spécifications pour les réseaux métropolitains radio ou les WMAN (Wireless Metropolitan Area Network), ou tout simplement une boucle locale radio. Un WMAN fournit un accès réseau aux immeubles et localités à travers des antennes extérieures communicant avec une station de base la BS. Les WMAN offrent une alternative aux réseaux câblés (coaxial, fibres optique, DSL ) en utilisant les ondes hertziennes. Comme les réseaux radios couvrent des zones géographiques importantes, sans la contrainte d'installation des infrastructures coûteuses pour faire parvenir la connexion par câble jusqu'à l'utilisateur, l'avenir de cette technologie est prometteur, à un tel point que INTEL décrit le IEEE 802.16 comme étant "la deuxième révolution après Internet", surtout qu'elle peut fournir des débits importants avec QoS, chose que ne pouvaient fournir les systèmes cellulaires présents, dont le point fort demeure la mobilité. Figure 18 - Le standard IEEE 802.16 permet des solutions qui répondent aux besoins d'une variété de segments large bande. 30

Le premier élément de l'architecture WMAN est la station de base BS, qui couvre une certaine zone géographique où des utilisateurs stationnaires ou en mouvement relativement lent peuvent communiquer avec la BS selon le principe du point à multipoints. Les applications possibles avec 802.16 sont nombreuses. Effectivement la 802.16 peut relier des hotspots en 802.11 entre eux ou avec le réseau fixe, permettre la liaison entre tours cellulaires, fournir du haut débit sur demande,aux entreprises ou même aux utilisateurs particuliers, surtout dans les zones difficiles d'accès aux réseaux câblés. Le 802.16 semble une solution très intéressante pour les utilisateurs. Ce réseau peut fournir des débits importants, une échelonnabilité due à la possibilité d'avoir des capacités de canal flexibles, une couverture importante (jusqu'à 50 Km) des services avec exigences de QoS ainsi qu'une sécurité importante [10]. En dépit de tous les avantages du système, il reste quand même le problème de la gestion de la mobilité comme dans les systèmes cellulaires, mais il semble qu'ils sont en train de travailler dessus dans le groupe de travail 802.16e. La plupart des informations sur le 802.16 ont été tirées de [11] 3.2 Groupes de travaux du IEEE 802.16 : La norme IEEE 802.16 comporte plusieurs groupes d étude : - Le groupe 802.16 pour les fréquences >10 GHz. Couche MAC commune (16,16a, 16b) - Le groupe 802.16a pour les fréquences <11 GHz - Le groupe 802.16b pour les fréquences <11 GHz, sans licences (UNII, 5-6 GHz, USA) - Le groupe 802.16.2 qui émet des recommandations pour la coexistence des systèmes 802.16 - Le groupe 802.16e pour la mobilité dans les systèmes 802.16 3.3 - Couche MAC La couche MAC est divisée en 3 sous-couches : - La SSCS (Service Specific Convergence Sublayer) - Sous-couche Commune qui contient les fonctions clés de la couche MAC - Sous-couche de protection (Privacy sublayer) qui contient les fonctions d authentification et de cryptage. 31

Figure 19 - Différentes sous-couches MAC et couche PHY dans 802.16 3.3.1- Service-Specific Convergence Sublayer La norme IEEE 802.16 définit deux sous-couches de convergence de services spécifiques pour mapper des services à partir et depuis les connexions MAC 802.16. Les deux services de convergence sont: - La sous-couche de convergence ATM qui est définie pour des services ATM. - La sous-couche de convergence de paquets est définie pour mapper des services de paquets tels que IPv4, IPv6, Ethernet, et réseau local virtuel (VLAN). La tâche primaire de la sous-couche est de classifier des unités de données de service SDU (Service Data Unit) à la connexion appropriée MAC, de préserver ou permettre la QoS, et permettre l'attribution de bande passante. Le mapping prend diverses formes selon le type de service. En plus de ces fonctions de base, les sous-couches de convergence peuvent également exécuter des fonctions plus sophistiquées telles que la suppression et la reconstruction d'en-tête de charge utile pour augmenter l'efficacité du lien hertzien. 32

3.3.2- Common Part Sublayer 3.3.2.1 Introduction et architecture générale En général, la couche MAC 802.16 est conçue pour soutenir une architecture point à multipoints avec une BS (Base Station) centrale manipulant simultanément des secteurs multiples indépendants. Sur le lien descendant, des données vers les SS (Subscriber Station) sont multiplexées en mode TDM. Le lien montant est partagé entre SS en mode TDMA La couche MAC 802.16 est orientée connexion. Tous les services, y compris les services non connectés, sont associés à une connexion. Ceci fournit un mécanisme de demande de bande passante, d'associer la QoS et les paramètres du trafic, transporter et router des données à la souscouche de convergence appropriée, et toutes autres actions liées aux limites contractuelles du service. Les connexions sont référencées par un identifiant de connexion sur 16 bits (CID) et peuvent demander la bande passante accordée continuellement (granted bandwidth), ou la bande passante sur demande. Les deux méthodes sont possibles. Chaque SS a une adresse MAC standard sur 48-bit, mais ceci sert principalement d'identifiant d'équipement, puisque les adresses primaires utilisées lors du fonctionnement sont les CID. Dès l'entrée sur le réseau, la SS est assignés trois connexions de gestion dans chaque sens de communication. Ces trois connexions reflètent les trois exigences différentes de QoS employées par les différents niveaux de gestion. - La première de ces trois connexions est la connexion de base, qui est employé pour le transfert de court messages, tels les messages MAC à temps critique et les messages de contrôle de lien radio (RLC). - La connexion primaire de gestion est employée pour transférer des messages plus longs, tolérants au délai comme ceux utilisés pour l'établissement de la connexion, et l'authentification. - La connexion secondaire de gestion est employée pour le transfert des messages de gestion basés sur des standards tels que le Dynamic Host Configuration Protocol (DHCP), le Trivial File Transfer Protocol (TFTP), et le Simple Network Management Protocol (SNMP). En plus de ces connexions de gestion, des connexions de transport sont allouées sur les SS pour les services contractés. Les connexions de transport sont unidirectionnelles pour faciliter les différents QoS et paramètres de trafic sur le lien montant et le lien descendant; ils sont typiquement assignés aux services par paires. MAC réserve les connexions additionnelles pour d'autres buts. - Une connexion est réservée pour l'accès initial basé contention. - Une autre est réservée pour des transmissions broadcast sur le lien descendant, aussi bien que pour demander aux SS si elles ont besoin de bande passante supplémentaire (les SS utilisent la contention) 33

- Des connexions additionnelles sont réservées pour le multicast, pour le vote basé contention. Les SS peuvent être invités à joindre des groupes multicast votés, liés à ces connexions de vote multicast. 3.3.2.2- Les formats de PDU MAC La PDU MAC est l'unité de données échangée entre les couches MAC du BS et de son SS. Une PDU MAC est composée d'un en-tête de longueur constante MAC, d'une charge utile de longueur variable, et d'un champ optionnel CRC (Cyclic Redundancy Check). Deux formats d'en-tête, distingués par le champ de HT, sont définis: - l'en-tête générique (fig. 20) - l'en-tête de demande de bande passante. Figure 20 - Format d'un entête générique d'un PDU MAC Excepté la demande de bande passante par un MAC PDU, qui ne contiennent aucune charge utile, le MAC PDU contiennent des messages de gestion MAC ou des données des sous-couches de convergence. Trois types de sous en-tête MAC peuvent être présents: - Le sous-en-tête de gestion des droits est employé par un SS pour transporter la demande de bande passante voulue auprès de son BS. - Le sous-en-tête de fragmentation contient l'information qui indique la présence et l'orientation dans la charge utile de tous les fragments de SDUs. - Le sous-en-tête d'agrégation est employé pour indiquer le regroupement de SDU multiples dans une PDU unique. Les sous en-têtes de gestion et de fragmentation peuvent être insérés dans un MAC PDU juste après l'en-tête générique si le champ de type l'indique. Le sous-en-tête d'agrégation peut 34

être inséré avant chaque MAC SDU si ceci est indiqué par le champ de type. Plus de détails sont fournis ci-dessous. 3.3.2.3 - Transmission d'un MAC PDU La couche MAC du 802.16 supporte de nombreux protocoles de haut niveau, tel que ATM ou IP. Les MAC SDU provenant des sous-couches de convergence correspondantes sont formatés selon le format de MAC PDU, probablement avec la fragmentation et/ou l'agrégation, avant d'être envoyés par l'intermédiaire d'une ou plusieurs connexions selon le protocole MAC. Après avoir traversé le lien hertzien, les MAC SDU originaux sont reconstruits de nouveau à partir des MAC PDU reçus de sorte que les modifications de format effectuées par le protocole de la couche MAC soient transparentes à l'entité réceptrice. IEEE 802.16 tire profit d'incorporer en même temps les processus d'agrégation et de fragmentation avec le procédé d'attribution de bande passante pour maximiser la flexibilité, l'efficacité de tous les deux. La fragmentation est le processus dans lequel un MAC SDU est divisé en un ou plusieurs fragments de MAC SDU. L'agrégation est le processus dans lequel plusieurs MAC SDU sont agrégés dans une charge utile d'un MAC PDU unique. Les deux processus peuvent être lancés par ou bien un BS pour une connexion de lien descendant ou un SS pour un connexion d'un lien montant. IEEE 802.16 permet la fragmentation et l'agrégation simultanées pour une utilisation optimale de la bande passante. Figure 21- Fragmentation et Agrégation dans la couche MAC 35

3.3.2.4 - Le support physique et la structure de trame A- La sous-trame du lien descendant La couche MAC de IEEE 802.16 supporte à la fois TDD (Time Division Duplex) où les liens montant et descendant se partagent le même canal mais ne transmettent pas simultanément, et FDD (Frequency Division Duplex), avec laquelle les deux liens montant et descendant utilisent deux canaux séparés, et peuvent transmettre simultanément. Avec FDD, les liens descendants continus ou en burst sont supportés. Les liens descendants continus tiennent compte de certaines techniques de perfectionnement de robustesse, telles que l'entrelacement de trames. Les liens descendants de burst (FDD ou TDD) permettent l'utilisation de techniques plus avancées de perfectionnement de robustesse et de capacité, telles que le profil de burst adaptatif, correspondant au niveau de l'abonné, et les systèmes évolués d'antennes. Le profil de burst adaptatif est le choix dynamique burst par burst des types de modulation et de codage (Voir couche physique). La couche MAC construit la sous-trame de lien descendant commençant par une unité de commande de trame contenant les messages DL-MAP et UL-MAP. La DL-MAP spécifie quand les transitions de la couche physique du lien descendant ont lieu (la modulation et le FEC changent), alors que la UL-MAP spécifie les allocations de bande passante et les profils de burst du lien montant. La sous-trame du lien descendant contient généralement une portion en TDM immédiatement après la trame de contrôle de section, qui contient les données vers les différentes SS. Ces données sur le lien descendant sont transmises à chaque SS en utilisant le profil de burst déjà négocié, spécifié par un code d'utilisation d'intervalle de lien descendant DIUC (Downlink Interval Usage Code). Les données sont transmises par ordre de robustesse décroissante pour permettre au SS de recevoir leurs données, avant que ne se présente un profil de burst moins robuste qui causera la perte de synchronisation entre le SS et le lien descendant. Dans les systèmes FDD, la partie TDM peut être suivie par une partie en TDMA où chaque segment comprend un préambule pour la synchronisation, si certaines SS fonctionnent en mode half-duplex. 36

Figure 22- Structure de la sous-trame du lien descendant Le message DL-MAP est toujours applicable à la trame courante et est toujours au moins de longueur égale à deux blocs FEC. La première transition de la couche physique est indiquée dans le premier bloc FEC, pour accorder un temps de traitement adéquat. Dans les deux systèmes TDD et FDD, le UL-MAP fournit des attributions commençant pas plus tard que la prochaine trame de lien descendant. Le message UL-MAP peut, cependant, commencer à allouer dans la trame courante aussi longtemps qu'on respecte les durées du traitement et du délai d'aller-retour. Le temps minimum entre la réception et l'application du message UL-MAP pour un système de FDD est montré dans la figure ci-dessous. Figure 23 - Correspondance minimale du UL-MAP avec la trame montante dans FDD 37

B- La sous-trame du lien montant La sous-trame du lien montant contient un message de contention pour l accès initial au système et pour les requêtes de bande passante transmises en multicast et broadcast. Pour l accès au système, les opportunités d accès sont choisies de manière à accorder un temps supplémentaire pour les SS qui n ont pas résolu assez tôt le transmit time advance (en fait, qui n ont pas envoyé en avance leurs trames) afin de pallier au décalage temporel de la transmission avec le BS. Ensuite sont émis les bursts des différents SS en utilisant le profil du burst spécifié par le UIUC (Uplink Interval Usage Code). Les UIUC sont spécifiés dans l entrée de la UL-MAP Figure 24- Structure de la sous-trame du lien montant 3.3.2.5 - Contrôle du lien radio La technologie de pointe des 802.16 PHY exige le contrôle également avancé du lien radio (RLC), en particulier les possibilités de la couche PHY à la transition d'un profil de burst à un autre. Le RLC doit contrôler ces possibilités aussi bien que les fonctions traditionnelles de RLC du contrôle de puissance et de ranging. RLC commence par l'émission périodique des profils de burst du BS, qui ont été choisis pour le lien montant et le lien descendant. Les profils particuliers de burst, utilisés sur un canal sont choisis selon un certain nombre de facteurs, tels que des possibilités de région de pluie et les capacités des équipements. Les profils de burst du lien descendant sont chacun marqués avec un code d'utilisation d'intervalle de lien descendant DIUC (Downlink Interval Usage Code). Ceux du lien montant sont chacun marqués avec un code d'utilisation d'intervalle du lien montant UIUC (Uplink Interval Usage Code). Pendant l'accès initial, des messages spécifiques RNG-REQ et RNG-RSP sont transmis entre BS et SS pour la mise à niveau de la puissance d'émission, et l'ajustement de l'avance du temps de transmission. 38

Pendant la séquence initiale de ranging, la SS demande également d'utiliser sur le lien descendant un profil de burst particulier, en transmettant son choix de DIUC à la BS. Le choix est basé sur des mesures de qualité du signal reçu sur le lien descendant, effectuées par la SS avant et pendant le ranging initial. La BS peut confirmer ou rejeter le choix dans sa réponse. De même, la BS surveille la qualité du signal qu'elle reçoit des SS sur le lien montant. Le BS commande la SS pour employer un profil particulier de burst sur le lien montant simplement en incluant le profil approprié UIUC de burst avec les concessions des SS (SS grants) dans des messages UL_MAP. Après la détermination initiale des profils de burst sur le lien montant et le lien descendant entre la BS et SS particuliers, RLC continue à surveiller et commander les profils de burst. Des conditions environnementales plus dures, telles que les fadings dus à la pluie, peut forcer la SS à demander un profil de burst plus robuste. Alternativement, le temps particulièrement beau peut permettre des SS à fonctionner temporairement avec un profil plus efficace de burst. Le RLC continue à adapter les profils de burst des SS sur les liens montant et descendant courants, en essayant de réaliser un équilibre entre la robustesse et l'efficacité. Pour plus de détails sur le changement et allocations des profils de burst, voir [11]. 3.3.3- Privacy sublayer - Contient les fonctions d authentification et de cryptage[11]. 39

3.4 - QoS dans IEEE 802.16 Par sa conception même Le 802.16 a été conçu dès le début pour supporter la QoS, avec l'utilisation entre autre des profils de burst adaptatifs, des requêtes de bande passante etc. Nous allons voir dans la suite de l'exposé les détails du traitement de la QoS dans 802.16. 3.4.1- Demande et attribution de bande passante La couche MAC du IEEE 802.16 permet de différencier deux classes de SS. Alors que dans les deux classes la requête de la bande passante est faite par la SS pour une connexion donnée, pour permettre à l'algorithme d'ordonnancement du lien montant de la BS de considérer correctement la QoS nécessaire en allouant la bande passante en tenant compte des conditions demandées de QoS et des ressources disponibles. La SS peut demander la bande passante de 3 manières: 1- Utiliser l intervalle contention request opportunities en étant votée par la BS (multicast ou broadcast). 2- Envoyer un message MAC autonome appelé BW request dans un slot déjà accordé. 3- Ferroutage (piggyback) d'un message de demande de BP sur un paquet de données. La BS va donc allouer et attribuer la bande passante dans UL-MAP suivant l'un des deux modes suivants correspondant aux deux classes de SS: - GPC (Grant per Connection): Où la bande passante est allouée explicitement par la BS à une connexion, et la SS emploie la concession seulement pour cette connexion. RLC et d'autres protocoles de gestion emploient la bande passante explicitement assignée aux connexions de gestion. Ce mode est le plus simple mais moins efficace et échelonnable que GPSS. - GPSS (Grant per SS): Où l'allocation de la bande passante par la BS est faite par station d'abonné SS, qui va ensuite répartir cette bande passante totale sur les différentes connexions. La SS peut changer dynamiquement l'allocation de bande passante suivant les variations des caractéristiques des différents flux, et gère plus efficacement l'allocation de bande passante, car il réagit plus rapidement aux variations des conditions de l'environnement. GPSS est le seul mode permis avec PHY 10-66 GHz. Toutefois il faut remarquer que les stations utilisant le GPSS nécessitent une intelligence plus importante pour la gestion de l'allocation de BP. 3.4.2- Services dans 802.16 [11] Chaque connexion sur le lien montant est mappée à un service spécifique. Chaque service est associé à un ensemble de règles imposées par l'ordonnanceur de la BS responsable d'assigner la capacité du lien montant et du protocole requête-concession entre SS et BS. Les spécifications détaillées des règles et du service utilisées pour une connexion particulière du lien montant sont négociées lors de l'établissement de la connexion. 40

Quatre services correspondant à quatre classes de QoS sont en principe définis dans 802.16 1- UGS (Unsolicited Grant Service): Service à concession non sollicitée Le service à concession non sollicité (UGS) est conçu pour les services qui produisent périodiquement des unités de données de longueur fixe. La BS émet régulièrement, de façon préemptive, des concessions selon la taille négociée à l'établissement de la connexion, sans demande explicite des SS. Ceci va permettre de vérifier les contraintes temporelles comme le délai et la gigue. Une limite pratique sur la gigue du délai est fixée par la durée de trame. Si des conditions plus rigoureuses de gigue doivent être vérifiées un buffering est nécessaire. [11]. Les services qui typiquement pourraient utiliser les connexions avec le service UGS incluent ATM avec CBR, les flux E1/T1 sur ATM, et aussi VoIP. Le bit "Poll-me" présent dans le sous-en-tête de gestion de concession (avec UGS) indique à la BS s'il est à 1, que la SS a besoin d'être votée pour pouvoir demander une allocation de bande passante pour une autre connexion. Le drapeau SI (Slip Indicator) indicateur de dérive permet aux SS de signaler que la file d'attente de transmission souffre d'une accumulation du nombre de trames, ceci étant dû à certains facteurs tels que des concessions perdues ou le biais d'horloge entre le système de IEEE 802.16 et le réseau extérieur. La BS, après détection du drapeau indicateur de dérive, peut assigner une certaine capacité additionnelle à la SS, lui permettant de récupérer l'état normal de file d'attente. Les connexions configurées avec UGS ne sont pas allouées à utiliser des occasions d'accès aléatoire (random access opportunity) pour faire des requêtes. 2- Real-Time Polling Service (rtps) Service à vote temps reel: Le service temps-réel à vote, est conçu pour satisfaire les besoins des services qui sont dynamiques en nature, mais qui émettent des requêtes dédiées périodiques ( BW request) pour répondre aux exigences du temps-réel. La BS émet des scrutins périodiques unicast, et la SS émet des requêtes explicites, l'overhead et la latence du protocole sont augmentés, mais l'avantage est que la capacité est allouée selon le besoin réel de la connexion. Il faut noter que pour ses requêtes la SS ne peut pas employer les demandes de contention, mais peut utiliser le piggybacking (voir "demande et attribution de bande passante") Le service temps-réel à vote est bien approprié aux connexions portant des services tels que VoIP, MPEG ou streaming vidéo ou audio. 3- Non-Real-Time Polling Service (nrtps) Service: Le service à vote non-temps-réel est presque identique au service temps-réel à vote, sauf que les connexions peuvent utiliser les occasions de transmission à accès aléatoire (requêtes par contention) pour envoyer des demandes de bande passante. Elles peuvent 41

aussi utiliser le piggybacking. La BS émet régulièrement des scrutins unicast, pas nécessairement périodiques. Typiquement, les services portés par ces connexions ont des paquets de taille variable qui tolèrent des délais plus longs et sont insensibles à la gigue comme l'internet avec un taux garanti minimum et aux connexions ATM GFR (Guaranteed Frame Rate) 4- Service Best Effort Un service Best effort a été également défini, évidement sans aucune garantie sur le débit ou le délai. Le SS peut utiliser les demandes par contention, les requêtes dédiées et le piggybacking pour demander l'allocation de bande passante. L'occurrence des occasions dédiées est sujette de la charge du réseau, et les SS ne peuvent pas compter sur leur présence. 3.4.3- Mécanismes de QoS -Classification : Mapping des champs du MAC SDU (ex. @ IP destination, champ TOS) dans les CID (Connection ID) et SFID (Service Flow ID) -Ordonnancement : - Lien descendant : Simple, toutes les files d'attente dans la BS. - Lien montant : - Les files d'attente sont distribuées parmi les SS. -Les états des files d'attente et les demandes de QoS sont obtenus par des requêtes de BP. - Algorithmes non définis dans le standard 42

3.5- Couche PHY 802.16.1 - Utilisation de la bande 10-66 GHz - Bande de 25 et 28 MHz - Débit maximal de 134 Mbps - Vue directe : LOS. - Rayon de couverture maximal : 50 Km - Modulation par simple porteuse : WirelessMAN-SC - Architecture point à multipoints : une BS et plusieurs SS - Méthodes d accès et de duplexage multiples - Utilise TDM et TDMA - Supporte TDD (Time-Division Duplex) - Emission de bursts - Asymétrie dynamique entre émission et réception Figure 25- Trame TDD (10-66GHz) Durée de trame : 1ms ( options : 0.5, 1, 2 ms) PS (Physical Slot) = 4 symboles QAM 43

- Et FDD (Frequency-Division Duplex) - Bursts ou mode continu - Asymétrie dynamique entre émission et réception - Half ou full duplex Figure 26- Bursts dans FDD - Profil de burst : - Modulation : QPSK, QAM16, QAM64 - FEC : Reed Solomon (GF 256) - Profils de burst adaptatifs (identifiés par DIUC et UIUC) burst par burst, suivant les conditions de transmission, et pour réaliser une meilleure efficacité d échange entre capacité et robustesse en temps-réel. - Codage convolutif interne 44

3.6 - IEEE 802.16a 3.6.1 - Couche PHY 802.16a - Utilisation de la bande 2-11 GHz - Vue directe : NLOS. - Architecture point à multipoints et en maille - Efficacité spectrale importante jusqu à 5 bits/sec/hz Les trois spécifications de l interface radio sont - WirelessMAN-OFDM : - WirelessMAN-OFDMA : - FFT 256 points avec TDMA (TDD/FDD) - QAM 4, QAM 16, QAM 64 - FFT 2048 points avec OFDMA (TDD/FDD) - QAM 4, QAM 16, QAM 64 - WirelessMAN-SC2 : - TDMA (TDD/FDD) - BPSK, QPSK, QAM 4, QAM 16, QAM 64, QAM 256 3.6.2- Couche MAC dans 802.16a - Supporte OFDM/OFDMA - ARQ (Automatic Repeat Request) - DFS (Dynamic Frequency Selection) - Supporte des systèmes d antennes adaptatives - Topologie en maille 45

II- Simulation 1- Contexte et paramètres 1.1 Introduction Dans cette deuxième partie du projet nous allons essayer de réaliser une simulation sur Network Simulator NS2 pour étudier certaines performances de QoS dans 802.11. Comme le but de la simulation est d'étudier la transmission de flux Voix sur IP (VoIP) sur un réseau 802.11, Ad hoc multi bonds, en présence d'un flux ftp en background, on va commencer par la description rapide de VoIP, et de voir quelles sont les contraintes de QoS que doit vérifier un tel flux. De plus on va introduire certains détails techniques sur 802.11, et décrire les paramètres utilisés dans la simulation ainsi que son environnement. Ensuite seront décrits et commentés les résultats des simulations avant de conclure. 1.2 Voix sur IP Le but de la voix sur IP est la transmission de paquets de voix sur un réseau IP (IPv4 ou IPv6). Donc la voix va utiliser le même réseau que l'internet, mais avec des contraintes de QoS importantes que ne supporte pas normalement le réseau "best effort ". Pour cette raison il faut introduire trois contraintes de QoS que doit vérifier un flux VoIP, qui sont le délai de bout en bout, la gigue de délai, et le taux de perte de paquets. Il ne faut pas oublier de parler des différents codecs de la VoIP, car les caractéristiques des codeurs-décodeurs (codec) vont affecter aussi les performances de la transmission. VoIP est un flux de voix en temps-réel. Plusieurs codecs permettent la paquétisation de la voix avant sa transmission. Pour faire passer la voix dans un réseau IP, il faut tenir comptes de certains paramètres. On estime la bande passante de la voix à 4 khz (400-3400 Hz). Ce qui donne après numérisation une bande passante de 8 khz et après codage un débit de 64 kbps. Ceci entraîne que si on veut transmettre la voix sur un réseau IP sans mécanisme d optimisation de la taille il nous faudra une bande passante «continue» de 64 kbps rien que pour la partie données à transmettre. Mais, ceci est rarement le cas, car à l aide de mécanisme de codage optimisé grâce aux lois de compression de l information, on arrive à réduire ce débit nécessaire de plus de 8 fois pour les meilleurs algorithmes de codages. Un groupe de codecs selon les différents standards sont exposés dans le tableau cidessous. Il faut quand même noter que le délai décrit dans le tableau correspond à la méthode de compression et la paquetisation. Or pour pouvoir transmettre selon G 711 sur un réseau IP on doit émettre des paquets de 80 octets chaque 10ms, ce qui donne un débit global de 64Kbps, mais ajoute un délai de 10ms. Une modification de ce flux sera utilisée dans la simulation, elle sera détaillée ultérieurement. 46

Table 2 - Codecs VoIP Les critères de QoS nécessaires pour un flux voix sur IP sont d'après [12]: 1- Délai de bout en bout unidirectionnel : - Excellent si inférieur à 100-150 ms - Acceptable entre 150 ms et 250 ms 2- Gigue de délai - Excellente si inférieure à 40ms - Acceptable entre 40ms et 75ms 3- Taux de pertes de paquets - Excellent si inférieur à 5% 1.3 Environnement et contexte de la simulation 1.3.1 Modèle de simulation Le programme de simulation utilise Network Simulator dans sa version ns-2.26 [13] à laquelle j'ai ajouté l'extension réalisée par [14] pour pouvoir implémenter EDCF, avec la possibilité de lui ajouter CFB (Contention Free Burst) au besoin. Pour pouvoir bénéficier d'un débit de transmission plus important, j'ai choisi de travailler avec 802.11g, avec un débit de base "basic rate" égal à 6Mbps, correspondant à la transmission de l'entête du protocole de la couche de convergence physique PLCP (entre MAC et PHY), ainsi que les ACK, alors que le débit d'informations "data rate" correspondant à la transmission de la partie données (trame MAC) est égal à 54 Mbps. En fait l'entête PLCP est émis avec un débit plus faible pour mieux le protéger contre les erreurs. Toutefois, il faut noter que le OFDM n'est pas implémenté dans NS. 47

Figure 27 - Structure du paquet de la couche physique du 802.11g Les détails du paquet PPDU (PLCP PDU): Une unité de protocole de niveau physique. L entête PLCP est transmise à 6 Mb/s. Préambule: Synchronisation pour une transmission OFDM. Zone signal (24 bits): le débit de transmission utilisé pour la zone données et sa longueur (un symbole de 4 µs à 6 Mb/s). La zone service est de 2/3 de symbole soient 16 bits (inutilisée). La zone de données contient une trame de niveau MAC d une longueur maximale de 2346 octets. A la fin TAIL est une zone de silence de 6 microsecondes. Il faut préciser que les valeurs de DIFS, PIFS, SIFS et SlotTime sont: SlotTime 20µs SIFS 10µs PIFS 30µs DIFS 50µs Table 3 Paramètres de la simulation Comme on doit utiliser EDCF, avec ou sans CFB il faut spécifier les paramètres correspondant à chacune des priorités. Les valeurs utilisées dans la simulation sont d'après [15]: 0 1 2 3 AIFSN 2 2 3 7 CWmin 7 15 31 31 CWmax 15 31 1023 1023 TXOPlimit 3.008ms 6.016 ms 0 0 Table 4 - Paramètres des différentes priorités Il est évident que la priorité 0 est la plus importante, et 3 la plus faible. TXOPlimit est la durée maximale de transmission d'un burst, et donc va aussi affecter les performances de CFB. 48

1.3.2 Topologie du réseau et routage La topologie choisie est celle d'un réseau Ad hoc comprenant initialement cinq stations 802.11, un routeur et quatre stations. Le routeur (qui pourra éventuellement être connecté au réseau fixe option prévue dans le programme- par exemple un réseau UMTS), permet dans la simulation de connecter les deux stations 2 et 3 qui vont jouer le rôle de routeurs respectivement pour les deux stations 1 et 4. Comme le rayon de couverture d'une station 802.11 est de 250 m dans la simulation, la distance entre les stations 2 et 3 est de 300 m pour les obliger à passer par le routeur. Les distances 1-2 et 3-4 sont égales à 111.8 m alors que les distances 2-0 et 3-0 sont égales a 158.11 m. Les dimensions de la zone de simulation sont 670m x 670 m. Pour résoudre le problème de routage dans ce réseau, on avait prévu d'utiliser Cellular IP. J'avais commencé par faire l'étude théorique du protocole pour comprendre son fonctionnement. Mais malheureusement pour la simulation l'extension de ns qui comprend le Cellular IP n'est compatible qu'avec une ancienne version 2.1b7 de ns, et cette dernière ne comprend pas l'extension du 802.11e. En voulant regrouper l'ancienne version de ns avec les deux extensions avec tous les patches correctifs et un travail sur le code ainsi que linux qui m`ont coûté une perte de temps inimaginable (plus d'un mois de travail intensif) et qui s est soldée en fin de compte par un échec, car le shell de linux refusait la version modifiée. Ne pouvant pas recevoir une aide des informaticiens pour résoudre le problème malgré leur bonne volonté, j'ai opté, après l'accord de la responsable du projet à ne plus travailler avec Cellular IP Figure 28 - Topologie du réseau Ad Hoc 802.11g vu que l'établissement d'une version de ns opérationnelle contenant Cellular IP et 802.11e nécessitait un projet à elle seule, et que le temps manquait. Il faut bien préciser aussi que 49

Cellular IP est utile pour résoudre surtout les problèmes de micromobilité, et donc le handoff entre cellules adjacentes, chose qu'on n'a pas dans la simulation puisqu'on suppose les stations immobiles. Après le conte de mes mésaventures, je reviens au protocole de routage. Parmi les protocoles Ad Hoc possibles et présents dans NS j'ai choisi le protocole "Ad hoc On demand Distant Vector" AODV qui fonctionne de la manière suivante: Quand un noeud veut connaître une route vers une certaine destination il génère un message "Route Request". Ce message de demande de route est expédié de proche en proche par les noeuds intermédiaires va créer pour lui-même une route inverse de la destination. Quand la requête atteint un noeud possédant une route vers la destination il génère un message de réponse "Route Reply" contenant le nombre de bonds requis pour atteindre la destination. Tous les nœuds ayant participé à expédier cette réponse vers le nœud source vont créer une route vers la destination. Cet état créé de chaque nœud, de la source à la destination, est un état bond par bond et non pas une route complète comme ceci est réalisé dans le routage par la source. 1.3.3 Scenarii et paramètres de simulation Avant de commencer les simulations sur les flux VoIP, j'ai voulu connaître les débits maximaux qui peuvent transiter à travers le réseau multi-bonds, surtout qu'une étude avec simulation a été réalisée [16] sur un réseau comprenant au maximum trois bonds et qui a montré une forte dégradation du débit pour un flux TCP. Les simulations ont été réalisées avec un flux CBR qui transmet des paquets de 2000 octets chaque 1ms. Ensuite plusieurs scenarii ont été choisis pour étudier les performances des flux VoIP dans le réseau Ad Hoc précédent. Tous les scenarii comprennent une transmission bidirectionnelle entre 1 et 4 de flux VoIP, et un flux unidirectionnel FTP sur TCP de 2 vers 3, avec une taille de paquet de 1000 octets et une fenêtre d'émission de 10 paquets pour TCP. Tous les flux VoIP utilise la plus haute priorité (0) alors que FTP en background utilise la plus faible (3) lorsque EDCF ou EDCF+CFB sont implémentés. Par contre lorsqu'on implémente DCF on n'a plus de priorité. Les différents scenarii de simulation sont 1- EDCF: VoIP bidirectionnel +FTP 2- EDCF +CFB : VoIP bidirectionnel +FTP 3- DCF : VoIP bidirectionnel +FTP 4- EDCF : flux bidirectionnels VoIP entre un nombre variable de stations voisines de 1 avec le même nombre de stations voisines de 4, + FTP, pour déterminer le nombre maximal de stations qui vérifient les critères de QoS. 5- EDCF + CFB : flux bidirectionnels VoIP entre un nombre variable de stations voisines de 1 avec le même nombre de stations voisines de 4 + FTP, pour déterminer le nombre maximal de stations qui vérifient les critères de QoS. 50

2 - Résultats des simulations et commentaires 2.1 - Débits maximaux Pour déterminer les débits maximaux en fonction du nombre de bonds, j'ai commencé par un flux CBR avec des débits croissants, et j'ai constaté que le débit maximal que je pouvais avoir à la station 2 provenant de la station 1, donc pour un bond ne pouvait dépasser un certain seuil quelque soit l'augmentation du débit ou la répartition de la taille des paquets ou leur fréquence. Pour cela j'ai choisi en fin de compte un flux CBR avec une taille de paquet égale à 2000 octets, et une durée entre deux paquets de 1ms, ce qui donnait un flux initial à l'émission de 16Mbps supérieur au seuil déjà évoqué. Les résultats obtenus pour différentes conditions et priorité sont regroupés dans le tableau comparatif suivant Nb. de bonds DCF Priorités EDCF EDCF + CFB _ 0 1 2 3 0 1 1 8.9 11.86 10.65 8.6 7.95 13.59 13.65 2 4.26 5.05 4.8 4.28 3.94 6.5 6.7 3 3 3.42 3.3 2.96 2.72 4.3 4.45 4 2.3 2.63 2.5 2.27 2.08 3.3 3.35 Table 5 - Débits maximaux en Mbps, du 802.11g, en fonction du nombre de bonds D'après les résultats ci-dessus on constate que le CFB avec la priorité 1 fournit le débit maximal, car pour cette priorité (bien que inférieure à la priorité 0) la durée de transmission d'un burst TXOP limit est la plus grande et est égale à 6ms (3ms pour la priorité 0). CFB permet d'avoir le débit le plus important car on peut envoyer plusieurs paquets pendant la durée du TXOP sans le besoin de contention pour chaque paquet. Ensuite on constate que le débit diminue avec la priorité pour EDCF ce qui est normal, et que la priorité 2 de EDCF est presque égale à DCF ce qui est évident car elles ont les mêmes paramètres temporels. Mais ce qui est le plus important c'est le débit maximal sur un bond qui est de 13.65 Mbps et qui est bien loin du 54 Mbps, débit de transmission des données sur le canal physique. Ceci est du à plusieurs causes, entre autre le débit de 6 Mbps pour les bits de contrôle, l'overhead des différents protocoles (IP, UDP,RTP,TCP,MAC,PHY,.) dans la simulation on a utilisé CBR/UDP qui ajoute avec les autres protocoles 72 octets à chaque paquet transmis- mais surtout à la méthode de contention avec tout le bagage de durées de silence (DIFS, PIFS, SIFS,AIFS,backoff) qui réduisent d'une manière importante le débit, ainsi que les pertes de paquets et les collisions qui nécessitent une retransmission du paquet. Le temps de propagation est très faible ( 1µs) et ne va pas pratiquement affecter. La durée d'émission du paquet est proportionnelle à sa longueur ce qui va augmenter le débit avec la longueur du paquet, mais sans dépasser le seuil maximal. Pour le calcul théorique du débit maximal voir [17] Un autre facteur est la dégradation importante du débit avec le nombre de bonds traversés, car à chaque bond pour le même paquet on a une nouvelle contention avec un nouveau retard, ceci 51

sans parler des pertes. En comparant les débits maximaux obtenus on constate en moyenne une chute à 47 %, 32 % et 24% respectivement pour deux, trois et quatre bonds, par comparaison au débit obtenu sur un seul bond, et des chutes moyennes à 20%, 9.5 %, 6.5% et 5% pour un, deux trois et quatre bonds par rapport à 54Mbps. En conclusion avec la topologie du réseau utilisé on doit se contenter d'un débit pour une station allant de 2.1 jusqu'à 3.35 Mbps avec un flux unidirectionnel traversant quatre bonds, ceci avec un taux de rejet de paquets important. 14 Débit maximal 802.11g en fonction du nb. de bonds 12 Débit (Mb/s) 10 8 6 DCF EDCF priorité 0 EDCF priorité 1 "EDCF priorité 2" "EDCF priorité 3" "EDCF priorité 0 + CFB" "EDCF priorité 1 + CFB 4 2 1 2 3 4 Nombre de bonds Figure 29 - Débits maximaux en Mbps, du 802.11g, en fonction du nombre de bonds 2.2 Modèle de flux VoIP Après avoir déterminer les limitations du réseau en débit, je suis passer à la simulation suivant les différents scenarii dont on a parlé précédemment. Dans tous les scenarii le flux VoIP que j'ai utilisé est tiré de la simulation de [18].Le modèle choisi pour ce flux est un modèle ON-OFF avec une durée ON de 400ms et une durée OFF de 600ms.La taille des paquets émis chaque 20ms est de 160 octets pour fournir un débit durant ON de 64 Kbps. 52

Par curiosité j'ai voulu savoir pourquoi ils ont choisi un intervalle de 20ms au lieu de 10ms et une taille de paquet de 160 octets au lieu de 80octets pour avoir le même débit. La réponse est venue lorsque j'ai réalisé les simulations avec un nombre croissant de stations. Comme on va le voir en détail par la suite, avec le choix du flux (160 20), on a pu atteindre cinq stations supplémentaires de chaque côté alors que avec le flux (80 10), on ne pouvait dépasser deux stations. Donc le choix d'un tel modèle est judicieux, bien qu'il introduise un délai de paquetisation de 20ms au lieu de 10ms. D'ailleurs ce choix est un compromis entre d'un côté la taille du paquet qu'on a intérêt à augmenter pour réduire les contentions et donc augmenter le débit, et de l'autre le problème de perte de paquets et la durée de paquetisation. 2.3 - Scenarii à deux stations émettrices Dans les trois premiers scenarii, la simulation comprenait la transmission d'un flux VoIP bidirectionnel entre les stations 1 et 4 et un flux FTP/TCP entre 2 et 3, en utilisant respectivement EDCF, EDCF+CFB et DCF. Les résultats des différents critères de QoS à savoir le délai, la gigue, et la perte de paquets sont exposés puis commentés ci-dessous: 2.3.1 Délai Les délais obtenus à partir des simulations sont: Délai entre les nœuds 1 et 4 (RX=4) Délai entre les nœuds 4 et 1 (RX=1) EDCF CFB DCF EDCF CFB DCF min 15.1 10.1 16.78 1.88 1.88 2.08 moyenne 30.5 43.8 43.2 25.22 25 32.6 max 68.5 144.9 117.6 57.5 87.3 93.6 Table 6 - Valeurs des délais (en ms) entre 1 et 4 pour un flux VoIP bidirectionnel D'après les valeurs des délais obtenues en 1 ou 4, on constate que le critère de QoS est vérifié dans tous les cas, car toutes les valeurs sont inférieures à 150ms. Si on ajoute la durée de paquetisation de 20ms seule la simulation avec CFB au nœud 4 va légèrement dépasser ce seuil mais reste tout de même très acceptable ( 250 ms). La deuxième constatation est que les performances de la réception en 1 sont meilleures que celle de 4. Ceci est évident car dans le sens 1-4 on a en plus le flux FTP alors que dans le sens inverse la voie est mieux dégagée. La troisième constatation est que les meilleures performances sont obtenues avec EDCF, ce qui est normal. Par contre on aurait pu supposer que en ajoutant CFB à EDCF on devrait avoir de meilleurs résultats, ce qui n'est pas le cas d'après les valeurs obtenues, surtout dans le sens 1-4 donc celui aussi du flux FTP. CFB en émettant les paquets par salve lorsque ceci est possible, va être plus perturbé par le flux FTP. Par contre dans le sens 4-1 on constate qu'on a presque les mêmes performances que pour EDCF (valeurs minimale et moyenne) 53

Avec DCF, le flux VoIP n'étant pas prioritaire sur FTP va subir donc des délais supérieurs, surtout dans le sens 1-4. 2.3.2 Gigue La mesure de la gigue du délai a été faite durant les durées ON de réception pour avoir des valeurs significatives. La meilleure chose à faire, en principe, était de réaliser plusieurs simulations pour chaque scénario et de prendre l'ensemble de ces valeurs pour une plus grande précision. Malheureusement cette méthode nécessite beaucoup de temps pour réaliser les simulations puis passer à l'interprétation des traces. Or justement ce qui me manquait le plus c'était le temps, avec tous les problèmes que j'ai rencontré. Pour cette raison j'ai décidé d'utiliser un petit truc qui consistait à supposer que la valeurs maximale d'une grandeur statistique pourrait être localisée entre la valeur moyenne plus deux fois l'écart type σ et la valeur moyenne plus trois fois σ (pour un signal gaussien on a 97.5 % et 99.9% des valeurs inférieures respectivement à moyenne + 2σ et moyenne + 3σ). En comparant les valeurs de moyenne+3σ aux valeurs maximales obtenues on constate la plupart du temps des valeurs très proches. Gigue des paquets reçus au noeud 4 Gigue des paquets reçus au noeud 1 EDCF CFB DCF EDCF CFB DCF min 0.24 14.8 2.9 0.5 1.76 0.42 moyenne 7.55 19.28 11 6.54 15.24 8.56 max 23.07 75.7 19.5 21.18 40.65 29.9 écart-type σ 5.78 16.7 6.65 4.81 10.03 6.84 moy +2σ 19.11 52.68 24.3 16.16 35.3 22.24 moy +3σ 24.89 69.38 30.95 20.97 45.33 29.08 Table 7 - Valeurs de la gigue (en ms) aux noeuds 1 et 4, pour un flux VoIP bidirectionnel Ce qui saute aux yeux tout de suite sont les valeurs de gigue importantes avec CFB, ceci est du au fait que CFB n'est pas régulier dans sa transmission: il envoie ses paquets par salves, et ces derniers peuvent subir des délais différents. Pour cette raison on constate que EDCF a comme prévu les meilleures performances, puis c'est le tour de DCF et à la fin du classement arrive CFB. En conclusion de cette partie ce qui nous importe le plus est que EDCF et DCF vérifient la contrainte de QoS pour avoir une excellente qualité ( 40ms) alors que CFB est très proche de cette qualité au nœud 1, mais doit se contenter d'une qualité acceptable au nœud 4 (40ms <gigue 75ms) 2.3.3 Perte de paquets La perte de paquets peut prendre plusieurs formes. Un paquet qui est émis et n'est pas reçu est perdu. De même, surtout pour un flux temps-réel, les paquets qui n'arrivent pas en séquence sont aussi supposés perdus. Par contre des paquets qui sont rejetés pendant la transmission au niveau des files des différents nœuds vont être signalés implicitement à la source dans 802.11 par l'absence de l'acquittement, et vont donc être réémis, si possible, après l'expiration d'un timeout. 54

On va se baser sur le taux de paquets perdus plutôt que le taux des paquets rejetés. D'ailleurs l'impact de ces derniers sera ressenti au niveau du délai et de la gigue, et sera donc pris en compte d'une manière indirecte. Pour le premier scenario avec EDCF, le taux de pertes de paquets est nul pour les deux stations 1 et 4, alors que le taux de rejet à la station réceptrice est au maximum de 7.6 % (21/275).Avec EDCF+CFB, le taux de pertes de paquets est au maximum égal a 1.04 % (1/96), alors que le taux de rejet à la station réceptrice est au maximum de 3.1% (3/96). Et enfin avec DCF, le taux de pertes de paquets est nul, alors que le taux de rejet à la station réceptrice est égal à 0.8% (2/239). De ce qui précède on peut conclure que les qualités de QoS sont vérifiées (pertes de paquets 5 %) et que l'introduction de CFB a l'avantage de réduire le rejet des paquets, propriété qui sera confirmée par les simulations suivantes. 2.4 - Scenarii à plusieurs stations émettrices Le but dans cette partie des simulations était de voir combien de stations supplémentaires on pourrait ajouter de chaque côté, ç.à.d. voisines respectives des stations 1 et 4, les distances les séparant respectivement des stations 2 et 3 étant presque les mêmes que celles séparant respectivement 1 et 4 des stations 2 et 3. Ces stations qui émettent des flux VoIP bidirectionnels par groupes de deux, comme 1 et 4, sont sensés vérifier toujours les critères de QoS déjà cités. Pour connaître ce nombre je ne pouvais pas pour chaque valeur démarrer la simulation puis interpréter la trace obtenue. J'ai plutôt introduit dans mon programme une fonction appelée résultats qui me permettait de connaître directement le taux de pertes de paquets. Une fois le seuil atteint, la simulation était arrêtée, le nombre de stations connu, et c'est à ce stade là que commençait l'interprétation de la trace pour voir si les contraintes temporelles sont vérifiées ou pas. D'après les résultats des simulations, le nombre de stations supplémentaires qu'on a pu ajouter de chaque côté était égal à cinq pour EDCF, ainsi que pour EDCF+CFB. La différence entre les deux cas est que au sixième groupe ajouté, une station du scénario EDCF était totalement bloquée et donc ne pouvait plus émettre alors que avec CFB le taux de pertes montait en flèche pour atteindre une valeur maximale de 57%. Avec le scénario de DCF on ne pouvait ajouter aucune station supplémentaire. Donc avec EDCF et CFB on avait 2x6 donc douze stations émettrices qui étaient connectées par 3 autres (stations 2, 3 et le routeur 0), ce qui faisait un total de 15 stations. Les résultats des simulations vont être présentées et commentées avant de conclure. 2.4.1 Délai Avant la détermination du delai global dans les deux scenarii EDCF et CFB, je préfére voir rapidement le delai sur le trajet 1-4 dans les deux directions pour voir ce qui a changé lorsque le nombre de stations a augmenté. Pour cela j'ai regroupé les résultats correspondants tirés uniquement de la simulation EDCF. 55

Délai entre les nœuds 1 et 4 (RX=4) EDCF Délai entre les nœuds 4 et 1 (RX=1) EDCF min 12.88 2.17 moyenne 79.37 49.5 max 217.98 157.8 écart-type σ 46.9 60.42 moy +2σ 173.17 170.34 moy +3σ 220.07 230.76 Table 8 - Valeurs des délais (en ms) entre 1 et 4 pour des flux VoIP bidirectionnels multiples A partir de ses valeurs on constate qu'il y'a eu une dégradation des performances plus aigue pour le chemin 1-4. En outre on constate que en ajoutant 20ms comme délai de paquetisation on se retrouve à la limite de l'acceptable comme qualité de communication.( 250 ms). Or avec le groupe 1-4 on a presque le pire des scenarii, et ce qui caractérise d'une meilleure façon le délai dans ce réseau est le délai global qui tient compte de tous les paquets de toutes les stations. Les valeurs du délai global, pour EDCF et CFB, sont regroupées dans le tableau suivant EDCF EDCF+CFB min 1.82 1.86 moyenne 55.5 46.7 max 218.43 199.6 écart-type σ 38.36 33.03 moy +2σ 132.22 112.76 moy +3σ 170.58 145.79 Table 9- Délai global (en ms) pour des flux VoIP bidirectionnels multiples Le délai global étant plus significatif que les délais sur chaque chemin, on peut constater que l'importance de CFB est apparue lorsque le nombre de stations a augmenté et que le réseau est devenu plus chargé. On voit clairement d'après les résultats précédents que la dégradation des performances est plus faible avec CFB qu'elle ne l'est avec EDCF seul. CFB améliore les performances sur le délai de l'ordre de 15%, d'où l'importance de l'utilisation de CFB dans les réseaux chargés, car il permet de mieux bénéficier de la bande passante disponible. 2.4.2 Gigue Il aurait été intéressant de travailler sur la gigue globale. Mais comme la gigue n'a de signification que pendant la durée ON et que ces durées sont variables d'un flux à un autre, on est contraint de travailler sur la gigue du chemin 1-4. 56

Gigue des paquets reçus au noeud 4 Gigue des paquets reçus au noeud 1 EDCF EDCF+CFB EDCF EDCF+CFB min 0.37 2.82 0.47 0.52 moyenne 13.53 17.7 9.35 15.28 max 42.1 35.77 52.76 52.47 écart-type σ 9.33 7.19 9.24 12.33 moy +2σ 32.19 32.08 27.83 39.94 moy +3σ 41.52 39.27 37.07 52.27 Table 10 -Valeurs de la gigue (en ms) aux noeuds 1 et 4, pour des flux VoIP bidirectionnels multiples. Avec la gigue, le problème de CFB demeure mais sous forme plus atténuée. Alors que pour les paquets reçus au nœud 4 on a presque les mêmes performances, et une qualité à la limite excellente, lorsque le chemin devient chargé dans le même sens par le flux FTP (sens 1-4) une dégradation plus nette est décelable, de l'ordre de 40%, ramenant ce flux à être de qualité plutôt acceptable du point de vue gigue de délai. 2.4.3 Perte de paquets Comme le critère de choix pour connaître le nombre de stations supplémentaires est pris dans la simulation, comme étant la vérification de la contrainte sur le taux de paquets perdus, donc toutes les stations dans les deux scenarii vont avoir un taux de pertes inférieur à 5%. Voici les détails: Paquets Paquets Paquets Paquets Taux de Reçus rejetés émis perdus pertes % 1 145 3 146 3 2.05 4 107 4 107 1 0.93 5 158 3 254 0 0 10 254 2 158 2 1.26 6 166 2 167 1 0.6 11 125 5 127 4 3.15 7 195 2 197 2 1.01 12 228 10 227 0 0 8 184 2 185 1 0.54 13 174 4 174 0 0 9 149 10 150 1 0.67 14 247 13 246 0 0 Total 2132 60 2138 12 0.561272 Table 11 - Taux de pertes de paquets, EDCF, flux multiples. 57

Paquets Paquets Paquets Paquets Taux de Reçus rejetés émis perdus pertes 1 161 0 163 2 1.23 4 137 0 137 0 0 5 188 0 188 0 0 10 94 0 98 4 4.08 6 91 0 91 0 0 11 124 5 126 2 1.58 7 297 0 297 0 0 12 187 3 187 0 0 8 203 1 204 1 0.49 13 285 1 285 0 0 9 133 0 134 2 1.49 14 137 1 136 0 0 Total 2037 11 2046 11 0.537634 Table 12 - Taux de pertes de paquets, EDCF+ CFB, flux multiples. En laissant de côté le 5% qui est vérifié, ce qui saute aux yeux c'est le nombre de paquets rejetés qui chute énormément avec CFB. En faisant le calcul on constate qu'on passe d'un taux de rejet de paquets de 2.8 % à 0.53% donc on passe à 19% des paquets rejetés sans CFB. Ceci est important pour utiliser les ressources disponibles de façon plus efficace. Par contre on ne constate aucune amélioration quant au taux de pertes de paquets qui reste pratiquement le même 3 Conclusion En se basant sur les résultats des différentes simulations, on peut déduire que le modèle de priorité introduit par EDCF, apporte une meilleure qualité à la transmission avec un nombre de stations plus important qu'avec DCF, où aucune différentiation de flux n'existe. Le problème majeur avec EDCF est l'impact négatif sur le débit de toutes les contraintes temporelles dues à la méthode de contention, comme les durées d'attente (DIFS, SIFS, PIFS, AIFS, backoff). Mais ces durées sont nécessaires pour le bon fonctionnement du système. Avec HCF qui utilise le principe de Polling la gestion de la bande est plus efficace, mais n' oublions pas que HCF est utilisé dans les réseaux à infrastructure avec une station de base qui va gérer la répartition et l'allocation de bande à chaque station. Comme la topologie de notre réseau est celle d'un réseau Ad Hoc on ne pouvait choisir que EDCF. Avec un nombre important de bonds égal à quatre, pouvoir écouler six flux bidirectionnels de VoIP en présence d'un flux FTP en background, avec une QoS, dans le pire des cas acceptable, me semble une bonne performance, bien que j'aurais aimé ajouter d'autre flux, vidéo par exemple, mais malheureusement le temps manquait à l'appel. L'importance de CFB est apparue clairement quand le nombre de flux a augmenté pour passer de deux à douze. Comme CFB permettait la transmission de petits paquets pendant la durée de burst qui peut atteindre au maximum TXOPlimit, ce qui réduisait l'overhead du à la 58

contention. Ceci a permis de réduire énormément (80%) le nombre de paquets rejetés, en libérant les files d'attente à chaque contention de plusieurs paquets au lieu d'un seul. Comme le nombre de paquets rejetés était réduit, le nombre de retransmission l'était aussi, ce qui a affecté positivement le délai global en le diminuant aussi (15%). Même avec la gigue qui était un peu plus importante que pour EDCF, CFB a permis d'améliorer à un certain degré les performances de la transmission. Enfin même s'il fallait ajouter la compensation de la gigue au délai global, CFB conservait une certaine avance (170.58+20+41,52=232.1 ms avec EDCF et 145.79+20+52.27=218.06 ms pour CFB).A mon avis CFB serait plus performant pour les flux n'ayant pas de contrainte de gigue importante. Il est aussi intéressant de préciser que le débit de TCP reçu à la station 3 est en moyenne de 2.23 Mbit/s (max 3.3 Mbits/s) pour EDCF +CFB alors qu'il n'est que de 1.37 Mb/s en moyenne (max 2.96 Mb/s) pour EDCF seul.ces résultats ajoute des crédits à CFB puisqu'il permet d'avoir de bonnes performances en perturbant le moins possible le flux FTP/TCP en background. Pour conclure, il faut quand même noter que tout le travail réalisé concernait les trois critères de QoS, à savoir le délai de bout en bout, la gigue et la perte de paquets. Mais ceux-ci ne sont pas les critères suffisants pour une qualité excellente de voix, car reste encore la QoS subjective ayant des critères spécifiques, qui sortent du cadre de notre étude. 59

Annexe 1- Interopérabilité avec UMTS Le UMTS a quatre classes de QoS Conversationnelle : Temps-réel, faibles délai et gigue. Ex: VoIP, Video conferencing Streaming : Temps-réel, tolérante a la gigue. ex. : Video-on-demand Interactive : Requête- réponse, Intégralité du contenu des paquets. ex. : www, serveur d accès Background : conserve le contenu (pas d erreur).ex. E-mails, MMS/SMS Ces quatre classes peuvent être mappés sur celles du 802.16, de même on peut utiliser la QoS de 802.11e.Pour réaliser l interopérabilité entre WLAN ou WMAN on peut le faire de plusieurs manières avec pour chaque méthode ses avantages et ses inconvénients : 1.1- Connexion au SGSN : -Av. : Dans ce cas WLAN devint un réseau d accès pour le CN du UMTS, le Handover est le plus rapide des 3 méthodes puisque le contexte de mobilité se trouve dans le SGSN. - Inc. : Solution la moins flexible car s applique uniquement à UMTS et pas à d autres réseaux. En outre tous le trafic vers l Internet doit nécessairement passer par le CN du UMTS ce qui causerait une charge supplémentaire inutile. Figure 30 - Approche de la connexion au SGSN 60

1.2- Connexion au GGSN : -Av. : Solution beaucoup plus flexible car dans ce cas on a accès a un routeur du réseau Internet et on travaille en IP. - Inc. : Le Handover est un peu moins rapide que dans le premier cas Figure 31 - Approche de la connexionau GGSN 1.3- Approche Mobile IP : -Av. : Solution la plus flexible car elle peut être appliquée à n importe quel réseau (4G). - Inc. : Le Handover est lent dû à l utilisation de MIP. Ces performances peuvent être améliorées en utilisant par exemple le FCAR (amélioration du DMIP)[19] 61

Figure 32 - Approche Mobile IP Pour réaliser un compromis, la solution la plus adaptée est, à mon avis, celle du GGSN. Pour les WLAN on peut le faire en passant par des routeurs, et pour le 802.16 on peut le faire directement. D ailleurs des hotspots utilisant le 802.11 peuvent être les SS du 802.16. 62

Bibliographies [1] J.-B. Lapeyrie, T. Turletti " Adding QoS Support for Bluetooth Piconet". INRIA Sophia Antipolis. Thème 1 Réseaux et systèmes, Projet Planete. Rapport de recherche n 4514 Juillet 2002 [2] A. Mercier, P. Minet, L. George " Introducing QoS support in Bluetooth Piconet with a Class-Based EDF Scheduling". INRIA. Thème 1. Rapport de recherche n 5054 Décembre 2003 [3] J. Lee "Overview of WLAN, WPAN,and WMAN technologies".présentation pour EE647, Avril 2004 [4] J.P.K. Gilb "Overview of Draft Standard 802.15.3" doc: IEEE 802.15-01/508rl Novembre 2001 [5] J. Gutierez "IEEE 802.15.4 Tutorial" doc. IEEE 802.15-03/036r0 Janvier 2003 [6] S. Mangold, S. Choi, G.R. Hiertz, O. Klein, B. Walke " Analysis of IEEE 802.11e for QoS Support in Wireless LANs". IEEE Wireless Communications, December 2003 [7] IEEE 802.11 WG: IEEE 802.11e/D4.1, Wireless MAC and physical layer specifications: MAC enhancements for QoS. (2002). [8] J. Tourrilhes. Packet Frame Grouping: Improving IP Multimedia Performance over CSMA/CA. Hewlett Packard Laboratories, Bristol, UK, 1997. [9] IEEE 802.11 WG. Draft Supplement to IEEE Standard 802.11-1999: Medium Access Control (MAC) Enhancements for Quality of Service (QoS). IEEE 802.11e/D5.0, 2003. [10] INTEL Corporation " IEEE 802.16 and WiMAX, Broadband Wireless Access for Everyone" White paper, Broadband Wireless Access, 2003 [11] C. Eklund, R. B. Marks, K.L. Stanwood, S. Wang " A Technical Overview of the WirelessMAN Air Interface for Broadband Wireless Access". IEEE Communications Magazine, June 2002. [12] T. Chen "QoS Support in Packet Networks", Université de Trente,Italie. Mai 2004 [13] The Network Simulator ns-2. http://www.isi.edu/nsnam/ns. [14] Simulation Model of IEEE 802.11e EDCF and CFB for ns-2.26. http://www.tkn.tuberlin.de/research/802.11e ns2. [15] IEEE 802.11 WG. Draft Supplement to IEEE Standard 802.11-1999: Medium Access Control (MAC) Enhancements for Quality of Service (QoS). IEEE 802.11e/D5.0, 2003. 63

[16] P. Mähönen, J. Riihijärvi, M. Petrova, Z. Shelby, " Hop-by-Hop Toward Future Mobile Broadband IP" IEEE Communications Magazine. Mars 2004. [17] Y. Xiao and J. Rosdahl, Throughput and Delay Limits of IEEE 802.11, IEEE, Communication Letters, vol. 6, no. 8, Aout. 2002, pp. 355 57. [18] Ansel P., Ni Q., and Turletti T.:" FHCF: A fair scheduling scheme for 802.11e WLAN", INRIA Research Report No 4883, Juillet 2003. Implementation et simulations disponibles à \http://www-sop.inria.fr/planete/qni/fhcf/". [19] S.-C. Lo, G. Lee, W.-T. Chen, J.-C. Liu "Architecture for Mobility and QoS Support in All- IP Wireless Networks".IEEE journal on selected areas in communications, Vol. 22, No 4, Mai 2004 64