JP2006287928A - 損失耐性のある伝送制御プロトコル - Google Patents

Abstract

【課題】データ・ブロック内のデータ・パケットを通信ネットワーク内でトランスポート・プロトコルにより送信または受信するための装置および方法を提供すること。
【解決手段】一実施例では、損失耐性のあるＴＣＰプロトコルが使用され、このプロトコルでは、最大セグメント・サイズ（ＭＳＳ）を輻輳ウィンドウの最小細分性に適合させることができる。また、プロアクティブな順方向誤り訂正（ＦＥＣ）パケットを、データ・ブロックのウィンドウに追加することができる。プロアクティブＦＥＣパケットの数を、例えば、推定消失率に基づいて決定することができる。加えて、リアクティブＦＥＣパケットを、データ・ブロックに追加することができる。また、受信器は、データ・ブロック内のデータ・パケットを受信し、受信されたデータ・パケットに応答して、選択的肯定応答（ＳＡＣＫ）を処理することができる。
【選択図】図１

Description

本発明は一般に通信ネットワークに関する。具体的には、本発明は、損失の多いリンク上の改善された通信パフォーマンスに備える。

本出願は、２００５年１２月１日に出願した米国特許出願第１１／２９０，８０７号、２００５年１２月１日に出願した米国特許出願第１１／２９０，８０９号、２００５年１２月１日に出願した米国特許出願第１１／２９０，８１０号の優先権を主張するものであり、２００５年３月３０日に出願した米国特許仮出願第６０／６６６，３９８号の権利を主張するものであり、それらのすべてが全体として参照により本明細書に組み込まれる。

無線チャネルを介したデータ通信は、ますます一般的になってきている。例えば、ＷｉＦｉは、ＩＥＥＥ ８０２．１１規格に基づいた接続のための無線通信のために使用される。２、３例を挙げると、ＷｉＭＡＸ、３Ｇ、メッシュ・ネットワーク、またはコミュニティ・ネットワークなど、多数の他の無線チャネルを使用することができる。無線チャネルは損失が多くなる場合があり、データはしばしば、様々な条件のいずれか１つにより送信中に失われる場合があるようになる。例えば、気象条件は、通信データの送信が損なわれる可能性があるようになる場合がある。同様に、同じチャネル上で送信中の他のデバイスからの干渉など、様々な原因からのデータ送信への干渉がある場合がある。これらの要素のいずれもが、データ・パケット送信における追加の損失、または、データ・パケット消失率の増加の一因となる場合がある。

エンドツーエンド・トランスポート・プロトコル（例えば、伝送制御プロトコル（ＴＣＰ））では、データ通信が、相互接続されたネットワークまたはデバイスに渡って提供される。このようなトランスポート・プロトコルでは、ＴＣＰがその一例であり、送信されるべきデータがデータのパケットに分けられる。データ・パケットは受信器に送信され、受信器でこれらのパケットが検証され、オリジナル・メッセージに再アセンブリされる。肯定応答（ＡＣＫ）が受信器から戻されて、データ・パケットが受信されたことが指示される。ＡＣＫが戻されない場合、データ・パケットが再送信されなければならない場合がある。加えて、送信器がＡＣＫを指定された期間内に受信しないとき、送信器のトランスポート・プロトコルはタイムアウトになる場合がある。これにより、トランスポート・プロトコルがＡＣＫの欠如をネットワーク内の輻輳として解釈するので、パケットの送信の速度が低減される結果となる。次いで、データ・パケットは、送信器のトランスポート・プロトコルによって再送信される場合がある。

ＴＣＰは、エンドツーエンド・トランスポート・プロトコルの一例であり、使用されている有力な伝送プロトコルになっている。しかし、ＴＣＰはまたパフォーマンス低下も受け、これは特に無線リンクにおいて、高いビット・エラー率、パケット消失、または断続的な接続性のような問題による。加えて、データ・パケット消失および損失は、ＴＣＰタイムアウト中のパフォーマンスにマイナスの影響を与える場合がある。このような問題は他のトランスポート・レイヤ・プロトコルにおいても見られる（例えば、メディア・ストリーミングもしくはＶｏＩＰ、またはいずれかの無線リンクレイヤ設計と統合された、ＵＤＰ）。輻輳はネットワーク内で、通信リンクまたはパス上のトラフィックの量がリンクまたはパスの容量を超えるとき、発生する場合がある。このような場合、過剰なデータは廃棄される場合があり、または、輻輳が緩和するまで、過剰なデータはバッファされる場合がある。しかし、輻輳が続く場合、この輻輳は、バッファ内のデータ・パケットを廃棄して、パケット交換網内のバッファをクリアすることによって、制御される。

ＴＣＰは通常、パケット損失の場合における輻輳制御のために使用される。しかし、データ・パケット損失が輻輳によるものでないとき（例えば、パケット消失によるパケット損失、または、損失の多い無線リンク内のパケットの損失）、ＴＣＰパフォーマンスは不必要な輻輳制御で損害を受ける場合がある。このような輻輳制御は、ＴＣＰに容量を過小評価させる場合があり、輻輳ウィンドウの縮小、および、使用可能な容量を十分に使用しない結果となる。ＴＣＰは、わずか１％の残留エラー率しか有していない、長いレイテンシ・チャネルにより、かなりのパフォーマンス低下を受ける。輻輳と非輻輳損失の間の混乱は、他のトランスポート・プロトコルについても存在する。

また、チャネル障害または干渉もまた、信号対雑音比（ＳＮＲ）の低下およびビット・エラーの結果となる場合があり、これらの結果は、パケット・エラーまたは消失の結果となる場合がある。

したがって、無線通信ネットワークにおけるパフォーマンス損失を低減し、損失が輻輳に関係していると誤解するために損失の多い通信チャネルにおけるトランスポート・レイヤ・プロトコルのパフォーマンスを高めるための、方法およびシステムの必要性が存在する。また、データ・セグメント・サイズを調整して、ビットまたはパケット消失へのネットワーク弾力性を増すための方法およびシステムの必要性もある。
米国特許出願第１１／２９０，８０７号 米国特許出願第１１／２９０，８０９号 米国特許出願第１１／２９０，８１０号 米国特許仮出願第６０／６６６，３９８号

以下で、本発明のいくつかの態様の基本的理解を提供するために、簡単な概要を提示する。この概要は、本発明の広範な概観ではない。これはまた本発明の重要または重大な要素を識別するようにも、本発明の範囲を線引きするようにも意図されない。以下の概要は単に、本発明のいくつかの概念を簡単な形態で、以下のより詳細な説明の前置きとして提示する。

本発明の一実施例では、データ・ウィンドウ内のデータ・パケットをトランスポート・プロトコルにより送信するための方法が提供される。一実施例では、ウィンドウ細分性を、最大セグメント・サイズ（ＭＳＳ）に基づいて決定または調整することができる。

さらにもう１つの実施例では、プロアクティブ順方向誤り訂正（ＦＥＣ）パケットの数を決定し、データ・ウィンドウに追加することができ、データ・ウィンドウ内のＦＥＣパケット対データ・パケットの比率を決定することができる。

もう１つの実施例では、プロアクティブＦＥＣパケットを決定されたウィンドウ細分性で収容するように、ＭＳＳを適合させることができる。

もう１つの実施例では、データ・ブロックを作成するための方法が提供される。データ・ブロックを作成する一実施例では、いくつかのデータ・パケットおよびＦＥＣパケットがデータ・ウィンドウ内に含まれる。もう１つの実施例では、ＦＥＣパケット対データ・パケットの比率が調整される。一実施例では、この比率は推定損失率に基づいて調整される。

もう１つの実施例では、トランスポート・プロトコルは、明示的輻輳通知（ＥＣＮ）が受信されるとき、輻輳ウィンドウを縮小することができる。例えば、ＥＣＮへの応答は、輻輳と消失損失の間の区別を提供することができる。もう１つの実施例では、ＥＣＮを受信することにおいて、バイト単位のウィンドウのサイズは、後続のブロック／ウィンドウ内の異なるデータ／ＦＥＣパラメータについて縮小される場合がある。

もう１つの実施例では、ウィンドウ細分性を最大パケット・サイズに基づいて調整するための方法が提供される。もう１つの実施例では、最小パケット・サイズが使用される。
もう１つの実施例では、ウィンドウ細分性を現在の最大セグメント・サイズ（ＭＳＳ）に基づいて調整するための方法が提供される。
もう１つの実施例では、リアクティブ・パケットの送信のための方法が提供される。
もう１つの実施例では、パケットを受信器でデコードする方法が提供される。
本発明のより完全な理解およびその利点は、添付の図面を考慮して以下の説明を参照することによって得ることができ、図面では、類似の参照番号は類似の機能を示す。

以下の様々な実施形態の説明では、添付の図面を参照し、図面は本明細書の一部を形成し、図面では、例示として、本発明を実施することができる様々な実施形態が示される。他の実施形態を利用することができ、構造的および機能的修正を、本発明の範囲および精神から逸脱することなく行うことができることを理解されたい。

図１は、本発明を実施することができる通信システムの一実施例を例示する。この実施例では、データを、無線チャネルを介して通信することができる。例えば、データを、電話１０１、ラップトップ・コンピュータ１０２、デスクトップ・コンピュータ１０３、または、データを送信することができる他のいずれかのデバイスなど、ユーザー・デバイスから送信することができる。一実施例では、家庭、会社またはホットスポットなど、顧客構内でのデバイスは、内部アクセス・ポイント１０５を介してデータを通信することができる。例示の実施例では、ラップトップ・コンピュータ１０２は、無線接続１０９を介して、顧客構内のアクセス・ポイント１０５と通信する。同様に、デスクトップ・コンピュータ１０３は、イーサネット（登録商標）接続１０８を介してアクセス・ポイント１０５と通信する。この実施例のアクセス・ポイント１０５はまた、加入者局１０４とも通信することができる。

図１が例示するように、加入者局１０４はデータを、基地局１０６との無線接続を介して送信または受信することができる。無線局は、いかなる様々な無線チャネルであってもよい。無線チャネルのいくつかの例には、２、３例を挙げると、ＷｉＦｉ、ＷｉＭＡＸ、３Ｇ、メッシュ・ネットワーク、コミュニティ無線ネットワーク、衛星ネットワーク、または、複数の無線リンクのトラバーサルを含むエンドツーエンド通信を含むデータ通信のための他の無線チャネルが含まれる。基地局１０６はさらに、例えば、ファイバー・ネットワークを通じて、インターネット１０７などのネットワークと通信することができる。

