JP6787845B2 - 被疑箇所推定装置、及び被疑箇所推定方法 - Google Patents

Description

本発明は、仮想移動体通信事業者網を経由するＷｅｂブラウジングサービスにおける品質劣化の被疑箇所を推定する技術に関連するものである。

スマートフォンやタブレットの利用者は増加傾向にあるが、昨今では、移動体通信事業者と比較して料金が安い、仮想移動体通信事業者（Ｍｏｂｉｌｅ Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ，ＭＶＮＯ）を利用するユーザも増えてきている。また、キャリアアグリゲーションなど高速化技術も進んでおり、様々なモバイルサービスが利用されるようになってきた。その中でも、特にＷｅｂアプリケーションサービスは多くのユーザが利用し、需要が高いサービスである。

しかしながら、モバイルＮＷ環境の品質は、利用する時間帯や場所等で大きく変動する。サービス利用中に、例えば、要求したページの表示時間が遅いなどの品質劣化が発生した場合、移動体通信事業者としては早急に対処する必要があるが、劣化原因や劣化箇所がすぐに特定できない場合は対応が遅れ、それによりユーザ満足度（ＱｏＥ：ｑｕａｌｉｔｙ ｏｆ ｅｘｐｅｒｉｅｎｃｅ）が低下し、顧客離れに繋がる恐れがある。

これまでにＷｅｂブラウザログから品質劣化箇所を推定する技術が提案されている。例えば、特許文献１には、ユークリッド空間内に特定される点の領域（閾値）で被疑箇所を特定する技術が開示されている。また、特許文献２には、各領域（端末、移動体通信事業者網、ＰＯＩ、サーバ）の被疑判定を行う際に付与した指標について、閾値との比較を行うことで被疑箇所を推定する技術が開示されている。

本多他、「被疑箇所推定装置及び被疑箇所推定方法」、特開２０１６−９２５００号公報 吉村他、「被疑箇所推定装置及び被疑箇所推定方法」、特開２０１７−２８５４６号公報

これまでの提案技術は、移動体通信事業者のＮＷ構成を対象とした品質劣化被疑箇所の推定であり、仮想移動体通信事業者は対象としていない。仮想移動体通信事業者のＮＷ構成においては、Ｗｅｂページの表示において移動体通信事業者網と仮想移動体通信事業者網の両方を介するが、無線ＮＷ区間で品質劣化が発生した場合に、従来技術では両網の切り分けが考慮できておらず、いずれの網が品質劣化被疑箇所であるかを推定することが困難である。特に移動体通信事業者網においては無線アクセス区間が、仮想移動体通信事業者網では移動体通信事業者網との接続点が、それぞれボトルネックとなり得ることからも、本切り分けは非常に重要な観点である。

本発明は上記の点に鑑みてなされたものであり、仮想移動体通信事業者網を経由する通信を行う端末のログ情報から移動体通信事業者網と仮想移動体通信事業者網に関する被疑箇所推定を可能とする技術を提供することを目的とする。

開示の技術によれば、複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信部と、
前記受信部によって受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間についての条件の判定と、前記表示過程における無線品質データについての無線品質条件を満足するかの判定との、両方の判定結果に基づき、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、を有し、
前記推定部は、
前記複数のログ情報を、前記ログ情報に含まれている前記端末の識別情報ごとの第１の集合に分類し、前記第１の集合ごとに、前記ログ情報に含まれている、ＤＮＳ応答の受信からＳＹＮパケットの送出までの第１の所要時間についての第１の条件と、前記ログ情報に含まれている、３ウェイハンドシェイクの完了からＨＴＴＰのＧＥＴメッセージの送出までの第２の所要時間についての第２の条件と、を判定し、
いずれかの前記第１の集合において、前記第１の条件及び前記第２の条件の少なくともいずれか一方が満たされる場合には、前記端末が前記被疑箇所であると推定し、
全ての前記第１の集合について、前記第１の条件及び前記第２の条件の双方が満たされない場合には、前記複数のログ情報を、前記ログ情報に含まれている基地局の識別情報ごとの第２の集合に分類し、前記第２の集合ごとに、前記ログ情報に含まれている、ＤＮＳクエリの送信からＤＮＳ応答の受信までの第３の所要時間についての第３の条件を判定し、
いずれかの前記第２の集合において、前記第３の条件が満たされる場合には、更に、当該第３の条件が満たされる前記第２の集合について前記ログ情報に含まれている無線品質データの値に対する無線品質条件を判定し、
前記無線品質条件が満たされる場合には、前記基地局が前記被疑箇所であると推定し、前記無線品質条件が満たされない場合には、仮想移動体通信事業者網が前記被疑箇所であると推定する、
ことを特徴とする被疑箇所推定装置が提供される。

