(57)【要約】【課題】パケット通信における特定ネットワークの混雑状況を適切に判定する。【解決手段】一例は、ネットワークのパケットを監視する監視システムであって、監視装置と、ユーザ端末側の第１ネットワークとサーバ側の第２ネットワークとの接続点において、前記ユーザ端末と前記サーバとの間で通信されるパケットを転送し、さらに、当該パケットを前記監視装置に転送する、転送装置と、を含む。前記監視装置は、前記ユーザ端末と前記サーバとの間で通信される前記パケットを解析し、前記解析の結果に基づいて、前記ユーザ端末と前記サーバとの間で転送されるパケットの、前記第１ネットワークにおけるパケット損失を決定し、前記第１ネットワークにおける前記パケット損失に基づいて、前記第１ネットワークがボトルネックであるか否かを判定する。【選択図】図１
2014179827.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークのパケットを監視する監視システムであって、
監視装置と、
ユーザ端末側の第１ネットワークとサーバ側の第２ネットワークとの接続点において、前記ユーザ端末と前記サーバとの間で通信されるパケットを転送し、さらに、当該パケットを前記監視装置に転送する、転送装置と、を含み、
前記監視装置は、
前記ユーザ端末と前記サーバとの間で通信される前記パケットを解析し、
前記解析の結果に基づいて、前記ユーザ端末と前記サーバとの間で転送されるパケットの、前記第１ネットワークにおけるパケット損失を決定し、
前記第１ネットワークにおける前記パケット損失に基づいて、前記第１ネットワークがボトルネックであるか否かを判定する、監視システム。
【請求項２】
請求項１に記載の監視システムであって、
前記監視装置は、前記解析の結果に基づいて、前記ユーザ端末と前記サーバとの間で転送されるパケットの、前記第２ネットワークにおけるパケット損失を決定し、
前記第２ネットワークにおける前記パケット損失に基づいて、前記第２ネットワークがボトルネックであるか否かを判定する、監視システム。
【請求項３】
請求項１又は２に記載の監視システムであって、
前記監視装置は、前記ユーザ端末から前記サーバに送信されるデータ受信確認用パケットに付された前記ユーザ端末が受信可能なデータ量を示す値に基づき、前記ユーザ端末がボトルネックであるか否か判定する、監視システム。
【請求項４】
請求項３に記載の監視システムであって、
前記監視装置は、
前記解析の結果に基づいて前記ユーザ端末と前記サーバとの間の通信速度を推定し、
前記推定した通信速度が閾値より小さく、前記第１ネットワーク、前記第２ネットワーク及び前記ユーザ端末のいずれもボトルネックではないと判定した場合に、前記サーバがボトルネックであると判定する、監視システム。
【請求項５】
請求項４に記載の監視システムであって、
前記監視装置は、前記ユーザ端末と前記サーバとの通信におけるボトルネックについての判定結果を示す情報を、前記ユーザ端末に送信する、監視システム。
【請求項６】
請求項５に記載の監視システムであって、
前記監視システムは前記前記ユーザ端末をさらに含み、
前記ユーザ端末は、
ユーザ入力に応じて、前記判定結果を示す情報の要求を、前記監視装置に送信し、
前記監視装置から受信した前記判定結果を示す情報を表示する、監視システム。
【請求項７】
請求項４に記載の監視システムであって、
前記監視装置は、
前記転送装置から転送されるパケットにおいて、前記第２ネットワークに接続する１又は複数サーバを含み予め登録されているサイトと複数ユーザ端末との間の通信パケットを解析し、
前記サイトと前記複数ユーザ端末との間の通信パケットの前記解析結果により前記サイトがボトルネックであると判定された回数及び前記第２ネットワークがボトルネックであると判定された回数をカウントし、
前記回数に基づいて前記サイトの負荷を判定する、監視システム。
【請求項８】
請求項７に記載の監視システムであって、
前記監視システムは第１ユーザ端末をさらに含み、
前記第１ユーザ端末は、
ユーザ入力に応じて、前記サイトの負荷の判定結果を示す情報の要求を前記監視装置に送信し、
前記監視装置から受信した前記情報が示す前記サイトの負荷状況を表示する、監視システム。
【請求項９】
請求項１に記載の監視システムであって、
前記第１ネットワークは、複数端末終端装置を含み、
前記監視装置は、
前記転送装置から転送されるパケットにおいて、前記複数端末終端装置のそれぞれが転送するパケットを解析し、
前記複数端末終端装置のそれぞれが転送するパケットの前記解析により前記第１ネットワークがボトルネックであると判定された回数を、前記複数端末終端装置のそれぞれについてカウントし、
前記回数に基づいて、前記複数端末終端装置のそれぞれを介したパケット通信における前記第１ネットワークの負荷を判定する、監視システム。
【請求項１０】
請求項９に記載の監視システムであって、
前記監視装置は、第１ユーザ端末からの要求に応答して、前記第１ユーザ端末を収容する端末終端装置についての前記第１ネットワークの負荷判定の結果を表す情報を、前記第１ユーザ端末に送信する、監視システム。
【請求項１１】
請求項１０に記載の監視システムであって、
前記監視システムは前記第１ユーザ端末をさらに含み、
前記第１ユーザ端末は、
ユーザ入力に応じて前記要求を前記監視装置に送信し、
受信した前記情報が示す前記第１ネットワークの負荷状況を表示する、監視システム。
【請求項１２】
請求項９に記載の監視システムであって、
前記監視装置は、第１ユーザ端末から要求を受信し、
前記第１ユーザ端末は、無線通信方式を切り替え可能であり、
前記監視装置は、前記要求に応答して、前記第１ユーザ端末に、前記第１ユーザ端末を収容可能な異なる無線通信方式の端末終端装置についての前記第１ネットワークの負荷判定の結果を表す情報を送信する、監視システム。
【請求項１３】
請求項１２に記載の監視システムであって、
前記監視システムは前記第１ユーザ端末をさらに含み、
前記第１ユーザ端末は、
ユーザ入力に応じて前記要求を前記監視装置に送信し、
受信した前記情報が前記異なる無線通信方式の負荷状況を表示し、
ユーザ入力に応じて前記異なる無線通信方式から選択した無線通信方式を使用してデータを通信する、監視システム。
【請求項１４】
請求項１又は２に記載の監視システムであって、
前記ユーザ端末が接続する端末終端装置を含む第３ネットワークと前記第１ネットワークとの接続点における第２転送装置をさらに含み、
前記監視装置は、前記転送装置から転送されたパケットを解析して、前記第１ネットワーク及び前記第３ネットワークでの総パケット損失を決定し、
前記第２転送装置から転送されたパケットの解析により、前記第１ネットワーク及び第２ネットワークでの総パケット損失を決定し、
前記第１ネットワーク及び前記第３ネットワークでの前記総パケット損失並びに前記第１ネットワーク及び第２ネットワークでの前記総パケット損失に基づき、前記第１ネットワークにおけるパケット損失を決定し、
前記第１ネットワークにおける前記パケット損失に基づいて、前記第１ネットワークがボトルネックであるか否かを判定する、監視システム。
【請求項１５】
ネットワークの監視方法であって、
ユーザ端末側の第１ネットワークとサーバ側の第２ネットワークとの接続点おける前記ユーザ端末と前記サーバとの間で通信される前記パケットを監視及び解析し、
前記解析の結果に基づいて、前記ユーザ端末と前記サーバとの間で転送されるパケットの、前記第１ネットワークにおけるパケット損失を決定し、
前記第１ネットワークにおける前記パケット損失に基づいて、前記第１ネットワークがボトルネックであるか否かを判定する、監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの監視システム及び監視方法に関する。
【背景技術】
【０００２】
最近の急速なＩＴ化により、通信トラフィックは急増し、ネットワークリソースはひっ迫している。このため、通信時に、ユーザが期待する通信速度が得られない場合がある。更に、サービス利用時に通信速度が遅いことがあっても、ユーザは、その原因がネットワーク内のどこにあるのかを知ることができない。また、ユーザがサービスサイトを利用する際、ユーザは、通信を始める前にネットワークやサービスサイトの状態を知ることはできない。ユーザは、サービスを利用してから、初めて通信が遅いことに気づく。
【０００３】
この改善策の一つは、移動体通信において基地局の負荷状況を端末に通知する方法である（例えば、特許文献１）。この方法は、基地局の負荷の度合いや通信速度をユーザ端末に通知する。
【０００４】
この他、ネットワーク上の輻輳の検出方法が、例えば、特許文献２に開示されている。この技術は、ネットワーク上のパケットを監視し、パケットロスを解析することにより、経路上の輻輳の有無を判定する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−２３３１３７号公報
【特許文献２】特開２００９−２３２３００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
一般に、ユーザ端末とサービスサイト（サービスサーバ）は、複数の異なるネットワーク（異なる管理者のネットワーク）を介して通信する。ユーザ及びネットワークの管理者にとって、特定のネットワークの混雑状況の情報は有益である。
【０００７】
例えば、ユーザは、特定のネットワークの負荷状況を参照して、当該ネットワークを介して通信を行うか否かを決定することができる。管理者は、その管理下のネットワークの負荷状況を知ることで、適切に管理化のネットワークを管理することができる。したがって、パケット通信における、特定ネットワークの混雑状況を知ることができる技術が望まれる。
【課題を解決するための手段】
【０００８】
本発明の一態様は、ネットワークのパケットを監視する監視システムであって、監視装置と、ユーザ端末側の第１ネットワークとサーバ側の第２ネットワークとの接続点において、前記ユーザ端末と前記サーバとの間で通信されるパケットを転送し、さらに、当該パケットを前記監視装置に転送する、転送装置と、を含む。前記監視装置は、前記ユーザ端末と前記サーバとの間で通信される前記パケットを解析し、前記解析の結果に基づいて、前記ユーザ端末と前記サーバとの間で転送されるパケットの、前記第１ネットワークにおけるパケット損失を決定し、前記第１ネットワークにおける前記パケット損失に基づいて、前記第１ネットワークがボトルネックであるか否かを判定する。
【発明の効果】
【０００９】
本発明によれば、パケット通信における特定ネットワークの混雑状況を適切に判定することができる。
【図面の簡単な説明】
【００１０】
【図１】実施例１における、複数ネットワークから構成されるネットワーク構成例を模式的に示す。
【図２】実施例１における、ＬＴＥネットワークの構成例を模式的に示す。
【図３】実施例１における、監視サーバの機能構成例を模式的に示すブロック図である。
【図４】実施例１における、監視サーバの物理構成例を模式的に示すブロック図である。
【図５】実施例１における、ＭＭＥの機能構成例を模式的に示すブロック図である。
【図６】実施例１における、ＴＣＰフローを用いたボトルネック解析のダウンロードトラフィック用フローチャートである。
【図７】実施例１における、ネットワーク負荷状況及びサイト負荷状況の解析例のフローチャートである。
【図８】実施例１における、基地局毎ネットワーク負荷状況判定テーブルの構成例を示す。
【図９】実施例１における、サイト負荷状況判定テーブルの構成例を示す。
【図１０】実施例１における、基地局毎ネットワーク負荷状況及びサイト負荷状況の判定で参照される、判定基準の例を示す。
【図１１】実施例１における、ユーザ端末に対するネットワーク及び代表サイトの負荷状況提示のためのシーケンスを示す。
【図１２】図１１のシーケンスにおける、ユーザ端末の処理例を示すフローチャートである。
【図１３】図１１のシーケンスにおける、監視サーバの処理例を示すフローチャートである。
【図１４】実施例１において、ユーザ端末画面におけるネットワーク負荷状況及び代表サイト負荷状況の表示例を示す。
【図１５】実施例１において、ボトルネック特定リクエストの処理シーケンスを示す。
【図１６】実施例１において、ユーザ端末画面におけるボトルネックの表形式による表示例を示す。
【図１７】実施例１において、ユーザ端末画面におけるボトルネックのネットワーク図による表示例を示す。
【図１８】実施例２における、３Ｇネットワークの構成例を模式的に示す。
【図１９】実施例２における、２Ｇネットワークの構成例を模式的に示す。
【図２０】実施例３における、ＷｉＭＡＸネットワークの構成例を模式的に示す。
【図２１】実施例４における、イントラネットの構成例を模式的に示す。
【図２２】実施例５における、多段構成ネットワークの構成例を模式的に示す。
【図２３】実施例６における、ＴＣＰフローを用いたボトルネック解析のアップロードトラフィック用フローチャートである。
【図２４】実施例７において、ユーザ端末画面における通信方向（ダウンロード／アップロード）を明記した推定通信速度の表示例を示す。
【図２５】実施例８における、ＵＤＰパケット解析のためのネットワーク構成例を模式的に示す図である。
【図２６】実施例９における、複数経路を提供するキャリアネットワークの構成例を模式的に示す図である。
【図２７】実施例９における、複数経路対応の負荷状況開示リクエストの処理シーケンスを示す。
【図２８】実施例９において、端末画面における経路別のネットワーク負荷状況の表示例を示す。
【図２９】実施例９において、端末画面における経路別のネットワーク負荷状況の他の表示例を示す。
【図３０】実施例９において、端末画面における経路別のネットワーク負荷状況の他の表示例を示す。
【図３１】実施例９において、端末画面における縮小表示した経路別のネットワーク負荷状況の表示例を示す。
【図３２】実施例９において、端末画面におけるボトルネック及び経路選択の表示画像例を示す。
【発明を実施するための形態】
【００１１】
以下に、本発明の実施の形態を説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡略化がなされている。特に説明のない限り、各図面において、共通要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略されている。
【００１２】
本発明の一実施形態は、特定ネットワークと１又は複数の他のネットワークとの各接続点において、通信サービスおけるパケットトラヒックを監視、解析する。これにより、特定ネットワークにおける混雑状況を適切に判定し、それをユーザ（ここでは、端末のユーザ及びネットワークの管理者を含む語）に示すことができる。例えば、特定ネットワークは、ネットワーク管理者の管理化のネットワークであり、１又は複数の他のネットワークは、管理外のネットワークである。
【００１３】
本発明の一例は、管理下のネットワークと管理外のネットワークの接続点におけるパケットトラフィックの解析により、複数の装置からなる通信経路上の混雑状況を、ユーザ端末、管理下のネットワーク、管理外のネットワーク及びサービスサーバという粒度で判定する。これにより、ユーザ（ここでは、端末のユーザ及びネットワークの管理者を含む語）は、ｅｎｄ−ｔｏ−ｅｎｄの通信品質を知ることができ、複数の装置からなる通信経路上の混雑状況を把握することができ、更に、通信速度が遅い時にその原因箇所を知ることができる。
【００１４】
ネットワーク管理者は、取得した情報により、管理化のネットワークをより適切に管理することができる。端末のユーザは、取得した情報を参照して、アクセスするサービスサーバや使用する通信方式（通信経路）を選択することができる。
【実施例１】
【００１５】
図１は、本発明を適用可能なネットワークシステムの構成例を模式的に示している。このネットワークシステムは、管理者による管理下のネットワーク１、同管理者の管理外のネットワーク２、同管理者の管理外のアクセスネットワーク３、ユーザ端末４及びサービスサーバ群５を含む。
【００１６】
管理下のネットワーク１は、管理外のネットワーク２及び管理外のアクセスネットワーク３と接続している。管理下のネットワーク１は、管理者用端末装置７、監視装置である監視サーバ６、端末終端装置群ａ９、通信装置群８を含む。
【００１７】
管理外のネットワーク２には、外部のサービスサーバ群５が接続されている。管理外のアクセスネットワーク３は、端末終端装置群ｂ１０を含む。ユーザ端末４は、管理下のネットワーク１内の端末終端装置群ａ９、又は、管理外のアクセスネットワーク３内の端末終端装置群ｂ１０に接続している。
【００１８】
監視サーバ６は、サービスサーバ群５と端末終端装置群ａ９との間で通信されるパケットトラヒックを、管理下のネットワーク１と管理外のネットワーク２との接続点おいて、監視、解析する。
【００１９】
本例において、監視サーバ６は、ＴＣＰフローの解析を繰り返し、各ＴＣＰフローの通信におけるボトルネックの有無及びボトルネック位置を特定する（ボトルネックの特定について、図６を参照して後述）。本開示において、通信速度が所望の速度よりも遅いときに、その原因となる経路上の装置又はネットワークを、ボトルネックと呼ぶ。
【００２０】
監視サーバ６は、ＴＣＰフロー解析により、サービスサーバ群５、管理外のネットワーク２、管理下のネットワーク１、ユーザ端末４のそれぞれが、ボトルネックであるか否か判定する。
【００２１】
監視サーバ６は、複数のＴＣＰフローの解析を行い、特定されたボトルネックの情報を保持する。監視サーバ６は、特定されたボトルネックから、サービスサーバ群５におけるサービスサイト（１又は複数サービスサーバからなる）の負荷情報及び管理下のネットワーク１の負荷状況を判定し、その判定結果の情報を保持する（負荷判定及びその判定結果の保持について図７から図１０を参照して後述）。後述するように、監視サーバ６は、基地局毎に管理下のネットワーク１の負荷判定結果を保持する。
【００２２】
装置又はネットワークの通信能力に対して通信すべきトラヒック（パケット数）が多い場合に負荷が高く、負荷が高いことは混雑度が高いことを意味する。ボトルネックは、装置又はネットワークの能力に対して通信すべきトラヒックが多いことを示し、装置又はネットワークがボトルネックであることは、その混雑度が高いことを意味する。
【００２３】
監視サーバ６は、ユーザ端末４からの要求に応答して、ユーザ端末４とサービスサーバ群５との間の通信経路の負荷状況（混雑状況）の情報を提示する（図１１から図１４を参照して後述）。さらに、監視サーバ６は、ユーザ端末４からの要求に応答して、ユーザ端末４と特定のサービスサイト（利用中サービスサイト）との間の通信におけるボトルネックを特定し、それを示す情報をユーザ端末４に提示する（図１５から図１７を参照して後述）。
【００２４】
以下、具体的に、通信キャリアが提供するネットワークサービスの例を用いて、本実施例のボトルネックの特定及びネットワークの通信状況（混雑状況）の把握を説明する。図２は、キャリアが提供する無線通信サービスのシステム構成例を示している。ここでは、一例として、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ)(登録商標、以下同)のシステム構成を用いて説明する。
【００２５】
ｅＮＢ（ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ）２１は基地局であり、図１の端末終端装置群ａ９に含まれる端末終端装置に相当する。Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）２３、Ｐ−ＧＷ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ  Ｇａｔｅｗａｙ）２４、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）２２は、それぞれ、図１の通信装置群８に含まれる通信装置に相当する。ＩＰネットワーク１２は、図１における管理外ネットワーク２に相当する。
【００２６】
この他に、システム構成要素としてはＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）、ＰＣＲＦ（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅ  Ｆｕｎｃｔｉｏｎ）などの管理系のサーバも含まれるが、本図では省略する。図２に示していないが、複数の各種装置がシステム内に存在する。本構成例は、キャリアネットワーク１３と外部ＩＰネットワーク１２の接続点に、パケットの複製及び転送を行う転送装置であるネットワークタップ（以下においてタップとも呼ぶ）１１を含む。タップと１１は、複製したパケットを監視サーバ６へ転送する。
【００２７】
監視サーバ６は、タップ１１により転送された通信データを解析することで、ボトルネックを特定する。ボトルネックの特定は、ボトルネックの有無及びその位置（ネットワーク又は装置）を特定する。本例では、ボトルネックの特定方法の一例として、ＴＣＰフローの解析によるボトルネックの特定方法を示す。
【００２８】
監視サーバ６は、サービスサーバ５（サービスサーバ群内のひとつのサーバ、以下同じ）からダウンロードされるデータパケット、及び、ユーザ端末４から返される受信確認用のＡｃｋパケットを監視し、パケットが廃棄された箇所が、タップ１１を挿入した箇所よりも上流であるか、下流であるかを決定する。
【００２９】
図３は、監視サーバ６の論理構成例を模式的に示すブロック図である。監視サーバ６は、パケット送受信部１５０２、メッセージ送受信部１５０３、ＴＣＰフロー検索・抽出部１５０４、ＴＣＰフロー解析部１５０５、基地局毎ネットワーク負荷状況判定テーブル５０１、基地局毎ネットワーク負荷状況推定部１５０６、サイト負荷状況判定テーブル６０１、サイト負荷状況推定部１５０７及びインタフェース部１５０８を含む。
【００３０】
パケット送受信部１５０２は、ネットワークに接続してパケットを送受信する。メッセージ送受信部１５０３は、ユーザ端末４とメッセージを送受信する。ＴＣＰフローの検索・抽出部１５０４は、ＴＣＰフローの検索及び抽出を行う。ＴＣＰフロー解析部１５０５は、ＴＣＰフローの解析を行う。
【００３１】
基地局毎ネットワーク負荷状況推定部１５０６は、基地局毎ネットワーク負荷状況判定テーブル５０１を管理し、キャリアネットワーク１３の基地局毎の負荷状況を判定（推定）する。サイト負荷状況推定部１５０７は、サイト負荷状況判定テーブル６０１管理し、サイトの負荷状況を判定（推定）する。インタフェース部１５０８は、管理者用端末７との通信インタフェースである。基地局毎ネットワーク負荷状況判定テーブル５０１、サイト負荷状況判定テーブル６０１の詳細は、図８、９を参照して後述する。
【００３２】
図４は、監視サーバ６のハードウェア構成例を示すブロック図である。監視サーバ６は、一般的な計算機構成により実現できる。図４の例において、監視サーバ６は、メインメモリ１７０２、プロセッサ１７０３、ハードディスクドライブなどの二次記憶デバイス１７０５、ディスプレイやキーボードなどの入出力デバイス１７０７、他装置と接続するための通信デバイス１７０６及びそれらを接続する内部バス１７０４を含む。
【００３３】
例えば、監視サーバ６の各機能部（１５０２〜１５０８）は、二次記憶デバイス１７０５に格納され、実行時にメインメモリ１７０２にコピーされるプログラムを、解釈・実行するプロセッサ１７０３により実現できる。監視サーバ６は、パケット送受信を、通信デバイス１７０６を介して行う。更に各機能部（１５０２〜１５０８）が管理するデータは、メインメモリ１７０２に格納されるともに、永続的にデータを記憶するために二次記憶デバイス１７０５に格納される。監視サーバ６の各機能部（１５０２〜１５０８）の少なくとも一部は、ハードウェアロジック回路によって実現されてもよい。
【００３４】
図５は、ＭＭＥ２２の論理構成例を模式的に示すブロック図である。ＭＭＥ２２は、パケット送受信部１６０２、ユーザの位置情報等を管理するユーザ情報管理部１６０３、監視サーバ６とのインタフェース部１６０４及び基地局通知部１６０５を含む。これら機能部１６０２〜１６０５は、プログラムに従って動作するプロセッサ及び／又はハードウェアロジック回路によって実現される。
【００３５】
基地局通知部１６０５は、監視サーバ６からの要求に応じて、ユーザ情報管理部１６０３に管理された情報を検索し、ユーザ端末４が収容される基地局２１（ユーザ端末４が通信する基地局２１）を特定して監視サーバ６に通知する。ＭＭＥ２２は、一般に、これらの他、Ｓ−ＧＷ２３や基地局（ｅＮＢ）２１とのインタフェース等も含むが、本例に直接に関係しないため説明を省略する。
【００３６】
図６は、監視サーバ６が行う、ＴＣＰフロー解析によるボトルネック特定方法（推定方法）の例を示すフローチャートである。本例は、ユーザ端末４によるサービスサーバ５からのデータダウンロードにおける一つのＴＣＰフローの解析（ボトルネック特定）を示す。
【００３７】
図６に示すように、通信監視サーバ６のＴＣＰフロー検索・抽出部１５０４は、タップ１１から転送される解析対象のＴＣＰフローのデータを、所定時間収集する（Ｓ３０２）。同一ＴＣＰフローのパケットは、例えば、送信元ＩＰアドレス及びポート番号並びに宛先ＩＰアドレス及びポート番号で同定される。
【００３８】
次に、ＴＣＰフロー解析部１５０５は、ステップＳ３０２で収集されたデータ量（例えばデータパケット数）を、解析に必要な量として予め定めておいた閾値Ａと比較する（Ｓ３０３）。収集されたデータ量が閾値Ａより大きい場合（Ｓ３０３：ＹＥＳ）、ＴＣＰフロー解析部１５０５は、以降の解析ステップに進む。収集されたデータ量が閾値Ａ以下の場合（Ｓ３０３：ＮＯ）、ＴＣＰフロー解析部１５０５は、データ量不足により解析失敗と判定する（Ｓ３１１）。
【００３９】
ステップＳ３０４において、ＴＣＰフロー解析部１５０５は、対象ＴＣＰフローにおけるユーザ端末４からのＡｃｋパケットが受信されているか判定する。Ａｃｋパケットが受信されていない場合（Ｓ３０４：ＮＯ）、ＴＣＰフロー解析部１５０５は、ボトルネック解析は失敗（解析不能）と判定する（Ｓ３２１）。
【００４０】
Ａｃｋパケットが受信されていないのは、ユーザ端末４の不具合が理由の一つと考えられる。しかし、その他にも、サービスサーバ５からのダウンロードデータ（データパケット）がユーザ端末４へ到達する前に、キャリアネットワーク１３内で全て消失してしまった、又は、ユーザ端末４からのＡｃｋパケットがＰ−ＧＷ２４に到達する前に全て消失してしまった等の理由も考えられる。そこで、ＴＣＰフロー解析部１５０５は、キャリアネットワーク１３の状態確認を管理者用端末７に要求し（Ｓ３２２）、本フローを終了する。
【００４１】
ＴＣＰフロー解析部１５０５は、対象フローのＡｃｋパケットを検出すると（Ｓ３０４：ＹＥＳ）、通信速度を算出する（Ｓ３０５）。例えば、ＴＣＰフロー解析部１５０５は、Ａｃｋパケットに含まれるＡｃｋ番号を使用して通信速度を算出することができる。
【００４２】
Ａｃｋパケットは、データをどこのバイト位置までを受信したかを表すＡｃｋ番号フィールドを有している。このフィールドは、受信が完了したデータ位置のシーケンス番号＋１の値を格納している。ＴＣＰフロー解析部１５０５は、時間内に得た最初のＡｃｋパケットに含まれるＡｃｋ番号と最後のＡｃｋパケットに含まれるＡｃｋ番号の差分を所定時間で除することにより、通信速度を算出する。
【００４３】
更に、ＴＣＰフロー解析部１５０５は、対象ＴＣＰフローにおけるデータパケットの、ＴＣＰヘッダ内のシーケンス番号フィールドを監視する。ＴＣＰフロー解析部１５０５は、シーケンス番号の不連続性から、データパケットの損失を検出し、損失したデータパケットのシーケンス番号をメインメモリ１７０２のメモリ領域に記録する。
【００４４】
ここで、監視点、即ち、タップ１１を挿入した箇所よりも上流のネットワーク（ＩＰネットワーク１２）において失われたデータパケットの割合を、データ損失率（上流）として、下記のように定義する。
【００４５】
損失データパケット数１：検出された損失データパケットの数
総データパケット数１：所定時間内に通過したデータパケットにおける
最大シーケンス番号と最小シーケンス番号との差分
データ損失率（上流）：損失データパケット数１／総データパケット数１
【００４６】
ＴＣＰフロー解析部１５０５は、データ損失率（上流）を使用して、上流のネットワークがボトルネックである（又は上流のネットワークにボトルネックが存在する）か否かを判定する（Ｓ３０６）。具体的には、ＴＣＰフロー解析部１５０５は、上記定義に従ってデータ損失率（上流）を算出し、予め設定した閾値Ｂと比較する。
【００４７】
本判定結果は、フローチャートの後のステップにおけるボトルネック特定において参照される。後述するように、データ損失率（上流）が閾値Ｂより大きい場合（Ｓ３０６：ＮＯ）、ＴＣＰフロー解析部１５０５は、上流ネットワーク（ＩＰネットワーク１２）は、ボトルネックであると判定する。
【００４８】
さらに、ＴＣＰフロー解析部１５０５は、ユーザ端末４からのＡｃｋパケットのＡｃｋ番号フィールドの監視により、監視点より下流で損失したデータパケット数を算出する。ＴＣＰ通信では、送信側は同じＡｃｋ番号のＡｃｋパケットを３回受け取ると、そのシーケンス番号のデータパケットは失われたと判定し、該当するデータパケットを再送する。
【００４９】
そこで、ＴＣＰフロー解析部１５０５は、同じＡｃｋ番号のパケットを３回受け取ると、対応データパケットが上流又は下流のネットワークにおいて失われたと判定し、そのＡｃｋ番号をメモリ領域に記録する。
【００５０】
Ａｃｋパケットの解析により検出された損失データパケットから、上記データパケットの解析（シーケンス番号フィールドの監視）により検出した上流ネットワークにおける損失データパケットを除いた、残りの損失データパケットが、下流ネットワーク（キャリアネットワーク１３）で失われたデータパケットである。
【００５１】
ここで、監視点、即ち、タップ１１を挿入した箇所よりも下流のネットワーク（キャリアネットワーク１３）において失われたデータパケットの割合を、データ損失率（下流）として、下記のように定義する。
【００５２】
損失データパケット数２：下流ネットワークで失われたデータパケット数
総データパケット数２：総データパケット数１−損失データパケット数１
データ損失率（下流）：損失データパケット数２／総データパケット数２
【００５３】
ＴＣＰフロー解析部１５０５は、データ損失率（下流）を使用して、下流のネットワークがボトルネックである（又は下流のネットワークにボトルネックが存在する）か否かを判定する（Ｓ３０７、Ｓ３１６）。具体的には、ＴＣＰフロー解析部１５０５は、上記定義に従ってデータ損失率（下流）を算出し、予め設定した閾値Ｃと比較する。
【００５４】
本判定結果は、フローチャートの後のステップにおけるボトルネック特定において参照される。後述するように、データ損失率（下流）が閾値Ｃより大きい場合（Ｓ３０７、Ｓ３１６：ＮＯ）、ＴＣＰフロー解析部１５０５は、下流ネットワーク（キャリアネットワーク１３）は、ボトルネックであると判定する。
【００５５】
データ損失率（上流）及びデータ損失率（下流）のそれぞれが、対応する閾値未満である場合（Ｓ３０６、Ｓ３０７：ＮＯ）、ＴＣＰフロー解析部１５０５は、予め設定した速度判定用の閾値Ｄと対象ＴＣＰフローの通信速度（Ｓ３０５において算出）を比較する（Ｓ３０８）。
【００５６】
通信速度が閾値Ｄより速い場合（Ｓ３０８：ＹＥＳ）、ＴＣＰフロー解析部１５０５は、当該ＴＣＰフローの通信において、ボトルネックは存在しないと判定する（Ｓ３０９）。通信速度が閾値Ｄ以下の場合（Ｓ３０８：ＮＯ）、ＴＣＰフロー解析部１５０５は、本ＴＣＰフローにおいて受信したＡｃｋパケットのウインドウサイズ（広告ウィンドウサイズ）の平均値を、予め設定した閾値Ｅと比較する（Ｓ３１２）。図６のフローチャートは、広告ウインドウサイズの平均値を、広告ＷＳと表記している。
【００５７】
Ａｃｋパケットは広告ウインドウサイズのフィールドを有しており、そのフィールドの値が広告ウインドウサイズである。広告ウインドウサイズは、受信側が受け取れるパケットの量を示している。この値が小さい場合、受信側は少量のデータしか受け取る準備ができていない。したがって、広告ＷＳが閾値Ｅ以下である場合（Ｓ３１２：ＮＯ）、ＴＣＰフロー解析部１５０５は、受信側のユーザ端末４がボトルネックになっていると、判定する（Ｓ３１４）。
【００５８】
広告ＷＳが閾値Ｅよりも大きい場合（Ｓ３１２：ＹＥＳ）、受信側のユーザ端末４の状態は良好である。ＴＣＰフロー解析部１５０５は、ボトルネックは、ネットワーク１２、１３及び受信側のユーザ端末４以外の場所、即ち、サービスサーバ５であると判定する（Ｓ３１３）。この場合、サービスサーバ５が過負荷であり、レスポンスが遅くなっている、又は、サービスサーバ５が遠隔地にありプロトコルの制約から通信速度が遅くなっていることがボトルネックの原因と推定することができる。
【００５９】
データ損失率(上流)は低く（Ｓ３０６：ＹＥＳ）、データ損失率(下流)が高い（Ｓ３０７：ＮＯ）場合、ＴＣＰフロー解析部１５０５は、上流ネットワークは良好で、下流ネットワークがボトルネックであると判定する（Ｓ３１５）。
【００６０】
データ損失率(上流)が高く（Ｓ３０６：ＮＯ）、データ損失率(下流)が低い（Ｓ３１６：ＹＥＳ）場合、ＴＣＰフロー解析部１５０５は、下流ネットワークは良好で、上流ネットワークがボトルネックであると判定する（Ｓ３１７）。
【００６１】
更に、上流、下流双方のネットワークにおけるデータ損失率が高い場合（Ｓ３０６：ＮＯ、Ｓ３１６：ＮＯ）、ＴＣＰフロー解析部１５０５は、双方のネットワークがボトルネックであると判定する（Ｓ３１８）。
【００６２】
ネットワークにボトルネックがあると判定された場合において（Ｓ３１５、Ｓ３１７、Ｓ３１８）、ＴＣＰフロー解析部１５０５は、更に、広告ＷＳと閾値Ｅを比較する（Ｓ３１９）。広告ＷＳが閾値Ｅ以下であれば（Ｓ３１９：ＮＯ）、ＴＣＰフロー解析部１５０５は、ユーザ端末４もボトルネックであると判定する（Ｓ３２０）。
【００６３】
図６のフローチャートを参照して説明した処理により、監視サーバ６は、選択した１つのＴＣＰフローにおけるボトルネックを特定する、つまり、ボトルネックの有無を判定し、存在するボトルネックの位置を特定することができる。
【００６４】
上記フローにおいて判定のために使用される閾値に対して、設計により適切な値が選択される。例えば、閾値Ｂ、Ｃは同一でもよいし、異なる値であってもよい。閾値は、アクセス先サービスサーバに応じて定義されていてもよい。例えば、アクセス先サービスサーバの提供サービスに応じて設定されていてもよいし、特定の登録サーバに対して個別に設定されていてもよい。
【００６５】
上記フローにおける閾値と監視値との比較ステップの順序は、上記例と異なっていてもよい。データ損失率、通信速度は、異なる方法により計算されてもよい。例えば、監視サーバ６は、データ損失率の計算は、データパケットのパケット数及びパケットサイズを使用してもよい。監視サーバ６は、同一ユーザ端末、同一サービスサーバについて、複数ＴＣＰフローの測定を行い、それらの平均値と閾値とを比較して決定してもよい。
【００６６】
上記例は、ユーザ端末４、キャリアネットワーク１３、ＩＰネットワーク１２、サービスサーバ５のいずれかがボトルネックであるか否かを判定する。監視サーバ６は、キャリアネットワーク１３及びＩＰネットワーク１２のいずれかがボトルネックであるかのみを判定してもよく、キャリアネットワーク１３がボトルネックであるかのみを判定してもよい。
【００６７】
次に、図７を参照して、キャリアネットワーク１３（下流ネットワーク）の負荷状況及びサービスサイトの負荷状況を解析（判定）する方法を説明する。監視サーバ６が、この処理を行う。ここで説明するサービスサイトは、サービスサーバ群５が接続するＩＰネットワーク１２（上流ネットワーク）上のサイトである。サービスサイトは、同一のサービスを提供する１又は複数のサービスサーバ５を含んで構成される。監視サーバ６は、サービスサイトの識別子と、サービスサイトに含まれるサービスサーバの識別子を関連付ける情報を保持し、管理する。
【００６８】
監視サーバ６は、本処理において、図６を参照して説明したボトルネック特定（推定）方法を利用する。監視サーバ６は、複数のＴＣＰフローを選択し、上記ボトルネック推定方法により各ＴＣＰフローを解析する。監視サーバ６は、それらの推定結果を参照して、キャリアネットワーク１３の負荷状況及びサービスサイト５の負荷状況を特定（推定）する。
【００６９】
後述するように、監視サーバ６は、基地局毎に、キャリアネットワーク１３の負荷状況を推定する。つまり、監視サーバ６は、各基地局２１を経由する１又は複数のＴＣＰフローを上記ボトルネック推定方法により解析し、当該基地局２１を経由する通信におけるキャリアネットワーク１３の負荷状況を推定する。
【００７０】
監視サーバ６は、サービスサイトの負荷状況の解析において、サービスサイトに含まれるサービスサーバ５の１又は複数のＴＣＰフローを上記ボトルネック推定方法により解析し、その解析結果から当該サービスサイトの負荷状況を推定する。本例では、サービスサイトの負荷状況は、サービスサイトとの通信におけるＩＰネットワーク１２の負荷状況及びサービスサーバ５の負荷状況を含む。
【００７１】
図７は、監視サーバ６による、キャリアネットワーク１３の負荷状況及びサービスサイトの負荷状況を解析する処理のフローチャートである。図７のフローチャートが示すように、まず、ＴＣＰフロー検索・抽出部１５０４は、通信中の、ｎ本（ｎは１より大きい整数）のＴＣＰフローを選択する（Ｓ４０２）。ここでは、選択されるＴＣＰフローは、サービスサーバ群５からユーザ端末４へのダウンロードのＴＣＰフローである。
【００７２】
さらに、ＴＣＰフロー検索・抽出部１５０４は、選択した複数のＴＣＰフローの宛先ＩＰアドレス、即ちユーザ端末４のＩＰアドレスをデータパケットのＩＰヘッダから取得し、メッセージ送受信部１５０３に渡す。
【００７３】
メッセージ送受信部１５０３は、選択したＴＣＰフローのそれぞれが通過する基地局２１を、ＭＭＥ２２に問い合わせる（Ｓ４０３）。ＭＭＥ２２と監視サーバ６の間には、基地局問い合わせ用のインタフェースが存在している。メッセージ送受信部１５０３は、問い合わせるＴＣＰフローの本数と、各ＴＣＰフローの宛先ＩＰアドレス（ユーザ端末４のＩＰアドレス）を、ＭＭＥ２２に送信する。
【００７４】
ＭＭＥ２２はユーザ端末４の移動を管理しており、通信中のユーザ端末４が現在いずれの基地局２１に収容されているかを把握している。ＭＭＥ２２は、問い合わせを受け、受信した各ＩＰアドレスを割り当てられたユーザ端末４が収容されている基地局２１を示すＥＣＧＩ(Ｅ−ＵＴＲＡＮ  Ｃｅｌｌ  Ｇｌｏｂａｌ  Ｉｄｅｎｔｉｆｉｅｒ)を検索する。ＥＣＧIは基地局２１からの通信範囲であるセルの識別子であり、基地局２１の識別子を含む。ＭＭＥ２２は、検索により取得したＥＣＧＩを、対応する宛先ＩＰアドレスと関連付けて、監視サーバ６へ返信する。
【００７５】
メッセージ送受信部１５０３は、ＭＭＥ２２から、問い合わせＩＰアドレスと関連付けられたＥＣＧＩ（基地局情報）を受信する。監視サーバ６は、受信した基地局情報により、選択した各ＴＣＰフローを、対応する基地局２１に関連付けることができる。
【００７６】
次に、ＴＣＰフロー解析部１５０５は、カウンタ変数ｉに初期値として０を代入し（Ｓ４０５）、カウンタ変数ｉが整数ｎに達するまで（Ｓ４１０）、順次、選択したｎ本のＴＣＰフローを解析する（Ｓ４０６）。ＴＣＰフローの解析（Ｓ４０６）は、図６を参照して説明した通りである。
【００７７】
ステップＳ４０６おけるＴＣＰフローの解析が失敗の場合（Ｓ４０７）、ＴＣＰフロー解析部１５０５は、ステップＳ４１０に進む。ステップＳ４０６おけるＴＣＰフローの解析が成功すると（Ｓ４０７：ＹＥＳ）、ＴＣＰフロー解析部１５０５は、そのＴＣＰフローの解析結果を、基地局毎ネットワーク負荷状況推定部１５０６及びサイト負荷状況推定部１５０７に渡す。
【００７８】
基地局毎ネットワーク負荷状況推定部１５０６は、ステップＳ４０６の解析結果に応じて、基地局毎ネットワーク負荷状況判定テーブル５０１を更新する（Ｓ４０８）。サイト負荷状況推定部１５０７は、ステップＳ４０６の解析結果に応じて、サイト負荷状況判定テーブル６０１を更新する（Ｓ４０９）。
【００７９】
図８は、基地局毎ネットワーク負荷状況判定テーブル５０１の構成例を示している。基地局毎ネットワーク負荷状況判定テーブル５０１は、メインメモリ１７０２及び／又は二次記憶デバイス１７０５に格納される。
【００８０】
基地局毎ネットワーク負荷状況判定テーブル５０１は、基地局２１からＰ―ＧＷ２４（タップ１１）までの通信における、キャリアネットワーク１３（下流ネットワーク）の負荷状況の情報を保持する。各エントリは、キャリアネットワーク１３における、一つの基地局を経由する１又は複数のＴＣＰフローの解析についての情報を格納している。このように、基地局毎ネットワーク負荷状況判定テーブル５０１は、基地局毎にＴＣＰフロー解析及び負荷判定結果の情報を管理している。
【００８１】
基地局毎ネットワーク負荷状況判定テーブル５０１は、基地局の識別子を格納するカラム５０２、サンプル数を格納するカラム５０３、ボトルネックと判定された回数を格納するカラム５０４、負荷判定結果を格納するカラム５０５を有している。
【００８２】
サンプル数（カラム５０３）は、各エントリにおいて、ステップＳ４０６で解析が成功したＴＣＰフローの内、当該基地局を経由するＴＣＰフローの数を示す。ボトルネックと推定された回数（カラム５０４）は、各エントリにおいて、当該基地局を経由するＴＣＰフローの内、下流ネットワーク（キャリアネットワーク１３）がボトルネックであると判定されたＴＣＰフローの数を示す。
【００８３】
負荷判定結果（カラム５０５）は、各エントリにおいて、当該基地局を経由する通信における下流ネットワーク（キャリアネットワーク１３）の負荷状況の判定結果を格納する。基地局毎ネットワーク負荷状況推定部１５０６は、各エントリの負荷状況を判定する。判定方法は後述する。
【００８４】
ステップＳ４０８において、基地局毎ネットワーク負荷状況推定部１５０６は、ステップＳ４０６の結果に応じて、サンプル数のカラム５０３及びボトルネックと推定された回数のカラム５０４を更新する。具体的には、基地局毎ネットワーク負荷状況推定部１５０６は、対応する基地局２１のエントリにおいて、サンプル数（カラム５０３）をカウントアップし、ボトルネックと判定された場合に、ボトルネックと判定された回数（カラム５０４）をカウントアップする。
【００８５】
図９はサイト負荷状況判定テーブル６０１の構成例を示している。サイト負荷状況判定テーブル６０１は、メインメモリ１７０２及び／又は二次記憶デバイス１７０５に格納される。サイト負荷状況判定テーブル６０１は、予め登録されている登録サイトの負荷状況の情報を保持している。例えば、通信リクエストの多いサイトが予め登録されている。
【００８６】
各エントリは、１つの登録サイトからの１又は複数のＴＣＰフローの解析についての情報を格納している。各エントリは、当該サイトにおけるサービスサーバ（サーバ）５の負荷状況と上流のＩＰネットワーク（ＮＷ）１２の負荷状況を管理する。このように、サイト負荷状況判定テーブル６０１は、サイト毎に、ＴＣＰフロー解析及び負荷判定結果の情報を管理している。
【００８７】
サイト負荷状況判定テーブル６０１は、サイトの識別子を格納するカラム６０２、サンプル数を格納するカラム６０３、ボトルネックと判定された回数を格納するカラム６０４、負荷判定結果を格納するカラム６０５、基準通信速度の値を格納するカラム６０６を有している。
【００８８】
サンプル数（カラム６０３）は、各エントリにおいて、ステップＳ４０６で解析が成功したＴＣＰフローの内、当該サイトからのＴＣＰフローの数を示す。ボトルネックと推定された回数（カラム６０４）は、各エントリにおいて、当該サイトからのＴＣＰフローの内、サービスサーバ５がボトルネックであると判定されたＴＣＰフローの数（「サーバ」のセル）と、上流ネットワーク（ＩＰネットワーク１２）がボトルネックであると判定されたＴＣＰフローの数（「ＮＷ」のセル）と、を示す。
【００８９】
負荷判定結果（カラム６０５）は、各エントリにおいて、当該サイトとの通信におけるサービスサーバ５の負荷状況の判定結果（「サーバ」のセル）と、上流ネットワーク（ＩＰネットワーク１２）の負荷状況の判定結果（「ＮＷ」のセル）を示す。サイト負荷状況推定部１５０７が、各エントリ（サイト）の負荷状況を判定する。判定方法は後述する。
【００９０】
基準通信速度（カラム６０６）は、ユーザ端末４とサイトとの通信の通信速度の推定において参照される基準通信速度を示す。サイト負荷状況推定部１５０７が、サイトの負荷状況（上流ネットワーク又はサイトのサーバの負荷状況）に基づいて、基準通信速度を決定（推定）する。基準通信速度の推定方法は後述する。
【００９１】
ステップＳ４０９において、サイト負荷状況推定部１５０７は、ステップＳ４０６の結果に応じて、サンプル数のカラム６０３及びボトルネックと推定された回数のカラム６０４を更新する。具体的には、サイト負荷状況推定部１５０７は、対応するサイトのエントリにおいて、サンプル数（カラム６０３の値）をカウントアップし、ボトルネックと判定された場合に、ボトルネックと判定された回数（カラム６０４における「サーバ」又は「ＮＷ」のセルの値）をカウントアップする。
【００９２】
解析されたＴＣＰフローが、サイト負荷状況判定テーブル６０１に登録されていないサイトからのＴＣＰフローである場合、サイト負荷状況推定部１５０７は、ステップＳ４０９を省略する。
【００９３】
選択した全てのＴＣＰフロー（ｎ本のＴＣＰフロー）のステップＳ４０６による解析が終了すると（Ｓ４１０：ＹＥＳ）、基地局毎ネットワーク負荷状況推定部１５０６は、基地局毎にネットワーク負荷状況を判定する。基地局毎ネットワーク負荷状況推定部１５０６は、その判定結果に応じて基地局毎ネットワーク負荷状況判定テーブル５０１における負荷判定結果カラム５０５の値を更新する。同様に、サイト負荷状況推定部１５０７はサイト毎に負荷状況を判定し、サイト負荷状況判定テーブル６０１における負荷判定結果カラム６０５の値を更新する（Ｓ４１１）。
【００９４】
図１０は、基地局毎ネットワーク負荷状況推定部１５０６及びサイト負荷状況推定部１５０７による負荷状況の判定で参照される、判定基準７０１の一例を示している。閾値α及び閾値βを含む判定基準７０１は、予め設定されている。αはβよりも大きい。
【００９５】
本例において、基地局毎ネットワーク負荷状況推定部１５０６は、基地局毎ネットワーク負荷状況判定テーブル５０１の各エントリにおいて、サンプル数（カラム５０３）に対するボトルネックと判定された回数（カラム５０４）の割合と、閾値α、βとを比較する。
【００９６】
割合がαより大きい場合、基地局毎ネットワーク負荷状況推定部１５０６は、当該基地局２１の負荷状況は高負荷であると判定する。割合がβより小さい場合、基地局毎ネットワーク負荷状況推定部１５０６は、当該基地局２１の負荷状況は低負荷であると判定する。
【００９７】
割合がβとαとの間である場合、基地局毎ネットワーク負荷状況推定部１５０６は、当該基地局２１の負荷状況は中負荷であると判定する。各判定結果が、対応エントリのカラム５０５に格納される。サイト負荷状況推定部１５０７も、同様の方法により、各サイトのサーバ負荷状況及びネットワーク負荷状況を判定し、それら判定結果をカラム６０５に格納する。
【００９８】
本例において、閾値α、βは、下流ネットワーク及び上流ネットワークの負荷判定に共通であるが、基地局毎ネットワーク負荷状況推定部１５０６、サイト負荷状況推定部１５０７は異なる閾値を使用してもよい。サイト負荷状況推定部１５０７は、サーバ負荷判定とネットワーク負荷判定とに異なる閾値を使用してもよい。閾値は、登録サイト毎に設定されていてもよい。ボトルネックと判定された回数と所定閾値とを比較してもよい。
【００９９】
さらに、サイト負荷状況推定部１５０７は、各登録サイトの基準通信速度（カラム６０６）を決定する。例えば、各登録サイトに対して、各サーバ負荷状況に関連付けられている基準通信速度の値と、各ネットワーク負荷状況に関連付けられている基準通信速度の値が、予め設定されている。予め設定されている基準通信速度は、サーバ負荷状況とネットワーク負荷状況とに共通でもよい。
【０１００】
サイト負荷状況推定部１５０７は、当該サイトのエントリの判定結果カラム６０５から、サーバ負荷状況判定結果とネットワーク負荷状況判定結果を取得し、さらに、それらに関連付けられている基準通信速度を取得する。サイト負荷状況推定部１５０７は、取得した基準通信速度のうち、より遅い基準通信速度を選択して、当該エントリの基準通信速度カラム６０６に格納する。
【０１０１】
管理者は、管理者用端末７を介して監視サーバ６にアクセスし、これらの情報（基地局毎ネットワーク負荷状況判定テーブル５０１及びサイト負荷状況判定テーブル６０１が示す情報）を適宜取得する。これにより、管理者は管理下のネットワークの状況に加え、管理外のネットワークの状況を把握することができる。
【０１０２】
なお、図８及び図９は、基地局毎ネットワーク負荷状況及びサイト負荷状況を表形式で示すが、これらの情報の管理は表形式での管理に限定されず、これらの情報は、どのような形式であっても、適切に関連付けて管理されていればよい。この点は、本開示において、他の情報の管理方法について同様である。
【０１０３】
図７のフローチャートは、複数ＴＣＰフローの監視及びボトルネック推定処理（Ｓ４０６）を順次行うが、監視サーバ６は、ステップＳ４０６〜Ｓ４０９を並列して行ってもよい。基地局情報は、基地局毎ネットワーク状況判定テーブルの更新（Ｓ４０８）までに得られればよい。監視サーバ６は、ＭＭＥ２２からの基地局情報の受信（Ｓ４０４）を待たずに、ＴＣＰフローの監視及びボトルネック推定ステップ（Ｓ４０６）を行ってもよい。
【０１０４】
次に、ユーザ端末４のユーザへのネットワーク及びサイトの負荷状況の提示方法を説明する。管理者用端末７を使用する管理者に、同様の方法で同様の情報を開示してもよい。ユーザは、予めユーザ端末４にネットワーク状況提示用のアプリケーション（以下、アプリＡと表示する）をインストールしておく。アプリＡは、例えば、バックグラウンドでも動作する。
【０１０５】
アプリＡは、起動時、定期的又はユーザからの明示的な指示（ユーザ端末４の操作による指示）を受けると、監視サーバ６に負荷状況提示リクエストを送信し、ネットワーク及び代表サイトの負荷状況の情報を監視サーバ６から取得する。アプリＡは、ハンドオーバ時にリクエストを送信してもよい。ネットワークや代表サイトの負荷状況の変化を検出した監視サーバ６がユーザ端末４に通知を送り、この通知を契機にユーザ端末４（アプリＡ）が、リクエストを送信してもよい。これら全てのトリガでの負荷状況提示リクエストの送信を強制するものではなく、アプリＡは、選択的にリクエストを実行してもよい。
【０１０６】
図１１は、ユーザ端末４に対するネットワーク及び代表サイトの負荷状況提示のためのシーケンスを示す。ユーザ端末４と監視サーバ６との間の通信は、基地局２１、Ｓ−ＧＷ２３、Ｐ−ＧＷ２４を介して行われる。本シーケンスでは、リクエスト送信のトリガは、ユーザ端末４におけるアプリＡの起動（Ｓ８０１）である。その他のトリガでも、同様のシーケンスとなる。
【０１０７】
ユーザ端末４（アプリＡ）は基地局２１との通信状況を確認し（Ｓ８０２）、基地局２１との接続に問題がなければ（Ｓ８０２：ＹＥＳ）、監視サーバ６にネットワーク状況提示リクエストを送信する（Ｓ８０３）。問題があれば、本シーケンスは終了する。
【０１０８】
ユーザ端末４からのリクエストは、当該ユーザ端末の識別子（例えばＳＩＭ番号）及び通信している基地局２１の識別子を含む。アプリＡには、予め監視サーバ６のＩＰアドレスが設定登録されている。又は、監視サーバ６の名前が予め登録されており、アプリＡは、図に表記されていないＤＮＳサーバに監視サーバ６のＩＰアドレスを問い合わせ、ＤＮＳサーバから監視サーバ６のＩＰアドレスを入手してもよい。
【０１０９】
監視サーバ６は、負荷状況提示リクエストを受信すると、指定されている基地局２１の負荷状況判定結果を、基地局毎ネットワーク負荷状況判定テーブル５０１のカラム５０５から取得する。監視サーバ６は、さらに、サイト負荷状況判定テーブル６０１から、予め登録されている代表サイトの基準通信速度を、カラム６０６から取得する。代表サイトは、サイト負荷状況判定テーブル６０１に登録されているサイトの一部又は全てである。
【０１１０】
監視サーバ６は、基地局２１の負荷状況判定結果と、代表サイトの基準通信速度を基に、当該基地局２１利用時の、当該代表サイトの通信速度を算出する（Ｓ８０４）。監視サーバ６は、例えば、予め規定されている数式により当該基地局２１の負荷状況判定結果から係数を算出し、当該係数を代表サイトの基準通信速度に乗じて、推定通信速度を求める。
【０１１１】
次に、監視サーバ６は、算出した各代表サイトの推定通信速度と、当該基地局２１に対応するネットワーク負荷状況判定結果を、要求元ユーザ端末４へ通知する（Ｓ８０５）。ユーザ端末４（アプリＡ）は、端末自身が持つ当該基地局２１との間の受信品質情報等を基に、予め定められている関数により、各代表サイト推定通信速度を修正する（Ｓ８０６）。ユーザ端末４（アプリＡ）は、ネットワーク状況の情報及び代表サイト推定通信速度の情報（図１４に例示）を画面に表示する（Ｓ８０７）。
【０１１２】
図１２のフローチャートは、図１１に示すシーケンスにおいて、アプリＡ（ユーザ端末４）が行う処理例を示す。アプリＡは、基地局２１との通信接続状態を判定する（Ｓ９０２）。基地局２１接続が確認できると（Ｓ９０２：ＹＥＳ）、アプリＡは、監視サーバ６へ、負荷状況提示リクエストを送信する（Ｓ９０３）。
【０１１３】
アプリＡは、監視サーバ６から、ネットワーク状況の情報及び代表サイト推定通信速度を受信する（Ｓ９０４）。アプリＡは、端末４自身が持つ、基地局２１との通信における受信品質情報等を基に、代表サイト推定通信速度を修正する（Ｓ９０５）。このステップは省略されてもよい。アプリＡは、ネットワーク状況及び代表サイト推定通信速度を、ユーザ端末４の画面に表示する（Ｓ９０６）。
【０１１４】
例えば、アプリＡは、ユーザ端末４自身が保持する通信品質情報（例えば電波強度）を係数に変換し、それの係数を推定通信速度に乗じることにより、代表サイトの推定速度を修正する。アプリＡは、本修正を必要に応じて行う。基地局２１との接続が確認できなかった場合は（Ｓ９０２：ＮＯ）、アプリＡは、電波が届いているか否かを確認する（Ｓ９０８）。
【０１１５】
電波が届いている場合（Ｓ９０８：ＹＥＳ）、アプリＡは、更に基地局２１の切り替えが頻繁に行われているか否かを確認する（Ｓ９０９）。頻繁に基地局２１の切り替えが行われている場合（Ｓ９０９：ＹＥＳ）、アプリＡは、高速移動により基地局２１が頻繁に切り替えられ、安定した通信が行われていないと判定する。アプリＡは、例えば、「高速移動中のため、通信ができません。」等のメッセージを画面に表示する（Ｓ９１０）。
【０１１６】
基地局２１とは継続的に接続されているにも関わらず通信ができない場合（Ｓ９０９：ＮＯ）、アプリＡは、「基地局と接続できません。原因は不明です。」等のメッセージを画面に表示する（Ｓ９１１）。電波が届いていない場合（Ｓ９０８：ＮＯ）、アプリＡは、「圏外です。」等のメッセージを画面に表示する（Ｓ９１２）。
【０１１７】
図１３のフローチャートは、図１１に示すシーケンスにおいて、監視サーバ６が行う処理例を示す。メッセージ送受信部１５０３は、ユーザ端末４からリクエストを受信する（Ｓ１００１）。基地局毎ネットワーク負荷状況推定部１５０６又はサイト負荷状況推定部１５０７は、リクエストに含まれる基地局の識別子を取得し、当該基地局を介した各代表サイトとの通信における、推定通信速度を決定する（Ｓ１００２）。推定通信速度の計算方法は、図１１を参照して説明した通りである。メッセージ送受信部１５０３は、各代表サイトの推定通信速度と、指定基地局に対するネットワーク負荷状況の判定結果を、要求元ユーザ端末４へ通知する（Ｓ１００３）。
【０１１８】
図１４は、ユーザ端末４の画面における、ネットワーク状況の表示方法の一例を示している。表示画像は、現在のネットワーク負荷状況（セクション１１０２）や、代表サイトの推定通信速度（セクション１１０３）を表示する。現在の通信状況を示すセクション１１０２において、「ＡＡ」はキャリア名を表す。
【０１１９】
図１４のセクション１１０３の例において、代表サイトの推定速度は、速度レベル（遅い、普通、速い）で表されている。ユーザ端末４は、代表サイトに対して設定されている閾値と、監視サーバ６から取得した推定速度値とを比較して、推定通信速度のレベルを決定し、表示する。監視サーバ６が速度レベルで表された推定速度をユーザ端末４に送信してもよい。アクセスが多い代表サイトの情報により、ユーザ端末４のサービスサイトとの通信前でも、多くのエンドユーザに対して有効な情報を提示することができる。
【０１２０】
代表サイトの推定通信速度は、一つの数値でもよいし、５００Ｋｂｐｓ〜１Ｍｂｐｓのように数値範囲でもよい。セクション１１０２において、ネットワークの状況を表す言葉は設計に依存し、言葉とは異なる絵や色で表現されていてもよい。また、情報の表示は、表形式での表示に限定されない。ユーザ端末４は、代表サイトの情報を取得、表示しなくてもよい。
【０１２１】
本アプリケーションの表示画像は、縮小されて、画面上に常駐していてもよい。図１４に示すような全画面表示において、表示画像は、「ボトルネックの特定実行」のボタン１１０４、「表示を小さくする」のボタン１１０５、及び「状況提示アプリを終了する」のボタン１１０６等を含んでいてもよい。ユーザは、ユーザ端末４の入力デバイスによりボタンを選択して、所望の動作をユーザ端末４に指示することができる。
【０１２２】
次に、図１５は、ボトルネック特定リクエストの処理シーケンスを示している。ユーザ端末４と監視サーバ６との通信は、基地局２１、Ｓ−ＧＷ２３、Ｐ−ＧＷ２４を介して行われる。これにより、ユーザ端末４が実際に通信を行う特定のサービスサイトとの間の通信における混雑状況を、ユーザが知ることができる。ユーザは、図１４に示す画像における「ボトルネックの特定実行」のボタン１１０４を選択することで、ユーザ端末４に、ボトルネックの特定を指示することができる。
【０１２３】
アプリＡ（ユーザ端末４）は、ユーザからの指示に従って、ボトルネック特定リクエストを、監視サーバ６に送信する（Ｓ１２０１）。監視サーバ６のメッセージ送受信部１５０３は、ボトルネック特定リクエストを受信する。
【０１２４】
ＴＣＰフロー検索・抽出部１５０４は、リクエストから送信元ＩＰアドレス（ユーザ端末４のＩＰアドレス）を取得し、リクエスト受信後にタップ１１から転送された通信パケットにおいて、当該ユーザ端末４のＴＣＰフローを検索する（Ｓ１２０２）。具体的には、ＴＣＰフロー検索・抽出部１５０４は、当該ユーザ端末４のＩＰアドレスをヘッダに含むパケットのＴＣＰフローを検索する。
【０１２５】
ＴＣＰフロー検索・抽出部１５０４が、所定時間のデータ観測により、当該ユーザ端末４のＴＣＰフローを検出できない場合（Ｓ１２０３：ＮＯ）、メッセージ送受信部１５０３は、ボトルネック特定処理を行うことなく、処理の終了をユーザ端４末に通知する（Ｓ１２０７）。
【０１２６】
ＴＣＰフロー検索・抽出部１５０４が、所定時間のデータ観測により、当該ユーザ端末４のＴＣＰフローを検出すると（Ｓ１２０３：ＹＥＳ）、ＴＣＰフロー解析部１５０５は、検出したＴＣＰフローの監視及びボトルネック特定処理を実行する（Ｓ１２０４）。ＴＣＰフロー解析部１５０５は、図６のフローチャートを参照して説明したように、ステップＳ１２０４を実行する。
【０１２７】
例えば、監視サーバ６は、ユーザ端末４と同一サイトとの間の複数のＴＣＰフローを検出した場合、それらから選択した１つのＴＣＰフローを解析して、ボトルネックを特定する。また、監視サーバ６は、ユーザ端末４と複数サイトとの間のＴＣＰフローを検出した場合、各サイトのＴＣＰフローを解析し、ボトルネックを特定する。
【０１２８】
メッセージ送受信部１５０３は、ステップＳ１２０４の処理結果を、当該ユーザ端末４に通知する（Ｓ１２０５）。処理結果は、１又は複数のサイトとユーザ端末４との間の通信におけるボトルネックについての情報を含む。例えば、この結果は、ユーザ端末４及び通信先サイトの負荷状況（ボトルネックか否か）の情報を含む。
【０１２９】
更に、当該結果は、キャリアネットワーク１３やＩＰネットワーク１２の負荷状況（ボトルネックか否か）の情報を含んでいてもよい。通信先サイトの負荷状況の情報は、ＩＰネットワーク１２とサービスサーバ５の一方がボトルネックと判定された場合、当該サイトの負荷が高いことを示してもよい。
【０１３０】
ユーザ端末４のアプリＡは、受信した情報を画面に表示する（Ｓ１２０６）。図１６は、ユーザ端末４の画面における、ボトルネックについての情報である、ボトルネック評価結果１３０１の表示例を示している。ユーザ端末４、キャリアネットワーク１３、通信先サイトの状況を表示する。図１６の例において、ＡＡネットワークはキャリアネットワーク１３に対応し、ユーザ端末４と二つのサイトＪＪ、ＫＫとの間のボトルネック評価結果が示されている。
【０１３１】
図１６の例において、「状況」カラムにおける「良好」は、当該要素が、ボトルネックではないと判定された（評価された）ことを示す。同一要素がボトルネックであると判定された場合、当該要素の「状況」カラムの表記は、例えば、「不良」である。
【０１３２】
「状況」カラムにおける「低負荷」は、当該サイトがボトルネックではないと判定された（評価された）ことを示し、「高負荷」は、当該サイトがボトルネックであると判定された（評価された）ことを示す。ボトルネック判定結果の表現方法は、本例に限定されない。また、図１７に示すように、ユーザ端末４は、簡略化したネットワーク画像１４０１を用いて、視覚的に分かりやすい表現形式で、ボトルネック箇所を示してもよい。図１７の例において、ボトルネック箇所はＪＪサイトであり、当該サイトが「混雑している」ことが示されている。
【０１３３】
本実施例により、ユーザ端末のユーザ及びネットワーク管理者は、ｅｎｄ−ｔｏ−ｅｎｄの通信状況を把握することが可能になる。特に、管理されたネットワーク及び管理外のネットワークが接続して構成されるネットワークシステムにおいて、管理されたネットワークの管理者が、ユーザ端末から接続先のサービスサーバまでを含めたｅｎｄ−ｔｏ−ｅｎｄのネットワークの混雑状況を把握することができる。
【０１３４】
ユーザ端末のユーザは、通信先となるサービスサイトの状態が分かるため、通信状態の悪いサービスサイトへのアクセスを停止し、ネットワークに無駄な負荷を与えることを避けることができる。ユーザ端末のユーザは、通信状況が悪い時に、通信速度の遅い原因がどこにあるかを知ることができる。また、特定サービスサイトへのアクセスにおいて、通信当初は早かった通信速度が時間の経過や場所の変化により遅くなってしまった場合も、エンドユーザは経路上のどこにその原因があるのかを知ることができる。
【０１３５】
ユーザ端末のユーザは、通信開始前又は通信開始後にネットワークや通信先サービスサイトの混雑状況を知ることができる。これにより、ユーザは、利用しようとしているサービスサイト又はネットワークが混雑していれば、当該サービスサイトの利用を後にずらす、混んでいない他のサービスサイトを利用する等の対処が可能になる。
【０１３６】
なお、上記例は、負荷状況を基地局単位で扱ったが、基地局に複数のセルが存在する場合、基地局をセルに読み替えて各処理を行うことにより、負荷状況をセル単位で扱ってもよい。図１５を参照して説明したシーケンスにおいて、監視サーバ６はリクエスト受けた後のＴＣＰフローを解析しているが、リクエストを受ける前に受信したＴＣＰフローを解析してもよい。タップ１１は、異なるネットワークの接続点に設置されていれば、同一管理者の２つのネットワークの接続点に設置されていてもよい。
【実施例２】
【０１３７】
本発明は、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）無線方式、２Ｇ（２ｎｄ  Ｇｅｎｅｒａｔｉｏｎ）無線方式といった、ＬＴＥとは世代の異なる無線方式にも適用できる。図１８は、３Ｇのネットワーク構成例を示す。
【０１３８】
３Ｇネットワーク構成においては、ＢＳ（Ｂａｓｅ  Ｓｔａｔｉｏｎ）１８０１及びＲＮＣ(Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ)１８０２が、端末終端装置群９に含まれる端末終端装置に相当する。ＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）１８０４、ＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）１８０５、及びＨＬＲ（Ｈｏｍｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）１８０３は、通信装置群８の通信装置に相当する。
【０１３９】
図１９は、２Ｇ無線方式のネットワーク構成例を示す。２Ｇネットワーク構成においては、ＢＴＳ（Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｔａｔｉｏｎ）１９０１及びＢＳＣ(Ｂａｓｅ  Ｓｔａｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ)１９０２が、端末終端装置群９における端末終端装置に相当する。通信装置群８は３Ｇと同じである。
【０１４０】
２Ｇ及び３Ｇの無線方式では、ＨＬＲ１８０３、１９０３が、ユーザ端末４の位置情報データベースを保持しており、ユーザ端末４がどの基地局１８０１、１９０１下にあるかを把握している。このため、監視サーバ６は、ＨＬＲ１８０３に監視対象のＴＣＰフローの基地局１８０１、１９０１を問い合わせることにより、ＬＴＥの構成と同様に、ネットワーク状況の把握及びボトルネックの特定が可能になる。
【実施例３】
【０１４１】
図２０は、本発明をＷｉＭＡＸ(登録商標、以下同)に適応した例である。ＷｉＭＡＸでは、ＡＳＮ（Ａｃｃｅｓｓ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ）が端末終端装置群９に相当し、ＣＳＮ（Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ）が通信装置群８に相当する。
【０１４２】
ＡＳＮは、ＢＳ（Ｂａｓｅ  Ｓｔａｔｉｏｎ）２００１及びＡＳＮ−ＧＷ（Ａｃｃｅｓｓ  Ｓｅｒｖｉｃｅ  Ｎｅｔｗｏｒｋ  Ｇａｔｅｗａｙ）２００２を含んで構成され、ＣＳＮは、ＧＷ２００４やＨＡ（Ｈｏｍｅ  Ａｇｅｎｔ）２００３、本図には表記されていないＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ、Ａｕｔｈｏｒｉｚａｔｉｏｎ、ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ）サーバ等を含んで構成される。
【０１４３】
本構成においては、ＡＳＮ−ＧＷ２００２がユーザ端末４の位置情報を保持している。監視サーバ６は、ＡＳＮ−ＧＷ２００２に基地局２００１の情報を問い合わせることにより、ＬＴＥの構成と同様に、ネットワーク状況の把握及びボトルネックの特定が可能になる。
【実施例４】
【０１４４】
本発明は、無線端末を含むシステムや、キャリアネットワークを含むシステムに限定されるものではなく、有線端末を含むシステムや、イントラネットを含むシステムにも適用可能である。
【０１４５】
図２１は、管理下ネットワーク１としてイントラネット２０１を含むネットワーク構成例を示す。イントラネット２０１と外部のＩＰネットワーク１２の接続点に、タップ１１が設置されている。タップ１１は、監視サーバ６と接続する。
【０１４６】
ユーザ端末４は、無線又は有線により、本図では省略されている無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）アクセスポイントやルータ等を介して、ＧＷ２１０２に接続する。本構成により、イントラネットを含むシステムにおいて、実施例１において説明したＴＣＰフローの監視及びボトルネックの特定が可能である。
【実施例５】
【０１４７】
本実施例は、管理下のネットワークが２つの外部ネットワークに接続する、多段接続ネットワークにおけるボトルネックの特定方法を説明する。図２２は、本実施例のシステム構成例を示す。本構成例において、管理下のネットワーク１は、外部（管理外）のＩＰネットワーク１２及び管理外アクセスネットワーク３と接続している。管理下のネットワーク１は、ＩＰネットワーク１２と管理外アクセスネットワーク３との間にある。
【０１４８】
ユーザ端末４は管理外アクセスネットワーク３に接続し、管理外アクセスネットワーク３及び管理下のネットワーク１を介して、ＩＰネットワーク１２上のサービスサイトにアクセスする。本例において、三つのネットワーク１、３、１２の管理者が異なる。
【０１４９】
管理下のネットワーク１は、ＩＰネットワーク１２との接続点にタップ１１ａを有し、管理外アクセスネットワーク３との接続点にタップ１１ｂを有する。管理下のネットワーク１は、さらに、通信装置群２２０１及び監視サーバ６ａ、６ｂを含む。監視サーバ６ａ、６ｂは、１つの監視装置である。監視サーバ６ａは、タップ１１ａにおけるＴＣＰフローを監視、解析する。監視サーバ６ｂは、タップ１１ｂにおけるＴＣＰフローを監視、解析する。監視サーバ６ａ及び監視サーバ６ｂは、ＴＣＰフローの解析結果を互いに通信することができる。
【０１５０】
監視サーバ６ａ、６ｂの一方又は双方は、ユーザ端末４とサービスサーバ５との間の通信におけるボトルネックを特定する。例えば、監視サーバ６ｂは、図６を参照して説明した方法によりタップ１１ｂから受信したＴＣＰフローを解析することで、タップ１１ｂより下流の管理外アクセスネットワーク３が、ボトルネックであるか否かを判定することができる。
【０１５１】
一方、監視地点（タップ１１ｂ）よりも上流のネットワーク（管理下のネットワーク１及びＩＰネットワーク１２からなる）がボトルネックである場合、監視サーバ６ｂは、管理下のネットワーク１と外部ＩＰネットワーク１２のいずれがボトルネックであるかを判定することができない。
【０１５２】
そこで、監視サーバ６ａは、タップ１１ａにおけるＴＣＰフローの監視及び解析によって得られた損失パケットの情報を、監視サーバ６ｂに提供する。監視サーバ６ｂは、監視サーバ６ｂ自身によるＴＣＰフローの監視及び解析により得た損失パケットの情報と監視サーバ６ａから得た損失パケットの情報を比較することにより、管理下のネットワーク１内で損失したパケット数を算出する。
【０１５３】
例えば、監視サーバ６ａは、図６を参照して説明した方法によりタップ１１ａから受信したパケットを解析し、特定のＴＣＰフローにおいて、タップ１１ａより上流で失われたパケットの数（損失パケット数Ａ）を特定する。監視サーバ６ａ、６ｂは、解析を行うＴＣＰフローの識別子を、通信により予め共有する。
【０１５４】
監視サーバ６ａは、上記損失パケット数Ａを、監視サーバ６ｂに通知する。この損失パケット数Ａは、ＩＰネットワーク１２での損失パケット数である。監視サーバ６ａは、損失パケット数Ａから算出されるデータ損失率を予め定められている閾値と比較することで、ＩＰネットワーク１２がボトルネックであるか否かを判定する。
【０１５５】
監視サーバ６ｂは、図６を参照して説明した方法によりタップ１１ｂから受信したパケットを解析し、上記特定ＴＣＰフローにおいて、タップ１１ｂより上流で失われたパケットの数を（損失パケット数Ｂ）を特定する。
【０１５６】
上記損失パケット数Ｂは、ＩＰネットワーク１２及び管理下のネットワーク１で失われたパケット数である。監視サーバ６ｂは、損失パケット数Ｂから損失パケット数Ａを減ずることにより、管理下のネットワーク１で失われたパケット数を算出する。
【０１５７】
監視サーバ６ｂは、管理下のネットワーク１におけるパケット損失数から算出されるデータ損失率を予め定められている閾値と比較することで、管理下のネットワーク１がボトルネックであるか否かを判定する。監視サーバ６ａ、６ｂは、判定結果を通信することで、ボトルネックの情報を共有する。
【０１５８】
本実施例によれば、管理下のネットワークに接続する上流及び下流の管理外ネットワークが存在する場合にも、管理下のネットワークがボトルネックであるか否かを適切に判定することができる。さらに、上流及び下流の管理外ネットワークがボトルネックであるか否かを適切に判定することができる。
【０１５９】
なお、監視サーバ６ｂに代わり、監視サーバ６ａが、管理下のネットワーク１のボトルネック判定を行ってもよい。監視サーバ６ｂは、特定のＴＣＰフローにおいて、タップ１１ｂより上流で失われたパケットの数を（損失パケット数Ｂ）を監視サーバ６ａに通知する。監視サーバ６ａは、当該ＴＣＰフローにおいて、タップ１１ａより上流で失われたパケットの数（損失パケット数Ａ）を特定する。監視サーバ６ａは、損失パケット数Ｂから損失パケット数Ａを減ずることで、管理下のネットワーク１で失われたパケット数を算出する。
【０１６０】
同様に、監視サーバ６ａ、６ｂがＴＣＰフロー解析の結果を通信することにより、いずれの監視サーバがいずれのネットワークのボトルネックについての判定を行ってもよい。監視サーバ６ａ、６ｂは、それらの解析結果を利用することで、実施例１において説明した他の処理を行うことができる。
【実施例６】
【０１６１】
本実施例は、ユーザ端末４からサービスサーバ５へのデータのアップロードフローの解析方法を説明する。実施例１は、サービスサーバ５からユーザ端末４へのデータのダウンロードフローを解析した。ユーザ端末４からアクセスサーバ５へのデータのアップロードフローについても、同様の解析が可能である。
【０１６２】
図２３は、アップロードＴＣＰフローの解析によるボトルネック特定のフローチャートを示す。以下において、実施例１において図６が示すダウンロードＴＣＰフローの解析によるボトルネック特定のフローチャートとの差異を説明する。
【０１６３】
アップロードＴＣＰフローの向き、ダウンロードＴＣＰフローの向きと逆である。そのため、ステップＳ３１３ｂ、３１４ｂ、３０２ｂにおけるボトルネック判定において、サービスサーバとユーザ端末とが、入れ替わっている。
【０１６４】
また、図６のフローチャートにおいては、ＩＰネットワーク１２が上流ネットワークであり、キャリアネットワーク１３が下流ネットワークである。図２３においては、ＩＰネットワーク１２が下流ネットワークであり、キャリアネットワーク１３が上流ネットワークである。なお、理解の容易のため、図２３は、上流ネットワークを端末側ＮＷと表記し、下流ネットワークをサーバ側ＮＷと表記している（Ｓ３０６ｂ、Ｓ３０７ｂ、Ｓ３１５ｂ〜Ｓ３１８ｂ）。
【０１６５】
図２３が示すアップロードＴＣＰフロー解析における各ステップの動作は、図６が示すダウンロードＴＣＰフロー解析と同様である。図２３のフローチャートに従ったＴＣＰフロー解析により、アップロードのトラフィックにおいても、ボトルネックを特定し、ネットワーク及びサイトの状況を監視することができる。
【０１６６】
図２４は、ユーザ端末４の画面における表示画像一例２４０１を示す。画像２４０１は、代表サイトの推定通信速度を、ダウンロードとアップロードを別々に示す。これにより、ユーザは、ダウンロード及びアップロードのそれぞれの通信状況を知ることができる。画像２４０１の他の項目については、図１４を参照した説明と同様である。
【実施例７】
【０１６７】
本実施例は、ユーザ端末４からのフィードバックによる、通信速度の推定精度の向上方法を説明する。図１１を参照して説明したように、ユーザ端末４は、負荷状況提示リクエストを監視サーバ６に送信し、代表サイトの推定通信速度を受信する。
【０１６８】
ユーザ端末４は、その後、実際に上記代表サイトと通信を行った際に、当該サイトとの間の通信速度を測定する。ユーザ端末４による通信速度測定は広く知られた技術であり、ここでの詳細説明を省略する。ユーザ端末４は、通信速度を測定した代表サイトの識別子及び測定結果（以下、実効速度）の情報を、監視サーバ６に通知する。
【０１６９】
監視サーバ６（基地局毎ネットワーク負荷状況推定部１５０６又はサイト負荷状況推定部１５０７）は、通知された実効速度と監視サーバ６が推定した当該代表サイトの通信速度を比較する。例えば、実効速度と推定速度の差が、規定の閾値を超える場合、監視サーバ６は、各種閾値を調整する。
【０１７０】
例えば、推定速度＞実効速度であり、その差分が規定の閾値より大きい場合、監視サーバ６は、図６における閾値Ｂや閾値Ｃを下げる。これにより、ネットワークやサイトがボトルネックと判定されやすくなり、推定速度が下げられる。又は、監視サーバ６は、図１０における閾値α及び／又は閾値βを下げる。これにより、対象要素の負荷が高い（低くない）と判定されやすくなり、推定速度が下げられる。
【０１７１】
推定速度＜実効速度であり、その差分が規定の閾値より大きい場合、監視サーバ６は、図６における閾値Ｂ及び閾値Ｃを上げる。これにより、ネットワークやサイトがボトルネックと判定されにくくなり、推定速度が上がる。又は、監視サーバ６は、図１０における閾値α及び／又は閾値βを上げる。これにより、対象要素の負荷が低い（高くない）と判定されやすくなり、推定速度が上げられる。
【０１７２】
本実施例により、ボトルネックの判定基準を適切に調整することができ、ネットワークの状況解析やボトルネック特定の精度が向上する。なお、監視サーバ６は、上記全ての閾値を調整してもよいし、閾値の調整を選択的に行ってもよい。ユーザ端末４が上記推定速度と実行速度とを比較し、その比較結果に応じて実行速度を監視サーバ６に送信するか否かを判定してもよい。
【実施例８】
【０１７３】
本実施例は、ＵＤＰトラフィック（ＵＤＰパケット）の監視及び解析により、管理下のネットワーク１の状況を判定する。ＵＤＰパケットは、ＴＣＰパケットと異なり、シーケンス番号、ウインドウサイズを含まない。また、ＵＤＰプロトコルは、Ａｃｋパケットを使用しない。
【０１７４】
図２５は、本実施例のシステム構成例を示している。管理下のネットワーク１は、管理外のネットワーク２との接続点にタップ１１ａを有し、管理外のアクセスネットワーク３の接続点にタップ１１ｂを有する。
【０１７５】
管理下のネットワーク１は、さらに、通信装置群２５０１及び監視サーバ６ａ、６ｂを含む。監視サーバ６ａは、タップ１１ａにおけるＵＤＰパケットを監視、解析する。監視サーバ６ｂは、タップ１１ｂにおけるＵＤＰを監視、解析する。監視サーバ６ａ及び監視サーバ６ｂは、ＵＤＰパケットの解析結果を互いに通信することができる。監視サーバ６ａ、６ｂは１つの監視装置である。
【０１７６】
監視サーバ６ａは、監視対象のユーザ端末４ａへ向かうＵＤＰパケットを監視する。監視サーバ６ａと監視サーバ６ｂとは、連携して、管理外のアクセスネットワーク３に接続するユーザ端末４ｂへ向かうＵＤＰパケットを監視、解析する。
【０１７７】
ユーザ端末４ａは、管理下のネットワーク１の端末終端装置群９に接続する。ユーザ端末４ａを終端する端末終端装置９は、所定の時間内に当該端末終端装置９がユーザ端末４ａへ送信したパケット数を、監視サーバ６ａに通知する。
【０１７８】
監視サーバ６ａは、ユーザ端末４ａを終端している上記端末終端装置９からその識別子を取得し、所定の時間内にタップ１１ａから受信したパケットにおいて、ユーザ端末４ａへのＵＤＰパケットであって、上記端末終端装置９に転送されたパケットを特定し、転送されたパケット数をカウントする。
【０１７９】
管理下のネットワーク１内で失われたパケット数の割合（データ損失率）は、次の数式で表される。
【０１８０】
（監視サーバ６ａが検出したパケット数−端末終端装置９が送信したパケット数）
／監視サーバ６ａが検出したパケット数
【０１８１】
監視サーバ６ａは、この式によって求められる値を、予め設定していた閾値と比較することにより、管理下のネットワーク１がボトルネックとなっているか否を判定する。割合がその閾値よりも大きい場合に、監視サーバ６ａは、管理下のネットワーク１がボトルネックであると判定し、閾値以下の場合に管理下のネットワーク１がボトルネックではないと判定する。
【０１８２】
本実施例によれば、ＵＤＰトラフィック（ＵＤＰパケット）の監視及び解析により、管理下のネットワーク１の状況を判定することができる。なお、端末４ｂの通信についても、監視サーバ６ａ、６ｂの連携によりネットワークのボトルネック判定が可能である。
【実施例９】
【０１８３】
本実施例は、ユーザ端末４への負荷状況の通知をユーザ端末４による複数経路からの使用経路の選択に応用した例を示す。図２６は、本実施例におけるネットワークの構成例を示している。本例において、キャリアは、複数の無線方式を提供している。
【０１８４】
キャリアネットワーク１３は、無線方式ａによる接続を提供するための基地局ａ２６０１ａ及び通信装置群ａ２６０２ａ、無線方式ｂによる接続を提供するための基地局ｂ２６０１ｂ及び通信装置群ｂ２６０２ｂ、無線方式ｃによる接続を提供する通信装置群ｃ２６０１ｃを含む。キャリアネットワーク１３は、さらに、監視サーバ６及び管理者用端末７を含む。
【０１８５】
各通信装置群２６０２は、外部のＩＰネットワーク１２に接続する。サービスサーバ５は、ＩＰネットワーク１２に接続する。無線方式ｃの基地局ｃ２６０１ｃは、キャリアとは別のネットワークアクセスサービスの提供者が提供する装置である。ユーザ端末４は、全ての無線方式に対応する。図２３の構成例は３つの無線方式を提供するが、提供される無線方式の数は特定の値に限定されるものではなく、３未満でも３より多くてもよい。
【０１８６】
図２７は、ユーザ端末４からの負荷状況提示リクエストに対応したシーケンスを示す。ユーザ端末４は、予め設定されているデフォルトの無線方式を利用して、監視サーバ６に、負荷状況提示リクエストを送信する（Ｓ２７０１）。ここでは、無線方式ａをデフォルトの無線方式とする。リクエストは、ユーザ端末識別子、並びに、ユーザ端末４が検出した無線方式及び基地局識別子の複数の組、を含む。
【０１８７】
ユーザ端末４が接続可能（収容可能）として検出した基地局２６０１と無線方式の組が、送信される。監視サーバ６は、通知された基地局２６０１に対応する負荷状況の情報を、基地局毎ネットワーク負荷状況判定テーブル５０１において検索する（Ｓ２７０２）。
【０１８８】
監視サーバ６は、検索結果に基づき、ユーザ端末４に必要な情報を通知する（Ｓ２７０３）。監視サーバ６がユーザ端末４に通知する情報は、（無線方式、基地局識別子、キャリネットワークの状況（混雑度、推定通信速度）の組と、代表サイトの状況（負荷状況）を含む。ユーザ端末４は、この通知を受けて、ネットワーク状況及び代表サイトの推定通信速度を画面に表示する（Ｓ２７０４）。
【０１８９】
上述のように、混雑状況は、負荷状況により決まる。監視サーバ６は、基地局毎ネットワーク負荷状況判定テーブル５０１のカラム５０５から、リクエストが示す基地局の負荷判定結果を取得する。例えば、負荷判定結果が低負荷の場合、混雑度は低く、負荷判定結果が高負荷の場合、混雑度は高い。
【０１９０】
監視サーバ６は、指定基地局の負荷判定結果と、その基地局の無線通信方式から、通信速度を推定する。例えば、監視サーバ６には、負荷判定結果と無線通信方式との各組に対応する推定通信速度が予め登録されている。監視サーバ６には、リクエストにより指定された基地局の負荷判定結果と、リクエストにより指定された無線通信方式と、の組から、推定通信速度を決定する。なお、管理下の各基地局とその無線通信方式を対応付ける情報が監視サーバ６に予め登録されていてもよい。その場合、ユーザ端末４から監視サーバ６への無線通信方式の通知は不要である。
【０１９１】
図２８はユーザ端末４の画面に表示されるネットワークの状況についての情報の一例を示す。図２８の画像例は、経路の識別に無線方式名を用いるが、ユーザ端末４は、これと異なる無線方式の識別子（例えばサービス名）を使用してもよい。図２８の例において、セクション２８０２は、監視サーバ６から受信した、基地局２６０１を含むキャリアネットワーク１３の混雑度と推定通信速度、を表示している。推定通信速度は、例えば、数値で表されている。
【０１９２】
更に、ユーザ端末４は、無線方式毎の注意事項、例えば公衆無線ＬＡＮであれば、「高速移動には適さない」や、ユーザによる無線方式の利用に合わせたメッセージを表示してもよい。これらの情報は、ユーザ端末４に予め記憶されている。ユーザ端末４は、ネットワーク状況２８０２及びネットワークの決定ボタン２８０３の他に、サービスサイトの状況２８０４、ボトルネック特定の実行ボタン２８０５、全面表示から縮小表示に切り替えるボタン２８０６、アプリケーションの終了ボタン２８０７等も表示してもよい。
【０１９３】
図２８の例において、サービスサイトの状況のセクション２８０４は、代表サイトの混雑状況を示す。代表サイトの混雑状況は、図１４に示す代表サイトの負荷状況に対応する。例えば、「高負荷」、「中負荷」、「低負荷」が、それぞれ、「混雑」、「普通」、「良好」に対応する。ボタン２８０５〜２８０７は、図１４を参照して説明したボタン１１０４〜１１０６と同様である。
【０１９４】
ユーザが、インタフェースにより、使用するネットワーク（無線方式）を選択し、ネットワーク決定ボタン２８０３を選択すると、ユーザ端末４は、使用する通信デバイスを、選択した無線方式に対応する無線通信デバイスへ切り替える。図２８において、キャリアネットワーク１３の混雑度と推定通信速度が別々に示されている。これは、混雑度と推定速度の関係が無線方式によって異なるためである。例えば、ＬＴＥの通信速度は、その混雑度が高くても、３Ｇ通信の通信速度より速い場合もある。
【０１９５】
図２８の画像例は、基地局の状況まで含むキャリアネットワークの状況を示している。図２９は、他の表示画像例２９０１を示している。表示画像例２９０１は、基地局の状況とネットワークの状況を分離して示している。ユーザ端末４は、基地局の混雑度を、例えば、基地局の管理装置又は基地局から入手する。
【０１９６】
図２８の画像例は、ネットワークの状況を表形式で表示する。図３０は、他の画像例３００１を示す。表示画像３００１は、ユーザがイメージをつかみやすくするために、簡略化したネットワーク図を示す。図３０において、「ＡＡ」にはキャリア名、「ＢＢ」はアクセスネットワークの提供者名を表す。
【０１９７】
図３１は、ネットワーク状況を示す他の画像例３１０１〜３１０３を示す。表示画像３１０１〜３１０３は、縮小表示された画像であり、ユーザ端末４は、その画面に、常に表示画像３１０１〜３１０３のいずれかを表示する。図３１の例は、それぞれが方式名とネットワーク状況の対を示す画像３１０１〜３１０３を、順番に表示する。これにより、ネットワークの状況を通知する。
【０１９８】
図３２はボトルネック特定結果を含む表示画像例３２０１を示す。表示画像３２０１は、セクション３２０２及び３２０３を含む。セクション３２０２は、簡略化したネットワーク図を用いて、ボトルネック特定結果を表示する。ユーザ端末４は、図１６のように、表形式で表示してもよい。
【０１９９】
セクション３２０３は、選択可能な経路を示す。ユーザ端末４は、例えば、ボトルネックが存在する場合に、ボトルネックの通知（セクション３２０２）と共に、選択可能な経路（セクション３２０３）を示す。これにより、ユーザは、ボトルネックを回避した経路を容易に選択できる。
【０２００】
ユーザは、セクション３２０３において使用する経路を選択し、さらに、「変更する」ボタン３２０４を選択する。ユーザ端末４は、ユーザからの入力に応答して、選択された無線方式の通信デバイスに、使用デバイスを切り替える。
【０２０１】
本実施例によれば、ユーザ端末４のユーザは、キャリアが提供する複数の経路の中から、適切な経路、例えば、ｅｎｄ−ｔｏ−ｅｎｄの通信品質が最も良い経路を選択することができる。また、ユーザは、ネットワークやサービスサイトが混んでいる時に無駄な通信を行うことなく、空いている時間帯に通信することができる。更に、ユーザが混雑していない経路を選択することにより、キャリアが提供する複数経路の利用率の平滑化が期待できる。
【０２０２】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０２０３】
また、上記の各構成・機能・処理部等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実効することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード等の記録媒体に置くことができる。
【符号の説明】
【０２０４】
１  管理下のネットワーク、２  管理外のネットワーク、３  管理外のアクセスネットワーク、４  ユーザ端末、５  サービスサーバ群、６  監視サーバ、７  管理者用端末、８  通信装置群、９、１０  端末終端装置群、１１  タップ、１２  ＩＰネットワーク、１３  キャリアネットワーク
【図１】
2014179827.tif 000003
【図２】
2014179827.tif 000004
【図３】
2014179827.tif 000005
【図４】
2014179827.tif 000006
【図５】
2014179827.tif 000007
【図６】
2014179827.tif 000008
【図７】
2014179827.tif 000009
【図８】
2014179827.tif 000010
【図９】
2014179827.tif 000011
【図１０】
2014179827.tif 000012
【図１１】
2014179827.tif 000013
【図１２】
2014179827.tif 000014
【図１３】
2014179827.tif 000015
【図１４】
2014179827.tif 000016
【図１５】
2014179827.tif 000017
【図１６】
2014179827.tif 000018
【図１７】
2014179827.tif 000019
【図１８】
2014179827.tif 000020
【図１９】
2014179827.tif 000021
【図２０】
2014179827.tif 000022
【図２１】
2014179827.tif 000023
【図２２】
2014179827.tif 000024
【図２３】
2014179827.tif 000025
【図２４】
2014179827.tif 000026
【図２５】
2014179827.tif 000027
【図２６】
2014179827.tif 000028
【図２７】
2014179827.tif 000029
【図２８】
2014179827.tif 000030
【図２９】
2014179827.tif 000031
【図３０】
2014179827.tif 000032
【図３１】
2014179827.tif 000033
【図３２】
2014179827.tif 000034