JP2008543244A - ユーザ嗜好ベースｄｓｌシステム - Google Patents

Abstract

ユーザ嗜好の、オペレータにより制御される実施が、実現可能な場合に提供される。ユーザ嗜好データがオペレータによって取得され、ＤＳＬシステムなどの通信システムの動作特性およびパラメータと比較されて、ユーザ嗜好のうちの１つ以上が通信システム内で実施されてもよいかどうかが判定される。ユーザ嗜好の実施がシステムの動作規則に違反する場合、または、実施がシステム動作に悪影響を及ぼす場合、嗜好は実施される必要はない。しかし、ユーザ嗜好が、問題を発生させることなく、システム内で実施されることが可能な場合、オペレータは、ユーザの所望を実現するために、ユーザ嗜好を実施してもよい（または、別のパーティに実施させてもよい）。ユーザ嗜好データは、（例えば、調査、およびその他の直接的なユーザフィードバックにより）ユーザから直接取得されてもよく、または、（例えば、ユーザ嗜好を示す隠れマルコフモデルを構築することにより）間接的に取得されてもよい。オペレータは、ユーザ嗜好データを、ユーザセット（例えば、１つのユーザ、または複数のユーザ）から収集してもよい。ユーザ嗜好データは、ユーザ嗜好データを実施するために実現可能な程度まで調整されてもよい、２つ以上のパフォーマンス測定基準と比較されてもよい。

Description

本発明は、一般に、ディジタル通信システムを管理するための方法、システム、および装置に関する。
（関連出願の相互参照）

本出願は、米国特許法第１１９条第（ｅ）項に基づいて、以下の優先権の利益を主張するものである。

２００５年６月１０日出願の「ＯＰＥＲＡＴＯＲ−ＣＯＮＴＲＯＬＬＥＤ ＵＳＥＲ−ＰＲＥＦＥＲＥＮＣＥ−ＢＡＳＥＤ ＸＤＳＬ ＳＹＳＴＥＭ」と題された米国仮特許出願第６０／６８９，４２１号（代理人整理番号０１０１−ｐ２６ｐ）の全開示内容は、あらゆる目的のために、その全体が、参照により本明細書に援用されるものとする。

２００５年７月１０日出願の「ＤＳＬ ＳＹＳＴＥＭ」と題された米国仮特許出願第６０／６９８，１１３号（代理人整理番号０１０１−ｐ２８ｐ）の全開示内容は、あらゆる目的のために、その全体が、参照により本明細書に援用されるものとする。

ディジタル加入者回線（ＤＳＬ）技術は、既存の電話加入者回線（ループおよび／または銅プラント（ｃｏｐｐｅｒ ｐｌａｎｔ）とも呼ばれる）上でのディジタル通信のために、潜在的に大きな帯域幅を提供する。特に、ＤＳＬシステムは、加入者回線の各端において、モデム（通常は、トランスミッタおよびレシーバの両方として機能するトランシーバ）のトレーニングおよび初期化の間に判定されたチャネル状態に合わせて調整可能な、複数のビットを各トーン（または、副搬送波）に割り当てる、ディスクリートマルチトーン（ＤＭＴ）回線コードを使用することによって、加入者回線の特性に合わせて調整することが可能である。

ＤＳＬシステムは、そのようなＤＳＬシステムのパフォーマンス側面の間での、一定のトレードオフを可能にする程度まで、設定可能である。したがって、ＤＳＬシステムの設定は、しばしば、カスタマによるＤＳＬサービスの使用における、カスタマの満足度に影響を及ぼす。ＤＳＬシステムは、カスタマ（ユーザ）にとって最も重要なパフォーマンス側面を取得、記録、評価、および／または実施すること、ならびに、そのような嗜好に対応するためにＤＳＬシステムがどのように設定されるべきかを決定することは、できなかった。

ＤＳＬシステムのユーザ嗜好を識別するための、そして、識別されたユーザ嗜好を満足するためにそのＤＳＬシステムを設定するための、改良を提供する、システム、装置、方法、および技術は、当技術分野における大幅な進歩を表す。さらに、そのようなユーザ嗜好評価およびＤＳＬシステム設定を実施するための、システム、装置、方法、および技術は、同様に、当技術分野における大幅な進歩を表す。

本発明の実施形態は、ユーザ嗜好の、オペレータにより制御される実施を、実現可能な場合に提供する。ＤＳＬシステムオペレータ（ｔｅｌｃｏ ＣＬＥＣまたはＩＬＥＣなど）は、システムの「動作領域（ｏｐｅｒａｔｉｏｎａｌ ｓｐａｃｅ）」を定義、制限、設定、および制御することが可能である。ここで、「動作領域」とは、そのようなシステムをユーザがどのように使用できるかを定義する、規則、許容される使用法、特性、動作パラメータ範囲などを含む。本発明を使用する場合、ユーザ嗜好データがオペレータによって取得され、ＤＳＬシステムなどの通信システムの、オペレータにより定義された動作領域と比較されて、ユーザ嗜好のうちの１つ以上がシステム内で実施されてもよいかどうかが判定される。ユーザ嗜好の実施がシステムの動作規則に違反する場合、または、実施がシステム動作に悪影響を及ぼす場合、嗜好は実施される必要はない。しかし、ユーザ嗜好が、問題を発生させることなく、システムの動作領域内で実施されることが可能な場合、オペレータは、ユーザの所望を実現するために、ユーザ嗜好を実施してもよい（または、別のパーティに実施させてもよい）。ユーザ嗜好データは、（例えば、調査、およびその他の直接的なユーザフィードバックにより）ユーザから直接取得されてもよく、または、（例えば、ユーザ嗜好を示す隠れマルコフモデルを構築することにより）間接的に取得されてもよい。オペレータは、ユーザ嗜好データを、ユーザセット（例えば、１つのユーザ、または複数のユーザ）から収集してもよい。ユーザ嗜好データは、ユーザ嗜好データを実施するために実現可能な程度まで調整されてもよい、２つ以上のパフォーマンス測定基準と比較されてもよい。

本発明のさらなる詳細および利点は、以下の詳細な説明および関連する図面において示される。

本発明は、以下の詳細な説明を、添付の図面と組み合わせることによって容易に理解されるであろう。図面において、同様の参照番号は、同様の構造要素を示す。

本発明の以下の詳細な説明では、本発明の１つ以上の実施形態に言及するが、本発明はそのような実施形態に限定されない。むしろ、詳細な説明は、あくまで例示のためのものである。図面に関連して本明細書に示す詳細な説明は、本発明がこれらの限定された実施形態を超えて拡張される際の、説明の目的のために提供されることを、当業者は容易に理解するであろう。

ＤＳＬオプティマイザ、動的スペクトル管理センタ（ＤＳＭセンタ）、「スマート」モデム、および／またはコンピュータシステムなどの、コントローラは、本発明のさまざまな実施形態に関連して説明する、動作データおよび／またはパフォーマンスパラメータ値を収集および解析するために使用されてもよい。コントローラおよび／またはその他の構成要素は、コンピュータによって実施される装置、または装置の組み合わせであってもよい。一部の実施形態では、コントローラは、通信回線に結合されたモデムまたはその他の通信装置から、遠く離れた場所にある。その他の場合、コントローラは、モデム、ＬＴ装置、ＤＳＬＡＭ、またはその他の通信システム装置に直接接続され、それにより「スマート」モデムを作成する装置などの、「ローカル」装置（すなわち、通信回線に直接結合された装置、またはそのようなローカル装置の一部）のうちの一方または両方と一緒に置かれてもよい。さらに、当業者によって理解されるように、コントローラは、本発明が有用となる、その他の任意のタイプのデータ転送システムに結合されてもよい。「結合され（ｃｏｕｐｌｅｄ ｔｏ）」および「接続され（ｃｏｎｎｅｃｔｅｄ ｔｏ）」などの語句は、本明細書では、２つの要素および／または構成要素の間の接続を記述するために使用され、直接結合されること、または、例えば、必要に応じて、１つまたは複数の介在する要素を経由して、または無線接続を経由して、間接的に結合されることを意味することが意図されている。その上、「通信システム（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｙｓｔｅｍ）」への言及も、適切な場合は、その他の任意のタイプのデータ転送システムへの言及を含むことが意図されている。

本発明の実施形態の、以下の例のいくつかは、例示的データ転送システムとしての、ＡＤＳＬおよび／またはＶＤＳＬシステムに関連して使用される。これらのＤＳＬシステム内では、例示的ＤＳＬシステムの動作、ならびに、システムに結合されたユーザおよび／または装置から入手可能な、情報および／またはデータを記述するための、特定の規約、規則、プロトコルなどが使用されてもよい。ただし、当業者によって理解されるように、本発明の実施形態はさまざまなタイプのデータ転送システムに適用されてもよく、したがって本発明はいかなる特定のシステムにも限定されない。

さまざまなネットワーク管理要素が、ＡＤＳＬおよびＶＤＳＬ物理層リソースの管理のために使用され、ここで、要素とは、ＡＤＳＬまたはＶＤＳＬモデムペアの全体内の、または個々の端における、パラメータまたは関数を意味する。ネットワーク管理フレームワークは、１つ以上の管理対象ノードからなり、各管理対象ノードはエージェントを含む。管理対象ノードは、ルータ、ブリッジ、スイッチ、モデム、またはその他であってもよい。少なくとも１つのＮＭＳ（ネットワーク管理システム）（しばしばマネージャとも呼ばれる）が、管理対象ノードを監視および制御し、ＮＭＳは、通常、一般的なＰＣまたはその他のコンピュータをベースにしている。ＮＭＳは、場合によっては、要素管理システム（ＥＭＳ）とも呼ばれる。ＮＭＳおよびＥＭＳシステムは、オペレーションサポートシステム（Ｏｐｅｒａｔｉｏｎｓ Ｓｕｐｐｏｒｔ Ｓｙｓｔｅｍｓ（ＯＳＳ））の部分であると見なされる。ネットワーク管理プロトコルが、マネージャおよびエージェントによって、管理情報およびデータの交換のために使用される。管理情報の単位は、オブジェクトである。関連するオブジェクトの集合は、管理情報ベース（ＭＩＢ）として定義される。

図１は、さまざまなＡＤＳＬおよびＶＤＳＬシステムに適用される、Ｇ．９９７．１標準（Ｇ．ｐｌｏａｍ）による参照モデルシステムを示す。それらのさまざまなＡＤＳＬおよびＶＤＳＬシステムは、当業者によく知られており、その中で本発明の実施形態が実施されてもよい。このモデルは、ＡＤＳＬ１（Ｇ．９９２．１）、ＡＤＳＬ−Ｌｉｔｅ（Ｇ．９９２．２）、ＡＤＳＬ２（Ｇ．９９２．３）、ＡＤＳＬ２−Ｌｉｔｅ（Ｇ．９９２．４）、ＡＤＳＬ２＋（Ｇ．９９２．５）、ＶＤＳＬ１（Ｇ．９９３．１）、およびその他の出現しつつあるＧ．９９３．ｘ ＶＤＳＬ標準、ならびに、Ｇ．９９１．１およびＧ．９９１．２ ＳＨＤＳＬ標準など（すべて、ボンディングあり、またはボンディングなし）の、スプリッタを含む、または含まない、さまざまな標準を満たしているＡＤＳＬおよびＶＤＳＬシステムに適用される。これらの標準、それに対する変形、およびＧ．９９７．１標準に関連したそれらの使用は、すべて、当業者によく知られている。

Ｇ．９９７．１標準は、Ｇ．９９７．１で定義されたクリア・エンベッディド・オペレーション・チャネル（ｃｌｅａｒ ｅｍｂｅｄｄｅｄ ｏｐｅｒａｔｉｏｎ ｃｈａｎｎｅｌ（ＥＯＣ））に基づく、ＡＤＳＬおよびＶＤＳＬ転送システムのための物理層管理と、Ｇ．９９ｘ標準で定義されたインジケータビットおよびＥＯＣメッセージの使用とを規定する。さらに、Ｇ．９９７．１は、構成、障害、およびパフォーマンス管理のための、ネットワーク管理要素の内容も規定する。これらの機能の実行において、システムは、アクセスノード（ＡＮ）において入手可能な、およびアクセスノード（ＡＮ）から収集可能な、さまざまな動作データを利用する。ＤＳＬ ＦｏｒｕｍのＴＲ６９レポートには、さらに、ＭＩＢと、それがどのようにアクセスされてもよいかが示されている。図１で、カスタマの端末装置１１０は、ホームネットワーク１１２に結合されており、ホームネットワーク１１２は、さらに、ネットワーク終端ユニット（ＮＴ）１２０に結合されている。ＡＤＳＬシステムの場合、ＮＴ １２０は、ＡＴＵ−Ｒ １２２（例えば、ＡＤＳＬおよび／またはＶＤＳＬ標準のうちのいずれかによって定義される、場合によってはトランシーバとも呼ばれる、モデム）、または、その他の任意の適切なネットワーク終端モデム、トランシーバ、またはその他の通信ユニットを含む。ＶＤＳＬシステム内のリモート装置は、ＶＴＵ−Ｒである。当業者によって理解されるように、そして、本明細書に記載するように、各モデムは、接続先の通信システムと相互作用を行い、また、通信システム内でのモデムのパフォーマンスの結果としての、動作データを生成してもよい。

ＮＴ １２０は、さらに、管理エンティティ（ＭＥ）１２４を含む。ＭＥ １２４は、任意の適用可能な標準および／またはその他の基準によって要求されるとおりに実行可能な、マイクロプロセッサ、マイクロコントローラ、または、ファームウェアまたはハードウェア内の回路状態機械などの、任意の適切なハードウェア装置であってもよい。ＭＥ １２４は、パフォーマンスデータを収集して、そのＭＩＢ内に記憶する。ＭＩＢは、各ＭＥによって維持される、情報のデータベースであり、また、ＭＩＢは、ネットワーク装置から情報を収集して管理者コンソール／プログラムに提供するために使用される管理プロトコルであるＳＮＭＰ（簡易ネットワーク管理プロトコル）などの、ネットワーク管理プロトコルを介してアクセスされてもよく、または、電気通信ネットワーク要素間での応答とコマンドとをプログラムするために使用される伝統的なコマンド言語である、ＴＬ１コマンドを介してアクセスされてもよい。

システム内の各ＡＴＵ−Ｒは、ＣＯ内またはその他のアップストリームかつ／または中央の位置内の、ＡＴＵ−Ｃに結合される。ＶＤＳＬシステムにおいては、システム内の各ＶＴＵ−Ｒは、ＣＯ内またはその他のアップストリームかつ／または中央の位置（例えば、ＯＮＵ／ＬＴ、ＤＳＬＡＭ、ＲＴなどの、任意の回線終端装置）内の、ＶＴＵ−Ｏに結合される。本発明においては、そのようなＶＴＵ−Ｏ（または均等物）は、終端装置上で終端する、すべてまたは多くの回線の、送信（ダウンストリーム）および受信（アップストリーム）に関して調整される。そのような調整された送信受信は、ベクトル化回線終端装置（ｖｅｃｔｏｒｅｄ ｌｉｎｅ−ｔｅｒｍｉｎａｔｉｏｎ ｄｅｖｉｃｅ）を構成する。図１では、ＡＴＵ−Ｃ １４２は、ＣＯ １４６内のアクセスノード（ＡＮ）１４０に位置している。当業者によって理解されるように、ＡＮ １４０は、ＤＳＬＡＭ、ＯＮＵ／ＬＴ、ＲＴなどの、ＤＳＬシステム構成要素であってもよい。ＭＥ １４４は、同様に、ＡＴＵ−Ｃ １４２に関するパフォーマンスデータのＭＩＢを維持する。当業者によって理解されるように、ＡＮ １４０は、ブロードバンドネットワーク１７０、またはその他のネットワークに結合されてもよい。ＡＴＵ−Ｒ １２２とＡＴＵ−Ｃ １４２とはループ１３０によって結合され、ループ１３０は、ＡＤＳＬ（およびＶＤＳＬ）の場合は、一般に、その他の通信サービスも搬送する電話ツイストペア線である。

図１に示すインタフェースのうちのいくつかは、動作および／またはパフォーマンスデータの決定と収集とのために使用されてもよい。図１内のインタフェースが、別のＡＤＳＬおよび／またはＶＤＳＬシステムインタフェース方式と違わない範囲内までは、システムは当業者によく知られており、また、差異は、当業者にとって既知であり明白である。Ｑインタフェース１５５は、オペレータのＮＭＳ １５０と、ＡＮ １４０内のＭＥ １４４との間のインタフェースを提供する。Ｇ．９９７．１標準で規定されたすべてのパラメータは、Ｑインタフェース１５５において適用される。ＭＥ １４４内でサポートされる近端パラメータは、ＡＴＵ−Ｃ １４２から得られ、一方、ＡＴＵ−Ｒ １２２からの遠端パラメータは、Ｕインタフェース上の２つのインタフェースのうちのいずれかによって得られてもよい。埋め込みチャネル１３２を使用して送信され、ＰＭＤ層において提供される、インジケータビットとＥＯＣメッセージとは、必要なＡＴＵ−Ｒ １２２パラメータをＭＥ １４４内で生成するために使用されてもよい。または、ＭＥ １４４によって要求された場合にＡＴＵ−Ｒ １２２からパラメータを取得するために、ＯＡＭ（オペレーション、アドミニストレーション、およびマネジメント）チャネルと、適切なプロトコルとが使用されてもよい。同様に、ＡＴＵ−Ｃ １４２からの遠端パラメータは、Ｕインタフェース上の２つのインタフェースのうちのいずれかによって得られてもよい。ＰＭＤ層において提供される、インジケータビットとＥＯＣメッセージとは、必要なＡＴＵ−Ｃ １４２パラメータをＮＴ １２０のＭＥ １２４内で生成するために使用されてもよい。または、ＭＥ １２４によって要求された場合にＡＴＵ−Ｃ １４２からパラメータを取得するために、ＯＡＭチャネルと、適切なプロトコルとが使用されてもよい。

（本質的にループ１３０である）Ｕインタフェースにおいては、２つの管理インタフェースが、１つはＡＴＵ−Ｃ １４２（Ｕ−Ｃインタフェース１５７）において、１つはＡＴＵ−Ｒ １２２（Ｕ−Ｒインタフェース１５８）において存在する。インタフェース １５７は、ＡＴＵ−Ｃ近端パラメータを、ＡＴＵ−Ｒ １２２がＵインタフェース１３０を越えて取得するために提供する。同様に、インタフェース１５８は、ＡＴＵ−Ｒ近端パラメータを、ＡＴＵ−Ｃ １４２がＵインタフェース１３０を越えて取得するために提供する。該当するパラメータは、使用されているトランシーバ標準（例えば、Ｇ．９９２．１またはＧ．９９２．２）に依存してもよい。

Ｇ．９９７．１標準は、Ｕインタフェースを横切る任意選択のＯＡＭ通信チャネルを規定する。このチャネルが実装されている場合、ＡＴＵ−ＣとＡＴＵ−Ｒとのペアは、物理層ＯＡＭメッセージを伝送するためにこのチャネルを使用してもよい。したがって、そのようなシステムのトランシーバ１２２、１４２は、それらのそれぞれのＭＩＢ内に維持されているさまざまな動作およびパフォーマンスデータを共有する。

ＡＤＳＬ ＮＭＳに関するさらなる情報は、「ＡＤＳＬ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ」と題されたＤＳＬ Ｆｏｒｕｍ Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ−００５（ＡＤＳＬ Ｆｏｒｕｍ、１９９８年３月）に見出すことができる。さらに、「ＣＰＥ ＷＡＮ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ」と題されたＤＳＬ Ｆｏｒｕｍ Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ−０６９（２００４年５月）にも見出すことができる。最後に、「ＬＡＮ−Ｓｉｄｅ ＤＳＬ ＣＰＥ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」と題されたＤＳＬ Ｆｏｒｕｍ Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ−０６４（２００４年５月）にも見出すことができる。これらの文献は、ＣＰＥ側管理のためのさまざまな状況を扱い、その中の情報は当業者によく知られている。ＶＤＳＬに関するさらなる情報は、ＩＴＵ標準Ｇ．９９３．１（「ＶＤＳＬ１」と呼ばれることもある）、および出現しつつあるＩＴＵ標準Ｇ．９９３．２（「ＶＤＳＬ２」と呼ばれることもある）、ならびに、進行中のいくつかのＤＳＬ Ｆｏｒｕｍ作業テキストに見出すことができ、これらはすべて当業者に知られている。例えば、追加情報は、「ＶＤＳＬ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ」と題されたＤＳＬ ＦｏｒｕｍのＴｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ−０５７（２００３年２月）（旧ＷＴ−０６８ｖ５）、および「ＦＳ−ＶＤＳＬ ＥＭＳ ｔｏ ＮＭＳ Ｉｎｔｅｒｆａｃｅ Ｆｕｎｃｔｉｏｎａｌ Ｒｅｑｕｉｒｅｍｅｎｔｓ」と題されたＴｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ−０６５（２００４年３月）、ならびに、ＶＤＳＬ１およびＶＤＳＬ２ ＭＩＢ要素のためのＩＴＵ標準Ｇ．９９７．１の出現しつつある改訂版、またはＡＴＩＳ Ｎｏｒｔｈ Ａｍｅｒｉｃａｎ Ｄｒａｆｔ Ｄｙｎａｍｉｃ Ｓｐｅｃｔｒｕｍ Ｍａｎａｇｅｍｅｎｔ Ｒｅｐｏｒｔ（ＮＩＰＰ−ＮＡＩ−２００５−０３１）で入手可能である。

同じバインダ（ｂｉｎｄｅｒ）を共有する回線が、同じ回線カード上で終端することは、ＶＤＳＬにおいて一般的であるのに比べて、ＡＤＳＬにおいてはあまり一般的ではない。ただし、同一バインダ回線の共通終端は同様に行われてもよいため、ＤＳＬシステムの以下の説明は、ＡＤＳＬにも拡張されてもよい（特に、ＡＤＳＬおよびＶＤＳＬの両方を処理する、より新しいＤＳＬＡＭにおいて）。複数のトランシーバペアが動作中および／または利用可能である、ＤＳＬプラントの一般的なトポロジにおいては、マルチペアバインダ（またはバンドル）内で、各加入者ループの一部が、他のユーザのループと一緒に置かれる。ペデスタルの後、カスタマ構内設備（ＣＰＥ）の非常に近くで、ループは引き込み線の形態を取り、バンドルを出る。したがって、加入者ループは、２つの異なる環境を横切る。ループの一部はバインダの内部に配置されてもよく、そこでは、ループは外部の電磁インタフェースからは遮蔽される場合があるが、クロストークが発生しやすい。ペデスタルの後、このペアが引き込み線のほとんどにわたって他のペアから遠く離れている場合、引き込み線はクロストークには影響されないことが多いが、引き込み線は遮蔽されていないため、転送は電磁妨害によって、同様により大きく損なわれる可能性がある。多くの引き込み線は、それらの中に２〜８本のツイストペア線を有し、家庭への複数のサービス、またはそれらの回線のボンディング（１つのサービスの多重化および逆多重化）の状況においては、引き込み線セグメント内で、それらの回線間に、追加のかなりのクロストークが発生する可能性がある。

