Honey, I Shrunk the Beacon Interval!

A beacon is an 802.11 management frame that describes a Wi-Fi network and its capabilities. Access points transmit beacons to announce the network to nearby clients and support functions such as basic service set (BSS) time synchronization and power-save management. Clients use the information in these frames when joining a network and evaluating roaming candidates. Beacons also help sleeping clients determine whether the access point has buffered broadcast, multicast, or unicast traffic waiting for delivery.

An access point schedules each beacon transmission for a Target Beacon Transmission Time (TBTT). The interval between target transmission times, known as the beacon interval, is measured in time units (TUs). The IEEE 802.11 standard defines one TU as 1,024 microseconds, and the beacon interval typically defaults to 100 TUs. That corresponds to 102,400 µs, or 102.4 ms, between target transmission times. If the medium is busy at the TBTT, however, the access point must contend for access before transmitting. Consequently, actual transmissions may not occur exactly 100 TUs apart. In practical terms, the default interval produces approximately 10 beacons per second.

Beacon transmissions consume valuable airtime, and their impact can be significant in legacy 802.11b networks or when an access point serves multiple SSIDs. Andrew Von Nagy’s SSID Overhead Calculator is a useful resource for estimating the overhead created by multiple SSIDs. A beacon’s airtime depends on its size—including the number and size of its information elements—and the basic rate used to transmit it. Because management frames usually use a low basic rate, they can consume a disproportionate amount of airtime. The examples below show beacon-airtime estimates from WiFi Explorer Pro.

Most vendors allow administrators to change the beacon interval, although the supported range varies. Some products accept values from 20 to 1,000 ms, while others offer a narrower range, such as 50 to 500 ms. The more important question is not which values are available, but whether changing the default provides a meaningful benefit without harming performance, stability, or client compatibility.

My friend Sam Clements has spotted some unusual beacon intervals in the wild. Whenever he shares one of these findings, I wonder why the network uses a nondefault value. What problem was the administrator—or perhaps the manufacturer—trying to solve?

I did some research and, as with many Wi-Fi settings, found plenty of questionable advice. One article, for example, recommends setting the interval to its lowest possible value so clients can discover the access point faster. It also suggests using the highest available value on a home network. Many other sites repeat similar recommendations without adequately addressing the tradeoffs or the effect on client behavior.

For a more informed perspective, I returned to Lee Badman’s Wi-Fi Question of the Day on Twitter (#WIFIQ). In one installment, he asked Wi-Fi professionals whether they had changed the beacon interval in a production deployment and, if so, why.

#WIFIQ 10/9/2015 Have you ever changed the WLAN beacon interval on your Wi-Fi deployments? To what? And why? Was it successful?

— Lee Badman (@wirednot) October 9, 2015

Most responses amounted to “No—just don’t do it.” Some participants considered higher values acceptable at home but said they would not recommend them for enterprise deployments. Others reported success after doubling the interval in congested environments to reduce overhead.

@wirednot No, never have in an actual deployment, yes for lab testing. Far better to keep the number of SSIDs down to a minimum instead IMO.

— Nick Lowe (@Nick_Lowe) October 9, 2015

@wirednot Nope. Seems like a good idea, but there is too much uncertainty as to how real-world clients will react. Especially BYOD junk.

— Jim Vajda (@JimVajda) October 9, 2015

The main argument against increasing the interval is client compatibility. Some devices may expect beacons at or near the default rate and behave unpredictably when the interval is longer. Power-saving clients may also behave differently when waking to receive buffered traffic. More fundamentally, changing the beacon interval may address the symptom rather than the source of excessive overhead. Before changing it, administrators should reduce unnecessary SSIDs and review the basic rates configured on the network.

In Controlling Beacons Boosts Wi-Fi Performance!, Veli-Pekka Ketonen of 7Signal suggests that increasing the interval from 102.4 ms to 307.2 ms can reduce network load and airtime utilization. However, he also recommends conducting a client study before making the change. A theoretical reduction in overhead has little value if some clients become slower, less reliable, or unable to connect.

The general consensus, then, is to leave the beacon interval at its default unless you have a specific, well-understood reason to change it. If testing indicates that another value may help, evaluate the change with the actual client population before deploying it broadly. Until then, whenever I encounter an interval other than 102.4 ms, I will continue to ask: Why is this person, organization, or manufacturer not using the default beacon interval?