特許 6787846 被疑箇所推定装置、及び被疑箇所推定方法

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

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

(11)【特許番号】6787846

(24)【登録日】2020年11月2日

(45)【発行日】2020年11月18日

(54)【発明の名称】被疑箇所推定装置、及び被疑箇所推定方法

(51)【国際特許分類】

   H04L 12/70 20130101AFI20201109BHJP

【ＦＩ】

   H04L12/70 100Z

【請求項の数】7

【全頁数】15

(21)【出願番号】特願2017-142030(P2017-142030)

(22)【出願日】2017年7月21日

(65)【公開番号】特開2019-22188(P2019-22188A)

(43)【公開日】2019年2月7日

【審査請求日】2019年8月26日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】吉村 憲子

(72)【発明者】

【氏名】恵木 則次

(72)【発明者】

【氏名】野尻 秀樹

【審査官】 宮島 郁美

(56)【参考文献】

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

【文献】 米国特許出願公開第２０１５／０２５７０７１（ＵＳ，Ａ１）

【文献】 国際公開第２０１４／００２５３３（ＷＯ，Ａ１）

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

【文献】 米国特許出願公開第２０１０／００１７８６１（ＵＳ，Ａ１）

【文献】 吉村 憲子，Ｎａｖｉｇａｔｉｏｎ ｔｉｍｉｎｇ ＡＰＩを用いたＷｅｂ品質劣化切り分け手法のフィールド検証 Field validation of fault isolation of web services using Navigation timing API，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，２０１５年１１月１９日，Ｖｏｌ．１１５ Ｎｏ．３２７，71-74

【文献】 吉村 憲子，Ｎａｖｉｇａｔｉｏｎ Ｔｉｍｉｎｇ ＡＰＩを用いた品質劣化区間判定手法の一検討 Study of quality deterioration section determination method using Navigation Timing API，電子情報通信学会２０１６年総合大会講演論文集 通信２，日本，一般社団法人電子情報通信学会，２０１６年 ３月１１日，388

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

Ｈ０４Ｌ１２／００−１２／２６，１２／５０−１２／９５５

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

【請求項1】

複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信部と、
前記受信部によって受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間についての条件を判定することで、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、を有し、
前記推定部は、Ｗｅｂページの表示過程において移動体通信事業者網を介して通信を行う端末から生成されたログ情報、及び、Ｗｅｂページの表示過程において前記移動体通信事業者網及び仮想移動体通信事業者網を介して通信を行う端末から生成されたログ情報の両方を用いて、仮想移動体通信事業者網を介して通信を行う端末のＷｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する、
ことを特徴とする被疑箇所推定装置。

【請求項2】

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

【請求項3】

前記推定部は、
全ての前記第１の集合について、前記第１の条件及び前記第２の条件の双方が満たされない場合には、前記仮想移動体通信事業者網を介して通信を行う端末から生成されたログ情報を、当該ログ情報に含まれている基地局の識別情報ごとの第２の集合に分類し、前記第２の集合ごとに、前記ログ情報に含まれている、ＤＮＳクエリ送出からＤＮＳ応答受信までの第３の所要時間についての第３の条件を判定し、
いずれかの前記第２の集合において、前記第３の条件が満たされる場合には、前記移動体通信事業者網を介して通信を行う端末から生成されたログ情報から、前記第３の条件が満たされる前記第２の集合に対する基地局の識別情報を持つ第２'の集合を抽出し、前記第２'の集合について前記第３の所要時間に対する第３'の条件を判定し、
前記第３'の条件が満たされる場合には、前記基地局が前記被疑箇所であると推定し、前記第３'の条件が満たされない場合には、前記仮想移動体通信事業者網が前記被疑箇所であると推定する、
ことを特徴とする請求項２記載の被疑箇所推定装置。

【請求項4】

前記推定部は、
全ての前記第２の集合について、前記第３の条件が満たされない場合には、前記仮想移動体通信事業者網を介して通信を行う端末から生成されたログ情報を、当該ログ情報に含まれるＷｅｂサーバの識別情報ごとの第３の集合に分類し、前記第３の集合ごとに、前記ログ情報に含まれている、ＴＣＰの３ウェイハンドシェイクの第４の所要時間についての第４の条件と、前記ログ情報に含まれている、ＨＴＴＰのＧＥＴメッセージの送出から最初の応答パケットの受信までの第５の所要時間についての第５の条件と、を判定し、
いずれかの前記第３の集合において、前記第４の条件及び前記第５の条件の少なくともいずれか一方が満たされる場合には、前記Ｗｅｂサーバが前記被疑箇所であると推定する、
ことを特徴とする請求項３記載の被疑箇所推定装置。

【請求項5】

前記推定部は、全ての前記第３の集合について、前記第４の条件及び前記第５の条件の双方が満たされない場合には、ＰＯＩが前記被疑箇所であると推定する、
ことを特徴とする請求項４記載の被疑箇所推定装置。

【請求項6】

