Does 802.11k/v/r work with APs individually configured? Or different vendors?

[mlai]

Hello gurus! I am wondering if 802.11k/v/r works with consumer/pro-summer grade APs (Netgears/Asus) configured independently via a wired network? Or do they only work in their respective Mesh or repeater configs?

For instance, I have a pair of Asus Zenwifi XT8 and they can act as APs or in AiMesh and they support 802.11k/v in mesh configs. I am ignoring the restrictive AiMesh and setup them up as individual APs connecting to 10G wired backbones. In such configuration, do the APs 802.11k/v still work? How do they know which APs should be on the roaming list provided to the clients?

Before someone said ask/post in the Asus forums..... I also have Netgear EAX80 and TPLink Archer AX6000, and wondering if mixing them into my network (connecting via wired ethernet), will the different vendors APs be able to work and provide 802.11k/v (r is a tall order......) for the clients to roam?

Basically, even if an individual AP supports 802.11k/v/r, if it is setup individually and not controller based (eg Unifi), is there any possibility of 802.11k/v/r working to assist in client roaming?

 

[thiggins]

Implementations of 802.11k,v and r vary widely. Part of this is that, like all 802.11 specs, there is a lot of room for interpretation. 11k and v also have many modes and not all are implemented in all products.

The advantage "mesh" systems have is that all nodes will have the same 11k/v/r support. But the same would apply for routers or APs of the same make/model and firmware revision.

These standards do not require a central controller to work.

But they won't work magic because devices still have the most control in the roaming process.

For more info on roaming, see the "Roaming Secrets" series starting here: https://www.smallnetbuilder.com/wireless/wireless-features/33195-wi-fi-roaming-secrets-revealed

 

[coxhaus]

The Cisco small business WAP581 wireless APs do fast roaming . I don't run a radius server. But Cisco's roaming works well without it. These are really good wireless APs. I don't understand why more poeople don't buy them. You can not mix and match wireless APs as the controller software is built-in to the APs which is self healing if you lose an AP in a virtual setup. Here is the help screen.

Fast Roaming
Fast roaming, also known as IEEE 802.11r or Fast BSS Transition (FT), allows a client device to roam quickly in environments implementing the WPA2 Enterprise security, by ensuring that the client device does not need to re-authenticate to the RADIUS server every time it roams from one access point to another.

Fast transition roaming is an amendment to the IEEE 802.11 standard that permits continuous connectivity aboard wireless devices in motion, with fast and secure handoffs from an AP to another managed AP in a seamless manner. In order to ensure voice quality and network security, a portable station must be able to maintain a secure, low-latency voice call while roaming between APs that are handling other traffic.

This device supports the FBT (Fast BSS Transition) as defined in 802.11r for fast handoff with WPA2 Enterprise security. For Voice over WI-FI Enterprise, only a subset of the features defined in 802.11r are supported. The fast BSS transition decreases latency during roaming.

FBT is enabled per VAP per radio.

Note
Before you configure FBT on a VAP, be sure to verify that the VAP is configured with WPA2 security, pre-authentication disabled and MFP disabled.

 

[Trip]

@mlai - First off, not to beat a dead horse, but it's usually the client, and all its limitations and/or lack of intelligence on its own, that will typically govern the lion's share of the roam event. That said, and as Tim highlighted, 802.11r, k and v are implemented to a widely varying degree across products. Consumer gear tends to range from non-existent or poor (ex: most cheap and/or standalone AIOs/APs) to adequate (example: Eero), small-business usually decent or better (UniFi, Omada, Cisco WAP), and enterprise usually complete implementations with the most amount control plane intelligence and roam crafting ability (Aironet, Aruba, Ruckus, etc.).

For the XT8 in particular, it lacks .11r (fast-transition, pre-auth), which means that while neighbor lists (.11k) and traffic load (.11v) info may be able to be shared and help influence roaming decisions (with clients that actually support those amendments), the actual APs themselves won't be able to pre-authenticate and fast-transition those clients, so any shot at truly seamless packet flow is more or less lost. Whether that's important to you or not, is up to you to decide, and/or to account for in your client population, that may (or may not?) support .11r (a fair amount these days should).

Regarding mixing APs with varying amounts of roaming amendment support and/or lack of a unified control plane (ie. controller), you can certainly give it a shot. As Tim said, .11r/k/v are usable without that central "brain". That said, controller-based WLANs should be able to elicit better roaming behavior more often than not -- again, provided the clients in-use are .11r/k/v capable. This is due to controller-based product being able to gather, analyze and transmit behavioral intelligence to all APs, on which clients to attempt to roam to which AP, and when, as well as (in certain products, usually enterprise) being able to extensively coordinate traffic flow so that packets don't just vaporize in-transit during the roam.

