特許 6051939 帯域測定装置及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6051939

(24)【登録日】2016年12月9日

(45)【発行日】2016年12月27日

(54)【発明の名称】帯域測定装置及びプログラム

(51)【国際特許分類】

   H04L 12/807 20130101AFI20161219BHJP

【ＦＩ】

   H04L12/807

【請求項の数】10

【全頁数】20

(21)【出願番号】特願2013-37061(P2013-37061)

(22)【出願日】2013年2月27日

(65)【公開番号】特開2014-165809(P2014-165809A)

(43)【公開日】2014年9月8日

【審査請求日】2015年3月6日

(73)【特許権者】

【識別番号】000005496

【氏名又は名称】富士ゼロックス株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】特許業務法人はるか国際特許事務所

(72)【発明者】

【氏名】ローシャン タプリヤ

(72)【発明者】

【氏名】胡 朝新

【審査官】 衣鳩 文彦

(56)【参考文献】

【文献】 特開２０１０−０４１３２６（ＪＰ，Ａ）

【文献】 特許第４７７２０５３（ＪＰ，Ｂ２）

【文献】 佐々木 貴之 他，適応型帯域推定とＳＡＣＫを組み合わせた無線ネットワーク向けＴＣＰ，電子情報通信学会論文誌，２００４年１０月 １日，第J87-B巻,第10号，p.1657〜1667，「２．３」，「４．１」，「４．２」

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／８０７

(57)【特許請求の範囲】

【請求項1】

輻輳ウィンドウのウィンドウサイズをＴＣＰ Ｒｅｎｏ方式で変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、
前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、
前記サーバから配信されたパケット集合を受信する受信手段と、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、
を含み、
前記算出手段は、前記再送タイムアウト発生条件が満足される場合、第１の数式に従って、前記帯域幅の推定値を算出し、
前記第１の数式は、前記帯域幅の推定値をＢＷと表し、前記ＲＴＴ取得手段により取得された測定値をＲＴＴと表し、前記ロス率取得手段により取得された測定値をｐと表し、所与の再送タイムアウト時間をＴと表し、パケット一つあたりのデータサイズをＭＳＳと表した場合、

【数1】

であること、
を特徴とする帯域測定装置。

【請求項2】

前記サーバから配信されたパケット集合が受信された場合に、受信されたパケット集合中のパケット数が、前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かを判定する手段をさらに含み、
前記判定手段は、前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、
を特徴とする請求項１に記載の帯域測定装置。

【請求項3】

前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに含み、
前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、
を特徴とする請求項２に記載の帯域測定装置。

【請求項4】

前記算出手段は、前記再送タイムアウト発生条件が満足されない場合、前記再送タイムアウト時間を含まない第２の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とする請求項１乃至３のいずれかに記載の帯域測定装置。

【請求項5】

輻輳ウィンドウのウィンドウサイズをＴＣＰ Ｒｅｎｏ方式で変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、
前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、
前記サーバから配信されたパケット集合を受信する受信手段、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、
として機能させるためのプログラムであって、
前記算出手段は、前記再送タイムアウト発生条件が満足される場合、第１の数式に従って、前記帯域幅の推定値を算出し、
前記第１の数式は、前記帯域幅の推定値をＢＷと表し、前記ＲＴＴ取得手段により取得された測定値をＲＴＴと表し、前記ロス率取得手段により取得された測定値をｐと表し、所与の再送タイムアウト時間をＴと表し、パケット一つあたりのデータサイズをＭＳＳと表した場合、

【数2】

であること、
を特徴とするプログラム。

【請求項6】

輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、
前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、
前記サーバから配信されたパケット集合を受信する受信手段と、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、
前記サーバから配信されたパケット集合が受信された場合に、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かを判定する手段と、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、
を含み、
前記判定手段は、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、
前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とする帯域測定装置。

【請求項7】

前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに含み、
前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、
を特徴とする請求項６記載の帯域測定装置。

【請求項8】

輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、
前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、
前記サーバから配信されたパケット集合を受信する受信手段、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、
前記サーバから配信されたパケット集合が受信された場合に、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かを判定する手段、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、
として機能させるためのプログラムであって、
前記判定手段は、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、
前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とするプログラム。

【請求項9】

輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、
前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、
前記サーバから配信されたパケット集合を受信する受信手段と、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、
前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段と、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、
を含み、
前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、
前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とする帯域測定装置。

【請求項10】

輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、
前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、
前記サーバから配信されたパケット集合を受信する受信手段、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、
前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、
として機能させるためのプログラムであって、
前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、
前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、帯域測定装置及びプログラムに関する。

【背景技術】

【0002】

ＴＣＰプロトコルでは、輻輳が起こらないように輻輳ウィンドウのサイズが制御される。例えば、重複ＡＣＫが受信された場合に、輻輳ウィンドウのサイズが半分にされる。また、例えば、再送タイムアウトが発生した場合に、輻輳ウィンドウのサイズが一パケット分のサイズに変更される（下記特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特表２００７−５３４１９４号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明の目的は、再送タイムアウトの発生を考慮して、通信チャネルの帯域幅を推定することである。

【課題を解決するための手段】

【0005】

上記課題を解決するための請求項１の発明は、輻輳ウィンドウのウィンドウサイズをＴＣＰ Ｒｅｎｏ方式で変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、前記サーバから配信されたパケット集合を受信する受信手段と、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、を含み、前記算出手段は、前記再送タイムアウト発生条件が満足される場合、第１の数式に従って、前記帯域幅の推定値を算出し、前記第１の数式は、前記帯域幅の推定値をＢＷと表し、前記ＲＴＴ取得手段により取得された測定値をＲＴＴと表し、前記ロス率取得手段により取得された測定値をｐと表し、所与の再送タイムアウト時間をＴと表し、パケット一つあたりのデータサイズをＭＳＳと表した場合、下記数式（１）であること、を特徴とする帯域測定装置である。

【0006】

【数1】

【0007】

また、請求項２の発明は、前記サーバから配信されたパケット集合が受信された場合に、受信されたパケット集合中のパケット数が、前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かを判定する手段をさらに含み、前記判定手段は、前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、を特徴とする請求項１に記載の帯域測定装置である。
また、請求項３の発明は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに含み、前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、を特徴とする請求項２に記載の帯域測定装置である。
また、請求項４の発明は、前記算出手段は、前記再送タイムアウト発生条件が満足されない場合、前記再送タイムアウト時間を含まない第２の数式に従って、前記帯域幅の推定値を算出すること、を特徴とする請求項１乃至３のいずれかに記載の帯域測定装置である。
また、請求項５の発明は、輻輳ウィンドウのウィンドウサイズをＴＣＰ Ｒｅｎｏ方式で変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、前記サーバから配信されたパケット集合を受信する受信手段、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、として機能させるためのプログラムであって、前記算出手段は、前記再送タイムアウト発生条件が満足される場合、第１の数式に従って、前記帯域幅の推定値を算出し、前記第１の数式は、前記帯域幅の推定値をＢＷと表し、前記ＲＴＴ取得手段により取得された測定値をＲＴＴと表し、前記ロス率取得手段により取得された測定値をｐと表し、所与の再送タイムアウト時間をＴと表し、パケット一つあたりのデータサイズをＭＳＳと表した場合、上記数式（１）であること、を特徴とするプログラムである。

【0008】

また、請求項６の発明は、輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、前記サーバから配信されたパケット集合を受信する受信手段と、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、前記サーバから配信されたパケット集合が受信された場合に、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かを判定する手段と、再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、を含み、前記判定手段は、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、を特徴とする帯域測定装置である。
また、請求項７の発明は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに含み、前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、を特徴とする請求項６記載の帯域測定装置である。
また、請求項８の発明は、輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、前記サーバから配信されたパケット集合を受信する受信手段、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、前記サーバから配信されたパケット集合が受信された場合に、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かを判定する手段、再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、として機能させるためのプログラムであって、前記判定手段は、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、を特徴とするプログラムである。

【0009】

また、請求項９の発明は、輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、前記サーバから配信されたパケット集合を受信する受信手段と、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段と、再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、を含み、前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、を特徴とする帯域測定装置である。
また、請求項１０の発明は、輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、前記サーバから配信されたパケット集合を受信する受信手段、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段、再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、として機能させるためのプログラムであって、前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定し、前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズを含む第１の数式に従って、前記帯域幅の推定値を算出すること、を特徴とするプログラムである。

【発明の効果】

【0015】

請求項１乃至１０に記載の発明によれば、再送タイムアウトの発生を考慮して通信チャネルの帯域幅を推定できる。

【0016】

特に請求項１、５の発明によれば、サーバがＴＣＰ Ｒｅｎｏ方式で輻輳ウィンドウのサイズを変化させる場合に、通信チャネルの帯域幅を正確に推定できる。

【0017】

また、特に請求項２乃至４、６乃至１０の発明によれば、本構成を有しない場合に比較してより高い精度で再送タイムアウトの発生を検知することができ、当該再送タイムアウトの発生を考慮して通信チャネルの帯域幅を推定できる。

【図面の簡単な説明】

【0018】

【図1】サービスシステムの構成の一例を示す図である。

【図2】携帯端末に実装される通信ポートを示す図である。

【図3】ウィンドウサイズの制御について説明するための図である。

【図4】ウィンドウサイズの制御について説明するための図である。

【図5】パケット数の時間推移の一例を示す図である。

【図6】ＶＰＮ通信ポート間の通信を説明するための図である。

【図7】ｒｔｔ列の一例を示す図である。

【図8】携帯端末にて実行される処理を示すフロー図である。

【図9】携帯端末にて実行される処理を示すフロー図である。

【図10】スループット方程式の問題点を説明するための図である。

【発明を実施するための形態】

【0019】

図１は、サービスシステム１の構成の一例を示す図である。サービスシステム１は、サービスサーバ４と、複数の基地局アンテナ６と、携帯端末２と、を含む。サービスサーバ４は、通信事業者から或る通信チャネルＸを借り受けている仮想移動体通信事業者（以下、ＭＶＮＯ（Mobile Virtual Network Operator）と表記する）が所有しているサーバであり、パブリックネットワークたるＷＡＮ(Wide Area Network)に接続されている。ＷＡＮは、インターネットとも呼ばれる。サービスサーバ４と、ＭＶＮＯの顧客の携帯端末２と、は通信チャネルＸを介して通信している。

【0020】

サービスサーバ４は、ＭＶＮＯの顧客の携帯端末２に対して各種情報処理サービス（例えば、動画のストリーミング配信サービス）を提供する。具体的には、サービスサーバ４には、ネットワークインタフェースに対応するＩＰ通信ポート（１）がオペレーティングシステムによりソフトウェア的に実装されている。ＩＰ通信ポート（１）には、サービスサーバ４のＩＰアドレスが割り当てられており、情報処理サービスに関するデータが、ＩＰ通信ポート（１）から携帯端末２へと送信される。

【0021】

また、本実施形態の場合、サービスサーバ４には、ＶＰＮ（Virtual Private Network）サーバソフトウェアがインストールされており、ＶＰＮサーバソフトウェアによりＶＰＮ通信ポート（１）がソフトウェア的に実装されている。ＶＰＮ通信ポート（１）には、バーチャルプライベートネットワーク（以下、ＶＰＮと表記する）におけるＩＰアドレスが割り当てられる。

【0022】

ＶＰＮ通信ポート（１）の意義については後述する。

【0023】

また、基地局アンテナ６は、携帯端末２をＷＡＮに無線接続するためのアンテナである。

【0024】

また、携帯端末２は、ＭＶＮＯの顧客が情報処理サービスを利用するために用いられるコンピュータであり、マイクロプロセッサ、主記憶、ディスプレイ、スピーカ、無線通信インタフェース、及びＧＰＳ（Global Positioning System）情報を随時受信するＧＰＳ受信機などを備える。ＧＰＳ情報は、携帯端末２の位置を示す。ここでは、携帯端末２は、いわゆるＡｎｄｒｏｉｄ（登録商標）オペレーティングシステムがインストールされた携帯電話である。主記憶には、オペレーティングシステム及びＭＶＮＯによってネットワーク配信された通信測定プログラムが格納され、マイクロプロセッサはこれらに従って各種情報を実行する。なお、通信測定プログラムは、ＤＶＤ（登録商標）―ＲＯＭ等のコンピュータ読み取り可能な情報記憶媒体から読み出されて主記憶に格納されてもよい。

【0025】

携帯端末２は、無線通信インタフェースによりいずれかの基地局アンテナ６（例えば、近くの基地局アンテナ６）に無線接続されることにより、ＷＡＮに無線接続される。なお、携帯端末２の接続先の基地局アンテナ６は、携帯端末２の移動に応じて切り替わる。携帯端末２が高速で移動している場合、接続先の基地局アンテナ６が頻繁に切り替わる。ちなみに、図１では、携帯端末２を一台しか示していないが、ＭＶＮＯの顧客は複数おり、実際には、通信チャネルＸを介してサービスサーバ４と通信する携帯端末２が複数存在している。

【0026】

図２は、携帯端末２にソフトウェア的に実装される通信ポートを示す図である。本実施形態の場合、同図に示すように、携帯端末２では、オペレーティングシステムにより、ＩＰ通信ポート（２）とＶＰＮ通信ポート（２）とが実装される。まず、ＩＰ通信ポート（２）について説明する。

【0027】

