ケーブルモデムを通じてプロトコルレイヤーを介してデータを受信するステップと、ケーブルサービスを介してデータの圧縮を行うステップとを含み、前記ケーブルサービスを介してデータの圧縮を行うステップは、前記プロトコルレイヤー内のDOCSISレイヤーで少なくともペイロードデータユニットPDUフィールドの圧縮を行うステップを含むケーブルデータサービスにおいて圧縮を行うための方法。説明のための参考として、図1のダイアグラム100は、ウエブページを見るのに必要な各プロトコルレイヤーを示している。データ圧縮は、フレームをベースとするネットワークまたはパケットをベースとするネットワークにおいて2つの形態、即ち、ヘッダ抑制/圧縮headersupression/compressionおよびペイロード圧縮payloadcompressionをとることができる。イーサネット登録商標またはDOCSIS/Euro‐DOCSISネットワークのようなフレームをベースとするネットワークおよびパケットをベースとするネットワークは、物理レイヤーインターフェース図1に示さず、データリンクレイヤーメディアアクセス制御MAC:MediaAccessControlサブレイヤーを含む図1におけるダイアグラム103、104、105、ネットワークレイヤー図1のダイアグラム102、トランスポートレイヤー図1のダイアグラム101、さらに、ITU‐TX.200において規定された開放型システム間相互接続OSI:OpenSystemsInterconnectionに従った上位のレイヤー関数を有する。データリンクレイヤー内の通信オブジェクトは、フレームに分けられ、ネットワークレイヤー内のオブジェクトは、パケットに分けられる。図1のイーサネット登録商標パケットフレームダイアグラム103に示すように、一般に、フレームおよびパケットは、ヘッダ、ペイロードデータユニットPDU:payloaddataunit、およびトレイラから構成される。ヘッダはフレーム/パケットの目的、終点アドレスを特定し、エラー訂正情報を含むことがある。PDUは、フレームまたはパケットによって搬送されるデータである。データリンクフレームのPDUは、データをあるピアから別のピアに搬送し、このデータは、MACフレームの全部または一部であり、ネットワークが3つ以上のレイヤーを使用する場合には、パケットである。通常、トレイラは、エラー検出または訂正の別の形態である。DOCSIS/Euro‐DOCSIS仕様は、最小で5つのレイヤーのネットワークを定義し、ヘッダによるオーバーヘッドが、より重要なPDUの利用可能な帯域幅を減らすことを認識し、MACPDU内でイーサネット登録商標メディアアクセス制御MACヘッダおよびTCP/UDP/IPパケットヘッダを圧縮するために、ペイロードヘッダ抑制PHS:PayloadHeaderSupressionを実施している。DOCSIS/Euro‐DOCSIS仕様に基づくケーブルデータサービスは、TCP/UDP101を使用し、このTCP/UDP101は、IPパケット内102で、イーサネット登録商標MACフレーム103に含まれ、DOCSIS/Euro‐MACフレーム104に含まれ、MPEG‐2フレーム105に含まれる。ペイロードヘッダ抑制PHSは、TCP/UDP/IPパケットおよびイーサネット登録商標フレームに関わるヘッダを圧縮する標準的な方法を提供する。しかしながら、PHSは、ケーブルモデムとケーブルデータサービスプロバイダのヘッドエンドにおけるケーブルモデム終端システムCTMS:CableModemTerminationSystemとの間のヘッダ抑制/圧縮のみを提供し、ケーブルモデムCMからケーブルモデムCM、または民生用アプリケーションからピアアプリケーションへのエンドツーエンドヘッダ抑制/圧縮を提供しない。従って、民生用ローカルエリアネットワークLAN:localareanetwok、ケーブル事業者のLAN、イントラネットまたは、他のワイドエリアネットワーク、さらに、終端末でのLAN存在する場合に対しても、帯域幅の要求は低減されない。本提案の一実施態様は、IETFInternetEngineeringTaskForceによって定められたTCP/UDP/IPヘッダ抑制/圧縮規格を使用してエンドツーエンドの圧縮を提供し、エンドツーエンドのスループット効率を向上させることである。例えば、IETFは、RFC2507IPヘッダ圧縮、RFC2508低速シリアルリンクのためのIP/UDP/RTPヘッダの圧縮、RFC3095堅牢なヘッダ圧縮ROHC:フレームワークおよび4つのプロファイル、およびRFC3545高遅延、パケット損失、および並べ替えReorderingを有するリンクのための向上した圧縮されたRTPCRTPを定めている。DOCSIS/Euro‐DOCSISネットワークでの使用のために、これらの標準的なヘッダ抑制/圧縮方法に適合するように制御メカニズムを修正、または再定義することが必要であろう。これらの標準的な抑制/圧縮方法を使用することによって、DOCSIS/Euro‐DOCSISPHSの実効性が低下するものの、DOCSIS/Euro‐DOCSISPHSのペイロードヘッダ抑制の使用は妨げられない。他の領域を圧縮する機会は、パケットおよび/またはフレームのPDUフィールドを圧縮する際にある。PDUの圧縮は、実効的な帯域幅を増加させるためのより魅力的な方法である。なぜならば、PDUのサイズは対応するヘッダよりも大幅に大きいからである。例えば、最大のイーサネット登録商標フレームは1518バイトであり、そのうちの4バイトはトレイラであり、ヘッダは約40バイトを使用するため、最大のPDUは約1474バイトになる。本提案の第2の実施態様は、DOCSIS/Euro‐DOCSISネットワークにおいて使用されるフレームおよびパケットのPDUの一方または両方において標準的なペイロード圧縮方法を使用することにある。例えば、RFC3173IPペイロード圧縮プロトコルIPComp、RFC2394DEFLATEを使用したIPペイロード圧縮、RFC2395LZSを使用したIPペイロード圧縮、およびITU‐T勧告V.44データ圧縮処理は、DOCSIS/Euro‐DOCSISネットワークにおける使用に適したPDU圧縮方法を定めている。PDU圧縮は、データリンク/MACレイヤーまたはネットワークレイヤーで行われ、各選択には異なる利点が存在する。ネットワークレイヤーでのPDU圧縮は、エンドツーエンドでの圧縮により適しているが、データリンク/MACレイヤーでの圧縮よりも全体的な圧縮が小さい。しかしながら、DOCSIS/Euro‐DOCSIS仕様を使用したケーブルデータサービスでは、ケーブルモデムと遠端far‐endとの間のハンドシェークhandshakeは、PDU圧縮を発生させる可能性が少ない。なぜならば、遠端システムは、RFC3173やRFC3051などのマッチしたPDU圧縮方法を実施している可能性が少ないからである。データリンクMAC/レイヤーでのPDU圧縮は、DOCSIS/Euro‐DOCSIS仕様がPDUを採用するように変更されたとすれば、PDU圧縮ハンドシェークを完了させる可能性が高くなるであろう。従って、ケーブルモデムおよびCMTSとの間のMACレイヤーでの通信は、PDU圧縮を実施するであろう。データリンク/MACレイヤーでのPDU圧縮により、ローカルケーブルサービス企業およびケーブルデータサービスの利用者は、より高いデータスループットおよびケーブルスペクトラムのより効率的な使用など、PDUの圧縮の利点を享受することができるであろう。再び、図1は、DOCSIS/Euro‐DOCSISケーブルデータサービスを介してTCP/IPを使用して利用者およびインターネットとの間のウエブページデータを転送するために必要な各プロトコルレイヤーを示している。図1は必要なマルチプルヘッダを例示しているが、必要となる追加のヘッダオーバーヘッドを含んでいない。なぜならばMPEG‐2フレームの184バイトのペイロードの制限内に収まるように、TCP/IPパケットが複数のフレームに分割されなければならないからである。イーサネット登録商標MACおよびより上位のレイヤーでのヘッダ抑制/圧縮は、オリジナルのTCP/IPパケットを分割することが依然として必要なものの、データ転送効率を向上させるであろう。図2のダイアグラム200は、DOCSIS/Euro‐DOCSISMACレイヤーで実施されるPDU圧縮を例示している。このレイヤーにおけるPDU圧縮もまた、イーサネット登録商標MACおよびより上位のレイヤーに関わるヘッダを圧縮する。なぜならば、これらのレイヤーは、DOCSIS/Euro‐DOCSISMACレイヤーのためのペイロードデータの部分である。PDU圧縮により、ヘッダ抑制/圧縮のみの場合よりも全体的なデータ転送効率が向上する。本発明の開示内容を組み込んだ様々な実施の形態を本明細書において図示し、説明したが、当業者であれば、これらの開示内容を組み込んだ上で、多くの様々な他の実施の形態を容易に考案することが可能である。