La plateforme d’expérimentation

Pour comparer les performances des différents niveaux de fragmentation, nous avons exécuté des tests réels en nous basant sur une plateforme d’expérimentation illustrée dans la Figure 5-2. La plateforme comprend deux réseaux 802.11 en mode infrastructure « IPTV WLAN » et « IPERF WLAN ». Les deux réseaux utilisent le même canal de transmission numéro 1. En effet, Afin d’éviter les interférences inter-canaux, les réseaux 802.11 peuvent utiliser trois canaux suffisamment espacés : les canaux numéro 1, 6 et 11 (voir section 2.2.1.1). Le canal 11 étant exploité par le réseau WiFi du laboratoire, nous avons décidé d’utiliser le canal numéro 1 pour nos expérimentations.

Figure 5-2 : La plateforme d'expérimentation

Le réseau « IPTV WLAN » est composé du XLAG et d’une station « IPTV STA ». D’une manière similaire, le réseau « IPERF WLAN » est composé d’un « IPERF AP » et d’une station « IPERF STA ». La disposition des deux réseaux est inversée comme l’illustre la Figure 5-2. Le XLAG est situé du côté de « IPERF STA » et le « IPERF AP » du côté de « IPTV STA ». Le Tableau 5-1 détaille les caractéristiques techniques des deux réseaux.

IPTV WLAN IPERF WLAN Chipset WiFi/driver AP/STA : Atheros / Madwifi AP/STA : Atheros / Madwifi

Norme 802.11g 802.11b

Débit physique 36 Mbits/s 1Mbits/s

Nombre de retransmissions au

niveau MAC ^{5 fois 5 fois}

Taille de la file d’attente au niveau

MAC ^{50 trames 50 trames} Tableau 5-1 : Les caractéristiques techniques des réseaux 802.11

Le réseau « IPTV WLAN » permet la transmission d’un flux vidéo du « XLAG » vers le « IPTV STA » et le réseau « IPERF WLAN » permet la transmission d’un flux UDP du « IPERF AP » vers le « IPERF STA ». Pour cela, le réseau « IPERF WLAN » utilise l’outil IPERF [211] qui permet de générer du trafic réseau UDP ou TCP en contrôlant plusieurs paramètres, comme le débit et la taille des paquets. Le trafic généré par le réseau « IPERF WLAN » sur le même canal de transmission provoque des interférences pour le réseau « IPTV WLAN ».

Afin de pouvoir comparer les résultats des tests, la même séquence vidéo est utilisée pour le streaming vidéo. Le Tableau 5-2 résume les caractéristiques de cette séquence vidéo.

Format de Codage MPEG-4

La taille d’un GOP 12

Structure d’un GOP IBBPBBPBBPBB

Résolution CIF : 352x288 pixels

Nombre d’images par seconde 25 fps

Débit moyen/max/min 439/608/328 Kbits/s

Durée de la séquence 240 secondes

Tableau 5-2 : Les caractéristiques de la vidéo de référence

5.2.2.5 Tests et évaluations de performance

Les tests consistent à transmettre simultanément un flux vidéo dans le réseau « IPTV WLAN » et un flux UDP dans le réseau « IPERF WLAN ». Afin de démontrer l’avantage de la fragmentation et de comparer les différents niveaux de fragmentation détaillés dans les sous-sections précédentes, nous avons défini quatre scénarios d’expérimentations. Dans chaque scénario, le XLAG exécute un niveau de fragmentation qui change la taille des trames MAC pour le flux vidéo. Ces scenarios sont présentés ci-dessous :

• No fragmentation : Ce scenario utilise des paquets de taille standard sans aucune fragmentation. La taille d’une trame MAC est inférieure ou égale à 1512 octets

• Application (APP) fragmentation : Dans ce scenario, les paquets RTP sont réduits pour avoir une taille de trame MAC inférieure ou égale à 512 octets.

• Network (NET) fragmentation : Dans ce scenario, le MTU est réduit pour avoir une taille de trame MAC inférieure ou égale à 512 octets.

