Doc.: IEEE 802.11-09/0757-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 10 Authors:

Apr 2009

Graham Smith, DSP Group

Slide 1

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Proposed Overlapping BSS Solution

Date: 2009, July 10

Name Affiliations Address Phone email Graham Smith DSP Group 2491 Sunrise Blvd,

#100, Rancho Cordova, CA 95742

916 851 9191 X209

[email protected]

Dan Dillon DSP Group 2491 Sunrise Blvd, #100, Rancho Cordova, CA 95742

916 851 9191 X205

[email protected]

John Janecek DSP Group 2491 Sunrise Blvd, #100, Rancho Cordova, CA 95742

916 851 9191 X208

[email protected]

Authors:

Apr 2009


Slide 2

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Abstract08/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

09/0660r3 examined using 11s MCCA for HCCA OBSS

09/0662r2 introduced OBSS Sharing with Access Fraction

09/0666r2 considered HCCAOP Advertisement for sharing

This presentation presents the proposed solution

Apr 2009


Slide 3

doc.: IEEE 802.11-09/0757-00-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


Slide 4

doc.: IEEE 802.11-09/0757-00-00aa

Submission Slide 4

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 OBSSsize <=3

FOR MORE COMPLETE EXPLANATION, SEE SLIDES 33 - 38

Slide 4

Apr 2009


Slide 5

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Outline of Proposal

1. New IE “QLoad”• Used for Channel Selection and Channel Sharing

2. TSPEC Requirement Request Response• Used by QAP to STA to indicate or confirm their TSPECs

3. Recommendations to avoid/minimize OBSS problem– Channel selection based upon:

• QAP Overlap

• QLoad

• Received Signal Strength

– Channel width selection 40/20MHz

Apr 2009


Slide 6

doc.: IEEE 802.11-09/0757-00-00aa

Submission

ElementID

LengthOverlap

And Prority

QAP (Self)

ID

QAP ID

Qload

1 1 2 2 6 12 VAR

Overlap and Priority

ReservedOverlap (4 bits)

Etc.For all QAPs

In OBSS Graph

QAP ID

Random Value

1

Octet 6 of MAC Address

1

QLOAD ELEMENT

1

QAPPriority

Streams6

b0

Number AC3 streams Number AC2 streams

QAP Priority Streams

QAPPriority

Streams

Qload

b0 b13 b15

STDEV

b4

b14

Distance

1

Access Fraction

Access Fraction

bits

Access Fraction

8 6

bits 4 4

2

Access Factor Integral

Access Factor Fraction

Qload(Self)

STDEV and Distance

MEAN HCCA Peak

2 2 2octets

CHPbit

b7

PROPOSED “QLOAD” ELEMENT

NOTE: CHP bit not used if HCCAOP Advertisementis used.

Apr 2009


Slide 7

doc.: IEEE 802.11-09/0757-00-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 33 – 38 for further information

Apr 2009


Slide 8

doc.: IEEE 802.11-09/0757-00-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


Slide 9

doc.: IEEE 802.11-09/0757-00-00aa

Submission

QAP ID

• First octet = random number (0 to 255)

• Second octet = octet 6 of MAC Address

• Once established, QAP ID is not changed

• Enables a QAP to indentify its QLoad in other QLoad elements

Apr 2009


Slide 10

doc.: IEEE 802.11-09/0757-00-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 indicate or confirm 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


Slide 11

doc.: IEEE 802.11-09/0757-00-00aa

Submission

TSPEC Requirement Request Response

Request from QAP to a particular STA

Two types of Request:

1. Send All TSPECs (ID 0)– Effectively all previous

(if any) TSPECs are deleted, need to set them up again

2. Confirm TSPECs (ID 1)– Confirm which

TSPECs are still required

– TSID plus Direction defines TSPEC

CATEGORYCODE

ACTIONCODE

DIALOGTOKEN

OPTIONAL SUB

ELEMENTS

REQUESTID LENGTH

1 1 1

1 1

VAR

1 1 1

0 = Send All TSPECs

1 = Confirm TSPECS # of TSPECs TSID+Dir TSID+Dir TSID+Dir

Not present

RESPONSEID LENGTH

1 1 1 1 10 = Accepted will send all TSPECs

1 = Confirmed TSPECS # of TSPECs TSID+Dir TSID+Dir TSID+Dir

Not present

TSPEC Requirement Request Response Action Frame

Apr 2009


Slide 12

doc.: IEEE 802.11-09/0757-00-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


Slide 13

doc.: IEEE 802.11-09/0757-00-00aa

Submission

QAP Priority Streams

• Number of EDCA Priority Streams, 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)– 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

