JP4683495B2

JP4683495B2 - ケーブル・データ・サービスにおける圧縮

Info

Publication number: JP4683495B2
Application number: JP2007529790A
Authority: JP
Inventors: ジーンロバーツ，ハロルド
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2004-08-25
Filing date: 2004-08-25
Publication date: 2011-05-18
Anticipated expiration: 2024-08-25
Also published as: EP1782560A1; JP2008511248A; WO2006025816A9; CN101129005A; US20070297319A1; MY143331A; BRPI0419011A; EP1782560A4; WO2006025816A1

Description

本発明は、一般的には、データ圧縮に関し、より具体的には、ケーブル・モデムを介したデータ・サービスのためのデータ圧縮に関する。

ＤＯＣＳＩＳ（米国における登録商標）（ＤａｔａＯｖｅｒＣａｂｌｅＳｅｒｖｉｃｅＩｎｔｅｒｆａｃｅＳｐｅｃｉｆｉｃａｔｉｏｎ）およびＥｕｒｏ‐ＤＯＣＳＩＳ（ＥｕｒｏｐｅａｎＤａｔａＯｖｅｒＣａｂｌｅＳｅｒｖｉｃｅＩｎｔｅｒｆａｃｅＳｐｅｃｉｆｉｃａｔｉｏｎ）は、ケーブル・モデムおよびこのケーブル・モデムをサポートする設備のためのインターフェース規格を定めている。ケーブル関連企業は、自己のケーブル・モデム・サービスのデータ・スループット性能がＤＳＬデータ・サービスに対して競争力を有することを望んでいる。ＡＤＳＬデータ・サービスは、下流側で１．５〜９Ｍｂｐｓ、上流側で１６〜６４０ｋｂｐｓを提供する。ＶＤＳＬは、下流側で１３〜５２ｂｐｓ、上流側で１．５〜２．３Ｍｂｐｓを提供する。上流側の転送速度に対する企業顧客の要求を満たすために、ケーブル業界は、近年、ＤＯＣＳＩＳ（米国における登録商標）の仕様を更新した。ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳのケーブル・モデムの仕様は、現在では、２５６値直交振幅変調（ＱＡＭ：ｑｕａｄｒａｔｕｒｅａｍｐｌｉｔｕｄｅｍｏｄｕｌａｔｉｏｎ）を上流側および下流側の双方でサポートしている。しかしながら、ＨＦＣネットワークは、上流側および下流側で利用可能な帯域幅を制限し、ＨＦＣネットワークの品質は、最大の変調を２５６ＱＡＭ以下に制限することがある。アナログ電話モデムにおいて使用されることの多いデータ圧縮技術をケーブル・モデムのためのＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳ仕様において使用することによって、ケーブル・データ・サービスは、既存のＨＦＣネットワークを使用してより高い実効的なスループットを提供することができる。

電気通信業界において、「高速」アナログ電話モデムを使用したデータ圧縮がテレビ電話を提供するために使用されている。アナログ電話モデム（ＩＴＵ‐ＴＶ．３４、ＩＴＵ‐ＴＶ．９０、ＩＴＵ‐ＴＶ．９２）において使用される変調技術は、時と共に改良されてきているが、帯域幅が制限された音声電話ネットワークのための、理論的な限界に次第に近づいてきている。アナログ電話モデム業界は、使用するデータ圧縮アルゴリズム（例えば、マイクロコム・ネットワーキング・プロトコル（ＭＮＰ）５、ＩＴＵ‐ＴＶ．４２ｂｉｓ、およびその後のＩＴＵ‐ＴＶ．４４）を改良することによって、アナログ電話モデムを改良してきた。ケーブル・モデム業界において、ケーブルをベースとするデータ・サービスの実効的なスループットを増加させるために、同様のデータ圧縮方法を使用することが可能である。

