Static Channel Assignment vs RRM/ARM

Static Channel Assignment vs RRM/ARM



Every time I scan a network that uses Radio Resource Management (RRM) or Adaptive Radio Management (ARM) and I see access points on the same channels near each other I cringe. I see this even with networks that are using all 26 5GHz channels. Why does RRM/ARM repeat channels so frequently? Every time I see this and I hear people saying RRM works every time without issue or configuration I have to chuckle a bit. Well, I think you will see as far as Channel planning it does not work well.


I have always been a fan of static channel assignments and static power. I know I am a dinosaur, but this is the only way you can be assured you will not see the same channel repeated very often.


I still recommend using an 8 channel plan, especially when using voice (as I said I am a dinosaur). I believe this is not a problem since back in the day we had 2.4GHz and only had 3 non over lapping channels to work with. Now if we recommend anyone use only 8 channels some network administrators cry like little schoolgirls saying “We want to use all the channels because we want the higher data rates that 40MHz and 80MHz channels give us”.


First of all, if you are using 80MHz in an enterprise environment (on 5GHz) you should be tarred and feathered. We all know how inefficient 80MHz channels are, but some Network Admins have bought into the marketing hype that bonded channels give you higher data rates and a faster more efficient network. This argument has plenty of holes in it.

The two I like to bring up are;

1.)The majority of even data packets are small (voice, email, web browsing) and these packets never use the full bandwidth of bonded channels.
2.)Even when larger packets are sent the secondary channels remain less than fully utilized.


I was once at a site that was using Extreme Access Point running Radio Resource Management (or whatever their version is). They had only 30 Access Points and were using 26 5GHz channels so, in theory, I should have seen only 4 channels repeated once and most channels never repeated. This of course was not the case. There were multiple times when I scanned the network and saw the same channels within range of each other. I can hear the skeptics saying that only happens with brands like Extreme but if you look at the screenshots below you will see this happens with Cisco and Aruba as well.


Each AP vendor has a crazy way of coming up with a list of preferred channels and they use these channels more often than others. Cisco used to heavily use Channel 36; now they’ve seemed to fix the channel 36 issues, but they still repeat channels in an RRM configuration far more than you would if you manually planned the channels.



When we design a wireless network, we always use a static channel and static power; this works extremely well. The problem comes in when we install the system and for whatever reason we let RRM take over after the design is done. Why is this? I have never heard of a design or customer requirement that states let RRM choose the channel and power. When you are planning your design the channel plan may be chosen by the design software like Ekahau or AirMagnet but this is still far better than RRM.


There are some arguments to be made for RRM over static channels design. Two of the arguments are the DFS channel issue and the coverage issues (if an AP goes offline). The first argument is the DFS channel issue. If you assigned your channel plan statically and used DFS channels, when the AP hears a radar event by the regulation, the AP needs to stay off that channel for 30 min. If you used static channels the AP would have to stop transmitting for 30 minutes. The AP does this because it lacks a mechanism to shift from the affected channel. The second argument for RRM is the coverage issue. If an AP goes offline then RRM can manually adjust the power of existing APs to fix the coverage gaps.


There are two fixes for this. The first is to keep to the 8-channel plan and you would never use a DFS channel. The second fix would be to design your network for voice coverage (two APs at -65 or better) if one AP went offline due to a radar event then there would be another AP to make sure the coverage was still good.



There are three screen shots below two from a Cisco network and one from an Aruba Network. These screenshots show multiple examples of RRM/ARM using the same channel in close proximity of each other.

This screenshot shows 2 APs on Channel 36 , 3 APs on Channel 100 . There is separation on some of these APs but my point is that, when left to RRM, Cisco uses channels more than they should on the same floor. This screenshot was filtered to show only the APs that my device was connecting to.





This screenshot is from a Cisco site running RRM. You can see multiple APs have the same channel. There are 5 APs on Channel 36 , 6 APs on Channel 44 , and 2 APs on Channel 149 . This screenshot was filtered to show only the APs that my device was connecting to.















Just in case you are thinking I am just picking on Cisco here is an Aruba site that has 2 APs using channel 44 , 2 APs using Channel 149 , and 2 APs using Channel 100 . This screenshot was filtered to show only the APs my device was connecting to.






In conclusion static channel power is the only way you can be certain that channels will not get used over and over again. RRM and ARM have there place but nothing can implement your channel plan better than you can.

Thank you for reading this blog. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter please use this link to follow me.


DFS channels and why to avoid them (even though you say you cannot)

DFS channels and why to avoid them (even though you say you cannot)


