(57)【要約】【課題】再送タイムアウトの発生を考慮して、通信チャネルの帯域幅を推定する。【解決手段】携帯端末は、サーバとの通信に用いる通信チャネルにおけるラウンドトリップタイムの測定値と、上記通信チャネルにおけるパケットロス率の測定値と、を取得する（Ｓ５０２、Ｓ５０３）。そして、携帯端末は、サーバにおいて再送タイムアウトが発生しているか否かを判定する（Ｓ５０４、Ｓ５０５、Ｓ５０６）。サーバにおいて再送タイムアウトが発生している場合、携帯端末は、タイムアウト時間を含む特別スループット方程式を用いて、上記通信チャネルの帯域幅の推定値を算出する（Ｓ５０７）。一方、サーバにおいて再送タイムアウトが発生していない場合、携帯端末は、タイムアウト時間を含まない通常のスループット方程式を用いて帯域幅の推定値を算出する。【選択図】図８
2014165809.tif 000002
【特許請求の範囲】
【請求項１】
輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、
前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、
前記サーバから配信されたパケット集合を受信する受信手段と、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、
を含み、
前記算出手段は、
前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズとを含む第１の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とする帯域測定装置。
【請求項２】
前記サーバは、ＴＣＰ  Ｒｅｎｏ方式で前記ウィンドウサイズを変化させ、
前記第１の数式は、前記帯域幅の推定値をＢＷと表し、前記ＲＴＴ取得手段により取得された測定値をＲＴＴと表し、前記ロス率取得手段により取得された測定値をｐと表し、前記タイムアウト時間をＴと表し、前記データサイズをＭＳＳと表した場合、
【数１】
2014165809.tif 000016
であること、
を特徴とする請求項１に記載の帯域測定装置。
【請求項３】
前記サーバから配信されたパケット集合が受信された場合に、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かを判定する手段をさらに含み、
前記判定手段は、
前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、
を特徴とする請求項１又は２に記載の帯域測定装置。
【請求項４】
前記サーバから配信されたパケット集合が受信された場合に、受信されたパケット集合中のパケット数が、前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かを判定する手段をさらに含み、
前記判定手段は、
前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、
を特徴とする請求項２に記載の帯域測定装置。
【請求項５】
前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに含み、
前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、を特徴とする請求項１又は２に記載の帯域測定装置。
【請求項６】
前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに含み、
前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、
を特徴とする請求項３記載の帯域測定装置。
【請求項７】
前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに含み、
前記判定手段は、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定すること、
を特徴とする請求項４に記載の帯域測定装置。
【請求項８】
前記算出手段は、前記再送タイムアウト発生条件が満足されない場合、前記再送タイムアウト時間を含まない第２の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とする請求項１乃至７のいずれかに記載の帯域測定装置。
【請求項９】
輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、
前記コンピュータと前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、
前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、
前記サーバから配信されたパケット集合を受信する受信手段、
前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、
前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、
として機能させるためのプログラムであって、
前記算出手段は、
前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズとを含む第１の数式に従って、前記帯域幅の推定値を算出すること、
を特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、帯域測定装置及びプログラムに関する。
【背景技術】
【０００２】
ＴＣＰプロトコルでは、輻輳が起こらないように輻輳ウィンドウのサイズが制御される。例えば、重複ＡＣＫが受信された場合に、輻輳ウィンドウのサイズが半分にされる。また、例えば、再送タイムアウトが発生した場合に、輻輳ウィンドウのサイズが一パケット分のサイズに変更される（下記特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２００７−５３４１９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、再送タイムアウトの発生を考慮して、通信チャネルの帯域幅を推定することである。
【課題を解決するための手段】
【０００５】
上記課題を解決するための請求項１の発明は、輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信する帯域測定装置であって、前記帯域測定装置と前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段と、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段と、前記サーバから配信されたパケット集合を受信する受信手段と、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段と、再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段と、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段と、を含み、前記算出手段は、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズとを含む第１の数式に従って、前記帯域幅の推定値を算出すること、を特徴とする帯域測定装置である。
【０００６】
また、請求項２に記載の帯域測定装置は、請求項１に記載の帯域測定装置において、前記サーバは、ＴＣＰ  Ｒｅｎｏ方式で前記ウィンドウサイズを変化させ、前記第１の数式は、前記帯域幅の推定値をＢＷと表し、前記ＲＴＴ取得手段により取得された測定値をＲＴＴと表し、前記ロス率取得手段により取得された測定値をｐと表し、前記タイムアウト時間をＴと表し、前記データサイズをＭＳＳと表した場合、
【０００７】
【数１】
2014165809.tif 000003
であることを特徴としている。
【０００８】
また、請求項３に記載の帯域測定装置は、請求項１又は２に記載の帯域測定装置に、前記サーバから配信されたパケット集合が受信された場合に、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かを判定する手段をさらに備えさせ、前記判定手段が、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かに基づいて前記再送タイムアウト発生条件が満足されるか否かを判定するようにしたことを特徴としている。
【０００９】
また、請求項４に記載の帯域測定装置は、請求項２に記載の帯域測定装置に、前記サーバから配信されたパケット集合が受信された場合に、受信されたパケット集合中のパケット数が、前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かを判定する手段をさらに備えさせ、前記判定手段が、前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定するようにしたことを特徴としている。
【００１０】
また、請求項５に記載の帯域測定装置は、請求項１又は２に記載の帯域測定装置に、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに備えさせ、前記判定手段が、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かに基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定するようにしたことを特徴としている。
【００１１】
また、請求項６に記載の帯域測定装置は、請求項３に記載の帯域測定装置に、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに備えさせ、前記判定手段が、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記サーバから前回配信されたパケット集合が受信されてから基準時間以上経過しているか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定するようにしたことを特徴としている。
【００１２】
また、請求項７に記載の帯域測定装置は、請求項４に記載の帯域測定装置に、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かを判定する手段をさらに備えさせ、前記判定手段が、前記帯域測定装置が高速移動条件を満足する移動速度で移動しているか否かと、前記受信されたパケット集合中のパケット数が前記サーバから前回受信されたパケット集合中のパケット数の二倍であるか否かと、に基づいて、前記再送タイムアウト発生条件が満足されるか否かを判定するようにしたことを特徴としている。
【００１３】
また、請求項８に記載の帯域測定装置は、請求項１乃至７のいずれかに記載の帯域測定装置において、前記算出手段が、前記再送タイムアウト発生条件が満足されない場合、前記再送タイムアウト時間を含まない第２の数式に従って、前記帯域幅の推定値を算出することを特徴としている。
【００１４】
また、上記課題を解決するための請求項５の発明は、輻輳ウィンドウのウィンドウサイズを変化させながらウィンドウサイズ分の数のパケットからなるパケット集合を配信するサーバと、パブリックネットワークを介して通信するコンピュータを、前記コンピュータと前記サーバとの通信に用いられる通信チャネルにおけるラウンドトリップタイムの測定値を取得するＲＴＴ取得手段、前記通信チャネルにおけるパケットロス率の測定値を取得するロス率取得手段、前記サーバから配信されたパケット集合を受信する受信手段、前記サーバから配信されたパケット集合が受信された場合に、該パケット集合中のパケットそれぞれに対応する確認応答パケットを前記サーバに返信する返信手段、
再送タイムアウトが発生しているか否かの再送タイムアウト発生条件が満足されるか否かを判定する判定手段、前記判定手段の判定結果に基づいて、前記通信チャネルにおける帯域幅の推定値を算出する算出手段、として機能させ、前記算出手段が、前記再送タイムアウト発生条件が満足される場合、前記ＲＴＴ取得手段により取得された測定値、前記ロス率取得手段により取得された測定値、所与の再送タイムアウト時間、及びパケット一つあたりのデータサイズとを含む第１の数式に従って、前記帯域幅の推定値を算出することを特徴とするプログラムである。
【発明の効果】
【００１５】
請求項１、９の発明によれば、再送タイムアウトの発生を考慮して、通信チャネルの帯域幅を推定できる。
【００１６】
請求項２の発明によれば、特にサーバがＴＣＰ  Ｒｅｎｏ方式で輻輳ウィンドウのサイズを変化させる場合に、通信チャネルの帯域幅を正確に推定できる。
【００１７】
請求項３、４、５、６、７の発明によれば、本構成を有しない場合に比較して、より高い精度で、再送タイムアウトの発生を検知できる。また、請求項８の発明によれば、再送タイムアウトの発生有無を考慮して、通信チャネルの帯域幅を推定できる。
【図面の簡単な説明】
【００１８】
【図１】サービスシステムの構成の一例を示す図である。
【図２】携帯端末に実装される通信ポートを示す図である。
【図３】ウィンドウサイズの制御について説明するための図である。
【図４】ウィンドウサイズの制御について説明するための図である。
【図５】パケット数の時間推移の一例を示す図である。
【図６】ＶＰＮ通信ポート間の通信を説明するための図である。
【図７】ｒｔｔ列の一例を示す図である。
【図８】携帯端末にて実行される処理を示すフロー図である。
【図９】携帯端末にて実行される処理を示すフロー図である。
【図１０】スループット方程式の問題点を説明するための図である。
【発明を実施するための形態】
【００１９】
図１は、サービスシステム１の構成の一例を示す図である。サービスシステム１は、サービスサーバ４と、複数の基地局アンテナ６と、携帯端末２と、を含む。サービスサーバ４は、通信事業者から或る通信チャネルＸを借り受けている仮想移動体通信事業者（以下、ＭＶＮＯ（Mobile Virtual Network Operator）と表記する）が所有しているサーバであり、パブリックネットワークたるＷＡＮ(Wide Area Network)に接続されている。ＷＡＮは、インターネットとも呼ばれる。サービスサーバ４と、ＭＶＮＯの顧客の携帯端末２と、は通信チャネルＸを介して通信している。
【００２０】
サービスサーバ４は、ＭＶＮＯの顧客の携帯端末２に対して各種情報処理サービス（例えば、動画のストリーミング配信サービス）を提供する。具体的には、サービスサーバ４には、ネットワークインタフェースに対応するＩＰ通信ポート（１）がオペレーティングシステムによりソフトウェア的に実装されている。ＩＰ通信ポート（１）には、サービスサーバ４のＩＰアドレスが割り当てられており、情報処理サービスに関するデータが、ＩＰ通信ポート（１）から携帯端末２へと送信される。
【００２１】
また、本実施形態の場合、サービスサーバ４には、ＶＰＮ（Virtual Private Network）サーバソフトウェアがインストールされており、ＶＰＮサーバソフトウェアによりＶＰＮ通信ポート（１）がソフトウェア的に実装されている。ＶＰＮ通信ポート（１）には、バーチャルプライベートネットワーク（以下、ＶＰＮと表記する）におけるＩＰアドレスが割り当てられる。
【００２２】
ＶＰＮ通信ポート（１）の意義については後述する。
【００２３】
また、基地局アンテナ６は、携帯端末２をＷＡＮに無線接続するためのアンテナである。
【００２４】
また、携帯端末２は、ＭＶＮＯの顧客が情報処理サービスを利用するために用いられるコンピュータであり、マイクロプロセッサ、主記憶、ディスプレイ、スピーカ、無線通信インタフェース、及びＧＰＳ（Global Positioning System）情報を随時受信するＧＰＳ受信機などを備える。ＧＰＳ情報は、携帯端末２の位置を示す。ここでは、携帯端末２は、いわゆるＡｎｄｒｏｉｄ（登録商標）オペレーティングシステムがインストールされた携帯電話である。主記憶には、オペレーティングシステム及びＭＶＮＯによってネットワーク配信された通信測定プログラムが格納され、マイクロプロセッサはこれらに従って各種情報を実行する。なお、通信測定プログラムは、ＤＶＤ（登録商標）―ＲＯＭ等のコンピュータ読み取り可能な情報記憶媒体から読み出されて主記憶に格納されてもよい。
【００２５】
携帯端末２は、無線通信インタフェースによりいずれかの基地局アンテナ６（例えば、近くの基地局アンテナ６）に無線接続されることにより、ＷＡＮに無線接続される。なお、携帯端末２の接続先の基地局アンテナ６は、携帯端末２の移動に応じて切り替わる。携帯端末２が高速で移動している場合、接続先の基地局アンテナ６が頻繁に切り替わる。ちなみに、図１では、携帯端末２を一台しか示していないが、ＭＶＮＯの顧客は複数おり、実際には、通信チャネルＸを介してサービスサーバ４と通信する携帯端末２が複数存在している。
【００２６】
図２は、携帯端末２にソフトウェア的に実装される通信ポートを示す図である。本実施形態の場合、同図に示すように、携帯端末２では、オペレーティングシステムにより、ＩＰ通信ポート（２）とＶＰＮ通信ポート（２）とが実装される。まず、ＩＰ通信ポート（２）について説明する。
【００２７】
ＩＰ通信ポート（２）は、図１に示すＩＰ通信ポート（１）と通信を行うための通信ポートであり、携帯端末２のＩＰアドレスが割り当てられている。サービスサーバ４は、ＩＰ通信ポート（１）から、輻輳ウィンドウ（Congestion Window）のウィンドウサイズ「Ｗｓ」分の数のパケット（ＤＡＴＡ［Ｎ＋１］、ＤＡＴＡ［Ｎ＋２］、・・・、ＤＡＴＡ［Ｎ＋Ｗｓ］）からなるパケット集合を配信しており、携帯端末２は、ＩＰ通信ポート（２）により、サービスサーバ４から配信されたパケット集合を受信する。また、携帯端末２は、パケット集合を受信すると、受信したパケット集合中のパケットそれぞれに対応する確認応答パケット（ＡＣＫ［Ｎ＋１］、ＡＣＫ［Ｎ＋２］、・・・、ＡＣＫ［Ｎ＋Ｗｓ］）をＩＰ通信ポート（２）から返信する。なお、ウィンドウサイズ「Ｗｓ」は、パケット数として表現される。また、ここでは、パケット一つ当たりのデータサイズＭＳＳは１５００バイトである。
【００２８】
ウィンドウサイズ「Ｗｓ」は一定ではない。すなわち、サービスサーバ４は、輻輳（Congestion）の発生を避けるために、ウィンドウサイズ「Ｗｓ」を適宜変化させている。図３及び図４は、ウィンドウサイズ「Ｗｓ」の制御について説明するための図である。上述のように、サービスサーバ４が、「Ｗｓ」個のパケットからなるパケット集合を送信すると（Ｓ１０１）、それを受信した携帯端末２は、受信したパケット集合中のパケットそれぞれに対応する確認応答パケットをＩＰ通信ポート（２）から返信する（Ｓ２０１）。
【００２９】
そして、サービスサーバ４が、携帯端末２から送信された確認応答パケットすべてを受信すると、図３に示すように、サービスサーバ４は、ウィンドウサイズ「Ｗｓ」を更新し（Ｓ１０２）、Ｓ１０１以降のステップを再度実行する。
【００３０】
本実施形態では、サービスサーバ４は、ＴＣＰ  Ｒｅｎｏ方式でウィンドウサイズを制御している。ＴＣＰ  Ｒｅｎｏ方式のウィンドウ制御については、ＲＦＣ(Request for Comment)に記載されている(http://tools.ietf.org/html/rfc2001)。簡単に説明すると、いわゆるスロースタートが実行中である場合、すなわち、ウィンドウサイズ「Ｗｓ」が閾値「Ｗｔｈ」未満である場合、Ｓ１０２でサービスサーバ４は、ウィンドウサイズ「Ｗｓ」を二倍する。また、スロースタートではなくいわゆる輻輳回避が実行中である場合、すなわち、ウィンドウサイズ「Ｗｓ」が閾値「Ｗｔｈ」以上である場合、Ｓ１０２でサービスサーバ４は、ウインドウサイズ「Ｗｓ」を「１」だけインクリメントする。従って、ウィンドウサイズ「Ｗｓ」は、スロースタート実行中、指数関数的に増加し、スロースタート実行後の輻輳回避中、線形的に増加することとなる。
【００３１】
但し、いわゆる重複ＡＣＫが発生した場合、すなわち、一つのパケットについてそのパケットに対応する確認応答パケットＡＣＫを重複して受信した場合、Ｓ１０２でサービスサーバ４は、早期回復アルゴリズムに従い、ウィンドウサイズ「Ｗｓ」を半減する。
【００３２】
また、再送タイムアウト（以下、ＲＴＯ（retransmission timeout）と表記する）が発生した場合、すなわち、パケット集合の送信からタイムアウト時間Ｔｏｕｔ経過しても、当該パケット集合中のパケットそれぞれに対応する確認応答パケットＡＣＫ全部が受信されない場合、サービスサーバ４は、図４に示すように、図３のＳ１０２の代わりに、Ｓ１０２Ａのステップを実行する。すなわち、Ｓ１０２Ａでサービスサーバ４は、ウィンドウサイズ「Ｗｓ」を「１」に更新する。そして、サービスサーバ４は、Ｓ１０１以降のステップを再度実行する。なお、閾値「Ｗｔｈ」は、ＲＴＯが発生したときに更新される。すなわち、閾値「Ｗｔｈ」は、ＲＴＯが発生したとき、そのときのウィンドウサイズ「Ｗｓ」の四分の一に更新される。また、閾値「Ｗｔｈ」は、そのほかのタイミングにも更新される。すなわち、更新前の閾値「Ｗｔｈ」が記憶されるようになっており、ＲＴＯの発生後、ウィンドウサイズ「Ｗｓ」が更新前の閾値「Ｗｔｈ」に達したときに、閾値「Ｗｔｈ」が更新前の値に戻される。
【００３３】
なお、Ｔｏｕｔが特許請求の範囲に記載の「Ｔ」に相当する。
【００３４】
ちなみに、重複ＡＣＫやＲＴＯは輻輳の発生時に発生する。そのため、輻輳発生時のウィンドウサイズ「Ｗｓ」を「Ｗ」と表した場合、サービスサーバ４から送信されるパケット集合中のパケット数の時間推移は図５のようになる傾向がある。横軸が時間を示し、縦軸がパケット数を示す。細い実線がパケット数の時間推移を示す。なお、太い実線は、閾値「Ｗｔｈ」の値の推移を示す。また、Ｔ１は、ＲＴＯ発生時の時刻を示す。また、Ｔ２は、Ｔ１からタイムアウト時間Ｔｏｕｔ経過後の時刻、すなわちスロースタートの実行が開始される時刻、を示す。また、Ｔ３は、スロースタートの実行が終了される時刻、すなわち、ウィンドウサイズ「Ｗｓ」が閾値「Ｗｔｈ」に達した時刻を示す。また、Ｔ４は、スロースタート終了後、ウィンドウサイズ「Ｗｓ」が、輻輳発生時のウィンドウサイズ「Ｗ」の半分である「Ｗ／２」に達した時刻を示す。上述のように、重複ＡＣＫが発生したときに、ウィンドウサイズ「Ｗｓ」が半減されている。また、ＲＴＯが発生したときに、ウィンドウサイズ「Ｗｓ」が「１」に更新されている。それだけでなく、閾値「Ｗｔｈ」が、時刻Ｔ１でＲＴＯが発生したときのウィンドウサイズ「Ｗ」の四分の一に更新されている。またその後、時刻Ｔ２から時刻Ｔ３の間スロースタートが実行され、ウィンドウサイズ「Ｗｓ」が、閾値「Ｗｔｈ」に達するまで指数関数的に増加している。また、時刻Ｔ３の後輻輳回避が実行され、ウィンドウサイズ「Ｗｓ」が線形的に増加している。また、時刻Ｔ４でウィンドウサイズ「Ｗｓ」が、更新前の閾値「Ｗｔｈ」、すなわち、輻輳が発生したときのウィンドウサイズ「Ｗ」の二分の一に達したとき、閾値「Ｗｔｈ」が更新前の値に更新されている。
【００３５】
なお、以下、Ｔ２からＴ３までの期間をスロースタート期間と呼び、Ｔ３からＴ４までの期間をリカバリ期間と呼ぶ。
【００３６】
このようにパケット数が推移する傾向があるので、スロースタート期間の長さ「Ｔ３−Ｔ２」をＴslowと表した場合、以下の数式が成立する。
【００３７】
【数２】
2014165809.tif 000004
【００３８】
よって、ウィンドウサイズ「Ｗｓ」のおおよその更新間隔ＲＴＴrefを時間の単位として用いた場合、Ｔslowは、以下のように近似される。
【００３９】
【数３】
2014165809.tif 000005
【００４０】
また、スロースタート期間に送信されるパケット数の総和をＰslowと表した場合、Ｐslowは、以下の数式であらわされる。
【００４１】
【数４】
2014165809.tif 000006
【００４２】
よって、Ｐslowは、以下のように表される。
【００４３】
【数５】
2014165809.tif 000007
【００４４】
一方、リカバリ期間の長さ「Ｔ４−Ｔ３」をＴrecoveryと表した場合、Ｔrecoveryは、ＲＴＴrefを用いて以下のように近似される。
【００４５】
【数６】
2014165809.tif 000008
【００４６】
また、スロースタート期間に送信されるパケット数の総和をＰrecoveryと表した場合、Ｐrecoveryは、台形の面積を求める公式から以下のようになる。
【００４７】
【数７】
2014165809.tif 000009
【００４８】
従って、Ｔ４からＴ１までの期間（以下、ＲＴＯ期間と表記する）の長さＴtotal及びＲＴＯ期間中に送信された総データ量Ｐtotalは、以下のように近似される。
【００４９】
【数８】
2014165809.tif 000010
【００５０】
なお、図５によれば、ウィンドウサイズ「Ｗｓ」が「Ｗ／２」であるときから「Ｗ」に達するまでの期間に、一回パケットロスが発生したと考えられる。従って、パケットロス率ｐは以下のように近似される。
【００５１】
【数９】
2014165809.tif 000011
【００５２】
よって、輻輳発生時のウィンドウサイズ「Ｗ」は、以下のように近似される。
【００５３】
【数１０】
2014165809.tif 000012
【００５４】
従って、Ｔtotal及びＰtotalは、パケットロス率ｐを用いて以下のように表される。
【００５５】
【数１１】
2014165809.tif 000013
【００５６】
次に、ＶＰＮ通信ポート（２）について説明する。ＶＰＮ通信ポート（２）は、ＶＰＮ通信ポート（１）とＶＰＮを介して通信するための通信ポートであり、ＶＰＮにおけるＩＰアドレスが割り当てられる。ＶＰＮ通信ポート（２）は、情報処理サービスを受けるために利用されるのではなく、通信チャネルＸにおけるラウンドトリップタイムを得るために用いられる。すなわち、携帯端末２は、ＶＰＮ通信ポート（２）からダミーパケットＤＵＭＭＹを繰り返し送信している。
【００５７】
図６は、ＶＰＮ通信ポート（２）とＶＰＮ通信ポート（１）との間の通信を説明するための図である。まず、携帯端末２（正確には、携帯端末２のマイクロプロセッサ）は、ＶＰＮ通信ポート（２）からダミーパケットＤＵＭＭＹを送信し（Ｓ３０１）、パラメータｔ１の値を、現在時刻Ｔｃに設定する（Ｓ３０２）。ダミーパケットＤＵＭＭＹの送信後、ダミーパケットＤＵＭＭＹを受信したサービスサーバ４から確認応答パケットＤＵＭＭＹ−ＡＣＫが返信される（Ｓ４０１）。確認応答パケットＤＵＭＭＹ−ＡＣＫを受信すると、携帯端末２のマイクロプロセッサは、パラメータｔ２の値を現在時刻Ｔｃに設定し（Ｓ３０３）、パラメータｔ１が示す時刻からパラメータｔ２が示す時刻までの時間を、ラウンドトリップタイムｒｔｔとして算出する（Ｓ３０４）。
【００５８】
そして、携帯端末２のマイクロプロセッサは、Ｓ３０４で算出したｒｔｔを、ラウンドトリップタイムｒｔｔのデータ列（以下、ｒｔｔ列と表記する）の最後の要素として主記憶に保存し（Ｓ３０５）、Ｓ３０１以降のステップを再度実行する。例えば、ｒｔｔ列に「Ｌ（Ｌは０又は正の整数）」個のラウンドトリップタイムｒｔｔが含まれている場合、Ｓ３０４で算出されたｒｔｔが、Ｓ３０５において、ｒｔｔ列の「Ｌ＋１」番目の要素として主記憶に保存されることになる。図７に、ｒｔｔ列の一例を示す。なお、本実施形態では、重複ＡＣＫが発生した場合（ＤＵＭＭＹ−ＡＣＫが重複して受信された場合）、Ｓ３０４で得られたｒｔｔに所定のフラグ値が関連づけられる。
【００５９】
この携帯端末２では、このｒｔｔ列に基づいて、通信チャネルＸの帯域幅（単位時間当たりに流れるデータ量）の推定値ＢＷが定期的に算出され、サービスサーバ４に届けられる。サービスサーバ４では、携帯端末２から受け取った推定値ＢＷに基づいて例えばパケットシェイピングが行われ、通信チャネルＸへと送信される単位時間当たりのデータ量が随時調整されることとなる。
【００６０】
図８及び図９は、推定値ＢＷの算出のため、携帯端末２のマイクロプロセッサが定期的に行う処理を示すフロー図である。まず、マイクロプロセッサ（ＲＴＴ取得手段）は、主記憶に記憶されるｒｔｔ列を読み出す（Ｓ５０１）。そして、マイクロプロセッサ（ＲＴＴ取得手段）は、ｒｔｔ列に基づいて、通信チャネルＸにおけるラウンドトリップタイムの測定値ＲＴＴmeasureを算出する（Ｓ５０２）。本実施形態の場合、Ｓ５０２でマイクロプロセッサは、ｒｔｔ列中の全ｒｔｔの平均をＲＴＴmeasureとして算出する。ＲＴＴmeasureが特許請求の範囲に記載の「ＲＴＴ」に相当する。
【００６１】
また、マイクロプロセッサ（ロス率取得手段）は、通信チャネルＸにおけるパケットロス率の測定値ｐを取得する（Ｓ５０３）。測定値ｐの取得方法は、多々あるが、本実施形態の場合、マイクロプロセッサは、ｒｔｔ列に基づいて測定値ｐを算出する。具体的に、Ｓ５０３でマイクロプロセッサは、ｒｔｔ列中のｒｔｔの総数に対する、上記所定のフラグ値が関連づけられたｒｔｔの数の割合いを、測定値ｐとして算出する。
【００６２】
そして、マイクロプロセッサは、Ｓ５０４以降のステップを実行することにより、推定値ＢＷを算出する。
【００６３】
ところで、よく知られた下記スループット方程式により、推定値ＢＷを算出してもよいように思われる。
【００６４】
【数１２】
2014165809.tif 000014
【００６５】
なお、「Ｃ」及び「ｋ」は、所定の定数である。
【００６６】
しかしＲＴＯが発生している状況下では、スループット方程式が成り立たなくなる。なぜなら、ＲＴＯが発生している最中は、パケットの送信が行われない。そのため、ＲＴＯが発生しているときに測定されるラウンドトリップタイムは、ＲＴＴmeasureとかけ離れた値になるからである。従って、ＲＴＯが発生している状況下で上記スループット方程式を用いた場合、実際の帯域幅より相当小さい推定値ＢＷが得られることになる。
【００６７】
図１０は、スループット方程式の問題点を説明するための図であり、ＲＴＯが発生している状況下での、「ＢＷ×（ＲＴＴmeasure／ＭＳＳ）」とｐとの関係を示す図である。縦軸は、「ＢＷ×（ＲＴＴmeasure／ＭＳＳ）」の値を対数目盛りで示し、横軸は、ｐの値を対数目盛で示している。中抜きされた正方形が、ＲＴＯ発生時の双方の関係を示し、点線が、スループット方程式における双方の関係を示している。同図に示すように、ＲＴＯ発生時では、「ＢＷ×（ＲＴＴmeasure／ＭＳＳ）」の値が点線を大きく下回っている。
【００６８】
そこで、この携帯端末２では、ＲＴＯが発生しているか否か、すなわちＲＴＯ発生条件が満足されるか否かによって、推定値ＢＷの算出に用いる数式を変化させる。すなわち、この携帯端末２では、ＲＴＯ発生条件が満足されない場合、上記スループット方程式により推定値ＢＷを算出し、ＲＴＯ発生条件が満足される場合、タイムアウト時間Ｔｏｕｔを含む下記特別スループット方程式により推定値ＢＷを算出する。
【００６９】
【数１３】
2014165809.tif 000015
【００７０】
ここで、ＲＴＯ発生条件は、以下の条件（１）〜条件（３）のいずれか一つが成立する場合に、満足される。すなわち、条件（１）〜条件（３）のいずれか一つが成立する場合、ＲＴＯが発生していると目される。
【００７１】
条件（１）：携帯端末２が高速で移動している（接続先の基地局アンテナ６が切り替わりやすい）。
条件（２）：パケット集合を受信してから基準時間Ｔｔｈ（例えばＴｔｈは３秒）以上経過した後に、次のパケット集合を受信した。
条件（３）：受信したパケット集合中のパケット数が、前回受信したパケット集合中のパケット数の２倍である（スロースタート期間中である）。
【００７２】
具体的には、マイクロプロセッサは、Ｓ５０４以降、以下の処理を実行する。すなわち、Ｓ５０４でマイクロプロセッサ（判定手段）は、携帯端末２が高速で移動しているか否かを判定する。すなわち、Ｓ５０４でマイクロプロセッサは、ＧＰＳ受信機が随時受信しているＧＰＳ情報に基づいて携帯端末２の移動速度ｖを算出し、移動速度ｖが閾値ｖｔｈ以上であるか否かを判定する（Ｓ５０４）。なお、Ｓ５０４では、条件（１）の成否が判定されている。
【００７３】
携帯端末２では、パケット集合が受信されるたびに、そのパケット集合が受信されてからの経過時間が計測されるようになっている。マイクロプロセッサ（判定手段）は、携帯端末２が高速で移動していない場合（Ｓ５０４のＮ）、ＩＰ通信ポート（２）を監視する。そして、ＩＰ通信ポート（２）がパケット集合を受信した場合、前回パケット集合が受信されてからの経過時間が基準時間Ｔｔｈ以上であるか否かを判定する（Ｓ５０５）。なお、Ｓ５０５では、条件（２）の成否が判定されている。
【００７４】
前回パケット集合が受信されてからの経過時間が基準時間Ｔｔｈ未満である場合（Ｓ５０５のＮ）、マイクロプロセッサは、受信したパケット集合中のパケット数を主記憶に記録し、ＩＰ通信ポート（２）を監視する。そして、マイクロプロセッサ（判定手段）は、ＩＰ通信ポート（２）がパケット集合を受信した場合、受信したパケット集合中のパケット数が主記憶に記録したパケット数の２倍であるか否かを判定する（Ｓ５０６）。なお、Ｓ５０６では、条件（３）の成否が判定されている。
【００７５】
そして、Ｓ５０４で肯定的な判定結果が得られた場合（Ｓ５０４のＹ）、又は、Ｓ５０５で肯定的な判定結果が得られた場合（Ｓ５０５のＹ）、又は、Ｓ５０６で肯定的な判定結果が得られた場合（Ｓ５０６のＹ）、マイクロプロセッサ（算出手段）は、上記特別スループット方程式に従って推定値ＢＷを算出し（Ｓ５０７）、算出した推定値ＢＷをサービスサーバ４に送信する。
【００７６】
一方、Ｓ５０４、Ｓ５０５、及びＳ５０６のいずれにおいても肯定的な判定結果が得られなかった場合（Ｓ５０６のＮ）、ＲＴＯが発生していないと考えられる。そこで、この場合、マイクロプロセッサ（算出手段）は、上記スループット方程式で推定値ＢＷを算出し、算出した推定値ＢＷをサービスサーバ４に送信する。但し、本実施形態の場合、マイクロプロセッサは、上記スループット方程式で推定値ＢＷを算出する際に、ＲＴＴmeasureの代わりに、以下で説明するＲＴＴpureを用いる。
【００７７】
すなわち、マイクロプロセッサは、ｒｔｔ列が表すｒｔｔの変化のパターン（以下、オリジナルパターンと表記する）に対してフーリエ変換を実行し（Ｓ５０８）、周波数スペクトルを取得する。そして、マイクロプロセッサは、フィルタリングを実行し、周波数スペクトルから高周波成分を除去する（Ｓ５０９）。すなわち、マイクロプロセッサは、周波数スペクトルから、予め定められた基準周波数ｆref以上の周波成分を除去する。
【００７８】
そして、マイクロプロセッサは、フィルタリングされた後の周波数スペクトルに対して逆フーリエ変換を実行し（Ｓ５１０）、オリジナルパターンから高周波成分を除去したパターンを算出する。そして、マイクロプロセッサは、Ｓ５１０の結果得られたパターンに基づいて上記ＲＴＴpureを算出する（Ｓ５１１）。ここでは、Ｓ５１１でマイクロプロセッサは、Ｓ５１０の結果得られたパターンの時間平均をＲＴＴpureとして算出する。
【００７９】
そして、マイクロプロセッサは、上記スループット方程式に従って推定値ＢＷを算出し（Ｓ５１２）、算出した推定値ＢＷをサービスサーバ４に送信する。なお、ここでは、ＲＴＴmeasureの代わりにＲＴＴpureが用いられているが、勿論、ＲＴＴmeasureが用いられてもよい。
【００８０】
なお、本発明の実施形態は、上記実施形態だけに限らない。
【００８１】
例えば、基地局アンテナ６は、無線アクセスポイントであってもよい。
【００８２】
また、Ｓ５０７でマイクロプロセッサ（算出手段）は、上記特別スループット方程式で推定値ＢＷを算出する際に、上記ＲＴＴmeasureの代わりに上記ＲＴＴpureを用いてもよい。この場合、ＲＴＴpureが特許請求の範囲に記載の測定値「ＲＴＴ」に相当することとなる。
【００８３】
また、マイクロプロセッサ（算出手段）は、Ｓ５０４、Ｓ５０５、及びＳ５０６のいずれにおいても肯定的な判定結果が得られた場合にのみ、Ｓ５０７のステップを実行してもよい。すなわち、上記条件（１）〜条件（３）のすべてが成立する場合に、ＲＴＯ発生条件が満足されることとしてもよい。
【００８４】
また、Ｓ５０４、Ｓ５０５、及びＳ５０６の全部ではなく、一部だけが実行されてもよい。例えば、これら３つのステップのうちの２つだけが実行されてもよいし、１つだけが実行されてもよい。例えば、Ｓ５０４とＳ５０５とだけが実行される場合、「上記条件（１）乃至上記条件（３）」のうちのいずれか一つの成立ではなく、「条件（１）及び条件（２）」のうちのいずれか一つの成立が、ＲＴＯ発生条件が満足されることの条件となる。また例えば、Ｓ５０５だけが実行される場合、条件（１）乃至条件（３）うちのいずれか一つの成立ではなく、条件（２）の成立が、ＲＴＯ発生条件が満足されることの条件となる。
【００８５】
また、Ｓ５０５でマイクロプロセッサ（判定手段）は、前回パケット集合が受信されてからの経過時間が基準時間Ｔｔｈ以上であるか否かを判定する代わりに、今回受信したパケット集合中のパケット数が「１」であるか否かを判定してもよい。すなわち、「パケットを一つのみ含むパケット集合の受信」を条件（２）としてもよい。ＲＴＯが発生するとウィンドウサイズ「Ｗｓ」が「１」に設定されるからである。
【符号の説明】
【００８６】
１  サービスシステム、２  携帯端末、４  サービスサーバ、６  基地局アンテナ。
【図１】
2014165809.tif 000017
【図２】
2014165809.tif 000018
【図３】
2014165809.tif 000019
【図４】
2014165809.tif 000020
【図５】
2014165809.tif 000021
【図６】
2014165809.tif 000022
【図７】
2014165809.tif 000023
【図８】
2014165809.tif 000024
【図９】
2014165809.tif 000025
【図１０】
2014165809.tif 000026