Showing posts with label DFS. Show all posts
Showing posts with label DFS. Show all posts

Sunday, 27 May 2018

The 5GHz “Problem” For Wi-Fi Networks: DFS

Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS.


Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (paid-for) licence to operate radio equipment.

All wireless services are generally subject to a range of enforceable technical restrictions to ensure they operate in a manner that will minimize interference to other wireless services. This may include restrictions on parameters such as RF transmit power levels and limiting the spectral characteristics of transmitted signals (e.g. channel widths used, spectral masks etc.).

Even though they may be licence-exempt, Wi-Fi networks are still subject to restrictions to minimize their impact on other wireless services and equipment in the same areas of spectrum used by WLANs.

One particular service that shares spectrum with wireless LANs is radar. Some types of radar installation operate in the 5GHz band that is used by Wi-Fi network. This means that they may use some of the same frequencies that are used for Wi-Fi networks. This doesn’t apply to all radar stations that have been deployed; there are many radar installations do not use 5GHz.

However, due to the coexistence of both radar and Wi-Fi networks in the same area of spectrum, the Wi-Fi standard (IEEE 802.11) was designed to incorporate a spectrum sharing mechanism on 5GHz to ensure that Wi-Fi networks do not operate on frequencies (hence causing interference) that are used by nearby radar stations. This mechanism is known as Dynamic Frequency Selection (DFS) and is designed to mitigate interference to 5GHz radar by WLANs.

How Does DFS Work?

DFS operation is as follows:

Channel Availability

Before an AP will use a channel that may be impacted by radar, it will perform a “Channel Availability Check” to check for radar signals on that channel. The AP will listen for 60 seconds for the presence of radar signals. If no radar is detected, then the channel is designated as being an “Available Channel”.

When powering up an AP that uses a DFS channel, you will see that the 2.4GHz radio becomes available as soon as the AP has completed its boot sequence, but the 5Ghz radio may not available for another minute. This is due to the AP performing its channel availability check, if the AP is trying to use a DFS-impacted 5GHz channel.

In some regions, where channels 120 – 128 are allowed for use by Wi-Fi networks, there may be an increased channel availability check of 10 minutes. This means that the 5GHz radio is not available until 10 minutes after the access point has booted up. This extended checking period is due to weather radar restrictions on those channels.

In-Service Monitoring

Once an AP is operating on a DFS channel, it has to monitor for the presence of radar signals appearing on that channel. This is known as “In-Service Monitoring”.

The AP must continuously monitor its channel for the presence of radar signals.
Channel Shutdown

If a radar signal is detected, then the AP must cease transmissions on the channel within the “Channel Move Time”, which is 10 seconds in the EU/UK.

At the end of this period, the AP will have ceased transmissions and moved to a new channel.

Prior to moving channels, some WLAN solutions may provide a “Channel Switch Announcement” 802.11 frame to connected clients to advise them which channel the AP will be moving to. Support for this on both WLAN infrastructure and client equipment seems to be optional from my own observations and should not be relied upon as a reliable method for clients to find the AP on its new channel.

Experience shows that there are variations between WLAN solutions around which channels an AP will choose to move to when radar is detected. In some solutions, APs that detect radar will move to channel 36 exclusively. In other solutions, APs will choose to move to any of the available non-DFS channels. Some will jump to any available 5GHz channel they find (DFS or non-DFS). Behaviour in this area seems to be inconsistent and is not defined within the 802.11 standard.

Non-Occupancy Period

Once radar has been detected on a channel, then the “Non-Occupancy Period” begins. This is a 30-minute period in which no further transmissions will be made by the AP on the affected channel.

At the end of the 30-minute period, most APs will attempt to return to their original channel, subject to a channel availability check. (Again behaviour in this area varies between vendors)

Radar Signal Characteristics

Radar signals themselves are very short duration pulses of Radio Frequency energy. In contrast to WLAN signals, they have no specific framing format, which makes their identification quite challenging.

Looking at the testing methodology in ETSI EN 301 893 V2.1.1 (Annex D), test pulses sent to WLAN gear under test may vary between 0.5 and 30 micro-seconds and be subject to a variety of test patterns. The table below is an extract from the document:

(Credit: Extract from ETSI standard: EN 301 893 V2.1.1)

The diagram below shows a single burst pattern that may be used to test WLAN devices:

(Credit: Extract from ETSI standard: EN 301 893 V2.1.1)