効果的なスループットを増加させるために、ケーブル業界は以下の方法を使用している。
Ａ）上流側：アドバンスド変調を使用する。例えば、ＱＰＳＫおよび１６ＱＡＭ（「ＤＯＣＳＩＳ（米国における登録商標）‐無線周波数インターフェース（ＲＦＩ）仕様」ＳＰ‐ＲＦＩｖ１．１‐Ｉ１０‐０３０７３０）から２５６ＱＡＭおよびＳ‐ＣＤＭＡ（ＤＯＣＳＩＳ‐無線周波数インターフェース仕様ＳＰ‐ＲＦＩｖ２．０‐Ｉ０４‐０３０７３０）に移る。
Ｂ）上流側：上流側チャンネルで利用可能な帯域幅を増加する（ＳＰ‐ＲＦＩｖ１．１‐Ｉ１０‐０３０７３０）。
Ｃ）下流側：帯域幅は、ＩＴＵ‐ＴＪ．８３‐Ｂネットワークにおいては６ＭＨｚに制限され、ＩＴＵ‐ＴＪ．８３‐Ａネットワークにおいては８ＭＨｚに制限される（ＳＰ‐ＲＦＩｖ２．０‐Ｉ０４‐０３０７３０）。
Ｄ）下流側：６４ＱＡＭ〜２５６ＱＡＭまでの変調を使用する（ＳＰ‐ＲＦＩｖ２．０‐Ｉ０４‐０３０７３０）。
Ｅ）ヘッダ抑制／圧縮（ｈｅａｄｅｒｓｕｐｐｒｅｓｓｉｏｎ／ｃｏｍｐｒｅｓｓｉｏｎ）（ＳＰ‐ＲＦＩｖ１．１‐Ｉ１０‐０３０７３０）
現在のＨＦＣネットワークは、１０２４ＱＡＭまでの変調をサポートすることができるが、アナログ電話モデムの場合と同様に、ＨＦＣネットワークに適した変調技術は、その性能の限界に近づいてきている。

方法「Ａ」および「Ｄ」は、実効的なスループットを増加させるために、複雑な変調を使用する。５１２ＱＡＭおよび１０２４ＱＡＭのようにより複雑なＱＡＭ変調を使用することは、ＨＦＣネットワークの品質のため、可能でない場合がある。方法「Ｂ」は、より多くのデータを搬送するためにチャンネルの帯域幅を増加する。現在、上流側チャンネルの帯域幅は、６．４ＭＨｚに制限されている。ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳ仕様では、上流側のデータ・スループットを増加するためにさらにチャンネル帯域幅を増加させることがあるが、この可能性は少ない。なぜならば、合計上流側周波数帯は、全てのケーブル・モデムによって共有され、さらなる増加は、合計上流側周波数帯（５〜４２ＭＨｚ）に制限されるからである。方法「Ｃ」は、国内外のビデオ規格に依存するものであり、下流側でのチャンネルの帯域幅を増加させてデータ・スループットを増加させる可能性は少ない。今日サービスが提供されているＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳバージョン１．１および２．０において使用されている方法「Ｅ」は、データ圧縮の一形態であるが、フレームまたはパケット（「ダイアグラム」とも呼ばれる）のヘッダ部分に制限され、フレームまたはパケットのより大きなペイロード部分における圧縮を試みるものではない。

従って、実効的なスループットを高めるために、ケーブル・モデムを利用したデータ・サービスにおけるデータ圧縮に対する要求が存在する。

（発明の概要）
ケーブル・データ・サービスにおいて圧縮を行うための方法は、プロトコル・レイヤーを介してデータを提供するステップと、プロトコル・レイヤー内のＤＯＣＳＩＳレイヤーで圧縮するステップとを含む。ＤＯＣＳＩＳレイヤーで圧縮を行うステップは、ＤＯＣＳＩＳレイヤーよりも上位のプロトコル・レイヤーの全てのレイヤーで圧縮を行うステップを含む。

代替的には、ケーブル・データ・サービスにおいて圧縮を行うための方法は、プロトコル・レイヤーを介してデータを提供するステップと、ＤＯＣＳＩＳレイヤーよりも上位のネットワーク・プロトコル・レイヤーにおいてデータを圧縮するステップとを含む。

本発明のより完全な理解は、図面を参照して以下の説明を考慮することによって得られるであろう。

