Memoire Online - Amélioration de la qualité de transmission vidéo dans les réseaux IEEE 802.11

Amélioration de la qualité de transmission vidéo dans les réseaux
sans fil IEEE 802.11

Adresse: 2004 route des lucioles BP 93 06902 Sophia Antipolis France Tél: (+33)492387777 Fax: (+33)492387765

Résumé

Le présent rapport a été élaboré dans le cadre du projet de fin d'études pour l'obtention du diplôme de mastère de recherche en informatique. Dans ce rapport, nous présentons une nouvelle solution permettant d'adapter le débit de transmission vidéo dans un réseau IP hybride (filaire/sans fils). Nous présentons un mécanisme leaderbased pour améliorer la transmission multipoint dans le réseau IEEE 802.11. Dans notre solution, nous proposons d'ajouter un nouvel agent placé entre le réseau filaire et le réseau sans fil permettant de distinguer entre les pertes de congestion de celles de transmission dans le réseau IEEE 802.11. L'agent permet d'estimer aussi le temps d'aller-retour RTT en se basant sur les rapports RTCP échangés entre la source vidéo et les stations mobiles. Ensuite, la source vidéo adapte leur débit d'émission en se basant sur un mécanisme de contrôle de congestion TCP-Friendly. A la fin de ce rapport, nous évaluons notre solution à l'aide du simulateur OMNET++.

Mots clés Réseaux locaux sans fil IEEE 802.11, Practical Leader Based, TCP-Friendly, Le contrôle de congestion multipoint.

Abstract

In this report, we describe an adaptive multicast transmission scheme for multimedia streaming over hybrid IEEE 802.11 multi Access Point and wired IP networks corresponding to a museum scenario. To enhance the standard IEEE 802.11 open-loop multicast transmission protocol, we propose a leader-based mechanism operating on each access point. Our solution uses an agent placed in the vicinity of wireless access points to discriminate between congestion and transmission errors. The agent also helps in estimating RTT and generates incoming RTCP receiver reports to the distant video source. The video source then adapts its transmission rate using a TCP-friendly congestion control algorithm. We evaluate the overall transmission mechanism using a modified version of the OMNET++ network simulator.

Mots clés : Hybrid wired/wireless network, IEEE 802.11, Leader-Based mechanism, Multicast congestion control.

Je dédie ce travail
À ma mère
À mon père
À mes frères
À ma soeur
À toute ma famille
À mes chers amis.

REMERCIEMENTS

Ces travaux de mémoire de mastère se sont déroulés au sein du projet Planète à l'INRIA Sophia Antipolis.

Je remercie Monsieur Walid Dabbous le chef du projet, de m'y avoir accueilli et donné les moyens de mener à bien mes travaux. Je remercie vivement mon encadrant Monsieur Thierry Turletti pour sa disponibilité et ses précieux conseils qui m'a permis d'enrichir mon travail, je le remercie également pour son soutien tout au long du déroulement de mon projet.

Je suis reconnaissant à Monsieur Abdelfettah Belghith Professeur à l'école nationale des sciences de l'informatique d'avoir accepté d'être superviseur de mon travail.

Je tiens aussi à adresser ma gratitude à toutes les personnes qui m'ont aidé pendant la préparation de ce travail, je pense ici à Monsieur Diego Dujovne doctorant à l'équipe Planète.

Je tiens à remercier profondément l'ensemble des doctorants et des stagiaires de l'équipe Amir Krifa, Mohamed Jaber, Mohamed Karim Sbai, Naveed Ben Rais avec lesquels j'ai eu des échanges scientifiques et culturels pendant toute la durée du projet.

Je ne saurais terminer ces remerciements sans penser aux membres du jury pour l'honneur qu'ils m'ont fait d'avoir voulu examiner et évaluer cette modeste contribution et à toute personne qui a contribué, directement ou indirectement, à l'achèvement de ce travail.

		Table des matières
		1.2.3 La couche MAC 802.11 1.2.3.1 Les modes opératoires de IEEE 802.11 1.2.3.1.1 Le mode infrastructure 1.2.3.1.2 Le mode ad hoc 1.2.3.2 Les algorithmes d'adaptation du débit physique . . .	9 11 12 12 12
		1.2.3.2.1 Le protocole ARF	12
		1.2.3.2.2 Le protocole RBAR	13
		1.2.3.2.3 Le protocole AARF	13
	1.3	Simulation et évaluation	14
		1.3.1 Comparaison entre les différents modèles de propagation physique 14
		1.3.2 Comparaison entre les deux algorithmes d'adaptation du débit
		physique ARF et AARF	16
	1.4	Conclusion	18
2	La transmission multipoint dans les réseaux IEEE 802.11		19
	2.1	Introduction	19
	2.2	La transmission multipoint sur les réseaux IEEE 802.11	20
	2.3	Les solutions existantes	20
	2.4	Practical Leader-Based	22
	2.5	Evaluation de performances	23
		2.5.1 Scénario statique	24
		2.5.2 Scénario dynamique	24
	2.6	Conclusion	25
3	Le contrôle de congestion dans un réseau IP hybride filaire/sans fil		27
	3.1	Introduction	27
	3.2	Le besoin du mécanisme de contrôle de congestion	28
			ii

1.1	Le fonctionnement de CSMA/CA avec RTS/CTS [6]	9
1.2	Scénario d'un réseau IEEE 802.11 en mode infrastructure	14
1.3	PER en fonction de la distance	16
1.4	Influence du fading sur la perte des paquets	17
1.5	Comparaison entre les deux approches ARF et AARF dans un scénario
	statique	17
1.6	Comparaison entre les deux approches ARF et AARF dans un scénario
	mobile	18
2.1	Scénario de transmission de la vidéo dans un réseau IEEE 802.11 . . . .	23
2.2	Scénario dynamique	25
2.3	Comparaison entre la transmission standard et PLB	26
3.1	Un environnement hybride filaire/sans fil	36
3.2	Messages RTCP échangées entre le réseau filaire/sans fil	38
3.3	Le taux de pertes pour LDA+/PLB et CBR/Legacy dans un réseau conges-
	tionné	40

1.1	Les valeurs typiques de Path loss Exponent et Shadowing Variance . . .	7
1.2	Caractéristiques des différentes couches physiques IEEE 802.11	10
1.3	Paramètres de configuration	14
1.4	Les paramètres du modèle Two-Ray	15
1.5	Les paramètres du modèles Shadowing	15
1.6	Les paramètres de configuration du fading	15
2.1	Le taux de perte des paquets	24
3.1	Les paramètres du modèles Shadowing	40

Introduction

Aujourd'hui, nous assistons à une évolution de l'Internet en nombre d'utilisateurs. Parmi les facteurs de cette évolution se trouve le succès des réseaux sans fil 802.11. Les réseaux IEEE 802.11 deviennent de plus en plus populaires car ils permettent aux utilisateurs de se connecter à l'Internet à un prix abordable avec une bande passante relativement importante et aussi la possibilité de se déplacer sans être déconnecté. De plus, de nos jours les cartes réseau sans fil IEEE 802.11 sont déployées dans la majorité des technologies comme les PDAs et les laptops.

En parallèle, les techniques de communication multimédia ont aussi évolué avec les nouveaux algorithmes de compression et de codage. Ainsi, de nombreuses applications multimédia deviennent accessibles à partir des réseaux sans fil. Cependant, ils présentent encore des obstacles au déploiement. Les problèmes majeurs de ces réseaux sont le taux de perte et la variation de délai dont les applications multimédia sont très exigeantes. Une solution évidente pour optimiser l'utilisation de la bande passante et améliorer la qualité de la vidéo consiste à transmettre la vidéo en multipoint à un ensemble d'utilisateurs.

Mais l'utilisation du multipoint standard présente trois problèmes principaux. Le premier est l'impossibilité d'adapter la fenêtre de contention suivant l'état du réseau. Le second est l'impossibilité d'adapter le débit physique suivant l'état du support de transmission, donc les paquets sont transmis à un débit physique fixe. Le troisième est l'impossibilité de retransmettre au niveau de la couche MAC les paquets perdus.

Une nouvelle approche a récemment été proposée pour remédier à ses problèmes. Elle consiste en l'élection d'un récepteur appelé leader pour assurer l'acquittement des paquets reçus. Ainsi, le point d'accès peut adapter le backoff et retransmettre les pa-

Dans ce rapport, nous présentons une nouvelle approche permettant de choisir un leader pour chaque groupe multipoint en utilisant de nouvelles trames de gestion.

D'autre part, le trafic vidéo, basé sur le protocole UDP, est en concurrence avec d'autres trafics TCP. Les flux TCP ont leurs propres mécanismes de s'adapter à l'état du réseau. Une nouveau mécanisme a été publié, connu par TFRC, permettant d'adapter les débit de transmission vidéo en gardant l'équité avec les autres flux TCP. L'utilisation de TRFC dans la transmission multipoint dans les réseaux IEEE 802.11 pose un problème puisqu'il est conçu pour la transmission point à point dans les réseaux filaires ainsi il ne tient compte ni des pertes dues au erreur de transmission ni de la retransmission des paquets perdus.

