Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:"— Presentation transcript:

1 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:

2 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 2 Abstract Presentation 08/0457r4 examined the OBSS problem and outlined possible solutions Presentation 08/1260r1 further expanded on a solution, “OSQAP” Presentations 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 gave the details of the revised OBSS proposal based upon the previous work This presentation is based upon the work to date and defines the proposed OBSS solution

3 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 3 Objectives of OBSS Proposal Provide the means for: 1.Meaningful Channel Selection 2.Co-operation between Admission Control QAPs 3.Co-operation between HCCA and Admission Control QAPs 4.Co-operation between HCCA QAPs Proposal 1.New IE “QLoad” Includes values for Overlaps, Qload Self, Qload Total Used for Channel Selection and Channel Sharing CHP bit used for HCCA 2.New use for Wireless DS (AP to AP), QoS CF-Poll (null data) Control of shared TXOPs for HCCA 3.Recommendations to avoid/minimize OBSS problem –Channel selection based upon: QAP Overlap QLoad Received Signal Strength –Channel width selection 40/20MHz

4 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 4 Definitions and OBSS Graph Length(OBSS graph) – longest shortest path between any two APs in the OBSS graph OBSS Extent = length(OBSS graph) (used in 08/0285r0)_ Size(OBSS graph) – number of nodes (APs) in the OBSS graph OBSS Solution Minimum Requirement (accepted in Los Angeles, Jan ’09) length(OBSS graph) <= 2 and the size(OBSS graph) <=3 Overlap - Number of overlapping BSSs that are sharing this channel –Overlap is simple for a QAP to report –Overlap” does not by itself indicate the OBSS Size or Length BUT, There is a direct relationship between OBSS Length AND: –the probability of Overlap2 –the number of Channels –and the number of other APs within radio range e.g. If Probability of Overlap2 <1% then OBSS length<=2 and OBSSsize <=3 FOR MORE COMPLETE EXPLANATION, SEE SLIDES 24 - 29 Slide 4

5 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 5

6 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 6 QAP ‘Q Load Element’ - New Overlap Number of overlapping BSSs that are sharing this channel (4 bits, see slide 29) QLoad Self Potential/Peak QoS traffic for this QAP,in units of 32 µsec periods per second (as per Medium Time) QLoad Total Aggregate of “QLoad self” from all the QAPs in the OBSS graph, in units of 32 µsec periods per second Channel Priority Used only if QAP is operating with HCCA, indicates HCCA Supervisor. The Q Load Element is used to Aid in Channel Selection Determine the ‘sharing’ between overlapping QAPs

7 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 7 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) Note: See also “Backup” slides 24 – 33 for further information

8 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 8 QLoad Self and Total There are two methods for the QAP to build QLoad Self: 1.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 2.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 The QAP is advertising its own potential peak load to other QAPs who may be considering sharing If a QSTA disassociates, the QLoad Self and QLoad Totals adjust accordingly “QLoad Total” is the aggregate of QLoad Self from all the QAPs in the OBSS graph. If Overlap=0, then QLoad Self = QLoad Total

9 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 9 General Sharing Scheme Monitor the QLoad Element(s) in the Beacon(s) overheard from each overlapping QAP Intended for: – Sharing EDCA Admission Control QAPs –HCCA overlapping with EDCA Admission Control QAPs CHP bit is used for overlapping HCCA QAPs

10 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 10 Using the QLoad Element QLoad Rules/Operation: 1.QAPs keep a note of the QLoad Elements of their overlapping QAPs 2.For QAPs that are directly overlapping, “QLoad Total” MUST be the SAME for each QAP, e.g. a)If sharing with only one other, then “QLoad Total” is sum of the two “QLoad Self” b)If QAP is not sharing, then “QLoad Self” = “QLoad Total” 3.If a QAP increases or decreases its QLoad Self it must adjust its QLoad Total accordingly 4.If any overlapping QAP increases or decreases its “QLoad Total”, then the overlapping QAPs follow and set their “QLoad Totals” to be the same 5.If a QAP sees that a previously overlapping QAP is no longer overlapping, then it reduces its own “QLoad Total” by the “QLoad Self” of the QAP that has disappeared

