DE10322885A1

DE10322885A1 - Verfahren zum Organisieren von Datenpaketen

Info

Publication number: DE10322885A1
Application number: DE10322885A
Authority: DE
Inventors: Ying Thomas Man Yin
Original assignee: Zarlink Semiconductor Ltd
Current assignee: Microsemi Semiconductor Ltd
Priority date: 2002-05-24
Filing date: 2003-05-21
Publication date: 2003-12-24
Also published as: GB0212037D0; FR2840141B1; US20040085963A1; GB2392062A; FR2840141A1

Abstract

Die Erfindung betrifft einen Datenpuffer 11, der ausgeführt ist, um von einer Datenverbindung 7 empfangene Datenpakete zu organisieren. Jedes Datenpaket ist mit einer indizierten Nummer versehen, die die Reihenfolge, in der die Datenpakete vom Datenpuffer 11 ausgegeben werden sollen, anzeigen. Erfindungsgemäß umfasst der Datenpuffer 11 eine Mehrzahl von Speicherbereichen, wobei jeder Speicherbereich in der Lage ist, ein einzelnes Datenpaket auf einmal zu speichern und wobei der Datenpuffer 11 ausgeführt ist, jedes empfangene Datenpaket in einem vorbestimmten aus der Mehrzahl von Speicherbereichen in Abhängigkeit von der indizierten Nummer des betreffenden Datenpakets zu speichern. Der Datenpuffer 11 kann in Verbindung mit einem Datenübertrager 1 und einem Datenprozessor 5, der Datenpakete in Echtzeit verarbeitet, benutzt werden.

Description

Die Erfindung betrifft ein Verfahren zum Organisieren von Datenpaketen nach dem Oberbegriff des Patentanspruchs 1 sowie einen zugehörigen Datenpuffer.
In einem Datenkommunikationssystem, in dem Datenpakete über eine Datenverbindung gesendet werden, beispielsweise über eine Netzwerkverbindung, ist es möglich, dass Datenpakete außerhalb der Reihenfolge und/oder mit einer Zeitinkonsistenz zwischen aufeinanderfolgend empfangenen Paketen beispielsweise mit einem Signalzittern (Jitter) empfangen werden. Diese Diskrepanz kann zu Problemen auf einer Empfängerseite des Systems führen, da die empfangenen Daten keine richtige Wiedergabe der gesendeten Daten sind. Entsprechend ist es deshalb häufig notwendig, die empfangenen Datenpakete neu zu sortieren, so dass sie in einer korrekten Reihenfolge und/oder mit kleineren Zeitproblemen an eine nachfolgende Verarbeitungsstufe übergeben werden können. Diese Sortierung wird üblicherweise in einer Speicherbaugruppe durchgeführt, die manchmal auch als Jitterpuffer bezeichnet wird.

Das Echtzeitübertragungsprotokoll (RTP) ist ein Beispiel für ein Datenprotokoll, das eine Echtzeitübertragung von Datenpaketen über ein Paketnetzwerk ermöglicht, die RTP-Pakete werden in einer Reihenfolge über das Netzwerk gesendet. Da das RTP häufig in populären Paketnetzwerkprotokollen, wie dem Internetprotokoll (IP) verwendet wird, treten die oben beschriebenen Probleme der falschen Reihenfolge und des Signalzitterns häufig auf. Bei Anwendungen in denen eine Echtzeitverarbeitung benötigt wird, beispielsweise bei einem IP-Telefon, in dem die Datenpakete Echtzeitsprachdaten repräsentieren, können solche Probleme hoch problematisch werden. Deshalb wird, um die RTP-Pakete über eine IP-Verbindung zu empfangen und zum Verarbeiten der RTP- Pakete in Echtzeit, ein Jitterpuffer benötigt, der die RTP-Pakete in der richtigen Reihenfolge sortiert und ihre unvorhersehbaren Ankunftsintervalle ausgleicht.

Ein System mit einem bekannten Jitterpuffer ist in Fig. 1 dargestellt. Das System umfasst einen Datenübertrager 1 zum Übertragen von Datenpaketen, beispielsweise RTP-Pakete, einen Jitterpuffer 3 und einen Echtzeitdatenprozessor 5, der die RTP-Pakete verarbeitet. Der Datenübertrager 1 überträgt die RTP-Pakete zum Jitterpuffer 3 über eine IP- Verbindung 7. Einige RTP-Pakete werden vom Jitterpuffer 3 zu unvorhersehbaren Intervallen und außerhalb der richtigen Reihenfolge empfangen. Der Jitterpuffer 3 speichert die RTP-Pakete und sortiert sie in die richtige Reihenfolge durch ein verbundenes Listenverfahren, das unten beschrieben wird. Der Echtzeitdatenprozessor 5 sendet in regelmäßigen Zeitabständen eine Datenanforderungsnachricht über den Bus 9 an den Jitterpuffer 3. Als Reaktion sendet der Jitterpuffer 3 für jede empfangene Datenanforderungsnachricht ein RTP-Paket an den Echtzeitdatenprozessor 5. Als Konsequenz empfängt der Echtzeitdatenprozessor 5 einen gleichmäßigen Strom von RTP-Paketen in der richtigen Reihenfolge.

Das verbundene Listenverfahren nachdem der herkömmliche Jitterpuffer 3 arbeitet wird nun ausführlich unter Bezugnahme auf Fig. 2 beschrieben. Wie aus Fig. 2a ersichtlich ist, wird eine empfangene Paketsequenz durch die Zahlen "0", "1 ", "2", "4" und "3" repräsentiert. Diese Zahlen sind aktuell vorgesehen, um die indizierten Nummern, die jedem Paket zugeordnet sind zu repräsentieren, wobei die indizierten Nummern die Reihenfolge der Pakete anzeigen, in der die Pakete aktuell über die IP- Verbindung 7 gesendet wurden. In anderen Worten ausgedrückt, wurde das Paket "0" zuerst und das Paket "4" als letztes gesendet. Jedoch wurde, wie noch gezeigt wird, im dargestellten Fall das Paket "4" vor dem Paket "3" empfangen und deshalb hat irgendwo auf der IP- Verbindung 7 eine Vertauschung der Reihenfolge stattgefunden. Wird das Paket "0" empfangen, dann wird es, wie in Fig. 2b dargestellt ist, in einem Speicherbereich gespeichert. Als nächstes wird das Paket "1" empfangen und, wie in Fig. 2c dargestellt ist, in einem neuen Speicherbereich gespeichert, der mit dem vorherigen verwendeten Speicherbereich verbunden ist. Der gleich Vorgang wird ausgeführt, wenn die Pakete "2" und "4" empfangen werden, was in den Fig. 2d und 2e dargestellt ist. Wird das Paket "3", dann erkennt der Jitterpuffer 3, das die indizierte Nummer "3" kleiner ist, als die mit dem vorher gespeicherten Paket assoziierte indizierte Nummer "4". Daraus resultiert, dass der neu gebildete Speicherbereich, der das Paket mit der indizierten Nummer "3" speichert zwischen die Speicherbereiche, die die Pakete mit den indizierten Nummern "2" und "4" speichern eingeschleift wird. Es wird also die Verbindung zwischen den Speicherbereichen, die die Pakete mit den indizierten Nummern "2" und "4" speichern aufgebrochen. Dies ist in Fig. 2f dargestellt.

Es wird deutlich, dass jedes Mal, wenn ein neues Datenpaket vom Jitterpuffer 3 empfangen wird, der Jitterpuffer 3 die Verbindungsliste dahingehend durchsuchen muss, ob das neue Datenpaket zwischen zwei vorher verbundene Speicherbereiche eingefügt werden muss und wenn dem so ist, wo das Datenpaket eingefügt werden muss. Die Tiefe des Jitterpuffers ist also variabel, weil die Anzahl von Speicherbereichen vergrößert wird, wenn mehr Datenpakete empfangen werden. Deshalb ist die Prozessbelastung groß. Grundsätzlich ist das Verfahren schwerfällig und sicherlich unerwünscht für Echtzeitanwendungen.

