DE60131890T2 - Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung - Google Patents

Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung Download PDF

Info

Publication number
DE60131890T2
DE60131890T2 DE60131890T DE60131890T DE60131890T2 DE 60131890 T2 DE60131890 T2 DE 60131890T2 DE 60131890 T DE60131890 T DE 60131890T DE 60131890 T DE60131890 T DE 60131890T DE 60131890 T2 DE60131890 T2 DE 60131890T2
Authority
DE
Germany
Prior art keywords
protocol
tcp
packet
header
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.)
Expired - Lifetime
Application number
DE60131890T
Other languages
English (en)
Other versions
DE60131890D1 (de
Inventor
Fred A. Roswell BUNN
Thomas L. Gainesville JOHNSON
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.)
Broadcom Corp
Original Assignee
Broadcom Corp
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 Broadcom Corp filed Critical Broadcom Corp
Application granted granted Critical
Publication of DE60131890D1 publication Critical patent/DE60131890D1/de
Publication of DE60131890T2 publication Critical patent/DE60131890T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
    • H03M7/3088—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method employing the use of a dictionary, e.g. LZ78
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2801—Broadband local area networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4782—Web browsing, e.g. WebTV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6402—Address allocation for clients
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Description

  • Hintergrund der Erfindung
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft allgemein Kommunikationssysteme. Genauer gesagt betrifft die vorliegende Erfindung ein Kabelmodemsystem, ein Verfahren und ein Computerprogramm-Produkt zum Optimieren der Übertragung von TCP/IP-Datenverkehr über ein DOCSIS-Netzwerk.
  • Verwandte Fachgebiete
  • Herkömmliche Kabelmodemsysteme verwenden mit DOCSIS (Data Over Cable System Interface Specifikation, Spezifikation für die Systemschnittstelle für die Übertragung von Daten über Kabel) konforme Geräte und Protokolle, um Datenpakete zwischen einem oder mehr Kabelmodems und einem Cable Modem Termination System (CMTS) zu übermitteln. DOCSIS bezieht sich im Allgemeinen auf eine Gruppe von Spezifikationen, die branchenweit gültige Standards für Kabel-Kopfstellen und Kabelmodem-Geräte definieren. Teilweise legt DOCSIS Anforderungen und Zielsetzungen für verschiedene Aspekte von Kabelmodemsystemen dar, welche Betriebsunterstützungssysteme, Verwaltung, Datenschnittstellen sowie Datentransport auf der Netzwerkschicht, auf der Sicherungsschicht und auf der Bitübertragungsschicht für Kabelmodemsysteme umfassen.
  • DOCSIS 1.1 ermöglicht die Unterdrückung redundanter Informationen in Paketen mittels einer Funktion, die als PHS (Payload Header Suppression, Nutzdaten-Header-Unterdrückung) bezeichnet wird. PHS in DOCSIS ermöglicht die Unterdrückung von sich nicht ändernden Bytes in einem Upstream-Datenstrom für ein bestimmtes Kabelmodem, (das heißt eine bestimmte SD). Diese PHS-Funktion ist hauptsächlich für sich nicht ändernde Pakettypen mit fester Länge konzipiert. Es handelt sich dabei um einen Byte-orientierten Unterdrückungsmechanismus, der jedes beliebige Protokoll unterstützt, das in dem DOCSIS-Netzwerk übertragen werden könnte.
  • Die Byte-orientierte Unterdrückung von DOCSIS PHS ist nicht so effizient wie ein feldorientiertes Schema zur Unterdrückung von Protokoll-Headern. Die Header-Bytes sind für jede TCP-Verbindung verschieden. Auch ist DOCSIS PHS nicht in der Lage, mehrere TCP-Verbindungen innerhalb desselben Datenstroms, das heißt derselben Dienstekennungen (SID), wobei es sich um den üblichen Anwendungsfall handelt, auf effiziente Weise handzuhaben. Diese Beschränkung könnte in gewisser Weise überwunden werden, indem mehrere Regeln zur Header-Unterdrückung für jede TCP-Sitzung auf einer SID reserviert werden. Leider werden bei diesem Ansatz CMTS-Ressourcen verbraucht, und er ist nicht sehr effizient.
  • Die Modifikation von DOCSIS-PHS-Regeln erfordert eine Vollduplex-Befehlstransaktion zwischen dem Kabelmodem und dem Cable Modem Termination System (CMTS). Um TCP/IP-Datenverkehr unter Verwendung von DOCSIS PHS effektiv zu unterdrücken, muss die Unterdrückungsregel jedes Mal aktualisiert werden, wenn sich der Header ändert, wodurch eine Verzögerung verursacht wird. Bei einem TCP/IP-Datenstrom verringert diese Verzögerung die Effizienz der Header-Unterdrückung deutlich, weil Pakete ohne Unterdrückung übertragen werden müssen, bis die Modifikation der Regel durch das CMTS bestätigt ist.
  • Mit den DOCSIS-PHS-Techniken können keine sich dynamisch ändernden Felder unterdrückt werden. TCP-Header-Felder wie "ACK", "SEQUENCE NUMBER" und "WINDOW SIZE" ändern sich während einer TCP/IP-Verbindungssitzung oft. Diese Felder lassen sich gemäß den DOCSIS-PHS-Regeln nicht unterdrücken.
  • DOCSIS-Kabelmodem-Netzwerke sind so ausgelegt, dass sie Datenverkehr vom Typ 802.3 (Ethernet) handhaben können. Das typische Datenverkehrsmuster in einem DOCSIS-Netzwerk ist TCP/IP, wovon die Suche im Web, E-Mail und FTP-Übertragungen den größten Teil ausmachen. Bei den meisten in der Upstream-Richtung eines DOCSIS-Netzwerks übertragenen Paketen handelt es sich um TCP-Bestätigungen (ACK-Pakete). Da es sich um einen Transport nach 802.3 handelt, handhabt das DOCSIS-Protokoll die TCP-Bestätigungen und dergleichen nicht sehr effizient.
  • Es werden ein System, ein Verfahren und ein Computerprogramm-Produkt benötigt, um die Übertragung von TCP/IP-Datenverkehr über ein DOCSIS-Netzwerk zu erkennen und zu optimieren. Ferner werden ein System, ein Verfahren und ein Computerprogramm-Produkt benötigt, um die Übertragung von TCP/IP-Datenverkehr über ein DOCSIS-Netzwerk zu erkennen und zu optimieren, durch welches sich ändernde und sich nicht ändernde Felder zwischen TPC-Protokollpaketen in einem TCP-Verbindungsdatenstrom gehandhabt werden.
  • Das US-Patent Nr. 6 032 197 A offenbart die Komprimierung von sich nicht ändernden Header-Feldern von Datenpaketen. Ein Komprimierungsbitwert gibt an, ob ein Datenpaket mit voller Länge oder ein komprimiertes Datenpaket übertragen worden ist.
  • In der Veröffentlichung von Jacobson V., "Compressing TCP/IP Headers for Low-Speed Serial Links", Network Working Group, Februar 1990 (1990-02), XP002139708, wird ein Verfahren zum Komprimieren von TCP/IP-Headern offenbart. Gemäß dieser Veröffentlichung werden redundante Felder, die sich mit der Zeit nicht ändern, aus dem Header entfernt. Anstatt der Felder selbst werden nur die Unterschiede bei den sich ändernden Feldern gesendet.
  • Es können jedoch verschiedene Unterdrückungstechniken für das Unterdrücken von Datenpaketen geeignet sein. Zum Beispiel ist unter Umständen die Delta-Codierung für einen bestimmten Strom von Datenpaketen nicht geeignet, wenn die Änderungen an den nicht-redundanten Feldern umfangreich sind. In diesem Fall kann die Delta-Codierung die Datenpakete nicht komprimieren.
  • Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zum Optimieren der Übertragung von TCP/IP-Datenverkehr über ein DOCSIS-Netzwerk bereitzustellen, welche je nach Art des Datenverkehrs die Verwendung unterschiedlicher Komprimierungstechniken ermöglicht.
  • Dieses Problem wird durch die Erfindung gemäß dem angehängten Anspruch 1 gelöst. Demgemäß wird eine Indexnummer mit den Paketen kommuniziert. Diese Indexnummer gibt eine Technik zur Unterdrückung von Paket-Headern an sowie die Regeln, die mit dem Unterdrücken und Rekonstruieren eines Pakets gemäß der Technik zur Unterdrückung von Paket-Headern verbunden sind. Der Empfänger wird über die Unterdrückungstechnik und geeignete Regeln zum Rekonstruieren des komprimierten Pakets informiert. Diese Regeln können aus einer Tabelle entnommen werden, die der Indexnummer zugeordnet ist. Außerdem wird ein Framing-Protokoll empfangen, um jeden TCP-Verbindungsdatenstrom zu trennen und zu identifizieren. Dadurch können mehrere Datenströme gleichzeitig übertragen werden. Der Empfän ger kann jeden Datenstrom unter Verwendung des Framing-Protokolls identifizieren und die unkomprimierten Pakete unter Verwendung der Indexnummer rekonstruieren.
  • Kurze Beschreibung der Figuren
  • Die beigefügten Zeichnungen, die in dieses Dokument aufgenommen wurden und einen Bestandteil der Anmeldung bilden, veranschaulichen die vorliegende Erfindung und dienen ferner zusammen mit der Beschreibung dazu, die Prinzipien der Erfindung zu erläutern und es einem Fachmann auf dem betreffenden Gebiet zu ermöglichen, die Erfindung auszuführen und zu verwenden.
  • 1 ist ein übergeordnetes Blockdiagramm eines Kabelmodemsystems gemäß Ausführungsbeispielen der vorliegenden Erfindung.
  • 2 ist ein schematisches Blockdiagramm eines Cable Modem Termination Systems (CMTS) gemäß Ausführungsbeispielen der vorliegenden Erfindung.
  • 3 ist ein schematisches Blockdiagramm eines Kabelmodems gemäß Ausführungsbeispielen der vorliegenden Erfindung.
  • 4 ist ein Ablaufdiagramm eines Verfahrens zum Unterstützen erweiterter Protokolle in einem Kabelmodemsystem gemäß Ausführungsbeispielen der vorliegenden Erfindung.
  • 5 ist ein Ablaufdiagramm eines Verfahrens zum Unterstützen erweiterter Protokolle in einem Kabelmodemsystem gemäß Ausführungsbeispielen der vorliegenden Erfindung.
  • 6A ist ein Blockdiagramm eines unkomprimierten Pakets, das in der Regel von einem Kabelmodem gemäß Ausführungsbeispielen der vorliegenden Erfindung empfangen wird.
  • 6B ist ein Blockdiagramm eines von einem Kabelmodem gemäß Ausführungsbeispielen der vorliegenden Erfindung komprimierten Pakets.
  • 6C ist ein Blockdiagramm einer einzelnen SID, die mehrere Pakete enthält, die von einem Kabelmodem unter Verwendung verschiedener Techniken zur Unterdrückung von Paket-Headern gemäß Ausführungsbeispielen der vorliegenden Erfindung komprimiert wurden.
  • 7 ist ein Ablaufdiagramm eines Verfahrens zum Komprimieren von Paketen unter Verwendung verschiedener Techniken zur Unterdrückung von Paket-Headern gemäß Ausführungsbeispielen der vorliegenden Erfindung.
  • 8 ist ein Ablaufdiagramm eines Verfahrens zum Dekomprimieren von Paketen, die unter Verwendung verschiedener Techniken zur Unterdrückung von Paket-Headern gemäß Ausführungsbeispielen der vorliegenden Erfindung komprimiert wurden.
  • 9A ist ein Diagramm eines beispielhaften 802.3/IP/UDP/RTP-Headers.
  • 9B ist ein Diagramm eines RTP-Protokollpakets.
  • 10 ist ein Diagramm, das ein Steuerwert-Byte veranschaulicht, das während des Einsatzes einer Technik zur Unterdrückung von RTP-Headern verwendet wird.
  • 11 ist ein übergeordnetes Ablaufdiagramm, das ein Verfahren zur Unterdrückung von RTP-Headern veranschaulicht.
  • 12A ist ein Ablaufdiagramm, das ein Verfahren zum Unterdrücken eines RTP-Headers unter Verwendung einer Technik zur Unterdrückung von RTP-Headern gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 12B ist ein Ablaufdiagramm, das ein Verfahren zum Festlegen des Inkrements eines IP-Paket-ID-Felds in einem RTP-Header gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 13 ist ein Ablaufdiagramm, das ein Verfahren zum Rekonstruieren eines RTP-Headers unter Verwendung einer Technik zur Unterdrückung von RTP-Headern gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 14A ist ein Diagramm, das einen beispielhaften 802.3/IP/TCP-Header veranschaulicht.
  • 14B ist ein Diagramm, das ein TCP-Protokollpaket veranschaulicht.
  • 15 ist ein Diagramm, das ein TCP-Protokollpaket veranschaulicht, wobei Felder hervorgehoben sind, die sich von Paket zu Paket ändern können.
  • 16A ist ein übergeordnetes Ablaufdiagramm, das ein Verfahren für eine Technik zur Delta-codierten Header-Unterdrückung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 16B ist ein übergeordnetes Ablaufdiagramm, das ein Verfahren für eine Technik zur Delta-codierten Rekonstruktion von Headern gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 17 ist ein Diagramm, das ein Änderungs-Byte gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 18 ist ein Diagramm, das einen endgültigen codierten Datenstrom gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 19 ist ein Diagramm, das die Übertragungsreihenfolge von Daten bei der Unterdrückung von TCP-Headern für einen Zustand des Nichterlernens gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 20 ist ein Diagramm, das die Übertragungsreihenfolge von Daten bei der Unterdrückung von TCP-Headern für einen Zustand des Erlernens gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 21 ist ein Ablaufdiagramm, das ein Verfahren zur Unterdrückung von TCP-Headern gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 22 ist ein Ablaufdiagramm, das ein Verfahren zur Rekonstruktion von TCP-Headern gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 23 ist ein Diagramm, das ein beispielhaftes Computersystem veranschaulicht.
  • Die Merkmale, Aufgaben und Vorteile der vorliegenden Erfindung werden aus der weiter unten dargelegten, ausführlichen Beschreibung noch besser verständlich, wenn diese zusammen mit den Zeichnungen betrachtet wird, in denen identische Bezugszeichen durchgängig entsprechende Elemente bezeichnen. In den Zeichnungen geben identische Bezugszeichen im Allgemeinen identische, funktionell ähnliche und/oder strukturell ähnliche Elemente an. Die Zeichnung, in der ein Element jeweils zum ersten Mal vorkommt, ist durch die ganz links befindliche(n) Ziffer(n) in dem entsprechenden Bezugszeichen angegeben.
  • Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele
  • Während die vorliegende Erfindung in diesem Dokument unter Bezugnahme auf veranschaulichende Ausführungsbeispiele für bestimmten Anwendungen beschrieben ist, versteht es sich, dass die Erfindung nicht darauf beschränkt ist. Die Fachleute auf diesem Gebiet, die Zugang zu den in diesem Dokument bereitgestellten Lehren haben, werden zusätzliche Modifikationen, Anwendungen und Ausführungsbeispiele erkennen, die in dem Schutzumfang dieser Erfindung liegen, sowie zusätzliche Bereiche, in denen die vorliegende Erfindung von beträchtlichem Nutzen wäre.
  • A. Kabelmodemsystem gemäß Ausführungsbeispielen der vorliegenden Erfindung
  • 1 ist ein übergeordnetes Blockdiagramm eines beispielhaften Kabelmodemsystems 100 gemäß Ausführungsbeispielen der vorliegenden Erfindung. Das Kabelmodemsystem 100 ermöglicht Sprachkommunikation-, Video- und Datendienste auf der Grundlage eines bidirektionalen Transfers von paketbasiertem Datenverkehr, wie beispielsweise IP-Datenverkehr (Internet Protocol), zwischen einer Kabelsystem-Kopfstelle 102 und einer Vielzahl von Kabelmodems über ein Netzwerk 110 mit HFC-Kabeln (hybriden Glasfaser-Koaxialkabeln). Bei dem beispielhaften Kabelmodemsystem 100 sind aus Gründen der Übersichtlichkeit nur zwei Kabelmodems 106 und 108 gezeigt. Im Allgemeinen kann das Kabelmodemsystem der vorliegenden Erfindung jede beliebige Anzahl von Kabelmodems umfassen.
  • Die Kabel-Kopfstelle 102 umfasst wenigstens ein Cable Modem Termination System (CMTS) 104. Das CMTS 104 ist derjenige Bereich der Kabel-Kopfstelle 102, der den Upstream- und Downstream-Transfer von Daten zwischen der Kabel-Kopfstelle 102 und den Kabelmodems 106 und 108 verwaltet, die sich auf dem Gelände des Kunden befinden. Das CMTS 104 sendet mittels Broadcast Informationen als kontinuierlich übertragenes Signal gemäß einer als Time Division Multiplexing (TDM) bezeichneten Zeitmultiplextechnik in Downstream-Richtung an die Kabelmodems 106 und 108. Zusätzlich steuert das CMTS 104 die Upstream-Übertragung von Daten von den Kabelmodems 106 und 108 an sich selbst, indem es jedem der Kabelmodems 106 und 108 kurze Zeiträume zuteilt, in denen Daten transferiert werden können. Gemäß dieser Time Domain Multiple Access (TDMA) genannten Technik darf jedes der Kabelmodems 106 und 108 während einer Übertragungsmöglichkeit, die ihm von dem CMTS 104 zugewiesen wurde, Informationen nur als kurze Burst-Signale in Upstream-Richtung senden.
  • Wie in 1 gezeigt, dient das CMTS 104 ferner als Schnittstelle zwischen dem HFC-Netzwerk 110 und einem paketvermittelten Netzwerk 112, wobei gegebenenfalls von den Kabelmodems 106 und 108 empfangene IP-Pakete zu dem paketvermittelten Netzwerk 112 und von dem paketvermittelten Netzwerk 112 empfangene IP-Pakete zu den Kabelmodems 106 und 108 transferiert werden. In Ausführungsbeispielen umfasst das paketvermittelte Netzwerk 112 das Internet.
  • Zusätzlich zu dem CMTS 104 kann die Kabel-Kopfstelle 102 auch einen oder mehrere Internet-Router umfassen, um die Verbindung zwischen dem CMTS 104 und dem paketvermittelten Netzwerk 112 zu erleichtern, sowie einen oder mehrere Server, um die notwendigen Aufgaben zur Netzwerkverwaltung durchzuführen.
  • Das HFC-Netzwerk 110 stellt eine Punkt-zu-Mehrpunkt-Topologie für den zuverlässigen und sicheren Hochgeschwindigkeitstransport von Daten zwischen der Kabel-Kopfstelle 102 und den Kabelmodems 106 und 108 auf dem Gelände des Kunden bereit. Wie Fachleute auf dem bzw. den relevanten Gebiet(en) erkennen, kann das HFC-Netzwerk 110 Koaxialkabel, Glasfaserkabel oder eine Kombination aus Koaxialkabeln und Glasfaserkabeln umfassen, die über einen oder mehrere Glasfaserknoten verbunden sind.
  • Jedes der Kabelmodems 106 und 108 fungiert als Schnittstelle zwischen dem HFC-Netzwerk 110 und wenigstens einer angeschlossenen Benutzervorrichtung. Insbesondere führen die Kabelmodems 106 und 108 die Funktionen aus, die notwendig sind, um über das HFC-Netzwerk 110 empfangene Downstream-Signale in IP-Pakete zum Empfang durch eine angeschlossene Benutzervorrichtung zu konvertieren. Zusätzlich führen die Kabelmodems 106 und 108 die Funktionen aus, die notwendig sind, um von der angeschlossenen Benutzervorrichtung empfangene IP-Datenpakete in Upstream-Burst-Signale zu konvertieren, die für den Transfer über das HFC-Netzwerk 110 geeignet sind. Bei dem beispielhaften Kabelmodemsystem 100 ist aus Gründen der Übersichtlichkeit nur gezeigt, dass jedes der Kabelmodems 106 und 108 eine einzelne Benutzervorrichtung unterstützt. Im Allgemeinen ist jedes der Kabelmodems 106 und 108 in der Lage, eine Vielzahl von Benutzervorrichtungen zur Kommunikation über das Kabelmodemsystem 100 zu unterstützen. Benutzervorrichtungen können PCs, Datenterminalgeräte, Telefonvorrichtungen, Breitband-Medienabspielgeräte, über das Netzwerk gesteuerte Geräte oder jegliche andere Vorrichtungen umfassen, die in der Lage sind, Daten über ein paketvermitteltes Netzwerk zu übertragen oder zu empfangen.
  • Bei dem beispielhaften Kabelmodemsystem 100 stellt das Kabelmodem 106 ein herkömmliches, DOCSIS-konformes Kabelmodem dar. Anders ausgedrückt überträgt das Kabelmodem 106 Datenpakete an das CMTS 104 in Formaten, welche die in der DOCSIS-Spezifikation dargelegten Protokollen einhalten. Das Kabelmodem 108 ist gleichfalls in der Lage, Datenpakete in den Standard-DOCSIS-Formaten an das CMTS 104 zu übertragen. Gemäß Ausführungsbeispielen der vorliegenden Erfindung ist das Kabelmodem 108 jedoch auch so konfiguriert, dass es Datenpakete unter Verwendung von proprietären Protokollen an das CMTS 104 überträgt, die über die DOCSIS-Spezifikation hinausgehen. Trotzdem ist das Kabelmodem 108 vollständig mit den DOCSIS-konformen Kabelmodems, wie beispielsweise dem Kabelmodem 106, und mit DOCSIS-konformen CMTS-Geräten interoperabel. Die Art und Weise, wie das Kabelmodem 108 funktioniert, um Daten zu transferieren, wird in diesem Dokument noch ausführlich beschrieben.
  • Außerdem funktioniert das CMTS 104 in dem beispielhaften Kabelmodemsystem 100 so, dass es zu ihm übertragene Datenpakete gemäß den in der DOCSIS-Spezifikation dargelegten Protokollen empfängt und verarbeitet. Gemäß Ausführungsbeispielen der vorliegenden Erfindung kann das CMTS 104 jedoch auch so funktionieren, dass es Datenpakete empfängt und verarbeitet, die unter Verwendung proprietärer Protokolle formatiert sind, die über diejenigen hinausgehen, die von der DOCSIS-Spezifikation bereitgestellt werden, wie beispielsweise von dem Kabelmodem 108 übertragene Datenpakete. Die Art und Weise, wie das CMTS 104 funktioniert, um Daten zu empfangen und zu verarbeiten, wird in diesem Dokument ebenfalls noch ausführlich beschrieben.
  • B. Komponenten des beispielhaften Kabelmodemsystems gemäß Ausführungsbeispielen der vorliegenden Erfindung
  • 2 zeigt ein schematisches Blockdiagramm einer Implementierung des CMTS 104 des Kabelmodemsystems 100, das beispielhalber dargestellt ist und die vorliegende Erfindung nicht beschränken soll. Das CMTS 104 ist so konfiguriert, dass es Signale von dem HFC-Netzwerk 110, von dem ein Teil durch das Glasfaserkabel 202 in 2 dargestellt ist, empfängt und an dieses überträgt. Demgemäß wird das CMTS 104 als ein Empfängerteil und ein Senderteil beschrieben.
  • Der Senderteil umfasst eine Umwandlungsstufe Glasfaser zu Koax 204, einen Funkfrequenzeingang 206, einen Splitter 214 und eine Vielzahl von Burst-Empfängern 216. Der Empfang beginnt mit dem Erhalt von Upstream-Burst-Signalen, die von einem oder mehreren Kabelmodems stammen, durch die Umwandlungsstufe Glasfaser zu Koax 204 über das Glasfaserkabel 202. Die Umwandlungsstufe Glasfaser zu Koax 204 leitet die empfangenen Burst-Signale über das Koaxialkabel 208 an den Funkfrequenzeingang (RF-Eingang) 206. Bei Ausführungsbeispielen weisen diese Upstream-Burst-Signale spektrale Charakteristika innerhalb des Frequenzbereichs von ungefähr 5–42 MHz auf.
  • Die empfangenen Signale werden von dem Funkfrequenzeingang 206 dem Splitter 214 des CMTS 104 bereitgestellt, der die Funkfrequenz-Eingangssignale in N gesonderte Kanäle trennt. Jeder der N gesonderten Kanäle wird dann einem gesonderten Burst-Empfänger 216 bereitgestellt, der so funktioniert, dass er die auf jedem einzelnen Kanal empfangenen Signale gemäß entweder einer QPSK-Technik (Quadraturphasenumtastung) oder 16-QAM-Technik (Quadratur-Amplitudenmodulation) demoduliert, um die zugrunde liegenden Informationssignale zurückzugewinnen. Jeder Burst-Empfänger 216 wandelt außerdem die zugrunde liegenden Informationssignale von einer analogen Form in eine digitale Form um. Diese digitalen Daten werden anschließend der Kopfstellen-Medienzugriffssteuerung (Kopfstellen-MAC) 218 bereitgestellt.
  • Die Kopfstellen-MAC 218 funktioniert so, dass sie die digitalen Daten gemäß der DOCSIS-Spezifikation, und gegebenenfalls gemäß proprietären Protokollen, die über die DOCSIS-Spezifikation hinausgehen, verarbeitet, wie noch ausführlich in diesem Dokument beschrieben wird. Die Funktionen der Kopfstellen-MAC 218 können in Hardware oder in Software implementiert sein. In der beispielhaften Implementierung von 2 sind die Funktionen der Kopfstellen-MAC 218 sowohl in Hardware als auch in Software implementiert. Softwarefunktionen der Kopfstellen-MAC 218 können entweder in dem Speicher mit wahlfreien Zugriff (RAM) 220 oder in dem Nur-Lese-Speicher (ROM) 218 gespeichert sein und von der CPU 222 ausgeführt werden. Die Kopfstellen-MAC ist mit diesen Elementen über eine Backplane-Schnittstelle 220 und ein gemeinsam genutztes Kommunikationsmedium 232 elektrisch verbunden. Bei Ausführungsbeispielen kann das gemeinsam genutzte Kommunikationsmedium 232 einen Computer-Bus oder ein Datennetzwerk mit Mehrfachzugriff umfassen.
  • Die Kopfstellen-MAC 218 ist außerdem sowohl über die Backplane-Schnittstelle 220 als auch über das gemeinsam genutzte Kommunikationsmedium 232 elektrisch mit der Ethernet-Schnittstelle 224 verbunden. Bei Bedarf werden von der Kopfstellen-MAC 218 wiederhergestellte Ethernet-Pakete zu der Ethernet-Schnittstelle 224 transferiert, um über einen Router an das paketvermittelte Netzwerk 112 geliefert zu werden.
  • Der Senderteil des CMTS 104 umfasst einen Downstream-Modulator 226, ein AOW-Filter (Akustische Oberflächenwellen-Filter) 228, einen Verstärker 230, einen Zwischenfrequenzausgang (IF-Ausgang) 212, einen Funkfrequenz-Aufwärtswandler (RF-Aufwärtswandler) 210 und die Umwandlungsstufe Glasfaser zu Koax 204. Die Übertragung beginnt mit dem Generieren eines digitalen Broadcast-Signals durch die Kopfstellen-MAC 218. Das digitale Broadcast-Signal kann Daten umfassen, die ursprünglich über die Ethernet-Schnittstelle 224 von dem paketvermittelten Netzwerk 112 empfangen wurden. Die Kopfstellen-MAC 218 gibt das digitale Broadcast-Signal an den Downstream-Modulator 226 aus, der es in eine analoge Form umwandelt und es gemäß entweder einer 64-QAM- oder einer 256-QAM-Technik einem Trägersignal aufmoduliert.
  • Das modulierte, von dem Downstream-Modulator 256 ausgegebene Signal wird in das AOW-Filter 228 eingegeben, das nur Spektralkomponenten des Signals durchlässt, welche innerhalb einer gewünschten Bandbreite liegen. Das gefilterte Signal wird dann an einen Verstärker 230 ausgegeben, der es verstärkt und an den Zwischenfrequenzausgang 212 ausgibt. Der Zwischenfrequenzausgang 212 leitet das Signal an den Funkfrequenz-Aufwärtswandler 210 weiter, der eine Aufwärtswandlung des Signals vornimmt. Bei Ausführungsbeispielen weist das aufwärts gewandelte Signal spektrale Charakteristika in dem Frequenzbereich von ungefähr 54–860 MHz auf. Das aufwärts gewandelte Signal wird dann über das Koaxialkabel 208 an die Umwandlungsstufe Glasfaser zu Koax 204 ausgegeben. Die Umwandlungsstufe Glasfaser zu Koax 204 sendet das Signal per Broadcast über das Glasfaserkabel 202 des HFC-Netzwerks 110.
  • 3 zeigt ein schematisches Blockdiagramm einer Implementierung des Kabelmodems 108 des Kabelmodemsystems 100, das beispielhalber dargestellt ist und die vorliegende Erfindung nicht beschränken soll. Das Kabelmodem 108 ist so konfiguriert, dass es Signale über den Koaxialanschluss 332 von 3 von dem HFC-Netzwerk 110 empfängt und an dieses überträgt. Demgemäß wird das Kabelmodem 108 als ein Empfängerteil und ein Senderteil beschrieben.
  • Der Empfängerteil umfasst ein Diplexfilter 302, einen Funkfrequenz-Tuner 304, ein AOW-Filter 306 und einen Verstärker 308 sowie einen Downstream-Empfänger 310. Der Empfang beginnt mit dem Erhalt eines von dem CMTS 104 stammenden Downstream-Signals durch das Diplexfilter 302. Das Diplexfilter 302 funktioniert so, dass es das Downstream-Signal isoliert und an den Funkfrequenz-Tuner 304 leitet. Bei Ausführungsbeispielen weist das Signal spektrale Charakteristika in dem Frequenzbereich von ungefähr 54–860 MHz auf. Der Funkfrequenz-Tuner 304 führt eine Abwärtswandlung des Signals durch und gibt es an das AOW-Filter 306 aus, das nur Spektralkomponenten des abwärts gewandelten Signals durchlässt, welche innerhalb einer gewünschten Bandbreite liegen. Das gefilterte Signal wird an den Verstärker 308 ausgegeben, der es verstärkt und an den Downstream-Empfänger 310 weitergibt. Eine automatische Verstärkungsregelung (AGC) wird dem Funkfrequenz-Tuner 304 von dem Downstream-Empfänger 310 bereitgestellt.
  • Der Downstream-Empfänger 310 demoduliert das verstärkte Signal gemäß entweder einer 64-QAM- oder einer 256-QAM-Technik, um das zugrunde liegende Informationssignal zurückzugewinnen. Der Downstream-Empfänger 310 wandelt außerdem das zugrunde liegende Informationssignal von einer analogen Form in eine digitale Form um. Diese digitalen Daten werden anschließend der Medienzugriffssteuerung (MAC) 314 bereitgestellt.
  • Die MAC 314 verarbeitet die digitalen Daten, die zum Beispiel Ethernet-Pakete für den Transfer an eine angeschlossene Benutzervorrichtung umfassen können. Die Funktionen der MAC 314 können in Hardware oder in Software implementiert sein. In der beispielhaften Implementierung von 3 sind die Funktionen der MAC 314 sowohl in Hardware als auch in Software implementiert. Softwarefunktionen der MAC 314 können entweder in dem RAM 322 oder in dem ROM 324 gespeichert sein und von der CPU 320 ausgeführt werden. Die MAC 314 ist mit diesen Elementen über ein gemeinsam genutztes Kommunikationsmedium 316 elektrisch verbunden. Bei Ausführungsbeispielen kann das gemeinsam genutzte Kommunikationsmedium einen Computer-Bus oder ein Datennetzwerk mit Mehrfachzugriff umfassen.
  • Die MAC ist außerdem über das gemeinsam genutzte Kommunikationsmedium 316 mit der Ethernet-Schnittstelle 318 elektrisch verbunden. Bei Bedarf werden von der MAC 314 wiederhergestellte Ethernet-Pakete zum Transfer an eine angeschlossene Benutzervorrichtung zu der Ethernet-Schnittstelle 318 transferiert.
  • Der Senderteil des Kabelmodems 108 umfasst einen Upstream-Burst-Modulator 326, ein Tiefpassfilter 328, einen Leistungsverstärker 330 und das Diplexfilter 302. Die Übertragung beginnt mit dem Aufbau eines Datenpakets durch die MAC 314. Das Datenpaket kann Daten umfassen, die ursprünglich über die Ethernet-Schnittstelle 318 von einer angeschlossenen Benutzervorrichtung empfangen wurden. Gemäß Ausführungsbeispielen der vorliegenden Erfindung kann die MAC 314 das Datenpaket gemäß den Protokollen formatieren, die in der DOCSIS-Spezifikation dargelegt sind, oder gegebenenfalls kann sie das Datenpaket gemäß einem proprietären Protokoll formatieren, das über diejenigen hinausgeht, die in der DOCSIS-Spezifikation dargelegt sind, wie noch ausführlich in diesem Dokument beschrieben wird. Die MAC 314 gibt das Datenpaket an den Upstream-Burst-Modulator 326 aus, der es in eine analoge Form umwandelt und es gemäß entweder einer QPSK- oder einer 16-QAM-Technik einem Trägersignal aufmoduliert.
  • Der Upstream-Burst-Modulator 326 gibt das modulierte Trägersignal an das Tiefpassfilter 328 aus, das nur Signale mit spektralen Charakteristika innerhalb einer gewünschten Bandbreite durchlässt. Bei Ausführungsbeispielen liegt die gewünschte Bandbreite in dem Frequenzbereich von ungefähr 5–42 MHz. Die gefilterten Signale werden dann in den Leistungsverstärker 330 eingebracht, der das Signal verstärkt und es dem Diplexfilter 302 bereitstellt. Die Verstärkung in dem Leistungsverstärker 330 wird durch den Burst-Modulator 326 reguliert. Das Diplexfilter 302 isoliert das verstärkte Signal und überträgt es während einer geplanten Burst-Möglichkeit in Upstream-Richtung über das HFC-Netzwerk 110.
  • C. Unterstützung erweiterter Protokolle für den Datentransfer gemäß Ausführungsbeispielen der vorliegenden Erfindung
  • Wie zuvor bereits angemerkt, senden gemäß Ausführungsbeispielen der vorliegenden Erfindung das Kabelmodem 108 und das CMTS 104 Daten bzw. empfangen Daten in proprietären Formaten, die über die Standard-DOCSIS-Protokolle hinausgehen. Zum Beispiel modifiziert bei Ausführungsbeispielen das Kabelmodem 108 Datenpakete gemäß einem proprietären Schema für die Header-Unterdrückung zur Übertragung an das CMTS 104, und beim Empfang der modifizierten Datenpakete rekonstruiert das CMTS 104 diese gemäß demselben proprietären Schema für die Header-Komprimierung.
  • In weiterer Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung ist das Kabelmodem 108 dennoch mit herkömmlichen, mit DOCSIS konformen CMTS-Geräten interoperabel, die, im Gegensatz zu dem CMTS 104, keine Unterstützung für erweiterte Protokolle bereitstellen. Das Kabelmodem 108 erreicht dies, indem es bestimmt, ob es mit einem CMTS kommuniziert, das erweiterte Protokolle unterstützt, wie beispielsweise dem CMTS 104, oder mit einem CMTS, das diese nicht unterstützt. Wenn das CMTS erweiterte Protokolle nicht unterstützt, transferiert das Kabelmodem 108 Daten, die gemäß den Standard-DOCSIS-Protokollen anstatt gemäß erweiterten Protokollen formatiert sind.
  • 4 zeigt ein Ablaufdiagramm 400 eines Verfahrens zum Unterstützen erweiterter Protokolle in einem Kabelmodemsystem gemäß Ausführungsbeispielen der vorliegenden Erfindung, das diesen Prozess noch ausführlicher erläutert. Die Erfindung ist jedoch nicht auf die Beschreibung beschränkt, die von dem Ablaufdiagramm 400 bereitgestellt wird. Das Ablaufdiagramm 400 wird unter weiterer Bezugnahme auf das beispielhafte CMTS 104 und auf das Kabelmodem 108 des Kabelmodemsystems 100 sowie unter Bezugnahme auf die beispielhafte Hardware-Implementierung des Kabelmodems 108 in 3 beschrieben.
  • In Schritt 402 sendet das Kabelmodem 108 eine Registrierungsnachricht an das CMTS 104, in der die Unterstützung eines erweiterten Protokolls bezeichnet ist. Im Hinblick auf die unter Bezugnahme auf 3 beschriebene, beispielhafte Implementierung des Kabelmodems 108 baut die MAC 314 diese Registrierungsnachricht, sowie alle übrigen MAC-Wartungsnachrichten auf, die von dem Kabelmodem 108 abgesetzt werden.
  • Bei Ausführungsbeispielen sendet das Kabelmodem 108 diese Registrierungsnachricht als Bestandteil eines Austausches von Registrierungsnachrichten, der zwischen einem Kabelmodem und einem CMTS durchgeführt werden muss, wenn das Kabelmodem zum ersten Mal in dem HFC-Netzwerk erscheint. Gemäß der DOCSIS-Spezifikation umfasst dieser Austausch von Registrierungsnachrichten im Allgemeinen das Senden einer Registrierungsanforderungsnachricht (REG-REQ) von dem Kabelmodem an das CMTS und das Senden einer Registrierungsantwortnachricht (REG-RSP) von dem CMTS an das Kabelmodem als Reaktion auf die empfangene REG-REQ-Nachricht. Dieses Registrierungsprotokoll ist nach dem Stand der Technik allgemein bekannt.
  • Bei Ausführungsbeispielen benachrichtigt das Kabelmodem 108 das CMTS 104, dass es ein erweitertes Protokoll unterstützt, indem es einen Deskriptor für die Unterstützung erweiterter Protokolle in einem anbieterspezifischen Informationsfeld der REG-REQ-Nachricht platziert, die es an das CMTS 104 sendet. Umgekehrt gibt bei solchen Ausführungsbeispielen das Fehlen eines Deskriptors für die Unterstützung erweiterter Protokolle in einem anbieterspezifischen Informationsfeld der REG-REQ-Nachricht an, dass ein Kabelmodem nur Standard-DOCSIS-Protokolle unterstützt.
  • In Schritt 404 empfängt das Kabelmodem 108 eine Antwort auf die Registrierungsnachricht von dem CMTS 104, welche angibt, ob das CMTS 104 das erweiterte Protokoll unterstützt oder nicht. Da das CMTS 104 des beispielhaften Kabelmodemsystems 100, wie oben erörtert, dieselben erweiterten Protokolle unterstützt wie das Kabelmodem 108, gibt die Antwort auf die Registrierungsnachricht an, dass das erweiterte Protokoll unterstützt wird. Wenn jedoch das CMTS 104 das erweiterte Protokoll nicht unterstützen würde (zum Beispiel wenn es sich um ein herkömmliches, DOCSIS-konformes CMTS handeln würde), dann würde die Antwort auf die Registrierungsnachricht eine Angabe enthalten, dass es dem CMTS 104 nicht gelungen ist, das erweiterte Protokoll zu erkennen. Zum Beispiel kann bei Ausführungsbeispielen, bei denen die Registrierungsnachricht eine REG-REQ-Nachricht umfasst, die einen Deskriptor für die Unterstützung erweiterter Protokolle in einem anbieterspezifischen Informationsfeld enthält, die Antwort eine REG-RSP-Nachricht sein, die angibt, dass es dem CMTS 104 nicht gelungen ist, den Deskriptor für die Unterstützung erweiterter Protokolle zu erkennen.
  • Wenn die Antwort auf die Registrierungsnachricht angibt, dass das erweiterte Protokoll von dem CMTS unterstützt wird, dann formatiert das Kabelmodem 108 Datenpakete für die Übertragung an das CMTS gemäß dem erweiterten Protokoll, wie in den Schritten 406 und 408 gezeigt. Wenn andererseits die Antwort auf die Registrierungsnachricht angibt, dass das CMTS das erweiterte Protokoll nicht unterstützt, dann formatiert das Kabelmodem 108 Datenpakete für die Übertragung an das CMTS gemäß Standard-DOCSIS-Protokollen, wie in den Schritten 406 und 410 gezeigt. Wie oben im Hinblick auf die beispielhafte Implementierung des in 3 gezeigten Kabelmodems 108 erörtert, ist die MAC 314 für das Formatieren von Datenpaketen zur Übertragung an das CMTS zuständig.
  • In alternativen Ausführungsbeispielen der vorliegenden Erfindung kann anstelle des oben beschriebenen Standard-DOCSIS-Protokolls mit REG-REQ und REG-RSP ein privater Kommunikationskanal verwendet werden, um die Schritte 402 und 404 des Ablaufdiagramms 400 zu implementieren. Zum Beispiel sendet in einem solchen Ausführungsbeispiel das CMTS 104 nach einer erfolgreichen Kabelmodemregistrierung eine UDP-Nachricht von dem Typ "Unicast" an das Kabelmodem 108, die angibt, dass das CMTS 104 in der Lage ist, erweiterte Protokolle zu unterstützen (in 4 nicht gezeigter Schritt). Wenn das Kabelmodem 108 ein erweitertes Protokoll unterstützt, antwortet es auf die UDP-Nachricht, indem es eine UDP-Antwort sendet, die angibt, welches erweiterte Protokoll es unterstützt. Gemäß dieser Technik umfasst die Registrierungsnachricht von Schritt 402 die UDP-Antwort von dem Kabelmodem 108. Bei Ausführungsbeispielen gibt die UDP-Antwort auch an, bis zu welchem Grad das Kabelmodem 108 in der Lage ist, das erweiterte Protokoll zu unterstützen.
  • Wenn das Kabelmodem kein erweitertes Protokoll unterstützt, sendet es keine Antwort auf die UDP-Nachricht. Bei Ausführungsbeispielen überträgt das CMTS 104 die UDP-Nachricht eine vorbestimmte Anzahl von Malen erneut, und wenn nach der vorbestimmten Anzahl von erneuten Übertragungen keine Antwort von dem Kabelmodem empfangen wurde, bestimmt das CMTS 104, dass das Kabelmodem keine erweiterten Protokolle unterstützt. Wenn das CMTS 104 jedoch eine geeignete UDP-Antwort von dem Kabelmodem 108 empfängt, erfasst es die Funktionen bezüglich erweiterter Protokolle des Kabelmodems 108 und antwortet mit einer zweiten UDP-Nachricht, welche angibt, ob es das von dem Kabelmodem 108 unterstützte, spezifische erweiterte Protokoll unterstützt oder nicht. Gemäß dieser Technik umfasst die Antwort auf die Registrierungsnachricht von Schritt 404 die zweite UDP-Nachricht von dem CMTS 104.
  • Das in dem Ablaufdiagramm 400 beschriebene Verfahren stellt die Interoperabilität zwischen einem Kabelmodem, das ein erweitertes Protokoll gemäß Ausführungsbeispielen der vorliegenden Erfindung unterstützt, und einem CMTS-Gerät, welches dasselbe Protokoll nicht unterstützt, sicher. In ähnlicher Weise ist ein CMTS, das ein erweitertes Protokoll gemäß Ausführungsbeispielen der vorliegenden Erfindung unterstützt, wie beispielsweise das CMTS 104, mit einem Kabelmodem interoperabel, welches dasselbe erweiterte Protokoll nicht unterstützt. Zum Beispiel ist das CMTS 104 mit herkömmlichen DOCSIS-konformen Kabelmodems interoperabel, die keine erweiterten Protokolle unterstützen, wie beispielsweise mit dem Kabelmodem 106. Das CMTS 104 erreicht dies, indem es bestimmt, ob ein empfangenes Paket von einem herkömmlichen, DOCSIS-konformen Kabelmodem, wie beispielsweise dem Kabelmodem 106, gesendet wurde, oder von einem Kabelmodem, das in der Lage ist, Daten unter Verwendung von erweiterten Protokollen zu senden, wie beispielsweise dem Kabelmodem 108, und indem es das Paket demgemäß verarbeitet.
  • 5 zeigt ein Ablaufdiagramm 500 eines Verfahrens zum Unterstützen erweiterter Protokolle in einem Kabelmodemsystem gemäß Ausführungsbeispielen der vorliegenden Erfindung, das diesen Prozess ausführlicher erläutert. Die Erfindung ist jedoch nicht auf die Beschreibung beschränkt, die von dem Ablaufdiagramm 500 bereitgestellt wird. Das Ablaufdiagramm 500 wird unter weiterer Bezugnahme auf das beispielhafte CMTS 104 und auf die Kabelmodems 106 und 108 des Kabelmodemsystems 100 sowie unter Bezugnahme auf die beispielhafte Hardware-Implementierung des CMTS 104 in 2 beschrieben.
  • In Schritt 502 empfängt das CMTS 104 eine Registrierungsnachricht von einem Kabelmodem, welche ein Protokoll für den Datentransfer angibt, das von dem Kabelmodem unterstützt wird. Im Hinblick auf das beispielhafte Kabelmodemsystem 100 von 1 kann die Registrierungsnachricht von dem Kabelmodem 106 stammen; in diesem Fall bezeichnet die Nachricht einen Datentransfer gemäß den Standard-DOCSIS-Protokollen, oder die Registrierungsnachricht kann von dem Kabelmodem 108 stammen; in diesem Fall bezeichnet die Nachricht einen Datentransfer gemäß einem erweiterten Protokoll. Bei Ausführungsbeispielen handelt es sich bei der Registrierungsnachricht um eine DOCSIS-REG-REQ-Nachricht, und das Vorhandensein eines Deskriptors für erweiterte Protokolle in einem anbieterspezifischen Feld der REG-REQ-Nachricht bezeichnet den Datentransfer gemäß einem erweiterten Protokoll, während das Fehlen des Deskriptors für erweiterte Protokolle den Datentransfer gemäß den Standard-DOCSIS-Protokollen bezeichnet.
  • In Schritt 504 weist das CMTS 104 dem Kabelmodem eine eindeutige Kabelmodem-ID zu und überträgt die Kabelmodem-ID an das Kabelmodem. Bei Ausführungsbeispielen umfasst die Kabelmodem-ID die primäre DOCSIS-Dienstekennung (SID), die von dem CMTS zugewiesen wird und die als Teil der DOCSIS-REG-RSP-Nachricht an das Kabelmodem übertragen wird. Im Hinblick auf die beispielhafte Implementierung des unter Bezugnahme auf 2 beschriebenen CMTS 104 ist die Kopfstellen-MAC 218 für das Zuweisen einer eindeutigen Kabelmodem-ID an das Kabelmodem zuständig.
  • In Schritt 506 erstellt das CMTS 104 in dem Speicher eine Zuordnung zwischen der Kabelmodem-ID und einem Protokollindikator, der das Protokoll für den Datentransfer angibt, das von dem Kabelmodem unterstützt wird. Im Hinblick auf die beispielhafte Implementierung des unter Bezugnahme auf 2 beschriebenen CMTS 104 wird diese Aufgabe durch die Kopfstellen-MAC 218 durchgeführt, welche die Kabelmodem-ID und den Protokollindikator als einander zugeordnete Werte entweder in dem ROM 218 oder in dem RAM 220 speichert. Bei Ausführungsbeispielen speichert das CMTS 104 die Kabelmodem-ID und den Protokollindikator als einander zugeordnete Werte in einer Nachschlagetabelle.
  • In Schritt 508 empfängt das CMTS 104 eine Anforderung für eine Übertragungsmöglichkeit von einem Kabelmodem, welche die dem Kabelmodem zugeordnete Kabelmodem-ID umfasst. Bei Ausführungsbeispielen wird die Anforderung in einem Anforderungs-Konkurrenzbereich empfangen, der durch eine DOCSIS-Zuordnungs-MAP definiert ist. Bei der Zuordnungs-MAP handelt es sich um eine MAC-Verwaltungsnachricht mit variabler Länge, die von dem CMTS auf dem Downstream-Kanal übertragen wird und die für ein bestimmtes Zeitintervall die Verwendungen beschreibt, für welche die Upstream-Bandbreite zur Verfügung gestellt werden muss. Die Zuordnungs-MAP ordnet Bandbreite in Form von grundlegenden Zeiteinheiten zu, die als Mini-Zeitschlitze bezeichnet werden. Eine bestimmte Zuordnungs-MAP kann einige Mini-Zeitschlitze als Zuteilung für ein bestimmtes Kabelmodem beschreiben, um darin Daten zu übertragen, und andere Mini-Zeitschlitze als verfügbar für eine konkurrierende Übertragung durch mehrere Kabelmodems. Die DOCSIS-Zuordnungs-MAP ist in der DOCSIS-Spezifikation beschrieben und nach dem Stand der Technik allgemein bekannt.
  • In Schritt 510 ordnet das CMTS 104 dem Kabelmodem als Antwort auf die Anforderung einer Übertragungsmöglichkeit eine Übertragungsmöglichkeit zu. Bei Ausführungsbeispielen ordnet die CMTS 104 dem Kabelmodem eine Übertragungsmöglichkeit zu, indem es dem Kabelmodem eine Anzahl von Mini-Zeitschlitzen in einer DOCSIS-Zuordnungs-MAP zur Upstream-Übertragung von Daten gemäß der DOCSIS-Spezifikation zuweist. Im Hinblick auf die beispielhafte Implementierung des unter Bezugnahme auf 2 beschriebenen CMTS 104 wird der Aufbau einer MAP-Zuordnungsnachricht durch die Kopfstellen-MAC 218 vorgenommen.
  • In Schritt 512 verwendet das CMTS 104 die Kabelmodem-ID aus der Anforderung der Übertragungsmöglichkeit, um auf den Protokollindikator zuzugreifen, welcher der Kabelmodem-ID zugeordnet wurde, die zuvor in Schritt 506 in dem Speicher gespeichert wurde. Bei Ausführungsbeispielen konsultiert das CMTS 104 eine Nachschlagetabelle, in der die Kabelmodem-ID dem Protokollindikator zuge ordnet ist. Im Hinblick auf die beispielhafte Implementierung des unter Bezugnahme auf 2 beschriebenen CMTS 104 wird dieser Schritt durch die Kopfstellen-MAC 218 durchgeführt.
  • In Schritt 514 verarbeitet das CMTS 104 von dem Kabelmodem während der zugeordneten Übertragungsmöglichkeit übertragene Daten gemäß dem durch den Indikator angegebenen Protokoll für den Datentransfer. Wenn zum Beispiel der Indikator angibt, dass ein erweitertes Protokoll unterstützt wird, wie in dem Fall des Kabelmodems 108, verarbeitet das CMTS 104 das Datenpaket, das es von dem Kabelmodem zu empfangen erwartet, gemäß einem erweiterten Protokoll. Wenn keine Unterstützung eines erweiterten Protokolls angegeben wird, wie in dem Fall des Kabelmodems 106, verarbeitet das CMTS 104 das Datenpaket, das es von dem Kabelmodem zu empfangen erwartet, gemäß den Standard-DOCSIS-Protokollen. Im Hinblick auf die beispielhafte Implementierung des unter Bezugnahme auf 2 beschriebenen CMTS 104 wird die Verarbeitung von Datenpaketen durch die Kopfstellen-MAC 218 vorgenommen.
  • Somit erfasst und speichert das CMTS 104 gemäß Ausführungsbeispielen der vorliegenden Erfindung während der Registrierung des Kabelmodems Informationen zu den Funktionen der Kabelmodems, mit denen es kommunizieren wird. Wenn das CMTS 104 anschließend einem Kabelmodem Upstream-Bandbreite zuordnet, greift es auf die gespeicherten Informationen zu, um zu bestimmen, wie die Daten verarbeitet werden sollen, die es von dem Kabelmodem zu empfangen erwartet. Diese Technik wird durch die TDMA-Aspekte eines Kabelmodemsystems erleichtert, das erfordert, dass dem CMTS bekannt ist, von welchem Kabelmodem es zu einem bestimmten Zeitpunkt Daten empfängt. Diese Technik ist vorteilhaft, weil sie die Verwendung von Protokollen erlaubt, die über DOCSIS hinausgehen, während gleichzeitig die Interoperabilität sichergestellt ist, indem die Standard-DOCSIS-Protokolle für die Registrierung, die Anforderung und die Zuteilung eingehalten werden.
  • 1. Unterdrückung von Paket-Headern
  • 6A bis 8 sind hilfreich für die Erklärung einer Art und Weise, wie Pakete gemäß Ausführungsbeispielen der vorliegenden Erfindung durch das Kabelmodem 108 komprimiert und durch das CMTS 104 dekomprimiert werden.
  • 6A stellt ein Datenpaket 605 dar, das durch eine Benutzervorrichtung für die Übertragung über das HFC-Netzwerk 110 generiert wurde. Das Datenpaket 605 umfasst einen MAC-Header 607, einen IP-Header 609, einen UDP-Header 611, einen RTP-Header 613 und Nutzdaten 615. In diesem Beispiel umfasst der MAC-Header 607 14 Byte, der IP-Header 609 umfasst 20 Byte, der UDP-Header 611 umfasst 12 Byte, der RTP-Header 613 umfasst 8 Byte und die Nutzdaten 615 umfassen, je nach Art der gerade gesendeten Daten, eine beliebige Menge von 1 bis N Byte.
  • Gemäß der vorliegenden Erfindung kann das Datenpaket 605 durch ein Anwendungsprogramm generiert werden, das auf der oben unter Bezugnahme auf 1 beschriebenen Benutzervorrichtung 116 ausgeführt wird. Zum Beispiel kann ein Anwendungsprogramm, das auf der Benutzervorrichtung 116 ausgeführt wird, Sprach- oder Dateninformationen für die Übertragung über das HFC-Netzwerk 110 generieren. Diese Sprach- oder Dateninformationen umfassen die Nutzdaten 615 des Datenpakets 605. Das auf der Benutzervorrichtung 116 ausgeführte Anwendungsprogramm hängt den IP-Header 609, den UDP-Header 611 und den RTP-Header 613 an die Nutzdaten 615 an, um eine Übertragung gemäß den Standard-IP-Protokollen zu ermöglichen. Eine Ethernet-Karte innerhalb der Benutzervorrichtung 116 hängt ferner den MAC-Header 607 an das Datenpaket 605 an, um eine Übertragung gemäß den Standard-Ethernet-Protokollen zu ermöglichen.
  • Beim Empfangen des Datenpakets 605 unterdrückt das Kabelmodem das Datenpaket 605 gemäß einer beliebigen gewünschten Technik zur Header-Unterdrückung. Beispiele für Techniken zur Header-Unterdrückung umfassen DOCSIS PHS sowie Techniken, die über die Standard-DOCSIS-Protokolle hinausgehen, wie beispielsweise dynamische Delta-Codierung und RTP-Codierung, wobei ausführliche Beschreibungen für diese in diesem Dokument noch vorgesehen sind. Nach dem Lesen dieser Beschreibung könnte ein Fachmann auf dem bzw. den relevanten Gebiet(en) erkennen, dass jede beliebige Anzahl von Techniken zur Unterdrückung verwendet werden kann, ohne dass von dem Schutzumfang der vorliegenden Erfindung abgewichen wird.
  • 6B stellt dar, wie das Datenpaket 605 aussieht, nachdem es komprimiert worden ist, um ein komprimiertes Datenpaket 610 gemäß Ausführungsbeispielen der vorliegenden Erfindung zu erzeugen. Bei diesem beispielhaften Ausführungsbeispiel wurden der IP-Header 609, der UDP-Header 611 und der RTP-Header 613 eliminiert und durch einen aus einem einzelnen Byte bestehenden Index 617 ersetzt. Demgemäß umfasst das komprimierte Datenpaket 610 den Index 617, den MAC-Header 607 und die Nutzdaten 615. Der Index 617 umfasst ein Byte und wird verwendet, um anzugeben, dass das Datenpaket 610 komprimiert worden ist. Der Index 617 wird außerdem verwendet, um die bestimmte Technik zur Unterdrückung anzugeben, die zum Komprimieren des Datenpakets verwendet wurde. Weitere Einzelheiten zu dem Index 617 werden weiter unten unter Bezugnahme auf 7 beschrieben. Als Ergebnis des Eliminieren der oben angegebenen Header ist das komprimierte Datenpaket 610 um 40 Byte kleiner als das ursprüngliche Datenpaket 605.
  • 6C ist ein Beispiel für einen DOCSIS-Übertragungs-Burst (das heißt eine SID) mit gemischten Protokollen 606, der mehrere Pakete enthält, die gemäß Ausführungsbeispielen der vorliegenden Erfindung unterdrückt wurden. Die SID mit gemischten Protokollen 606 umfasst das komprimierte Datenpaket 610 und zusätzliche komprimierte Datenpakete 612 und 614. Bei einem Ausführungsbeispiel wird das komprimierte Datenpaket 610 unter Verwendung von DOCSIS PHS komprimiert, wie durch den Index 617 angegeben. Das komprimierte Datenpaket 612 wird unter Verwendung der dynamischen Delta-Codierung komprimiert, wie durch den Index 619 angegeben, und das komprimierte Datenpaket 614 wird unter Verwendung einer RTP-Codierung komprimiert, wie durch den Index 621 angegeben. Die Indizes 617, 619 und 621 trennen die Pakete innerhalb der SID mit gemischten Protokollen 606. Bei dieser Trennung handelt es sich in Wirklichkeit um ein Framing-Protokoll. Auf diese Weise ist die SID mit gemischten Protokollen 606 in der Lage, mehrere Pakete zu übertragen, die durch unterschiedliche Techniken zur Unterdrückung von Paket-Headern unterdrückt wurden.
  • 7 zeigt ein Ablaufdiagramm 700 eines Verfahrens zum Komprimieren von Paketen unter Verwendung unterschiedlicher Techniken zur Unterdrückung von Paket-Headern gemäß Ausführungsbeispielen der vorliegenden Erfindung. Die Erfindung ist jedoch nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 700 bereitgestellt wird. Das Ablaufdiagramm 700 wird unter weiterer Bezugnahme auf das beispielhafte Kabelmodemsystem 100 von 1 beschrieben.
  • In Schritt 702 wird das Kabelmodem 108 eingeschaltet, und es leitet eine Handshaking-Routine mit dem CMTS 104 über das HFC-Netzwerk 110 ein. Wäh rend dieses Initialisierungsprozesses bezeichnet das Kabelmodem 108 eine oder mehrere Indexnummern, um eine bestimmte Art von Technik zur Unterdrückung von Paket-Headern darzustellen. Zum Beispiel könnte mit dem Index 1 die DOCSIS-PHS-Unterdrückung bezeichnet werden, während die Indexnummern 2 bis 10 zur Verwendung mit einer dynamischen Delta-Codierung bezeichnet werden könnten. Noch ferner könnten die Indexnummern 11 bis 20 zur Verwendung mit einer RTP-Codierung bezeichnet werden. Sobald diese Bezeichnungen vorgenommen wurden, wird diese Information über das HFC-Netzwerk 110 an das CMTS 104 kommuniziert. Während des Initialisierungsprozesses werden außerdem die mit dem Unterdrücken und Dekomprimieren eines Pakets gemäß den verfügbaren Unterdrückungstechniken verbundenen Regeln ausgetauscht. Die Regeln werden dem CMTS 104 durch das Kabelmodem 108 bereitgestellt. Das CMTS 104 speichert die Indexnummern und die zugehörigen Regeln in einer Nachschlagetabelle zum nachfolgenden Abrufen während des Prozesses der Paketdekomprimierung.
  • Bei Ausführungsbeispielen ist der oben beschriebene Initialisierungsprozess Bestandteil von Standard-DOCSIS-Protokollen zur Registrierung von Kabelmodems. Bei alternativen Ausführungsbeispielen kann ein privater Kommunikationskanal, der zuvor unter Bezugnahme auf 4 weiter oben bereits beschrieben wurde, verwendet werden, um den Transfer von Indexnummern und Regeln zu erleichtern. Dies kann besonders bei Kabelmodemsystemen gemäß DOCSIS 1.0 vorteilhaft sein, bei denen das DOCSIS-Protokoll keinerlei Funktionalität zur Klassifizierung/Header-Unterdrückung definiert.
  • In Schritt 704 empfängt das Kabelmodem 108 ein Datenpaket von der Benutzervorrichtung 116. Bei dem Datenpaket kann es sich zum Beispiel um das Datenpaket 605 von 6A handeln.
  • In Schritt 706 bestimmt das Kabelmodem 108, ob das Datenpaket gemäß der vorliegenden Erfindung unterdrückt werden soll. Bei einem Ausführungsbeispiel unterdrückt das Kabelmodem 108 das Datenpaket nicht, wenn es sich dabei um ein nicht komprimierbares Paket handelt (das heißt wenn es kein IP-Paket ist). In diesem Fall würde das Kabelmodem 108 das Datenpaket mit seinem vollständigen Header übertragen.
  • In Schritt 708 wählt das Kabelmodem 108 eine geeignete Technik zur Unterdrückung von Paket-Headern für die in Schritt 706 identifizierten Datenpakete aus. Bei einem Ausführungsbeispiel, bei dem es sich bei den Datenpaketen um Pakete des unbekannten IP-Datagramm-Typs handelt, wird DOCSIS PHS ausgewählt. Bei IP/RTP-Datenpaketen (das heißt bei Sprachpaketen) wird die RTP-Unterdrückung ausgewählt. Bei IP/TCP-Datenpaketen mit variabler Länge wird die dynamische Delta-Unterdrückung ausgewählt.
  • In Schritt 710 hängt das Kabelmodem 108 ein Paket-Header-Element an das zu unterdrückende Datenpaket an. Das Paket-Header-Element enthält die in Schritt 702 bezeichnete Indexnummer für die bestimmte, in Schritt 708 ausgewählte Unterdrückungstechnik.
  • In Schritt 712 wird das Datenpaket gemäß den Regeln unterdrückt, die mit der in Schritt 708 ausgewählten Unterdrückungstechnik verbunden sind. Bei dem entstehenden komprimierten Datenpaket kann es sich zum Beispiel um das komprimierte Datenpaket 610 von 6B handeln. Gemäß der vorliegenden Erfindung ermöglichen die Schritte (704–712) das Unterdrücken von Datenpaketen gemäß jeder beliebigen gewünschten Technik zur Header-Unterdrückung. Die mit jedem Datenpaket verbundene Indexnummer identifiziert den Anfang des Datenpakets. Demgemäß ist die Indexnummer ein nützlicher Mechanismus, um ein Datenpaket von einem anderen zu trennen und um die bestimmte, zum Verarbeiten jedes Datenpakets verwendete Technik zur Header-Unterdrückung zu identifizieren.
  • Wie zuvor bereits erörtert, ermöglicht das DOCSIS-Protokoll die Verkettung von Datenpaketen, aber es erlaubt nicht das Mischen verschiedener Techniken zur Header-Unterdrückung innerhalb eines einzelnen DOCSIS-Übertragungs-Burst bzw. einer SID. Da jedoch die Indexnummer, die in dem in Schritt 710 angehängten Paket-Header-Element enthalten ist, ein Mittel zum Trennen der Pakete bereitstellt, ist das Mischen von unterschiedlichen Techniken zur Header-Unterdrückung innerhalb einer SID nun möglich. Demgemäß wird in einem alternativen Ausführungsbeispiel in Schritt 714 eine SID mit gemischten Protokollen erzeugt.
  • In Schritt 714 werden die Datenpakete miteinander verkettet. Als Ergebnis des Verkettens von Paketen, die mit unterschiedlichen Techniken zur Header-Unterdrückung unterdrückt wurden, kann die SID nun als SID mit gemischten Protokollen betrachtet werden. Tatsächlich dient der Index als Framing-Protokoll, das die Pakete innerhalb der SID mit gemischten Protokollen trennt und kommuniziert außerdem die Art der Header-Unterdrückung, die für jedes Paket innerhalb der SID mit gemischten Protokollen verwendet wurde. Bei einem Ausführungsbeispiel kann es sich bei der SID mit gemischten Protokollen zum Beispiel um die SID mit gemischten Protokollen 606 von 6C handeln. Schließlich wird in Schritt 716 die SID mit gemischten Protokollen an ein CMTS 104 übertragen.
  • 2. Dekomprimierung von Paket-Headern
  • 8 ist ein Ablaufdiagramm eines Verfahrens zum Dekomprimieren von Paketen, die unter Verwendung unterschiedlicher Techniken zur Unterdrückung von Paket-Headern gemäß Ausführungsbeispielen der vorliegenden Erfindung komprimiert wurden.
  • In Schritt 802 empfängt das CMTS 104 eine SID mit gemischten Protokollen, die ein oder mehrere Datenpakete umfasst.
  • In Schritt 805 untersucht das CMTS 104 jedes der Datenpakete, um zu bestimmen, ob es unterdrückt wurde. Wenn an ein Datenpaket ein Paket-Header-Element angehängt wurde, weiß das CMTS 104, dass das Datenpaket unterdrückt worden ist. Wenn kein Paket-Header-Element gefunden wird, wurde das Datenpaket nicht unterdrückt, und der Prozess wird sofort bei Schritt 820 fortgesetzt.
  • In Schritt 810 sucht das CMTS 104 in seiner Nachschlagetabelle nach der in dem Paket-Header-Element enthaltenen Indexnummer. Wenn die Indexnummer gefunden wird, wurden die mit der Unterdrückungstechnik verbundenen Dekomprimierungsregeln zuvor dem CMTS 104 bereitgestellt. Bei einem Ausführungsbeispiel wären die Dekomprimierungsregeln zuvor während des in Schritt 702 beschriebenen Initialisierungsprozesses bereitgestellt worden. Wenn die Indexnummer nicht gefunden wird, wird der Prozess bei Schritt 815 fortgesetzt.
  • In Schritt 815 tauschen das CMTS 104 und das Kabelmodem 108 Daten aus, welche die Regeln zum Dekomprimieren des Pakets in Echtzeit (das heißt, sobald das Datenpaket ankommt) beschreiben.
  • In Schritt 820 verarbeitet das CMTS 104 jedes der Datenpakete. In dem Fall, in dem das Datenpaket nicht unterdrückt ist (das heißt, es war kein Paket-Header-Element vorhanden), wird das Datenpaket gemäß den Standard-DOCSIS-Protokollen verarbeitet. In dem Fall, in dem das Datenpaket unterdrückt war (das heißt, es war ein Paket-Header-Element vorhanden), ruft das CMTS 104 die Regeln zum Dekomprimieren des Datenpakets auf der Grundlage der Unterdrückungstechnik ab, die durch die in dem Paket-Header-Element gefundene Indexnummer angegeben ist. Durch das Dekomprimieren des Datenpakets erzeugt das CMTS 104 ein unkomprimiertes Datenpaket. Bei einem Ausführungsbeispiel würde das CMTS 104 am Ende von Schritt 820 ein Datenpaket wie beispielsweise das unkomprimierte Datenpaket 605 in 6A erzeugen. Da die SID mit gemischten Protokollen ein oder mehrere Datenpakete enthält, werden die Schritte 805 bis 820 wiederholt, bis alle Datenpakete innerhalb der SID mit gemischten Protokollen verarbeitet worden sind. Die Verarbeitung endet bei Schritt 825.
  • 3. Unterdrückung von RTP-Headern
  • Wie zuvor bereits festgestellt, stellt die Erfindung eine Unterdrückung von RTP-Headern (Real-Time Transport Protocol) bereit. Die Technik zur RTP-Header-Unterdrückung gemäß der vorliegenden Erfindung liefert einen großen Effizienzgewinn in der Nutzung von Netzwerkbandbreite, indem die Übertragung von redundanten Mustern eliminiert wird und sich ändernde Felder in einem Datenstrom unterdrückt werden. Die Erfindung erreicht dies durch Erkennen von regelmäßigen Mustern in dem Netzwerk-Datenverkehr. Bei Ausführungsbeispielen können die regelmäßigen Muster eliminiert werden, indem sich ein Absender von Netzwerk-Datenverkehr, wie beispielsweise das Kabelmodem 108, und ein Empfänger von Netzwerk-Datenverkehr, wie beispielsweise das CMTS 104, auf die Regeln zur ordnungsgemäßen Rekonstruktion von Headern einigen, um den Header auf der Empfangsseite wiederherzustellen. Indem die Menge von Netzwerkbandbreite verringert wird, die zum Übertragen von RTP-Informationen über das Netzwerk benötigt wird, ermöglicht die vorliegende Erfindung eine erhöhte Leistung für dieselbe Anzahl von Benutzern in dem Netzwerk sowie die Möglichkeit, auf effiziente Weise mehr Benutzer zu dem Netzwerk hinzuzufügen.
  • Bevor die erfindungsgemäße Technik zur Unterdrückung von RTP-Headern beschrieben wird, wird ein in 9A gezeigter, herkömmlicher 802.3/IP/UDP/RTP- Protokoll-Header 900 für eine RTP-Übertragung beschrieben. Der beispielhafte Protokoll-Header 900 umfasst einen 14 Byte langen 802.3-Header 902, einen 20 Byte langen IP-Header (Internet Protocol) 904, einen 8 Byte langen UDP-Header (User Datagram Protocol) 906 und einen 12 Byte langen RTP-Header 908. In diesem Beispiel wird für den 802.3/IP/UDP/RTP-Header 900 ein 54 Byte langer Header erzeugt. Der Datenteil eines RTP-Pakets kann im Vergleich zu dem Systemaufwand, der zum Senden der Daten unter Verwendung des 802.3/IP/UDP/RTP-Headers 900 erforderlich ist, gering sein. Zum Beispiel kann der Datenteil eines RTP-Pakets so klein sein, dass er nur 20 Byte umfasst, was dazu führt, dass er weniger als halb so groß ist wie der Header 900. Auch ändern sich die meisten der Felder innerhalb des Protokoll-Headers 900 von Paket zu Paket nicht. Die Übertragung solcher redundanten Muster (sich von Paket zu Paket nicht ändernde Header-Informationen) kann eine große Menge von Netzwerkbandbreite verschwenden, insbesondere, wenn der Datenteil des RTP-Pakets kleiner ist als der Header 900. Es wäre daher sehr ineffizient, den Header 900 ohne Komprimierung zu übertragen.
  • DOCSIS 1.1 ermöglicht die Unterdrückung redundanter Informationen in Paketen mittels einer Funktion, die als PHS (Payload Header Suppression, Nutzdaten-Header-Unterdrückung) bezeichnet wird. PHS ermöglicht die Unterdrückung von sich nicht ändernden Bytes in einer einzelnen SID (das heißt einem Datenstrom). Wie zuvor bereits festgestellt, können mit PHS keine sich dynamisch ändernden Felder unterdrückt werden.
  • Die Technik zur Unterdrückung von RTP-Headern gemäß der vorliegenden Erfindung erhöht die Effizienz der Datenlieferung, indem Verhaltensmuster bei den sich ändernden Feldern des 802.3/IP/UDP/RTP-Headers 900 erkannt werden. 9B ist ein Diagramm eines RTP-Protokollpakets 910. Das RTP-Protokollpaket 910 umfasst unter anderem ein Ziel-MAC-Adressenfeld 912, ein Quell-MAC-Adressenfeld 914, ein Typ-/Längenfeld 916, ein Protokollversionsfeld 918, ein Header-Längenfeld 920, ein Dienstartfeld 922, ein Gesamtlängenfeld 924, Paket-ID-Feld 926, ein Fragment-Offset-Feld 928, eine Lebenszeitfeld 930, ein Protokollfeld 932, ein Header-Prüfsummenfeld 934, ein Quell-IP-Adressenfeld 936, ein Ziel-IP-Adressenfeld 938, ein Quell-Port-Feld 940, ein Ziel-Port-Feld 942, ein Längenfeld 944, ein Prüfsummenfeld 946, ein Flag-Feld 948, ein Folgenummernfeld 950, ein Zeitstempelfeld 952, ein Feld für die ID der Synchronisationsquelle 954, ein PDU-Feld 956 und ein CRC-32-Feld 958. RTP-Protokollpakete sind nach dem Stand der Technik allgemein bekannt, somit werden die einzelnen Felder nicht im Detail erörtert.
  • Der größte Teil des Headers 900 kann unterdrückt werden. Die Felder des Datenpakets 910, die sich von Paket zu Paket ändern können, umfassen das Paket-ID-Feld 926, das IP-Header-Prüfsummenfeld 934, das RTP-Folgenummernfeld 950 und das RTP-Zeitstempelfeld 952. Das UDP-Prüfsummenfeld 946 ist immer auf null gesetzt, weil es nicht verwendet wird. Die übrigen Felder bleiben während der Lebensdauer einer Sprachverbindung konstant.
  • Das RTP-Folgenummernfeld 950 beginnt mit einem willkürlichen Wert und wird für jedes nachfolgende Paket um einen Wert von eins inkrementiert. Das RTP-Zeitstempelfeld 952 wird um einen Wert inkrementiert, der auf dem Quantisierungsintervall des Codec basiert. Das Delta zweiter Ordnung dieser Zahl ist für jeden Codec bei einem bestimmten Quantisierungsintervall immer null.
  • Die Erfindung ermöglicht die Lieferung von Paketen in der richtigen Reihenfolge auf der Upstream-DOCSIS-Funkfrequenz-Verbindung. Die Erfindung unterdrückt den 802.3/IP/UDP/RTP-Header 900 auf dem Kabelmodem 108 und stellt sicher, dass der Header 900 durch das CMTS 104 wiederhergestellt wird. Bei der Rekonstruktion des Headers 900 muss es sich um eine exakte Rekonstruktion handeln. Dies wird erreicht, indem die Differenz zwischen einem RTP-Folgenummernfeld 950 eines RTP-Eingabepakets und dem RTP-Folgenummernfeld 950 des vorherigen RTP-Pakets berechnet wird. Wenn die Differenz zwischen den Feldern für die RTP-Folgenummer 950 von aufeinander folgenden RTP-Paketen 1 ist, dann handelt es sich bei der Differenz zwischen dem RTP-Zeitstempelfeld 952 eines neuen RTP-Pakets und dem RTP-Zeitstempelfeld 952 eines vorherigen RTP-Pakets um die Differenz erster Ordnung, die auf jedem nachfolgenden Paket erscheinen wird, während der Codec und das Quantisierungsintervall konstant bleiben.
  • Durch Beobachtung wurde bestimmt, dass die Differenz erster Ordnung beim Zeitstempelfeld 952 eines RTP-Pakets bei einer Quantisierung von 10 Millisekunden bei G711, G726, G738 und G729 80 dezimal beträgt. Bei einer Quantisierung von 5 Millisekunden beträgt die Differenz erster Ordnung in dem Zeitstempelfeld 952 des RTP-Pakets 40 dezimal.
  • Anfänglich sendet das Kabelmodem 108 einen oder mehrere nicht unterdrückte, vollständige Header mit einem Steuerbit, das angibt, dass das CMTS 104 den Header 900 erlernen soll. Sobald der Quantisierungswert bestimmt ist, wird der Quantisierungswert verwendet, um zu überprüfen, ob die Rekonstruktion des Headers 900 korrekt erfolgt. Zu diesem Zeitpunkt sendet das Kabelmodem 108 entweder ein Steuerbit "Header erlernen" mit einem vollständigen Header in dem Fall, in dem die Rekonstruktion des Headers 900 nicht korrekt erfolgt ist, oder anstelle des 54 Byte langen 802.3/IP/UDP/RTP-Headers 900 ein 5 Bit langes RTP-Sequenz-Delta, einen 8 Bit langen Quantisierungswert und ein optionales, 1 Byte langes IP-Paket-ID-Delta. Bei Ausführungsbeispielen kann während des Lernprozesses mehr als ein Folge-Header mit gesetztem Lernbit gesendet werden. Dadurch wird sichergestellt, dass in dem Fall, in dem ein Paket auf der Funkfrequenz-Verbindung gelöscht wird, das CMTS 104 am Ende über einen gültigen Schablonen-Header verfügt, von dem aus Pakete neu erstellt werden sollen, sobald das Lernbit nicht mehr gesetzt ist.
  • 10 ist ein Diagramm, das ein Steuerwert-Byte 1000 veranschaulicht, das während des Einsatzes einer Technik zur Unterdrückung von RTP-Headern verwendet wird. Das Steuerwert-Byte 1000 umfasst ein L-Bit 1002, ein I(1)-Bit 1004, ein I(0)-Bit 1006 und einen 5 Bit langen V-Wert 1008. Bei dem L-Bit 1002 handelt es sich um ein Lernbit. Das L-Bit 1002 ist gesetzt, wenn das CMTS 104 den Header 900 erlernen soll.
  • Moderne IP-Protokoll-Stacks inkrementieren das IP-Paket-ID-Feld 926 zwischen den einzelnen Datagrammen entweder um 0x0001 oder um 0x0100. Die vorliegende Erfindung verwendet einen zwei Bit langen Flag-Wert, I(1)-Bit 1004 und I(0)-Bit 1006, um zu bestimmen, ob das IP-Paket-ID-Feld 926 um 0x0001 oder um 0x0100 inkrementiert werden soll oder ob das IP-Paket-ID-Feld 926 durch ein 2 Byte langes Delta-Feld ersetzt werden soll, das in Upstream-Richtung von dem Kabelmodem 108 übertragen wird. Wenn sowohl I(1) als auch I(0) nicht gesetzt sind, wird das IP-Paket-ID-Feld 926 um 0x0001 inkrementiert. Wenn sowohl I(1) als auch I(0) gesetzt sind, wird das IP-Paket-ID-Feld 926 nicht inkrementiert. Wenn I(1) nicht gesetzt ist und I(0) gesetzt ist, wird das IP-Paket-ID-Feld 926 um 0x0100 inkrementiert. Wenn I(1) gesetzt ist und I(0) nicht gesetzt ist, wird die Änderung in dem IP-Paket-ID-Feld 926 in einem zwei Byte langen Delta-Feld in Upstream-Richtung übertragen. Tabelle 1 stellt die vier Möglichkeiten zum Bestimmen des Werts des IP-Paket-ID-Felds 926 dar. Tabelle 1
    I(1) I(0) IP-Paket-ID
    0 0 inkrementiert um 0x0001
    0 1 inkrementiert um 0x0100
    1 0 Änderung wird in einem zwei Byte langen Delta-Feld in Upstream-Richtung übertragen
    1 1 kein Inkrementwert
  • Bei dem Steuerwert (V) 1008 handelt es sich um einen fünf Bit langen Wert, der den Delta-Wert des Folgenummernfelds 950 darstellt.
  • 11 ist ein übergeordnetes Ablaufdiagramm 1100, das ein Verfahren zur Unterdrückung von RTP-Headern veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 1100 bereitgestellt wird. Vielmehr ist für Fachleute auf dem bzw. den relevanten Gebiet(en) nach dem Lesen der in diesem Dokument bereitgestellten Lehren offensichtlich, dass auch andere funktionelle Ablaufdiagramme in dem Schutzumfang der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 1102, wobei der Prozess sofort bei Schritt 1104 fortgesetzt wird.
  • In Schritt 1104 werden Informationen zur Unterdrückung von RTP-Headern von dem Kabelmodem 108 an das CMTS 104 kommuniziert, um eine Rekonstruktion von RTP-Paketen an dem CMTS 104 zu ermöglichen. Wie zuvor bereits erörtert, kann dies eine Indexnummer umfassen, welche die bestimmte Art von Technik zur Unterdrückung von Paket-Headern angibt, die Regeln, die mit dem Unterdrücken und Rekonstruieren eines Pakets gemäß der bestimmten Art von Technik zur Unterdrückung von Paket-Headern verbunden sind, usw. Der Prozess wird dann bei Schritt 1106 fortgesetzt.
  • In Schritt 1106 wird ein vollständiges RTP-Paket, wie beispielsweise das RTP-Paket 910, von dem Kabelmodem 108 an das CMTS 104 gesendet, um das Lernen durch das CMTS 104 zu ermöglichen. Das CMTS 104 speichert den vollständi gen Header des RTP-Pakets 910 zur zukünftigen Bezugnahme als Schablone. Der Prozess wird dann bei Entscheidungsschritt 1108 fortgesetzt.
  • In Entscheidungsschritt 1108 wird bestimmt, ob das CMTS 104 das RTP-Paket 910 erlernt hat. Wenn das CMTS 104 das RTP-Paket 910 nicht erlernt hat, kehrt der Prozess zu Schritt 1106 zurück, in dem ein vollständiges Paket zum fortgesetzten Erlernen von dem Kabelmodem 108 an das CMTS 104 gesendet wird.
  • Wenn unter nochmaliger Bezugnahme auf den Entscheidungsschritt 1108 bestimmt wird, dass das CMTS 104 das RTP-Paket 910 erlernt hat, wird der Prozess bei Schritt 1110 fortgesetzt. In Schritt 1110 werden nachfolgende Pakete in dem RTP-Datenstrom von dem Kabelmodem 108 an das CMTS 104 gesendet. Die nachfolgenden Pakete umfassen Delta-Werte, die Änderungen in dem RTP-Header 900 darstellen. Somit wird nicht mehr das gesamte RTP-Paket 910 gesendet. Stattdessen werden nur Delta-Werte gesendet, welche die Änderungen in dem RTP-Header 900 darstellen. Das PDU-Feld 956 wird ebenfalls gesendet. Wenn eine Fehlerbehebung gewünscht wird, umfassen die nachfolgenden Pakete auch ein zusätzliches Byte, welches das niedrigere Byte des RTP-Folgenummernfelds 950 angibt. Wenn das Paket aus irgend einem Grund gelöscht wird, kann das CMTS 104 auf effektive Weise den Algorithmus zur Header-Wiederherstellung neu synchronisieren, indem es die Änderungen an dem Folgenummernfeld 950 und an dem Zeitstempelfeld 952 des RTP-Headers 900 für alle fehlenden Pakete anwendet. Somit ermöglicht das Senden des Bytes niedrigerer Ordnung des Paketfolgenummernfelds 950 eine Rekonstruktion von gelöschten oder verloren gegangen Paketen. Der Prozess wird dann bei Entscheidungsschritt 1112 fortgesetzt.
  • In Entscheidungsschritt 1112 wird bestimmt, ob alle RTP-Pakete gesendet worden sind. Wenn nicht alle RTP-Pakete gesendet worden sind, kehrt der Prozess zu dem Entscheidungsschritt 1110 zurück, um zu ermöglichen, dass nachfolgende Pakete in dem RTP-Datenstrom an das CMTS 104 gesendet werden.
  • Wenn bei nochmaliger Bezugnahme auf den Entscheidungsschritt 1112 bestimmt wird, dass alle RTP-Pakete gesendet worden sind, wird der Prozess bei Schritt 1114 fortgesetzt, wo der Prozess endet.
  • 12A ist ein Ablaufdiagramm, das ein Verfahren zum Unterdrücken eines RTP-Headers unter Verwendung einer Technik zur Unterdrückung von RTP-Headern gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 1200 bereitgestellt wird. Vielmehr ist für Fachleute auf dem bzw. den relevanten Gebiet(en) nach dem Lesen der in diesem Dokument bereitgestellten Lehren offensichtlich, dass auch andere funktionelle Ablaufdiagramme in dem Schutzumfang der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 1202, wobei eine RTP-Unterdrückungsfunktion auf der Übertragungsseite (das heißt bei dem Kabelmodem 108) gestartet wird. Der Prozess wird sofort bei Schritt 1204 fortgesetzt.
  • In Schritt 1204 wird das Delta des RTP-Zeitstempelfelds 952 zwischen zwei aufeinander folgenden RTP-Paketen 910 bestimmt. Der resultierende Wert ist der Delta-Wert des Zeitstempels. Der resultierende Delta-Wert des Zeitstempels wird gleich temp(0) gesetzt. Es sei angemerkt, dass während der Initialisierung temp(0) auf null gesetzt wird. Der Prozess wird dann bei Schritt 1206 fortgesetzt.
  • In Schritt 1206 wird der Delta-Wert für das Folgenummernfeld 950 bestimmt. Der resultierende Delta-Wert wird gleich dem Steuerwert (V) gesetzt. Dies erfolgt durch Bestimmen des Bytes niedriger Ordnung eines neuen Folgenummernfelds 950, das durch eine AND-Operation mit dem Hexadezimalwert 7f verknüpft wurde, und durch Bestimmen des Bytes niedriger Ordnung des alten Folgenummernfelds 950, das durch eine AND-Operation mit dem Hexadezimalwert 7f verknüpft wurde. Der resultierende Wert des neuen Folgenummernfelds 950 wird dann von dem resultierenden alten Folgenummernfeld 950 subtrahiert, um den Delta-Wert bzw. Steuerwert (V) zu erhalten. Der Prozess wird dann bei Entscheidungsschritt 1208 fortgesetzt.
  • In Entscheidungsschritt 1208 wird bestimmt, ob eine ordnungsgemäße Rekonstruktion erfolgen wird. Dies erfolgt durch Multiplizieren des in Schritt 1206 berechneten Delta-Werts des Folgenummernfelds 950 mit dem konstanten Wert für den Codec und durch Addieren dieses Werts zu dem vorherigen Zeitstempelwert. Wenn dieser Wert nicht gleich dem neuen Zeitstempel ist, wird der Prozess bei Schritt 1210 fortgesetzt.
  • In Schritt 1210 wird das Lernbit 1002 des Steuerwerts 1000 gesetzt. Der Prozess wird dann bei Schritt 1212 fortgesetzt.
  • In Schritt 1212 wird temp(1) gleich dem Steuerwert 1000 gesetzt. Temp(1) enthält nun den Delta-Wert für das Folgenummernfeld 950. Der Prozess wird dann bei Schritt 1214 fortgesetzt.
  • In Schritt 1214 wird ein neuer Puffer zugeordnet, und die zwei Byte aus temp (der Delta-Wert für das Zeitstempelfeld 952 und der Steuerwert 1000, der den Delta-Wert für das Folgenummernfeld 950 umfasst) werden in dem neuen Puffer gespeichert. Der Prozess wird bei Schritt 1216 fortgesetzt.
  • In Schritt 1216 werden der neue Puffer und der ursprüngliche Puffer, der einen vollständigen RTP-Header 900 enthält, an das CMTS 104 übertragen. Somit wird der vollständige RTP-Header 900 zusammen mit dem Delta-Wert für das Zeitstempelfeld 952 und dem Steuerwert 1000 an das CMTS 104 gesendet. Der Prozess wird dann bei Schritt 1218 fortgesetzt, wo der Prozess endet.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 1208 bestimmt wird, dass der berechnete Wert gleich dem neuen Zeitstempelfeld 952 ist, dann hat das Kabelmodem 108 den Quantisierungswert bestimmt. Der Prozess wird bei Schritt 1220 fortgesetzt.
  • In Schritt 1220 wird der Inkrementwert zum Inkrementieren des IP-Paket-ID-Felds 1426 bestimmt. Die Bits I(1) 1004 und I(0) 1006 des Steuerwerts 1000 werden gemäß dem Inkrementwert für den verwendeten IP-Protokoll-Stack gesetzt. Der Steuerwert wird dann in temp(1) gespeichert. Der Prozess wird dann bei Schritt 1222 fortgesetzt.
  • In Schritt 1222 werden die zwei Byte aus temp in den ursprünglichen Puffer kopiert. Temp(0) ist der Delta-Wert für das Zeitstempelfeld 952 oder der Quantisierungswert. Temp(1) ist der Steuerwert 1000, der den Delta-Wert für das Folgenummernfeld 950 enthält. Der Prozess wird dann bei Schritt 1224 fortgesetzt.
  • In Schritt 1224 wird die ursprüngliche Länge minus 52 Byte ab dem Offset 52 übertragen. Somit werden der Quantisierungswert bzw. das Delta des Zeitstem pelfelds 952, der Steuerwert 1000 und das PDU-Feld 956 an das CMTS 104 übertragen. Der Prozess wird dann bei Schritt 1218 fortgesetzt, wo der Prozess endet.
  • Wie zuvor bereits festgestellt, inkrementieren moderne IP-Protokoll-Stacks das IP-Paket-ID-Feld 926 zwischen den einzelnen Datagrammen entweder um 0x0001 oder um 0x0100. Über eine spezielle Regel in der vorliegenden Erfindung wird das Setzen der Steuer-Bits 1004 und 1006 gehandhabt, um den Inkrementwert zu bestimmen. 12B ist ein Ablaufdiagramm, das ein Verfahren zum Setzen der Inkrement-Bits I(1) 1004 und I(0) 1006 des Steuerwerts 1000 zum Inkrementieren des IP-Paket-ID-Felds 926 in dem RTP-Paket 910 veranschaulicht. Der Prozess beginnt mit Schritt 1232, wobei der Prozess sofort bei Entscheidungsschritt 1234 fortgesetzt wird.
  • Die vorliegende Erfindung beinhaltet einen Testmodus, in dem das Testen verschiedener Aspekte des Systems erfolgen kann. Wenn bestimmte Tests durchgeführt werden, werden die Steuer-Bits I(1) 1004 und I(0) 1006 demgemäß gesetzt, um ein Inkrement von null bereitzustellen. In dem Entscheidungsschritt 1234 wird bestimmt, ob sich das System in einem Testmodus befindet. Wenn das System sich in einem Testmodus befindet, wird der Prozess bei Schritt 1236 fortgesetzt.
  • In Schritt 1236 wird das Steuerwert-Bit I(1) 1004 auf 1 gesetzt, und das Steuerwert-Bit I(0) 1006 wird auf 1 gesetzt. Der Prozess wird dann bei Schritt 1248 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf den Entscheidungsschritt 1234 bestimmt wird, dass das System sich nicht in einem Testmodus befindet, wird der Prozess bei Entscheidungsschritt 1238 fortgesetzt.
  • In Entscheidungsschritt 1238 wird bestimmt, ob der Wert für das IP-Paket-ID-Felds 926 in Upstream-Richtung gesendet werden soll. Wenn der Wert für das IP-Paket-ID-Feld 926 in Upstream-Richtung gesendet werden soll, wird der Prozess bei Schritt 1240 fortgesetzt.
  • In Schritt 1240 wird das Steuerwert-Bit I(1) 1004 auf 1 gesetzt, und das Steuerwert-Bit I(0) 1006 wird auf 0 gesetzt. Der Prozess wird dann bei Schritt 1248 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf den Entscheidungsschritt 1238 der Wert für das IP-Paket-ID-Feld 926 nicht in Upstream-Richtung gesendet werden soll, wird der Prozess bei Entscheidungsschritt 1242 fortgesetzt.
  • In Entscheidungsschritt 1242 wird bestimmt, ob der IP-Protokoll-Stack ein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 erfordert. Wenn der IP-Protokoll-Stack ein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 erfordert, wird der Prozess bei Schritt 1244 fortgesetzt.
  • In Schritt 1244 wird das Steuerwert-Bit I(1) 1004 auf 0 gesetzt, und das Steuerwert-Bit I(0) 1006 wird auf 0 gesetzt. Der Prozess wird dann bei Schritt 1248 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf den Entscheidungsschritt 1242 der IP-Protokoll-Stack kein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 erfordert, wird der Prozess bei Schritt 1246 fortgesetzt.
  • In Schritt 1246 wird das Inkrement 0x0100 für das IP-Paket-ID-Feld 926 benötigt. Das Steuerwert-Bit I(1) 1004 wird auf 0 gesetzt, und das Steuerwert-Bit I(0) 1006 wird auf 1 gesetzt. Der Prozess wird dann bei Schritt 1248 fortgesetzt.
  • In Schritt 1248 endet der Prozess.
  • 13 ein Ablaufdiagramm 1300, das ein Verfahren zur Rekonstruktion eines unterdrückten RTP-Pakets gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 1300 bereitgestellt wird. Vielmehr ist für Fachleute auf dem bzw. den relevanten Gebiet(en) nach dem Lesen der in diesem Dokument bereitgestellten Lehren offensichtlich, dass auch andere funktionelle Ablaufdiagramme in dem Schutzumfang der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 1302, wobei die Rekonstruktionsfunktion gestartet wird. Der Prozess wird dann bei Schritt 1304 fortgesetzt.
  • In Schritt 1304 wird ein 54 Byte langer Header gelesen. Der Prozess wird dann bei Schritt 1306 fortgesetzt.
  • In Schritt 1306 wird der 1 Byte lange Steuerwert 1000 aus dem Eingabedatenstrom gelesen. Der Prozess wird dann bei Entscheidungsschritt 1308 fortgesetzt.
  • In Entscheidungsschritt 1308 wird bestimmt, ob das Lernbit 1002 des Steuerwerts 1000 gesetzt ist. Wenn bestimmt wird, dass das Lernbit 1002 gesetzt ist, muss der Header 900 von dem CMTS 104 erlernt werden. Der Prozess wird dann bei Schritt 1310 fortgesetzt.
  • In Schritt 1310 wird ein zweiter 1 Byte langer Wert aus dem Eingabedatenstrom gelesen. Dieser zweite 1 Byte lange Wert wird verworfen. Der Prozess wird dann bei Schritt 1312 fortgesetzt.
  • In Schritt 1312 wird der aktuelle 54 Byte lange Header, der in Schritt 1304 gelesen wurde, verworfen. Das CMTS 104 verwirft diese Daten, weil dieser 54 Byte lange Header durch den Mechanismus der Hardware zur Unterdrückung von Nutzdaten-Headern am Ende der Rekonstruktionsfunktion generiert wurde, was weiter unten noch unter Bezugnahme auf Schritt 1318 erörtert wird. Wenn der Mechanismus der Hardware zur Unterdrückung von Nutzdaten-Headern diesen 54 Byte langen Header einbringt, wird der 54 Byte lange Header vor dem Steuerwert 1000 platziert. Wenn das Lernbit 1002 gesetzt ist, wird somit dieser 54 Byte lange Header als Abfall betrachtet und muss verworfen werden. Aus Sicht des Kabelmodems 108 handelte es sich bei den gesendeten Daten um einen Unterdrückungsindex. Der Empfang des Unterdrückungsindex durch das CMTS 104 bewirkte, dass das CMTS 104 54 Byte nicht korrekte Daten in den Datenstrom eingebracht hat. Der Prozess wird dann bei Schritt 1314 fortgesetzt.
  • In Schritt 1314 wird der korrekte 54 Byte lange Header, der von dem Kabelmodem 108 übertragen wurde, aus dem Eingabedatenstrom gelesen. Der Prozess wird dann bei Schritt 1316 fortgesetzt.
  • In Schritt 1316 wird der 54 Byte lange Header in einen Schablonen-Header kopiert, und der 54 Byte lange Header, der von den Daten von dem PDU-Feld 956 gefolgt wird, wird abgeschickt. Der Prozess wird dann bei Schritt 1318 fortgesetzt, wo der Prozess endet.
  • Wenn unter nochmaliger Bezugnahme auf den Entscheidungsschritt 1308 bestimmt wird, dass das Lernbit 1002 des Steuerwerts 1000 nicht gesetzt ist, wird der Prozess bei Schritt 1320 fortgesetzt.
  • In Schritt 1320 wird der zweite 1 Byte lange Wert aus dem Eingabedatenstrom gelesen und in einem Byte niedriger Ordnung einer lokalen Variable mit dem Namen DELTA platziert. Bei DELTA handelt es sich um ein 32 Bit langes Datenwort. DELTA wird beim Start der RTP-Delta-Rekonstruktionsfunktion 1300 auf den Wert null vorinitialisiert. Der Prozess wird dann bei Schritt 1322 fortgesetzt.
  • Bei Schritt 1322 beginnt der Prozess des Bestimmens, ob das IP-Paket-ID-Feld 926 wie in Tabelle 1 dargelegt inkrementiert werden soll. In Schritt 1322 wird bestimmt, ob das I(1)-Bit 1004 des Steuerwerts 1000 gesetzt ist. Wenn das I(1)-Bit 1004 des Steuerwerts 1000 nicht gesetzt ist, wird der Prozess bei Schritt 1324 fortgesetzt.
  • In Schritt 1324 wird bestimmt, ob das I(0)-Bit 1006 des Steuerwerts 1000 gesetzt ist. Wenn das I(0)-Bit nicht gesetzt ist, wird der Prozess bei Schritt 1326 fortgesetzt.
  • In Schritt 1326 wird eine lokale Variable mit dem Namen INCR auf 0x0001 gesetzt, um das IP-Paket-ID-Feld 926 zu inkrementieren. Es sei angemerkt, dass es sich bei der lokalen Variablen INCR um einen 16 Bit langen Wert ohne Vorzeichen handelt. INCR wird in Schritt 1302 auf null vorinitialisiert. Der Prozess wird dann bei Schritt 1334 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Schritt 1324 das I(0)-Bit gesetzt ist, wird der Prozess bei Schritt 1328 fortgesetzt. In Schritt 1328 wird eine lokale Variable mit dem Namen INCR auf 0x0100 gesetzt, um das IP-Paket-ID-Feld 926 zu inkrementieren. Der Prozess wird dann bei Schritt 1334 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Schritt 1322 das I(1)-Bit gesetzt ist, wird der Prozess bei Schritt 1330 fortgesetzt. In Schritt 1330 wird bestimmt, ob das I(0)-Bit 1006 des Steuerwerts 1000 gesetzt ist. Wenn das I(0)-Bit gesetzt ist, wird der Prozess bei Schritt 1334 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Schritt 1330 das I(0)-Bit nicht gesetzt ist, wird der Prozess bei Schritt 1332 fortgesetzt. In Schritt 1332 wird die Änderung in dem IP-Paket-ID-Feld 926 von dem Kabelmodem 108 in Upstream-Richtung übertragen. Ein zwei Byte langer Wert ohne Vorzeichen wird aus dem Eingabedatenstrom eingelesen und bei Offset 18 des rekonstruierten Datenpakets platziert. Bei dem Offset 18 des rekonstruierten Datenpakets handelt es sich um das IP-Paket-ID-Feld 926. Der Prozess wird dann bei Schritt 1334 fortgesetzt.
  • Die Schritte 1334 bis 1340 sehen alle Aktualisierungen des IP-Paket-ID-Felds 926, des RTP-Folgenummernfelds 950 und des RTP-Zeitstempelfelds 952 für die Rekonstruktion des RTP-Pakets 910 vor. In Schritt 1334 wird bestimmt, ob die Bits 4-0 des Bytes bei Offset 45 (Bits niedriger Ordnung des Folgenummernfelds 950) des RTP-Pakets 910 gleich V 1008 in dem Steuerwert 1000 sind. Wenn bestimmt wird, dass die Bits 4-0 des Bytes bei Offset 45 (Bits niedriger Ordnung des Folgenummernfelds 950) des RTP-Pakets 910 gleich V 1008 in dem Steuerwert 1000 sind, wird der Prozess bei Schritt 1342 fortgesetzt.
  • In Schritt 1342 wird eine neue IP-Header-Prüfsumme bestimmt und bei Offset 24 (IP-Header-Prüfsummenfeld 934) platziert. Bei dem IP-Header-Prüfsummenfeld 934 handelt es sich um das 16 Bit lange Einerkomplement der Summe der Einerkomplemente aller 16 Bit langen Datenwörter in dem Header 900. Zum Zweck der Berechnung der Prüfsumme ist der Wert des Prüfsummenfelds null.
  • Wenn unter nochmaliger Bezugnahme auf Schritt 1334 bestimmt wird, dass die Bits 4-0 des Bytes bei Offset 45 (Bits niedriger Ordnung des Folgenummernfelds 950) des RTP-Pakets 910 nicht gleich V 1008 in dem Steuerwert 1000 sind, wird der Prozess bei Schritt 1336 fortgesetzt.
  • In Schritt 1336 wird der Wert eins zu dem Datenwort bei Offset 44 des RTP-Pakets 910 addiert, wobei es sich um das RTP-Folgenummernfeld 950 handelt. Der Prozess wird dann bei Schritt 1338 fortgesetzt.
  • In Schritt 1338 wird das Datenwort bei Offset 18 des RTP-Pakets 910, wobei es sich um das IP-Paket-ID-Feld 926 handelt, um die lokale Variable INCR inkrementiert. Der Prozess wird dann bei Schritt 1340 fortgesetzt.
  • In Schritt 1340 wird das Datenwort bei Offset 46 des RTP-Pakets 910, wobei es sich um das RTP-Zeitstempelfeld 952 handelt, um die lokale Variable DELTA inkrementiert. Der Prozess kehrt dann zu Schritt 1334 zurück, um zu bestimmen, ob der Steuerwert (V) 1008 mit den fünf Bits niedriger Ordnung in dem Folgenummernfeld 950 des RTP-Pakets 910 übereinstimmt. Die Schritte 1334 bis 1340 werden wiederholt, bis diese Zahlen gleich sind. Wenn diese Zahlen gleich sind, wird der Prozess, wie oben beschrieben, bei Schritt 1342 fortgesetzt.
  • 4. Schema zur dynamischen Delta-Codierung
  • Wie zuvor bereits festgestellt, stellt die Erfindung eine Optimierung der Übertragung von TCP/IP-Datenverkehr (Internet Protocol) über ein DOCSIS-Netzwerk bereit. Die Unterdrückungstechnik der vorliegenden Erfindung ist eher feldorientiert als Byte-orientiert. Viele Felder in einem TCP-Protokoll-Header ändern sich zwischen den einzelnen Paketen in demselben TCP-Verbindungsdatenstrom nicht. Diese redundanten Informationen werden einmal übertragen und in den nachfolgenden Paketen unterdrückt. Andere Felder in dem TCP-Protokoll-Header ändern sich auf eine vorhersehbare Weise. Diese Felder werden nicht in ihrer Gesamtheit übertragen. Stattdessen wird ein kleinerer, Delta-codierter Wert übertragen, der die Wertänderung jedes Felds von einem Paket zum nächsten darstellt. Die Delta-codierten Werte für 32-Bit-Felder werden immer als 16-Bit-Zahl dargestellt. Diese Technik verringert die zum Senden der sich ändernden Felder erforderliche Bandbreite um etwa 50% und stellt somit einen hohen Effizienzgewinn bei der Übertragung von TCP-Bestätigungen (ACK) bereit.
  • DOCSIS-Kabelmodems können die Lieferung von Paketen in der richtigen Reihenfolge in jedem IP-Datenstrom sicherstellen. Diese garantierte Lieferreihenfolge ermöglicht die Verwendung von Delta-codierten Feldern zum Aktualisieren jeglicher sich ändernden Felder in einem 802.3/IP/TCP-Protokoll-Header.
  • Bevor das Schema zur dynamischen Delta-Codierung für die Unterdrückung von TCP-Headern beschrieben wird, wird ein in 14A gezeigter, herkömmlicher 802.3/IP/TCP-Protokoll-Header 1400 für die TCP/IP-Übertragung beschrieben. Der Protokoll-Header 1400 umfasst einen 14 Byte langen 802.3-Header 1402, einen 20 Byte langen IP-Header 1404 und einen 20 Byte langen TCP-Header 1406. In diesem Beispiel wird aus dem 802.3/IP/TCP-Header 1400 ein 54 Byte langer Header für die TCP/IP-Übertragung erzeugt.
  • 14B ist ein Diagramm eines TCP-Protokollpakets 1410. Das TCP-Protokollpaket 1410 umfasst unter anderem ein Ziel-MAC-Adressenfeld 1412, ein Quell-MAC-Adressenfeld 1414, ein Typ-/Längenfeld 1416, ein Protokollversionsfeld 1418, ein Header-Längenfeld 1420, ein Dienstartfeld 1422, ein Gesamtlängenfeld 1424, ein Paket-ID-Feld 1426, ein Fragment-Offset-Feld 1428, eine Lebenszeitfeld 1430, ein Protokollfeld 1432, ein Header-Prüfsummenfeld 1434, ein Quell-IP-Adressenfeld 1436, ein Ziel-IP-Adressenfeld 1438, ein Quell-Port-Feld 1440, ein Ziel-Port-Feld 1442, ein Folgenummernfeld 1446, ein Bestätigungsnummemfeld 1448, ein Daten-Offset-Feld 1450, ein Flag-Feld 1452, ein Fensterfeld 1454, ein Prüfsummenfeld 1456, ein Feld für den Zeiger 'Dringend' (Urgent Pointer) 1458, ein PDU-Feld 1460 und ein CRC-32-Feld 1462. TCP-Protokollpakete sind nach dem Stand der Technik allgemein bekannt, somit werden die einzelnen Felder nicht im Detail erörtert.
  • Die meisten Felder in einem TCP-Protokollpaket 1410 ändern sich zwischen den einzelnen Paketen in demselben TCP-Verbindungsdatenstrom nicht. In dem TCP-Protokollpaket 1410 können alle Felder des Headers 1402 und die meisten Felder des Headers 1404 unterdrückt werden, sobald der Empfänger die redundanten bzw. sich nicht ändernden Felder erlernt hat. Viele der Felder in dem TCP-Header 1406 ändern sich zwischen den einzelnen Paketen in demselben TCP-Verbindungsdatenstrom. Mit der vorliegenden Erfindung werden diese Felder nicht in ihrer Gesamtheit übertragen. Stattdessen wird ein kleinerer Delta-codierter Wert übertragen. Der Delta-codierte Wert stellt die Wertänderung jedes Felds von einem Paket zum nächsten dar.
  • 15 ist ein Diagramm, das die Felder veranschaulicht, die sich in dem TCP-Protokollpaket 1410 von Paket zu Paket ändern. Die sich von Paket zu Paket ändernden Felder sind hervorgehoben. Die sich ändernden Felder umfassen das Paket-ID-Feld 1426 aus dem IP-Header 1404 sowie das Folgenummernfeld 1446, das Bestätigungsnummernfeld 1448, das Daten-Offset-Feld 1450, das Fensterfeld 1454, das Prüfsummenfeld 1456 und das Feld für den Zeiger 'Dringend' 1458 aus dem TCP-Header 1406.
  • Die Erfindung ermöglicht die Lieferung von Paketen in der richtigen Reihenfolge auf der Upstream-DOCSIS-Funkfrequenz-Verbindung. Die Erfindung unterdrückt den 802.3/IP/TCP-Header 1400 auf dem Kabelmodem 108 und stellt sicher, dass der Header 1400 durch das CMTS 104 in sein ursprüngliches Format wiederhergestellt wird. 16A und 16B stellen eine übergeordnete Beschreibung des Prozesses zur Delta-codierten Unterdrückung bzw. Rekonstruktion für die vorliegende Erfindung bereit.
  • 16A ist ein übergeordnetes Ablaufdiagramm 1600, das ein Verfahren für eine Delta-codierte Unterdrückungstechnik veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 1600 bereitgestellt wird. Vielmehr ist für Fachleute auf dem bzw. den relevanten Gebiet(en) nach dem Lesen der in diesem Dokument bereitgestellten Lehren offensichtlich, dass auch andere funktionelle Ablaufdiagramme in dem Schutzumfang der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 1601 und wird sofort bei Schritt 1602 fortgesetzt wird.
  • In Schritt 1602 werden Informationen zur Delta-codierten Unterdrückung von TCP-Headern von dem Kabelmodem 108 an das CMTS 104 kommuniziert, um eine Rekonstruktion von TCP-Paketen an dem CMTS 104 zu ermöglichen. Wie zuvor bereits erörtert, kann dies eine Indexnummer umfassen, welche die bestimmte Art von Technik zur Unterdrückung von Paket-Headern angibt, die Regeln, die mit dem Unterdrücken und Rekonstruieren eines Pakets gemäß der bestimmten Art von Technik zur Unterdrückung von Paket-Headern verbunden sind, usw. Das Kabelmodem 108 wählt den Unterdrückungsindex und damit die Technik zur Unterdrückung aus. Dies verhindert die Notwendigkeit einer Zweiwege-Befehlstransaktion während schneller Datentransfers. Der Prozess wird dann bei Schritt 1603 fortgesetzt.
  • In Schritt 1603 wird ein einzelner TCP-Verbindungsdatenstrom identifiziert. Ein Framing-Protokoll wird verwendet, um jeden TCP-Verbindungsdatenstrom in einer einzelnen DOCSIS-SID zu trennen und zu identifizieren. Nach dem Identifizieren des TCP-Verbindungsdatenstroms wird der Prozess bei Schritt 1604 fortgesetzt.
  • In Schritt 1604 wird ein erstes TCP-Protokollpaket 1410 in einem TCP-Verbindungsdatenstrom in seiner Gesamtheit an einen Empfänger übertragen. Das erste TCP-Protokollpaket 1410 umfasst einen Lernindikator. Der Indikator weist den Empfänger an, den vollständigen Header zu erlernen. Der vollständige Protokoll-Header 1400 kann erlernt werden, ohne dass hierzu eine Bestätigung von einem Empfänger, wie beispielsweise dem CMTS 104, erforderlich ist. Dies erlaubt es, den Header in Echtzeit zu erlernen. Sobald der Header erlernt worden ist, können nachfolgende Pakete in einem komprimierten Format gesendet werden. Es wird eine maximale Effizienz erreicht, indem erlaubt wird, dass einem nicht unterdrückten (erlernten) Header unmittelbar ein unterdrückter Header folgt. Dies eliminiert die Verzögerung, die in dem DOCSIS-Ansatz eingebracht wurde, der das Warten auf eine Lernbestätigung von dem Empfänger erfordert. Der Prozess wird dann bei Schritt 1606 fortgesetzt.
  • In Schritt 1606 wird das nächste Paket in dem TCP-Verbindungsdatenstrom abgerufen. Der Prozess wird dann bei Schritt 1608 fortgesetzt.
  • In Schritt 1608 werden die Felder, die sich gegenüber dem vorherigen übertragenen Paket geändert haben, identifiziert, und es wird ein Delta-codierter Wert bestimmt, der diese Änderung darstellt. Der Prozess wird dann bei Schritt 1610 fortgesetzt.
  • In Schritt 1610 wird ein Bitmuster-Flag generiert. Das Bitmuster-Flag gibt an, welche der möglichen Delta-codierten IP/TCP-Feldwerte zwischen einem Änderungs-Byte und dem Datenbereich des komprimierten TCP-Protokollpakets vorhanden sind. Bei dem Änderungs-Byte handelt es sich um ein ein Byte langes Bitmuster-Flag-Feld zum Angeben, welche Felder innerhalb des Protokoll-Headers 1400 sich geändert haben. Das Änderungs-Byte wird weiter unten unter Bezugnahme auf 17 noch ausführlicher erörtert. Der Prozess wird dann bei Schritt 1612 fortgesetzt.
  • In Schritt 1612 wird das komprimierte TCP-Protokollpaket generiert, und das Bitmuster-Flag wird vorn an das komprimierte TCP-Paket angehängt. Der Prozess wird dann bei Schritt 1614 fortgesetzt.
  • In Schritt 1614 wird das komprimierte TCP-Protokollpaket an den Empfänger übertragen. Der Prozess wird dann bei Entscheidungsschritt 1616 fortgesetzt.
  • In Entscheidungsschritt 1616 wird bestimmt, ob es weitere TCP-Protokollpakete 1410 in dem TCP-Verbindungsdatenstrom gibt, die übertragen werden sollen.
  • Wenn weitere Pakete übertragen werden sollen, kehrt der Prozess zu Schritt 1606 zurück, um das nächste Paket abzurufen.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 1616 keine weiteren Pakete in dem TCP-Verbindungsdatenstrom übertragen werden sollen, kehrt der Prozess zu Schritt 1603 zurück, in dem ein weiterer TCP-Verbindungsdatenstrom identifiziert wird.
  • 16B ist ein übergeordnetes Ablaufdiagramm 1620, das ein Verfahren für eine Delta-codierte Technik zur Rekonstruktion von Headern veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 1620 bereitgestellt wird. Vielmehr ist für Fachleute auf dem bzw. den relevanten Gebiet(en) nach dem Lesen der in diesem Dokument bereitgestellten Lehren offensichtlich, dass auch andere funktionelle Ablaufdiagramme in dem Schutzumfang der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 1622, wobei der Prozess sofort bei Schritt 1624 fortgesetzt wird.
  • In Schritt 1624 wird ein TCP-Protokollpaket 1410 von einem TCP-Verbindungsdatenstrom abgerufen. Der Prozess wird dann bei Entscheidungsschritt 1626 fortgesetzt.
  • In Entscheidungsschritt 1626 wird bestimmt, ob das abgerufene TCP-Protokollpaket 1410 erlernt werden soll. Dies erfolgt durch Bestimmen, ob das Indikator-Lernbit gesetzt ist. Wenn das Indikator-Lernbit gesetzt ist, wird der Prozess bei Schritt 1628 fortgesetzt.
  • In Schritt 1628 erlernt der Empfänger den aktuellen TCP-Protokoll-Header des Pakets 1410 und speichert das Paket 1410 zur zukünftigen Bezugnahme als Header-Schablone. Der Prozess kehrt dann zu Schritt 1624 zurück, um ein weiteres Paket abzurufen.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 1626 das Indikator-Lernbit nicht gesetzt ist, wird der Prozess bei Schritt 1630 fortgesetzt.
  • In Schritt 1630 wird das Änderungs-Byte gelesen, und die entsprechenden Delta-codierten Werte werden gelesen. Der Prozess wird dann bei Schritt 1632 fortgesetzt.
  • In Schritt 1632 wird der Header rekonstruiert. Die TCP/IP-Header-Flags werden aktualisiert, und die Delta-codierten Werte werden verwendet, um die geänderten Felder in einer gespeicherten Header-Schablone zu aktualisieren. Der Prozess wird dann bei Schritt 1634 fortgesetzt.
  • In Schritt 1634 wird der vollständig wiederhergestellte Header vor jeglichen empfangenen Daten aus dem TCP-Protokollpaket platziert, das in Schritt 1624 empfangen wurde. Zu diesem Zeitpunkt ist das Paket vollständig in seinem ursprünglichen Format wiederhergestellt und kann über ein IP-Netzwerk übertragen werden. Der Prozess kehrt dann zu Schritt 1624 zurück, wo ein weiteres TCP-Protokollpaket abgerufen wird.
  • 17 ist ein Diagramm, welches das Änderungs-Byte 1700 veranschaulicht, das beim Ausführen der Delta-codierten Technik zur Header-Unterdrückung verwendet wird. Bei dem Änderungs-Byte 1700 handelt es sich um ein ein Byte langes Bitmuster-Flag-Feld zum Angeben, welche Felder des Protokoll-Headers 1400 sich geändert haben. Das Änderungs-Byte 1700 gibt außerdem an, ob der Header 1400 auf der Empfangsseite erlernt werden soll oder nicht. Das Änderungs-Byte 1700 gibt ferner an, ob die IP-Paket-ID 1426 inkrementiert werden soll und um welchen Betrag die IP-Paket-ID 1426 inkrementiert werden soll. Das Änderungs-Byte 1700 umfasst ein L-Bit 1702, ein I(1)-Bit 1704, ein I(0)-Bit 1706, ein S-Bit 1708, ein A-Bit 1710, ein P-Bit 1712, ein W-Bit 1714 und ein U-Bit 1716.
  • Wenn es gesetzt ist, gibt das L-Bit 1702 an, dass der Rest des Änderungs-Bytes ignoriert werden kann und dass ein vollständiger 54 Byte langer 802.3/IP/TCP-Header 1400 in dem Burst-Signal enthalten ist und verwendet werden soll, um den aktuellen Schablonen-Header zu ersetzen.
  • Das I(1)-Bit 1704 und das I(0)-Bit 1706 werden verwendet, um die Änderung des IP-Paket-ID-Felds 926 auf ähnliche Weise zu bestimmen, wie oben in Tabelle 1 angegeben. Wenn es gesetzt ist, gibt das I(1)-Bit 1704 an, dass es sich bei dem nächsten Wert in dem Datenstrom um einen 2 Byte langen Wert handelt, der in das IP-Paket-ID-Feld 1426 des Schablonen-Headers kopiert werden soll. Das Ergebnis soll in den Schablonen-Header zurückgeschrieben und abgeschickt werden. Wenn das I(1)-Bit 1704 nicht gesetzt ist, muss das I(0)-Bit 1706 geprüft werden, um festzustellen, wie die IP-Paket-ID 1426 inkrementiert werden soll. Wenn das I(0)-Bit 1706 gesetzt ist, gibt es an, dass 0x0100 zu dem IP-Paket-D-Feld 1426 des Schablonen-Headers addiert werden soll, dieses dann in den Schablonen-Header zurückgeschrieben und abgeschickt werden soll. Wenn das I(0)-Bit 1706 nicht gesetzt ist, gibt es an, dass das IP-Paket-ID-Feld 1426 des Schablonen-Headers um 0x0001 inkrementiert werden soll, dieses dann in den Schablonen-Header zurückgeschrieben und abgeschickt werden soll. Das I(1)-Bit 1704 und das I(0)-Bit 1706 werden auf der Grundlage der Funktionsweise von modernen IP-Protokoll-Stacks und auf Grundlage der Art und Weise bestimmt, in der sie, wie oben beschrieben, inkrementiert werden.
  • Wenn das S-Bit 1708 gesetzt ist, gibt es an, dass es sich bei dem nächsten Wert in dem Datenstrom um einen 2 Byte langen Wert handelt, der zu dem 4 Byte langen TCP-Folgenummernfeld 1446 des Schablonen-Headers addiert werden soll. Das Ergebnis soll in den Schablonen-Header zurückgeschrieben und abgeschickt werden. Wenn das S-Bit 1708 nicht gesetzt ist, soll das TCP-Folgenummernfeld 1446 des Schablonen-Headers unverändert verwendet werden.
  • Wenn das A-Bit 1710 gesetzt ist, handelt es sich bei dem nächsten Wert in dem Datenstrom um einen 2 Byte langen Wert, der zu dem 4 Byte langen TCP-Bestätigungsnummernfeld 1448 des Schablonen-Headers addiert werden soll. Das Ergebnis soll in den Schablonen-Header zurückgeschrieben und abgeschickt werden. Wenn das A-Bit 1710 nicht gesetzt ist, soll das TCP-Bestätigungsnummernfeld 1448 des Schablonen-Headers unverändert verwendet werden.
  • Wenn das P-Bit 1712 gesetzt ist, gibt es an, dass das PUSH-Bit (nicht gezeigt) eines Nibble des TCP-Felds für Flags 1452 gesetzt und abgeschickt werden soll. Wenn das P-Bit 1712 nicht gesetzt ist, soll das Setzen des PUSH-Bits eines Nibble des TCP-Felds für Flags 1452 rückgängig gemacht und dieses abgeschickt werden.
  • Wenn das W-Bit 1714 gesetzt ist, handelt es sich bei dem nächsten Wert in dem Datenstrom um einen 2 Byte langen Wert, der in das TCP-Fensterfeld 1454 des Schablonen-Headers kopiert werden soll. Das Ergebnis soll in den Schablonen-Hea der zurückgeschrieben und abgeschickt werden. Wenn das W-Bit 1714 nicht gesetzt ist, soll das TCP-Fensterfeld 1454 des Schablonen-Headers unverändert verwendet werden.
  • Wenn das U-Bit 1716 gesetzt ist, handelt es sich bei dem nächsten Wert in dem Datenstrom um einen 2 Byte langen Wert, der in das TCP-Feld für den Zeiger 'Dringend' 1458 des Schablonen-Headers kopiert werden soll. Das Ergebnis soll in den Schablonen-Header zurückgeschrieben und abgeschickt werden. Wenn das U-Bit 1716 nicht gesetzt ist, soll das TCP-Feld für den Zeiger 'Dringend' 1458 des Schablonen-Headers unverändert verwendet werden.
  • Auf der Grundlage der Felder, die sich tatsächlich gegenüber den zuvor übertragenen Werten ändern, erfolgt eine von zwei Maßnahmen. Das TCP-Protokollpaket 1410 kann ohne jegliche Unterdrückung geändert werden, oder das TCP-Protokollpaket 1410 kann an das Änderungs-Byte 1700 angehängt werden und kann entweder ein vollständiges TCP-Protokollpaket 1410 oder zwei oder mehr Felder anstelle des 54 Byte langen 802.3/IP/TCP-Headers 1400 umfassen. Die zwei oder mehr Felder, die den 802.3/IP/TCP-Header 1400 ersetzen, umfassen Folgendes: (1) einen tatsächlichen Wert der IP-Paket-ID 1426 (der nur gesendet wird, wenn die IP-Paket-ID nicht um 0x0001 oder 0x0100 inkrementiert wurde); (2) einen Delta-codierten Wert für die TCP-Folgenummer 1446 (der nur gesendet wird, wenn die Delta-codierte TCP-Folgenummer ≠ 0); (3) einen Delta-codierten Wert für das TCP-Bestätigungsnummernfeld 1448 (der nur gesendet wird, wenn die Delta-codierte TCP-Bestätigungsnummer ≠ 0); (4) ein Daten-Byte für das TCP-Daten-Offset-Feld 1450; (5) einen tatsächlichen Wert für das TCP-Fensterfeld 1454 (der nur gesendet wird, wenn ein Delta-Wert für das TCP-Fensterfeld 1454 ≠ 0); (6) einen tatsächlichen Wert für das TCP-Header-Prüfsummenfeld 1456; und (7) einen tatsächlichen Wert für das TCP-Feld für den Zeiger 'Dringend' 1458 (der nur gesendet wird, wenn das IP-Dringlichkeits-Flag ('Urgent') gesetzt ist). Die Erfindung verwendet daher einen Framing-Machanismus, der komprimierten, unkomprimierten und nicht in dem IP-Format vorliegenden Datenverkehr in einer einzelnen DOCSIS-SID kombiniert.
  • Die herkömmlichen Internet-Protokolle zur Unterdrückung von TCP/IP-Headern verwenden ein Schema zur Delta-Codierung mit variabler Länge, um sich ändernde Felder darzustellen. Die vorliegende Technik ist für die Merkmale von Hochgeschwindigkeits-TCP/IP-Netzwerken optimiert. Bei solchen Netzwerken werden die sich ändernden TCP-Felder (das heißt Bestätigung (ACK), Folgenummer (SEQ), Fenster (WIN)) in der Regel um mehr als 255 Einheiten inkrementiert. Das Codieren dieser Änderungen mit einem festen, zwei Byte langen Delta-Feld optimiert den typischen Fall für Hochgeschwindigkeits-Netzwerke und verringert die für jedes übertragen TCP-Protokollpaket 1410 erforderliche Verarbeitung.
  • 18 ist ein Diagramm, das einen endgültigen, codierten Datenstrom 1800 veranschaulicht, der an einen Empfänger (das heißt an ein CMTS) gesendet wird, wenn das L-Bit 1702 nicht gesetzt ist. 18 zeigt eine erste Zeile 1802 für jedes Feld in dem endgültigen, codierten Datenstrom 1800 und eine zweite Zeile 1804, die eine Anzahl von Bytes angibt, die jedem Feld in dem endgültigen, codierten Datenstrom 1800 entspricht.
  • Ein erstes Feld 1806 entspricht dem Änderungs-Byte 1700. Wie zuvor angegeben, umfasst das Änderungs-Byte 1700 das eine Byte 1806.
  • Ein zweites Feld 1808 entspricht einem Delta-codierten Wert für das IP-Paket-ID-Feld 1426. Der Delta-codierte Wert 1808 für das IP-Paket-ID-Feld 1426 kann entweder aus 0 oder aus 2 Byte Daten bestehen (1809), je nachdem, ob ein Wert in den Schablonen-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll oder ob der Wert des IP-Paket-ID-Felds 1426 um entweder 0x0001 oder 0x0100 inkrementiert werden soll. Wenn ein Wert in den Schablonen-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll, enthält der endgültige, codierte Datenstrom 1800 2 Byte für das IP-Paket-ID-Feld 1426. Wenn kein Wert in den Schablonen-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll, enthält der endgültige, codierte Datenstrom 1800 keine Bytes für die IP-Paket-ID 1426. Stattdessen wird unter Verwendung des I(1)-Bits 1704 und des I(0)-Bits 1706 des Änderungs-Bytes 1700 ein Inkrementwert für das IP-Paket-ID-Feld 1426 bestimmt.
  • Ein drittes Feld 1810 entspricht einem Delta-codierten Wert für die TCP-Folgenummer 1446. Der Delta-codierte Wert 1810 für das TCP-Folgenummernfeld 1446 kann entweder aus 0 oder aus 2 Byte Daten (1811) bestehen, je nachdem, ob eine Änderung in dem TCP-Folgenummernfeld 1446 gegenüber dem zuvor übertragenen Wert erfolgt ist. Wenn eine Änderung in dem TCP-Folgenummernfeld 1446 gegenüber dem zuvor übertragenen Wert erfolgt ist, wird das S-Bit 1708 des Änderungs-Bytes 1700 gesetzt, und der endgültige, codierte Datenstrom 1800 enthält 2 Byte Daten zum Aktualisieren des TCP-Folgenummernfelds 1446 in dem Schablonen-Header. Wenn keine Änderung in dem TCP-Folgenummernfeld 1446 gegenüber dem zuvor übertragenen Wert erfolgt ist, wird das S-Bit 1708 des Änderungs-Bytes 1700 nicht gesetzt, und der endgültige, codierte Datenstrom 1800 enthält keine Bytes für das TCP-Folgenummernfeld 1446.
  • Ein viertes Feld 1812 entspricht einem Delta-codierten Wert für das TCP-Bestätigungsnummernfeld 1448. Der Delta-codierte Wert 1812 für das TCP-Bestätigungsnummernfeld 1448 kann entweder aus 0 oder aus 2 Byte Daten (1813) bestehen, je nachdem, ob eine Änderung in dem TCP-Bestätigungsnummernfeld 1448 gegenüber dem zuvor übertragenen Wert erfolgt ist. Wenn eine Änderung in dem TCP-Bestätigungsnummernfeld 1448 gegenüber dem zuvor übertragenen Wert erfolgt ist, wird das A-Bit 1710 des Änderungs-Bytes 1700 gesetzt, und der endgültige, codierte Datenstrom 1800 enthält 2 Byte Daten zum Aktualisieren des TCP-Bestätigungsnummernfelds 1448 in dem Schablonen-Header. Wenn keine Änderung in dem TCP-Bestätigungsnummernfeld 1448 gegenüber dem zuvor übertragenen Wert erfolgt ist, wird das A-Bit 1710 des Änderungs-Bytes 1700 nicht gesetzt, und der endgültige, codierte Datenstrom 1800 enthält keine Bytes für das TCP-Bestätigungsnummernfeld 1448.
  • Ein fünftes Feld 1814 dient als TCP-Daten-Offset-Feld 1450. Ein Wert für das TCP-Daten-Offset-Feld 1450 besteht aus 1 Byte Daten (1815), die in den endgültigen, codierten Datenstrom 1800 eingefügt werden sollen.
  • Ein sechstes Feld 1816 dient als TCP-Fensterfeld 1454. Ein Wert für das TCP-Fensterfeld 1454 kann entweder aus 0 oder aus 2 Byte Daten (1817) bestehen, je nachdem, ob eine Änderung in dem TCP-Fensterfeld 1454 gegenüber dem zuvor übertragenen Wert erfolgt ist. Wenn eine Änderung in dem TCP-Fensterfeld 1454 gegenüber dem zuvor übertragenen Wert erfolgt ist, wird das W-Bit 1714 des Änderungs-Bytes 1700 gesetzt, und der endgültige, codierte Datenstrom 1800 enthält 2 Byte Daten zum Aktualisieren des TCP-Fensterfelds 1454 in dem Schablonen-Header. Wenn keine Änderung in dem TCP-Fensterfeld 1454 gegenüber dem zuvor übertragenen Wert erfolgt ist, wird das W-Bit 1714 des Änderungs-Bytes 1700 nicht gesetzt, und der endgültige, codierte Datenstrom 1800 enthält keine Bytes für das TCP-Fensterfeld 1454.
  • Ein siebtes Feld 1818 dient als TCP-Prüfsummenfeld 1456. Ein Wert für das TCP-Prüfsummenfeld 1456 besteht aus 2 Byte Daten (1819), die in den endgültigen, codierten Datenstrom 1800 eingefügt werden.
  • Ein fünftes Feld 1820 entspricht dem TCP-Feld für den Zeiger 'Dringend' 1458. Ein Wert für das TCP-Feld für den Zeiger 'Dringend' 1458 kann entweder aus 0 oder aus 2 Byte Daten (1821) bestehen, je nachdem, ob ein IP-Dringlichkeits-Flag 'Urgent' in dem Flag-Feld 1452 gesetzt ist. Wenn das IP-Dringlichkeits-Flag 'Urgent' in dem Flag-Feld 1452 gesetzt ist, wird das U-Bit 1716 des Änderungs-Bytes 1700 gesetzt, und der endgültige, codierte Datenstrom 1800 enthält 2 Byte Daten, die in den Schablonen-Header kopiert werden sollen. Wenn das IP-Dringlichkeits-Flag 'Urgent' in dem Flag-Feld 1452 nicht gesetzt ist, wird das U-Bit 1716 des Änderungs-Bytes 1700 nicht gesetzt, und der endgültige, codierte Datenstrom 1800 enthält keine Bytes für das TCP-Feld für den Zeiger 'Dringend' 1458.
  • Ein neuntes Feld 1822 dient als TCP-PDU-Feld 1460. Die TCP-PDU kann aus 0 bis n Bytes (1823) bestehen.
  • 19 ist ein Diagramm, das eine Übertragungsreihenfolge 1900 für den endgültigen, codierten Datenstrom 1800 veranschaulicht, wenn das L-Bit 1702 nicht gesetzt ist. Die Übertragungsreihenfolge 1900 beginnt mit dem Änderungs-Byte 1700. Danach folgen die Felder 1808, 1810, 1812, 1814, 1816, 1818, 1820 und 1822.
  • 20 ist ein Diagramm, das eine Übertragungsreihenfolge 2000 veranschaulicht, wenn das L-Bit 1702 gesetzt ist. Dies gibt an, dass die gerade übertragenen Header-Informationen von dem Empfänger erlernt werden sollen. Die Übertragungsreihenfolge 2000 besteht aus einem Änderungs-Byte 1700, Fülldaten 2002, dem 54 Byte langen TCP-Protokoll-Header 1410 und der PDU 1460.
  • 21 ist ein Ablaufdiagramm 2100, das ein Verfahren zur Unterdrückung von TCP-Headern veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 2100 bereitgestellt wird. Vielmehr ist für Fachleute auf dem bzw. den relevanten Gebiet(en) nach dem Lesen der in diesem Dokument bereitgestellten Lehren offensichtlich, dass auch andere funktionelle Ablaufdiagramme in dem Schutzumfang der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 2102, in dem eine TCP-Unterdrückungsfunktion gestartet wird. Der Prozess wird dann bei Schritt 2104 fortgesetzt.
  • In Schritt 2104 werden das L-Bit 1702, das I(1)-Bit 1704, das I(0)-Bit 1706, das S-Bit 1708, das A-Bit 1710, das P-Bit 1712, das W-Bit 1714 und das U-Bit 1716 des Änderungs-Bytes 1700 bestimmt. Das Änderungs-Byte wird dann nach temp(0) kopiert. Der Prozess wird dann bei Entscheidungsschritt 2106 fortgesetzt.
  • In Entscheidungsschritt 2106 wird bestimmt, ob das L-Bit 1702 gesetzt ist. Wenn das L-Bit 1702 gesetzt ist, gibt dies an, dass der 802.3/IP/TCP-Protokoll-Header in seiner Gesamtheit gesendet werden soll, damit er von einem Empfänger, wie beispielsweise dem CMTS 104 erlernt werden kann. Der Prozess wird dann bei Schritt 2108 fortgesetzt.
  • In Schritt 2108 wird ein neuer Puffer zugeordnet. Der Prozess wird dann bei Schritt 2110 fortgesetzt.
  • In Schritt 2110 werden das Änderungs-Byte 1700 und ein einzelnes Füll-Byte in dem in Schritt 2108 zugeordneten Puffer gespeichert. Es sollten von der Systemhardware aus gesehen keine Puffer vorhanden sein, denen ein einzelnes Byte zugeordnet ist. Somit besteht eine Hardwarebeschränkung darin, Puffer mit mehr als 1 Byte bereitzustellen. Somit wird auch ein Füll-Byte in den Puffer eingefügt. Der Prozess wird dann bei Schritt 2112 fortgesetzt.
  • In Schritt 2112 wird ein ursprünglicher Puffer, der das TCP-Protokollpaket 1410 hält, auf einem BD-Ring an den neuen Puffer angehängt. Der Prozess wird dann bei Schritt 2114 fortgesetzt.
  • In Schritt 2114 werden die ursprüngliche Pufferlänge und die neue Pufferlänge übertragen. Somit werden das Änderungs-Byte und Fülldaten zum Erlernen des vollständigen 802.3/IP/TCP-Headers 1400 zusammen mit dem 54 Byte langen Header und der PDU 1460 übertragen. Wenn das L-Bit 1702 gesetzt ist, gilt die Übertragungsreihenfolge 2000. Der Prozess wird dann bei Schritt 2116 fortgesetzt, wo der Prozess endet.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2106 das L-Bit 1702 nicht gesetzt ist, wird der Prozess bei Schritt 2118 fortgesetzt. In Schritt 2118 wird die Länge von temp berechnet, und es wird ein Zeiger auf den Puffer [54] minus der Länge von temp gesetzt. Die Länge von temp umfasst die Länge aller Daten, die in dem endgültigen, codierten Datenstrom 1800 gesendet werden. Der Prozess wird dann bei Schritt 2120 fortgesetzt.
  • In Schritt 2120 wird temp in den Zeiger kopiert. Der Prozess wird dann bei Schritt 2122 fortgesetzt.
  • In Schritt 2122 wird der Zeiger auf dem BD-Ring platziert. Der Prozess wird dann bei Schritt 2124 fortgesetzt.
  • In Schritt 2124 wird die ursprüngliche Länge – [54] + Länge von temp übertragen. Somit wird der endgültige, codierte Datenstrom 1800 übertragen. Wenn das L-Bit 1702 nicht gesetzt ist, gilt die Übertragungsreihenfolge 1900. Der Prozess wird dann bei Schritt 2116 fortgesetzt, wo der Prozess endet.
  • 22 ist ein Ablaufdiagramm 2200, das ein Verfahren zur Rekonstruktion von TCP-Headern veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die in diesem Dokument im Hinblick auf das Ablaufdiagramm 2200 bereitgestellt wird. Vielmehr ist für Fachleute auf dem bzw. den relevanten Gebiet(en) nach dem Lesen der in diesem Dokument bereitgestellten Lehren offensichtlich, dass auch andere funktionelle Ablaufdiagramme in dem Schutzumfang der vorliegenden Erfindung liegen. Ein 54 Byte langer Schablonen-Header wird vor dem Start des Ablaufdiagramms 2200 durch die Engine zur Header-Rekonstruktion für DOCSIS-Nutzdaten (nicht gezeigt) generiert. Der Prozess beginnt bei Schritt 2202, in dem eine TCP-Rekonstruktionsfunktion gestartet wird. Der Prozess wird dann bei Schritt 2204 fortgesetzt.
  • In Schritt 2204 wird ein 54 Byte langer Header aus dem Eingabedatenstrom gelesen. Der Prozess wird dann bei Schritt 2206 fortgesetzt.
  • In Schritt 2206 wird das Änderungs-Byte 1700 aus dem Eingabedatenstrom gelesen. Der Prozess wird dann bei Entscheidungsschritt 2208 fortgesetzt.
  • In Entscheidungsschritt 2208 wird bestimmt, ob das L-Bit 1702 des Änderungs-Bytes 1700 gesetzt ist. Wenn das L-Bit 1702 gesetzt ist, wird der Prozess bei Schritt 2210 fortgesetzt.
  • In Schritt 2210 wird der 54 Byte lange Header, der in Schritt 2204 erfasst wurde, verworfen. Diese Daten werden verworfen, weil diese Daten nicht aus dem Eingabedatenstrom generiert wurden, sondern durch den Mechanismus der Hardware zur Unterdrückung von Nutzdaten-Headern am Ende des Rekonstruktionsprozesses generiert wurden, was weiter unten noch unter Bezugnahme auf Schritt 2216 erörtert wird. Wenn der Mechanismus der Hardware zur Unterdrückung von Nutzdaten-Headern diesen 54 Byte langen Header einbringt, wird der 54 Byte lange Header vor dem Änderungs-Byte 1700 platziert. Wenn das L-Bit 1702 gesetzt ist, wird somit dieser 54 Byte lange Header als Abfall betrachtet und muss verworfen werden. Aus Sicht des Kabelmodems 108 handelte es sich bei den gesendeten Daten um einen Unterdrückungsindex. Der Empfang des Unterdrückungsindex durch das CMTS 104 bewirkte, dass das CMTS 104 54 Byte nicht korrekte Daten in den Datenstrom eingebracht hat. Der Prozess wird dann bei Schritt 2212 fortgesetzt.
  • In Schritt 2212 werden 1 Byte lange Fülldaten aus dem Eingabedatenstrom gelesen und verworfen. Der Prozess wird dann bei Schritt 2214 fortgesetzt.
  • In Schritt 2214 wird der korrekte 54 Byte lange Header, der von dem Kabelmodem 108 übertragen wurde, aus dem Eingabedatenstrom gelesen. Der Prozess wird dann bei Schritt 2216 fortgesetzt.
  • In Schritt 2216 wird der 54 Byte lange Header in einen Schablonen-Header kopiert, und der 54 Byte lange Header und die folgenden Daten aus der PDU 1460 werden abgeschickt. Der Prozess wird dann bei Schritt 2218 fortgesetzt, wo der Prozess endet.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2208 das L-Bit 1702 des Änderungs-Bytes 1700 nicht gesetzt ist, wird der Prozess bei Entscheidungsschritt 2220 fortgesetzt.
  • Der Entscheidungsschritt 2220 beginnt den Prozess des Bestimmens, ob das IP-Paket-ID-Feld 1426 um 0x0001 oder um 0x0100 inkrementiert werden soll oder ob ein 2 Byte langer Wert aus dem Eingabedatenstrom in den Schablonen-Header des IP-Paket-ID-Felds 1426 kopiert werden soll. In Entscheidungsschritt 2220 wird bestimmt, ob das I(1)-Bit 1704 des Änderungs-Bytes 1700 gesetzt ist. Wenn das I(1)-Bit gesetzt ist, wird der Prozess bei Schritt 2222 fortgesetzt.
  • In Schritt 2222 wird ein 2 Byte langer Wert aus dem Eingabedatenstrom gelesen und in das IP-Paket-ID-Feld 1426 (Offset 18) kopiert. Der Prozess wird dann bei Schritt 2230 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2220 das I(1)-Bit 1704 des Änderungs-Bytes 1700 nicht gesetzt ist, wird der Prozess bei Entscheidungsschritt 2224 fortgesetzt. In Entscheidungsschritt 2224 wird bestimmt, ob das I(0)-Bit 1706 des Änderungs-Bytes 1700 gesetzt ist. Wenn das I(0)-Bit 1706 nicht gesetzt ist, wird der Prozess bei Schritt 2226 fortgesetzt.
  • In Schritt 2226 wird 0x0001 zu der IP-Paket-ID 1426 bei Offset 18 addiert. Der Prozess wird dann bei Schritt 2230 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2224 das I(0)-Bit 1706 des Änderungs-Bytes 1700 gesetzt ist, wird der Prozess bei Schritt 2228 fortgesetzt. In Schritt 2228 wird 0x0100 zu der IP-Paket-ID 1426 bei Offset 18 addiert. Der Prozess wird dann bei Entscheidungsschritt 2230 fortgesetzt.
  • In Entscheidungsschritt 2230 wird bestimmt, ob das S-Bit 1708 des Änderungs-Bytes 1700 gesetzt ist. Wenn das S-Bit 1708 gesetzt ist, was angibt, dass eine Änderung in dem TCP-IP-Paket-ID-Feld 1426 gegenüber dem vorherigen Wert erfolgt ist, wird der Prozess bei Schritt 2232 fortgesetzt.
  • In Schritt 2232 werden die nächsten 2 Byte Daten aus dem Eingabedatenstrom zu dem TCP-IP-Paket-ID-Feld 1426 bei Offset 38 hinzugefügt. Der Prozess wird dann bei Entscheidungsschritt 2234 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2230 das S-Bit 1708 des Änderungs-Bytes 1700 nicht gesetzt ist, wird der Prozess bei Entscheidungsschritt 2234 fortgesetzt.
  • In Entscheidungsschritt 2234 wird bestimmt, ob das A-Bit 1710 des Änderungs-Bytes 1700 gesetzt ist. Wenn das A-Bit 1710 gesetzt ist, was angibt, dass eine Änderung in dem TCP-Bestätigungsnummernfeld 1448 erfolgt ist, wird der Prozess bei Schritt 2236 fortgesetzt.
  • In Schritt 2236 werden die nächsten 2 Byte Daten aus dem Eingabedatenstrom zu dem TCP-Bestätigungsnummernfeld 1448 bei Offset 42 hinzugefügt. Der Prozess wird dann bei Schritt 2238 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2234 das A-Bit 1710 des Änderungs-Bytes 1700 nicht gesetzt ist, wird der Prozess bei Schritt 2238 fortgesetzt.
  • In Schritt 2238 wird das nächste Byte Daten aus dem Eingabedatenstrom in das TCP-Daten-Offset-Feld 1450 bei Offset 46 kopiert. Der Prozess wird bei Entscheidungsschritt 2240 fortgesetzt.
  • In Entscheidungsschritt 2240 wird bestimmt, ob das P-Bit 1712 des Änderungs-Bytes 1700 gesetzt ist. Wenn das P-Bit 1712 gesetzt ist, wird der Prozess bei Schritt 2242 fortgesetzt.
  • In Schritt 2242 wird der Wert 0x08 über eine OR-Operation mit den Daten in dem TCP-Flag-Feld 1452 bei Offset 47 verknüpft. Der Prozess wird bei Entscheidungsschritt 2246 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2240 das P-Bit 1712 des Änderungs-Bytes 1700 nicht gesetzt ist, wird der Prozess bei Schritt 2244 fortgesetzt.
  • In Schritt 2244 wird der Wert 0xF7 über eine AND-Operation mit den Daten in dem TCP-Flag-Feld 1452 bei Offset 47 verknüpft. Der Prozess wird bei Entscheidungsschritt 2246 fortgesetzt.
  • In Entscheidungsschritt 2246 wird bestimmt, ob das W-Bit 1714 des Änderungs-Bytes 1700 gesetzt ist. Wenn das W-Bit 1714 gesetzt ist, was angibt, dass eine Änderung in dem TCP-Fensterfeld 1454 erfolgt ist, wird der Prozess bei Schritt 2248 fortgesetzt.
  • In Schritt 2248 werden die nächsten 2 Byte Daten aus dem Eingabedatenstrom in das TCP-Fensterfeld 1454 bei Offset 48 kopiert. Der Prozess wird dann bei Schritt 2250 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf den Entscheidungsschritt 2246 bestimmt wird, dass das W-Bit 1714 des Änderungs-Bytes 1700 nicht gesetzt ist, wird der Prozess bei Schritt 2250 fortgesetzt.
  • In Schritt 2250 werden die nächsten 2 Byte Daten aus dem Eingabedatenstrom in das TCP-Prüfsummenfeld 1456 bei Offset 50 kopiert. Der Prozess wird dann bei Entscheidungsschritt 2252 fortgesetzt.
  • In Entscheidungsschritt 2252 wird bestimmt, ob das U-Bit 1716 des Änderungs-Bytes 1700 gesetzt ist. Wenn das U-Bit 1716 gesetzt ist, wird der Prozess bei Schritt 2254 fortgesetzt.
  • In Schritt 2254 werden die nächsten 2 Byte Daten aus dem Eingabedatenstrom in das TCP-Feld für den Zeiger 'Dringend' 1458 bei Offset 52 kopiert. Der Prozess wird dann bei Schritt 2256 fortgesetzt.
  • In Schritt 2256 wird das U-Bit in dem TCP-Flag-Feld 1452 gesetzt, indem der Wert 0x20 über eine OR-Operation mit dem TCP-Flag-Feld 1452 bei Offset 47 verknüpft wird. Der Prozess wird dann bei Schritt 2260 fortgesetzt.
  • Wenn unter nochmaliger Bezugnahme auf Entscheidungsschritt 2252 das U-Bit 1716 des Änderungs-Bytes 1700 nicht gesetzt ist, wird der Prozess bei Schritt 2258 fortgesetzt. In Schritt 2258 wird das Setzen des U-Bits in dem TCP-Flag-Feld 1452 rückgängig gemacht, indem der Wert OxDF über eine AND-Operation mit dem TCP-Flag-Feld 1452 bei Offset 47 verknüpft wird. Der Prozess wird dann bei Schritt 2260 fortgesetzt.
  • In Schritt 2260 wird das IP-Gesamtlängenfeld 1424 gleich der verbleibenden Lange der PDU 1460 plus 40 Byte gesetzt. Ein neues IP-Header-Prüfsummenfeld 1434 wird bestimmt und bei Offset 24 in dem Schablonen-Header platziert. Die IP-Header-Prüfsumme ist das 16 Bit lange Einerkomplement der Summe der Einerkomplemente der Werte bei den Offsets 14, 16, 18, 22, 26, 28, 30 und 32. Der Prozess wird dann bei Schritt 2216 fortgesetzt, in dem 54 Byte in den Schablonen-Header kopiert und abgeschickt werden. Der Prozess wird dann bei Schritt 2218 fortgesetzt, wo der Prozess endet.
  • D. Umgebung
  • Wie bereits an anderer Stelle in diesem Dokument erörtert, können die oben beschriebenen Techniken oder Verfahren als Softwareroutinen teilweise durch den MAC-Teil eines Kabelmodems und den Kopfstellen-MAC-Teil eines CMTS ausgeführt werden. Zum Beispiel führt unter Bezugnahme auf die beispielhafte Implementierung des Kabelmodems 108, die unter Bezugnahme auf 3 beschrieben wurde, die MAC 314 notwendige Verfahrensschritte durch, indem Softwarefunktionen mit Unterstützung der CPU 320 ausgeführt werden. Diese Softwarefunktionen können entweder in dem RAM 322 oder in dem ROM 324 gespeichert sein. Außerdem führt unter Bezugnahme auf die beispielhafte Implementierung des CMTS 104 die Kopfstellen-MAC 218 notwendige Verfahrensschritte durch, indem Softwarefunktionen mit Unterstützung der CPU 222 ausgeführt werden. Diese Softwarefunktionen können entweder in dem RAM 220 oder in dem ROM 218 gespeichert sein.
  • Die Verfahren gemäß der vorliegenden Erfindung müssen jedoch nicht auf diese Ausführungsbeispiele beschränkt sein. Zum Beispiel können die Verfahren gemäß der vorliegenden Erfindung in Softwareroutinen verwirklicht sein, die auf Computersystemen ausgeführt werden, wie beispielsweise einem Computersystem 2300, wie in 23 gezeigt. Verschiedene Ausführungsbeispiele werden anhand dieses beispielhaften Computersystems 2300 beschrieben. Nach dem Lesen dieser Beschreibung ist es für einen Fachmann auf dem relevanten Gebiet offensichtlich, wie die Erfindung unter Verwendung anderer Computersysteme und/oder Computerarchitekturen implementiert werden kann. Das Computersystem 2300 umfasst einen oder mehrere Prozessoren, wie beispielsweise den Prozessor 2303. Der Prozessor 2303 ist mit einem Kommunikationsbus 2302 verbunden.
  • Das Computersystem 2300 umfasst außerdem einen Hauptspeicher 2305, vorzugsweise einen Speicher mit wahlfreien Zugriff (RAM), und kann außerdem einen sekundären Speicher 2310 umfassen. Der sekundäre Speicher 2310 kann zum Beispiel ein Festplattenlaufwerk 2312 und/oder ein Laufwerk für Wechseldatenträger 2314 umfassen, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein optisches Plattenlaufwerk, usw. darstellt. Das Laufwerk für Wechseldatenträger 2314 liest auf allgemein bekannte Weise von einer Wechseldatenträgereinheit 2318 und schreibt auf diese. Die Wechseldatenträgereinheit 2318 stellt eine Diskette, ein Magnetband, eine optische Platte, usw. dar, die bzw. das das Laufwerk für Wechseldatenträger 2314 liest und auf die bzw. das dieses schreibt. Wie erkennbar ist, umfasst die Wechseldatenträgereinheit 2318 ein von einem Computer verwendbares Speichermedium, auf dem Computersoftware und/oder Daten gespeichert sind.
  • In alternativen Ausführungsbeispielen kann der sekundäre Speicher 2310 andere, ähnliche Mittel umfassen, um es zu erlauben, dass Computerprogramme oder andere Anweisungen in das Computersystem 2300 geladen werden. Solche Mittel können zum Beispiel eine Wechseldatenträgereinheit 2322 und eine Schnittstelle 2320 umfassen. Beispiele hierfür können eine Programmkassette und eine Kassettenschnittstelle umfassen (wie sie in Vorrichtungen für Videospiele zu finden sind), einen herausnehmbaren Speicherchip (wie beispielsweise ein EPROM oder PROM) und den zugeordneten Sockel und weitere Wechseldatenträgereinheiten 2322 und Schnittstellen 2320, die es erlauben, dass Software und Daten von der Wechseldatenträgereinheit 2322 zu dem Computersystem 2300 transferiert werden.
  • Das Computersystem 2300 kann außerdem eine Kommunikationsschnittstelle 2324 umfassen. Die Kommunikationsschnittstelle 2324 erlaubt es, dass Software und Daten zwischen dem Computersystem 2300 und externen Vorrichtungen transferiert werden. Beispiele für die Kommunikationsschnittstelle 2324 können ein Modem, eine Netzwerkschnittstelle (wie beispielsweise eine Ethernet-Karte), einen Kommunikations-Port, einen PCMCIA-Slot mit Karte, eine Schnittstelle für drahtloses LAN (lokales Netzwerk), usw. umfassen. Über die Kommunikationsschnittstelle 2324 transferierte Software und Daten liegen in der Form von Signalen 2328 vor, bei denen es sich um elektronische, elektromagnetische, optische oder andere Signale handeln kann, die von der Kommunikationsschnittstelle 2324 empfangen werden können. Diese Signale 2328 werden der Kommunikationsschnittstelle 2324 über einen Kommunikationspfad (das heißt einen Kanal) 2326 bereitgestellt. Dieser Kanal 2326 trägt Signale 2328 und kann unter Verwendung von Draht oder Kabel, Glasfaser, einer Telefonleitung, einer Mobiltelefonverbindung, einer drahtlosen Verbindung und anderer Kommunikationskanäle implementiert werden.
  • In diesem Dokument bezieht sich der Begriff "Computerprogramm-Produkt" auf die Wechseldatenträgereinheiten 2318, 2322 und Signale 2328. Diese Computerprogramm-Produkte sind Mittel, um dem Computersystem 2300 Software bereitzustellen. Die Erfindung ist auf solche Computerprogramm-Produkte gerichtet.
  • Computerprogramme (die auch als Computer-Steuerlogik bezeichnet werden) werden in dem Hauptspeicher 2305 und/oder in dem sekundären Speicher 2310 und/oder in Computerprogramm-Produkten gespeichert. Computerprogramme können außerdem über eine Kommunikationsschnittstelle 2324 empfangen werden. Solche Computerprogramme versetzen, wenn sie ausgeführt werden, das Computersystem 2300 in die Lage, die Merkmale der vorliegenden Erfindung auszuführen, wie in diesem Dokument erörtert. Insbesondere versetzen die Computerprogramme, wenn sie ausgeführt werden, den Prozessor 2303 in die Lage, die Merkmale der vorliegenden Erfindung auszuführen. Demgemäß stellen solche Computerprogramme Steuereinheiten des Computersystems 2300 dar.
  • In einem Ausführungsbeispiel, in dem die Erfindung durch Verwendung von Software implementiert wird, kann die Software in einem Computerprogramm-Produkt gespeichert sein und unter Verwendung des Laufwerks für Wechseldatenträger 2314, des Festplattenlaufwerks 2312 oder der Kommunikationsschnittstelle 2324 in das Computersystem 2300 geladen werden. Wenn die Steuerlogik (Software) durch den Prozessor 2303 ausgeführt wird, veranlasst sie den Prozessor 2303, die Funktionen der Erfindung wie in diesem Dokument beschrieben auszuführen.
  • In einem weiteren Ausführungsbeispiel ist die Erfindung hauptsächlich in Hardware implementiert, wobei zum Beispiel Hardwarekomponenten wie ASICs (anwendungsspezifische ICs) verwendet werden. Die Implementierung einer oder mehrerer Hardware-Regelmaschine(n) zum Ausführen der in diesem Dokument beschriebenen Funktionen ist für Fachleute auf dem bzw. den relevanten Gebiet(en) offensichtlich.
  • In noch einem weiteren Ausführungsbeispiel ist die Erfindung unter Verwendung einer Kombination aus Hardware und Software implementiert.
  • E. Schlussbemerkung
  • Die vorliegende Erfindung ist nicht auf das Ausführungsbeispiel eines Kabelmodemsystems beschränkt. Die vorliegende Erfindung kann mit jedem beliebigen System verwendet werden, das TCP-Pakete über ein Netzwerk überträgt. Die obige Beschreibung der bevorzugten Ausführungsbeispiele wird bereitgestellt, um jeglichen Fachmann auf diesem Gebiet in die Lage zu versetzen, die vorliegende Erfindung auszuführen oder zu verwenden. Während die Erfindung insbesondere unter Bezugnahme auf deren bevorzugte Ausführungsbeispiele gezeigt und beschrieben wurde, werden die Fachleute auf diesem Gebiet verstehen, dass verschiedene Änderungen in Form und Einzelheiten davon vorgenommen werden können, ohne dass von dem Gedanken und Schutzumfang der Erfindung abgewichen wird.

