Gluon: 功能要求：使用 802.11s 功能更好地控制网状链路

我认为大多数 11s 选项对我们来说并不是很有趣，因为我们在更高层的路由协议中进行所有路由决策，并且只使用 11s 作为 adhoc 模式的替代品。

一些允许将链接列入黑名单的工作已在 freifunk-gluon/packages#118 中完成，但尚未完成。

增加信标间隔可能是一个好主意，我们只需要确定一个好的值（此外，所有 VIF 使用相同的信标间隔，因此更改也会影响 AP 接口）。

增加信标间隔并不能解决频率拥挤的问题。 不要期望带宽会因此而增加很多（最多 10%）。 在 BSS 重叠的情况下，您真正​​想要的是 TDMA 或至少是 RTS/CTS。 例如http://netshe.ru/已经构建了一个基于 batadv14 的 TDMA 实现，它不使用数据包丢失，而是使用 nl80211 wifi 信息进行度量计算（但它是封闭源代码并且维护得不够好）。
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 Mesh Synchronization ）。这是惊人的准确（平均 <10 微秒）。与 TDMA 不同，MCCA 不使用时隙，而是使用 DTIM 间隔。 802.11s 节点可以通过单播或多播请求这样的 DTIM 间隔供其使用。所有相邻节点将根据与它们自己的时间间隔的任何重叠，通过回复拒绝或接受这一点。因此 MCCA 是一种用于 802.11s 的自组织 TDMA 功能，它真的很酷，我希望我之前知道它。

据我所知，网状接口的 DTIM 间隔对其他 VIF 没有影响。如果这是真的，那么我认为具有多个 VIF 的 802.11 有点损坏。
与 ath9k-hmac 如何使用 powersafe 模式停止 ath9k 的传输队列类似，802.11s VIF 需要能够阻止其他 VIF 在其自己的 DTIM 间隔之外传输。

编辑：我认为这不是大问题，因为似乎 MCCA 根本没有在 ath9k 中实现。 EDCA 是否会对多个 VIF 有任何问题（它是否利用队列调度）？ Broadcom/ralink 驱动程序呢？如果代码是封闭源代码或太混乱，我认为可以检查 IE。不幸的是，我不知道正确的格式，只发现了这个：

每个站都可以
启用其对 MCCA 的支持，并通过将 MCCA 启用位设置为 1 来显示此支持，
它位于网格配置元素的网格能力子字段中
信标和探测响应。另一个站可能支持 MCCA 但不实施它（
Mesh Capability 子字段还包括一个 MCCA Supported 位）。在这种情况下，车站可以
参与 MCCA 机制，但不能发起任何 MCCA 预留。
见https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf

结束：大多数 11s 选项与 Gluon 无关。 如果我们发现一个有趣的特定选项需要支持，则应打开一个单独的问题。

也可以看看：

• #421（阻止单个网格链接）
• #2028（信标间隔配置）