No matter what kind of Wi-Fi access point you have, it sends beacons. Beacons consume airtime and erode the capacity of your network. Configuring your beacons properly has a significant impact on how your network performs.
Beacons are relatively short, regular transmissions from access points (APs) with a purpose to inform user devices (clients) about available Wi-Fi services and near-by access points. Clients use beacons to decide to which AP to connect. A number of alternatives and “dials” are generally available in all access points to control beacons.
Beacon Per SSID
APs nowadays generally offer dual band operation, 2.4 GHz band and 5 GHz band. This is offered with two radios, one for each band. So each radio operates on one channel and continuously sends beacons on it, typically every 102.4ms.
Access points are often configured to provide multiple networks, with each identified by its SSID. This may help to route wired traffic differently, apply different priorities or security settings. It’s important to remember that each SSID sends its own beacon, at the same defined interval. If you have five SSIDs, five beacons are sent out every 102.4ms. Beacon settings at the AP or management software often allow varying the beacon interval. This setting applies to all SSIDs.
Beacons are sent out with the lowest mandatory data rate. Enterprise grade APs often allow defining the mandatory, optional and non-supported rates. When an 802.11b network is enabled, beacons must use a 1, 2, 5.5 or 11 Mbit/s rate. When –b is disabled, beacons use OFDM rates, starting from 6 Mbit/s.
The size of the beacon packet keeps gradually increasing as more information and services are being added to Wi-Fi. Beacon sizes vary from 60 bytes to even 450 bytes. The larger the beacon packet, the more airtime and capacity beacons consume. Beacon airtime utilization may easily get out of control with non-optimal settings.
Like Wi-Fi data packets, beacons follow the Wi-Fi channel access control protocol, called CSMA-CA (Carrier Sense Multiple Access/Collision Avoidance). At the time the beacon is scheduled to be sent, the AP first listens to the air to determine if the channel is available. If it’s not available, the AP will back off and try again after a short randomized time. If the channel keeps busy, beacons will usually be held back until the next scheduled time.
Beacons can be detected in a much larger area than useful coverage for each AP. When the radio chip can decode the PLCP radio packet header without errors, air is considered to be busy the whole duration of packet, including its payload. PLCP header precedes the user data fields. The PLCP header is always coded either with 1 Mbit/s rate (802.11b enabled) or 6 Mbit/s rate (all other current standards) and this makes it detectable at large distances. As a rule of thumb, packet header detection distance may be 3-5 times the radius of usable Wi-Fi service. High beacon load may impact networks at large distance.
Beacon rates and their corresponding range also impact roaming. Higher rate beacons cannot be decoded without errors at large distance. This may help to avoid clients sticking too long to distant APs or trying to join them too easily. Roaming algorithms vary between devices. Many have experienced a case where a smartphone jumps to Wi-Fi even when it’s not usable, instead of preferring LTE/cellular connection. Disabling low data rates can help.
Increasing beacons interval from 102.4ms to 307.2ms (can be indicated also as 100ms -> 300ms) can be a powerful way to reduce beacon load and air utilization. This should be combined with changing DTIM from 3 to 1 for maintaining similar power save operation. While some experts are wary of using this change, 7signal has had good success in numerous cases. When the terminals used in the network are relatively new and no VoIP only terminals (like certain Vocera badges) are used, this may provide a good performance gain for all users. It is advised to consider the client device base before making this change.
Another beacon setting commonly offered is “hiding” or “not broadcasting” the SSID name. This makes the SSID invisible to clients. Important catch here is that beacons are still sent, but they do not have an SSID name in it. Hiding SSID forces client devices to send probe requests to gain information on available APs. Each AP receiving a probe request with the SSID name will respond to the device with a probe response message. Probe response looks a lot like beacon, but they are sent individually to each client sending a probe request. Hidden network also means that initially end user needs to enter the SSID name to the device to enable it to connect to the hidden SSID.
Hiding SSIDs is often done in the name of added security. For example, a hospital might think that by hiding the SSID name, the risk of network breaches is lower since visitors cannot see the network name in their device. While this is true for the beacons, probe requests do include the network name. When the network is hidden, there is a lot of continuous probing. For a hacker, extracting SSIDs from those probe requests is a cinch; there are numerous freeware tools for this. It is widely accepted among network experts that hiding SSID does not add any security protection.
The 5 GHz band includes DFS channels generally in the range of channels 52-64 and 100-144. Some geographic variation does apply. On DFS channels, APs have special requirements to make space for radar when such is detected. Additionally, clients are not allowed to send probe requests on DFS channels. DFS therefore has beaconing implications. If an AP using DFS channels has a hidden SSID and client devices are not allowed to probe, there is no way for clients to detect alternative APs. This makes it impossible in practice to find APs. In other words, never hide SSIDs when DFS channels are used.
Hiding SSIDs is a mistake in general. Hidden SSIDs send useless beacons. With hidden SSIDs, all clients need to send probe requests regularly to detect APs. All APs receiving the probe will respond. This probe request-response traffic is multiplied by the number of clients configured to use a hidden network. This increases air utilization rapidly, since the sent hidden SSID beacons are completely useless for clients.
Hidden SSIDs provide no security protection from real hackers and have a good chance of degrading your network performance and provoking connection issues.
Airtime and Noise
Using low data rates for beacons consumes more air time than using faster rates. The faster the rate, the shorter is the transmission time for beacon and more air time is left to send actual data. Using 1-2 Mbit/s beacon rates will almost surely congest the air in any network with a number of APs.
In a heavily congested network, beacons may not be even sent at determined intervals. It goes without saying that under such conditions, the noise level in the network has also significantly increased.
Air is a shared resource. In dense areas with overlapping APs, the number of detected beacons increases rapidly. The number of APs on the same channel quickly multiplies the number of beacons loading the air.
Best practices for beaconing
- Limit the number of SSIDs preferably to three or less, maximum to five
- Disable the lowest rates, use 12-24 Mbit/s for beaconing
- Never hide SSIDs when DFS channels are used
- Do not hide SSIDs, instead consider using non-descriptive SSID names
- Increase beacon interval to 300ms, but do your client study first
- Turn off 802.11b support completely
- Locate possible unnecessary –b only devices (printers etc.) and turn the radio off
While you optimize your network’s beacon settings, you should be measuring and monitoring the impact of your changes against performance SLAs using 7signal’s Sapphire Wi-Fi Performance Management system. You will be amazed by what you can see.