Site icon bintorosoft.com

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

Red Snapper

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

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“

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

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.

Exit mobile version