ＩＰ通信ポート（２）は、図１に示すＩＰ通信ポート（１）と通信を行うための通信ポートであり、携帯端末２のＩＰアドレスが割り当てられている。サービスサーバ４は、ＩＰ通信ポート（１）から、輻輳ウィンドウ（Congestion Window）のウィンドウサイズ「Ｗｓ」分の数のパケット（ＤＡＴＡ［Ｎ＋１］、ＤＡＴＡ［Ｎ＋２］、・・・、ＤＡＴＡ［Ｎ＋Ｗｓ］）からなるパケット集合を配信しており、携帯端末２は、ＩＰ通信ポート（２）により、サービスサーバ４から配信されたパケット集合を受信する。また、携帯端末２は、パケット集合を受信すると、受信したパケット集合中のパケットそれぞれに対応する確認応答パケット（ＡＣＫ［Ｎ＋１］、ＡＣＫ［Ｎ＋２］、・・・、ＡＣＫ［Ｎ＋Ｗｓ］）をＩＰ通信ポート（２）から返信する。なお、ウィンドウサイズ「Ｗｓ」は、パケット数として表現される。また、ここでは、パケット一つ当たりのデータサイズＭＳＳは１５００バイトである。

【0028】

ウィンドウサイズ「Ｗｓ」は一定ではない。すなわち、サービスサーバ４は、輻輳（Congestion）の発生を避けるために、ウィンドウサイズ「Ｗｓ」を適宜変化させている。図３及び図４は、ウィンドウサイズ「Ｗｓ」の制御について説明するための図である。上述のように、サービスサーバ４が、「Ｗｓ」個のパケットからなるパケット集合を送信すると（Ｓ１０１）、それを受信した携帯端末２は、受信したパケット集合中のパケットそれぞれに対応する確認応答パケットをＩＰ通信ポート（２）から返信する（Ｓ２０１）。

【0029】

そして、サービスサーバ４が、携帯端末２から送信された確認応答パケットすべてを受信すると、図３に示すように、サービスサーバ４は、ウィンドウサイズ「Ｗｓ」を更新し（Ｓ１０２）、Ｓ１０１以降のステップを再度実行する。

【0030】

