1 / 18

OBSS HCCA Race Condition

OBSS HCCA Race Condition. Authors:. Date: 2010-01-17. Abstract. When implementing the OBSS solution from 802.11aa draft 0.03, a race condition has been discovered in the HCCA TXOP advertisement.

garren
Download Presentation

OBSS HCCA Race Condition

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. OBSS HCCA Race Condition Authors: Date: 2010-01-17 Alex Ashley, NDS Ltd

  2. Abstract When implementing the OBSS solution from 802.11aa draft 0.03, a race condition has been discovered in the HCCA TXOP advertisement. The presentation attempts to describe the issue and provides the outline of a potential solution. Alex Ashley, NDS Ltd

  3. HCCA TXOP Advertisement element • The HCCA TXOP Advertisement element is used by an AP to advertise its TXOP state to its overlapping APs. Figure 7-aa19 –HCCA TXOP Advertisement element Figure 7-aa20 – TXOP Reservation field Alex Ashley, NDS Ltd

  4. Example (1/4) • Two homes, with an AP in each home • Both APs from same vendor (i.e. same scheduling alg) • Each AP is streaming one 25fps 16Mbps video stream AP 1 AP 2 BEACON HCCA_TXOP[start=2870, dur=10ms interval=40ms] BEACON HCCA_TXOP[start=2885, dur=8ms, interval=40ms] Alex Ashley, NDS Ltd

  5. Example (2/4) • Once both APs have received a beacon from the other AP with the HCCA TXOP Advertisement element, they know each other’s current HCCA schedule. • However, what happens when both APs receive TSPEC requests in-between beacons? Alex Ashley, NDS Ltd

  6. Example (3/4) Current steady state situation 2870 2880 2885 2893 time AP A receives a request for a 8Mbps video stream 2898 2903 New schedule 2870 2880 2885 2893 time At the next beacon, AP B learns of the new schedule but what if AP B receives a TSPEC request before then? Alex Ashley, NDS Ltd

  7. Example (4/4) Current steady state situation 2870 2880 2885 2893 time AP A receives a request for a 8Mbps video stream 2898 2903 AP A schedule 2870 2880 2885 2893 time AP B also receives a request for a 8Mbps video stream 2898 2903 AP B schedule 2870 2880 2885 2893 time Alex Ashley, NDS Ltd

  8. Race Condition • In-between successfully received beacons, an AP is unaware of new HCCA allocations in neighbouring QAPs • But how likely is it that multiple APs will grant TSPECs in the same beacon period? • Murphy’s law – “If it can go wrong, it will” • After a power cut – many devices activating at the same time? • When trying to simulate the OBSS solution  Alex Ashley, NDS Ltd

  9. First attempt to fix the problem • Randomly choose to allocate at the start or the end of the service interval • Reduces chances of colliding allocations • Fairly easy to implement • However, didn’t remove the problem • Still got clashes • Birthday Paradox? • Murphy’s Law? • Bad random number generator? Alex Ashley, NDS Ltd

  10. Second Attempt • When making an allocation, send a frame to the other APs telling them of the allocation • Stops other AP allocating the same time slot • No need to wait a beacon period • Mostly worked for the case of two APs • Still suspect race condition with >2 APs • If both APs got their requests virtually simultaneously, they still made clashing allocations, and then sent a frame to the other AP to tell them about it Alex Ashley, NDS Ltd

  11. Third Attempt • When making an allocation, send a request to the other APs telling them of the allocation • If other AP has made a clashing allocation, it reserves a new slot of the same duration as the request and replies with a frame “please don’t use that schedule, here’s a new proposed schedule” • The temporary allocation is held for 3 beacon frames • If a request is received from another AP while waiting for a reply to its own TSPEC request, combine the allocation from the received request with own request and issue a “new schedule proposal” • Sort these allocation requests by BSSID Alex Ashley, NDS Ltd

  12. Key for following diagrams Allocated Traffic for AP 1 Existing scheduled traffic A desired time slot for a new TSPEC request A temporary allocation, used to offer an alternative to an allocation request from another AP Allocated Traffic for AP 2 Desired Allocation for AP 1 Desired Allocation for AP 2 Temporary Allocation for AP 1 Temporary Allocation for AP 2 Alex Ashley, NDS Ltd

  13. “Simple” CaseBoth APs get TSPEC requests at same time, one AP sends notification AP 1 AP 2 1 2 1 1 2 2 Allocation notification 1 1 2 1 2 1 2 Alternate schedule 1 2 1 2 Allocation notification 1 2 1 2 1 2 OK 1 2 1 2 Allocation notification 2 1 2 1 2 1 2 1 2 OK 1 2 1 2 Alex Ashley, NDS Ltd

  14. “Worst” CaseBoth APs send their notification frames at the “same” time AP 1 AP 2 1 2 1 1 2 2 2 1 Allocation notification Allocation notification 1 2 1 2 1 2 1 2 1 2 1 2 Alternate Schedule Alternate schedule 1 2 1 2 1 2 1 2 1 2 1 2 Allocation notification Allocation notification 1 2 1 2 1 2 1 2 OK OK 1 2 1 2 1 2 1 2 Alex Ashley, NDS Ltd

  15. Conclusions • Simulation results suggest there is a race condition • But how often does it occur in the real world? • A potential solution is proposed • Requires a new frame exchange sequence Alex Ashley, NDS Ltd

  16. Straw Poll 1 • Is this race condition something TGaa needs to solve? • Yes • No Alex Ashley, NDS Ltd

  17. Straw Poll 2 • Does the proposed solution outlined in this presentation seem plausible enough to want to see normative text? • Yes • No Alex Ashley, NDS Ltd

  18. References Alex Ashley, NDS Ltd

More Related