Claims (19)

  1. Verfahren zum Optimieren der Übertragung von TCP/IP-Datenverkehr über ein DOCSIS-Netzwerk, das die folgenden Schritte umfasst: (a) Kommunizieren von Informationen (1602), die eine TCP-Delta-codierte Header-Unterdrückung betreffen, an einen Empfänger (104), wobei die Kommunikation eine Indexnummer, die eine Technik zur Unterdrückung von Paket-Headern angibt, sowie die Regeln umfasst, die mit dem Unterdrücken und Rekonstruieren eines Pakets gemäß der Technik zur Unterdrückung von Paket-Headern verbunden sind; (b) Identifizieren (1603) eines einzelnen TCP-Verbindungsdatenstroms unter Verwendung eines Framing-Protokolls, um jeden TCP-Verbindungsdatenstrom zu trennen und zu identifizieren; (c) anfängliches Übertragen eines ersten TCP-Protokollpakets (1410) in seiner Gesamtheit mit einem Lernindikator (1702) an den Empfänger (104), wobei der Lernindikator (1702) anfänglich den Empfänger (104) anweist, anfänglich den vollständigen Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) zu erlernen; (d) sobald der vollständige Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) anfänglich von dem Empfänger (104) gemäß Schritt (c) erlernt worden ist, werden Header von nachfolgenden Protokollpaketen (1500) nachfolgend in einem komprimierten Format übertragen durch: (e) Unterdrücken redundanter Felder (1412, 1418) in den Protokoll-Headern der nachfolgenden TCP-Protokollpakete (1500); und (d) Übertragen eines Delta-codierten Werts (1808) für jedes nicht redundante Feld (1426) in den Protokoll-Headern (1800) der nachfolgenden TCP-Protokollpakete (1500), wobei der Delta-codierte Wert (1808) eine Wertänderung von dem nicht redundanten Feld (1426) in dem Protokoll-Header eines vorherigen TCP-Protokollpakets (1410) darstellt.
  2. Verfahren nach Anspruch 1, wobei Schritt (c) ferner den Schritt des Codierens von Änderungen in nicht redundanten Feldern (1426) in den Protokoll-Headern von nachfolgenden TCP-Protokollpaketen (1500) mit einem festen, zwei Byte langen Delta-Feld (1809) umfasst.
  3. Verfahren nach Anspruch 1, wobei die nachfolgenden TCP-Protokollpakete (1500) mit einem Bitmuster-Änderungs-Byte (1700) beginnen, wobei Bits (1704, 1706) in dem Bitmuster-Änderungs-Byte (1700) angeben, welches der nicht redundanten Felder in dem Protokoll-Header (1800) der nachfolgenden TCP-Protokollpakete (1500) den Delta-codierten Wert (1808) aufweist.
  4. Verfahren nach Anspruch 1, das ferner die folgenden Schritte umfasst: (g) Ermöglichen, dass ein Empfänger (104) das erste TCP-Protokollpaket (1410) erlernt; (h) Ermöglichen, dass ein Empfänger (104) die unterdrückten redundanten Felder in den Protokoll-Headern von nachfolgenden TCP-Protokollpaketen (1500) unter Verwendung des ersten TCP-Protokollpakets (1410) wiederherstellt; (i) Ermöglichen, dass ein Empfänger (104) die nicht redundanten Felder (1426) in den Protokoll-Headern von nachfolgenden TCP-Protokollpaketen (1504) unter Verwendung der Delta-codierten Werte (1808) wiederherstellt; und (j) Ermöglichen, dass ein Empfänger (104) den wiederhergestellten Header vor jeglichen empfangenen Daten (1460) zur Übertragung über ein Internet-Protokoll-Netzwerk (112) platziert.
  5. Verfahren nach Anspruch 3, das ferner die folgenden Schritte umfasst: (g) Ermöglichen, dass ein Empfänger (104) das Bitmuster-Änderungs-Byte (1700) liest; (h) Ermöglichen, dass ein Empfänger (104) die Delta-codierten Werte (1808) unter Verwendung des Bitmuster-Änderungs-Bytes (1700) abruft; (i) Ermöglichen, dass ein Empfänger (104) die nicht redundanten Felder (1426) in dem Protokoll-Header der nachfolgenden TCP-Protokollpakete unter Verwendung der Delta-codierten Werte (1808) aktualisiert; und (j) Ermöglichen, dass ein Empfänger (104) die Protokoll-Header der nachfolgenden TCP-Protokollpakete in ihr ursprüngliches Format (1410) wiederherstellt.
  6. Verfahren nach Anspruch 5, das ferner den Schritt des Platzierens des wiederhergestellten Headers (1410) vor jeglichen empfangenen Daten (1460) zum Übertragen über ein Internet-Protokoll-Netzwerk (112) umfasst.
  7. Verfahren zum Empfangen von Paketen über ein TCP/IP-Übertragungsmedium, das die folgenden Schritte umfasst: (a) Empfangen von Informationen (1602), welche die TCP-Delta-codierte Header-Unterdrückung betreffen, wobei die Kommunikation eine Indexnummer, die eine Technik zur Unterdrückung von Paket-Headern angibt, sowie die Regeln umfasst, die mit dem Unterdrücken und Rekonstruieren eines Pakets gemäß der Technik zur Unterdrückung von Paket-Headern verbunden sind; (b) Identifizieren (1603) eines einzelnen TCP-Verbindungsdatenstroms unter Verwendung eines Framing-Protokolls, um jeden TCP-Verbindungsdatenstrom zu trennen und zu identifizieren; (c) anfängliches Empfangen eines ersten TCP-Protokollpakets (1410) in seiner Gesamtheit mit einem Lernindikator (1702), wobei der Lernindikator (1702) anfänglich anweist, anfänglich den vollständigen Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) zu erlernen; (d) sobald der vollständige Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) anfänglich gemäß Schritt (c) erlernt worden ist, werden Header von nachfolgenden Protokollpaketen (1500) nachfolgend in einem komprimierten Format übertragen; (e) Empfangen eines Delta-codierten Werts (1808) für jedes nicht redundante Feld (1426) in den Protokoll-Headern (1800) der nachfolgenden TCP-Protokollpakete (1500), wobei der Delta-codierte Wert (1808) eine Wertänderung von dem nicht redundanten Feld (1426) in dem Protokoll-Header eines vorherigen TCP-Protokollpakets (1410) darstellt.
  8. Verfahren nach Anspruch 7, wobei die nachfolgenden TCP-Protokollpakete (1500) ein Bitmuster-Änderungs-Byte (1700) umfassen, wobei Bits (1704, 1706) in dem Bitmuster-Änderungs-Byte (1700) angeben, welches der nicht redundanten Felder in den Protokoll-Headern (1800) den Delta-codierten Wert (1808) aufweist.
  9. Verfahren nach Anspruch 7, das ferner die folgenden Schritte umfasst: (f) Verwenden der erlernten Informationen von dem ersten TCP-Protokollpaket (1410), um die unterdrückten Felder (1808) in dem Protokoll-Header eines aktuellen TCP-Protokollpakets (1800) zu rekonstruieren; und (g) Verwenden des nachfolgenden TCP-Protokollpakets (1800), um die nicht redundanten Felder (1426) in dem Protokoll-Header des vorliegenden TCP-Protokollpakets zu rekonstruieren.
  10. Verfahren nach Anspruch 9, das ferner den Schritt des Wiederherstellens des vorliegenden TCP-Protokollpakets (1800) in sein ursprüngliches Format und des Übertragens des vorliegenden TCP-Protokollpakets über ein Internet-Protokoll-Netzwerk (112) umfasst.
  11. Computerprogramm-Produkt, das ein von einem Computer verwendbares Medium einschließlich darin gespeicherter Steuerlogik umfasst, wobei die Steuerlogik zum Optimieren der Übertragung von TCP/IP-Datenverkehr über ein DOCSIS-Netzwerk geeignet ist, wobei die Steuerlogik Folgendes umfasst: Kommunikationsmittel zum Kommunizieren von Informationen (1602), die eine TCP-Delta-codierte Header-Unterdrückung betreffen, an einen Empfänger, wobei die Kommunikation eine Indexnummer, die eine Technik zur Unterdrückung von Paket-Headern angibt, sowie die Regeln umfasst, die mit dem Unterdrücken und Rekonstruieren eines Pakets gemäß der Technik zur Unterdrückung von Paket-Headern verbunden sind; Identifikationsmittel zum Identifizieren eines einzelnen TCP-Verbindungsdatenstroms unter Verwendung eines Framing-Protokolls, um jeden TCP-Verbindungsdatenstrom zu trennen und zu identifizieren; erste Mittel, um es einem Prozessor (2303) zu ermöglichen, anfänglich ein erstes TCP-Protokollpaket (1410) in seiner Gesamtheit mit einem Lernindikator (1702) an einen Empfänger (104) zu übertragen (1604), wobei der Lernindikator (1702) anfänglich den Empfänger (104) anweist, anfänglich den vollständigen Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) zu erlernen; wobei die ersten Mittel ferner Mittel umfassen, um es einem Prozessor (2303) zu ermöglichen, Header von nachfolgenden Protokollpaketen (1500) nachfolgend in einem komprimierten Format zu übertragen, sobald der vollständige Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) anfänglich von dem Empfänger (104) erlernt worden ist; Mittel, um es einem Prozessor (2303) zu ermöglichen, redundante Felder (1412, 1418) in Protokoll-Headern von nachfolgenden TCP-Protokollpaketen (1500) zu unterdrücken; und zweite Mittel, um es einem Prozessor (2303) zu ermöglichen, einen Delta-codierten Wert (1808) für jedes nicht redundante Feld (1426) in den Protokoll-Headern (1800) der nachfolgenden TCP-Protokollpakete (1500) zu übertragen, wobei der Delta-codierte Wert (1808) eine Wertänderung von dem nicht redundanten Feld (1426) in dem Protokoll-Header eines vorherigen TCP-Protokollpakets (1410) darstellt.
  12. Computerprogramm-Produkt nach Anspruch 11, wobei die nachfolgenden TCP-Protokollpakete (1500) mit einem Bitmuster-Änderungs-Byte (1700) beginnen, wobei Bits (1704, 1706) in dem Bitmuster-Änderungs-Byte (1700) angeben, welches der nicht redundanten Felder in dem Protokoll-Header (1800) der nachfolgenden TCP-Protokollpakete (1500) den Delta-codierten Wert (1808) aufweist.
  13. Computerprogramm-Produkt nach Anspruch 11, das ferner Folgendes umfasst: Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, das erste TCP-Protokollpaket (1410) zu erlernen; Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, die unterdrückten redundanten Felder in den Protokoll-Headern von nachfolgenden TCP-Protokollpaketen (1500) unter Verwendung des ersten TCP-Protokollpakets (1410) wiederherzustellen; Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, die nicht redundanten Felder (1426) in den Protokoll-Headern von nachfolgenden TCP-Protokollpaketen (1500) unter Verwendung der Delta-codierten Werte (1808) wiederherzustellen; und Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, den wiederhergestellten Header vor jeglichen empfangenen Daten (1460) zur Übertragung über ein Internet-Protokoll-Netzwerk (112) zu platzieren.
  14. Computerprogramm-Produkt nach Anspruch 12, das ferner Folgendes umfasst: Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, das Bitmuster-Änderungs-Byte (1700) zu lesen; Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, die Delta-codierten Werte (1808) unter Verwendung des Bitmuster-Änderungs-Bytes (1700) abzurufen; Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, die nicht redundanten Felder (1426) in dem Protokoll-Header der nachfolgenden TCP-Protokollpakete unter Verwendung der Delta-codierten Werte (1808) zu aktualisieren; und Mittel, um es einem Prozessor (2303) zu ermöglichen, es einem Empfänger (104) zu ermöglichen, Protokoll-Header der nachfolgenden TCP-Protokollpakete in ihr ursprüngliches Format (1410) wiederherzustellen.
  15. Computerprogramm-Produkt nach Anspruch 14, das ferner Mittel umfasst, um es einem Prozessor (2303) zu ermöglichen, den wiederhergestellten Protokoll-Header (1410) vor jeglichen empfangenen Daten (1460) zum Übertragen über ein Internet-Protokoll-Netzwerk (112) zu platzieren.
  16. Computerprogramm-Produkt, das ein von einem Computer verwendbares Medium einschließlich darin gespeicherter Steuerlogik umfasst, wobei die Steuerlogik zum Ermöglichen des Empfangen von Paketen über ein TCP/IP-Übertragungsmedium geeignet ist, wobei die Steuerlogik Folgendes umfasst: Mittel zum Empfangen von Informationen (1602), welche eine TCP-Delta-codierte Header-Unterdrückung betreffen, wobei die Kommunikation eine Indexnummer, die eine Technik zur Unterdrückung von Paket-Headern angibt, sowie die Regeln umfasst, die mit dem Unterdrücken und Rekonstruieren eines Pakets gemäß der Technik zur Unterdrückung von Paket-Headern verbunden sind; Mittel zum Identifizieren (1603) eines einzelnen TCP-Verbindungsdatenstroms unter Verwendung eines Framing-Protokolls, um jeden TCP-Verbindungsdatenstrom zu trennen und zu identifizieren; Mittel, um es einem Prozessor zu ermöglichen, anfänglich ein erstes TCP-Protokollpaket (1410) in seiner Gesamtheit mit einem Lernindikator (1702) zu empfangen, wobei der Lernindikator (1702) anfänglich anweist, anfänglich den vollständigen Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) zu erlernen; erste Mittel, um es einem Prozessor zu ermöglichen, nachfolgend Header von nachfolgenden Protokollpaketen (1500) in einem komprimierten Format zu empfangen, sobald der vollständige Header (1402, 1404, 1406) des ersten TCP-Protokollpakets (1410) anfänglich erlernt worden ist, zweite Mittel, um es einem Prozessor zu ermöglichen, unterdrückte Felder in den Protokoll-Headern von nachfolgenden TCP-Protokollpaketen zu empfangen; und dritte Mittel, um es einem Prozessor zu ermöglichen, einen Delta-codierten Wert (1808) für jedes nicht redundante Feld (1426) in den Protokoll-Headern (1800) der nachfolgenden TCP-Protokollpakete (1500) zu empfangen, wobei der Delta-codierte Wert (1808) eine Wertänderung von dem nicht redundanten Feld (1426) in dem Protokoll-Header eines vorherigen TCP-Protokollpakets (1410) darstellt.
  17. Computerprogramm-Produkt nach Anspruch 16, wobei die nachfolgenden TCP-Protokollpakete (1500) ein Bitmuster-Änderungs-Byte (1700) umfassen, wobei Bits (1704, 1706) in dem Bitmuster-Änderungs-Byte (1700) angeben, welches der nicht redundanten Felder in dem Protokoll-Header (1800) der nachfolgenden TCP-Protokollpakete (1500) die Delta-codierten Werte (1808) aufweist.
  18. Computerprogramm-Produkt nach Anspruch 16, das ferner Folgendes umfasst: Mittel, um es einem Prozessor (2303) zu ermöglichen, das erste TCP-Protokollpaket (1410) zu erlernen; Mittel, um es einem Prozessor (2303) zu ermöglichen, die erlernten Informationen von dem ersten TCP-Protokollpaket (1410) zu verwenden, um die unterdrückten Felder (1808) in dem Protokoll-Header eines aktuellen TCP-Protokollpakets (1800) zu rekonstruieren; und Mittel, um es einem Prozessor (2303) zu ermöglichen, das nachfolgende TCP-Protokollpaket (1800) zu verwenden, um die nicht redundanten Felder (1426) in dem Protokoll-Header des vorliegenden TCP-Protokollpakets zu rekonstruieren.
  19. Computerprogramm-Produkt nach Anspruch 18, das ferner Mittel umfasst: um es einem Prozessor (2303) zu ermöglichen, das vorliegende TCP-Protokollpaket (1800) in sein ursprüngliches Format wiederherzustellen und das vorliegende TCP-Protokollpaket über ein Internet-Protokoll-Netzwerk (112) zu übertragen.
