QoS und Overbooking: Wo die Grenzen im Access liegen

QoS und Overbooking gehören im Access-Netz untrennbar zusammen, weil die letzte Meile und die erste Aggregationsstufe fast immer überbucht sind – technisch, wirtschaftlich und betrieblich. Overbooking bedeutet, dass die Summe der vermarkteten Anschlussbandbreiten (z. B. 1 Gbit/s pro Kunde) deutlich größer ist als die tatsächlich verfügbare Kapazität auf einem gemeinsamen Segment (z. B. PON-Split, DSLAM-Uplink, CMTS/Remote-PHY-Uplink, Funkzelle oder Aggregationsuplink). Das ist grundsätzlich nicht „falsch“, sondern ein betriebswirtschaftliches Prinzip: Nicht alle Kunden nutzen gleichzeitig ihre Maximalrate. Problematisch wird Overbooking jedoch dann, wenn Echtzeitverkehr wie Voice, interaktives Video (WebRTC, Videokonferenzen) oder IPTV (Multicast) auf genau diesen überbuchten Access trifft. Denn Echtzeit leidet nicht primär an „zu wenig Durchschnittsbandbreite“, sondern an kurzzeitigen Engpässen, Microbursts, Queueing Delay-Spitzen und Paketverlustclustern. Genau dort liegen die Grenzen: In einem überbuchten Access können Sie mit QoS sehr viel stabilisieren, aber nicht alles „wegpriorisieren“. Wenn die physische Kapazität regelmäßig überschritten wird, muss QoS irgendwann harte Entscheidungen treffen: Wen schützt man, wen degradiert man, und wie verhindert man, dass Premium-Klassen sich aufblähen und am Ende sogar Voice schlechter wird? Dieser Artikel erklärt, wie Overbooking im Access entsteht, welche Grenzwerte in der Praxis relevant sind, welche QoS-Mechanismen wirklich helfen (und welche Nebenwirkungen erzeugen) und wie Sie Overbooking so planen, dass Voice & Video auch bei hoher Auslastung möglichst stabil bleiben.

Was Overbooking im Access wirklich bedeutet

Overbooking ist im Kern ein statistisches Modell: Sie verkaufen eine „Peak Rate“, rechnen aber mit einer deutlich niedrigeren gleichzeitigen Nutzung (Concurrency). In Access-Technologien ist das strukturell eingebaut, weil viele Teilnehmer ein gemeinsames Medium oder einen gemeinsamen Uplink teilen.

• Shared Medium: mehrere Teilnehmer teilen sich dieselbe Kapazität (PON, DOCSIS, Mobilfunk, WLAN).
• Shared Uplink: selbst bei „dedicated“ Last Mile teilen mehrere Anschlüsse einen Aggregationsuplink (DSLAM/OLT-Uplink, Access-Switch-Uplink, BNG/BRAS-Aggregation).
• Überbuchungsfaktor: Verhältnis aus verkaufter Summe zu physischer Kapazität, oft grob als
  $\mathrm{Overbooking}=\mathrm{SummePeak}/\mathrm{Kapazität}$
  gedacht.

Die Herausforderung ist, dass QoS nicht die Kapazität erhöht, sondern nur entscheidet, wie Engpässe verteilt werden. Ab einem bestimmten Punkt kann QoS nur noch „Schaden begrenzen“.

Warum Access-Overbooking Echtzeit zuerst trifft

Wenn ein Segment überbucht ist, entstehen Warteschlangen. Warteschlangen erzeugen Delay und Jitter. Und wenn Warteschlangen überlaufen oder Policers greifen, entsteht Paketverlust. Echtzeitverkehr ist hier besonders empfindlich:

• Voice (RTP/SRTP): kleine Pakete, konstante Rate, extrem sensibel auf Jitter und Loss; „zu spät“ ist wie „verloren“.
• Interaktives Video (WebRTC/UC): burstiger, toleriert mehr Delay als Voice, aber empfindlich auf Drop-Cluster und Throughput-Wellen.
• Streaming (TCP/QUIC): kaschiert Loss durch Retransmits, leidet aber bei Bufferbloat und instabilen Throughput-Fenstern (Qualitäts-Pendeln, Buffering).

