DE60130367T2 - Verfahren zum dynamischen mischen von Paketkopfunterdrückungstechniken - Google Patents

Verfahren zum dynamischen mischen von Paketkopfunterdrückungstechniken Download PDF

Info

Publication number
DE60130367T2
DE60130367T2 DE60130367T DE60130367T DE60130367T2 DE 60130367 T2 DE60130367 T2 DE 60130367T2 DE 60130367 T DE60130367 T DE 60130367T DE 60130367 T DE60130367 T DE 60130367T DE 60130367 T2 DE60130367 T2 DE 60130367T2
Authority
DE
Germany
Prior art keywords
header
packet
cable modem
field
data
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
DE60130367T
Other languages
English (en)
Other versions
DE60130367D1 (de
Inventor
Fred A. Roswell BUNN
Thomas L. Gainesville JOHNSON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Broadcom Corp
Original Assignee
Broadcom Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Broadcom Corp filed Critical Broadcom Corp
Application granted granted Critical
Publication of DE60130367D1 publication Critical patent/DE60130367D1/de
Publication of DE60130367T2 publication Critical patent/DE60130367T2/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

Landscapes

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

Description

  • Hintergrund der Erfindung
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft allgemein Kommunikationssysteme. Noch spezieller betrifft die Erfindung Kabelmodemsysteme und Verfahren zum Übertragen von Daten.
  • Stand der Technik
  • In herkömmlichen Kabelmodemsystemen stellt ein Hybrid-Faser-Koaxial-(HFC)-Netzwerk eine Punkt-zu-Mehrpunkt-Topologie für die Unterstützung einer Datenkommunikation zwischen einem Kabelmodem-Abschlusssystem (CMTS; cable modem termination system) an der Kabelkopfstelle und mehreren Kabelmodems (CM; cable modems) bei dem Kunden bereit. In solchen System wird Information von dem CMTS downstream zu den Kabelmodems als ein kontinuierlich übertragenes Signal in Übereinstimmung mit einem Zeitmultiplex-(TDM; time division multiplexing)-Verfahren rundgesendet. Im Gegensatz dazu wird Information upstream von jedem der Kabelmodems zu dem CMTS als Short-Burst-Signale in Übereinstimmung mit einem Zeitbereich-Mehrfachzugriff-(TDMA; time domain multiple access)-Verfahren übertragen. Die Upstream-Übertragung von Daten von den Kabelmodems wird von dem CMTS verwaltet, das jedem Kabelmodem spezifische Zeitschlitze zuteilt, innerhalb welcher die Daten zu übertragen sind. Herkömmliche Kabelmodemsysteme sind insofern asymmetrisch, als beträchtlich weniger Bandbreite für die Upstream-Übertragungen zur Verfügung steht als für die Downstream-Übertragungen. Dieser Mangel an Upstream-Bandbreite wird des Weiteren durch die Tatsache verschärft, dass die Upstream-Kanäle von mehreren Kabelmodems gemeinsam genutzt werden müssen. Als eine Folge davon ist die Erhaltung von Upstream-Bandbreite absolut erforderlich, um die Gesamtsystemperformanz aufrecht zu erhalten. Dies gilt insbesondere dann, wenn sich Kabelmodembenutzer mit Aktivitäten beschäftigen, die sowohl eine beträchtliche Upstream-, als auch eine beträchtliche Downstream-Bandbreite benötigen, wie etwa die IP-Telefonie, Videotelefonkonferenzen und Internet-Spiele.
  • Herkömmliche Kabelmodemsysteme benutzen DOCSIS-konforme Einrichtungen und Protokolle, um den Transfer von Datenpaketen zwischen mehreren Ka belmodems und einem CMTS auszuführen. Der Begriff DOCSIS (Data Over Cable System Interface Specification) bezieht sich im Allgemeinen auf eine Gruppe von Spezifikationen, die von CableLabs veröffentlicht wurden und die Industriestandards für Kabelkopfstellen- und Kabelmodemeinrichtungen definieren. Zum Teil legt die DOCSIS-Spezifikation Anforderungen und Aufgaben für verschiedene Aspekte von Kabelmodemsystemen dar, die Operationsunterstützungssysteme, das Management, Datenschnittstellen sowie auch Netzwerkschichten, Datenverbindungsschichten und den physikalischen Schicht-Transport für Data Over Cable Systeme umfassen. Die aktuellste Version der DOCSIS-Spezifikation ist DOCSIS 1.1.
  • Es ist aber festgestellt worden, dass die Verwendung von proprietären Datenübertragungsprotokollen, die über diejenigen hinausreichen, die von der DOCSIS-Spezifikation bereitgestellt werden, vorteilhaft in Bezug auf die Erhaltung von Netzwerkbandbreite in einem Kabelmodemsystem sein können. Dies trifft vor allem auf die Nutzlast-Header-Unterdrückung (PHS; Payload Header Suppression) zu. Die PHS, wie sie von DOCSIS 1.1 definiert ist, erlaubt die Unterdrückung von unnötigen Ethernet/IP-Header-Informationen in einem DOCSIS-Paket durch das Kabelmodem und eine nachfolgende Rekonstruktion des Header mittels des CMTS. Das Ziel der PHS ist, die Anzahl an Bits zu reduzieren, die pro Paket übertragen werden, wodurch die Netzwerkbandbreitenausnutzung verbessert wird. Aber die DOCSIS PHS (DPHS) erlaubt die Header-Unterdrückung nur auf der Grundlage des Vorhandenseins von redundanten Header-Bytes in sequentiell übertragenen Paketen. Es wäre wünschenswert, effizientere Nutzlast-Header-Unterdrückungstechniken bei der Übertragung von Daten über ein Kabelmodemnetzwerk verwenden zu können. Insbesondere wäre es wünschenswert, proprietäre protokollspezifische Header-Unterdrückungstechniken zu verwenden, die eine größere Reduktion der Größe der Nutzlast-Headers innerhalb eines gegebenen DOCSIS-Pakets erlauben, als dies von DOCSIS 1.1 vorgesehen ist.
  • Die Verwendung von proprietären Datenübertragungsprotokollen, die über DOCSIS hinausgehen, kann aus einer Anzahl von weiteren Gründen erwünscht sein. Zum Beispiel stellt die DOCSIS-Spezifikation keinen Mechanismus zur Identifizierung von TCP/IP oder RTP Datenströmen innerhalb eines Kabelmodem-Serviceablaufs bereit. Als eine Folge davon erlaubt DOCSIS keine spezialisierte Handhabung solcher TCP/IP oder RTP Datenströme in einer Art und Weise, die eine bessere Ausnutzung der Netzwerkbandbreite bereitstellt (z.B. eine protokollspezifische Un terdrückung von Nicht-Header-Informationen). Außerdem können, obwohl DOCSIS 1.1 Techniken für die Fragmentierung von sehr großen Paketen in mehrere Upstream-Bursts und die Verkettung von kleinen Paketen in einen einzigen Upstream-Burst bereitstellt, eine effizientere Paketfragmentierung und effizientere Verkettungstechniken erzielt werden.
  • Bisher ist die Verwendung von proprietären Datenübertragungsprotokollen, die über diejenigen hinausgehen, die von der DOCSIS-Spezifikation bereitgestellt werden, vermieden worden. Dies ist zum Teil auf die Tatsache zurückzuführen, dass die DOCSIS-Spezifikation keinen Mechanismus für die Verwendung von alternativen Protokollen in einem Kabelmodemsystem bereitstellt. Zum Beispiel stellt die DOCSIS-Spezifikation keinen Mechanismus für die Verwendung von Datenpaketformaten bereit, die sich von denen, die die DOCSIS-Spezifikation bereitstellt, unterscheiden. Darüber hinaus ist die Verwendung von erweiterten Protokollen vermieden worden, um eine Interoperabilität zwischen einzelnen Kabelmodemsystemkomponenten zu gewährleisten, weil herkömmliche CMTS- und Kabelmodemvorrichtungen in Übereinstimmung mit der DOCSIS-Spezifikation entwickelt wurden. So sind zum Beispiel herkömmliche DOCSIS-konforme CMTS-Einrichtungen nicht in der Lage, zwischen einen Standard-DOCSIS-Verkehr und einem Verkehr zu unterscheiden, der in Übereinstimmung mit einem erweiterten Protokoll übertragen wird.
  • Folglich werden ein System und ein Verfahren zur Übertragung von Daten in einem Kabelmodemnetzwerk gewünscht, das die Verwendung von Protokollen unterstützt, die über die DOCSIS-Spezifikation hinausgehen. Zum Beispiel sollten das gewünschte System und das gewünschte Verfahren die Verwendung von protokollspezifischen Paket-Header-Unterdrückungstechniken unterstützen, die effizienter als die DPHS sind. Aber das gewünschte System und Verfahren sollten interoperabel mit DOCSIS in dem Sinne sein, dass Komponenten eines Kabelmodemsystems, das die erweiterten Protokolle unterstützt, in dem gleichen Netzwerk mit Komponenten existieren können, die dies nicht tun. Des Weiteren sollten das gewünschte System und das gewünschte Verfahren nur sehr geringe Modifikationen bei existierenden Kabelmodemsystemkomponenten, wie etwa einer existierenden Kabelmodem- und CMTS-Einrichtung, erfordern.
  • Das Dokument US 6438123 "Method and apparatus for supporting header suppression and multiple microflows in a network" offenbart ein Verfahren zur dy namischen Einrichtung, Modifizierung und Verkettung/Mischung von mehreren Microflows (Ende-zu-Ende-Datenströme) zwischen dem CMTS und dem CM auf der gleichen Kabelmodem-SID (Service Identification; Dienstkennung). Microflows werden verkettet und alle zusammen für jede Gewährungszuordnung gesendet. Operationen wie etwa eine Header-Unterdrückung können für mehrere Ströme (Telefongespräche) auf der gleichen SID durchgeführt werden. Nichtsdestotrotz wird für alle Microflows die gleiche Header-Unterdrückungstechnik verwendet (das Header-Paket wird abgestreift), um eine konstante Paketgröße zu erhalten.
  • Das Dokument XP002193659 "DATA-OVER-CARLE SERVICE INTERFACE SPECIFICATIONS" ist Teil der DOCSIS-Spezifikation und offenbart eine Nutzlast-Header-Unterdrückung.
  • Zusammenfassung der Erfindung
  • Die Erfindung ist in den angehängten Ansprüchen definiert.
  • Kurze Beschreibung der Figuren
  • Die beigefügten Zeichnungen, die in der vorliegenden Beschreibung aufgenommen sind und Teil der Patentschrift bilden, veranschaulichen die vorliegende Erfindung, und zusammen mit der Beschreibung dienen sie des Weiteren dazu, die Prinzipien der Erfindung zu erklären und einen Fachmann auf dem relevanten Fachgebiet in die Lage zu versetzen, die Erfindung auszuführen und zu verwenden.
  • 1 ist ein Blockdiagramm hoher Ebene eines Kabelmodemsystems in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung.
  • 2 ist ein schematisches Blockdiagramm eines Kabelmodem-Abschlusssystems (CMTS) in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung.
  • 3 ist ein schematisches Blockdiagramm eines Kabelmodems in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung.
  • 4 ist ein Ablaufdiagramm eines Verfahrens zur Unterstützung von erweiterten Protokollen in einem Kabelmodemsystem in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung.
  • 5 ist ein Ablaufdiagramm eines Verfahrens zur Unterstützung von erweiterten Protokollen in einem Kabelmodemsystem in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung.
  • 6A ist ein Blockdiagramm eines nicht komprimierten Pakets, das typischerweise von einem Kabelmodem in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung empfangen wird.
  • 6B ist ein Blockdiagramm eines Pakets, das von einem Kabelmodem in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung komprimiert ist.
  • 6C ist ein Blockdiagramm von mehreren, eine einzige SID enthaltenden Paketen, die von einem Kabelmodem unter Verwendung von verschiedenen Paket-Header-Unterdrückungstechniken in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung komprimiert worden sind.
  • 7 ist ein Ablaufdiagramm eines Verfahrens zum Komprimieren von Paketen unter Verwendung von unterschiedlichen Paket-Header-Unterdrückungstechniken in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung.
  • 8 ist ein Ablaufdiagramm eines Verfahrens zum Expandieren bzw. Dekomprimieren von Paketen, die unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken komprimiert worden sind, in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung.
  • 9A ist ein Diagramm eines beispielhaften 802.3/IP/UDP/RTP Header.
  • 9B ist ein Diagramm eines RTP-Protokoll-Pakets.
  • 10 ist ein Diagramm, das ein Steuerwert-Byte veranschaulicht, das während der Operation einer RTP-Header-Unterdrückungstechnik verwendet wird.
  • 11 ist ein Ablaufdiagramm hoher Ebene, das ein Verfahren für die RTP-Header-Unterdrückung veranschaulicht.
  • 12A ist ein Ablaufdiagramm, das ein Verfahren zum Unterdrücken eines RTP Header unter Verwendung einer RTP-Header-Unterdrückungstechnik gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 12B ist ein Ablaufdiagramm, das ein Verfahren zum Festlegen des Inkrements eines IP-Paket-ID-Feldes in einem RTP Header gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 13 ist ein Ablaufdiagramm, das ein Verfahren zum Rekonstruieren eines RTP-Header unter Verwendung einer RTP-Header-Unterdrückungstechnik gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 14A ist ein Diagramm, das einen beispielhaften 802.3/IP/TCP Header veranschaulicht.
  • 14B ist ein Diagramm, das ein TCP-Protokoll-Paket veranschaulicht.
  • 15 ist ein Diagramm, das ein TCP-Protokoll-Paket veranschaulicht, wobei Felder, die sich von Paket zu Paket ändern können, hervorgehoben sind.
  • 16A ist ein Diagramm hoher Ebene, das ein Verfahren für eine deltacodierte Header-Unterdrückungstechnik gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 16B ist ein Diagramm hoher Ebene, das ein Verfahren für eine deltacodierte Header-Rekonstruktionstechnik gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 17 ist ein Diagramm. das ein Änderungsbyte gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 18 ist ein Diagramm, das einen endgültigen codierten Datenstrom gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 19 ist ein Diagramm, das die Übertragungsreihenfolge von Daten für die TCP-Header-Unterdrückung für einen nicht lernenden Zustand gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 20 ist ein Diagramm, das die Übertragungsreihenfolge von Daten für die TCP-Header-Unterdrückung für einen Lernzustand gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 21 ist ein Ablaufdiagramm, das ein Verfahren für die TCP-Header-Unterdrückung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 22 ist ein Ablaufdiagramm, das ein Verfahren für die TCP-Header-Rekonstruktion gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
  • 23 ist ein Diagramm, das ein beispielhaftes Computersystem veranschaulicht.
  • Die Merkmale, Aufgaben und Vorteile der vorliegenden Erfindung werden aus der ausführlichen Beschreibung, die unten dargelegt ist, wenn sie zusammen mit den Zeichnungen betrachtet wird, in denen gleiche Bezugszeichen durchgängig entsprechende Elemente identifizieren, besser ersichtlich. In den Zeichnungen beziehen sich gleiche Bezugszeichen im Allgemeinen auf identische, funktionell ähnliche und/oder strukturell ähnliche Elemente. Die Zeichnung, in der ein Element zum ersten Mal erscheint, wird mit der Zahl ganz links in dem entsprechenden Bezugszeichen angegeben.
  • Ausführliche Beschreibung der bevorzugten Ausführungsbeispiele
  • Obwohl die vorliegende Erfindung hier unter Bezugnahme auf veranschaulichende Ausführungsbeispiele für bestimmte Anwendungen beschrieben ist, sollte es klar sein, dass die Erfindung nicht darauf beschränkt ist. Diejenigen Fachleute auf dem Gebiet, die Zugang zu den hier bereitgestellten Lehren haben, werden zusätzliche Modifikationen, Anwendungen und Ausführungsbeispiele innerhalb des Schutzumgangs davon und zusätzliche Fachgebiete erkennen, in denen die vorliegende Erfindung von beträchtlichem Nutzen wäre.
  • A. Kabelmodemsystem in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung
  • 1 ist ein Blockdiagramm hoher Ebene eines beispielhaften Kabelmodem systems 100 in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung. Das Kabelmodemsystem 100 ermöglicht Sprachkommunikationen, Video- und Datendienste auf der Basis eines bidirektionalen Transfers von paketbasiertem Verkehr, wie etwa Internet Protocol (IP) Verkehr, zwischen einer Kabelsystemkopfstelle 102 und einer Vielzahl von Kabelmodems über ein Hybrid-Faser-Koaxial-(HFC)-Kabelnetzwerk 110. In dem beispielhaften Kabelmodemsystem 100 sind aus Gründen der Klarheit nur zwei Kabelmodems 106 und 108 gezeigt. Im Allgemeinen kann jegliche Anzahl von Kabelmodems in dem Kabelmodemsystem der vorliegenden Erfindung enthalten sein.
  • Die Kabelkopfstelle 102 besteht wenigstens aus einem Kabelmodem-Abschlusssystem (CMTS) 104. Das CMTS 104 ist der Abschnitt der Kabelkopfstelle 102, der die Upstream- und Downstream-Übertragung von Daten zwischen der Kabelkopfstelle 102 und den Kabelmodems 106 und 108 verwaltet, die sich beim Kunden befinden. Das CMTS 104 rundsendet Informationen downstream zu den Kabelmodems 106 und 108 als ein kontinuierlich übertragenes Signal in Übereinstimmung mit einem Zeitmultiplex-(TDM)-Verfahren. Außerdem steuert das CMTS 104 die Upstream-Übertragung von Daten von den Kabelmodems 106 und 108 zu sich selber, indem es jedem Kabelmodem 106 und 108 kurze Gewährungen von Zeit zu weist, innerhalb derer die Daten übertragen werden sollen. In Übereinstimmung mit diesem Zeitbereichs-Mehrfachzugriff-(TDMA)-Verfahren kann jedes Kabelmodem 106 und 108 Informationen upstream nur als Short-Burst-Signale während einer Übertragungsgelegenheit senden, die ihm von dem CMTS 104 zugeordnet worden ist.
  • Wie in 1 gezeigt ist, dient das CMTS 102 des Weiteren als eine Schnittstelle zwischen dem HFC-Netzwerk 110 und einem Paketvermittlungsnetz 112, die IP-Pakete, die von den Kabelmodems 106 und 108 empfangen werden, zu dem Paketvermittlungsnetz 112 überträgt, und die IP-Pakete, die von dem Paketvermittlungsnetz 112 empfangen werden, zu den Kabelmodems 106 und 108 überträgt, wenn dies geeignet ist. In Ausführungsbeispielen umfasst das Paketvermittlungsnetz 112 das Internet.
  • Zusätzlich zu dem CMTS 104 kann die Kabelkopfstelle 102 auch einen oder mehrere Internet-Router umfassen, um die Verbindung zwischen dem CMTS 104 und dem Paketvermittlungsnetz 112 zu ermöglichen, sowie auch einen oder mehrere Servers umfassen, um notwendige Netzwerkmanagementaufgaben durchzuführen.
  • Das HFC-Netzwerk 110 stellt eine Punkt-zu-Mehrpunkt-Topologie für den zuverlässigen und sicheren Hochgeschwindigkeits-Transport von Daten zwischen der Kabelkopfstelle 102 und den Kabelmodems 106 und 108 bei dem Kunden bereit. Wie den Fachleuten auf dem/den relevanten Fachgebiet(en) klar sein wird, kann das HFC-Netzwerk 110 Koaxialkabel, Glasfaserkabel oder eine Kombination aus Koaxialkabel und Glasfaserkabel verknüpft über einen oder mehrere Faserknoten umfassen.
  • Jedes der Kabelmodems 106 und 108 arbeitet als eine Schnittstelle zwischen dem HFC-Netzwerk 110 und wenigstens einer angeschlossenen Benutzervorrichtung. Insbesondere führen die Kabelmodems 106 und 108 die Funktionen durch, die notwendig sind, um Downstream-Signale, die über das HFC-Netzwerk 110 empfangen werden, in IP-Datenpakete für den Empfang durch eine angeschlossene Benutzervorrichtung umzuwandeln. Außerdem führen die Kabelmodems 106 und 108 die Funktionen durch, die notwendig sind, um IP-Datenpakete, die von der angeschlossenen Besuchervorrichtung empfangen werden, in Upstream-Burst-Signale umzuwandeln, die für die Übertragung über das HFC-Netzwerk 110 geeignet sind. In dem beispielhaften Kabelmodemsystem 100 ist jedes Kabelmodem 106 und 108 aus Gründen der Klarheit so gezeigt, dass es nur eine einzige Benutzervorrichtung unterstützt. Im Allgemeinen ist jedes Kabelmodem 106 und 108 in der Lage, eine Vielzahl von Benutzervorrichtungen für die Kommunikation über das Kabelmodemsystem 100 zu unterstützen. Benutzervorrichtungen können Personal Computers, Datenterminal-Einrichtungen, Telefonievorrichtungen, Breitbandmedienabspielgeräte, netzwerkgesteuerte Anwendungen oder jegliche andere Vorrichtung umfassen, die in der Lage ist, Daten über ein Paketvermittlungsnetz zu übertragen oder zu empfangen.
  • In dem beispielhaften Kabelmodemsystem 100 repräsentiert das Kabelmodem 106 ein konventionelles DOCSIS-konformes Kabelmodem. Mit anderen Worten, das Kabelmodem 106 überträgt Datenpakete zu dem CMTS 104 in Formaten, die die Protokolle befolgen, die in der DOCSIS-Spezifikation dargelegt sind. Das Kabelmodem 108 ist in ähnlicher Weise in der Lage, Datenpakete zu dem CMTS 104 in Standard-DOCSIS-Formaten zu übertragen. Aber in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung ist das Kabelmodem 108 auch so konfiguriert, dass es Datenpakete zu dem CMTS 104 unter Verwendung proprietärer Protokolle übertragen kann, die über die DOCSIS-Spezifikation hinausgehen. Nichtsdestotrotz ist das Kabelmodem 108 vollständig interoperabel mit den DOCSIS-konformen Kabelmodems, wie etwa dem Kabelmodem 106, und mit DOCSIS-konformen CMTS-Einrichtungen. Die Art und Weise, in der das Kabelmodem 108 arbeitet, um Daten zu übertragen, wird unten ausführlicher beschrieben werden.
  • Des Weiteren arbeitet das CMTS 104 in dem beispielhaften Kabelmodemsystem 100 derart, dass es Datenpakete empfängt und verarbeitet, die zu diesem in Übereinstimmung mit den Protokollen übertragen werden, die in der DOCSIS-Spezifikation dargelegt sind. Aber in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung kann das CMTS 104 auch so arbeiten, dass es Datenpakete empfängt und verarbeitet, die unter Verwendung proprietärer Protokolle formatiert worden sind, die über diejenigen hinausgehen, die von der DOCSIS-Spezifikation bereitgestellt werden, wie etwa Datenpakete, die von dem Kabelmodem 108 übertragen werden. Die Art und Weise, in der das CMTS 104 arbeitet, um Daten zu empfangen und zu verarbeiten, wird hier ebenfalls ausführlicher beschrieben werden.
  • B. Beispielhafte Kabelmodemsystemkomponenten in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung
  • 2 veranschaulicht ein schematisches Blockdiagramm einer Implementierung des CMTS 104 des Kabelmodemsystems 100, das beispielshalber präsentiert wird und nicht dafür bestimmt ist, die vorliegende Erfindung zu beschränken. Das CMTS 104 ist so konfiguriert, dass es Signale zu und von dem HFC-Netzwerk 110 empfangen und senden kann, wobei ein Teil davon durch die Glasfaser 202 in 2 repräsentiert wird. Dem gemäß wird das CMTS 104 in Form eines Empfängerabschnitts und eines Senderabschnitts beschrieben werden.
  • Der Empfängerabschnitt umfasst eine Glasfaser-zu-Koaxialkabel-Stufe 204, einen HF-Eingang 206, einen Splitter 214 und eine Vielzahl von Burst-Empfängern 216. Der Empfangsvorgang beginnt mit dem Empfang von Upstream-Burst-Signalen, die von einem oder mehreren Kabelmodems stammen, mittels der Glasfaser-zu-Koaxialkabel-Stufe 204 über die Glasfaser 202. Die Glasfaser-zu-Koaxialkabel-Stufe 204 routet die empfangenen Burst-Signale zu dem Hochfrequenz-(HF)-Eingang 206 über das Koaxialkabel 208. In Ausführungsbeispielen weisen diese Upstream-Burst-Signale spektrale Charakteristiken innerhalb des Frequenzbereichs von etwa 5-42 MHz auf.
  • Die empfangenen Signale werden von dem HF-Eingang 206 zu dem Splitter 214 des CMTS 104 geliefert, der die HF-Eingangssignale in N separate Kanäle aufteilt. Jeder der N separaten Kanäle wird dann einem separaten Burst-Receiver 216 bereitgestellt, der dahingehend arbeitet, die empfangenen Signale in jedem Kanal in Übereinstimmung mit einer Quadraturphasenumtastungs-(QPSK)- oder 16-Quadraturamplitudenmodulations-(QAM)-Technik zu demodulieren, um die zugrunde liegenden Informationssignale wiederherzustellen. Jeder Burst-Empfänger 216 wandelt die zugrunde liegenden Informationssignale auch von einer analogen Form in eine digitale Form um. Diese digitalen Daten werden dann nachfolgend der Kopfstellen-Medienzugriffssteuerung (MAC) 218 bereitgestellt.
  • Die Kopfstellen-MAC 218 arbeitet dahingehend, die digitalen Daten in Übereinstimmung mit der DOCSIS-Spezifikation, und wenn dies zweckdienlich ist, in Übereinstimmung mit proprietären Protokollen, die über die DOCSIS-Spezifikation hinausgehen, zu verarbeiten, was hier noch ausführlicher beschrieben werden wird. Die Funktionen der Kopfstellen-MAC 218 können in Hardware oder in Software implementiert werden. In der beispielhaften Implementierung von 2 sind die Funktionen der Kopfstellen-MAC 218 sowohl in Hardware als auch in Software imp lementiert. Softwarefunktionen der Kopfstellen-MAC 218 können in entweder dem Direktzugriffsspeicher (RAM) 220 oder in dem Nur-Lese-Speicher (ROM) 218 gespeichert und von der CPU 222 ausgeführt werden. Die Kopfstellen-MAC steht in elektrischer Kommunikation mit diesen Elementen sowohl über eine Ruckwandplatinen-Schnittstelle 220 als auch über ein gemeinsam genutztes Kommunikationsmedium 232. In Ausführungsbeispielen kann das gemeinsam genutzte Kommunikationsmedium 232 einen Computerbus oder ein Mehrfachzugriff-Datennetzwerk umfassen.
  • Die Kopfstellen-MAC 218 steht sowohl über die Rückwandplatinen-Schnittstelle 220 als auch über das gemeinsam genutzte Kommunikationsmedium 232 auch in elektrischer Kommunikation mit der Ethernet-Schnittstelle 224. Wenn es zweckdienlich ist, werden Ethernet-Pakete, die von der Kopfstellen-MAC 218 wiederhergestellt werden, zu der Ethernet-Schnittstelle 224 transferiert, um über einen Router zu dem Paketvermittlungsnetz 112 übermittelt zu werden.
  • Der Senderabschnitt des CMTS 104 umfasst einen Downstream-Modulator 226, ein Oberflächenwellen-(SAW; surface acoustic wave)-Filter 228, einen Verstärker 230, einen Zwischenfrequenz-(ZF)-Ausgang 212, einen Hochfrequenz-(HF)-Aufwärtskonvertierer 210 und die Glasfaser-zu-Koaxialkabel-Stufe 204. Der Sendevorgang beginnt mit der Erzeugung eines digitalen Rundsendesignals durch die Kopfstellen-MAC 218. Das digitale Rundsendesignal kann Daten enthalten, die ursprünglich von dem Paketvermittlungsnetz 112 über die Ethernet-Schnittstelle 224 empfangen wurden. Die Kopfstellen-MAC 218 gibt das digitale Rundsendesignal an den Downstream-Modulator 226 aus, der dieses in eine analoge Form umwandelt und es in Übereinstimmung mit entweder einem 64-QAM-Verfahren oder einem 256-QAM-Verfahren auf ein Trägersignal moduliert.
  • Die modulierte Trägersignalausgabe von dem Downstream-Modulator 256 wird in das SAW-Filter 228 eingegeben, das nur spektrale Komponenten des Signals übermittelt, die innerhalb einer gewünschten Bandbreite liegen. Das gefilterte Signal wird dann an einen Verstärker 230 ausgegeben, der dieses verstärkt und es an den ZF-Ausgang 212 ausgibt. Der ZF-Ausgang 212 routet das Signal zu dem HF-Aufwärtskonvertierer 210, der das Signal aufwärtskonvertiert. In Ausführungsbeispielen weist das aufwärtskonvertierte Signal spektrale Charakteristiken in dem Frequenzbereich von etwa 54-860 MHz auf. Das aufwärtskonvertierte Signal wird dann an die Glasfaser-zu-Koaxialkabel-Stufe 204 über das Koaxialkabel 208 ausgegeben. Die Glasfaser-zu-Koaxialkabel-Stufe 204 rundsendet das Signal über die Glasfaser 202 des HFC-Netzwerks 110.
  • 3 veranschaulicht ein schematisches Blockdiagramm einer Implementierung des Kabelmodems 107 des Kabelmodemsystems 100, das beispielshalber präsentiert wird, und ist nicht dafür bestimmt, die vorliegende Erfindung zu beschränken. Das Kabelmodem 108 ist so konfiguriert, dass es Signale zu und von dem HFC-Netzwerk 110 über den Koaxialstecker 332 von 3 empfangen und senden kann. Dem gemäß wird das Kabelmodem 108 vermittels eines Empfängerabschnitts und eines Senderabschnitts beschrieben.
  • Der Empfängerabschnitt umfasst ein Diplex-Filter 302, eine HF-Abstimmvorrichtung 304, ein SAW-Filter 306 und einen Verstärker 308 und einen Downstream-Empfänger 310. Der Empfangsvorgang beginnt mit dem Empfang eines Downstream-Signals, das von dem CMTS 104 stammt, mittels des Diplex-Filters 302. Das Diplex-Filter 302 arbeitet dahingehend, das Downstream-Signal zu isolieren und dieses zu der HF-Abstimmvorrichtung 304 zu routen. In Ausführungsbeispielen weist das Downstream-Signal spektrale Charakteristiken in dem Frequenzbereich von etwa 54-860 MHz auf. Die HF-Abstimmvorrichtung 304 wandelt das Signal abwärts und gibt dieses an das SAW-Filter 306 aus, das nur die spektralen Komponenten des abwärtsgewandelten Signals übermittelt, die sich in einer gewünschten Bandbreite befinden. Das gefilterte Signal wird an den Verstärker 308 ausgegeben, der es verstärkt und zu dem Downstream-Empfänger 310 übermittelt. Automatische Verstärkungsregelungen werden der HF-Abstimmvorrichtung 304 von dem Downstream-Empfänger 310 bereitgestellt.
  • Der Downstream-Empfänger 310 demoduliert das verstärkte Signal in Übereinstimmung mit entweder einer 64-QAM-Technik oder einer 256-QAM-Technik, um das zugrunde liegende Informationssignal wiederherzustellen. Der Downstream-Empfänger 310 wandelt das zugrunde liegende Informationssignal auch von der analogen Form in die digitale Form um. Diese digitalen Daten werden danach der Medienzugriffssteuerung (MAC) 314 bereitgestellt.
  • Die MAC 314 verarbeitet die digitalen Daten, die zum Beispiel Ethernet-Pakete für die Übertragung zu einer angeschlossenen Benutzervorrichtung umfassen können. Die Funktionen der MAC 314 können in Hardware oder in Software imple mentiert werden. In der beispielhaften Implementierung von 3 sind die Funktionen der MAC 314 sowohl in Hardware, als auch in Software implementiert. Software-Funktionen der MAC 314 können in entweder dem RAM 322 oder dem ROM 324 gespeichert und von der CPU 320 ausgeführt werden. Die MAC 314 steht über ein gemeinsam genutztes Kommunikationsmedium 316 in elektrischer Kommunikation mit diesen Elementen. In Ausführungsbeispielen kann das gemeinsam genutzte Kommunikationsmedium einen Computerbus oder ein Mehrfachzugriff-Datennetzwerk umfassen.
  • Die MAC 314 steht über das gemeinsam genutzte Kommunikationsmedium 316 auch in elektrischer Kommunikation mit der Ethernet-Schnittstelle 318. Wenn es zweckdienlich ist, werden die Ethernet-Pakete, die von der MAC 314 wiederhergestellt werden, zu der Ethernet-Schnittstelle 318 für die Übertragung zu einer angeschlossenen Benutzervorrichtung übertragen.
  • Der Senderabschnitt des Kabelmodems 108 umfasst einen Upstream-Burst-Modulator 326, ein Tiefpassfilter 328, einen Leistungsverstärker 330 und das Diplex-Filter 302. Die Übertragung beginnt mit der Konstruktion eines Datenpakets durch die MAC 314. Das Datenpaket kann Daten umfassen, die ursprünglich von einer angeschlossenen Benutzervorrichtung über die Ethernet-Schnittstelle 318 empfangen wurden. In Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung kann die MAC 314 das Datenpaket in Übereinstimmung mit den Protokollen formatieren, die in der DOCSIS-Spezifikation dargelegt sind, oder, falls zweckdienlich, kann sie das Datenpaket in Übereinstimmung mit einem proprietären Protokoll formatieren, das sich über diejenigen, die in der DOCSIS-Spezifikation dargelegt sind, hinaus erstreckt, was hier noch ausführlicher beschrieben werden wird. Die MAC 314 gibt das Datenpaket an den Upstream-Burst-Modulator 326 aus, der dieses in eine analoge Form umwandelt und es auf ein Trägersignal in Übereinstimmung mit entweder einer QPSK-Technik oder einer 16-QAM-Technik moduliert.
  • Der Upstream-Burst-Modulator 326 gibt das modulierte Trägersignal an das Tiefpassfilter 328 aus, das Signale mit spektralen Charakteristiken in einer gewünschten Bandbreite übermittelt. In Ausführungsbeispielen liegt die gewünschte Bandbreite innerhalb des Frequenzbereichs von etwa 5-42 MHz. Die gefilterten Signale werden dann in den Leistungsverstärker 330 eingeführt, der das Signal verstärkt und es dem Diplex-Filter 302 bereitstellt. Die Verstärkung in dem Leistungsverstär ker 330 wird von dem Burst-Modulator 326 geregelt. Das Diplex-Filter 302 isoliert das verstärkte Signal und sendet es upstream über das HFC-Netzwerk 110 während einer geplanten Burst-Gelegenheit.
  • C. Unterstützung erweiterter Datenübertragungsprotokolle in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung
  • Wie oben angemerkt worden ist, senden und empfangen das Kabelmodem 108 und das CMTS 104 Daten in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung jeweils in proprietären Formaten, die sich über Standard-DOCSIS-Protokolle hinaus erstrecken. Zum Beispiel modifiziert in Ausführungsbeispielen das Kabelmodem 108 Datenpakete in Übereinstimmung mit einem proprietären Header-Unterdrückungsverfahren für die Übertragung zu dem CMTS 104, und bei Empfang der modifizierten Datenpakete rekonstruiert das CMTS 104 diese in Übereinstimmung mit dem gleichen proprietären Header-Komprimierungsverfahren.
  • In weiterer Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung ist das Kabelmodem 108 nichtsdestotrotz interoperabel mit herkömmlichen DOCSIS-konformen CMTS-Einrichtungen, die anders als das CMTS 104 keine Unterstützung für erweiterte Protokolle bereitstellen. Das Kabelmodem 108 erzielt diesen Zweck, indem es ermittelt, ob es mit einem CMTS kommuniziert, das erweiterte Protokolle unterstützt, wie z.B. das CMTS 104, oder ob es mit einem CMTS kommuniziert, das dies nicht tut. Wenn das CMTS erweiterte Protokolle nicht unterstützt, dann überträgt das Kabelmodem 108 die Daten formatiert in Übereinstimmung mit Standard-DOCSIS-Protokollen anstatt in Übereinstimmung mit erweiterten Protokollen.
  • 4 veranschaulicht ein Ablaufdiagramm 400 eines Verfahrens zum Unterstützen erweiterter Protokolle in einem Kabelmodemsystem in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung, das diesen Prozess ausführlicher erläutert. Die Erfindung ist aber nicht auf die Beschreibung beschränkt, die von dem Ablaufdiagramm 400 bereitgestellt wird. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) aus den hier bereitgestellten Lehren klar sein, dass andere funktionelle Abläufe innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Das Ablaufdiagramm 400 wird unter fortgesetzter Bezugnahme auf das beispielhafte CMTS 104 und das beispielhafte Kabelmodem 108 des Kabelmo demsystems 100 sowie unter Bezugnahme auf eine beispielhafte Hardware-Implementierung des Kabelmodems 108 von 3 beschrieben.
  • Im Schritt 402 sendet das Kabelmodem 108 eine Registrierungsnachricht an das CMTS 104, die eine Unterstützung für ein erweitertes Protokoll designiert. Hinsichtlich der beispielhaften Implementierung des Kabelmodems 108, die unter Bezugnahme auf 3 beschrieben ist, konstruiert die MAC 314 die Registrierungsnachricht sowie auch andere MAC-Maintenance-Nachrichten, die von dem Kabelmodem 108 ausgegeben werden.
  • In Ausführungsbeispielen sendet das Kabelmodem 108 diese Registrierungsnachricht als einen Teil eines Austausches von Registrierungsnachrichten, die zwischen einem Kabelmodem und einem CMTS stattfinden müssen, wenn das Kabelmodem zum ersten Mal in dem HFC-Netzwerk erscheint. In Übereinstimmung mit der DOCSIS-Spezifikation umfasst dieser Austausch von Registrierungsnachrichten im Allgemeinen das Senden einer Registrierungsanforderungs-(REG-REQ)-Nachricht von dem Kabelmodem zu dem CMTS und das Senden einer Registrierungsantwort-(REG-RSP)-Nachricht von dem CMTS zu dem Kabelmodem in Reaktion auf die empfangene REG-REQ-Nachricht. Dieses Registrierungsprotokoll ist auf dem Fachgebiet allgemein bekannt.
  • In Ausführungsbeispielen meldet das Kabelmodem 108 dem CMTS 104, dass es ein erweitertes Protokoll unterstützt, indem es einen erweiterten Protokollunterstützungs-Deskriptor in einem händlerspezifischen Informationsfeld der REG-REQ-Nachricht platziert, die zu dem CMTS 104 gesendet wird. Im umgekehrten Fall bezeichnet in solchen Ausführungsbeispielen das Nichtvorhandensein eines erweiterten Protokollunterstützungs-Deskriptors in einem händlerspezifischen Informationsfeld der REG-REQ-Nachricht, dass ein Kabelmodem nur Standard-DOCSIS-Protokolle unterstützt.
  • Beim Schritt 404 empfängt das Kabelmodem 108 eine Antwort auf die Registrierungsnachricht von dem CMTS 104, die anzeigt, ob das CMTS 104 das erweiterte Protokoll unterstützt oder nicht. Da das CMTS 104 des beispielhaften Kabelmodemsystems 100 das gleiche erweiterte Protokoll wie das Kabelmodem 108 unterstützt, wie dies oben erörtert worden ist, wird die Antwort auf die Registrierungsnachricht anzeigen, dass das erweiterte Protokoll unterstützt wird. Aber wenn das CMTS 104 das erweiterte Protokoll nicht unterstützen würde (wenn es zum Beispiel ein herkömmliches DOCSIS-konformes CMTS wäre), dann würde die Antwort auf die Registrierungsnachricht eine Anzeige enthalten, dass es dem CMTS 104 nicht gelungen ist, das erweiterte Protokoll zu erkennen. Zum Beispiel kann die Antwort in Ausführungsbeispielen, bei denen die Registrierungsnachricht eine REG-REQ-Nachricht umfasst, die einen erweiterten Protokollunterstützungs-Deskriptor in einem händlerspezifischen Informationsfeld umfasst, eine REG-RSP-Nachricht sein, die anzeigt, dass es dem CMTS 104 nicht gelungen ist, den erweiterten Protokollunterstützungs-Deskriptor zu erkennen.
  • Wenn die Antwort auf die Registrierungsnachricht anzeigt, dass das erweiterte Protokoll von dem CMTS unterstützt wird, dann wird das Kabelmodem 108 Datenpakete für die Übertragung zu dem CMTS in Übereinstimmung mit dem erweiterten Protokoll formatieren, wie dies von den Schritten 406 und 408 gezeigt ist. Wenn andererseits die Antwort auf die Registrierungsnachricht anzeigt, dass das CMTS das erweiterte Protokoll nicht unterstützt, dann wird das Kabelmodem 108 Datenpakete für die Übertragung zu dem CMTS in Übereinstimmung mit Standard-DOCSIS-Protokollen formatieren, wie dies von den Schritten 406 und 410 gezeigt ist. Wie oben unter Bezugnahme auf die beispielhafte Implementierung des Kabelmodems 108, die in 3 veranschaulicht ist, erörtert wurde, ist die MAC 314 verantwortlich für die Formatierung von Datenpaketen für die Übertragung zu dem CMTS.
  • In alternativen Ausführungsbeispielen der vorliegenden Erfindung kann ein privater Kommunikationskanal anstelle des Standard-DOCSIS-REG-REQ/-REG-RSP-Protokolls, das oben beschrieben ist, verwendet werden, um die Schritte 402 und 404 des Ablaufdiagramms 400 zu implementieren. Zum Beispiel sendet in einem solchen Ausführungsbeispiel das CMTS 104 eine Unicast-UDP-Nachricht an das Kabelmodem 108 im Anschluss an eine erfolgreiche Kabelmodemregistrierung, die anzeigt, dass das CMTS 104 in der Lage ist, erweiterte Protokolle zu unterstützen (wobei dieser Schritt in 4 nicht gezeigt ist). Wenn das Kabelmodem 108 ein erweitertes Protokoll unterstützt, antwortet es auf die UDP-Nachricht, indem es eine UDP-Antwort sendet, die anzeigt, welches erweiterte Protokoll von ihm unterstützt wird. In Übereinstimmung mit dieser Technik umfasst die Registrierungsnachricht von Schritt 402 die UDP-Antwort von dem Kabelmodem 108. In Ausführungsbeispielen zeigt die UDP-Antwort auch den spezifischen Grad an, in dem das Kabelmodem 108 in der Lage ist, das erweiterte Protokoll zu unterstützen.
  • Wenn das Kabelmodem kein erweitertes Protokoll unterstützt, sendet es keine Antwort auf die UPD-Nachricht. In Ausführungsbeispielen sendet das CMTS 104 die UDP-Nachricht eine vorbestimmte Anzahl von Malen erneut, und wenn keine Antwort von dem Kabelmodem nach der vorbestimmten Anzahl von erneuten Übertragungen erhalten wird, stellt das CMTS 104 fest, dass das Kabelmodem keine erweiterten Protokolle unterstützt. Aber wenn das CMTS 104 eine geeignete UDP-Antwort von dem Kabelmodem 108 empfängt, erfasst es die erweiterten Protokollfähigkeiten des Kabelmodems 108 und antwortet mit einer zweiten UDP-Nachricht, die anzeigt, ob es das spezifische erweiterte Protokoll, das von dem Kabelmodem 108 unterstützt wird, unterstützt oder nicht. In Übereinstimmung mit dieser Technik umfasst die Antwort auf die Registrierungsnachricht von Schritt 404 die zweite UDP-Nachricht von dem CMTS 104.
  • Das Verfahren, das in dem Ablaufdiagramm 400 beschrieben wird, gewährleistet die Interoperabilität zwischen einem Kabelmodem, das ein erweitertes Protokoll unterstützt, in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung und CMTS-Einrichtungen, die nicht das gleiche Protokoll unterstützen. In ähnlicher Weise ist ein CMTS, das ein erweitertes Protokoll in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung unterstützt, wie etwa das CMTS 104, interoperabel mit einem Kabelmodem, das das gleiche erweiterte Protokoll nicht unterstützt. Zum Beispiel ist das CMTS 104 interoperabel mit herkömmlichen DOCSIS-konformen Kabelmodems, die erweiterte Protokolle nicht unterstützen, wie etwa das Kabelmodem 106. Das CMTS 104 erzielt diesen Zweck, indem es feststellt, ob ein empfangenes Paket von einem herkömmlichen DOCSIS-konformen Kabelmodem, wie etwa dem Kabelmodem 106, oder von einem Kabelmodem gesendet wurde, das in der Lage ist, Daten unter Verwendung erweiterter Protokolle zu übertragen, wie etwa das Kabelmodem 108, und das Paket entsprechend verarbeitet.
  • 5 veranschaulicht ein Ablaufdiagramm 500 eines Verfahrens zum Unterstützen erweiterter Protokolle in einem Kabelmodemsystem in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung, das diesen Prozess ausführlicher beschreibt. Die Erfindung ist aber nicht auf die Beschreibung beschränkt, die von dem Ablaufdiagramm 500 bereitgestellt wird. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) aus den hier bereitgestellten Lehren klar sein, dass andere funktionelle Abläufe innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Das Ablaufdiagramm 500 wird unter fortgesetzter Bezugnahme auf das beispielhafte CMTS 104 und die beispielhaften Kabelmodems 106 und 108 des Kabelmodemsystems 100 sowie auch unter Bezugnahme auf die beispielhafte Hardware-Implementierung des CMTS 104 von 2 beschrieben.
  • Beim Schritt 502 empfängt das CMTS eine Registrierungsnachricht von einem Kabelmodem, die ein Datenübertragungsprotokoll designiert, das von dem Kabelmodem unterstützt wird. Im Hinblick auf das beispielhafte Kabelmodemsystem 100 von 1 kann die Registrierungsnachricht von dem Kabelmodem 106 stammen, in welchem Fall die Nachricht die Datenübertragung in Übereinstimmung mit Standard-DOCSIS-Protokollen designiert, oder die Registrierungsnachricht kann von dem Kabelmodem 108 stammen, in welchem Fall die Nachricht die Datenübertragung in Übereinstimmung mit einem erweiterten Protokoll designiert. In Ausführungsbeispielen ist die Registrierungsnachricht eine DOCSIS-REG-REQ-Nachricht, und das Vorhandensein eines erweiterten Protokoll-Deskriptors in einem händlerspezifischen Feld der REG-REQ-Nachricht designiert eine Datenübertragung in Übereinstimmung mit einem erweiterten Protokoll, während das Nichtvorhandensein des erweiterten Protokoll-Deskriptors die Datenübertragung in Übereinstimmung mit Standard-DOCSIS-Protokollen designiert.
  • Beim Schritt 504 weist das CMTS 104 dem Kabelmodem eine einzigartige Kabelmodem-ID zu und sendet die Kabelmodem-ID zu dem Kabelmodem. In Ausführungsbeispielen umfasst die Kabelmodem-ID die primäre DOCSIS-Dienstkennung (SID, service ID), die von dem CMTS zugewiesen wird und zu dem Kabelmodem als Teil der DOCSIS-REG-RSP-Nachricht gesendet wird. Im Hinblick auf die beispielhafte Implementierung des CMTS 104, die unter Bezugnahme auf 2 beschrieben ist, ist die Kopfstellen-MAC 218 verantwortlich für das Zuweisen einer einzigartigen Kabelmodem-ID zu dem Kabelmodem.
  • Beim Schritt 506 erzeugt das CMTS 104 eine Speicherassoziation zwischen der Kabelmodem-ID und einem Protokollindikator, der das Datenübertragungsprotokoll anzeigt, das von dem Kabelmodem unterstützt wird. Im Hinblick auf die beispielhafte Implementierung des CMTS 104, die unter Bezugnahme auf 2 beschrieben ist, wird diese Aufgabe von der Kopfstellen-MAC 218 ausgeführt, die die Kabelmodem-ID und den Protokollindikator als assoziierte Werte in entweder dem ROM 218 oder dem RAM 220 speichert. In Ausführungsbeispielen speichert das CMTS 104 die Kabelmodem-ID und den Protokollindikator als assoziierte Werte in einer Nachschlagetabelle.
  • Beim Schritt 508 empfängt das CMTS 104 eine Anforderung bezüglich einer Übertragungsgelegenheit von einem Kabelmodem, die die Kabelmodem-ID umfasst, die mit dem Kabelmodem assoziiert ist. In Ausführungsbeispielen wird die Anforderung in einem Anforderungskonkurrenzbereich (request contention area) empfangen, der von einer DOCSIS-Zuordnungs-MAP definiert ist. Die Zuordnungs-MAP ist eine MAC-Managementnachricht variierender Länge, die von dem CMTS auf dem Downstream-Kanal übertragen wird, die für ein gewisses Zeitintervall die Verwendungen beschreibt, für die die Upstream-Bandbreite verwendet werden muß. Die Zuordnungs-MAP ordnet Bandbreite in Form von Basiszeiteinheiten zu, die Minislots genannt werden. Eine gegebene Zuordnungs-MAP kann einige Minislots als eine Gewährung für ein bestimmtes Kabelmodem beschreiben, um Daten darin zu senden, und kann andere Minislots als für die Konkurrenzübertragung durch mehrere Kabelmodems verfügbar beschreiben. Die DOCSIS-Zuordnungs-MAP ist in der DOCSIS-Spezifikation beschrieben und ist in dem Fachgebiet wohl bekannt.
  • Beim Schritt 510 ordnet das CMTS 104 dem Kabelmodem eine Übertragungsgelegenheit im Ansprechen auf die Anforderung bezüglich einer Übertragungsgelegenheit zu. In Ausführungsbeispielen weist das CMTS 104 dem Kabelmodem eine Übertragungsgelegenheit zu, indem es dem Kabelmodem eine Anzahl von Minislots in einer DOCSIS-Zuordnungs-MAP für die Übertragung von Daten upstream in Übereinstimmung mit der DOCSIS-Spezifikation zuweist. Im Hinblick auf die beispielhafte Implementierung des CMTS 104, die unter Bezugnahme auf 2 beschrieben ist, wird die Konstruktion einer MAP-Zuordnungsnachricht von der Kopfstellen-MAC 218 ausgeführt.
  • Beim Schritt 512 verwendet das CMTS 104 die Kabelmodem-ID aus der Anforderung bezüglich der Übertragungsgelegenheit, um auf den Protokollindikator zuzugreifen, der mit der Kabelmodem-ID assoziiert ist, die in einem vorhergehenden Schritt 506 in einem Speicher gespeichert worden ist. In Ausführungsbeispielen konsultiert das CMTS 104 eine Nachschlagetabelle, die die Kabelmodem-ID dem Protokollindikator zuordnet. Im Hinblick auf die beispielhafte Implementierung des CMTS 104, die unter Bezugnahme auf 2 beschrieben ist, wird dieser Schritt von der Kopfstellen-MAC 218 ausgeführt.
  • Beim Schritt 514 verarbeitet das CMTS 104 Daten, die von dem Kabelmodem während der zugeordneten Übertragungsgelegenheit in Übereinstimmung mit dem Datenübertragungsprotokoll übertragen worden sind, das von dem Indikator angezeigt worden ist. Wenn zum Beispiel der Indikator anzeigt, dass ein erweitertes Protokoll unterstützt wird, wie bei dem Fall des Kabelmodems 108, dann wird das CMTS 104 das Datenpaket, das es von dem Kabelmodem zu empfangen erwartet, in Übereinstimmung mit einem erweiterten Protokoll verarbeiten. Wenn keine Unterstützung für ein erweitertes Protokoll angezeigt wird, wie dies bei dem Kabelmodem 106 der Fall ist, dann wird das CMTS 104 das Datenpaket, das es von dem Kabelmodem zu empfangen erwartet, in Übereinstimmung mit Standard-DOCSIS-Protokollen verarbeiten. Im Hinblick auf die beispielhafte Implementierung des CMTS 104, die unter Bezugnahme auf 2 beschrieben ist, wird die Verarbeitung von Datenpaketen von der Kopfstellen-MAC 218 durchgeführt.
  • Auf diese Weise erfasst und speichert das CMTS 104 in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung während einer Kabelmodemregistrierung Informationen über die Fähigkeiten des Kabelmodems, mit dem es kommunizieren wird. Wenn das CMTS 104 danach einem Kabelmodem eine Upstream-Bandbreite zuordnet, greift es auf die gespeicherten Informationen zu, um festzustellen, wie es die Daten verarbeiten soll, die es von dem Kabelmodem zu empfangen erwartet. Diese Technik wird durch die TDMA-Aspekte eines Kabelmodemsystems ermöglicht, was erfordert, dass das CMTS Kenntnis davon hat, von welchem Kabelmodem es Daten zu einem gegebenen Zeitpunkt empfängt. Diese Technik ist vorteilhaft, weil sie die Verwendung von Protokollen erlaubt, die über DOCSIS hinausgehen, während sie die Interoperabilität gewährleistet, indem an Standard-DOCSIS-Registrierungs-, -Anforderungs- und Gewährungs-Protokollen festgehalten wird.
  • 1. Paket-Header-Unterdrückung
  • Die 6A-8 sind nützlich für die Erklärung einer Art und Weise, in der Pakete in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung von dem Kabelmodem 108 komprimiert und von dem CMTS 104 dekomprimiert werden.
  • 6A repräsentiert ein Datenpaket 605, das von einer Benutzervorrichtung zur Übertragung über das HFC-Netzwerk 110 erzeugt worden ist. Das Datenpaket 605 umfasst einen MAC-Header 607, einen IP-Header 609, einen UDP-Header 611, einen RTP-Header 613 und eine Nutzlast 615. In diesem Beispiel umfasst der MAC-Header 607 14 Bytes, der IP-Header 609 umfasst 20 Bytes, der UDP-Header 611 umfasst 12 Bytes, der RTP-Header 613 umfasst 8 Bytes und die Nutzlast 615 umfasst irgendeinen Wert von 1 bis N Bytes, und zwar in Abhängigkeit von dem Typ an Daten, die gesendet werden.
  • In Übereinstimmung mit der vorliegenden Erfindung kann das Datenpaket 605 von einem Anwendungsprogramm erzeugt werden, das auf der Benutzervorrichtung 116 abläuft, wie oben unter Bezugnahme auf 1 beschrieben worden ist. Zum Beispiel kann ein Anwendungsprogramm, das auf der Benutzervorrichtung 116 abläuft, Sprach- oder Dateninformationen für die Übertragung über das HFC-Netzwerk 110 erzeugen. Diese Sprach- oder Dateninformationen umfassen die Nutzlast 615 des Datenpakets 605. Das Anwendungsprogramm, das auf der Benutzervorrichtung 116 abläuft, wird den IP-Header 609, den UDP-Header 611 und den RTP-Header 613 an die Nutzlast 615 anhängen, um eine Übertragung in Übereinstimmung mit Standard-IP-Protokollen zu erlauben. Eine Ethernet-Karte in der Benutzervorrichtung 116 wird des Weiteren den MAC-Header 607 an das Datenpaket 605 anhängen, um eine Übertragung in Übereinstimmung mit Standard-Ethernet-Protokollen zu erlauben.
  • Beim Empfang des Datenpakets 605 unterdrückt das Kabelmodem das Datenpaket 605 in Übereinstimmung mit irgendeiner gewünschten Header-Unterdrückungstechnik. Beispiele für Header-Unterdrückungstechniken umfassen die Standard-DOCSIS-PHS sowie auch Techniken, die über Standard-DOCSIS-Protokolle hinausgehen, wie etwa die dynamische Deltacodierung und die RTP-Codierung, die hier noch ausführlicher beschrieben werden. Nach dem Lesen dieser Patentschrift würde ein Fachmann auf dem/den relevanten Fachgebiet(en) erkennen, dass jegliche Anzahl von Unterdrückungstechniken verwendet werden kann, ohne dass vom Schutzumfang der vorliegenden Erfindung abgewichen wird.
  • 6B repräsentiert das Aussehen des Datenpakets 605, nachdem es komprimiert ist, um ein komprimiertes Datenpaket 610 in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung zu erzeugen. In diesem exemplarischen Ausführungsbeispiel sind der IP-Header 609, der UDP-Header 611 und der RTP-Header 613 eliminiert und durch einen Ein-Byte-Index 617 ersetzt. Dem gemäß 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 verwendet, um anzuzeigen, dass das Datenpaket 610 komprimiert worden ist. Der Index 617 wird auch dazu verwendet, die spezielle Unterdrückungstechnik anzuzeigen, die verwendet wurde, um das Datenpaket zu komprimieren. Weitere Einzelheiten des Index 617 werden unten unter Bezugnahme auf 7 beschrieben werden. Als eine Folge der Eliminierung der oben spezifizierten Headers ist das komprimierte Datenpaket 610 um 40 Bytes kleiner als das ursprüngliche Datenpaket 605.
  • 6C ist ein Beispiel für einen gemischten Protokoll-DOCSIS-Sende-Burst (d.h., SID) 606, der mehrere Pakete enthält, die in Übereinstimmung mit den Ausführungsbeispielen der vorliegenden Erfindung unterdrückt wurden. Die gemischte Protokoll-SID 606 besteht aus dem komprimierten Datenpaket 610 und zusätzlichen komprimierten Datenpaketen 612 und 614. In einem Ausführungsbeispiel ist das komprimierte Datenpaket 610 unter Verwendung der DOCSIS PHS komprimiert, wie dies von dem Index 617 angezeigt wird. Das komprimierte Datenpaket 612 ist unter Verwendung der dynamischen Deltacodierung komprimiert, wie dies von dem Index 619 angezeigt wird, und das komprimierte Datenpaket 614 ist unter Verwendung der RTP-Codierung komprimiert worden, wie dies von dem Index 621 angezeigt ist. Die Indizes 617, 619 und 621 trennen die Pakete innerhalb der gemischten Protokoll-SID 606. Diese Trennung ist im Wesentlichen ein Framing-Protokoll. Auf diese Weise ist die gemischte Protokoll-SID 606 in der Lage, mehrere Pakete zu senden, die mittels verschiedener Paket-Header-Unterdrückungstechniken unterdrückt worden sind.
  • 7 veranschaulicht ein Ablaufdiagramm 700 eines Verfahrens zum Komprimieren von Paketen unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung. Die Erfindung ist aber nicht auf die hier im Hinblick auf das Ablaufdiagramm 700 bereitgestellte Beschreibung beschränkt. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren klar sein, dass andere funktionelle Abläufe innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Das Ablaufdiagramm 700 wird unter fortgesetzter Bezugnahme auf das beispielhafte Kabelmodemsystem 100 von 1 beschrieben werden.
  • Beim Schritt 702 wird das Kabelmodem 108 eingeschaltet und initiiert eine Handshaking-Routine mit dem CMTS 104 über das HFC-Netzwerk 110. Während dieses Initialisierungsprozesses designiert bzw. bestimmt das Kabelmodem 108 eine oder mehrere Indexzahlen, um einen bestimmten Typ von Paket-Header-Unterdrückungstechnik zu repräsentieren. Zum Beispiel kann der Index 1 für die DOCSIS PHS Unterdrückung bestimmt werden, während die Indexzahlen 2 bis 10 für die Verwendung mit der dynamischen Deltacodierung bestimmt werden können. Noch weiter können die Indexzahlen 11 bis 20 für die Verwendung mit der RTP-Codierung bestimmt werden. Wenn diese Designierungen einmal getätigt sind, wird diese Information zu dem CMTS 104 über das HFC-Netzwerk 110 kommuniziert. Während des Initialisierungsprozesses werden auch die Regeln, die mit der Unterdrückung und Expandierung eines Pakets in Übereinstimmung mit den zur Verfügung stehenden Unterdrückungstechniken assoziiert sind, ausgetauscht. Die Regeln werden dem CMTS 104 von dem Kabelmodem 108 bereitgestellt. Das CMTS 104 speichert die Indexzahlen und ihre entsprechenden Regeln in einer Nachschlagetabelle für ein späteres Abrufen während des Paketexpandierungsprozesses.
  • In Ausführungsbeispielen ist der oben beschriebene Initialisierungsprozess Teil von Standard-DOCSIS-Kabelmodemregistrierungsprotokollen. In alternativen Ausführungsbeispielen kann ein privater Kommunikationskanal, der vorher unter Bezugnahme auf 4 beschrieben worden ist, verwendet werden, um den Transfer von Indexzahlen und Regeln zu ermöglichen. Dies kann im Besonderen in DOCSIS 1.0 Kabelmodemsystemen vorteilhaft sein, in denen das DOCSIS-Protokoll keine Klassifizierungs-/Header-Unterdrückungs-Fähigkeit definiert.
  • Beim Schritt 704 empfängt das Kabelmodem 108 ein Datenpaket von der Benutzervorrichtung 116. Das Datenpaket kann zum Beispiel das Datenpaket 605 von 6A sein. Beim Schritt 706 stellt das Kabelmodem 108 fest, ob das Datenpaket in Übereinstimmung mit der vorliegenden Erfindung unterdrückt werden soll. In einem Ausführungsbeispiel wird das Kabelmodem 108 das Datenpaket nicht unterdrücken, wenn es ein nicht komprimierbares Paket (d.h., kein IP-Paket) ist. In diesem Fall würde das Kabelmodem 108 das Datenpaket mit seinem vollen Header übertragen.
  • Beim Schritt 708 wird das Kabelmodem 108 eine geeignete Paket-Header-Unterdrückungstechnik für diejenigen Datenpakete auswählen, die im Schritt 706 identifiziert worden sind. In einem Ausführungsbeispiel, bei dem Datenpakete von einem unbekannten IP-Datagramm-Typ sind, wird DOCSIS PHS ausgewählt. Für IP/RTP-Datenpakete (d.h., Sprachpakete) wird die RTP-Unterdrückung ausgewählt. Für IP/TCP-Datenpakete variabler Länge wird die dynamische Deltaunterdrückung ausgewählt.
  • Beim Schritt 710 wird das Kabelmodem 108 ein Paket-Header-Element an das Datenpaket anhängen, das unterdrückt wird. Das Paket-Header-Element enthält die Indexzahl, die im Schritt 702 für die bestimmte Unterdrückungstechnik bestimmt wurde, die im Schritt 708 ausgewählt worden ist.
  • Beim Schritt 712 wird das Datenpaket in Übereinstimmung mit den Regeln unterdrückt, die mit der Unterdrückungstechnik assoziiert sind, die im Schritt 708 ausgewählt worden ist. Das resultierende komprimierte Datenpaket kann zum Beispiel das komprimierte Datenpaket 610 von 6B sein. In Übereinstimmung mit der vorliegenden Erfindung gestatten die Schritte (704-712) die Unterdrückung von Datenpaketen in Übereinstimmung mit jeder gewünschten Header-Unterdrückungstechnik. Die Indexzahl, die mit jedem Datenpaket assoziiert ist, identifiziert den Beginn des Datenpakets. Folglich ist die Indexzahl ein nützlicher Mechanismus zur Trennung eines Datenpakets von einem anderen und zur Identifizierung der speziellen Header-Unterdrückungstechnik, die verwendet wird, um jedes Datenpaket zu verarbeiten.
  • Wie vorher erörtert worden ist, ermöglicht das DOCSIS-Protokoll die Verkettung von Datenpaketen, aber es erlaubt nicht das Mischen von unterschiedlichen Header-Unterdrückungstechniken innerhalb eines einzelnen DOCSIS-Sende-Burst bzw. einer einzelnen SID. Aber weil die Indexzahl, die in dem Paket-Header-Element enthalten ist, der im Schritt 710 angehängt worden ist, eine Einrichtung zum Trennen der Pakete bereitstellt, ist das Mischen von unterschiedlichen Header-Unterdrückungstechniken innerhalb einer SID nun möglich. Dem gemäß wird in einem alternativen Ausführungsbeispiel eine gemischte Protokoll-SID im Schritt 714 erzeugt.
  • Im Schritt 714 werden die Datenpakete miteinander verkettet. Als Folge von verketteten Paketen, die mit unterschiedlichen Header-Unterdrückungstechniken unterdrückt worden sind, kann die SID nun als eine gemischte Protokoll-SID betrachtet werden. Im Wesentlichen dient der Index als ein Framing-Protokoll, das die Pakete innerhalb der gemischten Protokoll-SID trennt sowie auch den Typ an Header-Unterdrückung kommuniziert, der bei jedem Datenpaket innerhalb der gemischten Protokoll-SID verwendet wird. In einem Ausführungsbeispiel kann die gemischte Protokoll-SID zum Beispiel die gemischte Protokoll-SID 606 von 6C sein. Schließlich wird im Schritt 716 die gemischte Protokoll-SID zu einem CMTS 104 gesendet.
  • 2. Paket-Header-Expandierung
  • 8 ist ein Ablaufdiagramm eines Verfahrens zum Expandieren bzw. Dekomprimieren von Paketen, die unter Verwendung verschiedener Paket-Header-Unterdrückungstechniken in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung komprimiert worden sind.
  • Beim Schritt 802 empfängt das CMTS 104 eine gemischte Protokoll-SID, die aus einem oder mehreren Datenpaketen besteht.
  • Beim Schritt 805 überprüft das CMTS 104 jedes der Datenpakete, um festzustellen, 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 gefunden wird, dann ist das Datenpaket nicht unterdrückt worden, und die Steuerung geht unmittelbar zum Schritt 820 weiter.
  • Beim Schritt 810 durchsucht das CMTS 104 seine Nachschlagetabelle nach der Indexzahl, die in dem Paket-Header-Element enthalten ist. Wenn die Indexzahl gefunden wird, dann sind die Expandierungsregeln, die mit der Unterdrückungstechnik assoziiert sind, dem CMTS 104 vorher bereitgestellt worden. In einem Ausführungsbeispiel wären die Expandierungsregeln vorher während des Initialisierungsprozesses, der im Schritt 702 beschrieben worden ist, bereitgestellt worden. Wenn die Indexzahl nicht gefunden wird, dann geht die Steuerung weiter zum Schritt 815.
  • Beim Schritt 815 tauschen das CMTS 104 und das Kabelmodem 108 Daten, die die Regeln für das Expandieren des Datenpakets beschreiben, in Echtzeit (d.h., wenn das Datenpaket ankommt) aus.
  • Beim Schritt 820 verarbeitet das CMTS 104 jedes der Datenpakete. In dem Fall, bei dem das Datenpaket nicht unterdrückt ist (d.h., ein Paket-Header-Element war nicht vorhanden), wird das Datenpaket gemäß Standard-DOCSIS-Protokollen verarbeitet. In dem Fall, bei dem das Datenpaket unterdrückt ist (d.h., ein Paket-Header-Element war vorhanden), ruft das CMTS 104 die Regeln für das Expandieren des Datenpakets auf der Grundlage der Unterdrückungstechnik ab, die von der Indexzahl angezeigt wird, die in dem Paket-Header-Element gefunden worden ist. Beim Expandieren des Datenpakets erzeugt das CMTS 104 ein dekomprimiertes Datenpaket. In einem Ausführungsbeispiel würde das CMTS 104 an dem Ende des Schrittes 820 ein Datenpaket wie etwa das nicht komprimierte Datenpaket 605 von 6A erzeugen. Da die gemischte Protokoll-SID ein oder mehrere Datenpakete enthält, werden die Schritte 805 bis 820 wiederholt, bis alle Datenpakete in der gemischten Protokoll-SID verarbeitet worden sind. Die Verarbeitung endet beim Schritt 825.
  • 3. RTP-Header-Unterdrückung
  • Wie vorher angemerkt worden ist, stellt die Erfindung eine Real Time Transport Protocol (RTP)-Header-Unterdrückung bereit. Die RTP-Header-Unterdrückungstechnik der vorliegenden Erfindung stellt große Effizienzverstärkungen in der Netzwerkbandbreitenausnutzung bereit, indem sie die Übertragung von redundanten Mustern eliminiert und indem sie sich ändernde Felder in einem Datenstrom unterdrückt. Die Erfindung erzielt dies, indem sie regelmäßige Muster im Netzwerkverkehr erkennt. In Ausführungsbeispielen können die regelmäßigen Muster eliminiert werden, indem bewirkt wird, dass sich ein Sender von Netzwerkverkehr, wie etwa das CM 108, und ein Empfänger von Netzwerkverkehr, wie etwa das CMTS 104, auf Regeln für eine korrekte Header-Rekonstruktion einigen, um den Header an dem empfangenden Ende zu reproduzieren. Durch das Reduzieren des Betrags an Netzwerkbandbreite, der benötigt wird, um RTP-Informationen quer durch das Netz zu übertragen, ermöglicht die vorliegende Erfindung eine gesteigerte Performanz für die gleiche Anzahl von Benutzern in dem Netzwerk sowie auch die Fähigkeit, dem Netzwerk effizient mehr Benutzer hinzufügen zu können.
  • Vor dem Beschreiben der RTP-Header-Unterdrückungstechnik der Erfindung wird ein herkömmlicher 802.3/IP/UDP/RTP-Protokoll-Header 900 für eine RTP-Übertragung in 9A beschrieben werden. Der beispielhafte Protokoll-Header 900 umfasst einen 802.3-Header 902 mit 14 Bytes, einen IP/(Internet Protocol)-Header 904 mit 20 Bytes, einen UDP/(User Datagram Protocol)-Header 906 mit 8 Bytes und einen RTP-Header 908 mit 12 Bytes. In diesem Beispiel erzeugt der 802.3/IP/UDP/RTP-Header 900 einen 54-Byte-Header. Der Datenabschnitt eines RTP-Pakets kann im Vergleich zu dem Overhead, der benötigt wird, um die Daten unter Verwendung des 802.3/IP/UDP/RTP-Header 900 zu senden, klein sein. Zum Beispiel kann der Datenabschnitt eines RTP-Pakets 20 Bytes klein sein, was weniger als die Hälfte der Größe des Header 900 ist. Auch ändern sich die meisten Felder innerhalb eines Protokoll-Header 900 nicht von Paket zu Paket. Die Übertragung von solchen redundanten Mustern (sich nicht ändernde Header-Informationen von Paket zu Paket) können große Beträge an Netzwerkbandbreite vergeuden, vor allem dann, wenn der Datenabschnitt des RTP-Pakets kleiner als der Header 900 ist. Es wäre daher sehr uneffizient, den Header 900 zu übertragen, ohne ihn zu komprimieren.
  • DOCSIS 1.1 ermöglicht die Unterdrückung von redundanten Informationen in Paketen mit einem Merkmal, das "Nutzlast-Header-Unterdrückung" (PHS; payload header suppression) genannt wird. PHS ermöglicht die Unterdrückung von sich nicht ändernden Bytes in einer individuellen SID (d.h., einem Datenstrom). Leider kann PHS, wie vorher angemerkt worden ist, nicht sich dynamisch ändernde Felder unterdrücken.
  • Die RTP-Header-Unterdrückungstechnik der vorliegenden Erfindung steigert die Effizienz der Datenübertragung, indem sie Verhaltensmuster in den sich ändernden Feldern des 802.3/IP/UDP/RTP-Header 900 erkennt. 9B ist ein Diagramm eines RTP-Protokoll-Pakets 910. Das RTP-Protokoll-Paket 910 umfasst unter anderem ein Ziel-MAC-Adressenfeld 912, ein Quell-MAC-Adressenfeld 914, ein Typ-/Längen-Feld 916, ein Protokollversionsfeld 918, ein Header-Längen-Feld 920, ein Diensttypfeld 922, ein Gesamtlängen-Feld 924, ein Paket-ID-Feld 926, ein Fragment-Offset-Feld 928, ein Lebenszeitfeld 930, ein Protokollfeld 932, ein Header-Prüfsummen-Feld 934, ein Quell-IP-Adressenfeld 936, ein Ziel-IP-Adressenfeld 938, ein Quellportfeld 940, ein Zielportfeld 942, ein Längenfeld 944, ein Prüfsummenfeld 946, ein Flag-Feld 948, ein Sequenznummernfeld 950, ein Zeitstempelfeld 952, ein Synchronisierungsquellenidentifizierungsfeld 954, eine PDU 956, und ein CRC-32 958. RTP-Protokoll-Pakete sind in dem/den Fachgebiet(en) wohl bekannt, so dass nicht jedes einzelne Feld ausführlich erörtert werden wird.
  • Der größte Teil des Header 900 kann unterdrückt werden. Die Felder des Datenpakets 910, die sich von Paket zu Paket ändern, 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 gesetzt, weil es nicht verwendet wird. Die restlichen Felder bleiben für die Lebensdauer einer Sprachverbindung konstant.
  • Das RTP-Sequenznummernfeld 950 startet bei irgendeinem willkürlichen Wert und inkrementiert um einen Wert von Eins für jedes nachfolgende Paket. Das RTP-Zeitstempelfeld 952 inkrementiert um einen Wert auf der Grundlage des Quantisierungsintervalls des Codec. Das Delta zweiter Ordnung dieser Zahl wird für jeden gegebenen Codec bei einem vorgegebenen Quantisierungsintervall immer Null sein.
  • Die Erfindung ermöglicht eine Übertragung von Paketen auf der Upstream-DOCSIS-HF-Verbindung in der richtigen Reihenfolge. Die Erfindung unterdrückt den 802.3/IP/UDP/RTP-Header 900 am CM 108 und gewährleistet, dass der Header 900 von dem CMTS 104 wieder erschaffen wird. Die Rekonstruktion des Header 900 muß eine exakte Rekonstruktion sein. Dies wird dadurch erzielt, dass der Unterschied zwischen einem RTP-Sequenznummernfeld 950 eines RTP-Eingangspakets und dem RTP-Sequenznummernfeld 950 des vorhergehenden RTP-Pakets berechnet wird. Wenn der Unterschied zwischen aufeinanderfolgenden RTP-Paket Sequenznummernfeldern 950 1 ist, wird der Unterschied zwischen einem Zeitstempelfeld 952 eines neuen RTP-Pakets und dem Zeitstempelfeld 952 eines vorhergehenden RTP-Pakets der Unterschied erster Ordnung sein, der bei jedem nachfolgenden Paket erscheinen wird, während der Codec und das Quantisierungsintervall konstant bleiben.
  • Durch Beobachtung wurde ermittelt, dass der Unterschied erster Ordnung in dem Zeitstempelfeld 952 des RTP-Pakets für eine Quantisierung von 10 Millisekunden für G711, G726, G738 und G729 80 Dezimale beträgt. Für eine Quantisierung von 5 Millisekunden beträgt der Unterschied erster Ordnung in dem Zeitstempelfeld 952 des RTP-Pakets 40 Dezimale.
  • Zuerst sendet das CM 108 einen oder mehrere nicht unterdrückte, vollständige Headers mit einem Steuerbit, das anzeigt, dass das CMTS 104 den Header 900" lernen" soll. Wenn der Quantisierungswert bestimmt ist, wird der Quantisierungswert dazu verwendet zu verifizieren, dass die Rekonstruktion des Header 900 korrekt sein wird. Zu diesem Zeitpunkt sendet das CM 108 entweder ein "Lern-Header"-Steuerbit mit einem vollständigen Header in dem Falle, dass die Rekonstruktion des Header 900 eventuell inkorrekt ist, oder ein 5-Bit-RTP-Sequenz-Delta, einen 8-Bit-Quantisierungswert und ein optionales 1-Byte-IP-Paket-ID-Delta anstelle des 54 Byte großen 802.3/IP/UDP/RTP-Header 900. In Ausführungsbeispielen kann während des Lernprozesses mehr als ein sequentieller Header mit dem gesetzten Lernbit gesendet werden. Dies gewährleistet, dass in dem Fall, dass ein Paket auf der HF-Verbindung fallengelassen wird, das CMTS 104 am Ende einen gültigen Vorlagen-Header aufweisen wird, aus dem Pakete neu erschaffen werden können, wenn das Lernbit nicht mehr länger gesetzt ist.
  • 10 ist ein Diagramm, das ein Steuerwert-Byte 1000 veranschaulicht, das während der Operation 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 5-Bit-V-Wert 1008. Das L-Bit 1002 ist ein Lernbit. Das L-Bit 1002 wird gesetzt, wenn das CMTS 104 den Header 900 lernen soll.
  • Moderne IP-Protokoll-Stacks inkrementieren oftmals das IP-Paket-ID-Feld 926 um entweder 0x0001 oder 0x0100 zwischen Datagrammen. Die vorliegende Erfindung verwendet einen Zwei-Bit-Flag-Wert, nämlich 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 werden soll, oder ob das IP-Paket-ID-Feld 926 durch ein 2-Byte-Delta-Feld ersetzt werden soll, das upstream von dem CM 108 übertragen wird. Wenn sowohl I(1) als auch I(0) nicht 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 ist und I(0) gesetzt ist, dann wird das IP-Paket-ID-Feld 926 um 0x0100 inkrementiert. Wenn I(1) gesetzt ist und I(0) nicht gesetzt ist, dann wird die Änderung in dem IP-Paket-ID-Feld 926 upstream in einem Zwei-Byte-Delta-Feld übertragen. Tabelle 1 repräsentiert die vier Möglichkeiten zur Bestimmung des Wertes des IP-Paket-ID-Feldes 926. Tabelle 1
    I(1) I(0) IP-Paket-ID
    0 0 um 0x0001 inkrementieren
    0 1 um 0x0100 inkrementieren
    1 0 die Änderung wird upstream in einem Zwei-Byte-Delta-Feld übertragen
    1 1 kein Inkrementwert
  • Der Steuerwert (V) 1008 ist ein Fünf-Bit-Wert, der den Delta-Wert des Sequenznummernfeldes 950 repräsentiert.
  • 11 ist ein Ablaufdiagramm 1100 hoher Ebene, das ein Verfahren für die RTP-Header-Unterdrückung veranschaulicht. Die Erfindung ist nicht auf die Beschreibung beschränkt, die hier im Hinblick auf das Ablaufdiagramm 1100 gegeben wird. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren offensichtlich sein, dass andere funktionelle Ablaufdiagramme innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 1102, bei dem der Prozess sofort zu Schritt 1104 weitergeht.
  • Im Schritt 1104 werden Informationen, die die RTP-Header-Unterdrückung betreffen, von dem CM 108 zu dem CMTS 104 kommuniziert, um eine Rekonstruktion von RTP-Paketen an dem CMTS 104 zu ermöglichen. Wie vorher erörtert worden ist, kann dies eine Indexzahl, die den speziellen Typ von Paket-Header-Unterdrückungstechnik anzeigt, die Regeln, die mit der Unterdrückung und der Rekonstruktion eines Pakets in Übereinstimmung mit dem bestimmten Typ von Paket-Header-Unterdrückungstechnik assoziiert sind, etc. umfassen. Der Prozess geht dann weiter zum Schritt 1106.
  • Im Schritt 1106 wird ein komplettes RTP-Paket, wie etwa das RTP-Paket 910, von dem CM 108 zu dem CMTS 104 gesendet, um dem CMTS 104 ein Lernen zu ermöglichen. Das CMTS 104 speichert den vollen Header des RTP-Pakets 910 für eine zukünftige Referenz als eine Vorlage. Der Prozess geht dann weiter zu dem Entscheidungsschritt 1108.
  • Im Entscheidungsschritt 1108 wird ermittelt, ob das CMTS 104 das RTP-Paket 910 gelernt hat. Wenn das CMTS 104 das RTP-Paket 910 nicht gelernt hat, dann kehrt der Prozess zurück zu Schritt 1106, an dem ein komplettes Paket von dem CM 108 zu dem CMTS 104 für ein Fortfahren des Lernens gesendet wird.
  • Nun wird nochmals auf den Entscheidungsschritt 1108 Bezug genommen. Wenn festgestellt wird, dass das CMTS 104 das RTP-Paket 910 gelernt hat, dann geht der Prozess weiter zum Schritt 1110. Im Schritt 1110 werden nachfolgende Pakete in dem RTP-Strom von dem CM 108 zu dem CMTS 104 gesendet. Die nachfolgenden Pakete bestehen aus Delta-Werten, die Änderungen in dem RTP-Header 900 repräsentieren. Auf diese Weise wird nicht mehr länger das gesamte RTP-Paket 910 gesendet. Statt dessen werden nur Delta-Werte, die die Änderungen in dem RTP-Header 900 repräsentieren, gesendet. Das PDU-Feld 956 wird ebenfalls gesendet. Wenn eine Fehlerkorrektur gewünscht wird, werden die nachfolgenden Pakete auch ein zusätzliches Byte umfassen, das das niedrigere Byte des RTP-Sequenznummernfelds 940 anzeigt. Wenn ein Paket aus irgendwelchen Gründen fallen gelassen wird, kann das CMTS 104 effektiv den Header-Wiederherstellungsalgorithmus erneut synchronisieren, indem die Änderungen an das Sequenznummernfeld 940 und das Zeitstempelfeld 952 des RTP-Header 900 für jedes fehlende Paket angelegt werden. Auf diese Weise wird das Senden des Byte niedrigerer Ordnung des Paketsequenznummernfeldes 940 eine Rekonstruktion von fallen gelassenen oder verlorenen Paketen ermöglichen. Der Prozess geht dann weiter zum Entscheidungsschritt 1112.
  • Im Entscheidungsschritt 1112 wird festgestellt, ob alle RTP-Pakete gesendet worden sind. Wenn nicht alle RTP-Pakete gesendet worden sind, kehrt der Prozess zu dem Entscheidungsschritt 1110 zurück, um zu ermöglichen, dass nachfolgende Pakete in dem RTP-Strom zu dem CMTS 104 gesendet werden können. Wenn zurückkehrend zu dem Entscheidungsschritt 1112 festgestellt wird, dass alle RTP-Pakete gesendet worden sind, dann geht der Prozess weiter zu Schritt 1114, bei dem der Prozess endet.
  • 12A ist ein Ablaufdiagramm, das ein Verfahren zum Unterdrücken eines RTP-Header unter Verwendung einer RTP-Header-Unterdrückungstechnik gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht. Die Erfindung ist nicht auf die hier im Hinblick auf das Ablaufdiagramm 1200 bereitgestellte Beschreibung beschränkt. Im Gegenteil, es wird den Fachleuten auf dem/den rele vanten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren offensichtlich sein, dass andere funktionelle Ablaufdiagramme innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Der Prozess beginnt mit dem Schritt 1202, bei dem ein RTP-Unterdrücker an dem sendenden Ende (d. h., beim CM 108) gestartet wird. Der Prozess geht dann sofort weiter zu Schritt 1204. Im Schritt 1204 wird das Delta des RTP-Zeitstempelfeldes 952 zwischen zwei aufeinanderfolgenden RTP-Paketen 900 bestimmt. Der sich ergebende Wert ist der Zeitstempel-Delta-Wert. Der sich ergebende Zeitstempel-Delta-Wert wird gleich temp(0) gesetzt. Es sei angemerkt, dass während der Initialisierung temp(0) auf Null gesetzt ist. Der Prozess geht dann weiter zum Schritt 1206.
  • Im Schritt 1206 wird der Delta-Wert für das Sequenznummernfeld 940 bestimmt. Der sich ergebende Delta-Wert wird gleich dem Steuerwert (V) gesetzt. Dies wird dadurch erzielt, dass das Byte niedriger Ordnung eines neuen Sequenznummernfeldes 950, das mit dem Hex-Wert 7f einem UND unterzogen wird, bestimmt wird, und dass das Byte niedriger Ordnung des alten Sequenznummernfeldes 950, das mit dem Hex-Wert 7f einem UND unterzogen wird, bestimmt wird. Der sich ergebende Wert des neuen Sequenznummernfeldes 950 wird dann von dem sich ergebenden alten Sequenznummernfeld 950 subtrahiert, um das Delta oder den Wert des Steuerwerts (V) zu erhalten. Der Prozess geht dann weiter zu dem Entscheidungsschritt 1208.
  • Im Entscheidungsschritt 1208 wird festgestellt, ob eine korrekte Rekonstruktion stattfinden wird. Dies wird dadurch erreicht, dass der Delta-Wert des Sequenznummernfeldes 950, der im Schritt 1206 berechnet worden ist, mit dem konstanten Wert für den Codec multipliziert wird und dieser dann zu dem vorhergehenden Zeitstempelwert addiert wird. Wenn dieser Wert nicht gleich dem neuen Zeitstempel ist, dann geht der Prozess weiter zum Schritt 1210.
  • Im Schritt 1210 wird das Lernbit 1002 des Steuerwertes 1000 gesetzt. Der Prozess geht dann weiter zum Schritt 1210.
  • Im Schritt 1212 wird temp(1) gleich dem Steuerwert 1000 gesetzt. Temp(1) enthält nun den Delta-Wert für das Sequenznummernfeld 950. Der Prozess geht dann weiter zum Schritt 1214.
  • Im Schritt 1214 wird ein neuer Pufferspeicher zugeordnet, und die beiden Bytes aus temp (der Delta-Wert für das Zeitstempel-Feld 952 und der Steuerwert 1000, der den Delta-Wert für das Sequenznummernfeld 950 enthält) werden in dem neuen Pufferspeicher gespeichert. Der Prozess geht dann weiter zum Schritt 1216.
  • Im Schritt 1216 werden der neue Pufferspeicher und der ursprüngliche Pufferspeicher, der einen vollständigen RTP-Header 910 enthält, zu dem CMTS 104 gesendet. Auf diese Weise wird der komplette RTP-Header 910 zusammen mit dem Delta-Wert für das Zeitstempelfeld 952 und dem Steuerwert 1000 zu dem CMTS 104 gesendet. Der Prozess geht dann weiter zum Schritt 1218, bei dem der Prozess endet.
  • Nun wird nochmals auf den Schritt 1208 Bezug genommen. Wenn festgestellt wird, dass der berechnete Wert gleich dem neuen Zeitstempelfeld 952 ist, dann hat das CM 108 den Quantisierungswert bestimmt. Der Prozess geht dann weiter zum Schritt 1220.
  • Im Schritt 1220 wird der Inkrementwert für das Inkrementieren des IP-Paket-ID-Feldes 926 bestimmt. Die Bits I(1) 1004 und I(0) 1006 des Steuerwerts 1000 werden entsprechend dem Wert des Inkrements für den verwendeten IP-Protokoll-Stack gesetzt. Der Steuerwert wird dann in temp(1) gespeichert. Der Prozess geht dann weiter zum Schritt 1222.
  • Im Schritt 1222 werden die beiden Bytes aus temp in den ursprünglichen Pufferspeicher kopiert. Temp (0) ist der Delta-Wert für das Zeitstempelfeld 952 oder der Quantisierungswert. Temp (1) ist der Steuerwert 1000, der den Delta-Wert für das Sequenznummernfeld 950 umfasst. Der Prozess geht dann weiter zum Schritt 1224.
  • Im Schritt 1224 wird die ursprüngliche Länge minus 52 Bytes beginnend beim Offset 52 übertragen. Auf diese Weise werden der Quantisierungswert oder das Delta des Zeitstempelfeldes 952, der Steuerwert 1000 und das PDU-Feld 956 zu dem CMTS 104 übertragen. Der Prozess geht dann weiter zum Schritt 1218, bei dem der Prozess endet.
  • Wie vorher angemerkt worden war, inkrementieren moderne IP-Protokoll-Stacks das IP-Paket-ID-Feld 926 im Allgemeinen um entweder 0x0001 oder 0x0100 zwischen Datagrammen. Eine spezielle Regel in der vorliegenden Erfindung hand habt das Setzen der Steuerbits 1004 und 1006, um den Inkrementwert zu bestimmen. 12B ist ein Ablaufdiagramm, das ein Verfahren zum Setzen der Inkrementbits I(1) 1004 und I(0) 1006 des Steuerwerts 1000 für das Inkrementieren des IP-Paket-ID-Feldes 926 in dem RTP-Paket 910 veranschaulicht. Der Prozess beginnt bei Schritt 1232, bei dem der Prozess sofort zum Entscheidungsschritt 1234 weitergeht.
  • Die vorliegende Erfindung enthält einen Testmodus, in dem das Testen verschiedener Aspekte des Systems durchgeführt werden kann. Wenn gewisse Tests durchgeführt werden, werden die Steuerbits I(1) 1004 und I(0) 1006 dementsprechend gesetzt, um ein Inkrement von Null bereitzustellen. Im Entscheidungsschritt 1234 wird festgestellt, ob sich das System in einem Testmodus befindet. Wenn sich das System in einem Testmodus befindet, dann geht der Prozess weiter zum Schritt 1236.
  • Im Schritt 1236 wird das Steuerwert-Bit I(1) 1004 auf 1 gesetzt und das Steuerwert-Bit I(0) 1006 wird auf 1 gesetzt. Dann geht der Prozess weiter zum Schritt 1248.
  • Nun wird nochmals auf den Entscheidungsschritt 1234 Bezug genommen. Wenn festgestellt wird, dass sich das System nicht in einem Testmodus befindet, dann geht der Prozess weiter zu dem Entscheidungsschritt 1238.
  • Im Entscheidungsschritt 1238 wird festgestellt, ob der Wert für das IP-Paket-ID-Feid 926 upstream gesendet werden soll. Wenn der Wert für das IP-Paket-ID-Feld 926 upstream gesendet werden soll, dann wird der Prozess zum Schritt 1240 weitergehen.
  • Im Schritt 1240 wird das Steuerwert-Bit I(1) 1004 auf 1 gesetzt und das Steuerwert-Bit I(0) 1006 wird auf 0 gesetzt. Dann geht der Prozess zum Schritt 1248 weiter.
  • Nun wird nochmals auf den Entscheidungsschritt 1238 Bezug genommen. Wenn der Wert für das IP-Paket-ID-Feld 926 nicht upstream gesendet werden soll, dann geht der Prozess weiter zum Entscheidungsschritt 1242.
  • Im Entscheidungsschritt 1242 wird festgestellt, ob der IP-Protokoll-Stack ein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 benötigt. Wenn der IP-Protokoll-Stack ein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 benötigt, dann geht der Prozess weiter zu dem Schritt 1244.
  • Im Schritt 1244 wird das Steuerwert-Bit I(1) 1004 auf 0 gesetzt und das Steuerwert-Bit I(0) 1006 wird auf 0 gesetzt. Dann geht der Prozess weiter zum Schritt 1248.
  • Nun wird nochmals auf den Entscheidungsschritt 1242 bezug genommen. Wenn der IP-Protokoll-Stack kein Inkrement von 0x0001 für das IP-Paket-ID-Feld 926 benötigt, dann geht der Prozess weiter zu 1246.
  • Im Schritt 1246 wird ein Inkrement von 0x0100 für das IP-Paket-ID-Feld 926 benötigt. Das Steuerwert-Bit I(1) 1004 wird auf 0 gesetzt und das Steuerwert-Bit I(0) 1006 wird auf 1 gesetzt. Dann geht der Prozess weiter zum Schritt 1248.
  • Beim Schritt 1248 endet der Prozess.
  • 13 ist ein Ablaufdiagramm 1300, das ein Verfahren zum Rekonstruieren eines unterdrückten RTP-Pakets gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht. Die Erfindung ist nicht auf die hier im Hinblick auf das Ablaufdiagramm 1300 bereitgestellte Beschreibung beschränkt. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren offensichtlich sein, dass andere funktionelle Ablaufdiagramme innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Der Prozess beginnt beim Schritt 1302, bei dem der Rekonstruktor gestartet wird. Der Prozess geht dann weiter zum Schritt 1304.
  • Im Schritt 1304 wird ein 54-Byte-Header gelesen. Dann geht der Prozess weiter zum Schritt 1306.
  • Im Schritt 1306 wird ein 1-Byte-Steuerwert 1000 aus dem Eingangsstrom ausgelesen. Dann geht der Prozess weiter zum Entscheidungsschritt 1308.
  • Im Entscheidungsschritt 1308 wird festgestellt, ob das Lernbit 1002 des Steuerwerts 1000 gesetzt ist. Wenn festgestellt wird, dass das Lernbit 1002 gesetzt ist, dann muß der Header 900 von dem CMTS 104 gelernt werden. Dann geht der Prozess weiter zum Schritt 1310.
  • Im Schritt 1310 wird ein zweiter 1-Byte-Wert aus dem Eingangsstrom ausgelesen. Dieser zweite 1-Byte-Wert wird verworfen. Dann geht der Prozess weiter zum Schritt 1312.
  • Im Schritt 1312 wird der aktuelle 54-Byte-Header, der im Schritt 1304 gelesen wurde, verworfen. Das CMTS 104 verwirft diese Daten, weil dieser 54-Byte-Header von dem Nutzlast-Header-Unterdrückungsmechanismus der Hardware an dem Ende des Rekonstruktorprozesses erzeugt wurde, was unten unter Bezugnahme auf den Schritt 1318 erörtert werden wird. Wenn der Nutzlast-Header-Unterdrückungsmechanismus der Hardware diesen 54-Byte-Header injiziert, dann wird der 54-Byte-Header vor dem Steuerwert 1000 platziert. Auf diese Weise wird dieser 54-Byte-Header dann, wenn das Lernbit 1002 gesetzt ist, als Datenmüll betrachtet und muß verworfen werden. Von Standpunkt des CM 108 aus war das, was gesendet wurde, ein Unterdrückungsindex. Der Empfang des Unterdrückungsindex durch das CMTS 104 hat das CMTS 104 veranlasst, 54 Bytes an inkorrekten Daten in den Datenstrom zu injizieren. Dann geht der Prozess weiter zum Schritt 1314.
  • Im Schritt 1314 wird der korrekte 54-Byte-Header, der von dem CM 108 übertragen wurde, aus dem Eingangsstrom ausgelesen. Dann geht der Prozess weiter zum Schritt 1316.
  • Im Schritt 1316 wird der 54-Byte-Header zu einem Vorlagen-Header kopiert, und der 54-Byte-Header, auf den die Daten aus der PDU 956 folgen, wird emittiert. Dann geht der Prozess weiter zum Schritt 1318, an dem der Prozess endet.
  • Wenn zurückkehrend zum Entscheidungsschritt 1308 festgestellt wird, dass das Lernbit 1002 des Steuerwerts 1000 nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 1320.
  • Im Schritt 1320 wird der zweite 1-Byte-Wert aus dem Eingangsstrom ausgelesen und in ein Byte niedriger Ordnung einer lokalen Variablen namens DELTA platziert. DELTA ist ein 32 Bit langes Wort. DELTA wird bei dem Start des RTP-Delta-Rekonstruktorprozesses 1300 auf Null vorinitialisiert. Dann geht der Prozess weiter zum Schritt 1322.
  • Der Schritt 1322 beginnt den Prozess zur Bestimmung, ob das IP-Paket-ID-Feld 926 inkrementiert werden soll, wie dies in der Tabelle 1 dargelegt ist. Im Schritt 1322 wird festgestellt, ob I(1) 1004 des Steuerwerts 1000 gesetzt ist. Wenn I(1) 1004 des Steuerwerts 1000 nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 1324.
  • Im Schritt 1324 wird festgestellt, ob I(0) 1006 des Steuerwerts 1000 gesetzt ist. Wenn I(0) nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 1326.
  • Im Schritt 1326 wird eine lokale Variable namens INCR auf 0x0001 für das Inkrementieren des IP-Paket-ID-Feldes 926 gesetzt. Es sei angemerkt, dass die lokale Variable INCR ein vorzeichenloser 16-Bit-Wert ist. INCR wird beim Schritt 1302 auf Null vorinitialisiert. Dann geht der Prozess weiter zum Schritt 1334.
  • Nun wird nochmals auf den Schritt 1324 Bezug genommen. Wenn I(0) gesetzt ist, dann geht der Prozess weiter zum Schritt 1328. Im Schritt 1328 wird die lokale Variable INCR auf 0x0100 zum Inkrementieren des IP-Paket-ID-Feldes 926 gesetzt. Dann geht der Prozess weiter zum Schritt 1334.
  • Nun wird nochmals auf den Schritt 1322 Bezug genommen. Wenn I(1) gesetzt ist, dann geht der Prozess weiter zum Schritt 1330. Im Schritt 1330 wird festgestellt, ob I(0) 1006 des Steuerwerts 1000 gesetzt ist. Wenn I(0) gesetzt ist, dann geht der Prozess weiter zum Schritt 1334.
  • Nun wird nochmals auf den Schritt 1330 Bezug genommen. Wenn I(0) nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 1332. Im Schritt 1332 wird die Änderung in dem IP-Paket-ID-Feld 926 upstream ausgehend von dem CM 108 übertragen. Ein vorzeichenloser Zwei-Byte-Wert 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. Dann geht der Prozess weiter zum Schritt 1334.
  • Die Schritte 1334 bis 1340 stellen alle Aktualisierungen für das IP-Paket-ID-Feld 926, das RTP-Sequenznummernfeld 950 und das RTP-Zeitstempelfeld 952 für die Rekonstruktion des RTP-Pakets 910 bereit. Im Schritt 1334 wird festgestellt, ob die Bits 4-0 des Byte am Offset 45 (Bits niedriger Ordnung des Sequenznummernfelds 950) des RTP-Pakets 910 gleich V 1008 in dem Steuerwert 1000 sind. Wenn festgestellt wird, dass die Bits 4-0 des Byte an dem Offset 45 (Bits niedriger Ordnung des Sequenznummernfelds 950) des RTP-Pakets 910 gleich V 1008 in dem Steuerwert 1000 sind, dann geht der Prozess weiter zum Schritt 1342.
  • Im Schritt 1342 wird eine neue IP-Header-Prüfsumme bestimmt und an dem Offset 24 (IP-Header-Prüfsumme 934) platziert. Das IP-Header-Prüfsummenfeld 934 ist das 16-Bit-Einerkomplement der Einerkomplementsumme aller 16-Bit-Worte im Header 900. Für die Zwecke der Berechnung der Prüfsumme ist der Wert des Prüfsummenfeldes null.
  • Nun wird nochmals auf den Schritt 1334 Bezug genommen. Wenn festgestellt wird, dass die Bits 4-0 des Byte an dem Offset 45 (Bits niedriger Ordnung des Sequenznummernfeldes 950) des RTP-Pakets 910 nicht gleich V 1008 im Steuerwert 1000 sind, dann geht der Prozess weiter zum Schritt 1336.
  • Im Schritt 1336 wird der Wert von Eins zu dem Wort an dem Offset 44 des RTP-Pakets 910 addiert, welcher das RTP-Sequenznummernfeld 950 ist. Dann geht der Prozess weiter zum Schritt 1338.
  • Im Schritt 1338 wird das Wort am Offset 18 des RTP-Pakets 910, welcher das IP-Paket-ID-Feld 926 ist, um die lokale Variable INCR inkrementiert. Dann geht der Prozess weiter zum Schritt 1340.
  • Im Schritt 1340 wird das Wort an dem Offset 46 des RTP-Pakets 910, welcher das RTP-Zeitstempelfeld 952 ist, um eine lokale Variable DELTA inkrementiert. Der Prozess kehrt dann zurück zum Schritt 1334, um festzustellen, ob der Steuerwert (V) 1008 mit den fünf Bits niedriger Ordnung in dem Sequenznummernfeld 950 des RTP-Pakets 910 übereinstimmt. Die Schritte 1334 bis 1340 werden wiederholt, bis diese Zahlen gleich sind. Wenn diese Zahlen gleich sind, dann wird der Prozess zum Schritt 1342 weitergehen, wie dies oben beschrieben ist.
  • 4. Dynamisches Deltacodierungsverfahren
  • Wie vorher angemerkt worden ist, sorgt die Erfindung für eine Optimierung der Übertragung von TCP/IP-(Internet Protocol)-Verkehr quer durch ein DOCSIS-Netzwerk. Die Unterdrückungstechnik der vorliegenden Erfindung ist eher feldorientiert als byteorientiert. Viele Felder in einem TCP-Protokoll-Header ändern sich nicht zwischen Paketen in dem gleichen TCP-Verbindungsstrom. Diese redundanten Informationen werden einmal übertragen und in den nachfolgenden Paketen unterdrückt. Andere Felder in dem TCP-Protokoll-Header ändern sich in einer vorhersagbaren Weise. Diese Felder werden nicht in ihrer Gesamtheit übertragen. Statt dessen wird ein kleinerer deltacodierter Wert übertragen, der jede Änderung im Wert eines Feldes von einem Paket zum nächsten repräsentiert. Die deltacodierten Werte für 32-Bit-Felder werden immer als eine 16-Bit-Zahl repräsentiert. Diese Technik reduziert die Bandbreite, die für das Senden der sich ändernden Felder benötigt wird, um etwa 50%, und stellt auf diese Weise eine hocheffiziente Verstärkung bei der TCP-Bestätigungs-(ACK)-Übertragung bereit.
  • DOCSIS-Kabelmodems können eine Übermittlung von Paketen in jedem IP-Strom in der richtigen Reihenfolge gewährleisten. Diese garantierte Vermittlungsreihenfolge ermöglicht die Verwendung von deltacodierten Feldern zur Aktualisierung jeglicher sich ändernder Felder in einem 802.3/IP/TCP-Protokoll-Header.
  • Vor dem Beschreiben des dynamischen Deltacodierungsverfahrens für die TCP-Header-Unterdrückung wird ein herkömmlicher 802.3/IP/TCP-Protokoll-Header 1400 für die TCP/IP-Übertragung in 14A beschrieben werden. Der Protokoll-Header 1400 umfasst einen 802.3-Header 1402 mit 14 Bytes, einen IP-Header 1404 mit 20 Bytes und einen TCP-Header 1406 mit 20 Bytes. In diesem Beispiel erzeugt der 802.3/IP/TCP-Header 1400 einen 54-Byte-Header für die TCP/IP-Übertragung.
  • 14B ist ein Diagramm eines TCP-Protokoll-Pakets 1410. Das TCP-Protokoll-Paket 1410 umfasst unter anderem ein Ziel-MAC-Adressenfeld 1412, ein Quell-MAC-Adressenfeld 1414, ein Typen-/Längenfeld 1416, ein Protokollversionsfeld 1418, ein Header-Längen-Feld 1420, ein Diensttypfeld 1422, ein Gesamtlängen-Feld 1424, ein Paket-ID-Feld 1426, ein Fragment-Offset-Feld 1428, ein Lebenszeitfeld 1430, ein Protokollfeld 1432, ein Header-Prüfsummen-Feld 1434, ein Quell-IP- Adressenfeld 1436, ein Ziel-IP-Adressenfeld 1438, ein Quellportfeld 1440, ein Zielportfeld 1442, ein Sequenznummernfeld 1446, ein Bestätigungsnummernfeld 1448, ein Daten-Offset-Feld 1450, ein Flags-Feld 1452, ein Fensterfeld 1454, ein Prüfsummenfeld 1456, ein Dringlichkeitszeiger-Feld 1458, ein PDU-Feld 1460 und ein CRC-32-Feld 1462. TCP-Protokoll-Pakete sind in dem/den relevanten Fachgebiet(en) wohl bekannt, so dass deshalb nicht jedes einzelne Feld ausführlich erörtert werden wird.
  • Die meisten Felder in dem TCP-Protokoll-Paket 1410 ändern sich nicht zwischen Paketen in dem gleichen TCP-Verbindungsstrom. Im TCP-Protokoll-Paket 1410 kann der gesamte Header 1402 und das meiste des Header 1404 unterdrückt werden, wenn der Empfänger einmal die redundanten oder sich nicht ändernden Felder gelernt hat. Viele dieser Felder in dem TCP-Header 1406 ändern sich zwischen Paketen in dem gleichen TCP-Verbindungsstrom. Mit der vorliegenden Erfindung werden diese Felder nicht in ihrer Gesamtheit übertragen. Statt dessen wird ein kleinerer deltacodierter Wert übertragen. Der deltacodierte Wert repräsentiert jede Änderung bezüglich des Wertes eines Feldes von einem Paket zu dem nächsten.
  • 15 ist ein Diagramm, dass die Felder veranschaulicht, die sich von Paket zu Paket in dem TCP-Protokoll-Paket 1410 ändern. Die Felder, die sich von Paket zu Paket ändern, sind hervorgehoben. Die sich ändernden Felder umfassen das Paket-ID-Feld 1426 von 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 Dringlichkeitszeiger-Feld 1458 von dem TCP-Header 1406.
  • Die Erfindung ermöglicht die Übermittlung von Paketen in der richtigen Reihenfolge auf der Upstream-DOCSIS-HF-Verbindung. Die Erfindung unterdrückt den 802.3/IP/TCP-Header 1400 am CM 108 und gewährleistet, dass der Header 1400 in seinem ursprünglichen Format von dem CMTS 104 rekonstruiert wird. Die 16A und 16B stellen jeweils eine Beschreibung hoher Ebene des deltacodierten Unterdrückungs- und Rekonstruktionsprozesses für die vorliegende Erfindung bereit.
  • 16A ist ein Ablaufdiagramm 1600 hoher Ebene, das ein Verfahren für eine deltacodierte Unterdrückungstechnik veranschaulicht. Die Erfindung ist nicht auf die hier im Hinblick auf das Ablaufdiagramm 1600 bereitgestellte Beschreibung begrenzt. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren offensichtlich sein, dass andere funktionelle Ablaufdiagramme innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Der Prozess beginnt mit dem Schritt 1601 und geht sofort zum Schritt 1602 weiter.
  • Im Schritt 1602 werden Informationen, die die deltacodierte TCP-Header-Unterdrückung betreffen, von dem CM 108 zu dem CMTS 104 kommuniziert, um die Rekonstruktion von TCP-Paketen an dem CMTS 104 zu ermöglichen. Wie vorher erörtert worden ist, kann dies eine Indexzahl, die den speziellen Typ von Paket-Header-Unterdrückungstechnik anzeigt, die Regeln, die mit dem Unterdrücken und Rekonstruieren eines Pakets in Übereinstimmung mit einem bestimmten Typ von Paket-Header-Unterdrückungstechnik assoziiert sind, etc. umfassen. Das CM 108 wählt den Unterdrückungsindex und auf diese Weise die Unterdrückungstechnik aus. Dies verhindert die Notwendigkeit einer Zwei-Wege-Befehlstransaktion während schneller Datenübertragungen. Der Prozess geht dann weiter zum Schritt 1603.
  • Im Schritt 1603 wird ein individueller TCP-Verbindungsstrom identifiziert. Ein Framing-Protokoll wird verwendet, um jeden TCP-Verbindungsstrom in einer einzelnen DOCSIS-SID zu trennen und zu identifizieren. Nach dem Identifizieren des TCP-Verbindungsstroms geht der Prozess weiter zum Schritt 1604.
  • Im Schritt 1604 wird ein erstes TCP-Protokoll-Paket 1410 in einem TCP-Verbindungsstrom in seiner Gesamtheit zu einem Empfänger übertragen. Das erste TCP-Protokoll-Paket 1410 umfasst einen Lernindikator. Der Indikator instruiert den Empfänger dahingehend, den kompletten Header zu lernen. Der komplette Protokoll-Header 1400 kann gelernt werden, ohne dass eine Bestätigung von einem Empfänger, wie etwa dem CMTS 104, notwendig ist. Dies erlaubt es, dass die Headers in Echtzeit gelernt werden können. Wenn der Header dann gelernt ist, können nachfolgende Pakete in einem komprimierten Format gesendet werden. Eine maximale Effizienz wird erzielt, indem es erlaubt wird, dass auf einen nicht unterdrückten (gelernten) Header sofort ein unterdrückter Header folgen kann. Dies beseitigt die Verzögerung, die in dem DOCSIS-Lösungsweg eingeführt wird und die es erfordert, dass auf eine Gelernt-Bestätigung von dem Empfänger gewartet wird. Der Prozess geht dann weiter zum Schritt 1606.
  • Im Schritt 1606 wird das nächste Paket in dem TCP-Verbindungsstrom abgerufen. Der Prozess geht dann weiter zum Schritt 1608.
  • Im Schritt 1608 werden die Felder, die sich seit dem vorher übertragenen Paket geändert haben, identifiziert, und ein deltacodierter Wert, der diese Änderung repräsentiert, wird bestimmt. Der Prozess geht dann weiter zum Schritt 1610.
  • Beim Schritt 1610 wird ein Bitmap-Flag (bit-mapped flag) erzeugt. Das Bitmap-Flag zeigt an, welche der möglichen deltacodierten IP/TCP-Feld-Werte zwischen einem Änderungsbyte und dem Datenbereich des komprimierten TCP-Protokoll-Pakets vorhanden sind. Das Änderungsbyte ist ein Ein-Byte-Bitmap-Flagfeld zum Anzeigen, welche Felder sich innerhalb des Protokoll-Header 1400 geändert haben. Das Änderungsbyte wird unten unter Bezugnahme auf 17 ausführlicher beschrieben werden. Der Prozess geht dann weiter zum Schritt 1612. Im Schritt 1612 wird das komprimierte TCP-Protokoll-Paket erzeugt, und das Bitmap-Flag wird vorne an das komprimierte TCP-Paket angehängt. Der Prozess geht dann weiter zum Schritt 1614.
  • Im Schritt 1614 wird das komprimierte TCP-Protokoll-Paket zu dem Empfänger übertragen. Der Prozess geht dann weiter zum Entscheidungsschritt 1616.
  • Im Entscheidungsschritt 1616 wird festgestellt, ob es noch mehr TCP-Protokoll-Pakete 1410 in dem TCP-Verbindungsstrom gibt, die übertragen werden sollen. Wenn es noch mehr Pakete zum Übertragen gibt, dann kehrt der Prozess zurück zu Schritt 1606, um das nächste Paket abzurufen.
  • Nun wird nochmals auf den Entscheidungsschritt 1616 Bezug genommen. Wenn keine weiteren Pakete mehr in dem TCP-Verbindungsstrom vorhanden sind, die übertragen werden sollen, dann wird der Prozess zurück zum Schritt 1603 gehen, bei dem ein anderer TCP-Verbindungsstrom identifiziert wird.
  • 16B ist ein Ablaufdiagramm 1620 hoher Ebene, das ein Verfahren für eine deltacodierte Header-Rekonstruktionstechnik veranschaulicht. Die Erfindung ist nicht auf die hier im Hinblick auf das Ablaufdiagramm 1620 bereitgestellte Beschreibung beschränkt. Im Gegenteil, es wird den Fachleuten auf dem/den relevan ten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren offensichtlich sein, dass andere funktionelle Ablaufdiagramme innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Der Prozess beginnt mit dem Schritt 1622, bei dem der Prozess sofort zum Schritt 1624 weitergeht.
  • Im Schritt 1624 wird ein TCP-Protokoll-Paket 1410 aus einem TCP-Verbindungsstrom abgerufen. Der Prozess geht dann weiter zum Entscheidungsschritt 1626.
  • Im Entscheidungsschritt 1626 wird festgestellt, ob das abgerufene TCP-Protokoll-Paket 1410 gelernt werden soll. Dies wird dadurch erzielt, dass ermittelt wird, ob das Indikator-Lernbit gesetzt ist. Wenn das Indikator-Lernbit gesetzt ist, geht der Prozess weiter zum Schritt 1628.
  • Im Schritt 1628 lernt der Empfänger den aktuellen TCP-Protokoll-Header des Pakets 1410 und speichert das Paket 1410 für eine zukünftige Referenz als eine Header-Vorlage. Der Prozess kehrt dann zum Schritt 1624 zurück, um ein anderes Paket abzurufen.
  • Nun wird nochmals auf den Entscheidungsschritt 1626 Bezug genommen. Wenn das Indikator-Lernbit nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 1630.
  • Im Schritt 1630 wird das Änderungsbyte gelesen und die entsprechenden deltacodierten Werte werden gelesen. Der Prozess geht dann zum Schritt 1632 weiter.
  • Im Schritt 1632 wird der Header rekonstruiert. Die TCP/IP-Header-Flags werden aktualisiert, und die deltacodierten Werte werden verwendet, um die geänderten Felder in einer gespeicherten Header-Vorlage zu aktualisieren. Der Prozess geht dann weiter zum Schritt 1634.
  • Im Schritt 1634 wird der komplett wiederhergestellte Header vor jegliche empfangene Daten aus dem TCP-Protokoll-Paket platziert, das im Schritt 1624 abgerufen worden ist. An diesem Punkt ist das Paket vollständig in seinem ursprünglichen Format wiederhergestellt und kann über ein IP-Netzwerk übertragen werden. Der Prozess geht dann zurück zum Schritt 1624, bei dem ein weiteres TCP-Protokoll-Paket abgerufen wird.
  • 17 ist ein Diagramm, das das Änderungsbyte 1700 veranschaulicht, das bei der Ausführung der deltacodierten Header-Unterdrückungstechnik verwendet wird. Das Änderungsbyte 1700 ist ein 1-Byte-Bitmap-Flag-Feld zum Anzeigen, welche Felder des Protokoll-Header 1400 sich geändert haben. Das Änderungsbyte 1700 zeigt auch an, ob der Header 1400 an dem empfangenden Ende gelernt werden soll oder nicht. Das Änderungsbyte 1700 zeigt ferner an, ob die IP-Paket-ID 1426 inkrementiert werden soll, und zeigt auch den Betrag an, um den die IP-Paket-ID 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 zeigt dann, wenn es gesetzt ist, an, dass der Rest des Änderungsbyte ignoriert werden kann, und dass ein ganzer 54 Byte großer 802.3/IP/TCP-Header 1400 in dem Burst enthalten ist und dazu verwendet werden sollte, den aktuellen Vorlagen-Header zu ersetzen.
  • Das I(1)-Bit 1704 und das I(0)-Bit 1706 werden verwendet, um die Änderung für das IP-Paket-ID-Feld 1426 in einer ähnlichen Weise zu bestimmen, wie dies oben in Tabelle 1 angegeben ist. Das I(1)-Bit 1704 zeigt dann, wenn es gesetzt ist, an, dass der nächste Wert in dem Datenstrom ein 2-Byte-Wert ist, der zu dem IP-Paket-ID-Feld 1426 des Vorlagen-Header kopiert werden soll. Das Ergebnis soll zu dem Vorlagen-Header zurückgeschrieben und emittiert werden. Wenn das I(1)-Bit 1704 leer ist, dann muß das I(0)-Bit 1706 überprüft werden, um festzustellen, wie die IP-Paket-ID 1426 inkrementiert werden soll. Das I(0)-Bit 1706 zeigt dann, wenn es gesetzt ist, an, dass 0x0100 zu dem Vorlagen-Header-IP-Paket-ID-Feld 1426 addiert werden soll, zu dem Vorlagen-Header zurückgeschrieben werden soll und emittiert werden soll. Wenn es leer ist, zeigt das I(0)-Bit 1706 an, dass das Vorlagen-Header-IP-Paket-ID-Feld 1426 um 0x0001 inkrementiert werden soll, in den Vorlagen-Header zurückgeschrieben werden soll und emittiert werden soll. Das I(1)-Bit 1704 und das I(0)-Bit 1706 werden auf der Grundlage der Operation der modernen IP-Protokoll-Stacks und der Art und Weise bestimmt, in der sie inkrementiert werden, wie dies oben beschrieben worden ist.
  • Das S-Bit 1708 zeigt dann, wenn es gesetzt ist, an, dass der nächste Wert in dem Datenstrom ein 2-Byte-Wert ist, der zu dem 4-Byte-TCP-Bestätigungsnummernfeld 1446 des Vorlagen-Header addiert werden soll. Das Ergebnis soll zu dem Vorlagen-Header zurückgeschrieben werden und emittiert werden. Wenn das S-Bit 1708 leer ist, soll das TCP-Sequenznummernfeld 1446 des Vorlagen-Header so verwendet werden, wie es ist.
  • Wenn das A-Bit 1710 gesetzt ist, dann ist der nächste Wert in dem Datenstrom ein 2-Byte-Wert, der zu dem 4-Byte-TCP-Bestätigungsnummernfeld 1448 des Vorlagen-Header addiert werden soll. Das Ergebnis soll zu dem Vorlagen-Header zurückgeschrieben werden und emittiert werden. Wenn das A-Bit 1710 leer ist, dann soll das TCP-Bestätigungsnummernfeld 1448 des Vorlagen-Header so verwendet werden, wie es ist.
  • Das P-Bit 1712 zeigt dann, wenn es gesetzt ist, an, dass das PUSH-Bit (nicht gezeigt) eines Nibble (4-Bit-Einheit) des TCP-Flags-Feldes 1452 gesetzt werden soll und emittiert werden soll. Wenn das P-Bit 1712 leer ist, soll das PUSH-Bit eines Nibble des TCP-Flags-Feldes 1452 gelöscht und emittiert werden.
  • Wenn das W-Bit 1714 gesetzt ist, dann ist der nächste Wert in dem Datenstrom ein 2-Byte-Wert, der zu dem TCP-Fensterfeld 1454 des Vorlagen-Header kopiert werden soll. Das Ergebnis soll zu dem Vorlagen-Header zurückgeschrieben und emittiert werden. Wenn das W-Bit 1714 leer ist, dann soll das TCP-Fensterfeld 1454 des Vorlagen-Header so verwendet werden, wie es ist.
  • Wenn das U-Bit 1716 gesetzt ist, dann ist der nächste Wert in dem Datenstrom ein 2-Byte-Wert, der zu dem TCP-Dringlichkeitszeiger-Feld 1458 des Vorlagen-Header kopiert werden soll. Das Ergebnis soll zu dem Vorlagen-Header zurückgeschrieben und emittiert werden. Wenn das U-Bit 1716 leer ist, soll das TCP-Dringlichkeitszeiger-Feld 1458 des Vorlagen-Header so verwendet werden, wie es ist. Auf der Grundlage der Felder, die sich seit den vorher übertragenen Werten tatsächlich ändern, wird eine von zwei Aktionen stattfinden. Das TCP-Protokoll-Paket 1410 kann ohne irgendeine Unterdrückung gesendet werden, oder das TCP-Protokoll-Paket 1410 kann an das Änderungsbyte 1700 angehängt werden und entweder ein ganzes TCP-Protokoll-Paket 1410 oder zwei oder mehr Felder an Stelle des 54-Byte-802.3/IP/TCP-Header 1400 enthalten. Die zwei oder mehr Felder, die den 802.3/IP/TCP-Header 1400 ersetzen, umfassen: (1) einen derzeitigen IP-Paket-ID-1426-Wert (der nur dann gesendet wird, wenn die IP-Paket-ID nicht um 0x0001 oder 0x0100 inkrementiert wurde); (2) einen deltacodierten Wert für die TCP-Sequenznummer 1446 (der nur dann gesendet wird, wenn die deltacodierte TCP-Sequenznummer ≠ 0 ist), (3) einen deltacodierten Wert für das TCP-Bestätigungsnummernfeld 1448 (der nur gesendet wird, wenn die deltacodierte TCP-Bestätigungsnummer ≠ 0 ist); (4) ein Byte an Daten für das TCP-Daten-Offset-Feld 1450; (5) einen derzeitigen Wert für das TCP-Fensterfeld 1454 (der nur gesendet wird, wenn ein deltacodierter Wert für das TCP-Fensterfeld 1454 ≠ 0 ist; (6) einen derzeitigen Wert für das TCP-Header-Prüfsummenfeld 1456; und (7) einen derzeitigen Wert für das TCP-Dringlichkeitszeiger-Feld 1458 (der nur gesendet wird, wenn das IP-Dringlichkeits-Flag gesetzt ist). Deshalb verwendet die Erfindung einen Framing-Mechanismus, der komprimierten, nicht komprimierten Verkehr und Verkehr, der nicht von der IP-Art ist, in einer einzigen DOCSIS SID kombiniert.
  • Traditionelle Internet-TCP/IP-Header-Unterdrückungsprotokolle verwenden ein Deltacodierungsverfahren variabler Länge, um sich ändernde Felder zu repräsentieren. Die vorliegende Technik ist für Charakteristiken von Hochgeschwindigkeits-TCP/IP-Netzwerken optimiert. Für solche Netzwerke werden die sich ändernden TCP-Felder (d.h., ACK, SEQ, WIN) typischerweise um mehr als 255 Einheiten inkrementiert. Das Codieren dieser Änderungen mit einem festen Zwei-Byte-Delta-Feld optimiert den typischen Fall für Hochgeschwindigkeitsnetzwerke und reduziert die Verarbeitung, die für jedes übertragene TCP-Protokoll-Paket 1410 benötigt wird.
  • 18 ist ein Diagramm, das einen endgültigen codierten Datenstrom 1800 veranschaulicht, der zu einem Empfänger (d.h., CMTS) gesendet wird, wenn das L-Bit 1702 nicht gesetzt ist. 18 zeigt eine erste Reihe 1802 für jedes Feld in einem endgültigen codierten Datenstrom 1800 und eine zweite Reihe 1804, die eine Anzahl von Bytes anzeigt, die jedem Feld in dem endgültigen codierten Datenstrom 1800 entsprechen.
  • Ein erstes Feld 1806 ist das Änderungsbyte 1700. Wie vorher angegeben, besteht das Änderungsbyte 1700 aus 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 aus entweder 0 oder 2 Bytes an Daten bestehen (1809), und zwar in Abhängigkeit davon, ob ein Wert zu dem Vorlagen-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll, oder ob der Wert des IP-Paket-ID-Feldes 1426 um entweder 0x0001 oder 0x0100 inkrementiert werden soll. Wenn ein Wert zu dem Vorlagen-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll, dann wird der endgültige codierte Datenstrom 1800 2 Bytes für das IP-Paket-ID-Feld 1426 enthalten. Wenn kein Wert zu dem Vorlagen-Header für das IP-Paket-ID-Feld 1426 kopiert werden soll, dann wird der endgültige codierte Datenstrom 1800 keine Bytes für die IP-Paket-ID 1426 enthalten. Statt dessen wird ein Inkrementwert für das IP-Paket-ID-Feld 1426 unter Verwendung der Bits I(1) 1704 und I(0) 1706 des Änderungsbyte 1700 bestimmt werden.
  • Ein drittes Feld 1810 ist ein deltacodierter Wert für die TCP-Sequenznummer 1446. Der deltacodierte Wert 1810 für das TCP-Sequenznummernfeld 1446 kann aus entweder 0 oder 2 Bytes an Daten (1811) bestehen, und zwar in Abhängigkeit davon, ob eine Änderung in dem TCP-Sequenznummernfeld 1446 seit dem vorher übertragenen Wert stattgefunden hat. Wenn eine Änderung in der TCP-Sequenznummer 1446 seit dem vorher übertragenen Wert stattgefunden hat, wird das S-Bit 1708 des Änderungsbyte 1700 gesetzt und der endgültige codierte Datenstrom 1800 wird 2 Bytes an Daten für die Aktualisierung des TCP-Sequenznummernfeldes 1446 in dem Vorlagen-Header enthalten. Wenn in dem TCP-Sequenznummernfeld 1446 seit dem vorher übertragenen Wert keine Änderung stattgefunden hat, dann wird das S-Bit 1708 des Änderungsbyte 1700 nicht gesetzt, und der endgültige codierte Datenstrom 1800 wird keine Bytes für das TCP-Sequenznummernfeld 1446 enthalten.
  • 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 aus entweder 0 oder 2 Bytes an Daten (1813) bestehen, und zwar in Abhängigkeit davon, ob eine Änderung in dem TCP-Bestätigungsnummernfeld 1448 seit dem vorher übertragenen Wert stattgefunden hat oder nicht. Wenn eine Änderung in dem TCP-Bestätigungsnummernfeld 1448 seit dem vorher übermittelten Wert stattgefunden hat, wird das A-Bit 1710 des Änderungsbyte 1700 gesetzt, und der endgültige codierte Datenstrom 1800 wird 2 Bytes an Daten für die Aktualisierung des TCP-Bestätigungsnummernfeldes 1448 in dem Vorlagen-Header enthalten. Wenn keine Änderung in dem Sequenznummernfeld 1446 seit dem vorher übertragenen Wert stattgefunden hat, dann wird das A-Bit 1710 des Änderungsbyte 1700 nicht gesetzt, und der endgültige codierte Datenstrom 1800 wird keine Bytes für das TCP-Bestätigungsnummernfeld 1448 enthalten.
  • Ein fünftes Feld ist für das TCP-Daten-Offset-Feld 1450. Ein Wert für das TCP-Daten-Offset-Feld 1450 besteht aus 1 Byte an Daten (1815), das in den endgültigen codierten Datenstrom 1800 eingefügt werden sollen.
  • Ein sechstes Feld 1816 ist für das TCP-Fensterfeld 1454. Ein Wert für das TCP-Fensterfeld 1454 kann aus 0 oder 2 Bytes an Daten (1817) bestehen, und zwar in Abhängigkeit davon, ob eine Änderung in dem TCP-Fensterfeld 1454 seit dem vorher übertragenen Wert stattgefunden hat. Wenn eine Änderung in dem TCP-Fensterfeld 1454 seit dem vorher übertragenen Wert stattgefunden hat, wird das W-Bit 1714 des Änderungsbyte 1700 gesetzt werden, und der endgültige codierte Datenstrom 1800 wird 2 Bytes an Daten für die Aktualisierung des TCP-Fensterfeldes 1454 in dem Vorlagen-Header aufweisen. Wenn keine Änderung in dem TCP-Fensterfeld 1454 seit dem vorher übertragenen Wert stattgefunden hat, wird das W-Bit 1714 des Änderungsbyte 1700 nicht gesetzt, und der endgültige codierte Datenstrom 1800 wird keine Bytes für das TCP-Fensterfeld 1454 enthalten.
  • Ein siebtes Feld 1818 ist für das TCP-Prüfsummenfeld 1456. Ein Wert für das TCP-Prüfsummenfeld 1456 besteht aus 2 Bytes an Daten (1819), die in den endgültigen codierten Datenstrom 1800 eingefügt werden sollen.
  • Ein achtes Feld 1820 ist für das TCP-Dringlichkeitszeiger-Feld 1458. Ein Wert für das TCP-Dringlichkeitszeiger-Feld 1458 kann aus 0 oder 2 Bytes an Daten (1821) bestehen, und zwar in Abhängigkeit davon, ob ein IP-Dringlichkeits-Flag in dem TCP-Flags-Feld 1452 gesetzt ist. Wenn das IP-Dringlichkeits-Flag in dem TCP-Flags-Feld 1452 gesetzt ist, wird das U-Bit 1716 des Änderungsbyte 1700 gesetzt werden, und der endgültige codierte Datenstrom 1800 wird 2 Bytes an Daten enthalten, die in den Vorlagen-Header kopiert werden sollen. Wenn das IP-Dringlichkeits-Flag in dem TCP-Flags-Feld 1454 nicht gesetzt ist, wird das U-Bit 1716 des Änderungsbyte 1700 nicht gesetzt, und der endgültige codierte Datenstrom 1800 wird keine Bytes für das TCP-Dringlichkeitszeiger-Feld 1458 enthalten.
  • Ein neuntes Feld 1822 ist für die TCP PDU 1460. Die TCP PDU kann aus 0-n Bytes bestehen (1823).
  • 19 ist ein Diagramm, das eine Sendereihenfolge 1900 für den endgültigen codierten Datenstrom 1800 veranschaulicht, wenn das L-Bit 1702 nicht gesetzt ist. Die Sendereihenfolge 1900 beginnt mit dem Änderungsbyte 1700. Die Felder 1808, 1810, 1812, 1814, 1816, 1818, 1820 und 1822 folgen.
  • 20 ist ein Diagramm, das eine Sendereihenfolge 2000 veranschaulicht, wenn das L-Bit 1702 gesetzt ist. Dies zeigt an, dass die Header-Information, die übertragen wird, von dem Empfänger gelernt werden soll. Die Sendereihenfolge 2000 besteht aus dem Änderungsbyte 1700, einem Pad 2002, einem 54-Byte-TCP-Protokoll-Header 1410 und der PDU 1460.
  • 21 ist ein Ablaufdiagramm 2100, das ein Verfahren für die TCP-Header-Unterdrückung veranschaulicht. Die Erfindung ist nicht auf die hier im Hinblick auf das Ablaufdiagramm 2100 bereitgestellte Beschreibung beschränkt. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren offensichtlich sein, dass andere funktionelle Ablaufdiagramme innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Der Prozess beginnt mit Schritt 2102, bei dem ein TCP-Unterdrücker gestartet wird. Der Prozess geht dann weiter zum Schritt 2104.
  • Im 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 Änderungsbyte 1700 ermittelt. Dann wird das Änderungsbyte in temp(0) kopiert. Der Prozess geht dann weiter zum Entscheidungsschritt 2106.
  • Im Entscheidungsschritt 2106 wird festgestellt, ob das L-Bit 1702 gesetzt ist. Wenn das L-Bit 1702 gesetzt ist, so zeigt dies an, dass 802.3/IP/TCP in seiner Gesamtheit gesendet werden sollte, damit er von einem Empfänger wie etwa dem CMTS 104 gelernt werden kann. Dann geht der Prozess weiter zum Schritt 2108.
  • Im Schritt 2108 wird ein neuer Pufferspeicher zugeordnet. Dann geht der Prozess weiter zum Schritt 2110.
  • Im Schritt 2110 werden das Änderungsbyte 1700 und ein einzelnes Pad-Byte (Stopf-Byte) in dem Pufferspeicher gespeichert, der in dem Schritt 2108 zugeordnet worden ist. Die System-Hardware sieht es nicht gerne, wenn es Pufferspeicher mit einer Zuordnung von einem einzigen Byte gibt. Deshalb besteht eine Hardware-Einschränkung darin, Pufferspeicher mit mehr als 1 Byte bereitzustellen. Auf diese Weise wird auch ein Pad-Byte in den Pufferspeicher eingefügt. Der Prozess geht dann weiter zum Schritt 2112.
  • Im Schritt 2112 wird ein ursprünglicher Pufferspeicher, der das TCP-Protokoll-Paket 1410 hält, an den neuen Pufferspeicher in einem BD-Ring angehängt. Dann geht der Prozess weiter zum Schritt 2114.
  • Im Schritt 2114 werden die ursprüngliche Pufferspeicherlänge und die neue Pufferspeicherlänge übertragen. Auf diese Weise werden das Änderungsbyte und ein Pad mit dem 54-Byte-Header und der PDU 1460 zum Lernen des kompletten 802.3/IP/TCP-Header übertragen. Wenn das L-Bit 1702 gesetzt ist, gilt die Sendereihenfolge 2000. Der Prozess geht dann weiter zum Schritt 2116, bei dem der Prozess endet.
  • Nun wird nochmals auf den Entscheidungsschritt 2106 Bezug genommen. Wenn das L-Bit 1702 nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 2118. Im Schritt 2118 wird die Länge von temp berechnet und ein Zeiger wird auf den Pufferspeicher [54] minus die Länge von temp gesetzt. Die Länge von temp umfasst die Länge aller Daten, die in dem endgültigen codierten Datenstrom 1800 gesendet werden. Dann geht der Prozess weiter zum Schritt 2120.
  • Im Schritt 2120 wird temp zu dem Zeiger kopiert. Dann geht der Prozess weiter zum Schritt 2122.
  • Im Schritt 2122 wird der Zeiger auf den BD-Ring gesetzt. Dann geht der Prozess weiter zum Schritt 2124.
  • Im Schritt 2124 wird die ursprüngliche Länge – [54] + die Länge von temp übertragen. Auf diese Weise wird der endgültige codierte Datenstrom 1800 übertragen. Wenn das L-Bit 1702 nicht gesetzt ist, gilt die Sendereihenfolge 1900. Dann geht der Prozess weiter zum Schritt 2116, bei dem der Prozess endet.
  • 22 ist ein Ablaufdiagramm 2200, das ein Verfahren für die TCP-Header-Rekonstruktion veranschaulicht. Die Erfindung ist nicht auf die hier im Hinblick auf das Ablaufdiagramm 2200 bereitgestellte Beschreibung beschränkt. Im Gegenteil, es wird den Fachleuten auf dem/den relevanten Fachgebiet(en) nach dem Lesen der hier bereitgestellten Lehren offensichtlich sein, dass andere funktionelle Ablaufdiagramme innerhalb des Schutzumfangs der vorliegenden Erfindung liegen. Ein 54-Byte-Vorlagen-Header wird von der DOCSIS-Nutzlast-Header-Rekonstruktionsmaschine (nicht gezeigt) vor dem Start des Ablaufdiagramms 2200 erzeugt. Der Prozess beginnt mit Schritt 2202, bei dem ein TCP-Header-Rekonstruktor gestartet wird. Der Prozess geht dann weiter zum Schritt 2204.
  • Beim Schritt 2204 wird ein 54-Byte-Header aus dem Eingangsstrom ausgelesen. Dann geht der Prozess weiter zum Schritt 2206.
  • Im Schritt 2206 wird das Änderungsbyte 1700 aus dem Eingangsstrom ausgelesen. Dann geht der Prozess weiter zum Entscheidungsschritt 2208.
  • Im Entscheidungsschritt 2208 wird festgestellt, ob das L-Bit 1702 aus dem Änderungsbyte 1700 gesetzt ist. Wenn das L-Bit 1702 gesetzt ist, dann geht der Prozess weiter zum Schritt 2210.
  • Im Schritt 2210 wird der 54-Byte-Header, der im Schritt 2204 erfasst wurde, verworfen. Diese Daten werden verworfen, weil diese Daten nicht aus dem Eingangsstrom erzeugt wurden, sondern von dem Nutzlast-Header-Unterdrückungsmechanismus der Hardware an dem Ende des Rekonstruktorprozesses erzeugt wurde, was unten unter Bezugnahme auf den Schritt 2216 beschrieben werden wird. Wenn der Nutzlast-Header-Unterdrückungsmechanismus der Hardware diesen 54-Byte-Header injiziert, wird der 54-Byte-Header vor dem Änderungsbyte 1700 platziert. Auf diese Weise wird dieser 54-Byte-Header dann, wenn das L-Bit 1702 gesetzt ist, als Datenmüll betrachtet und muß verworfen werden. Vom Standpunkt des CM 108 aus, war das, was gesendet wurde, ein Unterdrückungsindex. Der Empfang des Unterdrückungsindex durch das CMTS 1104 hat das CMTS 104 veranlasst, 54 Bytes an inkorrekten Daten in den Datenstrom zu injizieren. Dann geht der Prozess weiter zum Schritt 2212.
  • Im Schritt 2212 wird ein 1-Byte-Pad aus dem Eingangsstrom ausgelesen und verworfen. Dann geht der Prozess weiter zum Schritt 2214.
  • Im Schritt 2214 wird der korrekte 54-Byte-Header, der von dem CM 108 übertragen worden ist, aus dem Eingangsstrom ausgelesen. Dann geht der Prozess weiter zum Schritt 2216.
  • Im Schritt 2216 wird der korrekte 54-Byte-Header zu einem Vorlagen-Header kopiert, und der 54-Byte-Header und die Daten aus der PD 1460, die folgen, werden emittiert. Dann geht der Prozess weiter zum Schritt 2218, bei dem der Prozess endet.
  • Nun wird nochmals auf den Entscheidungsschritt 2208 Bezug genommen. Wenn das L-Bit 1702 des Änderungsbyte 1700 nicht gesetzt ist, dann geht der Prozess weiter zum Entscheidungsschritt 2220.
  • Der Entscheidungsschritt 2220 beginnt den Prozess zum Ermitteln, ob das IP-Paket-ID-Feld 1426 um 0x0001 oder 0x0100 inkrementiert werden soll, oder ob ein 2-Byte-Wert aus dem Eingangsstrom in den Vorlagen-Header des IP-Paket-ID-Feldes 1426 kopiert werden soll. In dem Entscheidungsschritt 2220 wird festgestellt, ob das I(1)-Bit 1704 des Änderungsbyte 1700 gesetzt ist. Wenn I(1) gesetzt ist, geht der Prozess weiter zum Schritt 2222.
  • Im Schritt 2222 wird ein 2-Byte-Wert aus dem Eingangsstrom ausgelesen und in das IP-Paket-ID-Feld 1426 kopiert (Offset 18). Dann geht der Prozess weiter zum Schritt 2230.
  • Nun wird nochmals auf den Entscheidungsschritt 2220 Bezug genommen. Wenn das I(1)-Bit 1704 des Änderungsbyte 1700 nicht gesetzt ist, geht der Prozess weiter zum Entscheidungsschritt 2224. Im Entscheidungsschritt 2224 wird festgestellt, ob das I(0)-Bit 1706 des Änderungsbyte 1700 gesetzt ist. Wenn das I(0)-Bit 1706 nicht gesetzt ist, geht der Prozess weiter zum Schritt 2226.
  • Im Schritt 2226 wird 0x0001 zu dem IP-Paket-ID 1426 an dem Offset 18 addiert. Dann geht der Prozess weiter zum Schritt 2230.
  • Nun wird nochmals auf den Entscheidungsschritt 2224 Bezug genommen. Wenn das I(0)-Bit 1706 des Änderungsbyte 1700 gesetzt ist, geht der Prozess weiter zum Schritt 2228. Im Schritt 2228 wird 0x0100 zu dem IP-Paket-ID 1426 an dem Offset 18 addiert. Dann geht der Prozess weiter zum Entscheidungsschritt 2230.
  • Im Entscheidungsschritt 2230 wird festgestellt, ob das S-Bit 1708 des Änderungsbyte 1700 gesetzt ist. Wenn das S-Bit 1708 gesetzt ist, was anzeigt, dass eine Änderung in dem TCP-Sequenznummernfeld 1446 seit dem vorherigen Wert stattgefunden hat, dann geht der Prozess weiter zum Schritt 2232.
  • Im Schritt 2232 werden die nächsten 2 Bytes an Daten aus dem Eingangsstrom zu dem TCP-Sequenznummernfeld 1446 an dem Offset 38 hinzugefügt. Dann geht der Prozess weiter zum Entscheidungsschritt 2234.
  • Nun wird nochmals auf den Entscheidungsschritt 2230 Bezug genommen. Wenn das S-Bit 1708 des Änderungsbyte 1700 nicht gesetzt ist, geht der Prozess weiter zum Entscheidungsschritt 2234.
  • Im Entscheidungsschritt 2234 wird festgestellt, ob das A-Bit 1710 des Änderungsbyte 1700 gesetzt ist. Wenn das A-Bit 1710 gesetzt ist, was anzeigt, dass eine Änderung in dem TCP-Bestätigungsnummernfeld 1448 stattgefunden hat, dann geht der Prozess weiter zum Schritt 2236.
  • Im Schritt 2236 werden die nächsten 2 Bytes an Daten aus dem Eingangsstrom zu dem TCP-Bestätigungsnummernfeld 1448 an dem Offset 42 addiert. Dann geht der Prozess weiter zum Schritt 2238.
  • Nun wird nochmals auf den Entscheidungsschritt 2234 Bezug genommen. Wenn das A-Bit 1710 des Änderungsbyte 1700 nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 2238.
  • Im Schritt 2238 wird das nächste Byte an Daten aus dem Eingangsstrom in das TCP-Daten-Offset-Feld 1450 bei dem Offset 46 kopiert. Der Prozess geht dann weiter zum Entscheidungsschritt 2240.
  • Im Entscheidungsschritt 2240 wird festgestellt, ob das P-Bit 1712 des Änderungsbyte 1700 gesetzt ist. Wenn das P-Bit 1712 gesetzt ist, dann geht der Prozess weiter zum Schritt 2242.
  • Im Schritt 2242 wird 0x08 einem ODER mit den Daten in dem TCP-Flag-Feld 1452 an dem Offset 47 unterzogen. Dann geht der Prozess weiter zum Entscheidungsschritt 2246.
  • Nun wird nochmals auf den Entscheidungsschritt 2240 Bezug genommen. Wenn das P-Bit 1712 des Änderungsbyte 1700 nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 2244.
  • Im Schritt 2244 wird 0xF7 mit den Daten in dem TCP-Flag-Feld 1452 bei dem Offset 47 einem UND unterzogen. Der Prozess geht dann weiter zum Entscheidungsschritt 2246.
  • Im Entscheidungsschritt 2246 wird festgestellt, ob das W-Bit 1714 des Änderungsbyte 1700 gesetzt ist. Wenn das W-Bit 1714 gesetzt ist, was anzeigt, dass eine Änderung in dem TCP-Fensterfeld 1545 stattgefunden hat, dann geht der Prozess weiter zum Schritt 2248.
  • Im Schritt 2248 werden die nächsten zwei Bytes an Daten aus dem Eingangsstrom in das TCP-Fensterfeld 1454 bei dem Offset 48 kopiert. Dann geht der Prozess weiter zum Schritt 2250.
  • Nun wird nochmals auf den Entscheidungsschritt 2246 Bezug genommen. Wenn festgestellt wird, dass das W-Bit 1714 des Änderungsbyte 1700 nicht gesetzt ist, dann geht der Prozess weiter zum Schritt 2250.
  • Im Schritt 2250 werden die nächsten 2 Bytes an Daten aus dem Eingangsstrom in das TCP-Prüfsummenfeld 1456 bei dem Offset 50 kopiert. Dann geht der Prozess weiter zum Entscheidungsschritt 2252.
  • Im Entscheidungsschritt 2252 wird festgestellt, ob das U-Bit 1716 des Änderungsbyte gesetzt ist. Wenn das U-Bit 1716 gesetzt ist, dann geht der Prozess weiter zum Schritt 2254.
  • Im Schritt 2254 werden die nächsten 2 Bytes an Daten aus dem Eingangsstrom in das TCP-Dringlichkeitszeiger-Feld 1458 bei dem Offset 52 kopiert. Dann geht der Prozess weiter zum Schritt 2256.
  • Im Schritt 2256 wird das U-Bit in dem TCP-Flags-Feld 1452 gesetzt, indem 0x20 durch ein ODER mit dem TCP-Flags-Feld 1452 an dem Offset 4 verknüpft wird. Dann geht der Prozess weiter zum Schritt 2260.
  • Nun wird nochmals auf den Entscheidungsschritt 2252 Bezug genommen. Wenn das U-Bit 1716 des Änderungsbyte 1700 nicht gesetzt ist, dann geht der Prozess weiter zu Schritt 2258. Im Schritt 2258 wird das U-Bit in dem TCP-Flags-Feld 1452 gelöscht, indem 0xDF durch ein UND mit dem TCP-Flags-Feld 1452 bei dem Offset 47 verknüpft wird. Der Prozess geht dann weiter zum Schritt 2260.
  • Im Schritt 2260 wird das IP-Gesamtlängen-Feld 1424 gleich der restlichen PDU-1460-Länge plus 40 Bytes gesetzt. Ein neues IP-Header-Prüfsummenfeld 1434 wird bestimmt und in den Vorlagen-Header bei dem Offset 24 platziert. Die IP-Header-Prüfsumme ist das 16-Bit-Einerkomplement der Einerkomplementsumme der Werte bei den Offsets 14, 16, 18, 22, 26, 28, 30 und 32. Der Prozess geht dann weiter zum Schritt 2216, bei dem 54 Bytes zu dem Vorlagen-Header kopiert und emittiert werden. Dann geht der Prozess zu dem Schritt 2218 weiter, bei dem der Prozess endet.
  • D. Umgebung
  • Wie hier an anderer Stelle erörtert worden ist, können die oben beschriebenen Techniken bzw. Verfahren als Software-Routinen teilweise von dem MAC-Abschnitt eines Kabelmodems und dem Kopfstellen-MAC-Abschnitt eines CMTS ausgeführt werden. Zum Beispiel und unter Bezugnahme auf die beispielhafte Implementierung des Kabelmodems 108, die unter Bezugnahme auf 3 beschrieben worden ist, führt die MAC 314 notwendige Verfahrensschritte durch, indem sie Software-Funktionen mit der Hilfe der CPU 320 ausführt. Diese Software-Funktionen können entweder in dem RAM 322 oder dem ROM 324 gespeichert sein. Des Weiteren und unter Bezugnahme auf die beispielhafte Implementierung des CMTS 104 führt die Kopfstellen-MAC 218 notwendige Verfahrensschritte durch, indem sie Software- Funktionen mit der Hilfe der CPU 222 ausführt. Diese Software-Funktionen können entweder im RAM 220 oder im ROM 218 gespeichert werden.
  • Aber Verfahren der vorliegenden Erfindung brauchen nicht auf diese Ausführungsbeispiele beschränkt zu sein. Zum Beispiel können die Verfahren der vorliegenden Erfindung in Software-Routinen verkörpert sein, die in Computersystemen wie etwa einem Computersystem 2300, wie es in 23 gezeigt ist, ablaufen. Verschiedene Ausführungsbeispiele werden im Hinblick auf dieses beispielhafte Computersystem 2300 beschrieben. Nach dem Lesen dieser Beschreibung wird es einem Fachmann auf dem relevanten Fachgebiet offensichtlich sein, wie die Erfindung unter Verwendung anderer Computersysteme und/oder Computerarchitekturen implementiert werden kann. 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 auch einen Hauptspeicher 2305, vorzugsweise einen Direktzugriffsspeicher (RAM), und kann auch einen externen Speicher 2310 umfassen. Der externe Speicher 2310 kann zum Beispiel ein Festplattenlaufwerk 2312 und/oder ein Wechselspeicherlaufwerk 2314 umfassen, das ein Magnetdiskettenlaufwerk, ein Magnetbandlaufwerk, ein CD-Laufwerk, etc. repräsentiert. Das Wechselspeicherlaufwerk 2314 liest aus einer Wechselspeichereinheit 2318 in einer wohl bekannten Art und Weise aus bzw. schreibt in diese hinein. Die Wechselspeichereinheit 2318 repräsentiert eine Magnetdiskette, ein Magnetband, eine CD, etc, die von dem Wechselspeicherlaufwerk 2314 gelesen und beschrieben werden. Wie klar sein wird, umfasst die Wechselspeichereinheit 2318 ein von einem Computer benutzbares Speichermedium, in dem Computer-Software und/oder Daten gespeichert sind.
  • In alternativen Ausführungsbeispielen kann der externe Speicher 2310 andere ähnliche Einrichtungen umfassen, die es erlauben, dass Computerprogramme oder andere Instruktionen in das Computersystem 2300 geladen werden können. Solche Einrichtungen können zum Beispiel eine Wechselspeichereinheit 2322 und eine Schnittstelle 2320 umfassen. Beispiele dafür können eine Programmkassette und eine Kassettenschnittstelle (wie sie etwa in Videospielvorrichtungen vorgefunden werden), einen auswechselbaren Speicherchip (wie etwa ein EPROM oder PROM) und einen assoziierten Sockel sowie auch andere auswechselbare Speichereinheiten 2322 und Schnittstellen 2320 umfassen, die es erlauben, dass Software und Daten von der Wechselspeichereinheit 2322 zu dem Computersystem 2300 übertragen werden können.
  • Das Computersystem 2300 kann auch eine Kommunikationsschnittstelle 2324 umfassen. Die Kommunikationsschnittstelle 2324 erlaubt es, dass Software und Daten zwischen dem Computersystem 2300 und externen Geräten übertragen werden können. Beispiele einer Kommunikationsschnittstelle 2324 können ein Modem, eine Netzwerkschnittstelle (wie etwa eine Ethernet-Karte), einen Kommunikationsport, einen PCMCIA-Schlitz und eine PCMCIA-Karte, eine drahtlose LAN-Schnittstelle (Schnittstelle eines Nahbereichsnetzes), etc. umfassen. Software und Daten, die über die Kommunikationsschnittstelle 2324 übertragen werden, liegen in der Form von Signalen 2328 vor, 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 Kommikationspfad (d.h., Kanal) 2326 bereitgestellt. Dieser Kanal 2326 überträgt die Signale 2328 und kann unter Verwendung von Draht oder Kabel, Glasfaseroptik, einer Telefonleitung, einer Funktelefonverbindung, einer drahtlosen Verbindung und anderer Kommunikationskanäle implementiert werden.
  • In diesem Dokument bezieht sich der Begriff "Computerprogrammerzeugnis" auf Wechselspeichereinheiten 2318, 2322 und die Signale 2328. Diese Computerprogrammerzeugnisse sind Einrichtungen zum Bereitstellen von Software für das Computersystem 2300. Die Erfindung ist auf solche Computerprogrammerzeugnisse ausgerichtet.
  • Computerprogramme (die auch Computersteuerlogik genannt werden) werden in dem Hauptspeicher 2305 und/oder dem externen Speicher 2310 und/oder in Computerprogrammerzeugnissen gespeichert. Computerprogramme können auch über die Kommunikationsschnittstelle 2324 empfangen werden. Solche Computerprogramme ermöglichen es dem Computersystem 2300 dann, wenn sie ausgeführt werden, die Merkmale der vorliegenden Erfindung so durchzuführen, wie sie hier erörtert worden sind. Insbesondere ermöglichen es die Computerprogramme dem Prozessor 2303 dann, wenn sie ausgeführt werden, die Merkmale der vorliegenden Erfindung durchzuführen. Folglich repräsentieren solche Computerprogramme die Steuervorrichtungen des Computersystems 2300.
  • In einem Ausführungsbeispiel, in dem die Erfindung unter Verwendung von Software implementiert ist, kann die Software in einem Computerprogrammerzeugnis gespeichert sein und in das Computersystem 2300 unter Verwendung des Wechselspeicherlaufwerks 2314, des Festplattenlaufwerks 2312 oder der Kommunikationsschnittstelle 2324 geladen werden. Die Steuerlogik (Software) bewirkt dann, wenn sie von dem Prozessor 2303 ausgeführt wird, dass der Prozessor 2303 die Funktionen der Erfindung, wie sie hier beschrieben ist, durchführt.
  • In einem anderen Ausführungsbeispiel ist die Erfindung primär in Hardware unter Verwendung von zum Beispiel Hardware-Komponenten wie etwa anwendungsspezifische integrierte Schaltkreise (ASICs; application specific integrated circuits) implementiert. Eine Implementierung einer oder mehrerer Hardware-Zustandsmaschine(n) zur Durchführung der hier beschriebenen Funktionen wird den Fachleuten auf dem/den relevanten Fachgebiet(en) offensichtlich sein.
  • In noch einem anderen Ausführungsbeispiel wird die Erfindung unter Verwendung einer Kombination aus Hardware und Software implementiert.
  • E. Schlussfolgerung
  • Die vorliegende Erfindung ist nicht auf die Ausführungsbeispiele eines Kabelmodemsystems beschränkt. Die vorliegende Erfindung kann mit jedem System verwendet werden, das TCP-Pakete über ein Netzwerk überträgt. Die vorausgehende Beschreibung der bevorzugten Ausführungsbeispiele ist bereitgestellt worden, um einen Fachmann auf dem Gebiet in die Lage zu versetzen, die vorliegende Erfindung durchführen oder verwenden zu können. Obwohl die Erfindung insbesondere unter Bezugnahme auf bevorzugte Ausführungsbeispiele davon gezeigt und beschrieben worden ist, wird es den Fachleuten auf dem Gebiet klar sein, dass verschiedene Änderungen bezüglich Form und Details durchgeführt werden können, ohne dass vom Schutzumfang der Erfindung abgewichen wird.

Claims (13)

  1. Verfahren zum dynamischen Mischen von Header-Unterdrückungstechniken zur Übertragung von Daten über ein Data Over Cable Service Interface Specification DOCSIS Netzwerk, das aus einem oder mehreren Kabelmodems (106, 108) und wenigstens einem Kabelmodem-Abschlusssystem (104) besteht, wobei das Verfahren die folgenden Schritte umfasst: a) Kommunizieren einer Vielzahl von unterschiedlichen Header-Unterdrückungstechniken und einer eindeutigen Indexzahl, die jeder der Vielzahl von unterschiedlichen Header-Unterdrückungstechniken zugewiesen ist, von wenigstens einem der Kabelmodems (106, 108) zu dem Kabelmodem-Abschlusssystem (104); b) Empfangen einer Vielzahl von Datenpaketen, die von dem wenigstens einen Kabelmodem (108) zu dem Kabelmodem-Abschlusssystem (104) übertragen werden sollen; c) Identifizieren, welches der empfangenen Datenpakete einen Header aufweist, der unterdrückt werden soll; d) Auswählen einer Header-Unterdrückungstechnik aus der Vielzahl von unterschiedlichen Header-Unterdrückungstechniken für jedes der identifizierten Datenpakete; e) Anhängen eines Paket-Header-Elements an jedes der identifizierten Datenpakete, wobei das Paket-Header-Element die eindeutige Indexzahl enthält, die der Header-Unterdrückungstechnik zugewiesen ist, die für jedes der identifizierten Datenpakete ausgewählt worden ist; f) Unterdrücken eines Header jedes der identifizierten Datenpakete unter Verwendung der Header-Unterdrückungstechnik, die für jedes der identifizierten Datenpakete ausgewählt worden ist; g) Verketten jedes Datenpakets, das Headers aufweist, die in Übereinstimmung mit einer der Vielzahl von unterschiedlichen Header-Unterdrückungstechniken unterdrückt werden, in einem einzigen DOCSIS Sendeburst, um einen gemischten Protokoll-Burst zu bilden, und h) Senden des gemischten Protokoll-Burst zu dem Kabelmodem-Abschlusssystem (104).
  2. Verfahren nach Anspruch 1, wobei jedes der empfangenen Datenpakete, die unbekannte Internet Protocol IP Pakete sind, zur Unterdrückung in dem Identifizierungsschritt c) identifiziert werden.
  3. Verfahren nach Anspruch 2, wobei die DOCSIS Nutzlast-Header-Unterdrückung in dem Auswahlschritt d) für jedes der empfangen Datenpakete ausgewählt wird, die unbekannte Internet Protocol IP Pakete sind.
  4. Verfahren nach Anspruch 1, wobei jedes der empfangenen Datenpakete, die Internet Protocol IP/Real-Time Transfer Protocol RTP Pakete mit sich dynamisch ändernden Mustern sind, als einen Header aufweisend, der unterdrückt werden soll, in dem Identifizierungsschritt c) identifiziert werden.
  5. Verfahren nach Anspruch 4, wobei die RTP-Unterdrückung in dem Auswahlschritt d) für jedes der empfangenen Datenpakete ausgewählt wird, die Internet Protocol IP/Real-Time Transfer Protocol RTP Pakete mit sich dynamisch ändernden Mustern sind.
  6. Verfahren nach Anspruch 1, wobei jedes der empfangenen Datenpakete, die Internet Protocol IP/Real-Time Transfer Protocol RTP Pakete mit variabler Länge sind, zur Unterdrückung in dem Identifizierungsschritt c) identifiziert werden.
  7. Verfahren nach Anspruch 6, wobei die dynamische Deltacodierungsunterdrückung in dem Auswahlschritt d) für jedes der empfangenen Datenpakete ausgewählt wird, die Internet Protocol IP/Real-Time Transfer Protocol RTP Pakete variabler Länge sind.
  8. Verfahren zum Erweitern von Datenpaket-Headers, die über ein Data Over Cable Service Interface Specification DOCSIS Netzwerk übertragen werden, das aus einem oder mehreren Kabelmodems (106, 108) und wenigstens einem Kabelmodem-Abschlusssystem (104) besteht, wobei das Verfahren die Folgenden Schritte umfasst: a) Empfangen eines gemischten Protokoll-Burst, der aus einem oder mehreren Datenpaketen besteht, die Headers aufweisen, die in Übereinstimmung mit einer ausgewählten Header-Unterdrückungstechnik einer Vielzahl von unterschiedlichen Header-Unterdrückungstechniken unterdrückt werden, an dem Kabelmodem-Abschlusssystem (104); b) Identifizieren jedes Datenpakets innerhalb des gemischten Protokoll-Burst, das einen unterdrückten Header aufweist; c) Durchsuchen einer Nachschlagetabelle, um einen Satz von Regeln aus einer Vielzahl von Sätzen von Regeln für das Erweitern eines unterdrückten Header jedes der in Schritt b) identifizierten Datenpakete auszuwählen; und d) Erweitern eines unterdrückten Header jedes der Datenpakete gemäß dem Satz von Regeln, der im Schritt c) identifiziert worden ist.
  9. Verfahren nach Anspruch 8, wobei jedes Datenpaket, das in dem Identifizierungsschritt b) identifiziert worden ist, ein angehängtes Paket-Header-Element aufweist, das eine Indexzahl enthält.
  10. Verfahren nach Anspruch 9, wobei der Durchsuchungsschritt c) jede Indexzahl verwendet, die in jedem angehängten Paket-Header-Element enthalten ist, um die Nachschlagetabelle zu durchsuchen.
  11. Verfahren nach Anspruch 10, wobei DOCSIS Nutzlast-Header-Erweiterungsregeln in dem Erweiterungsschritt d) für unbekannte Internet Protocol IP Pakete verwendet werden.
  12. Verfahren nach Anspruch 10, wobei Real-Time Transfer Protocol RTP Erweiterungsregeln in dem Erweiterungsschritt d) für Internet Protocol IP/Real-Time Transfer Protocol RTP Pakete mit sich dynamisch ändernden Mustern verwendet werden.
  13. Verfahren nach Anspruch 10, wobei dynamische Deltacodierungs-Erweiterungsregeln in dem Erweiterungsschritt d) für Internet Protocol IP/Real-Time Transfer Protocol RTP Pakete variabler Länge verwendet werden.
