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.
- Traffic-Volumen pro QoS-Klasse: Bytes/Packets pro Klasse (z. B. Voice/EF, Video/AF, Control, Best Effort). Dauerhaft „zu hohe“ Premium-Last ist ein Alarmzeichen.
- DSCP-/CoS-Verteilung: Histogramm der DSCP-Werte auf Ingress/Egress. Unerwartete Häufungen (z. B. viele EF-Pakete) deuten auf Fehlmarkierung oder fehlende Trust Boundary hin.
- Remarking-Statistiken: wie viele Pakete wurden von einem DSCP-Wert auf einen anderen umgeschrieben? Das zeigt Policy-Verletzungen, Kundemarkierungen oder interne Normalisierung.
- Mapping-Validierung an Übergängen: DSCP->802.1p CoS, DSCP->MPLS-TC/EXP, Inner->Outer-DSCP (Tunnel). Ein „QoS-Loch“ entsteht oft genau hier.
- Classify-Hits: Trefferzahlen pro Class-Map/Policy. Wenn eine Klasse erwartungsgemäß Traffic haben sollte, aber „0 Hits“ zeigt, greift die Klassifizierung nicht.
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.
- Queue Depth: Füllstand der Queue (Pakete/Bytes). Steigende oder „sägende“ Muster zeigen Congestion-Wellen oder Microbursts.
- Queueing Delay: abgeleitet aus Queue Depth und Service Rate oder direkt gemessen (falls verfügbar). Für Echtzeit ist der Delay-Perzentilwert entscheidender als der Mittelwert.
- Max/Peak-Queueing Delay: kurze Spitzen sind QoE-kritisch. Besonders im Access-Upstream und an Aggregationsuplinks.
- Scheduler Service Share: wie viel Sendezeit/Bandbreite bekommt jede Klasse tatsächlich? Das zeigt, ob Gewichte und Limits wie geplant wirken.
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.
- Queue Drops pro Klasse: absolute Drops und Drop-Rate. Drops in der Voice-Klasse sind ein Incident.
- Tail Drop vs. Early Drop: wenn Congestion Avoidance (z. B. WRED) aktiv ist, sollten Sie Early-Drop-Statistiken getrennt sehen.
- Drop Burstiness: Drops pro Zeitfenster (z. B. pro Sekunde) statt nur Gesamtzähler. Cluster erklären Freezes und MOS-Einbrüche.
- Discard Reasons: Drops durch Queue-Overflow, Policer-Drops, MTU/Fragmentierung, ACL/Firewall-Drops. Ohne Grundzuordnung wird Troubleshooting langsam.
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.
- Policer Conform/Exceed/Violate: Zähler für in-profile und out-of-profile Traffic. Exceed/Violate in Voice ist ein Alarmzeichen.
- Policer Drop vs. Policer Remark: Drops sind bei Echtzeit kritisch; Remarking ist häufig besser als harte Drops (außer bei Missbrauch).
- Shaping Rate: aktuelle Shaper-Rate und Shaper-Queueing. Das zeigt, ob der Shaper permanent „arbeitet“ oder nur Peaks glättet.
- Tokens/Burst-Parameter Wirkung: indirekt über Exceed-Events und Drop-Cluster erkennbar. Zu kleine Burst-Werte erzeugen Spikes.
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.
- One-Way Delay: Ende-zu-Ende oder segmentweise (Access/Metro/Core). RTT allein ist für Voice weniger aussagekräftig.
- Jitter: idealerweise aus RTCP-Reports oder Session-Analytics, weil das die echte Medienwahrnehmung abbildet.
- Paketverlust (RTP Loss): getrennt nach Uplink/Downlink, wenn möglich. Cluster besonders betrachten.
- MOS/R-Faktor: als aggregierter Qualitätsindikator für Reporting, Alarmierung und Trendanalysen.
- Call Setup Time: zeigt Signaling- und Control-Probleme; wichtig bei IMS/SIP-Trunks.
- Call Drop Rate / One-Way Audio Incidents: deutet auf NAT/Firewall/MTU/Interconnect-Probleme hin.
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:
- Packet Loss und Loss-Cluster: besonders bei interaktivem UDP-Video (WebRTC) kritisch.
- Throughput-Perzentile: 95./99. Perzentil sagt mehr als der Durchschnitt, weil ABR auf Spitzen reagiert.
- Freeze-/Rebuffer-Events: falls Plattform- oder CDN-Analytics verfügbar sind, sind diese KPIs extrem aussagekräftig.
- Bitrate Switching: Häufigkeit von Downshift/Up-shift zeigt Instabilität im Netz oder am Engpass.
- RTT/RTT-Variabilität: bei TCP/QUIC-basiertem Video ist Bufferbloat oft wichtiger als Drops.
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.
- Signaling-Transaktionszeiten: z. B. SIP INVITE->200 OK Zeitfenster, REGISTER-Response-Zeiten (wenn aus IMS/SBC sichtbar).
- Control-Klassen-Queueing und Drops: Control darf nicht in Best Effort verhungern.
- Routing-Health: IGP/BGP Stabilität, Flap-Events, Convergence-Zeiten; QoS kann indirekt leiden, wenn Control-Pakete verzögert werden.
- Time Sync: NTP/PTP-Status für korrekte One-Way-Delay-Messung und saubere Korrelation von Events.
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.
- Interface Utilization: getrennt nach Richtung und als Perzentile; Microbursts können trotz moderatem Durchschnitt auftreten.
- Errors/Discards: CRC, input/output errors, drops außerhalb der QoS-Queues (z. B. ASIC drops, buffer exhaustion).
- Optics/PHY: Signalstärke, FEC, Retransmissions bei Funk-/Microwave-Backhaul; physische Probleme wirken wie QoS-Probleme.
- MTU/Fragmentation Counters: Fragmentierung, PMTUD-Fehler, „Packet too big“ Drops; kleine MTU-Fehler ruinieren Echtzeit.
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:
- Passive Geräte-Telemetrie: Queue/Drops/Policer/Interface-KPIs aus Routern, Switches, Firewalls, SBCs.
- Active Probing: synthetische Messungen für Delay/Jitter/Loss (z. B. zwischen PoPs, über Backhaul-Segmente, bis zur NNI).
- Flow- und Session-Daten: IPFIX/NetFlow für DSCP-Verteilungen und Volumen, plus Session-Analytics (RTCP, MOS) aus IMS/UC-Plattformen.
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:
- Drops in der Voice-Klasse: immer Incident (auch wenn kurz), weil es direkt QoE betrifft.
- Queueing Delay-Spitzen in Voice: Incident oder mindestens Major Alarm, weil Jitter/MOS unmittelbar leiden kann.
- Policer-Drops auf Premium: Voice/Control sollten nicht regelmäßig out-of-profile laufen.
- Premium-Inflation: ungewöhnlich hohe EF/Voice-Volumen oder plötzliches Wachstum der Premiumklassen.
- Mapping-Drift: DSCP-Verteilung ändert sich signifikant nach einem Change, oder CoS/TC-Hits brechen ein.
- Service-KPI-Verfall: MOS sinkt, Call Drop Rate steigt, Video Freeze Events steigen – besonders wenn es korreliert mit Queueing/Drops.
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
- Premium-Inflation: EF/Voice-Volumen steigt dauerhaft; Classify-Hits zeigen neue Quellen; Best Effort wird schlechter.
- Microburst-Problem: kurze Drops/Delay-Spitzen ohne hohe Durchschnittsauslastung; Queue-Perzentile und Drop-Burstiness zeigen es.
- Policer zu hart: Exceed/Violate und Policer-Drops korrelieren mit MOS-Einbrüchen; Drops treten in Clustern auf.
- Mapping-Loch: DSCP stimmt am Ingress, aber CoS/TC-Hits am Egress fehlen; Premium-Queue bleibt leer, QoE wird schlecht.
- Bufferbloat: wenig Drops, aber hohe Queueing Delay-Perzentile; TCP-Video pendelt, Voice jittert.
- MTU/PMTUD-Fehler: sporadische Einweg-Audio oder Setup-Fails; Fragment/ICMP-Stats und Security-Drops liefern Hinweise.
Pflicht-Dashboards: Was ein Telco-NOC jederzeit sehen sollte
- QoS-Klassenübersicht pro Domäne: Access/Metro/Core getrennt, mit Volumen, Queueing Delay, Drops, Policer-Hits.
- Voice-Health: MOS/R-Faktor, RTP Jitter/Loss, Call Setup Time, Drop Rate, plus Voice-Queueing und Drops.
- Video-Health: Freeze/Rebuffer, Bitrate-Switching (falls vorhanden), Throughput-Perzentile, RTT-Variabilität.
- Markierungsintegrität: DSCP/CoS/TC-Verteilungen und Remarking an Schlüssel-Übergängen (NNI, PE, gNB/Backhaul, Edge-Firewall).
- Engpassradar: Interfaces mit steigenden Queueing Delay-Perzentilen oder Drop-Burstiness, bevor Kunden es merken.
Praxis-Blueprint: Minimalset an Pflichtmetriken für Telco-QoS
- Pro Klasse: Volumen, Queue Depth, Queueing Delay (inkl. Peaks/Perzentile), Drops, Scheduler Share.
- Policer/Shaper: Conform/Exceed/Drop, Shaping Rate, Remarking-Counts.
- Markierung: DSCP/CoS/TC-Verteilungen an Ingress/Egress und Mapping-Übergängen.
- Voice QoE: MOS/R-Faktor, RTP Jitter/Loss, Call Setup Time, Drop Rate.
- Video QoE: Freeze/Rebuffer, Bitrate Switching, Throughput-Perzentile, RTT-Variabilität.
- Transport: Interface-Errors/Discards, Utilization-Perzentile, MTU/Fragment/PMTUD-Indikatoren.
- Control: Control-Queueing/Drops, Routing-Health, Time-Sync-Status.
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.
