JP5023144B2 - ビデオストリーミング診断 - Google Patents

Description

この特許出願は、２００６年５月１日に出願の名称「ＤＳＬシステム」の米国特許仮出願第６０／７９６，３７１号に対する優先権を主張する。米国特許仮出願第６０／７９６，３７１号は、本願明細書に全体として引用したものとする。

この開示は、一般に通信ネットワーク、システムまたはその任意の組合せに、および、より詳しくはビデオストリーミング診断のための方法と装置に関する。

ＩＰＴＶ（インターネットプロトコルテレビ）は、デジタル加入者線（ＤＳＬ）回線のような消費者ブロードバンド接続を介したインターネットプロトコルを使用してテレビジョン信号をブロードキャストするための技術である。ＩＰＴＶは、ライブのＴＶ（マルチキャスト）、同じく格納されたビデオ（ビデオオンデマンドＶＯＤ）の両方を指す。基本的に、ＩＰＴＶ用のＤＳＬ物理層は、高速インターネットを供給するためのものと同一である。実際問題として、要求される性能目標はＩＰＴＶと高速インターネットとの間でかなり異なる。したがって、高速インターネットサービスのために設計されるＤＳＬ診断ツールは、ＩＰＴＶサービスに適切でないかもしれない。例えば、物理層内の少数のエラーは、ウェブサーファによって気がつかれないかもしれないが、ＩＰＴＶ視聴者にとって不満足な経験をもたらすかもしれない。対照的に、ウェブサーフィン中にエラーが生じる場合、損失パケットはほとんどの場合顧客がエラーに気づくことなく再送信を通して受信されることができる。しかしながら、ＩＰＴＶにとって、一旦訂正不能エラーが生じるならば、顧客は直ちにそれに気がつく。

ＩＰＴＶプロバイダのような、ビデオストリーミングを使用するコンテンツプロバイダは、それらのアプリケーションをＤＳＬサービスプロバイダから独立して維持する。結果として、ＤＳＬサービスプロバイダは一般的に物理層より上の問題を診断しない。対照的に、コンテンツプロバイダはそれ自身のアプリケーションを維持して、一般的に物理層の問題を診断しない。物理層は、オープンシステム相互結合基本参照モデル（ＯＳＩ）内に規定される７つの抽象層の１つである。７つの層は、物理、リンク、ネットワーク、トランスポート、セッション、プレゼンテーションおよびアプリケーション層として一般に公知である。しかしながら、ビデオストリーミングエラーは７つの層のうち複数のものから生じるかもしれない。この問題に対する以前の解決策は、複数の層からのデータの利用可能性を無視し、それは、しばしば信頼できないＩＰＴＶサービスをもたらす可能性がある。

ビデオストリームＤＳＬアナライザが、少なくとも非物理層管理データおよび物理層管理データを受信して、これに応答してメトリック情報を生成する。生成されたメトリック情報は、ビデオストリーム情報の性能を特徴づけるかまたは必要に応じて任意の問題を診断するのに用いられる。メトリック情報に応答して、ビデオストリームＤＳＬアナライザは性能を向上させるために一又はそれ以上のＤＳＬ構成（複数構成）を変更する。例えば、ビデオストリーミングプロトコルはオープンシステム相互結合基本参照モデル（ＯＳＩ）に従うことができる。ビデオストリームＤＳＬアナライザは、複数層上のＤＳＬ診断を実行する。診断は、物理および非物理層管理データ（すなわちリンク、ネットワーク、トランスポート、セッション、プレゼンテーションおよびアプリケーション層）の両方に応答して実行される。管理データは、ＤＳＬネットワークの一又はそれ以上の要素の性能を監視するか、診断するかまたは制御するのに適切な任意のデータを指す。一実施態様によれば、物理およびアプリケーション層が診断されるが、しかし、物理および非物理層の任意の組合せが診断されることができる。別の実施態様によれば、ビデオストリームＤＳＬアナライザは７つの可能な層のうち任意の２つに関するＤＳＬ診断を実行する。したがって、７つの層からの２つの層の任意の組合せによるデータが、メトリック情報を生成するのに用いられることができる。

ビデオストリームＤＳＬアナライザは、性能の問題および複数層に関する問題を診断して、対応する複数層のパラメータを最適化するように使用可能である。ビデオストリームＤＳＬアナライザは、ビデオストリーミングを高速インターネットサービス上でサポートするいくつかのＤＳＬ診断ツールの１つである。これらの診断ツールは、このビデオストリーミングサービスが任意の適切な性能要件に従うビデオ品質を提供することを確実にする。例えば、この診断ツールは、ビデオストリーミングサービスが既存のブロードキャスト、衛星またはケーブルテレビサービスと同じくらい安定した、またはこれらより安定したビデオ品質を提供することを確実にする。このビデオストリームＤＳＬアナライザによって、さらに、サービスプロバイダが、ビデオストリーミングサービスを配信するために、ＤＳＬ回線上で特定のデータレートを保証することができる。

ここで使用する用語「ＤＳＬ」は、例えば非対称ＤＳＬ（ＡＤＳＬ）、高速ＤＳＬ（ＨＤＳＬ）、対称ＤＳＬ（ＳＤＳＬ）または超高速ＤＳＬ（ＶＤＳＬ１およびＶＤＳＬ２）のようなさまざまなＤＳＬ技術またはその変形のいずれかを指す。この種のＤＳＬ技術は、例えばＡＤＳＬモデム用の国際電気通信連合（ＩＴＵ）規格Ｇ．９９２．１（別名Ｇ．ｄｍｔ）、ＡＤＳＬ２モデム用の国際電気通信連合（ＩＴＵ）規格Ｇ．９９２．３（別名Ｇ．ｄｍｔ．ｂｉｓ）、ＡＤＳＬ２＋モデム用の国際電気通信連合（ＩＴＵ）規格Ｇ．９９２．５（別名Ｇ．ａｄｓｌ２ｐｌｕｓ）、ＶＤＳＬモデム用の国際電気通信連合（ＩＴＵ）規格Ｇ．９９３．１（別名Ｇ．ｖｄｓｌ）、ＶＤＳＬ２モデム用の国際電気通信連合（ＩＴＵ）規格Ｇ．９９３．２、ハンドシェークを実施するモデム用の国際電気通信連合（ＩＴＵ）規格Ｇ．９９４．１（Ｇ．ｈｓ）、ＤＳＬモデムの管理用のＩＴＵ Ｇ．９９７．１（別名Ｇ．ｐｌｏａｍ）規格または任意の適切な組合せのような適用可能な規格に従って、一般に実現される。

ここで使用する用語「動作する」は動作の可能な、もしくは実際のところ動作中の装置、またはその任意の組合せを言う。例えば、停止されているかパワーオフされている装置は動作を実行するように「動作する」、すなわち装置がスイッチを入れられると、動作を実行することが可能である。したがって、たとえ装置がパワーオフされているかまたは他に停止されていても、装置は予めプログラムされたハードウェアまたはソフトウェアプログラムされたハードウェア、または、その任意の組合せによってある機能を実行するように「動作する」。他の意味がこれらの用語の使用の文脈から推測されることができるとはいえ、用語「信号」は一般的にアナログ信号を指し、用語「データ」は一般的にデジタルデータを指し、および、用語「情報」はアナログ信号またはデジタル信号のどちらかを指すことができる。

図１は、一実施態様によるビデオストリームＤＳＬアナライザ１００のブロック図である。ビデオストリームＤＳＬアナライザ１００は、ＤＳＬコンフィグレータ１２０に接続されるメトリック情報発生器１１０を含む。一実施態様によれば、ビデオストリームＤＳＬアナライザ１００はネットワーク管理システムサーバのようなコンピュータサーバ、または他の適切なコンピュータの一部であることができる。ビデオストリームＤＳＬアナライザ１００は、また、マイクロプロセッサのような、一又はそれ以上の適切にプログラムされたプロセッサであることができ、したがって、実行される時、ビデオストリームＤＳＬアナライザ１００に本願明細書に記載されている動作を実施させる実行可能命令を含有する関連メモリを含む。

図２は、一実施態様によるＤＳＬネットワーク上のビデオストリームを診断する方法の流れ図である。この方法は、図１内に示されるビデオストリームＤＳＬアナライザ１００によって実施されることができる。しかしながら、その他の適切な構成がまた、使われることができる。ステップ２１０で始まるこの方法は一連の動作として記載されているが、動作は任意の適切な順序で実行されることができて、任意の適切な組合せで繰り返されることができることは認識されよう。

図２のブロック２１０に、および、図１のブロック図内に示すように、メトリック情報発生器１１０は少なくとも非物理層管理データ１３０および物理層管理データ１４０を受信する。物理層管理データ１４０は、ＯＳＩモデルの物理層に関連した情報に対応することができる。非物理層管理データ１３０は、リンク、ネットワーク、トランスポート、セッション、プレゼンテーションおよびアプリケーション層のような、任意の対応する非物理ＯＳＩ層に関連したデータに対応することができる。一実施態様によれば、非物理層管理データ１３０は以下の任意の組合せを含む：加入者帯域幅使用、ＭＰＥＧエラーデータ、受信パケット、受信バイト、損失パケット、損失率、破損パケット、オーバラン、アンダーラン、受信到着間隔ジッター、平均受信到着間隔、受信パケット、パケット不連続カウンタまたはその他の適切なデータ。例えば、「ＴＲ−０６９使用可能なＳＴＢのためのデータモデル、ＷＴ−１３５改訂３版、２００６年２月」と名付けられたＤＳＬフォーラムが、セットトップボックス（ＳＴＢ）を監視して、制御するためのデータモデルを規定する。一実施態様によれば、上記した非物理層管理データ１３０はこのデータモデル内のＩＰＴＶサービスに関連したパラメータとしてリストされるが、しかし、任意の適切なビデオストリーミングサービスからのデータが使われることができる。例えば、これらのパラメータがＩＰＴＶ配信問題のようなビデオストリーミング問題を診断するために使われることができる。

