1 / 12

OBSS “OSQAP” QoS Issues

OBSS “OSQAP” QoS Issues. Authors:. Date: 2009-16-03. Abstract. The main objective of this presentation is to examine and discuss the QoS issues related to OBSS and the proposal “OSQAP”

oriel
Download Presentation

OBSS “OSQAP” QoS Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OBSS “OSQAP” QoS Issues Authors: Date: 2009-16-03 Graham Smith, DSP Group

  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 Graham Smith, DSP Group

  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 Graham Smith, DSP Group

  4. Qload Self Proposal is that QAP builds up the QLoad self by: • QSTAs sends a TSPEC with Inactivity Interval set to 0 (or 1) for instant timeout • 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 Graham Smith, DSP Group

  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. Graham Smith, DSP Group

  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 Graham Smith, DSP Group

  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 Graham Smith, DSP Group

  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 Graham Smith, DSP Group

  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 proportione.g. If QLoad Total = 120%, QLoad Self = 60% Allowable allocation = 60 x 100/120 = 50% • Playing safe – too safe? Graham Smith, DSP Group

  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 Graham Smith, DSP Group

  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% Graham Smith, DSP Group

  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 ServedEach 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’ Graham Smith, DSP Group

More Related