1 / 21

Wireless Networks Should Spread Spectrum On Demand

Wireless Networks Should Spread Spectrum On Demand. Ramki Gummadi (MIT) Joint work with Hari Balakrishnan. First 30 seconds. Next 30 seconds. The problem: Bursty traffic. Demand variability observable even at short (30 s) time scales From OSDI 2006 traces

Patman
Download Presentation

Wireless Networks Should Spread Spectrum On Demand

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wireless Networks Should Spread Spectrum On Demand Ramki Gummadi (MIT) Joint work with Hari Balakrishnan

  2. First 30 seconds Next 30 seconds The problem: Bursty traffic • Demand variability observable even at short (30 s) time scales • From OSDI 2006 traces • Five APs, three orthogonal channels • Spatio-temporal demand variations common

  3. Today: Static spectrum allocation • Partitioned into non-interfering channels • Avoid CSMA hidden and exposed terminals • Avoid back-offs X

  4. Insight: Spectrum tracks demand • Spectrum tracking demand achieves higher SINR than shifting demand to where spectrum is

  5. ODS: On-Demand Spectrum • Demand-based spectrum to nodes • Uses spread-spectrum codes • Allocates multiple codes to transmitters • A single transmitter can use entire spectrum

  6. Key challenge • Avoid inter-AP coordination • Different admin domains • Demand-communication overhead X

  7. Mechanism: Spread-spectrum codes Data Signal Concurrent Code Alice’s code Received signal Bob’s code Copy of received signal

  8. Roadmap • ODS design • Determine demands • Allocate codes • Ensure conflict-freedom • Use multiple codes concurrently • ODS evaluation

  9. d d 3 1 = = 1 2 q d i = i r i Determining demands • An AP computes demands of its own clients • Averaged over last 30 s • Demand if queue length qi, bit-rate ri • For uplink, a client tells its queue length to AP

  10. h t 9 3 2 6 i c c = = 1 2 l m d i c c = i P d j i Allocating codes • Large (128) codebook c of random codes • Same at each AP • AP allocates transmitter codes • Minimizes mean transmission time. (Fairness?)

  11. . . Code assignment • Each AP assigns codes to transmitters from the codebook randomly • No coordination among APs . . . .

  12. n 1 ! k k ( ( ) ) ¸ k n n 1 1 ¡ ¡ p = = c c k 1 ¡ p = ¸ c c = t o p n e Code selection • Each transmitter selects up to k (=11, say) codes from its allocation randomly • With 2 tx, 1 code, no-conflict probability: • With n transmitters, 1 code, • If n tx, k codes, conflict-free code number: • Optimum code number as The optimum conflict-free code number under random selection within factor e of centralized

  13. Random code selection performance Random selection policy can be both efficient and robust • High throughput at low contention • Non-zero throughput even with 128 interferers

  14. 1 1 0 2 p p p = = = . . Finding conflict-free codes • Transmitter uses feedback from receiver • Assign success probability p{0,1} per code • Toggle p based on receiver feedback • p=0 at tx whose hashed id closest to code . . . . id=010 id=100 code=101

  15. Using codes concurrently • Divide packet into sub-packets • Use one code per sub-packet • Transmit all coded sub-packets concurrently • Packet header tells receiver which codes are used • Codes in conflict easy to identify at receiver Packet

  16. Recap: Avoid inter-AP coordination • Two key mechanisms • Random code selection • Efficient and robust • Feedback-based conflict detection • Decentralized

  17. Roadmap • ODS design • Determine demands • Allocate codes • Ensure conflict-freedom • Use multiple codes concurrently • ODS evaluation

  18. I Convolution Filter Q Convolution Filter Rx I/Q Modem Peak Detector Peak I,Q Samples (USB) I2+Q2 PC FPGA Challenge: Data reduction Synchronization De-spreading • USRP/GNURadio USB throughput-limited • Two steps needed for data reduction • De-spreading and synchronization • FPGA de-spreads, followed by synchronization • Transmitter design similar

  19. Preliminary evaluation ODS, two bonded 2 Mbps links No ODS, two bonded 2 Mbps links ODS improves link throughput by 75%

  20. R2 (bits/s/Hz) P P P P ( ( ( ( ) ) ) ) l l l l 1 1 1 1 2 1 1 2 + + + + o o o o g g g g 2 2 2 2 P P N N N N + + 1 2 A VWID B TDMA R1 Related work • Plain CDMA • Inefficient spectrum usage with bursty traffic • Sub-optimal • Load-aware spectrum distribution (MSR) • Uses channel-widths instead of codes • Inter-AP coordination (10-minute updates) X CDMA

  21. Contributions • Exploit bursty demands to improve spectrum usage • Demand-based code allocation • Challenge: Avoid inter-AP coordination • Random code selection • Feedback-based conflict detection • Future work: Better implementation, evaluation • Need high-throughput, low-latency radios

More Related