Wi-Fi Beacon Frames, Simplified

We talk about the Wi-Fi offerings on one AP, or across multiple APs in the same extended service set (ESS), as if it is all one unified network.  In reality, each AP has its own set of SSIDs, and each SSID is on its own VLAN.  We set up multple SSIDs purposely to make each of these different SSIDs an “independent” network.  (If you want further explanation of VLANs and why to use them, check out my earier blog post on this.)  

Similarly, the SSIDs on the 2.4 GHz band are “independent” from the SSIDs on the 5 GHz band, because different physical radios and antennas are used.  I’m using “independent” in quotations, as there are some coupling terms between the SSIDs on the same AP and between the same SSID offered on both the 2.4 GHz and 5 GHz bands.  Hence, while we can configure all of these SSIDs and networks independently, they do have interactions in the unbound RF medium, and thus we want to maintain certain relationships between them.

Every SSID on each band broadcasts its own unique beacon frame.  This is a periodic advertisement broadcast out to tell any listening devices that this SSID is available and has particular features / capabilities.  Client devices depend upon these beacon frames to discover what networks are available (passive scanning), and to ensure that the networks that they are associated with are actually still present and available.  A client also has the option to perform active scanning, where a client device sends a broadcast request to see what networks are available, and each SSID from each AP in range will send out a unicast probe response that has the same information as a beacon frame.  

Think of a beacon frame as a guy/gal standing out in front of a shop in a silly costume, advertising the shop to any and all passers-by.  In contrast, think of the probe request as a potential customer coming up to the guy/gal in the costume and asking “what do you offer?”  In the scenario where an AP offers multiple SSIDs (either within the same band and/or across bands), extend the analogy to a strip mall with multiple shops, where each shop has someone in a different silly costume making an advertisement to passers-by, but they have a mutual agreement than only one of them will talk at a time, so they do not talk over each other and confuse customers (i.e. “avoid collisions” in Wi-Fi parlance).   The probe request from the client can contain a specific SSID, analogous to a customer walking up to a specific costumed advertiser to ask “what do you offer?”, or a null SSID analogous to a customer asking the entire group of costumed advertisers at once “what do all of you offer?”, with then each costumed advertiser giving his/her unique response.

Each beacon frame (or probe response) contains a lot of information about the specific SSID being offered.  While not a complete list, the really important items are as follows: 

• SSID Name: 1-32 character name of the network
• BSSID:  Unique Layer 2 MAC address of the SSID
• Security capabilities:  e.g. open, WEP, WPA, WPA2, personal (passphrase) vs. enterprise (802.1x with RADIUS server)
• Channel: specific frequency that this SSID on this AP is operating on
• Channel width: e.g. 20, 40, 80, 160 Mbps
• Country: List of all supported channels and corresponding channel settings
• Beacon interval: How often the AP sends out this beacon frame
• TIM / DTIM:  Used for power management to allow devices that sleep to wake up at specific intervals to find out if there is unicast or broadcast data waiting for them

Quite importantly, beacon frames also advertise the connection speeds that the AP can use to connect to a client device.   These are broken up into a few different categories: 

• Basic rates: These are the 802.11a/b/g speeds that every connecting client device MUST support in order to maintain a connection
• Supported rates:  These are the 802.11a/b/g speeds that the AP will support and could use if the client device also supports those speeds
• 802.11n MCS rates:  These are the subset of the 78 total modulation and coding schemes (MCS) that are defined for 802.11n that the AP supports.  In reality, it gets dictated by the number of spatial streams that the AP supports (MCS 0 -7 for single stream, MCS 8-15 for dual stream, MCS 16 – 23 for three streams, and MCS 24 – 31 for four streams).   MCS32 – MCS77 are defined as combinations of asymmetric rates across different streams, which sounds like a neat idea but is utterly impractical in practice. 
• 802.11ac MCS rates / streams:  This is simplified compared to 802.11n, as there are no asymmetric rates, and the particular modulation and coding stream combination use the same index no matter how many streams.  256 QAM is added, providing two additional modes per stream, so these are simply MCS 0-9.  The beacon indicates whether the AP supports MCS 0-9 on one stream, on two streams, on three streams, etc. up to eight streams.  While the beacon is architected such that it could exclude particular modes, e.g. “I don’t support MCS 5 on three streams”, the spec dictates that an AP must support all 802.11ac MCS modes across all of the streams it has available.

Beacons are always sent at the lowest basic rate (and primary channel when using extended channels in 802.11n/ac).  This is done to ensure that every possible client in range of the AP hears the beacon frame.  When an AP has multiple SSIDs (on the same and/or across multiple radios), it sends out a separate beacon for each SSID on each radio.  Each SSID in a particular band must have a unique MAC address, so typically one of the hexadecimal digit (usually the last, but some vendors increment the first) is incremented so that each SSID has a unique MAC address.   

