1. Outline of Proposed Overlapping BSS Solution
November 2009
doc.: IEEE /0xxx
November 2009
Outline of Proposed Overlapping BSS Solution
Date: 2009, November 18
Authors:
Graham Smith, DSP Group
Graham Smith, DSP Group

2. November 2009
doc.: IEEE /0xxx
November 2009
Abstract
This presentation presents the proposed solution for OBSS, with options
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
09/1136r1 examined the Hidden AP situation and AP Shut Out problem
09/1137r1 examined EDCA Bandwidth Factor
Graham Smith, DSP Group
Graham Smith, DSP Group

3. Objectives of OBSS Proposal
November 2009
Objectives of OBSS Proposal
Provide the means for:
Meaningful Channel Selection
Sharing in an OBSS Situation:
Co-operation between Admission Control QAPs
Co-operation between HCCA and Admission Control QAPs
Co-operation between HCCA QAPs
This proposal has some significant changes from previous and now includes the support for an On-Demand Sharing scheme in addition to a Proportional Sharing scheme.
Graham Smith, DSP Group

4. Outline of Proposal Qload Report Element
November 2009
Outline of Proposal
Qload Report Element
QLoad Report Request Action Frame
QLoad Report Public Action Frame
Optionally in Beacon
New entries in Extended Capabilities
QLoad Report (AP)
TSPEC Requirement Request (non-AP STA)
New Action Frame “TSPEC Requirement Request”
Sent by QAP to STA to indicate or confirm their TSPECs
New IE “HCCA TXOP Advertisement Element”
Used by HCCA QAPs to avoid the TXOPs of overlapping QAPs
Annex (Informative)
Channel selection based upon information in the QLoad Element:
How to calculate the values in the QLoad Report
How to use the fields in the QLoad Element for Sharing and to prevent over-allocation
Proportional Sharing Scheme
On-Demand Sharing Scheme
Graham Smith, DSP Group

5. Allocated Traffic Shared
November 2009
doc.: IEEE /0xxx
November 2009
QLoad Report Element
Element ID
Length
QLoad
Allocated
Traffic
Self
Allocated Traffic Shared
Access Factor
HCCA Peak
HCCA Access Factor
Overlap
octets 1 5 2
QLoad, Allocated Traffic Self, and Allocated Traffic Shared Fields
Octet 2 1
Mean
Stdev
Reserved
AC3 Streams
AC2 Streams
Bits 16 14 4
Graham Smith, DSP Group
Graham Smith, DSP Group

6. QLoad Fields November 2009 QLoad Allocated Traffic Self
indicates the total potential QoS traffic for the AP and its BSS and is expressed as a Mean and Standard Deviation in units of 32µs. Also indicates the number of AC2 and AC3 EDCA streams that make up that composite stream
Allocated Traffic Self
indicates the total allocated QoS traffic, and is expressed as a Mean and Standard Deviation in units of 32µs. Also indicates the number of AC2 and AC3 EDCA streams that make up that composite stream
Allocated Traffic Shared
the composite sum of the Allocated Traffic Self values that can be received from overlapping APs, plus the Allocated Traffic Self value of the AP itself, and is expressed as a Mean and Standard Deviation in units of 32µs and number of AC2 and AC3 streams.
Access Factor
the composite sum of the QLoads that can be received from overlapping APs, plus the QLoad of the AP itself. Calculated in units of 32µs and expressed as a fraction rounded down to 1/64
HCCA Peak
the total peak HCCA TXOP requirement, over a period of one second, for the AP and BSS, for all the HCCA TSPECS that are included in the QLoad. HCCA Peak is expressed in multiples of 32µs.
HCCA Access Factor
the sum of the QLoads that can be received from overlapping APs, plus the QLoad of the AP itself. Calculated in units of 32µs and expressed as a fraction rounded down to 1/64
Overlap
indicates the number of other APs that are sharing the same channel and whose beacons can be detected
Graham Smith, DSP Group

7. HCCA Advertisement Element
November 2009
HCCA Advertisement Element
The HCCA TXOP Advertisement element is used by an AP
to advertise its TXOP state to its overlapping APs
Element ID
Length
Number of
Reported
TXOP
Reservations
Reservation 1 n
octets 4
TX OP Reservation field
Duration
Service Interval
Start time
Octets 1 2
The Duration in multiples of 32µs.
The Service Interval (SI) in multiples of 1ms
The Start time is the lower order 2 octets of
the TSF timer value at the start of the first SP
Graham Smith, DSP Group

