DE60120466T2 - Effiziente Übertragung von RTP Paketen in einem Netzwerk - Google Patents

Effiziente Übertragung von RTP Paketen in einem Netzwerk Download PDF

Info

Publication number
DE60120466T2
DE60120466T2 DE60120466T DE60120466T DE60120466T2 DE 60120466 T2 DE60120466 T2 DE 60120466T2 DE 60120466 T DE60120466 T DE 60120466T DE 60120466 T DE60120466 T DE 60120466T DE 60120466 T2 DE60120466 T2 DE 60120466T2
Authority
DE
Germany
Prior art keywords
rtp
header
value
packet
field
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
DE60120466T
Other languages
English (en)
Other versions
DE60120466D1 (de
Inventor
A. Fred Roswell BUNN
L. Thomas Gainesville JOHNSON
Joel Alpharetta DANZIG
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
Publication of DE60120466D1 publication Critical patent/DE60120466D1/de
Application granted granted Critical
Publication of DE60120466T2 publication Critical patent/DE60120466T2/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. Spezifischer betrifft die vorliegende Erfindung ein Kabelmodemsystem sowie ein Verfahren und ein Computerprogrammprodukt zum Bereitstellen einer Echtzeit-Protokoll-Header-Unterdrückung quer durch ein DOCSIS-Netzwerk.
  • Stand der Technik
  • Herkömmliche Kabelmodemsysteme nutzen mit DOCSIS (Data Over Cable System Interface Specification – Daten-über-Kabel-Systemschnittstellenspezifikation) kompatible Geräte und Protokolle, um Daten zwischen einem oder mehreren Kabelmodems (KM) zu übertragen. DOCSIS betrifft allgemein eine Gruppe von Spezifikationen, die Industriestandards für Kabel-Kopfstellen- und Kabelmodemgeräte definieren. Zum Teil legt DOCSIS die Anforderungen und Ziele für verschiedene Aspekte von Kabelmodemsystemen dar, einschließlich Betriebsunterstützungssysteme (Operations Support Systems), Management, Datenschnittstellen sowie Vermittlungsschicht-, Sicherungsschicht- und Bitübertragungsschichttransport für Kabelmodemsysteme.
  • Das Real-time Transport Protocol (RTP – Echtzeittransportprotokoll) ist ein Protokoll zur Abgabe von paketiertem Audio- und Video-Verkehr über ein Internet-Protokollnetz. RTP stellt Ende-zu-Ende-Netztransportfunktionen für Anwendungen mit Echtzeitanforderungen bereit. Solche Anwendungen können Audio-, Video- oder Simulationsdaten über Multicast- oder Unicast-Netzdienste umfassen. RTP wird außerdem dazu verwendet, VOIP- (Voice over IP) Telefonanrufe zu senden.
  • Eine steigende Anzahl an Anwendungen nutzt RTP, um Sprach- und Multimediadatenströme zu liefern. Der Datenabschnitt eines RTP-Pakets ist im Vergleich zu dem zum Senden der Informationen erforderlichen Protokoll-Overhead häufig klein. Aktuelle Techniken zum Liefern von RTP-Paketen verschwenden Netzwerkbandbreite, indem sie redundante Informationen senden. Darüber hinaus sehen aktuelle Techniken keine ausreichende Unterdrückung oder Komprimierung von sich verändernden RTP-Feldern in einem Datenstrom vor.
  • CASNER, S. ET AL: "Compressing IP/UDP/RTP-Headers for Low-Speed Serial Links", NETWORK WORKING GROUP, Februar 1999 (1999-02), XP002121319, betrifft die TCP-Header-Komprimierung.
  • CABLE TELEVISION LABORATORIES: "RADIO FREQUENCY INTERFACE SPECIFICATION SP-RFIV1.1-I05-000714", DATA-OVER CABLE SERVICE INTERFFACE SPECIFICATIONS, [Online] 14. Juli 2000 (14.7.2000), Seiten I-XVIII, 93-100, 143-178 XP002193659, dem Internet zu entnehmen unter:
    <URL:http://www.docsis.org/docs/SP-RFIv1.1-I05-000714.pdf> [entnommen am 20.03.2002] ist eine Spezifikation für den DOCSIS1.1-Standard und erläutert unter anderem die Grundlagen der Nutzlast-Header-Unterdrückung.
  • DOCSIS 1.1 sieht eine Technik zur Unterdrückung redundanter Informationen vor, die "Nutzlast-Header-Unterdrückung" (PHS – Payload Header Suppression) genannt wird. PHS ermöglicht die Unterdrückung von unveränderlichen Bytes in einer einzelnen Dienstekennung (SID – Service Identifier) (d.h. Datenstrom). Somit sieht DOCSIS-PHS eine byteorientierte Unterdrückung vor. Eine byteorientierte Unterdrückung ist nicht so effizient wie ein feldorientiertes Protokoll-Header-Unterdrückungsschema. Ein weiterer Nachteil von PHS besteht in seiner Unfähigkeit, sich dynamisch verändernde Felder in einem Datenstrom zu unterdrücken.
  • Benötigt werden ein System und ein Verfahren zur Abgabe gesendeter RTP-Pakete in der richtigen Reihenfolge, die die Übertragung redundanter Muster beseitigen. Es werden ebenfalls ein System und ein Verfahren zur Abgabe gesendeter RTP-Pakete in der richtigen Reihenfolge benötigt, die ein feldorientiertes Protokoll-Header-Unterdrückungsschema bereitstellen. Ferner werden ein System und ein Verfahren zur Abgabe gesendeter RTP-Pakete in der richtigen Reihenfolge benötigt, die sich dynamisch verändernde Felder in einem Datenstrom unterdrücken.
  • Die vorliegende Erfindung erfüllt die vorstehenden Anforderungen durch Bereitstellen eines Verfahrens und eines Computerprogrammprodukts zur RTP-Header-Unterdrückung, wie in den unabhängigen Ansprüchen angegeben. Vorteilhafte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen definiert.
  • In der folgenden Beschreibung sind die Worte "Erfindung" und "Ausführungsform" so zu verstehen, dass sie zur nur Erläuterung des technischen Hintergrunds und nicht zur Beschreibung des Schutzumfangs dienen.
  • Die vorliegende Erfindung beseitigt die Notwendigkeit, redundante Muster quer durch ein Netzwerk zu senden und gleichzeitig sich verändernde RTP-Felder in einem Datenstrom zu unterdrücken. Die Erfindung erhöht die Bandbreitenkapazität von Hochgeschwindigkeits-DOCSIS-Kabelmodemnetzen durch Verwenden von Feldebeneübertragungsverfahren (field level encoding) anstelle einer einfachen Byte-Substitution. Weitere Ausführungsformen, Merkmale und Vorteile der vorliegenden Erfindung sowie der Aufbau und Betrieb der verschiedenen Ausführungsformen der vorliegenden Erfindung sind nachfolgend unter Bezugnahme auf die begleitenden Zeichnungen genauer beschrieben.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN/FIGUREN
  • Die begleitenden Zeichnungen, die hierin enthalten sind und einen Teil der Beschreibung bilden, stellen die vorliegende Erfindung dar und dienen, zusammen mit der Beschreibung, ferner dazu, die Grundlagen der Erfindung zu erläutern und es einem Fachmann auf dem entsprechenden Gebiet zu ermöglichen, die Erfindung herzustellen und anzuwenden.
  • 1 ist ein Blockdiagramm höherer Ebene eines Kabelmodemsystems gemäß den Ausführungsformen der vorliegenden Erfindung.
  • 2 ist ein schematisches Blockdiagramm eines Kabelmodemanschlusssystems (CMTS) gemäß den Ausführungsformen der vorliegenden Erfindung.
  • 3 ist ein schematisches Blockdiagramm eines Kabelmodems gemäß den Ausführungsformen der vorliegenden Erfindung.
  • 4 ist ein Flussdiagramm eines Verfahrens zur Unterstützung erweiterter Protokolle in einem Kabelmodemsystem gemäß den Ausführungsformen der vorliegenden Erfindung.
  • 5 ist ein Flussdiagramm eines Verfahrens zur Unterstützung erweiterter Protokolle in einem Kabelmodemsystem gemäß den Ausführungsformen der vorliegenden Erfindung.
  • 6A ist ein Blockdiagramm eines unkomprimierten Pakets, das typischerweise von einem Kabelmodem gemäß den Ausführungsformen der vorliegenden Erfindung empfangen wird.
  • 6B ist ein Blockdiagramm eines Pakets, das durch ein Kabelmodem gemäß den Ausführungsformen der vorliegenden Erfindung komprimiert worden ist.
  • 6C ist ein Blockdiagramm einer einzelnen SID, die mehrere Pakete enthält, die durch ein Kabelmodem unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken gemäß den Ausführungsformen der vorliegenden Erfindung komprimiert worden sind.
  • 7 ist ein Flussdiagramm eines Verfahrens zum Komprimieren von Paketen unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken gemäß den Ausführungsformen der vorliegenden Erfindung.
  • 8 ist ein Flussdiagramm eines Verfahrens zum Dekomprimieren von Paketen, die unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken gemäß den Ausführungsformen der vorliegenden Erfindung komprimiert worden sind.
  • 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 zeigt, das während des Betriebs einer RTP-Header-Unterdrückungstechnik verwendet wird.
  • 11 ist ein Flussdiagramm höherer Ebene, das ein Verfahren zur RTP-Header-Unterdrückung darstellt.
  • 12A ist ein Flussdiagramm, das ein Verfahren zum Unterdrücken eines RTP-Headers unter Verwendung einer RTP-Header-Unterdrückungstechnik gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 12B ist ein Flussdiagramm, das ein Verfahren zur Einstellung des Inkrements eines IP-Paket-ID-Feldes in einem RTP-Header gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 13 ist ein Flussdiagramm, das ein Verfahren zum Rekonstruieren eines RTP-Headers unter Verwendung einer RTP-Header-Unterdrückungstechnik gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 14 ist ein Diagramm, das einen beispielhaften 802.3-/IP-/TCP-Header zeigt.
  • 14B ist ein Diagramm, das ein TCP-Protokollpaket zeigt.
  • 15 ist ein Diagramm, das ein TCP-Protokollpaket zeigt, wobei die Felder hervorgehoben sind, die sich von Paket zu Paket verändern können.
  • 16A ist ein Diagramm höherer Ebene, das ein Verfahren für eine deltacodierte Header-Unterdrückungstechnik gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 16B ist ein Diagramm höherer Ebene, das ein Verfahren für eine deltacodierte Header-Rekonstruktionstechnik gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 17 ist ein Diagramm, das ein Änderungsbyte gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 18 ist ein Diagramm, das einen endgültigen codierten Datenstrom gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 19 ist ein Diagramm, das den Sendebefehl von Daten zur TCP-Header-Unterdrückung bei einem Nicht-Lern-Zustand gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 20 ist ein Diagramm, das den Sendebefehl von Daten zur TCP-Header-Unterdrückung bei einem Lern-Zustand gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 21 ist ein Flussdiagramm, das ein Verfahren zur TCP-Header-Unterdrückung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 22 ist ein Flussdiagramm, das ein Verfahren zur TCP-Header-Rekonstruktion gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 23 ist ein Diagramm, das ein beispielhaftes Computersystem zeigt.
  • Die Merkmale, Ziele und Vorteile der vorliegenden Erfindung gehen aus der nachfolgenden detaillierten Beschreibung in Verbindung mit den Zeichnungen genauer hervor, in denen gleiche Bezugszeichen immer entsprechende Elemente bezeichnen. In den Zeichnungen geben gleiche Bezugszeichen im Allgemeinen identische, funktionell ähnliche und/oder strukturell ähnliche Elemente an. Die Zeichnung, in der ein Element zuerst erscheint, wird durch die Ziffer(n) links außen in dem entsprechenden Bezugszeichen angegeben.
  • GENAUE BESCHREIBUNG DER ERFINDUNG
  • Obgleich die vorliegende Erfindung hierin unter Bezugnahme auf veranschaulichende Ausführungsformen für spezifische Anwendungen beschrieben ist, versteht es sich, dass die Erfindung nicht darauf beschränkt ist. Fachleute auf dem Gebiet, die Zugang zu den hierin angegebenen Lehren haben, werden weitere, im Schutzumfang derselben enthaltene Modifikationen, Anwendungen und Ausführungsformen sowie weitere Gebiete erkennen, in denen die vorliegende Erfindung von erheblichem Nutzen sein kann.
  • A. Kabelmodemsystem gemäß den Ausführungsformen der vorliegenden Erfindung
  • 1 ist ein Blockdiagramm höherer Ebene eines beispielhaften Kabelmodemsystems 100 gemäß den Ausführungsformen der vorliegenden Erfindung. Das Kabelmodemsystem 100 ermöglicht Sprachübertragungen, Video- und Datendienste, die auf einer bidirektionalen Übertragung von paketbasiertem Verkehr, wie etwa Internet-Protokoll- (IP-) Verkehr, zwischen einer Kabelsystem-Kopfstelle 102 und mehreren Kabelmodems über ein hybrides Lichtwellenleiter-Koaxialkabelnetz (HFC-Netz/hybrid fiber-coaxial cable network) 110 basieren. Bei dem beispielhaften Kabelmodemsystem 100 sind aus Gründen der Klarheit nur zwei Kabelmodems 106 und 108 dargestellt. Im Allgemeinen kann das erfindungsgemäße Kabelmodemsystem eine beliebige Anzahl an Kabelmodems umfassen.
  • Die Kabel-Kopfstelle (Cable Headend) 102 umfasst wenigstens ein Kabelmodemanschlusssystem (CMTS – Cable Modem Termination System) 104. Das CMTS 104 ist der Abschnitt der Kabel-Kopfstelle 102, die den Upstream- und Downstream-Transfer von Daten zwischen der Kabel-Kopfstelle 102 und den Kabelmodems 106 und 108 steuert, die sich in den Räumlichkeiten der Kunden befinden. Das CMTS 104 sendet Informationen als kontinuierlich gesendetes Signal in Downstream-Richtung an die Kabelmodems 106 und 108 in Übereinstimmung mit einer Zeitmultiplex- (TDM-/Time Division Multiplexing) Technik. Darüber hinaus steuert das CMTS 104 die Upstream-Datenübertragung von den Kabelmodems 106 und 108 an sich selbst, indem jedem Kabelmodem 106 und 108 eine kurze Bewilligungszeitspanne zugewiesen wird, in der die Daten zu übertragen sind. In Übereinstimmung mit dieser Zeitdomäne-Mehrfachzugriff- (TDMA-/Time Domain Multiple Access) Technik kann jedes Kabelmodem 106 und 108 Informationen nur in Upstream-Richtung als kurze Burst-Signale während einer Übertragungsgelegenheit senden, die die ihm durch das CMTS 104 zugewiesen wird.
  • Wie in 1 gezeigt, dient das CMTS 102 ferner als Schnittstelle zwischen dem HFC-Netz 110 und einem paketvermittelten Netz 112, die von den Kabelmodems 106 und 108 empfangene IP-Pakete an das paketvermittelte Netz 112 und von dem paketvermittelten Netz 112 empfangene IP-Pakete an die Kabelmodems 106 und 108 überträgt, wenn dies angemessen ist. In den Ausführungsformen umfasst das paketvermittelte Netz 112 das Internet.
  • Zusätzlich zum CMTS 104 kann die Kabel-Kopfstelle 102 auch einen oder mehrere Internet-Router, um die Verbindung zwischen dem CMTS 104 und dem paketvermittelten Netz 112 zu fördern, sowie einen oder mehrere Server umfassen, um die erforderlichen Netzwerk-Management-Aufgaben auszuführen.
  • Das HFC-Netz 110 sieht eine Punkt-zu-Multipunkt-Topologie für einen zuverlässigen und sicheren Hochgeschwindigkeitsdatentransport zwischen der Kabel-Kopfstelle 102 und den Kabelmodems 106 und 108 in den Räumlichkeiten der Kunden vor. Wie Fachleute auf dem oder den relevanten Gebieten erkennen werden, kann das HFC-Netz 110 Koaxialkabel, Glasfaserkabel oder eine Kombination aus Koaxialkabeln und Glasfaserkabeln, die über einen oder mehrere Faserknoten miteinander verbunden sind, umfassen.
  • Jedes der Kabelmodems 106 und 108 arbeitet als Schnittstelle zwischen dem HFC-Netz 110 und wenigstens einem angeschlossenen Benutzergerät. Die Kabelmodems 106 und 108 führen insbesondere die Funktionen aus, die zum Umwandeln von über das HFC-Netz 110 empfangenen Downstream-Signalen in IP-Datenpakete zum Empfang durch ein angeschlossenes Benutzergerät nötig sind. Darüber hinaus führen die Kabelmodems 106 und 108 die Funktionen aus, die zum Umwandeln von vom angeschlossenen Benutzergerät empfangenen IP-Datenpaketen in Upstream-Burst-Signale nötig sind, die sich zur Übertragung über das HFC-Netz 110 eignen. Bei dem beispielhaften Kabelmodemsystem 100 ist jedes Kabelmodem 106 und 108 aus Gründen der Klarheit so dargestellt, dass es nur ein einzelnes Benutzergerät unterstützt. Im Allgemeinen ist jedes Kabelmodem 106 und 108 dazu in der Lage, mehrere Benutzergeräte zur Kommunikation über das Kabelmodemsystem 100 zu unterstützen. Benutzergeräte können Personal-Computer, Datenendgeräte, Fernsprechgeräte, Breitbandmedienabspielgeräte, netzwerkgesteuerte Haushaltsgeräte (Appliances) oder jede andere Einrichtung umfassen, die dazu imstande ist, Daten über ein paketvermitteltes Netz zu senden oder zu empfangen.
  • Bei dem beispielhaften Kabelmodemsystem 100 stellt das Kabelmodem 106 ein herkömmliches DOCSIS-kompatibles Kabelmodem dar. Mit anderen Worten, das Kabelmodem 106 sendet Datenpakete in Formaten an das CMTS 104, die in der DOCSIS-Spezifikation ausgeführten Protokollen entsprechen. Das Kabelmodem 108 ist desgleichen dazu imstande, Datenpakete in standardgemäßen DOCSIS-Formaten an das CMTS 104 zu senden. Gemäß den Ausführungsformen der vorliegenden Erfindung ist das Kabelmodem 108 jedoch auch dafür konfiguriert, Datenpakete unter Verwendung von firmeneigenen Protokollen, die über die DOCSIS-Spezifikation hinausgehen, an das CMTS 104 zu senden. Dennoch ist das Kabelmodem 108 mit DOCSIS-kompatiblen Kabelmodems, wie etwa dem Kabelmodem 106, sowie mit DOCSIS-kompatiblen CMTS-Geräten vollständig dialogfähig. Die Art und Weise, in der das Kabelmodem 108 arbeitet, um Daten zu übertragen, wird hierin noch genauer beschrieben.
  • Des Weiteren wird das CMTS 104 bei dem beispielhaften Kabelmodemsystem 100 so betrieben, dass es Datenpakete empfängt und verarbeitet, die ihm in Übereinstimmung mit den in der DOCSIS-Spezifikation ausgeführten Protokollen zugesandt worden sind. Gemäß den Ausführungsformen der vorliegenden Erfindung kann das CMTS 104 jedoch auch so betrieben werden, dass es Datenpakete empfängt und verarbeitet, die unter Verwendung firmeneigener Protokolle formatiert wurden, welche über die durch die DOCSIS-Spezifikation vorgesehenen Protokolle hinausgehen, wie etwa durch das Kabelmodem 108 gesendete Datenpakete. Die Art und Weise, in der das CMTS 104 arbeitet, um Daten zu empfangen und zu verarbeiten wird hierin ebenfalls noch genauer beschrieben.
  • B. Beispielhafte Kabelmodemsystemkomponenten gemäß den Ausführungsformen der vorliegenden Erfindung
  • 2 zeigt ein schematisches Blockdiagramm einer Implementierung des CMTS 104 des Kabelmodemsystems 100, das rein beispielhaft angegeben ist und die vorliegende Erfindung nicht einschränken soll. Das CMTS 104 ist dafür konfiguriert, Signale vom HFC-Netz 110 zu empfangen und an dieses zu senden, wobei ein Abschnitt desselben gemäß 2 durch die Glasfaser 202 dargestellt ist. Dementsprechend wird das CMTS 104 vermittels eines Empfängerabschnitts und eines Senderabschnitts beschrieben.
  • Der Empfängerabschnitt umfasst eine Glasfaser-/Koaxialkabelstufe (Optical-to-Coax stage) 204, einen HF-Eingang 206, einen Splitter 214 und mehrere Burst-Empfänger 216. Der Empfang beginnt mit dem Empfangen von Upstream-Burst-Signalen, die von einem oder mehreren Kabelmodems stammen, durch die Glasfaser-/Koaxialkabelstufe 204 über die Glasfaser 202. Die Glasfaser-/Koaxialkabelstufe 204 leitet die empfangenen Burst-Signale über das Koaxialkabel 208 an den Hochfrequenz- (HF-) Eingang 206 weiter. Bei den Ausführungsformen haben diese Upstream-Burst-Signale Spektraleigenschaften innerhalb des Frequenzbereichs von ungefähr 5–42 MHz.
  • Die empfangenen Signale werden durch den HF-Eingang 206 dem Splitter 214 des CMTS 104 zugeführt, der die HF-Eingangssignale in N separate Kanäle aufteilt. Jeder der N separaten Kanäle wird dann einem separaten Burst-Empfänger 216 zugeführt, der so arbeitet, dass die empfangenen Signale auf jedem Kanal in Übereinstimmung mit entweder einer Quadratur-Phasenumtastungs- (QPSK-/Quadrature Phase Shift Key) oder 16-Quadratur-Amplitudenmodulations- (QAM-) Technik demoduliert werden, um die eigentlichen Informationssignale wiederherzustellen. Jeder Burst-Empfänger 216 wandelt außerdem die eigentlichen Informationssignale von einer analogen Form in eine digitale Form um. Diese digitalen Daten werden anschließend der Kopfstellen-Medienzugangssteuerung (MAC – Media Access Control) 218 zugeführt.
  • Die Kopfstellen-MAC 218 arbeitet derart, dass die digitalen Daten in Übereinstimmung mit der DOCSIS-Spezifikation und, sofern angemessen, in Übereinstimmung mit firmeneigenen Protokollen verarbeitet werden, die über die DOCSIS-Spezifikation hinausgehen, wie hierin noch genauer beschrieben. Die Funktionen der Kopfstellen-MAC 218 können in Hardware oder Software implementiert werden. Bei der beispielhaften Ausführung gemäß 2 sind die Funktionen der Kopfstellen-MAC 218 sowohl in Hardware als auch in Software implementiert. Software-Funktionen der Kopfstellen-MAC 218 können entweder im RAM (Random Access Memory – Lese-/Schreibspeicher mit wahlfreiem Zugriff) 220 oder im ROM (Read-Only Memory – Festwertspeicher) 218 gespeichert und durch die CPU (Zentraleinheit) 222 ausgeführt werden. Die Kopfstellen-MAC steht mit diesen Elementen über eine Backplane-Schnittstelle 220 und ein gemeinsam benutztes Kommunikationsmedium 232 in elektrischer Verbindung. Bei den Ausführungsformen kann das gemeinsam benutzte Kommunikationsmedium 232 einen Computerbus oder ein Mehrfachzugriffsdatennetz umfassen.
  • Die Kopfstellen-MAC 218 steht sowohl über die Backplane-Schnittstelle 220 als auch das gemeinsam benutzte Kommunikationsmedium 232 auch mit der Ethernet-Schnittstelle 224 in elektrischer Verbindung. Sofern angemessen, werden durch die Kopfstellen-MAC 218 wiederhergestellte Ethernet-Pakete an die Ethernet-Schnittstelle 224 übertragen, um über einen Router an das paketvermittelte Netz abgegeben zu werden.
  • Der Senderabschnitt des CMTS 104 umfasst einen Downstream-Modulator 226, ein Oberflächenwellenfilter (SAW-Filter – Surface Acoustic Wave filter) 228, einen Verstärker (AMP) 230, einen Zwischenfrequenzausgang (IF-Ausgang) 212, einen Hochfrequenz- (HF-) Aufwärtswandler 210 und die Glasfaser-/Koaxialkabelstufe 204. Die Übertragung beginnt mit der Erzeugung eines digitalen Sendesignals durch die Kopfstellen-MAC 218. Das digitale Sendesignal kann Daten enthalten, die ursprünglich über die Ethernet-Schnittstelle 224 von dem paketvermittelten Netz 112 empfangen wurden. Die Kopfstellen-MAC 218 gibt das digitale Sendesignal an den Downstream-Modulator 226 aus, der es in eine analoge Form umwandelt und es in Übereinstimmung mit entweder einer 64-QAM- oder 256-QAM-Technik auf ein Trägersignal moduliert.
  • Das vom Downstream-Modulator 256 ausgegebene, modulierte Trägersignal wird in das SAW-Filter 228 eingegeben, das nur Spektralkomponenten des Signals durchlässt, die innerhalb einer erwünschten Bandbreite liegen. Das gefilterte Signal wird dann an den Verstärker 230 ausgegeben, der es verstärkt und an den IF-Ausgang 212 ausgibt. Der IF-Ausgang 212 leitet das Signal an den HF-Aufwärtswandler 210 weiter, der das Signal aufwärts wandelt. Bei den Ausführungsformen hat das aufwärts gewandelte Signal Spektraleigenschaften innerhalb des Frequenzbereichs von ungefähr 54–860 MHz. Das aufwärts gewandelte Signal wird dann über das Koaxialkabel 208 an die Glasfaser-/Koaxialkabelstufe 204 ausgegeben. Die Glasfaser-/Koaxialkabelstufe 204 sendet das Signal über die Glasfaser 202 des HFC-Netzes 110.
  • 3 zeigt ein schematisches Blockdiagramm einer Implementierung des Kabelmodems 108 des Kabelmodemsystems 100, das rein beispielhaft angegeben ist und die vorliegende Erfindung nicht einschränken soll. Das Kabelmodem 108 ist dafür konfiguriert, über den Koaxialkabelanschluss 332 gemäß 3 Signale vom HFC-Netz 110 zu empfangen und an dieses zu senden. Dementsprechend wird das Kabelmodem 108 vermittels eines Empfängerabschnitts und eines Senderabschnitts beschrieben.
  • Der Empfängerabschnitt umfasst ein Diplex-Filter 302, einen HF-Tuner 304, ein SAW-Filter 306, einen Verstärker (AMP) 308 und einen Downstream-Empfänger 310. Der Empfang beginnt mit dem Empfangen eines vom CMTS 104 stammenden Downstream-Signals durch das Diplex-Filter 302. Das Diplex-Filter 302 arbeitet so, dass es das Downstream-Signal isoliert und es an den HF-Tuner 304 weiterleitet. Bei den Ausführungsformen hat das Downstream-Signal Spektraleigenschaften innerhalb des Frequenzbereichs von ungefähr 54–860 MHz. Der HF-Tuner wandelt das Signal abwärts und gibt es an das SAW-Filter 306 aus, das nur Spektralkomponenten des abwärts gewandelten Signals durchlässt, die innerhalb einer erwünschten Bandbreite liegen. Das gefilterte Signal wird an den Verstärker 308 ausgegeben, der es verstärkt und an den Downstream-Empfänger 310 weiterleitet. Automatische Verstärkungssteuerungen (AGC – Automatic Gain Control) werden vom Downstream-Empfänger 310 dem HF-Tuner 304 zugeführt.
  • Der Downstream-Empfänger 310 demoduliert das verstärkte Signal in Übereinstimmung mit entweder einer 64-QAM- oder 256-QAM-Technik, um das eigentliche Informationssignal wiederherzustellen. Der Downstream-Empfänger 310 wandelt außerdem das eigentliche Informationssignal von einer analogen Form in eine digitale Form um. Diese digitalen Daten werden anschließend der Medienzugangssteuerung (MAC) 314 zugeführt.
  • Die MAC 314 verarbeitet die digitalen Daten, die beispielsweise Ethernet-Pakete zur Übertragung an ein angeschlossenes Benutzergerät umfassen können. Die Funktio nen der MAC 314 können in Hardware oder Software implementiert werden. Bei der beispielhaften Ausführung gemäß 3 sind die Funktionen der MAC 314 sowohl in Hardware als auch in Software implementiert. Software-Funktionen der MAC 314 können entweder im RAM 322 oder im ROM 324 gespeichert und durch die CPU 320 ausgeführt werden. Die MAC 314 steht mit diesen Elementen über ein gemeinsam benutztes Kommunikationsmedium 316 in elektrischer Verbindung. Bei den Ausführungsformen kann das gemeinsam benutzte Kommunikationsmedium einen Computerbus oder ein Mehrfachzugriffsdatennetz umfassen.
  • Die MAC 314 steht über das gemeinsam benutzte Kommunikationsmedium 316 auch mit der Ethernet-Schnittstelle 318 in elektrischer Verbindung. Sofern angemessen, werden durch die MAC 314 wiederhergestellte Ethernet-Pakete an die Ethernet-Schnittstelle 318 übermittelt, um an ein angeschlossenes Benutzergerät übertragen zu werden.
  • Der Senderabschnitt des Kabelmodems 108 umfasst einen Upstream-Burst-Modulator 326, ein Tiefpassfilter (TP-Filter) 328, einen Leistungsverstärker (PA) 330 und das Diplex-Filter 302. Die Übertragung beginnt mit der Konstruktion eines Datenpakets durch die MAC 314. Das Datenpaket kann Daten enthalten, die ursprünglich über die Ethernet-Schnittstelle 318 von einem angeschlossenen Benutzergerät empfangen wurden. Gemäß den Ausführungsformen der vorliegenden Erfindung kann die MAC 314 das Datenpaket in Übereinstimmung mit den in der DOCSIS-Spezifikation ausgeführten Protokollen oder, sofern angemessen, in Übereinstimmung mit einem firmeneigenen Protokoll formatieren, das über die in der DOCSIS-Spezifikation ausgeführten Protokolle hinausgeht, wie hierin noch genauer beschrieben. Die MAC 314 gibt das Datenpaket an den Upstream-Burst-Modulator 326 aus, der es in eine analoge Form umwandelt und es in Übereinstimmung mit entweder einer QPSK- oder 16-QAM-Technik auf ein Trägersignal moduliert.
  • Der Upstream-Burst-Modulator 326 gibt das modulierte Trägersignal an das Tiefpassfilter 328 aus, das Signale mit Spektraleigenschaften innerhalb einer erwünschten Bandbreite durchlässt. Bei den Ausführungsformen liegt die erwünschte Bandbreite innerhalb des Frequenzbereichs von ungefähr 5–42 MHz. Die gefilterten Signale werden dann dem Leistungsverstärker (PA) 330 zugeführt, der das Signal verstärkt und es dem Diplex-Filter 302 zuführt. Die Verstärkung im Leistungsverstärker 330 wird durch den Burst-Modulator 326 geregelt. Das Diplex-Filter 302 isoliert das verstärkte Signal und sendet es während einer zeitlich geplanten Burst-Gelegenheit in Upstream-Richtung über das HFC-Netz 110.
  • C. Unterstützung erweiterter Datenübertragungsprotokolle gemäß den Ausführungsformen der vorliegenden Erfindung
  • Wie vorstehend erwähnt, senden bzw. empfangen das Kabelmodem 108 und das CMTS 104 gemäß den Ausführungsformen der vorliegenden Erfindung Daten in firmeneigenen Formaten, die über standardgemäße DOCSIS-Protokolle hinausgehen. Gemäß den Ausführungsformen modifiziert das Kabelmodem 108 beispielsweise in Übereinstimmung mit einem firmeneigenen Header-Unterdrückungsschema Datenpakete zur Übertragung an das CMTS 104, wobei das CMTS 104 bei Empfang der modifizierten Datenpakete diese in Übereinstimmung mit demselben firmeneigenen Header-Komprimierungsschema rekonstruiert.
  • Das Kabelmodem 108 ist, ferner gemäß den Ausführungsformen der vorliegenden Erfindung, dennoch mit herkömmlichen DOCSIS-kompatiblen CMTS-Geräten dialogfähig, die im Gegensatz zum CMTS 104 keine erweiterten Protokolle unterstützen. Das Kabelmodem 108 erreicht dies durch Feststellen, ob es mit einem CMTS kommuniziert, das erweiterte Protokolle unterstützt, wie etwa das CMTS 104, oder mit einem CMTS, das dies nicht tut. Wenn das CMTS keine erweiterten Protokolle unterstützt, überträgt das Kabelmodem 108 Daten, die in Übereinstimmung mit standardgemäßen DOCSIS-Protokollen, anstatt mit erweiterten Protokollen, formatiert wurden.
  • 4 zeigt ein Flussdiagramm 400 eines Verfahrens zur Unterstützung erweiterter Protokolle in einem Kabelmodemsystem gemäß den Ausführungsformen der vorliegenden Erfindung, das dieses Verfahren genauer beschreibt. Die Erfindung ist jedoch nicht auf die durch das Flussdiagramm 400 vorgesehene Beschreibung beschränkt. Es geht vielmehr für Fachleute auf dem oder den relevanten Gebieten aus den hierin dargelegten Lehren hervor, dass andere Funktionsflüsse im Schutzumfang der vorliegenden Erfindung enthalten sind. Das Flussdiagramm 400 wird unter ständiger Bezugnahme auf das beispielhafte CMTS 104 und das beispielhafte Kabelmodem 108 des Kabelmodemsystems 100 sowie unter Bezugnahme auf die beispielhafte Hardware-Implementierung des Kabelmodems 108 gemäß 3 beschrieben.
  • In Schritt 402 sendet das Kabelmodem (KM) 108 eine Registrierungsnachricht an das CMTS 104, die die Unterstützung eines erweiterten Protokolls angibt. In Bezug auf die beispielhafte Ausführung des unter Bezugnahme auf 3 beschriebenen Kabelmodems 108 konstruiert die MAC 314 diese Registrierungsnachricht sowie alle anderen vom Kabelmodem 108 ausgegebenen MAC-Unterstützungsnachrichten.
  • Gemäß den Ausführungsformen sendet das Kabelmodem 108 diese Registrierungsnachricht als Teil eines Austausches von Registrierungsnachrichten, der zwischen einem Kabelmodem und einem CMTS erfolgen muss, wenn das Kabelmodem erstmals am HFC-Netz erscheint. Gemäß der DOCSIS-Spezifikation umfasst dieser Austausch von Registrierungsnachrichten im Allgemeinen das Senden einer Registrierungsanfragenachricht (REG-REQ-Nachricht) vom Kabelmodem an das CMTS und das Senden einer Registrierungsantwortnachricht (REG-RSP-Nachricht) vom CMTS zum Kabelmodem in Antwort auf die empfangene REG-REQ-Nachricht. Dieses Registrierungsprotokoll ist im Stand der Technik wohlbekannt.
  • Gemäß den Ausführungsformen meldet das Kabelmodem 108 dem CMTS 104, dass es ein erweitertes Protokoll unterstützt, indem es einen Unterstützungsdeskriptor für erweiterte Protokolle in einem anbieterspezifischen Informationsfeld der REG-REQ-Nachricht platziert, die es an das CMTS 104 sendet. Im Gegensatz dazu bedeutet bei solchen Ausführungsformen die Abwesenheit eines Unterstützungsdeskriptors für erweiterte Protokolle in einem anbieterspezifischen Informationsfeld der REG-REQ-Nachricht, dass ein Kabelmodem nur standardgemäße DOCSIS-Protokolle unterstützt.
  • In Schritt 404 empfängt das Kabelmodem 108 eine Antwort auf die Registrierungsnachricht vom CMTS 104, die angibt, ob das CMTS 104 das erweiterte Protokoll unterstützt oder nicht. Da das CMTS 104 des beispielhaften Kabelmodemsystems 100 dasselbe erweiterte Protokoll wie das Kabelmodem 108 unterstützt, wie vorstehend besprochen, gibt die Antwort auf die Registrierungsnachricht an, dass das erweiterte Protokoll unterstützt wird. Wenn das CMTS 104 das erweiterte Protokoll jedoch nicht unterstützen würde (wenn es sich z.B. um ein herkömmliches DOCSIS-kompatibles CMTS handeln würde), dann würde die Antwort auf die Registrierungsnachricht eine Angabe umfassen, dass das CMTS 104 das erweiterte Protokoll nicht erkennen konnte. Bei Ausführungsformen beispielsweise, bei denen die Registrierungsnachricht eine REG-REQ-Nachricht umfasst, die einen Unterstützungsdeskriptor für erweiterte Protokolle in einem anbieterspezifischen Informationsfeld enthält, kann die Antwort eine REG-RSP-Nachricht sein, die angibt, dass das CMTS 104 den Unterstützungsdeskriptor für erweiterte Protokolle nicht erkennen konnte.
  • Wenn die Antwort auf die Registrierungsnachricht angibt, dass das erweiterte Protokoll durch das CMTS unterstützt wird, dann formatiert das Kabelmodem 108 die Datenpakete zur Übertragung an das CMTS in Übereinstimmung mit dem erweiterten Protokoll, wie durch die Schritte 406 und 408 dargestellt. Wenn die Antwort auf die Registrierungsnachricht andererseits angibt, dass das CMTS das erweiterte Protokoll nicht unterstützt, dann formatiert das Kabelmodem 108 die Datenpakete zur Übertragung an das CMTS in Übereinstimmung mit standardgemäßen DOCSIS-Protokollen, wie durch die Schritte 406 und 410 dargestellt. Wie vorstehend in Bezug auf die beispielhafte Ausführung des in 3 gezeigten Kabelmodems 108 besprochen, ist die MAC 314 für die Formatierung von Datenpaketen zur Übertragung an das CMTS verantwortlich.
  • Bei alternativen Ausführungsformen der vorliegenden Erfindung kann, anstelle des vorstehend beschriebenen standardgemäßen DOCSIS-REG-REQ-/REG-RSP-Protokolls, ein privater Kommunikationskanal genutzt werden, um die Schritte 402 und 404 des Flussdiagramms 400 zu implementieren. Bei einer solchen Ausführungsform sendet das CMTS 104 beispielsweise nach einer erfolgreichen Kabelmodemregistrierung eine Unicast-UDP-Nachricht an das Kabelmodem 108, die angibt, dass das CMTS 104 dazu in der Lage ist, erweiterte Protokolle zu unterstützen (Schritt ist nicht in 4 gezeigt). Wenn das Kabelmodem 108 ein erweitertes Protokoll unterstützt, antwortet es auf die UDP-Nachricht durch Senden einer UDP-Antwort, die angibt, welches erweiterte Protokoll es unterstützt. In Übereinstimmung mit dieser Technik umfasst die Registrierungsnachricht gemäß Schritt 402 die UDP-Antwort vom Kabelmodem 108. Gemäß den Ausführungsformen gibt die UDP-Antwort außerdem den spezifischen Grad an, in dem das Kabelmodem 108 dazu imstande ist, das erweiterte Protokoll zu unterstützen.
  • Wenn das Kabelmodem kein erweitertes Protokoll unterstützt, sendet es keine Antwort auf die UDP-Nachricht. Gemäß den Ausführungsformen sendet das CMTS 104 die UDP-Nachricht erneut eine vordefinierte Anzahl von Malen, wobei, wenn nach der vordefinierten Anzahl an erneuten Übertragungen keine Antwort vom Kabelmodem erhalten wird, das CMTS bestimmt, dass das Kabelmodem keine erweiterten Protokolle unterstützt. Wenn das CMTS 104 jedoch vom Kabelmodem 108 eine geeignete UDP-Antwort erhält, erfasst es die erweiterten Protokollfähigkeiten des Kabelmodems 108 und antwortet mit einer zweiten UDP-Nachricht, die angibt, ob es das vom Kabelmodem 108 unterstützte, spezifische erweiterte Protokoll unterstützt oder nicht. Gemäß dieser Technik umfasst die Antwort auf die Registrierungsnachricht gemäß Schritt 404 die zweite UDP-Nachricht vom CMTS 104.
  • Das im Flussdiagramm 400 beschriebene Verfahren stellt die Kompatibilität oder Dialogfähigkeit zwischen einem Kabelmodem, das ein erweitertes Protokoll gemäß den Ausführungsformen der vorliegenden Erfindung unterstützt, und einem CMTS-Gerät sicher, das nicht dasselbe Protokoll unterstützt. In ähnlicher Weise ist ein CMTS, das ein erweitertes Protokoll gemäß den Ausführungsformen der vorliegenden Erfindung unterstützt, wie etwa das CMTS 104, mit einem Kabelmodem dialogfähig, das nicht dasselbe erweiterte Protokoll unterstützt. Das CMTS 104 ist beispielsweise mit herkömmlichen DOCSIS-kompatiblen Kabelmodems dialogfähig, die keine erweiterten Protokolle unterstützen, wie etwa das Kabelmodem 106. Das CMTS 104 erreicht dies durch Bestimmen, ob ein empfangenes Paket von einem herkömmlichen DOCSIS-kompatiblen Kabelmodem gesendet wurde, wie etwa dem Kabelmodem 106, oder von einem Kabelmodem, das dazu imstande ist, Daten unter Verwendung erweiterter Protokolle zu senden, wie etwa das Kabelmodem 108, und durch entsprechendes Verarbeiten des Pakets.
  • 5 zeigt ein Flussdiagramm 500 eines Verfahrens zum Unterstützen von erweiterten Protokollen in einem Kabelmodemsystem gemäß den Ausführungsformen der vorliegenden Erfindung, das dieses Verfahren genauer erläutert. Die Erfindung ist jedoch nicht auf die durch das Flussdiagramm 500 vorgesehene Beschreibung beschränkt. Es geht vielmehr für Fachleute auf dem oder den relevanten Gebieten aus den hierin dargelegten Lehren hervor, dass andere Funktionsflüsse im Schutzumfang der vorliegenden Erfindung enthalten sind. Das Flussdiagramm 500 wird unter ständiger Bezugnahme auf das beispielhafte CMTS 104 und die beispielhaften Kabelmodems 106 und 108 des Kabelmodemsystems 100 sowie unter Bezugnahme auf die beispielhafte Hardware-Implementierung des CMTS 104 gemäß 2 beschrieben.
  • In Schritt 502 empfängt das CMTS 104 eine Registrierungsnachricht von einem Kabelmodem, die ein vom Kabelmodem unterstütztes Datenübertragungsprotokoll angibt. In Bezug auf das beispielhafte Kabelmodemsystem 100 gemäß 1 kann die Registrierungsnachricht vom Kabelmodem 106 stammen, in welchem Fall die Nachricht eine Datenübertragung gemäß standardgemäßen DOCSIS-Protokollen angibt, oder die Registrierungsnachricht kann vom Kabelmodem 108 stammen, in welchem Fall die Nachricht eine Datenübertragung gemäß einem erweiterten Protokoll angibt. Bei den Ausführungsformen ist die Registrierungsnachricht eine DOCSIS-REG-REQ-Nachricht, wobei die Anwesenheit eines Deskriptors für erweiterte Protokolle in einem anbieterspezifischen Feld der REG-REQ-Nachricht eine Datenübertragung gemäß einem erweiterten Protokoll bedeutet, während die Abwesenheit des Deskriptors für erweiterte Protokolle eine Datenübertragung gemäß standardgemäßen DOCSIS-Protokollen bedeutet.
  • In Schritt 504 weist das CMTS 104 dem Kabelmodem eine eindeutige Kabelmodemkennung (KM-ID) zu und sendet die Kabelmodemkennung an das Kabelmodem. Bei den Ausführungsformen umfasst die Kabelmodemkennung die primäre DOCSIS-Dienstekennung (SID), die vom CMTS zugewiesen und als Teil der DOCSIS-REG-RSP-Nachricht an das Kabelmodem gesendet wird. In Bezug auf die beispielhafte Implementierung des in Bezug auf 2 beschriebenen CMTS 104 ist die Kopfstellen-MAC 218 für die Zuweisung einer eindeutigen Kabelmodemkennung an das Kabelmodem verantwortlich.
  • In Schritt 506 erzeugt das CMTS 104 im Speicher eine Zuordnung zwischen der Kabelmodemkennung und einer Protokollangabe, die das vom Kabelmodem unterstützte Datenübertragungsprotokoll angibt. In Bezug auf die beispielhafte Ausführung des unter Bezugnahme auf 2 beschriebene CMTS 104 wird diese Aufgabe durch die Kopfstellen-MAC 218 ausgeführt, die die Kabelmodemkennung und die Protokollangabe entweder im ROM 218 oder im RAM 220 als zugeordnete Werte speichert. Bei den Ausführungsformen speichert das CMTS 104 die Kabelmodemkennung und die Protokollangabe als zugeordnete Werte in einer Nachschlagetabelle (Look-up-Tabelle).
  • In Schritt 508 empfängt das CMTS 104 eine Übertragungsgelegenheitsanfrage von einem Kabelmodem, die die dem Kabelmodem zugeordnete Kabelmodemkennung umfasst. Bei den Ausführungsformen wird die Anfrage in einem Anfragekonkurrenzbereich empfangen, der durch ein DOCSIS-Zuweisungs-MAP definiert ist. Das Zuweisungs-MAP ist eine MAC-Managementnachricht variabler Länge, die vom CMTS auf dem Downstream-Kanal gesendet wird und, für ein gewisses Zeitintervall, beschreibt, wofür die Upstream-Bandbreite verwendet werden muss. Das Zuweisungs-MAP weist die Bandbreite vermittels Basiszeiteinheiten zu, die Mini-Slots genannt werden. Ein gegebenes Zuweisungs-MAP kann einige Mini-Slots als Bewilligung für ein spezifisches Kabelmodem beschreiben, darin und in anderen Mini-Slots, die zur Konkurrenzübertragung durch mehrere Kabelmodems zur Verfügung sehen, Daten zu senden. Das DOCSIS-Zuweisungs-MAP ist in der DOCSIS-Spezifikation beschrieben und im Stand der Technik wohlbekannt.
  • In Schritt 510 weist das CMTS 104 dem Kabelmodem in Antwort auf die Übertragungsgelegenheitsanfrage eine Übertragungsgelegenheit zu. Bei den Ausführungsformen weist das CMTS 104 dem Kabelmodem eine Übertragungsgelegenheit zu, indem es dem Kabelmodem eine Anzahl an Mini-Slots in einem DOCSIS-Zuweisungs-MAP zur Übertragung von Daten in Upstream-Richtung gemäß der DOCSIS-Spezifikation zuweist. Im Hinblick auf die beispielhafte Ausführung des CMTS 104, das in Bezug auf 2 beschrieben ist, wird die Konstruktion einer MAP-Zuweisungsnachricht durch die Kopfstellen-MAC 218 ausgeführt.
  • In Schritt 512 verwendet das CMTS 104 die Kabelmodemkennung aus der Übertragungsgelegenheitsanfrage dazu, auf die der Kabelmodemkennung zugeordnete Protokollangabe zuzugreifen, welche im vorhergehenden Schritt 506 im Speicher gespeichert wurde. Bei den Ausführungsformen konsultiert das CMTS 104 eine Nachschlagetabelle, die die Kabelmodemkennung der Protokollangabe zuordnet. Im Hinblick auf die beispielhafte Ausführung des in Bezug auf 2 beschriebenen CMTS 104 wird dieser Schritt durch die Kopfstellen-MAC 218 durchgeführt.
  • In Schritt 514 verarbeitet das CMTS 104 vom Kabelmodem während der zugewiesenen Übertragungsgelegenheit gesendete Daten in Übereinstimmung mit dem durch die Angabe spezifizierten Übertragungsprotokoll. Wenn die Angabe beispielsweise aussagt, dass ein erweitertes Protokoll unterstützt wird, wie im Falle 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 für ein erweitertes Protokoll angegeben wird, wie im Falle des Kabelmodems 106, dann verarbeitet das CMTS 104 das Datenpaket, das es von dem Kabelmodem zu empfangen erwartet, gemäß standardgemäßen DOCSIS-Protokollen. Im Hinblick auf die beispielhafte Ausführung des in Bezug auf 2 beschriebenen CMTS 104 wird die Verarbeitung von Datenpaketen durch die Kopfstellen-MAC 218 durchgeführt.
  • Somit erfasst und speichert das CMTS 104 gemäß den Ausführungsformen der vorliegenden Erfindung während der Kabelmodemregistrierung Informationen über die Fähigkeiten der Kabelmodems, mit denen es kommunizieren wird. Wenn das CMTS 104 danach einem Kabelmodem Upstream-Bandbreite zuweist, greift es auf die gespeicherten Informationen zu, um zu ermitteln, wie die Daten zu verarbeiten sind, die es vom Kabelmodem zu empfangen erwartet. Diese Technik wird durch die TDMA-Aspekte eines Kabelmodemsystems erleichtert, wobei das CMTS zu jeder gegebenen Zeit wissen muss, von welchem Kabelmodem es Daten empfängt. Diese Technik ist vorteilhaft, da sie die Verwendung von Protokollen ermöglicht, die über DOCSIS hinausgehen, wobei gleichzeitig die Dialogfähigkeit durch Befolgen von standardgemäßen DOCSIS-Registrierungs-, Anfrage- und Bewilligungsprotokollen sichergestellt wird.
  • 1. Paket-Header-Unterdrückung oder -Komprimierung
  • Die 6A–8 sind zur Erläuterung der den Ausführungsformen der vorliegenden Erfindung gemäßen Art und Weise, in der Pakete durch das Kabelmodem 108 komprimiert und durch das CMTS 104 dekomprimiert werden, nützlich.
  • 6A stellt ein Datenpaket 605 dar, das durch ein Benutzergerät zur Übertragung über das HFC-Netz 110 erzeugt wird. Das Datenpaket 605 umfasst einen MAC-Header 607, einen IP-Header 609, einen UDP-Header 611, einen RTP-Header 613 und eine Nutzlast (Payload) 615. Bei diesem Beispiel umfasst der MAC-Header 607 14 Bytes, der IP-Header 609 20 Bytes, der UDP-Header 611 12 Bytes, der RTP-Header 613 8 Bytes und die Nutzlast 615 zwischen 1 und N Bytes, abhängig von der Art der gesendeten Daten.
  • Erfindungsgemäß kann das Datenpaket 605 durch ein Anwendungsprogramm erzeugt werden, welches das Benutzergerät 116 betreibt, wie vorstehend in Bezug auf 1 beschrieben. Ein vom Benutzergerät 116 betriebenes Anwendungsprogramm kann Sprach- oder Dateninformationen zur Übertragung über das HFC-Netz 110 erzeugen. Diese Sprach- oder Dateninformationen umfassen die Nutzlast 615 des Datenpakets 605. Das vom Benutzergerät 116 betriebene Anwendungsprogramm, hängt den IP-Header 609, den UDP-Header 611 und den RTP-Header 613 an die Nutzlast 615 an, um eine Übertragung in Übereinstimmung mit standardgemäßen IP-Protokollen zu ermöglichen. Eine Ethernet-Karte im Benutzergerät 116 hängt ferner den MAC-Header 607 an das Datenpaket 605 an, um eine Übertragung in Übereinstimmung mit standardgemäßen Ethernet-Protokollen zu ermöglichen.
  • Beim Empfang des Datenpakets 605 unterdrückt das Kabelmodem das Datenpaket 605 in Übereinstimmung mit einer beliebigen erwünschten Header-Unterdrückungstechnik. Beispiele für Header-Unterdrückungstechniken umfassen das standardgemäße DOCSIS-PHS sowie Techniken, die über standardgemäße DOCSIS-Protokolle hinausgehen, wie etwa dynamische Delta-Codierung und RTP-Codierung, die hierin genauer beschrieben sind. Nach dem Studium dieser Beschreibung wird ein Fachmann auf dem/den relevanten Gebieten erkennen, dass eine beliebige Anzahl an Unterdrückungstechniken genutzt werden kann, ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen.
  • 6B stellt das Erscheinungsbild eines Datenpakets 605 dar, nachdem es komprimiert worden ist, um ein komprimiertes Datenpaket 610 gemäß den Ausführungsformen der vorliegenden Erfindung zu erzeugen. Bei dieser beispielhaften Ausführungsform wurden der IP-Header 609, der UDP-Header 611 und der RTP-Header 613 beseitigt und durch einen Ein-Byte-Index 617 ersetzt. Dementsprechend besteht das komprimierte Datenpaket 610 aus dem Index 617, dem MAC-Header 607 und der Nutzlast 615. Der Index 617 besteht aus einem Byte und wird dazu verwendet, anzuzeigen, dass das Datenpaket 610 komprimiert worden ist. Der Index 617 wird außerdem dazu verwendet, die spezifische Unterdrückungstechnik anzugeben, die zum Komprimieren des Datenpakets verwendet worden ist. Weitere Details des Index 617 sind nachfolgend in Bezug auf 7 beschrieben. Infolge der Beseitigung der vorstehend genannten Header, ist das komprimierte Datenpaket 610 um 40 Bytes kleiner als das ursprüngliche Datenpaket 605.
  • 6C ist ein Beispiel eines Mischprotokoll-DOCSIS-Sende-Bursts (d.h. SID – Dienstekennung) 606, der mehrere Pakete enthält, die gemäß den Ausführungsformen der vorliegenden Erfindung unterdrückt worden sind. Die Mischprotokoll-SID 606 besteht aus dem komprimierten Datenpaket 610 und den weiteren komprimierten Datenpaketen 612 und 614. Gemäß einer Ausführungsform 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 der RTP-Codierung komprimiert, wie durch den Index 621 angegeben. Die Indizes 617, 619 und 621 trennen die Pakete in der Mischprotokoll-SID 606 voneinander. Diese Trennung ist eigentlich ein Framing-Protokoll. Auf diese Weise ist die Mischprotokoll-SID 606 dazu in der Lage, mehrere durch verschiedene Header-Unterdrückungstechniken unterdrückte Pakete zu senden.
  • 7 zeigt ein Flussdiagramm 700 eines Verfahrens zum Komprimieren von Paketen unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken gemäß den Ausführungsformen der vorliegenden Erfindung. Die Erfindung ist jedoch nicht auf die hierin in Bezug auf das Flussdiagramm 700 vorgesehene Beschreibung beschränkt. Für Fachleute auf dem/den relevanten Gebieten ist es nach dem Studium der hierin vorgesehenen Lehren ersichtlich, dass andere Funktionsflüsse im Schutzumfang der Erfindung enthalten sind. Das Flussdiagramm 700 wird unter ständiger Bezugnahme auf das beispielhafte Kabelmodemsystem 100 gemäß 1 beschrieben.
  • In Schritt 702 wird das Kabelmodem 108 eingeschaltet und initiiert ein Handshaking-Programm mit dem CMTS 104 über das HFC-Netz 110. Während dieses Initialisierungsverfahrens gibt das Kabelmodem 108 eine oder mehrere Indexzahlen an, um eine bestimmte Art von Paket-Header-Unterdrückungstechnik darzustellen. Beispielsweise könnte der Index 1 die DOCSIS-PHS-Unterdrückung bezeichnen, während die Indexzahlen 2 bis 10 die Verwendung einer dynamischen Delta-Codierung angeben könnten. Des Weiteren könnten die Indexzahlen 11 bis 20 die Verwendung einer RTP-Codierung angeben. Sobald diese Angaben gemacht worden sind, werden diese Informationen dem CMTS 104 über das HFC-Netz 110 mitgeteilt. Während des Initialisierungsverfahrens werden außerdem die der Komprimierung und Dekomprimierung eines Pakets zugeordneten Regeln in Übereinstimmung mit den verfügbaren Unterdrückungstechniken ausgetauscht. Die Regeln werden dem CMTS 104 durch das Kabelmodem 108 zugeführt. Das CMTS 104 speichert die Indexzahlen und ihre entsprechenden Regeln in einer Nachschlagetabelle zum späteren Abruf während des Paketdekomprimierungsverfahrens.
  • Bei den Ausführungsformen ist das vorstehend beschriebene Initialisierungsverfahren Teil der standardgemäßen DOCSIS-Kabelmodemregistrierungsprotokolle. Bei alternativen Ausführungsformen kann, wie vorstehend in Bezug auf 4 beschrieben, ein privater Kommunikationskanal dazu verwendet werden, die Übertragung von Indexzahlen und Regeln zu erleichtern. Dies kann bei DOCSIS1.0-Kabelmodemsystemen, bei denen das DOCSIS-Protokoll keine Klassifizierungs-/Header-Unterdrückungsfähigkeit definiert, besonders vorteilhaft sein.
  • In Schritt 704 empfängt das Kabelmodem 108 ein Datenpaket vom Benutzergerät 116. Das Datenpaket kann beispielsweise das Datenpaket 605 gemäß 6A sein.
  • In Schritt 706 bestimmt das Kabelmodem 108, ob das Datenpaket erfindungsgemäß unterdrückt werden soll. Bei einer Ausführungsform unterdrückt das Kabelmodem 108 das Datenpaket nicht, wenn es ein unkomprimierbares Paket ist (d.h. kein IP-Paket). In diesem Fall würde das Kabelmodem 108 das Datenpaket mit seinem vollständigen Header senden.
  • In Schritt 708 wählt das Kabelmodem 108 eine geeignete Paket-Header-Unterdrückungstechnik für die in Schritt 706 identifizierten Datenpakete aus. Bei einer Ausführungsform, wird, wenn die Datenpakete von der unbekannten IP-Datagramm-Art sind, DOCSIS-PHS gewählt. Bei IP-/RTP-Datenpaketen (d.h. Sprachpaketen) wird die RTP-Unterdrückung gewählt. Bei IP-/TCP-Datenpaketen variabler Länge wird die dynamische Delta-Unterdrückung gewählt.
  • In Schritt 710 hängt das Kabelmodem 108 ein Paket-Header-Element an das unterdrückte Datenpaket an. Das Paket-Header-Element enthält die in Schritt 702 angegebene Indexzahl für die in Schritt 708 gewählte spezifische Unterdrückungstechnik.
  • In Schritt 712 wird das Datenpaket gemäß den Regeln unterdrückt, die der in Schritt 708 gewählten Unterdrückungstechnik zugeordnet sind. Das resultierende komprimierte Datenpaket kann beispielsweise das komprimierte Datenpaket 610 gemäß 6B sein. Erfindungsgemäß ermöglichen die Schritte (704–712) die Unterdrückung oder Komprimierung von Datenpaketen gemäß jeder gewünschten Header-Unterdrückungstechnik. Die jedem Datenpaket zugeordnete Indexzahl kennzeichnet den Anfang des Datenpakets. Dementsprechend ist die Indexzahl ein brauchbarer Mechanismus zum Trennen eines Datenpakets von einem anderen und zur Bezeichnung der spezifischen Header-Unterdrückungstechnik, die zum Verarbeiten jedes Datenpakets verwendet wird.
  • Wie vorstehend besprochen, ermöglicht das DOCSIS-Protokoll eine Verkettung von Datenpaketen, es lässt jedoch kein Mischen verschiedener Header-Unterdrückungstechniken innerhalb eines/einer einzelnen DOCSIS-Sende-Bursts oder -SID zu. Da jedoch die Indexzahl, die in dem in Schritt 710 angehängten Paket-Header-Element enthalten ist, ein Mittel zum Trennen der Pakete bereitstellt, ist das Mischen verschiedener Header-Unterdrückungstechniken innerhalb einer SID nun möglich. Demgemäß wird bei einer alternativen Ausführungsform eine Mischprotokoll-SID in Schritt 714 erzeugt.
  • In Schritt 714 werden die Datenpakete miteinander verknüpft. Infolge der Verkettung von Paketen, die mit verschiedenen Header-Unterdrückungstechniken unterdrückt wurden, kann die SID nun als Mischprotokoll-SID betrachtet werden. Tatsächlich dient der Index als Framing-Protokoll, das sowohl die Pakete innerhalb der Mischprotokoll-SID voneinander trennt als auch die Art der Header-Unterdrückung nennt, die bei jedem Datenpaket innerhalb der Mischprotokoll-SID angewandt wurde. Bei einer Ausführungsform kann die Mischprotokoll-SID beispielsweise die Mischprotokoll-SID 606 gemäß 6C sein. Schließlich wird die Mischprotokoll-SID in Schritt 716 an ein CMTS 104 gesendet.
  • 2. Paket-Header-Erweiterung oder -Dekomprimierung
  • 8 ist ein Flussdiagramm eines Verfahrens zum Erweitern oder Dekomprimieren von Paketen, die unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken gemäß den Ausführungsformen der vorliegenden Erfindung komprimiert worden sind.
  • In Schritt 802 empfängt das CMTS 104 eine Mischprotokoll-SID, die aus einem oder mehreren Datenpaketen besteht.
  • In Schritt 805 untersucht das CMTS 104 jedes der Datenpakete, um zu bestimmen, ob es unterdrückt worden ist. Wenn ein Paket-Header-Element an ein Datenpaket angehängt worden ist, dann weiß das CMTS 104, dass das Datenpaket unterdrückt worden ist. Wenn kein Paket-Header-Element vorhanden ist, dann wurde das Paket nicht unterdrückt und die Steuerung geht direkt zu Schritt 820 über.
  • In Schritt 810 sucht das CMTS 104 in seiner Nachschlagetabelle nach der im Paket-Header-Element enthaltenen Indexzahl. Wenn die Indexzahl gefunden wird, dann wurden die der Unterdrückungstechnik zugeordneten Erweiterungsregeln zuvor dem CMTS 104 zugeführt. Bei einer Ausführungsform würden die Erweiterungsregeln zuvor während des in Schritt 702 beschriebenen Initialisierungsverfahrens zugeführt werden. Wenn die Indexzahl nicht vorhanden ist, dann geht die Steuerung zu Schritt 815 über.
  • In Schritt 815 tauschen das CMTS 104 und das Kabelmodem 108 Daten aus, die die Regeln zum Erweitern des Datenpakets in Echtzeit beschreiben (d.h. wenn das Datenpaket ankommt).
  • In Schritt 820 verarbeitet das CMTS 104 jedes der Datenpakete. Wenn das Datenpaket nicht unterdrückt wurde (d.h. es war kein Paket-Header-Element vorhanden), wird das Datenpaket gemäß standardgemäßen DOCSIS-Protokollen verarbeitet. Wenn das Datenpaket unterdrückt wurde (d.h. es war ein Paket-Header-Element vorhanden), ruft das CMTS 104 die Regeln zum Erweitern des Datenpakets basierend auf der Unterdrückungstechnik ab, die durch die im Paket-Header-Element vorhandene Indexzahl angegeben ist. Beim Erweitern des Datenpakets erzeugt das CMTS 104 ein unkomprimiertes Datenpaket. Bei einer Ausführungsform würde das CMTS 104, am Ende des Schritts 820, ein Datenpaket erzeugen, wie etwa das unkomprimierte Datenpaket 605 gemäß 6A. Da die Mischprotokoll-SID ein oder mehrere Datenpakete enthält, werden die Schritte 805 bis 820 wiederholt bis alle Datenpakete innerhalb der Mischprotokoll-SID verarbeitet worden sind. Die Verarbeitung endet mit Schritt 825.
  • 3. RTP-Header-Unterdrückung
  • Wie vorstehend erwähnt, stellt die Erfindung eine Echtzeit-Übertragungsprotokoll- (RTP-/Real-time Transport Protocol) Header-Unterdrückung bereit. Die erfindungsgemäße RTP-Header-Unterdrückungstechnik sieht große Effizienzgewinne bei der Netzwerkbandbreitennutzung vor, indem die Übertragung redundanter Muster beseitigt und veränderliche Felder in einem Datenstrom unterdrückt werden. Die Erfindung erreicht dies durch Erkennen regelmäßiger Muster im Netzverkehr. Bei den Ausführungsformen können die regelmäßigen Muster beseitigt werden, indem sich ein Sender von Netzverkehr, wie etwa das KM 108, und ein Empfänger von Netzverkehr, wie etwa das CMTS 104, über die Regeln für eine ordnungsgemäße Header-Rekonstruktion einigen, um den Header am Empfangsende zu reproduzieren. Durch Verringern der Menge an Netzwerkbandbreite, die zum Senden von RTP-Informationen quer durch das Netzwerk benötigt wird, ermöglicht die vorliegende Erfindung die verbesserte Leistung bei derselben Anzahl an Benutzern des Netzwerks sowie die Fähigkeit, dem Netzwerk in effizienter Weise mehr Benutzer hinzuzufügen.
  • Vor dem Beschreiben der erfindungsgemäßen RTP-Header-Unterdrückungstechnik wird ein herkömmlicher 802.3-/IP-/UDP-/RTP-Protokoll-Header 900 für eine RTP-Übertragung in 9A beschrieben. Der beispielhafte Protokoll-Header 900 umfasst einen 14Byte-802.3-Header 902, einen 20Byte-IP- (Internet-Protokoll) Header 904, einen 8Byte-UDP- (User Datagram Protocol) Header 906 und einen 12Byte-RTP-Header 908. Bei diesem Beispiel erzeugt der 802.3/IP-/UDP-/RTP-Header 900 einen 54Byte-Header. Der Datenabschnitt eines RTP-Pakets kann im Vergleich zu dem zum Senden von Daten unter Verwendung des 802.3-/IP-/UDP-/RTP-Headers 900 erforderlichen Overhead klein sein. Der Datenabschnitt eines RTP-Pakets kann beispielsweise lediglich 20 Bytes betragen, was dazu führt, dass seine Größe weniger als die Hälfte der Größe des Headers 900 beträgt. Außerdem ändern sich die meisten Felder im Paket-Header 900 nicht von Paket zu Paket. Die Übertragung solcher redundanter Muster (sich von Paket zu Paket nicht verändernder Header- Informationen) kann große Mengen an Netzwerkbandbreite verschwenden, insbesondere wenn der Datenabschnitt des RTP-Pakets kleiner als der Header 900 ist. Es wäre daher äußerst ineffizient, den Header 900 zu senden, ohne ihn zu komprimieren.
  • DOCSIS 1.1 ermöglicht die Unterdrückung redundanter Informationen in Paketen mit einem Merkmal, das "Payload Header Suppression" (PHS – Nutzlast-Header-Unterdrückung) genannt wird. PHS ermöglicht die Unterdrückung sich nicht verändernder Bytes in einer einzelnen SID (d.h. Datenstrom). Leider kann PHS, wie vorstehend ausgeführt, sich dynamisch verändernde Felder nicht unterdrücken.
  • Die erfindungsgemäße RTP-Header-Unterdrückungstechnik erhöht die Effizienz der Datenabgabe durch das Erkennen von Verhaltensmustern in den sich verändernden Feldern des 802.3-/IP/UDP-/RTP-Headers 900. 9B ist ein Diagramm eines RTP-Protokollpakets 910. Das RTP-Protokollpaket 910 umfasst unter anderem ein Ziel-MAC-Adressenfeld 912, ein Quellen-MAC-Adressenfeld 914, ein Typ-/Längenfeld 916, ein Protokollversionsfeld 918, ein Header-Längenfeld 920, ein Type-of-Service-Feld (ToS-Feld/Dienstleistungsfeld) 922, ein Gesamtlängenfeld 924, ein Paket-ID-Feld 926, ein Fragment-Offset-Feld 928, ein Time-to-Live-Feld 930, ein Protokollfeld 932, ein Header-Prüfsummenfeld 934, ein Quellen-IP-Adressenfeld 936, ein Ziel-IP-Adressenfeld 938, ein Quellenportfeld 940, ein Zielportfeld 942, ein Längenfeld 944, ein Prüfsummenfeld 946, ein Flag-Feld 948, ein Sequenznummernfeld (SEQ) 950, ein Zeitstempelfeld 952, ein Synchronisationsquellenkennungsfeld 954, ein PDU-Feld 956 und ein CRC-32-Feld 958. RTP-Protokollpakete sind auf dem/den relevanten Gebieten wohlbekannt, weshalb nicht jedes einzelne Feld genau beschrieben wird.
  • Der Großteil des Headers 900 kann unterdrückt werden. Die Felder des Datenpakets 910, die sich von Paket zu Paket ändern können, umfassen das IP-Paket-ID-Feld 926, das IP-Header-Prüfsummenfeld 934, das RTP-Sequenznummernfeld 950 und das RTP-Zeitstempelfeld 952. Das UDP-Prüfsummenfeld 946 ist immer auf null gestellt, da es nicht verwendet wird. Die übrigen Felder bleiben für die Dauer einer Sprachverbindung konstant.
  • Das RTP-Sequenznummernfeld 950 beginnt mit einem beliebigen Wert und wird bei jedem nachfolgenden Paket um einen Wert von eins inkrementiert. Das RTP-Zeitstempelfeld 952 wird um einen auf dem Quantisierungsintervall des Codec basieren den Wert inkrementiert. Der Deltawert zweiter Ordnung dieser Zahl beträgt für jeden gegebenen Codec bei einem gegebenen Quantisierungsintervall immer null.
  • Die Erfindung ermöglicht eine Abgabe der Pakete in der richtigen Reihenfolge über die Upstream-DOCSIS-HF-Verbindung. Die Erfindung unterdrückt den 802.3-/IP-/UDP-/RTP-Header 900 am KM 108 und stellt sicher, dass der Header 900 durch das CMTS 104 wiederhergestellt wird. Die Rekonstruktion des Headers 900 muss eine exakte Wiederherstellung sein. Dies wird durch Berechnen der Differenz zwischen dem RTP-Sequenznummernfeld 950 eines eingehenden RTP-Pakets und dem RTP-Sequenznummernfeld 950 des vorhergehenden RTP-Pakets erreicht. Wenn die Differenz zwischen aufeinander folgenden RTP-Paket-Sequenznummernfelden 950 1 beträgt, ist die Differenz zwischen dem Zeitstempelfeld 952 eines neuen RTP-Pakets und dem Zeitstempelfeld 952 eines früheren RTP-Pakets eine Differenz erster Ordnung, die bei jedem nachfolgenden Paket erscheint, während der Codec und das Quantisierungsintervall konstant bleiben.
  • Durch Beobachtung wurde ermittelt, dass die Differenz erster Ordnung im Zeitstempelfeld 952 des RTP-Pakets bei einem Quantisierungsintervall von 10 Millisekunden bei G711, G726, G738 und G729 die Dezimalzahl 80 ist. Bei einem Quantisierungsintervall von 5 Millisekunden ist die Differenz erster Ordnung im RTP-Paket-Zeitstempelfeld 952 die Dezimalzahl 40.
  • Zuerst sendet das KM 108 einen oder mehrere nicht unterdrückte vollständige Header mit einem Steuerbit, das angibt, dass das CMTS 104 den Header 900 lernen" soll. Sobald der Quantisierungswert bestimmt worden ist, wird der Quantisierungswert dazu verwendet, die korrekte Rekonstruktion des Headers 900 zu verifizieren. Zu diesem Zeitpunkt sendet das KM 108 entweder ein "Lern-Header-" Steuerbit mit einem vollständigen Header, im Falle einer möglicherweise inkorrekten Rekonstruktion des Headers 900, oder einen 5Bit-RTP-Sequenzdeltawert, einen 8Bit-Quantisierungswert und einen wahlfreien 1Byte-IP-Paket-ID-Deltawert anstelle des 54Byte-802.3-/IP-/UDP-/RTP-Headers 900. Bei den Ausführungsformen kann während des Lernprozesses mehr als ein sequenzieller Header mit dem gesetzten Lern-Bit gesendet werden. Dies stellt sicher, dass, falls ein Paket auf der HF-Verbindung verloren geht, das CMTS 104 einen gültigen Template-Header erhält, anhand dessen die Pakete wiederherzustellen sind, sobald das Lern-Bit nicht mehr gesetzt ist.
  • 10 ist ein Diagramm, das ein Steuerwert-Byte 1000 darstellt, das während des Betriebs der RTP-Header-Unterdrückungstechnik verwendet wird. Das Steuerwert-Byte 1000 umfasst ein L-Bit 1002, ein I(1)-Bit 1004, ein I(0)-Bit 1006 und einen 5Bit-V-Wert 1008. Das L-Bit 1002 ist ein Lern-Bit. Das L-Bit 1002 wird gesetzt, wenn das CMTS 104 den Header 900 lernen soll.
  • Moderne IP-Protokollstapel inkrementieren das IP-Paket-ID-Feld 926 häufig entweder um 0x0001 oder 0x0100 zwischen Datagrammen. Die vorliegende Erfindung verwendet einen Zwei-Bit-Flag-Wert, das I(1)-Bit 1004 und das I(0)-Bit 1006, um zu bestimmen, ob das IP-Paket-ID-Feld 926 um 0x0001 oder um 0x0100 inkrementiert oder ob das IP-Paket-ID-Feld 926 durch ein 2Byte-Deltafeld ersetzt werden soll, das durch das KM 108 in Upstream-Richtung gesendet wird. Wenn weder I(1) noch I(0) gesetzt sind, dann wird das IP-Paket-ID-Feld 926 um 0x0001 inkrementiert. Wenn sowohl I(1) als auch I(0) gesetzt sind, dann wird das IP-Paket-ID-Feld 926 nicht inkrementiert. Wenn I(1) nicht gesetzt und I(0) gesetzt ist, dann wird das IP-Paket-ID-Feld 926 um 0x0100 inkrementiert. Wenn I(1) gesetzt und I(0) nicht gesetzt ist, dann wird die Veränderung des IP-Paket-ID-Feldes 926 in einem Zwei-Byte-Deltafeld in Upstream-Richtung gesendet. Die Tabelle 1 stellt die vier Möglichkeiten zum Bestimmen des Wertes des IP-Paket-ID-Feldes 926 dar.
  • Tabelle 1
    Figure 00270001
  • Der Steuerwert (V) 1008 ist ein Fünf-Bit-Wert, der den Deltawert des Sequenznummernfeldes 950 darstellt.
  • 11 ist ein Flussdiagramm 1100 höherer Ebene, das ein Verfahren zur RTP-Header-Unterdrückung darstellt. Die Erfindung ist nicht auf die hierin in Bezug auf das Flussdiagramm 1100 vorgesehene Beschreibung beschränkt. Es wird vielmehr für Fachleute auf dem/den relevanten Gebieten nach dem Studium der hierin angegebenen Lehren ersichtlich sein, dass andere Funktionsflussdiagramme im Schutz umfang der Erfindung enthalten sind. Das Verfahren beginnt mit Schritt 1102, wobei das Verfahren direkt zu Schritt 1104 übergeht.
  • In Schritt 1104 werden die RTP-Header-Unterdrückung betreffende Informationen vom KM 108 an das CMTS 104 übertragen, um eine Rekonstruktion von RTP-Paketen am CMTS 104 zu ermöglichen. Wie vorstehend ausgeführt, kann dies eine Indexzahl umfassen, die die spezifische Art der Paket-Header-Unterdrückungstechnik, die Regeln, die der Unterdrückung und Rekonstruktion eines Pakets gemäß der spezifischen Art der Paket-Header-Unterdrückungstechnik zugeordnet sind, etc. angibt. Das Verfahren geht dann zu Schritt 1106 über.
  • In Schritt 1106 wird ein vollständiges RTP-Paket, wie etwa das RTP-Paket 910, vom KM 108 an das CMTS 104 gesendet, damit es das CMTS 104 lernen kann. Das CMTS 104 speichert den vollständigen Header des RTP-Pakets 910 zur späteren Bezugnahme als Template (Vorlage). Das Verfahren fährt dann mit dem Entscheidungsschritt 1108 fort.
  • Im Entscheidungsschritt 1108 wird bestimmt, ob das CMTS 104 das RTP-Paket 910 gelernt hat. Wenn das CMTS 104 das RTP-Paket 910 nicht gelernt hat, dann kehrt das Verfahren zu Schritt 1106 zurück, in dem ein vollständiges Paket vom KM 108 an das CMTS 104 zum fortgesetzten Lernen gesendet wird.
  • Bezug nehmend nochmals auf Schritt 1108, fährt das Verfahren, wenn bestimmt wird, dass das CMTS 104 das RTP-Paket 910 gelernt hat, mit Schritt 1110 fort. In Schritt 1110 werden nachfolgende Pakete im RTP-Strom vom KM 108 an das CMTS 104 gesendet. Die nachfolgenden Pakete bestehen aus Deltawerten, die Änderungen im RTP-Header 900 darstellen. Somit wird nicht mehr das gesamte RTP-Paket 910 gesendet. Stattdessen werden nur die die Änderungen im RTP-Header 900 repräsentierenden Deltawerte gesendet. Das PDU-Feld 956 wird ebenfalls gesendet. Wenn eine Fehlerbehandlung erwünscht ist, umfassen die nachfolgenden Pakete außerdem ein zusätzliches Byte, das das niedrigere Byte des RTP-Sequenznummernfeldes 940 angibt. Wenn ein Paket aus irgendeinem Grund verloren geht, kann das CMTS 104 den Header-Wiederherstellungsalgorithmus effizient neu synchronisieren, indem die Änderungen des Sequenznummernfeldes 940 und des Zeitstempelfeldes 952 des RTP-Headers 900 bei jedem fehlenden Paket angewandt werden. Somit ermöglicht das Senden des Bytes niedrigerer Ordnung des Paketsequenznummernfeldes 940 die Rekonstruktion verworfener oder verloren gegangener Pakete. Das Verfahren geht dann zum Entscheidungsschritt 1112 über.
  • Im Entscheidungsschritt 1112 wird bestimmt, ob alle RTP-Pakete gesendet worden sind. Wenn nicht alle RTP-Pakete gesendet worden sind, kehrt das Verfahren zum Entscheidungsschritt 1110 zurück, um nachfolgende Pakete im RTP-Strom an das CMTS 104 senden zu können.
  • Bezug nehmend nochmals auf Schritt 1112, geht das Verfahren, wenn bestimmt wird, dass alle RTP-Pakete gesendet worden sind, zu Schritt 1114 über, in dem das Verfahren endet.
  • 12A ist Flussdiagramm, das ein Verfahren zum Unterdrücken eines RTP-Headers unter Verwendung einer RTP-Header-Unterdrückungstechnik gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Die Erfindung ist nicht auf die hierin in Bezug auf das Flussdiagramm 1200 vorgesehene Beschreibung beschränkt. Es wird vielmehr für Fachleute auf dem/den relevanten Gebieten nach dem Studium der hierin angegebenen Lehren ersichtlich sein, dass andere Funktionsflussdiagramme im Schutzumfang der Erfindung enthalten sind. Das Verfahren beginnt mit Schritt 1202, in dem eine RTP-Unterdrückung am Sendeende (d.h. KM 108) gestartet wird. Das Verfahren fährt dann direkt mit Schritt 1204 fort.
  • In Schritt 1204 wird der Deltawert des RTP-Zeitstempelfeldes 952 zwischen zwei aufeinander folgenden RTP-Paketen 900 ermittelt. Der resultierende Wert ist der Zeitstempeldeltawert. Der resultierende Zeitstempeldeltawert wird gleich Temp(0) eingestellt. Es wird darauf hingewiesen, dass Temp(0) während der Initialisierung auf null eingestellt wird. Das Verfahren fährt dann mit Schritt 1206 fort.
  • In Schritt 1206 wird der Deltawert für das Sequenznummernfeld 940 ermittelt. Der resultierende Deltawert wird gleich dem Steuerwert (V) eingestellt. Dies wird durch Bestimmen des Bytes niedriger Ordnung eines neuen Sequenznummernfeldes 950, mit dem eine UND-Verknüpfung mit dem Hex-Wert 7f durchgeführt wird, und durch Bestimmen des Bytes niedriger Ordnung des alten Sequenznummernfeldes 950, mit dem eine UND-Verknüpfung mit dem Hex-Wert 7f durchgeführt wird, erreicht. Der Wert des resultierenden neuen Sequenznummernfeldes 950 wird dann vom resultierenden alten Sequenznummernfeld 950 subtrahiert, um die Deltazahl oder den Wert des Steuerwerts (V) zu erhalten. Das Verfahren geht dann zum Entscheidungsschritt 1208 über.
  • Im Entscheidungsschritt 1208 wird bestimmt, ob eine ordnungsgemäße Rekonstruktion stattfindet. Dies wird durch Multiplizieren des Deltawertes des Sequenznummernfeldes 950, der in Schritt 1206 berechnet wurde, mit dem konstanten Wert des Codec und durch Addieren desselben zum vorherigen Zeitstempelwert erreicht. Wenn dieser Wert nicht gleich dem neuen Zeitstempel ist, dann geht das Verfahren zu Schritt 1210 über.
  • In Schritt 1210 wird das Lern-Bit 1002 des Steuerwerts 1000 gesetzt. Das Verfahren fährt dann mit Schritt 1212 fort.
  • In Schritt 1212 wird Temp(1) gleich dem Steuerwert 1000 eingestellt. Temp(1) enthält nun den Deltawert für das Sequenznummernfeld 950. Das Verfahren geht dann zu Schritt 1214 über.
  • In Schritt 1214 wird ein neuer Puffer zugewiesen und die zwei Bytes aus Temp (der Deltawert für das Zeitstempelfeld 952 und der Steuerwert 1000, der den Deltawert für das Sequenznummernfeld 950 enthält) werden im neuen Puffer gespeichert. Das Verfahren fährt dann mit Schritt 1216 fort.
  • In Schritt 1216 werden der neue Puffer und der ursprüngliche Puffer, der einen vollständigen RTP-Header 910 enthält, an das CMTS 104 gesendet. Somit werden der vollständige RTP-Header 910 zusammen mit dem Deltawert für das Zeitstempelfeld 952 und dem Steuerwert 1000 an das CMTS 104 gesendet. Das Verfahren geht dann zu Schritt 1218 über, in dem das Verfahren endet.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 1208, hat das KM 108, wenn bestimmt wird, dass der berechnete Wert dem neuen Zeitstempelfeld 952 entspricht, den Quantisierungswert ermittelt. Das Verfahren fährt dann mit Schritt 1220 fort.
  • In Schritt 1220 wird der Inkrementwert zum Inkrementieren des IP-Paket-ID-Feldes 926 ermittelt. Die Bits I(1) 1004 und I(0) 1006 des Steuerwerts 1000 werden gemäß dem Inkrementwert des verwendeten IP-Protokollstapels gesetzt. Der Steuerwert wird dann in Temp(1) gespeichert. Das Verfahren geht dann zu Schritt 1222 über.
  • In Schritt 1222 werden die zwei Bytes aus Temp in den ursprünglichen Puffer kopiert. Temp(0) ist der Deltawert für das Zeitstempelfeld 952 oder der Quantisie rungswert. Temp(1) ist der Steuerwert 1000, der den Deltawert für das Sequenznummernfeld 950 enthält. Das Verfahren fährt dann mit Schritt 1224 fort.
  • In Schritt 1224 wird die ursprüngliche Länge abzüglich 52 Bytes, beginnend beim Offset (Versatz) 52 gesendet. Somit werden der Quantisierungswert oder der Deltawert des Zeitstempelfeldes 952, der Steuerwert 1000 und das PDU-Feld 956 an das CMTS 104 gesendet. Das Verfahren geht dann zu Schritt 1218 über, in dem das Verfahren endet.
  • Wie vorstehend erwähnt, inkrementieren moderne IP-Protokollstapel für gewöhnlich das IP-Paket-ID-Feld 926 entweder um 0x0001 oder 0x01000 zwischen Datagrammen. Eine spezielle Regel handhabt bei der vorliegenden Erfindung das Setzen der Steuerbits 1004 und 1006, um den Inkrementwert zu bestimmen. 12B ist ein Flussdiagramm, das ein Verfahren zum Setzen der Inkrementbits I(1) 1004 und I(0) 1006 des Steuerwerts 1000 zum Inkrementieren des IP-Paket-ID-Feldes 926 im RTP-Paket 910 darstellt. Das Verfahren beginnt mit Schritt 1232, wobei das Verfahren direkt zum Entscheidungsschritt 1234 übergeht.
  • Die vorliegende Erfindung umfasst einen Prüfmodus, in dem eine Überprüfung verschiedener Aspekte des Systems durchgeführt werden kann. Wenn gewisse Prüfungen durchgeführt werden, werden die Steuerbits I(1) 1004 und I(0) 1006 entsprechend gesetzt, um ein Inkrement von null bereitzustellen. Im Entscheidungsschritt 1234 wird bestimmt, ob sich das System in einem Prüfmodus befindet. Wenn sich das System in einem Prüfmodus befindet, dann fährt das Verfahren mit Schritt 1236 fort.
  • In Schritt 1236 wird das Steuerwertbit I(1) 1004 auf 1 und das Steuerwertbit I(0) 1006 auf 1 gesetzt. Das Verfahren geht dann zu Schritt 1248 über.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 1234, fährt das Verfahren, wenn bestimmt wird, dass sich das System nicht in einem Prüfmodus befindet, mit Schritt 1238 fort.
  • Im Entscheidungsschritt 1238 wird bestimmt, ob der Wert für das IP-Paket-ID-Feld 926 in Upstream-Richtung gesendet werden soll. Wenn der Wert des IP-Paket-ID-Feldes 926 in Upstream-Richtung gesendet werden soll, geht das Verfahren zu Schritt 1240 über.
  • In Schritt 1240 wird das Steuerwertbit I(1) 1004 auf 1 und das Steuerwertbit I(0) 1006 auf 0 gesetzt. Das Verfahren geht dann zu Schritt 1248 über.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 1238, fährt das Verfahren, wenn der Wert des IP-Paket-ID-Feldes 926 nicht in Upstream-Richtung gesendet werden soll, mit Schritt 1242 fort.
  • Im Entscheidungsschritt 1242 wird bestimmt, ob der IP-Protokollstapel für das IP-Paket-ID-Feld 926 ein Inkrement von 0x0001 benötigt. Wenn der IP-Protokollstapel ein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 benötigt, dann geht das Verfahren zu Schritt 1244 über.
  • In Schritt 1244 wird das Steuerwertbit I(1) 1004 auf 0 und das Steuerwertbit I(0) 1006 auf 0 gesetzt. Das Verfahren geht dann zu Schritt 1248 über.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 1242, fährt das Verfahren, wenn der IP-Protokollstapel kein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 benötigt, mit Schritt 1246 fort.
  • In Schritt 1246 wird für das IP-Paket-ID-Feld 926 ein Inkrement von 0x0100 benötigt. Das Steuerwertbit I(1) 1004 wird auf 0 und das Steuerwertbit I(0) 1006 auf 1 gesetzt. Das Verfahren geht dann zu Schritt 1248 über.
  • In Schritt 1248 endet das Verfahren.
  • 13 ist ein Flussdiagramm 1300, das ein Verfahren zum Rekonstruieren eines unterdrückten RTP-Pakets gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Die Erfindung ist nicht auf die hierin in Bezug auf das Flussdiagramm 1300 vorgesehene Beschreibung beschränkt. Es wird vielmehr für Fachleute auf dem/den relevanten Gebieten nach dem Studium der hierin angegebenen Lehren ersichtlich sein, dass andere Funktionsflussdiagramme im Schutzumfang der Erfindung enthalten sind. Das Verfahren beginnt mit Schritt 1302, in dem eine Rekonstruktion gestartet wird. Das Verfahren fährt dann mit Schritt 1304 fort.
  • In Schritt 1304 wird ein 54Byte-Header gelesen. Das Verfahren geht dann zu Schritt 1306 über.
  • In Schritt 1306 wird der 1 Byte-Steuerwert 1000 aus dem Eingangsstrom gelesen. Das Verfahren fährt dann mit dem Entscheidungsschritt 1308 fort.
  • Im Entscheidungsschritt 1308 wird bestimmt, ob das Lern-Bit 1002 des Steuerwerts 1000 gesetzt ist. Wenn bestimmt wird, dass das Lern-Bit 1002 gesetzt ist, dann muss der Header 900 vom CMTS 104 gelernt werden. Das Verfahren geht dann zu Schritt 1310 über.
  • In Schritt 1310 wird ein zweiter 1 Byte-Wert aus dem Eingangsstrom gelesen. Dieser zweite 1 Byte-Wert wird verworfen. Das Verfahren fährt dann mit Schritt 1312 fort.
  • In Schritt 1312 wird der aktuelle 54Byte-Header, der in Schritt 1304 gelesen wurde, verworfen. Das CMTS 104 verwirft diese Daten, da dieser 54Byte-Header durch den Nutzlast-Header-Unterdrückungsmechanismus der Hardware am Ende des Rekonstruktionsverfahrens erzeugt worden ist, was nachfolgend unter Bezugnahme auf den Schritt 1318 beschrieben ist. Wenn der Nutzlast-Header-Unterdrückungsmechanismus der Hardware diesen 54Byte-Header einspeist, wird der 54Byte-Header vor dem Steuerwert 1000 platziert. Daher wird, wenn das Lern-Bit 1002 gesetzt ist, dieser 54Byte-Header als Müll betrachtet und muss verworfen werden. Aus Sicht des KM 108 war das Gesendete ein Unterdrückungsindex. Der Empfang des Unterdrückungsindex durch das CMTS 104 hat bewirkt, dass das CMTS 104 54 Bytes inkorrekter Daten in den Datenstrom einspeist. Das Verfahren geht dann zu Schritt 1314 über.
  • In Schritt 1314 wird der vom KM 108 gesendete korrekte 54Byte-Header aus dem Eingangsstrom gelesen. Das Verfahren fährt dann mit Schritt 1316 fort.
  • In Schritt 1316 wird der 54Byte-Header in einen Template-Header kopiert und der 54Byte-Header, auf den die Daten vom PDU-Feld 956 folgen, wird gesendet. Das Verfahren dann geht zu Schritt 1318 über, in dem das Verfahren endet.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 1308 fährt das Verfahren, wenn bestimmt wird, dass das Lern-Bit 1002 des Steuerwerts 1000 nicht gesetzt ist, mit Schritt 1320 fort.
  • In Schritt 1320 wird der zweite 1 Byte-Wert aus dem Eingangsstrom gelesen und in einem Byte niedriger Ordnung eines lokalen variabel benannten DELTA-Werts platziert. DELTA ist ein 32 Bit langes Wort. DELTA wird zu Beginn des RTP-Delta- Rekonstruktionsverfahrens 1300 auf null vorinitialisiert. Das Verfahren geht dann zu Schritt 1322 über.
  • Der Schritt 1322 beginnt das Verfahren zum Bestimmen, ob das IP-Paket-ID-Feld 926 wie in Tabelle 1 dargelegt inkrementiert werden soll. In Schritt 1322 wird bestimmt, ob I(1) 1004 des Steuerwerts 1000 gesetzt ist. Wenn I(1) 1004 des Steuerwerts 1000 nicht gesetzt ist, dann fährt das Verfahren dann mit Schritt 1324 fort.
  • In Schritt 1324 wird bestimmt, ob I(0) 1006 des Steuerwerts 1000 gesetzt ist. Wenn I(0) nicht gesetzt ist, dann fährt das Verfahren dann mit Schritt 1326 fort.
  • In Schritt 1326 wird ein lokales variabel benanntes INKR zum Inkrementieren des IP-Paket-ID-Feldes 926 auf 0x0001 gesetzt. Es wird darauf hingewiesen, dass das lokale variable INKR ein 16Bit-Wert ohne Vorzeichen ist. Das INKR wird in Schritt 1302 auf null vorinitialisiert. Das Verfahren geht dann zu Schritt 1334 über.
  • Bezug nehmend nochmals auf Schritt 1324, fährt das Verfahren, wenn I(0) gesetzt ist, mit Schritt 1328 fort. In Schritt 1328 wird das lokale variable INKR zum Inkrementieren des IP-Paket-ID-Feldes 926 auf 0x100 gesetzt. Das Verfahren geht dann zu Schritt 1334 über.
  • Bezug nehmend nochmals auf Schritt 1322, fährt das Verfahren, wenn I(1) gesetzt ist, mit Schritt 1330 fort. In Schritt 1330 wird bestimmt, ob I(0) 1006 des Steuerwerts 1000 gesetzt ist. Wenn I(0) gesetzt ist, dann geht das Verfahren zu Schritt 1334 über.
  • Bezug nehmend nochmals auf Schritt 1330, fährt das Verfahren, wenn I(0) nicht gesetzt ist, mit Schritt 1332 fort. In Schritt 1332 wird die Änderung im IP-Paket-ID-Feld 926 vom KM 108 in Upstream-Richtung gesendet. Ein Zwei-Byte-Wert ohne Vorzeichen wird aus dem Eingangsstrom eingelesen und am Offset 18 des rekonstruierten Datenpakets platziert. Der Offset 18 des rekonstruierten Datenpakets ist das IP-Paket-ID-Feld 926. Das Verfahren geht dann zu Schritt 1334 über.
  • Die Schritte 1334 bis 1340 stellen sämtliche Aktualisierungen des IP-Paket-ID-Feldes 926, des RTP-Sequenznummernfeldes 950 und des RTP-Zeitstempelfeldes 952 zur Rekonstruktion des RTP-Pakets 910 bereit. In Schritt 1334 wird bestimmt, ob die Bits 4–0 des Bytes am Offset 45 (Bits niedriger Ordnung des Sequenznummernfeldes 950) des RTP-Pakets 910 gleich V 1008 im Steuerwert 1000 sind. Wenn bestimmt wird, dass die Bits 4–0 des Bytes am Offset 45 (Bits niedriger Ordnung des Sequenznummernfeldes 950) des RTP-Pakets 910 gleich V 1008 im Steuerwert 1000 sind, dann fährt das Verfahren mit Schritt 1342 fort.
  • In Schritt 1342 wird eine neue IP-Header-Prüfsumme ermittelt und am Offset 24 (IP-Header-Prüfsummenfeld 934) platziert. Das IP-Header-Prüfsummenfeld 934 ist das 16Bit-Einerkomplement der Einerkomplementsumme aller 16Bit-Worte im Header 900. Zur Berechnung der Prüfsumme beträgt der Wert des Prüfsummenfeldes null.
  • Bezug nehmend nochmals auf Schritt 1334 geht das Verfahren, wenn bestimmt wird, dass die Bits 4–0 des Bytes am Offset 45 (Bits niedriger Ordnung des Sequenznummernfeldes 950) des RTP-Pakets 910 nicht gleich V 1008 im Steuerwert 1000 sind, zu Schritt 1336 über.
  • In Schritt 1336 wird der Wert eins zu dem Wort am Offset 44 des RTP-Pakets 910 addiert, welcher das RTP-Sequenznummernfeld 950 ist. Das Verfahren fährt dann mit Schritt 1338 fort.
  • In Schritt 1338 wird das Wort am Offset 18 des RTP-Pakets 910, welcher das IP-Paket-ID-Feld 926 ist, durch das lokale variable INKR inkrementiert. Das Verfahren geht dann zu Schritt 1340 über.
  • In Schritt 1340 wird das Wort am Offset 46 des RTP-Pakets 910, welcher das RTP-Zeitstempelfeld 952 ist, durch den lokalen variablen DELTA-Wert inkrementiert. Das Verfahren kehrt dann zu Schritt 1334 zurück, um zu bestimmen, ob der Steuerwert (V) 1008 mit den fünf Bits niedriger Ordnung im Sequenznummernfeld 950 des RTP-Pakets 910 übereinstimmt. Die Schritte 1334 bis 1340 werden wiederholt bis diese Zahlen gleich sind. Wenn diese Zahlen gleich sind, fährt das Verfahren, wie vorstehend beschrieben, mit Schritt 1342 fort.
  • 4. Dynamisches Delta-Codierungsschema
  • Wie vorstehend ausgeführt, sieht die Erfindung eine Optimierung der Übertragung von TCP-/IP- (Internet-Protokoll) Verkehr quer durch ein DOCSIS-Netzwerk vor. Die erfindungsgemäße Unterdrückungstechnik ist feldorientiert statt byteorientiert. Viele Felder in einem TCP-Protokoll-Header ändern sich nicht zwischen Paketen in demselben TCP-Verbindungsstrom. Diese redundanten Informationen werden einmal gesendet und in nachfolgenden Paketen unterdrückt. Andere Felder im TCP- Protokoll-Header verändern sich in vorhersagbarer Art und Weise. Diese Felder werden nicht in ihrer Gesamtheit gesendet. Stattdessen wird ein kleinerer deltacodierter Wert gesendet, der die Wertänderung eines jeden Felds von einem Paket zum nächsten repräsentiert. Die deltacodierten Werte für 32Bit-Felder werden immer als 16Bit-Zahl dargestellt. Diese Technik verringert die zum Senden veränderlicher Felder erforderliche Bandbreite um 50 % und stellt somit einen hohen Effizienzgewinn bei der TCP-Bestätigungs- (ACK – Acknowledgement) Übertragung bereit.
  • DOCSIS-Kabelmodems können eine Abgabe von Paketen auf jedem IP-Strom in der richtigen Reihenfolge sicherstellen. Diese garantierte Reihenfolge der Abgabe ermöglicht die Verwendung von deltacodierten Feldern zum Aktualisieren sämtlicher veränderlicher Felder in einem 802.3-/IP-/TCP-Protokoll-Header.
  • Bevor das dynamische Delta-Codierungsschema zur TCP-Header-Unterdrückung beschrieben wird, wird anhand 14A ein herkömmlicher 802.3-/IP-/TCP-Protokoll-Header 1400 zur TCP-/IP-Übertragung beschrieben. Der Protokoll-Header 1400 umfasst einen 14Byte-802.3-Header 1402, einen 20Byte-IP-Header 1404 und einen 20Byte-TCP-Header 1406. Bei diesem Beispiel erzeugt der 802.3-/IP-/TCP-Header 1400 einen 54Byte-Header zur TCP-/IP-Übertragung.
  • 14B ist ein Diagramm eines TCP-Protokollpakets 1410. Das TCP-Protokollpaket 1410 umfasst unter anderem ein Ziel-MAC-Adressenfeld 1412, ein Quellen-MAC-Adressenfeld 1414, ein Typ-/Längenfeld 1416, ein Protokollversionsfeld 1418, ein Header-Längenfeld 1420, ein Type-of-Service-Feld 1422, ein Gesamtlängenfeld 1424, ein Paket-ID-Feld 1426, ein Fragment-Offset-Feld 1428, ein Time-to-Live-Feld 1430, ein Protokollfeld 1432, ein Header-Prüfsummenfeld 1434, ein Quellen-IP-Adressenfeld 1436, ein Ziel-IP-Adressenfeld 1438, ein Quellenportfeld 1440, ein Zielportfeld 1442, ein Sequenznummernfeld (SEQ) 1446, ein Bestätigungsnummernfeld (ACK) 1448, ein Daten-Offset-Feld 1450, ein Flags-Feld 1452, ein Fensterfeld (WIN) 1454, ein Prüfsummenfeld 1456, ein Dringlichkeitszeigerfeld (Urgent-Pointer-Feld) 1458, ein PDU-Feld 1460 und ein CRC-32-Feld 1462. TCP-Protokollpakete sind auf dem/den relevanten Gebieten wohlbekannt, weshalb nicht jedes einzelne Feld genau beschrieben wird.
  • Die meisten Felder im TCP-Protokollpaket 1410 ändern sich zwischen Paketen in demselben TCP-Verbindungsstrom nicht. Im TCP-Protokollpaket 1410 kann der gesamte Header 1402 und der Großteil des Headers 1404 unterdrückt werden, sobald der Empfänger die redundanten oder unveränderlichen Felder gelernt hat.
  • Viele der Felder im TCP-Header 1406 ändern sich zwischen Paketen in demselben TCP-Verbindungsstrom. Durch die vorliegende Erfindung werden diese Felder nicht in ihrer Gesamtheit gesendet. Stattdessen wird ein kleinerer deltacodierter Wert gesendet. Der deltacodierte Wert stellt die Wertänderung eines jeden Feldes von einem Paket zum nächsten dar.
  • 15 ist ein Diagramm, das die Felder zeigt, die sich im TCP-Protokollpaket 1410 von Paket zu Paket verändern. Die Felder, die sich von Paket zu Paket ändern, sind hervorgehoben. Die sich verändernden Felder umfassen das Paket-ID-Feld 1426 aus dem IP-Header 1404 und das Sequenznummernfeld 1446, das Bestätigungsnummernfeld 1448, das Daten-Offset-Feld 1450, das Fensterfeld 1454, das Prüfsummenfeld 1456 und das Dringlichkeitszeigerfeld 1458 aus dem TCP-Header 1406.
  • Die Erfindung ermöglicht die Abgabe von Paketen auf der Upstream-DOCSIS-HF-Verbindung in der richtigen Reihenfolge. Die Erfindung unterdrückt den 802.3-/IP-/TCP-Header 1400 am KM 108 und stellt sicher, dass der Header 1400 durch das CMTS 104 in seinem ursprünglichen Format wiederhergestellt wird. Die 16A und 16B sehen eine Beschreibung des erfindungsgemäßen deltacodierten Unterdrückungs- bzw. Rekonstruktionsverfahrens vor.
  • 16A ist ein Flussdiagramm 1600 höherer Ebene, das ein Verfahren für eine Delta-Codierung-Unterdrückungstechnik darstellt. Die Erfindung ist nicht auf die hierin in Bezug auf das Flussdiagramm 1600 vorgesehene Beschreibung beschränkt. Es wird vielmehr für Fachleute auf dem/den relevanten Gebieten nach dem Studium der hierin angegebenen Lehren ersichtlich sein, dass andere Funktionsflussdiagramme im Schutzumfang der Erfindung enthalten sind. Das Verfahren beginnt mit Schritt 1601 und geht sofort zu Schritt 1602 über.
  • In Schritt 1602 werden die deltacodierte TCP-Header-Unterdrückung betreffende Information vom KM 108 an das CMTS 104 übertragen, um eine Rekonstruktion von TCP-Paketen am CMTS 104 zu ermöglichen. Wie vorstehend besprochen, kann dies eine Indexzahl umfassen, die die spezifische Art der Paket-Header-Unterdrückungstechnik, die der Unterdrückung und Rekonstruktion eines Pakets gemäß der spezifischen Art der Paket-Header-Unterdrückungstechnik zugeordneten Regeln, etc. angibt. Das KM 108 wählt den Unterstützungsindex und somit die Unterdrückungstechnik. Dies vermeidet die Notwendigkeit einer Zwei-Wege-Befehlstransaktion während schnellen Datenübertragungen. Das Verfahren fährt dann mit Schritt 1603 fort.
  • In Schritt 1603 wird ein einzelner TCP-Verbindungsstrom identifiziert. Ein Framing-Protokoll wird dazu verwendet, jeden TCP-Verbindungsstrom anhand einer einzelnen DOCSIS-SID zu trennen und zu identifizieren. Nach dem Identifizieren des TCP-Verbindungsstroms, geht das Verfahren zu Schritt 1604 über.
  • In Schritt 1604 wird ein erstes TCP-Protokollpaket 1410 in einem TCP-Verbindungsstrom in seiner Gesamtheit an einen Empfänger gesendet. Das erste TCP-Protokollpaket 1410 umfasst einen Lern-Indikator. Der Indikator weist den Empfänger an, den vollständigen Header zu lernen. Der vollständige Protokoll-Header 1400 kann gelernt werden, ohne eine Bestätigung von einem Empfänger, wie etwa dem CMTS 104, zu benötigen. Dies ermöglicht ein Lernen der Header in Echtzeit. Sobald der Header gelernt worden ist, können nachfolgende Pakete in einem komprimierten Format gesendet werden. Die maximale Effizienz wird erreicht, indem zugelassen wird, dass unmittelbar auf einen nicht unterdrückten (gelernten) Header ein unterdrückter Header folgt. Dies beseitigt die durch den DOCSIS-Ansatz verursachte Verzögerung, wobei auf eine gelernte Bestätigung vom Empfänger gewartet werden muss. Das Verfahren geht dann zu Schritt 1606 über.
  • In Schritt 1606 wird das nächste Paket im TCP-Verbindungsstrom abgerufen. Das Verfahren fährt dann mit Schritt 1608 fort.
  • In Schritt 1608 werden die Felder identifiziert, die sich gegenüber dem zuvor gesendeten Paket verändert haben, und es wird ein deltacodierter Wert bestimmt, der diese Änderung repräsentiert. Das Verfahren geht dann zu Schritt 1610 über.
  • In Schritt 1610 wird ein Bit-Mapped-Flag erzeugt. Das Bit-Mapped-Flag gibt an, welche der möglichen deltacodierten IP-/TCP-Feldwerte zwischen einem Änderungsbyte und dem Datenbereich des komprimierten TCP-Protokollpakets vorhanden sind. Das Änderungsbyte ist ein 1 Byte-Bit-Mapped-Flag-Feld zur Angabe welche Felder im Protokoll-Header 1400 sich geändert haben. Das Änderungsbyte wird nachstehend unter Bezugnahme auf 17 genauer beschrieben. Das Verfahren fährt dann mit Schritt 1612 fort.
  • In Schritt 1612 wird das komprimierte TCP-Protokollpaket erzeugt und das Bit-Mapped-Flag vorne an das komprimierte TCP-Paket angehängt. Das Verfahren geht dann zu Schritt 1614 über.
  • In Schritt 1614 wird das komprimierte TCP-Protokollpaket an den Empfänger gesendet. Das Verfahren fährt dann mit Schritt 1616 fort.
  • Im Entscheidungsschritt 1616 wird bestimmt, ob im TCP-Verbindungsstrom noch weitere zu sendende TCP-Protokollpakete 1410 vorhanden sind. Wenn noch weitere zu sendende Pakete vorhanden sind, dann kehrt das Verfahren zu Schritt 1606 zurück, um das nächste Paket abzurufen.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 1616, kehrt das Verfahren, wenn im TCP-Verbindungsstrom keine weiteren zu sendenden Pakete mehr vorhanden sind, zu Schritt 1603 zurück, in dem ein anderer TCP-Verbindungsstrom identifiziert wird.
  • 16B ist ein Flussdiagramm 1620 höherer Ebene, das ein Verfahren für eine deltacodierte Header-Rekonstruktionstechnik darstellt. Die Erfindung ist nicht auf die hierin in Bezug auf das Flussdiagramm 1620 vorgesehene Beschreibung beschränkt. Es wird vielmehr für Fachleute auf dem/den relevanten Gebieten nach dem Studium der hierin angegebenen Lehren ersichtlich sein, dass andere Funktionsflussdiagramme im Schutzumfang der Erfindung enthalten sind. Das Verfahren beginnt mit Schritt 1622, wobei das Verfahren sofort zu Schritt 1624 übergeht.
  • In Schritt 1624 wird ein TCP-Protokollpaket 1410 von einem TCP-Verbindungsstrom abgerufen. Das Verfahren fährt dann mit dem Entscheidungsschritt 1626 fort.
  • Im Entscheidungsschritt 1626 wird bestimmt, ob das abgerufene TCP-Protokollpaket 1410 gelernt werden soll. Dies wird durch Bestimmen, ob das Indikator-Lern-Bit gesetzt ist, erreicht. Wenn das Indikator-Lern-Bit gesetzt ist, geht das Verfahren zu Schritt 1628 über.
  • In Schritt 1628 lernt der Empfänger den aktuellen TCP-Protokoll-Header des Pakets 1410 und speichert das Paket 1410 zur späteren Bezugnahme als Header-Template. Das Verfahren geht dann zu Schritt 1624 über, um ein weiteres Paket abzurufen.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 1626 fährt das Verfahren, wenn das Indikator-Lern-Bit nicht gesetzt ist, mit Schritt 1630 fort.
  • In Schritt 1630 werden das Änderungsbyte und die entsprechenden deltacodierten Werte gelesen. Das Verfahren geht dann zu Schritt 1632 über.
  • In Schritt 1632 wird der Header wiederhergestellt. Die TCP-/IP-Header-Flags werden aktualisiert und die deltacodierten Werte dazu verwendet, die veränderten Felder in einem gespeicherten Header-Template zu aktualisieren. Das Verfahren fährt dann mit Schritt 1634 fort.
  • In Schritt 1634 wird der vollständig wiederhergestellte Header vor sämtlichen empfangenen Daten aus dem in Schritt 1624 abgerufenen TCP-Protokollpaket platziert. An diesem Punkt wird das Paket vollständig in seinem ursprünglichen Format wiederhergestellt und kann über ein IP-Netz gesendet werden. Das Verfahren kehrt dann zu Schritt 1624 zurück, in dem ein anderes TCP-Protokollpaket abgerufen wird.
  • 17 ist ein Diagramm, das das Änderungsbyte 1700 darstellt, das beim Ausführen der deltacodierten Header-Unterdrückungstechnik verwendet wird. Das Änderungsbyte 1700 ist ein 1 Byte-Bit-Mapped-Flag-Feld zur Angabe, welche Felder des Protokoll-Headers 1400 sich verändert haben. Das Änderungsbyte 1700 gibt außerdem an, ob der Header 1400 am Empfangsende gelernt werden soll oder nicht. Das Änderungsbyte 1700 gibt ferner an, ob das IP-Paket-ID-Feld 1426 inkrementiert werden soll sowie den Betrag, um den das IP-Paket-ID-Feld 1426 inkrementiert werden soll. Das Änderungsbyte 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.
  • Das L-Bit 1702 gibt an, wenn es gesetzt ist, dass der Rest des Änderungsbytes ignoriert werden kann und dass ein kompletter 54Byte-802.3-/IP-/TCP-Header 1400 im Burst enthalten ist und dazu verwendet werden sollte, den aktuellen Template-Header zu ersetzen.
  • Das I(1)-Bit 1704 und I(0)-Bit 1706 werden dazu verwendet, die Änderung des IP-Paket-ID-Feldes 1426 in ähnlicher Weise wie vorstehend in Tabelle 1 angegeben zu bestimmen. Das I(1)-Bit 1704 gibt an, wenn es gesetzt ist, dass der nächste Wert im Datenstrom ein 2Byte-Wert ist, der in das IP-Paket-ID-Feld 1426 des Template-Headers kopiert werden soll. Das Ergebnis sollte in den Template-Header zurückgeschrieben und gesendet werden. Wenn das I(1)-Bit 1704 gelöscht ist, muss das I(0)-Bit 1706 überprüft werden, um zu bestimmen, wie das IP-Paket-ID-Feld 1426 inkrementiert werden soll. Das I(0)-Bit 1706 gibt an, wenn es gesetzt ist, dass 0x0100 zum Template-Header-IP-Paket-ID-Feld 1426 addiert, in den Template-Header zurückgeschrieben und gesendet werden sollte. Wenn das I(0)-Bit 1706 gelöscht ist, gibt dies an, dass das Template-Header-IP-Paket-ID-Feld 1426 um 0x0001 inkrementiert, in den Template-Header zurückgeschrieben und gesendet werden sollte. Das I(1)-Bit 1704 und das I(0)-Bit 1706 werden basierend auf dem Betrieb moderner IP-Protokollstapel und der Art und Weise, in der diese inkrementiert werden, bestimmt, wie vorstehend beschrieben.
  • Das S-Bit 1708 gibt an, wenn es gesetzt ist, dass der nächste Wert im Datenstrom ein 2Byte-Wert ist, der zum 4Byte-TCP-Sequenznummernfeld 1446 des Template-Headers addiert werden soll. Das Ergebnis sollte in den Template-Header zurückgeschrieben und gesendet werden. Wenn das S-Bit 1708 gelöscht ist, sollte das TCP-Sequenznummernfeld 1446 des Template-Headers so verwendet werden wie es ist.
  • Wenn das A-Bit 1710 gesetzt ist, ist der nächste Wert im Datenstrom ein 2Byte-Wert, der zu dem 4Byte-TCP-Bestätigungsnummernfeld 1448 des Template-Headers addiert werden sollte. Das Ergebnis sollte in den Template-Header zurückgeschrieben und gesendet werden. Wenn das A-Bit 1710 gelöscht ist, sollte das TCP-Bestätigungsnummernfeld 1448 des Template-Headers so verwendet werden wie es ist.
  • Das P-Bit 1712 gibt an, wenn es gesetzt ist, dass das PUSH-Bit (nicht gezeigt) eines Halbbytes (Nibble) des TCP-Flags-Feldes 1452 gesetzt und gesendet werden sollte. Wenn das P-Bit 1712 gelöscht ist, sollte das PUSH-Bit eines Halbbytes des TCP-Flags-Feld 1452 gelöscht und gesendet werden.
  • Wenn das W-Bit 1714 gesetzt ist, ist der nächste Wert im Datenstrom ein 2Byte-Wert, der in das TCP-Fensterfeld 1454 des Template-Headers kopiert werden soll. Das Ergebnis sollte in den Template-Header zurückgeschrieben und gesendet werden. Wenn das W-Bit 1714 gelöscht ist, sollte das TCP-Fensterfeld 1454 des Template-Headers so verwendet werden wie es ist.
  • Wenn das U-Bit 1716 gesetzt ist, ist der nächste Wert im Datenstrom ein 2Byte-Wert, der in das TCP-Dringlichkeitszeigerfeld 1458 des Template-Headers kopiert werden soll. Das Ergebnis sollte in den Template-Header zurückgeschrieben und gesendet werden. Wenn das U-Bit 1716 gelöscht ist, sollte das TCP-Dringlichkeitszeigerfeld 1458 des Template-Headers so verwendet werden wie es ist.
  • Basierend auf den Feldern, die sich tatsächlich gegenüber den zuvor gesendeten Werten verändern, findet eine von zwei Aktionen statt. Das TCP-Protokollpaket 1410 kann ohne jedwede Unterdrückung gesendet werden oder das TCP-Protokollpaket 1410 kann an das Änderungsbyte 1700 angehängt werden und entweder ein komplettes TCP-Protokollpaket 1410 oder zwei oder mehr Felder anstelle des 54Byte-802.3/IP-/TCP-Headers 1400 umfassen. Die zwei oder mehr Felder, die den 802.3-/IP-/TCP-Header 1400 ersetzen, umfassen: (1) einen tatsächlichen Wert des IP-Paket-ID-Feldes 1426 (der nur gesendet wird, wenn die IP-Paket-ID nicht um 0x0001 oder 0x0100 inkrementiert wurde), (2) einen deltacodierten Wert des TCP-Sequenznummernfeldes 1446 (der nur gesendet wird, wenn die deltacodierte TCP-Sequenznummer ≠ 0), (3) einen deltacodierten Wert des TCP-Bestätigungsnummernfeldes 1448 (der nur gesendet wird, wenn die deltacodierte TCP-Bestätigungsnummer ≠ 0), (4) ein Datenbyte des TCP-Daten-Offset-Feldes 1450, (5) einen tatsächlichen Wert des TCP-Fensterfeldes 1454 (der nur gesendet wird, wenn ein Deltawert des TCP-Fensterfeldes 1454 ≠ 0), (6) einen tatsächlichen Wert des TCP-Header-Prüfsummenfeldes 1456 und (7) einen tatsächlichen Wert des TCP-Dringlichkeitszeigerfeldes 1458 (der nur gesendet wird, wenn das IP-Dringlichkeits-Flag gesetzt ist). Die Erfindung verwendet daher einen Framing-Mechanismus, der komprimierte, unkomprimierte und nicht IP-artigen Verkehr in einer einzelnen DOCSIS-SID kombiniert.
  • Traditionelle Internet-TCP-/IP-Header-Unterdrückungsprotokolle verwenden ein Delta-Codierungsschema variabler Länge, um veränderliche Felder darzustellen. Die vorliegende Technik ist im Hinblick auf die Charakteristika von Hochgeschwindigkeits-TCP-/IP-Netzen optimiert. Bei solchen Netzen werden die veränderlichen TCP-Felder (d.h. ACK, SEQ, WIN) typischerweise um mehr als 225 Einheiten inkrementiert. Das Codieren dieser Änderungen mit einem festen 2Byte-Deltafeld optimiert ein typisches Hochgeschwindigkeitsnetz und reduziert die für jedes gesendete TCP-Protokollpaket 1410 erforderliche Verarbeitung.
  • 18 ist ein Diagramm, das einen endgültigen codierten Datenstrom 1800 darstellt, der an einen Empfänger (d.h. das CMTS 104) gesendet wird, wenn das L-Bit 1702 nicht gesetzt ist. 18 stellt eine erste Zeile 1802 für jedes Feld im endgültigen codierten Datenstrom 1800 und eine zweite Zeile 1804 dar, die die Anzahl der Bytes angibt, die jedem Feld im endgültigen codierten Datenstrom 1800 entsprechen.
  • Ein erstes Feld 1806 ist das Änderungsbyte 1700. Wie vorstehend angegeben, umfasst das Änderungsbyte 1700 1 Byte 1806.
  • Ein zweites Feld 1808 ist ein deltacodierter Wert für das IP-Paket-ID-Feld 1426. Der deltacodierte Wert 1808 für das IP-Paket-ID-Feld 1426 kann entweder aus 0 oder 2 Datenbytes (1809) bestehen, abhängig davon, ob ein Wert in den Template-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll oder ob der Wert des IP-Paket-ID-Feldes 1426 entweder um 0x0001 oder 0x0100 inkrementiert werden soll. Wenn ein Wert in den Template-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll, dann enthält der endgültige codierte Datenstrom 1800 2 Bytes für das IP-Paket-ID-Feld 1426. Wenn kein Wert in den Template-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll, dann enthält der endgültige codierte Datenstrom 1800 keine Bytes für das IP-Paket-ID-Feld 1426. Stattdessen wird ein Inkrementwert für das IP-Paket-ID-Feld 1426 unter Verwendung der Bits I(1) 1704 und I(0) 1706 des Änderungsbytes 1700 bestimmt.
  • Ein drittes Feld 1810 ist ein deltacodierter Wert für das TCP-Sequenznummernfeld 1446. Der deltacodierte Wert 1810 für das TCP-Sequenznummernfeld 1446 kann entweder aus 0 oder 2 Datenbytes (1811) bestehen, abhängig davon, ob im TCP-Sequenznummernfeld 1446 eine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat. Wenn im TCP-Sequenznummernfeld 1446 eine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat, wird das S-Bit 1708 des Änderungsbytes 1700 gesetzt und der endgültige codierte Datenstrom 1800 enthält 2 Datenbytes zum Aktualisieren des TCP-Sequenznummernfeldes 1446 im Template-Header. Wenn im TCP-Sequenznummernfeld 1446 keine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat, wird das S-Bit 1708 des Änderungsbytes 1700 nicht gesetzt und der endgültige codierte Datenstrom 1800 enthält keine Bytes für das TCP-Sequenznummernfeld 1446.
  • Ein viertes Feld 1812 ist ein deltacodierter Wert für das TCP-Bestätigungsnummernfeld 1448. Der deltacodierte Wert 1812 für das TCP-Bestätigungsnummernfeld 1448 kann entweder aus 0 oder 2 Datenbytes (1813) bestehen, abhängig davon, ob im TCP-Bestätigungsnummernfeld 1448 eine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat. Wenn im TCP-Bestätigungsnummernfeld 1448 eine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat, wird das A-Bit 1710 des Änderungsbytes 1700 gesetzt und der endgültige codierte Datenstrom 1800 enthält 2 Datenbytes zum Aktualisieren des TCP-Bestätigungsnummernfeldes 1448 im Template-Header. Wenn im Sequenznummernfeld 1446 keine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat, wird das A-Bit 1710 des Änderungsbytes 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 für das TCP-Daten-Offset-Feld 1450 ist vorhanden. Ein Wert für das TCP-Daten-Offset-Feld 1450 besteht aus einem 1 Datenbyte (1815), das in den endgültigen codierten Datenstrom 1800 einzusetzen ist.
  • Ein sechstes Feld 1816 für das TCP-Fensterfeld 1454 ist vorhanden. Ein Wert für das TCP-Fensterfeld 1454 kann aus 0 oder 2 Datenbytes (1817) bestehen, abhängig davon, ob im TCP-Fensterfeld 1454 eine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat. Wenn im TCP-Fensterfeld 1454 eine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat, wird das W-Bit 1714 des Änderungsbytes 1700 gesetzt und der endgültige codierte Datenstrom 1800 enthält 2 Datenbytes zum Aktualisieren des TCP-Fensterfeldes 1454 im Template-Header. Wenn im TCP-Fensterfeld 1454 keine Änderung gegenüber dem zuvor gesendeten Wert stattgefunden hat, wird das W-Bit 1714 des Änderungsbytes 1700 nicht gesetzt und der endgültige codierte Datenstrom 1800 enthält keine Bytes für das TCP-Fensterfeld 1454.
  • Ein siebtes Feld 1818 für das TCP-Prüfsummenfeld 1456 ist vorhanden. Ein Wert für das TCP-Prüfsummenfeld 1456 besteht aus 2 Datenbytes (1819), die in den endgültigen codierten Datenstrom 1800 einzusetzen sind.
  • Ein achtes Feld 1820 für das TCP-Dringlichkeitszeigerfeld 1458 ist vorhanden. Ein Wert für das TCP-Dringlichkeitszeigerfeld 1458 kann aus 0 oder 2 Datenbytes (1821) bestehen, abhängig davon, ob im TCP-Flags-Feld 1452 ein IP-Dringlichkeits-Flag gesetzt ist. Wenn im TCP-Flags-Feld 1452 ein IP-Dringlichkeits-Flag gesetzt ist, wird das U-Bit 1716 des Änderungsbytes 1700 gesetzt und der endgültige codierte Datenstrom 1800 enthält 2 Datenbytes, die in den Template-Header zu kopieren sind. Wenn im TCP-Flags-Feld 1452 kein IP-Dringlichkeits-Flag gesetzt ist, wird das U-Bit 1716 des Änderungsbytes 1700 nicht gesetzt und der endgültige codierte Datenstrom 1800 enthält keine Bytes für das TCP-Dringlichkeitszeigerfeld 1458.
  • Ein neuntes Feld 1822 für das TCP-PDU-Feld 1460 ist vorhanden. Das TCP-PDU-Feld kann aus 0-n Bytes (1823) bestehen.
  • 19 ist ein Diagramm, das einen Sendebefehl 1900 für einen endgültigen codierten Datenstrom 1800 zeigt, wenn das L-Bit 1702 nicht gesetzt ist. Der Sendebefehl 1900 beginnt mit dem Änderungsbyte 1700. Die Felder 1808, 1810, 1812, 1814, 1816, 1818, 1820 und 1822 folgen.
  • 20 ist ein Diagramm, das einen Sendebefehl 2000 zeigt, wenn das L-Bit 1702 gesetzt ist. Dies gibt an, dass die gesendeten Header-Informationen vom Empfänger gelernt werden sollen. Der Sendebefehl 2000 besteht aus dem Änderungsbyte 1700, einem Pad 2002, einem 54Byte-TCP-Protokoll-Header 1410 und einem PDU-Feld 1460.
  • 21 ist ein Flussdiagramm 2100, das ein Verfahren zur TCP-Header-Unterdrückung darstellt. Die Erfindung ist nicht auf die hierin in Bezug auf das Flussdiagramm 2100 vorgesehene Beschreibung beschränkt. Es wird vielmehr für Fachleute auf dem/den relevanten Gebieten nach dem Studium der hierin angegebenen Lehren ersichtlich sein, dass andere Funktionsflussdiagramme im Schutzumfang der vorliegenden Erfindung enthalten sind. Das Verfahren beginnt mit Schritt 2102, in dem eine TCP-Unterdrückung gestartet wird. Das Verfahren geht dann direkt zu Schritt 2104 über.
  • 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 Änderungsbytes 1700 bestimmt. Das Änderungsbyte wird dann in Temp(0) kopiert. Das Verfahren fährt dann mit dem Entscheidungsschritt 2106 fort.
  • Im 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-Header in seiner Gesamtheit gesendet werden soll, um von einem Empfänger, wie etwa dem CMTS 104, gelernt zu werden. Das Verfahren geht dann zu Schritt 2108 über.
  • In Schritt 2108 wird ein neuer Puffer zugewiesen. Das Verfahren fährt dann mit Schritt 2110 fort.
  • In Schritt 2110 werden das Änderungsbyte 1700 und ein einzelnes Pad-Byte (Füll-Byte) in dem in Schritt 2108 zugewiesenen Puffer gespeichert. Die System-Hardware sieht es nicht gerne, wenn Puffern ein einzelnes Byte zugewiesen wird. Daher besteht eine begrenzende Vorgabe für die Hardware darin, Puffern mehr als 1 Byte zuzuweisen. Daher wird auch ein Pad-Byte in den Puffer eingegeben. Das Verfahren geht dann zu Schritt 2112 über.
  • In Schritt 2112 wird ein ursprünglicher Puffer, der das TCP-Protokollpaket 1410 enthält, an den neuen, auf einem BD-Ring befindlichen Puffer angehängt. Das Verfahren fährt dann mit Schritt 2114 fort.
  • In Schritt 2114 werden die ursprüngliche Pufferlänge und die neue Pufferlänge gesendet. Somit werden das Änderungsbyte und ein Pad mit dem 54Byte-Header und dem PDU-Feld 1460 gesendet, um den vollständigen 802.3-/IP-/TCP-Header 1400 zu lernen. Wenn der L-Bit 1702 gesetzt ist, wird der Sendebefehl 2000 angewandt. Das Verfahren geht dann zu Schritt 2116 über, in dem das Verfahren endet.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2106, fährt das Verfahren, wenn das L-Bit 1702 nicht gesetzt ist, mit Schritt 2118 fort. In Schritt 2118 wird die Länge von Temp berechnet und ein Zeiger auf den Puffer [54], abzüglich der Länge von Temp, gerichtet. Die Länge von Temp umfasst die Länge sämtlicher Daten, die im endgültigen codierten Datenstrom 1800 gesendet werden. Das Verfahren geht dann zu Schritt 2120 über.
  • In Schritt 2120 wird Temp in den Zeiger kopiert. Das Verfahren fährt dann mit Schritt 2122 fort.
  • In Schritt 2122 wird der Zeiger auf dem BD-Ring platziert. Das Verfahren geht dann zu Schritt 2124 über.
  • In Schritt 2124 wird die ursprüngliche Länge – [54] + Länge von Temp gesendet. Somit wird der endgültige codierte Datenstrom 1800 gesendet. Wenn das L-Bit 1702 nicht gesetzt ist, wird der Sendebefehl 1900 angewandt. Das Verfahren fährt dann mit Schritt 2116 fort, in dem das Verfahren endet.
  • 22 ist ein Flussdiagramm 2200, das ein Verfahren zur TCP-Header-Rekonstruktion darstellt. Die Erfindung ist nicht auf die hierin in Bezug auf das Flussdiagramm 2200 vorgesehene Beschreibung beschränkt. Es wird vielmehr für Fachleute auf dem/den relevanten Gebieten nach dem Studium der hierin angegebenen Lehren ersichtlich sein, dass andere Funktionsflussdiagramme im Schutzumfang der vorliegenden Erfindung enthalten sind. Ein 54Byte-Template-Header wird von der DOCSIS-Nutzlast-Header-Rekonstruktionsmaschine (nicht gezeigt) vor dem Start des Flussdiagramms 2200 erzeugt. Das Verfahren beginnt mit Schritt 2202, in dem eine TCP-Header-Rekonstruktion gestartet wird. Das Verfahren geht dann zu Schritt 2204 über.
  • In Schritt 2204 wird ein 54-Byte-Header aus dem Eingangsstrom gelesen. Das Verfahren fährt dann mit Schritt 2206 fort.
  • In Schritt 2206 wird das Änderungsbyte 1700 aus dem Eingangsstrom gelesen. Das Verfahren geht dann zum Entscheidungsschritt 2208 über.
  • Im Entscheidungsschritt 2208 wird bestimmt, ob das L-Bit 1702 des Änderungsbytes 1700 gesetzt ist. Wenn das L-Bit 1702 gesetzt ist, dann fährt das Verfahren mit Schritt 2210 fort.
  • In Schritt 2210 wird der in Schritt 2204 erfasste 54Byte-Header verworfen. Diese Daten werden verworfen, da diese Daten nicht aus dem Eingangsstrom erzeugt worden sind, sondern anhand des Nutzlast-Header-Unterdrückungsmechanismus der Hardware am Ende des Rekonstruktionsverfahrens, was nachfolgend unter Bezugnahme auf Schritt 2216 beschrieben ist. Wenn der Nutzlast-Header-Unterdrückungsmechanismus der Hardware diesen 54Byte-Header einspeist, wird der 54Byte-Header vor dem Änderungsbyte 1700 platziert. Daher wird dieser 54Byte-Header, wenn das L-Bit 1702 gesetzt ist, als Müll betrachtet und muss verworfen werden. Aus Sicht des KM 108, war das Gesendete ein Unterdrückungsindex. Der Empfang des Unterdrückungsindex durch das CMTS 104 hat bewirkt, dass durch das CMTS 104 54 Bytes inkorrekter Daten in den Datenstrom eingespeist wurden. Das Verfahren geht dann zu Schritt 2212 über.
  • In Schritt 2212 wird ein 1Byte-Pad aus dem Eingangsstrom gelesen und verworfen. Das Verfahren fährt dann mit Schritt 2214 fort.
  • In Schritt 2214 wird der korrekte, vom KM 108 gesendete 54Byte-Header aus dem Eingangsstrom gelesen. Das Verfahren geht dann zu Schritt 2216 über.
  • In Schritt 2216 wird der korrekte 54Byte-Header in einen Template-Header kopiert und der 54Byte-Header sowie die Daten aus dem nachfolgenden PDU-Feld 1460 gesendet. Das Verfahren fährt dann mit Schritt 2218 fort, in dem das Verfahren endet.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2208 geht das Verfahren, wenn das L-Bit 1702 des Änderungsbytes 1700 nicht gesetzt ist, dann zum Entscheidungsschritt 2220 über.
  • Der Entscheidungsschritt 2220 beginnt das Verfahren zum Bestimmen, ob das IP-Paket-ID-Feld 1426 um 0x0001 oder 0x0100 inkrementiert oder ein 2Byte-Wert aus dem Eingangsstrom in den Template-Header des IP-Paket-ID-Feldes 1426 kopiert werden soll. Im Entscheidungsschritt 2220 wird bestimmt, ob das I(1)-Bit 1704 des Änderungsbytes 1700 gesetzt ist. Wenn I(1) gesetzt ist, fährt das Verfahren mit Schritt 2222 fort.
  • In Schritt 2222 wird ein 2Byte-Wert aus dem Eingangsstrom gelesen und in das IP-Paket-ID-Feld 1426 (Offset 18) kopiert. Das Verfahren geht dann zu Schritt 2230 über.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2220 fährt das Verfahren, wenn das I(1)-Bit 1704 des Änderungsbytes 1700 nicht gesetzt ist, mit dem Entscheidungsschritt 2224 fort. Im Entscheidungsschritt 2224 wird bestimmt, ob das I(0)-Bit 1706 des Änderungsbytes 1700 gesetzt ist. Wenn das I(0)-Bit 1706 nicht gesetzt ist, geht das Verfahren zu Schritt 2226 über.
  • In Schritt 2226 wird 0x0001 zum IP-Paket-ID-Feld 1426 am Offset 18 addiert. Das Verfahren fährt dann mit Schritt 2230 fort.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2224 fährt das Verfahren, wenn das I(0)-Bit 1706 des Änderungsbytes 1700 gesetzt ist, mit Schritt 2228 fort. In Schritt 2228 wird 0x0100 zum IP-Paket-ID-Feld 1426 am Offset 18 addiert. Das Verfahren fährt dann mit dem Entscheidungsschritt 2230 fort.
  • Im Entscheidungsschritt 2230 wird bestimmt, ob das S-Bit 1708 des Änderungsbytes 1700 gesetzt ist. Wenn das S-Bit 1708 gesetzt ist, gibt dies an, dass im TCP-Sequenznummernfeld 1446 eine Änderung gegenüber dem vorherigen Wert stattgefunden hat, das Verfahren geht dann zu Schritt 2232 über.
  • In Schritt 2232 werden die nächsten 2 Datenbytes aus dem Eingangsdatenstrom zum TCP-Sequenznummernfeld 1446 am Offset 38 addiert. Das Verfahren fährt dann mit dem Entscheidungsschritt 2234 fort.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2230 fährt das Verfahren, wenn das S-Bit 1708 des Änderungsbytes 1700 nicht gesetzt ist, mit dem Entscheidungsschritt 2234 fort.
  • Im Entscheidungsschritt 2234 wird bestimmt, ob das A-Bit 1710 des Änderungsbytes 1700 gesetzt ist. Wenn das A-Bit 1710 gesetzt ist, gibt dies an, dass im TCP-Bestätigungsnummernfeld 1448 eine Änderung stattgefunden hat, das Verfahren geht dann zu Schritt 2236 über.
  • In Schritt 2236 werden die nächsten 2 Datenbytes aus dem Eingangsdatenstrom zum TCP-Bestätigungsnummernfeld 1448 am Offset 42 addiert. Das Verfahren fährt dann mit dem Entscheidungsschritt 2238 fort.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2234 fährt das Verfahren, wenn das A-Bit 1710 des Änderungsbytes 1700 nicht gesetzt ist, mit dem Schritt 2238 fort.
  • In Schritt 2238 wird das nächste Datenbyte aus dem Eingangsstrom in das TCP-Daten-Offset-Feld 1450 am Offset 46 kopiert. Das Verfahren geht dann zum Entscheidungsschritt 2240 über.
  • Im Entscheidungsschritt 2240 wird bestimmt, ob das P-Bit 1712 des Änderungsbytes 1700 gesetzt ist. Wenn das P-Bit 1712 gesetzt ist, fährt das Verfahren mit Schritt 2242 fort.
  • In Schritt 2242 wird eine ODER-Verknüpfung von 0x08 und den Daten im TCP-Flag-Feld 1452 am Offset 47 durchgeführt. Das Verfahren geht dann zum Entscheidungsschritt 2246 über.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2240 fährt das Verfahren, wenn das P-Bit 1712 des Änderungsbytes 1700 nicht gesetzt ist, mit dem Schritt 2244 fort.
  • In Schritt 2244 wird eine UND-Verknüpfung von 0xF7 und den Daten im TCP-Flag-Feld 1452 am Offset 47 durchgeführt. Das Verfahren geht dann zum Entscheidungsschritt 2246 über.
  • Im Entscheidungsschritt 2246 wird bestimmt, ob das W-Bit 1714 des Änderungsbytes 1700 gesetzt ist. Wenn das W-Bit 1714 gesetzt ist, gibt dies an, dass im TCP-Fensterfeld 1454 eine Änderung stattgefunden hat, wobei das Verfahren dann mit Schritt 2248 fortfährt.
  • In Schritt 2248 werden die nächsten 2 Datenbytes aus dem Eingangsstrom in das TCP-Fensterfeld 1454 am Offset 48 kopiert. Das Verfahren geht dann zum Entscheidungsschritt 2250 über.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2246 fährt das Verfahren, wenn bestimmt wird, dass das W-Bit 1714 des Änderungsbytes 1700 nicht gesetzt ist, mit dem Schritt 2250 fort.
  • In Schritt 2250 werden die nächsten 2 Datenbytes aus dem Eingangsstrom in das TCP-Prüfsummenfeld 1456 am Offset 50 kopiert. Das Verfahren fährt dann mit dem Entscheidungsschritt 2252 fort.
  • Im Entscheidungsschritt 2252 wird bestimmt, ob das U-Bit 1716 des Änderungsbytes 1700 gesetzt ist. Wenn das U-Bit 1716 gesetzt ist, geht das Verfahren zu Schritt 2254 über.
  • In Schritt 2254 werden die nächsten 2 Datenbytes aus dem Eingangsstrom in das TCP-Dringlichkeitszeigerfeld 1458 am Offset 52 kopiert. Das Verfahren fährt dann mit Schritt 2256 fort.
  • In Schritt 2256 wird das U-Bit im TCP-Flags-Feld 1452 gesetzt, indem eine ODER-Verknüpfung von 0x20 und dem TCP-Flags-Feld 1452 am Offset 47 durchgeführt wird. Das Verfahren geht dann zum Entscheidungsschritt 2260 über.
  • Bezug nehmend nochmals auf den Entscheidungsschritt 2252 fährt das Verfahren, wenn das U-Bit 1716 des Änderungsbytes 1700 nicht gesetzt ist, mit dem Schritt 2258 fort. In Schritt 2258 wird das U-Bit im TCP-Flags-Feld 1452 gelöscht, indem eine UND-Verknüpfung von 0xDF und dem TCP-Flags-Feld 1452 am Offset 47 durchgeführt wird. Das Verfahren geht dann zum Entscheidungsschritt 2260 über.
  • In Schritt 2260 wird das IP-Gesamtlängenfeld 1424 der restlichen Länge des PDU-Feldes 1460 zuzüglich 40 Bytes gleichgesetzt. Ein neues IP-Header-Prüfsummenfeld 1434 wird bestimmt und im Template-Header am Offset 24 platziert. Die IP-Header-Prüfsumme ist das 16Bit-Einerkomplement der Einerkomplementsumme der Werte an den Offsets 14, 16, 18, 22, 26, 28, 30 und 32. Das Verfahren fährt dann mit Schritt 2216 fort, in dem 54 Bytes in den Template-Header kopiert und gesendet werden. Das Verfahren geht dann zu Schritt 2218 über, in dem das Verfahren endet.
  • D. Umgebung
  • Wie hierin an anderer Stelle erläutert, können die vorstehend beschriebenen Techniken oder Verfahren zum Teil durch den MAC-Abschnitt eines Kabelmodems und den Kopfstellen-MAC-Abschnitt eines CTMS als Software-Routinen ausgeführt werden. Bezug nehmend beispielsweise auf die beispielhafte Ausführung des Kabelmodems 108, das unter Bezugnahme auf 3 beschrieben ist, führt die MAC 314 die erforderlichen Verfahrensschritte durch Ausführen von Software-Funktionen mit Hilfe der CPU 320 durch. Diese Software-Funktionen können entweder im RAM 322 oder im ROM 324 gespeichert werden. Des Weiteren führt die Kopfstellen-MAC 218, in Bezug auf die beispielhafte Ausführung des CMTS 104, die erforderlichen Verfahrensschritte durch Ausführen von Software-Funktionen mit Hilfe der CPU 222 durch. Diese Software-Funktionen können entweder im RAM 220 oder im ROM 218 gespeichert werden.
  • Die Verfahren der vorliegenden Erfindung müssen jedoch nicht auf diese Ausführungsformen beschränkt sein. Die Verfahren der vorliegenden Erfindung können beispielsweise in Software-Routinen verkörpert sein, die in Computersystemen, wie etwa dem in 23 gezeigten Computersystem 2300, ausgeführt werden. Verschiedene Ausführungsformen sind vermittels dieses beispielhaften Computersystems 2300 beschrieben. Nach einem Studium dieser Beschreibung wird es für einen Fachmann auf dem relevanten Gebiet ersichtlich sein, wie die Erfindung unter Verwendung anderer Computersysteme und/oder Computerarchitekturen auszuführen ist. Das Computersystem 2300 umfasst einen oder mehrere Prozessoren, wie etwa den Prozessor 2303. Der Prozessor 2303 ist mit einem Kommunikationsbus 2302 verbunden.
  • Das Computersystem 2300 umfasst ferner einen Hauptspeicher 2305, bevorzugt einen RAM (Random Access Memory – Lese-/Schreibspeicher mit wahlfreiem Zugriff) und kann außerdem einen Sekundärspeicher 2310 enthalten. Der Sekundärspeicher 2310 kann beispielsweise ein Festplattenlaufwerk 2312 und/oder ein Wechselspeicherlaufwerk 2314 umfassen, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein optisches Plattenlaufwerk, etc. darstellt. Das Wechselspeicherlaufwerk 2314 liest aus einer Wechselspeichereinheit 2318 aus und/oder schreibt in diese auf wohlbekannte Art und Weise. Die Wechselspeichereinheit 2318 stellt eine Diskette, ein Magnetband, eine optische Platte, etc. dar, die/das durch das Wechselspeicherlaufwerk 2314 gelesen und beschrieben wird. Es versteht sich, dass die Wechselspeichereinheit 2318 ein computernutzbares Speichermedium umfasst, in dem Computer-Software und/oder Daten gespeichert sind.
  • Bei alternativen Ausführungsformen kann der Sekundärspeicher 2310 andere ähnliche Einrichtungen umfassen, die ein Laden von Computerprogrammen oder anderer Instruktionen in das Computersystem 2300 ermöglichen. Solche Einrichtungen können beispielsweise eine Wechselspeichereinheit 2322 und eine Schnittstelle 2320 umfassen. Beispiele dafür können eine Programmkassette und Kassettenschnittstelle (wie sie sich etwa in Videospielgeräten finden), einen Wechselspeicherchip (wie etwa einen EPROM oder PROM) und eine zugehörige Buchse sowie andere Wechselspeichereinheiten 2322 und Schnittstellen 2320, die eine Übertragung von Software und Daten von der Wechselspeichereinheit 2322 an das Computersystem 2300 ermöglichen.
  • Das Computersystem 2300 kann auch eine Kommunikationsschnittstelle 2324 umfassen. Die Kommunikationsschnittstelle 2324 ermöglicht eine Übertragung von Software und Daten zwischen dem Computersystem 2300 und externen Geräten. Beispiele für die Kommunikationsschnittstelle 2324 können ein Modem, eine Netzwerkschnittstelle (wie etwa eine Ethernet-Karte), einen Kommunikationsport, einen PCMCIA-Slot und eine PCMCIA-Karte, ein Schnittstelle für ein drahtloses LAN (lokales Netz), etc. umfassen. Über die Kommunikationsschnittstelle 2324 übertragene Software und Daten haben die Form von Signalen 2328, die elektronische, elektromagnetische, optische oder andere Signale sein können, die von der Kommunikationsschnittstelle 2324 empfangen werden können. Diese Signale 2328 werden der Kommunikationsschnittstelle 2324 über einen Kommunikationspfad (d.h. Kanal) 2326 zugeführt. Dieser Kanal 2326 überträgt die Signale 2328 und kann unter Verwendung eines Drahtes oder Kabels, einer Glasfaser, einer Telefonleitung, einer Mobiltelefonverbindung, einer drahtlosen Verbindung und anderer Kommunikationskanäle ausgeführt werden.
  • In diesem Dokument bezieht sich der Begriff "Computerprogrammprodukt" auf die Wechselspeichereinheiten 2318, 2322 und die Signale 2328. Diese Computerprogrammprodukte sind Mittel zum Zuführen von Software an das Computersystem 2300. Die Erfindung ist auf solche Computerprogrammprodukte gerichtet.
  • Computerprogramme (auch als Computersteuerlogik bezeichnet) werden im Hauptspeicher 2305 und/oder Sekundärspeicher 2310 und/oder in Computerprogrammprodukten gespeichert. Computerprogramme können auch über die Kommunika tionsschnittstelle 2324 empfangen werden. Solche Computerprogramme ermöglichen es, wenn sie ausführt werden, dem Computersystem 2300, die hierin beschriebenen Merkmale der vorliegenden Erfindung auszuführen. Insbesondere ermöglichen es die Computerprogramme, wenn sie ausführt werden, dem Prozessor 2303, die Merkmale der vorliegenden Erfindung auszuführen. Dementsprechend stellen solche Computerprogramme die Steuereinrichtungen des Computersystems 2300 dar.
  • Bei einer Ausführungsform, bei der die Erfindung unter Verwendung von Software implementiert wird, kann die Software in einem Computerprogrammprodukt gespeichert und unter Verwendung des Wechselspeicherlaufwerks 2314, des Festplattenlaufwerks 2312 oder der Kommunikationsschnittstelle 2324 in das Computersystem 2300 geladen werden. Die Steuerlogik (Software) bewirkt, wenn sie durch den Prozessor 2303 ausgeführt wird, dass der Prozessor 2303 die Funktionen der hierin beschriebenen Erfindung ausführt.
  • Bei einer anderen Ausführungsform wird die Erfindung hauptsächlich in Hardware implementiert, und zwar beispielsweise unter Verwendung von Hardware-Komponenten, wie etwa anwendungsspezifische integrierte Schaltungen (ASICs). Die Ausführung der Hardware-Zustandsmaschine(n) zur Durchführen der hierin beschriebenen Funktionen ist für Fachleute auf dem/den relevanten Gebieten ersichtlich.
  • Bei einer weiteren Ausführungsform wird die Erfindung unter Verwendung einer Kombination aus Hardware und Software implementiert.
  • E. Schlusswort
  • Die vorliegende Erfindung ist nicht auf die Ausführungsform eines Kabelmodemsystems beschränkt. Die vorliegende Erfindung kann mit jedem beliebigen System verwendet werden, dass RTP-Pakete über ein Netzwerk sendet. Die vorstehende Beschreibung der bevorzugten Ausführungsformen wurde vorgesehen, um es einem Fachmann auf dem Gebiet zu ermöglichen, die vorliegende Erfindung herzustellen und zu verwenden. Obgleich die Erfindung insbesondere in Bezug auf ihre bevorzugten Ausführungsformen dargestellt und beschrieben worden ist, versteht es sich für Fachleute auf dem Gebiet, dass verschiedene Abwandlungen in Form und Detail daran durchgeführt werden können, ohne vom Schutzumfang der Erfindung abzuweichen.

Claims (4)

  1. Verfahren zum Unterdrücken eines RTP-Headers (900), das die Schritte umfasst: a) Bestimmen (1204) eines Deltawerts für einen RTP-Zeitstempelwert (952) zwischen zwei aufeinander folgenden RTP-Paketen, b) Bestimmen (1206) eines Deltawerts für eine RTP-Sequenznummer (950) zwischen zwei aufeinander folgenden RTP-Paketen, c) Bestimmen (1208), ob eine Rekonstruktion des RTP-Headers (900) stattfindet, d) wenn keine Rekonstruktion des RTP-Headers (900) stattfindet, Setzen (1210) eines Lern-Bits (1002), um es einem Empfänger (104) zu ermöglichen, den RTP-Header (900) zu lernen, und Senden (1216) eines kompletten RTP-Pakets, eines Steuerwerts (1000) und des Deltawerts für den RTP-Zeitstempelwert (952) in Upstream-Richtung, um vom Empfänger (104) gelernt zu werden, und e) wenn eine Rekonstruktion des RTP-Headers (900) stattfindet, Senden (1224) des Steuerwerts (1000) und des Deltawertes für einen RTP-Zeitstempelwert (952) in Upstream-Richtung zur Rekonstruktion des RTP-Headers am Empfänger (104), dadurch gekennzeichnet, dass der Steuerwert (1000) das Lern-Bit (1002), zwei Bits zum Bestimmen, ob das IP-Paket-ID-Feld (926) des RTP-Headers (900) um 0x0001 und/oder 0x0100 inkrementiert werden soll, und fünf Bits (1008) für den Deltawert für die RTP-Sequenznummer (950) umfasst.
  2. Verfahren nach Anspruch 1, wobei Schritt c) ferner die Schritte des Bestimmens umfasst, ob ein vorheriger RTP-Zeitstempel, der Deltawert für die RTP-Sequenznummer (950) und ein Codec-Wert einen aktuellen Zeitstempelwert (952) generieren.
  3. Computerprogrammprodukt, das ein computernutzbares Medium umfasst, in dem eine Steuerlogik gespeichert ist, wobei die Steuerlogik zur Ermöglichung der Unterdrückung eines RTP-Headers (900) dient und die Steuerlogik umfasst: eine erste Bestimmungseinrichtung, um es einem Prozessor (2303) zu ermöglichen, einen Deltawert für einen RTP-Zeitstempelwert (952) zwischen zwei aufeinander folgenden RTP-Paketen zu bestimmen, eine zweite Bestimmungseinrichtung, um es einem Prozessor (2303) zu ermöglichen, einen Deltawert für eine RTP-Sequenznummer (950) zwischen zwei aufeinander folgenden RTP-Paketen zu bestimmen, eine dritte Bestimmungseinrichtung, um es einem Prozessor (2303) zu ermöglichen, zu bestimmen, ob eine Rekonstruktion des RTP-Headers (900) stattfindet, eine Setzeinrichtung, um es einem Prozessor (2303) zu ermöglichen, ein Lern-Bit (1002) zu setzen, um es einem Empfänger (104) zu ermöglichen, den RTP-Header (900) zu lernen, und eine Sendeeinrichtung, um es einem Prozessor (2302) zu ermöglichen, ein komplettes RTP-Paket, einen Steuerwert (1000) und den Deltawert für den RTP-Zeitstempelwert (952) in Upstream-Richtung zu senden, um vom Empfänger (104) gelernt zu werden, wenn keine Rekonstruktion des RTP-Headers (900) stattfindet, und eine Sendeeinrichtung, um es einem Prozessor (2303) zu ermöglichen, den Steuerwert (1000) und den Deltawert für den RTP-Zeitstempelwert (952) zur Rekonstruktion des RTP-Headers am Empfänger (104) in Upstream-Richtung zu senden, wenn eine Rekonstruktion des RTP-Headers (900) stattfindet, dadurch gekennzeichnet, dass der Steuerwert (1000) das Lern-Bit (1002), zwei Bits zum Bestimmen, ob das IP-Paket-ID-Feld (926) des RTP-Headers (900) um 0x0001 und/oder 0x0100 inkrementiert werden soll, und fünf Bits (1008) für den Deltawert für die RTP-Sequenznummer (950) umfasst.
  4. Computerprogrammprodukt nach Anspruch 3, wobei die dritte Bestimmungseinrichtung ferner Einrichtungen umfasst, die es einem Prozessor (2303) ermöglichen, zu bestimmen, ob ein vorheriger RTP-Zeitstempel (952), der Deltawert für die RTP-Sequenznummer (950) und ein Codec-Wert einen aktuellen Zeitstempelwert (952) generieren.
