DE60206934T2 - Verfahren zum bestätigen von daten - Google Patents

Verfahren zum bestätigen von daten Download PDF

Info

Publication number
DE60206934T2
DE60206934T2 DE60206934T DE60206934T DE60206934T2 DE 60206934 T2 DE60206934 T2 DE 60206934T2 DE 60206934 T DE60206934 T DE 60206934T DE 60206934 T DE60206934 T DE 60206934T DE 60206934 T2 DE60206934 T2 DE 60206934T2
Authority
DE
Germany
Prior art keywords
confirmation
data
radio channel
radio
indicator field
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 - Fee Related
Application number
DE60206934T
Other languages
English (en)
Other versions
DE60206934D1 (de
Inventor
Richard Kenneth ISAACS
Paul Simon DAVIS
Kier Toby PROCTOR
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 Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0120303A external-priority patent/GB0120303D0/en
Application filed by Siemens AG filed Critical Siemens AG
Publication of DE60206934D1 publication Critical patent/DE60206934D1/de
Application granted granted Critical
Publication of DE60206934T2 publication Critical patent/DE60206934T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1664Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1614Details of the supervisory signal using bitmaps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1671Details of the supervisory signal the supervisory signal being transmitted together with control information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0096Channel splitting in point-to-point links

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Near-Field Transmission Systems (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)
  • Automatic Analysis And Handling Materials Therefor (AREA)

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.
  • Figure 00060001
  • Figure 00070001
    Tabelle 1: Bestätigungs-Indikatorfeld
  • Figure 00070002
    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 (6)

  1. 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.
  2. Verfahren nach Anspruch 1, bei dem die Bestätigung die Form einer Bitmap hat.
  3. 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.
  4. 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.
  5. Verfahren nach einem der vorstehenden Ansprüche, bei dem der Funkkanal einen GERAN-Funkträger beinhaltet.
  6. Verfahren nach einem der vorstehenden Ansprüche, bei dem der verfügbare Funkkanal zum Zweck der Datenübertragung genutzt wird.
DE60206934T 2001-08-21 2002-08-19 Verfahren zum bestätigen von daten Expired - Fee Related DE60206934T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB0120303A GB0120303D0 (en) 2001-08-21 2001-08-21 Communication method
GB0120303 2001-08-21
GB0130436 2001-12-20
GB0130436A GB2379144B (en) 2001-08-21 2001-12-20 A method of acknowledging data
PCT/EP2002/009231 WO2003019852A1 (en) 2001-08-21 2002-08-19 A method of acknowledging data

Publications (2)

Publication Number Publication Date
DE60206934D1 DE60206934D1 (de) 2005-12-01
DE60206934T2 true DE60206934T2 (de) 2006-07-27

Family

ID=26246454

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60206934T Expired - Fee Related DE60206934T2 (de) 2001-08-21 2002-08-19 Verfahren zum bestätigen von daten

Country Status (10)

Country Link
EP (1) EP1419606B1 (de)
CN (1) CN1309202C (de)
AT (1) ATE308173T1 (de)
BR (1) BR0211838A (de)
CA (1) CA2458263A1 (de)
DE (1) DE60206934T2 (de)
ES (1) ES2248634T3 (de)
MX (1) MXPA04001544A (de)
RU (1) RU2292656C2 (de)
WO (1) WO2003019852A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7042857B2 (en) 2002-10-29 2006-05-09 Qualcom, Incorporated Uplink pilot and signaling transmission in wireless communication systems
US8611283B2 (en) * 2004-01-28 2013-12-17 Qualcomm Incorporated Method and apparatus of using a single channel to provide acknowledgement and assignment messages
US8891349B2 (en) 2004-07-23 2014-11-18 Qualcomm Incorporated Method of optimizing portions of a frame
JP4440037B2 (ja) * 2004-08-11 2010-03-24 株式会社東芝 通信装置及び通信方法
US8238923B2 (en) 2004-12-22 2012-08-07 Qualcomm Incorporated Method of using shared resources in a communication system
US8831115B2 (en) 2004-12-22 2014-09-09 Qualcomm Incorporated MC-CDMA multiplexing in an orthogonal uplink
EP2008390B1 (de) * 2006-04-19 2014-12-24 Telefonaktiebolaget L M Ericsson (publ) Verfahren und vorrichtung zur selektiven bestätigung
GB0619769D0 (en) * 2006-10-06 2006-11-15 Siemens Ag Variable length coding
US8296619B2 (en) * 2007-04-20 2012-10-23 Interdigital Technology Corporation Method and apparatus for indicating a temporary block flow to which a piggybacked ACK/NACK field is addressed
MX2010002139A (es) * 2007-08-24 2010-08-04 Interdigital Patent Holdings Metodo y aparato para transmitir de manera confiable bloques de radio transmitiendo campos de confirmacion/no confirmacion de datos.
JP5017089B2 (ja) * 2007-12-27 2012-09-05 株式会社東芝 無線通信システム、無線通信方法、無線通信装置および通信プログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1220830A (en) * 1984-12-28 1987-04-21 David S. Drynan Transmitting sequence numbers of information in a packet data transmission system
WO1998026567A1 (en) * 1996-12-09 1998-06-18 Motorola Inc. System controlled asymmetrical automatic repeat request protocol method
JP2002536873A (ja) * 1999-01-29 2002-10-29 ノキア ネットワークス オサケ ユキチュア データブロックを合成できる増分的冗長度通信システムにおけるシグナリング方法
US6772215B1 (en) * 1999-04-09 2004-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Method for minimizing feedback responses in ARQ protocols

Also Published As

Publication number Publication date
BR0211838A (pt) 2004-09-08
WO2003019852A1 (en) 2003-03-06
ATE308173T1 (de) 2005-11-15
CN1552137A (zh) 2004-12-01
EP1419606A1 (de) 2004-05-19
DE60206934D1 (de) 2005-12-01
MXPA04001544A (es) 2004-05-17
CA2458263A1 (en) 2003-03-06
ES2248634T3 (es) 2006-03-16
RU2292656C2 (ru) 2007-01-27
EP1419606B1 (de) 2005-10-26
CN1309202C (zh) 2007-04-04
RU2004108124A (ru) 2005-05-10

Similar Documents

Publication Publication Date Title
DE60313178T2 (de) Verfahren und einrichtung zur verminderung von übertragungsfehlern in einem zellularen system der dritte generation
DE60316218T2 (de) Anhalten der wiederholten Ubertragung von Hybrid ARQ-Daten in einem High Speed Downlink Packet Access (HSDPA) System
DE60306282T2 (de) Verfahren zur Datenkommunikation mittels Kontrollmitteilung
DE60036606T2 (de) Verfahren und einrichtung zur verwaltung von abfrageanforderungen in datenkommunikationen
DE60318873T2 (de) Verfahren zur überwachung von protokolldateneinheiten zugewiesenen übertragungssequenzzahlen zur erkennung und korrektur von übertragungsfehlern
DE60038198T2 (de) Hybrides ARQ-System mit Daten- und Kontrollkanal für Datenpaketübertragung
DE60221606T2 (de) Verfahren zum Steuern der Datenübertragung in einem Funkkommunikationssystem
DE69828766T2 (de) Zuteilung von steuerkanälen in einem paket-funknetzwerk
DE10295631B4 (de) Mechanismus für eine automatische Wiederholanforderung in einem Funkzugangsnetz
DE60113717T2 (de) Flusssteuerung in einem funkzugriffsnetzwerk
DE60035291T2 (de) Verfahren und vorrichtung zur nachrichtenübertragung mit mehrkanal stop-und-warten arq
EP1020093B1 (de) Optimierung von nachbarkanal-messberichten
DE202004017116U1 (de) Vorrichtung zur Unterstützung eines gleitenden Übergabebetriebs auf einer verbesserten Aufwärtsstrecke
DE20221907U1 (de) Vorrichtung zur drahtlosen Kommunikation
DE60206934T2 (de) Verfahren zum bestätigen von daten
DE10252536A1 (de) Verfahren und Vorrichtung zur Übertragung von Datenpaketen
DE69632092T2 (de) Sendewiederholungssteuerungsverfahren für CDMA-Mobilkommunikation
DE10252533A1 (de) Verfahren und Vorrichtung zur Übertragung von Datenpaketen
DE10244696A1 (de) Verfahren und Datenübertragungssystem zur Übertragung von Datenpaketen zwischen einem Sender und einem Empfänger
DE10252535A1 (de) Vorrichtung und ein Verfahren zur Übertragung von Datenpaketen verschiedener Verbindungen an einen Empfänger
EP1419623A1 (de) Übertragung von datenpaketen in einem funk-kommunikationssystem unter nutzung eines gemeinsamen harq (hybrid automatic repeat request)-prozesses
EP1352492B1 (de) Parallele übertragung identischer daten an mehrere endgeräte und rückübertragung von informationen über die übertragungsqualität
DE19959160B4 (de) Verfahren zur paketorientierten Datenübermittlung in einem Funk-Kommunikationssystem, Basisstation und Teilnehmerstation
EP1419639A1 (de) Verfahren zur übertragung von datenpaketen in einem funk-kommunikationssystem
DE10132577A1 (de) Verfahren zur Übertragung von Datenpaketen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE

8339 Ceased/non-payment of the annual fee