説明のための参考として、図１のダイアグラム１００は、ウエブ・ページを見るのに必要な各プロトコル・レイヤーを示している。データ圧縮は、フレームをベースとするネットワークまたはパケットをベースとするネットワークにおいて２つの形態、即ち、ヘッダ抑制／圧縮（ｈｅａｄｅｒｓｕｐｒｅｓｓｉｏｎ／ｃｏｍｐｒｅｓｓｉｏｎ）およびペイロード圧縮（ｐａｙｌｏａｄｃｏｍｐｒｅｓｓｉｏｎ）をとることができる。イーサネット（登録商標）またはＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳネットワークのようなフレームをベースとするネットワークおよびパケットをベースとするネットワークは、物理レイヤー・インターフェース（図１に示さず）、データ・リンク・レイヤー（メディア・アクセス制御（ＭＡＣ：ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）サブレイヤーを含む）（図１におけるダイアグラム１０３、１０４、１０５）、ネットワーク・レイヤー（図１のダイアグラム１０２）、トランスポート・レイヤー（図１のダイアグラム１０１）、さらに、ＩＴＵ‐ＴＸ．２００において規定された開放型システム間相互接続（ＯＳＩ：ＯｐｅｎＳｙｓｔｅｍｓＩｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）に従った上位のレイヤー関数を有する。データ・リンク・レイヤー内の通信オブジェクトは、「フレーム」に分けられ、ネットワーク・レイヤー内のオブジェクトは、「パケット」に分けられる。図１のイーサネット（登録商標）パケット・フレーム・ダイアグラム１０３に示すように、一般に、フレームおよびパケットは、ヘッダ、ペイロード・データ・ユニット（ＰＤＵ：ｐａｙｌｏａｄｄａｔａｕｎｉｔ）、およびトレイラから構成される。ヘッダはフレーム／パケットの目的、終点アドレスを特定し、エラー訂正情報を含むことがある。ＰＤＵは、フレームまたはパケットによって搬送されるデータである。データ・リンク・フレームのＰＤＵは、データをあるピアから別のピアに搬送し、このデータは、ＭＡＣフレームの全部または一部であり、ネットワークが３つ以上のレイヤーを使用する場合には、パケットである。通常、トレイラは、エラー検出または訂正の別の形態である。

ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳ仕様は、最小で５つのレイヤーのネットワークを定義し、ヘッダによるオーバーヘッドが、より重要なＰＤＵの利用可能な帯域幅を減らすことを認識し、ＭＡＣＰＤＵ内でイーサネット（登録商標）メディア・アクセス制御ＭＡＣヘッダおよびＴＣＰ／ＵＤＰ／ＩＰパケット・ヘッダを圧縮するために、「ペイロード・ヘッダ抑制（ＰＨＳ：ＰａｙｌｏａｄＨｅａｄｅｒＳｕｐｒｅｓｓｉｏｎ）」を実施している。ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳ仕様に基づくケーブル・データ・サービスは、ＴＣＰ／ＵＤＰ１０１を使用し、このＴＣＰ／ＵＤＰ１０１は、ＩＰパケット内１０２で、イーサネット（登録商標）ＭＡＣフレーム１０３に含まれ、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＭＡＣフレーム１０４に含まれ、ＭＰＥＧ‐２フレーム１０５に含まれる。ペイロード・ヘッダ抑制ＰＨＳは、ＴＣＰ／ＵＤＰ／ＩＰパケットおよびイーサネット（登録商標）フレームに関わるヘッダを圧縮する標準的な方法を提供する。しかしながら、ＰＨＳは、ケーブル・モデムとケーブル・データ・サービス・プロバイダのヘッドエンドにおけるケーブル・モデム終端システム（ＣＴＭＳ：ＣａｂｌｅＭｏｄｅｍＴｅｒｍｉｎａｔｉｏｎＳｙｓｔｅｍ）との間のヘッダ抑制／圧縮のみを提供し、ケーブル・モデムＣＭからケーブル・モデムＣＭ、または民生用アプリケーションからピア・アプリケーションへのエンド・ツー・エンドヘッダ抑制／圧縮を提供しない。従って、民生用ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌａｒｅａｎｅｔｗｏｋ）、ケーブル事業者のＬＡＮ、イントラネット（または、他のワイド・エリア・ネットワーク）、さらに、終端末でのＬＡＮ（存在する場合）に対しても、帯域幅の要求は低減されない。本提案の一実施態様は、ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）によって定められたＴＣＰ／ＵＤＰ／ＩＰヘッダ抑制／圧縮規格を使用してエンド・ツー・エンドの圧縮を提供し、エンド・ツー・エンドのスループット効率を向上させることである。例えば、ＩＥＴＦは、ＲＦＣ２５０７（「ＩＰヘッダ圧縮」）、ＲＦＣ２５０８（「低速シリアル・リンクのためのＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮」）、ＲＦＣ３０９５（「堅牢なヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル」）、およびＲＦＣ３５４５（「高遅延、パケット損失、および並べ替え（Ｒｅｏｒｄｅｒｉｎｇ）を有するリンクのための向上した圧縮されたＲＴＰ（ＣＲＴＰ）」）を定めている。ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳネットワークでの使用のために、これらの標準的なヘッダ抑制／圧縮方法に適合するように制御メカニズムを修正、または再定義することが必要であろう。これらの標準的な抑制／圧縮方法を使用することによって、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳＰＨＳの実効性が低下するものの、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳＰＨＳのペイロード・ヘッダ抑制の使用は妨げられない。

