Ursachen des Jitters

Für Genauigkeitsschwankung im Übertragungstakt sind sowohl Voice over IP (VoIP)- und über paketvermittelte Netze übertragene Video- als auch andere Echtzeitanwendungen anfällig. Die Genauigkeitsschwankung im Übertragungstakt ist insbesondere bei Multimedia-Anwendungen störend, da dadurch Pakete zu spät eintreffen können, um noch zeitgerecht mit ausgegeben werden zu können. Dies wirkt sich wie eine erhöhte Paketverlustrate aus. Treffen die Pakete einer Audioverbindung regelmäßig beim Empfänger ein, können diese direkt in Audiosignale umgesetzt werden. Da die Verzögerungen bei der Übertragung nicht konstant sind, entstehen Lücken im abgespielten Signal. Die Differenz zwischen den Verzögerungen einzelner Pakete wird als Jitter (Verzögerungsschwankung) bezeichnet. Man unterscheidet jedoch folgende Jitter-Typen:

· Typ A – konstanter Jitter: Die Genauigkeitsschwankung verändert sich zwischen der Ankunft unterschiedlicher aufeinanderfolgender Pakete nicht.

· Typ B – transienter Jitter: Die Genauigkeitsschwankung macht sich durch eine erhebliche Verzögerung bemerkbar und kann bereits durch die Verzögerung eines einzigen Pakets entstehen.

· Typ C – kurzzeitige Verzögerungsvariation: Diese Genauigkeitsschwankung kennzeichnet einen Anstieg der Verzögerung zwischen mehreren Paketen. Der Typ C Jitter tritt häufig bei Staus in Routern und Switches und bei Routen- Änderungen auf.

Paketverzögerungen im Sendesystem (Typ B): Bei einigen Systemen, beispielsweise Softphones, muss der VoIP-Prozess um die CPU mit anderen Anwendungen kämpfen. Aus diesem Grund kann bei diesen Systemen, während des Sendeprozesses, bereits zwischen den Paketen ein gewisser Jitter entstehen.

Überlastung im LAN (Typ B): Obwohl die Auslastung der LANs in der Regel relativ gering ist, können im Netz kurzzeitig Überlastungen auftreten. Im schlechtesten Fall dauert die Verzögerung so lange wie die Binary Exponential Backoff-Zeit des Ethernet Contention Algorithmus bzw. lässt sich anhand des Inter Packet Delays ableiten. Der Binary Exponential Backoff ist ein Stauauflösungsmechanismus. Wird von Stationen im Ethernet eine Kollision erkannt, beenden diese Stationen ihre Sendung und versuchen sofort oder nach einer Slot-Time von 51,2 µs (entspricht 512 Bit, gilt nur für 10/100 MBit/s Ethernet, 4,096 µs und 4096 Bit bei 1 GBit/s) erneut ihre Sendung über das Ethernet zu übertragen. Erhält ein VoIP-System aufgrund der maximalen Backoff-Zeit keinen Zugang zum LAN wird die Sendung zurückgestellt bzw. das betreffende Paket verworfen.

Beispiel einer Überlastung im LAN

Überlastung der Firewall (Typ B/C): Einige Firewalls terminieren die IP Streams auf einer Seite der Firewall und setzen diese Verbindung erneut auf der anderen Seite der Firewall auf. Das Verbindungsglied zwischen den beiden Streams erbringt die notwendige Inspektion der Paketinhalte und zusätzliche Sicherheitsmechanismen. Je nach Auslastung des Systems entstehen hierbei unterschiedlich lange Verzögerungen. Durch eine Implementation der Firewall-Funktionalität in ASICs wird dieses Problem auf ein Minimum reduziert.

Überlastung der Access Links (Typ C): Access-Links sind in der Regel die Engpässe einer Ende-zu-Ende-Kommunikationsbeziehung und somit die Hauptverursacher von Jitter. Beispielsweise führt die Serialisierung eines 1500 Byte IP-Pakets über eine 1.544 MBit/s schnelle WAN-Verbindung zu einer Verzögerung von ca. 8 Millisekunden. Befinden sich in einem Router bereits fünf Datenpakete in der Ausgangswarteschlange bevor ein VoIP-Paket beim Router eintrifft, wird dieses zusätzlich um 40 Millisekunden verzögert. Es muss warten bis die fünf Datenpakete über den WAN-Link übermittelt wurden. Zusätzlich kann bei ADSL oder CATV-Modems die Upload-Bandbreite durch eine Unsymmetrie der Transportströme noch weiter begrenzt sein. Verfügt ein Anschluss nur eine Upload-Bandbreite von 384 Kbit/s dann wird in der Ausgangswarteschlange jedes 1500 Byte IP-Paket um weitere 30 Millisekunden verzögert.

