QoS im Access: DSL/FTTH/Cable – Constraints und Patterns

QoS im Access ist in Telekommunikationsnetzen der Ort, an dem Servicequalität am häufigsten gewonnen oder verloren wird. Denn egal wie sauber der Core gebaut ist: Wenn DSL-, FTTH- oder Cable-Zugänge am Rand unter Oversubscription, Pufferproblemen, Upstream-Engpässen oder inkonsistenten Markierungen leiden, bekommen Voice, Video und Business-Connectivity keine stabilen Latenz-, Jitter- und Loss-Werte. Genau hier unterscheiden sich Access-Technologien deutlich. DSL ist häufig asymmetrisch und upstream-limitiert, dazu kommen Interleaving/Vectoring-Effekte und ein hoher Bedarf an sauberem Shaping. FTTH bietet sehr hohe Bandbreiten, aber der Engpass verschiebt sich oft in die Aggregation oder in die PON-Teilung (bei GPON/XGS-PON) – und damit in Scheduling und Fairness. Cable (DOCSIS) ist ein Shared Medium mit komplexer Upstream-Arbitrierung, Burstiness und hoher Sensitivität auf Bufferbloat und Mikrobursts. Wer QoS im Access richtig plant, denkt deshalb nicht in „Standard-QoS-Profilen“, sondern in Constraints und Patterns: Wo ist der echte Engpass? Wo liegt die Queue? Wie wird per Subscriber geformt? Welche Trust Boundaries gelten? Und wie wird alles messbar gemacht, damit SLAs und interne SLOs nicht nur auf dem Papier existieren?

Warum Access-QoS anders ist als Core-QoS

Im Core sind Links oft überdimensioniert, Latenzen stabil, und QoS dient primär der Konsistenz. Im Access dagegen sind Engpässe normal: Viele Teilnehmer teilen sich Ressourcen, die tatsächliche verfügbare Rate schwankt, und Upstream ist in der Praxis häufig kritischer als Downstream. Access-QoS muss deshalb stärker „schutzorientiert“ sein: Schutz vor Noisy Neighbors, Schutz der Echtzeitklassen vor Missmarking, Schutz vor Mikrobursts sowie Kontrolle der Queueing-Latenz (Bufferbloat). Außerdem muss Access-QoS subscriber- und servicebasiert skalieren: Policies für Zehntausende bis Millionen Anschlüsse, ohne manuelle Sonderfälle.

• Engpässe sind die Regel: Access ist der natürliche Staupunkt, nicht die Ausnahme.
• Shared Medium: PON und DOCSIS teilen Kapazität; Fairness ist Teil des QoS.
• Asymmetrien: Upstream-Constraints dominieren häufig Voice/Video-Probleme.
• Skalierung: per-Subscriber Policies und Automatisierung sind Pflicht.

Gemeinsame QoS-Ziele im Access: Echtzeit stabil halten, Missbrauch verhindern

Unabhängig von DSL, FTTH oder Cable lassen sich die Access-Ziele in drei Prioritäten bündeln. Erstens: Echtzeit (Voice/Video) muss niedrige Latenz, geringen Jitter und minimalen Loss bekommen, insbesondere im Upstream. Zweitens: Best Effort soll fair und effizient bleiben, idealerweise mit AQM/ECN gegen Bufferbloat. Drittens: Markierungen müssen kontrolliert werden, sonst „frisst“ sich Best Effort in Premium-Klassen. Daraus ergibt sich in der Praxis ein wiederholbares Muster: Trust Boundary am Access Edge/BNG, schlankes Klassenmodell, HQoS mit per-Subscriber Shaping, und Telemetrie auf Queue-Delay und Drops.

• Voice Media: strikt priorisiert, aber strikt limitiert.
• Video/Interaktiv: bevorzugt, aber fair gegenüber anderen Klassen.
• Signaling/Control: klein, aber zuverlässig, damit Sessions stabil bleiben.
• Best Effort: AQM/ECN als Hebel, um Latenz unter Last zu reduzieren.

Access-Constraint 1: Upstream ist oft der echte QoS-Schmerzpunkt