トランスポート・プロトコルを、無線チャネルを介したデータ通信のためのトランスポート・レイヤとして使用することができる。本発明はいかなるトランスポート・レイヤ・プロトコルにも適用可能にすることができ、これらのプロトコルには、例えば、トランスポート制御プロトコル（ＴＣＰ）、または、ＵＤＰ上のＲＴＰを介したマルチメディア・ストリーミングなど、いずれかの非ＴＣＰトランスポート・プロトコル、カスタム・トランスポート・プロトコル（例えば、ＮＡＳＡの衛星ネットワーク）、ＳＣＴＰなどのシグナリング・プロトコルなどが含まれる。本明細書はＴＣＰを、本発明におけるトランスポート・レイヤ・プロトコルの一実施例として参照する。しかし、いかなるトランスポート・プロトコルを使用することもできることを理解されたい。

ＴＣＰは通常、パケット・データの損失に応答して輻輳ウィンドウを縮小することによって、ネットワーク内の輻輳に対応する。例えば、輻輳が発生する場合、輻輳が緩和する時間に、データを後の送信のためにバッファ内に格納することができる。したがって、輻輳が存在するとき、ＴＣＰは、ネットワークのより低い容量を推定すること、および、それに応じて輻輳ウィンドウを縮小することによって、対応することができる。図２Ａ〜２Ｃは、通信ネットワーク内の輻輳中のＴＣＰパフォーマンスの一実施例を例示する。図２Ａは、データを受信器１３１に送信するトランスミッタ１３０を例示する。送信中のデータは、特定の帯域幅容量１３２でチャネルを介して送信することができる、データ・パケット１３３の形態である。データ・パケットはまた、データ・セグメントと呼ばれる場合もある。図２Ｂは、輻輳がネットワーク内にある一実施例におけるデータ通信を例示する。この実施例では、トランスミッタ１３０はデータ・パケット１３３を受信器１３１に送信する。しかし、輻輳の存在により、データ・パケットはネットワーク内で失われる。受信器１３１はデータ・パケット１３３を受信し、肯定応答（ＡＣＫ）または選択的ＡＣＫ（ＳＡＣＫ）をトランスミッタへ、フィードバック・ループ１３６を介して送信する。この実施例では、データ・パケットは輻輳のために失われている。データ・パケット損失に基づいて、ＴＣＰはネットワークのより低い容量を推定し、輻輳のために、推定されたより低い容量について収容するように、ウィンドウを調整する。調整されたウィンドウ１３４は、単位時間当たりにネットワークに送信されるトラフィックの量を、元のウィンドウ１３２と比較して縮小する（帯域幅要求を低減している）。よって、受信器１３１からの損失フィード・バックに基づいて、ネットワークの容量は縮小されていると仮定され、エンド・システムによるネットワーク上の帯域幅要求は相応して減少される。

図２Ｃは、トランスミッタ１３０がデータ・パケット１３３を受信器１３１に送信する、本発明の一実施例を例示する。パケット破損によるデータ・パケットの潜在的な損失にもかかわらず、データ・パケットは受信器１３１へ、ほぼ全容量で送信される。この実施例で例示するように、ネットワークの帯域幅容量１３５は、輻輳がない場合の帯域幅容量１３２に類似している。この実施例で使用されるトランスポート・レイヤは、本明細書で説明するように、損失耐性のある伝送制御プロトコル（ＬＴ−ＴＣＰ）である。

図３は、ＬＴ−ＴＣＰがいかなるの数の要素を含むこともできる、一実施例を例示する図である。この実施例では、ＬＴ−ＴＣＰは適応的最大セグメント・サイズ（ＭＳＳ）１２２を含み、ＭＳＳ１２２では、セグメント・サイズが制限され、調整され、またはそうでない場合は適合される場合がある。一実施例では、輻輳ウィンドウの細分化は、所定の最小または最大数を受けるデータ・パケットの数を有するように調整される。また、ＬＴ−ＴＣＰはさらに、プロアクティブ順方向誤り訂正（ＦＥＣ）１２０および／またはリアクティブＦＥＣ１２１を含むことができる。プロアクティブＦＥＣパケットの計算では、決定された数のＦＥＣパケットを、送信に先立ってプロアクティブに提供することができる。一実施例では、冗長性がデータに追加され、チャネル上のビット・エラーまたはパケット消失が許容されるようになる。リアクティブＦＥＣ１２１は、以下でさらに説明するように、ＴＣＰの元の送信または再送信を保護することができる。

図４Ａおよび４Ｂは、データ通信中の伝送損失の一実施例を例示する。図４Ａは、データ・パケットの送信を例示する全体図である。例示の実施例では、データ・パケットは送信器から受信器へ送信される。パケットは受信器で受信され、受信器は、状況を送信器またはトランスミッタへ送信することによって応答する。例えば、状況を、データ・パケットが受信器でうまく受信されたという肯定応答（ＡＣＫ）にすることができる。加えて、複数のデータ・パケットが選択的ＡＣＫ（ＳＡＣＫ）を介して肯定応答されて、いくつかのデータ・パケットは受信されるが、他のデータ・パケットは受信されていない可能性があることが、指示される場合がある。例示のための一実施例として、ＳＡＣＫが１１１００１１１０１の値を有する場合、パケット１、２、３、６、７、８および１０は受信されたが、パケット４、５および９は受信されなかった。例えば、ＳＡＣＫは、正しく受信されている連続バイトの開始および終了を指示することができる。データ・パケットが送信器から送信された後、送信器は、タイムアウト期間中に指定された長さの時間で待機することができる。この実施例で使用されるようなタイムアウトは、受信器からの、送信されたデータ・パケットが受信器で損なわれずに受信されたことを指示する肯定応答（例えば、ＳＡＣＫ）の受信を期待する間、送信器が待機する時間の量である。データ・パケットの肯定応答が、割り当てられたタイムアウト期間内に受信されない場合、送信されたデータ・パケットは失われている可能性がある。したがって、ＡＣＫを送信器で受信器からタイムアウト期間内に受信できなかったことによって、パケット損失を検出することができる。この場合、送信器またはトランスミッタは、欠落データ・パケットを再送信することができる。例えば、送信器は修復データ・パケットを受信器に送信することができる。

データ・パケット損失を検出するもう１つの方法は、重複肯定応答（ｄｕｐａｃｋ）の使用を通じた方法である。ｄｕｐａｃｋを使用して、それにおいてＡＣＫが以前に提供されている、以前に受信されたデータ・パケットを肯定応答することができる。例えば、第１のデータ・パケットが受信器で、送信器から受信される場合、受信器はＡＣＫを送信器に送信して、第１のデータ・パケットの受信を指示することができる。しかし、次に期待された第２のデータ・パケットが受信器で受信されない場合、受信器はＡＣＫを第２のデータ・パケットについて送信しない。送信器が第３のデータ・パケットを送信し、受信器が受信する場合、第２のデータ・パケットを受信していない受信器は、第１のデータ・パケット（すなわち、受信器がうまく受信した、最後のデータ・パケット）のためのＡＣＫを送信する。この場合、第１のデータ・パケットの受信を指示する第２のＡＣＫは重複ＡＣＫ（すなわち、ｄｕｐａｃｋ）であり、これは、ｄｕｐａｃｋが、以前に指示された第１のデータ・パケットの受信を再び肯定応答するからである。したがって、受信器は、ｄｕｐａｃｋの使用を通じて、後続のデータ・パケットが送信された後に特定のデータ・パケットが受信されなかった（すなわち、それが以前のＡＣＫの重複である）ことを指示することができる。加えて、ｄｕｐａｃｋはまた、順序が違った新しいパケットが受信器で受信されたことを指示することもできる。従来、ＴＣＰ送信器は、第３のｄｕｐａｃｋが受信器から受信されるときにのみ、パケットを再送信する。

図４Ｂは、低ウィンドウ細分性を有するウィンドウ内のデータ・パケットのデータの全損失の一実施例を例示する。この実施例では、ウィンドウ内の各セグメントまたはパケットが大きいので、最大セグメント・サイズ（ＭＳＳ）は大きい。これは低ウィンドウ細分性の結果となる。この実施例で例示するように、このウィンドウは５つのデータ・パケット、データ・パケット１〜５を含む。しかし、例えば、気象条件、または、エンドツーエンド・ネットワークの一部である場合のある無線リンク上の干渉など、様々な理由のために、データ・パケットは送信中に失われる場合がある。この実施例のウィンドウは低ウィンドウ細分性を有する（すなわち、ウィンドウ内のセグメントまたはパケットが高いＭＳＳを有する）ので、データ・パケット損失が発生する場合のある可能性はより高い。これは、最大セグメント・サイズが大きいほど、データ・パケットの全損失が発生する場合のある可能性がより高いからである。加えて、送信における障害（例えば、無線リンク上の気象条件）がリンク上に存在する時間の長さが長いほど、ウィンドウ内のすべてのデータ・パケットが失われる可能性はより高い。図４Ｂに例示した実施例では、ウィンドウ細分性は低く、ウィンドウ内のすべてのデータ・パケットは失われる。よって、受信器はＡＣＫを送信器に戻さず、したがって、タイムアウトが送信器で発生する。通常、ＴＣＰ送信器は、ウィンドウ・サイズを大幅に（例えば、１または２パケットまで）縮小することによってタイムアウトに対応し、次いで、パケットがうまく送信されるとき、ウィンドウ・バック・アップを徐々に構築する。

本発明の一実施例では、限定されないがＴＣＰなどのトランスポート・プロトコルは、明示的輻輳通知信号（ＥＣＮ）がＥＣＮ可能ネットワーク・パス内に存在する場合、データ・パケット損失を輻輳として扱い、輻輳がローカルで検出されるときにＥＣＮを生成することができるようにする。逆に、ＥＣＮ信号がＥＣＮ可能ネットワーク・パス内に存在しない場合、トランスポート・プロトコルはデータ・パケット損失を輻輳として扱わない。この実施例では、トランスポート・プロトコル（例えば、損失耐性のあるＴＣＰ（ＬＴ−ＴＣＰ））は、データ・パケットが他の理由（損失の多いシステムにおけるデータ損失またはパケット消失など）のために失われることとは対照的に、ネットワークが輻輳していることを指示する、ＥＣＮ信号などの指示が受信されるとき、その送信速度またはウィンドウを変更することによって、通信ネットワーク内の輻輳に対応することができる。この実施例では、ネットワーク内の輻輳を指示するために、明示的輻輳通知（ＥＣＮ）をネットワークによって、キューの状態に基づいて生成することができる。例えば、輻輳が存在することをネットワークに指示するためにＥＣＮ信号をヘッダに挿入することによって、ネットワーク内の輻輳中にネットワーク内のルーターによってデータ・パケットにマークを付けることができる。マーク付きのデータ・パケットを受信する受信器は、マーク付きのデータ・パケットに関する情報を戻すことができ、送信器はそれに応じて送信速度を下げることができる。この場合、ＬＴ−ＴＣＰなど、トランスポート・プロトコルは輻輳に対応することができ、これは、このプロトコルが、ＥＣＮマークを通じて輻輳の曖昧でない指示を受信するからである。

