1. Experimental Study on Wireless Multicast Scalability using Merged Hybrid ARQ with Staggered Adaptive FEC S. Makharia, D. Raychaudhuri, M. Wu*, H. Liu*, D. Li* WINLAB, Rutgers University *Thomson Inc. WoWMoM 2008

2. Contents Introduction Hybrid ARQ Motivation Proposed scheme: MHARQ System Architecture Algorithm Test results Conclusion Video quality results (left: w/ proposed scheme, right: w/o proposed scheme)

3. Introduction Real-time multimedia multicast over WLAN –Live TV, news, sports etc. Wireless channel suffers from multi-path fading and interference. –Random errors –Burst packet loss Error correction schemes to improve reliability: –Forward error correction (FEC) Lower FEC may cause poor protection Higher FEC may cause more overhead –Automatic repeat request (ARQ) Long round trip time delay for recovery Feedback explosion problem for multicast ARQ

4. Hybrid ARQ A way to combine the ARQ and FEC. Higher throughput than FEC Example –A. Majumdar, D. Grobe Sachs, I.V. Kozintsev, K. Ramchandran, and M. Yeung, ”Multicast and Unicast Realtime Video Streaming Over Wireless LANs,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 12, no. 6, June 2002

5. Motivation: Scalability Problem HARQ is more bandwidth efficient than FEC if there is only one AP. If there are multiple APs, it may have scalability issue. –A receiver at AP1 requires a lot of retx. –Another receiver at AP2 requires only few retx. –The server must retx FEC packets to meet the requirement of AP1. –AP2 also relays these FEC packets over its wireless link. This is because the retx in HARQ is controlled by means of a central controller (the video server).

6. Other approaches ARQ proxy at each AP –Introduce complexity in the AP –AP modification required Let each AP have its own ARQ multicast group –How to handle handoffs? –Extra signaling required –Not scalable to # of APs

7. MHARQ Propose Merged Hybrid ARQ system with staggered FEC (MHARQ) to achieve better scalability and bandwidth efficiency. Contributions 1.Proposing MHARQ a new and improved adaptive system for reliable video multicast over wireless LANs. 2.Proposing a client S/W architecture integrate the FEC functionality w/o changing the existing video player code 3.Addressing backward compatibility issues 4.Using experiments to investigate reliability, scalability, and bandwidth efficiency compare the performance with the existing video multicast system.

8. Cross Packet FEC In a MHARQ system, FEC packets for a source stream are divided into multiple layers, and each layer is transmitted in a different multicast group. 3 types of FEC groups: –Non-delayed FEC group: sent as soon as they are generated. –Delayed FEC group: TX is delayed by a configurable time. –ARQ FEC group: sent according to the NACK from the clients.  A client joins one or more Non-delayed FEC groups.  A client dynamically joins/leaves the delay FEC groups if non-delayed FEC packets are not enough to recover.  A client sends the NACK, and joins the corresponding ARQ FEC groups, if delayed FEC packets are not enough.  A client joins one or more Non-delayed FEC groups.  A client dynamically joins/leaves the delay FEC groups if non-delayed FEC packets are not enough to recover.  A client sends the NACK, and joins the corresponding ARQ FEC groups, if delayed FEC packets are not enough.

9. Server Side Architecture Video Server –FEC module: FEC packets are generated –Delay Buffer: Additional FEC is stored –UDP/IP/Ethernet: Data forwarding ARQ Server –HARQ operations: retranmit FEC or source packets when a NACK arrives

10. Client Side Architecture FEC decoding problem –Commercial and freeware video players do not support FEC. FEC Proxy –receives source and FEC packets from different multicast groups –recovers lost packets –sends the recovered video packets to the player through an internal socket.

11. Design issues on FEC Codec Support a multicast scenario with mixed FEC capable and non-FEC capable receivers –original RTP source packets are unchanged –non-FEC capable legacy players can just receive source multicast group. Use different FEC block size for video and audio –Different media tracks have different bit rate (normally, video rate > audio rate) –If we use the same FEC block size for audio/video tracks on encoding, we’ll have audio/video synchronization problem at the receiver. –Hard to have variable size due to complexity. –To improve encoding/decoding efficiency, max k and max n are fixed for all (n, k) codewords.

12. Adaptive MHARQ Algorithm (1/4) multicast session : media group = 1 : 1 media group : media track = 1 : N Media track : FEC group = 1 : N Assumptions –(m+1) FEC groups –group(0) is non-delayed FEC group. –group(1)-group(m-1) are delayed FEC groups. –group(m) is ARQ FEC group. –All clients will always join the source group and group(0). –Each client records avg_loss_rate and avg_variance.

13. Adaptive MHARQ Algorithm (2/4) IF a client has already received successfully, THEN –it does not have to join any new FEC groups or send an ARQ request. ELSE –it needs to receive extra redundant parity packets. –How to decide the number of FEC groups to join –Two solutions: Join all groups at one time Incremental joining

14. Adaptive MHARQ Algorithm (3/4) First solution: join G groups at one time. –The number of packets needed can be estimated by –The number of groups that client needs to join would be –Specify the duration that it would remain joined to this group:

15. Adaptive MHARQ Algorithm (4/4) Second solution: incremental joining. –The client first joins one additional delayed FEC group and a timer is set to expire that FEC group:

16. Test Environment Test on ORBIT LinkSys AP Microsoft Windows XP clients using QuickTime player Compare 3 error recovery schemes: –Staggered adaptive FEC (SAFEC) –Hybrid ARQ (HARQ) –Merged Hybrid ARQ (MHARQ)

17. Experiment Setup on ORBIT Multicast group overhead in percentage

18. Overhead Incurred by Clients on AP1 and AP2 Client on AP1 –bad channel Client on AP2 –good channel HARQ shows the same overhead in AP1 and AP2  not scalable SAFEC & MHARQ scale well SAFEC shows high overhead on bad channels MHARQ performs well on both channels

19. Scalability Test on ORBIT How would MHARQ system behave under a hotspot environment ? Choose 60 nodes on the ORBIT grid as clients AP is placed in the middle Noise injection from the four corners

20. Comparison of Packet Loss Overhead < 12% Loss rate < 0.1%

21. Overall Gains Overhead vs. noise power Correctly received vs. noise power

22. Conclusion One of 13 noteworthy contributions in WoWMoM 2008. Weakness –More playback delay and buffers may be required. –Not scalable to the number of multicast sessions. –IGMP join/leave latency problem –Only one AP is used for scalability test on ORBIT; HARQ may perform better.