[go: up one dir, main page]

DE60307032T2 - Steuerungs-Verfahren und -Vorrichtung zur Datenübertragung - Google Patents

Steuerungs-Verfahren und -Vorrichtung zur Datenübertragung Download PDF

Info

Publication number
DE60307032T2
DE60307032T2 DE60307032T DE60307032T DE60307032T2 DE 60307032 T2 DE60307032 T2 DE 60307032T2 DE 60307032 T DE60307032 T DE 60307032T DE 60307032 T DE60307032 T DE 60307032T DE 60307032 T2 DE60307032 T2 DE 60307032T2
Authority
DE
Germany
Prior art keywords
acknowledgment
data blocks
original data
confirmation
data segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60307032T
Other languages
English (en)
Other versions
DE60307032D1 (de
Inventor
Int.Prop.Dpt. Motoharu Miyake
Int.Prop.Dpt. Hiroshi Inamura
Int.Prop.Dpt. Osamu Takahashi
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.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Application granted granted Critical
Publication of DE60307032D1 publication Critical patent/DE60307032D1/de
Publication of DE60307032T2 publication Critical patent/DE60307032T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/1621Group acknowledgement, i.e. the acknowledgement message defining a range of identifiers, e.g. of sequence numbers
    • 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/187Details of sliding window management
    • 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/188Time-out mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809Selective-repeat protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

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

Description

  • Die vorliegende Erfindung bezieht sich auf ein Übertragungssteuerungsverfahren zur Nutzung in einem Kommunikationsverfahren entsprechend der Präambel von Anspruch 1, einer Kommunikationsvorrichtung entsprechend der Präambel von Anspruch 3, einem Kommunikationssystem entsprechend der Präambel von Anspruch 5 und einem Computerprogrammprodukt.
  • In D1, WO-A-01/97438, ist eine Leistungsverbesserung für ein Übertragungssteuerungsprotokoll für drahtlose Netzwerkanwendungen beschrieben, bei denen – insbesondere wenn bei drahtlosen Netzwerken ein Übertragungsfehler auftritt, der als Bitfehler BER-Fehler bekannt ist – ein TCP-Protokoll fälschlicherweise annimmt, dass das Netzwerk überlastet ist und seine Übertragung dramatisch von alten und neuen Paketen reduziert.
  • In D2, Floyd S. et al.r'rfc 2582 : The New Reno Modification to TCP's Fast Recovery Algorithm, Network Working Group Reguest For Comments, XX, No. 2582, pages 1–10, wird eine sogenannten Reno-Modifikationen für einen schnellen TCP-Wiederherstellungsalgorithmus beschrieben. Der beschriebene Ansatz basierend auf einer Modifikation der Nutzung einer neuen Variablen zur Nachverfolgung der höchsten nach jedem Wiedersendungs-Timeout gesendeten Sequenznummern.
  • Weiterhin wird in D3, Byung-Gon Chun et al.: 'Auxiliary timeout and selective packet discard Scheines to improve TCP peformance in PCN environment', Communications, 1997. ICC '97 Montreal, Towards The Knowledge Millennium. 1997 IEEE International Conference on Montreal, Quebec, Canada 8–12 June 1997, New York, NY, USA, IEEE, U.S., pages 381–385, ein Ersatz-Timeout und in selektives Paketlöschungsverfahren zur Erhöhung der TCP-Leistung in PCN-Umgebungen beschrieben.
  • Vorrichtungen, die TCP (Transmission Control Protocol) zum Senden und Empfangen von Daten nutzen, sind inzwischen weit verbreitet.
  • TCP ist ein unter dem OSI-Referenzmodel (Open Systems Interconnection) genutztes Protokoll, und es wird genutzt, wenn von einer Sendevorrichtung zu einer Empfangsvorrichtung zu übertragenede Daten in einer höheren Schicht zur Übertragung in Datensegmente aufgeteilt werden. TCP stellt eine verlässliche Übertragung von geordneten Datensegmenten zu einer Empfangsvorrichtung sicher. Insbesondere wird jedem Datensegment in einer Datensequenz eine Nummer (nachfolgend als "Sequenznummer" bezeichnet) zugeordnet, um eine Reihenfolge der Datensegmente in der Datensequenz festzulegen. Eine Sendevorrichtung ordnet eine Sequenznummer einem Header jedes zu übertragenden Datensegmentes zu, wenn das Datensegment übertragen wird. Wenn es von der Empfangsvorrichtung keine Bestätigung über den Empfang von gesendeten Datensegmente innerhalb einer angenommenen Zeit (Timeout) gibt, wobei die Zeit basierend auf einer angenommen Zeit für die Übertragung des Datensegmentes von seinem Anfang bis zur Bestätigung seines Empfangs (das heißt, geschätzte Round-Trip-Zeit des Datensegmentes) bestimmt wird, nimmt die Sendevorrichtung vorsichtshalber an, dass das Datensegment ohne die Empfangsvorrichtung zu erreichen verloren gegangen ist, und überträgt das Datensegment zu der Empfangsvorrichtung erneut.
  • Wenn bei der Empfangsvorrichtung eine Bestätigung empfangen wird, weist eine Nummer in einem Header der empfangenen Bestätigung darauf hin, welches Datensegment der empfangenen Bestätigung entspricht. Wenn die Empfangsvorrichtung eine Bestätigung sendet, setzt es eine Sequenznummer eines Datensegmentes, von dem erwartet wird, dass es als nächstes empfangen wird, in ein "Bestätigungsnummer"-Feld in dem Header der Bestätigung. Wenn beispielsweise Sequenznummern bei 500 beginnen und von 1000, 1500 und so weiter gefolgt werden, wird eine Bestätigungsnummer in einer an die Sendevorrichtung zu übertragenen Bestätigung 1000 gesetzt, wenn ein Datensegment mit der Sequenznummer "500" empfangen wurden. Nachdem die Sendevorrichtung solch eine Bestätigung empfangen hat, stellt sie fest, dass ein übertragenes Datensegment sicher von einer Empfangsvorrichtung empfangen wurde und überträgt ein nachfolgendes Datensegment.
  • Es sei darauf hingewiesen, dass eine Sendevorrichtung eine Bestätigung mit einer Bestätigungsnummer 1000 empfängt, wobei die Sendevorrichtung noch nicht ein Datensegment mit einer Sequenznummer 1000 gesendet hat, oder wenn das Datensegment bereits übertragen wurde, wurde das Segment nicht von der Empfangsvorrichtung empfangen. Diese Bestätigungsnummer bleibt auf 1000 gesetzt, bis ein Datensegment, das eine Sequenznummer 1000 enthält von der Empfangsvorrichtung empfangen wurde. Das gilt selbst dann, wenn ein nachfolgendes Datensegment mit einer Sequenznummer 1500 bereits von der Empfangsvorrichtung bedingt durch einen Verlust von dem Datensegment mit einer Sequenznummer 1000 empfangen wurde. Somit wird eine Sequenznummer des zuletzt empfangenen Datensegmentes, welches nicht durch eine Empfangsvorrichtung empfangen wurde; als eine Bestätigungsnummer gesetzt.
  • In dem oben erklärten Datensegmentübertragungsverfahren wird die Zuverlässigkeit durch ausschließliche Übertragung eines nachfolgenden Datensegmentes von einer Sendevorrichtung erreicht, nachdem von der Vorrichtung von der Empfangsvorrichtung eine Bestätigung für ein vorher übertragenes Datensegment empfangen wurde. Obwohl dieses Verfahren eine Übertragungssicherheit sicherstellt, verhindert es Effizienz. Um die Effizienz zu erhöhen, stellt TCP ein Verfahren zur Übertragung einer bestimmten Anzahl von Datensegmenten entsprechend einer Anzahl, die durch ein "Fenster" definiert ist, bereit. Ein "Fenster" ist eine Anzahl von Bytes oder eine Anzahl von Datensegmenten, die vor dem Empfang einer Bestätigung übertragen werden können. Eine Fenstergröße wird von einer Sendevorrichtung so festgelegt, dass die verfügbare Puffergröße in der Sendevorrichtung nicht überschritten wird. Wenn eine Sendevorrichtung eine Bestätigung für ein übertragenes Datensegment(e) empfängt, gleitet ein Fenster um die Anzahl von Datensegmenten weiter, für die eine Bestätigung empfangen wurde, und ein nachfolgendes Datensegment(e) wird entsprechend dem weiter gleitenden Fenster übertragen. Das Verfahren wird als "Gleitfensterverfahren" bezeichnet; und durch die Steuerung der Fenstergröße und wird der Datenfluss gesteuert.
  • Wenn beispielsweise ein Datenfluss bedingt durch eine Unterbrechung der drahtlosen Kommunikation oder einer Überlastung im System unterbrochen wird, wenn ein Gleitfensterverfahren angewendet wird, können übertragene Datensegmente in dem System entweder verloren gehen, oder sie müssen zeitweise in einem Knoten in dem Netzwerk zwischengespeichert werden bis die Datenkommunikation wiederhergestellt ist. Insbesondere in drahtlosen Kommunikationsumgebungen ist ein Datenverlust wahrscheinlicher. Nach einer Herstellung der Datenkommunikation sind alle temporär in einem Knoten des Netzwerkes gespeicherten Daten in der Lage, die Empfangsvorrichtung – wenn auch mit etwas Verzögerung – zu erreichen.
  • Wenn allerdings eine Kommunikationsunterbrechung für eine relativ lange Zeit auftritt, und ein Timeout an der Sendevorrichtung für ein zu übertragendes Datensegment auftritt, überträgt die Sendevorrichtung ein erstes Datensegment aus Datensegmenten, die bis dahin übertragen wurden, die aber noch nicht bestätigt wurden. Im Ergebnis empfängt die Empfangsvorrichtung sowohl das temporäre in dem Netzwerk gespeicherte Datensegment (nachfolgend als ein „Originaldatensegment" bezeichnet) und das erneut übertragene Datensegment. Die Empfangsvorrichtung schickt dann eine Bestätigung für das Originaldatensegment bei seinem Empfang und sendet auch eine Bestätigung für ein erneut übertragenes Datensegment bei seinem Empfang; jede dieser Bestätigungen hat normalerweise die gleiche Bestätigungsnummer. Dies führt zu dem Problem, dass die Sendevorrichtung nicht in der Lage ist, festzustellen, ob eine empfangene Bestätigung zu einem ursprünglich gesendeten oder zu einem wieder übertragenen Datensegment gehört, und verfällt in einen Status, bei dem festgestellt wird, dass das Originaldatensegment die Empfangsvorrichtung nicht erreicht hat.
  • In den folgenden beiden Beispielen wird eine Erklärung für solch eine Situation aufgezeigt.
  • 10 ist ein Beispielsequenzdiagramm, das einen Fall aufzeigt, bei dem eine Paketkommunikation zwischen einer Server-Vorrichtung 10' (eine Sendevorrichtung) und einer Client-Vorrichtung 50 (Empfangsvorrichtung) ausgeführt wird. Eine vierstellige Nummer, welche rechts von einem Ursprungspunkt auf jedem Pfeil bei der Server-Vorrichtung 10' in der Figur erscheint, ist eine Sequenznummer eines von der Server-Vorrichtung 10' übertragenen Datensegmentes; und eine vierstellige Nummer, die links von einem Ursprungspunkt jedes Pfeils der Empfangsvorrichtung 50 in der Figur erscheint, ist eine Bestätigungsnummer, die in einer Bestätigung enthalten ist, die von der Client-Vorrichtung 50 übertragen wird. Es wird angenommen, dass eine Originalgleitfenstergröße drei ist, das heißt, dass drei Datensegmente ohne den Empfang einer Bestätigung gesendet werden können.
  • In 10 werden drei Datensegmente (Originaldatensegmente) S1–S3 ein erstes Mal von einer Server-Vorrichtung 10' übertragen, wobei die Datensegmente S1, S2 und S3 die Sequenznummern 0, 1000 und 2000 aufweisen.
  • In der Figur werden die Datensegmente S1, S2 und S3 von der Client-Vorrichtung 50 mit einer Verzögerung bedingt durch eine Beeinträchtigung der Netzwerkkommunikationsbedingungen empfangen. Nach dem Empfang des Originaldatensegmentes S1 sendet die Server-Vorrichtung 10' eine Bestätigung R1, die die Bestätigungsnummer 1000 aufweist. In gleicher Weise sendet die Client-Vorrichtung 50 nach dem Empfang des Originaldatensegmentes S2 eine Bestätigung mit einer Bestätigungsnummer 2000 und eine Bestätigung R3 mit einer Bestätigungsnummer 3000 nachdem Empfang des Originaldatensegmentes S3.
  • Wie in der Figur dargestellt empfängt die Server-Vorrichtung 10' keine Bestätigung von der Empfangsvorrichtung 50 bevor eine aufgelaufenen Zeit, die durch einen Timer gemessen wird, einen Timeout-Wert überschreitet. Im Ergebnis stellt die Server-Vorrichtung 10' fest, dass das Originaldatensegment S1 zum Zeitpunkt des Timeout nicht durch die Client-Vorrichtung 50 empfangen wurde und überträgt ein Datensegment, welches die Nummer 0 aufweist (wieder übertragenes Datensegment S'1). Ein Datensegment, das heißt, das wieder übertragene Datensegment S'1 wird hier gesendet, weil eine Fenstergröße auf Grund des Timeout auf einen minimalen Wert reduziert wird.
  • Die Server-Vorrichtung 10' empfängt eine Bestätigung R1, welche als Bestätigungsnummer 1000 aufweist. Hierbei ist die Server-Vorrichtung 10' aus den oben genannten Gründen auf der Basis der Bestätigungsnummer 1000 nicht fähig festzustellen, ob die Bestätigung R1 zu dem Originaldatensegment S1 oder dem wieder übertragenen Datensegment S'1 gehört. Deshalb behandelt die Server-Vorrichtung 10' die Bestätigung R1 so, als wenn sie zu dem wieder übertragenen Datensegment S'1 gehört, und ein Datensegment mit einer Sequenznummer 1000 wird deshalb wieder übertragen (wieder übertragenes Datensegment S'2). Die Server-Vorrichtung 10' überträgt weiterhin ein Datensegment, das eine Sequenznummer 2000 aufweist (wieder übertragenes Datensegment S'3), weil die Fenstergröße nach dem Empfang der Bestätigung R1 um 1 vergrößert wurde.
  • Die Server-Vorrichtung 10' empfängt folglich eine Bestätigung R2 mit einer Bestätigungsnummer 2000, und ein nachfolgender Originaldatensegment (Originaldatensegment S4 und folgende Originaldatensegmente) werden nacheinander gesendet.
  • In dem Beispiel werden Originaldatensegmente S2 und S3 wieder übertragenen (wieder übertragene Daten Segmente S'2 und S'3), obwohl sie sicher bei der Client-Vorrichtung 50 ankamen. Das bedeutet, dass wenn Datensegmente S2 und S3 jede von der Client-Vorrichtung 50 zu zwei unterschiedlichen Zeiten empfangen werden, die Wiederübertragung der Datensegmente S2 und S3 in unnötigen Übertragungen resultieren, obwohl dieses nicht zu dem Zeitpunkt der Wiederübertragung festgestellt war. Darüber hinaus ist von 10 klar, dass die Bestätigungen R'2 und R'3 auch in Antwort auf die wieder übertragenen Datensegmente S'2 und S'3 übertragen werden. Somit wird eine Gesamtzahl von 4 Datensegmenten unnötigerweise übertragen.
  • 11 zeigt ein zweites Beispiel bei dem unnötige Wiederübertragungen von Datensegmenten auftreten. Um zu verhindern, dass eine Empfangsvorrichtung eine überflüssige Anzahl von Bestätigungen sendet, erlaubt TCP, dass eine Übertragung einer Bestätigung von einer Empfangsvorrichtung entsprechend einer vorher bestimmten Zeit verzögert werden kann, und dass die Bestätigung mit der nächsten Datenübertragung von der Empfangsvorrichtung übertragen werden kann ("Delayed Acknowledgement", RFC 2581). Trotzdem sollte für den Fall des Empfangs von zwei vollständigen großen Datensegmenten nacheinander in einer vorher bestimmten Zeit eine Bestätigung ohne ein Warten auf eine nächste Datenübertragung gesendet werden. Das heißt, dass in dem Fall, in dem zwei Datensegmente innerhalb einer kurzen Zeitspanne empfangen werden, beispielsweise innerhalb von 200 msec (Millisekunden), eine Bestätigung, die über den Empfang der beiden Datensegmente informiert, durch eine einzige Bestätigung substituiert werden kann. Insbesondere überträgt eine Empfangsvorrichtung eine Bestätigung für das zweite empfangene Datensegment, um eine Sendevorrichtung über den Empfang der beiden Datensegmente zu informiert. Dieses ist der Fall in dem Beispiel, das in 11 dargestellt ist.
  • In 11 werden die Originaldatensegmente und S1, S2 und S3 von der Server-Vorrichtung 10' übertragen und nachfolgend von der Client-Vorrichtung 50 mit einer Verzögerung bedingt durch eine Beeinträchtigung in dem Kommunikationspfad, wie im Fall von 10 angenommen, empfangen. Folglich sendet die Client-Vorrichtung 50 eine Bestätigung R2. In der Zwischenzeit überträgt die Server-Vorrichtung 10', bedingt durch den Timeout, das Datensegment S1 (wieder übertragenes Datensegment S'1). Ein Datensegment, das heißt das wieder übertragene Datensegment S'1, wird hier übertragen, weil eine Fenstergröße auf Grund des Timeout auf einen minimalen Wert reduziert wurde.
  • Die Server-Vorrichtung 10' empfängt nachfolgend die Bestätigung R2, die von der Client-Vorrichtung 50 gesendet wurde. Nach dem Empfang bezieht sich die Server-Vorrichtung 10' auf die Bestätigungsnummer 2000, die in der Bestätigung R2 enthalten ist, und überträgt ein Segmente wieder, das die gleiche Sequenznummer aufweist, das heißt das Originaldatensegment S3. Die Server-Vorrichtung 10' überträgt weiterhin ein nachfolgendes Originaldatensegment S4, welches eine Sequenznummer 3000 aufweist, weil die Fenstergröße bei dem Empfang der Bestätigung R2 um ein Datensegment vergrößert wurde.
  • Die Server-Vorrichtung 10' empfängt nachfolgend eine Bestätigung R3, welche eine Bestätigungsnummer 3000 aufweist, die von der Client-Vorrichtung 50 gesendet wurde. Folglich überträgt die Server-Vorrichtung 10' nachfolgend ein Originaldatensegment S5, welches eine nachfolgende Sequenznummer 4000 aufweist, sowie die nachfolgenden Datensegmente.
  • In diesem Beispiel wird das Originaldatensegment S3 erneut übertragen, obwohl das Segment S3 aktuell sicher von der Client-Vorrichtung 50 empfangen wurde; und wie in 11 dargestellt, wird auch eine Bestätigung R'3 für das wieder übertragene Datensegment S'3 übertragen. Somit stellen die Wiederübertragung des Datensegmentes S'3 und die Bestätigung R'3 unnötige Übertragungen dar.
  • Solche unnötigen Übertragungen von Datensegmenten werden nicht ausgeführt, wenn festgestellt wird, dass eine Bestätigung, die nach einer Wiederübertragung eines Datensegmentes empfangen wird, zu einem Originaldatensegment in dem Fall gehört, bei dem eine Sendevorrichtung nicht in der Lage ist festzustellen, ob eine Bestätigung zu dem Originaldatensegment oder zu dem wieder übertragenen Datensegment gehört.
  • Wenn allerdings solch eine Feststellung gemacht wird, wird eine Bestätigung für ein wieder übertragenes Datensegment als eine Bestätigung für ein Originaldatensegment angesehen, wobei ein Fenster vorwärts gleitet, was eine Übertragung von einem nachfolgenden Datensegment auslöst. Wenn solch eine Übertragung von einem Originaldatensegment wiederholt wird, gibt es ein erhöhtes Risiko einer kumulativen Erhöhung in der Anzahl der Datensegmente, die von der Server-Vorrichtung 10' übertragen werden, die aber nicht die Client-Vorrichtung 50 erreichen.
  • Um dieses Risiko zu vermeiden, wird default-mäßig festgestellt, dass eine Bestätigung in dem Fall zu einem Originaldatensegment gehört, in dem eine Sendevorrichtung nicht in der Lage ist festzustellen, ob eine Bestätigung zu dem Originaldatensegment oder einem wieder übertragenen Datensegment gehört. Durch diese Feststellung ist eine Sendevorrichtung nicht in der Lage, unnötige Wiederübertragungen eines Datensegmentes zu vermeiden.
  • Um dieses Problem zu lösen veröffentlicht "The Eifel Detection Algorithm for TCP" (Reiner Ludwig, et. al, http://www.watersprings, org/pub/id/draft-ietf-tsvwg-tcp-eifel-alg-04.txt, 24 July, 2002, vorher verfügbar unter http://www.ietf.org/intemet-oVafts/draft-ietf-tsvwg-tcp-eifel-alg-04.txt) eine Technik um zuverlässig festzustellen, ob eine Bestätigung zu einem Originaldatensegment oder einem wieder übertragenen Datensegment durch Nutzung der TCP-Zeitstempeloption, die in RFC 1323 definiert ist, gehört.
  • Weiterhin schlagen Allman et. al in "On Estimating End-To-End Network Path Properties. 2.8 Impact of Bad Timeouts" (Mark Allman, Vern Paxson, ACM SIGCOMM '99, vol.29, no.4, pp 263–274, Oct. 1999) eine Technik zur Nutzung von statistischen Informationen vor, um abzuschätzen, ob in einem Draht gebundenen Paketkommunikationsnetzwerk eine empfangene Bestätigung zu einem Originaldatensegment oder einem wieder übertragenen Datensegment bei einer Paketkommunikation gehört.
  • In dem Allman-Vorschlag wird die Abschätzung auf der Basis der Hälfte der minimalen Umlaufzeit als ein Schwellenwert ausgeführt, wobei die Minimalumlaufzeit der kleinste Wert einer Vielzahl von Umlaufzeiten ist, die durch Messung einer Zeit erhalten wird, von wo ein Datensegment übertragen wurde bis zu einer Zeit, zu der eine Bestätigung für das Datensegment empfangen wurde, während eine Verbindung zwischen einer Sendevorrichtung und einer Empfangsvorrichtung aufrecht erhalten bleibt. Bei diesem Verfahren wird die empfangene Bestätigung als zu dem wieder übertragenen Datensegment gehörig angesehen, wenn eine Zeit, die von der Wiederübertragung eines Datensegmentes bis zu einer Zeit, wenn eine erste Bestätigung empfangen wird, aufläuft, gleich oder größer als der Schwellenwert ist, wobei die aufgelaufenen Zeit kleiner (oder kleiner/gleich) als der Schwellenwert ist, wenn die empfangene Bestätigung als zu dem Originaldatensegment gehörig angesehen wird.
  • Die Bestimmung der Schwellenwertzeit als die Hälfte einer minimalen Umlaufzeit basiert auf den folgenden Bedingungen:
    • 1. Statistisch ist eine Wahrscheinlichkeit für eine Bestätigung für ein übertragenes Originaldatensegment ungefähr in Folgendem die gleiche: eine Periode von einer Wiederübertragung bis zu 1/2 einer minimalen Umlaufzeit; eine Periode von einer Wiederübertragung bis 3/4 einer minimalen Umlaufzeit; und einer Periode von einer Wiederübertragung bis zu einer kompletten minimalen Umlaufzeit; und
    • 2. Statistisch steigt die Wahrscheinlichkeit eines Empfangs einer Bestätigung für ein wieder übertragenes Datenelement ab einem Zeitpunkt kurz nach 1/2 der minimalen Umlaufzeit ab der Wiederübertragung scharf an.
  • Wenn allerdings der Eifel-Feststellalgorithmus benutzt wird, wird immer eine Zeitstempelinformationen an das Originaldatensegment bei der Sendevorrichtung und an eine Bestätigung von der Empfangsvorrichtung auch bei guten Netzwerkbedingungen angehängt. Dies bedeutet, dass die Größe von sowohl dem Originaldatensegment als auch der Bestätigung des Datensegmentes erhöht wird. Diese Erhöhung in dem Umfang der übertragenen Daten führt zu einer Erhöhung der Kommunikationsgebühren, wenn Abonnenten für die Kommunikation proportional zum Umfang von durch das Netzwerk übertragenen Segmenten bezahlen. Solch eine unerwünschte Erhöhung in den Kommunikationsgebühren wird wahrscheinlich negativer betrachtet, wenn die Netzwerkbedingungen gut sind und die Vorkommnisse für Datenwiederübertragungen wahrscheinlich gering sind. Es ist klar, dass solche Erhöhungen in den Kommunikationsgebühren für Nutzer von Empfangsvorrichtungen oder Sendevorrichtung nicht wünschenswert sind.
  • Es ist möglich, Zeitstempelinformationen in reservierten Bits eines TCP-Header zum Zeitpunkt einer Kommunikation unterzubringen anstelle die Information zu einem Datensegment hinzuzufügen. Leider unterstützen existierende Kommunikationssysteme so ein Verfahren nicht, und folglich müssten Sende- und Empfangsvorrichtungen signifikant modifiziert werden, um so ein Verfahren anzuwenden.
  • Außerdem kann auch dann, wenn die Technik von Allman genutzt wird, kein optimales Ergebnis bei der Bestimmung bei einer mobilen Kommunikationsumgebung erreicht werden, bei denen sich Datensegmentverzögerungen in drahtlosen Sektionen ankündigen.
  • Zusammenfassung
  • Die vorliegende Erfindung sieht vor, die obigen Probleme zu lösen, und ein Ziel ist die Vorstellung einer Technik, die eine verlässliche Bestimmung zulässt, ob eine von einer Sendevorrichtung empfangene Bestätigung für ein Originaldatensegment oder für ein wieder übertragenes Datensegment bestimmt ist. Insbesondere erhöht die hier beschriebene Technik nicht die Datenmenge und erfordert kein Redesign einer Empfangsvorrichtung und ein kleines Redesign einer Sendevorrichtung.
  • Um das obige Problem zu lösen, stellt die vorliegende Erfindung ein Übertragungssteuerverfahren zur Nutzung in einem Kommunikationsnetzwerk bereit, welches die Merkmale von Anspruch 1 aufweist, ein Übertragungsteuerverfahren zur Nutzung in einem Kommunikationsnetzwerk.
  • Entsprechend einem bevorzugten Ausführungsbeispiel, bei dem eine Anzahl der Vielzahl von gesendeten Originaldatenblöcken in dem Übertragungsschritt entsprechend einer Fenstergröße festgestellt wird, die eine Anzahl von Datenblöcken definiert, die übertragen werden, ohne dass eine Bestätigung empfangen wird; dabei enthält der Wiederübertragungsschritt eine Veränderung in der Fenstergröße auf eine Minimalgröße, wenn der Datenblock, der nicht innerhalb einer vorher festgelegten Zeit bestätigt wird, übertragen wird, und Wiederübertragung einer Anzahl von Datenblöcken entsprechend der geänderten Fenstergröße; und wobei der Erinnerungsschritt das Speichern der Fenstergröße in einer Speichervorrichtung (102) enthält, die den Wert vor der Änderung auf die minimale Fenstergröße hat; und wobei der Übertragungsschritt eine Vergrößerung der Fenstergröße enthält, wenn festgestellt wird, dass das Bestätigungssignal den Empfang von einem aus einer Vielzahl von Originaldatenblöcken in der Weise bestätigt, dass die Fenstergröße und gleich oder größer dem gespeicherten Wert ist, und Übertragung einer Anzahl von Datenblöcken, die entsprechend der erhöhten Fenstergröße bestimmt wird.
  • Die vorliegende Erfindung stellt weiterhin eine Kommunikationsvorrichtung mit den Merkmalen gemäß Anspruch 3 bereit.
  • In einem bevorzugten Ausführungsbeispiele wird eine Anzahl der Vielzahl von Originaldatenblöcken, die durch die Übertragungsmittel (101) übertragen werden, entsprechend einer Fenstergröße festgestellt, die eine Anzahl von Datenblöcken definiert, die ohne Empfang einer Bestätigung übertragen werden können; wobei die Wiederübertragungsmittel (101) angepasst sind, die Fenstergröße auf eine minimale Größe zu verändern, wenn ein Datenblock wieder übertragen wird, der nicht in einer vorher festgelegten Zeit bestätigt wird, und Wiederübertragung einer Anzahl von Datenblöcken entsprechend der geänderten Fenstergröße; wobei die Speichermittel (102) angepasst sind, einen Wert einer Fenstergröße zu speichern, der derjenige ist, bevor die Fenstergröße auf die minimale Größe geändert wurde; und wobei die Übertragungsmittel (101) angepasst sind, die Fenstergröße zu erhöhen, wenn festgestellt wird, dass das Bestätigungssignal den Empfang eines aus einer Mehrzahl von Originaldatenblöcken derart bestätigt, dass die Fenstergröße gleich oder größer dem gespeicherten Wert ist, und Übertragung einer Anzahl von Originaldatenblöcken, die entsprechend der erhöhten Fenstergröße bestimmt wird.
  • Die vorliegende Erfindung stellt weiterhin ein Kommunikationssystem mit den Eigenschaften von Anspruch 5 zur Verfügung.
  • Weiterhin stellt die vorliegende Erfindung ein Computerprogrammprodukt vor, dass die Merkmale von Anspruch 6 aufweist.
  • Das Programm kann auf verschiedenen Arten von Speichermedien wie ein Magnetband, eine Magnetplatte, eine Floppy-Disk, ein optisches Medium, ein magneto-optisches Aufzeichnungsmedium, eine DVD (Digital Video Disk), eine RAM und anderes gespeichert sein.
  • Die vorliegende Erfindung ermöglicht eine optimale Bestimmung darüber, ob eine Bestätigung, die von einer Sendevorrichtung empfangen wird, zu einem Originaldatensegment oder einem wieder übertragenem Datensegment gehört, ohne die Datenmenge eines Datensegmentes zu erhöhen. Folglich können unnötige Übertragungen von Datensegmenten vermieden werden. Darüber hinaus benötigt die vorliegende Erfindung kein Redesign einer Empfangsvorrichtung und ein kleines Redesign einer Sendevorrichtung.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Blockdiagramm, das eine Konfiguration eines Kommunikationssystems 1 entsprechend einem ersten Ausführungsbeispiel der vorliegenden Erfindung darstellt.
  • 2 ist ein Blockdiagramm, das eine Konfiguration einer Server-Vorrichtung 10 entsprechend dem Ausführungsbeispiel darstellt.
  • 3 ist ein Diagramm, das eine Datenkonfiguration eines Header darstellt, der an ein Datensegment entsprechend dem Ausführungsbeispiel hinzugefügt wird.
  • 4 ist ein Sequenzdiagramm, das ein Beispiel der Ausführung einer Paketkommunikation zwischen einer Server-Vorrichtung 10 und einer Client- Vorrichtung 50 entsprechend dem Ausführungsbeispiel darstellt.
  • 5 ist ein Flussdiagramm, das den Betrieb einer Übertragung und eines Empfangs von Datensegmenten von einer Server-Vorrichtung 10 darstellt.
  • 6 ist ein Diagramm zu Beschreibung eines Fensters entsprechend einem zweiten Ausführungsbeispiel der vorliegenden Erfindung.
  • 7 ist ein Sequenzdiagramm, das ein Beispiel einer Ausführung einer Paketkommunikation zwischen einer Server-Vorrichtung 10 und einer Client-Vorrichtung 50 entsprechend dem zweiten Ausführungsbeispiel darstellt.
  • 8 ist ein Flussdiagramm, das den Betrieb einer Server-Vorrichtung 10 des Sendens und Empfangens von Datensegmenten entsprechend dem zweiten Ausführungsbeispiel darstellt.
  • 9A und 9C sind Diagramme zur Beschreibung von Änderungen in einem Engpassfenster nach dem zweiten Ausführungsbeispiel darstellt.
  • 10 ist ein Sequenzdiagramm, das ein Beispiel einer Ausführung einer Paketkommunikation zwischen einer konventionellen Server-Vorrichtung 10' und einer Client-Vorrichtung 50 darstellt.
  • 11 ist ein Sequenzdiagramm, das ein anderes Beispiel einer Ausführung einer Paketkommunikation zwischen einer konventionellen Server-Vorrichtung 10' und einer Client-Vorrichtung 50 darstellt.
  • Beschreibung von bevorzugten Ausführungsbeispielen
  • Nachfolgend werden bevorzugte Ausführungsbeispiele der vorliegenden Erfindung mit Bezug auf die beigefügten Zeichnungen erklärt. Um unnötige Beschreibungen zu vermeiden, werden Beschreibungen von Komponenten nicht wiederholt.
  • A. Erstes Ausführungsbeispiel
  • 1. Konfiguration
  • Konfigurationen des Kommunikationssystems 1:
  • 1 ist ein Blockdiagramm, welches eine Konfiguration eines Kommunikationssystems 1 entsprechend einem ersten Ausführungsbeispiel der vorliegenden Erfindung darstellt.
  • Ein Kommunikationsendgerät 40 ist an eine Client-Vorrichtung 50 angeschlossen und führt eine Kommunikation mit einer Client-Vorrichtung 50 aus. Ein mobiles Paketkommunikationsnetzwerk 30 stellt Endgeräten 40, die einen Service aus dem Netzwerk 30 beziehen, Paketkommunikationsservice zur Verfügung. Die Server-Vorrichtung 10 führt eine Paketkommunikation mit einer Client-Vorrichtung 50 über das Internet 20, einem Mobilpaketkommunikationsnetzwerk 30 und einem Kommunikationsendgerät 40 aus. Es wird bei dem vorliegenden Ausführungsbeispiel angenommen, dass TCP (Tansmission Control Protocol) zur Ausführung der Paketkommunikation genutzt wird, wobei Datensegmente übertragen werden.
  • Konfiguration der Server-Vorrichtung 10:
  • Als Nächstes wird eine Beschreibung einer Konfiguration einer Server-Vorrichtung 10 angegeben. Die Server-Vorrichtung 10 ist auf die gleiche Art konfiguriert, wie ein Standard-Computer, und deshalb werden nur solche Komponenten unter Zuhilfenahme von 2 beschrieben, die sich auf die vorliegende Erfindung beziehen.
  • Eine CPU 100 führt ein Programm aus, welches in der Speichereinheit 105 gespeichert ist, wodurch jede Komponente der Server-Vorrichtung 10 gesteuert wird. Die CPU 100 umfasst einen Timer 100a, welcher ein Trigger-Signal ausgibt, wenn eine vorher bestimmte Zeit, die durch die CPU 100 gesetzt wird, abgelaufen ist. Die Speichereinheit 105 umfasst ein RAM (Random Access Memory) 102, ein ROM (Read Only Memory) 103 und eine HD (Hard Disk) 104.
  • ROM 103 speichert ein Programm, welches bewirkt, dass die CPU 100 eine Datensegmentübertragung steuert. Insbesondere teilt die CPU 100 Daten in Segmente, wenn Daten an eine Client-Vorrichtung 50 übertragen werden, fügt einen Header an jede der geteilten Datensegmente an und überträgt die Segmente sequenziell an die Client-Vorrichtung 50.
  • In dem vorliegenden bevorzugten Ausführungsbeispiel nutzt die CPU 100 das oben beschriebene Gleitfensterverfahren, um Datensegmente an die Client-Vorrichtung 50 basierend auf Parametervariablen (die in einem zweiten Ausführungsbeispiel detailliert sind), die auf der HD 104 gespeichert sind, zu übertragen.
  • 3 stellt eine Datenkonfiguration für einen Header dar, welcher an ein Datensegment angefügt wurde. Die CPU 100 teilt dem "Sequenznummernfeld" des Header eine Sequenznummer zu, wie es in 3 dargestellt ist, fügt andere notwendige Information in jeden Datenbereich des Header ein und fügt den Header an das Datensegment an.
  • Nach der Übertragung eines Datensegmentes zu einer Client-Vorrichtung 50 wartet die CPU 100 auf eine Bestätigung, welche darauf hinweist, dass das Datensegment von der Client-Vorrichtung 50 empfangen wurde. Eine Datenkonfiguration für einen Header, welcher an eine Bestätigung angehängt wird, ist der gleiche wie der in 3 dargestellte. In dem "Bestätigungsnummernfeld" des in 3 dargestellten Header wird eine Sequenznummer, welche die Client-Vorrichtung 50 als nächste zu empfangen erwartet, von der Client-Vorrichtung 50 gesetzt.
  • Die CPU 100 setzt den Timer 100a auf einen vorher bestimmten Wert (auf den als "ein Timeout-Wert" Bezug genommen wird) und bewirkt, dass der Timer 100a eine aufgelaufenen Zeit misst, während die Server-Vorrichtung 10 auf eine Bestätigung wartet. In dem Fall, in dem ein Trigger-Signal von dem Timer 100a ausgegeben wird, wobei das Signal, das darauf hinweist, dass der Timeout-Wert aufgelaufen ist, vor dem Empfang einer Bestätigung empfangen wurde, ermittelt die CPU 100, dass das Datensegment nicht von der Client-Vorrichtung 50 empfangen wurde. Die CPU 100 setzt dann den Wert des Timer 100a zurück und überträgt das Datensegment erneut. Wenn eine Server-Vorrichtung 10 nach einer Wiederübertragung eine Bestätigung empfängt, bestimmt die CPU 100, ob die empfangene Bestätigung zu einem Originaldatensegment oder zu einem wieder übertragenen Datensegment in der Weise korrespondiert wie es unten beschrieben ist.
  • In dem Entscheidungsprozess vergleicht die CPU 100 zuerst eine Bestätigungsnummer, die in der empfangenen Bestätigung (nachfolgend als "eine Bestätigungsnummer zum Vergleich") enthalten ist, mit einer Bestätigungsnummer (nachfolgend als „eine erwartete Bestätigungsnummer" bezeichnet), die von einer Bestätigung erwartet wird, die in Antwort auf das wieder übertragene Segment übertragen wird. Es sei darauf hingewiesen, dass die Bestätigungsnummer, die in Antwort auf das wieder übertragene Datensegment übertragen wird, eine Sequenznummer eines Datensegmentes ist, die auf diejenige des wieder übertragenen Datensegmentes folgt. In einem Ausführungsbeispiel kann die CPU 100 zur Zeit einer Wiederübertragung die Sequenznummer eines Datensegmentes, die nachfolgend zu dem wieder übertragenen Datensegment als eine erwartete Bestätigungsnummer ist, in einem RAM 102 speichern. Die aufgezeichnete, erwartete Bestätigungsnummer wird gelesen und für einen Vergleich in dem Fall genutzt, in dem der Entscheidungsprozess beim Empfang einer Bestätigung ausgeführt wird. Wie weiterhin detaillierter in der Beschreibung des zweiten Ausführungsbeispiels beschrieben ist, speichert die Server-Vorrichtung 10 eine Vielzahl von Arten von Parametervariablen und nutzt diese zur Engpasssteuerung. Unter diesen Variablen repräsentiert snd_nxt eine Sequenznummer eines nächsten zu übertragen Datensegmentes; und der Wert snd_nxt bezeichnet die Sequenznummer eines Datensegmentes, die zu dem wieder übertragenen Datensegmentes nachfolgend ist. Deshalb kann der Wert von snd_nxt als eine erwartete Bestätigungsnummer bei der Ausführung der Entscheidung anstelle der Aufzeichnung der erwarteten Bestätigungsnummer im RAM 102 genutzt werden.
  • In dem Fall, in dem der Wert der Bestätigungsnummer zum Vergleich größer als die erwartete Bestätigungsnummer ist, wird festgestellt, dass die Bestätigung zu dem Originaldatensegment gehört. Das heißt, die CPU 100 stellt fest, dass das Originaldatensegment von der Client-Vorrichtung 50 empfangen wurde und überträgt ein nachfolgendes Originaldatensegment.
  • In dem Fall, in dem der Wert der Bestätigungsnummer zum Vergleich der gleiche ist, wie der der erwarteten Bestätigungsnummer, kann die Entscheidung nicht vorgenommen werden, ob die Bestätigung zu dem Originaldatensegment oder zu dem wieder übertragenen Datensegment gehört. Deshalb nimmt die CPU 100 an, dass die Bestätigung zu dem wieder übertragenen Datensegment gehört, und stellt dann fest, ob es ein Datensegment zu Wiederübertragung gibt, das nachfolgend zu dem wieder übertragenen Datensegment ist. In dem Fall, in dem es ein solches Segment gibt, wird das nachfolgende Datensegment zur Wiederübertragung übertragen; und wenn es ein solches Segment nicht gibt, wird ein nachfolgendes Originaldatensegment übertragen.
  • Konfiguration der Client-Vorrichtung 50:
  • Die Client-Vorrichtung 50 hat eine Konfiguration eines üblicherweise genutzten Computers, und deshalb wird die Beschreibung nur für Funktionen der Vorrichtung 50 angegeben, die sich spezifisch auf das vorliegende, bevorzugte Ausführungsbeispiel beziehen.
  • Beim Empfang eines Datensegmentes von einer Server-Vorrichtung 10, überträgt die Client-Vorrichtung 50 zur Server-Vorrichtung 10, eine Bestätigung, welche darüber informiert, dass das Datensegment empfangen wurde. Insbesondere wird eine Sequenznummer, die auf eine nachfolgende Position nach dem Datensegment hinweist, als Bestätigungsnummer gesetzt, die in der Bestätigung zu Übertragung zu der Server-Vorrichtung 10 enthalten ist.
  • Es wird hier angenommen, dass sich die drahtlose Kommunikationsumgebung zwischen dem Kommunikationsendgerät 40 und dem Mobilkommunikationsnetzwerk 30 verschlechtert, während die Client-Vorrichtung 50 eine Paketkommunikation mit der Server-Vorrichtung 50 ausführt. In solch einem Fall empfängt die Client-Vorrichtung 50 nacheinander die Datensegmente mit einer Verzögerung, die von der Server-Vorrichtung 10 übertragen werden. In dem Fall, in dem in einem Intervall, beginnend mit dem Empfang eines erster Datensegment bis zu dem Zeitpunkt, an dem ein zweites Datensegment empfangen wird, kleiner als eine vorher bestimmte Zeitperiode ist, wird nur eine Bestätigung für das zweite Datensegment übertragen, wodurch die Server-Vorrichtung darüber informiert wird, dass zwei Datensegmente empfangen wurden. Insbesondere wird eine Sequenznummer als die Bestätigungsnummer der Bestätigung zur Übertragung zur Server-Vorrichtung 10 gesetzt, die eine nachfolgende Position bezeichnet, die nachfolgend zu dem zweiten Datensegment ist.
  • 2. Betrieb
  • Als nächstes wird der Betrieb des vorliegenden, bevorzugten Ausführungsbeispiels beschrieben.
  • 4 ist ein Sequenzdiagramm, das einen Beispielfall beschreibt, bei dem eine Paketkommunikation zwischen einer Server-Vorrichtung 10 und einer Client-Vorrichtung 50 ausgeführt wird. 5 ist ein Flussdiagramm, das den Betrieb einer Übertragung und eines Empfangs von Datensegmenten bei der Server-Vorrichtung 10 entsprechend dem vorliegenden Ausführungsbeispiel darstellt. Es wird angenommen, dass in den vorliegenden Ausführungsbeispiel das Gleitfensterverfahren zu Übertragung von Datensegmenten genutzt wird. Bei dem zweiten Ausführungsbeispiel wird die anfängliche Fenstergröße auf drei gesetzt, und der Empfang der Datensegmente, die durch die Client-Vorrichtung 50 empfangen werden, ist vergleichsweise groß im Verhältnis zur Fenstergröße, die durch die Server-Vorrichtung 10 gesetzt wird. Aus Vereinfachungsgründen wird angenommen, dass die Fenstergröße auf drei fixiert ist, und dass die Fenstergröße zum Zwecke einer Engpasssteuerung nicht erhöht wird. Im Falle eines Timeout speichert die Server-Vorrichtung 10 eine Fenstergröße, wie sie entsprechend direkt vor dem Wiederübertragungs-Timeout festgestellt wird.
  • In 4 werden Datensegmente, die Sequenznummern von 0, 1000 und 2000 (Originaldatensegmente S1, S2 und S3) haben, von der Server-Vorrichtung 10 zur Client-Vorrichtung 50 übertragen.
  • Bei dem in der Zeichnung dargestellten Beispiel ist eine drahtlose Kommunikationsumgebung zwischen einem Kommunikationsendgerät 40 und einem Mobilpaketkommunikationsnetzwerk 30 zusammengebrochen, und die Übertragung der Originaldatensegmente S1, S2 und S3 wurde ausgesetzt. Wenn die Mobilkommunikationsumgebung wieder besser ist, und die Kommunikation wieder aufgenommen wird, werden die Datensegmente S1, S2 und S3, die sich in dem Netzwerk 30 befanden, erneut zur Client-Vorrichtung 50 übertragen.
  • Auf der anderen Seite empfängt die Client-Vorrichtung 50 nacheinander Originaldatensegmente S1, S2 und S3 mit einer Verzögerung. In diesem Beispiel ist ein Intervall beginnend mit dem Zeitpunkt zu dem Originaldatensegmente empfangen werden, bis zu einem Zeitpunkt an dem Originaldatensegment S2 empfangen wird, kleiner als eine vorher bestimmte Zeit, und eine Bestätigung mit einer Bestätigungsnummer 2000 wird als eine Bestätigung für das Originaldatensegment S1 und S2 an die Server-Vorrichtung 10 übertragen.
  • In dem nun Folgenden wird eine Beschreibung des von der Server-Vorrichtung 10 ausgeführten Betriebes unter Zuhilfenahme von 5 beschrieben. In Schritt S300 überträgt die CPU 100 die Originaldatensegmente S1, S2 und S3 und wartet dann auf eine Bestätigung, die von der Client-Vorrichtung 50 in Antwort auf den Empfang auf das Originaldatensegment S1 übermittelt wird. Beim Warten auf die Bestätigung, setzt die CPU 100 einen Timeout-Wert beim Timer 100a, um den Timer zu veranlassen, eine aufgelaufene Zeit (Schritt S301) zu messen.
  • Die CPU 100 entscheidet dann, ob irgendeine Bestätigung empfangen wurde (Schritt S302). Wenn im Schritt S302 "Nein" entschieden wurde, entscheidet die CPU 100, ob ein Timeout beim Timer 100a entstanden ist (Schritt S303). In dem Fall, bei dem "Nein" in Schritt S303 entschieden, wurde, kehrt die Routine zu Schritt S302 zurück. Die Entscheidungen der Schritte S302 and S303 werden solange durch die CPU 100 wiederholt bis ein Timeout auftritt und keine Bestätigung empfangen wurde.
  • Es wird hier weiter angenommen, dass die aufgelaufene Zeit einen Timeout-Wert erreicht, bevor die Bestätigung R2 empfangen wurde, weil die Ankunft der Datensegmente S1 bis S3 verzögert ist. In diesem Fall wird ein Triggersignal von dem Timer 100a nach einer aufgelaufenen Zeit, die von dem Timer 100a gemessen wird, ausgegeben, ohne dass eine Bestätigung empfangen wurde (Schritt S302; Nein, Schritt S303; Ja). Die CPU 100 setzt dann den Timer 100a zurück und fährt mit Schritt S304 fort.
  • Im Schritt S304 entscheidet die CPU 100, dass das Originaldatensegment S1 nicht durch die Client-Vorrichtung 50 empfangen wurde und überträgt ein Datensegment, das eine Sequenznummer 0 hat (das wieder übertragene Datensegment S'1 in 4) an die Client-Vorrichtung 50. Die Fenstergröße wird auf einen Minimalwert bedingt durch den Timeout reduziert, und nur ein Datensegment wird hier wieder übertragenen. Die CPU 100 setzt weiterhin einen Timeout-Wert im Timer 100a, um ihn zur Messung einer aufgelaufenen Zeit zu veranlassen.
  • Die CPU 100 entscheidet dann, ob eine Bestätigung empfangen wurde (Schritt S305), und in dem Fall, dass im Schritt S305 "Nein" entschieden wird, entscheidet die CPU 100 dann, ob ein Timeout beim Timer 100a aufgetreten ist (Schritt S306). Wenn die Entscheidung im Schritt S306 "Nein" ist, kehrt die Routine zu Schritt S305 zurück. Danach werden die Entscheidungen der Schritte S305 und S306 von der CPU 100 solange wiederholt bis ein Timeout auftritt und keine Bestätigung empfangen wird. Es wird angenommen, dass die CPU 100 nachfolgend die Bestätigung R2 empfängt, bevor er Timeout-Wert erreicht wird, das heißt bevor ein Triggersignal von dem Timer 100a ausgegeben wird, wo im Schritt S305 „ja" entschieden wird, und die Routine bei Schritt S307 fort fährt.
  • In Schritt S307 setzt die CPU 100 den Timer 100a zurück. Die CPU 100 vergleicht die Bestätigungsnummer 2000, die in der Bestätigung R2 (die Bestätigungsnummer für den Vergleich) enthalten ist mit der erwarteten Bestätigungsnummer 1000, die als in einer Bestätigung enthaltend in Reaktion auf den Empfang des übermittelten Datensegmente, das in Schritt S4 übertragen wurde, erwarten wird; die erwartete Bestätigungsnummer wurde im RAM 102 zum Zeitpunkt der Wiederübertragung gespeichert. Weil in dem Beispiel die Bestätigungsnummer zum Vergleich größer als die erwartete Bestätigungsnummer ist, entscheidet die CPU 100, dass die Bestätigung R2 zu dem Originaldatensegmenten S1 und S2 gehört. Mit anderen Worten entscheidet die CPU 100, dass die Originaldatensegmente S1 und S2 ohne verloren gegangen zu sein durch die Client-Vorrichtung 50 empfangen wurden. Im Ergebnis wird die Fenstergröße auf "drei" wie vor dem Timeout unter Zuhilfenahme der in dem RAM 102 gespeicherten Informationen zurückgesetzt. Folglich können jetzt zwei Datensegmente nachfolgend zum übertragenen Datensegment S3 übertragen werden.
  • Im Schritt S309 überträgt die CPU 100 der Server-Vorrichtung 10 die Originaldatensegmente S4 und S5, die dem Originaldatensegment S3 folgen. In 4 wird ein zum Schritt S309 korrespondierender Prozess dargestellt, bei dem die Server-Vorrichtung 10 die Originaldatensegmente S4 und S5 an die Client-Vorrichtung 50 überträgt. Die Routine und kehrt dann zum Schritt S301 zurück, und der Timer 100a beginnt die Messung der aufgelaufenen Zeit.
  • Nachfolgend wiederholt die CPU 100 die Entscheidung von Schritt S302 und S303 bevor ein Timeout auftritt solange keine Bestätigung empfangen wird.
  • Während die Server-Vorrichtung 10 den oben erwähnten Ablauf ausführt, wird das Originaldatensegment S3 von der Client-Vorrichtung 50 empfangen. Dann wird eine Bestätigung R3 mit einer Bestätigungsnummer 3000 an die Server-Vorrichtung 10 in Reaktion auf das Originaldatensegment S3 übertragen.
  • Wenn in 5 die Bestätigung R3 mit einer Bestätigungsnummer 3000 die Server-Vorrichtung 10 reicht, wird von der CPU 100 der Server-Vorrichtung 10 im Schritt S302 „Ja" festgestellt. Im Ergebnis gleitet das Fenster ein Datensegment weiter, und die Server-Vorrichtung 10 kann nun ein Datensegment übertragen, dass nachfolgend zu dem letzten Datensegment S5 von den vorher übertragenen Datensegmenten ist. Im Schritt S300 überträgt die CPU 100 ein Originaldatensegment S6 mit einer nachfolgenden Sequenznummer 5000.
  • In 4 überträgt die Server-Vorrichtung 10 in einem in einem zum Schritt S302 korrespondierenden Prozess das Originaldatensegment S6 zur Client-Vorrichtung 50.
  • Das vorangegangene ist eine Erklärung wie Datensegmente von der Server-Vorrichtung 10 zur Client-Vorrichtung 50 übertragen werden.
  • B. Zweites Ausführungsbeispiel
  • Als Nächstes wird eine Beschreibung für ein anderes Beispiel für die Durchführung einer Paketkommunikation zwischen einer Server-Vorrichtung 10 und einer Client-Vorrichtung 50 angegeben. Dabei wird auf Beschreibungen der gleichen Komponenten wie im ersten Ausführungsbeispiel verzichtet. Außerdem werden ähnliche Komponenten durch gleiche zugewiesene Bezugsziffern beschrieben.
  • 1. Konfiguration
  • Konfiguration der Server-Vorrichtung 10:
  • Es wird nur eine Beschreibung von derjenigen Konfigurationen angegeben, die zum vorliegenden Ausführungsbeispiel gehören.
  • Bei der Übertragung von Datensegmenten zur Client-Vorrichtung 50 in dem vorliegenden Ausführungsbeispiel führt die CPU 100 eine Engpasssteuerung zusätzlich zur Nutzung des Gleitfensterverfahren, wie es in Bezug auf das erste Ausführungsbeispiel beschrieben ist, aus, um den Datenfluss von Datensegmenten zu steuern. Insbesondere erhöht oder verkleinert die CPU 100 eine Fenstergröße, das heißt eine Anzahl von Datensegmenten, die ohne Bestätigung übertragen werden können. Eine Veränderung der Fenstergröße wird jedes Mal initiiert, wenn eine Übertragung eines Datensegmentes bestätigt wird. Es sei auch darauf hingewiesen, dass ROM 103 im Voraus Informationen zur Steuerung von Engpassfenstern speichert.
  • In der folgenden Beschreibung wird die Engpassfenstersteuerung ausführlicher beschrieben. Entsprechend dem vorliegenden Ausführungsbeispiel speichert die Server-Vorrichtung 10 in HD 104 mindestens fünf Parametervariablen snd_max, snd_nxt, snd_una, snd_wnd und snd_cwnd. Einen Engpasssteuerung wird durch eine Übertragung einer Anzahl von Datensegmenten, die auf der Basis derjenigen Parametervariablen identifiziert werden, ausgeführt. 6 ist ein Diagramm, das die Abhängigkeiten dieser fünf Parametervariablen beschreibt. snd_max stellt eine Sequenznummer (Sequenznummer 5000 6) eines zu übertragenden Originaldatensegmentes dar; snd_nxt stellt eine nächste Sequenznummer (Sequenznummer 5000 in 6) eines Datensegmentes dar, das von der Server-Vorrichtung 10 übertragen oder wieder übertragen wird; snd_una stellt eine zuletzt unbestätigte Sequenznummer (Sequenznummer 2000 und 6) aus den Datensegmenten dar, die bereits übertragen wurden.
  • snd_cwnd stellt eine Anzahl von Datensegmenten dar, die von der Server-Vorrichtung 10 übertragen werden können, ohne dass eine Bestätigung für vorher übertragene Datensegmente empfangen wird. Ein Datensegment wird in einer Einheit repräsentiert, die Maximalsegmentgröße (die als "MSS" bezeichnet wird) genannt wird, wobei die Default-Größe von 1 MSS aus 1460 Bytes gebildet wird; und snd_cwnd hat beispielsweise 3 MSS als Startwert. Die CPU 100 der Server-Vorrichtung 10 erhöht den Wert von snd_cwnd unter Nutzung eines "Langsamstart"-Algorithmus, wobei eine Anzahl von zu übertragenden Datensegmenten exponentiell erhöht wird bis der Wert eines vorher bestimmten Schwellenwertes (z.B. 65535 Bytes) immer dann erreicht wird, wenn eine Bestätigung für übertragenes Datensegment empfangen wird; cnd_cwnd ist ein Wert, der von der Server Vorrichtung 10 gesteuert wird und repräsentiert eine "Engpassfenstergröße".
  • Im Gegensatz dazu repräsentiert snd_wnd eine ausgewiesene Fenstergröße, auf die von der Client-Vorrichtung 50 hingewiesen wird; und der Wert der ausgewiesenen Größe weist auf einen verfügbaren Empfangsraumpuffer der Client-Vorrichtung 50 hin und wird in Bytes ausgedrückt.
  • Die CPU 100 der Server-Vorrichtung 10 stellt ein Minimum der ausgewiesenen Fenstergröße (snd_wnd) und der Engpassfenstergröße (snd_cwnd) als Fenstergröße für die Übertragung auf der Basis, auf der die Festlegung des Fensters ausgeführt wird, fest. Folglich übersteigt eine Übertragungsfenstergröße nie eine ausgewiesene Fenstergröße, und einer Anzahl von Datensegmenten, die zur Client-Vorrichtung 50 übertragen wird, übersteigt nie einen verfügbaren Pufferraum der Client-Vorrichtung 50. In dem vorliegenden Ausführungsbeispiel wird angenommen, dass die ausgewiesene Fenstergröße eine ausreichend große Größe aufweist, die größer ist als eine Engpassfenstergröße; und aus Gründen der Erklärung wird eine Übertragungsfenstergröße als "Engpassfenstergröße" bezeichnet.
  • Wenn bei der vorliegenden Erfindung ein Wiederübertragungs-Timeout erkannt wird, setzt die CPU 100 der Server-Vorrichtung 10 zunächst den Wert von snd_cwnd auf 1 MSS und speichert im RAM 102 den Wert von snd_cwnd, der direkt vor dem Löschen des Wiederübertragungs-Timeout auftritt. Die CPU 100 ersetzt den Wert von snd_nxt durch denjenigen von snd_una und überträgt dann ein Datensegment, auf das durch snd_nxt Bezug genommen wird. Jedes Mal wenn eine Bestätigung für ein wieder übertragenes Datensegment empfangen wird, wird der Wert, der in snd_cwnd gesetzt ist, um eine MSS entsprechend dem oben beschriebenen Langsamstartalgorithmus erhöht.
  • Bei dem vorliegenden Ausführungsbeispiel wird der Entscheidungsvorgang (Schritt S307 von 5; Schritt S307 von 8 des zweiten Ausführungsbeispiels), der bei dem ersten Ausführungsbeispiel beschrieben ist, ausgeführt, wenn eine Bestätigung nachfolgend zu einer Datensegmentwiederübertragung empfangen wird. Im Ergebnis wird in dem Fall, bei dem eine empfangene Bestätigung zu einem Originaldatensegment korrespondiert, die Engpassfenstergröße auf den Wert zurückgesetzt, der direkt vor der Wiederübertragung vorlag. Insbesondere wird der Wert der Engpassfenstergröße mit dem Wert von snd_cwnd aktualisiert, der zum Zeitpunkt der Erkennung eines Wiederübertragungs-Timeout in dem RAM 102 gespeichert war. Zu diesem Zeitpunkt ersetzt die CPU 100 den Wert von snd_nxt durch den Wert von snd_max, und die Datenübertragung wird mit einem Datensegment gestartet, auf das durch snd_nxt Bezug genommenen wird.
  • In dem vorliegenden Ausführungsbeispiel führt die CPU 100 die beschriebene Engpasssteuerung durch, bei der ein Fluss von Daten wie vor dem Timeout schnell wiederhergestellt werden kann.
  • 2. Betrieb
  • 7 ist eine Sequenzdarstellung, die ein anderes Beispiel der Ausführung einer Paketkommunikation zwischen einer Server-Vorrichtung 10 und einer Client-Vorrichtung 50 darstellt. 8 ist ein Flussdiagramm, welches Übertragungs- und Empfangsoperationen von Datensegmenten durch die Server-Vorrichtung 10 entsprechend dem vorliegenden Ausführungsbeispiel darstellt. 9A und 9C sind schematische Diagramme, die Änderungen in der Engpassfenstergröße darstellen. Es sei darauf hingewiesen, dass gleiche Bezugszeichen die gleichen Schritte wie im ersten Ausführungsbeispiel bezeichnen, und auf eine zugehörige Beschreibung wird verzichtet.
  • In 7 werden Datensegmente mit Sequenznummern 0, 1000, 2000, 3000 und 4000 (Originaldatensegmente S11, S12, S13, S14, S15) von der Server-Vorrichtung 10 zur Client-Vorrichtung 50 übertragen. Die benutzte Engpassfenstergröße snd_cwnd ist hier 5 MSS. Wie in 9A dargestellt, wird die allerletzte und bestätigte Sequenznummer 0 (S11) als Wert von snd_una gesetzt. Die nächste zu übertragende Originalsequenznummer 5000 wird als snd_max gesetzt; und die Sequenznummer 5000 eines nächsten zu übertragenden Datensegmentes (S16) wird als snd_nxt gesetzt.
  • In dem in den Figuren dargestellten Beispiel verschlechtert sich die drahtlose Kommunikation zwischen dem Endgerät 40 und dem Mobilpaketkommunikationsnetzwerk 30 als Ergebnis einer unterbrochenen Übertragung von Originaldatensegmenten S12 bis S15. Wenn sich die drahtlosen Bedingungen verbessern und die Kommunikation wieder hergestellt ist, werden die Originaldatensegmente S11 bis S15 nacheinander zur Client-Vorrichtung 50 übertragen. Die Client-Vorrichtung 50 empfängt dann nacheinander die Originaldatensegmente S11 bis S15 mit einer signifikanten Verzögerung.
  • Während des Empfangs des Originaldatensegmentes S11 überträgt die Client-Vorrichtung 50 eine Bestätigung R11 mit einer Bestätigungsnummer 1000 als Antwort auf den Empfang des Originaldatensegmentes S11.
  • Es wird weiterhin angenommen, dass bedingt durch den verzögerten Empfang der Datensegmente S11 bis S15 ein Timeout bei der Server-Vorrichtung 10 vor dem Empfang der Bestätigung R11 auftritt. Das bedeutet, dass die CPU 100 keine Bestätigung empfangen hat auch wenn ein Triggersignal von dem Timer 100a nach einem Timeout-Wert nach Schritt S301 überschritten wurde (Schritt S302; Nein, Schritt S303; Ja). Wie in 9 dargestellt, aktualisiert beim Auftreten des Timeout die Server-Vorrichtung 10 die Engpassfenstergröße mit 1 MSS und ersetzt den Wert von snd_nxt durch den Wert von snd_una.
  • Als nächstes bestimmt die CPU 100 im Schritt S'304, das das Originaldatensegment S11 nicht durch die Client-Vorrichtung 50 empfangen wurde. Die CPU 100 überträgt dann ein Datensegment zur Client-Vorrichtung 50 erneut (ein wieder übertragenes Datensegment S'11 in 7); dabei hat das Datensegment die Sequenznummer 0, die durch den Wert von snd_nxt zugewiesenen wird. Die CPU 100 setzt auch einen Timeout-Wert beim Timer 100a zurück, um zu bewirken, dass der Timer 100a einen Timeout-Wert misst.
  • Nachfolgend empfängt die CPU 100 der Server-Vorrichtung 10 die Bestätigung R11 bevor ein Triggersignal von dem Timer 100a vor dem Ablauf der Timerzeit ausgegeben wird, und die Routine fährt dann beim Schritt S307 fort.
  • In Schritt S300 überträgt die CPU 100 der Server-Vorrichtung 10 die fünf Originaldatensegmente S11–S15 mit der Engpassfenstergröße von 5 MSS. Die CPU 100 führt dann die Vorgänge S301 bis S303 aus, und die Routine geht dann zu Schritt S'304. Im Schritt S'304 ändert die CPU 100 die Engpassfenstergröße zur Engpasssteuerung auf 1 MSS und überträgt die Datensegmente mit der Sequenznummer 0 (wieder übertragenes Datensegment S'11) erneut. Nachfolgend empfängt die Server-Vorrichtung 10 die Bestätigung R11 (Schritt S305; Ja), und der Vorgang des Schrittes S307 wird ausgeführt.
  • In Schritt S307 vergleicht die CPU 100 die Bestätigungsnummer 1000 (Bestätigungsnummer zum Vergleich), die in der Bestätigung R11 enthalten ist, mit der erwarteten Bestätigungsnummern (1000) für das wieder übertragene Datensegment, das in Schritt S307 wider übertragen wurde. Der Wert der erwarteten Bestätigungsnummer kann durch Bezugnahme auf den Wert snd_nxt erhalten werden; und alternativ kann auf die in RAM 102 gespeicherte Information zurückgegriffen werden, wie es im ersten Ausführungsbeispiel der Fall ist. In diesem Fall sind die Bestätigungsnummer zum Vergleich und die erwartete Bestätigungsnummer identisch; und es ist nicht möglich zu entscheiden, ob die Bestätigung R11 zu dem Originaldatensegment S11 oder zu dem wieder übertragenen Segment gehört. Deshalb nimmt die CPU 100 an, dass die Bestätigung R11 zu dem wieder übertragenen Datensegment S'11 gehört. Das heißt, dass festgestellt wird, dass das Originaldatensegment S11 nicht durch die Client-Vorrichtung 50 bedingt durch einen Verlust an Datensegmenten empfangen wurde, und die Routine fährt bei Schritt S308 fort.
  • In Schritt S308 wird festgestellt, ob irgendein Datensegment zur Wiederübertragung nach dem wieder übertragenen Datensegment S'11 existiert. Der Wert von snd_nxt zu diesem Zeitpunkt ist die Sequenznummer 1000 eines übertragenen Datensegmentes S12 (siehe 9a). Deshalb wird entschieden, dass ein Datensegment zur Wiederübertragung nicht existiert, und die Routine fährt dann bei Schritt S'304 fort. In Schritt S'304 wird die Engpassfenstergröße auf 2 MSS erhöht, weil die Bestätigung R11 empfangen wurde, wobei die Engpasssteuerung ausgeführt wird. Zwei Datensegmente mit aufeinander folgenden Sequenznummern 1000 und 2000 (S'12 und S'13) werden dann übertragen. Die CPU 100 setzt zur gleichen Zeit den Timer 100a.
  • In 7 werden die Datensegmente S'12 und S'13 von der Server-Vorrichtung 10 übertragen.
  • Auf der anderen Seite überträgt die Client-Vorrichtung 50 in Reaktion of die Originaldatensegmente S12, S13 und S14 Bestätigungen mit den Bestätigungsnummern 2000, 3000 und 4000. Es wird hier angenommen, dass die Bestätigungen R12 und R13 nicht bedingt durch Verschlechterungen bei der drahtlosen Kommunikation während der Übertragung verloren gingen. Im Ergebnis wird die Bestätigung R14 an die Server-Vorrichtung 10 übertragen.
  • In 8 empfängt die CPU 100 die Bestätigung R14 (Schritt S305; Ja) bevor eine von dem Timer 100a gemessene, aufgelaufene Zeit einen Timeout-Wert überschreitet. Die Routine fährt dann bei Schritt S307 fort.
  • In Schritt S307 vergleicht die CPU 100 die Bestätigungsnummer 4000 (Bestätigungsnummer zum Vergleich), die in der Bestätigung enthalten ist, mit einer erwarteten Bestätigungsnummern für ein wieder übertragenes Datensegment S'13 (3000). Weil die Bestätigungsnummer zum Vergleich größer ist als die erwartete Bestätigungsnummer, wird entschieden, dass das Originaldatensegment S11 bis S14 sicher von der Client-Vorrichtung 50 ohne Verlust empfangen wurden. Die Routine fährt dann bei Schritt S'309 fort.
  • In Schritt S'309 nimmt die CPU 100 auf die in RAM 102 gespeicherte Information und setzt die Engpassfenstergröße, die direkt vor dem Wiederübertragungs-Timeout existierte, zurück. Insbesondere wird die Engpassfenstergröße auf 5 MSS, die in RAM 102 gespeichert ist, zurückgesetzt, und wird weiterhin um 1 MSS als Ergebnis des Empfangs der Bestätigung R14 erhöht; dadurch werden insgesamt 6 MSS erreicht. Wie in 9B dargestellt, wird der Wert von snd_nxt durch den Wert von snd_max ersetzt. Weil das Originaldatensegment S15 nicht bestätigt wurde, wird weiterhin der Wert von snd_una auf 4000 geändert, der die Sequenznummer des Originaldatensegmentes S15 ist. Annehmend, dass das Engpassfenster ausgehend von dem Wert von snd_una 6 MSS ist, werden 5 Originaldatensegmente S16 bis S20, die noch nicht übertragen wurden und die unter dem Engpassfenster sind, nacheinander übertragen.
  • In 8 werden die Originaldatensegmente S16, S17, S18, S19 und S20 mit den Sequenznummern 5000, 6000, 7000, 8000, und 9000 von der Server-Vorrichtung 10 zur Client-Vorrichtung 50 übertragen.
  • Während der Übertragung dieser Originaldatensegmente empfängt die CPU eine Bestätigung R15. Die CPU 100 stellt dann fest, dass das Originaldatensegment S15 nicht durch die Client-Vorrichtung 50 empfangen wurde und verändert den Wert von snd_una auf die Sequenznummer 5000 entsprechend dem Originaldatensegment S16. Die Engpassfenstergröße wird um 1 MSS erhöht, womit sich 7 MSS ergeben (siehe 9C). Folglich können nachfolgende Originaldatensegmente S21 und S22 übertragen werden, und diese Datensegmente werden von der Server-Vorrichtung 10 zur Client-Vorrichtung 50 übertragen.
  • Die oben beschriebene Konfiguration stellt unnötige Wiederübertragungen von Datensegmenten und auch sonstige unnötige Reduzierungen in einer Übertragungsrate von Datensegmenten dar. Weil eine Übertragungsrate, die auf einen wert zurückgesetzt wird, der von einem Wert abgeleitet wird, der direkt vor einem Wiederübertragungs-Timeout existierte, kann eine durch unnötige Wiederübertragungen bedingte reduzierte Übertragungsrate schnell korrigiert werden.
  • C. Abwandlungen
  • In dem Vorangegangenen wurde ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung beschrieben. Die vorliegende Erfindung kann in verschiedenen anderen Ausführungsbeispielen ausgeführt werden, ohne von den Hauptmerkmalen der Erfindung abzuweichen. Folgende Beispiele sind Abwandlungen.
  • In den obigen bevorzugten Ausführungsbeispielen wird eine Paketkommunikation nach TCP ausgeführt. Die vorliegende Erfindung kann auch mit anderen Kommunikationsprotokollen als TCP für eine Paketkommunikation ausgeführt werden, wenn eine Wiederübertragungssteuerung eines Datenblockes oder Datensegmentes ausgeführt wird. In diesem Fall können Datensegmente durch Nutzung eines Fensters aus, dass ähnlich zu dem Fenster eines Gleitfensterverfahrens, welches bei TCP genutzt wird, ausgeführt wird.
  • Eine separate Server-Vorrichtung kann die Funktion zur Entscheidung, die von der Server-Vorrichtung 10 ausgeführt wird, um festzustellen, welches Datensegment zu einer empfangenen Bestätigung gehört, enthalten. In diesem Fall wird die Server-Vorrichtung 10 nach dem Empfang einer Bestätigung nach einer Übertragung eines Datensegmentes zur Wiederübertragung eine separate Server-Vorrichtung abfragen, ob eine Bestätigung zu einem Originaldatensegment oder zu einem wieder übertragenen Datensegment gehört. Die separate Server-Vorrichtung führt die Feststellung aus und überträgt ein Ergebnis der Feststellung an die Server-Vorrichtung 10. Die Server-Vorrichtung 10 ist dann in der Lage, auf der Basis des übertragenen Ergebnisses der Feststellung festzustellen, welches Datensegment zu der Bestätigung gehört.
  • In dem obigen Ausführungsbeispiel führt die Client-Vorrichtung 50 eine Paketkommunikation mit der Server-Vorrichtung 10 durch das Kommunikationsendgerät 40 aus. Die Client-Vorrichtung 50 kann eine drahtlose Kommunikationsfunktion umfassen, und sie kann eine Paketkommunikation mit der Server-Vorrichtung 10 durch das Mobilpaketkommunikationsnetzwerk 30, das Internet 20 und nicht durch das Kommunikationsendgerät 40 ausführen.

Claims (6)

  1. Übertragungssteuerungsverfahren zur Nutzung in einem Kommunikationsnetzwerk mit: a) Zuweisen von Sequenzinformationen zu jeden Datenblock, der sequentiell von einer Sendevorrichtung (10) an eine Empfangsvorrichtung (40, 50) übertragen werden soll; b) Übertragung einer Mehrzahl von ursprünglichen Datenblöcken an die Empfangsvorrichtung (40, 50) nachdem die Sequenzinformationen jedem aus der Mehrzahl von ursprünglichen Datenblöcken zugewiesen wurden; c) erneute Übertragung eines Datenblockes aus der Mehrzahl der ursprünglichen Datenblöcke für den kein Bestätigungssignal empfangen wurde, gekennzeichnet durch d) Speichern einer Sequenznummer in einem Speichermittel (102) der Sendevorrichtung, die nachfolgend zu einer Sequenznummer des erneut übertragenen Datensegmentes als eine erwartete Bestätigungsnummer ist; e) Empfangen eines Bestätigungssignals, das Sequenzinformationen als eine Bestätigungsnummer zum Vergleich mit der erwarteten Bestätigungsnummer enthält; und f) Feststellen, dass das Bestätigungssignal einen aus der Mehrzahl der ursprünglichen Datenblöcke bestätigt, wenn ein Wert der Bestätigungsnummer zum Vergleich größer ist als die erwartete Bestätigungsnummer und Annehmen, dass das Bestätigungssignal zum erneut gesendeten Datenblock gehört, wenn der Wert der Bestätigungsnummer zum Vergleich der gleiche ist wie der der erwarteten Bestätigungsnummer; g) wobei der Übertragungsschritt eine Übertragung eines ursprünglichen Datenblockes nach der Mehrzahl der gesendeten Datenblöcke enthält, wenn festgestellt wird, dass das Bestätigungssignal den Empfang eines aus der Mehrzahl der Datenblöcke bestätigt.
  2. Übertragungssteuerungsverfahren nach Anspruch 1, wobei die Anzahl der Mehrzahl der ursprünglichen Datenblöcke, die in dem Übertragungsschritt übertragen wurden, entsprechend einer Fenstergröße festgestellt wird, die eine Anzahl von Datenblöcken definiert, die ohne den Empfang einer Bestätigung übertragen worden sein kann; wobei der erneute Übertragungsschritt das Ändern der Fenstergröße auf eine minimale Größe enthält, wenn der Datenblock erneut übertragen wird, der nicht innerhalb einer vorhergesagten Zeit bestätigt wurde, und erneute Übertragung einer Anzahl von Datenblöcken entsprechend der geänderten Fenstergröße; und wobei der Speicherschritt ein Speichern eines Wertes der Fenstergröße in der Speichervorrichtung (102) enthält bevor die Fenstergröße auf die minimale Größe geändert wurde; und wobei der Übertragungsschritt eine Erhöhung der Fenstergröße enthält, wenn festgestellt wird, dass das Bestätigungssignal den Empfang eines aus der Mehrzahl der ursprünglich Datenblöcke bestätigt, so dass die Fenstergröße gleich oder größer dem gespeicherten Wert ist, und Übertragung einer Anzahl von Datenblöcken, die entsprechend der erhöhten Fenstergröße festgelegt wurde.
  3. Kommunikationsvorrichtung (10) mit: Zuweisungsmitteln (100), die angepasst sind, um Sequenzinformationen jeden Datenblock, der sequentiell an die Empfangsvorrichtung (50) übertragen werden soll, zuzuweisen; Übertragungsmitteln, die angepasst sind, um eine Mehrzahl von ursprünglichen Datenblöcken an die Empfangsvorrichtung zu übertragen nachdem die Sequenznummer jedem aus der Mehrzahl der Datenblöcke zugewiesen wurde; Mitteln zur erneuten Übertragung (101), die angepasst sind, um einen Datenblock aus der Mehrzahl der ursprünglichen Datenblöcke erneut zu übertragen, für den ein Bestätigungssignal nicht empfangen wurde; gekennzeichnet durch Speichermittel (102), die angepasst sind, um eine Sequenznummer zu speichern, die nachfolgend zur Nummer des erneut übertragenen Datensegmentes als erwartete Bestätigungsnummer ist; Empfangsmittel (101), die angepasst sind, ein Bestätigungssignal zu empfangen, das eine Sequenznummer als eine Bestätigungsnummer zum Vergleich mit der erwarteten Bestätigungsnummer enthält; und Feststellungsmittel (100), die angepasst sind, um festzustellen, dass das Bestätigungssignal den Empfang eines aus der Mehrzahl vor ursprünglichen Datenblöcken bestätigt, wenn ein Wert der Bestätigungsnummer zum Vergleich größer als die erwartete Bestätigungsnummer ist, und um anzunehmen, dass das Bestätigungssignal zu dem erneut gesendeten Datenblock gehört, wenn der Wert der Bestätigungsnummer zum Vergleich der gleiche ist wie der der erwarteten Bestätigungsnummer, wobei die Übertragungsmittel (101) angepasst sind, um einen ursprünglichen Datenblock nach der übertragenen Mehrzahl von ursprünglichen Datenblöcken zu übertragen, wenn festgestellt wird, dass das Bestätigungssignal einen Empfang eines aus einer Mehrzahl von ursprünglichen Datenblöcken bestätigt.
  4. Kommunikationsvorrichtung entsprechend Anspruch 3, wobei eine Anzahl der Mehrzahl von ursprünglichen Datenblöcken, die durch die Übertragungsmittel (101) übertragen wurden, entsprechend einer Fenstergröße festgestellt wird, die eine Anzahl von Datenblöcken definiert, die ohne den Empfang einer Bestätigung übertragen worden sein kann; wobei die Mittel zu erneuten Übertragung (101) angepasst sind, um die Fenstergröße zu einer minimalen Größe zu ändern, wenn eine erneute Übertragung eines Datenblockes nicht innerhalb einer vorhergesagten Zeit bestätigt wird, und um eine Anzahl von Datenblöcken entsprechend der geänderten Fenstergröße erneut zu übertragen; wobei die Speichermittel (102) angepasst sind, um einen Wert der Fenstergröße zu speichern, bevor die Fenstergröße auf die minimale Größe geändert wurde; und wobei die Übertragungsmittel (101) angepasst sind, um die Fenstergröße zu erhöhen, wenn festgestellt wird, dass das Bestätigungssignal den Empfang eines aus der Mehrzahl der ursprünglichen Datenblöcke bestätigt, so dass die Fenstergröße gleich oder größer als der gespeicherte Wert ist, und um eine Anzahl von ursprünglichen Datenblöcken entsprechend der erhöhten Fenstergröße zu übertragen.
  5. Kommunikationssystem mit einer Sendevorrichtung; einer Empfangsvorrichtung (50); und einer Server-Vorrichtung, die separat von der Sendevorrichtung und der Empfangsvorrichtung (50) verfügbar ist, wobei die Sendevorrichtung aufweist: Zuweisungsmittel, die angepasst sind, um jedem Datenblock, der sequentiell an die Empfangsmittel gesendet werden soll, Sequenzinformationen zuzuweisen; Übertragungsmittel, die angepasst sind, um eine Mehrzahl von ursprünglichen Datenblöcken an die Empfangsvorrichtung (50) zu übertragen nachdem die Sequenzinformation jedem aus der Mehrzahl der Datenblöcke zugewiesen wurde; Mittel zur erneuten Übertragung, die angepasst sind, um einen Datenblock aus der Mehrzahl der ursprünglichen Datenblöcke, für den keine Bestätigung empfangen wurde, erneut zu übertragen; gekennzeichnet durch Speichermittel (102), die angepasst sind, um eine Sequenznummer eines Datenblockes zu speichern, die als erwartete Bestätigungsnummer nachfolgend zur Bestätigungsnummer des erneut gesendeten Datenblockes ist; Empfangsmittel, die angepasst sind, um ein Bestätigungssignal zu empfangen, das Sequenzinformationen als eine Bestätigungsnummer zum Vergleich mit der erwarteten Bestätigungsnummer enthält; und Abfragemittel, die angepasst sind, um das Bestätigungssignal, die erwartete Bestätigungsnummer und eine Abfrage, ob das Bestätigungssignal einem aus der Mehrzahl der ursprünglichen Datenblöcke und den erneut an die Server-Vorrichtung gesendetem Datensegment entspricht, weiterzuleiten; wobei die Server-Vorrichtung (1) aufweist: Empfangsmittel, die angepasst sind, das Bestätigungssignal, die erwartete Bestätigungsnummer und die Anfrage von der Sendevorrichtung zu empfangen; Feststellungsmittel (100), die angepasst sind, um festzustellen, dass das Bestätigungssignal den Empfang von einem aus der Mehrzahl von ursprünglichen Datenblöcken bestätigt, wenn ein Wert der Bestätigungsnummer zum Vergleich größer als die erwartete Bestätigungsnummer ist, und um anzunehmen, dass das Bestätigungssignal zu dem erneut gesendeten Datenblock gehört, wenn der Wert der Bestätigungsnummer zum Vergleich der gleiche ist wie der der erwarteten Bestätigungsnummer; und Übertragungsmittel (101), die angepasst sind, um das Ergebnis der Feststellung an die Sendevorrichtung weiterzuleiten; und wobei die Übertragungsmittel der Sendevorrichtung angepasst sind, um einen ursprünglichen Datensatz nach der übertragenen Mehrzahl von ursprünglichen Datenblöcken zu übertragen, wenn festgestellt wird, dass das Bestätigungssignal den Empfang von einem aus der Mehrzahl der Datenblöcke bestätigt.
  6. Computerprogrammprodukt, das direkt in den internen Speicher eines Server-Computers ladbar ist, und das Software-Code-Anteile zur Ausführung aller der Schritte von Anspruch 1 oder 2 umfasst, wobei das Produkt auf einem Prozessor des Server-Computers läuft.
