1. Multiple BSSID Set considerations
March 2009
doc.: IEEE /xxxxr0
March 2009
Multiple BSSID Set considerations
Date:
Authors:
Mark Hamilton, Polycom
Mark Hamilton, Polycom

2. March 2009
doc.: IEEE /xxxxr0
March 2009
Abstract
CID58 claims that when k 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

3. March 2009
Background
802.11k, 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 ) format only carries the ‘n’ for
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 k.
Mark Hamilton, Polycom

4. 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

5. 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

6. 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

7. 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

8. March 2009
doc.: IEEE /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 v (and others?) to fix it there:
Mark Hamilton, Polycom
Mark Hamilton, Polycom