DE60034698T2

DE60034698T2 - Verbesserung eines funkverbindungsprotokolls zur zeitreduktion eines verbindungsaufbaues für datenanrufe

Info

Publication number: DE60034698T2
Application number: DE60034698T
Authority: DE
Inventors: Nischal San Diego ABROL; Nikolai K. Arlington LEUNG
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 1999-11-10
Filing date: 2000-11-09
Publication date: 2008-01-17
Anticipated expiration: 2020-11-10
Also published as: EP1806876B1; MXPA02004670A; KR20020059701A; NO20022235L; CN1423875A; DE60034698D1; WO2001035580A1; EP1228602B1; US6608818B1; ATE486429T1; IL185959A0; EP1806876A1; CA2389399A1; CN101179365A; CN1423875B; IL149456A0; UA68457C2; TW499804B; DE60042664D1; DE60045172D1

Description

HINTERGRUND DER ERFINDUNG
I. Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf drahtlose Kommunikationen. Insbesondere bezieht sich die vorliegende Erfindung auf ein verbessertes Verfahren und System, das eine verringerte Aufbauzeit benötigt, um einen Funkverbindungsprotokoll- bzw. RLP-Datenanruf (RLP = radio link protocol) einzurichten.
II. Beschreibung der verwandten Technik
Die Verwendung von Codemultiplex-Zugriffs-(CDMA)-Modulationstechniken (CDMA = code division multiple access) ist eine von mehreren Techniken für das Ermöglichen von Kommunikationen, in denen eine große Anzahl von Systemnutzern anwesend ist. Andere Mehrfachzugriffskommunikationssystemtechniken, wie beispielsweise Zeitmultiplex-Vielfachzugriff (TDMA = time division multiple access), Frequenzmultiplex-Vielfachzugriff (FDMA = frequency division multiple access) und AM-Modulationsschemata, wie beispielsweise Amplitude Companded Single Sideband (ACSSB) sind auf dem Fachgebiet bekannt. Diese Techniken sind standardisiert worden, um ein Zusammenwirken bzw. eine Interoperabilität von Einrichtungen, die von unterschiedlichen Unternehmen hergestellt worden sind, zu ermöglichen. Codemultiplexvielfachzugriffskommunikationssysteme sind in den USA im Telecommunications Industry Association TIA/EIA/IS-95-B, betitelt „MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM SYSTEMS" standardisiert worden, der im Folgenden als IS-95 bezeichnet wird. Zusätzlich ist ein neuer Standard für Codemultiplex-Vielfachzugriffskommunikationssysteme vorgeschlagen worden in den USA im Telecommunications Industry Association PN-4431, der als TIA/EIA/IS-2000-5 veröffentlicht wird, betitelt „UPPER LAYER (LAYER 3) SIGNALING STANDARD FOR cdma2000 SPREAD SPECTRUM SYSTEMS", vom 11. Juli 1999, und der im Folgenden als IS-2000 bezeichnet wird.
Die International Telecommunications Union hat kürzlich die Einreichung von vorgeschlagenen Verfahren für das Vorsehen bzw. Liefern von Daten mit hoher Rate und Sprachdiensten von hoher Qualität über Drahtloskommunikationskanäle angefordert. Ein erster dieser Vorschläge wurde von der Telecommunications Industry Association ausgegeben, betitelt „The cdma2000 ITU-R RTT Candidate Submission". Ein zweiter dieser Vorschläge wurde vom European Telecommunications Standards Institute (ETSI) ausgegeben, betitelt „The ETSI UMTS Terrestrial Radio Access (UTRA) ITU-R RTT Candidate Submission", auch bekannt als „Breitband-CDMA bzw. „Wideband-CDMA", und im Folgenden als W-CDMA bezeichnet. Ein dritter Vorschlag wurde von U.S. TG 8/1 eingereicht, betitelt „The UWC-136 Candidate Submission", im Folgenden als EDGE bezeichnet. Die Inhalte dieser Einreichungen sind öffentlich bekannt und sind auf dem Fachgebiet wohl bekannt.
IS-95 wurde ursprünglich optimiert für die Sendung von Sprachrahmen mit variabler Rate. Um Zwei-Wege-Sprachkommunikationen zu unterstützen, wie sie in drahtlosen Telefonanwendungen verkörpert sind, ist es wünschenswert, dass ein Kommunikationssystem eine recht konstante und minimale Datenverzögerung vorsieht. Aus diesem Grund werden IS-95-Systeme mit leistungsstarken Vorwärtsfehlerkorrekturprotokollen bzw. FEC-Protokollen (FEC = forward error correction) und Vocodern konstruiert, die konstruiert sind, um elegant auf Sprachrahmenfehler zu reagieren. Fehlersteuerprotokolle, welche Rahmenneuübertragungsprozeduren benötigen, fügen Sprachsendungen nicht akzeptable Verzögerungen hinzu, und sind somit nicht aufgenommen in die IS-95-Spezifikation.
Die Optimierungen, welche die unabhängige IS-95-Spezifikation ideal für Sprachanwendungen machen, machen es schwierig, diese für Paketdatenanwendungen zu verwenden. In vielen Nicht-Sprach-Anwendungen, wie beispielsweise der Sendung von Internetprotokoll-(IP)-Daten, sind die Verzögerungsanforderungen des Kommunikationssystems viel weniger streng als in Sprachanwendungen. Im Transmission-Control-Protokoll (TCP) bzw. Sende steuerprotokoll, dem wahrscheinlich verbreitetsten der Protokolle, die in einem IP-Netzwerk verwendet werden, werden nahezu unbegrenzte Sendeverzögerungen gestattet, um eine fehlerfreie Sendung zu garantieren. TCP verwenden die erneute Sendung von IP-Datagrammen, wie IP-Pakete herkömmlicher Weise genannt werden, um diese Transportzuverlässigkeit vorzusehen.
IP-Datagramme sind im Allgemeinen zu groß, um in einen einzelnen IS-95-Rahmen zu passen. Sogar nach dem Aufteilen eines IP-Datagramms in Segmente, die klein genug sind um in eine Serie von IS-95-Rahmen zu passen, müsste eine gesamte Serie von IS-95-Rahmen ohne Fehler empfangen werden, damit das einzelne IP-Datagramm für TCP nützlich wäre. Die Rahmenfehlerrate, die für ein IS-95-System typisch ist, führt zu einer sehr geringen Wahrscheinlichkeit für den fehlerfreien Empfang aller Segmente eines einzelnen Datagramms.
Wie in IS-95 beschrieben, ermöglichen alternative Dienstoptionen die Sendung anderer Arten von Daten anstelle von Sprachrahmen. Der TIA/EIA/IS-707-A, betitelt „DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS", im Folgenden als (S-707 bezeichnet, beschreibt Verfahren, die für die Sendung von Paketdaten in einem IS-95-System verwendet werden.
Das Radio-Link-Protokoll (RLP) bzw. das Funkverbindungsprotokoll wird beschrieben in TIA/EIA/IS-707-A.8, betitelt „DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL TYPE 2", im Folgenden als RLP2 bezeichnet. RLP2 beinhaltet ein Fehlersteuerprotokoll mit Rahmenneuübertragungsprozeduren über die IS-95-Rahmen-Layer bzw. – Schicht. RLP ist eine Klasse von Fehlersteuerprotokollen, die als NAK-basierte ARQ-Protokolle bekannt sind, welche auf dem Fachgebiet wohl bekannt sind. Das IS-707-RLP ermöglicht die Sendung eines Bytestroms anstelle einer Serie von Sprachrahmen, durch ein IS-95-Kommunikationssystem.
Mehrere Protokollschichten befinden sich typischerweise über der RLP-Schicht. IP-Datagramme werden beispielsweise typischerweise in einen Point- to-Point-Protokoll-(PPP)-Bytestrom bzw. Punkt-zu-Punkt-Protokoll-Bytestrom konvertiert, bevor sie der RLP-Protokollschicht als ein Bytestrom präsentiert bzw. vorgelegt werden. Da die RLP-Schicht das Protokoll und die Rahmung von Protokollen höherer Schichten ignoriert, wird der Strom von Daten, der vom RLP transportiert wird, als ein „merkmalsloser Bytestrom" bezeichnet.
RLP wurde ursprünglich konstruiert, um die Anforderungen des Sendens großer Rahmen durch einen IS-95-Kanal zu erfüllen. Wenn beispielsweise ein IP-Datagramm von 500 Bytes einfach in IS-95-Rahmen gesendet werden sollte, von denen jeder 20 Bytes trägt, würde das IP-Datagramm 25 aufeinander folgende IS-95-Rahmen füllen. Ohne, irgendeine Art von Fehlersteuerschicht würde alle 25 dieser Rahmen ohne Fehler empfangen werden müssen, damit das IP-Datagramm für die höheren Protokollschichten nützlich sein könnte. Auf einem IS-95-Kanal, der eine 1%-Rahmenfehlerrate aufweist, würde die effektive Fehlerrate der IP-Datagramm-Lieferung (9-(0,99)25) oder 22% sein. Dies ist eine sehr hohe Rate im Vergleich zu den meisten Netzwerken, die verwendet werden um Internet-Protokoll-Verkehr zu tragen. RLP wurde als ein Verbindungsschichtprotokoll bzw. Link-Layer-Protokoll konstruiert, welches die Fehlerrate des IP-Verkehrs verringern würde, um vergleichbar mit der Fehlerrate zu sein, die für einen 10Base2-Ethernet-Kanal typisch ist.
RLP ist ein Negativ-Bestätigung- bzw. NAK-basiertes Protokoll (NAK = negative acknowledgement), in dem NAK-Rahmen gesendet werden, um die erneute Sendung von Datenrahmen zu verursachen, die aufgrund von Kommunikationsfehlern verloren wurden. Das Timing der NAK-Rahmensendung basiert auf Schätzungen der Umlaufzeit (RTT = round-trip time), die zu Beginn einer RLP-Sitzung bestimmt werden. Die RTT-Bestimmung in existierenden Versionen von RLP benötigt einen 3-Wege-Handshake bzw. -Quittungsaustausch, bei dem beide Seiten spezifizierte Rahmenarten bzw. -typen senden, basierend auf den empfangenen Rahmenarten. Keine Daten werden von einer der Seiten gesendet, bis der 3-Wege-Handshake abgeschlossen ist. Dieser 3-Wege-Handshake verbraucht Zeit, die ansonsten genutzt werden könnte, um Daten zu senden.
In einer typischen Datendienstkonfiguration ist ein Laptop-Computer mit einem Drahtlosmodem verbunden, das mit einem Netzwerk über eine RLP-Verbindung kommuniziert. Bei einer typischen Laptop-Computer-Anwendung, wie beispielsweise dem Browsen einer Internnet-Webseite, tauscht der Computer nicht kontinuierlich Daten mit dem Netzwerk aus. Stattdessen sendet der Computer typischerweise eine kurze Anfrage nach Daten, die die Adresse einer Webseite enthält. Das Drahtlosmodem antwortet bzw. reagiert durch Einrichten einer RLP-Sitzung mit der lokalen Basisstation, und leitet die Anfrage weiter durch die Basisstation an das Netzwerk. Durch diese RLP-Sitzung empfängt das Drahtlosmodem dann die, angeforderten Daten (wie beispielsweise die Inhalte einer Webseite), und zeigt die Daten für den Benutzer an. Während der Benutzer die angezeigten Daten liest, werden keine Daten zwischen dem Drahtlosmodem und der Basisstation oder dem Netzwerk ausgetauscht.
Um die effizienteste Verwendung des Drahtlosspektrums zu gestatten, verwendet ein typisches Netwerk „Aktivitätstimer", die eine RLP-Sitzung nach einer vorbestimmten Periode von Verbindungsinaktivität abbrechen. Wenn dies stattfindet, bevor der Laptop-Computer versucht, mehr Daten durch das Drahtlosmodem zu senden, dann wird eine weitere RLP-Sitzung eingerichtet, um die neuen Daten zu bedienen. Die erneute Einrichtung einer neuen RLP-Sitzung verursacht zusätzliche Verzögerung beim Austauschen von Daten mit dem Netzwerk, welche durch „langsames Ansprechverhalten" des Laptop-Computers charakterisiert werden kann.
Das Hervorbringen einer neuen RLP-Sitzung, um neue Daten zu senden, wird immer länger brauchen als das Senden der neuen Daten über eine bereits existierende RLP-Sitzung. Existierende Versionen von RLP benötigen die Ausführung eines 3-Wege-Handshakes, um eine RLP-Sitzung einzurichten. Es ist daher in sehr wünschenswert, den Overhead zu minimieren, der benötigt wird, um eine RLP-Sitzung einzurichten bzw. aufzubauen, einschließlich der Minimierung oder Eliminierung der Verzögerung, die dem 3-Wege-Handshake anhaftet.
WO-A-99/37071 beschreibt einen TCP-Optimierer für langsame Verbindungen zum Bestimmen, basierend auf einer geschätzten RTT, ob ein Datenpaket ein neues Datenpaket, ein gültiges erneut gesendetes Datenpaket oder ein unnötiger Weise erneut gesendetes Datenpaket ist.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung kann verwendet werden, um die Sendung von RLP-Daten ohne das Benötigen des Abschlusses eines 3-Wege-Handshakes zu gestatten. Die vorliegende Erfindung ist auf jedes Kommunikationssystem anwendbar, das die Sendung eines Bytestroms über einen Drahtloskanal einsetzt. Die vorliegende Erfindung ist auf Systeme wie cdma2000, W-CDMA und EDGE anwendbar, wobei ein Bytestrom in Luftschnittstellen-Rahmen getragen wird, die für die Verwendung durch ein Drahtloskommunikationssystem spezifiziert sind.
Die vorliegende Erfindung weist Verfahren zur Aushandlung einer anfänglichen RTT-Schätzung auf, die für einen RLP-Anruf verwendet werden soll. Die anfängliche RTT-Schätzung wird, gemeinsam mit anderen RLP-Parametern wie dem NAK-Schema und Verschlüsselungsparametern, während der Dienstaushandlung ausgehandelt. Beim Abschluss der Dienstaushandlung sind beide Seiten der RLP-Kommunikationsverbindung mit einer anfänglichen RTT-Schätzung ausgerüstet und können das Senden von RLP-Datenrahmen beginnen, ohne den 3-Wege-Handshake auszuführen.
Die vorliegende Erfindung weist Verfahren für die Basisstation auf, die anfänglichen RTT-Schätzwerte zu bestimmen und zu aktualisieren, die während der Dienstaushandlung vorgeschlagen werden. Die vorliegende Erfindung weist auch Verfahren auf, durch die beide Seiten einer RLP-Kommunikationsverbindung die anfänglichen RTT-Schätzungen, die während der Dienstaushandlung spezifiziert wurden, aktualisieren und verfeinern können.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale, Ziele und Vorteile der vorliegenden Erfindung werden offensichtlicher aus der unten dargelegten detaillierten Beschreibung, wenn diese in Verbindung mit den Zeichnungen gesehen wird, in denen gleiche Bezugszeichen durchgängig Entsprechendes bezeichnen und in denen Folgendes gezeigt ist:
1 ist ein Diagramm eines Datenkommunikationssystems, das gemäß einem Ausführungsbeispiel der Erfindung konfiguriert ist.
2 ist ein Diagramm, das den Fluss der Nachrichten zeigt, die verwendet werden um eine RTT-Schätzung zu ermitteln unter Verwendung eines RLP-3-Wege-Handshakes.
3a ist ein Diagramm, das den Fluss der Nachrichten zeigt, die verwendet werden, um einen von der Teilnehmerstation ausgehenden RLP-Anruf einzurichten, der eine RTT-Schätzung gemäß einem Ausführungsbeispiel der Erfindung aufweist.
3b ist ein Diagramm, das den Fluss der Nachrichten zeigt, die verwendet werden, um einen von der Basisstation ausgehenden RLP-Anruf einzurichten, der eine RTT-Schätzung gemäß einem Ausführungsbeispiel der Erfindung, aufweist.
4a ist ein Flussdiagramm der Schritte, die von der Teilnehmerstation ausgeführt werden um eine RLP-Verbindung zu initialisieren und zu verwenden gemäß einem Ausführungsbeispiel der Erfindung.
4b ist ein Flussdiagramm der Schritte, die von einer Basisstation ausgeführt werden, um eine RLP-Verbindung gemäß einem Ausführungsbeispiel der Erfindung zu initialisieren und zu verwenden.
5 ist ein Flussdiagramm der Schritte, die verwendet werden um RTT-Schätzungen während einer RLP-Sitzung zu aktualisieren gemäß einem Ausführungsbeispiel der Erfindung.
6 ist ein Blockdiagramm einer Vorrichtung, die verwendet wird, um eine RLP-Verbindung durch einen CDMA-Drahtloskommunikationskanal einzurichten und zu verwenden, gemäß einem Ausführungsbeispiel der Erfindung.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGS-BEISPIELE
1 ist ein Diagramm eines Datenkommunikationssystems, das gemäß einem Ausführungsbeispiel der Erfindung konfiguriert ist. Wie gezeigt kommuniziert eine Teilnehmerstation (SS = subscriber station) 102 mit dem Netzwerk 108 über einen Drahtloskommunikationskanal 106 und eine Basisstation (BS = base station) 104.
Die Teilnehmerstation 102 und die Basisstation 104 bauen eine Funkverbindungsprotokoll- bzw. RLP-Kommunikationsverbindung (RLP = radio link protocol) auf, um Datenbyteströme durch den Drahtloskommunikationskanal 106 zu übermitteln. Die Datenbytes, die zwischen der Teilnehmerstation 102 und dem Netzwerk 108 durch die Basisstation 104 ausgetauscht werden, können Internet-Protokoll-(IP)-Datagramme sein, die in einen Bytestrom konvertiert wurden unter Verwendung eines Konvertierungsprotokolls, wie zum Beispiel des Point-to-Point-Protokolls bzw. PPP-Protokolis. Sowohl IP- als auch PPP-Protokolle sind auf dem Fachgebiet wohl bekannt.
Bevor irgendwelche Daten zwischen der Teilnehmerstation 102 und der Basisstation 104 ausgetauscht werden können, muss die RLP-Verbindung zwischen den beiden aufgebaut werden. Der Aufbau einer RLP-Verbindung beinhaltet das Ermitteln einer Umlaufzeit (RTT), die von sowohl der Teilnehmerstation 102 als auch der Basisstation 104 für NAK-Timing bzw. Timing für eine negative Bestätigung verwendet wird. In einem beispielhaften Ausführungsbeispiel der vorliegenden Erfindung sendet die Teilnehmerstation 102 der Basisstation 104 eine Service-Request- bzw. Dienstanfragenachricht, die spezifiziert, dass die Teilnehmerstation 102 eine anfängliche RTT-Schätzung ak zeptieren kann, die in einer Service-Response- bzw. Dienstanwortnachricht von der Basisstation 104 gesendet worden ist. Auf Empfang dieser Dienstanfragenachricht hin sendet die Basisstation 104 der Teilnehmerstation 102 eine Dienstantwortnachricht, die eine anfängliche RTT-Schätzung aufweist, die von der Teilnehmerstation 102 verwendet werden soll. Nachdem die Basisstation 104 eine anfängliche RTT-Schätzung an die Teilnehmerstation 102 liefert, besteht keine Notwendigkeit, einen zeitaufwändigen 3-Wege-Handshake auszuführen. Darauf folgend verwendet sie, wenn jede der Seiten einen NAK-Rahmen sendet, die Verzögerung zwischen der Sendung der NAK-Rahmen und dem Empfang eines entsprechenden erneut gesendeten Rahmens bzw. Neuübertragungsrahmens um ihre RTT-Schätzung für die Verwendung in der fortdauernden RLP-Kommunikationsverbindung zu aktualisieren.
2 zeigt, wie eine anfängliche RTT-Schätzung in herkömmlichen RLP-Kommunikationsverbindungen unter Verwendung des 3-Wege-Handshakes aufgebaut wird. Die Teilnehmerstation 102 sendet SYNC-Rahmen 202, SYNC/ACK-Rahmen 204, ACK-Rahmen 206 und Datenrahmen 208 an die Basisstation 104 auf der Rückwärtsverbindung. Die Basisstation 104 wiederum sendet SYNC-Rahmen 220, SYNC/ACK-Rahmen 222, ACK-Rahmen 224 und Datenrahmen 226 an die Teilnehmerstation 102 auf der Vorwärtsverbindung. In dem dargestellten Beispiel ist die Umlaufzeit (RTT = round trip time) 230 8 Rahmen lang. Die gesamte Synchronisationsperiode 232 des Generierens einer ersten RTT-Schätzung ist 12 Rahmen lang oder eineinhalbmal so lang wie RTT.
Zum Zeitpunkt des Beginns der RLP-Synchronisation 240 senden beide Seiten SYNC-Rahmen 202 und 220. Wie gezeigt sendet die Teilnehmerstation 102 einen SYNC-Rahmen in jeder Rahmenperiode. Die Basisstation 104 beginnt auch den Synchronisationsprozess durch Senden eines SYNC-Rahmens 220 in jeder Rahmenperiode.
Zum Zeitpunkt 242, nach der Hälfte der ersten RTT-Periode 230 und nachdem die Teilnehmerstation 102 vier SYNC-Rahmen 202a bis 202d gesendet hat, empfängt die Teilnehmerstation 102 den ersten SYNC-Rahmen 220, der von der Basisstation 104 gesendet wurde. Auf den Empfang dieses ersten SYNC-Rahmens 220 hin beendet die Teilnehmerstation das Senden von SYNC-Rahmen und sendet stattdessen einen SYNC/ACK-Rahmen 204 in jeder Rahmenperiode. Zum Zeitpunkt 242 empfängt die Basisstation 104 auch den ersten SYNC-Rahmen 202a, der von der Teilnehmerstation 102 gesendet wurde. Auf den Empfang dieses ersten SYNC-Rahmens 202a hin beendet die Basisstation 104 das Senden von SYNC-Rahmen und sendet stattdessen einen SYNC/ACK-Rahmen 222 in jeder Rahmenperiode.
Zum Zeitpunkt 244 empfängt die Teilnehmerstation 102 den ersten SYNC/ACK-Rahmen 222, der von der Basisstation 104 gesendet wurde. Auf den Empfang dieses ersten SYNC/ACK-Rahmens 222 hin beendet die Teilnehmerstation das Senden von SYNC/ACK-Rahmen und sendet stattdessen einen ACK-Rahmen 206 in jeder Rahmenperiode. Zum Zeitpunkt 244 empfängt auch die Basisstation 104 den ersten SYNC/ACK-Rahmen 204, der von der Teilnehmerstation 102 gesendet wurde. Auf den Empfang dieses ersten SYNC/ACK-Rahmens 204 hin beendet die Basisstation 104 das Senden von SYNC/ACK-Rahmen und sendet stattdessen einen ACK-Rahmen 224 in jeder Rahmenperiode.
Zum Zeitpunkt 246 empfängt die Teilnehmerstation 102 den ersten ACK-Rahmen 224, der von der Basisstation 104 gesendet wurde. Auf den Empfang dieses ersten ACK-Rahmens 224 hin beendet die Teilnehmerstation das Senden von ACK-Rahmen und kann damit beginnen, Datenrahmen 208 in jeder Rahmenperiode zu senden. Zum Zeitpunkt 246 empfängt auch die Basisstation 104 den ersten ACK-Rahmen 206, der von der Teilnehmerstation 102 gesendet wurde. Auf den Empfang dieses ersten ACK-Rahmens 206 hin beendet die Basisstation 104 das Senden von ACK-Rahmen und kann mit dem Senden von Datenrahmen 226 beginnen.
Die Periode bzw. Zeitdauer zwischen dem Zeitpunkt 240 und dem Zeitpunkt 246 ist eineinhalb Mal so lang wie die RTT 230, die für das Timing der nach folgenden NAK-Rahmen verwendet wird. Mit anderen Worten ist die Zeit 232 zwischen dem Senden der ersten SYNC-Rahmen 240 und dem Senden der ersten Datenrahmen 246 eineinhalb Mal so lang wie RTT 230. Wenn RTT 230 wie gezeigt 8 Rahmen ist, dann ist die Zeit, die benötigt wird um einen 3-Wege-Handshake 232 durchzuführen, 12 Rahmen.
Wenn irgendwelche der SYNC-, SYNC/ACK- oder ACK-Rahmen aufgrund von Kommunikationsfehlern während des 3-Wege-Handshakes verloren gehen, kann diese Synchronisationszeit länger sein. Zusätzlich können solche Kommunikationsfehler dazu führen, dass die resultierende RTT-Schätzung länger ist als die tatsächliche RTT der RLP-Verbindung. Eine RTT-Schätzung, die länger ist als die tatsächliche RTT der RLP-Verbindung führt zu unerwünschten Verzögerungen beim Senden von zusätzlichen NAK-Rahmen, wenn ein vorhergehender NAK-Rahmen verloren gegangen ist (wiederum aufgrund von Kommunikationsfehlern). Solche Verzögerungen können ein verlangsamtes Ansprechverhalten im Protokoll verursachen und können den Durchsatz der RLP-Verbindung verschlechtern.
3a ist ein Diagramm eines verbesserten Nachrichtenflusses, der verwendet wird, um eine RTT-Schätzung für einen von der Teilnehmerstation ausgehenden RLP-Anruf gemäß einem Ausführungsbeispiel der Erfindung zu ermitteln. Anstatt einen 3-Wege-Handshake auszuführen, sendet die Basisstation 104 der Teilnehmerstation 102 eine anfängliche RTT-Schätzung, die in der Luftschnittstellennachricht verwendet werden soll vor dem Aufbau der RLP-Verbindung.
In dem beispielhaften Ausführungsbeispiel beginnt die Teilnehmerstation 102 durch Senden einer Dienstanfragenachricht 302 an die Basisstation 104. In dem bevorzugten Ausführungsbeispiel der Erfindung weist diese Nachricht Anzeigen dafür auf, dass die Teilnehmerstation 102 den Empfang einer anfänglichen RTT von der Basisstation 104 ohne einen 3-Wege-Handshake unterstützt. In dem bevorzugten Ausführungsbeispiel weist die Dienstanfragenachricht 302 optional zusätzliche Parameter auf, wie beispielsweise das Spezifizieren eines oder mehrerer NAK-Schemata, die von der Teilnehmerstation 102 unterstützt werden. Die Dienstanfragenachricht 302 weist optional auch Verschlüsselungsparameter für die RLP-Kommunikationsverbindung auf.
Ein NAK-Schema wird durch die Anzahl der NAK-Rahmen, die nach jedem Ablauf eines NAK-Timers gesendet werden, wenn ein entsprechender erneut gesendeter Rahmen nicht empfangen wurde, charakterisiert. Ein Beispiel eines NAK-Schemas ist ein 1,2,3-NAK-Schema, wobei zuerst ein NAK gesendet wird. Wenn der NAK-Timer, der mit dieser ersten „Runde" von NAKs assoziiert ist, ausläuft ohne den Empfang eines entsprechenden erneut gesendeten Rahmens, dann wird eine weitere Runde von NAKs, bestehend aus zwei NAK-Rahmen, gesendet. Wenn der NAK-Timer, der mit der zweiten Runde von NAKs assoziiert ist, ausläuft ohne den Empfang mindestens eines der entsprechenden erneut gesendeten Rahmen, dann wird eine dritte Runde von drei NAKs gesendet. Andere mögliche NAK-Schemata beinhalten ein Fünf-Runden-1,1,1,1,1-Schema, ein Zwei-Runden-1,2-Schema. Alternativ kann die Dienstanfragenachricht 302 ein Nicht-NAK-Schema anzeigen, das für ein synchrones RLP-Protokoll geeignet ist, wie auf dem Fachgebiet wohl bekannt ist.
Auf den Empfang der Dienstanfragenachricht 302 hin, die keinen 3-Wege-Handshake anzeigt, sendet die Basisstation 104 eine Dienstantwortnachricht 304, die jegliche zusätzlichen oder vorgeschlagenen Modifikationen der Verbindungsparameter enthält. Auf den Empfang der Dienstantwortnachricht 304 hin sendet die Teilnehmerstation 102 eine zweite Dienstanfragenachricht 306, die die Akzeptanz oder Ablehnung der in der Dienstantwortnachricht 304 vorgeschlagenen Parameter anzeigt.
Auf den Empfang der Dienstanfragenachricht 306 hin sendet die Basisstation 104 eine Dienstverbindungs- bzw. Service-Connect-Nachricht 308, die die letztendlichen Verbindungsparameter anzeigt, die verwendet werden sollen. Die Dienstantwortnachricht 304 und die Dienstverbindungsnachricht 308 können zusätzlich NAK-Schemata oder Verschlüsselungsparameter anzeigen, wie oben beschrieben.
Nach dem Senden der Dienstverbindungsnachricht 308 kann die Basisstation 104 sofort damit beginnen, Datenrahmen 310 in aufeinander folgenden Rahmenperioden zu senden. Auf den Empfang der Dienstverbindungsnachricht 308 hin kann die Teilnehmerstation 102 sofort damit beginnen, Datenrahmen 312 an die Basisstation 104 zu senden. Wie im IS-2000 beschrieben, kann die Sendung von Datenrahmen 310 und 312 auch verzögert werden bis zu einer „Aktionszeit", die in einer oder mehreren der vorhergehenden Nachrichten spezifiziert wurde, oder bis eine Dienstverbindungsabschlussnachricht (nicht gezeigt) von einer oder beiden Seiten empfangen wurde. Der Fachmann wird erkennen, dass ein zusätzlicher „Aktionszeit"-Parameter oder eine Dienstverbindungsabschlussnachricht eingesetzt werden kann, ohne von der vorliegenden Erfindung abzuweichen.
Auf den Empfang der ersten Dienstanfragenachricht 302 hin kann die Basisstation 104 auch auswählen, sofort eine Dienstverbindungsnachricht 308 zu senden. Diese Abkürzung macht es unnötig, Zeit mit dem Senden der Dienstantwortnachricht 304 und der Dienstanfragenachricht 306 zu verbringen. Eine derartige Abkürzung funktioniert nur dann, wenn die von der Basisstation 104 in der Dienstverbindungsnachricht 308 vorgeschlagenen Parameter von der Teilnehmerstation 102 unterstützt werden und geeignet sind für die Art von Daten, die über die RLP-Kommunikationsverbindung ausgetauscht werden sollen.
In dem bevorzugten Ausführungsbeispiel nehmen beide Seiten, wenn kein spezifisches NAK-Schema in den verschiedenen Nachrichten angezeigt wird, ein vorbestimmtes Standard-NAK-Schema an, beispielsweise das oben beschriebene 1,2,3-Schema. Das Zulassen eines derartigen vorbestimmten Standard-NAK-Schemas erhält Nachrichtenraum und Bandbreite während der Dienstaushandlung.
In dem bevorzugten Ausführungsbeispiel ist das Format jeder der Nachrichten (Dienstanfragenachricht 302, Dienstantwortnachrichten 304 und 308 und Dienstverbindungsnachricht 308) wie das in der zuvor erwähnten IS-2000-Spezifikation beschriebene. In dem bevorzugten Ausführungsbeispiel weist jede der Nachrichten einen RLP_BLOB-Abschnitt auf, was eine neue Form von BLOB ist, die angepasst ist für RLP-Aushandlungszwecke. BLOB steht im IS-2000 kurz für „Block of Bits" bzw. einen „Block von Bits". In dem bevorzugten Ausführungsbeispiel weist der RLP_BLOB eine anfängliche RTT-Schätzung auf, die verwendet werden soll, und das NAK-Schema. Ein beispielhaftes Format für RLP_BLOB ist in Tabelle 1 unten beschrieben. Tabelle 1