一般的な、例示的ＤＳＬ配備シナリオを、図２に示す。合計（Ｌ＋Ｍ）個のユーザ２９１、２９２のすべての加入者ループは、少なくとも１つの共通バインダを通過する。各ユーザは、専用の回線を介して中央局（ＣＯ）２１０、２２０に接続される。ただし、各加入者ループは、異なる環境および媒体を通過してもよい。図２では、Ｌ個のカスタマまたはユーザ２９１が、光ファイバ２１３と銅ツイストペア線２１７との組み合わせを使用して、ＣＯ ２１０に接続されており、これは一般に、ファイバ・ツー・ザ・キャビネット（ＦＴＴＣａｂ）またはファイバ・ツー・ザ・カーブと呼ばれる。ＣＯ ２１０内のトランシーバ２１１からの信号は、ＣＯ ２１０および光ネットワークユニット（ｏｐｔｉｃａｌ ｎｅｔｗｏｒｋ ｕｎｉｔ（ＯＮＵ））２１８内の、光回線終端装置（ｏｐｔｉｃａｌ ｌｉｎｅ ｔｅｒｍｉｎａｌ）２１２および光ネットワーク終端装置（ｏｐｔｉｃａｌ ｎｅｔｗｏｒｋ ｔｅｒｍｉｎａｌ）２１５によって変換される。ＯＮＵ ２１８内のモデム２１６は、ＯＮＵ ２１８とユーザ２９１との間の信号のためのトランシーバとしての役割を果たす。

ＣＯ ２１０、２１８、およびＯＮＵ ２２０（ならびに、その他）などの位置で共通終端するユーザの回線は、ベクトル化などの、連係したやり方で動作させられてもよい。ベクトル化された通信システム（ベクトル化ＡＤＳＬおよび／またはＶＤＳＬシステムなど）においては、信号および処理の連係が達成されてもよい。ダウンストリームベクトル化は、ＤＳＬＡＭまたはＬＴからの、複数回線の転送信号が、共通のクロックおよびプロセッサを用いて共同生成される場合に発生する。そのような共通クロックを有するＶＤＳＬシステムにおいては、ユーザ間のクロストークは、各トーンについて別々に発生する。したがって、多くのユーザについてのダウンストリームトーンのそれぞれは、共通ベクトルトランスミッタによって別個に生成されてもよい。同様に、アップストリームベクトル化は、複数回線の信号を共同受信するために、共通のクロックおよびプロセッサが使用される場合に発生する。そのような共通クロックを有するＶＤＳＬシステムにおいては、ユーザ間のクロストークは、各トーンについて別々に発生する。したがって、多くのユーザについてのアップストリームトーンのそれぞれは、共通ベクトルレシーバによって別個に処理されてもよい。

残りのＭ個のユーザ２９２のループ２２７は、銅ツイストペア線のみであり、このシナリオは、ファイバ・ツー・ザ・エクスチェンジ（ＦＴＴＥｘ）と呼ばれる。可能であり、かつ経済的に実現可能である限り、ＦＴＴＣａｂの方がＦＴＴＥｘよりも好ましく、その理由は、それにより、加入者ループの銅部分の長さが減少し、したがって、達成可能な速度が増加するからである。ＦＴＴＣａｂループの存在は、ＦＴＴＥｘループに問題を引き起こす可能性がある。さらに、ＦＴＴＣａｂは、将来、ますます普及したトポロジとなることが期待される。このタイプのトポロジは、かなりのクロストーク干渉をもたらす可能性があり、また、さまざまなユーザの回線が、それらが動作する特定の環境のため、異なるデータ搬送およびパフォーマンス能力を有することを意味する可能性がある。トポロジは、ファイバ供給の「キャビネット」回線と交換回線とが、同じバインダ内で混合されることが可能であるようなものであってもよい。

図２からわかるように、ＣＯ ２２０からユーザ２９２への回線は、ＣＯ ２１０とユーザ２９１との間の回線によって使用されていない、バインダ２２２を共有する。さらに、別のバインダ２４０が、ＣＯ ２１０およびＣＯ ２２０と、それらのそれぞれのユーザ２９１、２９２との間のすべての回線に共通している。図２では、遠端クロストーク（ＦＥＸＴ）２８２と近端クロストーク（ＮＥＸＴ）２８１とが、ＣＯ ２２０において一緒に置かれた回線２２７のうちの少なくとも２本に影響するものとして示されている。

当業者によって理解されるように、これらの文献に記載された動作データおよび／またはパラメータのうちの少なくとも一部は、本発明の実施形態に関連して使用されてもよい。さらに、システムの説明のうちの少なくとも一部は、同様に、本発明の実施形態に適用可能である。ＤＳＬ ＮＭＳから入手可能な、さまざまなタイプの動作データおよび／または情報は、その中に見出されてもよく、その他は、当業者に知られている可能性がある。

本発明の一部の実施形態では、バインダ内の回線は、単一の回線カード上で終端することが望ましい（その回線カード上には、ベクトル化ＤＳＬチップまたは装置が搭載されているか、または、その回線カードには、そのような装置が別の方法で結合されている）。ただし、通常の配線の実践においては、そのような単一回線カード共通バインダ終端が行われるという保証はない。行われる場合、クロストークは、ベクトル化を用いてキャンセルされる／利用されることが可能である。信号のルーティングは、さらに、電子分配フレームまたはバックプレーン内で行われてもよいが、それらはシステム全体のコストを増加させる可能性がある。このように、近隣の、または建物内の、４８、９６、または１９２本の回線を、１つまたはいくつかの回線カード上で一般に終端させる、ＶＤＳＬの回線終端装置（ｌｉｎｅ ｔｅｒｍｉｎａｔｉｏｎ（「ＬＴ］））は、バインダからのすべての回線を１つの回線カード上で終端させる可能性が、特に、そのような共通カード終端を保証するために電話会社が配線において何らかの取り組みをする場合は、比較的高い。

一般的な通信システムにおいては、さまざまなパフォーマンス測定基準の間で、多数のトレードオフがある。一般に、システム動作特性およびパラメータの実施に関して行われる、評価および決定は、電気通信会社（すなわち、「ｔｅｌｃｏ」）などの、システムのサービスプロバイダまたはオペレータによって実行される（すべてのそのような集中型システム制御部を、本明細書では「オペレータ」と呼ぶ）。ＤＳＬオペレータは、一般に、ＤＳＬシステム内のアクセスノードを、制御し、動作させ、かつ／または、所有する。これらのアクセスノードは、ＤＳＬＡＭ、ＲＴ、ＬＴ、ＯＮＵ、および／または、その他の任意の類似した機器および／または装置であってもよい。

ＤＳＬシステムオペレータ（ｔｅｌｃｏ ＣＬＥＣまたはＩＬＥＣなど）は、システムの「動作領域（ｏｐｅｒａｔｉｏｎａｌ ｓｐａｃｅ）」を定義、制限、設定、および制御する（一般に、「定義する」と呼ばれる）ことが可能であり、ここで、「動作領域」は、そのようなシステムをユーザがどのように使用できるかを定義する、規則、許容される使用法、特性、動作パラメータ範囲などを含む。本発明を使用する場合、ユーザ嗜好データがオペレータによって取得され、ＤＳＬシステムなどの通信システムの、オペレータにより定義された動作領域と比較されて、１つ以上のユーザ嗜好がシステム内で実施されてもよいかどうかが判定される。実現可能な場合、または許容される場合、オペレータは、オペレータによるＤＳＬシステムの操作と矛盾しない、ユーザ嗜好を実施してもよい。言い換えると、オペレータによって定義および維持される動作領域内に収まるユーザ嗜好を、オペレータは実施してもよい。

さまざまな動作特性およびパラメータは、オペレータによる考慮事項の一部である。これらの動作特性およびパラメータは、システムの機能的属性（例えば、回線状態、外部ノイズなど）、システム実施（例えば、利用可能なＤＳＬサービスのタイプ、オペレータのサービスプランによって課される制限など）、ならびにユーザサービス制限（例えば、ユーザは３Ｍｂｐｓよりも大きなデータレートを受信するための加入者ではない、かつ／またはそのための十分な支払いをしていない、ユーザ装置など）を含んでもよい。例えば、ＡＤＳＬまたはその他のＤＳＬシステムにおいて、データレートとサービス安定性とは一般に逆比例し、より高いデータレートは、通常、サービス停止の確率を増加させ、より低いデータレートは、そのようなサービス停止の確率を減少させる。オペレータは、一般に、オペレータ独自の広く適用される規則を規定し、それらの一般的規則を、すべての通信リンク上で実施する。本発明の実施形態では、オペレータ（例えば、ＤＳＬサービスプロバイダ）は、１つ以上のユーザの嗜好データを評価し、ユーザ嗜好をある程度実施するように、１本以上の回線を設定する。ユーザの嗜好と、それらの嗜好を反映するユーザ嗜好データとは、直接的に（例えば、ユーザとの電話、電子メールによる調査、Ｗｅｂインタフェースなど）、または間接的に（例えば、ユーザデータ活動の、１つ以上の隠れマルコフモデルに基づいて）見出されてもよい。

以下の例のいくつかは、より高いデータレート（およびサービス停止のより高い確率）と、サービス停止／モデム再トレーニングのより低い確率（およびより低いデータレート）との、２つの逆比例する嗜好の間でトレードオフが行われる、ＤＳＬシステムのための、本発明の実施形態の実施を示す。一部のＤＳＬ回線は、時間とともに変化するノイズスペクトルによって、または時間とともに変化するインパルスノイズによって引き起こされる、劣化を受ける。そのような時間変化ノイズは、回線の最大達成可能データレートおよび／または安定性に直接影響を及ぼし、ノイズの影響が増加するにつれて回線はより不安定なサービスを経験する。多くの状況において、この時間とともに変化するノイズは、他のユーザのクロストークであってもよい。さらに、ファントムまたはスプリットペア回路が使用される場合は、ベクトル化差分システムにおけるように、一部のバインダ容量が、要求に応じて、異なるユーザに再割り当てされてもよく、その場合、各回線は、あたかも他の回線のうちの何本かはいかなる方法でも信号を搬送していないかのように動作する。非ベクトル化の状況では、任意の、および／または、すべてのユーザによって使用される、サービス品質およびデータレートにおいて、相互クロストークが制限効果となる可能性がある。

ＤＳＬモデムは、多くの場合、トレーニングの間に規定された一定のデータレートで動作する。レートまたはその他の何らかの動作パラメータ設定の、任意の後続の変更は、モデムの再トレーニングを必要とし、これは短いサービス停止（例えば、２０〜６０秒）を発生させる。これらの停止は、ユーザの不満および／または問題を発生させる可能性がある。サービス停止の予防が望ましい場合、より低いデータレートは、一般に、そのような停止の頻度を減少させるのに役立つ。他方、一部のユーザは、いかなるサービス停止にもかかわらず、それらのユーザの使用の性質のため、高データレートを要求および／または所望する場合がある。この第２のタイプのユーザは、ほとんどの時間、インターネットを対話的には使用しない可能性があり、そのため、時折のサービス停止は、より高いデータレートがその他の場合に維持されている限り、許容できる可能性がある。

第１のオペレータ戦略（「高信頼性」戦略）は、第１のユーザタイプの満足に焦点を合わせてもよく、したがって、非常に控えめなデータレート制限を設定する。そのような場合、１日（または１週間）につき数回の短いサービス中断を防止するために、データレートは、回線の平均最大達成可能データレートの２０〜３０％に抑制されてもよい。第２のオペレータ戦略（「高レート」戦略）は、第２のユーザタイプを満足させることを目指してもよく、第１の（高信頼性）戦略における場合よりも高いデータレートを設定する。第２の（高レート）戦略では、モデムはそのデータレートを、トレーニングのたびに、可能な最大レートに設定しているため、チャネルの大幅な時間変化を有する回線については、サービス停止がより頻繁に発生する可能性がある。

