@R1D2 

Your reference chart for WLAN channel allocation is pretty much out of date, by the way.

 

I don't typically like to get into these things because they're always "measuring" contests., but this one is kinda important. 

Your above statement is a feable way of attempting to discredit someone, and an incorrect one at that.  The information provided is by wifipros actually quite correct.  It is clear that you either 1)  do not reside in the US, or 2) you do not know your industry/market.  I believe you mentioned "hot spot" designer of some fashion?  I frequently find code writers to lack understanding of their own limitations, and it frequently revolves around believing the know more about how things "ACTUALLY" function, as opposed to how they function in the coders mind.  In example, as a lazy way of coding, drivers often have hardcoded values, rather than using the "industry standard" from the RFC's that explain EXACTLY how it should work.  This causes all manner of problems that can be easily found using wireshark, when you know what to look for.  Unfortately, it takes a lot of specialized looking, all because a "Dev" was lazy, or mis-guided (ie. mis-informed about his/her own knowledge). Let me give you an example:

A major mobile telco provider decides to write a driver for their devices.  While I will not deny the complexity of sending a radio signal to a tower while moving at 70 MPH has got to be a large task, there are standards.  One such DEV decided to override the standard "auto detection" of speed (of transmission of the device) and set it to a hardcoded number.  Every time the rest of the systems would query the "transmit" window, the hardcoded device would spit back an answer because of the hardcoded value, rather than the detected value...lets call it 100 mb/s for the sake of argument.  However, after passing through several endpoints, the final "link" transmit was several hundred kbp/s.  So, basically, all the devices that had this driver said "Send me 100mb/s of data, I can take it" and thereby overwhelming the linkpoint in between, that could not take 100mb/s.  This saturation not only effect the one device, but all customers that had to pass through that bottleneck point.  All that because a "DEV" thought they knew better than the guys that invented, designed, and standardized our modern networks.  Please, understand, I don't frequently trust "DEV's" ability to do anything other than write code, most have very little if any hands on experiece outside of a lab use.  And please...don't just read the doc's, ask someone who works closely with the systems you are building...it makes a better world for the rest of us.  (FYI, in the above "real world" example, the Dev wanted to "show" higher speeds for mobile devices and actually hardcoded 4 gb/s, apparently thinking it was just a upper boundary and not understanding how networking work. At the time they did this, 4G LTE was barely in planning, and 5G wasn't even a topic).  That was a "realworld" example presented by an expert at Wireshark's "Sharkfest" annual convention of pcap devs and professionals.  The topic was why we should read and know the RFC standards of the IEEE 802 body.

In my 30+ year career (20 of which dealing with wireless), and now working for one of the largest healthcare systems in the US, it's kinda my business to know what wireless IS and what is possible and "LEGAL".  (I was probably running wireless systems before you knew what a keyboard was.)  Having some of the most reviewed/audited, second guessed and publicly visible systems in the world, we kinda have to know or we get $10,000's or $100,000's of fines per day until corrected.  My job now is to DESIGN, REVIEW, then validate the RF signal is doing what we need.  I need to plan, know, and review radio RF and radiation.  In fact, one of our bigest challenges is ... you guessed it, agressive hotspot providers that refuse to "play nice" in shared airspace.

"DFS isn't legal in the US for x, y, z purpose"

Have you tried to use channel 14 for 2.4 GHz (in the US)?  While it is possible, through many precarious means, it is IMPOSSIBLE to find a vendor that will support it (no, not 1 vendor that will).  Why?  Because the LAW says it's not useable.  That means you CANNOT find one single device (in factory condition) sold in the US that will allow ch 14 for 2.4 GHz (while operating in US mode). NOT ONE!  Yet, I can go to Fry's, or Amazon, or name your local store.  I can find both consumer, business, and enterprise devices that ALL support channels 52, 56, 60, and 64.  Why?  They are ALL legal and free to use in the US with the caveat (means condition) that they have to back of transmitting and switch to another channel so long as signals are detected in the range.  Otherwise, NO other vendor could sell or support it (in the US).

I am not a large fan of enabling those channel's for commercial use.  In fact, many of my designs exclude them, as I cannot risk upsetting 700 other AP's because DFS channels are detected. At the same time, I need to balance the competing issues.  That is why "Wireless" is as much an art as it is a sceince.  Know what we did?  We did a study.  Of all of the AP's we have in 40+ geographically diverse hospitals, 100's or 1000's of clinics, and 10,000's of AP's.  In 90 days time, we found exactly 2 AP's that briefly detected DFS traffic causing a controlled transition.  Cisco, a major WiFi vendor, as well as many industry vendors, use a statistic that DFS accounts for way less than 2% (per network, and not WLAN) of wireless traffic.  And, the DFS transmissions are frequently brief.  So, unless you live directly by a military base or installation (I live by a number of them, and they are not using DFS frequently or at all), it's really something to be aware of.  It's something to be sure to make sure the regulations are followed, but otherwise, it's a moot point.  They're availible for use. (As is the 6GHz band that was litterally just approved today.)