開示の技術によれば、仮想移動体通信事業者網を経由する通信を行う端末のログ情報から移動体通信事業者網と仮想移動体通信事業者網に関する被疑箇所推定を可能とする技術が提供される。

本発明の実施の形態におけるＷｅｂシステムの構成例を示す図である。 本発明の実施の形態における被疑箇所推定装置のハードウェア構成例を示す図である。 本発明の実施の形態におけるユーザ端末及び被疑箇所推定装置の機能構成例を示す図である。 ユーザ端末が実行する処理手順の一例を説明するためのフローチャートである。 ユーザ端末から被疑箇所推定装置へ送信されるブラウザログの構成例を示す図である。 Ｗｅｂページの表示処理の処理手順の一例を示す図である。 ブラウザログに含まれる指標値群の一例を示す図である。 被疑箇所推定装置が実行する処理手順の一例を説明するためのフローチャートである。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（システム構成）
図１は、本発明の実施の形態におけるＷｅｂシステムの構成例を示す図である。図１において、１以上のユーザ端末２０は、１以上の基地局３０のうちのいずれかを介して、移動体通信事業者Ｎ２を介して仮想移動体通信事業者網Ｎ３に接続可能である。また、ユーザ端末２０は、移動体通信事業者網Ｎ２、仮想移動体通信事業者網Ｎ３、ＰＯＩ、及びインターネットＮ１等を介して、１以上のＷｅｂサーバ４０と通信可能である。更に、ユーザ端末２０は、例えば、移動体通信事業者網Ｎ２と仮想移動体通信事業者網Ｎ３を介して、被疑箇所推定装置１０と通信可能である。

ユーザ端末２０は、Ｗｅｂページを表示可能なＷｅｂブラウザ（以下、単に「ブラウザ」と言う。）を備えた通信端末である。例えば、携帯電話、スマートフォン、タブレット端末、車載機、又はＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等が、ユーザ端末２０として利用されてもよい。なお、Ｗｅｂページは、例えば、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）、及びスクリプト等を含むデータである。

被疑箇所推定装置１０は、ユーザ端末２０に表示されるＷｅｂページに関する表示時間（表示待ち時間）等の品質の劣化に関して、当該劣化の要因となった被疑箇所を推定するコンピュータである。本発明の実施の形態において、被疑箇所は、ユーザ端末２０、基地局３０、移動体通信事業者網Ｎ２、事業者間ＰＯＩを含む仮想移動体通信事業者網Ｎ３、ＰＯＩ（又はインターネットＮ１）、及びＷｅｂサーバ４０の６つの通信箇所のうちのいずれかの通信箇所に切り分けられる。なお、被疑箇所推定装置１０は、例えば、仮想移動体通信事業者に設置されてもよい。

Ｗｅｂサーバ４０は、Ｗｅｂページを記憶又は生成するＷｅｂサイトを実現する１以上のコンピュータである。

図２は、本発明の実施の形態における被疑箇所推定装置のハードウェア構成例を示す図である。図２の被疑箇所推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

被疑箇所推定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って被疑箇所推定装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

図３は、本発明の実施の形態におけるユーザ端末及び被疑箇所推定装置の機能構成例を示す図である。図３において、ユーザ端末２０は、Ｗｅｂ表示制御部２１、ログ生成部２２、ログ送信部２３、及びログ保存部２４等を有する。これら各部は、ユーザ端末２０にインストールされた１以上のプログラムが、ユーザ端末２０のＣＰＵに実行させる処理により実現される。

Ｗｅｂ表示制御部２１は、ユーザによるＷｅｂページの表示指示の入力に応じ、Ｗｅｂページのダウンロード及びＷｅｂページの表示等を行う。Ｗｅｂページの表示指示とは、例えば、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の入力や、既に表示されているＷｅｂページ内のリンクの選択等である。なお、Ｗｅｂ表示制御部２１は、例えば、Ｗｅｂブラウザプログラムが、ユーザ端末２０のＣＰＵに実行させる処理により実現されてもよい。

ログ生成部２２は、Ｗｅｂページの表示指示の入力を契機として、Ｎａｖｉｇａｔｉｏｎ Ｔｉｍｉｎｇ ＡＰＩや、ユーザ端末２０のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が備える標準のＡＰＩ等を呼び出すことにより、Ｗｅｂページが表示されるまでの過程における、複数の段階（複数の区間）の所要時間及びＷｅｂページ表示過程における無線品質データを計測し、その計測結果を含むログ（以下、「ブラウザログ」という。）を生成する。ここでは無線品質データとしてＲＳＲＱ及びＲＳＳＮＲを用いるが、これに限るものではない。例えば、ＲＳＲＰ、ＲＳＲＱ、ＲＳＳＩ、ＲＳＳＮＲのうちいずれか１つ又は複数を使用することとしてもよい。

ログ送信部２３は、ログ生成部２２によって生成されるブラウザログを、被疑箇所推定装置１０に送信する。あるいは、ログ送信部２３は、ログ保存部２４に保存されたブラウザログを被疑箇所推定装置１０に送信する。

ログ保存部２４は、ログ生成部２２によって生成されたブラウザログを保存（記憶）する。

なお、ユーザ端末２０を、ログ生成部２２及びログ送信部２３として機能させるプログラムは、例えば、Ｗｅｂブラウザに対するプラグインとして実装されてもよい。例えば、ユーザ端末２０から仮想移動体通信事業者に対して、Ｗｅｂページの表示時間の品質劣化の報告が有った場合に、当該仮想移動体通信事業者から当該ユーザ端末２０に対して当該プラグインが転送されてもよい。

被疑箇所推定装置１０は、ログ受信部１１、及び推定部１２等を有する。これら各部は、被疑箇所推定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。被疑箇所推定装置１０は、また、ログ記憶部１３を利用する。ログ記憶部１３は、補助記憶装置１０２、又は被疑箇所推定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

ログ受信部１１は、ユーザ端末２０から送信されるブラウザログを受信する。ログ受信部１１は、受信したブラウザログをログ記憶部１３に記憶する。従って、ログ記憶部１３には、ブラウザログが蓄積される。なお、ブラウザログには、ユーザ端末２０におけるＷｅｂページの表示過程を構成する複数の段階の所要時間等が含まれる。推定部１２は、ログ記憶部１３に記憶されたブラウザログに含まれる、Ｗｅｂページの表示過程を構成する複数の段階の所要時間等について、それぞれに関する条件を満足するかを判定して、Ｗｅｂページの表示の品質劣化の要因の被疑箇所を推定する。即ち、本実施の形態では、Ｎａｖｉｇａｔｉｏｎ Ｔｉｍｉｎｇの出力情報等に基づいて、より高い粒度（又は精度）で品質劣化の被疑箇所の切り分けが実現される。

なお、本発明の実施の形態では、以下の（１）〜（３）が前提とされる。

（１）１つのブラウザログは、単一のユーザ端末２０による同一サイト（Ｗｅｂサーバ４０）へのアクセスに関する情報である。即ち、ブラウザログは、ユーザ端末２０によるＷｅｂサーバ４０へのアクセス単位で生成される。

（２）ユーザ端末２０が、名前解決に利用するリゾルバ（ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ）は、移動体通信事業者網Ｎ２及び仮想移動体通信事業者Ｎ３内に設置されている。当該リゾルバがキャッシュを持たないクエリについては、通常のＤＮＳの動作に従い、インターネットＮ１上の権限サーバに対して、リゾルバから名前解決が要求される。

（３）ユーザ端末２０がＷｅｂページをダウンロードする際のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）の３ウェイハンドシェイク（３−Ｗａｙ ｈａｎｄｓｈａｋｅ）は、インターネットＮ１のＷｅｂサーバ４０との間で実行される。

更に推定部１２は、ログ記憶部１３に記憶されたブラウザログに含まれる、無線品質データについて、与えられた無線品質条件を満足するかを判定して、無線アクセス区間が被疑箇所であるかどうかを推定する。これにより品質劣化の被疑箇所が、無線アクセス区間であるか、あるいは無線アクセス区間よりも上位であるかの切り分けが実現される。

（システムの動作）
以下、ユーザ端末２０及び被疑箇所推定装置１０のそれぞれが実行する処理手順について説明する。図４は、ユーザ端末２０が実行する処理手順の一例を説明するためのフローチャートである。

ログ生成部２２は、Ｗｅｂブラウザに対するＷｅｂページの表示指示の入力を待機している（Ｓ１０１）。ログ生成部２２は、当該表示指示の入力を検知すると（Ｓ１０１でＹｅｓ）、Ｎａｖｉｇａｔｉｏｎ Ｔｉｍｉｎｇ ＡＰＩやＯＳのＡＰＩ等を呼び出し（Ｓ１０２）、当該ＡＰＩによって得られる情報を含むブラウザログを生成する（Ｓ１０３）。生成されたブラウザログは、ログ保存部２４に保存される。続いて、ログ送信部２３は、当該ブラウザログを、被疑箇所推定装置１０に送信する（Ｓ１０４）。なお、被疑箇所推定装置１０へのブラウザログの送信は、定期的に実行されてもよいし、ユーザによる指示の入力に応じて実行されてもよい。これらの場合、送信時期までに生成されたブラウザログがまとめて送信されてもよい。

図５は、ユーザ端末から被疑箇所推定装置へ送信されるブラウザログの構成例を示す図である。図５に示されるように、各ブラウザログは、例えば、日時、端末アドレス、基地局ＩＤ、サーバアドレス、及び指標値群等を含む。

日時は、Ｗｅｂページの表示指示が入力された日時、又はＷｅｂページの表示が完了した日時等である。端末アドレスは、例えば、ユーザ端末２０のＩＰアドレスである。基地局ＩＤは、Ｗｅｂページの表示時にユーザ端末２０がアクセスしていた基地局３０の識別情報である。サーバアドレスは、Ｗｅｂページの提供元のＷｅｂサーバ４０のアドレス情報（例えば、ＩＰアドレス又はＵＲＬ等）である。指標値群は、Ｗｅｂページの表示過程を構成する複数の段階のそれぞれの所要時間である。また、指標値群は無線品質も含む。指標値群の詳細については後述される。

なお、ステップＳ１０２及びＳ１０３に並行して、Ｗｅｂ表示制御部２１は、図６に示されるようなＷｅｂページの表示処理を実行する。

図６は、Ｗｅｂページの表示処理の処理手順の一例を示す図である。なお、図６において、ユーザ端末２０とＤＮＳサーバとの間のネットワークは、移動体通信事業者網Ｎ２及び仮想移動体通信事業者網Ｎ３であり、ユーザ端末２０とＷｅｂサーバ４０との間のネットワークは、移動体通信事業者網Ｎ２及び仮想移動体通信事業者網Ｎ３、インターネットＮ１である。

ステップＳ２０１において、Ｗｅｂ表示制御部２１は、ユーザによって入力されたＵＲＬに関して、ＤＮＳサーバにＤＮＳクエリを送信する。当該ＤＮＳクエリに応じ、ＤＮＳサーバは、名前解決結果を含むＤＮＳ応答を返信する（Ｓ２０２）。続いて、Ｗｅｂ表示制御部２１が、ＳＹＮパケットをＷｅｂサーバ４０に送信すると（Ｓ２０３）、Ｗｅｂサーバ４０は、ＳＹＮ ＡＣＫパケットを返信する（Ｓ２０４）。続いて、Ｗｅｂ表示制御部２１が、ＡＣＫパケットをＷｅｂサーバ４０に送信して（Ｓ２０５）、ＴＣＰ３ウェイハンドシェイクが完了する。

続いて、Ｗｅｂ表示制御部２１は、ＨＴＴＰのＧＥＴメッセージをＷｅｂサーバ４０に送信すると（Ｓ２０６）、Ｗｅｂページを構成するコンテンツデータのダウンロードが開始される（Ｓ２０７）。

上記のような表示処理に関して、図４のステップＳ１０３では、図７に示される指標値群を含むブラウザログが出力される。図７は、ブラウザログに含まれる指標値群の一例を示す図である。図７に示されるように、１つのブラウザログには、指標値１〜５が含まれる。

また、このとき、ＯＳのＡＰＩによりＲＳＲＱ値及びＲＳＳＮＲ値を取得し、それぞれ指標値６ａ、指標値６ｂとして各指標値群を含むようなブラウザログが出力される。

指標値１は、ＤＮＳ応答の受信からＴＣＰのＳＹＮパケットの送出までの所要時間である。指標値２は、ＴＣＰの３ウェイハンドシェイク完了からＨＴＴＰのＧＥＴメッセージの送出までの所要時間である。指標値３は、ＤＮＳクエリの送信からＤＮＳ応答の受信までの所要時間である。なお、仮想移動体通信事業者における指標３は、仮想移動体通信事業者内のＤＮＳサーバを対象とする。指標値４は、ＴＣＰの３ウェイハンドシェイクの所要時間である。指標値５は、ＨＴＴＰのＧＥＴメッセージの送出から最初の応答パケットの受信までの所要時間である。

なお、図６には、各指標値が示す所要時間に対応する区間に対して、各指標値の識別子（（ｉ）〜（ｖ））が付されている。

