JP5537692B1 - 品質劣化原因推定装置、品質劣化原因推定方法、品質劣化原因推定プログラム - Google Patents

Abstract

【課題】パッシブ監視によりネットワークから取得したパケットに基づいて、ユーザ体感品質を下げている要因がどの部分にあるかの切り分けを自動的に行うことを可能とする技術を提供する。
【解決手段】通信ネットワークにおける少なくとも２装置間の通信の品質劣化原因を推定する品質劣化原因推定装置において、前記装置間の通信に係るパケットを前記通信ネットワークからキャプチャすることにより取得したキャプチャデータを格納するキャプチャデータ格納手段と、前記キャプチャデータから、前記装置間の通信に係る特性値として、少なくともパケットのリオーダ幅を算出する特性値算出手段と、前記特性値の正常性を判定することにより、前記装置間の通信の品質劣化原因となる箇所を推定する推定手段と、前記推定手段による推定結果を出力する出力手段とを備える。
【選択図】図１

Description

本発明は、通信ネットワークにおけるアプリケーションサービス監視に関わるものであり、特に、アプリケーションサービスにおけるユーザ体感品質の劣化の原因となる箇所を推定する技術に関するものである。

アプリケーションがネットワーク環境においてどの程度の性能が発揮できているか、また利用者に対してストレスを与えていないか、等を測定するためにアプリケーションサービス監視がよく行われている。

アプリケーションサービス監視には、サーバにて直接情報を収集する方法と、外部からシステム全体の動作を推定する方法とがある。直接情報を収集する方法としては、従来から、監視対象のサーバ装置のプロセス情報やＣＰＵ、メモリ等、サーバ性能に関わるパラメータを取得し、監視する方法が一般的に行われている。外部から推定する方法としては、疑似通信を行う測定用プローブを設置してその通信をモニターするアクティブ監視と、実際に流れているユーザ通信をモニターするパッシブ監視がある。

直接情報を収集し監視する手法では、監視対象がサーバだけとなっているため、ネットワーク要因での体感品質劣化など、サーバ要因以外の問題は発見しにくい。これに対して、外部から推定する方法では、ネットワーク要因の問題を発見することができるものの、以下のような課題がある。

アクティブ監視における課題としては、測定結果があくまでも測定用プローブの値となってしまい、測定時間帯の実ユーザとの相関性が取れているのか確認する手段がない等、監視を行う上で、数値化された情報に対する信用性が低いという問題がある。

なお、アプリケーションの品質を評価するための従来技術として、例えば特許文献１，２に記載された技術がある。

特開２０１１−１４２４７３号公報 特開２０１１−１４２４７４号公報

パッシブ監視においては、既存の装置に測定用プローブをインストールしないで済むためユーザ装置への影響がなく、監視パケットをネットワークに流さず実際に行われている通信そのものの品質を直接監視できる長所があり、ユーザ視点での監視を行う場合、パッシブ監視が好まれるケースが多い。

しかしながら、従来のパッシブ監視による方法では、トラヒック情報から算出できる各要素（アプリケーション要素、ネットワーク要素など）の特性値を可視化することは可能であったが、ユーザ体感品質の劣化が発生した原因となる箇所を特定する際には、算出された結果から、オペレータのノウハウや長年の経験に頼らなくてはならないのが現状である。

特にアプリケーション動作の複雑化やユーザ端末の高性能化等により、従来用いていたパケットロスやジッタ等の値を計測及び監視しただけでは、ユーザ体感品質を下げている要因が、サーバ／ネットワーク／端末のどの部分にあるのか、切り分けることができないケースが増加している。

本発明は上記の点に鑑みてなされたものであり、パッシブ監視によりネットワークから取得したパケットに基づいて、ユーザ体感品質を下げている要因がどの部分にあるかの切り分けを自動的に行うことを可能とする技術を提供することを目的とする。

上記の課題を解決するために、本発明は、通信ネットワークにおける少なくとも２装置間の通信の品質劣化原因を推定する品質劣化原因推定装置であって、
前記装置間の通信に係るパケットを前記通信ネットワークからキャプチャすることにより取得したキャプチャデータを格納するキャプチャデータ格納手段と、
前記キャプチャデータから、前記装置間の通信に係る特性値として、少なくともパケットのリオーダ幅を算出する特性値算出手段と、
前記特性値の正常性を判定することにより、前記装置間の通信の品質劣化原因となる箇所を推定する推定手段と、
前記推定手段による推定結果を出力する出力手段と、を備えることを特徴とする品質劣化原因推定装置として構成される。