前記第１の条件、前記第２の条件、前記第３の条件、前記第３'の条件、前記第４の条件、又は前記第５の条件は、当該条件の判定に使用される所要時間に対して、非劣化時の所要時間の集合値との分布形状差分があり、且つ、平均値及び分散値について閾値を上回る差分があり、且つ、有意差があることである、
ことを特徴とする請求項４又は５に記載の被疑箇所推定装置。

【請求項7】

コンピュータが、
複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信手順と、
前記受信手順において受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間についての条件を判定することで、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定手順と、を実行し、
前記推定手順において、Ｗｅｂページの表示過程において移動体通信事業者網を介して通信を行う端末から生成されたログ情報、及び、Ｗｅｂページの表示過程において前記移動体通信事業者網及び仮想移動体通信事業者網を介して通信を行う端末から生成されたログ情報の両方を用いて、仮想移動体通信事業者網を介して通信を行う端末のＷｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する、
ことを特徴とする被疑箇所推定方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、Ｗｅｂブラウジングサービスにおける品質劣化の被疑箇所を推定する技術に関連するものである。

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【先行技術文献】

【特許文献】

【0005】

【特許文献1】本多他、「被疑箇所推定装置及び被疑箇所推定方法」、特開２０１６−９２５００号公報

【特許文献2】吉村他、「被疑箇所推定装置及び被疑箇所推定方法」、特開２０１７−２８５４６号公報

【発明の概要】

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

【0006】

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

【0007】

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

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

【0008】

開示の技術によれば、複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信部と、
前記受信部によって受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間についての条件を判定することで、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、を有し、
前記推定部は、Ｗｅｂページの表示過程において移動体通信事業者網を介して通信を行う端末から生成されたログ情報、及び、Ｗｅｂページの表示過程において前記移動体通信事業者網及び仮想移動体通信事業者網を介して通信を行う端末から生成されたログ情報の両方を用いて、仮想移動体通信事業者網を介して通信を行う端末のＷｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する、
ことを特徴とする被疑箇所推定装置が提供される。

【発明の効果】

【0009】

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

【図面の簡単な説明】

【0010】

【図1】本発明の実施の形態におけるＷｅｂシステムの構成例を示す図である。

【図2】本発明の実施の形態における被疑箇所推定装置のハードウェア構成例を示す図である。

【図3】本発明の実施の形態におけるユーザ端末及び被疑箇所推定装置の機能構成例を示す図である。

【図4】ユーザ端末が実行する処理手順の一例を説明するためのフローチャートである。

【図5】ユーザ端末から被疑箇所推定装置へ送信されるブラウザログの構成例を示す図である。

【図6】Ｗｅｂページの表示処理の処理手順の一例を示す図である。

【図7】ブラウザログに含まれる指標値群の一例を示す図である。

【図8】被疑箇所推定装置が実行する処理手順の一例を説明するためのフローチャートである。

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

図７は、ブラウザログに含まれる指標値群の一例を示す図である。図７に示されるように、１つのブラウザログには、指標値１〜５が含まれる。

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

なお、条件１、条件２、条件３、条件３'、条件４、条件５は、例えば、経験値に基づいて設定されてもよい。例えば、ユーザ端末２０、基地局３０、ＰＯＩ、Ｗｅｂサーバ４０のそれぞれが被疑箇所である状況において収集されたそれぞれのブラウザログの集合に基づいて条件１、条件２、条件３、条件３'、条件４、条件５が設定されてもよい。又は、指標値１〜指標値５について、理論的に求まる正常な値と異常な値との境界が、条件１、条件２、条件３、条件３'、条件４、条件５として設定されてもよい。

【0060】

（実施の形態のまとめ）
以上説明したように、本実施の形態によれば、複数の端末におけるＷｅｂページの表示過程において生成されるログ情報を受信する受信部と、前記受信部によって受信された複数のログ情報のそれぞれが含む、前記表示過程における複数の段階のそれぞれの所要時間についての条件を判定することで、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、を有し、前記推定部は、Ｗｅｂページの表示過程において移動体通信事業者網を介して通信を行う端末から生成されたログ情報、及び、Ｗｅｂページの表示過程において前記移動体通信事業者網及び仮想移動体通信事業者網を介して通信を行う端末から生成されたログ情報の両方を用いて、仮想移動体通信事業者網を介して通信を行う端末のＷｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する、ことを特徴とする被疑箇所推定装置が提供される。

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

なお、本実施の形態において、ユーザ端末２０は、端末の一例である。ユーザ端末２０ａは移動体通信事業者網を介して通信を行う端末の一例である。ユーザ端末２０ｂは移動体通信事業者網及び仮想移動体通信事業者網を介して通信を行う端末の一例である。ブラウザログは、ログ情報の一例である。ログ受信部１１は、受信部の一例である。集合Ｌｔは、第１の集合の一例である。集合Ｌｂは、第２の集合の一例である。集合Ｌｃは、第２'の集合の一例である。集合Ｌｓは、第３の集合の一例である。条件１、条件２、条件３、条件３'、条件４、条件５は、第１の条件、第２の条件、第３の条件、第３'の条件、第４の条件、第５の条件の一例である。

【0067】

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

【符号の説明】

【0068】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】