Das Packetization Interval (Paketisierungsintervall) ist einer der unterschätzten Stellhebel in VoIP- und IMS-Designs, weil es gleichzeitig Bandbreite, Jitter-Verhalten, Paketverlustwirkung und damit auch den MOS (Mean Opinion Score) beeinflusst. Viele kennen nur die Faustregel „20 ms ist Standard“ – und das stimmt oft. Aber sobald Links knapp sind, viele gleichzeitige Calls laufen, VPN/Overlays im Spiel sind oder ein Contact Center in der Busy Hour arbeitet, wird das Packetization Interval plötzlich zu einer echten Qualitäts- und Betriebsentscheidung. Ein kürzeres Intervall (z. B. 10 ms) erzeugt mehr Pakete pro Sekunde: Das kann die Codec-Latenz senken und dem Jitter-Buffer feinere Zeitauflösung geben, erhöht aber Overhead, CPU-/PPS-Last und Microburst-Risiko. Ein längeres Intervall (z. B. 30 ms) senkt Overhead und Paketrate, erhöht aber die Verzögerung pro Paket und macht einzelne Paketverluste „teurer“, weil mehr Audio in einem Paket steckt. Für MOS ist genau dieses Zusammenspiel entscheidend: MOS fällt, wenn One-Way-Delay steigt, wenn Jitter so schwankt, dass der Jitter-Buffer vergrößert werden muss, oder wenn Paketverlust (insbesondere Drop-Cluster) hörbar wird. Dieser Artikel erklärt praxisnah, wie das Packetization Interval Jitter und MOS beeinflusst, welche Werte in welchen Szenarien realistisch sind und wie Sie das Intervall zusammen mit QoS (LLQ, Shaping, Queue-Limits) so auswählen, dass Sprachqualität stabil bleibt.
Was ist das Packetization Interval?
Das Packetization Interval beschreibt, wie viel Audiozeit in ein RTP-Paket gepackt wird. Bei 20 ms bedeutet das: Der Codec sammelt 20 Millisekunden Audio, baut daraus die Payload und sendet ein RTP-Paket. Daraus ergeben sich direkt die Pakete pro Sekunde (PPS):
PPS= 1000/PI
Mit PI in Millisekunden:
- 10 ms: 100 pps
- 20 ms: 50 pps
- 30 ms: ca. 33,3 pps
Diese PPS-Zahl ist nicht nur „eine Statistik“, sondern ein operativer Faktor: Sie beeinflusst Overhead, Router-/Firewall-Load, Queue-Verhalten und die Wahrscheinlichkeit von Microbursts.
Wie Packetization Interval die Bandbreite beeinflusst
Bei gleicher Codec-Bitrate bleibt die Nutzdatenmenge pro Sekunde gleich. Was sich ändert, ist die Payload pro Paket und damit der Overheadanteil. Je kürzer das Interval, desto mehr Pakete pro Sekunde, desto häufiger zahlen Sie die Headerkosten (RTP/UDP/IP und ggf. Layer 2).
Overhead-Prinzip
- Mehr PPS → mehr Header pro Sekunde → mehr Bandbreite „für Verpackung“.
- Weniger PPS → weniger Header pro Sekunde → effizientere Bandbreitennutzung.
Das ist besonders relevant bei Codecs mit geringer Payload (z. B. stark komprimierte Codecs). Dort dominiert der Overhead schnell, und ein sehr kurzes Intervall kann die Einsparung teilweise wieder auffressen.
Die drei MOS-Treiber: Delay, Jitter und Loss
Um zu verstehen, wie Packetization Interval den MOS beeinflusst, genügt es, MOS als Funktion von drei praxisnahen Treibern zu betrachten:
- One-Way Delay: je höher die Verzögerung, desto schlechter die Gesprächsinteraktion (und desto höher die Wahrscheinlichkeit von Echo).
- Jitter: schwankende Laufzeiten zwingen den Jitter-Buffer, größer zu werden; das erhöht die effektive Latenz und kann bei Peaks zu „Late Loss“ führen.
- Paketverlust: jedes verlorene oder zu spät kommende Paket ist hörbar; Drop-Cluster sind besonders schädlich.
Packetization Interval beeinflusst alle drei – aber in unterschiedlichen Richtungen. Genau darin liegt der Zielkonflikt.
Packetization Interval und Delay: Mehr Audio pro Paket heißt mehr „Codec-Latenz“
Wenn Sie 30 ms Audio sammeln, bevor ein Paket gesendet werden kann, entsteht eine zusätzliche Verzögerungskomponente im Senderpfad. Zusätzlich kommen Codec- und Verarbeitungslatenzen hinzu. Das bedeutet nicht automatisch „30 ms mehr One-Way Delay“, aber es verschiebt den Delay-Budget spürbar – besonders in End-to-End-Szenarien mit ohnehin knappen Latenzbudgets (Contact Center, Telemedizin, VoNR/VoLTE).
- 10 ms: tendenziell geringere Paketisierungsverzögerung, schnellerer Versand
- 20 ms: bewährter Kompromiss, meist gut innerhalb typischer Delay-Budgets
- 30 ms: effizienter, aber erhöht die Baseline-Verzögerung und kann MOS in Grenzfällen senken
Wichtig: Wenn das Netz ohnehin Jitter verursacht, wird der Jitter-Buffer größer – und dann wirkt ein längeres Packetization Interval doppelt: mehr Baseline-Delay plus mehr Buffer-Delay.
Packetization Interval und Jitter: Nicht nur „wie viel“, sondern „wie sichtbar“
Jitter ist die Variation der Paketankunftszeit. Packetization Interval verändert nicht direkt die Netzjitter-Quelle, aber es beeinflusst, wie der Jitter sich auf die Audioausgabe auswirkt:
- Kürzere Intervalle: mehr Pakete, kleinere Audioportionen pro Paket; einzelne verspätete Pakete verursachen kleinere hörbare Lücken – aber es gibt mehr Gelegenheiten für Verzögerungsschwankungen.
- Längere Intervalle: weniger Pakete, größere Audioportionen; einzelne verspätete Pakete sind „teurer“ und führen zu auffälligeren Aussetzern.
In der Praxis bedeutet das: In einem Netz mit gelegentlichen Jitter-Spikes kann 30 ms schneller „hörbar“ werden als 20 ms, weil ein einzelnes Problemereignis mehr Audio betrifft. In einem sehr stabilen Netz kann 30 ms dagegen gut funktionieren und Overhead sparen.
Packetization Interval und Paketverlust: Wie teuer ist ein verlorenes Paket?
Ein zentraler MOS-Faktor ist, wie der Codec und der Receiver Paketverlust kaschieren können. Beim Packetization Interval ist die Verlustwirkung einfach zu verstehen:
- 10 ms: ein Paketverlust „fehlt“ 10 ms Audio
- 20 ms: ein Paketverlust „fehlt“ 20 ms Audio
- 30 ms: ein Paketverlust „fehlt“ 30 ms Audio
Je größer die fehlende Audiozeit, desto schwerer ist es, diese sauber zu kaschieren. Packet Loss Concealment (PLC) kann kleine Lücken besser „überbrücken“ als große. Deshalb ist 30 ms in Netzen mit sporadischen Drops oft riskanter für den MOS als 20 ms.
Microbursts und Queueing: Warum 10 ms nicht automatisch „besser“ ist
Auf dem Papier klingt 10 ms attraktiv: niedrigere Paketisierungsverzögerung, feinere Granularität. In der Praxis gibt es aber einen Haken: 100 pps pro Call belasten Geräte und Queues stärker. Bei vielen gleichzeitigen Calls steigt die PPS-Last massiv. Das kann Effekte auslösen, die den MOS indirekt verschlechtern:
- Höhere PPS-Last: Firewalls, SBCs, virtuelle Router und VMs können in den Slowpath geraten; Jitter steigt.
- Mehr Scheduling-Events: mehr Pakete bedeuten mehr Gelegenheiten für kurzfristiges Queueing.
- Microbursts: viele kleine Pakete können in Aggregation kurzzeitig als Burst auftreten, insbesondere bei Tunnel/Encap oder bei CPU-Jitter.
Deshalb ist 10 ms vor allem dann sinnvoll, wenn Netz und Plattformen darauf ausgelegt sind (hohe PPS-Kapazität, sauberes QoS, Shaping an Engpässen). In vielen Standardumgebungen ist 20 ms stabiler.
20 ms als Standard: Warum es sich in der Praxis bewährt hat
20 ms ist nicht zufällig der „Default“ vieler Systeme. Es ist ein Kompromiss zwischen:
- Overhead: moderat (50 pps)
- Delay: meist innerhalb typischer End-to-End-Budgets
- Loss-Wirkung: Verlust eines Pakets ist hörbar, aber häufig noch kaschierbar
- Gerätebelastung: PPS-Last bleibt beherrschbar
In Provider- und Enterprise-Netzen ist 20 ms daher oft die sicherste Baseline für MOS-stabile Sprachqualität, solange QoS (LLQ, Shaping, Trust Boundary) sauber implementiert ist.
30 ms und mehr: Wann es Sinn ergibt – und wann es gefährlich wird
Längere Intervalle werden häufig genutzt, um Bandbreite und PPS zu reduzieren, besonders auf schmalen Links oder in Szenarien mit sehr vielen Sessions. Das kann sinnvoll sein, wenn das Netz stabil ist und Paketverlust sehr niedrig bleibt.
- Sinnvoll: stabile MPLS/Carrier-Backbones, gut gemanagte Access-Links, striktes QoS ohne Drops in Voice-Klasse
- Riskant: Internet-VPNs, WLAN-lastige Umgebungen, überlastete Firewalls, Links mit Policing und Drop-Clustern
Bei 30 ms sind Drops und Jitterspitzen schneller hörbar. In kritischen Umgebungen (Telemedizin, Notruf, Contact Center) ist 20 ms meist die robustere Wahl, sofern Bandbreite es erlaubt.
Jitter-Buffer und Packetization Interval: Zwei Stellhebel, eine Wirkung
Der Jitter-Buffer im Endgerät ist der „Stoßdämpfer“ gegen Laufzeitschwankungen. Er fängt Jitter ab, erhöht aber die effektive Verzögerung. Packetization Interval beeinflusst, wie der Jitter-Buffer arbeitet:
- Kürzere Intervalle: mehr, kleinere Pakete; Buffer kann feiner reagieren, aber muss mehr Pakete verwalten.
- Längere Intervalle: weniger, größere Pakete; Bufferreaktionen sind gröber, einzelne verspätete Pakete schmerzen stärker.
Praktische Konsequenz: In einem Netz mit schwankender Verzögerung steigt der Jitter-Buffer an. Wenn Sie gleichzeitig ein langes Packetization Interval nutzen, steigt die Gesamtlatenz schnell – und MOS sinkt.
QoS-Design: Packetization Interval richtig mit LLQ, Shaping und Limits kombinieren
Unabhängig vom Intervall gilt: Audio muss in einer Echtzeitklasse laufen und darf nicht gedroppt werden. Die Wahl des Intervalls beeinflusst aber, wie Sie QoS dimensionieren:
- LLQ-Limit: bei 10 ms steigen PPS und Overhead; das LLQ-Limit muss zur tatsächlichen „on-the-wire“-Last passen.
- Shaping am Engpass: glättet Bursts und verhindert Drop-Cluster – besonders wichtig bei 10 ms und bei VAD-Transitions.
- Policing vermeiden: harte Policer auf Voice sind bei jedem Intervall riskant; bei 30 ms sind Drops besonders hörbar.
- Queue-Limits klein halten: Voice soll nicht gepuffert, sondern schnell gesendet werden; große Puffer erzeugen Jitter.
Wenn MOS-Ziele streng sind, ist die wichtigste Regel: keine Drops in der Voice-Klasse. Dann ist 20 ms oft die stabilste Wahl, während 10 ms nur bei sehr sauberem Underlay und hoher PPS-Fähigkeit Vorteile bringt.
Typische Fehlerbilder und wie das Packetization Interval darin steckt
- „Erste Silben fehlen“: oft nicht direkt Packetization, sondern Kombination aus VAD und Burst-Drops; bei 30 ms fällt das stärker auf.
- „Knacken bei Peak“: Drops/Policer-Hits in Voice; bei 30 ms sind Aussetzer länger, MOS fällt stärker.
- „MOS bricht sporadisch ein“: Microbursts und Queueing Delay; bei 10 ms können PPS-Spitzen Geräte belasten, bei 30 ms ist Loss-Wirkung höher.
- „Über VPN schlechter“: Outer-DSCP fehlt, Shaping fehlt, MTU-Probleme; Packetization kann das Problem verstärken, ist aber selten die Hauptursache.
Praxis-Blueprint: Packetization Interval auswählen, ohne MOS zu gefährden
- 20 ms als Baseline: für die meisten Enterprise- und Telco-Setups ist 20 ms der beste Kompromiss.
- 10 ms gezielt einsetzen: nur wenn PPS-Kapazität, QoS und Shaping sauber sind und Sie sehr niedrige Delay-Budgets brauchen.
- 30 ms nur bei sehr stabilem Netz: nutzen, wenn Bandbreite/PPS kritisch sind und Paketverlust extrem niedrig bleibt.
- LLQ-Limit aus „on-the-wire“-Werten ableiten: nicht nur Codec-Bitrate betrachten, Overhead berücksichtigen.
- Shaping an Engpässen: insbesondere im Upstream und vor Rate-Limits; reduziert Drop-Cluster und stabilisiert Jitter.
- Monitoring auf Perzentile: Queueing Delay, Drops in Voice, RTCP-Jitter/Loss – Peaks zählen mehr als Durchschnitt.
Häufige Fragen zum Packetization Interval
Ist 10 ms immer bessere Qualität als 20 ms?
Nicht automatisch. 10 ms kann die Baseline-Verzögerung senken, erhöht aber PPS und Overhead und kann Geräte/Queues stärker belasten. In vielen realen Netzen ist 20 ms stabiler und liefert einen besseren MOS, weil es weniger anfällig für Microbursts und PPS-bedingten Jitter ist.
Warum fällt MOS bei 30 ms oft stärker bei kleinen Problemen?
Weil ein verlorenes oder verspätetes Paket 30 ms Audio betrifft. Diese größere Lücke ist schwerer zu kaschieren und wirkt subjektiv stärker. Zusätzlich erhöht 30 ms die Baseline-Verzögerung und kann den Jitter-Buffer schneller vergrößern.
Was ist der wichtigste QoS-Hebel unabhängig vom Interval?
Eine kleine, limitierte Low-Latency-Queue für Audio (EF/LLQ) plus Shaping an rate-limitierten Engpässen, damit keine Drop-Cluster entstehen. Wenn Voice nicht gedroppt wird und Queueing Delay stabil bleibt, bleibt der MOS in der Regel auch stabil – unabhängig davon, ob Sie 20 ms oder in Spezialfällen 10 ms nutzen.