Once upon a time, wireless networks were completely the product of the person or persons who designed, installed, and configured them. The WLAN couldn’t think for itself, per se, and important settings like channel and power were determined by the human hands and minds behind each Wi-Fi network. This was mostly a hallmark of the age of Fat Access Points, when our wireless networks were more about general coverage and less the stuff of carefully weaving high-density signal tapestries that support ever increasing client device counts. Now, there is impressive (or utterly maddening, depending on vendor and code version) magic behind the typical modern business WLAN; access points get their configs from some version of a mothership, and mystical “algorithms” choose what power and channel settings each access point will use.
If you let them, that is.
After a recent spirited Twitter dialogue with a couple of dozen really smart fellow wireless networkers, I found myself a bit taken aback by the general distrust of “auto RF” functionality that comes with almost any new Wi-Fi gear that uses multiple access points to form a WLAN. After all, these systems are not cheap, and the auto RF stuff is a major feature that adds to the cost. I’m not aware of any system that lets you order system code without auto RF to lower the price, yet a lot of WLAN professionals aren’t really embracing it. Is it a matter of general disdain for something that has caused pain for their end users that have lead my colleagues to speak somewhat unflatteringly about auto RF features, or is there something else at work?
From my own experience, I’ve been *generally* satisfied with Cisco’s Radio Resource Management (RRM) and use it extensively in my extremely large WLAN environment. At the same time, there have been a few cases where I’ve had to manually override RRM’s selected values. Usually, I can look at these exceptions and point out a design trade-off that we were forced to make (the real world is rarely perfect) that probably threw the RRM algorithm for a loop. It’s not that RRM failed me- in fact you could say that at times my design failed RRM.
I think this is some of the essence of skepticism behind auto RF from my wireless homies. Auto RF features are not divine cure-alls for bad design, nor can they be trusted to simply come to life and make everything OK with manufacturer’s default values in all cases. You have to learn how they work in your environments and with your design approaches, and realize that not all vendors are going to implement the same way. For me, I’ve got the most experience with Cisco’s RRM (generally pleased), Meraki’s version (can be weird at times), some Aruba (did a building-wide pilot a few years back, Aruba’s ARM did fine for me back then) and Aerohive on a small scale. Making things even more complicated, vendors can change their algorithms as they choose (potentially negating what you think you understand) and some document the technical underpinnings better than others… it gets tricky, yet I can’t imagine trying to keep my own 4,000 AP network up without it.
Here are some vendor links relating to auto RF functions (No slight intended to anyone I left out, this is just a sampling), and I have no clue whether there are newer versions available :
You get the point… some vendors are more explicit in explaining the theory of operation behind their auto RF mechanisms, others seem to have added it because it’s what you’re supposed to do anymore. Regardless, it’s very interesting.
I’d love to hear your opinions on the notion of auto RF, whether for a specific vendor or in general. What have you found that works? That doesn’t work? What’s your advice for people just getting started with auto RF capabilities? Any good auto-RF links to share?
Thanks for reading!