1 / 24

Proposed Overlapping BSS Solution

Proposed Overlapping BSS Solution. Authors:. Date: 2009, August 21. 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

keahi
Télécharger la présentation

Proposed Overlapping BSS Solution

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. Proposed Overlapping BSS Solution Authors: Date: 2009, August 21 Graham Smith, DSP Group

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

  3. Changes from 09/0757r0 • TSPEC Requirement Request now just requests a re-issue of TSPECs., i.e. TSPEC Requirement Response deleted • HCCAOP Advertisement Element used throughout and CHP deleted • QLoad information simplified • Only provide information on self • Delete QAP ID • Added HCCA Access Factor • QLoad Request / Report Public Action Frame option added • QoS Traffic and Overlap Element added, and then removed • “Sharing” description re-written for clarification • HCCAOP Advertisement Element simplified • Only provide Self Times Report • Back up slides removed • OBSS Definitions removed • Options discussions added • Straw Polls added Graham Smith, DSP Group

  4. Objectives of OBSS Proposal Provide the means for: • Meaningful Channel Selection • Co-operation between Admission Control QAPs • Co-operation between HCCA and Admission Control QAPs • Co-operation between HCCA QAPs Graham Smith, DSP Group

  5. Outline of Proposal • “Qload”: Element or Public Action Frame • Options are presented and discussed • 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 QAPs to avoid the TXOPs of overlapping QAPs • Used by both EDCA and HCCA • Recommendations to avoid/minimize OBSS problem • Channel selection based upon information in the QLoad Element: • Overlap • QLoad • Access Factor • Channel width selection 40/20MHz, based upon Overlap • How to use the fields in the QLoad Element for Sharing and to prevent over-allocation Graham Smith, DSP Group

  6. PROPOSED “QLoad Report” Public Action Frame Graham Smith, DSP Group

  7. Alternative – QLoad Element Graham Smith, DSP Group

  8. QLoad Self “QLoad” is the total QoS traffic that the STA There are three methods for the QAP to build QLoad Self: • QSTAs in the BSS may send a TSPEC (ADDTS) with Inactivity Interval set to 0 (or 1) for instant timeout • By sending in a TSPEC the STA has the QAP commit, in advance, medium time for the STA • QAP notes and adjusts for new TSPECs from QSTAs • If accepted, “QLoad Self”, and also “QLoad Total” are adjusted only when the QSTA submits the ADDTS • Chance that ADDTS is denied as QSTA did not reserve medium time in advance • In response to TSPEC Requirements Request • QAP request STAs to confirm (re-send) their TSPECs • Used by QAP to ‘clear house’ or initially set up Q Load. The QAP is advertising its own potential QoS load to other QAPs who may be considering sharing Graham Smith, DSP Group

  9. QLoad MEAN and STDEV MEAN and STDEV is estimated from the individual TSPECs: MEAN µ = ΣMEANi STDEV σ = 0.25 sqrt{Σ(MAXi – MINi)2} MEAN µtot = ΣMEANi STDEV σtot = sqrt(Σσi2) Total Traffic Requirement can be estimated: • MAX traffic = µtot + 2 σtot • 90% Traffic = µtot + 1.3 σtot • 80% Traffic = µtot + 0.83σtot Graham Smith, DSP Group

  10. TSPEC Requirement Request Request from QAP to a particular STA • Send All TSPECs (ID 1) • Effectively all previous (if any) TSPECs are deleted, need to set them up again This is the only new feature that would require the STA to do anything different. Not essential, but certainly has benefit. Sending TSPECs with Inactivity Interval set to 0 does not require any new specification Graham Smith, DSP Group

  11. Overlap • QAP indicates the number of other QAPs with which it is sharing and indicates the size of the OBSS graph: • Zero indicates QAP has no other QAPs on the same channel within range • 1 indicates already sharing with one other QAP • 2 indicates already sharing with two other QAPs • etc The QAP is advertising the overlap to other QAPs who may be considering sharing. This parameter should be included in the Channel Selection procedure in order to select the best channel (08/1470r4) IF QLOAD REPORT Possibly need to add Overlap to a Beacon Element as important to the Channel Selection process, or add a new one • Modify existing QoS related Element (QoS Traffic Capabilities?) • New (preferred) Graham Smith, DSP Group

  12. Access Fraction and Access Factor • Access Fraction • Total actual admitted time and/or scheduled time expressed as a fraction of 32us/sec rounded down to 1/256 • The Access Fraction is the total composite stream that the AP has allocated at any one time. • 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 self and all the visible QAPs • Multiply the two to obtain the “Access Factor” Graham Smith, DSP Group

  13. ACCESS FACTOR FIELD • QLoads, Medium Time and TXOPs are all measured in 32us/sec • Access Factor can be > 1 • 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 in 32us/sec = 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

  14. QAP Priority Streams • Number of EDCA Voice and Video Priority Streams using AC_VO and AC_VI • Used to estimate “EDCA Bandwidth Factor” • EDCA Bandwidth Factor = 1 + 0.05 N (approx; keep it simple, see 09/0497, based upon the default AC_VI settings) • Where N = Number of streams • Example: 4 streams Effective Bandwidth Factor = 1.2Four 5.5Mbps streams will require 1.2 x 4 x 5.5 = 26.5Mbps • Note: The EDCA Bandwidth Factor is advisory and more work may be required in order to describe how a QAP should derive and apply it. For example if QAPs were not using the default EDCA parameters. Graham Smith, DSP Group

  15. HCCA Peak • “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

  16. 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 • Sharing Scheme • QAPs should examine their QLoad Report 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, • Using the Access Fractions (actual “live” traffic), Access Factor and QLoad self, a decision can be made whether to admit a new request. • Rules will be recommended in informative text Graham Smith, DSP Group

  17. Medium Time, TXOP Allocations - General It is important to understand how the AP allocates the actual Medium Times and TXOPs in responses to TSPECs and checks that it has not exceeded its ‘limit’ • In response to each TSPEC the AP would normally allocate the Medium Time or TXOP (HCCA) that corresponds to the peak traffic. • When allocating a Medium Time or TXOP, the AP must calculate what the composite stream would be for that AP, and check that this composite medium time does not exceed the limit. The limit is the defined as follows: • If the Access Factor is <=1, an AP may allocate up to its advertised Self QLoad (composite stream calculated as MAX traffic = µtot + 2 σtot ) • If the Access Factor is >1, an AP may only allocate up a value of Self QLoad/Access Factor • Before allocating an HCCA TXOP, the AP must check the “HCCA Access Factor” and check that: • If the HCCA Access Factor is <=1, an AP may allocate up to its advertised “HCCA Peak” • If the HCCA Access Factor is >1, an AP may only allocate up to HCCA Peak/HCCA Access Factor Graham Smith, DSP Group

  18. Special Case when Overlap = 2 • If QAP (B) has Overlap 2, and the other QAPs (A and C) are each advertising Overlap 1, then QAP B should not include both QAPs A and C in its calculation of Access Factor • QAPs A and C are not visible to each other and therefore do not interfere, BUT both interfere with QAP B • QAP B, in this case, will take the larger QLoad value of QAPs A and C for calculating its Access Factor. • QAPs A and C will each calculate their Access Factors as normal, using the QLoad value advertised by QAP B Graham Smith, DSP Group

  19. PROPOSED “HCCAOP ADVERTISEMENT” ELEMENT Graham Smith, DSP Group

  20. HCCAOP Advertisement Element • HCCAOP Advertisement Element must be provided by an HCCA QAP • TXOP Reservation • Duration: In units of 32us • Service Interval (ms) • Start Time: Lowest 2 Bytes of TSF when the next TXOP after the beacon is scheduled Graham Smith, DSP Group

  21. 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

  22. Discussion QLoadElement or Public Action Frame? Option 1 - Element (14 octets) • Option 1A: Put in all Beacons and Prove Responses • Easiest option • Caters for passive as well as active scanning by AP looking for channel • Option 1B: Only include in Beacon when changed, but present in all Probe Responses • As per “Schedule Information element”, generated only when changed • In practice it is sent in x number of Beacons following the change • An AP would always send a Probe Response when looking for a spare channel, maybe a problem for ‘passive scanning” • DSF does not matter is AP is beaconing then all is well ‘radarwise” Option 2 - Public Action Frame • Requires both Request and Report action frames • Requires an entry in Extended Capabilities Element • To show AP supports QLoad • AP must send the Report Action frame (several times) when there is a change Personal preference – Option 1A or 1B Graham Smith, DSP Group

  23. Other Options • Do we maintain the MEAN and STDEV fields, or are they ‘over-the-top”? • Does allow better traffic allocation • Would save 1 octet • Difficult to calculate, adds burden? • If STDEV can be set to zero if AP does not want to use multiplexing Personal preference – keep it • QAP Priority Fields: 0, 1 or 2 octets? • Is the EDCA Factor understood enough to be useful? • Is 16 + 16 streams enough for one AP? • Would save 1 or 2 octet Personal preference – keep it but possibly reduce to 1 octet Graham Smith, DSP Group

  24. Straw Polls • Should the QLoad information be in an Element or Public Action Frames “Request / Report”? • Element • Public Action Frames • No preference • “QLoad” should report Mean and STDEV as against a single value (peak?) • Yes/No/No preference • Keep QAP Priority Streams field • Yes, as is • Yes, but reduce to 1 octet • Delete • No preference Graham Smith, DSP Group

More Related