前記２装置は、例えば、ユーザ端末と、当該ユーザ端末にアプリケーションサービスを提供するサーバであり、前記箇所は、前記ユーザ端末、前記サーバ、又は、当該ユーザ端末と当該サーバとを接続する通信ネットワークである。

前記推定手段は、例えば、前記リオーダ幅と所定の閾値とを比較し、当該リオーダ幅が所定の閾値以上である場合に、前記品質劣化原因となる箇所が前記通信ネットワークにあると判定する。

前記特性値算出手段は、前記装置間の通信に係る特性値として、前記リオーダ幅に加えて、トラヒック流量、ＲＴＴ、パケットロス、ジッタ、セッション確立率、ウィンドウサイズ、及びサーバ応答時間を算出するようにしてもよい。

また、前記推定手段は、トラヒック流量、ＲＴＴ、パケットロス、ジッタ、リオーダ、セッション確立率、ウィンドウサイズ、及びサーバ応答時間の順に正常性の判定を行うこととし、正常でない判定結果が得られた時点で、前記出力手段が判定結果の出力を行うこととしてもよい。

また、前記品質劣化原因推定装置は、前記通信ネットワークのネットワーク構成情報を格納したネットワーク構成情報格納手段を備えてもよく、その場合、前記推定手段は、前記セッション確立率又は前記ウィンドウサイズの正常性を判定する際に、前記ネットワーク構成情報を参照して、前記通信ネットワークにおける前記２装置間に所定の装置が有るか否かを把握し、当該所定の装置が有るか否かに基づく判定を行うこととしてもよい。

また、本発明は、上記品質劣化原因推定装置が実行する品質劣化原因推定方法、及びコンピュータを、前記品質劣化原因推定装置における前記特性値算出手段と前記推定手段として機能させるための品質劣化原因推定プログラムとして構成してもよい。

本発明によれば、パッシブ監視によりネットワークから取得したパケットに基づいて、ユーザ体感品質を下げている要因がどの部分にあるかの切り分けを自動的に行うことが可能となる。

本発明の実施の形態の概要を説明するための図である。 品質劣化原因推定装置１０の機能構成図である。 本発明の実施の形態に係る動作例１を示すフローチャートである。 セッション確立率に関する判定処理例を説明するための図である。 ウィンドウサイズに関する判定処理例を説明するための図である。 本発明の実施の形態に係る動作例２を示すフローチャートである。 本発明の実施の形態に係る動作例３を示すフローチャートである。 表示例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、以下の実施の形態では、８種類の特性値を算出することとしているが、これらは例に過ぎず、これらよりも少ない種類の特性値を算出することとしてもよいし、これらよりも多い種類の特性値を算出することとしてもよい。また、８種類の特性値以外の特性値を含む複数の特性値を算出することとしてもよい。

（システム構成）
本実施の形態では、例えば、図１に示すネットワークシステム構成において、ネットワーク３を流れるパケットをキャプチャし、品質劣化原因推定装置１０において、キャプチャしたパケットを解析することで、ユーザ体感品質に影響を与える種々の特性値を算出し、算出した特性値に基づき、正常性判定やその原因を推定し、結果を出力する。なお、「特性値」とは、少なくとも後述する８種類の値を総称したものである。

図１に示すネットワークシステムは、アプリケーションサービスを提供するサーバ１とユーザ端末２とがネットワーク３を介して接続される構成であり、本実施の形態に係る技術が適用される基本的な構成である。なお、この構成は一例であり、本発明を適用できる構成は図１に示すものに限られない。例えば、３装置以上の装置間での通信に係る品質劣化原因を推定することもできる。

本実施の形態では、品質劣化原因推定装置１０が、ネットワーク３からリアルタイムにパケットをキャプチャして、キャプチャしたパケットに基づき品質劣化原因推定をリアルタイムに行うこととしてもよいし、パケットのキャプチャは別装置が行っておき、品質劣化原因推定装置１０にキャプチャデータを与えることで品質劣化原因推定を行ってもよいが、以下で説明する例では、別装置等において既に取得されたキャプチャデータを用いて解析を行うことを想定している。

また、本実施の形態は、ユーザからユーザ体感品質劣化の申告を受けて、それに応じて解析・判定を行う場合を想定しているが、申告がなくても、定期的に解析・判定を行い、異常が検知された場合に対処を迅速に行うことで、品質劣化をユーザが体感するのを未然に防止することもできる。

