Multimedia-Kommunikation über WLAN – Wie lässt sich Qualität sicherstellen?

Kommentieren Drucken


Das gute alte Tischtelefon hat offensichtlich ausgedient. An seine Stelle treten komplexe Kommunikationslösungen. Die Telefonie ist nur noch einer von vielen Diensten. Sie wird ergänzt durch verschiedenartigste Video-Anwendungen, Konferenzlösungen, Erreichbarkeits-Management, Messaging-Systeme und die Integration verschiedenster Anwendungen. Das alles lässt sich nur dann sinnvoll nutzen, wenn die Teilnehmer mobil sein können. Die Mobilität der Teilnehmer ist in der Tat der wesentliche Mehrwert moderner Kommunikationslösungen.

Neben dem Mobilfunk kommt dabei insbesondere im Enterprise-Bereich dem Wireless LAN eine herausragende Bedeutung zu. Nur leider sagt man dem WLAN nach, für Echtzeitaufgaben nicht besonders geeignet zu sein. Was ist also zu tun? Wie können WLAN für diese zusätzliche Aufgabe ertüchtigt werden?

Zunächst erlauben Sie mir eine Begriffsbestimmung: „Echtzeitfähigkeit“ ist wahrscheinlich nicht wirklich vonnöten. In der einschlägigen Literatur fand ich dazu folgende Definition: „Ein Rechnersystem wird dann als Echtzeitsystem bezeichnet, wenn es in eine Umgebung mit Sensoren, Meßinstrumenten und Aktoren eingebettet ist und auf die Signale, die von dieser Umgebung kommen, innerhalb von deterministischen Antwortzeiten reagiert“ (Zitat aus „Schnittstellen für einen Betriebssystem-Corechner in Echtzeitumgebungen“, Dipl.-Ing. Behrooz Moayeri, 1992).

Der Fokus der Echtzeitfähigkeit liegt also auf den deterministischen Antwortzeiten. Es lässt sich vorhersagen, nach welcher Zeit ein Echtzeitsystem geantwortet haben wird. Das ist leider in WLAN prinzipiell nicht möglich. Da es sich um eine Funktechnik handelt, ist immer auch mit Störungen zu rechnen, die eine deterministische Antwort vereiteln können. Im Rahmen des vorliegenden Artikels bevorzuge ich demzufolge den Begriff der Multimedia-Kommunikation.

Betrachten wir zunächst das Wesen der Multimedia-Kommunikation. Eines dieser „vielen Medien“ ist sicher die Bereitstellung von Dateien jeglicher Art. Dies wird bereits seit langem von WLAN geleistet. Gleiches gilt für die typischen Inhalte Web-basierter Anwendungen. Beides basiert normalerweise auf dem Transmission Control Protocol (TCP), das als sehr robust gilt. Insbesondere können Paketverluste den Inhalten der Kommunikation nichts anhaben. TCP wiederholt verlorene Pakete solange, bis sie vom Empfänger als angekommen bestätigt werden. Der Anwender erlebt dies lediglich als Verzögerung.

Anders sieht es mit Voice und Video aus. Der Anwender mag keine Verzögerungen, die sich in Sprachpausen und ruckelnden Bildern bemerkbar machen. Man verzichtet im Sinne einer geringen Übertragungszeit auf die Sicherheitsmechanismen des TCP und setzt stattdessen das User Datagram Protocol (UDP) ein. Wenn hierbei Pakete verloren gehen, wird auf deren Neuübertragung verzichtet. Stattdessen ersetzt der Empfänger die fehlende Information durch selbst berechnete Werte. Der Paketverlust wird dem hörenden bzw. zuschauenden Menschen verschleiert. Daher bezeichnet man diese Verfahren auch gerne mit dem Begriff „Loss Concealment“.

Die Anforderungen an das „Loss Concealment“ sind unterschiedlich. Fehler in der Sprach-Übertragung lassen sich relativ einfach überdecken. Versuche im ComConsult-Labor zeigen, dass bei manchen Telephonen bis zu 10% Paketverluste von einem Zuhörer kaum wahrgenommen werden. Anders sieht es bei der Videoübertragung aus. Hier können schon 1% verlorene Pakete zu erheblichen Bildstörungen führen. Darüber hinaus belegt Video deutlich höhere Bitraten als Sprache mit zum Teil erheblichen Schwankungen – je nach Bildinhalt. Letztlich hängt es vom verwendeten Codec ab, welche Bitrate erforderlich ist und wie robust die Übertragung gegen Paketverluste ist. Die Bitraten moderner Video Codecs liegen üblicherweise im einstelligen Megabit/s-Bereich.