There is little doubt, that compared to the detection of well-structured, longer duration 802.11 frames, WLAN equipment has been set quite a challenge in reliably detecting radar signals (which can lead to annoying side-effects, discussed later).

Are All 5GHz Channels Subject to DFS?

No, not all channels in the 5GHz band are subject to DFS. The channels that are exempt vary from country to country, as dictated by local regulations. In the UK/EU, channels 36, 40, 44 and 48 are not subject to DFS. However, all remaining channels are subject to DFS. In the USA, channels 36 - 48, together with 149 - 165 are exempt from DFS operation, with all remaining channels requiring DFS operation. (Check your local spectrum regulation authority for the latest information for your country).

Channels that are not subject to DFS operate without having to perform any radar checks. Therefore, they are not subject to any disruptions from local radar equipment (or any other sources RF interference that may cause false-positive detection)

What Happens To Clients During a DFS Event?

Devices that are subject to DFS checks are divided in to two roles: master and slave. It is the role of the master device to advise slave devices when radar has been detected and that a channel shutdown is required.  In WLANs, the access point is usually the master device, with the associated clients designated as slaves.

Once radar is detected, it is the duty of the master device to advise the slaves that a channel change is imminent via a channel switch announcement message. This message should advise slaves (clients) which channel the AP intends to move to.

What Is The Impact on Client Applications During a DFS Event?

Once a radar signal has been detected, the impact on clients due to the required channel change is “variable”.

WLAN systems may or may not send a channel switch announcement (CSA). If no announcement is received by a client (or is lost in transit), then the client will be forced to go through its probing process to find a suitable BSSID with which to associate. Depending on the network configuration and client capabilities (e.g. 802.11k/v/r), the time to re-associate with the network will vary. Note that even if a CSA is received, a client may still choose to go through its own AP discovery process based on probing or 80.211k information it has received.

Once the move to a new channel has been completed, there will then be the usual delays in the resumption of application data flow due to processes such network access authentication and DHCP exchanges – these will again vary with network configuration.

Whatever the configuration of the WLAN and client capabilities, the move to a new channel will not be without some connectivity impact. This impact may be unnoticeable for users who are using non-real-time applications (e.g. mail, web browsing), but will certainly have an impact on latency sensitive, real-time applications (e.g. voice, video).

What Causes False DFS Detection?

Although DFS is, in theory, a great idea to protect systems that share the 5GHz spectrum, it has a major pitfall: false positives.

Detecting a radar signal signature is quite a tricky business. Due to the variety of radar signatures that may be detected, together with the short-duration nature of radar signals, false positive events may be quite frequent in some WLAN systems.

A false positive means that an AP is fooled into thinking that a radar signal is present by a non-radar RF signal. This causes a channel change, when one is not needed. This obviously leads to un-necessary WLAN disruption, that has varying impact on clients, depending on the applications in-use.

Theories around the exact cause of false positive events seem to be numerous, depending on who you speak with. I’ve heard the following possible causes cited:

  •  Transient conditions due to high densities of clients
  •  Bad client drivers causing short term RF spikes
  •  Co-channel interference from distant APs on the same channel
  •  Local non-Wi-Fi equipment interference

Whatever the cause, the false positives observed generally tend to be observed during times of increased user presence (i.e. they seem more likely during “office hours” as user numbers & activity increase).

How Do I Detect DFS Events?

To find out if your network is being impacted by DFS events, you need to check the trap logs or syslog messages from your wireless system.

All systems should report when a radar hit has been detected. This will generally be recorded in the logs of the AP, wireless controller or management system. Often this will be forwarded as an SNMP trap to a management system or perhaps as a syslog message to your logging server.
If you have log analysis and trending capabilities, it is well worth monitoring radar events to look for patterns of behaviour (e.g. particular sites, event times and channels)

What Do “Real” DFS Events Look Like?

You might be scratching your head at this point wondering how you can tell the difference between “real” DFS events and false positives.

In my experience, DFS events caused by genuine radar systems tend to be limited to a specific subset of channels on the 5GHz band. For instance, you may check your system logs and find that in a particular building, only channels 116 and 120 (for example) are reporting DFS events (i.e. radar hits). Also, these tend to be at a consistent rata throughout the day.

In contrast, false positives tend to be spread across a very wide portion of the 5GHz band and will vary in frequency throughout the day. They also generally fall to very low levels outside of office hours and at weekend (depending on the working patterns of your particular establishment).

