Even in a deployment as small as this one (they only had eight APs) using 80MHz channel is a non-starter. The WLAN was literally interfering with itself. Even enabling DFS channels would have been a difficult thing to make work, even then (theoretically) we could have 5-6 channels. However, channel 144 is ONLY usable by 802.11ac devices. So, typically, we don't use channel 144. Also, if TDWR (Terminal Doppler Weather Radar) is within hearing range of the WLAN, those channels are not used. Now we're down to FOUR 80MHz channels. Four channels may work in a small environment, but then you have to consider WLANs other than yours.
Unless you are in a secluded area there will probably be other WLANs within earshot of your network. So, if any of the secondary-channels that make up the 80MHz channel that you are on are also in use by other clients, you will experience issues. In this case, the WLAN was in an office building that had other tenants with their own WLANs. So, using 80MHz channels in the scenario was the main cause of their problems. (Even if they were secluded usage of 80MHz channels would not be practical.)
The fix was simple. I enabled DFS on their controller and disabled 80MHz channel usage. This immediately dropped all APs (access points) to using 40MHz channels. And, with the use of the now available DFS channels, we had NINE channels to use among 8 APs. The point here is DFS gives A LOT more channels to work with - so it's worth using them.
I can't blame the customer for this. The installer should have known that 80MHz channels in an enterprise environment is not practical, or in this case, even viable. It was clear what had happened. The system defaults were left as-is, and there was little to no customization of the WLAN.
By default, 80MHz channels were enabled.
By default, DFS was disabled.
By default, all APs were set to transmit at maximum power.
This just shows the importance of knowledgable and experienced when deploying wireless networks. It's more than mounting APs and creating a few SSIDs. It's understanding how RF (radio frequencies) work, what its limitations are, and how to design around them.
One last note on using DFS channels. I have seen great success using them, but the reason DFS channels are not enabled by default is because they share spectrum with radar systems:
DFS is a mechanism to allow unlicensed devices to use the 5GHz frequency bands already allocated to radar systems without causing interference to those radars. The concept of DFS is to have the unlicensed device detect the presence of a radar system on the channel they are using and, if the level of the radar is above a certain threshold, vacate that channel and select an alternate channel.
- Aruba, an HP Enterprise Company
For this reason DFS is disabled by default on Aruba controllers (the system I was working on). If near an airport, a marina, or military installation, you should consider the possibility of radar events. A radar event occurs when an AP hears (or, thinks it hears) radar on the channel it's on. When this occurs the AP immediately switches to another channel (as per FCC regulation). This will cause all the clients on that AP to be disconnected. They will then probe for a new AP and reconnect. With a few events per month this may not be a big issue. But, if you have mission-critical applications (a hospital perhaps) radar events may not allow DFS to be an option. You may even need to go down to 20MHz channels so you can have more spatial re-use with non-DFS channels.
I recommend enabling and using DFS whenever possible. Then monitor your network for events. If they never occur, or are very infrequent then continue using DFS. If you see events that seem to be centered on certain frequencies disable just those DFS channels.
