Shortening or hiding the roam: the options compared

A single-radio roam is never free. Every technique on this page removes a different part of the gap, and only a second link that is already up can hide the move from the application.

That makes the comparison simple to state. Ask which part of the gap a technique removes, what the client and the network must both support, and what it leaves in place. Then measure.

What the gap is made of

A roam has stages, and each technique attacks a different one.

Scan. The client looks for candidates on other channels. In one industrial lab study, scanning lasted up towards 1 s¹ and was the largest single delay.
Decision. The client picks a target and a moment. One vendor’s roaming primer is blunt: it is always the client that decides to roam, and when and where. iPhones and iPads start looking at -70 dBm².
Authentication. On an 802.1X network without fast roaming, a full EAP exchange with the RADIUS server.
Key handshake. The 4-way handshake that derives fresh keys for the new access point.
Reassociation. The frames that join the new AP. The same study measured 55 ms of handover with no data after the scan.
Data path update. The wired network learns where the client went. When a client is authorized, a Linux access point broadcasts a Layer 2 Update frame³ so switches update their forwarding tables.

Where the gap starts and stops is defined in how to measure a roam gap.

The baseline: full 802.1X on every roam

Without fast roaming, an 802.1X roam repeats the whole EAP exchange and then the 4-way handshake. A university testbed measured 90 full EAP-TLS reauthentications averaging about 1.1 s⁴, on 802.11b hardware from around 2003. Apple says the full exchange might take several seconds, depending on the authentication infrastructure. One vendor’s primer puts it at 120 ms to a couple of seconds⁵. Those figures measure different things, so this site draws no range for it. See full 802.1X reauthentication.

A PSK network has no EAP to skip. The lab study put an unoptimized PSK roam at 520 ms including the scan, and its 55 ms handover alone sets the low end of this site’s 55 to 520 ms range for a PSK roam without FT.

Key caching: PMKID caching and OKC

Both skip the EAP exchange by reusing a pairwise master key (PMK) the client already holds. Neither skips the scan or the 4-way handshake.

PMKID caching helps only when the client returns to an AP where it already authenticated. On a route, the next access point may be one the client has never joined.

Opportunistic key caching (OKC) shares one cached PMK across many access points, so a first visit is fast too. One vendor notes that OKC is not defined by the 802.11 standard⁶ and is not supported by many devices. hostapd, the Linux access point daemon, shares its cache only among the BSSes in a single hostapd process. Windows uses OKC when 802.11r is not available⁷.

Measurements are thin. The same university testbed cut reauthentication to 25 ms on average by pushing keys to neighboring APs ahead of the client, with a simplified handshake. The vendor primer lists OKC at 8 to 100 ms. No independent measurement on current clients was found, so no range is drawn.

802.11r fast BSS transition

Fast transition (FT) uses a key hierarchy built so the client can move between APs without reauthenticating at each one. The initial handshake with the new AP happens before the client roams, so both sides calculate the session keys in advance. It removes the EAP exchange and the separate 4-way handshake. It does not touch the scan or the decision.

It comes in two forms. Over the air, the client talks directly to the target AP using 802.11 authentication with the FT algorithm⁸. Over the DS, it sends FT action frames through its current AP, which passes them across the wired side. That routes the exchange through the link the client is about to leave. Clients normally prefer over the DS when the network advertises it, and hostapd enables it by default.

Both ends must agree. FT works only within a mobility domain, and only for a key type both support: Windows does FT over 802.1X, not PSK. Fast roaming mismatch covers what happens when they disagree.

This site’s FT range is 15 to 90 ms⁹ of ping loss, from FT over PSK on two Android phones in a 2026 bachelor thesis. The lab study found that FT removed a handshake of about 6 ms from a handover of about 55 ms, so the mean barely moved. Under background traffic, its 99.9th-percentile round trip fell from 297 ms to 215 ms. In that setup FT did not trigger on a timeout-based roam, only on a signal threshold. No measurement of FT over 802.1X was found, and that is where the study’s authors expect the larger gain.

802.11k and 802.11v: help with the scan and the decision

These two shorten the hunt, not the handshake.

802.11k neighbor reports tell the client which APs to look for. Windows uses them to shorten the list of channels it scans. Apple devices use the first six entries to prioritize channels, and without 11k a roam scan can add several seconds. The lab study got the same effect by hand, cutting the scan list from 38 channels to 3. With FT on top, its 99.9th percentile fell to 143 ms. See off-channel scanning gaps.

802.11v BSS transition management lets the network direct the client to another AP. The client still chooses; Apple devices review the transition data to decide. One vendor’s steering feature goes further: a client that has not moved when its timer expires is disconnected forcefully. For a vehicle carrying I/O, that disconnect is the outage you were trying to avoid.

Vendor-specific fast roaming

Some vendors pair their own access points with their own clients or bridges and run a roaming method of their own. Treat every figure here as the vendor’s claim, under the vendor’s conditions.