How Can I Mitigate DFS Events on a Wi-Fi Network?

There are a few options available to try to mitigate the impact of DFS events on a WLAN:
  1. For genuine radar events that are impacting a subset of the 5GHz band, simply exclude the impacted channels from any channel planning. If using static channel planning, then avoid using affected channels. If using an auto-RF mechanism (i.e. automated channel planning), then exclude the affected channels from those available to the configuration of the auto-RF process
  2. Trying to mitigate false positives is a little more tricky. Options include:
    1. If you have sufficient non-DFS channels, do not use DFS channels at all in channel planning. This option is very much dependent on WLAN capacity requirements and the local regulatory domain in which the network operates
    2. Work with the WLAN vendor to find out if they have a more recent version of operating code that is less susceptible to DFS false positives. I have seen this approach used many times, with varying degrees of success
    3. Work with a vendor or VAR to try to identify any local sources of interference that may create false positives. Occasionally, it may be possible to identify a particular client type or item of non-Wi-Fi equipment that is causing false positives, If you have a support contract, assistance from a suitably qualified WLAN expert armed with a spectrum analyser and able to perform log analysis may be invaluable in tracking down offenders.
    4. If you vendor is unable to fix the issue, it may be worth trying an alternative vendor. Though this may seem extreme, I have seen huge variations between vendors and their susceptibility to DFS false positives. A limited-scope proof of concept costs little to deploy and can provide amazing leverage with your existing vendor…

What will be the impact of DFS on my Wi-Fi Network?

The impact of DFS events on your network (both “real” & false positive) will always be the same: a DFS event is detected and an AP will change channels. This will also cause the associated wireless clients to change channels.

The actual impact on the end-user will vary depending on what they are doing on their client.

Many applications that aren’t latency sensitive will simply continue with little obvious impact on service. If a user is browsing the web, sending email or even streaming a video file (assuming some buffering), they will generally not notice their client jump between channels as their associated AP changes channels. This assumes your WLAN is correctly designed so that clients have viable alternative APs available.

If clients are using real-time, latency sensitive applications, then they are much more likely to observe some sort of negative impact. The transition to a new channel is likely to be quite long (in WLAN terms). It will vary depending on the required operations (e.g. channel probing, 802.1X exchanges, DHCP exchanges etc.), but will generally be long enough to have an impact of real-time applications such a voice and real-time video. The use of enhanced WLAN features such as 802.11r/k may help to ensure that clients can significantly speed up the AP selection and roaming process.

These considerations provide a useful indication as to whether DFS events are going to provide problems on your WLAN and whether you should consider the impact of DFS on your wireless network.


In many Enterprise wireless WLANs, there will generally be a requirement to use as many unique 5GHz channels as possible. This provides opportunities to mitigate co-channel interference and increase capacity through the use of channel bonding (if required).

However, understanding and verifying the impact (if any) of radar detection is important to ensure the requirements of our WLAN design are not compromised.


Here are some other great sources of information you might like to look at for more information about DFS:

Sunday, 20 May 2018

Updated White Paper on Licence-Exempt Spectrum in the 5GHz band for Wireless LANs in the UK

For the past few years, I've maintained a white paper on the use of the 5GHz spectrum for Wi-Fi networks here in the UK. As Wi-Fi text books tend to focus on the spectrum available in the USA, I put this document together to clarify how 5GHz spectrum may be used in the UK.

Following the release of a Voluntary National Specification document by Ofcom in August 2017 (VNS 2030/8/3), additional channels became available for use in the UK on 5GHz.

As we now have additional spectrum, it's time for an update to my white paper to detail the new spectrum that is available.

Prior to updating the white paper, I published a summary sheet that shows the new spectrum allocation. This can be obtained obtain from my previous blog article: UK 5GHz WLAN Spectrum Allocation (August 2017) (this is definitely one to print off and laminate).

I have now completed my updates to the white paper, which I am pleased to share with you now. Note that in addition to adding the new spectrum details, I have added a few other topics around the use of 5GHz and the unique challenges that it presents. I'd recommend taking a look at my description of how DFS operates in Appendix 2, and have a play with the Opera weather radar location tool shown in Appendix 3.

I hope you find the update useful and informative.


Tuesday, 27 January 2015

5GHz in the UK White Paper (Version 2)

[Note: The information in this white paper has been superseded. Check out my updated white paper:]

I decided it was time to update my white paper detailing the use of the 5GHz band here in the UK for wireless LANs.