Apr 2009


Slide 14

doc.: IEEE 802.11-09/0757-00-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

• Access Factor– Total Traffic Requirement of self plus all other visible QAPs.

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


Slide 15

doc.: IEEE 802.11-09/0757-00-00aa

Submission

ACCESS FACTOR FIELD

• 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


Slide 16

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Sharing

• 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


Slide 17

doc.: IEEE 802.11-09/0757-00-00aa

Submission

HCCA Peak

• The total HCCA TXOP requirement for the QAP, expressed in 32us/sec.

– The sum of all the HCCA Peak values 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

Apr 2009


Slide 18

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Medium Time Allocations - Sharing

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’

1. In response to each TSPEC the AP allocates the Medium Time or TXOP (HCCA) that corresponds to the peak traffic

2. When allocating an additional Medium Time or TXOP, the AP must calculate what the composite stream would be, and check that this composite medium time does not exceed the limit

3. It is this composite time, that is advertised in the Access Fraction– The actual sum of the Medium Times and TXOPs 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. Similarly HCCA TXOPs terminate when no more data.

– Allocated HCCA TXOPs cannot exceed “1”

Apr 2009


Slide 19

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Apr 2009


Slide 20

doc.: IEEE 802.11-09/0757-00-00aa

Submission

CHP bit

• CHP bit is used for overlapping HCCA QAPs

• If CHP = 1, then the QAP is the Supervisor responsible for handing off the TXOP to each QAP

• Rules are required for a QAP to set CHP = 1

Apr 2009


Slide 21

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Rules for Setting CHP bit and SharingWhen a HCCA QAP is searching for a channel, it should do so in the following order:1. Set CHP (Channel Priority) to 02. If finds a clear Channel, set CHP to 13. If no clear channel, then may share with

a) Any legacy AP: Set CHP to 1b) An Admission Control QAP, overlap 0 or 1:

Resulting HCCA QAP overlap being 1:1, or 1:2 Set CHP to 1 (see Note 1)c) An HCCA QAP with CHP = 1 CHP stays at 0 (see Note 1)

4. If conditions as per 3 cannot be found, the QAP may share with an HCCA QAP, with CHP=0 and Overlap = 1, CHP stays as 0 BUT the following must occur:a) The QAP that now has Overlap = 2 shall negotiate with the QAP that has CHP=1 to take over the

Supervisor role. The new QAP must wait until it sees directly the QAP with CHP=15. If an HCCA QAP cannot find a channel that meets the above rules, it must fall back to

Admission Control (see note 3)

NOTES:1. If 3b) or 3c) or 4), check that “QLoad” is such that the two can share2. 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.

Apr 2009


Slide 22

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Harmonizing HCCA

• When sharing use Fixed Time Slot– Each AP (HC) knows how much of the Time Slot it can use:

• HCCA Peaks, Access Factor (and HCCA Access Factor)– 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.• “Supervisor Claim” also used when condition #4 is met. QAP with the

higher Overlap takes over.

Apr 2009


Slide 23

doc.: IEEE 802.11-09/0757-00-00aa

Submission

AP to 2 APs

A QLOAD B QLOAD

Slot Slot

A Actual B Actual A Actual B Actual

QAP A is the “Supervisor” and effectively in charge of the 10ms Slot and handing off to QAPs B and C

QAP A knows the 10 ms slot timing

QAP A sends QoS CF Polls to QAPs B and CQAP A sends QoS CF Polls to QAPs B and CTID= 1111 NAV=0

TXOP Limit = Tb and Tc

Tb

C QLoad

A BC

Tc

Tb

Tc

C Actual C Actual

Apr 2009


Slide 24

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Wireless DS QoS CF-Poll (Null Data) for AP to AP Communication

AP to AP QoS CF-Poll Address Fields

FunctionTo DS

From DS

Address 1

Address 2

Address 3

Address 4

Wireless DS 1 1 RA= QAP B

TA= QAP A

DA=QAP B

SA=QAP A

AP to AP QoS CF-Poll Frame Type and Sub-type

Type valueb3 b2

Type Description

Subtype value b7 b6 b5 b4

Subtype Description

10 Data 1110 QoS CF-Poll (no data)

Applicable Data Frame

Bits 0-3 Bit 4 Bits 5-6 Bit 7 Bits 8-15

QoS CF Poll TID EOSP= 1

ACK Policy Agg (11n) TXOP Limit

QoS Control Field

Use TID field as identifier

Apr 2009


Slide 25

doc.: IEEE 802.11-09/0757-00-00aa

Submission

WDS QoS CF Polls To Supervisor from QAP with CHP=0

From Supervisor QAP with CHP=1