Beispiel eines überlasteten Accesslinks

Lastverteilung über mehrere Access Links oder IP Service Provider (Typ A): Zur Realisierung von Redundanzfunktionen im WAN werden die Datenströme auf mehrere geroutete Access Links zu einem IP-Service-Provider oder mehreren unabhängigen ISPs übermittelt. Die einzelnen Pakete einer VoIP-Verbindung können dadurch über unterschiedliche Pfade übertragen werden. Da die Verzögerungen auf den einzelnen Pfaden unterschiedlich sein können, entsteht naturgemäß ein Jitter.

Lastverteilung innerhalb eines IP Services (Typ A):Einige IP-Service-Provider leiten den zu transportierenden Datenverkehr über mehrere Strecken ihres Netzwerks zum Ziel. Dies verbessert die Verfügbarkeit der Dienste und sorgt für eine gleichmäßigere Netzauslastung. Da die Routenentscheidungen nicht auf Basis der Datenströme, sondern auf Basis jedes Pakets getroffen werden, entstehen aufgrund unterschiedlicher Laufzeiten der Strecken der Jitter.

Lastverteilung innerhalb von Routern (Type A): Eine „Multi-Processing-Lösung“ sorgt in einigen Router-Architekturen für die Erhöhung der Übertragungskapazität. Dabei werden die abgehenden Datenpakete von mehreren parallelen Warteschlangen verarbeitet. Da die Warteschlangen nicht zu 100 Prozent synchron laufen (Ursache: unterschiedlich lange Pakete) kann diese Technik zu einer minimalen Erhöhung des Jitters führen.

Updates der Routing-Tabellen (Typ B): Die Routing-Tabellen in den Routern werden permanent einem Update unterzogen. Die Updates werden zu den benachbarten Routern mit einer hohen Priorität übermittelt. Da die Routen-Updates für die Übermittlung die hierfür notwendigen Router-Ressourcen benötigen, kann dies zu kurzzeitigen Verzögerungen bei der Übermittlung des regulären Datenverkehrs führen. Darüber hinaus können während des Updates der Routing-Tabellen kurzzeitige Routing-Loops bestehen. Routing-Loops sorgen für eine extrem hohe Verzögerung einzelner Pakete.

Durch Routing-Tabellen-Updates hervorgerufene periodische Verzögerungen

Routenänderungen (Typ B):Die Ursachen für Routenänderungen sind oftmals überlastete Verbindungen oder Fehler auf WAN-Links. Ein sogenanntes Routen-Flattern entsteht, wenn ein Router abwechselnd ein Ziel in schneller Folge, über eine und anschließend über eine andere Strecke propagiert. Ein eng verwandter Begriff ist das Schnittstellenflattern, bei dem eine Schnittstelle auf einem Router durch einen Hardware-Fehler abwechselnd zu- bzw. abgeschaltet wird. Das Routen- bzw. Schnittstellenflattern kann durch unterschiedliche Verzögerungen zu einem Jitter führen.

Zeit-Drift (Typ B): Ein Zeit-Drift macht sich nicht immer als Jitter bemerkbar. Ein Zeit-Drift kann jedoch zu gelegentlichen Jitter-Pufferproblemen (periodischer Überlauf oder Leerung des Jitter-Puffers) führen. Typische Zeitkomponenten in Rechnern weisen eine Frequenztoleranz von 300 ppm (plus 50 ppm durch Temperaturdrift) auf.

Messungen des Jitters

Zur Messung des Jitters werden heute die unterschiedlichsten Lösungsansätze verwendet. Leider sind die gängigen Messmethoden nicht in der Lage alle drei oben beschriebenen Jitter-Arten gleich gut darzustellen.

Mittlere Paket-zu-Paket Verzögerungsvariationen