Nous proposons un nouveau mécanisme permettant d'adapter le débit de transmission vidéo. Nous proposons d'ajouter un nouvel agent placé entre la partie filaire et la partie sans fil. Ce dernier permet de distinguer entre les pertes dues à la congestion dans le réseau filaire de celle due aux erreurs de transmission dans le IEEE 802.11.

Nous montrerons dans ce rapport l'apport de cette nouvelle approche par rapport à la méthode de transmission multipoint standard à l'aide de la simulation. Nos simulations sont effectuées à l'aide du simulateur OMNET++.

Dans ce rapport, nous proposons un cadre théorique pour la transmission vidéo dans les réseaux IEEE 802.11. En premier lieu, nous allons introduire le cadre général de notre projet, ensuite nous allons traiter la transmission vidéo dans les réseaux IEEE 802.11. En effet, dans le premier chapitre, nous étudierons l'existant. Nous y présenterons d'abord les modèles physiques de propagation, la norme IEEE 802.11, et les algorithmes d'adaptation du débit physique. Dans le deuxième chapitre, nous étudierons la transmission multipoint dans les réseaux IEEE 802.11, nous présenterons les travaux existants puis nous proposons notre nouveau protocole nommé PLB. Enfin, un Troisième chapitre s'intéressera au contrôle de congestion dans la transmission multipoint dans les réseaux IEEE 802.11. Nous présenterons notre nouveau mécanisme ainsi les résultats de simulation qui montreront la performance de notre approche par rapport à l'existant.

Les réseaux IEEE 802.11

1.1 Introduction

Les réseaux IEEE 802.11 deviennent de plus en plus populaires puisqu'ils permettent de se connecter à l'Internet facilement, rapidement et dans n'importe quel espace couvert par un point d'accès. De nombreuses recherches sont récemment intéressées à l'étude, la modélisation et la simulation de ce réseau afin d'améliorer ses performances puisque les cartes IEEE 802.11 sont intégrées dans de nombreux technologies tel que Laptops, PDA et téléphone cellulaires.

Nous présentons dans ce premier chapitre la norme IEEE 802.11 en décrivant ses deux couches liaisons de données et physiques. IEEE 802.11 est caractérisé par son taux d'erreur de transmission élevé en le comparant avec les réseaux IEEE 802.3. Ainsi plusieurs modèles d'erreur ont été proposés pour permettre la simulation de ce réseau. Nous décrvions dans la deuxième section de ce chapitre les modèles de propagation physique. Les stations ayant des cartes IEEE 802.11 sont mobiles et les conditions de respections change en fonction de leur déplacement.

Dans la troisième section, nous présenterons quelques algorithmes permettant l'adap-

tation du débit de transmission physique. Dans la dernière section de ce chapitre nous présenterons les résultats des simulations que nous avons effectués afin de comparer les deux algorithmes les plus connus ARF et AARF.

1.2 Introduction à la norme IEEE 802.11

La norme IEEE 802.11 (ISO/IEC 8802-11) est un standard international décrivant les caractéristiques d'un réseau local sans fil Wireless Local Area Network (WLAN). Grâce au IEEE 802.11, il est possible de créer des réseaux locaux sans fil à haut débit à condition que l'ordinateur à connecter ne soit pas trop distant par rapport au point d'accès. Dans la pratique, ce réseau permet de relier des ordinateurs portables, des ordinateurs de bureau, des assistants personnels (PDA) ou tout type de périphérique à une liaison haut débit sur un rayon de plusieurs dizaines de mètres en intérieur, et à plusieurs centaines de mètres en environnement ouvert. Ainsi, des opérateurs commencent à irriguer des zones à fortes concentration d'utilisateurs (gares, aéroports, hôtels, trains, ...) avec des réseaux sans fil. Ces zones d'accès sont appelées " hot spots ".

Comme tous les standards de l'IEEE, 802.11 couvre les deux premières couches du modèle de référence OSI. L'une de ses caractéristiques essentielles est qu'il définit une couche MAC commune à toutes les couches physiques de sorte que de futures couches physiques pourront être ajoutées sans qu'il soit nécessaire de modifier la couche MAC. Nous présentons dans ce qui suit ses deux couches.

1.2.1 La couche PHY IEEE 802.11

Le rôle de la couche physique Physical Layer (PHY) est de transporter correctement les données que l'émetteur souhaite envoyer au récepteur. Elle est divisée en deux sous-couches, Physical Layer Convergence Protocol PLCP et Physical Medium Dependent PMD. Cette dernière s'occupe de l'encodage des données, alors que la sous couche PLCP prend en charge l'écoute du support, en fournissant à cette occasion un signal à la couche MAC pour lui dire si le support est libre ou non.

IEEE 802.11 définit quatre couches physiques différentes : frequency hopping spread spectrum FHSS, sequence spread spectrum DSSS, infra rouge IR et orthogonal frequency division multiplexing OFDM.

La couche PFIY définit aussi la modulation des ondes radioélectriques et les caractéristiques de la signalisation pour la transmission de données. La norme 802.11 propose en réalité trois couches physiques, définissant des modes de transmission alternatifs comme le montre le tableau 1.2.

1.2.2 Les différents modèles de propagation

Les ondes électromagnétiques sont actuellement le support de la plupart des communications sans fil et l'étude de leur propagation devient de plus en plus importante afin de pouvoir prédire l'onde reçue par une station réceptrice, connaissant l'onde émise. Elles sont utilisées pour diverses applications, à l'intérieur ou à l'extérieur, mais l'influence des effets qu'elles doivent subir est bien souvent différent selon le contexte. En effet, les phénomènes tels que la diffraction, la dispersion, la réflexion, l'absorption ou encore la transmission ont un impact direct sur la propagation du signal.

La modélisation de la propagation dans un réseau IEEE 802.11 comprend les modèles d'affaiblissement du signal à grande échelle large-scale path loss et les modèles à petite échelle small-scale path loss ainsi que les différentes fonctions de calcul de la puissance reçue et les méthodes de calcul du taux d'erreur d'un bit Bit Error Rate BER et du taux d'erreur d'un paquet Packet Error Rate PER.

1.2.2.1 Les modèles à grande échelle

1.2.2.1.1 Le modèle Free-Space Free-Space est le modèle le plus utilisé dans la majorité des simulateurs afin de calculer la puissance reçue. Ce modèle exige l'existence d'un chemin direct entre l'émetteur et le récepteur. De plus, Il exige que les deux noeuds se trouvent dans un environnement sans bruit. La formule 1.1 de Friis est utilisée pour le calcul de la puissance reçue [1].

1.2.2.1.2 Le modèle Two-Ray Ce modèle est plus réaliste que le premier puisqu'il tient compte des réflexions subites par le signal lors de sa propagation de l'émetteur jusqu'à son arrivée au récepteur. L'émetteur et le récepteur se trouvent dans un environnement sans bruit avec un chemin direct entre eux. Par suite, Le signal émis par l'émetteur subira des réflexions afin d'arriver au récepteur. Ce modèle sera le bon choix surtout lorsque la distance entre l'émetteur et le récepteur est assez grande et que l'émetteur se trouve à une grande hauteur.

A une grande distance de l'émetteur, la distance d est suffisamment grande devant (htÄhr)² et donc, la puissance reçue est calculée grâce la formule 1.2 [1]:

1.2.2.1.3 Le modèle Shadowing Ce modèle n'exige pas l'existence d'un chemin direct entre l'émetteur et le récepteur. Il modélise les déviations subites par le signal lors de sa propagation. En adoptant ce modèle, nous tenons en compte des phénomènes imprévisibles que peut subir le signal. La puissance reçue dans ce modèle varie en fonction du logarithme de la distance. La perte moyenne pour une distance donnée est exprimée par PathLossExponent. Nous ajoutons ensuite le phénomène de Shadowing qui est une variation statistique du signal autour de la valeur calculé à l'aide de Free-Space théorique. Cette variation est de moyenne nulle et sa variance

TAB. 1.1 - Les valeurs typiques de Path loss Exponent et Shadowing Variance Shadowin g_Variance est bien évidemment non nulle.

Pour calculer la puissance reçue, nous calculons tout d'abord une puissance référence en supposant que le récepteur est à une distance, dans notre cas 1 mètre, de la source à l'aide de la formule de Friis. Ensuite, nous ajoutons la perte due à la distance et l'effet de Shadowing.

Pr (dB W) = PuissanceR'ef'erence (dB W) --1 0.PathLossExponent.log(distance) +Shadowing

(1.3) Les valeurs de PathLossExponent et Shadowin g_Variance dépendent de l'environnement. Le tableau 1.1 présente les valeurs des environnements typiques selon [2] et [1].

1.2.2.2 Les modèles à petite échelle

Small-Scale fading, ou simplement fading, est utilisé selon T. Rappaport [1] pour décrire une fluctuation rapide de l'amplitude ou de la phase du signal pendant une très courte période. La cause de ce phénomène est l'interférence entre les différentes versions du signal émis quand elles arrivent au récepteur dans des instants distincts.

Ce modèle peut être ajouté avec l'un des modèles à grande échelle déjà cité. Il s'intéresse au coté dynamique de l'environnement, comme les mouvements de l'émetteur ou du récepteur au cours de la transmission des données.

1.2.2.3 Calcul de la probabilité d'erreur d'un bit

