Site icon bintorosoft.com

Bandwidth Engineering: Wie viele Calls pro Link bei Headroom?

Red Snapper

Bandwidth Engineering für Voice ist die praktische Kunst, aus „Link hat X Mbit/s“ eine belastbare Antwort zu machen: Wie viele Calls passen pro Link – und zwar so, dass bei Lastspitzen, Failover, Overhead und Mischtraffic immer noch Headroom bleibt? Genau hier scheitern viele Planungen, weil sie nur die Codec-Bitrate betrachten („G.711 hat 64 kbit/s“), aber nicht die On-the-Wire Realität: RTP/UDP/IP-Header, Layer-2-Overhead, mögliche Tunnel-Encapsulation (IPsec/GRE/VXLAN), Packetization Interval, Silence Suppression (VAD), RTCP, sowie – ganz entscheidend – die QoS-Architektur am Engpass (LLQ-Limit, Shaping, Policer). In Provider- und Enterprise-WANs ist außerdem wichtig, dass Sie nicht auf 100% Linkauslastung planen dürfen. Voice braucht stabile Delay-Perzentile, und genau die gehen bei hoher Auslastung zuerst kaputt (Bufferbloat, Microbursts, Queue-Divergenz). Ein gutes Bandwidth Engineering arbeitet deshalb mit einem klar definierten Headroom, mit Busy-Hour Annahmen und mit einer Call-Admisson-Logik, die verhindert, dass die Voice-Klasse über ihr Budget wächst. Ziel ist nicht „maximale Callzahl“, sondern „maximale Callzahl bei garantierter Qualität“ – und die erreichen Sie nur mit sauberen Modellen und konservativen Reserven.

Warum „Codec-Bitrate × Calls“ nicht reicht

Die Codec-Bitrate beschreibt nur die Nutzlast, nicht die Transportrealität. Ein Voice-Call besteht aus vielen kleinen Paketen pro Sekunde. Je kleiner die Nutzlast pro Paket (z. B. 20 ms Audio), desto größer ist der relative Overhead durch Header. Außerdem sind VoIP-Calls oft bidirektional, und häufig laufen zusätzlich RTCP-Pakete. Wenn Sie dann noch VLAN/QinQ, MPLS, PPPoE oder IPsec hinzufügen, steigt die On-the-Wire Rate deutlich. Wer nur mit 64 kbit/s rechnet, plant regelmäßig zu optimistisch, dimensioniert LLQ-Limits zu knapp und bekommt in Busy Hour Policer-Drops oder Realtime-Queue-Overflows.

Die Grundformel: On-the-Wire Bandbreite pro Call

Für eine belastbare Abschätzung brauchen Sie eine On-the-Wire Betrachtung. Vereinfacht gilt: Bandbreite pro Richtung = Pakete pro Sekunde × (Nutzlast + Header/Overhead) × 8. Die Pakete pro Sekunde ergeben sich aus dem Packetization Interval. Bei 20 ms sind es 50 Pakete/s, bei 30 ms etwa 33,3 Pakete/s. Die Nutzlast hängt vom Codec ab (z. B. 20 ms G.711 ≈ 160 Byte). Dazu kommen RTP/UDP/IP-Header (typisch 12 + 8 + 20 Byte bei IPv4, bei IPv6 mehr) und Layer-2-Overhead (Ethernet, ggf. VLAN/QinQ). Zusätzlich können MPLS-Labels oder Tunnel-Header hinzukommen. Für Engineering reicht oft ein konservativer „Header-Block“, den Sie je nach Umgebung anpassen.

Vereinfachtes Modell für Berechnungen

Typische Richtwerte: G.711, Opus, G.729 – was praktisch pro Call anfällt

Für schnelle Planungen arbeiten viele Teams mit Richtwerten pro Call und Richtung. Diese Richtwerte variieren je nach Packetization Interval und Overhead, aber als Faustformeln sind sie hilfreich. Wichtig: Diese Werte sind ohne externe Referenzen als Orientierungsgrößen zu verstehen, nicht als absolute Wahrheit für jedes Netz. In der Praxis sollten Sie die Header-Kette Ihrer Umgebung (L2/MPLS/Tunnel) einmal sauber bestimmen und daraus Ihre eigenen Standardwerte ableiten.

Headroom definieren: Warum Voice nicht bis zur Kante geplant werden darf

