Feedback-jamming ARQ mechanisms

1. Feedback-jamming ARQ mechanisms Authors: Date: 2009-03-09 Jochen Miroll et al., Saarland University

2. Abstract • NACK-jamming leader based Multicast • Comparison with ACK polling • Pros and Cons • HLBP: Hybrid leader based Multicast protocol • Evaluation criteria (cf. 08/1093r0) • Summary Jochen Miroll et al., Saarland University

3. Glossary ACK-polling AP collects indivudial ACK from each STA LBP Leader-Based Protocol NACK-jamming enforced collision of leader-ACK with non-leader NACK Synchronisation of Multicast STAs, event-driven or clocked HLBP Hybrid (w.r.t. coding) LBP Jochen Miroll et al., Saarland University

4. NACK jamming Leader Based Protocol optional SEQ# indicator and NAV updater to synchronize jamming Jochen Miroll et al., Saarland University

5. NACK-jamming vs. Block-ACK polling NACK-jamming and ACK-polling Jochen Miroll et al., Saarland University

6. NACK jamming LBP summary (1) • Pros • Scalability: Depending on SEQ# signalling overhead • Our simulation shows an example for 10-Block-ACK vs. 25 STAs • From a latency PoV: Maximum delay is constant • Determined by (pre-configured) number of retransmission rounds, independent of number of STAs • Event driven, distributed, optimal feedback • NACK+ACK at the same time • Requires less strict synchronisation as compared to ACK-polling • Purposely jamming the ACK is enforcing a collision – synchronisation need not be as strict as for TDMA, see next slide Jochen Miroll et al., Saarland University

7. Block ACK Req Block ACK Block ACK Block ACK NACK NACK ACK Synchronisation: jamming vs. ACK Collision, Fail! Jamming SIFS SIFS AP1 STA 1 (leader) STA r-1 STA r Block Polling NACK Jamming Jochen Miroll et al., Saarland University

8. NACK jamming LBP summary (2) • Cons • NACK-jamming still requires synchronisation of individual STAs • But: If a STA is e.g. “too slow” to jam, it does not affect the others • Scalability may not be an issue at home • But: Other use-cases exist: large audience video broadcast, e.g. at public places like airports, etc. • LBP: How to select the leader? • But: ACK polling also requires knowledge at STAs about ACK sequence => Either mechanism requires some additional signalling • Not applicable for blocks of frames • But: This may be compensated by increased scalability • Residual packet error rate (PER) (loss at each STA) unknown • ACK-polling could count #ACKs from each STA Jochen Miroll et al., Saarland University

9. Increasing NACK-jamming efficiency: HLBP • NACK-jamming destroys „positive information“ • Block-NACK (similar to Block-ACK) is thus not possible • Solution: Apply FEC to a block and • Transmit block of frames • Assume at least one STA did not receive at least one frame in block => ACK gets jammed • Transmit FEC parity frames • STAs try to recover the data from the frames + parity they received • Repeat 2. until ACK does not get jammed anymore (or some retry limit reached) • Problem solved, Block-NACK-jamming possible: • The use of parity for retransmission eliminates the need for positive info Jochen Miroll et al., Saarland University

10. HLBP* Phase I Transmit a block of frames, similar to block-ACK Phase II Replace actual block-ACK phase with parity-NACK phase * A rateless FEC code is assumed in the figure, for e.g. for RS, parity would be parity OR data Jochen Miroll et al., Saarland University

11. HLBP vs. Block-ACK polling Jochen Miroll et al., Saarland University

12. Evaluation criteria (cf. 08/1093r0) • Flexibility of number of STAs in a group • ACK-polling may be highly reliable (even the exact residual PER can be determined) and efficient for small audiences (including 5-10 STAs) • NACK-jamming scales better (no limit on the size of the audience) but is less reliable (residual PER unknown, may even be perfectly unreliable for some STAs) • Flexibility in the number of simultaneously active multicast streams • We propose to have both ACK and NACK scheme, choose one for each MC group individually depending on the requirements • Each STA receives a QoS comparable to a single stream unicast with limited retries • Delay: w.r.t audience size: Const. for NACK-jamming • Jitter: We believe it is not a major issue of the retransmission scheme (power-saving / time-slot management and the OS largely affect jitter) Jochen Miroll et al., Saarland University

13. Evaluation criteria (cf. 08/1093r0) • Should make efficient use of the wireless medium, as video bandwidths can be high • Probably good: to use a NACK scheme for „video“, ACK for „voice“ • Flexible support for traffic shaping of video transmissions and power saving • Again, flexibility by switching/selection between ACK/NACK scheme • Compatible with legacy non-11aa STAs • HLBP not backwards-compatible, but assume plain NACK-jamming is • Provide support for duplicate detection • Proposed NACK schemes require SEQ# to work • Provide a mechanism to support rate adaptation • NACK-jamming could even use unicast rate adaptation mechanism • Provides a mode of operation that minimises the potential for requiring hardware modifications • Provides a mode of operation that supports collision avoidance Jochen Miroll et al., Saarland University

14. Summary • LBP with NACK jamming • For low jitter, low latency applications • For error tolerant applications • Improved scalability as compared to ACK-polling • Represents the Broadcast paradigm (delay-constrained, quasi-reliable: QoS at a STA within a MC group could depend on distance from sender) • LBP with NACK jamming and power-saving • Block-ACK polling may be more efficient for small audiences => No Block-NACK possible, Block-ACK may have lower CHT • HLBP • It is a Block-NACK scheme, comparable to Block-ACK • Most efficient in any scenario • Most complex due to required FEC (could be done on application layer) Jochen Miroll et al., Saarland University

15. Questions? Jochen Miroll et al., Saarland University

16. References • Multicast MAC Extensions for high rate real-time traffic in Wireless LANs • http://www.nt.uni-saarland.de Jochen Miroll et al., Saarland University