これまで、オペレータは、すべてのユーザにわたって適用される、上述した一般的な規則を使用して操作を行ってきており、完全なユーザ満足と使用ニーズとを考慮することはできなかった。本発明の実施形態は、オペレータが、ユーザ嗜好データ（例えば、ユーザ入力、または、ＨＭＭ分析などのその他の形態のユーザ嗜好情報）に基づいて、異なるユーザおよび／またはユーザセットに、異なる規則を適用することを可能にする。当業者によって理解されるように、本発明は任意の通信システムに適用されてもよい。例えば、無線サービスオペレータは、本発明の実施形態を使用して、カバレージエリアとバッテリ寿命とのトレードオフに使用される、個々のユーザリンクパラメータを設定してもよい。本明細書に記載した例および特許請求の範囲は、特に、ＤＳＬシステムを対象としている場合があるが、本発明はこれに限定されない。

本発明の一実施形態は、図３の流れ図に示す、方法３００である。３１０において、第１のパフォーマンス測定基準と第２のパフォーマンス測定基準との間の動作関係が決定される。これは、オペレータによる、または、システムの評価および制御においてオペレータを支援する、ＤＳＬオプティマイザまたはその他のエンティティなどのコントローラによる、通信システムから収集された動作データの解析を含んでもよい。これは、方法３００のこの段階において、オペレータが、システムの「動作領域」を定義、制限、設定、および制御してもよいことを意味し、ここで、「動作領域」は、そのようなシステムをユーザがどのように使用できるかを定義する、規則、許容される使用法、特性、動作パラメータ範囲などを含む。

一実施形態では、特に、非常に時間変化しやすいノイズまたはインパルスノイズを有する回線において、データレートとサービス安定性との間の関係が評価されてもよい。本発明の他の実施形態では、その他の測定基準およびそれらの関係が考慮されてもよい。例えば、特に、インパルスノイズを有する回線において、レイテンシとサービス安定性との間の関係、または、レイテンシとデータレートとの間の関係が評価されてもよい。ユーザは、これらのタイプの動作特性によって影響される、または決定付けられる、嗜好を有してもよく、それらの嗜好は、どのパラメータ値および／または範囲がユーザの嗜好に対応するのに役立つかを決定するために使用されてもよい。その他のパフォーマンス測定基準は、データレートの時間変化（すなわち、レートが、サービスに影響するのに十分なだけ、時間の経過とともに変化するか）、サービス安定性の時間変化、および、当業者に明白なその他を含む。

３２０において、１本の回線または複数の回線（例えば、ＤＳＬバインダグループ）であってもよい、ユーザセットから、嗜好データが収集される。収集されるユーザ嗜好データは、（例えば、ユーザとの直接通信からの）直接的なユーザ情報、または（例えば、ＨＭＭなどからの）間接的なユーザ情報を含んでもよい。直接的なユーザ情報を得るために、オペレータは、ユーザと直接連絡してユーザの嗜好を識別してもよく、さもなければ、ＨＭＭモデル、ユーザ苦情（トラブルチケット）などに基づいて、ユーザ満足のレベルを評価してもよい。直接的なユーザ調査では、パフォーマンス、使用、ユーザ満足などに関する、以下のような質問をしてもよい（または、これらは、ユーザに直接尋ねずに、サービス履歴から自動的に推論されてもよく、さまざまなサービス質問への回答は、記録された発生頻度に応じて導き出されてもよい）。
−長時間にわたるファイルのダウンロードを頻繁に行うか。
−ＶｏＩＰ、ネットワークゲームプログラム、その他のレイテンシに影響されやすいプログラムを使用するか。
−より高いデータレートを選ぶか、またはより安定したサービスを選ぶか。
−現在のデータレートに満足しているか。
−使用中のインターネット接続の安定性に満足しているか。
調査質問は、さらに、ユーザ嗜好データを後で解析する際の、ユーザの嗜好の定量化を可能にするために、評点またはその他の数値入力データを使用してもよい。オペレータとユーザとの間の直接的なユーザ連絡は、電話（ユーザがユーザサービスセンターに電話をかけた場合）、電子メールによる調査、Ｗｅｂインタフェースなどを介して行われてもよい。電子メールまたはＷｅｂインタフェースが使用される場合、データは、自動的に処理されて、コントローラ（ＤＳＬオプティマイザなど）に提供されてもよい。以下でより詳細に説明するように、ユーザ嗜好特性は、さらに、回線統計情報をある期間にわたって観測することによって推論されてもよい。

本発明の他の実施形態では、ユーザ嗜好は、さらに、オペレータのデータベース（例えば、加入者アカウントデータベース）のうちの１つ以上の中のユーザ嗜好情報から導き出されてもよい。オペレータは一組のサービスを提供してもよく、ユーザはそれらのサービスから選択してもよい。ユーザの、選択したサービスおよび／またはサービス選択履歴は、このアカウントデータベース内に存在する。一部の実施形態では、このユーザ嗜好情報は、サービス管理システム（ＳＭＳ）またはオーダーアンドコンフィギュレーションＯＳＳ（オペレーションサポートシステム）内に存在してもよい。そのようなデータベースの作成および維持に関する、ネットワーク管理の基本分野は、「ポリシー管理」と呼ばれる。

ユーザセットの回線の適切な動作を依然として可能にしながら、ユーザセットからの嗜好の実施を可能にする、動作設定が存在するかどうかを判定するために、３３０において、ユーザ嗜好データが解析される。関与する回線セットに適用可能な、妥当な選択肢が、識別および生成されてもよい。これらの選択肢の評価は、さまざまなユーザの嗜好が相互に整合性があるかどうかを（言い換えると、ユーザセットの回線内でユーザのさまざまな嗜好の実施可能な程度を）考慮することを含んでもよい。さらに、オペレータは、ユーザの嗜好が、オペレータによるシステムの操作と整合性があるかどうかを（すなわち、動作規則に違反することなく、ならびに／または、オペレータおよび／またはその他のユーザのためのシステムの動作を損なうことなく、オペレータがユーザ嗜好を実施できる程度を）評価してもよい。例えば、一部のユーザが非常に高いデータレートを要求し、そのデータレートを提供するために必要とされる電力レベルは、他のユーザに重大なクロストークの問題を発生させる場合、オペレータは、そのユーザ嗜好を実施しないことを選んでもよい。その他のそのような考慮は、当業者に明白であろう。

本発明の別の実施形態では、３３０において、ユーザ嗜好データを解析することによって、許容できる動作設定を決定するステップは、以下のステップを含む。既知のオペレータ規則（例えば、最小信頼性要件、最大データレートなど）を使用して、１つ以上の設定可能動作パラメータについての許容される値が識別される。これらの値のうちの１つ以上の選択は、ＤＳＬシステムの妥当で丁重な動作のための、オペレータの制約条件内での、ＤＳＬシステムの動作を可能にする。当業者によって理解されるように、オペレータはそのような制約条件を、丁重さだけでなく、任意の基準に基づいて設定してもよい。例えば、オペレータは、特別な加入または使用特権を有する「プレミアム」ユーザに、より広範な値を提供してもよい。許容される値の組は、ユーザ嗜好によって課される要求を満足するであろう値を選択するための、最適化領域を表してもよい。ユーザ嗜好データを明らかにした後、許容される値の組は、さらに、ユーザ嗜好とオペレータ規則との両方を満足するシステム動作をもたらすであろう値のみに制限される。最後に、得られる最高のパフォーマンスをＤＳＬシステムが達成するように、設定可能動作パラメータの値が（制限された組の中の値から）選択されてもよい。このようにして、オペレータとユーザとの両方の要求が、得られる最大の限度まで満足される。ＤＳＬシステムの動作パラメータを設定するための、値の範囲を絞るために、オペレータ規則とユーザ嗜好との両方が考慮に入れられる。

適用可能なシステム動作規則および動作パラメータに違反することなく、かつ／または、例えば、１つ以上のユーザにとっての不当な問題を引き起こすことなく、ユーザ嗜好データが実施可能である場合、３４０において、オペレータは、選択されたユーザセット（および／または、場合により、その他のユーザ）についての動作パラメータを、第１および第２のパフォーマンス測定基準に関するユーザ嗜好を実施するために設定してもよい。一部の実施形態では、オペレータは、所与のユーザまたはユーザのグループについて、動作パラメータベクトル値を実施してもよく、ここで、その動作パラメータベクトル値は、１つ以上の動作パラメータに値を割り当てる。当業者によって理解されるように、そのような動作パラメータベクトルは、１つの動作パラメータ値または複数の値を含んでもよい。

オペレータ（または、ＤＳＬオプティマイザなどの、オペレータのコントローラ）は、一部またはすべてのユーザ嗜好が、動作規則またはパラメータに違反するまでは有効であるように、または、ユーザセットがユーザ嗜好データを更新するまでは有効であるように、例えば、更新されたユーザ嗜好データが３２０において収集された場合に、回線を適切に設定してもよい。第１のパフォーマンス測定基準と第２のパフォーマンス測定基準との間の動作関係が、発展するか、またはその他の方法で変化する場合、方法３００は、ユーザ嗜好データを収集する前に、その関係情報を再構築するために、３１０に戻ってもよい。一部の実施形態では、オペレータは、回線設定自体を直接変更するのではなく、回線設定のために使用される規則を変更してもよい。上述したように、一部のデータ収集、解析、ＨＭＭ構築、設定などは、所望される場合、ＤＳＬオプティマイザなどの、オペレータのコントローラによって実行されてもよく、また、ＤＳＬシステム内で実施されてもよい。さらに、これらの方法のうちの１つ以上は、当業者によって理解されるように、ソフトウェアおよび／またはその他のコンピュータプログラムプロダクト内で実施されてもよい。

一般に、隠れマルコフモデル（ＨＭＭ）は、定義可能なパラメータを使用して、複雑な挙動をモデル化する、確率的信号モデルである。ＨＭＭは、複数の内部または隠れ状態と、状態遷移確率によって記述される定義済み状態シーケンスとを使用して、複雑な挙動をモデル化する。システムは、内部状態とは別個の出力を使用する。出力は、観測可能シンボルと呼ばれ、ＨＭＭへの１つの入力および／または入力タイプを表すスカラ値であってもよく、または、複数の入力および／または入力タイプを表すベクトル量であってもよい。観測可能シンボルは、ＨＭＭをモデル化するため、および、測定されるデータにＨＭＭがどれだけよく一致するかを表す確率を生成するために使用される。

より具体的には、（通信システムなどの）所与のシステムは、一般に、直接に観測可能ではない複数の内部状態を有する。本発明の実施形態によって実施されるＨＭＭは、特に、現在の状態と、システムが遷移してもよい次の状態と、システムの１つ以上の観測可能シンボルが既知の場合に、システムが所与の状態にある確率とを決定するのを支援する。数学的には、ＨＭＭは、以下のように記述される。
Ｎ：隠れ状態の数。
Ｍ：観測可能なスカラまたはベクトルシンボルの数。
Ａ：次の時間周期内に状態ｉに移動する、状態ｊの、状態遷移確率マトリクスであり、ここで、ａ_ｉｊ＝Ｐｒ（ｎ_ｔ＋１＝ｉ｜ｎ_ｔ＝ｊ）、１≦ｉ，ｊ≦Ｎであり、また、ｔは時間周期の指標であり、ｎ_ｔは時間周期ｔの間の状態番号である。
Ｂ：状態がｊである間の、観測しているシンボルｋの観測確率分布ベクトルであり、ここで、Ｂ_ｊ（ｋ）＝Ｐｒ（ｏ_ｔ＝ｋ｜ｎ_ｔ＝ｊ）、１≦ｋ≦Ｍ、１≦ｊ≦Ｎであり、ｏ_ｔは、時間周期ｔの間の観測されるシンボルである。
π：初期状態分布、π_ｊ＝Ｐｒ（ｎ_１＝ｊ）、１≦ｊ≦Ｎ。
λ：完全なＨＭＭモデルλ＝（Ａ，Ｂ，π）。
各時間周期内にＭ個のシンボルのうちの１つが観測されるが、状態は、直接観測可能ではないため、観測に基づいて推定される必要があることに留意されたい。