If you opt to “hide” the SSID, then the SSID name is blank, but the rest of the beacon is still sent out normally.  When the client decides to associate with an SSID, it has to specify the SSID name in the (re)association frame it sends to the AP.  This is why hiding an SSID is ineffective as a security measure and thus generally advise network admins not to bother:  anyone capturing association / reassociation request frames with a Wi-Fi packet analyzer will capture the name of the SSID in clear text.

Considerations for in-band (2.4. GHz OR 5 GHz) beacon frames

In the case where there are multiple SSIDs within the same band, all of the parameters could be set independently.  Obviously the SSID name, BSSID, and the security features are going to be unique, and the channel setting, channel width, and country will be identical.  But what about the other parameters?   

• Beacon interval:  Usually consistent across all SSIDs within a band.  To my knowledge, there isn’t anything to be gained if some of your SSIDs beacon more frequently than others.  A typical beacon interval is 100 time units (a time unit is 1.024 ms, so every 102.4 ms).  One would use a longer beacon interval (e.g. 300 time units or 307.2 ms) to reduce overhead in the channel, since beacons are transmitted at the lowest speeds and each SSID requires its own beacon).  Since a client device uses the beacon frames from the BSSID to which it is connected to confirm the AP is still there (i.e. in range and active), making the beacon interval too long might cause some clients to time out and instigate roaming to another AP when they should not be doing so.
  
  
• TIM / DTIM:  Usually consistent across all SSIDs within a band.  To my knowledge, there isn’t anything to be gained if some of your SSIDs require more frequent check-ins from sleeping client devices vs. others.  A typical DTIM will require that a sleeping client (e.g. VoIP phone, smartphone, tablet) be awake for every 3-5 beacon frames to check to see if any frames have been queued for it in the interim.  If you are using a slower beacon interval, then it is common to adjust the interval here in order that a sleeping client checks in regularly.  As an illustrative example, if one normally told the client to be awake every third beacon for 100 TU beacon interval, you'd probably want the client to be awake every beacon for 300 TU beacon interval.
  
  
• Connection Speeds:  Usually consistent across all SSIDs within a band.  To my knowledge, there isn’t anything to be gained by allowing particular connection speeds on some SSIDs and not others.  Changing lowest basic rates will change the speed at which particular beacons are transmitted, but again there is no advantage to having some beacons go out at faster speeds than others.

I suppose there are some rare use cases where one might want particular SSIDs to act differently.  One potential scenario is a guest network, where I want to maximize compatibility with all possible devices that could connect vs. a staff network, where the admin has strict control over the devices and their locations on their network and wants to “optimize” their performance.  To me, this seems to introduce a fair amount of complexity for dubious practical gains, which is a situation I generally try to avoid.

Cross-band (2.4 GHz AND 5 GHz) beacon frames

In the case where we have the same SSID on both the 2.4 GHz and 5 GHz bands, we generally want to take advantage of a feature called band steering to force dual-band clients to use the 5 GHz band.  The 5 GHz band generally has wider channels and fewer sources of external interference, making for a faster user experience.  In this case, the SSID name and all security features (along with VLAN settings, which are set on the AP but are not part of the beacon) should be identical.  The channel and channel width will be different (by definition).   The connection speeds will be somewhat different based on the differences between 802.11b/g/n on the 2.4 GHz band and 802.11a/n/ac on the 5 GHz band.   There is no need to support 802.11b speeds on the 5 GHz band, though the 802.11a and 802.11g speeds are identical, and the 802.11n speeds are also identical (if the streams are identical). As for beacon interval, these are usually identical but there is no requirement to do so.  Based on the usage characteristics per band (i.e. how many clients per band, what connection speeds being used, etc.), it could be advantageous to tweak this setting per band to optimize overhead performance.

Across the 2.4 GHz and 5 GHz bands, since the radios are independent on both the AP and client device, some vendors increment the BSSID to identify the particular SSID and some vendors don’t. (This is sometimes referred to a virtual BSSID.)  In this case, it doesn’t matter if the BSSID is reused since 2.4 GHz and 5 GHz transmissions cannot hear each other, and the Layer 1 (physical) and Layer 2 (MAC, think Wi-Fi chipset) levels are physically separate from each other.

The most common network scenario in practice is the need to support 802.11b devices (either legacy or new low-power IoT) and/or 802.11g devices (legacy).   Both of these are on the 2.4 GHz band.  There were virtually no independent 802.11a client devices, as this standard was primarily used for dedicated point-to-(multi)point wireless links.  Hence, if a network needs to support slower 2.4 GHz devices, one probably wants to leave the network configured with a standard beacon interval of 100 time units and support for all 802.11 b/g rates.  On the 5 GHz network, we almost always want to maximize performance, so on this band it would make sense to make tweaks, such as using longer beacon intervals (e.g. 300 time units) and drop support for some of the slower 802.11a connection speeds, such as 6 Mbps and 9 Mbps.