Almost every "the Wi-Fi drops in the far aisle" complaint we are called out to is not a coverage problem. It is a roaming problem, and the distinction matters because the two have opposite remedies. Coverage problems are solved by putting signal where there is none. Roaming problems are solved by designing the boundaries between cells, setting thresholds correctly, and understanding that the network does not actually get to decide when a device moves.
Roaming is a client decision
This is the fact that reframes everything else. In standard Wi-Fi, the access point does not hand a device over to its neighbour. The device decides, on its own, when to look for somewhere better and when to move. The infrastructure can inform that decision, encourage it, and in some cases refuse the association a device is trying to make — but the roam itself is initiated by the client.
What that means in practice is that roaming behaviour is a property of the device fleet as much as of the network. Two devices standing in exactly the same spot, seeing exactly the same signal, will roam at different moments because their drivers implement different logic. A design that works for one fleet can fail for another in the same building.
It also means that vendor features which "control roaming" are, with few exceptions, features that make the client's own decision easier or cheaper. That is genuinely useful. It is not the same as control.
Sticky clients, and what they cost you
A sticky client is a device that stays associated to an access point long after a better one is available. It is not misbehaving; it is following a simple rule — do not go looking for a new access point until the current one drops below some internal threshold — and that rule is tuned for a laptop in an office, not a scanner in a warehouse.
The thresholds vary by chipset and driver, and vendors do not always publish them, so anyone quoting a single universal figure is guessing. The behaviour, though, is consistent and its costs are worth spelling out:
- The device drops to low data rates. As signal degrades, the radio falls back to slower, more robust modulation. A transaction that took 2 ms of airtime at the cell centre might take twenty times that at the edge.
- Everyone else pays for it. Airtime is shared. One sticky client transmitting slowly occupies the medium that every other device on that channel is waiting for. This is why a handful of edge devices can visibly slow a whole area.
- Retries pile up. Poor signal means failed frames means retransmission, which consumes more airtime again.
- When it finally roams, it roams badly. A device that leaves it too late is scanning and re-authenticating from a position of weakness, which is exactly when a roam is most likely to fail outright.
You cannot fix stickiness by adding coverage. Adding a strong signal in the far aisle without changing anything else gives the device one more distant access point to cling to. What fixes it is designing where cells end.
Scanners and voice need a different design target
A laptop is an extraordinarily tolerant Wi-Fi client. It has a decent antenna, reasonable transmit power, mains or large-battery power, a full operating system, and — crucially — applications that buffer. A web page that takes an extra second to load does not generate a support ticket.
Handheld scanners and voice handsets have none of those advantages. Small antennas in a plastic case held next to a body that absorbs RF, low transmit power for battery life, and applications with no tolerance for a gap: a voice call drops audibly, a scan fails visibly, and a warehouse management session that times out means an operator standing still.
So these devices are designed to a higher primary signal threshold and, more importantly, to a deliberate overlap: at every point along the routes they travel, a second access point should already be audible above the level at which the device will consider roaming. Common industry design targets for voice sit around −65 to −67 dBm primary with a healthy signal-to-noise margin, but the right figure for a given site depends on the actual device fleet and should be established rather than assumed — some rugged scanners are markedly less sensitive than that guidance implies, and a few are better.
Minimum data rates and legacy rates
Every Wi-Fi cell has a set of enabled data rates, and a subset of those marked as basic or mandatory. Beacons, broadcasts and other management traffic are transmitted at the lowest basic rate, and a device can remain associated for as long as it can decode that rate.
Leaving the oldest rates enabled has two effects, both bad in a modern network:
- The cell has no edge. A device can hold an association out to the point where it can just about decode a 1 Mbps or 6 Mbps frame — far beyond where it can do anything useful. Raising the lowest basic rate pulls the usable cell boundary inward to something defined, and gives the client a clear reason to roam.
- Management traffic gets expensive. A frame sent at a low rate occupies the medium for far longer than the same frame at a high rate. Beacons go out roughly ten times a second per SSID per radio; multiply that by several SSIDs and a low basic rate and a meaningful slice of your airtime is spent announcing the network rather than using it.
Disabling legacy rates is therefore one of the highest-value changes available, and it costs nothing. It is also the change most likely to break something, which is why it needs care rather than enthusiasm. Older barcode terminals, some IoT sensors, building-services controllers and a surprising amount of long-lived industrial equipment are 802.11b or 802.11g only. Raise the floor above what they can decode and they simply disappear from the network. Establish what is actually on the SSID before touching this, and stage the change.
Band steering, and when it hurts
Band steering nudges dual-band capable clients away from 2.4 GHz and onto 5 GHz, usually by withholding or delaying probe responses on 2.4 GHz until the client has been seen on 5. The logic is sound: 2.4 GHz has three non-overlapping 20 MHz channels, is shared with a great deal of non-Wi-Fi equipment, and is where every legacy device lives.
Two cautions apply.
First, steering assumes 5 GHz is the better band for that device in that place. In a deep warehouse aisle with loaded racking, it may genuinely not be — 2.4 GHz will often reach where 5 GHz will not, and a scanner steered onto a marginal 5 GHz signal is worse off than one left on a solid 2.4 GHz one.
Second, aggressive steering interacts badly with client roaming logic. A device that has decided to roam and finds its preferred band unresponsive may take longer to associate anywhere, which is the opposite of the intent. Where steering is used with a critical device fleet, it should be tested against that fleet rather than switched on as a default.
802.11k, v and r: what each actually does
These three amendments are routinely bundled together as "fast roaming", which obscures the fact that they solve three different problems. None of them takes the roaming decision away from the client.
| Amendment | What it does | What that buys you, and what it doesn't |
|---|---|---|
| 802.11k Radio resource management | The access point supplies the client with a neighbour report — a list of nearby access points and the channels they are on. | Makes scanning cheaper. Instead of sweeping every channel looking for candidates, the client can check a short list. That reduces the time the device spends off-channel and not passing traffic. It does not make the client roam, and a client that ignores neighbour reports gets nothing from it. |
| 802.11v BSS transition management | The infrastructure can send the client a request to move to a named access point, optionally with a candidate list and a disassociation timer. | The closest thing to steering a roam that the standard offers, and it is the mechanism behind most vendor "client steering" features. It remains a request: a client may decline or ignore it. The disassociation timer is the blunt instrument behind it — effective, but it forces a full reassociation. |
| 802.11r Fast BSS transition | Caches key material across access points so a roaming client does not have to repeat the full authentication exchange. | The one that reduces roam duration, and the difference is largest on WPA2/WPA3-Enterprise, where a full 802.1X exchange against a RADIUS server is the slow part. Little benefit if the roam was already fast. Some older clients associate poorly or not at all when fast transition is enabled, so it is often introduced on a separate SSID and tested against the real fleet. |
Vendor-specific alternatives exist — opportunistic key caching being the common one — and behave broadly like 802.11r's key-caching benefit without the standardised negotiation. Support varies by platform and by client.
Why AGVs and voice are the least tolerant load on any site
If a site runs automated guided vehicles, autonomous mobile robots or wireless voice, those devices set the design standard for the whole building. Everything else will be comfortable if they are.
The reasons are structural rather than incidental:
- No buffering. A file transfer can pause for 300 ms and nobody notices. A voice codec cannot, and a vehicle taking movement instructions certainly cannot.
- The failure is expensive and manual. A scanner that drops gets retried by an operator. An AGV that loses its connection at the wrong moment stops, and someone has to go and recover it — which may mean stopping the aisle, or the line.
- They move continuously and predictably. That is actually helpful: the routes are known, so the roaming design can be built along them. It also means roam events happen at the same places every time, so a single weak boundary produces a repeating, high-visibility fault rather than an occasional one.
- They travel where people don't. Under conveyors, along guided aisles, through charging bays, into corners of the building nobody walks. A survey that follows the operator route will miss the vehicle route entirely.
- Their radios are often modest and their environment is hostile. Antennas mounted low on a metal chassis, close to motors and drives, moving through a reflective steel environment.
- Roaming behaviour may not be adjustable. Many vehicle radios are supplied as part of an integrated system with roaming parameters set by the vendor. If the client cannot be tuned, the RF design absorbs the entire burden.
The practical implication is that these routes need surveying as routes, at the height and orientation the device's antenna actually occupies, with the roaming boundaries checked in motion rather than inferred from a static coverage plot. Where a fleet is already deployed and misbehaving, that is a diagnostic exercise rather than a design one — measuring what is actually happening before anybody buys hardware. Where the fleet is being introduced, it belongs in the survey brief from the start.
Let's find out what your Wi-Fi is actually doing.
Book a survey and you get measured data, a design you can build to, and a number you can budget against — not an opinion.