しかし、受信器で受信されたＥＣＮ指示がないとき、データ・パケットの損失は、輻輳によるものと見なされない。この実施例では、うまく受信された他のパケットにもまた、輻輳を指示するＥＣＮマークは付けられない。したがって、ＬＴ−ＴＣＰは輻輳に対応しないが、その代わりに、パケット損失を、ネットワーク内のエラーによるものとして扱い、損失耐性のある応答を提供する。損失耐性のある応答を本明細書でさらに説明する。

ネットワーク輻輳に応答する、本発明のトランスポート・レイヤ・プロトコルの損失耐性のある応答の一実施例では、最大セグメント・サイズ、および、ウィンドウ内のデータ・パケットまたはセグメントの数を調整して、ウィンドウ細分性を増すことができる。図５Ａおよび５Ｂは、タイムアウトおよびデータ・パケットの再送信におけるウィンドウ細分性の効果を例示する。図５Ａは、５つのデータ・パケット、すなわち、データ・パケット１（５０２）、データ・パケット２（５０３）、データ・パケット３（５０４）、データ・パケット４（５０５）およびデータ・パケット５（５０６）のウィンドウ（Ｗ）５０１の一実施例を例示する。ウィンドウ５０１内の５つの各データ・パケット（５０２〜５０６）は、ネットワークを介して送信器から受信器へ順次送信される。しかし、ネットワーク上の様々な条件（例えば、干渉または気象条件）により、データ・パケット１ ５０２およびデータ・パケット５（５０６）のみが受信器でうまく受信される。データ・パケット２〜４（５０３〜５０５）は受信されず、したがって失われる。よって、データ・パケット１（５０２）が受信器で受信されるとき、受信器はＡＣＫ（すなわち、１ＡＣＫ５０７）を送信器へ戻して、データ・パケット１（５０２）が受信器でうまく受信されたことを指示する。しかし、ＡＣＫはデータ・パケット２〜４（５０３〜５０５）の各々について戻されず、これは、データ・パケット２〜４（５０３〜５０５）が受信されないからである。データ・パケット５（５０６）が送信器から送信され、受信器で受信されるとき、受信器はデータ・パケット５（５０６）を受信するが、データ・パケット２〜４（５０３〜５０５）のいずれもが受信器でうまく受信されなかったので、受信器はデータ・パケット５（５０６）の受信に、ｄｕｐａｃｋ（５０８）を送信器に戻すことによって応答する。ｄｕｐａｃｋは送信器に、データ・パケットが失われたこと、および、最後にうまく受信されたデータ・パケットはデータ・パケット１（５０２）であったことを指示する。同様に、１ＡＣＫ ５０７に応答して送信されたパケット、すなわち、データ・パケット６（図示せず）は、第２のｄｕｐａｃｋを生成する。しかし、図５Ａの実施例では、ウィンドウ細分性は低く（すなわち、各データ・パケットまたはセグメントのサイズが大きい）、さらなるｄｕｐａｃｋは生成されず、これは、さらなる順序が違ったデータ・パケットがウィンドウ内で許可されないからである。この実施例では、受信された不十分な数のｄｕｐａｃｋがあり、受信器でのデータ・パケット５の受信に応答して、ただ１つのｄｕｐａｃｋが送信器で受信される。したがって、送信器は、パケット２におけるＡＣＫを待機中である間に、タイムアウトする。また、受信される他のｄｕｐａｃｋはない。したがって、データ・パケット１（５０２）の受信に応答した最初のＡＣＫが送信器で受信された後、過剰な量の時間が経過する。したがって、送信器はタイムアウトを受けて、データ・パケット２で開始するすべてのパケットを再送信する。タイムアウトは容量を浪費し、より低いパフォーマンスにつながる。

図５Ｂは、データ・パケットの送信における増大されたウィンドウ細分性の効果を例示する。この実施例では、図５Ａに例示した実施例と比較すると、最大セグメント・サイズ（ＭＳＳ）が調整され、ウィンドウ内のデータ・フラグメントまたはセグメントの各々のサイズが低減されるようになる（すなわち、ウィンドウ細分性またはウィンドウ内のデータ・パケットまたはセグメントの数が増やされる）。図５Ａおよび５Ｂに例示する実施例では、ウィンドウ内のデータ・バイトの総数はなお図５Ａおよび図５Ｂで同じである。この実施例では、ウィンドウ（Ｗ）５０１は８個のデータ・パケット、すなわち、データ・パケット１〜８（５０９〜５１５、５１９）を含む。８個のデータ・パケット１〜８（５０９〜５１５、５１９）は、ネットワークを介して送信器から受信器へ順次送信される。しかし、気象条件または干渉などの条件により、データ・パケット１（５０９）、２（５１０）、および６〜８（５１４、５１５および５１９）のみが受信器でうまく受信される。データ・パケット３〜５（５１１〜５１３）は送信中に失われる。ビット・エラーを引き起こすチャネル条件は、ＭＳＳがこのときはより小さいので、パケット損失の数に関してより小さい相乗効果を有する。

受信器はＡＣＫを、うまく受信された各データ・パケットまたはセグメントについて戻す。よって、図５Ｂに例示した実施例では、受信器はデータ・パケット１（５０９）を受信し、ＡＣＫ１（５１６）を戻すことによって応答する。受信器は次いでデータ・パケット２（５１０）を受信し、ＡＣＫ２（５１７）を戻すことによって応答する。しかし、データ・パケット３〜５（５１１〜５１３）がそれぞれ受信器で受信されないので、受信器はＡＣＫをデータ・パケット３〜５（５１１〜５１３）のいずれについても戻さない。データ・パケット６〜８（５１４、５１５、５１９）が次いで、送信器から受信器へ送信される。この実施例では、受信器はデータ・パケット６〜８（５１４、５１５、５１９）をうまく受信し、データ・パケット３〜５（５１１〜５１３）をうまく受信しないので、受信器は、パケット６、７および８（５１４、５１５、５１９）を受信するとき、パケット２について３つの重複肯定応答（ｄｕｐａｃｋ）（５１８、５２０、５２１）を戻すことによって応答する。しかし、データ・パケット３〜５（５１１〜５１３）のいずれもが受信器で受信されなかったので、受信器は、各パケット６、７および８（５１４、５１５、５１９）を受信すると、データ・パケットまたはセグメント２（５１０）に対応するｄｕｐａｃｋ５１８、５２０および５２１を戻すことによって、データ・パケット６〜８（５１４、５１５、５１９）の受信に応答する。ｄｕｐａｃｋ（５１８、５２０、５２１）は、データ・パケットが失われていること、および、受信器で最後に受信されたデータ・パケットまたはセグメントがこの実施例ではデータ・パケット２ ５１０であったことを指示する。追加の３つのｄｕｐａｃｋ（５１８、５２０、５２１）が送信器で受信される。これにより、送信器にパケット３を再送信させる。

また、図５Ｂの実施例では、ウィンドウ細分性が高い（すなわち、ウィンドウ内のデータ・セグメントまたはパケットの数が高く、ウィンドウ内のデータ・パケットの各々のサイズが小さい）。したがって、送信器は、データ・パケット３〜５（５１１〜５１３）のいずれについてもＡＣＫを受信しておらず、ネットワーク内のデータ・パケットまたはセグメント損失を指示する３つのｄｕｐａｃｋ５１８、５２０、５２１が受信されるとき、なおタイムアウトを受けていない。結果として、送信器は、失われたデータ・パケット３〜５（５１１〜５１３）を受信器に再送信することができる。したがって、図５Ｂに例示した実施例では、増大されたウィンドウ細分性はタイムアウトを防止し、データ・パケットまたはセグメントの成功する送信および再送信を可能にする。

もう１つの実施例では、順方向誤り訂正（ＦＥＣ）パケットを使用して、失われたデータ・パケットを再構築することができる。ＦＥＣパケットはプロアクティブであってもリアクティブであってもよい。プロアクティブＦＥＣパケットを作成して、データ・パケット消失に対する適切な保護を提供することができる。プロアクティブＦＥＣパケットの一実施例では、決定された数のプロアクティブＦＥＣパケットが追加され、ウィンドウ内でデータ・パケットと共に送信される。最大セグメント・サイズ（ＭＳＳ）は、最大および／または最小値を受ける場合があり、適切なウィンドウ細分性を提供するように、ならびに、データ・パケットと共に送信されたＦＥＣパケットを収容するように、本明細書で説明するように調整または適合させることもできる。したがって、この実施例では、データ・パケットまたはセグメントは、データ・パケットのウィンドウ内でいくつかのＦＥＣパケットと共に送信され、ＭＳＳもまた、ＦＥＣパケットを収容するように、および／または、所望のウィンドウ細分性を維持するように、調整または適合させることができる。

図６は、ＦＥＣデータ・パケットのリカバリの一実施例を例示する。この実施例では、Ｎのブロック・サイズを有するパケット６０１のウィンドウがデータ通信ネットワーク内で送信される。Ｎ個のパケット６０１は、Ｋ個（ただしＫ＜Ｎ）のデータ・パケット６０２およびＰ個のＦＥＣパケット６０３を含み、ただし、Ｋ個のデータ・パケット６０２およびＰ個のＦＥＣパケット６０３の和はＮ個のパケット６０１である。この実施例の通信ネットワークは、データ・パケットが送信中に失われる、損失の多いシステムである場合がある。この実施例では、合計Ｋ個のパケット６０７が受信される。受信されたパケット６０７のうちいくつかは元のデータ・パケット６０２であるのに対して、受信された他のパケットはＦＥＣパケット６０５のいずれであってもよい。この実施例の誤り訂正パケット（すなわち、ＦＥＣパケット）は、失われたパケットのＦＥＣ再構築を可能にする。したがって、この実施例では、どのデータ・パケットが受信されるかは問題ではない。ＦＥＣパケット（例えば、パケット６０３のいずれか１つ）はいかなるデータ・パケット（例えば、データ・パケット６０２のいかなるもの）をも保護または修復することができる。よって、欠落データ・パケット６０２（すなわち、データ・パケット６０８）を、受信されたＦＥＣパケット（すなわち、データ・パケット６０５）により再構築することができる。これは、Ｋ個のデータ・パケットがリカバリされる結果となる（すなわち、データ・パケット６０６）。

ＦＥＣパケットを生成する代替方法の多数の他の実施例がある。例えば、１つの追加の方法は、プロアクティブおよび／またはリアクティブＦＥＣのために使用されるＦＥＣパケットのインベントリを事前計算し、ゼロ・セグメントのセットを使用して、従来のブロックベースのＦＥＣエンコーダ内で使用された「ブロック」を完成させることである。リード・ソロモン（ＲＳ）コードまたは他のブロックベースのコードを使用することができる。もう１つの方法は、新しいＦＥＣパケットを必要に応じてオン・ザ・フライで、セグメントのために計算することである。ランダム化された低密度パリティ・チェック（ＬＤＰＣ）コードのクラスのいずれかを使用することができる。いずれの場合でも、順序は問題ではないので、ＦＥＣの「シーケンス・アグノスティック」プロパティを使用して、ウィンドウを再構築することができる。また、トランスポート・レイヤは、より多くのＦＥＣパケットがブロックを再構築することを待機するときでさえ、順序正しいデータ・セグメントをアプリケーションに配信することができる。