These days most wireless guys say they cannot stick to only 8 channels. Most people agree that you should use all 26 channels (including all the DFS channels). The truth is you can use an 8-channel plan if you use 20 MHz wide channels exclusively. I know …I know every marketing person, every manager and every user just lost their collective minds. Everyone wants to use 80 and 160 MHz wide channels and most people (even Wi-Fi people) want to use 40 MHz channels everywhere. If you use wide channels then you cannot stick to an 8-channel plan. On the other hand, if you agree that using 20 MHz channels is a more efficient use of the channels and spectrum, then you can very easily get away with using only 8 channels.


There are 9 non-DFS channels but when you use channel 165 (the highest channel in UNII-3) you may run into issues since there is not enough separation between Channel 165 and UNII-4 band channels. This has been known to cause issues, especially with voice clients. I always recommend staying away from channel 165 which leaves us with an 8-channel plan (36, 40, 44, 48, 149, 153, 157, and 161).


Back in the day when we used 2.4 GHz only networks, you were limited to only 3 channels, and despite this people more clever than, I got it to work with very few issues. Yes, there was always co-channel interference, but the better engineers would work to minimize it. In 5 GHz, suddenly using 8 channels is big a hassle for most people. Have we gotten lazy, or have we bought into the lie that wider channels are better? I will save my arguments for why 40MHz channels are highly inefficient for another blog. If you do not want to wait, you can look at Devin Akin’s blog at  he does an amazing job diving into this point.


DFS Channels

What is a DFS channel? These channels share the spectrum with Weather Radar and Radar systems. For the FCC and IEEE to approve the use of these channels in WIFI, a mechanism had to be in place where these channels could co-exist. A mechanism called DFS (Dynamic Frequency Selection) was created to have the WIFI devices listen for radar events and either stop using the channels or automatically move off these channels. When RRM/ARM is used, and an AP hears a radar event it must pick a new channel and inform its clients to move to this new channel. If RRM/ARM is not used, then AP after hearing a radar event must stop transmitting for 30 minutes.






Why are DFS channels so bad?


There are 16 DFS channels in the UNII-2 and UNII-2e space (52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, and 144). These channels have two major drawbacks, especially for voice clients. These drawbacks are 1.) The length of time it takes for a client to scan DFS channels. 2.) When radar events are heard the APs and device must move off that channel. The rest of this blog I will talk about these two issues.


The first issue is how long it takes a client to scan the DFS channels. This changes a bit with different clients but since I know the Vocera devices I will use them as an example. When the Vocera badge scans non-DFS channels, it immediately sends a probe request and gets back a probe response this takes roughly 15 – 20ms per channel. The device must return to its original channel for 50ms to do any TX/RX it may need. The total time to scan each channel is 65ms. When you multiply 65ms by 8 channels you get a total scan time of 520ms. When the badge scans a DFS channel it cannot send a probe right away. It must make sure there is no radar on this channel. It does this by listening for a beacon (100 – 104ms). The device will then send a Probe Request and receive a Probe Response only after it hears a beacon. Since it has stayed off its channel so long it needs to return to its original channel for 150ms for any Tx/Rx. The round trip time for every channel is roughly 250ms. When you multiply 250ms by 16 channels you get a total scan time of 4000ms (4 seconds). Four seconds may seem like a short time but, for a voice client that has a jitter buffer of 120ms, a 4-second delay can seem like a lifetime. When the device is in the middle of a call and needs to find another AP to roam to a delay beyond 120ms will cause choppy audio. It will take even longer if you hide the SSID since the badge must take an extra step of sending a Probe Request with the wildcard in it so all APs will respond.


This improves greatly when you have 802.11k enabled. When using 802.11k after the device connects to the AP it will request a Neighbor list. This neighbor list will (normally…if everything is working right) contain a list of APs that are its closest neighbors. This will cut down the number of channels the device has to scan. If the device happens to move away from all the APs in the neighbor list it will need to do a full scan.


The second issue with DFS channels is when a DFS event occurs (or even a false positive happens) the AP must send out a channel change announcement which tells the devices that it must move. Most clients will treat this as a new roaming event without the benefit of pre-scanning the channels before the move. They will have to rescan all the channels instead of just the one where the AP is moving to. If you are a laptop surfing the internet or reading email you may never notice the delay but if you are a voice client in the middle of a call you will experience choppy audio during the forced roam.



In conclusion, stick with 20 MHz channels and use only the 8 Non-DFS channels. By doing this you will avoid all the issues that come along with the DFS channels. If your devices or applications need to move massive amounts of data, either stick a cable in it or switch over to Wi-Fi 6e and you can have all the bonded channels you want. You will not have to worry about the fact you are running highly inefficient bonded channels until you start using 320 MHz bonded channels and Wi-Fi 6e will be down to 4 channels and this will restart the discussion all over bonded channels again.