11 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 11 Use of QLoad element 09/0230r0 shows ‘rules’ provide successful outcomes for: Examples of 2, 3 and 4 overlapping QAPs Example of a QSTA leaving a BSS Examples of QAPs leaving “QLoad Total” is correctly maintained for every QAP in the OBSS Graph even when OBSSsize is >4

12 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 12 QLoad Total and Sharing Rules 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 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

13 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 13 Sharing Suggestions (as per 09/0347r0) If QLoad Total is <100%, there is no conflict If QLoad Total >100% then two basic options: Option A – Peak Load Approach –Each QAP shall reduce its allocation capacity by 100/Y, where Y% is the QLoad Total Good argument that QoS streams, especially Video, do have a practical ‘peak hour” and this approach “guarantees” availability Option B – Hybrid Approach If QLoad Total > 100% and <120%: “First Come First Served” –Each QAP may allocate traffic up to its Qload Self If QLoad Total > 120%: “Proportional Sharing” –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. “Acceptable” danger that “peak hour” is not catered for

14 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 14

15 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 15 QLoad element “CHP Bit” for HCCA Described in detail in 09/230r0 HCCA QAPs have to co-operate more tightly as the TXOP allocation schedules need to be aligned CHP bit (Channel Priority) in the QLoad Element is used

16 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 16 Rules for Setting CHP bit and Sharing (per 09/230r0) When a HCCA QAP is searching for a channel, it should do so in the following order: 1.Set CHP (Channel Priority) to 0 2.If finds a clear Channel, set CHP to 1 3.If no clear channel, then may share with a)Any legacy AP: Set CHP to 1 b)An Admission Control QAP, overlap 0 or 1: Resulting HCCA QAP overlap being 1:1, or 1:2Set CHP to 1 (see Note 1) c)An HCCA QAP with CHP = 1 CHP stays at 0 (see Notes 1 & 2) 4.If an HCCA QAP cannot find a channel that meets the rules, it must fall back to Admission Control (see note 3) NOTES: 1.If 3b) or 3c), check that “QLoad Total” is such that the two can share 2.An HCCA QAP may not share with an HCCA QAP which has CHP = 0, unless it is also sharing directly with the corresponding HCCA QAP that has CHP = 1 3.Restriction on sharing with HCCA would not be applicable in practice if 17 or more channels are available. HCCA QAP should be able to find channel that meets requirement, See Slides 24 – 29.

17 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 17 Harmonizing HCCA When sharing use Fixed Time Slot –Each AP (HC) knows how much of the Time Slot it can use: QLoad Self –Supervisor AP (CHP=1) hands off to the other QAP(s) using Wireless DS QoS CF-Poll (Null Data) for AP-AP communication Supervisor QAP (CHP = 1) controls the 10ms slot timing Supervisor QAP sends message to other QAPs (CHP = 0) indicating time to start of their respective TXOP periods. Uses Wireless DS (AP to AP), QoS CF-Poll (null data) 09/0230r0 describes rules for when Supervisor QAP goes away and when two QAPs have CHP set to 1 “Supervisor Claim” and “Is Supervisor There” packets used.

18 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 18 Wireless DS QoS CF-Poll (Null Data) for AP to AP Communication AP to AP QoS CF-Poll Address Fields Function To DS From DS Address 1 Address 2 Address 3 Address 4 Wireless DS11RA = QAP B TA = QAP A DA =QAP B SA =QAP A AP to AP QoS CF-Poll Frame Type and Sub-type Type value b3 b2 Type Description Subtype value b7 b6 b5 b4 Subtype Description 10Data1110QoS CF-Poll (no data) Applicable Data Frame Bits 0-3Bit 4Bits 5-6Bit 7Bits 8-15 QoS CF PollTIDEOSP = 1 ACK PolicyAgg (11n)TXOP Limit QoS Control Field Use TID field as identifier

19 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 19 WDS QoS CF Polls To Supervisor from QAP with CHP=0 From Supervisor QAP with CHP=1 ACTION Bits 0-3Bit 4Bits 5-6Bit 7Bits 8-15 Indication from Supervisor to another QAP of Time to start TXOP (HCCA sharing) 11111100Time to start of TXOP in units of 32us Supervisor Claim, CHP = 1000110000 ACTIONBits 0-3Bit 4Bits 5-6Bit 7Bits 8-15 CHP is set to 0000010000 Is Supervisor There?001010000 * May not be required unless a more strict control of QLoad is needed

