Design of Efficient Multicast Protocol for IEEE 802.11n WLANs and Cross-Layer Optimization for Scalable Video Streaming

Abstract

The legacy multicasting over IEEE 802.11-based WLANs has two well-known problems-poor reliability and low-rate transmission. In the literature, various WLAN multicast protocols have been proposed in order to overcome these problems. Existing multicast protocols, however, are not so efficient when they are used combining with the frame aggregation scheme of IEEE 802.11n. In this paper, we propose a novel MAC-level multicast protocol for IEEE 802.11n, named Reliable and Efficient Multicast Protocol (REMP). To enhance the reliability and efficiency of multicast services in IEEE 802.11n WLANs, REMP enables selective retransmissions for erroneous multicast frames and efficient adjustments of the modulation and coding scheme (MCS). In addition, we propose an extension of REMP, named scalable REMP (S-REMP), for efficient delivery of scalable video over IEEE 802.11n WLANs. In S-REMP, different MCSs are assigned to different layers of scalable video to guarantee the minimal video quality to all users while providing a higher video quality to users exhibiting better channel conditions. Our simulation results show that REMP outperforms existing multicast protocols for normal multicast traffic and S-REMP offers improved performance for scalable video streaming.

Experimental Evaluation of a Scalable WiFi Multicast Scheme in the ORBIT Testbed

“…Other studies propose rate adaptation mechanisms for improving network utilization [18]. In all cases, a key requirement is having appropriate feedback from receivers regarding the quality of the experienced multicast services.…”

“…(iv) Leader-Based Protocol with Negative Acknowledgements (LBP-NACK): The LBP-NACK approach [12], [18], [22] improves Pseudo-Broadcast by allowing the non-leaders to send NACKs for lost packets. The LBP-NACK approach not only requires changes to the standard, but also suffers from lack of reliability as a non-leader cannot reply with a NACK if it cannot identify a corrupted packet.…”

“…Since changing the bit-rate in the ath5k driver leads to changes in the MCS of beacon messages as well, this disconnection can be partially mitigated by modifying the driver to transmit beacons at 6 Mbps. Some nodes farther away from the AP also report low PDR values, e.g., node at position (18,4). This effect arises from the extremely static environment of the indoor testbed which results in standing waves and destructive interference at some locations.…”

Experimental evaluation of large scale WiFi multicast rate control

“…The leader acknowledges the reception of the unicast flow while the other receivers receive packets by listening to the channel in promiscuous mode. (iv) The Leader-Based Protocol with negative acknowledgements (LBP-NACK) [32], [44], [50] method improves PseudoBroadcast by allowing the other receivers to send NACKs for lost packets. The leader based approaches (ii)-(iv) cannot provide guarantees on the feedback accuracy [10], [38].…”

“…In [44] when the channel conditions are stable, RA is conducted based on reports of a single leader. When the channel conditions are dynamic, feedback is collected from all nodes.…”