Die entscheidende Frage lautet nicht nur „wie viele Calls passen“, sondern „wie viele Calls passen, wenn das Netz noch stabil bleibt“. In QoS-Designs ist die Voice-Klasse (LLQ) meist strikt priorisiert, aber strikt limitiert. Wenn Sie die LLQ zu eng dimensionieren, entstehen Voice-Drops (hörbar). Wenn Sie sie zu groß dimensionieren, riskieren Sie Starvation anderer Klassen und destabilisieren das Gesamtsystem. Headroom ist daher ein zweistufiges Konzept: (1) Headroom auf dem Link insgesamt (damit Queues nicht dauerhaft wachsen), und (2) Headroom innerhalb des Voice-Budgets (damit Peaks, Overhead und Talkspurts nicht sofort an die Grenze stoßen).

Ein praxistaugliches Rechenverfahren in 6 Schritten

Damit Bandwidth Engineering reproduzierbar wird, lohnt sich ein standardisierter Ablauf. Er ist unabhängig davon, ob Sie Enterprise-SD-WAN, SASE, MPLS oder ein klassisches Telco-Access-Design betreiben. Entscheidend ist, dass Sie den Engpass identifizieren und auf diesen Engpass dimensionieren – häufig ist das der Upstream, nicht der Downstream.

Bidirektional planen: Warum Upload oft der limitierende Faktor ist

In vielen Access- und Enterprise-Szenarien ist der Upload die knappere Ressource. Gleichzeitig ist Upload-Bufferbloat ein Haupttreiber für Jitter und Latenzspitzen. Wenn Sie Calls nur auf Basis des Downstreams planen, laufen Sie in Busy Hour in Upstream-Probleme: der Shaper sitzt zu hoch, die Provider-Queue füllt sich, Voice leidet. Deshalb ist es Best Practice, Calls pro Richtung zu planen und den kleineren Wert als Grenze zu nehmen. Zusätzlich sollten Sie bei symmetrischen Services (z. B. Business Ethernet) trotzdem prüfen, ob Aggregation oder Policer asymmetrisch wirken.

LLQ-Budgetierung und Admission Control: Der wichtigste Schutz gegen „zu viele Calls“

Selbst wenn Sie sauber planen, kommt es im Betrieb zu Ausreißern: Peaks, Fehlmarking, zusätzliche Video-/Screen-Share Streams, oder ein Failover, der Traffic auf weniger Kapazität bündelt. Deshalb braucht Voice Bandwidth Engineering immer einen Betriebsmechanismus, der das Budget schützt. Das kann Call Admission Control (CAC) auf Applikations-/SBC-Ebene sein, ein LLQ-Limit im QoS, oder HQoS pro Site/Subscriber. Entscheidend ist, dass die Voice-Klasse nicht unbounded wachsen kann, sonst verschiebt sich das Problem: Voice bleibt vielleicht „okay“, aber das Netz wird instabil oder andere Dienste kollabieren.

Overhead-Fallen: SRTP, IPsec, MPLS, VLAN und warum Ihre Zahl sonst nicht stimmt

In modernen Netzen ist Voice oft verschlüsselt (SRTP) und nicht selten zusätzlich getunnelt (IPsec in SD-WAN, GRE, SASE). Jede Encapsulation erhöht die Byte-Last pro Paket. Besonders bei Voice mit kleinen Paketen ist der relative Overhead groß. Das bedeutet: Ein Profil, das ohne Tunnel knapp passt, kann mit Tunnel plötzlich policen. Für Bandwidth Engineering ist daher Pflicht: Sie definieren Standard-Overhead-Profile (z. B. „LAN“, „MPLS“, „IPsec“, „VXLAN“) und rechnen die Callzahl je Profil. Dann können Sie pro Standort oder Service eine konsistente, auditierbare Zahl kommunizieren.

Headroom-Strategien: Konservativ, aber nicht verschwenderisch

Headroom wird oft pauschal gewählt („wir lassen 20% frei“). Das ist besser als nichts, aber nicht immer optimal. Im Provider-Engineering ist Headroom domänenspezifisch: Access mit variabler Rate braucht mehr Reserve, ein stabiles Business-Ethernet weniger. Interconnects mit Fan-in und Microbursts profitieren von Shaping und AQM, wodurch Sie Headroom gezielter einsetzen können. Eine praxistaugliche Strategie kombiniert: (1) festen Mindestheadroom für Echtzeitstabilität, (2) zusätzlichen Headroom für Failover-Szenarien, (3) Monitoring-getriebene Anpassung über Perzentile (Queue-Delay p95/p99, Drops, Mark-Raten).

Beispielhafte Rechnung als Muster: Von Linkrate zu Callzahl