DE60131890T 2000-10-11 2001-10-11 Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung Expired - Lifetime DE60131890T2 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US23952400P 2000-10-11 2000-10-11
US23953000P 2000-10-11 2000-10-11
US23952600P 2000-10-11 2000-10-11
US23952700P 2000-10-11 2000-10-11
US23952500P 2000-10-11 2000-10-11
US239525P 2000-10-11
US239530P 2000-10-11
US239524P 2000-10-11
US239526P 2000-10-11
US239527P 2000-10-11
US24055000P 2000-10-13 2000-10-13
US240550P 2000-10-13
PCT/US2001/031556 WO2002032081A1 (en) 2000-10-11 2001-10-11 Dynamic delta encoding for cable modem header suppression

Publications (2)

Publication Number Publication Date
DE60131890D1 DE60131890D1 (de) 2008-01-24
DE60131890T2 true DE60131890T2 (de) 2008-12-11

Family

ID=27559291

Family Applications (4)

Application Number Title Priority Date Filing Date
DE60118609T Expired - Lifetime DE60118609T2 (de) 2000-10-11 2001-10-11 Kabelmodemsystem und Verfahren zur Unterstützung erweiterter Protokolle
DE60120466T Expired - Lifetime DE60120466T2 (de) 2000-10-11 2001-10-11 Effiziente Übertragung von RTP Paketen in einem Netzwerk
DE60131890T Expired - Lifetime DE60131890T2 (de) 2000-10-11 2001-10-11 Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung
DE60130367T Expired - Lifetime DE60130367T2 (de) 2000-10-11 2001-10-11 Verfahren zum dynamischen mischen von Paketkopfunterdrückungstechniken

