QoS in Aggregation: Wie viele Kunden passen auf einen Uplink?

QoS in Aggregation ist die Stelle, an der sich viele Access-Realitäten entscheiden: Nicht im Backbone, sondern am ersten oder zweiten Aggregationsknoten, wo viele Kundenströme auf einen gemeinsamen Uplink treffen. Genau dort entsteht die praktische Frage, die in Projekten und im Betrieb immer wieder kommt: „Wie viele Kunden passen auf einen Uplink?“ Die ehrliche Antwort lautet: Es hängt von Trafficprofilen, Serviceklassen, Overbooking-Strategie, Burst-Verhalten, Technologie (FTTH/PON, DSL, HFC, Ethernet Access, Mobile Backhaul), Peak-Zeiten und SLA-Anforderungen ab. Trotzdem ist die Frage absolut berechtigt, weil sie ein Planungsproblem beschreibt, das Sie strukturiert lösen können: Sie brauchen ein Klassenmodell (Voice, Video, Signaling, Best Effort), Sie brauchen Zielwerte für Qualität (Jitter/Loss/Delay), Sie brauchen eine Busy-Hour-Annahme und Sie brauchen ein Modell für gleichzeitige Nutzung (Concurrency). Dann können Sie Uplink-Kapazität und Kundenanzahl so dimensionieren, dass Premium-Services auch bei Spitzen stabil bleiben – und dass Best Effort fair degradiert, statt unkontrolliert Bufferbloat und Drop-Cluster zu erzeugen. Dieser Artikel zeigt, wie Sie aus QoS-Sicht eine belastbare Kapazitätsplanung für Aggregationsuplinks aufbauen, welche Rechenansätze sich bewährt haben, welche typischen Grenzen in der Praxis auftreten und wie Sie Monitoring und Tests nutzen, um das Modell im laufenden Betrieb zu verifizieren.

Warum die Aggregation der kritischste QoS-Punkt im Netz ist

Im Aggregationslayer treffen drei Effekte zusammen, die Echtzeitdienste besonders stressen:

• Viele Quellen, ein Ausgang: viele Kundenports oder Access-Devices bündeln sich auf einen Uplink.
• Microbursts: selbst wenn der Durchschnitt niedrig ist, können viele Kunden gleichzeitig kurze Spitzen erzeugen.
• Service-Mix: Voice, Video, Streaming, Gaming und Cloud-Sync überlagern sich – oft zu unterschiedlichen Tageszeiten.

QoS ist hier nicht optional, sondern notwendig, um zu verhindern, dass Echtzeit in Best Effort untergeht. Gleichzeitig ist QoS in Aggregation auch die Stelle, an der Overbooking seine Grenzen zeigt: Wenn zu viele Kunden gleichzeitig aktiv sind, muss QoS harte Prioritätsentscheidungen treffen.

Die falsche Frage und die richtige Frage

„Wie viele Kunden passen auf einen Uplink?“ klingt wie eine feste Zahl. In der Praxis ist die bessere Frage:

• Wie viele Kunden passen auf einen Uplink, wenn ich definierte Serviceprofile (Voice/Video/Control/BE) mit konkreten SLA-Zielen einhalten will?

Damit verschiebt sich die Planung von einer Marketingzahl zu einer technischen Dimensionierung. Sie planen nicht „Kunden“, sondern „gleichzeitige Last pro Klasse“.

Grundlagen: Overbooking, Concurrency und Busy Hour

Kapazitätsplanung in Aggregation basiert auf Statistik. Drei Begriffe sollten sauber definiert sein:

• Peak Rate pro Kunde: die vermarktete Anschlussbandbreite (z. B. 1 Gbit/s).
• Concurrency: Anteil der Kunden, die gleichzeitig „signifikant“ Traffic erzeugen.
• Busy Hour: das Zeitfenster mit der höchsten gleichzeitigen Nutzung (tagsüber eher UC/Meetings, abends eher Streaming).

Ein einfaches Overbooking-Denkmuster lautet: Sie dimensionieren den Uplink nicht für die Summe der Peak Rates, sondern für eine Busy-Hour-Last, die aus Concurrency und typischem Nutzungsprofil entsteht.

QoS-First Dimensionierung: Zuerst Premium sichern, dann Best Effort skalieren

Ein praxistauglicher Ansatz ist, die Kapazität in zwei Teile zu denken:

• Teil 1: SLA-/Premium-Budget für Voice, Signaling und ggf. interaktives Video.
• Teil 2: Best Effort-Budget für den Rest, das bei Congestion fair degradiert.

Das verhindert den klassischen Fehler, bei dem Best Effort durch Overbooking so stark wird, dass Premium nur noch „auf dem Papier“ existiert.

Serviceprofile, die Sie für die Uplink-Dimensionierung brauchen

Um Kundenanzahl pro Uplink seriös zu planen, definieren Sie mindestens vier Klassen:

• Voice (Audio): sehr geringe Bandbreite pro Call, aber extrem empfindlich auf Jitter/Loss; LLQ mit Limit.
• Signaling/Control: kleine Bandbreite, aber wichtig für Setup und Stabilität; hoch priorisiert gewichtet.
• Interaktives Video: größer und burstiger; gewichtete Klasse mit garantierten Anteilen.
• Best Effort: alles andere; fair, kontrollierte Puffer, ggf. Congestion Avoidance.

Für Access-Provider und Telcos ist dieser Schritt entscheidend: Ohne klare Profile lässt sich nicht sagen, ob „mehr Kunden“ technisch sinnvoll sind.

Rechenmodell 1: Uplink-Kapazität aus gleichzeitigen Sessions ableiten

Wenn Ihr Haupttreiber Echtzeit ist (z. B. Business-Kunden, UC/Voice), können Sie über gleichzeitige Sessions planen:

• Voice-Budget:
  $N\times \mathrm{Calls}/\mathrm{Kunde}\times \mathrm{kbps}/\mathrm{Call}$
  (inkl. Overhead und Richtung).
• Video-Budget:
  $N\times \mathrm{Meetings}/\mathrm{Kunde}\times \mathrm{Mbps}/\mathrm{Stream}$
  (je nach HD/Full-HD, Screen Share, Up/Down).
• Control-Budget: klein, aber als Mindestanteil reservieren.

Wichtig: Diese Budgets sind nicht die gesamte Uplink-Auslastung, sondern die Premiumanteile, die Sie im Worst Case schützen wollen. Best Effort füllt den Rest.

Rechenmodell 2: Busy-Hour-Durchsatz pro Kunde (Traffic Engineering Ansatz)

Für breitbandige Consumer-Profile ist Sessions-basierte Planung oft zu granular. Dann ist „Busy-Hour Throughput pro Kunde“ praktikabler:

• Busy-Hour Durchschnitt pro aktivem Kunde: ein realistischer Wert, der aus Messdaten/Erfahrung stammt.
• Aktivitätsgrad (Concurrency): wie viele Kunden sind in der Busy Hour aktiv?
• Uplink-Planwert:
  $\mathrm{Kapazität}\approx N\times \mathrm{Concurrency}\times \mathrm{BH}–\mathrm{Throughput}$

QoS kommt hier ins Spiel, weil Sie festlegen müssen, wie viel dieser Busy-Hour-Last in Premiumklassen landet und wie viel in Best Effort bleibt. Je mehr Video-UC in Premium läuft, desto weniger „freie“ Kapazität bleibt für BE.

Warum „Gigabit-Kunden“ nicht gleich „Gigabit-Uplink“ bedeuten

Ein häufiger Planungsfehler ist die Gleichsetzung von Access-Produkt und Aggregationsdimensionierung. Ein Kunde mit 1 Gbit/s Anschluss erzeugt selten dauerhaft 1 Gbit/s. Aber: Moderne Workloads (Cloud Backups, 4K-Streaming, große Updates) können sehr wohl kurzfristig hohe Peaks erzeugen. In Aggregation bedeutet das:

• Peaks bestimmen QoE: Microbursts können Voice stören, obwohl der Durchschnitt okay ist.
• Uplink muss Burst-fähig sein: Queue-Design, Shaping und Bufferarchitektur sind genauso wichtig wie „Gbit/s“.
• Overbooking braucht Governance: Wenn zu viele Kunden Premium markieren dürfen, wird EF/LLQ groß und instabil.

QoS-Mechanik im Aggregationsuplink: Was muss dort zwingend passieren?

Der Aggregationsuplink ist der Ort, an dem Congestion real wird. Deshalb müssen hier mindestens diese Mechanismen sauber umgesetzt sein:

• Klassifizierung und Markierung: DSCP/CoS korrekt übernehmen oder sauber remarken (Trust Boundary).
• Scheduler: Voice in LLQ mit Limit; Video und Control gewichtet; BE fair.
• Shaping: wenn der Uplink auf ein Providerprofil oder eine physische Rate begrenzt ist, Shaping knapp darunter.
• Queue-Limits: Voice klein, Video moderat, BE kontrolliert, um Bufferbloat zu vermeiden.
• Policer vorsichtig: harte Drops in Echtzeit vermeiden; Überschuss eher remarken.

Ohne diese Bausteine ist die Frage „wie viele Kunden“ kaum sinnvoll zu beantworten, weil die Qualität dann zufällig ist.

Die praktische Grenze: Wann ist ein Uplink „zu voll“ für Echtzeit?

Für die Praxis ist nicht „90 % Auslastung“ der Grenzwert, sondern die Frage, ob Premiumklassen noch stabil bleiben. Grenzen erkennen Sie an diesen Signalen:

• EF/Voice-Drops: Incident-Signal. Wenn Voice dropt, ist die Grenze überschritten oder die Governance falsch.
• Voice Queueing Delay Peaks: steigen die 95/99-Perzentile, droht Late Loss und MOS-Fall.
• Policer Drops auf Premium: zeigt, dass Profile nicht mehr zu Last/Bursts passen.
• Unplausibles EF-Volumen: Premium-Inflation; „zu viele Kunden“ ist dann oft weniger das Problem als „zu viel Premium“.