In der Praxis heißt das: Overbooking zeigt sich nicht zuerst als „Speedtest langsam“, sondern als „Meetings ruckeln“ oder „Telefonie knackt“ – weil die Nutzerqualität an Peaks hängt, nicht am Durchschnitt.

Wo die physikalischen Grenzen im Access liegen

Die Grenze ist erreicht, wenn die überbuchte Ressource regelmäßig in einen Zustand kommt, in dem selbst Premiumklassen (Voice/Control) nicht mehr ohne Drops oder große Delay-Spitzen bedient werden können. Diese Grenze ist nicht nur eine Zahl, sondern hängt von Trafficprofilen ab:

• Busy Hour und Traffic-Mix: Videokonferenzen am Vormittag, Streaming am Abend, Gaming am Nachmittag – unterschiedliche Burst-Muster.
• Uplink vs. Downlink: Upstream ist oft knapper und pufferanfälliger; dort entstehen Bufferbloat und Policer-Drops besonders häufig.
• Microbursts: kurze Spitzen können Puffer überlaufen lassen, obwohl der 5-Minuten-Durchschnitt niedrig wirkt.
• Geräte- und Plattformlimits: CPE/ONT/Modem, WLAN-AP, Firewall/VPN-Gateway – CPU und Bufferarchitektur bestimmen, wann Jitter eskaliert.

Eine operative Definition der Grenze lautet: Wenn in der Voice-Klasse Drops auftreten oder wenn Voice-Queueing-Delay-Perzentile stark ansteigen, ist Overbooking nicht mehr „nur ökonomisch“, sondern QoE-kritisch.

Overbooking-Topologien im Access: Wo es typischerweise eng wird

Access ist nicht gleich Access. Je nach Technologie sitzen Engpässe an unterschiedlichen Stellen – und QoS muss dort greifen, wo der Engpass tatsächlich ist.

• FTTH/PON: Shared Medium auf dem PON-Segment plus OLT-Uplink/Aggregation. Engpässe sind oft upstream-seitig und in Aggregationsuplinks sichtbar.
• DSL: Last Mile ist dediziert, aber DSLAM/MSAN-Uplink und BRAS/BNG-Aggregation sind shared. Upstream-Profile und Interleaving/PHY-Effekte spielen mit hinein.
• HFC/DOCSIS: Shared Medium im Koax-Segment, Scheduling im CMTS/Remote-PHY, stark last- und signalabhängig. Peak-Events wirken sehr direkt auf Jitter/Loss.
• Mobilfunk: Funkressourcen sind shared und hoch dynamisch; zusätzlich kann Mobile Backhaul overbooked sein.
• Enterprise Access (Ethernet Access): physisch oft robust, aber Aggregation/NNI-Ports können überbucht sein; QoS-Loch an Übergaben ist ein Klassiker.

Der wichtigste Punkt: QoS muss an der Stelle wirken, wo gequeued und gedroppt wird. QoS im Core rettet keine überlaufenden Puffer im CPE oder Modem.

QoS-Mechanismen, die Overbooking im Access wirklich entschärfen

Im überbuchten Access sind nicht alle QoS-Werkzeuge gleich wirksam. Besonders bewährt haben sich Mechanismen, die Bursts glätten und Warteschlangen kontrollieren.

Shaping gegen Bufferbloat und Policer-Drops

• Warum: Wenn ein Providerprofil oder ein physischer Uplink eine harte Rate hat, erzeugen unshaped Bursts Drops oder riesige Puffer im falschen Gerät.
• Wirkung: Shaping verlagert die Warteschlange an einen kontrollierbaren Punkt und glättet Spitzen.
• Praxisregel: Shaping knapp unter der realen Linkrate, insbesondere im Upstream, reduziert Jitter drastisch.

LLQ für Voice – aber strikt limitiert

• Warum: Voice braucht minimale Warteschlange.
• Wirkung: Prioritätsqueue reduziert Jitter, verhindert, dass Voice hinter großen Paketen „steht“.
• Grenze: Ohne Limit wird LLQ bei Fehlmarkierung zur Starvation-Maschine; Overbooking macht das sofort sichtbar.

Gewichtete Klassen für Video und Control

