JP5203359B2 - ベクトル化ｄｓｌシステム - Google Patents

Description

本発明は一般にデジタル通信システムを監視するための方法、システム、及び、装置に関する。より詳細には、本発明は、ＤＳＬシステム又はそれと同等なシステムであって、特に分配及び／又は結合されたベクトル化ＤＳＬシステムの管理に関する。

本出願は、２００６年６月６日出願の“Improved DSL system”と題された米国仮特許出願番号６０／８１１，３５５により生じた優先権を主張する。

本出願は、２００６年３月３日出願の“Nesting of Vectored DSLs”と題された米国特許出願番号１１／３６７，９３０に関連する。

本出願は、２００５年１１月４日出願の“Phantom Use in DSL Systems”と題された米国特許出願番号１１／２６７，６２３に関連する。

本出願は、２００５年１１月２２日出願の“Tonal Rotors”と題された米国特許出願番号１１／２８４，６９２に関連する。

本出願は、２００６年１月２０日出願の“Tonal Precoding”と題された米国特許出願番号１１／３３６，６６６に関連する。

本出願は、２００６年１月２０日出願の“Adaptive GDFE”と題された米国特許出願番号１１／３３６，１１３に関連する。

本出願は、２００６年２月１日出願の“DSL System Training”と題された米国特許出願番号１１／３４５，２１５に関連する。

本出願は、２００６年１月２８日出願の“Binder Identification”と題された米国特許出願番号１１／３４２，０２８に関連する。

デジタル加入者線（ＤＳＬ）技術は、デジタル通信のための広帯域を既存の加入電話回線（ループ設備及び/又は銅製の設備と呼ばれる）を通じて潜在的に提供する。加入電話回線は、音声帯域アナログ通信のための独自設計であるにも関わらず、広帯域を提供することができる。特に、非対称デジタル加入者線（ＡＤＳＬ）及び超高速デジタル加入者線（ＶＤＳＬ）は、離散マルチトーン（ＤＭＴ）回線コードを用いることによって加入者線の特性に適応させることができる。そのＤＭＴは、いくつかのビットを、各トーン（又はサブキャリア）に割当てる。その各トーンは、加入者線の各末端でのモデム（通常、送信機及び受信機の両方として機能する送受信機である）のトレーニング及び初期化の間に測定されるようなチャネル状況に適用させることが可能である。ＤＳＬシステムは、ベクトル化技術を用いることができる。その場合には、漏話干渉の影響を軽減するよう、そして、性能が向上するよう複数のペアの間で共有の送信機信号処理及び/又は共有の受信機信号処理を実行させることができる。ＤＳＬベクトル化技術は通常、非ベクトル化技術と比較して複雑性が非常に高くなる。

例えば、ベクトル化ＤＳＬシステムのような通信システムにおける動作を向上させるシステム、方法、及び、技術は、技術的に顕著な効果を示すと考えられる。特に、計算上の複雑性を減少させ、サービス品質の要求を満足させ、そして、動作コストを削減するようなシステム、方法、及び、技術は、技術的に顕著な効果を示すと考えられる。さらに、上述の目的を達成するような通信システムにおける利用及び制御可能なデータのレベル及びタイプを向上させることは、その分野において注目すべき効果を示すと考えられる。

発明の概要
本発明の実施例は、相互接続に接続された少なくとも一つのベクトル化エンジンを備える。相互接続は、それぞれのＤＳＬループを通じて複数の加入者宅内機器（ＣＰＥ）デバイスに接続することが可能である。実施例はさらに、相互接続のための指示を受けるインターフェースを含む。その相互接続は、それぞれのＤＳＬループを通じて各ベクトル化エンジンをＣＰＥデバイスの重複しないサブセットに接続する。インターフェースはまた、ベクトル化をＤＳＬループに適用するベクトル化エンジンの一つのための指示を受ける。そのＤＳＬループを通じて、ＣＰＥデバイスの一つを相互接続へ接続する。

本発明の実施例は、例示の方法、そして、添付の図面の形態に制限されない方法によって説明する。その図面内において、同じ記号の表す内容は、同じ要素を示す。この開示における「ある」実施例や「一」実施例の記載は、必ずしも同一の実施例を示していないことに留意すべきである。そのような記載は、「少なくとも一つ」を意味する。

本発明の以下の詳細な説明は、本発明の一又は二以上の実施例に言及するが、そのような実施例には限定されない。むしろ、詳細な説明は例示のみを目的とする。本発明がそれら限定された実施例を逸脱する場合、図面についてここに記載された詳細な説明は、当業者であれば説明目的のために提供されることを容易に理解することができるであろう。

本発明において開示する方法、システム、及び、装置は、ベクトル化ＤＳＬシステムのために特定の利益をもたらす。ベクトル化ＤＳＬシステムにおいて、共有の送信機信号処理動作／共有の受信機信号処理動作は、複数のＤＳＬ回線の信号上で実行することが可能である。さらに、ベクトル化ＤＳＬ送受信機の通常の複雑性を削減することができる。その削減は、ベクトル化を行う一部の計算上の負担をベクトル化ＤＳＬ送受信機の外部のシステムへ移転させることによって、又は、性能と複雑性との間の最も良好なトレードオフを達成するベクトル化システムを制御することによって本発明の実施例を用いて行われる。ＤＳＬシステムは、ベクトル化技術を用いることができる。この場合、漏話干渉の影響を軽減するよう、そして、性能を向上させるよう複数のペアの間で共有の送信機信号処理又は共有の受信機信号処理を実行する。ＤＳＬベクトル化技術は、非ベクトル化ＤＳＬ技術と比較して複雑性が非常に高くなる。このため、ＤＳＬベクトル化技術は、改善されたデータレポート及びパラメータ制御を可能にするインターフェースによって効果を得ることができる。そのようなインターフェースは、複雑性と性能との間のトレードオフをさらに適切に管理するのに役立たせることができる。これにより、ベクトル化の効果を最小のコストで実現することが可能となる。

ここで使われる用語「ベクトル化（vectoring）」及びそれと同等な用語は、「分配ベクトル化（distributed vectoring）」、「結合ベクトル化（bonded vectoring）」を意味することができる。「分配ベクトル化」において、複数のユーザのモデムからの信号は、一緒に処理される。「結合ベクトル化」において、単一ユーザの複数のループからの信号は、一緒に処理される。分配ベクトル化、及び、結合ベクトル化の混成、そして、他のベクトル化の方法は、当業者に既知である。分配ベクトル化、及び、結合ベクトル化の混成方法は、上記で参照した米国特許出願番号１１／３６７，９３０に開示されている。

ＤＳＬ管理エンティティのようなコントローラや、ＤＳＬオプティマイザ、スペクトル管理センター（ＳＭＣ）、動的スペクトル管理センター（ＤＳＭセンター又は単にＤＳＭＣ）、「スマート」モデム、制御ソフトウエア、制御ハードウエア、コンピュータシステムなどは、本発明の様々な実施例に関連して記載されているような動作データ及び／又は性能のパラメータ値を収集かつ分析するよう用いることが可能である。コントローラ及び／又は他のコンポーネントは、コンピュータへの埋め込みデバイスや、デバイスの組み合わせとすることができる。ある実施例において、コントローラは、モデムから離れた場所に配置する。他の場合には、コントローラは、モデムや、デジタル加入者線アクセスマルチプレクサ（ＤＳＬＡＭ）、他の通信システムデバイスに直接接続される機器であるモデムの一又は双方と一緒に配置することが可能である（よって「スマート」モデムが与えられる）。ここで用いられる「連結する」、「結合する」、「接続する」などのような語句は、２つの要素及び／又はコンポーネント間の連結を表し、そして、直接同時かそれとも間接的に接続されるという意味を意図する。例えば、必要に応じて一又は二以上の介在要素を介して又は無線コネクションを介する。

本発明の実施例は、ここに開示されている通り及び／又はこの開示により当業者によって示唆される通り、ベクトル化ＤＳＬシステムにおいて用いることが可能である。本発明の様々な実施例を用いることが可能な２つの既知のシステムを図１及び図２に示す。これらのシステムは技術的に既知であり理解されていることから、本発明の説明に関するものを除いて図１及び図２には詳細な説明を示していない。

図１Ａは、ベクトル化のためのＩＴＵ−Ｔ Ｇ．９９７．１標準による参照モデル図の拡張事例であり、結合ループ１３０−２及び単一ループ１３０−１を示す。そのループは、分配ベクトル化を用いてループ１３０−２を含む一又は二以上のループと連結させることが可能である。加入者宅内機器（ＣＰＥ）側のモデム（又は他のＤＳＬデバイス）は、ＡＤＳＬ、ＶＤＳＬ、そして、ＤＳＬサービスのその他のタイプを取り扱うｘＤＳＬ送信遠隔ユニット（ｘＴＵ−Ｒ）としてみなされる。同様に、同じ理由から、上流の（複数の）端末デバイスは、ｘＤＳＬ送信中央ユニット（ｘＴＵ−Ｃ）としてみなされる。

さらに、図２Ａはまた、ベクトル化のためのＤＳＬフォーラムＴＲ−６９の技術レポートによる配置図の拡張事例である。そこでは、多数のユーザのループ２１３−１、２１３−２、そして、２１３−３は、分配ベクトル化を用いて連結させることができ、また、単一ユーザのループ２１３−３は、結合ベクトル化を用いて連結させることができる。

図１Ａは、Ｇ．９９７．１標準（時おり、Ｇ．ｐｌｏａｍと呼ばれる）の単一ペアシステムを拡張するベクトル化システムのための参照モデルを示す。この場合において、本発明の実施例を実装することが可能である。このモデルは、様々な標準を満たす全てのＡＤＳＬシステムに適用することができる。そのＡＤＳＬシステムは、スプリッタを含んでも含まなくてもよい。その様々な標準は、ＡＤＳＬ１ (Ｇ．９９２．１) 標準、ＡＤＳＬ−Ｌｉｔｅ (Ｇ．９９２．２) 標準、ＡＤＳＬ２ (Ｇ．９９２．３) 標準、ＡＤＳＬ２−Ｌｉｔｅ(Ｇ．９９２．４) 標準、ＡＤＳＬ２＋(Ｇ．９９２．５) 標準、ＶＤＳＬ１(Ｇ．９９３．１) 標準、そして、 Ｇ．９９３．２ ＶＤＳＬ２標準、同様に、Ｇ．９９１．１標準、及び、Ｇ．９９１．２ ＳＨＤＳＬ標準、また、それら全てを結合又は結合しないものである。

Ｇ．９９７．１標準は、ＤＳＬ送信システムのための物理層の管理をＧ．９９７．１で定義されたクリアＥＯＣ（embedded operation channel、内部オペレーションチャネル）、そして、Ｇ．９９ｘ標準で定義された指示ビットの使用及びＥＯＣ管理の使用に基づいて明確にする。さらに、Ｇ．９９７．１は、構成管理、故障管理、そして、性能管理のためのネットワーク管理要素の内容を明確にする。これら機能を実行する際、システムは多くの動作データを利用する。動作データは、ベクトル化アクセスノード（ＡＮ）又はネットワーク終端（ＮＴ）で利用可能であり、そして、ＡＮから又はＮＴから収集されてもよい。ＡＤＳＬフォーラムのＴＲ−０６９によるレポートはまた、管理情報ベース（Management Information Base、MIB）、そして、どのようにそれがアクセスされることが可能かをリストしている。

図１及び図１Ａにおいて、カスタマの端末機器１１０は、ホームネットワーク１１２に接続される。ホームネットワーク１１２は、ネットワーク終端ユニット（ＮＴ）１２０に順に接続する。ＤＳＬシステムの場合、ＮＴ１２０は、ｘＴＵ−Ｒ１２２（例えば、時として送受信機とみなされるモデムであって、ＤＳＬ標準の一つによって定義される。）、又は、その他任意の適切なネットワーク終端モデムや、送受信機、他の通信ユニットを備える。例えば、各モデムは、製造番号やモデル番号によって識別されることが可能である。当業者に明らかなように、そして、ここに開示されている通り、各モデムは、通信システムと相互にやりとりを行い、通信システムに接続して、動作データを通信システム内のモデムの性能結果として生成する。

ＮＴ１２０はまた、管理エンティティ（ＭＥ）１２４を備える。ＭＥ１２４は、例えば、マイクロプロセッサや、マイクロコントローラ、ファームウエア又はハードウエアの回路状態機械のような任意かつ適切なハードウエアデバイスとすることが可能である。そのハードウエアデバイスは、適切な基準及び／又は他の基準による要求に応じて実行することが可能である。ＭＥ１２４は、ＮＴのＭＩＢの性能データを収集し、記憶する。そのＭＩＢは、各ＭＥによって維持される情報のアクセス可能なデータベースである。データベースへのアクセスは、ＳＮＭＰ（シンプルネットワークマネージメントプロトコル）などのようなネットワーク管理プロトコルを介して、管理者コンソール／管理者プログラムに提供するためにネットワークデバイスから情報を集めるよう用いられる管理プロトコルを介して、又は、トランザクション言語１（ＴＬ１）コマンドを介して行われる。ＴＬ１は、電気通信ネットワーク要素間でレスポンスやコマンドをプログラムするよう長年用いられているコマンド言語である。

システム内の各ｘＴＵ−Ｒは、ある電話局（ＣＯ）又はその他の主要場所内のｘＴＵ−Ｃに接続される。図１において、ｘＴＵ−Ｃ１４２は、ＣＯ１４６内のベクトル化アクセスノード（ＡＮ）１４０に配置する。当業者にとって明らかなように、ベクトル化ＡＮ１４０は、ベクトル化ＤＳＬＡＭ又はそれと同等なもののようなベクトル化ＤＳＬシステムのコンポーネントとすることが可能である。同様に、ＭＥ１４４は、ｘＴＵ−Ｃ１４２に関連する性能データのＭＩＢを維持する。当業者にとって明らかなように、ベクトル化ＡＮ１４０は、ブロードバンドネットワーク１７０又は他のネットワークに接続することが可能である。ｘＴＵ−Ｒ１２２及びｘＴＵ−Ｃ１４２は、ループ１３０によって、相互に接続される。ＤＳＬの場合には、ループ１３０は通常、他の通信サービスも伝達するツイストペアの電話回線である。

図１及び図１Ａで示した幾つかのインターフェースは、性能データを特定及び収集するために用いることが可能である。Ｑインターフェース１５５は、オペレータのネットワーク管理システム（ＮＭＳ）１５０とＡＮ１４０内のＭＥ１４４との間のインターフェースを提供する。Ｇ．９９７．１標準で特定されている全てのパラメータは、Ｑインターフェース１５５に適用される。ＭＥ１４４で提供される近端のパラメータは、ｘＴＵ−Ｃ１４２から生じる。一方、ｘＴＵ−Ｒ１２２からの遠端パラメータは、Ｕインターフェースによる２つのインターフェースのどちらかによって生じさせることができる。指示ビット及びＥＯＣメッセージは、組み込みチャネル１３２の一つを用いて送られ、物理媒体依存（ＰＭＤ）層で提供される。そして、その指示ビット及びＥＯＣメッセージは、ＭＥ１４４内で必要なｘＴＵ−Ｒ１２２のパラメータを生成するよう用いることが可能である。チャネル１３２は、Ｇ．９９７．１の管理インターフェースの一部である。他には、ＯＡＭ（Operations（動作）、 Administrations（運営）、Management（管理））チャネル及び適切なプロトコルは、ＭＥ１４４より要求があった場合に、パラメータをｘＴＵ−Ｒ１２２から取り出すよう用いることが可能である。同様に、ｘＴＵ−Ｃ１４２からの遠端パラメータは、Ｕインターフェースによる２つのインターフェースのどちらかによって生じさせることができる。指示ビット及びＥＯＣメッセージは、ＰＭＤ層で提供され、ＮＴ１２０のＭＥ１２４内で必要なｘＴＵ−Ｃ１４２のパラメータを生成するよう用いることが可能である。他には、ＯＡＭチャネル及び適切なプロトコルは、ＭＥ１２４より要求があった場合に、パラメータをｘＴＵ−Ｃ１４２から取り出すよう用いることが可能である。

Ｕインターフェース（原則的に一又は二以上のループ１３０）において、ｘＴＵ−Ｃ１４２で１つ（Ｕ−Ｃインターフェース１５７）、そして、ｘＴＵ−Ｒ１２２で１つ（Ｕ−Ｒインターフェース１５８）である２つの管理インターフェースが存在する。インターフェース１５７は、Ｕインターフェース１３０によって情報を取り出すｘＴＵ−Ｒ１２２のために、ｘＴＵ−Ｃの近端のパラメータを提供する。同様に、インターフェース１５８は、Ｕインターフェース１３０によって情報を取り出すｘＴＵ−Ｃ１４２のために、ｘＴＵ−Ｒの近端のパラメータを提供する（例えば、Ｇ．９９２．１又はＧ．９９２．２）。