Pour obtenir des simulations de réseaux sans fil IEEE 802.11 plus réalistes, il faut pouvoir estimer avec précision les valeurs du BER et PER. Dans notre projet, nous sommes basés sur le travail de Masood Khosroshahy [2] pour le calcul du BER et du

PER. Il a déjà intégré son travail dans le simulateur YANS. Les formules pour le calcul du BER pour les différents types de modulations sont bien détaillées dans [2].

1.2.2.4 Calcul de la probabilité d'erreur d'un paquet

Dans cette partie, nous introduisons deux méthodes de calcul de la probabilité qu'un paquet soit perdu. La première, qui est la plus simple, est appelée la distribution uniforme de l'erreur Uniform Error Distribution. La deuxième est une nouvelle méthode proposée par Ramin Khalili et Kavé Salamatian [3].

1.2.2.4.1 Distribution uniforme de l'erreur Chaque paquet est composé de deux morceaux, la partie entête header et une partie donnée payload. Les deux morceaux sont envoyés dans la plupart des cas avec des débits de transmission différents. La probabilité de succès d'une transmission d'un morceau Chunk Success Rate CSR est calculée en fonction du BER de chaque bit de ce morceau à l'aide de l'équation 1.4.

Ensuite, La probabilité de succès d'une transmission d'un paquet Packet Success Rate PSR sera le produit des deux probabilités de chaque morceau [4]. Enfin, la probabilité d'erreur d'un paquet PER sera 1-PSR.

P ER = 1- (1- BERP _LCP ) HEADER - LENGT ^H.(1 - BERP AY LOAD) P AY LOAD_LENGTH (1.6)

Cette méthode suppose que la valeur de BER est uniforme pour tous les bits d'un paquet.

1.2.2.4.2 Distribution d'erreur non uniforme Dans ce paragraphe, nous présentons une deuxième approche pour le calcul du BER et du PER en se basant sur [3]. Selon Khalili et Salamatian [3] l'hypothèse que la distribution d'erreur est uniforme mène à une surestimation de la valeur PER. Ils ont ajouté de nouvelles notions afin de proposer d'autres formules pour le calcul du PER comme EER et À. Le taux d'erreur Error Event Rate EER est une probabilité indiquant la fréquence d'occurrence d'une erreur dans une partie d'un paquet. À est le paramètre d'une loi géométrique qui décrit la longueur d'une période d'erreur. Ce taux dépend de la valeur de SNR et aussi du FEC.

En bref, pour un morceau de paquet, il s'agit de tirer un nombre aléatoire qui serait l'événement d'un début d'une période d'erreur. Ensuite, tirer un autre nombre aléatoire qui représentera la durée en bits de cette erreur. Enfin, pour chaque bit dans cette période nous choisissons un nombre aléatoire et le comparons avec BER/ë.

1.2.3 La couche MAC 802.11

La couche de liaison de données de 802.11 se compose de deux sous-couches : le contrôle de la liaison logique Logical Link Control LLC et le contrôle d'accès au support Medium Access Control MAC. La norme 802.11 utilise la norme LLC 802.2 et un adressage sur 48 bits, tout comme les réseaux IEEE 802, simplifiant ainsi le pontage entre les réseaux sans fil et filaires. Le contrôle d'accès au support est en revanche propre aux WLAN. La couche MAC 802.11 est très proche de 802.3 dans sa conception: il est conçu pour supporter de multiples utilisateurs sur un support partagé en faisant détecter le support par l'expéditeur avant d'y accéder.

Access with Collision Detection régule l'accès des stations Ethernet au câble. Dans un WLAN 802.11, la détection des collisions est impossible du fait de ce qu'on appelle le problème "near/far". Pour détecter une collision, une station doit être capable de transmettre et d'écouter en même temps. Or, dans les systèmes radio, il ne peut y avoir transmission et écoute simultanées. En plus, la collision se fait au voisinage du récepteur et non pas de l'émetteur. Donc, l'émetteur peut ne pas détecter la collision.

Pour prendre en compte cette différence, le standard 802.11 fait appel à un protocole légèrement modifié, baptisé CSMA/CA Carrier Sense Multiple Access with Collision Avoidance, ou à la fonction DCF Distributed Coordination Function. Le protocole

Caractéristiques	802.1 1a	802.1 1b	802.1 1g
Fréquence	5 Ghz	2.4 Ghz	2.4 Ghz
Débit (Mbps)	6, 9, 12, 18, 24, 36, 48,54	1, 2, 5.5, 11	1, 2, 5.5, 6,9, 11, 12, 18, 22,24,33,36, 48,54
Modulation	BPSK, QPSK, 16 QAM, 64 QAM (OFDM)	DBPSK, DQPSK, CCK (DSSS, IR, et FH)	BPSK, DBPSK, QPSK, DQPSK, CCK, 16 QAM, 64 QAM (OFDM et DSSS)
FEC	1/2,2/3,3/4		1/2,2/3,3/4
Débit de base (Mbps)	6	1 ou 2	1,2 ou 6

CSMA/CA tente d'éviter les collisions en imposant un accusé de réception systématique des paquets (ACK), ce qui signifie que pour chaque paquet de données arrivé intact, un paquet ACK est émis par la station de réception.

Ce protocole CSMA/CA fonctionne de la manière suivante [5] une station qui souhaite émettre commence par explorer les ondes et, si aucune activité n'est détectée, elle attend un temps aléatoire avant de transmettre si le support est toujours libre. Si le paquet est intact à la réception, la station réceptrice émet une trame ACK qui, une fois reçue par l'émetteur, met un terme au processus. Si la trame ACK n'est pas détectée par la station émettrice (parce que le paquet original ou le paquet ACK n'a pas été reçu intact), une collision est supposée et le paquet de données est retransmis après attente d'un nouveau temps aléatoire.

CSMA/CA permet donc de partager l'accès aux ondes. Ce mécanisme d'accusé de réception explicite gère aussi très efficacement les interférences et autres problèmes radio.

Autre problème de la couche MAC, spécifique au sans fil, celui du noeud caché, où deux stations situées de chaque côté d'un point d'accès peuvent entendre toutes les deux une activité du point d'accès, mais pas de l'autre station, problème généralement lié aux distances ou à la présence d'un obstacle. Pour résoudre ce problème, le standard 802.11 définit sur la couche MAC un protocole optionnel de type RTS/CTS Request to Send/Clear to Send. Lorsque cette fonction est utilisée, une station émettrice transmet un RTS et attend que le point d'accès réponde par un CTS. Toutes les stations du réseau peuvent entendre le point d'accès, aussi le CTS leur permet de retarder toute transmis-

sion prévue, la station émettrice pouvant alors transmettre et recevoir son accusé de réception sans aucun risque de collision. Du fait que le protocole RTS/CTS ajoute à la charge du réseau comme le montre la figure 1.1 en réservant temporairement le support, il est généralement réservé aux plus gros paquets, dont la retransmission s'avérerait lourde du point de vue de la bande passante.

La norme IEEE 802.11 a donnée lieu à trois type de réseaux type de réseaux sans fil. Les premiers se fondent sur la norme IEEE 802.11b, les seconds sur les normes IEEE 802.11a et g et les troisièmes sur la norme IEEE 802.11n. 802.11b utilise la bande 2.4 Ghz et permet d'atteindre un débit théorique de 11 Mbps en utilisant les technologies d'étalement de spectre avec sauts de fréquence FHSS, de séquence directe DSSS, et IR. Alors que IEEE 802.11a transmet dans la bande 5 GHz et peut atteindre un débit de 54Mbps en utilisant OFDM. Le standard IEEE 802.11g est une extension du IEEE 802.11b qui peut atteindre un débit théorique maximale de 54Mbps.

Chaque mode de transmission est caractérisé par ses méthodes de modulation. La performance d'une modulation par rapport à une autre réside dans sa résistance contre les erreurs de propagation, les interférences et le fading.

Pour chaque mode de transmission, il y a toujours un mode de transmission de base utilisé généralement pour la transmission des ACK, RTS, CTS et les entêtes PLCP. Ce mode de transmission utilise BPSK ou DBPSK comme modulation pour avoir le minimum d'erreur. Les modes de transmission de base pour les couches physiques sont décrits dans le tableau 1.2. Par exemple, le débit de base pour IEEE 802.11b est 1 Mbps.

Dans la norme IEEE 802.11, chaque paquet peut être envoyer avec deux débits différents. L'entête PLCP est envoyée avec le débit de base, alors que la deuxième partie du paquet est envoyée avec un débit généralement plus élevé. Le débit de la deuxième partie est indiqué dans un champs de l'entête PLCP. Par la suite, le récepteur décode l'entête PLCP afin de connaître le débit de la deuxième partie du paquet.

1.2.3.1 Les modes opératoires de IEEE 802.11

Le standard 802.11 concerne deux types d'équipements, une station sans fil, en général un PC équipé d'une carte réseau sans fil, et un point d'accès (AP), qui joue le rôle de pont entre le réseau filaire et le réseau sans fil. Ce point d'accès se compose

habituellement d'un émetteur/récepteur radio, d'une carte réseau filaire comme par exemple IEEE 802.3 et d'un logiciel de pontage conforme au standard 802.1d. Le point d'accès se comporte comme la station de base du réseau sans fil, agrégeant l'accès de multiples stations sans fil sur le réseau filaire.

