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

July 2008 doc.: IEEE 802.11-08/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

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

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

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

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 802.11 levels of) privacy Shall not require detailed information about stream reservations to be exchanged between APs Alex Ashley, NDS Ltd

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

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

Non-functional Requirements July 2008 doc.: IEEE 802.11-08/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

July 2008 References Alex Ashley, NDS Ltd