一実施態様によれば、物理層管理データ１４０は以下の任意の組合せである：報告されたＩＮＰ、報告された遅延、報告されたデータレート、フルイニット(full inits)カウンタ、失敗したフルイニットカウンタ、ショートイニット(short inits)カウンタ、失敗したショートイニットカウンタ、ＦＥＣＳ−Ｌカウンタ、ＥＳ−Ｌカウンタ、ＳＥＳ−Ｌカウンタ、ＬＯＳＳ−Ｌカウンタ、ＵＡＳ−Ｌカウンタ、ＦＥＣＳ−ＬＦＥカウンタ、ＥＳ−ＬＦＥカウンタ、ＳＥＳ−ＬＦＥカウンタ、ＬＯＳＳ−ＬＦＥカウンタ、ＵＡＳ−ＬＦＥカウンタ、ＣＶ−Ｃカウンタ、ＦＥＣ−Ｃカウンタ、ＣＶ−ＣＦＥカウンタ、ＦＥＣ−ＣＦＥカウンタ、ＣＲＣ−Ｐカウンタ、ＣＲＣＰ−Ｐカウンタ、ＣＶ−Ｐカウンタ、ＣＶＰ−Ｐカウンタ、ＣＲＣ−ＰＦＥカウンタ、ＣＲＣＰ−ＰＦＥカウンタ、ＣＶ−ＰＦＥカウンタ、ＣＶＰ−ＰＦＥカウンタまたはその他の適切なデータ。

非物理層は、以下の少なくとも１つと対応する：イーサネット（登録商標）、ＩＰ、ＵＤＰ、ＲＴＰ、ＭＰＥＧ−ＴＳ、ＭＰＥＧペイロード、データ、リンク、ネットワーク、トランスポート、セッション、プレゼンテーションおよびアプリケーション層。代替実施態様によれば、ビデオストリームおよび対応する非物理層管理データ１３０および物理層管理データ１４０は開放型システム間相互接続基本参照モデル（ＯＳＩ）の全部または一部に従うことができる。一実施態様によれば、メトリック情報発生器１１０は７つの可能なＯＳＩ抽象層のうち任意の２つから情報を受信する。したがって、受信された管理データ１３０、１４０は物理層管理データに限られず、任意の適切なビデオストリーミングプロトコルに対して７つの層のうち任意の２つの層の任意の有効な層の組合せを含むことができる。

下のテーブルは、一実施態様によって、ＶＤＳＬ２に利用できるＤＳＬ初期化メトリックスとして、物理層管理データ１４０を例示する。このテーブルは物理層管理データ１４０として例示のＤＳＬ初期化メトリックスをリストするが、しかし、その他のメトリックスまたは類似したＤＳＬエラーメトリックスが同様に使われることができる。一実施態様によれば、物理層管理データ１４０によってビデオストリームＤＳＬアナライザ１００がビデオストリーミングを配信するための物理層の信頼性を推定することができる。例えば、要素管理システム（ＥＭＳ）、自動構成サーバ（ＡＣＳ）またはその任意の組合せは、後で詳しく述べるようにネットワークエラーメトリックスを導き出すためにビデオストリームＤＳＬアナライザ１００にＤＳＬエラーメトリックスを供給することができる。これらのＤＳＬ初期化メトリックスは、例えば、５、１０、１５分ごとの間隔でまたは任意の間隔で、更に、現在のおよび過去の１日間隔に対してまたは任意の適切な間隔に対して、報告されることができる。大きいカウントの初期化試行を示す初期化履歴は、時間変化する定常ノイズの徴候である可能性がある。

図２のブロック２２０に、および、図１のブロック図内に示すように、メトリック情報発生器１１０は非物理層管理データ１３０および物理層管理データ１４０に応答してメトリック情報１５０を生成する。例えば、複数ソースから得られる非物理層管理データ１３０および物理層管理データ１４０が、任意のビデオストリーム劣化の根本的原因を診断して、判定するために相関させられるかまたは組み合わせられることができる。

メトリック情報１５０を算出するための一例が、提供される。しかしながら、メトリック情報１５０を算出するための任意の代替技法が、使われることができる。一実施態様によれば、ビデオストリームＤＳＬアナライザ１００は、メトリック情報１５０を受信された管理データ１３０、１４０のうちの少なくとも１つに直接設定することができる。例えば、ビデオストリームＤＳＬアナライザ１００は、メトリック情報１５０をパケット損失、遅延、エラー率または受信された任意の適切な性能メトリックに直接設定することができる。一代替実施態様によれば、ビデオストリームＤＳＬアナライザ１００は対応する時間枠に対して受信された管理データ１３０、１４０をグループ化するかまたはさもなければ受信された管理データ１３０、１４０を同期させるかもしくは変換する。さらに別の実施態様によれば、ビデオストリームＤＳＬアナライザ１００は受信された管理データ１３０、１４０のうちの少なくとも２つの関数としてメトリック情報１５０を計算するかまたは生成する。この関数は、本譲受人によって所有されかつ、参照によって本願明細書に組み込まれる本願と同じ出願日を有する、代理人整理番号２０１０３／０７２７；Ｐ３９を有する名称「通信システムを特徴づけるために複数ソースからのデータを組み合わせる方法と装置」の同時係属出願にて説明したように、平均計算、ベイジアン計算、または任意の適切な関数であることができる。更に、ビデオストリームＤＳＬアナライザ１００は本願明細書に記載されている実施態様の任意の組合せまたはその他の適切な関数または組合せを使用してメトリック情報１５０を計算するかまたは生成する。

さらに別の実施態様によれば、メトリック情報１５０はパケット損失率であることができる。この場合もやはり、メトリック情報１５０は任意の適切なメトリック組合せまたは遅延、帯域幅使用、パケット不連続性、パケットサイズのようなパラメータ、または、任意の適切な性能メトリックであることができる。例えば、パケット損失率はコード違反カウント（ＣＶ−ＣおよびＣＶ−ＣＦＥ）から導き出されることができる。コード違反カウント導出はＶＤＳＬ１およびＶＤＳＬ２に対して異なるが、これはコード違反の定義がこれらの規格の間で異なるからである。パケット損失率を算出する例示のが下記に与えられるとはいえ、計算のためのベースとして使われる技法並びにデータは、例えば、所望の性能特性、利用可能なデータおよび関連する特定のプロトコルまたはＯＳＩレイヤーによって異なるものとすることができる。

ＶＤＳＬ１では、ＣＶ−ＣおよびＣＶ−ＣＦＥカウンタは少なくとも一つのＤＳＬエラーを含むＶＤＳＬ１スーパーフレームの数を収集することができる。その他の適切なメトリック、データ、カウンタまたは情報が、物理層管理データ１４０として使われることができる。例えば、１５分の期間（任意の適切な期間が使われることができる）内のイーサネットフレームの総数を以下と等しくする：

例示的な低エラー率シナリオにおいて、１つのＣＲＣエラーは、１つのイーサネットフレームだけがＤＭＴスーパーフレームにつき破損していることを意味する。例示的な高エラー率シナリオにおいて、各ＣＲＣエラーは、ＤＭＴスーパーフレームにまたがる全てのイーサネットフレームが破損していることを意味する。ここで、正味データレートがＶＤＳＬアプリケーションの範囲内にあるとすると、ＤＭＴスーパーフレームあたりイーサネットフレームの数は、１より大きい。（これは、４．３６４８Ｍｂｐｓより大きい正味データレートに対応する。）これがあてはまらないならば、２つのＣＲＣエラーは１つだけのイーサネットフレームエラーをもたらすであろう。

例示的な低エラー率シナリオを想定すると、１５分の間隔内の総イーサネットフレームに対する破損したイーサネットフレームの比率は、以下にほぼ等しい：

例示的な高エラー率シナリオを想定すると、１５分の間隔内の総イーサネットフレームに対する破損したイーサネットフレームの比率は、以下にほぼ等しい：

イーサネットフレーム損失率の上記の推定値は、続いて上位層のパケット形式に対する損失率に変換されることができる。例えば、７つのＭＰＥＧ−ＴＳパケットがイーサネットフレーム内に一般的に含まれることを知ることによって、ＭＰＥＧ−ＴＳ損失率を計算することができる。このように、ＤＳＬエラーメトリックスを上位層フレームエラー率に、および、最終的にはビデオフレームエラー率に変換することができる。

ＶＤＳＬ２では、フレーミング方法はＶＤＳＬ１とは完全に異なり、それはＣＶカウントの解釈に関する多くの含意を有する。２つのレーテンシ経路およびしたがって、２つのフレーミング動作がある。基本のフレーミングユニットは、オーバヘッドバッファ、ベアラチャネル０のバッファおよびベアラチャネル１のバッファからのバイトから成るＭｕｘデータフレーム（ＭＤＦ）である。Ｍｐ ＭＤＦを組み合わせることによって、ＲＳ符号語のペイロードが形成され、および、パリティバイトが加えられる。Ｔｐ／Ｍｐ ＲＳ符号語を組み合わせることによって、「符号語のグループ」が形成される。Ｕｐ「符号語のグループ」を組み合わせ上げることによって、「符号語のスーパーグループ」が形成される。この種の「スーパーグループ」内の合計バイト数は、（ＵｐｘＴｐ／Ｍｐ）とＲＳ符号語当たりのバイト数の積であり、ＰＥＲＢｐとして規定される。

各ＭＤＦは、複数のオーバヘッドバイトを有する。Ｔｐ／Ｍｐ ＲＳ符号語のＭＤＦ内に含まれるオーバヘッドバイトは、ＯＨサブフレームを形成する。Ｕｐ ＯＨサブフレームの組合せ（各「符号語のグループ」に対して１つ）が、ＯＨフレームを与える。ＯＨフレームのフォーマットは、ＣＲＣバイトを含むと見られることができる。このＣＲＣバイトは、ＲＳ符号語の「スーパーグループ」のＰＥＲＢｐバイトに基づいて計算される。

ＣＲＣバイトがその上に計算される「メッセージ」は可変長を有し、それは以下に示すように表される。

したがって、ＣＶカウントはエラーがＰＥＲＢｐバイトと等しい「データブロック」内にあることを意味する。このデータブロックは、オーバヘッドバイトおよびＲＳパリティバイトを含む。実際的な総データレートに対して、ＰＥＲＢｐが１７，０００バイトによって下限付けされることが分かる。この「データブロック」の正確な持続時間を算出することは、パラメータ（Ｔｐ、ＭｐおよびＵｐ）の知識を必要とする。このデータが利用できない場合、この種の持続期間についての知識を仮定して、次いで、イーサネットフレーム損失率計算はＶＤＳＬ１に関しての類似した導出を使用するであろう。

一実施態様によれば、任意選択のボック２３０に示すように、ＤＳＬコンフィグレータ１２０は生成されたメトリック情報１５０を受信して、これに応答して、少なくとも一つのＤＳＬ構成を変更するように動作する。ＤＳＬコンフィグレータ１２０はＤＳＬ構成データ１６０を生成してビデオストリームの性能を特徴づけ、問題（複数の問題）またはその任意の組合せを修正する。一実施態様によれば、ＤＳＬ構成データ１６０に応答して、ビデオストリームＤＳＬアナライザ１００は性能を向上させるために一又はそれ以上のＤＳＬ構成（複数構成）を変更する。ビデオストリームＤＳＬアナライザ１００は、７つの層のうち任意の２つに関するＤＳＬ診断を実行する。例えば、診断は物理層管理データ１４０および非物理層管理データ１３０（すなわちリンク、ネットワーク、トランスポート、セッション、プレゼンテーションおよびアプリケーション層）の両方に応答して実行される。一実施態様によれば、物理およびアプリケーション層が診断されるが、しかし、物理および非物理層の任意の組合せが診断されることができる。

図３は、一実施態様によるＤＳＬシステム３００のブロック図である。ＤＳＬシステム３００は、ＰＳＴＮ ３２０経由で顧客構内３１０に接続されるサービスプロバイダ位置３０５の装置を含む。図示の例では、ＤＳＬサービスは従来の撚り線対銅電話線３１５経由で例示の顧客構内３１０に与えられるかまたは与えられることができる。図３の例示の電話線３１５は、一般加入電話網（ＰＳＴＮ）３２０の一部である。サービスプロバイダ位置３０５は、ビデオストリームコンテンツ配信３０２、ビデオストリーミング配信サーバ３０６、イーサネットスイッチ３０８および非ビデオサービス配信サーバ３９２を含む。ビデオストリームコンテンツ配信３０２は、例えばテレビ局、ビデオストリームコンテンツのプロバイダ、またはビデオストリーム３０４を生成するその他の適切なビデオストリームコンテンツプロバイダであることができる。ビデオストリーミング配信サーバ（複数サーバ）３０６は、ビデオストリーム３０４を受信し、これに応答して、例えばインターネットプロトコル（ＩＰ）に従って、ビデオストリーム３０４をフォーマットし、かつ、サービス配信システム３６５に配信されるビデオストリーム３０７を供給する。同様に、非ビデオサービス配信サーバ３９２は、例えば、インターネットサービスプロバイダ（ＩＳＰ）または任意の適切なサーバから非ビデオコンテンツを受信し、インターネットプロトコルに従って非ビデオコンテンツをフォーマットし、かつ非ビデオストリーム３９４を生成する。サービス配信システム３６５は、少なくとも非ビデオストリーム３９４および配信されたビデオストリーム３０７を受信して、これに応答してインターネットデータ３６８を生成する。イーサネットスイッチ３０８は、インターネットデータ３６８を受信して、最終的に適切な加入者装置３３２への送信のためにルーティングされたか切替えられたインターネットデータ３０９を送信する。

顧客構内３１０は、例えば加入者装置３３２およびループ試験装置３４０に接続されたＤＳＬモデム３３０を含む。用語「顧客構内」は、通信サービスがサービスプロバイダによって提供される位置を指す。ＤＳＬサービスを提供するのに用いられる例示の一般加入電話網（ＰＳＴＮ）に対して、顧客構内は電話線のネットワーク終端装置（ＮＴ）側に位置する。ここで使用される用語「ユーザ」、「加入者」または「顧客」は通信サービスまたは装置が種々のサービスプロバイダ（複数プロバイダ）のいずれかによってそれに対して提供されるかまたは潜在的に提供されることができる人、企業または組織を指す。例示の加入者装置３３２は、加入者がＤＳＬサービスまたはインターネットサービスをそこで受信するかまたは利用する加入者の住居に設置されるパーソナルコンピュータ（ＰＣ）、セットトップボックス（ＳＴＢ）、住宅用ゲートウェイまたはテレビを含む。

サービスプロバイダ位置３０５は、ＤＳＬＡＭ（複数ＤＳＬＡＭ）３２５、金属の交差接続を実施する配線盤３３５、ループ試験装置３４５および回線テスタ３５０を含む。一実施態様によれば、例示のループ試験装置３４５はＤＳＬＡＭ ３２５によってもしくはその中に、または任意の適切な構成要素によって実現されることができる。用語「サービスプロバイダ位置」は、ＤＳＬサービスがそこから提供される位置、またはＤＳＬサービスの提供に関するシステムまたは装置がそこに設置される位置を指す。例示のサービスプロバイダは、通信サービスまたは通信機器を提供するか、販売するか、配給するか、処理するかまたは保守する、電話事業会社、ケーブル事業会社、無線事業会社またはインターネットサービスプロバイダを含む。例示のＤＳＬＡＭ（複数ＤＳＬＡＭ）３２５は、とりわけ、さまざまなまたはいくつかのＤＳＬモデム（複数モデム）のいずれかを実現し、その一つは電話線３１５経由で例示の顧客構内３１０にＤＳＬサービスを提供するのに用いられるか、または用いられることができる。サービスプロバイダ位置３０５はさらに、自動構成サーバ（ＡＣＳ）３６０、要素管理システム（ＥＭＳ）３５５、サービス保証システム（ＳＡＳ）３７０、サービス配信システム３６５、データ収集・結合器（図示せず）およびネットワーク管理システム（ＮＭＳ）３９０を含む。図３は一実施態様によるこれらの要素を示すが、しかし、これらの要素は任意の所望の方法で再割当されることができる。

ループ試験装置３４０または回線テスタ３５０の任意の組合せが、電話線３１５の状態を特徴づけるか、記述するかまたは示すさまざまな、信号、管理データ１３０、１４０、情報またはパラメータ（複数パラメータ）の任意の数またはいずれかを測定するか、計算するかまたは他に判定する。図３の図示の例において、例示のループ試験装置３４５は配線盤３３５経由で電話線３１５に接続され、および、例示のループ試験装置３４０は顧客構内３１０（すなわち家庭内の配信網）内に設置される電話配線に接続される。さらにまたは代わりに、例示のループ試験装置３４５はＤＳＬＡＭ ３２５によってもしくはその中、または任意の適切な構成要素によって実現されることができる。

ＥＭＳ ３５５は、例示のＤＳＬＡＭ ３２５とＤＳＬモデム３３０との間に生じるＤＳＬ通信に対する現在のまたは過去のＤＳＬ性能特性のような物理層管理データ１４０を監視するか、測定するかまたは記録する。進行中の(ongoing)ＤＳＬサービスに対するＤＳＬ性能データ、統計または情報のような物理層管理データ１４０が、種々の周知の技法のいずれかを使用して例示のＤＳＬモデム３３０またはＤＳＬＡＭ ３２５によって測定されることができるかまたはＥＭＳ ３５５に報告されることができる。例えば、それらはＤＳＬモデムの管理のためのＩＴＵ Ｇ．９９２．１（別名Ｇ．ｄｍｔ）規格に基づいて、またはＩＴＵ Ｇ．９９７．１（別名Ｇ．ｐｌｏａｍ）規格に基づいて測定されることができる。例示の性能データ、統計および情報は、以下の任意の組合せを含むが、これに限定されるものではない：ＥＭＳデータ、ＥＭＳ状態、ＨＬＯＧ、ＨＬＩＮ、ＱＬＮ（クワイエットラインノイズ）、ＳＮＲ、ＬＡＴＮ（回線減衰）、ＳＡＴＮ（信号減衰）、ノイズ、チャネル減衰、データレート、ＡＴＴＮＤＲ（達成可能データレート）、マージン、ＣＶ（コード違反）、ＦＥＣ（前方誤り訂正）カウント、ＥＳ（エラー秒数）、ＳＥＳ（重大エラー秒数）、ＵＡＳ（使用不可秒数）、ＢＩＴＳ（ビット配分）、ＧＡＩＮＳ（ファインゲイン）、ＴＳＳＩ（送信スペクトル成形）、ＭＲＥＦＰＳＤ（参照ＰＳＤ）、送信パワー、送信ＰＳＤ、故障、初期化カウント、実遅延、実インパルスノイズ保護、前方誤り訂正（ＦＥＣ）およびインタリービングデータ、インパルスノイズセンサデータ、複数のＦＥＣエラー、マージン情報、データレート情報、チャネル伝達関数、ループ減衰情報、ビット割当て情報、またはその他の適切な性能情報。物理層管理データ１４０は、ＤＳＬ物理層特性に関連した性能情報、または、ＳＮＲ、ビット配分、データレート、マージン、達成可能データレートもしくは任意の適切な情報を含むＤＳＬ−ＰＨＹ特性データを含む。図３の例において、ＤＳＬ性能データ、統計または情報のような物理層管理データ１４０は、例えば、ＩＴＵ Ｇ．９９４．１（別名Ｇ．ｈｓ）規格内に規定される交換プロトコルを使用してＤＳＬサービス経由で例示のＤＳＬモデム３３０によって送信される。さらにまたは代わりに、ＤＳＬ性能データ、統計または情報はＤＳＬフォーラム文書ＴＲ−０６９において規定したように、伝送制御プロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）接続を介してＤＳＬモデム３３０によってＡＣＳ ３６０まで送信されることができる。

サービス配信システム（複数システム）３６５は、例えばビデオストリーミング、ＩＰテレビ（ＩＰＴＶ）、ビデオオンデマンド（ＶｏＤ）、ＩＰ電話（ＶｏＩＰ）のような種々のサービスのいずれか、またはその任意のサービスの組合せを、例示の顧客構内３１０に提供するためにインターネットデータ３６８を生成する。ＳＡＳ ３７０は、例示のサービス配信システム３６５によって提供されるサービスの品質、性能または特性を監視する。例えば、サービス配信システム３６５は適切な加入者装置に対するインターネットプロトコルによる配信のためにインターネットデータ３９４および配信されるビデオストリーム３０７を組み合わせて、フォーマットする。例えば、ＳＡＳ ３７０は、例えば、ビデオストリーム３０４の動画像専門家グループ（ＭＰＥＧ）統計値（例えばフレーム損失など）、パケット損失率など、を監視する。

上記の通りに、例示のＡＣＳ ３６０、例示の回線テスタ３５０、例示のＥＭＳ ３５５、例示のＳＡＳ ３７０またはその任意の組合せは、電話線３１５経由でサービス配信システム３６５、ＤＳＬＡＭ ３２５またはＤＳＬモデム３３０によって提供されるかまたは提供可能な過去か、進行中か、または可能な将来のＤＳＬサービスを示すデータのソースを表す。上記の通りに、例示のデータソース３５０、３５５、３６０、３７０は、例示の電話線３１５の端部のいずれか一方または両方において、測定され、収集され、推定され、判定されるデータ、または、その任意の組合せを含むことができる。図３の例示のデータソース３５０、３５５、３６０、３７０は、周期的または非周期的ベースでデータを収集して報告することができる。さらにまたは代わりに、データは、データまたは情報に対するリクエストに応答して収集されて報告されることができる。データソース３５０、３５５、３６０、３７０によって収集されるデータまたは情報は、図３の例示のＤＳＬシステムの現在のまたは過去のスナップショット（複数スナップショット）を表すことができる。

異なるデータ収集ソースによって使われるデータフォーマットは実質的に異なることができることに留意されたい。例えば、ＥＭＳ ３５５は１５分のＤＳＬエラーカウンタのような物理層管理データ１４０を報告することができ、ＡＣＳ ３６０は開始時刻以降のＤＳＬエラーを報告することができ、および、サービス保証サーバ３７０はＭＰＥＧフレーム統計値を報告することができる。したがって、１つのタイプから別のタイプまで「変換する」方法は多くの要因に従い広範囲にわたって変化して、かつ適用されることができる。更に、複数ソースから収集されるデータは同期されることができず、および、データ比較が適切な時間間隔で行われるようにするために段階が踏まれなければならない。

例示のデータソース３５０、３５５、３６０、３７０によって収集されるか、取得されるか、測定されるか、計算されるか、推定されるか、受信される管理データ１３０、１４０または情報、またはその任意の組合せが、関連性、完全性、信頼性、精度および適時性（例えば、最近対古い）のような種々の要因のいずれかに影響を受ける可能性がある。例示のデータソース３５０、３５５、３６０、３７０のいくつかは、本質的により高い精度または信頼性を有し、したがって、図３の例示のＤＳＬシステムに関連した特定のパラメータの決定により役立つことができる。例えば、例示の回線テスタ３５０内に含まれるＴＤＲデータは、ＥＭＳ ３５５で利用できるチャネル減衰データまたはチャネル伝達関数と比べて、ブリッジタップの検出またはパラメータ化に対して、より正確であるかまたはより役立つことができる。

示した例において、データソース３５０、３５５、３６０、３７０のうちの２つは関連するか、類似するかまたは不完全である可能性のある管理データ１３０、１４０を含むかもしれない。例えば、（ａ）例示のＡＣＳ ３６０は、周波数の第１部分（例えばダウンストリームのチャネル）に対するチャネル減衰を表すＡＣＳタイプ管理データ１３０、１４０を含む一方、ＥＭＳ ３５５は周波数の第２の部分（例えばアップストリームチャネル）に対するチャネル減衰を表すＥＭＳタイプ管理データ１３０、１４０を含むことができ、または（ｂ）ブリッジタップは、ＡＣＳ ３６０内に含まれるチャネル伝達関数もしくは回線テスタ３５０内に含まれるＴＤＲ応答からの関連情報を使用して検出されることができる。更に、ＡＣＳ ３６０およびＥＭＳ ３５５が両方ともチャネル減衰タイプ管理データ１３０、１４０を含むことができるとはいえ、それらは異なる精度もしくは表現で管理データ１３０、１４０を得るかまたは格納することができる。ＡＣＳタイプ管理データ１３０、１４０の例はさらに、以下の任意の組合せを含む：ＡＣＳ状態、ＨＬＯＧ、ＨＬＩＮ、ＱＬＮ（クワイエットラインノイズ）、ＳＮＲ、ＬＡＴＮ（回線減衰）、ＳＡＴＮ（信号減衰）、ノイズ、チャネル減衰、データレート、ＡＴＴＮＤＲ（達成可能データレート）、マージン、ＣＶ（コード違反）、ＦＥＣ（前方誤り訂正）カウント、ＥＳ（エラー秒数）、ＳＥＳ（ひどくエラー秒数）、ＵＡＳ（使用不可秒数）、ＢＩＴＳ（ビット配分）、ＧＡＩＮＳ（ファインゲイン）、ＴＳＳＩ（送信スペクトル成形）、ＭＲＥＦＰＳＤ（参照ＰＳＤ）、送信パワー、送信ＰＳＤ、故障、初期化カウント、実遅延、実インパルスノイズ保護、ＦＥＣおよびインタリービングデータ、インパルスノイズセンサデータ、またはその他の適切なデータ。ＨＬＯＧは、それがどこに設置されるであろうとも、例えば特定の装置および関連したＤＳＬ規格に従いＥＭＳ ３５５ ＡＣＳ ３６０または任意の適切なネットワーク要素から報告されることができる。ＨＬＯＧは、物理層管理データ１４０の別の例である。ＤＳＬＡＭ ３２５からの管理データ１３０、１４０はＥＭＳ ３５５経由で収集されることができ、および、ＤＳＬモデム３３０からの管理データ１３０、１４０はＡＣＳ ３６０経由で収集されることができる。他の例は、当業者に豊富であろう。

さまざまな、方法（複数の方法）、プロトコル（複数プロトコル）、通信経路（複数経路）または通信技術（複数技術）のいずれかを使用して、図３の例示の回線テスタ３５０は、例示のループ試験装置３４０または３４５が、電話線３１５に種々の回線プローブ信号のいずれかを送信するか、または、回線プローブ信号の投入の有無にかかわらず、電話線３１５上に存在する信号を受信するかもしくは測定するように構成、命令、または要求することができる。信号プローブ、信号受信または測定の任意の組合せが、種々のシングルエンドまたはダブルエンドの回線試験方法（複数方法）、アルゴリズム（複数アルゴリズム）または技法（複数技法）のいずれかを実行するために例示の回線テスタ３５０またはループ試験装置３４０、３４５によって利用されることができる。例示のプローブ信号は、以下の任意の組合せを含む：ステップ時間分域反射率測定（ＴＤＲ）信号、パルスＴＤＲ信号、広帯域スペクトラム信号、公称モデム伝送信号（例えばＡＤＳＬモデム用のマルチキャリアトレーニング信号）、チャープ信号、インパルス列、単一インパルスまたは任意の適切な信号。回線プローブ信号を送信するか、または電話線３１５上に存在する信号（複数信号）を受信するかもしくは測定する例示の方法と装置が、２００６年５月１日出願の米国特許出願第６０／７９６，３７１号、および米国特許出願（代理人整理番号２０１０３／０７２８）内に記載されており、それらは、それらの全体を本願明細書に引用したものとする。

以下の開示が例示のデジタル加入者線（ＤＳＬ）システム３００または図３の例示のデバイスを参照するとはいえ、本願明細書に記載されている方法と装置は、任意の種類、任意のサイズまたは任意のトポロジのＤＳＬシステム３００またはネットワークに対する電話線３１５またはＤＳＬ装置の特性またはパラメータを含むメトリック情報１５０を推定するか、判定するかまたは推測するのに用いられることができる。例えば、ＤＳＬシステム３００は任意の数の顧客構内、複数の位置に設置される複数のＤＳＬアクセスマルチプレクサＤＳＬＡＭ（複数ＤＳＬＡＭ）３２５を含むことができるか、または、電話線、ＤＳＬモデム、サーバ、システム、データソース、データ収集器、データストア、データ結合器もしくはデータ収集・結合器の任意の数および組合せを含むことができる。

以下の開示が、例示のデジタル加入者線（ＤＳＬ）装置、ＤＳＬサービス、ＤＳＬシステム、またはＤＳＬサービス配信用の通常の撚り線対銅電話線の使用に関してなされるとはいえ、理解されるべきことは、本願明細書に開示される複数のデータソースから収集されるデータを使用して通信システムまたはネットワークの特性を推測する開示された方法と装置が、多くの他のタイプまたは種類の通信機器、サービス、技術またはシステムに適用可能である、ことである。例えば、開示された方法と装置はまた、無線配信システム、有線またはケーブル配信システム、同軸ケーブル配信システム、極超短波（ＵＨＦ）／高周波（ＶＨＦ）無線周波数システム、衛星または他の地球外システム、携帯配信システム、電力線ブロードキャストシステム、ＷｉＭＡＸ、ＷｉＦｉ、光ファイバネットワークまたは任意の適切なネットワークまたはシステムにも適用可能であることができる。その上、これらのデバイス、システムまたはネットワークの組合せもまた、使われることができる。例えば、バランによって接続される撚り線対および同軸ケーブルの組合せ、または、光ネットワークユニット（ＯＮＵ）の線形の光から電気への接続によるアナログファイバから銅への接続のような、その他の物理チャネル継続組合せが使われることができる。

代わりにまたはさらに、ループ試験装置３４０、３４５に通信可能に接続される、または、接続可能なコンピュータがメトリック情報１５０を生成することができる。例えば、例示の回線テスタ３５０は、ループ試験装置３４０、３４５から受信されるか測定される信号を得ることができ、かつメトリック情報１５０を推定するかまたは求めることができる。代わりにまたはさらに、加入者装置（例えば加入者のパーソナルコンピュータ（ＰＣ）またはセットトップボックス（ＳＴＢ））がメトリック情報１５０を推定するかまたは求めるのに用いられることができる。

図３の図示の例で示す一実施態様によれば、ビデオストリームＤＳＬアナライザ１００は例示のループテスタ３４０、３４５、例示の回線テスタ３５０、ＤＳＬＡＭ（複数ＤＳＬＡＭ）３２５、ＡＣＳ ３６０、ＥＭＳ ３５５、ＳＡＳ ３７０または任意の適切なデバイスから、種々の方法（複数の方法）、ネットワーク（複数ネットワーク）、プロトコル（複数プロトコル）のいずれかもしくはその任意の組合せを介して非物理層管理データ１３０および物理層管理データ１４０を受信する。ビデオストリーミング配信サーバ３０６、イーサネットスイッチ３０８および加入者装置３３２のような、メトリック情報１５０を受信するか、測定するか、計算するかまたは推定するのに用いられるその他のデバイスまたはシステムは、さらにまたは代わりに、例示の回線テスタ３５０にそれを供給することができる。

