WLAN richtig konfigurieren: Überlappungsfreie Kanäle wählen

WLAN nach 802.11n sollte im 2.4 GHz-Band ausschließlich mit 20 MHz-Breite konfiguriert werden (= 150 Mbps) und auf die Kanäle 1, 5, 9 oder 13 konfiguriert werden. Kompatibilität zu 802.11n-Clients sollte deaktiviert und statt dessen der „G-N-Mode“ gewählt werden.
Im Zweifel auf älteren Fritzboxen die Option „WLAN-Autokanal inklusive Kanal 12/13“ aktivieren, um das Spektrum vollständig auszunutzen (nur nicht für den deutschen Markt bestimmte, ältere Geräte können mit Kanal 13 keine Verbindung aufbauen – die totale Ausnahme).
Würde man 40 MHz breite Kanäle wählen, so stünden mit Kanal 3 und 11 lediglich zwei überlappungsfrei zur Verfügung und das Spektrum wäre bereits ausgeschöpft – untragbar, daher gilt: keine 40 MHz Breite bzw. 300 Mbps im 2.4 GHz-Band fahren! Bei der Fritz!Box die Option „Optimierte Funkkanäle nutzendeaktivieren(!), sie müßte richtig „40 MHz breiten WLAN kanal nutzen“ heißen.
Moderne Accesspoints verringern die Bandbreit zwar bei Kollision automatisch, aber das funktioniert nicht so zuverlässig und dauerhaft stabil wie eine manuelle Konfiguration mit Weitsicht.
Sind alle Kanäle belegt und Kollisionen mit Nachbarn nicht zu vermeiden, so führt eine direkte Kollision auf dem gleichen Kanal zu höherer Bandbreite als auf benachbarten aber sich doch in weiten Teilen überschneidenden Kanälen.
Sendeleistung auf das tatsächlich benötigte Minimum reduzieren, um die Nachbarn weniger zu stören.
Ein ordentlicher und auf Deutschland/Europa vom Hersteller ausgelegter Router wie eine Fritzbox von AVM oder ein neurer Speedport der Telekom konfigurieren den Kanal automatisch richtig und wechseln bei Kollisionen.
Vgl. die gute Darstellung des Elektronik Kompendiums.

Das 5 GHz-Band hält ein deutlich breiteres Spektrum vor, so dass sich weniger Kollisionen ergeben und höhere Geschwindigkeiten erzielen lassen. Dank der größeren Dämpfung ggü. 2.4 GHz ist die räumliche Ausbreitung (=Reichweite) geringer, was zur Vermeidung von Kollisionen beiträgt.
Im 5 GHz-Band stehen auf vielen „billigen“ Accesspoints nur die Kanäle 36 bis 48 zur Verfügung, da der Hersteller auf DFS verzichtet hat. Bei 20 MHz stehen vier Kanäle zur Verfügung, bei 40 MHz sind es nur noch zwei und bei Verwendung von AC mit 80 MHz ein einziger.
Im Bereich der Kanäle 36-48 sollte man daher auf Rücksicht auf die anderen Nutzer nicht mehr als 40 MHz breite Kanäle wählen und sich auf 36 oder 44 beschränken. Gleiches gilt für 52-64, das auf den meisten Accesspoints zur Verfügung steht.
Lediglich auf modernen Accesspoints, die Kanal 100 bis 116 bzw bis 128 unterstützen ist eine sinnvolle Nutzung von 80 MHz denkbar.
Praktisch stellen sich bei breiten Kanälen auf niedrigen Bändern so viele Kollisionen ein, dass die vermeintlich hohe Geschwindigkeit des breiten Kanals ohnehin verpufft. Eine stabile Verbindung ist mehr wert als eine theoretisch hohe aber praktisch nicht erreichbare Bandbreite.
Generell sollte man möglichst hohe Kanäle verwenden, um das kostbare niedrige Band zu entlasten – eine geringere Reichweite ist praktisch nicht feststellbar, auch Effekte durch Wettterradar auf 120-128 sind nahezu nie feststellbar.
Vgl. Darstellung des Elektronik Kompendiums für 20/40 und 80/160 MHz.

