DE69919027T2

DE69919027T2 - Kommunikationsendgerät und -verfahren

Info

Publication number: DE69919027T2
Application number: DE69919027T
Authority: DE
Inventors: Michael Meyer; Reiner Ludwig
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1999-01-08
Filing date: 1999-12-31
Publication date: 2005-08-11
Anticipated expiration: 2020-01-01
Also published as: ATE272281T1; DE69919027D1; KR20010102969A; EP1195966B1; CA2646512C; AR053570A2; US20060050638A1; EP1018821A1; CA2646502A1; AR038753A1; EP1195966A2; AR054023A2; JP5153799B2; US6992982B1; DE69921512T2; CA2646502C; AU2104300A; JP2012227953A; CN1645785A; DE69921512D1

Description

Die vorliegende Erfindung betrifft eine Kommunikationsvorrichtung und ein Verfahren, wobei eine Dateneinheit-orientierte Kommunikation zwischen einem Sender und einem Empfänger durchgeführt wird, wobei der Sender und der Empfänger in Übereinstimmung mit einem vorbestimmten Kommunikationsprotokoll arbeiten.
Eine Dateneinheit-orientierte Kommunikation ist altbekannt. In einer Dateneinheit-orientierten Kommunikation wird eine Menge von Daten in eine oder mehrere Dateneinheiten geteilt, wobei der Aufbau der Dateneinheiten durch ein Kommunikationsprotokoll definiert ist, welches der Sender und der Empfänger bei der Kommunikation befolgen. Das Protokoll definiert auch, wie eine spezifische Information zu codieren ist, und wie der Sender und/oder der Empfänger auf eine spezifische Information reagieren können. Eine Dateneinheit-orientierte Kommunikation ist auch als eine Paketaustauschkommunikation bekannt. Es sei darauf hingewiesen, dass die Dateneinheiten, die bei einer Verbindung mit spezifischen Protokollen verwendet werden, unterschiedliche Namen wie etwa Pakete, Rahmen, Segmente, etc. aufweisen. Zum Zweck der vorliegenden Erfindung bezieht sich der Ausdruck "Dateneinheit" allgemein auf jedwede Typen von Einheiten, die in einer Dateneinheit-orientierten Kommunikation verwendet werden.
Ein Merkmal, das viele Kommunikationsprotokolle zur Erhöhung einer Zuverlässigkeit benutzen, besteht darin, empfangene Daten zu bestätigen. Spezifischer sendet ein Sender oder ein Sende-Peer des gegebenen Protokolls Dateneinheiten aus, und der Empfänger oder Empfangs-Peer des gegebenen Protokolls bestätigt den korrekten Empfang durch ein Zurückgeben geeigneter Bestätigungs-Dateneinheiten. Auf diese Weise wird der Sende-Peer informiert, dass die Dateneinheiten, die gesendet wurden, auch korrekt empfangen wurden, und er kann dementsprechend die Flusssteuerung der weiteren, zu übertragenden Dateneinheiten steuern. Ein Beispiel eines Protokolls, das Bestätigungs-Dateneinheiten verwendet, ist das sogenannte Übertragungssteuerungsprotokoll (TCP, Transmission Control Protocol), das ein Teil der TCP/IP-Protokoll-Suite ist.
Das Übertragungssteuerungsprotokoll und die TCP-IP-Protokoll-Suite sind z.B. in "TCP/IP Illustrated, Volume 1 – The Protocols" von W. Richard Stevens, Addison-Wesley, 1994 gut beschrieben.
Um der Tatsache Rechnung zu tragen, dass Dateneinheiten oder Bestätigungs-Dateneinheiten verloren gehen können, ist ein Zeitablauf-Merkmal in vielen Protokollen bereitgestellt. Ein derartiges Zeitablauf-Merkmal bedeutet, dass eine Zeitablauf-Periode gesetzt wird, wenn Daten gesendet werden, und wenn die spezifischen Daten nicht zu der Zeit bestätigt worden sind, zu der die Zeitablauf-Periode abläuft, wird eine Zeitablauf-Antwortprozedur gestartet. In dem TCP besteht die Zeitablauf-Antwort aus einem erneuten Übertragen der Daten, die nicht bestätigt wurden, und einem Rücksetzen eines oder mehrerer Verlust-Steuerungsparameter.
Als ein Beispiel verwendet TCP eine Fenster-basierte Flusssteuerung. TCP ist ein Byte-orientiertes Protokoll, das eine gegebene Anzahl von zu übertragenden Bytes in sogenannte Segmente teilt, und eine Aufzeichnung der gesendeten Daten wird hinsichtlich von Bytes gehalten, d.h. bis zu demjenigen Byte, bis zu dem die Daten gesendet wurden, und eine Aufzeichnung der empfangenen Daten wird auch hinsichtlich von Bytes gehalten, d.h. bis zu demjenigen Byte, bis zu dem die Daten empfangen wurden. Der einfachste Weg zum Steuern des Flusses von Segmenten in Verbindung mit Bestätigungsnachrichten wäre es, ein Segment zu übertragen und das nächste Segment nicht zu übertragen, bis das zuletzt gesendete Segment bestätigt wurde. Ein derartiges Verfahren einer Flusssteuerung würde jedoch nicht sehr effizient sein. Wie bereits erwähnt, verwendet TCP eine Fenster-basierte Flusssteuerung, die auch als eine Flusssteuerung gemäß gleitenden Fenstern bezeichnet wird. Dieses Konzept ist in dem oben erwähnten Buch von W. Richard Stevens ebenfalls gut beschrieben.
2 veranschaulicht das Konzept von gleitenden Fenstern. Wie ersehen werden kann, ist eine Menge von 8.192 Bytes in dem Beispiel zu übertragen, wobei diese Menge in 8 Segmente geteilt ist. Das Übertragen der Segmente wird in Übereinstimmung mit dem Sendefenster gesteuert, wobei das linke Ende des Sendefensters durch die Daten in dem Segment definiert ist, die gesendet und bereits bestätigt worden sind. In dem Beispiel der 2 sind dies die Daten bis zu 2.048 Bytes, d.h. die Segmente 1 und 2. Die Einstellung der Länge des Sendefenster und dadurch des rechten Ende des Fensters ist eine Angelegenheit der Steuerungsprozedur, die hier im Detail nicht erläutert werden muss.
Das Sendefenster definiert die Menge von Daten, die ihre entsprechende Bestätigung ausstehend aufweisen können. In dem Beispiel der 2 sind die Daten bis zu 4 096 Bytes, d.h. Segmente 3 und 4 gesendet worden und noch nicht bestätigt worden, und der Unterschied zwischen derartig gesendeten und nicht bestätigten Segmenten von dem rechten Ende des Sendefensters definiert das verwendbare Fenster, d.h. die Daten, die noch gesendet werden können, ohne irgendwelche weiteren Bestätigungen empfangen zu haben. Als Konsequenz können in dem Beispiel der 2 die Segmente 5 und 6 noch gesendet werden, aber die Segmente 7 und 8 können nur gesendet werden, wenn sich das Fenster nach rechts bewegt, was dann passiert, wenn weitere Segmente bestätigt werden, derart, dass sich das linke Ende nach rechts bewegt und/oder wenn die Länge des Sendefensters zunimmt.
Überdies sei darauf hingewiesen, dass das TCP eine kumulative Bestätigung bereitstellt, d.h. es existiert keine Eins-zu-Eins-Entsprechung zwischen Segmenten und Bestätigungen für Segmente, weil eine Bestätigungsnachricht eine Mehrzahl von Segmenten abdecken kann. Als ein Beispiel könnte der Empfangs-Peer für die Datenmenge, die in 2 gezeigt ist, eine Bestätigung von Bytes bis zu 4.096 senden, derart, dass diese Bestätigungsnachricht beide Segmente 3 und 4 abdecken würde.
Das Sendefenster, das von dem Sende-Peer verwendet wird, wird in typischer Weise durch das sogenannte angebotene oder angekündigte Fenster bestimmt werden, welches eine Datenlänge ist, die dem Sende-Peer von dem Empfangs-Peer bereitgestellt wird. Auf diese Weise kann der Empfangs-Peer beeinflussen, wie viele Segmente der Sende-Peer jeweils übertragen wird, und typischer Weise wird das angekündigte Fenster auf der Grundlage des Empfangspuffers des Empfangs-Peers berechnet werden. Auch ist das angekündigte Fenster ein dynamischer Parameter, der mit jeder Bestätigung geändert werden kann, die von dem Empfangs-Peer gesendet wird.
Über das angekündigte Fenster hinaus ist es auch üblich, das sogenannte Besetzt-Fenster zu definieren, das in Verbindung mit mehreren Besetzt-Steuerungsroutinen wie etwa einem langsamen Start, einer Besetzt-Vermeidung, einer schnellen Neusendung und einer schnellen Wiedergewinnung verwendet wird, siehe wiederum z.B. das oben erwähnte Buch von W. Richard Stevens. Das Besetzt-Fenster ist eine Aufzeichnung, die der Sende-Peer hält, und ist dafür vorgesehen, einen Besetzt-Zustand entlang der Verbindung zwischen dem Sende-Peer und dem Empfangs-Peer zu berücksichtigen. Als ein typischer Steuerungsmechanismus wird das Sende-Fenster als das kleinere von dem angekündigten Fenster und dem Besetzt-Fenster definiert werden.
Während das angekündigte Fenster eine Flusssteuerung ist, die von dem Empfangs-Peer auferlegt ist, ist das Besetzt-Fenster eine Flusssteuerung, die von dem Sende-Peer auferlegt ist, als ein Mechanismus zum Berücksichtigen des Besetzt-Zustands.
In einem allgemeinen Sinn ist das Besetzt-Fenster ein Beispiel eines adaptiven Flusssteuerungsparameters. In dem TCP besteht die oben erwähnte Zeitablauf-Antwort aus einem Rücksetzen des Besetzt-Fensters in ein Segment und dann aus einem darauffolgenden ausschließlichen Übertragen eines Segments, nämlich einem erneuten Übertragen des Segments, das nicht bestätigt wurde und dadurch den Zeitablauf herbeiführte. Der Sende-Peer wartet dann auf die Bestätigung des erneut übertragenen Segments.
Ein anderes Beispiel eines adaptiven Flusssteuerungsparameters ist die Zeitablauf-Periode selbst, die z.B. in dem TCP als RTO (Zeitablauf für erneute Sendung) bezeichnet wird. Die RTO wird als Antwort auf einen Zeitablauf verdoppelt.
Wie bereits erwähnt, ist das Zeitablauf-Merkmal ein Datenverlust-Erfassungsmechanismus. Andere Datenverlust-Erfassungsmechanismen existieren. Ein anderes Beispiel ist die erneute Sendung von Dateneinheiten in dem TCP als Antwort auf den Empfang doppelter Bestätigungen. Dieser Mechanismus wird kurz im folgenden erläutert werden.
Wie bereits erwähnt (siehe z.B. 2), wird eine zu übertragende Datenmenge in eine Sequenz geteilt. Herkömmliche Implementierungen des TCP sind derart angeordnet, dass dann, wenn der Empfangs-Peer eine bestimmte Datenmenge bis zu einem gegebenen Byte empfangen und bestätigt hat (eine bestimmte Anzahl aufeinanderfolgender Segmente), der die Daten erwartet, die in der Sequenz als nächstes kommen. Beispielsweise wird, wenn Segmente bis zu dem Segment 4 hin empfangen worden sind, dann das Segment 4 bestätigt und der Empfangs-Peer erwartet, das Segment 5 zu empfangen. Wenn er dann eine weitere Dateneinheit empfängt, die unterschiedlich von dem Segment 5 ist (z.B. die Segmente 6, 7 und 8) setzt er die Bestätigung für das Segment 4 für jede Dateneinheit fort, die er empfängt. Folglich empfängt der Sende-Peer doppelte Bestätigungen. Üblicherweise ist das TCP auf eine derartige Weise implementiert, dass der Sende-Peer die Anzahl von doppelten Bestätigungen zählen wird, und wenn ein bestimmter Schwellenwert erreicht ist (z.B. 3), dann wird die Dateneinheit, die in der Sequenz als nächstes auf die Dateneinheit folgt, für welche doppelte Bestätigungen empfangen wurden, erneut übertragen.
Die WO 98/37670 beschreibt ein Verfahren zum Verbessern eines Transportprotokoll-Betriebsverhaltens in Netzen, welche verlustbehaftete Verbindungen aufweisen. Herkömmliche Sender in einer Kommunikation identifizieren, das ein Paket aufgrund eines Besetzt-Zustands verlorengegangen ist, entweder durch die Ankunft doppelter Bestätigungen oder durch die Abwesenheit einer Bestätigung innerhalb eines Zeitablauf-Intervalls. In Reaktion auf einen Besetzt-Zustand werden geeignete Steuerungsschemata in dem Sender wie etwa ein langsamer Start, eine schnelle Wiedergewinnung und eine schnelle erneute Übertragung ausgeführt. Die WO 98/37670 zeigt ferner auf, dass dann, wenn übertragene Pakete aus anderen Gründen als einem Besetzt-Zustand nicht empfangen werden können, Besetzt-Zustand-Kombinationsmaßnahmen schädlich sein können.
Die WO 98/37670 schlägt eine Verwendung selektiver Bestätigungen vor, die anzeigen, welche Pakete erfolgreich empfangen wurden, und welche mit Nicht-Besetzt-Zustand-Bitfehlern empfangen wurden, während doppelte Bestätigungen unterdrückt werden, um den Aufruf eines Besetzt-Mechanismus zu verhindern.
Der Artikel "A comparison of Mechanisms for Improving TCP Performance over Wireless Links" von H. Balakrishnan et al, IEEE/ACM Transactions on Networking, Bd. 5, Nr. 6, 12/1997, XP-000734405 beschreibt ein ähnliches Schema wie die WO 98/37670. Zusätzlich zu selektiven Bestätigungen erwähnt dieser Artikel auch eine explizite Verlustbenachrichtigung (ELN).
Es ist die Aufgabe der vorliegenden Erfindung, die Kommunikation in einem System zu verbessern, das ein Kommunikationsprotokoll verwendet, das die Bestätigung gesendeter Daten spezifiziert und eine Datenverlust-Erfassungsfunktion wie etwa eine Zeitablauffunktion oder eine doppelte Bestätigungs-Antwortfunktion spezifiziert.
Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 und eine Vorrichtung nach Anspruch 17 gelöst. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen beschrieben.
In Übereinstimmung mit der vorliegenden Erfindung wird ein Sender in einer Kommunikation eine Antwortprozedur als Antwort auf ein Ereignis ausführen, das einen Datenverlustmechanismus triggert, wobei die Antwortprozedur zumindest zwei unterschiedliche Modi zum Anpassen der adaptiven Parameter umfasst, die in einer Flusssteuerung verwendet werden. Auf diese Weise sind das Verfahren und die Vorrichtung der vorliegenden Erfindung in hohem Maße in ihrer Verwaltung zum Triggern von Ereignissen flexibel und können insbesondere auf eine derartige Weise implementiert werden, dass die Antwortprozedur in Abhängigkeit verschiedener potentieller Ursachen des Trigger-Ereignisses gewählt werden können, derart, dass die korrekten Antwortmaßnahmen auf eine gegebene Situation aufgerufen werden können, und dadurch Maßnahmen vermieden werden können, die die Situation tatsächlich verschlimmern können, die auftreten können, nachdem ein Datenverlust-Erfassungsmechanismus getriggert wurde.
Der Datenverlust-Erfassungsmechanismus ist ein Mechanismus, der in der Lage ist, einen Datenverlust zu erfassen. Beispiele sind ein Zeitablauf-Mechanismus oder ein doppelter Bestätigungs-Mechanismus. Natürlich kann die Erfindung auf jedweden geeigneten Datenverlust-Erfassungsmechanismus angewandt werden.
Gemäß der vorliegenden Erfindung umfasst eine Antwortprozedur zumindest zwei unterschiedliche Modi zum Anpassen der adaptiven Parameter, die in der Flusssteuerung verwendet werden. Als ein Beispiel, das eine bevorzugte Ausführungsform bildet, sind zwei Modi vorhanden, die jeweils unterschiedlichen Ursachen eines Zeitablaufs oder einer vorbestimmten Anzahl von doppelten Bestätigungen (z.B. die oben erwähnten 3) zugeordnet werden. Spezifischer ist ein erster Modus dem Verlust einer Dateneinheit zugeordnet, und der zweite Modus ist einer übermäßigen Verzögerung entlang der Verbindung zugeordnet. Aufgrund der Verwendung zweier unterschiedlicher Modi ist es möglich, die Parameter anzupassen, wie es für die Ursache des Zeitablaufs oder doppelter Bestätigungen geeignet ist. Dementsprechend wird die Flusssteuerungsprozedur einen oder mehrere Evaluations- und Beurteilungsschritte enthalten, in welchen das Trigger-Ereignis qualifiziert wird, z.B. eine Kategorisierung wird dahingehend durchgeführt, was das Ereignis herbeiführt. Dann kann in Abhängigkeit von dem Ergebnis dieser Charakterisierung eine geeignete Antwortprozedur ermöglicht werden. In dem Kontext des obigen Beispiels kann, wenn bestimmt wird, dass der Zeitablauf oder die doppelten Bestätigungen durch den Verlust einer Dateneinheit herbeigeführt sind, dann die bekannte Antwortprozedur auf dem Verlust von Dateneinheiten durchlaufen werden, wie es z.B. aus dem herkömmlichen TCP bekannt ist, das annimmt, das jedweder Zeitablauf oder der Empfang mehrerer doppelter Bestätigungen durch den Verlust einer Dateneinheit herbeigeführt ist. In Übereinstimmung mit der vorliegenden Erfindung ist jedoch ein zweiter Modus vorhanden, und wenn bestimmt wird, dass der Zeitablauf und doppelte Bestätigungen durch eine übermäßige Verzögerung entlang der Verbindung herbeigeführt sind, wird dann eine Antwortprozedur auf eine übermäßige Verzögerung durchlaufen, die typischer Weise unterschiedlich von der Antwortprozedur auf den Verlust einer Dateneinheit sein wird.
Spezifischer, wie auch detaillierter im folgenden erläutert werden wird, wird die Beurteilung, dass Dateneinheiten verlorengegangen sind, durch ein Verringern der Übertragungsrate beantwortet werden, um dadurch einen weiteren Besetzt-Zustand zu vermeiden. Andererseits wären, wenn eine übermäßige Verzögerung entlang der Verbindung vorhanden ist, dann die Maßnahmen, die als Antwort auf einen angenommenen Verlust von Dateneinheiten unternommen werden, nicht hilfreich, vielmehr können sie tatsächlich das Problem verschlimmern, das die übermäßige Verzögerung herbeiführt. Folglich wird die Antwortprozedur auf eine übermäßige Verzögerung typischer Weise unterschiedlich sein, und z.B. ein Aufrechterhalten der Übertragungsrate auf dem vorherigen Pegel, aber andererseits ein Erhöhen der Zeitablaufperiode umfassen, derart, dass weitere unnötige erneute Übertragungen vermieden werden.
Natürlich kann die vorliegende Erfindung bereitgestellt werden, eine beliebige Anzahl von Modi oder Antwortprozeduren auf verschiedene Fälle von Trigger-Ereignissen bereitzustellen. Die Anzahl der Modi und der spezifischen Maßnahmen, die in jedem Modus unternommen werden, hängen natürlich von der spezifischen Situation ab, d.h. dem gewählten Protokoll, der gegebenen Kommunikationssituation, etc.
Ein wichtiger Aspekt der vorliegenden Erfindung besteht darin, dass, obwohl der Datenverlustmechanismus in der Lage ist, einen Datenverlust zu erfassen, die Reaktion auf das Trigger-Ereignis des Datenverlust-Erfassungsmechanismus nicht annimmt, dass ein Datenverlust notwendigerweise aufgetreten ist, vielmehr ist eine flexible Antwort möglich, die verschiedene Ursachen des Trigger-Ereignisses berücksichtigen kann.
Weitere Aspekte und Vorteile der vorliegenden Erfindung werden aus der folgenden detaillierten Beschreibung besser verstanden werden, die Bezug nimmt auf die Figuren.
In den Figuren zeigen:
1 eine bevorzugte Ausführungsform der Steuerungsprozedur gemäß der vorliegenden Erfindung;
2 ein Erläutern des Diagramms zum Beschreiben des Konzeptes einer Fenster-basierten Flusssteuerung;
3 einen Graphen zum Erläutern der Vorteile der vorliegenden Erfindung; und
4 ein Erläutern des Diagramms zum Veranschaulichen einer Situation, in welcher eine übermäßigen Verzögerung in einer Verbindung zwischen zwei Host-Computern herbeigeführt werden kann.
Obwohl die folgende Beschreibung allgemein auf irgendein Kommunikationsprotokoll gerichtet sein wird, das eine Datenbestätigung verwendet und auch ein Zeitablauf-Merkmal bereitstellt, werden Beispiele häufig gegeben werden, die das Übertragungssteuerungsprotokoll TCP betreffen, das aus der TCP/IP-Protokoll-Suite bekannt ist. Die Anwendung der vorliegenden Erfindung auf dieses Protokoll ist eine bevorzugte Ausführungsform. Um jedwede unnötige Wiederholung zu vermeiden, ist die Offenbarung in der Einleitung dieser Anmeldung in die Erfindungsoffenbarung eingeschlossen.
1 zeigt ein Teil-Flussdiagramm einer bevorzugten Ausführungsform der vorliegenden Erfindung. Wie ersehen werden kann, zeigt ein Schritt S1 an, dass in eine Antwortprozedur eingetreten wird. 1 zeigt nicht die Flusssteuerungsprozedur, die zu diesem Punkt führt, da sie für die vorliegende Erfindung nicht von Wichtigkeit ist. Beispielsweise kann sie die Fenster-basierte Flusssteuerungsprozedur sein, die in Verbindung mit 2 erläutert ist und z.B. aus dem TCP altbekannt ist. Es ist für die Erfindung nur wichtig, dass ein Datenbestätigungs- und ein Datenverlusterfassungs-Merkmal vorhanden ist, und dass ein Sende-Peer des Protokolls die Fähigkeit eines Erfassens eines möglichen oder potentiellen Datenverlusts aufweist, und eine entsprechende Antwortprozedur durchführen kann. Wie bereits erwähnt, kann das Datenverlust-Erfassungsmerkmal z.B. ein Zeitablauf-Merkmal oder ein Erfassungsmerkmal für eine doppelte Bestätigung sein.
In dem Beispiel der 1 werden, nachdem in die Antwortprozedur eingetreten ist, selektive adaptive Parameter, die für die Flusssteuerung verwendet werden, gespeichert und dann auf vorbestimmte Werte in einem Schritt S2 zurückgesetzt. Als ein Beispiel sind die Zeitablaufperiode und/oder das umgeschriebene Besetzt-Fenster adaptive Flusssteuerungsparameter. In dem herkömmlichen TCP wird das Besetzt-Fenster typischer Weise auf einen Wert eines Segments zurückgesetzt und gleichzeitig wird die RTO verdoppelt. Es sei darauf hingewiesen, dass nicht sämtliche adaptiven Parameter, die in der Flusssteuerungsprozedur verwendet werden, tatsächlich geändert werden müssen, vielmehr nur eine ausgewählte Anzahl.
Es sollte auch klar sein, dass die vorliegende Erfindung natürlich nicht auf eine Fenster-basierte Flusssteuerung und die zugeordneten adaptiven Parameter beschränkt ist, vielmehr ist die Verbindung auf jedes Flusssteuerungsprinzip und die zugeordneten adaptiven Parameter anwendbar.
Zurückkehrend auf 1 wird die Dateneinheit, die das Ereignis triggerte (z.B. einen Zeitablauf herbeiführte) erneut in einem Schritt S3 übertragen. Mit anderen Worten wird, wenn bei dem Beispiel eines Zeitablaufs geblieben wird, die Dateneinheit, für welche eine Bestätigung empfangen wurde, während der Zeitablaufperiode erneut übertragen. Dann wird zu einem späteren Zeitpunkt in einem Schritt S4 bestimmt, ob eine Bestätigung, die der erneut übertragenen Dateneinheit zugeordnet ist, empfangen worden ist. Dies kann eine kumulative Bestätigung oder auch eine einzelne Bestätigung sein. Es sei darauf hingewiesen, dass die gestrichelten Linien in 1 anzeigen, dass andere Schritte dazwischengesetzt werden können, aber diese sind für die vorliegende Erfindung von keiner Bedeutung. Dann bestimmt gemäß dem bevorzugten Beispiel der 1 ein Schritt S5, ob die Bestätigung, die der Dateneinheit zugeordnet ist, die erneut übertragen wurde, tatsächlich die ursprüngliche Übertragung der Dateneinheit oder die erneute Übertragung bestätigt. Es sei darauf hingewiesen, dass die "ursprüngliche Übertragung" bereits eine erneute Übertragung sein kann, derart, dass die "erneute Übertragung" die erneute Übertragung einer erneuten Übertragung sein kann, etc. Es sind verschiedene Möglichkeiten eines Implementierens des Schritts S5 vorhanden, wie weiter erläutert werden wird.
Wenn der Schritt S5 bestimmt, dass die Bestätigungsnachricht tatsächlich die erneute Übertragung der Dateneinheit bestätigt, dann geht die Prozedur zu einem Schritt S7, in welchem eine Dateneinheit-Verlustantwortprozedur abläuft, weil das negative Ergebnis des Entscheidungsschritts S5 anzeigt, dass die ursprüngliche Übertragung der Dateneinheit verloren ging. In dem Beispiel von TCP wird der Schritt S7 aus herkömmlichen Maßnahmen gegenüber einem Dateneinheitverlust bestehen.
Im Gegensatz dazu geht, wenn der Entscheidungsschritt S5 bejahend beantwortet wird, dann die Prozedur zu einem Schritt S6, in welchem eine Antwortprozedur läuft, die eine übermäßige Verzögerung beantwortet. Mit anderen Worten müssen, weil der Schritt S5 anzeigt, dass die ursprüngliche Übertragung der Dateneinheit tatsächlich nicht verloren ging, sondern nur übermäßig verzögert wurde, entsprechende Maßnahmen unternommen werden. Beispielsweise kann dies, wenn das TCP als ein Protokollbeispiel genommen wird, aus einem Zurücksetzen des Besetzt-Fensters auf den Wert bestehen, der im Schritt S2 gespeichert ist, und andererseits einem Anpassen der Zeitablauf-Periode an die Verzögerung. Mit anderen Worten können die Rundlaufzeit RTT, die der ursprünglichen Übertragung zugeordnet ist, und die Bestätigung der ursprünglichen Übertragung als eine Grundlage zum Anpassen der Zeitablauf-Periode verwendet werden. Dadurch können weiter unnötige erneute Übertragungen und Zeitabläufe oder doppelte Bestätigungen aufgrund einer übermäßigen Verzögerung vermieden werden.
Vorzugsweise wird das Besetzt-Fenster nicht einfach auf den vorherigen Wert zurückgesetzt, sondern vielmehr auf den Wert gesetzt, den es angenommen hätte, wenn die Antwortprozedur nicht stattgefunden hätte, d.h. der Datenverlust-Erfassungsmechanismus nicht ausgelöst worden wäre.
Wie ersehen werden kann, zeigt das Beispiel der 1 einen ersten Modus, der aus den Schritten S2, S3, S4, S5 und S7 besteht, wie auch einem zweiten Modus, der aus den Schritten S2, S3, S4, S5 und S6 besteht.
Um die vorliegende Erfindung besser zu erläutern, wird nun Bezug genommen werden auf 3, die ein Beispiel einer Flusssteuerungsprozedur zeigt, die in Verbindung mit dem herkömmlichen TCP ausgeführt wird. Der Graph zeigt die Menge von Daten in transportierten Bytes über der Zeit. Wie ersehen werden kann, werden die ersten beiden Segmente zu einer Zeit t=4s gesendet. Dann werden aufgrund der Wechselwirkung der empfangenen Bestätigungsdateneinheiten und der Einstellung adaptiver Parameter, die nicht gezeigt sind, Segmente gesendet.
Zum Zwecke einer Erläuterung sei darauf hingewiesen, dass die diamantförmigen Symbole sich auf Segmente beziehen und die quadratischen Symbole auf Bestätigungsdaten-Einheiten. Die Diamantsymbole zeigen das erste Byte des Segments an, wohingegen die Quadrate das niedrigste nicht-bestätigte Byte anzeigen. Die Bestätigungsdateneinheiten, die in einem bestimmten Segmentpegel angezeigt sind, bestätigen immer die gesendeten Segmente bis zu dem Segmentpegel. Mit anderen Worten bestätigt die Bestätigung bei einem Segmentpegel 6.400 Bytes (t=12s) die Segmente unterhalb 6.400 Byte, aber nicht einschließend das Byte 6.400. Ganz im Gegensatz dazu, wie explizit in dem Graphen angezeigt, ist das Segment bei 6.400 Byte (t=10s) eine Dateneinheit oder ein Paket, das einen Zeitablauf herbeiführt. Als Folge wird eine erneute Übertragung der Dateneinheit bei dem 6.400 Byte-Pegel durchgeführt.
Wenn nun angenommen wird, dass der Zeitablauf, der in 3 gezeigt ist, durch eine übermäßige Verzögerung herbeigeführt wurde, nicht dadurch, dass das gezeigte erste Paket verloren geht, dann weist die erneute Übertragung die folgenden negativen Konsequenzen auf.
Einerseits führt sie zu einem verringerten Durchsatz-Betriebsverhalten, da die gleichen Daten die Verbindung oder den Verbindungspfad zweifach durchlaufen müssen, was Bandbreiten verschwendet, die andernfalls für Nutzdaten hätten verwendet werden können. Diese negative Konsequenz wird in jedwedem Protokoll auftreten, das auf einem Zeitablauf fälschlicherweise durch ein erneutes Übertragen der Dateneinheit antwortet.
Falls, wie in 3 gezeigt, das TCP-Protokoll verwendet wird, dann ist die Reaktion des Sende-Peers auf einen derartigen Zeitablauf, der nicht von einem Dateneinheitverlust herbeigeführt wird, besonders nachteilig: Der Sender wird sämtliche ausstehende Pakete erneut übertragen und darüber hinaus eine Übertragungsrate verringern. Dies ist explizit in 3 gezeigt.
Es sei darauf hingewiesen, dass der oben beschriebene Zeitablauf, der durch einen Dateneinheitverlust herbeigeführt wird, auch als ein unechter Zeitablauf bezeichnet wird.
Wie in 3 gezeigt wird, missinterpretiert in dem herkömmlichen TCP der Sender sämtliche Bestätigungen, die erneut übertragenen Dateneinheiten zugeordnet sind, als Bestätigen der erneuten Übertragung, auch wenn diese Bestätigungen (ACKs) tatsächlich verzögerte Bestätigungen der ursprünglichen Übertragungen sind.
Was 3 nicht zeigt, ist, dass die doppelten Dateneinheiten, die von dem Sende-Peer gesendet werden, zusätzlich doppelte Bestätigungen in dem Empfangs-Peer triggern werden, was noch zu einer weiteren Verringerung in der Übertragungsrate in dem herkömmlichen TCP-Sender führt, das Besetzt-Fenster wird nämlich auf eine Hälfte seines früheren Werts gesetzt.
Das Auftreten einer übermäßigen Verzögerung, die über das hinausgeht, was die TCP-Zeitablauf-Periode berücksichtigen kann, kann insbesondere bei drahtlosen Netzen oder derartigen Protokollverbindungen auftreten, von welchem zumindest ein Teil über eine drahtlose Verbindung läuft. Die Erfinder der vorliegenden Anmeldung erkannten, dass unechte Zeitabläufe oft genug in derartigen Netzen vorkommen können, so dass eine Erstverschlechterung des Betriebsverhaltens resultiert. Beispiele hierfür werden nun kurz erwähnt werden.
4 zeigt eine Situation, wo zwei Host-Computer als Peers des TCP wirken (angezeigt durch die langen Pfeile von Host zu Host an der Unterseite und der Oberseite der Figur). Die unteren Protokollschichten umfassen eine Funkverbindung über ein drahtloses Zugriffsnetz auf das Internet. Die Verbindung zwischen dem Internet und dem Host auf der rechten Seite ist nicht gezeigt. Ein Beispiel eines Protokolls für die Funkverbindung ist das sogenannte Funkverbindungs-Steuerungsprotokoll RLC. Wie in 4 angezeigt, weisen sowohl das Transportschichtprotokoll (z.B. TCP) als auch das Verbindungsschichtprotokoll (z.B. RLC) eine ARQ (Automatische Anforderung für erneute Übertragung)-Funktion auf. Dies bedeutet, dass diese Protokolle sowohl Zeitablauf- als auch erneute Übertragungsfunktionen implementieren. In der Situation der 4 wird aufgrund der ARQ, die in der Verbindungsschicht verwendet wird, eine Wettlaufbedingung zwischen der Verbindungsschicht und der Transportschicht erzeugt: Während die Verbindungsschicht Daten erneut überträgt, kann der Transport-Neuübertragungs-Zeitgeber ablaufen, was zu einem unechten Zeitablauf führt. Die erneuten Übertragungen in der Verbindungsschicht können z.B. aufgrund von Übertragungsfehlern oder einem Datenverlust wegen Kanalwechseln vorhanden sein.
Es sei auch darauf hingewiesen, dass die Übertragungsverzögerung über das drahtlose Netz oft ein beträchtlicher Teil der End-zu-End-Verzögerung zwischen dem Sende-Peer und dem Empfangs-Peer des Transportschichtprotokolls ist. Wenn in diesem Fall die Bandbreite, die für die Transportschichtverbindung verfügbar ist, in dem drahtlosen Netz über einer kurzen Zeitperiode beträchtlich abfällt, kann die resultierende Zunahme in der End-zu-End-Verzögerung zwischen dem Transportschicht-Sender- und Empfänger zu unechten Zeitabläufen führen. Beispiele von Bandbreitenabfällen schließen mobile Hosts ein, die einen Kanalwechsel in einer Zelle durchführen, die eine geringere Bandbreite als die alte Zelle bereitstellt.
Wie bereits zuvor angezeigt, kann, wenn die vorliegende Erfindung eingesetzt wird, das in Verbindung mit 3 beschriebene Problem vermieden werden. Spezifischer kann, wenn das Verfahren, das in Verbindung mit 1 beschrieben ist, auf das Problem in 3 angewandt wird, dann der Sende-Peer zwischen Bestätigungsdateneinheiten auf die ursprüngliche Übertragung einer Dateneinheit und Bestätigungsdateneinheiten auf die erneute Übertragung einer Dateneinheit unterscheiden. Auf dieser Information kann der Sender bestimmen, ob ein unechter Zeitablauf aufgetreten ist, oder ob tatsächlich ein Verlust einer Dateneinheit vorhanden war. Der Sender kann dann dementsprechend reagieren.
Spezifischer wird in dem Beispiel der 3 der Sender, der die Erfindung verwendet, in der Lage sein, die Bestätigungsdateneinheit, die empfangen wird, nachdem das gezeigte erste Paket erneut übertragen worden ist, identifizieren, eine Bestätigung für die ursprüngliche Übertragung (t=10s) und nicht für die erneute Übertragung (t=15s) zu sein. Aufgrund dessen wird der Sender eine geeignete Antwortprozedur auf die übermäßige Verzögerung durchführen, nämlich nicht die Dateneinheiten, die der ersten erneuten übertragenen Dateneinheit folgen, erneut übertragen, und auch nicht die Übertragungsrate verringern, vielmehr wird der Sender die Zeitablaufperiode, die in der Flusssteuerung eingesetzt wird, auf der Grundlage der gemessenen Verzögerung zwischen dem ursprünglichen Übertragen der Dateneinheit und dem Empfang der entsprechenden Bestätigungsdateneinheit für das ursprüngliche Übertragen erhöhen. Auf diese Weise können unechte erneute Übertragungen und Zeitabläufe vermieden werden.
Wie ersehen werden kann, ist die vorliegende Erfindung in der Lage, einen Mechanismus bereitzustellen, der ein flexibleres Kommunikationssystem zulässt, wenn ein Protokoll verwendet wird, das eine Bestätigung von Daten und eine Zeitablauffunktion oder eine doppelte Bestätigungs-Erfassungsfunktion bereitstellt. In dem gerade beschriebenen Beispiel ist die Erfindung in der Lage, ein Trigger-Ereignis zu qualifizieren, d.h. zwischen zumindest zwei unterschiedlichen Fällen zu unterscheiden, und dann in der Lage, eine geeignete Antwortprozedur aufzurufen. Es sei darauf hingewiesen, dass in den obigen Beispielen die Modi zum Anpassen der adaptiven Parameter einem Dateneinheitverlust einerseits und einer übermäßigen Verzögerung andererseits zugeordnet waren, aber natürlich ist die vorliegende Erfindung keineswegs darauf beschränkt. Vielmehr können die Modi zum Anpassen der adaptiven Parameter jedwedem möglichen Grund von Zeitablaufereignissen oder doppelten Bestätigungsereignissen zugeordnet werden.
In der in 1 beschriebenen Ausführungsform wurde in dem Schritt S5 bestimmt, ob die Bestätigungsdateneinheit, die einer gegebenen Dateneinheit zugeordnet ist, die ursprüngliche Übertragung oder die erneute Übertragung der gegebenen Dateneinheit bestätigte. Gemäß einer ersten bevorzugten Ausführungsform zum Implementieren dieses Schritts hält der Sender eine Aufzeichnung der Rundlaufzeit RTT, die der Verbindung zwischen dem Sende- und dem Empfangs-Peer zugeordnet ist, und hält insbesondere eine Aufzeichnung der kürzesten RTT, die während der Verbindung oder der Sitzungseinrichtung bis zu dem betrachteten Zeitpunkt gefunden wird. Dann bestimmt, wenn eine Bestätigungsdateneinheit für eine erneute übertragene Dateneinheit innerhalb einer Zeitperiode empfangen wird, die kleiner als ein vorbestimmter Teil der kürzesten RTT ist, dann der Sender, dass diese Bestätigung zu der ursprünglichen Übertragung und nicht zu der erneuten Übertragung gehört. Dieser Teil kann auf einen festen Wert eingestellt werden, oder er kann selbst ein adaptiver Parameter sein. Natürlich ist es nicht notwendig, dass der Vergleichswert, der mit dem Teil multipliziert wird, die kürzeste gemessene RTT ist, vielmehr ist es auch möglich, dass der Sender einen mittleren RTT-Wert hält. In diesem Sinne ist der Vergleichswert, der mit dem Teil zu multiplizieren ist, allgemein eine Funktion eines oder mehrerer RTT-Werte, die in dem Verlauf der Verbindung gemessen werden (während der Sitzung).
Gemäß einer anderen bevorzugten Ausführungsform zum Implementieren des Schritts S5 addiert der Sender eine Markierung zu Dateneinheiten, die er sendet, wobei die Markierung auf eine derartige Weise definiert ist, dass sie es zulässt, zwischen einer ursprünglichen Übertragung und einer erneuten Übertragung zu unterscheiden. Dann kann der Empfänger entsprechend Bestätigungsdateneinheiten markieren, derart, dass der Sender in der Lage ist, zu identifizieren, ob sich eine Bestätigung auf die ursprüngliche Übertragung oder die erneute Übertragung bezieht.
Dieses Markieren von Dateneinheiten kann auf jedwede gewünschte Weise durchgeführt werden. Beispielsweise wäre es theoretisch möglich, einfach ein einzelnes Bit in den Dateneinheiten zu bezeichnen, wobei ein Wert von 0 eine ursprüngliche Übertragung und ein Wert von 1 eine erneute Übertragung kennzeichnen würde, oder umgekehrt. In einem allgemeinen Sinne kann eine Bitkette gewählt werden, die auch etwas mehr Information übertragen kann. Jedoch ist es in Verbindung mit Protokollen, die eine derartige Option bereitstellen, vorzuziehen, die Zeitstempeloption zu verwenden. Diese Option ist z.B. für TCP altbekannt, siehe das oben erwähnte Buch von W.R. Stevens. Mit anderen Worten ist es vorzuziehen, einen Zeitstempel in gesendeten Dateneinheiten einzuschließen, der anzeigt, wann die Dateneinheit gesendet wurde. Der Empfänger kann dann einfach den Zeitstempel in die Bestätigungsdateneinheit einschließen, so dass der Sender eine eindeutige Weise zum Identifizieren der Dateneinheiten hat, auf welche sich die Bestätigung bezieht.
Obwohl die vorliegende Erfindung in Verbindung mit bevorzugten Ausführungsformen beschrieben worden ist, beschränken diese den Umfang nicht, und sind nur vorgesehen, um ein besseres Verständnis der Erfindung zu vermitteln. Vielmehr ist der Umfang der Erfindung durch die angehängten Ansprüche bestimmt.

Claims

Verfahren zum Steuern einer Dateneinheit-orientierten Kommunikation zwischen einem Sender und einem Empfänger, die in Übereinstimmung mit einem vorbestimmten Kommunikationsprotokoll arbeiten, wobei der Sender eine Länge von zu sendenden Daten in eine oder mehrere Dateneinheiten teilt, die einen Aufbau aufweisen, der durch das Protokoll bestimmt ist, der Empfänger den korrekten Empfang der Dateneinheiten durch ein Zurückgeben von Bestätigungsdateneinheiten zu dem Sender bestätigt, die Dateneinheiten von dem Sender in Übereinstimmung mit einer Flusssteuerungsprozedur gesendet werden, die auf der Grundlage eines oder mehrerer adaptiver Parameter und der Bestätigungs-Dateneinheiten durchgeführt wird, und die Flusssteuerungsprozedur einen Datenverlust-Erfassungsmechanismus umfasst, der in der Lage ist, einen Datenverlust in der Kommunikation zu erfassen, wobei der Datenverlust-Erfassungsmechanismus getriggert wird, um den potentiellen Verlust von Daten durch ein oder mehrere vorbestimmte Ereignisse anzuzeigen, wobei im Ansprechen auf das Triggern des Datenverlust-Erfassungsmechanismus eine entsprechende Antwortprozedur (S1, S2, S3, S4, S5, S6, S7) durchgeführt wird, die die erneute Übertragung (S3) einer gegebenen Dateneinheit umfasst, dadurch gekennzeichnet, dass die Antwortprozedur (S1, S2, S3, S4, S5, S6, S7) zumindest zwei unterschiedliche Modi (S6, S7) zum Anpassen des einen oder der mehreren adaptiven Parameter umfasst, und eine Entscheidung (S5) umfasst, welcher der zumindest zwei Modi (S6, S7) zum Anpassen der adaptiven Parameter auszuwählen ist, wobei die Entscheidung (S5) auf der Grundlage einer oder mehrerer Bestätigungsdateneinheiten ausgeführt wird, die von dem Sender empfangen werden, nachdem die gegebene Dateneinheit erneut übertragen worden ist.
Verfahren nach Anspruch 1, wobei der Datenverlust-Erfassungsmechanismus ein Zeitablaufmechanismus ist, derart, dass, nachdem eine gegebene Dateneinheit gesendet worden ist, der Sender eine Zeitablaufperiode überwacht, und wenn keine Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, empfangen wird, bevor die Zeitablaufperiode abläuft, der Zeitablaufmechanismus getriggert wird.
Verfahren nach Anspruch 1, wobei der Datenverlust-Erfassungsmechanismus ein doppelter Bestätigungserfassungsmechanismus ist, derart, dass der Sender die empfangenen Bestätigungen überwacht, und wenn eine Dateneinheit eine vorbestimmte Anzahl von Malen bestätigt ist, der doppelte Bestätigungserfassungsmechanismus getriggert wird.
Verfahren nach Anspruch 2, wobei die Zeitablaufperiode einer der adaptiven Parameter ist.
Verfahren nach einem der Ansprüche 1 bis 4, wobei die Flusssteuerungsprozedur Fenster-basiert ist und ein oder mehrere Flusssteuerfenster unter den adaptiven Parametern sind.
Verfahren nach einem der Ansprüche 1 bis 5, wobei die zumindest zwei Modi aus einem ersten und einem zweiten Modus bestehen, wobei der erste Modus der Beurteilung zugeordnet ist, dass das Triggerereignis durch den Verlust der gegebenen Dateneinheit herbeigeführt wurde, und der zweite Modus der Beurteilung zugeordnet ist, dass die gegebene Dateneinheit oder die Bestätigungsdateneinheit für die gegebene Dateneinheit übermäßig verzögert worden ist.
Verfahren nach Anspruch 6, wobei der Sender Dateneinheiten, die gesendet werden, derart markiert, dass eine ursprüngliche Übertragung von einer erneuten Übertragung unterschieden werden kann, und der Empfänger dementsprechend die Bestätigungsdateneinheiten markiert, derart, dass die Bestätigung einer ursprünglich gesendeten Dateneinheit von der Bestätigung der erneuten Übertragung der Dateneinheit unterschieden werden kann.
Verfahren nach Anspruch 7, wobei der Sender Dateneinheiten markiert, indem ein Zeitstempel in jede gesendete Dateneinheit eingeschlossen wird, wobei der Zeitstempel die Zeit anzeigt, zu der die Dateneinheit gesendet wurde, und der Empfänger die Bestätigungsdateneinheit für eine empfangene Dateneinheit markiert, indem der Zeitstempel, der in der empfangenen Dateneinheit enthalten ist, in die Bestätigungsdateneinheit für die empfangene Dateneinheit eingeschlossen wird.
Verfahren nach Anspruch 7, wobei der Sender Dateneinheiten markiert, indem eine Bitkette in jede gesendete Dateneinheit eingeschlossen wird, wobei die Bitkette zumindest zwei unterschiedliche Werte zum Unterscheiden zwischen einer ursprünglichen Übertragung und einer erneuten Übertragung aufweist, und der Empfänger die Bestätigungsdateneinheit für eine empfangene Dateneinheit markiert, indem die Bitkette, die in der empfangenen Dateneinheit enthalten ist, in die Bestätigungsdateneinheit für die empfangene Dateneinheit eingeschlossen wird.
Verfahren nach Anspruch 9, wobei die Bitkette aus einem einzigen Bit besteht.
Verfahren nach Anspruch 9, wobei die Bitkette aus einer Mehrzahl von Bits besteht, derart, dass die Bitkette in der Lage ist, zwischen unterschiedlichen erneuten Übertragungen zu unterscheiden.
Verfahren nach einem der Ansprüche 9 bis 11, wobei der erste Modus gewählt wird, wenn die erste Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, die empfangen wird, nachdem die gegebene Dateneinheit erneut übertragen worden ist, die erneute Übertragung der gegebenen Dateneinheit bestätigt, und der zweite Modus gewählt wird, wenn die erste Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, die empfangen wird, nachdem die gegebene Dateneinheit erneut übertragen worden ist, die ursprüngliche Übertragung der gegebenen Dateneinheit bestätigt.
Verfahren nach Anspruch 6, wobei der Sender die Rundlaufzeit misst, die der Verbindung zum Senden der Menge von Daten zugeordnet ist, die Zeit zwischen der erneuten Übertragung der gegebenen Dateneinheit und dem Empfang der ersten Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, bestimmt und mit einem Wert verglichen wird, der von einer oder mehreren der Rundlaufzeit-Messungen abgeleitet wird, und der erste oder zweite Modus auf der Grundlage des Ergebnisses des Vergleichs gewählt wird.
Verfahren nach Anspruch 13, wobei der Wert, der von den Rundlaufzeit-Messungen abgeleitet wird, die kürzeste Rundlaufzeit für die Verbindung ist, und der zweite Modus gewählt wird, wenn die Zeit zwischen der erneuten Übertragung der gegebenen Dateneinheit und dem Empfang der ersten Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, kleiner als ein vorbestimmter Teil der kleinsten Rundlaufzeit ist.
Verfahren nach einem der Ansprüche 6 bis 14, wobei der zweite Modus ein Anpassen der Zeitablaufperiode auf der Grundlage der Zeit umfasst, die zwischen der ursprünglichen Übertragung der gegebenen Dateneinheit und dem Empfang der ersten Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, verstrichen ist.
Verfahren nach einem der Ansprüche 6 bis 15, wobei die Flusssteuerungsprozedur Fenster-basiert ist und ein Besetzt-Fenster verwendet wird, wobei der Wert des Besetzt-Fensters zu der Zeit des Triggerereignisses gespeichert wird, nachdem das Trigger-Ereignis aufgetreten ist, und darauf der Wert des Besetzt-Fensters auf einen vorbestimmten Wert zurückgesetzt wird, und wenn der zweite Modus gewählt wird, nachdem die erste Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, empfangen worden ist, der Wert des Besetzt-Fensters auf den Wert gesetzt wird, den er angenommen hätte, wenn die Antwortprozedur nicht stattgefunden hätte.
Kommunikationsvorrichtung für eine Dateneinheitorientierte Kommunikation in Übereinstimmung mit einem vorbestimmten Kommunikationsprotokoll, wobei das Kommunikationsprotokoll vorschreibt, dass der Sender in einer Kommunikation eine Menge von zu sendenden Daten in eine oder mehrere Dateneinheiten teilt, die einen Aufbau aufweisen, der durch das Protokoll bestimmt ist, und der Empfänger in der Kommunikation den korrekten Empfang der Dateneinheiten durch ein Zurückgeben von Bestätigungsdateneinheiten zu dem Sender bestätigt, wobei die Kommunikationsvorrichtung umfasst: eine Einrichtung derart, dass, wenn die Kommunikationsvorrichtung als ein Sender wirkt, diese ausgelegt ist, Dateneinheiten in Übereinstimmung mit einer Flusssteuerungsprozedur zu senden, die auf der Grundlage eines oder mehrerer adaptiver Parameter und der Bestätigungsdateneinheiten durchgeführt wird, wobei die Flusssteuerungsprozedur einen Datenverlust-Erfassungsmechanismus umfasst, der in der Lage ist, einen Datenverlust in der Kommunikation zu erfassen, wobei der Datenverlust-Erfassungsmechanismus getriggert wird, um den potentiellen Verlust von Daten durch ein oder mehrere vorbestimmte Ereignisse anzuzeigen, wobei im Ansprechen auf das Triggern des Datenverlust-Erfassungsmechanismus eine entsprechende Antwortprozedur durchgeführt wird, die die erneute Übertragung einer gegebenen Dateneinheit umfasst, dadurch gekennzeichnet, dass die Kommunikationsvorrichtung derart ausgelegt ist, dass die Antwortprozedur (S1, S2, S3, S4, S5, S6, S7) zumindest zwei unterschiedliche Modi zum Anpassen des einen oder der mehreren adaptiven Parameter umfasst und eine Entscheidung (S5) umfasst, welcher der zumindest zwei Modi (S6, S7) zum Anpassen der adaptiven Parameter gewählt wird, wobei die Entscheidung (S5) auf der Grundlage der einen oder mehreren Bestätigungsdateneinheiten ausgeführt wird, die von dem Sender empfangen werden, nachdem die gegebene Dateneinheit erneut übertragen worden ist.
Vorrichtung nach Anspruch 17, wobei der Datenverlust-Erfassungsmechanismus ein Zeitablaufmechanismus ist, derart, dass, nachdem eine gegebene Dateneinheit gesendet ist, der Sender ausgelegt ist, eine Zeitablaufperiode zu überwachen, und wenn keine Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, empfangen wird, bevor die Zeitablaufperiode verstreicht, der Zeitablaufmechanismus getriggert wird.
Vorrichtung nach Anspruch 17, wobei der Datenverlust-Erfassungsmechanismus ein doppelter Bestätigungs-Erfassungsmechanismus ist, derart, dass der Sender ausgelegt ist, die empfangenen Bestätigungen zu überwachen, und wenn eine Dateneinheit eine vorbestimmte Anzahl von Malen bestätigt ist, der doppelte Bestätigungs-Erfassungsmechanismus getriggert wird.
Vorrichtung nach Anspruch 18, wobei die Zeitablaufperiode einer der adaptiven Parameter ist.
Vorrichtung nach einem der Ansprüche 17 bis 20, wobei die Flusssteuerungsprozedur Fenster-basiert ist, und ein oder mehrere Flusssteuerungsfenster unter den adaptiven Parametern sind.
Vorrichtung nach einem der Ansprüche 17 bis 21, wobei die zumindest zwei Modi aus einem ersten und einem zweiten Modus bestehen, wobei der erste Modus der Beurteilung zugeordnet ist, dass das Triggerereignis durch den Verlust der gegebenen Dateneinheit herbeigeführt wurde, und der zweite Modus der Beurteilung zugeordnet ist, dass die gegebene Dateneinheit oder die Bestätigungsdateneinheit für die gegebene Dateneinheit übermäßig verzögert worden ist.
Vorrichtung nach Anspruch 22, wobei die Vorrichtung, wenn sie als ein Sender wirkt, ausgelegt ist, Dateneinheiten, die gesendet werden, derart zu markieren, dass eine ursprüngliche Übertragung von einer erneuten Übertragung unterschieden werden kann, und die Vorrichtung, wenn sie als ein Empfänger wirkt, ausgelegt ist, die Bestätigungsdateneinheiten entsprechend zu markieren, derart, dass die Bestätigung einer ursprünglich gesendeten Dateneinheit von der Bestätigung der erneuten Übertragung der Dateneinheit unterschieden werden kann.
Vorrichtung nach Anspruch 23, wobei die Vorrichtung, wenn sie als ein Sender wirkt, ausgelegt ist, Dateneinheiten zu markieren, indem ein Zeitstempel in jede gesendete Dateneinheit eingeschlossen wird, wobei der Zeitstempel die Zeit anzeigt, zu der die Dateneinheit gesendet wurde, und die Vorrichtung, wenn sie als ein Empfänger wirkt, ausgelegt ist, die Bestätigungsdateneinheit für eine empfangene Dateneinheit zu markieren, indem der Zeitstempel, der in der empfangenen Dateneinheit enthalten ist, in die Bestätigungsdateneinheit für die empfangene Dateneinheit eingeschlossen wird.
Vorrichtung nach Anspruch 23, wobei die Vorrichtung, wenn sie als ein Sender wirkt, ausgelegt ist, Dateneinheiten zu markieren, indem eine Bitkette in jede gesendeten Dateneinheit eingeschlossen wird, wobei die Bitkette zumindest zwei unterschiedliche Werte zum Unterscheiden zwischen einer ursprünglichen Übertragung und einer erneuten Übertragung aufweist, und die Vorrichtung, wenn sie als ein Empfänger wirkt, ausgelegt ist, die Bestätigungsdateneinheit für eine empfangene Dateneinheit zu markieren, indem die Bitkette, die in der empfangenen Dateneinheit enthalten ist, in die Bestätigungsdateneinheit für die empfangene Dateneinheit eingeschlossen wird.
Vorrichtung nach Anspruch 24 oder 25, derart ausgelegt, dass der erste Modus gewählt wird, wenn die erste Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, die empfangen wird, nachdem die gegebene Dateneinheit erneut übertragen worden ist, die erneute Übertragung der gegebenen Dateneinheit bestätigt, und der zweite Modus gewählt wird, wenn die erste Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, die empfangen wird, nachdem die gegebene Dateneinheit erneut übertragen worden ist, die ursprüngliche Übertragung der gegebenen Dateneinheit bestätigt.
Vorrichtung nach Anspruch 22, wobei die Vorrichtung, wenn sie als ein Sender wirkt, ausgelegt ist, die Rundlaufzeit zu messen, die der Verbindung zum Senden der Menge von Daten zugeordnet ist, um die Zeit zwischen der erneuten Übertragung der gegebenen Dateneinheit und dem Empfang der ersten Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, zu bestimmen und mit einem Wert zu vergleichen, der von einer oder mehreren der Rundlaufzeit-Messungen abgeleitet ist, und um den ersten oder zweiten Modus auf der Grundlage des Ergebnisses des Vergleichs zu wählen.
Vorrichtung nach Anspruch 27, wobei der Wert, der von den Rundlaufzeit-Messungen abgeleitet wird, die kürzeste Rundlaufzeit für die Verbindung ist, und die Vorrichtung ausgelegt ist, den zweiten Modus zu wählen, wenn die Zeit zwischen der erneuten Übertragung der gegebenen Dateneinheit und dem Empfang der ersten Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, kleiner als ein vorbestimmter Teil der kleinsten Rundlaufzeit ist.
Vorrichtung nach einem der Ansprüche 22 bis 28, wobei der zweite Modus ein Anpassen der Zeitablaufperiode auf der Grundlage der Zeit umfasst, die zwischen der ursprünglichen Übertragung der gegebenen Dateneinheit und dem Empfang der ersten Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, verstrichen ist.
Vorrichtung nach einem der Ansprüche 22 bis 29, wobei die Flusssteuerungsprozedur Fenster-basiert ist und ein Besetzt-Fenster verwendet wird, wobei der Wert des Besetzt-Fensters zu der Zeit des Trigger-Ereignisses gespeichert wird, nachdem das Trigger-Ereignis aufgetreten ist, und darauf der Wert des Besetzt-Fensters auf einen vorbestimmten Wert zurückgesetzt wird, und wenn der zweite Modus gewählt ist, nachdem die erste Bestätigungsdateneinheit, die der gegebenen Dateneinheit zugeordnet ist, empfangen worden ist, der Wert des Besetzt-Fensters auf den Wert gesetzt wird, den er angenommen hätte, wenn die Antwortprozedur nicht stattgefunden hätte.