Recently, I posted about the differences between 802.11k and 802.11v. However, I left some questions unanswered. Both amendments help roaming, but many engineers feel 802.11v is noticeably more disruptive. In fact, I've had to turn it off with certain clients. Yet, it remains on by default for AP vendors such as Cisco Meraki (1) and Juniper Mist (2). What gives then? Should you use it or not?
Starting with the basics - The 802.11v Amendment
Assisted roaming happens with one of three frames(2, section 11.22.6):
BSS Transition Management Query
BSS Transition Management Request
BSS Transition Management Response
The BSS-TM Query allows clients to tell the AP their preferred target APs for roaming. Clients leverage the neighbor reports from 802.11k for the RF information about AP STAs in their proximity. Within the Query, the preference field allows clients to indicate their most preferred AP with a number between 1 and 255, where 255 is the most preferred AP.
Next, AP should respond with a BSS-TM Request. It can also send these Requests unsolicited to clients. The Requests also include the client's preferred AP list when sent after the client's Query. The AP should include at least "[...]one BSS candidate from that list with a non-zero Preference field value in the BSS Transition Candidate List[...]". A zero preference value means the BSS should be excluded. Essentially, the AP must suggest one AP nearby the client can roam to. In difficult RF environments, this sounds less than ideal, but I have not tested this myself. The AP then can indicate the "Disassociation Imminent" value set to 1 with an optional timer field to set to the number of beacon intervals before client disassociation.
Once the client receives this BSS-TM Request with an imminent disassociation, it may either accept, reject, or reject it with a delay. If the client receives a BSS-TM Request with an imminent disassociation and no preferred roaming candidate, it gets some more reject options, but I am unsure how this plays out if there must be at least one transition candidate. Topically, the standard doesn't seem too flawed as it gives opportunity for clients to reject the roams. If anything the standard doesn't specifically describe limitations on number of attempted roams, for example. As a result, the practical implementation requires major work on behalf of the client chipset to account for undesired roaming suggestions from the AP. It also requires effort on the vendor's part to account for when clients do not behave as expected which to leads to the next factor in assisted roaming.
Client Implementation
If there was a contest for client behavior documentation, Apple wins every time. They go as far to list the exact roaming thresholds for every client and which ones use 802.11v (4). Shout out to Keith Parsons for collecting this and other standard documents in one place here.
Unfortunately, most client devices may not even indicate if they support 802.11v. To get around this, you can view an OTA capture and look for the "BSS Transition" Value (Extended Capabilities tag, Octet 3) in probe requests, association requests and re-association requests. This will look the same as looking for AP support with Beacon frames:
However, as vendors have come to figure out, clients do not always include these values consistently in all these frames. I sympathize with device manufacturers that getting this information isn't easy especially when it requires back and forth with the wireless card manufacturer. However, if the wireless card becomes legacy, it may be the only opportunity for customers to understand it's behavior.
Vendor Implementation
Despite the mechanisms outlined in 802.11v, the amendment leaves much of the specific implementation up to vendors. For example, Meraki (1) changes the AP behavior in MR29.x+ to the following:
Load balancing attempts are limited to two
When checking 802.11v client abilities, the AP looks at association, and re-association requests in addition to probe requests.
802.11v client capabilities are re-sent over the LAN to other APs
Other vendors may have similar measures, but they may not publicly document them. This forces customers to engage with support for complex client needs. Even if they are documented, if the AP suggests roams in a disruptive manor to clients with limited configuration abilities, the only option may be to work out a solution with vendor support.
The Verdict?
So should you use 802.11v? For modern WiFi clients less than 5 years old, it's probably fine to enable and may be enabled without you realizing so. Widely used clients such as smartphones are more likely to receive a battery of 802.11v testing against multiple vendors. I struggle to describe tangible benefits outside latency-apathetic environments. If you want to see a practical analysis of 802.11k/r/v for voice-sensitive environments, please check out Andrew McHale's talk at WLPC Prague 2019 here.
If you have older clients or clients for specific verticals where wireless chipset capabilities take a backseat (looking at you healthcare and industrial), exercise extreme caution without vigorous testing against a specific AP model, firmware, and RF design. Ironically, these are the verticals where predictable roaming is most critical. My sentiment overall is both client and vendor manufacturers have too great discrepancies in how they implement 802.11v to give a flat "go or no-go" for even the same type of environment (office, industrial etc.) so I always encourage testing when possible.
Sources:
Comments