802.11r and 802.11k on Android: fast roaming deployment on Cisco Meraki, HPE Aruba and Ubiquiti UniFi

Yes, most Android handsets support 802.11r fast transition, 802.11k neighbour reports and 802.11v BSS transition. Support depends on the chipset driver and the manufacturer, not on the Android version alone. On Cisco Meraki, HPE Aruba or Ubiquiti UniFi, enable 802.11r in mixed mode and keep fast transition over the air. Confirm each handset model in a packet capture before rollout.

What does fast roaming actually do on an Android handset?

Fast roaming relies on three IEEE amendments working together:

• 802.11k helps the handset find the next access point.
• 802.11v lets the network suggest when to move.
• 802.11r shortens the handover itself.

Android can use all three. The handset decides when to roam, not the access point.

That point shapes every decision in this guide. On most Android devices, roaming runs in the WiFi chipset firmware and driver, not in the Android framework. The Android Open Source Project documents this as firmware roaming. As a result, two phones on the same Android release can roam quite differently.

802.11k: neighbour reports

An 802.11k-capable handset asks its current access point for a neighbour report. This is a list of nearby access points and the channels they use. The handset then scans only those channels instead of sweeping every band. It spends less time off-channel and makes a better-informed roaming decision. Handsets without 802.11k ignore the report and scan as normal.

802.11v: BSS transition management

802.11v BSS transition management lets the access point suggest that a handset move to a named access point. The handset can accept, reject or ignore the request. Android chipsets treat these requests as advice, and some act on them more readily than others. Pair 802.11v with 802.11k, because a transition request only helps if the handset already knows its options.

802.11r: fast BSS transition

802.11r, also called fast transition (FT), changes how encryption keys are set up during a roam.

IEEE 802.1X is the port-based authentication standard behind enterprise WiFi. RADIUS is the protocol your access points use to check credentials with an authentication server. Without FT, a handset on WPA2-Enterprise or WPA3-Enterprise repeats the full 802.1X exchange with the RADIUS server at every new access point. It then completes a four-way key handshake.

With 802.11r, the first connection still authenticates in full. Later roams within the same mobility domain derive fresh keys from a cached key hierarchy. That key exchange is folded into the authentication and reassociation frames. There is no trip to the RADIUS server and no separate four-way handshake.

This matters most for voice and push-to-talk. ITU-T Recommendation G.114 advises keeping one-way voice delay under 150 milliseconds. A full 802.1X exchange with a cloud RADIUS service, repeated at every access point, eats into that budget.

Why Android support varies by chipset and manufacturer

Google publishes the Android framework, but fast roaming lives lower in the stack. Support depends on four layers:

1. The chipset, from vendors such as Qualcomm, Broadcom and MediaTek.
2. The chipset vendor's driver and firmware.
3. The manufacturer's build.
4. The Android release.

A manufacturer can ship a chipset that supports 802.11r with the feature disabled or partly implemented. Ruggedised handsets and budget tablets often stay on older drivers for years.

Certification is the most practical signal. The WiFi Alliance's Agile Multiband programme tests 802.11k, 802.11v and 802.11r interoperability. Its Voice-Enterprise programme tests fast roaming for voice handsets. A certified model has passed interoperability testing. An uncertified model may still work, but you need to test it yourself.

For the protocol detail behind all three amendments, see Purple's 802.11r, 802.11k and 802.11v deployment guide.

What do you need before you enable 802.11r for Android?

Gather six things before you change a production SSID (the network name your devices join).

• A handset inventory. Pull model, Android release and security patch level from your mobile device management (MDM) platform. Group the fleet by model, because the model predicts roaming behaviour better than the Android release.
• Supported access point firmware. Confirm that your Cisco Meraki, HPE Aruba or Ubiquiti UniFi firmware supports 802.11r on the security type you run. Check the vendor's current release notes.
• One mobility domain. Fast transition only works between access points that share key material. Keep the access points a handset moves between in the same Meraki network, Aruba controller cluster or UniFi site. A roam across that boundary falls back to full authentication.
• Coverage overlap. A handset can only roam to an access point it can hear well. Validate overlap with a survey before tuning roaming settings. See WiFi Site Surveys: A Practical Planning Guide.
• Capture kit. You need a laptop or USB adapter that supports monitor mode, plus Wireshark, which is free.
• A pilot SSID. Clone production with the same security, VLAN and RADIUS server. A VLAN (virtual LAN) is the network segment where the traffic lands. Test on the clone, then promote the settings.

How do you set up fast roaming for a mixed Android fleet?

Work from the lowest risk to the highest:

1. Enable 802.11k and 802.11v on the pilot SSID. Handsets that do not support them ignore the extra elements, so association failures are rare.
2. Enable 802.11r in mixed mode. Each SSID advertises one or more authentication and key management (AKM) suites. Mixed mode advertises standard and FT suites side by side, so non-FT handsets can still join.
3. Keep FT over the air. Leave over-the-DS signalling off unless you have a tested reason to use it.
4. Test every handset model. Join the SSID, walk between access points during a call, and capture the roams.
5. Choose a strategy and roll out. Use the matrix below, then move settings to production in a change window with a rollback plan.

Which 802.11r strategy suits your Android fleet?

Your Android fleet	802.11r setting	802.11k and 802.11v	Why
Managed handsets, every model passes the pilot	Enabled, mixed mode, on the staff SSID	On	FT-capable handsets fast roam, and any non-FT device still joins with full 802.1X
Mostly current handsets, one or two legacy models fail in mixed mode	Enabled on the main SSID, plus a legacy SSID with 802.11r off on the same VLAN	On for both SSIDs	Legacy models keep working while the rest of the fleet fast roams
BYOD or a large estate of unknown models	Disabled	On	Avoids association failures, and PMK caching still shortens returns to an access point the handset has already visited
Cisco Meraki network, mostly Apple devices with some Android	Adaptive	On	Supported Apple devices fast roam, while Android handsets use full 802.1X
Dedicated voice or push-to-talk handsets, all one tested model	Enabled, mixed mode, on a dedicated voice SSID	On	Voice traffic gets the shortest roam without exposing other devices to FT

PMK caching is the standard 802.11i mechanism that lets a handset reuse a pairwise master key with an access point it has already authenticated to.

Fast transition over the air or over the distribution system?

802.11r defines two ways to carry the FT exchange. Over the air, the handset talks directly to the target access point. Over the distribution system (DS), the handset sends FT action frames to its current access point, which relays them across the wired network to the target.

Factor	Over the air	Over the DS
Frame path	Handset to target access point, by radio	Handset to current access point, then wired relay to the target
Android support	Common across FT-capable Android chipsets	Patchier, with some drivers mishandling the capability bit
When it helps	Most venues with good cell overlap	Edge cases where the target access point is weak at the moment of the roam
Failure mode	Roam falls back to full authentication	Roam can time out before the handset retries
Purple recommendation	Default for mixed Android fleets	Only after a passed per-model test

Cisco Meraki

Meraki exposes 802.11r per SSID with three options: Disabled, Enabled and Adaptive. Enabled advertises FT alongside standard key management, which is mixed mode. Adaptive enables FT only for Apple iOS devices that support Cisco's adaptive 802.11r extension. Android handsets on an Adaptive SSID join with standard authentication and get no fast transition. For an Android-heavy fleet, test Enabled on your pilot SSID instead. Meraki's documentation notes that some older devices cannot associate when 802.11r is enabled. Follow it for the current steps.

HPE Aruba

Aruba configures fast transition per WLAN. In ArubaOS controller deployments, the 802.11r profile attached to the SSID enables FT and holds the over-the-DS option. 802.11k and BSS transition management sit in the 802.11k profile. Aruba Instant and Aruba Central present the same features in the WLAN's roaming settings. Aruba also supports opportunistic key caching (OKC), a non-standard way of sharing keys between access points. Confirm that a handset model supports OKC before you rely on it as a fallback.

Ubiquiti UniFi

UniFi exposes 802.11r as Fast Roaming and 802.11v as BSS Transition in each WiFi network's advanced settings. Ubiquiti warns that some older devices may not support Fast Roaming. Enable BSS Transition first, then Fast Roaming on the pilot network. Check the release notes for your Network application version before production rollout.

Where Purple fits

Purple's Staff WiFi provides the identity layer through Identity-Based Networks. It authenticates staff over 802.1X against Microsoft Entra ID, Okta or Google Workspace, using cloud RADIUS. Fast transition runs on your access points. Purple authenticates the first connection, and 802.11r keeps later roams inside your WLAN.

Purple is hardware-agnostic and runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. It operates across 80,000+ live venues and handled 440 million logins in 2024 (Purple data).

Plan for leavers. When you revoke an identity, the change applies at that device's next full authentication. Until then, a revoked device can keep roaming on cached keys within the mobility domain. Your session timeout sets that window, so align it with your joiners, movers and leavers (JML) policy.

How do you check whether an Android device used fast transition?

Use three layers of evidence. Only the packet capture is definitive.

On the controller

