1. Proposed Overlapping BSS Solution
August 2009
doc.: IEEE /0xxx
August 2009
Proposed Overlapping BSS Solution
Date: 2009, August 17
Authors:
Graham Smith, DSP Group
Graham Smith, DSP Group

2. August 2009
doc.: IEEE /0xxx
August 2009
Abstract
08/0457r4 and 08/1260r1 examined the OBSS problem and outlined possible solutions – “QLoad” introduced
08/1250r0, 09/0285r0, and 08/1470r4 looked at the OBSS scenarios, estimated worse case overlaps and ran simulations using Channel Selection so as to size the problem.
09/0230r0 and 09/0476r1 gave the details of the revised OBSS proposal with use of CHP bit and HCCA Supervisor
09/0496r2 examined video stream statistics
09/0497r2 extended the video stream statistics to QLoad fields
09/0660r3 examined using 11s MCCA for HCCA OBSS
09/0662r2 introduced OBSS Sharing with Access Fraction
09/0666r2 considered HCCAOP Advertisement Element for sharing and TXOP avoidance
09/0931r0 looked at Stray and Overlapping STAs
This presentation presents the proposed solution for OBSS
Graham Smith, DSP Group
Graham Smith, DSP Group

3. August 2009
Changes from 09/0757r0
TSPEC Requirement Request now just requests a re-issue of TSPECs., i.e. TSPEC Requirement Response deleted (Slide 12)
HCCAOP Advertisement Element used throughout and CHP deleted
QLoad information simplified
Only provide information on self
Delete QAP ID
Added HCCA Access Factor
QLoad Request / Report Public Action Frame added
QoS Traffic and Overlap Element added
“Sharing” description re-written for clarification (slide 19)
HCCAOP Advertisement Element simplified
Only provide Self Times Report
Back up slides removed
Straw Polls added
Graham Smith, DSP Group

4. Objectives of OBSS Proposal
August 2009
Objectives of OBSS Proposal
Provide the means for:
Meaningful Channel Selection
Co-operation between Admission Control QAPs
Co-operation between HCCA and Admission Control QAPs
Co-operation between HCCA QAPs
Graham Smith, DSP Group

5. Definitions and OBSS Graph
November 2007
September 2008
August 2009
doc.: IEEE /1003r0
doc.: IEEE /2752r1
doc.: IEEE /0xxx
August 2009
Definitions and OBSS Graph
Length (OBSS graph)
– longest shortest path between any two APs in the OBSS graph
OBSS Extent is related to the length (OBSS graph) (used in 08/0285r0)_
Size (OBSS graph)
– number of nodes (APs) in the OBSS graph
OBSS Solution Minimum Requirement (accepted in Los Angeles, Jan ’09)
length (OBSS graph) <= 2 and the size (OBSS graph) <=3
Overlap - Number of overlapping BSSs that are sharing this channel
Overlap is simple for a QAP to report
Overlap” does not by itself indicate the OBSS Size or Length
BUT,
There is a direct relationship between OBSS Length AND:
the probability of Overlap2
the number of Channels
and the number of other APs within radio range
e.g. If Probability of Overlap2 <1% then OBSS length<=2 and OBSS size <=3
FOR MORE COMPLETE EXPLANATION, SEE BACKUP SLIDES
Slide 5
Slide 5
Graham Smith, DSP Group
Page 5
Page 5
Peter Ecclesine, Cisco Systems
Graham Smith, DSP Group
Alex Ashley, NDS Ltd

6. August 2009
Outline of Proposal
New Public Action Frame “QLoad Report”, Request and Report
Used for Channel Selection and Channel Sharing
Broadcast by QAP when changed, and possibly periodically
New Element “QoS Traffic and Overlap Element”
New Action Frame “TSPEC Requirement Request”
Used by QAP to STA to indicate or confirm their TSPECs
New IE “TXOP Advertisement Element”
Used by QAPs to avoid the TXOPs of overlapping QAPs
Used by both EDCA and HCCA
Recommendations to avoid/minimize OBSS problem
Channel selection based upon information in the QLoad Element:
Overlap
QLoad
Access Factor
Channel width selection 40/20MHz, based upon Overlap
How to use the fields in the QLoad Element for Sharing and to prevent over-allocation
Graham Smith, DSP Group

7. PROPOSED “QLoad Report” Public Action Frame
August 2009
doc.: IEEE /0xxx
August 2009
PROPOSED “QLoad Report” Public Action Frame
Graham Smith, DSP Group
Graham Smith, DSP Group

8. Alternative – QLoad Element
August 2009
Alternative – QLoad Element
Graham Smith, DSP Group