Ｇ．９９７．１標準は、Ｕインターフェースの各所で任意のＯＡＭ通信チャネルを特定する。このチャネルが実装されている場合、ｘＴＵ−ＣとｘＴＵ−Ｒのペアは、物理層のＯＡＭメッセージを送るために、そのチャネルを用いることができる。従って、そのようなシステムの送受信機１２２、１４２は、それぞれのＭＩＢにおいて、様々な動作データ、そして、性能データを共有する。

１９９８年３月のＤＳＬフォーラムによる「ADSL Network Element Management」と題されたＤＳＬフォーラム技術レポートＴＲ−００５内のＡＤＳＬ ＮＭＳｓに関して、より詳細な情報を理解することができる。そのことは、当業者にとって既知である。また、上記の通り、２００４年４月の「CPE WAN Management Protocol」と題されたＤＳＬフォーラム技術レポートＴＲ−０６９は、当業者にとって既知である。最後に、２００４年４月の「LAN-Side DSL CPE Configuration Specification」と題されたＤＳＬフォーラム技術レポートＴＲ−０６４も、当業者にとって既知である。これら文献は、ＣＰＥ側の管理のために異なる状況を扱っている。ＶＤＳＬについてのより詳細な情報は、ＩＴＵ標準Ｇ．９９３．１（時おり、「ＶＤＳＬ１」と呼ばれる）及びＩＴＵ標準Ｇ．９９３．２（時おり、「ＶＤＳＬ２」と呼ばれる）、同様に執筆が進行中のＤＳＬフォーラムのいくつかの文献内に存在することが分かる。これら文献の全ては、当業者に既知である。さらなる情報は以下のものによって理解することができる。「VDSL Network Element Management」と題された（２００３年２月）ＤＳＬフォーラム技術レポートＴＲ−０５７（以前は、ＷＴ−０６８ｖ５）、「FS-VDSL EMS to NMS Interface Functional Requirements」と題された（２００４年３月）ＤＳＬフォーラム技術レポートＴＲ−０６５、そして、「Data Model Template for TR-069 Enabled Devices」と題されたＤＳＬフォーラム技術レポートＴＲ−１０６、同様に、ＶＤＳＬ２ ＭＩＢ要素のためのＩＴＵ標準Ｇ．９９７．１の改定、又は、ＡＴＩＳ動的スペクトル管理レポートＡＴＩＳ−０６００００７で利用可能である。更なる情報は、「Testing & Interoperability: ADSL2/ADSL2plus Functionality Test Plan」と題されたＤＳＬフォーラムの草案中の文献ＷＴ−１０５、「Testing & Interoperability: VDSL2 Functionality Test Plan」と題されたＷＴ−１１５、そして、「DSL Home Technical: TR-069 Implementation Guidelines」と題されたＷＴ−１２１。

当業者にとって明らかなように、これら文献に開示された動作データの及び／又は動作パラメータの少なくとも一部は、本発明の実施例に関連して用いることができる。さらに、本システムの説明の少なくとも一部は、本発明の実施例に同じく適用できる。ＤＳＬ ＮＭＳから利用可能な動作データ及び／又は動作情報の各種タイプはここで理解することが可能であり、その他のものは当業者に既知である。

図２及び図２Ａは、一又は二以上のＣＰＥ側デバイス２０５を備え、ＣＰＥ側デバイスは、ＬＡＮ２０８によってＣＰＥモデムに又は他のＤＳＬデバイス２１０に接続することができる。モデム２１０は、一又は二以上のループ２１３によって、ベクトル化ＤＳＬＡＭに又は他の上流のＤＳＬデバイス２１５に接続される。ベクトル化ＤＳＬＡＭ２１５は、地域ブロードバンドネットワーク又は他のブロードバンドネットワークに接続することができる。当業者にとって明らかなように、そのネットワークには、ブロードバンドリモートアクセスサーバ（ＢＲＡＳ）やそれと同等なものを含む。自動構成サーバ（auto-configuration server、ＡＣＳ）２２０は、インターネットやそれと同等なものの一部とすること及び／又はそれらに接続することが可能である。ＡＣＳ２２０は、地域ブロードバンドネットワークを介して、ベクトル化ＤＳＬＡＭ２１５に接続される。ＡＣＳ２２０は、コントローラに対して「北向き」又は上流のインターフェース２２２（例えば、ＤＳＬ管理エンティティ、ＤＳＬオプティマイザ、ＤＳＭセンタ、スペクトル管理センター（ＳＭＣ）、制御ソフトウエア（ＡＣＳを外部に接続するよりむしろ内部に存在させることが可能）など）、そして、「南向き」又は下流のインターフェースを有する。図２及び図２Ａにおいて、南向きのインターフェース２３１、２３２は、ＡＣＳ２２０をＣＰＥ ＤＳＬデバイス２１０及びＣＰＥ側デバイス２０５へ接続する。以下でより詳細に説明する通り、本発明の実施例によるその他の実施例も用いることが可能である。

図３及び図３Ａは、基礎となる図１及び図１Ａの参照モデルを用いて拡張したＤＳＬシステムである。図１及び図１Ａのシステムとは異なり、図３及び図３Ａの拡張したシステムはそれぞれ、ベクトル化ＤＳＬシステムに接続されているＤＳＬ管理ツール及びＤＳＬ管理エンティティを有する。図３及び図３Ａを参照すると、ＤＳＬ管理エンティティ１９０は（例えば、サーバ１９７内に格納されており、サーバ１９７はブロードバンドネットワーク１７０に接続されている）、例えば、一又は二以上のＤＳＬデバイス１２２、１４２、システムにおける一又は二以上のＭＥｓ１２４、１４４、ＮＭＳ１５０、及び／又は、ＤＳＬ管理ツール１９５などのような様々なシステムコンポーネントと通信することを可能にする。その上、ＤＳＬ管理ツール１９５は、様々なシステムコンポーネントに利用可能である。図３及び図３Ａにおいて、ＤＳＬ管理ツール１９５は、ＮＭＳ１５０、ＭＥ１４４、そして、ＤＳＬ管理エンティティ１９０に接続されている。

図４及び図４Ａ、同様に図２及び図２Ａは、基礎となるＴＲ−０６９レポートによる配置図を用いて拡張したＤＳＬシステムである。図４及び図４Ａ内の各システムは、一又は二以上のＣＰＥ側デバイス４０５を備える。そのＣＰＥ側デバイスは、ＬＡＮ４０８によってＣＰＥモデム又は他のＤＳＬデバイス４１０に接続することが可能である。モデム４１０は、一又は二以上のループ４１３によってベクトル化ＤＳＬＡＭ又は他の上流のＤＳＬデバイス４１５に接続される。ベクトル化ＤＳＬマネージャ４４０（例えば、コントローラ、ＤＳＬ管理エンティティ、ＤＳＬオプティマイザ、ＤＳＭセンタ、スペクトル管理センター（ＳＭＣ）、制御ソフトウエアなど）は、例として地域ブロードバンドネットワークを介して、ベクトル化ＤＳＬＡＭ４１５に接続される。ベクトル化ＤＳＬマネージャ４４０は、それのコンポーネントとしてＡＣＳ及びサービス構成マネージャ（Service Configuration Manager）を備え、そして、一又は二以上の「南向き」又は下流のインターフェースも有することが可能である。一方、図４において、南向きインターフェース４３１、４３４は、ベクトル化ＤＳＬマネージャ４４０をＣＰＥ ＤＳＬデバイス４１０及びベクトル化ＤＳＬＡＭ４１５に接続する。以下でより詳細に説明する通り、本発明の実施例によるその他のインターフェースも用いることが可能である。

図５は、システムのレイアウトや操作を示すＤＳＬシステムの一般的な概念図を示す。ユーザが、ＣＰＥモデムを通じて銅製の設備によるＤＳＬＡＭｓ及びそれと同等なものに通信するような、レイアウト及びその他任意のレイアウトは、ここでは「現場」システムと呼ばれる（対立するものとしては、理論上の接続形態の構成を用いた「実験」システムである）。多くの送受信機のペアが動作及び／又は利用可能であるＤＳＬ設備の通常の接続形態において、各加入者のループの一部は、複数のペアの結合部（又は束）内で他のユーザのループと一緒に配置される。図５では図示していないが、ループは、ドロップワイヤの形態をとり、配線の基礎としてみなされる加入者宅内機器（ＣＰＥ）に近接するポイントで束から抜ける（配線ターミナル（distribution terminal）でとして既知である）。従って、加入者のループは、２つの異なる環境を行き来する。ループの一部は、結合部の内側に配置することができ、ここでは、時おり外部の電磁波妨害からループが保護されるが、漏話の影響を受けやすい。基礎を抜けた後、このペアが多くのドロップ用の他のペアから遠くにある場合、ドロップワイヤは、漏話の影響を頻繁には受けないが、送信は、ドロップワイヤが保護されていないことから電磁波妨害によって顕著に品質が低下する。多くのドロップは、内部に２乃至８のツイストペアを有し、家庭への多重サービスの状況又はそれら回線の結合（単一サービスの多重化及び逆多重化）の場面で、さらなる多くの漏話が、ドロップ部分内のそれら回線間で発生する可能性がある。

一般的かつ典型的なＤＳＬの配置シナリオを、図５に示す。ユーザ５９１、５９２における全加入者（Ｌ＋Ｍ）のループ全ては、少なくとも一つの共通の結合部５４０を通る。各ユーザは、電話局（ＣＯ）５１０、５２０に専用線を通じて接続する。しかしながら、各加入者のループは、異なる環境及び媒体を通ることが可能である。図５において、カスタマＬ又はユーザ５９１は、光ファイバー５１３及びツイスト銅ペア５１７の組み合わせを用いてＣＯ５１０に接続する。これは通常、ファイバー・トゥ・ザ・キャビネット（ＦＴＴＣａｂ）又はファイバー・トゥ・ザ・カーブと呼ばれる。ＣＯ５１０における送受信機５１１からの信号は、ＣＯ５１０における光回線ターミナル５１２、そして、光ネットワークユニット（ＯＮＵ）５１８における光ネットワークターミナル５１５によって変換された信号である。ＯＮＵ５１８におけるモデム５１６は、ＯＮＵ５１８とユーザ５９１との間の信号のための送受信機として機能する。モデム５１６のサブセットは、ベクトル化グループを含むことができる。他に、モデム５１６の重複しない２以上のサブセットは、対応するベクトル化グループを含むことができる。同様に、モデム５２１のサブセットはベクトル化グループを含むことができる。他に、モデム５２１の重複しない２以上のサブセットは、対応するベクトル化グループを含むことができる。

残りのユーザＭ５９２のループ５２７は、銅のツイストペアのみである。ファイバー・トゥ・ザ・エクスチェンジ（ＦＴＴＥｘ）と呼ばれるシナリオである。実行可能かつ経済的に採算性がある場合、ＦＴＴＣａｂはＦＴＴＥｘより好ましい。これは、加入者のループの銅部分の長さを減少させるからである。その結果として、達成可能な転送速度を高める。ＦＴＴＣａｂループの存在は、ＦＴＴＥｘのループにとって問題をもたらす可能性がある。さらに、ＦＴＴＣａｂは将来、ますます一般的な接続形態となることが期待されている。この接続形態のタイプは、かなりの漏話干渉をもたらす可能性がある。そして、この接続形態のタイプはまた、様々なユーザの回線が異なるデータ伝送及び実効能力を有することを意味することができる。そのデータ伝送及び実効能力は、それらが動作する特定の環境によって生じる。その接続形態は、ファイバーによる「キャビネット」回線とエクスチェンジ回線が同一の結合部において混成可能なようにすることができる。

図５を参照すると、ＣＯ５２０からユーザ５９２への回線は、結合部５２２を共有するが、Ｃ５１０とユーザ５９１との間の回線では使用されない。さらに、他の結合部５４０は、ＣＯ５１０及びＣＯ５２０から、それぞれのユーザ５９１及びユーザ５９２までの全ての回線で共通である。

図６Ａが示す本発明の一実施例によると、制御ユニット６００は、ＤＳＬシステムに接続されている独立のエンティティの一部とすることが可能である。そのようなコントローラ６１０（例えば、ＤＳＬ管理エンティティ、ＤＳＬオプティマイザ、ＤＳＭサーバ、ＤＳＭセンター、スペクトル管理センター）は、システムの使用の最適化においてユーザ及び／又は一又は二以上のシステムのオペレータやプロバイダを支援する。（ＤＳＬオプティマイザはまた、動的スペクトルマネージャ、動的スペクトル管理センター、ＤＳＭセンター、スペクトル管理センター（ＳＭＣ）と呼ばれる。そして、ＤＳＬオプティマイザは、ＤＳＬ管理ツールを備え、及び／又はＤＳＬ管理ツールにアクセスする。）ある実施例において、コントローラ６１０は、独立した地域通信事業者（ＩＬＥＣ）又は競争的地域通信事業者（ＣＬＥＣ）とすることができる。そのＩＬＥＣ又はＣＬＥＣは、ＣＯ又は他の場所からの多くのＤＳＬ回線を動作させる。図６Ａの点線６４６を参照すると、コントローラ６１０は、ＣＯ１４６内に存在させることが可能であり、ＣＯ１４６の外部に独立させること、そして、システム内で操作を行う任意の会社とすることも可能である。さらに、コントローラ６１０を、ＤＳＬ及び／又は複数のＣＯｓ内の他の通信回線に接続することや、そのコントローラ６１０が、それら回線を制御することが可能である。

制御ユニット６００は、収集手段６２０及び分析手段６４０を備える。図６Ａを参照すると、収集手段６２０は、ＮＭＳ１５０、ベクトル化ＡＮ１４０におけるＭＥ１４４、そして、ＭＥ１４４により維持されるＭＩＢ１４８、及び／又は、ＤＳＬ管理ツール１９５に接続することができる（ＤＳＬ管理ツール１９５は、ＭＥ１４４に接続すること、又は、他の方法で通信することが可能である）。データはまた、ブロードバンドネットワーク１７０（例えば、ＴＣＰ／ＩＰプロトコルや他のプロトコル、又は、所定のシステム内における通常の内部データ通信の範囲外の手段）を介して収集することもできる。これら一又は二以上のコネクションは、制御ユニットがシステムから動作データを収集することを可能にする。その動作データは、本発明の実施例によるカスタマイズデータ収集及びデータパラメータの収集を含む。データは、一度に又は時間をかけて収集することが可能である。ある場合には、収集手段６２０は、周期的に収集を行うが、要求に応じて収集、又は収集を非周期的（例えば、ＤＳＬＡＭ又は他のコンポーネントがデータを制御ユニットに送ったとき）に行うことも可能である。従って、所望の場合、収集手段６２０は、制御ユニット６００が、情報や、ルール、下位ルールなどを更新することを可能にする。手段６２０によって収集したデータは、ＤＳＬシステム及び／又はそれの任意のコンポーネントのさらなる動作に関する分析及び決定のために、分析手段６４０に対して提供される。

図６Ａの典型的なシステムにおいて、分析手段６４０は、コントローラ６１０における信号生成手段６５０を動作させるモデム及び／又はシステムに接続する。この信号ジェネレータ６５０は、モデム及び／又は通信システムの他のコンポーネント（例えば、ＤＳＬ送受信機及び／又はシステムにおける他の機器やコンポーネントなど）に対して指示信号を生成し送るよう構成されている。これら指示は、許容可能なデータ転送速度や、送信パワーレベル、コーディング、待ち時間要求などに関する指示を含むことができる。指示はまた、制御パラメータ、そして、指示で用いるタイムスタンプパラメータに関する時間関連の情報を含むことができる。その指示は、本発明の実施例により、コントローラ６１０が通信システムについての様々なパラメータ及びプロセスの必要性及び／又は望ましさを決定した後に生成させてもよい。例えば、ある場合には、その指示信号は、システムを使用する一又は二以上のカスタマ及び／又はオペレータのために性能を向上させるのに寄与することができ、その性能の向上は、通信システムの動作を介してコントローラ６１０がよりよい制御を行うことを可能にすることによってなされる。

本発明の実施例は、収集したデータや、関連パラメータに関してなされた決定、そのようなパラメータに関する過去の決定などに関連するデータベース、ライブラリ、そして、他のデータのコレクションを利用することができる。参照データのこのコレクションは記憶させることが可能であり、例えば、図６Ａのコントローラ６１０内のライブラリ６４８として記憶できる。そして、そのコレクションは、分析手段６４０及び／又は収集手段６２０によって利用されてもよい。

本発明のある実施例において、制御ユニット６００は、ＰＣや、ワークステーション、それらと同等なものなどの一又は二以上のコンピュータに組み込むことが可能である。当業者には明らかなように、収集手段６２０、分析手段６４０、そして、信号ジェネレータ６５０は、一又は二以上のソフトウエアモジュール、そして、ハードウエアモジュール／デバイス１７００（例えば、一般的に既知であるタイプのコンピュータや、プロセッサ、ＩＣ、コンピュータモジュールなど）、さらに、その両方の組み合わせとすることができる。多くのモデムを用いて動作させる場合、収集したデータ量を管理するために、データベースを導入して用いることが可能である。

