Site icon bintorosoft.com

QoS Monitoring für Telcos: Welche Metriken sind Pflicht?

Red Snapper

QoS Monitoring für Telcos ist der entscheidende Schritt, der aus „QoS ist konfiguriert“ ein tatsächlich messbares Qualitätsversprechen macht. In Provider-Netzen reicht es nicht, DSCP-Klassen zu definieren und Queues zu konfigurieren – Sie müssen jederzeit nachweisen können, dass Voice, Video und andere Premium-Services die vereinbarten SLA-Ziele (Latenz, Jitter, Paketverlust, Verfügbarkeit) wirklich einhalten. Genau hier scheitern viele Betriebsmodelle: Es wird nur die Linkauslastung überwacht, vielleicht noch Interface-Errors, und erst wenn Kunden sich beschweren, beginnt die Suche nach Queue-Drops, Microbursts oder Markierungslücken. Dabei ist QoS ein Zeitfenster-Thema: Kurze Delay-Spitzen, Drop-Cluster oder Policer-Drops von wenigen Sekunden können MOS und Nutzererlebnis massiv verschlechtern, ohne dass der 5-Minuten-Durchschnitt der Auslastung jemals „rot“ aussieht. Ein professionelles QoS Monitoring für Telcos kombiniert deshalb drei Ebenen: erstens Klassen- und Queue-Metriken (was passiert in der QoS-Mechanik), zweitens Service-KPIs (wie fühlt sich Voice/Video an) und drittens End-to-End- und Übergangsmessungen (wo gehen Markierungen verloren, wo entstehen Engpässe). Dieser Artikel zeigt, welche Metriken in einem Telco-Betrieb Pflicht sind, wie Sie sie sinnvoll interpretieren und welche typischen Fehlersignaturen Sie damit zuverlässig früh erkennen.

Warum reine Linkauslastung kein QoS Monitoring ist

Auslastung ist wichtig, aber sie erklärt QoS-Probleme selten vollständig. Voice knackt häufig bei kurzen Congestion-Events, Video friert bei Drop-Clustern, und Signaling wird langsam, wenn Control-Traffic in Best Effort verhungert. Diese Ereignisse sind meist zu kurz, um in Durchschnittsgraphen sichtbar zu werden. Zusätzlich verbergen moderne Netze viele Engpässe hinter Overlays, Firewalls oder rate-limitierten Access-Profilen. Ohne Queue- und Klassenmetriken sehen Sie nicht, ob das Netz „gesund“ ist oder nur „im Mittel nicht voll“.

Pflicht-Metrikgruppe 1: Traffic pro Klasse und Markierungsintegrität

Bevor Sie Jitter oder MOS interpretieren, müssen Sie wissen, ob Traffic überhaupt in den richtigen Klassen läuft. Diese Metriken sind die Basis, um Premium-Inflation und Mapping-Löcher zu erkennen.

Operative Regel: Wenn Premium-Volumen unplausibel wächst oder DSCP-Verteilungen „driften“, ist QoS nicht stabil – selbst wenn QoE-KPIs noch gut aussehen. Premium-Inflation ist meist der Vorläufer von Quality-Events.

Pflicht-Metrikgruppe 2: Queueing Delay und Queue Depth pro Klasse

Queueing ist der Ort, an dem QoS „passiert“. Deshalb sind Queue Depth und Queueing Delay die zentralen Frühindikatoren. In Telco-Netzen sollten Sie diese Werte pro Klasse, pro Engpassinterface und idealerweise als Perzentile überwachen.

Praxisregel: Voice-Klassen (LLQ) sollen sehr niedrige Queue Depth und sehr niedrigen Queueing Delay zeigen. Wenn die Voice-Queue sichtbar „steht“, ist das ein akutes Echtzeitrisiko, selbst ohne Drops.

Pflicht-Metrikgruppe 3: Drops pro Klasse und Drop-Patterns

Für Telcos sind Drops nicht gleich Drops. Entscheidend ist, in welcher Klasse gedroppt wird und ob Drops als Cluster auftreten. Besonders bei Voice und interaktivem Video sind Drop-Cluster deutlich schädlicher als vereinzelte Drops.

Operative Regel: Drops in Premiumklassen sind nicht „normal bei Peak“, sondern ein Design- oder Engpassproblem (Limits zu eng, Burst-Handling fehlt, Fehlklassifizierung, Mapping-Loch).

Pflicht-Metrikgruppe 4: Policer-, Shaper- und Remarking-Metriken

Viele QoS-Probleme entstehen nicht in Queues, sondern an Profilen: Policers schneiden Bursts ab, Shaper glätten, Remarking schiebt Überschuss in andere Klassen. Deshalb müssen Policers und Shaper genauso überwacht werden wie Queues.