DE60130367T 2000-10-11 2001-10-11 Verfahren zum dynamischen mischen von Paketkopfunterdrückungstechniken Expired - Lifetime DE60130367T2 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US23952400P 2000-10-11 2000-10-11
US23952600P 2000-10-11 2000-10-11
US23953000P 2000-10-11 2000-10-11
US23952700P 2000-10-11 2000-10-11
US23952500P 2000-10-11 2000-10-11
US239525P 2000-10-11
US239527P 2000-10-11
US239524P 2000-10-11
US239530P 2000-10-11
US239526P 2000-10-11
US24055000P 2000-10-13 2000-10-13
US240550P 2000-10-13
PCT/US2001/031567 WO2002032034A2 (en) 2000-10-11 2001-10-11 Method for dynamically mixing header suppressing techniques

Publications (2)

Publication Number Publication Date
DE60130367D1 DE60130367D1 (de) 2007-10-18
DE60130367T2 true DE60130367T2 (de) 2008-06-12

Family

ID=27559291

Family Applications (4)

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

Family Applications Before (2)

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

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60131890T Expired - Lifetime DE60131890T2 (de) 2000-10-11 2001-10-11 Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung

Country Status (4)

Country Link
US (9) US6963931B2 (de)
EP (4) EP1338128B1 (de)
DE (4) DE60118609T2 (de)
WO (5) WO2002032080A1 (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
AU2001238297A1 (en) * 2000-02-15 2001-08-27 Broadcom Corporation Method, system and computer program product for scheduling upstream communications
US6842459B1 (en) 2000-04-19 2005-01-11 Serconet Ltd. Network combining wired and non-wired segments
WO2002032080A1 (en) * 2000-10-11 2002-04-18 Broadcom Corporation Cable modem system and method for supporting packet pdu compression
US6649567B2 (en) * 2001-10-11 2003-11-18 Isp Investments Inc. Controlled release microbiocide for porous surfaces
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
US7773631B2 (en) * 2001-02-15 2010-08-10 Broadcom Corporation Specialized data transfer in a wireless communication system
US7085232B1 (en) * 2001-03-29 2006-08-01 Cisco Technology, Inc. ARQ in a point to multipoint network
US20020191691A1 (en) * 2001-05-10 2002-12-19 Holborow Clive Eric Payload header suppression including removal of fields that vary in known patterns
US7688824B2 (en) * 2001-07-11 2010-03-30 Broadcom Corporation Method, system, and computer program product for suppression index reuse and packet classification for payload header suppression
US7126920B2 (en) * 2001-08-08 2006-10-24 General Instrument Corporation Performance of lifetest using CMTS as a proxy
US7336680B2 (en) * 2001-09-18 2008-02-26 Scientific-Atlanta, Inc. Multi-carrier frequency-division multiplexing (FDM) architecture for high speed digital service
US7586914B2 (en) * 2001-09-27 2009-09-08 Broadcom Corporation Apparatus and method for hardware creation of a DOCSIS header
WO2003028304A1 (en) * 2001-09-27 2003-04-03 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
US7839860B2 (en) * 2003-05-01 2010-11-23 Genesis Microchip Inc. Packet based video display interface
US8204076B2 (en) * 2003-05-01 2012-06-19 Genesis Microchip Inc. Compact packet based multimedia interface
US7567592B2 (en) * 2003-05-01 2009-07-28 Genesis Microchip Inc. Packet based video display interface enumeration method
US7620062B2 (en) 2003-05-01 2009-11-17 Genesis Microchips Inc. Method of real time optimizing multimedia packet transmission rate
US7068686B2 (en) 2003-05-01 2006-06-27 Genesis Microchip Inc. Method and apparatus for efficient transmission of multimedia data packets
US7424558B2 (en) * 2003-05-01 2008-09-09 Genesis Microchip Inc. Method of adaptively connecting a video source and a video display
US20040218599A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Packet based video display interface and methods of use thereof
US7405719B2 (en) * 2003-05-01 2008-07-29 Genesis Microchip Inc. Using packet transfer for driving LCD panel driver electronics
US20040221312A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Techniques for reducing multimedia data packet overhead
US8068485B2 (en) 2003-05-01 2011-11-29 Genesis Microchip Inc. Multimedia interface
US7733915B2 (en) * 2003-05-01 2010-06-08 Genesis Microchip Inc. Minimizing buffer requirements in a digital video system
US20040218624A1 (en) * 2003-05-01 2004-11-04 Genesis Microchip Inc. Packet based closed loop video display interface with periodic status checks
US8059673B2 (en) * 2003-05-01 2011-11-15 Genesis Microchip Inc. Dynamic resource re-allocation in a packet based video display interface
US8040915B2 (en) * 2003-05-19 2011-10-18 Broadcom Corporation System, method, and computer program product for facilitating communication between devices implementing proprietary features in a DOCSIS-compliant broadband communication system
US20050030944A1 (en) * 2003-05-27 2005-02-10 General Instrument Corporation Method and apparatus for reducing packet size employing payload header suppression (PHS)
IL157787A (en) 2003-09-07 2010-12-30 Mosaid Technologies Inc Modular outlet for data communications network
US7450586B2 (en) * 2003-07-22 2008-11-11 Motorola, Inc. Network header compression arrangement
US7417989B1 (en) * 2003-07-29 2008-08-26 Sprint Spectrum L.P. Method and system for actually identifying a media source in a real-time-protocol stream
US11736311B2 (en) 2003-09-05 2023-08-22 Comcast Cable Communications, Llc Gateway for transporting out-of-band messaging signals
US7774436B2 (en) 2003-09-05 2010-08-10 Comcase Cable Holdings, LLC Method and system for internet protocol provisioning of customer premises equipment
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
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
US7634090B2 (en) * 2003-09-26 2009-12-15 Genesis Microchip Inc. Packet based high definition high-bandwidth digital content protection
US7613300B2 (en) * 2003-09-26 2009-11-03 Genesis Microchip Inc. Content-protected digital link over a single signal line
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
WO2005089055A2 (en) 2004-03-19 2005-09-29 Nortel Networks Limited Communicating processing capabilites 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
CN101129005A (zh) * 2004-08-25 2008-02-20 汤姆逊许可公司 有线数据业务的压缩方法
US7729346B2 (en) 2004-09-18 2010-06-01 Genband Inc. UMTS call handling methods and apparatus
US7830864B2 (en) 2004-09-18 2010-11-09 Genband Us Llc Apparatus and methods for per-session switching for multiple wireline and wireless data types
KR100677144B1 (ko) * 2004-10-20 2007-02-02 삼성전자주식회사 Ｗｕｓｂ 버스를 경유하여 데이터를 송수신하는 방법 및장치
CN101133658A (zh) * 2004-10-22 2008-02-27 特克雷克公司 移动性管理设备及方法
EP1807951B1 (de) 2004-10-29 2019-04-10 Avago Technologies International Sales Pte. Limited Hierarchische mehrkanalkommunikation auf flussebene
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
CN100593332C (zh) * 2004-12-10 2010-03-03 美国博通公司 有线电视通信系统中的上行信道绑定
US8228926B2 (en) * 2005-04-12 2012-07-24 Genband Us Llc Dynamic loading for signaling variants
US20060262788A1 (en) * 2005-05-23 2006-11-23 Broadcom Corporation Dynamic payload header suppression extensions for IPV6
US8483173B2 (en) 2005-05-31 2013-07-09 Genband Us Llc Methods and systems for unlicensed mobile access realization in a media gateway
US7668195B2 (en) 2005-06-14 2010-02-23 General Instrument Corporation Method and apparatus for transmitting and receiving data over a shared access carrier network
US7710966B1 (en) * 2005-07-19 2010-05-04 Google Inc. Distributing packets more evenly over trunked network links
US7961739B2 (en) 2005-07-21 2011-06-14 Genband Us Llc Systems and methods for voice over multiprotocol label switching
US7961754B2 (en) * 2005-07-26 2011-06-14 Electronics And Telecommunications Research Institute Apparatus and method for multimedia data transmission and reception in cable network using broadband and physical layer frame structure
US20070086434A1 (en) * 2005-10-19 2007-04-19 Muthaiah Venkatachalam Efficient mechanisms for supporting VoIp in a wireless network
JP4690857B2 (ja) * 2005-10-28 2011-06-01 マスプロ電工株式会社 バルク伝送システム
JP4779955B2 (ja) * 2006-01-06 2011-09-28 富士通株式会社 パケット処理装置及びパケット処理方法
US7835346B2 (en) * 2006-01-17 2010-11-16 Genband Us Llc Methods, systems, and computer program products for providing transcoder free operation (TrFO) and interworking between unlicensed mobile access (UMA) and universal mobile telecommunications system (UMTS) call legs using a media gateway
KR20070082992A (ko) * 2006-02-20 2007-08-23 엘지이노텍 주식회사 쌍방향 통신용 셋톱 박스
US7552363B2 (en) * 2006-03-23 2009-06-23 Arm Limited Generation of trace elements within a data processing apparatus
US9100407B2 (en) * 2006-03-23 2015-08-04 Cisco Technology, Inc. Method and system to enhance performance of a session initiation protocol network and its elements
FR2902268A1 (fr) * 2006-06-08 2007-12-14 France Telecom Systeme d'acces a un service de television sur ip dans un reseau a architecture ims
KR101266021B1 (ko) * 2006-10-13 2013-05-21 삼성전자주식회사 데이터 통신 시스템에서 이동통신 단말기를 제어하는 장치및 방법
US20080101366A1 (en) * 2006-10-31 2008-05-01 Motorola, Inc. Methods for optimized tunnel headers in a mobile network
US20080117906A1 (en) * 2006-11-20 2008-05-22 Motorola, Inc. Payload header compression in an rtp session
US7912050B2 (en) * 2006-12-05 2011-03-22 Electronics And Telecommunications Research Institute Method for classifying downstream packet in cable modem termination system at head-end supporting channel bonding mode, and cable modem termination system
CN101558626A (zh) * 2006-12-12 2009-10-14 维斯塔斯风力系统有限公司 多协议风力涡轮机系统和方法
CN101622711B (zh) 2006-12-28 2012-07-18 杰恩邦德公司 用于无声插入描述符（sid）转换的方法、系统
EP2677714B1 (de) 2007-03-12 2015-04-22 Citrix Systems, Inc. Systeme und Verfahren zum Verwenden von Komprimierungsverläufen zum Verbessern der Netzwerkleistung
US7865585B2 (en) 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing dynamic ad hoc proxy-cache hierarchies
US7619545B2 (en) * 2007-03-12 2009-11-17 Citrix Systems, Inc. Systems and methods of using application and protocol specific parsing for compression
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
AU2012203797B2 (en) * 2007-03-12 2015-05-07 Citrix Systems, Inc. Systems and methods for using compression histories to improve network performance
US7532134B2 (en) 2007-03-12 2009-05-12 Citrix Systems, Inc. Systems and methods for sharing compression histories between multiple devices
US7827237B2 (en) 2007-03-12 2010-11-02 Citrix Systems, Inc. Systems and methods for identifying long matches of data in a compression history
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 한국전자통신연구원 케이블모뎀의 수신채널집합 설정 및 변경 방법
WO2009086939A1 (en) * 2008-01-11 2009-07-16 Telefonaktiebolaget Lm Ericsson (Publ) Message handling in an ip multimedia subsystem
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
US8429440B2 (en) * 2009-05-13 2013-04-23 Stmicroelectronics, Inc. Flat panel display driver method and system
US8860888B2 (en) * 2009-05-13 2014-10-14 Stmicroelectronics, Inc. Method and apparatus for power saving during video blanking periods
US8760461B2 (en) * 2009-05-13 2014-06-24 Stmicroelectronics, Inc. Device, system, and method for wide gamut color space support
US8156238B2 (en) * 2009-05-13 2012-04-10 Stmicroelectronics, Inc. Wireless multimedia transport method and apparatus
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
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
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 纜線數據機及網路電話通訊協定選擇方法
CN105191225A (zh) * 2013-03-28 2015-12-23 株式会社东芝 通信装置、通信方法、以及通信程序
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
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
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
US10616380B2 (en) 2014-06-19 2020-04-07 Cavium, Llc Method of handling large protocol layers for configurable extraction of layer information and an apparatus thereof
US9635146B2 (en) 2014-06-19 2017-04-25 Cavium, Inc. Method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof
US9628385B2 (en) 2014-06-19 2017-04-18 Cavium, Inc. Method of identifying internal destinations of networks packets and an apparatus thereof
US9742694B2 (en) 2014-06-19 2017-08-22 Cavium, Inc. Method of dynamically renumbering ports 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
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
US10306024B2 (en) * 2016-03-25 2019-05-28 Amazon Technologies, Inc. Compression dictionary snapshot system and method
US10264103B2 (en) 2016-03-25 2019-04-16 Amazon Technologies, Inc. Compression dictionary generation service system and method
US11126663B2 (en) * 2017-05-25 2021-09-21 Intel Corporation Method and apparatus for energy efficient decompression using ordered tokens
FR3070566B1 (fr) * 2017-08-30 2020-09-04 Sagemcom Broadband Sas Procede de recuperation d'un fichier cible d'un logiciel d'exploitation et dispositif d'utilisation
US11502723B2 (en) * 2018-02-28 2022-11-15 Maxlinear, Inc. Full-duplex cable modem calibration
JP7024578B2 (ja) * 2018-04-24 2022-02-24 富士通株式会社 通信装置、通信制御方法、および通信制御プログラム
US10862807B2 (en) * 2018-09-19 2020-12-08 Cisco Technology, Inc. Packet telemetry data via first hop node configuration
CN112260982B (zh) * 2019-07-22 2022-03-11 华为技术有限公司 音频处理方法及设备
US11356563B1 (en) * 2020-06-16 2022-06-07 Andre Greene Amplified cable modem
US11805079B2 (en) * 2021-11-17 2023-10-31 Charter Communications Operating, Llc Methods and apparatus for coordinating data transmission in a communications network
WO2024059061A1 (en) * 2022-09-13 2024-03-21 Arris Enterprises Llc Active system for partitioning identifier space

Family Cites Families (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4814746A (en) * 1983-06-01 1989-03-21 International Business Machines Corporation Data compression method
US4862167A (en) * 1987-02-24 1989-08-29 Hayes Microcomputer Products, Inc. Adaptive data compression method and apparatus
US4864572A (en) * 1987-05-26 1989-09-05 Rechen James B Framing bitstreams
CA2065578C (en) 1991-04-22 1999-02-23 David W. Carr Packet-based data compression method
US5307413A (en) 1991-07-19 1994-04-26 Process Software Corporation Method and apparatus for adding data compression and other services in a computer network
US5537551A (en) * 1992-11-18 1996-07-16 Denenberg; Jeffrey N. Data compression method for use in a computerized informational and transactional network
CA2125337A1 (en) 1993-06-30 1994-12-31 Marlin Jay Eller Method and system for searching compressed data
US5530645A (en) 1993-06-30 1996-06-25 Apple Computer, Inc. Composite dictionary compression system
WO1995029437A1 (fr) * 1994-04-22 1995-11-02 Sony Corporation Dispositif et methode pour transmettre des donnees et dispositif et methode pour enregistrer des donnees
US6195391B1 (en) * 1994-05-31 2001-02-27 International Business Machines Corporation Hybrid video compression/decompression system
DE69433620T2 (de) * 1994-06-16 2004-08-12 Seiko Epson Corp. Datenkomprimierungsverfahren
EP0718980A1 (de) * 1994-12-20 1996-06-26 International Business Machines Corporation Verfahren zur Kompression von Daten für individuelle Folgen eines Datenstroms mit Hilfe eines Wörterbuches und Vorrichtung dafür
US6055268A (en) 1996-05-09 2000-04-25 Texas Instruments Incorporated Multimode digital modem
FI962381A (fi) 1996-06-07 1997-12-08 Nokia Telecommunications Oy Datan pakkaaminen tietoliikenneyhteydellä
US5831558A (en) 1996-06-17 1998-11-03 Digital Equipment Corporation Method of compressing and decompressing data in a computer system by encoding data using a data dictionary
JPH1074159A (ja) * 1996-08-30 1998-03-17 Hitachi Ltd 計算機システムの制御方法
JPH10154044A (ja) * 1996-11-22 1998-06-09 Advantest Corp 転送データ圧縮展開方式及び転送データ圧縮展開装置
US5987022A (en) * 1996-12-27 1999-11-16 Motorola, Inc. Method for transmitting multiple-protocol packetized data
US5889385A (en) * 1997-08-19 1999-03-30 Advanced Charger Technology, Inc. Equalization of series-connected cells of a battery using controlled charging and discharging pulses
US6067381A (en) * 1997-06-13 2000-05-23 International Business Machines Corporation Method of reinitializing dictionaries in a data transmission system using data compression
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
JP3337633B2 (ja) * 1997-12-03 2002-10-21 富士通株式会社 データ圧縮方法及びデータ復元方法並びにデータ圧縮プログラム又はデータ復元プログラムを記録したコンピュータ読み取り可能な記録媒体
US5945933A (en) * 1998-01-27 1999-08-31 Infit Ltd. Adaptive packet compression apparatus and method
CA2260289A1 (en) * 1998-01-29 1999-07-29 Steven Michael Bellovin A method of improving data compression over unreliable underlying networks
US6222916B1 (en) * 1998-05-22 2001-04-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for introducing and modifying telecommunications services
US20010004768A1 (en) * 1998-09-28 2001-06-21 Hodge Winston W. Hodge Winston W. Highly integrated computer controlled digital head end
US6438123B1 (en) * 1998-11-10 2002-08-20 Cisco Technology, Inc. Method and apparatus for supporting header suppression and multiple microflows in a network
US6624761B2 (en) * 1998-12-11 2003-09-23 Realtime Data, Llc Content independent data compression method and system
US6986157B1 (en) * 1998-12-21 2006-01-10 3Com Corporation Method and system for dynamic service registration in a data-over-cable system
NO991371L (no) * 1999-03-22 2000-09-25 Fileflow As FremgangsmÕte ved overføring av filer i et datakommunikasjonsnett
US6295481B1 (en) * 1999-03-24 2001-09-25 Ecp Family Properties Serial bus control system for sewing equipment
US6198735B1 (en) 1999-05-20 2001-03-06 Motorola, Inc. Method for retransmitting a data packet in a packet network
US6542504B1 (en) 1999-05-28 2003-04-01 3Com Corporation Profile based method for packet header compression in a point to point link
US6597812B1 (en) * 1999-05-28 2003-07-22 Realtime Data, Llc System and method for lossless data compression and decompression
US6680955B1 (en) * 1999-08-20 2004-01-20 Nokia Networks Oy Technique for compressing a header field in a data packet
US6788707B1 (en) * 1999-08-31 2004-09-07 Broadcom Corporation Method for the suppression and expansion of packet header information in cable modem and cable modem termination system devices
US6909715B1 (en) * 1999-08-31 2005-06-21 Broadcom Corporation Method and apparatus for the reduction of upstream request processing latency in a cable modem termination system
US6882637B1 (en) * 1999-10-14 2005-04-19 Nokia Networks Oy Method and system for transmitting and receiving packets
US6542931B1 (en) * 1999-11-05 2003-04-01 Nokia Corporation Using sparse feedback to increase bandwidth efficiency in high delay, low bandwidth environment
US6300887B1 (en) 1999-11-09 2001-10-09 Nokia Networks Oy Efficient handoff procedure for header compression
US6535925B1 (en) * 1999-11-09 2003-03-18 Telefonaktiebolaget L M Ericsson (Publ) Packet header compression using division remainders
AU1834600A (en) * 1999-11-30 2001-06-12 Telogy Networks, Inc. Synchronization of voice packet generation to unsolicited grants in a docsis cable modem voice over packet telephone
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
DE60141982D1 (de) 2000-09-01 2010-06-10 Broadcom Corp 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
WO2002032080A1 (en) * 2000-10-11 2002-04-18 Broadcom Corporation Cable modem system and method for supporting packet pdu compression
US7310353B1 (en) * 2000-10-30 2007-12-18 Yair Bourlas Compression of overhead in layered data communication links
US6963587B2 (en) * 2000-11-16 2005-11-08 Telefonaktiebolaget Lm Ericsson (Publ) Communication system and method utilizing request-reply communication patterns for data compression
US7082569B2 (en) * 2001-01-17 2006-07-25 Outlooksoft Corporation Systems and methods providing dynamic spreadsheet functionality
US20020191691A1 (en) * 2001-05-10 2002-12-19 Holborow Clive Eric Payload header suppression including removal of fields that vary in known patterns
US7688824B2 (en) * 2001-07-11 2010-03-30 Broadcom Corporation Method, system, and computer program product for suppression index reuse and packet classification for payload header suppression
KR100441589B1 (ko) * 2002-04-01 2004-07-23 삼성전자주식회사 Ｒｔｐ패킷 생성/복원 장치 및 방법
US7382749B2 (en) * 2002-11-26 2008-06-03 Sony Corporation Systems, methods, and apparatus with a common wireless communications protocol
US20050030944A1 (en) 2003-05-27 2005-02-10 General Instrument Corporation Method and apparatus for reducing packet size employing payload header suppression (PHS)
US7675895B2 (en) * 2004-09-14 2010-03-09 Alcatel-Lucent Usa Inc. Method and apparatus for wireless communication using voice over internet protocol
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
EP1348290A2 (de) 2003-10-01
DE60118609D1 (de) 2006-05-18
US7451235B2 (en) 2008-11-11
US20070058640A1 (en) 2007-03-15
EP1338128A2 (de) 2003-08-27
EP1348290B1 (de) 2007-09-05
DE60131890T2 (de) 2008-12-11
WO2002032034A3 (en) 2002-07-04
WO2002032073A2 (en) 2002-04-18
EP1340351A1 (de) 2003-09-03
US7693186B2 (en) 2010-04-06
EP1340351B1 (de) 2007-12-12
US20020049861A1 (en) 2002-04-25
US7130314B2 (en) 2006-10-31
WO2002032073A3 (en) 2002-06-13
WO2002032080A1 (en) 2002-04-18
US8767776B2 (en) 2014-07-01
WO2002032081A1 (en) 2002-04-18
US7275115B2 (en) 2007-09-25
WO2002032101A2 (en) 2002-04-18
DE60120466T2 (de) 2007-01-18
US7428247B2 (en) 2008-09-23
US20020073227A1 (en) 2002-06-13
DE60130367D1 (de) 2007-10-18
US7389527B2 (en) 2008-06-17
DE60131890D1 (de) 2008-01-24
DE60118609T2 (de) 2007-05-03
EP1338128B1 (de) 2006-06-07
US6963931B2 (en) 2005-11-08
EP1348289A2 (de) 2003-10-01
WO2002032034A9 (en) 2003-09-04
US20080304490A1 (en) 2008-12-11
US20020106029A1 (en) 2002-08-08
WO2002032101A3 (en) 2002-06-20
DE60120466D1 (de) 2006-07-20
US20020062394A1 (en) 2002-05-23
WO2002032034A2 (en) 2002-04-18
US20080010300A1 (en) 2008-01-10
EP1348289B1 (de) 2006-04-05
US20020080868A1 (en) 2002-06-27
US20110058540A1 (en) 2011-03-10

Similar Documents

Publication Publication Date Title
DE60130367T2 (de) Verfahren zum dynamischen mischen von Paketkopfunterdrückungstechniken
DE69736713T2 (de) Anordnung und verfahren zur übertragung von ip-daten über ein satellitennetz
DE60307406T2 (de) Packetübertragungssystem und Packetempfangssystem
DE60110303T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE60316094T2 (de) Verfahren, Vorrichtung und System für die Komprimierung von verlängerten Kopffeldern
DE69924732T2 (de) Quellknoten fuer ein breitbandnetzwerk mit atm zellen
DE60113906T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE602004010254T2 (de) Burst-übertragung
DE60017442T2 (de) Spärliche rückkoppelung in drahtlosen systemen die hohe verzögerung und niedrige bandbreite aufweisen
DE60018927T2 (de) Verfahren und Vorrichtung zur Datenpaketenübertragung
DE60116998T2 (de) In zugangstechnologie integrierte header-komprimierung
DE60108324T2 (de) System und Verfahren zur Erhöhung von Nachrichtendurchsatz in einem Funknetzwerk
DE10231958B4 (de) Verfahren und System zum Übertragen von Datenpaketen über ein Netzwerk an ausgewählte mehrere Bestimmungsorte, sowie computerlesbares Medium
DE10231941A1 (de) Datenpaketstruktur für direkt adressiertes Multicast-Protokoll
DE60118673T2 (de) System und Methode zur Bewahrung der Bandbreite bei der Übertragung von Nachrichtenpaketen
DE19919177A1 (de) Netzwerk mit mehreren Netzwerk-Clustern zur drahtlosen Übertragung von Paketen
EP1269718B1 (de) Verfahren zur signalisierung unterschiedlicher kopfinformationen
DE10160844B4 (de) System zur Übertragung eines Datenstroms über ein Netzwerk an unterschiedliche Netzwerkprotokolle unterstützende Empfänger
DE10303488A1 (de) System und Verfahren zur Verbesserung des Übertragungsverhaltens einer nach dem TCP/IP-Protokoll arbeitenden Datenübertragung über eine unidirektionale Funkverbindung
DE10219316A1 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem Kommunikationssystem
DE10129323A1 (de) Generische Schnittstelle zwischen einer Applikation und einer Transportschicht

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