Ein sauberes Latenzbudget für Voice/Video ist im Telco-Umfeld der zentrale Baustein, um aus „guter Hoffnung“ verlässliche End-to-End Qualität zu machen. Denn Latenz ist kein einzelner Wert, sondern die Summe vieler Teilstrecken: Access-Technologie, Aggregation, Core, Interconnect, Security-Funktionen, Tunneling, Funk/WLAN, plus die Verarbeitung in Endgeräten und Plattformen. Wenn Telcos End-to-End Targets definieren, müssen sie deshalb nicht nur ein Gesamtziel festlegen, sondern dieses Ziel in nachvollziehbare Budgets pro Domäne und pro Engpass zerlegen. Genau hier entsteht die Praxisreife: Latenzbudgets werden so gewählt, dass sie messbar, operativ steuerbar und in Failover-Szenarien weiterhin erreichbar sind. Ein gutes Latenzbudget für Voice/Video berücksichtigt außerdem Jitter und Loss, weil beide direkt mit Queueing, Mikrobursts und Buffering verknüpft sind. Dieser Artikel zeigt, wie Telcos End-to-End Targets pragmatisch definieren, wie Budgets pro Netzdomäne abgeleitet werden und welche Failure Patterns typische Budgetüberschreitungen verursachen.
Was „Latenz“ im Echtzeitkontext bedeutet: One-Way, RTT und wahrgenommene Verzögerung
Bevor Zahlen verteilt werden, muss klar sein, welche Latenz gemeint ist. In Netzen wird häufig RTT (Round Trip Time) gemessen, während Echtzeitdienste stärker auf One-Way-Delay reagieren. Zusätzlich kommt Anwendungs- und Endgeräteverarbeitung hinzu: Codec-Frame-Größe, Jitter-Buffer, Echo-Canceller, Video-Puffer. Ein Telco-Latenzbudget muss daher zwischen Transportlatenz und End-to-End Nutzerlatenz unterscheiden.
- One-Way-Delay: Laufzeit in eine Richtung; ideal für Voice/Video-Ziele, erfordert gute Zeitsynchronisation.
- RTT: leichter zu messen; als Näherung nutzbar, aber nicht immer halbierbar (asymmetrische Pfade).
- Queueing Delay: variable Latenz durch Warteschlangen; Haupttreiber für Jitter.
- Processing Delay: Endgeräte/Plattform (Codec, Verschlüsselung, Media-Server) addiert oft signifikant.
Warum Telcos Latenzbudgets brauchen: Von QoS-Policies zu messbaren Targets
QoS priorisiert Knappheit, aber Latenzziele entstehen aus Budgetierung. Ohne Budget kann ein Netz zwar „priorisieren“, aber niemand weiß, ob die Summe der Teilstrecken das Serviceziel überhaupt zulässt. Latenzbudgets schaffen drei Vorteile: Erstens werden Ziele in Domänen heruntergebrochen (Access/Aggregation/Core/Interconnect). Zweitens lassen sich Änderungen bewerten („passt diese neue Service-Funktion noch ins Budget?“). Drittens werden Mess- und Alarmgrenzen sinnvoll gesetzt (Perzentile, Zeitfenster, Fehlerbudgets).
- Planbarkeit: neue Links, neue Plattformen, neue Pfade können gegen das Budget geprüft werden.
- Fehlersuche: Budget-Overruns zeigen, in welcher Domäne die Ursache liegt.
- SLA-Fähigkeit: Targets sind messbar und nachvollziehbar, nicht nur „best effort“.
Voice vs. Video: Unterschiedliche Anforderungen, unterschiedliche Budgets
Voice ist extrem latenz- und jitterkritisch, während Video – je nach Typ – unterschiedliche Toleranzen hat. Interaktives Video (Videokonferenzen) benötigt ebenfalls niedrige Latenz, toleriert aber oft etwas mehr als Voice, solange Audio stabil bleibt. Streaming-Video ist weniger interaktiv, dafür throughput- und loss-sensitiv; hier ist Latenz weniger kritisch, solange Buffer ausreichend sind. Ein Telco-Latenzbudget sollte daher mindestens zwischen Voice, interaktivem Video und nicht-interaktivem Video unterscheiden.
- Voice: sehr niedrige Latenz und Jitter; kleine Pakete, häufig, strikt priorisiert und limitiert.
- Interaktives Video: niedrige Latenz, moderater Jitter; hohe Bandbreite, bevorzugt aber fair.
- Streaming: Latenz sekundär, aber stabile Bandbreite und geringer Loss wichtig.
Der Telco-Ansatz: Gesamtziel definieren und in Domänenbudgets zerlegen
Ein praktisches Vorgehen ist zweistufig: Zuerst wird ein End-to-End Ziel für die Serviceart festgelegt (z. B. Voice „interaktiv“). Danach wird das Ziel in Budgets pro Domäne aufgeteilt. Dabei werden „fixe“ Komponenten (Propagation, notwendige Verarbeitung) und „variable“ Komponenten (Queueing) getrennt behandelt. Besonders wichtig: Variable Latenz muss über QoS und Shaping kontrollierbar sein, sonst kippt das Budget in Busy Hour oder bei Mikrobursts.
Domänen, die typischerweise im Latenzbudget berücksichtigt werden
- Endgerät/Access: CPE/ONT/Modem, WLAN/Funk, erste Switches/Nodes.
- Access Aggregation: erste Sammelpunkte mit Oversubscription, häufige Congestion Points.
- Metro/Core: Backbone-Transport, meist stabil, aber Pfadlängen und TE/Failover relevant.
- Service Edge: SBC, Media-Relays, NAT/Firewall, Session-Control – Processing kann spürbar sein.
- Interconnect/Peering: begrenzte Kontrolle; Targets realistisch formulieren.
Budgetlogik: Fixe vs. variable Latenz und warum Jitter dazugehört
Für ein belastbares Budget ist die Trennung zentral: Fixe Latenz entsteht durch Physik (Glasfaserstrecke, Funk-Layer) und notwendige Verarbeitung. Variable Latenz entsteht durch Warteschlangen und ist der Teil, den QoS direkt beeinflusst. In Echtzeitdiensten ist variable Latenz gleichbedeutend mit Jitter-Risiko. Deshalb wird in Telco-Designs die Queueing-Komponente streng budgetiert und über Shaping, Queue-Limits und Priorisierung kontrolliert.
- Fixe Latenz: Propagation, SerDes, minimale Forwarding-Zeiten, zwingende Crypto/Media-Processing.
- Variable Latenz: Queueing durch Congestion und Mikrobursts; Haupttreiber für Jitter.
- Budgetregel: fixe Teile sind „gegeben“, variable Teile sind „zu kontrollieren“.
Messstrategie: Wie Telcos Latenzbudgets verifizieren
Ein Budget ist nur dann wertvoll, wenn es verifiziert werden kann. Telcos kombinieren dafür mehrere Messarten: aktive Messungen (synthetische Probes), passive Telemetrie (Interface/Queue-Statistiken) und – wo verfügbar – applikationsnahe Metriken (z. B. RTCP bei RTP). Für Budgetnachweise sind Perzentile und kurze Zeitfenster entscheidend, weil Mittelwerte Peaks verdecken. Eine typische Praxis ist die Bewertung in 5-Minuten-Intervallen mit p95/p99, ergänzt durch Monats-Fehlerbudgets.
- Active Probing: One-Way/RTT zwischen definierten Messpunkten pro Domäne.
- Queue-Telemetrie: Queue-Delay, Queue-Depth, Drops pro Klasse – direkte Congestion-Signale.
- Flow-/Class Utilization: Nutzung der Echtzeitklassen, um Budgetüberschreitungen zu erklären.
- Applikationsmetriken: Jitter/Loss aus RTP/RTCP oder Plattformstatistiken für End-to-End Sicht.
Budgetierung pro Klasse: Warum Voice und Video getrennte „Delay Budgets“ brauchen
In der QoS-Architektur haben Voice und Video unterschiedliche Queueing-Strategien. Voice läuft typischerweise in einer Low-Latency Queue (LLQ) und muss strikt limitiert werden, damit sie nicht andere Klassen verdrängt. Video gehört in eine gewichtete Echtzeitklasse, die Mindestbandbreite bekommt, aber keine absolute Priorität. Daraus folgt: Auch die Delay Budgets pro Klasse unterscheiden sich. Voice erhält die strengsten Queue-Delay Ziele; Video erhält stabile, aber etwas großzügigere Ziele, weil Bandbreite und Burstiness höher sind.
- Voice Delay Budget: sehr niedriges Queue-Delay; Ziel „nahe 0“ in Normalbetrieb, Peaks streng überwacht.
- Video Delay Budget: niedrig, aber mit fairer Bedienung; Shaping reduziert Bursts und Stabilitätsprobleme.
- Signalisierung: bevorzugt, damit Setup stabil bleibt; Delay- und Loss-Spitzen vermeiden.
Failure Patterns: Warum Budgets reißen – und wie man die Ursache domänenscharf findet
Budgetüberschreitungen sind selten „mysteriös“. Meist lassen sie sich einem wiederkehrenden Muster zuordnen: Congestion an einem nicht abgedeckten Engpass, fehlendes Shaping am WAN-Edge, Mikrobursts in Aggregation, zu große Buffers (Bufferbloat), Overlay-Markings, die im Tunnel verschwinden, oder Failover auf einen Pfad mit schlechteren Eigenschaften. Ein gutes Budgetmodell hilft dabei, nicht nur zu sehen, dass Latenz steigt, sondern wo und warum.
- Congestion ohne QoS: Engpass sitzt im Access/WLAN oder in unmanaged Segmenten; QoS greift nicht.
- Kein WAN-Shaping: Queue liegt beim Provider; Drops/Delay sind schwer steuerbar und messbar.
- Mikrobursts: kurze Peaks füllen Queues; Queue-Delay springt, Jitter steigt.
- Bufferbloat: zu große Queues erhöhen Delay dauerhaft; Echtzeit leidet trotz geringer Drops.
- Overlay/DSCP Copy: Underlay behandelt Echtzeit wie Best Effort; Budget kippt in Busy Hour.
- Failover: Backup-Pfad hat weniger Headroom oder andere Queue-Profile; Budget nur im Normalpfad erfüllt.
Pragmatische Vorgehensweise: So definiert man End-to-End Targets ohne „Zahlenspiel“
Telcos, die Latenzbudgets erfolgreich etablieren, gehen pragmatisch vor: Sie definieren zuerst den Service und die Messstrecke (Edge-to-Edge, Standort-zu-Cloud, In-Domain). Dann messen sie die fixe Grundlatenz im Normalpfad. Anschließend reservieren sie ein kontrollierbares Budget für Queueing, getrennt pro Klasse. Danach werden die kritischen Engpässe identifiziert und QoS so platziert, dass genau dort Queueing kontrolliert wird (Shaping am Edge, HQoS im Access, konsistente Queue-Limits). Schließlich werden SLOs in Perzentilen formuliert und mit Fehlerbudgets hinterlegt, sodass Betrieb und Change-Management realistisch bleiben.
- Messstrecke definieren: was ist im Einflussbereich, was nicht?
- Baseline messen: fixe Latenz im Normalpfad und in Failover-Pfaden.
- Queueing budgetieren: strenge Budgets für Voice, kontrollierte Budgets für Video.
- Engpässe abdecken: QoS an den tatsächlichen Congestion Points implementieren.
- SLOs operationalisieren: p95/p99, kurze Zeitfenster, Fehlerbudgets, Dashboards und Alarme.
Rezertifizierung: Budgets müssen mit dem Netz wachsen
Latenzbudgets sind kein einmaliges Projekt. Traffic-Profile ändern sich, Plattformen wechseln, Pfade werden optimiert, und neue Dienste kommen hinzu. Deshalb sollten Telcos Budgets regelmäßig rezertifizieren: Stimmen die Mappings und Trust Boundaries noch? Entspricht die Queueing-Strategie dem aktuellen Traffic? Haben Failover-Pfade ausreichend Headroom? Und sind die Messmethoden stabil geblieben? Eine rezertifizierte Budgetlogik verhindert, dass „historisch gewachsene“ Annahmen zu wiederkehrenden Qualitätsproblemen führen.
- Quarterly/half-year Reviews: Budget- und KPI-Checks pro Domäne.
- Failover-Tests: unter Last, nicht nur im Leerlauf.
- Template-Compliance: Drift in QoS-Profilen erkennen und beheben.
- Capacity Alignment: Budgets und Kapazität gemeinsam betrachten, nicht getrennt.