Im Elektronik Kompendium sind Historie und Empfehlung zur Kanalwahl bei WLAN gut beschrieben. Man sollte sich ausschließlich an die Anleitung für 802.11n und ac halten und die Empfehlung für Europa befolgen. Die CT hat ebenfalls einen guten WLAN-Ratgeber veröffentlicht.

Bei Problemen mit IPTV: darauf achten, dass alle Switches IGMP/Multicast unterstützen und auf FritzBoxen „WLAN-Übertragung für Live TV optimieren“ gesetzt ist. Bei OpenWRT/DDWRT basierten Router diesen Tipp beachten.

Kurztipps zur Kanalwahl und -konfiguration

  • Bei modernem Speedport oder Fritzbox automatische Kanalwahl einstellen, ansonsten:
  • Bei 2.4 GHz nur 20 MHz breite Kanäle (also nur 150 Mbps statt 300) wählen und auf 1,5,9 oder 13 konfigurieren. Aufgrund der hohen Reichweite des Bandes die Sendeleistung reduzieren, z.B. auf mittel.
    Modus 802.11g/n, kein 802.11b.
  • Im 5 GHz möglichst auf 40 MHz breite Kanäle setzen und zur Entlastung des kostbaren Spektrums möglichst hohe Kanäle wählen.
  • Bei vielen benachbarten, störenden WLANs lieber gleiche Kanäle wählen als „knapp daneben“ oder „halb überschneidend“. 1/5/9/13-Regel möglichst beibehalten, notfalls auf 1/6/11 (USA) oder 1/7/3 (802.11b-kompatibel, Europa) ausweichen.

 

Probleme mit IPTV (Entertain) über WLAN mit DDWRT/OPENWRT-Firmware auf dem Router? Lösung!

Installiert man auf einem Router die alternativen Firmwares DDWRT oder OpenWRT kann man darauf einige Funktionen aktivieren, die mit der Herstellerfirmware nicht vorgesehen waren.
Unglücklicherweise fängt man sich damit aber auch das Problem ein, dass die Accesspointfunktion in Mitleidenschaft gezogen wird und IPTV-Streams wie T-Entertain über WLAN nicht mehr richtig funktionieren oder stocken. Bei 802.11n WLAN-Protokoll basierten Routern, die problemlos 300 Mbps Bruttodatenrate erzielen unverständlich, zumal ein Speedtest schnell zeigt, dass die Bandbreite selbst nicht das Problem ist.

Ursächlich ist eine unglückliche Einstellung in den erweiterten WLAN-Settings bzgl. der Paketgröße über WLAN. Sie führt dazu, dass Pakete beispielsweise sehr stark fragmentiert werden und ein IPTV-Paket dann in 2 oder 3 WLAN-Pakete (richtig wäre 802.11n-Frame) eingepackt werden muss, weil es die „Fragementation Treshold“, also die Schwelle aber der fragmentiert wird, überschreitet. Die verursacht bei einem UDP-IPTV-Livestream ohne Bufferung natürlich Verzögerungen, instabile Paketlaufzeiten und reduziert den Durchsatz ein klein wenig. Moderne TCP-basierte Anwendungen erkennen diesen Umsatz und passen die Paketgröße durch Reduktion an, doch Entertain beherrscht dies nicht und ist ohnehin UDP-basiert.

Der Fehler kann aber auch in einer zu großen Paketgröße liegen, wobei der Router dann wartet, bis er ausreichend IPTV-Pakete gesammelt hat, um sie gemeinsam in eine WLAN-Datenpaket zu verpacken und zu senden. Der Client empfängt dann zwar mehrere Pakete auf einmal aber eben mit Verzögerung und u.U. ungleichen Laufzeiten. Geht ein WLAN-Paket durch Störungen fehlen gleich mehrere IPTV-Pakete und es gibt Bildstörungen oder Aussetzer.