Die von Paket-zu-Paket auftretenden Verzögerungsvariationen (MPPDV, Mean Packet to Packet Delay Variation) dienen als Grundlage der RTCP (RFC 1889) Jitter-Messung. Aus der Verzögerung von zwei aufeinander folgenden Paketen (T1 und T2) errechnet sich die Paket-zu-Paket-Verzögerung: abs (t2-t1). Die mittlere Paket-zu-Paket-Verzögerung errechnet sich daher wie folgt:

MPPDV = mittlere(abs(ti – ti-1) )

Bei Echtzeitanwendungen wie z.B. VoIP spricht man von Datenströmen. Die zuvor berechnete Zeit liefert bei einem konstanten Datenstrom die Zwischenankunftszeit. Diese Zeit sollte im Idealfall für eine Datenverbindung immer Konstant sein. Bei einer VoIP Verbindung werden im Regelfall Pakete alle 20 ms verschickt. Die Berechnung von oben würde also im Idealfall immer 20 ms ergeben. Bei Abweichungen von diesen 20 ms spricht man von Jitter welche im nächsten Abschnitt behandelt wird.

Mittlere absolute Paketverzögerungsvariation

Ist die nominale Ankunftszeit (im folgenden ai) für ein Paket bekannt oder kann ermittelt werden, dann beträgt die absolute Verzögerungsvarianz abs (MPPDV - ai). Um den Jitter zu berechnen müssen wir ai definieren. Bei einer VoIP Anwendung kann dieser Wert anhand der Timestamps in den Paketen berechnet werden. Die Zeitstempel werden beim Senden erzeugt und in die Pakete geschrieben. Ai kann daher aus zwei Timestamps berechnet werden. Wenn davon ausgegangen wird, das T der Timestamp eines Paketes ist und A die Ankunftszeit ist, ergeben sich vier Variablen bei zwei hintereinander folgenden Paketen. T1 und A1 für das erste Paket und T2 und A2 für das zweite Paket. Die mittlere absolute Abweichung der Paketverzögerung lautet dann:

Jitter_absolut = (A2 – A1) – (T2 - T1)

Dieser Wert gibt den absoluten Jitter der einzelnen Pakete an. Da Dieser Wert sehr schwanken kann wird für RTCP Übermittelung eine andere Berechnung verwendet um einen Mittelwert zu Bilden. Folgende Formel gibt die Berechnung für Jitter für RTCP an.

RTCP_Jitter = RTCP_Jitter + (abs(jitter_absolut)-RTCP_Jitter)/16

Durch diese Berechnung erreicht man einen Mittelwert, über alle empfangenen Pakete. Der Faktor 1/16 wird verwendet um die Auswirkungen einzelner Großen Jitter zu minimieren. Dieser Wert wird dann in jeweils in den RTCP Paketen alle 5 Sekunden ausgetauscht.

Vergleich von verschiedenen Jitter-Betrachtungen

Abbildung 4 zeigt einen Vergleich von verschiedenen Jitter-Betrachtungen. Der Absolute Jitter spiegelt den genauen Jitterverlauf wieder. Der RTCP-Jitter zeigt durch seine Mittelung eine ungefähre Darstellung des Jitters. Bei kurzzeitigem Jitteranstieg, fällt dies jedoch nicht auf. Der MPPDV ist für eine Aussage über das Jitterverhalten sehr ungeeignet, da dieser sich relativ schnell auf einen Wert einpendelt.

Y.1541 IPDV Parameter

Die ITU-T definiert im Dokument Y.1541 (ITU-T Recs. Y.1541 and Y.1221 —
A Basis for IP Network QoS Control and Traffic Management) die IP Verzögerungsvariation in Bezug auf die Differenz zwischen dem Minimum und Maximum der Übertragungsverzögerungen während eines Zeitintervalls.

IPTDmin = Minimum IP Übertragungsverzögerung

IPTDupper = 99.9 Prozent der IP Übertragungsverzögerung

IPDV = IPTDupper – IPTDmin

Dieser Parameter wird durch die Länge des Messintervalls bestimmt. In Abbildung 6 beträgt IPDV ca. 60 Millisekunden. Für diesen Zeitraum ist es unmöglich den Jitter mit der Anzahl der Paketverluste zu korrelieren. Nur bei einem längeren Messintervall (200 Millisekunden) lässt sich der IPDV Wert zur Abschätzung der einer möglichen Datenverlustwahrscheinlichkeit heranziehen. Anhand dieses Werts lässt sich anschließend ableiten, wie hoch der Prozentanteil der Messintervalle am Gesamtverkehrsaufkommen ist, die von wahrscheinlichen Paketverlusten betroffen sind.