Deshalb ist es Aufgabe der Erfindung, ein Verfahren zum Organisieren von Datenpaketen zur Verfügung zu stellen, das die beschriebenen Probleme vermeidet und einen zugehörigen Datenpuffer anzugeben.

Die Erfindung löst diese Aufgabe durch Bereitstellen eines Verfahrens zum Organisieren von Datenpaketen mit den Merkmalen des Patentanspruchs 1 sowie eines Rechnerprogramms mit den Merkmalen des Patentanspruchs 11 und eines Datenpuffers mit den Merkmalen des Anspruchs 12.

Entsprechend einem ersten Aspekt der Erfindung wird ein Verfahren zum Organisieren von Datenpaketen angegeben, die über eine Datenverbindung empfangen werden, wobei jedes Datenpaket mit einer Nummer indiziert ist, welche die Reihenfolge anzeigt, in der das Datenpaket ausgegeben wird. Das Verfahren stellt einen Puffer mit einer Mehrzahl von Speicherbereichen zur Verfügung, wobei jeder Speicherbereich in der Lage ist, ein einzelnes Datenpaket auf einmal zu speichern und wobei jedes empfangene Datenpaket in einem vorbestimmten der Mehrzahl von Speicherbereichen in Abhängigkeit von der indizierten Nummer des betreffenden Datenpakets gespeichert wird.

Da der Speicherbereich, in dem das jeweilige Datenpaket gespeichert wird von dem zugehörigen Index des jeweiligen Datenpakets abhängig ist, und weil der Index die Reihenfolge angibt, in der jedes der Datenpakete ausgegeben werden soll, folgt daraus, dass die Datenpakete in Speicherbereichen gespeichert werden können, welche die Reihenfolge reflektieren, in der die Datenpakete ausgegeben werden sollen. Anders als beim verbundenen Listenverfahren, wird ein neu empfangenes Datenpaket nicht automatisch mit einem bereits empfangenen Datenpaket verbunden. Zudem muss die Liste von allen bereits empfangenen Datenpaketen nicht analysiert werden, um zu bestimmen, ob das neu empfangene Datenpaket außerhalb der Reihenfolge ist. Dadurch wird die rechnerische Belastung reduziert.

Bei dem Verfahren liest ein Datenlesemittel periodisch die Datenpakete aus den jeweiligen Speicherbereichen, in denen sie gespeichert sind, in der Reihenfolge aus, in der die Datenpakete ausgegeben werden. Ein solcher periodischer Auslesevorgang ermöglicht eine Übertragung der gespeicherten Datenpakete an eine nachfolgende Datenverarbeitungsstufe, in der Reihenfolge, in der sie ausgegeben werden sollen. Die nachfolgende Datenverarbeitungsstufe kann ein Echtzeitdatenverarbeitungsgerät, wie ein IP-Telefon sein. Der periodische Lesevorgang entfernt Zeitinkonsistenzen, wie Signalzittern, die von einer Datenverbindung in die übertragene Datenpaketsequenz eingefügt werden können.

Vorzugsweise werden N Speicherbereiche zur Verfügung gestellt und die indizierten Nummern umfassen M Nummern, wobei N und M ganzzahlige Werte sind und wobei M größer oder gleich N ist und N größer als 1 ist. Deshalb kann der Puffer eine feste Größe ,N' haben. Die Datenpakete können in Abhängigkeit vom Ergebnis von M (Modulo N) in den Speicherbereichen gespeichert werden, wobei M die indizierte Nummer ist, die dem betroffenen Datenpaket zugeordnet ist. In diesem Zusammenhang wird angemerkt, dass das Ergebnis der Berechnung der Rest einer Division von M durch N ist. Deshalb ist, wenn M = 6 ist und N = 4, das Ergebnis von 6 (Modulo 4) gleich 2, weil 6 geteilt durch 4 gleich 1 Rest 2 ist.

Die indizierten Nummern können sich nach M über die Datenverbindung 7 gesendeten Datenpaketen wiederholen. In diesem Fall wird jedes empfangene Datenpaket überwacht, um zu bestimmen, ob seine zugehörige indizierte Nummer eine Wiederholung einer bereits empfangenen indizierten Nummer ist, wobei die indizierten Nummern von bereits im Puffer gespeicherten Datenpaketen in Abhängigkeit von einer solchen Bestimmung verändert werden, in dem ein ganzzahliges Vielfaches von N zu diesen indizierten Nummern addiert wird. Der Bestimmungsschritt, ob die empfangene indizierten Nummer eine Wiederholung einer bereits empfangenen indizierten Nummer ist, kann durch eine Erkennung, ob die indizierte Nummer des empfangenen Datenpakets kleiner ist als die indizierte Nummer eines direkt vorher empfangenen Datenpakets ausgeführt werden.

Eine Differenz zwischen den indizierten Nummer von zwei nacheinander empfangenen Datenpaketen kann überwacht werden, um zu bestimmen ob Datenpakete, die zwischen den beiden nacheinander empfangenen Datenpaketen ausgegeben werden sollen, noch nicht empfangen wurden, wobei der Bestimmungsschritt, ob eine empfangene indizierte Nummer eine Wiederholung von bereits gesendeten indizierten Nummern ist nur durchgeführt wird, wenn eine Anzahl von Datenpaketen, die noch nicht empfangen wurden eine vorbestimmte Nummer übersteigt. In diesem Fall wird, wenn (a) erkannt wird, dass die Anzahl von nicht empfangenen Datenpaketen die vorbestimmte Nummer übersteigt und (b) die empfangenen indizierten Nummern keine Wiederholung einer bereits gesendeten indizierten Nummer ist, der Puffer zurückgesetzt.

Jedes nachfolgende Datenpaket, das einem belegten Speicherbereich zugewiesen wird kann das in diesem Speicherbereich bereits gespeicherte Datenpaket überschreiben.

Das oben beschriebene Verfahren kann für jedes Datenpaketübertragungsprotokoll verwendet werden, bei dem Paket mit zugeordneten indizierten Nummern benutzt werden, welche die Reihenfolge anzeigen, in der die Pakete ausgegeben werden sollen. Vorzugsweise zeigen die indizierten Nummern auch die Reihenfolge an, in der die Datenpakete in die Datenverbindung eingegeben werden.

Beispielsweise haben RTP-Datenpakete eine zugeordnete Indexnummer, die im Protokollstandard auch als "Sequenznummer" bezeichnet wird. Da jedes RTP-Datenpaket über eine Datenverbindung übertragen wird, sind die zugehörigen Sequenznummern der nacheinander übertragenen Pakete erhöht. Entsprechend hat, wenn das erste Datenpaket die Sequenznummer 0 hat, das zweite Datenpaket die Sequenznummer 1 und so weiter, bis zu einer Sequenznummer 65535, nach der die Sequenznummer 0 wiederholt wird.

Entsprechend einem zweiten Aspekt der Erfindung wird ein Rechnerprogramm zur Verfügung gestellt, das auf einem rechnerlesbaren Datenträger gespeichert ist. Das Rechnerprogramm umfasst rechnerlesbare Befehle, die von einem Ausführungsmittel eines Rechners zur Durchführung von einem Verfahren zur Organisation von Datenpaketen, die von einem Rechner über eine Datenverbindung empfangen werden, wobei jedes Datenpaket mit einer Nummer indiziert ist, welche die Reihenfolge anzeigt, in der das Datenpaket aus ausgegeben werden soll. Das Verfahren stellt eine Mehrzahl von Speicherbereichen zur Verfügung, wobei jeder Speicherbereich in der Lage ist, ein einzelnes Datenpaket auf einmal zu speichern und wobei jedes empfangene Datenpaket in einem vorbestimmten der Mehrzahl von Speicherbereichen in Abhängigkeit von der indizierten Nummer des betreffenden Datenpakets gespeichert wird.