I've tidied a few things up and added some information around 802.11ac channel planning within the constraints of UK 5GHz spectrum.

You can download the whitepaper from here:

  • PDF download
  • Google docs
  • Scribd

Tuesday, 13 May 2014

802.11ac & 5GHz: The Emperors New Clothes? - Part 1

The WiFi industry has been buzzing with excitement around the recently ratified 802.11ac standard. The promise of higher speeds, lower battery usage for mobile devices and the enforced move to the higher-capacity 5GHz band is enough to put a smile on the face of even the most curmudgeonly members of the WiFi fraternity.

I've been giving some serious thought recently to what the best approaches might be in terms of designing and deploying 802.11ac networks. There are obviously challenges as we move through the transition from legacy standards to the shiny new 802.11ac standard: 
  • new cabling requirements for higher uplink speeds to 802.11ac APs
  • Increased power requirements for our 802.11ac APs
  • accommodating the mix of new and legacy clients
  • figuring out exactly how we plan our channels for the brave new world of 802.11ac

The 802.11ac standard mandates that access points and clients using the new standard will only be supported on the 5GHz band, which is great news...right? We can still use our legacy 802.11g and 802.11n standards on good old 2.4GHz, but 802.11ac is 5GHz only. 

The 5GHz band offers us far more channels that the noisy cesspit which is the 2.4GHz band. It provides around 20+ channels (depending on where you are in the world), compared to the pitiful 3 useable channels of the 2.4GHz band. 5Ghz is currently used by fewer (non-WiFi) devices, so has less noise and interference than it's noisy cousin down on 2.4GHz. As we have more channels to play with on 5GHz, we can also start bonding them together to get 40MHz (double-width) and 80MHz (quad-width) channels to get even faster throughput for our 802.11ac clients.

On the face of it, we are in easy-street on 5GHz compared to 2.4GHz. Faster speeds (for faster transfers and better spectral efficiency), together with lower noise and more channels for easier planning and higher capacity.

But, not so fast. 5GHz has a few little 'gotchas'' that maybe the marketing boys didn't tell you about...


When the 802.11 standards were created and the 2.4GHz and 5GHz bands were allocated for use by WiFi traffic, there was some difficulty surrounding existing services that already used the 5GHz band. Particularly in Europe, there was the issue of weather and airport radar systems that already used parts of the 5GHz band. Though this was initially confined to Europe, it is now a consideration in many areas of the world.

Unless protection mechanisms were put in place, there was a danger that a WiFi network on specific channels within the 5GHz band could interfere with these radar systems.  Therefore, it was decided to implement a protection system to guard against radar system interference: Dynamic Frequency Selection (DFS).

DFS ensures that if a WiFi network detects an RF signature that looks like a radar pulse on the channel on which an access point is operating, it will cease all transmissions on that channel and move to a new channel. This has a disruptive effect on associated wireless clients, who will also need to switch channels. This might cause a relatively short 'blip' for clients not carrying time-sensitive data (e.g. for simple web browsing, files transfers etc.). But, for latency sensitive traffic (e.g. voice & video), this channel switch will have significant effects, such as dropping established voice calls over WiFi.

To find out more about DFS, take a look at a great series of articles from Jennifer Minella at Network Computing.

Fortunately, the DFS mechanism does not apply to all channels within the 5GHz band. In many parts of the world, the first 4 channels of the 5GHz band for WiFi may operate without being subject to DFS (non-DFS channels). These are channels 36,40,44,48. This means we can confidently use these channels without any fear of service interruption due to radar detection events. (Note that in the USA, there are 9 non-DFS channels)

Unless you are near an obvious radar source (e.g. an airport), it may be difficult to determine if your network is going to affected by radar. Often, the first time this becomes apparent is when a wireless network has been deployed and radar blasts are reported by the wireless network. Due to the nature of the radar pulse width, radar systems tend not to detected during a wireless survey, even if using a spectrum analyser.

In addition to detection of genuine radar systems, there may also occasionally be local interference from non-radar systems which inadvertently trigger the DFS mechanism. This is due to the generation of a pulse of RF energy that looks similar to a radar pulse.

In the real world, reports from other wireless professionals I've spoken to suggest that actual radar events affecting WiFi networks tend to be rare. However, in very high density deployments, the incidence of false-positives from mis-behaving clients is not unusual.

