(57)【要約】【課題】パケットのデータ送信量を制御する際に通信帯域を有効に活用することが可能なパケット送信装置を提供する。【解決手段】パケット送信装置１は、パケットロス発生時にＲＴＴの増加に応じて輻輳ウインドウサイズ（ＣＷＮＤ）を削減する輻輳ウインドウサイズ削減手段１６０と、ＲＴＴに基づいてパケットロスが輻輳ロスかランダムロスかを判定するパケットロス原因判定手段１６１と、輻輳ロス発生時にＣＷＮＤの増加速度を初期化し、ランダムロス発生時にＣＷＮＤの増加速度が前回のパケットロス発生時から継続して増加する増加関数のパラメータを決定する増加関数パラメータ決定手段１６３と、ＡＣＫを受信するたびに、増加関数パラメータ決定手段１６３で決定された増加関数により演算されるＣＷＮＤを新たなＣＷＮＤとする輻輳ウインドウサイズ増加手段１６２と、を備えることを特徴とする。【選択図】図１
2014090367.tif 000002
【特許請求の範囲】
【請求項１】
送達確認応答なしに送信可能なパケット数を示す輻輳ウインドウサイズを予め定めた増加関数によって増加させ、パケットロスが発生したときに前記輻輳ウインドウサイズを削減するウインドウ制御方式によってパケットを送信するパケット送信装置において、
前記パケットの往復遅延時間を計測する往復遅延時間計測手段と、
前記パケットロスが発生したときに、当該ロス発生時の往復遅延時間に対する往復遅延時間の最小時間の割合を前記輻輳ウインドウサイズに乗算して当該輻輳ウインドウサイズを削減する輻輳ウインドウサイズ削減手段と、
前記往復遅延時間の増加量が予め定めた基準よりも大きい場合に、前記パケットロスがネットワークの輻輳によって発生した輻輳ロスであると判定し、それ以外の場合に、前記パケットロスがランダムに発生するランダムロスであると判定するパケットロス原因判定手段と、
このパケットロス原因判定手段で前記パケットロスが輻輳ロスと判定された場合に、前記輻輳ウインドウサイズの増加速度を初期化し、前記パケットロスがランダムロスと判定された場合に、前記輻輳ウインドウサイズの増加速度が前記パケットロス発生時から継続して増加する関数となるように増加関数のパラメータを決定する増加関数パラメータ決定手段と、
送達確認応答を受信するたびに、前記増加関数パラメータ決定手段で決定されたパラメータで特定される増加関数により演算される輻輳ウインドウサイズを新たな輻輳ウインドウサイズとする輻輳ウインドウサイズ増加手段と、
を備えることを特徴とするパケット送信装置。
【請求項２】
送達確認応答なしに送信可能なパケット数を示す輻輳ウインドウサイズを予め定めた増加関数によって増加させ、パケットロスが発生したときに前記輻輳ウインドウサイズを削減するウインドウ制御方式によってパケットを送信するパケット送信装置において、
前記パケットの往復遅延時間を計測する往復遅延時間計測手段と、
前記パケットロスが発生したときに、予め定めた割合で前記輻輳ウインドウサイズを削減したサイズと、当該ロス発生時の往復遅延時間に対する往復遅延時間の最小時間の割合を前記輻輳ウインドウサイズに乗算したサイズのうちで、大きい方のサイズを新たな輻輳ウインドウサイズとする輻輳ウインドウサイズ削減手段と、
前記往復遅延時間の増加量が予め定めた基準よりも大きい場合に、前記パケットロスがネットワークの輻輳によって発生した輻輳ロスであると判定し、それ以外の場合に、前記パケットロスがランダムに発生するランダムロスであると判定するパケットロス原因判定手段と、
前記パケットロスが発生したときに、前記輻輳ウインドウサイズの増加速度を初期化した関数となる第１増加関数のパラメータを決定するとともに、
前記パケットロス原因判定手段で前記パケットロスが輻輳ロスと判定された場合に、前記輻輳ウインドウサイズの増加速度を初期化し、前記パケットロスがランダムロスと判定された場合に、前記輻輳ウインドウサイズの増加速度が前記パケットロス発生時から継続して増加する関数となるように第２増加関数のパラメータを決定する増加関数パラメータ決定手段と、
送達確認応答を受信するたびに、前記増加関数パラメータ決定手段で決定されたパラメータで特定される第１増加関数および第２増加関数により演算される輻輳ウインドウサイズのうちで、大きい方のサイズを新たな輻輳ウインドウサイズとする輻輳ウインドウサイズ増加手段と、
を備えることを特徴とするパケット送信装置。
【請求項３】
送達確認応答なしに送信可能なパケット数を示す輻輳ウインドウサイズを予め定めた増加関数によって増加させ、パケットロスが発生したときに前記輻輳ウインドウサイズを削減するウインドウ制御方式によってパケットを送信するために、パケット送信装置のコンピュータを、
パケットのデータを入力してデータバッファに記憶するデータ入力手段、
前記データバッファに記憶されたパケットのデータを読み出し、通信回線を介して、送信するデータ送信手段、
送信したパケットに対する送達確認応答を受信する送達応答確認受信手段、
前記輻輳ウインドウサイズに基づいて、送信するパケットのデータ量を制御するフロー制御手段、
前記パケットの往復遅延時間を計測する往復遅延時間計測手段、
前記パケットロスが発生したときに、当該ロス発生時の往復遅延時間に対する往復遅延時間の最小時間の割合を前記輻輳ウインドウサイズに乗算して当該輻輳ウインドウサイズを削減する輻輳ウインドウサイズ削減手段、
前記往復遅延時間の増加量が予め定めた基準よりも大きい場合に、前記パケットロスがネットワークの輻輳によって発生した輻輳ロスであると判定し、それ以外の場合に、前記パケットロスがランダムに発生するランダムロスであると判定するパケットロス原因判定手段、
このパケットロス原因判定手段で前記パケットロスが輻輳ロスと判定された場合に、前記輻輳ウインドウサイズの増加速度を初期化し、前記パケットロスがランダムロスと判定された場合に、前記輻輳ウインドウサイズの増加速度が前記パケットロス発生時から継続して増加する関数となるように増加関数のパラメータを決定する増加関数パラメータ決定手段、
送達確認応答を受信するたびに、前記増加関数パラメータ決定手段で決定されたパラメータで特定される増加関数により演算される輻輳ウインドウサイズを新たな輻輳ウインドウサイズとする輻輳ウインドウサイズ増加手段、
として機能させるためのパケット送信プログラム。
【請求項４】
送達確認応答なしに送信可能なパケット数を示す輻輳ウインドウサイズを予め定めた増加関数によって増加させ、パケットロスが発生したときに前記輻輳ウインドウサイズを削減するウインドウ制御方式によってパケットを送信するために、パケット送信装置のコンピュータを、
パケットのデータを入力してデータバッファに記憶するデータ入力手段、
前記データバッファに記憶されたパケットのデータを読み出し、通信回線を介して、送信するデータ送信手段、
送信したパケットに対する送達確認応答を受信する送達応答確認受信手段、
前記輻輳ウインドウサイズに基づいて、送信するパケットのデータ量を制御するフロー制御手段、
前記パケットの往復遅延時間を計測する往復遅延時間計測手段、
前記パケットロスが発生したときに、予め定めた割合で前記輻輳ウインドウサイズを削減したサイズと、当該ロス発生時の往復遅延時間に対する往復遅延時間の最小時間の割合を前記輻輳ウインドウサイズに乗算したサイズのうちで、大きい方のサイズを新たな輻輳ウインドウサイズとする輻輳ウインドウサイズ削減手段、
前記往復遅延時間の増加量が予め定めた基準よりも大きい場合に、前記パケットロスがネットワークの輻輳によって発生した輻輳ロスであると判定し、それ以外の場合に、前記パケットロスがランダムに発生するランダムロスであると判定するパケットロス原因判定手段、
前記パケットロスが発生したときに、前記輻輳ウインドウサイズの増加速度を初期化した関数となる第１増加関数のパラメータを決定するとともに、
前記パケットロス原因判定手段で前記パケットロスが輻輳ロスと判定された場合に、前記輻輳ウインドウサイズの増加速度を初期化し、前記パケットロスがランダムロスと判定された場合に、前記輻輳ウインドウサイズの増加速度が前記パケットロス発生時から継続して増加する関数となるように第２増加関数のパラメータを決定する増加関数パラメータ決定手段、
送達確認応答を受信するたびに、前記増加関数パラメータ決定手段で決定されたパラメータで特定される第１増加関数および第２増加関数により演算される輻輳ウインドウサイズのうちで、大きい方のサイズを新たな輻輳ウインドウサイズとする輻輳ウインドウサイズ増加手段、
として機能させるためのパケット送信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信によってデータを送信するパケット送信装置およびそのプログラムに関する。
【背景技術】
【０００２】
品質の保証がされていないベストエフォートタイプのＩＰネットワークでは、ネットワーク機器内部でのバッファ漏れ、伝送中のビットエラー等によって、送信パケットの廃棄（パケットロス）が発生する。そのため、従来、ＩＰネットワーク上で、確実にデータを伝送するための送達確認を行うプロトコルとしてＴＣＰ（Transmission Control Protocol）が幅広く利用されている（非特許文献１参照）。
【０００３】
このＴＣＰでは、受信装置がパケットを受信すると、受信した旨の報告として、次に送信を要求するパケットの番号を送信装置に通知する。そして、送信装置は、受信装置から通知される報告に基づいて、パケットが正常に受信装置に到達したことを確認する。また、送信装置は、受信装置から通知される報告でパケットロスを検出した場合、当該パケットを再送するとともに、送達確認応答なしに送出可能なパケットの数（セグメント数）を表す輻輳ウインドウサイズ（ＣＷＮＤ：Congestion Window Size）を調整する。
一般的に、ＴＣＰは、ＣＷＮＤを用いて輻輳を制御するための輻輳制御アルゴリズムとして、スロースタートフェーズと、輻輳回避フェーズと呼ばれる２つのフェーズで動作する。
【０００４】
まず、スロースタートフェーズにおいて、送信装置は、ＣＷＮＤを最小値（“２”）に設定し、受信装置から送信パケットに対するＡＣＫ（送達確認応答）が通知されるごとに、ＣＷＮＤを指数的に増加（ＣＷＮＤ＝ＣＷＮＤ＋１）させる。そして、送信装置は、パケットロスを検出した段階で、スロースタートフェーズにおいて増加させるＣＷＮＤの上限閾値であるスロースタート閾値（ｓｓｔｈｒｅｓｈ）をパケットロス発生時のＣＷＮＤの２分の１に設定し、輻輳回避フェーズに移行する。なお、パケットの送信時に、再送タイムアウト（ＲＴＯ：Retransmission Time Out）が発生したとき、送信装置は、どのフェーズで動作している場合であっても、ＣＷＮＤを最小値（“２”）に設定するとともに、ｓｓｔｈｒｅｓｈを直前のＣＷＮＤの２分の１に設定し、再度、スロースタートフェーズで動作する。
【０００５】
一方、輻輳回避フェーズにおいて、送信装置は、ＣＷＮＤを徐々に増加させる。例えば、ＴＣＰの一種類であるＲｅｎｏ（非特許文献２参照）では、受信装置から送信装置にＡＣＫ（送達確認応答）が通知されるごとに、ＣＷＮＤを線形的に増加させる。具体的には、往復遅延時間（ＲＴＴ：Round Trip Time）に対して１パケットの割合でＣＷＮＤを増加（ＣＷＮＤ＝ＣＷＮＤ＋１／ＣＷＮＤ）させる。そして、送信装置は、パケットロスを検出した段階で、ＣＷＮＤを２分の１に削減するとともに、その値をｓｓｔｈｒｅｓｈに設定する。これによって、送信装置は、パケットロスが発生した場合、スロースタートフェーズには移行せず、輻輳回避フェーズから動作を継続する。
【０００６】
なお、この輻輳回避フェーズの動作については、ＴＣＰにおいて、Ｒｅｎｏ以外にも種々の手法がある。例えば、ＮｅｗＲｅｎｏ（非特許文献２参照）、Ｖｅｇａｓ（非特許文献３参照）、ＣＵＢＩＣ（非特許文献４参照）等が知られている。
【０００７】
ＮｅｗＲｅｎｏは、Ｒｅｎｏと同様、受信装置から送信装置にＡＣＫが通知されるごとに、ＣＷＮＤを線形的に増加させる。具体的には、ＲＴＴに対して１パケットの割合でＣＷＮＤを増加させる。また、ＮｅｗＲｅｎｏも、パケットロスを検出した場合、ＣＷＮＤを半分に削減する。
【０００８】
Ｖｅｇａｓは、送信装置がＲＴＴを計測し、その期待値と実測値との差が予め定めた定数よりも小さいときには、Ｒｅｎｏと同様、１ＲＴＴごとにＣＷＮＤを１増加させる。また、Ｖｅｇａｓは、ＲＴＴの期待値と実測値との差が予め定めた定数よりも大きいときには１ＲＴＴごとにＣＷＮＤを１減少させる。また、Ｖｅｇａｓは、ＲＴＴの期待値と実測値との差が予め定めた定数の範囲内であれば、ＣＷＮＤを維持する。また、Ｖｅｇａｓは、パケットロスを検出した場合、Ｒｅｎｏと同様、ＣＷＮＤを半分に削減する。
【０００９】
ＣＵＢＩＣは、ＲｅｎｏやＶｅｇａｓとは異なり、ＲＴＴを基準にＣＷＮＤを増加させるのではなく、経過時間の３乗に比例してＣＷＮＤを増加させる。なお、ＣＵＢＩＣは、パケットロスを検出した場合に、ＣＷＮＤを２分の１に削減するのではなく、予め定めた割合でＣＷＮＤを削減する。このＣＵＢＩＣは、Ｌｉｎｕｘ（登録商標） ｋｅｒｎｅｌ ２．６．１９から、ＴＣＰのデフォルトのＣＷＮＤ調整手法として用いられている（非特許文献５参照）。
【００１０】
このＣＵＢＩＣを使用した発明としては、後に通信を開始したフローが、先に通信を開始していたフローの帯域を獲得して公平に帯域を分け合う状態になるまでに時間がかかるという問題を改善した手法が開示されている（特許文献１参照）。
また、ＣＷＮＤを調整する他の手法として、パケットロスが発生した際に、パケットの再々送、パケットの到着間隔の伸び方等によって、ネットワークの輻輳状態を判定し、その判定結果に応じてＣＷＮＤの増減を切り変える手法が開示されている（特許文献２参照）。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特許第４４２９９８２号公報
【特許文献２】特許第４６５４９２６号公報
【非特許文献】
【００１２】
【非特許文献１】“RFC: 793 TRANSMISSION CONTROL PROTOCOL September 1981”、［online］、［平成２４年１０月１６日検索］、インターネット<URL: http://www.ietf.org/rfc/rfc793.txt>
【非特許文献２】“RFC:6582 The NewReno Modification to TCP's Fast Recovery Algorithm April 2012”、［online］、［平成２４年１０月１６日検索］、インターネット<URL: http://www.ietf.org/rfc/rfc6582.txt>
【非特許文献３】“TCP Vegas: End to End Congestion Avoidance on a Global Internet”, Lawrence S. Brakmo, Larry L. Peterson (IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS,Vol.13 No.8 pp.1465-1480, Oct. 1995)
【非特許文献４】“CUBIC: A New TCP-Friendly High-Speed TCP Variant”, Sangtae Ha, Injong Rhee and Lisong Xu (ACM SIGOPS Operating System Review, Volume 42, Issue 5, July 2008)
【非特許文献５】"The Linux Kernel Archives"、［online］、［平成２４年１０月１６日検索］、インターネット<URL:http://www.kernel.org>
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、前記したＲｅｎｏ、ＮｅｗＲｅｎｏ、Ｖｅｇａｓは、１ＲＴＴごとにＣＷＮＤを増加させるため、ＣＷＮＤの増加速度が、１パケット／ＲＴＴに制限されてしまう。そのため、前記したＲｅｎｏ等は、ＲＴＴが大きい遠隔地との通信では、ＣＷＮＤの増加速度が鈍く、たとえ広帯域の回線を用いた場合であっても、その回線を有効に利用することができないという問題があった。
【００１４】
また、前記したＣＵＢＩＣ（特許文献１の技術を含む）は、１ＲＴＴごとにＣＷＮＤを増加させるのではなく、経過時間の３乗に比例する増加関数でＣＷＮＤを増加させるため、ＲＴＴが大きな回線であっても短時間でＣＷＮＤを増加させることができ、広帯域の回線をＲｅｎｏ等よりも有効に利用することができる。
【００１５】
しかし、ＣＵＢＩＣは、パケットロスを検出した場合、一様にＣＷＮＤを削減してしまう。すなわち、ＣＵＢＩＣは、パケットロスが、輻輳以外の原因、例えば、ビット誤り等によって生じたランダムロスが原因であっても、輻輳発生時と同様にＣＷＮＤを削減してしまう。また、ＣＵＢＩＣは、ネットワーク内のバッファが少ない回線であっても、バッファが多い回線と同様に、ＣＷＮＤを削減してしまう。
このように、ＣＵＢＩＣは、必要以上にＣＷＮＤを削減する場合があり、ネットワーク内のバッファが帯域遅延積（ＢＤＰ）に対して小さい回線や、ランダムロスが多発する回線では、通信帯域を有効に活用することができないという問題があった。
【００１６】
なお、前記した特許文献２に記載の手法は、ネットワークの輻輳状態に応じてＣＷＮＤを調整することで、帯域の活用を図っている。しかし、この手法は、ＣＵＢＩＣのような経過時間に伴う増加関数によってＣＷＮＤを制御する輻輳制御方法を想定したものでない。すなわち、特許文献２に記載の手法では、パケットロスによるＣＷＮＤの不要な削減を抑えることはできても、輻輳発生後、ＣＷＮＤの増加速度が低下するため、やはりランダムロスが多発する回線では、ＣＷＮＤを高速に回線状態に適したサイズに増加させることができず、回線を有効に利用することができないという問題があった。
【００１７】
本発明は、このような問題に鑑みてなされたものであり、輻輳ウインドウサイズ（ＣＷＮＤ）を制御するウインドウ制御方式によってパケットのデータ送信量を制御する際に、通信帯域を有効に活用することが可能なパケット送信装置およびそのプログラムを提供することを課題とする。
【課題を解決するための手段】
【００１８】
前記課題を解決するため、請求項１に記載のパケット送信装置は、送達確認応答なしに送信可能なパケット数を示す輻輳ウインドウサイズを予め定めた増加関数によって増加させ、パケットロスが発生したときに前記輻輳ウインドウサイズを削減するウインドウ制御方式によってパケットを送信するパケット送信装置において、往復遅延時間計測手段と、輻輳ウインドウサイズ削減手段と、パケットロス原因判定手段と、増加関数パラメータ決定手段と、輻輳ウインドウサイズ増加手段と、を備える構成とした。
【００１９】
かかる構成において、パケット送信装置は、パケットロスが発生したときに、輻輳ウインドウサイズ削減手段によって、ロス発生時の往復遅延時間に対する往復遅延時間の最小時間の割合を輻輳ウインドウサイズに乗算して輻輳ウインドウサイズを削減する。
これによって、輻輳ウインドウサイズ削減手段は、往復遅延時間が増加した分に相当するデータ量以上、すなわち、ネットワーク上にバッファされているパケット量よりも、輻輳ウインドウサイズを削減することがないため、ネットワーク上の空きの発生を抑えることができる。
【００２０】
また、パケット送信装置は、パケットロス原因判定手段によって、往復遅延時間の増加量に応じてパケットロスの原因を判定する。ここで、パケットロス原因判定手段は、往復遅延時間の増加量が予め定めた基準よりも大きい場合に、パケットロスがネットワークの輻輳によって発生した輻輳ロスであると判定し、それ以外の場合に、パケットロスがランダムに発生するランダムロスであると判定する。
これによって、パケットロス原因判定手段は、パケットロスの発生原因が、ネットワーク輻輳によるものか、ビット誤り等の単発的なものかを判定する。
【００２１】
そして、パケット送信装置は、増加関数パラメータ決定手段によって、パケットロスが輻輳ロスと判定された場合に、輻輳ウインドウサイズの増加速度を初期化し、パケットロスがランダムロスと判定された場合に、輻輳ウインドウサイズの増加速度がパケットロス発生時から継続して増加する関数となるように増加関数のパラメータを決定する。
ここで、輻輳ウインドウサイズの増加速度とは、増加関数で演算される輻輳ウインドウサイズの単位時間あたりの増加量（増加関数の傾き）である。また、その初期化とは、パケットロス発生時刻において、再度増加関数を定義し、増加速度を初期値に設定し直すことをいう。
【００２２】
そして、パケット送信装置は、輻輳ウインドウサイズ増加手段によって、送達確認応答を受信するたびに、増加関数パラメータ決定手段で決定されたパラメータで特定される増加関数により、輻輳ウインドウサイズを増加させる。
これによって、輻輳ウインドウサイズ増加手段は、パケットロスがランダムロスであれば、少なくともパケットロス発生時の増加速度を落とすことなく、輻輳ウインドウサイズを増加させることができる。
【００２３】
また、請求項２に記載のパケット送信装置は、送達確認応答なしに送信可能なパケット数を示す輻輳ウインドウサイズを予め定めた増加関数によって増加させ、パケットロスが発生したときに前記輻輳ウインドウサイズを削減するウインドウ制御方式によってパケットを送信するパケット送信装置において、往復遅延時間計測手段と、輻輳ウインドウサイズ削減手段と、パケットロス原因判定手段と、増加関数パラメータ決定手段と、輻輳ウインドウサイズ増加手段と、を備える構成とした。
【００２４】
かかる構成において、パケット送信装置は、パケットロスが発生したときに、輻輳ウインドウサイズ削減手段によって、輻輳ウインドウサイズを削減する。ここで、輻輳ウインドウサイズ削減手段は、予め定めた割合で輻輳ウインドウサイズを削減したサイズと、ロス発生時の往復遅延時間に対する往復遅延時間の最小時間の割合を輻輳ウインドウサイズに乗算したサイズのうちで、大きい方のサイズを新たな輻輳ウインドウサイズとする。
これによって、輻輳ウインドウサイズ削減手段は、少なくとも往復遅延時間が増加した分に相当するデータ量以上、すなわち、ネットワーク上にバッファされているパケット量よりも、輻輳ウインドウサイズを削減することがないため、ネットワーク上の空きの発生を抑えることができる。
【００２５】
また、パケット送信装置は、パケットロス原因判定手段によって、往復遅延時間の増加量に応じてパケットロスの原因を判定する。ここで、パケットロス原因判定手段は、往復遅延時間の増加量が予め定めた基準よりも大きい場合に、パケットロスがネットワークの輻輳によって発生した輻輳ロスであると判定し、それ以外の場合に、パケットロスがランダムに発生するランダムロスであると判定する。
【００２６】
そして、パケット送信装置は、増加関数パラメータ決定手段によって、輻輳ウインドウサイズを増加させる増加関数のパラメータを決定する。
ここで、増加関数パラメータ決定手段は、輻輳ウインドウサイズの増加速度を初期化した関数となるように第１増加関数のパラメータを決定する。
【００２７】
また、増加関数パラメータ決定手段は、パケットロスが輻輳ロスと判定された場合に、輻輳ウインドウサイズの増加速度を初期化し、パケットロスがランダムロスと判定された場合に、輻輳ウインドウサイズの増加速度がパケットロス発生時から継続して増加する関数となるように第２増加関数のパラメータを決定する。
【００２８】
そして、パケット送信装置は、輻輳ウインドウサイズ増加手段によって、送達確認応答を受信するたびに、輻輳ウインドウサイズを増加させる。ここで、輻輳ウインドウサイズ増加手段は、増加関数パラメータ決定手段で決定されたパラメータで特定される第１増加関数および第２増加関数により演算される輻輳ウインドウサイズのうちで、大きい方のサイズを新たな輻輳ウインドウサイズとする。
これによって、輻輳ウインドウサイズ増加手段は、パケットロスがランダムロスであれば、少なくともパケットロス発生時の増加速度を落とすことなく、輻輳ウインドウサイズを増加させることができる。
【００２９】
なお、請求項１または請求項２に記載のパケット送信装置は、パケット送信装置のコンピュータを、データ入力手段、データ送信手段、送達応答確認受信手段、フロー制御手段、往復遅延時間計測手段、輻輳ウインドウサイズ削減手段、パケットロス原因判定手段、増加関数パラメータ決定手段、輻輳ウインドウサイズ増加手段、として機能させるためのパケット送信プログラムで動作させることで実現することができる（請求項３，請求項４）。
【発明の効果】
【００３０】
本発明は、以下に示す優れた効果を奏するものである。
請求項１，３に記載の発明によれば、パケットロスが発生した場合でも、ネットワーク上にバッファされているパケット量よりも、輻輳ウインドウサイズを削減することがないため、ネットワーク上の空きの発生を抑えることができる。これによって、狭帯域の回線であっても、効率よく回線を使用することができる。
また、請求項１，３に記載の発明によれば、パケットロスがランダムロスの場合、増加関数を初期化せず、パケットロス発生時における輻輳ウインドウサイズの増加速度から、増加速度を再開させるため、輻輳ウインドウサイズの増加速度を早めることができる。これによって、広帯域の回線であっても、高速に回線状態に適した輻輳ウインドウサイズに到達し、回線を有効に使用することができる。
【００３１】
請求項２，４に記載の発明によれば、輻輳ウインドウサイズを削減する際に、往復遅延時間に基づいて求められる輻輳ウインドウサイズよりも、予め定めた割合で削減した方が、輻輳ウインドウサイズが大きければ、それを適用し、輻輳ウインドウサイズを増加させる際に、増加関数を初期化せずに演算した輻輳ウインドウサイズよりも、増加関数を初期化して演算した輻輳ウインドウサイズの方が大きければ、それを適用するため、請求項１，３の効果に加え、従来の手法で制御した輻輳ウインドウサイズを下回ることがなく、効率的に回線を使用することができる。
【図面の簡単な説明】
【００３２】
【図１】本発明の実施形態に係るパケット送信装置の構成を示すブロック構成図である。
【図２】図１の輻輳ウインドウサイズ増加手段が用いるＣＷＮＤの増加関数を説明するためのグラフ図である。
【図３】図１の増加関数パラメータ決定手段が決定するパラメータで特定される第２増加関数を説明するためのグラフ図である。
【図４】図１の輻輳ウインドウサイズ増加手段が第１増加関数および第２増加関数のいずれを適用するのかを説明するためのグラフ図である。
【図５】図１の輻輳ウインドウサイズ増加手段が第１増加関数および第２増加関数のいずれを適用するのかを説明するためのグラフ図である。
【図６】本発明の実施形態に係るパケット送信装置のＣＷＮＤの削減処理動作を示すフローチャートである。
【図７】本発明の実施形態に係るパケット送信装置のＣＷＮＤの増加処理動作を示すフローチャートである。
【図８】参考例の実施形態に係るパケット受信装置の構成を示すブロック構成図である。
【発明を実施するための形態】
【００３３】
以下、本発明の実施形態について図面を参照して説明する。
〔パケット送信装置の構成〕
まず、図１を参照して、本発明の実施形態に係るパケット送信装置１の構成について説明する。
【００３４】
パケット送信装置１は、図示を省略したデータ送信装置等から入力されたデータ（パケットデータ）を、ウインドウ制御方式によって、そのデータ送信量を制御して、パケット受信装置２に送信するものである。このパケット送信装置１は、パケット受信装置２との間で、送達確認応答なしに送出可能なパケットの数（セグメント数）である輻輳ウインドウサイズ（ＣＷＮＤ：Congestion Window Size、以下、単にＣＷＮＤという。）を制御し、そのＣＷＮＤに応じてフロー制御を行うことで、送信するパケット数（量）を調整する。
ここでは、パケット送信装置１は、図１に示すように、データ入力手段１０と、データバッファ（一時記憶手段）１１と、フロー制御手段１２と、データ送信手段１３と、送達確認応答受信手段１４と、往復遅延時間計測手段１５と、輻輳制御手段１６と、を備える。
【００３５】
データ入力手段１０は、外部からパケット受信装置２に送信するためのデータ（パケットデータ）を入力するものである。このパケットデータは、例えば、ＩＰパケットである。このデータ入力手段１０は、入力されたパケットを逐次データバッファ１１に記憶するとともに、フロー制御手段１２に対して、パケットを入力した旨の通知を行う。
【００３６】
データバッファ（一時記憶手段）１１は、データ入力手段１０を介して入力されたパケットデータを一時的に記憶しておくもので、例えば、半導体メモリ等の記憶媒体である。このデータバッファ１１に記憶されたパケットデータは、データ送信手段１３によって読み出され、データバッファ１１は、ＦＩＦＯ（First-In First-Out）として機能する。
【００３７】
フロー制御手段１２は、輻輳制御手段１６によって制御されるＣＷＮＤに応じて、フロー制御を行うものである。すなわち、フロー制御手段１２は、一般的なウインドウ制御方式によって、データ送信手段１３から送信するパケット数を制御する。
【００３８】
具体的には、フロー制御手段１２は、データ入力手段１０を介してデータバッファ１１に記憶されたパケットを、データ送信手段１３に対して送信する旨を指示する。そして、フロー制御手段１２は、送達確認応答受信手段１４から、送信したパケットに対する送達確認応答（ＡＣＫ）を受信した段階で、データバッファ１１における次に送信すべきパケットの送信番号を更新する。このとき、フロー制御手段１２は、輻輳制御手段１６から通知されるＣＷＮＤのパケット数までは、ＡＣＫを受信することなく一度に、データ送信手段１３に対して送信を指示することができる。
このように、フロー制御手段１２は、輻輳制御手段１６によって制御されるＣＷＮＤによって、一度にパケット受信装置２に送信するパケット数を制御する。
なお、フロー制御手段１２は、送信したパケットに対するＡＣＫが所定時間内に受信されない場合（再送タイムアウト）、当該パケットを再送するとともに、再送タイムアウトが発生したことを、輻輳制御手段１６に通知する。
【００３９】
データ送信手段１３は、フロー制御手段１２の指示により、データバッファ１１に記憶されているパケットを、通信回線を介して、パケット受信装置２に送信するものである。なお、パケットデータには、パケットの宛先が記述されており、データ送信手段１３は、その宛先に対してパケットを送信する。例えば、パケットが、ＩＰパケットの場合、ＩＰヘッダに宛先のＩＰアドレスが記述されている。
【００４０】
送達確認応答受信手段１４は、データ送信手段１３を介して送信されたパケットに対応する送達確認応答（ＡＣＫ）を、送信先のパケット受信装置２から、通信回線を介して、受信するものである。この送達確認応答受信手段１４は、ＡＣＫを受信したことをフロー制御手段１２、往復遅延時間計測手段１５および輻輳制御手段１６に通知（ＡＣＫ受信通知）する。
【００４１】
また、送達確認応答受信手段１４は、データ送信手段１３から順次送信されたパケットに対するＡＣＫが欠落した場合、その旨（パケットロス通知）を、輻輳制御手段１６に通知する。なお、パケットロスの検出は、例えば、同一シーケンス番号のＡＣＫを３つ連続して受信した場合にロスが発生したとみなす等の一般的な手法により行うことができる。
【００４２】
往復遅延時間計測手段１５は、パケットの送信時刻と、当該パケットに対するＡＣＫの受信時刻との差であるパケットの往復遅延時間（ＲＴＴ）を計測するものである。この往復遅延時間計測手段１５は、計測したＲＴＴを輻輳制御手段１６に出力する。
このＲＴＴの計測は、一般的な手法を用いればよく、例えば、往復遅延時間計測手段１５は、データ送信手段１３からパケットの送信時刻を取得し、当該パケットに対するＡＣＫの受信時刻との差を演算することで、ＲＴＴを求めることができる。あるいは、データ送信手段１３が、送信パケットのヘッダに予め送信時刻を書き込み、送達確認応答受信手段１４が、当該送信時刻がコピーされたＡＣＫを受信することで、ＲＴＴを計測することとしてもよい。
【００４３】
なお、往復遅延時間計測手段１５は、計測するＲＴＴ（ＲＴＴｎｏｗ）については、予め定めた時間内で平滑化することとする。また、ＲＴＴｎｏｗ以外にも、往復遅延時間計測手段１５は、計測中のＲＴＴの最小値（ＲＴＴｍｉｎ）や、予め定めた時間内のＲＴＴのジッタ移動平均（ＲＴＴｖａｒ）も計測することとする。
【００４４】
輻輳制御手段１６は、ネットワークの輻輳状態を検出し、その輻輳状態に応じてフロー制御手段１２がフロー制御を行う際の輻輳ウインドウサイズ（ＣＷＮＤ）を制御するものである。この輻輳制御手段１６は、ＣＷＮＤを指数的に増加させるスロースタートフェーズと、輻輳を考慮してＣＷＮＤを増加させる輻輳制御フェーズとの２つのフェーズで動作する。なお、スロースタートフェーズについては、一般的なＴＣＰの動作と同様であるため、以降の説明においては説明を簡略化する。
【００４５】
この輻輳制御手段１６は、輻輳ウインドウサイズ削減手段１６０と、パケットロス原因判定手段１６１と、輻輳ウインドウサイズ増加手段１６２と、増加関数パラメータ決定手段１６３と、を備える。
【００４６】
輻輳ウインドウサイズ削減手段１６０は、送達確認応答受信手段１４から、パケットロスが発生した旨（パケットロス通知）を通知された段階で、ＣＷＮＤを削減するものである。この輻輳ウインドウサイズ削減手段１６０は、削減したＣＷＮＤをフロー制御手段１２に出力する。
具体的には、輻輳ウインドウサイズ削減手段１６０は、以下の式（１）により、新たなＣＷＮＤ（ＣＷＮＤｎｅｗ）を算出する。
【００４７】
【数１】
2014090367.tif 000003
【００４８】
この式（１）において、「ＣＷＮＤｌｏｓｓ＊（１−β）」は、従来のＣＵＢＩＣと同様、予め定めた割合でＣＷＮＤを削減するための計算式である。ここで、ＣＷＮＤｌｏｓｓは、パケットロスが発生した時点のＣＷＮＤである。また、（１−β）は、予め定めた割合であって、βは、例えば、“０．３”である。
【００４９】
一方、式（１）において、「ＣＷＮＤｌｏｓｓ＊ＲＴＴｍｉｎ／ＲＴＴｎｏｗ」は、ネットワーク上にバッファされたパケットのデータ量に応じてＣＷＮＤを削減するための計算式である。ここで、ＣＷＮＤｌｏｓｓは、パケットロスが発生した時点のＣＷＮＤである。また、ＲＴＴｍｉｎは、往復遅延時間計測手段１５で計測されたＲＴＴの中で最小のＲＴＴである。また、ＲＴＴｎｏｗは、パケットロスが発生した時点の平滑化したＲＴＴである。
【００５０】
すなわち、輻輳ウインドウサイズ削減手段１６０は、ＣＵＢＩＣのように、単に、予め定めた割合でＣＷＮＤを削減するのではなく、ＲＴＴの増加比の逆比に応じて削減したＣＷＮＤの方が、予め定めた割合で削減したＣＷＮＤよりも大きければ、大きい値を採用する。
これによって、輻輳ウインドウサイズ削減手段１６０は、ネットワーク上にバッファされているパケット量よりも、ＣＷＮＤを削減しないため、パケット送信装置１とパケット受信装置２との間のネットワーク内のバッファが少ない回線であっても、ネットワークの空きの発生を抑え、ネットワークを有効に利用することが可能になる。
【００５１】
また、輻輳ウインドウサイズ削減手段１６０は、パケットロスが通知された場合、スロースタートフェーズに移行した場合のＣＷＮＤの上限値を示すスロースタート閾値であるｓｓｔｈｒｅｓｈ（ｓｓｔｈｒｅｓｈｎｅｗ）を、以下の式（２）に示すように、式（１）で演算されたＣＷＮＤｎｅｗで更新する。
【００５２】
【数２】
2014090367.tif 000004
【００５３】
この輻輳ウインドウサイズ削減手段１６０は、更新前のＣＷＮＤ（ＣＷＮＤｌｏｓｓ）と更新後のＣＷＮＤ（ＣＷＮＤｎｅｗ）とを、増加関数パラメータ決定手段１６３に出力する。また、輻輳ウインドウサイズ削減手段１６０は、更新後のｓｓｔｈｒｅｓｈｎｅｗを、輻輳ウインドウサイズ増加手段１６２に出力する。
【００５４】
パケットロス原因判定手段１６１は、送達確認応答受信手段１４から、パケットロスが発生した旨（パケットロス通知）を通知された段階で、パケットロスの原因を判定するものである。ここでは、パケットロス原因判定手段１６１は、往復遅延時間計測手段１５で計測されるＲＴＴの増加が大きい場合、輻輳によりパケットロスが発生したと判定し、増加が小さい場合、ランダムロスによりパケットロスが発生したと判定する。
具体的には、パケットロス原因判定手段１６１は、以下の式（３）の大小関係により、パケットロスの原因を判定する。
【００５５】
【数３】
2014090367.tif 000005
【００５６】
ここで、式（３）の左辺は、往復遅延時間計測手段１５で計測されるＲＴＴのジッタ移動平均ＲＴＴｖａｒ（より正確には、その定数倍）である。この式（３）において、αは予め定めた定数（例えば、α＝４）である。
【００５７】
また、式（３）の右辺は、ＲＴＴの遅延増加量を表している。この式（３）において、ＲＴＴｎｏｗは、パケットロスが発生した時点のＲＴＴである。また、ＲＴＴｍｉｎは、計測されたＲＴＴの最小値である。
すなわち、パケットロス原因判定手段１６１は、式（３）の左辺で演算した値を基準として、式（３）の右辺で演算したＲＴＴの遅延増加量の方が大きければ、ネットワーク全体に影響のある輻輳によってパケットのロス（輻輳ロス）が発生したと判定する。また、その逆に、パケットロス原因判定手段１６１は、式（３）の右辺で演算したＲＴＴの遅延増加量が式（３）の左辺で演算した値以下であれば、単発でパケットのロス（ランダムロス）が発生したと判定する。このパケットロス原因判定手段１６１は、パケットロスの原因の判定結果を増加関数パラメータ決定手段１６３に出力する。
【００５８】
輻輳ウインドウサイズ増加手段１６２は、送達確認応答受信手段１４から、ＡＣＫを受信した旨（ＡＣＫ受信通知）を通知された段階で、ＣＷＮＤを増加させるものである。
この輻輳ウインドウサイズ増加手段１６２は、スロースタートフェーズにおいて、ＣＷＮＤに“２”を設定し、ＡＣＫ受信通知を通知されるたびに、ＣＷＮＤに“１”を加算して、フロー制御手段１２にＣＷＮＤを出力する。
そして、送達確認応答受信手段１４からパケットロスが発生した旨（パケットロス通知）を通知された段階で、輻輳回避フェーズに移行する。
【００５９】
この輻輳回避フェーズにおいて、輻輳ウインドウサイズ増加手段１６２は、予め定めたＣＷＮＤの増加関数を用いて、ＣＷＮＤの値を演算し、フロー制御手段１２に出力する。この増加関数は、１つの変曲点を有する３次関数である。ここでは、増加関数は、パケットロスが発生したときのＣＷＮＤで変曲点に達する３次関数とする。これによって、輻輳ウインドウサイズ増加手段１６２は、増加関数の変曲点、すなわち、前回のパケットロスが発生した際のＣＷＮＤまでは素早く回復させ、増加がほとんどない水平状態をある程度維持した後、再度、ＣＷＮＤを増加させる。
具体的には、輻輳ウインドウサイズ増加手段１６２は、ＣＷＮＤの値として、以下の式（４）に示すように２つの増加関数の演算結果で大きい方を適用する。
【００６０】
【数４】
2014090367.tif 000006
【００６１】
この式（４）において、「Ｃ＊（ｔ−ｋ）３＋Ｗｍａｘ」は、従来のＣＵＢＩＣと同様、経過時間ｔの３乗に比例してＣＷＮＤを増加させるための増加関数（以下、第１増加関数という。）である。ここで、Ｃは、予め定めた定数で、例えば、“０．４”である。また、ｔは、前回パケットロスが発生したときからの経過時間である。また、Ｗｍａｘは前回パケットロスが発生したときのＣＷＮＤの値である。また、ｋは、一旦削減されたＣＷＮＤをＷｍａｘまで増加させるための時間幅を示す。ここでは、Ｗｍａｘ，ｋは、増加関数パラメータ決定手段１６３で決定される。
これによって、第１増加関数「Ｃ＊（ｔ−ｋ）３＋Ｗｍａｘ」のグラフ形状は、図２に示したような関数形となる。すなわち、第１増加関数は、パケットロスが発生した時刻ｔ１から、時間がｋ経過（時刻ｔｐ）するまでにおいて、ＣＷＮＤを、前回のパケットロスが発生したＣＷＮＤ（Ｗｍａｘ）になるように素早く回復させ、増加関数の変曲点の後、さらにＣＷＮＤを増加させるような関数となる。
【００６２】
一方、前記式（４）において、「Ｃ＊（ｔ−ｎ＋Ｇ）３＋Ｗｄｉｆｆ」は、基本的にはＣＵＢＩＣと同様の増加関数であるが、パケットロスがランダムロスである場合に、パケットロスが発生した際のＣＷＮＤの増加速度を継続して再開させる関数（以下、第２増加関数という。）となる。この第２増加関数における第１増加関数と異なるパラメータであるＷｄｉｆｆ，Ｇ，ｎは、増加関数パラメータ決定手段１６３で決定された値であり、その内容については、後記する増加関数パラメータ決定手段１６３の説明で行うこととする。
【００６３】
なお、輻輳ウインドウサイズ増加手段１６２は、フロー制御手段１２から、再送タイムアウトが通知された場合、スロースタートフェーズに移行する。すなわち、輻輳ウインドウサイズ増加手段１６２は、再送タイムアウトが通知された場合、ＣＷＮＤを“２”に設定し、ＡＣＫ受信通知を通知されるたびに、ＣＷＮＤに“１”を加算し、フロー制御手段１２にＣＷＮＤを出力する。そして、輻輳ウインドウサイズ増加手段１６２は、ＣＷＮＤがｓｓｔｈｒｅｓｈに達した段階、あるいは、パケットロスが発生した段階で、輻輳制御フェーズに移行する。
【００６４】
増加関数パラメータ決定手段１６３は、パケットロス原因判定手段１６１で判定されたパケットロスの判定結果に基づいて、輻輳ウインドウサイズ増加手段１６２で使用する増加関数（前記式（４）参照）のパラメータを決定するものである。この増加関数パラメータ決定手段１６３は、式（４）の第１増加関数のパラメータであるＷｍａｘ，ｋと、第２増加関数のパラメータであるＷｄｉｆｆ，Ｇ，ｎを決定する。
なお、増加関数パラメータ決定手段１６３は、パケットロスの判定結果に関わらず、以下の式（５）に示すように、第１増加関数のパラメータであるＷｍａｘ（Ｗｍａｘ＿ｎｅｗ）、ｋ（ｋｎｅｗ）を更新する。
【００６５】
【数５】
2014090367.tif 000007
【００６６】
ここで、ＣＷＮＤｌｏｓｓは、輻輳ウインドウサイズ削減手段１６０から通知されるパケットロス発生時のＣＷＮＤである。また、βは、予め定めた定数であって、例えば、“０．３”である。また、Ｃは、予め定めた定数で、例えば、“０．４”である。
これによって、第１増加関数におけるＣＷＮＤの増加速度は初期化されることになる。
【００６７】
また、増加関数パラメータ決定手段１６３は、第２増加関数のパラメータについては、パケットロス原因判定手段１６１から通知される判定結果に基づいて、異なる値とする。具体的には、増加関数パラメータ決定手段１６３は、パケットロス原因判定手段１６１から、ランダムロスが通知された場合、以下の式（６）に示すように、第２増加関数のパラメータであるＷｄｉｆｆ（Ｗｄｉｆｆ＿ｎｅｗ），Ｇ（Ｇｎｅｗ），ｎ（ｎｎｅｗ）を決定する。
【００６８】
【数６】
2014090367.tif 000008
【００６９】
ここで、Ｗｄｉｆｆ＿ｌａｓｔは、直近のパケットロスが発生した際の第２増加関数の変曲点におけるＣＷＮＤ（Ｗｄｉｆｆ）である。また、ＣＷＮＤｌｏｓｓおよびＣＷＮＤｎｅｗは、それぞれ、輻輳ウインドウサイズ削減手段１６０から通知されるパケットロス発生時のＣＷＮＤおよび更新後のＣＷＮＤである。また、ｔｌａｓｔは、パケットロス発生時のｔ、つまり前回のパケットロスから今回のパケットロスが発生するまでの経過時間である。また、ｎｌｏｓｓ、Ｇｌｏｓｓは、直近のパケットロスが発生した際のパラメータｎ，Ｇである。
なお、スロースタートフェーズから輻輳回避フェーズへ移行した際は、必ず第１増加関数によるＣＷＮＤ計算が実施される。
このように、増加関数パラメータ決定手段１６３は、図３に示すように、第２増加関数Ｌ２において経過時間ｔ１でランダムロスが発生したとすると、ＣＷＮＤの減少分（ＣＷＮＤｌｏｓｓ−ＣＷＮＤｎｅｗ）だけ、Ｗｄｉｆｆを減少させるとともに、経過時間ｔ１以降において、第２増加関数Ｌ２と同様の傾き（増加速度）でＣＷＮＤを継続して増加させる第２増加関数Ｌ２′のパラメータを生成する。
【００７０】
一方、増加関数パラメータ決定手段１６３は、パケットロス原因判定手段１６１から、輻輳ロスが通知された場合、以下の式（７）に示すように、第２増加関数のパラメータであるＷｄｉｆｆ（Ｗｄｉｆｆ＿ｎｅｗ），Ｇ（Ｇｎｅｗ），ｎ（ｎｎｅｗ）を初期化する。
【００７１】
【数７】
2014090367.tif 000009
【００７２】
ここで、ＣＷＮＤｌｏｓｓは、輻輳ウインドウサイズ削減手段１６０から通知されるパケットロス発生時のＣＷＮＤである。また、βは、予め定めた定数であって、例えば、“０．３”である。また、Ｃは、予め定めた定数で、例えば、“０．４”である。
これによって、第２増加関数におけるＣＷＮＤの増加速度は初期化されることになる。
この式（７）に示すように、パケットロス原因判定手段１６１から、輻輳ロスが通知された場合、第２増加関数のパラメータの値は、式（５）に示した第１増加関数のパラメータの値と同じになり、第１増加関数の値および第２増加関数の値は同一となる。
このように、増加関数パラメータ決定手段１６３は、輻輳ウインドウサイズ増加手段１６２が用いる増加関数（第１増加関数、第２増加関数）のパラメータを生成する。
【００７３】
以上説明したようにパケット送信装置１を構成することで、パケット送信装置１は、パケットロス発生時におけるＣＷＮＤの削減量を抑えるとともに、ＣＷＮＤを高速に回線状態に適したサイズに増加させることができる。
すなわち、パケット送信装置１は、輻輳ウインドウサイズ削減手段１６０によって、パケットロス発生時おいて、式（１）に示すように、予め定めた割合でＣＷＮＤを削減したＣＷＮＤと、ＲＴＴの増加比の逆比に応じて削減したＣＷＮＤとで、大きい方のＣＷＮＤを採用するため、バッファが少ない回線であっても、ネットワークの空きの発生を抑え、ネットワークを有効に利用することができる。
【００７４】
また、パケット送信装置１は、輻輳ウインドウサイズ増加手段１６２によって、パケットロス発生時に、ＣＷＮＤ削減後、式（４）に示すように、ＣＷＮＤの増加速度を初期化した増加関数（第１増加関数）と、ＣＷＮＤの増加速度を継続して再開させた増加関数（第２増加関数）とで、ＣＷＮＤが大きい方の関数を適用してＣＷＮＤを増加させるため、ＣＷＮＤを高速に増加させることができる。
例えば、輻輳ウインドウサイズ増加手段１６２は、図４に示すように、増加関数の変曲点後、高速にＣＷＮＤを増加させている段階（経過時間ｔ１）でランダムロスが発生した場合、増加速度を初期化した増加関数である第１増加関数Ｌ１よりも、増加速度を継続して再開させた第２増加関数Ｌ２を適用することで、ＣＷＮＤを高速に増加させることができる。
【００７５】
また、例えば、輻輳ウインドウサイズ増加手段１６２は、図５に示すように、経過時間ｔ１でランダムロスが発生し、経過時間ｔ１から経過時間ｔ２の間、第１増加関数Ｌ１の方が第２増加関数Ｌ２よりもＣＷＮＤが大きくなる場合、第１増加関数で演算されたＣＷＮＤを採用し、経過時間ｔ２以降、第２増加関数Ｌ２の方が第１増加関数Ｌ１よりもＣＷＮＤが大きくなる場合、第２増加関数で演算されたＣＷＮＤを採用する。そのため、パケット送信装置１は、従来のＣＵＢＩＣのように、単に、増加関数Ｌ１のみでＣＷＮＤを増加させるよりも高速にＣＷＮＤを増加させることができる。
【００７６】
以上、パケット送信装置１の構成について説明したが、パケット送信装置１は、コンピュータを、前記した各手段として機能させるためのプログラム（パケット送信プログラム）で動作させることができる。
【００７７】
〔パケット送信装置の動作〕
次に、図６および図７を参照（構成については適宜図１参照）して、本発明の実施形態に係るパケット送信装置１の動作について説明する。
なお、パケット送信装置１におけるフロー制御や、輻輳制御におけるスロースタートフェーズの動作については、一般的なものであるため、ここでは、本発明の特徴である輻輳制御アルゴリズムにおける輻輳制御フェーズの動作、特に、ＣＷＮＤを制御する動作について説明する。
図６は、送達確認応答受信手段１４によって、パケットロスが検出された際のＣＷＮＤの削減処理を示す。また、図７は、送達確認応答受信手段１４によって、ＡＣＫを受信した際のＣＷＮＤの増加処理を示す。
【００７８】
（パケットロス検出に伴うＣＷＮＤ削減処理）
図６に示すように、パケット送信装置１は、送達確認応答受信手段１４においてパケットロスが検出されると（ステップＳ１）、輻輳制御手段１６の輻輳ウインドウサイズ削減手段１６０によって、ＣＷＮＤを削減する（ステップＳ２）。
このステップＳ２では、輻輳ウインドウサイズ削減手段１６０は、式（１）に示すように、予め定めた割合でＣＷＮＤを削減した場合（ＣＷＮＤｌｏｓｓ＊（１−β））と、往復遅延時間計測手段１５で計測されたＲＴＴを用いて、ネットワーク上にバッファされたパケットのデータ量に応じてＣＷＮＤを削減した場合（ＣＷＮＤｌｏｓｓ＊ＲＴＴｍｉｎ／ＲＴＴｎｏｗ）とで、大きい方のＣＷＮＤを採用する。
これによって、ネットワークの空きの発生を抑え、ネットワークを有効に利用することができる。
【００７９】
その後、パケット送信装置１は、輻輳制御手段１６のパケットロス原因判定手段１６１によって、ＲＴＴの増加量に基づいて、パケットロスの原因がランダムロスであるのか、輻輳ロスであるのかを判定する（ステップＳ３）。
このステップＳ３では、パケットロス原因判定手段１６１は、式（３）の左辺に示した往復遅延時間計測手段１５で計測されるＲＴＴのジッタ移動平均の定数倍（α＊ＲＴＴｖａｒ）よりも、式（３）の右辺に示したＲＴＴの遅延増加量（ＲＴＴｎｏｗ−ＲＴＴｍｉｎ）の方が大きい場合に、パケットロスが輻輳によって発生した輻輳ロスであると判定する。
また、パケットロス原因判定手段１６１は、ＲＴＴのジッタ移動平均の定数倍（α＊ＲＴＴｖａｒ）が、ＲＴＴの遅延増加量（ＲＴＴｎｏｗ−ＲＴＴｍｉｎ）以上であれば、パケットロスがランダムロスであると判定する。
【００８０】
ここで、パケットロスが輻輳ロスであると判定された場合（ステップＳ３でＹｅｓ）、パケット送信装置１は、輻輳制御手段１６の増加関数パラメータ決定手段１６３によって、輻輳ウインドウサイズ増加手段１６２で用いる増加関数（第１増加関数、第２増加関数）について、輻輳ロス用のパラメータを決定する（ステップＳ４）。
このステップＳ４では、増加関数パラメータ決定手段１６３は、式（５）によって、第１増加関数のパラメータであるＷｍａｘ，ｋを決定する。さらに、増加関数パラメータ決定手段１６３は、式（７）によって、第２増加関数のパラメータであるＷｄｉｆｆ，Ｇ，ｎを決定する。
【００８１】
一方、パケットロスがランダムロスであると判定された場合（ステップＳ３でＮｏ）、パケット送信装置１は、輻輳制御手段１６の増加関数パラメータ決定手段１６３によって、輻輳ウインドウサイズ増加手段１６２で用いる増加関数（第１増加関数、第２増加関数）について、ランダムロス用のパラメータを決定する（ステップＳ５）。
このステップＳ５では、増加関数パラメータ決定手段１６３は、式（５）によって、第１増加関数のパラメータであるＷｍａｘ，ｋを決定する。さらに、増加関数パラメータ決定手段１６３は、式（６）によって、第２増加関数のパラメータであるＷｄｉｆｆ，Ｇ，ｎを決定する。
この第２増加関数のパラメータによって、第２増加関数において、ＣＷＮＤの増加速度を再開し、継続してＣＷＮＤを増加させることができる。
以上の動作によって、輻輳制御手段１６は、パケットロスが検出された際のＣＷＮＤの削減処理を行う。
【００８２】
（ＡＣＫ受信に伴うＣＷＮＤ増加処理）
一方、図７に示すように、パケット送信装置１は、送達確認応答受信手段１４においてＡＣＫが受信されると（ステップＳ１０）、輻輳制御手段１６の輻輳ウインドウサイズ増加手段１６２によって、ＣＷＮＤを増加させる（ステップＳ１１）。
このステップＳ１１では、輻輳ウインドウサイズ増加手段１６２は、式（４）に示すように、図６のステップＳ４またはステップＳ５で決定されたパラメータで特定される第１増加関数および第２増加関数で、ＣＷＮＤを演算し、大きい方のＣＷＮＤを採用する。
【００８３】
図６および図７で説明したように、パケット送信装置１は、輻輳制御手段１６によって、逐次、ＣＷＮＤの増減制御を行う。そして、このように制御されたＣＷＮＤに基づいて、フロー制御手段１２が、パケットのウインドウ制御方式に基づくフロー制御を行う。
【００８４】
以上、本発明の実施形態に係るパケット送信装置１の構成および動作について説明したが、本発明はこの実施形態に限定されるものではない。
例えば、ここでは、輻輳ウインドウサイズ削減手段１６０は、式（１）により、「ＣＷＮＤｌｏｓｓ＊（１−β）」または「ＣＷＮＤｌｏｓｓ＊ＲＴＴｍｉｎ／ＲＴＴｎｏｗ」の大きい方を、新たなＣＷＮＤとしたが、「ＣＷＮＤｌｏｓｓ＊ＲＴＴｍｉｎ／ＲＴＴｎｏｗ」のみを用いて、新たなＣＷＮＤを求めることとしてもよい。
少なくとも、輻輳ウインドウサイズ削減手段１６０は、ＲＴＴの増加比の逆比に応じて削減したＣＷＮＤを採用することで、ネットワークの空きの発生を抑え、ネットワークを有効に利用することが可能になる。
【００８５】
また、ここでは、輻輳ウインドウサイズ増加手段１６２は、式（４）により、第１増加関数「Ｃ＊（ｔ−ｋ）３＋Ｗｍａｘ」と、第２増加関数「Ｃ＊（ｔ−ｎ＋Ｇ）３＋Ｗｄｉｆｆ」とで、演算結果が大きい方のＣＷＮＤを新たなＣＷＮＤとしたが、第１増加関数を用いずに、第２増加関数の演算結果のみを用いて新たなＣＷＮＤとしてもよい。
少なくとも、輻輳ウインドウサイズ増加手段１６２は、第２増加関数のみを用いることで、例えば、図５に示した増加関数の変曲点の前でパケットロスが発生した場合、従来のＣＵＢＩＣに比べてＣＷＮＤの増加は減少するが、その差は僅少である。それに比べ、図４に示した高速にＣＷＮＤが増加していく途中でパケットロスが発生した場合、パケットロス時点の増加速度を保って、高速にＣＷＮＤを増加させることができる。これによって、従来のＣＵＢＩＣに比べてＣＷＮＤを高速に増加させることができる。
【００８６】
以上、本発明の実施形態や変形例に係るパケット送信装置１について説明したが、パケット送信装置１が送信するパケットデータを受信するパケット受信装置２については、一般的な装置を用いることができる。
【００８７】
〔パケット受信装置〕
ここで、図８を参照して、パケット送信装置１が送信するパケットデータを受信する一般的なパケット受信装置２について簡単に説明しておく。
パケット受信装置２は、データ受信手段２０と、データバッファ（一時記憶手段）２１と、データ出力手段２２と、フロー制御手段２３と、送達確認応答送信手段２４と、を備える。
【００８８】
データ受信手段２０は、通信回線を介して、パケット送信装置１から送信されるパケットデータを受信するものである。このデータ受信手段２０は、受信したパケットを逐次データバッファ２１に書き込むとともに、フロー制御手段２３に対して、パケットを受信した旨の通知を行う。
【００８９】
データバッファ（一時記憶手段）２１は、データ受信手段２０を介して受信されたパケットデータを一時的に記憶しておくもので、例えば、半導体メモリ等の記憶媒体である。このデータバッファ２１に記憶されたパケットデータは、データ出力手段２２によって読み出され、データバッファ２１は、ＦＩＦＯとして機能する。
【００９０】
データ出力手段２２は、データバッファ２１に記憶されているパケットを、順次読み出して外部に出力するものである。なお、データ出力手段２２は、パケットを読み出した旨をフロー制御手段２３に通知する。
【００９１】
フロー制御手段２３は、パケット送信装置１との間でフロー制御を行うものである。
このフロー制御手段２３は、データバッファ２１の容量で予め定めた最大パケット数（受信ウインドウサイズ）を管理し、データバッファ２１に記憶されるパケット数が、受信ウインドウサイズを超過しないように、フロー制御を行う。なお、データバッファ２１に記憶されるパケット数は、データ受信手段２０で受信されたパケットと、データ出力手段２２で出力されるパケットの数で把握することができる。
ここで、フロー制御手段２３は、データ受信手段２０が受信したパケットに対して、受信した旨と、次に受信すべきパケットを特定する情報を含んだ送達確認応答（ＡＣＫ）を送達確認応答送信手段２４に出力する。
【００９２】
送達確認応答送信手段２４は、フロー制御手段２３から出力される送達確認応答（ＡＣＫ）を、通信回線を介して、パケット送信装置１に送信するものである。
パケット送信装置１は、以上説明したように、一般的なパケット受信装置２に対して、パケットを送信する場合であっても、ネットワーク上の空きの発生を抑えることができ、帯域が狭くても、効率よくネットワークを使用することができる。また、ランダムロスが多発するようなネットワークであっても、高速にＣＷＮＤを増加させることができ、ネットワークを有効に使用することができる。
【符号の説明】
【００９３】
１      パケット送信装置
１０    データ入力手段
１１    データバッファ（一時記憶手段）
１２    フロー制御手段
１３    データ送信手段
１４    送達確認応答受信手段
１５    往復遅延時間計測手段
１６    輻輳制御手段
１６０  輻輳ウインドウサイズ削減手段
１６１  パケットロス原因判定手段
１６２  輻輳ウインドウサイズ増加手段
１６３  増加関数パラメータ決定手段
【図１】
2014090367.tif 000010
【図２】
2014090367.tif 000011
【図３】
2014090367.tif 000012
【図４】
2014090367.tif 000013
【図５】
2014090367.tif 000014
【図６】
2014090367.tif 000015
【図７】
2014090367.tif 000016
【図８】
2014090367.tif 000017