With client density continually on the rise, and more high-density use cases popping up all the time, it only makes sense to replace unused 2.4GHz radios with 5GHz radios in many deployment scenarios. As the 2.4GHz band becomes more crowded with WiFi and non-WiFi devices, the pressure relief valve (so to speak) will be adding 5GHz radios into the design. To that end, vendors continue to introduce APs that are capable of Dual-5GHz (D5G) operation, rather than only Dual Band only.

Return on Investment (ROI)

One of the primary benefits of Dual-5GHz radios is ROI. In environments such as K-12, there is often one AP per classroom to handle density requirements (over the lifetime of the AP), but in that scenario, many 2.4GHz radios must be disabled in order to minimize or prevent CCI, which is the primary capacity killer in the network. Disabled 2.4GHz radios are not providing client connectivity, so capacity and ROI are significantly reduced. Some vendors may tout their ability to switch excess 2.4GHz radios into sensor mode(s), e.g. WIPS and/or spectrum as a benefit, and while that can provide meaningful value, it does not provide the same level of value that client connectivity would. If these radios could be switched to 5GHz, where there is cleaner spectrum and the possibility of providing far more capacity than with so many 2.4GHz radios, that would be a big win for customers. Essentially, customers would now be able to get all of what they pay for.

Typical Implementation

The typical implementation of the “D5G AP” is one fixed 5GHz radio and one “software-definable radio (SDR)” that can be configured for either band. This configuration offers broad design flexibility. The SDR could be used for WIPS scanning, mesh backhaul, or client access quite easily.

In the past, D5G has been implemented many times by companies such as Xirrus, Motorola, Meru, Extricom, and Cisco. Implementations have included Dual-5GHz capable APs, triple-radio APs with two 5GHz radios, and arrays capable of 4-16 radios. The elusive goal, to eliminate ACI, requires ~50dB+ of isolation between any two 5GHz radios. ACI causes erratic user experience due to varying volumes of frame errors across adjacent channels. Due to the requirement for more 5GHz radios, but the constraint of keeping cost in check, D5G APs are now resurfacing – this time (hopefully) solving the required 50dB (minimum) radio isolation and adding some neat new technology like Broadcom’s Zero-wait DFS feature. Zero-wait DFS can add value when RRM wants to move an AP to a DFS channel by pre-scanning that channel for 60+ seconds, but it cannot add value due to radar events because most regulatory domains require APs and clients to move away from a channel where radar has been detected within 10 seconds.

Next Generation of APs

When will we see the next generation of D5G APs?  The Aerohive AP-250 and AP-550 are two such APs, with one fixed 5GHz radio and one SDR (dual-band capable). Zero-wait DFS is supported only on the fixed 5GHz radios.  Aerohive claims to have achieved the 50dB+ isolation requirement, and part of their formula includes 80MHz spacing between channels on the same AP. That’s reasonable to achieve with a smart channel plan. D5G channel planning is already a controversial topic, depending on who you ask and their industry experience, so I’m going to dig into channel planning for D5G APs in a bit of detail below.

Radio Resource Management (RRM)

As I have written about and spoken on many times, RRM already has significant issues with minimizing CCI, regardless of vendor and “tuning.” I have repeatedly proven that not only is no vendor’s RRM perfect, but they are in fact usually very poor at doing their job. My challenge for RRM lovers everywhere is to survey three times, with four weeks between surveys, and each time, assess the CCI. This will tell you definitively if RRM is doing its job with that system, with that code revision, in your environment.
RRM could certainly be used to ‘figure out’ the channel plan of D5G radios, but given its track record of success in simple environments, I don’t believe I could trust it with something far more complex.  It’s for that reason that I strongly suggest a static channel/power plan when implementing Dual-5GHz radios, at least until such a time as vendors can greatly improve RRM.

Standard Channel Pairings

When using D5G APs, each radio will consume a 5GHz channel of course. To that end, we need to understand how to pair 20MHz channels on such APs.

36/100            149/116
40/104            153/132
44/108            157/136
48/112            161/140

Notice that the pairings I’ve listed above are non-DFS/DFS pairings, and this is for good reason. If there are clients that do not support DFS channels, then they will always have a non-DFS channel available in an area.  There are only 8 such channel pairings, but 8 channels is just barely enough to form a good channel re-use plan in single floor deployments.  You’re burning through spectrum at the same rate as deploying standard 40MHz channels, so you will have far less channels to work with than with 20MHz channel deployments. These “standard pairings” are designed to meet the required 80MHz of channel separation to achieve 50dB+ of channel isolation.

WARNING: It’s vital to understand that if you don’t create a set of standard pairings like those I’ve created above (and extend with additional channel pairings below), then you run the risk of creating high CCI.

