About 18 months ago a new building was completed on our campus. During the post install Wi-Fi survey I noticed that pretty much all the APs were using the same 5GHz channel, despite being configured for our standard radio management profile. In fact the only thing Aruba ARM appeared to have done was reduce the power of most APs to the minimum specified. So what was going wrong?

Depending on who you listen to using the automatic radio management tool in your enterprise Wi-Fi setup is either eminently sensible or complete madness. Feelings run high when it comes to radio config it seems. Whether you ultimately decide to use it or not, it’s worth understanding what it does, how it does it, and how it really behaves outside of the ideal deployment.

Your Wi-Fi vendor sales guy will promise the world; they’ll tell you their solution is the best (of course) and that it will solve any RF issues, even removing the need for costly install surveys and design because the magic radio management will just sort it all out.

This is, of course, not true.

The first thing to you should be very clear about is that no RF management will fix a fundamentally bad design. So what does it do for you?

I have the most experience with Aruba’s Adaptive Radio Management, or ARM for short. ARM has grown gradually more sophisticated over the years as ArubaOS has developed. Essentially what ARM does is attempt to stop your access points from interfering with each other, reducing co-channel interference (APs on the same channel within range of each other). ARM will change the channels used by your APs and adjust power levels. It can also disable 2.4GHz radios where it deems necessary. The latest version announced can even change channel widths, allowing you to maximise performance by switching to 40MHz channels automatically where there is sufficient channel space.

In an environment with a controller and ‘lightweight’ APs you can be forgiven for thinking the controller gathers all the information about which APs can see each other and then creates a perfect channel plan. In reality Aruba campus APs are far less lightweight than you might imagine. Most of the management traffic and RF decisions, such as radar detection, channel selection and how ARM behaves all takes place on the AP with the controller notified what channel the AP has done.

This means automatic channel selection is an iterative process. In a large building with a lot of APs it can take ARM a long time to settle down as APs move channel to avoid a neighbour, but then interfere with a different neighbour. You have all your APs moving around the available channels, trying to keep out of each other’s way. In a large deployment I reckon on this process taking about 24 hours.

So what was going on in that new building?

The settings we were running for ARM were mostly default and these are fairly conservative. APs moving channel can cause a poor user experience, so you don’t want your APs to be jumping around all the time. By default ARM won’t move channel if there’s a client associated with the radio. You can control this behaviour by disabling Client Aware and control how aggressive ARM is by adjusting the Coverage Index and Backoff Time.

By creating an “aggressive” ARM profile and applying this to the new building AP group I found ARM then worked as expected, changing channels in order to minimise channel overlap. Good job ARM. Once the iterative process had been left running for 24 hours, we reverted to our regular ARM profile and all has looked pretty good since.

Because the 2.4GHz band has few non-overlapping channels, if you install dual band APs you’ll probably want to disable the 2.4GHz radio on quite a few APs. ARM will do this for you with a function called Mode-Aware. I can’t recommend using this. The problem is that ARM doesn’t have a high level view of… anything. Remember it’s just each AP knowing what it can ‘see’ around it. So ARM doesn’t understand the layout of the building and what areas each AP are providing coverage for.

On every occasion mode-aware has been turned on, we’ve had problems. ARM has disabled 2.4GHz radios on the wrong APs, usually those closest to the majority of users. Once after a system upgrade we had complaints that previously functioning Wi-Fi was now very poor. ARM had moved which APs had the 2.4GHz radio switched off. This is a function that might improve in the future but right now when it comes to disabling radios I reckon I can do a better job myself.

There can be similar issues with changing power levels. I’ve limited the range ARM can use to adjust power. It can reduce power by about 6dB, which is quite enough.

I mentioned that ARM won’t fix a bad design. Take an example (now fixed) of an accommodation block with APs in corridors, mounted at the same point on each floor, so vertically above each other. Pretty much every AP could see every other AP. 2.4GHz was a disaster and all ARM could do was turn down the power, which it did, to the absolute minimum. That didn’t help the channel overlap, but it did mean there was no longer coverage into many of the bedrooms turning a bad Wi-Fi experience into no Wi-Fi experience at all. It turned out 5GHz wasn’t much better because there were always clients around, so several APs were stuck on the same 5GHz channel.

None of this is ARM’s fault, but as we worked to fix the problems experienced by users, the first thing we did was disable most of the ARM features because their attempts to fix the poor RF design just made things worse.

So why bother with ARM at all? Firstly there has been no appetite to manually build static channel plans for more than 2000 APs. Aruba’s config leans towards an assumption you’ll be using ARM. The administrative overhead of the necessary profiles for all the various channel options would be an unpleasant thing to deal with. Perhaps most importantly, since making some fairly small changes to ARM, and better understanding what it can do for us, it’s now a useful tool that makes running the network easier and more predictable.