Gluon: Запрос функции: используйте функции 802.11s для лучшего управления ячеистыми ссылками.

Я думаю, что большинство вариантов 11s не очень интересны для нас, так как мы принимаем все решения о маршрутизации в протоколе маршрутизации более высокого уровня и используем 11s только в качестве замены режима adhoc.

Некоторая работа по добавлению ссылок в черный список была проделана в freifunk-gluon/packages#118, но она не завершена.

Увеличение интервала маяка, вероятно, является хорошей идеей, нам просто нужно выбрать хорошее значение (кроме того, все VIF используют один и тот же интервал маяка, поэтому изменения также повлияют на интерфейсы AP).

Увеличение интервала маяка не решит проблему переполнения частоты. Не ожидайте от этого большого увеличения пропускной способности (максимум 10%). Что вам действительно нужно, так это TDMA или, по крайней мере, RTS/CTS в случае перекрытия BSS. Например, http://netshe.ru/ создал реализацию TDMA на основе batadv14, которая не использует потерю пакетов, а использует информацию Wi-Fi nl80211 для расчета метрик (но она имеет закрытый исходный код и недостаточно хорошо поддерживается).
ATH9K HMAC https://github.com/szehl/ath9k-hmac — это пробная реализация концепции использования небольшого хака, позволяющего заставить работать TDMA без нарушения CSMA/CA. С этим можно было бы убедиться, что сети AP не мешают сетям Mesh, но для этого потребуется кто-то вроде NeoRaider, чтобы очистить поддержку ядра вышестоящего уровня. Коммуникационный интерфейс netlink пользовательского пространства написан на C++ и должен быть сначала переписан на C. Также отсутствует обработчик динамической установки правил TDMA.

Возможно, я обнаружил проблему, которая ухудшает производительность 802.11s.
802.11s имеет функцию под названием MCCA, которая представляет собой механизм предотвращения коллизий, работающий аналогично TDMA. Все соседи 802.11s синхронизированы (см. Синхронизация сетки 802.11s ) по умолчанию. Это удивительно точно (в среднем <10 микросекунд). В отличие от TDMA MCCA использует не временные интервалы, а интервалы DTIM. Узел 802.11s может запросить через одноадресную или многоадресную рассылку такой интервал DTIM для его использования. Все соседние узлы будут либо отрицать, либо принимать это через ответ в зависимости от любого совпадения с их собственными интервалами. Таким образом, MCCA — это своего рода самоорганизующаяся функция TDMA для 802.11, которая действительно крутая, и я хотел бы знать о ней раньше.

Насколько я вижу, DTIM-интервалы ячеистого интерфейса не влияют на другие VIF.

Редактировать: я думаю, что это не большая проблема, поскольку кажется, что MCCA вообще не реализован в ath9k. Могут ли у EDCA быть проблемы с несколькими VIF (использует ли он планирование очереди)? А как насчет драйверов Broadcom/ralink? Я думаю, что можно проверить IE, если код закрыт или просто слишком запутан. К сожалению, я не знаю правильного формата для этого и нашел только это:

Каждая станция может
включить поддержку MCCA и показать эту поддержку, установив значение 1 для бита MCCA Enabled,
который находится в подполе Mesh Capability элемента конфигурации Mesh, присутствующего в
маяки и зондирующие ответы. Другая станция может поддерживать MCCA, но не реализовывать его (т.
Подполе Mesh Capability также включает бит MCCA Supported). В этом случае станция может
участвовать в механизме MCCA, но не могут инициировать резервирование MCCA.
см. https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf

Закрытие: большинство вариантов 11s не имеют отношения к Gluon. Если мы найдем конкретный вариант интересным для поддержки, следует открыть отдельный вопрос.

Смотрите также:

• #421 (блокировка отдельных ссылок сетки)
• #2028 (конфигурация интервала маяка)