1. OBSS Requirements Date: 2008-07-07 Authors: July 2008 July 2008
doc.: IEEE /0765r1
July 2008
OBSS Requirements
Date:
Authors:
Alex Ashley, NDS Ltd
Alex Ashley, NDS Ltd

2. July 2008
doc.: IEEE /0765r1
July 2008
Abstract
This presentation proposes some requirements that should be met by the OBSS solution provided by the 11aa amendment.
The following slides describe each requirement. The requirements are not listed in any particular order.
Alex Ashley, NDS Ltd
Alex Ashley, NDS Ltd

3. Terms Shall Should Might ? Something that is required
July 2008
Terms
Shall
Something that is required
Should
Something that is optional, but is recommended
Might
Something that is optional ?
Feedback from the group is requested
Alex Ashley, NDS Ltd

4. Requirements (1/5) Improves QoS Contention based protocols
July 2008
Requirements (1/5)
Improves QoS
When a stream (TSPEC?) has been accepted, traffic from other BSSs should not cause it to stop
Shall support 2 overlapping BSS
Should support 3 overlapping BSS
>3 OBSS unlikely in practice and probably an NP-hard problem
Contention based protocols
EDCA-AC admissions should be preserved
No special OBSS handling required for DCF, U-PSMP ?
Controlled access protocols
Shall support protection of HCCA, S-PSMP reservations
Shall support TBTT / DTIM adjustment to avoid beacon collision and multicast collision
Alex Ashley, NDS Ltd

5. Requirements (2/5) Inter-AP communication Management
July 2008
Requirements (2/5)
Inter-AP communication
Shall be possible via the WM when both APs in range of each other
Might be possible via WM when APs not in range
Should be possible via the wired DS ?
Management
Shall not mandate an AP to be configured as the master/supervisor controller
If solution requires an AP to be automatically chosen as master/supervisor, shall be robust to signal fade and AP removal
Might support master/supervisor controller for enterprise use
Shall not mandate pre-shared configuration
Alex Ashley, NDS Ltd

6. Requirements (3/5) Dynamic
July 2008
Requirements (3/5)
Dynamic
Shall be robust to the order in which APs are switched on
Removal of an AP shall not cause video streams in other BSSs to terminate
Shall (should?) support dynamic stream creation & deletion
Maintains (current levels of) privacy
Shall not require detailed information about stream reservations to be exchanged between APs
Alex Ashley, NDS Ltd

7. Requirements (4/5) Fair ESS / BSS
July 2008
Requirements (4/5)
Fair
The right to access the WM shall be fair
e.g. supervisor AP does not get “first dibs”
Actual division of time might not be fair, due to differing loads in each BSS
ESS / BSS
It shall not matter if the OBSS are in the same ESS or different ESS.
Alex Ashley, NDS Ltd

8. Requirements (5/5) Security Compatible with legacy equipment
July 2008
Requirements (5/5)
Security
Shall not require the reduction in the security policy of a BSS
Shall be robust to attacks from rogue AP / non-AP STA
Does not create a new denial of service technique
Compatible with legacy equipment
Should not require non-AP STA modification
Shall be tolerant of legacy APs and non-AP STAs
Frequencies
Shall support 2.4GHz and 5GHz
Shall support 20 and 40MHz channel widths
Shall support 5 and 10 MHz channels when all BSS using same channel width
Might support other frequencies (3.65 GHz) ?
Alex Ashley, NDS Ltd

9. Non-functional Requirements
July 2008
doc.: IEEE /0765r1
July 2008
Non-functional Requirements
Avoid OBSS
Use channel selection to avoid overlapping BSS whenever possible
Simple to implement
Compared to maximum (theoretical) throughput, OBSS enhancements are going to be way down on the purchase decision list
A complex solution unlikely to be implemented and hard to create a test plan
Provides an incentive
Beyond being a good (wireless) citizen, enabling enhanced OBSS must provide a benefit, or it will not be enabled
Regulation might require E-OBSS, but let’s not presuppose this
Alex Ashley, NDS Ltd
Alex Ashley, NDS Ltd

10. July 2008
References
Alex Ashley, NDS Ltd