CAC (Call Admission Control)

Is CAC fair to your clients that don’t support it?

I support a voice product that does not support CAC. Is it right for me to ask the Wireless Network Administrator to disable it because my device doesn’t support it? Is CAC fair? Why does it supersede WMM? I will attempt to answer some of these questions in this blog.

Cisco uses CAC (Call Admission Control) that enables access points to maintain controlled quality of service (QoS). CAC is also tasked with the ability to ensure there is a limited number of voice clients per AP.


How does CAC maintain control of QoS?

The AP will send a beacon frame out on each SSID, usually every 100ms or so. In these beacon frames, the AP will tell what features it will support for that particular SSID. Inside the beacon frames under the Vendor Tag: Microsoft: WMM parameters the AP tells the clients which WMM Access Category that CAC has been enabled on (see example 1 below). When a device associates to the AP (and the device doesn’t support CAC) the device will choose the highest level of WMM that doesn’t have CAC enabled on (see example 2 below). If CAC is enabled on AC_Voice, but not on AC_Video, AC_Best Effort or AC_Background then the client will choose AC_Video even if the client is expecting to use Voice grade WMM or even when the SSID and VLAN are set up to use Platinum QoS.


Why is this an issue?

WIFI is a contention-based shared media. The AP and clients need to know that no one else will be transmitting at the same time they are. If another device does transmit at the same time it will cause collisions and the packets will have to be resent. In order to avoid collisions, the clients and APs uses Physical Carrier Sense and Virtual Carrier Sense. A device or AP will use both Physical and Virtual Carrier Sense while trying to access the wireless medium.

Physical Carrier sense happens when the station listens to the wireless medium to see if there is RF energy on the medium. If there is, the device will then know that the medium is being used. This is called Clear Channel Assessment (CCA). Virtual Carrier sense is where the station reads the Duration/ID field and sets its own NAV (Network Allocation Vector) timer. While the NAV is still active the station will not transmit. When the NAV timer goes to 0 the station waits DIFS (Disturbed Coordination Function Interframe space), which is set per PHY that you are using.  When the DIFS expires the station will choose a random number from the Contention Window (CW) range and multiply it by the slot time of the PHY you are using.  After all the timers have ended the device will do another CCA and then transmit.

The Access Category gives the client a range called the Contention Window (CW). This range is called the CWmin and CWmax values (see chart below). The device will choose a random number in the CW range and will multiply this with a set number based on the PHY. The client will wait this random amount of time and then will do another Clear Channel Assessment (CCA) to make sure no one else is transmitting at that time. Each client will choose a different value in the Min/Max times. This gives the AC categories with the lower CW values a better chance to transmit, but it is only a probabilistic chance. The lower Categories will get a chance to transmit. When the lower priority clients hear a transmission in the middle of a count/hold sequence they will pause the count/hold, look into the Duration/ID field and sets its NAV timer. When the NAV timer expires and the air is clear the client will resume the hold sequence from where it left off. So eventually it will transmit even while the higher category might be counting down.


The CW values per AC Categories are below.

Category                    CWmin           CWmax

AC_Voice                            3                             7

AC_Video                            7                             15

AC_Background               15                           1023

AC_Best Effort                  15                           1023


When a client is sending voice packets the client expects to send these packets using the Platinum level of QoS to avoid latency or jitter. If the client does not support CAC and it has to choose the next WMM parameter that doesn’t have CAC support (in this case it was Video) the client will possibly get a much higher CWmin and CWmax time then it should. If the controller set up CAC on Video then the client would choose Background. This would give the client an even worse CWmin and CWmax range to work with. This not only affects upstream, but the packets are labeled as video which would further delay the packets through the wired network.


On the return traffic, the network may further strip the QoS level down to Best Effort. In a busy network, this can be problematic for voice clients.


Given all of this, is it right for me to ask the wireless guy at the hospital to change the CAC settings because my device does not support CAC? Or should I push back on my own engineering team to fix our client to support CAC? Or should I do both? I can see the wireless guys ponder this as I ask them to remove CAC. Most people in the wireless field are very accommodating especially when you show them the results. Our device is not seen as just another device needing access. This device is usually pushed by C Suite and the nurses on the floor. Wireless guys realize that our product if given the best environment to work in, will help caregivers communicate more effectively and will ultimately help patients. So, if you see me coming, be forewarned I don’t like CAC, DTIMs set to 2 or higher, FRA or RRM (with no limits set). I might ask for things others don’t, but when I do I will back it up with facts and will always be appreciative of your willingness to work with us.



Example 1 Beacon showing Voice is using ACM (CAC)










Example 2: Data packets showing Client chose QoS of Video