Le standard 802.11 définit deux modes : un mode infrastructure et un mode ad hoc.

1.2.3.1.1 Le mode infrastructure Le réseau sans fil consiste au minimum en un point d'accès connecté à l'infrastructure du réseau filaire et un ensemble de postes réseaux sans fil. Cette configuration est baptisée Basic Service Set BSS. Un Extended Service Set ESS est un ensemble d'au moins deux BSS formant un seul sous-réseau. En entreprise, la plupart des WLAN devront pouvoir accéder aux services pris en charge par le LAN filaire (serveurs de fichiers, imprimantes, accès Internet).

1.2.3.1.2 Le mode ad hoc Le mode ad hoc Independent Basic Service Set IBSS représente simplement un ensemble de stations sans fil 802.11 qui communiquent directement entre elles sans point d'accès. Ce mode permet de créer rapidement et simplement un réseau sans fil là où il n'existe pas d'infrastructure filaire.

1.2.3.2 Les algorithmes d'adaptation du débit physique

La transmission des ondes est susceptible à beaucoup de phénomènes physiques que nous avons listé dans la section précédente. Cependant, les variations de ses conditions de transmission peuvent être classer en deux catégories selon leur durée: l'une qui soit rapide comme la fermeture d'un porte, ou le déplacement d'un grand objet, et l'autre qui dure dans le temps comme se déplacer d'une chambre vers une autre. Ces perturbations auront toujours un effet sur l'énergie du signal radio, et dans la majorité des cas elles augmentent le BER.

Dans cette partie, nous présentons quelques algorithmes d'adaptation du débit de transmission physique en fonction des conditions du canal.

1.2.3.2.1 Le protocole ARF Auto Rate Feedback, est l'un des premiers algorithmes
publiés. Chaque station essaie d'augmenter son débit de transmission physique après
un certain nombre de transmissions avec succès et de diminuer ce débit en cas d'un ou

deux échecs successifs. Plus spécifiquement, ARF augmente le débit de transmission après dix transmissions successives avec succès et il le diminue lors de deux échecs successifs ou bien lors du premier échec juste après une augmentation du débit physique.

1.2.3.2.2 Le protocole RBAR Receiver Based Auto Rate a pour but d'optimiser le débit au niveau application. Cet algorithme exige l'échange des trames RTS/CTS entre la station émettrice et la station réceptrice. Cette dernière calcule le débit de transmission des données à l'aide du débit avec lequel a été envoyée la trame RTS et aussi à l'aide des valeurs de SNR des trames de données déjà reçus. Le débit de transmission PHY de la prochaine trame de donnée est envoyé avec la trame CTS. La figure 1.2 montre la performance de RBAR en le comparant avec ARF. RBAR [8] Receiver Based Auto Rate a pour but d'optimiser le débit au niveau application. Cet algorithme exige l'échange des trames RTS/CTS entre la station émettrice et la station réceptrice. Cette dernière calcule le débit de transmission des données à l'aide du débit avec lequel a été envoyée la trame RTS et aussi à l'aide des valeurs de SNR des trames de données déjà reçus. Le débit de transmission PHY de la prochaine trame de donnée est envoyé avec la trame CTS.

L'inconvénient de RBAR est qu'il exige que les toutes les stations écoutent les trames RTS et CTS afin de mettre à jour leur Network Allocation Vector (NAV) et aussi des modifications dans l'entête MAC IEEE 802.11.

1.2.3.2.3 Le protocole AARF Adaptative Auto Rate Feedback [9]est une amélioration de l'algorithme ARF. Ce dernier est la bonne solution pour un environnement où il y'a beaucoup de mouvement des stations. Mais, pour un environnement stable, le protocole ARF essaie périodiquement d'augmenter le débit alors que le débit de transmission actuel est le meilleur. AARF introduit de nouvelles variables pour minimiser le nombre de d'échecs suite à une augmentation du débit physique. AARF propose de doubler le nombre de transmissions avec succès nécessaire pour augmenter le débit de transmission physique lors d'un échec suite à une augmentation du débit.

1.3 Simulation et évaluation

Dans cette deuxième partie du chapitre nous présentons les résultats de nos simulations que nous avons effectuées. Nous présentons au début une comparaison entre des différents modèles de propagation, ensuite une comparaison entre les deux algorithmes d'adaptation de débit physique ARF et AARF.

1.3.1 Comparaison entre les différents modèles de propagation physique

Nous allons nous intéressés à la comparaison des modèles physiques de propagation FreeSpace, TwoRay et Shadowing. Nos comparaisons sont faîtes en fonction du

PER. Notre réseau est composé comme le montre la figure 1.2 essentiellement d'un serveur " source vidéo ", d'un point d'accès et une station. Le point d'accès est connecté à un réseau filaire dans lequel un serveur transmet un flux vidéo vers la station mobile. La station mobile se déplace avec une vitesse constante de 1m/s en s'éloignant du point d'accès avec une direction linéaire. Nous avons réalisé des simulations en utilisant un réseau IEEE 802.11a avec les paramètres décrits dans le tableau 1.3 Les

tableaux 1.4 et 1.5 montre les paramètres de configuration des deux modèles Two Ray et Shadowing que nous avons utilisés dans nos simulations. La figure 1.3 montre la variation de PER en fonction de la distance dans un cas où nous ne tenons pas compte du fading. Notre première remarque est que le modèle Two-Ray donne un faible taux de perte. Notre explication est que ce modèle n'est pas le mieux adopté pour les réseaux de type IEEE 802.11 car il est basé sur l'hypothèse que la distance entre l'émetteur et le récepteur doit être très grande par rapport à carré du produit de la hauteur et l'émetteur et du récepteur . Ce qui n'est pas toujours vrai dans le réseau IEEE 802.11 dont la dimension est généralement petite. Notre deuxième remarque est que dans tous les modèles le taux de perte augmente quand la distance entre l'émetteur et le récepteur augmente. Enfin, nous remarquons qu'il y a des pertes de paquets même à une petite distance du AP dans le modèle Shadowing.

Nous avons aussi simulé le même scénario avec le modèle FreeSpace en ajoutant l'effet de fading. Nous avons utilisé les même les paramètres utilisés par [2] qui sont dans le tableau 1.6.

La figure 1.4 montre que en ajoutant l'effet fading au modèle Free Space les pertes

commencent même à une petite distance du point d'accès. Nous remarquons aussi que à 50 mètres du point d'accès le taux de perte est très élevé.

1.3.2 Comparaison entre les deux algorithmes d'adaptation du débit physique ARF et AARF

Pour comparer AARF par rapport à ARF, nous avons simulé un scénario avec une station mobile distante de 50 mètres d'un point d'accès. La station (srv1) envoie une séquence vidéo avec un débit constant à la station mobile (whost1). Dans ce scénario nous avons utilisé le modèle FreeSpace avec le modèle fading.

D'après la figure1.5, Nous constatons que le meilleur débit PFIY entre ces deux stations est 6Mbps. ARF augmente le débit après 10 transmissions successifs et par la suite il cause plus de perte de paquets.

FIG. 1.5 - Comparaison entre les deux approches ARF et AARF dans un scénario statique

Pourtant AARF n'est pas le mieux adapté dans un environnement mobiles. Nous avons simuler le même scénario mais dans ce cas la station mobile (whost1) s'approche du point d'accès avec une vitesse constante de 1m/s. La figure1.6 montre que ARF converge rapidement vers le débit le plus adéquat alors que AARF continue à envoyer les paquets avec un débit plus faible que celui de ARF.

Cette comparaison mettre en evidence l'apport de AARF par rapport à ARF dans le cas d'un scénario peu mobile puisque les conditions de réceptions de change pas trop. Alors que dans un cas où les stations sont mobiles et les conditions de réception changent, ARF est le mieux adopté comme algorithme d'adaptation de débit.

FIG. 1.6 - Comparaison entre les deux approches ARF et AARF dans un scénario mobile

1.4 Conclusion

Nous avons présenté tout au long de ce chapitre la norme IEEE 802.11, les differents modèles de propagations physique et quelques algorithmes permettant d'adapter le débit de transmisssion physique en fonction des conditions du canal. Dans le chapitre suivant nous présenterons l'etat de l'art de la transmission multipoint dans les réseaux IEEE 802.11.

La transmission multipoint dans les

réseaux IEEE 802.11

2.1 Introduction

La meilleure solution proposée pour la diffusion d'un flux vidéo à un ensemble de récepteurs est le multipoint. Pourtant, la norme IEEE 802.11 ne supporte pas les mécanismes spécifiques pour la transmission multipoint.

Nous concernons ce deuxième chapitre à la présentation de la transmission multipoint dans les réseaux IEEE 802.11. En effet, nous présenterons dans la première section la transmission multipoint suivant la norme ainsi que les problèmes posés par cette dernière. Dans la deuxième section, nous présentons les approches proposées pour améliorer la qualité de la transmission vidéo. Dans la troisième section nous spécifions en détails notre nouvelle approche nommé PLB. La dernière section sera consacrée à l'évaluation de performance de notre approche par rapport à la transmission IEEE 802.11.

