← all cheat sheets
FUNDAMENTALS · MECHANISM WALKTHROUGH

Wi-Fi Roaming Mid-Call
Staying Connected Across APs

the roam decision is entirely the client's — the network can only make it faster. this is the mechanism (802.11r/k/v) that turns a multi-hundred-millisecond re-authentication into something imperceptible on an active call.
RSSI DEGRADES NEIGHBOR REPORT (11k) CLIENT SCANS CANDIDATES CLIENT DECIDES TO ROAM FAST BSS TRANSITION (11r) REASSOCIATION SAME IP, NO DHCP
01 The Full Sequence — Worked Example
1

The Setup

A user is mid-call on a laptop, associated to AP1 on SSID "Corp-Secure" (WPA2-Enterprise), managed by a controller/cloud platform (e.g. Meraki/Aruba) with 802.11r/k/v enabled across the wireless estate. AP2, on the same SSID and mobility domain, sits further down the corridor the user is walking toward.

Setup
2

Signal Degrades as the Client Moves

The client continuously monitors the RSSI (signal strength) of its current AP. As the user walks away from AP1, measured RSSI drops below the client driver's roaming threshold.

RSSI
3

802.11k Neighbor Report

AP1 proactively provides the client a Neighbor Report — a list of nearby APs and the channels they operate on. This lets the client target its scan directly at likely roam candidates (AP2 included) instead of blindly scanning every channel, dramatically cutting scan time.

802.11k
4

Client Background Scanning

Using the neighbor list, the client measures signal from candidate APs during brief off-channel gaps, timed to minimize disruption to the active call's audio/video stream.

Scan
5

The Roam Decision — Entirely the Client's

The client's driver/OS decides AP2 now offers meaningfully better signal than staying on AP1, and decides to roam. This decision is made entirely by the client — the network can only assist and suggest via neighbor reports and BSS transition hints, never force a roam.

Decision
6

Checkpoint — Why This Needs to Be Fast

Without any fast-roaming mechanism, moving to AP2 would require a full 802.1X/EAP/RADIUS re-authentication — the same multi-round-trip process as an initial connection. That's fine for a fresh connection, but for an active call, the resulting latency (often hundreds of milliseconds to over a second) is easily enough to cause an audible glitch, dropped packets, or a dropped call entirely.

Checkpoint
7

802.11r — Fast BSS Transition

With 802.11r enabled and supported end-to-end, the client pre-negotiates keying material with AP2 before actually roaming, using its existing association with AP1 to carry the FT messages. Because both APs share the same mobility domain and a cached PMK-R0/R1 key hierarchy, a fresh PTK for AP2 can be derived without a full new EAP/RADIUS exchange.

802.11r
8

Fallback — PMK Caching Without 802.11r

Where 802.11r isn't available, some deployments rely on PMK caching instead: if the controller shares PMKs across APs in the same mobility group, the client can skip the full EAP exchange but still needs to run a quick 4-way handshake using the cached PMK — faster than a full re-auth, but not as fast as 802.11r's pre-negotiated keys.

PMK Cache
9

Reassociation to AP2

The client sends a Reassociation Request to AP2, completing whichever abbreviated key exchange is available. AP2 confirms, and the controller updates its client-location table so wired-side traffic is now forwarded to AP2 instead of AP1.

Reassociation
10

Same IP — No DHCP Required

Because AP1 and AP2 sit in the same VLAN/subnet within the controller-managed mobility domain, the client keeps its existing IP address across the roam entirely — there's no DHCP release/renew involved. This is exactly why enterprise WLAN design deliberately keeps one consistent VLAN across an entire floor or building: it's what makes roaming seamless at Layer 3, not just Layer 2.

No DHCP
11

Call Continuity

With 802.11r active, the entire roam typically completes in under 50ms — imperceptible on an active call. Without it, the multi-hundred-millisecond to multi-second full re-authentication is often audible as a freeze or glitch, or can cause the call to drop outright — precisely why voice/video-heavy enterprise WLANs specifically enable 802.11r/k/v rather than leaving roaming to chance.

Delivered
02 How to Explain This in an Interview
03 Follow-Up / Gotcha Questions
Q What's the difference between 802.11r, 802.11k, and 802.11v?
A 802.11r (Fast BSS Transition) is what actually speeds up the authentication/key exchange during a roam. 802.11k (Neighbor Reports) speeds up how quickly a client finds good roam candidates by giving it a targeted list instead of a blind scan. 802.11v (BSS Transition Management) lets the network suggest a client should roam to a specific AP — useful for load balancing — but like the roam decision itself, the client can still choose to ignore the suggestion.
Q Why doesn't the client need a new DHCP lease when roaming to a new AP?
A Because both APs are part of the same VLAN/subnet within the controller's mobility domain — the client's IP configuration is still valid on the new AP, so there's nothing to renew. This is a deliberate design choice; if APs on the same floor were split across different VLANs, roaming would force a DHCP renewal and briefly interrupt any active session.
Q Is the roam decision made by the client or the network?
A The client. The network's role is limited to making the decision faster and better-informed — via neighbor reports (802.11k) and transition suggestions (802.11v) — but the actual choice of when and where to roam is made by the client's own driver and radio management logic.
Q What happens if the client device doesn't support 802.11r?
A It falls back to whatever the network supports next — PMK caching if configured, or a full 802.1X/EAP/RADIUS re-authentication if not. The roam still succeeds, but takes materially longer, and on an active call is far more likely to produce a noticeable glitch or drop.
Q What is a mobility domain, and why does it matter for fast roaming?
A It's the set of APs configured to share the same 802.11r key hierarchy (PMK-R0/R1), letting a client's pre-negotiated keys be valid across any AP within that domain. Roaming between APs in different mobility domains — e.g. different buildings on entirely separate controllers — can't use Fast BSS Transition at all, and falls back to a full re-authentication regardless of 11r support on the client.
Q Why might a call still glitch briefly even with 802.11r properly enabled?
A Even a fast, well-executed roam still involves a brief window where the client isn't transmitting/receiving on either AP — commonly tens of milliseconds. Under normal conditions this is imperceptible, but combined with other factors (RF interference, a marginal signal at the moment of roam, or a client that scans poorly) it can occasionally still produce a small audible artifact even when the underlying mechanism is working exactly as designed.
04 Quick-Fire Glossary
TermMeaning
RSSIReceived Signal Strength Indicator — the metric a client uses to judge its current AP's link quality
802.11kNeighbor Reports — lets a client scan targeted roam candidates instead of blindly scanning all channels
802.11rFast BSS Transition — pre-negotiates keying material with a target AP before the client actually roams
802.11vBSS Transition Management — network-suggested roam targets, e.g. for load balancing
PMK-R0 / PMK-R1The key hierarchy 802.11r uses to derive per-AP session keys without a full new EAP exchange
Mobility DomainThe set of APs sharing a common 802.11r key hierarchy, enabling Fast BSS Transition between them
ESSExtended Service Set — multiple APs presenting the same SSID as one logical, roamable network
ReassociationThe frame exchange a client uses to move its association from one AP to another within the same ESS
WLCWireless LAN Controller — centrally manages APs, client roaming state, and mobility groups
PMK CachingReusing a previously established PMK to skip full EAP re-authentication on a subsequent roam/reconnect