(57)【要約】【課題】送達確認に基づく遅延量を用いてパケット送信に関する輻輳ウィンドウの制御を行うパケット送信装置、通信端末及び輻輳制御方法【解決手段】本発明のパケット送信装置１１ａは、パケット送信の送達確認に基づく往復遅延時間（ＲＴＴ）と、往復遅延時間（ＲＴＴ）について継続して計測した最小の往復遅延時間（ＲＴＴｂａｓｅ）について輻輳ウィンドウサイズを縮小する度にリセットした基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）とを保持し、当該往復遅延時間（ＲＴＴ）を算出する度に更新するＲＴＴ更新部１１５ａと、パケットロス発生時に、往復遅延時間（ＲＴＴ）及び基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を基に輻輳ウィンドウサイズを縮小するとともに、基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）をリセットさせるよう制御する輻輳ウィンドウ制御部１１６ａと、を備える。【選択図】図１
2015185857.tif 000002
【特許請求の範囲】
【請求項１】
送達確認に基づく遅延量を用いてパケット送信に関する輻輳ウィンドウの制御を行うパケット送信装置であって、
パケット送信の送達確認に基づく往復遅延時間（ＲＴＴ）と、前記往復遅延時間（ＲＴＴ）について継続して計測した最小の往復遅延時間（ＲＴＴｂａｓｅ）について輻輳ウィンドウサイズを縮小する度にリセットした基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）とを保持し、当該往復遅延時間（ＲＴＴ）を算出する度に更新するＲＴＴ更新手段と、
パケットロス発生時に、前記往復遅延時間（ＲＴＴ）及び前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を基に前記輻輳ウィンドウサイズを縮小するとともに、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）をリセットさせるよう制御する輻輳ウィンドウ制御手段と、
を備えることを特徴とするパケット送信装置。
【請求項２】
予め定めたパケット遅延量に関する計測期間内における当該往復遅延時間（ＲＴＴ）について直前の１計測期間内で計測した最小の値を計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）として計測して保持し、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）と前記計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）を用いてパケット送信に関する遅延増加の発生を検出する遅延増加判定手段を更に備え、
前記輻輳ウィンドウ制御手段は、
前記パケットロス発生と前記遅延増加の発生のうち少なくとも一方を判定した際に、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）及び前記計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）を基に前記輻輳ウィンドウサイズを縮小するとともに、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）及び前記計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）をリセットさせるよう制御する手段を有することを特徴とする、請求項１に記載のパケット送信装置。
【請求項３】
請求項１又は２に記載のパケット送信装置を備えることを特徴とする通信端末。
【請求項４】
送達確認に基づく遅延量を用いてパケット送信に関する輻輳ウィンドウの制御を行う輻輳制御方法であって、
パケット送信の送達確認に基づく往復遅延時間（ＲＴＴ）と、前記往復遅延時間（ＲＴＴ）について継続して計測した最小の往復遅延時間（ＲＴＴｂａｓｅ）について輻輳ウィンドウサイズを縮小する度にリセットした基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）とを保持し、当該往復遅延時間（ＲＴＴ）を算出する度に更新するステップと、
パケットロス発生時に、前記往復遅延時間（ＲＴＴ）及び前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を基に前記輻輳ウィンドウサイズを縮小するとともに、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）をリセットさせるよう制御するステップと、
を含むことを特徴とする輻輳制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信によってデータを伝送するパケット通信におけるパケット送信装置、通信端末及び輻輳制御方法に関する。
【背景技術】
【０００２】
品質の保証がされていないベストエフォートタイプのＩＰ（Internet Protocol）ネットワークでは、ネットワーク機器内部でのバッファ溢れや、伝送中のビットエラー等によって送信パケットの廃棄が発生する。そのため、確実にデータを伝送するための送達確認を行うプロトコルとしてＴＣＰ（Transmission Control Protocol）が幅広く利用されている（例えば、非特許文献１参照）。
【０００３】
例えば、図１１に示すように、ＴＣＰを利用して相互通信接続を行う通信端末１０，２０において、通信端末１０にはパケット送信装置１１及びパケット受信装置１２が設けられ、通信端末２０にはパケット受信装置２１及びパケット送信装置２２が設けられる。パケット送信装置１１及びパケット受信装置２１とパケット送信装置２２及びパケット受信装置１２はそれぞれ同様の機能を有し、代表してパケット送信装置１１及びパケット受信装置２１に注目して説明する。パケット送信装置１１は、データ送信用パケットを所定の通信路を介してパケット受信装置２１に送信すると、パケット受信装置２１は、受信した旨の報告として送達確認応答パケットをパケット送信装置１１に送信する。
【０００４】
より具体的には、ＴＣＰでは、パケット受信装置２１がパケットを受信すると、受信した旨の報告として、次に送信を要求するパケットの番号をパケット送信装置１１に通知する。そして、パケット送信装置１１は、パケット受信装置２１から通知される報告に基づいて、パケットが正常にパケット受信装置２１に到達したことを確認する。パケット送信装置１１は、パケット受信装置２１から通知される報告に基づいて、送達確認応答なしに送出可能なパケットの数を表す輻輳ウィンドウサイズ（ＣＷＮＤ:Congestion Window Size）を調整する。例えばパケットが正常に受信された場合はＣＷＮＤを拡大し、パケットロスが検出された場合はＣＷＮＤを縮小する。
【０００５】
このＣＷＮＤを調整する技法は輻輳制御技法と呼ばれ、通信の状態によってその制御技法が切り替えられる。一般的には通信開始時やタイムアウト後に適用される「スロースタートフェーズ」、通信が安定している際に適用される「輻輳回避フェーズ」、ロスパケットを再送するための「ロスリカバリフェーズ」といったフェーズに応じて輻輳制御技法が切り替える。
【０００６】
ＴＣＰ ＮｅｗＲｅｎｏは、輻輳回避フェーズでは送達確認応答を受信する度に、式（１）によりＣＷＮＤを拡大する（例えば、非特許文献２参照）。尚、ＭＳＳはパケットに含まれるデータの最大バイト数である。
【０００７】
CWND ＝ CWND ＋ MSS ／CWND                                   （１）
【０００８】
また、パケットロスが発生した場合には式（２）によりＣＷＮＤを縮小する。
【０００９】
CWND ＝ max（CWND_MIN, CWND／２）                            （２）
【００１０】
ＣＷＮＤ_ＭＩＮはＣＷＮＤが取りうる最小の値である。このように、パケットロスが発生するまでＣＷＮＤを拡大し続ける技法を一般に「ロスベース技法」と呼ぶ。
【００１１】
一方、ＴＣＰ Ｖｅｇａｓは、輻輳回避フェーズでは１往復遅延時間（ＲＴＴ:Round Trip Time）毎に、式（３）によりＣＷＮＤを更新する（例えば、非特許文献３参照）。
【００１２】
diff ＝ CWND／RTTbase − CWND／RTTmin                        （３）
if diff ＞ β        
then    CWND ＝ CWND − MSS
ssthresh ＝ min（CWND, ssthresh）
else if diff ＜ α
then    CWND ＝ CWND ＋ MSS
else
CWND ＝ CWNＤ
【００１３】
ここに、ＲＴＴｂａｓｅは通信を開始してから現時点までに計測した最小のＲＴＴ、ＲＴＴｍｉｎは予め定めたパケット遅延量に関する計測期間内におけるＲＴＴについて直前の１計測期間で計測した最小のＲＴＴである。また、α，βは、予め定めたパラメータである。さらに、ｓｓｔｈｒｅｓｈは、スロースタートフェーズにおけるＣＷＮＤの拡大・縮小を決めるのに用いるスロースタート閾値である。このようにＲＴＴを用いてＣＷＮＤを増減する技法を一般に「遅延ベース技法」と呼ぶ。
【００１４】
また、ＴＣＰ Ｗｅｓｔｗｏｏｄはロスベース技法と遅延ベース技法を組み合わせており、「ハイブリッド技法」と呼ばれる（例えば、非特許文献４参照）。ＴＣＰ Ｗｅｓｔｗｏｏｄは送達確認応答を受信すると、ＴＣＰ ＮｅｗＲｅｎｏと同じようにＣＷＮＤを拡大する。パケットロスが発生した場合には式（４）によりＣＷＮＤを縮小する。
【００１５】
ssthresh ＝ BWE × RTTbase                                 （４）
CWND ＝ min（CWND, ssthresh）
【００１６】
ＢＷＥは使用帯域であり、ＣＷＮＤ／ＲＴＴで計算される。パケットロス発生時にＣＷＮＤを縮小する点はロスベース技法と同様だが、その縮小量は遅延ベース技法のようにＲＴＴｂａｓｅを用いて決定する。
【００１７】
また、Ｖｅｇａｓのように遅延増加時にもＣＷＮＤを縮小させることができるが、その縮小幅をＷｅｓｔｗｏｏｄのように使用帯域とＲＴＴｂａｓｅを用いて決定する技法が開示されている（例えば、特許文献１参照）。
【００１８】
これらの従来技術を総括するに、ロスベース技法においてはパケットロス発生時にＣＷＮＤの縮小幅を制御するためにＲＴＴｂａｓｅを基準に用いるように構成することがあり 、一方、遅延ベース技法においては、ＲＴＴｂａｓｅを遅延増加判定の閾値に用いるように構成する。例えば、ロスベース技法における、そのパケット送信装置１１の概略構成を示すと、図１２のようになり、遅延ベース技法における、そのパケット送信装置１１の概略構成を示すと、図１３のようになる。図１２及び図１３では、同様な構成要素には同一の参照番号を付している。尚、図１２及び図１３に示すパケット送信装置１１は、後述する本発明との対比に係る機能ブロックのみを図示したものであり、送達確認を行うパケット通信方式のパケット送信装置としてその他の必要な機能は、従来から知られている既知の技術と同様の構成とすることができ、その詳細な説明は省略する。まず、図１２に示す従来技術に基づくパケット送信装置１１は、送信時刻書込部１１１、パケット送信部１１２、送達確認応答受信部１１３、パケットロス判定部１１４、ＲＴＴ更新部１１５及び輻輳ウィンドウ制御部１１６を備える。
【００１９】
送信時刻書込部１１１は、パケット送信時に送信時刻を記録する。この送信時刻は、パケット送信装置１１の本体内メモリ（図示せず）にパケット番号とともに記録することができる。或いは、ＴＣＰのタイムスタンプオプションを用いて記録することもできる。
【００２０】
パケット送信部１１２は、パケット受信装置２１に向けてパケットを送信する。その後、送達確認応答受信部１１３は、パケット受信装置２１から通知される送達確認応答パケットを受信すると、次の処理を開始する。
【００２１】
送達確認応答受信部１１３は、送達確認応答パケットを受信すると、パケット送信部１１２からのパケット送信から送達確認応答パケットを受信するまでにかかったＲＴＴを計算する。ＲＴＴの計算は、本体内メモリに記録した送信時刻と受信時刻の差とすることができる。或いは、ＴＣＰタイムスタンプオプションを用いることができる。ＲＴＴの計算後、送達確認応答受信部１１３は、パケットロス判定部１１４へ送達確認応答パケットを、ＲＴＴ更新部１１５へ送達確認応答パケット及びＲＴＴを通知する。
【００２２】
パケットロス判定部１１４は、送達確認応答受信部１１３から送達確認応答パケットを受信すると、パケットロスが発生しているか否かの判定を行う。パケットロスの判定には、例えば送達確認応答パケットに含まれる送達確認番号が同じパケットを３回受信した場合とする方法がある。その後、輻輳ウィンドウ制御部１１６へ判定結果を通知する。
【００２３】
ＲＴＴ更新部１１５は、送達確認応答受信部１１３から送達確認応答パケット及びＲＴＴを受信すると、ＲＴＴｂａｓｅを式（５）により更新する。
【００２４】
RTTbase ＝ min (RTT, RTTbase)                                 （５）
【００２５】
その後、輻輳ウィンドウ制御部１１６へＲＴＴとＲＴＴｂａｓｅを通知する。
【００２６】
輻輳ウィンドウ制御部１１６は、パケットロス判定部１１６から判定結果を受信し、更にＲＴＴ更新部１１５からＲＴＴ及びＲＴＴｂａｓｅを受信し、パケットロスが発生していた場合、式（１）〜（４）のいずれかによりＣＷＮＤを更新し、パケット送信部１１２におけるパケット送信の輻輳ウィンドウを制御する。
【００２７】
また、図１３に示す従来技術に基づくパケット送信装置１１では、図１２に示すパケット送信装置１１に対して、更に、遅延増加判定部１１７が設けられる。この遅延増加判定部１１７は、ＲＴＴ更新部１１５から受信したＲＴＴｂａｓｅを遅延増加判定の閾値に用いてパケット遅延量を判別し、ＲＴＴ及び送達確認応答パケットを基にＲＴＴｍｉｎを更新して、パケット遅延量の判定結果とＲＴＴｍｉｎを輻輳ウィンドウ制御部１１６に出力する。このようにして、図１３に示す従来技術に基づくパケット送信装置１１では、遅延ベースの輻輳制御を行う。
【先行技術文献】
【特許文献】
【００２８】
【特許文献１】特許第４６３２８７４号明細書
【非特許文献】
【００２９】
【非特許文献１】“RFC793 Transmission Control Protocol”、［online］、昭和56（西暦1981）年9月策定、DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION、［平成26年2月24日検索］、インターネット〈URL：http://www.rfc-base.org/txt/rfc-793.txt〉
【非特許文献２】“RFC6582  The NewReno Modification to TCP’s Fast Recovery Algorithm”、［online］、平成24（西暦2012）年4月策定、Internet Engineering Task Force (IETF)、［平成26年2月24日検索］、インターネット〈URL：https://tools.ietf.org/html/rfc6582〉
【非特許文献３】Lawrence S. Brakmo, Larry L. Peterson，“TCP Vegas: End to End Congestion Avoidance on a Global Internet,” Selected Areas in Communications, IEEE Journal on Volume:13 ,  Issue: 8，  pp.1465-1480, Oct. 1995,［平成26年2月24日検索］、インターネット〈URL：http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=464716&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D464716〉
【非特許文献４】M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti and S. Mascolo, “TCP Westwood: congestion window control using bandwidth estimation,” IEEE Global Telecommunications Conference 2001, vol.3 pp.1698-1702, 2001,［平成26年2月24日検索］、インターネット〈URL：http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=965869&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D965869〉
【発明の概要】
【発明が解決しようとする課題】
【００３０】
ロスベース技法はパケットロスが発生するまでＣＷＮＤを拡大するため、必ずロスが発生する。一方、遅延ベース技法は遅延の増加を検出した時点でＣＷＮＤを縮小するため、パケットロスの発生を防ぐことが可能である。しかし、回線を共有するフロー間での使用帯域の公平性について問題があった。
【００３１】
例えば、或る回線にまずＩＰデータフロー１（Ｆ１）が発生したとする。Ｆ１はこの回線を使い切り、遅延が増加するまでＣＷＮＤを拡大する。そして、遅延が少し増加したところでＣＷＮＤの拡大を止める。Ｆ１のＲＴＴｂａｓｅ（Ｆ１_ＲＴＴｂａｓｅ）は回線が空いた状態で計測したＲＴＴとなる。
【００３２】
次に、ＩＰデータフロー２（Ｆ２）が発生したとする。Ｆ２は既にＦ１により遅延が増加した状態の回線にパケットを送信するため、Ｆ２のＲＴＴｂａｓｅ（Ｆ２_ＲＴＴｂａｓｅ）はＦ１_ＲＴＴｂａｓｅよりも大きい値となる。従って、Ｆ１とＦ２で同じＲＴＴｍｉｎを計測したとしてもＦ１が先にＣＷＮＤを縮小するスレッショルドを超えるため、Ｆ１ばかりがＣＷＮＤを縮小することとなり、使用帯域に不公平が生ずる。
【００３３】
ＴＣＰ Ｗｅｓｔｗｏｏｄの場合も同様に、ＲＴＴｂａｓｅを基にＣＷＮＤを計算するため、上記のようにＲＴＴｂａｓｅの値に不公平が生ずると、使用帯域にも不公平が生ずる。
【００３４】
特許文献１の技法も同様に、ＲＴＴｂａｓｅを用いた遅延増加判定とＣＷＮＤの更新を行うため、ＲＴＴｂａｓｅの値に不公平が生ずると使用帯域にも不公平が生ずる。
【００３５】
本発明は、上述の問題を鑑みて為されたものであり、本発明の目的は、送達確認を行うパケット通信方式において、遅延を指標とした輻輳制御を行う際に、回線を共有するフロー間の使用帯域の公平性を改善するパケット送信装置、通信端末及び輻輳制御方法を提供することにある。
【課題を解決するための手段】
【００３６】
本発明によるパケット送信装置を備える通信端末は、ＲＴＴｂａｓｅの値についてＣＷＮＤを縮小する度にリセットした新たな基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を用いてＣＷＮＤを更新するように構成し、これにより複数のＩＰデータフローの各々が同じＲＴＴｂａｓｅ_ｔｍｐを使用可能にして、複数のＩＰデータフローの使用帯域の公平性を改善する。
【００３７】
即ち、本発明のパケット送信装置は、送達確認に基づく遅延量を用いてパケット送信に関する輻輳ウィンドウの制御を行うパケット送信装置であって、パケット送信の送達確認に基づく往復遅延時間（ＲＴＴ）と、前記往復遅延時間（ＲＴＴ）について継続して計測した最小の往復遅延時間（ＲＴＴｂａｓｅ）について輻輳ウィンドウサイズを縮小する度にリセットした基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）とを保持し、当該往復遅延時間（ＲＴＴ）を算出する度に更新するＲＴＴ更新手段と、パケットロス発生時に、前記往復遅延時間（ＲＴＴ）及び前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を基に前記輻輳ウィンドウサイズを縮小するとともに、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）をリセットさせるよう制御する輻輳ウィンドウ制御手段と、を備えることを特徴とする。
【００３８】
また、本発明のパケット送信装置において、予め定めたパケット遅延量に関する計測期間内における当該往復遅延時間（ＲＴＴ）について直前の１計測期間内で計測した最小の値を計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）として計測して保持し、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）と前記計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）を用いてパケット送信に関する遅延増加の発生を検出する遅延増加判定手段を更に備え、前記輻輳ウィンドウ制御手段は、前記パケットロス発生と前記遅延増加の発生のうち少なくとも一方を判定した際に、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）及び前記計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）を基に前記輻輳ウィンドウサイズを縮小するとともに、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）及び前記計測期間内最小の往復遅延時間（ＲＴＴｍｉｎ）をリセットさせるよう制御する手段を有することを特徴とする。
【００３９】
また、本発明の通信端末は、本発明のパケット送信装置を備えることを特徴とする。
【００４０】
また、本発明の輻輳制御方法は、送達確認に基づく遅延量を用いてパケット送信に関する輻輳ウィンドウの制御を行う輻輳制御方法であって、パケット送信の送達確認に基づく往復遅延時間（ＲＴＴ）と、前記往復遅延時間（ＲＴＴ）について継続して計測した最小の往復遅延時間（ＲＴＴｂａｓｅ）について輻輳ウィンドウサイズを縮小する度にリセットした基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）とを保持し、当該往復遅延時間（ＲＴＴ）を算出する度に更新するステップと、パケットロス発生時に、前記往復遅延時間（ＲＴＴ）及び前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を基に前記輻輳ウィンドウサイズを縮小するとともに、前記基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）をリセットさせるよう制御するステップと、を含むことを特徴とする。
【発明の効果】
【００４１】
本発明によれば、遅延量を用いてＣＷＮＤの増減の判定や更新を行う輻輳制御技法にて、ＲＴＴｂａｓｅの値についてＣＷＮＤを縮小する度にリセットした新たな基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を用いてＣＷＮＤを更新するように構成したので、複数のＩＰデータフローの各々が同じＲＴＴｂａｓｅ_ｔｍｐを使用可能にして、複数のＩＰデータフローの使用帯域の公平性を改善することができる。
【図面の簡単な説明】
【００４２】
【図１】本発明による第１実施形態のパケット送信装置におけるブロック図である。
【図２】本発明による第１実施形態のパケット送信装置における送達確認応答受信部の処理を示すフローチャートである。
【図３】本発明による第１実施形態のパケット送信装置におけるパケットロス判定処理部の処理を示すフローチャートである。
【図４】本発明による第１実施形態のパケット送信装置におけるＲＴＴ更新部の処理を示すフローチャートである。
【図５】本発明による第１実施形態のパケット送信装置における輻輳ウィンドウ制御部の処理を示すフローチャートである。
【図６】本発明による第２実施形態のパケット送信装置におけるブロック図である。
【図７】本発明による第２実施形態のパケット送信装置におけるＲＴＴ更新部の処理を示すフローチャートである。
【図８】（Ａ），（Ｂ）は、本発明による第２実施形態のパケット送信装置に係るパケット遅延量に関する計測期間の説明図である。
【図９】本発明による第２実施形態のパケット送信装置における遅延増加判定部の処理を示すフローチャートである。
【図１０】本発明による第２実施形態のパケット送信装置における輻輳ウィンドウ制御部の処理を示すフローチャートである。
【図１１】ＴＣＰを利用して相互通信接続を行う通信端末のネットワーク接続例を説明する図である。
【図１２】従来技術に基づくロスベース技法のパケット送信装置におけるブロック図である。
【図１３】従来技術に基づく遅延ベース技法のパケット送信装置におけるブロック図である。
【発明を実施するための形態】
【００４３】
以下、図面を参照して、本発明による各実施形態のパケット送信装置、通信端末及び輻輳制御方法を説明する。
【００４４】
〔第１実施形態〕
図１は、本発明による第１実施形態のパケット送信装置１１ａにおけるブロック図である。
【００４５】
パケット送信装置１１ａは、図１２に示すパケット送信装置１１に置き換えて、図１１に示す通信端末１０に設ける装置である。同様に、通信端末２０に対しても、パケット送信装置２２に置き換えてパケット送信装置１１ａと同様の構成を設けることができる。したがって、図１１に示すように、ＴＣＰを利用して相互通信接続を行う通信端末１０，２０において、パケット送信装置１１ａは、データ送信用パケットを所定の通信路を介してパケット受信装置２１に送信すると、パケット受信装置２１は、受信した旨の報告として送達確認応答パケットをパケット送信装置１１ａに送信する。尚、図１に示すパケット送信装置１１ａは、本発明に係る機能ブロックのみを図示したものであり、送達確認を行うパケット通信方式のパケット送信装置としてその他の必要な機能は、従来から知られている既知の技術と同様の構成とすることができ、その詳細な説明は省略する。
【００４６】
図１に示すように、本実施形態のパケット送信装置１１ａは、送信時刻書込部１１１、パケット送信部１１２、送達確認応答受信部１１３、パケットロス判定部１１４、ＲＴＴ更新部１１５ａ及び輻輳ウィンドウ制御部１１６ａを備える。尚、図１２に示すパケット送信装置１１と比較して、本実施形態のパケット送信装置１１ａは、ＲＴＴ更新部１１５及び輻輳ウィンドウ制御部１１６の代わりに、ＲＴＴ更新部１１５ａ及び輻輳ウィンドウ制御部１１６ａを備える点で相違しており、同様な構成要素には同一の参照番号を付している。
【００４７】
送信時刻書込部１１１は、パケット送信時に送信時刻を記録する。この送信時刻は、パケット送信装置１１の本体内メモリ（図示せず）にパケット番号とともに記録することができる。或いは、ＴＣＰのタイムスタンプオプションを用いて記録することもできる。
【００４８】
パケット送信部１１２は、パケット受信装置２１に向けてパケットを送信する。その後、送達確認応答受信部１１３は、パケット受信装置２１から通知される送達確認応答パケットを受信すると、次の処理を開始する。
【００４９】
送達確認応答受信部１１３は、送達確認応答パケットを受信すると、パケット送信部１１２からのパケット送信から送達確認応答パケットを受信するまでにかかったＲＴＴを計算する。ＲＴＴの計算は、本体内メモリに記録した送信時刻と受信時刻の差とすることができる。或いは、ＴＣＰタイムスタンプオプションを用いることができる。より具体的には、図２に示すように、送達確認応答受信部１１３は、送達確認応答パケットを受信すると（ステップＳ１１）、送信時刻と受信時刻の差からＲＴＴを求め（ステップＳ１２）、ＲＴＴの計算後、パケットロス判定部１１４へ送達確認応答パケットを通知するとともに（ステップＳ１３）、ＲＴＴ更新部１１５ａへ送達確認応答パケット及びＲＴＴを通知する（ステップＳ１４）。
【００５０】
パケットロス判定部１１４は、送達確認応答受信部１１３から送達確認応答パケットを受信すると、パケットロスが発生しているか否かの判定を行う。より具体的には、図３に示すように、パケットロス判定部１１４は、送達確認応答受信部１１３から送達確認応答パケットを受信すると（ステップＳ２１）、輻輳ウィンドウ制御部１１６ａへ判定結果を通知する（ステップＳ２２）。パケットロスの判定には、例えば送達確認応答パケットに含まれる送達確認番号が同じパケットを３回受信した場合とする方法がある。
【００５１】
ＲＴＴ更新部１１５ａは、ＲＴＴｂａｓｅの値についてＣＷＮＤを縮小する度にリセットした新たな基準の往復遅延時間（ＲＴＴｂａｓｅ_ｔｍｐ）を用い、送達確認応答受信部１１３から受信した送達確認応答パケット及びＲＴＴを基にＲＴＴｂａｓｅ_ｔｍｐを更新するか、又は輻輳ウィンドウ制御部１１６ａから受信したＣＷＮＤをリセットする旨を示すＲＴＴリセット情報を基にＲＴＴｂａｓｅ_ｔｍｐを更新する。より具体的には、図４に示すように、ＲＴＴ更新部１１５ａは、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無を監視しており（ステップＳ３１）、送達確認応答受信部１１３から送達確認応答パケット及びＲＴＴを受信すると（ステップＳ３１：Ｙｅｓ）、ＲＴＴｂａｓｅ_ｔｍｐを式（６）により更新する（ステップＳ３２）。尚、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信が無い間（ステップＳ３１：Ｎｏ）、輻輳ウィンドウ制御部１１６ａからのＲＴＴリセット情報の受信の有無を監視するためステップＳ３４に移行する。
【００５２】
RTTbase_tmp ＝ min（RTT, RTTbase_tmp）                      （６）
【００５３】
送達確認応答パケット及びＲＴＴの受信時のＲＴＴｂａｓｅ_ｔｍｐの更新後、ＲＴＴ更新部１１５ａは、輻輳ウィンドウ制御部１１６ａへＲＴＴとＲＴＴｂａｓｅ_ｔｍｐを通知する（ステップＳ３３）。
【００５４】
また、ＲＴＴ更新部１１５ａは、輻輳ウィンドウ制御部１１６ａからのＲＴＴリセット情報の受信の有無を監視しており（ステップＳ３４）、輻輳ウィンドウ制御部１１６ａからＣＷＮＤをリセットする旨を示すＲＴＴリセット情報を受信すると（ステップＳ３４：Ｙｅｓ）、ＲＴＴｂａｓｅ_ｔｍｐを式（７）により更新する（ステップＳ３５）。尚、輻輳ウィンドウ制御部１１６ａからのＲＴＴリセット情報の受信が無い間（ステップＳ３４：Ｎｏ）、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無を監視するためステップＳ３６に移行する。
【００５５】
RTTbase_tmp ＝ max（RTT, RTTbase_tmp）                      （７）
【００５６】
そして、ＲＴＴ更新部１１５ａは、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の待機状態に入り（ステップＳ３６）、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無、及び、輻輳ウィンドウ制御部１１６ａからのＲＴＴリセット情報の受信の有無を監視する（ステップＳ３１，Ｓ３４）。尚、図４では、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無の監視、及び、輻輳ウィンドウ制御部１１６ａからのＲＴＴリセット情報の受信の有無の監視について経時的に行う例を説明したが、常時、双方の監視を行うように構成することができる。
【００５７】
輻輳ウィンドウ制御部１１６ａは、パケットロス判定部１１４の判定結果と、ＲＴＴ更新部１１５ａからのＲＴＴ及びＲＴＴｂａｓｅ_ｔｍｐに応じて、ＣＷＮＤを更新する。より具体的には、図５に示すように、輻輳ウィンドウ制御部１１６ａは、パケットロス判定部１１４から判定結果を受信し（ステップＳ４１）、更にＲＴＴ更新部１１５ａからＲＴＴとＲＴＴｂａｓｅ_ｔｍｐを受信する（ステップＳ４２）。
【００５８】
パケットロス判定部１１４の判定結果によりパケットロスが発生していた場合（ステップＳ４３：Ｙｅｓ）、輻輳ウィンドウ制御部１１６ａは、式（８）によりｓｓｔｈｒｅｓｈとＣＷＮＤを更新する（ステップＳ４５）。
【００５９】
ssthresh ＝ CWND × RTTbase_tmp ／RTT                      （８）
CWND ＝ min（CWND, ssthresh）
【００６０】
その後、輻輳ウィンドウ制御部１１６ａは、ＲＴＴ更新部１１５ａへＲＴＴリセット情報を通知する（ステップＳ４６）。
【００６１】
一方、パケットロス判定部１１４の判定結果によりパケットロスが発生していなかった場合には（ステップＳ４３：Ｎｏ）、式（９）によりＣＷＮＤを拡大する（ステップＳ４４）。
【００６２】
CWND ＝ CWND ＋ MSS／CWND                                 （９）
【００６３】
このように、輻輳制御技法において、パケットロス発生時に送達確認に基づく新たな基準の遅延量を示すＲＴＴｂａｓｅ_ｔｍｐを用いてＣＷＮＤを更新するように構成したことで、複数のＩＰデータフローの各々の間の使用帯域の公平性を改善することができる。
【００６４】
〔第２実施形態〕
図６は、本発明による第２実施形態のパケット送信装置１１ｂにおけるブロック図である。
【００６５】
パケット送信装置１１ｂは、図１２１３に示すパケット送信装置１１に置き換えて、図１１に示す通信端末１０に設ける装置である。同様に、通信端末２０に対しても、パケット送信装置２２に置き換えてパケット送信装置１１ｂと同様の構成を設けることができる。したがって、図１１に示すように、ＴＣＰを利用して相互通信接続を行う通信端末１０，２０において、パケット送信装置１１ｂは、データ送信用パケットを所定の通信路を介してパケット受信装置２１に送信すると、パケット受信装置２１は、受信した旨の報告として送達確認応答パケットをパケット送信装置１１ｂに送信する。尚、図６に示すパケット送信装置１１ｂは、本発明に係る機能ブロックのみを図示したものであり、送達確認を行うパケット通信方式のパケット送信装置としてその他の必要な機能は、従来から知られている既知の技術と同様の構成とすることができ、その詳細な説明は省略する。
【００６６】
図６に示すように、本実施形態のパケット送信装置１１ｂは、送信時刻書込部１１１、パケット送信部１１２、送達確認応答受信部１１３、パケットロス判定部１１４、ＲＴＴ更新部１１５ｂ、輻輳ウィンドウ制御部１１６ｂ及び遅延増加判定部１１７ｂを備える。尚、図１３に示すパケット送信装置１１と比較して、本実施形態のパケット送信装置１１ｂは、ＲＴＴ更新部１１５、輻輳ウィンドウ制御部１１６及び遅延増加判定部１１７の代わりに、ＲＴＴ更新部１１５ｂ、輻輳ウィンドウ制御部１１６ｂ及び遅延増加判定部１１７ｂを備える点で相違しており、同様な構成要素には同一の参照番号を付している。
【００６７】
また、本実施形態のパケット送信装置１１ｂは、第１実施形態のパケット送信装置１１ａと比較して、新たな構成の遅延増加判定部１１７ｂを追加し、遅延増加が発生した場合にもＣＷＮＤを縮小し、パケットロス発生時に送達確認に基づく新たな基準の遅延量を示すＲＴＴｂａｓｅ_ｔｍｐを用いてＣＷＮＤを更新するように遅延ベース技法に基づく構成とした例である。
【００６８】
送信時刻書込部１１１、パケット送信部１１２、送達確認応答受信部１１３、パケットロス判定部１１４の動作は第１実施形態と同様であり、更なる詳細な説明は省略する。
【００６９】
ＲＴＴ更新部１１５ｂは、第１実施形態と同様に、送達確認応答受信部１１３から受信した送達確認応答パケット及びＲＴＴを基にＲＴＴｂａｓｅ_ｔｍｐを更新するか、又は輻輳ウィンドウ制御部１１６ｂから受信したＣＷＮＤをリセットする旨を示すＲＴＴリセット情報を基にＲＴＴｂａｓｅ_ｔｍｐを更新する機能を有するが、遅延増加判定部１１７ｂに対してもＲＴＴ、ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットを通知するように構成される。より具体的には、図７に示すように、ＲＴＴ更新部１１５ｂは、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無を監視しており（ステップＳ５１）、送達確認応答受信部１１３から送達確認応答パケット及びＲＴＴを受信すると（ステップＳ５１：Ｙｅｓ）、ＲＴＴｂａｓｅ_ｔｍｐを式（６）により更新する（ステップＳ５２）。尚、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信が無い間（ステップＳ５１：Ｎｏ）、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無を監視するためステップＳ５５に移行する。
【００７０】
送達確認応答パケット及びＲＴＴの受信時のＲＴＴｂａｓｅ_ｔｍｐの更新後、ＲＴＴ更新部１１５ｂは、輻輳ウィンドウ制御部１１６ｂへＲＴＴとＲＴＴｂａｓｅ_ｔｍｐを通知するとともに（ステップＳ５３）、遅延増加判定部１１７ｂへＲＴＴ、ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットを通知する（ステップＳ５４）。
【００７１】
また、ＲＴＴ更新部１１５ｂは、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無を監視しており（ステップＳ５５）、輻輳ウィンドウ制御部１１６ｂからＣＷＮＤをリセットする旨を示すＲＴＴリセット情報を受信すると（ステップＳ５５：Ｙｅｓ）、ＲＴＴｂａｓｅ_ｔｍｐを式（７）により更新する（ステップＳ５６）。尚、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信が無い間（ステップＳ５５：Ｎｏ）、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無を監視するためステップＳ５７に移行する。
【００７２】
そして、ＲＴＴ更新部１１５ｂは、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の待機状態に入り（ステップＳ５７）、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無、及び、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無を監視する（ステップＳ５１，Ｓ５５）。尚、図７では、送達確認応答受信部１１３からの送達確認応答パケット及びＲＴＴの受信の有無の監視、及び、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無の監視について経時的に行う例を説明したが、常時、双方の監視を行うように構成することができる。
【００７３】
遅延増加判定部１１７ｂは、ＲＴＴ更新部１１５ｂから受信したＲＴＴ，ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットを基に、予め定めたパケット遅延量に関する計測期間における計測開始から１計測期間が経過したか否かを判定する。
【００７４】
例えば、図８（Ａ）に示すように、通信端末１０が連続的に送信するデータ送信用パケットＤ１，Ｄ２，Ｄ３を通信端末２０に向けて送信するとともに、データ送信用パケットＤ１，Ｄ２，Ｄ３の各々に対応する送達確認応答パケットＡＣＫ１，ＡＣＫ２，ＡＣＫ３を受信する場合を考えたとき、１計測期間は、計測期間の計測の開始から通信端末１０（パケット送信装置１１ｂ）が最初に送信するパケットに対する送達確認応答（ＡＣＫ）が到着するまで、とすることができる。
【００７５】
或いは、図８（Ｂ）に示すように、１計測期間は、計測期間の計測の開始から所定時間（例えば、直前の計測期間における最小のＲＴＴ（ＲＴＴｍｉｎ）経過時まで、とすることができる。尚、計測期間は、ＩＰデータフローに対して連続的に定めてもよいし、間欠的に定めてもよく、計測期間で求めたＲＴＴｍｉｎは少なくとも次回の計測期間でＲＴＴｍｉｎを求めるまで保持するように構成し、ＲＴＴｍｉｎを用いるＣＷＮＤ等の更新にはその更新時点で保持するＲＴＴｍｉｎを用いるようにする。
【００７６】
より具体的には、図９に示すように、遅延増加判定部１１７ｂは、ＲＴＴ更新部１１５ｂからのＲＴＴ，ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットの受信の有無を監視しており（ステップＳ６１）、ＲＴＴ更新部１１５ｂからＲＴＴ，ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットを受信すると（ステップＳ６１：Ｙｅｓ）、１計測期間が経過していた場合（ステップＳ６２：Ｙｅｓ）、式（１０）により遅延が増加しているか否かの判定を行う（ステップＳ６５，Ｓ６６）。尚、ＲＴＴｍｉｎは、１計測期間内で計測した最小のＲＴＴである。
【００７７】
diff ＝ CWND／RTTbase_tmp − CWND／RTTmin                   （１０）
if diff ＞ 閾値
then    遅延増加発生と判定
else    遅延増加未発生と判定
【００７８】
続いて、遅延増加判定部１１７ｂは、遅延増加と判定した場合（ステップＳ６６：Ｙｅｓ）、輻輳ウィンドウ制御部１１６ｂへＲＴＴｍｉｎと遅延増加発生を通知する（ステップＳ６８）。遅延増加未発生と判定した場合（ステップＳ６６：Ｎｏ）、輻輳ウィンドウ制御部へＲＴＴｍｉｎと遅延増加未発生を通知する（ステップＳ６７）。その後、遅延増加判定部１１７ｂは、ＲＴＴｍｉｎをＲＴＴに更新し（ステップＳ６９）、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無を監視するためステップＳ７０に移行する。
【００７９】
一方、遅延増加判定部１１７ｂは、ＲＴＴ更新部１１５ｂからＲＴＴ，ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットを受信し（ステップＳ６１：Ｙｅｓ）、１計測期間が経過していない場合（ステップＳ６２：Ｎｏ）、式（１１）によりＲＴＴｍｉｎを更新する（ステップＳ６３）。
【００８０】
RTTmin ＝ min（RTT, RTTmin）                               （１１）
【００８１】
続いて、遅延増加判定部１１７ｂは、輻輳ウィンドウ制御部１１６ｂへＲＴＴｍｉｎと遅延増加未発生の旨を通知し（ステップＳ６４）、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無を監視するためステップＳ７０に移行する。
【００８２】
また、遅延増加判定部１１７ｂは、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無を監視しており（ステップＳ７０）、輻輳ウィンドウ制御部１１６ｂからＣＷＮＤをリセットする旨を示すＲＴＴリセット情報を受信すると（ステップＳ７０：Ｙｅｓ）、ＲＴＴｍｉｎを式（１２）により更新する（ステップＳ７１）。尚、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信が無い間（ステップＳ７０：Ｎｏ）、ＲＴＴ更新部１１５ｂからのＲＴＴ、ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットの受信の有無を監視するためステップＳ７２に移行する。
【００８３】
RTTmin ＝ max（RTT, RTTmin）                              （１２）
【００８４】
そして、遅延増加判定部１１７ｂは、ＲＴＴ更新部１１５ｂからのＲＴＴ，ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットの受信の待機状態に入り（ステップＳ７２）、ＲＴＴ更新部１１５ｂからのＲＴＴ，ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットの受信の有無、及び、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無を監視する（ステップＳ６１，Ｓ７０）。尚、図９では、ＲＴＴ更新部１１５ｂからのＲＴＴ，ＲＴＴｂａｓｅ_ｔｍｐ及び送達確認応答パケットの受信の有無の監視、及び、輻輳ウィンドウ制御部１１６ｂからのＲＴＴリセット情報の受信の有無の監視について経時的に行う例を説明したが、常時、双方の監視を行うように構成することができる。
【００８５】
輻輳ウィンドウ制御部１１６ｂは、パケットロス判定部１１４の判定結果と、遅延増加判定部１１７ｂからのＲＴＴｍｉｎ及び判定結果と、ＲＴＴ更新部１１５ｂからのＲＴＴ及びＲＴＴｂａｓｅ_ｔｍｐに応じて、ＣＷＮＤを更新する。より具体的には、図１０に示すように、まず、輻輳ウィンドウ制御部１１６ｂは、パケットロス判定部１１４から判定結果を受信し（ステップＳ８１）、遅延増加判定部１１７ｂからＲＴＴｍｉｎ及び判定結果を受信し（ステップＳ８２）、更にＲＴＴ更新部１１５ａｂからＲＴＴとＲＴＴｂａｓｅ_ｔｍｐを受信する（ステップＳ８３）。
【００８６】
パケットロス判定部１１４の判定結果によりパケットロスが発生していた場合、或いは遅延増加判定部１１７ｂの判定結果により遅延増加が発生していた場合（ステップＳ８４：Ｙｅｓ）、輻輳ウィンドウ制御部１１６ｂは、式（１３）によりｓｓｔｈｒｅｓｈとＣＷＮＤを更新する（ステップＳ８６）。
【００８７】
ssthresh ＝ CWND × RTTbase_tmp ／RTTmin                   （１３）
CWND ＝ min（CWND, ssthresh）
【００８８】
その後、輻輳ウィンドウ制御部１１６ｂは、ＲＴＴ更新部１１５ｂ及び遅延増加判定部１１７ｂへＲＴＴリセット情報を通知する（ステップＳ８７）。
【００８９】
一方、パケットロス判定部１１４の判定結果によりパケットロスが発生していない場合、且つ遅延増加判定部１１７ｂの判定結果により遅延増加が発生していない場合（ステップＳ８４：Ｎｏ）、輻輳ウィンドウ制御部１１６ｂは、式（９）によりＣＷＮＤを拡大する（ステップＳ８５）。
【００９０】
このように、遅延ベース技法においても、送達確認に基づく新たな基準の遅延量を示すＲＴＴｂａｓｅ_ｔｍｐと遅延増加の判定を用いてＣＷＮＤを更新するように構成することで、複数のＩＰデータフローの各々の間の使用帯域の公平性を改善することができる。
【００９１】
以上、特定の実施例を挙げて本発明を説明したが、本発明は前述の各実施形態の例に限定されるものではなく、その技術思想を逸脱しない範囲で種々変形可能である。例えば、送達確認に基づく遅延量を用いてパケット送信に関する輻輳ウィンドウの制御を行うパケット送信装置であれば、如何なる態様の装置でもよい。
【産業上の利用可能性】
【００９２】
本発明によれば、複数のＩＰデータフローの使用帯域の公平性を改善することができるので、送達確認に基づく遅延量を用いてパケット送信に関する輻輳ウィンドウの制御を行う用途に有用である。
【符号の説明】
【００９３】
１０  通信端末
１１  従来技術に係るパケット送信装置
１１ａ，１１ｂ  本発明による一実施形態のパケット送信装置
１２  パケット受信装置
２０  通信端末
２１  パケット受信装置
２２  パケット送信装置
１１１  送信時刻書込部
１１２  パケット送信部
１１３  送達確認応答受信部
１１４  パケットロス判定部
１１５，１１５ａ，１１６ｂ  ＲＴＴ更新部
１１６，１１６ａ，１１６ｂ  輻輳ウィンドウ制御部
１１７，１１７ｂ  遅延増加判定部
【図１】
2015185857.tif 000003
【図２】
2015185857.tif 000004
【図３】
2015185857.tif 000005
【図４】
2015185857.tif 000006
【図５】
2015185857.tif 000007
【図６】
2015185857.tif 000008
【図７】
2015185857.tif 000009
【図８】
2015185857.tif 000010
【図９】
2015185857.tif 000011
【図１０】
2015185857.tif 000012
【図１１】
2015185857.tif 000013
【図１２】
2015185857.tif 000014
【図１３】
2015185857.tif 000015