例示のデータソース３５０、３５５、３６０および３７０が図３内に例示されるとはいえ、当業者は、ＤＳＬシステムが図３内に例示されるものよりも追加的なもしくは代わりのデータソースを含むことができるか、または例示されたデータソースのいずれかもしくは全てのうちの複数を含むことができると容易に理解するであろう。更に、この開示が、図３の例示のデータソース３５０、３５５、３６０、３７０の特定の１つを通して含まれるか利用できる特定のデータまたは情報を説明するとはいえ、当業者は、ＤＳＬサービスプロバイダがデータまたは情報およびデータソースの種々の組合せのいずれかを利用することができると容易に認識するであろう。

複数の電話線、ＤＳＬＡＭ ３２５またはＤＳＬモデム３３０を含むＤＳＬシステムまたはネットワークに対して、図３の例示のデータソース３５０、３５５、３６０または３７０は各電話線３１５、ＤＳＬＡＭ ３２５またはＤＳＬモデム３３０と関連するデータを含む。しかしながら、データソース３５０、３５５、３６０または３７０内に含まれるデータの組は、例えば、電話線から電話線、ＤＳＬＡＭからＤＳＬＡＭ、ＤＳＬモデムからＤＳＬモデムまたは加入者から加入者で、例えば、ＤＳＬサービスがどれくらいの間有効であったか、ＤＳＬモデムのタイプまたはメーカ、利用されるかまたは加入されるサービスのタイプ、顧客構内の位置、などのような種々の理由のいずれかのために異なる場合がある。

ビデオストリームＤＳＬアナライザ１００は、一又はそれ以上の例示のデータソース３５０、３５５、３６０または３７０から含まれるデータに基づく、種々のパラメータ（複数パラメータ）、管理データ１３０、１４０または情報のいずれかを受信して、メトリック情報１５０を生成し、更に、管理データ１３０、１４０の完全性をチェックして、管理データ１３０、１４０の一貫性をチェックする。管理データ１３０、１４０がデータソース３５０、３５５、３６０または３７０の複数から収集される場合、例示のデータビデオストリームＤＳＬアナライザ１００は発見的に、論理的に統計学的にまたは確率論的に、チェックされたデータ１３０、１４０を組み合わせる。

一実施態様によれば、ビデオストリームＤＳＬアナライザ１００は種々のデータ構造（複数構造）、データテーブル（複数テーブル）、データ配列（複数配列）、などのいずれかを使用して、例示のデータベース３７２内に非物理層管理データ１３０、物理層管理データ１４０、メトリック情報１５０またはＤＳＬ構成データ１６０を格納する。例示のデータベース３７２は、機械アクセス可能なファイル内にまたは種々のメモリ３７５のいずれか内に格納される。

ネットワーク管理システム（ＮＭＳ）３９０は、例示のＤＳＬシステム３００を制御するか、監視するか、維持するかまたはプロビジョニングして、ビデオストリームＤＳＬアナライザ１００および顧客サービス担当者、販売人または技師のような人が例示のＤＳＬシステム３００を制御するか、監視するか、維持するかまたはプロビジョニングすることができるようにする。例示のＮＭＳ ３９０は、例示のデータベース３７２内に格納されるパラメータ（複数パラメータ）、データまたは情報を使用するか、ビデオストリームＤＳＬアナライザ１００または人に供給するかまたは利用できるようにする。代わりとしてまたはさらに、図３の例示のＮＭＳ ３９０は、例示のビデオストリームＤＳＬアナライザ１００によって推測されるか、推定されるか、計算されるかまたは求められるパラメータ（複数パラメータ）、データまたは情報を、直接供給するかまたは利用できるようにすることができる。例えば、ＮＭＳ ３９０は技師が非物理層管理データ１３０、物理層管理データ１４０、メトリック情報１５０またはＤＳＬ構成データ１６０の任意の組合せを取り出すことができるＧＵＩを提供することができる。

図４は、別の実施態様によるビデオストリームＤＳＬアナライザ１００を実現するブロック図である。ＤＳＬコンフィグレータ１２０は、性能欠陥識別器４１０、物理層問題識別器４２０、ＤＳＬ設定セレクタ４３０、ＤＳＬ設定実現チェッカ４４０およびＤＳＬ設定コンフィグレータ４５０を更に含む。性能欠陥識別器４１０は、メトリック情報発生器１１０および物理層問題識別器４２０に動作するように接続される。ＤＳＬ設定セレクタ４３０は、物理層問題識別器４２０およびＤＳＬ設定実現チェッカ４４０に動作するように接続される。ＤＳＬ設定コンフィグレータ４５０は、ＤＳＬ設定実現チェッカ４４０に動作するように接続される。代替実施態様によれば、ＤＳＬ設定セレクタ４３０は性能欠陥識別器４１０に動作するように接続される。

図５は、一実施態様によってＤＳＬシステム３００上のビデオストリーミングの性能を診断する方法の流れ図である。この方法は、図１、３または図４内に示されるビデオストリームＤＳＬアナライザ１００によって実施されることができる。しかしながら、その他の適切な構成もまた、使われることができる。ステップ２１０で始まる方法は一連の動作として記載されているが、動作は任意の適切な順序で実行されることができて、任意の適切な組合せで繰り返されることができることは認識されよう。

図５のブロック５１０に、および図４に示すように、性能欠陥識別器４１０は性能閾値情報４１２と生成されたメトリック情報１５０を比較するように動作する。これに応答して、性能欠陥識別器４１０は性能欠陥があるかどうか判定して、対応する性能欠陥情報４１４を任意選択で生成する。性能欠陥の判定は、経験の品質（ＱｏＥ）またはサービス品質（ＱＯＳ）上に直接的な影響を有する。例えば、ＩＰＴＶのような、ビデオストリーミングは遅延、ジッターおよび損失のようなネットワーク効果に影響を受ける。セットトップボックス（ＳＴＢ）のような加入者装置３３２が、（ジッターを補償する）バッファリングの機構および（損失を補償する）エラーコンシールメントアルゴリズムを通してこれらの作用を部分的に補償することができる。しかしながら、増大されたバッファサイズがチャネル変更時間に否定的に影響を及ぼすのでバッファリングのソリューションは遅延問題を悪化させる。したがって、性能閾値は性能欠陥が生じるかどうか判定するために定められることができる。

図６の一番下のテーブルは、性能閾値情報４１２として直接または間接的に使われることができるいくつかの例示的な性能目標をリストする。例えば、最大推奨遅延は性能閾値情報４１２に対応することができ、および、測定された遅延は生成されたメトリック情報１５０に対応することができる。図６内にリストされた最大推奨遅延は例示のためだけのものであり、すなわち、特定の最大推奨遅延または性能閾値情報４１２は、特定の要件、装置、規格または用途に従い任意の適切な量であることができる。脱落し、繰り返され、順序が狂ったビデオフレームの度合いにユーザ経験を関連づける他の情報が、同様に使われることができる。ビデオおよびオーディオの最小アプリケーション層ビットレート要件の例もまた、図６内に示される。テーブル内の最大遅延の例および図６内の最小ビットレート要件の例は性能欠陥があるかどうか判定するのに用いられる性能閾値情報４１２の例であるが、しかし、任意の適切な性能要件および特定の要件レベルが使われることができる。

さらに別の実施態様によれば、性能閾値情報４１２は予め収集されたデータに基づいて調整される。例えば、性能閾値があまりに厳しいと判明する場合、性能閾値情報４１２は、人間の介入なしで自動的に、または人間の対話処理によってのどちらかで、例えば、システム資源を解放するか、処理負担を減少させるか、また他に性能速度を向上するために、緩和されることができる。別の実施態様によれば、性能閾値情報は帯域幅使用情報に基づいて調整される。例えば、帯域幅使用が比較的高い場合、性能閾値判定基準はサービス品質を向上するために調整されることができる。１日２４時間ＩＰＴＶのようなストリーミングビデオを見るユーザは、より高いサービス品質を必要とするであろう。代わりとして、ビデオストリームＤＳＬアナライザ１００は帯域幅使用に従いメトリック情報１５０を調整することができる。ユーザが積極的に帯域幅を使用する場合、およびその場合だけ、いくつかのメトリックスが装置から累算されることができる。例えば、ユーザが積極的にビデオチャネルを使用している場合だけ、ビデオ信号内のエラーがカウントされる場合、エラーカウントの影響は帯域幅に従い変化する。一実施態様によれば、性能閾値情報４１２が所望のＱＯＥもしくはＱＯＳ要件を満たすのに適切でない場合、または、ＱＯＥもしくはＱＯＳ要件が変化する場合、性能閾値情報４１２はそれに応じて調整されることができる。例えば、性能閾値情報４１２は、例えば、ＱＯＥもしくはＱＯＳ要件が変化する場合、または関数もしくは関係表が変化する場合、性能閾値情報４１２が人間の介入なしで自動的に変化するように、数学的関数によってもしくは単に関係表によってＱＯＥもしくはＱＯＳと関連づけられることができる。何の性能欠陥もない場合、処理はブロック２３０へ戻り、さもなければ、処理はブロック５２０へ進む。

ブロック５２０に、および、図４内に示すように、物理層問題識別器４２０は性能欠陥情報４１４を受信し、これに応答して物理層内に問題があるかどうか判定するように動作する。物理層問題識別器４２０は、物理層問題情報４２２を生成することができる。

図７は一実施態様によるＶＤＳＬ２に利用できる例示的なＤＳＬエラーメトリックスを示すが、しかし、その他のメトリックスが同様に使われることができる。例えば、図７内のＤＳＬ性能監視パラメータまたは管理データ１３０、１４０の一又はそれ以上のようなＤＳＬエラーメトリックスは、物理層に問題があるかどうか判定するために、物理層閾値と、またはブロック５１０に関するメトリック情報１５０と比較されることができる。これらのＤＳＬエラーメトリックスは例えば、１５分の間隔で、更に、現在のおよび過去の１日間隔で、または任意の適切な間隔で報告されることができる。時間変化するノイズの実例は、他のＤＳＬ回線からのクロストーク、ホームネットワークシステムからのクロストークおよび他の顧客構内デバイスからの干渉を含む。上記のパラメータＤＳＬエラーメトリックスのいずれかが、物理層またはＤＳＬ層でビデオストリーミング問題を検出するのを助けることができる。一実施態様によれば、ＣＶ−ＣおよびＣＶ−ＣＦＥのパラメータがＤＳＬ層の品質メトリックを推定する目的のために使われることができる。これに加えて、ＥＳ−ＬおよびＥＳ−ＬＦＥパラメータ（カウント秒数）は同様に役立つことができる。

