DE60206934T2

DE60206934T2 - Verfahren zum bestätigen von daten

Info

Publication number: DE60206934T2
Application number: DE60206934T
Authority: DE
Inventors: Richard Kenneth ISAACS; Paul Simon DAVIS; Kier Toby PROCTOR
Original assignee: Siemens AG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2001-08-21
Filing date: 2002-08-19
Publication date: 2006-07-27
Anticipated expiration: 2022-08-20
Also published as: BR0211838A; RU2292656C2; ATE308173T1; EP1419606B1; CN1552137A; CA2458263A1; DE60206934D1; RU2004108124A; EP1419606A1; CN1309202C; MXPA04001544A; WO2003019852A1; ES2248634T3

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Bestätigen von Daten, das insbesondere für den Einsatz für Mobiltelefonsysteme konzipiert ist.
Herkömmliche Festnetz-Telekommunikationssysteme sorgen für die bestätigte und die unbestätigte Datenübertragung. Wenn ein Datenblock zwischen zwei Punkten auf einem bestimmten Kanal übertragen wird, wird über diesen Kanal für die bestätigte Datenübertragung eine Bestätigung zurückgesendet. Eine ähnliche Anordnung wird für die mobile Datenübertragung verwendet, die auf Funkkanälen basiert. Der Datenfluss geschieht über vorab festgelegte Kanäle und die Bestätigung wird über denselben Kanal gesendet. Allerdings weist die mobile Datenübertragung eingeschränktere Kapazitäten auf, da die Übertragung über die Luftschnittstelle erfolgen muss, sodass, wenn eine Bestätigung allein für sich gesendet wird, die vorhandenen Ressourcen nicht immer effizient genutzt werden.
Gemäß der vorliegenden Erfindung umfasst ein Verfahren zur Bestätigung von Datenblöcken folgende Schritte: das Empfangen von Datenblöcken, die über einen Funkkanal übertragen werden; das Erzeugen eines Bestätigungs-Datenblocks für die empfangenen Datenblöcke, wobei dieser Bestätigungs-Datenblock ein Bestätigungs-Indikatorfeld beinhaltet; wahlweises Senden der Bestätigung über einen beliebigen verfügbaren Funkkanal, der genutzt wird; Setzen des Bestätigungs-Indikatorfeldes derart, dass es angibt, ob sich die Bestätigung auf den Empfang von Datenblöcken bezieht, die über denselben Funkkanal übertragen wurden, auf dem auch die Bestätigung übermittelt wird, oder ob sich die Bestätigung nicht auf den Empfang von Datenblöcken bezieht, die über denselben Funkkanal übertragen wurden, auf dem die Bestätigung übermittelt wird sowie Übertragen der Bestätigung auf dem verfügbaren Funkkanal.
Die vorliegende Erfindung löst die Aufgabe, dass die vorhandenen Ressourcen nicht effizient genutzt werden, indem eine Bestätigung über einen beliebigen verfügbaren Funkkanal gesendet wird, der beispielsweise zum Zweck der Datenübertragung genutzt wird, und ein Indikatorfeld bereitgestellt wird, das angibt, ob sich die Bestätigung auf den betreffenden Funkkanal bezieht oder nicht.
Vorzugsweise hat die Bestätigung die Form einer Bitmap.
Vorzugsweise wird das Bestätigungs-Indikatorfeld auf den Wert „01" gesetzt um anzuzeigen, dass die Kennung des Funkkanals in einem ACK/NACK-Paket enthalten ist, um zu kennzeichnen, auf welchen Funkkanal sich das ACK/NACK-Paket bezieht.
Vorzugsweise wird das Bestätigungs-Indikatorfeld auf den Wert „10" gesetzt um anzuzeigen, dass der empfangende Funkkanal mit dem Funkkanal für die Bestätigung identisch ist.
Vorzugsweise beinhaltet der Funkkanal einen GERAN-Funkträger.
Vorzugsweise wird der verfügbare Funkkanal zum Zweck der Datenübertragung genutzt.
Ein Beispiel für ein Verfahren zur Bestätigung von Daten gemäß der vorliegenden Erfindung wird im Folgenden unter Bezugnahme auf die beiliegenden Zeichnungen erläutert, wobei:
1 ein Verfahren gemäß der vorliegenden Erfindung darstellt, bei dem die Funkträger für Daten und Bestätigung dieselbe Kennung haben;
2 ein Verfahren gemäß der vorliegenden Erfindung für mehrere Funkträger zeigt; und
3 ein Verfahren gemäß der vorliegenden Erfindung darstellt, bei dem die Funkträger für Daten und Bestätigung dieselbe Kennung für mehrere Funkträger haben.
Das Dokument WO9826567 stellt zwei mögliche Arten von drahtlosen Systemen dar: Ein System, bei dem der Rückkanal dieselbe Funkfrequenz wie ein Vorwärtskanal nutzt; und ein zweites System, bei dem eine andere Funkfrequenz genutzt wird.
Die vorliegende Erfindung ist in der Lage, die Effizienz bei der Nutzung der vorhandenen Ressourcen von Systemen zur mobilen Datenübertragung zu verbessern. Zwar kann dieses Verfahren auch für Festnetzsysteme eingesetzt werden, jedoch ist dort der Anreiz, es zu implementieren, nicht in demselben Maße gegeben. Somit kann für Datenübertragungssysteme, die mehrere logische Kanäle nutzen, bei denen einige der logischen Kanäle bestätigte Dienste unterstützen, die Effizienz verbessert werden, indem den Bestätigungen für einen bestimmten logischen Kanal nach dem „Huckepack"-Prinzip Daten für einen anderen Kanal aufgesetzt werden (sog. „Piggy-Backing"). Ein Beispiel, wo dies eingesetzt werden kann, ist das GERAN-System, auf das im Folgenden näher eingegangen wird. Im GSM/EDGE Radio Rccess Network (GERAN) bestehen zwischen der Mobilstation und dem Netz fest geschaltete physische Subkanäle (DPSCH, Dedicated Physical Sub-Channels) über die Luftschnittstelle. Bestätigungen von Funk-Datenblöcken auf langsamen zugeordneten Steuerkanälen (SACCH, Slow Associated Control Channels), eigenständigen fest geschalteten Steuerkanälen (SDCCH, Stand-alone Dedicated Control Channels) und schnellen zugeordneten Steuerkanälen (FACCH, Fast Associated Control Channels) werden auf einem DPSCH abgebildet. Allerdings verfügen die logischen SACCH-, SDCCH- und FACCH-Kanäle, wenn sie auf einen DPSCH abgebildet werden, nur über begrenzte Kapazität. So findet sich beispielsweise der SACCH lediglich in jedem 13. und 26. Rahmen einer Mehrfachrahmen-Struktur für den DPSCH. Dementsprechend ist es wichtig, die Nutzung dieser Kanäle zu optimieren.
Die logischen SACCH-, SDCCH- und FACCH-Kanäle unterstützen sowohl bestätigte als auch unbestätigte Dienste für mehrere Funkträger. Diese logischen Kanäle können vier oder sogar acht Funkträger unterstützen, wobei jeder Funkträger durch eine Funkträgerkennung identifiziert wird. Das RLC/MAC-Protokoll (Radio Link Control/Medium Access Control-Protokoll) arbeitet über diese Schnittstelle. Die Formate der Header der RLC/MAC-Datenblöcke und -Steuerungsinformationen wurden bereits in einem Vorschlag vorgelegt. In diesem Vorschlag werden Bestätigungen für einen gegebenen Funkträger, der in einem bestätigten Modus arbeitet, im Piggy-Back-Verfahren auf Daten in Datenblöcken für denselben Funkträger aufgesetzt. Wenn keine Daten vorhanden sind, die gesendet werden sollen, kann die Bestätigung auch in einem leeren Datenblock gesendet werden. Dies stellt jedoch eine Verschwendung von Ressourcen dar, daher zielt die vorliegende Erfindung darauf ab, die Nutzung der vorhandenen Ressourcen auf Basis des Prinzips zu verbessern, dass Bestätigungen für einen Funkträger auf Daten für einen anderen Funkträger im Piggy-Back-Verfahren aufgesetzt werden können. Dies ist insbesondere im Fall mehrerer Funkträger von Vorteil, da hierdurch die Wahrscheinlichkeit verringert wird, dass eine Bestätigung in einem leeren Datenblock gesendet wird. Eine weitere Optimierung besteht darin, dass die Bestätigungen für mehrere Funkträger in einem einzigen Datenblock untergebracht werden können.
Eine Alternative besteht darin, eine Bestätigung für einen Funkträger im Piggy-Back-Verfahren auf Daten für einen Funkträger aufzusetzen, der in einem unbestätigten Modus betrieben wird. In diesem Fall ist es erforderlich, dass der Empfänger der Bestätigungen signalisiert, dass er die Bestätigung empfangen hat.
Bestätigungen können entweder im Piggy-Back-Verfahren auf Datenblöcke aufgesetzt werden oder in Blöcken gesendet werden, die keinerlei Daten enthalten, wenn für den signalisierenden Funkträger (SRB, Signalling Radio Bearer) in der Richtung, in die die Bestätigung übertragen werden soll, keine Daten zur Verfügung stehen. Im Fall mehrerer Datenblockströme (TBF, Temporary Block Flow) kann es zu einer Situation kommen, in der eine Bestätigung für einen SRB gesendet werden muss, aber für den betreffenden SRB in der Richtung, in der die Bestätigung übertragen werden soll, keinerlei Daten zur Verfügung stehen, sondern lediglich Daten für einen anderen SRB in der Richtung der Übertragung der Bestätigung verfügbar sind. In diesem Fall ist es vorteilhaft, wenn eine Bestätigung für einen SRB X zusammen mit Daten für den SRB Y gesendet wird.
Um anzuzeigen, ob die Bestätigungen für einen anderen SRB gelten als den SRB, für den der Datenblock bestimmt ist, wird die Definition eines Bestätigungs-Indikatorfeldes (AI, Acknowledgement Indicator) erweitert wie in Tabelle 1 dargestellt. Wenn das Bestätigungs-Indikatorfeld angibt, dass die Bestätigungen sich auf einen anderen SRB beziehen als den SRB, für den Daten vorhanden sind, dann hat die Bestätigungs-Bitmap das Format wie nachstehend in Tabelle 2 dargestellt.
Dieser Vorschlag erhöht die Komplexität des RLC, und eines der Probleme, die hinzukommen, bezieht sich auf das Senden von Bestätigungen zusammen mit Daten für einen unbestätigten Funkträger. Wenn Bestätigungen über einen unbestätigten Funkträger übertragen werden, können sie verloren gehen und werden nicht erneut übertragen. Dies kann dazu führen, dass das Fenster blockiert wird, sodass der Sender in regelmäßigen Abständen eine Abfrage ausführen muss, um eine Antwort zu erhalten. Alternativ könnte der Empfänger eine Bestätigung zurücksenden um anzuzeigen, dass er eine ACK/NACK-Bitmap auf einem unbestätigten Funkträger empfangen hat. Dies würde das Senden einer Funkträgerkennung sowie der Sendesequenznummer für den Beginn der ACK/NACK-Bitmap beinhalten.
Eine weitere Schwierigkeit ergibt sich bei Neuübertragungen. Wenn ein Datenblock erneut gesendet werden muss, dann sollten die Bestätigungen für den Funkträger, der in der ersten Übertragung bestätigt wurde, mitgesendet werden, obwohl die letzte Bitmap gesendet werden sollte, um beim Empfänger Probleme mit der richtigen Reihenfolge zu vermeiden. Damit der Sender der ACK/NACK-Bitmap weiß, wann er sein Fenster weiterrücken kann, wäre es erforderlich, auf jedem der Funkträger, über die die Bitmap gesendet wurde, Kopien der Bitmaps zu speichern.
Tabelle 1: Bestätigungs-Indikatorfeld
Tabelle 2: ACK/NACK-Paket
Spezifische Beispiele der Formate der Bestätigungs-Bitmaps für drei Szenarien sind in den 1 bis 3 dargestellt. In 1 ist die Bestätigungs-Bitmap für denselben Funkträger wie die Daten, wohingegen in 2 die Daten für den Funkträger 1 die Bestätigungs-Bitmaps für die Funkträger 1 und 2 enthalten. In jeder der Abbildungen wird die genaue Gestaltung der ACK/NACK-Pakete durch die Einstellung des Bestätigungs-Indikatorfeldes „AI" bestimmt. 1 zeigt den Datenfluss von der Mobilstation (MS) zum Netz über den Funkträger 1 für die Sequenznummern 5 bis 10. Beim Netz gehen alle Daten ein mit Ausnahme des Datenpakets mit der Sequenznummer 7. In dem ACK/NACK-Paket lautet die Start-Sequenznummer für die ACK/NACK-Bitmap „5", und die Bitmap zeigt an, dass die Sequenznummern 5, 6, 8, 9 und 10 empfangen wurden.
2 zeigt den Datenfluss von der Mobilstation zum Netz über die Funkträger 1, 2, und 3. Das Netz sendet eine Bestätigung mit Daten für Funkträger 3. Die Bestätigungen beziehen sich auf Daten, die über die Funkträger 2 und 3 empfangen wurden. Das Bestätigungs-Indikatorfeld „AI" ist auf den Wert „01" gesetzt und zeigt damit an, dass die Funkträgerkennung in dem ACK/NACK-Paket enthalten ist um anzuzeigen, an welchen Funkträger das ACK/NACK-Paket gerichtet ist. Die ACK/NACK-Bitmaps für die Funkträger 1 und 2 sind im Piggy-Back-Verfahren auf die Daten für den Funkträger 3 aufgesetzt.
In 3 wird derselbe Nettodatenfluss erzielt wie in 2, obwohl in 2 zwei Nachrichten weniger ausgetauscht werden. Jedoch ist das Format des ACK/NACK-Pakets aus 2 in 3 komplexer. Das Format des Datenflusses in 2 ist vorteilhaft, wenn die Notwendigkeit besteht, die Anzahl der ausgetauschten Nachrichten zu begrenzen, wie bei der Übertragung über die Luftschnittstelle im GERAN-System. Dieser Mechanismus würde in einem Festnetz wenig Nutzen bringen, wenn keine derartige Notwendigkeit herrscht, Ressourcen effizient zu nutzen.