図２に、品質劣化原因推定装置１０の機能構成図を示す。図２に示すように、本実施の形態に係る品質劣化原因推定装置１０は、特性値算出部１１、判定部１２、入出力部１３、キャプチャデータ格納部１４、ネットワーク構成情報格納部１５を有する。

特性値算出部１１は、品質劣化原因推定の対象となる装置（本実施の形態では、図１に示すサーバ１とユーザ端末２）を特定する情報（ＩＰアドレス等）と対象時刻の入力を受け、当該時刻を含む所定の時間長において当該装置間で送受信されたキャプチャデータをキャプチャデータ格納部１４から抽出し、当該キャプチャデータから後述する各種特性値を算出する機能部である。

判定部１２は、特性値算出部１１により算出された個々の特性値が正常か否か、また、品質劣化の原因がサーバ、ネットワーク、ユーザ端末のどこにあるのかの推定を行う機能部である。また、判定部１２は、判定結果を記憶する記憶部１２１を備える。

入出力部１３は、品質劣化原因推定装置１０を使用するユーザのユーザインタフェースである。入出力部１３は、ユーザに操作画面を表示し、当該画面を用いて、情報入力や情報表示を行ってもよいし、入出力部１３にユーザ操作端末をネットワーク経由で接続し、ユーザ操作端末において情報入出力を行ってもよい。

キャプチャデータ格納部１４には、ネットワークから取得（キャプチャ）されたデータが格納される。キャプチャデータには、後述する特性値を求めるために必要なデータが含まれているものとする。特に本例では、ＴＣＰパケットについてのパケットロス、リオーダ（reorder）、セッション確立等の特性値算出を行うため、キャプチャデータは、少なくともＴＣＰプロトコルのデータを含む。

また、ネットワークにおける複数のポイントからキャプチャを行う場合、キャプチャデータ格納部１４には、ポイント毎にキャプチャデータが格納される。このとき、特性値算出部１１は、キャプチャポイント毎に特性値算出を行い、判定部１２においても、キャプチャポイント毎に判定を行う。これにより、障害発生箇所の前後でキャプチャデータの取得を行った場合、ポイント毎の判定結果に差分がでるため、障害発生箇所の特定が容易に可能となる。

ネットワーク構成情報格納部１５には、各装置の種類、トポロジー情報（各装置がどの装置と接続されているかを示す情報）、リンク帯域情報等が格納されており、例えば、判定部１２は、ネットワーク構成情報格納部１５を参照することで、対象の装置（サーバとユーザ端末）間に、帯域制御装置等があることを把握できる。

本実施の形態における品質劣化原因推定装置１０は、例えば、１つ又は複数のコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、品質劣化原因推定装置１０の各部が有する機能は、当該品質劣化原因推定装置１０を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。

また、コンピュータを、品質劣化原因推定装置１０における特性値算出部１１と推定手段１２として機能させるための品質劣化原因推定プログラムを提供してもよい。

上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

（品質劣化原因推定装置の動作例１）
以下、上記の構成を備える品質劣化原因推定装置１０の動作例１を、図３のフローチャートに示す手順に沿って説明する。

＜ステップ１：解析対象指定＞
品質劣化原因推定装置１０の特性値算出部１１は、入出力部１３を介して品質劣化原因推定の対象時刻、及び対象装置（本例では、図１のサーバ１とユーザ端末２とする）の情報（ＩＰアドレス、ＭＡＣアドレス等）の入力を受ける。

＜ステップ２：トラヒック流量算出、判定＞
特性値算出部１１は、キャプチャデータ格納部１４におけるデータから、入力された対象時刻、及び対象装置に該当するデータを識別することにより、まず、ユーザ端末２とサーバ１間のトラヒック流量を算出する。より具体的には、所定時間内におけるトラヒック流量の最大値を算出する。そして、判定部１２が、算出されたトラヒック流量とユーザの契約帯域とを比較して、帯域が不足していないかどうか（正常かどうか）を判断し、その結果（帯域不足、ネットワーク原因等）をメモリ等の記憶部１２１に格納する。なお、この時点でこの判定結果を表示してもよい。以下の各ステップでも同様に、各ステップでの判定結果を各ステップの時点で表示してもよい。

