OBSS Sharing with Access Fraction

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0012r0 Submission January 2013 Graham Smith, DSP GroupSlide mc Annex N Discussion/Proposals Date: Authors:
Advertisements

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 / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 15 Authors:
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 / aa Submission March 2009 Graham Smith, DSP GroupSlide 1 OBSS “OSQAP” QoS Issues 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 /0294r1 Submission Dynamic Sensitivity Control Channel Selection and Legacy Sharing Date: Authors: Graham Smith, DSP GroupSlide.
Doc.: IEEE /0097r0 SubmissionJarkko Kneckt (Nokia)Slide 1 Bandwidth Specific TXOP Limits Date: Authors: January 2011.
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 / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:
Synchronization of HCCA APs in OBSS
Overlapping BSS Proposed Solution – “OSQAP”
How to collect STAs’ Tx demands for UL MU
Overlapping BSS Proposed Solution
QoS Tutorial Date: Authors: Nov 2008 Nov 2008
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Consideration on Interference Management in OBSS
Overlapping BSS Proposed Solution
Dec 2008 doc.: IEEE /0xxx Nov aa –Robust Audio Video Transport Streaming Atlanta Opening Report Date: Authors: Graham Smith,
Outline of Proposed Overlapping BSS Solution
Consideration on Interference Management in OBSS
Random Access RU Allocation in the Trigger Frame
Class-based Contention Periods (CCP) for the n MAC
Considerations for OBSS Sharing using QLoad Element
Random Access RU Allocation in the Trigger Frame
HCCAOP Scheme, Efficiency and Sharing
Synchronization of HCCA APs in OBSS
Consideration on Interference Management in OBSS
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
TG ax A Unified Approach to Spatial Reuse
Interworking with 802.1Qat Stream Reservation Protocol
Proposed Overlapping BSS Solution
VTS SG PAR Scope Topics Date: Authors: January 2008
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
Proposed Resolutions of Some Comments Related to TSPEC Parameters
VTS Robust Multicast/Broadcast Protocol
HCCAOP Scheme, Efficiency and Sharing
Comment resolution #79 Date: 2009, November 17 Authors: November 2009
OBSS Sharing with Access Fraction
Scheduled Peer Power Save Mode for TDLS
TGbb MAC Channel Access features proposal
TGbb MAC Channel Access features proposal
Dec 2008 doc.: IEEE /0xxx Nov aa –Robust Audio Video Transport Streaming Atlanta Opening Report Date: Authors: Graham Smith,
Applicability of 11s MCCA to HCCA OBSS
802.11e QoS Tutorial Date: Authors: Oct 2008 Oct 2008
Overlapping BSS Proposed Solution
AP Shut Out Neighborhood Effect
WME Overview 7/20/03 doc.: IEEE /678r0 July 2003
Admissions Control and Scheduling Behaviours for Scheduled EDCA
Presentation transcript:

OBSS Sharing with Access Fraction May 2009 doc.: IEEE 802.11-08/0xxx May 2009 OBSS Sharing with Access Fraction Date: 2009-06-01 Authors: Graham Smith, DSP Group Graham Smith, DSP Group

May 2009 doc.: IEEE 802.11-08/0xxx May 2009 Abstract Presentation 09/0660r1 introduced the HCCAOP scheme for HCCA QAPs OBSS based upon the MCCAOP Advertisement Element used in 11s. In that element fields for Access Fraction and Access Fraction Limit are used. 09/0660r1 proposed adding these fields to the QLoad Element proposed for OBSS in order to provide a method for sharing between overlapping QAPs. This presentation studies how these fields may be used for Sharing. Graham Smith, DSP Group Graham Smith, DSP Group

May 2009 OBSS The OSQAP proposal introduced the QLoad Element for EDCA Admission Control and HCCA QAPs This element has evolved over several presentations and the latest form is given overleaf. Graham Smith, DSP Group

May 2009 Graham Smith, DSP Group