In summary, although radar detection is infrequent, it may be unpredictable and may cause significant disruption when using a WiFi system on 5GHz near a radar source. The effects of DFS may be completely mitigated by using only non-DFS channels, but this will reduce our usable channels from our original 20+ channels down to just four (OK, maybe 9 if you're in the USA...).

In part 2 of this article series, we'll look at more restrictions impacting the use of the 5GHz band and 802.11ac.

Tuesday, 7 May 2013

5GHz - 3 Missing Channels in Europe

Last year, I put up a posting which highlighted the fact that here in the UK (and I suspect all of Europe) we often have 3 channels missing from our allocation of unlicensed channels in the 5GHz band.  Looking at many manufacturer data sheets, channels 120, 124 and 128 are often shown as not being supported. This is despite the fact that they are allocated for use by local regulatory bodies (OFCOM here in the UK).

I recently posted a question about this on a partner forum of a major WiFi vendor that I deal with and finally got a definitive answer on this. In this post, I'll share my findings.

The reason that these particular channels (120 - 128) receive special treatment is that they occupy frequencies that are used by weather radar systems. WiFi systems have to be very careful not to interfere with those systems during their normal operation. Therefore, WiFi equipment has some additional checks and tests imposed on it to make sure that it does not inadvertently cause any interference.

In the ETSI region (Europe), the standard EN 301 893 dictates that any channels operating in the frequency range 5.6GHz to 5.65GHz must wait an additional period of time before using a channel. For most DFS-affected channels, a WiFi device must wait for 60 seconds to verify that no radar is present before commencing operation. However, on the channels in the 5.6GHz to 5.65GHz range, the device (i.e. Access Point) must wait 10 minutes! The table below (taken from Annex D of the standard) details this requirement:

Due to this 10 minute wait period, it seems that many manufacturers have chosen to withdraw support for the channels affected, which are 120, 124 and 128. This makes perfect sense now - who would want an AP to be allocated to a channel and then wait for 10 minutes before it can use it..?

I'm pleased to have finally got to the bottom of this particular grey area, but it seems like bad news for WiFi usage in Europe generally. With the anticipated sharp uptake in 5GHz usage around the globe, as 802.11ac starts to roll out, the loss of 3 channels is quite a chunk of spectrum to lose.

In the UK we have 19 unlicensed channels to use on 5GHz for WiFi. Losing 3 of those channels is a 15% loss in spectrum. This is at a time when we really need to be increasing spectrum availability to cope with the additional channel bonding opportunities that  802.11ac provides to increase WiFi speeds.

Hmmm....let's hope some additional spectrum turns up in the near future.

Update: I've now created a white paper which details 5GHz usage for WiFi in the UK. Find it here

Monday, 8 October 2012

The Missing Channels on 5GHz in the UK : 120, 124, 128

In my recent article : 'WiFi Channels On The 5GHz Band In The UK', I noted that although the 5GHz channels 120, 124 and 128 are unlicensed channels available for use by WiFi equipment in the UK, it appears that a few major WiFi equipment manufacturers do not allow their use (in the UK or EU).

I spoke with a major vendor representative today who advised me that the 3 channels are available for use, but that an update to the ETSI standard 301 893 v1.5.1 introduced some detection techniques for various military equipment used in the EU. However, many access points that were already manufactured (or using chip-sets that had already been manufactured) did not support the granularity of detection that is required for this equipment. So, it was decided to simply disable support for the affected channels.

Apparently, later APs which use an updated chip-set will not be subject to the same limitations (once a few firmware updates are sorted out).

I had a poke about in the standard to see if I could track down the offending addition, but there didn't seem to be a "what's new" or "change log" that accompanies the document. All I could find was the following note in the ETSI work program item that accompanies the standard:

"Include Staggered PRF radar test signals across the 5 250 MHz to 5 725 MHz band. Include narrow pulse widths for the radar test signals (0,8 ┬Ás) across the 5 250 MHz to 5 725 MHz band. Address noise calibration scan ("zero check") in the 5 600 MHz to 5 650 MHz band."

Perhaps the "zero check" scan that is referenced is the offending item that caused the issue - it certainly falls within the range of the channels that have been disabled.

Although this doesn't provide a comprehensive answer, it at least suggests why we have lost a few channels on 5GHz here in the EU (at least for the moment, anyhow).

UPDATE: I now have an answer on this! Check out my later article here.

Update: I've now created a white paper which details 5GHz usage for WiFi in the UK. Find it here