一実施態様によれば、図７内にリストされるパラメータまたはその他の適切なパラメータの一つ以上が、組み合わせられることができて、図６内に与えられるパフォーマンス基準と比較されることができる。更に、物理層閾値はブロック５１０に関して上で説明されているものと同様の方法で調整されることができる。物理層に何の性能欠陥もない場合、報告がブロック５３０で他のモジュールになされ、さもなければ、処理はブロック５４０へ進む。

ブロック５４０に、および、図４内に示すように、ＤＳＬ設定セレクタ４３０は物理層性能欠陥情報４２２を受信し、これに応答して少なくとも一つのＤＳＬ設定を選択してＤＳＬ設定情報４３２を生成するように動作する。物理層性能欠陥情報４２２および前述した推定手続きを使用して得られるその他の適切なメトリックスは、ＩＰＴＶ劣化がＤＳＬ物理層による場合を明らかにするのを助けることができる。ＩＰＴＶ問題を診断した後、例えばＤＳＬ設定情報４３２を変更することによって、問題を修正するように動作が推奨されることができる。代替実施態様によれば、ＤＳＬ設定セレクタ４３０は性能欠陥識別器４１０から性能欠陥情報４１４を受信するように動作する。

一実施態様によれば、別々に処理されるべきＩＰＴＶ劣化の２つの場合がある。１つの場合では、ＤＳＬ問題が時間変化する定常ノイズによる可能性がある。応答として、供給されたデータレートは定常ノイズによるリトレインを防ぐ設定に調整されなければならない。

第２の場合は、ＤＳＬ問題が回線上のインパルスノイズから生ずるものである。この問題は、構成パラメータを回線上のインパルスノイズ保護を強化するように調整することによって処理されなければならない。構成パラメータは、最小／最大データレート、最大遅延および最小インパルスノイズ保護を含むことができる。

ＡＤＳＬ高速インターネットサービスとＩＰＴＶサービスをサポートするＶＤＳＬとの間の重大な差は、ＩＰＴＶサービスが高速インターネットサービスと違って、データレート保証を含むことができるということである。したがって、インパルスノイズ保護を強化する構成パラメータに対するいかなる変更も、データレートが保証されたレベルより下に低下しないようなものでなければならない。あるいは、インパルスノイズ保護強化が不可避的にかなり低下するデータレートに至る場合、提供されたサービスは異なるカテゴリに割り当てられなければならない。ＤＳＬ設定セレクタ４３０は、ＤＳＬ設定が有効であるかどうか判定するために、ＤＳＬ設定実現チェッカ４４０に提案されたＤＳＬ設定情報４３２を与える。

ブロック５５０に、および、図４内に示すように、ＤＳＬ設定実現チェッカ４４０は提案されたＤＳＬ設定に対してチェックを行う。ＤＳＬ設定実現チェッカ４４０はＤＳＬ設定情報４３２を受信し、これに応答して、選択された少なくとも一つのＤＳＬ設定が実現可能かどうかチェックし、かつ、ＤＳＬ設定実現情報４４２を生成するように動作する。ＤＳＬ設定実現チェッカ４４０は、インパルスノイズ保護に関連した異なる構成設定から生じるデータレート性能を予測することができる。しかしながら、これらのパラメータの任意の選択は可能でなく、構成エラー、無効な構成または初期化失敗をもたらすかもしれない。この種のエラー／失敗に対して以下の２つの理由がある：

１．装置限界−特定の構成設定は、インターリーバ（デインターリーバ）メモリのようなリソース限界および単位時間あたりデコードされることができる最大数のＲＳ符号語のために実現するのが不可能である。この種の限界は、例えば、ＡＤＳＬ２およびＡＤＳＬ２＋勧告に記載されている。同じ種類の限界が、ＶＤＳＬ１およびＶＤＳＬ２システム内に存在する。対応する勧告は、これらの限界を明示的に与えないが、しかしながら、インターリーバ−デインターリーバ遅延、インターリーバ深さおよび（１／Ｓ）パラメータの集合体(aggregate)に関する公知の制約（図８−９を参照）。

２．性能目標：データレートの損失−装置が特定の設定を可能とする場合、性能目標が実現可能でないかもしれず、および、結果として、新しいＤＳＬ設定情報４３２が必要である点に注意されたい。例えば、インパルスノイズ保護能力を強化するには、しばしば、ＲＳ符号語当たりのパリティバイト数を増加させる必要がある。この種の増加は追加的な冗長性をもたらし、正味利用可能なデータレートはこれに対応して減少することを意味する。換言すれば、追加で与えられる保護はより小さい正味符号化利得の代価で生じることができる。

ＤＳＬ設定実現チェッカ４４０は、この実施態様による１）装置および２）性能目標の任意の組合せをチェックすることができる。上記の観察および対応するＤＳＬ設定実現情報４４２を使用して、ＤＳＬ設定セレクタ４３０は、この例に従って、ブロック５６０の強化されたインパルスノイズ保護を伴う新しい構成を推奨する：

所定の所望のデータレートに対して、以下の条件を満たすＩＮＰ＿ｍｉｎおよびｄｅｌａｙ＿ｍａｘの組合せを選択する：

ａ）新しいＩＮＰ＿ｍｉｎは、以前のＩＮＰ＿ｍｉｎより大きくなければならない。

ｂ）ＩＮＰ＿ｍｉｎおよびｄｅｌａｙ＿ｍａｘの組合せは、それらが所望のデータレートに対して、および、所定の装置に対して実現可能であるようなものでなければならない。これは、図８および９内のもののようなテーブルを使用して実現されることができる。

所定の所望のデータレートおよび選択されたＩＮＰ＿ｍｉｎとｄｅｌａｙ＿ｍａｘの組合せに対して、現在の正味符号化利得と以前の正味符号化利得との間の差を推定する。この差が、強化された保護による「損失」度を与える。現在のＳＮＲマージンがこの「損失」と比較して不十分な場合、ＩＮＰ＿ｍｉｎおよびｄｅｌａｙ＿ｍａｘのこの選択は回線の初期化失敗をもたらすであろう。正味符号化利得の差を知っていると、この状況を回避することができる。正味符号化利得を計算する方法が、次に説明される。

正味符号化利得の推定
図１０は、一実施態様に従って正味符号化利得を算出するためのＤＳＬ連結された符号器および復号器１０００のブロック図である。ＤＳＬ設定情報４３２をチェックする正味符号化利得の例示の計算が、与えられる。正味符号化利得が、ビデオストリームＤＳＬアナライザ１００または任意の適切なＤＳＬオプティマイザ、または、ＤＳＬ管理センタによって使われて、ＤＳＬ設定情報４３２をチェックすることができる。

図１０に示すように、ＡＤＳＬ１、ＡＤＳＬ２、ＡＤＳＬ２＋およびＶＤＳＬ２において、連結された符号器および復号器は外部のＲＳ符号器１０１０、ＲＳ復号器１０２０および内部のトレリス符号器１０３０、１０４０の連結から成る（例えば、Ｗｅｉによって開発された１６−状態、４次元コード）。インターリーバ１０３０はＲＳ符号器１０１０とトレリス符号器１０５０との間に配置され、および、デインターリーバ１０４０はトレリス復号器１０６０とＲＳ復号器１０２０との間に配置される。

ＲＳコードの、符号語サイズＮおよびペイロードバイト数Ｋは既知であるとする。（これらは、特定の実装に対して、報告された値からまたはまとめられたテーブルから、またはアルゴリズム記述から、得られることができる。）またＲＳ復号器１０２０で生じるエラーがランダムであるとする。また所望のデータレートがＲであるとする。符号化利得は、以下のように３つの項の加算としてデシベルで表されることができる：

符号化利得損失は、以下のように表されることができる：

ＤＳＬ設定情報４３２が、例えば１）装置構成、２）性能目標または３）必要符号化利得の任意の組合せに基づいて実現可能でない場合、処理はブロック５６０へ進み、選択された少なくとも一つのＤＳＬ設定を利用できないとして分類し、および、新しいＤＳＬ設定情報４３２を備えた別のＤＳＬ設定が、ブロック５４０で選択される。ＤＳＬ設定情報４４２が実現可能な場合、処理はブロック５７０へ進む。

ブロック５７０および図４に示すように、この実施態様によるＤＳＬ設定コンフィグレータ４５０は、ＤＳＬ設定実現情報４４２を受信して、これに応答してＤＳＬ構成データ１６０を生成する。ＮＭＳ ３９０は、ＤＳＬ構成データ１６０を受信して、要求された構成変更を実行する。

図１１は、例示のビデオストリームＤＳＬアナライザ１００を実現するように使われるかまたはプログラムされることができる例示のプロセッサプラットホーム１１００のブロック図である。例えば、プロセッサプラットホーム１１００は一又はそれ以上のメインプロセッサ、コア、マイクロコントローラ、１１０５などによって実現されることができる。プロセッサ１１０５は、例示のビデオストリームＤＳＬアナライザ１００を実現するためにメインメモリ１１１５内に（例えば、ランダムアクセスメモリ（ＲＡＭ）内に）含まれるビデオＤＳＬアナライザ命令１１１０を実行する。プロセッサ１１０５は、ＩＮＴＥＬ（登録商標）、ＡＭＤ（登録商標）、ＳＵＮ（登録商標）、ＩＢＭ（登録商標）ファミリのコア、プロセッサまたはマイクロコントローラからのＤＳＰ、ＲＩＳＣプロセッサまたは汎用もしくはカスタマイズされたプロセッサのような、任意のタイプの処理ユニットであることができる。

プロセッサ１１０５は、バス１１２５経由で（読取り専用メモリ（ＲＯＭ）１１２０またはハードディスク装置のような）メインメモリ１１１５と通信する。ＲＡＭ １１１５はダイナミックランダムアクセスメモリ（ＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）またはその他のタイプのＲＡＭデバイスによって実現されることができ、および、ＲＯＭ １１２０はフラッシュメモリまたはその他の所望のタイプのメモリデバイスによって実現されることができる。例えばＧＵＩを表示するかまたは出力するために、出力デバイス１１４０が使われることができる。

