Reliable Multicast transport of the video over the WiFi network. (Transport Multicast fiable de la vidéo sur le réseau WiFi)

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.