(57)【要約】  予め定められた通信プロトコルの送信ピアから受信ピアへのデータ量の流れを制御する方法が記載される。この方法は、データ量を、順番に並べられた複数のデータセグメントに分割するステップを有する。セグメントは順番に従って受信ピアへ送信される。受信ピアは、データセグメントの正しい受信を受信確認するとともに、データセグメントの適切な順番で最後に正しく受信されたデータセグメントを特定する。送信ピアは閾値数の重複受信確認を受信したら、再送を実行するように構成される。再送を開始させる閾値は、受信ウィンドウのサイズに基づいて決定される適応パラメータである。ここで、受信ウィンドウサイズは、受信ピアにおけるバッファ空間に格納可能なデータセグメントの数を表す。【特許請求の範囲】
【請求項１】
送信ピアから受信ピアへのデータセグメント列の流れを制御する方法であって、
データセグメントを前記送信ピアから前記受信ピアへ、前記列の順番で送信するステップと、
前記列の適切な順番でデータセグメントが正しく受信されたことを示す受信確認メッセージを、前記受信ピアから受信するステップと、
データセグメントが受信されたが、前記列の前記適切な順番でない場合に、データセグメントの前記列の順番で最後に正しく受信されたデータセグメントに関連した重複受信確認メッセージを、前記受信ピアから前記送信ピアで受信するステップと、
重複受信確認メッセージの数が、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数に対応する受信ウィンドウサイズに基づいて決定された重複受信確認閾値に達した場合、送信されたが受信確認されないデータセグメントが喪失したと判定するステップと、
喪失したと判定されたデータセグメントを再送するステップとを有することを特徴とする方法。
【請求項２】
前記受信ウィンドウサイズによって前記喪失したと判定されるデータセグメントの正しい受信を示す前記受信確認メッセージが、前記喪失したと判定されるデータセグメントの順番より後の順番のデータセグメントの送信より前に前記送信ピアで受信されるように選択された前記データセグメント列における時点より前に、前記喪失したと判定されるデータセグメントが再送されるように前記重複受信確認閾値が設定されることを特徴とする請求項１記載の方法。
【請求項３】
前記重複受信確認閾値は、前記受信ウィンドウサイズと、受信確認がなされていない送信済データセグメントの数を表すフライトサイズとの差によって形成される利用可能ウィンドウサイズに基づいて決定されることを特徴とする請求項１又は請求項２記載の方法。
【請求項４】
前記重複受信確認閾値は、前記利用可能ウィンドウサイズと前記フライトサイズとの差に基づいて決定されることを特徴とする請求項１乃至請求項３のいずれか１項に記載の方法。
【請求項５】
前記重複受信確認閾値は、最初の重複メッセージの受信前のある一時点において、
値１及び、（受信ウィンドウサイズ−（ｋ×フライトサイズ））の計算によって得られる値（ｋは浮動小数点数）、
の値のうち、大きい方の値として決定されることを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項６】
ｋ＝２であることを特徴とする請求項５記載の方法。
【請求項７】
前記重複受信確認閾値は、
（２×フライトサイズ）−受信ウィンドウサイズ＋１＜Ｎ＜３
の条件を満たす調整パラメータを形成するＮを用いて、
受信ウィンドウサイズ−（２×フライトサイズ）＋Ｎ
として決定されることを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項８】
前記重複受信確認閾値は、前記受信ウィンドウサイズの変化の判別時に更新されることを特徴とする請求項１乃至請求項７のいずれか１項に記載の方法。
【請求項９】
前記重複受信確認閾値は、前記データセグメントの１つに対して少なくとも最初に前記重複受信確認メッセージが受信されると更新されることを特徴とする請求項１乃至請求項７のいずれか１項に記載の方法。
【請求項１０】
Ｎ＝５であることを特徴とする請求項７又は請求項９記載の方法。
【請求項１１】
前記重複受信確認閾値は、前記受信確認メッセージが受信されるごとに更新されることを特徴とする請求項１乃至請求項７のいずれか１項に記載の方法。
【請求項１２】
前記喪失したと判定されるデータセグメントは、前記送信ピアが過去に送信されていないデータセグメントの送信をブロックされている場合に再送されることを特徴とする請求項１乃至請求項１１のいずれか１項に記載の方法。
【請求項１３】
以下の条件の１つが満たされている場合に前記送信ピアがブロックされていると見なすことを特徴とする請求項１２記載の方法。
過去に送信されていないデータセグメントの数が前記受信ウィンドウサイズを超えている場合、
過去に送信されていないデータセグメントが前記送信ウィンドウサイズを超えている場合、又は前記データセグメントのソースを形成するアプリケーションが送信用のデータセグメントを供給しない場合。
【請求項１４】
コンピュータで実行された際に、請求項１乃至請求項１３のいずれか１項に記載された方法を実行するように構成されたコンピュータプログラム。
【請求項１５】
請求項１４記載のコンピュータプログラムを格納したコンピュータ読み取り可能な記憶装置。
【請求項１６】
送信ピアから受信ピアへの一連のデータセグメントの流れを制御する通信装置であって、
データセグメントを前記送信ピアから前記受信ピアへ、前記列の順番で送信する手段と、
前記列の適切な順番でデータセグメントが正しく受信されたことを示す受信確認メッセージを、前記受信ピアから受信する手段と、
データセグメントが受信されたが、前記列の前記適切な順番でない場合に、データセグメントの前記列の順番で最後に正しく受信されたデータセグメントに関連した重複受信確認メッセージを、前記受信ピアから受信する手段と、
重複受信確認メッセージの数が、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数に対応する受信ウィンドウサイズに基づいて決定された重複受信確認メッセージ閾値に達した場合、送信されたが受信確認されないデータセグメントが喪失したと判定する手段と、
前記喪失したと判定されたデータセグメントを再送する手段とを有することを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ある特定の通信プロトコルの送信ピアから受信ピアへのデータ量の流れを制御する方法に関する。
【背景技術】
【０００２】
通信分野において、送信すべきデータ量を、順番に並べられた複数のデータセグメントに分割するデータ伝送技術が知られている。そして、これらのデータセグメントは並べられた順番に送信される。
【０００３】
この手順は、そのようなデータセグメントの取り扱いについてのルールを含む予め定められたプロトコルに従った通信の、所謂送信ピアにおいて行われる。この予め定められたプロトコルに関する受信エンティティは、受信ピアと呼ばれる。プロトコル、プロトコル階層、階層化、及びプロトコルピアの概念は、例えば、W. Richard Stevensによる、「TCP/IP Illustrated Volume 1, The Protocols」、1994年、Addison Wesley社に示されるように、本技術分野において周知である。ＴＣＰ／ＩＰプロトコルスイートからの周知の伝送制御プロトコル（ＴＣＰ）は、送信すべきデータを一連のセグメントにするプロトコルの一例である。
【０００４】
通常、送信のために、個々のセグメントは、特定のプロトコルによって規定された構造を有するデータユニットに配置される。これらのデータユニットはパケット、フレーム、プロトコルデータユニット、セル、等、プロトコルによって様々な名前を有しうる。本明細書において「データユニット」という用語は、このような規定されたデータ構造の全てを包含するために総称的に用いられる。また、本明細書において、「セグメント」と「データユニット」は交換可能な用語として用いる。
【０００５】
送信ピアはデータユニットを下位層へ受け渡す。例えば、ＴＣＰ送信ピアは、ＩＰ層を介してＴＣＰセグメントをリンク層へ受け渡すであろう。そして、受信側では、受信ピアが下位層群からデータユニットを受信するであろう。データユニットを規定する（例えば開始と終了を規定する）予め定められた構成は、受信ピアが個々のセグメントを識別することを可能にする。
【０００６】
ＯＳＩ階層化概念によれば、下位層へ受け渡されたデータユニットがどのように処理され、またそこへ搬送されるかについては関係ない点に留意されたい。すなわち、特定の送信ピアがビットストリームを下流に受け渡し、受信ピアがビットストリームを受信する。このビットストリームは、フレーム境界インジケータのような識別要素を含んでおり、それを用いて受信ピアは個々のデータユニット及び個々のセグメントを識別することができる。
【０００７】
信頼できるデータ伝送を保証するため、多くのプロトコルはデータユニットの再送機能を提供している。これは、必要であれば、シーケンスからセグメントを再送可能であることを意味する。通常、再送は受信確認(acknowledgement)技術を利用して行われる。つまり、受信ピアによるデータユニットの正しい受信が、受信ピアから送信ピアへ返送される適切な受信確認メッセージによって確認される。送信ピアはそのような受信確認メッセージを受信すると、送信ピアは適切に別のデータユニットの送信を継続することができる。受信確認メッセージが受信されなかったり、非受信確認(non-acknowledgement)メッセージが受信されたりすると、受信ピアによって正しく受信されなかったそのデータユニットは、送信ピアによる再送が可能である。
【０００８】
適切な再送を行うことが出来るよう、送信ピアは、既知の方法を用いて、データユニット又はセグメントの喪失が発生したことの通知を取得することになっている。そのような既知の機能の１つは再送タイムアウトである。これは、データユニットの送信後にタイマを監視し、そのデータユニットの受信確認を受信しないうちに予め定められた時間が経過した場合、そのデータユニットが喪失したものと見なし、再送されるというものである。
【０００９】
別の仕組みは、重複受信確認(duplicate acknowledgement)の計数である。重複受信確認は、最後に正しく受信されたデータセグメントとして、既に受信確認されているデータセグメントを特定している受信確認である。すなわち、例えばＴＣＰのような、多くのプロトコルは、シーケンスのセグメントが正しく受信できるごとに受信確認メッセージを送信するように動作する、受信ピア用の受信確認生成機構を有している。ここで、受信確認は、最後に正しく受信されたデータセグメントを、シーケンスの順番で特定する。換言すれば、例えば１番目から４番目のデータセグメントが受信され、かつ受信確認されているとして、５番目のデータセグメントが到着すると、受信ピアはその５番目のセグメントに対する受信確認を送信するであろう。その後、７番目及び８番目のセグメントが正常に到着したとすると、受信ピアは再度１つ又は２つの受信確認メッセージを送信するであろう。しかし、シーケンスの順番においては５番目のセグメントが正常受信された最後のセグメントであるため、これらの受信確認メッセージは５番目のセグメントだけを特定するであろう。すなわち、受信ピアは６番目のセグメントを待っており、６番目より後のセグメントを正常に受信したとしても、受信ピアは５番目のセグメントの受信確認を継続するであろう。その結果、送信ピアは重複受信確認の受領により、データユニットが喪失したことを知らされる。
【００１０】
従って、上述した、受信確認メッセージがシーケンスの順番通りに正しく受信された最後のデータユニットのみの受信確認を行うような受信確認機構を用いるプロトコルにおいては、シーケンスにおける先の順番のデータユニットが受信されていたとしても、予め定められた数の重複した受信確認が送信ピアで受信されると再送機構が実施されることになるであろう。ＴＣＰにおいて、これに対応する仕組みは「高速再送(fast retransmit)」として知られ、３つの重複受信確認を受信した後に再送が成立する。ＴＣＰにおける高速再送機構の詳細な説明については、上述したStevensの著書における21.7章を参照されたい。
【００１１】
【非特許文献１】W. Richard Stevens、「TCP/IP Illustrated Volume 1, The Protocols」、1994年、Addison Wesley社
【発明の開示】
【発明が解決しようとする課題】
【００１２】
データユニットが喪失したことの通知を受け取る上述したような仕組みはいずれも、送信ピアがデータユニットが喪失したことの間接的な通知しか受信しないという問題の影響を受ける。そして、予め定められたトリガイベント（タイムアウト又は所定数の重複受信確認）の発生は、データユニットの真の喪失を必ずしも意味しないのが実情である。これらのトリガイベントは、例えば、あるデータユニットが伝送網で遅延された一方で、シーケンスの後の順番のセグメントに付随するデータユニットがその伝送網で配信されている場合には、誤って発生しうる。このような現象は順序の入れ替わり(reordering)とも呼ばれる。
【００１３】
（発明の目的）
本発明の目的は、送信ピアにおいてセグメント再送処理が発生する可能性を概して改善することにある。
【課題を解決するための手段】
【００１４】
この発明の目的は、送信ピアから受信ピアへのデータセグメント列の流れを制御する方法であって、データセグメントを前記送信ピアから前記受信ピアへ、前記列の順番で送信するステップと、前記列の適切な順番でデータセグメントが正しく受信されたことを示す受信確認メッセージを、前記受信ピアから受信するステップと、データセグメントが受信されたが、前記列の前記適切な順番でない場合に、データセグメントの前記列の順番で最後に正しく受信されたデータセグメントに関連した重複受信確認メッセージを、前記受信ピアから前記送信ピアで受信するステップと、重複受信確認メッセージの数が、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数に対応する受信ウィンドウサイズに基づいて決定された重複受信確認閾値に達した場合、送信されたが受信確認されないデータセグメントが喪失したと判定するステップと、喪失したと判定されたデータセグメントを再送するステップとを有する方法によって達成される。
【００１５】
従って、送信ピアは重複受信確認メッセージ閾値を、受信ピアの状況を考慮して設定することが可能である。
【００１６】
別の実施形態によれば、受信ウィンドウサイズにより、喪失したと判定されるデータセグメント、すなわち再送されたデータセグメントの正しい受信を示す受信確認メッセージが、喪失したと判定されるデータセグメントの順番よりも後の順番のデータセグメントの送信より前に送信ピアで受信されるように選択されたデータセグメント列における時点より前に、喪失したと判定されるデータセグメントが再送されるように重複受信確認閾値が設定される。従って、受信ピアのリソースを常に最適に利用する閾値を維持することができる。
【００１７】
別の実施形態によれば、重複受信確認メッセージ閾値は、受信ウィンドウサイズとフライトサイズとの差によって形成される利用可能ウィンドウサイズに基づいて決定される。フライトサイズは、受信確認がなされていない送信済データセグメントの数を表す。
【００１８】
さらに、重複受信確認メッセージ閾値は利用可能ウィンドウサイズとフライトサイズの差に基づいて決定されても良い。
【００１９】
別の実施形態によれば、重複受信確認メッセージ閾値は、最初の重複メッセージの受信前のある一時点において、値１と下式により計算される値の大きい方の値として決定される。
（受信ウィンドウサイズ−（ｋ×フライトサイズ））
ここで、ｋは浮動小数点数(float)である。好ましくは、ｋ＝２である。
【００２０】
さらに、重複受信確認メッセージ閾値は、
受信ウィンドウサイズ−（２×フライトサイズ）＋Ｎと決定することもできる。
Ｎは、（２×フライトサイズ）−受信ウィンドウサイズ＋１＜Ｎ＜３の条件を満たす調整パラメータを形成する。
【００２１】
他の実施形態によれば、受信ウィンドウサイズの変更の判別時に重複受信確認メッセージ閾値が更新される。
【００２２】
あるいは、重複受信確認メッセージ閾値は、複数のデータセグメントの１つに対する重複受信確認メッセージ閾値が少なくとも最初に受信されるごとに更新してもよい。この場合、調整パラメータＮは好ましくは５に設定される。
【００２３】
別の選択肢として、重複受信確認メッセージ閾値は、受信確認メッセージが受信されるごとに更新されても良い。
【００２４】
他の実施形態によれば、喪失したと判定されたデータセグメントは、送信ピアが過去に送信されていないデータセグメントの送信をブロックされている場合に再送される。
【００２５】
この実施形態では、送信ピアは、以下の条件の１つが満たされている場合、ブロックされていると見なされる。過去に送信されていないデータセグメントの数が受信ウィンドウサイズを超えている場合、過去に送信されていないデータセグメントが送信ウィンドウサイズを超えている場合、又はデータセグメントのソースを形成するアプリケーションが送信用のデータセグメントを供給しない場合。
【００２６】
コンピュータで実行された際に、上述の動作の少なくとも１つを実行するよう、コンピュータプログラムを適合することもできる。
【００２７】
このコンピュータプログラムをコンピュータ読み取り可能な記憶装置に格納してもよい。
【００２８】
さらに、発明の目的は、送信ピアから受信ピアへの一連のデータセグメントの流れを制御する通信装置であって、データセグメントを前記送信ピアから前記受信ピアへ、前記列の順番で送信する手段と、前記列の適切な順番でデータセグメントが正しく受信されたことを示す受信確認メッセージを、前記受信ピアから受信する手段と、データセグメントが受信されたが、前記列の前記適切な順番でない場合に、データセグメントの前記列の順番で最後に正しく受信されたデータセグメントに関連した重複受信確認メッセージを、前記受信ピアから受信する手段と、重複受信確認メッセージの数が、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数に対応する受信ウィンドウサイズに基づいて決定された重複受信確認メッセージ閾値に達した場合、送信されたが受信確認されないデータセグメントが喪失したと判定する手段と、前記喪失したと判定されたデータセグメントを再送する手段とを有する通信装置によっても達成される。
【発明を実施するための最良の形態】
【００２９】
本発明は、送信すべきデータ量が複数のデータセグメントに分割され、データセグメントが一列に並べられ、列の順番でデータセグメントが送信ピアから受信ピアへ送信され、受信ピアが送信ピアに、列の正しい順番で正しく受信されたことを示す受信確認であって、正しい順番で受信された最後のデータセグメントを示す受信確認を送信し、正しい順番で受信されたデータセグメントのうち、最後に正しく受信されたデータセグメントとして同じデータセグメントを示す受信確認メッセージを送信ピアが閾値数受信したら、重複した受信確認が受信されたセグメントの直後のセグメントが再送される特定の通信プロトコルの任意の実装に適用可能である。
【００３０】
そのようなプロトコルの一例はＴＣＰである。しかし、上述した特性のうち、本発明の概念の実施に関する範囲の特性を有する他の任意の通信プロトコルに本発明が適用可能であることを明記しておく。
【００３１】
本発明によれば、受信確認メッセージ数の閾値、すなわち、重複受信確認閾値は、受信ウィンドウのサイズに基づいて決定される。ここで、受信ウィンドウサイズは、受信ピアにおけるバッファ空間に格納可能なデータセグメントの数を表す。
【００３２】
従って、既に述べたように、重複受信確認閾値は、重複受信確認が受信されている特定のセグメントを喪失したものと決定するまでにどれくらい待てばよいかに関する送信ピアの決定に関係したパラメータである。本発明によれば、閾値が適合されるので、この決定自体を適合的に行うことが可能であり、より一層の柔軟性を実現できる。
【００３３】
図１は、本発明の実施形態に係る、送信ピア及び受信ピア（図示せず）間のデータセグメントの流れを制御する動作を説明する図である。
【００３４】
最初の工程１０１において、送信ピアは、ある特定の順番でデータセグメントを送信する通常のルーチンを実行するものとする。例えば、複数のデータセグメントに01, 02, 03, 04, 05, 06,...のような連番が付与され、この連番の順に送信ピアで送信されるようにスケジュールされる。このような連続した番号の付与は、例えば本技術分野で周知であるように、データソースのデータセグメントの出力にうまく対応するであろう。データセグメントは任意のペイロードデータ、すなわち、音声データ、通信セッションにおけるコンピュータ装置間のデータ交換、ビデオデータ、オーディオデータ等、任意の種類のアプリケーション又はフォーマットに関するデータを搬送しうることが理解されよう。
【００３５】
受信ピア（図１には示していない）は、データセグメントを受信し、送信ピアに返送される受信確認メッセージにより、データセグメントの受信の確認を行う。受信ピアからのこれら受信確認メッセージは、工程１０２において送信ピアが受信する。動作が正常であり、順番に送信されたデータセグメントが順番通り受信ピアで受信されれば、各データパケットは受信確認メッセージによって受信確認され、送信ピアはデータセグメントが正しい順序で受信されていることが分かる。送信ピアから送信され、正しく受信確認されたデータセグメントは、再送の必要がないであろうから、例えば送信ピアにおける送信バッファから除去したりするなどにより破棄することが可能である。
【００３６】
通常、正しく受信されたデータセグメント、すなわち誤りがなく順番通りであるデータセグメントの各々は、受信ピアにおいて受信確認メッセージをトリガし、受信確認メッセージが送信ピアへ返送される。正しく受信されたデータセグメントの後に順番通りでないデータセグメントが受信された場合、つまり、データセグメントの送信において遅延又は障害が発生した場合、最後に正しく受信されたデータセグメントに対する受信確認メッセージが繰り返される。この、繰り返された受信確認メッセージを、重複受信確認メッセージと呼ぶ。
【００３７】
上述の例において、何らかの理由により送信順序の正しい順番でデータセグメントが受信されない場合、例えばセグメント01,02,03の後、データセグメント04の前にデータセグメント05が受信されたとすると、受信ピアは、受信確認メッセージを送信ピアへ返送しない。代わりに、受信ピアは、データセグメントが受信されたが、順番通りではないことを示す重複受信確認メッセージを送信ピアへ送信する。重複受信確認メッセージは、一連のデータセグメントにおいて、順序通りに最後に正しく受信されたパケットに関連付けされる。データセグメント04の前にデータセグメント05が受信された上述の例において、重複受信確認メッセージは、順序通りに正しく受信された最後のデータセグメントが、データセグメント03であることを示すであろう。
【００３８】
従って、工程１０３において送信ピアに受信される重複受信確認メッセージは、このデータパケットが送信ピアから受信ピアへの送信経路の間で実際に喪失したことが分かった場合、あるいは喪失したと判断される場合には、最後に正しく受信されたパケットに続くパケットの再送が要求されるであろうことを、送信ピアへ知らせる。従って、送信ピアは、工程１０３で受信した重複受信確認メッセージが示す最後に正しく受信されたデータパケットより後に送信されたデータパケットを、送信バッファから破棄しないであろう。
【００３９】
しかし、送信ピアは受信ピアへのデータセグメントの送信を継続する。つまり、上述の例におけるデータセグメント04がさらに長い期間受信ピアで受信されないとすると、受信ピアはデータセグメントを受信するたびに重複受信確認メッセージの送信を継続する。従って、送信ピアはより多くの重複受信確認メッセージを受信し、重複受信確認メッセージごとに、受信確認されていないデータセグメントが実際に喪失した可能性が高まっていく。工程１０４において、送信ピアは、重複受信確認メッセージの数が、送信ピアに適切に設定されている重複受信確認メッセージ閾値（後述）を超えているか否かを判定する。工程１０４において、判定が「ＮＯ」であれば、重複受信確認メッセージ閾値に未だ達していないことを示し、動作は工程１０１へ戻る。すなわち、送信ピアは順番に従ってデータセグメントの送信を継続する。
【００４０】
しかし、工程１０４での判定が「ＹＥＳ」であれば、重複受信確認メッセージ閾値に達したか、閾値を超えたかを示し、工程１０５において送信ピアは、送信したが受信確認されていないデータセグメントが喪失したと判定する。上述の例を継続すると、順番通りに正しく受信された最後のデータセグメントはデータセグメント３であることを示す重複受信確認メッセージにより、送信ピアはデータセグメント４が本当に喪失したと判定する。
【００４１】
工程１０６において、喪失したと判定されたデータセグメント、この例ではデータセグメント04、が再送される。再送は例えばＴＣＰプロトコルによる高速再送(fast retransmit)によって行うことができる。
【００４２】
もちろん、重複受信確認メッセージ閾値を適切に設定するために最も重要な点として、データパケットの早期の再送は不必要なトラフィックの原因となること、送信されたが受信確認されていない全てのデータセグメントを送信ピア及び受信ピアのバッファに保持しておかねばならないため、あまりに長い間データセグメントの再送を行わないと別の送信を妨害する原因となることを念頭に置く必要がある。
【００４３】
より正確に言えば、送信済だが受信確認されていないデータセグメントの許容最大数に達したことにより、送信ピアにおいてデータセグメントの送信が禁止されることがないように閾値を設定すべきである。この許容最大数は受信ウィンドウサイズに等しい。スライディングウィンドウプロトコルによれば、ある通信プロトコルに係る送信ピアからのデータセグメントは、受信確認されたデータセグメントの最も古いものの番号と、次に送信するデータセグメントの番号との差が受信ウィンドウサイズを超えなければ、単に送信のスケジュールがなされるだけである。
【００４４】
上述した実施形態において、重複受信確認メッセージ閾値は受信ウィンドウサイズを用いていた。ここではこれ以上説明しないが、重複受信確認閾値は、その設定をより改良するため、例えば送信ピアにおけるウィンドウサイズなど、送信ピアの状況に基づいてさらに適合させることも可能である。以下、本発明のさらなる実施形態を図２に関して説明する。図２は、重複受信確認メッセージ閾値の好ましい設定のための動作を説明する。
【００４５】
上述の通り、閾値は、受信ピアにおけるバッファオーバフローを確実に防ぐことができ、かつ送信ピアからのデータセグメント送信が停止することを確実に防ぐことができるよう、適切に選択する。送信ピアにおける送信の停止や禁止は、送信済だが受信確認されていないデータセグメントの数が受信ウィンドウサイズをまさに超えようとする際に発生しうる。
【００４６】
上述の条件を満たすには、受信確認されていない最も古いデータセグメントを含む送信済データセグメントの数が、受信ピアにおける受信ウィンドウサイズを常に超えないようにする必要がある。
【００４７】
従って、あるデータセグメントが受信確認されていないとすると、このデータセグメントの再送が正しく受信されたことの受信確認が（再送データセグメントの正常な受信確認が受信されない場合に受信バッファのオーバフローを招きうる番号を有するデータセグメントの送信がスケジュールされるより前に）送信ピアへ到達することが可能な時点で、そのデータセグメントの再送をスケジュールすべきである。
【００４８】
つまり、受信確認されていないデータセグメントの再送は、この再送に伴う受信確認が、受信確認されていないデータセグメントを含む送信済データセグメントの数が受信ウィンドウサイズを超えないうちに送信ピアに届くことが期待されるように実行される必要がある。この条件が満たされないとすると、送信ピアはそれ以上のデータパケットの送信を許可されず、コネクションが停止してしまうであろう。
【００４９】
図２の工程２０１において、後述する条件に従った重複受信確認メッセージ閾値の更新を行うべきか否かを判定する。判定が「ＹＥＳ」であれば、工程２０２において、上述したように、受信ウィンドウサイズによって喪失したと判定されるデータセグメントについての正しい受信を示す受信確認メッセージが、喪失したと判定されるデータセグメントの順番より後の順番のデータセグメントの送信より前に送信ピアで受信されるように選択された、データセグメント列におけるある時点又はそれより前に、喪失したと判定されるデータセグメントが再送されるように重複受信確認閾値が設定される。従って、送信ピアがさらなるデータセグメントの送信を阻害されることを防止できる。
【００５０】
この場合、データ送信におけるウィンドウ停止(window stalling)の回避が可能であり、さらには受信バッファのオーバフローも回避可能である。
【００５１】
図３は、本発明の実施形態を説明するフローチャートである。フローチャートの左側は一般的なフロー制御に関するものであるが、本発明は例えばＴＣＰや他のフロー制御プロトコルによって提供されるような一般的なフロー制御とは関係ないため、この部分は模式的に一点鎖線で示すに止める。図の右側は重複受信確認の処理手順を示している。すなわち、工程３０１に示すように、一般的なフロー制御の過程で受信確認(ACK)が受信されると、それをきっかけに重複受信確認の処理手順が開始される。
【００５２】
工程３０２において、受信確認が重複受信確認かどうかを判定する。つまり、正しい順番で受信されたシーケンスの最後のデータセグメントを示す特定の受信確認の回数Ｎが求められ、回数Ｎが１よりも大きいかどうか判定される。もし違えば、ACKは重複ACKでなく、手順は一般的なフロー制御へ戻る。
【００５３】
工程３０２の結果が、受信確認が重複受信確認であることを示す場合、手順は工程３０３へ移行し、Ｎ(ACK)が重複受信確認閾値Thに達したか否かが判定される。実装に応じて、Ｎ(ACK)が重複受信確認閾値に等しい場合は重複受信確認閾値に達したと見なしても良い。あるいは、Ｎ(ACK)が重複受信確認閾値よりも大きい場合に重複受信確認閾値に達したと見なしても良い。
【００５４】
この工程は任意の適切な方法で実行することが可能である。例えば、最後に受信確認されたセグメントの記録を保持し、関連するカウンタを以下のように設定すればよい。新たに受信された受信確認が以前の受信確認と同一（すなわち、重複受信確認）であればカウンタを１増加させ、新たに受信された受信確認が最後に受信された受信確認によって示されるセグメントに続くセグメントを示していれば、カウンタを１にリセットする。
【００５５】
図３の例において、Ｎ(ACK)は送信ピアが特定の受信確認ACKを受信した回数を示す。つまり、Ｎ＝１は特定のセグメントに対する受信確認が初めて受信されたことを意味し、Ｎ＞１は受信確認が重複受信確認であることを示す。
【００５６】
工程３０３により、受信確認の数が閾値に達したと判定された場合、受信確認されていない最も古いセグメントが工程３０５で再送される。受信確認されていない最も古いセグメントは、重複受信確認において特定されるセグメントの次のセグメントである。一方、工程３０３の結果が否であれば、送信ピアの状況を考慮するため手順は工程３０４へ移る。
【００５７】
工程３０４において、送信ピアが、送信ピアで発生した状況によってデータセグメントの送信をブロックされている状況にあるか否かを判定する。ここにおける、ブロックされているとは、送信ピアが受信ピアへのデータセグメントの送信を許可されていないか、送信できないことを意味する。
【００５８】
一例によれば、過去に送信されていないデータセグメントの数が受信ウィンドウサイズを超えた場合、送信ピアはブロックされているものと見なされる。例えば、誤りや予期しない状況により、重複受信確認閾値が大きく設定され、受信ウィンドウサイズに達してしまうことがあり得る。この状況を受信機による制約(receiver limited)と呼ぶことができる。
【００５９】
別の例によれば、過去に送信されていないデータセグメントの数が送信ウィンドウサイズを超えた場合、送信ピアはブロックされているものと見なされる。例えば送信ピアの送信バッファが共用されているメモリ領域であり、データセグメントを保存するために残っている容量が受信ウィンドウサイズを下回るような大きさになるかもしれない。この状況を送信機による制約(sender limited)と呼ぶことができる。
【００６０】
他の例によれば、データセグメントのソースを形成するアプリケーションが、送信のためのデータセグメントを供給しない場合に、送信ピアがブロックされていると見なされる。例えば、データセグメントが例えばウェブページのデータセグメントである場合、動的に生成されうる。また、アプリケーションは新たなデータセグメントの生成を一時的に中止しうる。さらに、アプリケーションが単に現在送信するためデータセグメントを有していないかもしれない。この状況をアプリケーションによる制約(application limited)と呼ぶことができる。
【００６１】
工程３０４において、送信ピアがデータセグメントの送信をブロックされていると判定されると、受信確認されていない最も古いセグメントが工程３０５で再送される。
【００６２】
工程３０４において、送信ピアがデータセグメントの送信をブロックされていないと判定された場合、重複受信確認で特定されるセグメントの次にくるセグメントに続く順番のセグメントが工程３０６で送信される。
【００６３】
工程３０５又は３０６の後、手順は一般的なフロー制御に戻る。
【００６４】
なお、工程３０４は任意であり、工程３０３における判定が「ＮＯ」であれば直ちに処理を一般的なフロー制御へ戻しても良い。あるいは、工程３０６へ移行し、順番における次のセグメントの送信を行っても良い。
【００６５】
図３の実施形態は単なる一例であり、様々な方法で変更することが可能であることに留意されたい。動作を異なる形態に構成可能であることは当業者が理解するところであろう。さらに、工程３０６は単なる一例であり、本発明は重複受信確認閾値を超えた後の手順とは特に関係しない。つまり、重複受信確認閾値を超えた後の手順は、任意の適切又は好適な方法から選択可能であり、ＴＣＰのようなプロトコルに関する様々な可能性についてさらに検討すべきである。
【００６６】
同様に、重複受信確認に対する一般的なフロー制御における応答についても、本発明には必須でない。例えば、工程３０３の結果が否、つまり重複受信確認が受信されたがその数が閾値に達していない場合、一般的なフロー制御はそれ以上のセグメントの送信を停止しても良いし、これまで通りセグメントの送信を継続しても良い。
【００６７】
重複受信確認閾値は、好適又は望ましい任意の方法で設定又は更新することができる。例えば、閾値を適合させるために用いられる１つ又は複数の値に基づいて、定期的に更新することができる。つまり、これら１つ又は複数の値は定期的に測定又は求められ、それに従って閾値Thが更新される。この処理は、図３に示す処理には含まれず、独立した手順で行われる。すなわち、この独立手順は適切に保存されるThの値を定期的に更新し、工程３０３及び３０４はThの現在の値を単にアクセスもしくは呼び出す。一方、予め定めたトリガイベントの発生時にThを更新することもできる。１つの可能な方法として、Thを適合させるために用いられる１つ又は複数の値の１つ又は複数が変化した際にのみThを更新することができる。このような手順もまた、おそらく図３に示す手順とは独立であり、工程３０３及び３０４はThの現在の値を単にアクセスもしくは呼び出すであろう。
【００６８】
しかし、指定されたトリガイベントは図４に示す手順の一部であっても良い。つまり、Thの更新は、受信確認の受信に関連したトリガイベントの発生時に実行しても良い。例えば、１回目の重複ACKを受信するたびにThを更新しても良い。これを図４に示す。図４において、図３と同じ工程には同じ参照数字を付してある。つまり、図４に示す工程４０１及び４０２は、図３に示した工程３０２と３０３の間で実施される。工程３０２によって重複受信確認の受信が判定された後、工程４０１は、重複受信確認が最初の重複受信確認であるかどうか、すなわちＮ(ACK)＝２かどうかを判定する。そしてもしそうであれば、工程４０２でThが更新される。工程４０１又は４０２の後、工程３０３が実施される。他の全工程については図３と関連して既に説明したため、ここではこれ以上の説明を行わない。
【００６９】
重複受信確認の都度Thを更新することもできる。これを図５に示す。つまり、更新工程５０１は、全ての重複受信確認によりThが更新されるように、工程３０２の後にくる。
【００７０】
あるいは、図示しないが、閾値Thを受信確認ごとに更新することもできる。つまり、更新工程を図３の工程３０１と３０２の間で実行してもよい。別の態様としては、受信確認されていない(outstanding)データセグメントに関するACK、すなわちＮ(ACK)＝１の受信確認についてのみ、Thを更新する工程を有しうる。この場合、更新工程は図３の工程３０２の結果が否であった場合に実行されうる。
【００７１】
上述の通り、重複受信確認閾値Thの更新は、任意の適切又は望ましいタイミングで実行することが可能である。同様に、上述したように、受信ピアにおける受信ウィンドウサイズを考慮した任意の適切又は好適な方法で更新を行っても良い。
【００７２】
以下、図６に関して、本発明の別の実施形態を説明する。図６は、送信ピアと受信ピアの間で例えばＴＣＰプロトコル又はたの好適な通信プロトコルを用いて送信されるデータセグメントの流れを制御するための、送信ピアの要素を示す。
【００７３】
図６は、例えばデスクトップコンピュータ、ラップトップコンピュータ、ＰＤＡのような携帯コンピュータ装置のような何らかのコンピュータ装置又は移動電話機等である送信ピア６００を示す。本発明は有線式のデータ交換にも、無線又は少なくとも一部が無線のデータ伝送にも等しく適用可能である。
【００７４】
送信ピアは、送信ピアから受信ピアへ順番に従ってデータセグメントを送信するとともに、上述の実施形態において説明したように、喪失したと判定されるデータセグメントを再送するための送信／再送手段６０１を有する。
【００７５】
さらに、送信ピアは、正しい順番でデータセグメントが正しく受信された場合に受信ピアから受信確認メッセージを受信するとともに、データセグメントが受信されたが順番が正しくない場合に受信ピアから重複受信確認メッセージを受信するための受信手段６０２を有する。重複受信確認メッセージは、順番通りに正しく受信された最後のデータセグメントに関連して受信される。
【００７６】
さらに、送信ピアは、重複受信確認メッセージの数が、受信ウィンドウサイズに基づいて決定された重複受信確認メッセージ閾値に達した場合に、送信したが受信確認されないデータセグメントが喪失したことを判定するためのパケット喪失判定手段６０３を有する。受信ウィンドウサイズは、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数に対応する。パケット喪失判定手段は、受信確認メッセージもしくは他の任意の手段により、受信ウィンドウサイズの情報を取得することができる。
【００７７】
さらに、パケット喪失判定手段は、受信ウィンドウサイズによって喪失したと判定されるデータセグメント、すなわち再送されたデータセグメント、についての正しい受信を示す受信確認メッセージが、喪失したと判定されるデータセグメントの番号より大きな番号のデータセグメントの送信より前に送信ピアで受信されるように選択された、データセグメント列におけるある時点に、喪失したと判定されるデータセグメントが再送されるように重複受信確認閾値を設定するように構成されうる。
【００７８】
以下、図６に関して本発明の別の実施形態を説明する。
【００７９】
図７は、例えばＴＣＰプロトコルを用いて、重複受信確認メッセージ閾値を決定する原理をさらに説明するための詳細な実施形態を示す。
【００８０】
図７は、例えば上述の実施形態に関して述べたような、送信ピア及び受信ピアを示している。
【００８１】
送信ピアにおいて、受信ピアへ送信するための01,02,03,...,30と番号付けされた一連のデータセグメントが示されている。ここでは、伝送経路上で喪失したか、遅延が大きすぎると見なされるデータセグメント01の再送が含まれている。データセグメント01は以下に説明する理由により、データセグメント22の後に再送されている。
【００８２】
図７の実施形態において、重複受信確認閾値は、受信ウィンドウサイズに基づいて設定される。より正確に言えば、受信ウィンドウサイズによって喪失したと判定されるデータセグメントについての正しい受信を示す受信確認メッセージが、喪失したと判定されるデータセグメントの順番より後の順番のデータセグメントの送信より前に送信ピアで受信されるように選択されたデータセグメント列におけるある時点に、喪失したと判定されるデータセグメントが再送されるよう、重複受信確認閾値が設定される。データセグメント01を再送する時点は、送信ピアにおける停止が発生しうる時点より前の最も遅い時点を形成する。そのため、さらに遅延された送信、すなわちより大きな重複受信確認閾値を回避する一方で、より少ない遅延、すなわちより小さな重複受信確認メッセージ閾値を一般に実現できる。
【００８３】
本事例において、受信ウィンドウサイズは３０、すなわち受信バッファはデータセグメント用に３０の格納場所を有するものとする。これは、３１番目のデータセグメントは最初のデータセグメントに対する受信確認がなされた後でのみ送信可能であることを暗示する。
【００８４】
図７の例において、既に述べたように、また点線の矢印で示したように、送信ピアで最初のデータセグメントとして送信されたデータセグメント01は、伝送経路において喪失したものと見なされている。データセグメント02,03等は、正しく送受信されているものと見なされている。
【００８５】
従って、データセグメント01が受信ピアで不足しているため、受信ピアにおけるデータセグメント02は最初の重複受信確認メッセージ(DUPACK)の返送を招く。最初の重複受信確認メッセージは、データパケット10の送信後で、データパケット11の送信前に送信ピアに受信されるものと考えられる。このDUPACKの遅延は、伝送遅延、処理遅延及び類似物に関連する。同様に、データセグメント01が依然として不足し続けているので、受信ピアにおける引き続く全てのデータセグメントの受信は、受信ピアから送信ピアへの重複受信確認メッセージの送信を引き起こす。そして、図７の左側に示すように、送信ピアで受信する重複受信確認メッセージの数が増加する。送信ピアがデータセグメント01の再送を行わずに、順番に従ったデータセグメントの送信を継続したとすると、最終的にはデータセグメント30が送信されると、受信ウィンドウサイズに達して送信を停止せざるを得なくなる。つまり、データセグメント01を含む、デーセグメント01からの３０のデータセグメントに対する受信確認が未解決なので、データセグメント30以降の送信は許可されないであろう。送信ピアにおける送信の停止又はブロックは、例えば、送信済で受信確認されていないデータセグメントが受信ウィンドウサイズを超えようとした時点に発生しうる。
【００８６】
この状況を回避するため、図に示すように、再送されたデータセグメント01の受信確認がデータセグメント31の送信前に送信ピアに到達するための十分な時間を与えるため、１４番目に送信されたデータパケット、すなわちデータパケット14によって発生した１３番目の重複受信確認メッセージを受信した後、最初のデータパケット01が再送される。従って、データセグメント01は、１３番目の重複受信確認メッセージの受信時又は遅くとも１３番目の重複受信確認メッセージの受信後、データセグメント22の後に送信され、データセグメント30以降の一連のデータセグメントの送信が停止することを回避可能にする。
【００８７】
従って、送信の停止が許容されるか、送信の停止が他の手段によって回避されない限り、本実施形態における、１３番目の重複受信確認メッセージ後のデータセグメント01の再送は回避されなければならない。早期の送信は停止を招かないが、不要かもしれない再送によりネットワークトラフィックを増加させる。つまり、図７に示すように、送信ピアにおける送信の停止を回避できる限りはデータセグメント01の再送を待つべきである。
【００８８】
重複受信確認メッセージ閾値は、受信ウィンドウサイズとフライトサイズの差によって形成される利用可能ウィンドウサイズに基づいて決定されることが好ましい。ここで、フライトサイズは、受信確認が未だなされていない送信済データセグメントの数を表す。例えば、重複受信確認メッセージ閾値がデータセグメント10の送信時に計算されるとすると、フライトサイズ、すなわち送信済だが受信確認されていないデータセグメントは１０である。さらに、図示の通り、利用可能ウィンドウは、受信ウィンドウサイズから送信ウィンドウサイズを差し引いたもの、すなわち、送信されたが受信確認されていないデータセグメントの最小番号である送信ウィンドウの左端と、過去に送信されていないデータセグメントの最小番号である送信ウィンドウの右端との差として定義される。換言すれば、利用可能ウィンドウは、受信ピアにより制限されるまで、状況が許す限りＴＣＰセンダが任意の時点で送信可能なデータ量である。
【００８９】
さらに、重複受信確認メッセージ閾値は利用可能ウィンドウサイズとフライトサイズの差に基づいて決定されても良い。より正確に言えば、他の例によれば、重複受信確認メッセージ閾値が最初の重複受信確認メッセージを受信する直前、すなわちデータセグメント10の送信時に計算されるものと再度仮定すると、図７に示す条件及び上述の条件を満たす重複受信確認メッセージ閾値は以下のようになる。
利用可能ウィンドウサイズ＋２−（フライトサイズ−１）
これは、以下に等しい。
利用可能ウィンドウサイズ−フライトサイズ＋３
【００９０】
別の代替方法において、重複受信確認メッセージ閾値が最初の重複受信確認メッセージの受信時、すなわちデータセグメント11の送信時に計算されるものと仮定すると（上述した閾値更新の実施形態を参照されたい）、利用可能ウィンドウは１小さくなり、フライトサイズは１大きくなり、従って重複受信確認メッセージ閾値は以下のように計算される。
利用可能ウィンドウサイズ−フライトサイズ＋５
【００９１】
より一般化すると、重複受信確認メッセージ閾値は以下のように計算することができる。
利用可能ウィンドウサイズ−フライトサイズ＋Ｎ
また、上述した
利用可能ウィンドウ＝受信ウィンドウ−フライトサイズ
という条件を用いると、重複受信確認メッセージ閾値は、以下のように得られる。
受信ウィンドウサイズ−２×フライトサイズ
または、さらに一般化すると、以下のようになる。
受信ウィンドウサイズ−（ｋ×フライトサイズ）
ここで、ｋは浮動小数点数(floating value)である。
【００９２】
さらに、別の例によれば、重複受信確認メッセージ閾値は以下のように求められる。
受信ウィンドウサイズ−（２×フライトサイズ）＋Ｎ
Ｎは、以下の条件を満たす調整パラメータを形成する。
（２×フライトサイズ）−受信ウィンドウサイズ＋１＜Ｎ＜３
【００９３】
なお、上式は、重複受信確認閾値が、図７に示すように、最初の重複受信確認メッセージを受信するより１つ前の工程において計算されるものと仮定した場合である。また、既に概要を述べたように、重複受信確認閾値が１つ後の工程、すなわち、最初の重複受信確認メッセージの受信時に計算されるものとすると、Ｎ＜３をＮ＜５に置き換える。調整パラメータＮは、この場合５に設定可能であり、それによって、再送されたデータセグメントに対する受信確認が過去に送信されていないデータセグメント（すなわち初めて送信されるデータセグメント）の数が受信ウィンドウサイズを超える前に受信されるという上述の条件を満足する。条件が満たされないとすると、送信ピアは順番に従ったさらなるデータセグメントの送信のみを許されるので、送信済だが受信確認されていないデータセグメントの数がたとえ受信ピアによって知らされた受信ウィンドウサイズを超えなくても、送信ピアにおける送信停止を招くであろう。上述の数式を用いることで、フライトサイズが受信ウィンドウに関して大きい場合には負の重複受信確認閾値が得られる。このような負の重複受信確認閾値を回避するには、最大演算子(max-operator)を利用することができ、重複受信確認閾値がそのような負の値となることを回避することができる。従って、重複受信確認閾値を図７に示したタイミング、すなわち最初の重複受信確認メッセージを受信する前に計算する好ましい方法は、以下の通りである。
重複受信確認メッセージ閾値＝max（受信ウィンドウサイズ−２×フライトサイズ＋Ｎ，１）
【００９４】
以下の例では、調整パラメータをどのように求めることができるかについて説明する。上述の通り、Ｎ＝３とし、重複受信確認メッセージ閾値を最初の重複受信確認メッセージを受信する１つ前の工程で求めると、再送された最初のデータパケット01に対する受信確認は受信ウィンドウが「満タン」になった直後に受信される。しかしながら、これはただ１つのパケットが喪失し、パケットの順序入れ替わり(reordiering)が発生しないという条件下でのみ有効である。これら２つの条件が有効な場合、Ｎの３を超える増加は結局はウィンドウ停止、すなわち送信ピアが更なるデータパケットの送信を許されない状況となるであろう。そのため、Ｎ＝３はＮの上限値と考えられる。しかし、複数のセグメントが不足した場合、ウィンドウ停止を回避するためにＮをさらに増加させることもできる。しかしながら、これは一般的なケースではなく、Ｎ＝３が上限値として好ましく選択されうるであろう。
【００９５】
Ｎの下限値に関しては、重複受信確認閾値を計算するための任意のアルゴリズムに対し、１以上の値を計算することを要求することが合理的である。これは、以下の条件を満たせば得られる値である。
Ｎ＝（２×フライトサイズ−受信ウィンドウ−１）
【００９６】
一般に、Ｎが減少すれば、システムは保守的でない方向へ移行する。すなわち、早めにエラー回復が起動され、換言すればデータパケットが喪失したという判定が早めになされる。しかしながら、小さいＮ、つまり小さい重複受信確認閾値は、ネットワークにおけるパケットの順序入れ替わりに対する送信ピアのロバスト性を低下させる。
【００９７】
良好な結果を得るための、上限値及び下限値の間の合理的な値として、重複受信確認メッセージ閾値は、
max（受信ウィンドウサイズ−２×フライトサイズ，１）
として設定することができる。
すなわち、Ｎ＝０である。
【００９８】
図６の通信装置は、上述した計算及び工程を実行するように構成されうる。
【００９９】
より正確には、別の実施形態において、通信装置は、受信ウィンドウサイズによって喪失したと判定されるデータセグメント、すなわち再送されたデータセグメントの正しい受信を示す受信確認メッセージが、喪失したと判定されるデータセグメントの順番よりも後の順番のデータセグメントの送信より前に送信ピアで受信されるように選択されたデータセグメント列における時点より前に、喪失したと判定されるデータセグメントが再送されるように重複受信確認閾値を設定するための手段を有する。
【０１００】
さらに、別の実施形態において、通信装置は重複受信確認閾値を受信ウィンドウサイズとフライトサイズの差によって形成される利用可能ウィンドウサイズに基づいて決定する手段を有する。フライトサイズは送信済で受信確認されていないデータセグメントの数を表す。
【０１０１】
さらに、別の実施形態において、通信装置は重複受信確認閾値を利用可能ウィンドウサイズとフライトサイズの差に基づいて決定する手段を有する。
【０１０２】
重複受信確認メッセージ閾値を決定するための手段は、最初の重複メッセージの受信前のある一時点において、以下の値のうち、大きい方の値として決定される。
値１及び以下の計算により計算される値
（受信ウィンドウサイズ−（ｋ×フライトサイズ））
ここで、ｋは浮動小数点数(float)である。
【０１０３】
重複受信確認閾値を決定する手段は、ｋ＝２を用いるように構成されうる。
【０１０４】
さらに、別の実施形態において、通信装置は重複受信確認閾値を以下のように決定する手段を有する。
受信ウィンドウサイズ−（２×フライトサイズ）＋Ｎ
Ｎは、以下の条件を満たす調整パラメータを形成する。
（２×フライトサイズ）−受信ウィンドウサイズ＋1＜Ｎ＜3
【０１０５】
さらに、別の実施形態において、通信装置は重複受信確認閾値を受信ウィンドウサイズの変化の判別時に更新する手段を有する。
【０１０６】
さらに、別の実施形態において、通信装置は、データセグメントの１つに対して少なくとも最初に重複受信確認メッセージが受信されるごとに重複受信確認閾値を更新する手段を有する。
【０１０７】
さらに、別の実施形態において、通信装置は、受信確認メッセージが受信されるごとに重複受信確認閾値を更新する手段を有する。上述した、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数を表す受信ウィンドウサイズに基づいた重複受信確認メッセージ閾値の設定に加え、送信ピアの状況を考慮することも可能である。より正確には、他の実施形態によれば、喪失したと判定されたデータセグメントは、送信ピアが過去に送信されていないデータセグメントの送信をブロックされている場合に再送される。この場合、以下の条件の１つが満たされている場合、送信ピアがブロックされていると見なす。過去に送信されていないデータセグメントの数が受信ウィンドウサイズを超えている場合、過去に送信されていないデータセグメントが送信ウィンドウサイズを超えている場合、又はデータセグメントのソースを形成するアプリケーションが送信用のデータセグメントを供給しない場合。
【０１０８】
本発明の方法は、適切又は好適な任意の方法で実施することができ、特にコンピュータプログラムの形式で存在しうる。従って、そのようなコンピュータプログラムを保持する記憶媒体の形式でも存在しうる。同様に、本発明は本発明の方法に従って動作するように構成された通信装置の形態においても存在しうる。
【０１０９】
本発明を詳細な実施形態によって説明してきたが、本発明は添付した特許請求の範囲によって規定され、これらの実施形態には一切限定されない。さらに、特許請求の範囲における参照数字は、請求範囲の読解を容易にすることのみを目的としたものであり、本発明を限定するものとして理解すべきではない。
【図面の簡単な説明】
【０１１０】
【図１】本発明の実施形態に係る、データ列の流れを制御する方法の動作を示す図である。
【図２】本発明の実施形態に係る、重複受信確認閾値の決定動作を示す図である。
【図３】本発明の別の実施形態に係る、送信ピアから受信ピアへのデータセグメントの流れを制御する方法の動作のうち、特に受信確認されていないデータセグメントの再送の流れについて示す図である。
【図４】本発明の実施形態に係る、重複受信確認閾値の更新動作を示す図である。
【図５】本発明の実施形態に係る、重複受信確認閾値の更新動作を示す図である。
【図６】少なくとも送信ピアとして振る舞い、データセグメントの流れを制御する通信装置を示す図である。
【図７】重複受信確認閾値の決定について説明するため、送信ピア及び受信ピア間のデータセグメント及び受信確認メッセージの流れの詳細を示す図である。
【図１】
2008524942.tif 000002
【図２】
2008524942.tif 000003
【図３】
2008524942.tif 000004
【図４】
2008524942.tif 000005
【図５】
2008524942.tif 000006
【図６】
2008524942.tif 000007
【図７】
2008524942.tif 000008
【手続補正書】
【提出日】平成19年12月19日(2007.12.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
送信ピアから受信ピアへのデータセグメント列の流れを制御する方法であって、
データセグメントを前記送信ピアから前記受信ピアへ、前記列の順番で送信するステップと、
前記列の適切な順番でデータセグメントが正しく受信されたことを示す受信確認メッセージを、前記受信ピアから受信するステップと、
データセグメントが受信されたが、前記列の前記適切な順番でないことを示す重複受信確認メッセージであって、データセグメントの前記列の順番で最後に正しく受信されたデータセグメントに関連した重複受信確認メッセージを、前記受信ピアから前記送信ピアで受信するステップと、
重複受信確認メッセージの数が、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数に対応する受信ウィンドウサイズに基づいて決定された重複受信確認閾値に達した場合、送信されたが受信確認されないデータセグメントが喪失したと判定するステップと、
喪失したと判定されたデータセグメントを再送するステップとを有することを特徴とする方法。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１６
【補正方法】変更
【補正の内容】
【請求項１６】
送信ピアから受信ピアへの一連のデータセグメントの流れを制御する通信装置であって、
データセグメントを前記送信ピアから前記受信ピアへ、前記列の順番で送信する手段と、
前記列の適切な順番でデータセグメントが正しく受信されたことを示す受信確認メッセージを、前記受信ピアから受信する手段と、
データセグメントが受信されたが、前記列の前記適切な順番でないことを示す重複受信確認メッセージであって、データセグメントの前記列の順番で最後に正しく受信されたデータセグメントに関連した重複受信確認メッセージを、前記受信ピアから受信する手段と、
重複受信確認メッセージの数が、受信ピアにおけるバッファ空間に保存可能なデータセグメントの数に対応する受信ウィンドウサイズに基づいて決定された重複受信確認メッセージ閾値に達した場合、送信されたが受信確認されないデータセグメントが喪失したと判定する手段と、
前記喪失したと判定されたデータセグメントを再送する手段とを有することを特徴とする装置。
【国際調査報告】
2008524942.tif 000009
2008524942.tif 000010
2008524942.tif 000011