DE60307032T 2002-12-27 2003-12-22 Steuerungs-Verfahren und -Vorrichtung zur Datenübertragung Expired - Lifetime DE60307032T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002382222 2002-12-27
JP2002382222 2002-12-27

Publications (2)

Publication Number Publication Date
DE60307032D1 DE60307032D1 (de) 2006-09-07
DE60307032T2 true DE60307032T2 (de) 2007-02-15

Family

ID=32463667

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60307032T Expired - Lifetime DE60307032T2 (de) 2002-12-27 2003-12-22 Steuerungs-Verfahren und -Vorrichtung zur Datenübertragung

Country Status (4)

Country Link
US (1) US7505412B2 (de)
EP (1) EP1434380B1 (de)
CN (1) CN1244211C (de)
DE (1) DE60307032T2 (de)

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1548972A3 (de) * 2003-12-26 2006-12-27 NTT DoCoMo, Inc. Sender und Relais zur Steuerung der Datenübertragung
JP4417733B2 (ja) * 2004-01-15 2010-02-17 ソニー・エリクソン・モバイルコミュニケーションズ株式会社 伝送方法及び装置
GB0403459D0 (en) * 2004-02-17 2004-03-24 Ibm Data transfer in a messaging system
KR100604597B1 (ko) * 2004-02-20 2006-07-24 주식회사 팬택앤큐리텔 이동 통신 단말기
US7873070B2 (en) * 2004-09-16 2011-01-18 Alcatel-Lucent Usa Inc. Determining a number of automatic request retransmissions based on block size
US7882412B2 (en) * 2004-10-05 2011-02-01 Sanjiv Nanda Enhanced block acknowledgement
US20060168287A1 (en) * 2004-12-07 2006-07-27 Glauert Timothy H Rotating event buffer
US9325456B2 (en) * 2005-03-22 2016-04-26 Intel Corporation Method and apparatus for delayed recovery for block acknowledgement bursting in a wireless network
US9094257B2 (en) 2006-06-30 2015-07-28 Centurylink Intellectual Property Llc System and method for selecting a content delivery network
US8289965B2 (en) * 2006-10-19 2012-10-16 Embarq Holdings Company, Llc System and method for establishing a communications session with an end-user based on the state of a network connection
US8184549B2 (en) 2006-06-30 2012-05-22 Embarq Holdings Company, LLP System and method for selecting network egress
US8000318B2 (en) * 2006-06-30 2011-08-16 Embarq Holdings Company, Llc System and method for call routing based on transmission performance of a packet network
US7948909B2 (en) * 2006-06-30 2011-05-24 Embarq Holdings Company, Llc System and method for resetting counters counting network performance information at network communications devices on a packet network
US8194643B2 (en) * 2006-10-19 2012-06-05 Embarq Holdings Company, Llc System and method for monitoring the connection of an end-user to a remote network
US8717911B2 (en) 2006-06-30 2014-05-06 Centurylink Intellectual Property Llc System and method for collecting network performance information
US8488447B2 (en) 2006-06-30 2013-07-16 Centurylink Intellectual Property Llc System and method for adjusting code speed in a transmission path during call set-up due to reduced transmission performance
WO2008024387A2 (en) * 2006-08-22 2008-02-28 Embarq Holdings Company Llc System and method for synchronizing counters on an asynchronous packet communications network
US7684332B2 (en) * 2006-08-22 2010-03-23 Embarq Holdings Company, Llc System and method for adjusting the window size of a TCP packet through network elements
US7843831B2 (en) 2006-08-22 2010-11-30 Embarq Holdings Company Llc System and method for routing data on a packet network
US8549405B2 (en) 2006-08-22 2013-10-01 Centurylink Intellectual Property Llc System and method for displaying a graphical representation of a network to identify nodes and node segments on the network that are not operating normally
US8130793B2 (en) 2006-08-22 2012-03-06 Embarq Holdings Company, Llc System and method for enabling reciprocal billing for different types of communications over a packet network
US8743703B2 (en) 2006-08-22 2014-06-03 Centurylink Intellectual Property Llc System and method for tracking application resource usage
US8238253B2 (en) 2006-08-22 2012-08-07 Embarq Holdings Company, Llc System and method for monitoring interlayer devices and optimizing network performance
US8224255B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for managing radio frequency windows
US8199653B2 (en) 2006-08-22 2012-06-12 Embarq Holdings Company, Llc System and method for communicating network performance information over a packet network
US8619600B2 (en) 2006-08-22 2013-12-31 Centurylink Intellectual Property Llc System and method for establishing calls over a call path having best path metrics
US9479341B2 (en) 2006-08-22 2016-10-25 Centurylink Intellectual Property Llc System and method for initiating diagnostics on a packet network node
US8576722B2 (en) 2006-08-22 2013-11-05 Centurylink Intellectual Property Llc System and method for modifying connectivity fault management packets
US8537695B2 (en) 2006-08-22 2013-09-17 Centurylink Intellectual Property Llc System and method for establishing a call being received by a trunk on a packet network
US20080049629A1 (en) * 2006-08-22 2008-02-28 Morrill Robert J System and method for monitoring data link layer devices and optimizing interlayer network performance
US8223655B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for provisioning resources of a packet network based on collected network performance information
US8274905B2 (en) 2006-08-22 2012-09-25 Embarq Holdings Company, Llc System and method for displaying a graph representative of network performance over a time period
US7940735B2 (en) * 2006-08-22 2011-05-10 Embarq Holdings Company, Llc System and method for selecting an access point
US8098579B2 (en) * 2006-08-22 2012-01-17 Embarq Holdings Company, LP System and method for adjusting the window size of a TCP packet through remote network elements
US8194555B2 (en) * 2006-08-22 2012-06-05 Embarq Holdings Company, Llc System and method for using distributed network performance information tables to manage network communications
US8228791B2 (en) 2006-08-22 2012-07-24 Embarq Holdings Company, Llc System and method for routing communications between packet networks based on intercarrier agreements
US8064391B2 (en) 2006-08-22 2011-11-22 Embarq Holdings Company, Llc System and method for monitoring and optimizing network performance to a wireless device
JP2008053854A (ja) * 2006-08-22 2008-03-06 Fujitsu Ltd データの再送方法、通信装置、およびコンピュータプログラム
US8307065B2 (en) 2006-08-22 2012-11-06 Centurylink Intellectual Property Llc System and method for remotely controlling network operators
US8102770B2 (en) * 2006-08-22 2012-01-24 Embarq Holdings Company, LP System and method for monitoring and optimizing network performance with vector performance tables and engines
US8144586B2 (en) * 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for controlling network bandwidth with a connection admission control engine
US8144587B2 (en) 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for load balancing network resources using a connection admission control engine
US8015294B2 (en) 2006-08-22 2011-09-06 Embarq Holdings Company, LP Pin-hole firewall for communicating data packets on a packet network
US8189468B2 (en) 2006-10-25 2012-05-29 Embarq Holdings, Company, LLC System and method for regulating messages between networks
US8125897B2 (en) * 2006-08-22 2012-02-28 Embarq Holdings Company Lp System and method for monitoring and optimizing network performance with user datagram protocol network performance information packets
US8531954B2 (en) 2006-08-22 2013-09-10 Centurylink Intellectual Property Llc System and method for handling reservation requests with a connection admission control engine
US8750158B2 (en) 2006-08-22 2014-06-10 Centurylink Intellectual Property Llc System and method for differentiated billing
US7808918B2 (en) 2006-08-22 2010-10-05 Embarq Holdings Company, Llc System and method for dynamically shaping network traffic
US8407765B2 (en) 2006-08-22 2013-03-26 Centurylink Intellectual Property Llc System and method for restricting access to network performance information tables
US8111692B2 (en) * 2007-05-31 2012-02-07 Embarq Holdings Company Llc System and method for modifying network traffic
JP2009044581A (ja) 2007-08-10 2009-02-26 Fujitsu Ltd 通信装置、送信方法、受信方法
KR101345526B1 (ko) 2007-10-17 2013-12-27 한국과학기술원 통신 시스템에서 데이터 송수신 장치 및 방법
US8068425B2 (en) 2008-04-09 2011-11-29 Embarq Holdings Company, Llc System and method for using network performance information to determine improved measures of path states
US8880716B2 (en) * 2009-05-08 2014-11-04 Canon Kabushiki Kaisha Network streaming of a single data stream simultaneously over multiple physical interfaces
US8325623B1 (en) * 2010-02-16 2012-12-04 Google Inc. System and method for reducing latency during data transmissions over a network
US8830838B2 (en) * 2011-09-14 2014-09-09 Hewlett-Packard Development Company, L.P. Node interface indicators
CN104734985A (zh) * 2013-12-23 2015-06-24 腾讯数码(天津)有限公司 数据接收流量控制方法及其系统
JP6409558B2 (ja) * 2014-12-19 2018-10-24 富士通株式会社 通信装置、中継装置、および、通信制御方法
US9992087B2 (en) * 2015-05-15 2018-06-05 Sr Technologies, Inc. System and method for long range wireless local area network communications
CN108809532A (zh) * 2017-05-05 2018-11-13 华为技术有限公司 一种数据传输方法、装置和系统
EP4344156A3 (de) 2017-08-10 2024-05-22 Samsung Electronics Co., Ltd. Verfahren und vorrichtung zur datenverarbeitung in einem drahtloskommunikationssystem
EP3629505A1 (de) * 2018-09-25 2020-04-01 Panasonic Intellectual Property Corporation of America Benutzergerät und basisstation mit beteiligung an der übertragung von daten
WO2022116178A1 (zh) * 2020-12-04 2022-06-09 华为技术有限公司 一种tcp mss调整方法、装置及系统
US11750333B2 (en) 2021-10-06 2023-09-05 Sr Technologies, Inc. System and method for long range wireless local area network communications

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4839891A (en) * 1987-07-24 1989-06-13 Nec Corporation Method for controlling data flow
US5245616A (en) * 1989-02-24 1993-09-14 Rosemount Inc. Technique for acknowledging packets
CA2249152C (en) * 1998-09-30 2003-07-08 Northern Telecom Limited Apparatus for and method of managing bandwidth for a packet-based connection
EP1077559A1 (de) * 1999-08-17 2001-02-21 Telefonaktiebolaget Lm Ericsson Verfahren und Einrichtung zur Bestimmung eines Zeit-Parameters
US6757248B1 (en) 2000-06-14 2004-06-29 Nokia Internet Communications Inc. Performance enhancement of transmission control protocol (TCP) for wireless network applications
US20020165973A1 (en) * 2001-04-20 2002-11-07 Doron Ben-Yehezkel Adaptive transport protocol

