Transport Multicast fiable de la vidéo sur le réseau WiFi

Abstract

Le transport multicast est une solution efficace pour envoyer le même contenu à plusieurs récepteurs en même temps. Ce mode est principalement utilisé pour fournir des flux multimédia en temps réel. Cependant, le multicast classique de l’IEEE 802.11 n'utilise aucun mécanisme d’acquittement. Ainsi, l’échec de réception implique la perte définitive du paquet. Cela limite la fiabilité du transport multicast et impact la qualité des applications vidéo. Pour résoudre ce problème, 802.11v et 802.11aa sont définis récemment. Le premier amendement propose Direct Multicast Service (DMS). D'autre part, le 802.11aa introduit GroupCast with Retries (GCR). GCR définit deux nouvelles politiques de retransmission : Block Ack (BACK) et Unsolicited Retry (UR).Dans cette thèse, nous évaluons et comparons les performances de 802.11v/aa. Nos résultats montrent que tous les nouveaux protocoles multicast génèrent un overhead de transmission important. En outre, DMS a une scalabilité très limitée, et GCR-BACK n'est pas approprié pour des grands groupes multicast. D’autre part, nous montrons que DMS et GCR-BACK génèrent des latences de transmission importantes lorsque le nombre de récepteurs augmente. Par ailleurs, nous étudions les facteurs de pertes dans les réseaux sans fil. Nous montrons que l'indisponibilité du récepteur peut être la cause principale des pertes importantes et de leur nature en rafales. En particulier, nos résultats montrent que la surcharge du processeur peut provoquer un taux de perte de 100%, et que le pourcentage de livraison peut être limité à 35% lorsque la carte 802.11 est en mode d’économie d'énergie.Pour éviter les collisions et améliorer la fiabilité du transport multicast, nous définissons le mécanisme Busy Symbol (BS). Nos résultats montrent que BS évite les collisions et assure un taux de succès de transmission très important. Afin d'améliorer davantage la fiabilité du trafic multicast, nous définissons un nouveau protocole multicast, appelé Block Negative Acknowledgement (BNAK). Ce protocole opère comme suit. L’AP envoi un bloc de paquets suivi par un Block NAK Request (BNR). Le BNR permet aux membres de détecter les données manquantes et d’envoyer une demande de retransmission, c.à.d. un Block NAK Response (BNAK). Un BNAK est transmis en utilisant la procédure classique d’accès au canal afin d'éviter toute collision avec d'autres paquets. En plus, cette demande est acquittée. Sous l'hypothèse que 1) le récepteur est situé dans la zone de couverture du débit de transmission utilisé, 2) les collisions sont évitées et 3) le terminal a la bonne configuration, très peu de demandes de retransmission sont envoyées, et la bande passante est préservée. Nos résultats montrent que BNAK a une très grande scalabilité et génère des délais très limités. En outre, nous définissons un algorithme d'adaptation de débit pour BNAK. Nous montrons que le bon débit de transmission est sélectionné moyennant un overhead très réduit de moins de 1%. En plus, la conception de notre protocole supporte la diffusion scalable de lavvidéo. Cette caractéristique vise à résoudre la problématique de la fluctuation de la bande passante, et à prendre en considération l'hétérogénéité des récepteurs dans un réseau sans fil.