Entsprechend einem dritten Aspekt der Erfindung wird ein Datenpuffer zum Organisieren von Datenpaketen zur Verfügung gestellt, die über eine Datenverbindung empfangen werden, wobei jedes Datenpaket mit einer Nummer indiziert ist, welche die Reihenfolge anzeigt, in der das Datenpaket aus dem Datenpuffer ausgegeben werden soll. Der Datenpuffer umfasst eine Mehrzahl von Speicherbereichen, wobei jeder Speicherbereich in der Lage ist, ein einzelnes Datenpaket auf einmal zu speichern und wobei der Datenpuffer ausgeführt ist, jedes empfangene Datenpaket in einem vorbestimmten der Mehrzahl von Speicherbereichen in Abhängigkeit von der indizierten Nummer des betreffenden Datenpakets zu speichern.

Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen angegeben.

Nachfolgend wird die Erfindung anhand von in den Zeichnungen dargestellten Ausführungsbeispielen beschrieben. Es zeigen:

Fig. 1 ein Blockschaltbild eines Systems mit einem herkömmlichen Jitterpuffer;

Fig. 2 eine schematische Darstellung eines bekannten verbundenen Listenverfahrens bei einem Jitterpuffer;

Fig. 3 ein Blockschaltbild eines Systems mit einem erfindungsgemäßen Jitterpuffers;

Fig. 4 ein detailliertes Blockschaltbild des Jitterpuffers aus Fig. 3;

Fig. 5(a) bis (f) eine schematische Darstellung von Teilen eines Ablaufs im Jitterpuffer;

Fig. 6 ein Zustandsübergangsdiagramm des vom Jitterpuffer aus Fig. 3 und 4 ausgeführten Ablaufs;

Fig. 7 ein Flussdiagramm für Schritte in einem ersten in Fig. 6 dargestellten Zustand;

Fig. 8 ein Flussdiagramm für Schritte in einem zweiten in Fig. 6 dargestellten Zustand; und

Fig. 9 ein Flussdiagramm für Schritte in einem dritten in Fig. 6 dargestellten Zustand.