Feld Länge (Bits)

RLP_BOB_ID 3

RTT 4

NAK_ROUNDS_FWD 3

NAK_ROUNDS_REV 3

NAK_ROUNDS_FWD-Auftritte gemäß dem Folgenden

NAK_PER_ROUND_FWD 3

NAK_ROUNDS_REV-Auftritte gemäß dem Folgenden

NAK_PER_ROUND_REV 3
In Tabelle 1 zeigt das RLP_BLOB_ID-Feld eine Versionsnummer des RLP_BLOB-Formats an, das verwendet wird, um den Rest der Inhalte des RLP_BLOB-Abschnitts zu interpretieren. RTT ist ein anfänglicher RTT-Wert, der in dem Anruf verwendet werden soll. NAK_ROUNDS_FWD zeigt die An zahl von NAK-Runden an, die für die Vorwärtsverbindungs-RLP-Sendungen verwendet werden soll (FWD = forward = vorwärts). NAK_ROUNDS_REV zeigt die Anzahl von NAK-Runden an, die für die Rückwärtsverbindungs-RLP-Sendungen verwendet werden soll (REV = reverse = rückwärts). Wie angezeigt, folgt dem NAK_ROUNDS_REV-Feld eine Anzahl von NAK_PER_ROUND_FWD-Feldern, entsprechend dem Wert in dem NAK_ROUNDS_FWD-Feld. Dem letzten der NAK_PER_ROUND_FWD-Felder folgt eine Anzahl von NAK_PER_ROUND_REV-Feldern, entsprechend dem Wert in dem NAK_ROUNDS_REV-Feld. Wenn das NAK_ROUNDS_FWD-Feld einen Wert von Null besitzt, dann werden die NAK_PER_ROUNDS_REV-Felder (wenn vorhanden) dem NAK_ROUNDS_REV-Feld direkt folgen.
Beispielsweise hat in einer Nachricht, die anzeigt, das ein 1,2,3-NAK-Schema auf sowohl der Vorwärts- als auch der Rückwärtsverbindung verwendet werden soll, das RLP_BLOB-Feld einen NAK_ROUNDS_FWD-Wert von 3 und einen NAK_ROUNDS_REV-Wert von 3. Dem NAK_ROUNDS_REV-Wert folgen drei NAK_PER_ROUND_FWD-Felder, die die jeweiligen Werte 1, 2 und 3 besitzen. Dem letzten NAK_PER_ROUND_FWD-Feld folgen drei NAK_PER_ROUND_REV-Felder, die jeweils die Werte 1, 2 und 3 besitzen.
Zusätzlich zum Verwenden der oben beschriebenen Nachrichtenarten, können anfängliche RTT-Zeiten, NAK-Schemata und Verschlüsselungsparameter ausgehandelt werden unter Verwendung der RLP_BLOB-Abschnitte anderer Arten von Nachrichten. Solche Nachrichtenarten beinhalten die allgemeine Übergabe- bzw. Handoff-Anweisungsnachricht (GHDM = General Handoff Direction Message) und die Universalübergabe- bzw. Handoff-Anweisungsnachricht (UHDM = Universal Handoff Direction Message), die im zuvor erwähnten IS-2000 beschrieben sind.
In dem bevorzugten Ausführungsbeispiel wird jede der zuvor beschriebenen Nachrichten, die den RLP_BLOB-Abschnitt weglässt, so interpretiert, als würde sie das Ausführen eines 3-Wege-Handshakes anzeigen. Das NAK-Schema kann dann ein vorbestimmter Standard sein, oder kann während des 3-Wege-Handshakes ausgehandelt werden.
In einem alternativen Ausführungsbeispiel kann die Basisstation 104 weiter die Anzahl der Nachrichten reduzieren, die benötigt werden, um RTT und NAK-Schemata für einen RLP-Anruf zu spezifizieren. Durch Nachverfolgen der Optionen, die in vorhergehenden RLP-Anrufen zu jeder Teilnehmerstation unterstützt wurden, kann die Basisstation 104 einen Anruf damit beginnen, eine Dienstverbindungsnachricht 308 zu senden, die die RLP-Parameter, die verwendet werden sollen, spezifiziert. Nach dem Senden der Dienstverbindungsnachricht 308, und ohne Empfang einer Dienstanforderungsnachricht 302 oder einer Dienstantwortnachricht von der Teilnehmerstation 102, beginnt die Basisstation 104 das Senden von Benutzerdaten.
Mehrere Verfahren können von der Basisstation 104 eingesetzt werden, um die anfängliche RTT-Schätzung zu bestimmen, und zwar für die Spezifizierung zu einer Teilnehmerstation am Beginn eines RLP-Anrufs. In einem bevorzugten Ausführungsbeispiel erlangt die Basisstation 104 die anfängliche RTT-Schätzung durch Addieren einer vorbestimmten Schutzzeit zum Durchschnitt der RTT-Werte, die während des 3-Wege-Handshakes für vorhergehende Anrufe berechnet wurden. In einem alternativen Ausführungsbeispiel wird die anfängliche RTT-Schätzung in der Basisstation 104 von einem Drahtlosdienstbetreiber bzw. -operator konfiguriert.
3b ist ein Diagramm, dass die Variation des verbesserten Nachrichtenflusses zeigt, der verwendet wird, um eine RTT-Schätzung für einen von einer Basisstation ausgehenden RLP-Anruf gemäß einem Ausführungsbeispiel der Erfindung zu ermitteln. Im Gegensatz zu einem von einer Teilnehmerstation ausgehenden Anruf wird bei einem von einer Basisstation ausgehenden Anruf die Dienstanfragenachricht 342 von der Basisstation 104 gesendet und die Dienstantwortnachricht 344 wird von der Teilnehmerstation 102 gesendet. Die Dienstverbindungsnachricht 308 besitzt das gleiche Format und den gleichen Inhalt wie oben beschrieben. Wie gezeigt, beginnt die Basisstation 104 das Senden von Vorwärts-RLP-Datenrahmen 310 sofort nach der Dienstverbindungsnachricht 308. Auf den Empfang der Dienstverbindungsnachricht 308 hin beginnt die Teilnehmerstation 102 das Senden von Rückwärts-RLP-Datenrahmen 312.
In dem beispielhaften Ausführungsbeispiel weist die Dienstanfragenachricht 312 einen Vorschlag auf, dass beide Seiten der Verbindung eine anfängliche RTT-Schätzung verwenden anstatt einen 3-Wege-Handshake zu verwenden.
Wie gezeigt akzeptiert die Teilnehmerstation 102 den Vorschlag in der Dienstantwortnachricht 344, und der 3-Wege-Handshake wird nicht durchgeführt zwischen der Dienstverbindungsnachricht 308 und RLP-Datenrahmen 310 und 312.
All die gleichen RLP-Parameter, die in Verbindung mit von der Teilnehmerstation ausgehenden RLP-Anrufen beschrieben wurden, können in den Nachrichten ausgehandelt werden, die für einen von der Basisstation ausgehenden RLP-Anruf gezeigt sind. Beispielsweise kann die Dienstanfragenachricht 342 ein vorgeschlagenes NAK-Schema aufweisen, welches in einer Dienstantwortnachricht 344 akzeptiert wird.
4a ist ein Flussdiagramm der Schritte, die von einer Teilnehmerstation durchgeführt werden, um eine RLP-Kommunikationsverbindung gemäß einem Ausführungsbeispiel der Erfindung zu initialisieren und zu verwenden. Die Schritte sind für einen von einer Teilnehmerstation ausgehenden RLP-Anruf gezeigt, wie dem in 3a gezeigten, und für einen von einer Basisstation ausgehenden RLP-Anruf, wie dem in 3b gezeigten.
In einem von einer Teilnehmerstation ausgehenden RLP-Anruf 400 initiiert die Teilnehmerstation Dienstaushandlungen durch Senden einer ersten Dienstanfragenachricht 402, die die Fähigkeit der Teilnehmerstation anzeigt, eine anfängliche RTT-Schätzung während der Dienstaushandlung, oder andere vorgeschlagene RLP-Parameter auszuhandeln. Die Teilnehmerstation empfängt dann und decodiert die Antwort 404 von der Basisstation. Die Art der Antwort, die empfangen wurde, wird evaluiert 406 um zu entscheiden, ob weitere RLP-Parameter ausgehandelt werden sollen. Wenn die empfangene Nachricht eine Dienstantwortnachricht war, die vielleicht Änderungen an den RLP-Parametern, die zuvor gesendet wurden, vorschlägt, dann sendet die Teilnehmerstation eine weitere Dienstanfragenachricht 402. Die neue Dienstanfragenachricht enthält einen Satz von Parametern, die entweder passen bzw. übereinstimmen oder die die neuen RLP-Parameter modifizieren, die von der Basisstation vorgeschlagen werden. Die Teilnehmerstation wartet dann, bis sie eine weitere Antwort 404 auf die aktuellste Dienstanfragenachricht empfängt.
Schließlich wird bei Schritt 406 herausgefunden, dass die Antwortart eine Dienstverbindungsnachricht ist, die die RLP-Parameter enthält, die verwendet werden sollen. Die Dienstverbindungsnachricht wird bei Schritt 408 evaluiert um zu bestimmen, ob die Dienstverbindungsnachricht das Ausführen eines 3-Wege-Handshakes anzeigt. Wenn die Dienstverbindungsnachricht das Ausführen eines 3-Wege-Handshakes anzeigt, dann wird der 3-Wege-Handshake durchgeführt 410 vor dem Beginn des Sendens von Benutzerdaten 412. Wenn die Dienstverbindungsnachricht anzeigt, dass ein 3-Wege-Handshake nicht notwendig ist, und stattdessen eine anfängliche RTT-Schätzung spezifiziert, die verwendet werden soll, dann kann die Teilnehmerstation sofort damit beginnen, Benutzerdaten 412 zu senden.
Wie zuvor erwähnt kann die Dienstverbindungsnachricht anzeigen, dass ein 3-Wege-Handshake nicht notwendig ist, aber nicht die anfängliche RTT-Schätzung aufweisen. In diesem Fall wird die Teilnehmerstation eine vorbestimmte Standard-Anfangs-RTT-Schätzung verwenden.
Bei einem von einer Basisstation ausgehenden RLP-Anruf 420 empfängt und decodiert die Teilnehmerstation eine erste Dienstanfragenachricht 422 von der Basisstation. Diese Dienstanfragenachricht kann anzeigen, dass die Basisstation das Spezifizieren einer anfänglichen RTT-Schätzung während der Dienstaushandlung unterstützt. Die Teilnehmerstation antwortet durch Senden einer Dienstantwortnachricht 424, die anzeigt, dass der Teilnehmer auch das Verwenden einer anfänglichen RTT-Schätzung unterstützt, die während einer Dienstaushandlung empfangen wurde. Die Teilnehmerstation empfängt und decodiert dann die nächste Antwortnachricht 426, die von der Basisstation gesendet wurde. Die Art der Antwort wird evaluiert 428. Die Antwort kann eine weitere Dienstanfragenachricht sein, die beispielsweise einen Vorschlag für ein bestimmtes NAK-Schema oder andere zusätzliche RLP-Parameter anzeigt. Die Teilnehmerstation sendet dann eine weitere Dienstanwortnachricht 424, die die Akzeptanz oder Ablehnung der zusätzlichen RLP-Parameter anzeigt. Wenn eine Dienstverbindungsnachricht empfangen worden ist, dann geht die Verarbeitung vom Schritt 428 zum Schritt 408 weiter, wie zuvor beschrieben.
4b ist ein Flussdiagramm der Schritte, die von einer Basisstation durchgeführt werden, um eine RLP-Kommunikationsverbindung gemäß einem Ausführungsbeispiel der Erfindung zu initialisieren und zu verwenden. Die Schritte sind für einen von einer Teilnehmerstation ausgehenden RLP-Anruf gezeigt, wie dem in 3a gezeigten, und für einen von einer Basisstation ausgehenden RLP-Anruf, wie dem in 3b gezeigten.
Bei einem von einer Teilnehmerstation ausgehenden RLP-Anruf 450 empfängt und decodiert die Basisstation eine erste Dienstanfragenachricht 452, die die Fähigkeit der Teilnehmerstation anzeigt, eine anfängliche RTT-Schätzung während der Dienstaushandlung und andere vorgeschlagene RLP-Parameter auszuhandeln. Als nächstes werden die RLP-Parameter, die in der Dienstanfragenachricht angezeigt sind, evaluiert 454 um zu bestimmen, ob irgendwelche Parameteränderungen ausgehandelt werden sollten. Wenn dem so ist, sendet die Basisstation einen neuen Satz von vorgeschlagenen RLP-Parametern in einer Dienstanfragenachricht und sendet diese an den Teilnehmer 456.
Wenn die bei Schritt 454 evaluierten RLP-Parameter für die Basisstation akzeptabel sind, sendet die Basisstation eine Dienstverbindungsnachricht 470, die die RLP-Parameter anzeigt, die verwendet werden sollen. Die Basisstation entscheidet 472 dann, basierend auf den Inhalten der Dienstverbindungsnachricht, ob ein 3-Wege-Handshake ausgeführt werden sollte. Wenn dem so ist, dann führt die Basisstation einen 3-Wege-Handshake 474 aus und beginnt dann mit dem Senden von Benutzerdaten. Wenn kein 3-Wege-Handshake von der Dienstverbindungsnachricht angezeigt wird, dann geht die Basisstation direkt vom Schritt 472 über zum Senden von Benutzerdaten 476.
Bei einem von einer Basisstation ausgehenden RLP-Anruf 460 beginnt die Basisstation die Dienstaushandlung durch Senden einer Dienstanfragenachricht 462 an die Teilnehmerstation. Diese Dienstanfragenachricht zeigt an, dass die Basisstation das Spezifizieren einer anfänglichen RTT-Schätzung während der Dienstaushandlung unterstützt. Die Basisstation empfängt und decodiert dann die Dienstantwortnachricht empfangen von der Teilnehmerstation 464.
Die in der Dienstantwortnachricht angezeigten RLP-Parameter werden evaluiert 466, um zu bestimmen, ob irgendwelche Parameteränderungen ausgehandelt werden sollten. Wenn dem der Fall ist, geht die Basisstation zurück zum Schritt 462 und sendet einen neuen Satz von vorgeschlagenen RLP-Parametern in einer Dienstanfragenachricht. Anderenfalls sendet die Basisstation eine Dienstverbindungsnachricht 470 und fährt von diesem Schritt wie zuvor beschrieben fort.
5 ist ein Flussdiagramm der Schritte, die verwendet werden, um die RTT-Schätzungen während einer RLP-Sitzung gemäß einem Ausführungsbeispiel der Erfindung zu aktualisieren. In dem Fall, dass die anfängliche RTT- Schätzung während der Dienstaushandlung ausgehandelt wird, ist es für beide Seiten vorteilhaft, in der Lage zu sein, ihre RTT-Schätzungen gemäß den Messungen, die während des Anrufs durchgeführt werden, anzupassen. Dieses Verfahren verwendet Information, die während der Sendung von NAK und erneut übertragenen Rahmen gesammelt wurde, um die RTT-Schätzung dy namisch während eines RLP-Anrufs zu aktualisieren, was in einem RTT-Aktualisierungsprozess resultiert, der in den NAK-Prozess integriert ist. Für eine einfache Beschreibung wird das Verfahren unten aus Sicht einer Teilnehmereinheit in einem RLP-Anruf beschrieben. Der Fachmann wird erkennen, dass Ausführungsbeispiele des Verfahrens von der Teilnehmerstation, der Basisstation oder beiden ausgeführt werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
Die RTT-Schätzungsaktualisierungsprozedur beginnt, wenn die Teilnehmerstation ein Sequenznummernloch bzw. eine Sequenznummernlücke 502 detektiert. Die Teilnehmerstation startet einen RTT-Zahler 504, um zu messen, wie lange es dauert einen erneut gesendeten Rahmen für einen oder mehrere NAK-Rahmen, die gesendet werden sollen, zu empfangen. Die Teilnehmerstation initialisiert auch einen NAK-Timer mit der aktuellen RTT-Schätzung und startet den NAK-Timer 506. Die Teilnehmerstation sendet dann die Anzahl der NAK-Rahmen 508, die mit der ersten Runde im aktuellen NAK-Schema assoziiert sind.
Schritt 510 evaluiert, ob ein entsprechender erneut gesendeter Rahmen empfangen wird bevor der NAK-Timer abläuft. Wenn dem der Fall ist, dann wird der RTT-Zahler beim. Schritt 520 geprüft. Wenn der RTT-Zähler nicht läuft, wenn der erneut gesendete Rahmen empfangen wird, dann werden der RTT-Zähler und der NAK-Timer angehalten je nach Bedarf. Wenn der RTT-Zahler immer noch läuft, wenn ein erneut gesendeter Rahmen empfangen wird, dann wird die RTT-Schätzung, die für den RLP-Anruf verwendet wird, aktualisiert 522 gemäß der neuen Schätzung. In einem beispielhaften Ausführungsbeispiel wird die neue RTT-Schätzung berechnet durch Ausführen einer gewichteten Mittelung des Wertes der alten RTT-Schätzung und der Summe des RTT-Timers und einer vorbestimmten Schutzzeit. Der Fachmann wird erkennen, dass zahlreiche andere Kombinationsverfahren verwendet werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Diese anderen Verfahren beinhalten das Ersetzen der RTT-Schätzung mit der Summe des Wertes des RTT-Timers und einer Schutzzeit.
Nach dem Aktualisieren der RTT-Schätzung 522, werden der RTT-Zähler und der NAK-Timer angehalten, und der in den NAK-Prozess integrierte RTT-Aktualisierungsprozess endet 540. Wenn bei Schritt 520 festgestellt wird, dass der NAK-Timer nicht läuft, dann wird das Aktualisieren der RTT beim Schritt 522 ausgelassen, und das Verfahren fährt direkt von Schritt 520 zu Schritt 524 fort.
Wenn, bei Schritt 510, die Teilnehmerstation entdeckt, dass der NAK-Timer ausgelaufen ist, bevor ein entsprechender erneut gesendeter Rahmen empfangen wurde, dann evaluiert 530 die Teilnehmerstation, wie viele NAK-Runden bereits vergangen sind, ohne einen entsprechenden erneut gesendeten Rahmen zu empfangen. Die Grenze der Anzahl der NAK-Runden in dem aktuellen NAK-Schema wurde zu Beginn des Anrufs bestimmt, entweder durch das zuvor erwähnte NAK_ROUNDS_REV-Feld, oder durch das zuvor erwähnte vorbestimmte Standard-NAK-Schema. Wenn die Anzahl der NAK-Runden, die abgelaufen sind, gleich dieser Grenze ist, dann ist die NAK-Grenze erreicht worden. Wenn die NAK-Grenze erreicht wurde, dann sind keine weiteren NAK-Runden gestattet für die entsprechende Lücke, und die Teilnehmerstation geht zu Schritt 524 weiter.
Wenn bei Schritt 530 die NAK-Grenze nicht erreicht wurde, evaluiert 532 die Teilnehmerstation, ob die RTT-Schätzung für den RLP-Anruf jemals aktualisiert wurde. Wenn sie zuvor aktualisiert worden ist, dann hält die Teilnehmerstation den RTT-Zähler 534 an, bevor sie den NAK-Timer wieder startet 506 und sendet die nächste Runde von NAK-Rahmen 508. Das Anhalten des RTT-Zählers vor dem Senden einer weiteren Runde von NAK-Rahmen verhindert, dass eine Mehrdeutigkeit erneut gesendeter Rahmen Ungenauigkeit von RTT-Schätzungen verursacht. Wenn beispielsweise ein erneut gesendeter Rahmen empfangen würde, nachdem eine zweite Runde von NAK-Rahmen gesendet wurde, würde die Teilnehmerstation nicht wissen, ob der erneut gesendete Rahmen einer NAK in der ersten oder der zweiten Runde entspricht. Falsches Matching bzw. Zuordnen eines solchen erneut gesendeten Rahmens zu einer späteren NAK-Runde würde zu einer falschen RTT-Schätzung führen.
Ein weiteres Problem tritt jedoch auf beim Anhalten des RTT-Zählers nach Auslaufen des ersten NAK-Timers. Wenn, aus irgendeinem Grund, die anfängliche RTT-Schätzung, die während der Dienstaushandlung spezifiziert wurde, künstlich klein ist, dann wird der erste NAK-Timer möglicherweise auslaufen, bevor eine erster erneut gesendeter Rahmen die Möglichkeit hat, die Teilnehmerstation zu erreichen. Unter diesen Umständen wird die fälschlich kleine RTT-Schätzung möglicherweise nie aktualisiert, und könnte eine schwache Performance für die Dauer des RLP-Anrufs verursachen.
Dieses Problem wird in dem beispielhaften Ausführungsbeispiel dadurch gelöst, dass dem RTT-Zahler gestattet wird, weiterzulaufen, wenn die Teilnehmerstation bestimmt 532, dass die RTT-Schätzung noch nicht aktualisiert worden ist. Wenn die RTT-Schätzung noch nicht aktualisiert worden ist, dann wird der Schritt 534 ausgelassen, und der Teilnehmer startet den NAK-Timer 506 erneut und sendet die nächste Runde von NAK-Rahmen 508. Im schlimmsten Fall wird dies möglicherweise zu einer aktualisierten RTT-Schätzung führen, die übermäßig lang ist, aber dies ist gegenüber einer RTT-Schätzung, die zur kurz ist, vorzuziehen. Entsprechend gibt in dem bevorzugten Ausführungsbeispiel Schritt 522 der existierenden RTT-Schätzung kein oder wenig Gewicht beim gewichteten Mittel, wenn die RTT-Schätzung das erste Mal aktualisiert wird. In einem alternativen Ausführungsbeispiel variiert die Gewichtung der existierenden RTT-Schätzung bei der ersten Aktualisierung basierend auf dem Betrag, um den die erste RTT-Schätzung die existierende RTT-Schätzung überschreitet und auf der Anzahl der NAK-Runden, die vor dem Empfang eines erneut gesendeten Rahmen gesendet wurde.
In einem alternativen Ausführungsbeispiel basiert die Entscheidung bei Schritt 532 nicht darauf, ob die RTT-Schätzung jemals aktualisiert worden ist, sondern darauf, ob die Lücke entsprechend dem abgelaufenen NAK-Timer die erste Lücke ist, die in der RLP-Sitzung detektiert wird. Wenn die Lücke die erste war, die detektiert wurde, dann wird der RTT-Zähler nicht angehalten, bevor zu Schritt 506 fortgeschritten wird. Wenn andere Lücken zuvor detektiert wurden, dann wird der RTT-Zähler angehalten 534, bevor zu Schritt 506 fortgeschritten wird.
6 ist ein Blockdiagramm einer Vorrichtung, die verwendet wird um eine RLP-Verbindung durch einen CDMA-Drahtloskommunikationskanal gemäß einem Ausführungsbeispiel der Erfindung aufzubauen und zu verwenden. Aus Gründen einer einfachen Darstellung wird die Vorrichtung unten bezüglich ei ner Teilnehmerstation beschrieben. Der Fachmann wird erkennen, dass die abgebildete Konfiguration und ihre Variationen auf gleiche Weise in Verbindung mit einer Drahtlosbasisstation verwendet werden können, ohne von der vorliegenden Erfindung abzuweichen.
Die gezeigte Vorrichtung weist eine Datenschnittstelle bzw. -interface 602 auf, die mit einer externen Eingabe/Ausgabe-Vorrichtung, beispielsweise einem Anzeigeterminal oder einem handgehaltenen oder Laptop-Computer, verbunden sein kann. Die Datenschnittstelle 602 kann weggelassen werden, wenn die Teilnehmerstation 102 weiter eine interne Benutzerschnittstelle aufweist, beispielsweise ein Tastenfeld und eine Anzeige. Beispielsweise kann die Teilnehmerstation 102 ein CDMA-Drahtlos-PDA (PDA = personal digital assistant = persönlicher digitaler Assistent) sein, der in der Lage ist, Daten mit dem Internet auszutauschen und sie auf einer Flüssigkristallanzeige bzw. auf einer LCD (LCD = liquid crystal display) anzuzeigen.
Je nachdem ob die Rohbenutzerdaten durch die Datenschnittstelle 602 oder von einer anderen internen Eingabe/Ausgabe-Schnittstelle empfangen werden, werden die Daten wie benötigt von einem Steuerprozessor 604 manipuliert. Der Steuerprozessor 604 führt die notwendige Formatierung und Protokolleinkapselung durch und sendet die Daten Ober die Drahtlosverbindung. In dem bevorzugten Ausführungsbeispiel nimmt der Steuerprozessor 604 einen Bytestrom, der durch die Datenschnittstelle 602 empfangen wird, und kapselt ihn in RLP-Rahmen ein für die Sendung durch ein CDMA-Modulationsmodul 620. Der Steuerprozessor 604 extrahiert auch Daten von RLP-Rahmen, die durch das CDMA-Demodulationsmodul 640 empfangen wurden, und liefert den resultierenden Bytestrom an die Datenschnittstelle 602. Zusätzlich zu den RLP-Rahmen führt der Steuerprozessor 604 auch eine Dienstaushandlung durch durch Senden und Empfangen von Dienstanfrage-, Dienstantwort-, Dienstverbindungs- und anderen oben beschriebenen Nachrichten durch das CDMA-Modulationsmodul 620 und das CDMA-Demodulationsmodul 640.
Der Steuerprozessor 604 ist verbunden mit, und sieht Senderahmen vor an, das CDMA-Modulatormodul 620. In dem bevorzugten Ausführungsbeispiel liefert der Steuerprozessor 604 die Senderahmen an das Vorwärtsfehlerkorrektur- bzw. FEC-Modul 610 (FEC = forward error correction), welches die Rahmen basierend auf einem FEC-Code codiert. Das FEC-Modul 610 verwendet irgendeine von mehreren Vorwärtsfehlerkorrekturtechniken, einschließlich Turbocodierung, Faltungscodierung oder anderen Formen von Soft-Decision- oder Blockcodierung. Die resultierenden codierten Daten werden durch das FEC-Modul 610 an Interleaver bzw. Verschachteler (INT) 612 geliefert, welcher die Daten verschachtelt, um Zeitdiversität bzw. -Diversity für das gesendete Signal vorzusehen. Der Verschachteler 612 verwendet irgendeine Anzahl von Verschachtelungstechniken, wie beispielsweise Blockverschachtelung und Bitumkehrverschachtelung. Die Ausgabe des Verschachtelers 612 ist binär, und wird dann an den Walsh-Spreizer 614 geliefert, welcher das Signal unter Verwendung von Walsh-Codes spreizt. Nach dem Walsh-Spreizen wird die Ausgabe des Walsh-Spreizers 612 an den Pseudorausch-(PN)-Spreizer 616 (PN = pseudonoise) geliefert, wo sie unter Verwendung von PN-Codes gespreizt wird. Die Ausgabe des PN-Spreizers 616 wird dann an den Sender (TMTR = transmitter) 618 geliefert, wo sie hochkonvertiert, verstärkt und an den Diplexer (DPLX) 650 vorgesehen wird, und dann durch Antenne 652 gesendet wird.
In dem bevorzugten Ausführungsbeispiel ist der PN-Spreizer 616 ein komplexer PN-Spreizer, der die komplexe Ausgabe des Walsh-Spreizers 614 mit einem komplexen PN-Code multipliziert. In einem alternativen Ausführungsbeispiel multipliziert der PN-Spreizer 616 die komplexe Ausgabe des Walsh-Spreizers 614 mit einem reellen (nicht komplexen) PN-Code.
Signale, die durch die Antenne 652 empfangen werden, durchlaufen Diplexer 650 und werden dann verstärkungsgesteuert und herabkonvertiert im Empfänger (RCVR = receiver) 638. Von dort werden die Signale an das CDMA-Demodulatormodul 640 vorgesehen, in welchem sie PN-entspreizt werden im PN-Entspreizer 636, Walsh-entspreizt im Walsh-Entspreizer 634, entschach telt im Entschachteler bzw. Deinterleaver (DEINT) 632 und FEC-decodiert im FEC-Decodierer 630. Der FEC-Decodierer 630 liefert die resultierenden empfangenen Rahmen an den Steuerprozessor 604.
In dem bevorzugten Ausführungsbeispiel ist der PN-Entspreizer 636 ein komplexer PN-Entspreizer, der die komplexen Abtastungs- bzw. Sampleströme vom Empfänger 638 mit einem komplexen PN-Code multipliziert. In einem alternativen Ausführungsbeispiel multipliziert der PN-Entspreizer 638 die komplexen Abtastungsströme vom Empfänger 638 mit einem reellen (nicht komplexen) PN-Code. Der Entschachteler verwendet irgendeine Anzahl von Deinterleaving- bzw. Entschachtlungstechniken wie beispielsweise Blockentschachtelung und Bitumkehrentschachtelung. Der FEC-Decodierer 610 verwendet irgendeine von mehreren Vorwärtsfehlerkorrekturtechniken, einschließlich Turbocodierung, Faltungscodierung oder anderen Formen von Soft-Decision- oder Blockcodierung.
Die vorangehende Beschreibung der bevorzugten Ausführungsbeispiele wird vorgesehen, um es einem Fachmann zu ermöglichen, die vorliegende Erfindung herzustellen oder zu verwenden. Die verschiedenen Modifikationen dieser Ausführungsbeispiele werden dem Fachmann leicht ersichtlich sein, und die hierin definierten generischen Prinzipien können auf andere Ausführungsbeispiele angewandt werden ohne die Verwendung erfinderischer Tätigkeit. Somit ist es nicht beabsichtigt, die vorliegende Erfindung auf die hierin gezeigten Ausführungsbeispiele zu beschränken sondern ihr soll der weiteste Umfang zugewiesen werden, der durch die Ansprüche definiert ist.