DE60120466T 2000-10-11 2001-10-11 Effiziente Übertragung von RTP Paketen in einem Netzwerk Expired - Lifetime DE60120466T2 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US23952600P 2000-10-11 2000-10-11
US23953000P 2000-10-11 2000-10-11
US23952500P 2000-10-11 2000-10-11
US23952700P 2000-10-11 2000-10-11
US23952400P 2000-10-11 2000-10-11
US239526P 2000-10-11
US239530P 2000-10-11
US239525P 2000-10-11
US239527P 2000-10-11
US239524P 2000-10-11
US24055000P 2000-10-13 2000-10-13
US240550P 2000-10-13
PCT/US2001/031559 WO2002032073A2 (en) 2000-10-11 2001-10-11 Efficiently transmitting rtp protocol in a network

Publications (2)

Publication Number Publication Date
DE60120466D1 DE60120466D1 (de) 2006-07-20
DE60120466T2 true DE60120466T2 (de) 2007-01-18

Family

ID=27559291

Family Applications (4)

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

Family Applications After (3)

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
DE60131890T Expired - Lifetime DE60131890T2 (de) 2000-10-11 2001-10-11 Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung
DE60118609T Expired - Lifetime DE60118609T2 (de) 2000-10-11 2001-10-11 Kabelmodemsystem und Verfahren zur Unterstützung erweiterter Protokolle

