One in one hundred and fifty three quintillion.

RRM – a common term for Radio Resource Management – or the set of algorithms that set the channel and power level of your Access Points in an automated fashion. You’ve heard it all before, “RRM is broken, RRM picked the wrong channel, RRM hates me, RRM isn’t right for my network”. The reality is that RRM:

  • Isn’t dumb
  • Doesn’t hate you
  • Doesn’t love you
  • Doesn’t feel anything for that matter

As it turns out, RRM isn’t even smart. It has no feelings, passion, hate, love, real, imagined, or otherwise. In fact, RRM is just a series of algorithms that are built to do one thing – whatever you tell it to. RRM is a framework, meant to be built, adjusted, tweaked, and tuned. To be fair, there are two major topics that tend to give RRM a bad name and they are:

1) Every vendor implements RRM differently. This is a good thing. It’s called a competitive differentiator and the hardware capabilities of some vendors are not present in other vendors equipment so they may make poorer or less-informed decisions about your network

2) Most people don’t modify the default RRM configuration. This is a bad thing which leads me to the point of my post.

I decided to put myself in the shoes of Cisco. I asked myself, if I were building RRM, and I could only set one configuration as a default out of the box, how many would I have to pick from? The answer may surprise you – if you counted every possible RRM combination exposed in the GUI on a Cisco WLC (running 8.2 code) you’d end up in the neighborhood of 53 quintillion possibilities (153042639740283000000 to be exact). Assuming my math is correct (and if it’s not, I’m actually too low), that means that some poor developer somewhere had to pick *one* default configuration to ship out of the box and if you’ve not adjusted it, there’s a couple more for you to try… Now, I can already hear the groaning – “but I don’t have time to try all those!”. You’re right – of the possible sane configurations you can try, there are a few widgets you should focus on – and you certainly don’t need to try every possible combination but much like any other auto functioning mechanism in your network (OSPF, EIGRP, VTP, Auto Updates) the defaults are likely to not be 100% optimal in your environment. When your network adopted OSPF, did you leave it at the defaults? What about Windows Updates? What about AntiVirus? What about… never mind you get the idea…

Well, you may ask, why doesn’t Cisco just change the RRM defaults to ‘fit more environments’? That’s an excellent question and in fact, Cisco has done just that! They made a neighbor threshold change in WLC release and the overhauled the defaults with the Mobility Express setup wizard in 8.0. The question is, did you implement the changes of the new defaults or are you running an old config?

If you have an issue with the way RRM is functioning, instead of lambasting it as hateful, dumb, or otherwise ineffectual, I have one question to ask you. Which of the 153042639740283000000 combinations didn’t work for you?




Fun fact: if every possible RRM combination was a black pixel on your shiny new 4k TV, and you were watching 120FPS content, you’d be staring at a black screen for over 160 years.


Q: Isn’t it easier to just static plan all channels and TX powers everywhere?

A: Not if you want to spend your life manually reacting to new neighbors, new sources of interference, or any of the myriad of other changes that could occur in your environment – including AP failures (no one ever accidentally unplugs an AP, do they?) and people moving and changing furniture or other obstructions.

Q: Do I really need to try every last one of those combinations?

A: No! Nor am I advocating that. I think you should look at some of the heavy hitters (neighbors, max/min), understand how those work and how they’re impacting your network, then decide for yourself if tuning RRM makes sense.

Q: Why doesn’t Cisco just update my network with the new RRM defaults when I update code?

A: Because, not all RRM options are safe/valid for all users – you have a configuration on your WLC and I have one on mine. If you want to implement a new feature, you should do it prescriptively – not because a manufacture thinks it’s the best thing since sliced bread.

Q: Your number is too high. Are you sure that’s real?

A: Nope! In fact, I included *all* possible combinations with the intention of seeing just how high it actually is. This includes all possible channel combinations.

Q: But everyone runs the same channel combinations, that’s an inaccurate representation of your claims!

