Contemplating Auto RF Functions In WLAN Systems

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!

20 thoughts on “Contemplating Auto RF Functions In WLAN Systems

  1. John

    I’m certainly no expert but (and this may be available and ice just not found it yet) I’d like to be able to set the parameters (down to the AP?) that an auto-RF feature would adhere to. IE if I could say only ever use channels X,Y,Z and never more than A for power and B as the least power (per radio?)….that would certainly help in those odd places where design, architectural, vendor?, client use etc don’t all play nice so as to allow an auto-RF work as-is/default since it won’t necissarily know of such variables etc to “just work” correctly.

    Now that I’m thinking about it…I’ll go check out that Aerohive link and see what else I can’t find.

    Reply
  2. Frank

    We called Juniper a few months ago about auto rf making some blatantly bad decisions (as in, 3 APs in the same room all on 11 bad). Their response was that outside of a few APs or a lab environment, the recommendation was to disable it and set everything statically.

    We’re now in the process of migrating to Aruba, and are hopeful that their auto rf will play a little nicer.

    Reply
    1. stevemckim13

      That’s very interesting to hear John. I’ve seen similar things with Juniper. I’ll be taking a hard look at channel plans everywhere now.

      Reply
  3. Keith Parsons

    Thanks for bringing this to the forefront. I’ve just seen too many bad choices and poorly performing networks when customers believe the marketing and think their Auto-generated system is “magic” -that somehow it will fix what is wrong with a bad WLAN.

    Even the marketing names for some of these features borders on the unbeleivable. Like somehow a piece of software will clean up Rf interference… yet many actually fall for the marketing spin… they also plan on magically removing 2.4GHz CCM by just implementing get this mythical channel 14 and all will be well with the world.

    Reply
  4. niklasmato

    I’n my case i have some experience with Ruckus. I must say that it works fine from a certain Zonedirector release (eg 9.8..) I had a client who had an older version running in which 3AP’s on the same floor where running on channel 6. No need to say that CCI was causing tremendous problems. IMHO i’d suggest letting the auto selection on for 5Ghz but turn it off for 2.4Ghz and try to do this manually.

    Reply
    1. Primoz

      I would have a similar recommendation although with UNII bands in the EU having different power allowances I would suggest to make some sort of groups or pools of frequencies of which an AP could pick from.

      Reply
  5. Jon Foster (@UkEljay)

    I think there are a cases where auto-RF really shines, but more often than not it’s touted as an alternative to a good and thorough design. Given that many organisations don’t have Wi-Fi expertise, it’s all to easy for a bunch of “Professionals” to just chuck the APs up and sell the magic of Auto-RF – quoting the canned statements that come directly from the Vendor.

    For anyone in an area where the ‘airspace’ is not contended heavily, I would ask why use it. Using a tool like Ekahau Site Survey one can perform iterative design to minimise channel overlaps with set, known power levels. Why would you leave any Auto-RF stuff on or allow it to alter any of the settings you’ve so carefully laid out? Do you not find that the radio management is always changing channels – possibly causing cascades of changes? Even in well designed networks? Does it not do-your-head-in when you have to check that all your APs are still set up the same when troubleshooting a problem? (“Curses – i;m sure it was on channel 6 yesterday!”)

    I paid an awesome UK CWNP (CWNE level ) certified outfit to design a network for me, based on Aruba’s AP-125’s. They produced a very good design, which was installed … mostly as the photography and detailed design plans showed. They followed up with a validation survey which showed that things were generally good, BUT that the channels were all wrong – certainly not as planned.Checking just now I can see that they’re even now in-flux, changing a few times a day. If it were easy to accomplish without significant reconfig, I’d just turn ARM off completely.

    Aruba still hold that one should use ARM.

    If I had the resources, I’d issue this Challenge:-

    ARM vs CWNE.

    – Take one building.
    – Agree how interference and design quality would be measured
    – Design with CWNE certified engineer to agreed criteria.
    – Survey to test these criteria with channel and power setting nailed down
    – Enable ARM.
    – Resurvey to test these criteria . (May need a few surveys if the channel/power settings never settle down though, eh?)
    – Compare. See who’s network is better.

    Reply
    1. Andrew

      As others have said, automatic RF management will not save you from bad design, however, it can be a godsend when it comes to mitigating uncontrollable situations, such as microwave ovens, the new office tenants one floor below that are blasting haphazardly, other ISM wireless devices, Bluetooth, and so forth. The Wi-Fi frequency bands are unlicensed, meaning you’ve got no guarantee of coverage, ever. For my part, I want a mechanism to ensure that the client’s system continues to work despite outside influences.

      Two points I’d like to make from my experience with Zebra’s (formerly Motorola, formerly Symbol) SmartRF.
      First, we live in an age of instant gratification, and no automatic RF system can produce instantaneous results. Be patient, it some can take hours or even a day before the system as a whole settles down to some sort of normal operating mode. This doesn’t mean it doesn’t work in the interim, it just doesn’t have the best configuration worked out … yet.
      Second, get reports on neighboring AP coverage. Zebra’s platform has a handy feature that will report back the attenuation between neighboring APs and whether or not they are interfering with each other, and I don’t mean on the same channel. Two APs in close enough proximity will interfere with each other even if they are separate channels (eg: 1 and 6). By analyzing these reports you can constrain the power settings as too much signal is just as bad as not enough signal.
      @Frank, as an interesting point to Juniper’s comment that automatic RF is only for the lab, I’ve actually found the reverse, Zebra’s SmartRF works better when there are more APs. With 5 or fewer APs it doesn’t really do much, but once you’ve got more it starts to shine.

      Reply
      1. Keith R. Parsons

        I’ve got to disagree with your statement in the first paragraph. Auto RF systems CAN NOT mitigate the RF interfering devices. The best you can hope for is a temporary change in channel (with all the issues that are involved in moving clients from a channel) – Auto RF systems CAN NOT, and DO NOT actually fix anything! Perhaps they might sense something is wrong on a channel and switch channels (causing a change ripple) – but not do anything at all to mitigate the actual cause of the RF interference.

        AutoRF systems also have very little to do with client-based coverage. They are usually just AP’s listening to other AP’s – and don’t bring what the clients hear into their algorithms. AutoRF systems also are notorious for perpetuating more Co-Channel Interference. If two or more AP’s hear each other on the same frequency – above the CCA threshold – they will defer to each other. Thus be in the same collision domain. Thus sharing the same capacity – NOT adding more capacity. Yet AutoRF algorithms use this very feature to hear other AP’s on the same frequency – thus causing lower bandwidth availability for client devices.

        A well-designed WLAN has enough redundancy that any single AP going down won’t cause any coverage holes. Thus it is far better to replace the broken AP, than to have the nearby AP’s increase their power even more, causing even more Co-Channel Interference and lower throughput…

        Just my two cents,

        Keith

      2. Andrew

        @Keith, you are right, Auto RF cannot actually “fix” an underlying issue, however, in an environment that is unlicensed, external influences are inevitable, consequently a system that can adapt to a changing environment is, IMHO, superior to one that becomes unavailable or degraded because it cannot. Nor does an Auto RF system have to go off channel only temporarily, it can go permanently onto a different channel if a more stable equilibrium is found using another configuration pattern. Some elements in a WiFi network might need to be nailed down (mesh roots, P2P links come to mind), and an Auto RF system has to be able to work around that. Ultimately, an Auto RF system must finesse the configuration over time, and not start making changes that will rapidly propagate and trigger more changes. Not all vendor’s automatic RF systems are created equal, and that should be one of the selection criteria in selecting the vendor.
        From an operational perspective, it is perfectly normal for an Automatic RF system to make “tweaks” here and there, and unreasonable to expect it not to, again because of external influences. The one thing you want though is to be monitoring / getting alerts if the automatic RF system it is making many changes in a short time span, as this would be indicative of an underlying RF problem / design defect of one sort or another.

        You’ve indicated that neighbor/coverage hole recovery is undesirable, and I agree with you. I disable neighbor/coverage hole recovery functionality on any automatic RF system. A WLAN should have built-in redundancy which makes more sense. More RF signals do not generally help.
        At the end of the day, I don’t think that it is a good use of resources to spend time adjusting channel / power settings because of new and/or transient sources of interference. I’d prefer that the system do that itself, within set guidelines.

    2. wirednot Post author

      Thanks for reading and commenting, Jon- is an interesting challenge to think about. I’m guessing results would vary not only depending on what vendor gear was in play, but also by what code version was in use on that gear. Nothing simple about this stuff!

      -Lee

      Reply
      1. Jon Foster (@UkEljay)

        Indeed. And the design would also be different with each vendor’s kit due to differences in AP capabilities/antenna/etc. And what kind of building would one use to be representative? Etc!

  6. Sean

    Auto RF from any vendor is going to be a mostly static algorithm(firmware to firmware basis) decided on by the vendor to work for what they believe to be a majority of their customers implementations. Will it help? Sure. Is it a replacement for manual power/channel settings based off of predictive/active/manual site survey results? No, not at all.

    Personally, I would never base a purchasing decision or give much weight to Auto RF as a feature in any POC. In a single organization Auto RF from one vendor could work perfectly at one location and be a disaster in the next. You also leave the stability of your wireless environment up to the whims of what the vendor thinks works best. A 1db change on a single metric for a new firmware could change your entire RF environment.

    I get it, most IT shops don’t have the time or resources to commit to manual channel and power settings but these same shops should understand the risks of using Auto RF over manual planning. Auto RF is the “Pop Music” of the 802.11 industry. Vendors are producing a song that appeals to the masses but any music aficionado will tell you lacks substance.

    Many points have been made in this discussion to add visibility to the metrics used in vendor Auto RF algorithms and/or allow you to adjust these metrics. This could be a viable option for some “power admins” that have dedicated cycles to adjust these metrics but consider the point that settings these metrics for your environment is going to be a time intensive process and in order to be completed properly a site survey will still be needed. So if this much time is going to be spent just take the same time to do it properly and set power/channel setting yourself based on a sound site survey and unique user needs.

    Point being, Auto RF is a marketing device. Yes, vendors do spend considerable time on these algorithms. This feature shouldn’t be trusted, not due to the lack of vendor knowledge or commitment, but because this feature is designed to work for everyone, which usually means it won’t work for you and your WLAN implementation. Take the time to implement properly and don’t lean on this blanket based feature. If the time our resources aren’t available then at the very least understand the risks involved with leaning on this feature and make sure IT management is aware.

    Reply
    1. wirednot Post author

      Thanks for a great comment, Sean. I think you give a healthy, realistic perspective and those new to auto RF functions should read it a couple of times.

      -Lee

      Reply

Tell me what YOU think.

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

WordPress.com Logo

You are commenting using your WordPress.com 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