Übergeordneter Artikel: Netzwerkoptimierung

Warum?

Unsere Ad-hoc BSSIDs widersprechen derzeit 802.11, da die ersten beiden Bits nicht 01 sind.
- d.h. auf den meisten aktuellen Geräten / Firmwaren lassen sich unsere BSSIDs gar nicht mehr einstellen.

  Die Frequenzbänder für 802.11 werden erweitert (6GHz, 60GHz, sub-GHz). Wenn dort Ad-Hoc (IBSS) verwendet werden soll, dann braucht man ein neues BSSID-Schema, weil im derzeitigen schon für 5GHz zu wenig Platz ist. 
  Wenn verschiedene Freie Netzwerke auf Ad-hoc-Ebene zusammenwachsen sollen (z.B. Graz/Maribor), dann braucht man ein vernünftiges gemeinsames Schema. Das vereinbart man besser früher als später.

Es gab dazu es im Februar 2011 eine Diskussion auf der tech-Mailingliste.

Seit November 2013 wird die Maximallösung Kanal (siehe unten) angestrebt. Neue Netzsegmente die aus verschiedenen Gründen das alte Schema nicht übernehmen können bzw. wollen sollten dieses Schema verwenden.

Die Grundfragen

Was soll kodiert werden?
- Kanal/Frequenz?
- Kanalbreite?
- Polarisation?

  Wie viel Platz muss bleiben?

Warum Kanal/Frequenz?

Warum überhaupt verschiedene BSSIDs und nicht nur eine?

Wenn man für mehrere Kanäle die gleichen BSSIDs verwendet, dann verbinden z.B. auch v3 und v8 miteinander (wurde bereits gesehen). Durch verschiedene BSSIDs können solche an sich unsinnigen Verbindungen auf einer sehr niedrigen Ebene (OSI-Schicht|2]) ausgeschlossen werden.

Warum NICHT Polarisation?

RTS/CTS → Reduziert gegenseitige Störungen, auch zwischen verschiedenen Polarisationen, wenn ausreichender gegenseitiger Empfang gegeben. Also genau der Fall, wo es gebraucht wird. Wenn kein ausreichender Empfang, dann ist auch die Störung von Haus aus gering und RTS/CTS nicht so wichtig.
Verschiedene Polarisationen sind durchaus kombinierbar:
- v…Vertikal
- h…Horizontal (wird derzeit auch für Helix verwendet)
- r…Rechtsdrehend (noch nicht beschlossen)
- l…Linksdrehend (noch nicht beschlossen)

  v+v = sehr gut 
  h+h = sehr gut 
  v+h = sehr schlecht 
  r+h, r+v, l+h, l+v = akzeptabel, derzeit ist zumindest eine rechtsdrehende Helixantenne in unserem Netz in Verwendung über die zwei angeblich horizontal polarisierte Knoten angebunden sind. 
  r+l = sinnlos

→ Polarisation sollte nur in der ESSID stehen, sodass zwei Knoten verschiedener Polarisation im Fall des Falles trotzdem verbinden.

Aaron Kaplan hat darauf hingewiesen, dass in Wien auf Ebene der BSSID die Polarisation kodiert ist. Dort ist man aufgrund einer sehr stark störenden Sendeanlage, die schon vor WLAN zugelassen wurde, gezwungen auf horizontale Polarisation auszuweichen. siehe: http://wiki.funkfeuer.at/index.php/Kanalwahl#Unsere_ssid_und_bssid → Das Wiki widerspricht dem. → Muss geklärt werden.

Warum (nicht) Kanalbreite? – Über die Kanäle, Modulation etc.

Die derzeit in Österreich zugelassenen Bänder befinden sich im 2.4|GHz] und 5|Ghz] Bereich. Derzeit verwenden wir nur 802.11g Equipment für Ad-hoc (also 2.4GHz, OFDM, 20MHz Kanalbreite). Dies könnte sich aber eines Tages ändern, und dann ist die Kanalbreite eine relevante Größe. Da es allerdings teilweise möglich und sinnvol sein kann das Linkpartner mit unterschiedelichen Kanalbreiten kommunizieren (zb. 20MHz Client auf 40MHz AP) ist die die Kanalbreite als Teil der BSSID eher ungeignet.

Für eine detaillierte Erklärung siehe Artikel Kanäle

Der aktuelle Stand

ESSID

Im 2,4GHz-Band ist die ESSID prinzipiell “graz.funkfeuer.at”, es können (sollen) aber Kanal und Polarisation durch v (vertikal) und h (horizontal) + Kanalnummer angegeben werden, wobei h8 derzeit auch für eine Helixantenne verwendet wird. Bsp.: v9.graz.funkfeuer.at