ACTIONBits 0-3 Bit 4 Bits 5-6 Bit 7 Bits 8-15

Indication from Supervisor to another QAP of Time to start TXOP (HCCA sharing)

1111 1 10 0 Time to start of TXOP in units of 32us

Supervisor Claim, CHP = 1 0001 1 00 0 0

ACTION Bits 0-3 Bit 4 Bits 5-6 Bit 7 Bits 8-15

CHP is set to 0 0000 1 00 0 0

Is Supervisor There? 0010 1 00 0 0

* May not be required unless a more strict control of QLoad is needed

Apr 2009


Slide 26

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Apr 2009


Slide 27

doc.: IEEE 802.11-09/0757-00-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


Slide 28

doc.: IEEE 802.11-09/0757-00-00aa

Submission

HCCAOP Advertisement Element• HCCA Advertisement Element informs ONLY TXOPs THAT ARE

ACTIVE (except for HCCA Access Factor)• 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: Total HCCA Peak of all QAPs Distance 0, 1 and 22 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 all QAPs that have a “Distance” of 1 and 2 in the QLoad Element

Apr 2009


Slide 29

doc.: IEEE 802.11-09/0757-00-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 2 (see 09/0662)

• HCCA QAP looks at the HCCAOP Advertisement to select a TXOP that does not interfere with an existing TXOP in place

• 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.– Uses HCCA Peak, HCCA Access Fraction, HCCA Access Factor

Apr 2009


Slide 30

doc.: IEEE 802.11-09/0757-00-00aa

Submission

CHP bit Scheme, versus HCCAOP Advertisement

• CHP bit– Very efficient, Supervisor hands off the TXOPs using Wireless DS frames– No clock drift problem– Requires a Supervisor and selection procedure– Limited to OBSS length 2 and size 3

• Supervisor must be at Distance 1 from other 2 QAPs• In practice, will meet all scenarios if 20/40MHz channel selection is adopted

(08/1470)

• HCCAOP Advertisement– Simple scheme and builds upon other work (11s)

• Especially if OBSS length 2 and size 3

– Is expandable to any OBSS Graph– Requires each QAP to convert slots to local time– Does suffer from Clock Drift– Can be inefficient

Apr 2009


Slide 31

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Apr 2009


Slide 32

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Poll #1

Which HCCA Scheme is preferred:

1. CHP bit Supervisor?

2. HCCAOP Advertisement?

Apr 2009


Slide 33

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Poll #2“It is recommended that the OBSS proposal, as described

in 09/xxxxr0 be adopted in principle and further recommends that normative and informative text should now be written”

Y/N/A

Apr 2009


Slide 34

doc.: IEEE 802.11-09/0757-00-00aa

Submission

BACKGROUND SLIDES• OBSS Requirements• Channel Selection• Proposal Summary

• Poll

Apr 2009


Slide 35

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Apr 2009


Slide 36

doc.: IEEE 802.11-09/0757-00-00aa

Submission Slide 36

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 36

Apr 2009


Slide 37

doc.: IEEE 802.11-09/0757-00-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


Slide 38

doc.: IEEE 802.11-09/0757-00-00aa

Submission


A

B

C

A B

C

OBSS Length = 2OBSS Size = 3

Overlaps A = 2, B = 1, C = 1


Overlaps A = 2, B = 2, C = 2

A

B

C

D


Overlaps A = 2, B = 2, C = 1, D = 1

Overlap <=2 ButLength and Size above “spec”

√

X

√

Apr 2009


Slide 39

doc.: IEEE 802.11-09/0757-00-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


Slide 40

doc.: IEEE 802.11-09/0757-00-00aa

Submission


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


Slide 41

doc.: IEEE 802.11-09/0757-00-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



• Hence, Overlap Field size made 4bits (0 - 15)

Apr 2009


Slide 42

doc.: IEEE 802.11-09/0757-00-00aa

Submission

Apr 2009


Slide 43

doc.: IEEE 802.11-09/0757-00-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”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 Band 20MHz USA 24 CH, Europe 19 CH

40MHz USA 11 CH, Europe 9 CH

Apr 2009


Slide 44

doc.: IEEE 802.11-09/0757-00-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


Slide 45

doc.: IEEE 802.11-09/0757-00-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


Slide 46

doc.: IEEE 802.11-09/0757-00-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, 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 > 22. It is assumed that it is in the QAP’s own interest to use an

independent 20MHz channel rather than share a 40MHz channel

Apr 2009


Slide 47

doc.: IEEE 802.11-09/0757-00-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

Documents

Doc.: IEEE 802.11-09/0757-00-00aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 10 Authors: