Gluon: Solicitud de función: use las funciones de 802.11s para un mejor control de los enlaces de malla

Creo que la mayoría de las opciones de 11s no son muy interesantes para nosotros, ya que tomamos todas las decisiones de enrutamiento en un protocolo de enrutamiento de capa superior y solo usamos 11s como reemplazo del modo adhoc.

Se realizó un trabajo para permitir la inclusión de enlaces en la lista negra en freifunk-gluon/packages#118, pero no está terminado.

Aumentar el intervalo de baliza es probablemente una buena idea, solo necesitamos decidir un buen valor (además, todos los VIF usan el mismo intervalo de baliza, por lo que los cambios también afectarán las interfaces AP).

Aumentar el intervalo de la baliza no resolverá el problema de que una frecuencia esté saturada. No espere mucho aumento de ancho de banda de eso (máximo 10%). Lo que realmente desea es TDMA o al menos RTS/CTS en caso de BSS superpuestos. Por ejemplo, http://netshe.ru/ ha creado una implementación TDMA basada en batadv14 que no utiliza la pérdida de paquetes sino la información wifi nl80211 para los cálculos métricos (pero es de código cerrado y no se mantiene lo suficientemente bien).
ATH9K HMAC https://github.com/szehl/ath9k-hmac es una implementación de prueba de concepto del uso de un pequeño truco para hacer que TDMA funcione sin romper CSMA/CA. Con esto, uno podría asegurarse de que las redes AP no interfieran con las redes Mesh, pero necesitaría a alguien como NeoRaider para limpiar esto para el soporte del kernel ascendente. La interfaz de comunicación de enlace de red del espacio de usuario está escrita en C++ y primero debe reescribirse en C. Tampoco hay un controlador para la configuración dinámica de las reglas TDMA.

Tal vez encontré un problema que empeora el rendimiento de 802.11s.
802.11s tiene una característica llamada MCCA, que es un mecanismo para evitar colisiones que funciona de manera similar a TDMA. Todos los vecinos 802.11s están sincronizados (consulte Sincronización de malla 802.11s ) de forma predeterminada. Esto es asombrosamente preciso (promedio <10 microsegundos). A diferencia de TDMA, MCCA no usa intervalos de tiempo sino intervalos DTIM. Un nodo 802.11s puede solicitar a través de unidifusión o multidifusión dicho intervalo DTIM para su uso. Todos los nodos vecinos negarán o aceptarán esto a través de una respuesta dependiendo de cualquier superposición con sus propios intervalos. Por lo tanto, MCCA es una especie de función TDMA autoorganizada para 802.11s que es realmente genial y desearía haberlo sabido antes.

Por lo que puedo ver, los intervalos DTIM de la interfaz de malla no tienen efecto en los otros VIF.

Editar: creo que este no es el gran problema, ya que parece que MCCA no está implementado en absoluto en ath9k. ¿EDCA podría tener algún problema con múltiples VIF (utiliza la programación de colas)? ¿Qué pasa con los controladores de broadcom/ralink? Creo que uno podría verificar los IE si el código es de fuente cerrada o simplemente demasiado confuso. Desafortunadamente, no sé el formato correcto para eso y solo encontré esto:

Cada estación puede
habilite su soporte para MCCA y muestre este soporte configurando en 1 el bit MCCA habilitado,
que está en el subcampo de capacidad de malla del elemento de configuración de malla presente en
respuestas de balizas y sondas. Otra estación puede admitir MCCA pero no implementarlo (la
El subcampo Capacidad de malla también incluye un bit compatible con MCCA). En ese caso, la estación puede
participar en el mecanismo MCCA, pero no puede iniciar ninguna reserva MCCA.
consulte https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf

Cierre: la mayoría de las opciones de 11 no son relevantes para Gluon. Si encontramos una opción específica interesante para apoyar, se debe abrir una edición separada.

Ver también:

• #421 (bloqueo de enlaces de malla individuales)
• #2028 (configuración de intervalo de baliza)