Wi-Fi Roaming Secrets Revealed

[thiggins]

Ever wonder what happens behind the scenes when Wi-Fi devices roam, or more likely don't? We'll show you why the "seamless" roaming Wi-Fi gear makers promise is still as elusive as a Yeti.

Read on SmallNetBuilder

 

[SwampKracker]

Ever wonder what happens behind the scenes when Wi-Fi devices roam, or more likely don't? We'll show you why the "seamless" roaming Wi-Fi gear makers promise is still as elusive as a Yeti.

Read on SmallNetBuilder

Chipping away at the marketing hype...

Thanks, Tim.

 

[CrystalLattice]

Looks like you may have found that the infrastructure’s radio resource management plays a huge role in the process of STA to AP roaming.

 

[Razor512]

Is it possible to somehow force a client to a different AP in a way that is transparent or barely noticeable to the client?

For example, implement some way for the APs to share data relating to the connection state of each client, and then arrange a hand off where 1 PS tells the other, that a specific client is closer to me than it is to you, so send me the data relating to the connection, and i will handle the next frame that the client sends.

Usually with most client devices, a complete loss of connectivity for a few milliseconds, will not cause the client to lose the connection, thus they have some method of maintaining of being able to resume a previous connection.

If there were some kind of brute force method of having access points being able to forcibly move a client to a different AP without it having to go through the entire association process again.

In testing a wide range of smartphones, it is a real mixed bag in terms of how roaming is handled, and it doesn't seem like device makers are really interested in putting much attention towards roaming, thus it seems best for router makers to come up with some workaround.

 

[sfx2000]

Ever wonder what happens behind the scenes when Wi-Fi devices roam, or more likely don't? We'll show you why the "seamless" roaming Wi-Fi gear makers promise is still as elusive as a Yeti.

Good article - can appreciate the level of effort to get this one done.

 

[Easy Rhino]

Impressive article. I don't think I fully grasp what I should be grasping, but impressive.

Dumb tangential question: should the 802.11 k,v,r tweaks be interopable between vendors? (i.e. a true standard).
In other words, if you had orbis and velops intermingled, should those features still work and be useful?

 

[coxhaus]

I like the article. I did not understand band-steering. Are you considering band-steering the same as roaming? So your roaming is 2.4GHz to 2.4GHz to 5GHz. Is this right?

I guess if you are using band-steering the APs are spaced for 2.4GHz for roaming? If you walk fast does the roaming change twice with band-steering once to 2.4GHz and then to 5GHz as you change APs?

I found it much easier to only use 5GHz for spacing APs. It takes more APs though. I am interested in 2.4GHz if I can make it work the way I want.

 

[thiggins]

Impressive article. I don't think I fully grasp what I should be grasping, but impressive.

I'm sorry for that. What part(s) did you not understand so I can update the article or address it in the follow on? I'm really trying to demystify this topic because there is so much vendor hype/misinformation.

Dumb tangential question: should the 802.11 k,v,r tweaks be interopable between vendors? (i.e. a true standard).
In other words, if you had orbis and velops intermingled, should those features still work and be useful?

These "standards" leave a lot of room for interpretation and have many optional parts..

So just as all "11ac" products do not operate the same way, seeing 11k,v or r support specified does not mean a product will operate the same way. It is still early days for 11k/v/r, so it's best to stick with one vendor.

Once and if products go for Wi-Fi Agile Multiband certification, interoperability should improve. But the devil is in the details and that certification still has many optional sub-certifications.

 

[thiggins]

I like the article. I did not understand band-steering. Are you considering band-steering the same as roaming? So your roaming is 2.4GHz to 2.4GHz to 5GHz. Is this right?

I guess if you are using band-steering the APs are spaced for 2.4GHz for roaming? If you walk fast does the roaming change twice with band-steering once to 2.4GHz and then to 5GHz as you change APs?

I found it much easier to only use 5GHz for spacing APs. It takes more APs though. I am interested in 2.4GHz if I can make it work the way I want.

Roaming means a STA changes from one radio (BSSID) to another. That new radio can be in the same band or a different one.

In the roams in the article, it appeared that Orbi is using the 11v BSS Transition Management requests to band steer, i.e. move a STA from one band to another, because the BSSID in the report was in a different band than the STA was currently connected to.

You are correct that the difference between 2.4 and 5 GHz signal strengths complicates things if you are trying to control your RSSI overlaps. That is why enterprise APs provide better power controls and in some cases use Radio Resource Management to automatically tweak power levels to maintain proper overlap.

Such controls do not exist in "smart" consumer Wi-Fi stuff. Your solution, disabling 2.4 GHz, is one way to go. Or you could still keep the 2.4 GHz radios on, but assign a different SSID and encryption key, which is used only for specific devices (IP cams, smart speakers, etc.)

