I recently had the pleasure of being schooled out in the wild about DFS events in a facility near an airport. For those that aren't familiar, DFS is a mandatory spectrum-sharing mechanism defined by the IEEE 802.11h standard that ensures wireless networks do not interfere with primary radar systems including weather radar, military radar, and aviation radar systems.
The frequency of DFS events observed at this facility is likely elevated due to the proximity of a regional airport located less than five miles from the site, as aviation radar systems are primary users of the 5GHz spectrum and operate continuously for air traffic control and navigation purposes.
The 802.11h standard defines three critical timing parameters that govern DFS behavior.
The Non-Occupancy Period requires that any channel on which radar has been detected must remain unused for a minimum of 30 minutes, ensuring adequate protection for radar systems.
The Channel Availability Check (CAC) mandates that access points must passively monitor any new DFS channel for 60 seconds before transmitting, scanning for existing radar activity.
Finally, the Channel Move Time specifies that once radar is detected, the access point must cease all transmissions and vacate the channel within 10 seconds maximum.
Figure 1. DFS Event Captured on Controller
Do you see that second highlighted line that says the current channel 116 was changed to channel 173?
The rra173/5 was the hint that I didn't get but channel 173 exists in the UNII 4 band of 5GHz and has been a thing for a couple years - I did not get that memo. Until last week, I thought the 5GHz world stopped at 165. Meanwhile, 31 minutes later it changes back to channel 116.
Figure 3. DFS Event Choosing 6GHz Channel for 12 Hours
This one evidently had clients associated to it which means the Non-Occupancy Period must now be 12 hours. This one picked channel 140 in 6GHz.
Because the controller picked channel 173 in 5GHz UNII 4 and channel 140 in 6GHz, this created a black hole of coverage because there is not one single device on the network that can use those channels. Just because you can doesn't mean you should. The customer had no idea this was happening, but it was one of many things wreaking havoc on their system.
The customer was told to change the ARM (Aruba) configuration to prioritize non-DFS channels in UNII 1 and UNII 3 and stop using all the UNII2e channels to avoid so many DFS events.
The lesson here is to pay attention and see if there are any DFS events on any controller with Wi-Fi 6 and 6E access points and make sure they either cannot use any of the channels in UNII 4 or 6GHz, or confirm that every device on the network can support those channels.
If you work in hospitals, the answer to that last bit will be no.
UPDATE: One of the things I love about LinkedIn is having a community of expertise to discuss findings and learn new things. I was very pleased to discover that DFS will never use a 6GHz radio because 6GHz doesn't require DFS. Staring at data and asking yourself "is it really doing that, I didn't know it could...?" I had the privilege of the David Coleman explaining that the rra140/6 is really just a typo bug in the controller. Sanity checks are critical and having a community full of individuals who have already been where you are is priceless!
Curious what gear you were using that allow UNII-4?
ReplyDelete