本発明の実施形態では、１つ以上のユーザ嗜好データを推定するために、１つ以上のＨＭＭが、オペレータによって使用されてもよい。このデータは、所与の通信回線が使用中である頻度、および回線について行われている使用の種類（例えば、ＶｏＩＰおよびその他の高需要の使用）などの、状態を表してもよい。場合によっては、各状態は、パフォーマンス測定基準（例えば、サービス安定性についてのユーザ満足度）であってもよく、一方、依拠される出力は、１つの動作またはパフォーマンスパラメータ値または分布、または、動作またはパフォーマンス状態（例えば、ユーザ／カスタマ苦情）、または、パラメータおよび／またはパフォーマンス特性の組み合わせであってもよい。

ＨＭＭは、対象の通信システムおよび／またはそのユーザから入手可能な情報に基づいて選択されてもよい。ＤＳＬシステムの場合、本開示で上述したように、また以下にも記載するように、システムＭＩＢから、および／またはシステムのその他の構成要素から入手可能な、多数のパラメータおよび／またはデータが存在する。さらに、本明細書でより詳細に説明するように、また、当業者に知られているように、ＤＳＬオプティマイザなどの、オペレータのコントローラが、その他の手段を介して、システムからその他の動作データを収集してもよい。

本発明の実施形態は、考慮中のユーザセット内の１つ以上のユーザの嗜好の推定を支援するために、ＨＭＭを使用する。本発明の実施形態のさまざまな例は、ＤＳＬシステムと関連付けて、本明細書に示されている。ただし、当業者によって理解されるように、本発明は、より一般的に、本発明の方法、装置、およびその他の実施形態が適用されることが可能な、任意の通信システムに適用される。

本発明の一部の実施形態では、ユーザ嗜好を識別するために使用される方法は、「教師なし学習」（ｎｏｎ-ｓｕｐｅｒｖｉｓｅｄ ｌｅａｒｎｉｎｇ）または「クラスタリング」または「ベクトル量子化」としてさまざまに知られているアルゴリズム分野に関連していると見られてもよい（これらの分野のいずれも、本発明の実施形態に関連して使用される方法に類似した方法で適用されたことはないが）。

以下のステップが実行されてもよい。
ａ）未知のユーザ嗜好を有するユーザのＤＳＬリンクから観測されたデータが、ベクトルｘにフォーマットされる（例えば、ＡＴＭセルカウント、現在のデータレート、ＣＶ違反、ＦＥＣ訂正など）。
ｂ）最小距離基準に基づいて、ベクトルｘは、いくつかのクラスタのうちの１つに分類される。
ｃ）選択されたクラスタに属する、既知のユーザ嗜好を有するユーザの、その他のＤＳＬリンクが、未知のユーザ嗜好を有するユーザのＤＳＬリンクについてのユーザ嗜好を推定するために調べられる（例えば、ユーザ嗜好は、トラフィック負荷、トラフィックタイプなどを示してもよい）。

一部の実施形態では、クラスタリング方法は、トレーニングのための独立した方法と、上述の、分類のための独立した方法とを含んでもよい。クラスタリングに関連する一般的なトレーニング方法は、当業者によく知られている（本発明の実施形態によって対処されるタイプの状況に適用されたことはないが）。本発明による１つ以上の方法を説明する例を、以下に示す。ｘを、ＤＳＬリンクの、観測されるデータのベクトルであると仮定し、ｙ_ｉ、ｉ＝１，．．．，Ｃを、Ｃ個のクラスタに関連付けられたベクトルであると仮定し、ここで、各クラスタは、別個のユーザ嗜好に対応する。以下のステップが実行される。
ｉ．ベクトルｙ_ｉ、ｉ＝１，．．．，Ｃを初期化する。
ｉｉ．１回以上のイタレーションを実行して、トレーニングセットのデータに基づく新しいモデルベクトルｙ_ｉ、ｉ＝１，．．．，Ｃを取得する。
ｉｉｉ．トレーニングセットのデータについての、全ひずみを計算する。
ｉｖ．全ひずみが、何らかの閾値よりも小さい場合は、終了する。それ以外の場合は、ステップｉｉに進む。

ステップｉｉおよびｉｉｉについて、以下に、より詳細に説明する。

ステップｉｉについては、
ａ）トレーニングセットに属する各ベクトルｘについて、ｉ以外の任意のｊについてｄ（ｘ，ｙ_ｉ）≦ｄ（ｘ，ｙ_ｊ）となる、クラスタ／モデルｉを見つける。
ｂ）各クラスタについて、クラスタ／モデルｉに同様に属するトレーニングセットのすべてのベクトルｘの平均として、ｙ_ｉを再計算する。当業者によって理解されるように、「平均」は、ここでは、任意の適切な平均化操作であると定義される。

ステップｉｉｉについては、
ａ）全ひずみを、Ｄ＝ａｖｅｒａｇｅ［ｄ（ｘ，ｙ_ｉ）｜ｄ（ｘ，ｙ_ｉ）≦ｄ（ｘ，ｙ_ｊ），ｊ≠ｉ］として計算。言い換えると、これは、トレーニングセットのデータの各ベクトルの、最も近いｙ_ｉベクトルからの平均距離である。
ｂ）上記の分類段階方法を使用することによって、観測されたデータのベクトルｘは、Ｃ個のクラスタのうちの１つに分類されてもよく、ここで、各クラスタは、１つ以上の特定のループ特性（例えば、特定のＨＭＭ）に関連している。

図４は、前の例を実施し、４クラスタの場合のクラスタを使用する、本発明の一実施形態を示す。それぞれの十字形４１１、４１２、４１３、４１４は、ベクトルｙ_ｉに対応する。ＤＳＬ回線の、クラスタへの分類も示されており、ここで、同じクラスタに分類されたＤＳＬ回線は、図４００の線４３０によって境界を付けられた、正方形４２１、円形４２２、星形４２３、および三角形４２４として示されている。これらのタイプのシステム内で、別個のユーザ嗜好に対応するクラスタの組を決定する、ＤＳＬシステムについてのユーザ嗜好データが収集されてもよい。クラスタの組は、ユーザ嗜好を十分に分類するために必要なだけ多くのクラスタ（またはクラスタ点）を含んでもよい。ＤＳＬシステムについての動作データが、次に、収集されてもよく、その後、所与のユーザは、収集された動作データに基づいて、特定のクラスタに割り当てられてもよい。ユーザ嗜好データは、その場合、割り当てられたクラスタへのユーザの割り当てに基づいた、ｉである。

本発明の一部の実施形態では、嗜好データは、さらに、ユーザのコンピュータ、ネットワーク装置、ＤＳＬモデムなどの中に記憶されてもよいデータから取得されてもよい。そのようなデータは、ネットワーク統計情報（例えば、ＡＴＭセルカウント、パケットカウント、パケット遅延測定基準など）、アプリケーション情報（例えば、ビデオデコーダ、娯楽システム、ＶｏＩＰ電話など）、およびユーザ嗜好に関する情報を抽出するために使用されてもよいその他のデータを含んでもよい。

回線および／またはシステムが、設定、維持、または変更されるべきかどうかの評価、ならびに／または、本発明の実施形態による動作データの任意のその他の評価は、動作状態に関する最新の利用可能な動作データに基づくことが要求されてもよく、または、現在データだけでなく履歴データにも基づいてもよい。例えば、過去にパフォーマンスの問題を引き起こしたノイズ源（例えば、機器またはその他の装置）が除去された（例えば、居住者によって捨てられた）場合、その源からのノイズに関する、ＨＭＭの構造および／または規則の実施への、以前の影響は、取り除かれるか、または少なくとも低減されるべきである。したがって、履歴データは、使用される場合、任意の適切な方法で重み付けされてもよい。例えば、現在および履歴データの重み付けが、データがどれだけ新しいかに応じて適用されてもよいように、データ重み付けベクトル（Ｗ）が、各回線および／または動作状態に与えられてもよい。例えば、重み付けベクトルがＷ１＝［１１１］である場合、適合の評価において、最後の３つの更新期間（例えば、日）からのデータは、等しい重みを与えられる。重み付けベクトルがＷ２＝［１０００００００．５］である場合、最後に報告された動作状態データからのデータは、重み付け１とともに使用され、７更新期間前（例えば、１週間前）からのデータは、重み付け０．５とともに使用される。その他の更新期間からのデータは無視される。最後の２か月のみからのデータを、等しい重み付けとともに使用することが所望される場合、重み付けベクトルは、１日の更新期間を使用し、サイズ６０で、すべて１（すなわち、Ｗ３＝［１１１．．．１１１］）であってもよい。例えば、１回の読み取りが、任意の決定および／またはＨＭＭへの変更のための基礎となるべきかどうかに依存して、異なる動作状態について異なる重み付けベクトルが使用されてもよい。

考慮される動作データの適時性に加えて、任意の決定が行われるべきかどうか、および／または処置が取られるべきかどうかの評価、ならびに／または、動作データのその他の任意の評価は、十分な量の利用可能な動作データに基づくことが要求されてもよい。例えば、場合によっては、データ収集システムが誤動作するか、または非活動状態になる可能性があり、これは、利用可能なデータが非常に少ないか、または、まったくない可能性があることを意味している。そのような場合、高信頼の評価の基となるデータが不十分にしかないならば、システムは、システムおよび／または回線動作への、または、それらに適用可能なあらゆる制限および／またはパラメータへの、いかなる変更も行うことを控えることが役立つ可能性がある。不適切な変更が実施されるのを防止するために、変更の実施は、最後の評価以来、または指定された期間内に、十分な追加データが収集された場合のみに限られてもよい。動作データは、カーディナリティ技術およびデータ確率分布を使用して調べられてもよい。最近収集されたデータに有利なように、遠い過去の値の影響を低減するための、高度な分布推定が使用されてもよく、これは当業者によってよく理解されている。データの十分性または適時性規則が満足されない場合、そのような規則が満たされることを可能にする新しいデータが収集されるまで、動作は行われなくてもよい。

いくつかの実施例は、同様に、本発明の実施形態を説明する。

実施例１
この実施例では、（例えば、回線状態に対してデータレートが比較的高い場合の、ＤＳＬモデムの再トレーニングによる）サービス停止についてのユーザ苦情と、同じ時間周期の間の、実施されているデータレートとに関する、ユーザ嗜好データが、オペレータによって／オペレータのために収集される。図５Ａは、ある期間にわたる、これらの２つのタイプのデータの可能な関係を、この実施例の目的のために示す。ＨＭＭを使用した、データレート対サービス安定性の合同推定を、時間線５２０に示し、ここで、時間線５１０に示す利用可能なユーザデータレートが、その「より高い実施されているデータレート」状態５１２にある場合に、状態５２４において、ユーザ苦情が起こる可能性がより高い（例えば、それらは確率の閾値を超える）。この場合、このユーザセット内のユーザは、安定したサービスへの関心に比較して、データレート速度への関心はより少ないと結論付けられてもよい。状態５１４において、低いデータレートが実施されている場合に、ユーザ苦情がない（または比較的低い）という事実は、ユーザ嗜好の決定に影響を及ぼしてもよく、または及ぼさなくてもよいが、サービス速度に関する苦情がない（または非常に少ない）ため、場合によっては、ユーザの満足と解釈されてもよい。

実施例２
図５Ｂに示す、実施例１の変形では、モデルは、実施例１および図５Ａの、サービス安定性の苦情ではなく、高データレートを必要とするサービスの利用可能性に関するユーザ苦情を調べる。図５Ｂの時間線５３０には、より低いデータレート期間５３４と、より高いデータレート期間５３２とが、再び描画されている。時間線５４０では、１つ以上の所望のユーザサービスを提供するための十分に高いデータレートが利用できないことにより、５４４においてユーザ苦情が発生することがわかる。この場合、対象のユーザセットはサービス安定性よりも回線速度により関心があると、オペレータは推測してもよい。