Viele QoS-Designs fokussieren auf Downstream, weil dort die großen Datenraten sichtbar sind. Für Echtzeit ist jedoch der Upstream häufig kritischer: VoIP und Videokonferenzen senden kontinuierlich, und schon ein kleiner upstream Engpass erzeugt Queueing-Delay und Drops, die sofort hörbar sind. Dazu kommt: Upload-Traffic wie Cloud-Sync, Backups oder Kamera-Uploads tritt bursty auf und kann Echtzeitpakete verdrängen, wenn Shaping und Klassen nicht sauber gesetzt sind.

• Uplink Shaping: hält die Queue kontrollierbar und verhindert Provider-/CPE-Bufferbloat.
• Per-Subscriber Budgets: verhindern Noisy Neighbor Effekte auf Shared Links.
• Echtzeit-Queues: müssen im Upstream genauso konsequent gelten wie im Downstream.

Access-Constraint 2: Bufferbloat und Mikrobursts sind im Access besonders häufig

Access-Plattformen und CPEs puffern oft aggressiv, um Drops zu vermeiden. Das führt unter Last zu Bufferbloat: hohe, schwankende Latenz, die Echtzeitqualität zerstört, obwohl Paketverlust gering aussieht. Gleichzeitig sind Mikrobursts typisch, wenn viele Teilnehmerströme in Aggregationslinks zusammenlaufen oder wenn DOCSIS/PON-Scheduler Traffic in Wellen freigeben. Ein praxistauglicher Ansatz kombiniert Shaping, sinnvolle Queue-Limits und AQM in Best Effort Klassen. Für Echtzeitklassen gilt: lieber kurze, kontrollierte Queues als „große Sicherheitspuffer“.

• Queue-Delay messen: Latenzspitzen sind oft wichtiger als Drops.
• Shaping: glättet Bursts, reduziert Drop-Spitzen und Jitter.
• AQM/ECN: besonders wirksam gegen Best-Effort-Bufferbloat auf knappen Links.

Access-Pattern: Hierarchisches QoS (HQoS) als Standard

Im Access ist HQoS fast immer der richtige Ansatz, weil Sie zwei Ebenen gleichzeitig steuern müssen: per Subscriber/Service und per physikalischem Interface. Ein Parent-Shaper kontrolliert die Gesamtrate des Anschlusses oder des Aggregationsports, während Child-Policies innerhalb dieser Rate Klassen priorisieren. Dadurch lassen sich Produkte (z. B. Business Internet mit priorisiertem Voice) sauber abbilden, und Sie verhindern, dass einzelne Teilnehmer die gemeinsamen Ressourcen dominieren.

• Parent: Shaping auf Anschlussrate (oder leicht darunter), um Queueing lokal zu kontrollieren.
• Child: Klassenbasierte Queues (Voice, Video, Signaling, BE, Bulk) mit definierten Budgets.
• Limits: LLQ/Strict Priority immer begrenzen, sonst droht Starvation anderer Klassen.

DSL: Constraints und QoS-Patterns

DSL-Zugänge sind häufig asymmetrisch und stark upstream-limitiert. Zusätzlich kann die physikalische Schicht (Leitungslänge, Störungen) die verfügbare Rate schwanken lassen. Interleaving kann Latenz erhöhen, während Vectoring zwar Bandbreite verbessert, aber nicht automatisch QoS-Probleme löst. In der Praxis ist bei DSL das wichtigste Pattern: Egress Shaping im Upstream, idealerweise so, dass die Queue nicht im CPE-Buffer „ausbrennt“, sondern kontrollierbar am Access Edge/BNG oder am CPE mit korrektem Queueing liegt. Wenn die Queue beim Endgerät oder im DSL-Modem ungeführt wächst, entstehen hohe Jitter-Spitzen.

• Upstream Shaping: essenziell, weil Upload schnell der Engpass wird.
• Kleine Echtzeitqueues: gegen Bufferbloat; Voice braucht minimalen Queueing-Delay.
• AQM im Best Effort: reduziert Latenzspitzen bei gleichzeitigen Uploads.
• Profilstabilität: variable Sync-Raten berücksichtigen, Budgets konservativ planen.