他の領域を圧縮する機会は、パケットおよび／またはフレームのＰＤＵフィールドを圧縮する際にある。ＰＤＵの圧縮は、実効的な帯域幅を増加させるためのより魅力的な方法である。なぜならば、ＰＤＵのサイズは対応するヘッダよりも大幅に大きいからである。例えば、最大のイーサネット（登録商標）フレームは１５１８バイトであり、そのうちの４バイトは「トレイラ」であり、ヘッダは約４０バイトを使用するため、最大のＰＤＵは約１４７４バイトになる。本提案の第２の実施態様は、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳネットワークにおいて使用されるフレームおよびパケットのＰＤＵの一方または両方において標準的なペイロード圧縮方法を使用することにある。例えば、ＲＦＣ３１７３（「ＩＰペイロード圧縮プロトコル（ＩＰＣｏｍｐ）」）、ＲＦＣ２３９４（「ＤＥＦＬＡＴＥを使用したＩＰペイロード圧縮」）、ＲＦＣ２３９５（「ＬＺＳを使用したＩＰペイロード圧縮」）、およびＩＴＵ‐Ｔ勧告Ｖ．４４（「データ圧縮処理」）は、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳネットワークにおける使用に適したＰＤＵ圧縮方法を定めている。

ＰＤＵ圧縮は、データ・リンク／ＭＡＣレイヤーまたはネットワーク・レイヤーで行われ、各選択には異なる利点が存在する。ネットワーク・レイヤーでのＰＤＵ圧縮は、エンド・ツー・エンドでの圧縮により適しているが、データ・リンク／ＭＡＣレイヤーでの圧縮よりも全体的な圧縮が小さい。しかしながら、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳ仕様を使用したケーブル・データ・サービスでは、ケーブル・モデムと遠端（ｆａｒ‐ｅｎｄ）との間のハンドシェーク（ｈａｎｄｓｈａｋｅ）は、ＰＤＵ圧縮を発生させる可能性が少ない。なぜならば、遠端システムは、ＲＦＣ３１７３やＲＦＣ３０５１などのマッチしたＰＤＵ圧縮方法を実施している可能性が少ないからである。データ・リンクＭＡＣ／レイヤーでのＰＤＵ圧縮は、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳ仕様がＰＤＵを採用するように変更されたとすれば、ＰＤＵ圧縮ハンドシェークを完了させる可能性が高くなるであろう。従って、ケーブル・モデムおよびＣＭＴＳとの間のＭＡＣレイヤーでの通信は、ＰＤＵ圧縮を実施するであろう。データ・リンク／ＭＡＣレイヤーでのＰＤＵ圧縮により、ローカル・ケーブル・サービス企業およびケーブル・データ・サービスの利用者は、より高いデータ・スループットおよびケーブル・スペクトラムのより効率的な使用など、ＰＤＵの圧縮の利点を享受することができるであろう。

再び、図１は、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳケーブル・データ・サービスを介してＴＣＰ／ＩＰを使用して利用者およびインターネットとの間のウエブ・ページ・データを転送するために必要な各プロトコル・レイヤーを示している。図１は必要なマルチプル・ヘッダを例示しているが、必要となる追加のヘッダ・オーバーヘッドを含んでいない。なぜならばＭＰＥＧ‐２フレームの１８４バイトのペイロードの制限内に収まるように、ＴＣＰ／ＩＰパケットが複数のフレームに分割されなければならないからである。イーサネット（登録商標）ＭＡＣおよびより上位のレイヤーでのヘッダ抑制／圧縮は、オリジナルのＴＣＰ／ＩＰパケットを分割することが依然として必要なものの、データ転送効率を向上させるであろう。

