OBSS HCCA Race Condition Mar 1020 doc.: IEEE 802.11-10/0062r1 Mar 2010 OBSS HCCA Race Condition Date: 2010-03-15 Authors: Alex Ashley, NDS Ltd Alex Ashley, NDS Ltd

Mar 1020 doc.: IEEE 802.11-10/0062r1 Mar 2010 Abstract When implementing the OBSS solution from 802.11aa 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

HCCA TXOP Advertisement element Mar 1020 doc.: IEEE 802.11-10/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

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

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

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

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

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

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

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

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

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

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

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

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

Mar 1020 doc.: IEEE 802.11-10/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

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

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

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)/2+36+16+28+ ? +9*(3+255)/2+36+16+28 ≈ 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

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

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

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

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