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:

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0328r2 Submission Dense Apartment Complex Throughput Calculations Channel Selection and DSC Date: Authors: Graham Smith, DSP.
Advertisements

Doc.: IEEE /630r4a Submission S. Choi, Philips Research January 2002 Slide 1 HC Recovery and Backoff Rules Sunghyun Choi and Javier del Prado.
Doc.: IEEE /0012r0 Submission January 2013 Graham Smith, DSP GroupSlide mc Annex N Discussion/Proposals Date: Authors:
Dynamic Sensitivity Control V2
Doc.: IEEE /1012r0 Submission Sept 2013 Dynamic Sensitivity Control Improvement to area throughput Date: Authors: Graham Smith, DSP GroupSlide.
Submission doc.: IEEE 11-12/0420r2 March 2012 Fei Tong, CSRSlide 1 Providing extended range with limited transmission power in ah network Date: 14-March-2012.
Doc.: IEEE /0081r0 Submission January 2012 Osama Aboul-Magd, Huawei TechnologiesSlide 1 On Traffic Stream Setup for Audio/Visual Bridging Date:
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 10 Authors:
Doc.: IEEE /2684r0 Submission November 2007October 2007 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution Date: Authors:
Doc.: IEEE /1290r0 Submission Nov 2013 Dynamic Sensitivity Control for HEW SG Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0328r0 Submission Dense Apartment Complex Throughput Calculations Date: Authors: Graham Smith, DSP GroupSlide 1 Mar 2014.
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 15 Authors:
Doc.: IEEE /1489r0 Submission Nov 2013 Airport Capacity Analysis Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0717r1 Submission July 2008 Graham Smith, DSP GroupSlide Packets and MPEG Frames Background to Graceful degradation of audio.
Doc.: IEEE /0062r0 Submission Jan 2010 Alex Ashley, NDS LtdSlide 1 OBSS HCCA Race Condition Date: Authors:
Doc.: IEEE / aa Submission May 2009 Graham Smith, DSP GroupSlide 1 Considerations for Statistical Multiplexing Support in OBSS Proposal.
Doc.: IEEE / aa Submission November 2009 Graham Smith, DSP GroupSlide 1 Outline of Proposed Overlapping BSS Solution Date: 2009, November.
Doc.: IEEE /0328r1 Submission Dense Apartment Complex Throughput Calculations Date: Authors: Graham Smith, DSP GroupSlide 1 Mar 2014.
Doc.: IEEE /0014r0 Submission January mc TXOP Limits Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /1378r0 Submission November 2008 Darwin Engwer, Nortel NetworksSlide 1 Improving Multicast Reliability Date: Authors:
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Considerations for Statistical Multiplexing Support in OBSS Proposal.
Doc.: IEEE / aa Submission Feb 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: Authors:
Doc.: IEEE /0219r0 Submission Interworking with 802.1Qat Stream Reservation Protocol Date: Authors: Mar 2010 Ganesh Venkatesan,
Doc.: IEEE /0294r1 Submission Dynamic Sensitivity Control Channel Selection and Legacy Sharing Date: Authors: Graham Smith, DSP GroupSlide.
Resolutions to Static RTS CTS Comments
Doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution Date: Authors:
Doc.: IEEE /0126r1 Submission January mc HEMM Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0415r0 Submission April mc CIDs 1136,1118,1458 Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0212r3 Submission Feb 2016 TG ax Enterprise Scenario, Color and DSC Date: Authors: Graham Smith, SR TechnologiesSlide 1.
Doc.: IEEE / aa Submission November 2009 Graham Smith, DSP GroupSlide 1 EDCA Bandwidth Factor Date: 2009, November 17 Authors:
Doc.: IEEE /0635r1 Submission May 2014 Dynamic Sensitivity Control Implementation Date: 2014-May Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:
Overlapping BSS Proposed Solution – “OSQAP”
Overlapping BSS Proposed Solution
QoS Tutorial Date: Authors: Nov 2008 Nov 2008
Consideration on Interference Management in OBSS
Overlapping BSS Proposed Solution
120MHz channelization solution
Outline of Proposed Overlapping BSS Solution
Consideration on Interference Management in OBSS
Considerations for OBSS Sharing using QLoad Element
HCCAOP Scheme, Efficiency and Sharing
Consideration on Interference Management in OBSS
OBSS Sharing with Access Fraction
Empirical Formula for EDCA Bandwidth Factor
HCCAOP Scheme, Efficiency and Sharing
20/40MHz Channel Selection
OBSS Sharing with Access Fraction
Stray and Overlapping STAs
802.11e QoS Tutorial Date: Authors: Nov 2008 Nov 2008
Overlapping BSS Proposed Solution – “OSQAP”
HCCAOP Scheme, Efficiency and Sharing
OBSS HCCA Race Condition
Stray and Overlapping STAs
Proposed Overlapping BSS Solution
Proposed Overlapping BSS Solution
Applicability of 11s MCCA to HCCA OBSS
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Recommendation for EDCA Bandwidth Factor
Considerations for OBSS Sharing using QLoad Element
HCCAOP Scheme, Efficiency and Sharing
Comment resolution #79 Date: 2009, November 17 Authors: November 2009
OBSS Sharing with Access Fraction
Applicability of 11s MCCA to HCCA OBSS
OBSS Requirements Date: Authors: July 2008 July 2008
802.11e QoS Tutorial Date: Authors: Oct 2008 Oct 2008
Overlapping BSS Proposed Solution
AP Shut Out Neighborhood Effect
Triggered QoS Measurements
OBSS Requirements Date: Authors: July 2008 July 2008
Presentation transcript:

doc.: IEEE / aa Submission March 2009 Graham Smith, DSP GroupSlide 1 OBSS “OSQAP” QoS Issues Date: Authors:

doc.: IEEE / aa 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

doc.: IEEE / aa 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

doc.: IEEE / aa 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

doc.: IEEE / aa 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.

doc.: IEEE / aa 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

doc.: IEEE / aa 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

doc.: IEEE / aa 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

doc.: IEEE / aa 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?

doc.: IEEE / aa 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

doc.: IEEE / aa 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%

doc.: IEEE / aa 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’