また、本願明細書に記載されている例示のソフトウェアまたはファームウェア実装は、以下のような任意選択の有形の記憶媒体上に格納されることができる点に注意するべきである：磁気媒体（例えばディスクもしくはテープ）、ディスクのような光磁気もしくは光学媒体、またはメモリーカードのような固体媒体または一又はそれ以上のリードオンリー（不揮発性）メモリ、ランダムアクセスメモリもしくは他の書き換え可能な（揮発性の）メモリを収容する他のパッケージ、またはコンピュータ命令を含有する信号。電子メールまたは他の自己内蔵型情報アーカイブまたはアーカイブの組に対するデジタル添付ファイルは、有形の記憶媒体に等しい配布媒体とみなされる。したがって、本願明細書に記載されている例示のソフトウェアまたはファームウェアはそれらの上記したまたは等価物および承継媒体のような有形の記憶媒体または配布媒体上に格納されることができる。代替実施態様によれば、ビデオＤＳＬアナライザ命令１１１０は例えば、無線通信またはＷｉＭａｘネットワークのような広領域無線アクセス網（ＷＷＡＮ）、またはＷｉＦｉネットワークのようなローカル無線アクセス網（ＬＷＡＮ）経由で、メモリ１１１５に無線で送信されることができる。

もちろん、当業者は、例示のシステム内に例示されるメモリ１１１５の順序、サイズおよび割合が変化することができると認識するであろう。これらのハードウェア部品およびソフトウェア部品のいずれかまたは全てが、ハードウェアだけで、ソフトウェアだけで、ファームウェアだけで、またはハードウェア、ファームウェアもしくはソフトウェアのいくつかの組合せで具体化されることができることが考えられる。したがって、当業者は容易に、上記した実例がこの種のシステムを実現する唯一の方法でないと認識するであろう。

一実施態様によれば、ＡＳＩＣ、プログラマブルロジックアレイおよび他のハードウェアデバイスを含むがこれに限らず専用ハードウェア実装が、本願明細書に記載されている例示の方法もしくは装置のいくつかまたは全てを実現するために、全体的にあるいは部分的に、同様に構成されることができる。さらに、分散処理または構成要素／オブジェクト分散処理、並列処理または仮想マシン処理を含むがこれに限らず代替ソフトウェア実装もまた、本願明細書に記載されている例示の方法もしくは装置を実現するように構成されることができる。

図１２は、ＩＰＴＶに対する３つの例示的な代替ネットワーク階層化方式：ＭＰＥＧ−ＴＳ／ＵＰ １２１０、ＭＰＥＧ−ＴＳ／ＲＴＰ／ＵＤＰ １２２０およびネイティブＲＴＰ １２３０を示す。図１２は、非物理層管理データ１３０および物理層管理データ１４０の実例が与えられることを示す。ＩＰＴＶストリーミングのようなビデオストリーミングの配信に対して何の唯一の固有の仕様もなく、したがって、他の適切な層方式が使われることができる。したがって、ビデオストリームＤＳＬアナライザ１００はその他の適切なビデオストリーミング方式およびその他の将来のビデオストリーミング方式をサポートすることができる。

物理層１２３２プロトコルは、基底の物理媒体に依存する。異なる技術による、少なくとも３つのセグメントが使われることができる：

ｉ．バックボーン
バックボーン光リンクは、１０^-10より低いビットエラー確率によって特徴づけられる。

ｉｉ．最後の（最初の）マイル
イーサネット層による銅対を介したＶＤＳＬ送信のいくつかの例が、以下に与えられる：
・ＶＤＳＬ１
・ＶＤＳＬ２
・ＥＦＭ（最初の１マイルのためのイーサネット規格）のためのＶＤＳＬ

ＶＤＳＬトランシーバとイーサネット層１２３４との間のインタフェースは、γ−インタフェースと一般的に呼ばれている。これは、ＴＰＳ−ＴＣ（伝送プロトコル特有の伝送コンバージェンス）機能と「ユーザアプリケーションＩ／Ｆ」との間のインタフェースである。ＶＤＳＬ１は、ＨＤＬＣカプセル化に基づいて（ＰＴＭ−ＴＣと呼ばれる）パケット転送モードに対するＴＰＳ−ＴＣを規定する。このモードは、イーサネットトラフィックを搬送するのに用いられることができる。ＶＤＳＬ２は、イーサネットおよび一般パケットトランスポート（ＰＴＭ−ＴＣ）に対するＴＰＳ−ＴＣを規定する。このモードは、６４／６５カプセル化を使用する。（１０ＰＡＳＳ−ＴＳと呼ばれる）ＶＤＳＬのためのＥＦＭ規格は、ＶＤＳＬ１規格に基づくイーサネットシステムのためのＩＥＥＥ仕様である。

図１３は、電話線３１５上のＥＦＭ（最初の１マイルのためのイーサネット規格）の例示的なアーキテクチャを示す。ＥＦＭは、さまざまな機能に対してわずかに異なる命名を使用する。γ−インタフェースは、伝送コンバージェンス（ＴＣ）と物理符号化副層（ＰＣＳ）機能との間に位置する。

イーサネット層１２３４は、媒体アクセス制御（ＭＡＣ）層を含み、かつＩＥＥＥ規格８０２．３−２００２、地方および大都市圏ネットワーク、パート３：衝突検出型キャリア検知多重アクセス（ＣＳＭＡ／ＣＤ）アクセス方式および物理層の仕様、２００２年３月８日、に記載のフレームフォーマットを有する。ペイロード（ＭＡＣクライアント）データは、４６バイトと１５００バイトとの間で変化することができる。イーサネットフレームは、フレームチェックシーケンスを有し、それがエラーを検出するために使われることができる。ＩＰＴＶのような、ビデオストリーミングアプリケーションに対して、ペイロードデータはＩＰパケットを含む。

ＩＰ層１２４０は、２つの基本機能：アドレス指定およびフラグメンテーション／リアセンブリを提供する。データのフロー制御、エラー制御および接続または仮想回路が、提供されることができる。一実施態様によれば、インターネットグループ管理プロトコル（ＩＧＭＰ）がＩＰマルチキャスティングのために使われ、そこでＩＰパケットが単一のＩＰ宛先アドレスを用いて複数の宛先ホストに送信される。一群の宛先ホストがマルチキャストホストグループとして規定され、および、ホストグループのメンバーは動的である。このＩＧＭＰプロトコルが、それらのマルチキャストグループメンバーをすぐに隣接したマルチキャストルータに報告するためにＩＰホストによって使われる。

ユーザデータグラムプロトコル（ＵＤＰ）１２５０は、アプリケーションプログラムが最小のプロトコル機構で他のプログラムにメッセージを送信する手段を提供する。配信および複製保護は、保証されても保証されなくてもよい。

実時間プロトコル（ＲＴＰ）１２６０は、オーディオおよびビデオのような実時間データを送信するアプリケーションに対してエンドツーエンドのネットワークトランスポート機能を提供する。一実施態様によれば、リソース予約が利用可能であることができる。各ＲＴＰストリームは、必要に応じて複数のストリームを同期させるためにクライアント側で使用されるタイミング情報を具備しなければならない。ＲＴＰヘッダは、パケット損失を検出して、パケットシーケンスを回復させるためにレシーバによって使われることができるシーケンス番号を具備する。代替実施態様によれば、ＲＴＰ １２６０はさらに、データ配信を監視するための制御プロトコル（実時間制御プロトコル、ＲＴＣＰ）を含む。その主要機能は、データ配信の品質に関するフィードバックを提供することであって、プロトコルの不可欠な部分であるとみなされる。ネイティブＲＴＰ法１２３０は、ＲＴＰを介してＡＶＣビデオおよびＡＡＣオーディオを運ぶ。ＭＰＥＧ−ＴＳ １２１０、１２２０とは対照的に、異なるＲＴＰストリームがビデオおよびオーディオトランスポートのために使われる。一般的に、単一のＮＡＬユニットがＲＴＰパケットにマップされる。これによってビデオパケットの高機能なマッピングがパケットを搬送することができ、その結果、ビデオパケットは２つのＵＤＰパケットに分割されない。

ＭＰＥＧ−２トランスポートストリーム（ＭＰＥＧ−ＴＳ）１２７０は、ＩＳＯ／ＩＥＣ １３８１８−１：２０００（ＩＴＵ勧告Ｈ．２２２．０）、動画および関連したオーディオ情報の一般的な符号化：システム、２０００年１０月、に記載されている。この実施態様によれば、ＭＰＥＧ−ＴＳ １２７０は、４バイトのヘッダを含む１８８バイトを備えたパケットで構成されるが、しかし、任意の適切なパケットフォーマットが使われることができる。パケットペイロードはプログラム情報およびパケット化基本ストリーム（ＰＥＳ）を含み、それはビデオおよびオーディオ情報を搬送する。したがって、トランスポートストリームは多重化データ：オーディオ、ビデオおよびプログラム情報を含む。ＩＰＴＶストリーミングのためのＭＰＥＧ−ＴＳ／ＵＤＰ手法１２１０に関して、ＭＰＥＧトランスポートストリームはＵＤＰデータグラムのペイロードとして直接運ばれる。図１２に示すように、ＭＰＥＧ−ＴＳ／ＲＴＰ／ＵＤＰ法１２２０は複数のＭＰＥＧ−ＴＳパケットを運ぶためにＲＴＰペイロードを使用する。