20 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 20

21 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 21 OBSS Proposal For all QAPs 1.Add new QLOAD Element 1.Channel Priority CHP 2.Slot time concept for HCCA 2.Use of TSPEC with Inactivity Interval set to 0 or 1 to build “QLoad” 3.Define sharing procedure by monitoring of QLoad Element of overlapping QAPs 4.Define procedure for Channel Selection (5GHz band only) including procedures for 20/40MHz channel use For HCCA QAPs Rules and procedures for Channel Selection and setting of CHP Rules and Procedures for Sharing Fixed 10ms Slot time for HCCA QAPs that share Use of Wireless DS QoS CF Polls (null data) for HCCA TXOP scheduling

22 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 22 BACKGROUND SLIDES OBSS Requirements Channel Selection Proposal Summary Poll

23 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 23

24 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 24 OBSS Requirement (from 09/0054r2) What is a OBSS graph? OBSS edge -- Any two APs operating in the same channel and can hear each other (either directly or via a STA associated to one of the APs) OBSS Graph – is a graph where APs are nodes of the graph and the edges are OBSS edges and every AP with in the OBSS graph can be connected via one or more OBSS APs to every other AP in the OBSS graph Length(OBSS graph) – longest shortest path between any two APs in the OBSS graph Size(OBSS graph) – number of nodes (APs) in the OBSS graph OBSS Solution Requirement (accepted in Los Angeles, Jan ’09) – if length(OBSS graph) <= 2 and the size(OBSS graph) <=3, enable the OBSS QAP solution otherwise (a) backoff to legacy (non.11aa) mode or (b) use a different solution Note: 08/0285r0 showed OBSSsizes up to 8 were likely with 10 Channels in dense apartment block scenario and argued size of 3 was not sufficient. 08/1470r4 also confirmed this with 9 and 11 channels. Slide 24

25 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 25 OBSS Size, Length and Overlap OBSS Size or Length difficult for an AP to directly indicate “Overlap” is simple for an AP to directly indicate “Overlap” does not by itself indicate the OBSS Size or Length

26 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 26 OBSS Size, Length and Overlap OBSS Length = 2 OBSS Size = 3 Overlaps A = 2, B = 1, C = 1 OBSS Length = 1 OBSS Size = 3 Overlaps A = 2, B = 2, C = 2 OBSS Length = 3 OBSS Size = 4 Overlaps A = 2, B = 2, C = 1, D = 1 Overlap <=2 But Length and Size above “spec” √ X √

27 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 27 OBSS Size, Length and Overlap Overlap of 2 does not directly indicate OBSS length BUT there is a direct relationship between OBSS Length AND: –the probability of Overlap2 –the number of Channels –and the number of other APs within radio range For OBSS length >2, there must be, at least: two Overlaps2 within the overlap area AND they must be on the same channel Calculation of Probability of this happening # of Channels = N; Prob of APs with Overlap2 = n; # of overlapping APs = M Probability of at least 2 Overlap2’s being in overlap area (binomial): Probability of no Overlap2 P0 = (1-n)^M Probability of one Overlap2P1 = M.n (1-n)^(M-1) Probability of two or moreP2 = 1 – P1 – P0 Probability of selecting same channel Probability of not selecting a certain channel Pc0 = (1-1/N)^n Probability of not selecting a certain channel just once Pc1 = n/N (1-1/N)^(n-1) Probability of selecting a certain channel at least 2 timesPc2 = 1 – P1 – P0 Probability of OBSS Length>2 = P2 x Pc2

28 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 28 OBSS Size, Length and Overlap Example: Double Apartment, 53 APs in range: –17 CH, (N=17, M=53) Probability of Overlap2 = 0.73% Probability of OBSS length > 2 = 0 –16 CH, (N=16, M=53) Probability of Overlap2 = 1.88% Probability of OBSS length > 2 = 0.08% –15 CH, (N=15, M=53) Probability of Overlap2 = 3.9% Probability of OBSS length > 2 = 1.4% Hence, in this case, for 99% service, at least 16CH are required 100% service for 17 or more Channels

