The WLAN Battle Over RRM

There is something of a religious war raging in the WLAN practitioner community. At the center of the debate is whether or not radio resource management ought to be used, and whether it can be trusted to keep WiFi systems running right. I’m going to share my opinion on both RRM and the accompanying imbroglio that is playing out among wireless professionals.

For those not up to speed on radio resource management, or RRM, let’s start with a simple definition: RRM is Cisco’s nomenclature for the feature set that allows for automatic channel and power selection in an operational WiFi network. Other vendors have their own names for this capability -- for example, Aruba Networks calls it adaptive radio management or ARM --  but RRM has become the de facto generic label put on auto-RF capabilities from different WLAN vendors.

RRM is an optional capability that you choose whether to use or not, but are certainly paying for when you buy a WLAN system in that it’s not added or removed with licensing. And like so many other aspects of today’s hyper-complicated WLAN systems, every vendor’s RRM is proprietary. This is  the source of the problem with RRM, and the foolishness of the current debate about its use.

The RRM brouhaha has two factions. There are those of us who recognize it as a time-saving tool when mastered and used properly, and those who swear that it’s wrong in every case and that manual power and channel selection is always the way to go. In my own very large WLAN environment, I give RRM credit for saving my organization hundreds (if not thousands) of man-hours in ongoing tuning of properly designed complex environments.

rock-em-sock-em-robots.jpg

At the same time, I’ve been bitten a couple of times by buggy code versions -- RRM lives in the underlying system code -- or ran into problems where I’ve had to use sub-optimal WLAN designs in a given area because of situational constraints. In both cases, I either learned how to fix the problem or tapped tech support to help me get past issues with manual tweaks in isolated areas of my WLAN; RRM still proved to be a formidable force multiplier in the rest of my environment.

When the RRM nay-sayers start throwing dirt, I look for important substance in their argument, which is usually missing.  I’ve heard plenty of rabid “RRM sucks!” rants on social media, but rarely hear references to the specific problematic vendor, code version, or WLAN hardware. I’ve also observed that RRM-bashers often are in a position of charging by the hour to “fix” RRM environments, while those who rely on it find RRM to be like an always-on staff member that watches over the WLAN and ultimately saves money via automated tweaks. 

However, I agree with the anti-RRMers on one point: Highly skilled wireless professionals could probably squeeze more performance out of a wireless network at any instant in time than RRM does. But I’ve found that at least with Cisco’s version of RRM, those extra few percentage points would likely not be noticed by the wireless clients or worth the high hourly cost of getting there. And whatever human-driven improvement that might get applied at that moment can be quickly invalidated a day later when the dynamic RF environment changes. It’s just not as simple as “RRM sucks” unless you use a specific vendor that doesn’t implement RRM well in code.

WLAN is an incredibly flexible technology, and leading vendors dump a ton of time and money into R&D. Each deployment starts with defining customer and situational requirements, and then a solution is shaped from a huge range of features and hardware options to meet those requirements. If a customer wants RRM, you’re better off designing a network that supports it and educating on its use than ranting about how all of those using RRM are wrong.

But then again, I find RRM to be just one item in a growing list of WLAN-specific topics that a small set of vocal absolutists like to harp on, and I don’t think it’s particularly good for the industry. We also have those who argue “2.4 GHz is dead!”, “Never use mesh wireless!”, “Never/always disable lower data rates!” and more from the book of This Is How I Do It, So You Must Too.

It’s time to lower the rhetoric and get back to the business of WiFi.

interop-las-vegas-small-logo.jpg

Learn more about wireless infrastructure and supporting the mobile enterprise in the Wireless & Mobility Track at Interop Las Vegas this spring. May 2-6. Don't miss out -- Register now!