Embedded Wi-Fi Roaming: BSSID Selection, Hysteresis and Connection Continuity

Define continuity before tuning signal thresholds

A moving embedded device can stay attached to a fading AP or bounce between two otherwise usable APs. Both are selection-policy problems, but they do not have the same remedy. Begin by defining the application’s tolerable interruption, stale-data limit and recovery behavior. Then investigate the actual roaming controller: firmware, driver, supplicant or application. This guide addresses AP selection within one intended Wi-Fi network. It does not cover switching from Wi-Fi to cellular. The concrete references are the AOSP android16-release supplicant configuration, a checked NetworkManager reference and Cisco’s Catalyst 9800 roaming explanation (document 221671, updated 20 May 2026; IOS XE 17.9.4 reference setup). All thresholds discussed below are design variables to validate, not measured recommendations for an unspecified radio.

Separate the network identity from the selected AP

An SSID is the network-name identity, while a BSSID identifies a particular basic service set. A roaming profile should generally allow eligible BSSIDs within its intended network policy. Check for accidental pinning introduced during initial provisioning. NetworkManager’s BSSID property explicitly warns that locking the profile to one BSSID prevents roaming and disables background scanning in that implementation; its support is driver dependent. The AOSP configuration likewise restricts association when bssid is set. Remove an unintended restriction only through the product’s authorized configuration process. Do not treat a matching SSID alone as proof of matching security, administrative ownership or IP continuity across two APs.

Use fresh candidates and a stable decision rule

A practical candidate record includes BSSID, security compatibility, channel, signal observation time and any available link-quality evidence. Discard stale observations before comparing them. A proposed policy might require current-link degradation, a candidate advantage greater than a chosen margin, and persistence across a defined observation interval. This hysteresis reduces decisions driven by small fluctuations, while a minimum residence time can discourage immediate return to the previous AP. Add an escape for a genuinely failed link so residence time does not trap the device offline. Express the margin, freshness limit and timers in configuration with units. RSSI is one input rather than a universal measure of delivered application service; interference and congestion can produce different outcomes at similar RSSI.

Coordinate scanning with the owner of roaming

Background scanning consumes radio time and can affect live traffic. The referenced supplicant configuration documents a simple bgscan module with short and long scan intervals selected around a signal threshold. It is a discovery mechanism, not a complete promise about when a roam will occur. Confirm whether that module was built and whether firmware roaming supersedes it. Do not run an application timer that disconnects the station while a lower layer is already evaluating candidates. A good instrumentation contract exposes scan start, candidate update, roam request, association result and the chosen BSSID. If the stack offers no controlled roaming API, document that constraint rather than presenting a disconnect-and-reconnect loop as seamless roaming.

Verify k, v and r as separate capabilities

In Cisco’s roaming guide, 802.11k neighbor reports help identify candidates, 802.11v BSS Transition Management assists selection, and 802.11r supports fast transition procedures. These functions are not interchangeable. An AP setting called “fast roaming” does not prove that the embedded client negotiated or used all three. Record client build options, AP configuration and observed exchanges for the specific security mode. Keep feature advertisement, negotiation and successful operation as separate evidence. A transition recommendation should not be interpreted as a guarantee of a stronger link, and a fast authentication path does not solve a broken IP topology. Start with a compatible baseline and enable one capability at a time in the validation matrix.

Measure the gap seen by the application

Align timestamps for the last useful application response on AP A, the scan or transition decision, association with AP B, address state and the first useful response afterward. A same-SSID transition does not by itself guarantee the same subnet, retained DHCP state or survival of a transport connection. Check the deployment topology instead of forcing a fresh address request after every BSSID change. Use a monotonic application sequence number to distinguish a temporary gap from duplicate processing. A transport that remains open can still deliver stale queued commands after the roam; the application should enforce its own freshness or expiry policy. Do not label an ICMP response alone as proof that the real business session continued.

Test movement without hiding the stationary control

In an authorized test environment, use a repeatable route or controlled attenuation and log the actual AP association timeline. Include a stationary device in an overlap area, because ping-pong behavior may be most obvious without movement. Test a gradual fade, abrupt loss, a stale candidate, mismatched security, and the return to the original AP. Repeat with the relevant k/v/r combinations and with an application workload representative of deployment. Document trial count, environment and unsuccessful runs before computing any percentile. This article proposes those experiments; it reports no roaming benchmark. When results fail, distinguish delayed discovery, conservative selection, authentication delay, IP changes and application recovery instead of tuning every threshold simultaneously.

Accept the policy and its failure boundary

Release criteria should cover maximum tolerated application gap, unnecessary transition rate while stationary, recovery after the current AP disappears, and behavior when no eligible candidate exists. Set those limits from the product’s requirements, not from a generic RSSI value copied online. Require evidence that a temporary candidate outage cannot create an endless A-to-B-to-A loop. Store enough versioned, non-secret event data to compare regressions after firmware updates. If the radio owns an opaque selection policy, the supported AP layout and observed limits become part of the product boundary. Reliable roaming is established by a consistent decision path and application continuity evidence, not by displaying a new BSSID.