July 2008 doc IEEE 802 11 080765 r

  • Slides: 10
Download presentation
July 2008 doc. : IEEE 802. 11 -08/0765 r 1 OBSS Requirements Date: 2008

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 OBSS Requirements Date: 2008 -07 -07 Authors: Submission 1 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Abstract This presentation proposes

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

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Terms • Shall –

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 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 Submission 3 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Requirements (1/5) • Improves

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Requirements (1/5) • Improves Qo. S – 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 Submission 4 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Requirements (2/5) • Inter-AP

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 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 Submission 5 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Requirements (3/5) • Dynamic

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 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 Submission 6 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Requirements (4/5) • Fair

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 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. Submission 7 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Requirements (5/5) • Security

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 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. 4 GHz and 5 GHz – Shall support 20 and 40 MHz channel widths – Shall support 5 and 10 MHz channels when all BSS using same channel width – Might support other frequencies (3. 65 GHz) ? Submission 8 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 Non-functional Requirements • Avoid

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 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 Submission 9 Alex Ashley, NDS Ltd

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 References Submission 10 Alex

July 2008 doc. : IEEE 802. 11 -08/0765 r 1 References Submission 10 Alex Ashley, NDS Ltd