Bei der Auslegung von WLAN für die Multimedia-Kommunikation sind also zwei Dinge zu berücksichtigen

  1. Die Kapazität des WLAN muss so groß sein, dass alle anfallende Multimedia-Kommunikation gleichzeitig übertragen werden kann. Hierzu sind zum einen entsprechend leistungsfähige WLAN-Techniken bereitzustellen. Zum anderen muss die Größe der WLAN-Funkzellen so gewählt werden, dass nicht zu viele Teilnehmer diese zur gleichen Zeit nutzen werden.
  2. Es ist dafür Sorge zu tragen, dass die Multimedia-Kommunikation nicht von anderer („unwichtiger“) Kommunikation behindert wird. Entsprechende Verfahren werden bekanntlich unter dem Begriff Quality of Service (QoS) zusammengefasst.

Kapazität des WLAN

Auf beides werde ich im Folgenden eingehen. Beginnen wir mit der Kapazität des WLAN: Ein WLAN der verbreiteten Technik gemäß IEEE 802.11n leistet bis zu 200 Mbit/s – netto. Die modernsten heute verkauften WLAN-Komponenten (IEEE 802.11ac „Wave 1“) schaffen sogar fast 1 Gbit/s netto. Wohlgemerkt, unter optimalen Bedingungen. Wie diese Bedingungen aussehen und warum das so ist, habe ich in früheren Artikeln bereits im Detail erläutert. Tatsache ist: Um derart hohe Bitraten erzielen zu können, bedarf es einer sehr hohen Dichte an WLAN Access Points. Die Faustregel lautet „ein Access Point pro Raum“. Eine hohe Anzahl von Access Points scheint also eine hohe Kapazität im WLAN schaffen zu können. Leider sieht das in der Praxis ganz anders aus.

Nehmen wir als Beispiel ein „Horrorszenario“ für jeden WLAN-Planer: Das Regallager. Dort sind Access Points oft an den Hallendecken montiert, so dass sie die in die „Schluchten“ zwischen den Regalen strahlen. Fahrwege von Staplern und andere Arbeitsbereiche werden dadurch scheinbar gut ausgeleuchtet. Allerdings gibt es in diesen Umgebungen immer wieder Probleme. Stationen haben zwar guten Empfang, d.h. die Access Points werden mit guter Signalstärke empfangen. Kommunikation ist jedoch nur mit schlechter Performance oder überhaupt nicht möglich. Anders ausgedrückt: Es gibt zwar viele Access Points, dennoch stellt das WLAN keine Kapazität bereit. Woran liegt das?

WLAN beherbergen eine Vielzahl von Endgeräten unterschiedlichster Art. Hochmoderne und ältere. Kompatibilität ist eine wesentliche Anforderung, d.h. alle Endgeräte müssen kommunizieren können. Daher werden in den meisten mir bekannten WLAN alle möglichen Bitraten unterstützt, von der schnellsten (siehe oben) bis zur langsamsten. Je langsamer jedoch die Bit-
rate, desto weniger Signalstärke wird für eine fehlerlose Übertragung benötigt. Auf diesen Zusammenhang gehe ich etwas tiefer ein.

In Bild 2 erkennen Sie Werte für Mindest-Signalstärken, die ich dem Datenblatt eines Herstellers entnommen habe. Der entsprechende Access Point unterstützt IEEE 802.11ac „Wave 1“ mit 80 MHz Kanalbandbreite und MIMO[1] mit 3 Spatial Streams. Der Access Point unterstützt natürlich auch die älteren Verfahren, also z.B. gemäß IEEE 802.11n und IEEE 802.11a. Vergleichen wir die drei eingekreisten Werte:

  • Wenn der Access Point gemäß IEEE 802.11n mit 3 Spatial Streams und der hierbei „schnellsten“ Modulation 64 QAM betrieben wird (entsprechend 450 Mbit/s), benötigt er eine Mindest-Signalstärke von -72 dBm.
  • Wird der Access Point im 11ac-Modus mit 256-QAM und 80 MHz Kanalbandbreite betrieben (1,3 Gbit/s), so benötigt er ein Signal von -61 dBm. Das ist 11 dB mehr und entspricht einer erforderlichen Leistungserhöhung von gut dem 10fachen. Um Daten mit 1,3 Gbit/s zu übertragen, muss die Signalstärke 10mal höher sein als bei 450 Mbit/s.
  • Der Access Point sendet gewisse Pakete, insbesondere die so genannten Beacon Frames, mit der langsamsten möglichen Bitrate. Hierfür werden besonders robuste Modulationen verwendet, wie die BPSK[2]. Der betrachtete Access Point benötigt zum fehlerlosen Empfang dieser Signale nur ein vergleichsweise schwaches Signal von -90 dBm.

