(57)【要約】【課題】より高精度なＲＴＰストリームを監視するシステムおよび方法を提供する。【解決手段】本発明により、ネットワーク内の第１及び第２エンドポイント間のＲＴＰストリームを監視する装置が提供され、この装置は、ネットワーク内の第１及び第２エンドポイントの間の中間点に接続され、ＲＴＣＰパケットからデータを抽出及び処理してネットワーク内の最悪のケースのジッタ及びパケットロスを有する蓄積されたＲＴＰストリームを選択及び監視するネットワークアナライザを含んでいる。【選択図】図３
2004129275.tif 000002
【特許請求の範囲】
【請求項１】
　ネットワーク内の第１及び第２エンドポイント間のＲＴＰストリームを監視する装置であって、
　前記ネットワーク内の第１及び第２エンドポイントの間の中間点に接続されたネットワークアナライザであり、
　該ネットワークアナライザが、ＲＴＣＰパケットからデータを抽出及び処理して前記ネットワーク内の最悪のケースのジッタ及びパケットロスを有する蓄積されたＲＴＰストリームを選択及び監視する、ネットワークアナライザと、
を有する装置。
【請求項２】
　前記ネットワークアナライザが、
　それぞれのＲＴＰストリームに関連するＲＴＣＰパケットを蓄積し、
　最大データ値を有する既定数のＲＴＣＰパケットを選択し、
　前記選択したＲＴＣＰパケットを処理して追加データを抽出し、データ伝送エラーを監視する、請求項１に記載の装置。
【請求項３】
　前記ＲＴＣＰパケットがＳＲ及びＲＲパケットを有しており、前記ＲＲパケットを解析してジッタ及びパケットロスデータを抽出し、前記ＳＲパケットを解析して、送信されたパケット及びオクテット数に対応するデータを抽出する、請求項１に記載の装置。
【請求項４】
　前記ネットワークアナライザに接続され、前記ＲＴＣＰパケット及びデータを表のフォーマットで表示する画面を更に有する、請求項１に記載の装置。
【請求項５】
　前記ネットワークアナライザが、
　前記ＲＴＣＰパケットの中の１つを選択し、
　前記選択したＲＴＣＰパケットに対応する抽出したジッタ、パケットロス、パケット数、又はオクテット数を示すグラフを表示する、請求項３に記載の装置。
【請求項６】
　前記画面が、前記ＲＴＰストリームに対応するデータと共に、それぞれのＲＴＣＰパケットに関連するＲＴＰストリームを表示する、請求項４に記載の装置。
【請求項７】
　前記ＲＴＰストリームの追加データをＱｏＳと組み合わせて使用し、データ伝送エラーが発生している場所を判定する、請求項２に記載の装置。
【請求項８】
　ネットワーク内の第１及び第２エンドポイント間のＲＴＰストリームを監視する方法であって、
　前記第１及び第２エンドポイントの間の中間点において、前記第１及び第２エンドポイント間で伝送されるＲＴＣＰパケットを抽出するステップと、
　前記ＲＴＣＰパケットを解析しデータを抽出するステップと、
　それぞれのＲＴＣＰパケットに対応するＲＴＰストリームを蓄積するステップと、
　前記ＲＴＣＰパケットから抽出されたデータの中の少なくとも１つを選択するステップと、
　前記選択したデータの中の少なくとも１つに基づいて前記ＲＴＣＰパケットをソートするステップと、
　既定数のＲＴＣＰパケットを選択して処理し、データ伝送エラーを引き起こしている前記ネットワーク内の地点を判定するステップと、
を有する方法。
【請求項９】
　それぞれのＲＴＣＰパケットに関連するＲＴＰストリームを蓄積するステップと、
　最大のデータ値を有するＲＴＰストリームを選択するステップと、
　前記選択したＲＴＣＰパケット及び／又はＲＴＰストリームを処理して追加データを抽出し、データ伝送エラーを監視するステップと、
を更に有する請求項８に記載の方法。
【請求項１０】
　前記ＲＴＣＰパケットを解析するステップが、前記ＲＴＣＰパケット内のＳＲ及びＲＲパケットを解析するステップを有し、前記データが、前記ＲＲパケットから抽出されるジッタ及びパケットロスデータを有し、前記データが、前記ＳＲパケットから抽出される送信されたパケット及びオクテット数に対応している、請求項８に記載の方法。
【請求項１１】
　前記ＲＴＣＰパケットと前記データを表のフォーマットで表示するステップを更に有する、請求項８に記載の方法。
【請求項１２】
　前記ＲＴＣＰパケットの中の１つを選択するステップと、
　前記選択したＲＴＣＰパケットに対応するジッタ、パケットロス、パケット数、又はオクテット数を示すグラフと前記選択したＲＴＣＰパケットと関連するＲＴＰストリームを前記ＲＴＰストリームに対応するデータと共に表示するステップと、
を更に有する請求項１０に記載の方法。
【請求項１３】
　ネットワーク内の第１及び第２エンドポイント間のＲＴＰストリームを監視する方法であって、
　前記ネットワーク内の第１及び第２エンドポイントの間に中間点を選択するステップと、
　前記第１及び第２エンドポイント間で伝送されるＲＴＣＰ　ＳＲ／ＲＲパケットを抽出するステップと、
　前記ＲＴＣＰ　ＳＲ／ＲＲパケットを解析してデータを抽出するステップと、
　それぞれのＲＴＣＰ　ＳＲ／ＲＲパケットに対応するＲＴＰパケットを蓄積するステップと、
　前記ＲＴＣＰ　ＳＲ／ＲＲパケットから抽出されたデータの中の少なくとも１つを選択するステップと、
　前記選択したデータの中の少なくとも１つに基づいて、前記ＲＴＣＰ　ＳＲ／ＲＲパケット及び対応するＲＴＰストリームをソートするステップと、
　最大のデータ値を有する既定数のＲＴＣＰ　ＳＲ／ＲＲパケット及び／又はＲＴＰストリームを選択するステップと、
　前記選択したＲＴＣＰ　ＳＲ／ＲＲパケット及び／又は対応するＲＴＰストリームから追加データを抽出し、データ伝送エラーを引き起こしている前記ネットワーク内の第１及び第２エンドポイント間の場所を判定するステップと、
有する方法。
【請求項１４】
　前記ＲＴＣＰ　ＳＲ／ＲＲパケットを解析するステップが、前記ＲＴＣＰパケット内のＳＲ及びＲＲパケットを解析するステップを有し、前記データが、前記ＲＲパケットから抽出されるジッタ及びパケットロスデータを有する、請求項１３に記載の方法。
【請求項１５】
　前記データが、前記ＳＲパケットから抽出される、送信されたパケット及びオクテット数に対応するデータを更に有する、請求項１４に記載の方法。
【請求項１６】
　前記ＲＴＣＰ　ＳＲ／ＲＲパケット及び／又はＲＴＰストリームから抽出されたデータを表示するステップを更に有する請求項１４に記載の方法。
【請求項１７】
　前記ＲＴＣＰ　ＳＲ／ＲＲパケット及び対応するＲＴＰストリームをソートするステップが、前記選択したデータの中の少なくとも１つの値に基づいて降順でソートする、請求項１３に記載の方法。
【請求項１８】
　前記ＲＴＣＰ　ＳＲ／ＲＲパケットから抽出されたデータが往復遅延情報を更に有し、
該往復遅延情報は、前記ＳＲ／ＲＲパケット、平均ジッタ、標準偏差、及びＲＴＰストリームの時間幅の組み合わせを使用して算出される、請求項１３に記載の方法。
【請求項１９】
　それぞれに重み付け値としきい値が設定された前記ジッタ及びパケットロスに基づいて、ＱｏＳを判定するステップを更に有する請求項１３に記載の方法。
【請求項２０】
　前記ＲＴＣＰ　ＳＲ／ＲＲパケットの中の１つを選択するステップと、
　前記選択したＲＴＣＰ　ＳＲ／ＲＲパケットに対応するジッタ、パケットロス、パケット数、又はオクテット数を示すグラフを表示するステップと、
を更に有する請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、ＲＴＣＰ　ＳＲ／ＲＲパケット情報を使用してＲＴＰストリームを監視するシステム及び方法に関する。
【背景技術】
【０００２】
　リアルタイムプロトコル（ＲＴＰ）は、オーディオ、ビデオ、或いはシミュレーションデータなどのリアルタイムデータをマルチキャスト又はユニキャストネットワークサービスを介して伝送するアプリケーションに適したエンドツーエンドのネットワーク搬送機能を提供するものである。ＲＴＰストリームは、リソース予約を行わず、リアルタイムサービスのＱｏＳ（quality-of-service）の保証も行わない。データ搬送を制御プロトコル（ＲＴＣＰ）によって強化し、大規模なマルチキャストネットワークに拡張可能な方式でデータ搬送を監視できるようにすると共に、最低限の制御と識別機能を提供している。ＲＴＰ及びＲＴＣＰは、基盤となるトランスポート及びネットワークレイヤから独立するべく設計されている。既存の監視システムは、例えば、音声通話の品質やデータ伝送の品質を監視するべく、ネットワーク内の任意の地点で最悪のケースのＲＴＰストリームを判定することができない。この最悪のケースのＲＴＰストリームの判定に伴う問題点の１つが、エンドポイント間で伝送されるすべてのＲＴＰストリームをチェック及び分析するのに利用可能な処理能力である。例えば、ネットワーク内の任意の地点を通過するＲＴＰストリームの数は数千にも及び、このため、任意の地点を通過するそれぞれのＲＴＰストリームを分析することは、既存の処理技術ではできないのである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
　従来、最悪のケースのＲＴＰストリームの分析は、２つの方式によって実行されている。第１の方式は、格段に低速（即ち、ＲＴＰストリームの帯域幅の５％未満）で出現するＲＴＣＰ ＲＲ（receiver report）パケット及びＲＴＣＰ ＳＲ（sender report）パケットをチェックするものである。しかしながら、ＲＴＣＰ　ＲＲパケットには、ネットワークのエンドポイントで観測されるジッタ（jitter）及びパケットロス情報が含まれており、これらは、ネットワーク内の問題を引き起こしている場所の判定を妨げる。ＲＴＰストリームをチェックするユーザーがネットワーク内の問題が発生している地点を判定できないため、これらのジッタ及びパケットロス情報は許容することができない。第２の方式は、ＲＴＰパケットストリームを監視するものである。選択基準を設定せずに、観測される順番でＲＴＰストリームを選択する。この第２の方式は、正確な情報を提供することができるが、すべてのＲＴＰストリームを監視するには、利用可能な処理能力が不十分である。
【０００４】
　本発明の目的は、かかる問題を克服し、より高精度なＲＴＰストリームを監視するシステムおよび方法を提供することである。
【課題を解決するための手段】
【０００５】
　前述及びその他の目的を実現するべく、本発明により、ネットワーク内の第１及び第２エンドポイント間のＲＴＰストリームを監視する装置が提供され、この装置は、ネットワーク内の第１及び第２エンドポイントの間の中間点に接続され、ＲＴＣＰパケットからデータを抽出及び処理してネットワーク内の最悪のケースのジッタ及びパケットロスを有する蓄積されたＲＴＰストリームを選択及び監視するネットワークアナライザを含んでいる。
【０００６】
　前述及びその他の目的を実現するべく、本発明により、ネットワーク内の第１及び第２エンドポイント間のＲＴＰストリームを監視する方法が更に提供され、この方法は、第１及び第２エンドポイントの間の中間点において、第１及び第２エンドポイント間で伝送されるＲＴＣＰパケットを抽出するステップと、ＲＴＣＰパケットを解析しデータを抽出するステップと、それぞれのＲＴＣＰパケットに対応するＲＴＰストリームを蓄積するステップと、ＲＴＣＰパケットから抽出されたデータの中の少なくとも１つを選択するステップと、この選択したデータの中の少なくとも１つに基づいてＲＴＣＰパケットをソートするステップと、既定数のＲＴＣＰパケットを選択及び処理し、データ伝送エラーを引き起こしているネットワーク内の地点を判定するステップと、を含んでいる。
【０００７】
　前述及びその他の目的を実現するべく、本発明により、ネットワーク内の第１及び第２エンドポイント間のＲＴＰストリームを監視する方法が更に提供され、この方法は、ネットワーク内の第１及び第２エンドポイントの間の中間点を選択するステップと、第１及び第２エンドポイント間で伝送されるＲＴＣＰ　ＳＲ／ＲＲパケットを抽出するステップと、ＲＴＣＰ　ＳＲ／ＲＲパケットを解析しデータを抽出するステップと、それぞれのＲＴＣＰ　ＳＲ／ＲＲパケットに対応するＲＴＰストリームを蓄積するステップと、ＲＴＣＰ　ＳＲ／ＲＲパケットから抽出されたデータの中の少なくとも１つを選択するステップと、この選択したデータの中の少なくとも１つに基づいてＲＴＣＰ　ＳＲ／ＲＲパケット及び対応するＲＴＰストリームをソートするステップと、最大のデータ値を有する既定数のＲＴＣＰ　ＳＲ／ＲＲパケット及び／又はＲＴＰストリームを選択するステップと、この選択したＲＴＣＰ　ＳＲ／ＲＲパケット及び／又は対応するＲＴＰストリームから追加データを抽出しデータ伝送エラーを引き起こしているネットワーク内の第１及び第２エンドポイントの間の場所を判定するステップと、を含んでいる。
【０００８】
　これら、及び以降で明らかとなるその他の態様と利点については、以下に詳細に説明並びに権利を主張する構造及び動作の詳細に示されている。又、以下説明においては、本明細書の一部を形成する添付の図面を参照しているが、それらの図面においては、同様の参照符号によって同様の要素を示している。
【０００９】
　添付の図面と関連し、以下の詳細な説明を参照することにより、本発明の前述及びその他の目的、特徴、及びその他の利点について明瞭に理解されるであろう。
【発明を実施するための最良の形態】
【００１０】
　以下、添付の図面を参照し、本発明の実施例について詳細に説明する。但し、本発明は、多数の異なる形態で実施可能であって、本明細書に記述する実施例に限定されるものではなく、それらの実施例は、本開示を十分且つ完全なものにすると共に、本発明の概念を当業者に十分に伝達するべく提示するものである。
【００１１】
　ＲＴＰは、特定のフォーマットを有し、固定された、或いは決定論的に変化するヘッダフィールドを有している。これらのフィールドには、シーケンス番号、タイムスタンプ、ＳＳＲＣ（synchronization source、同期送信元）識別子、及びＣＳＲＣ（contributing source、寄与送信元）識別子用のフィールドが含まれている。このヘッダフィールドをＲＴＰヘッダー拡張によって拡張し、追加情報のＲＴＰデータパケットヘッダでの搬送を必要とする新しいペイロードフォーマットから独立した機能を提供可能である。更に、ＲＴＰストリーム内のＲＴＣＰパケットは、制御情報用のパケットフォーマットとヘッダフィールドを有している。ＲＴＣＰヘッダには、ローカルな電話ソース（即ち、ソース）が生成したタイミングを着信側の電話レシーバー（即ち、レシーバー）が再構築できるようにするタイミング情報とシーケンス番号が含まれている。図１は、ヘッダ、センダー情報、レポートブロック１、及びレポートブロック２を含むセンダーレポートＲＴＣＰパケットを示している。図２は、レシーバーレポートＲＴＣＰパケットを示している。レシーバーレポート（ＲＲ）パケットのフォーマットは、パケットタイプフィールドに２０１という定数が格納されており、センダー情報の５ワード（即ち、ＮＴＰ及びＲＴＰタイムスタンプ及びセンダーのパケット及びオクテット数）が省略されていることを除き、センダーレポート（ＳＲ）パケットのフォーマットと同一である。ＲＴＣＰパケットには、ＲＲ（レシーバーレポート）及びＳＲ（センダーレポート）のいずれか、或いは、ＲＲ及びＳＲレポートの両方を格納することができる。
【００１２】
　ＲＴＰストリームには、通常、１秒当たり３０〜５０のＲＴＰデータパケットが含まれており、通常、２〜５秒の間隔で１つのＲＴＣＰパケットが送信される。ＲＴＣＰパケットとは、センダーレポート（ＳＲ）及び／又はレシーバーレポート（ＲＲ）パケットである。両方のレポートタイプが存在する場合には、これらは同一の物理パケットに合成される。本発明の実施例に従い、定期的にそれぞれのＳＲ及びＲＲパケットから情報を抽出及び処理して、監視用にユーザーに提供することができる。ソースとレシーバー間で伝送されるＲＴＰストリームのデータパケット数が多いため、例えば、データバッファを含むＲＴＰストリームを監視するプロセッサの処理能力と容量は、すべてのＲＴＰストリームを監視には不十分である。これらの場合、通常、監視機器のデータバッファにおいてデータのオーバーランが発生する（ＲＴＰストリームがオーバーレイする）。本発明によれば、すべてのＲＴＰストリームをチェックするのではなく、ＲＴＰストリーム内の要約パケットであってＲＴＰストリームに比べて格段にその出現速度が低いＲＴＣＰパケットを使用し、最悪のケースのＲＴＰストリームを選択及び監視する。
【００１３】
　ＳＲパケット及びＲＲパケットは、同一のＲＴＣＰパケット内に共存可能であり、別個のＲＴＣＰパケットで提供することもできる。説明のために、本明細書においては、ＲＴＣＰパケットにＳＲパケットとＲＲパケットの両方が含まれている本発明による一実施例について説明するが、ＲＴＣＰパケットにＲＲパケット及びＳＲパケットのいずれかが含まれる実施例も可能である。
【００１４】
　図３は、本発明の一実施例に従って、ＲＴＣＰパケットを使用してＲＴＰストリームを監視する通信システムの構成を示す図である。発信側の電話機１０（即ち、ソース）及び受信側の電話機１２（即ち、レシーバー）は、ＶＯＩＰ（Voice Over Internet Protocol）ゲートウェイ２４、２６を介して通信ネットワーク２０にアクセスする。代替構成においては、この通信ネットワーク２０は、ＬＡＮ／ＷＡＮ、或いはその他のＩＰネットワークなどの可変遅延ネットワークであってよい。ＶＯＩＰゲートウェイ２４、２６は、インターネットプロトコルを使用しネットワーク２０を介してソース１０とレシーバー１２間の通話をルーティングし、ＲＴＰヘッダを使用してＲＴＰジッタバッファリングとオーディオフレームのカプセル化を実行する。既存のシステムの場合には、ソース１０とレシーバー１２間のＲＴＰストリームを監視するには、ソース１０とレシーバー１２が直接接続されているネットワークのエンドポイントにネットワークアナライザを接続する必要がある。しかしながら、このような、データ搬送を監視するために、通信、ケーブル、又はインターネットサービスプロバイダがソース１０又はレシーバー１２に（即ち、電話ネットワークのエンドポイントに）ネットワークアナライザを接続しなければならない既存のシステムとは異なり、本システムの場合には、プロバイダは、ネットワークアナライザをネットワーク内のどこにでも接続可能である。従って、例えば、サービス要員には、本発明のシステムを内蔵するネットワークアナライザをネットワーク内のどこにでも接続できるという柔軟性が付与されることになる。
【００１５】
　マサチューセッツ州アンドバーに所在するアジレントテクノロジー社の「J6844A Telephony Network Analyzer」などの電話通信ネットワークアナライザ３０をネットワーク２０内に接続し、ソース１０とレシーバー１２間のＩＰトラフィック（例：ＲＴＰデータ）を監視することができる。又、電話通信ネットワークアナライザ３０には、磁気及び光ディスク、ＲＡＭ、ＲＯＭなどの固定又はリムーバブルなストレージを有するプロセッサが含まれており、本発明のプロセス（即ち、方法）及びデータ構造をそれらに保存して配布することが可能である。尚、図示されている通信ネットワーク２０は１つだけであるが、複数のものが存在してもよい。
【００１６】
　図４は、本発明の一実施例に従って、ソース１０とレシーバー１２間のＲＴＣＰ　ＳＲ／ＲＲパケットを監視するシステムを示す図である。ＰＯＡ（Ｐｏｉｎｔ　ｏｆ　Ａｎａｌｙｓｉｓ：分析点）とは、本発明の一実施例に従って、ＲＴＣＰ　ＳＲ／ＲＲパケットを含むＲＴＰストリームを監視するべく、電話通信ネットワークアナライザ３０を接続するネットワーク内の地点を意味している。この図４に示されているように、ソース１０から、ＲＴＰストリームとＲＴＣＰ　ＳＲパケットがレシーバー１２に対して出力される。レシーバー１２は、これを受信し、ＲＴＰストリームとＲＴＣＰ　ＲＲパケットをソース１０に対して返送する。ネットワークアナライザは、ＰＯＡにおいて、これらのＳＲ／ＲＲパケットを抽出しＲＴＰストリームを監視する。
【００１７】
　ネットワーク内のＰＯＡにネットワークアナライザを接続した後に、ソース１０及びレシーバー１２間のインターネット又は通信トラフィックを監視する。ＲＴＣＰパケットには、エンドポイント（即ち、ソース１０及びレシーバー１２）が観測するものの要約が格納されており、格段に低いデータレートで出現する（通常、その回数は、ＲＴＰデータパケットに対して２５０：１未満であることが多い）。従って、本発明の一実施例によるネットワークアナライザは、ＰＯＡにおいてソース１０とレシーバー１２間のＲＴＣＰ　ＳＲ／ＲＲパケットを抽出及び監視するべく設計されている。このネットワークアナライザは、従来の方法を使用してＲＴＣＰ　ＳＲ／ＲＲパケットを抽出する。そして、ＰＯＡにおいて、ＲＴＣＰ　ＳＲ／ＲＲパケットを抽出すると、ＲＲパケットを解析し、ジッタ及びパケットロスデータを抽出する。同様に、ＳＲパケットを解析し、送信されたパケット及びオクテット（octet）の数に対応するデータを抽出する。ＳＲ／ＲＲからは、ＳＲ／ＲＲパケット、平均ジッタ、標準偏差、及びＲＴＰストリームの時間幅の組み合わせを使用して算出される往復遅延情報などの追加情報を抽出並びに提供することもできる。即ち、ＲＴＣＰ情報が出現するデータレートは格段に低速であり、ネットワークアナライザは、ＲＴＰストリーム全体の追跡を試みるのではなく、ＲＴＣＰパケットを追跡すればよいのである。
【００１８】
　更に、それぞれ重み付け値としきい値を設定したジッタ及びパケットロスに基づいて、ＱｏＳ（quality of service）を判定することも可能である。まず、ユーザー定義可能なしきい値をジッタとパケットロスの両方に設定する。これらのユーザー定義可能なしきい値は、ＱｏＳ値が上昇してユーザー定義可能なしきい値を上回るまで、ジッタ（又は、パケットロス）によるＱｏＳの低下を防止する。又、ＱｏＳでは、ジッタ又はパケットロスの相対的な重み付けを考慮することもできる。この相対的な重み付けは、ユーザーインターフェイス（図示されていない）を介してスライダバーによって設定するが、スライダバーの一端においては、ジッタの重み付けの重要度が１００％に設定され、スライダバーの他端において、パケットロスの重み付けの重要度が１００％に設定される。スライダバーの中央においては、ジッタとパケットロスの重要度は、それぞれ５０％で等しくなる。
【００１９】
　従って、図５の下段部分に示されているように、ネットワークアナライザは、ネットワークアナライザに接続されたユーザーインターフェイス（即ち、表示画面）（図示されていない）を介して、ＲＴＣＰ　ＳＲ／ＲＲパケットと抽出データを表のフォーマットで表示する。このＲＴＣＰ　ＳＲ／ＲＲパケットから表示するデータには、抽出したジッタ、パケットロス、並びにパケット及びオクテット数が含まれる。例えば、ＳＲ／ＲＲパケットから抽出した情報は表の列に表示され、ＲＴＣＰ　ＳＲ／ＲＲパケットは表の行に表示される。
【００２０】
　ユーザーは、特定のＲＴＰストリームのＲＴＣＰパケットに対応する行を選択可能である。行を選択すると、ユーザーインターフェイスにより、図５の上段部分に示されているように、例えば、選択したＲＴＣＰパケットに対応する抽出されたジッタ、パケットロス、或いはパケット又はオクテット数を示すグラフが表示される。
【００２１】
　更に、ネットワークアナライザは、選択したＲＴＣＰ　ＳＲ／ＲＲ情報に関連するＲＴＰデータを蓄積する。そして、図６に示すように、選択したＲＴＣＰパケットに関連するＲＴＰストリームを表示することができる。ユーザーは、ＲＴＰストリームに対応するデータと共に表示されているこれらのＲＴＣＰパケット及び関連ＲＴＰストリームをクリックすることができる。
【００２２】
　次いで、ユーザーは、ＲＴＣＰ　ＳＲ／ＲＲパケットから抽出された少なくとも１つのデータのために、少なくとも１つの列を選択可能である。選択すると、その列のデータに基づいて、ＲＴＣＰパケット（及び関連するＲＴＰストリーム）がソートされる。例えば、抽出されたジッタの列をユーザーが選択すれば、ＲＴＣＰパケット及び／又はＲＴＰストリームがジッタデータ値の降順に（最大から最小の順に）ソートされる。例えば、最大のジッタデータ値を有するストリームについてＲＴＣＰ行の情報をソートすれば、ユーザーは、次いで、最大のジッタ値を有する既定数のＲＴＣＰパケット及び／又はＲＴＰストリームを選択することができる。そして、選択したそれらのＲＴＣＰ　ＳＲ／ＲＲパケット及び／又はＲＴＰストリームに対応するＲＴＰストリームを更に処理して追加データを抽出し、ジッタなどのデータ伝送エラーが、ソース１０側のエンドポイントから、或いはレシーバー１２側のエンドポイントから発生しているかどうかを判定することができる。サービスエンジニアは、このＲＴＰストリームからの追加データを、ＱｏＳと組み合わせて使用し、例えば、ジッタが発生している場所を判定することができる。
【００２３】
　例えば、サービスエンジニアは、次いで、ネットワークアナライザをレシーバー１２により近い場所に接続し、再びネットワークアナライザを動作させてＲＴＣＰパケットを監視する。そして、最大のデータ値を有するＲＴＣＰパケットについて取得した、ジッタの値が以前取得したデータ値を下回っている場合には、サービスエンジニアは、ＰＯＡとソース１０の間のどこかの地点でデータ伝送エラーが発生していると判定するであろう。この場合、サービスエンジニアは、次いで、ネットワークアナライザ３０をソース１０により近い場所に接続し、データ伝送エラーを引き起こしているネットワーク内の地点を最終的に特定することができる。
【００２４】
　図７は、本発明の一実施例に従って、ＲＴＣＰパケット及び関連ＲＴＰストリームを選択及び監視する方法を示すフローチャートである。ステップ１００において、ＰＯＡを選択し、ネットワーク内のこのＰＯＡにネットワークアナライザを接続する。そして、ネットワーク内のＰＯＡにネットワークアナライザを接続した後に、ステップ１０２において、ソース１０とレシーバー１２間で伝送されているＳＲ／ＲＲパケットを含むＲＴＣＰパケットを抽出及び監視する。ステップ１０４において、ＲＴＣＰパケット内のＲＲパケットを解析し、ジッタとパケットロスデータを抽出する。又、ステップ１０６において、ＳＲパケットを解析し、送信されたパケット及びオクテット数に対応するデータを抽出する。これらＳＲパケット及びＲＲパケットは、順番に、或いは同時に解析可能である。ＲＴＣＰパケット内の情報には、ＳＲ（ソースが送信したＲＴＰデータパケットに属するデータを格納するもの）を格納可能であり、更に、ＲＴＣＰパケットは、ＲＲ（ソースから送信された最後のＲＴＣＰパケット以降に、ソースが受信したＲＴＰデータパケットに関する情報を格納するもの）を格納可能である。ステップ１０８において、ネットワークアナライザは、関連する又は対応するＲＴＣＰ　ＳＲ／ＲＲパケットと共に、ＲＴＰストリームを蓄積する。ステップ１１０において、ネットワークアナライザは、例えば、ＲＴＣＰ　ＳＲ／ＲＲパケット及び／又は関連するＲＴＰストリームからのデータをソートし、表のフォーマットで表示する。
【００２５】
　ステップ１１２において、ＲＴＣＰ　ＳＲ／ＲＲパケットから抽出された少なくとも１つのデータのために、少なくとも１つの列を選択する。ステップ１１４において、この選択したデータに基づいて、ＲＴＣＰ　ＳＲ／ＲＲパケット及び対応するＲＴＰストリームを降順にソートする。ステップ１１６において、最大のジッタ値を有する既定数のＲＴＣＰ　ＳＲ／ＲＲパケット及び／又はＲＴＰストリームを選択する。ステップ１１８において、選択したそれらのＲＴＣＰ　ＳＲ／ＲＲパケット及び／又は関連するＲＴＰストリームを更に処理して追加データを抽出し、データ伝送エラーを引き起こしているネットワーク内のソース１０とレシーバー１２の間の場所を判定する。
【００２６】
　以上、ＲＴＣＰ　ＳＲ／ＲＲパケット情報を利用し、ネットワーク内の最も不良なケースのジッタ及びパケットロスを有するＲＴＰストリームを選択及び監視するシステム及び方法の観点で本発明について説明した。ＲＴＣＰ　ＳＲ／ＲＲパケット情報を監視する際に、このネットワークアナライザの場合には、システムをエンドポイント間のネットワーク内のどこにでも接続可能であり、この結果、ネットワークのエンドポイントにおいて観測されるジッタとパケットロス情報を含むＲＴＣＰ　ＲＲパケットを回避することできる。そして、選択したＲＴＰストリームに対応するデータのみをチェックすることにより、すべてのＲＴＰストリームを監視するには利用可能な処理能力が不十分であるという既存の問題が解決される。
【００２７】
　前述の方法を実装するシステムには、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ　ｓｐｅｃｉｆｉｃ　ｉｎｔｅｇｒａｔｅｄ　ｃｉｒｃｕｉｔ）、磁気又は光ディスク、ＲＡＭ、ＲＯＭなどの固定又はリムーバブルのストレージが含まれ、本発明のプロセスとデータ構造をそれらに保存して配布することができる。又、本プロセスは、例えば、インターネットなどのネットワークを介したダウンロードによって配布することも可能である。
【００２８】
　以上の詳細な説明により、本発明の多数の特徴と利点は明らかであり、本発明の真の理念と範囲に属するそれらの本発明のあらゆる特徴及び利点は、添付の請求の範囲に包含される。又、当業者であれば、多数の変更や変形を容易に想起できることから、本明細書に例示し説明した構造や動作に本発明を限定することは望ましいことではなく、あらゆる適切な変形や等価物も本発明の範囲に属するものである。
【図面の簡単な説明】
【００２９】
【図１】センダーレポート（ＳＲ）ＲＴＣＰパケットを示す図である。
【図２】レシーバーレポート（ＲＲ）ＲＴＣＰパケットを示す図である。
【図３】本発明の一実施例に従ってＲＴＰストリームを監視する通信システムの構成を示す図である。
【図４】本発明の一実施例に従ってソースとレシーバー間のＲＴＣＰ　ＳＲ／ＲＲパケットを監視するシステムを示す図である。
【図５】ＲＴＣＰ　ＳＲ／ＲＲパケット及び対応するデータを示す図である。
【図６】ＲＴＣＰ　ＳＲ／ＲＲパケットの中の１つに関連するＲＴＰストリームを示す図である。
【図７】本発明の一実施例に従ってＲＴＣＰ　ＳＲ／ＲＲパケットを選択及び監視する方法を示すフローチャートである。
【符号の説明】
【００３０】
１０　第１エンドポイント
１２　第２エンドポイント
２０　ネットワーク
３０　ネットワークアナライザ
７２，７６　ＲＴＰストリーム
【図１】
2004129275.tif 000003
【図２】
2004129275.tif 000004
【図３】
2004129275.tif 000005
【図４】
2004129275.tif 000006
【図５】
2004129275.tif 000007
【図６】
2004129275.tif 000008
【図７】
2004129275.tif 000009