29 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 29 Overlap Field Channel Selection simulations run as described in 08/1460r4 For Double Apartment scenario, (53 QAPs in range): –9CH maximum value of Overlap = 5 –8CHmaximum value of Overlap = 6 –7CHmaximum value of Overlap = 7 –3CHmaximum value of Overlap = 8 Hence, Overlap Field size made 4bits (0 - 15)

30 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 30

31 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 31 1 - Channel Selection Channel Selection Procedure: 1.Select Channel(s) with least number of APs 2.If more than one channel, select channel with least “overlaps” 3.If more than one channel, select lowest “QLoad Total” in “QLoad Element” Results dependant upon number of available channels –(see 08/1479r4 and 09/0285r0) 2.4GHz Band 3 CH maximum 5GHz Band20MHz USA 24 CH, Europe 19 CH 40MHz USA 11 CH, Europe 9 CH

32 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 32 Channel Selection Analysis (08/1470r4) Double Apartment 100% occupancy 53 overlapping apartments 17 CH (20MHz Channels) 99.3% probability of 0 or 1 channel overlap *Zero chance of length > 2 or size > 3 (<1 occurrence of 2 overlaps in 100 apartments) 9 CH (40MHz Channels) 28.5% probability of 0 or 1 overlap 41.6% probability of 2 ch overlap 30% probability of 3+ ch overlap *Zero chance of length < 2 many cases of size > 3 BUT Many dwellings will be able to use 40MHz channels 2.4GHz Band hopeless!

33 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 33 Channel Selection Analysis Summary If 17CH or greater, then Channel Selection can ensure OBSSlength <=2 in all scenarios examined With Channel Selection, Networks using 40MHz channels will have high percentage of no OBSS for all scenarios except dense apartments Channel Section is improved if ‘overlap selection’ is included

34 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 34 40/20MHz Channels If a QAP wanted to determine when to use 40MHz or 20MHz channel, then following procedure could be used: 1.If an 11n QAP cannot find a free channel using 40MHz, switch to using 20MHz If it still cannot find a clear channel, then it can settle on a 40MHz channel (secondary?) Rule #2 then comes into play 2.If an 11n QAP, using 40MHz, finds itself overlapping with more than one other QAP (20 or 40MHz) then it must switch to using 20MHz ( It may decide to search again using 40MHz, and then rule 1 applies Notes: 1.The primary intention is to avoid OBSSlengths > 2 2.It is assumed that it is in the QAP’s own interest to use an independent 20MHz channel rather than share a 40MHz channel

35 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 35 Channel Selection Summary Using suggested selection scheme: –17 available channels required to ensure OBSSlength <=2 and OBSSsize <=3 in most extreme scenario examined –Only applicable to 5GHz Band, 2.4GHz is a “lost cause” 20/40MHz 1.40MHz channels is fine for many scenarios 2.Suggested procedure for 40MHz channels to drop back to 20MHz when overlap and sharing exists in order to prevent excessive OBSS lengths

36 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 36

37 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 37 OBSS Proposal Summary “OSQAP” EDCA Admission Control networks can share An HCCA and one or more EDCA Admission Control Networks can share Two (three) HCCA networks can share –Although highly unlikely, an HCCA QAP will drop back to Admission Control when sharing not possible with other HCCA networks Scalable solution, does work for any OBSSlength If Channel Selection “Rules” are followed –For selection of best channel (see slide 29) –For 40MHz channels dropping to 20MHz (see slide 32) Then “OBSS length” =< 2 and “OBSS size” =<3 Proposed additions to the Standard are : Normative –“Q LOAD Element” –Use of Wireless DS QoS CF Polls (null data) for HCCA TXOP scheduling –Fixed 10ms Slot time for HCCA QAPs that share Informative –Rules for indicating overlap and QLoad sharing –Description of Channel Selection –Rules for 20/40MHz channels

38 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 38

39 doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 39 Straw Poll “It is recommended that the OBSS proposal, as described in 09/xxxxr0 be adopted in principle and further recommends that normative text should now be written” Y/N/A


Download ppt "Doc.: IEEE 802.11-09/0476-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:"

Similar presentations


Ads by Google