Gluon: Permintaan Fitur: gunakan fitur 802.11s untuk kontrol meshlink yang lebih baik

Saya pikir sebagian besar opsi 11s tidak terlalu menarik bagi kami, karena kami melakukan semua keputusan perutean dalam protokol perutean lapisan yang lebih tinggi dan hanya menggunakan 11s sebagai pengganti mode adhoc.

Beberapa pekerjaan untuk mengizinkan tautan daftar hitam dilakukan di freifunk-gluon/packages#118, tetapi belum selesai.

Meningkatkan interval suar mungkin merupakan ide yang bagus, kita hanya perlu memutuskan nilai yang baik (juga, semua VIF menggunakan interval suar yang sama, sehingga perubahan akan memengaruhi antarmuka AP juga).

Meningkatkan interval suar tidak akan menyelesaikan masalah frekuensi yang penuh sesak. Jangan berharap banyak peningkatan bandwidth dari itu (maksimal 10%). Yang Anda inginkan adalah TDMA atau setidaknya RTS/CTS jika terjadi tumpang tindih BSS. Misalnya http://netshe.ru/ telah membangun implementasi TDMA berbasis batadv14 yang tidak menggunakan packet loss tetapi informasi wifi nl80211 untuk perhitungan metrik (tetapi itu adalah sumber tertutup dan tidak dikelola dengan cukup baik).
ATH9K HMAC https://github.com/szehl/ath9k-hmac adalah implementasi proof-of-concept menggunakan sedikit hack untuk membuat TDMA bekerja tanpa merusak CSMA/CA. Dengan ini dapat memastikan bahwa jaringan AP tidak mengganggu jaringan Mesh, tetapi akan membutuhkan seseorang seperti NeoRaider untuk membersihkan ini untuk dukungan kernel upstream. Antarmuka komunikasi netlink userspace ditulis dalam C++ dan perlu ditulis ulang dalam C terlebih dahulu. Juga tidak ada handler untuk pengaturan dinamis aturan TDMA.

Mungkin saya menemukan masalah yang membuat kinerja 802.11s lebih buruk.
802.11s memiliki fitur yang disebut MCCA yang merupakan mekanisme penghindaran tabrakan yang bekerja mirip dengan TDMA. Semua tetangga 802.11s disinkronkan (lihat Sinkronisasi Mesh 802.11s ) secara default. Ini sangat akurat (rata-rata <10 mikrodetik). Tidak seperti TDMA, MCCA tidak menggunakan slot waktu tetapi interval DTIM. Sebuah node 802.11s dapat meminta melalui unicast atau multicast seperti interval DTIM untuk digunakan. Semua node tetangga akan menolak atau menerima ini melalui balasan tergantung pada tumpang tindih dengan interval mereka sendiri. Jadi MCCA adalah semacam fitur TDMA yang mengatur sendiri untuk 802.11s yang sangat keren dan saya berharap saya mengetahuinya sebelumnya.

Sejauh yang saya bisa lihat, interval DTIM dari antarmuka mesh tidak berpengaruh pada VIF lainnya.

Sunting: Saya pikir ini bukan masalah besar karena tampaknya MCCA tidak diterapkan di ath9k sama sekali. Bisakah EDCA memiliki masalah dengan beberapa VIF (apakah menggunakan penjadwalan antrian)? Bagaimana dengan driver broadcom/ralink? Saya pikir orang dapat memeriksa IE jika kodenya sumber tertutup atau terlalu membingungkan. Sayangnya saya tidak tahu format yang benar untuk itu dan hanya menemukan ini:

Setiap stasiun dapat
aktifkan dukungannya untuk MCCA dan tunjukkan dukungan ini dengan menyetel ke 1 bit MCCA Enabled,
yang ada di Subbidang Kemampuan Mesh dari Elemen Konfigurasi Mesh yang ada di
beacon dan tanggapan probe. Stasiun lain mungkin mendukung MCCA tetapi tidak mengimplementasikannya (the
Subbidang Kemampuan Mesh juga menyertakan bit yang Didukung MCCA). Dalam hal ini, stasiun dapat
berpartisipasi dalam mekanisme MCCA, tetapi tidak dapat memulai reservasi MCCA apa pun.
lihat https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf

Penutupan: Sebagian besar opsi 11s tidak relevan untuk Gluon. Jika kami menemukan opsi tertentu yang menarik untuk didukung, masalah terpisah harus dibuka.

Lihat juga:

• #421 (memblokir tautan jala individu)
• #2028 (konfigurasi interval suar)