Paketverzögerungsvariationen

Mit jedem der bisher diskutierten Lösungsansätze für die Jitter-Messungen lassen sich die Jitter nur über kurze Zeiträume darstellen. Diese Ansätze beziehen sich entweder auf eine Paket-zu-Paket- oder eine absolute Paketverzögerungsvariation.

Zeitreihenanalyse

Ein alternativer Lösungsansatz wird als Zeitreihenanalyse bezeichnet. Bei diesem Zeitreihenmodell wird eine zufällige Reihenfolge von Messwerten mit einer Filterfunktion verknüpft und die statistischen Eigenschaften der Sequenz genutzt, um die Daten zu modellieren. Beispielsweise nutzt das AutoRegressive-Moving Average-Modell (ARMA) ein lineares Modell zur Berechnung zeitdiskreter stochastischer Prozesse. Ihr mathematischer Kern ist ein lineares Gleichungssystem. Man kann solche Modelle auch als Differenzengleichungen bzw. Differenzengleichungssysteme ansehen.

In Anbetracht der verschiedenen Beispiele zur Ermittlung des Jitters erscheint es sinnvoll, den Jitter als die Summe einer Reihe von unabhängigen und zufälligen Prozessen anzusehen, bei der die Reihe von Impulsen mit einer Moving Average-Filter-Funktion verknüpft ist. Dieses Impuls Driven Moving Average (IDMA) Modell ist in der Lage, die über die Zeit verteilten unterschiedlichen Arten des Jitters zu modellieren. Daher wird dieses Modell auch bei der Simulationsmodellierung des Jitters in IP-Netzwerken angewendet.

Die Jitter-Metrik für diesen Ansatz umfasst eine Beschreibung der Impuls-Verteilung, die sich aus der Zeitreihe der statistischen Daten ergibt und sich als funktional äquivalent zu den gemessenen Daten erweist.

Emulation des Jitter-Puffers

In den vorherigen Abschnitten dieses Papiers haben wurde dargestellt, welche Jitter es gibt und wie diese berechnet werden. Da ein Jitter unumgänglich ist, da es zu den negativen Eigenschaften des IP-Netzwerkes gehören, müssen Lösungen zur Milderung gefunden werden. Durch den Einsatz eines so genannten Jitterpuffers werden Daten gepuffert um einen den Jitter auszugleichen. Bei diesem Lösungsansatz wird direkt bestimmt, wie viele Pakete als Folge des Jitters verworfen werden. Dies hat den Vorteil, dass man direkt die zeitliche Verteilung der Datenverluste beobachten kann. Dabei wird vermieden, die jeweilige Jitter-Metrik mit der Datenverlustrate zu korrelieren.

Jitter-Puffer

Ein Jitter-Puffer hat die Aufgabe die im dekodierten Sprach/Videostrom Auswirkungen des Jitters zu beseitigen. Dabei wird jedes empfangene Paket kurzzeitig zwischengepuffert, bevor es an den Empfänger (Applikation) weitergeleitet wird. Im Jitter-Puffer werden die zu spät empfangenen Pakete direkt verworfen. Durch die Kontrollfunktion treten im Jitter-Puffer zusätzliche Verzögerung auf. Jitter-Puffer haben entweder eine feste Größe oder die Größe des Puffers wird dynamisch festgelegt. Letztere Varianten werden auch als adaptive Jitter-Puffer bezeichnet. Diese haben die Fähigkeit ihre Größe dynamisch zu optimieren, um sich optimal an die jeweiligen Verzögerungen/ Datenverluste anzupassen.

Adaptive Jitter-Puffer sind in der Lage, sich automatisch an Verzögerungsänderungen anzupassen. Erfolgt beispielsweise eine schrittweise Veränderung der Verzögerung um 20 Millisekunden, hat dies kurzfristig einige Paketverluste zur Folge. Über diesen Zeitraum justiert sich der Jitter-Puffer jedoch neu und vermeidet somit weitere Datenverluste. Der Jitter-Puffer kann somit wie ein Zeitfenster angesehen werden. Auf der einen Seite des Fensters (der frühen Seite) werden die aktuellen Daten erfasst und auf die andere Seite des Fensters (der späten Seite) repräsentiert die maximal zulässige Verzögerung (nach der ein Paket zu verwerfen ist).