図６Ｂに本発明の他の実施例を示す。ＤＳＬオプティマイザ６６５は、ベクトル化ＤＳＬＡＭ６８５又は他のＤＳＬシステムコンポーネント上で動作し、及び／又はそれらに関連する。ベクトル化ＤＳＬＡＭ６８５及び他のＤＳＬシステムコンポーネントの一方又は両方は、電話会社の構内６９５上に置くことができる。ＤＳＬオプティマイザ６６５は、データ収集モジュール及びデータ分析モジュール６８０を備える。それらモジュール６８０は、ＤＳＬオプティマイザ６６５のために、そして、ＤＳＬオプティマイザ６６５に対して、動作データを収集、整理、調整、操作、及び、供給することができる（この場合、本発明の任意の実施例と同様に、動作データは性能データを含むことが可能である）。モジュール６８０は、ＰＣ又はそれと同等なものなどのような一又は二以上のコンピュータに実装することが可能である。モジュール６８０からのデータは、ＤＳＭサーバモジュール６７０に分析のため提供される。情報はまた、ライブラリ又はデータベース６７５により利用可能となる。そのライブラリ又はデータベースは、電話会社と関連していても関連していなくてもよい。プロファイルセレクタ６９０は、例えばデータパラメータやデータ値及び／又は制御パラメータや制御値のようなプロファイルを選択し、実装するよう用いることができる。当業者であれば明らかなように、プロファイル及び他の任意の指示は、ＤＳＭサーバ６７０の制御の基で、又は他の任意の適切な方法によって選択されてよい。セレクタ６９０によって選択されたプロファイルは、ベクトル化ＤＳＬＡＭ６８５及び／又は他の任意の適切なＤＳＬシステムコンポーネント機器内で利用することができる。図６Ｂで示す通り、そのような機器は、カスタマの敷地内における機器６９９のようなＤＳＬ機器に接続することが可能である。そのＤＳＬ機器は、分配ベクトル化及び／又は結合ベクトル化のための信号を提供することが可能である。当業者にとって明らかなように、図６Ｂのシステムは、図６Ａのシステムに似た方法で動作させることができるが、本発明の実施例を実行する際、相違点をもたせることが可能である。

ＤＳＬ管理インターフェースに関連して用いられる本発明の実施例は、ベクトル化ＤＳＬシステムが配置されている場合、ＤＳＬネットワークの管理能力を顕著に向上させることが可能である。そして、その実施例は、ＤＳＬ機器及びＤＳＬサービスに関連する検査を向上させることも可能である。その実施例はまた、計算の負担を削減することを目的とする。その計算の負担は、ＤＳＬＡＭ又はＣＰＥに配置されたＤＳＬ送受信機に課せられる。そして、その負担は、関連する計算の一部をＤＳＭＣによって実行可能にすることによって削減される。また、その実施例は、ＤＳＬカスタマ間でサービス品質要件、そして、優先順位決定要件を満たすために、ＤＳＭＣがベクトル化ＤＳＬシステムを管理することを可能にする。これら利益は、より高性能かつ総コストを抑えながらＤＳＬプロバイダが機器及びサービスを提供する機会を次々に生み出す。

より高度な制御、そして、ベクトル化ＤＳＬシステム又は同等なデジタル通信システムのより優れた動作を可能にする方法、技術、コンピュータプログラムプロダクト、装置、デバイスなどの実施例は、現場システムと実験システムの両方において以下でさらに説明かつ定義される。各実施例は、デジタル相互接続の実装又はスイッチの実装を含む。デジタル相互接続の実装又はスイッチの実装は、ベクトル化の利益を最大にし、かつ、ベクトル化の実行コストを最小にするようベクトル化エンジンへのＤＳＬループの最適なルーティングを可能にする。また、各実施例は、タイムスタンプの実装（システムのより正確な測定、監視、制御などを可能にする）、カスタマイズデータ収集技術、データパラメータ及び／又は制御パラメータのための拡張定義パラメータ、そして、現場設定及び実験設定の両方におけるこれらの実装を備える。

本発明の各実施例はまた、ＤＳＬＡＭ又はＣＰＥに配置されたベクトル化ＤＳＬ送受信機の複雑さを削減する方法、技術、コンピュータプログラムプロダクト、装置、デバイスなどを用いる。各実施例は、ＤＳＬ送受信機とＤＳＬオプティマイザとの間の通信の実装を含み、ベクトル化動作が実行されることを可能にする。そのベクトル化動作は、ＤＳＬマネージャ、ＤＳＬオプティマイザ、ＤＳＭサーバ、コントローラ、また、それたと同等なものによって行われる。これらベクトル化動作は、一般的なベクトル化制御や、トーン選択及び回線選択、回線のグルーピング、初期化機能、データ通信中動作（showtime operations）、データ転送速度、命令（orders）の優先度、ユーザの優先度、ユーザのサービス品質、更新動作、そして、ベクトル化ＤＳＬ回線の開始及び停止に関する動作に関連させることができる。

本発明の実施例は、ＤＳＬ管理エンティティ又はＤＳＬオプティマイザとベクトル化ＤＳＬＡＭとの間のインターフェース、そして、ＤＳＬ管理エンティティとデジタル相互接続との間のインターフェースに関する。ベクトル化ＤＳＬＡＭは一又は二以上のベクトル化エンジンを備える。デジタル相互接続のネットワークポートは、ＤＳＬループを通じてＣＰＥモデムに接続される。相互接続のＤＳＬＡＭポートは、ベクトル化エンジンのＤＳＬポートに接続される。これらを図１５に示す。図１５のシステム１５００において、ＤＳＬ管理エンティティ又はＤＳＬオプティマイザ１５０５は、インターフェース１５０６及び１５０８を通じて、それぞれベクトル化エンジン１５１１及び１５１２に接続される。ベクトル化ＤＳＬＡＭ（又は上流の他のＤＳＬデバイス）１５０７は、ベクトル化エンジン１５１１及び１５１２を備える。ベクトル化エンジン１５１１及び１５１２は、デジタル相互接続（ここではまた、スイッチと呼ばれる）１５２０のＤＳＬＡＭポート１５１６及び１５１７に接続される。デジタル相互接続１５２０のネットワークポート１５２２及び１５２４は、ＤＳＬループ１５３１、１５３２、１５３３、１５３４を通じてＣＰＥモデム１５４１、１５４２、１５４３、１５４４に接続される。本発明の実施例は、インターフェース１５０６及び１５０８を用いることが可能である新しくかつ向上した方法を定義する。

デジタル相互接続１５２０は、ベクトル化ＤＳＬＡＭ１５０７内の要素として図１５に示す実施例内に表されている。他の実施例において、デジタル相互接続はベクトル化ＤＳＬＡＭの外側に配置することが可能である。さらに、本実施例において、デジタル相互接続１５２０は、ベクトル化ＤＳＬＡＭの内側に配置されており、デジタル相互接続は、ベクトル化ＤＳＬＡＭのラインカード上に、又は、ベクトル化ＤＳＬＡＭ内の集積回路（ＩＣ）上に実装することが可能である。

本発明のさらに他の実施例において、複数のベクトル化ＤＳＬＡＭは、ＤＳＬ管理エンティティ１５０５によって制御されてもよい。その実施例において、各ベクトル化ＤＳＬＡＭは、一又は二以上のベクトル化エンジンを備える。そのような実施例におけるデジタル相互接続１５２０は、ベクトル化ＤＳＬＡＭの外側に配置され、相互接続のＤＳＬＡＭポートは、各ベクトル化ＤＳＬＡＭ内のベクトル化エンジンのＤＳＬポートに接続される。

ベクトル化を可能にすることについての決定を行うＤＳＭセンター又はスペクトル管理センター（ＳＭＣ）の重要性を示すある例を、図１５に関連して説明する。図１５は、システム１５００を表す。そこにおいて、２つのベクトル化エンジン１５１１及び１５１２が存在する。２つのベクトル化エンジン１５１１及び１５１２は、それぞれ、２つのＤＳＬ回線を提供する（例えば、エンジン１５１１は、回線１５３１及び１５３２を提供し、エンジン１５１２は、回線１５３３及び１５３４を提供する）。これは、ベクトル化エンジンが一度に２つの回線のみにベクトル技術を適用可能であることを意味する。この機器の制限は、回線を選択するためにベクトル化エンジンを重要なものにする。ベクトル化はその回線上で適用される。デジタル相互接続又はスイッチ１５２０は、２つのベクトルエンジンへの４つの回線のルートを適切に決定するよう図１５の実施例において実行される。そして、そのデジタル相互接続又はスイッチは、ベクトル化によって利益を得るであろうそれら回線の選択を可能にする。この例において、ＣＰＥ１５４３に対応する回線は、線１５５０によって示されるように、ＣＰＥ１５４１に対応する回線から激しい漏話を受けると推測される。この情報は、いろいろな方法を介してＤＳＭＣ１５０５で利用することが可能である。その方法は以下の通りである。結合部の識別は、前もってこれを公開しておいてもよく、また、結合部グループについての配線情報が利用可能とすることもでき、そして、これら回線上に配置されたＤＳＬサービスが激しい漏話を起すことを分かるようにしてもよい。結合部の識別のための技術は、前述の米国特許出願１１／３４２０２８において理解可能である。

この例において、ＤＳＭＣ１５０５は、ＣＰＥ１５４１及びＣＰＥ１５４３の回線がベクトル化エンジン１５１１へルートを決定するよう、そして、ベクトル化エンジン１５１１に対する下流の方向における遠端漏話（ＦＥＸＴ）の解消を可能にするよう選択することができる。そのような場合、ＤＳＭＣ１５０５はまた、ＣＰＥ１５４２及びＣＰＥ１５４４の回線がベクトル化エンジン１５１２へルートを決定するよう選択する。そして、ベクトル化エンジン１５１２に対する下流の方向におけるＦＥＸＴの解消を可能にすることができる。他には、ＤＳＭＣは、動作情報を得ることができ、デジタル相互接続を手動で制御及び構成するのに十分なアウトプットを管理者に提供し、特定のＣＰＥの回線のルートを特定のベクトル化エンジンへ適切に決定する。

ベクトル化は、初期化の間、以下のステップを含む。
−−ベクトル化の同期
−−ベクトル化チャネルの識別
−−ノイズ相関の識別

ベクトル化の同期は、ベクトル化ＤＳＬシステムによって実行すること可能である。ベクトル化ＤＳＬシステムは、「同期モード」の動作のためのＶＤＳＬ１及びＶＤＳＬ２の推奨で知られるそれらと同様な方法を用いる。そのような同期は、ベクトル化システムのＤＳＬ回線に対応するＤＭＴフレームの適切な配置を達成するよう要求される。

ベクトル化チャネルの識別及びノイズの相関関係の識別のステップの間、ＳＭＣは、差最大漏話結合又は最大ノイズ結合を伴う回線及びトーンを識別し、そして、指示信号又は制御パラメータをデジタル相互接続へ送信し、最大漏話結合を伴う回線を共通のベクトル化エンジンへ割当てる。ＳＭＣはまた、指示信号及び制御パラメータをベクトル化エンジンへ送信し、識別したトーンにベクトル化動作を適用する。ベクトル化動作は、ベクトル化システムの回線のサブセット上で、又は、ベクトル化システムのトーンのサブセット上で実行することが可能である。

結合部の識別の間、ＳＭＣは、ＤＳＬＡＭから得た回線のＸｌｏｇパラメータを用い、回線間の漏話を識別する。得た情報に基づいて、ＳＭＣは、同一グループ内で互いに漏話が多い回線を決定するよう指示を送り、そして、異なるグループ内で互いに漏話が少ない回線を決定するよう指示を送る。上流への方向に関して、回線をグルーピングするためにノイズ相関情報もまた組み込むことができる。得た情報に基づいて、ＳＭＣは、同一グループ内で互いに漏話が多い回線又は、同一グループ内で高い相関性を有するノイズ信号を持つ回線、を決定するよう指示を送り、異なるグループ内で互いに漏話が少ない回線、又は、異なるグループ内でノイズ信号の相関性が無いに等しい回線を決定する。

一度グルーピングが実行されると、ＳＭＣは、各ベクトル化エンジンに接続されている回線によって提供先のカスタマに関してのサービス品質の要求を収集する。サービス品質の要求に基づいて、ＳＭＣは、デコーディング（アップストリーム）又はエンコーディング（ダウンストリーム）のための各ベクトル化エンジンに接続された回線の順序付け（ordering）を算出する。次に、ＳＭＣは、ベクトル化ＤＳＬインターフェースを介して、各ベクトル化エンジンへ指示信号を送り、算出した回線の順序付けを適用する。サービス品質の要求は、カスタマのデータ転送速度や、カスタマの遅延についての要求、カスタマの優先度、カスタマのサービスクラスなどに基づくことが可能である。回線の順序付けを算出するための一方法は、サービス品質の要求を満たす転送速度帯の算出、及び、転送速度帯におけるポイントの選択を行うことを含む。ＳＭＣの指示信号は、受信機のベクトル化動作のための順序付け（アップストリーム動作）又は送信機のベクトル化動作のための順序付け（ダウンストリーム動作）に関する指示とすることが可能である。

一度、回線の順序付けが特定されると、各ベクトル化エンジンに接続された回線をデコーダィングするために要求される待ち時間は、順序配置（order configuration）のデコーディングに基づいてＳＭＣにおいて算出される。ある実装において、回線のデコーディングの待ち時間は、先にデコーディングされた回線のデコーディングの待ち時間に影響を受ける。従って、回線のデコーディングの待ち時間を算出することは、より重要なデコーディングの順序（order）を有する回線のデコーディングの待ち時間を最初に算出することを必要とすることができる。要求される待ち時間は、各ベクトル化エンジンのために許容される最大待ち時間に対して比較される。各ベクトル化エンジンに関して、要求される待ち時間が最大待ち時間を越えていない場合、指示信号は、ＳＭＣからベクトル化エンジンへ送られ、特定されている順序配置のデコーディングを適用する。

ＳＭＣによってベクトル化エンジンへ送られる指示信号又は制御パラメータは、以下のパラメータを含むことが可能である。maximum decoding delay（最大デコーディング遅延）、minimum impulse noise protection（最小インパルスノイズ保護）、decoding ordering（デコーディングの順序付け）、tones for applying vectoring（ベクトル化を適用するためのトーン）、lines for applying vectoring（ベクトル化を適用するための回線）、carrier mask（通信事業者のマスク）、spectrum mask（スペクトルのマスク）、data rate（データ転送速度）、margin（マージン）、又はtraining sequences（トレーニングシーケンス）。

上記ステップは、ベクトル化を実行するための設定／係数を算出する。実装可能な一つのアプローチは、これら係数の計算を用いることで役に立つＳＭＣに向けたものである。ある一般的な帯域の要求は以下で説明する。

ベクトル化チャネルの識別及びノイズ相関の識別のアウトプットは、ベクトル化が適用されているトーンの数に等しい複素量である。１０００トーンのセットは、実数部と虚数部のそれぞれのために１６ビットを必要とする典型的なトーンセットとして用いられ得る。さらに、この例は、チャネルマトリクス及びノイズ相関マトリクスの非常に大きい要素のみを送信する必要があると想定することができる。その想定は、これらマトリクスの各行に関して、多くても３つの要素が重要であることを示す。２つのベクトル化回線に関して、やりとりをするのに３２Ｋバイトのデータを必要とする。４つのベクトル化回線のデータ量は、９６Ｋバイトにまで増加する。最後に、８つのベクトル化回線に関して、やりとりをするのに１９２Ｋバイトのデータを必要とする。４つのベクトル化回線に関して、より詳細には、それぞれ４つの行を持つ２つのテーブルが存在する。その場合、各行の３つの要素のみが送信に必要である。そして、各要素は３２ビットを含む。１０００トーンのそれぞれに、そのようなテーブルが２つ存在する。結果として、（２）×（４）×（３）×（３２）×（１０００）＝７６８０００ビット＝９６Ｋバイトとなる。このやりとりは、１秒オーダー内の時間周期で完了させるべきである。従って、上記ベクトル化回線の評価は、モデムからＤＳＭＣへの方向におけるそのようなインターフェースの要求についてのおおよその評価を与える。

ＤＳＭＣからモデムへの方向における要求は主に、ベクトル化のためにフィードフォワードフィルター及びフィードバックフィルター（ダウンストリームのため又はアップストリームのためのどちらか）を設定する必要性によって支配される。さらに、これらは、予備部（例えば、各行中に意味のあるエントリは３つのみ）用いてかそれとも、より少ないパラメータ（例えばローター）を用いて２つのマトリクスを表すことが可能である。この見解は、ＤＳＭＣからモデムへの方向における帯域要求が、モデムからＤＳＭＣへの方向のそれと同一水準の大きさの範囲であることを示唆する。注意すべきは、ＤＳＭＣが、初期化の負荷を軽減するよう計算を実行することが可能であることである。その計算は、ビットローディングや、時間領域等化器（Ｔｉｍｅ Ｄｏｍａｉｎ Ｅｑｕａｌｉｚｅｒ、ＴＥＱ）フィルタリングの初期測定、周波数領域等化器（Ｆｒｅｑｕｅｎｃｙ Ｄｏｍａｉｎ Ｅｑｕａｌｉｚｅｒ、ＴＥＱ）タップの初期測定などである。ＤＳＭＣは、前述の米国特許出願番号１１／３４４、８７３に開示されているような技術を用いて、そのような計算を実行することが可能である。

