RRM Design - Putting it into Perspective

An interesting debate rages about wether or not enabling an Auto RF feature, such as Radio Resource Management (RRM), is a good thing to do. RRM does get its fair share of bad press but at the same time it’s no silver bullet either. The theory behind RRM is a good one;

“dynamically adjust RF parameters, to adapt to changes in the environment, to either maintain operation or self-healing of the RF network”

 

For the purpose of this blog, we will not be delving into the inner workings of RRM as there are many flavours of vendor implementations out there but what I will try to do is put things into Design perspective. Let me also make it clear that I am in no way advocating for RRM and nor am I against it. I strongly believe each Wi-Fi deployment should be based upon its own merits, customer requirements, constraints and technical support policies of the engineering company. I have had my fair share of implementation challenges where RRM has either worked or it hasn’t. I know for certain that most failed implementations are more than likely born from a lack of knowledge and dare I say it…a poor design approach.

Poor design is probably the biggest contributor to a failed, RRM enabled Wi-Fi design rather than RRM itself.  Lack of or poor configuration, eg leaving it on defaults, is also another contributor Remember what RRM is? Simply put, it is an algorithm. It’s a code that executes and makes decisions based upon what it’s been told to do via the RF inputs it receives. A common mistake engineers make is to turn on RRM retrospectively. What I mean here, they design a Wi-Fi network in a predictive model, install, turn up then blindly turn on RRM and wait for the magic to happen.
…
..
.

When the dust settles and you start your validation survey, I can guarantee you that it will look nothing like your original design. If the new landscape has changed for the worse, ask yourself this, has YOUR design failed RRM or is it RRM failing YOUR design?........ It’s not RRM.

If you or your customer have made the decision to implement RRM solution, the very first thing to consider before you begin to walk and click, is understand how the vendor RRM algorithm actually works and how it will integrate into your design. Easier said than done I know but if you don’t grasp it fully then don’t use it until you do. Where RRM gets a bad press is when a design is implemented and RRM is enabled but because no one really fully understood how it will modify the landscape, it’s deemed a bad design and RRM is to blame. That’s not how it works and a little unfair but ill also stress it’s a misconception that enabling RRM fixes your problems too.

Now, while it’s crucial to know how RRM works we have this double edged design sword to contend with. Firstly we rely heavily on good vendor documentation which can be hit and miss as it may not detailed or clear enough. Secondly we don’t have any tools to predict an auto RF design. Existing predictive modelling tools require AP Transmit power and channels to be statically applied. Wouldn’t it be great if our modelling tools were equipped to provide us engineers with an RRM simulate button? Is there such a demand for this feature? While we may ponder that last question, we have to make do with our existing tools.

So, how can we install a successful RRM solution? That’s the question for which I don’t have the silver bullet answer for you BUT I do have my own design approach that I will share with you:

1 – Determine what Transmit power levels are supported for your AP model. Everyone is different. Take into consideration the different UNII bands also.
2 – Stick to using supported transmit power levels only for your AP model, in your predictive design
3 – Produce your design based upon customer requirements, technical constraints and a basic understanding of RRM. Eg Cisco RRM requires each AP to see min 4 neighbors
4 – Validate first without RRM enabled using the static AP transmit powers in your predictive model. This gives you a baseline for YOUR design
5 – Validate with RRM enabled. Set RRM parameters. DO NOT LEAVE ON DEFAULTS!
6 – compare the 2. Which is working best? Which failed? Find out why? Which can you tweak to improve? Going forward, which solution is best for your customer?

This is a method I have tried to implement on occasions where the WIFI network isn’t too big and I have time to survey multiple times. I do this because I want to understand RRM in greater detail and answer those “WHY did you do that” questions

You should always Validate any design you install regardless of RRM or not. I have heard engineers relying on the algorithm as an excuse to not validate which is my book is poor and lazy. You still need to know just how well, or bad, RRM performs. It helps with troubleshooting!!!

If RRM determines your design rather than your design determining RRM, that’s a design relationship that’s never going to work. Decide which solution is appropriate for you and your customers. Work with what you are comfortable in. RRM can, if implemented properly, work within a satisfactory manner but there is also nothing wrong with not using it all.