Roaming in Wi-Fi is a critical component of the overall user experience. It can make or break the perception of a wireless network, especially when real-time applications like voice or live video are in use. Seamless, fast roaming is essential—but here’s the catch: roaming is a client decision, and every device handles it a bit differently. In this chapter, we’ll explore the roaming techniques available and why capabilities like 802.11r play a major role in improving the handoff process.
Roaming basics
At its core, roaming simply means a client moves its association from one AP to another. But in reality, it’s more than that. Before a client can associate, it must authenticate—and if encryption is in place (which we hope it is), the dynamic encryption and temporal keys must be re-established.
These steps all need to happen before a roaming event is considered successful. Unlike the initial association (which uses an Association Request/Response), roaming uses a Reassociation Request/Response. I covered the full roaming process in detail during my CWAP Chapter 5 blog post.
Roaming Time
The number one key metric in deciding whether a roam is good or bad is the roaming time. This is the duration between the last packet sent on the previously connected AP and the moment the 4-way handshake with the new AP is completed — meaning data packets can flow again.
As mentioned earlier, this becomes especially critical with real-time applications like voice. The maximum recommended roaming delay for uninterrupted calls is 150ms, and that’s the number we’ll focus on.
If we’re talking about basic, unenhanced roaming, there’s already a big difference between WPA2-Personal and WPA2-Enterprise. With WPA2-Personal (PSK), authentication is relatively fast — a typical roam from start to 4-way handshake completion takes about 50–100ms, comfortably under the 150ms threshold. So in that case, we’re usually fine.
But with WPA2-Enterprise (802.1X), things get slower. A full roam can take anywhere between 250ms to over 500ms — way past the comfort zone for voice or video. You’ll likely notice drops, jitter, or even call termination during a roam like that.
A slow roam on a WPA2-Enterpise SSID includes the following steps:
- Open System authentication
- (re-)association
- 802.1X/EAP Authentication
- 4-way handshake
Steps 1, 2, and 4 are pretty much identical to those in a fast PSK roam. That puts the spotlight on the 802.1X/EAP authentication as the main delay factor. And to make matters worse, this delay doesn’t just depend on your Wi-Fi infrastructure — it’s also influenced by where your RADIUS server lives. If it’s sitting on a remote site, every bit of latency adds up. We know now where the problem resides and just need to understand how we can solve this challenge.
Layer 2 and Layer 3 Roaming
Apart from security mechanisms, roaming behavior also depends on how the wireless environment is set up. Roaming typically happens in one of the following ways:
- Layer 2 roaming across APs within a single controller, or even without one
- Layer 2 roaming across APs connected to separate controllers
- Layer 3 roaming
When a device roams at Layer 2, its IP configuration remains intact. Since the IP doesn’t change, ongoing sessions — like voice or video calls — stay alive, making Layer 2 roaming the preferred method. In fact, it’s essential for supporting real-time services like VoIP.
If maintaining the same IP address is mission-critical, deploying a wireless controller can make life much easier. While distributed APs often need proprietary protocols to handle client movement, a controller can streamline the process. If client traffic is tunneled through the controller, it can track the MAC address and coordinate the roam between APs more efficiently.
Layer 3 roaming occurs when the client STA roams to an AP that cannot provide the same IP configuration. Possible explanations are that the AP is on a different wired network, a different VLAN subnet or uses a different L2 space for the same SSID (Carpenter et al., p300). In that case, the client has to get a new IP address via DHCP, and that’s where things break down.
Session continuity? Gone. If you’re in the middle of a file transfer or a voice call, there’s a good chance that session will drop — leading to frustration, especially for latency-sensitive applications.
To solve roaming issues—especially on WPA2-Enterprise networks—fast and secure roaming mechanisms must be implemented. Techniques like 802.11r (Fast BSS Transition) allow clients to pre-negotiate key material with APs, eliminating the need to perform full EAP exchanges on every roam.
Note: While these solutions don’t fix Layer 3 roaming issues (like IP reassignment), they do reduce roaming time dramatically, leading to better efficiency, fewer dropped sessions, and an overall smoother user experience.
Wi-Fi Voice Enterprise and Roaming Enhancements
Before diving into all the optimizations for fast and secure roaming, it’s worth highlighting the Wi-Fi Voice Enterprise® certification. If you’re working on VoWLAN (Voice over WLAN) deployments, you’ll want to be familiar with the requirements for this type of application. Meeting these standards—when properly designed and implemented—should deliver enterprise-grade voice quality, even in demanding wireless environments where latency, jitter, and packet loss need to be kept in check.
Key features of the Wi-Fi Voice Enterprise certification include:
- Traffic Prioritization: WMM (Wi-Fi Multimedia) allows you to prioritize voice traffic over less time-sensitive data using Quality of Service (QoS) mechanisms.
- Bandwidth Management: WMM Admission Control ensures bandwidth is managed effectively, providing the resources voice traffic needs and preventing oversubscription.
- Seamless Transitions: 802.11r (Fast BSS Transition) enables clients to roam quickly and smoothly between APs, preventing voice dropouts.
- Power Saving: WMM-Power Save helps extend battery life on mobile devices by optimizing how and when packets are transmitted.
- Security: Strong security using WPA2-Enterprise or WPA3-Enterprise ensures that sensitive voice communications are protected.
(wifi.org, 2025)
With these features in place, the target performance for VoWLAN roaming is typically a maximum delay of 50ms, with occasional spikes up to 100ms allowed, which helps maintain call quality during transitions.
In addition to 802.11r (for fast roaming) and 802.11e (for QoS), other helpful features include 802.11k and 802.11v, both of which further enhance the roaming process:
- 802.11k – Radio Resource Measurement: This amendment allows the AP to provide clients with information about neighboring APs, including channel and signal strength data. The client can use this “neighbor report” to make smarter roaming decisions, rather than scanning all channels. This reduces roaming time and helps avoid sticky client issues.
- 802.11v – Wireless Network Management: This amendment enables network-assisted roaming. The AP can “suggest” to the client that a roam may be beneficial based on changing RF conditions or load balancing needs. This is done via a ‘BSS Transition Management Request’ action frame, which nudges the client in the right direction—though the final roam decision still lies with the client.
Together, these enhancements form a solid foundation for improving roaming efficiency and user experience, especially in environments that rely heavily on voice or real-time communications.
Now that we’ve got the basics out of the way, let’s take a closer look at how roaming can actually be improved. I already discussed this in my blog post on CWAP Chapter 5, but to make things easier for you — so you don’t have to open another tab and jump back and forth — I’ll paste the relevant part right here. Everything quoted from the previous post will be in italic font for clarity.
Preauthentication and PMK Caching
- Preauthentication: The station can have multiple PMK Security Associations (PMKSA) with other APs. 802.1X authentication against target APs is established via the currently connected AP, resulting in a PMKSA. This eliminates the need to go through the EAP authentication process, leading to faster and shorter connections.
- PMK Caching: The PMK used by the station is cached on the AP. This means that if the station roams back to the same AP and the PMK is still cached (and hasn’t expired), the EAP authentication process does not need to be repeated. However, this caching only works if the station returns to an AP it’s already associated with. It will not work with a previously unassociated AP.
Both legacy methods of Preauthentication and PMK Caching do not scale well in large Wi-Fi deployments. For them to work effectively, every AP must maintain a PMKSA with all associated stations.
Fast Transition
In 2009, the 802.11r amendment introduced Fast (BSS) Transition (FT), revolutionizing Wi-Fi roaming. For stations and APs to participate in this process, they must belong to the same Mobility Domain—an identifier that essentially defines a “roaming domain.” Think of it as a way to group APs together to enable fast and seamless transitions between them. However, it’s best practice to create separate mobility domains for different campuses. This approach minimizes overhead (since APs within a mobility domain communicate with each other) and simplifies troubleshooting by keeping roaming boundaries manageable.
There are two ways that FT can happen: Over-the-Air and Over-the-DS.
Over-the-Air is the common mode you’ll encounter in the field. Both modes speak for themselves. In this mode, a station performs an authentication and reassociation exchange over-the-air and “off-channel” with the target AP. The authentication algorithm is set to Fast BSS Transition (2), and a new PMK is derived from the current AP. Only after this is done does the station disassociate from the current AP and reassociate with the target AP.
Over-the-DS shares some similarities, but instead of sending authentication frames directly to the target AP, it sends FT Action frames to the current AP. The current AP then forwards the frames to possible target APs over the wired network, and the FT Action response is sent back to the station. Once the station receives its desired response, it can dissociate and reassociate with the target AP.
PMK-R0 and PMK-R1
There are a couple of things I didn’t cover or highlight in my CWAP post that are worth mentioning here. One important detail is that when 802.11r (Fast BSS Transition, or FT) is enabled, we no longer speak of just a single PMK. Instead, the PMK is split into two components: PMK-R0 and PMK-R1.
You can think of the PMK-R0 as the “real” PMK—just like in PSK or non-FT-enabled 802.1X networks. The PMK-R1 is derived from this PMK-R0, which in turn is derived from the MSK during the 802.1X/EAP authentication process. The key distinction is that PMK-R1 is unique per AP in the mobility domain.
The PMK-R0 is held by the supplicant (client) on one side and by either the controller or the first AP (in a controller-less deployment) on the other. These PMK-R1 keys are then securely distributed from the PMK-R0 holder to other APs in the mobility domain. This can happen proactively or on-demand—for example, the target AP may request the PMK-R1 key over the wired LAN from the PMK-R0 holder when a client is about to roam.
These keys aren’t valid forever. They have a limited lifetime, governed by configurable reauthentication or caching timers on the authenticator side. Once the reauthentication period expires and a new PMK-R0 is created, all associated PMK-R1 keys must also be regenerated and redistributed accordingly.
Fast Roaming Information Elements
Based on this knowledge, we’re almost there in painting the full picture of how fast roaming works. Two key components in the process are the Mobility Domain Element (MDE) and the Fast BSS Transition Element (FTE).
The MDE contains the Mobility Domain ID and the FT Capability and Policy fields, and it’s advertised by the AP in beacon and probe response frames. This element is later included by the supplicant in its FT Authentication and (Re)Association Request frames. A successful roam requires the client to match the parameters advertised by the AP. The FT Capability and Policy field also indicates which FT method is being used—Over-the-DS or Over-the-Air (with Over-DS = 0 for Over-the-Air).
The FTE is where things get more interesting. It includes the ANonce, SNonce, and identifiers for both the PMK-R0 and PMK-R1 holders on the authenticator side (R0KH-ID and R1KH-ID). The R0KH-ID is hashed for security reasons, while the R1KH-ID is sent in the clear—it’s actually the MAC address of the AP the client is roaming to. This explicit detail avoids any ambiguity between client and AP (since theoretically, something like the Receiver Address could’ve been misinterpreted as the target AP).
The ANonce and SNonce values in the FTE should ring a bell—they’re exactly what’s used to derive the PTK, just like in the traditional 4-way handshake. Combined with the PMK information, they allow both the AP and the client to generate matching session keys. And yes, the GTK is still sent in the Reassociation Response from the AP to the client. What’s beautiful here is that these four frames—Authentication Request and Response + Reassociation Request and Response—contain everything needed for the 4-way handshake. Efficiency at its finest.
This process describes how Over-the-Air FT works. The only difference with Over-the-DS is in the frame exchange: instead of direct 802.11 FT Authentication frames, the AP sends FT Request and FT Response action frames over the wired network. These include the same info, plus the MAC addresses of both the roaming station and the target AP. Once the target AP replies, the original AP forwards the response back over 802.11 to the client.
In practice, Over-the-Air is the most commonly used method and typically the faster one—because the client can talk directly to the AP it’s trying to roam to. That said, both methods are valid, and the performance difference is usually minimal. What matters is that they both dramatically reduce roaming delays.
Hopefully this gave you a better grasp of the building blocks of 802.11r—and how they come together to deliver fast and secure roaming across your wireless network.
Single Channel Architecture
Another (proprietary) approach to eliminate roaming delays is the well-known Single Channel Architecture, or SCA. It’s a solution that only a couple of vendors ever adopted—most notably Meru Networks, which was later acquired by Fortinet in 2015. I’ve worked with this architecture quite a bit at my first employer, so this stuff is familiar to me.
The core concept behind SCA is that all APs broadcast the same BSSID over the same channel. From the client’s perspective, it appears there’s only one AP on the network—so it doesn’t even try to roam. There’s no decision-making by the client at all. Instead, the infrastructure handles the roaming entirely behind the scenes, and the client doesn’t even need to reauthenticate.
Sounds like a dream, right? There are clear benefits: no roaming delays, no handoff hiccups, and a simplified experience for the client. But—of course—there are trade-offs.
First, it’s a proprietary design, not part of the 802.11 standard. Second, since all APs operate on the same channel, you’re inherently dealing with Co-Channel Contention, which limits the functional capacity of your WLAN. While you could try to mitigate this by deploying different SCA domains per wing or floor (each with their own channel), or by placing multiple stacked APs with different channels next to each other, it’s still a design constraint you have to work around.
In the case of these stacked APs—where multiple SCA domains are deployed side by side on different channels—the client will stick to its initially assigned AP and channel for as long as the signal remains above the roaming threshold (typically around -70 dBm). As long as the primary signal strength stays “good enough,” the client sees no reason to roam.
But when that signal eventually drops and the client decides to jump to another AP on a different channel, things start to fall apart. Since this type of roaming no longer happens within a single BSSID, it’s not handled by the infrastructure in the same seamless way. Instead, the client reverts to standard 802.11 roaming behavior, and the controller may not always manage the transition smoothly—leading to possible disruption or delay.
For CWSP purposes, just remember the key takeaway: Single Channel Architecture uses a single BSSID across all APs, and roaming is fully managed by the infrastructure—not the client.
Roaming is one of those things that often gets overlooked—until it doesn’t work. At that point, users start noticing dropped calls, frozen video, or failed file uploads. We’ve now unpacked what makes roaming fast or slow, what kind of impact different security methods have, and how technologies like 802.11r, k, and v help keep things moving smoothly.
Of course, not every deployment needs every feature. But if you’re supporting applications where latency matters, then understanding how these mechanisms interact is crucial. Roaming isn’t just a client issue—it’s a design consideration that stretches from the controller to the AP and even into the wired side of the network.
Solid roaming performance doesn’t happen by accident. It’s the result of good planning, understanding the standards, and knowing how your clients behave.
Source(s):
Carpenter, T., et al. (2023). CWSP-207: Certified Wireless Security Professional Study Guide (1st ed.). Durham NC, USA: Certitrek Publishing
wi-fi.org. (n.d.) Voice Enterprise. Retrieved May 26, 2025, from https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-voice-enterprise