通常のＤＳＬ送受信機は、少なくとも一つの集積回路、そして、集積回路の外部にある一又は二以上の個別コンポーネントを用いて実装される。少なくとも一つの集積回路（チップセットとして知られる）、及び、一又は二以上の個別のコンポーネントは、回路基板上に配置される。ＤＳＬＡＭ機器において、回路基板は、集積回路及び個別のコンポーネントを備えることができ、複数のＤＳＬ回線の動作をサポートする。複数のそのような回路基板（場合によって、ラインカードとして知られる）は、ＤＳＬＡＭ内に含まれてもよい。従って、多くのＤＳＬ回線を潜在的にサポートする。

ベクトル化ＤＳＬシステムのための潜在的な実装のアプローチは、ベクトル化（ＦＥＴＸの解消又はノイズの相関性を無くすような）に関連するデータ通信中信号処理（showtime signal processing）に向けたものである。そのベクトル化は、ＤＳＬ送受信機の主機能を実装するチップセットの外部で実行される。そのようなアプローチは、チップセット内の計算上の要求を低減することを可能にする。この外部で実装されるベクトル化は、受信機の実装のための図１６に示す。当業者であれば、外部で実装される同じようなベクトル化が送信機の実装のために可能であることを理解できるであろう。ＤＳＬ回線上の受信信号は、ＤＳＬチップセット１６０１のアナログフロントエンド１６０５を介して最初に処理される。次に、アナログ信号は、アナログデジタルコンバータ（ＡＤＣ）１６１０によって、デジタルの形態に変換される。デジタル信号は、１６１５によってデシメーションフィルタリング及びデジタルフィルタリングを受ける。ある実施例において、時間領域等化器（ＴＥＱ）は、符号間干渉（Ｉｎｔｅｒ−Ｓｙｍｂｏｌ Ｉｎｔｅｒｆｅｒｅｎｃｅ、ＩＳＩ）を減少させるよう信号上で利用される。その結果生じる信号サンプルは、ＤＭＴシンボルにグルーピングされ、周期的拡張（cyclic extension）は減少され、受信機のウインドウ動作を利用することが可能である。その次に、ＤＭＴシンボルは、ＦＦＴ動作へインプットとして提供される。

ベクトル化ＤＳＬシステムに関して、フィードフォワードベクトルフィルタリング１６３５は利用され、その結果として、フィードバックベクトルフィルタリング１６４０も利用される。フィードフォワードベクトルフィルタリング１６３５は、インプットとしてベクトル化回線のＦＥＴモジュール１６３０によって生成されたアウトプットを受ける。フィードバックフィルタリング１６４０のアウトプットは、ベクトル化回線のトレリスデコーダ／トレリススライサーモジュール１６４５のインプットとして提供される。フィードバックベクトルフィルタリングは、デコーダのエラーメトリクスの形態において、追加のインプトをベクトル化回線のトレリスデコーダ／トレリススライサーモジュール１６４５から任意で受け入れることが可能である。トレリスデコーダ／トレリススライサーモジュール１６４５のアウトプットは、デインタリーバ１６５０に提供される。そして、最後にＲＳデコーダ１６５５はデータストリームのリードソロモンデコーディングを実行する。その処理に関して、ベクトル化動作１６３５及び１６４０は、チップセット１６０１上の処理のための読み込み（load）を削減するために外部モジュール１６０２によって実行されてもよい。

上述の通り、あるインターフェースの例を評価することが可能である。さらに、有効な１０００のトーンを用いることが可能であり、そのトーンは、デコーディングが行われる必要があり、そして、そのトーン上でベクトル化が利用される。複雑なサンプルのそれぞれは、一次元あたり１６ビットによって表すことが可能である。４ＫヘルツのＤＭＴシンボルレートが用いられてもよい。これを換算すると、各方向において３２ビット／トーン × １０００トーン／フレーム × ４０００フレーム／秒 ＝ １２８Ｍｂｐｓに変換する必要がある。その結果生じる複数ユーザのための双方向の帯域幅要求を決定することができる。ベクトル化回線が２つであれば、５１２Ｍｂｐｓを必要とし、ベクトル化回線が４つであれば、１０２４Ｍｂｐｓを必要とする。そして、ベクトル化回線が８つであれば、２０４８Ｍｂｐｓを必要とする。この事例に関してインターフェース速度の要求が高いことは明らかである。

ベクトル化に必要な更新動作は数多くあり、そして、ＳＭＣは支援をもたらすことが可能である。最初に、通常のビット更新及びゲイン更新（gains updating）に加えて、ベクトル化はまた、ユーザの順序付けの更新を要求することができる。ベクトル化モジュール設定（例えば、フィードフォワードフィルター及びフィードバックフィルターの係数）に対して、更新を要求することができる。更新される設定の計算は、ＳＭＣによって実行させてもよい。送信機の事前コーディングは、受信機とそれに対応する送信機の間で相当な帯域幅のフィードバックチャネルを要求する。また、それは、データ通信中にブラインドチャネル識別／ノイズ識別かそれとも、ＶＤＳＬ２の同期フレームのような周期的な参照シンボルの存在のどちらか一方を要求する。そのような更新は、前述の米国特許出願番号１１／３４４、８７３に開示されている技術を含むことができる。

ＳＭＣが更新を推測すると、チャネル情報及びノイズ情報（又は、エラーメトリクスのような更新のための情報と同等なもの）はＳＭＣに伝えられる。期待されるインターフェースの要求は、初期化に関する前述のそれらと同様である。ここで一つの潜在的利点は、トーンの小さいサブセットのみを毎回更新する必要があることである。そのような更新は、ＤＭＴシンボルレートより大幅に低いレートで実行される。加えて、サービスプロバイダのプロダクトの提供、そして、結合部の漏話及びダイナミクスに基づくユーザの順序／優先度の決定は、複雑な機能であって、ＳＭＣによって最適に実行される。その場合、多くのカスタマ／回線上で計算の能力を共有することが可能である。

モデムのオン／オフのスイッチは、ベクトル化の更新に関して重要な問題である。この点におけるベクトル化エンジンとＳＭＣとの間のインターフェースの役割を以下の例を用いて説明する。

例１
ベクトル化システムに属するモデムが停止している場合、送信機でのベクトル化動作についての効果は最も低くなる。しかし、受信機におけるベクトル化動作に関して、そのようなモデムの停止は、顕著な効果を有する。回線がなくなった場合、ノイズの無相関性（及び／又はフィードバックを必要とする他の動作）は、有効性を失う可能性がある。考えられる受信機の一解決策は、ある状態を持続する回線のデコーディング動作に対するものである。その状態において、ノイズサンプルは検出され、そして、そのノイズサンプルは、ノイズの無相関性を保つために、他の受信機の経路へ提供される。そのような規則的なモデムの停止を用いて、ＳＭＣは、指示を送ることが可能となり、変化のために停止を調整し、ベクトル化モジュールを準備する。従って、ＤＳＭＣは、そのような停止において重要な役割を果す。

例２
新しい回線がベクトル化システムに入る必要がある場合、崩壊することなく動作を可能にするよう一連のステップを処理する。ＳＭＣが、漏話結合及び他の回線の動作状態についての情報を有する場合、ＤＳＭＣは、漏話の影響を最小にしながら新しい回線の導入を制御することができる。これを達成する一つの方法は、新しい回線の送信パワーを制限することであり、最初はレベルを低くし、そして、少しずつパワーを上げる。上記のＤＳＭＣの機能のためのインターフェースへの要求は、限られたものである。ＳＭＣが、新しい回線の漏話結合、ノイズの相関性、及び／又は動作状態についての情報を有していない場合、ＳＭＣは、動作データを提供するよう新しいＤＳＬ回線に指示し、新しい回線の動作データをベクトル化ＤＳＬシステムから収集する。ＤＳＭＣは、新しい回線を利用可能なベクトル化エンジンの一つに割当てるようデジタル相互接続に指示する。

例３
非ベクトル化動作だけでなくベクトル化動作におけるＳＭＣの機能は、安全である最大データ転送速度の測定である。そのデータ転送速度では、回線が、サービス崩壊又はサービスの喪失（又はカスタマの不満）の可能性が許容できる範囲の低くさで動作することを可能にする。このベクトル化の機能は、結合部における他の回線、そして、選択されているデータ転送速度及び漏話の優先順位の抽出と関連性が強い。ＳＭＣは、結合部の漏話情報及び結果として生じるキャンセラ係数だけでなく、回線及び結合部の履歴も含めながら、最適なデータ転送速度を算出することができる。その回線及び結合部の履歴は、使用パターン、ノイズ発生、インパルスノイズの存在、又は、他の非定常的な動作に関するものである。そのような算出は、サービスプロバイダのプロダクト（すなわち、カスタマのサービス選択及び支払い意欲の相関的要素でもあるデータ転送速度、そして、それらデータ転送速度についてのサービス品質の要求）、ビリング管理、そして、一般的なプロビジョニングの実行及び調整を、動作に組み込む。ＳＭＣは、任意のベクトル化情報とともにＤＳＬ回線へプロファイル（例えば、一又は二以上の以下のものを含む。データ転送速度、マージン、パワーレベル、そして、ＰＳＤ）を実行のために提供する（通常、ＤＳＬＡＭ又は要素管理システムＭＩＢを介する）。この機能は、広範囲な回線にわたる観測による統計情報だけではなくサービスプロバイダからのインプットを利用する。なので、この機能は、各ＤＳＬＡＭにおいて経済的な実装とはならない。適切に設計されたベクトル化システムにおいて用いられる取消しの命令（線形のみのシステムは、正しく評価が行われた場合、顕著な性能の喪失があることが分かる）は、ＤＳＬＡＭにおいて局所的に提供されるので、その算出は効率的ではない。

本発明の実施例は、ＤＳＬ管理エンティティとＤＳＬＡＭとの間、及び／又はＤＳＬ管理エンティティとＤＳＬ ＣＰＥモデムとの間のインターフェースに関する。これらを図７Ａで説明する。図７Ａのシステム７１０において、ＤＳＬ管理エンティティ７１２は、ベクトル化ＤＳＬＡＭ（又は他の上流のＤＳＬデバイス）７１４に、及び／又は、一又は二以上のＣＰＥモデム（又は他の下流のＤＳＬデバイス）７１６に接続される。ベクトル化ＤＳＬＡＭ７１４及びモデム７１６は、ＤＳＬループ７１５を通じて互いに接続される。ＤＳＬ管理エンティティ７１２は、インターフェース７２２を用いてベクトル化ＤＳＬＡＭ７１４に通信する。ＤＳＬ管理エンティティ７１２は、インターフェース７２４を用いてモデム７１６に通信する。本発明の実施例は、それらインターフェース７２２、７２４を用いることができる新しい方法及び改良された方法を定義する。さらに、本発明の実施例は、「現場」通信システム又は「実験」通信システムで用いることが可能である。

現在、様々なＤＳＬ管理インターフェースが存在する。当業者に既知である３つの公開されている標準は、ＤＳＬ管理のためのインターフェースに関連しており、
−ＩＴＵ−Ｔ標準Ｇ．９９７．１「Physical layer management for digital subscriber line transceivers」
−ＤＳＬフォーラム標準ＴＲ−０６９「CPE WAN Management Protocol」
−ＡＴＩＳ技術レポート「Dynamic Spectrum Management」ＡＴＩＳ−０６００００７

Ｇ．９９７．１は、ＤＳＬ送信システムのための物理層管理を定める。その物理層管理は、ＩＴＵ−Ｔ勧告のＧ９９２．Ｘシリーズ及びＧ９９３．Ｘシリーズで定義される指示ビットとＥＯＣメッセージの利用、そして、Ｇ９９７．１で定義されるクリア内部オペレーションチャネルの利用に基づく。また、Ｇ．９９７．１は、構成管理、故障管理、性能管理のためのネットワーク管理要素の内容も定める。

Ｇ．９９７．１は、アクセスノードと任意のネットワーク管理システムとの間のＱインターフェース（例えば、図１、図１Ａ、図３、図３Ａ、そして、図６Ａに示されている）を定める。そのネットワーク管理システムは、本発明の実施例におけるＤＳＬ管理エンティティの一部として考えることが可能である。ＴＲ−０６９は、ＣＰＥと自動構成サーバ（ＡＣＳ）との間の通信を対象としたＣＰＥ ＷＡＮ管理プロトコルを開示する。その自動構成サーバは、本発明の実施例におけるＤＳＬ管理エンティティの一部として考えることが可能である。これらを示した図７Ｂにおいて、ＤＳＬ管理エンティティ７４２は、
−インターフェース７５４を介したＣＰＥモデム７４６
−インターフェース７５２を介したベクトル化ＤＳＬＡＭ７４４
で利用可能である。ベクトル化ＤＳＬＡＭ７４４及びモデム７４６は、他の一つにＤＳＬループ７４５によって接続される。

ベクトル化ＤＳＬシステムのサポートはＧ．９９７．１とＴＲ−０６９のどちらにも設計されていない。ＴＣＰ／ＩＰネットワークスタックをバイパスするインターフェース、及び／又は、より早い速度かつ少ない待ち時間を提供するインターフェースは、ベクトル化ＤＳＬシステムの管理のために特別な利点を有する。本発明の実施例は、Ｇ．９９７．１及びＴＲ−０６９で定義されており、以下のようなインターフェースの制限の少なくとも一部を克服する。
−データパラメータや制御パラメータのための時期又は時間の識別機能がない
−各ＤＳＬ回線のためのカスタマイズデータ収集が不可
−非常に遅いデータレポートとデータ制御（タイムフレームが分単位）
−ベクトル化ＤＳＬシステムに関して不十分な制御パラメータ
−ベクトル化ＤＳＬシステムに関して不十分な報告データパラメータ
−初期化動作又はデータ通信中動作の間に順序配置を制御又は特定することに基づいて、漏話回避システム内のユーザの重要性の特定及び／又は解決を行うことができない。

ＴＲ−０６９は、付録Ｂ内に「ＣＰＥパラメータ」リストを定義する。ＴＲ−０６９の付録Ａに定義されているリモートプロシージャーコール（ＲＰＣ）の方法を用いて、読み取り又は書き込みのために、これらパラメータへアクセスすることが可能である。本発明の実施例は、ＴＲ−０６９の表６１における以下の「ブランチ」の基でパラメータに対して主に焦点を合わせている。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLInterfaceConfig
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLDiagnostics
第１の上記ブランチの基でいくつかのパラメータは、「現在」の値を維持するものとして定義される。例えば、
−アップストリームの減衰（UpstreamAttenuation）
−ダウンストリームの減衰（DownstreamAttenuation）
−アップストリームのパワー（Upstream Power）
−ダウンストリームのパワー（Downstream Power）

しかしながら、「現在」の定義は、定義しにくい。なぜならば、これらパラメータの更新を完了させるために複数の動作（それぞれ相当な処理遅延を伴う）を要求するからである。ある場合には、ＤＳＬ機器はこれらパラメータの継続的な更新を実現することができない。従って、以前のシステムにおいて、これらパラメータの最終更新からの正確な時間を実際には知り得ない。とりわけ、ベクトル化ＤＳＬに関して、パラメータの最終更新の時間を知るために要求される精度は、ＤＭＴシンボルの長さと同様とすることができる。

上記第２のブランチの基で定義されるパラメータは、診断動作が終了した後のみ用いられることを目的とする。しかしながら、これらパラメータの多くは、診断動作なしで算出されることが可能である。標準的なモデムの初期化の間にこれらパラメータを生成することが可能であり、また、そのパラメータをデータ通信中でも更新することが可能である。しかし、これらパラメータの最終算出／最終更新の時を正確に知ることがないという問題が存在し続ける。とりわけベクトル化ＤＳＬに関して、パラメータを取得する際の正確な時間を知ることは重要である。ベクトル化動作の有効性は、ベクトル化チャネル及びノイズ相関性についての適時の情報に依存するからである。最新では無いパラメータの値を識別可能とすることは重要である。なぜならば、ベクトル化動作を実行する時、そのような最新では無いパラメータの値を使用することは、ＤＳＬの性能を実質的に低下させるからである。

最後に、以前のシステムにおいて、パラメータに書き込みを行うためにこれらパラメータにアクセスする問題が存在している。現存するスキームに関して、既知の遅延及び／又は特定の遅延を伴って書き込み動作をスケジューリングする方法は存在しない。例えば、これは、特定の命令において複数の書き込みパラメータを書き込む必要がある時に必要である。さらに、これはベクトル化ＤＳＬのために重要である。なぜならば、特定のベクトル化モジュールへの書き込み動作が、正確に定義された時間（ＤＭＴシンボルの順序上の精度内で）で効果を生じるはずだからである。適切な時間に書き込み動作を利用できないことは、システムの不安定性及び／又はコネクションの損失を導く可能性がある。

Ｇ．９９７．１のセクション７は、管理情報ベース（ＭＩＢ）要素を定義し、そして、Ｑインターフェースを介して、そのＭＩＢの読み取りや書き込みを行うことを可能にすることを説明している。ＴＲ−０６９による状況と同様に、最終更新時間が知られていないような要素が存在する。特に、「Line Test, Diagnostic and Status Parameters」（Ｇ．９９７．１の表７乃至表２３及び表７乃至表２４）に基づく多くの要素は、それらがいつ算出されるか明確では無い。そのような算出は、以下の時間の任意の間に実行される可能性がある。
−診断の実行
−モデムの通常の初期化
−モデムの通常の動作（データ通信中）
−あるモデムが初期化を行っており、他のモデムがデータ通信中で既に動作している時間

一方で、ＭＩＢ要素への書き込みは、制御パラメータが実行及び／又は実装されるであろう時に、スケジューリング又は他の識別を行うための機能を備えていない。書き込み動作の実行と、そして、モデム又は他のＤＳＬデバイスの直近の再初期化が実行されることとの間の区別を行う方法がない。書き込み動作は、データ通信動作の終了又は他の通常の遮断動作なしに、適切に適応するモデムを必要とする。そのような特徴を必要とする要素の例は、「Line configuration profile groups」及び「Channel configuration profile」の群（Ｇ．９９７．１の表７乃至表９、表７乃至表１２）の基で理解可能である。

本発明のある実施例において、タイムスタンプは、ＴＲ−０６９の「ＣＰＥパラメータ」及び／又はＧ．９９７．１の「ＭＩＢ要素」に関連しており、時間の識別を提供する。その時間の識別は、そのＭＩＢ要素などが最後に更新された時（パラメータの読み取り専用のため）、又は、そのＭＩＢ要素などが実行されるべき時（パラメータの書き込みのため）である。この実施例の一つを、図８Ａに示す。その場合、パケット８１０は、動作パラメータの名前８１２及び値８１４に関連するタイムスタンプ８１６を含む。（データ）パラメータの読み取りのみを行うことについて、タイムスタンプは、一又は二以上の以下のタイプの情報を含むことができる。
−診断時、通常の初期化時、データ通信中などの特定の段階及び／又は特定の動作モードの間に更新が実行されたか？
−時間基準に対して更新はいつ実行されたか（例えば、直近の再初期化の開始に対して、又は、絶対時間に対して）？
（制御）パラメータの書き込みに関して、タイムスタンプは、一又は二以上の以下のタイプの情報を含むことができる。
−初期化を実行する更新であるか？
−ある遅延を伴って、又は、次の初期化を伴って更新が直近で実行されるか？
−既知の時間基準に対する更新の遅延は何であるか？

当業者であれば明らかなように、一般的なコンセプトでは、複数かつ任意のアプローチを用いて実行されてよい。ベクトル化ＤＳＬに関して留意することは、時間基準は、ＤＭＴシンボルの順序上での時間周期内で正確である必要がある。図８Ｂで説明する一つのアプローチにおいて、同一のタイムスタンプ８２６に関連するデータパラメータ及び／又は制御パラメータ８２２、８２４は、ＤＳＬ管理インターフェースを介して運ばれる単一のパケット８２０内に一緒にグルーピングされてよい。従って、単一のタイムスタンプは、図８Ｃに図示する通り全てのパラメータに関連する。

他には、タイムマーカーは、パラメータのための時間情報を提供するよう定義され用いられることが可能である。例えば、図８Ｃにおいて、動作パラメータ８３２は、パケット８３０内のタイムマーカー８３４に関連する。多くのタイムマーカーは、図８Ｃに示した典型的な表通りに定義することが可能である。各動作パラメータは、事前に定義されているタイムマーカーの一つと関連させることができる。当業者に明らかなように、図８Ｃのテーブル内に表される回線×１、回線×２、回線×３、及び、回線×４は、タイムマーカーを設定するよう用いられる同一のＤＳＬ回線、又は、複数の回線とすることができる。さらに、タイムマーカーを用いることは、以下のステップを用いて、ＴＲ−０６９のＲＰＣの方法の拡張として実装することが可能である。
１．タイムマーカーを記憶するようＣＰＥパラメータの新しいセットを導入する。
２．構造体メンバーの一つとしてタイムマーカー（Time-Marker）を含むようパラメータ値構造体（ParameterValueStruct）の構造体定義を拡張する（ＴＲ−０６９のＡ．３．２．１内の表１１による）。従って、新しい構造体であるパラメータ値時間構造体（ParameterValueTimeStruct）を生成する。
３．パラメータリスト（ParameterList）配列内にパラメータ値時間構造体要素を準備するようパラメータ値の取得（GetParameterValues）の方法（ＴＲ−０６９のＡ．３．２．２による）を拡張する。パラメータ値の取得が呼ばれるときはいつも、時間基準のＣＰＥパラメータの値を読み取るようタイムマーカーをパラメータリストに含めなければならない。
４．パラメータリスト（ParameterList）配列内にパラメータ値時間構造体要素を準備するようパラメータ値の設定の方法（ＴＲ−０６９のＡ．３．２．１による）を拡張する。パラメータ値の設定が呼ばれるときはいつも、時間基準のＣＰＥパラメータを書き込むよう対応するタイムマーカーをパラメータリストに含めなければならない。

従って、図１０に示す本発明の一又は二以上の実施例によると、ＤＳＬ実験システム及び／又はＤＳＬ現場システム（及び／又はそのような方法を実装するコンピュータプログラムプロダクト）を動作させる方法１０００は、一又は二以上の動作パラメータ（例えば、データパラメータ、制御パラメータ、動作パラメータなど）に関連して用いられるタイムスタンプを含むことができる。通常、ベクトル化ＤＳＬシステムの一又は二以上の動作パラメータは、１０２０で提供され、タイムスタンプは、１０５０で、その／それらの動作パラメータへ付加される。（当業者であればあきらかなように、ここで用いる「付加」は、他のデータへタイムスタンプ、又は、タイムスタンプデータを物理的に加えることと意味することができる。または、他のある方法において、関連データをタイムスタンプに関連付けすることと意味することができる。）次に、動作パラメータは、ＤＳＬシステムを動作させる際に（例えば、データパラメータ又は制御パラメータとして）１０６０で用いられてよい。又は、動作パラメータは、他の方法でＤＳＬシステム（ＤＳＬ現場システム、ＤＳＬ実験システムなどとすることができる。）を動作させる際に役立つよう用いられてもよい。上記で述べた通り、タイムスタンプを付加することは、タイムスタンプと動作パラメータの名前又は値を関連付けすることによって、そして、ここに開示された他の方法及び当業者にとって明らかな他の方法によって実行することができる。ＤＳＬデバイスを用いた本発明は（以下に限定されないが）、モデム、ＤＳＬＡＭ、ラインカード、リモートターミナル、ラインターミナル、自動構成サーバ、ネットワーク管理システム（時おり、要素管理システムとして既知である）の様々な実装又はコンポーネント、そして、それらと同等なものを含むよう用いることが可能である。本発明の実施例は、ここに、そして、当業者に明らかな他のものに示され示唆されているようなＤＳＬシステムにおいて実行することが可能である。

データパラメータ（すなわち、読み取り専用のパラメータ）を含む場合、タイムスタンプは、フェーズ識別及び／又は時間基準とすることが可能である。フェーズ識別は、動作モードを識別する。その動作モードは、ＤＳＬシステムや他のシステムにおいて、データパラメータが動作のフェーズに関して最終更新された時、又は、他の任意の時間的な記述である時を示す。動作モードの例は、診断、通常の初期化、データ通信中などを含む。ベクトル化ＤＳＬに関して、動作のフェーズは、関心のある回線の仕様に合わせることができ、そして、ベクトル化係数更新などのようなイベントを参照することが可能である。時間基準は、絶対時間によって定義される時間のポイントや、一又は二以上のフェーズ変移に関連するポイント（例えば、初期化からデータ通信を行うまで）、一又は二以上のフェーズ定義されたイベントに関連して定義された時間のポイント（例えば、データ通信中に入った後の３０秒、最後の初期化の後の５６４秒など）などとすることができる。ベクトル化ＤＳＬに関して、時間基準は、ＤＭＴスパーフレーム（又はＤＭＴ同期シンボル）に関して、又は、ＤＭＴシンボルに関してさらに繊細に定義することが可能である（例えば、回線３がデータ通信中に入った後の６３５４ＤＭＴスパーフレーム、又は、回線１のベクトル化係数の最終更新の後の７８７６４ＤＭＴスパーフレームに６７ＤＭＴフレームを加える）。

制御パラメータ（すなわち、書き込みのパラメータ）を含む場合、タイムスタンプは例えば、更新が初期化を実行するかどうかに関しての情報や、更新が実行及び／又は実装される時に関しての情報、既知の時間基準と更新の実行及び／又は実装との間の遅延に関しての情報などとすることができる。他の有用かつ実装可能なタイムスタンプは当業者に既知である。

多くの動作パラメータが割り当てれられ、同一のタイムスタンプを有する場合、上記の通り、動作パラメータのグループ化を用いることが可能である。例えば、多くの動作パラメータは、一緒にグループ化させることが可能であり、そして、そのグループに付加される単一のタイムスタンプを有することができる。他の場合には、タイムマーカーによってタイムスタンプのグループを定義及び識別することが可能である。そして、タイムスタンプをある動作パラメータに付加することは、定義されているタイムマーカーの一つを動作パラメータに関連付けすることによって達成させることができる。

当業者にとって明らかなように、本発明の実施例を用いたコンピュータプログラムプロダクトは、機械読み取り可能な媒体、そして、機械読み取り可能な媒体に含まれるプログラムの指示を含むことが可能である。プログラムの指示は、ベクトル化ＤＳＬシステムを動作させる方法をここに開示した一又は二以上の方法によって特定する。

ＴＲ−０６９において、ＤＳＬ物理層のパラメータのためのデータ収集は、全てのＣＰＥのための方法とまさに同じように実行される。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLInterfaceConfig.
パラメータは、現在の値を維持しなければならない（例えば、DownstreamNoiseMargin）。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLDiagnostics.
パラメータは、最終診断セッションからの値を維持しなければならない（例えば、SNRpsds）。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLInterfaceConfig.Stats.Total.
パラメータは、すべての統計値を維持しなければならない（例えば、データ収集開始からのFECErrors）。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLInterfaceConfig.Stats.Showtime.
パラメータは、直近のデータ通信中に積み重ねた統計値を維持しなければならない。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLInterfaceConfig.Stats.LastShowtime.パラメータは、直近２番目のデータ通信中に積み重ねた統計値を維持しなければならない。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLInterfaceConfig.Stats.CurrentDay.
パラメータは、１日の間に積み重ねた統計値を維持しなければならない。
−InternetGatewayDevice.WANDevice.{i}.WAN-DSLInterfaceConfig.Stats.QuarterHour. パラメータは、進行中の１５分間の間に積み重ねた統計値を維持しなければならない。
また、データ収集の開始時から、そして、直近のデータ通信の開始からなどの秒数を示すパラメータも存在する。

このアプローチは、各回線毎に独立してデータ収集を調整する機能を欠いている。例えば、問題のある回線又は他の理由のある回線に関して、より頻繁に安定した回線と比較してデータを収集することが望ましい。ベクトル化回線はまた、更新が必要か否かを決定するよう、又は、モデムのスイッチがオンもしくはオフとなる時などの状況を検出するよう、より厳密な監視を必要とすることが可能である。追加のデータは、問題の診断や解決法の提案を行うよう用いることができる。一方、全ての回線がきわめて頻繁にデータを収集することを要求することは通常、実用的では無い。なぜならば、それは、非常に高容量なメモリの必要性や非常に大きい通信帯域幅の必要性をもたらすこととなり、それらの必要性は、関連する全ての回線に関して妥当性を欠いたものとなるからである。

Ｇ．９９７．１において、ＭＩＢ要素が存在する。
−回線性能監視パラメータ（例えば、Errored Seconds（エラーが生じた秒数））
−チャネル性能監視パラメータ（例えば、FEC corrections（ＦＥＣ訂正））
−ＡＴＭデータ経路性能監視パラメータ（例えば、HEC violations（ＨＥＣ違反））
これら要素に関して、カウンターは、１５分間及び２４時間の一定間隔にわたって定義される。エラーが生じた秒数に関して、ひどくエラーが生じた秒数や、利用不可であった秒数のカウンターはまた、１５分間の過去１６インターバルについて記憶される（Ｇ．９９７．１のセクション７．２．７．９参照）

（１）回線検査、診断パラメータ、及び、ステータスパラメータ（例えば、SNR margin downstream（ＳＮＲマージンダウンストリーム））、そして、（２）チャネル検査、診断パラメータ、及び、ステータスパラメータ（例えば、actual interleaving delay（現実のインタリーブ遅延））のためのＭＩＢ要素が存在する。これら要素は、「現在」の値のみ記憶する。用語「現在」は、以前のシステム及びそれと同等なものに適用される。

最後に、監視パラメータのための閾値を記憶するＭＩＢ要素が存在する。閾値（１５分間及び２４時間の一定間隔にわたって定義される）を越えた場合、「threshold report（閾値レポート）」がＱインターフェースを介して生成され報告される。

ＴＲ−０６９と同様にＧ．９９７．１におけるＭＩＢ要素の定義は、各回線毎のカスタマイズデータ収集を認めない。従って、それらガイドラインの基では、問題を有する回線に対して、より詳細な情報を収集するために、より高速な転送速度（又は所定の時間間隔でより多くのデータポイントを収集すること）で特定のパラメータを収集することは不可能である。

本発明の実施例は、カスタマイズデータ収集及び／又は適応するデータ収集を可能にし、各ＣＰＥデバイスや、ＤＳＬＡＭデバイス、ＤＳＬデバイス毎それぞれにデータ収集手順を定義する。各パラメータ毎に、そして、時間内の異なる瞬間に対応する各パラメータ毎に複数の値が記憶される。パラメータ値を記憶する時間は、各ＤＳＬデバイス毎それぞれにプログラムすることが可能である。

例は、本発明の一実施例の利益及び実装を説明する。ＣＰＥ「Ａ」が安定した回線であることを仮定すると、その安定した回線は、時おりの監視のみを必要とする。パラメータ（SNR marginのような）は、まれに、又は、「通常」の基準（例えば毎時）で収集させることが可能であり、以下に示す表の通り、回線が安定状態を維持していることを単純に確かめる。
表１ ＣＰＥ Ａ（安定した回線）

安定した回線のための適応するデータ収集の例
しかしながら、ＣＰＥ「Ｂ」が問題を有する回線である場合、直近の監視を、不安定性の原因を判断するよう用いることが可能である。問題が生じる時間をより正確に示すために、以下に示す表の通り、ＳＮＲマージンのようなパラメータをより頻繁（例えば、毎１５分ごとに）に収集することが望ましい。
表２ ＣＰＥ Ｂ（問題を有する回線）

問題を有する回線のための適応するデータ収集の例

一般的に、本発明によるカスタマイズデータ収集は、各パラメータ（又はパラメータのグループ）を、以下の一又は二以上の変数に関連させることを要求してもよい。
−データ収集開始時間
−データ収集期間
−データ収集終了時間、又は、データ収集ポイントの総計
第１変数及び第３変数は、ある実施例において省略することが可能である。

本発明によるカスタマイズデータ収集は、当業者にとって明らかなようにＴＲ−０６９又は、Ｇ．９９７．１に組み込むことが可能である。ＴＲ−０６９に関して、以下のステップは、ＴＲ−０６９の動作を拡張させるよう用いることが可能である。
−カスタマイズデータ収集を明確にするための新しいＣＰＥパラメータ（又はＭＩＢ要素）の生成
−ベクトルタイプに対してのデータカスタマイズ収集機能を用いてＣＰＥパラメータ（又はＭＩＢ要素）を拡張する。データ収集がベクトルで満たされたときはすぐに、データ収集の停止か、古い値に新しい値の上書きのどちらかを行う。

最後に、「閾値レポート」は、ＴＲ−０６９を用いたデータ収集を拡張することができる。これを達成する一つの方法は、（ＴＲ−０６９のＡ．３．２．４による）ＳｅｔＰａｒａｍｅｔｅｒＡｔｔｒｉｂｕｔｅｓ（パラメータ属性の設定）の方法を変更することである。現在、ＳｅｔＰａｒａｍｅｔｅｒＡｔｔｒｉｂｕｔｅｓＳｔｒｕｃｔ（パラメータ属性構造体の設定）構造体におけるＮｏｔｉｆｉｃａｔｉｏｎ（通知）フィールドを設定することは、ＣＰＥが、値が変化するパラメータをＤＳＬ管理エンティティに通知することを可能にする。ＳｅｔＰａｒａｍｅｔｅｒＡｔｔｒｉｂｕｔｅｓ（パラメータ属性の設定）構造体に対するフィールドの追加を具備した結果、パラメータが所定の閾値を超えるようなイベントによって、その通知を始動させてもよい（例えば、ベクトル化ＤＳＬシステムにおいて、ある値がエラーメトリックを超えると、通知は、ベクトル化係数の更新が必要であることを示す働きをする）。他には、パラメータ値が閾値を下回った場合に、通知を送ってもよい。「トリガーフィールド」は以下の許容値を有する。
−トリガーイベントが値の任意の変化であることを示す特別な値
−トリガーを通知するための閾値の範囲

本発明の一又は二以上の実施例によるＤＳＬループにおける適応するデータ収集のための方法を図１１及び１２に示す。図１１の方法１１００は、１１１０でカスタマイズ収集のためのベクトル化ＤＳＬシステムの一又は二以上のデータパラメータの抽出から始まる。１１１０は、ＤＳＬループの性能を評価することを含むことが可能である。さらにＤＳＬループは、ＴＲ−０６９やＧ．９９７．１による通常のデータ収集動作のような第１のデータ収集手順を用いる。次に、ＤＳＬループの性能の評価に基づくＤＳＬループのための第２のデータ収集手順は、１１２０で特定されてよい（例えば、おおよそ頻繁にデータを収集する。又は、ループの性能を評価するために多少のデータポイントを収集する）。一度、１１２０で異なるデータ収集手順が決定及び／又は定義されると、属性は、１１３０でコントローラ（ＤＳＬ管理エンティティ）からＤＳＬデバイス（例えば、ＣＰＥモデム）へ送られてもよい。その後、ＤＳＬループの動作は、１１４０で、各データパラメータ毎の値／値のベクトルを、ＤＳＬデバイスからコントローラへ送ることによって、第２のデータ収集手順を用いるよう適応させてもよい。従って、その各データパラメータ毎の値／値のベクトルは、そのような方法の実行の間で調整されるデータ収集の頻度としてもよい。

図１２内の方法１２００に示すような、閾値レポートを用いた場合、ベクトル化ＤＳＬシステムのデータパラメータは、１２１０で抽出され、１２２０で一又は二以上の属性が割当てられる。さらに、属性は、１２３０でコントローラからＤＳＬデバイスへ送られる。その後、閾値の条件を満たした場合、データパラメータの値は、１２４０でＤＳＬデバイスからコントローラへ逆送される。

当業者にとって明らかなように、そのような方法は、ＤＳＬ結合部の全てのループや、ベクトル化ＤＳＬ回線のグループ、又は、他の任意の適切なグループに適用することが可能である。その結果、データ収集は、ループごとの基準によって適切なものとすることが可能である。そのような方法は、コンピュータプログラムプロダクト（例えば、ソフトウエア）又はある種類のコントローラによって実行されてもよい。そのコントローラは、例えば、ＤＳＬオプティマイザや、ＳＭＣ、それらと同等なものなどである。さらに、これら方法は拡張することが可能であり、そして、一又は二以上の動作パラメータは、必要に応じて検討され評価されてもよい。そのような各動作パラメータに関して、データ収集開始時間、データ収集期間、データ収集終了時間を指定してもよい。ある場合には、上述の通り、各動作パラメータのためのデータ収集期間のみを指定してもよい。そのような方法が用いられているループはまた、コントローラ又はそれと同等なものに通知するようプログラム及び／又は他の方法で構成させることが可能である。その通知は、動作パラメータの閾値又は範囲が達成された場合又は維持できなくなった場合すぐに、又は、動作パラメータの値が、特定の範囲外又は特定の範囲に減少した場合に行われる。その値や範囲は、動作パラメータの値における最大値や、最小値、十分な変化などである。上記の通り、これら一又は二以上の方法は、当業者にとって明らかなように、ＴＲ−０６９及び／又はＧ．９９７．１の拡張として実装することが可能である。

ＴＲ−０６９において、ＤＳＬ物理層のパラメータは、以下のブランチの基で定義される。
−ＩｎｔｅｒｎｅｔＧａｔｅｗａｙＤｅｖｉｃｅ．ＷＡＮＤｅｖｉｃｅ．{ｉ}．ＷＡＮ−ＤＳＬＩｎｔｅｒｆａｃｅＣｏｎｆｉｇ．
−ＩｎｔｅｒｎｅｔＧａｔｅｗａｙＤｅｖｉｃｅ．ＷＡＮＤｅｖｉｃｅ．{ｉ}．ＷＡＮ−ＤＳＬＤｉａｇｎｏｓｔｉｃｓ．
これらパラメータは、ＤＳＬ診断をトリガーするのに用いる
ＩｎｔｅｒｎｅｔＧａｔｅｗａｙＤｅｖｉｃｅ．ＷＡＮＤｅｖｉｃｅ．{ｉ}．ＷＡＮ−ＤＳＬＤｉａｇｎｏｓｔｉｃｓ．ＬｏｏｐＤｉａｇｎｏｓｔｉｃｓＳｔａｔｅ
を除いて、ＤＳＬ管理エンティティによって書き込まれることは無い。

ＴＲ−０６９のこの制限は、以下のことを意味する。ＣＰＥのＤＳＬ物理層を構成するための経路のみが、Ｇ．９９７．１によって提供される手段によるものであること、そして、その経路が、初期化中のＤＳＬＡＭとＣＰＥとの間で実行されるメッセージ交換によるものであること。しかしながら、以前の解決法は、以下の様々な事情において問題を有する。
ＤＳＬＡＭ制御の故障−ある状況において、実装の問題に起因してＤＳＬ管理エンティティからＣＰＥパラメータを制御することは不可能である。通信経路が遮断しているいくつかのポイントが存在する。適切に動作する経路に関して、多くの要素が、適切に機能する必要がある。それは以下の通りである。Ｑインターフェースは、必要な制御を備えていなければならない。管理部分のＤＳＬＡＭの実装は、全部揃っていなければならない。そして、ＤＳＬＡＭとＣＰＥとの間の経路上を通るメッセージは正確に実装されていなければならない。さらに、管理部分のＣＰＥの実装は、全部揃っていなければならない。
Ｇ．９９７．１のＣＰＥの構成パラメータにおける制限されているセット−Ｇ．９９７．１において現在プログラム可能として定義されていないＣＰＥパラメータの中の多くをプログラム可能にすることは有利な点である。例えば、特定のトーン上でロードすることができる最大ビット数をプログラムすることが可能であることは有用である。
ベクトル化ＤＳＬのための構成パラメータ−ＤＳＬＡＭの外部で制御することが可能なベクトル化動作に関連するパラメータを有することは有利な点である。これは、ＤＳＬＡＭの管理負荷を軽減し、複雑性を外部の管理システムに移転する。
ＣＰＥで利用するには遅すぎるパラメータの値−あるパラメータは、初期化（例えば、最大ＳＮＲマージン）の様々な段階でＤＳＬＡＭからＣＰＥへ伝達される。しかしながら、ＣＰＥは、回線を最適化するために、より早い時期にこれらパラメータの値を知る必要がある可能性がある。例えば、最大ＳＮＲマージンの場合、ＣＰＥは、適切な送信パワースペクトル密度（Power Spectral Density、PSD）レベルを初期段階で決定しなければならない。

ＣＰＥのＤＳＬ構成制御に関連する、Ｇ．９９７．１の制限は、上記で述べた通りである。加えて、Ｇ．９９７．１のＭＩＢ要素は、ＤＳＬ管理に役立つ多くの構成パラメータを特にベクトル化ＤＳＬに関して省略している。追加の便利な要素は以下で説明する。

ＣＰＥにおけるＤＳＬの構成制御を向上させる本発明の実施例を用いると、特定のＣＰＥパラメータは、ＤＳＬ管理エンティティのようなコントローラによってプログラム可能なように構成することができる。この場合、コントローラ（ＤＳＬ管理エンティティ）によって直接プログラムされている値とＤＳＬＡＭによって指示されている値との間で起こり得る衝突について、問題が生じる可能性がある。そのような衝突を解決する以下のような様々な方法が存在する。
−ＣＰＥパラメータは、衝突が合った場合、ＤＳＬＡＭの値又はＤＳＬ管理エンティティの値のどちらが優先度が高いか示すよう定義されていてもよい。
−ＤＳＬ管理エンティティによって指示されている一又は二以上の値が、障害のある回線をもたらす場合、又は、ある異常な状況をもたらす場合、ＣＰＥパラメータは、リセットされることを可能とする、及び／又は、ＤＳＬＡＭを用いて再初期化される回線の優先される値とすることができる。そして、回線が再設定された後、ＣＰＥは、異常な状況をＤＳＬ管理エンティティへレポートすることができる。

本発明の実施例に関連するＤＳＬ構成のためのＣＯモデム又はＣＰＥモデムを用いて使用可能な制御パラメータのリストを以下の表３Ａに示す。本発明の実施例に関連するベクトル化ＤＳＬ構成のためのＣＯモデム又はＣＰＥモデムのどちらかを用いて使用可能な制御パラメータのリストを以下の表３Ｂに示す。図３Ｂにおいて、オーダースワップ(order swap)は含まれる。なぜならば、ユーザの優先度は変化する可能性があり、そして、オーダーの取消しの範囲内でそれの位置は変化（恐らく、転送速度の変化にしたがって）する可能性があるからである。キャンセラは、オーダー内における直前の一般的なユーザと同じ状態にある。従って、オーダースワッピングは、全てのキャンセラ、スペクトル分散、そして、ビット分散を設定することなく様々なデータの要求に対して迅速に調整することができる。

表３Ｂにおいて、ファントムシステムの使用可能性のための制御パラメータが含まれる。ファントムモードのＤＳＬ動作が、前述の米国特許出願番号１１／２６７，６２３で説明されている。従って、ＳＭＣは、ファントムモードが有効な場合の制御を有することが望ましい可能性がある。ＳＭＣは、ファントムモード機能により、そのような制御パラメータをベクトル化ＤＳＬデバイスに本発明の実施例を用いて提供することができる。

「送信機のベクトル化−フィードフォーワードモジュール」及び／又は「送信機のベクトル化−フィードフォーワードモジュール」のための制御は、前述の米国特許出願番号１１／２８４，６９２で説明されているトーナルローターのような低減された複雑性の構造体のための適切なパラメータを含むことができる。ＳＭＣは、トーナルローターを算出することができ、そのような制御パラメータを本発明の実施例を用いてベクトル化ＤＳＬデバイスへ提供することが可能である。

「送信機のベクトル化−フィードバックモジュール」のための制御は、前述の米国特許出願番号１１／３３６，６６６で説明されているような構造体を事前にコーディングするために適切なパラメータを含むことができる。ＳＭＣは、構造体を事前にコーディングするためにパラメータを算出することができ、そのような制御パラメータを本発明の実施例を用いてベクトル化ＤＳＬデバイスへ提供することが可能である。

「受信機のベクトル化−フィードバックモジュール」のための制御は、前述の米国特許出願番号１１／３３６，１１３で説明されているようなＧＤＦＥ構造体のために適切なパラメータを含むことができる。ＳＭＣは、ＧＤＦＥ構造体のためにパラメータを算出することができ、そのような制御パラメータを本発明の実施例を用いてベクトル化ＤＳＬデバイスへ提供することが可能である。

表３Ａにおける制御は、ベクトル化回線における新しい回線の途切れのない準備や、導入を可能にする。それらはまた、ベクトル化ＤＳＬシステムにおける回線の規則正しい停止を可能にする。そのような方法は、前述の米国特許出願番号１１／３４５，２１５で説明されている。

従って、図１３に示すような本発明の実施例を用いると、ベクトル化ＤＳＬシステムを動作させるための方法１３００は、１３１０で少なくとも一つのモデムデバイス（例えば、ＣＰＥデバイス又はＣＯデバイス）を提供することを伴って開始することが可能である。そのモデムデバイスは、ＤＳＬシステム（又は、実験ＤＳＬシステム又は現場ＤＳＬシステムとすることが可能なＤＳＬシステム内の少なくとも一又は二以上のＤＳＬデバイス）を制御及び／又は動作させるために制御パラメータをＴＣＰ／ＩＰベースのプロトコルを介して受けとる。少なくとも一つの動作パラメータ（例えば、表３Ａ又は表３Ｂによる一又は二以上のパラメータ）は、ＤＳＬデバイスのための書き込み可能な制御パラメータとして１３２０で提供されてもよい。そして、１３３０で書き込み可能な制御パラメータに対して値が書き込まれることを可能にし、書き込まれた制御パラメータの値を生成する。その後１３４０で、ＤＳＬデバイスは、書き込まれた制御パラメータの値を用いて動作することが可能となる。ここに開示した他の技術と同様に、ＤＳＬデバイスは、任意の適切なデバイスとすることが可能である。その任意の適切なデバイスは、（これらに限定しないが）ＣＰＥモデム、ＤＳＬＡＭ、リモートターミナル、回線ターミナル、自動構成サーバ、要素管理システム、システム内で使用可能な他のＤＳＬモデムのタイプを含む。

上記の通り、衝突が生じる可能性がある。本発明の実施例は、書き込まれた制御パラメータの値と矛盾するパラメータの値との間の衝突を任意かつ適切な優先順位付けスキームを用いることによって解消することができる。そのスキームは、書き込まれた制御パラメータの値を優先する、矛盾するパラメータの値を優先する、又は、ＤＳＬデバイスが動作しているＤＳＬループの再初期化などである。ＤＳＬループを再初期化する場合、ＤＳＬループの再初期化は、書き込み可能な制御パラメータをデフォルトパラメータの値にリセットすることを含むことができる。ＤＳＬループの再初期化はまた、任意のパラメータの衝突をコントローラへレポートすることを含むことが可能である。ある事例において、デフォルトパラメータの値は、矛盾するパラメータの値であってもよい。

ベクトル化ＤＳＬのための制御パラメータは、現在定義されているインターフェースに含まれていない。これら制御パラメータは、ＣＯモデム（又はオプティカルネットワークユニット（ＯＮＵ）又はリモートターミナル（ＲＴ））かＣＰＥモデムのどちらかで適用されることを可能とする。それら制御パラメータは、帯域内プロトコル（例えば、ＡＤＳＬ／ＶＤＳＬの内部オペレーションチャネル（ＥＯＣ））か帯域外プロトコル（例えば、ＴＣＰ／ＩＰ）のどちらかを用いてＣＰＥ側に適用されることが可能である。それらプロトコルは、ネットワークスタックのより高い層で動作する。

本発明のこれら実施例は、様々なパラメータに適用することがＧ．９９７．１及び／又はＴＲ−０６９の基で可能である。そのようなものとして、これら方法はまた、ＤＳＬ管理エンティティとＤＳＬデバイスとの間のインターフェースの少なくとも一部として実装させてもよい。当業者によって、本発明による一又は二以上の方法を実装する様々なコンピュータプログラムプロダクトを理解することが可能である。

ＴＲ−０６９で定義されているＣＰＥパラメータ及びＧ．９９７．１のＭＩＢ要素は、本発明の一又は二以上の実施例によるベクトル化システムのＤＳＬ管理に有益であるデータパラメータを含まない。本発明の実施例に関連するＤＳＬ構成のためのＣＰＥモデム又は上流のデバイス（例えばＤＳＬＡＭ）の使用に適したデータパラメータのリストを以下の表４に示す。ベクトル化ＤＳＬ（ＣＰＥモデム又はＣＰＥモデムのどちらか）に使用可能なデータパラメータのリストを以下の表５に示す。

従って、図１４に示した本発明の実施例を用いると、ＤＳＬシステムを動作させるための方法１４００は、少なくとも一つのＣＰＥモデム又は上流のＤＳＬデバイス（例えば、ＤＳＬＡＭ）を１４１０で提供することで開始する。そのＣＰＥモデム又は上流のＤＳＬデバイスは、（現場又は実験の）ベクトル化ＤＳＬシステムのステータス、動作、又は、性能を評価するために、一又は二以上のデータパラメータを算出する。少なくとも一つの動作パラメータ（例えば、表４又は表５による一又は二以上のパラメータ）は、ＤＳＬデバイスのための読み取り可能なデータパラメータとして１４２０で提供されることを可能とし、１４３０で、ある値が読み取り可能なデータパラメータに割当てられることを可能にし、割当てられたデータパラメータの値を生成する。その後、ＤＳＬデバイスは、割当てられたデータパラメータの値を用いて１４４０で動作させることができる。ここに開示した他の技術と同様、当業者にとって理解されるように、ＤＳＬデバイスは、任意かつ適切なデバイスとすることができる。ある場合において、そのデバイス（これらに限定しないが）は、ＣＰＥモデム、ＤＳＬＡＭ、リモートターミナル、回線ターミナル、自動構成サーバ、要素管理システム、又は、システムで使用可能なＤＳＬモデムの任意のタイプを含む。