40MHz or 80MHz Channels

Oh hell no. 40MHz channels should normally be used in single floor buildings, with fairly lossy (~15dB) walls. Use cases for 40MHz channels are few and far between already, e.g. home office or branch office. In a D5G scenario, use of two 20MHz channels per AP is already using up spectrum 40MHz per AP, but when using 40MHz per radio, 80MHz of spectrum is being used per AP, and when using 80MHz per radio, 160MHz of spectrum is being used per AP. Unless the use case is a small branch office or home, with clean spectrum, don’t do it.

DFS Safety Channel

The next consideration is what I call a “DFS Safety Channel”.  When you have DFS events, and need a 5GHz radio to exit a DFS channel, the 5GHz radio needs somewhere to go that won’t cause CCI. I would recommend using channel 165 for this safety channel due to no DFS requirements. Channel 165 can be paired with a UNII-2 channel, such as 52, to offer the network designer an additional channel for added capacity and reduced CCI.

TDWR Channels

Some systems do not support channels 120, 124, and 128, and even if they do, there are times when you shouldn’t use them (e.g. near an airport) if they are experiencing regular DFS events.  If they are available in your system, and it’s safe to use them, then I might suggest the following additional pairings for added capacity:


This can bring our channel pairing total to 12, and that’s easily enough for single floor environments and sometimes enough for multi-floor environments as well (depending on facility construction). I would strongly encourage readers to limit their multi-floor environments to medium-sized 2-floor environments due to the (very) limited number of available channels for the reuse plan. Large, 3-floor environments are usually very complex to plan when you have a limited (e.g. <20) number of channels in the reuse plan.

Of course, there’s our semi-new friend, channel 144, who has been left all alone. That’s OK. If additional capacity is needed, and many clients in the environment are 11ac capable, an AP can have channel 144 paired with a 2.4GHz channel for yet even more capacity.

Typical Deployment

I believe that you will soon see that D5G deployments will be primarily bound to two scenarios: 1 and 2 floor HD/VHD scenarios where lots of 5GHz radios are important for capacity, and TCO and ROI are important. While that may seem like a narrow set of scenarios, it’s really not.

In scenarios where it makes sense (due to CCI) to disable many (50-75%) of your 2.4GHz radios, enabling additional 5GHz radios in their place retains a customer’s ROI, while giving them capacity beyond what they would’ve had with the 2.4GHz radios enabled. This can certainly be important in environments like K-12 and universities.

Band Steering

Anyone who has attended one of my classes knows that I strongly promote against use of band steering because putting an SSID on both 2.4GHz and 5GHz will allow client devices to have a highly variable user experience. My advice in most enterprise environments is to disable band steering and put SSIDs on one band or the other. This does not apply to VHD environments that use a single SSID, such as stadiums and arenas.

That said, in D5G environments, a hybrid feature (that I call “channel steering) of band steering and load balancing can be used to balance client devices between 5GHz radios on the same AP, whether based on airtime utilization or client count on the AP’s radio. D5G channel steering will be a big winner for HD/VHD.

Predictive Modeling Tools

Ekahau’s ESS Pro can already model D5G radios.  Tamosoft says that TamoGraph will have it in their shortly-forthcoming 5.0 version, and NetScout/Fluke/AirMagnet said that they are also currently working on this. Kudos to each of them for keeping pace.

Random Thoughts

Thought #1:
I recently wrote a technical analysis blog on BlackBox’s HD3 solution, which I generally consider to be the worst Wi-Fi solution that has ever been contrived (and certainly should never have been).  If anyone is approached by BlackBox, trying to push HD3 as the same approach as D5G, tell them to lay off the crack pipe. I am happy to provide anti-references (those folks who have tried HD3 and found it to be a disgrace to all things WiFi related).

Thought #2:
When you have a small AP count, having a 5GHz mesh backhaul while also having 5GHz client access, could be useful.

Thought #3:
In the not-so-distant future, D5G combinations of 5GHz 11ac with 5GHz 11ax will make sense in order that 11ac clients don’t impair the efficiency of 11ax. There will be far more 11ac clients than 11ax clients for years to come, so keeping them separate, while still on the same AP should work nicely. I would very much like to see triple- or quad-radio APs that can add 11ad and/or LTE (but not LTE-U) radios to the 11ax/11ac D5G APs.

Thought #4:
Because lots of big A-MPDUs mixed with VoIP frames can be a problem for the voice traffic (it gets delayed behind large A-MPDUs), it could make sense, in some environments, to put a voice SSID on one radio per AP to separate applications. This could create a tricky channel design scenario, but it might work in small/medium scenarios.

Final Thoughts