QLoad Element Fields May 2009 Overlap Number of APs that are sharing this channel and are overlapping Access Fraction (see 09/0660) based on MCCAOP Advertisment Access Fraction: Total actual admitted time and/or scheduled time expressed as a fraction of 32us/sec rounded down to 1/256 Access Fraction Limit: Maximum admitted time and/or scheduled time that this QAP may allocate (expressed as a fraction of 32us/sec rounded down to 1/256) QLoad MEAN and STDEV The mean and standard deviation of the total traffic presented to the QAP by TSPECs from STAs associated to that QAP (see 09/0496r2 and 09/0497r2) QAP ID First octet = random number (0 to 255) Second octet = octet 6 of MAC Address Once selected, QAP retains this ID Distance Distance is set to 0 for Self QAP ID Directly visible to the QAP Self, then “Distance” is set to 1 Not directly visible to the QAP Self, then “Distance” is set to 1 plus the value reported for that QAP ID in the QAP that is directly visible Any QAP with Distance” > 2 is not recorded in QLoad Element Graham Smith, DSP Group

Using the Access Fraction Fields In QLoad Element May 2009 Using the Access Fraction Fields In QLoad Element Access Fraction (as per MCCAOP) Total actual admitted time and/or scheduled time Use is straightforward. QAP reports what it is doing at that moment. Access Fraction Limit (AFL): Maximum admitted time and/or scheduled time Use is clear. How it is set, is not clear – how to use for Sharing? Observations: The AFL refers to the QAP itself and hence sets the maximum allocation for that QAP. For the AFL to be meaningful for all QAPs in the OBSS, they must all use the same “rule” for setting AFL If we had a “rule”, then the advertising of the AFL would be solely to act as a check that the QAP was applying the rule correctly Could “the rule” have variations? If so, how does the OBSS know which “rule”? Want to look deeper into how to use this for Sharing Graham Smith, DSP Group

