DE102009044647A1 - Verfahren zur Datenverkehrsflusssteuerung, Vorrichtung und Drahtlos-Gerät - Google Patents

Verfahren zur Datenverkehrsflusssteuerung, Vorrichtung und Drahtlos-Gerät Download PDF

Info

Publication number
DE102009044647A1
DE102009044647A1 DE102009044647A DE102009044647A DE102009044647A1 DE 102009044647 A1 DE102009044647 A1 DE 102009044647A1 DE 102009044647 A DE102009044647 A DE 102009044647A DE 102009044647 A DE102009044647 A DE 102009044647A DE 102009044647 A1 DE102009044647 A1 DE 102009044647A1
Authority
DE
Germany
Prior art keywords
data
data packets
received
buffer memory
packets
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.)
Granted
Application number
DE102009044647A
Other languages
English (en)
Other versions
DE102009044647B4 (de
Inventor
Dan Dr. Dinescu
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.)
Intel Deutschland GmbH
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Publication of DE102009044647A1 publication Critical patent/DE102009044647A1/de
Application granted granted Critical
Publication of DE102009044647B4 publication Critical patent/DE102009044647B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • 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/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • 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/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Es werden Verfahren zur Datenverkehrsflusssteuerung, eine Vorrichtung und ein Drahtlos-Gerät bereitgestellt. Ein Verfahren zur Datenverkehrsflusssteuerung weist auf das Empfangen von Datenpaketen, wobei die Datenpakete weiterzuleiten sind (110); das Speichern mindestens eines der Datenpakete in einem Pufferspeicher, wenn der Pufferspeicher einen verfügbaren Platz zur Unterbringung des mindestens einen der Datenpakete aufweist (120); und Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist (130). Eine Vorrichtung ist dafür eingerichtet, das Verfahren auszuführen. Ein Drahtlos-Gerät kann die Vorrichtung enthalten.

Description

  • Ausführungsformen der Erfindung betreffen allgemein Verfahren zur Datenverkehrsflusssteuerung, eine Vorrichtung und ein Drahtlos-Gerät.
  • Gemäß einem Ausführungsbeispiel wird ein Verfahren zur Datenverkehrsflusssteuerung bereitgestellt, mit den folgenden Schritten: Empfangen von Datenpaketen, wobei die Datenpakete weiterzuleiten sind, Speichern mindestens eines der Datenpakete in einem Pufferspeicher, wenn der Pufferspeicher einen verfügbaren Platz zum Unterbringen des mindestens einen der Datenpakete aufweist, und Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist.
  • Gemäß einer Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner den folgenden Schritt auf: Weiterleiten des gespeicherten mindestens einen der Datenpakete.
  • Gemäß einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner den folgenden Schritt auf: Nichtweiterleiten des verworfenen mindestens einen anderen der Datenpakete.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verwerfen auf, nur ein anderes der Datenpakete zu verwerfen.
  • Die Datenpakete Nutzinformations-Datenpakete können sein.
  • Die Datenpakete können Datenpakete des Transmission Control Protocol (TCP) sein.
  • Das Empfangen kann aufweisen, die Datenpakete in einem gemultiplexten Datenstrom zusammen mit Bestätigungen zu empfangen, wobei die Bestätigungen weiterzuleiten sind.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner den folgenden Schritt auf: Herausfiltern der Bestätigungen aus dem gemultiplexten Datenstrom.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner den folgenden Schritt auf: Weiterleiten einer oder mehrerer der Bestätigungen, wobei die eine bzw. die mehreren der Bestätigungen später als das gespeicherte mindestens eine der Datenpakete empfangen wird und eine höhere Priorität als das gespeicherte mindestens eine der Datenpakete aufweist.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner den folgenden Schritt auf: Speichern der Bestätigungen in einem Bestätigungspuffer.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner den folgenden Schritt auf: Weiterleiten aller gespeicherten Bestätigungen mit einer höheren Priorität als das gespeicherte mindestens eine der Datenpakete.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels kann es vorgesehen sein, dass der Pufferspeicher einen insgesamt zugewiesenen Platz zur Unterbringung des mindestens einen der Datenpakete aufweist, wobei der insgesamt zugewiesene Platz größer als BW mal RTT und kleiner als zweimal BW mal RTT ist, wobei BW eine maximale Übertragungsbandbreite für eine Weiterleitung des mindestens einen der Datenpakete ist und wobei RTT eine minimale Gesamtlaufzeit für eine Übertragung und eine Bestätigung des mindestens einen der Datenpakete ist, wobei mit BW die maximale Übertragungsbandbreite für eine Weiterleitung eines UL-Datenpakets; und RTT eine minimale Gesamtlaufzeit für eine Übertragung und eine Bestätigung eines UL-Datenpakets; bezeichnet wird.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels kann es vorgesehen sein, dass der Pufferspeicher einen insgesamt zugewiesenen Platz zur Unterbringung des mindestens einen der Datenpakete aufweist, wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  • Gemäß einem anderen Ausführungsbeispiel wird ein Verfahren zur Datenverkehrsflusssteuerung bereitgestellt, mit den folgenden Schritten: Empfangen von Nutzinformations-Datenpaketen, wobei die Nutzinformations-Datenpakete in einer ersten Richtung einer bidirektionalen Datenverbindung weiterzuleiten sind; Speichern der empfangenen Nutzinformations-Datenpakete in einem Pufferspeicher, wenn der Pufferspeicher einen zugewiesenen verfügbaren freien Platz für das jeweilige nächste empfangene Nutzinformations-Datenpaket aufweist; und Verwerfen der empfangenen Nutzinformations-Datenpakete, wenn der Pufferspeicher keinen zugewiesenen verfügbaren freien Platz für das jeweilige nächste empfangene Nutzinformations-Datenpaket aufweist.
  • Gemäß einer Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner den folgenden Schritt auf: Empfangen von Bestätigungen für in einer zweiten Richtung der bidirektionalen Datenverbindung übertragene Daten, wobei die Bestätigungen in der ersten Richtung der bidirektionalen Datenverbindung weiterzuleiten sind.
  • Gemäß einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner die folgenden Schritte auf: Weiterleiten der gespeicherten Nutzinformations-Datenpakete; und Weiterleiten der empfangenen Bestätigungen mit einer höheren Priorität als die gespeicherten Nutzinformations-Datenpakete.
  • Gemäß noch einem anderen Ausführungsbeispiel wird ein Verfahren zur Datenverkehrsflusssteuerung bereitgestellt, mit den folgenden Schritten: Empfangen eines in einer Richtung einer bidirektionalen Datenverbindung zu übertragenden Datenstroms, wobei der Datenstrom Nutzinformations-Datenpakete aufweist und Bestätigungen aufweist, wobei die Bestätigungen den Empfang von in einer anderen Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigen; und Simulieren eines Verlusts eines in dem Datenstrom empfangenen Nutzinformations-Datenpakets, wobei der Verlust vorgeblich weiter signalabwärts in der einen Richtung der bidirektionalen Datenverbindung auftritt.
  • Gemäß einer Ausgestaltung dieses Ausführungsbeispiels weist das Simulieren auf, das empfangene Datenpaket abzuwerfen, statt es in der einen Richtung der bidirektionalen Datenverbindung weiterzuleiten.
  • Gemäß einer Ausgestaltung dieses Ausführungsbeispiels weist das Simulieren auf, das empfangene Datenpaket so zu manipulieren, dass es bei einem Adressat des Datenpakets nicht als ordnungsgemäß empfangenes Datenpaket erkannt wird.
  • Gemäß einer Ausgestaltung dieses Ausführungsbeispiels weist das Simulieren auf, den Verlust des empfangenen Nutzinformations-Datenpakets nur dann zu simulieren, wenn eine vordefinierte maximale Menge von Daten durch andere Nutzinformations-Datenpakete überschritten wird, die in dem Datenstrom vor dem empfangenen Nutzinformations-Datenpaket empfangen wurden, und wobei diese anderen Nutzinformations-Datenpakete noch nicht in der einen Richtung der bidirektionalen Datenverbindung weitergeleitet worden sind.
  • Gemäß einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verfahren ferner die folgenden Schritte auf: Weiterleiten von anderen in dem Datenstrom empfangenen Nutzinformations-Datenpaketen; und Weiterleiten von in dem Datenstrom empfangenen Bestätigungen mit einer höheren Priorität als die anderen Nutzinformations-Datenpakete.
  • Gemäß noch einem anderen Ausführungsbeispiel wird eine Vorrichtung bereitgestellt, aufweisend: einen Eingangsport zum Empfangen von Datenpaketen, wobei die Datenpakete weiterzuleiten sind; einen Pufferspeicher zum Speichern mindestens eines der Datenpakete, wenn der Pufferspeicher einen verfügbaren Platz zur Unterbringung des mindestens einen der Datenpakete aufweist; und eine Steuereinheit zum Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist.
  • Gemäß einer anderen Ausgestaltung dieses Ausführungsbeispiels weist das Verwerfen auf, nur ein anderes der Datenpakete zu verwerfen.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels ist es vorgesehen, dass der Pufferspeicher einen insgesamt zugewiesenen Platz zur Unterbringung des mindestens einen der Datenpakete aufweist, wobei der insgesamt zugewiesene Platz größer als BW mal RTT und kleiner als zweimal BW mal RTT ist, wobei BW eine maximale Übertragungsbandbreite für eine Weiterleitung des mindestens einen der Datenpakete ist und wobei RTT eine minimale Gesamtlaufzeit für eine Übertragung und eine Bestätigung des mindestens einen der Datenpakete ist.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels ist es vorgesehen, dass der Pufferspeicher einen insgesamt zugewiesenen Platz zur Unterbringung des mindestens einen der Datenpakete aufweist, wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels ist es vorgesehen, dass der Eingangsport ferner Bestätigungen empfangen soll, wobei die Bestätigungen weiterzuleiten sind.
  • Gemäß noch einer anderen Ausgestaltung dieses Ausführungsbeispiels weist die Vorrichtung ferner auf eine Weiterleitungseinheit zum Weiterleiten des gespeicherten mindestens einen der Datenpakete und zum Weiterleiten einer Bestätigung, wobei die Bestätigung später als das gespeicherte mindestens eine der Datenpakete empfangen wird, mit einer höheren Priorität als das gespeicherte mindestens eine der Datenpakete.
  • Gemäß noch einem anderen Ausführungsbeispiel wird ein Drahtlos-Gerät bereitgestellt mit einer oben beschriebenen Vorrichtung.
  • Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgenden näher erläutert.
  • Es zeigen
  • 1 ein Verfahren zur Datenverkehrsflusssteuerung gemäß einer Ausführungsform der Erfindung;
  • 2 ein Verfahren zur Datenverkehrsflusssteuerung gemäß einer weiteren Ausführungsform der Erfindung;
  • 3 ein Verfahren zur Datenverkehrsflusssteuerung gemäß noch einer weiteren Ausführungsform der Erfindung; und
  • 4 ein Blockschaltbild einer Vorrichtung gemäß einer Ausführungsform der Erfindung.
  • Die folgende ausführliche Beschreibung erläutert beispielhafte Ausführungsformen der vorliegenden Erfindung. Gegebenenfalls soll die Beschreibung einer Verfahrensausführungsform auch die Funktionsweise einer entsprechenden Vorrichtungsausführungsform beschreiben und umgekehrt. Die Beschreibung ist nicht im einschränkenden Sinne aufzufassen, sondern erfolgt lediglich zur Veranschaulichung der allgemeinen Prinzipien der Erfindung. Der Schutzumfang der Erfindung wird jedoch nur durch die Ansprüche definiert und soll nicht durch die nachfolgend beschriebenen beispielhaften Ausführungsformen beschränkt werden.
  • In 1 ist ein Verfahren zur Datenverkehrsflusssteuerung gemäß einer Ausführungsform der Erfindung gezeigt.
  • Datenverkehrsflusssteuerung bedeutet gewöhnlich, dass der Datenfluss über eine Datenverbindung (der „Verkehr”) gezielt beeinflusst wird. Ein Verhalten der Datenverbindung oder des Datenflusses selbst kann somit verbessert werden.
  • Bei 110 werden Datenpakete empfangen. Die Datenpakete sind weiterzuleiten.
  • Bei 120 wird mindestens eines der Datenpakete in einem Pufferspeicher gespeichert, wenn der Pufferspeicher einen verfügbaren Platz zur Unterbringung des mindestens einen der Datenpakete aufweist.
  • Bei 130 wird mindestens ein anderes der Datenpakete verworfen, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist.
  • 2 zeigt ein Verfahren zur Datenverkehrsflusssteuerung gemäß einer weiteren Ausführungsform der Erfindung.
  • Bei 210 werden Nutzinformations-Datenpakete empfangen. Die Nutzinformations-Datenpakete sind in einer ersten Richtung einer bidirektionalen Datenverbindung weiterzuleiten.
  • Bei 220 werden die empfangenen Nutzinformations-Datenpakete in einem Pufferspeicher gespeichert, wenn der Pufferspeicher einen zugewiesenen freien verfügbaren Platz für das jeweilige nächste empfangene Nutzinformations-Datenpaket aufweist.
  • Bei 230 werden die empfangenen Nutzinformations-Datenpakete verworfen, wenn der Pufferspeicher keinen zugewiesenen freien verfügbaren Platz für das jeweilige nächste empfangene Nutzinformations-Datenpaket aufweist.
  • 3 zeigt ein Verfahren zur Datenverkehrsflusssteuerung gemäß noch einer weiteren Ausführungsform der Erfindung.
  • Bei 310 wird ein Datenstrom empfangen. Der Datenstrom ist in einer Richtung einer bidirektionalen Datenverbindung zu übertragen. Der Datenstrom enthält Nutzinformations-Datenpakete und enthält Bestätigungen. Die Bestätigungen bestätigen den Empfang von in einer anderen Richtung der bidirektionalen Datenverbindung übertragenen Daten.
  • Bei 320 wird ein Verlust eines in dem Datenstrom empfangenen Nutzinformations-Datenpakets simuliert. Der simulierte Verlust tritt vorgeblich in einer Richtung der bidirektionalen Datenverbindung weiter signalabwärts auf.
  • Eine zum Übertragen von Daten verwendete Datenverbindung kann verwendet werden, um Daten gleichzeitig in entgegengesetzten Richtungen zu übertragen. Die Daten können über separate Übertragungskanäle in jeder Richtung oder unter Verwendung eines einzigen Übertragungskanals auf zeitlich gemultiplexte Weise übertragen werden. In jedem solchen Fall ist es im Allgemeinen erwünscht, dass ein Datentransfer in einer Richtung einen gleichzeitigen Datentransfer in der anderen Richtung nicht stört.
  • Eine bidirektionale Datenverbindung kann eine schnelle Richtung und eine langsame Richtung aufweisen. Man kann auch sagen, dass sie einen schnellen Pfad und einen langsamen Pfad aufweisen kann. Eine solche Datenverbindung wird als asymmetrische Datenverbindung bezeichnet. Zum Beispiel sind ADSL (Asymmetrical Digital Subscriber Line), wobei es sich um eine drahtgebundene Datenverbindung handelt, und HSDPA (High Speed Downlink Packet Access), wobei es sich um eine drahtlose Datenverbindung handelt, stark asymmetrische Datenverbindungen. Eine asymmetrische Datenverbindung gewährleistet gewöhnlich in der Abwärtsstrecke (die gewöhnlich die Richtung von einem Netzwerk oder einem Server zu einem Endgerät oder einem Benutzer ist) eine hohe Übertragungsgeschwindigkeit und gewährleistet gewöhnlich in der Aufwärtsstrecke (die gewöhnlich die Richtung von einem Endgerät oder einem Benutzer zu einem Netzwerk oder einem Server ist) eine langsame Übertragungsgeschwindigkeit.
  • Auf einer asymmetrischen Datenverbindung kann ein Datentransfer in der schnellen Richtung (z. B. Abwärtsstrecke) durch jegliche Datentransfers in der langsamen Richtung (z. B. Aufwärtsstrecke) stark beeinträchtigt werden. Dies gilt insbesondere in dem Fall, wenn die Datenverbindung gemäß dem Transmission Control Protocol TCP betrieben wird.
  • Eine Datenübertragung in der langsamen Richtung kann die verfügbare Übertragungskapazität leicht überlasten. Auf einer stark asymmetrischen Datenverbindung ist die Übertragungskapazität in der langsamen Richtung viel geringer als die der schnellen Richtung. Anders ausgedrückt, kann eine Sättigung der Übertragungsbandbreite in der langsamen Richtung auftreten.
  • Gleichzeitig werden Daten in der schnellen Richtung der Datenverbindung mit einer hohen Datenrate übertragen, die durch die hohe Übertragungskapazität der schnellen Richtung ermöglicht wird. Bestätigungen, die den Empfang dieser schnellen Daten bestätigen, werden beim Empfang der Daten erzeugt. Die Bestätigungen sind zu dem Absender der schnellen Daten unter Verwendung der langsamen Richtung zurückzuübertragen.
  • Als Folge einer Sättigung der Übertragungsbandbreite in der langsamen Richtung können die den Empfang von in der schnellen Richtung der Datenverbindung übertragenen Daten bestätigenden Bestätigungen nicht ordnungsgemäß übertragen werden. Zum Beispiel bleiben sie in einer langen Warteschlange aller anderen in der langsamen Richtung zu übertragenden Daten hängen. Der Absender der schnellen Daten empfängt Bestätigungen für die schnellen Daten nicht rechtzeitig genug und verlangsamt oder unterbricht sogar den Datentransfer in der schnellen Richtung.
  • Wie aus dem Obengesagten ersichtlich ist, kann eine Sättigung der Übertragungsbandbreite in der langsamen Richtung zu einer Verlangsamung eines schnellen Datentransfers in der anderen Richtung führen, wodurch ein großer Teil der in der schnellen Richtung verfügbaren Übertragungsbandbreite unbenutzt bleibt.
  • Um die Bandbreite (BW) in der schnellen Richtung besser zu nutzen, kann ein Verfahren zur Verkehrsflusssteuerung verwendet werden.
  • Außerdem kann der Datentransfer in einer Richtung bei einer weniger asymmetrischen bidirektionalen Datenverbindung oder sogar bei einer stark symmetrischen bidirektionalen Datenverbindung durch den Datentransfer in der anderen Richtung stark beeinträchtigt werden, z. B. können Bestätigungen, die den Empfang von in der einen Richtung übermittelten Daten bestätigen und sich deshalb in der anderen Richtung ausbreiten, durch Nutzinformationsdaten, die sich auch in der anderen Richtung ausbreiten, verzögert werden.
  • Um die Bandbreite in jeder bidirektionalen Datenverbindung und in jeder Richtung dieser bidirektionalen Datenverbindung besser zu nutzen, kann ein Verfahren zur Verkehrsflusssteuerung verwendet werden.
  • Im Folgenden wird die Verkehrsflusssteuerung weiter erläutert. Es wird eine Ausführungsform der Erfindung betrachtet, bei der ein Client-Datenverarbeitungsgerät, z. B. ein Client-Computer, z. B. ein Personal Computer (PC), mit einem Server-Datenverarbeitungsgerät, z. B. einem Computer, z. B. einem im Internet befindlichen Server, über eine asymmetrische Datenverbindung gemäß dem Transmission Control Protocol (TCP) verbunden ist. Die asymmetrische Datenverbindung gewährleistet in der Abwärtsstrecke (DL), die von dem Server zu dem Client führt, eine hohe Übertragungsgeschwindigkeit und in der Aufwärtsstrecke (UL), die von dem Client zu dem Server führt, eine niedrige Übertragungsgeschwindigkeit. Die Datenverbindung oder ein Teil der Datenverbindung kann z. B. durch ein Modem realisiert werden, z. B. ein drahtloses Modem, das ein selbstständiges Modem sein kann oder in dem Client-Computer, z. B. in einen Notebook-PC oder in einen Personal Digital Assistant (PDA), eingebaut oder in ein separates Mobiltelefon, das zusammen mit dem Server-Computer verwendet wird, integriert werden kann.
  • Ein Computerprogramm, das auf dem Client-Computer oder einem mit der Datenverbindung assoziierten Router ausgeführt wird, kann als eine Verkehrsflusssteuervorrichtung verwendet werden. Die Verkehrsflusssteuervorrichtung kann die Anwendungen auf dem Client-Computer überwachen und die Daten begrenzen, die sie in der UL senden dürfen, und somit eine Sättigung der in der UL verfügbaren Bandbreite (BW) vermeiden. Die TCP-Bestätigungen (ACKs) können dann sofort in der UL übertragen werden. Die Verkehrsflusssteuervorrichtung kann die ACKs für die DL-Datenpakete filtern und ihnen gegenüber anderen UL-Datenpaketen höhere Priorität geben. Somit müssen die ACKs nicht in den Warteschlangen warten und können unmittelbar in der UL übertragen werden, auch wenn die BW in der UL gesättigt ist.
  • Die in dem vorausgehenden Paragraphen beschriebenen Ansätze können gut funktionieren, sind aber nicht in allen Fällen angemessen. Ein solcher Fall liegt vor, wenn der Client-Computer unter Verwendung eines Mobiltelefons oder eines drahtlosen Modems oder dergleichen, was im Folgenden allgemein als drahtloses Gerät bezeichnet wird, mit dem Netzwerk (dem Server-Computer) verbunden ist.
  • Eine Steuerung des Teils der BW in der UL, der von Anwendungen auf dem Client-Computer benutzt werden darf, würde bedeuten, dass der Benutzer spezielle Software installieren muss, was zusätzliche Kosten und potentielle Konfigurationsarbeit bedeutet. zusätzlich würden die zusätzlichen Puffer zwischen einer auf dem Client-Computer implementierten Verkehrsflusssteuervorrichtung und einer analogen Schnittstelle zu Kommunikationsmedien, die mit dem Netzwerk verbinden, zu einer Vergrößerung der ACK-Verzögerung beitragen.
  • Selbst wenn man nach einer in dem Drahtlos-Gerät implementierten Lösung sucht, wobei die TCP-ACKs eine höhere Priorität erhalten und somit nicht in den Warteschlangen des Drahtlos-Geräts warten müssen würden, ist der Gewinn gering, weil diese Warteschlangen im Vergleich zu den Puffern in dem Client-Computer, der ein Personal Computer (PC) oder dergleichen sein kann, relativ klein sind. Die Datenpuffer in dem Drahtlos-Gerät können schnell nur mit Daten aufgefüllt werden, die eine Anwendung auf dem Client-Computer in der UL senden möchte. Also liegt kein herauszufilterndes und vor die anderen Daten zu stellendes ACK in dem Datenpuffer (der Warteschlange) des Drahtlos-Geräts vor. Ein Versuch, den TCP-ACKs eine höhere Priorität mit Bezug auf die Warteschlangen des Drahtlos-Geräts zu geben, könnte deshalb möglicherweise nicht gut arbeiten.
  • Gemäß Ausführungsformen der Erfindung wird mindestens ein Datenpaket verworfen, statt weitergeleitet zu werden. Dies hat den Effekt, dass dieses Datenpaket den Adressaten nicht erreicht und der Adressat kein ACK für dieses Datenpaket zu dem Absender des Datenpakets zurücksendet. Dies hat seinerseits den Effekt, dass der Absender informiert wird, dass ein Datenpaket an irgendeiner Stelle auf seinem Weg zu dem Adressaten verloren ging. Ein Absender, der ein Datenübertragungsprotokoll verwendet, das den abgehenden Datenfluss auf der Basis von empfangenen ACKs steuert, wird reagieren, indem er die Datenrate reduziert, d. h. von nun an weniger Daten pro Zeit sendet, da ein Verlust eines Datenpakets eine Anzeige dafür ist, dass die zuvor benutzte Datenrate zu hoch war, d. h. mehr BW erforderte, als die Datenverbindung bereitstellen konnte. Anders ausgedrückt, ist das Verwerfen eines Datenpakets wie hier beschrieben eine Methode, dem Absender, z. B. dem TCP-IP-Protokollstapel eines Client-Computers, zu signalisieren, dass er versucht, eine BW zu verwenden, die zu hoch ist, und dass der Absender eine niedrigere BW verwenden sollte.
  • Das Ziel dieser Manipulation besteht darin, die durch Daten, z. B. Nutzinformations-Datenpakete, verwendete BW in einer Richtung einer Datenverbindung, z. B. in der UL, auf einen Wert zu begrenzen, der auch den ACKs, die sich in der einen Richtung ausbreiten, die den Empfang von sich in der anderen Richtung der Datenverbindung ausbreitenden Daten bestätigen, Z. B. für die DL-Datenpakete, den notwendigen Teil der BW gibt. Somit wird die BW in der einen Richtung, z. B. in der UL, nicht kontinuierlich durch sich in der anderen Richtung ausbreitende Daten gesättigt und die Datenwarteschlangen über das System hinweg in der einen Richtung werden sich nicht auffüllen. Dies minimiert die den ACKs für die sich in der anderen Richtung der Datenverbindung ausbreitenden Daten, Z. B. für die DL-Datenpakete, auferlegten Verzögerungen.
  • Gemäß Ausführungsformen der Erfindung wird nur ein Datenpaket verworfen. Spätere Datenpakete können normal an den Adressaten weitergeleitet werden. Dies hat immer noch den Effekt, dem Absender zu signalisieren, dass er versucht, eine BW zu verwenden, die zu hoch ist, und dass der Absender eine niedrigere BW verwenden sollte. Dies hat den weiteren Effekt, dass die Datenübertragung weniger gestört wird als in einem Fall, bei dem mehr als ein Datenpaket verworfen werden würde. Der Adressat kann eine Benachrichtigung zu dem Absender senden, dass ein Datenpaket nicht angekommen ist, und kann weiter ACKs für spätere Datenpakete senden. Es sollte beachtet werden, dass sich die Begrenzung der BW, die von Daten in der einen Richtung der Datenverbindung verwendet wird, nicht auf die reine Abwesenheit des einzigen oder die reine Abwesenheit des mehr als einen verworfenen Datenpakets weiter signalabwärts verlässt, sondern stattdessen auf dem Signalisierungseffekt und auf der Reaktion des Absenders, eine niedrigere BW zu verwenden, sobald er erkennt, dass ein Datenpaket an irgendeiner Stelle auf seinem Weg zu dem Adressaten verloren geht, basiert.
  • Gemäß einer Ausführungsform der Erfindung wird ein Datenpaket manipuliert und dann zu dem Adressaten weitergeleitet (statt verworfen zu werden). Zum Beispiel wird gezielt eine Prüfsumme in dem Datenpaket verändert. Als Ergebnis der Manipulation wird das manipulierte Datenpaket beim Adressaten nicht als ein ordnungsgemäß empfangenes Datenpaket erkannt. Der Adressat sendet dann kein ACK für dieses manipulierte Datenpaket zu dem Absender des Datenpakets zurück. Dies hat wieder den Effekt, dem Absender zu signalisieren, dass er versucht, eine BW zu verwenden, die zu hoch ist, und dass der Absender eine niedrigere BW verwenden sollte.
  • Eine vorgeschlagene Lösung gemäß einer Ausführungsform versucht, die Verzögerung in dem System für die für die DL-Datenpakete erzeugten ACKs zu verringern. Diese ACKs werden in der UL-Richtung übertragen. Um dies zu erzielen, sollten die UL-relevanten Puffer in dem PC für den größten Teil der Zeit leer sein, und in dem Modem sollte es den ACKs erlaubt sein, die Datenpakete zu überholen und mit hoher Priorität gesendet zu werden. Dadurch wird sichergestellt, dass die ACKs nicht auf die UL-Datenpakete sowohl in den PC-Puffern als auch den Modem-Puffern warten müssen.
  • Gemäß einer Ausführungsform liest das Modem, um die beiden in dem vorausgehenden Paragraphen erwähnten Vorbedingungen zu erzielen, alle Daten, die der PC senden kann, und führt für jedes Paket Folgendes durch: Wenn das Paket ein ACK ist, Speichern desselben in einem ACK-Puffer. Wenn dieser Puffer voll ist, wird Flusssteuerung zwischen UE und PC verwendet. Wenn das Paket ein TCP-Datenpaket ist, Speichern desselben in einem anderen Pufferspeicher, der als „Staupuffer” bezeichnet werden kann. Wenn dieser Pufferspeicher voll ist oder einen vorbestimmten Füllstand erreicht hat, Verwerfen mindestens eines der verbleibenden Datenpakete. Es kann mehr als eines oder es können sogar alle der verbleibenden Datenpakete verworfen werden. Verwerfen bedeutet, dass die jeweiligen Datenpakete voll aufgegeben und nicht weitergeleitet werden. Andere Datenpakete (wie UDP) sollten auch in dem Staupuffer oder in einem anderen Puffer gespeichert werden. Wenn kein Platz zum Speichern verfügbar ist, kann der Flusssteuermechanismus zwischen Modem und PC verwendet werden.
  • Gemäß einer Ausführungsform wird nur eines der verbleibenden Datenpakete verworfen, wenn der Pufferspeicher („Staupuffer”) einen vorbestimmten Füllstand, z. B. eine gegebene Füllstandschwelle, erreicht. Die anderen verbleibenden Datenpakete werden in dem Pufferspeicher gespeichert. Das Verwerfen von nur einem Datenpaket reicht aus, um den Signalisierungseffekt zu ergeben und um die Reaktion des Absenders, eine niedrigere BW zu verwenden, sobald er erkennt, dass ein Datenpaket an irgendeiner Stelle auf seinem Weg zu dem Adressaten verloren ging, zu provozieren. Wenn kein Platz zum Speichern von mehr Datenpaketen der anderen verbleibenden Datenpakete in dem Pufferspeicher verfügbar ist, kann der Flusssteuermechanismus zwischen Modem und PC verwendet werden. Als Alternative kann zum Speichern dieser Datenpakete ein anderer Speicher als Erweiterung des Pufferspeichers verwendet werden.
  • Bei einer Ausführungsform wird nur eines der verbleibenden Datenpakete verworfen, wenn der Pufferspeicher („Staupuffer”) einen vorbestimmten Füllstand, z. B. eine gegebene Füllstandsschwelle erreicht, und es werden keine weiteren Datenpakete verworfen, bis der Füllstand des Pufferspeichers unter den vorbestimmten Füllstand, z. B. die gegebene Füllstandsschwelle fällt und sich dem vorbestimmten Füllstand wieder von unterhalb dieses Stands aus nähert und diesen erreicht. Zum Beispiel verringert der Absender zuerst die Anzahl der Datenpakete „im Fluge” („on-the-fly”) (als Reaktion auf den Verlust des verworfenen Datenpakets, und dies führt zu einer signifikanten Abnahme des Füllstands des Pufferspeichers. Danach versucht der Absender langsam, die Anzahl der Datenpakete wieder „im Fluge” („on-the-fly”) zu vergrößern. Nach einiger Zeit wird der Füllstand wieder den vorbestimmten Füllstand, z. B. die gegebene Füllstandsschwelle erreichen. Dann wird wieder nur eines der verbleibenden Datenpakete verworfen.
  • Das Verwerfen von Datenpaketen wird sich auf die allgemeine Datenrate in der UL nur wenig auswirken. Der TCP/IP-Stapel in dem PC wird die verworfenen Datenpakete für Netzwerkstau halten und dann versuchen, sie neu zu senden. Der TCP/IP- Stapel in dem PC wird auch entsprechend das sogenannte Staufenster anpassen, d. h. ihm eine beträchtlich kleinere Größe geben. Deshalb wird er nicht mehr Daten im Fluge (ohne Bestätigung) senden, als der Staupuffer halten kann. Als unmittelbares Ergebnis kann das Modem den PC-Puffer in die internen Puffer, z. B. ACK-Puffer und Staupuffer leeren, ohne weitere Datenpakete verwerfen zu müssen.
  • Da das Staufenster nach jedem abgeworfenen Paket nur langsam wieder größer wird, liegt auch ein Zeitraum vor, in dem keine Pakete verworfen werden. Ein leerer PC-Puffer wird es den ACKs erlauben, das Modem ohne Verzögerungen zu erreichen.
  • Bei einer Ausführungsform wird den ACKs in dem Modem im Vergleich zu den Datenpaketen eine höhere Priorität gegeben. Deshalb werden sie hier auch nicht verzögert.
  • Das Ergebnis dieses Ansatzes wird ein leichter Abfall der UL-Datenrate am Anfang und eine relativ gute mittlere Datenrate hinterher sein. Die DL-Datenrate wird durch die UL-Verbindung nicht mehr beeinträchtigt.
  • Ausführungsformen der Erfindung besitzen die folgenden Vorteile: Verfahren zur Datenflusssteuerung gemäß Ausführungsformen können in dem Modem vollständig und transparent implementiert werden, wobei der Ausdruck „transparent implementiert” bedeutet, dass der Client-Computer, der Server-Computer und der Rest der Datenverbindung nicht von der Implementierung abhängen wird. Der Client-Computer und der Server-Computer und der Rest der Datenverbindung (Datenpfad) müssen nicht geändert werden. Der Datenfluss justiert sich selbst, ohne dass irgendeine aktive Abstimmung notwendig ist. Das Verhalten des Datenflusses ist großenteils von den Einstellungen des die Daten in der UL empfangenen Computers unabhängig. Es können optimale Datenraten in beiden Richtungen (UL, DL) gleichzeitig erzielt werden.
  • Gemäß Ausführungsformen der Erfindung basiert die Verkehrsflusssteuerung auf einer Simulation in dem Modem eines Netzwerkstaus. Gemäß Ausführungsformen weist die Simulation eines Netzwerkstaus das Verwerfen von UL-Datenpaketen auf, wenn der interne (Stau-)Puffer voll ist. Wenn die Flusssteuer- und Stauvermeidungsmechanismen, die in einem Datenübertragungsprotokoll definiert sind, die Bestätigungen verwendet, um ordnungsgemäßen Empfang von Daten sicherzustellen, wie z. B. TCP, gegeben sind, hilft dieser Ansatz bei der Regulierung der Kommunikation. Der Teil der BW in der UL, der von den UL-Datenpaketen benutzt wird, wird somit begrenzt, und eine kontinuierliche Sättigung der BW in der UL durch Daten, die ACKs, die sich parallel zu den Daten ausbreiten, verzögern würde, kann somit vermieden werden. Den ACKs in der UL-Richtung in dem Modem eine höhere Priorität zu geben, verbessert die Regulierung der Kommunikation weiter.
  • 4 zeigt ein Blockschaltbild einer Vorrichtung gemäß einer Ausführungsform der Erfindung. Die Vorrichtung ist in einem Drahtlos-Gerät 400 enthalten, das zum Beispiel ein dediziertes Drahtlos-Modem für Datentransfer oder ein in ein Mobiltelefon oder einen PDA (Personal Digital Assistant) integriertes Drahtlos-Modem ist.
  • Ein Client-Computer (Benutzer-Computer) 405, der zum Beispiel ein Personal Computer (PC) ist, wird über eine asymmetrische Datenverbindung 420, 425, 430, 435 gemäß dem Transmission Control Protocol (TCP) mit einem Server-Computer 410, z. B. einem Server im Internet 415, verbunden. Die asymmetrische Datenverbindung weist eine lokale Verbindung 420, 425, auf, z. B. eine USB-Verbindung (Universal Serial Bus) zwischen dem Client/Benutzer 405 und dem drahtlosen Gerät 400 und weist eine Verbindung per Funk 430, 435, auf zwischen dem drahtlosen Gerät 400 und dem Server 410. Sie besitzt eine Abwärtsstrecken-(DL-)Richtung 420, 430, die die Richtung von dem Server 410 zu dem Client 405 ist, und eine Aufwärtsstrecken-(UL-)Richtung 425, 435, die die Richtung von dem Client 405 zu dem Server 410 ist. Der DL-Pfad in dem Drahtlos-Gerät 400 ist als Datenleitungen 440 gezeigt, und der UL-Pfad in dem Drahtlos-Gerät 400 ist als Datenleitungen 445 gezeigt. Die asymmetrische Datenverbindung gewährleistet in der Verbindung per Funk 430 in der DL eine hohe Übertragungsgeschwindigkeit und gewährleistet in der Verbindung per Funk 435 in der UL eine niedrige Übertragungsgeschwindigkeit.
  • Mehrere Anwendungsprogramme 450 (die als mit 1, 2, ..., n beziffert gezeigt sind), die durch den PC ausgeführt werden, können gleichzeitig Daten mit einem oder mehreren Servern 410 im Internet 415 über das Drahtlos-Gerät 400 austauschen. Der Datenaustausch ist auf der Seite des PC 405 gemäß dem Transmission Control Protocol (TCP) durch den PC-TCP/IP-Stapel 455 organisiert, der zu sendende Daten von den Anwendungsprogrammen 450 sammelt und empfangene Daten an diese verteilt.
  • Aus dem Internet 415 kommende Abwärtsstrecken-(DL-)Daten (die auch als Herunterladedaten bezeichnet werden) kommen über die Verbindung per Funk 430 an dem drahtlosen Gerät (Modem) 400 an und werden in dem Protokollstapel 460 verarbeitet. Der Protokollstapel 460 ist zum Beispiel ein Drahtlos-Protokollstapel des Typs 3G oder 4G (UMTS) oder UMTS-LTE oder UMTS-LTE-Advanced. Die DL-Daten werden über den DL-Abgangspuffer 465 und die lokale Verbindung 420 zu dem PC 405 gesendet. Hier werden die DL-Daten in dem PC-DL-Puffer 470 empfangen und zu dem PC-TCP/IP-Stapel 455 weitergeleitet.
  • Aus den Anwendungsprogrammen 450 kommende Aufwärtsstrecken-(UL-)Daten (die auch als Heraufladedaten bezeichnet werden) durchlaufen den PC-TCP/IP-Stapel 455 und den PC-UL-Puffer 475. Die UL-Daten kommen über die lokale Verbindung 425 an dem Drahtlos-Gerät (Modem) 400 an und werden dort durch den Eingangsport 480 empfangen. Ferner erzeugt der PC-TCP/IP- Stapel 455 Bestätigungen (ACKs) zum Bestätigen des Empfangs der DL-Daten. Diese ACKs werden parallel mit den UL-Daten zum Internet 415 gesendet. Nach dem Durchlaufen des PC-UL-Puffers 475 kommen die ACKs über die lokale Verbindung 425 an dem Drahtlos-Gerät (Modem) 400 an und werden dort durch den Eingangsport 480 empfangen.
  • Gemäß Ausführungsformen der Erfindung werden die UL-Daten und die ACKs dann weiter verarbeitet, um Datenverkehrsflusssteuerung zu erzielen, wie in den folgenden Paragraphen beschrieben werden wird. Nur UL-Daten und ACKs, die über die Datenleitungen 445 weitergeleitet werden, werden dann in dem Protokollstapel 460 verarbeitet und über die Verbindung per Funk 435 zum Internet 415 gesendet.
  • Die durch den Eingangsport 480 empfangenen UL-Datenpakete und die ACKs werden dann dem ankommenden UL-Puffer 485 zugeführt. Die Größe des ankommenden UL-Puffers 485 wird hauptsächlich durch Leistungsfähigkeitsaspekte bestimmt.
  • Bei einer Ausführungsform werden alle in dem ankommenden UL-Puffer 485 existierenden ACKs in den ACK-Puffer 490 verlegt. Wenn keine weiteren ACKs in den ACK-Puffer 490 passen, muss Flusssteuerung mit dem PC 405 verwendet werden. Die ACKs in dem ACK-Puffer 490 werden dann zu dem Protokollstapel 460 weitergeleitet.
  • Bei einer Ausführungsform werden die UL-Datenpakete in dem ankommenden UL-Puffer 485 auf die folgende Weise abgewickelt: Der Staupuffer 495 empfängt Datenpakete für die UL-Richtung aus dem ankommenden UL-Puffer 485. Wenn ein TCP-Datenpaket aus dem ankommenden UL-Puffer 485 nicht mehr in einen Teil des Staupuffers 485 passt, der durch einen Schwellenfüllstand definiert wird und der zuerst gefüllt werden soll, wird dieses Datenpaket verworfen. Spätere TCP-Datenpakete aus dem ankommenden UL-Puffer 485 werden nicht verworfen. Die Steuereinheit 500 steuert, welche TCP-Datenpakete verworfen werden. Das Verwerfen eines TCP-Datenpakets wird in 4 durch den von der Steuereinheit 500 wegzeigenden gestrichelten Pfeil 505 symbolisiert. Außerdem werden Nicht-TCP-Datenpakete, z. B. UDP-Datenpakete, nicht verworfen. Wenn nicht zu verwerfende Datenpakete überhaupt nicht in den Staupuffer 495 passen, d. h. auch der Teil über dem Schwellenfüllstand voll ist, kann Flusssteuerung mit dem PC 405 verwendet werden. Als Alternative kann ein anderer Puffer verwendet werden, um die nicht zu verwerfenden Datenpakete unterzubringen.
  • Der Multiplexer (MUX) 510 multiplext die ACKs aus dem ACK-Puffer 490 und die UL-Datenpakete aus dem Staupuffer 495 und sendet diese zu dem Protokollstapel 460.
  • Bei einer Ausführungsform werden die ACKs immer eine höhere Priorität als die UL-Datenpakete aufweisen. Das bedeutet, dass UL-Datenpakete nur dann zu dem Protokollstapel 460 gesendet werden, wenn der ACK-Puffer 490 leer ist.
  • Da der Protokollstapel 460 gewöhnlich auch Puffer enthält, ist es nützlich, diese Puffer so klein wie möglich zu halten oder die ACKs und UL-Datenpakete erst zu dem Protokollstapel 460 zu senden, wenn die Puffer in dem Protokollstapel 460 das Risiko laufen, leer zu werden. Andernfalls könnten diese Puffer mit UL-Daten aufgefüllt werden, und die ACKs müssten potentiell eine zu große Zeit warten. Dies könnte dann den TCP-Fluss stören und die DL-Daten verzögern.
  • Die Größe des Staupuffers 495 kann so gewählt werden, dass sogar nach einem Paketverlust, z. B. wenn ein TCP-UL-Datenpaket verworfen wird oder auf seinem weiteren Weg zu dem Server 410 verloren geht, der Staupuffer 495 nicht leer läuft. Die entsprechende Größe richtet sich hauptsächlich nach dem Produkt „BW mal RTT”, wobei BW die maximale Übertragungsbandbreite für eine Weiterleitung eines UL-Datenpakets ist und wobei RTT eine minimale Gesamtlaufzeit für eine Übertragung und eine Bestätigung eines UL-Datenpakets ist. Die RTT kann mit dem leeren Staupuffer 495 und der voll genutzten DL-Datenverbindung gemessen werden.
  • Wenn die Größe, genauer gesagt der maximal benutzte Füllstand, des Staupuffers 495 wenigstens geringfügig größer als das Produkt „BW mal RTT” ist, kann sich das durch den PC-TCP/IP-Stapel 455 für UL-Daten verwendete TCP-Staufenster bis auf einen Maximalwert erweitern, der mindestens etwas größer als zweimal BW mal RTT ist, bis ein weiteres UL-Datenpaket „im Fluge” nicht mehr in den Staupuffer 495 passt und verworfen wird. Da das durch den PC-TCP/IP-Stapel 455 verwendete TCP-Staufenster halbiert wird, wenn der PC-TCP/IP-Stapel 455 Paketverlust detektiert, wird das neue TCP-Staufenster immer noch mindestens etwas größer als das Produkt „BW mal RTT” sein. Der Staupuffer 495 wird deshalb nicht vollständig leer laufen, und dies hilft dabei, die volle verfügbare BW in der UL auszunutzen. Andererseits sollte der Staupuffer 495 relativ klein gehalten werden, um die Datenpaketausbreitungszeit von dem Client zu dem Server zu reduzieren.
  • Bei einer Ausführungsform ist die Größe des Staupuffers 495 größer als BW mal RTT und kleiner als zweimal BW mal RTT. Wenn zum Beispiel BW = 40 Kb/s und RTT = 1 s gilt, kann der Staupuffer 495 so dimensioniert werden, dass er eine Datenmenge von zwischen 40 Kb und 80 Kb hält.
  • Bei einer weiteren Ausführungsform ist die Größe des Staupuffers 495 größer als BW mal RTT und kleiner als dreimal BW mal RTT. Wenn zum Beispiel BW = 40 Kb/s und RTT = 1 s gilt, kann der Staupuffer 495 so dimensioniert werden, dass er eine Datenmenge von zwischen 40 Kb und 120 Kb hält.
  • Bei einer Ausführungsform wird die Größe, genauer gesagt ein maximaler benutzter Füllstand oder ein Schwellenfüllstand des Staupuffers 495 während eines ablaufenden Datentransfers dynamisch justiert. Die verwendete Größe wird so justiert, dass sie so niedrig wie möglich ist, ohne dass der Puffer leer läuft. Wenn auch nach einem Ereignis mehr als einige wenige, z. B. mehr als 2 oder 3, Datenpakete immer in dem Puffer verbleiben, wobei das durch den PC-TCP/IP-Stapel 455 verwendete TCP-Staufenster verringert ist, wird die benutzte Größe (die Schwelle) herabgesetzt. Wenn nach einem Ereignis weniger als einige wenige, z. B. weniger als 2 oder 3, Datenpakete in dem Puffer verbleiben, wobei das durch den PC-TCP/IP-Stapel 455 verwendete TCP-Staufenster verringert ist, oder der Puffer in einem solchen Fall sogar leer läuft, wird die benutzte Größe (die Schwelle) erhöht.
  • Gemäß Ausführungsformen der Erfindung können der Staupuffer 495 und/oder der ACK-Puffer 490 jeweils durch einen separaten physischen Pufferspeicher, durch einen Teil eines physischen Pufferspeichers, durch einen logischen Pufferspeicher, durch Vergeben eines Attributs „im Staupuffer gespeichert” oder „im ACK-Puffer gespeichert” an in irgendeinem Speicher gespeicherte Daten oder durch eine beliebige Kombination davon realisiert werden.
  • Bei einer Ausführungsform werden der Staupuffer 495 und der ACK-Puffer 490 zu einem vereinigten Puffer kombiniert. Ein Teil dieses vereinigten Puffers, der sowohl für UL-Datenpakte als auch ACKs in der Reihenfolge, in der sie ankommen, verwendet wird, wird durch einen Auslöse(Trigger)-Füllstand des vereinigten Puffers definiert. Sobald dieser Trigger-Füllstand erreicht ist, werden keine TCP-Datenpakete mehr in den vereinigten Puffer geleitet. Von nun an werden alle neuankommenden TCP-Datenpakete verworfen oder gelöscht, bis der tatsächliche Füllstand unter den Trigger-Füllstand fällt. Im Gegensatz dazu werden ACKs immer noch in den vereinigten Puffer eingelassen, auch wenn der tatsächliche Füllstand über dem Trigger-Füllstand liegt.
  • Bei einer Ausführungsform werden der ACK-Puffer 490 und/oder der Staupuffer 495 nicht als separate Puffer implementiert. Stattdessen wird der ankommende UL-Puffer 485 so konfiguriert, dass er ihre jeweiligen Funktionen wie in der vorliegenden Anmeldung beschrieben ausführt. Es müssen also nicht alle ACKs und UL-Datenpakete aus dem ankommenden UL-Puffer 485 in andere Puffer verlagert werden. Sie werden lediglich gelesen und verarbeitet, d. h. werden als ein ACK oder als ein UL-Datenpaket markiert und erhalten eine Priorität für Weiterleitung oder werden im Fall von UL-Datenpaketen gelöscht (statt verworfen), wenn eine vorbestimmte maximale Menge von UL-Daten in dem ankommenden UL-Puffer 485 überschritten wird.
  • Gemäß einer Ausführungsform der Erfindung wird in der Abwärtsstreckenrichtung einer Datenverbindung ein Verfahren zur Datenflusssteuerung oder eine Vorrichtung wie in der vorliegenden Anmeldung beschrieben verwendet.
  • Gemäß einer Ausführungsform der Erfindung wird in der schnellen Richtung einer asymmetrischen Datenverbindung ein Verfahren zur Datenflusssteuerung oder eine Vorrichtung wie in der vorliegenden Anmeldung beschrieben verwendet.
  • Gemäß einer Ausführungsform werden ein Verfahren zur Datenflusssteuerung oder eine Vorrichtung wie in der vorliegenden Anmeldung beschrieben sowohl in der langsamen Richtung als auch in der schnellen Richtung einer asymmetrischen Datenverbindung verwendet.
  • Gemäß einer Ausführungsform der Erfindung werden ein Verfahren zur Datenflusssteuerung oder eine Vorrichtung wie in der vorliegenden Anmeldung beschrieben in einer symmetrischen Datenverbindung verwendet.
  • Gemäß einer Ausführungsform der Erfindung werden ein Verfahren zur Datenflusssteuerung oder eine Vorrichtung wie in der vorliegenden Anmeldung beschrieben in beiden Richtungen einer symmetrischen Datenverbindung verwendet.
  • Gemäß einer Ausführungsform der Erfindung kann jede durch einen der Ansprüche definierte Ausführungsform mit einer beliebigen einen oder mit mehreren anderen durch einen jeweiligen einen oder mehrere der anderen Ansprüche definierten Ausführungsformen kombiniert werden.

Claims (25)

  1. Verfahren zur Datenverkehrsflusssteuerung, mit den folgenden Schritten: • Empfangen von Datenpaketen, wobei die Datenpakete weiterzuleiten sind (110); • Speichern mindestens eines der Datenpakete in einem Pufferspeicher, wenn der Pufferspeicher einen verfügbaren Platz zum Unterbringen des mindestens einen der Datenpakete aufweist (120); und • Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist (130).
  2. Verfahren gemäß Anspruch 1, ferner mit dem folgenden Schritt: Weiterleiten des gespeicherten mindestens einen der Datenpakete.
  3. Verfahren gemäß Anspruch 1 oder 2, ferner mit dem folgenden Schritt: Nichtweiterleiten des verworfenen mindestens einen anderen der Datenpakete.
  4. Verfahren gemäß einem der Ansprüche 1 bis 3, wobei das Verwerfen aufweist, nur ein anderes der Datenpakete zu verwerfen.
  5. Verfahren gemäß einem der Ansprüche 1 bis 4, wobei die Datenpakete Nutzinformations-Datenpakete sind.
  6. Verfahren gemäß einem der Ansprüche 1 bis 5, wobei die Datenpakete Datenpakete des Transmission Control Protocol sind.
  7. Verfahren gemäß einem der Ansprüche 1 bis 6, wobei das Empfangen aufweist, die Datenpakete in einem gemultiplexten Datenstrom zusammen mit Bestätigungen zu empfangen, wobei die Bestätigungen weiterzuleiten sind.
  8. Verfahren gemäß Anspruch 7, ferner mit dem folgenden Schritt: Herausfiltern der Bestätigungen aus dem gemultiplexten Datenstrom.
  9. Verfahren gemäß Anspruch 7 oder 8, ferner mit dem folgenden Schritt: Weiterleiten einer oder mehrerer der Bestätigungen, wobei die eine bzw. die mehreren der Bestätigungen später als das gespeicherte mindestens eine der Datenpakete empfangen wird und eine höhere Priorität als das gespeicherte mindestens eine der Datenpakete aufweist.
  10. Verfahren gemäß einem der Ansprüche 7 bis 9, ferner mit dem folgenden Schritt: Speichern der Bestätigungen in einem Bestätigungspuffer.
  11. Verfahren gemäß Anspruch 10, ferner mit dem folgenden Schritt: Weiterleiten aller gespeicherten Bestätigungen mit einer höheren Priorität als das gespeicherte mindestens eine der Datenpakete.
  12. Verfahren gemäß einem der Ansprüche 1 bis 11, wobei der Pufferspeicher einen insgesamt zugewiesenen Platz zur Unterbringung des mindestens einen der Datenpakete aufweist, wobei der insgesamt zugewiesene Platz größer als BW mal RTT und kleiner als zweimal BW mal RTT ist, wobei BW eine maximale Übertragungsbandbreite für eine Weiterleitung des mindestens einen der Datenpakete ist und wobei RTT eine minimale Gesamtlaufzeit für eine Übertragung und eine Bestätigung des mindestens einen der Datenpakete ist, wobei mit • BW die maximale Übertragungsbandbreite für eine Weiterleitung eines UL-Datenpakets; und • RTT eine minimale Gesamtlaufzeit für eine Übertragung und eine Bestätigung eines UL-Datenpakets; bezeichnet wird.
  13. Verfahren gemäß einem der Ansprüche 1 bis 12, wobei der Pufferspeicher einen insgesamt zugewiesenen Platz zur Unterbringung des mindestens einen der Datenpakete aufweist, wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  14. Verfahren zur Datenverkehrsflusssteuerung, mit den folgenden Schritten: • Empfangen von Nutzinformations-Datenpaketen, wobei die Nutzinformations-Datenpakete in einer ersten Richtung einer bidirektionalen Datenverbindung weiterzuleiten sind (210); • Speichern der empfangenen Nutzinformations-Datenpakete in einem Pufferspeicher, wenn der Pufferspeicher einen zugewiesenen verfügbaren freien Platz für das jeweilige nächste empfangene Nutzinformations-Datenpaket aufweist (220); und • Verwerfen der empfangenen Nutzinformations-Datenpakete, wenn der Pufferspeicher keinen zugewiesenen verfügbaren freien Platz für das jeweilige nächste empfangene Nutzinformations-Datenpaket aufweist (230).
  15. Verfahren gemäß Anspruch 14, ferner mit dem folgenden Schritt: Empfangen von Bestätigungen für in einer zweiten Richtung der bidirektionalen Datenverbindung übertragene Daten, wobei die Bestätigungen in der ersten Richtung der bidirektionalen Datenverbindung weiterzuleiten sind.
  16. Verfahren gemäß Anspruch 15, ferner mit den folgenden Schritten: • Weiterleiten der gespeicherten Nutzinformations-Datenpakete; und • Weiterleiten der empfangenen Bestätigungen mit einer höheren Priorität als die gespeicherten Nutzinformations-Datenpakete.
  17. Verfahren zur Datenverkehrsflusssteuerung, mit den folgenden Schritten: • Empfangen eines in einer Richtung einer bidirektionalen Datenverbindung zu übertragenden Datenstroms, wobei der Datenstrom Nutzinformations-Datenpakete aufweist und Bestätigungen aufweist, wobei die Bestätigungen den Empfang von in einer anderen Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigen (310); und • Simulieren eines Verlusts eines in dem Datenstrom empfangenen Nutzinformations-Datenpakets, wobei der Verlust vorgeblich weiter signalabwärts in der einen Richtung der bidirektionalen Datenverbindung auftritt (320).
  18. Verfahren gemäß Anspruch 17, wobei das Simulieren aufweist, das empfangene Datenpaket abzuwerfen, statt es in der einen Richtung der bidirektionalen Datenverbindung weiterzuleiten.
  19. Verfahren gemäß Anspruch 17 oder 18, wobei das Simulieren aufweist, das empfangene Datenpaket so zu manipulieren, dass es bei einem Adressat des Datenpakets nicht als ordnungsgemäß empfangenes Datenpaket erkannt wird.
  20. Verfahren gemäß einem der Ansprüche 17 bis 19, wobei das Simulieren aufweist, den Verlust des empfangenen Nutzinformations-Datenpakets nur dann zu simulieren, wenn eine vordefinierte maximale Menge von Daten durch andere Nutzinformations-Datenpakete überschritten wird, die in dem Datenstrom vor dem empfangenen Nutzinformations-Datenpaket empfangen wurden, und wobei diese anderen Nutzinformations-Datenpakete noch nicht in der einen Richtung der bidirektionalen Datenverbindung weitergeleitet worden sind.
  21. Verfahren gemäß einem der Ansprüche 17 bis 20, ferner mit den folgenden Schritten: • Weiterleiten von anderen in dem Datenstrom empfangenen Nutzinformations-Datenpaketen; und • Weiterleiten von in dem Datenstrom empfangenen Bestätigungen mit einer höheren Priorität als die anderen Nutzinformations-Datenpakete.
  22. Vorrichtung (400), aufweisend: • einen Eingangsport (480) zum Empfangen von Datenpaketen, wobei die Datenpakete weiterzuleiten sind; • einen Pufferspeicher (495) zum Speichern mindestens eines der Datenpakete, wenn der Pufferspeicher (495) einen verfügbaren Platz zur Unterbringung des mindestens einen der Datenpakete aufweist; und • eine Steuereinheit (500) zum Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher (495) keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist.
  23. Vorrichtung (400) gemäß Anspruch 22, wobei der Pufferspeicher (495) einen insgesamt zugewiesenen Platz zur Unterbringung des mindestens einen der Datenpakete aufweist, wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  24. Vorrichtung (400) gemäß Anspruch 22 oder 23, ferner, aufweisend: eine Weiterleitungseinheit zum Weiterleiten des gespeicherten mindestens einen der Datenpakete und zum Weiterleiten einer Bestätigung, wobei die Bestätigung später als das gespeicherte mindestens eine der Datenpakete empfangen wird, mit einer höheren Priorität als das gespeicherte mindestens eine der Datenpakete.
  25. Drahtlos-Gerät (400), das eine Vorrichtung (400) gemäß einem der Ansprüche 22 bis 24 aufweist.
DE102009044647.8A 2008-12-18 2009-11-25 Verfahren zur Datenverkehrsflusssteuerung, Vorrichtung und Drahtlos-Gerät Active DE102009044647B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/337,652 US8194543B2 (en) 2008-12-18 2008-12-18 Methods of data traffic shaping, apparatus and wireless device
US12/337,652 2008-12-18

Publications (2)

Publication Number Publication Date
DE102009044647A1 true DE102009044647A1 (de) 2010-09-16
DE102009044647B4 DE102009044647B4 (de) 2014-10-23

Family

ID=42265889

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102009044647.8A Active DE102009044647B4 (de) 2008-12-18 2009-11-25 Verfahren zur Datenverkehrsflusssteuerung, Vorrichtung und Drahtlos-Gerät

Country Status (3)

Country Link
US (2) US8194543B2 (de)
JP (1) JP5011515B2 (de)
DE (1) DE102009044647B4 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2360598A1 (de) * 2010-02-12 2011-08-24 Blue Wonder Communications GmbH Verfahren und Vorrichtung zur Synchronisation von Datenaussendungen
GB2481971B (en) * 2010-07-07 2016-12-21 Cray Uk Ltd Apparatus & method
US9112691B2 (en) * 2010-08-13 2015-08-18 Qualcomm Incorporated Methods and systems for downlink flow control in a wireless communication system
CN104283808B (zh) * 2013-07-03 2019-03-26 华为技术有限公司 拥塞控制方法、设备及系统
CN104702531B (zh) * 2013-12-10 2018-04-20 华为技术有限公司 一种网络设备拥塞避免的方法及网络设备
KR101737786B1 (ko) 2015-01-27 2017-05-19 서울대학교산학협력단 무선 자원 상태 예측 및 트래픽 제어를 위한 프록시 장치 및 방법
CN108370327A (zh) * 2015-09-25 2018-08-03 Fsa技术股份有限公司 多干线数据流调节系统和方法
JP7448015B2 (ja) * 2020-08-20 2024-03-12 日本電信電話株式会社 シェーピングを行うための通信システム、装置、方法及びプログラム

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6490251B2 (en) * 1997-04-14 2002-12-03 Nortel Networks Limited Method and apparatus for communicating congestion information among different protocol layers between networks
JP3556495B2 (ja) * 1998-12-15 2004-08-18 株式会社東芝 パケットスイッチ及びパケット交換方法
JP2001127830A (ja) 1999-11-01 2001-05-11 Nippon Telegr & Teleph Corp <Ntt> データ通信方法及びデータ通信網
US6894974B1 (en) * 2000-05-08 2005-05-17 Nortel Networks Limited Method, apparatus, media, and signals for controlling packet transmission rate from a packet source
CA2438195C (en) * 2001-02-24 2009-02-03 International Business Machines Corporation Optimized scalabale network switch
US20040085915A1 (en) * 2002-11-04 2004-05-06 Yuval Gronau Protocol performance using ACK priority
JP3974027B2 (ja) 2002-11-28 2007-09-12 株式会社エヌ・ティ・ティ・ドコモ 基地局制御装置、データ伝送方法及びプログラム
JP4228850B2 (ja) 2003-09-16 2009-02-25 富士電機システムズ株式会社 パケット中継装置
US7315515B2 (en) * 2003-09-30 2008-01-01 Conexant Systems, Inc. TCP acceleration system
US7058058B2 (en) * 2003-11-05 2006-06-06 Juniper Networks, Inc. Transparent optimization for transmission control protocol initial session establishment
US7706261B2 (en) * 2004-08-27 2010-04-27 Jinshen Sun Queue-based active queue management process
JP2006245887A (ja) 2005-03-02 2006-09-14 Kddi Corp 無線mac処理部における送信パケットスケジューリング方法、プログラム及び無線通信装置
JP2006279867A (ja) 2005-03-30 2006-10-12 Nec Access Technica Ltd Adsl通信装置、プログラム及び方法
US7606234B2 (en) 2005-06-14 2009-10-20 Microsoft Corporation Multi-stream acknowledgement scheduling
US8462624B2 (en) * 2005-07-28 2013-06-11 Riverbed Technologies, Inc. Congestion management over lossy network connections
JP4554544B2 (ja) 2006-03-28 2010-09-29 三菱電機株式会社 ストリーミングバッファ制御方法、ストリーム配信システム及び中継装置
US8036127B2 (en) * 2006-07-20 2011-10-11 Oracle America, Inc. Notifying network applications of receive overflow conditions
US9049017B2 (en) 2006-10-02 2015-06-02 Sony Corporation Efficient TCP ACK prioritization in wireless networks
GB2447469B (en) 2007-03-14 2009-06-24 Motorola Inc Method and apparatus for handling interconnection transmissions
WO2008148173A1 (en) 2007-06-07 2008-12-11 Smart Internet Technology Crc Pty Ltd A system and method for improving throughput in a network device
US20090073878A1 (en) * 2007-08-31 2009-03-19 Kenneth Gustav Carlberg Usage based queuing with accounting for wireless access points
EP2068511B1 (de) * 2007-12-06 2011-04-06 Alcatel-Lucent USA Inc. Stauregelung in einem paketgeschalteten Datennetz
US7864818B2 (en) * 2008-04-04 2011-01-04 Cisco Technology, Inc. Multinode symmetric load sharing
KR101671804B1 (ko) * 2008-04-25 2016-11-16 인텔렉추얼디스커버리 주식회사 Tcp ack 패킷 전송 및 수신 방법과, 이를 지원하는 장치

Also Published As

Publication number Publication date
JP5011515B2 (ja) 2012-08-29
US20120213068A1 (en) 2012-08-23
DE102009044647B4 (de) 2014-10-23
US8194543B2 (en) 2012-06-05
JP2010148110A (ja) 2010-07-01
US8755278B2 (en) 2014-06-17
US20100157797A1 (en) 2010-06-24

Similar Documents

Publication Publication Date Title
DE102009044647B4 (de) Verfahren zur Datenverkehrsflusssteuerung, Vorrichtung und Drahtlos-Gerät
DE69738359T2 (de) System zur Verbesserung des Datendurchsatzes einer TCP/IP Netzwerkverbindung mit langsamen Rückkanal
DE112013000398B4 (de) Multisprung-Fehlerbehebung
DE60023019T2 (de) Verfahren und system zur ablösung oder regeneration von quittierungspaketen in adsl kommunikationen
DE69025713T2 (de) Dynamische Fensterbestimmung in einem Datennetzwerk
DE3780800T2 (de) Anordnung zur ueberlastregelung fuer paketvermittlungssystem.
DE69025558T2 (de) Verfahren und Vorrichtung zur Überlastregelung in einem Datennetzwerk
DE69932069T2 (de) Arq protokoll mit packetbasierter zuverlässigkeitseinstellung
DE60113549T2 (de) Tcp-flusssteurung
DE3780799T2 (de) Anordnung zur ueberlastregelung durch bandbreitenverwaltung fuer paketvermittlungssystem.
DE69834763T2 (de) Verfahren zur Unterstützung von verbindungsindividuellen Warteschlangen für rückgekoppelte Verkehrssteuerung
DE60117485T2 (de) Verfahren und Vorrichtung zur Pufferverwaltung
DE60130011T2 (de) Http-multiplexer/demultiplexer
DE69033551T2 (de) Vermeidung von Überlastung in Computer-Netzwerken mit Hilfe von Verzögerung
DE69930992T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
DE112016002847T5 (de) Dienstgüte in einem drahtlosen Backhaul
DE69732398T2 (de) System zur Verkehrssteuerung und Überlastregelung für Paketnetzwerke
DE102020105776A1 (de) Kostengünstige Überlastungsisolierung für verlustfreies Ethernet
DE69811622T2 (de) Verfahren und Vorrichtung zur Bandbreitenverwaltung in einem Datenübertragungsnetz
DE112013000411T5 (de) Benachrichtigung durch Netzwerkelement über Paketverluste
DE60212383T2 (de) Verfahren zur Übertragung von Datenströmen mit Datensegmenten variabler Länge
DE102007038964A1 (de) Verfahren und Vorrichtung zum Verarbeiten von Netzwerkdaten
EP1168753A1 (de) Verfahren und Mittel zur Übertragung von Daten unterschiedlicher Dienstqualität in Internet-Protokoll Datagrammen
DE602004010056T2 (de) Verfahren und System zur Verwaltung des Netzwerkverkehrs unter Berücksichtung von mehreren Zwangsbedingungen
DE102021109482A1 (de) SYSTEM UND VERFAHREN ZUR REGELUNG VON NVMe-oF-BEFEHLSANFRAGEN UND DATENFLUSS ÜBER EIN NETZWERK MIT UNGLEICHMÄßIGER GESCHWINDIGKEIT

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R081 Change of applicant/patentee

Owner name: INTEL DEUTSCHLAND GMBH, DE

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG, 85579 NEUBIBERG, DE

Effective date: 20130207

Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG, 85579 NEUBIBERG, DE

Effective date: 20130207

R082 Change of representative

Representative=s name: VIERING, JENTSCHURA & PARTNER MBB PATENT- UND , DE

Effective date: 20130207

Representative=s name: VIERING, JENTSCHURA & PARTNER PATENT- UND RECH, DE

Effective date: 20130207

Representative=s name: VIERING, JENTSCHURA & PARTNER, DE

Effective date: 20130207

R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R081 Change of applicant/patentee

Owner name: INTEL DEUTSCHLAND GMBH, DE

Free format text: FORMER OWNER: INTEL MOBILE COMMUNICATIONS GMBH, 85579 NEUBIBERG, DE

R082 Change of representative

Representative=s name: VIERING, JENTSCHURA & PARTNER MBB PATENT- UND , DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029020000

Ipc: H04L0065000000