Part 1 of this series looked at how a device with known roaming behavior worked with a NETGEAR Orbi router and satellite. Since the octoScope Pal device supports 802.11v BSS Transition Management Requests, we got to see how that feature was used in band steering the Pal.
Before we move on to look at the roaming behavior of a Windows and Android STA, I thought we would take a short detour to look at how to tell whether devices support 802.11k, v and r. From my time working with an assortment of devices in preparing this series, I've found the indications are not always obvious. I've also found that even when support is indicated, the actual function might be improperly or incompletely implemented.
To recap, the Windows STA is a Lenovo M600 computer running Windows 10 Pro 64 bit with an Intel Wireless-AC 8260 internal adapter with latest 18.104.22.168 driver. I chose this adapter because Intel says the AC-8260 supports 802.11k,v and r and Microsoft says Windows 10 supports 802.11k,v and r (depending on device driver support, of course).
The Samsung Galaxy Tab A 8" (2017 version - SM-T380) was chosen because it was found to support 802.11k and v by packet inspection, even though neither is specified.
The Wireshark capture files used came from an octoScope Pal-24 (2.4 GHz) and octoScope Pal-5 tuned to the two channels in use (6 and 40). The files were merged before analysis.
How To Tell - 802.11k
802.11k is the IEEE Radio Resource Management standard. Its focus is on making the roaming process more efficient by reducing the need for a STA to probe (scan) for information about possible APs to roam to. The summary below from an excellent 7Signal whitepaper outlines key 802.11k features. (You can also see Veli-Pekka Ketonen from 7Signal deliver the presentation in this video.)
802.11k Radio Resource Management
We can start by filtering for STA Association wlan.fc.type_subtype ==0 or Reassociation Requests wlan.fc.type_subtype ==2, looking for Radio Management Capabilities Beacon Passive wlan.rmcap.b4 == 1 and Beacon Active Measurement wlan.rmcap.b5 == 1 fields enabled. The entire Wireshark filter is:
((wlan.fc.type_subtype ==0)||(wlan.fc.type_subtype ==2)) && (wlan.rmcap.b4 == 1 || wlan.rmcap.b5 == 1).
If we drop the STA Association Request part of the filter, however, we see Orbi advertising its 11k support in Beacon's and Probe responses, as shown in the Wireshark detail below.
11k support indicators
Another thing we can look for as an indication of 11k support is a STA actually issuing a Neighbor Report request wlan.rm.action_code == 4. The capture below shows the Intel STA issuing a request twice. But the Orbi's response is not very helpful, with no neighbor information supplied.
11k Neighbor Report Request & Response
We can also look for a Neighbor Report itself by applying a wlan.tag.number == 52 filter. The screenshot below shows Orbi providing a Neighbor Report in the same frame that it issues a BSS Transition Management Request. There is only one BSSID in the report, which is the 5 GHz radio of the same AP, 08:02:8e:9f:39:c8.
11k Neighbor Report
802.11k also supports Measurement Requests, found using a wlan.rm.action_code == 0 filter. The screenshot below shows Orbi issuing a Beacon request. A more specific filter would be wlan.tag.number == 38, found under Tagged Parameters.
11k Radio Measurement Request
If we go looking for a Measurement Report by filtering for wlan.tag.number == 39, however, we don't find one in this capture, or any others for the Intel STA. But looking at a capture using the Samsung Tab STA, shows two responses. However, the report details says no measurement was actually made as indicated by measurement duration: 0x0000 and all the other zero values. This is an example of a feature that appears to be supported, but actually isn't because no actionable information is provided.
11k Radio Measurement Report
If you still haven't had enough fun with 11k hunting, you can check out this video by Mark Williams that has more examples with commentary.