Eine geringere Signalstärke impliziert in der Funktechnik immer eine höhere Reichweite. Dies habe ich in der Bild 3 zu illustrieren versucht. Man erkennt die drei oben genannten Signalstärken und die damit zu überbrückenden Entfernungen im „Freiraum“, d.h. ohne Hindernisse, Reflektionen, usf. Es ist zu erkennen, dass Pakete mit der höchstmögliche Bitrate nur 60 Meter weit reichen, wohingegen die Beacon Frames mehr als einen Kilometer weit „fliegen“.

Die Auswirkungen auf das WLAN im Regallager sind erschreckend: Die Access Points hören sich gegenseitig zu gut; schließlich gibt es zwischen den Access Points keine Hindernisse in Form von Regalen oder Wänden. Beacon Frames aller Access Points sind in der gesamten Halle zu empfangen. Dummerweise belegen die Beacon Frames eine relativ große Zeitspanne. Das liegt trivialerweise daran, dass sie mit der geringstmöglichen Bitrate ausgesandt werden. Diese Zeit ist für jegliche Datenübertragung verloren. Anders ausgedrückt: Im geschilderten Szenario vertilgen die Beacon Frames einen erheblichen Teil der zur Verfügung stehenden WLAN-Kapazität.

Wie kann man dem abhelfen? Nun, eine Halle ist sozusagen der Worst Case für WLAN mit hohen Bitraten. Grundsätzlich muss die Ausleuchtung nämlich so erfolgen, dass die Clients an jedem Ort mindestens einen Access Point sehen können. Gleichzeitig dürfen sich die Access Points untereinander nicht sehen. Wenn Access Points an der Hallendecke montiert werden sollen, wären also mindestens Richtantennen einzusetzen. Das reicht jedoch erfahrungsgemäß nicht. Funkwellen werden an den Oberseiten der Regale und der darin eingebrachten Materialien reflektiert und erreichen so doch die benachbarten Access Points. Vielleicht ist es besser, die Access Points an den Wänden anzubringen und von dort mit stark bündelnden Richtantennen in die „Schluchten“ zwischen den Regalen hineinstrahlen zu lassen. Vielleicht hat man Erfolg, wenn man die Access Points von vornherein in den „Schluchten“ anbringt, so dass man die abschirmende Wirkung der Regale ausnutzen kann. Eine allgemeine Aussage ist leider nicht möglich, zu sehr hängt es von der Beschaffenheit der Umgebung ab.

In Büroumgebungen sieht es etwas besser aus. Hier sorgen Wände und Decken für eine natürliche Abgrenzung zwischen den Access Points. Aber Wände verschlechtern natürlich auch die Verbindung der mobilen Clients zu den Access Points.

Letztlich besteht die Lösung darin, die Reichweite des WLAN zu begrenzen. Oder anders ausgedrückt: Die Bitrate in WLANs sollte so homogen wie möglich sein! Das wird dazu führen, dass Sie es zukünftig mit zwei verschiedenen Zellplanungen zu tun haben:

  • Zellplanung für „Legacy Devices“, also Bestandssysteme im 2,4-GHz-Band. Hier sollte die Mindest-Bitrate auf 11 Mbit/s heraufgesetzt werden, da man davon ausgehen kann, dass es keine Endgeräte mehr gibt, die auf 1 oder 2 Mbit/s angewiesen sind (was im Einzelfall zu prüfen wäre). Die maximale Bitrate in diesem Band wird auf 54 Mbit/s begrenzt.
  • Zellplanung für „High-Speed Devices“, also moderne Endgeräte im 5-GHz-Band. Hier dürfen Sie die Mindest-Bitrate deutlich heraufsetzen, z.B. auf 24 oder 54 Mbit/s. Es ergeben sich Zellen, die deutlich kleiner sind als ihre Pendants im 2,4-GHz-Band. Da es aktuell im Enterprise-Bereich überwiegend Dual-Band Access Points gibt, wird zukünftig an zahlreichen Access Points das 2,4-GHz-Radio abgeschaltet bleiben.

Darüber hinaus sollten Sie darauf achten, dass nur wenige WLANs parallel existieren. Wenn Sie nicht zufällig über eine WLAN-Lösung verfügen, die ein „Single SSID Design“ unterstützt, sollten Sie sich auf beispielsweise 3 WLANs begrenzen, für Office, Produktion und Gäste. Denn für jedes WLAN werden eigene Beacon Frames benötigt, die an der wertvollen Kapazität nagen.