2.2 La transmission multipoint sur les réseaux IEEE 802.11

Le multipoint est un paradigme efficace pour transmettre des données d'un émetteur vers un groupe de récepteurs appelé souvent "membre du groupe ". Le multipoint permet de gagner en terme de bande passante par rapport à une transmission point à point pour chaque membre du groupe multipoint. Plusieurs applications comme les études à distance, les conférences multimédia, les jeux vidéo sur web et les calculs parallèles utilisent le la transmission multipoint.

Le standard IEEE 802.11 ne supporte pas de mécanismes spécifiques pour la transmission multipoint. Cette transmission se fait de la même manière que la diffusion. L'utilisation du standard pose trois problèmes principaux qui sont:

La fiabilité de transmission: La plupart des applications multimédia tolèrent la perte des paquets dans le réseau, mais en cas de grande perte de paquets la qualité de transmission se détériore rapidement.

L'adaptation du débit physique de transmission: Pour optimiser la qualité de transmission d'un flux multimédia, les réseaux IEEE 802.11 doivent adapter dynamiquement leur débit physique de transmission. Un grand nombre de mécanismes ont été proposés comme RBAR, ARF et AARF. Pour la transmission multipoint, les points d'accès utilisent un débits fixe qui est le plus faible.

Le contrôle de congestion: Dans les réseaux IEEE 802.11, la taille de la fenêtre de contention est fixe pour la transmission multipoint alors que pour les flux pointà-point la couche MAC double la taille de sa fenêtre de contention en cas de collision. Sans avoir un mécanisme de feedback, le contrôle de congestion est impossible pour les flux multipoint surtout que ce flux sera en concurrence avec d'autres flux point à point. Donc, sans un mécanisme de contrôle de congestion, on ne peut pas adapter le débit de transmission et garantir l'équité entre les flux.

2.3 Les solutions existantes

BMW (Broadcast Medium Window) [10] est le protocole le plus fiable pour la transmission multipoint puisqu'il propose d'envoyer une copie de la trame multipoint à

chaque membre du groupes multipoint en point-à-point. BMW ajoute une grande surcharge pour les réseaux IEEE 802.11 qui peut engendrer une congestion dans la file d'attente du point d'accès.

Sun et al. [11] propose l'algorithme Batch Mode Multicast MAC BMMM une amélioration de BMW, BMMM garde les mêmes entêtes des messages RTS,CTS, et ACK spécifié dans la norme IEEE 802.11 et ajoute une nouvelle trame de contrôle nommé RAK, (Request fo ACK). RAK sera utilisé par le point d'accès pour demander un ACK d'un récepteur. A la réception d'une trame multipoint le point d'accès envoie un RTS à chaque membre de groupe multipoint. Chaque membre du groupe multipoint répond par un CTS. Une fois le point d'accès reçoit le CTS du dernier membre il envoie la trame multipoint ensuite il vérifie si la trame est reçu correctement par la totalité des membre du groupe. Pour ce faire, il envoie RAK à chaque station membre du groupe multipoint et attend la réception du ACK. Deux cas se présentent, si le point d'accès ne reçoit pas un ACK de l'un du membre du groupe, il retransmet la trame sinon la trame est reçue correctement par tous les membres du groupe multipoint. Les avantages de BMMM sont : réduction du nombre des phases de contention et pas de modifications dans des entêtes de la norme IEEE 802.11. Par contre, Il ajoute une surcharge au réseau avec les messages RTS/CTS et RAK/ACK à chaque transmission.

Kuri et al. [12] propose un autre protocole nommé Leader-Based Protocol LBP. LBP introduit quelque modification au niveau de la couche MAC en utilisant les trames RTS/CTS dans la transmission multipoint. Le protocole suppose qu'une station parmi les récepteurs multipoints est choisie d'être leader du group. Le leader renvoie un CTS ou ACK lorsqu'on reçoit un RTS ou paquet multipoint, respectivement. Le point d'accès conserve une liste de groupe multipoint ainsi que l'adresse du leader de chaque groupe. Le protocole ajoute aussi deux messages envoyés par les stations join-message et leave-message permettant de joindre et quitter un groupe multipoint, respectivement. L'inconvénient de cette solution est qu'il est inefficace dans le cas où les stations sont peu mobiles ou immobiles puisqu'elle surcharge le réseau avec les nouvelles trames.

LPRMP est un autre protocole proposée par Ding et al.[13]. Ce protocole traite la détection des collisions de message multipoint par les points d'accès dans un réseau sans fil. Le point d'accès LPRMP attend une nouvelle période appelée MCDI (Multicast collision detection internal) en plus du DIFS avant d'envoyer le paquet multipoint.

Tous les protocoles présentés n'ont pas traités la congestion au niveau du point d'accès ni l'adaptation du débit due à la condition du canal.

Dans [14], Villalòn et al. ont proposé une solution nommé auto rate selection mechanism ARSM, pour résoudre les problèmes de la congestion, l'adaptation du débit ainsi que la fiabilité de transmission multipoint. ARSM met à jour le débit de transmission selon les conditions de réceptions des stations. Afin de ne pas surcharger le réseau, la station ayant une valeur de SNR la plus faible a plus de priorité d'envoyer son feedback. En effet, le point d'accès choisi le leader selon la valeur de SNR la plus faible. L'inconvénient de ARSM est qu'il ajoute de nouvelle trames de contrôle ainsi il n'est pas compatible avec la norme IEEE 802.11.

Le protocole Leader-Based Multicast Service LBMS [15] est une nouvelle approche basée aussi sur le mécanisme leader. LBMS spécifie de nouvelles trames de contrôle de congestion dans le réseau qui sont : LBMS.request, LBMS report. Le point d'accès sélectionne un Leader pour chaque flux multicast. Cette élection se base sur les rapports envoyés périodiquement par les stations qui peuvent contenir des informations sur la qualité de réception comme PER, SNR. La trame LMBS.request est envoyée par une station vers le point d'accès auquel elle est associée pour s'abonner à un ou plusieurs groupes multipoint. La trame LBMS.report est une nouvelle trame envoyée par une station vers le AP de façon périodique. Elle contiendra des statistiques de performance (Packet Loss Rate, SNIR..) . Les trames LBMS sont envoyées par le point d'accès vers une station et vice versa.

2.4 Practical Leader-Based

Dans cette section, nous présentons en détail notre nouveau mécanisme Practical Leader-Based PLB. PLB utilise les rapports de diagnostiques spécifiés dans IEEE 802.11v [16]. En effet, chaque station envoie périodiquement un message contenant ses valeurs courantes de SNR et PER ainsi que les adresses multipoint des stations dont elle est inscrit. Au début de la session, le point d'accès choisie une la première station qui se s'associe au groupe multipoint comme leader. En se basant sur les messages de diagnostiques, le point d'accès sélectionne la station qui possède la valeur SNR la plus faible ou bien la valeur de PER la plus élevé comme leader. Pour transmettre une trame multipoint, le point d'accès utilise les trames RTS/CTS avec le leader. La struc-

ture les messages RTS/CTS sont les mêmes utilisés dans la transmission point-à-point, seulement le champ TA (transmitter address) de la trame RTS aura l'adresse du groupe multipoint au lieu de l'adresse du point d'accès. Pour réduire la surcharge ajoutée par les messages RTS/CTS, le point d'accès utilise le débit courant pour transmettre la trame RTS au leader.

Donc, le Leader, élu grâce par le AP, acquitte les trames reçues du point d'accès. Le point d'accès utilise ARF pour adapter le débit de transmission physique. Quand le temporisateur expire ou bien la réception de dix acquittements consécutifs alors le débit de transmission passe au prochain niveau. Dans le cas contraire, en cas de perte de 2 trames successives, le débit de transmission physique diminue, c'est-à-dire le débit descend vers le niveau le plus bas. Ainsi, en fonction les trames CTS/ACK reçu du leader, le point d'accès adapte le backoff.

2.5 Evaluation de performances

Afin de montrer l'apport de l'approche leader-based dans la transmission multipoint dans les réseaux IEEE 802.11 nous avons effectués une série de simulations. Nous avons classés nos simulations en deux classes. La première classe concerne les scénarios statiques où les stations sont immobiles alors que la deuxième classe contient des scénarios dont les stations sont mobiles.

2.5.1 Scénario statique

Afin de montrer l'apport de l'approche leader-based dans la transmission multimédia dans les réseaux IEEE 802.11, nous avons simulé deux scénarios de transmission vidéo dans un réseau IEEE 802.11a similaires à ceux décrits dans [17].

Le premier scénario avec la transmission multicast standard alors que le deuxième avec l'approche Leader. Le modèle physique utilisé dans ce scénario est le Shadowing avec 2.0 comme valeur de pathlossexponent et 4.0 comme valeur de variance de l'effet shadowing.

Comme le montre la figure 2.1, ce scénario consiste à deux réseaux l'un de type Ethernet et l'autre de type IEEE 802.11. La source vidéo envoie un CBR de 512kbps. Le tableau 2.1 montre le taux de perte des paquets RTP au niveau de chaque station, Nous constatons que le taux de perte est très élevé dans la station 4 dans notre première simulation. Cette perte est due à la distance qui sépare la station 4 du point d'accès.

