(57)【要約】【課題】アプリケーションレベルの簡易な構成で、受信確認のないプロトコルが使用できないネットワーク上の可用帯域の推定を高精度に行う。【解決手段】本発明の制御システムは、送信側装置７００が、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用いて、パケットトレイン等の第１のパケット列の送信前に、暖機パケット列を受信側装置８００に送信する暖機パケット列送信手段７０１と、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置８００における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段７０３と、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段７０２とを備えている。【選択図】図８
2019012866.tif 000002
【特許請求の範囲】
【請求項１】
送信側の通信装置である送信側装置と、受信側の通信装置である受信側装置とを備え、
前記送信側装置は、
受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、前記プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、前記受信側装置に送信する暖機パケット列送信手段と、
前記暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、
前記暖機パケット列の送信の結果取得される、前記暖機パケット列に含まれる各暖機パケットの送信時刻および前記受信側装置における受信時刻に基づいて、前記暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段とを含み、
前記暖機パケット数決定手段は、前記輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する
ことを特徴とする制御システム。
【請求項２】
暖機パケット数決定手段は、第１のパケット列に含まれるパケット数から、推定された輻輳ウィンドウサイズの最低値を引いた値を、再送信を行う暖機パケット列に含ませる暖機パケットの数とする
請求項１に記載の制御システム。
【請求項３】
ウィンドウサイズ推定手段は、第１のパケット列の暖機パケット列の送信の結果取得される、前記第１のパケット列に含まれる各暖機パケットの送信時刻および前記受信側装置における受信時刻に基づいて、前記第１のパケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定し、
暖機パケット数決定手段は、前記輻輳ウィンドウサイズの最低値の推定結果を基に、次回の第１のパケットの送信前に送信を行う暖機パケット列に含ませる暖機パケットの数を決定する
請求項１または請求項２に記載の制御システム。
【請求項４】
暖機パケット数決定手段は、第１のパケット列の送信時およびその前の暖機パケット列の送信時にいずれのパケットロスも発生しなかった場合には、次回の第１のパケットの送信前に送信を行う暖機パケット列に含ませる暖機パケットの数を０に決定する
請求項３に記載の制御システム。
【請求項５】
送信側装置は、
暖機パケット列に含まれる各暖機パケットの、送信時刻および受信側装置における受信時刻を取得する送受信時刻取得手段と、
前記暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻から、前記暖機パケット列の送信中におけるアプリケーションレベルでのラウンドトリップタイムであるＲＴＴおよびプロトコルスタックレベルでの再送タイマの値であるＲＴＯ−ｖａｌを算出するタイマ値推定手段と、
前記暖機パケット列に含まれる各暖機パケットの送信時刻から特定される前記暖機パケットの送信間隔と、前記暖機パケット列に含まれる各暖機パケットの受信時刻から特定される前記暖機パケットの受信間隔と、前記ＲＴＴと、前記ＲＴＯ−ｖａｌとに基づいて、パケットロスが発生したか否かおよびその際の輻輳の度合いが軽度か重度かを判定するパケットロス判定手段とを含み、
ウィンドウサイズ推定手段は、前記パケットロス判定手段による判定結果に基づいて、輻輳ウィンドウサイズの最低値を推定する
請求項１から請求項４のうちのいずれか１項に記載の制御システム。
【請求項６】
ウィンドウサイズ推定手段は、暖機パケット列の送信により受け取る受信確認の数と、軽度および重度の輻輳によるパケットロスの発生回数とに少なくとも基づいて、輻輳ウィンドウサイズの最低値を推定する
請求項５に記載の制御システム。
【請求項７】
送信側の通信装置である送信側装置と、受信側の通信装置である受信側装置とを備え、
前記送信側装置は、
受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、前記プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、前記受信側装置に送信する暖機パケット列送信手段と、
前記暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、
前記暖機パケット列の送信の結果取得される、前記暖機パケット列に含まれる各暖機パケットの送信時刻および前記受信側装置における受信時刻に基づいて、前記暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段と、
前記輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、
前記第１のパケット列を、前記受信側装置に送信する第１パケット列送信手段とを含み、
前記受信側装置は、
前記第１のパケット列の受信結果に基づいて、送信側装置と受信側装置間の通信経路における可用帯域を推定する可用帯域推定手段を含み、
前記暖機パケット数決定手段は、前記輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する
ことを特徴とする可用帯域推定システム。
【請求項８】
受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、前記プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に送信する暖機パケット列送信手段と、
前記暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、
前記暖機パケット列の送信の結果取得される、前記暖機パケット列に含まれる各暖機パケットの送信時刻および前記受信側装置における受信時刻に基づいて、前記暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段とを備え、
前記暖機パケット数決定手段は、前記輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する
ことを特徴する通信装置。
【請求項９】
送信側の通信装置である送信側装置が、
受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、前記プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に向けて送信し、
前記暖機パケット列の送信の結果取得される、前記暖機パケット列に含まれる各暖機パケットの送信時刻および前記受信側装置における受信時刻に基づいて、前記暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定し、
前記輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定し、
決定された暖機パケットの数が１以上である場合に、前記第１のパケット列の送信前に、決定された数の暖機パケットを含む暖機パケット列の再送信を行う
ことを特徴とする制御方法。
【請求項１０】
コンピュータに、
受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、前記プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に送信する処理、
前記暖機パケット列の送信の結果取得される、前記暖機パケット列に含まれる各暖機パケットの送信時刻および前記受信側装置における受信時刻に基づいて、前記暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定する処理、および
前記輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する処理
を実行させるための制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、可用帯域の推定を行う可用帯域推定システム並びに輻輳ウィンドウサイズを制御するための制御システム、通信装置、制御方法および制御プログラムに関する。
【背景技術】
【０００２】
通信回線の可用帯域（利用可能帯域とも呼ばれる）とは、通信回線のボトルネックリンクの物理帯域から、ネットワークに流れている他のトラヒック（以下、クロストラヒックと呼ぶ）を引いた空き帯域である。例えば、通信回線のボトルネックリンクの物理帯域が１００Ｍｂｐｓ、クロストラヒックが３０Ｍｂｐｓの場合には、可用帯域は１００−３０＝７０Ｍｂｐｓとなる。
【０００３】
時々刻々と変動する可用帯域の現在の値を推定することは、端末間で双方向に映像データを送り合ってコミュニケーションをするビデオチャットやテレビ電話、テレビ会議などにおいて重要である。その理由は、映像データを送信する際のパケットの送信レートを可用帯域の推定値以下に抑えることで、パケットの送信レートとクロストラヒックの合計が通信回線のボトルネックリンクの物理帯域を超過することを防止できるので、パケットの送信遅延による映像品質の劣化を防止できるためである。
【０００４】
可用帯域の推定技術に関して、例えば、特許文献１には、可用帯域推定用のパケットである推定パケットを複数まとめて１つのパケットトレインと称し、パケットトレインに含まれる各推定パケットを所定の時間間隔で送信することで、受信装置側で可用帯域を推定する方法が記載されている。特許文献１に記載の方法は、送信側装置が、パケットが徐々に増加する複数の推定パケットからなるパケットトレインを用意し、該パケットトレインに含まれる推定パケットを順番に等間隔で送信する。そして、受信側装置が、各推定パケットの受信間隔の変化を検出することで、可用帯域を推定する。
【０００５】
この方法によれば、パケットトレイン内で、各推定パケットの送信レートが線形に増加する。パケットトレインがネットワークを通過する際に、推定パケットの送信レートがネットワークの可用帯域を超えた場合には、ネットワーク上のルータやスイッチなどの装置において一時的にパケットがキューイングされる（以下、キューイングによる遅延をキューイング遅延と呼ぶ）。キューイング遅延が発生すると、受信側装置において、推定パケットの受信間隔が送信側装置での送信間隔よりも増加する。この性質を利用して、受信側装置は、受信間隔が送信側装置での送信間隔と比較して増加し始める推定パケットを特定し、その推定パケットのパケットサイズを送信間隔で除算することで、可用帯域を算出する。
【０００６】
また、例えば、特許文献２には、送信側装置のマイクロプロセッサが輻輳ウィンドウのウィンドウサイズを変化させながらラウンドトリップタイム（Round-Trip Time；ＲＴＴ）と、パケットロス率を測定して、これら測定値とパケット１つあたりのデータサイズとから可用帯域を推定する方法が記載されている。また、特許文献２には、さらに、再送タイムアウト（Retransmission TimeOut；ＲＴＯ）が発生したか否かによって異なる計算式を用いて、可用帯域を推定する方法も記載されている。
【０００７】
また、トラフィックの輻輳が予想される場合など事前設定した時間帯に、予め準備用のパケットを流して他のトラフィックを押しのけておき、その後でアプリケーションの送信をする技術が特許文献３に記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】国際公開第２０１４／０１７１４０号パンフレット
【特許文献２】特開２０１４−１６５８０９号公報
【特許文献３】特表２００９−５３１９１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１に記載の方法は、通信路におけるパケットフローの監視をしなくても、アプリケーション層で簡易に可用帯域を推定することができるため、様々な環境に導入しやすく、好ましい。例えば、特許文献２に記載の方法は、輻輳ウィンドウサイズの変更や、ＲＴＴやパケットロス率の計測、ＲＴＯの発生有無の判定など、アプリケーション層より下位における動作が必要であり、導入コストがかかるといった問題がある。また、計算式は、輻輳制御における一般的なパケット数の時間的推移を基に再送タイムアウトによる輻輳制御による送信遅延のみを考慮しているものであって、例えば、上記で示したような、キューイング遅延等は考慮されておらず、可用帯域の推定精度がよいとは言えない。
【００１０】
なお、特許文献１に記載の方法も、送信側装置からの推定パケットの送信タイミングに誤差が生じると、推定精度が低下するという問題がある。高精度に可用帯域を推定するためには、推定値算出用のアプリケーションソフトウェアが指定したタイミングで正確に推定パケットが連続送信されなければならない。そのために、推定パケットとしては、アプリケーションから送信タイミングを制御しやすいＵＤＰ（User Datagram Protocol）パケットが利用される。また、可用帯域の時間的な推移や、一定以上の時間内における可用帯域の平均値を把握するために、パケットトレインは定期的に送信されることが多い。
【００１１】
しかし、ファイアウォールなどによりＵＤＰによる通信ができないネットワーク環境では、特許文献１に記載の方法が利用できない。そこで、ＵＤＰ通信ができないネットワーク環境に対応するために、プロトコルを単純にＵＤＰからＴＣＰ（Transmission Control Protocol）に変更することを考えてみる。この場合、通信自体はできるようになるものの、ＴＣＰの輻輳制御が「外乱」となり、パケットの連続送信が途中で一時中断する現象が発生する。
【００１２】
この現象を説明するための基礎知識として、ＴＣＰ通信の概要を説明する。ＴＣＰ通信では、ＯＳが駆動するＴＣＰ用のプロトコルスタックによって輻輳制御が働く。以下、アプリケーション層との対比という意図で、ＴＣＰ用のプロトコルスタックも含めてＯＳという。輻輳制御として、ＴＣＰの送信側のＯＳは、輻輳ウィンドウサイズ（以下、ｃｗｎｄと呼ぶ）を管理している。なお、ｃｗｎｄの値を保持する変数はＯＳが管理する内部変数であるため、アプリケーションから直接観測できない場合が多い。
【００１３】
ＴＣＰの送信側のＯＳは、ｃｗｎｄと同じ個数だけ、ＴＣＰの受信側のプロトコルスタックからのＡＣＫ（肯定応答）を待たずにパケットを連続送信できる。例えば、ｃｗｎｄの値が１０である場合には、ＴＣＰの送信側のＯＳは、パケットを１０個まで連続送信でき、ＡＣＫが返って来ない場合には、ＡＣＫが返ってくるまで連続送信が一時中断される。ＡＣＫが返ってくるとｃｗｎｄを増加させた上で、一時中断していた連続送信を再開する。ＴＣＰ通信では、この連続送信と一時中断の繰り返しが発生するのが一般的である。
【００１４】
また、ＴＣＰの送信側のＯＳは、各パケットの送信時刻と対応するＡＣＫの受信時刻から、各パケットのＲＴＴを計測する。そして、各パケットのＲＴＴを計測する度に、標準規格であるＩＥＴＦ  ＲＦＣ  ６２９８（以下、非特許文献１という。）に記載の下記の数式により、再送タイムアウト値（以下、ＲＴＯが発生する時間をＲＴＯ−ｖａｌという）を算出する。
【００１５】
まず、初回のパケットのＲＴＴを計測したら、ＲＴＴの指数加重移動平均値ＳＲＴＴと、ＲＴＴの平均偏差ＲＴＴＶＡＲと、ＲＴＯ−ｖａｌとを、以下のとおり初期化する。なお、左向きの矢印は、右辺の変数への左辺の値の代入を表す。また、ｍａｘ（Ａ，Ｂ）はＡとＢのうちのより大きい方の値を取り出す関数である。
【００１６】
・ＳＲＴＴ←ＲＴＴ
・ＲＴＴＶＡＲ←ＲＴＴ／２
・ＲＴＯ−ｖａｌ←ＳＲＴＴ＋ｍａｘ（Ｇ，Ｋ＊ＲＴＴＶＥＲ）
【００１７】
次に、２番目以降のパケットのＲＴＴを計測する度に、ＳＲＴＴと、ＲＴＴＶＡＲと、ＲＴＯ−ｖａｌとを、以下の通り更新する。
【００１８】
・ＲＴＴＶＡＲ←（１−ｂｅｔａ）＊ＲＴＴＶＡＲ＋β＊｜ＳＲＴＴ−ＲＴＴ｜
・ＳＲＴＴ←（１−ａｌｐｈａ）＊ＳＲＴＴ＋α＊ＲＴＴ
・ＲＴＯ−ｖａｌ←ＳＲＴＴ＋ｍａｘ（Ｇ，Ｋ＊ＲＴＴＶＡＲ）
【００１９】
なお、Ｇ，Ｋ，α，βは、既定の定数である。ＴＣＰの送信側のＯＳは、各パケットの送信時に、このＲＴＯ−ｖａｌをタイムアウト値とする再送タイマを起動する。
【００２０】
また、ＴＣＰ通信では、ＴＣＰの送信側のＯＳが、パケットロスが発生したと判断すると、ネットワークの輻輳を回避するためにｃｗｎｄの値を低下させる。パケットロスの発生の判断には２種類があり、軽度の輻輳によるパケットロスと、重度の輻輳によるパケットロスである。それらの間ではｃｗｎｄの値の低下の挙動が異なる。
【００２１】
図１０は、軽度の輻輳によるパケットロス発生例を示す説明図である。また、図１１は、重度の輻輳によるパケットロス発生例を示す説明図である。なお、両例とも１００個のパケットの送信を、送信側装置のアプリケーション側から依頼されたものとする。また、送信側装置における送信前のｃｗｎｄの値は１００であるものとする。なお、図１０および図１１では、図の複雑さを避けるために意図的にパケットを送信してからＡＣＫが返ってくるまでの往復遅延に相当するＲＴＴを短くして各パケットのやり取りの直線が重ならないようにしている。ただし、本来は、パケットの送信間隔よりもＲＴＴの方が長い場合が多い。例えば、９０番目のパケットのＡＣＫは、図１１では９１番目のパケットの送信前に返ってきているが、本来は、９０番目のパケットだけでなくそれ以降の複数のパケットを連続送信した後で返ってくる場合が多い。
【００２２】
軽度の輻輳によるパケットロスの発生例を示す図１０では、９０番目のパケットが受信側装置に届くと、送信側装置に９０番目まで届いたことを示すＡＣＫが返信される。本例では、９１番目のパケットでパケットロスが発生したとする。そのような場合に、９２番目のパケットが受信側装置に届くと、受信側装置は、９１番目のパケットが届いていないので、送信側装置に９０番目まで届いたことを示す２回目のＡＣＫを返信する。次いで、９３番目のパケットが受信側装置に届くと、受信側装置は、９１番目のパケットが届いていないので、送信側装置に再度９０番目まで届いたことを示すＡＣＫを返信する。送信側装置は、９０番目まで届いたことを示すＡＣＫが３回重複して届いた時点で、初めて９１番目のパケットでパケットロスが発生したと判断する。所定回数の重複ＡＣＫ受信によりパケットロスの発生を検知すると、送信側装置は、これまでにＡＣＫが帰ってきていない９１番目のパケットを再送するとともに、ｃｗｎｄの値を変更する。この場合、送信側装置は、ｃｗｎｄの値を例えば０．７倍にする。なお、何倍にするかはＴＣＰの実装によって異なる。例えば、Ｌｉｎｕｘ（登録商標）  ＯＳにおいてデフォルトで使われるＣＵＢＩＣ  ＴＣＰの場合は０．７倍である。仮に、パケットロスの発生を検知した時点のｃｗｎｄの値が１９０であったとすると、送信側装置は、ｃｗｎｄの値を１９０から１３３へと減少させる。以下、このような所定回数の重複ＡＣＫにより検知されるパケットロスを軽度の輻輳によるパケットロスと呼ぶ場合がある。
【００２３】
重度の輻輳によるパケットロスの発生例を示す図１１では、９０番目のパケットが受信側装置に届くと、送信側装置に９０番目まで届いたことを示すＡＣＫが返信される。なお、送信側装置は、ＡＣＫを受信する度にＲＴＯの値（ＲＴＯ−ｖａｌ）を更新している。本例では、９１、９２、９３番目のパケットでパケットロスが発生したとする。そして、送信側装置において、９４番目のパケットを送信する前に、９１番目のパケットの送信時に起動した再送タイマがタイムアウトする（ＲＴＯ発生）。送信側装置は、ＲＴＯ発生により、これまでにＡＣＫが返ってきていない９１、９２、９３番目のパケットでパケットロスが発生したと判断する。ＲＴＯ発生によりパケットロスの発生を検知すると、送信側装置は、これまでにＡＣＫが帰ってきていない９１、９２、９３番目のパケットを再送するとともに、ｃｗｎｄの値を変更する。この場合、送信側装置は、ｃｗｎｄの値を例えば２にする。なお、いくつの値にするかはＴＣＰの実装によって異なる。仮に、パケットロスの発生を検知した時点のｃｗｎｄの値が１９０であったとすると、送信側装置は、ｃｗｎｄの値を１９０から２へと大きく減少させる。以下、このようなＲＴＯ発生により検知されるパケットロスを、重度の輻輳によるパケットロスと呼ぶ場合がある。
【００２４】
なお、ｃｗｎｄと同様、ＴＣＰレベルのＲＴＴやＲＴＯ−ｖａｌなどは、ＯＳが管理する内部変数であるため、アプリケーションから直接観測できない場合が多い。
【００２５】
次に、ＴＣＰの輻輳制御が「外乱」となり、パケットの連続送信が途中で一時中断する現象について説明する。
【００２６】
ここでは、１００個の推定パケットを１つのパケットトレインとし、複数のパケットトレインを定期的に送信する場合を考える。まず、１つのパケットトレインを送信中に、軽度の輻輳によるパケットロスが発生したとする。軽度の輻輳によるパケットロスが１回程度であれば、パケットロス発生時またはパケットロス発生後のＡＣＫ受信によりパケットトレイン送信終了時のｃｗｎｄの値は十分に大きくなっていることが考えられる。しかし、軽度の輻輳によるパケットロスが複数回発生した場合には、パケットトレイン送信終了時のｃｗｎｄの値が１００を下回ることも考えられる。例えば、次回のパケットトレインの送信時のｃｗｎｄの値が７０であったとする。この場合、７０番目の推定パケットまでは連続送信ができるものの、その直後に推定パケットの連続送信が一時中断してしまう。すると、送信側装置からの推定パケットの送信タイミングに誤差が生じ、推定精度が低下してしまう。
【００２７】
また、１つのパケットトレインを送信中に、重度の輻輳によるパケットロスが発生したとする。この場合、次回のパケットトレインの送信時にはｃｗｎｄの値が大幅に小さくなる。例えば、次回のパケットトレインの送信時のｃｗｎｄの値が２とであったとする。この場合、２番目の推定パケットまでは連続送信ができるものの、その直後に推定パケットの連続送信が一時中断してしまい、やはり推定精度が低下してしまう。
【００２８】
したがって、ＴＣＰなどの、ＡＣＫ送信（受信確認）およびウィンドウによる輻輳制御があるプロトコルを用いてパケットトレインを送信するに当たっては、毎回、何らかの方法によりｃｗｎｄの値を十分大きくしておくことが重要である。そうしないと、送信途中で推定パケットの連続送信が一時中断し、推定精度が低下してしまうからである。
【００２９】
なお、特許文献３に記載の方法は、準備用パケットを送信することにより、わざと輻輳を起こさせ、それによりアプリケーションのパケットよりも優先度の低いパケットが送信されないようにする方法であり、それによりｃｗｎｄを、アプリケーションのパケットの連続送信が可能な値まで十分に大きくしようといったことは全く考慮されていない。そもそも特許文献３では、アプリケーションのパケットは高精度な連続送信は要求されていないため、その必要もない。
【００３０】
そこで、上述した問題に鑑み、本発明は、アプリケーションレベルの簡易な構成で、受信確認のないプロトコルが使用できないネットワーク上の可用帯域の推定を高精度に行うことが可能な可用帯域推定システム、並びにそのための輻輳ウィンドウサイズの制御を行う制御システム、通信装置、制御方法および制御プログラムの提供を目的とする。
【００３１】
また、本発明は、可用帯域の推定用途に限らず、受信確認およびウィンドウによる輻輳制御があるプロトコルを用いて所定のパケット列を送信する場合に、アプリケーションレベルの簡易な構成で、事前に輻輳ウィンドウを当該パケット列の連続送信が可能なサイズまで大きくすることができる制御システム、制御方法および制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００３２】
本発明による制御システムは、送信側の通信装置である送信側装置と、受信側の通信装置である受信側装置とを備え、送信側装置は、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、受信側装置に送信する暖機パケット列送信手段と、暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段とを含み、暖機パケット数決定手段は、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定することを特徴とする。
【００３３】
本発明による可用帯域推定システムは、送信側の通信装置である送信側装置と、受信側の通信装置である受信側装置とを備え、送信側装置は、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、受信側装置に送信する暖機パケット列送信手段と、暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段と、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、第１のパケット列を、受信側装置に送信する第１パケット列送信手段とを含み、受信側装置は、第１のパケット列の受信結果に基づいて、送信側装置と受信側装置間の通信経路における可用帯域を推定する可用帯域推定手段を含み、暖機パケット数決定手段は、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定することを特徴とする。
【００３４】
本発明による通信装置は、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に送信する暖機パケット列送信手段と、暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段とを備え、暖機パケット数決定手段は、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定することを特徴する。
【００３５】
本発明による制御方法は、送信側の通信装置である送信側装置が、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に向けて送信し、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定し、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定し、決定された暖機パケットの数が１以上である場合に、第１のパケット列の送信前に、決定された数の暖機パケットを含む暖機パケット列の再送信を行うことを特徴とする。
【００３６】
本発明による制御プログラムは、コンピュータに、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に送信する処理、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定する処理、および輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する処理を実行させることを特徴とする。
【発明の効果】
【００３７】
本発明によれば、アプリケーションレベルの簡易な構成で、受信確認のないプロトコルが使用できないネットワーク上の可用帯域の推定を高精度に行うことができる。また、本発明によれば、受信確認およびウィンドウによる輻輳制御があるプロトコルを用いて所定のパケット列を送信する場合に、アプリケーションレベルの簡易な構成で、事前に輻輳ウィンドウを当該パケット列の連続送信が可能なサイズまで大きくすることができる。
【図面の簡単な説明】
【００３８】
【図１】第１の実施形態の可用帯域推定システムのネットワーク構成の一例を示すネットワーク構成図である。
【図２】可用帯域推定システムに含まれる送信側装置１および受信側装置２のより詳細な構成例を示すブロック図である。
【図３】データ記憶手段１７が記憶するデータのデータ構造の例を示す説明図である。
【図４】データ記憶手段２２が記憶するデータのデータ構造の例を示す説明図である。
【図５】第１の実施形態の可用帯域推定システムの動作の一例を示すフローチャートである。
【図６】送信側装置１のアプリケーション層における軽度の輻輳によるパケットロスの判定方法の説明図である。
【図７】送信側装置１のアプリケーション層における重度の輻輳によるパケットロスの判定方法の説明図である。
【図８】本発明による制御システムの概要を示すブロック図である。
【図９】本発明による制御システムの他の構成例を示すブロック図である。
【図１０】軽度の輻輳によるパケットロス発生例を示す説明図である。
【図１１】重度の輻輳によるパケットロス発生例を示す説明図である。
【発明を実施するための形態】
【００３９】
次に、本発明の実施形態について図面を参照して説明する。図１は、本発明の第１の実施形態の可用帯域推定システムのネットワーク構成の一例を示すネットワーク構成図である。図１に示す可用帯域推定システムは、送信側装置１と、受信側装置２とが、ネットワーク３を介して接続されている。
【００４０】
送信側装置１と受信側装置２とはそれぞれ、パーソナルコンピュータ（ＰＣ）、携帯型コンピュータ（ＰＤＡ）、携帯電話、スマートフォン、タブレット端末、固定電話、街頭マルチメディア端末、車載端末、ネットワーク接続機能付きテレビ、ネットワーク接続機能付きセットトップボックス、ゲーム機、ネットワーク接続機能付きプリンタ、ネットワーク接続機能付きスキャナ、外部と情報をやり取りする機能を備えたその他の類似装置であってよい。
【００４１】
また、ネットワーク３には、送信側装置１と受信側装置２以外の図示しない装置が接続されていてもよく、これらの図示しない装置間でクロストラヒックが流れていてもよい。
【００４２】
次に、本実施形態の概要を説明する。本実施形態の可用帯域推定システムは、まず、送信側装置１が、パケットトレインの送信前に、複数のＴＣＰパケットであり準備用のパケット（以下、暖機パケットと呼ぶ）を１つのまとまりとする暖機パケット列を送信する。そして、送信側装置１は、暖機パケット列の各暖機パケットに対する応答パケット等に記憶される受信時刻等を用いて、各暖機パケットの受信間隔を算出し、アプリケーションレベルのＲＴＴを計測する。そして、送信側装置１は、計測したアプリケーションレベルのＲＴＴからＴＣＰレベルのＲＴＯ−ｖａｌを推定し、上述の受信間隔とＲＴＴとＲＴＯ−ｖａｌを基に、ＴＣＰレベルでの重度の輻輳または軽度の輻輳によるパケットロスが発生したかどうかを判定する。ここで、上記のパケットロスが発生したと判定した場合には、送信側装置１は、輻輳の度合いに合わせて暖機パケット数を必要最小限の個数に調整した上で暖機パケット列を再度送信する。これにより、パケットトレインの送信前に、ｃｗｎｄを十分大きな値まで増大することができる。
【００４３】
加えて、本実施形態の送信側装置１は、パケットトレインの送信に際しても、各推定パケットの受信間隔の算出、アプリケーションレベルのＲＴＴの計測、ＴＣＰレベルのＲＴＯ−ｖａｌの推定を行って、これらに基づき推定されるパケットロスの発生有無に基づいて次回の暖機パケット列の暖機パケット数を調整してもよい。
【００４４】
暖機パケット列の送信時とパケットトレインの送信時の両方においてＴＣＰレベルでパケットロスが発生したかどうかを判定し、パケットロスの発生有無と輻輳の度合いに応じて、次に送るべき暖機パケット数を調整することで、暖機パケットの送信数を全体的に抑えることができる。なお、本実施形態では、パケットトレインの送信に用いるプロトコルがＴＣＰである場合を例に説明するが、プロトコルは、ＴＣＰに限られず、受信確認およびウィンドウによる輻輳制御があるプロトコルであればよい。
【００４５】
図２は、可用帯域推定システムに含まれる送信側装置１および受信側装置２のより詳細な構成例を示すブロック図である。
【００４６】
送信側装置１は、パケット送信手段１０と、パケット列生成手段１１と、暖機パケット数決定手段１２と、受信間隔算出手段１３と、タイマ値推定手段１４と、パケットロス判定手段１５と、輻輳ウィンドウサイズ推定手段１６と、データ記憶手段１７と、を含んでいてもよい。
【００４７】
パケット送信手段１０は、暖機パケット列やパケットトレインを送信する。以下では、暖機パケット列における各暖機パケットと、パケットトレインにおける各推定パケットとを特に区別する必要がない場合は、「パケット列における各パケット」または単に「各パケット」という場合がある。
【００４８】
パケット列生成手段１１は、暖機パケット列やパケットトレインを生成する。
【００４９】
暖機パケット数決定手段１２は、暖機パケット列に含ませる暖機パケット数を決定する。
【００５０】
受信間隔算出手段１３は、受信側装置２で記録されたパケットの受信時刻を基に、パケット列の各パケットの受信間隔を算出する。
【００５１】
タイマ値推定手段１４は、各パケットのアプリケーションレベルの送信時刻と、当該各パケットに対する応答パケットの受信時刻とから、アプリケーションレベルのＲＴＴを算出し、それからＴＣＰレベルのＲＴＯのタイマ値であるＲＴＯ−ｖａｌを推定する。
【００５２】
パケットロス判定手段１５は、パケット列の各パケットの受信間隔と、算出されたアプリケーションレベルのＲＴＴと、推定されたＲＴＯ−ｖａｌとを用いて、ＴＣＰレベルで重度の輻輳または軽度の輻輳によるパケットロスが発生したかどうかを判定する。
【００５３】
輻輳ウィンドウサイズ推定手段１６は、上記のパケットロスの発生の判定結果に基づいて、ｃｗｎｄの値を推定する。
【００５４】
データ記憶手段１７は、各種データを格納する。図３は、データ記憶手段１７が記憶するデータのデータ構造の例を示す説明図である。図３に示すように、データ記憶手段１７は、暖機パケット数３０と、１つ以上の暖機パケット送信間隔３１と、１つ以上の暖機パケット受信間隔３２と、１つ以上のＲＴＴ計測値４０と、１つ以上のＲＴＯ推定値４１と、輻輳ウィンドウサイズ推定値４２と、推定パケット数５０と、１つ以上の推定パケット送信間隔５１と、１つ以上の推定パケット受信間隔５２とを記憶してもよい。
【００５５】
ここで、暖機パケット数３０は、暖機パケット列に含まれる暖機パケットの個数である。暖機パケット送信間隔３１は、各暖機パケットの送信間隔である。暖機パケット受信間隔３２は、各暖機パケットの受信間隔である。ＲＴＴ計測値４０は、上述したアプリケーションレベルのＲＴＴの算出値である。ＲＴＯ推定値４１は、上述したＴＣＰレベルのＲＴＯ−ｖａｌの推定値である。輻輳ウィンドウサイズ推定値４２は、送信側装置１におけるＴＣＰレベルのｃｗｎｄの推定値である。
【００５６】
また、推定パケット数５０は、パケットトレインに含まれる推定パケットの個数である。この個数は、システムの利用者や管理者が手動で設定する。推定パケット送信間隔５１は、各推定パケットの送信間隔である。推定パケット受信間隔５２は、各推定パケットの受信間隔である。
【００５７】
また、受信側装置２は、図２に示すように、パケット受信手段２０と、可用帯域推定手段２１と、データ記憶手段２２と、を含んでいてもよい。
【００５８】
パケット受信手段２０は、暖機パケットや推定パケットを受信した場合に、対応する応答パケットを、ＴＣＰレベルのＡＣＫパケットとともに返信する。
【００５９】
可用帯域推定手段２１は、可用帯域を推定する。可用帯域推定手段２１は、例えば、パケットトレインとしてまとめられた所定の時間間隔で連続送信される複数の推定パケットを受信した際の各パケットの受信間隔の変化の有無等から、可用帯域を推定できる。
【００６０】
データ記憶手段２２は、各種データを格納する。図４は、データ記憶手段２２が記憶するデータのデータ構造の例を示す説明図である。図４に示すように、データ記憶手段２２は、可用帯域推定値５９を記憶してもよい。
【００６１】
可用帯域推定値５９は、可用帯域の推定値である。
【００６２】
本実施形態において、パケット送信手段１０、パケット列生成手段１１、暖機パケット数決定手段１２、受信間隔算出手段１３、タイマ値推定手段１４、パケットロス判定手段１５および輻輳ウィンドウサイズ推定手段１６は、例えば、送信側装置１が備えるＣＰＵ等のプログラムに従って動作する情報処理装置によって実現される。また、データ記憶手段１７は、例えば、記憶装置によって実現される。また、可用帯域推定手段２１は、例えば、受信側装置２が備えるＣＰＵ等のプログラムに従って動作する情報処理装置によって実現される。また、データ記憶手段２２は、例えば、記憶装置によって実現される。
【００６３】
次に、図５を参照して本実施形態の動作を説明する。図５は、本実施形態の可用帯域推定システムの動作の一例を示すフローチャートである。なお、図５に示す例において、推定パケット数５０には、本システムの利用者や管理者により手動で１００が設定されているものとする。換言すると、本例では、１つのパケットトレインに含まれる推定パケット数として１００個が指定されているものとする。また、暖機パケット送信間隔３１や、推定パケット送信間隔５１には、本システムの利用者や管理者により手動で所望の値が設定されている。ここで、１つの暖機パケット列に含まれる各暖機パケットの送信間隔は同一でなくてもよい。同様に、１つのパケットトレインに含まれる各推定パケットの送信間隔は同一でなくてもよい。
【００６４】
図５に示す例では、まず、ステップＳ６０において、送信側装置１の暖機パケット数決定手段１２が、暖機パケット列に含ませる暖機パケットの個数を、データ記憶手段１７に保持されている暖機パケット数３０と同じ値に設定する。初回のパケットトレインの送信時には、暖機パケット数３０を推定パケット数５０で上書きすることで、暖機パケット列とパケットトレインとにそれぞれ含ませるパケット数を同じにしてもよい。
【００６５】
また、ｄｅｌａｙｅｄ  ＡＣＫと呼ばれるＴＣＰの仕組みが受信側装置２で働くことが想定される場合には、暖機パケット２つに対してＴＣＰレベルのＡＣＫパケットが１つ返ってくるため、暖機パケット列の送信によって推定パケット数分のＡＣＫが受信されるように、暖機パケット数３０を、推定パケット数５０の２倍の値で上書きしてもよい。これは、暖機パケット列送信後のｃｗｎｄの値を推定パケット数５０以上にするためである。この場合、暖機パケット列に含ませる暖機パケット数は、パケットトレインに含ませる推定パケット数の２倍となる。
【００６６】
次に、パケット列生成手段１１が、暖機パケット数３０が示す数の暖機パケットを含む暖機パケット列を生成する。そして、パケット送信手段１０は、生成された暖機パケット列を送信する。パケット送信手段１０は、例えば、ＯＳ層に順次、暖機パケット列に含まれる各暖機パケットの送信依頼を行うことで、暖機パケット列を送信してもよい。このとき、パケット送信手段１０は、各暖機パケットの送信時刻を保持しておき、各暖機パケットの送信時刻から、各暖機パケットの送信間隔を算出し、暖機パケット送信間隔３１としてデータ記憶手段１７に保持させる。各暖機パケットの送信時刻は、例えば、ＯＳ層に対して送信依頼を行ったタイミングまたはＯＳ層から送信完了を受けたタイミングとしてもよい。
【００６７】
続くステップＳ６１では、まず、受信側装置２のパケット受信手段２０が、暖機パケットを受信し、対応する応答パケットを返信する。なお、応答パケットの返信の前に、ＴＣＰレベルではＡＣＫ返信が行われているか、もしくは応答パケット自体がＴＣＰレベルのＡＣＫ返信を兼ねている。ここで、各応答パケットには、対応する暖機パケットの受信側装置２における受信時刻が埋め込まれている。
【００６８】
次に、送信側装置１の受信間隔算出手段１３は、受信側装置２が送信した応答パケットを受信すると、応答パケットに含まれる、対応する暖機パケットの受信時刻と一つ前の暖機パケットの受信時刻とから、当該対応する暖機パケットの受信間隔を算出する。そして、受信間隔算出手段１３は、算出された受信間隔を、対応する暖機パケットの暖機パケット受信間隔３２としてデータ記憶手段１７に保持させる。
【００６９】
続くステップＳ６２では、送信側装置１のタイマ値推定手段１４が、ステップＳ６０で取得された各暖機パケットの送信時刻と、ステップＳ６１で取得された応答パケットの受信時刻とから、暖機パケットごとにアプリケーションレベルのＲＴＴを算出し、ＲＴＴ計測値４０としてデータ記憶手段１７に保持させる。また、タイマ値推定手段１４は、算出した暖機パケットごとのアプリケーションレベルのＲＴＴから、暖機パケットごとにＴＣＰレベルのＲＴＯ−ｖａｌを推定し、ＲＴＯ推定値４１としてデータ記憶手段１７に保持させる。ＴＣＰレベルのＲＴＯ−ｖａｌの推定には、非特許文献１に記載の方法を用いてもよい。このとき、アプリケーションレベルのＲＴＴをＴＣＰレベルのＲＴＴとして用いてＲＴＯ−ｖａｌを求めてのよい。また、例えば、アプリケーションレベルのＲＴＴからＯＳ層からアプリケーション層にわたるまでのタイムラグが分かっている場合には、その値を差し引いた値を、ＴＣＰレベルのＲＴＴとして用いて、ＲＴＯ−ｖａｌを求めてもよい。
【００７０】
続くステップＳ６３では、送信側装置１の輻輳ウィンドウサイズ推定手段１６が、軽度の輻輳によるパケットロスが発生したかどうかを判定する。具体的には、輻輳ウィンドウサイズ推定手段１６は、暖機パケットごとの暖機パケット受信間隔３２を、当該暖機パケット列における先頭パケットから末尾パケットまで順に調べて行き、現在着目している暖機パケットの暖機パケット受信間隔３２の値が、ＴＣＰレベルにおいて軽度の輻輳によるパケットロスの発生判断とされる所定の値（以下、第１の閾値という）以上になっているか否かを判定する。第１の閾値は、例えば、３回の重複ＡＣＫ受信時により軽度の輻輳によるパケットロスの発生が認識される場合、着目しているパケットの送信時刻から当該パケットがロスして３回の重複ＡＣＫを受信するまでの時間とすればよい。より具体的には、現在着目している暖機パケットの暖機パケット送信間隔３１または平均的な暖機パケット送信間隔３１の３倍の値に、現在着目している暖機パケットのＲＴＴ計測値４０または平均的なＲＴＴ計測値４０の値を加えた値としてもよい。
【００７１】
なお、輻輳ウィンドウサイズ推定手段１６は、軽度の輻輳によるパケットロス発生の判定条件として、後続の暖機パケットの暖機パケット受信間隔３２が極めて短い既定の第２の閾値以下であることを、上記の条件に加えてもよい。ここで、第２の閾値としては、ＯＳ層における、複数のパケットを一度に受信したときの各パケットに付す受信タイムスタンプの間隔を基に定めてもよい。例えば、平均値や最大値や最小値としてもよいし、ＯＳの処理速度に応じた所定値（例えば、１００μｓ等）としてもよい。
【００７２】
以下、このような送信側装置１のアプリケーション層における軽度の輻輳によるパケットロスの判定条件について、図６を参照してより具体的に説明する。図６に示す例では、暖機パケット列の送信直前のｃｗｎｄの値は、初期値とされた１０以上であるとする。図６に示すように、９０番目の暖機パケットがロスせずに届くと、受信側装置２のＯＳ層は即座にアプリケーション側に９０番目の暖機パケットが届いたことを通知するので、受信側装置２の可用帯域推定のアプリケーション（例えば、パケット受信手段２０）は即座に９０番目の暖機パケットを受信したことを認識する。そして、受信側装置２のＯＳ層は９０番目の暖機パケットに対するＴＣＰレベルのＡＣＫパケットを返信する。
【００７３】
送信側装置１のＯＳ層は９０番目の暖機パケットに対するＡＣＫパケットを受信すると、９０番目の暖機パケットがロスせずに届いたことを認識する。そして、ＡＣＫ受信により、ｃｗｎｄ値を＋１する。このような処理が１番目の暖機パケットから９０番目の暖機パケットまで問題なく続いた場合、９０番目の暖機パケットに対するＡＣＫが届いた時点での送信側装置１のｃｗｎｄ値は、１０＋９０＝１００以上であると推測できる。
【００７４】
しかし、その後送信した９１番目の暖機パケットが途中のネットワークでロスしたとする。また、９２番目の暖機パケットは途中のネットワークでロスせずに届いたとする。受信側装置２のＯＳ層は期待する９１番目の暖機パケットが届いていないので、この時点ではアプリケーション側に暖機パケットが届いたことを通知せず、９０番目の暖機パケットに対するＴＣＰレベルのＡＣＫパケットを再度返信する。その後送信された９３番目の暖機パケットも途中のネットワークでロスせずに届いた場合、受信側装置２のＯＳ層は期待する９１番目の暖機パケットが届いていないことから、９２番目の暖機パケット受信時と同様の処理を行う。すなわち、受信側装置２のＯＳ層は、この時点でもアプリケーション側に暖機パケットが届いたことを通知せずに、９０番目の暖機パケットに対するＴＣＰレベルのＡＣＫパケットを再度返信する。
【００７５】
送信側装置１のＯＳ層は、９０番目の暖機パケットに対するＴＣＰレベルの重複ＡＣＫパケットを合計３回受信したことを契機に、９１番目の暖機パケットでパケットロスが発生したと判断し、９１番目の暖機パケットを再送する。
【００７６】
再送された９１番目の暖機パケットが途中のネットワークでロスせずに届くと、受信側装置２のＯＳ層は、即座にアプリケーション側にこれまでに受信した９１，９２，９３番目の暖機パケットが届いたことを通知するとともに、対応する暖機パケットのＡＣＫパケットを送信側装置１に返信する。受信側装置２の可用帯域推定のアプリケーション（パケット受信手段２０）は、ＯＳ層からの通知を受けて初めて９１，９２，９３番目の暖機パケットを受信したことを認識する。
【００７７】
送信側装置１における各暖機パケットの受信時刻は、受信側装置２におけるアプリケーションからの応答パケットから得ている。このため、８９番目とロスしなかった９０番目の暖機パケット間の受信間隔（９０番目の暖機パケットの暖機パケット受信間隔３２）は、９０番目からロスした９１番目の暖機パケット間のそれ（９１番目の暖機パケットの暖機パケット受信間隔３２）と比べて、大きく異なる。より具体的には、８９番目と９０番目の暖機パケット間の受信間隔は、８９番目と９０番目の暖機パケット間の送信間隔に近い値になるが、９０番目と９１番目の暖機パケット間の受信間隔は、図６に示すように、９０番目と９１番目の暖機パケット間の送信間隔の３倍の値に、９１番目の暖機パケットに対して求められたＲＴＴ計測値４０または平均的なＲＴＴ計測値４０の値を加えた値と同じかそれ以上の値に延びる。
【００７８】
また、アプリケーション側から見ると、パケットロスした暖機パケット以降の所定数の暖機パケットである９１，９２，９３番目の暖機パケットはほぼ同時に受信したように見えるので、９１番目と９２番目の暖機パケット間の受信間隔や、９２番目と９３番目の暖機パケット間の受信間隔は、極めて短い値になる。そのため、これら受信間隔の極端な短さを、軽度の輻輳によるパケットロス発生の判定条件に加えてもよい。
【００７９】
図５に戻り、輻輳ウィンドウサイズ推定手段１６は、軽度の輻輳によるパケットロスが発生したと判定した場合には（ステップＳ６３のＹｅｓ）、ステップＳ６４に処理を進め、判定しなかった場合には（ステップＳ６３のＮｏ）、ステップＳ６５に処理を進める。
【００８０】
ステップＳ６４では、軽度の輻輳によるパケットロス発生有りの判定結果を受けて、輻輳ウィンドウサイズ推定手段１６は、ＴＣＰレベルの輻輳ウィンドウサイズすなわちｃｗｎｄの値を推定する。ここで、輻輳ウィンドウサイズ推定手段１６は、厳密な値を推定する必要は無く、取り得る可能性として最も小さい値（以下、最低値という場合がある）を推定すればよい。例えば、ｃｗｎｄの最低値は、例えば、ＴＣＰレベルのｃｗｎｄの初期値や、前回のパケット列の送信結果、特定されるパケットロスの発生有無および輻輳の度合いや、今回のパケット列の送信結果、特定されるパケットロスの発生有無および輻輳の度合いを基に、プロトコルスタックの輻輳ウィンドウの制御に倣う、すなわちプロトコルスタックにおいてｃｗｎｄに対して行われるのと同様の数値計算を行うことで、算出してもよい。
【００８１】
例えば、ＴＣＰのプロトコルスタックにおける輻輳ウィンドウの制御が、ＡＣＫ受信の度に＋１、軽度の輻輳によるパケットロス発生時には０．７倍するといった場合を考える。輻輳ウィンドウサイズ推定手段１６は、例えば、ＴＣＰレベルのｃｗｎｄの初期値と、パケットロス発生時までに暖機パケット列によって受信したＡＣＫの数とから直前のｃｗｎｄを求め、それに対して０．７倍することで、パケットロス発生後のｃｗｎｄを予想することができる。なお、その後、残りのパケット列が正常に受信されていれば、残りの暖機パケット数のＡＣＫ受信により増加する分を足し合わせれば、暖機パケット列送信完了時点におけるｃｗｎｄの値を推定できる。なお、暖機パケット送信前のｃｗｎｄの値を初期値以上とせずに０としてもよい。なお、軽度の輻輳によるパケットロスの発生回数が１回であれば、暖機パケット列送信完了後のｃｗｎｄの値は、パケットロス前およびパケットロス後のＡＣＫ受信による増加分を考慮すると、おおよそ暖機パケット数の０．７倍以上となることが想定できるので、そのような単純計算により求めてもよい。
【００８２】
今、１つの暖機パケット列を送信し終えた時点で、ｃｗｎｄの値が少なくとも７０以上であると推定されたとする。その場合、ｃｗｎｄの値としては、パケットトレイン送信前に推定パケット数である１００以上としたいことから、あと３０増加させればよいことがわかる。
【００８３】
暖機パケット数決定手段１２は、輻輳ウィンドウサイズ推定手段１６による輻輳ウィンドウサイズの推定結果を基に、次の暖機パケット列のパケット数を決定する。ここでは、必要とされる最小の値に設置すればよい。本例の場合、１００−７０＝３０個の暖機パケットを送信すればよいので、暖機パケット数決定手段１２は、暖機パケット数３０を３０個に設定する。そして、ステップＳ６０に戻り、更新後のパケット数の暖機パケット列の送信を再度行わせる。
【００８４】
一方、軽度の輻輳によるパケットロスが発生していないと判定された場合、ステップＳ６５では、輻輳ウィンドウサイズ推定手段１６が、さらに重度の輻輳によるパケットロスが発生したかどうかを判定する。具体的には、輻輳ウィンドウサイズ推定手段１６は、暖機パケットごとの暖機パケット受信間隔３２を、当該暖機パケット列における先頭パケットから末尾パケットまで順に調べて行き、現在着目している暖機パケットの暖機パケット受信間隔３２の値が、ＴＣＰレベルにおいて重度の輻輳によるパケットロスの発生判断とされる所定の値（以下、第３の閾値という）以上になっているか否かを判定する。第３の閾値は、例えば、ＲＴＯ発生により重度の輻輳によるパケットロスの発生が認識される場合、着目しているパケットの送信間隔にＲＴＯのタイマ値とを加えた時間とすればよい。より具体的には、現在着目している暖機パケットの暖機パケット送信間隔３１の値に、現在着目している暖機パケットのＲＴＯ推定値４１または平均的なＲＴＯ推定値４１の値を加えた値としてもよい。
【００８５】
なお、輻輳ウィンドウサイズ推定手段１６は、重度の輻輳によるパケットロス発生の判定条件として、後続の暖機パケットの暖機パケット受信間隔３２が極めて短い既定の閾値（上記の第２の閾値と同様でよい）以下であることを、上記の条件に加えてもよい。
【００８６】
以下、このような送信側装置１のアプリケーション層における重度の輻輳によるパケットロスの判定条件について、図７を参照してより具体的に説明する。図７に示す例でも、暖機パケット列の送信直前のｃｗｎｄの値は、初期値とされた１０以上であるとする。図７に示すように、９０番目の暖機パケットがロスせずに届くと、図６に示す例と同様、受信側装置２のＯＳ層は即座にアプリケーション側に９０番目の暖機パケットが届いたことを通知するとともに、９０番目の暖機パケットに対するＴＣＰレベルのＡＣＫパケットを返信する。
【００８７】
送信側装置１のＯＳ層は９０番目の暖機パケットに対するＡＣＫパケットを受信すると、９０番目の暖機パケットがロスせずに届いたことを認識する。なお、本例でも、１番目の暖機パケットから９０番目の暖機パケットまで問題なく続いた場合、９０番目の暖機パケットに対するＡＣＫが届いた時点での送信側装置１のｃｗｎｄ値は、１０＋９０＝１００以上であると推測できる。
【００８８】
しかし、その後９１，９２，９３番目の暖機パケットが途中のネットワークでロスし、９１番目の暖機パケットに対するＴＣＰレベルのＡＣＫパケットが、ＴＣＰにおけるＲＴＯの値の時間長を超えても返って来なかったとする。その場合、送信側装置１のＯＳ層は、９１番目の暖機パケットの送信時に起動した再送タイマが満了（ＲＴＯが発生）したことを受けて、重度の輻輳によるパケットロスが発生したと判断し、これまでにＡＣＫが返ってきていない９１，９２，９３番目の暖機パケットを再送する。
【００８９】
このとき再送された９１，９２，９３番目の暖機パケットは、途中のネットワークでロスせずに届いたとする。受信側装置２のＯＳ層は即座にアプリケーション側にこれまでに受信した９１，９２，９３番目の暖機パケットが届いたことを通知するとともに、対応する暖機パケットのＡＣＫパケットを送信側装置１に返信する。受信側装置２の可用帯域推定のアプリケーション（パケット受信手段２０）は、ＯＳ層からの通知を受けて初めて９１，９２，９３番目の暖機パケットを受信したことを認識する。
【００９０】
本例の場合も、８９番目とロスしなかった９０番目の暖機パケット間の受信間隔（９０番目の暖機パケットの暖機パケット受信間隔３２）と、９０番目からロスした９１番目の暖機パケット間の受信間隔（９１番目の暖機パケットの暖機パケット受信間隔３２）とは、大きく異なる。より具体的には、８９番目と９０番目の暖機パケット間の受信間隔は、８９番目と９０番目の暖機パケット間の送信間隔に近い値になるが、９０番目と９１番目の暖機パケット間の受信間隔は、図７に示すように、９０番目と９１番目の暖機パケット間の送信間隔に、９１番目の暖機パケットに対して求められたＲＴＯ推定値４１または平均的なＲＴＯ推定値４１の値を加えた値と同じかそれ以上の値に延びる。
【００９１】
また、アプリケーション側から見ると、パケットロスした暖機パケット以降の所定数の暖機パケットである９１，９２，９３番目の暖機パケットはほぼ同時に受信したように見えるので、軽度の輻輳によるパケットロスの場合と同様、後続する暖機パケットの受信間隔の極端な短さを、重度の輻輳によるパケットロス発生の判定条件に加えてもよい。
【００９２】
図５に戻り、輻輳ウィンドウサイズ推定手段１６は、重度の輻輳によるパケットロスが発生したと判定した場合には（ステップＳ６５のＹｅｓ）、ステップＳ６６に処理を進め、判定しなかった場合には（ステップＳ６５のＮｏ）、ステップＳ６７に処理を進める。
【００９３】
ステップＳ６６では、重度の輻輳によるパケットロス発生有りの判定結果を受けて、輻輳ウィンドウサイズ推定手段１６は、ＴＣＰレベルのｃｗｎｄの値を推定する。ここでも、輻輳ウィンドウサイズ推定手段１６は、厳密な値を推定する必要は無く、可能性として取り得る最も小さい値の予想が立てばよい。
【００９４】
例えば、ＴＣＰのプロトコルスタックにおける輻輳ウィンドウの制御が、重度の輻輳によるパケットロス発生時にはｃｗｎｄの値を２にするといった場合を考える。輻輳ウィンドウサイズ推定手段１６は、例えば、重度の輻輳によるパケットロス発生が起こった際には、パケットロス発生後のｃｗｎｄを２と推定できる。なお、重度の輻輳によるパケットロスがどのタイミングで発生するかによって、暖機パケット列送信完了後のｃｗｎｄの値として、９９〜２までの値を取り得る。しかし、それらタイミングを考慮せずにｃｗｎｄの最低値を、最悪のパターンである２としてもよい。また、輻輳ウィンドウサイズ推定手段１６は、ｃｗｎｄの最低値を、軽度の輻輳によるパケットロスの判定方法と同様、例えば、各種計測値や推定値を基に、プロトコルスタックの輻輳ウィンドウの制御に倣うことで、算出してもよい。
【００９５】
今、１つの暖機パケット列を送信し終えた時点で、ｃｗｎｄの値が少なくとも２以上であると推定されたとする。その場合、ｃｗｎｄの値としては、パケットトレイン送信前に推定パケット数である１００以上としたいことから、あと９８増加させればよいことがわかる。
【００９６】
暖機パケット数決定手段１２は、輻輳ウィンドウサイズ推定手段１６による輻輳ウィンドウサイズの推定結果を基に、次の暖機パケット列のパケット数を決定する。ここでは、必要とされる最小の値に設置すればよい。本例の場合、１００−２＝９８個の暖機パケットを送信すればよいので、暖機パケット数決定手段１２は、暖機パケット数３０を９８個に設定する。そして、ステップＳ６０に戻り、更新後のパケット数の暖機パケット列の送信を再度行わせる。
【００９７】
一方、重度の輻輳によるパケットロスが発生していないと判定された場合、ステップＳ６７に進むが、ステップＳ６７〜ステップＳ７３の動作は、送信する対象が暖機パケット列からパケットトレインに変わるだけで、動作の内容はステップＳ６０〜ステップＳ６６と本質的に同じなので、説明は省略する。すなわち、パケットトレイン列の送信が完了すると、パケットトレイン列に対しても、送信中における軽度または重度の輻輳によるパケットロスの判定が行われる。なお、ステップＳ７１およびステップＳ７３における暖機パケット数の調整は、次回の暖機パケット列の送信時における暖機パケット数を決定するためのものであり、当該調整完了後はステップＳ７５に進む。
【００９８】
また、ステップＳ７４は、暖機パケット列の送信時もパケットトレインの送信時もパケットロスが一切発生しなかったと判定された場合に進む処理である。ステップＳ７４では、暖機パケット数決定手段１２は、暖機パケット数３０の値を０個に設定してもよい。なお、暖機パケット列の送信時やパケットトレイン送信時におけるパケットロスの判定結果に関わらず、次回の暖機パケット列の送信時における暖機パケットに含ませる暖機パケット数を、推定パケット数としてもよい。
【００９９】
ステップＳ７５では、受信側装置２の可用帯域推定手段２１が、送信側装置１から送信されたパケットトレインの受信結果を基に、可用帯域を推定する。そして、可用帯域推定手段２１は、推定した可用帯域の値を、可用帯域推定値５９としてデータ記憶手段２２に保持させる。可用帯域の推定には、例えば、特許文献１に記載の方法を用いてもよい。
【０１００】
なお、システムの単純化のために、ステップＳ６４、ステップＳ６６、ステップＳ７１、ステップＳ７３、ステップＳ７４において、暖機パケット数３０の値を、推定パケット数５０と同じ値や、推定パケット数５０の２倍の値に設定してもよい。
【０１０１】
以上のように、本実施形態によれば、暖機パケットの数を、パケットロスの発生有無および輻輳の度合いに応じて調整することで、パケットトレインの全推定パケットにわたって、指定された時刻で正確に送信するために必要な暖機パケットの個数をできるだけ少なくすることができる。このため、パケットトレインを指定された時刻で正確に送信できるだけでなく、暖機パケットの送信に伴う時間と通信負荷のオーバヘッドも低減できる。
【０１０２】
また、暖機パケット列の送信時とパケットトレインの送信時の両方において、暖機パケットの数を、パケットロスの発生有無および輻輳の度合いに応じて調整することで、複数回パケットトレインの送信を行う場合であっても、暖機パケットの個数を減らすことができ、暖機パケットの送信に伴う時間と通信負荷のオーバヘッドを低減できる。
【０１０３】
なお、上記の実施形態では、可用帯域の推定を行う可用帯域推定システムに、本発明による輻輳ウィンドウサイズの制御方法を適応した例を示したが、本発明による輻輳ウィンドウサイズの制御方法は、可用帯域の推定用途に限定されない。例えば、アプリケーション層にプロトコルスタックの輻輳ウィンドウサイズを所定値以上とする機能を提供する制御システムとしても適用可能である。その場合、送信側装置１におけるパケットトレインの送信に関する機能および受信側装置２における可用帯域の推定に関する機能は省略される。
【０１０４】
次に、本発明による制御システムおよび可用帯域推定システムの概要を説明する。図８は、本発明による制御システムの概要を示すブロック図である。図８に示すように、本発明による制御システムは、送信側の通信装置である送信側装置７００と、受信側の通信装置である受信側装置８００とを備えている。
【０１０５】
また、送信側装置７００は、暖機パケット列送信手段７０１と、暖機パケット数決定手段７０２と、ウィンドウサイズ推定手段７０３とを含む。
【０１０６】
暖機パケット列送信手段７０１（例えば、パケット送信手段１０、パケット列生成手段１１等）は、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、受信側装置８００に送信する。
【０１０７】
暖機パケット数決定手段７０２（例えば、暖機パケット数決定手段１２）は、暖機パケット列に含ませる暖機パケットの数を決定する。暖機パケット数決定手段７０２は、後述するウィンドウサイズ推定手段７０３による輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する。
【０１０８】
ウィンドウサイズ推定手段７０３（例えば、輻輳ウィンドウサイズ推定手段１６）は、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置８００における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定する。
【０１０９】
このような構成によれば、受信確認およびウィンドウによる輻輳制御があるプロトコルを用いて所定のパケット列を送信する場合に、アプリケーションレベルの簡易な構成で、事前に輻輳ウィンドウを当該パケット列の連続送信が可能なサイズまで大きくすることができる。また、第１のパケット列が可用帯域推定用のパケットトレインである場合には、アプリケーションレベルの簡易な構成で、受信確認のないプロトコルが使用できないネットワーク上の可用帯域の推定を高精度に行うことができる。
【０１１０】
また、図９は、本発明による制御システムの他の構成例を示すブロック図である。図９に示すように、本発明による制御システムは、上記の構成に加えて、送信側装置７００が、送受信時刻取得手段７０４、タイマ値推定手段７０５、パケットロス判定手段７０６や、第１パケット列送信手段７０７を含んでいてもよい。また、受信側装置８００が、可用帯域推定手段８０１を含んでいてもよい。
【０１１１】
送受信時刻取得手段７０４（例えば、受信間隔算出手段１３、パケット送信手段１０等）は、暖機パケット列に含まれる各暖機パケットの、送信時刻および受信側装置における受信時刻を取得する。
【０１１２】
タイマ値推定手段７０５（例えば、タイマ値推定手段１４）は、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻から、暖機パケット列の送信中におけるアプリケーションレベルでのラウンドトリップタイムであるＲＴＴおよびプロトコルスタックレベルでの再送タイマの値であるＲＴＯ−ｖａｌを算出する。
【０１１３】
パケットロス判定手段７０６（例えば、パケットロス判定手段１５）は、暖機パケット列に含まれる各暖機パケットの送信時刻から特定される暖機パケットの送信間隔と、暖機パケット列に含まれる各暖機パケットの受信時刻から特定される暖機パケットの受信間隔と、ＲＴＴと、ＲＴＯ−ｖａｌとに基づいて、パケットロスが発生したか否かおよびその際の輻輳の度合いが軽度か重度かを判定する。
【０１１４】
第１パケット列送信手段７０７（例えば、パケット送信手段１０、パケット列生成手段１１等）は、第１のパケット列を、受信側装置８００に送信する。
【０１１５】
可用帯域推定手段８０１（例えば、可用帯域推定手段２１）は、第１のパケット列の受信結果に基づいて、送信側装置と受信側装置間の通信経路における可用帯域を推定する。
【０１１６】
なお、送信側装置１が第１パケット列送信手段７０７を含み、受信側装置２が可用帯域推定手段８０１を含む構成である場合、制御システムは可用帯域推定システムと呼ばれてもよい。
【０１１７】
また、上記の実施形態の一部または全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１１８】
（付記１）送信側の通信装置である送信側装置と、受信側の通信装置である受信側装置とを備え、送信側装置は、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、受信側装置に送信する暖機パケット列送信手段と、暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段とを含み、暖機パケット数決定手段は、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定することを特徴とする制御システム。
【０１１９】
（付記２）暖機パケット数決定手段は、第１のパケット列に含まれるパケット数から、推定された輻輳ウィンドウサイズの最低値を引いた値を、再送信を行う暖機パケット列に含ませる暖機パケットの数とする付記１に記載の制御システム。
【０１２０】
（付記３）ウィンドウサイズ推定手段は、第１のパケット列の暖機パケット列の送信の結果取得される、第１のパケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、第１のパケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定し、暖機パケット数決定手段は、輻輳ウィンドウサイズの最低値の推定結果を基に、次回の第１のパケットの送信前に送信を行う暖機パケット列に含ませる暖機パケットの数を決定する付記１または付記２に記載の制御システム。
【０１２１】
（付記４）暖機パケット数決定手段は、第１のパケット列の送信時およびその前の暖機パケット列の送信時にいずれのパケットロスも発生しなかった場合には、次回の第１のパケットの送信前に送信を行う暖機パケット列に含ませる暖機パケットの数を０に決定する付記３に記載の制御システム。
【０１２２】
（付記５）送信側装置は、暖機パケット列に含まれる各暖機パケットの、送信時刻および受信側装置における受信時刻を取得する送受信時刻取得手段と、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻から、暖機パケット列の送信中におけるアプリケーションレベルでのラウンドトリップタイムであるＲＴＴおよびプロトコルスタックレベルでの再送タイマの値であるＲＴＯ−ｖａｌを算出するタイマ値推定手段と、暖機パケット列に含まれる各暖機パケットの送信時刻から特定される暖機パケットの送信間隔と、暖機パケット列に含まれる各暖機パケットの受信時刻から特定される暖機パケットの受信間隔と、ＲＴＴと、ＲＴＯ−ｖａｌとに基づいて、パケットロスが発生したか否かおよびその際の輻輳の度合いが軽度か重度かを判定するパケットロス判定手段とを含み、ウィンドウサイズ推定手段は、パケットロス判定手段による判定結果に基づいて、輻輳ウィンドウサイズの最低値を推定する付記１から付記４のうちのいずれかに記載の制御システム。
【０１２３】
（付記６）ウィンドウサイズ推定手段は、暖機パケット列の送信により受け取る受信確認の数と、軽度および重度の輻輳によるパケットロスの発生回数とに少なくとも基づいて、輻輳ウィンドウサイズの最低値を推定する付記５に記載の制御システム。
【０１２４】
（付記７）ウィンドウサイズ推定手段は、プロトコルスタックにおける輻輳ウィンドウの制御における軽度の輻輳時による輻輳ウィンドウサイズの減少率をｊとすると、軽度の輻輳によるパケットロスが発生したと判定された場合に、現時点のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を、送信に用いた暖機パケット列に含まれる暖機パケット数のｊ倍と推定する付記５または付記６に記載の制御システム。
【０１２５】
（付記８）ウィンドウサイズ推定手段は、プロトコルスタックにおける輻輳ウィンドウの制御における重度の輻輳後の輻輳ウィンドウサイズの値をｋとすると、重度の輻輳によるパケットロスが発生したと判定された場合に、現時点のプロトコルスタックにおける輻輳ウィンドウサイズの最低値をｋと推定する付記５から付記７のうちのいずれかに記載の制御システム。
【０１２６】
（付記９）パケットロス判定手段は、プロトコルスタックが軽度の輻輳を検知するまでに受信する重複した受信確認の回数をｎとすると、ある暖機パケットの受信間隔が、当該暖機パケットの送信間隔をｎ倍した値にＲＴＴを加えた値以上である場合を、当該暖機パケットにおける軽度の輻輳によるパケットロス発生の判定条件として用いて、各暖機パケットに対して軽度の輻輳によるパケットロスの発生を判定する付記５から付記８のうちのいずれかに記載の制御システム。
【０１２７】
（付記１０）パケットロス判定手段は、ある暖機パケットの受信間隔が、当該暖機パケットの送信間隔にＲＴＯ−ｖａｌを加えた値以上である場合を、当該暖機パケットにおける重度の輻輳によるパケットロス発生の判定条件として用いて、各暖機パケットに対して重度の輻輳によるパケットロスの発生を判定する付記５から付記９のいずれかに記載の制御システム。
【０１２８】
（付記１１）パケットロス判定手段は、軽度の輻輳によるパケットロス発生の判定条件または重度の輻輳によるパケットロス発生の判定条件として、さらに、着目している暖機パケットの後続の所定数の暖機パケットである後続暖機パケットの受信間隔が所定の閾値以下であることを条件に加える付記９または付記１０に記載の制御システム。
【０１２９】
（付記１２）送信側の通信装置である送信側装置と、受信側の通信装置である受信側装置とを備え、送信側装置は、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、受信側装置に送信する暖機パケット列送信手段と、暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段と、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、第１のパケット列を、受信側装置に送信する第１パケット列送信手段とを含み、受信側装置は、第１のパケット列の受信結果に基づいて、送信側装置と受信側装置間の通信経路における可用帯域を推定する可用帯域推定手段を含み、暖機パケット数決定手段は、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定することを特徴とする可用帯域推定システム。
【０１３０】
（付記１３）受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に送信する暖機パケット列送信手段と、暖機パケット列に含ませる暖機パケットの数を決定する暖機パケット数決定手段と、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定するウィンドウサイズ推定手段とを備え、暖機パケット数決定手段は、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定することを特徴する通信装置。
【０１３１】
（付記１４）送信側の通信装置である送信側装置が、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に向けて送信し、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定し、輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定し、決定された暖機パケットの数が１以上である場合に、第１のパケット列の送信前に、決定された数の暖機パケットを含む暖機パケット列の再送信を行うことを特徴とする制御方法。
【０１３２】
（付記１５）コンピュータに、受信確認およびウィンドウによる輻輳制御が行われるプロトコルを用い、かつ所定の送信間隔での送信が要求される複数のパケットからなる第１のパケット列の送信前に、該プロトコルを用いて送信される準備用パケットである暖機パケットを複数個まとめた暖機パケット列を、所定の受信側装置に送信する処理、暖機パケット列の送信の結果取得される、暖機パケット列に含まれる各暖機パケットの送信時刻および受信側装置における受信時刻に基づいて、暖機パケット列の送信後のプロトコルスタックにおける輻輳ウィンドウサイズの最低値を推定する処理、および輻輳ウィンドウサイズの最低値の推定結果を基に、再送信を行う暖機パケット列に含ませる暖機パケットの数を決定する処理を実行させるための制御プログラム。
【０１３３】
以上、本実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【産業上の利用可能性】
【０１３４】
本発明は、端末間で双方向に映像を送り合ってコミュニケーションをするビデオチャットやテレビ電話、テレビ会議などを行う場合などにおいて映像品質を確保するために可用帯域を推定する用途に好適に適用可能である。また、本発明は、可用帯域の推定用途に限定されず、所定の時間間隔で精度良く複数のパケットを連続的に送信したい場合にも好適に適用可能である。また、連続送信用途に限らず、アプリケーション層からプロトコルスタックの輻輳ウィンドウサイズを増加、維持させたい場合にも好適に適用可能である。
【符号の説明】
【０１３５】
１、７００  送信側装置
２、８００  受信側装置
３  ネットワーク
１０  パケット送信手段
１１  パケット列生成手段
１２  暖機パケット数決定手段
１３  受信間隔算出手段
１４  タイマ値推定手段
１５  パケットロス判定手段
１６  輻輳ウィンドウサイズ推定手段
１７  データ記憶手段
２０  パケット受信手段
２１  可用帯域推定手段
２２  データ記憶手段
３０  暖機パケット数
３１  暖機パケット送信間隔
３２  暖機パケット受信間隔
４０  ＲＴＴ計測値
４１  ＲＴＯ推定値
４２  輻輳ウィンドウサイズ推定値
５０  推定パケット数
５１  推定パケット送信間隔
５２  推定パケット受信間隔
５９  可用帯域推定値
７０１  暖機パケット列送信手段
７０２  暖機パケット数決定手段
７０３  ウィンドウサイズ推定手段
７０４  送受信時刻取得手段
７０５  タイマ値推定手段
７０６  パケットロス判定手段
７０７  第１パケット列送信手段
８０１  可用帯域推定手段
【図１】
2019012866.tif 000003
【図２】
2019012866.tif 000004
【図３】
2019012866.tif 000005
【図４】
2019012866.tif 000006
【図５】
2019012866.tif 000007
【図６】
2019012866.tif 000008
【図７】
2019012866.tif 000009
【図８】
2019012866.tif 000010
【図９】
2019012866.tif 000011
【図１０】
2019012866.tif 000012
【図１１】
2019012866.tif 000013