Skip to content

Latest commit

 

History

History
193 lines (121 loc) · 18.9 KB

dfs_dynamic_frequency_selection.md

File metadata and controls

193 lines (121 loc) · 18.9 KB

DFS (динамический выбор частоты)

Источник: DFS (Dynamic Frequency Selection)

Связанные разделы исходной документации:

Обзор

Здесь будут собраны идеи по проектированию будущей реализации DFS для mac80211. Работа над этой страницей продолжается.

Динамический выбор частоты (Dynamic Frequency Selection, DFS) позволяет устройствам 802.11, способным работать в диапазоне 5 ГГц, совместно использовать спектр с радиолокационными системами. Радары используются аэропортами, метеорологическими станциями и вооружёнными силами. Например, некоторые метеостанции применяют погодные радары, помогающие точнее направлять самолёты к аэропортам. Поскольку радары и беспроводные устройства совместно используют диапазон 5 ГГц, страны, в которых работают такие радары, тщательно регулируют допустимые помехи.

Общий принцип работы DFS в 802.11 заключается в следующем. Прежде чем разрешить связь на канале DFS, ведущее устройство 802.11 должно в течение определённого времени отслеживать на нём радарные импульсы. Начав использовать канал, устройство обязано регулярно продолжать такую проверку. Если обнаруженная последовательность импульсов соответствует сигналу радара, ведущее устройство должно уведомить всех подключённых клиентов о смене канала и перейти на новый канал за установленное время. После этого оно не должно возвращаться на прежний канал в течение заданного периода. По его окончании канал можно снова внести в список разрешённых и со временем использовать повторно.

Для этого программное обеспечение должно обеспечивать:

  • учёт каналов, на которых недавно обнаруживались радарные импульсы, и таймеров для их последующей очистки;
  • уведомление подключённых клиентов о смене канала;
  • алгоритмы выбора следующего подходящего канала — предположительно, по требованиям канал необходимо выбирать случайно;
  • аппаратное обнаружение радара. Для управления всеми этими действиями необходимо программное обеспечение.

Высокоуровневая архитектура

Предлагаемая архитектура программного обеспечения должна позволить использовать как можно больше общего кода с различным оборудованием.

wpa_supplicant (применение правил регуляторного домена) / hostapd (выполнение таких действий, как смена канала?) — пользовательское пространство:

* || cfg80211 (в основном передаёт команды вверх и вниз)
  * || mac80211 (в основном передаёт команды вверх и вниз)
    * || микропрограмма TI (обнаружение радара), или драйвер ath9k
         (обнаружение радара), или другое оборудование

Необходимо определить общий API между низкоуровневой микропрограммой или драйвером и остальной частью стека. Может ли кто-нибудь это задокументировать?

Здесь также пригодилось бы более подробное описание доработок кода и дополнительных функций, необходимых каждому из показанных выше основных компонентов.

Требования DFS в разных странах

В настоящее время DFS обязательно применяется в США, ЕС и Японии. По-видимому, некоторые другие страны также начинают рассматривать введение этого требования.

Основные понятия

  • Non-Occupancy List (NOL, список недоступных каналов): каналы, на которых, как нам известно, недавно обнаруживались радарные импульсы и которые поэтому нельзя использовать.
  • Channel Availability Check (CAC, проверка доступности канала): время, в течение которого необходимо оставаться на канале без передачи кадров 802.11 и проверять наличие радарных импульсов.

Типы импульсов

Различные типы радарных импульсов различают по следующим характеристикам:

  • частота повторения импульсов (Pulse Repetition Frequency, PRF) — используется в ЕС;
  • интервал повторения импульсов (Pulse Repetition Interval, PRI) — используется FCC и в Японии;
  • длительность импульса;
  • продолжительность пачки импульсов.

Примечание: PRI и PRF эквивалентны, поскольку PRI = 1 / PRF.

Спецификация FCC

Испытательные сигналы радаров с короткими импульсами по FCC

Испытательный сигнал радара Длительность импульса (мкс) PRI Импульсов в пачке Минимальная доля успешных обнаружений Число испытаний
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

Тип радара Длительность импульса (мкс) Ширина ЛЧМ-сигнала (МГц) PRI Число импульсов Минимальная доля успешных обнаружений Число испытаний
5 50–100 5–20 1000–2000 1–3 8–20 80%

В исходной статье заголовки и значения последних столбцов этой таблицы не согласуются друг с другом. Здесь сохранены их исходные расположение и значения.

Испытательные сигналы радаров с перестройкой частоты

Тип радара Длительность импульса (мкс) PRI Импульсов на одну перестройку Скорость перестройки (МГц) Длина последовательности перестроек (мс) Минимальная доля успешных обнаружений Число испытаний
6 1 333 9 0.333 300 70% 30

Спецификация ETSI

Спецификации ETSI версий 1.4.1 и 1.5.1 перенесены на отдельную страницу ETSI.

Спецификация Japan / Telec

Японский испытательный сигнал радара W53

Тип радара Длительность импульса (мкс) PRI (мкс) Число импульсов Минимальная доля успешных обнаружений
J1-1 1 1428 18 60%
J1-2 2.5 3846 18 60%

Японский испытательный сигнал радара W56