Wenn diese Signale in der Busy Hour regelmäßig auftreten, müssen Sie entweder Kapazität erhöhen, Premium-Budgets anpassen oder Markierungsgovernance verschärfen.

So wird aus „Kundenanzahl“ ein belastbarer Planwert

Ein praktikables Vorgehen im Projekt (und später im Betrieb) sieht so aus:

• Schritt 1: Uplink-Kapazität und Rate-Limits bestimmen (physisch und policer-/profilseitig).
• Schritt 2: Serviceprofile definieren (Voice/Control/Video/BE) und Budgets pro Klasse festlegen.
• Schritt 3: Busy-Hour-Lastmodell wählen (Sessions-basiert für Business/UC, Throughput-basiert für Consumer).
• Schritt 4: Concurrency schätzen (Messdaten bevorzugt) und konservative Peaks einplanen.
• Schritt 5: QoS-Mechanik am Uplink implementieren (LLQ mit Limit, weights, shaping, queue-limits).
• Schritt 6: Verifikation mit Telemetrie und Probes (EF/AF/BE), Sekundenfenster und Perzentile.
• Schritt 7: Kundenanzahl als operativen Grenzwert definieren (z. B. bis EF-Drops oder Delay-Perzentile bestimmte Schwellen erreichen).

Dieser Ansatz liefert nicht „eine magische Zahl“, sondern einen nachvollziehbaren Kapazitätsplan, der im Betrieb über Messwerte verifiziert und nachjustiert werden kann.

Monitoring als Kapazitätskompass: Welche Metriken Ihre Uplink-Grenze zeigen

• Traffic pro Klasse: EF/AF/Control/BE – Trends und plötzliche Verschiebungen.
• Queueing Delay pro Klasse: 95./99. Perzentile und Peaks.
• Drops pro Klasse: besonders EF und Video; Drop-Cluster sind wichtiger als Durchschnitt.
• Policer/Shaper Events: Exceed/Drop, Shaping Queueing, Remarking.
• Service-KPIs: MOS/R-Faktor, RTP Jitter/Loss, Video Freeze/Bitrate Switching, Call Setup Times.

Ein Uplink kann „durchschnittlich“ gut aussehen und trotzdem Echtzeit zerstören. Deshalb sind Perzentile und hochauflösende Telemetrie im Aggregationslayer Pflicht.

Typische Fehler bei der Frage „wie viele Kunden“

• Nur Peak Rates addieren: führt zu unrealistisch niedrigen Kundenanzahlen und ignoriert Concurrency.
• Nur Durchschnittswerte betrachten: übersieht Microbursts, die QoE dominieren.
• QoS im Core statt am Engpass: Congestion sitzt am Uplink; dort muss QoS greifen.
• Zu viele Premium-Markierungen: Premium-Inflation macht jede Overbooking-Strategie instabil.
• Policer auf Echtzeit: harte Drops erzeugen sofort hörbare Artefakte.

Praxis-Blueprint: Kapazität und QoS in Aggregation so planen, dass Echtzeit stabil bleibt

• Definieren: klare Serviceprofile mit Budgets (Voice strikt limitiert, Control geschützt, Video gewichtet, BE fair).
• Dimensionieren: N+1 und Busy-Hour-Concurrency berücksichtigen; Uplink nicht nur auf Durchschnitt planen.
• Schützen: Trust Boundary und DSCP-Whitelist gegen Premium-Inflation, Remarking für Überschuss.
• Glätten: Shaping an rate-limitierten Uplinks, um Microbursts und Bufferbloat zu reduzieren.
• Verifizieren: Classify-Hits, DSCP-Verteilungen, Queueing Delay/Drops pro Klasse, Probes pro Klasse.
• Operationalisieren: Grenzwerte über EF-Drops und Delay-Perzentile definieren; bei Drift früh reagieren.

Häufige Fragen zur Aggregationsplanung

Gibt es eine Faustformel für „Kunden pro Uplink“?

Es gibt keine universelle Zahl, weil Trafficprofile und SLAs stark variieren. Eine brauchbare Faustregel ist jedoch: Planen Sie Premium (Voice/Control/Video) zuerst über definierte Budgets und Concurrency, und lassen Sie Best Effort den Rest füllen. Die operative Grenze ist erreicht, wenn EF/Voice Drops oder starke Delay-Perzentile auftreten.

Warum sind Uplink-Probleme oft zuerst bei Voice sichtbar?

Weil Voice sehr sensibel auf Jitter und Drop-Cluster reagiert und keine Retransmits hat. Schon kurze Peaks in Queueing Delay oder wenige Drops pro Sekunde sind hörbar, während Best Effort zunächst nur „langsamer“ wirkt.

Was ist der wichtigste Hebel, wenn ein Aggregationsuplink zu eng wird?

Technisch sind es Shaping am Engpass und saubere Klassentrennung (LLQ für Voice mit Limit, Video gewichtet). Strategisch ist es Kapazitätsausbau oder Anpassung der Overbooking-Strategie. QoS kann Engpässe fair und SLA-konform verteilen, aber nicht dauerhaft fehlende Kapazität ersetzen.