プロアクティブＦＥＣパケットに加えて、ＦＥＣパケットはまたリアクティブであってもよい。リアクティブＦＥＣパケットを、データ・パケット損失に応答して提供および送信することができる。例えば、リアクティブＦＥＣパケットを、受信器からのｄｕｐａｃｋに応答して使用することができる。図７は、プロアクティブおよびリアクティブＦＥＣパケットを含むデータ・パケットのブロックの一実施例を例示する。図７が例示するように、ウィンドウ（Ｗ）７０１は、プロアクティブＦＥＣ（Ｆ）パケット７０２およびデータ・パケット７０３を含むデータ・パケットを含み、これらのパケットを送信器から受信器へ送信することができる。しかし、データ・パケットが送信中に失われる場合、受信器は、すべての送信されたデータ・パケットを受信することができず、トランスミッタは対応するＡＣＫを受信器から受信しない。応答して、トランスミッタは対応する数のリアクティブＦＥＣパケット７０４を受信器へ送信することができる。よって、リアクティブＦＥＣデータ・パケットは、ＳＡＣＫに応答して送信される再送信を補完および保護することができる。リアクティブＦＥＣパケットは、失われる元の送信または再送信を修復する働きをすることができる。

図８は、送信におけるプロアクティブＦＥＣデータ・パケットの一実施例を例示する。この実施例では、データ・パケットのウィンドウ（Ｗ）は、４つのデータ・パケット８０１（データ・パケット１〜４）および２つのプロアクティブＦＥＣパケット８０２を含む。しかし、送信中に、データ・パケット３および４が失われる。これは、例えば、干渉または気象条件による場合がある。しかし、プロアクティブＦＥＣパケット８０２はうまく送信される。よって、２つの送信されたプロアクティブＦＥＣパケット８０２は、失われたデータ・パケットを再構築するために使用される。これは、ｄｕｐａｃｋの使用なしに、すべてのデータ・パケット（すなわち、この実施例ではデータ・パケット１〜４）の送信が成功する結果となる。

図９は、損失データ・パケットの再送信の一実施例を例示する。この実施例では、データ・パケットのウィンドウは６つのデータ・パケット（すなわち、データ・パケット１〜６）を含む。しかし、送信中に、いくつかのデータ・パケットが失われる場合がある。この実施例では、データ・パケット２および３が送信中に失われる。よって、受信器はデータ・パケット１を受信することができるが、データ・パケット２および３を受信することはできない。この実施例では、受信器は、データ・パケット１を受信することに応答して、ＡＣＫをトランスミッタに送信する。しかし、データ・パケット２および３は、この実施例では受信器で受信されない。したがって、受信器はＡＣＫを、データ・パケット２または３のいずれについても戻さない。データ・パケット４が受信器で受信されるとき、受信器はデータ・パケット２または３を受信していない。したがって、受信器は、データ・パケット４を受信することに応答して、ｄｕｐａｃｋを戻す。ｄｕｐａｃｋは、データ・パケット損失が発生していること、および、最後にうまく受信されたデータ・パケットはデータ・パケット１であったことを指示する。加えて、受信器はさらに、データ・パケット２の再送信が受信されるまで、続いてトランスミッタによって送信され、受信器によって受信された各データ・パケットに応答して、ｄｕｐａｃｋを送信することができる。図９に例示するように、データ・パケット４、５および６をそれぞれ受信することに応答して、３つのｄｕｐａｃｋがＡＣＫストリーム内でトランスミッタに戻される。トランスミッタはデータ・パケット２を受信器へ、ｄｕｐａｃｋに応答して再送信し、受信器は、対応するＡＣＫを送信することによって、再送信されたデータ・パケット２を肯定応答することができる。

しかし、多数の場合では、再送信されたデータ・パケット自体が送信中に失われる場合がある。この実施例では、再送信されたデータ・パケット２もまた受信器でうまく受信される前に失われる場合、受信器は、トランスポート・プロトコルがタイムアウトを受けるまで、ｄｕｐａｃｋをトランスミッタに送信し続けることができる。タイムアウト期間中に、パケットは送信器によって送信されず、データ・パケット２は、タイムアウト期間の最後で再送信されるようになる。タイムアウト期間はかなり長くなる可能性があり、したがって、かなりのスループットの損失の結果となる可能性がある。

図１０は、受信器へのデータの送信においてリアクティブＦＥＣパケットを使用することができる、一実施例を例示する。この実施例では、データ・パケットのウィンドウ（Ｗ）は６つのデータ・パケット（すなわち、データ・パケット１〜６）を含む。データ・パケットのウィンドウの送信中に、データ・パケット２および３が失われる（この実施例では）。受信器はデータ・パケット１をトランスミッタから受信し、データ・パケット１に対応するＡＣＫを戻すことによってデータ・パケットの受信を肯定応答する。しかし、データ・パケット２および３は、受信器でうまく受信されない。したがって、受信器は、データ・パケット２または３の肯定応答におけるＡＣＫを戻さない。その代わりに、受信器は、４、５および６など、うまく送信された（および受信された）データ・パケットについて、ｄｕｐａｃｋを戻す。

受信器からｄｕｐａｃｋを受信することに応答して、トランスミッタはリアクティブＦＥＣパケットを送信して、失われたデータ・パケット（すなわち、この実施例では、データ・パケット２および３）を再構築する。図１０に例示するように、２つのリアクティブＦＥＣパケットが送信器またはトランスミッタから受信器に送信される。受信器はリアクティブＦＥＣパケットを受信することができ、リアクティブＦＥＣパケットを受信器で使用して、データ・パケット２および３を再構築することができる。図１０に示すように、受信器はリアクティブＦＥＣパケットを、データ・パケット２および３の再構築のために使用して、すべての送信されたデータ・パケット（図１０ではデータ・パケット１〜４として例示）を得る。リアクティブＦＥＣパケットを使用して、失われたパケットのいずれかの損失を修復する能力は、効率的なリカバリを可能にする。

したがって、本発明の一実施例では、ＬＴ−ＴＣＰは、ネットワークが輻輳しているという指示が受信されるとき、送信速度を変更することによって、通信ネットワーク内の輻輳に対応することができる。一実施例では、ネットワーク輻輳はキューの状態に基づいて指示され、これにおいて明示的輻輳通知（ＥＣＮ）がネットワークによって生成され、データ・パケット（例えば、データ・パケットのヘッダ内）に挿入されて、データ・パケットにマークが付けられる。マーク付けを、例えば、ネットワーク内のルーターによって実施することができる。この場合、トランスポート・プロトコルは輻輳に対応することができ、これは、ＥＣＮマークを通じて輻輳の曖昧でない指示を受信するからである。逆に、失われたデータ・パケットがあるが、ＥＣＮ指示が受信器で受信されない場合、データ・パケットの損失は輻輳によるものではない。したがって、ＬＴ−ＴＣＰは輻輳に対応しないが、その代わりにパケット損失を、ネットワーク内のエラーによるものとして扱う。

トランスポート・プロトコルがネットワーク内で輻輳を識別する（例えば、ＥＣＮ指示が存在する）とき、トランスポート・プロトコルはさらにＭＳＳを調整または適合させることができる。一実施例では、トランスポート・プロトコルは、ＭＳＳを縮小してそれによりウィンドウ細分性を増すことによって、ＭＳＳを適合させる。例えば、ＭＳＳを、例えば０％と１００％の間のある係数（例えば、係数「ｆ」）によって低減することができる。もう１つの実施例では、係数「ｆ」は５０％であり、ＭＳＳが１／２に低減されるようになる。

トランスポート・プロトコルは、プロアクティブＦＥＣパケットを提供することによって、パケット損失／消失に対応することができる。ＦＥＣパケットは信頼性を増し、ウィンドウ内の損失の予想において提供することができる。ＦＥＣパケットはしたがって、パケット損失に対する「保険」を提供する。プロアクティブＦＥＣパケットの数を、消失率の適応的推定値に基づくようにすることができる。例えば、トランスポート・プロトコルは、データ・パケットのウィンドウ毎に消失率を推定することができる。ウィンドウ毎の推定されたデータ・パケット消失率に基づいて、トランスポート・プロトコルは、十分なウィンドウ細分性を維持しながら、プロアクティブＦＥＣデータ・パケットを可能にするようにＭＳＳを調整することができる。

消失率を様々な方法で推定することができる。一実施例では、パケット消失率の推定値を、指数加重移動平均（ＥＷＭＡ）に基づいて決定することができる。例えば、ＥＷＭＡパラメータを適応的に、より高い消失率の方へ偏らせることができる。例えば、以下の場合、
Ｎ＝新たに測定された消失率；
α＝（Ｎ）／（Ｎ＊Ｅ）；
β＝１−α＝（Ｅ）／（Ｎ＋Ｅ）
推定消失率を、この実施例では、以下のように平均プロセスを通じて決定することができる。
Ｅ＝推定消失率＝α＊Ｎ＋β＊Ｅ

もう１つの実施例では、αおよびβの値を定数（すなわち、偏りなし）にすることができる。例えば、もう１つの実施例では、αおよびβを０．５などの定数値に設定することができる。

データ・パケット消失率の推定値を、バイト単位のウィンドウ・サイズのためにデータ・パケットのウィンドウに追加されるべきプロアクティブＦＥＣデータ・パケットの数にマップするための、関数が提供される。この実施例では、消失率の推定値が得られ、次のブロック内のＦＥＣパケットの数を、この推定値に基づいて計算することができる。例えば、バイト単位のあるウィンドウ・サイズ（例えば、Ｗ）、および、現在の推定損失が与えられると、これらを使用して、ブロックのための保護の量を決定することができる。例示するための一実施例として、推定損失率が１０％である場合、パケットの１０％はプロアクティブＦＥＣパケットとなる。残りのパケットはデータ・パケットである。送信器は次いで、Ｗ＊推定消失率に等しいバイト単位のプロアクティブＦＥＣパケットを決定することができ、ただし、Ｗはバイト単位のウィンドウ・サイズである。また、データ・パケットの数を、Ｗ＊（１−推定消失率）に等しいように決定し、結果として、ブロック内でデータに対応するバイトと、プロアクティブＦＥＣに対応するバイトの間で分割することができる。それぞれデータおよびＦＥＣのバイトの数に基づいて、データ・パケットまたはセグメント、および、プロアクティブＦＥＣパケットまたはセグメントの数を、プロアクティブＦＥＣのバイトを現在のＭＳＳによって除算した商である、プロアクティブＦＥＣパケット（「Ｐ」）の数として決定することができる。データ・パケットまたはセグメントの数（「Ｋ」）を、データのバイトの数を現在のＭＳＳによって除算した商として決定することができる。Ｋ＋Ｐは、「Ｎ」個のパケットのブロック全体を構成する。