ＭＰＥＧペイロード層１２８０に関して、高度動画像圧縮符号化標準(Advanced VideoCoding)（ＡＶＣ）は、ＭＰＥＧグループによって開発されて、ＩＴＵ−Ｔ勧告Ｈ．２６４、一般視聴覚サービスのための高度動画像圧縮符号化標準、２００５年５月におけるＩＴＵ勧告Ｈ．２６４として公開された。それは、また、ＭＰＥＧ−４パート１０として公知であり、ＤＶＤフォーラム、ブルーレイディスク協会、ＤＶＢ、３ＧＰＰおよびＩＳＭＡによって採用されている。一実施態様によれば、ＡＶＣは各画像をスライスにセグメント化する。画像スライスは、複数のマクロブロックを含む。マクロブロックは、１６ｘ１６ピクセルの画像に対応する。マクロブロックは、イントラまたはインターモードで符号化される。符号器の出力は、ネットワーク抽象化層（ＮＡＬ）ユニット内にカプセル化される。高度動画像圧縮符号化標準は、ＭＰＥＧグループによってＩＳＯ／ＩＥＣ １４４９６−３：１９９９、「視聴覚オブジェクトの符号化−パート３：オーディオ、１９９９」において規格化されており、現在ｉＴｕｎｅｓおよびＸＭ衛星無線によって使われ、および３ＧＰＰ、ＩＳＭＡおよびＤＶＢによって採用されている。

図１４は、１つの例示的な実施態様による複数通信層を診断するための流れ図である。この実施態様によれば、非物理層管理データ１３０はネットワーク層およびアプリケーション層データに対応する。しかしながら、このデータは開放型システム間相互接続基本参照モデル（ＯＳＩ）の全部または一部に従うことができる。更に、物理層の診断および管理はブロック１４１０で実行され、ネットワーク層の診断はブロック１４２０で実行され、および、アプリケーション層の診断はブロック１４３０で実行される。しかしながら、物理および非物理層の任意の組合せに対する診断が実行されることができる。例えば、ブロック４２０での物理層およびブロック１４３０でのアプリケーション層の診断が、物理層管理データ１４０および非物理層管理データ１３０に応答して実行される。

上記の仕様が特定のデバイス、規格またはプロトコルに関して例示の構成要素および機能を説明する範囲で、本発明の教示がこの種のデバイス、規格またはプロトコルに限られていないことが、理解される。たとえば、ＤＳＬ、ＡＤＳＬ、ＶＤＳＬ、ＨＤＳＬ、Ｇ．ｄｍｔ、Ｇ．ｈｓ、Ｇ．ｐｌｏａｍ、ＴＲ−０６９、イーサネット、ＤＳＰ、ＩＥＥＥ ８０２．１１ｘおよびＩＥＥＥ ８０２．３ｘは現在の最高水準の技術の例を表す。この種のシステムは、同じ汎用を有する高速なまたはより効率的なシステムによって定期的に取って代わられる。したがって、同じ汎用機能を有する代替物または将来のデバイス、規格またはプロトコルは、添付の特許請求の範囲の範囲内に含まれることを目的とされる等価物である。

そのさまざまな態様における本発明の他の変形例および変更態様の実施が当業者にとって明らかであること、および、本発明が記載されている特定の実施態様によって限定されないことが理解される。したがって、本願明細書に開示されかつ請求される、根本的基礎をなす原理の趣旨および範囲内に含まれるありとあらゆる変更態様、変形例または等価物が本発明によって包含されることが意図される。

一実施態様によるビデオストリームアナライザのブロック図である。 一実施態様によるＤＳＬネットワーク上のビデオストリームを診断する方法の流れ図である。 一実施態様によるＤＳＬシステムのブロック図である。 別の実施態様によるビデオストリームＤＳＬアナライザを実現するブロック図および方法である。 一実施態様によるＤＳＬシステム上のストリームを診断する方法の流れ図である。 一実施態様による最小および最大遅延に対するテーブルを例示する。 一実施態様によるＶＤＳＬ２に利用できるＤＳＬエラーメトリックスのテーブルである。 一実施態様による最小および最大遅延に対するテーブルである。 一実施態様による最小および最大遅延に対するテーブルである。 一実施態様によるＤＳＬ連結された符号化のブロック図である。 一実施態様による例示のプロセッサプラットホームのブロック図である。 一実施態様による３つの例示的な代替ネットワーク階層化方式を例示する。 一実施態様による電話線上のＥＦＭ（最初の１マイルのためのイーサネット規格）の例示的なアーキテクチャを例示する。 一実施態様による複数通信層を診断するための流れ図である。

Claims (14)

1. デジタル加入者線（ＤＳＬ）ネットワーク上を配送されたビデオストリームを診断するための方法であって、
   ビデオストリームに対応する少なくとも非物理層管理データおよび物理層管理データを受信するステップと、
   対応する時間枠に対して前記受信された管理データをグループ化するステップと、
   少なくとも前記非物理層管理データおよび前記物理層管理データの関数としてメトリック情報を計算するステップと、
   性能閾値と前記計算されたメトリック情報を比較し、比較に基づいて性能欠陥があるかどうか判定するステップと、
   性能欠陥があると判定したことに応答して前記物理層における問題があるかどうか判定するステップと、
   前記物理層における問題があると判定したことに応答して前記ＤＳＬネットワークの少なくとも１つのＤＳＬ構成を変更するステップと、を含む方法。
2. 請求項１に記載の方法であって、非物理層データが、イーサネット（登録商標）、インターネットプロトコル（ＩＰ），ユーザデータグラムプロトコル（ＵＤＰ），リアルタイムプロトコル（ＲＴＰ）、動画像専門家グループトランスポートストリームＭＰＥＧ−ＴＳ、動画像専門家グループ（ＭＰＥＧ）ペイロード、データ、リンク、ネットワーク、トランスポート、セッション、プレゼンテーションおよびアプリケーション層、のうちの少なくとも一つと関連するデータに対応する、ことを特徴とする方法。
3. 請求項２に記載の方法であって、前記非物理層管理データが、加入者帯域幅使用データ、ＭＰＥＧエラーデータ、受信パケット、受信バイト、損失パケット、損失率、破損パケット、オーバラン、アンダーラン、受信到着間隔ジッター、平均受信到着間隔、およびパケット不連続性カウンタ、のうちの少なくとも一つを含む、ことを特徴とする方法。
4. 請求項１に記載の方法であって、前記物理層管理データが、ＤＳＬ物理層からのパラメータであり、該パラメータが、報告されたＩＮＰ、報告された遅延、報告されたデータレート、フルイニットカウンタ、失敗したフルイニットカウンタ、ショートイニットカウンタ、失敗したショートイニットカウンタ、ＦＥＣＳ−Ｌカウンタ、ＥＳ−Ｌカウンタ、ＳＥＳ−Ｌカウンタ、ＬＯＳＳ−Ｌカウンタ、ＵＡＳ−Ｌカウンタ、ＦＥＣＳ−ＬＦＥカウンタ、ＥＳ−ＬＦＥカウンタ、ＳＥＳ−ＬＦＥカウンタ、ＬＯＳＳ−ＬＦＥカウンタ、ＵＡＳ−ＬＦＥカウンタ、ＣＶ−Ｃカウンタ、ＦＥＣ−Ｃカウンタ、ＣＶ−ＣＦＥカウンタ、ＦＥＣ−ＣＦＥカウンタ、ＣＲＣ−Ｐカウンタ、ＣＲＣＰ−Ｐカウンタ、ＣＶ−Ｐカウンタ、ＣＶＰ−Ｐカウンタ、ＣＲＣ−ＰＦＥカウンタ、ＣＲＣＰ−ＰＦＥカウンタ、ＣＶ−ＰＦＥカウンタ、およびＣＶＰ−ＰＦＥカウンタ、のうちの少なくとも一つである、ことを特徴とする方法。
5. 請求項１に記載の方法であって、前記性能閾値が、予め収集されたデータに基づいて調整される、ことを特徴とする方法。
6. 請求項５に記載の方法であって、さらに、帯域幅使用情報を受信し、前記帯域幅使用情報の受信に応答して前記性能閾値を調整するステップ、を含む方法。
7. 請求項１に記載の方法であって、さらに、
   ビデオストリ−ミングクライアントにおけるエラー回復、エラーコンシールメント、またはエラー回復およびエラーコンシールメントの両方が、前記判定された性能欠陥を適切に軽減することができるかどうか判定するステップと、
   前記ビデオストリーミングクライアントにおけるエラー回復、エラーコンシールメント、またはエラー回復およびエラーコンシールメントの両方を実行するために前記少なくとも一つのＤＳＬ構成を変更するステップと、を含む方法。
8. 請求項７に記載の方法であって、さらに、ストリーミングビデオクライアントにおけるエラー回復、エラーコンシールメント、またはエラー回復およびエラーコンシールメントが前記性能欠陥を適切に軽減することができる場合、前記物理層内にある問題を診断するステップ、を含む方法。
9. 請求項１に記載の方法であって、さらに、
   少なくとも一つのＤＳＬ設定を選択するステップと、
   前記選択された少なくとも一つのＤＳＬ設定が実現可能かどうかを判定するステップと、を含む方法。
10. 請求項９に記載の方法であって、さらに、
    正味符号化利得を推定するステップと、
    前記正味符号化利得の推定に応答して前記少なくとも一つのＤＳＬ設定が実現可能かどうか判定するステップと、を含む方法。
11. 請求項９に記載の方法であって、さらに、前記少なくとも一つのＤＳＬ設定が実現可能な時、前記少なくとも一つのＤＳＬ構成を変更するステップ、を含む方法。
12. 請求項９に記載の方法であって、さらに、最小ＩＮＰ、最大遅延、目標データレート、最大データレート、最小データレート、目標ノイズマージン、最大ノイズマージンおよび最小ノイズマージン、のうちの少なくとも一つを、アップストリーム、ダウンストリーム、またはアップストリームおよびダウンストリームの両方に設定するステップ、を含む方法。
13. 請求項１に記載の方法であって、ビデオストリームが、ビデオおよびオーディオストリーム、テレビストリームおよびインターネットプロトコルテレビ（ＩＰＴＶ）ストリーム、のうちの少なくとも一つを含む、ことを特徴とする方法。
14. ビデオストリームＤＳＬアナライザであって、
    ビデオストリームに対応する少なくとも非物理層管理データおよぶ物理層管理データを受信する受信手段と、
    対応する時間枠に対して前記受信された管理データをグループ化し、少なくとも前記非物理層管理データおよび前記物理層管理データの関数としてメトリック情報を計算する、前記受信手段に接続される生成手段と、
    性能閾値と前記計算されたメトリック情報を比較し、比較に基づいて性能欠陥があるかどうか判定する手段と、
    性能欠陥があると判定したことに応答して前記物理層における問題があるかどうか判定する手段と、
    前記物理層における問題があると判定したことに応答してＤＳＬ構成を変更する手段と、を備えることを特徴とするアナライザ。

Images