When SSID count still matters
Airtime is the argument people have, but it is not the only cost of an SSID, and this page deliberately measures only the part that can be computed. The rest is real and belongs in the decision:
Group keys do not respect VLANs. Each BSS has one GTK, so if you collapse several VLANs onto one SSID with dynamic assignment, every client holding that key can decrypt the broadcast and multicast traffic of every other VLAN on it — and can forge frames as the AP. Separate SSIDs are the only genuine over-the-air separation for group-addressed traffic. This argues for more SSIDs, not fewer.
Clients have to scan them all. More BSSIDs means longer scan cycles, larger 802.11k neighbour reports, and more candidates to evaluate at every roam. Airtime says an SSID is nearly free on 6 GHz; a handheld roaming across a warehouse at walking pace may still disagree.
MBSSID is only as good as the implementations. Drivers that ignore non-transmitted profiles, vendors that reorder the transmitted BSS across reboots, clients that cache the wrong BSSID — all of it is still out there. Verify on the platforms you actually deploy rather than trusting the arithmetic on this page.
One long beacon is not the same as several short ones. An MBSSID beacon is a single non-preemptible transmission. The percentage is tiny, but for voice, AR/VR or industrial control the jitter from one 1–2 ms blocking event can matter more than the airtime does. That figure is on the page for exactly this reason.
Everything downstream still costs. Every SSID is another set of RADIUS policies, VLANs, firewall rules and troubleshooting paths, and most controllers cap how many you can run per radio anyway. None of that shows up as airtime and all of it shows up in operations.
The honest version of the argument is not "SSIDs are free now." It is that the airtime objection no longer settles it by itself, so the decision has to be made on these grounds instead.
Method, assumptions and limits
What this number is, exactly
Every percentage is medium occupancy summed across the co-channel APs you specify, not the load of one radio, and the line under each headline number always gives you the per-AP figure so the two never get mixed up. Most disagreements about SSID overhead turn out to be exactly this: four SSIDs at a 24 Mbps beacon rate cost about 0.6% on the AP itself, and four times that on the channel if you genuinely have three co-channel neighbours. Both numbers are right; they answer different questions.
CCI therefore starts at 1 everywhere — this AP only. A design with three or four audible co-channel APs on a 5 GHz channel has a channel-plan problem, and charging that airtime to SSID count would be dishonest. Raise it to match what your survey actually shows; on 2.4 GHz, with three non-overlapping channels, you will not get it down to 1.
Occupancy means time the medium is carrying a transmission — preamble plus PPDU. Contention is excluded by default, because DIFS and backoff slots are idle time every station counts down through together; they belong to no single frame, and a radio's CCA-busy counter, which is what your survey tool turns into "channel utilisation", does not count them. Switch on Include contention in More options to add it anyway. It matters more than you would expect at high rates: it adds 15% to the beacon figure at 6 Mbps, 39% at 24 Mbps, and more than half at 54 Mbps.
HR/DSSS and OFDM do not share timing, and this page no longer pretends they do. Each column derives its constants from its own rate: OFDM uses a 20 µs preamble, SIFS 16, a 9 µs slot and CWmin 15, giving 101.5 µs of contention per frame; HR/DSSS uses a 192 µs long preamble, SIFS 10, a 20 µs slot and CWmin 31, giving 360 µs. Applying the OFDM set to a 1 Mbps 2.4 GHz column understates its contention cost by more than three times. Every one of those constants is editable under Shared PHY / MAC constants, and each column states which PHY it is using beneath its headline number.
Probe traffic is off by default but one click away, because it is the other management cost that scales with SSID count and on dense 5 GHz it can exceed beacon airtime outright. Both directions are counted: the request itself once per burst, and the responses it draws. It stays off by default because it rests on client behaviour you have to estimate, and a headline number built on estimates is the easiest thing in the world to argue with — so beacons, which are not negotiable, carry the headline instead.
Rather than ask for a probe rate nobody actually knows, Client scanning offers three measured-ish behaviours: Light (15 clients, 4 bursts/min — stationary laptops and phones on known SSIDs), Typical (25 at 6), and Heavy (45 at 15 — handhelds and scanners roaming constantly, the warehouse and retail case). The underlying client count and burst rate stay editable in More options if you have capture data; changing them switches the selector to Custom.
The wildcard share is the lever that decides whether probes scale with SSID count at all. A wildcard probe request — no SSID named — draws a response from every BSS on the radio, so eight SSIDs means eight responses. A directed probe for a known SSID draws exactly one, no matter how many you advertise. The default assumes 100% wildcard, which is the worst case; dial it down in More options and watch the per-BSS multiplier collapse. At eight SSIDs, going from all-wildcard to all-directed takes probe airtime from 1.27% to 0.19%. If someone tells you probe responses are what makes SSIDs expensive, this is the number to ask them about.
Amendments, MLO, and why 6 GHz has no MBSSID switch
The Amendment selector changes what the AP puts in the beacon, not how clients behave. That distinction matters: a beacon is broadcast at the basic rate to everyone in earshot, so the mix of Wi-Fi 6E and Wi-Fi 7 clients on your network does not change beacon airtime at all. What does change it is the AP's own generation — 802.11be adds EHT Capabilities and EHT Operation, the Multi-Link elements, and a mandatory MME, since beacon protection is required in Wi-Fi 7. Enable MLO and each affiliated link beyond the first adds its per-link profile and RNR entry on top.
The 6 GHz column has no MBSSID toggle because 802.11ax requires the Multiple BSSID element for an AP advertising multiple BSSIDs in that band. It is not a design choice you get to make, so the tool will not let you model a 6 GHz radio that does not use it.
The byte figures behind the amendment selector are estimates, not measurements. Element lengths vary by vendor and by which optional IEs are enabled, and there is no published table worth quoting. Open Frame sizes & interval and replace them with lengths from your own capture — that is the single highest-value change you can make to this page's accuracy.
Region and channel width
Nothing on this page is region-specific. The model never counts channels — you tell it how many co-channel APs you hear, and it costs you their beacons. Whether your regulatory domain gives you 59 6 GHz channels or a handful changes how hard it is to get that number down to 1; it does not change what the number costs once you are there. The only region-dependent figures anywhere are the channel counts quoted in this prose, which are US, and they are illustration rather than input.
Channel width does not change beacon airtime either, which surprises people. A beacon goes out at the basic rate, and on a wider BSS it is sent as a non-HT duplicate — the same 20 MHz-worth of symbols repeated across the width. Same duration, same airtime, just blocking more spectrum while it happens. Where width does matter is indirectly: 80 MHz channels mean roughly a quarter as many channels as 20 MHz ones, so CCI climbs, and CCI is the input that moves this number more than anything else.
How it computes
Frame duration uses real OFDM symbol quantization — 20 µs preamble + ceil((22 + 8·bytes) / (rate·4)) · 4 µs — so a frame occupies whole 4 µs symbols rather than a fractional average. The DSSS/CCK rates (1, 2, 5.5 and 11 Mbps) are computed instead as a 192 µs long preamble plus PSDU time, since they are not OFDM. Under MBSSID the whole BSS set rides in one frame, sized common + (N−1)·profile, which is why the marginal SSID there costs bytes rather than an entire extra transmission. With probe responses switched on, each is unicast and carries frame + SIFS + ACK, and every probe request draws one response per BSS — the multiplier that dominated dense 2.4 and 5 GHz, and the one 6 GHz removes outright by steering clients in with RNR instead of letting them blind-scan.
Airtime is a property of the channel, not the AP, so every column multiplies by its CCI count. That single input moves the answer more than anything else here, which is exactly why it starts at 1 on 5 and 6 GHz rather than at a number picked to make a point. Where 6 GHz genuinely wins before MBSSID is even switched on is that holding CCI at 1 is easy across 59 20 MHz channels and hard across roughly 25 usable on 5 GHz (US figures) — but that belongs in your channel plan, not in an argument about SSID count.
The Settings row holds every band to the same knobs, so the only difference between the columns is MBSSID. That is a controlled comparison, not a picture of a real site: no real 2.4 GHz network runs at 6 Mbps with no co-channel interference. The scenario presets are the opposite — each one sets every band to what that band actually looks like in the field, which is why clicking one switches on per-band mode. Put 2.4 GHz on a 1 Mbps basic rate with two co-channel neighbours and eight SSIDs eat over half the channel; the same eight SSIDs at 11 Mbps with a clean channel cost under 4%. The band is not what makes 2.4 GHz expensive — the basic rate and the reuse are.
The presets move CCI, client density and the basic rate together. Click Legacy 2.4 GHz to put the basic rate back to 1 Mbps and see why the rule existed at all: eight SSIDs at that rate eat most of the channel before a single client sends anything. Preset figures are estimates and vendor behaviour varies — beacon size in particular, along with the rate your AP actually uses on 6 GHz. Treat the output as a shape, then confirm it with a capture from the site you are arguing about.
by Jonathan Finney
· Wi-Fi Architect
· creator of NOCTernal