続いて、被疑箇所推定装置１０が実行する処理手順について説明する。図８は被疑箇所推定装置が実行する処理手順の一例を説明するためのフローチャートである。図８の処理は、例えば、ユーザ端末２０のユーザからの品質劣化の申告や、移動体通信事業者側での品質劣化の検知等に応じて実行されてもよいし、定期的に実行されてもよいし、任意のタイミングで実行されてもよい。

なお、本手順において被疑箇所判定を行う際には予め、劣化データとの比較用データ（非劣化データ）を準備しておく必要がある。

ステップＳ３０１において、推定部１２は、ログ記憶部１３から処理対象とするブラウザログの集合を抽出する。例えば、日時の値が、現在時刻から遡って所定時間内であるブラウザログが処理対象とされてもよい。また、ユーザからの品質劣化の申告や、仮想移動体通信事業者側での品質劣化の検知等において、品質が劣化した日時が或る程度特定されている場合、品質が劣化した日時の前後所定時間内の日時を含むブラウザログが処理対象とされてもよい。

続いて、推定部１２は、抽出されたブラウザログの集合（以下、「集合Ｌ」という。）を、ユーザ端末２０別に分類する（Ｓ３０２）。ユーザ端末２０別への分類は、各ブラウザログの端末アドレスの値に基づいて行われてもよい。分類後の各集合を、以下「集合Ｌｔ」という。

続いて、推定部１２は、集合Ｌｔごとに、指標値１が非劣化時と差があると言う条件（以下、「条件１」という。）、及び指標値２が非劣化時と差があると言う条件（以下、「条件２」という。）を判定する（Ｓ３０３）。指標値１もしくは指標値２が非劣化時と差があると言う条件は、非劣化時の当該所要時間の集合値と集合Ｌｔの比較において、分布形状差分があり、且つ、平均値及び分散値について閾値を上回る差分があり、且つ、有意差があることとする。

いずれかの集合Ｌｔに関して（即ち、いずれかのユーザ端末２０に関して）条件１及び条件２の少なくともいずれか一方が満たされる場合（Ｓ３０３でＹｅｓ）、推定部１２は、条件１及び条件２の少なくともいずれか一方が満たされたユーザ端末２０が被疑箇所であると判定する（Ｓ３０４）。この場合、図８の処理は終了する。

一方、全ての集合Ｌｔについて、条件１及び条件２の双方が満たされない場合（Ｓ３０３でＮｏ）、推定部１２は、集合Ｌを、基地局３０別に分類する（Ｓ３０５）。即ち、ユーザ端末２０別の分類は解除された状態で、基地局３０別への分類が行われる。基地局３０別への分類は、各ブラウザログの基地局ＩＤに基づいて行われてもよい。分類後の各集合を、以下「集合Ｌｂ」という。

続いて、推定部１２は、集合Ｌｂごとに、指標値３が非劣化時と差があると言う条件（以下、「条件３」という。）を判定する（Ｓ３０６）。指標値３が非劣化時と差があると言う条件は、非劣化時の当該所要時間の集合値と集合Ｌｂの比較において、分布形状差分があり、且つ、平均値及び分散値について閾値を上回る差分があり、且つ、有意差があることとする。

いずれかの集合Ｌｂに関して（即ち、いずれかの基地局３０に関して）条件３が満たされる場合（Ｓ３０６でＹｅｓ）、劣化被疑箇所が移動体通信事業者と仮想移動体通信事業者間（事業者間ＰＯＩ）の影響であるかどうかを判定するために、推定部１２は集合Ｌｂに関してＲＳＲＱ値を指標値６ａ、ＲＳＳＮＲ値を指標値６ｂとして抽出し、指標値６ａもしくは指標値６ｂが非劣化時と差があると言う条件（以下、「条件６」という。）を判定する（Ｓ３０７）。指標値６ａ、６ｂが非劣化時と差があると言う条件は、非劣化時のＲＳＲＱ値もしくはＲＳＳＮＲ値の集合値と集合Ｌｂの比較において、分布形状差分があり、且つ、平均値及び分散値について閾値を上回る差分があり、且つ、有意差があることとする。集合Ｌｂに関して条件６が満たされた場合（Ｓ３０７でＹｅｓ）は基地局３０（つまり、無線アクセス区間）が被疑箇所であると判定し（Ｓ３０８）、条件６が満たされなかった場合（Ｓ３０７でＮｏ）は仮想移動体通信事業者網Ｎ３が被疑箇所であると判定する（Ｓ３０９）。Ｓ３０８、Ｓ３０９いずれの場合も、図８の処理は終了する。