8. TSPEC Requirements Request
November 2009
TSPEC Requirements Request
The TSPEC Requirements Request frame is used by an AP
to direct a non-AP STA to send ADDTS Requests for all its potential TSPECs
Category, Action, Dialog Token
Graham Smith, DSP Group

9. 11 MLME November 2009 QLoad Element
The QLoad element is contained in a public action frame that
is provided by an AP and optionally, periodically in the Beacon.
The QLoad Report public action frame is transmitted upon the
receipt of a QLoad Report Request.
Whenever there is a change in the contents of the QLoad Element,
an unsolicited QLoad Action frame should be transmitted.
Graham Smith, DSP Group

10. Values in QLoad Element
November 2009
Values in QLoad Element
The values in the QLoad Field shall be derived by one or more of three methods:
Send TSPEC Requirements Request (if STA supports). STA responds with TSPECs that it wishes to be included in the QLoad.
At any time a STA sends TSPEC that it wishes to be included in the QLoad. Note: The STA may set the Inactivity Interval to a low value so that the TSPEC is deleted after the TSPEC response
Noting TSPECs as they arise (AP decides whether to keep or not after DELTS)
EDCA Priority Streams
The number of AC2 and AC3 streams that make up the peak composite traffic
are included in the QLoad. These are used to calculate the EDCA BW Factor
As per 09/1137r0, allocated Medium Times do not include contention overhead.
The number of streams is used to calculate the “EDCA Bandwidth Factor”
The recommended formula is provided in Annex (Informative)
Graham Smith, DSP Group

11. Allocated Traffic Self and Shared
November 2009
Allocated Traffic Self and Shared
Allocated Traffic Self
The Allocated Traffic Self indicates the total allocated QoS traffic, and is expressed as a Mean and Standard Deviation in units of 32µs, plus the number of AC2 and AC3 streams. As the AP adds new streams, this field changes
Allocated Traffic Shared
The Allocated Traffic Shared is the sum of Allocated Traffic Self values for all overlapping APs including self
As per 09/1136r0, the problem of an AP in the middle of two APs that are hidden from each other, requires that the AP in the middle needs to advertise the “shared” traffic value so as to avoid being shut out. The two fields are used to enable the On-Demand Sharing scheme.
Graham Smith, DSP Group

12. Access Factor Access Factor
November 2009
Access Factor
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 the QLoad of self and all the visible QAPs
Multiply the two to obtain the “Access Factor”
This field is used to indicate the potential load, or overload of the OBSS, and is used in the Proportional Sharing scheme.
Graham Smith, DSP Group

13. HCCA Peak and Access Factor
November 2009
HCCA Peak and Access Factor
“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

14. HCCAOP Advertisement Scheme
November 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

15. Annex aa - Informative Recommendations on:
November 2009
Annex aa - Informative
Recommendations on:
How to calculate values in QLoad fields
Channel Selection
Sharing
Proportional
On-Demand
Graham Smith, DSP Group

16. MEAN and STDEV calculations
November 2009
MEAN and STDEV calculations
As per 09/496r2 and 09/497r2, it is recommended that the mean (MEAN), maximum (MAX) and minimum (MIN) values of the Medium or HCCA Medium Times, are calculated using the values provided in the individual TSPECs, as follows:
For a TSPEC for stream, i, the mean value, µ, is:
µi = MEANi
and the standard deviation, σ, is:
σi = 0.25 sqrt{(MAXi – MINi)2}
or, if the MIN value is not provided
σi = (MAXi – MEANi)/2
Note that if neither the MAXi nor the MINi values are provided, then σi = 0
The values reported in the QLoad and Allocated Traffic fields represent the composite stream of all the individual streams and it is recommended that they are calculated as follows:
MEAN µtot = ΣMEANi
STDEV σtot = sqrt(Σσi2)
The Peak value is calculated as:
PEAK = Mean + 2 x STDEV
Graham Smith, DSP Group