Nous avons choisi cette station comme leader dans notre deuxième simulation. Nous constatons que le taux de perte a diminué pour cette station de 16.37% à 9.09%. Le taux de pertes a diminué aussi pour les autres stations. Le taux de pertes 9.09% est due au perte des paquets après trois retransmissions successifs et aussi aux pertes dans la queue du point d'accès due au retransmission des anciens paquets.

2.5.2 Scénario dynamique

Dans nos simulations, nous avons utilisés le modèle shadowing comme modèle de propagation. Comme le montre la figure2.2 , otre scénario correspond à un musée contenant 3 salles (40m x 40m) et un point d'accès placé au milieu de la salle. 3 stations mobiles qui correspondent à 3 visiteurs se déplacent dans la salle de manière linéaire. La vitesse et temps de pause et période de mouvement sont des variables aléatoires qui suivent une loi uniforme.

La topologie de ce scénario contient 3 APs et une station source vidéo. La station est utilisée pour envoyer des flux TCP et un flue vidéo multipoint pour un ensemble de 9 stations sans fil. Pour comparer la performance de PLB par rapport à la transmission standard, nous avons effectué deux simulations.

A l'instant t=5s, la station commence la transmission d'un CBR vidéo de 512kbps. A l'instant t=50s, les connexions TCP commencent. La figure 2.3a montre le débit vidéo reçu par les deux stations (la meilleur et la pire) le débit TCP correspondant. Nous pouvons remarquer que la station 7 (la meilleur) reçoit un débit proche de celui de la station 4(la pire).

La figure 2.3b montre le débit vidéo par la transmission standard et le TCP reçus par les mêmes stations de la figue 2.3a. Le débit vidéo reçu est 5% mois que celui reçu en utilisant PLB. En plus, les stations 7 et 4 ont reçu respectivement 20% et 30% mois de débit avec la transmission standard. En effet, avec la transmission standard obtient plus de priorité pour accéder au medium que les flux TCP.

2.6 Conclusion

Tout au long de ce chapitre, nous avons présenté la transmission multipoint dans la norme IEEE 802.11 et les travaux existants proposés pour améliorer cette dernière. Nous avons décrit en détail notre nouveau protocole PLB et nous avons montré ses performances par rapport à la transmission multipoint standard.

Le prochain chapitre traitera le contrôle de congestion de la transmission multipoint dans un scénario hybrif filaire/sans fil.

Le contrôle de congestion dans un réseau

TP hybride filaire/sans fil

3.1 Introduction

L'Tnternet a vécu une énorme évolution en nombre d'utilisateur pendant ses dix dernières années surtout avec l'apparition dans réseaux sans fils TEE 802.11. En plus, les nouvelles applications multimédia demandent de plus en plus de la qualité de service en délai et taux de pertes. Parmi les facteurs influant sur la qualité de service qui est la contrôle de la congestion.

Dans ce chapitre, nous présentons un cadre général du contrôle de congestion sur Tnternet. Nous décrivons dans la troisième section de ce chapitre le contrôle de congestion dans le cas des applications multimédia. Dans la section 4, nous décrivons un état de l'art du contrôle de congestion dans le cas des réseau sans fil, nous proposons ensuite notre nouveau mécanisme permettant d'estimer le temps aller-retour et de distinguer les pertes due à la congestion des pertes de transmission.

Dans une dernière section, nous présenterons les résultats de nos simulations et une étude de performance de notre nouvelle approche.

3.2 Le besoin du mécanisme de contrôle de congestion

Avant de présenter le contrôle de congestion sur Internet et son impact sur les applications multimédia commencent par comprendre pourquoi a-t-on besoin d'un mécanisme de control de congestion.

Tout d'abord, le réseau Internet accepte tous les paquets envoyés et essaie avec son Best Effort de les transmettre aux récepteurs. Cependant, le Best Effort ne garantit pas la livraison de tous les paquets puisqu'il supprime les paquets en excès en cas de congestion. Dans ce cas, les protocoles de la couche applicative doivent calculer le taux de pertes des paquets envoyés pour adapter leur taux d'émission des paquets. Sinon, il y aura une chute dans les performances du réseau.

Les techniques de contrôle et de gestion de flux sont donc capitales dans le monde des réseaux. Les réseaux à transfert de paquets sont comme des autoroutes s'il a trop de trafic, plus personne ne bouge. Il faut donc contrôler le réseau et les flux qui y circulent. Le contrôle de flux est préventif, puisqu'il limite les flots d'information à la capacité de transport du support physique. Le control de congestion a pour objectif d'éviter la congestion dans les noeuds et de résoudre les embouteillages lorsqu'ils sont effectifs.

Les deux termes, contrôle de flux et de contrôle de congestion peuvent être définis de manière plus précise.

- Le control de flux est un accord entre deux entités, la source et la destination, pour limiter le débit de transmission du service en considérant les ressources disponibles dans le réseau.

- Le contrôle de congestion représente l'ensemble des actions entreprises afin d'éviter et éliminer la congestion causés par manque de ressources.

3.3 Le contrôle de congestion sur Internet

Le contrôle de congestion sur Internet est implémenté au niveau de la couche Transport. Le protocole UDP ne contient aucun mécanisme de contrôle de congestion alors que TCP possède un ensemble d'algorithme de contrôle de congestion.

TCP est un exemple de protocole qui utilise la fenêtre coulissante. La source ajoute un numéro de séquence dans chaque paquet qu'elle envoie et attend la réception d'un acquittement de la part du récepteur. A l'aide de cette fenêtre chaque source TCP peut estimer les capacités du réseau et par conséquence éviter la saturation su réseau.

Le principe de base du contrôle est fondé sur l'algorithme slow-start. Le contrôle s'effectue par la fenêtre, qui augmente ou diminue suivant la valeur du délai aller- retour dans paquets dans le réseau. La fenêtre augmente de façon exponentielle jusqu'à ce qu'une perte soit considère. La dernière valeur acceptable avant la perte est appelée seuil de saturation. Apres la perte, la valeur de la fenêtre est remise à 1 puis se met de nouveau à augmenter. A partie de là, la croissance se fait en deux phases. La première phase, le slow-start de nouveau, commence par une fenêtre de taille 1, correspond à un segment TCP. A chaque réception d'un acquittement la fenêtre double de valeur. Même en partant d'un flux faible au départ, on arrive rapidement à un débit important, surtout si le délai aller-retour, ou RTT( Round Trip Time), du réseau est court. Cette procédure est maintenue jusqu'à ce que la fenêtre atteigne la limite, indiquant un nouveau processus de croissance de la fenêtre, qui devient beaucoup plus limité, puisqu'on approche de la limite de saturation de la connexion. On passe alors d'une phase dite de Congestion Avoidance.

La fenêtre évolue de façon linéaire, augmentent d'un segment supplémentaire chaque fois qu'un ensemble de segments est reçu correctement. A chaque nouvelle perte de paquet, le seuil de saturation se met à jour et l'algorithme redémarre par slow-start.

3.4 Le contrôle de congestion pour les applications multimédias

Avant de présenter les mécanismes de contrôle pour les applications multimédia. Nous présentons tout d'abord le protocoles temps réels RTP et RTCP.

3.4.1 Les protocoles temps réels

Les applications temps réel sont soumises à des contraintes de temps strictes qui rendent impossible l'utilisation de Transport Control Protocol (TCP). Le protocole Realtime Transport Protocol [20] (RTP) essaye de palier aux inconvénients des protocoles TCP et User Datagram Protocol (UDP). En effet, les mécanismes du protocole TCP, tels que la fiabilité par acquittement et retransmission des paquets manquants, le contrôle de flux par la fenêtre de congestion (slow start), sont incompatibles avec les applications temps réel. En plus les paquets UDP se trouvent dépourvus de certaines informations comme le numéro de séquence.

3.4.1.1 Le protocole Real-time Transport Protocole (RTP)

Le protocole RTP (Real Time Trotocol) a été développe au sein du groupe travail ACT (Audio Video Transport) de l'IETF. RTP définit un format d'encapsulation de données multimédia temps réel " compatible ALF" sur l'Internet.

Ce protocole assure une numérotation et un horodatage des paquets en encapsulant les données dans une nouvelle entête. Il repose lui-même sur le protocole UDP, qui ne renvoie pas les trames perdues en cours de route, afin de privilégier l'enchaînement du son et des images, plutôt que l'intégrité des données. La qualité peut en souffrir si la liaison est mauvaise, mais c'est un mal nécessaire à la diffusion en direct.

Dans le cadre même de notre projet, deux possibilités se présentent. La première consiste à envoyer simultanément un flux de données vers chacun des clients. L'autre solution est le multipoint qui se caractérise par la diffusion d'un flux unique vers un groupe multipoint, dont les clients lisent simultanément les mêmes informations. Dans l'objectif d'avoir une optimisation de la consommation de la bande passante, il est préférable d'utiliser une diffusion en multipoint.

- la flexibilité du type des données transmises : RTP doit pouvoir être extensible des applications autres que l'audio et la visioconférence,

- la comptabilité avec les passerelles: les passerelles de niveau RTP permettent de concaténer plusieurs flots de médias en un flot unique en changent la taille des paquets et/ou codage et/ou le protocole de transport.