QLoads All QAPs report their QLoads in the form of : May 2009 QLoads All QAPs report their QLoads in the form of : MEAN and STDEV This allows the summing of the QLoads to take account of the distributed nature of the traffic Total Traffic Requirement can be estimated (see 09/0497r2) MEAN µtot = ΣMEANi STDEV σtot = sqrt(Σσi2) 100% MAX traffic = µtot + 2 σtot 90% Traffic = µtot + 1.3 σtot 80% Traffic = µtot + 0.83σtot In addition EDCA overhead is required 1 + 0.05 N (N = # of directly competing streams, i.e. Distance =1) Graham Smith, DSP Group

Sharing Method by way of example May 2009 Sharing Method by way of example Example used is 4 QAPs with 3 Video streams as per below QAP TRAFFIC A 2 DVD streams 1 HDTV B 3 SDTV Streams C 1 HDTV 1 DVD 1 SDTV D 2 DVD 1 SDTV Video Streams, Fractions of Bandwidth Bandwidth 65 Mbps MEAN MAX STDEV DVD 0.085 0.123 0.019 SDTV 0.062 0.092 0.015 HDTV 0.231 0.308 0.038 Video Streams, Mbps MEAN MAX STDEV DVD 6 8 1.25 SDTV 4 1 HDTV 15 20 2.5 Graham Smith, DSP Group

May 2009 Summing of Times At first sight, the “total” Requirement will be the sum of all the QLoads of the QAPs in the QLoad Element “A + B + C + D” BUT, in this example, QAP D can re-use the time of QAP A (and vice versa) as they are at Distance 3 from each other QAP B has QAP D in its QLoad Element, at Distance 2 and can see that QAP A does not have QAP D in its QLoad Element. Therefore, QAP B knows that QAP D and QAP A are at Distance 3 and re-use can happen. Therefore the Total Requirement is “B + C + (A or D)” (whichever is the larger) In our example, QLoad shows QAP and Distances as: A0 B1 C2 B0 A1 C1 D2 C0 B1 D1 A2 D0 C1 B2 QAP B looks for D in QAP A QLoad Not present, so knows A and D can re-use time Hence, B takes the greater Self QLoad of A and D Graham Smith, DSP Group

Summary of QLoad Elements May 2009 Summary of QLoad Elements QAP # Streams SELF Distance OTHER TOTAL Mean STDEV A B C D 3 0.40 0.05 1 2 (3) 0.56 0.96 0.07 0.18 0.03 0.78 0.38 0.58 0.23 0.79 0.06 B + C + A A>D # streams EDCA QAP (Direct) Factor A 6 1.3 B 9 1.45 C D Graham Smith, DSP Group

May 2009 Traffic Requirements ignoring EDCA QAP SELF TOTAL (visible) 100% 90% 80% A 0.49 0.46 0.44 1.10 1.05 1.02 B 0.24 0.22 0.21 C 0.47 0.41 D 0.29 0.27 0.26 0.92 0.87 0.84 Traffic Requirements with EDCA Factor QAP SELF TOTAL (visible) 100% 90% 80% A 0.64 0.60 0.57 1.43 1.37 1.33 B 0.34 0.32 0.30 1.60 1.53 1.48 C 0.68 0.63 D 0.38 0.35 0.33 1.19 1.13 1.10 Example chosen to deliberately cause “Overload” so as to look at “Sharing” As can be seen, the EDCA Factor does have a significant effect 100, 90 and 80% does not seem, in this case, to make a significant difference Graham Smith, DSP Group

May 2009 SHARING PROCEDURE Intention is to reduce the worse “Total” to unity. In this example this refers to QAPs B and C. The following procedure achieves this. Each QAP calculates its 100% traffic Each QAP examines its QLoad Element for QAPs at Distance 2 and then checks to see if that QAP is not present in any QAP at Distance 1. The larger of QLoads is then used. Each QAP calculates the 100% traffic for all QAPs in QLoad Element, taking account of re-use Each QAP then applies its EDCA Factor This Value, “Access Factor (AF)”, must be advertised in the QLoad Element In order to make the Total Traffic at QAP B unity, then: The Self Traffic that each QAP can allocate is reduced by largest value of “AF” in its QLoad Element Hence, because of “EDCA Factor” AND “Access Factor”, in our example QAP A Self Traffic = 0.49 Allocation Limit = 0.31 QAP B Self Traffic = 0.24 Allocation Limit = 0.15 QAP C Self Traffic = 0.47 Allocation Limit = 0.29 QAP D Self Traffic = 0.29 Allocation Limit = 0.18 THEREFORE THE “ACCESS FRACTION LIMIT” FIELD IN “QLOAD ELEMENT” IS MODIFIED TO BE “ACCESS FACTOR” Graham Smith, DSP Group

ACCESS FACTOR FIELD Medium Time and TXOPs are all measured in 32us/sec May 2009 ACCESS FACTOR FIELD Medium Time and TXOPs are all measured in 32us/sec Access Factor can be > 1 32us/sec = 31,250 per second which is 15 bits Use 2 octets for Access Factor gives maximum = 2.09712 Is this enough? Too precise? 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 = 74268 = 2.376576 seconds Hence, octet would be 10 01100 [2 and 24/64 = 2.375] Maximum value would be 3.98 Graham Smith, DSP Group

“Access Factor” in QLoad Element May 2009 “Access Factor” in QLoad Element In the QLoad Element proposed in slide 4, the “Access Fraction Limit” is replaced with “Access Factor” “Access Fraction” and “Access Factor” are 1 octet each “Access Factor” is the total traffic requirement for all overlapping QAPs, derived from the sum of the traffic of all QAPs in the QLoad Element. The Access Factor also should include the “EDCA Factor” to account for the overhead required due to multiple priority streams. QAPs should examine their QLoad Element 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. The procedure for calculating Access Factor, as per previous slide, shall be detailed in the Specification Graham Smith, DSP Group

May 2009 Graham Smith, DSP Group

Medium Time Allocations May 2009 Medium Time Allocations It is important to understand how the AP allocates the actual Medium Times in responses to TSPECs and checks that it has not exceeded its ‘limit’ Obviously, in response to each TSPEC the AP allocates the Medium Time that corresponds to the peak traffic When allocating an additional Medium Time, the AP must calculate what the composite stream would be, and check that this composite medium time does not exceed the limit It is this composite time, that is advertised in the Access Fraction Note that the actual sum of the Medium Times will be greater than the composite time, but EDCA only uses what it needs, and hence the statistical nature of the streams causes the composite time to be the maximum of what is actually being used. Graham Smith, DSP Group

May 2009 Conclusion By including the “Access Factor” field in the QLoad Element, it is possible for all overlapping QAPs to allocate streams such that they do not cause over-allocation in other overlapping QAPs The method by which the “Access Factor” may be used to prevent over-allocation has been described The calculation of Access Factor must include the method of determining re-use of QAPs at Distance 3 How to use the Access Factor for Sharing is further discussed in 09/0666 Graham Smith, DSP Group