Most controllers list per-client capabilities parsed from the association request, including 802.11r, 802.11k and 802.11v support. Open the client's detail view and roam history in your Meraki, Aruba or UniFi dashboard. A capability flag shows that the handset can use FT. It does not prove that a particular roam used it.

In an over-the-air capture

Capture on the target access point's channel while a tester walks the handset between cells. The table shows what to look for in Wireshark.

What you see	Frame	What it means
Mobility Domain element, ID 54	Beacon or probe response	The access point advertises 802.11r
AKM suite 00-0F-AC:3, :4 or :9	Handset's association or reassociation request	The handset chose FT-802.1X, FT-PSK or FT-SAE
Authentication algorithm number 2	Authentication frame during the roam	The handset performed an over-the-air FT roam
FT action frames to the current access point	Action frames before the roam	The handset performed an over-the-DS roam
Algorithm 0, then a full EAP exchange and four-way handshake	Authentication, EAPOL	No FT, so the handset ran full 802.1X
RM Enabled Capabilities element, ID 70, and neighbour report requests	Association request, action frames	The handset supports and uses 802.11k
BSS transition management query, request and response	Wireless network management (WNM) action frames	The handset supports and uses 802.11v

A successful 802.1X FT roam shows the FT authentication and reassociation exchange with no EAP traffic and no four-way handshake.

On the handset

Turn on Developer options, then enable the WiFi verbose logging option. Connect over ADB (Android Debug Bridge) and run adb shell dumpsys wifi, or take a bug report. Look for the key management names that wpa_supplicant uses: FT-EAP, FT-PSK or FT-SAE. Output varies by manufacturer and Android release, so treat it as supporting evidence rather than proof.

Why do some Android phones fail to connect when 802.11r is on?

Most failures trace back to six causes.

• The driver mis-parses mixed mode. Some older drivers cannot handle FT suites in the security element alongside standard ones. The handset fails to associate, or in some cases does not list the network at all. Fix it with a legacy SSID without FT, a manufacturer update pushed through MDM, or retirement of the model.
• The SSID is configured FT-only. Handsets without FT cannot join an SSID that advertises only FT suites. Fix it by switching to mixed mode.
• Over the DS is advertised. Handsets that mishandle the capability bit fail roams and then reconnect slowly. Fix it by returning to over the air.
• WPA3 adds Protected Management Frames. WPA3 requires PMF (802.11w), and FT-SAE support is patchier than FT-PSK or FT-802.1X. A handset that passes on WPA2 can still fail on WPA3. Test each security mode separately.
• The roam crosses mobility domains. A move between Meraki networks, Aruba clusters or UniFi sites forces full authentication. That can look like broken FT. Fix it in the network design, not on the handset.
• Handsets stay on a weak access point. FT shortens the roam but does not make a handset roam sooner. Rely on 802.11k and 802.11v, and raise minimum data rates carefully. Aggressive client steering can disconnect Android handsets outright.

Worked scenarios from hotels, retail and the public sector

These are illustrative deployments, not named Purple customers. Each one shows the decision path and the measure used to confirm the result.

A 200-room hotel on Cisco Meraki

Situation. Housekeeping and maintenance teams used Android handsets with a VoIP app on a WPA2-Enterprise staff SSID. 802.11r was disabled, and calls dropped between floors. The fleet held two models: a current Agile Multiband-certified handset and 18 older ruggedised units.

What was done. The team enabled 802.11r on a pilot SSID, and all 18 older units failed to associate. They set the main staff SSID to Enabled and added a legacy SSID with 802.11r off, on the same VLAN and RADIUS policy. 802.11k and 802.11v stayed on for both SSIDs.

Outcome. Captures showed the current handsets roaming with algorithm 2 authentication and no EAP traffic. RADIUS requests from those handsets fell from one per roam to one per session. All 18 legacy units connected on day one and were scheduled for replacement. For more on Hotels, see Purple's hospitality pages.

A 40-store retail chain on HPE Aruba

Situation. Stock teams used Android scanners that hold a live session to the stock system. 802.11r was already on, with over the DS enabled. One scanner model kept dropping sessions between the stock room and the shop floor.

What was done. In a pilot store, the team turned off over the DS and kept FT over the air. They enabled 802.11k and BSS transition management, then captured roams for each scanner model.

Outcome. Captures confirmed over-the-air FT roams for every model. Roam failures for the affected model stopped in the pilot store. The change reached all 40 stores over two change windows. See Retail for Purple's retail work.

A council office on Ubiquiti UniFi

Situation. Corporate Android handsets and BYOD (bring your own device) phones shared one network. Staff reported Teams call drops in a long open-plan floor.