図２のダイアグラム２００は、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳＭＡＣレイヤーで実施されるＰＤＵ圧縮を例示している。このレイヤーにおけるＰＤＵ圧縮もまた、イーサネット（登録商標）ＭＡＣおよびより上位のレイヤーに関わるヘッダを圧縮する。なぜならば、これらのレイヤーは、ＤＯＣＳＩＳ／Ｅｕｒｏ‐ＤＯＣＳＩＳＭＡＣレイヤーのための「ペイロード・データ」の部分である。ＰＤＵ圧縮により、ヘッダ抑制／圧縮のみの場合よりも全体的なデータ転送効率が向上する。

本発明の開示内容を組み込んだ様々な実施の形態を本明細書において図示し、説明したが、当業者であれば、これらの開示内容を組み込んだ上で、多くの様々な他の実施の形態を容易に考案することが可能である。

図１は、ウエブ・ページを見るのに必要な各プロトコル・レイヤーのダイアグラムである。図２は、本発明に従ったＤＯＣＳＩＳＭＡＣペイロード・データ・ユニットの圧縮によって生じる図１の各レイヤーの圧縮を示すダイアグラムである。

Claims

ケーブル・モデムを通じてプロトコル・レイヤーを介してデータを受信するステップと、
圧縮されたデータを形成するためにケーブル・サービスを介して前記データの圧縮を行うステップとを含み、
前記ケーブル・サービスを介してデータの圧縮を行うステップは、前記プロトコル・レイヤーのデータ・リンク・レイヤー内のＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーで少なくともペイロード・データ・ユニット（ＰＤＵ）フィールドの圧縮を行うステップを含み、前記ＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーで圧縮を行うステップは、ＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーにおける前記プロトコル・レイヤーおよび当該ＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーよりも上位の前記プロトコル・レイヤーのレイヤー内のみに存在する少なくとも前記ペイロード・データ・ユニット（ＰＤＵ）フィールドの圧縮を行うステップを含み、前記ケーブル・サービスを介してデータの圧縮を行うステップは、ＭＰＥＧメディア・アクセス制御（ＭＡＣ）レイヤー内の少なくともペイロード・データ・ユニット・フィールドの圧縮を含まない、
ケーブル・データ・サービスにおいて圧縮を行うための方法。
前記ケーブル・サービスを介してデータの圧縮を行う前記ステップが、伝送制御プロトコル（ＴＣＰ）レイヤーの圧縮を行うステップを含む、請求項１に記載の方法。
前記ケーブル・サービスを介してデータの圧縮を行う前記ステップが、インターネット・プロトコル（ＩＰ）レイヤーの圧縮を行うステップを含む、請求項１に記載の方法。
前記ケーブル・サービスを介してデータの圧縮を行う前記ステップが、イーサネット（登録商標）プロトコル・レイヤーの圧縮を行うステップを含む、請求項１に記載の方法。
前記ケーブル・サービスを介してデータの圧縮を行う前記ステップが、前記ケーブル・サービス・レイヤーを介したデータのペイロード・データ・ユニット（ＰＤＵ）のメディア・アクセス制御（ＭＡＣ）レイヤーの圧縮のみを行うステップを含む、請求項１に記載の方法。
ウエブ・ページを見るためにケーブル・モデムを通じてプロトコル・レイヤーを介してデータを受信するステップと、
少なくともＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーの圧縮されたペイロード・データ・ユニット（ＰＤＵ）フィールドを形成するために前記プロトコル・レイヤーのデータ・リンク・レイヤー内の前記ＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーの少なくともペイロード・データ・ユニット（ＰＤＵ）フィールドの圧縮を行うステップとを含み、
前記ＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーで圧縮を行うステップは、前記ＤＯＣＳＩＳメディア・アクセス制御（ＭＡＣ）レイヤーよりも上位の前記プロトコル・レイヤーのレイヤー内のみに存在する少なくとも前記ペイロード・データ・ユニット（ＰＤＵ）フィールドの圧縮を行うステップを含み、前記ケーブル・サービスを介してデータの圧縮を行うステップは、ＭＰＥＧメディア・アクセス制御（ＭＡＣ）レイヤー内の少なくともペイロード・データ・ユニット・フィールドの圧縮を含まない、
ケーブル・データ・サービスにおいて圧縮を行うための方法。
前記ＤＯＣＳＩＳレイヤー内部に含まれる前記プロトコル・レイヤーのうちの各レイヤーが、少なくとも伝送制御プロトコル（ＴＣＰ）レイヤー、インターネット・プロトコル（ＩＰ）レイヤー、およびイーサネット（登録商標）プロトコル・レイヤーの少なくとも１つを含む、請求項６に記載の方法。