• MAC (MAC) fragmentation : Ce scenario utilise la fragmentation 802.11 au niveau MAC. La taille du fragment est limitée à 512 octets.

La durée d’une expérimentation est de 240 secondes. Durant l’intervalle [60s, 180s], le « IPERF AP » transmet vers le « IPERF STA » un trafic UDP avec un débit fixe de 300 Kbits/s. Les trames MAC dans le réseau « IPERF WLAN » possèdent une taille fixe de 1512 octets. Dans chaque scénario, nous avons exécuté dix tests. Nous nous intéressons pour chaque scénario au taux de perte et au débit vidéo réalisés.

Les Figures 5-3 et 5-4 illustrent un exemple des résultats obtenus tout au long d’un test dans chaque scénario. Elles donnent respectivement les taux de perte RTCP et le débit d’émission du flux vidéo au niveau MAC pour les différents scénarios. Dans la Figure 5-3, nous remarquons, clairement, l’effet des interférences introduit par le réseau « IPERF WLAN » dans l’intervalle [60s, 180s]. Dans la Figure 5-4, nous distinguons la différence du débit vidéo au niveau MAC pour les quatre scénarios.

0 5 10 15 20 25 30 35 40 45 0 50 100 150 200

Packet loss ratio (%)

Time (s)

No fragmentation Application fragmentation Network fragmentation MAC fragmentation

Figure 5-3 : Les taux de perte RTCP d’un test dans chaque scénario

300 400 500 600 700 800 0 50 100 150 200 Throughput(Kbps) Time (s) No fragmentation Application fragmentation Network fragmentation MAC fragmentation

460 480 500 520 540 No frag Application frag Network frag MAC frag Throughput(Kbps) 0 2 4 6 8 10 12 14 No frag Application frag Network frag MAC frag Loss ratio (%)

Figure 5-5 : Le débit moyen d’émission des dix tests dans chaque scénario

Figure 5-6 : Le taux moyen de perte des dix tests dans chaque scénario

Les Figures 5-5 et 5-6 donnent respectivement le taux moyen de perte et le débit moyen d’émission pour le flux vidéo au niveau MAC des dix tests dans chaque scénario. Ces moyennes ont été calculées durant la période d’interférence [60s, 180s].

Le taux élevé de perte, 12.1 %, est enregistré par le premier scenario « no fragmentation ». Les pertes diminuent avec le troisième scénario « Network fragmentation » pour atteindre une moyenne de 4.6 %. Cette moyenne atteint les 0.2 % dans le deuxième scénario « Application fragmentation » et elle est nulle dans le dernier scénario « MAC fragmentation » qui n’enregistre aucune perte durant cette période d’interférence.

Afin d’expliquer ces résultats, nous rappelons que les interférences provoquent la perte des trames MAC qui peuvent être supprimées à deux niveaux distincts :

• Au niveau de la couche MAC du récepteur : Cette suppression est due à l’altération de quelques bits dans la trame MAC durant la transmission, ce qui provoque sa suppression durant la vérification du champ CRC de la couche MAC ou de la couche Physique.

• Au niveau de la couche MAC de l’émetteur : Cette suppression est causée par une surcharge de la file d’attente MAC au niveau de l’émetteur. En effet, un niveau d’interférence élevé dans un canal peut être interprété dans l’algorithme d’accès DCF comme étant un canal occupé. Ceci fait augmenter le temps d’attente d’une trame à cause des attentes successives DIFS pour la libération du canal. Par conséquent, le taux d’occupation de la file d’attente au niveau MAC augmente et lorsque ce taux dépasse un certain seuil, les trames MAC sont supprimées.

Dans le premier test « No fragmentation », la taille des trames étant de 1512 octets, le taux de perte élevé (12.1%) des paquets peut être expliqué par la suppression conjointe des trames au niveau de la couche MAC de l’émetteur et du récepteur.

Par contre dans les autres scénarios « Application fragmentation », « Network fragmentation » et « MAC fragmentation » la même taille de trame MAC (512 octets) est utilisée mais les moyennes des taux de perte diffèrent. Nous commençons par expliquer la différence des taux de perte entre les deux scénarios « Application fragmentation » et « Network fragmentation ». Ensuite, nous expliquons pourquoi les pertes s’annulent dans le dernier scénario « MAC fragmentation »