トラヒック流量の算出、判定は、上り（ユーザ端末２→サーバ１）と下り（サーバ１→ユーザ端末２）のそれぞれで行ってもよいし、例えば、下りだけで行ってもよい。また、判定については、例えば、契約帯域×０．８とトラヒック流量とを比較し、トラヒック流量が契約帯域×０．８以上である場合に帯域不足であると判定することができる。帯域不足である場合、帯域を圧迫していることになる。

＜ステップ３：ＲＴＴ算出、判定＞
次に、特性値算出部１１は、キャプチャデータを用いて、対象となっているサーバ１とユーザ端末２間のＲＴＴ、より具体的には、ユーザ端末２からパケットを送信してからサーバ１からの応答が返ってくるまでの時間であるＲＴＴ（Round Trip Time）を算出する。ＲＴＴは複数個算出し、その平均値を算出値としてもよい。

判定部１２は、ネットワーク構成情報格納部１５に格納されたネットワーク構成情報に基づき、サーバ１とユーザ端末２間のホップ数や距離等からＲＴＴの理論値を算出し、当該理論値と上記特性値算出部１１により算出されたＲＴＴとを比較することで、ＲＴＴが理論値よりも大きいか否かを判定する。判定結果は記憶部１２１に格納する。なお、ＲＴＴ値の理論値は予め各拠点毎に測定しておいた値を用いてもよい。

ＲＴＴが理論値よりも大きくなる場合、その原因は主に装置間距離やサーバ過負荷による処理遅延等である。

なお、ＲＴＴが大きいときにはジッタが大きくなることが多いが、ジッタの大小に関わらずＲＴＴが大きいときはユーザ体感品質等に問題が発生しやすい。

＜ステップ４：パケットロス算出、判定＞
次に、特性値算出部１１は、キャプチャデータを用いて、サーバ１とユーザ端末２間のパケットロス（具体的にはパケットロス率）を算出する。判定部１２は、パケットロス率を所定の閾値（例：０．１）と比較し、パケットロス率が所定の閾値以上であれば通信に影響を与えるパケットロスが発生していると判定し、閾値未満であれば正常と判定する。判定結果は記憶部１２１に格納される。また、キャプチャポイントが複数存在する場合、上流側（サーバ側）でのパケットロスと下流側（ユーザ端末側）でのパケットロスのそれぞれについて、算出、判定してもよい。

通信に影響を与えるパケットロスが発生する原因は、装置故障やネットワーク装置の処理能力不足（ＣＰＵ、メモリサイズ、…等）、物理的な接続不完全等である。ネットワーク装置処理能力不足によりパケットロスが発生するのは、ネットワーク装置に処理性能を超えたトラフィックが流入した場合、ＣＰＵとメモリの状態などに応じて、流入したパケットの転送を放棄し、パケットの破棄を行うためである。

＜ステップ５：ジッタ算出、判定＞
次に、特性値算出部１１は、キャプチャデータに基づいて、ユーザ端末２とサーバ１間の通信におけるジッタを算出する。ジッタとは、パケットの遅延のばらつき（つまり、到着間隔のばらつき）である。判定部１２は、例えば、ジッタの値を所定の値と比較することで、通信に影響を与えるジッタが発生しているか否かを判定し、判定結果を記憶部１２１に格納する。

トラフィック流量がネットワーク装置（ルータ等）の処理性能限界に近づいてくると、パケット転送におけるジッタが大きくなる。つまり、ジッタが生じる場合、その原因は、ネットワーク装置の処理性能にあることが多い。また、ジッタの程度がひどくなるとパケットロスにつながる。

＜ステップ６：リオーダ（ｒｅｏｒｄｅｒ）幅算出、判定＞
次に、特性値算出部１１は、キャプチャデータを用いて、ユーザ端末２とサーバ１間の通信における所定時間内のパケットのリオーダ幅の平均値を算出する。判定部１２は、算出したリオーダ幅と所定の閾値（例：３）とを比較し、リオーダ幅が閾値以上であれば通信に影響を与えるパケット反転が発生している（異常である）と判定し、リオーダ幅が閾値未満であれば正常であると判定し、判定結果を記憶部１２１に格納する。

リオーダ（reorder）とは、パケットの反転（順序の入れ替わり）のことである。指定時間内に発生したリオーダの割合がリオーダ率であり、リオーダが発生した際のパケットの飛び幅をリオーダ幅と呼ぶ。本実施の形態では、特にリオーダ幅を用いている。例えば、リオーダ幅が３以上になると再送要求が行われ、ウィンドウサイズが低下し、スループットが低下する。

