Источник: 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 обязательно применяется в США, ЕС и Японии. По-видимому, некоторые другие страны также начинают рассматривать введение этого требования.
- Non-Occupancy List (NOL, список недоступных каналов): каналы, на которых, как нам известно, недавно обнаруживались радарные импульсы и которые поэтому нельзя использовать.
- Channel Availability Check (CAC, проверка доступности канала): время, в течение которого необходимо оставаться на канале без передачи кадров 802.11 и проверять наличие радарных импульсов.
Различные типы радарных импульсов различают по следующим характеристикам:
- частота повторения импульсов (Pulse Repetition Frequency, PRF) — используется в ЕС;
- интервал повторения импульсов (Pulse Repetition Interval, PRI) — используется FCC и в Японии;
- длительность импульса;
- продолжительность пачки импульсов.
Примечание: PRI и PRF эквивалентны, поскольку PRI = 1 / PRF.
| Испытательный сигнал радара | Длительность импульса (мкс) | 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 |
| Тип радара | Длительность импульса (мкс) | Ширина ЛЧМ-сигнала (МГц) | PRI | Число импульсов | Минимальная доля успешных обнаружений | Число испытаний |
|---|---|---|---|---|---|---|
| 5 | 50–100 | 5–20 | 1000–2000 | 1–3 | 8–20 | 80% |
В исходной статье заголовки и значения последних столбцов этой таблицы не согласуются друг с другом. Здесь сохранены их исходные расположение и значения.
| Тип радара | Длительность импульса (мкс) | PRI | Импульсов на одну перестройку | Скорость перестройки (МГц) | Длина последовательности перестроек (мс) | Минимальная доля успешных обнаружений | Число испытаний |
|---|---|---|---|---|---|---|---|
| 6 | 1 | 333 | 9 | 0.333 | 300 | 70% | 30 |
Спецификации ETSI версий 1.4.1 и 1.5.1 перенесены на отдельную страницу ETSI.
| Тип радара | Длительность импульса (мкс) | PRI (мкс) | Число импульсов | Минимальная доля успешных обнаружений |
|---|---|---|---|---|
| J1-1 | 1 | 1428 | 18 | 60% |
| J1-2 | 2.5 | 3846 | 18 | 60% |
| Тип радара | Длительность импульса (мкс) | PRI (мкс) | Число импульсов | Минимальная доля успешных обнаружений |
|---|---|---|---|---|
| J2-1 | 0.5 | 1388 | 18 | 60% |
| J2-2 | 2 | 4000 | 18 | 60% |
Сначала DFS будет реализован для AR9280 посредством ath9k и ath9k_hw. Позднее TI рассмотрит способы программирования DFS для своих устройств и перечислит необходимые параметры cfg80211.
Для этого необходимо сопоставить каждый регуляторный домен с одним из трёх регионов DFS.
Опубликованные патчи: обсуждение в списке рассылки linux-wireless.
Для этого нужно разобрать регуляторную информацию и передать регион DFS драйверу через cfg80211. Благодаря этому драйверы должны знать, к какому региону DFS они относятся:
- FCC;
- ETSI;
- JP.
Необходимо опросить как можно больше специалистов по регуляторным требованиям, чтобы выяснить, существуют ли другие регионы и как эта схема будет выглядеть через десять лет. После завершения этой работы можно будет начать запрашивать параметры DFS, чтобы впоследствии запрограммировать их в оборудовании.
Опубликованные патчи: обсуждение в списке рассылки linux-wireless.
Один из вариантов — использовать API request_firmware(), поскольку предполагается, что эти параметры будут зависеть от региона и набора микросхем. Для этого необходимо тщательно изучить все наборы микросхем, уделяя первоочередное внимание тем, для которых есть поддержка производителя или документация и которые планируется поддерживать в существующих драйверах. На данный момент это оборудование Atheros и TI. Atheros также должна будет проверить свои мобильные драйверы (Vipin, Len).
В ath9k_hw уже есть некоторые средства настройки. Felix уже отправил часть этих изменений в основную ветку. Большая часть необходимой здесь работы будет выполняться в ath9k.
Большая часть работы здесь будет связана с объединением 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
Теперь они назначаются только по мере необходимости.
Журнал IRC: dfs-2010-12-14.txt (ссылка из исходной статьи сейчас недоступна).
- Обзор основных понятий DFS и списка желающих участвовать в реализации. На тот момент это были следующие компании:
- Atheros;
- TI;
- saxnet.de;
- neratec.com.
- Обзор необходимых программных компонентов и определение того, в какие вышестоящие проекты они войдут (
hostapd/mac80211).
Слайды о DFS, представленные на Linux Wireless Summit в Ванкувере в 2011 году: Vancouver2011-Slides-DFS.pdf (ссылка из исходной статьи сейчас недоступна).