(57)【要約】【課題】ＲＴＰパケット配信の品質をリアルタイムかつ高精度に評価することができないという問題があった。【解決手段】一実施形態による配信品質評価装置（１１２）は、配信サーバ（映像配信サーバ１〜３）からプロバイダ網（１１０）を介して受信した配信データのトラフィック量の時間的パターンを求める特性情報取得部（１１２３）と、特性情報取得部（１１２３）が求めた時間的パターンの変化に基づき、配信サーバ（映像配信サーバ１〜３）またはプロバイダ網（１１０）における異常状態を検出する異常検出部（１１２３）とを有する。【選択図】図２
2010124230.tif 000002
【特許請求の範囲】
【請求項１】
配信サーバからプロバイダ網を介して受信した配信データのトラフィック量の時間的パターンを求める特性情報取得部と、
前記特性情報取得部が求めた前記時間的パターンの変化に基づき、前記配信サーバまたは前記プロバイダ網における異常状態を検出する異常検出部とを有する配信品質評価装置。
【請求項２】
前記トラフィック量の時間的パターンの変化は前記配信データの周期であり、
前記異常検出部は、前記異常状態が前記配信サーバにおけるものか、前記プロバイダ網におけるものかを特定する、請求項１に記載の配信品質評価装置。
【請求項３】
前記トラフィック量の時間的パターンの変化は前記配信データの１周期における最初のバーストポイントまでの時間であり、
前記異常検出部は、前記最初のバーストポイントまでの時間のみが変化した場合、前記異常状態が前記配信サーバのエンコード処理におけるものであると特定する、請求項１または２に記載の配信品質評価装置。
【請求項４】
前記異常検出部は、前記最初のバーストポイントまでの時間以外が変化した場合、前記異常状態が前記配信サーバのＩＯカードにおけるものであると特定する、請求項３に記載の配信品質評価装置。
【請求項５】
前記トラフィック量の時間的パターンの変化は、パケット到着間隔に対する確率密度のパターンである、請求項１に記載の配信品質評価装置。
【請求項６】
配信サーバから送出された配信データをプロバイダ網を介して受信する段階と、
前記配信データのトラフィック量の時間的パターンを求める段階と、
前記時間的パターンの変化に基づき、前記配信サーバまたは前記プロバイダ網における異常状態を検出する段階とを含む配信品質評価方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット配信の品質評価装置及び方法に関する。
【背景技術】
【０００２】
音声や映像などのリアルタイムサービスの伝送品質は、例えば、音声はＩＴＵ−Ｔ勧告Ｇ．１０７およびＴＴＣ標準ＪＪ−２０１．０１で定義されているＲ値により、映像はＩＴＵ−Ｔ勧告Ｊ．２４１に規定されたパケット伝送品質測定により、評価されている。
【０００３】
また、ＳＩＰサーバや映像配信サーバに品質測定エージェントを配置し、サーバ負荷（例えば、ＣＰＵ使用率やメモリ使用率）やアプリケーション応答を測定することによりサービスの品質を評価する方法が確立されている。
【０００４】
なお、上記に関連して、一定周期で一定期間ごとに、対象サーバごとにパケット数を計数してＲＴＰパケットのトラフィック変動を測定することが知られている。
【特許文献１】特開２００１−１４４７７１号公報
【特許文献２】特許第３６１１８２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記の評価方法では、ＲＴＰパケット配信の品質をリアルタイムかつ高精度に評価することができないという問題があった。
【課題を解決するための手段】
【０００６】
一実施形態による配信品質評価装置は、配信サーバからプロバイダ網を介して受信した配信データのトラフィック量の時間的パターンを求める特性情報取得部と、前記特性情報取得部が求めた前記時間的パターンの変化に基づき、前記配信サーバまたは前記プロバイダ網における異常状態を検出する異常検出部とを有する。
【０００７】
また、一実施形態による配信品質評価方法は、配信サーバから送出された配信データをプロバイダ網を介して受信する段階と、前記配信データのトラフィック量の時間的パターンを求める段階と、前記時間的パターンの変化に基づき、前記配信サーバまたは前記プロバイダ網における異常状態を検出する段階とを含む。
【発明の効果】
【０００８】
ＲＴＰパケット配信の品質をリアルタイムかつ高精度に評価することができる。
【発明を実施するための最良の形態】
【０００９】
図面を参照して実施形態を詳細に説明する。図面を通して、同一または対応する構成要素には同一または対応する参照符号を付した。
【００１０】
以下、映像配信の場合を例にとって説明するが、本発明は音声配信などその他のリアルタイムデータの配信にも適用することができる。
【００１１】
図１は、一実施形態による映像配信ネットワーク１００を示す図である。映像配信ネットワーク１００は、映像配信サーバ１〜３とパケットコピー装置１１１と品質管理システム１１２とを含むプロバイダ網（ＭＶＮＯ／ＳＮＩ）１１０を含む。また、映像配信ネットワーク１００は、コア網ルータ１〜４を含むコア網１２０を含む。さらに、映像配信ネットワーク１００は、パーソナルコンピュータやＩＰテレビ等である映像受信端末１〜３を含むアクセス網１３０を含む。
【００１２】
ＲＴＰパケットは、例えば、プロバイダ網１１０の映像配信サーバ１から送信され、コア網１２０のコア網ルータ１〜４によりルーティングされ、アクセス網１３０の映像受信端末１〜３により受信される。
【００１３】
ＲＴＰパケットは、プロバイダ網１１０のパケットコピー装置１１１（例えば、ＴＡＰ）によりコピーされ、コピーされたＲＴＰパケットは品質管理システム１１２に送られる。
【００１４】
図２は、一実施形態による品質管理システム１１２を示すブロック図である。パケットコピー装置１１１によりコピーされたＲＴＰパケットは、品質管理システム１１２の、ネットワークを流れるパケットを収集するパケット収集部１１２１に送られる。
【００１５】
パケット収集部１１２１により収集されたＲＴＰパケットは、ヘッダ情報からフレームの先頭を検出し、１周期分のフレームを切り出すヘッダ情報解析部１１２２に送られる。
【００１６】
ヘッダ情報解析部１１２２により切り出された１周期分のフレームは、切り出されたフレーム内の特性値を算出する特性情報管理部１１２３に送られる。特性値とは、例えば、１フレームに含まれるトラフィックの山と谷の数や、山と谷の間隔や、山と谷の高低差である。
【００１７】
特性情報管理部１１２３により算出された特性値は、その特性値が閾値を越えたときにユーザにアラームを通知する品質劣化検出部１１２４に送られる。
【００１８】
品質管理システム１１２はさらにデータベース１１２５を含む。一実施形態では、特性情報管理部１１２３は算出した特性値をデータベース１１２５に格納し、品質劣化検出部１１２４はデータベース１１２５にアクセスして、格納された特性値に基づき、その特性値が閾値を越えたときにユーザにアラームを通知してもよい。他の実施形態では、特性情報管理部１１２３は算出した特性値をデータベース１１２５に格納し、必要に応じてデータベース１１２５にアクセスして、格納された特性値を読み出して品質劣化検出部１１２４に送ってもよい。
【００１９】
このように、上記実施形態による配信品質評価装置（品質管理システム１１２）は、配信サーバ（例えば、図１の映像配信サーバ１〜３〜）からプロバイダ網（例えば、図１のプロバイダ網１１０）を介して受信した配信データ（例えば、ＲＴＰパケット）のトラフィック量の時間的パターンを求める特性情報取得部（例えば、特性情報管理部１１２３）を有している。また、上記配信品質評価装置は、特性情報取得部が求めた時間的パターンの変化に基づき、配信サーバまたはプロバイダ網における異常状態（例えば、配信サーバにおけるエンコード処理やＩＯカードの異常や、プロバイダ網における輻輳等のネットワーク異常）を検出する異常検出部（例えば、品質劣化検出部１１２４）とを有する。
【００２０】
図３は、データベース１１２５に格納される特性値を示す配信サーバ情報テーブル３００のデータ構造を示す図である。図４は、特性値を説明するための図である。
【００２１】
配信サーバ情報テーブル３００は、各映像配信サーバ１〜３のＩＰアドレスを示すＩＰアドレステーブル３０１と、ＩＰアドレステーブル３０１とそれぞれ対応付けられた山谷数テーブル３０２、山谷間隔テーブル３０３、山谷高低幅テーブル３０４を含む。
【００２２】
山谷数テーブル３０２は、図４Ａに示したように、１フレームのトラフィック量における山４１と谷４２の数を配信サーバごとに示している。
【００２３】
山谷間隔テーブル３０３は、図４Ｂに示したように、１フレームのトラフィック量における山と谷のペア（山谷間番号で示す）ごとの間隔（ａ〜ｄ）を、配信サーバごとに示している。
【００２４】
山谷高低幅テーブル３０４は、図４Ｃに示したように、１フレームトラフィック量における山と谷（山谷番号で示す）ごとの高低幅を、配信サーバごとに示している。
【００２５】
このように、配信サーバごとに、１周期分のフレームの特性値を測定し、そのパターンの変化を調べることにより、ＲＴＰパケットの配信品質を検出することができる。
【００２６】
図５は、プロバイダ網における異常箇所の切り分けを説明するための図である。図５（Ａ）は正常な場合を示し、図５（Ｂ）は配信サーバに異常がある場合を示し、図５（Ｃ）は配信サーバ以外のプロバイダ網に異常がある場合を示している。
【００２７】
プロバイダ網が正常な場合、図５（Ａ）に示したように、トラフィック量は一定周期で変化することが分かっている。
【００２８】
一方、配信サーバに異常が生じた場合には、図５（Ｂ）に示したように、１周期にかかる時間に一定の遅延が発生することが分かっている。これについては、図６を参照して後で詳しく説明する。
【００２９】
また、ネットワークに異常が生じた場合には、図５（Ｃ）に示したように、１周期にかかる時間にランダムな遅延が発生することが分かっている。これは、他のサービスの負荷（他サービスパケットの割り込み）により、遅延の大きさが変化することが原因である。
【００３０】
図６は、配信サーバ（例えば、図１の配信サーバ１）に異常が生じた場合をさらに詳しく説明するための図である。図６（Ａ）は正常な場合を示し、図６（Ｂ）は配信サーバのＩＯカードに異常が生じた場合を示し、図６（Ｃ）は配信サーバのエンコード処理部に異常が生じた場合を示す。
【００３１】
配信サーバが正常な場合、図６（Ａ）に示したように、符号６１で示した映像配信データのトラフィック量が符号６２で示した性能を有するＩＯカードにより送出されるため、品質管理システム１１２（図１参照）が受信するデータは符号６３のようになる。
【００３２】
配信サーバのＩＯカードに異常が発生した場合、図６（Ｂ）に示したように、符号６１で示した映像配信データのトラフィック量が、符号６４で示した（性能６２よりスループットが低下した）性能を有するＩＯカードにより送出されるため、品質管理システム１１２（図１参照）が受信するデータは符号６５のようになる。符号６５で示した受信データは、符号６３で示した正常時の受信データと比較して、周期が長くなり、山谷の数が多くなり、山谷の高さが低くなっている。
【００３３】
逆に言うと、品質管理システム１１２が受信する受信データの周期が長くなり、山谷の数が多くなり、山谷の高さが低くなっているときには、配信サーバのＩＯカードに異常が発生したとみなすことができる。
【００３４】
配信サーバのエンコード処理部に異常が発生した場合、図６（Ｃ）に示したように、符号６６で示した（輻輳等により処理遅延が発生し、ピークが下がった）映像配信データのトラフィック量が、符号６２で示した性能を有するＩＯカードにより送出されるため、品質管理システム１１２（図１参照）が受信するデータは符号６７のようになる。符号６７で示した受信データは、符号６３で示した正常時の受信データと比較して、周期が長くなっている。
【００３５】
逆に言うと、品質管理システム１１２が受信する受信データの周期が長くなっているときには、配信サーバのエンコード処理部に異常が発生したとみなすことができる。
【００３６】
図７は、一実施形態によるＲＴＰパケット配信の品質評価方法７０を示すフローチャートである。品質評価方法７０は、例えば図２に示した品質管理システム１１２により実行することができる。
【００３７】
品質評価方法７０は、ステップＳ７１において、ネットワークを流れるパケットを収集する。パケットの収集には、例えばそのネットワークにパケットコピー装置（例えば、図２に示したパケットコピー装置１１１）を挿入して、パケットコピー装置がコピーしたパケットを受け取る。
【００３８】
ステップＳ７１に続きステップＳ７３において、収集したパケットのヘッダ情報からフレームの先頭を検出して、１周期分のフレームを切り出す。これは、例えばトランスポート・ストリーム（ＴＳ）パケットのヘッダ情報に含まれるパケットユニット開始表示（ＰＵＳＩ：Packet Unit Start Indicator）を参照することで、先頭パケットかどうかを判定することができる。そして、次の先頭パケットを捕捉するまでの時間を１周期として判断することができる。
【００３９】
ステップＳ７３に続きステップＳ７５において、特性値を算出する。特性値は、例えば、１周期におけるトラフィック量の山谷の数、山谷ごとの間隔、山谷ごとの高低幅である。
【００４０】
ステップＳ７５に続きステップＳ７７において、１周期の間隔が延びているか判断する。もし伸びていなければ（ＮＯ）、ステップＳ７９に進み、パケット配信は正常であると判断する。
【００４１】
一方、ステップＳ７７において１周期の間隔が伸びていれば（ＹＥＳ）、ステップＳ８１に進む。
【００４２】
ステップＳ８１において、１周期の間隔が一定ではなくランダムに延びているか判断する。もしランダムに伸びていれば（ＹＥＳ）、ステップＳ８３に進み、プロバイダ網（ネットワーク）に異常があると判断する。これは図５（Ｃ）を参照して説明した通りである。
【００４３】
一方、ステップＳ８１において１周期の間隔の伸び方がランダムでなければ（ＮＯ）、ステップＳ８５に進む。
【００４４】
ステップＳ８５において、最初のバーストポイントまでの時間のみが大きくなっているか判断する。１周期の最初のデータ送信は、ＩＯカードの最大限の性能まで利用してエンコードデータを送信するため、バーストする特性がある。最初のバーストポイントまでの時間（図４（Ｂ）の区間ａ）のみが大きくなった場合、映像配信サーバ内のエンコード処理部に異常が発生している可能性がある。一方、図４（Ｂ）の区間ｂ、ｃ、ｄの間隔及び構成幅に変化があった場合、ＩＯカードの性能が劣化している可能性がある。さらに、山谷ごとの高低幅の最大値が小さくなっている場合、ＩＯカードの性能が劣化している可能性がある。
【００４５】
そこで、ステップＳ８５において、最初のバーストポイントまでの時間のみが大きくなっている場合（ＹＥＳ）、ステップＳ８７に進み、配信サーバのエンコード処理部に異常があると判断する。
【００４６】
一方、ステップＳ８５において、最初のバーストポイントまでの時間以外も大きくなっている場合（ＮＯ）、ステップＳ８９に進み、配信サーバのＩＯカードに異常があると判断する。
【００４７】
他の実施形態では、映像配信サーバ（例えば、図１の映像配信サーバ１〜３）を含むプロバイダ網（図１のプロバイダ網１１０）の構成要素における異常と、品質管理システム１１２の受信パケットの受信パターンとの間にある、上記以外の因果関係に基づき、品質管理システム１１２の受信パケットの受信パターンにより、プロバイダ網（図１のプロバイダ網１１０）の構成要素における異常を判断してもよい。
【００４８】
このように、一実施形態による配信品質評価方法は、配信サーバから送出された配信データを、プロバイダ網を介して受信する段階（ステップＳ７１）と、前記配信データのトラフィック量の時間的パターン（例えば、山谷数、山谷間隔、山谷高低幅）を求める段階（ステップＳ７３、Ｓ７５）と、前記時間的パターンの変化に基づき、前記配信サーバまたは前記プロバイダ網における異常状態を検出する段階（ステップＳ７７〜Ｓ８９）とを含んでいる。
【００４９】
図８は、特性値による異常判定方法を説明するための図である。図２に示した品質劣化検出部１１２４は、特性情報管理部１１２３から受け取った特性値に基づき、図８に示した特性管理テーブル８００を作成することができる。
【００５０】
特性管理テーブル８００は、配信サーバごとに、領域８０１〜８０３を有している。
【００５１】
領域８０１には山谷の数と、事前に計算またはオペレータから指定された閾値と、山谷の数がその閾値を越えた時に考えられる原因とがエントリーされている。
【００５２】
また、領域８０２には、山谷間番号と、その山谷間の間隔と、事前に計算またはオペレータから指定された閾値と、山谷間の間隔がその閾値を越えた時に考えられる原因とがエントリーされている。
【００５３】
また、領域８０３には、山谷番号と、その山谷の高低幅と、事前に計算またはオペレータから指定された閾値と、山谷の高低幅がその閾値を越えた時に考えられる原因とがエントリーされている。
【００５４】
各領域８０１〜８０３に示す原因は配信サーバの特性ごとにユーザが任意のメッセージを設定することができる。
【００５５】
例えば、配信サーバ２において、山谷間番号２の間隔は４０であり、それに対応する閾値３０を越えているため、エンコード異常が発生していると考えられる。図２を参照して説明したように、品質劣化検出部１１２４は、この原因をアラームとしてユーザに通知することができる。
【００５６】
プロバイダ網（例えば、図１のプロバイダ網１１０）には、各配信サーバへの負荷をバランスさせるために、ロードバランサが配置されることがある。図９は、ロードバランサが配置されたプロバイダ網９１０を示す図である。
【００５７】
プロバイダ網９１０は、映像配信サーバ１〜３と、パケットコピー装置１１１とを含む点では、図１に示したプロバイダ網１１０と同様であるが、各映像配信サーバ１〜３への付加を分散するロードバランサ９１１と、品質管理システム９１２とを含む点で異なる。
【００５８】
プロバイダ網１１０においては、映像配信サーバ１〜３は同一のＩＰアドレスを有し、ロードバランサ９１１のポート番号で区別される。そのため、品質管理システム９１２は、映像配信サーバ１〜３をそのＩＰアドレスだけでなく、ロードバランサ９１１のポート番号に基づいて管理する。したがって、映像配信サーバがロードバランサにより負荷分散されている場合、品質管理システム９１２は、ＩＰアドレスとポート番号とを指定して映像配信サーバを特定する。品質管理システム９１２のその他の構成は、図１に示した品質管理システム１１２と同様である。
【００５９】
上記の実施形態では、品質管理システムにおける受信データの時間的パターンに基づき、プロバイダ網における異常を検出した。他の実施形態では、受信データのパケット到着間隔の確率密度に基づき、プロバイダ網における異常を検出することもできる。図５、図６を参照して説明した受信データの時間的パターンは、受信データのパケット到着間隔の確率密度にも反映される。そこで、必ずしも受信データの時間的パターンを求めなくても、受信データのパケット到着間隔の確率密度を求めることにより、配信サーバやネットワークにおける異常を検出することができる。
【００６０】
図１０は、一実施形態によるプロバイダ網１０１０を示す図である。プロバイダ網１０１０は、パケットコピー装置１０１１と、品質管理システム１０１２と、ネットワーク１０１３とを含む。
【００６１】
パケットコピー装置１０１１は、ネットワーク１０１３を流れてくるパケットＡ〜Ｄをコピーして品質管理システム１０１２に送る。
【００６２】
品質管理システム１０１２は、パケットコピー装置１０１１から受け取るパケットに基づき、パケット到着間隔による確率密度を求める。
【００６３】
例えば、パケットＡ，Ｂ，Ｃ，Ｄが品質管理システム１０１２に到着した時刻をそれぞれｔａ，ｔｂ，ｔｃ，ｔｄとすると、パケット到着間隔は
ｔｂ−ｔａ
ｔｃ−ｔｂ
ｔｄ−ｔｃ
となる。確率密度は、（パケット到着間隔に対するパケット数）／（一定時間の間に品質管理システムで受信した全パケット数）で求めることができる。
【００６４】
図１１は、パケット到着間隔による確率密度の一例としてのグラフ１１００を示す図である。グラフ１１００では、パケット到着間隔が０，７，１７秒前後でそれぞれトラフィックが集中している。データエンコードの種類が同じであれば、配信するコンテンツによらず同様の特性となる。
【００６５】
なお、上記の実施形態による配信品質評価装置または方法により、従来の方法に伴う次のような課題も解決することが可能となることは当業者には明らかであろう。
・音声品質測定等の場合、１０〜２０ｍｓｅｃの一定周期でＲＴＰパケットが送出される。しかし、映像配信の場合、サーバ負荷、エンコード負荷などの影響により、ＲＴＰパケットは必ずしも一定周期で送出されず、配信品質を高精度で監視することが困難である。長い周期でのトラフィックの平均値や総量で評価することも可能ではあるが、配信品質の劣化の検出が遅れてしまうおそれがある。
・短周期で特性を分析する場合、平均値にバラつきが生じる為、評価することが困難である。
・長周期で特性を分析する場合、傾向を平準化することはできるが、分析に時間を要し、かつ突発的変化（激増、激減）の結果が平均値で丸められてしまう。
・サーバが不具合によりデッドロックした場合、同一システム上に存在する品質測定エージェントも影響を受け、正常な評価が出来なくなる。
・品質測定エージェント自身がサービスサーバに負荷をかけ、サービス性能を低下させる
といった課題がある。
【００６６】
以上、本発明の実施の形態について詳述したが、本発明は特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形及び変更が可能である。
【００６７】
上記の実施形態について、以下の付記を記載する。
（付記１）
配信サーバからプロバイダ網を介して受信した配信データのトラフィック量の時間的パターンを求める特性情報取得部と、
前記特性情報取得部が求めた前記時間的パターンの変化に基づき、前記配信サーバまたは前記プロバイダ網における異常状態を検出する異常検出部とを有する配信品質評価装置。
（付記２）
前記トラフィック量の時間的パターンの変化は前記配信データの周期であり、
前記異常検出部は、前記異常状態が前記配信サーバにおけるものか、前記プロバイダ網におけるものかを特定する、付記１に記載の配信品質評価装置。
（付記３）
前記トラフィック量の時間的パターンの変化は前記配信データの１周期における最初のバーストポイントまでの時間であり、
前記異常検出部は、前記最初のバーストポイントまでの時間のみが変化した場合、前記異常状態が前記配信サーバのエンコード処理におけるものであると特定する、付記１または２に記載の配信品質評価装置。
（付記４）
前記異常検出部は、前記最初のバーストポイントまでの時間以外が変化した場合、前記異常状態が前記配信サーバのＩＯカードにおけるものであると特定する、付記３に記載の配信品質評価装置。
（付記５）
前記トラフィック量の時間的パターンの変化は、パケット到着間隔に対する確率密度のパターンである、付記１に記載の配信品質評価装置。
（付記６）
前記配信サーバがロードバランサにより負荷分散されている場合、前記配信サーバが接続されたポート番号により前記配信サーバを特定する、付記１ないし５に記載の配信品質評価装置。
（付記７）
配信サーバから送出された配信データをプロバイダ網を介して受信する段階と、
前記配信データのトラフィック量の時間的パターンを求める段階と、
前記時間的パターンの変化に基づき、前記配信サーバまたは前記プロバイダ網における異常状態を検出する段階とを含む配信品質評価方法。
（付記８）
前記トラフィック量の時間的パターンの変化は前記配信データの周期であり、
前記異常状態を検出する段階は、前記異常状態が前記配信サーバにおけるものか、前記プロバイダ網におけるものかを特定する段階を含む、付記７に記載の配信品質評価方法。
（付記９）
前記トラフィック量の時間的パターンの変化は前記配信データの１周期における最初のバーストポイントまでの時間であり、
前記異常状態を特定する段階は、前記最初のバーストポイントまでの時間のみが変化した場合、前記異常状態が前記配信サーバのエンコード処理におけるものであると特定する段階を含む、付記７または８に記載の配信品質評価方法。
（付記１０）
前記異常状態を特定する段階は、前記最初のバーストポイントまでの時間以外が変化した場合、前記異常状態が前記配信サーバのＩＯカードにおけるものであると特定する段階を含む、付記９に記載の配信品質評価方法。
（付記１１）
前記トラフィック量の時間的パターンの変化は、パケット到着間隔に対する確率密度のパターンである、付記７に記載の配信品質評価方法。
（付記１２）
前記配信サーバがロードバランサにより負荷分散されている場合、前記配信サーバが接続されたポート番号により前記配信サーバを特定する、付記７ないし１１に記載の配信品質評価方法。
【図面の簡単な説明】
【００６８】
【図１】一実施形態による映像配信ネットワークを示す図である。
【図２】一実施形態による品質管理システム１１２を示すブロック図である。
【図３】データベースに格納される特性値を示す配信サーバ情報テーブルのデータ構造を示す図である。
【図４】特性値を説明するための図である。
【図５】プロバイダ網における異常箇所の切り分けを説明するための図である。
【図６】配信サーバに異常が生じた場合をさらに詳しく説明するための図である。
【図７】一実施形態によるＲＴＰパケット配信の品質評価方法を示すフローチャートである。
【図８】特性値による異常判定方法を説明するための図である。
【図９】ロードバランサが配置されたプロバイダ網を示す図である。
【図１０】一実施形態によるプロバイダ網を示す図である。
【図１１】パケット到着間隔による確率密度の一例を示す図である。
【符号の説明】
【００６９】
１００  映像配信ネットワーク
１１０  プロバイダ網
１１１  パケットコピー装置
１１２  品質管理システム
１２０  コア網
１３０  アクセス網
３００  配信サーバ情報テーブル
３０１  ＩＰアドレステーブル
３０２  山谷数テーブル
３０３  山谷間隔テーブル
３０４  山谷高低幅テーブル
９１１  ロードバランサ
９１２  品質管理システム
１０１０  プロバイダ網
１０１１  パケットコピー装置
１０１２  品質管理システム
１１２１  パケット収集部
１１２２  ヘッダ情報解析部
１１２３  特性情報管理部
１１２４  品質劣化検出部
【図１】
2010124230.tif 000003
【図２】
2010124230.tif 000004
【図３】
2010124230.tif 000005
【図４】
2010124230.tif 000006
【図５】
2010124230.tif 000007
【図６】
2010124230.tif 000008
【図７】
2010124230.tif 000009
【図８】
2010124230.tif 000010
【図９】
2010124230.tif 000011
【図１０】
2010124230.tif 000012
【図１１】
2010124230.tif 000013