Wireless Access

I have been thinking about how often we choose a Wi-Fi band based on speed, without really considering where the device is being used.

For example, 5 GHz can be a good choice when a client is relatively close to the access point and needs higher throughput. But once distance and walls become a bigger factor, 2.4 GHz can sometimes be more practical.

I don't think there is one band that makes sense for every client.

A phone being used in the same room as the AP is very different from a device sitting several rooms away. IoT devices are another example. Many of them don't need high throughput at all, so coverage and compatibility can matter more than speed.

I would normally look at a few things before deciding how to handle the bands:

• Distance between the client and AP

• Number and type of walls or obstacles

• Required throughput

• Channel congestion

• Client device capabilities

• Whether the device actually benefits from 5 GHz

It also makes me wonder whether automatically steering every client toward 5 GHz is always the right approach. Some devices may work perfectly well on 2.4 GHz, while others clearly benefit from the extra capacity available on 5 GHz.

For those managing wireless networks, how do you normally decide which band a device should use?

Do you prefer letting the client make the decision, or do you actively control band usage through the wireless configuration?

I would control it, but when I design the network, not client by client. Size the cells for 5 GHz (and 6 where you have it), then turn off the 2.4 GHz radios you don't need so both bands cover about the same area. The Campus VSG RF design chapter recommends exactly that, and says to check in VisualRF that you haven't opened a gap: https://arubanetworking.hpe.com/techdocs/VSG/docs/010-campus-design/esp-campus-design-047-rf-design/

Once the cells match, 2.4's extra reach stops being a feature. A client hanging on to a distant AP at low rates costs everyone airtime. IoT that only speaks 2.4 gets its own SSID, and I raise the minimum rates to 12 or 24 Mbps.

For dual band clients I let ClientMatch decide. In AOS 10 it only moves a 2.4 client that's weaker than -45 dBm, and only when a 5 or 6 GHz radio hears it better than -65 dBm. Clients that ignore it get left alone for a day or two: https://arubanetworking.hpe.com/techdocs/aos/aos10/services/clientmatch/

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

Agreed, coverage, obstacles, and client support all matter. But I'd just shift the focus somewhat. Moving to 5 GHz and/or 6 GHz isn't mainly about speed. It's about using the spectrum better.

Wi-Fi is shared and contention-based. 2.4 GHz has few channels, lots of neighboring networks, and plenty of non-Wi-Fi. A device can have a strong signal and still perform poorly spending time waiting for airtime or resending packets (retries).

With good coverage and channel planning, 5 and 6 GHz give you more room to spread clients out and reuse channels. That means less contention and steadier latency and jitter. Even low-bandwidth apps benefit.

Build a modern enterprise WLAN around 5 GHz, plus 6 GHz where supported. That's what folks have been doing for a while. I'd keep 2.4 GHz only for devices that can't do 5 GHz. Disable 2.4 GHz on your SSIDs. Moving capable clients off 2.4 also frees up airtime for the IoT and legacy gear stuck there. Low bandwidth doesn't automatically mean 2.4 GHz.

Coverage still needs validating, including the client's ability to talk back to the AP (uplink direction). But 5 GHz isn't a same room only band. If normal phones and laptops keep landing on 2.4 because 5 GHz coverage is weak, that's an AP placement and RF design problem. 6 GHz also needs its own coverage check, compatible clients, the right security setup (WPA3 or Enhanced Open), and is not available in all regulatory domains.

I'm not a fan of steering. Don't enable 2.4 GHz on SSIDs where you don't want clients on 2.4 GHz. And infrastructure nudges only go so far. Measure success by reliability and airtime efficiency. Not a speed test... 🙂

I'd still leave ClientMatch on is sticky clients between APs. It asks with 802.11v first and only falls back to a deauth after five ignored requests, so it's a suggestion before it's a kick.

On your 6 GHz caveat, the same guide is blunt: an existing WPA2-Personal or WPA2-Enterprise SSID can't be enabled for 6 GHz, so the security change comes first. Keep 5 and 6 on one SSID too. The 5 GHz beacons carry the neighbor report that tells clients where the 6 GHz radio is.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

Original Message:
Sent: Sep 30, 2026 02:28 PM
From: JS-d3d5bc
Subject: When Do You Prefer 2.4 GHz or 5 GHz?

Agreed, coverage, obstacles, and client support all matter. But I'd just shift the focus somewhat. Moving to 5 GHz and/or 6 GHz isn't mainly about speed. It's about using the spectrum better.