QoS im WLAN

Quality of Service (QoS) stützt sich bekanntlich auf drei Säulen:

  • Klassifizierung: Netze bestehen heute (noch) aus autonomen Komponenten. Jede Komponente betrachtet die eingehenden Pakete völlig unabhängig davon, was vorher mit ihnen passiert ist. Damit das Paket einer bestimmten Dienstegüte zugeordnet werden und entsprechend weitergeleitet werden kann, muss es eine Markierung aufweisen. Diese Markierung wird entweder bereits vom Endgerät vorgenommen oder aber von der Netzkomponente, an der das Paket in das Netz eingeleitet wird.
  • Queuing: Die Netzkomponente ordnet die Pakete anhand ihrer Markierung in eine Warteschlange (Queue) ein. Die einfachste Variante besteht aus einer „Priority Queue“, die quasi als Überholspur an allen anderen Warteschlangen vorbeiführt. Die übrigen Queues werden nur bedient, sobald die Priority Queue leer ist. Demgegenüber basiert „Rate Queuing“ auf mehreren Warteschlangen, die mit einer gewissen Häufigkeit nacheinander abgefragt werden.
  • Verkehrs-Management: Es wacht darüber, dass Datenverkehr bestimmter Klassen bestimmte Grenzwerte einhält. Insbesondere sorgt es dafür, dass Verkehr in der Priority Queue den übrigen Verkehr nicht vollständig lahmlegt. Eine zuweilen als „Policer“ oder „Packet Shaper“ bezeichnete Instanz erledigt das, indem sie entweder Pakete verwirft oder diese in eine Warteschlange sehr niedriger Priorität schickt.

Bereits im Ur-WLAN von 1999 gab es Ansätze, die als Basis für eine Umsetzung von QoS gedacht waren. Neben dem Standard-Modus für den Medienzugang, der auf einem CSMA[3]-Verfahren basiert, wurde ein zweiter Modus definiert. Die so genannte Point Coordination Function (PCF) sieht eine zentrale Steuerung des Medienzugangs vor. In regelmäßigen Zeitabständen fragt der „Point Coordinator“ (als Teil des Access Points implementiert) mobile Clients ab und gibt ihnen die Möglichkeit, Daten ohne weitere Wartezeit auszusenden. Der Access Point stellt damit sicher, dass immer nur genau eine Station senden kann; Kollisionen treten bei PCF nicht auf. Leider bestimmt der WLAN-Standard die regelmäßigen Zeitabstände für die Abfrage als Vielfaches des Beacon-Intervalls. Bestenfalls kann also der Access Point alle 100 Millisekunden seine Stationen abfragen. Es ist sofort klar, dass diese Zeitspanne für die meisten Multimedia-Anwendungen erheblich zu lang ist. Bei der VoIP-Telefonie ist beispielsweise alle 20 Millisekunden mit einem Paket zu rechnen. Wahrscheinlich ist das der Grund dafür, dass PCF niemals implementiert wurde, sieht man einmal von einer speziellen Variante ab, die von Siemens für die PROFINET-Kommunikation über WLAN implementiert wurde (iPCF).