• Video: benötigt stabile Throughput-Fenster, aber keine strict priority.
• Signaling/Control: volumenarm, aber kritisch; eine kleine, hoch priorisierte gewichtete Klasse verhindert Setup-Probleme in Congestion.

Queue-Limits bewusst dimensionieren

• Zu große Queues: Bufferbloat → hohe Latenz/Jitter ohne sichtbare Drops.
• Zu kleine Queues: Drop-Cluster bei Bursts → Freezes und Knacken.
• Praxis: Voice-Queues klein, Video moderat, Best Effort kontrolliert, aber nicht „endlos“.

Was QoS nicht kann: Overbooking „wegzaubern“

QoS kann Prioritäten setzen, aber keine Kapazität erzeugen. In einem dauerhaft überlasteten Segment muss irgendjemand verlieren. Typische Grenzen:

• Wenn Premium dauerhaft groß wird: Dann wird Premium selbst zum Engpass. Voice dropt oder queue’t, obwohl QoS „richtig“ ist.
• Wenn der Engpass vor Ihrer QoS-Instanz liegt: CPE-/Modem-Puffer, WLAN-Airtime, Providerpolicer – QoS im Router hilft dann nur begrenzt.
• Wenn Overbooking in Peaks zu groß ist: Microbursts überlaufen Puffer schneller, als Scheduling reagieren kann.

Die Konsequenz ist ein realistisches SLA- und Produktdesign: Voice kann oft stabil gehalten werden, Video kann kontrolliert degradiert werden, aber Best Effort muss in Spitzen bewusst zurückstehen.

Die Overbooking-Falle: Premium-Inflation im Access

Eine der häufigsten Ursachen für „QoS hilft nicht“ ist Premium-Inflation: Zu viele Flows landen in Premiumklassen (EF/LLQ oder „High Priority“), weil Markierungen blind vertraut werden oder Apps unpassend markieren.

• Symptom: EF/Voice-Volumen steigt unplausibel, LLQ ist dauerhaft gefüllt, EF-Drops treten in Busy Hour auf.
• Ursache: fehlende Trust Boundary, fehlende DSCP-Whitelist, Kundenmarkierungen werden ungeprüft übernommen.
• Folge: Im overbooked Access eskaliert das schneller als im Core, weil Puffer kleiner und Profile härter sind.

Ein robustes Access-Design setzt deshalb Trust Boundaries und Remarking-Regeln: Voice darf EF sein, aber nur aus definierten Quellen und nur bis zu einem profilieren Budget. Überschuss wird herabgestuft statt gedroppt.

Overbooking und Richtung: Warum der Upstream der kritische Punkt ist

Viele Access-Probleme sind uplink-dominiert. Gründe:

• Asymmetrische Raten: Upstream ist oft deutlich kleiner als Downstream.
• CPE/Modem-Buffer: Upstream-Puffer sind häufig groß und schlecht kontrolliert; Bufferbloat entsteht.
• Traffic-Mix: Cloud-Sync, Uploads, Screen Sharing, Backup – alles erzeugt uplinkseitige Bursts, die Echtzeit stören.

Deshalb ist „Upstream-Shaping + Voice-LLQ + kontrollierte BE-Queues“ oft der schnellste Weg, um trotz Overbooking spürbar bessere QoE zu erreichen.

Planung: Welche Serviceprofile in overbooked Access sinnvoll sind

Ein praktikables Klassenmodell im Access sollte wenige, klare Klassen haben, damit Mapping und Betrieb beherrschbar bleiben:

• Voice Audio: EF/LLQ mit Limit, sehr geringe Queue-Limits, praktisch keine Drops tolerierbar.
• Signaling/Control: hoch priorisiert, gewichtet; schützt Call Setup, DNS und Steuerpfade.
• Interaktives Video: AF-Klasse, gewichtet; Burst-Handling und moderates Queue-Limit.
• Best Effort: fair, kontrollierte Puffer, ggf. Congestion Avoidance; darf bei Congestion zurückstehen.
• Background: optional, für Updates/Backups, klar niedriger priorisiert.

In overbooked Umgebungen ist „zu viele Klassen“ ein Risiko: Jede zusätzliche Klasse erhöht die Wahrscheinlichkeit von Mapping-Löchern und Drift.

