(57)【要約】【課題】ネットワークのトラフィック状況の変化に追従したデータパケットの送信を可能にする。【解決手段】パケット量計算部１６が、ネットワークのトラフィック状況を取得する。ウィンドウサイズ制御部１７が、取得したトラフィック状況に応じてウィンドウサイズの変更量を動的に変更する。送信制御部１２は、動的に変更されたウィンドウサイズの変更量に基づいて変更されたウィンドウサイズを用いて、データパケットを送信するよう制御する。【選択図】図２
2005218069.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークのトラフィック状況を取得する取得手段と、
前記トラフィック状況に基づいて、ウィンドウサイズの変更量を決定するウィンドウサイズ制御手段と、
前記ウィンドウサイズの変更量に基づいて、データパケットの送信を制御する送信制御手段と
を備えることを特徴とする通信システム。
【請求項２】
前記取得手段は、前記トラフィック状況として前記ネットワーク上のルータに蓄積されているデータパケットの蓄積パケット量を計算し、
前記ウィンドウサイズ制御手段は、前記蓄積パケット量に基づいて前記変更量を計算することを特徴とする請求項１に記載の通信システム。
【請求項３】
ネットワークのトラフィック状況を取得する取得手段と、
前記トラフィック状況に基づいて、ウィンドウサイズの変更量を決定するウィンドウサイズ制御手段と、
前記ウィンドウサイズの変更量に基づいて、データパケットの送信を制御する送信制御手段と
を備えることを特徴とする通信装置。
【請求項４】
コンピュータを
ネットワークのトラフィック状況を取得する取得手段と、
前記トラフィック状況に基づいて、ウィンドウサイズの変更量を決定するウィンドウサイズ制御手段と、
前記ウィンドウサイズの変更量に基づいて、データパケットの送信を制御する送信制御手段として機能させるためのプログラム。
【請求項５】
ネットワークのトラフィック状況を取得し、
前記トラフィック状況に基づいて、ウィンドウサイズの変更量を決定し、
前記ウィンドウサイズの変更量に基づいて、データパケットの送信を制御することを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、通信装置、プログラム及び通信方法に関する。
【背景技術】
【０００２】
ＴＣＰ（Transmission  Control  Protocol）における輻輳制御方式には、ＴＣＰ  Ｒｅｎｏのようなリアクティブな輻輳制御方式や、ＴＣＰ  Ｖｅｇａｓのようなプロアクティブな輻輳制御方式がある。ＴＣＰ  Ｒｅｎｏでは、送信端末はネットワークの輻輳に伴うパケットロスが発生するまでデータパケットの送信速度を徐々に増加させ、パケットロスを検出すると送信速度を大きく減少させる。そのため、ＴＣＰ−Ｒｅｎｏでは、結局、輻輳が発生してしまい、ネットワークを有効に利用できない欠点がある。
【０００３】
ＴＣＰ  Ｖｅｇａｓでは、送信端末は、送信端末と受信端末との間のラウンドトリップタイム（Round  Trip  Time、以下「ＲＴＴ」と表す）の増加を、輻輳検出に用いる。具体的には、ネットワークが輻輳し始めると、ネットワーク上のルータに蓄積され、待ち行列に入る蓄積パケット量が増加することによるキューイング遅延が増大し、ＲＴＴが増加し始める。そのため、送信端末は、ＲＴＴが増加し始めた時点で、データパケットの送信速度を抑える。よって、ＴＣＰ  Ｖｅｇａｓでは、輻輳を防止し、ネットワークを有効に利用できる（例えば、非特許文献１、非特許文献２参照）。
【０００４】
ＴＣＰ  Ｖｅｇａｓでは、輻輳回避フェーズ（Congestion  Avoidance  Phase）に移行後、送信端末は１ＲＴＴ毎に、以下に示す（１）式、（２）式を用いて輻輳ウィンドウサイズ（Congestion  Window  Size、以下「ｃｗｎｄ」と表す）を変更し、輻輳制御を行う。
【０００５】
Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ＜α  のとき、
ｃｗｎｄ＿ｎｅｘｔ＝ｃｗｎｄ＋１データパケット  （１）式  
Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ＞β  のとき、
ｃｗｎｄ＿ｎｅｘｔ＝ｃｗｎｄ−１データパケット  （２式）
【０００６】
（１）、（２）式において、「Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ」は蓄積パケット量、「ｃｗｎｄ」は現在のｃｗｎｄ、「ｃｗｎｄ＿ｎｅｘｔ」は次にデータパケットを送信する際のｃｗｎｄである。α、βは定数であり、αのデフォルト値は１データパケット、βのデフォルト値は３データパケットである。
【非特許文献１】Charalampos (Basis) Samios and Mark K. Vernon, “Modeling the Throughput of TCP Vegas”, Proceedings of the 2003 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, volume 31 Issue 1, June 2003
【非特許文献２】長谷川  剛、倉田  謙二、村田  正幸、「バージョン間の公平性を考慮したＴＣＰ  Ｖｅｇａｓの改善方式」、電子情報通信学会技術研究報告（SSE2000-31），２０００年５月
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来のＴＣＰ  Ｖｅｇａｓにおける輻輳制御方法では、ｃｗｎｄは１ＲＴＴ毎に１データパケット分しか増減できず、ｃｗｎｄの変更量は固定的である。即ち、ｃｗｎｄの変更の早さは、１ＲＴＴにつき１データパケット分だけであり、固定的である。そのため、従来の輻輳制御方法では、ネットワークのトラフィック状況の急激な変化に十分に追従することができなかった。
【０００８】
具体的には、図７（ａ）に示すように、送信端末２１０の通信中に他の端末装置も通信している場合、ネットワーク上には送信端末２１０による送信端末トラフィック２０１ａと、他の端末装置による他トラフィック２０１ｂとが存在する。そして、ネットワーク上のルータ２３０の送信バッファ２３１には、送信端末２１０や他の端末装置からのデータパケット２０１が蓄積され、待ち行列に入っている。
【０００９】
図７（ａ）において、他トラフィック２０１ｂが少ない、あるいは、他の端末装置が通信をしておらず、他トラフィック２０１ｂが存在しないとする。このとき、図７（ｂ）に示すように、他の端末装置が送信するデータパケット量が増加したり、他の端末装置が通信を開始したりすると、他トラフィック２０１ｂが増加し、ネットワークが輻輳し始める。そして、ルータ２３０の送信バッファ２３１に大量のデータパケット２０１が蓄積され始める。この場合に、従来の輻輳制御方法では、ｃｗｎｄを１ＲＴＴ毎に１データパケット分しか減少させることができず、送信速度の低下が遅いため、送信端末２１０や他の端末装置のデータパケットの送信速度を速やかに抑えることができない。その結果、送信バッファ２３１からデータパケット２０１が溢れ、パケットロスが発生する。
【００１０】
一方、図７（ａ）において、ある程度の他トラフィック２０１ｂが存在するとする。このとき、図７（ｃ）に示すように、他の端末装置が通信を終了すると、他トラフィック２０１ｂはなくなり、送信端末トラフィック２０１ａだけになる。そして、ルータ２３０の送信バッファ２３１にデータパケットが蓄積されなくなり、ネットワークの通信帯域に空きが生じる。この場合に、従来の輻輳制御方法では、ｃｗｎｄを１ＲＴＴ毎に１データパケット分しか増加させることができず、送信速度の向上が遅いため、送信端末２１０のデータパケットの送信速度を速やかに向上させることができない。その結果、ネットワークの通信帯域を有効に利用できない。
【００１１】
そこで、本発明は、ネットワークのトラフィック状況の変化に追従したデータパケットの送信を可能にすることを目的とする。
【課題を解決するための手段】
【００１２】
本発明に係る通信システム、通信装置は、ネットワークのトラフィック状況を取得する取得手段と、トラフィック状況に基づいて、ウィンドウサイズの変更量を決定するウィンドウサイズ制御手段と、ウィンドウサイズの変更量に基づいて、データパケットの送信を制御する送信制御手段とを備えることを特徴とする。
【００１３】
このような通信システム、通信装置によれば、トラフィック状況を取得し、取得したトラフィック状況に応じてウィンドウサイズの変更量を動的に変更できる。そして、通信システム、通信装置は、動的に変更されたウィンドウサイズの変更量に基づいて動的に変更されたウィンドウサイズを用いて、データパケットを送信できる。そのため、通信システム、通信装置は、ネットワークのトラフィック状況の変化に追従してデータパケットを送信できる。
【００１４】
更に、取得手段は、トラフィック状況としてネットワーク上のルータに蓄積されているデータパケットの蓄積パケット量を計算し、ウィンドウサイズ制御手段は、蓄積パケット量に基づいて変更量を計算することが好ましい。これによれば、通信システム、通信装置は、蓄積パケット量を用いて変更量を計算することにより、容易に適切なウィンドウサイズの変更量を決定できる。よって、通信システム、通信装置は、ネットワークのトラフィック状況の変化に、より適切に、かつ、容易に追従してデータパケットを送信できる。
【００１５】
本発明に係るプログラムは、コンピュータをネットワークのトラフィック状況を取得する取得手段と、トラフィック状況に基づいて、ウィンドウサイズの変更量を決定するウィンドウサイズ制御手段と、ウィンドウサイズの変更量に基づいて、データパケットの送信を制御する送信制御手段として機能させるためのプログラムである。このようなプログラムによれば、上記通信システムや通信装置を実現できる。本発明に係る通信方法は、ネットワークのトラフィック状況を取得し、トラフィック状況に基づいて、ウィンドウサイズの変更量を決定し、ウィンドウサイズの変更量に基づいて、データパケットの送信を制御することを特徴とする。
【発明の効果】
【００１６】
以上説明したように、本発明によれば、ネットワークのトラフィック状況の変化に追従したデータパケットの送信が可能になる。
【発明を実施するための最良の形態】
【００１７】
図１に示すように、通信システム１００は、送信端末１０と、受信端末２０と、複数のルータ３０ａ，３０ｂと、ネットワーク４０を備える。通信システム１００では、輻輳制御方式としてＴＣＰ  Ｖｅｇａｓを用いる。送信端末１０、受信端末２０は、ネットワーク４０に接続する通信装置である。送信端末１０は、ネットワーク４０を介して受信端末２０にデータパケット１を送信する。受信端末２０は、データパケット１を受信すると、ネットワーク４０を介して送信端末１０に肯定応答（Acknowledge、以下「Ａｃｋ」と表す）２を送信する。
【００１８】
ルータ３０ａ，３０ｂは、送信端末１０と受信端末２０との間のネットワーク４０上に設けられる。ルータ３０ａは、データパケット１を送信端末１０から受信端末２０まで転送する。ルータ３０ａは、送信バッファ３１を備える。ルータ３０ａは、送信端末１０からデータパケット１を受信し、送信バッファ３１に蓄積して待ち行列に入れる。ルータ３０ａは、送信バッファ３１からデータパケット１を取り出して受信端末２０に転送する。ルータ３０ｂもルータ３０ａと同様に送信バッファを備える。ルータ３０ｂは、受信端末２０からＡｃｋ２を受信し、送信端末１０に転送する。
【００１９】
次に、送信端末１０について詳細に説明する。送信端末１０は、送信バッファ１１と、送信制御部１２と、通信インタフェース１３と、送信記録テーブル１４と、時計部１５と、パケット量計算部１６と、ウィンドウサイズ制御部１７とを備える。
【００２０】
通信インタフェース１３は、送信制御部１２からデータパケットを取得する。通信インタフェース１３は、送信制御部１２の指示に従ってデータパケットを受信端末２０に送信する。通信インタフェース１３は、受信端末２０からＡｃｋを受信する。通信インタフェース１３は、受信したＡｃｋを送信制御部１２とパケット量計算部１６に入力する。送信バッファ１１は、送信端末１０が送信するデータパケットを保持する。送信記録テーブル１４は、送信端末１０によるデータパケットの送信状況を記憶する。送信記録テーブル１４は、送信状況として、送信端末１０が送信したデータパケットのシーケンス番号と、データパケットを送信した送信時刻とを対応付けて保持する。
【００２１】
パケット量計算部１６は、ネットワーク４０のトラフィック状況を取得する取得手段である。パケット量計算部１６は、トラフィック状況として、ネットワーク４０上のルータ３０ａに蓄積されているデータパケットの蓄積パケット量を計算し、トラフィック状況を取得する。パケット量計算部１６は、ネットワーク４０上のルータのうち、送信端末１０から受信端末２０へのデータパケットの転送経路上にあり、送信バッファ３１にデータパケットが蓄積し、データパケット転送のボトルネックとなっているルータ３０ａの蓄積パケット量を計算する。パケット量計算部１６は、蓄積パケット量として、送信端末１０以外の端末装置が送信したデータパケットを除いた、送信端末１０がボトルネックのルータ３０ａに蓄積させているパケット量を計算してもよい。
【００２２】
パケット量計算部１６は、通信インタフェース１３からＡｃｋを取得する。パケット量計算部１６は、Ａｃｋを取得すると時計部１５を参照し、Ａｃｋの受信時刻を取得する。時計部１５は現在時刻を提供する。Ａｃｋは、受信端末２０が受信したデータパケットのシーケンス番号を含む。パケット量計算部１６は、Ａｃｋに含まれるシーケンス番号に基づいて送信記録テーブル１４を検索し、送信端末１０がＡｃｋを受信したデータパケットの送信時刻を取得する。パケット量計算部１６は、Ａｃｋを受信したデータパケットの送信状況を、送信記録テーブル１４から削除する。パケット量計算部１６は、Ａｃｋの受信時刻、データパケットの送信時刻を用いて、蓄積パケット量を計算する。パケット量計算部１６は、計算により取得した蓄積パケット量を、ウィンドウサイズ制御部１７に入力する。
【００２３】
ウィンドウサイズ制御部１７は、トラフィック状況に基づいて、ウィンドウサイズの変更量を決定するウィンドウサイズ制御手段である。ウィンドウサイズ制御部１７は、トラフィック状況として蓄積パケット量を用い、変更量を計算する。ウィンドウサイズ制御部１７は、パケット量計算部１６からトラフィック量として蓄積パケット量を取得する。
【００２４】
通信システム１００においてウィンドウサイズを制御する制御周期を「Ｒｏｕｎｄ」と表す。ウィンドウサイズを制御した直後から、次にウィンドウサイズを制御するまでの期間が制御周期（Ｒｏｕｎｄ）となる。ウィンドウサイズ制御部１７は、制御周期（Ｒｏｕｎｄ）毎にウィンドウサイズの変更量を決定する。具体的には、ウィンドウサイズ制御部１７は、１ＲＴＴ毎にウィンドウサイズの変更量を決定する。よって、制御周期（Ｒｏｕｎｄ）の長さは１ＲＴＴになる。ウィンドウサイズ制御部１７は、ウィンドウサイズとしてｃｗｎｄの変更量を決定する。
【００２５】
ウィンドウサイズ制御部１７は、決定したウィンドウサイズの変更量を用いて、ウィンドウサイズを決定する。ウィンドウサイズ制御部１７は、現在の制御周期（Ｒｏｕｎｄ）よりも後の制御周期（Ｒｏｕｎｄ）の変動量及びウィンドウサイズであれば、どの制御周期（Ｒｏｕｄｎｄ）について決定してもよい。そのため、ウィンドウサイズ制御部１７は、次の制御周期（Ｒｏｕｎｄ）の変動量及びウィンドウサイズを決定してもよく、更に後の制御周期（Ｒｏｕｎｄ）の変更量及びウィンドウサイズを決定してもよい。ウィンドウサイズ制御部１７は、決定したウィンドウサイズを送信制御部１２に入力する。又、ウィンドウサイズ制御部１７は、ウィンドウサイズを決定せずに、ウィンドウサイズの変更量を送信制御部１２に入力してもよい。
【００２６】
送信制御部１２は、ウィンドウサイズの変更量に基づいて、データパケットの送信を制御する送信制御手段である。送信制御部１２は、ウィンドウサイズ制御部１７からウィンドウサイズ又はウィンドウサイズの変更量を取得する。送信制御部１２は、ウィンドウサイズの変更量を取得した場合には、まず、変更量を用いてウィンドウサイズを決定する。
【００２７】
送信制御部１２は、取得、又は、決定したウィンドウサイズのデータパケットを送信バッファ１１から取得する。そして、送信制御部１２は、取得したデータパケットを通信インタフェース１３に入力し、制御周期（Ｒｏｕｎｄ）を指定してウィンドウサイズのデータパケットを送信するよう指示する。
【００２８】
又、送信制御部１２は、データパケットの送信状況を送信記録テーブル１４に記録する。送信制御部１２は、通信インタフェース１３にデータパケットの送信を指示する際に時計部１５を参照し、データパケットの送信時刻を取得する。送信制御部１２は、データパケットのシーケンス番号と送信時刻を対応付けて、送信記録テーブル１４に記録する。更に、送信制御部１２は、通信インタフェース１３からＡｃｋを取得する。送信制御部１２は、一定時間経過してもＡｃｋを受信できないデータパケットについては、通信インタフェース１３に再送を指示する。
【００２９】
次に、ウィンドウサイズの変更量、ウィンドウサイズの決定方法について詳細に説明する。以下、制御周期（Ｒｏｕｎｄ）の順番を「＃ｉ」、「＃ｉ」番目の制御周期を「Ｒｏｕｎｄ（＃ｉ）」と表す。通信開始後１回目の制御周期（Ｒｏｕｎｄ）が「Ｒｏｕｕｎｄ（＃１）」となる。Ｒｏｕｎｄ（＃ｉ）におけるｃｗｎｄを「ｃｗｎｄ（＃ｉ）」、ｃｗｎｄの変更量を「Ｖ（＃ｉ）」と表す。又、データパケットのシーケンス番号を「Ｓｉ」、シーケンス番号が「Ｓｉ」のデータパケットを「データパケット（Ｓｉ）」、シーケンス番号が「Ｓｉ」のデータパケットに対するＡｃｋを「Ａｃｋ（Ｓｉ）」と表す。更に、ネットワーク４０が輻輳していないときの送信端末１０と受信端末２０との間のＲＴＴを「ＲＴＴｂａｓｅ」と定義する。図３〜５を用いて、ＴＣＰ  Ｖｅｇａｓにおける輻輳回避フェーズ（Congestion  Avoidance  Phase）移行後の送信端末１０と受信端末２０との間のデータパケットの送受信を例にとって説明する。
【００３０】
まず、図３に示すように、Ｒｏｕｎｄ（＃ｉ）において、送信端末１０がｃｗｎｄ（＃ｉ）のデータパケット、データパケット（Ｓ４）１ａ、データパケット（Ｓ５）１ｂ、データパケット（Ｓ６）１ｃ、データパケット（Ｓ７）１ｄを受信端末２０に送信する。尚、既にＲｏｕｎｄ（＃ｉ）におけるデータパケット（Ｓ１）〜データパケット（Ｓ３）は送信済みである。このとき、送信端末１２の送信制御部１２は、送信した全てのデータパケットの送信時刻を送信記録テーブル１４に記録する。又、送信端末１０は、Ｒｏｕｎｄ（＃ｉ）において既に送信したデータパケットに対するＡｃｋ（Ｓ１）２ａ、Ａｃｋ（Ｓ２）２ｂ、Ａｃｋ（Ｓ３）２ｃを受信端末２０から受信する。
【００３１】
Ｒｏｕｎｄ（＃ｉ＋１）が開始すると、図４に示すように、受信端末２０が、Ｒｏｕｎｄ（＃ｉ）において送信したデータパケットに対するＡｃｋ（Ｓ４）２ｄ、Ａｃｋ（Ｓ５）２ｅを送信端末１０に送信する。送信端末１０のパケット量計算部１６は、送信端末１０が受信したＡｃｋ（Ｓ４）、Ａｃｋ（Ｓ５）のシーケンス番号を用いて、送信記録テーブル１４から、データパケット（Ｓ４）の送信時刻ｔ４、データパケット（Ｓ５）の送信時刻ｔ５を取得する。
【００３２】
パケット量計算部１６は、Ａｃｋの受信時刻、データパケットの送信時刻を用いて、Ｒｏｕｎｄ（＃ｉ）において送信した全てのデータパケットのＲＴＴを計算する。即ち、パケット量計算部１６は、送信端末１０がデータパケットを送信してからそのＡｃｋを受信するまでの時間を、送信端末１０と受信端末２０との間のＲＴＴとして計算する。例えば、パケット量計算部１６は、データパケット（Ｓ４）の送信時刻ｔ４とＡｃｋ（Ｓ４）の受信時刻との差分を計算し、そのデータパケットのＲＴＴを計算する。このようにして、パケット量計算部１６はＲＴＴを常に計算することにより、測定する。そして、パケット量計算部１６は、測定したＲＴＴの中で最小のＲＴＴをＲＴＴｂａｓｅとして用いる。
【００３３】
Ｒｏｕｎｄ（＃ｉ＋１）開始直後は、図４の点線Ａよりも矢印Ｂ側に示すように、Ｒｏｕｎｄ（＃ｉ）において送信端末１０が送信したデータパケット（Ｓ６）１ｃ、データパケット（Ｓ７）１ｄは、まだ受信端末２０に到達していない。更に、Ｒｏｕｎｄ（＃ｉ＋１）では、送信端末１０はｃｗｎｄ（＃ｉ＋１）のデータパケットを受信端末２０に送信する。そのため、図４の点線Ａよりも矢印Ｃ側に示すように、Ｒｏｕｎｄ（＃ｉ＋１）におけるデータパケット（Ｓ８）１ｅ、データパケット（Ｓ９）１ｆの送信が開始される。尚、送信端末１０のウィンドウサイズ制御部１７は、輻輳回避フェーズ移行直後のＲｏｕｎｄ（＃２）ではｃｗｎｄ（＃２）としてｃｗｎｄ（＃１）をそのまま用いる。
【００３４】
図５に示すように、送信端末１０が、データパケット（Ｓ１１）１ｇ、データパケット（Ｓ１２）１ｈ、データパケット（Ｓ１３）１ｉ、データパケット（Ｓ１４）１ｊを受信端末２０に送信し、Ｒｏｕｎｄ（＃ｉ＋１）におけるデータパケットが全て送信され、Ｒｏｕｎｄ（＃ｉ＋１）が終了する頃になると、送信端末１０は、Ｒｏｕｎｄ（＃ｉ）において送信した全てのデータパケットのＡｃｋを受信端末２０から受信し終わる。そして、受信端末２０は、Ｒｏｕｎｄ（＃ｉ＋１）において送信したデータパケットに対するＡｃｋ（Ｓ８）２ｆ、Ａｃｋ（Ｓ９）２ｇ、Ａｃｋ（Ｓ１０）２ｈを送信端末１０に送信し始める。
【００３５】
送信端末１０のパケット量計算部１６は、Ｒｏｕｎｄ（＃ｉ）において送信した全てのデータパケットのＲＴＴの平均値を計算する。そして、パケット量計算部１６は、以下に示す（３）式を用いて蓄積パケット量を計算する。「Ｒｏｕｎｄ（＃ｉ）」における蓄積パケット量を「Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）」、Ｒｏｕｎｄ（＃ｉ）において送信したデータパケットのＲＴＴの平均値を「ＲＴＴ＿ａｖｅ（＃ｉ）」と表す。  
Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）＝（ｃｗｎｄ（＃ｉ）／ＲＴＴ＿ａｖｅ（＃ｉ））×（ＲＴＴ＿ａｖｅ（＃ｉ）―ＲＴＴｂａｓｅ）  （３）式
【００３６】
次に、ウィンドウサイズ制御部１７は、求めた蓄積パケット量と、以下に示す（４）式、（５）式を用いて、Ｒｏｕｎｄ（＃ｉ＋２）におけるＶ（＃ｉ＋２）を計算する。  
Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）＜α、又は、Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）＞βのとき、
Ｖ（＃ｉ＋２）＝ε（δ―Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ））  （４式）
α≦Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）≦βのとき、
Ｖ（＃ｉ＋２）＝０  （５）式
【００３７】
そして、ウィンドウサイズ制御部１７は、求めたＶ（＃ｉ＋２）と、以下に示す（６）式を用いて、Ｒｏｕｎｄ（＃ｉ＋２）におけるｃｗｎｄ（＃ｉ＋２）を計算する。  
ｃｗｎｄ（＃ｉ＋２）＝ｃｗｎｄ（＃ｉ）＋Ｖ（＃ｉ＋２）  （６）式
【００３８】
あるいは、ウィンドウサイズ制御部１７は、求めた蓄積パケット量と、以下に示す（７）式、（８）式を用いて、ウィンドウサイズの変更量に基づいたｃｗｎｄ（＃ｉ＋２）を直接計算してもよい。  
Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）＜α、又は、Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）＞βのとき、
ｃｗｎｄ（＃ｉ＋２）＝ｃｗｎｄ（＃ｉ）＋ε（δ―Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ））  （７式）
α≦Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）≦βのとき、
ｃｗｎｄ（＃ｉ＋２）＝ｃｗｎｄ（＃ｉ）  （８）式
【００３９】
（４）〜（８）式において、α、β、εは定数である。δ＝（α＋β）／２である。定数α、βは、ウィンドウサイズの変更の可否を判断するための定数である。蓄積パケット量が少なく、ネットワークの通信帯域に空きが生じている場合には、データパケットの送信速度を速やかに向上させて、ネットワークの通信帯域を有効に利用する必要がある。そのため、定数αとして、蓄積パケット量が少ない場合にウィンドウサイズの変更を適切に行えるように、ウィンドウサイズの変更の可否を判断する蓄積パケット量の下限値を設定する。又、蓄積パケット量が多く、輻輳が生じている場合には、データパケットの送信速度を速やかに抑え、輻輳を抑制する必要がある。そのため、定数βとして、蓄積パケット量が多い場合にウィンドウサイズの変更を適切に行えるように、ウィンドウサイズの変更の可否を判断する蓄積パケット量の上限値を設定する。
【００４０】
更に、キューイング遅延の変動が大きくなると、ウィンドウサイズや蓄積パケット量が一定の値に収束せずに振動が生じるおそれがある。そのため、定数αとβは、ウィンドウサイズの変更によるデータパケットの送信速度の抑制と向上が適切に行えるように、かつ、振動が生じないように決定することが好ましい。具体的には、定数αとβの間隔を振動が生じない程度に大きくして、ウィンドウサイズの変更を行わない安定な領域を増やすように定数α、βを設定する。
【００４１】
定数εは、０＜ε＜２の範囲で設定することが好ましい。例えば、Ｎ個の送信端末が、あるボトルネックとなっているルータ３０ａを経由して、データパケットを送信しているとする。ルータ３０ａがｎ番目にデータパケットを転送する送信端末に注目し、その送信端末のＲｏｕｎｄ（＃ｉ）におけるｃｗｎｄを「ｃｗｎｄ＿ｎ（＃ｉ）」、その送信端末と受信端末との間のＲＴＴを「ＲＴＴ＿ｎ」、そのＲＴＴｂａｓｅを「ＲＴＴｂａｓｅ＿ｎ」として（７）式に代入すると、以下に示す（９）式になる。
【００４２】
ｃｗｎｄ＿ｎ（＃ｉ＋２）
＝ｃｗｎｄ＿ｎ（＃ｉ）＋ε（δ―Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ））
＝ｃｗｎｄ＿ｎ（＃ｉ）＋ε｛δ―〔ｃｗｎｄ＿ｎ（＃ｉ）×Ｄ／（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）〕｝
＝｛１―〔εＤ／（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）〕｝×ｃｗｎｄ＿ｎ（＃ｉ）＋εδ（９）式
【００４３】
（９）式より、ｃｗｎｄ＿ｎ（＃ｉ＋２）が発散しないためには、（１０）式を満たす必要がある。  
｜｛１―〔εＤ／（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）〕｝｜＜１
０＜｛εＤ／（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）｝＜２          （１０）式
【００４４】
「Ｄ」は、ボトルネックとなるルータ３０ａによるデータパケットのキューイング遅延時間である。キューイング遅延時間Ｄは、ネットワーク４０等の状況に応じて変動する。そのため、定数εを、０＜ε＜２の範囲で設定することにより、キューイング遅延時間Ｄがどのような値をとっても、（１０）式を満たすことができる。
【００４５】
例えば、定数α、β、εを、α＝１、β＝３、ε＝１に設定し、（７）式、（８）式を用いてウィンドウサイズを決定する場合、以下に示す（７’）式、（８’）式のようになる。  
Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）＜１、又は、Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）＞３のとき、
ｃｗｎｄ（＃ｉ＋２）＝ｃｗｎｄ（＃ｉ）＋１×（２―Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ））  （７’）式
１≦Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）≦３のとき、
ｃｗｎｄ（＃ｉ＋２）＝ｃｗｎｄ（＃ｉ）  （８’）式  
【００４６】
このような（４）式〜（６）式、又は、（７）式及び（８）式を用いてウィンドウサイズの変動量およびウィンドウサイズを決定することにより、蓄積パケット量Ｑｕｅｕｅｄ＿ｐａｃｋｅｔと、定数α、βとのずれが大きい程、制御周期毎のウィンドウサイズの変更量を大きくできる。よって、蓄積パケット量が少なく、ネットワークの通信帯域に空きが生じ、その利用効率が低い場合や、蓄積パケット量が多く、輻輳が生じている場合に、制御周期毎のウィンドウサイズの変更量を大きくできる。更に、ウィンドウサイズの変更量を大きくし過ぎると、ウィンドウサイズや蓄積パケット量が一定値に収束せずに振動が生じ、ネットワーク４０が不安定になるおそれがある。しかし、（４）式〜（６）式、又は、（７）式及び（８）式を用いてウィンドウサイズの変動量およびウィンドウサイズを決定した場合には、以下に示すように、ネットワーク４０が安定な範囲内でウィンドウサイズを制御できる。上記（９）式を変形すると、（１１）式が得られる。
【００４７】
ｃｗｎｄ＿ｎ（＃ｉ＋２）―｛δ（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）／Ｄ｝
＝｛１―〔εＤ／（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）〕｝×｛ｃｗｎｄ＿ｎ（＃ｉ）―〔δ（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）／Ｄ〕｝  （１１）式
ここで、ａ＝１―｛εＤ／（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）｝、ｂ＝δ（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）／Ｄとおくと、（１２）式が得られる。  
ｃｗｎｄ＿ｎ（＃ｉ＋２）―ｂ＝ａ（ｃｗｎｄ＿ｎ（＃ｉ）―ｂ）  （１２）式
【００４８】
キューイング遅延時間Ｄが大きく変動しない場合、ａ、ｂは大きく変動しない。又、（１０）式より、｜ａ｜＜１である。そのため、時間の経過と共に、ｃｗｎｄ＿ｎ（＃ｉ＋２）は、ｂに近づいていく。よって、以下に示す（１３）式が得られる。  
ｃｗｎｄ＿ｎ（＃ｉ＋２）→δ（ＲＴＴｂａｓｅ＿ｎ＋Ｄ）／Ｄ
Ｄ×ｃｗｎｄ＿ｎ（＃ｉ＋２）／（ＲＴＴｂａｓｅ＋Ｄ）＝Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）→δ    （１３）式
【００４９】
このように蓄積パケット量Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）がδに近づいていく。よって、送信端末１０は、（４）式〜（６）式、又は、（７）式及び（８）式を用いてウィンドウサイズの変動量およびウィンドウサイズを決定することにより、蓄積パケット量が一定値に収束せずに発散してしまうことを防止できる。そのため、送信端末１０は、ネットワーク４０が、蓄積パケット量が発散しない安定な範囲内でウィンドウサイズを制御できる。
【００５０】
又、（３）式を用いて蓄積パケット量を計算することにより、以下に示すように、パケット量計算部１６は、蓄積パケット量として、送信端末１０がボトルネックのルータ３０ａに蓄積させているパケット量を計算できる。キューイング遅延時間Ｄが発生すると、（１４）式に示すようにＲＴＴが増大する。  
ＲＴＴ＝ＲＴＴｂａｓｅ＋Ｄ  （１４）式
このようにキューイング遅延時間Ｄは、ＲＴＴの変動から測定できる。（３）式に（１４）式を代入する。このとき、送信端末１０のデータパケットの送信速度を「Ｔ」とする。Ｔ＝ｃｗｎｄ（＃ｉ）／ＲＴＴ＿ａｖｅ（＃ｉ）である。
【００５１】
Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）
＝（ｃｗｎｄ（＃ｉ）／ＲＴＴ＿ａｖｅ（＃ｉ））×（ＲＴＴ＿ａｖｅ（＃ｉ）―ＲＴＴｂａｓｅ）
＝｛（ｃｗｎｄ（＃ｉ）／ＲＴＴｂａｓｅ）―（ｃｗｎｄ（＃ｉ）／（ＲＴＴ＿ａｖｅ（＃ｉ））｝×ＲＴＴｂａｓｅ
＝｛（ｃｗｎｄ（＃ｉ）／ＲＴＴｂａｓｅ）―〔ｃｗｎｄ（＃ｉ）／（ＲＴＴｂａｓｅ＋Ｄ）〕｝×ＲＴＴｂａｓｅ
＝（ｃｗｎｄ（＃ｉ）／ＲＴＴ＿ａｖｅ（＃ｉ））×Ｄ
＝Ｔ×Ｄ  （１５）式
【００５２】
キューイング遅延時間Ｄは、送信端末１０以外の端末装置が送信したデータパケットも含めた全てのトラフィック量によって決まる。しかし、ＴＣＰコネクションを確立した送信端末１０は、送信速度Ｔでデータパケットを常に送信する。そのため、送信端末１０からの全てのデータパケットがキューイング遅延時間Ｄの間、送信バッファ３１に蓄積され、待ち行列に入ってから、送信されると考えられる。よって、結局、Ｔ×Ｄで示されるＱｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）は、送信端末１０が送信バッファ３１に蓄積させている蓄積パケット量に相当する。
【００５３】
そして、送信制御部１２は、Ｒｏｕｎｄ（＃ｉ＋２）になると、ウィンドウサイズ制御部１７が決定したｃｗｎｄ（＃ｉ＋２）に従って、データパケットを受信端末２０に送信する。その後、同様にして、パケット量計算部１６、ウィンドウサイズ制御部１７は、蓄積パケット量Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ＋１）を計算し、ｃｗｎｄ（＃ｉ＋３）を決定する。以降、パケット量計算部１６、ウィンドウサイズ制御部１７は、蓄積パケット量Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ＋２）を計算し、ｃｗｎｄ（＃ｉ＋４）を決定するというように、２つ前の周期制御における蓄積パケット量を用いて、ウィンドウサイズの変更量及びウィンドウサイズを決定する。
【００５４】
尚、ウィンドウサイズ制御部１７は、ボトルネックとなっているルータ３０ａの送信バッファ３１の蓄積パケット量が、１〜３パケットに維持できるようにｃｗｎｄを制御することが好ましい。又、送信制御部１２は、ウィンドウサイズ制御部１７からウィンドウサイズの変更量を取得した場合には、（６）式を用いてウィンドウサイズを決定できる。
【００５５】
このような送信端末１０は、コンピュータに、コンピュータを、ネットワークのトラフィック状況を取得する取得手段と、トラフィック状況に基づいて、ウィンドウサイズの変更量を決定するウィンドウサイズ制御手段と、ウィンドウサイズの変更量に基づいて、データパケットの送信を制御する送信制御手段として機能させるためのプログラムを実行させることにより実現できる。このようなプログラムは記録媒体に格納しておき、コンピュータが記録媒体から読み出して実行する。
【００５６】
次に、通信システム１００を用いた通信方法について説明する。図６に示すように、Ｒｏｕｎｄ（＃ｉ）において、送信端末１０は、ｃｗｎｄ（＃ｉ）でデータパケットを送信する（Ｓ１０１）。このとき、送信端末１０は、各データパケットの送信時刻を記録する（Ｓ１０２）。Ｒｏｕｎｄ（＃ｉ＋１）になると、送信端末１０は、ｃｗｎｄ（＃ｉ＋１）でデータパケットを送信する（Ｓ１０３）。更に、送信端末１０は、Ｒｏｕｎｄ（＃ｉ）において送信したデータパケットのＡｃｋを受信する。そして、送信端末１０は、Ｒｏｕｎｄ（＃ｉ）において送信した各データパケットのＲＴＴを、ステップ（Ｓ１０２）で記録した送信時刻を用いて計算する（Ｓ１０４）。
【００５７】
送信端末１０は、Ｒｏｕｎｄ（＃ｉ）において送信したデータパケットのＡｃｋを全て受信すると、Ｒｏｕｎｄ（＃ｉ）におけるＲＴＴの平均値、ＲＴＴ＿ａｖｅ（＃ｉ）を計算する（Ｓ１０５）。そして、送信端末１０は、ＲＴＴ＿ａｖｅ（＃ｉ）を用いて、Ｒｏｕｎｄ（＃ｉ）における蓄積パケット量Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）を計算する（Ｓ１０６）。更に、送信端末１０は、蓄積パケット量Ｑｕｅｕｅｄ＿ｐａｃｋｅｔ（＃ｉ）を用いて、Ｒｏｕｎｄ（＃ｉ＋２）におけるｃｗｎｄ（＃ｉ＋２）を計算し、ウィンドウサイズの変更量に基づくウィンドウサイズを決定する（Ｓ１０７）。そして、送信端末１０は、Ｒｏｕｎｄ（＃ｉ＋２）になると、ｃｗｎｄ（＃ｉ＋２）でデータパケットを送信する（Ｓ１０８）。
【００５８】
このような通信システム１００、送信端末１０、送信端末１０を実現するプログラム及び通信方法によれば、ネットワーク４０のトラフィック状況を取得し、取得したトラフィック状況に応じてウィンドウサイズの変更量を動的に変更できる。そして、通信システム１００、送信端末１０は、動的に変更されたウィンドウサイズの変更量に基づいて動的に変更されたウィンドウサイズを用いて、データパケットを送信できる。しかも、通信システム１００、送信端末１０は、蓄積パケット量を用いて変更量を計算することにより、容易に適切なウィンドウサイズの変更量を決定できる。そのため、通信システム１００、通信装置１０は、ネットワーク４０のトラフィック状況の変化に、適切に追従してデータパケットを送信できる。
【００５９】
より具体的には、通信システム１００、通信装置１０は、１ＲＴＴの長さを持つ制御周期（Ｒｏｕｎｄ）毎のｃｗｎｄの増減量を、トラフィック状況に合わせて動的に変更できる。そのため、通信システム１００、通信装置１０は、トラフィック状況の変化に対する追従性を向上できる。よって、通信システム１００、通信装置１０は、輻輳が発生した場合には速やかに輻輳を緩和し、ネットワークの通信帯域に空きが生じた場合には、速やかに空いた通信帯域を有効に利用できる。
【００６０】
尚、本発明は上記実施形態に限定されるものではなく、種々の変更が可能である。例えば、通信装置として、ウィンドウサイズを制御する制御装置を通信システムに設けてもよい。そして、制御装置が、ネットワーク４０のトラフィック状況を取得して、ウィンドウサイズの変更量やそれに基づくウィンドウサイズを決定し、各送信端末に通知することにより、データパケットの送信を制御してもよい。又、例えば、パケット量計算部１６、ウィンドウサイズ制御部１７、送信制御部１２が、別々の通信装置に設けられてもよい。
【図面の簡単な説明】
【００６１】
【図１】本発明の第１の実施の形態に係る通信システムの構成を示す図である。
【図２】本発明の第１の実施の形態に係る送信端末の構成を示すブロック図である。
【図３】本発明の第１の実施の形態に係るＲｏｕｎｄ（＃ｉ）における通信システムの状況を示す図である。
【図４】本発明の第１の実施の形態に係るＲｏｕｎｄ（＃ｉ＋１）開始時の通信システムの状況を示す図である。
【図５】本発明の第１の実施の形態に係るＲｏｕｎｄ（＃ｉ＋１）終了時の通信システムの状況を示す図である。
【図６】本発明の本発明の第１の実施の形態に係る通信方法の手順を示すフロー図である。
【図７】従来の輻輳制御方法を示す図である。
【符号の説明】
【００６２】
１００  通信システム
１０，２１０  送信端末
１１  送信バッファ
１２  送信制御部
１３  通信インタフェース
１４  送信記録テーブル
１５  時計部
１６  パケット量計算部
１７  ウィンドウサイズ制御部
２０  受信端末
３０ａ，３０ｂ，２３０  ルータ
３１，２３１  送信バッファ
４０  ネットワーク
【図１】
2005218069.tif 000003
【図２】
2005218069.tif 000004
【図３】
2005218069.tif 000005
【図４】
2005218069.tif 000006
【図５】
2005218069.tif 000007
【図６】
2005218069.tif 000008
【図７】
2005218069.tif 000009