Band steering and load balancing on deterministic clients
Steering features delay, deny, or disconnect clients to spread load across bands and access points, and a control device that gets steered loses time its application never allowed for.
On this page5 sections
Is this your problem? It presents like this
- Devices take several attempts to join, or sit on a weaker access point than the one nearest them.
- The access point logs association rejections, or forced disconnects after transition requests.
- Drops rise at peak shift or as the fleet grows, when access points cross a client threshold.
- Some client models cope and others fail, usually the ones that ignore transition requests or rejections.
- Devices end up on a weaker 5 GHz link at spots where 2.4 GHz would have been stronger.
- Bands
- 2.4 GHz5 GHz5 GHz DFS
Why it happens
Steering works by saying no. Load balancing answers a join with status code 171 when an access point is busy, and one vendor’s controller can turn a client away up to 10 times before letting it in. Another vendor’s band steering withholds the first probe response in 2.4 GHz2, and for 802.11v clients the access point tries to steer them every five minutes. When the controller vendor’s low-signal disconnect feature sends a transition request and the client stays put, the client is disconnected forcefully.
Steering does not know what the device is doing. The vendor that withholds the probe response says its band steering works irrespective of the strength of the signal between the access point and the client. Clients differ in how they respond. Windows accepts and responds to transition requests when its driver supports 802.11v, while a survey of implementations found that implementation quality varies even among devices that support it.
Steering does real work in a crowded office, spreading laptops and phones across bands and access points. Even there, the controller vendor lets you switch load balancing off per WLAN for time-sensitive voice clients. A device with a fixed job and a short timeout should never be the one the network chooses to move.
How to confirm it
- List every steering feature on the SSID, including band steering, load balancing, client balancing, 802.11v transition management, and low-signal disconnects.
- Capture association attempts and look for rejections, missing 2.4 GHz probe responses, and transition requests followed by a disassociation.
- Line up drops with each access point's client count at the time.
- Turn steering off for one access point group or SSID, and compare the drop rate.
The fix
- Turn off band steering and load balancing on SSIDs that carry control traffic.
- Put control clients on their own SSID and band, so there is nothing to steer.
- If you keep 802.11v, confirm that each client model acts on transition requests before you let the network disconnect clients that do not move.
Prevent it at design time
- Size capacity so every access point can carry its peak fleet without balancing.
- Leave steering features off on OT SSIDs, and enable one only after testing it with every client model.
About this page
Built from 5 sources: 4 vendor documents and 1 other source. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "Band steering and load balancing on deterministic clients." OT Wireless, published October 5, 2026. https://otwireless.com/causes/band-steering-and-load-balancing/
APA 7
Rutter, B. (2026, October 5). Band steering and load balancing on deterministic clients. OT Wireless. https://otwireless.com/causes/band-steering-and-load-balancing/
BibTeX
@misc{rutter2026bandsteeringandloadbalancing,
author = {Rutter, Ben},
title = {{Band steering and load balancing on deterministic clients}},
year = {2026},
howpublished = {\url{https://otwireless.com/causes/band-steering-and-load-balancing/}},
organization = {OT Wireless},
}