I honestly anticipate that D5G will be a game changer for some customers, allowing them to keep pace with client density as we move computing devices to 5GHz so that IoT-in-2.4GHz has room to breathe.

I’d like to hear your thoughts on this. There has to be aspects of this approach that I haven’t considered, and I’d like to learn from those who can add value here.  Have you tried D5G radios before?  Which vendor? Did it work?  How did you test it?


Dual-5GHz Radio APs

6 thoughts on “Dual-5GHz Radio APs

  • April 7, 2016 at 7:37 am


    Nice article. You have mentioned band steering between the 5 GHz radios on the AP. Since u have suggested non-DFS/DFS channels, if u do not admit on non-DFS, will not the client have to wait a longer time to latch on to the DFS channel.. also, will all clients indicate DFS support in probe requests?..

    • April 7, 2016 at 12:50 pm

      Hi Srikanth,

      There would be no delay in allowing clients onto the DFS AP radios. Regarding the clients indicating their channel support to the AP:

      10.9.2 Association based on supported channels

      A STA shall provide an AP with a list of the channels in which it can operate when associating or reassociating using a Supported Channels element in Association Request frames or Reassociation Request frames.

      An AP may use the supported channels list for associated STAs as an input into an algorithm used to select a new channel for the BSS. The specification of the algorithm is beyond the scope of this standard.

      An AP may reject an association or reassociation request from a STA if it considers the STA’s supported channel list to be unacceptable. For example, a STA’s supported channel list might be unacceptable if it can operate only in a limited number of channels. The criteria for accepting or rejecting associations or reassociations are beyond the scope of this standard.

      Hope this helps.


      • July 12, 2016 at 1:40 am

        Thanks Devin for the clarification.


  • September 2, 2016 at 3:40 pm

    Greetings Devin. As always, thank you for your insight. I currently have a client who has enabled 40MHz wide channels on both 5 GHz radios in the same classroom. Help! Can you explain why this is a bad idea so I can logically dissuade them from this type of college classroom deployment utilizing “dual 5 GHz radio” technology?

  • September 2, 2016 at 4:32 pm

    Hi Mark,

    Thanks for dropping by.

    In a single-floor (2D) deployment, you would need about 9-10 channels in your 5GHz channel reuse plan if your walls cause 15-20dB loss at 5GHz in order to prevent CCI. In a multi-floor (3D) deployment, with the same wall loss, you would need 20+ channels in your reuse plan.

    Dual-5GHz deployments were only meant to be standalone if in a 2D environment with ~20 channels in your reuse plan because you are using them up 2 at a time (one 20MHz channel per radio). In a 3D environment, you are guaranteeing yourself lots of CCI by using 40MHz channels on a dual-band (5GHz/2.4GHz) scenario, and that CCI would then double with the use of dual-40MHz channels.

    The proper deployment of Dual-5GHz APs should be mixture of 5/5, 5/2.4, and 5/sensor — using ONLY 20MHz channels for 5GHz and using a meticulous channel plan (as you can read in this blog).

    It is better to use 20MHz channels (that have no CCI) than 40MHz channels that do. 40MHz channels will almost always (depending on physical building structure) cause CCI, which doubles (or more) the number of contenders in a contention domain. 25+ simultaneous transmitters in a contention domain will sharply decrease your throughput in the channel, very negatively impacting the user experience, which is the most important design/validation consideration.

    Keep in mind that the higher data rates achieved by using wider channels is MORE than offset by the induced CCI and decreased SNR. Doubling the channel width adds 3dB to the noise floor, and therefore decreases the SNR of a link by 3dB. That makes it harder to achieve the max MCS. http://www.revolutionwifi.net/revolutionwifi/2014/09/wi-fi-snr-to-mcs-data-rate-mapping.html

    In a multi-floor environment, I strongly suggest that you set some APs to 5/5, some to 5/2.4, and some to 5/sensor (for security and/or performance monitoring, if that’s desirable). Make sure your 5GHz channels on 5/5 APs are at least 80MHz apart (as previously mentioned in this blog post). 40MHz channels are a no-no, as it would induce a HUGE amount of ACI unless your walls and floors are made of solid lead. 🙂 (unlikely) Keep your output power on all 5GHz radios to a reasonably low EIRP (e.g. 10-13dBm) and 2.4GHz radios (what few of them are enabled) to 7-10dBm EIRP. Keep your Minimum Basic Rates to 24Mbps (disabling all other rates below 24Mbps) unless you have 11b clients on 2.4GHz. Only put an SSID on one band (never both in an enterprise environment), and disable bandsteering. Keeping these best practices in mind, design a good channel plan, and then validate it with a survey and by testing your client devices. From there, you’ll be in good shape.

Comments are closed.