View
213
Download
1
Category
Preview:
Citation preview
Apr 2009
Graham Smith, DSP Group
Slide 1
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Proposed Overlapping BSS Solution
Date: 2009, July 15
Name Affiliations Address Phone email Graham Smith DSP Group 2491 Sunrise Blvd,
#100, Rancho Cordova, CA 95742
916 851 9191 X209
Graham.smith@dspg.com
Dan Dillon DSP Group 2491 Sunrise Blvd, #100, Rancho Cordova, CA 95742
916 851 9191 X205
Dan.dillon@dspg.com
John Janecek DSP Group 2491 Sunrise Blvd, #100, Rancho Cordova, CA 95742
916 851 9191 X208
John.janecek@dspg.com
Authors:
Apr 2009
Graham Smith, DSP Group
Slide 2
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Abstract08/0457r4 and 08/1260r1 examined the OBSS problem and outlined
possible solutions – “QLoad” introduced08/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 fields09/0660r3 examined using 11s MCCA for HCCA OBSS09/0662r2 introduced OBSS Sharing with Access Fraction09/0666r2 considered HCCAOP Advertisement Element for sharing
and TXOP avoidance
This presentation presents the proposed solution.
Apr 2009
Graham Smith, DSP Group
Slide 3
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Changes from 09/0757r0• TSPEC Requirement Request now just requests a re-issue of
TSPECs., i.e. TSPEC Requirement Response deleted (Slide 12)
• HCCAOP Advertisement Element used throughput and CHP deleted
• QAP ID now a two octet random number
• “Sharing” description re-written for clarification (slide 19)
• Interfering Times Report in HCCAOP Advertisement Element now only includes times from Self Times Reports from direct neighbor QAPs (Distance 1)
• Description of use of HCCAOP Advertisement re-written for clarification (Slide 22)
Apr 2009
Graham Smith, DSP Group
Slide 4
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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
Apr 2009
Graham Smith, DSP Group
Slide 5
doc.: IEEE 802.11-09/0757-01-00aa
Submission Slide 5
Definitions and OBSS GraphLength (OBSS graph) – longest shortest path between any two APs in the OBSS graph
OBSS Extent is related to the length (OBSS graph) (used in 08/0285r0)_Size (OBSS graph)– number of nodes (APs) in the OBSS graphOBSS 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 rangee.g. If Probability of Overlap2 <1% then OBSS length<=2 and OBSS size <=3
FOR MORE COMPLETE EXPLANATION, SEE BACKUP SLIDES
Slide 5
Apr 2009
Graham Smith, DSP Group
Slide 6
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Outline of Proposal1. New IE “QLoad”
• Used for Channel Selection and Channel Sharing
2. New Action Frame “TSPEC Requirement Request” • Used by QAP to STA to indicate or confirm their TSPECs
3. New IE “HCCAOP Advertisement Element”• Used by HCCA QAPs to avoid the TXOPs of overlapping HCCA
QAPs
4. 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
Apr 2009
Graham Smith, DSP Group
Slide 7
doc.: IEEE 802.11-09/0757-01-00aa
Submission
ElementID
LengthOverlap
And Prority
QAP (Self)
ID
QAP ID
Qload
1 1 2 2 6 22 VAR
Overlap and Priority
ReservedOverlap (4
bits)
Etc.For all QAPs
In OBSS Graph
QLOAD ELEMENT
2
QAPPriority
Streams6
Number AC3 streams Number AC2 streams
QAP Priority Streams
QAPPriority
Streams
Qload
b0 b13 b15
STDEV
b14
Distance
1
Access Fraction Factor
Access Fraction
bits
Access Fraction
8 6
bits 8 8
2
Access Factor Integral
Access Factor Fraction
Qload(Self)
STDEV and Distance
MEAN HCCA Peak
2 2 2octets
bits 4 4
PROPOSED “QLOAD” ELEMENT
Apr 2009
Graham Smith, DSP Group
Slide 8
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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 for further information
Apr 2009
Graham Smith, DSP Group
Slide 9
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Distance
• Distance is set to 0 for Self
• If QAP ID Directly visible to the QAP Self, then “Distance” is set to 1
• If 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
Apr 2009
Graham Smith, DSP Group
Slide 10
doc.: IEEE 802.11-09/0757-01-00aa
Submission
QAP ID
• 2 Octet Random Number
• Once established, QAP ID is not changed
• Enables a QAP to indentify its own QLoad in other QLoad elements
Apr 2009
Graham Smith, DSP Group
Slide 11
doc.: IEEE 802.11-09/0757-01-00aa
Submission
QLoad SelfThere are three 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
3. 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
Apr 2009
Graham Smith, DSP Group
Slide 12
doc.: IEEE 802.11-09/0757-01-00aa
Submission
TSPEC Requirement Request
Request from QAP to a particular STA
1. Send All TSPECs (ID 1)– Effectively all previous
(if any) TSPECs are deleted, need to set them up again
CATEGORYCODE
ACTIONCODE
DIALOGTOKEN
REQUESTID
1 1 11 = Send All TSPECs
TSPEC Requirement Request Action Frame
Apr 2009
Graham Smith, DSP Group
Slide 13
doc.: IEEE 802.11-09/0757-01-00aa
Submission
QLoad MEAN and STDEV
MEAN and STDEV is estimated from the individual TSPECs:
MEAN µ = ΣMEANi
STDEV σ = 0.25 sqrt{Σ(MAXi – MINi)2}
MEAN µtot = ΣMEANiSTDEV σtot = sqrt(Σσi
2)
Total Traffic Requirement can be estimated:1. MAX traffic = µtot + 2 σtot
2. 90% Traffic = µtot + 1.3 σtot
3. 80% Traffic = µtot + 0.83σtot
Apr 2009
Graham Smith, DSP Group
Slide 14
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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.
Apr 2009
Graham Smith, DSP Group
Slide 15
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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 the individual QLoads of all QAPs in the QLoad element as a composite stream
• Calculate the EDCA Bandwidth Factor from the total number of Priority Streams in the visible QAPs (Distance 0 and 1)
• Multiply the two to obtain the “Access Fraction” .
Apr 2009
Graham Smith, DSP Group
Slide 16
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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
Apr 2009
Graham Smith, DSP Group
Slide 17
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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 Element is
the “HCCA Access Factor” (which is provided in the HCCAOP Advertisement Element)
– 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
Apr 2009
Graham Smith, DSP Group
Slide 18
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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 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,
– Using the Access Fractions (actual “live” traffic), Access Factor and QLoad self, a decision can be made whether to admit a new request.
– Rules could be recommended in informative text.
Apr 2009
Graham Smith, DSP Group
Slide 19
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Medium Time, TXOP Allocations - SharingIt 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’
1. In response to each TSPEC the AP would normally allocate the Medium Time or TXOP (HCCA) that corresponds to the peak traffic.
2. 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 Self QLoad/Access Factor
3. 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
HCCA Peak/HCCA Access Factor
Apr 2009
Graham Smith, DSP Group
Slide 20
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Element ID
LengthHCCA
InfoSelf Times
ReportInterfering Times
Report
HCCA Access Fraction
Self Times Report Present
Interfering Times Report
Present
Octets 1 1 2 Variable Variable
1 166
Number of Reported TXOP Reservations
TXOP Reservation 1
TXOP Reservation N
Duration Service Interval Offset
Octets 1
1 1 2
4 4
Self Times Report
Number of Reported TXOP Reservations
TXOP Reservation1
TXOP Reservation N
Octets 1 4 4
Interfering Times Report
HCCA Access Factor Fraction
HCCA Access Factor Integral
2Bits
PROPOSED “HCCAOP ADVERTISEMENT” ELEMENT
Apr 2009
Graham Smith, DSP Group
Slide 21
doc.: IEEE 802.11-09/0757-01-00aa
Submission
HCCAOP Advertisement Element• HCCAOP Advertisement Element must be provided by an HCCA QAP and also by
an EDCA QAP that is a direct neighbor of an HCCA QAP.– A non-HCCA QAP will set “HCCA Access Factor”, HCCA Access Fraction” and “Self Times
Report Present” to zero• Access Fraction Fields
– HCCA Access Fraction: Total actual scheduled time expressed as a fraction of 32us/sec rounded down to 1/256
– HCCA Access Factor: Sum of “HCCA Peak” of all QAPs Distance 0, 1 and 2
2 bits for Integral (whole number)6 bits for the decimal fraction, expressed as a fraction rounded down to 1/64
• TXOP Reservation– Duration: In units of 32us– Service Interval (ms)– Offset: Beginning of first TXOP after a Beacon, relative to beginning of each scheduled
Beacon, in units of 32us
• Interfering Times Report– Includes the TXOPs of only QAPs at a “Distance” of 1, i.e. are directly visible
Apr 2009
Graham Smith, DSP Group
Slide 22
doc.: IEEE 802.11-09/0757-01-00aa
Submission
HCCAOP Advertisement Scheme• HCCA QAPs need to schedule TXOPs that do not interfere with the other
HCCA QAPs in the OBSS Graph. • This is achieved by the HCCAOP Advertisement Element which lists all
the TXOPs that have been already scheduled by the QAPs up to a “Distance” of 1 (see 09/0662)
• HCCA QAP looks at the HCCAOP Advertisement of direct neighbor QAPs (Distance 1), in order to select a TXOP time that does not interfere with any TXOP being advertised in either the Self or Interfering Times Reports
– Note that the neighboring QAPs will include the times for the QAPs at distance 2 in its Interfering Times Report, as well as any existing TXOP times for the QAP looking for the “space”
• QAP must check that allocating a new TXOP will not cause the total TXOPs of QAPs in the QLoad Element to exceed 1 sec/sec.
– See Slide 19• All times in the HCCAOP Advertisement Element are expressed in 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.
Apr 2009
Graham Smith, DSP Group
Slide 23
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Poll“Would you be interested in normative and informative
text corresponding to the OBSS proposal as described in 09/757r1?”
Y/N/A
Apr 2009
Graham Smith, DSP Group
Slide 24
doc.: IEEE 802.11-09/0757-01-00aa
Submission
BACKGROUND SLIDES• OBSS Requirements• Channel Selection• Proposal Summary
Apr 2009
Graham Smith, DSP Group
Slide 25
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Apr 2009
Graham Smith, DSP Group
Slide 26
doc.: IEEE 802.11-09/0757-01-00aa
Submission Slide 26
OBSS Requirement (from 09/0054r2)What is an 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 26
Apr 2009
Graham Smith, DSP Group
Slide 27
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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
Apr 2009
Graham Smith, DSP Group
Slide 28
doc.: IEEE 802.11-09/0757-01-00aa
Submission
OBSS Size, Length and Overlap
A
B
C
A B
C
OBSS Length = 2OBSS Size = 3
Overlaps A = 2, B = 1, C = 1
OBSS Length = 1OBSS Size = 3
Overlaps A = 2, B = 2, C = 2
A
B
C
D
OBSS Length = 3OBSS Size = 4
Overlaps A = 2, B = 2, C = 1, D = 1
Overlap <=2 ButLength and Size above “spec”
√
X
√
Apr 2009
Graham Smith, DSP Group
Slide 29
doc.: IEEE 802.11-09/0757-01-00aa
Submission
OBSS Size, Length and OverlapOverlap of 2 does not directly indicate OBSS lengthBUT 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 = MProbability of at least 2 Overlap2’s being in overlap area (binomial):Probability of no Overlap2 P0 = (1-n)^MProbability of one Overlap2 P1 = M.n (1-n)^(M-1)Probability of two or more P2 = 1 – P1 – P0Probability of selecting same channel Probability of not selecting a certain channel Pc0 = (1-1/N)^nProbability 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 times Pc2 = 1 – P1 – P0
Probability of OBSS Length>2 = P2 x Pc2
Apr 2009
Graham Smith, DSP Group
Slide 30
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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, 53 APs in range, for 99% service, at least 16CH are required
• 100% service for 17 or more Channels
Apr 2009
Graham Smith, DSP Group
Slide 31
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Overlap Field
• Channel Selection simulations run as described in 08/1470r4
• For Double Apartment scenario, (53 QAPs in range):– 9CH maximum value of Overlap = 5
– 8CH maximum value of Overlap = 6
– 7CH maximum value of Overlap = 7
– 3CH maximum value of Overlap = 8
• Hence, Overlap Field size made 4bits (0 - 15)
Apr 2009
Graham Smith, DSP Group
Slide 32
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Apr 2009
Graham Smith, DSP Group
Slide 33
doc.: IEEE 802.11-09/0757-01-00aa
Submission
1 - Channel Selection
Channel Selection Procedure:1. Select Channel(s) with least number of APs2. If more than one channel, select channel with least
“Overlaps” being advertised in the QLoad Element3. If more than one channel, select lowest “Access Factor” in
QLoad Element
Results dependant upon number of available channels – (see 08/1479r4 and 09/0285r0)
• 2.4GHz Band 3 CH maximum• 5GHz Band 20MHz USA 24 CH, Europe 19 CH
40MHz USA 11 CH, Europe 9 CH
Apr 2009
Graham Smith, DSP Group
Slide 34
doc.: IEEE 802.11-09/0757-01-00aa
Submission
Channel Selection Analysis (08/1470r4) Probability of Zero or One overlap
100% Assignment
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
24 22 19 17 11 9 3
Channels
Pro
bab
lili
ty
Detached Houses, 12 overlaps
Terrace Houses, 16 overlaps
Town Houses, 24 overlaps
Single Apartments, 28 overlaps
Double Apartments, 53 overlaps
Probability of Zero Overlaps with 40MHz Channels
0
0.2
0.4
0.6
0.8
1
11 9 3
Number of Channels
Pro
ba
bili
ty
Detached Houses, 12 overlaps
Terrace Houses, 16 overlaps
Town Houses, 24 overlaps
Single apartment, 28 overlaps
Double apartment, 53 overlaps
Double Apartment • 100% occupancy• 53 overlapping apartments17 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)*Zero chance of length < 2 many cases of size > 3Hence need to drop back to 20MHz and increase number of available channelsBUTMany APs will use 40MHz channels 2.4GHz Band
hopeless!
Apr 2009
Graham Smith, DSP Group
Slide 35
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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
Apr 2009
Graham Smith, DSP Group
Slide 36
doc.: IEEE 802.11-09/0757-01-00aa
Submission
40/20MHz ChannelsIf 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, thena) It may chose to share a 40MHz channel, orb) Switch to 20MHz operation and search again
2. If an 11n QAP, using 40MHz, finds itself overlapping such that Overlaps of 2 are present in the QLoad Element, then• It should switch to 20MHz operation and search again
Notes: 1. The primary intention is to avoid OBSSlengths > 2 which will
cause excessive OBSS sizes2. It is in the QAP’s own interest to use an independent 20MHz
channel rather than share a 40MHz channel when there is an Overlap of 2 or more present.
Apr 2009
Graham Smith, DSP Group
Slide 37
doc.: IEEE 802.11-09/0757-01-00aa
Submission
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
Recommended