FTTH/PON: Constraints und QoS-Patterns

FTTH wirkt oft „bandbreitenfrei“, weil die nominalen Raten hoch sind. In der Realität sind FTTH-Architekturen häufig PON-basiert (z. B. GPON/XGS-PON), also Shared Medium: Mehrere Teilnehmer teilen sich eine Upstream- und Downstream-Kapazität, die durch Scheduler und Timeslots verteilt wird. Das bedeutet: Fairness und Scheduling sind Teil der QoS-Wirkung. Ein typisches Pattern ist per-ONT/Subscriber Shaping plus klare Klassen im Aggregations- oder BNG-Bereich. Zusätzlich ist die Aggregation (z. B. OLT-Uplinks) oft der echte Staupunkt, wenn viele PONs auf wenige Uplinks laufen. Hier müssen Queueing und Telemetrie besonders sauber sein.

• Shared Medium: Upstream-Scheduling kann Jitter erzeugen, wenn Profile nicht sauber sind.
• OLT/Uplink Engpässe: Aggregation ist häufig der echte Congestion Point.
• Per-Subscriber QoS: verhindert, dass einzelne ONTs/Haushalte Ressourcen dominieren.
• Consistent Mapping: DSCP↔PCP-Mappings sind im Ethernet-lastigen FTTH-Access zentral.

Cable/DOCSIS: Constraints und QoS-Patterns

Cable-Zugänge (DOCSIS) sind Shared Medium mit komplexer Upstream-Arbitrierung. Der Upstream ist oft der kritischste Bereich, weil viele Teilnehmer um Timeslots konkurrieren und bursty Uploads zu schnellen Stauphasen führen können. DOCSIS-Mechanismen können QoS-ähnliche Service Flows unterstützen, dennoch bleibt die operative Realität: Bufferbloat, Mikrobursts und „Bad Minutes“ treten häufig in Spitzenzeiten auf. Ein wirksames Pattern ist: klare Serviceprofile, konsequentes Shaping, und eine Messstrategie, die nicht nur Durchschnittsauslastung betrachtet, sondern Queue-Delay und Loss-Spitzen sichtbar macht. Zusätzlich ist die Trennung von Echtzeit und Best Effort wichtig, damit Upload-Spitzen (Cloud Sync, Backups) nicht interaktive Dienste verdrängen.

• Upstream-Contention: Timeslot-Verteilung kann variable Delays erzeugen.
• Bursty Traffic: Uploads verursachen Mikrobursts; Shaping und AQM helfen.
• Service Flows/Profiles: Profile konsequent auf Produkte abbilden, sonst driftet QoS.
• Messung in kurzen Fenstern: 1–5 Minuten, Perzentile, um Peak-Probleme zu sehen.

Marking im Access: Trust Boundaries und Remarking sind Pflicht

Im Access entscheidet sich, ob DSCP-Markierungen sinnvolle Signale oder Missbrauchsvektoren sind. Bei DSL/FTTH/Cable gilt: Der Provider sollte kundenseitige Markierungen nicht blind vertrauen. Stattdessen wird an der Access Edge (häufig am BNG/PE) eine Allowlist definiert, Markings werden auf interne Klassen gemappt, und Überschreitungen werden per Policer/Remarking kontrolliert. Für Managed Services kann Trust näher am Endgerät liegen, aber auch dann sollten Limits gelten – insbesondere für EF/Voice, weil strikt priorisierte Queues ohne Budget destabilisieren.

• Allowlist: nur definierte DSCP-Werte akzeptieren; Rest normalisieren.
• Remarking: Kundenwerte in Provider-Standardwerte übersetzen, damit der Core konsistent bleibt.
• Per-Class Budgets: EF/Voice streng begrenzen, Video kontrollieren, Best Effort fair halten.
• Auditfähigkeit: Remarking- und Policer-Zähler als Nachweis, dass Regeln greifen.

QoS-Mechanik am Access-Engpass: Wo die Queue liegen sollte

