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.Impressive article. I don't think I fully grasp what I should be grasping, but impressive.
These "standards" leave a lot of room for interpretation and have many optional parts..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?
Roaming means a STA changes from one radio (BSSID) to another. That new radio can be in the same band or a different one.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.
Ruckus is not interested in the consumer Wi-Fi market. We don't really cover Enterprise products.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.
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.
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.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.
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.
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.isnt that what meshs do