Roaming is what happens when a WiFi device moves from one access point to another. The device, not the network, decides when to move, so good roaming depends on two things: coverage designed so there is always a better access point to move to, and network settings that make the move fast. Get both right and calls, scanners and video keep working as people walk through the building.
Why roaming goes wrong
Most roaming complaints come down to a handful of causes:
- Sticky clients. A device stays connected to the access point it joined, even after walking well past a closer one. Signal drops, the device slows to a crawl, and users blame the WiFi.
- Coverage gaps. If cells do not overlap, the device loses its old connection before it finds a new one. In a stairwell or corridor this shows up as a dropped call every time someone walks through.
- Too much overlap. When a device can hear many access points at similar strength, it may bounce between them, and co-channel interference rises.
- Slow re-authentication. On an 802.1X network, a full login at each new access point can take long enough to interrupt voice or video.
- Inconsistent settings. Different SSID settings, security modes or VLANs on different access points can force devices to reconnect from scratch.
How a device decides to roam
Each device has its own roaming logic, set by its chipset and driver. Typically it watches the signal strength of its current access point. When signal falls below an internal threshold, it scans for others on the same SSID and moves to one that looks better. Thresholds vary widely: a phone may roam aggressively, while an older laptop or industrial scanner may hang on far longer than it should.
This is why design matters. You cannot change how every device behaves, but you can make sure that by the time any device decides to look, a strong alternative is available. Designing to a signal target such as the one in why −67 dBm is the WiFi design target, with overlap between neighbouring cells, gives devices that option.
Design for roaming
Cell overlap
Neighbouring cells should overlap enough that a moving device always hears a second access point at a usable signal level before the first one becomes poor. The right amount depends on the devices, the building and the applications. Voice and real-time video need more careful overlap than a network used mostly for laptops at desks.
Transmit power
Access points running at full power make cells large, but client devices usually transmit at lower power than access points. A device can hear an access point it cannot reliably talk back to. Matching access point power more closely to typical client power reduces stickiness and keeps cells a sensible size.
Data rates
Disabling the lowest legacy data rates encourages devices to move on rather than cling to a distant access point at a crawl. It also frees airtime. Change this carefully: very old devices may depend on those rates.
Channel plan
Overlapping cells must be on different channels, or they interfere with each other. Roaming design and WiFi channel planning are done together.
Roaming between buildings and subnets
If a device moves to an access point on a different subnet, it may need a new IP address, which breaks active sessions. Controllers and cloud-managed systems handle this in different ways, for example by tunnelling traffic back to a central point or extending the same VLAN across the roaming area. Plan this early on campuses, hospitals and warehouses where people move between buildings or zones.
802.11k, v and r
Three amendments to the WiFi standard help devices roam faster and smarter. They only help when both the network and the device support them.
| Amendment | What it does |
|---|---|
| 802.11k | The access point gives the device a list of neighbouring access points, so it scans fewer channels and finds a target faster. |
| 802.11v | The network can suggest that a device move to a better access point. The device can still refuse. |
| 802.11r (Fast BSS Transition) | Keys are prepared in advance so a device on a secured network can move without repeating the full authentication. This is the big one for voice on 802.1X networks. |
Some networks also use key caching methods, such as opportunistic key caching, that achieve a similar result for devices without 802.11r support. On 802.1X networks, the security design and roaming design are tied together; see WPA3 and 802.1X authentication.
Test with your real devices. Some older clients fail to connect when 802.11r is enabled on an SSID. Before turning it on everywhere, test each device type you depend on, or use the mixed or adaptive modes some vendors offer.
Testing roaming
Roaming problems often do not show up in a static heat map. Verification should include:
- Walk tests along real routes with the devices people actually use, such as handsets, scanners and tablets
- Continuous voice or video calls during the walk, watching for gaps or drops
- Controller or management logs showing roam times and failed roams
- Checks in stairwells, elevator lobbies, corridors and building transitions
- Repeat tests after any change to power, channels or security settings
How ehZee can help
Our WiFi surveys start by asking what devices and applications you run, because a network built for voice handsets and roaming scanners is designed differently from one built for laptops at desks. Through our WiFi design and build service we plan overlap, power, channels and fast roaming settings, then walk the site to confirm devices move cleanly.
Common questions
Can the network force a device to roam?
Not fully. 802.11v lets the network suggest a move, and some systems will disconnect a device to push it along, but the device makes the final decision. Good coverage design is still the main tool.
Why do calls drop only in certain spots?
Usually a coverage gap, a stairwell or elevator lobby with poor signal, or a slow re-authentication at a specific access point. A walk test with a live call along that route will usually show which.
Should we turn on 802.11r?
If you run voice or video over an 802.1X network, it is usually worth it. Test your device types first, since some older clients do not handle it well.