したがって、本発明の一実施例では、ウィンドウ・サイズが最初に、輻輳制御アルゴリズムまたはメカニズムに基づいて決定される。これは、例えば、ネットワーク容量のそのフェア・シェアのエンド・システムの推定値に基づくことができる。ＭＳＳを次いで、ウィンドウ・サイズおよび所望の（または最小）ウィンドウ細分性に基づいて決定することができる。加えて、プロアクティブＦＥＣパケットを、ウィンドウ内のデータ・パケットの数に追加することができる。ウィンドウ内のデータ・パケットに追加されるプロアクティブＦＥＣパケットの数を、例えば、推定消失率に基づいて決定することができる。加えて、ＭＳＳを適合させ、または調整して、プロアクティブＦＥＣパケットを収容するように、および、ウィンドウ・サイズが与えられると所望の最小ウィンドウ細分性を維持するようにすることができる。パケットのウィンドウを次いで、ネットワークを介して受信器に送信することができ、パケットのウィンドウは、いくつかのデータ・パケットおよびいくつかのプロアクティブＦＥＣパケットを含む。加えて、いくつかのリアクティブＦＥＣパケットをまた、現在観察されるような動的状態、および／または、送信器で受信された最後のＳＡＣＫにおいて観察されたパケット消失の数に基づいて、提供することもできる。例えば、受信器がブロックをデコードするとき、受信器は、どのパケットがうまく通り抜けたか、および、どのパケットがうまく通り抜けなかったかを知る。このブロックを完全にデコードすることができるようになる前に、いくつのパケット（データまたはＦＥＣ）が必要とされるかを決定する、変数を維持することができる。この数を、「ホール・サイズ」としてフィード・バックすることができる。リアクティブＦＥＣパケットの数は、ＡＣＫにおける「ホール・サイズ」によって決定される。例えば、ブロックのために送信されたプロアクティブＦＥＣパケット、ブロックのために送信されたリアクティブＦＥＣパケット、およびＳＡＣＫ再送信のカウントを使用して、生成されるリアクティブ・パケットの数を制限することができる。そうでない場合、送信器はある数のリアクティブ・パケットを送信し、これらが推定エラー率のためのホールをカバーするようにする。

図１１は、データ・ブロック内のデータおよび／またはＦＥＣパケットを伝送する方法の一実施例を例示する流れ図である。この実施例では、ＥＣＮ信号が検出される（工程１１０１）。ＥＣＮ信号は、輻輳がネットワーク内にあることを指示する。この実施例では、各ウィンドウ内のＭＳＳ適合およびＦＥＣプロビジョニングを、ＥＣＮとは無関係に達成することができる。例えば、ＥＣＮが、ＭＳＳ適合、プロアクティブＦＥＣプロビジョニング、および／または、ｄｕｐａｃｋへのリアクティブＦＥＣ応答中に受信されないとき、ウィンドウは増大することができる。ＥＣＮ信号はまた、ウィンドウを例えば１／２だけ低減させること、および／または、ＭＳＳを係数ｆによって低減させることもできる。したがって、トランスポート・プロトコルはＭＳＳおよびＦＥＣパケットを、ネットワーク内の輻輳の存在に基づいて処理する。工程１１０２で、損失推定値が決定される。また、工程１１０３で、ウィンドウ・サイズが得られる。工程１１０３で得られたウィンドウ・サイズ、および、工程１１０２で決定された損失推定値に基づいて、プロアクティブＦＥＣパケットの数および／または比率が決定される。プロアクティブＦＥＣパケットのこの数を、例えば、工程１１０２で得られた損失推定値に基づいて、データ・パケットの数に関して決定することができる。工程１１０２で得られた損失推定値をまた使用して、ウィンドウ細分化を決定することもできる。工程１１０３で得られたウィンドウ・サイズ、および、工程１１０２で得られた損失推定値をまた使用して、ウィンドウ細分化（すなわち、ウィンドウ内のパケットまたはセグメントの数）を決定することもできる（工程１１０４）。損失推定値、ウィンドウ・サイズ、およびウィンドウ細分化に基づいて、ＭＳＳを適合させることができる（工程１１０５）。データ・ウィンドウはネットワーク内で、決定されたウィンドウ細分性で、計算された比のプロアクティブＦＥＣパケット対データ・パケットを含んで送信される（工程１１０６）。

図１２に例示するような本発明のもう１つの実施例では、パケットのブロックが作成される。この実施例では、損失推定値は最初に「０」に設定され（工程１２０１）、ウィンドウは最初に最小ウィンドウ細分性（「Ｇ」）により設定される（工程１２０２）。損失推定値を続いて、ＡＣＫが受信されるとき、それに応じて調整することができる。Ｇは、ウィンドウ内のパケットまたはセグメントの最小数を示し、いかなる値に設定することもできる。一実施例では、Ｇは１０に設定される。ウィンドウ内の少なくともＧ個のパケットまたはセグメントの各々は、最小（「ｍｉｎｍｓｓ」）および最大（「ｍｓｓｍａｘ」）数の間にすることができるバイトの数を含むことができる。一実施例では、ｍｉｎｍｓｓは２００バイトであり、最大ｍｓｓは１５００バイトである。また、ブロック番号のためのパラメータ（「ｂｌｏｃｋｎｕｍｂｅｒ」）は最初に「１」に設定されて、最初のブロックが指示される（工程１２０３）。ｂｌｏｃｋｎｕｍｂｅｒパラメータは、後続のブロックについて増分される。

この実施例では、現在のブロックのブロック・サイズは、ウィンドウのサイズ（「Ｗ」）に設定される（工程１２０４）。よって、ウィンドウ・サイズ（「Ｗ」）は、ブロック・サイズを決定するためのガイドとして使用される。一実施例では、Ｗは２０００バイト以上である。ブロック内のパケットまたはセグメントの数は「Ｎ」（すなわち、ブロック内のパケットの総数）である。ブロック内のこれらのＮ個のパケットは、いくつかのデータ・パケット（「Ｋ」）およびいくつかのプロアクティブＦＥＣパケット（「Ｐ」）に分割される（工程１２０５）。プロアクティブＦＥＣパケットの数（「Ｐ」）を、ブロック内のデータ・パケットの数（「Ｋ」）に関連して推定損失に基づくようにすることができる。一実施例として、損失が１０％となるように推定される場合、プロアクティブＦＥＣパケットの数（「Ｐ」）は、パケットまたはセグメントの総数の約１０％に設定される。一実施例では、プロアクティブＦＥＣパケットのための初期推定値は５０％である。この実施例では、最初のブロックは、５０％の初期の保守的な推定損失率により、５個のプロアクティブＦＥＣパケットおよび５個のデータ・パケット、総数１０個のパケットを有することができる（この実施例では、損失推定値はプロアクティブＦＥＣパケットの％に等しい）。この実施例では、未使用のプロアクティブＦＥＣパケットを「オーバーヘッド」と見なすことができる。オーバーヘッドを、後続の損失推定値により低減することができる。

ブロック内のＮ個のパケット（Ｋ個のデータ・パケットおよびＰ個のプロアクティブＦＥＣパケットを含む）は、ネットワークを通じて送信される（工程１２０６）。ブロックの送信の後、次のブロックのためのＫおよびＰのための値が、損失推定値の現在の値およびウィンドウ・サイズＷに基づいて決定される（工程１２０７）。ＡＣＫが受信器から受信されるとき、送信器はそれに応じて損失推定値を更新する（工程１２０８）。このプロセスは、接続が終了されるまで、継続することができる。

ブロック・サイズを、現在のウィンドウ・サイズによって決定することができる。ブロックの送信が完了された後、次のブロックが作成される。１つの例示的実施例では、ウィンドウが（ＡＣＫを受信すると）スライドして、いかなるブロック内でもないパケットの送信を可能にする場合、これは新しいブロックの形成をトリガする。これは、現在のブロックが送信される場合でも、発生する可能性がある。一実施例では、パケット／セグメントが再送信される場合、再送信されたパケット／セグメントはなお、最初に割り当てられたものと同じブロック番号に割り当てられる。ブロックの状態をさらに状態テーブル内で維持することができる。したがって、状態テーブルを検索して、いかなる数のブロックの状態についての情報をも得ることができる。

送信器は、いかなる数のモードにおいても動作することができる。例えば、送信器はデータ・モードで動作することができ、このモードでは、データ・パケットがブロック内で送信される。また、送信器はプロアクティブＦＥＣ（ＰＦＥＣ）モードで動作することができ、このモードでは、Ｋ個のデータ・パケットが送信された後、送信器はプロアクティブＦＥＣ（ＰＦＥＣ）パケットを送信することができる。Ｋ＋Ｐ個のパケットが送信された後、次のブロックが作成される。タイムアウトまたは再送信が発生する場合、システムは現在のブロックの状態をフリーズする場合があるが、より古いパケット／セグメントが送信されて、正しいパケット／セグメントが送信されることが保証される。次いで、現在のブロックのためのカウントは増分されない。加えて、送信器は、第３のｄｕｐａｃｋが受信されるとき、高速リカバリを実施することができる。重複ＡＣＫが受信される場合、送信器はリアクティブＦＥＣパケットを送信することができる。この実施例では、ＡＣＫは、異なるブロック、すなわち、受信器によって最後に受信されたパケットに対応するブロック、および、ＡＣＫフィールド内のＡＣＫ番号に対応するブロック（より古いブロックである可能性がある）のための、ホール・サイズを含むことができる。ホールは、ブロックを完全に再構築するために受信器でなお必要とされたパケット／セグメントの数である。送信器は、送信器にフィード・バックされたホール・サイズ情報に応答して、リアクティブＦＥＣパケットを送信することができる。

ウィンドウ細分性を調整する一実施例では、パケットの一時サイズ（すなわち、「ｔｍｐｓｉｚｅ」）およびＭＳＳのための最大値（すなわち、「ｍａｘｍｓｓ」）に対応する、変数が確立される。図１３は、ウィンドウ細分性を得るか、または調整する一実施例を例示する流れ図である。この実施例では、輻輳ウィンドウがバイト単位で得られる（例えば、「ｗｎｄｉｎｂｙｔｅｓ」）（工程１２１０）。ウィンドウ内に収容されたセグメントまたはパケットの数（「ｔｍｐｓｅｇｓ」）は、バイト単位の輻輳ウィンドウ（「ｗｎｄｉｎｂｙｔｅｓ」）をパケットの一時サイズ（「ｔｍｐｓｉｚｅ」）によって除算した商として決定される（工程１２１１）。ｔｍｐｓｉｚｅは、最小ウィンドウ細分性（「Ｇ」）と比較される。ｔｍｐｓｉｚｅが最小ウィンドウ細分性以下である場合（工程１２１２のＹＥＳ分岐）、ｔｍｐｓｉｚｅが低減され（工程１２１４）、ｔｍｐｓｅｇｓは、更新されたｔｍｐｓｉｚｅにより再計算される（工程１２１５）。ｔｍｐｓｉｚｅがＧ以下になるとき（工程１２１２のＮＯ）、ｔｍｐｓｉｚｅおよびｔｍｐｓｅｇｓのための値が、それぞれセグメントのサイズおよびセグメントの数として出力される（工程１２１３）。