実施例３
ユーザは、定められた／限定された長さの時間にわたる、より高いデータレートのサービスの購入を所望することを示してもよい。Ｗｅｂインタフェースを介して、ユーザは、限定された期間（１時間〜１日）のレート増加を指示する、アップグレードされたＤＳＬサービスを注文してもよい。ＤＳＬオプティマイザまたはその他のコントローラは、続いて、ＤＳＬシステムの設定を、より高いデータレートを可能にするために変更してもよい。指定された期間が過ぎた後の、対応するレートの減少も、ＤＳＬオプティマイザ、コントローラなどを介してスケジュールされる。そのような機能は、ＡＤＳＬ２／２＋およびＶＤＳＬ２のシームレスレート適合（Ｓｅａｍｌｅｓｓ Ｒａｔｅ Ａｄａｐｔａｔｉｏｎ（ＳＲＡ））機能を利用することにより提供されてもよく、その場合、より高い、またはより低いデータレートに向けて接続を導くために、ＳＲＡに関連付けられたアップシフトおよびダウンシフトマージンが、ＳＨＯＷＴＩＭＥの間に適合されてもよい。または、レートの変更は、再トレーニングを強制することによって可能にされてもよい。

実施例４
ユーザ嗜好は、既知のトラフィックタイプによって特徴付けられる特定のアプリケーションとともにＤＳＬサービスを使用することに向けての嗜好を含んでもよい。ユーザ嗜好の知識は、したがって、ネットワークプロトコル（ＴＣＰ、ＵＤＰ、ＲＴＰなど）の設定可能パラメータをチューニングするために利用されてもよい。そのようなチューニングは、ユーザと最もしばしば関連付けられるトラフィックタイプについての、転送を向上することを目指す。レイテンシ設定およびインパルスノイズ保護などの、ＤＳＬ物理層パラメータを設定するために、パケット損失、スループット、バッファサイズなどのネットワークプロトコル統計情報も、ユーザ嗜好の知識と組み合わされてもよい。

図６Ａに示す、本発明の一実施形態によれば、嗜好ベース制御ユニット６００は、ＤＳＬまたはその他の通信システムに結合されたオペレータの一部であるか、またはそのようなオペレータに結合されていてもよい。コントローラ６１０（例えば、オペレータのＤＳＬオプティマイザ、ＤＳＭサーバ、ＤＳＭセンタ、または動的スペクトルマネージャとして、またはそれらとともに機能している装置）は、システムの運用において、および、場合により、システムの使用の最適化において、オペレータを支援する。（ＤＳＬオプティマイザは、動的スペクトルマネージャ、動的スペクトル管理センタ、ＤＳＭセンタ、スペクトルメンテナンスセンタまたはＳＭＣとも呼ばれてもよい）。一部の実施形態では、コントローラ６１０は、完全に独立したエンティティであってもよく、一方、他の実施形態では、コントローラ６１０は、ｔｅｌｃｏ ＣＯまたはその他の位置から複数のＤＳＬ回線を操作している、ＩＬＥＣまたはＣＬＥＣの一部であってもよい。図６Ａの破線６４６からわかるように、コントローラ６１０は、ＣＯ １４６内にあってもよく、または、ＣＯ １４６の外部にあってもよい。さらに、コントローラ６１０は、複数のＣＯ内のＤＳＬおよび／またはその他の通信回線に、結合されていてもよく、かつ／または、それらを制御していてもよい。

オペレータの嗜好ベース制御ユニット６００は、収集手段として識別されるデータ収集ユニット６２０と、解析手段として識別される解析ユニット６４０とを含む。図６Ａに示すように、収集手段６２０（一般的に知られているタイプの、コンピュータ、プロセッサ、ＩＣ、コンピュータモジュールなどであってもよい）は、ＮＭＳ １５０、ＡＮ １４０におけるＭＥ １４４、および／または、ＭＥ １４４によって維持されるＭＩＢ １４８に結合されてもよく、それらのいずれかまたはすべては、例えば、ＤＳＬシステムの部分であってもよい。データは、さらに、ブロードバンドネットワーク１７０を介して（例えば、所与のＤＳＬシステム内の通常の内部データ通信の外側で、ＴＣＰ／ＩＰプロトコルまたはその他のプロトコルまたは手段を経由して）収集されてもよい。これらの接続のうちの１つ以上は、嗜好ベース制御ユニット６００が、動作データをシステムから、および、適切な場合は、他の場所から、収集することを可能にする。データは、一度に、または、ある期間にわたって収集されてもよい。場合によっては、収集手段６２０は、周期的に収集を行うが、さらに、要求に応じて、またはその他の任意の非周期的なやり方で（例えば、ＤＳＬＡＭまたはその他の構成要素が嗜好ベース制御ユニットにデータを送信した場合に）データを収集してもよく、それにより、嗜好ベース制御ユニット６００は、必要な場合に、その情報、動作などを更新することが可能になる。手段６２０によって収集されたデータは、通信システム内の、１つ以上のパフォーマンス測定基準、ユーザ嗜好の推定において使用される１つ以上のＨＭＭの構築および／または修正、ユーザ嗜好のパフォーマンス測定基準の実施を可能な程度まで許可する動作パラメータの定義などに関する、ユーザ嗜好についての解析および任意の決定のために、解析手段６４０（同様に、一般的に知られているタイプの、コンピュータ、プロセッサ、ＩＣ、コンピュータモジュールなどであってもよい）に提供される。

図６Ａの例示的システムにおいて、解析手段６４０は、オペレータのコントローラ６１０内の信号生成手段６５０に結合される。この信号発生器６５０（コンピュータ、プロセッサ、ＩＣ、コンピュータモジュールなどであってもよい）は、モデム、および／または、通信システムのその他の構成要素（例えば、ユーザのＤＳＬトランシーバ、および／または、システム内のその他の装置、構成要素など）への指示信号を、生成および送信するように構成される。これらの指示は、データレート、転送電力レベル、コーディングおよびレイテンシ要件、再トレーニングのスケジューリングおよび実施、システム設定指示、ユーザ嗜好データおよび／またはその他のデータの直接的要求などに関する指示を含んでもよい。指示は、コントローラ６１０に結合された所与の通信システム内で、１つ以上のユーザ嗜好が実施されてもよいかどうかを、コントローラ６１０が判定した後で生成されてもよい。

本発明の実施形態は、収集されたデータ（ユーザ嗜好データ、動作領域データ、収集された動作データなどに関する履歴データ、およびその他のタイプのデータを含む）、以前に構築されたＨＭＭなどに関する、データベース、ライブラリ、またはその他のデータの集合を利用してもよい。この参照データの集合は、例えば、図６Ａのコントローラ６１０内の、またはコントローラ６１０が利用可能な、ライブラリ６４８（例えば、データベースまたはメモリ）として、オペレータによって記憶されてもよく、そして、解析手段６４０、収集手段６２０などによって使用されてもよい。オペレータは、さらに、ライブラリ、メモリ、および／またはデータベース情報を、コントローラの外部の位置において記憶してもよく、そこから、コントローラはデータにアクセスしてもよい。これは、図６Ｂのライブラリ／データベース／メモリ６７５についても同様である。

本発明の一部の実施形態では、嗜好ベース制御ユニット６００は、ＰＣ、ワークステーションなどの１つ以上のコンピュータ内で、および／または、１つ以上のコンピュータプログラムプロダクト内で、実施されてもよい。収集手段６２０および解析手段６４０は、当業者によって理解されるように、ソフトウェアモジュール、ハードウェアモジュール、または両方の組み合わせであってもよい。多数のモデム、回線、ユーザなどを処理する場合は、収集される大量のデータを管理するために、データベースが導入されて使用されてもよい。

本発明の別の実施形態を、図６Ｂに示す。オペレータのＤＳＬオプティマイザ６６５は、ＤＳＬＡＭ ６８５またはその他のアップストリームエンドＤＳＬシステム構成要素（例えば、ＲＴ、ＯＮＵ／ＬＴなど）上で、および／または、それらに関連して動作し、それらのいずれかまたは両方は、電気通信会社（「ｔｅｌｃｏ」）の構内６９５にあってもよい。オペレータのＤＳＬオプティマイザ６６５は、ユーザ嗜好データ、動作データなどの、収集、組み立て、調整、操作、および／または供給を、ＤＳＬオプティマイザ６６５のために、およびＤＳＬオプティマイザ６６５に対して行ってもよい、データモジュール６８０を含む。モジュール６８０は、１つ以上の、ＰＣなどのコンピュータ内で実施されてもよい。モジュール６８０からのデータは、解析（例えば、さまざまなパフォーマンス測定基準の間の動作関係の決定、収集されたユーザ嗜好データの解析、ユーザ嗜好の実施を許可する、可能な動作パラメータ範囲および値の解析など）のために、ＤＳＭサーバモジュール６７０に供給される。情報は、さらに、ｔｅｌｃｏに関係していてもよく、またはｔｅｌｃｏとは無関係であってもよい、ライブラリまたはデータベース６７５から入手可能であってもよい。

通信システムの動作に影響を及ぼす信号を実施するために、動作セレクタ６９０が使用されてもよい。当業者によって理解されるように、そのような決定は、ＤＳＭサーバ６７０によって、または、その他の任意の適切な方法で行われてもよい。セレクタ６９０によって選択される動作モードは、ＤＳＬＡＭ ６８５内、および／または、その他の任意の適切なＤＳＬシステム構成装置内で実施されてもよい。そのような装置は、カスタマ構内装置６９９などの、ＤＳＬ装置に結合されてもよい。装置６８５は、ＤＳＬオプティマイザ６６５によって評価されたユーザ嗜好データ（直接的または間接的）に基づいて指示される任意の変更を実施するために使用されてもよい。図６Ｂのシステムは、当業者によって理解されるように、図６Ａのシステムに類似した方法で動作可能であるが、本発明の実施形態をやはり実施しながら、差異を実現することが可能である。

一般に、本発明の実施形態は、１つのコンピュータ、複数のコンピュータ、および／または、コンピュータの組み合わせ（これらのすべては、本明細書では、「コンピュータ」および／または「コンピュータシステム」と、区別せずに呼ばれてもよい）であってもよい、１つ以上のコンピュータシステム内に記憶された、またはそれらのコンピュータシステムを通して転送される、データが関与する、さまざまなプロセスを用いる。本発明の実施形態は、さらに、これらの動作を実行するためのハードウェア装置またはその他の装置に関する。この装置は、必要な目的のために特別に構築されてもよく、または、コンピュータ内に記憶されたコンピュータプログラムおよび／またはデータ構造によって選択的にアクティブにされる、または再設定される、汎用のコンピュータおよび／またはコンピュータシステムであってもよい。本明細書に記載したプロセスは、いかなる特定のコンピュータまたはその他の装置にも、本質的には関連しない。特に、さまざまな汎用のマシンが、本明細書に記載した教示に従って書かれたプログラムとともに使用されてもよく、または、必要な方法ステップを実行するためのより特殊化された装置を構築することが、より好都合な場合がある。さまざまなこれらのマシンのための、特定の構造は、以下に示す説明に基づくことにより、当業者にとって明らかになるであろう。

上記のような、本発明の実施形態は、コンピュータシステム内に記憶されたデータが関与する、さまざまなプロセスステップを用いる。これらのステップは、物理量の物理的操作を必要とするものである。必ずしもではないが、通常、これらの量は、記憶、転送、組み合わせ、比較、およびその他の操作をされることが可能な、電気的または磁気的信号の形態を取る。主に一般的使用の理由で、これらの信号を、ビット、ビットストリーム、データ信号、制御信号、値、要素、変数、文字、データ構造などと呼ぶことが、場合によっては好都合である。ただし、これらおよび類似した用語のすべては、適切な物理量に関連付けられるものであり、これらの量に適用される単なる好都合なラベルにすぎないということに留意すべきである。

