1. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 1 OBSS “OSQAP” QoS Issues Date: 2009-16-03 Authors:

2. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 2 Abstract The main objective of this presentation is to examine and discuss the QoS issues related to OBSS and the proposal “OSQAP” When presenting 09/0230r0, the concept of peak traffic arose. An objective of this presentation is to clarify how traffic allocation is handled

3. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 3 QLoad Element OSQAP introduced QLoad Element, including: –QLoad Self –QLoad Total –Overlap QLoad Self Potential QoS traffic for this QAP (as per Medium Time) QLoad Total Potential QoS traffic for sharing QAPs, NOTE: If QLoad Total>Q Load Self, indicates sharing Overlap Number of APs that are sharing this channel and are overlapping

4. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 4 Qload Self Proposal is that QAP builds up the QLoad self by: 1.QSTAs sends a TSPEC with Inactivity Interval set to 0 (or 1) for instant timeout 2.QAP remembers TSPECs associated with QSTAs Idea is that the QAP is advertising its potential load to other QAPs who may be considering sharing If QSTA disassociates, the QLoad Self adjusts accordingly

5. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 5 QLoad total QLoad total indicates the total potential (peak) Qload of ALL QAPs that are overlapping, both directly and indirectly If QLoad total <100%, then each sharing QAP can allocate its Qload self traffic If Qload total >100%, then this indicates that an over allocation situation exists Note: “100%” is meant to indicate the total bandwidth capacity, not necessarily 100% of the bandwidth.

6. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 6 Example #1 Extended Adding new QAPs is straightforward using defined Rules Adding to QLoad Self is straightforward using defined Rules Also note that each QAP is aware of the hidden QAPs Overlaps are: A = 2:2:1; B = 2:2:1; C = 1:2; D = 1:2

7. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 7 QLoad Total value The QLoad Element provides all the information required to allow the OBSS networks to carry out a “policy” for sharing and allocation If QLoad Total <100% then there is no policy required, each QAP can allocate its QLoad Self traffic knowing that there is sufficient bandwidth If QLoad Total >100% then a sharing policy is required and ONLY if >100% Note: QAPs should use the QLoad total, advertised in the QLoad Element to avoid joining QAPs with high QLoad Total

8. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 8 Results from “08/1470r4“ Zero or One overlap is almost guaranteed for 20MHz channels Suggestions made for dropping from 40 to 20MHz i.e. Typical condition is not to have multiple overlaps

9. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 9 Sharing Options First Come First Served –Each QAP allocates its traffic as it arises. –As QLoad Total is a PEAK traffic indicator, there exists a probability that ALL traffic being allocated together – hopefully not 100% –Possibility exists that quality does get hit –Dependent upon actual QLoad Total value (what if 200%?) Proportional Sharing –Each QAP reduces its QLoad Self in proportion e.g. If QLoad Total = 120%, QLoad Self = 60% Allowable allocation = 60 x 100/120 = 50% –Playing safe – too safe?

10. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 10 Proposal For QLoad Total up to X% –Allocation shall be “First Come First Served” For QLoad Total above X%, –Each QAP shall reduce its allocation capacity by 100/Y, where Y% is the QLoad Total and Y>X

11. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 11 X% What value for X? Points: –If QLoad Total was high one would hope that QAPs would not willingly share anyway – X could be seen as “limit” for joining –Video traffic tends to be long term, hence, unlike voice, say, peak to mean traffic may be closer than ‘normally assumed’ –Could use Poisson distribution, but what durations should be used? Hours? –Pick a number? Not too big as possibility does exist that over- allocation will occur –Suggest X = 120%

12. doc.: IEEE 802.11-09/0347-00-00aa Submission March 2009 Graham Smith, DSP GroupSlide 12 SUMMARY Concept of advertising Peak Traffic loads is useful –QAPs considering sharing can use this –As long as QLoad Total is <100%, there is no conflict If QLoad Total > 100% and <120%: –First Come First Served Each QAP may allocate traffic up to its Qload Self If QLoad Total > 120%: –Each QAP shall reduce its allocation capacity by 120/Y, where Y% is the QLoad Total –Note that the QLoad Self value does not change. ALTERNATIVES Declare “Out of Scope” Suggest/define with ‘informative text’