図１４は、ウィンドウ細分性を得るか、または調整するもう１つの実施例を例示する流れ図である。ウィンドウ細分性を調整するこの実施例では、ｔｍｐｓｉｚｅ変数は現在のＭＳＳ値に設定される（工程１２２０）。Ｔｍｐｓｅｇｓは、バイト単位の輻輳ウィンドウ（「ｗｎｄｉｎｂｙｔｅｓ」）をｔｍｐｓｉｚｅによって除算したものとして決定される（工程１２２１）。ｔｍｐｓｉｚｅの値は次いで、「ｓｔｅｐｖａｌｕｅ」だけ増分され（工程１２２２）、ｓｔｅｐｖａｌｕｅは、それによってＭＳＳ値を１つのパス内で増大させることができるバイトの数を示す。一実施例では、ｓｔｅｐｖａｌｕｅは約２００バイトに等しい。ｔｍｐｓｅｇｓの値が次いで、更新されたｔｍｐｓｉｚｅ値により再計算される（工程１２２３）。セグメントの数（ｔｍｐｓｅｇｓ）が最小ウィンドウ細分性（Ｇ）以下であり（工程１２２４の「ＹＥＳ」分岐）、パケット／セグメント・サイズ（ｔｍｐｓｉｚｅ）がＭＳＳのための最大値（「ｍａｘｍｓｓ」）以下である（工程１２２５の「ＹＥＳ」分岐）場合、ＭＳＳはｔｍｐｓｉｚｅに設定され、ウィンドウ内のパケットまたはセグメントの数はｔｍｐｓｅｇｓに設定される（工程１２２７）。そうでない場合（工程１２２４または工程１２２５のいずれかの「ＮＯ」分岐）、ＭＳＳおよびウィンドウ内のパケットまたはセグメントの数は更新されない（工程１２２６）。

ウィンドウ増大ビヘイビアのもう１つの実施例では、ＥＣＮが受信され（輻輳の存在を指示する）、パケット／セグメント・サイズがそれに応じて低減される。しかし、パケット・サイズがＭＳＳのための最小値（「ＭＩＮ＿ＭＳＳ」）未満となる場合、ウィンドウ・サイズ（セグメント単位）は、その代わりに最小ウィンドウ細分性を受けてカットされる。例えば、ウィンドウ内で最初のＥＣＮを受信すると、バイト単位のウィンドウ・サイズがカットされる場合がある。この実施例では、ＭＳＳ適合ポリシーはセグメントの単位におけるウィンドウ・サイズに影響を及ぼすが、バイトには影響を及ぼさない場合がある。ウィンドウ増大中に、バイト単位のウィンドウ・サイズを決定し、バイト単位の所定のしきい値と比較して、プロセスがｓｌｏｗｓｔａｒｔにあるかどうかを判断することができる。一実施例では、タイムアウトの後、ウィンドウは２００バイトの１０個のパケットにサイズ変更される。もう１つの実施例では、ＥＣＮが受信されるとき、バイト単位のウィンドウ・サイズが半分にカットされる場合があり、このカットは、パケット・サイズを半分だけ、またはセグメントの数を半分だけカットすることによって、実施される場合がある。

図１５は、リアクティブＦＥＣパケットの送信の一実施例を例示する流れ図である。この実施例では、送信器がＡＣＫを受信し、ＡＣＫを受信器からのｄｕｐａｃｋにすることができる（工程１２３０）。それにおいて対応するＡＣＫが受信された、現在のブロックのため、および最後のブロックのためのホール・サイズを決定することができる。これらの値を送信器における状態マシン内で更新することができる。ｄｕｐａｃｋが受信される場合（工程１２３０）、リアクティブ・パケットＦＥＣパケットを送信することができる（工程１２３４）。リアクティブＦＥＣパケットの送信では、ブロックから送信されたプロアクティブＦＥＣ、リアクティブＦＥＣ、および／またはＳＡＣＫパケットのカウントが得られる（工程１２３１）。ＦＥＣまたは再送信の期待数を計算することができる（工程１２３２）。現在のブロックから送信されるべきリアクティブ・パケットの数を、様々な要素から決定することができる（工程１２３７）。例えば、ブロックから送信されるべきリアクティブ・パケットの数を、受信器に到達するように期待されたプロアクティブＦＥＣパケットの数に基づくようにすることができる。この実施例では、受信器に到達するように期待されたプロアクティブ・パケットの数は、損失推定値を１から減算し、ブロックから送信されたプロアクティブＦＥＣパケットの数によって乗算して、「バックオフされた」ＰＦＥＣ値を得ることによって、推定することができる。バックオフされたＰＦＥＣ値をさらに使用して、現在のブロックから送信されるべきリアクティブＦＥＣパケットの数を決定することができる。

もう１つの実施例では、リアクティブＦＥＣパケットの数を、受信器に到達するように期待された再送信の数、すなわち、「バックオフされた」再送信の数に基づくようにすることができる。この実施例では、受信器に到達するように期待された再送信の数を、損失推定値を決定し、損失推定値を１から減算し、送信された再送信の数によって乗算することによって、推定することができる。よって、現在のブロックから送信するべきリアクティブＦＥＣパケットの数を、それに限定されないが、バックオフされたＰＦＥＣ、バックオフされた再送信、または、ブロック内のパケットの総数、ブロック内のデータ・パケットの数、ブロック内のプロアクティブＦＥＣパケットの数、もしくはブロックから送信されたリアクティブ・パケットの数など、他の変数のいずれか１つまたは組み合わせなど、様々な変数のいずれかの関数に基づいて推定することができる。

リアクティブＦＥＣの総数（「Ｒ」）が、ブロックから送信されるべきリアクティブＦＥＣパケットの数以下である場合（工程１２３３の「ＹＥＳ」分岐）、リアクティブ・パケットが現在のブロックから送信され（工程１２３４）、現在のブロックから送信されたリアクティブＦＥＣパケットの数が、損失率に鑑みて更新される（工程１２３５）。したがって、受信器に到達しているＦＥＣおよび再送信の期待数が計算される。

受信器から受信された各ＡＣＫは、現在の着信パケットに対応するブロック（「現在の」ブロック）、および、それに対して累積ＡＣＫが送信中であるブロックに対応するブロック（「最後の」ブロック）の、ホール・サイズについての情報を含むことができる。一実施例として、受信器はブロック１０からのパケット番号２１２を待機する。ブロック１１は完全にデコードされており、ブロック１２からのパケット番号２４３は次のパケットである。ブロック１０のためのホール・サイズは、例えば２であり、ブロック１２のためのホール・サイズは、例えば０である。したがって、この実施例では、受信器からのＡＣＫは、ブロック１０のための２のホール・サイズ、および、ブロック１２のための０のホール・サイズについての情報を含む。

送信器がＡＣＫを受信するとき、送信器はパケット内の「フェーズ３フラグ」をチェックすることができ、このフラグは、送信器からのすべてのリアクティブＦＥＣパケット上で設定される。フェーズ３フラグをヘッダ内で設定することができ、エコー・バックすることができ、これはさらなるリアクティブＦＥＣパケットをトリガすることができる。送信器がフェーズ３フラグを識別するとき、送信器はリアクティブＦＥＣパケットを送信する。これは、パケットの安定したストリームを保証する。ｄｕｐａｃｋが検出されるとき、リアクティブＦＥＣパケットを、送信器で受信されたＳＡＣＫベースの肯定応答内の指示に基づいて、必要に応じて「現在の」ブロックおよび「最後の」ブロックから送信することができる。このようにして送信されるリアクティブ・パケットの数は、様々な要素に基づいて決定される。例えば、送信器は最初に、受信器に到達しているように期待されたプロアクティブＦＥＣパケットの数を推定することができる。この値を０に設定することができ、または、損失推定値を使用して決定することができる（例えば、期待されたプロアクティブＦＥＣ＝（１−損失率）＊ｐｆｅｃ＿ｓｅｎｔ）。

送信器は、これまでに受信されたＳＡＣＫ再送信の数、これまでにブロックから送信されたリアクティブＦＥＣパケットの数、および、ブロックのためのホール・サイズを知ることができる。ホール・サイズを累積にして（すなわち、低減することができない）、増大または低減する再送信またはホール・サイズによって満たされたホールを計上することを回避することができる。ＳＡＣＫ再送信およびＰＦＥＣパケットが「バックオフ」された後、送信器は十分なリアクティブ・パケットを送信して、ホール・サイズを満たす。これはまた、損失推定値を計上することもできる。例えば、バックオフした後、５個のホールが満たされなければならず、損失推定値が５０％である場合、１０個のパケットが送信されるようになる。したがって、受信器は、それが受信している再送信および元の送信の数を知ることができる。もう１つの実施例では、受信器は、送信器から送信された再送信の数を知ることができる。

図１６は、本発明において受信器でデコードする方法の一実施例を例示する流れ図である。この実施例では、着信パケットが、すでにデコードされたブロックのためのものである場合（工程１２４１の「ＹＥＳ」分岐）、ブロックに属する着信パケット（工程１２４０）は廃棄され（工程１２４６）、プロセスは終了される（工程１２５５）。パケットが、今までのところはデコードされていないブロックに属する場合（工程１２４１の「ＮＯ」分岐）、ブロックが以前に見られていない場合（工程１２４２の「ＹＥＳ」分岐）、ブロックのための構造が初期化され、割り振られる（工程１２４８）。着信パケットを、パケットのタイプに基づいて処理することができる。パケットがＴＣＰタイプのパケットである場合（工程１２４３の「ＹＥＳ」分岐）、パケットはブロックのためのパケットのリストに挿入され、パケットのリストは順序通りに維持される（工程１２４９）。ＴＣＰパケットのためのＡＣＫが次いで送信／受信される（工程１２５０）。パケットがＦＥＣタイプのパケットである場合（工程１２４５の「ＹＥＳ」分岐）、パケットは、デコードのためのブロックからの他のパケットと共に保存され（工程１２４４）、ＡＣＫが、受信されたＦＥＣパケットのために送信される（工程１２４７）。ブロックからのＮ個のパケットのうちＫ個が得られている場合（工程１２５１の「ＹＥＳ」分岐）、ブロック全体がデコードされ（工程１２５２）、これはまた、いかなる欠落パケットをも、そのブロックのために受信されたＦＥＣパケットにより再構築することもできる。新しいデータ・パケットを、トランスポート・プロトコルに従ってさらに処理することができる（工程１２５３）。したがって、この実施例では、ＦＥＣパケットのためのＡＣＫは、最後のデータ・パケットのためのＡＣＫが送信されることを指示し、これは、この実施例ではＦＥＣパケットが連続番号を有していないからである。

