Site icon BintoroSoft PDF Tools

QoS im Telekommunikationsnetz: Grundlagen für Voice & Video

Quality of Service (QoS) im Telekommunikationsnetz ist die Grundlage dafür, dass Voice- und Video-Dienste auch unter hoher Auslastung stabil, verständlich und ohne störende Aussetzer funktionieren. Während klassische Datenanwendungen wie E-Mail oder Datei-Downloads kurze Verzögerungen meist verzeihen, reagieren Echtzeitdienste extrem empfindlich auf Paketlaufzeit, Schwankungen in der Laufzeit (Jitter) und Paketverluste. Genau hier setzt QoS an: Es priorisiert, steuert und schützt kritische Datenströme, damit Sprach- und Videopakete bevorzugt durch das Netz gelangen. In modernen Telekommunikationsnetzen – von Campus- und Provider-Backbones bis hin zu MPLS- oder SD-WAN-Umgebungen – ist QoS nicht nur „nice to have“, sondern häufig Voraussetzung für SLA-konforme Sprachqualität, ruckelfreie Videokonmunikation und zuverlässige Konferenzsysteme. Dieser Artikel erklärt die wichtigsten QoS-Grundlagen praxisnah: von Verkehrsklassen und Markierung über Queueing und Scheduling bis hin zu typischen Stolperfallen bei der Umsetzung für Voice & Video.

Warum QoS für Voice & Video so entscheidend ist

Voice over IP (VoIP) und Video-Streams sind zeitkritisch. Sie übertragen kontinuierlich kleine Pakete in festen Intervallen. Kommen diese Pakete zu spät, in unregelmäßigen Abständen oder gar nicht an, entsteht sofort ein hör- oder sichtbarer Qualitätsverlust. Drei Kennzahlen sind dabei besonders relevant:

QoS adressiert diese Punkte, indem es Engpässe kontrolliert: Es sorgt nicht dafür, dass „mehr Bandbreite“ entsteht, sondern dafür, dass wichtige Pakete bei Konflikten bevorzugt behandelt werden. Das Ziel ist planbares Verhalten unter Last – besonders an kritischen Übergängen wie WAN-Uplinks, Provider-Edges, Aggregationsknoten oder in Mobilfunk-Transportnetzen.

Die Grundidee: Klassifizieren, markieren, behandeln

Ein solides QoS-Design folgt in der Regel einem klaren Ablauf: Zuerst wird Verkehr erkannt, dann in Klassen eingeordnet, anschließend markiert und schließlich auf allen relevanten Netzabschnitten konsistent behandelt. In Telekommunikationsnetzen ist diese Konsistenz entscheidend, weil Daten häufig mehrere Domänen durchlaufen (Access, Aggregation, Core, Peering/Transit).

Klassifizierung: Welche Pakete sind „Voice“ und welche „Video“?

Bei der Klassifizierung entscheidet das Netzgerät, zu welcher Verkehrsklasse ein Paket gehört. Das kann anhand verschiedener Merkmale passieren:

Best Practice ist: Echtzeitverkehr wird möglichst nah an der Quelle korrekt klassifiziert und markiert. So vermeiden Sie, dass „irgendwo im Netz“ geraten werden muss, was ein Paket ist.

Markierung: DSCP, CoS und die Sprache der Priorität

Markierung bedeutet, dass Pakete ein „Label“ erhalten, das auf dem gesamten Pfad ausgewertet werden kann. Im IP-Netz ist dafür DSCP (Differentiated Services Code Point) im IP-Header üblich. Auf Layer 2 wird oft 802.1p/CoS (Class of Service) in VLAN-Tags genutzt. In der Praxis gilt:

Typische DSCP-Werte (als Orientierung, nicht als starres Gesetz) sind:

Wichtig ist weniger der konkrete Zahlenwert als die klare Vereinbarung: Welche Klasse steht für welchen Dienst, und wie wird diese Klasse an jedem Knoten behandelt?

QoS-Mechanismen im Telekommunikationsnetz

QoS besteht aus mehreren Bausteinen. Ein häufiger Fehler ist, nur „Priority“ zu aktivieren und zu glauben, damit sei alles erledigt. In der Praxis müssen Priorisierung, Pufferung und Schutzmechanismen zusammenspielen.

