WO2004112341A2 - Verfahren und vorrichtung zur verarbeitung von echtzeitdaten - Google Patents

Verfahren und vorrichtung zur verarbeitung von echtzeitdaten Download PDF

Info

Publication number
WO2004112341A2
WO2004112341A2 PCT/EP2004/006080 EP2004006080W WO2004112341A2 WO 2004112341 A2 WO2004112341 A2 WO 2004112341A2 EP 2004006080 W EP2004006080 W EP 2004006080W WO 2004112341 A2 WO2004112341 A2 WO 2004112341A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
data packets
packet type
real
packets
Prior art date
Application number
PCT/EP2004/006080
Other languages
English (en)
French (fr)
Other versions
WO2004112341A3 (de
Inventor
Roland Harend
Robert Morelj
Ingo Volkening
Original Assignee
Infineon Technologies Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies Ag filed Critical Infineon Technologies Ag
Priority to US10/545,917 priority Critical patent/US7969982B2/en
Publication of WO2004112341A2 publication Critical patent/WO2004112341A2/de
Publication of WO2004112341A3 publication Critical patent/WO2004112341A3/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/35—Flow control; Congestion control by embedding flow control information in regular packets, e.g. piggybacking

Definitions

  • the present invention relates to a method and a device for processing data packets which comprise real-time data packets.
  • it relates to a method and a device for processing real-time data packets with voice or similar communication data, which are transmitted via an IP network.
  • Such devices are therefore dependent on the speed and data processing capacity of this single main processor.
  • Overloading the main processor can lead to problems such as loss of data packets, jitter, runtime fluctuations or other delays. In the case of voice data, for example, this leads to a reduction in the quality of the transmission and, in the worst case, can lead to suspension or an interruption of the connection.
  • the real-time data packets are assigned a higher priority during processing. However, this does not solve the basic problem of possible overloading of the main processor and at least leads to delayed processing of the other data packets. This procedure also involves a relatively high level of processing and implementation effort.
  • the data packets are classified into at least one first data packet type, which comprises or is assigned real-time data packets, and a second data packet type, and the data packets of the first data packet type are classified via a first data path and the data packets of the to process the second data packet type via a second data path.
  • the second data packet type can include data packets with control or signal information, in particular relating to the respective connection.
  • the first data path preferably has a smaller delay in the processing or transmission of the data packets than the second data path.
  • the second data path can comprise a main processor, while in the first data path the data packets can be processed, for example, by coprocessors. This relieves the load on the main processor and the real-time data packets can be processed with little delay via the first data path.
  • connection data for the exchange of real-time data packets can be stored with a communication device and the data packets can be classified as data packets of the first data packet type if at least part of the connection data of the data packet matches the stored connection data.
  • connection data can be a network address of a sender of the data packets or a port on which the data packets are received.
  • the data can be classified by a processor unit, in particular by a coprocessor.
  • Memory management is preferably carried out by a main processor unit.
  • the utilization or availability of the first data path is advantageously monitored, and packets of the first data packet type are exceptionally transmitted for processing via the second data path if the utilization of the first data path exceeds a predetermined value or the first data path is not available. This creates redundancy, and in the event of malfunctions or failures in the first data path, which is primarily intended for the real-time data packets, the second data path can be used, which enables a more reliable connection.
  • the real-time data packets include, for example, voice data, so that the invention is particularly suitable for "Voice over ⁇ " applications.
  • voice data for example, voice data
  • the invention is explained in more detail below with reference to the accompanying drawing using preferred exemplary embodiments. Show it:
  • FIG. 1 shows a block diagram of an exemplary embodiment of a device according to the invention
  • FIG. 2 shows an illustration for a classification of data packets on the basis of connection data
  • FIG. 3 shows a flowchart which shows an exemplary embodiment for the classification of data packets according to the invention
  • FIG. 4 shows a block diagram which represents a possible memory management of the device according to the invention from FIG. 1.
  • FIG. 1 shows an exemplary embodiment of a device according to the invention in the form of a block diagram.
  • the exemplary embodiment deals with the reception of data packets from a communication network (not shown) such as the Internet.
  • a corresponding device would also be possible for sending data.
  • Incoming data packets which include real-time data packets, are received via a data path a and sent to a coprocessor 1, hereinafter referred to as a packet coprocessor.
  • a packet coprocessor In this packet coprocessor 1, the incoming data packets are examined and classified into at least two data packet types, real-time data packets being assigned to the first data packet type. Other data packets, which for example control signals for a connection over which the. Data packets received, are assigned to a second data packet type. Suitable criteria for this classification are discussed in more detail below.
  • Data packets of the first data packet type ie real-time data packets such as data packets with voice data
  • a further coprocessor 2 for processing via a first data path b, in the case of voice data a voice coprocessor. He can check again whether it is actually the desired real-time data. If this is the case, the coprocessor 2 can process the data packet and, for example, forward the voice data via a data path e to a downstream unit 4 for processing and outputting this voice data.
  • Data packets of the second data packet type are forwarded via a first part c of a second data path to a main processor 3 ("Central Processing Unit", CPU) for processing.
  • This second data path can contain a second part d, with which the further coprocessor 2 can also send data packets to the main processor 3 if it is recognized that the real-time data packets are not the desired ones.
  • incoming real-time data packets can thus be processed by the coprocessors 1 and 2 alone without the aid of the main processor 3.
  • this relieves the load on the main processor and, on the other hand, enables faster processing of the data and thus a reduction in delays in the data flow since the first data path b is only used for these real-time data packets.
  • the availability of the first data path b can be monitored. If it turns out that the first data path b is not available, for example because of overloading or because of an interruption, data packets of the first data packet type, i.e. real-time data packets, can also be sent to the main processor unit via the second data path c and then further via the paths d and e to the downstream unit 4 be directed. This means that the system also works for the Case ensured that the first data path b is not available (redundancy).
  • FIG. 2 shows an example of the classification of data packets on the basis of so-called header parameters, i.e. Parameters that contain information about a connection in a communication network are shown. Such header parameters are placed in front of the actual data in a data packet and remain essentially unchanged in the course of a connection. When a connection is initialized, for example to receive voice data, these header parameters 5 are set once by the main processor unit 3.
  • the main processor 3 When setting up the connection, the following are carried out by the main processor 3 in a device which operates, for example, according to the H.323 standard:
  • Gateway who is responsible for the corresponding network zone (for example, through an IP multicast using a UDP ("User Datagram Protocol”) protocol) and asks for permission to set up the connection.
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • H.323 server a TCP connection is established to the corresponding (called) H.323 server.
  • a call is set up using an H.225.0 protocol (similar to a Q.931 call setup) via the TCP connection.
  • the header parameters 5 generated in this case include Ethernet header parameters 5A, which include parameters of an Ethernet connection, for example in a LAN, IP header parameters 5B, which contain information about the connection to an IP network such as the Internet, and UDP header parameters 5C, which information via the "User Datagram" protocol, which is typically used to send voice data.
  • Ethernet header parameters 5A which include parameters of an Ethernet connection, for example in a LAN
  • IP header parameters 5B which contain information about the connection to an IP network such as the Internet
  • UDP header parameters 5C which information via the "User Datagram" protocol, which is typically used to send voice data.
  • These header parameters 5 are sent to the coprocessors 1 and 2 via the two parts of the second data path c, d and are stored there for reference purposes.
  • a data packet 6, which is received via data path a also contains such header parameters 6A, 6B, 6C and also the actual data 6D, in the case of voice data RTP ("Real Time Protocol") real-time voice data.
  • RTP Real
  • the header parameters ⁇ A, 6B, 6C are compared with the corresponding stored header parameters 5A, 5B, 5C. If the parameters match in such a way that it can be ensured that the data originate from the corresponding connection for receiving voice data, the data packet 6 is classified as the first data packet type and passed on to the further coprocessor 2 via the first data path b. This can continue the classification, especially when processing the data. If the classification in the packet coprocessor 1 or in the speech coprocessor 2 shows that it is not speech data, the data packet is transferred to the main processor 3. Otherwise, it is processed by the speech coprocessor 2.
  • a first step 7 it is checked whether the port on which the data packet was received is the port provided for the respective connection for receiving voice data. This is particularly important when several connections are active at the same time. If so (Y), go to the next step 8 if No (N), the process proceeds to step 13, in which the corresponding data packet is transferred to the main processor unit 3.
  • step 8 it is checked whether the correct connection type, for example IP, is specified for the respective connection in the Ethernet header 6A. If so, go to step 9; if no, go back to step 13.
  • the correct connection type for example IP
  • step 9 it is checked whether the destination IP address of the received data packet matches the corresponding IP address provided for the connection. If no, the process continues to step 13.
  • These first three classification steps 7 to 9 are carried out, for example, in the packet processor 1. They allow a low level classification by checking only elementary communication parameters.
  • step 9 the data packet is transferred to the speech coprocessor 2 for further treatment.
  • step 10 There it is checked in step 10 whether the protocol of the received data packet is a UDP protocol. If no, the process moves to step 14, which means that the data packet is again passed on to the main processor 3. If so, go to step 11. Here it is checked whether the UDP port is the port for voice data reception. This is used to distinguish between so-called RAS ("Registration, Admission and Status") and voice data packets. If no, the process continues to step 14. If so, the data packet is processed in step 12 and, if necessary, the processed data is passed on to the subordinate unit 4 shown in FIG. 1 for further processing and for voice output.
  • RAS Registration, Admission and Status
  • the main processor 3 processes the corresponding application protocol stack (H.323 USW), the TCP connection, the Internet connection and the interfaces to the network (Ethernet, ATM etc.).
  • the coprocessors process only a reduced part of the protocol stack, for example parts of the Internet (IP) protocol, the "User Datagram” protocol (UDP) and the network interface (e.g. Ethernet).
  • IP Internet
  • UDP User Datagram
  • Ethernet the network interface
  • the actual voice or other real-time data (RTP data) are processed, for example, by a unit downstream of the second processor.
  • FIG. 4 shows the memory management and the transfer of the data packets between the coprocessors 1, 2 and the central processor 3 in more detail.
  • the packet coprocessor 1 comprises a packet memory 15 with a list of descriptors 151, 152, ... to 15N. Each of these descriptors 151, 152,... 15N contains a pointer 25 to a memory area 20, 21 in a memory element 19, for example an SDRAM.
  • the list of descriptors is known to a direct memory access (DMA) unit (not shown) that receives the data.
  • Incoming packets are stored in the corresponding memory areas 20, 21, wherein in the present example the memory areas 20 are occupied with received data packets while the memory area 21 is still free. If a data packet has been completely received and stored in a corresponding memory area 20, this is communicated to the packet coprocessor 1, for example by an interrupt.
  • DMA direct memory access
  • the packet coprocessor 1 then classifies the data packet as described above. If the data packet is classified as the second data packet type is adorned, ie is not a real-time data packet, the data packet is transferred to the main memory 3, as indicated by arrow g. This is done, for example, by transferring the associated descriptor with the pointer to the corresponding memory area. In return, the main processor 3 assigns the packet coprocessor 1 a new free memory area 21, so that there are always enough descriptors and pointers to free memory areas available in the list in the packet memory 15 (arrow h). The communication in the packet coprocessor 1 is carried out by a unit 16.
  • the speech coprocessor 2 contains a stored list 18 with descriptors 181, 182, ..., 18M, which in turn contain pointers 25 on the memory areas 23, 24 assigned to the speech coprocessor 2.
  • the memory areas 23 already contain packets classified by the packet coprocessor 1 as voice data packets, while the memory area 24 is still free.
  • the speech coprocessor 2 now receives a descriptor or pointer to a new speech data packet as described above, in return it sends a pointer 25 to a free memory section back to the packet coprocessor 1 (arrow f). If, as is possible in FIG. 3 in steps 10 and 11, the speech coprocessor notices that the data packet is not a speech data packet, the pointer to the data packet is sent to the
  • the arrows e, f shown in FIG. 4 correspond to communication via the first data path b, while the arrows g, h correspond to communication via the first part c of the second data path and the arrows i, j to communication correspond to the second part d of the second data path.
  • the present invention is not limited to the transmission of voice data, but other real-time data such as video data can also be transmitted. Data for real-time control or monitoring would also be conceivable, for example.

Abstract

Es wird ein Verfahren und eine Vorrichtung zur Verarbeitung von Datenpaketen, welche Echtzeitdatenpakete umfassen, bereitgestellt. Dabei werden die Datenpakete zunächst von einer Koprozessoreinheit (1) in zumindest einen ersten Datenpakettyp, welcher Echtzeitdatenpakete umfasst, und einen zweiten Datenpakettyp klassifiziert. Die Datenpakete des ersten Datenpakettyps werden über einen ersten Datenpfad (b) mit einer weiteren Koprozessoreinheit (2) verarbeitet, während die Datenpakete des zweiten Datenpakettyps über einen zweiten Datenpfad (c, d) verarbeitet werden, welcher eine Hauptprozessoreinheit (3) umfasst. Damit werden Echtzeitdatenpakete verarbeitet, ohne die Hauptprozessoreinheit (3) in Anspruch zu nehmen.

Description

Beschreibung
Verfahren und Vorrichtung zur Verarbeitung von Echtzeitdaten
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zur Verarbeitung von Datenpaketen, welche Echt- zeitdatenpakete umfassen. Insbesondere bezieht sie sich auf ein Verfahren und eine Vorrichtung zur Verarbeitung von Echt- zeitdatenpaketen mit Sprach- oder ähnlichen Kommunikationsda- ten, welche über ein IP-Netzwerk übertragen werden.
Der Übertragung von Echtzeitdaten über Kommunikationsnetzwerke wie beispielsweise dem Internet kommt eine zunehmende Bedeutung zu. Bekanntestes Beispiel hierfür sind so genannte Voice-over-IP-Anwendungen, bei der beispielsweise Sprachdaten übertragen werden, so dass ein Gespräch über das Netzwerk möglich wird. Neben Sprachdaten können derartige Echtzeitdaten auch Videodaten oder dergleichen umfassen.
Herkömmliche Vorrichtungen zum Empfangen oder Senden derartiger Daten benutzen einen einzelnen Datenpfad über einen Hauptprozessor der Vorrichtung. Dieser Hauptprozessor verarbeitet demnach diese Echtzeitdaten. Er ist jedoch auch für eine Vielzahl von anderen Aufgaben und Datenverarbeitungen zuständig, welche in der jeweiligen Vorrichtung, beispielsweise einem Mikrocomputer, anfallen.
Daher sind derartige Vorrichtungen von der Geschwindigkeit und Datenverarbeitungskapazität dieses einzelnen Hauptprozes- sors abhängig. Überlastung des Hauptprozessors kann zu Problemen wie dem Verlust von Datenpaketen, Jitter, Laufzeitschwankungen oder anderen Verzögerungen führen. Dies führt beispielsweise im Fall von Sprachdaten zu einer Verringerung der Qualität der Übertragung und kann schlimmstenfalls zu ei- nein Aussetzen oder einer Unterbrechung der Verbindung führen. Herkömmlicherweise wird durch Verwendung zusätzlicher Protokolle in den Datenpaketen den Echtzeitdatenpaketen eine höhere Priorität bei der Verarbeitung zugewiesen. Dies löst jedoch das prinzipielle Problem einer möglichen Überlastung des Hauptprozessors nicht und führt zumindest zu einer verzögerten Verarbeitung der übrigen Datenpakete. Zudem ist mit dieser Vorgehensweise ein relativ hoher Verarbeitungs- und Implementierungsaufwand verbunden.
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren bzw. eine Vorrichtung bereitzustellen, womit die Verarbeitung von Echtzeitdaten mit großer Zuverlässigkeit ermöglicht wird, was zu einer verbesserten Qualität der Verbindung ("Quality of Service", QoS) führt.
Diese Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1 bzw. eine Vorrichtung nach Anspruch 18. Die ünteransprüche definieren jeweils bevorzugte oder vorteilhafte Ausführungsbeispiele des Verfahrens bzw. der Vorrichtung.
Erfindungsgemäß wird vorgeschlagen, zur Verarbeitung von Datenpaketen, welche Echtzeitdatenpakete umfassen, die Datenpakete in zumindest einen ersten Datenpakettyp, welcher Echtzeitdatenpakete umfasst bzw. diesen zugeordnet ist, und einen zweiten Datenpakettyp zu klassifizieren und die Datenpakete des ersten Datenpakettyps über einen ersten Datenpfad und die Datenpakete des zweiten Datenpakettyps über einen zweiten Datenpfad zu verarbeiten. Der zweite Datenpakettyp kann dabei Datenpakete mit Steuer- oder Signalinformationen, insbesonde- re betreffend die jeweilige Verbindung, umfassen.
Bevorzugt weist der erste Datenpfad eine geringere Verzögerung bei der Verarbeitung oder Übertragung der Datenpakete auf als der zweite Datenpfad. Insbesondere kann der zweite Datenpfad einen Hauptprozessor umfassen, während bei dem ersten Datenpfad eine Verarbeitung der Datenpakete beispielsweise durch Koprozessoren erfolgen kann. Damit wird der Hauptprozessor entlastet, und die Echtzeitda- tenpakete können über den ersten Datenpfad mit geringer Verzögerung verarbeitet werden.
Zur Klassifizierung der Daten können Verbindungsdaten für den Austausch von Echtzeitdatenpaketen mit einer Kommunikationseinrichtung gespeichert werden und die Datenpakete als Datenpakete des ersten Datenpakettyps klassifiziert werden, wenn mindestens ein Teil der Verbindungsdaten des Datenpakets mit den gespeicherten Verbindungsdaten übereinstimmt. Dabei wird ausgenutzt, dass sich derartige Verbindungsdaten im Laufe einer Verbindung nicht oder nur wenig ändern und somit eine Klassifizierung der Datenpakete ermöglichen.
Derartige Verbindungsdaten können eine Netzadresse eines Absenders der Datenpakete oder auch ein Port, auf dem die Datenpakete empfangen werden, sein. Die Klassifizierung der Daten kann dabei durch eine Prozessoreinheit, insbesondere durch einen Koprozessor, erfolgen. Die Speicherverwaltung wird dabei bevorzugt von einer Hauptprozessoreinheit übernommen.
Vorteilhafterweise wird eine Auslastung oder Verfügbarkeit des ersten Datenpfades überwacht, und Pakete des ersten Datenpakettyps werden zur Verarbeitung ausnahmsweise über den zweiten Datenpfad übertragen, wenn die Auslastung des ersten Datenpfades einen vorgegebenen Wert übersteigt bzw. der erste Datenpfad nicht verfügbar ist. Somit wird eine Redundanz ge- schaffen, und bei Störungen oder Ausfällen des hauptsächlich für die Echtzeitdatenpakete vorgesehenen ersten Datenpfades kann der zweite Datenpfad benutzt werden, was eine verlässlichere Verbindung ermöglicht.
Die Echtzeitdatenpakete umfassen beispielsweise Sprachdaten, so dass die Erfindung insbesondere für "Voice over ^"-Anwendungen geeignet ist. Die Erfindung wird im Folgenden unter Bezugnahme auf die beigefügte Zeichnung anhand bevorzugter Ausführungsbeispiele näher erläutert. Es zeigen:
Figur 1 ein Blockschaltbild eines Ausführungsbeispiels einer erfindungsgemäßen Vorrichtung,
Figur 2 eine Veranschaulichung für eine Klassifizierung von Datenpaketen anhand von Verbindungsdaten,
Figur 3 ein Flussdiagramm, welches ein Ausführungsbeispiel für die erfindungsgemäße Klassifizierung von Datenpaketen zeigt, und
Figur 4 ein Blockdiagramm, welches eine mögliche Speicherverwaltung der erfindungsgemäßen Vorrichtung aus Figur 1 darstellt.
In Figur 1 ist ein Ausführungsbeispiel für eine erfindungsgemäße Vorrichtung in Form eines Blockschaltbilds dargestellt. Das Ausführungsbeispiel behandelt dabei den Empfang von Datenpaketen aus einem (nicht dargestellten) Kommunikations- netzwerk wie beispielsweise dem Internet. Eine entsprechende Vorrichtung wäre auch für das Senden von Daten möglich.
Eingehende Datenpakete, welche Echtzeitdatenpakete umfassen, werden dabei über einen Datenpfad a empfangen und an einen Koprozessor 1, im Folgenden als Paketkoprozessor bezeichnet, geleitet. In diesem Paketkoprozessor 1 werden die eingehenden Datenpakete untersucht und in zumindest zwei Datenpakettypen klassifiziert, wobei Echtzeitdatenpakete dem ersten Datenpa- kettyp zugeordnet werden. Andere Datenpakete, welche beispielsweise Steuersignale für eine Verbindung, über die die. Datenpakete empfangen werden, umfasst, werden einem zweiten Datenpakettyp zugeordnet. Auf geeignete Kriterien für diese Klassifizierung wird nachfolgend noch näher eingegangen. Datenpakete des ersten Datenpakettyps, also Echtzeitdatenpa- kete wie beispielsweise Datenpakete mit Sprachdaten, werden über einen ersten Datenpfad b an einen weiteren Koprozessor 2 zur Verarbeitung geschickt, im Fall von Sprachdaten ein Sprachkoprozessor . Dieser kann nochmals überprüfen, ob es sich tatsächlich um die gewünschten Echtzeitdaten handelt. Wenn dies der Fall ist, kann der Koprozessor 2 das Datenpaket verarbeiten und beispielsweise die Sprachdaten über einen Da- tenpfad e an eine nachgeordnete Einheit 4 zur Verarbeitung und Ausgabe dieser Sprachdaten weiterleiten.
Datenpakete des zweiten Datenpakettyps werden über einen ersten Teil c eines zweiten Datenpfades an einen Hauptprozessor 3 ("Central Processing Unit", CPU) zur Verarbeitung weitergeleitet. Dieser zweite Datenpfad kann einen zweiten Teil d beinhalten, mit denen auch der weitere Koprozessor 2 Datenpakete an den Hauptprozessor 3 schicken kann, wenn erkannt wird, dass es sich nicht um die gewünschten Echtzeitdatenpa- kete handelt.
Mittels des ersten Datenpfades b können somit eingehende Echtzeitdatenpakete ohne Zuhilfenahme des Hauptprozessors 3 allein von den Koprozessoren 1 und 2 verarbeitet werden. Dies entlastet zum einen den Hauptprozessor und ermöglicht zum anderen eine schnellere Verarbeitung der Daten und somit eine Verringerung von Verzögerungen im Datenfluss, da der erste Datenpfad b nur für diese Echtzeitdatenpakete verwendet wird.
Zusätzlich kann die Verfügbarkeit des ersten Datenpfads b ü- berwacht werden. Wenn sich herausstellt, dass der erste Datenpfad b beispielsweise wegen Überlastung oder wegen einer Unterbrechung nicht verfügbar ist, können auch Datenpakete des ersten Datenpakettyps, also Echtzeitdatenpakete, über den zweiten Datenpfad c zur Hauptprozessoreinheit und dann weiter über die Pfade d und e zur nachgeordneten Einheit 4 geleitet werden. Damit ist ein Funktionieren des Systems auch für den Fall sichergestellt, dass der erste Datenpfad b nicht verfügbar ist (Redundanz) .
In Figur 2 ist beispielhaft die Klassifizierung von Datenpa- keten anhand von so genannten Headerparametern, d.h. Parametern, welche Informationen über eine Verbindung in einem Kommunikationsnetzwerk beinhalten, dargestellt. Derartige Headerparameter werden in einem Datenpaket den eigentlichen Daten vorangestellt und bleiben im Verlauf einer Verbindung im Wesentlichen unverändert. Wenn eine Verbindung beispielsweise zum Empfangen von Sprachdaten initialisiert wird, werden diese Headerparameter 5 einmal von der Hauptprozessoreinheit 3 festgelegt.
Beim Einrichten der Verbindung wird dabei in einer Vorrichtung, welche beispielsweise nach dem H.323-Standard arbeitet, von dem Hauptprozessor 3 folgende Schritte ausgeführt:
1. Registrierung, Zulassung und Status (Registration, Admis- sion and Status, RAS). Dabei registriert sich ein H.323-
Client bei einer Verwaltungseinheit (Gatekeeper) , welcher für die entsprechende Netzwerkzone zuständig ist (beispielsweise durch ein IP-Multicast mittels eines UDP ("User Datagram Pro- tocol") -Protokolls) und bittet um Erlaubnis für die Einrich- tung der Verbindung.
2. Dann wird eine TCP ("Transmission Control Protocol") -Verbindung an den entsprechenden (den angerufenen) H.323-Server aufgebaut. Der Aufbau eines Anrufs wird über ein H.225.0-Pro- tokoll (ähnlich einem Q.931-Anrufaufbau) über die TCP-Verbindung bewerkstelligt.
3. Der Aufbau der logischen Kanäle zwischen Anrufer und Angerufenem erfolgt dann wiederum über TCP gemäß dem H.245- Standard. Im vorliegenden Beispiel beinhalten die dabei generierten Headerparameter 5 Ethernetheaderparameter 5A, welche Parameter einer Ethernetverbindung beispielsweise in einem LAN beinhalten, IP-Headerparameter 5B, welche Informationen über die Verbindung zu einem IP-Netzwerk wie dem Internet beinhalten, und UDP-Headerparameter 5C, welche Informationen über das "User Datagram"-Protokoll, -welches typischerweise zum Versenden von Sprachdaten benutzt wird, enthält. Diese Headerparameter 5 werden über die beiden Teile des zweiten Da- tenpfades c, d an die Koprozessoren 1 und 2 geschickt und dort zu Referenzzwecken abgespeichert. Ein Datenpaket 6, welches über den Datenpfad a empfangen wird, enthält ebenfalls derartige Headerparameter 6A, 6B, 6C und zudem die eigentlichen Daten 6D, im Fall von Sprachdaten RTP ("Real Time Proto- col") -Echtzeitsprachdaten.
Die Headerparameter βA, 6B, 6C werden mit den entsprechenden abgespeicherten Headerparametern 5A, 5B, 5C verglichen. Wenn die Parameter derart übereinstimmen, dass sichergestellt wer- den kann, dass die Daten aus der entsprechenden Verbindung zum Empfangen von Sprachdaten stammen, wird das Datenpaket 6 als erster Datenpakettyp klassifiziert und über den ersten Datenpfad b and den weiteren Koprozessor 2 weitergegeben. Dieser kann die Klassifizierung noch fortführen, insbesondere beim Verarbeiten der Daten. Falls sich bei der Klassifizierung in dem Paketkoprozessor 1 oder in dem Sprachkoprozessor 2 ergeben sollte, dass es sich nicht um Sprachdaten handelt, wird das Datenpaket an den Hauptprozessor 3 übergeben. Andernfalls wird es von dem Sprachkoprozessor 2 verarbeitet.
In Figur 3 ist diese Klassifizierung anhand eines Flussdiagramms detailliert dargestellt. In einem ersten Schritt 7 wird überprüft, ob der Port, auf dem das Datenpaket empfangen wurde, der für die jeweilige Verbindung zum Empfangen von Sprachdaten vorgesehene Port ist. Dies ist insbesondere dann wichtig, wenn mehrere Verbindungen gleichzeitig aktiv sind. Wenn ja (J) , wird zum nächsten Schritt 8 übergegangen, wenn nein (N) , wird zu Schritt 13 übergegangen, in dem das entsprechende Datenpaket an die Hauptprozessoreinheit 3 übergeben wird.
Im nächsten Schritt 8 wird überprüft, ob im Ethernetheader 6A der richtige Verbindungstyp, beispielsweise IP, für die jeweilige Verbindung angegeben ist. Falls ja, wird zu Schritt 9 übergegangen, falls nein, wiederum zu Schritt 13.
In Schritt 9 wird überprüft, ob die Ziel-IP-Adresse des empfangenen Datenpakets mit der entsprechenden für die Verbindung vorgesehenen IP-Adresse übereinstimmt. Falls nein, wird wiederum zu Schritt 13 übergegangen. Diese ersten drei Klassifizierungsschritte 7 bis 9 werden beispielsweise in dem Pa- ketkoprozessor 1 durchgeführt. Sie erlauben eine Klassifizierung auf niedriger Ebene, indem nur elementare Kommunikationsparameter überprüft werden.
Falls sich bei Schritt 9 eine Übereinstimmung ergibt, wird das Datenpaket an den Sprachkoprozessor 2 zur weiteren Behandlung übergeben. Dort wird in Schritt 10 überprüft, ob das Protokoll des empfangenen Datenpakets ein UDP-Protokoll ist. Falls nein, wird zu Schritt 14 übergegangen, was bedeutet, dass das Datenpaket wiederum an den Hauptprozessor 3 überge- ben wird. Falls ja, wird zu Schritt 11 übergegangen. Hier wird überprüft, ob der UDP-Port der Port für Sprachdatenempfang ist. Dies wird benutzt, um zwischen so genannten RAS ("Registration, Admission and Status")- und Sprachdatenpaketen zu unterscheiden. Falls nein, wird wiederum zu Schritt 14 übergegangen. Falls ja, wird in Schritt 12 das Datenpaket verarbeitet und gegebenenfalls die verarbeiteten Daten an die in Figur 1 gezeigte nachgeordnete Einheit 4 zur weiteren Verarbeitung und zur Sprachausgabe weitergegeben. Die Aufteilung ■ der Schritte 7 bis 11 zwischen dem Paketkoprozessor 1 und dem Sprachkoprozessor 2 ist dabei prinzipiell beliebig. In der nachgeordneten Einheit 4 kann dabei beispielsweise die tatsächliche Verarbeitung der Sprachdaten vorgenommen werden, während im Sprachkoprozessor 2 im Wesentlichen das UDP-Proto- koll abgearbeitet wird.
Insgesamt verarbeitet bei einer derartigen Vorrichtung der Hauptprozessor 3 dabei die entsprechenden Anwendungsprotokollstapel (H.323 USW), die TCP-Verbindung, die Internetverbindung und die Schnittstellen zum Netzwerk (Ethernet, ATM etc.). Die Koprozessoren verarbeiten zur Klassifizierung nur einen reduzierten Teil des Protokollstapels, beispielsweise Teile des Internet (IP) -Protokolls, des "User Datagram"- Protokolls (UDP) und der Netzwerkschnittstelle (z.B. Ethernet) . Die eigentlichen Sprach- oder anderen Echtzeitdaten (RTP-Daten) werden beispielsweise von einer dem zweiten Ko- prozessor nachgeordneten Einheit verarbeitet.
In Figur 4 ist die Speicherverwaltung und die Übergabe der Datenpakete zwischen den Koprozessoren 1, 2 und dem Zentral- prozessor 3 genauer dargestellt.
Dabei umfasst der Paketkoprozessor 1 einen Paketspeicher 15 mit einer Liste von Deskriptoren 151, 152, ... bis 15N. Jeder dieser Deskriptoren 151, 152, ... 15N enthält einen Zeiger 25 auf einen Speicherbereich 20, 21 in einem Speicherelement 19, beispielsweise einem SDRAM. Die Liste von Deskriptoren ist einer (nicht dargestellten) DMA("Direct Memory Access") -Einheit, welche die Daten in Empfang nimmt, bekannt. Eingehende Pakete werden in den entsprechenden Speicherbereichen 20, 21 abgespeichert, wobei im vorliegenden Beispiel die Speicherbereiche 20 mit eingegangenen Datenpaketen belegt sind, während der Speicherbereich 21 noch frei ist. Ist ein Datenpaket vollständig empfangen und in einem entsprechenden Speicherbereich 20 abgespeichert, wird dies dem Paketkoprozessor 1 bei- spielsweise durch einen Interrupt mitgeteilt. Der Paketkoprozessor 1 klassifiziert das Datenpaket dann wie oben beschrieben. Wenn das Datenpaket als zweiter Datenpakettyp klassifi- ziert wird, d.h. kein Echtzeitdatenpaket ist, wird das Datenpaket an den Hauptspeicher 3 übergeben, wie durch Pfeil g angedeutet. Dies geschieht beispielsweise, indem der zugehörige Deskriptor mit dem Zeiger auf den entsprechenden Speicherbe- reich übergeben wird. Im Gegenzug weist der Hauptprozessor 3 dem Paketkoprozessor 1 einen neuen freien Speicherbereich 21 zu, so dass in der Liste in dem Paketspeicher 15 immer genügend Deskriptoren und Zeiger auf freie Speicherbereiche zur Verfügung stehen (Pfeil h) . Die Kommunikation im Paketkopro- zessor 1 wird dabei durch eine Einheit 16 durchgeführt.
Falls es sich hingegen um ein Datenpaket des ersten Datenpa- kettyps, also um ein Echtzeitdatenpaket handelt, wird der entsprechende Zeiger auf das Datenpaket an den Sprachkopro- zessor 2 übergeben, wie durch Pfeil e dargestellt. Im Sprachprozessor 2 ist dabei analog zum Paketkoprozessor 1 eine Einheit 17 zur Kommunikation vorgesehen. Weiterhin enthält der Sprachkoprozessor 2 eine gespeicherte Liste 18 mit Deskriptoren 181, 182, ..., 18M, welche wiederum Zeiger 25 auf dem Sprachkoprozessor 2 zugeordnete Speicherbereiche 23, 24 enthalten. Die Speicherbereiche 23 enthalten dabei bereits vom Paketkoprozessor 1 als Sprachdatenpakete eingestufte Pakete, während der Speicherbereich 24 noch frei ist. Erhält der Sprachkoprozessor 2 nun wie oben beschrieben einen Deskriptor bzw. Zeiger auf ein neues Sprachdatenpaket, schickt er im Gegenzug einen Zeiger 25 auf einen freien Speicherabschnitt an den Paketkoprozessor 1 zurück (Pfeil f) . Wenn, wie in Figur 3 bei den Schritten 10 und 11 möglich, der Sprachkoprozessor bemerkt, dass es sich bei dem Datenpaket um kein Sprachdaten- paket handelt, wird der Zeiger auf das Datenpaket an den
Hauptprozessor 3 übergeben und im Gegenzug ein Zeiger auf einen freien Speicherbereich erhalten, wie durch die Pfeile i und j dargestellt.
Zu beachten ist, dass dabei bei der durch die Pfeile e und f angedeuteten Kommunikation lediglich Zeiger auf Speicherbereiche ausgetauscht werden, welche zuvor vom Hauptprozessor den jeweiligen Koprozessoren zugeordnet wurden. Die Koprozes- soren können demnach nicht selbstständig Speicherbereiche freigeben, sondern erhalten eine gewisse Liste von Speicherbereichen von dem Hauptprozessor 3 zugewiesen.
Wie aus der vorhergehenden Beschreibung hervorgeht, entsprechen die in Figur 4 gezeigten Pfeile e, f einer Kommunikation über den ersten Datenpfad b, während die Pfeile g, h einer Kommunikation über den ersten Teil c des zweiten Datenpfads und die Pfeile i, j einer Kommunikation über den zweiten Teil d des zweiten Datenpfads entsprechen.
Es sei nochmals darauf hingewiesen, dass diese genaue Ausführung der Speicherverwaltung lediglich ein Beispiel darstellt. Auch andere Architekturen sind hier möglich. Zudem ist die vorliegende Erfindung nicht auf die Übertragung von Sprachdaten beschränkt, sondern es können auch andere Echtzeitdaten wie beispielsweise Videodaten übertragen werden. Denkbar wären beispielsweise auch Daten zur Echtzeitsteuerung oder -Überwachung.

Claims

Patentansprüche
1. Verfahren zur Verarbeitung von Datenpaketen (6), welche Echtzeitdatenpakete umfassen, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete (β) in zumindest einen ersten Datenpa- kettyp, welcher Echtzeitdatenpaketen zugeordnet ist, und einen dazu unterschiedlichen zweiten Datenpakettyp klassifiziert werden, dass die Datenpakete des ersten Datenpakettyps über einen ersten Datenpfad (b) verarbeitet werden, und dass die Datenpakete des zweiten Datenpakettyps über einen zweiten (c, d) Datenpfad verarbeitet werden.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass der zweite Datenpakettyp Datenpaketen mit Steuer- oder
Signalinformationen zugeordnet ist.
3. Verfahren nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t, dass der erste Datenpfad (b) eine geringere Verzögerung bei der Verarbeitung von Datenpaketen als der zweite Datenpfad (c, d) aufweist.
4. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass Verbindungsdaten (5A, 5B, 5C) für den Austausch von Echtzeitdatenpaketen mit einer Kommunikationseinrichtung ge- speichert werden und die Datenpakete (6) als Datenpakete des ersten Datenpakettyp klassifiziert werden, wenn mindestens ein Teil der Verbindungsdaten (6A, 6B, 6C) der Datenpakete (6) mit den gespeicherten Verbindungsdaten (5A, 5B, 5C) übereinstimmt .
5. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete (6) anhand eines Ports, auf dem sie empfangen werden, klassifiziert werden.
6. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete (6) anhand einer in den Datenpaketen enthaltenen Netzadresse klassifiziert werden.
7. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete (6) als Echtzeitdatenpakete klassifiziert wird, wenn sie ein für die Übertragung von Echtzeitdaten vorgesehenes Protokoll enthalten.
8. Verfahren nach Anspruch 7, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete (6) als Echtzeitdatenpakete klassifiziert werden, wenn das für die Übertragung von Echtzeitdaten vorgesehene Protokoll auf einen Echtzeitdatenport für den Empfang dieser Datenpakete verweist.
9. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete (6) des ersten Datenpakettyps über den ersten Datenpfad (β) an eine erste Prozessoreinheit (2) zum Verarbeiten der Echtzeitdatenpakete übertragen werden, und dass die Datenpakete des zweiten Datenpakettyps über den zweiten Datenpfad (c, d) an eine zweite Prozessoreinheit (3) zum Verarbeiten übertragen werden.
10. Verfahren nach Anspruch 9, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete zumindest teilweise in einer dritten Prozessoreinheit (1) klassifiziert und abhängig von der Klas- sifizierung an die erste Prozessoreinheit (2) oder die zweite Prozessoreinheit (3) übertragen werden.
11. Verfahren nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t, dass die zweite Prozessoreinheit (3) eine Hauptprozessoreinheit und die ersten und dritten Prozessoreinheiten (1, 2) Ko- prozessoreinheiten sind.
12. Verfahren nach Anspruch 11, d a d u r c h g e k e n n z e i c h n e t, dass die Hauptprozessoreinheit (3) den Koprozessoreinheiten (1, 2) Speicherbereiche zum Speichern von Datenpaketen zuweist.
13. Verfahren nach Anspruch 11 oder 12, d a d u r c h g e k e n n z e i c h n e t, dass die Klassifizierung zeitlich in mehreren Stufen (7, 8, 9, 10, 11) erfolgt und nach jeder Stufe die Datenpakete (6) zum Verarbeiten an die Hauptprozessoreinheit (3) übertragen werden, wenn sie als Datenpakete des zweiten Datenpakettyps klassifiziert worden sind.
14. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass eine Verfügbarkeit des ersten Datenpfades (b) geprüft wird, und dass die als Datenpakete des ersten Datenpakettyps klassifizierte Datenpakete zur Verarbeitung über den zweiten Datenpfad (c, d) übertragen werden, wenn die Verfügbarkeit des ersten Datenpfades (b) unzureichend ist.
15. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass eine Auslastung des ersten Datenpfades (b) gemessen wird und die als Datenpakete des ersten Datenpakettyps klassifizierte Datenpakete zur Verarbeitung über den zweiten Daten- pfad (c, d) übertragen werden, wenn die Auslastung des ersten Datenpfades einen vorgegebenen Wert übersteigt.
16. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Datenpakete (6) über ein IP-Übertragungsnetzwerk empfangen werden.
17. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Echtzeitdatenpakete Sprachdaten umfassen.
18. Vorrichtung zur Verarbeitung von Datenpaketen (6), welche Echtzeitdatenpakete umfassen, g e k e n n z e i c h n e t durch
Mittel (1) zur Klassifizierung der Datenpakete (6), welche derart ausgestaltet sind, dass sie die Datenpakete in zumin- dest einen ersten Datenpakettyp, welcher Echtzeitdatenpaketen zugeordnet ist, und einen dazu unterschiedlichen zweiten Datenpakettyp klassifizieren, einen ersten Datenpfad (b) zur Verarbeitung der Datenpakete des ersten Datenpakettyps, und einen zweiten Datenpfad (c, d) zur Verarbeitung der Datenpakete des zweiten Datenpakettyps .
19. Vorrichtung nach Anspruch 18, d a d u r c h g e k e n n z e i c h n e t, dass der zweite Datenpfad (c, d) eine Hauptprozessoreinheit (3) umfasst.
20. Vorrichtung nach Anspruch 18 oder 19, d a d u r c h g e k e n n z e i c h n e t, dass der erste Datenpfad (b) eine erste Koprozessoreinheit
(2) zum Verarbeiten der Datenpakete des ersten Datenpakettyps umfasst.
21. Vorrichtung nach einem der Ansprüche 18 bis 20, d a d u r c h g e k e n n z e i c h n e t, dass die Mittel zur Klassifizierung der Datenpakete eine zweite Koprozessoreinheit (1) umfassen.
22. Vorrichtung nach Anspruch 19, 20 und 21, d a d u r c h g e k e n n z e i c h n e t, dass die erste Koprozessoreinheit (2) über den ersten Daten- pfad (b) mit der ersten Koprozessoreinheit (1) und über den zweiten Datenpfad (b, c) mit der zweiten Koprozessoreinheit (1) verbunden ist.
23. Vorrichtung nach Anspruch 22, d a d u r c h g e k e n n z e i c h n e t, dass sowohl die erste (2) als auch die zweite (1) Koprozessoreinheit derart ausgestaltet sind, dass sie Mittel zur Klassifizierung der Datenpakete (β) in zumindest den ersten Datenpakettyp und den zweiten Datenpakettyp umfassen, wobei die Klassifizierungen in der ersten Koprozessoreinheit (2) und in der zweiten Koprozessoreinheit (1) anhand unterschiedlicher Kriterien erfolgen, und dass die ersten und zweiten Koprozessoreinheiten (1, 2) derart ausgestaltet sind, dass sie Datenpakete des zweiten Da- tenpakettyps an die Hauptprozessoreinheit (3) zur Verarbeitung übergeben.
24. Vorrichtung nach einem der Ansprüche 18 bis 23, d a d u r c h g e k e n n z e i c h n e t, dass die Vorrichtung zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 17 ausgestaltet ist.
PCT/EP2004/006080 2003-06-18 2004-06-04 Verfahren und vorrichtung zur verarbeitung von echtzeitdaten WO2004112341A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/545,917 US7969982B2 (en) 2003-06-18 2004-06-04 Method and device for processing real-time data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10327545.2 2003-06-18
DE10327545A DE10327545B4 (de) 2003-06-18 2003-06-18 Verfahren und Vorrichtung zur Verarbeitung von Echtzeitdaten

Publications (2)

Publication Number Publication Date
WO2004112341A2 true WO2004112341A2 (de) 2004-12-23
WO2004112341A3 WO2004112341A3 (de) 2005-03-31

Family

ID=33520712

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/006080 WO2004112341A2 (de) 2003-06-18 2004-06-04 Verfahren und vorrichtung zur verarbeitung von echtzeitdaten

Country Status (4)

Country Link
US (1) US7969982B2 (de)
CN (1) CN100544311C (de)
DE (1) DE10327545B4 (de)
WO (1) WO2004112341A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100428738C (zh) * 2005-09-21 2008-10-22 华为技术有限公司 无连接的分组交换通信系统

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5381194B2 (ja) * 2009-03-16 2014-01-08 富士通株式会社 通信プログラム、中継ノード、および通信方法
US8787381B2 (en) * 2011-06-08 2014-07-22 Broadcom Corporation Quality of service, battery lifetime, and latency in wireless communication devices
CN102984285A (zh) * 2011-09-07 2013-03-20 启碁科技股份有限公司 通信装置、数据处理方法及路由模块
US20150261721A1 (en) * 2014-03-13 2015-09-17 Lantiq Deutschland Gmbh Flow control between processing devices

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999065196A1 (en) * 1998-06-10 1999-12-16 Merlot Communications, Inc. Integrated voice and data communications over a local area network
US20020191543A1 (en) * 2001-05-04 2002-12-19 Terago Communications, Inc. System and method for policing multiple data flows and multi-protocol data flows
EP1280297A2 (de) * 2001-07-23 2003-01-29 Primary Network, Inc. d/b/a Acme Packet, Inc. System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6584108B1 (en) * 1998-09-30 2003-06-24 Cisco Technology, Inc. Method and apparatus for dynamic allocation of multiple signal processing resources among multiple channels in voice over packet-data-network systems (VOPS)
US6449650B1 (en) * 1999-02-01 2002-09-10 Redback Networks Inc. Methods and apparatus for deploying quality of service policies on a data communication network
US6594268B1 (en) * 1999-03-11 2003-07-15 Lucent Technologies Inc. Adaptive routing system and method for QOS packet networks
US6678246B1 (en) * 1999-07-07 2004-01-13 Nortel Networks Limited Processing data packets
ES2557892T3 (es) * 1999-07-15 2016-01-29 Telefonaktiebolaget Lm Ericsson (Publ) Control de admisión y planificación de tráfico de datos por paquetes
US6570849B1 (en) * 1999-10-15 2003-05-27 Tropic Networks Inc. TDM-quality voice over packet
DE10058524A1 (de) * 2000-11-24 2002-06-13 Siemens Ag System und Verfahren zur parallelen Übertragung von echtzeitkritischen und nicht echtzeitkritischen Daten über schaltbare Datennetze, insbesondere Ethernet
US6904040B2 (en) * 2001-10-05 2005-06-07 International Business Machines Corporaiton Packet preprocessing interface for multiprocessor network handler
US20030152065A1 (en) * 2002-02-08 2003-08-14 Institute For Information Industry Integrated IP network telephone distributor with switching and routing functions
US7385997B2 (en) * 2002-04-08 2008-06-10 International Business Machines Corporation Priority based bandwidth allocation within real-time and non-real-time traffic streams
KR100608904B1 (ko) * 2003-12-18 2006-08-04 한국전자통신연구원 서비스 품질 보장을 위한 시스템 및 방법
TWI241807B (en) * 2004-03-02 2005-10-11 Hon Hai Prec Ind Co Ltd System and method for network quality of service
JP4570981B2 (ja) * 2005-02-23 2010-10-27 株式会社エヌ・ティ・ティ・ドコモ 移動通信システムおよびパケットデータ転送制御方法
JP2006261935A (ja) * 2005-03-16 2006-09-28 Nec Corp パケット伝送方法および装置
US20080119165A1 (en) * 2005-10-03 2008-05-22 Ajay Mittal Call routing via recipient authentication
US7649886B2 (en) * 2005-11-21 2010-01-19 Motorola, Inc. Method and system for processing incoming packets in a communication network
US7668161B2 (en) * 2006-07-27 2010-02-23 Cisco Technology, Inc. Classifying data packet protocol values

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999065196A1 (en) * 1998-06-10 1999-12-16 Merlot Communications, Inc. Integrated voice and data communications over a local area network
US20020191543A1 (en) * 2001-05-04 2002-12-19 Terago Communications, Inc. System and method for policing multiple data flows and multi-protocol data flows
EP1280297A2 (de) * 2001-07-23 2003-01-29 Primary Network, Inc. d/b/a Acme Packet, Inc. System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100428738C (zh) * 2005-09-21 2008-10-22 华为技术有限公司 无连接的分组交换通信系统

Also Published As

Publication number Publication date
DE10327545B4 (de) 2005-12-01
US20070165637A1 (en) 2007-07-19
US7969982B2 (en) 2011-06-28
CN1809995A (zh) 2006-07-26
CN100544311C (zh) 2009-09-23
WO2004112341A3 (de) 2005-03-31
DE10327545A1 (de) 2005-01-13

Similar Documents

Publication Publication Date Title
EP2882144B1 (de) Verfahren und Filteranordnung zum Filtern von über einen seriellen Datenbus eines Kommunikationsnetzwerks in einem Teilnehmer des Netzwerks eingehenden Nachrichten
DE69927457T2 (de) Verfahren und Vorrichtung zur Cache-Speicherung von Informationen im Netzwerk
DE60109060T2 (de) Interkommunikationsvorprozessor
DE60303384T2 (de) Lastausgleich in datennetzwerken
DE102019210229A1 (de) Verfahren und Vorrichtung zur Analyse dienste-orientierter Kommunikation
WO2020108998A1 (de) Verteilerknoten, automatisierungsnetzwerk und verfahren zum übertragen von telegrammen
DE10327545B4 (de) Verfahren und Vorrichtung zur Verarbeitung von Echtzeitdaten
EP3668051A1 (de) Verfahren zur datenübertragung, kommunikationsgerät, com-puterprogramm und computerlesbares medium
DE10045205A1 (de) Verfahren zum Aufbau von Verbindungen mit vorgegebener Dienstgüte für ein paketorientiertes Kommunikationsnetz mit einem Resourcenmanager
DE60313026T2 (de) Verfahren und gerät zur verteilung von datenpaketen von einem computer zu einem clustersystem
DE60207687T2 (de) Verfahren und vorrichtung zum klassifizieren von abfrageknoten
EP1623559B1 (de) Verfahren zum datenaustausch zwischen netzelementen in netzwerken mit verschiedenen adressbereichen
DE102019125545B3 (de) Datenübertragungsverfahren, segment-telegramm und automatisierungskommunikationsnetzwerk
EP1180888B1 (de) Verfahren zum Aufbauen einer Datenverbindung zwischen einer ersten und einer zweiten Recheneinheit und Vorrichtung zum Austauschen von Daten
DE60109027T2 (de) Verfahren und system zur steuerung von datenströmen in teil-datenstrom-bündeln von computernetzwerken
DE102019207579A1 (de) Verfahren und Vorrichtung zum Überwachen von Datenaustausch in einem Kommunikationssystem
EP1358735B1 (de) Einheit zur verteilung und verarbeitung von datenpaketen
WO2019145102A1 (de) Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium
DE102019210230A1 (de) Vorrichtung und Verfahren für Angriffserkennung in einem Rechnernetzwerk
WO2006061394A1 (de) Aggregation der inter-domain ressourcen-signalisierung
EP4170977A1 (de) Verfahren zum überwachen eines datennetzwerks in einem kraftfahrzeug sowie switchvorrichtung und kraftfahrzeug
DE10055066A1 (de) Verfahren zum multidirektionalen Austausch von Informationen zwischen Teilnehmern auf Ethernet Basis
WO2022090064A1 (de) Verfahren zum überwachen eines datennetzwerks in einem kraftfahrzeug sowie switchvorrichtung und kraftfahrzeug
WO2022090065A1 (de) Verfahren zum überwachen eines datenverkehrs zwischen steuergeräten eines kraftfahrzeugs sowie entsprechend ausgestattetes kraftfahrzeug
EP1059788B1 (de) Verfahren und Anordnung zur Übertragungsaufbereitung von Echtzeitdaten

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 20048169796

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2007165637

Country of ref document: US

Ref document number: 10545917

Country of ref document: US

122 Ep: pct application non-entry in european phase
WWP Wipo information: published in national office

Ref document number: 10545917

Country of ref document: US