9. August 2009
Overlap
QAP indicates the number of other QAPs with which it is sharing and indicates the size of the OBSS graph:
Zero indicates QAP has no other QAPs on the same channel within range
1 indicates already sharing with one other QAP
2 indicates already sharing with two other QAPs
etc
The QAP is advertising the overlap to other QAPs who may be considering sharing.
This parameter should be included in the Channel Selection procedure in order to select the best channel (08/1470r4)
IF QLOAD REPORT
Possibly need to add Overlap to a Beacon Element as important to the Channel Selection process, or add a new one
Modify existing QoS related Element (QoS Traffic Capabilities?)
New (preferred)
Graham Smith, DSP Group

10. QoS Traffic and Overlap Element
August 2009
QoS Traffic and Overlap Element
Could delete the QAP Priority Streams from QLoad Report
Graham Smith, DSP Group

11. QLoad Self There are three methods for the QAP to build QLoad Self:
August 2009
QLoad Self
There are three methods for the QAP to build QLoad Self:
QSTAs in the BSS may send a TSPEC (ADDTS) with Inactivity Interval set to 0 (or 1) for instant timeout
By sending in a TSPEC the STA has the QAP commit, in advance, medium time for the STA
QAP notes and adjusts for new TSPECs from QSTAs
If accepted, “QLoad Self”, and also “QLoad Total” are adjusted only when the QSTA submits the ADDTS
Chance that ADDTS is denied as QSTA did not reserve medium time in advance
In response to TSPEC Requirements Request
QAP request STAs to confirm (re-send) their TSPECs
Used by QAP to ‘clear house’ or initially set up Q Load.
The QAP is advertising its own potential QoS load to other QAPs who may be considering sharing
Graham Smith, DSP Group

12. TSPEC Requirement Request
August 2009
TSPEC Requirement Request
Request from QAP to a particular STA
Send All TSPECs (ID 1)
Effectively all previous (if any) TSPECs are deleted, need to set them up again
Graham Smith, DSP Group

13. August 2009
QLoad MEAN and STDEV
MEAN and STDEV is estimated from the individual TSPECs:
MEAN µ = ΣMEANi
STDEV σ = 0.25 sqrt{Σ(MAXi – MINi)2}
MEAN µtot = ΣMEANi
STDEV σtot = sqrt(Σσi2)
Total Traffic Requirement can be estimated:
MAX traffic = µtot + 2 σtot
90% Traffic = µtot σtot
80% Traffic = µtot σtot
Graham Smith, DSP Group

14. August 2009
QAP Priority Streams
Number of EDCA Voice and Video Priority Streams using AC_VO and AC_VI
Used to estimate “EDCA Bandwidth Factor”
EDCA Bandwidth Factor = N (approx; keep it simple, see 09/0497, based upon the default AC_VI settings)
Where N = Number of streams
Example: 4 streams Effective Bandwidth Factor = 1.2 Four 5.5Mbps streams will require 1.2 x 4 x 5.5 = 26.5Mbps
Note: The EDCA Bandwidth Factor is advisory and more work may be required in order to describe how a QAP should derive and apply it. For example if QAPs were not using the default EDCA parameters.
Graham Smith, DSP Group

15. Access Fraction and Access Factor
August 2009
Access Fraction and Access Factor
Access Fraction
Total actual admitted time and/or scheduled time expressed as a fraction of 32us/sec rounded down to 1/256
The Access Fraction is the total composite stream that the AP has allocated at any one time.
Access Factor
Total Traffic Requirement in 32us/sec. Expressed as a fraction that may be greater than 1.
Calculated as follows:
Sum, as a composite stream, the Self QLoads of itself and all QAPs that are directly visible
Calculate the EDCA Bandwidth Factor from the total number of Priority Streams in self and all the visible QAPs
Multiply the two to obtain the “Access Factor”
Graham Smith, DSP Group

16. August 2009
ACCESS FACTOR FIELD
QLoads, Medium Time and TXOPs are all measured in 32us/sec
Access Factor can be > 1
To express in 1 octet
2 bits for Integral (whole number)
6 bits for the decimal fraction, expressed as a fraction rounded down to 1/64
Example: Sum = in 32us/sec = seconds
Hence, octet would be [2 and 24/64 = 2.375]
Maximum value would be 3.98
Graham Smith, DSP Group

17. HCCA Peak “HCCA Peak” “HCCA Access Factor”
August 2009
HCCA Peak
“HCCA Peak”
The total HCCA TXOP requirement for the QAP, expressed in 32us/sec.
“HCCA Access Factor”
The sum of all the “HCCA Peak” values in the QLoad Elements of self and directly visible QAPs is the “HCCA Access Factor”
If HCCA Access Factor > 1sec then potential for TXOP over-allocation
HCCA TXOPs can sum to “1” independent of EDCA Medium Time allocations, (as TXOPs terminate immediately when no more data)
Graham Smith, DSP Group

