[WLANtalk] 5GHz DFS Gedanken

Di Nov 11 23:44:55 CET 2014

So nun noch mal,

bevor ich den 5Ghz-Adhoc-Modus endgültig zu den Akten lege, wollte ich
noch mal eine Diskussionsrunde starten. Vielleicht übertrifft die
zukünftige Adhoc Lösung später sogar einmal die AP/Client-Lösung, eben
weil Adhoc mit gleichwertigen Partnern arbeitet.

   Hier noch mal der Versuch einer logischen Argumentationskette...
   Ich würde mal ein paar Problem-Fälle bei Radar-Detektion aufzählen
   die mir einfallen.

1. Ein einzelner Knotenpunkt im Mesh kann verloren gehen, ohne dass es
das übrige Netz bemerkt.

2. Ein Mesh-Netz kann in viele verschiedene Knoten und Teilnetze
zerfallen.

3. Bei mehreren Teil-Mesh-Netzen kann es passieren, dass die freien
nicht überlappenden Kanäle knapp werden, wenn ein Kanal gesperrt wird.

   Die Lösung muss also dazu im Stande sein, ein völlig zerbrochenes
   Netz wieder zu vereinen. Daraus würde ich folgende Nebenbedingungen
   ableiten:

1. Alle Knoten brauchen ein gemeinsames Informationssystem, welches
ihnen über die gesperrten Kanäle aller beteiligten Knoten und über
deren "Gruppenzugehörigkeit" aller beteiligten Knoten berichtet.

2. Es bedarf einer Einteilung in "Gruppenzugehörigkeit", um die
Signale über die zur Verfügung stehenden Kanäle nicht überlappend bzw.
sich gegenseitig störend zu übertragen.

3. Es bedarf einem gemeinsamen Algorithmus um sich nach einer
Mesh-Zerschlagung auf einem gemeinsamen freien Kanal wieder zu finden.

4. Die Knoten müssen sich nach Radar-Detektion zunächst auf einem
beliebigen freien Kanal wieder anmelden. Danach suchen sie sich einen
gemeinsamen Kanal.

   Die Information der gesperrten Kanäle zu übertragen, dazu bietet sich
   meines Erachtens die ESSID und die BSSID an. 
   Man könnte die Gruppenzugehörigkeit, wie schon gehabt, mit Hilfe der
   BSSID signalisieren. Dies wäre ja für den Ad-Hoc-Modus sowieso
   notwendig. Die gesperrten Kanäle könnte man mittels ESSID
   übermitteln. Ein daemon, wie der hostapd (vielleicht hostahd) würde
   sequentiell Scans durchführen und einen Algorithmus zur Kanalauswahl
   beherrschen. 

Wie könnte nun dieser Algorithmus aussehen?

Zu den SSIDs...
Die BSSID könnte neben Caffee noch eine Nummer enthalten, welche die
Gruppenzugehörigkeit signalisiert. 05:01:CA:FF:EE:EEEEEE
Die ESSID veröffentlicht alle gesperrten Kanäle.
Die Vereinigungsmenge der publizierten gesperrten Kanäle aller Knoten
ergibt die tatsächlich gesperrten Kanäle.

Wenn das so einfach wäre...
Jetzt ergibt sich noch ein klitze kleines Problem.
Es werden nicht alle Knoten von allen anderen Knoten gleichermaßen
im Scan erkannt. Hier muss eine weitere Lösung her.

Ein erster Gedanke war, es muss eine weitere Info in die ESSID.

Hier nun ein Vorschlag für solch eine Lösung:

Alle gesperrten Kanäle werden publiziert.
Dazu wird von jedem Knoten, der die Sperre selbst hat eine 0 angehängt.
Beispiel: 

104-0;100-4;108-255;

Kanal 104 wurde von mir selbst wegen Radar als gesperrt markiert.
Kanal 100 wurde von einem 4 Hops entfernten Knoten detektiert. 
Kanal 108 ist frei bzw. der Knoten liegt ausreichend weit (255 Hops)
entfernt.

Ich denke der Rest erklärt sich von selbst.

Am Tue, 11 Nov 2014 03:10:53 +0100
schrieb Markus Schräder <augsburgfreifunk at priv.de>:

> Hallo Simlebef,
> 
> und dann soll der olsrd oder batman das sehen und sich automatisch
> konfigurieren? Oder für welchen Zweck möchtest Du dies so laufen
> lassen?
> 
> Viele Grüße
> Markus
> 
> > Wollte noch mal das Thema DFS ausgraben. Was spricht gegen eine
> > dynamische Kodierung der ESSID?
> > 
> > Laut Wikipedia darf diese bis zu 32 Zeichen lang sein.
> > 
> > 
> > 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 10 21 22
> > 23 24 25 26 27 28 29 30 31 32
> > 
> > Die BSSID ist immer so etwas "02-ca-ff-ee-ba-be" oder 
> > "05:ca:ff:ee:ba:be" und muss für Adhoc gleich sein.
> > 
> > Die (E)SSID ist beliebig. Könnte also auch zur Kommunikation
> > zwischen den Nodes genutzt werden. Für eine automatische
> > Verbindungsaufnahme könnte man einen sinnvollen Code in der BSSID
> > und (E)SSID eintragen.
> > 
> > Erst mal die Frage welche Informationen übermittelt werden
> > müssten. 1. 2.4, 5.0 Modus 2. Die momentan freien Kanäle:
> > 100,104,108,112... 3. Ein "Freifunk". 4. Vielleicht noch die
> > Teilnehmer-Anzahl (0-Z)? 5. Vielleicht eine Gruppenzugehörigkeit
> > wegen nicht Überlappung. Wobei die Gruppe auch in der BSSID stehen
> > könnte.
> > 
> > Kanäle nicht ausschreiben:
> > 
> > 36=0 ... 140=i
> > 
> > Ich sortiere:
> > 
> > 5 F r e i f u n k .        Freq. und Flagge 0 1 2 3 4 5 6 7 8 9
> > freie Kanäle a b c d e f g h i .        freie Kanäle z . n s o w a
> > b c d        Verbindungszahl und Gruppenzuhehörigkeit
> > 
> > Ein Scan könnte aller 5 min laufen. Ein modifizierter hostapd
> > könnte die Kanalwahl vornehmen. Ein eindeutiger Algorithmus sorgt
> > für Einigkeit.
> > 
> > 
> > lg
> > 
> > 
> > 
> > _______________________________________________ WLANtalk mailing
> > list WLANtalk at freifunk.net Abonnement abbestellen? ->
> > http://lists.freifunk.net/mailman/listinfo/wlantalk-freifunk.net
> > 
> > Weitere Infos zu den freifunk.net Mailinglisten und zur An- und
> > Abmeldung unter http://freifunk.net/mailinglisten
> > 
> 
> _______________________________________________
> WLANtalk mailing list
> WLANtalk at freifunk.net
> Abonnement abbestellen? ->
> http://lists.freifunk.net/mailman/listinfo/wlantalk-freifunk.net
> 
> Weitere Infos zu den freifunk.net Mailinglisten und zur An- und
> Abmeldung unter http://freifunk.net/mailinglisten

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 213 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/wlantalk-freifunk.net/attachments/20141111/5eebb87f/attachment.sig>