以下の実施例では、損失推定値が決定される。この実施例では、最初のプロアクティブＦＥＣパケットが受信され、サンプル損失推定値が使用されて、平均損失推定値が更新される。各ブロックのための損失サンプルを決定する一実施例は、ブロック内のパケットの総数、および、受信器デコード・ブロック内に存在する元の送信の総数を得ることを含む（リストをウォークすること、および、ヘッダ内のｏｒｉｇ＿ｔｒａｎｓフラグをチェックすることによって、得ることができる）。失われたパケットの数は、パケットの総数から元のパケットの数を差し引いたものとして決定される。損失サンプルは、失われたパケットの数を、受信器デコード・ブロック内に存在する元の送信の総数によって除算したものとして、決定することができる。新しい損失推定値は、ＥＷＭＡ式を使用して決定され、ただし、αおよびβ＝０．５である。損失推定値を次いで、受信器から送信器へのＡＣＫにおいてエコー・バックすることができる。

以下の実施例では、ブロックのためのホール・サイズが決定される。この実施例では、パケットが受信され、対応するブロックのために到着しているべきであるパケットの数が決定される。一実施例として、このブロックが１００で開始し、ブロック内の最高パケットが１０５である場合、６個のパケットがブロック内で受信されているべきである。一実施例では、元の送信内のパケットの数をカウントすることができる。代替実施例では、元の送信および再送信を含む、ブロック内のパケットの数が決定される。この実施例では、ホール・サイズは、これらの２つの数の間の差に基づいて決定される。ホール・サイズは受信器デコード構造内に格納され、この構造がアクセスされ、最後および現在のブロックのためのホール・サイズをＡＣＫに追加することができる。この決定はまたＦＥＣパケットにも適用されるが、パケットの総数は同じである。例えば、送信器は１０のウィンドウで開始し、データおよびプロアクティブＦＥＣパケットのための基本セルフクロッキング・ビヘイビアに従うことができる。もう１つの実施例では、ホール・サイズは、元の、および再送信されたパケットの間の差ではなく、ブロックが１００で開始し、我々が元の送信である１００、１０２および１０３を有し、我々が１０９および１１０を受信しており、そのうちの１０９が再送信であり、１１０が元のものであった場合、我々は５パケットのホール・サイズを有する（１０４〜１０８）ようになる。一実施例では、再送信されたパケット１０９が無視され、ホール・サイズは６である。再送信されたパケットを無視することによって、我々はホール・サイズを増大させて、より多くのリアクティブ・パケットを送信する。

以下は、送信器プロアクティブＦＥＣアルゴリズムのもう１つの実施例であり、ただし、Ｇは最小ウィンドウ細分性であり、ＭＳＳ_ＭＡＸは、可能にされた最大ＭＳＳであり、ｎｅｗ_１は新しい測定された消失率であり、Ｐはブロック内のＰＦＥＣパケットの数であり、ＭＳＳ＿１は一時変数であり、ＭＳＳ_ＭＩＮは、可能にされた最小ＭＳＳであり、ＭＳＳは、現在の使用されるＭＳＳであり、Ｅは平均消失率推定値であり、Ｒはブロック内のＲＦＥＣパケットの数であり、Ｗはパケット内の輻輳ウィンドウである。
Ｐ＝ｆ（Ｅ）
ＭＳＳ＿１＝（Ｗ＊ＭＳＳ＊Ｅ）／Ｐ
ＩＦ（ＭＳＳ＿１＜ＭＳＳ_ＭＩＮ）
Ｗ＝（Ｗ＊ＭＳＳ）／ＭＳＳ_ＭＩＮ
ＭＳＳ＝ＭＳＳ_ＭＩＮ
ＩＦ（（Ｗ＊Ｅ）＜１）
Ｒ＝１
ＥＬＳＥ
Ｒ＝Ｗ＊Ｅ
ＥＬＳＥ
ＩＦ（ＭＳＳ＿１＞ＭＳＳ_ＭＡＸ）
ＩＦ（Ｗ／ＭＳＳ_ＭＡＸ＞Ｇ）
Ｗ＝（Ｗ＊ＭＳＳ）／ＭＳＳ_ＭＡＸ
ＭＳＳ＝ＭＳＳ_ＭＡＸ
Ｒ＝Ｗ＊Ｅ
ＥＬＳＥ
Ｗ＝Ｇ
ＭＳＳ＝Ｗ／Ｇ
Ｒ＝Ｗ＊Ｅ
ＥＬＳＥ
ＩＦ（Ｗ／ＭＳＳ＿１＞Ｇ）
Ｗ＝（Ｗ＊ＭＳＳ）／ＭＳＳ＿１
ＭＳＳ＝ＭＳＳ＿１
Ｒ＝Ｐ
ＥＬＳＥ
Ｗ＝Ｇ
ＭＳＳ＝Ｗ／Ｇ
Ｒ＝Ｗ＊Ｅ
以下は、受信器ＦＥＣデコーダ方法の一実施例である。
ＩＦ（データ・パケット）
ＩＦ（次の順序）
ＩＦ（以前に処理されていない保存されたパケットがブロック内にない）
ＳＡＣＫパケットを処理する
ＥＬＳＥ
ＩＦ（（現在のブロック内のパケット）ＡＮＤ（失われたパケット＜Ｐ））
パケットを保存する
ＥＬＳＥ
すべての保存されたＳＡＣＫパケットを処理する
ＥＬＳＥ
ＩＦ（（現在のブロック内のパケット）ＡＮＤ（失われたパケット＜Ｐ））
パケットを保存する
ＥＬＳＥ
すべての保存されたＳＡＣＫパケットを処理する
ＥＬＳＥ／／冗長パケット
ＩＦ（いずれかの保存されたパケット）
ＩＦ（（現在のブロック内のパケット）ＡＮＤ（失われたパケット＜Ｐ））
すべてのＳＡＣＫパケットをリカバリおよび処理する
ＥＬＳＥ
ＩＦ（（ブロック内の最後のパケット）ＯＲ（新しいブロック内のパケット））
すべての保存されたＳＡＣＫパケットを処理する
ＥＬＳＥ
パケットを保存する

本発明は、本明細書で開示されたいかなる新規な特徴または特徴の組み合わせを明示的に、または、そのいかなる一般化をも含む。本発明を、本発明を実行する現在好ましい態様を含む特定の実施例に関して説明したが、上述のシステムおよび技術の多数の変形形態および入れ替えがあることは、当業者には理解されよう。したがって、本発明の精神および範囲は、付属の特許請求の範囲に示すように幅広く解釈されるべきである。

本発明の様々な態様を実施することができるネットワークの一実施例を例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、適応的チャネル容量を有するデータ・ブロック内で送信されたデータ・パケットの一実施例を例示するブロック図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、適応的チャネル容量を有するデータ・ブロック内で送信されたデータ・パケットの一実施例を例示するブロック図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、適応的チャネル容量を有するデータ・ブロック内で送信されたデータ・パケットの一実施例を例示するブロック図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、ＬＴ−ＴＣＰ（損失耐性のあるＴＣＰ）のコンポーネントを例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、データ・パケットの送信およびタイムアウトの一実施例を例示する図である。 全伝送損失の一実施例を例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、タイムアウトおよびデータ・パケットの再送信におけるウィンドウ細分性の効果の一実施例を例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、タイムアウトおよびデータ・パケットの再送信におけるウィンドウ細分性の効果の一実施例を例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、ＦＥＣデータ・パケットのリカバリの一実施例を例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、プロアクティブおよびリアクティブＦＥＣを含むデータ・パケットのブロックの一実施例を例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、送信におけるプロアクティブＦＥＣデータ・パケットの一実施例の図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、損失データ・パケットの再送信の一実施例の図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、リアクティブＦＥＣデータ・パケットを使用して、データを受信器に再送信することができる一実施例を例示する図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、データ・ブロック内のデータおよび／またはＦＥＣパケットを送信する方法の一実施例を例示する流れ図である。 データ・ブロック内のデータ及び／又はＦＥＣパケットを送信する方法の他の実施例を示す流れ図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、ウィンドウ細分性を得るか、または調整する一実施例を例示する流れ図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、ウィンドウ細分性を得るか、または調整するもう１つの実施例を例示する流れ図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、リアクティブＦＥＣパケットの送信の一実施例を例示する流れ図である。 本発明の１つまたは複数の例示的実施形態を実施することができる、受信器でデコードする方法の一実施例を例示する流れ図である。

Claims (33)

1. パケットを含むデータ・ウィンドウを通信ネットワーク内で送信するための方法であって、前記データ・ウィンドウはウィンドウ・サイズを有し、
   パケット消失率を推定する工程と、
   前記データ・ウィンドウのためのプロアクティブＦＥＣパケットの数を、前記推定されたパケット消失率に基づいて決定する工程と、
   前記データ・ウィンドウ内の前記パケットのためのパケット・サイズを、前記データ・ウィンドウの前記ウィンドウ・サイズ、および、前記決定されたプロアクティブＦＥＣパケットの数に基づいて決定する工程と、
   前記データ・ウィンドウを送信する工程であって、前記送信されたデータ・ウィンドウ内の前記パケットは、前記決定されたパケット・サイズに対応するサイズを有し、前記決定されたプロアクティブＦＥＣパケットの数を含む工程とを備える方法。
2. パケット・サイズを決定する前記工程は、前記ウィンドウの細分性を決定する工程を備える、請求項１に記載の方法。
3. パケット・サイズを決定する前記工程は、前記データ・パケットのための前記パケット・サイズを係数ｆによって低減する工程を備え、前記方法は、明示的輻輳通知（ＥＣＮ）を受信する工程をさらに備え、前記データ・パケットのための前記パケット・サイズを低減する工程は前記ＥＣＮに応答する、請求項１に記載の方法。
4. 前記送信されたデータ・ウィンドウはＮ個のデータ・パケットを含み、前記Ｎは、データ・パケットの数、および、前記決定されたプロアクティブＦＥＣパケットの数の和に等しく、Ｎは、前記決定されたパケット・サイズに基づいて決定される、請求項１に記載の方法。
5. プロアクティブＦＥＣパケットの数を決定する前記工程は、
   前記データ・ウィンドウ内のプロアクティブＦＥＣバイトの量を、前記ウィンドウ・サイズおよび前記推定されたパケット消失率の積として得る工程と、
   前記プロアクティブＦＥＣパケットの数を、前記プロアクティブＦＥＣバイトの量を現在のパケット・サイズによって除算した商として決定する工程とを備える、請求項１に記載の方法。