Fig. 3 zeigt ein Blockschaltbild eines Systems mit einem erfindungsgemäßen Jitterpuffer 11. Das System umfasst den Datenübertrager 1 und den Echtzeitdatenprozessor 5 aus Fig. 1. Der Datenübertrager 1 ist ausgeführt, um die RTP-Datenpakete über die IP-Verbindung 7 zum Jitterpuffer 11 zu übertragen. Der Echtzeitdatenprozessor 5 ist ausgeführt, um durch Senden einer Datenanforderungsnachricht über den Datenbus 9 periodisch RTP-Datenpakete vom Jitterpuffer 11 anzufordern. In Abhängigkeit von jeder empfangenen Datenanforderungsnachricht ist der Jitterpuffer 11 ausgeführt, um ein RTP-Paket über den Bus 9 an den Echtzeitdatenprozessor 5 zu übertragen. Nachfolgend wird das Verfahren mit dem dies erreicht werden soll im Detail beschrieben.
Wie aus Fig. 4, die ein detailliertes Blockschaltbild des Jitterpuffers 11 zeigt; ersichtlich ist, umfasst der Jitterpuffer 11 einen Prozessor 13, der (i) mit einem Speicherfeld 15 und (ii) mit einem Speicher mit direktem Zugriff (RAM) 17 verbunden ist. Der Prozessor 13 ist mit der IP- Verbindung 7 über eine Dateneingabeleitung 19 verbunden und ist durch eine Paketausgabeleitung 21 und eine Nachrichtenanforderungsleitung 23 mit dem Datenbus 9 verbunden. Der Echtzeitdatenprozessor sendet periodisch eine Datenanforderungsnachricht über die Nachrichtenanforderungsleitung 23 und in Abhängigkeit davon ist der Prozessor 13 ausgeführt, um Datenpakete über die Paketausgabeleitung 21auszugeben. Das Speicherfeld 15 ist als eine Anzahl von getrennten Speicherbereichen ausgeführt. In Fig. 4 sind acht Speicherbereiche dargestellt, die mit [0] bis [7] bezeichnet sind.
Im Betrieb sendet der Datenübertrager 1 einen Strom von RTP- Datenpaketen, die nachfolgend vom Echtzeitdatenprozessor 5 verarbeitet werden. Beispielsweise entsprechen der Datenübertrager 1 bzw. der Echtzeitdatenprozessor 5 jeweils einem Übertragungsteil bzw. einem Empfängerteil einer IP-Telefonstrecke. Weil jedoch die IP-Verbindung 7 Diskrepanzen, wie Vertauschen der Reihenfolge oder ein Signalzittern, in den Paketstrom einführen kann, wird der Jitterpuffer 11 benutzt, um die empfangenen Datenpakete in einer verbesserten Reihenfolge zu organisieren, so dass die geordneten Datenpakete mit einer benötigten regelmäßigen Rate an den Echtzeitdatenprozessor 5 übertragen werden können.
Jedes vom Datenübertrager 1 gesendete RTP-Datenpaket hat eine zugeordnete indizierte Nummer, die nachfolgend als ,Sequenznummer' bezeichnet wird. Die jedem Datenpaket zugeordnete Sequenznummer zeigt die Reihenfolge an, in der das entsprechende Datenpaket über die IP-Verbindung 7 gesendet wird. Deshalb hat das erste Datenpaket die Sequenznummer "0", das nächste gesendete Datenpaket hat die Sequenznummer "1" und so weiter. Entsprechend dem RTP-Standard ist die höchste benutzbare Sequenznummer "65535". Das nächste nach der höchsten Sequenznummer gesendete Datenpaket hat wieder die Sequenznummer "0" und so wiederholen sich die Sequenznummern bei nacheinander übertragenen Datenpaketen. Durch die vorgegebenen Sequenznummern, die die Reihenfolge der über die IP-Verbindung 7 gesendeten Datenpakete anzeigen, ist der Jitterpuffer 11 ausgeführt, um die Information der Sequenznummern zur Organisation der empfangenen Datenpakete zu benutzen und die Datenpakete in einer korrekten oder wenigstens in einer verbesserten Reihenfolge für eine nachfolgende periodische Übertragung an den Echtzeitdatenprozessor 5 anzuordnen. Speziell wird ein Rechnerprogramm durch den Prozessor 3 des Jitterpuffers 11 betrieben, das einem Ablauf folgt, der nachfolgend beschrieben wird.
Es versteht sich von selbst, dass in Echtzeitanwendungen die Reihenfolge, in der die Datenpakete über die IP-Verbindung 7 gesendet werden, die benötigte Reihenfolge ist, in der die Datenpakete an den Echtzeitdatenprozessor 5 ausgegeben werden.
Das Hauptprinzip mit dem der Jitterpuffer 11 die empfangenen RTP- Datenpakete organisiert, basiert auf einer Berechnung, mit der die Datenpakete in einem bestimmten der acht Speicherbereiche des Speicherfeldes 15 entsprechend eines Ergebnisses von M (Modulo N), wobei M die Sequenznummer ist, die jedem einzelnen RTP-Datenpaket zugeordnet ist und N ist die Anzahl der Speicherbereiche im Speicherfeld 15. Das Ergebnis dieser Berechnung ist der Rest aus M geteilt durch N.
Um das Prinzip zu demonstrieren, zeigt Fig. 5a das Speicherfeld 15 des Jitterpuffers 11 aus Fig. 4. Das Speicherfeld 15 hat acht Speicherbereiche und deshalb ist N gleich "8". Fig. 5b zeigt Sequenznummern für eine empfangene RTP-Paketsequenz. Es wird darauf hingewiesen, dass die Sequenznummern "4" und "5" in einer falschen Reihenfolge empfangen wurden.
Wird das erste RTP-Paket empfangen, dann ist das Ergebnis aus 0(Modulo 8 gleich "0" und deshalb wird dieses RTP-Paket im Speicherbereich [0] gespeichert. Werden die nächsten drei Datenpakete empfangen, dann sind die Ergebnisse von 1 (Modulo 8), 2(Modulo 8) bzw. 3(Modulo 8) jeweils "1", "2" bzw. "3". Entsprechend werden diese drei Datenpakete in den Speicherbereichen [1], [2] bzw. [3] gespeichert. Wird das nächste Datenpaket empfangen, dann ist, weil die Sequenznummer "5" ist, das Ergebnis von 5(Modulo 8) gleich 5 und deshalb wird dieses Datenpaket im Speicherbereich [5] gespeichert. Der Speicherbereich [4] wird nicht benutzt. Diese Situation ist in Fig. 5c dargestellt. Wird das nächste RTP-Paket empfangen, d. h. das Datenpaket mit der Sequenznummer "4", dann wird dieses Paket offensichtlich im Speicherbereich [4] gespeichert, weil das Ergebnis von 4(Modulo 8) gleich 4 ist. Deshalb wird keine Umsortierung benötigt, um dieses Datenpaket im richtigen Speicherbereich im Speicherfeld 15 abzulegen.
Der oben beschriebene Ablauf wird für die verbliebenen Pakete der RTP-Paketsequenz weitergeführt. Zum Zeitpunkt, an dem ein RTP- Paket mit der Sequenznummer "8" empfangen wird, ist das Ergebnis von 8(Modulo 8) wieder "0", weil 8 geteilt durch 8 keinen Rest hat, und so wird dieses Datenpaket wieder im Speicherbereich [0] gespeichert, d. h. durch Überschreiben des bereits in diesem Speicherbereich gespeicherten Datenpakets. Diese Situation ist in Fig. 5d dargestellt. Der Ablauf ist jedoch so aufgebaut, dass sichergestellt ist, dass die Datenpakete an den Echtzeitdatenprozessor 5 übertragen oder abgelegt wurden, bevor ein Überschreibvorgang auftritt.
Durch Benutzung der oben beschriebenen M(Modulo N) Berechnung folgt, dass anstelle von einer kontinuierlich ansteigenden Zahl von Speicherbereichen, eine feste Anzahl von Speicherbereichen benutzt werden kann. Dies kann als "Regalfachtechnik" bezeichnet werden. Die gewählte Anzahl von Speicherbereichen für das Speicherfeld 15, die auch als Puffertiefe bezeichnet wird, ist vom Typ der Dienstanforderungen abhängig. Im wirklichen Einsatz kann der Puffer 11 für eine praktikablen IP-Verbindung 500 Speicherbereiche benötigen. Bildet eine nahezu perfekte Internetverbindung die Verbindung, dann kann der Puffer 11 nur 100 Speicherbereiche benötigen.
Eine interessante Situation tritt auf, wenn ein Datenpaket mit der höchst möglichen Sequenznummer erreicht wird, d. h. "65535" im Fall von RTP- Paketen. Das kommt davon, weil das nächste Datenpaket zwangsweise eine niedrigere Sequenznummer hat, d. h. "0", wenn das nächste Datenpaket nicht in einer falschen Reihenfolge empfangen wird. Diese Situation wird als "Umkehrpunkt" bezeichnet. Fig. 5e und das in Fig. 5f dargestellte Speicherfeld 15 werden benutzt, um das Prinzip zu demonstrieren. Für eine einfachere Erklärung wird angenommen, dass sich die Sequenznummern nach einer Übertragung der Nummer "4" vom Datenübertrager 1 wiederholen. Das bedeutet, dass nach dem Senden des Datenpakets mit der Nummer "4", das nächste Datenpaket die Sequenznummer "0" hat, was in Fig. 5e mit einem Pfeil angezeigt wird. Tritt dies auf, dann ist der Umkehrpunkt erreicht. Diese Situation wird vom Jitterpuffer 11 erkannt, wie nachfolgend beschrieben wird, anderenfalls wird das nächste RTP-Datenpaket im Speicherbereich [0] und nicht im Speicherbereich [5] gespeichert. Dies kann problematisch sein, wenn der Echtzeitdatenprozessor 5 noch keine gültigen im Speicherbereich [0] gespeicherte Daten empfangen hat. Mit dem Erkennen eines Umkehrpunktes wird ein ganzzahliges Vielfaches von N, d. h. im dargestellten Beispiel von 8, zu der Sequenznummer addiert, bevor der Ablauf weitergeht. Dies hat den Effekt, dass die Sequenznummer nach oben verschoben werden, so dass nachfolgend empfangene Nummern nicht länger eine niedrigere Sequenznummer haben.
Eine weitere Situation mit der der Jitterpuffer umgehen muss, ist ein sogenannter Zustand der "Out-of-Range-Unterbrechung". Dieser Zustand tritt auf, wenn eine vorbestimmte Anzahl von aufeinanderfolgenden RTP-Datenpaketen nicht in ihrer erwarteten Position in der empfangenen Datensequenz ankommen. Dies kann dadurch vorkommen, wenn eine große Anzahl von aufeinanderfolgenden Datenpaketen verloren gegangen sind. Durch Beobachten der ankommenden Sequenznummern und durch Detektieren, wenn eine Differenz zwischen aufeinanderfolgend empfangenen Datenpaketen größer ist als ein vorbestimmter Schwellwert, kann der Jitterpuffer 11 eine solche "Out-of-Range- Unterbrechung" erkennen und diese fehlenden Pakete als verloren ablegen.
Die Überprüfung des oben beschriebenen Umkehrpunkts und der Outof-Range-Unterbrechung wird vorzugsweise vor dem Organisationsschritt M(Modulo N) durchgeführt. Deshalb werden die vom Jitterpuffer 11 empfangenen RTP-Datenpakete temporär im RAM 17 gespeichert, so dass die oben beschriebenen Überprüfungen durchgeführt werden können. Danach werden die Datenpakete organisiert in ihren zugehörigen Speicherbereichen im Speicherfeld 15 abgelegt.
Nach der zusammenfassenden Beschreibung der Hauptfunktionen und der vom Jitterpuffer 11 durchgeführten Überprüfungen wird nun der Ablauf im Jitterpuffer im Detail beschrieben. Wie oben ausgeführt, ist der Ablauf als Rechnerprogramm realisiert, das vom Prozessor 13 ausgeführt wird, kann aber auch als Firmware implementiert werden.
Der Ablauf benutzt die nachfolgend angegebenen Konstanten und Variablen, um die empfangenen RTP-Datenpakete zu verarbeiten. Eine kurze Erläuterung jeder Konstanten bzw. Variablen wird ebenfalls gegeben, so dass ihre jeweilige bestimmte Funktion durch die nachfolgende Beschreibung deutlich wird.
A. Konstanten:

- MAX_RTP_SEQ: Maximale Sequenznummer für RTP, d. h. 65535.
- BUF_DEPTH: Tiefe des Jitterpuffers 11, abhängig vom Typ der Dienstanforderung.
- NO_PACKET: Konstante, die anzeigt, dass ein Paket noch nicht empfangen wurde.
- PACKET_UNREAD: Konstante, die benutzt wird, um anzuzeigen, dass ein Paket empfangen wurde, aber noch nicht an den Echtzeitdatenprozessor 5 übertragen wurde.
- PACKET_READ: Konstante, die benutzt wird, dass ein Paket zum Echtzeitdatenprozessor 5 übertragen wurde.

B. Variablen:

- RecvSeq: Sequenznummer eines neu empfangenen RTP-Pakets.
- MostRecentSeq: Sequenznummer des höchsten der bereits im Speicherfeld 15 des Jitterpuffers 11 gespeicherten RTP-Pakete.
- LeastRecentSeq: Sequenznummer des niedrigsten bereits im Speicherfeld 15 des Jitterpuffers 11 gespeicherten RTP-Pakete.
- SendSeq: Sequenznummer des nächsten RTP-Pakets, das zur Verarbeitung an den Echtzeitdatenprozessor 5 gesendet werden soll.
- PacketStore[BUF_DEPTH]: feste Größe des Jitterpufferspeichers.
- PacketStatus[BUF_DEPTH]: Zustand des Jitterpufferspeichers.
- PacketIndex: Nummer des Speicherbereichs, der benutzt wird um das empfangene RTP-Paket zu speichern.
- JitterThreshold: Schwellwert zum Steuern des Datenflusses.
- JitterHysteresis: Hysterese des Schwellwerts.
- JitterMax: Maximaler Wert des Jitterschwellwertes.
- JitterMin: Minimaler Wert des Jitterschwellwertes.
- JitterAdjTime: Einstellperiode des Jitterschwellwertes.
- LateSeq: Anzahl von Paketen, die zu spät angekommen sind, um an den Echtzeitdatenprozessor 5 übertragen zu werden.
- LateSeqLimit: Grenzwert für die Anzahl von zu spät empfangenen Paketen, bevor der Jitterschwellwert neu eingestellt wird.
- MaxDropOut: Grenzwert für die Anzahl von ausgefallenen Paketen, bevor der Jitterpuffer 11 zurückgesetzt wird.

Fig. 6 zeigt ein Zustandsübergangsdiagramm des Ablaufs, der im Jitterpuffer 11 implementiert ist und der sechs Zustände umfasst. In einem ersten Zustand 30 wird der Jitterpuffer 11 initialisiert. Wenn dies abgeschlossen ist, wechselt der Jitterpuffer 11 in einen weiteren Zustand 32 in dem entweder (i) eine Ankunft eines neuen RTP-Pakets von der IP- Verbindung 7 erwartet wird, oder (ii) ein Empfang einer Datenanforderungsnachricht vom Echtzeitprozessor 5 erwartet wird. Mit dem Empfang eines neuen RTP-Pakets wechselt der Jitterpuffer 11 in einen neuen Zustand 34, in dem die oben beschriebenen Hauptorganisationsschritte durchgeführt werden, z. B. Überprüfung der Out-of-Range- Unterbrechung, Überprüfung des Umkehrpunktes und die Paketorganisation. Vorausgesetzt, dass ein gültiges RTP-Paket empfangen wurde, dann wird das Paket im zugehörigen Speicherbereich des Speicherfeldes 15 gespeichert und Parameter, d. h. Variablen, des Jitterpuffers 11 werden entsprechend dem weiteren Schritt 36 eingestellt. Ist dies abgeschlossen, dann wird ein neues RTP-Paket durch Rückkehr zum Schritt 32 erwartet. Wird ein nicht gültiges Datenpaket empfangen, beispielsweise weil das Paket zu spät empfangen wurde oder weil eine Out-of- Range-Unterbrechung detektiert wurde, dann wird nicht zum Parametereinstellschritt 36 gewechselt, sondern zum Schritt 32 und das nächste Datenpaket wird erwartet.
Wird eine Datenanforderungsnachricht vom Echtzeitdatenprozessor 5 empfangen, dann wechselt der Jitterpuffer 11 in einen Datenanfordungsbearbeitungszustand 38, in dem ein Datenpaket aus dem Speicherbereich des Speicherfeldes 15 ausgelesen wird. Abhängig davon, ob ein angefordertes RTP-Datenpaket gültig gesendet wurde oder nicht, beispielsweise weil das Paket bisher noch nicht empfangen wurde oder weil das Paket schon gesendet wurde, wird in einen Datenflusseinstellzustand 40 gewechselt, in dem der Datenfluss des Jitterpuffers 11 passend eingestellt wird, so dass eine effiziente Übertragung der nacheinander gesendeten Datenpakete sichergestellt wird. Nach der Beendigung dieses Vorgangs wird zum Schritt 32 zurückgekehrt und das nächste Datenpaket erwartet.
Nun wird die Arbeitsweise jedes Zustandes des Ablaufs im Jitterpuffer 11 beschrieben.
Wie bereits ausgeführt wurde, ist der erste Zustand 30 des Ablaufs die Initialisierung des Jitterpuffers 11. Grundsätzlich umfasst dies ein Setzen der Variablen des Jitterpuffers 11 auf ihre Initialisierungswerte durch:

1. Setzen der Variablen MostRecentSeq und LateSeq auf Null;
2. Setzen der Variablen LeastRecentSeq auf (MAX_RTP_SEQ - BUF_DEPTH + 1);
3. Setzen aller Bits der Variablen PacketStatus auf NO_PACKET;
4. Setzen der Variablen JitterMax, JitterMin, JitterHysteresis, JitterAdjTime und LateSeqLimit auf ihre Vorgabewerte;
5. Setzen der Variablen JitterThreshold auf irgendeinen Wert zwischen JitterMax und JitterMin; und
6. Setzen der Variablen SendSeq auf (MAX_RTP_SEQ - JitterThreshold + 1).

Wie aus Fig. 6 ersichtlich ist, wird nach Beendigung des Zustands 30 zum nächsten Schritt 32 gewechselt, in dem das nächste RTP-Paket oder eine Datenanforderungsnachricht erwartet wird. In diesem Zustand wechselt, wenn ein RTP-Paket über die IP-Verbindung 7 empfangen wird, der Jitterpuffer 11 zum Zustand 34, wo die Hauptorganisationsschritte ausgeführt werden. Die im Zustand 32 ausgeführten Schritte des Ablaufs werden im Zusammenhang mit Fig. 7 beschrieben.
Wie aus Fig. 7 ersichtlich ist wird im Schritt 44 eine Anfangsschleife aufgebaut, wobei wenn kein RTP-Paket empfangen wird der Ablauf zum Schritt 32 zurückkehrt und so den Vorgang wiederholt. Die folgenden nummerierten Schritte bezeichnen einen fortlaufenden Betrieb.

1. Wurde ein neues Datenpaket empfangen, dann vergleicht der Ablauf die Sequenznummer des RTP-Pakets (RecvSeq) mit der höchsten bereits empfangenen (MostRecentSeq) und der niedrigsten bereits empfangenen (LeastRecentSeq) RTP- Sequenznummer, die für die bereits im Speicherfeld 15 gespeicherten RTP-Pakete aufgenommen wurden.
2. Als nächstes wird im Schritt 46 eine Überprüfung der Out-of- Range-Unterbrechung durchgeführt, deren Prinzip bereits beschrieben wurde. Bei diesem Ablauf tritt eine Out-of-Range- Unterbrechung auf, wenn der absolute Wert von (MostRecentSeq - RecvSeq) größer ist als (MaxDropOut + BUF_DEPTH) und der absolute Wert von (LeastRecentSeq - RecvSeq) größer ist als (MaxDropOut + BUF_DEPTH). Wird keine Out-of-Range- Unterbrechung detektiert, dann wird zum Schritt 52 gewechselt.
3. Wird eine Out-of-Range-Unterbrechung detektiert, dann wird im Schritt 48 eine weitere Überprüfung durchgeführt, um zu bestimmen, ob ein Umkehrpunktzustand vorliegt. Eine solcher Zustand liegt vor, wenn RecvSeq kleiner ist als (MaxDropOut + BUF_DEPTH) und wenn LeastRecentSeq größer ist als MAX_RTP_SEQ - (MaxDropOut + BUF_DEPTH).
4. Liegt ein Umkehrpunktzustand vor, dann wird im Schritt 50 in den Umkehrpunktmodus gewechselt. Der Ablauf arbeitet in diesem Umkehrpunktmodus für alle nachfolgend empfangenen RTP- Datenpakete bis ein Ende des Umkehrpunktzustandes erkannt wird. In diesem Zusammenhang liegt ein Umkehrpunktzustand vor, die Variable MostRecentSeq kleiner ist als die Variable LeastRecentSeq und der Umkehrpunktzustand wird beendet, wenn MostRecentSeq größer ist als LeastRecentSeq.
5. Im Umkehrpunktmodus, d. h. im Schritt 50, werden die Werte von RecvSeq, MostRecentSeq, LeastRecentSeq und SendSeq mit einem Offset versehen, um den Umkehrpunktzustand durch eine Addition von Q × BUF_DEPTH zu verlassen, wobei Q eine ganzzahlige Konstante ist. Der Offsetwert sollte im Bereich zwischen (MaxDropOut + BUF_DEPTH) und (MAX_RTP_SEQ - 1) liegen. Dann wird zum Schritt 52 gewechselt.
6. Wurde im Schritt 48 kein Umkehrpunktmodus erkannt, dann setzt der Ablauf den Jitterpuffer 11 im Schritt 56 zurück, weil alle im Speicherfeld 15 gespeicherten Daten durch das Vorliegen der bereits detektierten Out-of-Range-Unterbrechung als abgelaufen gelten. Der Jitterpuffer 11 wird durch Setzen der Variablen MostRecentSeq auf RecvSeq, der Variablen LeastRecentSeq auf (Recv- Seq - BUF_DEPTH + 1) und der Variablen SendSeq auf (Recv- Seq - JitterThreshold + 1) zurückgesetzt. Das empfangene RTP- Paket wird dann in einem Speicherbereich des Speicherfelds 15 entsprechend der bereits erwähnten Berechnung M (Modulo N) gespeichert. Dies wird durch die Berechnung RecvSeq (Modulo BUF-DEPTH) erreicht. Die Variable PacketStatus[PacketIndex] die mit dem Speicherbereich korrespondiert, wird dann auf PACKET_UNREAD gesetzt, um anzuzeigen, dass das Paket bereit ist, um für den Echtzeitdatenprozessor 5 ausgelesen zu werden. Der Ablauf kehrt dann in den Wartezustand 32 zurück.
7. Wird keine Out-of-Range-Unterbrechung im Schritt 46 erkannt, oder nach dem Offset-Vorgang in Schritt 50 wird in den Schritt 52 gewechselt. Im Schritt 52 wird die Gültigkeit des empfangenen RTP-Pakets geprüft. Ist die Variable RecvSeq kleiner als die Variable SendSeq, dann scheint das Paket zu spät angekommen zu sein, um für den Echtzeitdatenprozessor 5 ausgelesen werden zu können und scheint deshalb ungültig zu sein. Entsprechend wird das Paket im Schritt 58 abgelegt. Jeglicher Offset, der im Umkehrpunktmodus (Schritt 50) hinzugefügt wurde, wird in den Schritten 60 und 62 entfernt und der Ablauf kehrt wieder zum Wartezustand 32 zurück. Ist die Variable RecvSeq nicht kleiner als die Variable SendSeq, dann scheint das RTP-Paket gültig zu sein.
8. Scheint das RTP-Paket im Schritt 52 gültig zu sein, dann wird das Paket entsprechend der Berechnung M (Modulo N) im Speicherfeld 15 gespeichert. In anderen Worten, das RTP-Paket wird mit der Regalfachtechnik im Speicherfeld 15 abgelegt, wobei der Speicherindex gleich dem Wert RecvSeq (Modulo BUF_DEPTH) ist. Das RTP-Paket wird dann unter Benutzung des berechneten Wertes PacketStore[PacketIndex] zum entsprechenden Speicherbereich übertragen. PacketStatus[PacketIndex] wird dann auf PACKET_UNREAD gesetzt, um anzuzeigen, dass das im Speicherbereich gespeicherte Paket fertig zum Versenden an den Echtzeitdatenprozessor 5 ist, wenn eine Datenanforderungsnachricht empfangen wird. Der Ablauf wechselt in den Zustand 36, in dem verschiedene Parameter des Jitterpuffers 11 neu eingestellt werden.

Nachfolgend zu den oben im Zusammenhang mit Fig. 5 beschriebenen Beispielen der Hauptorganisationsschritte wird nun eine Anzahl von weiteren Beispielen beschrieben.

Beispiel 1

Detektierung einer Out-of-Range-Unterbrechung

Es wird angenommen, dass BUF_DEPTH gleich 16 ist, MaxDropOut gleich 16 ist und die empfangenen Sequenznummern der RTP- Paketsequenz sind 0, 1, 2, 3, 4, 67, 68, 69, dann wird eine Out-of- Range-Unterbrechung erkannt, wenn das Paket mit der Sequenznummer 67 empfangen wird. Bezugnehmend auf die oben in Verbindung mit Schritt 46 des Ablaufs beschriebene Gleichung, ist der absolute Wert von MostRecentSeq (d. h. 4) minus RecvSeq (d. h. 67) gleich 63, was größer ist als MaxDropOut + BUF_DEPTH (d. h. 32). Zudem ist der absolute Wert von LeastRecentSeq (d. h. 0) minus RecvSeq (d. h. 67) gleich 67, was wiederum größer ist als 32. Es ist jedoch kein Umkehrpunkt aufgetreten, was verständlich ist, wenn man der Gleichung folgt, die oben in Verbindung mit Schritt 48 beschrieben wurde.

Beispiel 2

Erkennung eines Umkehrpunktes

Es wird angenommen, dass BUF_DEPTH gleich 16 ist, MaxDropOut gleich 16 ist, Q gleich 10 ist und die empfangenen Sequenznummern der RTP-Paketsequenz sind 65533, 65534, 65535, 0, 1, 2, 3, dann wird ein Umkehrpunkt zu dem Zeitpunkt erkannt, wenn das RTP-Paket mit der Sequenznummer 0 empfangen wird. Dies ist wiederum verständlich, wenn man die in Verbindung mit Schritt 48i Detail beschriebene Gleichung ausführt. Daraus resultiert, das die Sequenznummern mit einem Offset von (Q × BUF_DEPTH) unter Benutzung von Modulo MAX_RTP_SEQ versehen werden, bevor mit die Weiterverarbeitung fortgesetzt wird. Der Offset ist deshalb gleich 160 und so sind die Off setsequenznummern 157, 158, 159, 160, 161, 162 und 163.

Beispiel 3

Organisation der RTP-Pakete mit einer falschen Reihenfolge

Wie oben bereits beschrieben wurde, wird dies durch die Gleichung M (Modulo N) ausgeführt, oder wenn die Terminologie des Ablaufs benutzt wird durch RecvSeq (Modulo BUF_DEPTH). Deshalb werden, wenn BUF_DEPTH gleich 16 ist, MaxDropOut gleich 16 ist und die Sequenz 20, 21, 22, 25, 23, 24 empfangen wird, die Pakete 20, 21 und 22 in den jeweiligen Speicherbereichen mit den zugehörigen indizierten Nummern [4], [5] bzw. [6] gespeichert. Mit dem Empfang des Datenpakets mit der Sequenznummer 25, wird keine Out-of-Range-Unterbrechung erkannt, weil der MaxDropOut gleich 16 ist, und das RTP-Paket wird im Speicherbereich mit der indizierten Nummer [9] gespeichert. Die Pakete mit den Nummern 23 und 24 werden jeweils in den Speicherbereichen [7] bzw. [8] gespeichert.
Wie oben bereits ausgeführt, werden die Organisationsüberprüfungen und -vorgänge vor dem Speichern des aktuell empfangenen RTP- Pakets (RecvSeq) im zugehörigen Speicherbereich im Speicherfeld 15 durchgeführt. Zu diesem Zweck werden die empfangenen RTP-Pakete in das RAM 17 übertragen, wo danach die oben beschriebenen Organisationsüberprüfungen und -vorgänge durchgeführt werden.
Die betroffenen Schritte zum Einstellen der Parameter des Jitterpuffers 11, d. h. im Zustand 36, wird nachfolgend unter Bezugnahme auf Fig. 8 beschrieben. Dieser Zustand wird nur erreicht, wenn ein gültiges RTP- Paket im Speicherfeld 15 gespeichert wird.
In einem Eingangsschritt 64 wird bestimmt, ob die Variable RecvSeq größer ist als die Variable MostRecentSeq. Wenn dies der Fall ist, dann wird im Schritt 66 die Variable MostRecentSeq aufgefrischt, so dass sie gleich RecvSeq ist. In anderen Worten ausgedrückt, die aktuelle Sequenznummer wird nun zur MostRecentSeq und die Sequenznummer des nächsten empfangenen Paket ist dann RecvSeq. Wird im Schritt 68, der durch LeastRecentSeq<(MostRecentSeq - BUF_DEPTH + 1) dargestellt wird, festgestellt, dass das aktuelle RTP-Paket das niedrigste bereits empfangene RTP-Paket im Speicherfeld 15 überschreibt, dann wird im Schritt 70 die Variable LeastRecentSeq auf den Wert (MostRecentSeq - BUF_DEPTH + 1) aufgefrischt. Im Schritt 72 wird, wenn genügend Zeit verfügbar ist, der aktuelle Wert der Variablen JitterThreshold eingestellt, abhängig davon, ob neue Datenpakete empfangen wurden, und dann die akkumulierte Anzahl von verspäteten Paketen (Late- Seq) überwacht. Wie oben bereits ausgeführt wurde, sind Pakete verspätet, wenn die Variable RecvSeq kleiner ist als die Variable SendSeq. Wenn dem so ist, dann wird im Schritt 74 bestimmt, ob die akkumulierte Anzahl einen vorbestimmten Wert der Variablen LateSeqLimit über einer vorbestimmten Zeitperiode JitterAdjTime überschreitet. Wenn dem so ist, dann wird im Schritt 76 der aktuelle Wert der Variablen JitterThreshold vergrößert. Ist dem nicht so, dann wird im Schritt 78 der aktuelle Wert der Variablen JitterThreshold verkleinert. Die Variable JitterThreshold bewegt sich zwischen den Variablen JitterMax und JitterMin.
Nach den Einstellungsschritten wird im Schritt 80 bestimmt, ob ein Umkehrpunktzustand vorliegt. Wenn dem so ist, dann werden die in vorherigen Stufen zu den Sequenznummern hinzugefügten Offsets, d. h. der addierte Wert Q mal BUF_DEPTH, im Schritt 82 durch Benutzung von Modulo MAX_RTP_SEQ entfernt. Nach der Entfernung des Offsets, wird in den Wartezustand 32 zurückgekehrt. Es wird direkt in den Wartezustand zurückgekehrt, wenn keine Zeit für eine Einstellung in Schritt 72 vorhanden ist, oder wenn kein Umkehrpunktzustand im Schritt 80 erkannt wurde.
Nun werden die vom Ablauf im Zustand 38 der Handhabung einer Datenanforderung auszuführenden Schritte beschrieben. Wie bereits ausgeführt, wird dieser Zustand erreicht, wenn eine Datenanforderungsnachricht vom Echtzeitdatenprozessor 5 empfangen wurde. Nach dem Empfang einer Datenanforderungsnachricht wird, wenn das nächste der Variablen SendSeq entsprechende RTP-Paket bereits empfangen und im Speicherfeld 15 des Jitterpuffers 11 gespeichert wurde, was dadurch angezeigt wird, das die Variable PacketStatus für das betreffende Datenpaket gleich PACKET_UNREAD ist, das RTP-Paket zum Echtzeitdatenprozessor 5 gesendet. Die zugehörige Variable PacketStatus für dieses Paket wird dann auf PACKET_READ gesetzt. Ist das mit SendSeq korrespondierende RTP-Paket nicht verfügbar, dann wird kein Paket zum Echtzeitdatenprozessor 5 gesendet. In jedem Fall wird SendSeq um eins erhöht und der Ablauf wechselt zum Zustand Datenflusseinstellung 40.
Der Betrieb des Jitterpufferablaufs im Zustand Datenflusseinstellung 40 wird nun in Verbindung mit Fig. 9 beschrieben.
Wird in einem ersten Schritt 84 des Datenflusseinstellungszustands 40 festgestellt, dass sich der Ablauf im Umkehrpunktmodus befindet, was durch MostRecentSeq < LeastRecentSeq angezeigt wird, dann werden im nächsten Schritt 86 die Variablen RecvSeq, MostRecentSeq, LeastRecentSeq und SendSeq durch einem Offset in eine Region außerhalb des Umkehrpunktes durch Addieren von Q mal BUF_DEPTH unter Benutzung von Modulo MAX_RTP_SEQ versetzt, wobei Q eine ganzzahlige Konstante ist. Der Offsetwert muss innerhalb des Bereichs zwischen (MaxDropOut + BUF_DEPTH) und (MAX_RTP_SEQ - 1) angeordnet sein. Als nächstes wird zum Schritt 88 gewechselt. Zum Schritt 88 wird direkt gewechselt, wenn kein Umkehrpunktzustand im Schritt 84 detektiert wurde.
Im Schritt 88 bestimmt der Ablauf, ob die Variable SendSeq kleiner oder gleich zu (MostRecentSeq - JitterThreshold - Hysteresis) ist. Dies zeigt an, dass die aktuelle Speicherbereichposition die vom Echtzeitdatenprozessor 5 betrachtet oder ausgelesen wird über dem Wert des JitterThreshold liegt. Das nächste an den Echtzeitdatenprozessor 5 zu sendende RTP-Paket wird dann im Schritt 90 durch Erhöhen von Send- Seq abgelegt. Ist das Ergebnis von Schritt 88 "nein", dann wird im Schritt 92 bestimmt, ob SendSeq größer ist als (MostRecentSeq - JitterThreshold + Hysteresis), dies zeigt an, dass die aktuell betrachtete Speicherbereichposition unter dem JitterThreshold liegt. Ist dies der Fall, dann kann die nächste Datenanforderungsnachricht durch Verkleinern des Wertes von SendSeq im Schritt 94 ignoriert werden.
Wird im Schritt 96 festgestellt, dass SendSeq kleiner ist als LeastRecentSeq, dann wird SendSeq im Schritt 98 auf (LeastRecentSeq + 1) gesetzt. Jegliche Offsets, die durch einen Umkehrpunktzustand hinzugefügt wurden, werden im Schritt 100 erkannt und im Schritt 102 durch Modulo MAX_RTP_SEQ entfernt. Dann wird in den Wartezustand 32 zurückgekehrt, wo der Ablauf auf ein neues RTP-Paket von der IP- Verbindung 7 wartet oder auf eine weitere Datenanforderungsnachricht vom Echtzeitdatenprozessor 5.
Es ist zu beachten, dass ein Hystereseband bei den oben beschriebenen Einstellungen des JitterThreshold benutzt wird. Entsprechend sollte der maximale Wert von JitterMax nicht auf einen größeren Wert als (BUF_DEPTH - Hysteresis - 1) gesetzt werden. Analog sollte der minimale Wert von JitterMin nicht auf einen kleineren Wert wie (Hysteresis + 1) gesetzt werden.
Während der oben beschriebene Ablauf als Programm implementiert ist, das auf dem Prozessor 13 des Jitterpuffers 11 abläuft, versteht es sich, dass der Ablauf auch in Form von Hardware oder Firmware umgesetzt werden kann. Die Modulo BUF_DEPTH Regalfachtechnik kann auch durch eine Maskierung der niederwertigsten Bits (LSBs) der Sequenznummern ausgeführt werden, unter der Voraussetzung, dass der Wert von BUF_DEPTH eine Zweier-Potenz ist, beispielsweise durch eine Maskierung der letzten vier LSBs für einen Wert von BUF_DEPTH von 16. Die Addition von Vielfachen des Wertes von BUF_DEPTH für die Handhabung des Umkehrpunktes, kann durch Implementierung einer Zweier-Komplement Übertragung realisiert werden, wieder unter der Voraussetzung, dass der Wert von BUF_DEPTH eine Zweier-Potenz ist.
Der oben beschriebene Ablauf kann an jedes paket- oder framebasiertes Netzwerkprotokoll angepasst werden, das eine sequentielle Sortierung von Datenpaketen am Ausgabeende umfasst und bei dem die Sequenzindexe gebunden sind und bei einem Umkehrpunkt auf null gesprungen wird, wenn der maximale Index erreicht ist.

Claims

1. Verfahren zum Organisieren von Datenpaketen, die über eine Datenverbindung (7) empfangen werden, wobei jedes Datenpaket mit einer Nummer indiziert ist, welche die Reihenfolge anzeigt, in der das Datenpaket ausgegeben wird, dadurch gekennzeichnet, dass ein Puffer (11) mit einer Mehrzahl von Speicherbereichen zur Verfügung gestellt wird, wobei jeder Speicherbereich in der Lage ist, ein einzelnes Datenpaket auf einmal zu speichern und wobei jedes empfangene Datenpaket in einem vorbestimmten der Mehrzahl von Speicherbereichen in Abhängigkeit von der indizierten Nummer des betreffenden Datenpakets gespeichert wird.

2. Verfahren zum Organisieren von Datenpaketen nach Anspruch 1, dadurch gekennzeichnet, dass ein Datenlesemittel (13) periodisch die Datenpakete aus den jeweiligen Speicherbereichen, in denen sie gespeichert sind, in der Reihenfolge ausliest, in der die Datenpakete ausgegeben werden.

3. Verfahren zum Organisieren von Datenpaketen nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass N Speicherbereiche zur Verfügung gestellt werden und die indizierten Nummern M Nummern umfassen, wobei N und M ganzzahlige Werte sind, wobei M größer oder gleich N ist und N größer als 1 ist.

4. Verfahren zum Organisieren von Datenpaketen nach Anspruch 3, dadurch gekennzeichnet, dass die Datenpakete in Abhängigkeit vom Ergebnis von M (Modulo N) in den Speicherbereichen gespeichert werden, wobei M die indizierte Nummer ist, die dem betroffenen Datenpaket zugeordnet ist.

5. Verfahren zum Organisieren von Datenpaketen nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass sich die indizierten Nummern nach M über die Datenverbindung 7 gesendeten Datenpaketen wiederholen, wobei jedes empfangene Datenpaket überwacht wird, um zu bestimmen, ob seine zugehörige indizierte Nummer eine Wiederholung einer bereits empfangenen indizierten Nummer ist, wobei die indizierten Nummern von bereits im Puffer (11) gespeicherten Datenpaketen in Abhängigkeit von einer solchen Bestimmung verändert werden, in dem an ganzzahliges Vielfaches von N zu diesen indizierten Nummern addiert wird.

6. Verfahren zum Organisieren von Datenpaketen nach Anspruch 5, dadurch gekennzeichnet, dass der Bestimmungsschritt, ob die empfangene indizierten Nummer eine Wiederholung einer bereits empfangenen indizierten Nummer ist, durch eine Erkennung, ob die indizierte Nummer des empfangenen Datenpakets kleiner ist als die indizierte Nummer eines direkt vorher empfangenen Datenpakets ausgeführt wird.

7. Verfahren zum Organisieren von Datenpaketen nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass eine Differenz zwischen den indizierten Nummer von zwei nacheinander empfangenen Datenpaketen überwacht wird, um zu bestimmen ob Datenpakete, die zwischen den beiden nacheinander empfangenen Datenpaketen ausgegeben werden sollen, noch nicht empfangen wurden, wobei der Bestimmungsschritt, ob eine empfangene indizierte Nummer eine Wiederholung von bereits gesendeten indizierten Nummern ist nur durchgeführt wird, wenn eine Anzahl von Datenpaketen, die noch nicht empfangen wurden eine vorbestimmte Nummer übersteigt.

8. Verfahren zum Organisieren von Datenpaketen nach Anspruch 7, dadurch gekennzeichnet, dass wenn (a) erkannt wird, dass die Anzahl von nicht empfangenen Datenpaketen die vorbestimmte Nummer übersteigt und (b) die empfangenen indizierten Nummern keine Wiederholung einer bereits gesendeten indizierten Nummer ist, dann wird der Puffer (11) zurückgesetzt.

9. Verfahren zum Organisieren von Datenpaketen nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass jedes nachfolgende Datenpaket, das einem belegten Speicherbereich zugewiesen wird, so ausgelegt ist, dass es das in diesem Speicherbereich bereits gespeicherte Datenpaket überschreibt.

10. Verfahren zum Organisieren von Datenpaketen nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die indizierten Nummern auch die Reihenfolge angeben, in der die Datenpakete in die Datenverbindung (7) eingegeben werden.

11. Rechnerprogramm, das auf einem rechnerlesbaren Datenträger gespeichert ist, gekennzeichnet, durch rechnerlesbare Befehle, die von einem Ausführungsmittel eines Rechners zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 10 ausgeführt werden.

12. Datenpuffer zum Organisieren von Datenpaketen, die über eine Datenverbindung (7) empfangen werden, wobei jedes Datenpaket mit einer Nummer indiziert ist, welche die Reihenfolge anzeigt, in der das Datenpaket aus dem Datenpuffer ausgebbar ist, gekennzeichnet, durch eine Mehrzahl von Speicherbereichen, wobei jeder Speicherbereich in der Lage ist, ein einzelnes Datenpaket auf einmal zu speichern und wobei der Datenpuffer (11) ausgeführt ist, jedes empfangene Datenpaket in einem vorbestimmten der Mehrzahl von Speicherbereichen in Abhängigkeit von der indizierten Nummer des betreffenden Datenpakets zu speichern.

13. Datenpuffer zum Organisieren von Datenpaketen nach Anspruch 12, dadurch gekennzeichnet, dass der Datenpuffer (11) ausgeführt ist, die Datenpakete aus den jeweiligen Speicherbereichen des Datenpuffers (11), in denen sie gespeichert sind, in Abhängigkeit von einer periodischen Datenanforderungsnachricht auszugeben, das von einem Datenverarbeitungsmittel (5) empfangen wird.

14. Datenpuffer zum Organisieren von Datenpaketen nach Anspruch 12 oder 13, gekennzeichnet durch N Speicherbereiche, die ausgeführt sind, um Datenpakete mit indizierten Nummern zu speichern, die M Nummern umfassen, wobei N und M ganzzahlige Werte sind, wobei M größer oder gleich N ist und N größer als 1 ist.

15. Datenpuffer zum Organisieren von Datenpaketen nach Anspruch 14, dadurch gekennzeichnet, dass die Datenpakete in Abhängigkeit vom Ergebnis von M (Modulo N) in den Speicherbereichen gespeichert werden.

16. Datenpuffer zum Organisieren von Datenpaketen nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass der Datenpuffer (11) ausgeführt ist, um zu bestimmen, ob eine indizierte Nummer eines empfangenen Datenpakets eine Wiederholung einer bereits empfangenen indizierten Nummer ist, wobei die indizierten Nummern von bereits im Puffer (11) gespeicherten Datenpaketen in Abhängigkeit von einer solchen Bestimmung verändert werden, in dem an ganzzahliges Vielfaches von N zu diesen indizierten Nummern addiert wird.

17. Datenpuffer zum Organisieren von Datenpaketen nach Anspruch 16, dadurch gekennzeichnet, dass der Datenpuffer (11) durch eine Erkennung, ob die indizierte Nummer des empfangenen Datenpakets kleiner ist als die indizierte Nummer eines direkt vorher empfangenen Datenpakets, bestimmt, ob die empfangene indizierten Nummer eine Wiederholung einer bereits empfangenen indizierten Nummer ist.

18. Datenpuffer zum Organisieren von Datenpaketen nach Anspruch 16 oder 17, dadurch gekennzeichnet, dass der Datenpuffer (11) ausgeführt ist, um (a) zu bestimmen ob Datenpakete, die zwischen zwei nacheinander empfangenen Datenpaketen ausgegeben werden sollen, noch nicht empfangen wurden und (b) zu bestimmen, ob eine empfangene indizierte Nummer eine Wiederholung von bereits gesendeten indizierten Nummern ist, wobei dies nur durchgeführt wird, wenn eine Anzahl von Datenpaketen, die noch nicht empfangen wurden eine vorbestimmte Nummer übersteigt.

19. Datenpuffer zum Organisieren von Datenpaketen nach einem der Ansprüche 12 bis 18, dadurch gekennzeichnet, dass der Datenpuffer so ausgeführt ist, dass jedes nachfolgende Datenpaket, das einem belegten Speicherbereich zugewiesen wird, in der Lage ist, das in diesem Speicherbereich bereits gespeicherte Datenpaket zu überschreiben.