Example 3: Screenshot from the Wireless Controller Config showing the WLAN has the QoS set to Platinum


(Cisco Controller) >show wlan x

WLAN Identifier……………………………. x

Profile Name………………………………. xxxxxxxxx

Network Name (SSID)………………………… xxxxxxxx

Status……………………………………. Disabled

MAC Filtering……………………………… Disabled

Broadcast SSID…………………………….. Disabled

AAA Policy Override………………………… Enabled

************************Data Removed*********************

Quality of Service…………………………. Platinum




Example 4: Screenshot from the Wireless Controller showing CAC and ACM set on the Voice AC



Call Admission Control (CAC) configuration

Voice AC:

Voice AC – Admission control (ACM)………… Enabled

Voice Stream-Size……………………….. 84000

Voice Max-Streams……………………….. 2

Voice max RF bandwidth…………………… 75

Voice reserved roaming bandwidth………….. 6

Voice CAC Method ……………………….. Load-Based

Voice tspec inactivity timeout……………. Disabled

CAC SIP-Voice configuration

SIP based CAC ………………………….. Disabled

SIP Codec Type …………………………. CODEC_TYPE_G711

SIP call bandwidth ……………………… 64

SIP call bandwith sample-size ……………. 20

Video AC:

Video AC – Admission control (ACM)………… Disabled

Video max RF bandwidth…………………… Infinite

Video reserved roaming bandwidth………….. 0

Video load-based CAC mode………………… Disabled

Video CAC Method ……………………….. Static

CAC SIP-Video Configuration

SIP based CAC ………………………….. Disabled

Best-effort AC – Admission control (ACM)…… Disabled

Background AC – Admission control (ACM)……. Disabled

Maximum Number of Clients per AP Radio……….. 200


Cisco’s Flexible Radio Assignment (FRA)


I have heard about Cisco FRA for a while but I am only starting to see this out in the field. This technology offers great advancements over statically assigned Radios.

There are two modes of operation in FRA Macro/Macro cell and Macro/Micro cell. I will only be discussing the Macro/Micro mode in this blog. The Macro/Micro cell will have a large cell and a smaller cell inside which will increase capacity on your 5 GHz network.

The theory behind FRA is if you design a network for 5 GHz then you will more than likely have too much 2.4 GHz coverage. This is why FRA is only run against the 2.4 GHz radios.

There are only two AP models that work with FRA. They are the 2800/3800. When the AP creates a Micro cell, the power will always be set to the minimum power of the AP. In the case of the 3802, this would be 2 dBm.


How it Works

FRA uses the Neighbor Discovery Protocol (NDP) from RRM to figure out if there is too much coverage on the 2.4 GHz band. The output of this calculation is called Coverage Overlap Factor (COF). You can set the threshold for the COF at Low 100%, Medium 95% and High 90%. When FRA sees too much coverage based on these thresholds values, it will mark the radio as redundant. Once it is marked redundant it can be assigned another role. There are three states (roles) these radios can be in 2.4GHz/5GHz/Monitor Mode. Depending on the COF the controller will either leave it at 2.4GHz, change it to 5 GHz or put it in Monitor Mode. When the controller puts an AP in Monitor mode the only way to fix this is to reset the AP.


Probe Suppression

The AP can suppress Probe responses from one of the radios. When the APs receives Probe requests on both the Macro and Micro cells within a short period of time from a client who is not associated, the AP can suppress the Probe Responses on the radio which it doesn’t want the device to join. When a client is associated to either radio on the AP, the AP will suppress the Probe Response from the other radio. This should help prevent the client from roaming between radios. The Probe Suppression option is disabled by default on the controller.


FRA will monitor the cells and keep devices that are similar on the same radio. This will help improve throughput. FRA will use 802.11v, 802.k and Probe Suppression to keep the same type of clients on the same radio.




Pros and Cons of FRA


      • FRA will give you more capacity in the 5 GHz band.
      • FRA eliminates of fixes the balance between 5 GHz and 2.4 GHz radios on your wireless network.
      • The controller will limit how many devices can be on the Micro cell.



  • If your device authenticates to the Micro Cell and moves away from the Micro cell area. This could force it to roam to the Macro cell, which would increase roaming. These additional roaming events force the device to stay awake more which will affect battery life. Cisco has safeguards against this but just like RRM, it doesn’t always work.
  • If you have 2.4 GHz clients your network, the coverage area after FRA runs could change dramatically. Depending on how often you have FRA run, this can lead to a less stable network. I know Devin Akin (@DevinAkin) would say that 2.4 GHz is dead and probably should be at this point especially for voice clients, but I just did a job last week where they insisted using 2.4 GHz for voice.