一般に、ＳＭＣは、選択の決定に関与させることができる。その選択の決定によって、回線のベクトル化及びトーンのベクトル化は適用されるべきであって、その選択の決定はベクトル化技術に適用すべきであるものである。ＳＭＣは、適切な指示をベクトル化エンジンや、ＤＳＬＡＭ、ＤＳＬ集積回路、スイッチに送ることができる。そのような決定は、ループ及び配備されているサービスについての情報、そして、機器の機能及び制限についての情報を得た後に行われる。そのような情報は、ベクトル化エンジンや、ＤＳＬＡＭ、ＤＳＬ集積回路から受ける。ＤＳＬＡＭと比較してＳＭＣは、これらの決定をすることにおいて有利な点を有する。なぜならば、それは、追加の情報へアクセスできるからである。

上記機能に関連するデータパラメータは表３Ｂにリストされている全てを含む。上記機能に関連する制御パラメータは、使用可能なベクトル化システムや、使用可能なベクトル化機能、使用可能なファントムシステムのカテゴリの基で表５にリストされている全てを含む。

これらパラメータは、現在定義されているＧ．９９７．１及びＴＲ−０６９のインターフェースの拡張としてサポートされることが可能である。これらパラメータに起因する追加の帯域幅及びメモリの要求は、かなり控えめである。最後に、これらパラメータの読み取りや、書き込みのための許容し得る待ち時間は、数秒のオーダーである。そのことは、本発明の実施例にとって十分である。

以下でより詳細に説明する通り、本発明の一又は二以上の実施例を実装する制御ユニットは、あるコントローラの一部（例えば、ＤＳＬオプティマイザや、動的スペクトルマネージャ又はＤＳＭＣ、スペクトル管理センター、ＤＳＬ管理エンティティを備えるもの又はその一部である任意のもの）とすることが可能である。コントローラ及び／又は制御ユニットは、どこにでも配置することが可能である。ある実施例において、コントローラ及び／又は制御ユニットは、ＤＳＬ局に備わっている。一方、他の場合において、それらは、その局の外部にあるサードパーティによって動作させることも可能である。本発明の実施例に関連して使用可能なコントローラ及び／又は制御ユニットの構造体や、プログラム、具体的な他の特徴などは、当業者にとって本開示を検討した後、明らかとなるであろう。

ＤＳＬ管理エンティティ、ＤＳＬオプティマイザ、動的スペクトル管理センター（ＤＳＭセンター）、スペクトル管理センター（ＳＭＣ）、「スマート」モデム、及び／又はコンピュータシステムなどのようなコントローラは、本発明の様々な実施例に関連して説明されているような動作データ及び／又は動作パラメータの値を収集し分析するよう用いることが可能である。コントローラ及び／又は他のコンポーネントは、コンピュータに組み込まれているデバイス、又は、デバイスの組み合わせでも良い。ある実施例において、コントローラは、モデムから離れた場所に存在する。他の場合には、コントローラは、モデム、ＤＳＬＡＭ、又は、他の通信システムデバイスに直接接続される機器のようなモデムの一つ又は両方のモデムと一緒に用いることも可能である。よって、「スマート」モデムが形成される。「連結する」、「結合する」、「接続する」などのような語句は、ここでは２つの要素及び／又は２つのコンポーネント間の接続を説明するよう用いられ、そして、同時に直接又は間接的に接続されていることの一方を意味することを目的とする。例えば、必要に応じて、一又は二以上の介在要素を介して、又は、無線接続を介してなどである。

本発明の実施例の一部は、典型的な通信システムとしてＤＳＬシステムを用いる。これらＤＳＬシステム内において、所定の慣習、ルール、プロトコルなどは、典型的なＤＳＬシステムの動作や、カスタマ（またユーザとも呼ばれる）及び／又はシステム上の機器によって利用可能な情報及び／又はデータなどを説明するのに用いることが可能である。しかしながら、当業者にとって明らかな通り、本発明の実施例は、様々な通信システムに適用させることが可能である。そして、本発明は特定のシステムに限定されない。本発明は、サービス品質を制御パラメータに関連させることが可能な任意のデータ送信システム内で用いることが可能である。

様々なネットワーク管理要素は、ＤＳＬ物理層のリソースの管理のために用いられる。その場合、要素は、ＤＳＬモデムのペア（共同または個別のどちらか一方）内でパラメータ又は機能に関連する。ネットワーク管理フレームワークは、管理されている一又は二以上のノードからなる。それらノードは、それぞれエージェントを備える。管理されているノードは、ルータや、ブリッジ、スイッチ、ＤＳＬモデム、他のデバイスなどとすることが可能である。しばしば、マネージャと呼ばれる少なくとも一つのＮＭＳ（ネットワーク管理システム）は、管理されているノードを監視し制御する。そして、通例そのＮＭＳは、通常のＰＣ又は他のコンピュータに基づいている。ネットワーク管理プロトコルは、管理情報やデータを交換するマネージャ又はエージェントによって用いられる。管理情報のユニットは、オブジェクトである。関連するオブジェクトの収集は、管理情報ベース（ＭＩＢ）として定義される。

本発明の実施例は、上述した通り「現場」ＤＳＬシステムで用いることが可能である。さらに、本発明の実施例は、「実験」ＤＳＬシステムで用いてもよい。図９は、ある実験構成９１０を図示する。自動化テストデバイス９１２は、ループ／ノイズ実験シミュレータ９１４に接続されている。そのような実験シミュレータは、技術的に既知である。各種機能は、実際のＤＳＬループ、そして、ＤＳＬ結合部などのようなループのグループを置き換えるために用いることが可能である。実験シミュレータは、通信環境の動作をシミュレーションするハードウエア機器及び／又はソフトウエア機器である。テスト機器９１２は、実験システム９１０の他のモジュールを制御するハードウエア及び／又はソフトウエアとすることが可能であり、これら他のデバイスから測定データを収集することもできる。デバイス９１２はまた、図９に示す通り、少なくとも一つのＣＰＥモデム９１６及びベクトル化ＤＳＬＡＭ９１８に接続されている。これらデバイス９１６、９１８のそれぞれは、ループ／ノイズ実験シミュレータに接続されており、特定のＤＳＬループを再生成する。最後に、パケットトラフィックテスター９２０は、デバイス９１２、９１６、９１８に接続されており、テスター９２０がこれら様々なデバイスからデータを収集することを可能にする。テスター９２０は、パケットトラフィックを生成しテストするハードウエア及び／又はソフトウエアである。これは、アップストリームトラフィック（ＣＰＥからＤＳＬＡＭへ）及びダウンストリーム（ＤＳＬＡＭからＣＰＥへ）の両方のために実行することが可能である。

当業者にとって明らかなように、構成９１０は、モジュール間の適切な接続を含むことが可能である。例えば、ＤＳＬＡＭ９１８と実験シミュレータ９１４との間の接続、そして、ＣＰＥモデム（又はモデム）９１６と実験シミュレータ９１４との間の接続は、ショートケーブル接続とすることが可能である。ＤＳＬＡＭ９１８とパケットトラフィックテスター９２０との間の接続、そして、ＣＰＥモデム（又はモデム）９１６とパケットトラフィックテスター９２０との間の接続は、標準的なインターフェース及び接続手段とすることが可能である。ＤＳＬＡＭ９１８と自動化テストデバイス９１２との間の接続は、本発明の実施例及び／又はＧ．９９７．１によって定義されているインターフェースや、動作パラメータなどを用いることが可能である。同様に、ＣＰＥモデム（又はモデム）９１６と自動化テストデバイス９１２との間の接続は、本発明の実施例及び／又はＴＲ−０６９によって定義されているインターフェースや、動作パラメータなどを用いることが可能である。最後に、実験シミュレータ９１４と自動化テストデバイス９１２との間の接続、そして、パケットトラフィックテスター９２０と自動化テストデバイス９１２との間の接続は、標準的なインターフェース及び通信手段とすることが可能である。

本発明の実施例は、ＤＳＬＡＭ及びＣＰＥ機器のテストを自動化するよう用いることができる。そのような技術は、ここに記載されている本発明の態様や、ＴＲ−０６９、Ｇ．９９７．１によって定義されているインターフェースの使用を構成させることが可能である。以下で説明する通り、本発明の使用は、実験システムの設定におけるそのようなテストにおいて特に有利な点が存在する。自動化ＤＳＬ機器テストのための一つの構成を図９に示す。多くのＤＳＬ機器テストは、以下のステップによって定義することが可能である。
（ａ）実験シミュレータを設定する
（ｂ）ＤＳＬＡＭ及びＣＰＥモデムを設定する
（ｃ）パケットトラフィックテスターを設定する（あるテストの時のみ必要である）
（ｄ）ＤＳＬＡＭ及びＣＰＥモデムからデータを収集する
ステップ（ｂ）及び（ｄ）は、同じテストの間、繰り返してもよい。これら方法の他のバリエーションは、当業者に明らかであろう。

図９の構成は、ＤＳＬ機器をテストするプロセスを自動化するよう用いることが可能である。自動化テストデバイス９１２は、各テストの間に実行するステップを制御し調整するよう用いる。当業者にとって明らかなように、「現場」システムの設定で用いる機器や技術を評価するために、そして、異なるタイプの機器の機能を確認するために様々なテストを実行することが可能である。特に各テストのために、自動化テストデバイスは以下を実行する。
−コマンドを実験シミュレータに送り、ループの状況及びノイズの状況を特定する。
−本発明の制御パラメータ、Ｇ．９９７．１、ＴＲ−０６９、及び／又は、ベクトル化ＤＳＬのために適切な他のインターフェースを使用し、テスト定義において特定されるようなＤＳＬＡＭ及びＣＰＥモデムを構成する。
−コマンドをパケットトラフィックテスターへ送り、トラフィック生成及びテストを開始する。
−本発明のデータパラメータ、Ｇ．９９７．１、ＴＲ−０６９、及び／又は、ベクトル化ＤＳＬのために適切な他のインターフェースを使用し、ＤＳＬＡＭ及びＣＰＥモデムから測定結果を収集する。
テストが終了した後、収集した測定結果を、予測値に対して比較することができ、合否結果を示す。他の場合、当業者にとって明らかなように、収集した測定結果を他の目的のために用いることが可能である。

本発明の実施例は、検証テストの他の方法と比較して多くの利点を有する。顕著な利益は、上述のアプローチで実現させることが可能である。そのアプローチは、本発明のインターフェース及び／又は動作パラメータ、Ｇ．９９７．１、ＴＲ−０６９、及び／又は、以下のためのベクトル化ＤＳＬに適切な他のインターフェースの使用によるものである。
−ＤＳＬＡＭ及びＣＰＥの制御パラメータを設定すること
−ＤＳＬＡＭ及びＣＰＥからデータパラメータを収集すること
上記目的のための本発明の使用は特に、様々な理由で有利な点が存在する。理由のいくつかを以下で概説する。

単一インターフェース
ＤＳＬＡＭ及びＣＰＥモデムの制御パラメータとデータパラメータへアクセスするための他のアプローチは、対応するＤＳＬＡＭ及びＣＰＥモデムの専用インターフェースを用いることである。異なるＤＳＬＡＭ及びＣＰＥモデムを用いた多くの専用インターフェースを有することと比較してベクトル化システムのための本発明のインターフェースを用いることは望ましいことである。

タイムスタンプ機能
標準化されたインターフェースの間で、Ｇ．９９７．１、ＴＲ−０６９のどちらも、上述のタイムスタンプ機能（例えば、データ収集の時間、制御パラメータの利用時間の特定など）を有さない。本発明は、この障害を克服し、検証テストを非常に容易にする。

カスタマイズデータ収集機能
Ｇ．９９７．１及びＴＲ−０６９と比較して、本発明は、カスタマイズデータ収集の追加の機能が利用可能である。これは、データ収集が各検証テストのニーズに適応するよう調整可能であること意味する。データパラメータは、まさに適切な頻度で収集されることが可能である。従って、一方では、過剰なデータ収集を回避し、他方では、非常に頻度の低いデータ収集を回避する。

データパラメータ及び制御パラメータの拡張セット
Ｇ．９９７．１及びＴＲ−０６９と比較して、本発明は、多くの追加のデータパラメータ及び制御パラメータを有する。これは、検証テストのためのＤＳＬＡＭ及びＣＰＥモデムを構成するよう自動化テストデバイスの機能を引き上げる。また、ＤＳＬＡＭ及びＣＰＥモデムから得ることが可能な測定結果のセットを拡張する。従って、さらに多くの検証テストの自動化を可能にする。

一般的に、本発明の実施例は、一又は二以上のコンピュータシステム内に記憶されている又は一又は二以上のコンピュータシステムを介して転送されるデータに伴う様々なプロセスを採用する。一又は二以上のそのコンピュータは、単一のコンピュータや、複数のコンピュータ、又は、コンピュータの組み合わせとしてもよい（ありとあらゆるコンピュータは、ここでは「コンピュータ」及び／又は「コンピュータシステム」として両方で呼ばれる）。本発明の実施例は、これらの動作を実行するためのハードウエアデバイス又は他の装置に関連する。この装置は特に、要求される目的のために構成されていてもよい。または、コンピュータに記憶されているコンピュータプログラム及び／又はデータ構造によって選択的に有効となる又は再構成される一般目的のコンピュータ及び／又はコンピュータシステムであってもよい。ここに提示されるプロセスは、特定のコンピュータ又は他の特定の装置に本質的に関連しない。特に、様々な一般目的の機械は、ここに示した教示によって書かれたプログラムを伴って用いることが可能である。また、必要な方法のステップを実行するよう、より特化した装置を構成することは、より利便性を向上させる。これら様々な機械のための特定の構成は、当業者であれば以下に示す説明に基づき明らかとなるであろう。

上記のような本発明の実施例は、コンピュータシステムに記憶されているデータを伴う様々なプロセスのステップを採用する。これらステップは、物理量の物理的処置を必要とする。必ずしも必要ではないが、通常、これら量は、記憶や、転送、結合、比較、他の操作を実行することが可能な電気信号又は磁気的信号の形態を取る。主に通常の利用の説明に関して、ビット、ビットストリーム、データ信号、制御信号、値、要素、変数、文字、データ構造体などのようなこれら信号に注目することは、時おり重宝される。しかしながら、これら用語及び同様な用語の全ては、適切な物理量に関連しており、これら量に適用されている単なる便利なラベルにすぎないということを念頭に置くべきである。

さらに、実行される操作はしばしば、識別、適合、比較などのような用語として言及される。本発明の一部を形成し、ここに開示されている任意の動作において、これら動作は、機械の動作である。本発明の実施例の動作を実行するための実用的な機械は、一般目的のデジタルコンピュータ又は他の同様なデバイスを含む。あらゆる場合において、コンピュータを動作させることにおける動作方法と、計算それ自体の方法の間での相違点を念頭において考慮されるべきである。本発明の実施例は、コンピュータを動作させるための方法のステップに関連する。その動作は、電気信号又は他の物理的な信号を処理し、その他の所望の物理信号を生成することである。

本発明の実施例はまた、これら動作を実行するための装置に関連する。この装置は、要求される目的のために特に構成されていてもよい。また、この装置は、コンピュータに記憶されているコンピュータプログラムによって選択的に有効となる又は再構成される一般目的のコンピュータであってもよい。ここに提示されているプロセスは、特定のコンピュータ又は特定の他の装置に本質的に関連しない。特に、様々な一般目的の機械は、ここに示した教示によって書かれたプログラムを伴って用いることが可能である。また、必要な方法のステップを実行するよう、より特化した装置を構成することは、より利便性を向上させる。これら様々な機械のための要求されている構成は、上記で記載されている説明によって明らかであろう。

加えて、本発明の実施例はさらに、コンピュータが読み取り可能な媒体に関連しており、その媒体は、コンピュータに実装された様々な動作を実行するためのプログラムの指示を含む。その媒体及びプログラムの指示は、本発明の目的のために特別に設計され構成されていてもよく、また、コンピュータソフトウエア技術における技術者にとって既知で利用可能なものであってもよい。コンピュータが読み取り可能な媒体の例は、これらに限定しないが、ハードディスクや、フレキシブルディスク、磁気テープのような磁気媒体や、ＣＤ−ＲＯＭディスクなどのような光学媒体、光学ディスクのような光磁気媒体、読み取り専用メモリデバイス（ＲＯＭ）及びランダムアクセスメモリ（ＲＡＭ）のようなプログラム指示を記憶し実行するよう特別に構成されたハードウエアデバイスを含む。プログラム指示の例は、コンパイラによって生成されるような、又は、インタープリタを用いてコンピュータによって実行することが可能なより高いレベルのコードからなるファイルのようなそれら両方の機械コードを含む。

