12-09-2015 12:05 PM
So I am taking a CWNA boot camp and so far its been great. The instructor is great and very knowledgeable. However he went off on this long tangent about channel planning, how all auto sensing sucks and degrades performance of the network and whatnot.
I gotta say I was a little taken aback. I quit over all channel planning a long time ago. Granted I know that there are some instances where some tweaking of channels can help solving specific issues, but to be so adamantly against any sort of auto sensing I thought was unrealistic.
So I am putting it out there, what's your opinion on this? Lets hear it!
Network+ | CWNA | ACSP | ACMP | ACMA | BREC
12-10-2015 12:17 AM
Let me start with the statement that I work for Aruba, so my experience is based mainly on the Aruba ARM solution, and this may bias my personal opinion as well.
I found that most of my customers actively run the ARM (Adaptive Radio Management) that comes in the Aruba solution in the default settings. If you have a good coverage, network, that works pretty well. Lets take out the exceptions for very high density like crowd coverage in stadiums, event halls, and very hostile RF environments where you typically either tune ARM or revert back to static channel assignments.
Also, I learned that many other vendors in the wireless space, without calling specific names, advise against automatic radio management for several reasons that seem mostly related to their implementation. It either does convert quickly to a stable channel plan, or it does just a bad job, does not scale, does not adapt to changes in the environment because it only scans and calibrates during nights so adapts to a situation without users on the network. Please also note that if you are planning statically you will need to know your RF environment very well; do spectrum analysis on a regular schedule, check channel utilization, which require well trained engineers.
The reason to use ARM in most Aruba deployments is that typically channel assignment by the ARM algorithm has a much quicker outcome and is near or probably better than manual channel picking. So it saves time and if your channel plan is not better by ARM it probably is not much worse. Also they way Aruba implemented ARM is that if suddenly a source of interference, both WiFi and non WiFi, comes up, or the RF environment changes because your users move and change the RF environment, that a static channel plan will not respond to that; so you stick to the static plan that you developed. Also on 5 GHz if you use DFS channels, and you probably do, if a radar event is detected with a static channel assignment the radio has no oter choice than to go offline, potentially creating coverage holes.
In some networks, it may work to help ARM and remove some channels on APs were you see radar detections. Also if you have clients that refuse to work on DFS channels, it may help to create a basic grid with the non-DFS channels and let the other APs select a DFS channel for additional capacity for clients (most clients!) that do support DFS.
And yes, there are exceptions.... as mentioned before. It is known to me that different WLAN specialists have different views on it, either theoretical or pragmatic. I do believe in theory you can create a better channel plan through solid engineering; on the other hand I'm a pragmatist and believe that good is good enough and if the easy and automated way does not provide the desired results you can always revert back to the manual engineering work.
Hope this personal view helps. May be others can let know what their experience is?
If you have urgent issues, please contact your Aruba partner or Aruba TAC.
12-13-2015 02:39 PM
I've been on the fence regarding this. One day I'll have zero channel reuse issues on a floorplan, then the next day I have several APs sharing a channel. This is troubling in a high density VoIP deployment that I manage. I don't like the unpredictability that this results in. To combat this, I've been tweaking ARM nerd-knobs and working on what I call a dynamic channel plan. It's basically the idea of utilizing multiple regulatory domains with different sets of allowed channels. This way we can allow certain channels in one area and not another. This is somewhat of an experiment right now and if it doesn't pan out, I'm going to consider a static channel plan. I utilize DFS channels, and APs going offline because of radar interference could be problematic. I have sufficient overlap, but it's still a concern. I'd like to share my results after I'm done, so others may benefit from my findings. I haven't found a whole lot of good documentation regarding this.
If a reply adequately addresses your issue, please click on the "Accept as Solution" and "Give Kudos" button so this information can benefit other users.