17. November 2009
EDCA BW Factor
The Medium Time does not include the access time (SIFS, AIFSN, Contention Window) and for two or more streams, there is also the time when each packet is delayed while another stream is being transmitted.
Number of Streams
EDCA BW Factor
VI or VO
only,
one VO plus VI
2 or more
VO plus 1 - 2
1.40 3
1.50
1.55 4+
1.60
The recommended EDCA Bandwidth overhead factor is subject of 09/1137r0 and is provided in Table aa1:
NOTE: As the factor does not increase for streams over four, 4 bits for each AC field is adequate in the QLoad and Allocated Traffic fields
Graham Smith, DSP Group

18. Allocated Traffic Self
November 2009
Allocated Traffic Self
Allocated Traffic Self represents the total composite stream that the AP has allocated at any one time. It is recommended that as each stream is added or deleted, the AP should calculate the mean and standard deviation of the resulting composite stream. The field also includes the total number of EDCA streams that are now admitted for this AP.
It is recommended that the values of the mean and standard deviation placed in the Allocated Traffic Self field, for i allocated streams is calculated using:
MEAN = ΣMEANi
STDEV = sqrt(Σσi2)
Graham Smith, DSP Group

19. Allocated Traffic Shared
November 2009
Allocated Traffic Shared
Allocated Traffic Shared is the sum of the values expressed in the Allocated Traffic Self field of all overlapping APs, including its own Allocated Traffic Self. It is recommended that the values of the mean and standard deviation, placed in the Allocated Traffic Shared field, for n overlapping APs is calculated using:
MEAN = ΣMEANn
STDEV = sqrt(Σσn2)
In addition, the sums of the AC2 and AC3 streams provided in the Allocated Traffic Self field of all overlapping APs, including its own Allocated Traffic Self, are included in this field.
Note: This field is required in order to overcome the “AP in the middle” problem as per 09/1136r0
Graham Smith, DSP Group

20. November 2009
Access Factor
The Access Factor is the total traffic requirement for all the overlapping APs expressed as a fraction that may be greater than 1. It is recommended that the Access Factor be calculated from the addition of all the QLoads of the APs that are overlapping as follows:
First calculate the Overlap Traffic for all the overlapping APs. Each AP should note the reported QLoads for every overlapping AP, including the AP’s own QLoad, and calculate the maximum traffic of the composite stream, using the formula:
Overlap Traffic = µtot + 2 σtot
Where, for i QLoads, µtot = ΣMEANi and σtot = sqrt(Σσi2)
Add the number of AC_VO and AC-VI streams advertised in the EDCA Priority Fields and calculate the EDCA BW Factor
Multiply the Overlap Traffic by the EDCA BW Factor
Note: This field also overcomes the “AP in the middle” problem as per 09/1136r0 and is used in the Proportional Sharing scheme
Graham Smith, DSP Group

21. Access Factor and HCCA Access Factor
November 2009
Access Factor and HCCA Access Factor
QLoads, Medium Time and TXOPs are all measured in 32us/sec
Access Factor and HCCA Access Factor can be > 1
To express in 1 octet (example provided in Annex aa)
8 bits for the decimal fraction, expressed as a fraction rounded down to 1/64
Example: Sum = in 32us/sec = seconds
x 64, rounded down = 152
Hence, octet would be [2 and 24/64 = 2.375]
Maximum value would be 3.98
Graham Smith, DSP Group

22. November 2009
Channel Selection
Channel Selection recommended in the following procedure:
Check if the APs that are advertising Admission Control and/or HCCA support, i.e. QAPs
Select the channel(s) with the least number of QAPs
If more than one channel, send out QLoad Requests
Select channel with least Overlaps
If more than one channel, select channel with lowest QLoads
Graham Smith, DSP Group

23. November 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
Two Recommended Sharing Schemes
Proportional Sharing
Uses Access Factor
On Demand Sharing
Uses Allocated Traffic Self and Shared fields
Graham Smith, DSP Group