Family Applications Before (2)

Application Number Title Priority Date Filing Date
DE60118609T Expired - Lifetime DE60118609T2 (de) 2000-10-11 2001-10-11 Kabelmodemsystem und Verfahren zur Unterstützung erweiterter Protokolle
DE60120466T Expired - Lifetime DE60120466T2 (de) 2000-10-11 2001-10-11 Effiziente Übertragung von RTP Paketen in einem Netzwerk

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60130367T Expired - Lifetime DE60130367T2 (de) 2000-10-11 2001-10-11 Verfahren zum dynamischen mischen von Paketkopfunterdrückungstechniken

Country Status (4)

Country Link
US (9) US7451235B2 (de)
EP (4) EP1348289B1 (de)
DE (4) DE60118609T2 (de)
WO (5) WO2002032101A2 (de)

Families Citing this family (179)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6993007B2 (en) * 1999-10-27 2006-01-31 Broadcom Corporation System and method for suppressing silence in voice traffic over an asynchronous communication medium
WO2001061924A2 (en) * 2000-02-15 2001-08-23 Broadcom Corporation Cable modem system and method for specialized data transfer
US6842459B1 (en) 2000-04-19 2005-01-11 Serconet Ltd. Network combining wired and non-wired segments
US6649567B2 (en) * 2001-10-11 2003-11-18 Isp Investments Inc. Controlled release microbiocide for porous surfaces
US7451235B2 (en) * 2000-10-11 2008-11-11 Broadcom Corporation Dynamic delta encoding for cable modem header suppression
KR100390427B1 (ko) * 2000-12-06 2003-07-07 엘지전자 주식회사 케이블 네트워크에서의 ｍａｃ 프레임 포맷 및 통신 설정방법
JP2002185880A (ja) * 2000-12-14 2002-06-28 Sony Corp 情報処理装置および方法、受信装置および方法、並びに記録媒体
US8009667B1 (en) * 2001-01-16 2011-08-30 Wi—LAN, Inc. Packing source data packets into transporting packets with fragmentation
US7769047B2 (en) * 2001-02-15 2010-08-03 Broadcom Corporation Methods for specialized data transfer in a wireless communication system
US7085232B1 (en) 2001-03-29 2006-08-01 Cisco Technology, Inc. ARQ in a point to multipoint network
US20020191691A1 (en) * 2001-05-10 2002-12-19 Holborow Clive Eric Payload header suppression including removal of fields that vary in known patterns
US7688824B2 (en) * 2001-07-11 2010-03-30 Broadcom Corporation Method, system, and computer program product for suppression index reuse and packet classification for payload header suppression
US7126920B2 (en) * 2001-08-08 2006-10-24 General Instrument Corporation Performance of lifetest using CMTS as a proxy
US7336680B2 (en) * 2001-09-18 2008-02-26 Scientific-Atlanta, Inc. Multi-carrier frequency-division multiplexing (FDM) architecture for high speed digital service
EP1440539A4 (de) * 2001-09-27 2009-08-26 Broadcom Corp Stark integrierte medien zugriffsregelung
US7586914B2 (en) * 2001-09-27 2009-09-08 Broadcom Corporation Apparatus and method for hardware creation of a DOCSIS header
WO2003039150A1 (en) 2001-10-11 2003-05-08 Serconet Ltd. Outlet with analog signal adapter, a method for use thereof and a network using said outlet
US7310352B2 (en) * 2001-10-31 2007-12-18 Juniper Networks, Inc. Context-dependent scheduling through the use of anticipated grants for broadband communication systems
US20030095567A1 (en) * 2001-11-20 2003-05-22 Lo Man Kuk Real time protocol packet handler
US6976085B1 (en) * 2001-11-20 2005-12-13 Cisco Technology, Inc. Methods and apparatus for inserting data into a communications session
US7602716B1 (en) * 2001-12-20 2009-10-13 Cisco Technology, Inc. Load sharing on DOCSIS
GB2386805B (en) * 2002-03-22 2004-05-26 Roke Manor Research Apparatus and method for compression of a signalling portion of a communications packet
US20030232547A1 (en) * 2002-06-17 2003-12-18 Ron Reiss Plug-in unit for cable modem
US20040022309A1 (en) * 2002-08-01 2004-02-05 Adc Telecommunications Israel Ltd. Multiple modem apparatus
JP4317403B2 (ja) * 2002-08-09 2009-08-19 パナソニック株式会社 ヘッダ圧縮装置及びヘッダ圧縮方法
US7324516B2 (en) * 2002-08-14 2008-01-29 Intel Corporation Data packet header conversion
US8051176B2 (en) 2002-11-07 2011-11-01 Hewlett-Packard Development Company, L.P. Method and system for predicting connections in a computer network
US7594032B2 (en) * 2002-11-07 2009-09-22 Hewlett-Packard Development Company, L.P. Method and system for communicating information between a switch and a plurality of servers in a computer network
JP3853765B2 (ja) * 2002-11-08 2006-12-06 Ｎｅｃインフロンティア株式会社 パケット圧縮方式及びパケット復元方式並びにパケット圧縮方法及びパケット復元方法
IL152824A (en) 2002-11-13 2012-05-31 Mosaid Technologies Inc A socket that can be connected to and the network that uses it
US20040120357A1 (en) * 2002-12-23 2004-06-24 Sami Kekki On-demand header compression
US7386013B1 (en) * 2003-01-03 2008-06-10 Juniper Networks, Inc. Systems and methods for compressing packet headers
US8254372B2 (en) 2003-02-21 2012-08-28 Genband Us Llc Data communication apparatus and method
US7706316B1 (en) * 2003-03-26 2010-04-27 Cisco Technology, Inc. Processing an incoming packet of unknown protocol by encapsulating the packet and sending it to another processor
US7424558B2 (en) * 2003-05-01 2008-09-09 Genesis Microchip Inc. Method of adaptively connecting a video source and a video display
US7405719B2 (en) * 2003-05-01 2008-07-29 Genesis Microchip Inc. Using packet transfer for driving LCD panel driver electronics
US7068686B2 (en) 2003-05-01 2006-06-27 Genesis Microchip Inc. Method and apparatus for efficient transmission of multimedia data packets
US7567592B2 (en) * 2003-05-01 2009-07-28 Genesis Microchip Inc. Packet based video display interface enumeration method
US7733915B2 (en) * 2003-05-01 2010-06-08 Genesis Microchip Inc. Minimizing buffer requirements in a digital video system
US8068485B2 (en) 2003-05-01 2011-11-29 Genesis Microchip Inc. Multimedia interface
US20040218624A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Packet based closed loop video display interface with periodic status checks
US8059673B2 (en) * 2003-05-01 2011-11-15 Genesis Microchip Inc. Dynamic resource re-allocation in a packet based video display interface
US20040221312A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Techniques for reducing multimedia data packet overhead
US7620062B2 (en) 2003-05-01 2009-11-17 Genesis Microchips Inc. Method of real time optimizing multimedia packet transmission rate
US20040218599A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Packet based video display interface and methods of use thereof
US8204076B2 (en) * 2003-05-01 2012-06-19 Genesis Microchip Inc. Compact packet based multimedia interface
US7839860B2 (en) * 2003-05-01 2010-11-23 Genesis Microchip Inc. Packet based video display interface
US8040915B2 (en) 2003-05-19 2011-10-18 Broadcom Corporation System, method, and computer program product for facilitating communication between devices implementing proprietary features in a DOCSIS-compliant broadband communication system
US20050030944A1 (en) * 2003-05-27 2005-02-10 General Instrument Corporation Method and apparatus for reducing packet size employing payload header suppression (PHS)
IL157787A (en) 2003-09-07 2010-12-30 Mosaid Technologies Inc Modular outlet for data communications network
US7450586B2 (en) * 2003-07-22 2008-11-11 Motorola, Inc. Network header compression arrangement
US7417989B1 (en) * 2003-07-29 2008-08-26 Sprint Spectrum L.P. Method and system for actually identifying a media source in a real-time-protocol stream
US11736311B2 (en) 2003-09-05 2023-08-22 Comcast Cable Communications, Llc Gateway for transporting out-of-band messaging signals
US7961742B2 (en) * 2003-09-05 2011-06-14 Comcast Cable Holdings, Llc Cable modem termination system having a gateway for transporting out-of-band messaging signals
WO2005024589A2 (en) * 2003-09-05 2005-03-17 Comcast Cable Holdings, Llc Cable modem termination system having a gateway for transporting out-of-band messaging signals
US7450579B2 (en) * 2003-09-09 2008-11-11 Broadcom Corporation Downstream synchronous multichannels for a communications management system
US7487273B2 (en) * 2003-09-18 2009-02-03 Genesis Microchip Inc. Data packet based stream transport scheduler wherein transport data link does not include a clock line
US7800623B2 (en) * 2003-09-18 2010-09-21 Genesis Microchip Inc. Bypassing pixel clock generation and CRTC circuits in a graphics controller chip
FR2860114A1 (fr) * 2003-09-23 2005-03-25 Cit Alcatel Procede perfectionne de transmission de paquets comportant des echantillons de signaux sonores entre deux reseaux a commutation de paquets separes par un reseau a commutation de circuits
GB0322491D0 (en) * 2003-09-25 2003-10-29 British Telecomm Virtual networks
US7613300B2 (en) * 2003-09-26 2009-11-03 Genesis Microchip Inc. Content-protected digital link over a single signal line
US7634090B2 (en) * 2003-09-26 2009-12-15 Genesis Microchip Inc. Packet based high definition high-bandwidth digital content protection
US7567559B2 (en) * 2003-09-30 2009-07-28 Intel Corporation Device, system and method for data transfer optimization
US20050078699A1 (en) * 2003-10-10 2005-04-14 Broadcom Corporation System, method, and computer program product for utilizing proprietary communication parameters to improve channel efficiency in a DOCSIS-compliant broadband communication system
US7370100B1 (en) * 2003-12-10 2008-05-06 Foundry Networks, Inc. Method and apparatus for load balancing based on packet header content
IL159838A0 (en) 2004-01-13 2004-06-20 Yehuda Binder Information device
IL160417A (en) 2004-02-16 2011-04-28 Mosaid Technologies Inc Unit added to the outlet
US8027265B2 (en) 2004-03-19 2011-09-27 Genband Us Llc Providing a capability list of a predefined format in a communications network
US7990865B2 (en) 2004-03-19 2011-08-02 Genband Us Llc Communicating processing capabilities along a communications path
US8351468B2 (en) 2004-04-05 2013-01-08 Broadcom Corporation Method and apparatus for downloading content using channel bonding
IL162305A (en) * 2004-06-02 2010-06-16 Eci Telecom Ltd Method, device and system for transmitting ethernet packets
GB2417401B (en) * 2004-08-18 2007-04-25 Wecomm Ltd Data transmission over a network
US20070297319A1 (en) * 2004-08-25 2007-12-27 Roberts Harold G Compression in Cable Data Service
US7729346B2 (en) 2004-09-18 2010-06-01 Genband Inc. UMTS call handling methods and apparatus
US7830864B2 (en) 2004-09-18 2010-11-09 Genband Us Llc Apparatus and methods for per-session switching for multiple wireline and wireless data types
KR100677144B1 (ko) * 2004-10-20 2007-02-02 삼성전자주식회사 Ｗｕｓｂ 버스를 경유하여 데이터를 송수신하는 방법 및장치
US8971898B2 (en) * 2004-10-22 2015-03-03 Genband Us Llc Mobility management apparatus and methods
CN101027862B (zh) * 2004-10-29 2011-06-08 美国博通公司 对通信流量分级的多信道通信
US7729385B2 (en) * 2004-11-01 2010-06-01 Nokia Corporation Techniques for utilization of spare bandwidth
US8705567B2 (en) * 2004-12-10 2014-04-22 Broadcom Corporation Upstream channel bonding using legacy maps in a cable communications system
US8711878B2 (en) * 2004-12-10 2014-04-29 Broadcom Corporation Upstream channel bonding in a cable communications system
US8228926B2 (en) * 2005-04-12 2012-07-24 Genband Us Llc Dynamic loading for signaling variants
US20060262788A1 (en) * 2005-05-23 2006-11-23 Broadcom Corporation Dynamic payload header suppression extensions for IPV6
US8483173B2 (en) 2005-05-31 2013-07-09 Genband Us Llc Methods and systems for unlicensed mobile access realization in a media gateway
US7668195B2 (en) * 2005-06-14 2010-02-23 General Instrument Corporation Method and apparatus for transmitting and receiving data over a shared access carrier network
US7710966B1 (en) * 2005-07-19 2010-05-04 Google Inc. Distributing packets more evenly over trunked network links
US7961739B2 (en) * 2005-07-21 2011-06-14 Genband Us Llc Systems and methods for voice over multiprotocol label switching
US7961754B2 (en) * 2005-07-26 2011-06-14 Electronics And Telecommunications Research Institute Apparatus and method for multimedia data transmission and reception in cable network using broadband and physical layer frame structure
US20070086434A1 (en) * 2005-10-19 2007-04-19 Muthaiah Venkatachalam Efficient mechanisms for supporting VoIp in a wireless network
JP4690857B2 (ja) * 2005-10-28 2011-06-01 マスプロ電工株式会社 バルク伝送システム
JP4779955B2 (ja) * 2006-01-06 2011-09-28 富士通株式会社 パケット処理装置及びパケット処理方法
US7835346B2 (en) * 2006-01-17 2010-11-16 Genband Us Llc Methods, systems, and computer program products for providing transcoder free operation (TrFO) and interworking between unlicensed mobile access (UMA) and universal mobile telecommunications system (UMTS) call legs using a media gateway
KR20070082992A (ko) * 2006-02-20 2007-08-23 엘지이노텍 주식회사 쌍방향 통신용 셋톱 박스
US7552363B2 (en) * 2006-03-23 2009-06-23 Arm Limited Generation of trace elements within a data processing apparatus
US9100407B2 (en) * 2006-03-23 2015-08-04 Cisco Technology, Inc. Method and system to enhance performance of a session initiation protocol network and its elements
FR2902268A1 (fr) * 2006-06-08 2007-12-14 France Telecom Systeme d'acces a un service de television sur ip dans un reseau a architecture ims
KR101266021B1 (ko) * 2006-10-13 2013-05-21 삼성전자주식회사 데이터 통신 시스템에서 이동통신 단말기를 제어하는 장치및 방법
US20080101366A1 (en) * 2006-10-31 2008-05-01 Motorola, Inc. Methods for optimized tunnel headers in a mobile network
US20080117906A1 (en) * 2006-11-20 2008-05-22 Motorola, Inc. Payload header compression in an rtp session
US7912050B2 (en) * 2006-12-05 2011-03-22 Electronics And Telecommunications Research Institute Method for classifying downstream packet in cable modem termination system at head-end supporting channel bonding mode, and cable modem termination system
CN101558626A (zh) * 2006-12-12 2009-10-14 维斯塔斯风力系统有限公司 多协议风力涡轮机系统和方法
EP2108193B1 (de) 2006-12-28 2018-08-15 Genband US LLC Verfahren, systeme und computerprogrammprodukte zur umsetzung des stille-einfügungsdescriptors (sid)
US7460038B2 (en) * 2007-03-12 2008-12-02 Citrix Systems, Inc. Systems and methods of clustered sharing of compression histories
US7865585B2 (en) 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing dynamic ad hoc proxy-cache hierarchies
US7619545B2 (en) * 2007-03-12 2009-11-17 Citrix Systems, Inc. Systems and methods of using application and protocol specific parsing for compression
AU2012203797B2 (en) * 2007-03-12 2015-05-07 Citrix Systems, Inc. Systems and methods for using compression histories to improve network performance
US7532134B2 (en) * 2007-03-12 2009-05-12 Citrix Systems, Inc. Systems and methods for sharing compression histories between multiple devices
US7827237B2 (en) * 2007-03-12 2010-11-02 Citrix Systems, Inc. Systems and methods for identifying long matches of data in a compression history
US8255570B2 (en) * 2007-03-12 2012-08-28 Citrix Systems, Inc. Systems and methods of compression history expiration and synchronization
CN101690079B (zh) * 2007-03-12 2013-11-06 思杰系统有限公司 用于使用压缩历史来改进网络性能的系统和方法
US8379623B2 (en) * 2007-07-10 2013-02-19 Motorola Solutions, Inc. Combining mobile VPN and internet protocol
US8908700B2 (en) 2007-09-07 2014-12-09 Citrix Systems, Inc. Systems and methods for bridging a WAN accelerator with a security gateway
US20090094658A1 (en) * 2007-10-09 2009-04-09 Genesis Microchip Inc. Methods and systems for driving multiple displays
US7961878B2 (en) 2007-10-15 2011-06-14 Adobe Systems Incorporated Imparting cryptographic information in network communications
US8478331B1 (en) 2007-10-23 2013-07-02 Clearwire Ip Holdings Llc Method and system for transmitting streaming media content to wireless subscriber stations
US9003302B1 (en) 2007-12-05 2015-04-07 Sprint Spectrum L.P. Anonymous sidebar method and system
US7773634B1 (en) * 2007-12-06 2010-08-10 Sprint Communications Company L.P. Algorithms for constructing sets of frequently occurring strings
KR100926234B1 (ko) * 2007-12-10 2009-11-09 한국전자통신연구원 케이블모뎀의 수신채널집합 설정 및 변경 방법
ES2390988T3 (es) * 2008-01-11 2012-11-20 Telefonaktiebolaget L M Ericsson (Publ) Gestión de mensajes en un subsistema multimedia IP
US20090219932A1 (en) * 2008-02-04 2009-09-03 Stmicroelectronics, Inc. Multi-stream data transport and methods of use
US8126048B2 (en) * 2008-03-18 2012-02-28 Seiko Epson Corporation Recording streaming delta-encoded data
US20090262667A1 (en) * 2008-04-21 2009-10-22 Stmicroelectronics, Inc. System and method for enabling topology mapping and communication between devices in a network
US20100069143A1 (en) * 2008-09-15 2010-03-18 Aristocrat Technologies Australia Pty Limited Gaming controller, device and method of gaming
JP5075784B2 (ja) * 2008-10-01 2012-11-21 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム及び送信側ノード
US8051287B2 (en) 2008-10-15 2011-11-01 Adobe Systems Incorporated Imparting real-time priority-based network communications in an encrypted communication session
KR20100050072A (ko) * 2008-11-05 2010-05-13 삼성전자주식회사 데이터 압축 방법 및 이를 이용한 데이터 통신 시스템
US7835399B2 (en) * 2009-01-06 2010-11-16 Alcatel Lucent IP header compression context identifier synergism
US20100183004A1 (en) * 2009-01-16 2010-07-22 Stmicroelectronics, Inc. System and method for dual mode communication between devices in a network
US8234233B2 (en) * 2009-04-13 2012-07-31 Palo Alto Research Center Incorporated System and method for combining breadth-first and depth-first search strategies with applications to graph-search problems with large encoding sizes
US8860888B2 (en) * 2009-05-13 2014-10-14 Stmicroelectronics, Inc. Method and apparatus for power saving during video blanking periods
US8156238B2 (en) * 2009-05-13 2012-04-10 Stmicroelectronics, Inc. Wireless multimedia transport method and apparatus
US8429440B2 (en) * 2009-05-13 2013-04-23 Stmicroelectronics, Inc. Flat panel display driver method and system
US8760461B2 (en) * 2009-05-13 2014-06-24 Stmicroelectronics, Inc. Device, system, and method for wide gamut color space support
US8291207B2 (en) * 2009-05-18 2012-10-16 Stmicroelectronics, Inc. Frequency and symbol locking using signal generated clock frequency and symbol identification
US8370554B2 (en) * 2009-05-18 2013-02-05 Stmicroelectronics, Inc. Operation of video source and sink with hot plug detection not asserted
US8582452B2 (en) 2009-05-18 2013-11-12 Stmicroelectronics, Inc. Data link configuration by a receiver in the absence of link training data
US8468285B2 (en) * 2009-05-18 2013-06-18 Stmicroelectronics, Inc. Operation of video source and sink with toggled hot plug detection
US20110007754A1 (en) * 2009-07-10 2011-01-13 Gerald Pepper Flexible Hardware Checksum Generator
US8908541B2 (en) 2009-08-04 2014-12-09 Genband Us Llc Methods, systems, and computer readable media for intelligent optimization of digital signal processor (DSP) resource utilization in a media gateway
US8671234B2 (en) 2010-05-27 2014-03-11 Stmicroelectronics, Inc. Level shifting cable adaptor and chip system for use with dual-mode multi-media device
TWI442259B (zh) * 2010-11-05 2014-06-21 Acer Inc 權限控制系統及方法，及其電腦程式產品
JP2011125039A (ja) * 2011-01-06 2011-06-23 Thomson Licensing ケーブル・データ・サービスにおける圧縮
US8644383B2 (en) * 2011-03-10 2014-02-04 Microsoft Corporation Mean absolute difference prediction for video encoding rate control
US9125087B2 (en) * 2011-10-22 2015-09-01 Qualcomm Incorporated Systems and methods for header compression
US20130155918A1 (en) * 2011-12-20 2013-06-20 Nokia Siemens Networks Oy Techniques To Enhance Header Compression Efficiency And Enhance Mobile Node Security
US9049491B2 (en) * 2012-08-30 2015-06-02 Maxlinear, Inc. Method and system for power management in a frequency division multiplexed network
CN103873443B (zh) * 2012-12-13 2018-04-27 联想(北京)有限公司 信息处理方法、本地代理服务器和网络代理服务器
TWI496440B (zh) * 2013-01-09 2015-08-11 Compal Broadband Networks Inc 纜線數據機及網路電話通訊協定選擇方法
WO2014155617A1 (ja) * 2013-03-28 2014-10-02 株式会社東芝 通信装置、通信方法、及び通信プログラム
KR20160018791A (ko) * 2013-08-13 2016-02-17 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법
KR20150050133A (ko) * 2013-10-31 2015-05-08 삼성전자주식회사 통신 시스템에서 패킷 송수신 방법 및 장치
ES2890653T3 (es) 2013-11-27 2022-01-21 Ericsson Telefon Ab L M Formato de carga útil RTP híbrido
US9825884B2 (en) 2013-12-30 2017-11-21 Cavium, Inc. Protocol independent programmable switch (PIPS) software defined data center networks
SE539660C2 (sv) * 2014-03-20 2017-10-24 Scania Cv Ab Förfarande för att starta en förbränningsmotor i en hybriddrivlina, fordon med en sådan hybriddrivlina, datorprogram föratt starta en förbränningsmotor, samt en datorprogramproduk t innefattande programkod
US10050833B2 (en) 2014-06-19 2018-08-14 Cavium, Inc. Method of reducing latency in a flexible parser and an apparatus thereof
US9531848B2 (en) * 2014-06-19 2016-12-27 Cavium, Inc. Method of using generic modification instructions to enable flexible modifications of packets and an apparatus thereof
US9742694B2 (en) 2014-06-19 2017-08-22 Cavium, Inc. Method of dynamically renumbering ports and an apparatus thereof
US9628385B2 (en) 2014-06-19 2017-04-18 Cavium, Inc. Method of identifying internal destinations of networks packets and an apparatus thereof
US9961167B2 (en) 2014-06-19 2018-05-01 Cavium, Inc. Method of modifying packets to a generic format for enabling programmable modifications and an apparatus thereof
US10616380B2 (en) 2014-06-19 2020-04-07 Cavium, Llc Method of handling large protocol layers for configurable extraction of layer information and an apparatus thereof
US9635146B2 (en) 2014-06-19 2017-04-25 Cavium, Inc. Method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof
EP3016432B1 (de) * 2014-10-30 2018-07-04 Vodafone IP Licensing limited Inhaltskompression in einem mobilen Netzwerk
US9606781B2 (en) 2014-11-14 2017-03-28 Cavium, Inc. Parser engine programming tool for programmable network devices
CN105992242B (zh) * 2015-03-06 2019-07-26 电信科学技术研究院 一种空口协议栈的配置方法、数据传输方法及设备
WO2016195547A1 (en) 2015-05-29 2016-12-08 Telefonaktiebolaget Lm Ericsson (Publ) Methods for compression and decompression of headers of internet protocol packets, devices, computer programs and computer program products
US10362150B2 (en) * 2015-09-09 2019-07-23 Sony Corporation Communication device and communication method
KR102515830B1 (ko) * 2015-11-20 2023-03-29 삼성전자주식회사 데이터 송신 장치 및 방법과, 데이터 수신 장치 및 방법
US10306024B2 (en) * 2016-03-25 2019-05-28 Amazon Technologies, Inc. Compression dictionary snapshot system and method
US10264103B2 (en) 2016-03-25 2019-04-16 Amazon Technologies, Inc. Compression dictionary generation service system and method
US10582015B2 (en) 2016-03-25 2020-03-03 Amazon Technologies, Inc. Compression dictionary systems and methods
US11126663B2 (en) * 2017-05-25 2021-09-21 Intel Corporation Method and apparatus for energy efficient decompression using ordered tokens
FR3070566B1 (fr) * 2017-08-30 2020-09-04 Sagemcom Broadband Sas Procede de recuperation d'un fichier cible d'un logiciel d'exploitation et dispositif d'utilisation
US11502723B2 (en) * 2018-02-28 2022-11-15 Maxlinear, Inc. Full-duplex cable modem calibration
JP7024578B2 (ja) * 2018-04-24 2022-02-24 富士通株式会社 通信装置、通信制御方法、および通信制御プログラム
US10862807B2 (en) * 2018-09-19 2020-12-08 Cisco Technology, Inc. Packet telemetry data via first hop node configuration
CN112260982B (zh) * 2019-07-22 2022-03-11 华为技术有限公司 音频处理方法及设备
US11356563B1 (en) * 2020-06-16 2022-06-07 Andre Greene Amplified cable modem
US11805079B2 (en) * 2021-11-17 2023-10-31 Charter Communications Operating, Llc Methods and apparatus for coordinating data transmission in a communications network
WO2024059061A1 (en) * 2022-09-13 2024-03-21 Arris Enterprises Llc Active system for partitioning identifier space

