The Impact of the Reliability on the Fairness Between the Unicast and the Multicast in Highly Loaded WLANs

International audienceOne of the major issues experienced by the IEEE 802.11 standard is the fair sharing of the channel between unicast and multicast flows. This problem is obviously caused by the use of the smallest Contention Window size to transmit the multicast packets compared to an exponentially incremented size for every unicast packet transmission retry. This pattern is due mainly to the reliability degree difference between the unicast and the multicast traffic. Currently, the unicast uses feedbacks to provide reliability, whereas the multicast does not rely on such a mechanism and is therefore considered as unreliable. In this paper we propose a reliable Multicast flow transport proposal called the Reliable PLCP-based Multicast Protocol (RPMP) and we study its impact on the fair channel sharing with unicast flows in high-load conditions. We show that RPMP solves the issues of the legacy multicast

Reliable Multicast transport of the video over the WiFi network

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.The multicast transport is an efficient solution to deliver the same content to many receivers at the same time. This mode is mainly used to deliver real-time video streams. However, the conventional multicast transmissions of IEEE 802.11 do not use any feedback policy. Therefore missing packets are definitely lost. This limits the reliability of the multicast transport and impacts the quality of the video applications. To resolve this issue, the IEEE 802.11v/aa amendments have been defined recently. The former proposes the Direct Multicast Service (DMS). On the other hand, 802.11aa introduces Groupcast with Retries (GCR) service. GCR defines two retry policies: Block Ack (BACK) and Unsolicited Retry (UR).In this thesis we evaluate and compare the performance of 802.11v/aa. Our simulation results show that all the defined policies incur an important overhead. Besides, DMS has a very limited scalability, and GCR-BACK is not appropriate for large multicast groups. We show that both DMS and GCR-BACK incur important transmission latencies when the number of the multicast receivers increases. Furthermore, we investigate the loss factors in wireless networks. We show that the device unavailability may be the principal cause of the important packet losses and their bursty nature. Particularly, our results show that the CPU overload may incur a loss rate of 100%, and that the delivery ratio may be limited to 35% when the device is in the power save mode.To avoid the collisions and to enhance the reliability of the multicast transmissions, we define the Busy Symbol (BS) mechanism. Our results show that BS prevents all the collisions and ensures a very high delivery ratio for the multicast packets. To further enhance the reliability of this traffic, we define the Block Negative Acknowledgement (BNAK) retry policy. Using our protocol, the AP transmits a block of multicast packets followed by a Block NAK Request (BNR). Upon reception of a BNR, a multicast member generates a Block NAK Response (BNAK) only if it missed some packets. A BNAK is transmitted after channel contention in order to avoid any eventual collision with other feedbacks, and is acknowledged. Under the assumption that 1) the receiver is located within the coverage area of the used data rate, 2) the collisions are avoided and 3) the terminal has the required configuration, few feedbacks are generated and the bandwidth is saved. Our results show that BNAK has a very high scalability and incurs very low delays. Furthermore, we define a rate adaptation scheme for BNAK. We show that the appropriate rate is selected on the expense of a very limited overhead of less than 1%. Besides, the conception of our protocol is defined to support the scalable video streaming. This capability intends to resolve the bandwidth fluctuation issue and to consider the device heterogeneity of the group members.BORDEAUX1-Bib.electronique (335229901) / SudocSudocFranceF