SO, in closing...

1) Stop attacking people's position if yours is a weak one (at it was).

2) Know your industry, PLEASE!

3) Don't just rely on your own knowledge, ability to read, or your "like" programmer, inquire from someone that has "hands-on" time logged over many scenarios.

4) Play nicely with Hospital WiFi (it might just save your own life), and lastly:

DFS Channels 52, 56, 60, and 64 are ALL legal for ANY USE in the US, provided they backoff/change channel on detection of very specific signals.

(TP-Link  Please just update our firmware to enable these (both EAP 225v3 and 245v3) ... It is idiotic they aren't there, you're better than that.)  

Here is today's frequency band's (litterally today as 6 Ghz was approve, today).

I will conceed this is a vendor drawing, not official:

@forrest this would also be useful for me in the Philippines...

@forrest I can attest that Band 1 and Band 4 are not enough for customers such as myself, who operate their network in crowded, urban environments. It would open up a lot of available spectrum and reduce interference and improve network performance if TPLink were to enable DFS via firmware updates. My older Apple AirportExtreme 802.11ac router supports DFS and it always selects a DFS channel in the location I'm in. Yes, sometimes it has to change the channel it's using, but that never significantly disrupts the network.

@forrest Enough channels? There is no such thing as "enough channels". Consider an Omada campus installation with dozens of access points -- do you really think there can be "enough channels"? In the 5 GHz bands, the EAP225-Outdoor has exactly 4 (four) channels of 20 MHz bandwidth each. That's absolutely totally NOT enough! Let us use channels 116-140 (actually 144), it's legal in both the EU and the US and there are very good reasons to use them. I don't think there is a single wifi chip set in the world that would not support them, so it's just a software limitation and you can fix it. Please do so!

When is DFS coming?  This is crap.

Chrissi wrote

@forrest Enough channels? There is no such thing as "enough channels". Consider an Omada campus installation with dozens of access points -- do you really think there can be "enough channels"? In the 5 GHz bands, the EAP225-Outdoor has exactly 4 (four) channels of 20 MHz bandwidth each. That's absolutely totally NOT enough! Let us use channels 116-140 (actually 144), it's legal in both the EU and the US and there are very good reasons to use them. I don't think there is a single wifi chip set in the world that would not support them, so it's just a software limitation and you can fix it. Please do so!

@Chrissi 

2 things (not just @Chrissi , but the entire conversation, but I'll start with Chrissi):
There are still (amazingly) a ton of devices (primarily software based) that do not support UNII-2e (100-140).  We (the largest hospital system in the U.S., or one of) cannot use those channels because of so many devices that do not support them.  If they are not supported by a device, but we've deployed those channels, it appears like a blind/dead spot.  I am amazed at how many do not.  We have some devices that do not even use the DFS channels, not for the reasons of abrubtly leaving the channel, but because they don't want to spend the time "scannning" those channels.  Each channel takes roughly 100ms of a scan to see if it is a feasible successor.  Adding 4 channels is almost an additional half second of time each scan.  I don't agree with it, but the idea is out there and being used.

BUT....TP-LINK PLEASE GIVE US THE CHOICE to use what we want!  All my stuff supports it, my neighbors do not.  It would be great to have a nearly clean space just to my self.

As to the DFS channels - while it might be a pain to "abuptly exit" if radar is detected - it is less prolific than one would think.  We (one of the largest hospital systems in the US) did a bit of research across our systems to find out how many "DFS changes" we actually got.  We have to design and deploy all the AP's nation wide.  We found a total of 2 events in our logs (dating back several years) of DFS channel exit.  Just 2 (out of 10's of thousands of AP's across the company).

We decided using those channels with that few of "disruptions" was an acceptable risk.  Think of a 3-D building...if you have more than 8 AP's, you're likely going to have overlapping channels - remember, signal travels up and down as well as laterally.  To that point, we have found (in general) two things kill our WiFi the fastest 1) Coverage gaps (due to low density designs), 2) Co-Channel interference when we have more AP's than we should in an area, or they are not properly channel assigning.  AP deployment is an art.  You need the right number in the right places, at the right power.  Otherwise, it's just chaos hoping it will work.

TP-LINK - PLEASE, PLEASE, PLEASE enable the options for both UNII-2 (DFS channels 52-64) AND UNII-2e (100 - 144).  All are legal, usable by anyone channels.  Then WE can choose to enable or disable depending on our need/environment.