なお、事業者間ＰＯＩは仮想移動体通信業者網に含まれ、基地局３０は移動体通信事業者網に含まれると考えてよい。前述したように、移動体通信事業者網においては無線アクセス区間が、仮想移動体通信事業者網では移動体通信事業者網との接続点（事業者間ＰＯＩ）が、それぞれボトルネックとなり得る。よって、基地局３０が被疑箇所であると判定された場合には移動体通信事業者網が被疑箇所であると考えることができ、基地局３０が被疑箇所でなくて、移動体通信事業者網と仮想移動体通信事業者網を経由する部分（図６のＤＮＳクエリ〜ＤＮＳ応答）が被疑となる場合には、事業者間ＰＯＩ、すなわち仮想移動体通信業者網が被疑箇所となる。

よって、本実施の形態により、移動体通信事業者網と仮想移動体通信事業者網のいずれの網が劣化被疑箇所であるかを、仮想移動体通信事業者網を経由する端末のログ情報のみから推定できる。

一方、全ての集合Ｌｂについて、条件３が満たされない場合（Ｓ３０６でＮｏ）、推定部１２は、集合Ｌを、Ｗｅｂサーバ４０別に分類する（Ｓ３１０）。即ち、基地局３０別の分類は解除された状態で、Ｗｅｂサーバ４０別への分類が行われる。Ｗｅｂサーバ４０別への分類は、各ブラウザログのサーバアドレスの値に基づいて行われてもよい。分類後の各集合を、以下「集合Ｌｓ」という。

続いて、推定部１２は、集合Ｌｓごとに、指標値４が非劣化時と差があると言う条件（以下、「条件４」という。）、及び指標値５が非劣化時と差があると言う条件（以下、「条件５」という。）を判定する（Ｓ３１１）。指標値４もしくは指標値５が非劣化時と差があると言う条件は、非劣化時の当該所要時間の集合値と集合Ｌｓの比較において、分布形状差分があり、且つ、平均値及び分散値について閾値を上回る差分があり、且つ、有意差があることとする。

いずれかの集合Ｌｓに関して（即ち、いずれかのＷｅｂサーバ４０に関して）条件４及び条件５の少なくともいずれか一方が満たされる場合（Ｓ３１１でＹｅｓ）、推定部１２は、条件４及び条件５の少なくともいずれか一方が満たされたＷｅｂサーバ４０が被疑箇所であると判定する（Ｓ３１２）。この場合、図８の処理は終了する。

一方、全ての集合Ｌｓについて、条件４及び条件５の双方が満たされない場合（Ｓ３１１でＮｏ）、推定部１２は、ＰＯＩが被疑箇所であると判定する（Ｓ３１３）。

なお、図８の処理が、品質の劣化とは無関係なタイミングで実行される場合、ステップＳ３１３においては、被疑箇所は無いと判定されてもよい。

上述したように、本実施の形態によれば、不特定のログ情報に基づいてＷｅｂページの表示時間に関する品質劣化の要因の被疑箇所の推定を可能とすることができる。その結果、サービス事業者、プラットフォーム事業者、移動体通信事業者及び仮想移動体通信事業者の各事業者の責任範囲を明確化することができる。また、品質劣化発生時の状況把握と実態把握の迅速化や、監視技術の効率化等を期待することができる。

なお、条件１〜条件６は、例えば、経験値に基づいて設定されてもよい。例えば、ユーザ端末２０、基地局３０、仮想移動体通信事業者網Ｎ３、ＰＯＩ、Ｗｅｂサーバ４０のそれぞれが被疑箇所である状況において収集されたそれぞれのブラウザログの集合に基づいて得られた平均値・分散を非劣化時の平均値・分散とする設定がされてもよい。又は、指標値１〜指標値５及び指標値６ａ、指標値６ｂについて、理論的に求まる正常な値と異常な値との境界が、条件１〜条件６として設定されてもよい。

（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信部と、前記受信部によって受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間についての条件の判定と、前記表示過程における無線品質データについての無線品質条件を満足するかの判定との、両方の判定結果に基づき、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、を有することを特徴とする被疑箇所推定装置が提供される。