6. 前記データ・ウィンドウ内のデータ・バイトの量を、前記ウィンドウ・サイズ、および、１と前記推定されたパケット消失率の間の差の積として得る工程と、
   データ・パケットの数を、前記データ・ウィンドウ内の前記データ・バイトの量を前記現在のパケット・サイズによって除算した商として決定する工程とによって、データ・パケットの数を決定する工程をさらに備える、請求項５に記載の方法。
7. パケット・サイズを決定する前記工程は、前記パケット・サイズを、第１のサイズから、前記第１のサイズより小さい第２のサイズへ適合させる工程を備え、パケット・サイズを決定する前記工程は、前記データ・ウィンドウのウィンドウ細分性を増す工程を含む、請求項１に記載の方法。
8. 重複肯定応答を受信する工程と、
   前記重複肯定応答に応答して、リアクティブＦＥＣパケットを送信する工程とをさらに備える、請求項１に記載の方法。
9. 送信するべきリアクティブＦＥＣパケットの数を、受信されるように期待されたパケットの数に基づいて決定する工程をさらに備える、請求項８に記載の方法。
10. 送信するべきリアクティブＦＥＣパケットの数を、受信されるように期待された前記プロアクティブＦＥＣパケットの数、および、前記推定されたパケット消失率に基づいて、決定する工程をさらに備える、請求項８に記載の方法。
11. 前記データ・ウィンドウのウィンドウ細分性を、前記データ・ウィンドウ内の前記パケットの前記サイズの調整、および、前記データ・ウィンドウ内の前記プロアクティブＦＥＣパケットの数のうち１つに基づいて、調整する工程をさらに備える、請求項１に記載の方法。
12. データ・ブロックに対応するリアクティブ・パケットを送信するためのトランシーバであって、
    重複肯定応答信号を受信するための受信器と、
    前記データ内のパケットに対応する少なくとも１つの値を得て、受信器で受信されているべきパケットの期待数を決定し、リアクティブ・パケット・パラメータを、前記少なくとも１つの値および前記パケットの期待数のうち１つに基づいて設定するためのプロトコルと、
    プロアクティブＦＥＣパケットの数が前記リアクティブ・パケット・パラメータ以下である場合、リアクティブＦＥＣパケットを送信するための送信器とを備えるトランシーバ。
13. 前記少なくとも１つの値は少なくとも、前記データ・ブロックから送信されたプロアクティブＦＥＣパケットの数に対応する第１の値、前記データ・ブロックに対応する送信されたリアクティブＦＥＣパケットの数に対応する第２の値、または、前記データ・ブロックに対応する送信されたＳＡＣＫパケットの数に対応する第３の値を備える、請求項１２に記載のトランシーバ。
14. 前記プロトコルはさらに、受信されるように期待されたプロアクティブＦＥＣパケットの数を決定し、前記プロアクティブＦＥＣパケットの数を決定することは、損失推定値を決定すること、および、前記データ・ブロック内の前記プロアクティブＦＥＣパケットの数と、前記データ・ブロック内の前記プロアクティブＦＥＣパケットの数および前記損失推定値の積の間の、差を得ることを備える、請求項１３に記載のトランシーバ。
15. 前記プロトコルはさらに、受信されるように期待された再送信の数を決定し、前記再送信の数を決定することは、損失推定値を決定すること、および、送信された再送信の数と、前記送信された再送信の数および前記損失推定値の積の間の、差を得ることを備える、請求項１３に記載のトランシーバ。
16. 前記プロトコルはさらに、前記送信されたリアクティブ・パケットの数を、損失推定値に基づいて増し、前記送信されたリアクティブ・パケットの数を増すことは、送信されるべきリアクティブ・パケットの数を、前記送信されたリアクティブ・パケットの数と、前記送信されたリアクティブ・パケットの数および前記損失推定値の積の間の、差に等しい量だけ増すことを備える、請求項１３に記載のトランシーバ。
17. 少なくとも１つのパケットを備えるデータ・ブロックを受信する方法であって、
    パケットを受信する工程と、
    着信パケットに対応するデータ・ブロックを決定する工程と、
    前記パケットに対応する前記データ・ブロックがすでにデコードされている場合、前記パケットを廃棄し、そうでない場合、前記データ・ブロックのためのデコード構造を初期化および割り振る工程と、
    前記ブロックのＮ個のパケットのうちＫ個のパケットが受信されているとき、前記データ・ブロックをデコードする工程であって、Ｎは、前記データ・ブロック内のパケットの数であり、Ｋは、前記データ・ブロック内のデータ・パケットの数である工程とを備える方法。
18. 前記パケットを、前記データ・ブロックに関連付けられた順次パケットのリストに挿入する工程をさらに備える、請求項１７に記載の方法。
19. いくつかのパケットのデータ・ウィンドウを含むデータ・ブロックを送信する方法であって、
    損失推定値を設定する工程と、
    前記データ・ウィンドウ内のパケットの数を、最小ウィンドウ細分性に対応するパケットの第１の数に設定する工程であって、各パケットは第１の数のバイトを含む工程と、
    前記データ・ブロックのブロック・サイズをウィンドウ・サイズに設定する工程であって、前記ブロック内のパケットの数はＮである工程と、
    前記ブロック内の前記Ｎ個のパケットを、データ・パケットの第１のグループおよびプロアクティブＦＥＣパケットの第２のグループへ、前記損失推定値に基づいて分割する工程と、
    前記データ・ブロックを送信する工程であって、前記データ・ブロックは、前記データ・パケットの第１のグループおよび前記プロアクティブＦＥＣパケットの第２のグループを含む工程とを備える方法。
20. 前記損失推定値を更新する工程、および、データ・パケットの数およびプロアクティブＦＥＣパケットの数を、前記更新された損失推定値およびウィンドウ・サイズに基づいて再計算する工程をさらに備える、請求項１９に記載の方法。
21. 前記再計算されたデータ・パケットの数および前記再計算されたプロアクティブＦＥＣパケットの数を備える、第２のデータ・ブロックを送信する工程をさらに備える、請求項２０に記載の方法。
22. 前記損失推定値を決定する工程は、
    損失推定パラメータを備える肯定応答信号を受信する工程と、
    前記損失推定値を、前記損失推定パラメータに基づいて更新する工程とを備える、請求項２０に記載の方法。
23. 前記ブロック・サイズを設定する前記工程は、
    前記データ・ウィンドウのサイズを得る工程と、
    前記データ・ウィンドウ内に収容されることが可能なパケットの数を、前記データ・ウィンドウの前記サイズに基づいて決定する工程と、
    前記データ・ウィンドウ内に収容されることが可能なパケットの数を更新する工程と、
    Ｎを、前記更新されたパケットの数に対応するパケットの数に等しく設定する工程とを備える、請求項１９に記載の方法。
24. 前記更新する工程を、第１の値が前記最小ウィンドウ細分性より大きくなるまで繰り返す工程をさらに備える、請求項２３に記載の方法。
25. パケットの数を決定する前記工程は、
    パケットの最大サイズに対応する第１の値を決定する工程と、
    前記データ・ウィンドウの前記サイズを前記第１の値によって除算する工程とを備え、
    パケットの数を更新する前記工程は、
    前記第１の値の値を所定の量だけ低減する工程と、
    前記第１の値が最小ウィンドウ細分性以下である場合、前記データ・ウィンドウの前記サイズを、前記低減された第１の値によって除算する工程とを備え、
    前記更新する工程は、前記第１の値が前記最小ウィンドウ細分性より大きくなるまで繰り返される、請求項２３に記載の方法。
26. 前記データ・ウィンドウ内に収容されることが可能なパケットの数を決定する前記工程は、
    パケットの最大サイズに対応する第１の値を決定する工程と、
    前記データ・ウィンドウの前記サイズを前記第１の値によって除算する工程とを備える、請求項２３に記載の方法。
27. パケットの数を更新する前記工程は、
    パケットの最大サイズに対応する第１の値の値を所定の量だけ低減する工程と、
    前記データ・ウィンドウの前記サイズを、前記低減された第１の値によって除算する工程とを備える、請求項２３に記載の方法。
28. 低減および除算する前記工程は、前記第１の値が最小ウィンドウ細分性以下である場合にのみ実行される、請求項２７に記載の方法。
29. 前記ブロック・サイズを設定する前記工程は、
    前記データ・ウィンドウの最大セグメント・サイズ（ＭＳＳ）を得る工程と、
    前記データ・ウィンドウ内に収容されることが可能なパケットの数を、前記ＭＳＳに基づいて決定する工程と、
    前記データ・ウィンドウ内に収容されることが可能なパケットの数を更新する工程と、
    前記更新されたパケットの数に対応するパケットの数を含むデータ・ウィンドウを提供する工程とを備える、請求項１９に記載の方法。
30. 前記データ・ウィンドウ内に収容されることが可能なパケットの数を決定する前記工程は、
    前記ＭＳＳに対応する第１の値を決定する工程と、
    前記データ・ウィンドウのサイズを前記第１の値によって除算する工程とを備える、請求項２９に記載の方法。
31. 前記データ・ウィンドウ内に収容されることが可能なパケットの数を更新する前記工程は、
    前記ＭＳＳに対応する第１の値を所定の量だけ増分する工程と、
    前記データ・ウィンドウのサイズを前記増分された第１の値によって除算する工程とを備える、請求項２９に記載の方法。
32. パケットの数を更新する前記工程は、
    前記データ・ウィンドウ内に収容されることが可能なパケットの前記更新された数が前記最小ウィンドウ細分性未満であり、前記増分された第１の値が、前記データ・ウィンドウ内のパケットの最大サイズ以下である場合、前記ＭＳＳを前記増分された第１の値に設定する工程をさらに備える、請求項３１に記載の方法。
33. 前記データ・ウィンドウ内に収容されることが可能なパケットの数を決定する前記工程は、
    前記ＭＳＳに対応する第１の値を決定する工程と、
    前記データ・ウィンドウのサイズを前記第１の値によって除算する工程とを備え、
    前記データ・ウィンドウ内に収容されることが可能なパケットの数を更新する前記工程は、
    前記ＭＳＳに対応する第１の値を所定の量だけ増分する工程と、
    前記データ・ウィンドウのサイズを前記増分された第１の値によって除算する工程と、
    前記データ・ウィンドウ内に収容されることが可能なパケットの前記更新された数が最小ウィンドウ細分性未満であり、前記増分された第１の値が、前記データ・ウィンドウ内のパケットの最大サイズ以下である場合、前記ＭＳＳを前記増分された第１の値に設定する工程とを備える、請求項２９に記載の方法。
    

Images