(57)【特許請求の範囲】
【請求項１】
ネットワークへ送出すべきパケット群のデータ量を規定したウインドに従い前記ネットワークにパケットを送信する送信部と、
前記ネットワークへ送信したパケットに対する受信確認通知を受信し且つパケット廃棄の有無を検知する受信部と、
前回パケット廃棄を検知した際の現在時刻と、今回パケット廃棄を検知した際の現在時刻との差分である第１のパケット廃棄間隔を、パケットの廃棄を検知するたびに計算する廃棄間隔計算部と、
前記受信部によりパケット廃棄が検知されない場合に、前記第１のパケット廃棄間隔と、前記受信部がパケット廃棄を検知しなかった際の現在時刻と前回パケット廃棄を検知した際の現在時刻との差分である第２のパケット廃棄間隔とを用いて現行のウインドに対する増加幅を決定し且つ当該増加幅を用いて前記現行のウインドを更新するウインド設定部とを備えることを特徴とする通信装置。
【請求項２】
前記廃棄間隔計算部は、パケット廃棄間隔の算出ごとに現時点までの前記第１のパケット廃棄間隔の平均値を計算し、
前記ウインド設定部は、ウインドの増加幅の倍率を規定するパラメータと、前記第１のパケット廃棄間隔の平均値および前記第２のパケット廃棄間隔のうちの大きいほうとの積により前記増加幅を算出することを特徴とする請求項１記載の通信装置。
【請求項３】
パケットの往復遅延時間を計測するＲＴＴ計測部を更に備え、
前記ウインド設定部は、前記ＲＴＴ計測部による計測値の減少関数を前記積の値に乗じることにより前記増加幅を算出することを特徴とする請求項２記載の通信装置。
【請求項４】
さらに、パケットの往復遅延時間を計測するＲＴＴ計測部の計測値が閾値以下であるか否かを判定するＲＴＴ判定部を備え、
前記廃棄間隔計算部は、前記ＲＴＴ計測部の計測値が閾値以下である間のパケット廃棄間隔である条件付きパケット廃棄間隔を算出し、且つ、前記算出ごとに現時点までの条件付きパケット廃棄間隔の平均値を算出し、
前記ウインド設定部は、前記受信部によりパケット廃棄が検知されない場合であって且つ前記ＲＴＴ計測部の計測値が閾値以下であるという条件を満たした場合には、ウインドの増加幅の倍率を規定するパラメータと、前記ＲＴＴ計測部による計測値の増加関数と、条件付きパケット廃棄間隔の最新値および平均値のうちの大きいほうとの積により前記増加幅を算出することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
【請求項５】
さらに、前記廃棄間隔計算部の計算値を用いてパケット廃棄間隔の期待値を計算する期待値計算部を備え、
前記ウインド設定部は、前記期待値計算部の計算値としてのＥを用いた（１−Ｅ）項を前記積に乗じることにより前記増加幅を算出することを特徴とする請求項４記載の通信装置。
【請求項６】
さらに、前記廃棄間隔計算部の計算値を用いてパケット廃棄間隔の期待値を計算する期待値計算部を備え、
前記ＲＴＴ計測部は、往復遅延時間の計測値に対する前記期待値の加算により前記計測値を補正し、
前記ウインド設定部は、前記補正した計測値を前記ＲＴＴ計測部による計測値として前記増加幅を算出することを特徴とする請求項４記載の通信装置。
【請求項７】
前記期待値計算部は、条件付きパケット廃棄間隔の平均値としてのｘと条件付きパケット廃棄間隔の最新値としてのｙとについての関数ｇ（ｘ,ｙ）であり、且つ、ｙ＝ｘのときに最大値をとる前記関数ｇ（ｘ,ｙ）により前記期待値を算出することを特徴とする請求項５又は６記載の通信装置。
【請求項８】
前記期待値計算部は、パケット廃棄間隔の平均値としてのｘとパケット廃棄間隔の最新値としてのｙとについての関数ｇ（ｘ,ｙ）であり、且つ、ｙ＝ｘのときに最大値をとる前記関数ｇ（ｘ,ｙ）により前記期待値を算出することを特徴とする請求項５又は６記載の通信装置。
【請求項９】
前記ウインド設定部は、前記（１−Ｅ）項を前記積に乗じた値から前記ＲＴＴ計測部による計測値であるパケット遅延時間に対する増加関数となる値を減算することにより前記増加幅を算出することを特徴とする請求項５、７及び８のいずれか１項に記載の通信装置。
【請求項１０】
パケット廃棄が検知された場合に現行の閾値を増加させ、パケット廃棄が検知されなかった場合に現行の閾値を減少させる、ことによって、現行のウインドに対する増加の度合いを変更するための閾値を設定する閾値設定部を更に備え、
前記ウインド設定部は、現行のウインドが前記閾値より大きい場合には前記廃棄間隔計算部による計算値を用いて現行のウインドに対する増加幅を決定し、
更に前記ウインド設定部は、前記現行のウインドが前記閾値より小さい場合には前記現行のウインドが前記閾値より大きい場合よりも大きな度合いで増加するように現行のウインドに対する増加幅を決定することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
【請求項１１】
前記ウインド設定部は、前記受信部によりパケット廃棄が検知された場合、前記ＲＴＴ計測部の計測値に基づく前記ネットワークの輻輳度を用いて現行のウインドを減少させるよう更新することを特徴とする請求項１乃至１０のいずれか１項に記載の通信装置。
【請求項１２】
コンピュータを請求項１乃至１１のいずれか１項に記載の通信装置として機能させることを特徴とするプログラム。
【請求項１３】
通信装置が行う通信方法であって、
前記通信装置が備える送信部が、ネットワークへ送出すべきパケット群のデータ量を規定したウインドに従い前記ネットワークにパケットを送信するステップと、
前記通信装置が備える受信部が、前記ネットワークへ送信したパケットに対する受信確認通知を受信し且つパケット廃棄の有無を検知するステップと、
前記通信装置が備える廃棄間隔計算部が、前回パケット廃棄を検知した際の現在時刻と、今回パケット廃棄を検知した際の現在時刻との差分である第１のパケット廃棄間隔を、パケットの廃棄を検知するたびに計算するステップと、
前記通信装置が備えるウインド設定部が、パケット廃棄が検知されない場合に、前記第１のパケット廃棄間隔と、前記受信部がパケット廃棄を検知しなかった際の現在時刻と前回パケット廃棄を検知した際の現在時刻との差分である第２のパケット廃棄間隔とを用いて現行のウインドに対する増加幅を決定し且つ当該増加幅を用いて前記現行のウインドを更新するステップとを備えることを特徴とする通信方法。
【請求項１４】
前記廃棄間隔計算部が、パケット廃棄間隔を計算する前記ステップにおいて、前記パケット廃棄間隔の算出ごとに現時点までの前記第１のパケット廃棄間隔の平均値を計算し、
前記ウインド設定部が、ウインドを更新する前記ステップにおいて、ウインドの増加幅の倍率を規定するパラメータと、前記第１のパケット廃棄間隔の平均値および前記第２のパケット廃棄間隔のうちの大きいほうとの積により前記増加幅を算出することを特徴とする請求項１３記載の通信方法。
【請求項１５】
前記通信装置が更に備えるＲＴＴ計測部が、パケットの往復遅延時間を計測するステップを更に備え、
前記ウインド設定部が、ウインドを更新する前記ステップにおいて、前記往復遅延時間の計測値の減少関数を前記積の値に乗じることにより前記増加幅を算出することを特徴とする請求項１４記載の通信方法。
【請求項１６】
前記通信装置が更に備えるＲＴＴ判定部が、前記往復遅延時間の計測値が閾値以下であるか否かを判定するステップを更に備え、
前記廃棄間隔計算部が、パケット廃棄間隔を計算する前記ステップにおいて、前記往復遅延時間の計測値が閾値以下である間のパケット廃棄間隔である条件付きパケット廃棄間隔を算出し、且つ、前記算出ごとに現時点までの条件付きパケット廃棄間隔の平均値を算出し、
前記ウインド設定部が、前記受信部によりパケット廃棄が検知されない場合であって且つ前記ＲＴＴ計測部の計測値が閾値以下であるという条件を満たした場合には、ウインドを更新する前記ステップにおいて、ウインドの増加幅の倍率を規定するパラメータと、前記往復遅延時間の計測値の増加関数と、条件付きパケット廃棄間隔の最新値および平均値のうちの大きいほうとの積により前記増加幅を算出することを特徴とする請求項１３乃至１５のいずれか１項に記載の通信方法。
【請求項１７】
前記通信装置が更に備える期待値計算部が、前記パケット廃棄間隔の計算値を用いてパケット廃棄間隔の期待値を計算するステップを更に備え、
前記ウインド設定部が、ウインドを更新する前記ステップにおいて、前記期待値の計算値としてのＥを用いた（１−Ｅ）項を前記積に乗じることにより前記増加幅を算出することを特徴とする請求項１６記載の通信方法。
【請求項１８】
前記通信装置が更に備える期待値計算部が、前記パケット廃棄間隔の計算値を用いてパケット廃棄間隔の期待値を計算するステップを更に備え、
前記ＲＴＴ計測部が、パケットの往復遅延時間を計測する前記ステップにおいて、往復遅延時間の計測値に対する前記期待値の加算により前記計測値を補正し、
前記ウインド設定部が、ウインドを更新する前記ステップにおいて、前記補正した計測値を前記往復遅延時間の計測値として前記増加幅を算出することを特徴とする請求項１６記載の通信方法。
【請求項１９】
前記期待値計算部が、パケット廃棄間隔の期待値を計算する前記ステップにおいて、条件付きパケット廃棄間隔の平均値としてのｘと条件付きパケット廃棄間隔の最新値としてのｙとについての関数ｇ（ｘ,ｙ）であり、且つ、ｙ＝ｘのときに最大値をとる前記関数ｇ（ｘ,ｙ）により前記期待値を算出することを特徴とする請求項１７又は１８記載の通信方法。
【請求項２０】
前記期待値計算部が、パケット廃棄間隔の期待値を計算する前記ステップにおいて、パケット廃棄間隔の平均値としてのｘとパケット廃棄間隔の最新値としてのｙとについての関数ｇ（ｘ,ｙ）であり、且つ、ｙ＝ｘのときに最大値をとる前記関数ｇ（ｘ,ｙ）により前記期待値を算出することを特徴とする請求項１７又は１８記載の通信方法。
【請求項２１】
前記ウインド設定部が、ウインドを更新する前記ステップにおいて、前記（１−Ｅ）項を前記積に乗じた値から前記ＲＴＴ計測部による計測値であるパケット遅延時間に対する増加関数となる値を減算することにより前記増加幅を算出することを特徴とする請求項１７、１９及び２０のいずれか１項に記載の通信方法。
【請求項２２】
前記通信装置が更に備える閾値設定部が、パケット廃棄が検知された場合に現行の閾値を増加させ、パケット廃棄が検知されなかった場合に現行の閾値を減少させる、ことによって、現行のウインドに対する増加の度合いを変更するための閾値を設定するステップを更に備え、
前記ウインド設定部が、ウインドを更新する前記ステップにおいて、現行のウインドが前記閾値より大きい場合には前記廃棄間隔計算部による計算値を用いて現行のウインドに対する増加幅を決定し、
更に前記ウインド設定部が、ウインドを更新する前記ステップにおいて、前記現行のウインドが前記閾値より小さい場合には前記現行のウインドが前記閾値より大きい場合よりも大きな度合いで増加するように現行のウインドに対する増加幅を決定することを特徴とする請求項１３乃至１５のいずれか１項に記載の通信方法。
【請求項２３】
前記ウインド設定部が、ウインドを更新する前記ステップにおいて、パケット廃棄が検知された場合、前記往復遅延時間の計測値に基づく前記ネットワークの輻輳度を用いて現行のウインドを減少させるよう更新することを特徴とする請求項１３乃至２２のいずれか１項に記載の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、TCP (Transmission Control Protocol)が適用されるネットワークにおける通信装置および通信方法に関し、特に、ネットワークの輻輳制御に用いるウインドを制御する技術に関する。
【背景技術】
【０００２】
インターネットにおけるデータ通信用の第四層プロトコルとして最も多く用いられているプロトコルにTCPがある。TCPを用いることにより、端末間で信頼性の高い通信、すなわち通信途中でデータを消失し難い通信を実現することが出来る。
【０００３】
また、TCPは輻輳制御機能を提供している。その輻輳制御において、送信側の装置は、ネットワークの輻輳状況に応じて自装置のウインドを適切に調整する。ネットワークに輻輳がない場合は、ウインドを大きく設定することで送信帯域を増加させ、ネットワークが輻輳している場合にはウインドを小さく設定することで送信帯域を減少させる。
【０００４】
輻輳ウインドの制御方法として、一般的には、パケットロスの検出に基づくAIMD (Additive Increase Multiple Decrease)方式が広く用いられている。このAIMD方式を用いた輻輳制御の方式として、後述の非特許文献１に記載されている「TCP-Reno」がある。AIMD方式では、パケット廃棄が無いときにはウインドサイズが線形に増加され、パケット廃棄が発生した際には、輻輳ウインドの値に１以下の所定値を乗じることでウインドサイズが減少される。
【０００５】
しかしながら、上記のAIMD方式では、通信の高速性と公平性との両立が難しいという問題がある。そこで、ネットワークのより詳細な輻輳度合いの指標としての往復遅延時間（以下、「RTT」（Round Trip Time）と称す。）を用いて輻輳ウインドを制御する方式が提案されている。
【０００６】
RTTを用いた輻輳制御の方式としては、後述の非特許文献２に記載されている「TCP-Vegas」や、非特許文献３に記載の「FAST」などがある。これらの方式は、ネットワーク内のノードに滞留しているフローのパケット量をRTTから推定し、滞留するパケット量を一定に保つように輻輳ウインドサイズを制御するというものである。また、「TCP-Vegas」や「FAST」を拡張したものとして、特許文献１に記載の「Compound-TCP」がある。この方式は、RTTを基に計算される輻輳ウインドサイズと、AIMD制御において計算される輻輳ウインドサイズとを合計したものを通信に適用するというものである。
【０００７】
RTTとAIMD制御とを組み合わせた方法としては、特許文献２に開示されているものや、非特許文献４に記載の「TCP-Illinois」がある。これらの方式では、パケット廃棄の直前に測定したRTT値をそれまでの最小のRTT値と比較し、測定値が最小値に近い場合には輻輳ウインドの増加幅を大きくし、そうでなければ輻輳ウインドの増加幅を小さくするか或いは負の値に設定する。これにより、RTTが短い、すなわちネットワークが混雑していないと判断された場合には、より高速に輻輳ウインドを増加させるAIMD制御が適用される。また、RTTが長い、すなわちネットワークが混雑していると判断された場合には、従来のAIMD制御と同等に、より低速に輻輳ウインドを増加させるAIMD制御が適用される。よって、この方式は、従来のAIMD制御による方式とネットワーク内で共存する場合の親和性が高い。
【特許文献１】米国特許出願公開第２００６／０２２７７０８号明細書
【特許文献２】特開２００６−２１７２３４号公報
【非特許文献１】W. Stevens、“TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms”、RFC2001、Jan. 1997
【非特許文献２】L. Brakmo and L. Peterson、“TCP Vegas: End to End Congestion Avoidance on a Global Internet”、IEEE Journal on Selected Areas in Communication、 Vol. 13,  No. 8、October 1995、pages 1465-1480
【非特許文献３】Cheng Jin, David X. Wei, Steven H. Low, G. Buhrmaster, J. Bunn, D. H. Choe, R. L. A. Cottrell, J. C. Doyle, W. Feng, O. Martin, H. Newman, F. Paganini, S. Ravot, S. Singh、“IEEE Network”、19(1):4-11、 January/February 2005
【非特許文献４】S. Liu, T. Basar and R. Srikant、“TCP-Illinois:  A Loss and Delay-Based Congestion Control Algorithm for High-Speed Networks”、Proc. First International Conference on Performance Evaluation Methodologies and Tools (VALUETOOLS)、Pisa, Italy、October 11-13, 2006
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述した特許文献および非特許文献に記載の輻輳制御では、例えば、ノードが送信しようとするデータのバッファ量が少ない割に、回線速度が非常に高速である場合、RTTの増大を検出し難いという問題がある。具体的には、例えば、バッファ量が128KBで回線速度が10Gbpsの場合、RTTが0.1msecほどであるのに対し、そのRTTの計測には数msec程度の誤差が生じるという問題である。よって、高速回線であっても送信データのバッファ量が極めて少ない場合は、RTTを正確に計測し難い。
【０００９】
上述の輻輳制御方式において、正確なRTTが得られない場合、実際は輻輳しているにもかかわらず輻輳していないと判断される可能性がある。そうすると、輻輳時においてもウインドを積極的に増加させてしまい、輻輳をより悪化させるおそれがある。
【００１０】
本発明は、上記課題に鑑みてなされたものであり、その目的は、RTTを正確に計測し難い状況であってもTCPのウインドを適切に増加させる技術を提供することにある。
【課題を解決するための手段】
【００１１】
本発明に係る通信装置は、ネットワークへ送出すべきパケット群のデータ量を規定したウインドに従い前記ネットワークにパケットを送信する送信部と、
前記ネットワークへ送信したパケットに対する受信確認通知を受信し且つパケット廃棄の有無を検知する受信部と、前回パケット廃棄を検知した際の現在時刻と、今回パケット廃棄を検知した際の現在時刻との差分である第１のパケット廃棄間隔を、パケットの廃棄を検知するたびに計算する廃棄間隔計算部と、前記受信部によりパケット廃棄が検知されない場合に、前記第１のパケット廃棄間隔と、前記受信部がパケット廃棄を検知しなかった際の現在時刻と前回パケット廃棄を検知した際の現在時刻との差分である第２のパケット廃棄間隔とを用いて現行のウインドに対する増加幅を決定し且つ当該増加幅を用いて前記現行のウインドを更新するウインド設定部とを備える。
【００１２】
本発明に係る通信方法は、通信装置が行う通信方法であって、前記通信装置が備える送信部が、ネットワークへ送出すべきパケット群のデータ量を規定したウインドに従い前記ネットワークにパケットを送信するステップと、前記通信装置が備える受信部が、前記ネットワークへ送信したパケットに対する受信確認通知を受信し且つパケット廃棄の有無を検知するステップと、前記通信装置が備える廃棄間隔計算部が、前回パケット廃棄を検知した際の現在時刻と、今回パケット廃棄を検知した際の現在時刻との差分である第１のパケット廃棄間隔を、パケットの廃棄を検知するたびに計算するステップと、前記通信装置が備えるウインド設定部が、パケット廃棄が検知されない場合に、前記第１のパケット廃棄間隔と、前記受信部がパケット廃棄を検知しなかった際の現在時刻と前回パケット廃棄を検知した際の現在時刻との差分である第２のパケット廃棄間隔とを用いて現行のウインドに対する増加幅を決定し且つ当該増加幅を用いて前記現行のウインドを更新するステップとを備える。
【発明の効果】
【００１３】
本発明によれば、高速回線に対する送信データのバッファ量が極めて少ない場合のように、ネットワークのRTTを正確に計測し難い状況であっても、ウインドを適切に増加させることができる。これにより、深刻な輻輳が発生することを防ぐことができる。
【発明を実施するための最良の形態】
【００１４】
本発明の実施の形態について、図面を参照して詳細に説明する。
【実施例１】
【００１５】
（構成の説明）
図１は、本実施例による端末1の構成を示すブロック図である。端末1は、ネットワーク100へ送信すべきデータを発生させるデータ発生部1-1と、ネットワーク100の他の端末との間で通信セッションを確立しパケットを送受信するデータ送信制御部1-2とで構成される。
【００１６】
データ送信制御部1-2は、データ発生部1-1からの送信データをパケット化してネットワーク100へ送信するパケット送信部1-3と、ネットワーク100から受信確認(ACK)パケットを受信するパケット受信部1-4と、RTTの計測を行うRTT計測部1-5と、パケット送信部1-3に適用するTCPの輻輳ウインドを設定する輻輳ウインド設定部1-0と、パケット廃棄の時間間隔を計算するパケット廃棄間隔計算部1-9とを備える。
【００１７】
輻輳ウインド設定部1-0は、輻輳ウインドの値を更新して記憶する輻輳ウインド保持部1-6と、非輻輳時の輻輳ウインド増加幅を決定する輻輳ウインド増加幅計算部1-7と、輻輳時の輻輳ウインド減少幅を決定する輻輳ウインド減少幅計算部1-8とで構成される。
【００１８】
（動作の説明） 
図２は、本実施例の動作を説明するフローチャートである。図１及び図２を参照して、本実施例の動作について説明する。
【００１９】
データ発生部1-1において送信データが発生すると、データの送信が開始される（ステップA1）。パケット送信部1-3は、パケット化した送信データを、輻輳ウインド保持部1-6にある現在の輻輳ウインドの値に従ってネットワーク100へ出力する。パケット送信部1-3は、送信するパケットのヘッダに、タイムスタンプとして現在時刻を書き込む。輻輳ウインドの値が大きければ、一度に多くのパケットをネットワークに出力できるため、高いスループットが得られる。また、輻輳ウインドの値が小さいときにはスループットが低くなる。
【００２０】
端末1からネットワーク100にパケットが送信されると、それを受信した端末（図示略）から端末1に対しACKパケットが返される。このACKパケットを端末1のパケット受信部1-4が受信する（ステップA2）。パケット受信部1-4は、受信側にて確認されたパケットのデータ量や、ネットワーク100におけるパケット廃棄の有無の判定を行い、正常に受信されたデータをパケット送信部1-3から消去する。RTT計測部1-5は、パケット受信部1-4から供給されるタイムスタンプ情報と現在時刻との差分から、RTTを計算する（ステップA3）。
【００２１】
パケット受信部1-4においてパケット廃棄が確認されなかった場合（ステップA4：No）、輻輳ウインド増加幅計算部1-7が輻輳ウインドの増加幅を計算し（ステップA5）、その増加幅を用いて輻輳ウインド保持部1-6が輻輳ウインドの値を更新する（ステップA6）。
【００２２】
輻輳ウインド増加幅計算部1-7は、パケット廃棄間隔計算部1-9が算出した最新のパケット廃棄間隔と、その平均値とのうちの大きい方の値を用いて、以下の式（1）又は（2）により、輻輳ウインド増加幅αを決定する。なお、パケット廃棄間隔の平均値Iavgは、後述するように、パケット廃棄が検出された時にパケット廃棄間隔計算部1-9が算出する値である。また、パケット廃棄間隔の最新値とは、現在時刻と前回のパケット廃棄時刻との差分に相当する。
【００２３】
α = b * max(Iavg, 現在時刻 - 前回のパケット廃棄時刻)  …（1）
あるいは、
α = b * f(RTT-最小RTT) * max(Iavg, 現在時刻 - 前回のパケット廃棄時刻)  …（2）
ここで、f1(x)は「x」に対する減少関数であり、「b」は増加幅の倍率を定めるパラメータである。「b」が大きいほど輻輳ウインドの増加幅が大きくなる。上式（2）において「b * e-f(RTT-RTTmin)」に相当する項は、特許文献２にて提案されているものに対応する。この項に対してパケット廃棄間隔の項を乗じた式が、本実施例の式（2）に相当する。
【００２４】
輻輳ウインド保持部1-6は、次の式（3）のようにして、輻輳ウインドの値を増加させる。この式（3）は、輻輳ウインドが、非特許文献１に記載の「TCP-Reno」に比べてα倍速く増加することを意味する。
【００２５】
輻輳ウインドサイズ = 輻輳ウインドサイズ + α/輻輳ウインドサイズ  …（3）
以上の式（1）〜（3）によれば、パケット廃棄間隔の最新値が平均値よりも小さい間は、平均値から増加幅αが決定されるため、輻輳ウインドが線形に増加する。そして、パケット廃棄間隔の最新値が平均値よりも大きくなれば、増加幅αが線形に増加するため、輻輳ウインドは２乗に比例して増加する。パケット廃棄間隔の最新値が平均値よりも大きくなることは、それまでよりもネットワークの輻輳度が低くなった可能性があることを意味する。この場合、輻輳ウインドがより急速に大きくなるよう制御される。
【００２６】
一方、パケット受信部1-4においてパケット廃棄が確認された場合（ステップA4：Yes）、輻輳ウインド減少幅計算部1-8が輻輳ウインドの減少幅を決定し、その減少幅を用いて輻輳ウインド保持部1-6が輻輳ウインドの値を更新する（ステップA7,A8）。ウインドの減少方法としては、例えば、前述の「TCP-Reno」のように一律に半減させる、あるいは、特許文献２に記載の方法のようにRTTの値を用いて次式（4）のように減少させても良い。
【００２７】
輻輳ウインドサイズ = 輻輳ウインドサイズ * 1 / (1 + c)  …（4）
ただし、輻輳度cは、以下の式（5）のように計算する。
【００２８】
c = (RTT - 最小RTT) / (最大RTT - 最小RTT)  …（5）
式（5）において、送信データのバッファ量が非常に小さい場合、「最大RTT = 最小RTT」となり、輻輳度cが適正に算出されない。よって、ある定数rを加算する、すなわち以下の式（6）ようにして「c」を計算してもよい。
【００２９】
c = (RTT - 最小RTT + r) / (最大RTT - 最小RTT + r)  …（6）
パケット廃棄間隔計算部1-9は、パケット廃棄間隔の平均値Iavgを次式（7）のようにして更新する（ステップA9）。
【００３０】
Iavg = a * Iavg + (1-a) * (現在時刻 - 前回のパケット廃棄時刻)  …（7）
式（7）において、a（0≦a≦1）は、平均への収束速度を表すパラメータであり、任意に設定することができる。パラメータ「ａ」が小さいほど平均への追従性が高く、「ａ」が大きいほど平均への追従性が低い。追従性が高いほど、通信環境の変化に強くなるが安定性は低下する。よって、通信環境の変化に対する耐性と安定性との兼ね合いを考慮して、パラメータ「a」を設定すればよい。
【００３１】
端末1は、バッファリングされている全てのデータの送信が終了するまで、以上の処理を繰り返す（ステップA10）。
【００３２】
（本実施例の効果）
このように、本実施例の端末1は、輻輳ウインドを増加させる際、パケット廃棄間隔の最新値と平均値との比較結果に応じて増加幅を決定する。従って、本実施例によれば、端末1における送信データのバッファ量が極めて少ないために正確なRTTを計測し難く、ネットワークの輻輳状態を把握し難い場合であっても、輻輳ウインドの増加幅を適切に設定することが可能となる。
【実施例２】
【００３３】
本発明の第２の実施例について図面を参照して説明する。
【００３４】
（構成の説明）
図３は、本実施例による端末2の構成を示すブロック図である。図示の構成において、前述した第１の実施例の構成（図１）と同様な構成要素には、第１の実施例での符号と対応する符号が与えられている。例えば、本実施例のデータ発生部2-1は、第１の実施例のデータ発生部1-1（図１）に対応するものである。
【００３５】
本実施例の構成は、第１の実施例の構成と比較して次の点が異なる。それは、データ送信制御部2-2におけるRTT判定部2-10の追加と、パケット廃棄間隔計算部2-9の計算方法とである。
【００３６】
（動作の説明） 
図４は、本実施例の動作を説明するフローチャートである。図３及び図４を参照して、本実施例の動作について説明する。動作に関し、第１の実施例と本実施例との差分は、本実施例では、RTTが閾値（RTTth）以下の場合にパケット廃棄間隔を更新し、更新した値を輻輳ウインドの増加幅の計算に用いる。
【００３７】
データ発生部2-1において送信データが発生してから、ACKパケットを受信し、RTTを計算し、パケット廃棄の判断を行うまでの手順（ステップB1〜B4）は、前述の第１の実施例において対応する手順（ステップA1〜A4）と同様であり、説明を省略する。以下、第１の実施例との差分について説明する。
【００３８】
パケット受信部2-4においてパケット廃棄が確認されなかった場合（ステップB4：No）、輻輳ウインドの増加幅を算出するに先立ち、RTT判定部2-10が、RTT計測部2-5により算出されたRTTを閾値（RTTth）と比較する。その結果、RTTが閾値RTTth以下であった場合のみ（ステップB5：Yes）、最新のACKパケットの受信間隔を用いて、パケット廃棄間隔の計測値Icurr’を次式８のように更新する（ステップB6）。
【００３９】
Icurr’ = Icurr’ + (現在時刻 - 前回のACK受信時刻), if (RTT < RTTth)  …（8）
上式（8）により得られる計測値Icurr’は、本発明における条件付きパケット廃棄間隔に対応する値であり、すなわち、RTTが閾値RTTth以下となっている期間に算出されるパケット廃棄間隔である。
【００４０】
ここで、閾値RTTthは、それまでの最小のRTTと予め設定された固定値とを加えたもの、あるいは、次式（9）のように、ある定数d (0<d<1)を用いて算出したものでも良い。
【００４１】
RTTth = 最小RTT + d*(最大RTT-最小RTT)  …（9）
輻輳ウインド増加幅計算部2-7は、上記式（8）により算出した条件付きパケット廃棄間隔（Icurr’）、及び、後述するパケット廃棄間隔の平均値（Iavg’）のうちの大きい方の値を用いて、次式（10）のように輻輳ウインド増加幅αを決定する（ステップB7）。
【００４２】
α = b * f2(RTT-最小RTT) * max(Iavg’, Icurr’)  …（10）
式１０において、f2(x)は「x」に対する増加関数であり、「b」は増加幅の倍率を定めるパラメータである。パケット廃棄間隔の平均値Iavg’は、後述の方法により、パケットの廃棄が検出された場合に更新される。
【００４３】
なお、RTTが閾値（RTTth）を超えると判断された場合（ステップB5：No）、輻輳ウインド増加幅計算部2-7は、前述の第１の実施例と同様な方法で、すなわち式（1）又は（2）により、ウインドの増加幅αを計算する。
【００４４】
輻輳ウインド減少幅計算部2-8は、輻輳ウインド増加幅計算部2-7の計算結果を用いて、現行の輻輳ウインドを増加するよう更新する（ステップB8）。
【００４５】
一方、パケット受信部2-4においてパケット廃棄が確認された場合（ステップB4：Yes）、輻輳ウインド減少幅計算部2-8が輻輳ウインドの減少幅を決定し、その減少幅により輻輳ウインド保持部2-6が輻輳ウインドを更新する（ステップB9,B10）。この処理は第１の実施例のもの（ステップA7,A8）と同様であるため、説明を省略する。
【００４６】
パケット廃棄間隔計算部2-9は、パケット廃棄間隔の平均値Iavg’を次式（11）のように更新する（ステップB11）。「a」（0≦a≦1）は、前述の式（7）で用いられるものと同様なパラメータである。
【００４７】
Iavg’ = a * Iavg’ + (1-a) * Icurr’、Icurr’ = 0  …（11）
端末2は、バッファリングされている全てのデータの送信が終了するまで、以上の処理を繰り返す（ステップB12）。
【００４８】
（本実施例の効果）
本実施例によれば、第１の実施例と同様な効果が得られると共に、輻輳度が長期的に安定した平衡状態にある、すなわち輻輳度の変動が比較的少ない状態において、輻輳ウインド増加幅αが過度に増大するのを防ぐことができる。これにより、平衡状態がより長く続くという効果がある。
【実施例３】
【００４９】
本発明の第３の実施例について図面を参照して説明する。
【００５０】
（構成の説明）
図５は、本実施例による端末3の構成を示すブロック図である。図示の構成において、前述した第２の実施例の構成（図３）と同様な構成要素には、第２の実施例での符号と対応する符号が与えられている。例えば、本実施例のデータ発生部3-1は、第２の実施例のデータ発生部2-1（図３）に対応するものである。
【００５１】
本実施例の構成は、第２の実施例の構成と比較して、次の点が異なる。それは、データ送信制御部3-2におけるパケット廃棄期待値計算部3-11の追加、及び、輻輳ウインド設定部3-0におけるウインドの設定方法である。
【００５２】
（動作の説明） 
図６は、本実施例の動作を説明するフローチャートである。図５及び図６を参照して、本実施例の動作について説明する。動作に関し、前述の第２の実施例と本実施例との差分は、パケット廃棄間隔について期待値を算出し、その期待値が大きくなるに従って、輻輳ウインド増加幅を小さくすることである。以下では第２の実施例との差分について説明する。
【００５３】
データ発生部3-1において送信データが発生してから、ACKパケットを受信し、RTTを計算し、パケット廃棄の判断を行う手順（ステップC1〜C3、C5）は、前述の第２の実施例において対応する手順（ステップB1〜B4）と同様であり、説明を省略する。
【００５４】
本実施例では、パケット廃棄期待値計算部3-11において、次式（12）によりパケット廃棄間隔の期待値Eを求める（ステップC4）。
【００５５】
E = g(Iavg’, Icurr’)  …（12）
ここで、関数g(x,y)は、0≦g(x,y)≦1であり、y=0あるいはy=∞で最小値を取り、y=xで最大値を取る関数である。また、「Icurr’」は、前述の式（8）により求められる条件付きパケット廃棄間隔であり、「Iavg’」は、前述の式（11）による平均値である。
【００５６】
パケット受信部3-4においてパケット廃棄が確認されなかった場合（ステップC5：No）は、輻輳ウインド増加幅計算部3-7が期待値Eを用いて次式（13）のように輻輳ウインド増加幅αを決定する（ステップC8）。
【００５７】
α = b * f2(RTT-最小RTT) * max(Iavg’, Icurr’) * (1-E)  …（13）
上記式（13）は、すなわち、前述の第２の実施例における増加幅αの式（10）に、期待値Eを用いた（1-E）項を乗じたものに相当する。輻輳ウインド保持部3-6は、算出された増加幅αを用いて輻輳ウインドを増加するよう更新する（ステップC9）。
【００５８】
一方、パケット受信部3-4においてパケット廃棄が確認された場合（ステップC5：Yes）、その処理(ステップC10〜C12)は、第２の実施例において対応する処理(ステップB9〜B11)と同様であるため、ここでは説明を省略する。
【００５９】
端末3は、ネットワーク100へバッファリングされている全てのデータの送信が終了するまで、以上の処理を繰り返す（ステップC13）。
【００６０】
なお、本実施例の変形として、期待値Eの算出に次のような式を用いてもよい。ここでの関数g(x,y)の定義は、前述の式（12）のものと同様である。
【００６１】
E = g(Iavg, (現在時刻 -前回のパケット廃棄時刻))  …（14）
E = g(推定回線帯域, 現在の送信帯域)  …（15）
E = g(W, 現在の輻輳ウインドサイズ)  …（16）
式（14）は、第１の実施例の要領で求めたパケット廃棄間隔の平均値Iavgおよび最新値を用いるものである。このほか、推定回線帯域及び現在の送信帯域を用いた式（15）や、輻輳ウインドサイズを用いた式（16）であってもよい。式（16）の「W」は、過去のパケット廃棄が発生した時に適用されていた輻輳ウインドサイズあるいはその平均である。
【００６２】
（本実施例の効果）
本実施例によれば、第１の実施例と同様な効果が得られると共に、送信データのバッファ量が極めて少ないことによりRTTの変化を検知し難い場合でも、輻輳ウインドの増加幅が大きくなりすぎることを防ぐことができる。
【実施例４】
【００６３】
本発明の第４の実施例について説明する。
【００６４】
（構成の説明）
本実施例の構成は、前述の第３の実施例のもの（図５）と同様であり、説明を省略する。
【００６５】
（動作の説明） 
本実施例の動作は、輻輳ウインド増加率αの算出方法を除いて、第３の実施例（図６）と同様である。本実施例における増加幅αの算出には、前述の式（13）に対し減算項を付加した次式（17）を用いる。この減算項は、RTTの値に対する増加関数となっていればよい。
【００６６】
α = b * f2(RTT-最小RTT) * max(Iavg’, Icurr’) * (1-E) - (RTT-最小RTT) * (輻輳ウインドサイズ / RTT) + 1  …（17）
式（17）は、非特許文献３の「FAST」のような、RTTを用いた輻輳制御方式における輻輳ウインドと同様の性質を持つ。すなわち、上式（17）の減算項は、ネットワーク上でボトルネックとなっているルータのキューにあるパケット量に相当する量を表す。そして、式（17）によれば、輻輳ウインドサイズから前記相当量が減算される。
【００６７】
（本実施例の効果）
本実施例によれば、RTTを用いた輻輳制御方式と同様の特徴、すなわち定常状態において輻輳ウインドサイズが最適値に収束することや、フロー間のRTTが異なってもフロー間のスループットの公平性が高いといった効果がある。
【実施例５】
【００６８】
本発明の第５の実施例について説明する。
【００６９】
（構成の説明）
本実施例の構成は、前述の第３の実施例のもの（図５）と同様であり、説明を省略する。
【００７０】
（動作の説明） 
本実施例の動作は、RTT計測部3-5におけるRTTの算出方法を除き、第３の実施例の手順（図６）と同様である。本実施例のRTT計測部3-5は、第３の実施例と同様に、すなわち第１の実施例と同様にRTTを算出する。そして、算出した値を「計測RTT」とし、ある定数rとパケット廃棄間隔の期待値Eとを用いて次式（18）のように補正する。すなわち、パケット廃棄の期待値Eが大きくなるに従い、RTTの値が大きくなるよう補正する。
【００７１】
補正RTT = 計測RTT + r * E  …（18）
本実施例の輻輳ウインド設定部3-0は、輻輳ウインドの増加幅および減少幅を計算する際には、上式（18）により補正された値（「補正RTT」）をRTTとして用いる。したがって、更新された輻輳ウインドは、パケット廃棄間隔の期待値Eが反映されたものとなる。
【００７２】
なお、本実施例の場合、パケット廃棄の期待値Eは、式（18）による「補正RTT」に含まれている。よって、輻輳ウインド増加幅αの算出の際は、第３の実施例で用いた式（13）から(1-E)の項を削除した次式（19）を用いる。
【００７３】
α = b * f2(補正RTT-最小RTT) * max(Iavg’, Icurr’)  …（19）
（本実施例の効果）
本実施例によれば、輻輳ウインドの更新に用いるRTTをパケット廃棄間隔の期待値により補正することから、送信データのバッファ量が極めて少ないためにRTTの変化を検出し難い状況においても、輻輳ウインドを適切に設定することができる。これにより、輻輳ウインドの増加幅が大きくなりすぎること、及び、減少幅が小さくなりすぎることを防ぐことができる。
【実施例６】
【００７４】
本発明の第６の実施例について図面を参照して説明する。
【００７５】
（構成の説明）
図７は、本実施例による端末6の構成を示すブロック図である。図示の構成において、前述した第１の実施例の構成（図１）と同様な構成要素には、第１の実施例での符号と対応する符号が与えられている。例えば、本実施例のデータ発生部6-1は、第１の実施例のデータ発生部1-1（図１）に対応するものである。
【００７６】
本実施例の構成は、第１の実施例の構成と比較して、次の点が異なる。データ送信制御部6-2におけるスロースタート閾値設定部6-10の追加と、輻輳ウインド保持部6-6による輻輳ウインドの増加方法とである。本実施例の輻輳ウインド保持部6-6は、スロースタート閾値設定部6-10により設定される後述のスロースタート閾値に基づいて、現行の輻輳ウインドに対する増加の度合いを変更する。
【００７７】
（動作の説明） 
図８は、本実施例の動作を説明するフローチャートである。図７及び図８を参照して、本実施例の動作について説明する。データ発生部6-1において送信データが発生してから、ACKパケットを受信し、RTTを計算し、パケット廃棄の判断を行うまでの手順（ステップD1〜D4）は、前述の第１の実施例において対応する手順（ステップA1〜A4）と同様であり、説明を省略する。
【００７８】
また、本実施例において、輻輳ウインドの更新（増加）およびスロースタート閾値の設定以外の動作は前述の第１の実施例の手順と同様である。以下、第１の実施例との差分について説明する。
【００７９】
パケット受信部6-4においてパケット廃棄が検出されなかった場合(ステップD4：No)、輻輳ウインド増加幅計算部6-7が、第１の実施例と同様にして輻輳ウインドの増加幅αを算出する(ステップD5)。
【００８０】
輻輳ウインド保持部6-6は、現行の輻輳ウインドとスロースタート閾値設定部6-10が設定したスロースタート閾値SSthとの大小関係に応じて、輻輳ウインドを次式（20）又は（21）のように増加させる(ステップD6)。
【００８１】
輻輳ウインドサイズ = 輻輳ウインドサイズ + α/輻輳ウインドサイズ, if (輻輳ウインドサイズ > SSth)  …（20）
輻輳ウインドサイズ = 輻輳ウインドサイズ + 1, if (輻輳ウインドサイズ <= SSth)  …（21）
すなわち、現行の輻輳ウインドが、閾値SSthより大きい場合は式（20）が適用され、閾値SSthより小さい場合は式（21）が適用される。これにより、パケット廃棄が検出されない間、現行の輻輳ウインドが小さいほど、より急速に輻輳ウインドを大きくするよう制御される。
【００８２】
スロースタート閾値設定部6-10は、パケット廃棄が検出されない場合は、次式（22）のように閾値SSthを減少させるよう更新する（ステップD7）。
【００８３】
SSth = max(SSth + 1/輻輳ウインドサイズ, 輻輳ウインドサイズ/2)  …（22）
一方、パケット廃棄が検出された場合（ステップD4：Yes）、スロースタート閾値設定部6-10は、次式（23）のように閾値SSthを増加させるよう更新する（ステップD11）。
【００８４】
SSth = SSth / 2  …（23）
上記の式（22）及び（23）のようにして計算される閾値SSthは、非特許文献１の「TCP-Reno」のようなAIMD方式による輻輳ウインドサイズと同じように計算されることになる。
【００８５】
（本実施例の効果）
本実施例によれば、輻輳ウインドサイズが、AIMD方式による輻輳ウインドサイズを下回らないように制御されるため、AIMD方式と共存した場合のスループットの公平性が保たれるという効果がある。
【図面の簡単な説明】
【００８６】
【図１】本発明の第１の実施例による端末の構成を示すブロック図である。
【図２】本発明の第１の実施例の動作を示すフローチャートである。
【図３】本発明の第２の実施例による端末の構成を示すブロック図である。
【図４】本発明の第２の実施例の動作を示すフローチャートである。
【図５】本発明の第３の実施例による端末の構成を示すブロック図である。
【図６】本発明の第３の実施例の動作を示すフローチャートである。
【図７】本発明の第６の実施例による端末の構成を示すブロック図である。
【図８】本発明の第６の実施例の動作を示すフローチャートである。
【符号の説明】
【００８７】
100：ネットワーク、1：端末、1-1：データ発生部、1-2：データ送信制御部、1-3：パケット送信部、1-4：パケット受信部、1-5：RTT計測部、1-6：輻輳ウインド保持部、1-7：輻輳ウインド増加幅計算部、1-8：輻輳ウインド減少幅計算部、1-9：パケット廃棄間隔計算部
【図１】
0005146725.tif 000002
【図２】
0005146725.tif 000003
【図３】
0005146725.tif 000004
【図４】
0005146725.tif 000005
【図５】
0005146725.tif 000006
【図６】
0005146725.tif 000007
【図７】
0005146725.tif 000008
【図８】
0005146725.tif 000009