DE69932184T2 - Verfahren und vorrichtung zur reduzierung der verarbeitungszeit von daten in kommunikationsnetzwerken - Google Patents

Verfahren und vorrichtung zur reduzierung der verarbeitungszeit von daten in kommunikationsnetzwerken Download PDF

Info

Publication number
DE69932184T2
DE69932184T2 DE69932184T DE69932184T DE69932184T2 DE 69932184 T2 DE69932184 T2 DE 69932184T2 DE 69932184 T DE69932184 T DE 69932184T DE 69932184 T DE69932184 T DE 69932184T DE 69932184 T2 DE69932184 T2 DE 69932184T2
Authority
DE
Germany
Prior art keywords
data
protocol layer
data packets
protocol
packets
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Lifetime
Application number
DE69932184T
Other languages
English (en)
Other versions
DE69932184D1 (de
Inventor
Reiner Ludwig
Bela Rathonyi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE69932184D1 publication Critical patent/DE69932184D1/de
Application granted granted Critical
Publication of DE69932184T2 publication Critical patent/DE69932184T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

  • Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Verbessern der Verarbeitungszeit von empfangenen Daten in paketorientierten Anwendungen in der Übertragung über Kommunikationsnetzwerke, insbesondere über ein IP-Netzwerk und ein mobiles Kommunikationsnetzwerk, wie beispielsweise das Global System for Mobile Communication (GSM), das Universal Mobile Telecommunications System (UMTS) oder den General Packet Radio Service (GPRS).
  • In US-A-4 703 475 wird das Problem der Minimierung einer Nachrichtenverzögerung durch Verteilen von Nachrichtenpaketen über eine Anzahl von physikalischen Leitungen und die Neuordnung von empfangenen Paketen auf einer Nachrichtenbasis erörtert, wobei eine Nachricht zu einem logischen Kanal zugewiesen wird. Zu diesem Zweck weist eine Kommunikationssteuerungsschicht die empfangene Nachricht zu einem verfügbaren logischen Kanal zu und übergibt die Nachricht an die Paketebene, welche die Nachricht in Datenpakete aufschlüsselt und einen Header hinzufügt, der die Informationen über die zugewiesene Nummer des logischen Kanals enthält. Eine zusätzliche Mehrfachleitungsebene wird eingeführt, um einen Mehrfachleitungs-Header mit einer Sequenznummer eines logischen Kanals hinzuzufügen, welcher die Reihenfolge der Datenpakete in dem logischen Kanal definiert. Auf diese Weise erstellte Datenpakete werden über ein Netzwerk übertragen. Am Empfänger werden die empfangenen Datenpakete nach der Nummer des logischen Kanals und der Folgenummer des logischen Kanals sortiert und an die Paketschicht übergeben, wenn die richtige Reihenfolge in dem bestimmten logischen Kanal erreicht worden ist.
  • Das Dokument "Packet reassembly during cell loss" von G.J. Armitage und K.M. Adams in IEEE Network: The magazine of Computer Communications, Band 7, Br. 5, 1. September 1993, Seite 26–34, lehrt, wie die Datenpakete einer höheren Protokollschicht aus den empfangenen Daten einer niedrigeren Protokollschicht wieder zusammengesetzt werden. Zu diesem Zweck wird auf der Senderseite ein Datenpaket in kleinere Datenpakete (Zellen) segmentiert, und jede Zelle erhält einen Header mit einem Eintrag über die tragende Informationsart, die von den Datenpaketen der höheren Protokollschicht empfangen wird. Die Informationen können der Anfang der Nachricht (BOM), die Fortsetzung der Nachricht (COM) oder das Ende der Nachricht (EOM) sein. Zusätzlich wird ein MID-Eintrag in jede Zelle eingefügt, um die Entsprechung zu einem Paket einer höheren Ebene zu erkennen. Auf der Basis dieser Informationen wird ein Datenpaket einer höheren Schicht auf der Empfängerseite wieder zusammengesetzt, wobei COM- oder EOM-Zellen mit MID-Wert, die nicht einem gegenwärtig wieder zusammengesetzten Paket entsprechen, ignoriert werden. Die Zusammensetzungsprozedur wird abgebrochen, wenn ein Paket außerhalb der Reihenfolge empfangen wird, Dies wird erkannt, wenn die Folgenummer nicht die nächstfolgende ist.
  • Ein Protokoll wird definiert als eine Gesamtheit von Deklarationen zwischen Partner-Instanzen zum Zweck einer gemeinsamen Kommunikation. Daher ist ein gemeinsames bindendes Protokoll eine Voraussetzung für einen Datenaustausch zwischen zwei kommunizierenden Netzwerkknoten. Es ist erforderlich, dass die Protokolle universal und untereinander kompatibel definiert werden, denn nur auf einer einheitlichen Basis lassen sich verschiedene Netzwerke miteinander in Reihe verbinden, um auch über die Grenzen eines Systems hinaus zu kommunizieren.
  • Hinsichtlich einer modularen Struktur ist das gesamte Protokoll einer Kommunikation in Schichten unterteilt.
  • Jede Schicht löst die Aufgaben, die ihr mittels eines eigenen Protokolls zugewiesen sind. Eine Kommunikation zwischen benachbarten Schichten wird über klar definierte Schnittstellen gewährleistet. In diesem Fall ist eine Schicht n mit der Schicht n + 1, die direkt darüber liegt, indem sie Dienste für die Schicht erbringt, und mit der Schicht n – 1, die direkt unter der Schicht liegt, indem die Dienste der Schicht verwendet werden, verbunden. Des Weiteren besteht eine Kommunikation mit der Schicht n des Kommunikationspartners, indem die Dienste aller unteren Schichten verwendet werden. Somit wird der logische Datenfluss von Protokolldateneinheiten PDU auf jeweils einer Protokollschicht ausgeführt. Auf der Empfängerseite werden die Daten in einer umgekehrten Reihenfolge verarbeitet, d.h. die Daten werden von den unteren Schichten an die direkt darüber liegenden Protokollschichten freigegeben.
  • Die Struktur des Protokollstapels kann in Reaktion auf das physikalische Netzwerk und die Anwendung unterschiedlich ausfallen. Die Abweichung muss jedoch innerhalb der kompatiblen Grenzen liegen, um die Kommunikation zwischen verschiedenen Netzwerken zu gewährleisten. Der standardisierte Protokollstapel für Internet-Anwendungen ist der PCP/IP- (Transmission Control Protocoll/Internet Protocol) Protokollstapel. Er besteht aus vier Schichten. Die oberste Schicht – die Anwendungsschicht – umfasst Anwendungsprotokolle. Ein Transportprotokoll, zum Beispiel das so genannte TCP (Transmission Control Protocol) ist direkt darunter angeordnet. Das Internet-Protokoll – das so genannte IP – bildet die Netzwerkschicht. Die zwei untersten Schichten – die Verbindungsschicht und die physikalische Schicht – können kombiniert werden, um die so genannten netzwerkorientierten Schichten auszubilden, wie sie insbesondere in Reaktion auf das darunter angeordnete Netzwerk definiert werden. Die modulare Struktur des TCP/IP-Protokollstapels und die Kommunikationsverbindungen zwischen den jeweiligen Schichten sind in 2 dargestellt.
  • Das Transportprotokoll TCP bietet einen zuverlässigen Übertragungsdienst für einen Byte-Fluss. Zuverlässigkeit bezieht sich hierbei auf Fehlerfreiheit, Beibehaltung von Reihenfolgen und Schutz vor Datenverlust und Doppeln. Die Fehlerkorrektur erfolgt, indem das so genannte ARQ-(Automatic Repeat Reuest) Verfahren verwendet wird. Eine Kopie der Pakete, die gesendet werden sollen, wird auf der Senderseite generiert und aufbewahrt, bis das gesendete Datenpaket von der Gegenseite positiv bestätigt wird. Der Empfänger prüft das erhaltene Paket und bestätigt den korrekten Empfang mittels einer positiven Bestätigung und weist den Empfang eines nicht korrekt empfangenen Pakets zurück. In dieser Hinsicht ist auch anzumerken, dass TCP das Senden von negativen Bestätigungen nicht gestattet. Die Wiederholung von nicht korrekt gesendeten Paketen erfolgt mittels eines Mechanismus, der auf den positiven Bestätigungen basiert, d.h. wenn keine positive Bestätigung erfolgt, geht der Sender unter gewissen Umständen davon aus, dass ein Paket nicht empfangen worden ist.
  • Der zu übertragende Byte-Fluss, der von der Anwendungsschicht an die TCP-Schicht übergeben wird, wird durch das TCP in Segmente unterteilt, die als IP-Datagramme gesendet werden. Ein IP-Datagramm bezeichnet ein Datenpaket, das gemäß den Regeln des IP-Protokolls formatiert ist. Die Eigenschaft von Datagrammen besteht darin, dass der Datenaustausch, der unter Verwendung von Datagrammen ausgeführt wird, nicht zuverlässig ist. Daher gewährleistet das IP nicht, dass ein Paket tatsächlich zu einem Empfänger gesendet wird. Außerdem können IP-Datagramme in ihrer Reihenfolge durcheinander gebracht sein oder können beim Empfänger in Doppeln ankommen. Innerhalb der Grenzen dieses Konzepts ist es jedoch die Aufgabe des TCP, die fehlerhafte Übertragung zu erkennen und die aufgetretenen Fehler zu korrigieren.
  • Die IP-Datagramme werden des Weiteren entsprechend dem Hierarchieprinzip an die Verbindungsschicht gesendet, die direkt darunter angeordnet ist. Die Schicht empfängt die IP-Datagramme und organisiert sie in so genannten Datenübertragungsblöcken. Dies erfolgt mittels eines Verfahrens, das unter der Bezeichnung Framing bekannt ist, d.h. die Verbindungsschicht packt ein IP-Datagramm in einen oder mehrere Datenübertragungsblöcke, wobei die Datenübertragungsblöcke durch die Verwendung spezieller Bit-Kombinationen begrenzt sind. Es ist festgelegt, welche Bit-Kombination sich auf den Anfangsseparator, die so genannte Anfangskennung, und welche sich auf den Endseparator, die so genannte Endekennung eines Datenübertragungsblocks, bezieht.
  • Abgesehen vom Framing erfüllt die Verbindungsschicht zwei zusätzliche Aufgaben. Die Verbindungsschicht ist auch für die Fehlererkennung zuständig. Daher werden nicht korrekt übertragene Datenübertragungsblöcke normalerweise von dem Empfänger der Verbindungsschicht zurückgewiesen. Zu diesem Zweck ist das Datenpaket mit einem Feld zum Anwenden eines so genannten zyklischen Codes versehen, der so genannten Blockprüfzeichenfolge FCS oder der zyklischen Blockprüfung CRC. Das Konzept dabei ist, ein Datenpaket als ein Polynom zu interpretieren. Der Sender ergänzt das Datenpaket auf eine Weise, dass der Empfänger den Rest 0 durch die Teilung durch ein so genanntes Generatorpolynom empfängt. Auf diese Weise wird die Fehlererkennung ausgeführt. Die Verbindungsschicht führt optional auch die Fehlerkorrektur aus. Dies erfolgt durch die Wiederholung von nicht korrekt empfangenen Paketen, beispielsweise unter Verwendung des ARQ-Verfahrens.
  • Protokolle der Verbindungsschicht werden normalerweise zwischen physikalisch direkt benachbarten Netzwerkknoten angewendet. Zu diesem Zweck wurde eine Anzahl alternativer Protokolle definiert. Welches Protokoll zwischen zwei Netzwerkknoten angewendet wird, hängt von dem Netzwerk ab, durch welches die zwei Netzwerkknoten verbunden sind. Das bekannte Punkt-zu-Punkt-Protokoll, das PPP, bildet ein Beispiel für ein Protokoll der Verbindungsschicht. Das PPP erfüllt die ersten zwei Aufgaben der Verbindungsschicht – das Framing und die Fehlererkennung. Daher führt das PPP keine Wiederholung der nicht korrekt empfangenen Pakete durch. Obwohl es einen speziellen Implementierungsmodus des PPP gibt, der in einem so genannten "nummerierten Modus" RFC1663 arbeitet, wird er normalerweise nicht verwendet.
  • Auf Grund der Tatsache, dass das PPP eine Korrektur durch die wiederholte Paketübertragung nicht unterstützt, oder weil der Prozess bei hohen Übertragungsfehlerraten ineffizient wäre, wird ein zusätzliches Protokoll in Netzwerken mit einer besonders hohen Fehlerrate bei einer Datenübertragung angewendet. Die mobilen Kommunikationsnetzwerke sind zum Beispiel als Netzwerke mit hohen Übertragungsfehlerraten bekannt. Das GSM (Global System for Mobile Communication) und der GPRS (General Packet Radio Service) müssen darunter klassifiziert werden. Ein zusätzliches Protokoll – das so genannte RLP (Radio Link Protocol) wird auf die Verbindungsschicht des GSM-Netzwerks angewendet. Das RLP segmentiert den Byte-Fluss von der PPP-Schicht in Datenübertragungsblöcke, die normalerweise kleiner als die Datenübertragungsblöcke auf der PPP-Ebene sind. Die Fehlerkorrektur wird von dem ARQ-Verfahren auf der Basis der Datenübertragungsblöcke vorgenommen. Die Funk tionalität des ARQ erfordert, dass die Datenübertragungsblöcke aufeinander folgend nummeriert werden. Daher erhält jeder Datenübertragungsblock eine eindeutige fortlaufende Folgenummer während der Gruppierung. Beim derzeitigen Implementierungsstand wird der Byte-Fluss transparent in RLP-Datenübertragungsblöcke segmentiert und gepackt. Dadurch bleibt unberücksichtigt, welche Art von Daten, Steuerdaten oder tatsächliche Daten betroffen sind. Ein Byte-Fluss kann ausschließlich von der RLP-Schicht gesehen werden. Daher kann es vorkommen, dass Daten von zwei verschiedenen PPP-Datenübertragungsblöcken in einem RLP-Datenübertragungsblock kombiniert werden. Der RLP-Datenübertragungsblock empfängt dann die Endekennung des ersten PPP-Datenübertragungsblocks und ebenso die Anfangskennung des folgenden PPP-Pakets. Die Lösung für dieses Problem wird in EP 0 973 302 bereitgestellt, in dem vorgeschlagen wird, den Byte-Fluss auf Separatoren in dem Sender zu prüfen. Somit wird eine Unterscheidung zwischen den verschiedenen PPP-Paketen getroffen, wenn der Byte-F1uss auf der Sendeseite in RLP-Pakete gepackt wird, wodurch vermieden wird, dass Daten von zwei PPP-Paketen in einem RLP kombiniert werden.
  • Die gleiche Funktionalität wird in dem GPRS-Netzwerk mittels des RLC-Protokolls ausgeführt, welches daraus resultiert, dass beide Protokolle, das RLP und das RLC, dem ISO-Standard HDLC (High Level Data Link Control) ISO87 ähnlich sind und dementsprechend eine ähnliche Struktur aufweisen. Ein Unterscheid zwischen den Protokollen besteht hinsichtlich der Generierung der Datenübertragungsblöcke.
  • Es ist das Ziel der hierarchischen Struktur, eine Protokollarchitektur aufzubauen, in der die Protokollschichten und vor allem die Protokolle in horizontaler Hinsicht voneinander unabhängig sind. Damit wird er reicht, dass verschiedene Anwendungen und verschiedene Transportprotokolle über das gleiche Netzwerkprotokoll, wie beispielsweise das Internet-Protokoll IP übertragen werden. Des Weiteren wird dadurch gestattet, dass eine IP-Protokollschicht auf verschiedenen physikalischen Plattformen arbeiten kann. Dementsprechend können die IP-Datagramme über verschiedene physikalische Netzwerke übertragen werden, wie beispielsweise das GSM, das Internet, den GPRS.
  • Für den Benutzer bleibt die Kommunikation auf den Protokollebenen im Wesentlichen unsichtbar. Er erwartet von dem verfügbaren System, dass es die verschiedenen Anwendungsdienste unterstützt, wie beispielsweise das Senden und Empfangen von E-Mails, eines Datenflusses oder von Web-Browsing. Die Daten, die für die Übertragung zur Verfügung gestellt werden, überschreiten häufig die Größe der Pakete, die über eine physikalische Verbindung gesendet werden können. Aus diesem Grund wird eine Nachricht in kleinere Pakete aufgeteilt, die nacheinander für eine Übertragung angeordnet werden. Die Unterteilung der Daten ist Bestandteil der Formatierung. Die Formatierung der Daten wird auf jeder Protokollschicht durchgeführt. Auf gewissen Protokollschichten, wie beispielsweise der RLP-Schicht, findet eine Unterteilung von Daten statt, d.h. die Daten werden in kleinere Datenblöcke unterteilt. Die Datenblöcke weisen auf den verschiedenen Schichten unterschiedliche Bezeichnungen auf, zum Beispiel werden sie auf der IP-Protokollschicht als Datagramme und auf der Verbindungsschicht als Datenübertragungsblöcke bezeichnet. Des Weiteren werden die Datenblöcke, die sich nicht individuell auf eine Protokollschicht beziehen, mit dem Begriff Datenpaket bezeichnet.
  • Die Formatierung der Daten umfasst insbesondere das Hinzufügen von Steuerdaten, die für jede Protokoll schicht charakteristisch sind. In den meisten Fällen werden die Steuerdaten an den Anfang eines Datenpakets in Form des so genannten Headers und/oder das Ende in Form des so genannten Tails angehängt. Die tatsächlichen Daten sind in dem Feld Benutzerdaten enthalten. Der Mechanismus wird im Folgenden ausführlicher mittels eines TCP-/IP-Protokollstapels erläutert.
  • Gemäß 3 werden die Benutzerdaten auf der Anwendungsschicht segmentiert und Steuerinformationen werden zu jedem Datenpaket hinzugefügt. Die Datenpakete werden nacheinander an die Transportschicht TCP weitergeleitet. Die Schicht fügt ihre Steuerdaten in Form eines Headers hinzu. Die Daten werden an eine Netzwerkschicht übergeben, wo zum Beispiel das IP die relevanten Steuerdaten enthält, wie beispielsweise Routing-Informationen. Auf diese Weise wird ein IP-Datagramm ausgebildet, das in dem folgenden Schritt an eine Verbindungsschicht übergeben wird. Die Protokolle der Verbindungsschicht, wie zum Beispiel das PPP, verarbeiten die empfangenen Daten, indem eigene Steuerinformationen hinzugefügt werden, wie beispielsweise die Separatoren. Die Datenpakete, die auf dieser Ebene generiert werden, werden als Datenübertragungsblöcke bezeichnet. Die Datenübertragungsblöcke werden dann über das verfügbare Netzwerk übertragen. Es kommt vor, dass die Datenpakete an dem Empfänger einer gewissen Schicht in einer unterschiedlichen Reihenfolge ankommen. Es kann die Aufgabe des Empfängers dieser Schicht sein, die übertragene Reihenfolge zu reproduzieren. Dies ist zum Beispiel die Aufgabe eines TCP- oder eines RLP-Empfängers, nicht jedoch eines IP-Empfängers.
  • Der Mechanismus des Packens der Daten auf den Protokollschichten ist unter dem Begriff Kapselung bekannt. Die umgekehrte Funktion ist als Entkapselung bekannt und wird auf der empfangenden Seite durchgeführt.
  • Im Folgenden werden die Datenpakete, die sich entweder auf die RLP-Datenübertragungsblöcke oder die RLC-Datenübertragungsblöcke oder auch auf die PPP-Datenübertragungsblöcke beziehen, die jeweils in einem nummerierten Modus arbeiten, mit dem allgemeinen Begriff L2ARQ-Datenübertragungsblock bezeichnet.
  • In Form der L2ARQ-Datenübertragungsblöcke werden die Benutzerdaten zu einem Empfänger gesendet. Zur gleichen Zeit werden die L2ARQ-Datenübertragungsblöcke in einem Pufferspeicher des Senders gespeichert. Dies scheint für den Fall erforderlich zu sein, dass das Paket wiederholt wird. Mittels der fortlaufenden Nummern in den L2ARQ-Datenübertragungsblöcken wird von einem Empfänger ermittelt, ob ein Paket während der Übertragung verloren gegangen ist. Wenn ein L2ARQ-Datenübertragungsbock verloren gegangen ist, wird die Wiederholung des L2ARQ-Datenübertragungsblocks initiiert. Mittels eines entsprechenden Mechanismus empfängt der Sender eine Nachricht über den aufgetretenen Fehler, und das Paket mit der entsprechenden Nummer wird dem Pufferspeicher entnommen und nochmals übertragen. Wenn ein Paket erfolgreich an den Empfänger übertragen worden ist, wird es aus dem Pufferspeicher auf der Senderseite entfernt.
  • Der beschriebene Mechanismus bezieht sich auf den so genannten nummerierten Modus. Dieser Modus leistet einen zuverlässigen Dienst, indem eine zuverlässige Datenübertragung von einem Sender zu einem Empfänger gewährleistet wird. Es gibt auch den so genannten unnummerierten Modus. In diesem Modus wird keine Fehlerkorrektur unter Verwendung des ARQ-Prozesses durchgeführt. Daher leistet der Modus einen unzuverlässigen Dienst.
  • Die Wiederholung der Pakete hat jedoch zur Folge, dass die Pakete, die auf der Empfängerseite angekommen sind, in einer Reihenfolge bereitgestellt werden, die nicht der übertragenen Reihenfolge entspricht.
  • Bei den derzeitigen Entwicklungsprozeduren ist es die Aufgabe des Verbindungsschicht-Protokolls – vorausgesetzt, es unterstützt die ARQ – die L2ARQ-Datenübertragungsblöcke in die übertragene Reihenfolge zu bringen. Dies impliziert, dass zum Beispiel die empfangenen RLP-Pakete in einem Pufferspeicher auf der Empfängerseite gesammelt werden, bis die Reihenfolge der RLP-Pakete reproduziert wird. Dies bedeutet, dass ein RLP-Datenübertragungsblock nur dann an die Schicht freigegeben wird, die direkt darüber liegt, wenn der Datenübertragungsblock vollständig empfangen worden ist und wenn der Datenübertragungsblock der nächste in der Reihenfolge ist. Wenn ein Datenübertragungsblock jedoch auf Grund eines Fehlers wiederholt wird, werden alle folgenden, bereits empfangenen Datenübertragungsblöcke in dem Pufferspeicher behalten, bis der wiederholte Datenübertragungsblock ohne Fehler empfangen worden ist. Nur wenn die RLP-Pakete in einer entsprechenden Reihenfolge angeordnet sind, die mittels der Folgenummern generiert wird, werden sie anschließend an die PPP-Schicht übergeben. Davor werden die Steuerinformationen gelöscht.
  • Der Empfänger der PPP-Schicht führt eine Identifizierung der PPP-Datenübertragungsblöcke durch. Zu diesem Zweck werden die Separatoren gesucht. Wenn ein PPP-Datenübertragungsblock als vollständig erkannt worden ist, wird das empfangene IP-Datagramm an die IP-Schicht übergeben, die das empfangene TCP-Segment dann an die TCP-Protokollschicht übergibt.
  • Auf Grund der Tatsache, dass die L2ARQ-Datenübertragungsblöcke temporär auf der Verbindungsschicht gespei chert werden, wodurch gestattet wird, dass die Datenübertragungsblöcke in die entsprechende Reihenfolge gebracht werden, können hohe Verarbeitungszeiten auftreten. Dies hat insbesondere eine negative Auswirkung auf die Anwendungen, die gegenüber Zeitverzögerungen empfindlich sind. Lange Zeitverzögerungen beeinträchtigen auf jeden Fall die effiziente Datenverarbeitung. In dem Fall der Anwendungen, die gegenüber Verzögerungen empfindlich sind, kann dies sogar den Abbruch einer Ausführung verursachen. Des Weiteren erfordert dieses Verfahren einen großen Pufferspeicher auf den entsprechenden Protokollschichten, insbesondere jedoch auf der RLP-Protokollschicht, weil die Pakete temporär auf der Ebene gepuffert werden, bis die angeforderte Reihenfolge reproduziert worden ist. Lange Datenspeicherungszeiten führen jedoch zu langen Verzögerungszeiten für die Datenverarbeitung in einer hierarchischen Protokollarchitektur.
  • Dementsprechend ist es die Aufgabe der vorliegenden Erfindung, ein Verfahren und eine Vorrichtung bereitzustellen, die eine effizientere Verarbeitung der Daten durch den Empfänger in paketorientierten Anwendungen bei einer Datenübertragung gewährleisten. Insbesondere ist es eine Aufgabe der Erfindung, die Speicherplatzanforderung auf der Empfängerseite zu reduzieren.
  • Gemäß der Erfindung wird die Aufgabe durch die Lehre des Patentanspruchs 1 und durch die Lehre des Patentanspruchs 24 erfüllt.
  • Es ist von Vorteil, dass keine langen temporären Speicherzeiten durch die direkte Übertragung der Pakete, die vollständig auf der Verbindungsschicht generiert werden, zu der Protokollschicht auftritt, die direkt darüber bereitgestellt ist.
  • Aus diesem, Grund hat es sich auch als vorteilhaft erwiesen, dass die empfangenen Daten schneller zu der Anwendungsschicht übertragen wurden, wodurch eine stabilere Arbeitsweise von Anwendungen gewährleistet wird, die gegenüber Verzögerungen empfindlich sind.
  • Ein weiterer Vorteil besteht in der Reduzierung der erforderlichen Speicherkapazität auf der entsprechenden Protokollschicht auf der Empfängerseite, da die empfangenen Daten nicht in dem Pufferspeicher behalten werden, bis eine entsprechende Reihenfolge der empfangenen Daten bereitgestellt wird, sondern die vollständig generierten Pakete direkt für die darüber liegende Protokollschicht freigegeben werden, auch wenn einige Datenpakete möglicherweise vorher nicht empfangen worden sind.
  • Weitere vorteilhafte Formen der Erfindung lassen sich aus den Ansprüchen 2 bis 23 und Patentanspruch 25 ableiten.
  • Im Folgenden wird die Erfindung ausführlicher an Hand von Ausführungsformen und den folgenden Figuren erläutert:
  • 1 zeigt ein Ablaufdiagramm des Verfahrens gemäß der Erfindung,
  • 2 zeigt eine Darstellung von Protokollschichten im Internet,
  • 3 zeigt eine schematisches Darstellung von Benutzerdaten,
  • 4 zeigt eine Darstellung eines Netzwerksystems,
  • 5 zeigt eine schematische Darstellung eines Internet-Protokolls,
  • 6 zeigt eine Darstellung eines RLP-Datenübertragungsblocks,
  • 7 zeigt eine Darstellung eines Inter-Flussmodus, und
  • 8 zeigt eine Darstellung eines Intra-Flussmodus.
  • Im Folgenden wird die Erfindung unter Bezugnahme auf 1 und Patentanspruch 1 erläutert.
  • Gemäß 1 werden Datenpakete einer ersten Protokollschicht auf einer Senderseite bereitgestellt 10 und anschließend an eine zweite Protokollschicht, die direkt darunter liegt, übergeben 20. Die Schicht packt die empfangenen Daten in Datenpakete der zweiten Protokollschicht 30. Diesbezüglich wird darauf geachtet, dass ein Datenpaket der zweiten Protokollschicht nicht die Daten von zwei verschiedenen Datenpaketen der ersten Protokollschicht enthält. Jedes Datenpaket der zweiten Protokollschicht erhält eine eindeutige Folgenummer. Die Datenpakete der zweiten Protokollschicht, die auf diese Weise gepackt sind, werden an ein verfügbares Netzwerk in der gegenwärtigen Reihenfolge übergeben 40 und werden anschließend über das Netzwerk übertragen 50. Die einzelnen Datenpakete der zweiten Protokollschicht werden auf einer Empfängerseite empfangen 60. Die empfangenen Datenpakete der zweiten Protokollschicht werden mittels der Folgenummer in eine Reihenfolge sortiert 70 und in dem bereitgestellten Pufferspeicher gespeichert 80. Sie werden hinsichtlich ihrer Reihenfolge geprüft, um die Datenpakete der ersten Protokollschicht zu erkennen 90. Wenn ein Datenpaket der zweiten Protokollschicht empfangen wird, wird zuerst geprüft, ob dieses Datenpaket Separatoren der ersten Protokollschicht enthält. Falls ja, ist entweder eine Anfangskennung oder eine Endekennung eines Datenpakets der ersten Protokollschicht betroffen. Im Fall einer Anfangsmarkierung bedeutet dies, dass die nachfolgenden Datenpakete der zweiten Protokollschicht zu einem neuen Datenpaket der ersten Protokollschicht gehören. Die Datenpakete der zweiten Protokollschicht werden in dem Pufferspeicher behalten, bis ein Datenpaket der ersten Protokollschicht vollständig empfangen worden ist 100. Dies wird durch den Empfang eines Datenpakets der zweiten Protokollschicht erkannt, in welcher das Datenfeld eine Endekennung enthält und außerdem das nächstfolgende in einer Reihenfolge ist. Nur ein vollständig generiertes Datenpaket der ersten Protokollschicht wird für die direkt darüber liegende Protokollschicht freigegeben 110.
  • Im Folgenden wird die Erfindung unter Bezugnahme auf Anspruch 24 erläutert.
  • Eine Formatierung von Datenpaketen einer ersten Protokollschicht auf einer zweiten Protokollschicht und ihre Anordnung gemäß einer Übertragungsreihenfolge wird durch eine Einrichtung zum Bereitstellen von Datenpaketen einer ersten Protokollschicht für eine zweite Protokollschicht ausgeführt. Die Datenpakete werden über ein bereitgestelltes Netzwerk durch Übertragungseinrichtungen übertragen. Die Empfangseinrichtung zum Empfangen der Datenpakete auf der Empfängerseite empfängt die Pakete. Mit einer Sortiereinrichtung zum Sortieren der Datenpakete werden die empfangenen Datenpakete in eine Reihenfolge von aufeinander folgenden Datenpaketen gebracht und in einem Pufferspeicher zum temporären Speichern der empfangenen Datenpakete der zweiten Protokollschicht gespeichert. Die Datenpakete der zweiten Protokollschicht werden geprüft, ob ein Datenpaket der ersten Protokollschicht erkannt werden kann. Dies erfolgt unter Verwendung einer Erkennungseinrichtung zum Erkennen eines vollständig kombinierten Datenpakets der ersten Protokollschicht. Folglich wird ein vollständig generiertes Datenpaket der ersten Protokollschicht durch eine Prüfeinrichtung für die Verbindung zu einem Datenfluss geprüft. Daran anschließend wird ein geprüftes Datenpaket mittels einer Freigabeeinrichtung zum Freigeben eines vollständig generierten Datenpakets der ersten Protokollschicht freigegeben.
  • Ein möglicher Anwendungsbereich der Erfindung liegt im Bereich von Internet-Anwendungen über ein mobiles Daten-Netzwerk, wie beispielsweise das GSM. Eine mögliche Anwendung der Erfindung wird im Folgenden ausführlicher unter Bezugnahme auf eine Ausführungsform erläutert, wobei die Verarbeitung der Daten als diejenige der Anwendung auf der Senderseite bis zur Freigabe der vollständig generierten Datenpakete auf der Empfängerseite dargestellt ist.
  • Zu diesem Zweck wird ein Netzwerksystem verwendet, das schematisch in 4 dargestellt ist. Eine Kommunikation zwischen einem mobilen Teilnehmer mit beispielsweise einer Mobilstation und einem Teilnehmer, der in ein festes Netzwerk mit einem Server integriert ist, wird hierbei schematisch dargestellt. Der obere Teil der Figur zeigt die physikalische Verbindung mit den entsprechenden Kommunikationseinheiten, und der untere Teil bildet die logische Verbindung mit den beteiligten Protokollen.
  • Die Mobilstation MS kann zum Beispiel ein Laptop-Computer sein. Der Laptop-Computer ist über eine Endgerätanpassungsfunktion (TAF), deren Prozess beispielsweise durch die PCMCIA-Karte (Personal Computer Memory Card International Association) ausgeführt wird, mit der Mobilstation, beispielsweise einem Mobiltelefon verbunden. Die Mobilstation MS kommuniziert mit einer BTS (Funkbasisstation), die wiederum mit einem BSC (Basisstations-Controller) kommuniziert. Die Verbindung zu einem öffentlichen analogen Telefonnetzwerk, dem so genannten öffentlichen Fernsprechnetz (PSTN), wird mittels eines Modems ausgeführt, das in die so genannte Netzübergangsfunktion IWF integriert ist. Die Netzübergangsfunktion IWF ist Teil der mobilen Vermittlungsstelle, der so genannten Funkvermittlungsstelle (MSC). Des Weiteren verläuft die Verbindung über ein öffentliches Fernsprechnetz PSTN zu einem Internet-Dienstanbieter (ISP), der einen Netzwerk-Übergangsknoten zum Internet besitzt. Die Verbindung zu einem Endgerät-Teilnehmer, Server, wird über das Internet aufgebaut. Aus Gründen der Klarheit wurde die Verbindung über das Internet in 4 nicht ausführlicher dargestellt.
  • Es ist anzumerken, dass die Anwendungen unabhängig von den darunter liegenden Protokollschichten implementiert werden. Die Übertragung der durch sie generierten Daten wird auf eine für den Benutzer transparenten Weise durchgeführt. Dies ist auch das Ziel der hierarchischen Struktur des Protokollstapels, nämlich eine optimale und stabile Übertragung zu gewährleisten, ohne den Benutzer in die Gegebenheiten des System mit einbeziehen zu müssen. Von dem darunter liegenden System wird jedoch erwartet, dass es alle vom Benutzer verwendeten Anwendungen unterstützt, wie beispielsweise den Zugang zum Internet oder die Übertragung von Videodaten. Die verschiedenen Anwendungen stellen jedoch unterschiedliche Anforderungen an das System.
  • Gewisse Internet-Anwendungen wie eine Bank-Transaktion erfordern zum Beispiel ein sicheres Transportprotokoll, denn nur auf diese Weise wird ein fehlerfreier Datenfluss während Geldtransaktionen über das Internet gewährleistet. Eine sichere Datenübertragung wird durch das so genannte Transmission Control Protocol TCP gewährleistet.
  • Im Gegensatz dazu ist es im Fall einer Video-Übertragung nicht erforderlich, ein Protokoll zu verwenden, das eine zuverlässige Sicherheit der Datenübertragung gewährleistet, da die Sicherheit eines zuverlässigen Datenflusses möglicherweise mit längeren Verzögerungszeiten bei der Übertragung verbunden ist. Im Fall einer Video-Übertragung ist es besser, eine schnellere Übertragung von aufeinander folgenden Daten zu gewährleisten, um dadurch einen realistischen Eindruck bei der Darstellung von Videobildern zu erhalten. Die Fehler, die während einer Übertragung auftreten können, liegen innerhalb gewisser Grenzen und können toleriert werden, wenn die Videobilder rundgesendet werden. Aus diesem Grund wird bei der Video-Übertragung kein fehlerkorrigierendes Protokoll verwendet. Ein Beispiel für solche Protokolle der Übertragungsebene ist das so genannte User Datagram Protocol UDP.
  • In den meisten Fällen verwendet ein Benutzer mehrere Anwendungen während einer Sitzung, zum Beispiel, wenn er eine E-Mail senden und gleichzeitig im Hintergrund ein Video übertragen möchte. In diesem Fall generiert der Benutzer zwei verschiedene Datenflüsse, wobei die E-Mail-Übertragung auf dem TCP basiert und die Video-Übertragung auf dem UDP basiert. Ein weiteres Beispiel ist der Internet-Zugang. In den meisten Fällen werden während einer Sitzung mehrere Internet-Seiten aufgerufen, die sich oft auf verschiedenen Servern befinden. Obwohl die generierten Datenflüsse ausschließlich TCP-Flüsse sind, sind in diesem Fall verschiedene Datenflüsse betroffen, weil die Empfänger verschieden sind.
  • Der Unterschied wird auf der Netzwerk-Protokollschicht, wie beispielsweise der IP-Schicht, berücksichtigt. Die Schicht umfasst Pakete, die aus der Transportprotokollschicht empfangen werden, und packt sie, um Pakete mit ihrem eigenen Format auszubilden. 5 stellt ein Format eines IP-Pakets dar. Das Paket enthält Steuerdaten, in welchen zum Beispiel die Version des IP-Protokolls enthalten ist, beispielsweise Ipv4 oder Ipv6. Dies wurde in 5 nicht im Detail dargestellt. Des Weiteren ist das IP-Datenformat mit einem Feld versehen, das die Informationen in Bezug auf das Transportprotokoll enthält. Im Fall eines UDP-Protokolls bedeutet dies, dass eine Bit-Kombination in das Feld eingegeben wird, die der Bezeichnung des UDP entspricht.
  • Der entscheidende Faktor beim Unterscheiden des Datenflusses ist jedoch nicht nur der Protokolltyp, sondern auch der Faktor hinsichtlich dessen, welche Adressen in dem IP-Header enthalten sind. Wenn sowohl die IP-Adresse des Senders als auch die Adresse des Empfängers in zwei IP-Paketen gemäß 5 identisch sind, bedeutet dies, dass zusätzlich der TCP-Header im Anschluss daran geprüft werden muss, um den Unterschied zwischen den Datenflüssen herauszufinden. Verschiedenen Datenflüssen sind verschiedene Port-Nummern zugewiesen. Die Port-Nummern identifizieren den entsprechenden Datenfluss auf der Übertragungsebene, mittels welcher eine Kommunikation zwischen den Partner-Instanzen gewährleistet wird. Der Header eines TCP-Pakets enthält Informationen in Bezug auf die Port-Nummern, welche verglichen werden, wenn der Datenfluss differenziert wird. Nur wenn die Port-Nummern des Senders und des Empfängers identisch sind, ist der Datenfluss der gleiche. Wenn die Adressen unterschiedlich sind, d.h. wenn beide IP-Adressen und die Port-Nummern sich voneinander unterscheiden, sind die Empfänger verschieden, und daher sind die Datenflüsse verschieden. Der Mechanismus ist in der derzeit verwendeten Version des IP, der so genannten Internet-Protokollversion IP4v implementiert. In der nächsten Version des IP, der so genannten Internet-Protokollversion IP6v ist die Definition im Wesentlichen die gleiche. Hier werden verschiedene Datenflüsse mittels so genannter Datenfluss-Kennzeichner – auch als Fluss-Kennzeichner bezeichnet – differenziert. Das beschriebene Verfahren kann auch auf Ipv6 und im Wesentlichen auf jeden Protokollstapel übertragen werden, bei dem der Datenfluss identifiziert werden kann.
  • In Abhängigkeit davon, ob die Pakete auf der IP-Schicht sich von identischen oder von verschiedenen Datenflüssen ableiten, wird eine Unterscheidung zwischen zwei Modi getroffen. Im Fall von IP-Paketen eines identischen Datenflusses handelt es sich um einen so genannten Intra-Datenfluss-Modus oder Intra-Flussmodus. Der Begriff Inter-Flussmodus bezeichnet einen Modus, in welchem IP-Pakete, die zu verschiedenen Datenflüssen gehören, differenziert werden.
  • Gemäß 4, in dem Fall, in dem eine Verbindung auf der Transportschicht zwischen einer Mobilstation und einem Server in dem Internet bereits aufgebaut worden ist, wird im Folgenden ein Beispiel eines Datenflusses von dem Server zu der Mobilstation gezeigt. In diesem Beispiel wird Beteiligung der Kommunikationseinheiten und der Kommunikationsprotokolle ausführlicher erläutert.
  • Die auf der Netzwerkschicht gepackten IP-Datagramme werden über das Internet zu einem so genannten Internet-Dienstanbieter ISP übertragen. Der ISP überträgt die empfangenen IP-Pakete zu der PPP-Schicht. Die Schicht generiert einen Byte-Fluss, der in PPP-Daten übertragungsblöcken aus den erhaltenen Daten formatiert wird. Für die Differenzierung zwischen den jeweiligen Paketen werden die Separatoren hinzugefügt. Somit werden die PPP-Datenübertragungsblöcke für eine analoge Übertragung bereitgestellt. Der ISP stellt ein Modem für die Übertragung bereit, welche die Daten in Reaktion auf die Übertragungsgeschwindigkeit und den -modus zu einem Audiosignal moduliert. In dem dargestellten Beispiel, in dem eine Verbindung über ein analoges Netzwerk, das PSTN, verläuft, ist dies ein V.32-Modem. Wenn die Verbindung über ein ISDN-Netzwerk verläuft, wird zum Beispiel ein V.110-Protokoll verwendet. Zum Steuern des Flusses, d.h. um anschließend einen Datenüberlauf in der Netzübergangsfunktion IWF zu vermeiden, wird ein V.42-Protokoll verwendet. Der Prozess entspricht dem Prozess des Funkverbindungsprotokolls RLP im GSM.
  • In der Netzübergangsfunktion IWF findet die Umwandlung der empfangenen Daten in das Format statt, das für das GSM gewünscht wird.
  • Dies bedeutet, dass der Byte-Fluss der PPP-Schicht an die RLP-Schicht freigegeben wird. Die Schicht packt den empfangenen Byte-Fluss in RLP-Datenübertragungsblöcke. Ein Format eines RLP-Datenübertragungsblocks wird in 6 dargestellt. Ein RLP-Datenübertragungsblock besteht aus 240 Bits. 16 Bits davon sind für die Header-Informationen vorgesehen und 24 Bits für die Blockprüfzeichenfolge FCS. Ein entscheidender Faktor beim Packen der PPP-Datenübertragungsblöcke in RLP-Datenübertragungsblöcke besteht darin, dass Datenpakete der höheren Protokollschichten für die RLP-Schicht in dem empfangenen Byte-Fluss nicht direkt sichtbar sind. Dies bedeutet insbesondere, dass die RLP-Schicht keine Unterscheidung zwischen den PPP-Datenübertragungsblöcken oder zwischen den IP-Datagrammen und somit zwi schen den Paketen der Transportschicht treffen kann. Zum Differenzieren der Pakete muss der Byte-Fluss auf die Separatoren geprüft werden. Dies ist notwendig, um zu vermeiden, dass Daten von zwei verschiedenen PPP-Datenübertragungsblöcken in einen RLP-Datenübertragungsblock gepackt werden. Jeder neu gepackte RLP-Datenübertragungsblock ist mit einer Folgenummer versehen.
  • Pakete, die auf diese Weise angeordnet sind, werden über ein bereitgestelltes mobiles Netzwerk übertragen. Während der Übertragung kann die Reihenfolge der RLP-Datenübertragungsblöcke auf Grund der auftretenden Übertragungsfehler und des ARQ-Prozesses, der zu deren Korrektur verwendet wird, durcheinander geraten. Dies führt folglich dazu, dass die Datenübertragungsblöcke von dem Empfänger in einer geänderten Reihenfolge empfangen werden. Der Empfänger prüft zunächst die empfangenen RLP-Datenübertragungsblöcke auf die Folgenummer, um die Position des RLP-Datenübertragungsblocks in der gegenwärtigen Reihenfolge herauszufinden. In einem weiteren Schritt wird geprüft, ob der empfangene RLP-Datenübertragungsblock einen Separator enthält. Wenn er eine Anfangskennung enthält, wird er als der erste Datenübertragungsblock in einem anschließenden PPP-Datenübertragungsblock erfasst und in einem Pufferspeicher auf der entsprechenden Position gespeichert. Die anschließenden RLP-Datenübertragungsblöcke, die aufeinander folgende Nummern aufweisen, werden dann ebenfalls in dem Pufferspeicher auf der entsprechenden Position gespeichert. Dies wird fortgesetzt, bis ein PPP-Datenübertragungsblock den Status eines vollständig generierten Datenübertragungsblocks empfängt. Ein PPP-Datenübertragungsblock ist vollständig generiert, wenn sowohl die Anfangskennung als auch die Endekennung korrekt empfangen worden sind, und alle RLP-Datenübertragungsblöcke ohne irgendwelche Lücken kor rekt empfangen worden sind, und wenn sie sich in der richtigen Reihenfolge zwischen dem RLP-Datenübertragungsblock, der die Anfangskennung enthält, und dem RLP-Datenübertragungsblock, der die Endekennung enthält, befinden. Bevor die RLP-Datenübertragungsblöcke in dem Pufferspeicher gespeichert werden, werden die Datenübertragungsblöcke entkapselt, d.h. die Steuerdaten der RLP-Protokollschicht werden entfernt.
  • Wenn die RLP-Pakete geprüft werden, werden nicht nur die PPP-Pakete unterschieden, sondern die Prüfung der Datenübertragungsblöcke kann auf die Erfassung der IP-Pakete erweitert werden. Dies ist die Basis zum Differenzieren zwischen dem Intra-Flussmodus und dem Inter-Flussmodus. Wie bereits erwähnt, enthält der IP-Header die Informationen hinsichtlich des verwendeten Transportprotokolls und der entsprechenden Adressen. Auf Grund der Tatsache, dass ein ganzes IP-Datagramm in einen PPP-Datenübertragungsblock passt, kann die Prüfung eines abgeschlossenen PPP-Datenübertragungsblocks der Erkennung eines IP-Datagramms und dessen Informationen zugewiesen werden, d.h. hinsichtlich dessen, ob IP-Datagramme des gleichen von verschiedenen Datenflüssen betroffen sind.
  • Zu diesem Zweck werden die Steuerdaten des Datenübertragungsblocks geprüft, nachdem ein vollständiger PPP-Datenübertragungsblock generiert worden ist. Die Daten werden insbesondere auf die Steuerdaten der jeweiligen Protokollschicht geprüft. Dies wird ausgeführt, indem eine Erkennungseinrichtung zum Erkennen eines vollständig kombinierten Datenpakets verwendet wird. Dies bedeutet, dass Informationen hinsichtlich der Steuerdaten der jeweiligen Schicht für die Einrichtung verfügbar sein müssen, denn nur auf dieser Basis wird eine Entscheidung getroffen, welche Steuerdaten sich von der Verbindungsschicht, insbesondere vom PPP ableiten, und wo in dem PPP-Datenübertragungsblock die Steuerdaten der IP-Steuerschicht beginnen. Auf Grund der Tatsache, dass das Format der Entkapselung der Daten auf jeder Schicht standardisiert ist, muss eine Implementierung in dem Mechanismus vorgenommen werden, die den gültigen Standards der Kapselung ähnlich ist. Eine nähere Erörterung der Prüfung der IP-Datagramme wird in den im Folgenden erläuterten Ausführungsformen vorgenommen.
  • Ein IP-Datagramm wird zu der Protokollschicht – der Transportschicht – übertragen, die direkt darüber liegt. Die TCP-Pakete werden ebenfalls fortlaufend nummeriert, und auf Grund der vorhandenen Nummerierung wird die Reihenfolge der TCP-Pakete auf der Transportschicht generiert. Mit anderen Worten, das TCP ist dafür zuständig, die TCP-Pakete in einer korrekten Reihenfolge anzuordnen. Auf dieser Ebene werden auch die fehlerhaften Pakete erfasst, und die Fehler werden entfernt, indem eine Abfrage für die wiederholte Übertragung der Pakete gestartet wird.
  • Auf Grund der Tatsache, dass das TCP dafür zuständig ist, die korrekte Reihenfolge der übertragenen TCP-Pakete zu generieren, ist es nicht mehr erforderlich, das Gleiche auch auf der Netzwerk-Protokollschicht durchzuführen. Dies gestattet insbesondere, dass die IP-Datagramme in einer geänderten Reihenfolge empfangen werden. Die Ursache für den Empfang der IP-Datagramme in der nicht korrekten Reihenfolge ist deren asynchrone Übertragung. Die einzelnen Pakete können verschiedene Pfade zu dem Empfänger nehmen, wodurch es vorkommen kann, dass die gesendeten Pakete sich auf ihrem Weg überholen, wodurch sie am Empfänger in einer geänderten Reihenfolge ankommen. Auf Grund der Tatsache, dass die Transportschicht, insbesondere das TCP, dafür zuständig ist, die Reihenfolge zu generieren, ist es nicht wichtig, in welchem Ausmaß die Reihenfolge der IP-Pakete auf der Netzwerkschicht geändert wird. Dies bedeutet insbesondere, dass die Effizienz der Paketverarbeitung nicht beeinflusst wird, wenn die Reihenfolge zusätzlich durch die RLP-Protokollschicht geändert wird.
  • Das Gleiche gilt für das UDP, bei dem die Änderung der Reihenfolge der Pakete zulässig ist.
  • Im Folgenden wird eine Implementierung der Erfindung gemäß Patentanspruch 16 für den Inter-Flussmodus ausführlicher unter Bezugnahme auf 7 erläutert.
  • In dem Inter-Flussmodus werden Pakete, die zu verschiedenen Datenflüssen gehören, differenziert. Zu diesem Zweck werden vollständig generierte PPP-Datenübertragungsblöcke geprüft, wie oben beschrieben wurde. In dem Modus werden die PPP-Datenübertragungsblöcke bereits durch den RLP-Empfänger freigegeben, erstens, wenn sie vollständig und korrekt empfangen werden, und zweitens, wenn gewährleistet ist, dass keine weiteren PPP-Datenübertragungsblöcke in den Daten enthalten sind, die möglicherweise durch den RLP-Empfänger gepuffert wurden, die zu dem gleichen Datenfluss der PPP-Datenübertragungsblöcke gehören, die freigegeben werden sollen.
  • Nachdem die Steuerdaten der IP-Schicht erkannt worden sind, kann in den Daten nach dem Transportprotokollfeld gesucht werden. Wenn die Eingabe in dem Feld in den geprüften PPP-Datenübertragungsblöcken unterschiedlich ist, handelt es sich definitiv um verschiedene Datenflüsse. Wenn die Eingabe hinsichtlich des Transportprotokolls jedoch übereinstimmend ist, werden die IP-Adressen der Sender und der Empfänger geprüft. Im Fall einer Übereinstimmung der Adressen wird die Port-Nummer der Sender und der Empfänger geprüft. Wenn keine Unterschiede während dieser Prüfung festgestellt werden können, handelt es sich um PPP-Datenübertragungsblöcke des gleichen Datenflusses.
  • Im Folgenden wird gemäß 7 der Fall angenommen, dass der Sender Daten von zwei verschiedenen Datenflüssen überträgt, dem UDP-Datenfluss und dem TCP-Datenfluss 170. Die PPP-Datenpakete werden aus den Daten in einem Kapselungsprozess generiert 180. In Abhängigkeit davon, ob es sich um einen UDP-Datenfluss oder einen TCP-Datenfluss handelt, werden zwei Arten von PPP-Datenpaketen, das PPP(IP(TCP(n)))- und das PPP(IP(UDP(n)))-Paket differenziert. Das n bezeichnet hierbei die Folgenummer eines UDP-Pakets oder eines TCP-Pakets. Gemäß 7 werden zwei UDP-Pakete PPP(IP(UDP(1))), PPP(IP(UDP(2))) und zwei TCP-Pakete PPP(IP(TCP(1))), PPP(IP(TCP(2))) auf der PPP-Protokollschicht generiert. Diese werden dann an die RLP-Protokollschicht übertragen, welche dieselben in einen Fluss von aufeinander folgenden RLP-Datenübertragungsblöcken (RLP(1), RLP(2), ... RLP(12) überträgt 190. Wie bereits oben erwähnt wurde, wird auf der RLP-Protokollschicht kein Unterschied zwischen den verschiedenen Datenpaketen der darüber liegenden Protokollschicht gemacht. Gemäß 7 wird das Datenpaket PPP(IP(TCP(1))) in RLP(1), RLP(2), RLP(3) und RLP(4) unterteilt. Die anderen Datenpakete der Netzwerk-Protokollschicht werden ebenfalls auf diese Weise unterteilt. Die endgültigen RLP-Datenübertragungsblöcke werden dann über ein Netzwerk übertragen 200. Während der Übertragung kann eine Änderung der Reihenfolge der RLP-Datenübertragungsblöcke auftreten, was auf die häufige Wiederholung von nicht korrekt übertragenen RLP-Datenübertragungsblöcken des TCP-Datenflusses zurückzuführen sein kann.
  • Angenommen, der Empfänger empfängt gemäß 7 den RLP-Datenübertragungsblock RLP(1) zuerst 210, und die RLP-Datenübertragungsblöcke RLP(5), RLP(6), RLP(7) werden danach empfangen 220. Diese werden als vollständig empfangenes Paket erkannt. Demzufolge wird das Paket geprüft, um den Typ des Datenflusses zu erfassen. Es wird als ein UDP-Paket, PPP(IP(UDP(1))) erkannt und wird an die PPP-Schicht freigegeben 230. Die PPP-Schicht wird jedoch nur freigegeben, wenn sichergestellt worden ist, dass definitiv keine PPP-Datenübertragungsblöcke des gleichen Datenflusses in den Daten enthalten sind, die möglicherweise durch den RLP-Empfänger gepuffert sind. In dieser Ausführungsform ist es nur zulässig, die PPP-Datenübertragungsblöcke, die zu verschiedenen Datenflüssen oder zu dem gleichen Datenfluss gehören, an die PPP-Protokollschicht freizugegeben, allerdings nur in der korrekten Reihenfolge hinsichtlich der Nummerierung der RLP-Datenübertragungsblöcke.
  • Gemäß 7 sind die RLP-Datenübertragungsblöcke RLP(8), RLP(9), RLP(19) die Nächsten, die empfangen werden sollen 240. Diese werden dann wieder in einem Pufferspeicher gespeichert und als ein vollständiges PPP(IP(UDP(2)))-Paket erkannt 250. Da das RLP-Protokoll die Information hat, dass das erste UDP-Paket PPP(IP(UDP(1))), das zu dem gleichen Datenfluss gehört, bereits freigegeben worden ist, wird jetzt auf der Basis dieser Information die Entscheidung getroffen, das PPP(IP(UDP(2))) an die PPP-Protokollschicht freizugeben. Da die PPP-Datenübertragungsblöcke des TCP-Pakets noch nicht vollständig generiert worden sind, da das PPP(IP(TCP(1))) nur das RLP(1) enthält, wird es weiterhin in dem Pufferspeicher behalten. Wenn jedoch das PPP(IP(UDP(1))) auch nicht vollständig ist, wird das PPP(IP(UDP(2))) in dem Pufferspeicher behalten, bis das PPP(IP(UDP(1))) vollständig generiert worden ist.
  • Die folgende Ausführungsform schlägt eine erweiterte Implementierung vor, in der eine Freigabe von vollständig generierten PPP-Datenübertragungsblöcken, die sowohl zu verschiedenen als auch gleichen Datenflüssen gehören, zulässig ist.
  • Im Folgenden wird die Ausführungsform ausführlicher unter Bezugnahme auf 8 und Patentanspruch 17 erläutert.
  • Angenommen, dass auf Grund einer temporären schlechten Übertragungsqualität der Verbindung, die während der Übertragung der ersten PPP-Pakete aufgetreten ist, zuerst das PPP(IP(UDP(2))) vollständig empfangen worden ist. Dies erfolgt auf Grund des Empfangs der Datenübertragungsblöcke RLP(8), RLP(9), RLP(10) 280. Der Zwischenspeicher enthält nur einen RLP-Datenübertragungsblock, den Datenübertragungsblock RLP(5) 270. Auf Grund der Tatsache, dass der Intra-Flussmodus zulässig ist, werden alle vollständig generierten Datenübertragungsblöcke, auch diejenigen, die zu dem gleichen Datenfluss gehören, freigegeben. Dies bedeutet, dass ausschließlich die Vollständigkeit eines PPP-Datenübertragungsblocks beachtet wird. Die höheren Schichten sind dann dafür zuständig, die Pakete in der korrekten Reihenfolge anzuordnen. Auch das RLP(1), das zuerst empfangen wurde und das den ersten Datenübertragungsblock eines unvollständig generierten PPP(IP(TCP(1))) bildet, wird in dem Pufferspeicher behalten 260.
  • In dem oben Genannten wurde die Erfindung mittels einer beispielhaften Anwendung in dem GSM-Bereich vorgestellt. Die gleichen Anwendungsmöglichkeiten sind in anderen Netzwerken vorhanden, wie beispielsweise dem GPRS-Netzwerk. Das Netzwerk ist für die Übertragung von einer paketorientierten Anwendung von dem Sender zu dem Empfänger ausgelegt. Die Architektur des Protokollstapels ist in beiden Fällen ebenfalls vergleichbar.
  • Die Erfindung kann auch in einer Umgebung angewendet werden, in der nur ein Verbindungsprotokoll vorgesehen ist. Dies bedeutet, dass ein einzelnes Verbindungsprotokoll implementiert ist statt des PPP und RLP im GSM oder dem LLC und RLC in dem GPRS. In diesem Fall ist es erforderlich, dass das Protokoll in einer zuverlässigen Weise arbeitet. Es ist zum Beispiel möglich, diese Form einer Implementierung im UMTS anzutreffen.

Claims (25)

  1. Verfahren zum Verbessern einer Verarbeitungszeit von empfangenen Daten in paketorientierten Anwendungen in einer Datenübertragung zwischen einem Sender und einem Empfänger, die jeweils eine erste und eine darunter liegende zweite Protokollschicht umfassen, über ein Kommunikationsnetzwerk, wobei – Daten von der ersten Protokollschicht an die zweite Protokollschicht in dem Sender freigegeben werden (10), – die Daten der ersten Protokollschicht in aufeinander folgende Datenpakete der zweiten Protokollschicht unterteilt werden, die eine Reihenfolge von aufeinander folgenden Datenpaketen mit Folgenummern generiert, wodurch ein Datenpaket der zweiten Protokollschicht Daten aus nur einem Datenpaket der ersten Protokollschicht enthält (30), – die Datenpakete der zweiten Protokollschicht über das Kommunikationsnetzwerk übertragen werden (50), – Datenpakete der zweiten Protokollschicht, die in dem Empfänger empfangen werden (60), auf der zweiten Protokollschicht in die Reihenfolge von aufeinander folgenden Datenpaketen mittels der Folgenummern sortiert werden, – die empfangenen Datenpakete auf der zweiten Protokollschicht zu Datenpaketen der ersten Protokollschicht zugewiesen werden, – nachdem ein Datenpaket der ersten Protokollschicht vollständig generiert worden ist (100), das Datenpaket auf die Verbindung zu einem Datenfluss geprüft wird und an die erste Protokollschicht freigegeben wird (110).
  2. Verfahren nach Anspruch 1, wobei eine Verarbeitung der Daten in dem Sender und/oder dem Empfänger auf einer modularen Protokollstruktur basiert.
  3. Verfahren nach Anspruch 1 oder 2, wobei die Datenpakete der zweiten Protokollschicht fortlaufend nummeriert und durch eine entsprechende Folgenummer gekennzeichnet werden.
  4. Verfahren nach einem der Ansprüche 1 bis 3, wobei die erste Protokollschicht wenigstens zwei Übertragungsmodi, einen zuverlässigen und einen unzuverlässigen Modus unterstützt.
  5. Verfahren nach Anspruch 4, wobei die Datenpakete der zweiten Protokollschicht mittels einer wiederholten Übertragung in dem Fall eines Übertragungsfehlers und unter Verwendung des zuverlässigen Übertragungsmodus korrigiert werden.
  6. Verfahren nach einem der Ansprüche 1 bis 5, wobei die Daten der ersten Protokollschicht mittels Separatoren klar voneinander differenziert sind.
  7. Verfahren nach Anspruch 3, wobei die empfangenen Datenpakete einer Folgenummer entsprechend in eine Reihenfolge sortiert werden.
  8. Verfahren nach Anspruch 3 oder 7, wobei die Folgenummer eine RLP- (Radio Link Protocol) Folgenummer oder eine RLC- (Radio Link Control) Folgenummer ist.
  9. Verfahren nach einem der vorhergehenden Ansprüche 1 bis 8, wobei die empfangenen Datenpakete in einem Pufferspeicher des Empfängers gespeichert werden.
  10. Verfahren nach einem der Ansprüche 1 bis 9, wobei ein Datenpaket der ersten Protokollschicht in einen Status eines vollständig generierten Datenpakets gebracht wird, wenn sowohl eine Anfangskennung als auch eine Endekennung innerhalb der Datenpakete der zweiten Protokollschicht korrekt empfangen worden sind, und wenn alle Datenpakete der zweiten Protokollschicht, die dazwischen liegen, ihrer korrekten Reihenfolge entsprechend korrekt empfangen worden sind.
  11. Verfahren nach Anspruch 10, wobei die vollständig generierten Datenpakete der ersten Protokollschicht gemäß den Regeln eines Kapselungsprozesses geprüft werden, um Pakete von weiteren Protokollschichten zu identifizieren.
  12. Verfahren nach Anspruch 10 oder 11, wobei wenigstens ein Steuerfeld, das Steuerdaten enthält, in den vollständig generierten Datenpaketen der ersten Protokollschicht vorgesehen ist, um die Informationen hinsichtlich eines entsprechenden Datenflüssen bereitzustellen.
  13. Verfahren nach Anspruch 12, wobei die Steuerdaten an die tatsächlichen Datensequenzen als Steuerfelder in den entsprechenden Protokollschichten in Form eines Headers und/oder eines Tails angehängt sind.
  14. Verfahren nach einem der Ansprüche 1 bis 13, wobei ein Datenfluss mittels gewisser Steuerdaten in den hierfür vorgesehenen Steuerfeldern differenziert wird.
  15. Verfahren nach Anspruch 14, wobei die Steuerdaten zum Differenzieren von Datenflüssen die Adressen des Senders und/oder Empfängers in Form von Quellenadressen, Zieladressen und Port-Nummern sind.
  16. Verfahren nach einem der Ansprüche 1 bis 15, wobei die Datenpakete der ersten Protokollschicht direkt an die erste Protokollschicht auf der zweiten Protokollschicht freigegeben werden, wenn die Datenpakete auf der zweiten Protokollschicht erstens vollständig und korrekt empfangen worden sind und wenn zweitens gewährleistet worden ist, dass die Daten, die möglicherweise durch den Empfänger der zweiten Protokollschicht gespeichert worden sind, keine weiteren Datenpakete der ersten Protokollschicht enthalten, die zu dem gleichen Datenfluss der Datenpakete der ersten Protokollschicht gehören, die freigegeben werden sollen.
  17. Verfahren nach einem der Ansprüche 1 bis 15, wobei die zweite Protokollschicht der Datenpakete der ersten Protokollschicht direkt an die erste Protokollschicht freigegeben werden, wenn die Datenpakete vollständig und korrekt empfangen worden sind.
  18. Verfahren nach Anspruch 1, wobei die Datenpakete der ersten Protokollschicht IP-Datagramme sind, und die Datenpakete der zweiten Protokollschicht PPP-Datenübertragungsblöcke sind, wobei PPP-Daten übertragungsblöcke mittels wiederholter Übertragung korrigiert werden, wenn ein Fehler auftritt.
  19. Verfahren nach Anspruch 1, wobei die Datenpakete der ersten Protokollschicht PPP-Datenübertragungsblöcke sind und die Datenpakete der zweiten Protokollschicht RLP-Daten-Datenübertragungsblöcke sind.
  20. Verfahren nach Anspruch 1, wobei die Datenübertragung über ein IP-Netzwerk und ein mobiles Kommunikationsnetzwerk durchgeführt wird.
  21. Verfahren nach Anspruch 1, wobei die paketorientierten Anwendungen Internet-Anwendungen sind.
  22. Verfahren nach den Ansprüchen 18 bis 21, wobei eine Internet-Anwendung mittels des Transportprotokolls Transmission Control Protocol (TCP) übertragen wird.
  23. Verfahren nach den Ansprüchen 18 bis 21, wobei eine Internet-Anwendung mittels des Transportprotokolls User Datagram Protocol (UDP) übertragen wird.
  24. Vorrichtung zum Verbessern einer Verarbeitungszeit von empfangenen Daten in paketorientierten Anwendungen in einer Datenübertragung zwischen einem Sender und einem Empfänger, die jeweils eine erste und eine darunter liegende zweite Protokollschicht umfassen, über ein Kommunikationsnetzwerk, umfassend – eine Einrichtung zum Bereitstellen von Datenpaketen von einer ersten Protokollschicht für eine zweite Protokollschicht (10), die so ausgelegt ist, dass die Daten der ersten Protokollschicht in aufeinander folgende Datenpakete der zweiten Protokollschicht aufgeteilt werden, die eine Reihenfolge von aufeinander folgenden Datenpaketen mit Folgenummern generiert, wodurch ein Datenpaket der zweiten Protokollschicht Daten aus nur einem Datenpaket der ersten Protokollschicht enthält (30), – eine Übertragungseinrichtung zum Übertragen der Datenpakete (40), – eine Empfangseinrichtung zum Empfangen der Datenpakete (60), – eine Sortiereinrichtung zum Sortieren der empfangenen Datenpakete in die Reihenfolge von aufeinander folgenden Datenpaketen mittels der Folgenummern (70), – eine Erkennungseinrichtung zum Erkennen eines vollständig kombinierten Datenpakets der ersten Protokollschicht in der Reihenfolge von aufeinander folgenden Daten (100), – eine Prüfeinrichtung zum Prüfen der Verbindung der Datenpakete der ersten Protokollschicht mit einem Datenfluss, nachdem ein vollständig kombiniertes Datenpaket der ersten Protokollschicht erkannt worden ist, – eine Freigabeeinrichtung zum Freigeben eines vollständig generierten Datenpakets an die erste Protokollschicht (100).
  25. Vorrichtung nach Anspruch 24, umfassend einen Pufferspeicher zum temporären Speichern der empfangenen Datenpakete der zweiten Protokollschicht.
DE69932184T 1998-12-22 1999-12-13 Verfahren und vorrichtung zur reduzierung der verarbeitungszeit von daten in kommunikationsnetzwerken Expired - Lifetime DE69932184T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP98124010A EP1014641A1 (de) 1998-12-22 1998-12-22 Verfahren und Vorrichtung zur Reduzierung der Aufarbeitungszeit von Daten in Kommunikationsnetzen
EP98124010 1998-12-22
PCT/EP1999/009861 WO2000038390A1 (en) 1998-12-22 1999-12-13 Method and device for reducing the processing time of data in communication networks

Publications (2)

Publication Number Publication Date
DE69932184D1 DE69932184D1 (de) 2006-08-10
DE69932184T2 true DE69932184T2 (de) 2007-06-14

Family

ID=8233163

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69932184T Expired - Lifetime DE69932184T2 (de) 1998-12-22 1999-12-13 Verfahren und vorrichtung zur reduzierung der verarbeitungszeit von daten in kommunikationsnetzwerken

Country Status (10)

Country Link
US (1) US6948108B1 (de)
EP (2) EP1014641A1 (de)
JP (1) JP4594530B2 (de)
CN (1) CN1287576C (de)
AT (1) ATE332051T1 (de)
AU (1) AU760994B2 (de)
CA (1) CA2356900A1 (de)
DE (1) DE69932184T2 (de)
ES (1) ES2270631T3 (de)
WO (1) WO2000038390A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102377805A (zh) * 2010-08-20 2012-03-14 贺心雅 自动腹膜透析无线网络系统及数据传输方法

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3525869B2 (ja) * 2000-07-12 2004-05-10 日本電気株式会社 パケット通信システムの接続装置及び方法
FR2818066B1 (fr) 2000-12-12 2003-10-10 Eads Airbus Sa Procede et dispositif de transmission deterministe de donnees asynchrones mises en paquet
FR2818844B1 (fr) * 2000-12-22 2003-03-07 Mitsubishi Electricite Procede de transmission de donnees entre au moins un emetteur et au moins un recepteur, emetteur, recepteur et systeme de transmission correspondants
US7099326B2 (en) * 2001-02-23 2006-08-29 Nokia Inc. System and method for fast GPRS for IPv6 communications
US7096261B2 (en) * 2001-03-12 2006-08-22 Qualcomm Incorporated Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
EP1253736A3 (de) * 2001-04-26 2003-12-10 NTT DoCoMo, Inc. Datenübertragungsstreckensteuerung für mobile Kommunikation
US20030002467A1 (en) * 2001-06-29 2003-01-02 Leung Nikolai K.N. Internet protocol framing using radio link protocol
KR100469720B1 (ko) * 2001-10-15 2005-02-02 삼성전자주식회사 이동통신시스템에서 과금장치 및 방법
TWI283976B (en) * 2003-09-30 2007-07-11 Broadcom Corp Classifier for IEEE 802.11g receiver
US7269146B2 (en) * 2003-10-20 2007-09-11 Motorola Inc. Method and apparatus for interchanging and processing mobile radio subsystem control information
US7814219B2 (en) * 2003-12-19 2010-10-12 Intel Corporation Method, apparatus, system, and article of manufacture for grouping packets
KR100583872B1 (ko) * 2004-03-17 2006-05-26 주식회사 팬택앤큐리텔 기지국의 상향 링크 패킷 전송 방법 및 그 방법이 구현된이동통신 시스템
US7586882B2 (en) 2004-03-19 2009-09-08 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using RLP
WO2005094020A1 (en) * 2004-03-19 2005-10-06 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using rlp
US7626926B2 (en) * 2004-12-09 2009-12-01 Airvana, Inc. Traffic management in a wireless data network
JP5210895B2 (ja) * 2008-02-20 2013-06-12 株式会社日立製作所 無線通信システム、端末及び基地局
CN101729224A (zh) * 2008-10-20 2010-06-09 富士通株式会社 传输数据生成装置和接收机
CN102761571B (zh) * 2011-04-28 2014-11-12 上海市特种设备监督检验技术研究院 电梯智能物联终端
CN110149670A (zh) 2018-02-13 2019-08-20 华为技术有限公司 一种数据路由选择的方法及装置

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4703475A (en) * 1985-12-04 1987-10-27 American Telephone And Telegraph Company At&T Bell Laboratories Data communication method and apparatus using multiple physical data links
JPS6399651A (ja) * 1986-10-15 1988-04-30 Nec Corp デ−タ通信方式
US5243592A (en) * 1990-10-15 1993-09-07 Digital Equipment Corporation Method and apparatus for distance vector routing on datagram point-to-point links
JPH04291556A (ja) * 1991-03-20 1992-10-15 Fujitsu Ltd 通信制御方式
US6088342A (en) * 1997-05-05 2000-07-11 Nokia Mobile Phones Limited Dynamic configuration of radio link protocol in a telecommunications system
US5570367A (en) * 1994-07-29 1996-10-29 Lucent Technologies Inc. Asymmetric protocol for wireless communications
FI98027C (fi) * 1995-01-10 1997-03-25 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten
FI97927C (fi) * 1995-05-09 1997-03-10 Nokia Telecommunications Oy Ei-transparentti datansiirto digitaalisessa tietoliikennejärjestelmässä
FI98174C (fi) * 1995-05-09 1997-04-25 Nokia Telecommunications Oy Datansiirtojärjestelmä, jossa on liukuvaan ikkunaan perustuva datavuonohjaus
US5729536A (en) * 1996-04-10 1998-03-17 Lucent Technologies Cellular system architectures supporting data services
US5936965A (en) * 1996-07-08 1999-08-10 Lucent Technologies, Inc. Method and apparatus for transmission of asynchronous, synchronous, and variable length mode protocols multiplexed over a common bytestream
US5708656A (en) * 1996-09-11 1998-01-13 Nokia Mobile Phones Limited Method and apparatus for packet data transmission
KR100260516B1 (ko) * 1997-04-01 2000-07-01 정선종 코드분할 다중접속 이동통신망에서의 비동기통신 데이터발신호 및 착신호 서비스 방법
JPH10341487A (ja) * 1997-04-09 1998-12-22 Sony Corp 情報端末装置、情報処理方法、情報提供装置および方法、情報ネットワークシステム、並びに提供媒体
KR19990001580A (ko) * 1997-06-16 1999-01-15 양승택 Cdma 이동통신망을 이용한 g3 팩스 서비스 방법
US6314101B1 (en) * 1997-06-17 2001-11-06 Qualcomm Incorporated Method for detecting delayed data frames in a transport function
US6011796A (en) * 1997-06-17 2000-01-04 Qualcomm Incorporated Extended range sequence numbering for selective repeat data transmission protocol
US6236647B1 (en) * 1998-02-24 2001-05-22 Tantivy Communications, Inc. Dynamic frame size adjustment and selective reject on a multi-link channel to improve effective throughput and bit error rate
US5862452A (en) * 1997-10-20 1999-01-19 Motorola, Inc. Method, access point device and peripheral devices for low complexity dynamic persistence mode for random access in a wireless communication system
US6226301B1 (en) * 1998-02-19 2001-05-01 Nokia Mobile Phones Ltd Method and apparatus for segmentation and assembly of data frames for retransmission in a telecommunications system
US6112084A (en) * 1998-03-24 2000-08-29 Telefonaktiebolaget Lm Ericsson Cellular simultaneous voice and data including digital simultaneous voice and data (DSVD) interwork
US6307867B1 (en) * 1998-05-14 2001-10-23 Telefonaktiebolaget Lm Ericsson (Publ) Data transmission over a communications link with variable transmission rates
US6310893B1 (en) * 1998-06-17 2001-10-30 Genuity Inc. Method and system for connectionless communication in a cell relay satellite network
US6160804A (en) * 1998-11-13 2000-12-12 Lucent Technologies Inc. Mobility management for a multimedia mobile network
US6169732B1 (en) * 1999-06-29 2001-01-02 Motorola, Inc. Method and apparatus in a wireless communication system
US6301479B1 (en) * 1999-07-08 2001-10-09 Telefonaktiebolaget Lm Ericsson Technique for providing a secure link in a mobile communication system
US6317224B1 (en) * 1999-09-17 2001-11-13 Motorola, Inc. Method and apparatus for modifying facsimile data transfer rates based upon varying bit rates of a transport medium

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102377805A (zh) * 2010-08-20 2012-03-14 贺心雅 自动腹膜透析无线网络系统及数据传输方法

Also Published As

Publication number Publication date
US6948108B1 (en) 2005-09-20
CN1287576C (zh) 2006-11-29
EP1142263B1 (de) 2006-06-28
CN1331877A (zh) 2002-01-16
EP1142263A1 (de) 2001-10-10
JP4594530B2 (ja) 2010-12-08
AU760994B2 (en) 2003-05-29
WO2000038390A1 (en) 2000-06-29
DE69932184D1 (de) 2006-08-10
AU2096300A (en) 2000-07-12
JP2002534001A (ja) 2002-10-08
EP1014641A1 (de) 2000-06-28
CA2356900A1 (en) 2000-06-29
ATE332051T1 (de) 2006-07-15
ES2270631T3 (es) 2007-04-01

Similar Documents

Publication Publication Date Title
DE69932184T2 (de) Verfahren und vorrichtung zur reduzierung der verarbeitungszeit von daten in kommunikationsnetzwerken
DE60102809T2 (de) Datenpaketnummerierung bei der paketvermittelten datenübertragung
DE60214144T2 (de) Verfahren und Vorrichtung zur bereitstellung von unterschiedlichen Dienstqualitätsstufen in einer Funkpaketdatendienstverbindung
DE3904403C2 (de)
DE69828572T2 (de) Verfahren und vorrichtung zur umlenkung einer verbindung in einer verbindung in einem fernmeldenetz mit einer vielzahl von netzelementen
DE60007829T2 (de) Kopfkomprimierung für General Packet Radio Service Tunnel Protokoll (GTP)
DE60131890T2 (de) Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung
DE69731276T2 (de) Verfahren zur angabe der grösse von minizellen
DE60102810T2 (de) Datenpaketnummerierung bei der paketvermittelten datenübertragung
DE60300354T2 (de) Methode zur Rekonstruktion paketisierter Nachrichten, die über ein oder mehrere Netzwerke verschickt wurden
EP1405422B1 (de) Verfahren zur optimierten nutzung von sctp (stream control transmission protocol) in mpls (multi protocol label switching) netzen
DE19730159B4 (de) Kommunikationsverfahren und System
DE19532422C1 (de) Lokales, nach dem asynchronen Transfermodus (ATM) arbeitendes Netzwerk mit wenigstens zwei Ringsystemen
EP1252787A1 (de) Verfahren zum betreiben eines mobilfunknetzes
DE10008148A1 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE60029852T2 (de) Verfahren und Anordnung zur Einschränkung der Übertragung von Datenpaketen in einem digitalen mobilen Fernsprechnetz
EP0794680A2 (de) Verfahren zum Betreiben einer Breitband-Verbindung zwischen einem Mobilfunk-Endgerät und einer netzseitigem Mobilfunkeinrichtung sowie Mobilfunk-Endgerät, netzseitige Mobilfunkeinrichtung und Mobilfunksystem
DE60111022T2 (de) Verfahren und system für datenkommunikation zwischen einer mobilen und einer packetvermittelten kommunikationsarchitektur
DE10147755B4 (de) Verfahren und Vorrichtungen zur Header-Kompression in paketorientierten Netzwerken
DE69922369T2 (de) Verfahren und vorrichtung zur erhöhung eines datendurchsatzes
DE69530886T2 (de) Prüfung der Echtheit von zwischen zwei Stationen eines Telecommunikationsnetz übertragenen Daten
EP1102441A1 (de) Verfahren und Vorrichtung zur Verbesserung eines Datendurchsatzes in einem Kommunikationssystem
DE69932855T2 (de) Verfahren und systeme zur übermittlung von ss7-nachrichten
EP1312992A1 (de) Verfahren zum Tunneln eines höherwertigen Protokolls auf einem Feldbussystem
DE60034193T2 (de) Datenumsetzungsgeräte und -verfahren

Legal Events

Date Code Title Description
8364 No opposition during term of opposition