A: Not technically a question, but fair point – except that there are many multiple channel planning recommendations – some customers use a 3 channel 2.4GHz plan in the US, some use a 4 channel 2.4GHz plan in the UK. Some folks use UNII2e, some folks don’t. Some folks say use all channels except 149 (for Apple TV issues), some don’t. The upshot is that you must know your environment’s requirements including channel requirements and adjust for them. By the way, capping with a max 3 channel 2.4GHz plan and a max using default number of 5GHz channels (12)  in my calculations still leaves 18680481146880000 possible combinations. Feel free to check my math:

WLC combinations


14 Responses to One in one hundred and fifty three quintillion.

  1. wirednot says:

    Reblogged this on wirednot and commented:
    An excellent take on RRM, from a fellow professional whose opinion I trust and value. Have a read.

  2. WirelessStew says:

    Reblogged this on @WirelessStew and commented:
    Sam’s point of view on Radio Resource Managment (RRM for the masses). Make sure to grab a double espresso.

  3. Jason Grant says:

    Couldn’t we somehow build an algorithm to determine a pixel color for the 153,042,639,740,283,000,000 combinations for 160 years… maybe there’s be some art? Also, I’m disappointed you didn’t factor in how many of those 4k screens you’d need to buy since they most certainly won’t last the full cycle. 🙂

    I’m really glad you wrote this because really there is a problem. Defaults are defaults for a reason but don’t fit every situation and (regardless of vendor) not tweaking will always result in disappointment.

    • Sam Clements says:

      Hah! I was going to do a ‘too the moon and back’ equation, but it got out of hand (as you could imagine). The problem is, when dealing with numbers that large, you have to relate it to something because just understanding ‘how many’ when staring at a lot of digits is hard to do. I should have done an ‘if these were mW, here’s how many dBm it would be’… 🙂

  4. whywireless says:

    Reblogged this on whywireless and commented:
    Sam – good write-up/re-blogging +1

  5. Great post Sam. And I think it’s important to note that RRM is not magic and it can be as complex to configure as creating a static channel plan, but your point of not wanting to respond to neighbor changes on a regular basis is very valid in many (if not most) implementations. In the RRM debate, I would say that MUCH more training in:

    1) how it works
    2) impact of config changes

    is needed by the vendors. Instead of just giving us the feature, teach us how to use it in the complexity that is really there. This cannot be done by vendor-neutral organizations, like CWNP, because we would have to teach the nitty gritty details of each vendor’s implementation, which, of course, loses vendor neutrality. However, we do plan to cover it more in the new version of CWNA when it is released in the coming years. Great addition to the debate my friend!


    • Sam Clements says:

      Thanks Tom! Those of us fortunate enough to be Cisco shops can rely on the copious amounts of information on how their specific implementation works and failing the ability to digest the various white papers, there are awesome sessions at Cisco Live every year that go quite in-depth into the topic.

  6. Rowell says:

    Great write up Sam. I’ve been quiet on RRM and advocate on static channel planning but with a caveat – I haven’t spent enough time getting to know RRM. At the moment I choose to use static planning because I am redesigning and I’d like to get the network in a state where it lends itself towards RRM.

    In order for the algorithms to work correctly a wireless network should be designed properly with RRM in mind. Hopefully everyone agrees with me there.

    Now that I’ve said that, time to read up on it:

  7. Excellent write up. I’m not going to #checkthemath since that really isn’t the point. I’m amazed at times with some of the configurations that people have selected instead of letting RRM calculations happen.

    • Sam Clements says:

      Thank you sir! Yeah, it seems to be a topic of much debate, but at the end of the day RRM can do dang near anything a person can do, you just have to know how to tell it to do so – a skill which not many of the vendor neutral folks seem inclined to spend the time to learn.

  8. Kevin Marshall says:

    It is also worth noting that the RF Design Considerations section of the Cisco 8.1 Mobility Design Guide was completely re-written by Jim Florwick. As a RRM newbie I found this section much easier to consume.

    • Sam Clements says:

      Agreed 100% – The point is that there is a mountain of excellent information on Cisco’s RRM implementation. It is very powerful and while you don’t need to know every widget out there, inevitably one of them will get RRM to do what it is you think it should be doing. 🙂

  9. Pingback: 10 WiFi Networking Blogs You Should Read – Site Title

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: