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

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

Info

Publication number
DE102009044647B4
DE102009044647B4 DE102009044647.8A DE102009044647A DE102009044647B4 DE 102009044647 B4 DE102009044647 B4 DE 102009044647B4 DE 102009044647 A DE102009044647 A DE 102009044647A DE 102009044647 B4 DE102009044647 B4 DE 102009044647B4
Authority
DE
Germany
Prior art keywords
data
data packets
forwarding
acknowledgments
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.)
Active
Application number
DE102009044647.8A
Other languages
English (en)
Other versions
DE102009044647A1 (de
Inventor
Dr. Dinescu Dan
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
Intel Mobile Communications GmbH
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 Intel Mobile Communications GmbH filed Critical Intel Mobile Communications GmbH
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

Images

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

Verfahren zur Datenverkehrsflusssteuerung, mit den folgenden Schritten: • Empfangen von Datenpaketen, die von einem Sender gesendet werden, wobei die Datenpakete in einer Uplink-Richtung einer bidirektionalen Datenverbindung 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); • Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist (130), womit in der Uplink-Richtung ein Staufenster des Senders verringert wird, wenn mindestens ein anderes der Datenpakete verworfen wird, • wobei das Empfangen aufweist, die Datenpakete in einem gemultiplexten Datenstrom zusammen mit Bestätigungen zu empfangen, wobei die Bestätigungen den Empfang von in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigen und in der Uplink-Richtung der bidirektionalen Datenverbindung weiterzuleiten sind; • Weiterleiten einer oder mehrerer der Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung, 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; • 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 ...

Description

  • Aus dem Dokument WO 2008/040 725 A1 ist ein Verfahren zur Datenverkehrsflusssteuerung bekannt, bei dem die Bestätigungen und die Datenpakete von einem Multiplexer zu empfangen und über jeweils separate Träger weitergeleitet und zu gesendet werden. Die jeweiligen Sendepuffer für die Bestätigungen und die Datenpakete werden an einer Layer 1-Schnittstelle als separate Datenströme gesehen und über separate Radioträger übertragen.
  • Aus dem Dokument US 2006/0 045 008 A1 ist ein Warteschlangenmanagement bekannt, bei dem ein Schwellwert für eine Warteschlangengröße in Abhängigkeit eines Staugrades erfolgt.
  • Aus ROHDE & SCHWARZ: R&S AMU 200A Baseband Signal Generator and Fading Simulator, Spezifikation, Version 01.00, April 2007, Firmenschrift ist eine Spezifikation eines Baseband Signalgenerators und Fading Simulators bekannt.
  • Aus dem Dokument US 2007/0 002 863 A1 ist eine Scheduling-Software bekannt, die in einem Treiber implementiert ist, der mit dem Netzwerk-Stapel des Computers verknüpft ist, und die Bestätigungspakete in einem Datenstrom relativ zu Datenpaketen in einem anderen Datenstrom neu anordnen kann Damit kann die Priorität einzelner Bestätigungspakete erhöht werden.
  • Das Dokument WO 2008/148 173 A1 beschreibt ein Verfahren zum Verwalten von Datenpaketen, die in einem asymmetrischen Netzwerk gesendet werden, wobei eine Übertragungsrate berechnet werden kann. Bestätigungen und Datenpakete können in verschiedene Warteschlangen eingeteilt und die Bestätigungs-Warteschlange priorisiert werden.
  • Das Dokument WO 2008/112 456 A1 beschreibt ein Verfahren zum Ermitteln, ob der andere Teilnehmer, zu dem über eine Netzwerkverbindung Datenpakete und Bestätigungen gesendet werden, bei einem zufälligen Verlust von Datenpaketen die Größe des Staupuffers verändert, wobei zum Ermitteln ein empfangenes Datenpaket fallengelassen wird.
  • 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, die von einem Sender gesendet werden, wobei die Datenpakete in einer Uplink-Richtung einer bidirektionalen Datenverbindung 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, Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist, womit in der Uplink-Richtung ein Staufenster des Senders verringert wird, wenn mindestens ein anderes der Datenpakete verworfen wird, wobei das Empfangen aufweist, die Datenpakete in einem gemultiplexten Datenstrom zusammen mit Bestätigungen zu empfangen, wobei die Bestätigungen den Empfang von in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigen und in der Uplink-Richtung der bidirektionalen Datenverbindung weiterzuleiten sind, Weiterleiten einer oder mehrerer der Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung, 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, 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, und wobei der insgesamt zugewiesene Platz zur Unterbringung des mindestens einen der Datenpakete während eines ablaufenden Datentransfers dynamisch justiert wird.
  • 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 können Nutzinformations-Datenpakete sein.
  • Die Datenpakete können Datenpakete des Transmission Control Protocol (TCP) sein.
  • 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: 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äß einem anderen Ausführungsbeispiel wird ein Verfahren zur Datenverkehrsflusssteuerung bereitgestellt, mit den folgenden Schritten: Empfangen von Nutzinformations-Datenpaketen, die von einem Sender gesendet werden, wobei die Nutzinformations-Datenpakete in einer Uplink-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; Verwerfen der empfangenen Nutzinformations-Datenpakete, wenn der Pufferspeicher keinen zugewiesenen verfügbaren freien Platz für das jeweilige nächste empfangene Nutzinformations-Datenpaket aufweist, womit in der Uplink-Richtung ein Staufenster des Senders verringert wird, wenn die empfangenen Nutzinformations-Datenpakete verworfen werden; Empfangen von Bestätigungen für in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragene Daten, wobei die Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung weiterzuleiten sind, 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; und wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  • 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 Uplink-Richtung einer bidirektionalen Datenverbindung zu übertragenden Datenstroms, der von einem Sender gesendet wird, wobei der Datenstrom Nutzinformations-Datenpakete aufweist und Bestätigungen aufweist, wobei die Bestätigungen den Empfang von in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigen und wobei die Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung weiterzuleiten sind; und Simulieren eines Verlusts eines in dem Datenstrom empfangenen Nutzinformations-Datenpakets, wobei der Verlust vorgeblich weiter signalabwärts in der Uplink-Richtung der bidirektionalen Datenverbindung auftritt, womit in der Uplink-Richtung ein Staufenster des Senders verringert wird, wenn der Verlust eines der empfangenen Nutzinformations-Datenpakete simuliert wird; Weiterleiten der Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung, wobei die Bestätigungen später als die Nutzinformations-Datenpakete empfangen werden und eine höhere Priorität als die Nutzinformations-Datenpakete aufweisen, 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; und wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  • 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, die von einem Sender gesendet werden, wobei die Datenpakete in einer Uplink-Richtung einer bidirektionalen Datenverbindung 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; 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, zum Verringern eines Staufensters des Senders in der Uplink-Richtung, wenn mindestens ein anderes der Datenpakete verworfen wird; und eine Weiterleitungseinheit zum Weiterleiten des gespeicherten mindestens einen der Datenpakete in der Uplink-Richtung der bidirektionalen Datenverbindung und zum Weiterleiten einer Bestätigung in der Uplink-Richtung der bidirektionalen Datenverbindung, wobei die Bestätigung später als das gespeicherte mindestens eine der Datenpakete empfangen wird und den Empfang von in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigt, mit einer höheren Priorität als das gespeicherte mindestens eine der Datenpakete; wobei der Pufferspeicher (495) 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; und wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  • 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 (18)

  1. Verfahren zur Datenverkehrsflusssteuerung, mit den folgenden Schritten: • Empfangen von Datenpaketen, die von einem Sender gesendet werden, wobei die Datenpakete in einer Uplink-Richtung einer bidirektionalen Datenverbindung 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); • Verwerfen mindestens eines anderen der Datenpakete, wenn der Pufferspeicher keinen verfügbaren Platz zur Unterbringung des mindestens einen anderen der Datenpakete aufweist (130), womit in der Uplink-Richtung ein Staufenster des Senders verringert wird, wenn mindestens ein anderes der Datenpakete verworfen wird, • wobei das Empfangen aufweist, die Datenpakete in einem gemultiplexten Datenstrom zusammen mit Bestätigungen zu empfangen, wobei die Bestätigungen den Empfang von in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigen und in der Uplink-Richtung der bidirektionalen Datenverbindung weiterzuleiten sind; • Weiterleiten einer oder mehrerer der Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung, 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; • 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; und • wobei der insgesamt zugewiesene Platz zur Unterbringung des mindestens einen der Datenpakete während eines ablaufenden Datentransfers dynamisch justiert wird.
  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, ferner mit dem folgenden Schritt: Herausfiltern der Bestätigungen aus dem gemultiplexten Datenstrom.
  8. Verfahren gemäß einem der Ansprüche 1 bis 7, ferner mit dem folgenden Schritt: Speichern der Bestätigungen in einem Bestätigungspuffer.
  9. Verfahren gemäß Anspruch 8, ferner mit dem folgenden Schritt: Weiterleiten aller gespeicherten Bestätigungen mit einer höheren Priorität als das gespeicherte mindestens eine der Datenpakete.
  10. Verfahren zur Datenverkehrsflusssteuerung, mit den folgenden Schritten: • Empfangen von Nutzinformations-Datenpaketen, die von einem Sender gesendet werden, wobei die Nutzinformations-Datenpakete in einer Uplink-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); • 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), womit in der Uplink-Richtung ein Staufenster des Senders verringert wird, wenn die empfangenen Nutzinformations-Datenpakete verworfen werden; • Empfangen von Bestätigungen für in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragene Daten, wobei die Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung weiterzuleiten sind • 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; und • wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  11. Verfahren gemäß Anspruch 10, 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.
  12. Verfahren zur Datenverkehrsflusssteuerung, mit den folgenden Schritten: • Empfangen eines in einer Uplink-Richtung einer bidirektionalen Datenverbindung zu übertragenden Datenstroms, der von einem Sender gesendet wird, wobei der Datenstrom Nutzinformations-Datenpakete aufweist und Bestätigungen aufweist, wobei die Bestätigungen den Empfang von in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigen (310) und wobei die Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung weiterzuleiten sind; • Simulieren eines Verlusts eines in dem Datenstrom empfangenen Nutzinformations-Datenpakets, wobei der Verlust vorgeblich weiter signalabwärts in der Uplink-Richtung der bidirektionalen Datenverbindung auftritt (320), womit in der Uplink-Richtung ein Staufenster des Senders verringert wird, wenn der Verlust eines der empfangenen Nutzinformations-Datenpakete simuliert wird; • Weiterleiten der Bestätigungen in der Uplink-Richtung der bidirektionalen Datenverbindung, wobei die Bestätigungen später als die Nutzinformations-Datenpakete empfangen werden und eine höhere Priorität als die Nutzinformations-Datenpakete aufweisen • 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; und • wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  13. Verfahren gemäß Anspruch 12, wobei das Simulieren aufweist, das empfangene Datenpaket abzuwerfen, statt es in der einen Richtung der bidirektionalen Datenverbindung weiterzuleiten.
  14. Verfahren gemäß Anspruch 12 oder 13, wobei das Simulieren aufweist, das empfangene Datenpaket so zu manipulieren, dass es bei einem Adressat des Datenpakets nicht als ordnungsgemäß empfangenes Datenpaket erkannt wird.
  15. Verfahren gemäß einem der Ansprüche 12 bis 14, 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.
  16. Verfahren gemäß einem der Ansprüche 12 bis 15, 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.
  17. Vorrichtung (400), aufweisend: • einen Eingangsport (480) zum Empfangen von Datenpaketen, die von einem Sender gesendet werden, wobei die Datenpakete in einer Uplink-Richtung einer bidirektionalen Datenverbindung 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; • 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, zum Verringern eines Staufensters des Senders in der Uplink-Richtung, wenn mindestens ein anderes der Datenpakete verworfen wird; und • eine Weiterleitungseinheit zum Weiterleiten des gespeicherten mindestens einen der Datenpakete in der Uplink-Richtung der bidirektionalen Datenverbindung und zum Weiterleiten einer Bestätigung in der Uplink-Richtung der bidirektionalen Datenverbindung, wobei die Bestätigung später als das gespeicherte mindestens eine der Datenpakete empfangen wird und den Empfang von in einer Downlink-Richtung der bidirektionalen Datenverbindung übertragenen Daten bestätigt, mit einer höheren Priorität als das gespeicherte mindestens eine der Datenpakete; • wobei der Pufferspeicher (495) 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; und • wobei der insgesamt zugewiesene Platz während eines ablaufenden Datentransfers dynamisch justiert wird.
  18. Drahtlos-Gerät (400), das eine Vorrichtung (400) gemäß Anspruch 17 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 2008-12-18
US12/337,652 US8194543B2 (en) 2008-12-18 2008-12-18 Methods of data traffic shaping, apparatus and wireless device

Publications (2)

Publication Number Publication Date
DE102009044647A1 DE102009044647A1 (de) 2010-09-16
DE102009044647B4 true 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 서울대학교산학협력단 무선 자원 상태 예측 및 트래픽 제어를 위한 프록시 장치 및 방법
US20170093728A1 (en) 2015-09-25 2017-03-30 Fsa Technologies, Inc. Data flow prioritization system and method
JP7448015B2 (ja) 2020-08-20 2024-03-12 日本電信電話株式会社 シェーピングを行うための通信システム、装置、方法及びプログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060045008A1 (en) * 2004-08-27 2006-03-02 City University Of Hong Kong Queue-based active queue management process
US20070002863A1 (en) * 2005-06-14 2007-01-04 Microsoft Corporation Multi-stream acknowledgement scheduling
WO2008040725A1 (en) * 2006-10-02 2008-04-10 Ipwireless Inc. Efficient tcp ack prioritization in wireless networks
WO2008112456A1 (en) * 2007-03-14 2008-09-18 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

Family Cites Families (19)

* 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
JP3871327B2 (ja) * 2001-02-24 2007-01-24 インターナショナル・ビジネス・マシーンズ・コーポレーション 最適化されたスケーラブル・ネットワーク・スイッチ
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
JP2006245887A (ja) 2005-03-02 2006-09-14 Kddi Corp 無線mac処理部における送信パケットスケジューリング方法、プログラム及び無線通信装置
JP2006279867A (ja) 2005-03-30 2006-10-12 Nec Access Technica Ltd Adsl通信装置、プログラム及び方法
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
US20090073878A1 (en) * 2007-08-31 2009-03-19 Kenneth Gustav Carlberg Usage based queuing with accounting for wireless access points
ATE505006T1 (de) * 2007-12-06 2011-04-15 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 패킷 전송 및 수신 방법과, 이를 지원하는 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060045008A1 (en) * 2004-08-27 2006-03-02 City University Of Hong Kong Queue-based active queue management process
US20070002863A1 (en) * 2005-06-14 2007-01-04 Microsoft Corporation Multi-stream acknowledgement scheduling
WO2008040725A1 (en) * 2006-10-02 2008-04-10 Ipwireless Inc. Efficient tcp ack prioritization in wireless networks
WO2008112456A1 (en) * 2007-03-14 2008-09-18 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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROHDE & SCHWARZ: R & S AMU200A Baseband Signal Generator and Fading Simulator, Specifications, Version 01.00, April 2007, Firmenschrift *

