How Much Air-Time Do Beacons Actually Burn?

-
It’s a well known rule of thumb when designing WiFi networks that you need to try to keep the number of SSIDs broadcast by your wireless network  down to a ‘reasonable’ number. In this article, I take a look at how much of an issue SSIDs (and their beacons) are in consuming valuable wireless air-time.

Generally, it’s recommended to keep the number of SSIDs below around 5 (ish).

The reason for keeping the number of SSIDs to a minimum is that each SSID is advertised using a type of management frame called a ‘beacon’.  Beacons are generally sent 10 times per second for each SSID on the wireless network. Therefore, if you have 10 SSIDs, they will each be advertised 10 times per second, giving us 100 beacons per second.

Air-time is a finite resource – there is only so much data that can be transferred across the air over a period of one second. If a large chunk of air-time is being consumed by SSID beacons, then that doesn’t leave a whole lot of time remaining for actual user data to travel over the air (which is the whole point of having a wireless network!).

I have previously heard statements from various wireless engineers along the lines of up to 50% of available air-time being consumed by beacons once you have 6 or 7 SSIDs being broadcast by a network. I’ve taken this information on face-value and never really thought too much about it.

However, this evening I found myself in a hotel room with some time on my hands, a Cisco WLC, a Cisco AP and a copy of Metageek Eye PA. I thought it was time to test the ‘conventional wisdom’.

My approach was simple: I would set up my AP on channel 11 (2.4GHz) and capture all frames using Eye PA. I would vary the number of SSIDs being broadcast and monitor the results.

I would also vary the lowest mandatory speed supported by the 2.4GHz network between 1Mbps, 11Mbps and 54Mbps. Beacons are sent at the lowest mandatory speed that is configured for a wireless network. Therefore, if 1Mbps is the lowest mandatory speed, beacons are sent at 1Mbps (and hence are a lot slower and consume more air-time)

To determine how much actual air-time is being consumed by beacons, I would use Eye PA’s filtering capabilities to remove all frames except beacon frames, and remove any other local interfering SSID traffic (i.e. the pesky hotel WiFi on the same channel!). This would leave me with just the beacon frames from my AP:

Eye PA Filtering Beacon Frame


Eye PA allows you to select a period of one second of the filtered traffic that you have captured, and also shows the amount of air-time those frames consumed in that period:



I just then applied some simple maths to work out how much time the beacons frames consumed over a period of one second.
I then tabulated the results:

Number SSIDs Broadcast
Lowest Mandatory Speed
Beacons AirTime Over 1 Sec (mS)
Percentage AirTime Used by Beacons
1
1Mbps
25
3%
7
1Mbps
167
17%
15
1Mbps
326
33%
1
11Mbps
10.5
1%
7
11Mbps
73.5
7%
15
11Mbps
158
16%
1
54Mbps
1.52
0%
7
54Mbps
10.6
1%
15
54Mbps
20.8
2%

The results show pretty much what I expected, but I was surprised by how little time the beacons consumed, particularly once the lowest mandatory speed is ramped up to 54Mbps. They certainly don’t support the information that had been imparted to me regarding 7 SSIDs consuming 50% of all air-time.

You can clearly see the effect of adding more SSIDs (and consequently more beacons). As more SSIDs are added, more air-time is devoted to beacon traffic. This is a bad thing, if it becomes a significant chunk of your air-time.

You can also clearly see the effect of increasing the lowest mandatory speed supported by the wireless network. Once you increase it to 54Mbps, even with 15 SSIDs, you are only consuming 2% of the available air-space.

I suspect that the conventional wisdom of keeping your SSID numbers down to below 5 is founded on the assumption that many wireless networks are going to be installed using default settings. Often, default settings will configure the lowest mandatory speed to one of the lower 802.11b speeds, which could then make significant numbers of SSIDs an issue.

For me there are several lessons to take away:

  • Verify what the defaults of a system are – what is the lowest mandatory speed configured on your system out of the box?
  • Increasing the lowest mandatory speed on a wireless network is going to increase the efficiency (and hence throughput) of your wireless network significantly – less time will be given over to beacon traffic
  • The ‘less than 5 SSIDs’ rule may be a good starting point, but on a well engineered network, it may not be as relevant as it used to do, especially in the presence of modern wireless clients which do not need to support the lower, legacy speeds of 802.11b/g.

A word of caution though before making any wholesale changes to your network. Make sure you do not have any older wireless clients that need to be able to connect to the network at the slower/legacy speeds. Clients need to be able to initially associate to a wireless network at the lowest mandatory speed supported by a wireless network. If you have older devices that are not in areas that have good coverage, they may not be able to associate at a higher speed and will not be able to join the wireless network in those areas. It is probably worth testing the effect of any changes you make carefully.


I’d welcome any feedback on my testing. If there are any flaws in my logic or testing or there are other considerations I may have missed, then please feel free to drop me a note or comment.

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p...
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client...
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would ...
Read more