(57)【特許請求の範囲】
【請求項１】
送達確認に基づいて輻輳ウインドウサイズを決定しパケット送信に関するスロースタート制御を行うパケット送信装置であって、
パケット送信の送達確認として通知される送達確認応答用パケットを受信し、該パケット送信の送信時刻と該送達確認応答用パケットの受信時刻との差から当該パケット送信の送達確認に基づく往復遅延時間を算出する送達確認応答受信手段と、
通信開始から輻輳ウインドウサイズを拡大しつつ輻輳判定を行って、輻輳と判定した際にスロースタートフェーズから輻輳回避フェーズへ遷移させるように動作するスロースタート制御手段とを備え、
前記スロースタート制御手段は、
スロースタートフェーズで動作中に、前記往復遅延時間について継続して計測した最小の往復遅延時間と、輻輳ウインドウサイズの更新が為される度に所定の更新式に基づいて更新される輻輳ウインドウサイズの最大値と、当該受信した送達確認応答用パケットに対して最近時に受信したパケット群の送信時刻及び受信時刻とに基づいて、予め定めたパケット遅延量に関する計測期間毎に前記輻輳ウインドウサイズの上限値を決定する輻輳ウインドウ上限算出手段と、
前記送達確認応答用パケットを受信する度に直前の１計測期間の経過時に決定された当該輻輳ウインドウサイズの上限値以下で前記輻輳ウインドウサイズを所定幅で拡大し、当該計測期間毎に該輻輳ウインドウサイズの上限値と当該拡大した輻輳ウインドウサイズとを比較して、前記拡大した輻輳ウインドウサイズが該輻輳ウインドウサイズの上限値以上となる際に、スロースタートフェーズから輻輳回避フェーズへ遷移させるように動作する輻輳ウインドウ増加手段と、
を有することを特徴とするパケット送信装置。
【請求項２】
前記輻輳ウインドウ上限算出手段は、
前記送達確認応答用パケットを受信する度に、該送達確認応答用パケットに対応する送信パケットの送信レートが前記輻輳ウインドウサイズの最大値から求められる送信レート以上であるか否かを判定する第１判定手段と、
前記送達確認応答用パケットを受信する度に、最近時に受信したパケット群に含まれるか否かの判定を行う第２判定手段と、
前記第１判定手段及び前記第２判定手段の双方の判定を満たすときは当該最近時に受信したパケット群の受信バイト数に該送達確認応答用パケットにより送達確認したバイト数を加えた受信バイト数を定め、前記第１判定手段及び前記第２判定手段のいずれか一方の判定を満たさないときには、該受信バイト数から求められる当該最近時に受信したパケット群の受信レートを基準にした輻輳ウインドウサイズを算出して当該計測期間毎に更新し、当該更新した輻輳ウインドウサイズを前記輻輳ウインドウサイズの上限値として決定する輻輳ウインドウ上限決定手段と、
を有することを特徴とする、請求項１に記載のパケット送信装置。
【請求項３】
前記輻輳ウインドウサイズの最大値は、前記所定の更新式として、更新された輻輳ウインドウサイズの２倍の値か、又は更新された輻輳ウインドウサイズの２倍の値と、直前の１計測期間の経過時に決定された前記輻輳ウインドウサイズの上限値のうち小さい方の値により更新されることを特徴とする、請求項１又は２に記載のパケット送信装置。
【請求項４】
前記スロースタート制御手段は、受信する送達確認応答用パケット毎の往復遅延時間の変動量を監視して連続する往復遅延時間パケットのパケット列の最大の変動量を計測し、当該計測期間毎に当該最大の変動量について移動平均した値を往復遅延時間の平均変動量として算出する遅延変動量推定手段を更に備え、
前記輻輳ウインドウ上限算出手段は、前記平均変動量を加味して当該輻輳ウインドウの上限値を決定する手段を有し、
前記輻輳ウインドウ増加手段は、前記往復遅延時間について継続して計測した最小の往復遅延時間に当該平均変動量を加えた値と、直前の１計測期間で最小の値として計測した計測期間内最小の往復遅延時間とを比較して、該計測期間内最小の往復遅延時間が前記往復遅延時間について継続して計測した最小の往復遅延時間に当該平均変動量を加えた値を超える際に、スロースタートフェーズから輻輳回避フェーズへ遷移させるように動作する手段を更に有することを特徴とする、請求項１に記載のパケット送信装置。
【請求項５】
請求項１から４のいずれか一項に記載のパケット送信装置を備えることを特徴とする通信端末。
【請求項６】
送達確認に基づいて輻輳ウインドウサイズを決定しパケット送信に関するスロースタート制御を行うスロースタート制御方法であって、
スロースタートフェーズで動作中に、パケット送信の送信時刻と送達確認応答用パケットの受信時刻との差から当該パケット送信の送達確認に基づく往復遅延時間について継続して計測した最小の往復遅延時間と、輻輳ウインドウサイズの更新が為される度に所定の更新式に基づいて更新される輻輳ウインドウサイズの最大値と、当該受信した送達確認応答用パケットに対して最近時に受信したパケット群の送信時刻及び受信時刻とに基づいて、予め定めたパケット遅延量に関する計測期間毎に前記輻輳ウインドウサイズの上限値を決定するステップと、
前記送達確認応答用パケットを受信する度に直前の１計測期間の経過時に決定された当該輻輳ウインドウサイズの上限値以下で前記輻輳ウインドウサイズを所定幅で拡大し、当該計測期間毎に該輻輳ウインドウサイズの上限値と当該拡大した輻輳ウインドウサイズとを比較して、前記拡大した輻輳ウインドウサイズが該輻輳ウインドウサイズの上限値以上となる際に、スロースタートフェーズから輻輳回避フェーズへ遷移させるように動作するステップと、
を含むことを特徴とするスロースタート制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信によってデータを伝送する技術に関し、特に、送達確認に基づいて輻輳ウインドウサイズを決定しパケット送信に関するスロースタート制御を行うパケット送信装置、通信端末及びスロースタート制御方法に関する。
【背景技術】
【０００２】
品質の保証がされていないベストエフォートタイプのＩＰ（Internet Protocol）ネットワークでは、ネットワーク機器内部でのバッファ溢れや、伝送中のビットエラー等によって送信パケットの廃棄が発生する。そのため、確実にデータを伝送するための送達確認を行うプロトコルとしてＴＣＰ（Transmission Control Protocol）が幅広く利用されている（例えば、非特許文献１参照）。
【０００３】
例えば、図１２に示すように、ＴＣＰを利用して相互通信接続を行う通信端末１０，２０において、通信端末１０にはパケット送信装置１１及びパケット受信装置１２が設けられ、通信端末２０にはパケット送信装置２２及びパケット受信装置２１が設けられる。パケット送信装置１１及びパケット受信装置２１とパケット送信装置２２及びパケット受信装置１２はそれぞれ同様の機能を有し、代表してパケット送信装置１１及びパケット受信装置２１に注目して説明する。パケット送信装置１１は、データ送信用パケットを所定の通信路を介してパケット受信装置２１に送信すると、パケット受信装置２１は、受信した旨の報告として送達確認応答用パケットをパケット送信装置１１に送信する。
【０００４】
より具体的には、ＴＣＰでは、パケット受信装置２１がパケットを受信すると、受信した旨の報告として、次に送信を要求するパケットの番号をパケット送信装置１１に通知する。そして、パケット送信装置１１は、パケット受信装置２１から通知される報告に基づいて、パケットが正常にパケット受信装置２１に到達したことを確認する。パケット送信装置１１は、パケット受信装置２１から通知される報告に基づいて、送達確認応答なしに送出可能なパケットの数を表す輻輳ウインドウサイズ（cwnd: congestion window size）を調整する。例えばパケットが正常に受信された場合はcwndを拡大し、パケットロスが検出された場合はcwndを縮小する。
【０００５】
このcwndを調整する技法は輻輳制御技法と呼ばれ、通信の状態によってその制御技法が切り替えられる。一般的には通信開始時やタイムアウト後に適用される「スロースタートフェーズ」、通信が安定している際に適用される「輻輳回避フェーズ」、ロスパケットを再送するための「ロスリカバリフェーズ」といったフェーズに応じて輻輳制御技法を切り替える。ＲＦＣ５６８１には一般的なＴＣＰが用いる輻輳制御技法が記載されている（例えば、非特許文献２参照）。ＲＦＣ５６８１に記載されているスロースタートフェーズの動作では、cwndがスロースタート閾値（ssthresh）未満である場合、式（１）によりcwndを拡大する。ssthreshは、スロースタートフェーズと輻輳回避フェーズの切り替えを決定する閾値である。
【０００６】
cwnd ＝ min（N, MSS）                                          （１）
【０００７】
Nは新たに送達確認されたバイト数、MSSはパケットに含まれるデータの最大バイト数である。cwndがssthresh以上になるか、パケットロスが発生した時点でスロースタートフェーズでの動作を終了する。
【０００８】
ＴＣＰ ＣＵＢＩＣ（例えば、非特許文献３参照）やＣＴＣＰ（例えば、非特許文献４参照）など様々なＴＣＰが提案されているが、「スロースタートフェーズ」での動作はＲＦＣ５６８１と同じであり、「輻輳回避フェーズ」に独自の輻輳制御アルゴリズムが組み込まれている。
【０００９】
一例のスロースタートフェーズでの動作として、Ｌｉｍｉｔｅｄ Ｓｌｏｗ‐Ｓｔａｒｔが提案されている（例えば、非特許文献５参照）。ＲＦＣ５６８１では、cwndがssthreshより大きくなるまで式（１）によりcwndを拡大するが、Ｌｉｍｉｔｅｄ Ｓｌｏｗ‐Ｓｔａｒｔでは新たにmax_ssthreshという閾値を導入し、cwndがmax_ssthreshより大きくなると１往復遅延時間（rtt：Round Trip Time）辺りに増加するcwndをmax_ssthresh／２に制限する。
【００１０】
他例のスロースタートフェーズでの動作として、Ｈｙｓｔａｒｔが提案されている（例えば、非特許文献６参照）。Ｈｙｓｔａｒｔでは、スロースタート終了条件についてＲＦＣ５６８１に加えて２つの新しい条件を定義している。１つは、１往復遅延時間（rtt）中に送信するパケット列の送信にかかる時間が閾値を超えた場合に終了する。もう１つは、所定の１計測期間中に送信するパケット列の先頭の数パケットで計測した最小のrttであるrttminが、それまでに計測した最小のrttであるrttbaseよりも閾値以上に大きくなっている場合に終了する。ここに、rttbaseは通信を開始してから現時点までに計測した最小のrttである。
【００１１】
また、スロースタートフェーズの前に、独自の帯域測定を行う技法が提案されている（例えば、特許文献１参照）。この技法では、通信開始時にＴＣＰの輻輳ウインドウサイズにはよらず予め決められた数のパケットを送信し、その結果をＴＣＰの輻輳制御方式にフィードバックすることで、より高速に輻輳ウインドウサイズを拡大可能としている。
【００１２】
これらのスロースタートフェーズに関する動作を適用可能な従来技術のＲＦＣ５６８１やＲＦＣ３７４２等に基づくパケット送信装置を総括するに、そのパケット送信装置１１の概略構成を示すと、図１３のようになる。尚、図１３に示すパケット送信装置１１は、後述する本発明との対比に係る機能ブロックのみを図示したものであり、送達確認を行うパケット通信方式のパケット送信装置としてその他の必要な機能は、従来から知られている既知の技術と同様の構成とすることができ、その詳細な説明は省略する。図１３に示す従来技術に基づくパケット送信装置１１は、送信時刻書込部１１１、パケット送信部１１２、送達確認応答受信部１１３、パケットロス判定部１１４及びパケット送信制御部１１５を備え、パケット送信制御部１１５は、ロス再送動作部１１６、ロスリカバリ動作部１１７、輻輳回避動作部１１８及びスロースタート動作部１１９からなる。
【００１３】
送信時刻書込部１１１は、パケット送信時に送信時刻を記録する。この送信時刻は、パケット送信装置１１の本体内メモリ（図示せず）にパケット番号とともに記録することができる。或いは、ＴＣＰのタイムスタンプオプションを用いて記録することもできる。
【００１４】
パケット送信部１１２は、パケット受信装置２１に向けてパケットを送信する。その後、送達確認応答受信部１１３は、パケット受信装置２１から通知される送達確認応答用パケットを受信すると、次の処理を開始する。
【００１５】
送達確認応答受信部１１３は、送達確認応答用パケットを受信すると、パケット送信部１１２からのパケット送信から送達確認応答用パケットを受信するまでにかかったrttを計算する。rttの計算は、本体内メモリに記録した送信時刻と受信時刻の差とすることができる。或いは、ＴＣＰタイムスタンプオプションを用いることができる。rttの計算後、送達確認応答受信部１１３は、パケットロス判定部１１４へ送達確認応答用パケットとrttを通知する。
【００１６】
パケットロス判定部１１４は、送達確認応答部１１３から送達確認応答用パケットとrttを受信すると、rttbaseを更新し、パケットロスの発生の有無を判定する。パケットロスが発生している場合には、パケットロス判定部１１４は、ロス再送動作部１１６へ送達確認応答用パケットとrttを通知し、所定のパケットロス再送動作を実行させる。パケットロスが発生していない場合は、パケットロス判定部１１４は、現在の動作フェーズがロスリカバリフェーズの場合はロスリカバリ動作部１１７へ、輻輳回避フェーズの場合は輻輳回避動作部１１８へ、送達確認応答用パケットとrttを通知する。また、パケットロス判定部１１４は、スロースタートフェーズの場合はスロースタート動作部１１９へ、式（１）に関する所定のスロースタートの動作指示を通知する。
【００１７】
ロス再送動作部１１６は、送達確認応答用パケットとrttを基に送信パケットの再送処理を実行する。
【００１８】
ロスリカバリ動作部１１７は、送達確認応答用パケットとrttを基にパケットロスの発生後の通信状況の回復を行うようcwndの値の拡大又は縮小の調整処理を実行する。
【００１９】
輻輳回避動作部１１８は、送達確認応答用パケットとrttを基に通信路の輻輳を回避するようcwndの値を更新する。
【００２０】
ただし、ロス再送動作部１１６、ロスリカバリ動作部１１７及び輻輳回避動作部１１８は、一般的なＴＣＰなどを含み既知の輻輳制御技法に基づいたレート制御処理を実行するように構成すればよく、その動作の更なる詳細については省略する。
【００２１】
スロースタート動作部１１９は、パケットロスが発生していない間、式（１）を基にcwndの値を拡大するよう更新する。
【００２２】
このようにして、パケット送信制御部１１５は、パケットロスの発生の有無に応じて各種の動作フェーズに基づいたレート制御を実行する。
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】特許第４３６７５０５号明細書
【非特許文献】
【００２４】
【非特許文献１】“RFC793-Transmission Control Protocol”、［online］、昭和56（西暦1981）年9月策定、DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION、［平成26年12月19日検索］、インターネット〈URL：http://www.rfc-base.org/txt/rfc-793.txt〉
【非特許文献２】“RFC5681-TCP Congestion Control”、［online］、平成21（西暦2009）年9月策定、Network Working Group、［平成26年12月19日検索］、インターネット〈URL：http://tools.ietf.org/search/rfc5681〉
【非特許文献３】Sangtae Ha, Injong Rhee and Lisong Xu，“CUBIC: A New TCP-Friendly High-Speed TCP Variant,”［online］、ACM SIGOPS Operating System Review, Volume 42, Issue 5, July 2008、［平成26年12月19日検索］、インターネット〈URL：http://dl.acm.org/citation.cfm?id=1400105〉
【非特許文献４】kun Tan, Jingmin Song, Qian Zhang and Murari Sridharan,“A Compound TCP Approach for High-speed and Long Distance Networks,” ［online］、 INFOCOM 2006. 25th IEEE International Conference on Computer Communications. Proceedings, April 2006, ［平成26年12月19日検索］、インターネット〈URL：http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4146841&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4146841〉
【非特許文献５】“RFC3742-Limited Slow-Start for TCP with Large Congestion windows”、［online］、平成16（西暦2004）年3月策定、Network Working Group、［平成26年12月19日検索］、インターネット〈URL：https://tools.ietf.org/html/rfc3742〉
【非特許文献６】Sangtae  Ha and Injong Rhee, “Hybrid slow start for high-bandwidth and long-distance networks,” ［online］、 PFLDnet, 2008,［平成26年12月19日検索］、インターネット〈URL：http://netsrv.csc.ncsu.edu/export/hybridstart_pfldnet08.pdf〉
【発明の概要】
【発明が解決しようとする課題】
【００２５】
ＲＦＣ５６８１では、通信開始時にはssthreshは十分に大きい値（例えば取りうる最大の値）に設定されることが推奨されており、結果的にパケットロスが発生するまでスロースタートフェーズが継続する。パケットロスが発生するまで急速にcwndを拡大しネットワークにパケットを送出するため、他のトラフィックに影響を与えてしまう。また、パケットロスが発生すると損失したパケットを再度送り直す必要があるため、自身の通信効率も低下する。
【００２６】
そこで、パケットロスを発生させずにスロースタートフェーズから輻輳回避フェーズへ移行することで上記の問題を解決することができる。ただし、非特許文献５に開示されるＬｉｍｉｔｅｄ Ｓｌｏｗ‐Ｓｔａｒｔではロスが発生する前にcwndの増加速度を落とすことで一度に多くのパケットロスが発生すること避けるが、パケットロスが発生するまではスロースタートフェーズが終了しないため、最終的にパケットロスが発生してしまう。また、通信開始時にはmax_ssthreshの値は不明であり、ＲＦＣ５６８１と同じ挙動となってしまうという問題がある。
【００２７】
また、非特許文献６に開示されるＨｙｓｔａｒｔではスロースタートフェーズにおいて送信されるパケットのrttを用い、パケットロスが発生する前に輻輳を検知することで輻輳回避フェーズへ移行する技法を提示している。しかし、Ｈｙｓｔａｒｔでは有線ネットワークのように伝搬遅延が安定した環境を前提にしており、各rtt期間に計測するrttのうち、先頭の数サンプルのみを用いて輻輳検知を実施しているため、無線ネットワークのように輻輳とは無関係に伝搬遅延が変化するネットワークでは、cwndが拡大する前に輻輳回避フェーズへ移行してしまうことがある。
【００２８】
また、特許文献１に開示される技法では、通信開始時に回線状況が不明なまま、予め定められた負荷をかけるため、輻輳を引き起こし回線の品質を下げる可能性がある。
【００２９】
本発明は、上述の問題に鑑みてなされたものであり、本発明の目的は、送達確認を行うパケット通信において、無線ネットワークのような遅延変動が起きやすい環境でも通信開始時におけるパケットロスを抑制し、高速な通信を可能にするパケット通信におけるパケット送信装置、通信端末及びスロースタート制御方法を提供することにある。
【課題を解決するための手段】
【００３０】
本発明によるパケット送信装置は、スロースタートフェーズにおいて、パケットの送受信結果から輻輳ウインドウサイズの上限値を決定し、スロースタートフェーズ終了判定に用いるよう構成する。
【００３１】
即ち、本発明のパケット送信装置は、送達確認に基づいて輻輳ウインドウサイズを決定しパケット送信に関するスロースタート制御を行うパケット送信装置であって、パケット送信の送達確認として通知される送達確認応答用パケットを受信し、該パケット送信の送信時刻と該送達確認応答用パケットの受信時刻との差から当該パケット送信の送達確認に基づく往復遅延時間を算出する送達確認応答受信手段と、通信開始から輻輳ウインドウサイズを拡大しつつ輻輳判定を行って、輻輳と判定した際にスロースタートフェーズから輻輳回避フェーズへ遷移させるように動作するスロースタート制御手段とを備え、前記スロースタート制御手段は、スロースタートフェーズで動作中に、前記往復遅延時間について継続して計測した最小の往復遅延時間と、輻輳ウインドウサイズの更新が為される度に所定の更新式に基づいて更新される輻輳ウインドウサイズの最大値と、当該受信した送達確認応答用パケットに対して最近時に受信したパケット群の送信時刻及び受信時刻とに基づいて、予め定めたパケット遅延量に関する計測期間毎に前記輻輳ウインドウサイズの上限値を決定する輻輳ウインドウ上限算出手段と、前記送達確認応答用パケットを受信する度に直前の１計測期間の経過時に決定された当該輻輳ウインドウサイズの上限値以下で前記輻輳ウインドウサイズを所定幅で拡大し、当該計測期間毎に該輻輳ウインドウサイズの上限値と当該拡大した輻輳ウインドウサイズとを比較して、前記拡大した輻輳ウインドウサイズが該輻輳ウインドウサイズの上限値以上となる際に、スロースタートフェーズから輻輳回避フェーズへ遷移させるように動作する輻輳ウインドウ増加手段と、を有することを特徴とする。
【００３２】
また、本発明のパケット送信装置において、前記輻輳ウインドウ上限算出手段は、前記送達確認応答用パケットを受信する度に、該送達確認応答用パケットに対応する送信パケットの送信レートが前記輻輳ウインドウサイズの最大値から求められる送信レート以上であるか否かを判定する第１判定手段と、前記送達確認応答用パケットを受信する度に、最近時に受信したパケット群に含まれるか否かの判定を行う第２判定手段と、前記第１判定手段及び前記第２判定手段の双方の判定を満たすときは当該最近時に受信したパケット群の受信バイト数に該送達確認応答用パケットにより送達確認したバイト数を加えた受信バイト数を定め、前記第１判定手段及び前記第２判定手段のいずれか一方の判定を満たさないときには、該受信バイト数から求められる当該最近時に受信したパケット群の受信レートを基準にした輻輳ウインドウサイズを算出して当該計測期間毎に更新し、当該更新した輻輳ウインドウサイズを前記輻輳ウインドウサイズの上限値として決定する輻輳ウインドウ上限決定手段と、を有することを特徴とする。
【００３３】
また、本発明のパケット送信装置において、前記輻輳ウインドウサイズの最大値は、前記所定の更新式として、更新された輻輳ウインドウサイズの２倍の値か、又は更新された輻輳ウインドウサイズの２倍の値と、直前の１計測期間の経過時に決定された前記輻輳ウインドウサイズの上限値のうち小さい方の値により更新されることを特徴とする。
【００３４】
また、本発明のパケット送信装置において、前記スロースタート制御手段は、受信する送達確認応答用パケット毎の往復遅延時間の変動量を監視して連続する往復遅延時間パケットのパケット列の最大の変動量を計測し、当該計測期間毎に当該最大の変動量について移動平均した値を往復遅延時間の平均変動量として算出する遅延変動量推定手段を更に備え、前記輻輳ウインドウ上限算出手段は、前記平均変動量を加味して当該輻輳ウインドウの上限値を決定する手段を有し、前記輻輳ウインドウ増加手段は、前記往復遅延時間について継続して計測した最小の往復遅延時間に当該平均変動量を加えた値と、直前の１計測期間で最小の値として計測した計測期間内最小の往復遅延時間とを比較して、該計測期間内最小の往復遅延時間が前記往復遅延時間について継続して計測した最小の往復遅延時間に当該平均変動量を加えた値を超える際に、スロースタートフェーズから輻輳回避フェーズへ遷移させるように動作する手段を更に有することを特徴とする。
【００３５】
更に、本発明の通信端末は、本発明のパケット送信装置を備えることを特徴とする。
【００３６】
更に、本発明のスロースタート制御方法は、送達確認に基づいて輻輳ウインドウサイズを決定しパケット送信に関するスロースタート制御を行うスロースタート制御方法であって、スロースタートフェーズで動作中に、パケット送信の送信時刻と送達確認応答用パケットの受信時刻との差から当該パケット送信の送達確認に基づく往復遅延時間について継続して計測した最小の往復遅延時間と、輻輳ウインドウサイズの更新が為される度に所定の更新式に基づいて更新される輻輳ウインドウサイズの最大値と、当該受信した送達確認応答用パケットに対して最近時に受信したパケット群の送信時刻及び受信時刻とに基づいて、予め定めたパケット遅延量に関する計測期間毎に前記輻輳ウインドウサイズの上限値を決定するステップと、前記送達確認応答用パケットを受信する度に直前の１計測期間の経過時に決定された当該輻輳ウインドウサイズの上限値以下で前記輻輳ウインドウサイズを所定幅で拡大し、当該計測期間毎に該輻輳ウインドウサイズの上限値と当該拡大した輻輳ウインドウサイズとを比較して、前記拡大した輻輳ウインドウサイズが該輻輳ウインドウサイズの上限値以上となる際に、スロースタートフェーズから輻輳回避フェーズへ遷移させるように動作するステップと、を含むことを特徴とする。
【発明の効果】
【００３７】
送達確認を行うパケット通信において、無線ネットワークのような遅延変動が起きやすい環境で生じうる輻輳とは無関係の遅延による輻輳の誤検出を抑制し、また、バースト的なパケットロスの発生を抑制し、これにより通信開始時のスロースタートフェーズにおける輻輳ウインドウサイズを拡大させる前の輻輳回避フェーズへの移行を効率よく抑制することができるので、高速な通信が可能となる。
【図面の簡単な説明】
【００３８】
【図１】本発明による一実施形態のパケット送信装置におけるブロック図である。
【図２】本発明による一実施形態のパケット送信装置における送達確認応答受信部の処理を示すフローチャートである。
【図３】本発明による一実施形態のパケット送信装置におけるパケットロス判定部の処理を示すフローチャートである。
【図４】（Ａ），（Ｂ）は、本発明による一実施形態のパケット送信装置に係るパケット遅延量に関する計測期間の説明図である。
【図５】本発明による一実施形態のパケット送信装置における実施例１のスロースタート動作部の構成を示すブロック図である。
【図６】本発明による一実施形態のパケット送信装置における実施例１のスロースタート動作部の輻輳ウインドウ増加処理を示すフローチャートである。
【図７】本発明による一実施形態のパケット送信装置における実施例１のスロースタート動作部の輻輳ウインドウ上限算出処理を示すフローチャートである。
【図８】本発明による一実施形態のパケット送信装置における実施例２のスロースタート動作部の構成を示すブロック図である。
【図９】本発明による一実施形態のパケット送信装置における実施例２のスロースタート動作部の輻輳ウインドウ増加処理を示すフローチャートである。
【図１０】本発明による一実施形態のパケット送信装置における実施例２のスロースタート動作部の遅延変動量算出処理を示すフローチャートである。
【図１１】本発明による一実施形態のパケット送信装置における実施例２のスロースタート動作部の輻輳ウインドウ上限算出処理を示すフローチャートである。
【図１２】ＴＣＰを利用して相互通信接続を行う通信端末のネットワーク接続例を説明する図である。
【図１３】従来技術に基づくパケット送信装置におけるブロック図である。
【発明を実施するための形態】
【００３９】
以下、図面を参照して、本発明による一実施形態のパケット送信装置、通信端末及びスロースタート制御方法を説明する。
【００４０】
図１は、本発明による一実施形態のパケット送信装置１１ａにおけるブロック図である。パケット送信装置１１ａは、図１３に示すパケット送信装置１１に置き換えて、図１２に示す通信端末１０に設ける装置である。同様に、通信端末２０に対しても、パケット送信装置２２に置き換えてパケット送信装置１１ａと同様の構成を設けることができる。したがって、図１２に示すように、ＴＣＰを利用して相互通信接続を行う通信端末１０，２０において、パケット送信装置１１ａは、データ送信用パケットを所定の通信路を介してパケット受信装置２１に送信すると、パケット受信装置２１は、受信した旨の報告として送達確認応答用パケットをパケット送信装置１１ａに送信する。尚、図１に示すパケット送信装置１１ａは、本発明に係る機能ブロックのみを図示したものであり、送達確認を行うパケット通信方式のパケット送信装置としてその他の必要な機能は、従来から知られている既知の技術と同様の構成とすることができ、その詳細な説明は省略する。
【００４１】
図１に示すように、本実施形態のパケット送信装置１１ａは、送信時刻書込部１１１、パケット送信部１１２、送達確認応答受信部１１３、パケットロス判定部１１４及びパケット送信制御部１１５を備え、パケット送信制御部１１５は、ロス再送動作部１１６、ロスリカバリ動作部１１７、輻輳回避動作部１１８及びスロースタート動作部１１９ａからなる。尚、図１３に示すパケット送信装置１１と比較して、本実施形態のパケット送信装置１１ａは、スロースタート動作部１１９の代わりに、スロースタート動作部１１９ａを備える点で相違しており、同様な構成要素には同一の参照番号を付している。
【００４２】
送信時刻書込部１１１は、データ送信用パケットの送信時の送信時刻を記録する。この送信時刻は、パケット送信装置１１の本体内メモリ（図示せず）にパケット番号とともに記録することができる。或いは、ＴＣＰのタイムスタンプオプションを用いて記録することもできる。
【００４３】
パケット送信部１１２は、パケット受信装置２１に向けてパケットを送信する。その後、送達確認応答受信部１１３は、パケット受信装置２１から通知される送達確認応答用パケット（以下、「ＡＣＫパケット」と表記する。）を受信すると、次の処理を開始する。
【００４４】
送達確認応答受信部１１３は、ＡＣＫパケットを受信すると、パケット送信部１１２からのパケット送信からＡＣＫパケットを受信するまでにかかった往復遅延時間（rtt）を計算する。rttの計算は、本体内メモリに記録した当該ＡＣＫパケットに対応する送信パケットの送信時刻（以下、「sndtime」と表記する。）と当該ＡＣＫパケットの受信時刻（以下、「rcvtime」と表記する。）の差とすることができる。或いは、本体内メモリに記録する代わりに、ＴＣＰタイムスタンプオプションを用いることができる。rttの計算後、送達確認応答受信部１１３は、パケットロス判定部１１４へＡＣＫパケットとrtt，sndtime，rcvtimeを通知する。より具体的には、図２に示すように、送達確認応答受信部１１３は、ＡＣＫパケットを受信すると（ステップＳ１１）、送信時刻（sndtime）と受信時刻（rcvtime）の差から往復遅延時間（rtt）を求め（ステップＳ１２）、rttの計算後、パケットロス判定部１１４へＡＣＫパケット及びrtt，sndtime，rcvtimeを通知する（ステップＳ１３）。
【００４５】
パケットロス判定部１１４は、送達確認応答部１１３からＡＣＫパケットと、rtt，sndtime，rcvtimeを受信すると、ＡＣＫパケット内の送達確認番号（「ＡＣＫ番号」とも称される。）によりパケットロス判定を行う。パケットロスが発生している場合には、パケットロス判定部１１４は、ロス再送動作部１１６へＡＣＫパケットとrttを通知する。パケットロスが発生していない場合は、パケットロス判定部１１４は、現在の動作フェーズがロスリカバリフェーズの場合はロスリカバリ動作部１１７へＡＣＫパケットとrttを通知し、輻輳回避フェーズの場合は輻輳回避動作部１１８へＡＣＫパケットとrttを通知し、スロースタートフェーズの場合はスロースタート動作部１１９ａへＡＣＫパケットとrtt、sndtime、rcvtimeを通知する。より具体的には、図３に示すように、パケットロス判定部１１４は、送達確認応答受信部１１３から送達確認応答用パケットとrttを受信すると（ステップＳ２１）、パケットロスが発生しているか否かの判定を行う（ステップＳ２２）。パケットロスの判定には、例えばＡＣＫパケットに含まれるＡＣＫ番号が同じパケットを３回受信した場合とする方法がある。
【００４６】
パケットロスが発生している場合には（ステップＳ２２：Ｙｅｓ）、パケットロス判定部１１４は、ロス再送動作部１１６へＡＣＫパケットとrttを通知し、所定のパケットロス再送動作を実行させる（ステップＳ２３）。パケットロスが発生していない場合は（ステップＳ２２：Ｎｏ）、パケットロス判定部１１４は、現在の動作フェーズがロスリカバリフェーズの場合はロスリカバリ動作部１１７へ（ステップＳ２４，Ｓ２５）、輻輳回避フェーズの場合は輻輳回避動作部１１８へ（ステップＳ２４，Ｓ２６）、ＡＣＫパケットとrttを通知する。また、パケットロス判定部１１４は、スロースタートフェーズの場合は本発明に係るスロースタート動作部１１９ａへ、ＡＣＫパケットとrtt、sndtime、rcvtimeを通知する（ステップＳ２４，Ｓ２７）。
【００４７】
パケット送信制御部１１５は、パケットロスの発生の有無に応じて各種の動作フェーズに基づいたレート制御を実行する。尚、ロス再送動作部１１６、ロスリカバリ動作部１１７及び輻輳回避動作部１１８は、一般的なＴＣＰなどを含み既知の輻輳制御技法に基づいたレート制御処理を実行するように構成すればよく、その動作の更なる詳細については省略する。特に、パケット送信制御部１１５は、スロースタート動作部１１９ａによる比較的高速に輻輳ウインドウサイズを拡大するスロースタートフェーズと、輻輳回避動作部１１８による比較的緩やかに輻輳ウインドウサイズを調整する輻輳回避フェーズとを遷移しながらレート制御を実行するよう動作する。
【００４８】
詳細に後述するが、本発明に係る実施例１のスロースタート動作部１１９ａは、通信を開始してから現時点までに計測した最小のrttであるrttbaseを用い、このrttbaseを比較・監視しつつ、パケットの送受信結果から輻輳ウインドウサイズの上限値（以下、「cwndlimit」と表記する。）を決定し、スロースタートフェーズの終了判定に用いるよう構成される。また、本発明に係る実施例２のスロースタート動作部１１９ａは、通信を開始してから現時点までに計測した最小のrttであるrttbaseと、受信したＡＣＫパケットに対応するrttに関して予め定めた１計測期間毎に計測する全てのrttの中で最小のrttであるrttminを算出・更新し、このrttbase及びrttminを比較・監視しつつ、パケット遅延の変動量を考慮してパケットの送受信結果から輻輳ウインドウサイズの上限値（cwndlimit）を決定し、スロースタートフェーズの終了判定に用いるよう構成される。尚、本発明に係るrttminは、非特許文献６に開示されるＨｙｓｔａｒｔにおける最小のrtt（rttmin）とは相違する点に留意する。
【００４９】
ここで、「計測期間」に関して説明する。例えば、図４（Ａ）に示すように、通信端末１０が連続的に送信するデータ送信用パケットＤ１，Ｄ２，Ｄ３を通信端末２０に向けて送信するとともに、データ送信用パケットＤ１，Ｄ２，Ｄ３の各々に対応するＡＣＫパケットＡＣＫ１，ＡＣＫ２，ＡＣＫ３を受信する場合を考えたとき、１計測期間は、計測期間の計測の開始から通信端末１０（パケット送信装置１１ａ）が最初に送信するパケットに対する送達確認応答（ＡＣＫ）が到着するまで、とすることができる。
【００５０】
或いは、図４（Ｂ）に示すように、１計測期間は、計測期間の計測の開始から所定時間経過時まで（例えば、直前の１計測期間における最小のrtt（rttmin）経過時まで）、とすることができる。尚、計測期間は、ＩＰデータフローに対して連続的に定めてもよいし、間欠的に定めてもよく、計測期間で求めたrttminは少なくとも次回の計測期間でrttminを求めるまで保持するように構成し、rttminを用いるcwnd等の更新にはその更新時点で保持するrttminを用いるようにする。
【００５１】
（実施例１のスロースタート動作部）
まず、本発明に係る実施例１のスロースタート動作部１１９ａについて、図５乃至図７を参照して説明する。図５は、本発明に係る実施例１のスロースタート動作部１１９ａの構成を示すブロック図である。図６は、本発明に係る実施例１のスロースタート動作部１１９ａの輻輳ウインドウ増加処理を示すフローチャートである。図７は、本発明に係る実施例１のスロースタート動作部１１９ａの輻輳ウインドウ上限算出処理を示すフローチャートである。
【００５２】
図５に示すように、実施例１のスロースタート動作部１１９ａは、輻輳ウインドウ増加処理を実行する輻輳ウインドウ増加部１１９１と、輻輳ウインドウ上限算出処理を実行する輻輳ウインドウ上限算出部１１９２とを備える。
【００５３】
まず、図６を参照して、輻輳ウインドウ増加部１１９１による輻輳ウインドウ増加処理を説明する。
【００５４】
輻輳ウインドウ増加部１１９１は、パケットロス判定部１１４からＡＣＫパケットと、rtt，sndtime，rcvtimeを受信すると（ステップＳ３１）、式（２）によりrttbaseを更新する（ステップＳ３２，Ｓ３３）。rttbaseは通信開始から通信中に計測したrttの最小値である。rttbaseの通信開始時における初期値は、とりうる最大の値など、或る決まった値とすることができる。
【００５５】
if     rttbase ＞ rtt                                         （２）
then   rttbase ＝ rtt
【００５６】
次に、輻輳ウインドウ増加部１１９１は、ＡＣＫパケットと、rttbase，sndtime，rcvtime，cwndmaxを輻輳ウインドウ上限算出部１１９２に通知する（ステップＳ３４）。cwndmaxは、輻輳ウインドウ上限算出部１１９２において輻輳ウインドウサイズの上限値（cwndlimit）の算出に用いる値である。cwndmaxの値の計算方法（更新方法）や、輻輳ウインドウサイズの上限値（cwndlimit）の算出手順については後述する。
【００５７】
続いて、輻輳ウインドウ増加部１１９１は、輻輳ウインドウ上限算出部１１９２からcwndlimitを受信すると（ステップＳ３５）、１計測期間を経過していたか否かを判定する（ステップＳ３６）。１計測期間の判定方法として、前述した図４のように、例えば１計測期間の測定を開始してから最初に送信したパケットに対する送達確認応答を受信した時とする方法や、１計測期間の開始時から所定時間が経過した時とする方法がある。この１計測期間が経過していた場合（ステップＳ３６：Ｙｅｓ）、輻輳ウインドウ増加部１１９１は、スロースタートフェーズを終了するか否かの判定を行う（ステップＳ３８〜Ｓ４０）。この判定は現在の輻輳ウインドウサイズ（cwnd）と輻輳ウインドウサイズの上限値（cwndlimit）の比較によって行われ、即ち式（３）によって行う。
【００５８】
if     cwnd ≧ cwndlimit                                       （３）
then   スロースタートフェーズを終了、
else   スロースタートフェーズを継続。
【００５９】
そして、スロースタートフェーズを終了する場合（ステップＳ３８：Ｙｅｓ）、式（４）に示す処理を行う（ステップＳ４０）。
【００６０】
ssthresh ＝ cwnd                                              （４）
cwnd ＝ cwnd ＋ MSS
【００６１】
一方、スロースタートフェーズを継続する場合（ステップＳ３８：Ｎｏ）、式（５）に示す処理を行う（ステップＳ３９）。
【００６２】
cwnd ＝ min(cwnd ＋ γ，cwndlimit)                            （５）
【００６３】
γは、１回のＡＣＫパケットの受信で増加させる輻輳ウインドウサイズ（cwnd）の大きさであり、MSS、又は今回受信したＡＣＫパケットにより送達確認が行われたバイト数とすることができる。
【００６４】
また、スロースタートフェーズを継続する場合（ステップＳ３８：Ｎｏ）、cwndmaxの更新も行う（ステップＳ３９）。cwndmaxは、輻輳ウインドウ上限算出部１１９２において輻輳ウインドウサイズの上限値（cwndlimit）の算出に用いる値であり、より具体的には次回のスロースタートフェーズ終了判定までに取りうる輻輳ウインドウの最大値であり、cwndmaxの初期値として、通信開始時には取りうる最大の値とすることができる。また、通信開始後にスロースタート閾値（ssthresh）を用いてスロースタートフェーズと輻輳回避フェーズの切り替えが為されていたときは、今回のスロースタートフェーズに用いるcwndmaxの初期値をスロースタート閾値（ssthresh）の値とすることができる。
【００６５】
cwndmaxは、今回のスロースタートフェーズにてcwndが更新される度に所定の更新式に基づいて更新され、より具体的な更新式の例として、輻輳ウインドウ増加部１１９１は、例えば更新するcwndmaxを、更新されたcwndの２倍の値とすることや、更新されたcwndの２倍の値と、直前の１計測期間の経過時に決定された輻輳ウインドウサイズの上限値cwndlimitのうち小さい方の値として決定する。
【００６６】
そして、１計測期間が経過していないと判定した場合（ステップＳ３６：Ｎｏ）、輻輳ウインドウ増加部１１９１は、式（５）に示す処理を行う（ステップＳ３７）。
【００６７】
次に、図７を参照して、輻輳ウインドウ上限算出部１１９２による輻輳ウインドウ上限算出処理を説明する。
【００６８】
輻輳ウインドウ上限算出部１１９２は、輻輳ウインドウ増加部１１９１からＡＣＫパケットと、rttbase，sndtime，rcvtime，cwndmaxを受信すると（ステップＳ４１）、輻輳ウインドウサイズの上限値cwndlimitを下記の手順で計算する。cwndlimitは、今回のスロースタートフェーズ中に輻輳ウインドウサイズを増加させる場合の上限値であり、ＡＣＫパケットから受信レートを算出し計算を行う。cwndlimitの初期値は、事前に想定した予め定めた最大値（取りうる最大の値）とすることができる。
【００６９】
輻輳ウインドウサイズの上限値cwndlimitの算出は、ＡＣＫパケットを受信する度に行い、まず、cwndmaxから求められる送信レートと、今回受信したＡＣＫパケットに対応する送信パケットの送信レートとの比較を行う（ステップＳ４２）。
【００７０】
今回受信したＡＣＫパケットに対応する送信パケットの送信レートが、cwndmaxから求められる送信レート以上であるときに（ステップＳ４２：Ｙｅｓ）、続いて、今回受信したＡＣＫパケットが最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなすＡＣＫパケット群）に含まれるか否かの判定を行う（ステップＳ４３）。これにより、無線ネットワークのような遅延変動が起きやすい環境でスロースタートフェーズ時に生じうる輻輳による遅延変動を有して受信するＡＣＫパケットが一連の送信パケットに対応するものとして扱うか否かを判定する。この判定には、以下の二例の判定方法が有効である。
【００７１】
第１例の判定方法は、式（６）により行う。尚、sndtimelastは、直前に受信したＡＣＫパケットに対応する送信パケットの送信時刻である。
【００７２】
if    sndtime−sndtimelast ≦ (MSS／cwndmax)×rttbase            （６）
then  最近時に受信したパケット群に含まれる。
else  最近時に受信したパケット群に含まれない。
【００７３】
第２例の判定方法は、式（７）により行う。尚、rcvbyteは最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなしたＡＣＫパケット群）で受信したバイト数、sndtimefirstは最近時に受信したパケット群の先頭のＡＣＫパケットに対応する送信パケットの送信時刻である。
【００７４】
if   sndtime−sndtimefirst ≦
((rcvbyte ＋ 送達確認バイト数)／cwndmax)×rttbase          （７）
then  最近時に受信したパケット群に含まれる。
else  最近時に受信したパケット群に含まれない。
【００７５】
今回受信したＡＣＫパケットに対応する送信パケットの送信レートが、cwndmaxから求められる送信レート以上でないとき（ステップＳ４２：Ｎｏ）、及び、今回受信したＡＣＫパケットが最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなすＡＣＫパケット群）に含まれないと判定したとき（ステップＳ４３：Ｎｏ）、最近時に受信したパケット群の記録から式（８）により、最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなしたＡＣＫパケット群）の受信レートを基準にして、この受信レートを満たす輻輳ウインドウサイズcwndestを算出する（ステップＳ４５）。
【００７６】
cwndest ＝ rcvbyte × rttbase／(rcvtimelast−rcvtimefirst)      （８）
【００７７】
ここに、rcvbyteは最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなしたＡＣＫパケット群）で受信したバイト数、rcvtimelastは最近時に受信したパケット群のうち最後のＡＣＫパケットを受信した時刻、rcvtimefirstは最近時に受信したパケット群のうち先頭のＡＣＫパケットを受信した時刻である。
【００７８】
また、１rtt以上に輻輳ウインドウサイズの算出に要する計測状態が継続することを防ぐことを意図して、１rtt未満で定期的に、輻輳ウインドウサイズの算出を行うようにするために、式（９）に示すように、今回受信したＡＣＫパケットに対応する送信パケットに対して連続した送信の期間（sndtime - sndtimefirst）が所定の閾値（本例では、rttbase ／２）を超える場合も、式（８）による輻輳ウインドウサイズcwndestを算出するようにする。
【００７９】
if    sndtime−sndtimefirst ＞ rttbase ／２                      （９）
then  式（８）による輻輳ウインドウサイズの算出。
【００８０】
cwndestを算出すると、式（１０）により１計測期間でのcwndestの最大値cwndlimit-tmpを更新する（ステップＳ４６，Ｓ４７）。尚、cwndlimit-tmpの初期値は、cwndlimit-tmp ＝ ０である。
【００８１】
if    cwndlimit-tmp ＜ cwndest                                （１０）
then  cwndlimit-tmp ＝ cwndest
【００８２】
更に、次に受信するＡＣＫパケットに関するステップＳ４４の判定や、輻輳ウインドウサイズの算出のために、式（１１）のように各変数をリセットする（ステップＳ４８）。
【００８３】
rcvbyte ＝ ０                                                 （１１）
sndtimefirst ＝ sndtime
rcvtimefirst ＝ rcvtime
【００８４】
今回受信したＡＣＫパケットに対応する送信パケットの送信レートが、cwndmaxから求められる送信レート以上であり（ステップＳ４２：Ｙｅｓ）、今回受信したＡＣＫパケットが最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなすＡＣＫパケット群）に含まれると判定したとき（ステップＳ４３：Ｙｅｓ）、即ち送信間隔に基づく判定で連続したパケット列とみなし、且つ連続したパケット列に関する送信パケットの所定の送信期間が予め定めた閾値を超えない場合、式（１２）により、当該連続したパケット列の受信バイト数を更新する（ステップＳ４４）。
【００８５】
rcvbyte ＝ rcvbyte ＋ 送達確認バイト数                        （１２）
【００８６】
次に、１計測期間が経過したか否かを判定し（ステップＳ４９）、１計測期間が経過していたと判定するときは（ステップＳ４９：Ｙｅｓ）、cwndlimit-tmpの更新が行われているか否かを判定する（ステップＳ５０）。
【００８７】
cwndlimit-tmpの更新が行われている場合に（ステップＳ５０：Ｙｅｓ）、式（１３）によりcwndlimitを更新する（ステップＳ５１）。
【００８８】
if     cwndlimit-tmp ＞ ０                                    （１３）
then   cwndlimit ＝ cwndlimit-tmp  ，
cwndlimit-tmp ＝ ０
【００８９】
１計測期間を経過していないと判定したとき（ステップＳ４９：Ｎｏ）、及び、cwndlimit-tmpの更新が行われていないとき（ステップＳ５０：Ｎｏ）、cwndlimitは前回値のままである。
【００９０】
ステップＳ５０を経てcwndlimitの値が決定されると、式（１４）によりsndtimelast, rcvtimelastを更新する（ステップＳ５２）。尚、実施例１では、式（６）による場合のみ、sndtimelastを利用する。
【００９１】
sndtimelast ＝ sndtime                                       （１４）
rcvtimelast ＝ rcvtime
【００９２】
最後に、輻輳ウインドウ上限算出部１１９２は、cwndlimitを輻輳ウインドウ増加部１１９１へ通知する（ステップＳ５３）。したがって、輻輳ウインドウ上限算出部１１９２は、ステップＳ４２及びステップＳ４３の双方の判定を満たすときは当該最近時に受信したパケット群の受信バイト数に今回受信したＡＣＫパケットにより送達確認したバイト数を加えた受信バイト数を定め（ステップＳ４４）、ステップＳ４２及びステップＳ４３のいずれか一方の判定を満たさないときには、該受信バイト数から求められる当該最近時に受信したパケット群の受信レートを基準にした輻輳ウインドウサイズ（cwndlimit-tmp）を算出して１計測期間毎に更新し、１計測期間毎に更新した該輻輳ウインドウサイズ（cwndlimit-tmp）を輻輳ウインドウサイズの上限値（cwndlimit）として決定する。そして、輻輳ウインドウ増加部１１９１は、ＡＣＫパケットを受信する度に１計測期間の経過時に決定されたcwndlimit以下で輻輳ウインドウサイズ（cwnd）を所定幅で拡大し、計測期間毎に、１計測期間の経過時に決定されたcwndlimitと当該拡大したcwndとを比較してスロースタートフェーズから輻輳回避フェーズへの遷移を判定する。
【００９３】
このように、輻輳ウインドウ増加部１１９１及び輻輳ウインドウ上限算出部１１９２を備える実施例１のスロースタート動作部１１９ａを構成し、パケット送信装置１１ａに具備させることで、バースト的なパケットロスの発生を抑制し、これにより通信開始時のスロースタートフェーズにおける輻輳ウインドウサイズを拡大させる前の輻輳回避フェーズへの移行を効率よく抑制することができるので、高速な通信が可能となる。
【００９４】
（実施例２のスロースタート動作部）
次に、本発明に係る実施例１のスロースタート動作部１１９ａについて、図８乃至図１１を参照して説明する。図８は、本発明に係る実施例２のスロースタート動作部１１９ａの構成を示すブロック図である。図９は、本発明に係る実施例２のスロースタート動作部１１９ａの輻輳ウインドウ増加処理を示すフローチャートである。図１０は、本発明に係る実施例２のスロースタート動作部１１９ａの遅延変動量算出処理を示すフローチャートである。図１１は、本発明に係る実施例２のスロースタート動作部１１９ａの輻輳ウインドウ上限算出処理を示すフローチャートである。尚、図８は、実施例１と同様な構成要素には同一の参照番号を付している。
【００９５】
図８に示すように、実施例２のスロースタート動作部１１９ａは、輻輳ウインドウ増加処理を実行する輻輳ウインドウ増加部１１９１と、輻輳ウインドウ上限算出処理を実行する輻輳ウインドウ上限算出部１１９２と、輻輳とは無関係の遅延変動量を推定する遅延変動量推定部１１９３を備える。
【００９６】
実施例２において、遅延変動量推定部１１９３は、受信するＡＣＫパケット毎のrttの変動量を監視して連続するＡＣＫパケットのパケット列の最大の変動量を計測し、１計測期間毎に当該最大の変動量について移動平均した値をrttの平均変動量として算出する。そして、輻輳ウインドウ上限算出部１１９２は、このrttの平均変動量を加味して輻輳ウインドウの上限値（cwndlimit）を決定する。そして、輻輳ウインドウ増加部１１９１は、通信を開始してから現時点までに計測した最小のrtt（rttbase）に当該平均変動量を加えた値と、計測期間内におけるrttについて直前の１計測期間で計測した最小のrtt（rttmin）との比較によってスロースタート終了判定を行い、終了と判定された場合にはスロースタートフェーズから輻輳回避フェーズへ遷移させる。したがって、実施例２は、当該rttの平均変動量を加味してスロースタートフェーズの終了判定を行うことを可能とする点で、実施例１とは相違する。
【００９７】
まず、図９を参照して、輻輳ウインドウ増加部１１９１による輻輳ウインドウ増加処理を説明する。
【００９８】
輻輳ウインドウ増加部１１９１は、パケットロス判定部１１４からＡＣＫパケットと、rtt，sndtime，rcvtimeを受信すると（ステップＳ６１）、式（１５）によりrttminを更新する（ステップＳ６２，Ｓ６３）。rttminは直前の１計測期間で決定したrttの最小値である。尚、通信を開始してから１計測期間を経過する前のrttminの値は、通信を開始してから現時点までに計測した最小のrttであるrttbaseと同じ値とすることができる。尚、rttbaseの通信開始時における初期値は、とりうる最大の値など、或る決まった値とすることができる。また、１計測期間の開始から最初に計測したrttについては、その大きさに関わらずrttminに代入する。
【００９９】
if     (１計測期間で最初に計測したrtt) or (rttmin ＞ rtt)      （１５）
then   rttmin ＝ rtt
【０１００】
式（１５）によりrttminを更新した場合（ステップＳ６３）、続けて式（２）によりrttbaseを更新する（ステップＳ６４，Ｓ６５）。rttbaseは通信中に計測したrttの最小値である。通信開始時には、とりうる最大の値など、或る決まった値に初期化することができる。
【０１０１】
次に、輻輳ウインドウ増加部１１９１は、遅延変動量推定部１１９３へＡＣＫパケットと、rtt，sndtimeを通知し（ステップＳ６６）、遅延変動量推定部１１９３からjitteraveを受信する（ステップＳ６７）。jitteraveは輻輳とは無関係の遅延変動量であり、その算出方法は図１０を参照して後述する。
【０１０２】
次に、輻輳ウインドウ増加部１１９１は、ＡＣＫパケットと、rttbase，jitterave，sndtime，rcvtime，cwndmaxを輻輳ウインドウ上限算出部１１９２に通知する（ステップＳ６８）。cwndmaxは、輻輳ウインドウ上限算出部１１９２において輻輳ウインドウサイズの上限値（cwndlimit）の算出に用いる送信パケットを決定するために用いる値である。cwndmaxの値の計算方法（更新方法）は実施例１と同様であり、輻輳ウインドウサイズの上限値（cwndlimit）の算出手順については後述する。
【０１０３】
続いて、輻輳ウインドウ増加部１１９１は、輻輳ウインドウ上限算出部１１９２からcwndlimitを受信すると（ステップＳ６９）、１計測期間を経過しているか否かを判定する（ステップＳ７０）。この１計測期間が経過していた場合（ステップＳ７０：Ｙｅｓ）、輻輳ウインドウ増加部１１９１は、スロースタートフェーズを終了するか否かの判定を行う（ステップＳ７２）。この判定は式（１６）によって行う。
【０１０４】
if     rttmin ＞ rttbase ＋ jitterave                          （１６）
then   スロースタートフェーズを終了、
else   式（３）によりスロースタートフェーズの終了判定へ移行。
【０１０５】
式（３）によるスロースタートフェーズの終了判定は、現在の輻輳ウインドウサイズcwndと輻輳ウインドウサイズの上限値（cwndlimit）との比較によって行い（ステップＳ７３）、スロースタートフェーズを終了する場合（ステップＳ７２：Ｙｅｓ、又はステップＳ７３：Ｙｅｓ）、実施例１と同様に、式（４）に示す処理を行う（ステップＳ７５）。
【０１０６】
一方、スロースタートフェーズを継続する場合（ステップＳ７２：Ｎｏ、且つステップＳ７３：Ｎｏ）、実施例１と同様に、式（５）に示す処理を行う（ステップＳ７４）。
【０１０７】
また、スロースタートフェーズを継続する場合（ステップＳ７２：Ｎｏ、且つステップＳ７３：Ｎｏ）、cwndmaxの更新も行い、rttminは直前の１計測期間で決定したrttの最小値で初期化する（ステップＳ７４）。
【０１０８】
そして、１計測期間が経過していないと判定した場合（ステップＳ７０：Ｎｏ）、輻輳ウインドウ増加部１１９１は、式（５）に示す処理を行う（ステップＳ７１）。
【０１０９】
次に、図１０を参照して、遅延変動量推定部１１９３による遅延変動量算出処理を説明する。
【０１１０】
遅延変動量推定部１１９３は、輻輳ウインドウ増加部１１９１からＡＣＫパケットと、rtt，sndtimeを受信すると（ステップＳ８１）、式（１７）による最近時に受信したパケット群（ＡＣＫパケットのパケット列）と連続したパケットであるか否かの判定を行う（ステップＳ８２）。
【０１１１】
if    sndtime−sndtimelast ≦ β                              （１７）
then  連続したパケット、
else  連続していないパケット。
【０１１２】
sndtimelastは、直前に受信したＡＣＫパケットに対応する送信パケットの送信時刻であり、βは定数である。βは、パケット送信装置１１ａが計測可能な最小時間の整数倍や、パケット送信装置１１ａが１ＭＳＳの長さを持つＴＣＰパケットを１つ送信するために必要な時間の整数倍とすることができる。
【０１１３】
連続したパケットと判定した場合（ステップＳ８２：Ｙｅｓ）、式（１８）により当該ＡＣＫパケットに関するパケット間のジッタ（jitter）を計算する（ステップＳ８３）。rttlastは、前回受信したＡＣＫパケットで計測したrttである。
【０１１４】
jitter ＝ |rtt−rttlast|                                      （１８）
【０１１５】
jitterの計算後、式（１９）の処理を行い、１計測期間中の最大のjitterを表すjittermaxを更新する（ステップＳ８４）。
【０１１６】
if     jittermax ＜ jitter                                    （１９）
then   jittermax ＝ jitter
【０１１７】
一方、連続していないパケットと判定した場合（ステップＳ８２：Ｎｏ）や、１計測期間中の最大のjitterを表すjittermaxを更新しないとき（ステップＳ８４：Ｎｏ）、ステップＳ８６に移行する。
【０１１８】
そして、jittermaxの値を確定後、１計測期間が経過しているか判定し（ステップＳ８６）、１計測期間が経過している場合（ステップＳ８６：Ｙｅｓ）、jittermaxの値が０より大きいとして算出されていたときは（ステップＳ８９：Ｙｅｓ）、式（２０）により平均ジッタ（jitterave）を更新し（ステップＳ９０）、jittermaxの値を０にリセットする（ステップＳ９１）。jittermaxの値を０にリセットしたとき（ステップＳ９１）、及び、１計測期間が経過している場合でもjittermaxの値が０のときは（ステップＳ８９：Ｎｏ）、ステップＳ８７に移行する。jitteraveの初期値は０である。尚、αは１未満の重み付け定数であり、例えば０．５とするなど予め定めた値とすることができる。
【０１１９】
jitterave ＝ (１−α)×jitterave ＋α×jittermax              （２０）
【０１２０】
次に、今回のＡＣＫパケットの受信時に１計測期間が経過していないと判定した場合（ステップＳ８６：Ｎｏ）や、jittermaxの値を０にリセットしたとき（ステップＳ９１）、或いは１計測期間が経過していると判定した場合でもjittermaxの値が０のときは（ステップＳ８９：Ｎｏ）、rttlast, sndtimelastを式（２１）により更新する（ステップＳ８７）。
【０１２１】
rttlast ＝ rtt                                                 （２１）
sndtimelast ＝ sndtime
【０１２２】
jitteraveの値を確定後、遅延変動量推定部１１９３は、輻輳ウインドウ増加部１１９１へ通知する（ステップＳ８８）。
【０１２３】
次に、図１１を参照して、輻輳ウインドウ上限算出部１１９２による輻輳ウインドウ上限算出処理を説明する。
【０１２４】
輻輳ウインドウ上限算出部１１９２は、輻輳ウインドウ増加部１１９１からＡＣＫパケットと、rttbase，jitterave，sndtime，rcvtime，cwndmaxを受信すると（ステップＳ１０１）、輻輳ウインドウサイズの上限値cwndlimitを下記の手順で計算する。cwndlimitは、スロースタートフェーズ中に輻輳ウインドウサイズを増加させる場合の上限値であり、ＡＣＫパケットから受信レートを算出し計算を行う。cwndlimitの初期値は、事前に想定した予め定めた最大値（取りうる最大の値）とすることができる。尚、実施例２は、式（６）の処理を式（２２）に、式（７）の処理を式（２３）に、式（８）の処理を式（２４）に、式（９）の処理を式（２５）とする以外は、実施例１と同一の処理である。
【０１２５】
輻輳ウインドウサイズの上限値cwndlimitの算出動作は、ＡＣＫパケットを受信すると、まず、cwndmaxから求められる送信レートと、今回受信したＡＣＫパケットに対応する送信パケットの送信レートとの比較を行う（ステップＳ１０２）。
【０１２６】
今回受信したＡＣＫパケットに対応する送信パケットの送信レートが、cwndmaxから求められる送信レート以上であるときに（ステップＳ１０２：Ｙｅｓ）、続いて、今回受信したＡＣＫパケットが最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなすＡＣＫパケット群）に含まれるか否かの判定を行う（ステップＳ１０３）。これにより、無線ネットワークのような遅延変動が起きやすい環境でスロースタートフェーズ時に生じうる輻輳及びジッタによる遅延変動を有して受信するＡＣＫパケットが一連の送信パケットに対応するものとして扱うか否かを判定する。この判定には、以下の二例の判定方法が有効である。
【０１２７】
第１例の判定方法は、式（２２）により行う。尚、sndtimelast及びcwndmaxは、実施例１と同様である。
【０１２８】
if    sndtime−sndtimelast ≦(MSS／cwndmax)×(rttbase＋jitterave)  （２２）
then  最近時に受信したパケット群に含まれる。
else  最近時に受信したパケット群に含まれない。
【０１２９】
第２例の判定方法は、式（２３）により行う。尚、sndtimefirstは、実施例１と同様である。
【０１３０】
if   sndtime−sndtimefirst ≦
((rcvbyte＋送達確認バイト数)／cwndmax)×(rttbase＋jitterave)  （２３）
then  最近時に受信したパケット群に含まれる。
else  最近時に受信したパケット群に含まれない。
【０１３１】
今回受信したＡＣＫパケットに対応する送信パケットの送信レートが、cwndmaxから求められる送信レート以上でないとき（ステップＳ１０２：Ｎｏ）、及び、今回受信したＡＣＫパケットが最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなすＡＣＫパケット群）に含まれないと判定したとき（ステップＳ１０３：Ｎｏ）、最近時に受信したパケット群の記録から式（２４）により、その受信レートを満たす輻輳ウインドウサイズcwndestを算出する（ステップＳ１０５）。
【０１３２】
cwndest＝rcvbyte×(rttbase＋jitterave)／(rcvtimelast−rcvtimefirst)  （２４）
【０１３３】
また、１rtt以上に輻輳ウインドウサイズの算出に要する計測状態が継続することを防ぐことを意図して、１rtt未満で定期的に、輻輳ウインドウサイズの算出を行うようにするために、式（２５）に示すように、今回受信したＡＣＫパケットに対応する送信パケットに対して連続した送信の期間（sndtime - sndtimefirst）が所定の閾値（本例では、(rttbase＋jitterave)／２）を超える場合も、式（２４）による輻輳ウインドウサイズcwndestを算出するようにする。
【０１３４】
if    sndtime−sndtimefirst ＞ (rttbase＋jitterave) ／２            （２５）
then  式（２４）による輻輳ウインドウサイズの算出。
【０１３５】
cwndestを算出すると、式（１０）により１計測期間でのcwndestの最大値cwndlimit-tmpを更新する（ステップＳ１０６，Ｓ１０７）。
【０１３６】
更に、次に受信するＡＣＫパケットに関するステップＳ４４の判定や、輻輳ウインドウサイズの算出のために、式（１１）のように各変数をリセットする（ステップＳ１０８）。
【０１３７】
今回受信したＡＣＫパケットに対応する送信パケットの送信レートが、cwndmaxから求められる送信レート以上であり（ステップＳ１０２：Ｙｅｓ）、今回受信したＡＣＫパケットが最近時に受信したパケット群（即ち、一連の送信パケットに対応するものとしてみなすＡＣＫパケット群）に含まれると判定したとき（ステップＳ１０３：Ｙｅｓ）、即ち送信間隔に基づく判定で連続したパケット列とみなし、且つ連続したパケット列に関する送信パケットの所定の送信期間が予め定めた閾値を超えない場合、式（１２）により、当該連続したパケット列の受信バイト数を更新する（ステップＳ１０４）。
【０１３８】
次に、１計測期間を経過しているか否かを判定し（ステップＳ１０９）、１計測期間を経過していると判定したときは（ステップＳ１０９：Ｙｅｓ）、cwndlimit-tmpの更新が行われているか否かを判定する（ステップＳ１１０）。
【０１３９】
cwndlimit-tmpの更新が行われている場合に（ステップＳ１１０：Ｙｅｓ）、式（１３）によりcwndlimitを更新する（ステップＳ１１１）。
【０１４０】
今回受信したＡＣＫパケットが１計測期間を経過していないとき（ステップＳ１０９：Ｎｏ）、及び、cwndlimit-tmpの更新が行われていないとき（ステップＳ１１０：Ｎｏ）、cwndlimitは前回値のままである。
【０１４１】
ステップＳ１１０を経てcwndlimitの値が決定されると、式（１４）によりsndtimelast, rcvtimelastを更新する（ステップＳ１１２）。
【０１４２】
最後に、輻輳ウインドウ上限算出部１１９２は、cwndlimitを輻輳ウインドウ増加部１１９１へ通知する（ステップＳ１１３）。したがって、実施例２において、輻輳ウインドウ上限算出部１１９２は、輻輳とは無関係に生じるジッタをも考慮し、ステップＳ１０２及びステップＳ１０３の双方の判定を満たすときは当該最近時に受信したパケット群の受信バイト数に今回受信したＡＣＫパケットにより送達確認したバイト数を加えた受信バイト数を定め（ステップＳ１０４）、ステップＳ１０２及びステップＳ１０３のいずれか一方の判定を満たさないときには、該受信バイト数から求められる当該最近時に受信したパケット群の受信レートを基準にした輻輳ウインドウサイズ（cwndlimit-tmp）を算出して１計測期間毎に更新し、１計測期間毎に更新した該輻輳ウインドウサイズ（cwndlimit-tmp）を輻輳ウインドウサイズの上限値（cwndlimit）として決定する。そして、輻輳ウインドウ増加部１１９１は、ＡＣＫパケットを受信する度に１計測期間の経過時に決定されたcwndlimit以下で輻輳ウインドウサイズ（cwnd）を所定幅で拡大し、計測期間毎に、１計測期間の経過時に決定されたcwndlimitと当該拡大したcwndとを比較してスロースタートフェーズから輻輳回避フェーズへの遷移を判定する。
【０１４３】
このように、輻輳ウインドウ増加部１１９１、輻輳ウインドウ上限算出部１１９２及び遅延変動量推定部１１９３を備える実施例２のスロースタート動作部１１９ａを構成し、パケット送信装置１１ａに具備させることで、輻輳とは無関係に生じるジッタをも考慮してバースト的なパケットロスの発生を抑制し、これにより通信開始時のスロースタートフェーズにおける輻輳ウインドウサイズを拡大させる前の輻輳回避フェーズへの移行を効率よく抑制することができるので、高速な通信が可能となる。
【０１４４】
以上、特定の実施例を挙げて本発明を説明したが、本発明は前述の実施形態及び各実施例に限定されるものではなく、その技術思想を逸脱しない範囲で種々変形可能である。例えば、送達確認に基づく遅延量を用いてパケット送信に関するスロースタート制御を行うパケット送信装置であれば、如何なる態様の装置でもよい。
【産業上の利用可能性】
【０１４５】
本発明によれば、送達確認を行うパケット通信において、無線ネットワークのような遅延変動が起きやすい環境で通信開始時のスロースタートフェーズにおける通信効率を高めることができるので、送達確認に基づく遅延量を用いてパケット送信に関するスロースタート制御を行う用途に有用である。
【符号の説明】
【０１４６】
１０  通信端末
１１  従来技術に係るパケット送信装置
１１ａ  本発明による一実施形態のパケット送信装置
１２  パケット受信装置
２０  通信端末
２１  パケット受信装置
２２  パケット送信装置
１１１  送信時刻書込部
１１２  パケット送信部
１１３  送達確認応答受信部
１１４  パケットロス判定部
１１５  パケット送信制御部
１１６  ロス再送動作部
１１７  ロスリカバリ動作部
１１８  輻輳回避動作部
１１９  従来技術に係るスロースタート動作部
１１９ａ  本発明に係るスロースタート動作部
１１９１  輻輳ウインドウ増加部
１１９２  輻輳ウインドウ上限算出部
１１９３  遅延変動量推定部
【図１】
0006417225.tif 000002
【図２】
0006417225.tif 000003
【図３】
0006417225.tif 000004
【図４】
0006417225.tif 000005
【図５】
0006417225.tif 000006
【図６】
0006417225.tif 000007
【図７】
0006417225.tif 000008
【図８】
0006417225.tif 000009
【図９】
0006417225.tif 000010
【図１０】
0006417225.tif 000011
【図１１】
0006417225.tif 000012
【図１２】
0006417225.tif 000013
【図１３】
0006417225.tif 000014