Wi-Fi roaming and band steering: the client decides

Your phone decides when to leave one access point for another, and nothing on the network side can overrule that decision except in two narrow cases defined below. Cisco Meraki states it in one line: "Roaming is a client side decision in 802.11 WiFi." Juniper Mist adds the caveat that matters: "Ultimately roaming is the decision of the client, however the infrastructure can help the client to make better roaming decisions". Almost every consumer roaming fix, band steering included, is an access point trying to influence something it does not control, so the useful question about each feature is how much influence it actually carries.

Why a device clings to a distant access point

Apple's deployment documentation assigns ownership without hedging: "Devices connected to a Wi-Fi network are responsible for maintaining their 802.11 connection." Apple also publishes the thresholds, which most vendors do not. An iPhone or iPad holds its current BSSID until the signal falls to about -70 dBm; a Mac holds on until about -75 dBm. Only then does the device run a roam scan, "the process used by a device to check for access points that support the currently associated ESSID."

Finding something stronger is still not enough. On iOS, iPadOS and visionOS "the candidate BSS needs to have an RSSI that's 8 dB stronger if the iPhone, iPad, or Apple Vision Pro is transmitting data, or an RSSI that's 12 dB stronger if the device is idle". On macOS the bar is 12 dB "whether the Mac is idle or transmitting data".

Two consequences follow. The trigger is absolute rather than comparative, so a laptop sitting at a comfortable signal level will not go looking for anything better even while standing directly under a second access point. And the extra dB requirement is deliberate hysteresis: without it a device between two equal access points would flap between them continuously.

Meraki describes the visible result: "client 1 associated to AP 1 will not roam to AP 2 despite AP 2's probe response reflecting a higher RSSI value." Outside Apple's estate you are guessing at the numbers, because clients "may not roam until received signal dips below a specified proprietary threshold on the wireless NIC."

What 802.11k, 802.11v and 802.11r each actually do

The credit is misassigned constantly. 802.11r is the amendment people name when they mean roaming, and it does nothing at all until the client has already chosen a target. Sophos puts its contribution at "a factor of ten, from hundreds of milliseconds down to as little as 40 or 50 milliseconds", every bit of it in the authentication leg. If your device is not roaming, 802.11r has no opinion on the matter.

802.11k attacks the other slow part, the scan. Mist: "802.11k helps clients discover neighboring APs, reducing the need for the client to perform off-channel scanning as it makes the decision on the next Access Point to roam to." Apple devices with 802.11k available "use the first six entries in the Neighbor Report to prioritize the channels to be scanned", which cuts a full sweep of 2.4 GHz, 5 GHz and the 6 GHz scanning channels down to a handful.

Only 802.11v speaks to the decision. Wi-Fi Alliance bundled all three plus 802.11u into Wi-Fi CERTIFIED Agile Multiband, whose technology overview is dated December 2017, and made 802.11r optional inside that program. The stated premise is deliberately two-sided: "both the Wi-Fi network and client devices have information which can aid in making roaming decisions". A separate program, Wi-Fi CERTIFIED Optimized Connectivity, announced 19 February 2018 and built on 802.11ai and 802.11k, works on the adjacent problem of network discovery and initial authentication rather than on transitions between access points.

BSS transition management, and the two flags that are not suggestions

An access point sends an unsolicited BSS Transition Management Request when it wants a client to move. Wi-Fi Alliance lists the reasons, and one of them is the sticky client by name: "The infrastructure believes the client device is sticking unnecessarily to a particular AP and is not autonomously roaming to better APs as the user moves around".

Two fields turn the request into an instruction. With Disassociation Imminent set to 1, or BSS Termination Included set to 1, the client "is required to leave its current AP, unless specific exception cases apply". If the attached neighbour report also sets Abridged to 1, the client "should roam to one of the recommended APs, or leave the network completely". A disassociation imminent request must additionally carry a timeout, and the client "must not attempt to associate back to this AP until the timeout has expired".

With neither flag set, the request is advice: "the client is not obliged to act on the request". Mist is blunter about how that plays out in practice, calling BSS transition management a way to make recommendations "which the client is free to ignore, and they often do". The reason is that the decision does not live in the Wi-Fi driver alone. Wi-Fi Alliance: "a client device's connection manager, typically part of the operating system, considers various factors such as user preferences, availability of authentication credentials, usage cost, and disruption to ongoing sessions when considering a network switch."