Country Status (4)

Country Link
US (9) US7130314B2 (de)
EP (4) EP1348289B1 (de)
DE (4) DE60120466T2 (de)
WO (5) WO2002032034A2 (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
EP1256229B1 (de) * 2000-02-15 2005-01-26 Broadcom Corporation Spracharchitektur für übertragung über ein gemeinsames, konkurrenzbasiertes medium
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
DE60120466T2 (de) * 2000-10-11 2007-01-18 Broadcom Corp., Irvine Effiziente Übertragung von RTP Paketen in einem Netzwerk
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
WO2003007116A2 (en) * 2001-07-11 2003-01-23 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
US7586914B2 (en) * 2001-09-27 2009-09-08 Broadcom Corporation Apparatus and method for hardware creation of a DOCSIS header
US7715437B2 (en) * 2001-09-27 2010-05-11 Broadcom Corporation Highly integrated media access control
US7436842B2 (en) 2001-10-11 2008-10-14 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
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
US8051176B2 (en) 2002-11-07 2011-11-01 Hewlett-Packard Development Company, L.P. Method and system for predicting connections 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
US8059673B2 (en) * 2003-05-01 2011-11-15 Genesis Microchip Inc. Dynamic resource re-allocation in a packet based video display interface
US8204076B2 (en) * 2003-05-01 2012-06-19 Genesis Microchip Inc. Compact packet based multimedia interface
US8068485B2 (en) 2003-05-01 2011-11-29 Genesis Microchip Inc. Multimedia interface
US7620062B2 (en) * 2003-05-01 2009-11-17 Genesis Microchips Inc. Method of real time optimizing multimedia packet transmission rate
US20040218624A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Packet based closed loop video display interface with periodic status checks
US7068686B2 (en) 2003-05-01 2006-06-27 Genesis Microchip Inc. Method and apparatus for efficient transmission of multimedia data packets
US20040221312A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Techniques for reducing multimedia data packet overhead
US7733915B2 (en) * 2003-05-01 2010-06-08 Genesis Microchip Inc. Minimizing buffer requirements in a digital video system
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
US20040218599A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Packet based video display interface and methods of use thereof
US7839860B2 (en) * 2003-05-01 2010-11-23 Genesis Microchip Inc. Packet based video display interface
US7567592B2 (en) * 2003-05-01 2009-07-28 Genesis Microchip Inc. Packet based video display interface enumeration method
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
CA2536106C (en) * 2003-09-05 2015-03-24 Comcast Cable Holdings, Llc Method and system for out-of-band messaging between customer premises equipment and a cable modem termination station
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
US11736311B2 (en) 2003-09-05 2023-08-22 Comcast Cable Communications, Llc 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
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
US7729346B2 (en) 2004-09-18 2010-06-01 Genband Inc. UMTS call handling methods and apparatus
KR100677144B1 (ko) * 2004-10-20 2007-02-02 삼성전자주식회사 Ｗｕｓｂ 버스를 경유하여 데이터를 송수신하는 방법 및장치
EP1803310B1 (de) * 2004-10-22 2015-12-23 Genband US LLC Vorrichtungen und verfahren zum mobilitätsmanagement
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
US7970010B2 (en) * 2004-12-10 2011-06-28 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
EP2127291B1 (de) * 2006-12-12 2019-10-16 Vestas Wind Systems A/S Mehrprotokoll-windturbinensystem und verfahren
CN101622711B (zh) 2006-12-28 2012-07-18 杰恩邦德公司 用于无声插入描述符（sid）转换的方法、系统
US7532134B2 (en) 2007-03-12 2009-05-12 Citrix Systems, Inc. Systems and methods for sharing compression histories between multiple devices
AU2012203797B2 (en) * 2007-03-12 2015-05-07 Citrix Systems, Inc. Systems and methods for using compression histories to improve network performance
US8255570B2 (en) * 2007-03-12 2012-08-28 Citrix Systems, Inc. Systems and methods of compression history expiration and synchronization
US7460038B2 (en) * 2007-03-12 2008-12-02 Citrix Systems, Inc. Systems and methods of clustered sharing of compression histories
EP2651092B1 (de) * 2007-03-12 2015-08-12 Citrix Systems, Inc. System und Verfahren zur Festlegung eines Vorrangs von übereinstimmenden Fingerabdrücken in einem Komprimierungsverlauf
US7619545B2 (en) * 2007-03-12 2009-11-17 Citrix Systems, Inc. Systems and methods of using application and protocol specific parsing for compression
US7827237B2 (en) * 2007-03-12 2010-11-02 Citrix Systems, Inc. Systems and methods for identifying long matches of data in a compression history
US7865585B2 (en) * 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing dynamic ad hoc proxy-cache hierarchies
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 한국전자통신연구원 케이블모뎀의 수신채널집합 설정 및 변경 방법
JP5345154B2 (ja) * 2008-01-11 2013-11-20 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｐマルチメディアサブシステムにおけるメッセージハンドリング
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
US8760461B2 (en) * 2009-05-13 2014-06-24 Stmicroelectronics, Inc. Device, system, and method for wide gamut color space support
US8860888B2 (en) * 2009-05-13 2014-10-14 Stmicroelectronics, Inc. Method and apparatus for power saving during video blanking periods
US8429440B2 (en) * 2009-05-13 2013-04-23 Stmicroelectronics, Inc. Flat panel display driver method and system
US8156238B2 (en) 2009-05-13 2012-04-10 Stmicroelectronics, Inc. Wireless multimedia transport method and apparatus
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
US8468285B2 (en) * 2009-05-18 2013-06-18 Stmicroelectronics, Inc. Operation of video source and sink with toggled hot plug detection
US8582452B2 (en) 2009-05-18 2013-11-12 Stmicroelectronics, Inc. Data link configuration by a receiver in the absence of link training data
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 纜線數據機及網路電話通訊協定選擇方法
JP5951888B2 (ja) * 2013-03-28 2016-07-13 株式会社東芝 通信装置、通信方法、及び通信プログラム
CN105453554B (zh) * 2013-08-13 2019-04-23 Lg 电子株式会社 发送、接收广播信号的装置及其方法
KR20150050133A (ko) * 2013-10-31 2015-05-08 삼성전자주식회사 통신 시스템에서 패킷 송수신 방법 및 장치
WO2015080658A1 (en) 2013-11-27 2015-06-04 Telefonaktiebolaget L M Ericsson (Publ) Hybrid rtp payload format
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
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
US10050833B2 (en) 2014-06-19 2018-08-14 Cavium, Inc. Method of reducing latency in a flexible parser 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
US9742694B2 (en) 2014-06-19 2017-08-22 Cavium, Inc. Method of dynamically renumbering ports 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
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
US9628385B2 (en) 2014-06-19 2017-04-18 Cavium, Inc. Method of identifying internal destinations of networks packets 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
WO2017043179A1 (ja) * 2015-09-09 2017-03-16 ソニー株式会社 通信装置および通信方法
KR102515830B1 (ko) * 2015-11-20 2023-03-29 삼성전자주식회사 데이터 송신 장치 및 방법과, 데이터 수신 장치 및 방법
US10582015B2 (en) 2016-03-25 2020-03-03 Amazon Technologies, Inc. Compression dictionary systems and methods
US10264103B2 (en) 2016-03-25 2019-04-16 Amazon Technologies, Inc. Compression dictionary generation service system and method
US10306024B2 (en) * 2016-03-25 2019-05-28 Amazon Technologies, Inc. Compression dictionary snapshot system and method
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
US5530645A (en) * 1993-06-30 1996-06-25 Apple Computer, Inc. Composite dictionary compression system
CA2125337A1 (en) * 1993-06-30 1994-12-31 Marlin Jay Eller Method and system for searching compressed data
CA2163556C (en) * 1994-04-22 2006-07-11 Tetsuji Kawashima System and method for transmitting compressed data or pre-compressed data based on a preset compression ratio
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
US6597812B1 (en) * 1999-05-28 2003-07-22 Realtime Data, Llc System and method for lossless data compression and decompression
US6542504B1 (en) * 1999-05-28 2003-04-01 3Com Corporation Profile based method for packet header compression in a point to point link
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
EP1364479B1 (de) 2000-09-01 2010-04-28 Broadcom Corporation Satellitenempfänger und entsprechendes verfahren
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
DE60120466T2 (de) * 2000-10-11 2007-01-18 Broadcom Corp., Irvine Effiziente Übertragung von RTP Paketen in einem Netzwerk
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
WO2003007116A2 (en) * 2001-07-11 2003-01-23 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
US7733867B2 (en) * 2005-08-26 2010-06-08 Alcatel-Lucent Usa Inc. Header compression for real time internet applications
US9031071B2 (en) * 2005-08-26 2015-05-12 Alcatel Lucent Header elimination 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
WO2002032034A2 (en) 2002-04-18
DE60120466D1 (de) 2006-07-20
EP1338128B1 (de) 2006-06-07
US20020062394A1 (en) 2002-05-23
US7130314B2 (en) 2006-10-31
DE60130367D1 (de) 2007-10-18
US7389527B2 (en) 2008-06-17
US7693186B2 (en) 2010-04-06
US20110058540A1 (en) 2011-03-10
US8767776B2 (en) 2014-07-01
EP1340351B1 (de) 2007-12-12
WO2002032080A1 (en) 2002-04-18
WO2002032034A3 (en) 2002-07-04
US7451235B2 (en) 2008-11-11
WO2002032073A2 (en) 2002-04-18
DE60118609D1 (de) 2006-05-18
EP1348289A2 (de) 2003-10-01
US20080304490A1 (en) 2008-12-11
WO2002032101A2 (en) 2002-04-18
EP1348290A2 (de) 2003-10-01
US6963931B2 (en) 2005-11-08
WO2002032101A3 (en) 2002-06-20
US7275115B2 (en) 2007-09-25
US7428247B2 (en) 2008-09-23
US20070058640A1 (en) 2007-03-15
US20020106029A1 (en) 2002-08-08
EP1348289B1 (de) 2006-04-05
WO2002032073A3 (en) 2002-06-13
DE60131890T2 (de) 2008-12-11
WO2002032034A9 (en) 2003-09-04
US20020080868A1 (en) 2002-06-27
US20080010300A1 (en) 2008-01-10
EP1340351A1 (de) 2003-09-03
DE60118609T2 (de) 2007-05-03
EP1338128A2 (de) 2003-08-27
EP1348290B1 (de) 2007-09-05
US20020073227A1 (en) 2002-06-13
US20020049861A1 (en) 2002-04-25
DE60130367T2 (de) 2008-06-12
WO2002032081A1 (en) 2002-04-18
DE60131890D1 (de) 2008-01-24

Similar Documents

Publication Publication Date Title
DE60120466T2 (de) Effiziente Übertragung von RTP Paketen in einem Netzwerk
DE60110303T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE60316094T2 (de) Verfahren, Vorrichtung und System für die Komprimierung von verlängerten Kopffeldern
DE602004010254T2 (de) Burst-übertragung
DE60007829T2 (de) Kopfkomprimierung für General Packet Radio Service Tunnel Protokoll (GTP)
DE69736713T2 (de) Anordnung und verfahren zur übertragung von ip-daten über ein satellitennetz
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE60022391T2 (de) System und verfahren zur erzielung einer robusten ip/udp/rtp-paketkopf-komprimierung in der gegenwart unzuverlässiger netze
DE60132071T2 (de) Kabelmodemsystem und verfahren zur übertragung von speziellen daten
DE60128409T2 (de) Verfahren und Vorrichtung zur Entkomprimierung von Paket-Kopfdaten
DE102005054978A1 (de) Verfahren zum Aktualisieren eines Datensatzes sowie Vorrichtung zur Durchführung des Verfahrens
US20070271588A1 (en) System and Method for Supporting Extended Protocols in a Wireless Communication System
DE10231958B4 (de) Verfahren und System zum Übertragen von Datenpaketen über ein Netzwerk an ausgewählte mehrere Bestimmungsorte, sowie computerlesbares Medium
DE60118673T2 (de) System und Methode zur Bewahrung der Bandbreite bei der Übertragung von Nachrichtenpaketen
DE10160844B4 (de) System zur Übertragung eines Datenstroms über ein Netzwerk an unterschiedliche Netzwerkprotokolle unterstützende Empfänger
US7965737B2 (en) Addressing method for transporting data on a telecommunication network, corresponding address structure signal, gateway and computer program
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