In 2004 veröffentlichte das IEEE unter der Bezeichnung 802.11e eine Erweiterung des WLAN-Standards, die sich mit QoS beschäftigte. Das nun als Hybrid Coordination Function (HCF) bezeichnete Verfahren vereint eine verbesserte Form der PCF mit einem neuartigen Ansatz für die Priorisierung des Medienzugriffs bei CSMA. Wie zu erwarten, hat es für die PCF-basierende Variante bis heute keine Implementierungen gegeben, bleibt es doch bei den regelmäßigen Zeitabständen in Vielfachen von 100 Millisekunden. Die Erweiterung des CSMA-Verfahrens ist jedoch heute allgemein verfügbar. Der Standard bezeichnet sie als Enhanced Distributed Channel Access (EDCA), gebräuchlicher ist jedoch die Bezeichnung, die von der Wi-Fi Alliance (http://www.wi-fi.org) dafür gewählt wurde: Wi-Fi Multimedia (WMM).

Eine WLAN-Station, die WMM implementiert, unterstützt demzufolge vier Verkehrsklassen unterschiedlicher Priorität, im Standard als „Access Categories“ (AC) bezeichnet:

  • Voice Priority: Sprachkommunikation besitzt die höchste Priorität und damit die geringste Latenz. Pakete aus dem LAN werden in diese Klasse eingeordnet, wenn die Priorität (Priority Code Point gem. IEEE 802.1Q) im VLAN-Tag den Wert 7 oder 6 enthält.
  • Video Priority: Auch Video-Daten werden priorisiert übertragen, jedoch der Sprachkommunikation nachgelagert. Pakete aus dem LAN werden in diese Klasse eingeordnet, wenn die Priorität im VLAN-Tag den Wert 5 oder 4 enthält.
    Best Effort Priority: Dies ist die Standard-Priorität, d.h. Daten ohne spezielle QoS-Anforderungen werden in dieser Klasse übertragen. Pakete aus dem LAN werden in diese Klasse eingeordnet, wenn die Priorität im VLAN-Tag den Wert 0 oder 3 enthält.
  • Background Priority: Damit besteht die Möglichkeit, bestimmten Datenverkehr nachrangig zu behandeln. Pakete aus dem LAN werden in diese Klasse eingeordnet, wenn die Priorität im VLAN-Tag den Wert 1 oder 2 enthält.

Die IEEE 802.11e schlägt eine Implementierung auf Basis von vier Warteschlangen vor, je eine pro Verkehrsklasse. Jeder dieser Warteschlangen muss ihre Daten in das gemeinsame Medium Funk abgeben und unterliegt dabei den Beschränkungen des CSMA-Verfahrens. Jede Warteschlange verhält sich bezüglich des Shared Medium wie ein unabhängiges WLAN-Radio.

Damit eine Priorisierung der Daten entsprechend der Verkehrsklasse erfolgt, hat man sich einen Trick einfallen lassen: Pakete niederer Priorität müssen einfach länger warten. Möchten also zwei Warteschlangen gleichzeitig ein Paket aussenden, wird dasjenige der höheren Verkehrsklasse das Medium mit einer gewissen Wahrscheinlichkeit zuerst belegen. Bild 4 illustriert das Verfahren. Wie im WLAN üblich, dürfen Pakete nicht sofort gesendet werden, sobald das Medium als frei erkannt wurde. Zunächst müssen alle Warteschlangen eine bestimmte Zeit lang warten; das wird Inter-Frame Spacing (IFS) genannt. Darauf folgt eine weitere Wartezeit, die „gewürfelt“ wird; sie wird als Contention Window (CW) bezeichnet. Bei EDCA hängen beide Zeiten von der Verkehrsklasse ab. Das IFS wird umso länger, je niedriger die Verkehrsklasse ist. Gleiches gilt für den Wertebereich des Contention Window. Niedrigere Verkehrsklassen müssen sozusagen mehrere Würfel werfen.

Dieser Trick funktioniert. Man kann nachweisen, dass viel Verkehr in Voice oder Video Priority den übrigen Datenverkehr lahmlegt. Ganz wie bei einer Priority Queue in Switches. Über das Verkehrsmanagement in WLAN ist also auch noch etwas zu sagen, ebenso über die Klassifizierung der Pakete.

QoS-Klassifizierung im WLAN

Oben wurde bereits erwähnt, dass die Priorität (Priority Code Point gem. IEEE 802.1Q) im VLAN-Tag über die Verkehrsklasse entscheidet. Es muss dafür gesorgt werden, dass hier die richtigen Werte gesetzt sind, sobald das Paket vom Ethernet in den Access Point (respektive WLAN Controller) eintritt. Das ist technisch grundsätzlich beherrschbar. Die Endgeräte der entsprechenden Anwendungen, z.B. VoIP Phones oder Gateways, markieren Pakete üblicherweise im IP Header mittels Distributed Services Code Point (DSCP). Netzkomponenten können diese Markierungen auswerten und entsprechend den Priority Code Point setzen. Soweit so gut. Aber was ist mit Endgeräten, die keine Markierung von Paketen vornehmen? Was ist mit der unübersehbaren Zahl mobiler „Gadgets“, auf denen die schöne neue bunte Kommunikations-Welt genauso gut funktionieren soll? Die triviale Antwort lautet: Man verpflichte die Programmierer der Apps, entsprechende Maßnahmen zu ergreifen. Und natürlich die Hersteller der Endgeräte, dies in den WLAN-Treibern zu unterstützen und entsprechende Schnittstellen (APIs) bereitzustellen. Ob und wie das in Zukunft gelingen wird, kann ich leider nicht einschätzen. Es gibt jedoch Alternativen.

Kommunikations-Anwendungen verfügen im Allgemeinen über zentrale Komponenten, die eine gewisse Kenntnis über die Kommunikationsbeziehungen haben. Wenn diese zentralen Komponenten nun das WLAN entsprechend steuern könnten, käme man der Lösung einen Schritt näher. Mit anderen Worten: Nicht die Endgeräte klassifizieren die Daten, sondern das Netz ordnet sie anhand von Informationen aus den Anwendungen direkt in die richtigen Verkehrsklassen ein. Dafür kennen wir den knackigen Begriff des Software Defined Networking (SDN).

Das erste mir bekannte Beispiel, das diesen Weg geht, ist Microsoft Lync (das demnächst in „Skype for Business“ umbenannt werden soll). Die aktuelle Version von Lync lässt sich um eine Komponente erweitern, die eine Schnittstelle zum Netz bereitstellt. Microsoft nennt das „Lync SDN API“. Das funktioniert wie folgt:

  • Das Lync Server Front End vermittelt Kommunikation zwischen den Endgeräten. Es ist also über alle Medienströme informiert, die in seiner Hoheit generiert werden.
  • Das Lync Server Front End leitet diese Informationen an den Lync Dialog Listener weiter.
  • Der Lync Dialog Listener bearbeitet die Informationen und überführt sie in ein XML[4]-Format. Die so kodierte Information sendet er an den Lync SDN Manager.
  • Der Lync SDN Manager führt die Informationen aus allen Lync Dialog Listeners zusammen und leitet sie an Netzwerk-Management-Systeme weiter. Die Information ist ebenfalls in XML kodiert, und die Kodierung wurde von Microsoft offengelegt.

Ein Netzwerk-Management-System kann z.B. ein WLAN Controller sein. Und in der Tat unterstützt inzwischen mehr als ein Hersteller von WLAN Equipment dieses API. Beispiele dafür sind das „Lync Over Aruba Wi-Fi Validated Reference Design“ von Aruba Networks oder die „OneFabric Connect Integration with Microsoft Lync SDN API“ von Extreme Networks. Die Information über die Medienströme wird bei diesen Lösungen an den zentralen WLAN Controller gemeldet. Dieser leitet die Information entsprechend formatiert an die übrigen Komponenten der WLAN-Lösung weiter.

Empfängt ein Access Point ein WLAN-Paket von einem mobilen Lync Client, klassifiziert und markiert er es derart, dass es im LAN mit passender Verkehrsklasse bis zum WLAN Controller übertragen wird. Der WLAN Controller leitet das Paket mit QoS weiter zu einem Access Point, der es in der richtigen Verkehrsklasse per EDCA an das Ziel überträgt.

Verkehrs-Management im WLAN

Klassifizierung und Queuing lassen sich mit den beschriebenen Mechanismen im Wesentlichen realisieren. Wie steht es aber um das Verkehrs-Management? Wie lässt sich also beispielsweise verhindern, dass eine große Zahl von Lync Clients den Rest des WLAN lahmlegt? In der Tat ist das eine der großen Sorgen bei einigen meiner Kunden, die WLAN in der Fertigung produktiv einsetzen. Die große Zahl privater Endgeräte, die sich naturgemäß auch in solchen Bereichen finden, belastet schließlich die Funkzellen mit allerlei Management Frames, selbst wenn gar keine Datenübertragung stattfindet.

WLAN selbst bringt im Rahmen der IEEE 802.11e ein Verfahren zur Reservierung von Ressourcen mit, das wie folgt funktioniert:

  • Der Client informiert den Access Point darüber, dass er einen Medienstrom mit bestimmten Charakteristika übertragen möchte. Er verwendet dazu ein Kommando namens „Add Traffic Stream“ (ADDTS).
  • Die Charakteristika des Medienstromes werden über die „Traffic Specification“ (TSPEC) definiert. TSPEC enthält unter anderem die Richtung des Datenstroms, maximale und mittlere und Mindest-Bitraten, die Länge von Datenblöcken (Bursts) und das angeforderte Verfahren für QoS (z.B. EDCA).
  • Der Access Point entscheidet darüber, ob die Ressourcen bereitstehen. Falls nicht, weist er die Anforderung des Client ab.
  • Am Ende gibt der Client die Ressourcen wieder frei mittels „Delete Traffic Stream“ (DELTS).

Immerhin! Die Frage bleibt, was ein Client machen soll, der vom Access Point die benötigten Ressourcen nicht erhält. Er kann es bei einem anderen Access Point versuchen. Er kann es später einfach nochmal probieren oder dem Anwender eine Fehlermeldung präsentieren. Und wer weiß, vielleicht ist ja der Nachbar-Access-Point auch schon ausgelastet. Es wird klar, dass diese Lösung zwar die Werkzeuge für die Information der Clients bereitstellt, nicht aber eine sinnvolle Anwendung dafür. Eine solche Anwendung kann nur funktionieren, wenn sie über alle Ressourcen aller Access Points informiert ist.

Und hier kommt wieder das SDN ins Spiel. Wenn eine Anwendung in der Lage ist, das Netz über die zu erwartenden Verkehrsströme zu informieren, dann könnte das Netz im Gegenzug die Anwendung darüber in Kenntnis setzen, welche Ressourcen an welchen Punkten des Netzes bereitstehen. Die Anwendung könnte dann entsprechende Aktionen ergreifen, bis hin zu einer sinnvollen Fehlermeldung. Die Betonung liegt dabei auf „sinnvoll“. Denn was nützt es dem Anwender, wenn es wie üblich heißt: „Allgemeiner Netzwerkfehler“. Besser wäre ein „Vorübergehend alle Ressourcen belegt“ mit einer nachfolgenden Mitteilung, wenn wieder Ressourcen frei sind. Aber so weit ist – um zum Microsoft-Beispiel zurückzukommen – das Lync SDN API noch nicht. Wenn Sie die XML-Pfeile in Bild 5 betrachten, erkennen Sie deren Richtung. Ein Rückweg vom Netz zum Lync Frontend Server ist nicht vorgesehen. Jedenfalls nicht nach meinem bisherigen Kenntnisstand.

Ein neuer WLAN-Standard adressiert Voice und Video

Im Mai 2012 kam – einigermaßen unbemerkt – eine Erweiterung des WLAN-Standards mit dem Titel „MAC Enhancements for Robust Audio Video Streaming“ heraus (IEEE 802.11aa). Dieser Standard adressiert einige Schwächen der WLAN im Zusammenhang mit Streaming-Anwendungen und fügt neue Mechanismen hinzu. Einige versuche ich in der Folge kurz zusammenzufassen.

Die Beschränkung auf je eine Verkehrsklasse für Voice und Video reicht möglicherweise nicht aus. Stellen Sie sich vor, in Ihrem Unternehmen wird Video einerseits für Videokonferenzen benötigt, die besonders oft von der Geschäftsleitung genutzt werden. Andererseits stellen Sie für bestimmte Zwecke Video-Streaming bereit. Hier kann es sinnvoll sein, die Videokonferenzen gegenüber dem Streaming zu bevorzugen. Oder umgekehrt, wenn per Streaming z.B. die Bilder wichtiger Überwachungskameras betrachtet werden müssen. Wie dem auch sei, IEEE 802.11aa spaltet die Verkehrsklassen Voice und Video in je zwei Unterklassen auf. Insgesamt lassen sich nun 6 Warteschlangen einrichten, wie in Bild 7 dargestellt. Da das Medienzugangsverfahren (EDCA) aber nach wie vor nur vier „Access Categories“ kennt, werden die Warteschlangen-Paare für Voice und Video zusammengeführt. Hier kann eine Wichtung stattfinden, d.h. die Warteschlange „Voice“ wird beispielsweise doppelt so oft abgefragt wie die Warteschlange „Alternate Voice“.

Neben dieser Erweiterung der QoS-Fähigkeit adressiert IEEE 802.11aa insbesondere das Problem der überlappenden Zellen, als „Overlapping Basic Service Sets“ (OBSS) bezeichnet. Dabei handelt es sich um das von mir weiter oben beschriebene Problem des Regallagers. Mehrere Access Points auf demselben Kanal hören einander. Und das wird als besonderes Problem für das Video Streaming angesehen. Denn ein Video Stream belegt in dieser Konstellation nicht nur „seine“ WLAN-Funkzelle sondern auch die benachbarten Zellen.

IEEE 802.11aa sieht vor, dass Access Points überlappender Funkzellen sich gegenseitig über die Auslastung der verschiedenen Verkehrsklassen informieren. Sie nutzen dafür die Informationen, die ihnen die Stationen per „Traffic Specification“ (TSPEC) mitgeteilt haben – diese Möglichkeit habe ich im Zusammenhang mit dem Verkehrs-Management bereits erwähnt. Ein Access Point kennt nun die TSPEC seiner eigenen Clients und die der Nachbar Access Points. Der Access Point kann damit ausrechnen, ob die in den sich überlappenden Zellen insgesamt vorhandene WLAN-Kapazität ausreicht, weitere Datenströme zuzulassen. Dieser Mechanismus kann Überlast bei sich überlappenden Zellen verhindern. Eines leistet er jedoch wohlgemerkt nicht: Die Kapazität wird nicht vergrößert. Sie leidet nach wie vor unter der Überlappung, siehe oben.

Eine weiterer Vorschlag der IEEE 802.11aa betrifft aber letztlich doch die verfügbare WLAN-Kapazität im Zusammenhang mit Voice und Video Streaming. Da Streaming normalerweise mit Multicasts einhergeht, lohnt sich eine Optimierung. Bisher konnten Multicasts nämlich auf zwei Weisen versandt werden. Normalerweise wird – wie im LAN üblich – der Multicast genau einmal ausgesandt ohne zu verifizieren, ob die Pakete auch überall angekommen sind. Es findet im Gegensatz zu Unicasts keine Wiederholung bei Paketverlust statt. Damit dennoch eine gute Übertragungs-Qualität erzielt werden kann, können Stationen verlangen, dass Multicasts als Unicasts zugestellt werden. Der Access Point vervielfacht beim so genannten „Directed Multicast Service“ (DMS) das Paket und sendet es nacheinander an alle Multicast-Empfänger. Jeder Empfänger bestätigt den Multicast; bei Paketverlust erfolgt Wiederholung.

Es ist sofort einsichtig, dass DMS erheblich an der WLAN-Kapazität zerrt. IEEE 802.11aa führt zur Verbesserung ein Verfahren namens „Groupcast with Retries“ (GCR) ein. Multicasts werden grundsätzlich mehrfach ausgesandt, um die Wahrscheinlichkeit des fehlerlosen Empfangs bei allen Multicast-Empfängern zu erhöhen. Eine andere Spielart des GCR wählt einige Multicast-Empfänger aus, die den erfolgreichen Empfang von in Blöcken zusammengefassten Multicasts bestätigen. Man geht einfach davon aus, dass, wenn nur die ausgewählten Empfänger die Multicasts bestätigen, auch alle anderen sie empfangen haben werden.

Zusammenfassung

Die Veröffentlichung von IEEE 802.11aa zeigt, dass noch längst nicht alle Möglichkeiten des WLAN ausgereizt sind. Oder anders ausgedrückt: Die Erfinder des WLAN haben erkannt, dass WLAN einige Schwächen aufweist, die sich insbesondere bei der Multimedia-Kommunikation bemerkbar machen. Eine konsequente Umsetzung von Quality of Service ist für die erfolgreiche Multimedia-Kommunikation eine Voraussetzung. Das reicht aber nicht. So muss insbesondere die Anwendung mitspielen. Was nützt es, wenn die WLAN-Funkzellen den Endgeräten Überlast signalisieren und diese weder der Anwendung noch dem Anwender eine sinnvolle Rückmeldung geben können? Eine Kommunikation zwischen Anwendung und Netz scheint hierfür ein vielversprechender Ansatz zu sein, und die Vorstellung des Microsoft Lync SDN API macht Hoffnung, dass die Hersteller sich dieser Herausforderung stellen wollen.

Ich bin jedoch der Überzeugung, dass noch ein weiter Weg zurückzulegen ist, bevor es wirklich funktionierende Lösungen für die von mir geschilderten Problemfelder geben wird. Auch stellt sich die Frage, ob es am Ende wirklich Hersteller-unabhängige Standards geben wird, die eine Vielzahl von Anwendungen und WLAN-Systemen in diesem Sinne miteinander sprechen lassen. Als erste Maßnahme bleibt uns also nur, aus den vorhandenen Komponenten das Beste herauszuholen. Als erstes sind bei der WLAN-Zellplanung neue Wege einzuschlagen.

Literatur

[1] MIMO = Multiple Input Multiple Output, ein Verfahren zur parallelen Übertragung mehrerer Datenströme auf derselben Frequenz

[2] BPSK = Binary Phase Shift Keying, eine zweiwertige Phasenmodulation. QPSK ist eine vierwertige Phasenmodulation und QAM bedeutet Quadratur-Amplitudenmodulation, bei WLAN 16, 64 oder 256wertig.

[3] CSMA = Carrier Sense Multiple Access, ein Medienzugangsverfahren, bei dem Stationen nur unter der Bedingung senden dürfen, wenn sie das Medium zuvor als frei verifiziert haben. Leider kann dieses Verfahren Kollisionen und dadurch ausgelöste Paketverluste nicht verhindern.

[4] XML = Extensible Markup Language, eine auf lesbaren Zeichen basierende Beschreibungssprache für beliebige Inhalte, gerne im Zusammenhang mit Internet-basierenden Anwendungen eingesetzt.

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.