なお、パケットロスが発生していないにも関わらず、品質劣化している場合があるが、このような場合、リオーダ幅が大きい場合がある。つまり、パケットロスの発生がなく一見正常にパケット転送されているように見受けられる場合であっても、リオーダ幅を見ることにより、ネットワーク側に問題があることを推定できる。

なお、リオーダ率が高くても、ＲＴＴが短ければユーザ体感品質は劣化しない場合が多い。そこで、本実施の形態では、ＲＴＴについて先に算出、判定し、リオーダ率については算出していない。ただし、リオーダ率を算出し、所定の閾値と比較するなどの判定を行うこととしてもよい。

リオーダが生じる主な原因は、複数経路による順番制御である。複数経路は、ネットワーク経路の冗長によるものもあれば、ネットワーク装置内で複数ＣＰＵを用いて処理する等の場合も含む。リオーダが発生したとしてもパケットは届いていることがほとんどなので、パケットロスに問題がない場合が多いが、リオーダ幅が大きい場合には再送等の処理負荷が増えるため、ユーザ体感品質が低下する場合が多い。

＜ステップ７：セッション確立率算出、判定＞
次に、特性値算出部１１は、キャプチャデータを用いて、サーバ１とユーザ端末２間におけるＴＣＰセッションのセッション確立率を算出する。セッション確立率とは、セッション確立シーケンスを行った全体数の中での、セッション確立ができた数の割合である。判定においては、セッション確立率をセッション確立失敗率（＝１００％−セッション確立率）に置き換えて判定してもよい。

ここで、サーバ１とユーザ端末２間に、セッション終端を行う装置（例：帯域制御装置、ファイアウォール）が存在する場合、設定条件によってセッション確立をはじく場合がある。そこで、本実施の形態では、判定部１２は、ネットワーク構成情報格納部１５におけるネットワーク構成情報から、セッション終端を行う装置の有無を把握することで、図４に示す手順で判定を行っている。

まず、判定部１２は、セッション確立失敗率が所定の閾値（例：１０％）を超えているかどうかを判定する（ステップ７１）。超えていなければセッション確立は正常であると判定する（ステップ７２）。セッション確立失敗率が所定の閾値を超えている場合、セッションを終端する装置の有無を確認し（ステップ７３）、装置がある場合、セッション終端装置に原因がある可能性があるため、セッション終端装置の処理内容（ログ）を確認する必要があると判定する（ステップ７４）。セッション終端装置がない場合、サーバ１に原因があると判定する（ステップ７５）。判定結果は記憶部１２１に格納される。

なお、ステップ７４に至った場合において、セッション終端装置のログを確認した結果、セッション確立をはじく動作を行っていないことが確認できれば、原因はサーバ１にあると推定できる。そのような場合、サーバ１のＦＷ設定や、ＣＰＵ負荷率等を確認することになる。

＜ステップ８：ウィンドウサイズ(Window size)算出、判定＞
図３に戻り、次に、特性値算出部１１は、キャプチャデータからウィンドウサイズ（所定時間内における最大値）を算出し、判定部１２が所定の閾値との比較等を行うことで正常か異常かを判定する。

サーバ１において適切な設定が行われている場合、論理的な回線帯域にウィンドウサイズが達した場合に、輻輳が発生し、ウィンドウサイズが下がる挙動を示すが、サーバ１の設定が適切でない場合、回線帯域に達する前に、ウィンドウサイズの低下が発生するケースや、ウィンドウサイズ自体が一定に保たれる（のこぎり状にならない）などの挙動を示す。ただし、サーバ１とユーザ端末２との間に帯域制御装置が存在する場合、ウィンドウサイズを大きくしない制御を行って、スループットを上げない制御を行う場合がある。そこで、本実施の形態では、ネットワーク構成情報格納部１５におけるネットワーク構成情報から、帯域制御装置の有無を把握することで、図５に示す手順で判定を行っている。

まず、判定部１２は、所定時間内のウィンドウサイズの最大値が所定の閾値（上記の回線帯域に相当）に達しているかどうかを判定する（ステップ８１）。所定の閾値以上であれば正常なウィンドウサイズ制御が行われていると判定する（ステップ８２）。