- le démultiplexage selon le type de média : par exemple audio PCM, video H.264,
- le démultiplexage selon le type de média : par exemple audio PCM, video H.264,
- la suppression de la gigue de délai introduite par la transmission au niveau ré-

Mais le protocole RTP ne permet pas de réserver les ressources dans le réseau, d'assurer une fiabilité et de garantir le délai de livraison.

3.4.1.2 Le protocole Real-time Transport Controle Protocole (RTCP)

Le protocole RTP est complété par le protocole RTCP qui transmet périodiquement des paquets de contrôle à tous les participants d'une session. Il adopte le même mécanisme de transmission que le protocole RTP.

Selon [18] et [19], le protocole RTCP remplit trois fonctions principales plus une optionnelle. Il retourne les statistiques feedback sur la qualité de réception des données transmises dans les paquets RTP. Ces informations temps réel peuvent être exploitées par la source pour adapter le type de codage au niveau des ressources disponibles. RTCP transporte un identificateur unique de la source RTP, appelé Nom Permanent Canonical NAME (CNAME) car l'identifiant SSRC peut changer et ne permet pas, à lui tout seul, d'identifier une source. Les destinataires peuvent avoir besoin du nom permanent, CNAME, pour associer plusieurs flux de données d'un même participant dans un ensemble de sessions RTP, par exemple pour une synchronisation audio-vidéo.

De plus, la réception des feedbacks et la connaissance du CNAME supposent que tous les participants envoient des paquets RTCP régulièrement. Ces informations servent à ajuster le débit de sortie et à l'adapter de manière à accommoder toutes les personnes désirant se joindre à l'évènement.

Enfin, la quatrième fonction qui est optionnelle, consiste à transmettre des informations permettant une régulation minimale des membres. RTCP assure l'identification des participants à une conférence en jouant le rôle d'un canal de liaison entre des participants fluctuants, et a priori non identifiés.

3.4.2 Le contrôle de congestion multimédia

Le contrôle de congestion regroupe l'ensemble des mécanismes permettant d'adapter le débit des flux à la bande passante disponible dans le réseau. Les propriétés fondamentales d'un schéma de contrôle de congestion sont la stabilité, l'équité et la réactivité.

La stabilité signifie que la congestion est contrôlée et que le réseau fonctionne avec un état satisfaisant, sans oscillation excessive. Le concept d'équité est plus complexe, on dit qu'un algorithme est équitable lorsque, en régime stable, la bande passante est allouée de manière identique à tous les flots qui traversent une liaison congestionnée. Enfin, la réactivité porte sur la vitesse de convergence vers un état stable.

Le contrôle de congestion s'apparente alors à un processus adaptif impliquant source et récepteur qui, en surveillant l'état du réseau, peut détecter l'apparition de congestion ou les phénomènes d'évanouissement sur réseaux et réduire le débit de l'émetteur. À l'inverse, un état peu "chargé" du réseau va déclencher une augmentation du débit.

Deux solutions peuvent être envisagées suivant les contraintes applicatifs, une pour les applications point à point et une autre pour les applications multipoints.

Le contrôle de congestion dans les communications s'effectue à la source. Le principe est basé sur l'échange de message de contrôle entre le récepteur et la source. Ce dernier adapte son débit en fonction des informations collectées.

Les informations renvoyés par le récepteur peuvent être le temps aller retour RTT ou bien le taux de pertes. D'une part, en cas de congestion, le remplissage de la file d'attente entraîne l'accroissement du RTT. D'autre part, en cas de congestion, il y a aura des pertes des paquets due à la saturation des files d'attente du réseau. Le récepteur peut calculer son taux de pertes sur un intervalle donné et revoie cette valeur à la source en utilisant le protocole RTCP.

La première solution proposée était une émulation du protocole TCP en utilisant l'algorithme Additive-Increase Multiplicative-Decrease (AIMD). Comme TCP, Rate Adaptation Protocole RAP [22], les paquets envoyés par la source seront acquittés par le récepteur. La seule différence entre TCP et RAP est que la source ne revoie pas de nouveau les paquets perdus. Une autre approche vise le partage équitable des ressources avec les connexions TCP. Floyd et al [23] propose une équation permettant d'adapter

le débit en fonction de l'état du réseau en se comportant de la même manière que TCP.

Avec RTT est le temps aller retour, MTU la taille des paquets et L est le taux de pertes calculés par le récepteur. Les rapports RR du protocole RTCP fournissent l'information de taux de pertes ainsi que l'information nécessaire au calcul du délai aller- retour RTT.

Padye et al.[24] ont proposé un modèle plus robuste et plus fiable tenant en compte de la retransmission et l'effet du timeouts sur TCP. L'équation de prédiction de la bande passante s'exprime alors sous la forme:

Où S est la taille des paquets, l le taux de pertes, tRTT est le temps aller-retour. Le

terme tRT O représente la valeur du timeouts régissant les demandes de retransmission de TCP estimée par quatre fois le temps aller retour:

LDA+, Loss-Delay Based Adustement Algorithm [25] proposé par Dorgham Sisalem et Hening Schulzrinne permet d'adapter le débit de transmission pour les applications multimédia. La source commence la session RTP avec un débit initiale r0 et une valeur initiale pour le A0. Après la réception an RTCP du récepteur, la source calcule de nouveau A_m avec:

Avec R est le goulot d'étranglement,M la taille de paquets, ô est le RTT et rm_1 est le débit courant. Si un taux de perte est indiqué dans le paquet RTCP alors de débit est

r_m = rm_1 + A_m (3.10) En adaptant le modèle du throughput TCP proposé par [22], TCP-Friendly Rate Control (TFRC) est introduit afin d'éviter les comportements oscillatoires. La mesure du taux de pertes est remplacée par une mesure d'événement de pertes afin de modéliser plus

finement la réaction à des rafales des pertes. Un événement de pertes est défini comme plusieurs paquets consécutifs perdus et afin d'améliorer la stabilité les variations de RTT sont lissées par un filtre glissante.

Cho et Al[26] proposent une amélioration de TFRC avec un protocole plus robuste appelé Adaptive TCP Friendly Rate Control Protocol AFTRC. ATFRC distingue entre le calcule de débit des périodes de pertes ainsi que la périodes sans perdes. Il garde la même formule [22] pour les périodes avec pertes et proposent une nouvelle équation pour les périodes sans pertes.

3.4.2.2 Le contrôle de congestion multipoint

Le multipoint ajoute des problèmes liés à l'hétérogéniste des conditions de réception dans le réseau, mais ainsi aux capacités de décodage des récepteurs. Il s'agit alors de concevoir un ensemble de mécanismes permettant à une source de transmettre un même flux vidéo à plusieurs récepteurs, tout en ayant la possibilité d'adapter de manière dynamique et avec une granularité suffisamment fin le débit reçu par chacun aux conditions de transmission qu'il reçoit.

La solution proposée est le codage multi niveau ou chaque niveau correspond à un incrément de qualité. Cela revient à découpler la source, qui émet de façon indépendante le flux vers multi niveaux, des récepteurs capables de s'abonner à un ou plusieurs flux afin de satisfaire aux conditions liées aux caractéristiques des différents liens et au contrôle de congestion associé. Cette solution permet aux récepteurs de changer leur niveau en réponse d'une certaine congestion. L'idée de base est que chaque récepteur:

3.5 Le Contrôle de congestion dans les réseaux sans fil

Dans cette section nous nous intéressons à la scénario hybride filaire/sans fil comme l'indique la figure. La source vidéo est localisée sur Internet et les récepteurs vidéo sont placés dans un réseau local. En effet ce scénario correspond bien au cas musée où les visiteurs sont invités à suivre des séquence vidéo lors de leur déplacement entre les

différents couloirs. Les visiteurs peuvent aussi consulter leur boite de messagerie, té-
lécharger les images de haute définition, et naviguer sur Internet. Ainsi, le flux vidéo

multipoint est en concurrence avec d'autres flux point-à-point. Les mécanismes que nous avons déjà cités dans la section précédente ne traitent pas le cas des réseaux sans fil. Les pertes dans les réseaux sans fil sont différentes par rapport à celle dans les réseaux filaires puisque d'autres pertes s'ajoutent aux pertes de congestion. En plus dans notre cas il s'agit d'une transmission multipoint et non pas point à point donc les erreurs de transmission varie d'une station à une autre. Nous présentons dans ce qui suit l'état de l'art des mécanismes proposés pour résoudre le problème de congestion dans un tel scénario.

3.5.1 Etude de l'existant

Sisalem et al [27] proposent un nouveau algorithme WLDA+ Wireless Loss-Delay based Adaptation algorithm. WLDA+ est une extension de LDA+ dans un environnent sans fil. Le taux d'erreurs calculé par les récepteurs est constitué des pertes due à la congestion ainsi que les pertes due au canal de transmission. Pour distinguer entre les deux types d'erreurs, [27] proposent deux versions de WLDA+ chacune basé sur une méthode pour le calcul des pertes dans le réseau IEEE 802.11. WIN-LDA+ calcule les pertes dans le réseaux sans fil en utilisant l'inter arrivé des paquets tel qu'il a été proposée par Biaz [28]. Le second se base sur le travail de Tobe et al [29] pour calculer le taux de pertes dans la partie sans fil du réseau appelé WRO-LDA+. L'inconvénient de cette solution est l'envoie de paquets de taille fixe.