Es wird diskutiert zu Werbezwecken dies auf http://graz.funkfeuer.at/v9 zu ändern, was bei den meisten Geräten auch einseitig (ohne Übereinstimmung mit den anderen Geräten) gemacht werden kann, solang die BSSID bei allen miteinander verbundenen Geräten gleich ist. Diese Idee wird von einigen bis vielen begrüßt und unterstützt.

BSSID

Die BSSID ist im 2,4GHz-Band prinzipiell Kanalnummer + :CA:FF:EE:BA:BE. Bsp.: 01:CA:FF:EE:BA:BE → Kanal 1

Jedoch gibt es historisch bedingte Ausnahmen, nämlich v3 und v8. Dort ist die BSSID 02:etc. Es besteht ein Konsens, dass dies zukünftig vereinheitlicht werden soll. Im 5GHz-Band gibt es keine solche Übereinkunft, da bei uns derzeit keine 5GHz-Ad-Hoc-Netze betrieben werden, was nicht immer so bleiben muss. Hier hätten wir dann ein Problem: Die Kanalnummern wären teilweise dreistellig.

Andere Gruppen

wlanljubljana|http://wlan-lj.net/|wlanljubljana] wird eines Tages vor dem gleichen Problem stehen: Sie verwenden v8 + 02:CA:FF:EE:BA:BE

https://kifuse02.pberg.freifunk.net/moin/channel-bssid-essid

http://osdir.com/ml/org.freifunk.wlanware/2006-12/

http://comments.gmane.org/gmane.org.freifunk.berlin/11087

Vorgaben

Der Standard 802.11 gibt vor, dass die ersten beiden übertragenen Bits der BSSID bei IBSS (Ad-hoc) immer 0 und 1 sein sollen. Die Bitreihenfolge ist klein → groß. Daraus ergibt sich, dass in Hexadezimalschreibweise die zweite Stelle 2, 6, A oder E sein soll. In der Diskussion “BSSID und Ad-Hoc” auf der Berliner|Freifunk-Liste] wurde auf den IEEE802.11-Standard|http://standards.ieee.org/getieee802/download/802.11-2007.pdf|IEEE802.11-Standard] Abschnitt 7.1.3.3.3 zweiter Absatz verwiesen, wo folgendes zu finden ist. Dort gibt es eine klare Vorgabe für IBSS (Ad-hoc):
- individual/group bit: 0
- universal/local bit: 1

Demnach darf an zweiter Stelle der BSSID bei IBSS nur 2, 6, A oder E stehen. Wo die beiden Bits zu finden sind und wie das Ganze zur hex-Version korreliert wird hier erklärt: Standard Group MAC Addresses: A Tutorial Guide http://standards.ieee.org/develop/regauth/tut/macgrp.pdf Hexspeak/Magic Numbers: Um eine leichte Wiedererkennbarkeit zu erreichen, hat man also ursprünglich einfach die Variante “02:” und das beliebte 0xCAFEBABE hergenommen und zu “02:CA:FF:EE:BA:BE” verbunden.

Später bestand dann die Notwendigkeit für verschieden Kanäle eigene BSSIDs zu haben, was zu Varianten wie z.B. 13:CA:FF:EE:BA:BE, D2:CA:FF:EE:BA:BE oder auch 00:13:CA:FE:BA:BE geführt hat.

  Laut [[[[WikiPedia>List|List]] of WLAN channels]] wurden in Japan im 5GHz-Band noch einmal die Nummern 7, 8, 9, 11 für 802.11 WLAN zugelassen.

Mögliche Lösungen

Kurzfristig, Graz

802.11 ist uns gezwungernermaßen egal, weil uns eine kurzfristige Komplettumstellung zu viel Aufwand bei wenig Nutzen ist.

802.11n: 40MHz Kanalbreite

Es wurde festgestellt, dass 802.11n in greifbarer Nähe ist. (Max) Soll heißen: Funkfeuertaugliche Hardware dürfte es bereits geben. Das bringt uns 40MHz-Kanäle und damit die Notwendigkeit unsere BSSIDs zu überarbeiten.

Eliminierung von 02:CA:FF…

Wir haben folgendes Problem:

Bei 20MHz Kanalbreite (das derzeit übliche) wären 4 überlappungsfreie Kanäle/Netze möglich (v1, v5, v9, v13). v3 ist unser ältestes und größtes Ad-hoc Meshnetzwerk und stört 50% von Kanal 1 und Kanal 5. Als zweites Netz wurde v8 errichtet (wenns stimmt), welches sich nicht mit v3 überlappen würden und nur noch wenige Knoten hat.
02:CA:FF… bei v3 und v8 zu verwenden ist ein Relikt, das auch zu sinnlosen Routingversuchen zwischen den beiden Netzen führt.
Es kommt teilweise zu erheblichen Störungen zwischen v7, v8 und v9 (z.B. hochstein panel1 v8 und maschendraht2 v9 senden in die gleiche Richtung)
Eine Umstellung von panel1 ist durchaus erwünscht, lässt sich aber nicht gut durchführen, da durch die örtlichen Gegebenheiten nur v1, v5 oder v13 in Frage kommen. Wenn v13 nicht möglich ist (nicht geklärt), dann blieben nur v1 und v5. Das würde wiederum durch dir örtlichen Gegebenheiten zu Störungen zwischen v3 und v1 oder v5 führen → ganz blöde Situation.

Zwei Möglichkeiten:

Wir stellen die BSSIDs von v3 und v8 um, sodass wir ein einheitliches Schema haben. (weil einheitliche Lösungen ja so schön sind)
Wir stellen die Kanäle bei Knoten mit v3 und v8 um: Gleicher Aufwand wie BSSID-Umstellung und wir wären mit einem Schlag zwei alte Probleme los.

Wie ginge man das an?

Welche Kanäle wären gut?
- Vielleicht v3 → v1 und v8 nach v5
- Vorteil von v1: Ein Kanal am Rand des Bandes, der somit weniger Überlappungsgefährdet ist als z.B. v5. Nach v3 → v1 wäre v1 das mit Abstand größte Netz und ein “guter” Kanal wie v1 einen gute Wahl. Bei v13 muss geklärt werden, ob das merkwürdige Verhalten von Linksys-Routern in diesem Zusammenhang für die Funktionalität des v13 Netzes relevant ist.

...

Problemfeld Polarisation

Die Polarisation soll nur in der ESSID angegeben werden, eine Erweiterung für die Helixantennen wird vorgenommen, weil Bedarf jetzt gegeben. Die ESSIDs werden einheitlich auf http://graz.funkfeuer.at/Polarisation+Kanal umgestellt.

Würde dann so aussehen:

Kanal 5
BSSID: 05:CA:FF:EE:BA:BE
ESSID: http://graz.funkfeuer.at/v5 oder
- http://graz.funkfeuer.at/h5 oder
- http://graz.funkfeuer.at/r5 oder
- http://graz.funkfeuer.at/l5 je nach Antenne.

Es sollte selbstverständlich sein, dass Knotenbetreiber über die Polarisation ihrer Antennen bescheid wissen und zumindest ein rudimentäres Verständnis vom technischen Konzept Polarisation haben. Derzeit ist nicht immer verlässlich erkennbar, welche Polarisation ein Knoten hat.

Conclusio für Graz

Komplettumstellung auf Schema 1,5,9,13 → 02:CA:FF:EE:BA:BE verschwindet automatisch
Es wird die Maximallösung Kanal angestrebt. Die Kanalbreite wird nicht in die BSSID aufgenommen (siehe oben).

Langfristig, gruppenübergreifend

Es wird Kontakt zu anderen Gruppen aufgenommen
- Es wird um Vorschläge gebeten, vielleicht ohne zuvor unsere eigenen mit zu teilen. Möglicherweise stoßen wir so auf neue Probleme/Ideen, an die wir nicht gedacht haben.

Minimallösung

CA:FE:BA:BE:00:13

Maximallösung

Dies wäre Kanal/Frequenz + Polarisation

Bsp. für Maximallösung Kanal

CA:99:99:99:C1:36
||:|       :|->Kanalnummer
|| |
|| |-> Frequenzband in MHz, dezimal
||
||-> E= horizontal, A= Vertikal, 2= Rechtsdrehend, 6= Linksdrehend
|-> C = Channel encoded

Bsp.:

Kanal  v13 = CA:00:24:00:C0:13
Kanal v136 = CA:00:50:00:C1:36

Diese Lösung wird seit November 2013 angestrebt. Neue Netzsegmente die aus verschiedenen Gründen das alte Schema nicht übernehmen können bzw. wollen sollten dieses Schema verwenden.

Bsp. für Maximallösung Frequenz

FA:CB:FF:FF:FF:FF
||:||:|->Mittenfrequenz in kHz, hex
|| ||
|| ||-> Kanalbreite in MHz, hex
||
||-> E= horizontal, A= Vertikal, 2= Rechtsdrehend, 6= Linksdrehend
|-> F = Frequency encoded