本実施形態では、サービスサーバ４は、ＴＣＰ Ｒｅｎｏ方式でウィンドウサイズを制御している。ＴＣＰ Ｒｅｎｏ方式のウィンドウ制御については、ＲＦＣ(Request for Comment)に記載されている(http://tools.ietf.org/html/rfc2001)。簡単に説明すると、いわゆるスロースタートが実行中である場合、すなわち、ウィンドウサイズ「Ｗｓ」が閾値「Ｗｔｈ」未満である場合、Ｓ１０２でサービスサーバ４は、ウィンドウサイズ「Ｗｓ」を二倍する。また、スロースタートではなくいわゆる輻輳回避が実行中である場合、すなわち、ウィンドウサイズ「Ｗｓ」が閾値「Ｗｔｈ」以上である場合、Ｓ１０２でサービスサーバ４は、ウインドウサイズ「Ｗｓ」を「１」だけインクリメントする。従って、ウィンドウサイズ「Ｗｓ」は、スロースタート実行中、指数関数的に増加し、スロースタート実行後の輻輳回避中、線形的に増加することとなる。

【0031】

但し、いわゆる重複ＡＣＫが発生した場合、すなわち、一つのパケットについてそのパケットに対応する確認応答パケットＡＣＫを重複して受信した場合、Ｓ１０２でサービスサーバ４は、早期回復アルゴリズムに従い、ウィンドウサイズ「Ｗｓ」を半減する。

【0032】

また、再送タイムアウト（以下、ＲＴＯ（retransmission timeout）と表記する）が発生した場合、すなわち、パケット集合の送信からタイムアウト時間Ｔｏｕｔ経過しても、当該パケット集合中のパケットそれぞれに対応する確認応答パケットＡＣＫ全部が受信されない場合、サービスサーバ４は、図４に示すように、図３のＳ１０２の代わりに、Ｓ１０２Ａのステップを実行する。すなわち、Ｓ１０２Ａでサービスサーバ４は、ウィンドウサイズ「Ｗｓ」を「１」に更新する。そして、サービスサーバ４は、Ｓ１０１以降のステップを再度実行する。なお、閾値「Ｗｔｈ」は、ＲＴＯが発生したときに更新される。すなわち、閾値「Ｗｔｈ」は、ＲＴＯが発生したとき、そのときのウィンドウサイズ「Ｗｓ」の四分の一に更新される。また、閾値「Ｗｔｈ」は、そのほかのタイミングにも更新される。すなわち、更新前の閾値「Ｗｔｈ」が記憶されるようになっており、ＲＴＯの発生後、ウィンドウサイズ「Ｗｓ」が更新前の閾値「Ｗｔｈ」に達したときに、閾値「Ｗｔｈ」が更新前の値に戻される。

【0033】

なお、Ｔｏｕｔが特許請求の範囲に記載の「Ｔ」に相当する。

【0034】

ちなみに、重複ＡＣＫやＲＴＯは輻輳の発生時に発生する。そのため、輻輳発生時のウィンドウサイズ「Ｗｓ」を「Ｗ」と表した場合、サービスサーバ４から送信されるパケット集合中のパケット数の時間推移は図５のようになる傾向がある。横軸が時間を示し、縦軸がパケット数を示す。細い実線がパケット数の時間推移を示す。なお、太い実線は、閾値「Ｗｔｈ」の値の推移を示す。また、Ｔ１は、ＲＴＯ発生時の時刻を示す。また、Ｔ２は、Ｔ１からタイムアウト時間Ｔｏｕｔ経過後の時刻、すなわちスロースタートの実行が開始される時刻、を示す。また、Ｔ３は、スロースタートの実行が終了される時刻、すなわち、ウィンドウサイズ「Ｗｓ」が閾値「Ｗｔｈ」に達した時刻を示す。また、Ｔ４は、スロースタート終了後、ウィンドウサイズ「Ｗｓ」が、輻輳発生時のウィンドウサイズ「Ｗ」の半分である「Ｗ／２」に達した時刻を示す。上述のように、重複ＡＣＫが発生したときに、ウィンドウサイズ「Ｗｓ」が半減されている。また、ＲＴＯが発生したときに、ウィンドウサイズ「Ｗｓ」が「１」に更新されている。それだけでなく、閾値「Ｗｔｈ」が、時刻Ｔ１でＲＴＯが発生したときのウィンドウサイズ「Ｗ」の四分の一に更新されている。またその後、時刻Ｔ２から時刻Ｔ３の間スロースタートが実行され、ウィンドウサイズ「Ｗｓ」が、閾値「Ｗｔｈ」に達するまで指数関数的に増加している。また、時刻Ｔ３の後輻輳回避が実行され、ウィンドウサイズ「Ｗｓ」が線形的に増加している。また、時刻Ｔ４でウィンドウサイズ「Ｗｓ」が、更新前の閾値「Ｗｔｈ」、すなわち、輻輳が発生したときのウィンドウサイズ「Ｗ」の二分の一に達したとき、閾値「Ｗｔｈ」が更新前の値に更新されている。

【0035】

なお、以下、Ｔ２からＴ３までの期間をスロースタート期間と呼び、Ｔ３からＴ４までの期間をリカバリ期間と呼ぶ。

【0036】

このようにパケット数が推移する傾向があるので、スロースタート期間の長さ「Ｔ３−Ｔ２」をＴ_slowと表した場合、以下の数式が成立する。

【0037】

【数2】

【0038】

よって、ウィンドウサイズ「Ｗｓ」のおおよその更新間隔ＲＴＴ_refを時間の単位として用いた場合、Ｔ_slowは、以下のように近似される。

【0039】

【数3】

【0040】

また、スロースタート期間に送信されるパケット数の総和をＰ_slowと表した場合、Ｐ_slowは、以下の数式であらわされる。

【0041】

【数4】

【0042】

よって、Ｐ_slowは、以下のように表される。

【0043】

【数5】

【0044】

一方、リカバリ期間の長さ「Ｔ４−Ｔ３」をＴ_recoveryと表した場合、Ｔ_recoveryは、ＲＴＴ_refを用いて以下のように近似される。

【0045】

【数6】

【0046】

また、スロースタート期間に送信されるパケット数の総和をＰ_recoveryと表した場合、Ｐ_recoveryは、台形の面積を求める公式から以下のようになる。

【0047】

【数7】

【0048】

従って、Ｔ４からＴ１までの期間（以下、ＲＴＯ期間と表記する）の長さＴ_total及びＲＴＯ期間中に送信された総データ量Ｐ_totalは、以下のように近似される。

【0049】

【数8】

【0050】

なお、図５によれば、ウィンドウサイズ「Ｗｓ」が「Ｗ／２」であるときから「Ｗ」に達するまでの期間に、一回パケットロスが発生したと考えられる。従って、パケットロス率ｐは以下のように近似される。

【0051】

【数9】

【0052】

よって、輻輳発生時のウィンドウサイズ「Ｗ」は、以下のように近似される。

【0053】

【数10】

【0054】

従って、Ｔ_total及びＰ_totalは、パケットロス率ｐを用いて以下のように表される。

【0055】

【数11】

【0056】

次に、ＶＰＮ通信ポート（２）について説明する。ＶＰＮ通信ポート（２）は、ＶＰＮ通信ポート（１）とＶＰＮを介して通信するための通信ポートであり、ＶＰＮにおけるＩＰアドレスが割り当てられる。ＶＰＮ通信ポート（２）は、情報処理サービスを受けるために利用されるのではなく、通信チャネルＸにおけるラウンドトリップタイムを得るために用いられる。すなわち、携帯端末２は、ＶＰＮ通信ポート（２）からダミーパケットＤＵＭＭＹを繰り返し送信している。

【0057】

図６は、ＶＰＮ通信ポート（２）とＶＰＮ通信ポート（１）との間の通信を説明するための図である。まず、携帯端末２（正確には、携帯端末２のマイクロプロセッサ）は、ＶＰＮ通信ポート（２）からダミーパケットＤＵＭＭＹを送信し（Ｓ３０１）、パラメータｔ１の値を、現在時刻Ｔｃに設定する（Ｓ３０２）。ダミーパケットＤＵＭＭＹの送信後、ダミーパケットＤＵＭＭＹを受信したサービスサーバ４から確認応答パケットＤＵＭＭＹ−ＡＣＫが返信される（Ｓ４０１）。確認応答パケットＤＵＭＭＹ−ＡＣＫを受信すると、携帯端末２のマイクロプロセッサは、パラメータｔ２の値を現在時刻Ｔｃに設定し（Ｓ３０３）、パラメータｔ１が示す時刻からパラメータｔ２が示す時刻までの時間を、ラウンドトリップタイムｒｔｔとして算出する（Ｓ３０４）。

【0058】

そして、携帯端末２のマイクロプロセッサは、Ｓ３０４で算出したｒｔｔを、ラウンドトリップタイムｒｔｔのデータ列（以下、ｒｔｔ列と表記する）の最後の要素として主記憶に保存し（Ｓ３０５）、Ｓ３０１以降のステップを再度実行する。例えば、ｒｔｔ列に「Ｌ（Ｌは０又は正の整数）」個のラウンドトリップタイムｒｔｔが含まれている場合、Ｓ３０４で算出されたｒｔｔが、Ｓ３０５において、ｒｔｔ列の「Ｌ＋１」番目の要素として主記憶に保存されることになる。図７に、ｒｔｔ列の一例を示す。なお、本実施形態では、重複ＡＣＫが発生した場合（ＤＵＭＭＹ−ＡＣＫが重複して受信された場合）、Ｓ３０４で得られたｒｔｔに所定のフラグ値が関連づけられる。

【0059】

この携帯端末２では、このｒｔｔ列に基づいて、通信チャネルＸの帯域幅（単位時間当たりに流れるデータ量）の推定値ＢＷが定期的に算出され、サービスサーバ４に届けられる。サービスサーバ４では、携帯端末２から受け取った推定値ＢＷに基づいて例えばパケットシェイピングが行われ、通信チャネルＸへと送信される単位時間当たりのデータ量が随時調整されることとなる。

【0060】

図８及び図９は、推定値ＢＷの算出のため、携帯端末２のマイクロプロセッサが定期的に行う処理を示すフロー図である。まず、マイクロプロセッサ（ＲＴＴ取得手段）は、主記憶に記憶されるｒｔｔ列を読み出す（Ｓ５０１）。そして、マイクロプロセッサ（ＲＴＴ取得手段）は、ｒｔｔ列に基づいて、通信チャネルＸにおけるラウンドトリップタイムの測定値ＲＴＴ_measureを算出する（Ｓ５０２）。本実施形態の場合、Ｓ５０２でマイクロプロセッサは、ｒｔｔ列中の全ｒｔｔの平均をＲＴＴ_measureとして算出する。ＲＴＴ_measureが特許請求の範囲に記載の「ＲＴＴ」に相当する。

【0061】

また、マイクロプロセッサ（ロス率取得手段）は、通信チャネルＸにおけるパケットロス率の測定値ｐを取得する（Ｓ５０３）。測定値ｐの取得方法は、多々あるが、本実施形態の場合、マイクロプロセッサは、ｒｔｔ列に基づいて測定値ｐを算出する。具体的に、Ｓ５０３でマイクロプロセッサは、ｒｔｔ列中のｒｔｔの総数に対する、上記所定のフラグ値が関連づけられたｒｔｔの数の割合いを、測定値ｐとして算出する。

【0062】

そして、マイクロプロセッサは、Ｓ５０４以降のステップを実行することにより、推定値ＢＷを算出する。

【0063】

ところで、よく知られた下記スループット方程式により、推定値ＢＷを算出してもよいように思われる。

【0064】

【数12】

【0065】

なお、「Ｃ」及び「ｋ」は、所定の定数である。

【0066】

しかしＲＴＯが発生している状況下では、スループット方程式が成り立たなくなる。なぜなら、ＲＴＯが発生している最中は、パケットの送信が行われない。そのため、ＲＴＯが発生しているときに測定されるラウンドトリップタイムは、ＲＴＴ_measureとかけ離れた値になるからである。従って、ＲＴＯが発生している状況下で上記スループット方程式を用いた場合、実際の帯域幅より相当小さい推定値ＢＷが得られることになる。

【0067】

図１０は、スループット方程式の問題点を説明するための図であり、ＲＴＯが発生している状況下での、「ＢＷ×（ＲＴＴ_measure／ＭＳＳ）」とｐとの関係を示す図である。縦軸は、「ＢＷ×（ＲＴＴ_measure／ＭＳＳ）」の値を対数目盛りで示し、横軸は、ｐの値を対数目盛で示している。中抜きされた正方形が、ＲＴＯ発生時の双方の関係を示し、点線が、スループット方程式における双方の関係を示している。同図に示すように、ＲＴＯ発生時では、「ＢＷ×（ＲＴＴ_measure／ＭＳＳ）」の値が点線を大きく下回っている。

【0068】

そこで、この携帯端末２では、ＲＴＯが発生しているか否か、すなわちＲＴＯ発生条件が満足されるか否かによって、推定値ＢＷの算出に用いる数式を変化させる。すなわち、この携帯端末２では、ＲＴＯ発生条件が満足されない場合、上記スループット方程式により推定値ＢＷを算出し、ＲＴＯ発生条件が満足される場合、タイムアウト時間Ｔｏｕｔを含む下記特別スループット方程式により推定値ＢＷを算出する。

【0069】

【数13】

【0070】

ここで、ＲＴＯ発生条件は、以下の条件（１）〜条件（３）のいずれか一つが成立する場合に、満足される。すなわち、条件（１）〜条件（３）のいずれか一つが成立する場合、ＲＴＯが発生していると目される。

【0071】

条件（１）：携帯端末２が高速で移動している（接続先の基地局アンテナ６が切り替わりやすい）。
条件（２）：パケット集合を受信してから基準時間Ｔ_ｔｈ（例えばＴ_ｔｈは３秒）以上経過した後に、次のパケット集合を受信した。
条件（３）：受信したパケット集合中のパケット数が、前回受信したパケット集合中のパケット数の２倍である（スロースタート期間中である）。

【0072】

具体的には、マイクロプロセッサは、Ｓ５０４以降、以下の処理を実行する。すなわち、Ｓ５０４でマイクロプロセッサ（判定手段）は、携帯端末２が高速で移動しているか否かを判定する。すなわち、Ｓ５０４でマイクロプロセッサは、ＧＰＳ受信機が随時受信しているＧＰＳ情報に基づいて携帯端末２の移動速度ｖを算出し、移動速度ｖが閾値ｖ_ｔｈ以上であるか否かを判定する（Ｓ５０４）。なお、Ｓ５０４では、条件（１）の成否が判定されている。

【0073】

携帯端末２では、パケット集合が受信されるたびに、そのパケット集合が受信されてからの経過時間が計測されるようになっている。マイクロプロセッサ（判定手段）は、携帯端末２が高速で移動していない場合（Ｓ５０４のＮ）、ＩＰ通信ポート（２）を監視する。そして、ＩＰ通信ポート（２）がパケット集合を受信した場合、前回パケット集合が受信されてからの経過時間が基準時間Ｔ_ｔｈ以上であるか否かを判定する（Ｓ５０５）。なお、Ｓ５０５では、条件（２）の成否が判定されている。

【0074】

前回パケット集合が受信されてからの経過時間が基準時間Ｔ_ｔｈ未満である場合（Ｓ５０５のＮ）、マイクロプロセッサは、受信したパケット集合中のパケット数を主記憶に記録し、ＩＰ通信ポート（２）を監視する。そして、マイクロプロセッサ（判定手段）は、ＩＰ通信ポート（２）がパケット集合を受信した場合、受信したパケット集合中のパケット数が主記憶に記録したパケット数の２倍であるか否かを判定する（Ｓ５０６）。なお、Ｓ５０６では、条件（３）の成否が判定されている。

【0075】

そして、Ｓ５０４で肯定的な判定結果が得られた場合（Ｓ５０４のＹ）、又は、Ｓ５０５で肯定的な判定結果が得られた場合（Ｓ５０５のＹ）、又は、Ｓ５０６で肯定的な判定結果が得られた場合（Ｓ５０６のＹ）、マイクロプロセッサ（算出手段）は、上記特別スループット方程式に従って推定値ＢＷを算出し（Ｓ５０７）、算出した推定値ＢＷをサービスサーバ４に送信する。

【0076】

一方、Ｓ５０４、Ｓ５０５、及びＳ５０６のいずれにおいても肯定的な判定結果が得られなかった場合（Ｓ５０６のＮ）、ＲＴＯが発生していないと考えられる。そこで、この場合、マイクロプロセッサ（算出手段）は、上記スループット方程式で推定値ＢＷを算出し、算出した推定値ＢＷをサービスサーバ４に送信する。但し、本実施形態の場合、マイクロプロセッサは、上記スループット方程式で推定値ＢＷを算出する際に、ＲＴＴ_measureの代わりに、以下で説明するＲＴＴ_pureを用いる。

【0077】

すなわち、マイクロプロセッサは、ｒｔｔ列が表すｒｔｔの変化のパターン（以下、オリジナルパターンと表記する）に対してフーリエ変換を実行し（Ｓ５０８）、周波数スペクトルを取得する。そして、マイクロプロセッサは、フィルタリングを実行し、周波数スペクトルから高周波成分を除去する（Ｓ５０９）。すなわち、マイクロプロセッサは、周波数スペクトルから、予め定められた基準周波数ｆ_ref以上の周波成分を除去する。

【0078】

そして、マイクロプロセッサは、フィルタリングされた後の周波数スペクトルに対して逆フーリエ変換を実行し（Ｓ５１０）、オリジナルパターンから高周波成分を除去したパターンを算出する。そして、マイクロプロセッサは、Ｓ５１０の結果得られたパターンに基づいて上記ＲＴＴ_pureを算出する（Ｓ５１１）。ここでは、Ｓ５１１でマイクロプロセッサは、Ｓ５１０の結果得られたパターンの時間平均をＲＴＴ_pureとして算出する。

【0079】

そして、マイクロプロセッサは、上記スループット方程式に従って推定値ＢＷを算出し（Ｓ５１２）、算出した推定値ＢＷをサービスサーバ４に送信する。なお、ここでは、ＲＴＴ_measureの代わりにＲＴＴ_pureが用いられているが、勿論、ＲＴＴ_measureが用いられてもよい。

【0080】

なお、本発明の実施形態は、上記実施形態だけに限らない。

【0081】

例えば、基地局アンテナ６は、無線アクセスポイントであってもよい。

【0082】

また、Ｓ５０７でマイクロプロセッサ（算出手段）は、上記特別スループット方程式で推定値ＢＷを算出する際に、上記ＲＴＴ_measureの代わりに上記ＲＴＴ_pureを用いてもよい。この場合、ＲＴＴ_pureが特許請求の範囲に記載の測定値「ＲＴＴ」に相当することとなる。

【0083】

また、マイクロプロセッサ（算出手段）は、Ｓ５０４、Ｓ５０５、及びＳ５０６のいずれにおいても肯定的な判定結果が得られた場合にのみ、Ｓ５０７のステップを実行してもよい。すなわち、上記条件（１）〜条件（３）のすべてが成立する場合に、ＲＴＯ発生条件が満足されることとしてもよい。

【0084】

また、Ｓ５０４、Ｓ５０５、及びＳ５０６の全部ではなく、一部だけが実行されてもよい。例えば、これら３つのステップのうちの２つだけが実行されてもよいし、１つだけが実行されてもよい。例えば、Ｓ５０４とＳ５０５とだけが実行される場合、「上記条件（１）乃至上記条件（３）」のうちのいずれか一つの成立ではなく、「条件（１）及び条件（２）」のうちのいずれか一つの成立が、ＲＴＯ発生条件が満足されることの条件となる。また例えば、Ｓ５０５だけが実行される場合、条件（１）乃至条件（３）うちのいずれか一つの成立ではなく、条件（２）の成立が、ＲＴＯ発生条件が満足されることの条件となる。

【0085】

また、Ｓ５０５でマイクロプロセッサ（判定手段）は、前回パケット集合が受信されてからの経過時間が基準時間Ｔ_ｔｈ以上であるか否かを判定する代わりに、今回受信したパケット集合中のパケット数が「１」であるか否かを判定してもよい。すなわち、「パケットを一つのみ含むパケット集合の受信」を条件（２）としてもよい。ＲＴＯが発生するとウィンドウサイズ「Ｗｓ」が「１」に設定されるからである。

【符号の説明】

【0086】

１ サービスシステム、２ 携帯端末、４ サービスサーバ、６ 基地局アンテナ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】