さらに、実行される操作は、しばしば、識別する（ｉｄｅｎｔｉｆｙｉｎｇ）、適合させる（ｆｉｔｔｉｎｇ）、または比較する（ｃｏｍｐａｒｉｎｇ）などの用語で呼ばれる。本発明の部分を形成する、本明細書に記載するいかなる動作においても、それらの動作はマシン動作である。本発明の実施形態の動作を実行するための有用なマシンは、汎用ディジタルコンピュータ、またはその他の類似した装置を含む。すべての場合に、コンピュータを動作させることにおける動作の方法と、計算自体の方法との間の区別に留意すべきである。本発明の実施形態は、電気的またはその他の物理的信号を、その他の望ましい物理的信号を生成するために処理することにおいて、コンピュータを動作させるための、方法ステップに関する。

本発明の実施形態は、さらに、これらの動作を実行するための装置に関する。この装置は、必要な目的のために特別に構築されてもよく、または、コンピュータ内に記憶されたコンピュータプログラムによって選択的にアクティブにされる、または再設定される、汎用コンピュータであってもよい。本明細書に記載したプロセスは、いかなる特定のコンピュータまたはその他の装置にも、本質的には関連しない。特に、さまざまな汎用のマシンが、本明細書に記載した教示に従って書かれたプログラムとともに使用されてもよく、または、必要な方法ステップを実行するためのより特殊化された装置を構築することが、より好都合な場合がある。さまざまなこれらのマシンのために必要とされる構造は、上に示した説明から明らかになるであろう。

その上、本発明の実施形態は、コンピュータによって実施されるさまざまな動作を実行するためのプログラム命令を含む、コンピュータ読み取り可能な媒体に、さらに関する。媒体およびプログラム命令は、本発明の目的のために特別に設計および構築されたものであってもよく、または、それらは、コンピュータソフトウェア技術における当業者によく知られた、そのような当業者が入手可能な種類のものであってもよい。コンピュータ読み取り可能な媒体の例としては、以下に限定されるものではないが、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープなどの磁気媒体、ＣＤ−ＲＯＭディスクなどの光媒体、フロプティカルディスクなどの光磁気媒体、ならびに、読み出し専用メモリ装置（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）などの、プログラム命令を記憶および実行するために特別に構成されたハードウェア装置などがある。プログラム命令の例には、コンパイラによって生成されるような、マシンコードと、インタープリタを使用してコンピュータによって実行されてもよい、より高水準なコードを含むファイルとの、両方が含まれる。

図７は、本発明の１つ以上の実施形態に従って、ユーザおよび／またはコントローラによって使用されてもよい、一般的なコンピュータシステムを示す。コンピュータシステム７００は、一次記憶装置７０６（一般に、ランダムアクセスメモリ、またはＲＡＭ）、一次記憶装置７０４（一般に、読み出し専用メモリ、またはＲＯＭ）を含む、記憶装置に結合された、任意の数のプロセッサ７０２（中央処理ユニット、またはＣＰＵとも呼ばれる）を含む。当技術分野でよく知られているように、一次記憶装置７０４は、データおよび命令を、ＣＰＵへの一方向で転送するように働き、一次記憶装置７０６は、一般に、双方向の方法でデータおよび命令を転送するために使用される。これらの一次記憶装置の両方は、上記のコンピュータ読み取り可能な媒体のうちの、任意の適切なものを含んでもよい。大容量記憶装置７０８は、ＣＰＵ ７０２に双方向でさらに結合されて、追加のデータ記憶容量を提供するもので、上記のコンピュータ読み取り可能な媒体のうちのいずれを含んでもよい。大容量記憶装置７０８は、プログラム、データなどを記憶するために使用されてもよく、一般に、一次記憶装置よりも低速な、ハードディスクなどの二次記憶媒体である。大容量記憶装置７０８内に保持される情報は、適切な場合には、仮想メモリとして、一次記憶装置７０６の一部として標準的な方法で組み込まれてもよいということが理解されるであろう。ＣＤ−ＲＯＭ ７１４などの特定の大容量記憶装置も、ＣＰＵに一方向でデータを渡してもよい。

ＣＰＵ ７０２は、さらに、ビデオモニタ、トラックボール、マウス、キーボード、マイクロフォン、タッチセンシティブディスプレイ、トランスデューサカードリーダ、磁気または紙テープリーダ、タブレット、スタイラス、音声または手書き文字認識装置、または、当然ながら、他のコンピュータなどの、その他のよく知られた入力装置といった、１つ以上の入出力装置を含む、インタフェース７１０に結合される。最後に、ＣＰＵ ７０２は、任意選択で、７１２において一般的に示されているようなネットワーク接続を使用して、コンピュータまたは電気通信ネットワークに結合されてもよい。そのようなネットワーク接続を用いて、ＣＰＵは、上記の方法ステップの実行中に、ネットワークから情報を受信してもよく、または、ネットワークに情報を出力してもよいということが考えられる。上記の装置および事項は、コンピュータハードウェアおよびソフトウェア技術における当業者によく知られている。上記のハードウェア要素は、本発明の動作を実行するための複数のソフトウェアモジュールを規定してもよい。例えば、コードワード合成コントローラ（ｃｏｄｅｗｏｒｄ ｃｏｍｐｏｓｉｔｉｏｎ ｃｏｎｔｒｏｌｌｅｒ）を実行するための命令は、大容量記憶装置７０８または７１４上に記憶され、一次メモリ７０６と連携してＣＰＵ ７０２上で実行されてもよい。好ましい実施形態では、コントローラは、ソフトウェアサブモジュールに分割される。

本発明の多くの特徴および利点は、記載した説明から明らかであり、したがって、添付の特許請求の範囲は、本発明のそのような特徴および利点をすべて包含することを意図したものである。さらに、多くの変形および変更に、当業者は容易に想到するため、本発明は、説明および記載されたとおりの構成および動作には限定されない。したがって、記載された実施形態は、限定的ではなく例示的なものと解釈されるべきであり、また、本発明は、本明細書に記載された詳細に限定されるべきではなく、特許請求の範囲と、現在または将来において予測できる、または予測できない、それらの全範囲の均等物とによって規定されるべきである。

本発明の実施形態が使用されてもよい、さまざまなＤＳＬおよびその他の通信システムに適用可能な、Ｇ．９９７．１標準による参照モデルシステムの概略ブロック図である。 一般的な、例示的ＤＳＬ配備を示す概略図である。 本発明の１つ以上の実施形態による方法の流れ図である。 本発明の一実施形態に従ってクラスタリングを使用する方法を示す図である。 本発明の一実施形態による方法の実施を示す図である。 本発明の一実施形態による別の方法の実施を示す図である。 本発明による、オペレータにより制御されるユーザ嗜好ベース制御ユニットを含むコントローラである。 本発明による、オペレータにより制御されるユーザ嗜好ベース制御ユニットを含むコントローラを実施する、ＤＳＬオプティマイザである。 本発明の実施形態の実施に適した、一般的なコンピュータシステムまたは集積回路システムのブロック図である。

Claims (55)

1. オペレータによってＤＳＬシステムの動作を制御する方法であって、
   前記ＤＳＬシステムについての動作領域を定義するステップと、
   前記ＤＳＬシステムについてのユーザ嗜好データを収集するステップと、
   前記ＤＳＬシステムの動作パラメータベクトル値を決定するために、前記収集されたユーザ嗜好データを解析するステップであって、前記動作パラメータベクトル値は、
   前記動作領域内での前記ＤＳＬシステムの動作を可能にし、かつ、
   前記収集されたユーザ嗜好データ内に反映された１つ以上のユーザ嗜好を実施するステップと、
   前記動作パラメータベクトル値をユーザのために実施するステップと動作領域
   を含む方法。
2. 前記動作領域を決定するステップは、少なくとも２つのパフォーマンス測定基準の間の動作関係を決定するステップをさらに含む、請求項１に記載の方法。
3. 前記ＤＳＬシステムについてのユーザ嗜好データを収集するステップは、ユーザ調査を行うステップ、電子メールによるアンケートを送信するステップ、ユーザとの電話を介してユーザフィードバックを取得するステップ、Ｗｅｂインタフェースを使用するステップ、または、直接的なユーザフィードバックを取得するステップのうちの少なくとも１つを含む、請求項１に記載の方法。
4. 前記ＤＳＬシステムについてのユーザ嗜好データを収集するステップは、
   ＨＭＭを取得するステップと、
   前記ＤＳＬシステムについての動作データを収集するステップと、
   ＨＭＭ内部状態を判定するために、前記収集された動作データを使用するステップと、
   前記ユーザ嗜好データを導き出すために、前記ＨＭＭ内部状態を使用するステップとを含む、請求項１に記載の方法。
5. 前記ＤＳＬシステムについてのユーザ嗜好データを収集するステップは、
   別個のユーザ嗜好に対応する、クラスタの組を決定するステップであって、前記クラスタの組は、第１のクラスタを含むステップと、
   前記ＤＳＬシステムについての動作データを収集するステップと、
   前記収集された動作データに基づいて、前記第１のクラスタに前記ユーザを割り当てるステップと、
   前記第１のクラスタへの前記ユーザの前記割り当てに基づいて、前記ユーザ嗜好データを生成するステップとを含む、請求項１に記載の方法。
6. 前記ＤＳＬシステムについてのユーザ嗜好データを収集するステップは、前記ユーザ嗜好データを取得するためにデータベースへの問い合わせを行うステップを含む、請求項１に記載の方法。
7. 前記収集されたユーザ嗜好データを解析するステップは、
   設定されるべき動作パラメータベクトルを決定するステップと、
   前記動作パラメータベクトルの、許容されるベクトル値の組を識別するステップであって、前記許容されるベクトル値の組の中の、各ベクトル値は、前記動作領域に適合するステップと、
   前記動作パラメータベクトルの、前記許容されるベクトル値の組を、前記収集されたユーザ嗜好データに適合するように制限するステップと、
   前記制限された許容されるベクトル値の組の中から、目標パフォーマンスレベルを達成する、前記動作パラメータベクトルの最適化ベクトル値を決定するステップとを含む、請求項１に記載の方法。
8. 前記動作パラメータベクトル値を前記ユーザのために実施するステップの前に、前記ＤＳＬシステムを再トレーニングするステップをさらに含む、請求項１に記載の方法。
9. 前記収集されたユーザ嗜好データを解析するステップは、
   前記ＤＳＬシステムの動作データを収集するステップと、
   前記収集されたユーザ嗜好データ内に反映された１つ以上の嗜好の実施の実現可能性を、前記ＤＳＬシステムの前記収集された動作データに照らして判定するステップとを含む、請求項１に記載の方法。
10. 前記ＤＳＬシステムの動作データを収集するステップは、前記収集された動作データに重み付け係数を適用するステップ、前記収集された動作データについての十分性検査を実行するステップ、または、前記収集された動作データについての適時性検査を実行するステップのうちの少なくとも１つを含む、請求項９に記載の方法。
11. マシン読み取り可能な媒体と、
    前記マシン読み取り可能な媒体内に含まれるプログラム命令とを含むコンピュータプログラムプロダクトであって、前記プログラム命令は、オペレータによってＤＳＬシステムの動作を制御する方法を指定し、前記方法は、
    前記ＤＳＬシステムについての動作領域を定義するステップと、
    前記ＤＳＬシステムについてのユーザ嗜好データを収集するステップと、
    前記ＤＳＬシステムの動作パラメータベクトル値を決定するために、前記収集されたユーザ嗜好データを解析するステップと、
    前記動作パラメータベクトル値をユーザのために実施するステップとを含み、
    前記動作パラメータベクトル値は、
    前記動作領域内での前記ＤＳＬシステムの動作を可能にし、かつ、
    前記収集されたユーザ嗜好データ内に反映された１つ以上のユーザ嗜好を実施するコンピュータプログラムプロダクト。
