Bandwidth Engineering: Wie viele Calls pro Link bei Headroom?

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.

• Transport-Overhead: RTP/UDP/IP + Layer-2 + ggf. MPLS/Tunnel erhöhen die effektive Rate.
• Paketfrequenz (PPS): kleine Packetization Interval erhöhen PPS und damit Overhead und Burstiness.
• Bidirektionalität: pro Gespräch zählen beide Richtungen, oft über denselben Engpass (z. B. Upstream).
• Mischtraffic: Voice läuft selten allein; Headroom muss Datenpeaks berücksichtigen.

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

• Paketisierung: $\mathrm{PPS}=1/t$ mit $t$ in Sekunden (20 ms → 0,02 s → 50 PPS).
• Bytes pro Paket: $\mathrm{Payload}+\mathrm{Overhead}$.
• Bitrate: $\mathrm{BW}=\mathrm{PPS}\cdot (\mathrm{Payload}+\mathrm{Overhead})\cdot 8$.

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.

• G.711 (20 ms): häufig im Bereich ~80–100 kbit/s pro Richtung „on the wire“, abhängig von L2/Tunnel-Overhead.
• G.729 (20 ms): trotz niedriger Nutzlast nicht proportional niedrig, weil Overhead dominiert; oft ~25–40 kbit/s pro Richtung.
• Opus: stark variabel (Bitrate, FEC, DTX), daher eher mit Profilen planen (z. B. „Opus-Voice-Mode“), nicht mit einem Fixwert.

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).

• Link-Headroom: Reserve gegen Mikrobursts, variable Access-Raten, Provider-Queueing und Failover.
• LLQ-Headroom: Reserve innerhalb der Realtime-Klasse für Peaks und Modellunsicherheit.
• Operational Headroom: Reserve für Wachstum, Messfehler, neue Applikationen und „Bad Minutes“.

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.

• Engpass bestimmen: Wo entsteht Congestion wirklich? (Upstream/Access/Interconnect/Hub)
• Linkrate realistisch setzen: effektive Rate statt nominale Vertragsrate (inkl. Overhead/Variabilität).
• Voice-Profil festlegen: Codec, Packetization, ggf. SRTP, VAD, FEC.
• On-the-Wire pro Call berechnen: pro Richtung und für beide Richtungen, wo relevant.
• Headroom abziehen: Link-Headroom und LLQ-Headroom definieren.
• Max Calls ableiten: verfügbare Voice-Bandbreite / Bandbreite pro Call, konservativ runden.

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.

• Upstream ist oft enger: besonders bei Broadband-Access und in Home-Office.
• QoS wirkt am Engpass: ohne korrektes Shaping wandert Congestion zum Provider.
• Callzahl = min(Uplink, Downlink): konservativ und realitätsnah.

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.

• CAC: begrenzt Calls aktiv, bevor die Qualität leidet.
• LLQ-Limit: verhindert Starvation und macht Realtime-Budgets messbar.
• HQoS: verhindert Noisy Neighbor Effekte bei Multi-Site/Multi-Tenant.
• Degrade statt Drop: Überschreitungen ummarkieren, wenn harte Drops in Voice zu teuer sind.

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.

• Small packets, big overhead: Voice ist PPS-lastig; Overhead wirkt überproportional.
• MTU/MSS: Overhead kann Fragmentierung triggern; das wirkt wie Loss und reduziert effektive Qualität.
• Provider-Policer: Overhead zählt „on the wire“; zu knappe Profile droppen echte Voice.

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).

• Access-Headroom: höher bei variablen Links, geringer bei stabilen Leased Lines.
• Failover-Headroom: abhängig von Schutzpfaden und Traffic-Bündelung.
• QoS-Headroom: LLQ nicht „bis zur Kante“ planen; Peaks einkalkulieren.

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.

• Audio-only: relativ gut planbar, konstante PPS und Bitraten je Profil.
• Video: variabel, burstig, höhere Anforderungen an Mindestbandbreite und Loss-Spitzen.
• Separates Budget: verhindert, dass Video die Voice-Planung verwässert.

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.

• LLQ Utilization p95/p99: zeigt, ob das Voice-Budget realistisch ist.
• Policer/Remarking Counters: zeigen Profilüberschreitungen und Missmarking.
• Queue-Delay: frühes Signal für Bufferbloat und Mikrobursts.
• RTP KPIs: jitter, late loss, concealment – direkter QoE-Indikator.

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.

• Overhead ignoriert: Policers greifen zu früh, Voice bekommt Drops.
• Headroom fehlt: Queueing-Delay steigt in Busy Hour, Jitter Buffer wächst, QoE sinkt.
• Falscher Engpass: Upload überläuft, obwohl Download frei ist.
• Video nicht getrennt: Meetings sprengen die Audio-Planung.
• Failover nicht modelliert: Schutzpfade brechen unter Last.

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.