Claims

Verfahren zum Bestätigen von Datenblöcken, wobei das Verfahren folgende Schritte umfasst: Empfangen von Datenblöcken, die über einen Funkkanal (RB1, RB2, RB3) übertragen werden; Erzeugen eines Bestätigungs-Datenblocks für die empfangenen Datenblöcke; gekennzeichnet dadurch, dass der Bestätigungs-Datenblock ein Bestätigungs-Indikatorfeld (AI) beinhaltet; wahlweises Senden der Bestätigung über einen beliebigen verfügbaren Funkkanal, der genutzt wird (RB1, RB2, RB3); Setzen des Bestätigungs-Indikatorfeldes derart, dass es angibt, ob sich die Bestätigung auf den Empfang von Datenblöcken bezieht, die über denselben Funkkanal übertragen wurden, auf dem auch die Bestätigung übermittelt wird, oder ob sich die Bestätigung nicht auf den Empfang von Datenblöcken bezieht, die über denselben Funkkanal übertragen wurden, auf dem auch die Bestätigung übermittelt wird; sowie Übertragen der Bestätigung auf dem verfügbaren Funkkanal.
Verfahren nach Anspruch 1, bei dem die Bestätigung die Form einer Bitmap hat.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Bestätigungs-Indikatorfeld auf „01" gesetzt wird um anzuzeigen, dass die Kennung des Funkkanals in einem ACK/NACK-Paket enthalten ist, um zu erkennen, auf welchen Funkkanal sich das ACK/NACK-Paket bezieht.
Verfahren nach Anspruch 1 bis 3, bei dem das Bestätigungs-Indikatorfeld auf „10" gesetzt wird um anzuzeigen, dass der empfangende Funkkanal identisch ist mit dem Funkkanal, über den die Bestätigung gesendet wird.
Verfahren nach einem der vorstehenden Ansprüche, bei dem der Funkkanal einen GERAN-Funkträger beinhaltet.
Verfahren nach einem der vorstehenden Ansprüche, bei dem der verfügbare Funkkanal zum Zweck der Datenübertragung genutzt wird.