Also Published As

Publication number Publication date
US20040190540A1 (en) 2004-09-30
EP1434380A1 (de) 2004-06-30
EP1434380B1 (de) 2006-07-26
US7505412B2 (en) 2009-03-17
CN1244211C (zh) 2006-03-01
CN1512710A (zh) 2004-07-14
DE60307032D1 (de) 2006-09-07

Similar Documents

Publication Publication Date Title
DE60307032T2 (de) Steuerungs-Verfahren und -Vorrichtung zur Datenübertragung
US6115357A (en) Method for pacing data flow in a packet-based network
JP4016387B2 (ja) データフロー制御方法
DE69932069T2 (de) Arq protokoll mit packetbasierter zuverlässigkeitseinstellung
DE60203285T2 (de) Verfahren und empfänger zur verbesserten datenpaketübertragung in ein übertragungsprotokoll
DE69837513T2 (de) Vorrichtung für die sichere Kommunikation über Funk- und Leitungsnetzwerke mittels Transportschichtverbindungen
DE69921512T2 (de) Kommunikationsverfahren
DE69931215T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
AU766823B2 (en) Method and device for determining a time-parameter
DE69935554T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und zuverlässigen Übertragen von kleinen Datennachrichten von einem Sendesystem zu einer grossen Anzahl von Empfangssystemen
DE60109959T2 (de) Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen
DE60036218T2 (de) Verbindungsschichtquittierung und wiederübertragung für ein zellulares telekommunikationssystem
DE60317837T2 (de) Verfahren und System zur Messung von Last und Kapazität auf einem Kanal mit variabler Kapazität
DE69838360T2 (de) System und Verfahren zur Leistungsüberwachung eines drahtlosen lokalen Netzwerkes und zum dynamischen Einstellen seiner Betriebsparameter
US7698453B2 (en) Early generation of acknowledgements for flow control
DE60211322T2 (de) Empfängerinitiierte Inkrementierung der Übertragungsrate
DE60206606T2 (de) Verfahren und vorrichtung zur verbesserung eines datendurchsatzes
DE60201553T2 (de) System und Verfahren zur Fehlerbeseitigung mit negativer Rückquittierung (NACK)
JP2004537218A (ja) Nackベースのプロトコルにおける輻輳制御の信頼性のある効率的な対応方法
KR100912178B1 (ko) 무선 환경에서의 혼잡제어방법 및 기록매체
EP1435704B1 (de) Verfahren und System zur Übertragungssteuerung
Henderson TCP performance over satellite channels
EP1102441A1 (de) Verfahren und Vorrichtung zur Verbesserung eines Datendurchsatzes in einem Kommunikationssystem
DE19911951C2 (de) Datenkommunikationssystem und Datenkommunikationsverfahren, welches eine Nachrichtenkollision umgehen kann
JP2005509370A (ja) 信頼性の低い通信環境における通信効率および性能の改良

Legal Events

Date Code Title Description
8364 No opposition during term of opposition