Multiple BSSID Set considerations March 2009 doc.: IEEE 802.11-09/xxxxr0 March 2009 Multiple BSSID Set considerations Date: 2009-03-09 Authors: Mark Hamilton, Polycom Mark Hamilton, Polycom

March 2009 doc.: IEEE 802.11-09/xxxxr0 March 2009 Abstract CID58 claims that when 802.11k was introduced, there was insufficient discussion text included in the amendment for the Multiple BSSID Set architectural concepts. This presentation considers some architectural aspects that could be considered for additional discussion in the Standard. Mark Hamilton, Polycom Mark Hamilton, Polycom

March 2009 Background 802.11k, 11.10.11 describes Multiple BSSID Set as (along with other details about how BSSIDs are used): All members of the set use a common regulatory class, channel, and antenna connector The set has a maximum size of 2n for at least one n, where 1 ≤ n ≤ 46. The Multiple BSSID Element (section 7.3.2.46) format only carries the ‘n’ for 11.10.11. There appear to be no other restrictions or guidance on what a Multiple BSSID represents, nor is other information about the BSSIDs transmitted by the AP. 802.11k Multiple BSSID concept only relates to Measurement Pilot. Other amendments (802.11v, so far) are building on this concept, using only the definition in 802.11k. Mark Hamilton, Polycom

March 2009 Background – 2 My opinion: This concept was meant to allow efficiency gains (medium time, especially) when a single AP “device” desires to start more than one BSS to allow, for example, different security modes, access to different wired VLANs, or different QoS parameters. Without multiple BSSID set, this would require Beacons, Pilot Measurements, Probe Responses, BC/MC frames, etc. to be duplicated for each BSSID. 802.11k only addresses Pilot Measurements. 802.11v is expanding this to Beacons. Note: by “device” I mean to include “fat APs,” or “controller based APs” where there may be a distributed nature to the AP, sliced horizontally. But, this is quite different from the vertical slice/sharing described by Multiple BSSID Mark Hamilton, Polycom

Sharing considerations March 2009 Sharing considerations In the case of multiple BSSIDs, there is a spectrum of options for how the (logically) independent MACs/PHYs could share information and state Could literally be two (or more) completely independent PHYs and MACs, sharing just an antenna (and some “out of scope” knowledge of the existence of each other) Could be a single “device” sharing almost everything between the two PHYs and MACs except MAC address. Or, somewhere in between Some examples/discussion follow. Perhaps the details can be debated, but the point is that the Standard is not clear or specific. Mark Hamilton, Polycom

March 2009 Sharing examples - 1 Consider completely separate PHY and MAC, except for antenna These APs have true medium contention between them, with normal multiple-STA collision probabilities and backoffs/retries – seems very inefficient. Since there are multiple channel access functions running at once, the aggregate of these APs has a higher probability of medium access than a single AP would. The APs could be on the same ESS. How would a typical non-AP STA respond to this? Mark Hamilton, Polycom

Sharing examples - 2 Consider sharing almost everything March 2009 Sharing examples - 2 Consider sharing almost everything What defines an “addressable unit”? Associations cannot be shared (true?) Can security associations and other security context be shared? Can they share queues and coordination functions? Can they (must they?) coordinate quiet periods? Mark Hamilton, Polycom

March 2009 doc.: IEEE 802.11-09/xxxxr0 March 2009 Straw Poll Questions Which action do you believe TGmb should consider for Multiple BSSID concepts? 1) Add/change text to clarify the concept, and provide limitations and/or guidance: 2) Do nothing, clarification is not needed and/or the flexibility is appropriate: 3) Existing Standard and amendments do not have a problem, discuss issue with 802.11v (and others?) to fix it there: Mark Hamilton, Polycom Mark Hamilton, Polycom