Hintergrund Paketgrößen und MTU:
Ein Ethernet (LAN)-Frame bzw. Paket ist normalerweise 1518 Bytes groß (VLANs und Q-in-Q-tagging außen vor gelassen). Zieht man den Header ab, so verbleiben 1500 Bytes, was auch als maximum transmission unit (MTU) bezeichnet wird.
Beim Internetzugang über xDSL werden die Pakete mittels PPPoE-Protokoll eingepackt, was weitere 8 Bytes kostet
Bei der kabelgebundenen Übertragung tritt das Problem übrigens nicht auf, da die maximale IP-Paketgröße aus dem Internet bei 1500 Bytes MTU (Ethernet-Paketgröße) abzüglich PPPeE-Header bei 1492 Bytes liegt.
Beim Versand eines IP-Datenpaketes fallen für den IP-Header 20 Bytes weg, was die Nutzlast auf 1472 Bytes reduziert.
Mittels ping-Kommando kann man ein ICMP-Datenpaket versenden es mit do-not-fragment-Flag versehen, um die maximale Paketgröße zu ermitteln.
Da ICMP wiederum einen Header von 8 Bytes hat, führt folgendes Kommando auf einem DSL-Anschluss zum Erfolg:
ping -f spiegel.de -l 1464

Die Lösung liegt in der Anpassung zweier Werte in den WLAN-Einstellungen der alternativen Firmwares DDWRT/OPENWRT.
Die 802.11n-Pakatgröße beträgt normalerweise 2346 Bytes. Es wird deutlich, dass ein IP-Datenpaket mit maximal 1472 Bytes ohne Fragementierung genau einmal reinpasst. Für ruckelfreies IPTV sollte der Router also genau ein IP-Paket in ein WLAN-Paket packen und dieses dann sofort abschicken. Ein Entertain Multicast-IPTV-Paket ist typischerweise 1370 Bytes groß (Protocol 2048 (ip), IP Protocol 17 (udp), Size 1370, IP Packet Size 1356, IP: IP Header Size 20, TOS 32,..)
Der Wert müsste also so gewählt werden, dass ein Entertain-Paket nicht fragmentiert wird und zugleich nicht zwei Entertain-Pakete in einem WLAN-Paket landen. Zugleich sind aber weitere IP-Pakete auf dem WLAN-Interface unterwegs diese beanspruchen durchschnittliches nicht die volle Größe. Darüber hinaus senden PCs im lokalen Netz 1500 Bytes großes Ethernetframes.
Es lässt sich daher keine Patentlösung finden, die sich an einer bestimmen Paketgröße orientiert.
Man ist daher gezwungen, die WLAN-Datenpaketgröße so klein zu wählen, dass sowohl typische Standard-Ethernetframe als auch IPTV-Datenpakete zügig abtransportiert werden.

Neben der Fragmentierungsschwelle verwendet das WLAN-Protokoll 802.11n noch das RTS-CTS (Request to Send / Clear to Send)-Protokoll u.a. um zu prüfen, ob der Kanal frei ist und um Kollisionen und damit einhergehende verlorene oder defekte Pakete zu vermeiden. Die Einstellung „RTS Treshold“ legt fest, ab welcher Paketgröße WLAN-Accesspoint und Client das RTS-CTS-Protokoll verwenden müssen. Die WLAN-Paketgröße muss also kleiner oder gleich der RTS Treshold liegen, sonst wird letztere niemals überschritten.

Den Lösungsvorschlag habe ich nach einiger Recherche hier gefunden und er basiert darauf, Standard-Ethernet-Paket mit  1500 Bytes Größe (=MTU) in zwei WLAN-Pakete aufzuteilen und empfiehlt eine Fragmentation Treshold von 784 Bytes (1500 Bytes Framesize / 2 = 750 Bytes Nutzlast + 34 Bytes Overhead für Header).
Dem geht einher, das RTS-CTS-Protokoll ab einem Drittel Ethernet-Frame zu verwenden, also einer RTS Treshold von 534 Bytes.

Im Falle der Entertain IPTV-Datenpakete, die 1370 Bytes groß sind, wird das RTS-CTS-Protokoll verwendet und es wird auf zwei WLAN-Pakete fragmentiert.