Family Cites Families (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4814746A (en) * 1983-06-01 1989-03-21 International Business Machines Corporation Data compression method
US4862167A (en) * 1987-02-24 1989-08-29 Hayes Microcomputer Products, Inc. Adaptive data compression method and apparatus
US4864572A (en) * 1987-05-26 1989-09-05 Rechen James B Framing bitstreams
CA2065578C (en) 1991-04-22 1999-02-23 David W. Carr Packet-based data compression method
US5307413A (en) 1991-07-19 1994-04-26 Process Software Corporation Method and apparatus for adding data compression and other services in a computer network
US5537551A (en) * 1992-11-18 1996-07-16 Denenberg; Jeffrey N. Data compression method for use in a computerized informational and transactional network
CA2125337A1 (en) 1993-06-30 1994-12-31 Marlin Jay Eller Method and system for searching compressed data
US5530645A (en) 1993-06-30 1996-06-25 Apple Computer, Inc. Composite dictionary compression system
WO1995029437A1 (fr) * 1994-04-22 1995-11-02 Sony Corporation Dispositif et methode pour transmettre des donnees et dispositif et methode pour enregistrer des donnees
US6195391B1 (en) 1994-05-31 2001-02-27 International Business Machines Corporation Hybrid video compression/decompression system
EP0687995B1 (de) * 1994-06-16 2004-03-17 Seiko Epson Corporation Verfahren zur Datenkompression
EP0718980A1 (de) * 1994-12-20 1996-06-26 International Business Machines Corporation Verfahren zur Kompression von Daten für individuelle Folgen eines Datenstroms mit Hilfe eines Wörterbuches und Vorrichtung dafür
US6055268A (en) 1996-05-09 2000-04-25 Texas Instruments Incorporated Multimode digital modem
FI962381A (fi) 1996-06-07 1997-12-08 Nokia Telecommunications Oy Datan pakkaaminen tietoliikenneyhteydellä
US5831558A (en) * 1996-06-17 1998-11-03 Digital Equipment Corporation Method of compressing and decompressing data in a computer system by encoding data using a data dictionary
JPH1074159A (ja) 1996-08-30 1998-03-17 Hitachi Ltd 計算機システムの制御方法
JPH10154044A (ja) * 1996-11-22 1998-06-09 Advantest Corp 転送データ圧縮展開方式及び転送データ圧縮展開装置
US5987022A (en) * 1996-12-27 1999-11-16 Motorola, Inc. Method for transmitting multiple-protocol packetized data
US5889385A (en) * 1997-08-19 1999-03-30 Advanced Charger Technology, Inc. Equalization of series-connected cells of a battery using controlled charging and discharging pulses
US6067381A (en) * 1997-06-13 2000-05-23 International Business Machines Corporation Method of reinitializing dictionaries in a data transmission system using data compression
US6032197A (en) 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
JP3337633B2 (ja) 1997-12-03 2002-10-21 富士通株式会社 データ圧縮方法及びデータ復元方法並びにデータ圧縮プログラム又はデータ復元プログラムを記録したコンピュータ読み取り可能な記録媒体
US5945933A (en) * 1998-01-27 1999-08-31 Infit Ltd. Adaptive packet compression apparatus and method
CA2260289A1 (en) 1998-01-29 1999-07-29 Steven Michael Bellovin A method of improving data compression over unreliable underlying networks
US6222916B1 (en) * 1998-05-22 2001-04-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for introducing and modifying telecommunications services
US20010004768A1 (en) * 1998-09-28 2001-06-21 Hodge Winston W. Hodge Winston W. Highly integrated computer controlled digital head end
US6438123B1 (en) * 1998-11-10 2002-08-20 Cisco Technology, Inc. Method and apparatus for supporting header suppression and multiple microflows in a network
US6624761B2 (en) * 1998-12-11 2003-09-23 Realtime Data, Llc Content independent data compression method and system
US6986157B1 (en) * 1998-12-21 2006-01-10 3Com Corporation Method and system for dynamic service registration in a data-over-cable system
NO991371L (no) * 1999-03-22 2000-09-25 Fileflow As FremgangsmÕte ved overføring av filer i et datakommunikasjonsnett
US6295481B1 (en) 1999-03-24 2001-09-25 Ecp Family Properties Serial bus control system for sewing equipment
US6198735B1 (en) 1999-05-20 2001-03-06 Motorola, Inc. Method for retransmitting a data packet in a packet network
US6542504B1 (en) * 1999-05-28 2003-04-01 3Com Corporation Profile based method for packet header compression in a point to point link
US6597812B1 (en) * 1999-05-28 2003-07-22 Realtime Data, Llc System and method for lossless data compression and decompression
US6680955B1 (en) * 1999-08-20 2004-01-20 Nokia Networks Oy Technique for compressing a header field in a data packet
US6788707B1 (en) * 1999-08-31 2004-09-07 Broadcom Corporation Method for the suppression and expansion of packet header information in cable modem and cable modem termination system devices
US6909715B1 (en) 1999-08-31 2005-06-21 Broadcom Corporation Method and apparatus for the reduction of upstream request processing latency in a cable modem termination system
US6882637B1 (en) 1999-10-14 2005-04-19 Nokia Networks Oy Method and system for transmitting and receiving packets
US6542931B1 (en) 1999-11-05 2003-04-01 Nokia Corporation Using sparse feedback to increase bandwidth efficiency in high delay, low bandwidth environment
US6535925B1 (en) * 1999-11-09 2003-03-18 Telefonaktiebolaget L M Ericsson (Publ) Packet header compression using division remainders
US6300887B1 (en) 1999-11-09 2001-10-09 Nokia Networks Oy Efficient handoff procedure for header compression
EP1161805B1 (de) * 1999-11-30 2005-11-09 Telogy Networks Inc. Synchronisierung der sprachpaketerzeugung auf unverlangte zuteilungen in einem docsis kabelmodem-netzwerk mit sprachtelephonie mittels paketen
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US6857132B1 (en) 2000-01-14 2005-02-15 Terayon Communication Systems, Inc. Head end multiplexer to select and transmit video-on-demand and other requested programs and services
US6940899B2 (en) * 2000-03-29 2005-09-06 Hughes Electronics Corporation System employing data compression transparent mode with compression parameter negotiation
US6643815B1 (en) * 2000-03-30 2003-11-04 International Business Machines Corporation Data compression over communications links which are exposed to occasional errors
US6807193B1 (en) * 2000-06-20 2004-10-19 3Com Corporation Cable modem with dribble grant access system and method
US6856651B2 (en) * 2000-07-25 2005-02-15 Peribit Networks, Inc. System and method for incremental and continuous data compression
US7254190B2 (en) * 2000-09-01 2007-08-07 Broadcom Corporation Satellite receiver
US6742187B1 (en) * 2000-09-15 2004-05-25 3Com Corporation Upstream bandwidth allocation map (MAP)-initiated channel change method for data-over-cable systems
US6765925B1 (en) * 2000-09-28 2004-07-20 Nortel Networks Limited Apparatus and method of maintaining state in a data transmission system
US7451235B2 (en) 2000-10-11 2008-11-11 Broadcom Corporation Dynamic delta encoding for cable modem header suppression
US7310353B1 (en) * 2000-10-30 2007-12-18 Yair Bourlas Compression of overhead in layered data communication links
US6963587B2 (en) * 2000-11-16 2005-11-08 Telefonaktiebolaget Lm Ericsson (Publ) Communication system and method utilizing request-reply communication patterns for data compression
US7082569B2 (en) * 2001-01-17 2006-07-25 Outlooksoft Corporation Systems and methods providing dynamic spreadsheet functionality
US20020191691A1 (en) * 2001-05-10 2002-12-19 Holborow Clive Eric Payload header suppression including removal of fields that vary in known patterns
US7688824B2 (en) * 2001-07-11 2010-03-30 Broadcom Corporation Method, system, and computer program product for suppression index reuse and packet classification for payload header suppression
KR100441589B1 (ko) 2002-04-01 2004-07-23 삼성전자주식회사 Ｒｔｐ패킷 생성/복원 장치 및 방법
US7382749B2 (en) * 2002-11-26 2008-06-03 Sony Corporation Systems, methods, and apparatus with a common wireless communications protocol
US20050030944A1 (en) 2003-05-27 2005-02-10 General Instrument Corporation Method and apparatus for reducing packet size employing payload header suppression (PHS)
US7675895B2 (en) * 2004-09-14 2010-03-09 Alcatel-Lucent Usa Inc. Method and apparatus for wireless communication using voice over internet protocol
US9031071B2 (en) * 2005-08-26 2015-05-12 Alcatel Lucent Header elimination for real time internet applications
US7733867B2 (en) * 2005-08-26 2010-06-08 Alcatel-Lucent Usa Inc. Header compression for real time internet applications
FR2903836B1 (fr) 2006-07-13 2008-09-12 Thales Sa Systeme permettant de mettre en relation des usagers voip et des ressources analogiques reparties
EP2036981A1 (de) 2007-09-12 2009-03-18 Bayer Schering Pharma Aktiengesellschaft Mit 18F markierte Aptamere

Also Published As

Publication number Publication date
EP1348289B1 (de) 2006-04-05
US20110058540A1 (en) 2011-03-10
DE60120466D1 (de) 2006-07-20
EP1338128A2 (de) 2003-08-27
EP1348290B1 (de) 2007-09-05
US6963931B2 (en) 2005-11-08
US20020049861A1 (en) 2002-04-25
US7130314B2 (en) 2006-10-31
WO2002032101A3 (en) 2002-06-20
WO2002032073A2 (en) 2002-04-18
US20020080868A1 (en) 2002-06-27
US7389527B2 (en) 2008-06-17
US20020073227A1 (en) 2002-06-13
DE60130367D1 (de) 2007-10-18
WO2002032034A2 (en) 2002-04-18
WO2002032081A1 (en) 2002-04-18
EP1340351B1 (de) 2007-12-12
US20070058640A1 (en) 2007-03-15
WO2002032080A1 (en) 2002-04-18
EP1348290A2 (de) 2003-10-01
US7428247B2 (en) 2008-09-23
EP1340351A1 (de) 2003-09-03
WO2002032034A3 (en) 2002-07-04
EP1348289A2 (de) 2003-10-01
DE60118609D1 (de) 2006-05-18
US20080010300A1 (en) 2008-01-10
WO2002032034A9 (en) 2003-09-04
US7275115B2 (en) 2007-09-25
US20020106029A1 (en) 2002-08-08
DE60120466T2 (de) 2007-01-18
DE60118609T2 (de) 2007-05-03
DE60131890D1 (de) 2008-01-24
US7451235B2 (en) 2008-11-11
EP1338128B1 (de) 2006-06-07
US7693186B2 (en) 2010-04-06
US20020062394A1 (en) 2002-05-23
DE60130367T2 (de) 2008-06-12
US8767776B2 (en) 2014-07-01
US20080304490A1 (en) 2008-12-11
WO2002032101A2 (en) 2002-04-18
WO2002032073A3 (en) 2002-06-13

Similar Documents

Publication Publication Date Title
DE60131890T2 (de) Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung
DE69736713T2 (de) Anordnung und verfahren zur übertragung von ip-daten über ein satellitennetz
DE60316094T2 (de) Verfahren, Vorrichtung und System für die Komprimierung von verlängerten Kopffeldern
DE60113906T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE60304045T2 (de) Verfahren, computerlesbares medium und vorrichtungen zur wiederherstellung von datenverkehr bei ausfallsicherung in einer kopfstation eines breitbandkabelnetzes
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE60132071T2 (de) Kabelmodemsystem und verfahren zur übertragung von speziellen daten
DE69924732T2 (de) Quellknoten fuer ein breitbandnetzwerk mit atm zellen
DE60307406T2 (de) Packetübertragungssystem und Packetempfangssystem
DE60214144T2 (de) Verfahren und Vorrichtung zur bereitstellung von unterschiedlichen Dienstqualitätsstufen in einer Funkpaketdatendienstverbindung
DE60128409T2 (de) Verfahren und Vorrichtung zur Entkomprimierung von Paket-Kopfdaten
DE60017442T2 (de) Spärliche rückkoppelung in drahtlosen systemen die hohe verzögerung und niedrige bandbreite aufweisen
DE60208466T2 (de) Verfahren und Vorrichtung zur Fehlerkorrektur der statischen Informationen im Kopffeld eines empfangenen Packets
DE112006002644T5 (de) Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse
DE60116998T2 (de) In zugangstechnologie integrierte header-komprimierung
US7849489B2 (en) System and method for supporting extended protocols in a wireless communication system
DE10160844B4 (de) System zur Übertragung eines Datenstroms über ein Netzwerk an unterschiedliche Netzwerkprotokolle unterstützende Empfänger
DE10219316A1 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem Kommunikationssystem

Legal Events

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

Representative=s name: BOSCH JEHLE PATENTANWALTSGESELLSCHAFT MBH, 80639 M