1. OBSS HCCA Race Condition
Mar 1020
doc.: IEEE /0062r1
Mar 2010
OBSS HCCA Race Condition
Date:
Authors:
Alex Ashley, NDS Ltd
Alex Ashley, NDS Ltd

2. Mar 1020
doc.: IEEE /0062r1
Mar 2010
Abstract
When implementing the OBSS solution from aa draft 0.03, a race condition was discovered in the HCCA TXOP advertisement procedure.
The presentation attempts to describe the issue and provides the outline of a potential solution for which normative text has been prepared.
Alex Ashley, NDS Ltd
Alex Ashley, NDS Ltd

3. HCCA TXOP Advertisement element
Mar 1020
doc.: IEEE /0062r1
Mar 2010
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
Alex Ashley, NDS Ltd

4. Example (1/4) Two homes, with an AP in each home
Mar 2010
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. Mar 2010
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
Mar 2010
Example (3/4)
Current steady state situation
2870
2880
2885
2893
time
AP A receives a request for an 8Mbps video stream
New schedule
2870
2880
2885
2893
2898
2903
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
Mar 2010
Example (4/4)
Current steady state situation
2870
2880
2885
2893
time
AP A receives a request for a 8Mbps video stream
AP A schedule
2870
2880
2885
2893
2898
2903
time
AP B also receives a request for a 8Mbps video stream
AP B schedule
2870
2880
2885
2893
2898
2903
time
Alex Ashley, NDS Ltd

8. Mar 2010
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
Mar 2010
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. Mar 2010
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. Mar 2010
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 max 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”
BSSID used to decide which AP chooses to re-schedule
Alex Ashley, NDS Ltd

12. HCCA TXOP Advertisement frame
Mar 2010
HCCA TXOP Advertisement frame
Used to signal to other APs a new TXOP allocation
Other APs reply to say if this is ok or causes conflict
Category
Action
Dialog Token
TXOP Reservation
Octets 1 4
Alex Ashley, NDS Ltd

13. HCCA TXOP Response frame
Mar 2010
HCCA TXOP Response frame
Status code
“ok”
“TS should not be created because the schedule conflicts”
Alternate Schedule field contains proposed alternate
Optional avoidance request field contains TXOP that replying AP would like the other AP to avoid
Category
Action
Dialog Token
Status Code
Alternate Schedule
Avoidance Request
Octets 1 2
0 or 4
Alex Ashley, NDS Ltd

14. Table 11-2aa—Contents of TXOP Response Frame
Mar 2010
Table 11-2aa—Contents of TXOP Response Frame
Case
Status Code
Alternate Schedule Field
Avoidance Request Field
No conflict with existing or in-progress schedules
“OK”
Not present
Not Present
Conflicts with existing schedule, no ADDTS request in progress
“The TS should not be created because the schedule conflicts with an existing schedule…”
Period of time that does not conflict with any currently accepted HCCA TXOPs
Conflict in-progress schedules, RA[1] < TA[2]
Period of time that does not conflict with any currently accepted HCCA TXOPs nor the in-progress ADDTS request
Schedule of in-progress ADDTS request
Conflict in-progress schedules, RA > TA
Same schedule that was in the TXOP Advertisement
Period of time that does not conflict with any currently accepted HCCA TXOPs nor the period given in the Alternate Schedule field
[1] RA is the MAC address of the STA that received the TXOP Advertisement frame
[2] TA is the MAC address of the STA that sent the TXOP Advertisement frame
Alex Ashley, NDS Ltd

15. Key for following diagrams
Mar 2010
Key for following diagrams
Allocated Traffic for AP 1
Existing scheduled traffic
A desired time slot for a new TSPEC request
A temporary allocation, that the AP will try to avoid when scheduling. It is used when offering an alternative to an allocation request from another AP
Allocated Traffic for AP 2
Desired Allocation for AP 1
Desired Allocation for AP 2
Avoidance Allocation for AP 1
Avoidance Allocation for AP 2
Alex Ashley, NDS Ltd

16. Mar 1020
doc.: IEEE /0062r1
Mar 2010
“Simple” Case Both APs get TSPEC requests at same time, one AP sends notification
AP 1
AP 2 1 2 3 1 2 3
Allocation notification 3 1 2 3 4
s=3
a=4
TXOP Response 1 2 3 4
Allocation notification 3 1 2 3 4 OK 1 2 3 4 4
Allocation notification 1 2 3 4 1 2 3 4 OK 1 2 3 4
Alex Ashley, NDS Ltd
Alex Ashley, NDS Ltd

17. Mar 2010
“Worst” Case Both APs send their notification frames at the “same” time
AP 1
AP 2 1 2 3 1 2 3 3 3
Allocation notification
Allocation notification 1 2 3 4
s=4
s=3
a=4 1 2 3 4
TXOP Response
a=3
TXOP Response 1 2 3 4 1 2 3 4 4 3
Allocation notification
Allocation notification 1 2 3 4 1 2 3 4 OK OK 1 2 3 4 1 2 3 4
Alex Ashley, NDS Ltd

18. Questions from Jan meeting
Mar 2010
Questions from Jan meeting
What is the delay caused by negotiation?
Does it work with more than 2 APs?
Alex Ashley, NDS Ltd

19. What is the delay caused by negotiation?
Mar 2010
What is the delay caused by negotiation?
No schedule conflict
Time to send TXOP Advertisement + TXOP Response
AC_VO (CWmin = 3, CWmax=255), 5GHz (slot=9µs, sifs=16 µs), 24Mbps PHY rate
Back-off + TXadvert + SIFS + ACK + ? + Back-off + TXresponse + SIFS + ACK
9*(3+255)/ ? +9*(3+255)/ ≈ 2.5ms
2+ APs
Extra TXOP Advertisement + TXOP Response for each AP
≈ 2.5* N ms (N=number of APs)
Without negotiation, first possible correction is after a beacon from each AP
≈ 100ms
Alex Ashley, NDS Ltd

20. Mar 2010
Does it work when more than 2 APs? (All APs sending their notification frames at the “same” time)
AP 1
AP 2
AP 3 1 2 3 3 1 2 3 1 2 3 3
Allocation notification
Allocation notification 1 2 3 4
TXOP Response 1 2 3 4
s=4
a=3 1 2 3 4
TXOP Response
s=3
a=4 1 2 3 4 5 5
Allocation notification
Allocation notification 5 1 2 3 5 1 2 4 5 OK OK 1 2 3 4 5
Alex Ashley, NDS Ltd

21. Mar 2010
Does it work when more than 2 APs? (All APs sending their notification frames at the “same” time)
AP 1
AP 2
AP 3 1 2 3 4 5 1 2 3 5 1 2 4 5 3
Allocation notification
Allocation notification 3 1 2 3 4 5 1 2 3 4 5 OK OK 1 2 3 5 1 2 3 4 5 4
Allocation notification 4 1 2 3 4 5 1 2 3 4 5 OK OK 1 2 3 4 5
Alex Ashley, NDS Ltd

22. Conclusions Simulation results suggest there is a race condition
Mar 2010
Conclusions
Simulation results suggest there is a race condition
But how often does it occur in the real world?
A solution is proposed
Requires a new frame exchange sequence
Requires 2 frame exchange (Advertisement, Response) per overlapping AP
Alex Ashley, NDS Ltd

23. References Normative text is in document 10/0326r0 Mar 2010
Alex Ashley, NDS Ltd