Queueing: Warteschlangen statt Chaos

Wenn ein Ausgangsinterface mehr Verkehr bekommt, als es gleichzeitig senden kann, muss es puffern. Dazu existieren Warteschlangen (Queues). QoS ordnet Pakete diesen Queues zu. Für Voice & Video sind zwei Aspekte entscheidend: erstens geringe Verzögerung in der Warteschlange, zweitens Schutz vor Missbrauch (damit nicht zu viel „Premium“-Traffic alles verdrängt).

Scheduling: Wer kommt als Nächstes dran?

Scheduling beschreibt, wie Pakete aus den Queues auf das Medium gelangen. Häufige Verfahren sind:

Für Voice ist eine echte Low-Latency-Behandlung üblich, weil Sprachpakete klein und konstant sind und von minimaler Queueing-Verzögerung profitieren. Für Video ist oft ein gewichteter Ansatz sinnvoll, da Video hohe Bitraten erzeugen kann und bei strikter Priorität andere Dienste zu stark verdrängen würde.

Policing: Grenzen setzen, damit QoS fair bleibt

Policing begrenzt Datenraten. Überschreitet ein Flow oder eine Klasse das definierte Limit, werden Pakete verworfen oder heruntergestuft (Remarking). In Telekommunikationsnetzen ist Policing besonders relevant an Übergängen:

Für Voice ist Policing heikel, weil Paketverlust sofort spürbar wird. Deshalb wird Voice häufig so dimensioniert, dass es in der Prioritätsklasse nicht „überläuft“. Für Video kann Policing hingegen ein Mittel sein, um Konferenz- oder Streaming-Traffic in Grenzen zu halten.

Shaping: Glätten statt wegwerfen

Shaping begrenzt ebenfalls die Rate, aber anders als Policing: Es puffert überschüssige Pakete und sendet sie später. Das reduziert Paketverlust und ist bei Video oft vorteilhaft, weil viele Video-Encoder bei moderaten Verzögerungen stabiler reagieren als bei Verlusten. Shaping findet typischerweise am Ausgang statt (Egress), beispielsweise auf WAN-Interfaces oder an Provider-Edges, um einen „ruhigen“ Verkehrsstrom zu erzeugen.

WRED/Drop-Strategien: Intelligentes Verwerfen bei Überlast

Bei Überlast müssen Router/Switches irgendwann Pakete verwerfen. Mit Verfahren wie WRED (Weighted Random Early Detection) lässt sich vermeiden, dass TCP-Streams gleichzeitig in den Kollaps laufen. Für Echtzeitverkehr (RTP) ist WRED selten sinnvoll, weil RTP nicht wie TCP reagiert. Hier ist eher wichtig, dass Echtzeitklassen nicht in Situationen geraten, in denen überhaupt verworfen werden muss – das ist primär ein Design- und Kapazitätsthema.

QoS-Design für Voice: Priorität ja, aber kontrolliert

Voice-Traffic (RTP) ist meist relativ bandbreitenschonend, aber extrem empfindlich gegen Delay und Jitter. Typische Ziele sind: minimale Warteschlangenzeit, stabile Paketlaufzeiten und möglichst kein Verlust. Dafür wird Voice häufig in eine Low-Latency- oder Priority-Klasse gelegt.

Praktisch bedeutet das: Voice bekommt „Express-Spur“, aber diese Spur ist so dimensioniert, dass sie realistische Spitzen abdeckt, ohne zum Dauerstau für alles andere zu führen.

QoS-Design für Video: Bandbreite planen, Fairness sichern

Video ist komplexer als Voice: Bitraten variieren stärker, Auflösungen und Codecs verändern das Profil, und manche Systeme passen die Rate dynamisch an (Adaptive Bitrate). Video ist ebenfalls zeitkritisch, toleriert aber in vielen Fällen minimal mehr Verzögerung als Voice. Dafür sind hohe Durchsatzanforderungen typisch.