Proprietary key management. One vendor’s scheme works only with that vendor’s infrastructure and compatible clients. In a jointly published industrial design guide, a workgroup bridge using it converged within 63 to 97 ms at 5 to 100 mph¹⁰, with no I/O timeout at a 20 ms standard RPI and a 40 ms safety RPI. The test used two APs on an RF attenuator in a controlled lab.
Client-driven roaming. One industrial bridge maker claims roaming recovery under 150 ms¹¹ in client mode, with any vendor’s APs. That is an average under optimized conditions: interference-free 20 MHz channels, WPA2-PSK, a three-channel scan list and 100 kbps of load.
Make-before-break handoff. One vendor’s industrial mode claims handoffs with zero packet loss and latency under 10 ms¹². It connects to the next AP before losing the current one, runs its own label-switching protocol over the radio, and needs that vendor’s radio on the vehicle.

Two of the three tie both ends to one maker. The third puts the whole method in the client. This site’s range for these schemes, 63 to 150 ms, is built from vendor figures and is labeled that way.

Wi-Fi 7 multi-link operation

The Wi-Fi Alliance says multi-link operation (MLO) lets devices transmit and receive over multiple links for increased throughput, reduced latency and improved reliability. Its launch release also claims deterministic latency for critical traffic. Read that as marketing, not a measured bound.

MLO does not move you between access points. In 802.11be, the APs of one multi-link device are co-located on the same hardware. Switching links inside that device can be make-before-break. Leaving its coverage for another AP is still a roam. No source found for this page measures an MLO roam. The Wi-Fi 6E and Wi-Fi 7 page has the detail.

Wi-Fi 8 roaming between AP MLDs: a draft

802.11bn, the amendment behind Wi-Fi 8, defines a Seamless Mobility Domain that groups several AP MLDs in one ESS into one logical coverage area. Once the client decides to roam, the current and target AP MLDs transfer its context ahead of time. The old AP MLD keeps sending buffered downlink data for a draining period while the new one can start, and no re-authentication is needed inside the domain. The project targets 25% less MPDU loss, especially during transitions between BSSs¹³.

It is a draft. The task group produced Draft 2.1 after its September 2026 meeting and projects final approval in May 2028. It needs 802.11bn at both ends, and the client still makes the decision. Buy today’s vehicles for break-before-make roaming.

Make-before-break with a second radio

To hide the gap rather than shorten it, the next link has to be up before the first one drops. One vendor claims that inside its own closed scheme. A second radio can do it without changing the access points.

A 2005 research prototype did it in the client. A second interface scanned and pre-associated with the next AP while the first carried traffic, then traffic moved over. Both interfaces used the same IP and MAC addresses, so the network saw an ordinary reassociation, and the authors report 0 ms of handoff latency¹⁴. The cost showed up too. Two radios in one small device interfered even on channels 1 and 11: 154 slow pings against 10 with one radio. Packets still queued on the old interface could be lost.

On a vehicle the same idea usually means two bridges, or a dual-radio client, on separate paths. Duplicate frames, loops and a second set of radios come with it. Redundant radio paths covers the designs.

The options side by side

Technique	Removes	Both ends must support	Leaves in place	Range on this site
Full 802.1X (baseline)	Nothing	802.1X	Every stage	None drawn: figures disagree
PMKID caching	EAP, on a return to a known AP	Client and AP	Scan, handshake, every first visit	None: no current measurement
OKC	EAP, on any AP sharing the cache	Client and the APs or controller	Scan, handshake	None: no current measurement
802.11r	EAP and the separate handshake	Client and every AP on the route, same key type	Scan, decision, data path	15 to 90 ms (FT over PSK, phones)
802.11k	Part of the scan	APs send neighbor reports, client uses them	Authentication, keys	None
802.11v	Part of the decision	APs send transition requests, client acts on them	Everything after the decision	None
Vendor-specific	Varies by scheme	Usually one maker at both ends	Whatever the vendor does not publish	63 to 150 ms (vendor figures)
Wi-Fi 7 MLO	Link switches inside one AP MLD	Wi-Fi 7 client and AP	The roam to another AP	None
802.11bn (draft)	Re-authentication and the break, inside one domain	Wi-Fi 8 client and APs	Scan and decision	None: not shipping
Second radio	Hides the gap from the application	Two radios on the vehicle	Cost, duplicates, loops	None for current hardware

Vendors quote single digits

The strongest objection is that vendors already publish tiny numbers. The roaming primer lists 802.11r and its own key management at 4 to 50 ms, and an industrial vendor claims zero packet loss. If those hold on your floor, the roam is solved.

They may hold in the conditions behind them. The primer itself says the low end of each range was measured in a lab in a perfect RF environment. The design guide’s 63 to 97 ms came from two APs on an attenuator. In an industrial lab with enterprise access points, the study saw scans of up to a second before its 55 ms handover. A Windows laptop in the thesis lost 150 to 450 ms per roam, with no FT in its frames.

None of those numbers is yours. Check what each client supports in the client roaming matrix, then measure the gap on your client model, on your route, with your security settings, as how to measure a roam gap describes.

What to ask a vendor

Which methods the client or bridge supports, per key type: PMKID caching, OKC, 802.11r over the air and over the DS, 802.11k, 802.11v.
Whether its fast roaming needs the same maker at both ends.
Its published roam time, and how it was measured: RF environment, number of APs, scan list, security, load.
What triggers its roam, and whether you can set that threshold.
Whether it can carry a second radio, and how it handles duplicates and loops if it does.
Which 802.11bn features its hardware will support, and whether that needs new hardware.

A technique shortens only the part of the roam it was built for. Your measurement tells you whether that was the part your timeout could not afford.