Cisco Optimized Roaming: Client behavior with 11v vs. without 11v

With or Without V

In my previous blog entry, I discussed what is necessary to get BSS Transition Management working with Cisco controller-based Wi-Fi networks. In this entry, I wanted to present a comparison of client behavior when BSS Transition Management is enabled to when it is not enabled.

For you to see 11v frames from your Cisco network, either aggressive load balancing or optimized roaming must be enabled. For this discussion, I will focus on optimized roaming. The optimized roaming engine will keep track of client statistics, such as RSSI and data rate, and disassociate clients that don't meet configurable thresholds. If BSS Transition Management is enabled (at the WLAN level) in combination with optimized roaming, the AP will send a transition request to a client before disassociating it, giving the client time to roam to a better AP. If BSS Transition Management is not enabled, or the client does not support it, the client will simply be disassociated.

Before I dive into the packet captures, we need to discuss a specific detail of optimized roaming: the engine only looks at RSSI of data packets, not management or action. To see optimized roaming work, the client must be moving data.

The test client was my Windows 10 Dell laptop with an integrated Intel 8260 dual-band wireless adapter. The advanced configuration for the adapter has a parameter called "roaming aggressiveness," which has 5 options, from lowest to highest. According to Intel's documentation, the setting "lowest" means the client will not roam unless it loses connectivity. I set roaming aggressiveness to "lowest" for the tests, so the optimized roaming engine would try to get my client to roam before it decided to itself.

The test WLAN had an SSID of Test, 5 GHz only. The WLAN was configured for WPA2-Enterprise with Fast Transition. BSS Transition Management was on for the first test, then turned off for the second.

The test setup was identical to my first post: two APs in local mode and two APs in sniffer mode, watching the same channels as the local mode APs nearest to them.

Figure 1: Testing setup

I would start off by associating to the "Back" AP, then moving towards the "Front" AP. Because I had set the roaming aggressiveness of my client to its lowest setting, I could get to line-of-sight of the "Font" AP and still be connected to the "Back" AP. I would verify what AP my client was connected to by issuing a netsh wlan show interface command from a command prompt. The output of this command will show what channel the client is on, so I could tell what AP it was connected to.

With 11v BSS Transition Management

Once the client reaches a point where the optimized roaming engine determines it should roam, a transition management request is sent to it.

Figure 2: Transition Management 

You can see in figure two that the client sends probes prior to sending the transition management response. I guess it wanted to confirm that there was an AP on the channel indicated in the transition request frame. Looking at the time stamps, it took about 50ms for the client to re-associate to another AP.

To be honest here, it looks like the client was not happy with the SNR it was seeing from the new AP. There are probe requests/responses on channel 64, which was the channel of the "Back" AP it had been associated to. This could explain why the roam took 50ms.

Without 11v BSS Transition Management 

In this test, my client was line of sight to the "Front" AP when the optimized roaming engine sent a disassociate frame.

Figure 3: Abrupt Disassociation

You can see from figure 3 that it took 800ms for the client to realize what had happened and send out probe requests, then another 90ms to get connected. Total time from disassociation to re-association response is nearly 900ms. Luckily, it was able to re-associate without having to do a complete EAP authentication cycle, otherwise the roam would have taking about a full second.

Conclusion

While 900ms may be a tolerable roam time for a data client, it is too long for voice applications. Even if you only have data clients, sticky clients ruin the party for other clients by using low data rates and consuming more air time. If you are going to use Optimized Roaming, 11v BSS Transition Management offers a way to gracefully move sticky clients to a better AP.

Comments? Suggestions? Please leave a comment below or reach me on Twitter @GiantsNerd.