Praxisregel: Wenn Sie QoS im Access stabilisieren wollen, ist Shaping am Upstream fast immer ein zentrales Monitoring-Objekt. Ein Upstream ohne Shaping ist häufig eine Bufferbloat-Quelle.

Pflicht-Metrikgruppe 5: SLA-nahe Service-KPIs für Voice

Queue-Metriken zeigen, was das Netz tut. Service-KPIs zeigen, was der Kunde erlebt. Für Telcos sind Voice-KPIs Pflicht, besonders wenn Sprachqualität Teil eines SLA ist.

Wichtig ist die Korrelation: Ein MOS-Drop ohne Queue-Drops kann trotzdem Bufferbloat bedeuten (Queueing Delay-Spitzen). Ein MOS-Drop mit Policer-Drops ist meistens ein Profilproblem.

Pflicht-Metrikgruppe 6: SLA-nahe Service-KPIs für Video

Video ist nicht nur „mehr Bandbreite“. Videoqualität hängt stark von Throughput-Stabilität, Drop-Patterns und Buffering ab. In Telco-Kontexten (UC, WebRTC, Live-Events, IPTV/Streaming) sollten Sie mindestens folgende KPIs etablieren:

Operative Regel: Für Video ist „stabile Throughput-Fenster“ das Ziel. Drops und RTT-Spitzen sind die Hauptfeinde, nicht unbedingt die absolute Bandbreite.

Pflicht-Metrikgruppe 7: Signaling- und Control-Plane-Metriken

Telco-QoS bricht oft nicht zuerst im Media, sondern im Control: wenn Routing, Signaling oder Session-Steuerung instabil wird, steigen Setup Times, Re-Registrations, oder Sessions flappen. Daher sind Control-Plane-Metriken Pflicht.

Ein typischer Fehler ist, QoS nur als Datenplane-Thema zu behandeln. In Telco-Netzen ist Control-Plane-Health ein Teil der QoS-Wahrheit.

Pflicht-Metrikgruppe 8: Interface- und Transportgrundlagen, aber QoS-relevant

Auch klassische Transportmetriken sind Pflicht – nicht als Ersatz für QoS, sondern als Kontext, um QoS-Anomalien richtig zu interpretieren.

Praxisregel: Wenn QoS-Metriken sauber sind, aber QoE schlecht, prüfen Sie physische Fehler, MTU und Security-Hops. QoS kann keine kaputte Physik oder MTU-Blackholes kompensieren.

Messmethoden: Passive Telemetrie, Active Probing und Service-Analytics kombinieren

In Telco-Umgebungen reicht selten eine einzige Messmethode. Ein robustes Monitoring kombiniert:

Wichtig ist die zeitliche Auflösung: QoS-Probleme sind oft Sekundenereignisse. Wenn Ihr Monitoring nur 5-Minuten-Aggregate sammelt, ist das für Echtzeitbetrieb häufig zu grob.

Alarmierungslogik: Welche Schwellenwerte und Signale sind „Incident-würdig“?

Telco-Betrieb braucht klare Regeln, sonst wird QoS-Monitoring zum Datensilo ohne Wirkung. Typische Incident-Trigger:

Eine gute Alarmierung ist korrelationsbasiert: Ein einzelner Counter ist selten die ganze Wahrheit. Wenn aber Voice-Queueing steigt und MOS fällt, ist die Diagnose deutlich schneller.

Typische QoS-Fehlersignaturen und welche Pflichtmetriken sie aufdecken

Pflicht-Dashboards: Was ein Telco-NOC jederzeit sehen sollte

Praxis-Blueprint: Minimalset an Pflichtmetriken für Telco-QoS

Häufige Fragen aus dem Telco-Betrieb

Welche einzelne Metrik ist die wichtigste?

Für Echtzeitdienste ist die wichtigste einzelne Kennzahl „Drops in der Voice-Klasse“. Sobald Voice gedroppt wird, ist die Nutzerqualität gefährdet. Direkt danach folgen Queueing Delay-Spitzen in Voice, weil sie Jitter und „Late Loss“ verursachen können, selbst ohne sichtbare Drops.

Warum brauche ich Perzentile und nicht nur Mittelwerte?

Weil QoS-Probleme oft Sekundenereignisse sind. Mittelwerte glätten genau die Peaks, die MOS und Video-Freezes verursachen. Perzentile (z. B. 95./99.) und Peak-Metriken zeigen Microbursts, Burst-Drops und Bufferbloat deutlich zuverlässiger.

Wie erkenne ich Fehlklassifizierung schnell?

Über DSCP-/CoS-Verteilungen und Classify-Hits: Wenn EF plötzlich mehr Volumen hat, wenn Remarking ansteigt oder wenn eine Klasse „leer“ bleibt, obwohl sie genutzt werden sollte, ist das ein starkes Signal für Mapping-Drift oder Trust-Boundary-Probleme.

Exit mobile version