- Posted by IPTel Solutions
- On March 2, 2019
- 0 Comments
It sounds like a bit of a stretch for most people that WiFi would have an issue with Radar. Microwave ovens are a pretty well known interferer with WiFi in the 2.4GHz spectrum (they generate alerts for interferers, so we know they’re there!)
The bands in which WiFi operate are known as unlicensed spectrum. This is different in each country that you operate – you have to tell your controller and APs in which domain they operate and the relevant channels are made available.
While the 2.4GHz band tends to have a lot more interferers than the 5GHz band (in addition to those Microwave ovens, there’s Bluetooth headsets, some types of lights and so on), the 5GHz band is also susceptible.
Typically you don’t see too many interferers – 5GHz is the preferred band for the reason that it generally has less interferences from outside sources than the 2.4GHz band.
We have though seen things like Mobile phone repeaters that use 5GHz as a backhaul between repeaters, channel hopping and managing to obliterate several channels in the process. The one big one – if your site is near a port of an airport – is radar. You may have seen a large radome (tallish building with a giant golf ball on top) near such facilities and it turns out that this can be operating in some of the 5GHz spectrum.
The DFS process is all about detecting when a radar facility is nearby and ensuring that any WiFi devices can’t interfere.
The Access Points spend some of their time off-channel scanning and if they hear radar (and they area DFS channel), they will decide to go off channel, for a period of 45 – 60 seconds. This is a programmed feature to allow WiFi to make use of the same spectrum as a radar, but try not to either interfere with it – or be interfered by it. Unfortunately, the process is not exactly seamless, requiring APs to go offline and mark channels as non-useable.
During the time the APs are offline, they continue to listen and will then return themselves to service on a non-conflicting channel, having marked the original channel as unavailable for use for the time being.
That’s the theory – what does that look like in practice: If you’re using a WiFi phone and you roam onto that AP, it will just disappear and your phone will be forced to make a roaming decision. This can result in up to a 5 second silence (although it can be shorter), while the phone selects the next best AP and re-authenticates to it.
The secondary effect though is that the actual best AP is now offline for the next minute or so, so you will be connected to a secondary AP that’s not as good – and if that’s too far away, you might get further dropouts.
Here’s some output from an AP that was being affected by the DFS – you’ve got the very distinctive output highlighted to show the process occurring – the AP has heard the channel in use and then goes offline:
*Aug 15 04:52:08.499: %DOT11-6-DFS_TRIGGERED: DFS: triggered on frequency 5260 MHz
*Aug 15 04:52:09.236: %LINK-6-UPDOWN: Interface Dot11Radio1, changed state to down
*Aug 15 04:52:09.292: %LINK-5-CHANGED: Interface Dot11Radio1, changed state to reset
*Aug 18 19:00:13.940: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to down
*Aug 18 19:00:13.978: %DOT11-6-DFS_SCAN_START: DFS: Scanning frequency 5320 MHz for 60 seconds.
*Aug 18 19:00:13.981: %LINK-6-UPDOWN: Interface Dot11Radio1, changed state to up
*Aug 18 19:00:14.981: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to up
If you want to use the UNI II band DFS channels, don’t have your site near an airport! If you have newer APs, you’ll find you can use the UNI II Extended band, which will allow some additional channels to be used – which depending on the region you’re in, might help.
For the most part using the UNI I and UNIIII bands would see the installation not have any issues with DFS. Alternatively, if you’re only using data functionality (and not voice), you can most likely get away with using DFS and the effect not get noticed.