Controllerless Networks

According to the following: community post & brief description (all I could find):

Client-aware will not change channels whien there is an "active client associated to it" unless "detecting radar or excessive noise/interference on current channel."

1. What is the threshold for determining a client 'active'?

• My guess would be: a certain bps from an associated client.

2. What is the threshold for determining 'excessive noise/interference'?

• My guess would be a certain Noise Floor (ie >-82). Based on the descriptions, CU% does not appear to be a part of client-aware's decision.

3. Is client-aware in any way platform-specific? 

1.  Don't know if there is a specific number that has been documented, but it is low.

2.  There is an "error-rate-threshold" parameter that states under what circumstances a channel will change  This trumps other ARM parameters because if we have enough interference, we should change channel regardless:  http://www.arubanetworks.com/techdocs/ArubaOS_64_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/rf_arm_profile.htm

3. It is not.

Thanks c,

1. Ok, will keep looking.

2. Good to know it's configurable. Assuming this is PER? If I'm reading that link correctly, it's 50% PER in 30 seconds (at default values). Do you know how to view this counter?

My guess would be either the following, though this appears to be total (since last reset):

show ap debug radio-stats 1 | i "CRC Error"
Rx CRC Errors 650

or...

show ap arm rf-su | b "Channel quality histor"

Channel quality history:wifi0
36:Q: 91 91 91 91 91 90 91 91 91 91 91 91 91 90 91 91 91 91 91 90 91 91 90 90
:c: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
:N: 92 92 92 92 92 91 90 91 91 90 91 90 90 91 91 91 91 90 91 91 91 90 91 91
:s: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
:U: 9 9 9 9 9 10 9 9 9 9 9 9 9 10 9 9 9 9 9 10 9 9 10 10

1. I don't remember seeing it anywhere.  In general, associated clients will keep an access point from changing channel due to ARM.

2. It is per.  The best way to view if an access point has changed channels due to noise is "show log wireless all"

Noise triggers and Radar triggers will force a  channel on an access point EVEN if client aware is enabled; noise is a critical issue, and observing radar requires that we change channels immediately based on regulatory statutes.  Client Match does not move clients due to noise or radar; the access point changes channel and that would force a move.  In general, client-match is a load balancing and band-steering mechanism and is not related to your query.

HI Colin,

Thanks for correcting me :).

My point was, when the channel having more noise then the client SNR  will drop significantly and CM will move it to the AP where the client can maintain good SNR.

Corect me if I'm going wrong some where :)

Ok, thanks guys. Let me try to summarize & keep on-topic. Let's assume we are talking about 2.4GHz or 5GHz UNII-1/UNII-3/ISM bands (removing DFS from the equation) and only a single AP (removing Client-match from the equation)

1. We don't know exact number, or bps, but it is low. As an example: if at lease one client is mereley 'Associated', ie a mobile client doing backgrond check-ins etc., client-aware will prevent channel-change unless:

2. PER is > 50% over a 30 second period (default values, configurable) OR the IAP determines the channel above the channel-quality-threshold (seems this replaced noise-threshold). channel-quality-threshold is default 70 (configurable 1-100).

If the above is correct, I'd still like to know how to verify.

More specifically; how do I show current PER? How do I show current channel-quality-threshold? 

My guess would be the following for "quality" (in this case the number is 91):

show ap arm rf-su

Channel Summary
---------------
channel retry phy-err mac-err noise util(Qual) cov-idx(Total) intf_idx(Total)
------- ----- ------- ------- ----- ---------- -------------- ---------------
36 0 0 0 91 0/0/0/0/91 0/0(0) 87/13//0/0(100)

"Show log wireless all" and "show ap arm history" are great for seeing channel change events, but after they occur.

I am debating with myself over client aware as well. I have a number of clients always connected to the SSID, and as a result the ARM doens't really do it's job on channel changing. I end up with several access points on the same floor on the same channel. At the same time we have tried disabling client aware, and it led to frequent changes and disruptive service.

I would love a schedule option on this setting.  That can be achieved I suppose with Airwave, but not all use airwave. It would make sense to ignore the client aware setting at the middle of the night when there is no/few users on the site and let the channels adjust despite constantly connected clients. Then come office hours and channel changes don't happen with clients connected.

As it is now, I have ended up with many areas having CoChannel inteference where it could have been avoided had ARM changed it unless clients was constantly connected.

John654,

You probably need your logs.tar looked at.  With regards to the 2.4ghz spectrum, there are few channels to deal with and in a dense environment, there are few channels to put APs on that are much better than before.  If your access points continue to change channels, TAC can offer options about how to make it more permissive and change channels less.  Sometimes ARM parameters needs to be tuned to the environment they are in to achieve the best results.

I have a AP225 greenfield deployment, and have implemented some of the recommendations from this guide: http://community.arubanetworks.com/t5/Validated-Reference-Design/RF-and-Roaming-Optimization-for-Aruba-802-11ac-Networks/ta-p/227716

Will test those in a small area, and see how the users experience it and if the ARM change channels to more appropriate settings. 2,4Ghz is hard I know, but it's disturbing that 3 AP that is right next to each other, have been set at channel 64 through ARM.

Is there any guide or reference on how I can check free channel index for an AP?

Think I need to clean up my enviroment a littlebit before I involve TAC :)

How many access points do you have?

What is your regulatory domain?

Please see the ARM supplement here:  http://community.arubanetworks.com/aruba/attachments/aruba/70/1204/1/ARM+Doc+Supplement.pdf

To see what an access point sees on each channel:

show ap monitor channel ap-name <name of ap>

Have  130 AP's and reg domain Norway (Equal EU I beleive). 7210 controller and 6.4.2.4 software at the moment.

Thanks for that link. Will have a look at those AP's selecting same 5ghz channels.

John

DEFINATELY need to go around and clean up the enviroment to give ARM a chance by giving it better working conditions.

Thanks for your help :)

Hi,

As per my knowledge, ARM will trigger the AP to change the channel if any of the following criteria matches,

1. The Interference Index metric on a new channel is at least “arm free-channelindex” value less than its current channel interference index value

2. The ARM noise-threshold value is reached

3. The ARM error-rate-threshold is reached

4. When a Radar is detected

5. If the AP is initially on a non-valid channel

6. If “arm rogue-ap-aware” is enabled and an active client is found using the Rogue AP

But if the "arm Client aware" is enabled, client will not change it's channel.

Here I want to throw some light,

If Client-match is enabled and the above threshold ( noise-threshold and error-rate-threshold) reached, client match would have moved those clients to some other AP therefore if Client-match is enabled most of the occasions Client aware will not effect changing the channel, but of course , if client-match failed , AP can not change the channel.

Hope you got some more clarity on this :)

Please feel free to comeback for any further help .