DE60109959T2 - Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen - Google Patents

Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen Download PDF

Info

Publication number
DE60109959T2
DE60109959T2 DE60109959T DE60109959T DE60109959T2 DE 60109959 T2 DE60109959 T2 DE 60109959T2 DE 60109959 T DE60109959 T DE 60109959T DE 60109959 T DE60109959 T DE 60109959T DE 60109959 T2 DE60109959 T2 DE 60109959T2
Authority
DE
Germany
Prior art keywords
enhancer
data
links
downstream
upstream
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
DE60109959T
Other languages
English (en)
Other versions
DE60109959D1 (de
Inventor
Robert Bitterne Park HANCOCK
Mark Alan North Baddesley WEST
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.)
Roke Manor Research Ltd
Original Assignee
Roke Manor Research Ltd
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 Roke Manor Research Ltd filed Critical Roke Manor Research Ltd
Publication of DE60109959D1 publication Critical patent/DE60109959D1/de
Application granted granted Critical
Publication of DE60109959T2 publication Critical patent/DE60109959T2/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
    • 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]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • 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
    • 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/165Combined use of TCP and UDP protocols; selection criteria therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/0864Round trip delays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Selective Calling Equipment (AREA)

Description

  • Die vorliegende Erfindung betrifft Kommunikationssysteme im Allgemeinen und kann insbesondere für Kommunikationssysteme angewendet werden, die eine Vielzahl von Übertragungsstrecken aufweisen, wobei eine Übertragungsstrecke im Hinblick auf den Datenfluss wesentlich langsamer ist als andere Übertragungsstrecken.
  • Um den Datenfluss und seine Steuerung in herkömmlichen Systemen zu veranschaulichen, zeigt 1 eine schematische Darstellung des Kommunikationssystems. Die Einheit 1, welche als der Absender (von Informationen) bezeichnet werden kann, stellt eine Quelle von zu übertragenden Daten dar und kann zum Beispiel das Internet sein. Sie besitzt eine Draht-Übertragungsstrecke 2 mit einer drahtlosen Basisstation 3. Diese drahtlose Basisstation kommuniziert über Funkstrecken 4 mit Einheiten A, B, C, bei denen es sich in der Praxis um eine Anzahl von Mobiltelefonen handeln kann.
  • Bei einem bekannten System mit einer herkömmlichen Betriebsweise sendet die Einheit 1 ein Datenpaket unter Verwendung des standardmäßigen Transmission Control Protocols (TCP, Übertragungssteuerungsprotokolls) an die drahtlose Basisstation. Beim TCP-System sendet die drahtlose Basisstation 3 eine Quittung an den Absender, mit der sie bestätigt, dass sie das Datenpaket empfangen hat, und der Absender (oder Server) verdoppelt daraufhin die Datenübertragungsgeschwindigkeit und sendet zwei Datenpakete. Nachdem er eine Quittung empfangen hat, dass die Basisstation diese zwei Datenpakete empfangen hat, verdoppelt er erneut die Datenübertragungsgeschwindigkeit und sendet vier Datenpakete. Dieser Prozess setzt sich fort, bis eine maximale Transfergeschwindigkeit erreicht ist. Die Funktion der Basisstation besteht darin, die Daten zu Mobiltelefonen weiterzuleiten. Da diese zweite Übertragungsstrecke eine Funkstrecke ist, ist die Datenübertragungsgeschwindigkeit wesentlich niedriger als die der ersten Übertragungsstrecke, d. h. sie besitzt eine begrenzte Bandbreite. Da die drahtlose Basisstation über einen begrenzten Pufferspeicherplatz verfügt und ankommende Daten bearbeiten und quittieren muss sowie weitergeleitete Datenpakete steuern und absenden muss, treten Fehler auf, wie etwa ein Verlust von Datenpaketen. Bei Verwendung des TCP wird ein Verlust von Datenpaketen durch unterschiedliche Mechanismen erkannt, wie etwa daran, dass für ein bestimmtes Datenpaket nicht innerhalb einer vorgegebenen Zeit eine Quittung empfangen wird, oder daran, dass die nummerierten Datenpakete nicht in der erforderlichen Reihenfolge ankommen. In den letzteren Fällen sendet die Basisstation zum Beispiel das Duplikat der Anforderung (oder eine wiederholte Anforderung) für das Datenpaket Nr. 3, falls nach dem Datenpaket Nr. 2 die Datenpakete Nr. 4 und 5 usw. kommen sollten. Wenn der Server einen Verlust von Datenpaketen erkennt, sendet er die verloren gegangenen Daten nochmals und nimmt an, dass er die Daten zu schnell sendet. Infolgedessen halbiert er daraufhin die Datenübertragungsgeschwindigkeit. Erneute Verluste von Datenpaketen bewirken dann eine nochmalige Halbierung der Datenübertragungsgeschwindigkeit und haben schließlich eine sukzessive Verlangsamung der Übertragung (Meltdown) zur Folge. Infolgedessen kann der Server nichts anderes mehr tun, und die Geschwindigkeit des Datenflusses wird stark verlangsamt, und es wird Zeit benötigt, um die Datenübertragungsgeschwindigkeit wieder allmählich zu erhöhen.
  • Kurz gesagt, implementiert TCP daher eine Reihe von Algorithmen unter der allgemeinen Überschrift "Stauvermeidung" (Congestion Avoidance). Diese sind dazu bestimmt, TCP "reaktionsfähig" auf Staus im Netz zu machen und seine Sendegeschwindigkeit so zu steuern, dass ein Verursachen eines "Stau-Kollapses" vermieden wird. Dies ist im Internet eine sehr reale Gefahr, und daher sind die Algorithmen wesentlich. Die wichtigen Aspekte der Stauvermeidung sind folgende:
    • – Slowstart (langsamer Start) – eine exponentielle Erhöhung der TCP-Sendegeschwindigkeit. Ein Slowstart wird durchgeführt: bei jeder neuen Verbindung; nachdem eine Verbindung eine gewisse Zeit inaktiv war; und nachdem ein Übertragungswiederholungs-Timeout erfolgt ist.
    • – Fast-retransmit/recovery (schnelle Übertragungswiederholung/Wiederherstellung) – weggelassene Datenpakete können durch wiederholte Quittungen erkannt werden. Wenn dies geschieht, wird die aktuelle Sendegeschwindigkeit effektiv halbiert und erhöht sich danach linear.
  • Kurz gesagt, sind die Umgebung des drahtlosen Zugangs und andere Kommunikationsszenarien daher mit einer Reihe von Bedingungen verknüpft, welche die Erzielung einer hohen Leistung von Übertragungen unter Verwendung des TCP erschweren, wie begrenzte Bandbreite, variable Bandbreite, lange Latenzzeiten sowie eventuell länger andauernde Unterbrechungen.
  • In der folgenden Dokumentenliste sind Entwürfe von Protokollen aufgeführt, welche dazu bestimmt sind, die Funktionsweise von Mobilfunksystemen, Internet und anderen derartigen Systemen zu verbessern:
    • • HAAS Z J ET AL: "Mobile-TCP: an asymmetric transport protocol design for mobile systems" (Mobile-TCP: ein Entwurf eines asymmetrischen Transportprotokolls für Mobilfunksysteme), COMMUNICATIONS, 1997. ICC '97 MONTREAL, TOWARDS THE KNOWLEDGE MILLENIUM. 1997 IEEE INTERNATIONAL CONFERENCE ON MONTREAL, QUE., CANADA 8.–12. JUNI 1997, NEW YORK, NY, USA, IEEE, US, 8. JUNI 1997 (1997-06-08), Seiten 1054–1058. XP010227263 ISBN: 0-07803-3925-8
    • • KUANG-YEH WANG ET AL: "Mobile-end transport protocol: an alternative to TCP/IP over wireless links" (Mobile-end Transportprotokoll: eine Alternative zu TCP/IP über drahtlose Übertragungsstrecken), INFOCOM '98. SEVENTEENTH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETIES. PROCEEDINGS. IEEE SAN FRANCISCO, CA, USA 29. MÄRZ – 2. APRIL 1998, NEW YORK, NY, USA, IEEE, US, 29. März 1998 (1998-03-29), Seiten 1046–1053, XCP010270379 ISBM: 0-7803-4383-2
    • • BALAKRISHNAN H ET AL: "IMPROVING TCP/IP PERFORMANCE OVER WIRELESS NETWORKS" (VERBESSERUNG DER LEISTUNG VON TCP/IP IN DRAHTLOSEN NETZEN), MOBICOM, PROCEEDINGS OF THE ANNUAL INTERNATIONAL CONFERENCE ON MOBILE COMPUTING AND NETWORKING, XX, XX, November 1995 (1995-11), Seite ERGÄNZEN XP002920962
    • • AJAY BAKRE ET AL: "I-TCP: INDIRECT TCP FOR MOBILE HOSTS" (I-TCP: INDIREKTES TCP FÜR MOBILE HOSTS), PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS. VANCOUVER, 30. MAI – 2. JUNI 1995, LOS ALAMITOS, IEEE COMP. SOC. PRESS, US, Bd. CONF. 15, 30. Mai 1995 (1995-05-30), Seiten 136–143, XP000530804 ISBM: 0-7803-2963-5
    • • YAVATKAR R ET AL: "IMPROVING END-TO-END PERFORMANCE OF TCP OVER MOBILE INTERNETWORKS" (VERBESSERUNG DER ENDE-ENDE-LEISTUNG VON TCP IN MOBILFUNK-VERBINDUNGSNETZEN), PROCEEDINGS, WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS, IEEE COMPUTER SOCIETY PRESS, LOS ALAMITOS, CAR, US, 8. Dezember 1994 (1994-12-08), Seiten 146–152, XP0002062284
    • • Internationales Patent WO 00 151372 A (3COM CORP) 31. August 2000 (2000-08-31)
  • Eine Aufgabe der Erfindung ist es, Paketverlust-Ereignisse zu begrenzen und zu verhindern und den Datenfluss so zu verwalten, dass Übertragungsquellen auf eine ausgewogene Art und Weise optimal genutzt werden und die Möglichkeit eines Überlauf der verfügbaren Puffer-Ressourcen verringert wird und somit die Gesamteffizienz des Systems erhöht wird.
  • Die Erfindung besteht in einem Verfahren und einem System nach Anspruch 1 und 6.
  • Indem der Enhancer (Verbesserungseinheit) Daten gleichmäßiger und besser steuerbar sendet, sowie mit einer Geschwindigkeit, bei der die auf der Downstream-Seite (netzabwärts) befindlichen Einheiten arbeiten können, kann der Verlust von Datenpaketen auf ein Minimum begrenzt oder vermieden werden. Außerdem kann der Enhancer auf optimale Weise von schnellen Übertragungsstrecken Gebrauch machen, wie es gewöhnlich die Übertragungsstrecke zwischen Absender und Enhancer sein würde. Der Enhancer kann schnell Quittungen an den Absender senden, dass er Daten empfangen oder nicht empfangen hat, ohne dass der Absender darauf warten muss, dass auf der Downstream-Seite befindliche Einheiten (mit langsameren Übertragungsstrecken) Quittungen zurücksenden. Bei Systemen, die den bisherigen Stand der Technik verkörpern, hat der Absender möglicherweise viele Datenpakete während der Zeit ausgesendet, nach welcher Überlast und Datenverlust aufgetreten sind, was eine Zeitverschwendung wäre.
  • Durch diese Maßnahme werden Flusssteuerung und Stau-Management nicht mehr durchgehend von Ende zu Ende durchgeführt, wie es beim gewöhnlichen TCP geschehen würde. Dies ist wichtig, weil die drahtlose Übertragungsstrecke charakteristische Eigenschaften aufweist, die sich sehr von denen der anderen, terrestrischen Abschnitte unterscheiden, welche die Pakete benutzen werden. Indem er die Verbindung aufspaltet, anstatt einfach als Router zu wirken, kann der Enhancer den Zugriff auf die drahtlose Ressource steuern, ohne Pakete weglassen zu müssen. Dies ist ein wesentlicher Vorteil gegenüber einem einen Engpass darstellenden Router, welcher, wenn er mit Daten "überschwemmt" wird, Pakete aussondern müsste.
  • Ein wichtiger Punkt, der für die Verwendung asymmetrischer Enhancer gemäß der Erfindung spricht, besteht darin, dass, sobald ein Paket die Schnittstelle mit der drahtlosen Übertragungsstrecke erreicht hat, die Daten über eine Punkt-zu-Punkt-Übertragungsstrecke zur Mobilstation übertragen werden. Diese Übertragungsstrecke wird nicht gemeinsam genutzt, und auf ihr kann kein Stau auftreten. Es ist außerdem wichtig anzumerken, dass das mit dem Mobiltelefon verknüpfte Netz ein "Stichleitungs"-Netz ist. Das heißt, es existieren keine darüber hinausreichenden Netze, in denen ein Routing hierüber erfolgt. Aufgrund dieser Punkte dürfte ersichtlich sein, dass keine Stau-Steuerungsmechanismen erforderlich sind, nachdem die drahtlose Übertragungsstrecke erreicht worden ist. Dies ist die Art und Weise, wie die Verbesserung erzielt wird. Die Verbindung wird am Enhancer aufgespalten. Ein TCP-Fluss, welcher zurück in das Internet regeneriert wird, bleibt ein standardmäßiger, reaktionsfähiger TCP-Fluss. Bei einem TCP-Fluss, welcher zu einem Mobiltelefon hin regeneriert wird, ist jedoch der Stauvermeidungsmechanismus entfernt. Auf diese Weise ist das vom Enhancer verwendete Protokoll vollständig mit dem Host kompatibel, der mit der Mobilstation verknüpft ist – sämtliche Datagramme entsprechen vollkommen dem Standard TCP/IP. Die Leistung wird verbessert, weil Stauvermeidung nicht auf einer Übertragungsstrecke ausgeführt wird, für die sie unangebracht ist.
  • Die Luftschnittstelle, die für die Kommunikation mit den Mobilstationen verwendet wird, besitzt eine feste maximale Kapazität. Die Ist-Geschwindigkeit, mit welcher Benutzerdaten über die Übertragungsstrecke übertragen werden können, hängt jedoch von der Fehlerrate der Übertragungsstrecke und der Aufteilung zwischen Aufwärtsstrecke und Abwärtsstrecke ab.
  • Da die Verbindung am Enhancer aufgespalten wird, ist es möglich, nicht nur die Stauvermeidung anzupassen, sondern auch die Rückübertragungsstrategie zwischen dem Enhancer und einem mobilen Host. Auch in diesem Falle unterscheiden sich die charakteristischen Eigenschaften der Übertragungsstrecke genügend stark von denen einer drahtgebundenen Internet-Verbindung, so dass dies eine nützliche Maßnahme darstellt.
  • Die Erfindung wird im Folgenden anhand eines Beispiels und unter Bezugnahme auf die beigefügten Abbildungen beschrieben, wobei:
  • 1 eine einfache schematische Darstellung eines Systems nach dem bisherigen Stand der Technik zeigt;
  • 2 eine sehr einfache Ausführung der Erfindung in Anwendung auf das System von 1 zeigt, welche einen Enhancer umfasst;
  • 3 eine Ausführung des Systems zeigt, bei welcher die Zunahme der zu Einheiten auf der Downstream-Seite übertragenen Daten von dem Enhancer überwacht wird.
  • 4 zeigt die physikalische Darstellung einer weiteren Ausführungsform der Erfindung, bei welcher eine Übertragungsstrecke mit drei Verbindungen vorhanden ist.
  • 5 zeigt eine weitere Ausführungsform der Erfindung, bei welcher die Menge der nicht quittierten netzabwärts gesendeten Daten überwacht werden kann.
  • 6 zeigt eine Ausführungsform der Erfindung, welche ein Beispiel für die Software-Architektur des Enhancers darstellt.
  • 2 zeigt eine einfache Ausführung der Erfindung, die im Wesentlichen dieselben Merkmale wie in 1 umfasst, wobei jedoch zusätzlich ein Enhancer 6 eingefügt ist, der zwischen dem Internet-Server und der drahtlosen Basisstation angeordnet ist. Der Enhancer teilt oder trennt praktisch das Kommunikationssystem in zwei Hälften und bewirkt, dass Probleme, die auf einer Seite des Enhancers auftreten, sich nicht auf die Funktionsweise auf der anderen Seite auswirken. Die Aufspaltung der Verbindung ist der Hauptmechanismus, um eine Verbesserung der Leistungsfähigkeit des TCP möglich zu machen. Anstatt zu ermöglichen, dass die TCP-Verbindung wie gewöhnlich durchgehend von Ende zu Ende besteht, wird die Verbindung in Abschnitte aufgeteilt. Der Enhancer beendet eine TCP-Verbindung an einer Schnittstelle und erzeugt sie an einer anderen neu (regeneriert sie). Die Verbindungsaufspaltung erfolgt mittels einer Methode, die in der Technik als "Spoofing" (Vortäuschung) bezeichnet wird, wobei der Enhancer eine Quittung an den Absender "fälscht", mit der er sagt "Ich bin die drahtlose Basisstation", so dass, soweit es den Absender betrifft, die Verbindung am Enhancer beendet ist. Der Enhancer wirkt mit den dahinter (netzabwärts) angeordneten Systemen und Einheiten auf eine solche Weise zusammen, dass er an sie Daten auf eine geregeltere, aggressivere und somit effizientere Art und Weise sendet, auf eine adaptive Weise unter Nutzung von Kenntnissen darüber, wie die netzabwärts angeordneten Systeme funktionieren. Anders ausgedrückt, der Enhancer verschafft sich ein Maß dafür, wie gut die netzabwärts angeordneten Einheiten arbeiten bzw. wie "verstopft" die netzabwärts angeordneten Systeme sind; und er sendet Daten regulierbar und so, dass er den netzabwärts angeordneten Einheiten nicht mehr liefert, als sie verkraften können, und so, dass kein Verlust von Datenpaketen auftritt.
  • Ein Weg, wie dies implementiert werden kann, besteht darin, dass der Enhancer für die Kommunikation mit den netzabwärts angeordneten Einheiten ein modifiziertes TCP verwendet, welches mit den Übertragungsstrecken kompatibel ist, gleichzeitig jedoch adaptiv arbeitet. Der Begriff "adaptiv" bedeutet hierbei, dass sich das TCP so anpassen lässt, dass dessen Funktionsweise von der Art der Übertragungsstrecke und der Einheiten, d. h. von den netzabwärts angeordneten Systemen und deren Funktionsweise, abhängt.
  • Es gibt viele Wege, wie sich der Enhancer ein Maß dafür verschaffen kann, wie die netzabwärts angeordneten Einheiten zurzeit arbeiten. Im Allgemeinen kann der Enhancer nicht nur Kenntnisse über den Typ der netzabwärts von ihm angeordneten Übertragungsstrecken und Systeme verwenden, wie etwa darüber, ob es sich um Mobiltelefon-Übertragungsstrecken handelt, sondern er kann sich auch auf verschiedene Weise Rückmeldungen verschaffen, um Informationen darüber zu erhalten, wie diese netzabwärts angeordneten Systeme funktionieren, und um die Datenübertragungsgeschwindigkeit zu diesen Systemen dementsprechend zu steuern.
  • Die effektive Aufspaltung des Systems durch den Enhancer bedeutet außerdem, dass er, da er vortäuscht, die netzabwärts angeordneten Systeme zu sein, mit dem Server kommunizieren kann, um an diesen eine frühzeitige Rückmeldung von Quittungen zu senden, da er nicht darauf warten muss, dass Quittungen von den weiter netzabwärts angeordneten Systemen kommen, was aufgrund der Entfernung des Netzes und der Langsamkeit der netzabwärts befindlichen Übertragungsstrecken gewöhnlich länger dauert. Dank der schnellen Übertragungsstrecke zwischen dem Enhancer und dem Server können eventuell verloren gegangene Pakete somit schnell bestätigt und nochmals übertragen werden. Eine solche schnelle Kommunikation, bei der man nicht auf eine Quittung von der Downstream-Seite angewiesen ist, hat eine bessere Ausnutzung und höhere Effizienz dieser Übertragungsstrecke zur Folge und ermöglicht folglich hohe Datenübertragungsgeschwindigkeiten vom Server zum Enhancer.
  • Der Enhancer muss einen Puffer enthalten; dieser muss jedoch nicht so groß sein, wie man zunächst annehmen könnte, da der Enhancer, wie bereits erwähnt, die Datenübertragungsgeschwindigkeit weiter gesendeter Datenpakete durch intelligente, effiziente Steuerung derselben wie oben beschrieben erhöhen kann.
  • Im Folgenden werden Beispiele angegeben, wie der Enhancer an die jeweilige Betriebsart der auf der Downstream-Seite angeordneten Systeme angepasst werden kann.
  • Beispiel 1. Messung der Umlaufzeit
  • 3 zeigt eine schematische Zeichnung eines Kommunikationssystems zur Veranschaulichung dieser Ausführungsform. Auch in diesem Falle ist die Abbildung den vorhergehenden Abbildungen ähnlich, zeigt jedoch zusätzlich den Puffer einer drahtlosen Basisstation. Die Funkstrecke zur Station würde eine feste Kapazität haben, d. h. es würde eine feste Pufferkapazität von beispielsweise 64 KByte vorliegen. Die Funkstation übermittelt Daten über eine Funkstrecke an einen oder mehrere Hosts, z. B. an Mobiltelefone. Die Daten, welche in der Form von Datenpaketen 7 zum mobilen Host gesendet werden, bewirken, dass eine Quittung 8 zurück zum Enhancer gesendet wird. Diese Quittungen werden entweder umgehend beim Empfang eines Pakets gesendet, oder unter gewissen Umständen nach einer kurzen Verzögerung (normalerweise in der Größenordnung von 200 ms). Falls die Geschwindigkeit, mit der die Pakete an den Host gesendet werden, kleiner als die verfügbare Bandbreite bleibt, wird sich niemals mehr als 1 Datenpaket im Puffer befinden, und die Umlaufzeit ist dann relativ gleich bleibend. Die Umlaufzeit ist als die Zeit zwischen dem Absenden eines Datenpakets und dem Empfang einer Quittung definiert. Wenn sich die Geschwindigkeit des Sendens über die verfügbare Bandbreite hinaus erhöht, beginnt sich der Puffer zu füllen, was schließlich zu einem Pufferüberlauf führen könnte. Der Puffer entleert sich außerdem mit der Geschwindigkeit, die durch die verfügbare Bandbreite bestimmt wird. Dies bewirkt, dass sich die Umlaufzeit zu erhöhen scheint. Dies setzt sich ständig fort, bis die Sendegeschwindigkeit zu hoch ist und der Puffer sich füllt und es zu einem Verlust von Datenpaketen kommt.
  • Der Enhancer verwendet die Messung der Umlaufzeit (unter der Annahme, dass der Puffer eine angemessene Größe hat) für Rückschlüsse darauf, in welchem Grade die Übertragungsstrecke überlastet ist, und um die Datenübertragungsgeschwindigkeit entsprechend zu verlangsamen. Somit kann der Enhancer die Übertragungsgeschwindigkeit bei einer Erhöhung der Umlaufzeit dynamisch anpassen.
  • Beispiel 2. Gesamtüberwachung
  • Bei vielen Protokollen wie etwa TCP wird ein "Gleitfenster" als wirksames Mittel zur Flusssteuerung verwendet. Das Fenster ist die maximale Datenmenge, welche ein Sender ausgeben kann, ohne eine Quittung zu empfangen, was eine nützliche Methode darstellt, um die Fähigkeit eines Systems einzuschränken, ein auf der Downstream-Seite befindliches Netz zu "überfluten". Somit kann man, wenn man die Größe der Datenpakete, die Größe des Puffers auf der Downstream-Seite und die Anzahl der nicht quittierten Pakete kennt, eine entsprechende Verlangsamung vornehmen, um sicherzustellen, dass kein Pufferüberlauf eintritt. Es ist wichtig, dass das Fenster genügend groß ist, um das Maximum zu unterstützen. Normalerweise wird das Fenster entsprechend dem Produkt von Verzögerung und Bandbreite der Übertragungsstrecke bemessen.
  • Ein hierbei auftretendes Problem besteht darin, dass diese Bemessung der Größe für jede Übertragungsstrecke durchgeführt wird, wobei eine Übertragungsstrecke jeweils zwischen zwei Einheiten definiert ist. Falls mehrere gleichzeitige Verbindungen auf einer Übertragungsstrecke vorhanden sind, hat dies zur Folge, dass die effektive Fenstergröße vervielfacht wird, was sich als ein Problem im Hinblick auf die Steuerung der Pufferverwendung erweisen kann und zu Arbitrierungs- und Synchronisationseffekten von Bursty Networks (Netzen mit ruckartigem Verkehr) führen kann.
  • Bei einer Ausführungsform der Erfindung wird dieses Problem durch die Verwendung eines kombinierten Fensters überwunden, wobei jede Verbindung wie üblich ihr eigenes Fenster verwendet, jedoch ein Gesamtfenster für alle Verbindungen angewendet wird. Dies ist in
  • 4 dargestellt. Zwischen dem Enhancer und dem Ziel sind mehrere Verbindungen in Betrieb, im Beispiel drei Verbindungen, welche gleichzeitig betrieben werden. Falls jede Verbindung zum Beispiel eine Fenstergröße von 10 KB ermöglicht, jedoch der Puffer am Endziel nur 20 KB hat, tritt dann ein Überlauf des Puffers ein. Um einen solchen Datenverlust zu vermeiden und somit das wiederholte Senden auf ein Minimum zu begrenzen, ist die Steuerung des Enhancers so beschaffen, dass er nur dann Daten auf einer bestimmten Verbindung einer Übertragungsstrecke ausgeben kann, wenn das Fenster der betreffenden Verbindung nicht voll ist UND das Gesamtfenster nicht voll ist. Anders ausgedrückt, der Enhancer summiert die Anzahlen der nicht quittierten Datenpakete für die einzelnen Verbindungen auf und stellt sicher, dass, falls die Summe oder Gesamtmenge größer als ein vorgegebener Wert ist, keine weiteren Daten an die Einheit gesendet werden.
  • Beispiel 3. Überwachung der Summengeschwindigkeit
  • Im Folgenden wird noch eine weitere Möglichkeit beschrieben, wie der Enhancer quantitative Messwerte für den netzabwärts gerichteten Datenfluss erhalten kann. Oft ist auf einem Übermittlungsabschnitt, zum Beispiel zu einer Basisstation, der Datenfluss von einem Server von einem gemischten Typ; es können Datenpakete unterschiedlicher Art vorhanden sein. Beispielsweise sind manche Datenpakete, wie etwa Audio- oder Video-Datenpakete, nicht quittierte Datenpakete (Unacknowledged Data Packets, UDP), das heißt, wenn sie von einer Einheit empfangen wurden, wird keine Quittung an den Absender gesendet. In diesen Fällen hat es, wenn UDP verloren gehen, keinen Sinn, sie nochmals zu senden, da diese Datenpakete gleichmäßig, d. h. in einer bestimmten Reihenfolge gesendet werden müssen. Der Verlust eines Datenpakets ist nicht so kritisch und verursacht lediglich einen kurzzeitigen Aussetzer in einem Video- oder Audiosignal.
  • Bei einer solchen gemischten Datenübertragung tritt ein Problem auf, welches darin besteht, dass der Enhancer keine Informationen empfängt, die den Fortschritt der Übertragung der UDPs betreffen, da die UDPs nicht quittiert werden und dem Enhancer somit nicht bekannt ist, ob sie angekommen oder verloren gegangen sind. Die Erfinder haben eine innovative Methode bereitgestellt, wie es dem Enhancer ermöglicht werden kann zu bestimmen, wie es den UDPs ergeht, indem die Tatsache ausgenutzt wird, dass alle Datenpakete, sowohl die quittierten als auch die nicht quittierten, in einer Folge abgesendet werden, in der sie unmittelbar aneinander angrenzen. Indem die nicht quittierten Pakete an quittierte Pakete "angehängt" werden, ist es möglich zu bestimmen, ob die UDPs angekommen sind. Dies ist in 5 dargestellt. Diese zeigt einen Datenfluss zwischen dem Enhancer und einer netzabwärts angeordneten Einheit. Der Datenstrom umfasst Pakete, die gemäß dem TCP-Protokoll zu quittieren sind (mit TCP bezeichnet), sowie nicht quittierte Pakete (mit UDP bezeichnet). Wenn ein Datenpaket TCP1 ohne Fehler verarbeitet und gespeichert oder weitergesendet worden ist, wird eine Quittung Ac1 gesendet. Wenn ein Datenpaket UDP1 eintrifft, wird, selbst wenn es ohne Fehler gespeichert oder weitergesendet worden ist, keine Quittung gesendet. Wenn jedoch das Datenpaket TCP2 ohne Fehler korrekt gespeichert oder weitergesendet worden ist, verwendet der Enhancer dies, um anzunehmen, dass das Paket UDP1 korrekt und ohne Fehler gespeichert worden ist. Somit liefert dies dem Enhancer Informationen über die noch nicht eingetroffenen Daten, darüber, wie viel Pufferplatz belegt worden ist und welche Datenübertragungsgeschwindigkeit vorliegt, und kann somit in Verbindung mit jeder beliebigen der obigen Methoden verwendet werden.
  • Software-Architektur
  • 6 zeigt in schematischer Darstellung ein Beispiel für die Software-Architektur einer Ausführungsform des Enhancers. Die Übertragungsstrecke zu "Host B [Mobilseite]" verläuft nicht direkt zum Mobiltelefon. Diese Übertragungsstrecke transportiert die Pakete zum drahtlosen Zugangspunkt oder Steuergerät (im Weiteren als das "SG" bezeichnet).
  • Zwei TCP-Stapel, die mittels des Spoofers verbunden sind, befinden sich über einem einzelnen IP-Stapel, welcher seinerseits über der Ethernet-Schicht angeordnet ist. Der Begrenzungsmodul schätzt den Füllzustand der SG-Puffer und schaltet den Datentransfer aus, vom äußeren zum inneren TCP-Stapel, wenn der Puffer als zu voll eingeschätzt wird. Außerdem ist ein Weighted Fair Queuing Modul (WFQ-Modul, Modul für gewichtete faire Warteschlangenbildung) vorhanden, welcher die maximale Gesamt-Datenübertragungsgeschwindigkeit vom äußeren zum inneren Stapel steuert.
  • Das SG weist mehrere Puffer auf (pro Mobiltelefon einen). Wenn Daten mit einer zu hohen Geschwindigkeit zum SG gesendet werden, könnten diese Puffer überlaufen und einen Verlust von Datenpaketen verursachen. Diese Pakete müssten dann erneut gesendet werden, was die Leistung des verbesserten TCP ernsthaft beeinträchtigen würde. Der Enhancer verfügt über keine direkte Möglichkeit zur Abfrage des SG, um festzustellen, wie voll diese Puffer sind. Deshalb wurde ein Begrenzungsmodul entworfen, das den Füllzustand dieser Warteschlangen schätzt und, falls erforderlich, dem Spoofer mitteilt, dass er keine Daten mehr übertragen soll, bis die Puffer entleert worden sind. Das Grundprinzip besteht darin, die minimale und die mittlere RTT (Round Trip Time, Umlaufzeit) für jede Klasse (Puffer) zu verfolgen. Dies ist die Zeit, die vergeht, bis eine Quittung eines Pakets, das vom inneren TCP-Stapel ausgesendet wurde, wieder beim inneren Stapel eintrifft. Die minimale RTT wird als Kennwert für die einer Übertragungsstrecke innewohnenden Latenzzeit verwendet. Große RTT, von denen angenommen wird, dass sie auf nochmalige Übertragungen zurückzuführen sind, werden ignoriert. Wenn die mittlere RTT größer wird als ein gewisses Vielfaches der minimalen RTT, wird angenommen, dass sich der Puffer füllt (Pakete müssen im Puffer in eine Warteschlange eingereiht werden, bevor sie verarbeitet werden, demzufolge erhöht sich die RTT). In diesem Falle wird dem Spoofer untersagt, weitere Pakete für diese Klasse zu senden, bis ein Timeout erfolgt (dies ist eine Absicherung, und das sollte nicht eintreten).
  • Die Begrenzerklasse
  • Der Begrenzer einschätzt, dass sich der Puffer ausreichend geleert hat, so dass die Datenübertragung wieder beginnen kann. Um am besten zu beschreiben, wie der Begrenzungsmodul funktioniert, ist es erforderlich, die zentrale Datenstruktur des Moduls zu beschreiben – die Begrenzerklasse. Pro Puffer wird im SG eine Begrenzerklasse verwaltet; sie weist die folgenden Elemente auf: Einen Merker, welcher angibt, ob sich die Klasse im aktiven Zustand oder im Ruhezustand befindet. Der Spoofer darf keine Daten für eine Klasse senden, welche sich im Ruhezustand befindet.
  • Eine Paketschleife. Diese Schleife enthält mehrere Datenpakete für die Klasse (den Konfigurationsparameter loop_length). Bei diesen Paketen handelt es sich nicht um die vollständigen Pakete, die gesendet werden, sondern sie enthalten lediglich die notwendigen Informationen zur Identifizierung des TCP-Abschnitts, d. h. die Quell- und Ziel-IP-Adresse und Anschlussnummer (Port-Nummer) sowie die Laufnummer. Die Zeit zwischen Registrierungen von Paketen in dieser Schleife ist durch die Konfigurationsvariable "Time between logs" (Zeit zwischen Registrierungen) definiert. Diese Paketschleife hat zwei Hauptzwecke: die Umlaufzeiten RTT zu verfolgen und mit ihrer Hilfe zu bestimmen, wann eine Klasse in den Ruhezustand versetzt werden soll; und zu bestimmen, wann eine im Ruhezustand befindliche Klasse aktiviert werden soll. Die Pakete werden entsprechend dem in Millisekunden angegebenen Zeitintervall der Registrierung ständig registriert. Der innere TCP-Stapel übermittelt die relevanten detaillierten Angaben an den Begrenzer, bevor er das Paket ausgibt. Pakete werden erst aus der Paketschleife gelöscht, wenn eine Quittung ACK am inneren TCP-Stapel empfangen worden ist. Zu diesem Zeitpunkt kann dann eine Umlaufzeit RTT für das registrierte Paket berechnet werden.
  • Den Zeitpunkt, zu dem die Paketschleife zuletzt aktualisiert wurde. Dieser wird registriert, um zu überwachen, wann ein anderes Paket in der Paketschleife registriert werden sollte.
  • Eine Marke für den Anfangsblock und das Ende der Schleife. Dies sind zyklische Werte modulo Schleifenlänge. Der Paket-Kopf stellt die Position für die Protokollierung des nächsten Pakets dar, während das Paket-Ende das älteste registrierte Paket repräsentiert. Das Vorliegen eines zyklischen Puffers stellt sicher, dass zu jedem beliebigen Zeitpunkt ein Maximum an sinntragenden Paketen entsprechend der Schleifenlänge gespeichert werden kann.
  • Den Zeitpunkt, zu dem eine Klasse in den Ruhezustand versetzt wurde (trifft nur zu, wenn der Aktivierungsmerker auf FALSE gesetzt ist). Wenn die Klasse in den Ruhezustand versetzt wird, wird der Zeitpunkt registriert, so dass sie, wenn sie nicht aktiviert ist, durch ein ACK eines Pakets in der Paketschleife innerhalb eines vorgegebenen Zeitintervalls aktiviert werden kann.
  • Den Mittelwert und die Varianz der RTT. Die minimale RTT und der "Zählwert" der RTT werden ebenfalls gespeichert. Wenn der Mittelwert der RTT größer wird als ein gewisses Vielfaches der minimalen RTT, so wird die Klasse in den Ruhezustand versetzt. Der RTT-"Zählwert" wird zu Beginn schrittweise bis auf einen maximalen Wert erhöht und als ein Gewichtsfaktor bei der Berechnung der neuen mittleren RTT aus dem alten Wert verwendet, d. h.
    Figure 00150001
    wobei ⟨R⟩new die neue mittlere RTT ist, ⟨R⟩old die alte mittlere RTT ist, Rnew die neu übermittelte RTT ist und Rc der RTT-"Zählwert" ist. Diese "schrittweise Erhöhung" des RTT-"Zählwerts" stellt sicher, dass zu einem frühen Zeitpunkt auftretende Werte der RTT (d. h. wenn der Begrenzer erstmals gestartet wird) mit einem größeren Gewicht in den Mittelwert eingehen als spätere. Zu beachten ist, dass, wie bei allen Berechnungen von gleitenden Mittelwerten, die Summe der Gewichtsfaktoren (in runden Klammern) eins beträgt. Die Varianz der RTT wird verwendet, um zu schätzen, wann eine RTT eine nochmalige Übertragung erfordert. Diese werden ignoriert.
  • Einen Merker, welcher angibt, ob RTTs ignoriert werden sollten oder nicht. Es sei daran erinnert, dass RTTs verwendet werden, um zu schätzen, wann eine Klasse in den Ruhezustand versetzt werden sollte. Wenn eine Klasse in den Ruhezustand versetzt wird, werden RTTs, die zu Paketen gehören, welche ab diesem Zeitpunkt bis zu dem Zeitpunkt registriert werden, zu dem die Klasse wieder aktiviert wird, ignoriert. Wenn die Klasse in den Ruhezustand versetzt wird, wird der Merker "RTTs ignorieren" auf TRUE gesetzt, und die Variable "Ignorieren bis Paket" wird auf die Position gesetzt, an welcher das erste Paket, nachdem die Klasse wieder aktiviert worden ist, registriert werden soll. Alle Pakete, die in der Paketschleife vor diesem kommen, werden (für die Zwecke der Berechnung von RTTs) ignoriert. Sobald das Paket, das durch "Ignorieren bis Paket" angegeben wird, quittiert worden ist, wird der Merker "RTTs ignorieren" auf FALSE gesetzt. Durch diese Methode ist sichergestellt, dass die mittlere RTT nicht von sehr großen RTTs beeinflusst wird, auf die bereits effektiv reagiert worden ist (indem die Klasse in den Ruhezustand versetzt wurde). Wenn diese RTTs nicht ignoriert würden, würde eine Klasse, die gerade aktiviert worden ist, unnötigerweise wieder in den Ruhezustand versetzt.
  • Schätzung des Füllgrades des SG-Puffers
  • Unter der Annahme, dass jedes Paket, das an den SG-Puffer gesendet wird, in der Schleife der Begrenzerklasse registriert wird, und dass keine Latenzzeit in der Übertragungsstrecke vorhanden ist, spiegelt die Schleife der Begrenzerklasse exakt den Zustand des SG-Puffers wider. Das heißt, das Paket am vorderen Ende der Begrenzerklassenschleife befindet sich am hinteren Ende der Warteschlange des SG-Puffers, und das Paket am hinteren Ende der Begrenzerklassenschleife befindet sich am vorderen Ende der Warteschlange des SG-Puffers. Unter der weiteren Annahme, dass die Datenflüsse sowohl in den Puffer hinein als auch aus ihm heraus eine konstante Geschwindigkeit aufweisen, sind die Umlaufzeiten für diese Pakete exakt gleich der Länge der Warteschlange (in ms). Daher ist die Differenz der Registrierungszeitpunkte zwischen dem Paket am vorderen Ende und dem Paket am hinteren Ende der Paketschleife exakt gleich der Länge des SG-Puffers in ms (d. h. der Zeit, die benötigt würde, um die Warteschlange zu leeren, wenn keine Pakete mehr gesendet würden). Dies sind die Prinzipien, die angewendet werden, um eine Klasse in den Ruhezustand zu versetzen und wieder zu aktivieren. Wenn die RTTs für Pakete im Klassen-Puffer größer werden als ein gewisses Vielfaches der Basis-RTT, wird angenommen, dass sich der SG-Puffer füllt, und die Klasse wird in den Ruhezustand versetzt. Wenn die Differenz der Registrierungszeitpunkte zwischen dem Paket am vorderen Ende und dem Paket am hinteren Ende der Paketschleife kleiner wird als ein gewisses Vielfaches der Basis-RTT, wird die Klasse wieder aktiviert.
  • Nochmalige Übertragung
  • Zu handhaben ist die Bereitstellung eines gesicherten Schicht-2-Dienstes auf der Übertragungsstrecke zum mobilen Host (von Schicht 2 wird ausgegangen, um die ARQ-Schemata der Quittungswiederholungs-Anforderung [Acknowledgement Repeat Request] nutzen zu können). Die Übertragungsstrecke wird dem TCP nun weniger als eine fehlerhafte Strecke, als vielmehr als eine Übertragungsstrecke mit in hohem Grade variabler RTT erscheinen (jede nochmalige Übertragung einer niedrigeren Schicht bewirkt eine Verdopplung der RTT). Aufgrund der auftretenden Latenzzeiten könnte dies zur Folge haben, dass das Ende-zu-Ende-TCP unnötig Pakete nochmals überträgt, da die Erhöhung der RTT ein Timeout auslösen kann.
  • Der Enhancer ist in der Lage, diese Schwierigkeit zu bewältigen, da der Zeitgeber für die nochmalige Übertragung so geändert werden kann, dass er einen geeigneten minimalen Wert verwendet, welcher die Möglichkeit von Schicht-2 Übertragungswiederholungen berücksichtigt. Die Annahme, dass die Schicht-2 zuverlässig ist, bedeutet, dass es als unwahrscheinlich angesehen werden kann, dass dieses Timeout eintritt. Falls das Timeout dennoch ausgelöst wird, so kann dies darauf hinweisen, dass die Übertragungsstrecke zum mobilen Host zeitweilig getrennt ist.
  • Das normale TCP nimmt im Falle einer Übertragungswiederholung eine Reduzierung der Übertragungsgeschwindigkeit vor. Das heißt, wenn ein Timeout auftritt, wird das Paket nochmals übertragen. Das Timeout für dieses Paket wird dann verdoppelt. Dies geschieht, um eine Überlastung des Netzes zu vermeiden. Im Falle eines mobilen Hosts können (relativ) lange Zeitintervalle der Trennung vorhanden sein. Wenn diese exponentielle Reduzierung durchgeführt würde, könnte es lange dauern, bis ein Paket gesendet wird, welches feststellt, dass die Übertragungsstrecke wieder verfügbar ist. Aus diesem Grunde nimmt der Enhancer im Falle einer Übertragungswiederholung diese Reduzierung nicht vor. Stattdessen behält er den ursprünglichen Wert des Zeitgebers der Übertragungswiederholung bei und sendet das verloren gegangene Paket mit einer konstanten Übertragungsgeschwindigkeit neu. Dies bewirkt eigentlich ein zyklisches Abfragen des mobilen Hosts; es ruft eine umgehende Antwort hervor, wenn die Übertragungsstrecke verfügbar wird. Dies verbessert das Verhalten des Systems über Ende-zu-Ende-TCP. Im Falle des Hochladens (Datenfluss vom Mobiltelefon aus) gibt es einen Fall, in dem der Enhancer die Situation verbessern kann, und dies ist bei lange andauernden Trennungen. Ein unveränderter TCP-Stapel am mobilen Host nimmt an, falls er keine Quittung empfängt (infolge des Ausfalls der Funkstrecke), dass ein Paketverlust eingetreten ist, und führt eine nochmalige Übertragung durch. Wie oben beschrieben, reduziert das TCP exponentiell die Geschwindigkeit seiner Übertragungswiederholungen. Das bedeutet, dass die Tendenz dahin gehen wird, dass es lange dauern wird, um zu bemerken, dass die Übertragungsstrecke verfügbar geworden ist. Der Enhancer kann in diesem Falle die Wiederherstellung verbessern, indem er erkennt, dass die Übertragungsstrecke zu einem gegebenen Mobiltelefon frei (idle) ist. In diesem Falle sollte er die letzte Quittung, die auf jeder Verbindung gesendet wurde, in regelmäßigen, jedoch nicht sehr kurzen Intervallen wiederholen. Dies hat dann die Wirkung, dass das TCP am mobilen Host in eine Antwort "gestoßen" wird, wenn die Übertragungsstrecke verfügbar wird. Das Erkennen, ob die Übertragungsstrecke frei (und damit potentiell nicht verfügbar) ist, kann recht einfach beschrieben werden: Falls wenigstens eine TCP-Verbindung zu dem Mobiltelefon existiert und keine TCP-Verbindung zu diesem Mobiltelefon während der Dauer eines Timeout-Intervalls ein Paket erhalten hat, kann die Übertragungsstrecke als frei betrachtet werden. Die einzigen Fälle, in denen dies zutrifft, sind die, wenn die Übertragungsstrecke nicht verfügbar ist oder wenn die Verbindungen alle zufällig frei sind (d. h. keine ausstehenden nicht quittierten Daten oder Daten, die auf ihre Versendung warten, vorhanden sind). Falls die Verbindungen frei sind, hat das Senden von Quittungsduplikaten keinen Einfluss auf das Verhalten des mobilgeräteseitigen TCP-Stapels; es handelt sich somit um eine neutrale Aktivität. Hierfür wird zwar eine gewisse Bandbreite benötigt, doch das Senden eines "ACH"-Pakets alle paar Sekunden ist keine große Belastung. In dem Falle, wenn die Übertragungsstrecke nicht verfügbar ist, wird ein Schließen des TCP-Fensters ermöglicht, das vom Enhancer für die Internet-Hosts angezeigt wird. Damit wird dem sendenden TCP signalisiert, dass die Pakete korrekt empfangen werden, jedoch von der Anwendung nicht verarbeitet werden. Der Enhancer sendet dann (wie beim Standard-TCP) ein Paket zur "Fensteraktualisierung", sobald wieder mit der Verarbeitung von Daten begonnen wird, um dem Host zu signalisieren, dass er wieder mit dem Senden beginnen kann. Zusätzlich sendet das sendende TCP, wenn sich das Fenster vollständig schließt, periodisch einen "Fenstertest", um festzustellen, wann sich das Fenster öffnet (da die Fensteraktualisierung nicht zuverlässig übermittelt wird). Die kombinierte Wirkung des "Anstoßens" des TCP und der Steuerung des Absenders durch den Enhancer bedeutet, dass verbesserte Verbindungen in der Lage sind, nach einer langen Trennung wesentlich schneller wiederhergestellt zu werden als bei normalem Ende-zu-Ende TCP/IP. Für Fachleute ist klar, dass die Enhancer gemäß der Erfindung in vielfältigen unterschiedlichen Kommunikationssystemen eingesetzt werden kann, und sie wissen, welcher Ort dafür am geeignetsten ist. Natürlich kann ein Kommunikationssystem, insbesondere ein komplexes mit vielen Übertragungsstrecken, sehr wohl auch von mehreren Enhancern profitieren.

Claims (9)

  1. Verfahren zur Verbesserung des Datenflusses in einem Kommunikationssystem mit wenigstens zwei Übertragungsstrecken (2, 4) zur Verbindung mehrerer Einheiten (1, 3, A, B, C), wobei wenigstens eine Übertragungsstrecke mehrere simultane Verbindungen aufweist, welches das Aufspalten einer der besagten Übertragungsstrecken und das Einfügen wenigstens eines Enhancers (6) in diese umfasst, dessen Funktionsweise darin besteht, a) mit einer Einheit stromaufwärts im Datenfluss (1) so zu kommunizieren, dass die stromaufwärts befindliche Einheit wahrnimmt, dass sie mit einer Einheit (Einheiten) stromabwärts des Enhancers (6) kommuniziert; b) sich ein Maß für die Effizienz der Funktionsweise der stromabwärts befindlichen Einheit(en) zu verschaffen, indem er die Gesamtmenge der nicht quittierten Daten ermittelt (10), die auf der Übertragungsstrecke mit mehreren simultanen Verbindungen gesendet wurden; und c) je nach Messergebnis die Steuerung des Datenflusses, der zu den stromabwärts befindlichen Einheiten gesendet wird, anzupassen, indem er über eine bestimmte Verbindung keine Daten sendet, falls die Menge der nicht quittierten Daten, die über diese bestimmte Verbindung gesendet wurden, eine erste vorgegebene Menge übersteigt und die Menge der besagten gesamten Daten eine zweite vorgegebene Menge übersteigt.
  2. Verfahren nach Anspruch 1, wobei für die besagte Kommunikation des Enhancers mit der stromaufwärts befindlichen Einheit das Standard-TCP verwendet wird und für die Kommunikation mit stromabwärts befindlichen Einheiten ein modifiziertes und adaptives Protokoll verwendet wird.
  3. Verfahren nach einem der vorhergehenden Ansprüche, wobei der (die) Enhancer an Positionen angeordnet ist (sind), wo stromaufwärts davon befindliche Übertragungsstrecken im Allgemeinen schneller sind als stromabwärts vom Enhancer befindliche Übertragungsstrecken.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei die stromaufwärts befindliche Einheit das Internet ist.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei die stromabwärts befindlichen Übertragungsstrecken Funkstrecken sind.
  6. Kommunikationssystem mit wenigstens zwei Übertragungsstrecken zur Verbindung mehrerer Einheiten, wobei wenigstens eine Übertragungsstrecke mehrere simultane Verbindungen aufweist, und das wenigstens einen Enhancer enthält, der angeordnet ist, indem eine der besagten Übertragungsstrecken aufgespalten und der Enhancer in diese eingefügt wurde, wobei der besagte Enhancer Mittel umfasst, um mit einer Einheit stromaufwärts im Datenfluss so zu kommunizieren, dass die stromaufwärts befindliche Einheit wahrnimmt, dass sie mit der Einheit (den Einheiten) stromabwärts des Enhancers kommuniziert; Mittel, mit deren Hilfe sich die Effizienz der Funktionsweise der stromabwärts befindlichen Einheiten) feststellen lässt, indem die Gesamtmenge aller nicht quittierten Daten ermittelt wird, die auf der Übertragungsstrecke mit mehreren simultanen Verbindungen gesendet wurden; und Mittel, um auf regelbare Weise die zu den stromabwärts befindlichen Einheiten gesendeten Daten in Abhängigkeit von dem besagten Messergebnis zu steuern, indem über eine bestimmte Verbindung keine Daten gesendet werden, falls die Menge der nicht quittierten Daten, die über diese bestimmte Verbindung gesendet wurden, eine erste vorgegebene Menge übersteigt und die Menge der besagten gesamten Daten eine zweite vorgegebene Menge übersteigt.
  7. Kommunikationssystem nach Anspruch 6, wobei der (die) Enhancer an Positionen angeordnet ist (sind), wo stromaufwärts davon befindliche Übertragungsstrecken im Allgemeinen schneller sind als stromabwärts vom Enhancer befindliche Übertragungsstrecken.
  8. Kommunikationssystem nach Anspruch 6 oder 7, wobei die stromaufwärts befindliche Einheit das Internet ist.
  9. Kommunikationssystem nach einem der Ansprüche 6 bis 8, wobei die stromaufwärts befindlichen Übertragungsstrecken Funkstrecken sind.
DE60109959T 2000-12-16 2001-12-12 Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen Expired - Lifetime DE60109959T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0030709 2000-12-16
GB0030709A GB2370200B (en) 2000-12-16 2000-12-16 Method of enhancing the efficiency of data flow in communications systems
PCT/EP2001/014857 WO2002049293A1 (en) 2000-12-16 2001-12-12 Method of enhancing the efficiency of data flow in communication systems

Publications (2)

Publication Number Publication Date
DE60109959D1 DE60109959D1 (de) 2005-05-12
DE60109959T2 true DE60109959T2 (de) 2005-09-08

Family

ID=9905221

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60109959T Expired - Lifetime DE60109959T2 (de) 2000-12-16 2001-12-12 Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen

Country Status (5)

Country Link
US (1) US7489637B2 (de)
EP (1) EP1344359B1 (de)
DE (1) DE60109959T2 (de)
GB (1) GB2370200B (de)
WO (1) WO2002049293A1 (de)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7304948B1 (en) * 2000-12-29 2007-12-04 Nortel Networks Limited Congestion control for signalling transport protocols
US7483487B2 (en) * 2002-04-11 2009-01-27 Microsoft Corporation Streaming methods and systems
US7616644B2 (en) * 2004-02-25 2009-11-10 Nokia Corporation Method and apparatus providing a protocol to enable a wireless TCP session using a split TCP connection
GB0421114D0 (en) 2004-09-22 2004-10-27 Orange Personal Comm Serv Ltd Radio access data packet network and method
JP4655619B2 (ja) * 2004-12-15 2011-03-23 日本電気株式会社 無線基地局装置およびそのレート制御方法
US8719399B2 (en) * 2005-04-07 2014-05-06 Opanga Networks, Inc. Adaptive file delivery with link profiling system and method
ATE449494T1 (de) 2005-09-22 2009-12-15 Alcatel Lucent Netzwerkgerät zur verbesserung der transmissionseffizienz durch behandlung der tcp segmente
US20070253445A1 (en) * 2006-04-27 2007-11-01 Arcadyan Technology Corporation Method for the bandwidth detection
US20080170508A1 (en) * 2007-01-17 2008-07-17 Abb Technology Ag Channel integrity metric calculation
KR100967630B1 (ko) * 2008-08-04 2010-07-07 한양대학교 산학협력단 (3-메톡시페로세닐프로필)디메틸실란, 이의 제조방법 및이를 포함하는 하이드록시 말단 폴리부타디엔의 제조 방법
JP2010045193A (ja) * 2008-08-12 2010-02-25 Canon Inc 露光装置およびデバイス製造方法
US20100111095A1 (en) * 2008-11-03 2010-05-06 Bridgeworks Limited Data transfer
US9548936B2 (en) * 2011-06-30 2017-01-17 The Chinese University Of Hong Kong Method and system for improved TCP performance over mobile data networks
US10136355B2 (en) 2012-11-26 2018-11-20 Vasona Networks, Inc. Reducing signaling load on a mobile network
JP2014165551A (ja) * 2013-02-21 2014-09-08 Fujitsu Ltd 通信装置、通信方法、プログラム、及び、通信システム
MX368605B (es) * 2013-11-12 2019-10-09 Vasona Networks Inc Congestion en una red inalambrica.
MX368606B (es) * 2013-11-12 2019-10-09 Vasona Networks Inc Ajuste de retraso de llegada de datos a una estacion base.
US10039028B2 (en) 2013-11-12 2018-07-31 Vasona Networks Inc. Congestion in a wireless network
US9397915B2 (en) 2013-11-12 2016-07-19 Vasona Networks Inc. Reducing time period of data travel in a wireless network
US9345041B2 (en) 2013-11-12 2016-05-17 Vasona Networks Inc. Adjusting delaying of arrival of data at a base station
US10341881B2 (en) 2013-11-12 2019-07-02 Vasona Networks, Inc. Supervision of data in a wireless network
US9621448B2 (en) * 2014-04-08 2017-04-11 AppDynamics, Inc. Network analysis and monitoring tool
JP6459645B2 (ja) * 2015-03-06 2019-01-30 富士通株式会社 スループット計測プログラム、スループット計測方法及びスループット計測装置
US10299167B2 (en) 2017-05-16 2019-05-21 Cisco Technology, Inc. System and method for managing data transfer between two different data stream protocols
US10944697B2 (en) * 2019-03-26 2021-03-09 Microsoft Technology Licensing, Llc Sliding window buffer for minimum local resource requirements

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2576780B2 (ja) * 1993-12-17 1997-01-29 日本電気株式会社 プロトコル終端方式
US6473793B1 (en) * 1994-06-08 2002-10-29 Hughes Electronics Corporation Method and apparatus for selectively allocating and enforcing bandwidth usage requirements on network users
US6990069B1 (en) * 1997-02-24 2006-01-24 At&T Corp. System and method for improving transport protocol performance in communication networks having lossy links
US6119235A (en) * 1997-05-27 2000-09-12 Ukiah Software, Inc. Method and apparatus for quality of service management
US6501732B1 (en) * 1999-02-25 2002-12-31 3Com Corporation System and method for controlling data flow in a wireless network connection
GB9929882D0 (en) * 1999-12-18 2000-02-09 Roke Manor Research TCP/IP enhancement for long latency links
US6831912B1 (en) * 2000-03-09 2004-12-14 Raytheon Company Effective protocol for high-rate, long-latency, asymmetric, and bit-error prone data links
US6687227B1 (en) * 2000-03-13 2004-02-03 Nortel Networks Limited Systems and methods for requesting packets for transmission over a wirless channel having a dynamically changing capacity due to a highly varibale delay

Also Published As

Publication number Publication date
US20050041582A1 (en) 2005-02-24
GB2370200A (en) 2002-06-19
GB0030709D0 (en) 2001-01-31
DE60109959D1 (de) 2005-05-12
GB2370200B (en) 2004-06-02
EP1344359A1 (de) 2003-09-17
WO2002049293A1 (en) 2002-06-20
US7489637B2 (en) 2009-02-10
EP1344359B1 (de) 2005-04-06

Similar Documents

Publication Publication Date Title
DE60109959T2 (de) Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen
DE69837513T2 (de) Vorrichtung für die sichere Kommunikation über Funk- und Leitungsnetzwerke mittels Transportschichtverbindungen
DE69931215T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
DE60036218T2 (de) Verbindungsschichtquittierung und wiederübertragung für ein zellulares telekommunikationssystem
DE69930992T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
DE60113549T2 (de) Tcp-flusssteurung
DE69932069T2 (de) Arq protokoll mit packetbasierter zuverlässigkeitseinstellung
DE60029221T2 (de) Begrenztes automatisches wiederholungsaufforderungsprotokoll für rahmenbasierte kommunikationskanäle
DE60223799T2 (de) Verfahren und sender für einen effizienten paketdatentransfer in einem übertragungsprotokoll mit wiederholungsanforderungen
DE69836007T2 (de) Verfahren und endgerät mit verbesserter verbraucherantwortzeit in einem mobilen netzwerk
DE60219932T2 (de) Ssystgem und Verfahren zur Verwendung von Algorithmen und Protokollen zur optimierung von CSMA-Protokollen (Carrier Sense Multiple Access) in drahtlosen Netzwerken
DE60201553T2 (de) System und Verfahren zur Fehlerbeseitigung mit negativer Rückquittierung (NACK)
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE10066463B4 (de) Verfahren zur Kommunikation mit verzögerter Bestätigung und Alarmverwaltung
DE69935530T2 (de) Automatisches wiederholungsaufforderungsprotokoll
DE69935554T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und zuverlässigen Übertragen von kleinen Datennachrichten von einem Sendesystem zu einer grossen Anzahl von Empfangssystemen
DE60031263T2 (de) Umhüllungsverfahren für protokolldateneinheiten
DE60211322T2 (de) Empfängerinitiierte Inkrementierung der Übertragungsrate
DE602004002086T2 (de) Verfahren und Apparat zur gemeinsamen dynamischen Verwaltung von Fensterlängen von mehreren ARQ-Datenverbindungen
DE60030442T2 (de) Verfahren zur bereitstellung einer sicheren verbindung in einem mobilen kommunikationssystem
DE19983404B4 (de) Verfahren und Vorrichtung zur Verwendung bei der Einstellung eines TCP Gleitfensters
DE60311155T2 (de) Genaue steuerung von informationsübertragungen in ad-hoc netzwerken
DE60019206T2 (de) Verfahren und Vorrichtung zur vom Empfänger inizierten Wiederherstellung für das L2TP Protokoll
DE112013000411T5 (de) Benachrichtigung durch Netzwerkelement über Paketverluste
DE10295631T5 (de) Mechanismus für eine automatische Wiederholanforderung in einem Funkzugangsnetz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: MAIER, D., DIPL.-ING. UNIV., PAT.-ASS., 85221 DACH