(57)【要約】【課題】複数のマルチキャスト・トラヒックを定常的に監視し、それを集計することで、サービス品質の劣化箇所の特定を可能とする技術を提供する。【解決手段】マルチキャスト・トラヒック測定システムはＮＷ機器を監視するＩＰＴＶマルチキャスト監視プローブ３２０を備える。ＩＰＴＶマルチキャスト監視プローブ３２０は、ＭＬＤ制御機能部４１３とＰＳＡＭＰサンプリング機能部４１１を備える。ＭＬＤ制御機能部４１３は、監視対象のＮＷ機器に対して、接続要求から解放要求までの時間間隔が予め設定された時間間隔である接続要求と解放要求を複数のマルチキャストについて時間的にずらして繰り返し発行することにより、前記ＮＷ機器に、前記複数のマルチキャストの接続要求から解放要求までのトラヒックのみを配信させる。ＰＳＡＭＰサンプリング機能部４１１は、前記ＮＷ機器から配信されたマルチキャスト・トラヒックに対して前記接続要求から解放要求までの時間間隔よりも短い固定長時間のサンプリングを行う。【選択図】図４
2010206633.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャスト・トラヒックを測定するマルチキャスト・トラヒック測定システムであって、
ＮＷ機器を監視するマルチキャスト監視プローブを備え、
前記マルチキャスト監視プローブは、
監視対象のＮＷ機器に対して、接続要求から解放要求までの時間間隔が予め設定された時間間隔である接続要求と解放要求を複数のマルチキャストについて時間的にずらして繰り返し発行することにより、前記ＮＷ機器に、前記複数のマルチキャストの接続要求から解放要求までのトラヒックのみを配信させる制御機能部と、
前記ＮＷ機器から配信されたマルチキャスト・トラヒックに対して前記接続要求から解放要求までの時間間隔よりも短い固定長時間のサンプリングを行うサンプリング機能部と、
を備えることを特徴とするマルチキャスト・トラヒック測定システム。
【請求項２】
請求項１に記載のマルチキャスト・トラヒック測定システムであって、
前記制御機能部は、前記接続要求と前記開放要求をＭＬＤまたはＩＧＭＰの接続要求メッセージと開放要求メッセージによって行うことを特徴とするマルチキャスト・トラヒック測定システム。
【請求項３】
請求項１または２に記載のマルチキャスト・トラヒック測定システムであって、
前記サンプリング機能部は、
前記ＮＷ機器から配信されたトラヒックに対してマルチキャスト・トラヒックのみをフィルタリングする第１のセレクタと、
前記第１のセレクタでフィルタリングされたマルチキャスト・トラヒックに対して前記固定長時間のサンプリングを行う第２のセレクタと、
前記第２のセレクタでサンプリングされた前記固定長時間の時間内のパケットに対して固定長のパケット間隔でサンプリングを行う第３のセレクタと、
を備えることを特徴とするマルチキャスト・トラヒック測定システム。
【請求項４】
請求項３に記載のマルチキャスト・トラヒック測定システムであって、
前記第３のセレクタがサンプリングした固定長のパケット間隔のパケットのシーケンス番号を用いて、パケットロスを測定することを特徴とするマルチキャスト・トラヒック測定システム。
【請求項５】
請求項３または４に記載のマルチキャスト・トラヒック測定システムであって、
前記第３のセレクタがサンプリングした固定長のパケット間隔のパケットの受信間隔により、パケットの受信間隔を測定することを特徴とするマルチキャスト・トラヒック測定システム。
【請求項６】
請求項１ないし５のうちいずれか１項に記載のマルチキャスト・トラヒック測定システムであって、
前記マルチキャスト監視プローブから配信されるマルチキャスト・トラヒック測定結果を収集するマルチキャスト監視装置を備えることを特徴とするマルチキャスト・トラヒック測定システム。
【請求項７】
マルチキャスト・トラヒックを測定するマルチキャスト・トラヒック測定システムにおけるマルチキャスト・トラヒック測定方法であって、
前記マルチキャスト・トラヒック測定システムは、ＮＷ機器を監視するマルチキャスト監視プローブを備え、
前記マルチキャスト監視プローブは、制御機能部とサンプリング機能部とを備え、
前記制御機能部が、監視対象のＮＷ機器に対して、接続要求から解放要求までの時間間隔が予め設定された時間間隔である接続要求と解放要求を複数のマルチキャストについて時間的にずらして繰り返し発行することにより、前記ＮＷ機器に、前記複数のマルチキャストの接続要求から解放要求までのトラヒックのみを配信させ、
前記サンプリング機能部が、前記ＮＷ機器から配信されたマルチキャスト・トラヒックに対して前記接続要求から解放要求までの時間間隔よりも短い固定長時間のサンプリングを行う、
ことを特徴とするマルチキャスト・トラヒック測定方法。
【請求項８】
請求項１ないし６に記載のマルチキャスト・トラヒック測定システムのためのプログラムであって、前記制御機能部と前記サンプリング機能部としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャスト・トラヒック測定技術に関し、特に複数のマルチキャスト・トラヒックにおけるトラヒック状況及び品質状況を計測可能とするトラヒック情報収集手法とその情報をもとに品質劣化箇所を特定する手法に関する。
【背景技術】
【０００２】
ＩＰＴＶなどに代表されるマルチキャスト配信サービスは、近年、その重要度が増し、サービス品質の提供状態を把握する必要性も増している。また、ＩＰＴＶなどでは、今後、チャネル数が増加することが予想され、より経済的で拡張性のあるトラヒック情報の収集方式が望まれる。網内に流れるパケットのトラヒック情報を収集する手法は、マルチキャストに限らず、従来以下の手法がある。
１）ルータなどのＮＷ（ネットワーク）中継装置にてトラヒック情報を収集し、それをＳＮＭＰ（非特許文献３）、ＮｅｔＦｌｏｗなどで配信することでこれを可能とする。
２）加入者ユーザ宅に配置するＳＴＢ（セットトップボックス）にトラヒック情報を収集する分析する機能をもたせ、この情報を収集することでこれを実現する。
３）トラヒック・キャプチャ・プローブをＮＷ内の各所に配置し、このプローブからの情報をもとに、トラヒック情報を収集する。
【０００３】
しかし、網内のマルチキャスト・トラヒックを監視する手法については、いまだ十分に確立されたものはなく、ネットワーク運用者がサービスの提供状態を把握することは困難な状況となっている。
【０００４】
特許文献１は、上記の従来の手法１）のＮＷ中継装置で品質監視情報を収集する機能を具備することとしているが、このような機能をＮＷ中継装置に具備することは難しい。なぜなら、マルチキャスト・トラヒックが流れるネットワークは、他の膨大なユニキャスト・トラヒックも流れるため、マルチキャストに特化した機能を具備することは実装コストが高くなるためである。また、非特許文献３のようにＭＩＢモジュールを用いて、トラヒックの状況を把握することは可能ではあるが、ＩＰＴＶなどの品質を監視するという点では、これを満たしていない。
【０００５】
これは、特許文献２にあるような従来の手法３）も同等である。特に、ＩＰＴＶの影響により、マルチキャスト・トラヒックそのものが大量となる環境では、そのトラヒック品質を監視することも必要であり、経済的で拡張性のある監視手法については、まだ検討されていないといえる。
【０００６】
また、手法２）では、ＳＴＢなどの加入者端末にてトラヒック情報を収集し、ＮＷ機器と連携することで、その情報収集を可能としている。この場合、ＳＴＢに機能を配置することが必要となり、加入者にそのコストを転化することになることを考えると広範に利用されうるシステムになるとは考えにくい。
【０００７】
また、マルチキャストネットワークに特化した監視システムでは、ＩＰＴＶなどの品質を監視することは満たせない。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−１７２７４８号公報（ストリーム配信管理方法、ストリーム配信管理サーバ装置、ストリーム中継装置）
【特許文献２】特開２００６−１６５７８９号公報（ユーザ体感品質監視装置および方法）
【非特許文献】
【０００９】
【非特許文献１】B. Claise et al "Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information," RFC5101, January 2008.
【非特許文献２】T. Zseby et al. "Sampling and Filtering Techniques for IP Packet Selection," draft-ietf-psamp-sample-tech-11.txt, July 9, 2008.
【非特許文献３】D. McWalter et al. "IP Multicast MIB," RFC5132, December 2007.
【発明の概要】
【発明が解決しようとする課題】
【００１０】
特許文献１は、上記の従来の手法１）のＮＷ中継装置で品質監視情報を収集する機能を具備することとしているが、このような機能をＮＷ中継装置に具備することは難しい。なぜなら、マルチキャスト・トラヒックが流れるネットワークは、他の膨大なユニキャスト・トラヒックも流れるため、マルチキャストに特化した機能を具備することは実装コストが高くなるためである。また、非特許文献３のようにＭＩＢモジュールを用いて、トラヒックの状況を把握することは可能ではあるが、ＩＰＴＶなどの品質を監視するという点では、これを満たしていない。
【００１１】
これは、特許文献２にあるような従来の手法３）も同等である。特に、ＩＰＴＶの影響により、マルチキャスト・トラヒックそのものが大量となる環境では、そのトラヒック品質を監視することも必要であり、経済的で拡張性のある監視手法については、まだ検討されていないといえる。
【００１２】
また、手法２）では、ＳＴＢなどの加入者端末にてトラヒック情報を収集し、ＮＷ機器と連携することで、その情報収集を可能としている。この場合、ＳＴＢに機能を配置することが必要となり、加入者にそのコストを転化することになることを考えると広範に利用されうるシステムになるとは考えにくい。
【００１３】
また、マルチキャストネットワークに特化した監視システムでは、ＩＰＴＶなどの品質を監視することは満たせない。
【００１４】
そこで、ＮＷ内のルータのようなＮＷ機器に特別な機能を配備せず、ＳＴＢのような加入者端末にも機能を配備しないマルチキャスト・計測手法が必要となる。
【００１５】
しかし、この場合、上記手法３）のトラヒック・キャプチャ・プローブを配置する必要があるが、ＩＰＴＶなどのような複数チャネルを継続的にモニタするような手法については、十分に検討が進んでいない。特に、ＩＰＴＶのチャネルが１００チャネルもしくは２００チャネルとなる場合、マルチキャスト・トラヒックのみのトラヒック量が１Ｇｂ／ｓを超えることになり、複数ＩＦを用いた監視が必要となりうる。
【００１６】
一方、近年フロー情報出力機能（非特許文献１）が具備されたルータ、トラヒック・キャプチャ・プローブが普及している。フロー情報出力機能は、転送パケットを、フローと呼ばれるヘッダの何種類かのフィールドが同一のパケット群に集約して、その情報を出力する。最も一般的なフローは、｛送信ＩＰアドレス，受信ＩＰアドレス，送信ポート番号，受信ポート番号，トランスポートプロトコル｝の５組の値が同一の５−ｔｕｐｌｅフローである。このとき全転送パケットを対象にフロー出力するのではなく、ある観測点をながれるパケットをフィルタ機能により選択しフロー出力することも一般的となりつつある。
【００１７】
特に非特許文献２では、さまざまなサンプリング手法が提案されており、それを利用することによる拡張性が期待される。特に、系統的な時間サンプリングによる手法では、ある時間スロット毎のトラヒックをキャプチャすることができればよいため、より効率的となる。ただし、トラヒック・キャプチャ・プローブに流れこむトラヒックは制御できないため、トラヒック・キャプチャ・プローブがもつ性能及びＩＦの帯域を超えるような複数のマルチキャスト・トラヒックを監視することは難しい。また、受信したトラヒックを一定時間間隔で時間サンプリングしても、全トラヒックがＩＦに流入する状況では、トラヒック・キャプチャ・プローブの負荷低減にならないという問題がある。
【００１８】
本発明では上記課題を鑑み、ＩＰＴＶに代表されるネットワーク上を流れる複数のマルチキャスト・トラヒックを定常的に監視し、それを集計することで、サービス品質の劣化箇所の特定を可能とする。
【課題を解決するための手段】
【００１９】
本明細書において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００２０】
第１の発明は、マルチキャスト・トラヒックを測定するマルチキャスト・トラヒック測定システムであって、ＮＷ機器を監視するマルチキャスト監視プローブを備え、前記マルチキャスト監視プローブは、監視対象のＮＷ機器に対して、接続要求から解放要求までの時間間隔が予め設定された時間間隔である接続要求と解放要求を複数のマルチキャストについて時間的にずらして繰り返し発行することにより、前記ＮＷ機器に、前記複数のマルチキャストの接続要求から解放要求までのトラヒックのみを配信させる制御機能部と、前記ＮＷ機器から配信されたマルチキャスト・トラヒックに対して前記接続要求から解放要求までの時間間隔よりも短い固定長時間のサンプリングを行うサンプリング機能部と、を備えることを特徴とする。
【００２１】
第２の発明は、第１の発明において、前記制御機能部は、前記接続要求と前記開放要求をＭＬＤまたはＩＧＭＰの接続要求メッセージと開放要求メッセージによって行うことを特徴とする。
【００２２】
第３の発明は、第１または第２の発明において、前記サンプリング機能部は、前記ＮＷ機器から配信されたトラヒックに対してマルチキャスト・トラヒックのみをフィルタリングする第１のセレクタと、前記第１のセレクタでフィルタリングされたマルチキャスト・トラヒックに対して前記固定長時間のサンプリングを行う第２のセレクタと、前記第２のセレクタでサンプリングされた前記固定長時間の時間内のパケットに対して固定長のパケット間隔でサンプリングを行う第３のセレクタと、を備えることを特徴とする。
【００２３】
第４の発明は、第３の発明において、前記第３のセレクタがサンプリングした固定長のパケット間隔のパケットのシーケンス番号を用いて、パケットロスを測定することを特徴とする。
【００２４】
第５の発明は、第３または第４の発明において、前記第３のセレクタがサンプリングした固定長のパケット間隔のパケットの受信間隔により、パケットの受信間隔を測定することを特徴とする。
【００２５】
第６の発明は、第１〜第５の発明において、前記マルチキャスト監視プローブから配信されるマルチキャスト・トラヒック測定結果を収集するマルチキャスト監視装置を備えることを特徴とする。
【００２６】
第７の発明は、マルチキャスト・トラヒックを測定するマルチキャスト・トラヒック測定システムにおけるマルチキャスト・トラヒック測定方法であって、前記マルチキャスト・トラヒック測定システムは、ＮＷ機器を監視するマルチキャスト監視プローブを備え、前記マルチキャスト監視プローブは、制御機能部とサンプリング機能部とを備え、前記制御機能部が、監視対象のＮＷ機器に対して、接続要求から解放要求までの時間間隔が予め設定された時間間隔である接続要求と解放要求を複数のマルチキャストについて時間的にずらして繰り返し発行することにより、前記ＮＷ機器に、前記複数のマルチキャストの接続要求から解放要求までのトラヒックのみを配信させ、前記サンプリング機能部が、前記ＮＷ機器から配信されたマルチキャスト・トラヒックに対して前記接続要求から解放要求までの時間間隔よりも短い固定長時間のサンプリングを行う、ことを特徴とする。
【００２７】
第８の発明は、第１〜第６の発明のマルチキャスト・トラヒック測定システムのためのプログラムであって、前記制御機能部と前記サンプリング機能部としてコンピュータを機能させるためのプログラムである。
【発明の効果】
【００２８】
本発明によればＮＷ機器の負荷を上げることなく、マルチキャストの論理的な経路を特定し、そこをながれるトラヒック量とその品質を特定することが可能となる。これにより、ネットワーク管理者は、マルチキャストサービスの提供状況や問題発生時の対応、受信側ユーザからの問い合わせに対しても迅速に対応することが可能となる。
【図面の簡単な説明】
【００２９】
【図１】本発明の実施形態のミクロなサンプリングを示す図である。
【図２】本発明の実施形態の接続要求／開放要求によるマクロサンプリングを示す図である。
【図３】本発明の実施例の基本構成の一例を示す図である。
【図４】本発明の実施例のＩＰＴＶマルチキャスト監視プローブの実装概要を示す図である。
【図５】ＭＬＤ送達結果レポートのテンプレートイメージ例を示す図である。
【図６】トラヒック情報、パケットロス情報をＩＰＦＩＸにて配信する情報要素のテンプレートイメージ例を示す図である。
【図７（１）】全Ｐｒｏｂｅの全チャネルの接続状態を表示した描画イメージである。
【図７（２）】単一Ｐｒｏｂｅで受信した全チャネルのトラヒック監視状態を表示した描画イメージである。
【図７（３）】単一チャネルの全Ｐｒｏｂｅでの品質・トラヒック状態を表示した描画イメージである。
【発明を実施するための形態】
【００３０】
以下、本発明の実施の形態を説明する。本発明の実施の形態では、非特許文献２に示した系統的な時間サンプリングの手法を活用する。さらに、マルチキャストのチャネル毎にＪｏｉｎ／ｌｅａｖｅ（接続要求／解放要求）メッセージの発行を時間間隔でサンプリングすることで定常的に、より大量なマルチキャスト・トラヒックの収集と監視を可能とする。
【００３１】
時間粒度の異なるミクロなサンプリング（例：１秒間の中で、１０ｍｓから９００ｍｓまでの時間間隔でトラヒックをキャプチャする。）とマクロなサンプリング（例：１時間の中で、１０分から５０分までの時間間隔でトラヒックをキャプチャする。）を組み合わせることにより、より大量なマルチキャスト・トラヒックの収集と監視を可能とする。
【００３２】
ミクロなサンプリングの手法は、非特許文献２に示される系統的時間サンプリングの手法を活用する。図１では、マルチキャスト・トラヒックのみをフィルタリングしたのちに、固定長時間での系統的な時間サンプリングを行い、パケット・キャプチャ・プローブが受信するパケット数を削減することができる。
【００３３】
図１において、１０１はＳｅｌｅｃｔｏｒ＃１（１１１）によるマルチキャストフィルタリング、１０２はＳｅｌｅｃｔｏｒ＃２（１１２）による固定長時間サンプリング、１０３はＳｅｌｅｃｔｏｒ＃３（１１３）による固定長パケットカウントサンプリングである。１２０は流入するトラヒックであり、○が一つのパケットを表し、同じパターンが同じフローを表す。トラヒック１２０はＳｅｌｅｃｔｏｒ＃１（１１１）によりマルチキャスト・トラヒック１２１のみがフィルタリングされる。マルチキャスト・トラヒック１２１はＳｅｌｅｃｔｏｒ＃２（１１２）により固定長時間サンプリングが行われ、１２２に示すように、Ｓｐａｃｉｎｇ  Ｉｎｔｅｒｖａｌ内のパケットは破棄され、Ｓａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ内のパケットのみがサンプルされる。次に、Ｓｅｌｅｃｔｏｒ＃３（１１３）により、１２３に示すように、パケット間隔＝２のパケットが抽出される。ＲＴＰのシーケンス番号は順序どおりにインクリメントされるので、パケット＃ｉとパケット＃ｊを抽出した際には、「Ｓｅｑｕｅｎｃｅ番号（ｊ）−Ｓｅｑｕｅｎｃｅ番号（ｉ）−２（パケット間隔）」をパケットロスと見なすことにより、パケットロスを検査する。また、パケット間隔＝２で抽出されたパケットの受信間隔からパケット受信間隔を測定する。図１の例ではパケット間隔＝２のパケットをサンプリングしたが、固定長のパケット間隔でパケットをサンプリングすればよい。
【００３４】
また、マクロなサンプリングの手法として、ＭＬＤもしくはＩＧＭＰの接続要求／解放要求メッセージを系統的に時間間隔で発行することで、パケット・キャプチャ・プローブに誘導するパケットを制限しつつ、複数のマルチキャスト・パケットのトラヒック監視を可能とする。ＭＬＤ、ＩＧＭＰの接続要求／解放要求メッセージを制御することで、マクロな時間間隔のサンプリングを実施する。具体的にＭＬＤ  ｖ２の場合、接続要求メッセージはＭｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｒｅｐｏｒｔ  ＭｅｓｓａｇｅのＲｅｃｏｒｄ  Ｔｙｐｅが“ＡＬＬＯＷ＿ＮＥＷ＿ＳＯＵＲＣＥ”の場合を示し、解放要求メッセージは、Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｒｅｐｏｒｔ  ＭｅｓｓａｇｅのＲｅｃｏｒｄ  Ｔｙｐｅが“ＢＬＯＣＫ＿ＯＬＤ＿ＳＯＵＲＣＥ”の場合のときを示す。
【００３５】
この接続要求／解放要求メッセージを繰り返す様子を図２に示す。図２に示すように、接続要求から開放要求までの時間間隔が予め設定された時間間隔（Ｉｎｔｅｒｖａｌ）である接続要求と開放要求をチャネル＃１〜＃２００の２００チャネルのＩＰＴＶトラヒックについて時間的にずらして繰り返し発行し、２００チャネルのＩＰＴＶトラヒックのＩｎｔｅｒｖａｌ内のトラヒックのみを受け付けることにより、各時刻について８０チャネル分のトラヒックのみを受け付ける。このようにマクロなサンプリングがなされた８０チャネル分のトラヒックに対して、前記接続要求から開放要求までの時間間隔より短い固定長時間でミクロなサンプリング（図１の１０２参照）を行い、パケットロスやパケットの受信間隔等のマルチキャスト・トラヒック測定結果を得る。各時刻では８０チャネル分であるが、これを長い時間（図２では１時間以上）続けることにより、２００チャネル分のトラヒックについてのマルチキャスト・トラヒック測定結果を得ることができる。
【００３６】
これにより、たとえば、２００チャネルのＩＰＴＶトラヒック（２．５Ｇｂ／ｓ相当）を１Ｇｂ／ｓ（８０チャネル相当）のＩＦにて監視することを可能にする。なぜなら、ＭＬＤ／ＩＧＭＰ接続要求／解放要求メッセージを繰り返し発行することにより、同時に誘導するチャネル数を８０チャネル分に制御することによって監視対象のトラヒックを１Ｇｂ／ｓ内に抑えた上で、継続的に全２００チャネル分のトラヒック監視を可能とすることができる。上記のような機能をＩＰＴＶマルチキャスト監視プローブに具備し、このプローブにより収集したトラヒック情報やパケットロス数をＩＰＴＶ監視装置に配信することで、非特許文献３）では、実現することができない品質監視を可能とする。なお、図２においては、２００チャネルを８０チャネル分に制御しているが、一般的には、接続要求から解放要求までの時間間隔が予め設定された時間間隔である接続要求と解放要求を複数のマルチキャストについて時間的にずらして繰り返し発行することにより、複数のマルチキャストの接続要求から解放要求までのトラヒックのみを受け付けるように制御すればよい。
【実施例】
【００３７】
以下、図面を用いて本発明の実施例を説明する。
【００３８】
図３は、あるネットワーク上を流れるマルチキャスト・トラヒックデータを対象とする本発明の実施例のマルチキャスト・トラヒック測定システムの基本構成の一例を示す図である。
【００３９】
図３において、３０１はＩＰＴＶマルチキャスト監視装置、３０２はネットワーク、３０３はＩＰＴＶコンテンツプロバイダ、３１１〜３１７はネットワーク３０２に配置されたＮＷ機器（ルータ、スイッチ）、３２１〜３２７はそれぞれＮＷ機器３１１〜３１７に対して配置されたＩＰＴＶマルチキャスト監視プローブ、３３０は特定地域＃Ａ、３４０は特定地域＃Ｂ、３５０は特定地域＃Ｃ、３３１〜３３５は特定地域＃Ａ（３３０）の加入者（端末）、３４１は特定地域＃Ｂ（３４０）の加入者（端末）、３５１は特定地域＃Ｃの加入者（端末）である。
【００４０】
図３の例では、太線の矢印のように、ＩＰＴＶコンテンツプロバイダ３０３からＩＰＴＶマルチキャストストリームがＮＷ機器３１１を経由してＮＷ機器３１２に流れ、そこからＮＷ機器３１３を経由して加入者３４１へ、ＮＷ機器３１４を経由して加入者３３３へ、ＮＷ機器３１５を経由して加入者３３５に流れている。点線で示すように、ＩＰＴＶマルチキャスト監視装置３０１とＩＰＴＶマルチキャスト監視プローブ３２１〜３２７との間でトラヒック収集結果の配信および制御が行われる。
【００４１】
図３に示すように、ある特定拠点を代表するような加入者を収容するＮＷ機器（ルータ）３１３、３１４、３１５、３１７や網内のコアのＮＷ機器（ルータ）３１２、３１６もしくはＩＰＴＶコンテンツプロバイダ３０３との接続点となるＮＷ機器（ルータ）３１１などに対して、ＩＰＴＶマルチキャスト監視プローブ３２１〜３２７を配置する。その際に、全ＮＷ機器に隣接して配置してもよいし、拠点毎に配置することでもよい。
【００４２】
また、ＩＰＴＶマルチキャスト監視装置３０１は、ＩＰＴＶマルチキャスト監視プローブ３２１〜３２７からのトラヒック情報を収集し、トラヒック量やパケットロスなどの品質情報を可視化する。また、各ＩＰＴＶマルチキャスト監視プローブ３２１〜３２７にどのＩＰＴＶチャネルを監視するかを指示する。
【００４３】
図４は、本発明の実施例のＩＰＴＶマルチキャスト監視プローブの実装概要に示す図である。
【００４４】
３０１はＩＰＴＶマルチキャスト監視装置、４０１は設定画面、４０２は測定結果表示である。３２０はＩＰＴＶマルチキャスト監視プローブ（図３の３２１〜３２７の一つに対応する）、４１１はＰＳＡＭＰサンプリング機能部、４１２はＩＰＦＩＸ送信機能部、４１３はＭＬＤ制御機能部、４１４は監視ＩＦである。ＰＳＡＭＰサンプリング機能部４１１は、図１に示すＳｅｌｅｃｔｏｒ＃１（１１１）とＳｅｌｅｃｔｏｒ＃２（１１２）とＳｅｌｅｃｔｏｒ＃３（１１３）を備える。
【００４５】
ＩＰＴＶマルチキャスト監視装置３０１は設定画面４０１によりＩＰＴＶマルチキャスト監視プローブ３２０のＭＬＤ制御機能部４１３に対して設定内容更新（指示）を行う。図４には示していないが、ＩＰＴＶマルチキャスト監視プローブ３２０の左側にはこのＩＰＴＶマルチキャスト監視プローブ３２０が監視する監視対象のＮＷ機器がある。ＩＰＴＶマルチキャスト監視プローブ３２０のＭＬＤ制御機能部４１３は設定に基づいて監視ＩＦ４１４を介してＮＷ機器に対してＭＬＤ接続要求／開放要求を行う。これにより、図２に示すように、ＮＷ機器は、ＮＷ機器を通過する例えば２００チャネルのトラヒックの接続要求から開放要求までのトラヒックのみ、すなわち各時刻について８０チャンネル分のトラヒックのみをＩＰＴＶマルチキャスト監視プローブ３２０に配信する。
【００４６】
ＮＷ機器から配信されたＩＰＴＶパケットはＩＰＴＶマルチキャスト監視プローブ３２０の監視ＩＦ４１４を介してＰＳＡＭＰサンプリング機能部４１１に入力され図１に示す処理等がなされる。ＰＳＡＭＰサンプリング機能部４１１によって測定されたＲＴＰパケットロスおよびＲＴＰ受信間隔等のマルチキャスト・トラヒック測定結果はＩＰＦＩＸ送信機能部４１２に送られ、ＩＰＦＩＸ送信機能部４１２はマルチキャスト・トラヒック測定結果をＩＰＦＩＸにてＩＰＴＶマルチキャスト監視装置３０１に配信し、ＩＰＴＶマルチキャスト監視装置３０１は測定結果表示４０２を行う。
【００４７】
ＩＰＴＶマルチキャスト監視プローブ３２０は、あらかじめ、以下の設定がしてあるものとする。これからの設定条件は、ＩＰＴＶマルチキャスト監視装置３０１から指示されて設定されることでもよい。ＰＳＡＭＰサンプリング機能部４１１では、主に、下記の１）〜３）の設定条件をもとに動作する。また、ＭＬＤ制御機能部４１３では、下記の４）〜５）の条件をもとに動作する。
【００４８】
１）Ｓｅｌｅｃｔｏｒ＃１  マルチキャスト・フィルタリング
・網内に一般的に使用されるマルチキャストアドレスを指定する。または、ＩＰＴＶチャネル単位に、送信元アドレス、マルチキャスト・グループアドレスを指定してもよい。ここで、マルチキャストアドレスは、一般的にＩＰｖ４の場合は２２４．０．０．０から２３９．２５５．２５５．２５５の範囲であり、ＩＰｖ６の場合はｆｆ：：／１６で示される範囲である。送信元アドレスは、ＩＰヘッダの送信元ＩＰアドレス・フィールドに指定されるアドレスであり、マルチキャスト・グループアドレスは、ＩＰヘッダの宛先ＩＰアドレス・フィールドに指定されるマルチキャストアドレスである。ＩＰＴＶチャネルは、ひとつの映像ストリームを意味し、送信元ＩＰアドレスとマルチキャスト・グループアドレスのペアがＩＰＴＶチャネルである。
【００４９】
２）Ｓｅｌｅｃｔｏｒ＃２  固定長時間サンプリング
・Ｓａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（ｍｓ）：受信したパケットを収集する時間間隔（図１参照）。
・Ｓｐａｃｉｎｇ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（ｍｓ）：受信したパケットを破棄する時間間隔（図１参照）。
【００５０】
３）Ｓｅｌｅｃｔｏｒ＃３  固定長パケットカウントサンプリング
・Ｓａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ：収集するパケットのパケット間隔を示す。図１の例ではパケット間隔＝２である。
【００５１】
４）マクロな時間サンプリングパラメータ：
・接続Ｉｎｔｅｒｖａｌ（ｍｉｎ）：ＭＬＤ／ＩＧＭＰにより当該ＩＰＴＶチャネルを視聴する時間間隔（図２参照）。
【００５２】
５）最大チャネル数（ｐ）：図２の例ではｐ＝８０チャネルである。
【００５３】
ＩＰＴＶマルチキャスト監視プローブ３２０の具体的な実装例としては、最大チャネル数（ｐ）分のＭＬＤ／ＩＧＭＰスレッドを生起させ、各ＩＰＴＶチャネルをそのスレッドに割り当てる。各スレッドでは、割り当てられたＩＰＴＶチャネルの中からひとつのチャネルに対して、接続要求をおこない、接続Ｉｎｔｅｒｖａｌ時間経過後に解放メッセージを発行する。その後、同一のスレッドに割り振られた別のＩＰＴＶチャネルに対して接続要求を発行し、接続Ｉｎｔｅｒｖａｌ時間経過後に解放メッセージを発行する。各スレッドでは、割り当てられた複数のＩＰＴＶチャネルで、この動作を繰り返す。これにより、監視ＩＦに流入する最大チャネル数（ｐ）が維持される。
【００５４】
また、網内に配置したＩＰＴＶマルチキャスト監視プローブ３２０に対して、どのＩＰＴＶチャネルを監視対象とするかは、ＩＰＴＶマルチキャスト監視装置３０１から設定内容更新として指示される。この際に、ＩＰＴＶマルチキャスト監視装置３０１では、全ＩＰＴＶチャネルを監視するようにＩＰＴＶマルチキャスト監視プローブに指示することも、ＮＷ機器に流れるＩＰＴＶチャネルだけに絞りこんで、隣接するＩＰＴＶマルチキャスト監視プローブに指示することも可能とする。
【００５５】
以下に、後者の場合の実行手順を示す。
【００５６】
１）ＩＰＴＶマルチキャスト監視装置３０１は、網内のＮＷ機器（ルータ）にＳＮＭＰでアクセスし、当該ルータにマルチキャスト・トラヒックが流れているかを確認する。この際に非特許文献３）に記述されたＩＰ  Ｍｕｌｔｉｃａｓｔ  ＭＩＢモジュールにアクセスし、当該情報を得る。
【００５７】
２）あるマルチキャスト・トラヒックが流れた場合には、｛送信元アドレス，マルチキャスト・グループアドレス｝（以下、｛Ｓ，Ｇ｝という。）を特定し、この｛Ｓ，Ｇ｝の情報を観測したＮＷ機器に隣接するＩＰＴＶマルチキャスト監視プローブに指示する。この｛Ｓ，Ｇ｝の情報が、ＩＰＴＶマルチキャストの１チャネルに相当する。
【００５８】
３）ＩＰＴＶマルチキャスト監視プローブ３２０では、指示を受けた｛Ｓ，Ｇ｝をＭＬＤ制御機能部４１３に通知する。ＭＬＤ制御機能部４１３内では、当該｛Ｓ，Ｇ｝を、あるスレッドに割り振り、ＭＬＤ／ＩＧＭＰにより、ＩＰＴＶマルチキャスト・トラヒックを誘導する。この際、ＭＬＤによる接続要求／解放要求メッセージの結果をＭＬＤ送達結果レポートとして、ＩＰＴＶマルチキャスト監視装置３０１に配信する。送達結果レポートの例として、これをＩＰＦＩＸにて配信した場合の情報要素のテンプレートイメージ例を図５に示す。５０１に示す“ｅｖｅｎｔＩｄｅｎｔｉｆｉｅｒ”は、接続要求＝１もしくは解放＝２を表す。これにより、ＭＬＤもしくはＩＧＭＰでの送達結果レポートを送信可能である。
【００５９】
４）また、上記１）〜３）とは、独立にＩＰＴＶマルチキャスト監視プローブ３２０のＰＳＡＭＰサンプリング機能部４１１では、監視ＩＦ４１４で受信したパケットを検査し、Ｓｅｌｅｃｔｏｒ＃１のマルチキャストフィルタリング機能を用いて、マルチキャスト・パケット以外を破棄する。また、Ｓｅｌｅｃｔｏｒ＃２は、Ｓｅｌｅｃｔｏｒ＃１がフィルタリングしたマルチキャスト・パケットに対して受信時間がＳａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅの時間内であれば、これを収集する。Ｓｅｌｅｃｔｏｒ＃３は、Ｓｅｌｅｃｔｏｒ＃２によりＳａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅの時間内で収集されたパケットに対して、固定長のＳａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ間隔でパケットを抽出し、ＲＴＰヘッダ内のシーケンス番号をもとに、パケットロスを検査する。すなわち、ＲＴＰのシーケンス番号は、順序どおりにインクリメントされるので、パケット＃ｉとパケット＃ｊを抽出した際には、「Ｓｅｑｕｅｎｃｅ番号（ｊ）−Ｓｅｑｕｅｎｃｅ番号（ｉ）−Ｓａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ」をパケットロスと見なすことにより、パケットロスを検査する。また、パケット＃ｉとパケット＃ｊの受信間隔からパケット受信間隔を測定する。
【００６０】
５）ＩＰＦＩＸ送信機能部４１２では、ＰＳＡＭＰサンプリング機能部４１１にて、得られたトラヒック情報、パケットロス情報を編集し、ＩＰＦＩＸパケットとして、ＩＰＴＶマルチキャスト監視装置３０１に配信する。これは、Ｓａｍｐｌｉｎｇ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ終了時を契機に送信されるものとする。図６にＩＰＦＩＸにて配信する情報要素のテンプレートイメージ例を示す。６０１に示す“ｄｒｏｐｐｅｄＤｅｌｔａＰａｃｋｅｔＣｏｕｎｔ”が、パケットロス数を表し、６０２に示す“ＲＴＰ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（Ａｖｅ．）”が、ＲＴＰパケットの受信間隔の平均時間を、６０３に示す“ＲＴＰ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（Ｍａｘ．）”と６０４に示す“ＲＴＰ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（Ｍｉｎ．）”が、ＲＴＰパケットの受信間隔の最大・最小時間をそれぞれ表わす。
【００６１】
６）ＩＰＴＶマルチキャスト監視装置３０１では、受信したＩＰＦＩＸ情報をもとに、プローブ毎、ＩＰＴＶチャネル毎のトラヒック・品質情報を描画する。図７にこの描画イメージを示す。
【００６２】
図７（１）は、全てのＩＰＴＶマルチキャスト監視プローブのチャネルの接続状態を表示した描画イメージである。「Ｓｔａｔｕｓ」の欄が「Ａｃｔｉｖｅ」になっているチャネルがＩｎｔｅｒｖａｌ期間中である。図７（２）は、単一のＩＰＴＶマルチキャスト監視プローブで受信した全チャネルのトラヒック監視状態を表示した描画イメージである。各チャネルについてパケットロスとトラヒック量が表示されている。図７（３）は単一のチャネルの全てのＩＰＴＶマルチキャスト監視プローブでの品質・トラヒック状態を表示した描画イメージである。図７（３）には、武蔵野、関西、仙台の特定地域に配置されたＩＰＴＶマルチキャスト監視プローブでのＩＰＴＶ＃１−ＡＫＯＢＡ−ＴＶの品質・トラヒック状態が示されている。
【００６３】
以上、本発明の実施例を詳細に説明したが、一般的には、本発明の実施例のマルチキャスト・トラヒック測定システムは、ＮＷ機器を監視するマルチキャスト監視プローブを備え、マルチキャスト監視プローブは、監視対象のＮＷ機器に対して、接続要求から解放要求までの時間間隔が予め設定された時間間隔である接続要求と解放要求を複数のマルチキャストについて時間的にずらして繰り返し発行することにより、前記ＮＷ機器に、前記複数のマルチキャストの接続要求から解放要求までのトラヒックのみを配信させる制御機能部と、前記ＮＷ機器から配信されたマルチキャスト・トラヒックに対して前記接続要求から解放要求までの時間間隔よりも短い固定長時間のサンプリングを行うサンプリング機能部と、を備えていればよい。
【００６４】
以上、本発明者によってなされた発明を、前記実施例形態および前記実施例に基づき具体的に説明したが、本発明は、前記実施形態および前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【符号の説明】
【００６５】
１０１…マルチキャストフィルタリング、１０２…固定長時間サンプリング、１０３…固定長パケットカウントサンプリング、１１１…Ｓｅｌｅｃｔｏｒ＃１、１１２…Ｓｅｌｅｃｔｏｒ＃２、１１３…Ｓｅｌｅｃｔｏｒ＃３、１２０…流入するトラヒック、１２１…マルチキャスト・トラヒック、１２２…固定長時間サンプリングが行われるマルチキャスト・トラヒック、１２３…固定時間長パケットカウントサンプリングが行われるパケット、３０１…ＩＰＴＶマルチキャスト監視装置、３０２…ネットワーク、３０３…ＩＰＴＶコンテンツプロバイダ、３１１〜３１７…ＮＷ機器（ルータ、スイッチ）、３２０〜３２７…ＩＰＴＶマルチキャスト監視プローブ、３３０…特定地域＃Ａ、３４０…特定地域＃Ｂ、３５０…特定地域＃Ｃ、３３１〜３３５…加入者（端末）、４０１…設定画面、４０２…測定結果表示、４１１…ＰＳＡＭＰサンプリング機能部、４１２…ＩＰＦＩＸ送信機能部、４１３…ＭＬＤ制御機能部、４１４…監視ＩＦ、５０１…ｅｖｅｎｔＩｄｅｎｔｉｆｉｅｒ、６０１…ｄｒｏｐｐｅｄＤｅｌｔａＰａｃｋｅｔＣｏｕｎｔ、６０２…ＲＴＰ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（Ａｖｅ．）、６０３…ＲＴＰ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（Ｍａｘ．）、６０４…ＲＴＰ  Ｉｎｔｅｒｖａｌ  Ｔｉｍｅ（Ｍｉｎ．）
【図１】
2010206633.tif 000003
【図２】
2010206633.tif 000004
【図３】
2010206633.tif 000005
【図４】
2010206633.tif 000006
【図５】
2010206633.tif 000007
【図６】
2010206633.tif 000008
【図７（１）】
2010206633.tif 000009
【図７（２）】
2010206633.tif 000010
【図７（３）】
2010206633.tif 000011