Wi-Fi roaming is often a tumultuous subject. The crux of the issue is, with Wi-Fi the roaming decision is left to the client.
In the recent years, there have been great strides in improving Wi-Fi roaming with the creation of standards-based roaming technologies. Cisco first pioneered fast roaming many years ago with CCKM (Cisco Centralized Key Management), which was the foundation for 802.11r. 11r which was ratified by the IEEE in 2008, allows for fast roaming, even on a secure 802.1X SSID. With 802.11r it is possible to roam without disruption during a voice or video call.
While client support of 802.11r is largely lacking in the laptop space, there is large support in the smartphone realm. Apple iOS devices have supported 11r since iOS 6 (http://support.apple.com/kb/HT5535). The recent Samsung smartphones, such as the Galaxy S4, S5, and Note 3, also support 11r.
Note: Some non-802.11r clients can react adversely when connected to an 11r WLAN. The current recommendation from Cisco is to have a separate WLAN for 802.11r clients.
802.11k is another amendment from the IEEE that helps to improve roaming. 802.11k provides a whole slew of information to the client, which allows the client to understand the RF environment and make an informed roaming decision. This information can include channel load and AP neighbor lists.
11r and 11k help, however, that does not mean the infrastructure is irrelevant in the roaming picture. With the help of a model train, we did some testing to figure out just how much impact the infrastructure could have. We compared Cisco to one of our competitors, whom we will call Vendor A.
This video summarizes the results and shows the train in action, or continue reading for more details:
Both Cisco and Vendor A were configured following the best practices outlined in the vendor’s voice deployment guide or roaming deployment guide. This included enabling 802.11r and 802.11k as well as disabling the lower data rates. An 802.1X SSID was used.
Four access points were placed around an office building, as well as an O-gauge model train set. We then put various Wi-Fi clients one at a time on a flatbed traincar and observed the roaming performance and other Wi-Fi statistics as the train – with the client in tow – moved throughout the building. The train was moving at walking pace.
Here is a map of the AP placements and the train.
- WLC: 5508 w/ AireOS 184.108.40.206
- AP: 3702i
- 11k Enabled
- 11r Enabled
- Disabled Lower Data Rates
- Followed Cisco Apple Devices Best Practices Doc
- Equivalent controller and AP with most recent software release
- 11k Enabled
- 11r Enabled
- Disabled Lower Data Rates
- Followed Roaming Design Guide
With Cisco, the roams were both consistent and predicable as the train went around the track. Vendor A was a different story. Vendor A’s radio resource management had assigned all four APs to maximum transmit power, so the client associated to the middle AP and never roamed. To help facilitate the roaming with Vendor A, we lowered the maximum transmit power in RRM to 12 dBm. In this case the client roamed, but the roams were not nearly as consistent nor as predictable as with Cisco.
This screenshot shows the implications on client performance of Vendor A with default RRM vs. Cisco. Cisco maintained consistent throughput with a low retry rate. With Vendor A, the client stuck to one AP, so the throughput is inconsistent, but more importantly there is a high retry rate, which would wreak havoc on real-time applications such as voice or video calls.
This screenshot shows the detailed statistics of when and where the client roamed. Note Vendor A’s transmit power was manually lowered for this test to help facilitate roaming. With Cisco you could pretty much predict when and where the client would roam. With Vendor A, the roams were sporadic at best and when the client did roam, the AP it roamed to was unpredictable.
While 802.11r and 802.11k were important to the roaming experience in our test and definitely worth enabling on your network, they could be defeated by a misbehaving infrastructure, as we saw with Vendor A. We found the infrastructure’s radio resource management to play a huge role in the roaming process. That should come as no surprise; because at the end of the day, RF matters.
For more on Cisco’s wireless products and solutions, visit www.cisco.com/go/wireless
Great article! But it would have been interesting to disable 802.11r and 802.11k, and measure the roaming delay, just to notice the benefit to enable those protocols.
Very interesting !!!
I performed similar tests with my little legs, but the tests were not very scientific. Tests with an automatic train are much more regular and therefore scientific
Same comment that andré and I will add that it would be interesting to know the speed of the train to see the limits of the client.
Thanks for the comments, Filipe and André. Without 11r the roam times could have been as high as a second if the client has to do a full reauth with a four-way handshake. More likely the clients would support something like PKC and the roam times would have been around 100-200 ms. Without 11k the clients would have had to spend more time off-channel scanning for an AP to roam to, resulting in degraded performance in the throughput test.
As for the speed of the train, it was walking pace, maybe about 2-3 miles an hour.
Comments are closed.