Eine der wichtigsten Designentscheidungen lautet: Wo liegt die Warteschlange? Wenn die Queue im CPE oder in einer Black-Box beim Provider liegt, ist das Verhalten schwer kontrollierbar und Messdaten fehlen. In vielen Access-Szenarien ist daher das Ziel, Congestion in kontrollierbare Geräte zu holen – durch Shaping knapp unter der realen Rate und durch klare Queueing-Policies. Das ist besonders wichtig bei DSL- und Cable-Upstreams, aber auch bei FTTH-Aggregation, wenn OLT-Uplinks der Engpass sind.

• Shaping: verlagert Congestion in kontrollierbare Queues.
• Queue-Limits: Echtzeitqueues kurz halten, Best Effort mit AQM stabilisieren.
• HQoS: kombiniert per-Subscriber Kontrolle mit Interface-Stabilität.

SLIs/SLOs im Access: Was Sie messen müssen, damit QoS nicht „gefühlte Qualität“ bleibt

Access-QoS ist nur so gut wie seine Telemetrie. Durchschnittsauslastung allein reicht nicht, weil Mikrobursts und Bufferbloat in kurzen Intervallen passieren. Für Voice/Video sind Queue-Delay und Queue-Drops pro Klasse entscheidend, ergänzt durch loss- und jitternahe Metriken (z. B. aus RTP/RTCP in Managed-Umgebungen). Für Best Effort sind RTT-Perzentile, ECN/WRED-Marks und Tail Drops relevant. Wichtig ist die Domänentrennung: Access, Aggregation und Core müssen getrennt sichtbar sein, sonst wird die Ursache falsch verortet.

• Queue-Delay: p95/p99 in kurzen Fenstern als Frühindikator für Echtzeitprobleme.
• Queue-Drops: pro Klasse; Drops in Voice/Video sind immer kritisch.
• Per-Subscriber Utilization: zeigt Noisy Neighbors und Profilüberschreitungen.
• Best Effort AQM/ECN: Mark- und Drop-Raten zur Bufferbloat-Reduktion.

Typische Failure Patterns im Access und ihre Ursachen

Viele Access-Störungen wiederholen sich: Voice ist „meistens gut“, bricht aber in der Busy Hour ein; Videokonferenzen ruckeln beim Upload; ein bestimmtes Segment hat hohe Latenz trotz genügend Bandbreite. Diese Muster lassen sich häufig auf wenige Ursachen zurückführen: fehlendes Shaping, zu große Buffers, inkonsistente Markings, fehlende HQoS-Hierarchie oder Engpässe in Aggregation/CMTS/OLT-Uplinks.

• Busy-Hour Jitter: Bufferbloat und Queueing in Upstream-Engpässen; AQM/Shaping prüfen.
• Spiky Loss: Mikrobursts; Queue-Limits und Shaping-Placement prüfen.
• Premium-Queue Flooding: fehlende Trust Boundary; Remarking/Policer fehlen.
• Failover-Probleme: Backup-Uplink ohne kompatible QoS-Policies und Headroom.

Blueprint: Access-QoS als wiederholbares Muster für DSL/FTTH/Cable

Ein belastbarer Ansatz beginnt mit einem schlanken Klassenmodell und klaren DSCP-Mappings. Danach wird am Access Edge eine Trust Boundary definiert: Allowlist, Remarking und per-Class Budgets pro Subscriber/Service. Anschließend wird HQoS etabliert: Parent-Shaping auf realistische Raten (inklusive Reserve), Child-Queues für Voice/Video/Signaling/Best Effort/Bulk. Best Effort erhält AQM/ECN, um Bufferbloat zu reduzieren, während Echtzeitqueues kurz gehalten und strikt begrenzt werden. Schließlich wird Telemetrie so aufgebaut, dass Queue-Delay und Drops in kurzen Fenstern sichtbar sind und sich Domänen sauber trennen lassen. So entstehen QoS-Patterns, die über DSL, FTTH und Cable hinweg konsistent funktionieren – trotz unterschiedlicher physikalischer Constraints.