ウィンドウサイズの最大値が所定の閾値に達していない場合（ステップ８１のＹｅｓ）、帯域制御装置の有無を確認し（ステップ８３）、帯域制御装置が有る場合、帯域制御装置に原因がある可能性があるため、帯域制御装置のログ確認要と判定する（ステップ８４）。帯域制御装置が無い場合、サーバ１の設定又はアプリケーションに原因があると判定する（ステップ８５）。判定結果は記憶部１２１に格納される。

なお、上記判定処理の中で、ウィンドウサイズの変化のグラフを表示し、ユーザがのこぎり状になっているか否かを判断し、その判断結果を加味して正常性の判定を行うこととしてもよい。

上記ステップ８４に至った場合に帯域制御装置のログを確認した結果、帯域制御装置がフロー制御に介在していないことが分かった場合、原因はサーバ側にあると推定できる。

＜ステップ９：サーバ応答時間算出、判定＞
図３に戻り、次に、特性値算出部１１は、キャプチャデータを用いてサーバ応答時間（本例では所定時間内の最大値）を算出する。サーバ応答時間とは、サーバ１が要求を受けてから、応答を返すまでの時間である。判定部１２は、サーバ応答時間の最大値と所定の閾値とを比較することにより、サーバ性能が正常か否かを判定する。判定結果は記憶部１２１に格納される。

サーバ応答時間が大きい場合、その原因はサーバの性能不足又はアプリケーションの作りにあることが多い。サーバ応答時間が大きくなる場合、ユーザ要求への応答が伸びてしまうなどにより、ユーザ体感品質が低下する。

＜ステップ１０：判定結果出力＞
次に、入出力部１３は、判定部１２により判定され、記憶部１２１に格納されている判定結果を出力する。判定結果の出力においては、正常結果、異常結果の全てを出力してもよいし、正常でない判定結果のみを出力してもよい。また、判定部１２は、上記各判定のうち、ステップ２〜６の少なくとも１つの判定結果に正常でない結果がある場合には、ネットワーク側に品質劣化の要因があると推定し、ステップ２〜６が正常で、かつ、ステップ７〜９の少なくとも１つの判定結果に正常でない結果がある場合には、サーバ側に品質劣化の要因があると推定し、ステップ２〜９の全てが正常である場合には、ユーザ端末側に品質劣化の要因があると推定し、当該推定結果を出力してもよい。これにより、ユーザ（ネットワーク管理者）は、ネットワークに要因があるのか、それともサーバ側に要因があるのか、それともユーザ端末側に要因があるのかを迅速に判断できる。

（その他の例）
上記動作例１では、特性値の算出、判定を全ての特性値において行うこととしている。上記算出／判定の順番は基本的に、順番が先にある特性値の判定結果が良くない場合、それ以降の順番にある判定結果も良くない可能性が高いという関係にある。例えば、回線帯域が圧迫されている場合、ＲＴＴも長くなり、パケットロス、ジッタも増加し、大きな幅のリオーダが発生し易くなり、キャプチャデータから算出されるサーバ応答時間も大きくなる、等である。例外はあるが、概ね、順番が先にある特性値の判定結果が良くない場合、それ以降の順番にある判定結果も良くない結果になる場合が多い。

従って、順番どおりに判定を行うこととして、正常でない判定結果となった時点で、解析を終了して判定結果を出力することとしてもよい。その場合の動作例（動作例２）を図６に示す。図６に示すように、各特性値の算出／判定毎に、判定結果が正常でなければ次の特性値に進まずに、判定結果出力を行うこととしている。各特性値の算出／判定の内容は前述したとおりである。また、この場合も、動作例１の場合と同じように、ネットワーク／サーバ／ユーザ端末のどこに原因があるのかを推定し、出力してもよい。

また、各特性値について算出と判定を行う代わりに、図７に示すように、まず、全ての特性値を求め、記憶部（記憶部１２１でもよいし、その他の記憶領域でもよい）に格納し（ステップ３２）、その後に、各特性値についての判定（ステップ３３）、及び判定結果出力（ステップ３４）を行うようにしてもよい。

なお、判定結果の出力に関しては、「異常」、「正常」、「帯域制御装置のログ確認要」等のように、文字で出力してもよいし、特性値を時系列でグラフ化し、対象時刻において閾値を越えていることを示した画像や、ログ確認要の装置を画像で示したものを出力することとしてもよい。