Beziehung zwischen verworfenen Paketen und Jitter-Messungen

Die Abbildung 5 zeigt ein Beispiel für die Beziehung zwischen verworfenen Paketen und unterschiedlichen Jitter-Metriken. Man erkennt, dass der Anstieg des RTCP-Jitter einen ungefähren Hinweis auf den voraussichtlichen Verwurf einzelner verzögerter Pakete gibt.

Adaptive Jitter-Puffer

Adaptive Jitter-Puffer reagieren der Regel entweder auf Ereignisse oder die Erhöhung des gemessenen Jitters. Wird ein zu spät empfangenes Paket festgestellt (und dies daher verworfen) wird automatisch der Jitter-Puffer vergrößert. Wird kein zu spät empfangenes Paket festgestellt, wird der Jitter-Puffer reduziert.

Treten in einem LAN häufiger Staus auf oder ändern sich die Routen häufig, dann liegen die Jitter-Ereignisse weit auseinander. Die durch adaptive Jitter-Puffer hervorgerufene Vergrößerung des Jitter-Puffers kann sich kontraproduktiv auf die Kommunikation auswirken. Die Verzögerungen werden durch das erste Ereignis adaptiv vergrößert. Aber es dauert zu lange bis das nächste Ereignis eintritt und der Jitter-Puffer automatisch wieder verringert wurde. Ein adaptiver Jitter-Puffer reagiert hervorragend, wenn Jitter in größeren Mengen (beispielsweise bei Staus auf WAN-Links) auftritt.

Da heute adaptive Jitter-Puffer hauptsächlich genutzt werden und deren Betrieb recht empfindlich auf die Jitter-Verteilung reagiert, ist es wichtig, dass die Jitter Messungen die zeitliche Verteilung einkalkulieren. Durch eine zusätzliche Emulation des Jitter-Puffers kann eine pragmatische Lösung erreicht werden, die dafür sorgt, dass sich daraus die Jitter-basierten Datenverluste abschätzen lassen.

Ansätze zur korrekten Jitter-Modellierung und zur Jitter-Messung

Wie oben dargestellt, müssen zur Jitter-Modellierung und zur korrekten Jitter-Messung die zeitlichen Charakteristiken und die Auswirkungen auf die Berechnung der Jitter-Puffer einbezogen werden. Hierfür stehen mehrere Techniken zur Verfügung:

· Modellierung: Zur Ermittlung plausibler Daten im Zusammenhang mit einer IP-Netzwerk-Emulation oder Simulation zu ermitteln, sollte ein Impuls getriebenes Zeitreihen-Modell verwendet werden.

· Jitter-Messungen: Um den Jitter unabhängig von den spezifischen Anwendung messen zu können, empfiehlt es sich, die mittlere Abweichung von den kurzfristigen durchschnittliche Verzögerung als Messgröße zur Generierung eines Histogramms heranzuziehen, um Abweichungen des Jitters feststellen zu können.

· Auswirkungen des Jitters: Zur Beurteilung der Auswirkungen des Jitters auf VoIP-Dienste ist es empfehlenswert, dass ein Jitter-Puffer-Emulator genutzt wird und somit direkt die Anzahl der verworfenen Pakete ermitteln zu können.

Fazit

Der Jitter ist ein unumgänglicher Fehler in einem Netzwerk. Dieser Fehler kann kaum verhindert werden, daher ist es notwendig diesen zu untersuchen. Jitter kann unterschiedliche Fehler verursachen. Bei Datenanwendungen sind diese Fehler vernachlässigbar. Bei VoIP können diese Fehler zu unangenehmen Störungen führen. Die Messsoftware von Nextragen [1] ist darauf spezialisiert die Eigenschaften des Dienstes VoIP zu prüfen. Die Software TraceView 3Q ist zur passiven Analyse von VoIP-Strömen. Der Jitter kann hier von jedem Strom einzeln begutachtet werden. Die Fehler (Paketverluste) die durch den vorgekommenen Jitter verursacht werden können, werden berechnet. Die Software TraceSim VoIP simuliert VoIP-Verbindungen. Hier können Sprachqualitätsmessungen durchgeführt werden. Die Folgen des Jitters werden berücksichtigt und dargestellt.

Benjamin Kolbe, CTO Nextragen

Mathias Hein, freier Journalist