Meraki's client balancing shows the shift from blunt to standardised. Before firmware MR 29.X it worked by refusal: "a client may be rejected with a reason code 17 message indicating that the AP is busy in order to guide the client to a different AP". From MR 29.X an "unsolicited 802.11v BSS-TM frame may be sent from the AP to the client". Either way the access point eventually concedes. On a third association attempt it will "a) accept the association request and b) mark this client as persistent".

Band steering is a probe response you never receive

Band steering has no IEEE amendment. It is a vendor heuristic, and the common implementation is silence. Meraki documents its own: "If the AP hears a probe request in 2.4 GHz while band steering is enabled, it only responds if it has not heard anything on the 5 GHz band from that same client in the last 60 seconds."

Two properties of that design surprise people. It ignores signal quality entirely: "Band steering functions utterly irrespective of the strength of the signal between an AP and a client. An AP will try to steer a client towards 5 GHz band even if the signal in 2.4 GHz is much stronger." And it is one way only: "There is no mechanism to steer clients from 5 GHz back to 2.4 GHz."

So a dual band device at the far end of the house can be pushed onto the band with worse propagation and kept there, while a 2.4 GHz only smart plug, never heard on 5 GHz, is unaffected and simply waits longer for its first association. Neither behaviour is a bug in the client. The client was never told anything; it was not answered.

One SSID across bands is usually right

Apple's router guidance is a single line for the network name: "Set to a single, unique name (case-sensitive) for all bands", and "Make sure that all routers on your network use the same name for every band they support." A Wi-Fi 6E network that splits names gets flagged on the device: Apple devices that support Wi-Fi 6E "identify the network as having limited compatibility".

The mechanical reason is that a move inside one SSID is a BSS transition the Wi-Fi driver can evaluate against the thresholds above, using neighbour reports and candidate lists that are scoped to that extended service set. A move between two differently named networks is a network change, handled by the operating system's connection manager against saved profile priorities, with no roaming machinery involved at all. Split the names and you have not disabled band steering, you have replaced a fast decision with a slow one.

Minimum RSSI, and the kick that has nowhere to send you

Minimum RSSI, sold under names like forced disconnect or roaming assistant, is the crudest lever: below a set signal level the access point disconnects the client outright. EnGenius publishes defaults of -80 dBm for forced disconnect, -75 dBm for answering probe requests and -70 dBm for accepting association requests, with the note that the "AP checks the client's RSSI every 30 seconds and actively disconnects clients whose RSSI is lower than a given threshold."

The failure mode is structural. A disconnect names no destination, so a client kicked in a spot where the current access point is genuinely the best one it can hear will reassociate to exactly that access point, and be kicked again on the next poll. OpenWrt's dawn steering daemon encodes the lesson in its defaults guidance: kick method 1, RSSI comparison, is preferred because it "considers other APs when making such decisions and wouldn't kick if no better option exists for the client", while the absolute threshold variants, kick method 2 and kick method 3, "are to be avoided."

What genuinely helps in a home with two or three access points

Fix coverage before touching any of the above. Sophos publishes usable design targets: a minimum of -67 dBm for voice and -72 dBm for data, "a 15 to 20% overlap between coverage areas for optimal performance", and a 10 to 15 dB gap between the current access point and the next. Under 10% overlap produces sticky clients because no candidate ever clears the client's margin; over 30% produces interference and load balancing problems.

Then turn the standardised features on, because they are frequently off. In OpenWrt, ieee80211k, bss_transition and ieee80211r all default to 0. Neighbour reports also need the access points to know about each other, which on a hand built multi access point setup is a separate synchronisation job rather than a checkbox.

Treat 802.11r as the optional extra it is in the certification program. Keenetic names the classic casualties, Samsung GT-N7100 and GT-N8000 phones and laptops with Intel 4965 or 3945 adapters, where the extra authentication suites in the security element mean "the client does not understands and refuses to connect". OpenWrt changed the ft_over_ds default from 1 to 0 in release 23.05.0 for a related reason: the old value "is known to cause issues especially with Apple devices". The wiki's own warning is the right frame for the whole feature set: "Beware that an incorrectly configured or otherwise non-functional implementation of many roaming technologies can result in a poorer roaming experience than having none of these featurse enabled at all."