Gluon: 기능 요청: meshlink의 더 나은 제어를 위해 802.11s 기능 사용

대부분의 11s 옵션은 우리에게 그다지 흥미롭지 않다고 생각합니다. 우리는 상위 계층 라우팅 프로토콜에서 모든 라우팅 결정을 수행하고 adhoc 모드를 대체하기 위해 11s만 사용하기 때문입니다.

블랙리스트 링크 허용에 대한 일부 작업은 freifunk-gluon/packages#118에서 수행되었지만 완료되지 않았습니다.

비컨 간격을 늘리는 것은 아마도 좋은 생각일 것입니다. 좋은 값을 결정하기만 하면 됩니다(또한 모든 VIF는 동일한 비컨 간격을 사용하므로 변경 사항은 AP 인터페이스에도 영향을 미칩니다).

비콘 간격을 늘려도 주파수가 붐비는 문제가 해결되지 않습니다. 그로부터 많은 대역폭 증가를 기대하지 마십시오(최대 10%). 당신이 정말로 원하는 것은 TDMA 또는 겹치는 BSS의 경우 최소한 RTS/CTS입니다. 예를 들어 http://netshe.ru/ 는 패킷 손실을 사용하지 않고 메트릭 계산을 위해 nl80211 wifi 정보를 사용하는 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.11s를 위한 일종의 자체 구성 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 참조

마무리: 대부분의 11s 옵션은 Gluon과 관련이 없습니다. 지원하기에 흥미로운 특정 옵션을 찾으면 별도의 문제를 열어야 합니다.

또한보십시오:

• #421(개별 메쉬 링크 차단)
• #2028(비콘 간격 설정)