24. Proportional Sharing November 2009
The AP examines the Access Factor in the QLoad Reports from each overlapping BSS, including its own QLoad, and determines the maximum Access Factor
If the maximum Access Factor is less than or equal to 1, an AP may allocate up to its advertised QLoad traffic.
If the maximum Access Factor is greater than unity, then the AP may only allocate up to a value of its QLoad divided by the maximum Access Factor.
Steps if Access Factor >1:
Calculate the peak traffic value of the Qload, using:
Peak = MEAN + 2 STDEV
Divide this value by the maximum Access Factor. This is termed the maximum allowable Qload traffic
Calculate the resulting value of the Allocated Traffic Self if the new TSPEC is accepted, and then calculate the resulting peak value using
If the resulting peak value, calculated in step 3 is less than the maximum allowable QLoad traffic, OK
If new stream is HCCA TSPEC then AP needs to check HCCA Access Factor and schedule using the HCCA TXOP Advertisement
Note: The advertised Allocated Traffic Self could indicate if the AP is cheating
Graham Smith, DSP Group

25. On-Demand Sharing November 2009
Before allocating a new stream, the AP examines the Allocated Traffic Shared values in the QLoad Reports from each overlapping BSS, including its own QLoad, and selects the maximum Allocated Traffic Shared value which has the highest peak value, using:
Peak = MEAN + 2 STDEV.
The AP also notes the number of AC2 and AC3 streams in this maximum Allocated Traffic Shared Field.
The AP adds the requested new stream (new) to the selected maximum Allocated Traffic Shared value (max) determined in step 1, using:
MEAN = MEANnew + MEANmax
STDEV = sqrt(STDEV2new + STDEV2max)
The AP then calculates the peak value for the new composite stream calculated in step 3 , using:
Peak = MEAN + 2 STDEV
Using the values of the AC2 and AC3 streams noted in step 2, plus the new stream, the AP determines the new EDCA BW Factor
Multiply the peak value calculated in step 4 by the EDCA BW Factor, determined in step 5. This is the new Peak Traffic requirement
If new ‘peak value” <=1 then OK
If new stream is HCCA TSPEC then AP needs to check HCCA Access Factor and schedule using the HCCA TXOP Advertisement
Note: If, using either the proportional or on-demand sharing schemes, an AP determines that the acceptance of a TSPEC would exceed the available allocation, or a STA has a TSPEC refused, the STA could always request a new TSPEC that represents a lower Medium Time or TXOP. This may be used, for example, where the STA or AP has the ability to send a more compressed stream.
Graham Smith, DSP Group

26. Responses to Comments Major Comments included here.
November 2009
Responses to Comments
Major Comments included here.
Some have resulted in text changes (where indicated)
Other previous Comments resulted in changes
to the original text and were instrumental in the
the decision to add Annex aa
Graham Smith, DSP Group

27. November 2009
HCCA TXOP Advertisement should not be limited to HCCA. MCCA was applied to EDCA.
Response:
To mirror what MCCA does we would have to switch off networks in turn. To do this we need to keep all STAs in a network quiet to allow overlapping network to transmit. We could not see a way of doing this with legacy EDCA STAs, e.g. Quiet Periods, PCF, QoS CF Polls. Hence the Access Factor and EDCA Bandwidth factor are used to allow the EDCA to overlap.
Graham Smith, DSP Group

28. Building QLoad with TSPEC inactivity interval set to 1
November 2009
Building QLoad with TSPEC inactivity interval set to 1
Comment: This is a very poor idea. The non-AP STA can never undo/change such a TSPEC. Inactivity Interval needs to be set properly (e.g. to 24 hours), if after nearly 24 hours it is still applicable, the client should send it again with a new update. If it is no longer applicable, the client should send a DELTS. Otherwise the only way for an AP to maintain current information is to send a TSPEC Requirements Request to every client every few seconds (or faster?)
Response: The setting of the Inactivity Interval to 1 has been removed from the text. The basic idea is for STAs to have an opportunity to inform the AP as to what they are, and for the AP to advertise its peak or potential loading. This is a major part of this proposal and addresses an aspect of QoS not considered before. Previous QoS Elements only advertise their current condition, and this does not reflect the true loading and this is an important parameter for channel selection. The AP can send the TSPEC Requirements Request whenever it wants, clearing the load. A STA can send any inactivity interval in the TSPEC if it wishes, it is up to the AP to do with it what it will, a low value would cause the TSPEC to expire after the ADDTS response.
Graham Smith, DSP Group