Grenzen sichtbar machen: Welche Metriken Overbooking-Probleme früh zeigen

Overbooking wird im Betrieb häufig zu spät erkannt, weil nur Linkauslastung betrachtet wird. Für QoS und Access-Grenzen sind diese Metriken entscheidend:

• Queueing Delay pro Klasse: 95./99. Perzentil und Peaks, besonders in Voice/Control.
• Drops pro Klasse: EF-Drops sind ein Incident; Video-Drop-Cluster erklären Freezes.
• Policer Exceed/Drop: zeigt, ob Profile zu hart sind oder Bursts nicht passen.
• EF-Volumen und Remarking-Raten: zeigt Premium-Inflation und Governance-Probleme.
• Service-KPIs: MOS/R-Faktor, RTP Jitter/Loss, Video Freeze/Bitrate Switching, Call Setup Times.

Eine praktische Betriebsregel lautet: Wenn Voice-Queueing-Delay-Perzentile steigen oder EF-Drops auftreten, ist das Overbooking- oder Governance-Problem bereits in der Qualitätszone, nicht nur in der „Kapazitätszone“.

Typische Fehlannahmen bei QoS und Overbooking

• „Wenn wir Voice priorisieren, ist alles gut“: stimmt nur, wenn Premium klein bleibt und der Engpass korrekt gequeued wird.
• „Keine Drops = keine Probleme“: Bufferbloat erzeugt hohe Latenz und Jitter ohne Drops.
• „QoS im Core reicht“: Access-Engpässe entstehen oft im CPE/Modem oder am ersten Aggregationsuplink.
• „Mehr Klassen lösen es“: mehr Klassen erhöhen Komplexität und Drift; oft ist ein schlankes Modell stabiler.

Praxis-Blueprint: Overbooking im Access so designen, dass Echtzeit stabil bleibt

• Schritt 1: Engpassstellen identifizieren (CPE/Modem, Uplink, OLT/DSLAM/CMTS, Aggregation).
• Schritt 2: Serviceprofile definieren (Voice, Control, Video, BE) und klare DSCP/CoS-Mappings festlegen.
• Schritt 3: Trust Boundary setzen (DSCP-Whitelist, Conditional Trust), Premium-Inflation verhindern.
• Schritt 4: Upstream-Shaping aktivieren und korrekt dimensionieren (knapp unter realer Rate).
• Schritt 5: Voice in LLQ mit Limit, kleine Queue-Limits; Drops als Incident behandeln.
• Schritt 6: Video gewichtet, Burst-Handling und moderates Queue-Limit; Überschuss ggf. remarken.
• Schritt 7: Monitoring auf Perzentile und Sekundenfenster umstellen (Queueing Delay/Drops/Policer).
• Schritt 8: Overbooking-Grenzen operationalisieren (Schwellenwerte: EF-Drops, Voice-Delay-Perzentile, Remarking-Spikes).

Häufige Fragen zu QoS und Overbooking im Access

Kann QoS Overbooking vollständig kompensieren?

Nein. QoS verteilt Engpässe, erhöht aber keine Kapazität. Es kann Voice und Control in vielen Fällen stabil halten und Video kontrolliert degradieren lassen. Wenn die physische Kapazität jedoch regelmäßig deutlich überschritten wird, müssen Dienste verlieren – dann ist Ausbau oder Produkt-/Profilanpassung nötig.

Warum sind Access-Probleme oft nur im Upstream sichtbar?

Weil Upstreamraten häufig kleiner sind und weil Bufferbloat und harte Providerprofile dort besonders stark wirken. Ein einzelner Upload oder Screen Share kann den Upstream so puffern, dass Voice Jitter sieht, obwohl der Downstream frei wirkt. Upstream-Shaping ist deshalb ein zentraler QoS-Baustein.

Was ist das wichtigste Signal dafür, dass Overbooking die Qualitätsgrenze erreicht hat?

Drops oder starke Queueing-Delay-Perzentile in der Voice-Klasse (EF/LLQ) sowie ein unplausibler Anstieg des EF-Volumens. Das zeigt entweder echte Kapazitätsknappheit im Fail-/Peak-Zustand oder Premium-Inflation durch Fehlmarkierung – beides ist qualitativ kritisch und sollte priorisiert behandelt werden.