Gerade bei Videokonferenzen ist zudem wichtig, zwischen interaktivem Video (Meetings) und nicht-interaktivem Video (Streaming/On-Demand) zu unterscheiden. Interaktives Video verdient in der Regel eine höhere Klasse als reines Streaming.

End-to-End-QoS: Warum „ein Router“ nicht reicht

QoS wirkt nur dann zuverlässig, wenn es durchgängig umgesetzt wird. Ein häufiger Praxisfehler ist, nur am WAN-Router „QoS einzuschalten“, während im LAN keine korrekte Markierung existiert oder im Provider-Netz Markierungen ignoriert bzw. überschrieben werden. End-to-End bedeutet:

Wenn irgendwo auf dem Pfad die Markierungen verloren gehen oder eine Station keine passenden Queues besitzt, verpufft der QoS-Effekt genau dort, wo Sie ihn brauchen.

Typische QoS-Stolperfallen in Telekommunikationsnetzen

Messgrößen und Monitoring: So wird QoS überprüfbar

QoS sollte nicht nur „konfiguriert“, sondern auch validiert werden. Für Voice & Video sind diese Methoden üblich:

Im Telekommunikationsnetz ist außerdem wichtig, Messpunkte entlang der Service-Kette zu setzen: Access, Aggregation, Core und Übergänge. So erkennen Sie schnell, ob Probleme durch Markierung, durch Engpässe oder durch fehlerhafte Queue-Profile entstehen.

Praxisnahes Klassenmodell: Ein verständlicher Startpunkt

Für Einsteiger und Mittelstufe ist ein überschaubares Klassenmodell oft besser als ein hochkomplexes Schema. Ein typisches, gut wartbares Modell kann so aussehen:

Der Schlüssel liegt in der sauberen Definition: Welche Anwendungen gehören wohin, wie werden sie erkannt, wie werden sie markiert, und welche Behandlung erhält jede Klasse an Engpässen?

QoS in MPLS, Carrier Ethernet und modernen WANs

In Telekommunikationsnetzen kommen häufig MPLS oder Carrier-Ethernet zum Einsatz. Hier wird QoS oft in Provider-Traffic-Classes umgesetzt, die intern auf Label-Felder oder service-spezifische Markierungen abgebildet werden. Für Kunden ist wichtig, das Provider-QoS-Profil zu verstehen: Welche DSCP-Werte werden akzeptiert, welche Klassen gibt es, welche Bandbreiten- und Drop-Profile gelten, und wie werden Überschreitungen behandelt (Drop vs. Remark)?

In SD-WAN-Umgebungen kommt eine zusätzliche Ebene dazu: Applikationserkennung, dynamisches Steering über mehrere Links (z. B. Internet + MPLS) und Performance-basierte Pfadwahl. QoS bleibt dabei relevant, weil auch SD-WAN-Overlays letztlich über physische Engpässe laufen. Gute SD-WAN-Designs kombinieren Pfadwahl (Latenz/Jitter/Loss) mit klassischem Queueing/Shaping auf dem Underlay.

Best Practices für eine saubere QoS-Implementierung

Häufige Fragen zu QoS für Voice & Video

Reicht es, Voice auf „Highest Priority“ zu setzen?

Nein. Ohne Begrenzung kann eine Prioritätsklasse andere Dienste verdrängen. Zusätzlich müssen Markierung, Klassifizierung und End-to-End-Behandlung stimmen, sonst wird die Priorität unterwegs wirkungslos.

Ist QoS auch bei „genug Bandbreite“ notwendig?

Oft ja, weil Engpässe nicht nur durch Bandbreite entstehen: Burst-Verhalten, Mikrospitzen, asymmetrische Pfade, Pufferung und Übergänge zwischen Netzen können auch bei scheinbar ausreichend Kapazität zu Jitter und Verlust führen.

Was ist wichtiger: niedrige Latenz oder kein Paketverlust?

Für Voice sind beide wichtig, aber geringe Queueing-Latenz und niedriger Jitter stehen meist an erster Stelle. Für Video kann moderates Shaping (mehr Verzögerung, weniger Verlust) häufig besser sein als aggressives Policing (weniger Verzögerung, mehr Verlust), abhängig vom Einsatzszenario.

Exit mobile version