DE60215953T2 - Nichttransparente datenübertragung in einem mobilnetzwerk - Google Patents

Nichttransparente datenübertragung in einem mobilnetzwerk Download PDF

Info

Publication number
DE60215953T2
DE60215953T2 DE60215953T DE60215953T DE60215953T2 DE 60215953 T2 DE60215953 T2 DE 60215953T2 DE 60215953 T DE60215953 T DE 60215953T DE 60215953 T DE60215953 T DE 60215953T DE 60215953 T2 DE60215953 T2 DE 60215953T2
Authority
DE
Germany
Prior art keywords
data
rlp
frame
frames
radio link
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
DE60215953T
Other languages
English (en)
Other versions
DE60215953D1 (de
Inventor
Jukka Ala-Vannesluoma
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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Application granted granted Critical
Publication of DE60215953D1 publication Critical patent/DE60215953D1/de
Publication of DE60215953T2 publication Critical patent/DE60215953T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • 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
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • H04W28/14Flow control between communication endpoints using intermediate storage
    • 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/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/08Access restriction or access information delivery, e.g. discovery data delivery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24Transfer of terminal data
    • H04W8/245Transfer of terminal data from a network towards a terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02Data link layer protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Communication Cables (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung betrifft Funksysteme und insbesondere die nichttransparente Datenübertragung in einem Mobilkommunikationssystem.
  • HINTERGRUND DER ERFINDUNG
  • Mobilkommunikationssysteme beziehen sich im Allgemeinen auf verschiedene Telekommunikationssysteme, die eine persönliche drahtlose Datenübertragung ermöglichen, wenn Teilnehmer sich im Bereich des Systems bewegen. Ein typisches Mobilkommunikationssystem ist ein öffentliches Landmobilfunknetz PLMN (Public Land Mobile Network), das auf der Erdoberfläche eingerichtet ist.
  • In Mobilkommunikationssystemen der zweiten und dritten Generation, wie beispielsweise im GSM (Globales System für mobile Kommunikation) beziehungsweise im UMTS (Universelles Mobilfunktelekommunikationssystem), werden Sprache und Daten in digitaler Form übertragen. In digitalen Mobilkommunikationssystemen gibt es zusätzlich zur herkömmlichen Sprachübertragung eine Mehrzahl andere Dienste, die verfügbar sind: Kurznachrichten, Telefax, Datenübertragung usw. Die Dienste der Mobilkommunikationssysteme können im Allgemeinen in Teledienste und Trägerdienste unterteilt werden. Ein Trägerdienst ist ein Telekommunikationsdienst, welcher eine Signalübertragung zwischen Benutzer-Netz-Schnittstellen bildet. Zum Beispiel sind Modem-Dienste und verschiedene Datenübertragungsdienste Trägerdienste. In einem GSM-Mobilfunknetz zum Beispiel sind leitungsvermittelte Datendienste definiert, welche verschiedene Datenraten bis zu 14,4 kbit/s verwenden. Bei HSCSD-Diensten (Diensten mit hochbitratigen leitungsvermittelten Daten nach engl. High Rate Circuit Switched Data) werden mehrere Dutzende von Kilobits jede Sekunde erreicht. Bei Telediensten stellt das Netz auch Endgerätedienste bereit. Sprach-, Fax- und Videotexdienste sind wichtige Teledienste.
  • Trägerdienste werden im Allgemeinen gemäß einigen Eigenschaften in verschiedene Gruppen unterteilt, zum Beispiel asynchrone Trägerdienste und synchrone Trägerdienste. Jede dieser Gruppen umfasst eine Anzahl von Trägerdiensten, wie beispielsweise einen transparenten Dienst (T) und einen nichttransparenten Dienst (NT). Bei einem transparenten Dienst sind die zu übertragenden Daten unstrukturiert, und die Übertragungsfehler werden nur mit einer Kanalcodierung korrigiert. Bei nichttransparenten Diensten werden die zu übertragenden Daten zu Datenpaketen, d.h. Protokolldateneinheiten (PDU für eng. Protocol Data Units), strukturiert, und die Übertragungsfehler werden unter Verwendung von automatischen Wiederholungssendungsprotokollen (zusätzlich zur Kanalcodierung) korrigiert. Das GSM-System zum Beispiel verwendet zwei Protokolle zur nichttransparenten Datenübertragung, d.h. das Funkverbindungsprotokoll (RLP für eng. Radio link Protocol) und das Verbindungsprotokoll L2R (Schicht-2-Brückenfunktion nach engl. Layer 2 Relay). Solche Verbindungsprotokolle sind im Allgemeinen als Verbindungszugangssteuerung LAC (für eng. Link Access Control) bekannt.
  • Die L2R-Schicht positioniert die zu sendenden Daten in L2R-Rahmen, welche an die RLP-Schicht übermittelt werden, um weiter übertragen zu werden. Im GSM-System unterstützt die RLP-Schicht mehrere Datenraten, d.h. in der Praxis mehrere verschiedene Kanalcodierungen. Um verschiedene Datenraten zu implementieren, hat die RLP-Schicht zwei RLP-Rahmenlängen verfügbar, auf welchen die zu übertragenden Daten positioniert werden: eine von 240 Bits und die andere von 576 Bits. Die RLP-Rahmenlänge, die in der Datenübertragungsverbindung verwendet wird, muss während der Datenübertragung in eine andere Rahmenlänge umgeändert werden können, falls nötig, wodurch sowohl das Sender-RLP als auch das Empfänger-RLP neu synchronisiert werden müssen, d.h. die Daten neu zugeordnet werden müssen. Dies findet normalerweise derart statt, dass das Empfänger-RLP Informationen über die RLP-Rahmennummer angibt, deren Empfang. als Nächstes zu erwarten ist, und das Sender-RLP als Reaktion darauf die Benutzerdaten, die nach dem RLP-Rahmen gesendet werden, aus dem Übertragungspuffer entpackt und in neue RLP-Rahmen von einer anderen Länge positioniert. Eine Datenübertragung kann natürlich in beiden Richtungen, d.h. von der Mobilstation zum Netz und vom Netz zur Mobilstation, erfolgen. Demnach werden Informationen über die RLP-Rahmennummer, deren Empfang als Nächstes zu erwarten ist, sowohl vom Empfänger-RLP der Mobilstation als auch des Netzes an das Sender-RLP der Gegenseite vermittelt.
  • Es sind drei verschiedene Version für das RLP-Protokoll definiert: Version 0, 1 und 2. Das GSM-System verwendet alle drei Versionen, wohingegen das UMTS-System nur Version 2 verwendet. Die Datenpakete, die von der L2R-Schicht an die RLP-Schicht übergeben werden, um übertragen zu werden, können Benutzerdaten, Fülldaten und Statusinformationen umfassen, welche Informationen enthalten, die den Status der Datenübertragung definieren. Die Länge des Datenpakets, das von der L2R-Schicht an die RLP-Schicht übergeben wird, hängt von der Kanalcodierung ab, die in jedem Einzelfall verwendet wird. Wenn Version 0 oder 1 des RLP-Protokolls verwendet werden, müssen die Statusinformationen in jedem Datenpaket der L2R-Schicht gesendet werden, aber in der RLP-Version 2 werden die Statusinformationen nur dann gesendet, wenn sich der Status der Datenübertragung auf irgendeine Weise geändert hat.
  • Ein Problem in dem zuvor beschriebenen System ist die Situation, in welcher bei Verwenden von RLP-Version 2 fast unmittelbar, nachdem die Statusaktualisierung vom Endgerät gesendet wurde, eine Neuzuordnungsanforderung vom Netz ankommt, welche fordert, dass die RLP-Rahmen, die vor der Statusaktualisierung gesendet wurden, erneut gesendet werden. Demnach entsteht eine Situation, in welcher das Endgerät die Statusinformationen zwar bereits gesendet hat, das Endgerät aber sogar danach eine Wiederholungssendung von RLP-Rahmen anfordert, welche die Statusinformationen enthalten. In solch einem Fall kann es eine erhebliche Verzögerung bei der Aktualisierung der Statusinformationen auf der Netzseite geben, insbesondere wenn es eine große Menge an Informationen gibt, die erneut zu senden sind, und die Statusinformationen im Wesentlichen in den letzten Rahmen gesendet werden. Wenn die Statusaktualisierung zum Beispiel eine Datenträgererfassung (DCD für engl. Data Carrier Detect) betrifft, die mit einer langen Verzögerung übertragen wird, kann demnach die Datenübertragung ganz beendet werden.
  • KURZE BESCHREIBUNG DER ERFINDUNG
  • Eine Aufgabe der Erfindung ist es, eine Anordnung bereitzustellen, mit deren Hilfe das Endgerät und das Netz über dieselben aktualisierten Informationen über den Status des Endgeräts verfügen. Die Aufgaben der Erfindung werden mit einem Verfahren, einem Mobilkommunikationssystem und einer Vorrichtung eines Mobilkommunikationssystems, wie beispielsweise einer Mobilstation oder einer Basissendeempfangsstation, welche dadurch gekennzeichnet sind, was in den unabhängigen Ansprüchen dargelegt ist, erreicht.
  • Die bevorzugten Ausführungsformen der Erfindung werden in den abhängigen Ansprüchen offenbart.
  • Die Erfindung basiert auf der Idee, dass die Statusinformationen über die L2R-Schicht jedes Mal gesendet werden, wenn sich die Länge des RLP-Rahmens infolge einer Kanalcodierungsänderung ändert. Demnach werden die Statusinformationen über die L2R-Schicht vorzugsweise jedes Mal gesendet, wenn sich die RLP-Rahmenlänge ändert, ungeachtet dessen, wann sich der Status zuletzt geändert hat.
  • In Verbindung mit der Kanalcodierungsänderung leiten das Endgerät und das Netz eine Neuzuordnung der zu übertragenden RLP-Rahmen oder, was mit anderen Worten ein Neuzuordnungsprozess genannt wird, ein. Hierbei beginnen das Endgerät und das Netz, die Daten erneut zu senden, die in jenen RLP-Rahmen enthalten sind, die nach dem RLP-Rahmen gesendet wurden, den die Gegenseite als zuletzt empfangenen gemeldet hat. Demnach werden die RLP-Rahmen, die nach dem RLP-Rahmen gesendet wurden, den die Gegenseite als zuletzt empfangenen gemeldet hat, aus dem Übertragungsspeicher in die L2R-Schicht kopiert, welche die Daten der Rahmen in einen Neuzuordnungspuffer entpackt, wobei die Daten im Puffer in Benutzerdatenfeldern von RLP-Rahmen von verschiedenen Längen angeordnet werden, wodurch die Statusinformationen über die L2R-Schicht vorzugsweise mit dem ersten RLP- Rahmen verbunden werden, der an das Netz zu senden ist, ungeachtet dessen, wann sich der Status zuletzt geändert hat.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung ist die L2R-Schicht so ausgelegt, dass sie den ersten RLP-Rahmen, der aus dem RLP-Übertragungsspeicher an die L2R-Schicht übertragen wird, derart interpretiert, dass der Neuzuordnungsprozess eingeleitet wurde. Dementsprechend zeigt dies der L2R-Schicht an, dass die L2R-Statusinformationen nach dem Neuzuordnungsprozess an den ersten RLP-Rahmen einer anderen Länge anzuhängen sind.
  • Ein Vorteil des Verfahrens und des Systems der Erfindung ist, dass sowohl das Endgerät als auch das Netz stets aktualisierte Informationen über den gegenseitigen L2R-Status empfangen, was den Wirkungsgrad der Datenübertragung und der Protokollstruktur verbessert. Außerdem kann vorzugsweise bestätigt werden, dass es keine solche problematische Situation gibt, in welcher die Gegenseite veraltete L2R-Informationen aufweisen würde. Ein Vorteil einer Ausführungsform der Erfindung ist, dass bestätigt werden kann, dass jedes Mal, wenn in Verbindung mit dem Neuzuordnungsprozess RLP-Rahmen in den Neuzuordnungspuffer gesammelt werden, der erste RLP-Rahmen einer neuen Länge, der an die Gegenseite gesendet wird, die L2R-Statusinformationen enthält.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird nun in Verbindung mit bevorzugten Ausführungsformen unter Bezugnahme auf die angehängten Zeichnungen ausführlicher beschrieben, wobei:
  • 1 ein Blockdiagramm der Struktur des GSM-Systems darstellt;
  • 2 Protokolle und Anpassungen darstellt, die für nichttransparente Trägerdienste erforderlich sind;
  • 3 einen Zeichengabeplan einer problematischen Situation gemäß dem Stand der Technik bei der Übertragung von nichttransparenten Daten darstellt;
  • 4 einen Zeichengabeplan des Neuzuordnungsprozesses gemäß einer Ausführungsform der Erfindung darstellt; und
  • 5 einen Zeichengabeplan von mehreren Neuzuordnungsprozessen gemäß einer zweiten Ausführungsform der Erfindung darstellt.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • Im Folgenden wird die Erfindung unter Verwendung einer nichttransparenten Datenübertragung, die im GSM-System implementiert wird, als ein Beispiel ausführlicher beschrieben. Die Erfindung ist jedoch nicht auf das GSM-System beschränkt, sondern kann auf jedes Mobilkommunikationssystem angewendet werden, in welchem nichttransparente Datenübertragungsdienste einer entsprechenden Art implementiert werden. Insbesondere kann die Erfindung bei Verwendung dessen, was Dualmodus-Mobilstationen genannt wird, die sowohl im GSM- als auch im UMTS-Netz funktionieren, im UMTS-Mobilkommunikationssystem der dritten Generation (3G) implementiert werden.
  • 1 veranschaulicht die Struktur des GSM-Systems. Das GSM-System umfasst Mobilstationen (MS), die über einen Funkweg mit Basissendeempfangsstationen (BTS für engl. Base Transceiver Station) in Verbindung stehen. Mehrere Basissendeempfangsstationen BTS sind mit einer Basisstationssteuerung (BSC für engl. Base Station Controller) verbunden, welche die Funkfrequenzen und Funkkanäle steuert, die für die Basissendeempfangsstationen verfügbar sind. Die Basisstationssteuerung BSC und die damit verbundenen Basissendeempfangsstationen BTS bilden ein Basisstationssubsystem (BSS). Die Basisstationssteuerungen sind ihrerseits mit einer Mobildienstevermittlungseinrichtung (MSC für engl. Mobile Services Switching Centre) verbunden, welche den Verbindungsaufbau und die Leitweglenkung von Rufen zu den korrekten Adressen erledigt. Hierbei werden zwei Datenbanken als Hilfe verwendet, wobei die Datenbanken Informationen über Mobilstationsteilnehmer umfassen: eine Heimatdatei (HLR für engl. Home Location Register), die Informationen über alle Teilnehmer am Mobilnetz und über die von ihnen abonnierten Dienste umfasst, und eine Besucherdatei (VLR für engl. Visitor Location Register), die Informationen über Mobilstationen umfasst, die eine bestimmte Mobildienstevermittlungseinrichtung MSC besuchen. In Verbindung mit der Mobildienstevermittlungseinrichtung MSC gibt es normalerweise eine TRAU-Einheit (Transcodier- und Ratenanpasseinheit nach engl. Transcoder/Rate Adaptation Unit), d.h. eine Netzanpassungsfunktion IWF (für engl. Interworking Function), welche die Daten, die in TRAU-Rahmen positioniert sind, entpackt und die Datenübertragungsrate und die Rahmenstruktur in solch eine Form umwandelt, dass die Daten weiter übertragen werden können. Die Mobildienstevermittlungseinrichtung MSC ist ihrerseits über eine Übergangsmobildienstevermittlungseinrichtung GMSC (für engl. Gateway Mobile Services Switching Centre) mit anderen Modildienstevermittlungseinrichtungen und mit einem öffentlichen Telefonwählnetz (PSTN für eng. Public Switched Telephone Network) verbunden. Das GSM-System wird in den ETSI/GSM-Spezifikationen und in dem Buch The GSM System for Mobile Communications von M. Mouly und M. Pautet, Palaiseau, Frankreich, 1991, ISBN: 2-957190-07-7, ausführlicher beschrieben.
  • Wenn eine nichttransparente GSM-Datenverbindung mit einer Mobilstation MS hergestellt wird, werden die zu übertragenden Daten in RLP-Rahmen (Funkverbindungsprotokoll) positioniert. Das RLP ist ein rahmenstrukturiertes, symmetrisches Datenübertragungsprotokoll (der HDLC- oder Hochpegeldatenübertragungssteuerungsart nach engl. Highlevel Data Link Control), in welchem eine Fehlerkorrektur auf einer Wiederholungssendung von verfälschten Rahmen auf Anforderung vom empfangenden Partner basiert. Da die Verantwortung für die Korrektheit der zu übertragenden Daten einer Protokollschicht zugewiesen wird, wird eine umfangreiche Zeichengabe zwischen Elementen der Datenübertragungskette vermieden. Im GSM-System findet die Datenübertragung, die in den RLP-Rahmen durchgeführt wird, zwischen einer Mobilstation und/oder einer Endgeräteanpassungsfunktion TAF (Terminal Adapation Function) in einem damit verbundenen Datenendgerät und normalerweise einer Netzanpassungsfunktion in einer Mobildienstevermittlungseinrichtung MSC statt.
  • 2 veranschaulicht einige Protokolle und Funktionen, die für nichttransparente Trägerdienste erforderlich sind. Eine nichttransparente leitungsvermittelte Verbindung zwischen der Endgeräteanpassung TAF und der Netzanpassungsfunktion IWF auf dem GSM-Verkehrskanal umfasst mehrere Protokollschichten, welche all diesen Diensten gemeinsam sind. Diese umfassen verschiedene Ratenanpassungsfunktionen RA, wie beispielsweise RA1' zwischen der Endgeräteanpassung TAF und einer Kanal-Codec-Einheit CCU (Channel Codec Unit), die in der Basisstationssubsystem BSS positioniert ist, RA1 zwischen der CCU und der Netzanpassungsfunktion IWF, RAA (oder RAA' zum Kanal von 14,4 kbit/s) zwischen der CCU und der Transcoder-Einheit TRAU, die getrennt von der Basissendeempfangsstation positioniert ist, und RA2 zwischen der Transcoder-Einheit TRAU und der Netzanpassungsfunktion IWF. Die IWF und die TAF umfassen ferner Protokolle von oberen Schichten, welche dienstspezifisch sind. In einem asynchronen nichttransparenten Trägerdienst müssen die IWF und die TAF die L2R (Schicht-2-Brückenfunktion) und das RLP (Funkverbindungsprotokoll) umfassen, zusätzlich zu dem die IWF noch ein Modem oder eine Ratenanpassung in der Richtung des Festnetzes benötigt. Die Schnittstelle zwischen der IWF und zum Beispiel einem Audiomodem MODEM entspricht dem CCITT V.24 und ist in 2 durch das Symbol L2 gekennzeichnet. Diese nichttransparente Konfiguration wird auch beim Zugang zum Internet verwendet.
  • Die L2R-Schicht positioniert die zu übertragenden Daten, die von der Anwendung kommen, in den L2R-Rahmen, welche an die RLP-Schicht übermittelt werden, um weiter übertragen zu werden. Im GSM-System unterstützt die RLP-Schicht mehrere Datenraten, d.h. in der Praxis mehrere verschiedene Kanalcodierungen. Um verschiedene Datenraten zu implementieren, hat die RLP-Schicht zwei RLP-Rahmen von verschiedenen Längen verfügbar, in welchen die zu übertragenden Daten positioniert werden; einen von 240 Bits und den anderen von 576 Bits. Nötigenfalls muss der RLP-Rahmen, der in der Datenübertragungsverbindung verwendet wird, während der Datenübertragung in einen Rahmen einer anderen Länge umgeändert werden können, wodurch sowohl das Sender-RLP als auch das Empfänger-RLP neu synchronisiert werden müssen.
  • Es sind drei verschiedene Versionen für das RLP-Protokoll definiert: Version 0, 1 und 2. Das GSM-System verwendet alle drei Versionen, wohingegen das UMTS-System nur Version 2 verwendet. Die Datenpakete, die von der L2R-Schicht an die RLP-Schicht übergeben werden, um übertragen zu werden, können Benutzerdaten, Fülldaten und Statusinformationen umfassen, welche Informationen enthalten, die den Status der Datenübertragung definieren. Die Länge des Datenpakets, das von der L2R-Schicht an die RLP-Schicht übergeben wird, hängt von der Kanalcodierung ab, die in jedem Einzelfall verwendet wird. Die Statusinformationen können zum Beispiel Informationen über die Endeinrichtung, die zum Senden und Empfangen von Daten bereit ist (DTR, Data Terminal Ready oder Endgerät Betriebsbereit), die Trägerwelle der Datenübertragung, die erfasst wird, oder die bestehende Datenübertragungsverbindung (DCG, Data Carrier Detect), oder Flusssteuerungsinformationen, mit deren Hilfe die Datenübertragung der Gegenseite zum Beispiel in einer Situation gesteuert wird, in welcher der Empfängerpuffer voll wird.
  • Die Mobilstation und/oder die damit verbundene Datenendeinrichtung MT verwenden eine Datenanwendung, welche Benutzerdaten UD (User Data) bildet, welchen ein PPP (Punkt-zu-Punkt-Protokoll)-Kopf hinzugefügt wird, der die Datenverbindung und die zuvor beschriebenen L2R-spezifischen Daten definiert. Die Daten, die auf diese Weise gebildet werden, werden ferner in RLP-Rahmen angeordnet, deren Länge, wie bereits erwähnt, 240 oder 576 Bits betragen kann. Die RLP-Rahmen von 240 Bits umfassen einen 16-Bit-Kopf, ein 200-Bit-Benutzerdatenfeld und eine 24-Bit-Rahmenprüfzeichenfolge FCS (Frame Check Sequence), um die Fehler auf dem Übertragungsweg zu erfassen. Solch ein 240-Bit-RLP-Rahmen wird in Version 0 und 1 verwendet, und auch in Version 2, wenn nicht nummerierte Protokollsteuerinformationen (U-Rahmen) im Rahmen verwendet werden. Wenn andererseits entweder nur Steuerformationen (S-Rahmen) oder Steuerinformationen, die an die Benutzerinformationen angehängt werden (I + S-Rahmen), im RLP-Rahmen von Version 2 übertragen werden, betragen die entsprechenden Feldlängen 24 + 92 + 24 Bits. Dementsprechend können die Köpfe in den 576-Bit-RLP-Rahmen zwischen 16 und 24 Bits variieren, wodurch die Länge des Benutzerdatenfeldes 536 oder 528 Bits beträgt. Die Länge der Rahmenprüfzeichenfolge FCS beträgt stets 24 Bits.
  • Die Datenübertragungsrate, die bei 240-Bit-RLP-Rahmen vorgesehen ist, beträgt entweder 4,8 oder 9,6 kbit/s. Der 576-Bit-RLP-Rahmen verwendet 14,4 kbit/s als seine Übertragungsrate. Die zuvor beschriebene Ratenanpassung RA wird für diese Daten derart durchgeführt, dass die Datenübertragung über die Funkschnittstelle, die von der Mobilstation MS/MT zur Basissendeempfangsstation BTS gebildet wird, stets in Übereinstimmung mit den GSM-Spezifikationen in einem Verkehrskanalzeitrahmen bei einer Rate von 22,8 kbit/s stattfindet.
  • Im HSCSD-Konzept des GSM-Systems wird ein hochbitratiges Datensignal in getrennte Datenflüsse geteilt, welche dann über N Unterkanäle (N Verkehrskanalrahmen) auf der Funkschnittstelle übertragen werden. Wenn die Datenflüsse geteilt wurden, werden sie in Unterkanälen übertragen, als ob sie unabhängig voneinander wären, bis sie in der IWF und der MS verknüpft werden. Logischerweise jedoch sind diese N Verkehrsunterkanäle Teile derselben HSCSD-Verbindung, d.h. sie bilden einen HSCSD-Verkehrskanal. Diese Teilung und Verknüpfung der Datenflüsse wird im RLP gemäß Version 2 durchgeführt, welches demnach allen Unterkanälen gemeinsam ist. Unter diesem gemeinsamen RLP werden dieselben Ratenanpassungen RA1'-RAA-RA2 für jeden Unterkanal durchgeführt, wie in 2 für einen Unterkanal zwischen MS/TAF und MSC/IWF dargestellt. Demnach verwendet ein HSCSD-Verkehrskanal ein gemeinsames RLP für verschiedene Unterkanäle, obwohl die Datenrate auf einem einzelnen Unterkanal wenigstens 43,2 kbit/s und die Gesamtdatenrate 64 kbit/s betragen kann.
  • Demnach kann die Datenübertragungsrate eines Verkehrskanals wenigstens zwischen 4,8, 9,6, 28,8 und 43,2 kbit/s gemäß der verwendeten Anzahl von verschiedenen Kanalcodierungen und HSCSD-Unterkanälen variieren. Diese Kanalcodierung und der RLP-Rahmen, die verwendet werden, müssen während der Datenübertragung in andere umgeändert werden können. Somit müssen sowohl das Sender-RLP als auch das Empfänger-RLP neu synchronisiert werden.
  • In Version 0 und 1 des RLP-Protokolls werden die Statusinformationen der L2R-Schicht in jedem RLP-Rahmen übertragen, was nicht optimal ist, was den Wirkungsgrad der Datenübertragung betrifft. In Version 2 der L2R-Schicht werden die Statusinformationen im RLP-Rahmen nur gesendet, wenn der Status sich auf der L2R-Schicht geändert hat. In der Datenübertragung gemäß Version 2 des RLP-Protokolls kann es demnach eine Problemsituation in der Datenübertragung geben, wenn fast unmittelbar, nachdem die Statusaktualisierung vom Endgerät übertragen wurde, das Netz versucht, die verwendete Kanalcodierung zu ändern. Demnach entsteht eine Situation, in welcher fast unmittelbar, nachdem die Statusaktualisierung vom Endgerät übertragen wurde, eine Anforderung zur Neuzuordnung vom Netz ankommt, welche fordert, dass die RLP-Rahmen, die vor der Statusaktualisierung übertragen wurden, in einer neuen Rahmenlänge angeordnet erneut gesendet werden. Somit entsteht eine Situation, in welcher das Endgerät zwar neue Statusinformationen gesendet hat, das Netz aber sogar danach fordert, dass RLP-Rahmen, welche die alten Statusinformationen umfassen, erneut gesendet werden. Wenn sich der Status des Endgeräts danach nicht ändert und wenn folglich das Endgerät keine Statusinformationen überträgt, bleiben inkorrekte Informationen über den Status des Endgeräts im Netz, was normalerweise Unterbrechungen in der Datenübertragung verursacht, bevor der Status erneut aktualisiert wird. Dies kann in einigen Fällen zur Beendigung der Datenübertragung führen.
  • Solch eine problematische Situation wird im Folgenden unter Bezugnahme auf 3 veranschaulicht. 3 stellt die Datenübertragung zwischen der L2R-Schicht des Endgeräts und der L2R-Schicht der Basissendeempfangsstation dar. Zunächst findet eine Datenübertragung in beiden Richtungen statt: das Endgerät sendet Datenpakete, welche nur Benutzerdaten umfassen, an das Netz (300), wobei die Reihenfolgenummer der Datenpakete M1 ist; und das Netz sendet Datenpakete, welche nur Benutzerdaten umfassen, an das Endgerät (302), wobei die Reihenfolgenummer dieser Datenpakete N1 ist. Das Endgerät erkennt eine Notwendigkeit zur Aktivierung einer Flusssteuerung der L2R-Schicht normalerweise, wenn zum Beispiel der Empfängerpuffer voll wird, und überträgt das Datenpaket (304, Reihenfolgenummer M2), welches nicht nur Benutzerdaten, sondern auch eine Statusaktualisierung umfasst, welche ausdrückt, dass die Flusssteuerung aktiviert werden muss. Das Netz reagiert darauf und stoppt die Übertragung von Datenpaketen der L2R-Schicht an das Endgerät (306). Das Endgerät fährt mit dem Senden von Benutzerdatenpaketen fort (308, Reihenfolgenummer M3). Nach einer gewissen Zeit überträgt das Endgerät ein Datenpaket (310, Reihenfolgenummer Mn), welches nicht nur Benutzerdaten, sondern auch eine Statusaktualisierung umfasst, welche ausdrückt, dass die L2R-Flusssteuerung deaktiviert werden kann. Im Wesentlichen geschieht es jedoch genau dann, dass das Netz eine Notwendigkeit zur Neuzuordnung von Kanalcodierung erkennt (312), was dazu führt, dass die Basissendeempfangsstation dem Endgerät einen RLP-Rahmen einer unterschiedlichen Länge im Vergleich zu jenen, die zuvor verwendet wurden, sendet, wobei der Rahmen auch Informationen über die Reihenfolgenummer des Rahmens umfasst, der durch die Basissendeempfangsstation zuletzt empfangen wurde. Nach den Bestätigungen beginnt das Endgerät damit, jene Rahmen aus dem Übertragungspuffer, welche die Basissendeempfangsstation nicht empfangen hat, erneut zu senden, wobei die Daten in den Rahmen in einer neuen Rahmenlänge angeordnet sind. Die Basissendeempfangsstation hat die Deaktivierungsnachricht der Flusssteuerung normalerweise nicht empfangen, sondern sie empfängt sie nur in den Daten, die in einer neuen Rahmenlänge angeordnet sind und in der Basissendeempfangsstation mit einer beträchtlichen Verzögerung ankommen. Während dieser Verzögerung wurde die Flusssteuerung vom Gesichtspunkt des Netzes reaktiviert, und es ist dem Netz nicht gestattet, L2R-Datenpakete an das Endgerät zu übertragen, obwohl das Endgerät bereits wesentlich früher versuchte, die Flusssteuerung zu deaktivieren. Ein entsprechendes Problem entsteht im umgekehrten Fall, in dem das Endgerät versucht, die Aktivierungsnachricht der Flusssteuerung zu übertragen, das Netz sie aber mit einer beträchtlichen Verzögerung empfängt. Demnach ist dieses Problem besonders schwierig, da das Endgerät versucht, zu verhindern, dass das Netz Datenpakete sendet, aber das Netz infolge der Verzögerung die Statusaktualisierung nicht rechtzeitig empfängt und im schlimmsten Fall Zeit hat, mehrere Datenpakete zu übertragen.
  • In dem zuvor beschriebenen Fall wird eine endgeräterzeugte Aktivierung der Flusssteuerung als ein Beispiel für eine Statusaktualisierung verwendet. Ein entsprechendes Problem entsteht jedoch bei jeder anderen Statusaktualisierung, wie beispielsweise bei der Übertragung einer DTR- oder DCD-Nachricht, oder bei der Flusssteuerung, die durch die Basissendeempfangstation aktiviert wird. Das Problem ist besonders schwierig, wenn die übertragene Statusaktualisierung eine Datenträgererfassung, d.h. eine DCD-Nachricht, betrifft. Demnach kann eine zu lange Verzögerung bei der Aktualisierung des DCD-Status dazu führen, dass die gesamte Datenübertragung beendet wird.
  • Diese Problemsituation kann mit einem Verfahren gemäß der Erfindung vermieden werden, in welchem die Statusinformationen der L2R-Schicht jedes Mal gesendet werden, wenn eine Änderung der Länge des RLP-Rahmens auf der RLP-Schicht infolge einer Kanalcodierungsänderung stattfindet. Demnach werden die Statusinformationen über die L2R-Schicht vorzugsweise jedes Mal übertragen, wenn sich die Länge des RLP-Rahmens ändert, ungeachtet dessen, ob sich der Status geändert hat oder nicht. Somit werden sowohl das Endgerät als auch das Netz stets über jeden einzelnen Status auf dem Laufenden gehalten.
  • Das Verfahren gemäß der Erfindung kann mithilfe des Zeichengabeplans gemäß 4 veranschaulicht werden, welcher auf eine vereinfachte Art und Weise die Änderung der Länge des RLP-Rahmens auf der RLP-Schicht infolge der Kanalcodierungsänderung, d.h. das, was eine Neuzuordnungsprozess genannt wird, darstellt. In der Anfangssituation von 4 werden Daten in RLP-Rahmen von 240 Bits übertragen. Die Änderung der Kanalcodierung wird von der Seite des Netzes eingeleitet, wobei das Netz einen 576-Bit-Rahmen (S-Rahmen), der nur Steuerinformationen enthält, an das Endgerät überträgt (400). Das Endgerät erkennt, dass sich die Länge des Rahmens geändert hat, und antwortet darauf mit einem REMAP_command- oder NEUZUORDNUNGS_Befehls-Rahmen (402), welcher die Reihenfolgenummer umfasst, welche vom Endgerät als Nächstes erwartet wird. Das Netz seinerseits antwortet darauf mit einem REMAP_response- oder NEUZUORDNUNGS_Antwort-Rahmen (404), welcher die Reihenfolgenummer umfasst, die vom Netz als Nächstes erwartet wird. Danach beginnen beide Partner, das Endgerät und das Netz, damit, RLP-Rahmendaten erneut zu senden, die nach dem RLP-Rahmen übertragen wurden, den die Gegenseite als zuletzt empfangen gemeldet hat. Der Prozess funktioniert in beiden RLP/L2R-Einheiten auf dieselbe Art und Weise, aber im Folgenden wird dies nur von der Seite des Endgeräts beschrieben.
  • Die 240-Bit-RLP-Rahmen, die nach dem RLP-Rahmen übertragen werden, der durch die Gegenseite als zuletzt empfangen gemeldet wurde, werden in die L2R-Schicht kopiert (406), welche die Daten in den Rahmen in einen speziellen Neuzuordnungspuffer entpackt (408). Danach werden immer, wenn die RLP-Schicht Rahmen übertragen kann, Daten im Puffer in den Benutzerdatenfeldern von 576-Bit-RLP-Rahmen angeordnet (410, neu zuordnen). Eine Zeichengabe der L2R-Schicht kann dann an diese 576-Bit-RLP-Rahmen angehängt werden, wobei Statusinformationen der L2R-Schicht vorzugsweise an den ersten 576-Bit-Rahmen, der an das Netz übertragen wird, angehängt werden (412), ungeachtet dessen, wann sich der Status zuletzt geändert hat. Demnach wird das Netz in diesem Augenblick sofort über den L2R-Status des Endgeräts unterrichtet. Auf eine entsprechende Art und Weise übergibt das Netz die Informationen über den L2R-Status des Netzes an das Endgerät. Es ist jedoch zu erwähnen, dass in der zuvor beschriebenen Implementierung die Daten, die in RLP-Rahmen übertragen werden, eine Beendigung der Datenübertragung und BREAK- (Unterbrechung) und BREAK_ACK-Nachrichten, welche die Bestätigung der Unterbrechung anzeigen, umfassen, welche stets an derselben Stelle zu übertragen sind, wo sie ursprünglich positioniert waren.
  • Demnach bestätigt das Verfahren gemäß der Erfindung vorzugsweise, dass sowohl das Endgerät als auch das Netz stets aktualisierte Informationen über den gegenseitigen L2R-Status empfangen, was den Wirkungsgrad der Datenübertragung und der Protokollstruktur verbessert. Außerdem kann vorzugsweise bestätigt werden, dass es keine derartige problematische Situation gibt, wie sie zuvor beschrieben wurde, d.h. in welcher die Gegenseite veraltete L2R-Statusinformationen aufweisen würde.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung ist die L2R-Schicht so ausgelegt, dass sie den ersten 240-Bit-RLP-Rahen, der vom RLP-Übertragungsspeicher an die L2R-Schicht übermittelt wird, derart interpretiert, dass der Neuzuordnungsprozess eingeleitet wurde. Dementsprechend zeigt dies der L2R-Schicht an, dass die L2R-Statusinformationen nach dem Neuzuordnungsprozess an den ersten 576-Bit-RLP-Rahmen angehängt werden müssen. Somit ist leicht, zu bestätigen, dass jedes Mal, wenn in Verbindung mit dem Neuzuordnungsprozess RLP-Rahmen in den Neuzuordnungspuffer gesammelt werden, der erste RLP-Rahmen einer neuen Länge, der an die Gegenseite zu übertragen ist, die L2R-Statusinformationen enthält. Es ist zu erwähnen, dass, obwohl in dem zuvor erwähnten Beispiel der Neuzuordnungsprozess als eine Änderung der Rahmenlänge von einem 240-Bit-Rahmen in einen 576-Bit-Rahmen beschrieben wurde, der Prozess gemäß der Erfindung auch umgekehrt, d.h. von einem 576-Bit-Rahmen in einen 240-Bit-Rahmen, implementiert werden kann.
  • Wenn die verwendete Kanalcodierung sich erneut sehr schnell ändert, wodurch ein neuer Neuzuordnungsprozess eingeleitet werden muss, bevor der gesamte Neuzuordnungspuffer im vorhergehenden Neuzuordnungsprozess gelöscht wurde, kann es problematisch sein, RLP-Rahmen im Neuzuordnungspuffer derart zu speichern, dass RLP-Rahmen, die vorher im Puffer gespeichert wurden, nicht verloren gehen.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung kann dies derart vermieden werden, dass die RLP-Rahmen, die so definiert sind, dass sie erneut zu senden sind, aus dem RLP-Übertragungsspeicher in den Neuzuordnungspuffer entpackt werden, wobei vom Ende, d.h. in der umgekehrten Reihenfolge zu der des RLP-Übertragungsspeichers, begonnen wird. Die Daten in diesen RLP-Rahmen werden demnach auf der L2R-Schicht entpackt und im Neuzuordnungspuffer gespeichert, wobei von den letzten freien Speicherstellen begonnen wird. Auf diese Weise kann sichergestellt werden, dass auch, wenn sich die Kanalcodierung mehrmals innerhalb eines kurzen Zeitraums änderte, Daten, die aus dem Neuzuordnungspuffer übertragen werden sollen, nicht verloren gehen. Danach entpackt die L2R-Schicht jedes Mal, wenn die RLP-Schicht Rahmen übertragen kann, Daten aus dem Neuzuordnungspuffer, wobei sie von der ersten gespeicherten Speicherstelle beginnt, und ordnet sie in dem Rahmen an, der durch die Kanalcodierung definiert wird. Auf der L2R-Schicht wird die Übertragung aus dem Neuzuordnungspuffer so lange fortgesetzt, als gespeicherte Daten zu übertragen sind, wonach die Übertragung aus dem gewöhnlichen Datenspeicher der L2R-Schicht fortgesetzt wird, welcher Benutzerdaten umfasst, die von der Anwendungsschicht ankommen. Wenn danach die RLP-Rahmen, die so definiert sind, dass sie aus dem RLP-Übertragungsspeicher erneut zu übertragen sind, in den Neuzuordnungspuffer der L2R-Schicht entpackt wurden, braucht die RLP-Schicht vorzugsweise nicht zu wissen, ob die zu übertragenden Daten aus dem Neuzuordnungspuffer oder aus dem gewöhnlichen Datenpuffer in die RLP-Rahmen eingegeben werden.
  • Bei dieser Ausführungsform kann vorzugsweise bestätigt werden, dass die Änderung der Kanalcodierung während der Datenübertragung ungeachtet dessen durchgeführt werden kann, wie schnell die nächste Änderung nach der vorhergehenden Kanalcodierungsänderung durchgeführt wird. Auch Mittel zum Entpacken von Daten in den Neuzuordnungspuffer, vorzugsweise eine Software, können auf eine einfachere Weise implementiert werden.
  • Im Folgenden wird diese Ausführungsform unter Bezugnahme auf 5 ausführlicher beschrieben. Um die Ausführungsform zu veranschaulichen, findet die Datenübertragung in der Situation gemäß 5 nur in der Aufwärtsverbindungsrichtung (d.h. vom Endgerät zum Netz) statt. Zunächst überträgt das Endgerät 240-Bit-RLP-Rahmen (500, 504, 508), welche sowohl Benutzerdaten und Steuerinformationen (I + S-Rahmen) umfassen und deren Reihenfolgenummern dementsprechend 1, 2 und 3 sind. Gleichzeitig werden diese Rahmen im RLP-Übertragungsspeicher gespeichert, wie in der Figur dargestellt. Das Endgerät überträgt 240-Bit-RLP-Rahmen (502, 506, 510), welche nur Steuerinformationen (S-Rahmen) umfassen, an das Endgerät. Nach dem dritten übertragenen RLP-Rahmen empfängt das Endgerät jedoch den 576-Bit-Rahmen (510), welcher nur Steuerinformationen (S-Rahmen) umfasst, welcher Rahmen demnach den Neuzuordnungsprozess einleitet. Das Endgerät überträgt eine 576-Bit-REMAP_command-Nachricht an das Netz (512), worauf das Netz mit einer REMAP_response -Nachricht antwortet (514), welche die Definition umfasst, dass das Endgerät die Informationen, die in den drei RLP-Rahmen enthalten sind, die zuvor in 576-Bit-RLP-Rahmen übertragen wurden, erneut übertragen muss.
  • Der RLP-Rahmen des Endgeräts leitet die Übertragung der drei RLP-Rahmen aus dem Übertragungsspeicher an die L2R-Schicht derart ein, dass zuerst der RLP-Rahmen übertragen wird, der zuletzt (NS = 3) übertragen wurde und von welchem Rahmen der L2R-Rahmen die Daten, die darin enthalten sind, decodiert und die Daten an der letzten Speicherstelle (516) des Neuzuordnungspuffers speichert. Danach wird der RLP-Rahmen übertragen, der als zweitletzter übertragen wurde (NS = 2) und dessen Daten im Neuzuordnungspuffer an der letzten freien Speicherstelle, in diesem Fall der zweitletzten Speicherstelle (518), gespeichert wird. Schließlich wird der RLP-Rahmen übertragen, der zuerst übertragen wurde (NS = 1) und dessen Daten im Neuzuordnungspuffer wieder an der letzten freien Speicherstelle, in diesem Fall der drittletzten Speicherstelle (520), gespeichert werden. Als Nächstes ordnet die L2R-Schicht Daten aus dem Neuzuordnungspuffer in einen 576-Bit-RLP-Rahmen an, hängt die L2R-Statusinformationen gemäß der zuvor dargelegten Beschreibung daran an, und überträgt den RLP-Rahmen an das Netz (522). Als Nächstes empfängt das Endgerät vom Netz einen 240-Bit-RLP-Rahmen (524), welcher nur Steuerinformationen (S-Rahmen) umfasst und welcher Rahmen dann einen neuen Neuzuordnungsprozess einleitet. Das Endgerät überträgt eine 240-Bit-REMAP_Befehls-Nachricht an das Netz (526), worauf das Netz mit einer REMAP_response-Nachricht antwortet (528), welche die Definition umfasst, dass das Endgerät die Informationen, die im 576-Bit-RLP-Rahmen enthalten sind, in 240-Bit-RLP-Rahmen erneut senden muss.
  • Es war nicht genug Platz im 576-Bit-RLP-Rahmen, der vorher übertragen wurde, für die Daten, die zuvor im Neuzuordnungspuffer gespeichert wurden, derart dass die letzte Speicherstelle noch immer Daten enthält, die noch nicht erneut gesendet wurden (530). Die RLP-Schicht des Endgeräts übergibt den 576-Bit-RLP-Rahmen aus dem Übertragungsspeicher an die L2R-Schicht, von wo die L2R-Schicht die Daten, die darin enthalten sind, decodiert und die Daten in den letzten freien Speicherstellen des Neuzuordnungspuffers derart speichert, dass die Daten nicht über den Pufferdaten gespeichert werden, die zuvor gespeichert wurden (532). Danach beginnt die L2R-Schicht mit der Anordnung von Daten aus dem Neuzuordnungspuffer in 240-Bit-Rahmen, wobei die L2R-Statusinformationen an den ersten Rahmen angehängt und mit dem ersten RLP-Rahmen an das Endgerät übertragen werden (534).
  • Für Fachleute ist zu erkennen, dass die Grundidee der Erfindung mit dem Fortschritt der Technik auf viele Arten und Weisen implementiert werden kann. Demnach sind die Erfindung und Ausführungsformen davon nicht auf die zuvor beschriebenen Beispiele beschränkt, sondern können innerhalb des Rahmens der Ansprüche variieren.

Claims (11)

  1. Verfahren zum Aktualisieren von Statusinformationen, die in einer Datenübertragung in einem Mobilkommunikationssystem enthalten sind, umfassend ein Funkverbindungsprotokoll (RLP) und ein Verbindungsprotokoll (L2R) zum Durchführen der Datenübertragung, für welches Funkverbindungsprotokoll wenigstens zwei verschiedene Rahmen von fester Länge definiert werden, und welches Verbindungsprotokoll so ausgelegt ist, dass es Statusinformationen überträgt, welche die Datenübertragung definieren, gekennzeichnet durch Einleiten einer Neuzuordnung während der Datenübertragung auf der Funkverbindungsprotokollschicht (RLP) zwischen den Rahmen; Anzeigen der Einleitung der Neuzuordnung der Verbindungsprotokollschicht (L2R); und Übertragen der aktuellen Statusinformationen über das Verbindungsprotokoll (L2R) im Rahmen des Funkverbindungsprotokolls (RLP), der nach der Neuzuordnung zuerst übertragen wird.
  2. Verfahren nach Anspruch 1, gekennzeichnet durch: Übertragen von Funkverbindungsprotokoll (RLP)-Rahmen, die Gegenstand der Neuzuordnung sind, vom Übertragungspuffer zur Verbindungsprotokollschicht (L2R); und Entpacken von Daten, die in den Rahmen enthalten sind, in einen Neuzuordnungspuffer auf der Verbindungsprotokollschicht (L2R).
  3. Verfahren nach Anspruch 2, gekennzeichnet durch: Anzeigen der Einleitung der Neuzuordnung der Verbindungsprotokollschicht (L2R) mittels des ersten Rahmens, der vom Neuzuordnungspuffer übertragen wird.
  4. Verfahren nach Anspruch 2 und 3, gekennzeichnet durch: Übertragen der Funkverbindungsprotokollschicht (RLP)-Rahmen von einem Übertragungspuffer der Funkverbindungsprotokollschicht zur Verbindungsprotokollschicht (L2R) in der umgekehrten Reihenfolge im Vergleich zum Speichern der Rahmen im Übertragungspuffer; und Speichern der Daten in den Rahmen im Neuzuordnungspuffer auf der Verbindungsprotokollschicht (L2R) beginnend vom letzten freien Speicherplatz.
  5. Verfahren nach einem der Ansprüche 2 bis 4, gekennzeichnet durch: Anordnen der Daten im Neuzuordnungspuffer in Funkverbindungsprotokollrahmen, die nach der Neuzuordnung verwendet werden; und Fortsetzen der Datenübertragung vom Übertragungsspeicher auf der Verbindungsprotokollschicht (L2R), nachdem die Daten des Neuzuordnungspuffers übertragen wurden.
  6. Mobilkommunikationssystem, umfassend eine Mobilstation und eine Basissendeempfangsstation, welche beide so ausgelegt sind, dass sie ein Funkverbindungsprotokoll (RLP) und ein Verbindungsprotokoll (L2R) in einer Datenübertragung verwenden, wobei wenigstens zwei verschiedene Rahmen von fester Länge für das Funkverbindungsprotokoll definiert sind, und das Verbindungsprotokoll so ausgelegt ist, dass es Statusinformationen überträgt, welche die Datenübertragung definieren, dadurch gekennzeichnet, dass: der Beginn einer Neuzuordnung während der Datenübertragung zwischen den Rahmen so ausgelegt ist, dass er auf der Funkverbindungsprotokollschicht (RLP) in der Datenübertragung zwischen der Mobilstation und der Basissendeempfangsstation eingeleitet wird; die Einleitung der Neuzuordnung so ausgelegt ist, dass sie der Verbindungsprotokollschicht (L2R) angezeigt wird; und die aktuellen Statusinformationen über das Verbindungsprotokoll (L2R) so ausgelegt sind, dass sie in dem Funkverbindungsprotokoll (RLP)-Rahmen übertragen werden, der nach der Neuzuordnung zuerst gesendet wird.
  7. Mobilkommunikationssystem nach Anspruch 6, dadurch gekennzeichnet, dass: die Funkverbindungsprotokoll (RLP)-Rahmen, die Gegenstand der Neuzuordnung sind, so ausgelegt sind, dass sie vom Übertragungspuffer der Funkverbindungsprotokollschicht zur Verbindungsprotokollschicht (L2R) übertragen werden; und die Daten in den Rahmen so ausgelegt sind, dass sie in den Neuzuordnungspuffer auf der Verbindungsprotokollschicht (L2R) entpackt werden.
  8. Mobilkommunikationssystem nach Anspruch 7, dadurch gekennzeichnet, dass: die Einleitung der Neuzuordnung so ausgelegt ist, dass sie der Verbindungsprotokollschicht (L2R) mittels des Rahmens angezeigt wird, der vom Übertragungspuffer zuerst übertragen wird.
  9. Mobilkommunikationssystem nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass: die Funkverbindungsprotokoll (RLP)-Rahmen so ausgelegt sind, dass sie vom Übertragungspuffer der Funkverbindungsprotokollschicht zur Verbindungsprotokollschicht (L2R) in der umgekehrten Reihenfolge im Vergleich zum Speichern der Rahmen im Übertragungspuffer übertragen werden; und Daten in den Rahmen so ausgelegt sind, dass sie im Neuzuordnungspuffer auf der Verbindungsprotokollschicht (L2R) beginnend vom letzten freien Speicherplatz gespeichert werden.
  10. Mobilkommunikationssystem nach einem der vorhergehenden Ansprüche 7 bis 9, dadurch gekennzeichnet, dass: die Daten im Neuzuordnungspuffer so ausgelegt sind, dass sie an die Funkverbindungsprotokollrahmen angepasst werden, die nach der Neuzuordnung verwendet werden; und die Datenübertragung so ausgelegt ist, dass sie vom Übertragungsspeicher auf der Verbindungsprotokollschicht (L2R) fortgesetzt wird, nachdem die Daten des Neuzuordnungspuffers übertragen wurden.
  11. Vorrichtung eines Mobilkommunikationssystems, wie beispielsweise eine Mobilstation oder eine Basissendeempfangsstation, wobei die Vorrichtung so ausgelegt ist, dass sie ein Funkverbindungsprotokoll (RLP) und ein Verbindungsprotokoll (L2R) in einer Datenübertragung verwendet, in welchem Funkverbindungsprotokoll wenigstens zwei Rahmen von fester Länge zur Datenübertragung definiert sind, und welches Verbindungsprotokoll so ausgelegt ist, dass es Statusinformationen überträgt, welche die Datenübertragung definieren, dadurch gekennzeichnet, dass: die Vorrichtung so ausgelegt ist, dass sie in der Datenübertragung eine Neuzuordnung während der Datenübertragung auf dem Funkverbindungsprotokoll (RLP) zwischen den Rahmen einleitet; die Einleitung der Neuzuordnung so ausgelegt ist, dass sie der Verbindungsprotokollschicht (L2R) der Vorrichtung angezeigt wird; und die aktuellen Statusinformationen über das Verbindungsprotokoll (L2R) so ausgelegt sind, dass sie in dem Funkverbindungsprotokoll (RLP)-Rahmen übertragen werden, der von der Vorrichtung nach der Neuzuordnung zuerst übertragen wird.
DE60215953T 2001-08-23 2002-08-22 Nichttransparente datenübertragung in einem mobilnetzwerk Expired - Lifetime DE60215953T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI20011699A FI112141B (fi) 2001-08-23 2001-08-23 Ei-transparentti datasiirto matkaviestinverkossa
FI20011699 2001-08-23
PCT/FI2002/000689 WO2003019898A1 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network

Publications (2)

Publication Number Publication Date
DE60215953D1 DE60215953D1 (de) 2006-12-21
DE60215953T2 true DE60215953T2 (de) 2007-04-05

Family

ID=8561786

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60235052T Expired - Lifetime DE60235052D1 (de) 2001-08-23 2002-08-22 Nichttransparente Datenübertragung in einem Mobilnetzwerk
DE60215953T Expired - Lifetime DE60215953T2 (de) 2001-08-23 2002-08-22 Nichttransparente datenübertragung in einem mobilnetzwerk

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE60235052T Expired - Lifetime DE60235052D1 (de) 2001-08-23 2002-08-22 Nichttransparente Datenübertragung in einem Mobilnetzwerk

Country Status (13)

Country Link
US (1) US7609715B2 (de)
EP (2) EP1744504B1 (de)
JP (1) JP4188829B2 (de)
KR (1) KR100611176B1 (de)
CN (1) CN1545791B (de)
AT (2) ATE454774T1 (de)
BR (1) BRPI0212109B1 (de)
CA (1) CA2456353C (de)
DE (2) DE60235052D1 (de)
ES (1) ES2274988T3 (de)
FI (1) FI112141B (de)
HK (1) HK1069267A1 (de)
WO (1) WO2003019898A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9288713B2 (en) * 2005-01-31 2016-03-15 Google Technology Holdings LLC Method and apparatus for dynamically changing modes of a reliable transport protocol
WO2007084134A1 (en) * 2006-01-23 2007-07-26 Semiconductor Components Industries, L.L.C. Communication circuit and method therefor
US8340027B2 (en) * 2006-08-07 2012-12-25 Qualcomm Incorporated Monitor period for asynchronous wireless communication
US8416762B2 (en) * 2006-08-07 2013-04-09 Qualcomm Incorporated Message exchange scheme for asynchronous wireless communication
US8737313B2 (en) * 2006-08-07 2014-05-27 Qualcomm Incorporated Transmit time segments for asynchronous wireless communication
US8310996B2 (en) * 2006-08-07 2012-11-13 Qualcomm Incorporated Conditional scheduling for asynchronous wireless communication
US9008002B2 (en) 2006-08-07 2015-04-14 Qualcomm Incorporated Conditional requests for asynchronous wireless communication
CN101577673B (zh) * 2008-05-09 2012-07-11 中兴通讯股份有限公司 一种流控处理方法
CN101345709B (zh) * 2008-08-18 2012-02-22 中兴通讯股份有限公司 一种非透明数据业务切换的实现方法及一种td-scdma终端
US8565197B2 (en) * 2010-08-24 2013-10-22 Blackberry Limited System and method for uplink data transfer in dynamic timeslot reduction

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI97927C (fi) 1995-05-09 1997-03-10 Nokia Telecommunications Oy Ei-transparentti datansiirto digitaalisessa tietoliikennejärjestelmässä
FI955944A (fi) 1995-12-11 1997-06-12 Nokia Telecommunications Oy Nopeussovitusmenetelmä ja nopeussovitin
FI107364B (fi) 1998-05-11 2001-07-13 Nokia Networks Oy Ei-transparentti datasiirto matkaviestinverkossa
FI108824B (fi) 1998-06-03 2002-03-28 Nokia Corp Datasiirtomenetelmiä tietoliikennejärjestelmässä
JP3595690B2 (ja) * 1998-08-06 2004-12-02 富士通株式会社 固定長データ処理装置
US6985470B1 (en) 1998-08-10 2006-01-10 Nokia Networks Oy Data transmission in a telecommunication system
FI982854A (fi) 1998-12-31 2000-07-01 Nokia Networks Oy Datasiirto tietoliikennejärjestelmässä
US6286076B1 (en) * 1999-01-05 2001-09-04 Sun Microsystems, Inc. High speed memory-based buffer and system and method for use thereof
KR20000075358A (ko) 1999-05-27 2000-12-15 윤종용 이동통신시스템에서 라디오링크프로토콜에 따른 가변길이의 데이터 송수신 장치 및 방법
ATE288640T1 (de) 1999-10-11 2005-02-15 Nokia Corp Verfahren und vorrichtung zur synchronisierung in einem kommunikationssystem
SE519221C2 (sv) 1999-12-17 2003-02-04 Ericsson Telefon Ab L M Icke-transparent kommunikation där bara dataramar som detekterats som korrekta skickas vidare av basstationen
US6414938B1 (en) 2000-02-14 2002-07-02 Motorola, Inc. Method and system for retransmitting data packets in a communication system having variable data rates

Also Published As

Publication number Publication date
JP4188829B2 (ja) 2008-12-03
FI20011699A (fi) 2003-02-24
KR100611176B1 (ko) 2006-08-09
EP1744504B1 (de) 2010-01-06
FI112141B (fi) 2003-10-31
WO2003019898A1 (en) 2003-03-06
DE60235052D1 (de) 2010-02-25
CA2456353C (en) 2009-11-03
CA2456353A1 (en) 2003-03-06
EP1744504A1 (de) 2007-01-17
FI20011699A0 (fi) 2001-08-23
ATE345005T1 (de) 2006-11-15
EP1419635B1 (de) 2006-11-08
ATE454774T1 (de) 2010-01-15
KR20040027915A (ko) 2004-04-01
DE60215953D1 (de) 2006-12-21
BRPI0212109B1 (pt) 2016-03-01
US7609715B2 (en) 2009-10-27
CN1545791B (zh) 2010-05-05
ES2274988T3 (es) 2007-06-01
CN1545791A (zh) 2004-11-10
HK1069267A1 (en) 2005-05-13
US20030039269A1 (en) 2003-02-27
EP1419635A1 (de) 2004-05-19
JP2005501480A (ja) 2005-01-13
BR0212109A (pt) 2004-08-24

Similar Documents

Publication Publication Date Title
DE69635548T2 (de) Mehrkanaliger hochgeschwindigkeitsdatentransfer
DE69630374T2 (de) Gleitfenster-datenflusssteuerung mit veränderbarer gleitfensterlänge
DE69635453T2 (de) Mobiles kommunikationssystem und verfahren zur herstellung einer datenübertragung
DE69434826T2 (de) Datenübertragung in einem Funktelefonnetz
DE69632404T2 (de) Verfahren und einrichtung zur datenvermittlung mit verschiedenen datenraten
EP1488581B1 (de) Verfahren zur übertragung von datenpaketen in einem mobilfunksystem und entsprechendes mobilfunksystem
DE69634948T2 (de) Mehrkanal-datenübertragungssystem mit gleitfensterdatenflusssteurerung
DE69534905T2 (de) Verfahren und einrichtung zur datenübertragung mit hoher geschwindigkeit in einem mobilen telekommunikationssystem mit zeitmultiplexvielfachzurgriff
DE69633315T2 (de) Implementation von gegenseitigen Datenratenanpassungen bei Datendiensten zwischen GSM und DECT
DE60035773T2 (de) Datenwiederübertragungsverfahren in einem sprach-über-datenkommunikationssystem
DE60037204T2 (de) Sortierungsmechanismus eines funkverbindungsprotokolls für drahtlose datenkanäle mit dynamischer kapazität
DE69834505T2 (de) Verwendung eines tcp proxy bei paketdatendienst- übertragungen in einem mobilnetz
DE69931905T2 (de) Implementierung von mehrfachen Simultanen Rufverbindungen in einem mobilen Kommunikationssystem
DE60109269T2 (de) Universalles Mobil-Telekommunikationssystem (UMTS) Dienstqualität (QoS) zur Unterstützung die Verhandlung des einstellbaren Dienstqualitätes
DE60113652T2 (de) Verfahren und funksystem zur auflösung von einem ruhebetriebsmodus in einem paketdata schicht
DE60317992T2 (de) Verfahren zum Übertragen von GPRS Datenpaketen aus unterschiedlichen PDP Kontexten gemäss ihrer relativen Priorität
DE69633273T2 (de) Hochgeschwindigkeitsdatenübertragung in mobilkommunikationsnetzwerken
DE69732751T2 (de) DECT/GSM-externes Weiterreicher
DE69731721T2 (de) Verfahren und einrichtung zum datenrufaufbau und adaptereinrichtung
DE19730159B4 (de) Kommunikationsverfahren und System
DE60130247T2 (de) Senden von nachrichten in einem telekommunikationssystem mit einem paketfunknetzwerk
DE60215953T2 (de) Nichttransparente datenübertragung in einem mobilnetzwerk
DE69936788T2 (de) Signalierungsverfahren und telekommunikationssystem.
EP0847211A2 (de) Verfahren zum Übertragen von Daten, insbesondere von GSM-Daten
DE69633342T2 (de) Anpassung einer Interworking function an ein Festnetzprotokoll

Legal Events

Date Code Title Description
8364 No opposition during term of opposition