18. August 2009
Sharing Basis
If the Access Factor is >1, then there is a potential over-allocation
Hopefully QAPs should avoid this in the Channel selection process
Sharing Scheme
QAPs should examine their QLoad Report in order to determine the maximum “Access Factor” being reported. This maximum value is then used to determine the allocation limit for that QAP in order not to cause over-allocation in other QAPs that are overlapping,
Using the Access Fractions (actual “live” traffic), Access Factor and QLoad self, a decision can be made whether to admit a new request.
Rules will be recommended in informative text
Graham Smith, DSP Group

19. Medium Time, TXOP Allocations - General
August 2009
Medium Time, TXOP Allocations - General
It is important to understand how the AP allocates the actual Medium Times and TXOPs in responses to TSPECs and checks that it has not exceeded its ‘limit’
In response to each TSPEC the AP would normally allocate the Medium Time or TXOP (HCCA) that corresponds to the peak traffic.
When allocating a Medium Time or TXOP, the AP must calculate what the composite stream would be for that AP, and check that this composite medium time does not exceed the limit. The limit is the defined as follows:
If the Access Factor is <=1, an AP may allocate up to its advertised Self QLoad (composite stream calculated as MAX traffic = µtot + 2 σtot )
If the Access Factor is >1, an AP may only allocate up a value of Self QLoad/Access Factor
Before allocating an HCCA TXOP, the AP must check the “HCCA Access Factor” and check that:
If the HCCA Access Factor is <=1, an AP may allocate up to its advertised “HCCA Peak”
If the HCCA Access Factor is >1, an AP may only allocate up to HCCA Peak/HCCA Access Factor
Graham Smith, DSP Group

20. Special Case when Overlap = 2
August 2009
Special Case when Overlap = 2
If QAP (B) has Overlap 2, and the other QAPs (A and C) are each advertising Overlap 1, then QAP B should not include both QAPs A and C in its calculation of Access Factor
QAPs A and C are not visible to each other and therefore do not interfere, BUT both interfere with QAP B
QAP B, in this case, will take the larger QLoad value of QAPs A and C for calculating its Access Factor.
QAPs A and C will each calculate their Access Factors as normal, using the QLoad value advertised by QAP B
Graham Smith, DSP Group

21. PROPOSED “HCCAOP ADVERTISEMENT” ELEMENT
August 2009
PROPOSED “HCCAOP ADVERTISEMENT” ELEMENT
Graham Smith, DSP Group

22. HCCAOP Advertisement Element
August 2009
HCCAOP Advertisement Element
HCCAOP Advertisement Element must be provided by an HCCA QAP
TXOP Reservation
Duration: In units of 32us
Service Interval (ms)
Offset: Beginning of first TXOP after a Beacon, relative to beginning of each scheduled Beacon, in units of 32us
Graham Smith, DSP Group

23. HCCAOP Advertisement Scheme
August 2009
HCCAOP Advertisement Scheme
HCCA QAPs need to schedule TXOPs that do not interfere with the other HCCA QAPs that are directly visible.
The HCCAOP Advertisement Element lists all the HCCA TXOPs that have been already scheduled by that QAP in the “Self Times Report”
An HCCA QAP looks at the TXOP Advertisement of direct neighbor QAPs in order to select a TXOP time that does not interfere with any TXOP being advertised in the “Self Times Report”
QAP must check that allocating a new TXOP will not cause the HCCA Access Factor (sum of HCCA Peak in the QLoad Report) to exceed 1 sec/sec.
All times in the HCCAOP Advertisement Element are expressed with respect to the TSF of the QAP that is transmitting the element
QAPs need to monitor the TSF of their neighbors so as to keep an up to date TSF Offset value.
Graham Smith, DSP Group

24. Options QLoad could be Element or Public Action Frames
August 2009
Options
QLoad could be Element or Public Action Frames
Element would be 14 octets – is this too long?
Public Action Frame requires:
Request and Report
New Element for Overlap Or
QAP must always send QLoad Request to obtain Overlap information
Is this efficient?
Decision could be based upon more than Overlap
Overlap could be added to an existing Element
11v QoS Traffic Capabilities? Based on STA count
QAP Priority Streams information is more useful?
Do we maintain the MEAN and STDEV fields, or are they ‘over-the-top”?
Graham Smith, DSP Group

25. August 2009
Straw Polls
Should the QLoad information be in an Element or Public Action Frames “Request / Report”?
Element
Public Action Frames
No preference
If Public Action Frame
Should a new Element be added for Overlap and Priority Streams, or require the QAP to request the QLoad each time it is looking to share a channel?
New Element
Require “Request”
Graham Smith, DSP Group