Ces deux informations : (1) une taille de trame identique et (2) une moyenne des taux de perte différente pour le « Application fragmentation » et « Network fragmentation » permettent d’affirmer

que la différence dans les taux de perte n’est pas provoquée par la corruption des trames parce que la corruption d’une trame est en relation directe avec sa taille. Ainsi, la différence peut être provoquée uniquement par la suppression de ces trames au niveau de l’émetteur à cause de la surcharge de la file d’attente MAC. Les pertes sont plus élevées dans le scénario « Network fragmentation », comparé au scénario « Application fragmentation » pour deux raisons principales: • La première raison se résume dans le fait que la fragmentation au niveau réseau « Network

fragmentation » augmente le nombre des fragments IP qui sont transmis à la couche MAC. Cette dernière n’arrive pas à transmettre tous ces fragments qui sont stockés dans sa file d’attente. Puisque les files d’attente sont gérées en nombre de trames (50 trames dans notre plateforme de test) et non pas en nombre d’octets. La file d’attente est rapidement surchargée et supprime, par conséquent, des fragments IP. Ce cas de figure ne se produit pas dans le scénario « Application fragmentation » bien que le nombre de paquets RTP soit aussi important. Ces paquets RTP sont stockés dans la file d’attente de la couche IP qui a une taille plus grande. Ceci signifie que la charge que subisse la file d’attente MAC dans le scénario « Network fragmentation » est déplacée vers la file d’attente IP dans le scénario « Application fragmentation », cette dernière arrivant à absorber les paquets RTP.

• La deuxième raison se résume dans le faite que les taux de perte recueillis durant les tests sont les taux de perte des paquets RTP calculés au niveau du récepteur et envoyés dans les rapports RTCP vers l’émetteur. Dans le scenario « Network fragmentation » un paquet RTP peut être fragmenté en plusieurs fragments IP. La perte d’un de ces fragments provoque la perte de tout le paquet RTP. Par contre, dans le scenario « Application fragmentation » c’est la taille du paquet RTP qui est réduite. Ceci évite de détruire des paquets correctement reçus et permet, par la même, de réduire les taux de perte. Par exemple, si une image vidéo est découpée en 3 paquets RTP avec une taille de trame MAC de 1512 octets et 9 paquets avec une trame MAC de 512 octets, la perte d’un fragment dans le scénario « Network fragmentation » génère un taux de perte de 1/3, mais la perte d’un fragment dans le scénario « application fragmentation » génère un taux de perte de 1/9.

Les pertes s’annulent complètement dans le dernier scenario « MAC fragmentation » puisque la fragmentation 802.11 au niveau MAC se base sur le « fragment burst » qui transmet tous les fragments en une seule fois sans relâcher le contrôle du canal de transmission. Ceci réduit considérablement le temps d’attente des trames MAC dans la file d’attente, ce qui évite, par la même, sa surcharge et la suppression de ces trames.

Concernant le débit du flux vidéo au niveau de la couche MAC présenté dans la Figure 5-5. Les résultats sont compréhensibles. Plus le niveau de fragmentation est élevé, plus le débit du flux vidéo augmente. Ainsi, le débit est plus élevé dans le scénario « Application fragmentation » parce que les en-têtes RTP (12 octets), UDP (8 octets), IP (20 octets), LLC (8 octets), MAC (34 octets), PHY (24 octets) sont dupliqués dans chaque fragment d’image. Le débit le plus faible est réalisé par la fragmentation MAC puisque seule les en-têtes MAC et PHY sont dupliqués.

Cette étude démontre clairement que la fragmentation au niveau MAC 802.11 offre de meilleures performances de transmission puisque elle évite la suppression des trames MAC aussi

bien au niveau émetteur qu’au niveau récepteur. De plus, elle permet de réduire l’overhead des en-têtes parce qu’elle représente le dernier niveau d’encapsulation des données.