Ein Musterbeispiel hilft, das Vorgehen greifbar zu machen. Nehmen wir einen Engpasslink mit effektiven 10 Mbit/s nutzbarer Rate (nach Overhead/Varianz), und Sie reservieren 15% als generellen Headroom gegen Mischlast, Microbursts und Variabilität. Dann bleiben 8,5 Mbit/s planbar nutzbar. Davon definieren Sie z. B. 10% als Voice-LLQ-Budget (konservativ, abhängig vom Serviceprofil): 0,85 Mbit/s für Voice. Wenn Sie für G.711 mit 20 ms Packetization konservativ 90 kbit/s pro Richtung on-the-wire ansetzen, ergibt das etwa 9 Calls pro Richtung, also 9 gleichzeitige Calls über diesen Engpass. Für einen Codec mit geringerem Bedarf oder mit anderem Packetization kann die Zahl steigen, aber das Verfahren bleibt gleich: erst Linkheadroom, dann Voice-Budget, dann Division durch realistische per-call Werte, immer konservativ runden.

Warum Video und Screen Share die Callzahl „heimlich“ verändern

In modernen UC-Szenarien ist „ein Call“ nicht immer nur Audio. Videokonferenzen können mehrere Streams erzeugen (Audio, Video, Screen Share, ggf. mehrere Teilnehmerströme) und dynamische Bitraten nutzen. Wenn Sie „Calls pro Link“ planen, müssen Sie klar definieren, ob Sie Audio-only meinen oder „UC-Session“ mit Video. In vielen Organisationen ist der beste Ansatz: Audio und Video getrennt budgetieren (Voice in LLQ, Video in gewichtete Klasse) und für Video konservative Profile pro Meetingtyp definieren. Sonst wird die Voice-Zahl zwar eingehalten, aber die Gesamterfahrung bricht, weil Video die Datenklassen überfährt oder weil Failover-Pfade nicht dimensioniert sind.

Messbarkeit: So validieren Sie Ihre Callzahl im Betrieb

Bandwidth Engineering ist keine einmalige Rechnung, sondern ein Regelkreis. Sie müssen überprüfen, ob Ihre Annahmen stimmen: Wie hoch ist die reale LLQ-Auslastung in p95/p99? Gibt es Policer-Drops oder Remarking? Wie verhalten sich Queue-Delay und Jitter in Busy Hour? Gibt es Microbursts, die trotz ausreichender Durchschnittsrate Drops erzeugen? Die richtigen Messgrößen sind queuebezogen, nicht nur linkbezogen: Queue-Delay p95/p99 pro Klasse, Drops/Marks pro Klasse, und Call-/Sessiondaten (RTP jitter, loss, concealment). Wenn Ihre LLQ dauerhaft nahe am Limit läuft, ist die Callzahl zu hoch oder das per-call Modell zu konservativ/zu optimistisch – beides muss sauber getrennt werden.

Typische Fehlerbilder und wie Sie sie in der Planung verhindern

Wenn die Callzahl „auf dem Papier“ stimmt, aber Voice leidet, sind die Ursachen oft wiederkehrend. Häufig ist der Engpass nicht dort, wo Sie denken (z. B. Upstream statt Downstream). Oder die Voice-Budgetierung ignoriert Overhead und Paketisierung. Oder ECMP/Path-Variabilität erzeugt Jitter/late loss, obwohl Bandbreite vorhanden ist. Oder die LLQ ist unlimitiert und erzeugt Starvation, sodass das Netz instabil wird. Diese Fehler lassen sich durch eine saubere Bandwidth-Engineering-Methodik und durch Headroom-Disziplin vermeiden.

Blueprint: Calls pro Link mit Headroom als Standardprozess

Ein belastbarer Standardprozess beginnt mit der Definition Ihrer Voice-Profile (Codec, Packetization, Security/Tunnel). Daraus leiten Sie On-the-Wire Werte pro Richtung ab und dokumentieren sie als interne Standardtabelle. Dann identifizieren Sie pro Linktyp die effektive Rate und definieren Headroom-Regeln (Normalbetrieb und Failover). Anschließend legen Sie das Voice-Budget (LLQ-Limit) fest, inklusive eigenem Headroom. Daraus berechnen Sie die maximale gleichzeitige Callzahl als konservativ gerundeten Wert und koppeln diese Zahl an Admission Control oder an klare Betriebsgrenzen. Schließlich validieren Sie das Modell über Telemetrie: LLQ-Auslastung p95/p99, Queue-Delay/Drops, RTP-KPIs. So wird „wie viele Calls pro Link“ nicht zu einer Diskussion nach Gefühl, sondern zu einem reproduzierbaren Bandwidth-Engineering-Ansatz, der Headroom, QoS und reale On-the-Wire-Physik konsequent zusammenführt.

Exit mobile version