12. オペレータデータベースと、
    コントローラとを含むＤＳＬシステム動作制御システムであって、
    前記コントローラは、
    データ収集ユニットであって、
    前記オペレータデータベースからの動作領域データと、
    ＤＳＬシステムからの動作データと、
    ユーザ嗜好データとを収集するように構成されたデータ収集ユニットと、
    前記収集ユニットに結合された解析ユニットであって、
    前記収集された動作データと、前記収集されたユーザ嗜好データとを解析し、および、
    前記収集されたユーザ嗜好データ内に反映された１つ以上の嗜好の実施の実現可能性を、前記動作領域データに照らして判定するように構成され解析ユニットと、
    前記解析ユニットに結合された制御信号発生器であって、
    前記ＤＳＬシステムに制御信号を送信するように構成され、さらに、前記制御信号は、前記ＤＳＬシステムの動作を制御する信号を含む制御信号発生器と
    を含む、ＤＳＬシステム動作制御システム。
13. 前記収集ユニットは、
    ＨＭＭを取得し、
    前記ＤＳＬシステムについての動作データを収集し、
    前記収集された動作データから、ＨＭＭ内部状態を判定し、および、
    前記ＨＭＭ内部状態から、前記ユーザ嗜好データを導き出すように構成される、請求項１２に記載のコントローラ。
14. 前記収集ユニットは、
    別個のユーザ嗜好に対応する、第１のクラスタを含むクラスタの組を決定し、
    前記ＤＳＬシステムについての動作データを収集し、
    前記収集された動作データに基づいて、前記第１のクラスタに前記ユーザを割り当て、および、
    前記第１のクラスタへの前記ユーザの前記割り当てに基づいて、前記ユーザ嗜好データを生成するように構成される、請求項１２に記載のコントローラ。
15. 前記収集ユニットは、前記ユーザ嗜好データを取得するために、加入者アカウントデータベースへの問い合わせを行うように構成される、請求項１２に記載のコントローラ。
16. 前記解析ユニットは、
    設定されるべき動作パラメータベクトルを決定し、
    前記動作パラメータベクトルの、許容される値の組であって、オペレータ規則の組に適合する前記許容される値の組の中の各値を識別し、
    前記動作パラメータベクトルの、前記許容される値の組を、前記収集されたユーザ嗜好データに適合するように制限し、および、
    前記制限された許容される値の組の中から、目標パフォーマンスレベルを達成する、前記動作パラメータベクトルの最適化値を決定するように構成される、請求項１２に記載のコントローラ。
17. 前記制御信号発生器は、前記ＤＳＬシステムに再トレーニング信号を送信するように、さらに構成される、請求項１２に記載のコントローラ。
18. 前記制御信号発生器は、前記ＤＳＬシステムのトラフィックレベルが閾値未満である場合のみ、前記ＤＳＬシステムに再トレーニング信号を送信するように、さらに構成される、請求項１７に記載のコントローラ。
19. 前記データ収集ユニットは、前記収集された動作データへの重み付け係数の適用、前記収集された動作データについての十分性検査の実行、前記収集された動作データについての適時性検査の実行、前記収集されたユーザ嗜好データへの重み付け係数の適用、前記収集されたユーザ嗜好データについての十分性検査の実行、前記収集されたユーザ嗜好データについての適時性検査の実行、前記収集された動作領域データへの重み付け係数の適用、前記収集された動作領域データについての十分性検査の実行、または、前記収集された動作領域データについての適時性検査の実行のうちの少なくとも１つを実行するように、さらに構成される、請求項１２に記載のコントローラ。
20. オペレータデータベースをさらに含む、請求項１２に記載のコントローラ。
21. システムオペレータによって通信システムの動作を制御する方法であって、
    第１のパフォーマンス測定基準と第２のパフォーマンス測定基準とを含む、少なくとも２つのパフォーマンス測定基準の間の、動作関係を決定するステップと、
    前記通信システムからユーザ嗜好データを収集するステップであって、前記ユーザ嗜好データは、ユーザセットの嗜好と、前記第１および第２のパフォーマンス測定基準への前記嗜好の影響に関係するステップと、
    少なくとも１つの動作パラメータの調整か、または、回線設定のために使用される１つ以上の規則の調整のうちの少なくとも１つを行うことによって、前記ユーザ嗜好データ内に反映された前記ユーザセットの少なくとも１つの嗜好を反映するように、前記通信システムを動作させるステップとを含む方法。
22. 前記通信システムは、ＤＳＬシステム、ケーブルシステム、または無線システムのうちの１つである、請求項２１に記載の方法。
23. 前記第１のパフォーマンス測定基準は、サービス安定性である、請求項２１に記載の方法。
24. 前記第２のパフォーマンス測定基準は、データレートである、請求項２３に記載の方法。
25. 前記第１のパフォーマンス測定基準は、データレート、レイテンシ、遅延、データレートの時間変化、またはサービス安定性の時間変化のうちの１つである、請求項２１に記載の方法。
26. 前記ユーザセットは、１つのユーザである、請求項２１に記載の方法。
27. 前記ユーザセットは、複数のユーザである、請求項２１に記載の方法。
28. ユーザ嗜好データを収集するステップは、ユーザ嗜好に関する直接的なユーザ情報を前記オペレータが取得するステップを含む、請求項２１に記載の方法。
29. 前記直接的なユーザ情報は、調査情報、ユーザ苦情、Ｗｅｂインタフェースを介したユーザからの通信、またはユーザコメントのうちの少なくとも１つを含む、請求項２８に記載の方法。
30. ユーザ嗜好データを収集するステップは、ＨＭＭを構築するステップを含む、請求項２１に記載の方法。
31. マシン読み取り可能な媒体と、
    前記マシン読み取り可能な媒体内に含まれるプログラム命令とを含むコンピュータプログラムプロダクトであって、前記プログラム命令は、請求項２０の記載に従って通信システムの動作を制御する方法を指定するコンピュータプログラムプロダクト。
32. ＤＳＬシステムを動作させる方法であって、
    前記ＤＳＬシステムに関する動作データを収集するステップと、
    前記ＤＳＬシステムの１つ以上のユーザを含むユーザセットから、ユーザ嗜好データを収集するステップと、
    前記収集されたユーザ嗜好データ内に反映された１つ以上のユーザ嗜好の実施の実現可能性を解析するステップと、
    前記収集された動作データと前記収集されたユーザ嗜好データとに基づいて、少なくとも１つの実現可能なユーザ嗜好を実施するステップとを含む方法。
33. 前記ユーザ嗜好データは、前記ＤＳＬシステムの動作特性に関する情報を含む、請求項３２に記載の方法。
34. 前記ユーザ嗜好データは、サービス安定性、サービス安定性の時間変化、データレート、データレートの時間変化、遅延、またはレイテンシのうちの少なくとも１つに、直接的または間接的に関連する情報を含む、請求項３３に記載の方法。
35. 前記ユーザ嗜好データは、前記ユーザセットから直接的に収集された情報を含む、請求項３２に記載の方法。
36. 前記ユーザ嗜好データは、前記ユーザセットから間接的に収集された情報を含む、請求項３２に記載の方法。
37. 前記ユーザセットから間接的に収集された前記情報は、ＨＭＭから取得された情報を含む、請求項３６に記載の方法。
38. 前記収集されたユーザ嗜好データ内に反映された１つ以上のユーザ嗜好の実施の実現可能性を解析するステップは、
    前記ユーザセット内の複数のユーザからのユーザ嗜好の適合性を評価するステップ、または、
    前記ＤＳＬシステムの動作特性およびパラメータとの、前記ユーザ嗜好データの適合性を評価するステップ、
    のうちの少なくとも１つを含む、請求項３２に記載の方法。
39. 前記ＤＳＬシステムの動作特性およびパラメータとの、前記ユーザ嗜好データの適合性を評価するステップは、前記システムの機能的属性、システム実装、およびユーザサービス制限のうちの少なくとも１つを評価するステップを含む、請求項３８に記載の方法。
40. データ収集ユニットであって、
    ＤＳＬシステムからの動作データと、
    ユーザセットからのユーザ嗜好データとを収集するように構成されたデータ収集ユニットと、
    前記収集ユニットに結合された解析ユニットであって、
    前記収集された動作データとユーザ嗜好データとを解析し、および、
    前記収集されたユーザ嗜好データ内に反映された１つ以上の嗜好の実施の実現可能性を、前記ＤＳＬシステムの動作特性およびパラメータに照らして判定するように構成された解析ユニットと、
    前記解析ユニットに結合された制御信号発生器であって、
    前記ユーザセットに制御信号を送信するように構成され、さらに、前記制御信号は、前記ユーザセットの動作を制御する信号を含む制御信号発生器と
    を含むコントローラ。
41. 前記コントローラは、前記ＤＳＬシステム内でユーザ嗜好が実施されることが可能な程度を判定するように構成される、請求項４０に記載のコントローラ。
42. 前記ユーザセットは、１本のＤＳＬ回線を含む、請求項４０に記載のコントローラ。
43. 前記ユーザセットは、複数のＤＳＬ回線を含む、請求項４０に記載のコントローラ。
44. 前記ユーザセットは、バインダ内の複数のＤＳＬ回線を含む、請求項４０に記載のコントローラ。
45. 前記ユーザ嗜好データは、サービス安定性、サービス安定性の時間変化、データレート、データレートの時間変化、遅延、またはレイテンシのうちの少なくとも１つに関するデータを含む、請求項４０に記載のコントローラ。
46. 前記コントローラはＤＳＬオプティマイザである、請求項４０に記載のコントローラ。
47. マシン読み取り可能な媒体と、
    前記マシン読み取り可能な媒体内に含まれるプログラム命令とを含むコンピュータプログラムプロダクトであって、前記プログラム命令は、ＤＳＬシステムの動作を制御する方法を指定し、前記方法は、
    第１のパフォーマンス測定基準と第２のパフォーマンス測定基準との間の、動作関係に関するデータを取得するステップと、
    前記ＤＳＬシステムからユーザ嗜好データを収集するステップであって、前記ユーザ嗜好データは、ユーザセットの動作および／またはパフォーマンス嗜好に関するステップと、
    １つ以上のユーザ嗜好の実施の、前記第１および第２のパフォーマンス測定基準への影響を評価するステップと、
    前記ユーザ嗜好データ内に反映された、前記ユーザセットの１つ以上の嗜好を反映するように、少なくとも１つの動作パラメータを設定することによって、前記ＤＳＬシステムを制御するステップとを含むコンピュータプログラムプロダクト。
48. 前記第１のパフォーマンス測定基準は、サービス安定性である、請求項４７に記載のコンピュータプログラムプロダクト。
49. 前記第２のパフォーマンス測定基準は、データレートである、請求項４８に記載のコンピュータプログラムプロダクト。
50. 前記第１のパフォーマンス測定基準は、データレート、レイテンシ、遅延、データレートの時間変化、またはサービス安定性の時間変化のうちの１つである、請求項４７に記載のコンピュータプログラムプロダクト。
51. 前記ユーザセットは、１つのユーザである、請求項４７に記載のコンピュータプログラムプロダクト。
52. 前記ユーザセットは、複数のユーザである、請求項４７に記載のコンピュータプログラムプロダクト。
53. 前記ユーザ嗜好データは、ＨＭＭからのデータを含む、請求項４７に記載のコンピュータプログラムプロダクト。
54. マシン読み取り可能な媒体と、
    前記マシン読み取り可能な媒体内に含まれるプログラム命令とを含むコンピュータプログラムプロダクトであって、前記プログラム命令は、ＤＳＬシステムを動作させる方法を指定し、前記方法は、
    前記ＤＳＬシステムに関する動作データを取得するステップと、
    前記ＤＳＬシステムの１つ以上のユーザを含むユーザセットから、ユーザ嗜好データを取得するステップと、
    前記ユーザ嗜好データ内に反映された１つ以上のユーザ嗜好の実施の実現可能性を解析するステップと、
    前記動作データと前記ユーザ嗜好データとに基づいて、少なくとも１つの実現可能なユーザ嗜好を実施するステップとを含むコンピュータプログラムプロダクト。
55. 請求項２１に記載の方法を実施するように構成されたコントローラ。

Images