前記推定部は、前記複数のログ情報を、前記ログ情報に含まれている前記端末の識別情報ごとの第１の集合に分類し、前記第１の集合ごとに、前記ログ情報に含まれている、ＤＮＳ応答の受信からＳＹＮパケットの送出までの第１の所要時間についての第１の条件と、前記ログ情報に含まれている、３ウェイハンドシェイクの完了からＨＴＴＰのＧＥＴメッセージの送出までの第２の所要時間についての第２の条件と、を判定し、いずれかの前記第１の集合において、前記第１の条件及び前記第２の条件の少なくともいずれか一方が満たされる場合には、前記端末が前記被疑箇所であると推定する、こととしてもよい。

前記推定部は、全ての前記第１の集合について、前記第１の条件及び前記第２の条件の双方が満たされない場合には、前記複数のログ情報を、前記ログ情報に含まれている基地局の識別情報ごとの第２の集合に分類し、前記第２の集合ごとに、前記ログ情報に含まれている、ＤＮＳクエリの送信からＤＮＳ応答の受信までの第３の所要時間についての第３の条件を判定し、いずれかの前記第２の集合において、前記第３の条件が満たされる場合には、更に、当該第３の条件が満たされる前記第２の集合について前記ログ情報に含まれている無線品質データの値に対する無線品質条件を判定し、前記無線品質条件が満たされる場合には、前記基地局が前記被疑箇所であると推定し、前記無線品質条件が満たされない場合には、仮想移動体通信事業者網が前記被疑箇所であると推定する、こととしてもよい。

前記推定部は、全ての前記第２の集合について、前記第３の条件が満たされない場合には、前記複数のログ情報を、前記複数のログ情報に含まれるＷｅｂサーバの識別情報ごとの第３の集合に分類し、前記第３の集合ごとに、前記ログ情報に含まれている、ＴＣＰの３ウェイハンドシェイクの第４の所要時間についての第４の条件と、前記ログ情報に含まれている、ＨＴＴＰのＧＥＴメッセージの送出から最初の応答パケットの受信までの第５の所要時間についての第５の条件と、を判定し、いずれかの前記第３の集合において、前記第４の条件及び前記第５の条件の少なくともいずれか一方が満たされる場合には、前記Ｗｅｂサーバが前記被疑箇所であると推定する、こととしてもよい。

前記推定部は、全ての前記第３の集合の値について前記第４の条件及び前記第５の条件の双方が満たされない場合には、ＰＯＩが前記被疑箇所であると推定する、こととしてもよい。

前記第１の条件、前記第２の条件、前記第３の条件、前記第４の条件、前記第５の条件、又は前記無線品質条件は、例えば、当該条件の判定に使用される指標値に対して、非劣化時の値の集合値との分布形状差分があり、且つ、平均値及び分散値について閾値を上回る差分があり、且つ、有意差があることである。

前記無線品質データは、例えば、ＲＳＲＰ、ＲＳＲＱ、ＲＳＳＩ、ＲＳＳＮＲのうちいずれか１つを含む。

なお、本実施の形態において、ユーザ端末２０は、端末の一例である。ブラウザログは、ログ情報の一例である。ログ受信部１１は、受信部の一例である。集合Ｌｔは、第１の集合の一例である。集合Ｌｂは、第２の集合の一例である。集合Ｌｓは、第３の集合の一例である。条件１、条件２、条件３、条件４、条件５、条件６は、第１の条件、第２の条件、第３の条件、第４の条件、第５の条件、無線品質条件の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 被疑箇所推定装置
１１ ログ受信部
１２ 推定部
１３ ログ記憶部
２０ ユーザ端末
２１ Ｗｅｂ表示制御部
２２ ログ生成部
２３ ログ送信部
２４ ログ保存部
３０ 基地局
４０ Ｗｅｂサーバ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス
Ｎ１ インターネット
Ｎ２ 移動体通信事業者網
Ｎ３ 仮想移動体通信事業者網

Claims (6)