また、例えば、あるアプリケーションに関して、予め特性値（例：ＲＴＴ値）と実際のユーザが感じる品質（快適値、利用限界値）とを実験で求めておき、サーバと各地点のユーザ端末間で、上述したパケットキャプチャに基づく特性値を算出し、図８に示すような画面で表示することとしてもよい。

（実施の形態のまとめ、効果等）
上述したように、実施の形態によれば、パッシブ監視によりネットワーク上を流れる通信のパケットをキャプチャして、キャプチャデータに基づき各特性値を算出し、各特性値に基づいてユーザ体感品質劣化の要因を推定することから、サーバから直接情報収集をしなくても、品質劣化の要因を自動的に推定することができる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１ サーバ
２ ユーザ端末
３ ネットワーク
１０ 品質劣化原因推定装置
１１ 特性値算出部
１２ 判定部
１３ 入出力部
１４ キャプチャデータ格納部
１５ ネットワーク構成情報格納部
１２１ 記憶部

Claims (8)

1. 通信ネットワークにおける少なくとも２装置間の通信の品質劣化原因を推定する品質劣化原因推定装置であって、
   前記装置間の通信に係るパケットを前記通信ネットワークからキャプチャすることにより取得したキャプチャデータを格納するキャプチャデータ格納手段と、
   前記キャプチャデータから、前記装置間の通信に係る特性値として、少なくともパケットのリオーダ幅を算出する特性値算出手段と、
   前記特性値の正常性を判定することにより、前記装置間の通信の品質劣化原因となる箇所を推定する推定手段と、
   前記推定手段による推定結果を出力する出力手段と
   を備えることを特徴とする品質劣化原因推定装置。
2. 前記２装置は、ユーザ端末と、当該ユーザ端末にアプリケーションサービスを提供するサーバであり、前記箇所は、前記ユーザ端末、前記サーバ、又は、当該ユーザ端末と当該サーバとを接続する通信ネットワークである
   ことを特徴とする請求項１に記載の品質劣化原因推定装置。
3. 前記推定手段は、前記リオーダ幅と所定の閾値とを比較し、当該リオーダ幅が所定の閾値以上である場合に、前記品質劣化原因となる箇所が前記通信ネットワークにあると判定する
   ことを特徴とする請求項２に記載の品質劣化原因推定装置。
4. 前記特性値算出手段は、前記装置間の通信に係る特性値として、前記リオーダ幅に加えて、トラヒック流量、ＲＴＴ、パケットロス、ジッタ、セッション確立率、ウィンドウサイズ、及びサーバ応答時間を算出する
   ことを特徴とする請求項１ないし３のうちいずれか１項に記載の品質劣化原因推定装置。
5. 前記推定手段は、トラヒック流量、ＲＴＴ、パケットロス、ジッタ、リオーダ、セッション確立率、ウィンドウサイズ、及びサーバ応答時間の順に正常性の判定を行うこととし、正常でない判定結果が得られた時点で、前記出力手段が判定結果の出力を行う
   ことを特徴とする請求項４に記載の品質劣化原因推定装置。
6. 前記品質劣化原因推定装置は、前記通信ネットワークのネットワーク構成情報を格納したネットワーク構成情報格納手段を備え、
   前記推定手段は、前記セッション確立率又は前記ウィンドウサイズの正常性を判定する際に、前記ネットワーク構成情報を参照して、前記通信ネットワークにおける前記２装置間に所定の装置が有るか否かを把握し、当該所定の装置が有るか否かに基づく判定を行う
   ことを特徴とする請求項４に記載の品質劣化原因推定装置。
7. 通信ネットワークにおける少なくとも２装置間の通信の品質劣化原因を推定する品質劣化原因推定装置が実行する品質劣化原因推定方法であって、
   前記品質劣化原因推定装置は、前記装置間の通信に係るパケットを前記通信ネットワークからキャプチャすることにより取得したキャプチャデータを格納するキャプチャデータ格納手段を備えており、
   前記キャプチャデータから、前記装置間の通信に係る特性値として、少なくともパケットのリオーダ幅を算出する特性値算出ステップと、
   前記特性値の正常性を判定することにより、前記装置間の通信の品質劣化原因となる箇所を推定する推定ステップと、
   前記推定ステップによる推定結果を出力する出力ステップと
   を備えることを特徴とする品質劣化原因推定方法。
8. コンピュータを、請求項１ないし６のうちいずれか１項に記載の品質劣化原因推定装置における前記特性値算出手段と前記推定手段として機能させるための品質劣化原因推定プログラム。