29. November 2009
In TXOP Reservation , for video, given the 24 Hz and 60Hz sources, 1ms is actually a poor choice
Why not have 1ms if MSB is 0, but if MSB is 1, then 1/960 seconds. Or because I’ve just taken a bit, 2ms and 1/480 seconds?
Responses:
In the TSPEC the SI fields are 4 octets long, specifying in units of 1us. In all the TSPECs that have/had been proposed in the WFA work for WMM Admission Control and WMM-SA, the SI fields were always a multiple of 1ms, actually units of 10ms would have worked – hence we chose 1ms to be frugal
The standards offer both 60 frames/sec plus 60 * 1000/1001 (about 59.94) frames/sec and 24 frames/sec plus 24 * 1000/1001 frames/sec (about  23.98) frames/sec. There is no common denominator that can cover all of these, except for the prime ratio of 1000/1001. Therefore, the choice of 1 ms is no worse than any other value.
Happy to discuss and be persuaded, but consider 1ms is adequate
Graham Smith, DSP Group

30. QLoad Report Request and QLoad Report are terrible names
November 2009
QLoad Report Request and QLoad Report are terrible names
Maybe QLoad Parameter Set or QLoad Information, or something similar is better.
Response:
We thought we were following convention with similarly named exchanges from 11k and 11v. Did want to make clear that the QLoad Report used the QLoad element
Happy to discuss and be persuaded in Comments
Graham Smith, DSP Group

31. November 2009
Access Fraction: Integer and fractional descriptions are always needlessly complicated.
Make it in units of 32us per second, and note that it may exceed 100%, up to ~390%. Then define the max number as indicating the max or higher.
Response:
The idea proposed enables a fraction of 3.98 in one octet. Expressing same in multiples of 32us would require 3 octets. 2 octets provides maximum fraction of 2.10.
It is agreed that the “integer, fraction’ text is confusing and better to simply state ‘expressed as a fraction rounded down to 1/64”, this is now in the text
Graham Smith, DSP Group

32. EDCA Bandwidth Factor November 2009 Comment:
MAC experts I’ve spoken to do not believe that a simple formula exists to characterise EDCA overheads. This is most likely a dead-end.
Response:
This has been investigated in 09/1137r0, it is not that complicated, just that there are many cases and maybe the proposed formula is not 100% correct, but the need for it does exist and should be catered for. If it is omitted then there is a real danger that over allocation will occur as Medium Time does not include medium access overhead. We consider this is better than not having it. We moved the recommended values for EDCA BW Factor to the Annex so that an AP can use its own formulas, but it does highlight the need for an AP to take this into account. We also believe that the Table provided is pretty accurate and could be used with confidence. If necessary we could spend more time and produce a set of comprehensive tables covering all combinations, but doubt if any useful addition would result.
Will continue to produce results for many variables to see if the present Table could benefit from changes.
Graham Smith, DSP Group

33. Why Have Two Sharing Schemes?
November 2009
Why Have Two Sharing Schemes?
Comment
Do we need to support two sharing schemes? If so do we need a mechanism for APs to agree on the sharing?
Response
So far we have included the hooks for two schemes. Both will protect the AP in the middle scenario and also prevent over allocation. If we had just On-Demand we could omit the Access Factor but would want to retain the QLoad field indicating potential loads to assist in channel selection. Each scheme has merits for ‘guaranteed’ QoS; proportional provides long term repeatability, while on-demand provides short term efficiency. Consideration could be given for an exchange to agree a sharing scheme – could introduce Action Frames for this, but need some ‘agreement’ procedure. There are also two spare bits in the QLoad Element that could be used.
E.g. “Proportional”, “On-Demand”, “Don’t Care”?
Could Propose that AP advertises its preference using the two spare bits in the QLoad field.
Happy to discuss as an addition
Graham Smith, DSP Group

34. What is incentive to be a good neighbor?
November 2009
What is incentive to be a good neighbor?
Response
It is clear that in the case of the ‘AP in the middle’, the outer APs do need to give something up in order to allow the middle AP to work. It is also clear that an AP that finds itself in an Overlap 2 situation would be well advised to look for a better channel. Having said that, the QLoad element does provide enough information for any overlapping AP to determine if a particular AP is ‘cheating’ or over-allocating. Obviously, if one AP cheats then the others can cheat and chaos reign, maybe this is enough?
Welcome suggestions in Comments
Graham Smith, DSP Group