NOTE: this page is for archival only, see the note at the end of the page.

DFS

Overview

We will put in place here design ideas for a future mac80211 DFS implementation. This page is work in progress.

Dynamic Frequency Selection allows 5 GHz capable 802.11 devices to share spectrum with radar devices. Radars are used by airports, weather stations, and military. For example some weather stations use weather radars to help with directing airplanes to airports more accurately. Interference with radars then is carefully regulated by countries that make use of them as they share spectrum in the 5 GHz band.

The general idea behind how DFS works with 802.11 is master 802.11 devices must first monitor DFS channel for radar pulses for a period of time before it actually enables communication on it. Once it starts using that channel it must then commit to routinely check for radar pulses and if a pulse pattern is detected that matches a radar signal the master device must tell all connected clients it is switching channels and switch over to a new channel within a specific period of time. The master device must also ensure to not come back to that channel again for period of time after which it can white-list the channel and eventually use it again.

Software then is needed for:

  • Management of which channels have seen radar pulses recently / timers to clean them
  • Management of informing connected clients of switching channels
  • Algorithms to help identify the next best channel - think the requirement is to actually choose one randomly
  • Hardware radar detection

We need software to do all this.

DFS requirements world wide

DFS is currently a requirement in the US, EU, and Japan, but it seems some countries are starting to consider requiring DFS as well.

Concepts

  • Non Occupancy List (NOL): channels which we know have recent radar pulses and we cannot use
  • Channel Availibility Check (CAC) Time: amount of time we should sit idle on a channel checking for radar pulses before initiating 802.11 frames on

Pulse types

The different types of radar pulses are distinguished based on:

  • Pulse Repetition Frequency - PRF - EU uses this
  • Pulse Repetition Interval - PRI - FCC / JP uses this
  • Pulse width
  • Pulse burst length

FCC specification

FCC Short Pulse Radar Test Waveforms

Radar test signal

Pulse Width (µs)

PRI

Pulses per burst

Minimum % of successful detection

Number of Trials(Times)

1

1

1428

18

60%

30

2

1-5

150-230

23-29

60%

30

3

6-10

200-500

16-18

60%

30

4

11-20

200-500

12-16

60%

30

1-4

x

x

x

80%

120

FCC Long Pulse Radar Test Waveforms

Radar type

Pulse Width (µs)

Chirp width (MHz)

PRI

Number of pulses'

Minimum % of successful detection

Number of Trials(Times)

5

50-100

5-20

1000-2000

1-3

8-20

80%

30

Frequency Hopping Radar Test Waveforms

Radar type

Pulse Width (µs)

PRI

Pulses per hop

Hopping rate (MHz)

Hopping sequence Length (msec)

Minimum % of successful detection

Number of Trials(Times)

6

1

333

9

0.333

300

70%

30

ETSI specification

Radar test signal

Pulse Width (µs)

PRI (pps)

Pulses per burst

Minimum % of successful detection

1 - Fixed

1

750

15

60%

2 - Variable

1, 2, 5

200, 300, 500, 800, 1000

10

60%

3 - Variable

10, 15

200, 300, 500, 800, 1000

15

60 %

4 - Variable

1, 2, 5, 10, 15

1200, 1500, 1600

15

60%

5 - Variable

1, 2, 5, 10, 15

2300, 3000, 4000

25

60%

6 - Variable modulated

20, 30

2000, 3000, 40000

20

60 %

Parameter

EU

FCC

JP

CAC time

60ms (minimum)

?

?

Channel move time

10ms (maximum)

?

?

Channel closing time

260ms (maximum)

?

?

Interference detection threshold on master TX power ≥ 200mW

-64 dBm

?

?

Interference detection threshold on master TX power < 200mW

-62 dBm

?

?

Interference detection on slave TX power ≥ 200mW

-64 dBm

?

?

Interference detection on slave TX power < 200mW

Not required

?

?

Non-occupancy period

30 minutes (minimum)

30 minutes (minimum)

?

Japan / Telec specification

Japan Specific Radar Test Waveform (W53)

Radar type

Pulse Width (µs)

PRI(µs)

Number of pulses

Minimum % of successful detection

J1-1

1

1428

18

60%

J1-2

2.5

3846

18

60%

Japan Specific Radar Test Waveform (W56)

Radar type

Pulse Width (µs)

PRI(µs)

Number of pulses

Minimum % of successful detection

J2-1

0.5

1388

18

60%

J2-2

2

4000

18

60%

Development roadmap

DFS will be implemented first for AR9280 through ath9k, ath9k_hw TI will eventually review how to program DFS for their devices and list required cfg80211 knobs

== map countries to a DFS region bit =

This involves mapping each regulatory domain to one of the three DFS regions.

mcgrof will work on this.

get that info through cfg80211 to the driver

This involves parsing the regulatory information and sending the DFS region to the driver through cfg80211. With this the drivers should know what DFS region they belong to:

  • FCC
  • ETSI
  • JP

We need to query as many regulatory experts as possible to find out if we have other regions or what this pictures will look like 10 years from now. By the time we get done with this we should be able to start requesting for DFS parameters to eventually program them into hardware.

mcgrof will work on this.

Where do we stuff DFS parameters for each region

One idea is to use the request_firmware() API as it is expected these parameters will be region and chipset specific. This requires a good review of all chipsets and with priority on the ones who have vendors or we have documentation for that we want to support in existing drivers. Today this means Atheros hardware and TI hardware. Atheros will also have check with their mobile drivers (Vipin, Len).

Program hw DFS parameters

ath9k_hw already has some knobs for this, Felix already submitted some of these changes upstream. Most of the work required here will take place on ath9k.

DFS events

Most of the work here will involve hooking things up for mac80211 / cfg80211 / nl80211. This will consists of receiving DFS events from the driver for radar detection, keeping the NOL list, sending it to hostapd, choosing a random channel, and sending CSA to STAs.

Weekly meetings

We will meet Tuesday at 9am PST on irc.freenode.net on #linux-wireless

2010-12-14

  • Review the different basic concepts of DFS and willing participants of implementation. So far we have three companies:
    • Atheros
    • TI
    • saxnet.de
    • neratec.com
  • Review the different software components required and where the components are going to go upstream (hostapd/mac80211).

This is a static dump of the wiki, taken after locking it in January 2015. The new wiki is at https://wireless.wiki.kernel.org/.
versions of this page: last, v39, v38, v37, v36, v35, v34, v33, v32, v31, v30, v29, v28, v27, v26, v25, v24, v23, v22, v21, v20, v19, v18, v17, v16, v15, v14, v13, v12, v11, v10, v9, v8, v7, v6, v5, v4, v3, v2, v1