Updated 8/24/18: Added explanation for lack of band steering
It's been a slow summer for Wi-Fi product introductions. So before the draft 11ax router dam breaks in the fall, I've been spending a lot of time thinking about how to put together the next Wi-Fi testbed and exploring new test methods. A lot of that time recently has been focused on Wi-Fi roaming.
The Wi-Fi Roaming Secrets series was a good start at understanding what makes Wi-Fi roaming tick. But it didn't explore how a client device supporting all three roaming enhancement standards, 802.11k, v and r, behaved, because I couldn't find such a device.
The studies were also hindered by the time it took to manually analyze device telemetry logs and Wireshark capture files and construct roaming behavior plots like the one below.
This roaming plot takes a lot of time to put together
Fortunately, two significant developments have significantly improved my ability to assess Wi-Fi roaming behavior. The first is the development of a web-based roaming analysis tool by my test partner, octoScope. The tool takes any uploaded pcap file, automatically analyzes it for key roaming events and generates an RSSI vs. time plot along with a table of detected roaming events.
octoScope Wi-Fi roaming analysis tool
The example plot shown above also places markers (blue dots) corresponding to each detected roaming event on the plot. In the actual tool, mousing over each plotted point—RSSI or roaming event—pops up relevant information. The screenshot above shows the "tooltip" information for one of the RSSI points. The color of the RSSI plot indicates the band (green for 2.4 GHz, red for 5 GHz) for easier identification of band steering events.
Since the plot also extracts RSSI information from the captures, I no longer need to get that information from the STA. So there is no need to run a client-side app to gather the data for readback. Traffic can still be run while testing using either ping or iperf3, since iperf3 apps are available for Windows, iOS, MacOS and Android and ping is built into all modern OSes.
The other roaming test improvement is that I've found a device, actually a bunch of them, that support all three roaming assistance standards. The key to this discovery was understanding the fact that many devices (STA) don't advertise 11r support unless they talk to an access point (AP) that also supports it.
The mesh consumer systems I've tested until recently don't support 11r because it can cause connection problems with older clients. But TP-Link decided 11r support was important and it can be optionally enabled in the second-generation Deco M9 Plus system I recently reviewed.
Once I enabled 11r in the Deco M9 Plus (and confirmed it was at least advertised as supported), I retested my stable of clients and came up with the following results shown in the table below.
Table 1: Device 802.11k/v/r support
iOS devices appear to be the winner here. I was even surprised to see 11r supported in the older iPod Touch G5 and iOS 9.3.5. But the Intel AC 8260 still apparently doesn't support 802.11r, contrary to what Intel and Microsoft say.
Here's the Wireshark filter used to look for Authentication, Association and Reassociation frames with RSN Auth Key Management (AKM) Type 4 set...
(wlan.fc.type_subtype == 0x0000 || wlan.fc.type_subtype == 0x000b || wlan.fc.type_subtype == 0x0002)&& wlan.rsn.akms.type == 4
...and the Wireshark capture showing the STA advertising 11r support.
The telltale 11r STA frame
Now that I have an 11k/v/r capable device, I configured the testbed to use it instead of the octoScope Pal, which supports only 802.11v BSS Transition Management Requests. I chose the more recent iPodTouch Gen 6 as the test client. Here's what it looks like set up in the large octoScope test chamber. Please excuse the elegant test stand. Two octoScope high gain antennas are used to couple the STA into the testbed.
Roaming test setup with device STA
Here's the block diagram of the setup. The ipod Touch sits in parallel with the Pal-24 and Pal-5 that are used for frame capture.