The Products

I selected the following Wi-Fi systems for roaming test. Table 2 summarizes the 11kvr support specified by the manufacturers. As described in Part 2, each of these standards has many methods within it, with each method affecting roaming differently. So you don't really know unless you look at the packets what a manufacturer really means when it specs support for 11k,v or r.

Table 2: DUT 11kvr support - manufacturer spec
* = default disabled

Since I did look at the packets for each product with a device supporting all three standards—an iPod Touch - 6th Generation—I was able to construct Table 3 of observed behavior for the 11kvr functions shown.

Table 3: DUT 11kvr support - observed

I was most surprised about the total lack of 11v BSS Transition Management requests in this round of testing, especially because all products tested advertise support for 11v. I found in Part 1 that NETGEAR's Orbi reliably used these requests to try to band steer the octoScope Pal STA. This time around, even though these requests can be solicited by a STA or sent unsolicited by an AP, none were observed in any of the roams using the iPod Touch client.

The Test

I ran the same roaming test on the five mesh Wi-Fi systems. Here's the test sequence:

1. Testbed is initialized
2. Packet capture is started on 2.4 and 5 GHz channels
3. Attenuators are set to initial value
4. STA is associated to AP1
5. Continuous ping is started and logged to a file
6. “To” roam done, cross-ramping attenuators from 0 to 63 dB, 1 dB steps, 1 second step dwell time
7. 10 second post-roam pause
8. “From” roam done, same parameters as "To" roam
9. 10 second post roam pause
10. File capture stopped, saved and merged into one file and roam analysis performed
    

I ran each test at least three times using the iPod Touch G6 and at least once using an octoScope Pal-245 as STA. I used the Pal as a sanity check, since I know its roaming behavior. Although it doesn't support 11k or r, it does support 11v and reliably responds to 11v BSS Transition Management Requests, at least from NETGEAR Orbi.

The Results

For those who want to cut to the chase, here's a summary of roaming behavior.

Table 4: Results summary

A few table categories need some explanation:

• Roams: Number of successful roams. Should be 2, since we are testing a round-trip roam
• Band changes: Number of times STA changes bands. This includes non-roaming band-steering events.
• Missed pings: This is the maximum number of sequential ping misses. It provides a rough indication of roaming time. Since ping frequency is 1/second we're not looking for sub-second roaming behavior. Note the missed pings metric represents pings missed during the return roam only.
• Deauths / Disassocs: Number of deauthorizations or disassociations sent by the AP, not the STA. These are typically used to "encourage" a STA to roam.

In the sections that follow, I'll show a the result used to create the above summary, along with commentary. You'll be able to download a PDF of the roaming summary and the pcap file itself.

If you copy this Wireshark dfilter_buttons file into your Windows Users > [username] > Appdata > Roaming > Wireshark folder, you'll be able to use the filters I've created to look for roaming events. Be sure to rename the existing file before copying to save any filter buttons you may have created.

ASUS Lyra Trio

Roaming summary

[Download summary] [Download pcap]

The Lyra Trio set the radios on both nodes for Channel 6 (20 MHz B/W) and 149 (80 MHz B/W). So either could be used for backhaul. We see only the 2.4 GHz radios used in the roam and no sign of band steering attempts.

The roam plots use green to indicate 2.4 GHz and red for 5 GHz, but don't differentiate channels or BSSIDs (that's on the list for plot improvements).

Google WiFi roam

The Trio made no attempt to band steer the Apple STA to 5 GHz. If the one disassociation at the start of the run was meant to encourage the STA to move, it was ineffective because the STA ended up connecting to that BSSID.

The roaming summary above shows three sets of 11k neighbor report requests and responses at around 2, 57 and 146 seconds into the run (denoted as Type: Action frames, Category: Radio Measurement on the summary). In each case, however, the report includes only the 2.4 GHz BSSID on the non-associated mesh node. It's also not clear how or if they affect roaming because they come right after an association/reassociation event. No 11k radio measurement requests or 11v BSS Transition Management Requests are observed in any of the ASUS Lyra Trio captures.

Three pings were missed during one of the roams, putting roaming time at around 3 seconds.

Google WiFi

Roaming summary

[Download summary] [Download pcap]

Google WiFi decided to use 5 GHz Channel 149 (80 MHz B/W) for backhaul and set the root node to 2.4 GHz Channel 6 and the Hop 1 node to Channel 1. Both 2.4 GHz channels were 20 MHz wide. While this means using 2.4 GHz for backhaul is not an option, it does provide more effective bandwidth for devices by giving each node its own channel. I had to bring a third capture device online and tune it to the other 2.4 GHz channel to properly capture everything.

Google WiFi roam

The roam is once again 2.4 GHz only. No deauths or disassociations were observed. The roaming summary above shows that 11kvr doesn't really affect roams for Google WiFi. Most of the roaming events shown are authentications and association and resassociation requests and responses. The four measurement reports requests Google WiFi makes were not answered by the STA.