Also Published As

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

Similar Documents

Publication Publication Date Title
DE102009044647B4 (de) Verfahren zur Datenverkehrsflusssteuerung, Vorrichtung und Drahtlos-Gerät
DE19983404B4 (de) Verfahren und Vorrichtung zur Verwendung bei der Einstellung eines TCP Gleitfensters
DE69738359T2 (de) System zur Verbesserung des Datendurchsatzes einer TCP/IP Netzwerkverbindung mit langsamen Rückkanal
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE60133324T2 (de) Schubsdatenpaket zur Minimierung von Datenpufferungsverzögerung
DE60317837T2 (de) Verfahren und System zur Messung von Last und Kapazität auf einem Kanal mit variabler Kapazität
DE60023019T2 (de) Verfahren und system zur ablösung oder regeneration von quittierungspaketen in adsl kommunikationen
DE112013000398B4 (de) Multisprung-Fehlerbehebung
DE69025713T2 (de) Dynamische Fensterbestimmung in einem Datennetzwerk
DE69834763T2 (de) Verfahren zur Unterstützung von verbindungsindividuellen Warteschlangen für rückgekoppelte Verkehrssteuerung
DE69025558T2 (de) Verfahren und Vorrichtung zur Überlastregelung in einem Datennetzwerk
DE3780800T2 (de) Anordnung zur ueberlastregelung fuer paketvermittlungssystem.
DE60211322T2 (de) Empfängerinitiierte Inkrementierung der Übertragungsrate
US20050213586A1 (en) System and method to increase network throughput
DE112013000411T5 (de) Benachrichtigung durch Netzwerkelement über Paketverluste
DE102020105776A1 (de) Kostengünstige Überlastungsisolierung für verlustfreies Ethernet
DE112020006828T5 (de) Verbessern einer Ende-zu-Ende-Überlastungsreaktion unter Verwendung von adaptivem Routing und Überlastungshinweis-basierter Drosselung für IP-geroutete Rechenzentrumsnetzwerke
CN101971578B (zh) Tcp分组间距
DE112016002847T5 (de) Dienstgüte in einem drahtlosen Backhaul
EP4080829A1 (de) Dienstklasseneinstellungsverfahren, gerät, vorrichtung und speichermedium
DE602004010056T2 (de) Verfahren und System zur Verwaltung des Netzwerkverkehrs unter Berücksichtung von mehreren Zwangsbedingungen
EP1168753A1 (de) Verfahren und Mittel zur Übertragung von Daten unterschiedlicher Dienstqualität in Internet-Protokoll Datagrammen
DE60311065T2 (de) Datenübertragungsverfahren für ein mehrbenutzer-mehrpunkt-zu-mehrpunkt-digitaldatenübertragungssystem
DE112004002544B4 (de) Verfahren, System und Programm zur Identifizierung von Datenüberlauf
DE60318252T2 (de) Verfahren und vorrichtungen zur datenübertragung zwischen speichernetzwerken

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