A roaming STA would still see the 2.4 GHz radios when it probes/scans. But they would not be a roam candidate because they're in a different SSID, which the STA does not have credentials for.

 

[Sineira]

Thanks, this is great!

 

[adamjb]

Ruckus is the one vendor I've dealt with that has something that actually seems to approach seamless roaming with their controller working some kind of magic. Not something that most can afford in their home, with $500+ APs and a $1000+ controller, but I'd be really interested in you guys testing Ruckus' roaming. Their roaming and beam-forming technology have always amazed me, and are why they're my favorite Wifi vendor.

 

[thiggins]

Ruckus is the one vendor I've dealt with that has something that actually seems to approach seamless roaming with their controller working some kind of magic. Not something that most can afford in their home, with $500+ APs and a $1000+ controller, but I'd be really interested in you guys testing Ruckus' roaming. Their roaming and beam-forming technology have always amazed me, and are why they're my favorite Wifi vendor.

Ruckus is not interested in the consumer Wi-Fi market. We don't really cover Enterprise products.

None of these companies have "magic" when it comes to roaming. Good roaming performance requires proper RF management (proper AP overlap), which can be the most effective factor.

What impresses you most about Ruckus' roaming? What are you comparing to?

 

[Razor512]

I'm working in areas with both ruckus and cisco APs, the roaming behavior seems similar with my smartphone.

What has been weird for me is that the roaming behavior for many smartphones seems to be based on software and not on the WiFi chipset.
Currently have 6 different smartphone models with the same model of WiFi radio, running the same version of android. Each phone behaves differently with roaming from 1 AP to another.

It is just frustrating that the companies making the access points can't find a more brute force method of taking some of that roaming control away from the client devices, and making for faster roaming behavior.

 

[coxhaus]

None of these companies have "magic" when it comes to roaming. Good roaming performance requires proper RF management (proper AP overlap), which can be the most effective factor.

I think proper AP overlap is key for roaming. I spent a lot of time adjusting my 3 Cisco APs getting them in the best balance for my home. Then I recently upgraded to Cisco APs with AC and I adjusted a little more by a few feet.

 

[thiggins]

I'm working in areas with both ruckus and cisco APs, the roaming behavior seems similar with my smartphone.

What has been weird for me is that the roaming behavior for many smartphones seems to be based on software and not on the WiFi chipset.
Currently have 6 different smartphone models with the same model of WiFi radio, running the same version of android. Each phone behaves differently with roaming from 1 AP to another.

It is just frustrating that the companies making the access points can't find a more brute force method of taking some of that roaming control away from the client devices, and making for faster roaming behavior.

You really should read up on how Wi-Fi works. Your posts frequently wish for things that are just not possible within the standard. I recommend Matt Gast's 802.11 Wireless Networks: The Definitive Guide.

Android does not determine roaming behavior, nor does Wi-Fi chipset. The behavior is parameters embedded in the Wi-Fi driver, which each vendor can adjust.

 

[Razor512]

I understand that what I was asking about is not possible within the standard, I was mainly wondering if they could break/ deviate from those standards in a way that can still maintain compatibility.

In many other parts of the electronics industry device makers will deviate from standards in order to offer more value to the customers.

 

[basix]

Hi all, new on this forum but reading for years this website. Just my 2 cents, I am running for years at multiple homes and a hotel with Aruba Instant networks. Most with IAP-103 and IAP-105 accespoints. They support band steering, ARM, 802.11k+V+R and a lot off other Enterprise features for a much lower price. Maybe u can do a review of it also.

 

[thiggins]

I am running for years at multiple homes and a hotel with Aruba Instant networks.

Thanks for your report. Aruba is definitely enterprise grade, which we don't review.

 

[5nolly6oster]

Is it possible to somehow force a client to a different AP in a way that is transparent or barely noticeable to the client?

For example, implement some way for the APs to share data relating to the connection state of each client, and then arrange a hand off where 1 PS tells the other, that a specific client is closer to me than it is to you, so send me the data relating to the connection, and i will handle the next frame that the client sends.

Usually with most client devices, a complete loss of connectivity for a few milliseconds, will not cause the client to lose the connection, thus they have some method of maintaining of being able to resume a previous connection.

If there were some kind of brute force method of having access points being able to forcibly move a client to a different AP without it having to go through the entire association process again.

In testing a wide range of smartphones, it is a real mixed bag in terms of how roaming is handled, and it doesn't seem like device makers are really interested in putting much attention towards roaming, thus it seems best for router makers to come up with some workaround.

isnt that what meshs do

 

[thiggins]

isnt that what meshs do

Not all "mesh" or multi-AP systems behave the same, nor do all clients. If the client device does not support 11k,v, or r roaming assistance, the only tools an AP has to control client connection are to refuse or delay replies to association requests, deauthorization and deauthentication. These are brute force tools that don't always have the desired effect.