Wi-Fi is shared and contention-based. 2.4 GHz has few channels, lots of neighboring networks, and plenty of non-Wi-Fi. A device can have a strong signal and still perform poorly spending time waiting for airtime or resending packets (retries).

With good coverage and channel planning, 5 and 6 GHz give you more room to spread clients out and reuse channels. That means less contention and steadier latency and jitter. Even low-bandwidth apps benefit.

Build a modern enterprise WLAN around 5 GHz, plus 6 GHz where supported. That's what folks have been doing for a while. I'd keep 2.4 GHz only for devices that can't do 5 GHz. Disable 2.4 GHz on your SSIDs. Moving capable clients off 2.4 also frees up airtime for the IoT and legacy gear stuck there. Low bandwidth doesn't automatically mean 2.4 GHz.

Coverage still needs validating, including the client's ability to talk back to the AP (uplink direction). But 5 GHz isn't a same room only band. If normal phones and laptops keep landing on 2.4 because 5 GHz coverage is weak, that's an AP placement and RF design problem. 6 GHz also needs its own coverage check, compatible clients, the right security setup (WPA3 or Enhanced Open), and is not available in all regulatory domains.

I'm not a fan of steering. Don't enable 2.4 GHz on SSIDs where you don't want clients on 2.4 GHz. And infrastructure nudges only go so far. Measure success by reliability and airtime efficiency. Not a speed test... 🙂

Dustin, if you're interpreting my comment as a recommendation to disable ClientMatch altogether, that inference isn't accurate. My comment about steering was in the context of band selection: if an SSID shouldn't serve clients on 2.4 GHz, configure its allowed bands accordingly rather than relying on steering to achieve that.

That's a separate discussion from ClientMatch helping sticky clients move between APs. A client can certainly remain sticky on a 5 GHz-only WLAN, and I wasn't suggesting that 802.11v-assisted roaming has no value, as you implied.

I'd also distinguish the 802.11v request from deauth fallback. Five attempts is the documented ClientMatch default, but the fallback depends on the applicable rules and client type, including device-specific exceptions. This isn't universally "five ignored requests, then a kick."

My point is to separate allowed bands per SSID from roaming assistance...

Original Message:
Sent: Sep 30, 2026 02:43 PM
From: DB86
Subject: When Do You Prefer 2.4 GHz or 5 GHz?

I'd still leave ClientMatch on is sticky clients between APs. It asks with 802.11v first and only falls back to a deauth after five ignored requests, so it's a suggestion before it's a kick.

On your 6 GHz caveat, the same guide is blunt: an existing WPA2-Personal or WPA2-Enterprise SSID can't be enabled for 6 GHz, so the security change comes first. Keep 5 and 6 on one SSID too. The 5 GHz beacons carry the neighbor report that tells clients where the 6 GHz radio is.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------


Original Message:
Sent: Sep 30, 2026 02:28 PM
From: JS-d3d5bc
Subject: When Do You Prefer 2.4 GHz or 5 GHz?

Agreed, coverage, obstacles, and client support all matter. But I'd just shift the focus somewhat. Moving to 5 GHz and/or 6 GHz isn't mainly about speed. It's about using the spectrum better.

Wi-Fi is shared and contention-based. 2.4 GHz has few channels, lots of neighboring networks, and plenty of non-Wi-Fi. A device can have a strong signal and still perform poorly spending time waiting for airtime or resending packets (retries).

With good coverage and channel planning, 5 and 6 GHz give you more room to spread clients out and reuse channels. That means less contention and steadier latency and jitter. Even low-bandwidth apps benefit.

Build a modern enterprise WLAN around 5 GHz, plus 6 GHz where supported. That's what folks have been doing for a while. I'd keep 2.4 GHz only for devices that can't do 5 GHz. Disable 2.4 GHz on your SSIDs. Moving capable clients off 2.4 also frees up airtime for the IoT and legacy gear stuck there. Low bandwidth doesn't automatically mean 2.4 GHz.

Coverage still needs validating, including the client's ability to talk back to the AP (uplink direction). But 5 GHz isn't a same room only band. If normal phones and laptops keep landing on 2.4 because 5 GHz coverage is weak, that's an AP placement and RF design problem. 6 GHz also needs its own coverage check, compatible clients, the right security setup (WPA3 or Enhanced Open), and is not available in all regulatory domains.

I'm not a fan of steering. Don't enable 2.4 GHz on SSIDs where you don't want clients on 2.4 GHz. And infrastructure nudges only go so far. Measure success by reliability and airtime efficiency. Not a speed test... 🙂