Тип радара Длительность импульса (мкс) PRI (мкс) Число импульсов Минимальная доля успешных обнаружений
J2-1 0.5 1388 18 60%
J2-2 2 4000 18 60%

Дорожная карта разработки

Сначала DFS будет реализован для AR9280 посредством ath9k и ath9k_hw. Позднее TI рассмотрит способы программирования DFS для своих устройств и перечислит необходимые параметры cfg80211.

Сопоставить страны с идентификатором региона DFS

Для этого необходимо сопоставить каждый регуляторный домен с одним из трёх регионов DFS.

Опубликованные патчи: обсуждение в списке рассылки linux-wireless.

Передать регион DFS драйверу через cfg80211

Для этого нужно разобрать регуляторную информацию и передать регион DFS драйверу через cfg80211. Благодаря этому драйверы должны знать, к какому региону DFS они относятся:

  • FCC;
  • ETSI;
  • JP.

Необходимо опросить как можно больше специалистов по регуляторным требованиям, чтобы выяснить, существуют ли другие регионы и как эта схема будет выглядеть через десять лет. После завершения этой работы можно будет начать запрашивать параметры DFS, чтобы впоследствии запрограммировать их в оборудовании.

Опубликованные патчи: обсуждение в списке рассылки linux-wireless.

Где хранить параметры DFS для каждого региона

Один из вариантов — использовать API request_firmware(), поскольку предполагается, что эти параметры будут зависеть от региона и набора микросхем. Для этого необходимо тщательно изучить все наборы микросхем, уделяя первоочередное внимание тем, для которых есть поддержка производителя или документация и которые планируется поддерживать в существующих драйверах. На данный момент это оборудование Atheros и TI. Atheros также должна будет проверить свои мобильные драйверы (Vipin, Len).

Программирование аппаратных параметров DFS

В ath9k_hw уже есть некоторые средства настройки. Felix уже отправил часть этих изменений в основную ветку. Большая часть необходимой здесь работы будет выполняться в ath9k.

События DFS

Большая часть работы здесь будет связана с объединением mac80211, cfg80211 и nl80211. Потребуется получать от драйвера события DFS при обнаружении радара, вести список NOL, передавать его hostapd, выбирать случайный канал и отправлять объявления о смене канала (Channel Switch Announcement, CSA) клиентским станциям (STA).

Предложенный на обсуждении DFS в IRC 18 января 2011 года вариант архитектуры:

Функция DFS Затрагиваемый код
Выбор канала Пользовательское пространство (hostapd)
CAC/NOL cfg80211
Обнаружение импульсов ath9k (драйвер)

Проверка соответствия требованиям

Проверка соответствия DFS требованиям занимает много времени и дорого стоит. Atheros планирует предоставить свою поддержку — команды тестирования и испытательные стенды — для периодической проверки соответствия эталонных платформ. Полное аппаратное тестирование такого уровня следует проводить при появлении новых или обновлённых микросхем и эталонных платформ, а также при изменении аппаратно-зависимых значений INI, влияющих на DFS.

Atheros предложила новый способ помочь разработчикам программного обеспечения тестировать DFS без дорогостоящих испытательных стендов и связанных с ними затрат времени и сил. Мы проведём на реальном оборудовании несколько испытаний различных типов радаров и запишем данные об импульсах в текстовый файл. Параметры в этом файле будут иметь определённый формат, позволяющий передавать их программному обеспечению в качестве входных данных. Пример формата дампа «данных об импульсах», передаваемого программе классификации радаров:

timestamp | rssi | width | ...

На высоком уровне программное обеспечение DFS сначала передаст данные об импульсах функции «классификатора радаров». Результатом её работы станет информация об обнаружении радара. Затем вся высокоуровневая логика будет обрабатывать эти данные и выполнять необходимые действия.

При таком подходе Atheros сможет выполнить все аппаратные испытания и записать данные в файлы-снимки, с которыми программное обеспечение в обычных условиях работало бы в реальном времени. После этого команды разработчиков смогут обрабатывать данные, настраивать программу, снова обрабатывать данные и повторять настройку до тех пор, пока всё не заработает правильно. После каждого изменения алгоритмов классификации радаров, обнаружения и проверки соответствия DFS разработчик сможет просто повторно прогнать файлы с данными об импульсах через программную логику и проверить успешность или неуспешность результата.

Еженедельные встречи

Раньше обсуждения проходили в IRC каждый вторник в 09:00 по тихоокеанскому времени:

server: irc.freenode.net
channel: #linux-wireless

Теперь они назначаются только по мере необходимости.

2010-12-14

Журнал IRC: dfs-2010-12-14.txt (ссылка из исходной статьи сейчас недоступна).

  • Обзор основных понятий DFS и списка желающих участвовать в реализации. На тот момент это были следующие компании:
    • Atheros;
    • TI;
    • saxnet.de;
    • neratec.com.
  • Обзор необходимых программных компонентов и определение того, в какие вышестоящие проекты они войдут (hostapd/mac80211).

Связанная информация

Слайды о DFS, представленные на Linux Wireless Summit в Ванкувере в 2011 году: Vancouver2011-Slides-DFS.pdf (ссылка из исходной статьи сейчас недоступна).


сеть ядро