1. 複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信部と、
   前記受信部によって受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間についての条件の判定と、前記表示過程における無線品質データについての無線品質条件を満足するかの判定との、両方の判定結果に基づき、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、を有し、
   前記推定部は、
   前記複数のログ情報を、前記ログ情報に含まれている前記端末の識別情報ごとの第１の集合に分類し、前記第１の集合ごとに、前記ログ情報に含まれている、ＤＮＳ応答の受信からＳＹＮパケットの送出までの第１の所要時間についての第１の条件と、前記ログ情報に含まれている、３ウェイハンドシェイクの完了からＨＴＴＰのＧＥＴメッセージの送出までの第２の所要時間についての第２の条件と、を判定し、
   いずれかの前記第１の集合において、前記第１の条件及び前記第２の条件の少なくともいずれか一方が満たされる場合には、前記端末が前記被疑箇所であると推定し、
   全ての前記第１の集合について、前記第１の条件及び前記第２の条件の双方が満たされない場合には、前記複数のログ情報を、前記ログ情報に含まれている基地局の識別情報ごとの第２の集合に分類し、前記第２の集合ごとに、前記ログ情報に含まれている、ＤＮＳクエリの送信からＤＮＳ応答の受信までの第３の所要時間についての第３の条件を判定し、
   いずれかの前記第２の集合において、前記第３の条件が満たされる場合には、更に、当該第３の条件が満たされる前記第２の集合について前記ログ情報に含まれている無線品質データの値に対する無線品質条件を判定し、
   前記無線品質条件が満たされる場合には、前記基地局が前記被疑箇所であると推定し、前記無線品質条件が満たされない場合には、仮想移動体通信事業者網が前記被疑箇所であると推定する、
   ことを特徴とする被疑箇所推定装置。
2. 前記推定部は、
   全ての前記第２の集合について、前記第３の条件が満たされない場合には、前記複数のログ情報を、前記複数のログ情報に含まれるＷｅｂサーバの識別情報ごとの第３の集合に分類し、前記第３の集合ごとに、前記ログ情報に含まれている、ＴＣＰの３ウェイハンドシェイクの第４の所要時間についての第４の条件と、前記ログ情報に含まれている、ＨＴＴＰのＧＥＴメッセージの送出から最初の応答パケットの受信までの第５の所要時間についての第５の条件と、を判定し、
   いずれかの前記第３の集合において、前記第４の条件及び前記第５の条件の少なくともいずれか一方が満たされる場合には、前記Ｗｅｂサーバが前記被疑箇所であると推定する、
   ことを特徴とする請求項１記載の被疑箇所推定装置。
3. 前記推定部は、全ての前記第３の集合の値について前記第４の条件及び前記第５の条件の双方が満たされない場合には、ＰＯＩが前記被疑箇所であると推定する、
   ことを特徴とする請求項２記載の被疑箇所推定装置。
4. 前記第１の条件、前記第２の条件、前記第３の条件、前記第４の条件、前記第５の条件、又は前記無線品質条件は、当該条件の判定に使用される指標値に対して、非劣化時の値の集合値との分布形状差分があり、且つ、平均値及び分散値について閾値を上回る差分があり、且つ、有意差があることである、
   ことを特徴とする請求項２又は３に記載の被疑箇所推定装置。
5. 前記無線品質データは、ＲＳＲＰ、ＲＳＲＱ、ＲＳＳＩ、ＲＳＳＮＲのうちいずれか１つを含む
   ことを特徴とする請求項１ないし４のうちいずれか１項に記載の被疑箇所推定装置。
6. コンピュータが、
   複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信手順と、
   前記受信手順において受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間について条件の判定と、前記表示過程における無線品質データについての無線品質条件を満足するかの判定との、両方の判定結果に基づき、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定手順と、を実行する被疑箇所推定方法であり、
   前記推定手順において、前記コンピュータは、
   前記複数のログ情報を、前記ログ情報に含まれている前記端末の識別情報ごとの第１の集合に分類し、前記第１の集合ごとに、前記ログ情報に含まれている、ＤＮＳ応答の受信からＳＹＮパケットの送出までの第１の所要時間についての第１の条件と、前記ログ情報に含まれている、３ウェイハンドシェイクの完了からＨＴＴＰのＧＥＴメッセージの送出までの第２の所要時間についての第２の条件と、を判定し、
   いずれかの前記第１の集合において、前記第１の条件及び前記第２の条件の少なくともいずれか一方が満たされる場合には、前記端末が前記被疑箇所であると推定し、
   全ての前記第１の集合について、前記第１の条件及び前記第２の条件の双方が満たされない場合には、前記複数のログ情報を、前記ログ情報に含まれている基地局の識別情報ごとの第２の集合に分類し、前記第２の集合ごとに、前記ログ情報に含まれている、ＤＮＳクエリの送信からＤＮＳ応答の受信までの第３の所要時間についての第３の条件を判定し、
   いずれかの前記第２の集合において、前記第３の条件が満たされる場合には、更に、当該第３の条件が満たされる前記第２の集合について前記ログ情報に含まれている無線品質データの値に対する無線品質条件を判定し、
   前記無線品質条件が満たされる場合には、前記基地局が前記被疑箇所であると推定し、前記無線品質条件が満たされない場合には、仮想移動体通信事業者網が前記被疑箇所であると推定する、
   ことを特徴とする被疑箇所推定方法。

Images