07-23-2014 09:21 PM
I have a customer who is interested in the clientmatch, and would like to understand it works.
Q. Does CM(ClientMatch) automatically select a better AP, before it releases the sticky AP ?
Q. If so, what is the time delay ? Doesn't the smartphone need a time to switch the wifi one AP to another, which may cause service delay ?
Q. What if, I have done the demo of CM, and it turned out it did not work properly, and then what do you think I missed or need to check on ?
Jino from Korea
Solved! Go to Solution.
Re: how clienmatch algorism works
07-29-2014 11:23 AM
Q1: The issue of "stickyness" is coming from the client, not the AP. The client (like the iPhone) is optimised for consumer-use which means that usually the owner doesn't have a controller-based wireless infrastructure at home and hence the iPhone tries to talk to the AP that it knows for as long as possible. If it would roam smarter, as e.g. "professional" VoWLAN phones - this whole feature wouldn't be necessary
Q2: ClientMatch knows when an AP is in a better sight of the client. The solution will then initiate a de-association from the current AP that is "too far away" or otherwise not optimal and only respond to client probes from the AP where the solution thinks the client "fits best" (e.g. the closest and least crowded AP). I personally haven't experienced any "bad time delay" when I worked with CM. I believe the short interruption of switching to "the better AP" is usually better than staying connected to a crowded AP or being on a very slow connection.
Q3: That is difficult to answer for me, there might be better people here to tell you where to start debugging. I could usually use the controller view of CM to show a better distribution of clients over the available APs and hence a better service for everybody.
My Homepage: http://dokuwiki.alu4u.com