Controller Based WLANs

Why client match is not working well on some users

Environment : Few users complaining of disconnects randomly. the users up in Airwave and show low health and very low SNR. For some reasons the users are not being handed off between APs. Mostly Ap's are 105 model.

 

The users are  on Windows systems 8 and 8.1.PMKID turned off on the clients. What do you suppose would make clients behave this way? 

 

First we need to look at clientmatch events in Airwave to see if they correspond with user complaints.

 

rtaImage (1).jpg

 

A lot of sticky client events and that could be because the power on your access points are too high.  first backup  flash and then try setting the ARM min and ARM max to 12 and 18 respectively.  That way, clients will not hang onto APs longer than they should.

How adjusting the power and updating client drivers help?

The issue with running your indoor APs at such a high power is that, while it makes the coverage 'look' good (since there's RF blasted everywhere and so all the client devices report super great signal), the clients themselves do not have the same power and antenna gain to support 'reach back' at the same level. So take an AP at 23dBm and a client at 17dBm (which is actually higher than most devices like phones and tablets), that is at least a 6dB difference in the link budget. That means the AP has at least 4 times the power output of the client.

What occurs next is the client says 'hey I think I have great signal, I am going to stay with this AP and ask to negotiate a high data rate'. Except when this happens, it doesn't actually work that way. The client may try to run at MCS15 (as an extreme example), but in reality, the client is too far away such that the smaller power output of the client can't really 'push' MCS15 back to the AP. The result is the transmit fails and the client falls back on slower rates until it gets an ACK back from the AP. Carrying it further, if a client is a long distance away from the AP, while the 23dB power output may be enough to get the frames to the client, the 17dB client is not powerful enough to send a frame back. A such, the client keeps re-transmitting without ever getting an ACK, and may chose not to want to roam because it thinks it has great signal from it's associated AP.

 

In short, everything works best indoors when the AP power output (in general) matches the client power output you are supporting. 25-50mW is pretty much the range of client device power output for most consumer WiFi devices (small phones to laptops, respectively). If all your laptops have a 100mW radio with a 3dB antenna then we can run your APs wide open.

 

So the controller and APs have some mechanisms to help address these conditions, like Client-Match, probe-response thresholds, etc which are great tools to have, but maxing the power ouput of all the APs means the system can't work as well because it creates the above issues (and others like more broad ACI/CCI which raises the noise floor and decreases Rx sensitivity across the board, etc). So better to set ARM to use a more manageable range of power that is commisurate with the device types you are looking to support, so that the 'system' starts off 'healthy' in the first place.

Version History
Revision #:
1 of 1
Last update:
‎04-08-2015 06:35 AM
Updated by:
 
Labels (1)
Contributors
Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.