Claims

Ein Verfahren zum Senden eines Stromes von Informationsbytes, wobei das Verfahren gekennzeichnet ist durch die folgenden Schritte: Ermitteln einer ersten Schätzung einer Funkverbindungsprotokollumlaufzeitschätzung, worauf im Folgenden auch als RLP-RTT-Schätzung (RLP = Radio Link Protocol, RTT = Round Trip Time) Bezug genommen wird; und Verwenden der ersten RLP-RTT-Schätzung, um ein Nachrichten-Timing für eine negative Bestätigung, worauf im Folgenden als NAK (NAK = Negative Acknowledgement) Bezug genommen wird, zu bestimmen, und zwar in einer nachfolgenden RLP-Kommunikationssitzung.
Verfahren nach Anspruch 1, wobei das Ermitteln ausgeführt während der Dienstaushandlung wird.
Verfahren nach Anspruch 2, wobei das Verfahren weiterhin folgende Schritte aufweist: Messen (504) der Verzögerung zwischen dem Senden eines NAK-Rahmens und dem Empfangen eines entsprechenden ersten neu gesendeten Rahmens, um eine zweite RLP-RTT-Schätzung zu bilden; und Aktualisieren (522) der ersten RLP-RTT-Schätzung basierend auf der zweiten RLP-RTT-Schätzung.
Verfahren nach Anspruch 3, wobei der Schritt des Aktualisierens (522) weiterhin Folgendes aufweist: Ausführen einer gewichteten Mittelung der ersten RLP-RTT-Schätzung und der zweiten RLP RTT-Schätzung.
Verfahren nach Anspruch 3, wobei der Schritt des Aktualisierens (522) weiterhin Folgendes aufweist: Austauschen der ersten RLP-RTT-Schätzung mit der zweiten RLP-Schätzung basierend auf dem Empfang des ersten neu gesendeten Rahmens der RLP-Kommunikationssitzung.
Verfahren nach Anspruch 1, wobei das Ermitteln Folgendes aufweist: Ausführen eines 3-Wege-Handshakes bzw. -Quittungsaustauschs, um die erste RLP-RTT-Schätzung zu generieren, wobei die erste RLP-RTT-Schätzung mit einer ersten RLP-Kommunikationssitzung assoziiert ist, wobei das Verfahren weiterhin Folgendes aufweist: Ermitteln einer zweiten RLP-RTT-Schätzung, die mit einer zweiten RLP-Kommunikationssitzung assoziiert ist, wobei die zweite RLP-RTT-Schätzung auf der ersten RLP-RTT-Schätzung basiert, und wobei die zweite RLP-RTT-Schätzung während der Dienstaushandlung ermittelt wird, wobei das Verwenden das Verwenden der zweiten RLP-RTT-Schätzung aufweist, um das NAK-Nachrichten-Timing in einer nachfolgenden RLP-Kommunikationssitzung zu bestimmen.
Verfahren nach Anspruch 6, wobei der Schritt des Ausführens eines 3-Wege-Handshakes ausgeführt wird zwischen einer Basisstation (104) einer Teilnehmerstation (102) und wobei der Schritt des Ermittelns einer zweiten RLP-RTT-Schätzung ausgeführt wird zwischen der Basisstation (104) und der Teilnehmerstation (102).
Verfahren nach Anspruch 6, wobei der Schritt des Ausführens eines 3-Wege-Handshakes ausgeführt wird zwischen einer Basisstation (104) und einer ersten Teilnehmerstation (102) und der Schritt der Ermittlung einer zweiten RLP-RTT-Schätzung ausgeführt wird zwischen der Basisstation (104) und einer zweiten Teilnehmerstation (102).
Verfahren nach Anspruch 6, wobei die zweite RLP-RTT-Schätzung generiert wird durch Hinzufügen einer vorbestimmten Schutzzeit zu der ersten RLP-RTT-Schätzung.
Verfahren nach Anspruch 1, das weiterhin Folgendes aufweist: Empfangen einer Nachricht, die die erste RLP-RTT-Schätzung spezifiziert, wobei das Verwenden das Durchführen einer RLP-Kommunikationssitzung aufweist unter Verwendung der ersten RLP-RTT-Schätzung, um das NAK-Nachrichten-Timing zu bestimmen.
Verfahren nach Anspruch 1, das weiterhin Folgendes aufweist: Senden einer Nachricht, die die erste RLP-RTT-Schätzung spezifiziert, wobei das Verwenden das Durchführen einer RLP-Kommunikationssitzung unter Verwendung der ersten RLP-RTT-Schätzung zur Bestimmung des NAK-Nachrichten-Timings, aufweist.
Verfahren nach Anspruch 10 oder 11; wobei die Nachricht eine Dienstaushandlungsnachricht ist.
Verfahren nach Anspruch 11, wobei die erste RLP-RTT-Schätzung spezifiziert wird durch einen Betreiber einer Basisstation (104) und verwendet wird zum Bestimmen des NAK-Nachrichten-Timings in RLP-Kommunikationssitzungen zwischen einer oder mehreren Teilnehmerstationen (102) und der Basisstation (104).
Verfahren nach Anspruch 10 oder 11, wobei die Nachricht eine Dienstverbindungsnachricht (308) ist.
Verfahren nach Anspruch 10 oder 11, wobei die Nachricht eine Dienstanfragenachricht (302, 306, 342) ist.
Verfahren nach Anspruch 10 oder 11, wobei die Nachricht eine Dienstantwortnachricht (304, 344) ist.
Verfahren nach Anspruch 10 oder 11, wobei die Nachricht eine allgemeine Übergabeanweisungsnachricht bzw. General-Handoff-Direction-Message ist.
Verfahren nach Anspruch 10 oder 11, wobei die Nachricht eine Universalübergabeanweisungsnachricht ist.
Verfahren nach Anspruch 14, wobei die Dienstverbindungsnachricht (308) weiterhin ein NAK-Schema spezifiziert, und wobei das Verfahren zum Senden weiterhin den Schritt des Verwendens des NAK-Schemas aufweist.
Verfahren nach Anspruch 10 oder 12, das weiterhin den Schritt des Aushandelns, und zwar unter Verwendung von Dienstaushandlungsnachrichten, eines NAK-Schemas aufweist, das während der nachfolgenden RLP-Kommunikationssitzung verwendet wird.
Verfahren nach Anspruch 10 oder 20, das weiterhin den folgenden Schritt aufweist: Aushandeln unter Verwendung von Dienstaushandlungsnachrichten, von Verschlüsselungsparametern, die während der nachfolgenden RLP-Kommunikationssitzung verwendet werden.
Teilnehmerstationsvorrichtung (102), gekennzeichnet durch: einen Steuerprozessor (604) angepasst zum Empfangen einer Dienstaushandlungsnachricht, die eine erste Schätzung einer Funkverbindungsprotokollumlaufzeit, was im Folgenden als RLP-RTT bezeichnet wird, spezifiziert und zur Verwendung der RLP-RTT-Schätzung, um ein Nachrichten-Timing einer negativen Bestätigung in einer nachfolgenden RLP-Kommunikationssitzung zu bestimmen.
Vorrichtung (102) nach Anspruch 22, wobei der Steuerprozessor (604) angepasst ist, um das Verfahren nach Anspruch 10 oder nach einem der Ansprüche 12 bis 21, die davon abhängig sind, auszuführen.
Basisstationsvorrichtung (104) gekennzeichnet durch: einen Steuerprozessor (604) angepasst zum Senden einer Dienstaushandlungsnachricht, die eine erste Schätzung für eine Funkverbindungsprotokollumlaufzeit, worauf im Folgenden als RLP-RTT-Schätzung Bezug genommen wird, spezifiziert, und zwar zu einer Teilnehmerstation (102), und Verwenden der RLP-RTT-Schätzung, um ein Nachrichten-Timing einer negativen Bestätigung, worauf im Folgenden als NAK-Nachricht Bezug genommen wird, in einer nachfolgenden RLP-Kommunikationssitzung zwischen der Basisstation (104) und der Teilnehmerstation (102) zu bestimmen.
Vorrichtung (104) nach Anspruch 24, wobei der Steuerprozessor (604) angepasst ist zum Ausführen des Verfahrens nach Anspruch 11 oder einem der Ansprüche 12 bis 21, die abhängig davon sind.
Vorrichtung (102, 104) nach Anspruch 22 oder 24, die weiterhin Folgendes aufweist: ein CDMA-Modulationsmodul (620) zum Modulieren von Dienstaushandlungsrahmen und RLP-Rahmen, die von dem Steuerprozessor (604) vorgesehen werden.
Vorrichtung nach Anspruch 26, wobei das CDMA-Modulationsmodul (620) weiterhin einen PN-Spreizer (616) zum Mulitplizieren eines Informationssignals, das die Dienstaushandlungsrahmen und die RLP-Rahmen aufweist, mit einem PN-Code.