“ PPR: Partial Packet Recovery in Wireless Networks ” [Jamieson and Balakrishnan, 2007]

1. CS244 Spring 2014 Cross-Layer Wireless • “PPR: Partial Packet Recovery in Wireless Networks”[Jamieson and Balakrishnan, 2007] Sachin Katti (slides courtesy Kyle Jamieson)

2. Context: Interference Limited Networks [MIT Roofnet] Wireless local area networks Wireless mesh networks WiFi hotspots [moteiv.com] Wireless sensor networks

3. Interference from other transmissions interferer sender receiver Received phase  3 /2  /2 0 More bit errors Time  QPSK modulation, differential demodulation Likely correct Likely errored [ettus.com]

4. Interference raises bit error rate 1 bit error per 1500 byte packet 802.11b at 5.5 Mbits/s [Data source: Harris Semiconductor]

5. Sharing the wireless medium Carrier sense multiple access (CSMA) Mechanism: defer to ongoing Good: Simple, flexible Bad: doesn’t preclude interference Bad: reduces concurrency ? Defer “Hidden terminals” Defer “Exposed terminals”

6. The problem • Concurrency • Interference • Need both for good network throughput • Tension between the two How do we both increase concurrency and reduce interference?

7. Current approach 802.11 WiFi, 802.15.4 Zigbee Route selection, multi-hop forwarding Network layer CSMA medium access for interference Link layer data bits “Wired” abstraction: pass only entirely correct frames Share fate? Modulation and coding for link impairments Physical layer

8. Bits in corrupted packets don’t share fate 31 node Zigbee testbed, carrier sense on Many bits in corrupted packets are correct!

9. Bit-rate adaptation makes errors 802.11 WiFi Rate adaptation based on frame loss Link layer • Makes wrong decision! data bits “Wired” abstraction: pass only entirely correct frames • Slower modulation • Lower coding rate Physical layer

10. Current approach hampers performance CSMA fails to prevent interference and reduces concurrency • Discard many correct bits • Don’t know which are correct packet “Wired” abstraction: pass only entirely correct frames

11. Change perspective from packets to symbols: the SoftPHY interface • Cross-layer information flow from PHY up • Extract use from high-confidence parts of packets • Maintain layered architecture (PHY-independent use) Network layer Link layer Confidence SoftPHY interface Packet 1 Packet 2 Problem: Preamble Physical layer Time 

12. Your comments • Michael Gummelt: More information is often good, but one of the tradeoffs common to these approaches, and present in PPR, is that they require the lower layers to do more. This isn't just a problem of complexity, but also of modularity. For example, the proposed SoftPHY interface couples the physical layer with the link layer, requiring the physical layer to send proximity coding information to the link layer. If we later decide to use a different physical layer, it's required to support this feature. • Manikanta Kotaru: The paper suggests ‘hints’ as the digital abstraction SoftPHY provides. These hints are PHY dependent. For example, Hamming distance gives one kind of threshold and Viterbi decoder gives threshold of another kind. It is not clear how the monotonicity of ‘hints’ helps in PHY-independent utilization of hints at higher layers.

13. Postamble-based packet detection Preamble Postamble packet 1 packet 2 Angle  Time  High SINR bits Low SINR bits

14. What you said • Jongho Shin: Lastly, they are putting additional information apart from actual data, postamble and checksums. I think it could be a great overhead. In case of 802.11, it uses time rather than bytes for the sake of backwards compatibility in the physical layer. Thus only a few bytes could be a great overhead for high-speed transmissions such as 600Mbps. Then postamble could be disastrous

15. Design • SoftPHY physical layer abstraction • Zigbee implementation • 802.11a-like implementation (work in progress) • PP-ARQ: Increasing reliable throughput over a link • Other applications of SoftPHY • Channel access • With Vutukuru and Balakrishnan, USENIX NSDI 2008 • Bit rate adaptation • Opportunistic and mesh-based forwarding

16. Zigbee physical layer design Receiver: Transmitter: data, SoftPHY hints data A(n) 4 bits 250 Kbits/s 250 Kbits/s 4 bits Decoder Block coding 32 chips 2 Mchips/s 32 chips 2 Mchips/s Detector MSK modulation Synchronizer Chipcon CC2420 radio Software radio

17. Zigbee decoder • 16 codewords {Ci}, each of length 32 chips • Receive 32 chips R, decide on closest C  {Ci} SoftPHY hint =16 – dHamming(R, C) R: 11101101000111000011010110100010 C1: 11101101100111000011010100100010 SoftPHY hint is 16 – 2 = 14 R: 11001101000111010111011110110111 C1: 11101101100111000011010100100010 SoftPHY hint is 16 – 9 = 7

18. 802.11a-like physical layer design Receiver: Transmitter: data A(n) data, SoftPHY hints Convolutional coding [Anastasopoulos] Encoder Decoder Deinterleaver Interleaver Soft info. y OFDM modulate OFDM [Rondeau et al.] BPSK, QPSK, 16-QAM OFDM detector USRP [Ettus et al.] 2.4 GHz RFX2400 front end [ettus.com]

19. 802.11a decoder Soft input y0 (OFDM demod) A(n) Viterbi Hard symbol decisions pA(n)|Y(+1|y) LLR(n) = log Soft input y0 (OFDM demod) pA(n)|y(±1|y0) pA(n)|Y(–1|y) BCJR Soft symbol probabilities SoftPHY hint Interference abs data SoftPHY hints Time

20. Design • SoftPHY physical layer abstraction • Zigbee implementation • 802.11a-like implementation (work in progress) • PP-ARQ: Increasing reliable throughput over a link • Other applications of SoftPHY • Channel access • With Vutukuru and Balakrishnan, USENIX NSDI 2008 • Bit rate adaptation • Opportunistic and mesh-based forwarding

21. PP-ARQ: Retxmits with partial packets sender receiver Use SoftPHY to label: Packet, 1st transmission “bad” “good” 1 2 3 4 5 C C 1 2 3 4 5 “Resend 1 & 2, send a checksum of 3, 4, 5” feedback Packet, 2nd transmission 1 2 C’ 1 2 C’ Combine 1st and 2nd: 1 2 3 4 5 C ? 1 2 1 2 3 4 5 C

22. PP-ARQ: Challenges • How to label bits “good” or “bad?” • Which bits should the receiver ask for in feedback message? • How to cope with errors in labeling? • Will use correct, incorrect for ground truth

23. Labeling bits “good” or “bad” • Threshold test: pick a threshold h • Label bits with SoftPHY hint ≥h“good” • Label bits with SoftPHY hint < h“bad” • Actual truth: correct/incorrect SoftPHY hint h “bad” “good”

24. Choosing a threshold  h Same results: varying send rate, CS on/off, noisy or quiet background

25. Which bits should the receiver ask for? Assuming “good” and “bad” labels correct Better choice Bits labeled “good” Bits labeled “bad” • All of the “bad” bits • Beginning and ending with “bad” bits: chunk • Maybe some “good” bits Poor choice Better chunk E.g.: Four chunks One chunk Two chunks One chunk

26. Principle: balance forward and feedback sender receiver Not enough feedback detail: Status quo: waste re-sending correct bits on forward channel “nack” Too much feedback detail: Waste time on feedback

27. Which bits should the receiver ask for? chunki,j: from beginning of ith run to end of jth run of “bad” bits (and all bits within) Bits labeled “good” Bits labeled “bad” chunk1,3 chunk2,3 chunk1,2 3rd bad run 2nd bad run 1st bad run This problem exhibits: • Overlapping subproblems • Optimal substructure  Try dynamic programming (DP)

28. What you said • Stephen Quinonez: The second potential problem is that this solution is more computationally demanding than the usual function of receivers. There are two reasons this could be a negative. One is that it will take more time to process packets and decide what to do with them. … The second and perhaps more important point would be that more computation and buffering are needed for PPR, which could mean higher hardware requirements for the receivers. In this case it would make it more difficult to implement in existing systems and harder to standardize in general. • Chirag Sangani: PPR’s energy performance has been neglected. For wireless communication, this is an important metric. Considering that PPR introduces complex calculations of complexity O(L^3) for every packet, it may be worse off than simpler techniques like Fragmented CRC, balancing out the marginal performance gains.

29. PP-ARQ: asynchronous streaming Shift from packets to symbols Data bits 1st pkt., 1sttx. “Good” data bits 1st pkt., 2nd tx. 2nd pkt., 1st tx. “Bad” data bits Checksum (32-bit) 1st pkt., 3rd tx. 3rd pkt., 1st tx.

30. Asynchronous streaming of feedback sender receiver 1st pkt., 1st tx. “bad” “good” 1 2 3 4 5 feedback Feedback for 1st packet 2nd pkt., 1st tx. 1st pkt., 2nd tx. Feedback for 1st and 2nd packets feedback 1 2 3 4 5

31. Implementation Sender: telos tmote sky sensor node Radio: CC2420 DSSS/MSK (Zigbee) Modified to send postambles Receiver: USRP software radio with 2.4 GHz RFX 2400 daughterboard Despreading, postamble synchronization, demodulation SoftPHY implementation [moteiv.com] [ettus.com]

32. Experimental design 25 senders 6 receivers • Live wireless testbed • 31 node testbed • Senders transmit 101-byte packets, varying traffic rate • Run in Zigbee channel 11, validate in channel 26 • Trace-driven experiments • Evaluate PP-ARQ performance 3 MHz 3 MHz 802.11b Ch. 1 802.11b Ch. 11 -10 dBm -35 dBm 12 11 25 26 2410 MHz 2405 2475 2480 MHz 2462

33. Experiment: aggregate throughput • Traffic pattern: sender uploads to best receiver • Packet CRC • Status quo for 802.11, Zigbee • Discard packet on CRC fail • SoftPHY best • Deliver all correct bits • (“oracle” tells us which) • No-overhead, no-loss feedback • No other overheads 0.5× N=15 runs, unpaired t-test

34. Agenda • SoftPHY physical layer abstraction • Zigbee implementation • 802.11a-like implementation (work in progress) • PP-ARQ: Increasing reliable throughput over a link • With Balakrishnan, ACM SIGCOMM 2007 • Other applications of SoftPHY • Channel access • With Vutukuru and Balakrishnan, USENIX NSDI 2008 • Mesh networks • Bit rate adaptation

35. The problem • Concurrency • Interference • Need both for good throughput • Tension between the two How do we both increase concurrency and reduce interference?

36. Conflict maps: rethinking CSMA Good: simple, flexible Bad: reduces concurrency Defer “Exposed terminals” Promise: double concurrency, double throughput u Challenge: justdisable CSMA?  break common case: v “Harnessing Exposed Terminals In Wireless Networks” with Vutukuru and Balakrishnan, USENIX NSDI 2008

37. Conflict maps: main idea Approach: disable CSMA but learn from mistakes. Preamble senders Postamble u v receiver Insight: Using SoftPHY + postamble detection, put useful information here, selectively enable CSMA “Harnessing Exposed Terminals In Wireless Networks” with Vutukuru and Balakrishnan, USENIX NSDI 2008

38. Mesh networks • PP-ARQ works link-by-link • Mesh: diversity creates more opportunities • MIXIT [Katti et al.]: forward on only SoftPHY’s “good” bits

39. SoftPHY may be useful to adapt bitrate • Measure “slack” in received constellation • Look at change in SoftPHY hint slack SNR = 10 dB SNR = 20 dB SoftPHY hint  Infer collision

40. Looking forward • New directions • Better combining of retransmissions at the receiver • Incorporating multiuser detection techniques • New applications • Wireless systems that use cross-layer information • Sensor networks for medical applications