What was done. The team split the network into a corporate SSID with Fast Roaming and BSS Transition on, and a BYOD SSID with BSS Transition only. They tested each corporate handset model before rollout.

Outcome. Corporate handsets showed FT roams in captures. BYOD devices joined without association failures because they never saw FT. The same model suits ward handsets in Healthcare, where clinical devices and personal phones share the same buildings.

What does fast roaming cost, and what do you get back?

802.11r, 802.11k and 802.11v are firmware features on Cisco Meraki, HPE Aruba and Ubiquiti UniFi access points. None of them needs a separate feature licence. The main cost is engineering time:

• Building a pilot SSID.
• Testing each handset model.
• Taking captures.
• Booking change windows.

A legacy SSID carries a smaller hidden cost. Every SSID sends its own beacons, which consume airtime on every channel.

The return is measurable. A handset that roams 30 times in a shift triggers 30 full 802.1X exchanges without FT. With FT, it triggers one per session, plus PMK cache hits on access points it revisits. That cuts load on your RADIUS service and removes repeated authentication gaps from voice calls and scanner sessions. You get this from access points you already own; see Why your next WiFi upgrade doesn't need new hardware.

Fast transition matters most on secured staff SSIDs. On an open or captive-portal Guest WiFi SSID, there is no 802.1X exchange to shorten, so the gain is small. If you are pricing the guest side on the same access points, see Captive portal pricing compared: per site, per access point and per user models.

Frequently asked questions

Does Android support 802.11r fast transition?

Yes, most current Android handsets support 802.11r, but support depends on the chipset, driver and manufacturer build rather than the Android release. Roaming usually runs in chipset firmware, so two phones on the same Android release can behave differently. Agile Multiband or Voice-Enterprise certification is the strongest signal. For uncertified models, confirm FT in a packet capture by looking for FT key management in the association request and algorithm 2 authentication during a roam.

Does Android support 802.11k and 802.11v?

Yes, many Android handsets use 802.11k neighbour reports and 802.11v BSS transition requests, again depending on chipset and manufacturer. Handsets without support ignore the extra elements, so enabling both rarely blocks association. Android treats 802.11v requests as advice, not instructions. Confirm support per model by checking the RM Enabled Capabilities element and the BSS transition management frames in a capture.

Do I need an extra licence for 802.11r on Cisco Meraki, HPE Aruba or Ubiquiti UniFi?

No, 802.11r, 802.11k and 802.11v are included firmware features on all three platforms, with no separate feature licence. Your cost is engineering time for a pilot SSID, per-model testing and change windows. If you add a legacy SSID for older handsets, expect a small airtime cost from the extra beacons rather than a licence fee.

Will enabling 802.11r lock older Android devices out of my network?

It can, which is why you should test on a pilot SSID first. Some older drivers fail to associate when an SSID advertises FT alongside standard key management. Use mixed mode, never FT-only, and keep FT over the air. If a model still fails, give it a legacy SSID with 802.11r off on the same VLAN, update its firmware through MDM, or retire it.

Should I use Adaptive 802.11r on Cisco Meraki for Android devices?

No, Adaptive 802.11r gives Android handsets no fast transition. It enables FT only for Apple iOS devices that support Cisco's adaptive extension. Android devices on an Adaptive SSID join with standard 802.1X and run a full authentication at every roam. For an Android-heavy fleet, test the Enabled setting on a pilot SSID and fall back to a legacy SSID for any model that fails.

Does Purple Staff WiFi work with 802.11r on my existing access points?

Yes, Purple's Staff WiFi runs on your existing access points and works alongside 802.11r. Purple is hardware-agnostic across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Purple's cloud RADIUS authenticates the first connection against Microsoft Entra ID, Okta or Google Workspace. Fast transition then keeps later roams on your access points, without a return trip to RADIUS.

Does fast roaming affect PCI DSS or GDPR compliance?

No, 802.11r keeps 802.1X-grade encryption and does not change the personal data you process. PCI DSS requires strong cryptography for wireless networks that carry cardholder data, and FT derives fresh per-session keys at every roam. Under GDPR, roaming collects no new personal data. Review your session timeout, because it sets how long a revoked device can keep roaming on cached keys.

How long does an 802.11r rollout for an Android fleet take?

Plan for one pilot cycle per handset model, then a production change window per site or group of sites. The setting change takes minutes, while testing takes most of the time. Each model needs a join test, a walk test during a call and a capture. A fleet with two or three models on one controller platform usually fits a single pilot cycle before rollout.