Gluon: 機能リクエスト：メッシュリンクをより適切に制御するために802.11s機能を使用する

上位層のルーティングプロトコルですべてのルーティング決定を行い、アドホックモードの代わりに11のみを使用するため、ほとんどの11sオプションは私たちにとってあまり興味深いものではないと思います。

リンクをブラックリストに登録するためのいくつかの作業はfreifunk-gluon / packages＃118で行われましたが、まだ完了していません。

ビーコン間隔を長くすることはおそらく良い考えです。適切な値を決定する必要があります（また、すべてのVIFが同じビーコン間隔を使用するため、変更はAPインターフェイスにも影響します）。

ビーコン間隔を長くしても、周波数が混雑するという問題は解決されません。 それから帯域幅が大幅に増加することは期待しないでください（最大10％）。 本当に必要なのは、BSSが重複している場合はTDMAまたは少なくともRTS / CTSです。 たとえば、 http： //netshe.ru/は、パケット損失を使用せず、メトリック計算にnl80211 Wi-Fi情報を使用するbatadv14ベースのTDMA実装を構築しました（ただし、これはクローズドソースであり、十分に維持されていません）。
ATH9K HMAC https://github.com/szehl/ath9k-hmacは、CSMA / CAを壊すことなくTDMAを機能させるために、小さなハックを使用する概念実証の実装です。 これにより、APネットワークがメッシュネットワークに干渉しないようにすることができますが、アップストリームカーネルサポートのためにこれをクリーンにするためにNeoRaiderのような人が必要になります。 ユーザースペースのネットリンク通信インターフェースはC ++で記述されており、最初にCで書き直す必要があります。 TDMAルールを動的に設定するためのハンドラーもありません。

たぶん私は802.11sのパフォーマンスを悪化させる問題を見つけました。
802.11sには、TDMAと同様に機能する衝突回避メカニズムであるMCCAと呼ばれる機能があります。 デフォルトでは、すべての802.11sネイバーが同期されます（ 802.11sメッシュ同期を参照）。 これは驚くほど正確です（平均<10マイクロ秒）。 TDMAとは異なり、MCCAはタイムスロットではなくDTIM間隔を使用します。 802.11sノードは、ユニキャストまたはマルチキャストを介して、そのようなDTIM間隔を使用するように要求できます。 すべての隣接ノードは、自身の間隔との重複に応じて、応答を介してこれを拒否または受け入れます。 したがって、MCCAは802.11用の自己組織化TDMA機能の一種であり、非常に優れています。以前に知っていればよかったのですが。

私が見る限り、メッシュインターフェイスのDTIM間隔は他のVIFに影響を与えません。

編集：MCCAはath9kにまったく実装されていないように見えるので、これは大きな問題ではないと思います。 EDCAは複数のVIFで問題が発生する可能性がありますか（キュースケジューリングを利用していますか）？ Broadcom / ralinkドライバーはどうですか？ コードがクローズドソースであるか、単に混乱しすぎている場合は、IEを確認できると思います。 残念ながら、私はそのための正しい形式を知りません、そしてこれだけを見つけました：

各ステーションは
MCCAのサポートを有効にし、MCCA有効ビットを1に設定して、このサポートを示します。
これは、に存在するメッシュ構成要素のメッシュ機能サブフィールドにあります
ビーコンとプローブ応答。 別のステーションがMCCAをサポートしている可能性がありますが、実装していません（
メッシュ機能サブフィールドには、MCCAサポートビットも含まれます）。 その場合、駅は
MCCAメカニズムに参加しますが、MCCA予約を開始することはできません。
https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdfを参照して

締めくくり：ほとんどの11のオプションはGluonには関係ありません。 サポートするのに興味深い特定のオプションが見つかった場合は、別の問題を開く必要があります。

参照：

• ＃421（個々のメッシュリンクをブロックする）
• ＃2028（ビーコン間隔設定）