So, yeah, you're free to use whatever you want, but at the end of the day, you need modern, amendment-compliant and properly implemented clients and APs, plus proper WLAN topology design and config, to make .11r, k and v truly pay off for you.

Hope that helps answer your questions to completion.

 

[mlai]

Thanks for all. I actually did the reverse and had moved from a completely unifi based installation to the Linksys velop and believe it or not, had better roaming performance for my clients (Samsung S10/S20, iPhones XR and 11, MacBook Pro 2018 and MacBook Air 2020, Surface Pro 7 etc). Same clients switch APs faster and without drop with Velop where they used to stutter with Unifi AC Pros.

I understand that 802.11r is supposed to speed up WPA2-ENT but oddly, I see in certain vendors marketing materials that it now also works with PSK. Maybe something new that I am not aware of.

But the jist of the post is that I do have basic ideas on how 802.11kvr works theoretically. But in terms of individuals APs, how can they be aware of what constitutes as a preferred list of APs to roam? For instance, if both XT8s or low and behold, the Archer AX6000 and Netgear EAX80 are connected to the same Ethernet backbone individually as APs, how they they be aware of each other thus building a list of preferred APs and providing to clients to speed up the clients' AP selection? (802.11k). And how can they know other APs have lower loads and ask the clients to roam to a different AP albeit with weaker signal (802.11v)?

I mean even if the APs support the 802.11kvr standards, how do the different APs (not in a mesh or repeater configuration) and without a central controller able to provide 802.11k/v? Because to me, to provide 802.11k/v, the APs will have to be aware of what APs are considered to be in the same network, thus preferred, and that I presume, that the APs really have to be aware of each other? If the APs are set as individual APs, how will this work?

And are the claims by certain vendors that 802.11r works with PSK now a whole bunch of BS, or are there something new and magical that I missed in 802.11r specs?

 

[thiggins]

11k and v messages are sent in management Action frames, so are available to all APs and STAs that choose to listen. They do not depend on a controller to forward them.

Yes, there is a version of 11r that supports PSK. But it may not be implemented in a particular AP or STA.

11v BSS Transition Management Requests are the main mechanism for "suggesting" that STAs roam. More forceful methods are deauthentication and disassociation frames. But sticky STAs will either ignore those, or connect right back again.

 

[coxhaus]

Seems like to me you still need controller software, be it external or internal which dictates not being able to mix brands regardless of standards. Clients have the final say but it is the controller software that runs the system. I would think the controller software is written for particular hardware which would exclude other hardware. How would you know when the master controller goes down and to automatically promote another? Then be able to reverse the process when the master controller comes back online. Hardware specific.

In my small scale setup Wi-Fi calling is the hardest thing for me to get roaming to work correctly and not drop part of a sentence. And I am not sure how many it could stand at the same time but again I am working at small scale not enterprise level.

 

[JohnB_123]

Seems like to me you still need controller software, be it external or internal which dictates not being able to mix brands regardless of standards. Clients have the final say but it is the controller software that runs the system. I would think the controller software is written for particular hardware which would exclude other hardware. How would you know when the master controller goes down and to automatically promote another? Then be able to reverse the process when the master controller comes back online. Hardware specific.

In my small scale setup Wi-Fi calling is the hardest thing for me to get roaming to work correctly and not drop part of a sentence. And I am not sure how many it could stand at the same time but again I am working at small scale not enterprise level.

The only way I have gotten Wi-Fi calling to work well when roaming nodes is by using dumb wired backhaul APs with the same SSID (in the case I'm referring to, using Asus RT-AC86u AP and router). Always had some issue with AIMesh, Orbi, Ubiquiti, Velop, etc etc. - as soon as it transferred stations, either the stream dropped or it transferred to cellular.

 

[coxhaus]

I have to say I am using dumb wired backhaul Cisco APs. But I like to be able to walk around when I am talking on the phone. I don't want any APs that don't work with Wi-Fi calling and roaming. LTE is not an option for me as it does not work well in my older home. LTE works fine outside.

 

[JohnB_123]

I have to say I am using dumb wired backhaul Cisco APs. But I like to be able to walk around when I am talking on the phone. I don't want any APs that don't work with Wi-Fi calling and roaming. LTE is not an option for me as it does not work well in my older home. LTE works fine outside.

Totally get it. The handoff works well in the circumstances I described with iPhone X and 11 phones on wifi calling using dumb Asus APs. The client rarely drops at all when roaming between APs.

 

[coxhaus]

Totally get it. The handoff works well in the circumstances I described with iPhone X and 11 phones on wifi calling using dumb Asus APs. The client rarely drops at all when roaming between APs.

To me it is not so much dropping calls as do you lose parts of a sentence when talking and roaming. My older Cisco APs never dropped but you would lose part of a sentence when you roamed. With my newer Cisco WAP581 I don't have that issue. But I never have dropped calls with either of the Cisco APs.

 

[coxhaus]

Is 802.11r important at this level? How many home users or small business users are going to all the trouble to setup a Radius server and use it and manage it? It seems like work to me.

 

[Ola Malmstrom]

Interesting thread. I have an AX88U router at the center. Then one AX87U, one AX66U and one old N56U connected as wired APs. Roaming works well between all four systems.

My wife uses Facetime all the time while walking around the house. She would sure let me know if it didn't work for her....

I have considered replacing the AX87U and the N56U with mesh-compliant APs. However after having read this and a number of related threads / articles, I can't really see any point to do so. I can chose the channels I want on each AP. I have switched off the 2.4 GHz band in two of the APs and entered a few stationary client AP addresses in the Wireless Mac Filter as rejected in all systems. I have also reduced the transmit power in two of the APs. I have very good control of the roaming behavior in a way I wouldn't have in a mesh system (at least not in the Google or Asus mesh versions).

However I have switched off the Smart Connect on the AX88U - can't see how it would benefit me.

 

[coxhaus]

What seems to be more difficult in roaming for me is not FaceTime but WI-FI calling. I always seem to walk around while talking on the iPhone if nothing else to go look at something or go in another room while I am talking.

 

[Ola Malmstrom]

Yes, but FaceTime is through WiFi!

 

[coxhaus]

I understand but FaceTime is more tolerant than voice over Wi-Fi from my experience.

 

[Ola Malmstrom]

Maybe so, but I am constantly roaming with other devices / apps. Android phones, iphones, PCs attached to my employers VPN. Whatsapp voice, Whatsapp video, other applications. They all roam seamlessly. Without mesh........

 

[Trip]

What seems to be more difficult in roaming for me is not FaceTime but WI-FI calling.

Carrier-grade VoWifi requires ePDG mapping and ability to identify and flow-prioritize the IPSec tunnel between the UE (iPhone) and ePDG. Cisco small biz gear simply lacks the capability; you'd need to step up to a true enterprise-grade product the like Ruckus (Unleashed, ZD or vSZ), Cisco Catalyst or Aruba for proper VoWifi support.

 

[coxhaus]

Carrier-grade VoWifi requires ePDG mapping and ability to identify and flow-prioritize the IPSec tunnel between the UE (iPhone) and ePDG. Cisco small biz gear simply lacks the capability; you'd need to step up to a true enterprise-grade product the like Ruckus (Unleashed, ZD or vSZ), Cisco Catalyst or Aruba for proper VoWifi support.

I think Cisco has added some support for voice over Wi-Fi in their small business APs. There is a priority setting in the new Cisco CBW240ac wireless APs for voice traffic. I think I saw a taste of it in the Cisco WAP581 wireless APs. I am sure it is not enterprise grade but it is a level above the consumer gear. I don't think consumer gear can handle it at all. So, I think you are wrong Trip.

I have been using voice over Wi-Fi for a couple of years since it was supported in the iPhones. I do not have dropped calls and I am sure we are pushing on the 10 mbps upload I have at times. I have 3 people doing Wi-Fi calling every day. My granddaughter does Zoom school and talks with her girlfriends all using her iPhone at the same time.

PS
I forgot about my daughter's small business. I had everybody setup on voice over Wi-Fi calling to save minutes on their phones. I also had 19 IP phones setup at the same time. People are either on their IP phone or on their cell most of time as they were a real estate office. The only issue was with T-Mobile which I think was as much as the user as it was T-Mobile. AT&T and Sprint worked fine. I did not need to tunnel anything as it was a small network, only a couple of switches. I prioritized all the IP phone traffic using the Cisco L3 switch and the built-in Cisco macros for IP phones.

 

[Trip]

DSCP and 802.1p is definitely there on the Cisco small biz stuff (as it is on most SMB gear) and often that alone provides acceptable-enough egressing QoS. Being able to actually flow-prioritize the entire ePDG tunnel, though, adds extra assurance of real-time data flow quality. VoWifi exchange is fairly complex (here's a decent overview article).

Regarding the T-Mobile issue, if you had ePDG hard-coding and prioritization ability at the AP level, you could specify the server address (TMobile's is ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org) to aid in faster resolution and tunnel establishment for T-Mobile clients, as well as better behavior while roaming APs. That said, there might have been a device and/or upstream issue preventing any of that from helping, but that's the kind of thing that would be possible to at least try with slightly higher level gear.

With this stuff as with anything, I'm less concerned with who's right or wrong, and more interested shedding light on things together to see what really works or really doesn't in the real world. It's encouraging to see the SMB Cisco stuff doing well enough, at least anecdotally. Certainly is a compelling alternative to super-spendy enterprise kit, so that's a good data point to me.