How Radio Resource Management (RRM) Optimizes Wi-Fi Networks

The first place I heard the term “RRM,” I had to ask for what the acronym meant. This was in the years before Wi-Fi was popular, and the term originally came from mobile telephony networks.

You see, early in my career, I worked for a major telecom equipment supplier, and my little division was something like 1-2% of the company’s revenue and employee count. (I remember when we were finally big enough to appear in the parent company’s financial statements because our revenue was big enough to be a decimal point, and it was cause for celebration at division HQ.)

RRM stands for “radio resource management,” an important concept when you spend billions of dollars on radio spectrum (see how much was spent at the latest auction). The auction numbers were smaller when I first heard the term, but then, so was my phone bill!

After having spent huge amounts of money to acquire exclusive rights to the spectrum, it helps to use that spectrum in the most efficient way possible. Mobile telephony network planners had a variety of tools to wring the most out of their spectrum, both in terms of static planning tools and, later, dynamic algorithms.

The goal of RRM is to improve efficiency, and its effect can be measured along a continuum. At the most inefficient end, every transmitter in a network requires its own channel. With perfect efficiency, RRM would allow every transmitter to use the exact same spectrum. Cost can take several forms. In a mobile telephony network, spectrum has a financial cost because of the license.

Wireless LANs don’t have an explicit cost for spectrum, but cannot easily acquire more and still need to use the granted unlicensed spectrum as efficiently as possible.

Wireless LANs adopted the terminology of RRM systems because our customers weren’t radio experts, and they didn’t want to become radio experts. The typical early adopter of Wi-Fi was a network administrator who was familiar with layer 2 networks and wanted to extend an IP network out to a fuzzy wireless edge.

All the start-up companies formed to build high-end wireless LAN equipment needed to make radio setup easy for IT administrators that had no desire to become radio experts.  Airespace (later acquired by Cisco) adopted the RRM moniker without change; Aruba called their feature set ARM for “adaptive radio management.”

When Aerohive was founded later (yes, we celebrated the 10-year last week, but that makes us the new kid on the block), it was obvious that we needed to build in radio management.  Initially, our RRM capabilities were built around ACSP, the Aerohive Channel Selection Protocol; as we added further functions beyond automatic channel selection, it grew into RF-IQ.

As vendors, we talk a great deal about radio management algorithms. And yet, it doesn’t matter. Unless you have the skills, desire, and most importantly, time to develop your own metric of radio layout quality, the ability to measure that metric yourself, and know what tolerance range you need to land in, the quality of a radio management algorithm isn’t something that should register in your evaluation and purchasing decisions.

Even at Aerohive, I’d add that “where the algorithm executes” probably doesn’t matter as much to our customers as it does to us. I can talk at length about the value of a distributed computational approach to radio management, but that’s really the means we selected to get to the end you want: a solid, automatically-determine channel plan.

What does that metric look like? Well, that might even depend on the purpose of your network.

Most networks should be built to optimize total network throughput. That means that to assess how good a radio layout is, you should have several test endpoints per AP (believe me, the queuing algorithms for 40 clients per AP and 1-2 clients per AP look different!), and you should be able to determine to statistical significance whether RRM algorithm A or RRM algorithm B is better, and more importantly, by how much.

Throughput is easy to measure, but it might be wrong. Instead of focusing on streaming media, say instead that you stream real-time financial information (I probably wouldn’t do that over Wi-Fi, but I needed an example, and high-frequency algorithmic trading has made latency so important that there’s even a Wikipedia page on what it means in that industry).

If latency is your key metric, I don’t know of an off-the-shelf test tool you can buy to measure latency.  Heck, I don’t even know of tools you can buy that will allow you to monitor latency in your deployment with a real traffic mix.

So, before you take a position on whether RRM is for you, or whether you need an expert to double check what RRM is doing in your network, ask yourself these questions:

  1. What really drives my network? That is, what is the metric I care about more than anything else in the world?
  2. What is the acceptable range of my metric, and what are statistically significant ranges of the metric, so that I can understand the cost/benefit ratio of improving it?
  3. How do I measure my metric on an ongoing basis?

In my experience, the answer to question 1 is typically “throughput,” but many network architects don’t have a solid enough understanding of what the network is being asked to do to answer questions 2 and 3 quantitatively.

Understanding how your network is different from or similar to other networks is one of the main reasons that you might consider hiring an expert, and an experienced consultant will be able to put together a test and measurement plan using far more sophisticated tools than you might even know about. And of course, those of us in the vendor community need to instrument systems well enough to answer your questions.

So, should you use RRM? Should you hire a consultant? Should you do both?

It’s up to you, but if you’re going to look seriously at radio management, be sure you first understand what you need RRM to do and can quantitatively assess the results.

Matthew Gast is Director of Advanced Technology at Aerohive Networks. He currently serves as chair of both the Wi-Fi Alliance's security task groups, was the first chair of the Wireless Network Management Marketing task group, and is the past chair of the IEEE 802.11 revision task group. Matthew is also the author of 802.11 Wireless Networks: The Definitive Guide (O'Reilly), which is now in its second edition and has been translated into six languages. His companion book, 802.11n book, 802.11n: A Survival Guide (O’Reilly), was recently published and provides information on how 802.11n works and what it means for the WLAN planning process. Most recently, Matthew completed 802.11ac: A Survival Guide (O'Reilly).

Leave a Reply

Your email address will not be published. Required fields are marked *