Lee et al[30] s'appuie sur le champs DATA.indication dans le paquets IEEE 802.11 pour distinguer les erreurs due à la transmission par rapport à celle due à la congestion. Il s'appuie sur un mécanisme cross layer pour renvoyer ses informations à la couche transport.

TFRC-ASN est une autre approche proposé par Lee et al [31] permettant de distinguer entre les erreurs de transmission des erreurs de congestion. TFRC-ASN ajoute une nouvelle étiquette au paquet dans les réseaux sans fil contenant un nouveau numéro de séquence. Pour discriminer les erreurs de congestion et de transmission le point d'accès implémentant TFRC-ASN compare le désordre dans la nouvelle séquence ajoutée et cette du protocole transport (TCP ou RTP). L'inconvénient de cette solution est la sécurité puisqu'elle se base sur la lecture des entêtes des couches supérieur (couche transport).

Li et al [32] proposent TFRC-Jr qui utilise la valeur du la gigue des paquets RR du protocole RTCP afin de distinguer entre les erreurs de transmission des erreurs due à la congestion.

Tous ces travaux ne tiennent pas compte des retransmissions dans le réseau sans fil, suppose que le lien sans fil est le goulot d'étranglement et impose l'utilisation des paquets de tailles fixes. Dans le paragraphe suivant nous proposons notre mécanisme qui permet de distinguer entre les erreurs de transmission et les erreur de congestion et qui est valide pour un réseau hybride filaire/sans fil.

3.5.2 Notre mécanisme TCP-Friendly pour le contrôle de congestion

Nous proposons un nouveau mécanisme qui se base sur PLB pour la transmission multipoint dans les réseaux IEEE 802.11 et utilise LDA+ pour adapter le débit de transmission physique afin de permettre d'améliorer la transmission dans un réseau IP hybride filaire/sans fil. Nous avons utilisé LDA+ car il utilise les paquets RTCP spécifier dans le RFC 3550 et qui est implémenter dans le simulateur OMNET++. Ce mécanisme contient deux boucles de contrôle : la première entre les points d'accès et les stations membre des groupes multipoint et la deuxième est l'adaptation du débit en fonction des conditions de réception. Nous proposons d'introduire un nouvel agent entre les

deux types de réseaux pour discriminer entre les pertes dans le réseau filaire et celles dans le réseau sans fil.

3.5.2.1 Le comportement de la source vidéo

Comme toute session multipoint, chaque station reçoit un message RTCP (SR) généré par la source vidéo, calcule son taux de pertes, construit son message RTCP (RR) et l'envoie à l'agent. Après la réception de ses rapports par l'agent, ce dernier génère son message (RR) et l'envoie à la source vidéo. Enfin, la source vidéo adapte son débit de transmission vidéo en fonction du rapport reçu de l'agent. Pour ce fait, la source utilise les valeurs Fractionloss, DLSR et LSR du rapport d'agent et calcule la bande passante disponible à l'aide de LDA+. La figure 3.2 montre les différents messages

FIG. 3.2 - Messages RTCP échangées entre le réseau filaire/sans fil échangés entre la source vidéo, l'agent et les stations mobiles.

3.5.2.2 Le comportement de l'agent

L'agent génère les rapport RTCP (RR) et les envoie à la source vidéo pour qu'elle adapte son débit de transmission suivant l'état de réception des stations mobiles. Il estime l'état de chaque station (perte de paquets, délai) périodiquement qui correspond

à la réception d'un rapport SR. Les stations mobiles dans le réseau local renvoient périodiquement leur rapport RR contentant le taux de pertes (fraction loss), l'instant de l'envoie du dernier du SR (LSR) et la période entre la réception du SR et la génération du RR (DLSR).

Concernant le paramètre taux de pertes, il est très important de distinguer entre les pertes de congestion et celle due à la mauvaise condition de réception. Notons que la station qui a le taux de pertes le plus faible est celle qui a la meilleure condition de réception. Le taux de pertes des stations mobiles contient les pertes communes comme la congestion dand le réseau Internet, la congestion au niveau des point d'accès, les collisions dans le réseau IEEE 802.11, et d'autres pertes individuelles qui sont des pertes due aux mauvaises conditions de réception. Dans notre approche, l'agent utilise la valeur de taux de pertes la plus faible comme estimation de pertes de congestion.

Concernant maintenant l'estimation du délai aller-retour, comme l'agent est placé entre le réseau filaire et le réseau sans fil, il peut aider à estimer le temps RTT entre la station mobile et la source vidéo. Dans notre approche, l'agent prend la valeur de RTT de la station qui a le taux de perte le mois élevé.

Pour ce faire, L'agent sauvegarde l'instant de la réception du RTCP (SR) reçu du la source vidéo TSR et le temps de réception du RTCP (RR) de la station TRR. Ensuite, le temps d'aller retour entre l'agent et l'émetteur RTT vaut:

Avec t le temps de l'envoie du RR, LSR le tems de l'envoie du rapport SR du la source, DLSR le temps entre ma réception du SR et l'envoie du RR et enfin RTT le temps d'aller retour entre l'agent et la station qui a le taux de perte le moin élevé.

3.6 Evaluation de performances

Pour évaluer notre mécanisme, nous avons utilisé une version INET du simulateur OMNET++. Notre version de INET est disponible sur [33]. Dans les simulations suivantes, nous avons utilisés le modèle shadowing comme modèle de propagation avec les paramètres spécifiés dans le tableau 3.1.

Notre scénario correspond à un musée contenant 3 salles (40m x 40m) et un point d'accès placé au milieu de la salle. 3 stations mobiles qui correspondent à 3 visiteurs se déplaçant dans la salle de manière linéaire. La vitesse et temps de pause et période de mouvement sont des variables aléatoires qui suivent une loi uniforme. La vitesse de la station est entre 2m/s et 4m/s, la période de pause entre 2 et 7secondes et le temps de déplacement entre 1 et 4s.

Les point d'accès et les stations mobiles utilise ARF [7] comme algorithme d'adaptation de débit. Comme l'indique la figure 3.2 la source vidéo est placé en dehors du musée, connecté à l'aide d'un connexion IP (1Mbps/10ms). L'agent est connecté au même hub que les points d'accès. Dans ce scénario, La source utilise LDA+ pour adapter le débit de transmission physique. Chaque station reçoit le flux multipoint et un autre flux TCP. Nous comparons la performance de PLB/LDA+ par rapport à la per-

FIG. 3.3 - Le taux de pertes pour LDA+/PLB et CBR/Legacy dans un réseau congestionné

formance du multicast standard/CBR en les simulant avec le même scénario. La figure 3.3 montre le taux de pertes applicatif observé dans les deux mécanismes pour les deux stations : celle qui a la meilleur condition de réception et celle du cas pire.

On peut observer que le mécanisme LDA+/PLB obtient en moyenne la moitié en taux de pertes que la transmission multipoint standard. Les autres pertes (2-3%) sont due à la congestion dans le réseau filaire puisque PLB permet de retransmettre le paquet perdus dans la partie sans fil.

3.7 Conclusion

Ce chapitre a été consacré à l'étude de la congestion dans les réseaux Internet. Nous avons présenté le contrôle de congestion pour les applications point-à-point et multipoint. Nous avons proposé un nouveau mécanisme permettant de contrôler le débit de transmission dans un scnarrio hybrid filaire/sans fil. Dans une dernière partie de ce chapitre nous avons présenté les résultats de nos simulations et nous avons étudié les performances de notre approche.

Conclusion

Le succès grandissant des applications multimédia sur l'Internet rend indispensable l'amélioration de la diffusion vidéo dans les réseaux 802.11. À cet effet, la méthode de diffusion multipoint avec l'élection d'un leader apporte plusieurs améliorations permettant d'enregistrer de nouveaux progrès dans la diffusion de la vidéo sur les réseaux sans fil. En outre, elle adapte le débit physique suivant l'état du support de transmission et retransmet au niveau de la couche MAC les paquets perdus. Nous avons montré que notre nouveau protocole PLB permet de réduire les pertes dans les réseau IEEE 802.11 et de garantir plus d'équité avec les flux point-à-point concurrents.

Dans une deuxième partie de notre rapport nous avons proposé un nouveau mécanisme permettant d'adapter le débit de transmission multipoint dans le cas d'un scénario hybride filaire/sans fil. Nous avons validé nos solutions à l'aide des simulations. Nos simulations sont réalisées à l'aide du simulateur OMNET++.

Ce projet nous a permis de toucher à la réalité du travail dans un laboratoire de recherche. Nous avons appris à considérer les notions d'un oeil critique afin de vouloir toujours améliorer, toujours essayer de changer et d'innover. Cette expérience est la première dans notre jeune formation, elle fût réussie à plusieurs points de vue. Sur le plan concret, ce projet nous a offert l'occasion de programmer en C++, décortiquer la norme IEEE 802.11 et les protocoles temps réels RTP et RTCP, implémenter de nouveaux protocoles et simuler quelques exemples de scénarios.

Bibliographie

Wireless Networks" Graphical Models and Image processing,(60) :pages 125-135, 1998.