(57)【特許請求の範囲】
【請求項１】
第１のネットワーク要素と第２のネットワーク要素とを含むネットワークにおけるデータ処理のための方法であって、前記ネットワークはイーサネット（登録商標）・プロトコルが用いられ、前記データは、フレームに組織化され、前記方法は、データリンク層において又は物理層において用いられ、
−  データ・フレームを前記第１のネットワーク要素から前記第２のネットワーク要素に送信するステップと、
−  前記第２のネットワーク要素は、前記第１のネットワーク要素に制御情報を提供するステップと、
−  第１のネットワーク要素は前記制御情報から、正しく受信されたデータ・フレーム、又は、誤って受信されたデータ・フレームを判定するステップと、
−  前記データ・フレームの判定により、破損したデータ・フレームを特定した場合、前記第１のネットワーク要素から前記第２のネットワーク要素への前記データ・フレームの再送信を開始するステップと、
を含み、
前記制御情報は、肯定応答フレーム、又は、否定応答フレームであり、
前記肯定応答フレームは、前記第２のネットワーク要素において受信されたデータ・フレームのフィンガプリントとして用いるＣＲＣコンテンツを含み、
前記否定応答フレームは、前記第２のネットワーク要素において受信されたＣＲＣコンテンツ、及び、前記第２のネットワーク要素において受信されたペイロードから計算されたＣＲＣコンテンツを含み、
前記第１のネットワーク要素が、前記データ・フレームを格納するためのバッファを含み、
前記第１のネットワーク要素と前記第２のネットワーク要素とが、デジタル加入者線を介して接続され、さらに、
前記第１のネットワーク要素において、正しく受信されたと判定され、特定された前記データ・フレームが前記第１のネットワーク要素に格納された最も古いデータ・フレームではないデータ・フレームに対応する場合に、前記の現在特定されたデータ・フレームが前記第１のネットワーク要素において削除され、この現在特定されたデータ・フレームよりも古い前記データ・フレームが、前記第１のネットワーク要素から前記第２のネットワーク要素へと再送信されるステップを含むことを特徴とする方法。
【請求項２】
前記第１のネットワーク要素は、前記制御情報を用いて前記第１のネットワーク要素に搬送された前記ＣＲＣコンテンツが、前記第１のネットワーク要素によって、特定のデータ・フレームに対して判定されたＣＲＣコンテンツと一致しない場合に、前記データ・フレームを再送信することを特徴とする、請求項１に記載の方法。
【請求項３】
前記制御情報は、前記第２のネットワーク要素によって前記受信されたデータから計算されたＣＲＣコンテンツを含むことを特徴とする、請求項１乃至請求項２に記載の方法。
【請求項４】
前記制御情報は、前記データ・フレームが誤って受信された場合にのみ、送信されることを特徴とする、請求項１乃至３に記載の方法。
【請求項５】
前記第１のネットワーク要素は、前記制御情報に含まれるＣＲＣコンテンツと、前記バッファに格納された前記データ・フレームのＣＲＣコンテンツとを比較することを特徴とする請求項１乃至４に記載の方法。
【請求項６】
前記第１のネットワーク要素及び／又は前記第２のネットワーク要素が、デジタル加入者線アクセス・マルチプレクサ（ＤＳＬＡＭ）であることを特徴とする、請求項１乃至請求項５のいずれかに記載の方法。
【請求項７】
前記第２のネットワーク要素が、契約者宅内設備、特にＤＳＬモデムであることを特徴とする、請求項１乃至請求項６のいずれかに記載の方法。
【請求項８】
プロセッサ・ユニットを含むデータ処理用装置であって、前記プロセッサ・ユニットが、請求項１乃至請求項７のいずれかに記載の方法が該プロセッサ・ユニット上で実行可能となるように配置されたことを特徴とする、装置。
【請求項９】
前記装置が、通信装置、特にネットワーク要素であることを特徴とする、請求項８に記載の装置。
【請求項１０】
前記装置が、ＤＳＬＡＭ又はＤＳＬモデムであることを特徴とする、請求項８又は９のいずれかに記載の装置。
【請求項１１】
請求項８乃至請求項１０のいずれかに記載の装置を含むことを特徴とする、通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理のための方法及び装置、並びにそのような装置を含む通信システムに関する。
【背景技術】
【０００２】
ＤＳＬ（デジタル加入者線）は、電話アクセス・ネットワークの配線を通じてデジタル・データを伝送する技術の一系列である。ＤＳＬ技術は、多くの場合「ｘＤＳＬ」と呼ばれ、「ｘ」は、種々のＤＳＬの変種を表す。
【０００３】
非対称デジタル加入者線（ＡＤＳＬ、ＩＴＵ−Ｔ  Ｇ．９９２．１）は、ＤＳＬの一形態であり、銅の電話線を通じて、従来の音声帯域モデムが提供できるデータ伝送よりも高速なデータ伝送を可能にするデータ通信技術である。このような高速伝送は、音声通話では通常用いられない周波数、とりわけ通常の人間の聴覚よりも高い周波数を利用することによって達成される。
【０００４】
ＡＤＳＬ２（ＩＴＵ−Ｔ  Ｇ．９９２．３）及びＡＤＳＬ２＋（ＩＴＵ−Ｔ  Ｇ．９９２．５）は、ＡＤＳＬの変種であり、両方とも、基本のＡＤＳＬと比べてより優れた性能を提供する。
【０００５】
ＶＤＳＬ（超高速ＤＳＬ、ＩＴＵ−Ｔ  Ｇ．９９３．１）並びにＶＤＳＬ２（超高速ＤＳＬ２、ＩＴＵ−Ｔ  Ｇ．９９３．２）は、一対のツイス  トペア配線を通じてさらに高速なデータ伝送を提供するｘＤＳＬ技術である。これは、主として、より広い周波数範囲を用いることによって達成される。
【０００６】
ｘＤＳＬ技術は、もともとは単純旧式電話サービス（ＰＯＴＳ）用に設計された銅線の既存のインフラストラクチャを活用する。それらは、電話局（ＣＯ）から配備することもでき、例えば、顧客の敷地の近くに設置されることが好ましいファイバ供給キャビネット（fiber-fed cabinet）から配備することもでき、又は建物内に配備することもできる。
【０００７】
現実の通信経路は、基本的な物理法則に起因する紛失及び誤りを有する。デジタル世界においては、典型的には、ビット誤り率が１０-12よりも低く、パケット紛失率が１０-8よりも優れている場合に、そのリンクは高品質であるものとみなされる。
【０００８】
それでもやはり、技術的な制約に起因する著しく高い（悪い）ビット誤り率を有する通信リンクもある。このような例の１つは、典型的なパケット紛失率が１０-5よりも大きいＤＳＬ線である。
【０００９】
アプリケーションの中には、パケット紛失又はビット誤りに対して寛容なものもあるが、かなりの数のアプリケーションは、誤り率が実質上ゼロに近くなることを要求する。このようなシナリオにおいては、紛失又は欠損パケットの問題を克服するために、再送信又は前方誤り訂正（ＦＥＣ）が用いられる。
【００１０】
紛失に対して非常に敏感なアプリケーションについての１つの例は、映像コンテンツのリアルタイム・ストリーミングである。この場合、一つのパケットの紛失が、ＴＶ画面上のアーチファクトとして目に見える誤りを生じさせる。高精細度ＴＶ（ＨＤＴＶ）のアプリケーションは、１秒あたり膨大な量のパケットを必要とするので、もしＤＳＬの基本的なパケット紛失率が適用されたならば許容しがたい数のアーチファクトが生じることになる。
【００１１】
伝送制御プロトコル（ＴＣＰ）は、伝送されるデータにオーバーヘッドを付加することによって再送信能力を提供することが知られている。これは、送信機においても受信機においても複雑な処理を必要とし、かつ肯定応答パケットの逆方向のフローを必要とし、それによって逆方向又はフィードバック・チャネルにもオーバーヘッド・データが付加される。
【００１２】
ＴＣＰによって導入されるオーバーヘッドは、順方向においては転送パケットあたり２０バイトであり（ＴＣＰヘッダ）、逆方向においては転送パケットあたり６４バイトである（ＴＣＰ肯定応答パケット）。ＴＣＰは、エンド・ツー・エンド・プロトコルなので、完全なエンド・ツー・エンドのリンク経路の往復遅延よりも高い遅延を転送データ・ストリームに導入する。結果として、ＴＣＰは、インターネット・アプリケーションがリアルタイム・ストリーミングを必要とし、かつ再送信能力に依拠する場合には、そのインターネット・アプリケーションに１秒を超える遅延を導入する。
ＴＣＰは、マルチキャスト配信に準拠していない。結果として、ＴＣＰは、ＤＳＬを通じたＩＰＴＶのようなアプリケーションのために用いることができない。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
解決すべき課題は、上述のような短所を克服することであり、特に、ＨＤＴＶのような高品位のアプリケーションにさえ適したＤＳＬ接続の効率的な利用を可能にする解決策を提供することである。
【課題を解決するための手段】
【００１４】
この課題は、独立請求項の特徴に従って解決される。さらなる実施形態は、従属請求項からもたらされる。
【００１５】
この課題を克服するために、第１のネットワーク要素と第２のネットワーク要素とを含むネットワークにおけるデータ処理のための方法が提供され、この方法は、
（ａ）第２のネットワーク要素が第１のネットワーク要素に制御情報を提供するステップと、
（ｂ）第１のネットワーク要素から第２のネットワーク要素へ送信されたデータの部分が制御情報によって特定されるステップと、
（ｃ）データの部分が特定されると、第１のネットワーク要素から第２のネットワーク要素への再送信を開始することができるステップと
を含む。
【００１６】
それゆえ、第１のネットワーク要素は、制御情報を受信すると、受信機において正しく受信された又は正しくなく受信された、それゆえ再送信を必要とすることがある少なくとも１つのデータの部分（例えば、データ・パケット又はデータ・フレーム）を判定することができる。
データの部分は、少なくとも１つのデータの部分を含むことができることに留意されたい。特に、データは、（いくつかの）フレーム及び／又はパケットに組織化されるものとすることができる。
【００１７】
この手法は、とりわけ以下の利点を有する。
−  パケット紛失率を少なくとも３桁のオーダーで改善することができる。
−  本手法は、新旧の機器（本機構が可能な機器及び可能でない機器）の相互運用を可能にする。
−  フィードバック・チャネルは、非常に低い帯域幅しか必要としない。
−  本手法は、再送信を要求しないが遅延に対して敏感な他のサービスに対して最小限の影響しか与えない。
−  さらに、本手法は、第２のネットワーク要素（受信機）、特にＤＳＬモデムにおいて、最小限のプロトコル・オーバーヘッドしか必要としない。
−  順方向において通常のデータに付加的なデータ（例えば、ヘッダ）を付加する必要がないので、順方向における帯域幅を広げる必要はない。
−  第１のネットワーク要素、例えばＤＳＬＡＭにおけるプロトコル・オーバーヘッドは中程度にすぎない。
−  本手法はソフトウェアとして実装することができるので、既存の第２のネットワーク要素機器（受信機、ＤＳＬモデム）をファームウェアの更新によって容易にアップグレードすることができる。
−  提供される手法は、短い待ち時間を可能にする。
【００１８】
提供される手法は、第１のネットワーク要素と第２のネットワーク要素との間で、特にＤＳＬ接続（又はｘＤＳＬ接続若しくはその派生物）を用いることができる。
さらに、第１のネットワーク要素及び第２のネットワーク要素は、イーサネット（登録商標）・プロトコルを用いるネットワーク内のネットワーク要素とすることができ、特にこれらは、エンド・ツー・エンド接続のセクション又はセグメントとしてのホップ・ツー・ホップ接続として理解することができる。
【００１９】
一実施形態において、本方法は、データリンク層において又は物理層において用いることができる。
別の実施形態において、ネットワークは、イーサネット・プロトコルを用いるネットワークである。
さらに別の実施形態において、第１のネットワーク要素は、データの少なくとも１つの部分を格納するためのバッファを含む。
このバッファは、再送信バッファとも称され、及び／又は再送信バッファとしても用いられる。
次の実施形態において、データは、少なくとも部分的にパケット及び／又はフレームに組織化される。
【００２０】
別の実施形態に従って、第１のネットワーク要素と第２のネットワーク要素とは、デジタル加入者線を介して接続される。
デジタル加入者線は、ＤＳＬのいずれかの派生物（ｘＤＳＬ、ＶＤＳＬ、ＡＤＳＬ等）を含むことができる。
【００２１】
一実施形態によれば、制御情報は、特に、
−  一方向性関数、
−  ハッシュ関数、
−  コード、特にＣＲＣコード
のうちの１つを利用することによってデータの少なくとも一部分を特定する。
したがって、多様な種類の方法又は関数を用いて、データ（好ましくは、そのフレーム又はパケット）を、好ましくは第２のネットワーク要素から第１のネットワーク要素へと（好ましくはフィードバック・チャネルを介して）伝送されるための小さな帯域幅しか必要としない、所与の表現又はフィンガプリントに対してマッピングすることができる。
【００２２】
別の実施形態によれば、ステップ（ｃ）は、
−  第１のネットワーク要素において特定されたデータの部分が、第１のネットワーク要素に格納された最も古いデータの部分に対応する場合に、この最も古いデータの部分が第１  ネットワーク要素において削除されるステップ、
−  第１のネットワーク要素において特定されたデータの部分が第１のネットワーク要素に格納されていない場合に、何の行動も取らないステップ、
−  第１のネットワーク要素において特定されたデータの部分が第１のネットワーク要素に格納された最も古いデータの部分ではないデータの部分に対応する場合に、現在特定されたデータの部分が第１のネットワーク要素において削除され、この現在特定されたデータの部分よりも古いデータの部分が、第１のネットワーク要素から第２のネットワーク要素へと再送信されるステップ
のうちの少なくとも１つのステップをさらに含む。
【００２３】
さらに別の実施形態において、制御情報は、第２のネットワーク要素において受信に成功しなかった少なくとも１つのデータの部分を特定する。
具体的には、制御情報は、受信されたＣＲＣコンテンツと、第２のネットワーク要素において受信されたデータから計算されたＣＲＣコンテンツとを含むことができる。
別の実施形態として、制御情報は、第１のコンテンツ、特に第２のネットワーク要素において受信されたＣＲＣコンテンツと、第２のコンテンツ、特に第２のネットワーク要素において受信されたデータから計算されたＣＲＣコンテンツとを含む。
それゆえ、このような両方のＣＲＣコンテンツを、第２のネットワーク要素に送信されたデータ又はＣＲＣが正しくなかったかどうかを第１のネットワーク要素が判定することを可能にするために、制御情報として第１のネットワーク要素に搬送することができる。
ＣＲＣコードの代わりに、他のいずれかの種類のコード又はフィンガプリントを使用することができることに留意されたい。
【００２４】
次の実施形態によれば、第１のネットワーク要素は、制御情報を用いて、伝送に成功しなかったデータの部分を判定する。
【００２５】
さらに別の実施形態に従って、第１のネットワーク要素は、制御情報を通じて第１のネットワーク要素に搬送された第１のコンテンツ及び／又は第２のコンテンツが第１のネットワーク要素によって特定のデータの部分について判定されたコンテンツ、特にＣＲＣコンテンツと一致しない場合に、そのデータの部分を再送信する。
第１のコンテンツは、特に第２のネットワーク要素において受信されたＣＲＣコンテンツを含むことができる。第２のコンテンツは、特に第２のネットワーク要素によって受信されたデータから計算されたＣＲＣコンテンツを含むことができる。
【００２６】
ＣＲＣコンテンツは、特に、例えば、計算され及び／又は分解され及び／又は第１のネットワーク要素による比較によって判定されるなどして、決定することができる。
【００２７】
さらに別の実施形態によれば、ステップ（ｃ）は、少なくとも１つの
−  第１のネットワーク要素が、第１のネットワーク要素において特定されたデータの部分が第２のネットワーク要素において受信に成功しなかったものとして特定されたデータに対応する場合に、このデータの部分を第２のネットワーク要素に再送信するステップをさらに含む。
【００２８】
別の実施形態として、第１のネットワーク要素及び／又は第２のネットワーク要素は、デジタル加入者線アクセス・マルチプレクサ（ＤＳＬＡＭ）である。
また、第２のネットワーク要素が、契約者宅内設備、特にＤＳＬモデムであることも、一実施形態である。
【００２９】
上述の問題はさらに、本明細書に記載された方法がプロセッサ・ユニット上で実行可能となるように装備され及び／又は配置されたプロセッサ・ユニットを含む、データ処理用装置によって解決される。
一実施形態によれば、装置は、通信装置、特にネットワーク要素である。好ましくは、装置は、ＤＳＬＡＭ又はＤＳＬモデムとすることができる。
上述の問題はさらに、本明細書に記載されるような装置を含む通信システムによって解決される。
【００３０】
本発明の実施形態は、以下の図面に示され説明される。
【図面の簡単な説明】
【００３１】
【図１】再送信の手法又は概念のアーキテクチャを示す。
【図２】フレームをどのようにペイロードとＣＲＣとに分割することができるかを示す。
【発明を実施するための形態】
【００３２】
本明細書において提供される解決策は、特に、データリンク層におけるＤＳＬＡＭ及びＤＳＬモデムの挙動を修正することができる。１つの特定の目的は、破損したデータ・フレーム（又はデータ・パケット）を再送信することができることであり、ここでプロトコル・オーバーヘッドを最小にすることができる。
【００３３】
この手法は、別段、可能なあらゆるビット誤りについての再送信の成功を保証するものではないが、ほとんどの場合、再送信の成功がもたらされる。
例えば、１０００のビット誤り事象のうち９９９で再送信が成功すれば、全体としてのビット誤り率又はパケット紛失率を３桁のオーダーで改善することができ、これは、多くのアプリケーションにとって十分といえる。
その上、プロトコル・オーバーヘッドは極めて小さく、受信機内部で必要とされる処理オーバーヘッドは小さい。
【００３４】
この解決策は、イーサネット・プロトコルに基づくものとすることができるが、とりわけ、データ・フレーム及び／又はデータ・パケットにわたってチェックサムを利用するどのようなプロトコルにも適用可能とすることができる。
【００３５】
再送信概念の基本的なアーキテクチャは図１に示され、これは、第１のネットワーク要素１０１、例えば送信機、特にＤＳＬＡＭと、第２のネットワーク要素１０２、例えば受信機、特に、契約者宅内設備（ＣＰＥ）であり得るＤＳＬモデムとを含む。第１のネットワーク要素１０１は、データ・チャネル１０３（順方向チャネル）を介してデータを送信し、第２のネットワーク要素は、フィードバック・チャネル１０４（逆方向）を介してデータを送信する。第１のネットワーク要素１０１から第２のネットワーク要素１０２へと向かう方向は下流方向と称されることもあり、反対の方向は上流方向と称されることもある。
しかしながら、本明細書で説明される手法は、上流方向並びに下流方向の両方に対して適用可能である。
【００３６】
送信機１０１は、データ、特にデータ・パケット又はデータ・フレームに組織化されたデータを転送チャネル１０３に沿って受信機１０２に伝送し、同時に、このようなデータの複製を内部バッファ内に一時的に格納する。
【００３７】
受信に成功したフレームごとに、受信機１０２は、受信されたフレームのフィンガプリントを含む制御情報、特に肯定応答フレームを返送する。
フィンガプリントは、例えば２バイト長とすることができるので、それにより、フィードバック・チャネル１０４を介して搬送されるオーバーヘッドが著しく低減される。
有利なことに、データ・チャネル１０３を介した順方向のオーバーヘッドは必要がない場合があり、受信機１０２は、例えば、受信された通常のペイロード・データにわたるチェックサムとして、全く単独でフィンガプリントを生成することができる。
【００３８】
送信機１０１は、受信機１０２によって提供された前述の肯定応答フレームを用いて、どのパケット及び／又はフレームが伝送に成功したかを判定することができる。さらに、送信機１０１は、伝送に成功しなかったパケット及び／又はフレームを受信機１０２に再送信することができる。
【００３９】
肯定応答フレームのコンテンツは、フレームのフィンガプリントを含むことができる。送信機１０１は、このフィンガプリントを自身のバッファ（特に再送信バッファ）内に格納されたフレームのフィンガプリントと比較する。送信機は、一致するフレームをその再送信バッファから除去することが有利である。
【００４０】
好ましくは、伝送されたフレームは、再送信バッファ内に伝送順に格納される。したがって、ＤＳＬ環境は順々に（１つずつ）データ・フレームを処理するので、受信された肯定応答フレームは、ほとんどの場合、最も古いバッファ・エントリと関連付けられる。
【００４１】
パケット紛失の場合、送信機１０１において受信された肯定応答フレームは、最も古いバッファ・エントリに対応しないデータ・フレームを参照することがある。例示的なアルゴリズムとして、種々のケースは、以下のように取り扱われるものとすることができる。
（１）送信機において受信された肯定応答フレームが、再送信バッファ内に格納された最も古いデータ・フレームを参照する場合：この最も古いデータ・フレームのエントリが再送信バッファから削除される。
（２）送信機において受信された肯定応答フレームが、再送信バッファ内に格納されたどのデータ・フレームとも一致しない場合：何の行動も取られない。
（３）送信機において受信された肯定応答フレームが再送信バッファ内に格納されたデータ・フレームＮを参照し、このデータ・フレームが再送信バッファ内で最も古いエントリではない場合：このデータ・フレームＮのエントリが再送信バッファから削除され、再送信バッファ内に格納された、このデータ・フレームＮよりも古いデータ・フレームが、受信機に再送信される。
（４）送信機が、後続のデータ・フレームを伝送すること、及びこの後続のデータ・フレームをそれに応じてバッファに入れることを望むが、再送信バッファが満杯である場合：この最も古いデータ・フレームのエントリが再送信バッファから削除され、この実際の（後続の）データ・フレームの新しいエントリがバッファに追加される。
【００４２】
データ・リンク層のプロトコルがイーサネットである場合、イーサネット・フレームは、この手法の目的のために利用されるチェックサムを提供することができる。
イーサネット・プロトコルは、データ・フレームの最後に２バイトのＣＲＣフィールドを設ける。このＣＲＣフィールドは、フィンガプリントとして用いることができ、受信機における処理オーバーヘッドを著しく低減することができる。
【００４３】
それゆえ、肯定応答フレームはこれらの２バイトを含み、これは、通常のイーサネット・フレームよりもずっと短い。（ＤＳＬ環境においては）全てのフレームは、開始バイト及び終了バイトによって互いに分離されるので、このような短いフレームを、有利に、逆方向に伝送することができる。送信機は、フレーム長を検査することによって、通常のデータ・フレームを肯定応答フレームと容易に区別することができる。フレーム長が合計して例えば４バイト（それぞれが２バイトの長さを含む、フィンガプリント及び通常のＣＲＣ）となる場合、送信機は肯定応答フレームを検出する。フレーム長が６４バイトに等しいか又はそれよりも多くを含む場合には、そのフレームは通常のデータとして認識される。
【００４４】
提示した実施形態に加えて、又はその代替として、制御情報は、第２のネットワーク要素１０２において受信に成功しなかったペイロード・データ（特にデータ・フレーム及び／又はデータ・パケット）の少なくとも１つの部分を特定することができる。
【００４５】
送信機１０１は、データを転送チャネル１０３に沿って受信機１０２に伝送し、転送されたデータの複製を内部バッファ（再送信バッファとも称される）に（一時的に）格納する。特に、受信に失敗した（即ち、受信機１０２が、データ・フレームが破損されたと判定する）フレームごとに、受信機１０２は否定応答（ＮＡＫ）フレームを返送し、これは、受信されたフレームのＣＲＣフィールドのコンテンツ、並びに受信されたフレームのペイロード・データに基づいて受信機自体によって計算されたＣＲＣ値を含む。
受信機１０２は、破損がペイロード・データに関するものである（ＣＲＣフィールドは誤りを含まない）のか又はＣＲＣ値に関するものである（ペイロード・データは誤りを含まない）のかが分からないので、これら２つのＣＲＣ値は両方とも送信機１０１に返送されることが有利である。
【００４６】
図２に示されるように、この文脈における「ペイロード」は、具体的には、フレームのうちＣＲＣフィールドを含まないデータのことを指す。
【００４７】
イーサネット・フレームのＣＲＣ値は２バイトを有し、かつＮＡＫフレームは伝送が失敗した場合にのみ送信されるので、逆方向１０４において必要とされる帯域幅は非常に小さい。順方向１０３においては、オーバーヘッド・データは必要とされない。
【００４８】
送信機１０１は、このＮＡＫフレームを用いて、どのデータ・パケット及び／又はフレームが伝送に成功しなかったのかを判定する。次いで、この特定のデータ・フレームが再送信される。
【００４９】
ＮＡＫフレームは有利には２つのＣＲＣ値を含むことができ、それら２つのＣＲＣ値のうちの１つは正しい。送信機１０１は、２つのＣＲＣ値を、送信機１０１の再送信バッファ内に格納されたデータ・フレームのＣＲＣと比較して、一致するデータ・フレームを再送信する。
【００５０】
好ましくは、再送信バッファは、伝送されたデータ・フレームをそれらの伝送に従った順序で格納する。したがって、ＮＡＫフレームが受信機１０２から送信機１０１に送信される場合、それは、伝送中に破損した最も古いバッファ・エントリに対して送信される。これは、データ・フレームの厳密な順序が保持されるＤＳＬの環境における場合に特にあてはまる。
【００５１】
例示的なアルゴリズムとして、種々のケースは、以下のように取り扱われるものとすることができる。
（１）ＮＡＫフレームによって搬送された２つのＣＲＣ値のうちの１つが送信機の再送信バッファ内のデータ・フレームと一致する場合：このデータ・フレームが送信機によって再送信される。
（２）ＮＡＫフレームによって搬送された２つのＣＲＣ値のそれぞれが、送信機の再送信バッファ内の別々のデータ・フレームと一致する（即ち、２つのデータ・フレームが特定される）場合：デフォルトで、最も古いデータ・フレームが再送信される。
（３）送信機が、後続のデータ・フレームを伝送すること、及びこの後続のデータ・フレームをそれに応じてバッファに入れることを望むが、再送信バッファが満杯である場合：この最も古いデータ・フレームのエントリが再送信バッファから削除され、この実際の（後続の）データ・フレームの新しいエントリがバッファに追加される。
【００５２】
ＮＡＫフレームは、４バイトのペイロード（２つのＣＲＣ値）並びに２バイトのＣＲＣ値（各イーサネット・フレームに対して通常、付加される）を含むことが好ましく、それゆえ通常のイーサネット・フレームよりも著しく短い。
【００５３】
（ＤＳＬ環境においては）全てのフレームは、開始バイト及び終了バイトによって互いに分離されるので、このような短いフレームを、有利に、逆方向に伝送することができる。送信機は、フレーム長を検査することによって、通常のデータ・フレームをＮＡＫフレームと容易に区別することができる。フレーム長が合計して例えば６バイト（４バイトのペイロードと２バイトの通常ＣＲＣ）となる場合、送信機はＮＡＫフレームを検出する。フレーム長が６４バイトに等しいか又はそれよりも多くを含む場合には、そのフレームは通常のデータとして認識される。
【００５４】
さらなる実施形態の詳細
（１）ＤＳＬモデムの後方互換性
ＤＳＬモデムが、提唱したような再送信アルゴリズムをサポートしない場合、そのモデムは、このような４バイトのフレーム（ＮＡＫフレームの場合は６バイト）を上流方向に送信しない。結果として、再送信はなされないことになる。そのため、どのような新しいＤＳＬＡＭ（再送信アルゴリズムをサポートする）及び古いＤＳＬモデムも、いかなる設定も又はオートネゴシエーションも必要とすることなく、相互運用することが可能である。
【００５５】
（２）上流トラフィックのための再送信
上述の例示的なシナリオによれば、下流トラフィックのみを保護することができる。しかしながら、同じ手法及び／又はアルゴリズムを上流方向で用いることができ、又は両方向に対して同時に用いることができる。
【００５６】
（３）ＡＣＫフレームの紛失
提唱したアルゴリズムは、ＤＳＬ上で起こり得るほとんどのビット誤りの状況に対処する。しかしながら、肯定応答フレーム自体が、逆方向チャネルを介して搬送されているときに紛失されるか又は破損されてしまうシナリオがあり得る。この場合、データ・フレームが不必要に再送信され、受信機において二回受信されることがある。ほとんどのアプリケーション（例えば、ＴＣＰベース又はＲＴＰベースのもの）は、特にそれらのシーケンス番号が同一であることから、このようなデータ・フレームの重複に対処することができる。このようなデータ・フレームの重複に対処できないアプリケーションが存在する場合、そのようなアプリケーションに対するデータ・フローを再送信から除外することができる。以下の（４）を参照のこと。
【００５７】
（４）特定のアプリケーションに対する再送信のイネーブル化及び／又はディスエーブル化
説明したアルゴリズムは、再送信バッファ内に一時的に格納されたデータ・フレームを再送信する。データ・フレームが再送信バッファ内に格納されていない（又は、もはや格納されていない）場合、対応する肯定応答フレームは、アルゴリズムを混乱させない（上記を参照のこと。このような場合、何の行動も取られない）。
したがって、送信機は、どのフレームをバッファに入れるべきか否かを決定することができる。例えば、送信機は、ＴＣＰ層を監視し、特定のＴＣＰポートを有する全てのデータ・フレームをバッファに入れるものから除外することができる。
このようなＴＣＰポート番号は単なる例として挙げたものである。送信機によってアクセス可能及び／又は適用可能ないかなるフィルタ規則も、再送信をディスエーブルにするため又はイネーブルにするために用いることができる。
このような特徴は、受信機に対してどのような処理オーバーヘッドも課さないことが有利である。
同じことが、ＮＡＫフレームにも、それに応じて適用される。
【００５８】
（５）フィンガプリントの衝突
肯定応答フレーム（ＮＡＫフレームではなく）を用いる前述のアルゴリズムの別の問題は、後続のフレームが異なるペイロードを有するけれども同一のフィンガプリントをもたらすことがある（著しく低い）確率である。
第１のデータ・フレーム（フィンガプリント「ｋ」を有する）が順方向伝送の間に紛失／破損した場合、このデータ・フレームは再送信されない。その代わりに、第２のデータ・フレーム（やはり、フィンガプリント「ｋ」を有する）が、たとえこのフレーム内にビット誤りがなかったとしても再送信される。
しかしながら、たった２バイトのフィンガプリントが選択された場合でさえも、２つの同一のフレームが生じる確率は１０-4未満となるので、このことは、些細な問題と考えられる。パケット紛失率が少なくとも４桁のオーダーで改善されるという結果は、非常に多くのシナリオにおいて十分といえる。
当然のことながら、２つの同一フレームが生じる確率は、より精密なフィンガプリントを提供することによって低くすることができる。例えば、４バイト長のフィンガプリントは、フィンガプリントの衝突の確率を１０-9未満の値まで低くすることができる。
【００５９】
（６）ＮＡＫフレームの紛失
提唱した手法は、ＤＳＬ上で起こり得るほとんどのビット誤りの状況に対処する。しかしながら、ＮＡＫフレーム自体が、逆方向チャネルを介して搬送されているときに紛失されるか又は破損されてしまうことがある。この場合、再送信は行われない。こうした事象についての確率は些細なものであり、順方向におけるパケット紛失率と逆方向におけるパケット紛失率の積のオーダーである。例えば、ＤＳＬのパケット紛失率が１０-5である場合、この事象の確率は１０-10のオーダーであり、これはほとんどの場合、無視できる。
【００６０】
（７）破損したペイロード及びＣＲＣ
この場合、ＮＡＫフレームは、送信機の再送信バッファのエントリと一致しない。したがって、データ・フレームは再送信されない。しかしながら、このような誤りの確率はかなり小さい。
【００６１】
（８）バッファにおける二重一致
ＮＡＫの各ＣＲＣがバッファ内のフレームと一致する（２つのフレームが特定される）場合、送信機は、２つのデータ・フレームのうちのどちらを再送信するべきか判定することができない。デフォルトに従って、送信機は、最も上にある（即ち、最も古い）フレームを再送信する。
このデフォルト設定によって、これらの（どちらかといえば起こりそうにない）ケースの半数は解決することができる。
それでも、このような二重一致の確率は２バイトのＣＲＣ値の場合１０―4未満なので、このことは些細な問題である。結果として、パケット紛失率は少なくとも４桁のオーダーで改善され、これは、ほとんどの場合において十分といえる。
【００６２】
（９）順方向経路が１つのフレームから２つのフレームを作成する場合の誤り
これは、ビット誤りが、間違った開始／終了シーケンスをデータ・フレーム及び／又はデータ・パケットの中間に付加するときに起こり得る。
それゆえ、ＮＡＫフレームを用いたアルゴリズムが用いられる場合、受信機は、データ・パケットの最初の半分のためにＮＡＫフレームを送信し、データ・パケットの後半の半分のために別のＮＡＫフレームを送信することになる。
後者のＮＡＫフレームが送信機によって認識され、完全なデータ・パケット（データ・フレーム）の正しい再送信が開始されることになる。
【００６３】
さらなる利点
提示された手法は、特に以下の利点を示す。
−  順方向経路のためのプロトコル・オーバーヘッド（例えば、ヘッダ）が生成されない。したがって、順方向の帯域幅を広げる必要がない。
−  肯定応答フレームのサイズは、具体的には、合計してわずか４バイトとすることができるので、逆方向経路のためのオーバーヘッドは小さい。ＮＡＫフレームの場合には、オーバーヘッドのサイズは、合計して６バイトになる。
−  受信機及び送信機は、巡回冗長検査（ＣＲＣ）を用いて、各データ・フレーム又はデータ・パケットごとに互いに独立してフィンガプリントを生成することができる。このようなＣＲＣが可能なハードウェアは、例えばイーサネットＭＡＣのような、データリンク層デバイスにおいて利用可能である。
−  受信機において要求される付加的な処理は、かなり小さいものとすることができる。したがって、アルゴリズムは、処理能力がより高い新しい受信機ハードウェアを準備することを必要とせずに既存の受信機のファームウェアをアップグレード（例えば、ＩＰＴＶのために用いられている既に配備されたＡＤＳＬ２＋  ＣＰＥのアップグレード）するだけで実装することができる。
−  再送信は、例えば、再送信によって導入されるジッタに対するアプリケーションの感度に応じて、特定のアプリケーションに対してイネーブル／ディスエーブルにすることができる。
−  送信機は、受信機が、提唱された再送信プロトコルを取り扱うことができるかどうかを知る必要はない。この再送信プロトコルを実装していてもいなくても、送信機と受信機とのどのような組み合わせも、いかなる設定及び／又はオートネゴシエーションも必要とすることなく相互運用することができる。
−  提唱された再送信によって導入される遅延は些細なものであり、ＤＳＬ接続の往復時間のみから成る。
−  提供される手法は、上流方向及び／又は下流方向に適用可能である。
−  提供される手法は、イーサネットがＡＴＭの上で動作する場合には、（ＡＤＳＬ２＋上のＩＰＴＶアプリケーションの場合と同様に）（ＡＴＭベースの）ＡＤＳＬ２＋に適用することができる。
−  ＮＡＫフレームを用いる機構は、具体的には、そのデータ・フレームのペイロードにわたるチェックサムの伝送を規定する及び／又は可能にする、どのようなトランスポート・プロトコルに対しても用いることができる。
−  肯定応答フレームを用いる機構は、どのようなトランスポート・プロトコルに対しても用いることができる。
【図１】
0005518724.tif 000002
【図２】
0005518724.tif 000003