図１７は、本発明の一又は二以上の実施例によるユーザ及び／又はコントローラによって用いることが可能な通常のコンピュータシステムを示す。コンピュータシステム１７００は、主要なストレージ１７０４（通常は、読み取り専用メモリ、ＲＯＭ）と主要なストレージ１７０６（通常はランダムアクセスメモリ、ＲＡＭ）を具備するストレージデバイスに接続されている多数のプロセッサ１７０２（また、中央処理ユニット、又はＣＰＵと呼ばれる）を備える。技術的に既知であるように、主要なストレージ１７０４は、ＣＰＵ及び主要なストレージ１７０６へデータ及び指示を一方向に転送するよう動作する。そのＣＰＵ及び主要なストレージ１７０６は通常、双方向の態様でデータ及び指示を転送するよう用いられる。これら主要なストレージデバイスはともに、上述の適切なコンピュータが読み取り可能な媒体を備えることが可能である。マスストレージデバイス１７０８はまた、ＣＰＵ１７０２へ双方向に接続され、追加のデータストレージ機能を提供し、そして、上述のコンピュータ読み取り可能な媒体を備えることが可能である。マスストレージデバイス１７０８は、プログラム、データ、それらと同等なものを記憶するよう用いることが可能であり、通常、主要なストレージより遅いハードディスクのような補助的なストレージ媒体である。当然のことながら、情報はマスストレージデバイス１７０８内に保持される。特有な場合において、そのマスストレージデバイスは、仮想メモリとして主要なストレージ１７０６の一部に標準的な方式で組み込みが可能である。ＣＤ−ＲＯＭ１７１４のような特定のマスストレージデバイスはまた、データをＣＰＵへ一方向で通すことが可能である。

ＣＰＵ１７０２はまた、インターフェース１７１０に接続される。そのインターフェース１７１０は、ビデオモニター、トラックボール、マウス、キーボード、マイク、タッチセンサー式ディスプレィ、トランスデゥーサカードリーダ、磁気テープリーダ、紙テープリーダ、タブレット、スタイラス、声認識デバイス、手書き認識デバイス、又は他の既知のインプットデバイス（当然ながら他のコンピュータも含む）のような一又は二以上のインプット／アウトプットデバイスを含む。最後に、ＣＰＵ１７０２は、コンピュータネットワーク又は電気通信ネットワークに１７１２に示したネットワーク接続を用いて追加で接続することが可能である。そのようなネットワーク接続を用いて、ＣＰＵが、上記の方法のステップを実行する経過の中でネットワークから情報を受け、ネットワークへ情報をアウトプットすることが考えられる。上記のデバイス及び器具は、コンピュータハードウエア及びソフトウエアの技術者に良く知られているであろう。上記のハードウエアの要素は、本発明の動作を実行するために複数のソフトウエアモジュールを定義することが可能である。例えば、コードワード構成コントローラを実行するための指示を、マスストレージデバイス１７０８又は１７１４に記憶することが可能であり、そして、主要なメモリ１７０６と連動してＣＰＵ１７０２で実行されてよい。望ましい実施例において、コントローラは、ソフトウエアサブモジュールに分類される。

本発明の多くの特徴及び有利な点が記載されている説明により明確となった。このように、添付の特許請求の範囲は、本発明のそのような特徴及び有利な点全てを保護するよう意図している。開示した実施例は、説明として取り上げるべきであって、限定のために取り上げるべきではない。そして、本発明は、ここに記載した詳細な説明に限定すべきではなく、添付の特許請求の範囲によって定義されるべきである。

ＩＴＵ−Ｔ Ｇ．９９７．１標準によるＤＳＬシステムのための参照モデル図を示す。 図１のＤＳＬベクトル化の場合における拡張事例の図を示す。 ＤＳＬフォーラムＴＲ−０６９の技術レポートによる配置図を示す。 図２のＤＳＬベクトル化の場合における拡張事例の図を示す。 基礎となる図１及び図１Ａの参照モデルを用いて拡張したＤＳＬシステム、ＤＳＬシステムに接続されているＤＳＬ管理ツール及びＤＳＬ管理エンティティを示す。 基礎となる図１及び図１Ａの参照モデルを用いて拡張したＤＳＬシステム、ＤＳＬシステムに接続されているＤＳＬ管理ツール及びＤＳＬ管理エンティティを示す。 基礎となるＤＳＬフォーラムＴＲ−０６９レポートによる配置図を用いて拡張したＤＳＬシステム、一又は二以上のＣＰＥ側のデバイスを示す。そのＣＰＥ側のデバイスはＬＡＮによってＣＰＥモデム又は他のＤＳＬデバイスに接続可能である。 基礎となるＤＳＬフォーラムＴＲ−０６９レポートによる配置図を用いて拡張したＤＳＬシステム、一又は二以上のＣＰＥ側のデバイスを示す。そのＣＰＥ側のデバイスはＬＡＮによってＣＰＥモデム又は他のＤＳＬデバイスに接続可能である。 ＤＳＬシステムのレイアウト及び動作を表す一般的概念図を示す。 本発明の実施例によるＤＳＬシステムに接続され通信するＤＳＬオプティマイザを示す。 本発明の実施例によるベクトル化ＤＳＬＡＭと関連して動作させるＤＳＬオプティマイザを示す。 ＤＳＬ管理エンティティとベクトル化ＤＳＬＡＭとの間の及び／又はＤＳＬ管理エンティティとＤＳＬ ＣＰＥモデムとの間のインターフェースに関連する本発明の実施例を示す。 本発明の実施例による分離したインターフェースを通じてＣＰＥモデム又はベクトル化ＤＳＬＡＭで利用可能なＤＳＬ管理エンティティ７４２を示す。 ＴＲ−０６９の「ＣＰＥパラメータ」及び／又はＧ．９９７．１の「ＭＩＢ要素」と関連するタイムスタンプを説明する。 ＤＳＬ管理インターフェースによって転送される単一パケットにおける同一のタイムスタンプに関連するデータパラメータ及び／又は制御パラメータを一緒にグルーピングすることを示す。 タイムマーカーに関連するタイムスタンプを示す。 本発明の実施例が利用可能なような実験ＤＳＬ構成を示す。 ＤＳＬシステムを動作させ、一又は二以上の動作パラメータに関連して用いられるタイムスタンプを実行する方法を示す。 本発明の一又は二以上の実施例によるＤＳＬループにおける適応するデータ収集のための方法を示す。 本発明の一又は二以上の実施例によるＤＳＬループにおける適応するデータ収集のための方法を示す。 本発明の実施例によるＤＳＬシステムを動作させるための方法を示す。 本発明の実施例によるＤＳＬシステムを動作させるための方法を示す。 本発明の実施例によるベクトル化エンジンに接続されたＤＳＬ管理エンティティ又はＤＳＬオプティマイザを示す。 本発明の実施例によって、チップセット内における計算上の要求を削減するために、受信機のチップセットの外部で実行されるベクトル化に関連するデータ通信中信号処理のための実装を示す。 本発明の一又は二以上の実施例によるユーザ及び／コントローラによって用いるためのコンピュータシステムを示す。

Claims (24)

1. 装置であって、
   少なくとも一つのベクトル化エンジンと、
   前記少なくとも一つのベクトル化エンジンに接続されており、個別のデジタル加入者線（ＤＳＬ）ループを通じて複数の加入者宅内機器（ＣＰＥ）デバイスのそれぞれに接続する相互接続と、
   サブセットの中にない前記加入者宅内機器（ＣＰＥ）デバイスに関連する個別のＤＳＬループよりも、ノイズ結合又は漏話結合のいずれかまたは両方が大きい個別のＤＳＬループを介して、前記相互接続に、前記少なくとも一つのベクトル化エンジンと、前記ＣＰＥデバイスのサブセットとを接続させるための指示を前記装置の外部にあるソースから受け、
   前記相互接続に接続される前記サブセットの中に前記ＣＰＥデバイスを含む当該サブセットを介して、前記相互接続に接続する前記個別のＤＳＬループにベクトル化を適用する前記少なくとも一つのベクトル化エンジンのための指示を受けるインターフェースと、
   を備え、前記指示によって、前記装置で、前記サブセットの遠端クロストークを低減させることを特徴とする装置。
2. 請求項１に記載の装置であって、前記装置がＤＳＬアクセスマルチプレクサであることを特徴とする装置。
3. 請求項１に記載の装置であって、複数のデジタル加入者線アクセスマルチプレクサ（ＤＳＬＡＭ）をさらに備え、各ＤＳＬＡＭが少なくとも一つのベクトル化エンジンを備えることを特徴とする装置。
4. 請求項１に記載の装置であって、前記装置の外部にある前記ソースはコントローラを備え、前記インターフェースは、さらに該コントローラと接続し、前記指示を受け、
   前記コントローラは、前記インターフェースを介して、前記ベクトル化エンジンと結合した前記サブセット中の各前記ＤＳＬループに関するサービスパラメータの品質を受信し、供給された前記サービスパラメータの品質に応答して、前記ベクトル化エンジンと結合した前記ＤＳＬループの前記サブセットを順序付ける命令を、前記インターフェースを介して送信することを特徴とする装置。
5. 請求項１に記載の装置であって、前記インターフェースは、前記個別のＤＳＬループそれらの間で漏話結合又はノイズ相関性が最大となる前記個別のＤＳＬループを通じて、前記少なくとも一つのベクトル化エンジンを前記ＣＰＥデバイスの重複しないサブセットに接続する前記相互接続のための指示を受けることを特徴とする装置。
6. 請求項１に記載の装置であって、前記インターフェースは、前記ＤＳＬループそれらの間で漏話結合又はノイズ相関性が最大となる前記ＤＳＬループにベクトル化を適用する前記少なくとも一つのベクトル化エンジンのための指示を受けることを特徴とする装置。
7. 請求項１に記載の装置であって、前記インターフェースはさらに、コントローラに動作データを提供し、提供された前記動作データに応じて該コントローラにより算出される制御パラメータを受けることを特徴とする装置。
8. ベクトル化エンジンと、該ベクトル化エンジンに、そして、複数の加入者宅内機器（ＣＰＥ）デバイスのそれぞれに個別のＤＳＬループを通じて接続されている相互接続と、インターフェースとを備える装置を管理するための方法が、
   サブセットの中にない前記加入者宅内機器（ＣＰＥ）デバイスに関連する個別のＤＳＬループよりも、ノイズ結合又は漏話結合のいずれかまたは両方が大きい個別のＤＳＬループを介して、前記相互接続に、前記少なくとも一つのベクトル化エンジンと、前記ＣＰＥデバイスのサブセットとを接続させるための指示を前記装置の外部にあるソースから前記インターフェースを介して受けることと、
   前記相互接続に接続される前記サブセットの中に前記ＣＰＥデバイスを含む当該サブセットを介して、前記個別のＤＳＬループにベクトル化を適用するように前記ベクトル化エンジンのための指示を受けることと、
   を含み、前記指示によって、前記装置で、前記サブセットの遠端クロストークを低減させることを特徴とする前記方法。
9. 請求項８に記載の方法であって、前記装置が二又は三以上のベクトル化エンジンを備え、前記ベクトル化エンジンを前記ＣＰＥデバイスのサブセットに前記個別のＤＳＬループを通じて接続する前記相互接続のための指示を前記インターフェースを介して受けることは、各ベクトル化エンジンを前記ＣＰＥデバイスの重複しないサブセットに前記個別のＤＳＬループを通じて接続する前記相互接続のための指示を受けることを含む方法。
10. 請求項８に記載の方法であって、前記装置が二又は三以上のベクトル化エンジンを備え、前記ＣＰＥデバイスの一つを前記相互接続に接続する前記ＤＳＬループにベクトル化を適用する前記ベクトル化エンジンのための指示を受けることは、前記ＣＰＥデバイスの一つを前記相互接続に接続する前記ＤＳＬループにベクトル化を適用する前記ベクトル化エンジンの一つのための指示を受けることを含む方法。
11. 請求項８に記載の方法であって、前記ベクトル化エンジンを前記ＣＰＥデバイスのサブセットに接続する前記相互接続のための指示を前記インターフェースを介して受けることは、前記個別のＤＳＬループそれらの間で漏話結合又はノイズ相関性の一方又は両方が最大となる前記個別のＤＳＬループを通じて前記ベクトル化エンジンをＣＰＥデバイスの前記サブセットに接続する前記相互接続のための指示を受けることを含む方法。
12. 請求項８に記載の方法であって、該方法が、
    新しいＤＳＬループを前記相互接続に接続することと、
    前記新しいＤＳＬループに関連する動作データを得ることと、
    前記動作データに応じて前記ベクトル化エンジンを前記ＣＰＥデバイスのサブセットに前記新しいＤＳＬループを通じて接続する前記相互接続のための指示を前記インターフェースを介して受けることと、
    をさらに含むことを特徴とする方法。
13. 請求項１２に記載の方法であって、前記動作データには、
    サービス品質のデータ、
    エラーカウンタ、
    現在の転送速度のデータ、
    現在のマージンのデータ、
    ステータスデータ、
    テストパラメータのデータ、
    診断データ、
    性能データ、
    到達可能な最大データ転送速度のデータ、
    Ｘｌｏｇデータ、
    ノイズ相関のデータ、
    の少なくとも一つが含まれることを特徴とする方法。
14. 請求項１３に記載の方法であって、前記サービス品質のデータには、
    カスタマのデータ転送速度、
    カスタマの遅延についてのデータ、
    カスタマの優先度のデータ、
    カスタマのサービスクラスのデータ、
    の少なくとも一つが含まれることを特徴とする方法。
15. 請求項８に記載の方法であって、前記装置は前記ＤＳＬループの一つにそれぞれ接続されている複数の受信機をさらに備えており、前記方法が、
    前記受信機の一つである第１の受信機において、該第１の受信機が接続されている前記ＤＳＬループから受けたノイズサンプルを検知することと、
    異なるＤＳＬループに接続されている前記受信機の一つである第２の受信機に、検知された前記ノイズサンプルを提供し、該第２の受信機が、前記異なるＤＳＬループから受信するデータ信号のデコーディングに検知された前記ノイズサンプルを適用することと、
    をさらに含むことを特徴とする方法。
16. 請求項１５に記載の方法であって、前記ノイズサンプルが検知されている前記ＤＳＬループに対応するエンコーディング動作を中断することをさらに含む方法。
17. 請求項１６に記載の方法であって、前記ベクトル化エンジンを前記ＣＰＥデバイスの異なるサブセットに前記個別のＤＳＬループを通じて接続する前記相互接続のための指示を前記インターフェースを介して受けることをさらに含むことを特徴とする方法。
18. 請求項１６に記載の方法であって、少なくとも一つの前記個別のＤＳＬループのための
    データ転送速度、
    マージン、
    スペクトル
    通信事業者のマスク、
    遅延、
    トレーニングシーケンス、
    インパルスノイズ保護、
    のパラメータのうち少なくとも一つを変更することをさらに含む方法。
19. 請求項８に記載の方法であって、
    前記ベクトル化エンジンに接続されている前記サブセットにおける前記ＤＳＬループそれぞれに関連するサービス品質のパラメータを、前記装置に関連するコントローラに前記インターフェースを通じて提供することと、
    提供された前記サービス品質のパラメータに応じて前記ベクトル化エンジンに接続されているＤＳＬループの前記サブセットを順序付けする指示を、前記インターフェースを通じて前記コントローラから受けることと、
    をさらに含むことを特徴とする方法。
20. 請求項１８に記載の方法であって、前記サービス品質のパラメータには、
    カスタマのデータ転送速度、
    カスタマの遅延についての要求、
    カスタマの優先度、
    カスタマのサービスクラス、
    の少なくとも一つが含まれることを特徴とする方法。
21. 請求項１８に記載の方法であって、前記順序付けの指示は、
    受信機のベクトル化動作のための順序付けの指示と、
    送信機のベクトル化動作のための順序付けの指示と、
    の少なくとも一つを含むことを特徴とする方法。
22. 請求項１８に記載の方法であって、前記コントローラによって算出されたデコーディング待ち時間が最大待ち時間を越えていない場合、デコーディングの順序を前記ＤＳＬループに適用する指示を、前記コントローラから前記ベクトル化エンジンへの前記インターフェースを介して受けることをさらに含む方法。
23. 請求項２２に記載の方法であって、前記デコーディングの順序の指示を受けることは、
    最大デコーディング遅延、
    最小インパルスノイズ保護、
    デコーディングの順序付け、
    ベクトル化を適用するためのトーン、
    ベクトル化を適用するための回線、
    通信事業者のマスク、
    スペクトルのマスク、
    データ転送速度、
    マージン、
    のパラメータの少なくとも一つを受けることを特徴とする方法。
24. 請求項８に記載の方法であって、前記装置はＤＳＬモデムをさらに備え、前記指示を受けることが、
    診断の初期化、
    前記ＤＳＬモデムの初期化、
    前記ＤＳＬモデムの動作、
    前記ＤＳＬループの少なくとも一つが初期化を行っていて、同時にその他の前記ＤＳＬループの少なくとも一つが動作中である時、
    の時間の一つの間で生じることを特徴とする方法。

Images