(57)【要約】   ＤＳＬリンクの安定性のレベルを示すデータが受信される。受信されたデータに基づいて、データが最小閾値を上回る又は下回るＤＳＬリンクの安定性のレベルを示すかどうかを決定する。ＤＳＬリンクの安定性のレベルが最小閾値を下回る場合、故障時の前のＤＳＬリンクと関係付けられた雑音は、故障時の後のＤＳＬリンクと関係付けられた雑音と比較される。故障時の前及び後の間の雑音の差異が閾値を超える場合、次いで雑音の差異はＤＳＬリンクと関連付けられた固定雑音として特性化される。しかし、故障時の前及び後の間の雑音の差異が閾値を下回る場合、故障がＤＳＬリンクへの電力損失又は重大なインパルス雑音イベントと関連付けられるかどうかが決定され、それに従って、雑音の差異が特性化される。最後に、ＤＳＬリンクと関連付けられる雑音の特性化はリンクの安定性を向上させるために、その後に起こりうるＤＳＬリンクの再構成のために保存される。
2010505288.tif 000002
【特許請求の範囲】
【請求項１】
ＤＳＬリンクに関連する雑音を特性化する方法であって、
ＤＳＬリンクの安定性のレベルを示すデータを受信するステップと、
前記データが、最小閾値を上回る又は下回る前記ＤＳＬリンクの安定性のレベルを示すかどうかを決定するステップと、
前記ＤＳＬリンクの安定性の前記レベルが前記最小閾値を下回る場合、
故障時の前の前記ＤＳＬリンクに関連する雑音と前記故障時の後の前記ＤＳＬリンクに関連する雑音とを比較するステップと、
前記故障時の前及び後の前記雑音間の差異が閾値を超える場合、次いで雑音の前記差異を前記ＤＳＬリンクに関連する固定雑音として特性化するステップと、
前記故障時の前及び後の前記雑音間の前記差異が前記閾値を下回る場合、前記故障が前記ＤＳＬリンクへの電力損失又は重大なインパルス雑音イベントに関連するかどうかを調査し、それに従って雑音の前記差異を特性化するステップと、
前記ＤＳＬリンクに関連する前記雑音の前記特性化を記録するステップと、
を備える、方法。
【請求項２】
前記データに基づいて前記ＤＳＬリンクの故障時を推定するステップをさらに備え、かつ故障時の前の前記ＤＳＬリンクに関連する雑音と前記故障時の後の前記ＤＳＬリンクに関連する雑音とを比較するステップは、
前記推定される故障時の前の前記ＤＳＬリンクに関連する雑音と前記推定される故障時の後の前記ＤＳＬリンクに関連する雑音とを比較するステップを備える、請求項１に記載の方法。
【請求項３】
前記ＤＳＬリンクに関連する雑音を比較するステップは、前記関連するＤＳＬリンクに結合されるＤＳＬレシーバにおいて、前記故障時の前の雑音と前記故障時の後の雑音とを比較するステップを備える、請求項１に記載の方法。
【請求項４】
経時的な前記受信されるデータの分布を評価するステップをさらに備え、かつ前記データが、最小閾値を上回る又は下回る前記ＤＳＬリンクの安定性のレベルを示すかどうかを決定するステップは、前記データの分布が、最小閾値を上回る又は下回る前記ＤＳＬリンクの安定性のレベルを示すかどうかを決定するステップを備える、請求項１に記載の方法。
【請求項５】
故障時の前の前記ＤＳＬリンクに関連する雑音と前記故障時の後の前記ＤＳＬリンクに関連する雑音とを比較するステップは、故障時の前の前記ＤＳＬリンクに関連する雑音と、前記ＤＳＬ回線が再初期化されかつ安定した状態である後の前記ＤＳＬリンクに関連する雑音とを比較するステップを備える、請求項１に記載の方法。
【請求項６】
前記ＤＳＬリンクに結合されるＤＳＬレシーバのデコーダの平均２乗誤差、及び信号対雑音比（ＳＮＲ）マージンのうちの少なくとも１つに従って、前記雑音が測定される、請求項１に記載の方法。
【請求項７】
前記故障時の前及び後の前記雑音間の前記差異は、複数の異なる周波数に対応する値のベクトルとして計算され、かつ前記雑音が前記閾値を超える又は下回るかどうかは、前記雑音が前記複数の異なる周波数の数に対して前記閾値を超える又は下回るかどうかを備える、請求項１に記載の方法。
【請求項８】
前記故障が重大なインパルス雑音イベントに関連するかどうかを調査するステップは、前記故障時と同じ又は同様の時間の前及び後の前記ＤＳＬリンクに隣接する１つ以上のＤＳＬリンクに関連する雑音を比較するステップを備える、請求項１に記載の方法。
【請求項９】
前記ＤＳＬリンクに関連する前記雑音の前記記録される特性化に応答して前記ＤＳＬリンクを再構成するステップをさらに備える、請求項１に記載の方法。
【請求項１０】
前記雑音の差異が前記ＤＳＬリンクに関連する固定雑音として特性化される場合、前記ＤＳＬリンクを再構成するステップは、
前記ＤＳＬリンクに関連する全ての周波数に対するターゲット又は最大ＳＮＲマージンを増加させるステップと、
前記ＤＳＬリンクに関連する前記固定雑音によって影響を受ける雑音に対するターゲット又は最大ＳＮＲマージンを増加させるステップと、
前記影響を受ける周波数を無効にするステップと、
前記影響を受ける周波数が、ビットスワップを介してロードビットの関連する数を増加させることを防ぐステップと、
前記影響を受ける周波数が、予め定められる閾値を超えてビットスワップを介してロードビットの前記関連する数を増加させることを防ぐステップと、
のうちの少なくとも１つを備える、請求項９に記載の方法。
【請求項１１】
前記雑音の差異が重大なインパルス雑音イベントとして特性化される場合、前記ＤＳＬリンクを再構成するステップは、再訓練閾値を調整するステップを備える、請求項９に記載の方法。
【請求項１２】
再訓練閾値を調整するステップは、
ＭＩＮＳＮＲＭと、
再訓練をトリガするコード違反に対する閾値と、
再訓練をトリガするデコーダエラーに対する閾値と、
のうちの少なくとも１つを備える、請求項１１に記載の方法。
【請求項１３】
前記ＤＳＬリンクの品質のレベルを示す性能監視データの分布を受信するステップと、
前記性能監視データの分布が、最小閾値を上回る又は下回る前記ＤＳＬリンクの前記品質のレベルを示すかどうかを決定するステップと、
前記ＤＳＬリンクの前記品質のレベルが前記最小閾値を下回る場合、
前記ＤＳＬリンクに関連する任意のインパルス雑音イベントが断続的または持続的であるかどうかを特性化するステップと、
前記ＤＳＬリンクに関連する前記インパルス雑音イベントの前記特性化を記録するステップと、
をさらに備える、請求項１に記載の方法。
【請求項１４】
前記性能監視データは、チャネル、回線、または上位層の性能監視データのうちの少なくとも１つを備える、請求項１３に記載の方法。
【請求項１５】
前記性能監視データの分布が、最小閾値を上回る又は下回る前記ＤＳＬリンクの品質のレベルを示すかどうかを決定するステップは、前記性能監視データの分布に基づく導出が、最小閾値を上回る又は下回る前記ＤＳＬリンクの品質のレベルを示すかどうかを決定するステップを備える、請求項１３に記載の方法。
【請求項１６】
前記性能監視データの分布が、最小閾値を上回る又は下回る前記ＤＳＬリンクの品質のレベルを示すかどうかを決定するステップは、前記分布に関して、ＣＶ、ＥＳ、ＳＥＳ、ＵＡＳ、ＬＯＳＳ、ＵＡＳ、またはそれらの導出のカウントのうちの少なくとも１つを測定するステップを備える、請求項１３に記載の方法。
【請求項１７】
前記ＤＳＬリンクに関連する任意のインパルス雑音イベントが断続的または持続的であるかどうかを特性化するステップは、前記インパルス雑音イベントの継続期間を決定するステップを備える、請求項１３に記載の方法。
【請求項１８】
前記ＤＳＬリンクに関連する前記インパルス雑音イベントの前記特性化を記録するステップは、前記インパルス雑音イベントの各々に関連する日付、時間、継続期間、及び影響を受ける周波数のうちの少なくとも１つを記録するステップをさらに備える、請求項１３に記載の方法。
【請求項１９】
インパルス雑音イベントの前記記録される特性化に応答して、前記ＤＳＬリンクを再構成するステップをさらに備える、請求項１３に記載の方法。
【請求項２０】
前記ＤＳＬリンクに関連する前記インパルス雑音イベントが断続的として特性化される場合、前記ＤＳＬリンクを再構成するステップは、前記ＤＳＬリンクに対するインパルス雑音保護に関連する設定を増加させるステップを備える、請求項１９に記載の方法。
【請求項２１】
前記ＤＳＬリンクに対するインパルス雑音保護に関する設定を増加させるステップは、
推定されるインパルス雑音幅よりも大きく最小インパルス雑音保護を設定するステップと、
推定されるインパルス雑音期間よりも小さく最大インターリーバ遅延を設定するステップと、
遅延バジェットよりも小さく最大インターリーバ遅延を設定するステップと、
ＲＳ符号語内の全バイトからの割合として推定エラーバイト数によって乗じられるｘよりも大きく最小ＲＳオーバヘッドを設定するステップであって、ｘは抹消復号化無しで２の値と等しく、かつｘは抹消復号化有りで２より小さくかつ１以上の間の値と等しいステップと、
のうちの少なくとも１つを備える、請求項２０に記載の方法。
【請求項２２】
前記ＤＳＬリンクに対するインパルス雑音保護に関する設定を増加させるステップは、
推定されるインパルス雑音幅よりも大きく最小インパルス雑音保護を設定するステップと、
推定されるインパルス雑音期間よりも小さく最小内部到達時間を設定するステップと、
遅延バジェットよりも小さく最大インターリーバ遅延を設定するステップと、
最小ＲＳオーバヘッド＞ｘ＊（ＲＳ符号語内の全バイトからの割合としての推定エラーバイト数）に設定するステップであって、抹消復号化無しでｘ＝２であり、かつ抹消復号化有りで１＝＜ｘ＜２であるステップと、
のうちの少なくとも１つを備える、請求項２０に記載の方法。
【請求項２３】
前記ＤＳＬリンクに関連する前記インパルス雑音イベントが持続的として特性化される場合、前記ＤＳＬリンクを再構成するステップは、前記ＤＳＬリンクに対するインパルス雑音保護に関連する設定を増加させるステップであって、
影響を受ける周波数がより小さいビット数（ＢＣＡＰ［ｎ］）をロードするように強いるステップと、
影響を受けるトーンを無効にするステップと、
影響を受けるトーンに対するＰＳＤＭＡＳＫまたはターゲットマージンを増加させるステップと、
を有するステップを備える、請求項１９に記載の方法。
【請求項２４】
コンピュータ可読媒体を備える製造業者の物品であって、前記コンピュータ可読媒体はコンピュータシステムによって実行されるときに、前記コンピュータシステムに以下の、
ＤＳＬリンクの安定性のレベルを示すデータを受信するステップと、
前記データが、最小閾値を上回る又は下回る前記ＤＳＬリンクの安定性のレベルを示すかどうかを決定するステップと、
前記ＤＳＬリンクの安定性の前記レベルが前記最小閾値を下回る場合、
故障時の前の前記ＤＳＬリンクに関連する雑音と前記故障時の後の前記ＤＳＬリンクに関連する雑音とを比較するステップと、
前記故障時の前及び後の前記雑音間の差異が閾値を超える場合、次いで雑音の前記差異を前記ＤＳＬリンクに関連する固定雑音として特性化するステップと、
前記故障時の前及び後の前記雑音間の差異が前記閾値を下回る場合、前記故障が前記ＤＳＬリンクへの電力損失又は重大なインパルス雑音イベントに関連するかどうかを調査し、それに従って雑音の前記差異を特性化するステップと、
前記ＤＳＬリンクに関連する前記雑音の前記特性化を記録するステップと、
を実行させる命令を含む、物品。
【請求項２５】
前記コンピュータシステムによって実行されるときに、前記コンピュータシステムに前記データに基づいて前記ＤＳＬリンクの故障時を推定するステップを実行させる命令をさらに備え、かつ故障時の前の前記ＤＳＬリンクに関連する雑音と前記故障時の後の前記ＤＳＬリンクに関連する雑音とを比較するステップに関する命令は、前記推定される故障時の前の前記ＤＳＬリンクに関連する雑音と前記推定される故障時の後の前記ＤＳＬリンクに関連する雑音とを比較するステップに関する命令を備える、請求項２４に記載の製造業者の物品。
【請求項２６】
前記コンピュータシステムによって実行されるときに、前記コンピュータシステムに経時的な前記受信されるデータの分布を評価するステップを実行させる命令をさらに備え、かつ前記データが、最小閾値を上回る又は下回る前記ＤＳＬリンクの安定性のレベルを示すかどうかを決定するステップは、前記データの分布が、最小閾値を上回る又は下回る前記ＤＳＬリンクの安定性のレベルを示すかどうかを決定するステップを備える、請求項２４に記載の製造業者の物品。
【請求項２７】
前記コンピュータシステムによって実行されるときに、前記コンピュータシステムに前記ＤＳＬリンクに関連する前記雑音の前記記録される特性化に応答して前記ＤＳＬリンクを再構成するステップを実行させる命令をさらに備る、請求項２４に記載の製造業者の物品。
【請求項２８】
前記コンピュータシステムによって実行されるときに、前記コンピュータシステムに以下の、
性能監視データの前記分布が、最小閾値を上回る又は下回る前記ＤＳＬリンクの品質のレベルを示すかどうかを決定するステップと、
前記ＤＳＬリンクの前記品質のレベルが前記最小閾値を下回る場合、
前記ＤＳＬリンクに関連する任意のインパルス雑音イベントが断続的または持続的であるかどうかを特性化するステップと、
前記ＤＳＬリンクに関連する前記インパルス雑音イベントの前記特性化を記録するステップと、
を実行させる命令をさらに備る、請求項２４に記載の製造業者の物品。
【請求項２９】
前記ＤＳＬリンクに関連する前記インパルス雑音イベントの前記特性化を記録するステップに関する命令は、前記インパルス雑音イベントの各々に関連する日付、時間、継続期間、及び影響を受ける周波数のうちの少なくとも１つを記録するステップに関する命令をさらに備える、請求項２８に記載の製造業者の物品。
【請求項３０】
前記コンピュータシステムによって実行されるときに、前記コンピュータシステムにインパルス雑音イベントの前記記録される特性化に応答して前記ＤＳＬリンクを再構成するステップを実行させる命令をさらに備る、請求項２８に記載の製造業者の物品。
【請求項３１】
ＤＳＬリンクに関連する雑音を特性化する装置であって、
ＤＳＬリンクの安定性のレベルを示すデータを受信する収集手段と、
前記データが、最小閾値を上回る又は下回る前記ＤＳＬリンクの安定性のレベルを示すかどうかを決定し、
前記ＤＳＬリンクの安定性の前記レベルが前記最小閾値を下回る場合、
故障時の前の前記ＤＳＬリンクに関連する雑音と前記故障時の後の前記ＤＳＬリンクに関連する雑音とを比較し、
前記故障時の前及び後の前記雑音間の差異が閾値を超える場合、次いで雑音の前記差異を前記ＤＳＬリンクに関連する固定雑音として特性化し、
前記故障時の前及び後の前記雑音間の差異が前記閾値を下回る場合、前記故障が前記ＤＳＬリンクへの電力損失又は重大なインパルス雑音イベントに関連するかどうかを調査し、それに従って雑音の前記差異を特性化し、かつ
前記ＤＳＬリンクに関連する前記雑音の前記特性化を記録する解析手段と、
を備える、装置。
【請求項３２】
前記解析手段は、前記データに基づいて前記ＤＳＬリンクの故障時を推定する手段をさらに備え、かつ故障時の前の前記ＤＳＬリンクに関連する雑音と前記故障時の後の前記ＤＳＬリンクに関連する雑音とを比較する前記解析手段は、前記推定される故障時の前の前記ＤＳＬリンクに関連する雑音と前記推定される故障時の後の前記ＤＳＬリンクに関連する雑音とを比較する解析手段を備える、請求項３１に記載の装置。
【請求項３３】
前記ＤＳＬリンクに結合されるＤＳＬレシーバのデコーダの平均２乗誤差、及び信号対雑音比（ＳＮＲ）マージンのうちの少なくとも１つに従って、前記雑音が測定される、請求項３１に記載の装置。
【請求項３４】
前記ＤＳＬリンクに関連する前記雑音の前記記録される特性化に応答して前記ＤＳＬリンクを再構成する手段をさらに備える、請求項３１に記載の装置。
【請求項３５】
前記収集手段はさらに、前記ＤＳＬリンクの品質のレベルを示す性能監視データの分布を受信し、
前記解析手段はさらに、
前記性能監視データの分布が、最小閾値を上回る又は下回る前記ＤＳＬリンクの前記品質のレベルを示すかどうかを決定し、
前記ＤＳＬリンクの前記品質のレベルが前記最小閾値を下回る場合、
前記ＤＳＬリンクに関連する任意のインパルス雑音イベントが断続的または持続的であるかどうかを特性化し、
前記ＤＳＬリンクに関連する前記インパルス雑音イベントの前記特性化を記録する、請求項３１に記載の装置。
【請求項３６】
前記性能監視データは、チャネル、回線、または上位層の性能監視データのうちの少なくとも１つを備える、請求項３５に記載の装置。
【請求項３７】
前記ＤＳＬリンクに関連する任意のインパルス雑音イベントが断続的または持続的であるかどうかを特性化する前記解析手段は、前記インパルス雑音イベントの継続期間を断続的又は持続的インパルス雑音イベントと決定する、請求項３５に記載の装置。
【請求項３８】
インパルス雑音イベントの前記記録される特性化に応答して前記ＤＳＬリンクを再構成する手段をさらに備える、請求項３５に記載の装置。
【請求項３９】
前記ＤＳＬリンクに関連する前記インパルス雑音イベントが断続的として特性化される場合、前記ＤＳＬリンクを再構成する前記手段は、前記ＤＳＬリンクに対するインパルス雑音保護に関連する設定を増加させる、請求項３８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してデジタル通信システムの品質と安定性を分析し改善するための方法及び装置に関する。より詳細には、本発明は、ＤＳＬシステムにおけるリンク故障及びエラーを分析しかつ低減させることに関する。
【０００２】
（関連出願の相互参照）
本願は、２００６年７月３１日に提出され、ＤＳＬ  Ｓｙｓｔｅｍと題された米国仮特許出願第６０／８３４４３６号への優先権を主張する。
【０００３】
本願は、２００４年３月８日に提出され、Ａｄａｐｔｉｖｅ  Ｃｏｄｅｗｏｒｄ  Ｍａｎａｇｅｍｅｎｔと題された米国特許出願第１０／７９５５９３号に関連する。
【０００４】
本願は、２００４年４月２日に提出され、ＤＳＬ  Ｓｙｓｔｅｍ  Ｅｓｔｉｍａｔｉｏｎ  ａｎｄ  Ｐａｒａｍｅｔｅｒ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎと題された米国特許出願第１０／８１７１２８号に関連する。
【０００５】
本願は、２００６年７月８日に提出され、Ａｄａｐｔｉｖｅ  Ｍａｒｇｉｎ  ａｎｄ  Ｂａｎｄ  Ｃｏｎｔｒｏｌと題された特許協力条約（ＰＣＴ）出願第ＵＳ２００６／０２６７９６号に関連する。
【背景技術】
【０００６】
デジタル加入者回線（ＤＳＬ）技術は、既存の電話加入者回線（ループ及び／又は銅設備（ｃｏｐｐｅｒ  ｐｌａｎｔ）とも呼ばれる）上でのデジタル通信のために、潜在的に大きな帯域幅を提供する。加入電話回線は、音声帯域のアナログ通信だけのための当初の設計にもかかわらず、この帯域幅を提供することが出来る。特に、非対称ＤＳＬ（ＡＤＳＬ）及びＶＤＳＬ（ｖｅｒｙ−ｈｉｇｈ−ｓｐｅｅｄ  ＤＳＬ）は、加入者回線の各端において、モデム（通常は、トランスミッタ及びレシーバの両方として機能するトランシーバ）のトレーニング及び初期化の間に決定されたチャネル状態に合わせて調整可能な、複数のビットを各トーン（又は、副搬送波）に割り当てる、ディスクリートマルチトーン（ＤＭＴ）回線コードを使用することによって、加入者回線の特性に合わせて調整することが可能である。ＤＳＬシステムはベクトル化技術を使用することが出来る。すなわち、結合トランスミッタ及び／又は結合レシーバの信号処理は複数のペアの間で実行され、クロストーク干渉の影響を低減させることが出来、ひいては性能を改善することが出来る。
【０００７】
ＤＳＬシステムはさらに、ＤＳＬリンク故障又はリンクエラーを引き起こし得るＤＳＬリンクの不安定性及び／又は低いリンクの品質の発生の原因を決定し、リンクの安定性及び／又はリンクの品質を改善するための手段を講じることにより利益を享受するであろう。
【発明の概要】
【０００８】
本発明の実施形態は、データを収集し、ＤＳＬリンク故障又はＤＳＬリンクエラーを引き起こす原因を特性化するためのデータの解析を行い、原因が決定されると、故障及び／又はエラーを低減させるためにＤＳＬリンクを再構成する手段及び方法を備える。
【図面の簡単な説明】
【０００９】
本発明の実施形態は、例示の方法であって、添付の図面に限定の方法で説明されるのではない。添付の図面では、同じ参照は同様の要素を示す。この開示における「１の（ａｎ）」又は「１つの（ｏｎｅ）」実施形態への参照は必ずしも同じ実施形態に対するものではなく、このような参照は「少なくとも１つの」を意味するものであることに留意すべきである。
【図１】ＩＴＵ−Ｔ  Ｇ．９９７．１標準からのＤＳＬシステムのための参照モデル略図を示す。
【図２】ＤＳＬシステムの一般的な概念図の説明であって、システムの配置と動作を示す。
【図３Ａ】本発明の実施形態によるＤＳＬシステムと連通して結合されるＤＳＬオプティマイザの説明である。
【図３Ｂ】本発明の実施形態によるＤＳＬＡＭと結合して動作するＤＳＬオプティマイザの説明である。
【図４】本発明の１の実施形態による流れ図の説明である。
【図５】経時的なインパルス雑音の特性の説明である。
【図６】本発明の１の実施形態による流れ図の説明である。
【図７】本発明の実施形態による、インパルス雑音によって破損した可能性が高いＲＳ符号語内のバイトの位置の説明である。
【図８】本発明の１以上の実施形態によるユーザ及び／又はコントローラによって使用されるコンピュータシステムの説明である。
【発明を実施するための形態】
【００１０】
図１は、Ｇ．９９７．１標準（Ｇ．ｐｌｏａｍ）による参照モデルシステムを示す。このモデルは、ＡＤＳＬ１（Ｇ．９９２．１）、ＡＤＳＬ−Ｌｉｔｅ（Ｇ．９９２．２）、ＡＤＳＬ２（Ｇ．９９２．３）、ＡＤＳＬ２−Ｌｉｔｅ  Ｇ．９９２．４、ＡＤＳＬ２＋（Ｇ．９９２．５）及びＧ．９９３．１及びＧ．９９３２ＶＤＳＬ標準、さらにＧ．９９１．１及びＧ．９９１．２ＳＨＤＳＬ標準、全ての結合及び非結合のような、スプリッタを有し又は有し得ない様々な標準に適合する全てのＡＤＳＬシステムに適用される。このモデルは、当業者には周知のものである。
【００１１】
Ｇ．９９７．１標準は、Ｇ．９９７．１で定義されたクリア・エンベデッド・オペレーション・チャネル（ＥＯＣ）に基づく、ＡＤＳＬ転送システムのための物理層管理と、Ｇ．９９２．ｘ及びＧ．９９３．ｘ標準で定義されたインジケータビット及びＥＯＣメッセージの使用とを規定する。さらに、Ｇ．９９７．１は、構成、故障、及び性能管理のための、ネットワーク管理要素の内容も規定する。これらの機能の実行において、システムは、アクセスノード（ＡＮ）において入手可能な、様々な動作データを利用する。
【００１２】
図１では、ユーザの端末装置１１０はホームネットワーク１１２に結合される。ホームネットワーク１１２は、同様にネットワーク終端装置（ＮＴ）１２０に結合される。ＮＴ１２０は、ｘＴＵ−Ｒ１２２（例えば、ＡＤＳＬ標準の１つによって定義されるトランシーバ）又は他の任意の適切なネットワーク終端モデム、トランシーバ又は他の通信装置を有する。ＮＴ１２０はまた、管理エンティティ（ＭＥ）１２４も有する。ＭＥ１２４は、任意の適用可能な標準及び／又は他の基準に従って実行することが出来る、任意の適切なハードウェア装置、例えば、マイクロプロセッサ、マイクロコントローラ、又はファームウェア若しくはハードウェアの回路状態機械（ｃｉｒｃｕｉｔ  ｓｔａｔｅ  ｍａｃｈｉｎｅ）であり得る。ＭＥ１２４は、その管理情報ベース（ＭＩＢ）に性能データを収集し、保存する。ＭＩＢは、各ＭＥによって維持される情報のデータベースである。ＭＩＢには、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、管理者コンソール／プログラムへ提供するためにネットワーク装置から情報を集めるために使用される管理プロトコルのようなネットワーク管理プロトコルを介して、又はプログラム応答のために使用される周知のコマンド言語であるＴＬ１コマンド及び通信ネットワーク要素間のコマンドを介してアクセスすることが出来る。
【００１３】
システム内の各ｘＴＵ−Ｒは、セントラルオフィス（ＣＯ）又は他の中央位置のｘＴＵ−Ｃに結合される。図１では、ｘＴＵ−Ｃ１４２は、ＣＯ１４６内のアクセスノード（ＡＮ）１４０に位置する。ＭＥ１４４は同様に、ｘＴＵ−Ｃ１４２に関する性能データのＭＩＢを維持する。ＡＮ１４０は、当業者には理解されるように、広帯域ネットワーク１７０又は他のネットワークに結合されてもよい。ｘＴＵ−Ｒ１２２及びｘＴＵ−Ｃ１４２は、ループ１３０によって互いに結合される。通常、ループ１３０は、ＡＤＳＬ及びＶＤＳＬの場合には、他の通信サービスも搬送する電話ツイストペア線である。
【００１４】
図１に示すインタフェースのうちのいくつかは、性能データの決定及び収集のために使用される。Ｑインタフェース１５５は、オペレータのネットワーク管理局（ＮＭＳ）１５０及びＡＮ１４０内のＭＥ１４４との間のインタフェースを提供する。Ｇ．９９７．１標準で規定される全てのパラメータは、Ｑインタフェース１５５において適用される。ＭＥ１４４内でサポートされる近端パラメータは、ｘＴＵ−Ｃ１４２から得ることが出来る。一方、ｘＴＵ−Ｒ１２２からの遠端パラメータは、Ｕインタフェース上の２つのインタフェースのうちのいずれかによって得ることが出来る。エンベデッドチャネル１３２を使用して送信され、かつＰＭＤ層において提供される、インジケータビット及びＥＯＣメッセージは、ｘＴＵ−Ｒ１２２パラメータをＭＥ１４４内で生成するために使用することが出来る。あるいは、ＭＥ１４４によって要求された場合に、ｘＴＵ−Ｒ１２２からパラメータを取得するために、オペレーション・アドミニストレーション・マネジメント（ＯＡＭ）チャネル及び適切なプロトコルを使用することが出来る。同様に、ｘＴＵ−Ｃ１４２からの遠端パラメータは、Ｕインタフェース上の２つのインタフェースのうちのいずれかによって得ることが出来る。ＰＭＤ層において提供される、インジケータビット及びＥＯＣメッセージは、ｘＴＵ−Ｃ１４２パラメータをＮＴ１２０のＭＥ１２２内で生成するために使用することが出来る。あるいは、ＭＥ１２４によって要求された場合に、ｘＴＵ−Ｃ１４２からパラメータを取得するために、ＯＡＭチャネル及び適切なプロトコルを使用することが出来る。
【００１５】
（本質的にループ１３０である）Ｕインタフェースにおいて、２つの管理インタフェースが、１つはｘＴＵ−Ｃ１４２（Ｕ−Ｃインタフェース１５７）において、かつ１つはｘＴＵ−Ｒ１２２（Ｕ−Ｒインタフェース１５８）において存在する。インタフェース１５７は、ｘＴＵ−Ｃ近端パラメータを、ｘＴＵ−Ｒ１２２がＵインタフェース１３０を越えて取得するために提供する。同様に、インタフェース１５８は、ｘＴＵ−Ｒ近端パラメータを、ｘＴＵ−Ｃ１４２がＵインタフェース１３０を越えて取得するために提供する。該当するパラメータは、使用されるトランシーバ標準（例えば、Ｇ．９９２．１又はＧ．９９２．２）に依存してもよい。
【００１６】
Ｇ．９９７．１標準は、Ｕインタフェースを横切る任意選択のＯＡＭ通信チャネルを規定する。このチャネルが実装されている場合、ｘＴＵ−Ｃ及びｘＴＵ−Ｒのペアは、物理層ＯＡＭメッセージを伝送するためにこのチャネルを使用してもよい。このようにして、このようなシステムのトランシーバ１２２、１４２は、これらの各々のＭＩＢ内に維持される様々な動作及び性能データを共有する。
【００１７】
ＡＤＳＬ  ＮＭＳに関するさらなる情報は、「ＡＤＳＬ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ」と題されたＤＳＬ  Ｆｏｒｕｍ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  ＴＲ−００５（ＡＤＳＬ  Ｆｏｒｕｍ、１９９８年３月付け）に見出すことが出来、これは当業者には周知である。また上述のように、「ＣＰＥ  ＷＡＮ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ」と題されたＤＳＬ  Ｆｏｒｕｍ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  ＴＲ−０６９（２００４年５月付け）も当業者には周知である。最後に、「ＬＡＮ−Ｓｉｄｅ  ＤＳＬ  ＣＰＥ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」と題されたＤＳＬ  Ｆｏｒｕｍ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  ＴＲ−０６４（２００４年５月付け）は当業者には周知である。これらの文献は、ＣＰＥ側管理のための様々な状況に対処する。ＶＤＳＬに関するさらなる情報は、ＩＴＵ標準Ｇ．９９３．１（「ＶＤＳＬ１」と呼ばれることもある）、及びＩＴＵ標準Ｇ．９９３．２（「ＶＤＳＬ２」と呼ばれることもある）、並びに、進行中のいくつかのＤＳＬ  Ｆｏｒｕｍ作業テキストに見出すことが出来、これらは全て当業者に知られている。追加情報は、「ＶＤＳＬ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ」と題されたＤＳＬ  ＦｏｒｕｍのＴｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  ＴＲ−０５７（旧ＷＴ−０６８ｖ５）（２００３年２月）、及び「ＦＳ−ＶＤＳＬ  ＥＭＳ  ｔｏ  ＮＭＳ  Ｉｎｔｅｒｆａｃｅ  Ｆｕｎｃｔｉｏｎａｌ  Ｒｅｑｕｉｒｅｍｅｎｔｓ」と題されたＴｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  ＴＲ−０６５（２００４年３月）、並びに、ＶＤＳＬ１及びＶＤＳＬ２  ＭＩＢ要素のためのＩＴＵ標準Ｇ．９９７．１の改訂版、又はＡＴＩＳ  Ｄｙｎａｍｉｃ  Ｓｐｅｃｔｒｕｍ  Ｍａｎａｇｅｍｅｎｔ  Ｒｅｐｏｒｔ、ＡＴＩＳ−０６００００７で入手可能である。さらなる情報は、ＤＳＬ  Ｆｏｒｕｍ草稿作業テキストである、「Ｔｅｓｔｉｎｇ  ＆  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ：  ＡＤＳＬ２／ＡＤＳＬ２ｐｌｕｓ  Ｆｕｎｃｔｉｏｎａｌｉｔｙ  Ｔｅｓｔ  Ｐｌａｎ」と題されたＷＴ−１０５及び「Ｔｅｓｔｉｎｇ  ＆  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ：  ＶＤＳＬ２  Ｆｕｎｃｔｉｏｎａｌｉｔｙ  Ｔｅｓｔ  Ｐｌａｎ」と題されたＷＴ−１１５及び「ＤＳＬ  Ｈｏｍｅ  Ｔｅｃｈｎｉｃａｌ：  ＴＲ−０６９  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｇｕｉｄｅｌｉｎｅｓ」と題されたＷＴ−１２１に見出すことが出来る。
【００１８】
当業者には理解されるように、これらの文書に記載されたパラメータのうちの少なくともいくつかは、本発明の実施形態と関連して使用される。さらに、システムの記載のうちの少なくともいくつかは、本発明の実施形態に同様に適用することが出来る。ＤＳＬ  ＮＭＳから入手可能な様々なタイプの動作データ及び情報は、それらの中に見出すことが出来る。その他のことが当業者に知られていてもよい。多数のトランシーバのペアが動作中で及び／又は利用可能である、ＤＳＬ設備の典型的な接続形態では、各加入者ループの一部は、複数ペアのバインダ（又はバンドル）内の他のユーザのループと共に用いられる。ペデスタルの後、カスタマ構内設備（ＣＰＥ）の非常に近くで、ループは引き込み線の形態を取り、バンドルを出る。従って、加入者ループは、２つの異なる環境を横切る。ループの一部はバインダの内部に配置されてもよく、そこでは、ループは外部の電磁インタフェースからは遮蔽される場合があるが、バインダ内の他のループへの近接のためクロストークが発生しやすい。ペデスタルの後、引き込み線のほとんどが他のペアから遠く離れているため、引き込み線はクロストークには影響されないことが多いが、引き込み線は遮蔽されていないため、伝送は電磁妨害によって、より大きく損なわれる可能性もある。多くの引き込み線は、それらの中に２〜８本のツイストペア線を有し、家庭への複数のサービス、又はそれらの回線の結合（１つのサービスの多重化及び逆多重化）の状況においては、引き込み線セグメント内で、それらの回線間に、追加の相当量のクロストークが発生する可能性がある。
【００１９】
一般的な、例示的ＤＳＬ配置シナリオを、図２に示す。合計（Ｌ＋Ｍ）個のユーザ２９１、２９２の全ての加入者ループは、少なくとも１つの共通バインダを通過する。各ユーザは、専用線を介してセントラルオフィス２１０、２２０に接続される。ただし、各加入者ループは、異なる環境及び媒体を通過してもよい。図２では、Ｌ個のユーザ２９１が、光ファイバ２１３と銅ツイストペア線２１７との組み合わせを使用して、ＣＯ２１０に接続されており、これは一般に、ファイバ・ツー・ザ・キャビネット（ＦＴＴＣａｂ）又はファイバ・ツー・ザ・カーブと呼ばれる。ＣＯ２１０内のトランシーバ２１１からの信号は、ＣＯ２１０及び光ネットワークユニット（ＯＮＵ）２１８内の、光回線終端装置２１２及び光ネットワーク終端装置２１５によって変換される。ＯＮＵ２１８内のモデム２１６は、ＯＮＵ２１８及びユーザ２９１の間の信号のためのトランシーバとして機能を果たす。
【００２０】
残りのＭ個のユーザ２９２のループ２２７は、銅ツイストペア線のみであり、このシナリオは、ファイバ・ツー・ザ・エクスチェンジ（ＦＴＴＥｘ）と呼ばれる。可能であり、かつ経済的に実現可能である限り、ＦＴＴＣａｂの方がＦＴＴＥｘよりも好ましく、その理由は、それにより、加入者ループの銅部分の長さが減少し、従って、達成可能な速度が増加するからである。ＦＴＴＣａｂループの存在は、ＦＴＴＥｘループに問題を引き起こす可能性がある。さらに、ＦＴＴＣａｂは、将来、ますます普及した接続形態となることが期待される。このタイプの接続形態は、相当量のクロストーク干渉を引き起こす可能性があり、また、様々なユーザの回線が、それらが動作する特定の環境のため、異なるデータ搬送及び実行能力を有することを意味する場合がある。接続形態は、ファイバ供給の「キャビネット」回線及び交換回線が、同じバインダ内で混合されることが可能であるようなものであってもよい。
【００２１】
図２から分かるように、ＣＯ２２０からユーザ２９２への回線は、ＣＯ２１０及びユーザ２９１間の回線によって使用されていない、バインダ２２２を共有する。さらに、別のバインダ２４０が、ＣＯ２１０及びＣＯ２２０、並びにそれらの各ユーザ２９１、２９２の間の全ての回線に共通している。
【００２２】
図３Ａに示す本発明の１実施形態によれば、アナライザ３００は、システムの使用を最適化し、場合によっては制御するに当たって、ユーザ及び／又は１つ以上のシステムのオペレータ若しくはプロバイダを支援するコントローラ３１０（例えば、ＤＳＬオプティマイザ、動的スペクトルマネージャ、又は動的スペクトル管理センタ）として１つ以上のＤＳＬシステムを監視する独立したエンティティの一部であってもよい。（動的スペクトルマネージャは、動的スペクトル管理センタ、ＤＳＭセンタ、ＤＳＬオプティマイザ、スペクトルメンテナンスセンタ、又はＳＭＣと呼ばれることもある）。いくつかの実施形態では、コントローラ３１０は、ＣＯ又は他の場所からの複数のＤＳＬ回線を操作するインカンベント・ローカル・エクスチェンジ・キャリア（ＩＬＥＣ）又はコンペティティブ・ローカル・エクスチェンジ・キャリア（ＣＬＥＣ）によって操作されてもよい。他の実施形態では、「スマート」モデム装置が、ユーザ位置、セントラルオフィス又は他の何らかの単独の位置でモデムと統合される（例えば、プロセッサ又はメモリを有する）コントローラを有してもよい。図３Ａの破線３４６から分かるように、コントローラ３１０はＣＯ１４６内にあり、若しくは一部であってもよく、又はＣＯ１４６及びシステム内で動作する任意の企業の外部にあってこれらから独立してもよい。さらに、コントローラ３１０は、複数のＣＯに結合され、及び／又はそれを制御することが出来る。同様に、コントローラ３１０の構成部品は、同じ場所にあり、かつ／又は同じ装備であってもよく、かつ／又は代わりに異なる場所でコントローラによってアクセスされてもよい。
【００２３】
図３Ａの例示的な実施形態では、アナライザ３００は（所望の場合には監視も行ってよい）収集手段３２０及び解析手段３４０を有する。図３Ａで分かるように、収集及び／又は監視手段３２０は、例えば、ＮＭＳ１５０、ＡＮ１４０におけるＭＥ１４４、及び／又はＭＥ１４４によって維持されるＭＩＢ１４８のような、ＤＳＬシステムへの内部のソースに結合されてよく、かつそれらを通じて、かつそれらからデータを収集してもよい。データはまた、広帯域ネットワーク１７０（例えば、ＴＣＰ／ＩＰプロトコル又は所定のＤＳＬシステム内の通常の内部データ通信システムの外部の他の手段）を通じて手段３２０によって外部ソースから収集されてもよい。また、収集手段３２０は、配置情報、接続形態情報、クロストーク結合などのバインダレベルの情報、又はビットローディング及び電力割当のようなモデム能力に関する情報、並びにサービス優先度を記憶する、１つ以上のデータベース又は他のソース３４８へのアクセスを有してもよい。ＥＭＳ帯域幅が制限されている場合、又はＥＭＳが非協力的な場合（例えば、設備製造業者がその設備の内部で管理を行うことを望むため、報告される管理データを遮ることにより）、コントローラは、インターネット上でｘＴＵ−Ｒから、又はインターネット上でｘＴＵ−Ｃからでさえ、動作データを収集してもよい。動作データは、様々なソース自身から収集している可能性があるサービスプロバイダのＮＭＳから収集することも出来る。
【００２４】
解析手段３４０及び／又は監視／収集手段３２０はまた、アナライザ３００又はコントローラ３１０の一部である又は一部でないかもしれないデータベース又はメモリのような、パラメータ履歴及び／又は他の関連する情報のソース３４５に結合されてもよい。１つ以上のアナライザの接続により、アナライザ３００は動作データを収集することが出来る。データは、一度に（例えば、単独のトランシーバの訓練中に）又は経時的に収集されてもよい。場合によっては、監視手段３２０は、周期的にデータを収集してもよいが、データを要求に応じて又は他の何らかの非周期的な方式でデータを収集することも可能である。このようにして、所望の場合に、アナライザ３００はそのユーザ及び回線データを更新することが出来る。
【００２５】
モデムが雑音効果を減少させるのを支援するため１つ以上のモデムに指示を送る必要があるかどうかを決定するために、解析手段３４０は送られてくるデータを解析する能力を有する。アナライザ３００の解析手段３４０は、コントローラ３１０内の指示信号生成手段３５０に結合される。信号ジェネレータ３５０は、モデムに使用される解析手段３４０によって生成されるパラメータ値を受け入れるように構成される。そのパラメータ値は、動作データに基づき、かつ１つ以上のモデムが、雑音を低減させ、安定性を改善し、故障を排除し、エラーを減少させるのを支援するために計算される。信号ジェネレータ３５０は、通信システム（例えば、ＡＴＵ−ＣのようなＡＤＳＬトランシーバ）のユーザへ指示信号を送信するように構成される。破線３４７によって示されるように、指示信号生成手段３５０は、アナライザ３００の一部であり又はなくてもよく、かつ／又はコンピュータシステムのような同じハードウェア内に実装されてもよい。指示信号ジェネレータ３５０はモデムペアにおける１つ以上のパラメータ値を調整する手段を構成する。
【００２６】
本発明の他の実施形態が図３Ｂに示される。ＤＳＬオプティマイザ３６５は、ＤＳＬＡＭ３８５又は他のＤＳＬシステム構成部品（例えば、ＲＴ、ＯＮＵ／ＬＴなど）上で及び／又はこれらと関連して動作する。これらのうちのどちらか又は両方は、電気通信会社（「テルコ」）の施設３９５上にあってもよい。ＤＳＬオプティマイザ３６５は、ＤＳＬオプティマイザ３６５について及びそれのために動作データを収集し、組立て、調整し、操作し、かつ／又は供給することが出来るデータモジュール３８０を有する。モジュール３８０は、ＰＣ又はワークステーションなどの１つ以上のコンピュータに実装することが出来る。モジュール３８０からのデータは、解析（例えば、所与の通信回線、通信システムへの制御及び動作の変化、報告されるモデム能力などに基づいて、プロファイルの可用性、実装される遷移など）のためにＤＳＭサーバモジュール３７０に供給される。情報はまた、テルコに関連する又は関連しない場合があるライブラリ又はデータベース３７５から入手可能であってもよい。プロファイルセレクタ３９０は、通信システムの動作に影響を与える信号を実装するために使用されてもよい。このような決定は、当業者には理解されるように、ＤＳＭサーバ３７０又は他の何らかの適切な方法によって行われてもよい。セレクタ３９０によって選択される動作モードは、ＤＳＬＡＭ３８５及び／又は他の何らかの適切なＤＳＬシステム構成部品の設備に実装される。このような設備は、加入者宅内設備３９９のようなＤＳＬ設備に結合されてもよい。装置３８５は、ＤＳＬオプティマイザ３６５によって考慮される、許容されるプロファイル、性能強化などに基づいて任意の命令される変更を実装するために使用されてもよい。図３Ｂのシステムは、当業者には理解されるように図３Ａのシステムに類似する方法で動作することが可能であるが、本発明の実施形態をさらに実装する間に、差分は達成することが出来る。
【００２７】
収集手段３２０又はデータモジュール３８０は、第２のコントローラ又はＤＳＬオプティマイザの対応するモジュールに結合されてもよい。このようにして、他のＤＳＬ回線が同じＤＳＬオプティマイザ、ＤＳＭセンタ又はＳＭＣによって制御されない場合であっても、動作データを他のＤＳＬ回線から収集することが出来る。反対に、調整者、サービスプロバイダ及び／又は他のＤＳＬオプティマイザによって適切に使用されるために、コントローラ３１０又はＤＳＬオプティマイザ３６５は、公衆又は個人のデータベース（例えば、ＤＳＬ管理エンティティが適切にデータを共有することが出来る公衆又は個人に制御されるウェブサイト又は接続）へのそれ自身のＤＳＬ回線の動作データを提供してもよい。当業者には理解されるように、コントローラが完全に独立したエンティティである場合（すなわち、ＣＯ内の企業所有のかつ／又は企業運用の回線によって所有されかつ／又は運用されるものではない場合）、ＤＳＬシステムの構成及び動作情報の大部分は入手出来ない可能性がある。ＣＬＥＣ又はＩＬＥＣがコントローラ３１０として動作及び／又は機能する場合であっても、このデータの大部分は不明である可能性がある。
【００２８】
本発明のいくつかの実施形態では、アナライザ３００はＰＣ又はワークステーションなど（これらの例の１つは、図８に関連して開示される）のようなコンピュータに実装される。収集手段３２０、解析手段３４０及び／又は指示信号生成手段３５０は、当業者には理解されるように、ソフトウェアモジュール、ハードウェアモジュール又は両者の組み合わせであってもよい。これらの構成部品は、全て同じコンピュータシステム内に存在してもよいし、例えば、別個の装置であってもよい。多数の回線の管理のために、データベースが、回線及びコントローラによって生成されるデータの量を管理するために導入され、かつ使用されてもよい。
【００２９】
本発明の実施形態は、雑音特性化及び雑音低減の２つの部分に特徴付けられ得る。雑音特性化の検討は次に提供され、雑音低減の検討はその後に続く。
【００３０】
（雑音特性化）
図４を参照して、本発明の１実施形態が説明される。モジュール４０５において、データが収集される。データ収集は、図３Ａ及び図３Ｂを参照して上述のように行うことが出来る。データ収集は複数回行われる可能性がある。収集されるデータは、瞬時値（データ収集時の値）、又は値の履歴（データ収集以前の様々な時に取得される値）を有してもよい。カウンタを表すデータ（例えば、コード違反（ＣＶ）、エラー秒数（ＥＳ））は、ベクトルとして表されてもよく、ベクトルの各要素は既知の時間間隔内のカウントである。データは、セントラルオフィス（ＣＯ側、又は場合によっては近端、ＮＥとも呼ばれる）、又は顧客宅内（ＣＰ側、又は場合によっては遠端、ＦＥと呼ばれる）に関連するパラメータを有することが出来る。
【００３１】
本発明の１実施形態では、収集するパラメータは以下を有してもよい。
【００３２】
Ｇ．９９７．１から、
回線一覧（Line inventory)
−  Ｇ．９９４．１  ベンダＩＤ
−  システムベンダＩＤ
−  バージョン番号
−  シリアル番号
チャネルの試験、診断及び状態パラメータ
−  実際のデータ速度
−  実際のインターリーブ遅延
−  実際の構成者の設定
−  ＮＦＥＣ、ＲＳ符号語サイズ
−  ＲＦＥＣ、ＲＳパリティバイト
−  ＬＳＹＭＢ、記号（ｓｙｍｂｏｌ）ごとのビット
−  ＩＮＴＬＶＤＥＰＴＨ、インターリーバの深さ
−  ＩＮＴＬＶＢＬＯＣＫ、インターリーバのブロックサイズ
回線の試験、診断及び状態パラメータ
−  ＬＡＴＮ、回線減衰
−  ＳＡＴＮ、信号減衰
−  ＳＮＲＭ、ＳＮＲマージン
−  ＡＣＴＰＳＤ、実際のＰＳＤレベル
−  ＵＰＢＯＫＬＥ、電気的長さ
−  ＡＣＴＡＴＰ、実際の集約送信電力
−  ＨＬＩＮ、複合チャネル応答
−  ＨＬＯＧ、チャネル応答の大きさ
−  ＱＬＮ、クワイエットライン雑音
−  ＳＮＲ
−  ＢＩＴＳ
−  ＧＡＩＮＳ
−  ＴＳＳ、送信スペクトル形成
−  ＭＲＥＦＰＳＤ、参照ＰＳＤ
−  ＴＲＥＬＬＩＳ
−  ＡＣＴＵＡＬＣＥ、巡回拡張長
チャネル性能監視パラメータ
−  ＣＶ、コード違反
−  ＦＥＣ、前方誤り訂正
回線性能監視パラメータ
−  ＦＥＣＳ、ＦＥＣ秒数
−  ＥＳ、エラー秒数
−  ＳＥＳ、重大なエラー秒数
−  ＬＯＳＳ、信号損失（ｌｏｓｓ−ｏｆ−ｓｉｇｎａｌ）秒数
−  ＵＡＳ、無効時間秒数
−  完全初期化（又はＲＥＩＮＩＴ）
−  初期化失敗
回線故障
−  ＬＯＳ、信号損失故障
−  ＬＯＦ、フレーム損失故障
−  ＬＰＲ、電力損失故障
−  ＬＩＮＩＴ、回線初期化故障
【００３３】
ＷＴ−１３５第４改訂版から、
Ｏｂｊｅｃｔ．ＳＴＢＳｅｒｖｉｃｅ．｛ｉ｝．ＡＶＳｔｒｅａｍｓ．−ＡＶＳｔｒｅａｍ．｛ｉ｝．ＩＰ．ＲＴＰ．Ｓｔａｔｓ
−  ＰａｃｋｅｔｓＲｅｃｅｉｖｅｄ
−  ＢｙｔｅｓＲｅｃｉｅｖｅｄ
−  ＰａｃｋｅｔｓＬｏｓｔ
−  ＦｒａｃｔｉｏｎＬｏｓｔ
−  ＣｏｒｒｕｐｔｅｄＰａｃｋｅｔｓ
−  Ｏｖｅｒｒｕｎｓ
−  Ｕｎｄｅｒｒｕｎｓ
−  ＲｅｃｅｉｖｅＩｎｔｅｒａｒｒｉｖａｌＪｉｔｔｅｒ
Ｏｂｊｅｃｔ．ＳＴＢＳｅｒｖｉｃｅ．｛ｉ｝．ＡＶＳｔｒｅａｍ．−ＡＶＳｔｒｅａｍ．｛ｉ｝．ＭＰＥＧ２ＴＳ．Ｓｔａｔｓ
−  ＰａｃｋｅｔｓＲｅｃｅｉｖｅｄ
−  ＰａｃｋｅｔＤｉｓｃｏｎｔｉｎｕｉｔｙＣｏｕｎｔｅｒ
−  Ｏｖｅｒｒｕｎｓ
−  Ｕｎｄｅｒｒｕｎｓ
【００３４】
ダイナミック・スペクトル・マネジメント・テクニカル・レポートからの追加のパラメータ
−  ＭＳＥ、トーンごとの平均２乗誤差（ｍｅａｎ−ｓｑｕａｒｅ−ｅｒｒｏｒ）
−  Ｐｂ、トーンごとのエラーの可能性
−  Ｘｌｏｇ、Ｘｌｉｎ、クロストーク結合
−  ＭＡＲＧＩＮ［ｉ］、トーンごとのマージン
【００３５】
追加のパラメータ
−  ＳＯＳ通知／イベント／カウンタ（データ速度の突然の減少となる）
−  ＳＲＡ（シームレス・レート・アダプテーション）通知／イベント／カウンタ
−  故障原因
−  ビットスワップ（ｂｉｔ−ｓｗａｐ）カウント
−  ビット分布の統計（例えば、トーンごとの最小最大中央値平均（ｍｉｎ−ｍａｘ−ｍｅｄｉａｎ−ａｖｅｒａｇｅ））
−  雑音ピーク対平均（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ）比（また時間領域内の雑音ピーク）
−  エコー応答
−  ループインピーダンス
−  インパルス雑音幅（又は関連する統計）
−  インパルス雑音期間（又は関連する統計）
−  インパルス雑音イベント継続期間（又は関連する統計）
−  停止、欠落パケット、エラー潜在パケット、再送パケット、欠落／補間ＭＰＥＧブロック、バッファオーバフロー／アンダーフロー、再送信などのような、ＩＰＴＶ又はＭＰＥＧ配信統計
【００３６】
インパルス雑音は図５に示されるように経時的に特性化され、そこでは、イベント継続期間５２０内の各雑音パルス５１０は幅５３０及び期間５４０を有する。これらの量の統計（例えば、ヒストグラム、最小、最大、中央値、ｘ％最悪状況）は、計算され、かつ報告されることが可能である。
【００３７】
モジュール４１０はリンクの安定性及びリンクの品質を評価する。リンクの安定性を評価するために、上記の回線故障、完全な／失敗した初期化（再訓練としても知られる）、及び無効時間秒数（ＵＡＳ）のようなパラメータが、図３Ａ及び３Ｂ並びに図４のモジュール４０５に関して記載されたように取得される。いくつかの実施形態では、経時的なこれらの量の分布が評価される。例えば、ＬＯＳが１５分間隔でカウントされる場合、１日の総測定期間に対して、９６個のＬＯＳがカウントされる。ＬＯＳの分布を評価することは、どのくらいの間隔でＬＯＳのカウントが０に等しかったか、どのくらいの間隔でＬＯＳのカウントが１に等しかったか、などを評価することを意味する。
【００３８】
このような分布からリンクの安定性レベルは決定される。１実施形態では、例えば、以下の全ての条件が有効である場合、リンクの安定性は良好であると宣言される。  
−  間隔の９０％について、ＬＯＳ＝０
−  間隔の９９％について、ＬＯＳ＜＝１
−  間隔の１００％について、ＬＯＳ＜＝２
【００３９】
以下の全ての条件が有効である場合、リンクの安定性は中程度よりも良いと宣言される。  
−  間隔の８０％について、ＬＯＳ＝０
−  間隔の９０％について、ＬＯＳ＜＝１
−  間隔の９５％について、ＬＯＳ＜＝２
−  間隔の１００％について、ＬＯＳ＜＝４
【００４０】
他の全ての場合において、リンクの安定性は悪いと宣言される。
【００４１】
リンクの安定性は、複数のパラメータに対して上記のような条件を組み合わることによって決定されてもよい。
【００４２】
図４のモジュール４２０は、リンク故障の前及び後の雑音を比較する。リンクの安定性が不十分であると宣言される場合、次いで不十分なリンクの安定性を発生させている雑音／撹乱の種類に関してさらなる決定がなされる。雑音／撹乱の種類を決定する方法は、リンク故障の前及びリンク故障の後のＤＳＬレシーバにおける雑音を比較することでなされる。（リンク故障は、いわゆる「ＳＯＳイベント」又はＳＲＡイベントを有し、ＤＳＬレシーバ内のモデムは動作可能な状態を維持するが、データ速度が減少する。）測定された雑音の間の重大な差異は、雑音レベルの実質的な増大のためにリンク故障が生じたことを示唆する。リンク故障の前及び後の比較可能な雑音レベルは、雑音の増加以外の原因がリンク故障を導くことを示唆する。
【００４３】
より信頼出来る結論を出すために、このような比較は複数のリンク故障に対応する複数の期間にわたって行われる。例えば、ＬＯＳ（又は完全初期化）の記録は、リンク故障の時間を特定するために使用することが出来る。複数の雑音の測定結果は、リンク故障の前及び後の時間において取得することが出来る。リンク故障の総数のうちの所定の割合について雑音レベルの実質的な変化が観測される場合、雑音レベルの変化がリンク故障の原因であるとみなすことが出来る。
【００４４】
リンク故障前の雑音測定は、好ましくはリンク故障が起こる少なくとも数秒前に行われる。リンク故障後の雑音測定は、ＤＳＬリンクが再初期化された後（又はデータ速度を減少させるＳＯＳ若しくはＳＲＡプロシージャが終了した後）であり、かつ安定した状態（例えば、信号対雑音比（ＳＮＲ）マージンが安定している、ＣＶカウントが低いなど）にある場合に行われるべきである。
【００４５】
ＤＳＬレシーバの雑音を評価するための多くの技術が存在する。１つの方法は、レシーバが、そのデコーダの平均２乗誤差（ＭＳＥ）を報告することである。このようなエラーは、スライサの出力、トレリスデコーダの出力、又はＲＳデコーダの出力に対応することが可能である。
【００４６】
代替として、雑音は他のパラメータを使用して間接的に計算されてもよい。例えば、ＳＲＮ、ＨＬＯＧ（チャネル減衰）、ＭＲＥＦＰＳＤ（送信ＰＳＤ）及びＧＡＩＮＳ（ゲインスケーリング）がＶＤＳＬ２モデムによって報告される場合、次いでレシーバの平均２乗誤差は次の式によって推定することが出来る。
【００４７】
ＭＳＥ（ｄＢｍ／Ｈｚ）＝ＨＬＯＧ（ｄＢ）＋ＭＰＲＥＦＰＳＤ（ｄＢｍ／Ｈｚ）＋ＧＡＩＮＳ（ｄＢ）−ＳＮＲ（ｄＢ）
【００４８】
さらに他の代替方法によれば、雑音の測定としてＳＮＲマージンの報告される値を使用する。ＳＮＲマージンは、平均として又はトーンごとのどちらかを、及び故障前及び後の雑音を比較するためにそれを使用することが出来るどちらかの形式で報告されてもよい。
【００４９】
レシーバ雑音の推定のためのさらなる技術は、２００４年４月２日に提出され、２００５年７月９日に米国公報第２００５／０１２３０２７号として公開され、「ＤＳＬ  Ｓｙｓｔｅｍ  Ｅｓｔｉｍａｔｉｏｎ  ａｎｄ  Ｐａｒａｍｅｔｅｒ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ」と題された、関連する米国特許出願第１０／８１７，１２８号に見出すことが出来る。
【００５０】
一般的には、雑音の前及び後の間の差異に基づいて、雑音レベルの実質的な変化が決定される。差異は、異なる周波数に対応する１つ以上の値のベクトルである。１実施形態では、差異が所定の数の周波数点についての所定の閾値を超えることが検出される場合、実質的な差異が宣言される。重み係数が所定の周波数の差異値に適用されてもよい。
【００５１】
実質的な雑音変化の決定は、「第３のワイヤ（ｔｈｉｒｄ  ｗｉｒｅ）」の既知の問題を診断するために使用することが出来る。一部の国／地域では、電話サービス用の内部配線は、３本のワイヤを有し、２本は電話通信信号の伝送用であり、かつ１本は呼出信号用である。このような運用は、近年陳腐化しているが、第３のワイヤを有する宅内設備は存在し続けている。残念ながら、この第３のワイヤはＤＳＬ信号伝送の平衡を悪化させるため、ＤＳＬ伝送を深刻に損なう。その結果、外部の雑音源は特にＤＳＬに強い干渉を引き起こす。さらに詳細には、時間変化する雑音源は、次いでリンク故障につながり得る実質的な雑音変化を引き起こす。このような雑音変化は本明細書に記載される実施形態を使用して検出することが可能であり、その結果として、第３のワイヤの存在は潜在的な主要因として示唆されことが可能である。
【００５２】
実質的な雑音変化の決定は、「屋内配線に関する問題」のより一般的な状態を診断するためにも使用することが出来る。場合によっては、屋内配線は不十分に取付けられ又は管理されており、それによりＤＳＬ信号伝送の平衡を悪化させ、かつＤＳＬ伝送は外部の雑音源により害を受ける可能性がある。かさねて、本明細書に記載されるように雑音変化を検出することは、屋内配線の問題を診断することを援助することが出来る。
【００５３】
次に図４のモジュール４３０を参照して、本発明の１実施形態は、リンク故障が電力損失と相関性があるかどうかを検査する。リンク故障の前及び後の雑音が実質的に相違しないことを検出する場合、次いでリンク故障は電力損失の結果、又は重大なインパルス雑音イベント（例えば、回線上の電圧サージ）の結果である可能性があると決定する。これらの状況の相互間の差異を明確にするために、いくつかの追加の検査を行うことが出来る。
【００５４】
−  リンク故障が、報告されている電力損失（ＬＰＲ）故障と相関性があるかを検査する。ＬＰＲが故障イベントと相関性がある場合、リンク故障は、停電のために発生した。  
−  ＣＰＥモデム（例えば、パーソナルコンピュータ（ＰＣ）のようなコンピュータによって駆動されるＵＳＢＣＰＥモデム）が、ＤＳＬリンク上で使用されるかどうかを検査する。このような方法が用いられる場合、次いで顧客宅内でＰＣの電源を切ってすぐに入れ直すこと又は電源を切ることは回線切断を生ずる。  
−  隣接するリンクが、同時に又は同様の時間に故障を経験するかどうかを検査する。このような場合、複数のリンクは重大なインパルス雑音イベントにより害を受けていると推測され得る。  
−  ＤＳＬレシーバの飽和、受信される信号電力の増加、回路保護論理の起動、オーバフロービット又は同様の起動の表示を検査する。このような表示が存在する場合、次いで重大なインパルス雑音イベントが発生した可能性がある。
【００５５】
他の全ての場合において、リンク故障は重大なインパルス雑音イベントに起因する可能性がある。このようにして、不十分なリンクの安定性の原因は、電力損失イベント、又は重大なインパルスイベントのいずれかとして特定することが出来る。
【００５６】
モジュール４４０を参照して、リンク故障が電力損失と相関性があることが検出される場合、次いでリンク故障を特性化する情報が記録されてもよい。例えば、このようなイベントが生じる可能性が最も高い時間、日に関する統計的な情報を提供するために、リンク故障の時間／日を記録することが出来る。
【００５７】
モジュール４５０において、リンク故障が重大なインパルスイベントに起因することが検出される場合、次いでリンク故障を特性化する情報が記録される。例えば、このようなイベントが生じる可能性が最も高い時間、日に関する統計的な情報を提供するために、リンク故障の時間／日を記録することが出来る。
【００５８】
モジュール４２０に戻って、リンク故障の前及び後の雑音が実質的に異なることが検出される場合、受信される雑音強度の突然の変化がリンク故障の原因であることが推測される。リンク故障を特性化する情報が記録される。例えば、このようなイベントが生じる可能性が最も高い時間、日に関する統計的な情報を提供するために、リンク故障の時間／日を記録することが出来る。
【００５９】
リンク故障の前及び後の雑音における差異は、保存することが可能であり、かつこのような雑音変化の効果を低減させるリンクを再構成するための価値ある情報を提供する。この差異は、雑音変化を引き起こす雑音源の異なる周波数上の電力（電力スペクトル密度、ＰＳＤ）を効果的に明らかにする。このような差異が複数のリンク故障について計算される場合、より高い信頼性を提供するために平均値を計算することが出来る。雑音の差異を測定するための代わりの方法として、ビット分布の差異のような量を用いることが出来る。
【００６０】
モジュール４１０に戻って、リンクの品質を評価するために、チャネル性能監視パラメータ及び／又は回線性能監視パラメータが、図３Ａ及び図３Ｂを参照して上述したように取得される。本発明のいくつかの実施形態では、経時的なこれらの量の分布が評価される。上位層のパラメータは、ＩＰＴＶ又は他のビデオストリームの配信のような応用のために取得することが出来る。このようなパラメータのリストは、当業者には周知の、ＤＳＬフォーラム文書ＷＴ−１３５第４改訂版の中で提供される。
【００６１】
リンクの品質レベルは、このような分布の評価から決定される。１実施形態では、例えば、以下の全ての条件が有効である場合、リンクの品質は許容可能であると宣言される。
【００６２】
−  間隔の９５％についてＣＶ＜＝１
−  間隔の９９％についてＣＶ＜＝１０
−  間隔の１００％についてＣＶ＜＝１００
−  間隔の９５％についてＳＥＳ＜＝１
−  間隔の９９％についてＳＥＳ＜＝１５
−  間隔の１００％についてＳＥＳ＜＝６０
【００６３】
他の全ての場合には、リンクの品質は許容不可能であると宣言される。
【００６４】
他の量は上記のパラメータから導き出すことが出来る。これらは合計（例えば、ＵＡＳ＋ＳＥＳ）、又はより複雑な式（例えば、ＣＶ／（３６０ｅ３−（ＳＥＳ＋ＵＡＳ）＊４００））を有する可能性がある。これらのような数式は、ＣＯ側若しくはＣＰ側のどちらかに関連する、又はＣＯ側及びＣＰ側の双方に関連するパラメータについて構築されよもよい。このような数式は、ベンダ及び／又はシステムＩＤに依存してもよい。
【００６５】
４１０においてリンクの品質が不十分であると決定される場合、次いでモジュール４７０においてエラーについてさらなる分析が行われ、不十分な品質を引き起こすインパルス雑音イベントが断続的であるか又は持続的であるかを決定することが出来る。このような特性化の基本的な差異は、インパルス雑音イベントの継続期間である（図５を参照）。
【００６６】
このような特性化を行う方法は、コード違反（ＣＶ）カウンタを監視することである。かなりの割合の時間にわたるＣＶカウンタの大きな値は、インパルス雑音イベントの継続期間が長く、かつインパルス雑音は持続的又は反復性であると分類出来ることを示唆する。反復性のインパルス雑音を宣言する例示的な基準は、少なくとも１つの以下の条件を満足させることである。  
−  間隔の１０％についてＣＶ＞＝１００、又は
−  間隔の５％についてＣＶ＞＝１０００
【００６７】
代替のパラメータを使用することが可能であり、又は基準は規則と以下のような複数のパラメータとの組み合わせを使用して構築することが出来る。  
−  ＦＥＣ、修正される符号語の数
−  ＦＥＣＳ、ＦＥＣ秒数
−  ＥＳ、エラー秒数
−  ＳＥＳ、重大なエラー秒数
−  ＬＯＳＳ、信号損失秒数
−  ＵＡＳ、無効時間秒数
【００６８】
ＣＶ及びＦＥＣは、秒数のカウントと比較してより細かい精度を有するため、好都合である。上記のようなパラメータから導き出されるいずれの条件も、データ速度及びマージンのような性能パラメータを組み込むことが可能である。
【００６９】
いくつかの実施形態では、ＤＳＬシステムによって、インパルス雑音に関するより詳細な情報が提供されてもよい。例えば、情報は以下を有してもよい。  
−  インパルス雑音幅の、平均値、統計、又は分布
−  インパルス雑音期間の、平均値、統計、又は分布
−  インパルス雑音継続期間の、平均値、統計、又は分布
【００７０】
インパルス雑音は、次いで、以下の全ての条件が満たされる場合、反復性として特性化されてもよい。  
−  インパルス雑音イベント継続期間＞ｘ秒（例えば、１０秒）
−  インパルス雑音期間＜ｙミリ秒（例えば、１０００ミリ秒）
−  インパルス雑音幅＞ｚＤＭＴシンボル（例えば、０．５ＤＭＴシンボル）
【００７１】
これらの条件が満たされない場合、雑音は断続的なインパルス雑音と分類される。
【００７２】
他の実施形態では、インパルス雑音は、ＤＳＬ物理層よりも上位のネットワーク層に関する情報を検査することにより特性化されてもよい。例えば、情報は以下を有してもよい。  
−  損失又は破損パケット／ＭＰＥＧフレームの、平均値、統計、又は分布
−  パケット内部出現ジッタの、平均値、統計、又は分布
−  ＭＰＥＧバッファオーバーラン及びアンダーランの、平均値、統計、又は分布
【００７３】
例えば、インパルス雑音は、次いで、以下の全ての条件が満たされる場合、反復性として特性化されてもよい。  
−  測定間隔の１０％について、損失パケット＞ｘ１、又は
−  測定間隔の５％について、損失パケット＞ｘ２
【００７４】
上記の条件は何れも、ベンダ及び／又はシステムＩＤに依存してもよい。
【００７５】
次のステップ４８０として、反復性インパルス雑音であると不十分なリンクの品質の原因を宣言した後、さらなる分析を行ってもよい。
【００７６】
故障を特性化する情報は記録される。例えば、不十分な品質の時間／日は、このようなイベントが発生する可能性が最も高い時間、日に関する統計的な情報を提供するために、記録することが出来る。これは、例えば、ＣＶ又は他の何らかのチャネル／回線性能監視パラメータが所定の閾値を超える時に、間隔を記録することによって達成することが出来る。
【００７７】
チャネル又は回線性能監視パラメータを使用し、かつこれらのパラメータが所定の閾値を超える時間の長さを記録することにより、インパルス雑音イベント継続期間もまた推定することが出来る。
【００７８】
性能監視パラメータを測定する間隔が、ほぼマイクロ秒の程度に十分短くされる場合に、インパルス雑音幅及び期間もまた推定することが出来る。そのような短い間隔が不可能であっても、反復性インパルス雑音は、性能監視パラメータに基づいておおよそ特性化することが出来る。例えば、以下の場合、反復性インパルス雑音はレベル１であるとして特性化されてもよい。  
−  間隔の１０％についてＣＶ＞＝１００、又は
−  間隔の５％についてＣＶ＞＝１０００
【００７９】
又は、以下の場合、レベル２であるとして特性化されてもよい。
【００８０】
−  間隔の２０％についてＣＶ＞＝１００、又は
−  間隔の１０％についてＣＶ＞＝１０００
【００８１】
反復性インパルス雑音は、他のもの以上に所定の周波数に影響を及ぼす可能性がある。影響を受けた周波数を特定する方法が次に説明される。
【００８２】
反復性インパルス雑音は、ＤＳＬレシーバが受ける平均雑音に影響を有する可能性があることが観測されている。雑音測定が、インパルス雑音イベントの開始前、及びインパルス雑音イベントの進行中に行われる場合、次いでこれらの雑音測定結果は実質的に異なる可能性がある。（ＳＮＲマージン測定を行うことにより同じ効果を認めることが出来る。）雑音が実質的に異なる周波数を記録することにより、反復性インパルス雑音に最も影響を受ける周波数を特定することが出来る。このような知識を利用する方法は、以下により詳細に説明される。
【００８３】
４７０において、インパルス雑音が不十分なリンクの品質の原因であると宣言される場合、さらなる分析が行われてもよい。リンク故障を特性化する情報が記録される。例えば、不十分な品質の時間／日は、このようなイベントが発生する可能性が最も高い時間、又は日に関する統計的な情報を提供するために、記録することが出来る。これは、例えば、ＣＶ又は他の何らかのチャネル／回線性能監視パラメータが所定の閾値を超える時に、間隔を記録することによって達成することが出来る。
【００８４】
インパルス雑音イベント継続期間、インパルス雑音幅及びインパルス雑音期間はまた、反復性インパルス雑音に関するものと同様の方法を使用して推定してもよい。雑音特性化は、原因のその宣言に一意である必要はないことに留意しなければならない。例えば、リンクの不安定性の原因となる突然の雑音変化、及び不十分なリンクの品質の原因となる断続的インパルス雑音のために、リンクの安定性及びリンクの品質の両方が不十分であると決定されてもよい。このような場合、本発明の実施形態は、順番に又は同時に、ステップ４２０及び４７０に続くステップを実行してもよい。
【００８５】
（雑音低減）
図６を参照して、雑音低減作用は、上記で概説されたように雑音特性化６０５の結果に依存する。本発明の１実施形態では、雑音低減は、図３Ａ及び図３Ｂに示されるようにＤＳＬリンク再構成によって達成される。複数回のデータ収集及びリンク再構成が、適切な雑音低減を達成するために行われてもよい。
【００８６】
制御され得るパラメータのリストは以下を有する。
【００８７】
Ｇ．９９７．１より、
回線構成パラメータ
−  ＭＡＸＮＯＭＰＳＤ、最大公称（ｎｏｍｉｎａｌ）ＰＳＤ
−  ＭＡＸＮＯＭＡＴＰ、最大公称集約送信機電力
−  ＭＡＸＲＸＰＷＲ、最大受信電力
−  ＣＡＲＭＡＳＫ、搬送波マスク
−  ＰＳＤＭＡＳＫ、ＰＳＤマスク
−  ＲＦＩＢＡＮＤＳ、ＲＦＩ帯域
−  ＤＰＢＯＳＨＡＰＥＤ、下流電力バックオフ
−  ＵＰＢＯＳＨＡＰＥＤ、上流電力バックオフ
−  ＴＡＲＳＮＲＭ、ターゲットＳＮＲマージン
−  ＭＡＸＳＮＲＭ、最大ＳＮＲマージン
−  ＭＩＮＳＮＲＭ、最小ＳＮＲマージン
−  ＭＳＧＭＩＮ、メッセージオーバヘッドチャネルの最小速度
【００８８】
チャネル構成パラメータ
−  最小データ速度
−  最大データ速度
−  最大インターリーブ遅延
−  最小インパルス雑音保護
−  ＦＥＣ冗長割合
【００８９】
ＤＳＭ  ＴＲからの追加
−  マージンキャップモード
−  帯域選択（ｂａｎｄ  ｐｒｅｆｅｒｅｎｃｅ）
【００９０】
追加のパラメータ
−  ＴＡＲＳＮＲＭ［ｎ］、トーンごとのターゲットＳＮＲマージン
−  ＢＣＡＰ［ｎ］、トーンごとのビットキャップ
−  再訓練閾値
−  ＤＳＬ層に対する再送信パラメータ
【００９１】
６０５において、固定雑音６１０がリンク不安定性の原因であると決定される場合、次いで６１５において、本発明の実施形態によるＤＳＬリンクの１つ以上の特定の再構成が、問題を低減する可能性がある。固定雑音の解析は、リンク故障の前及び後の雑音変化の推定を生成する。新しい雑音の電力スペクトル密度の推定は、影響を受ける周波数に対する、かつそのような雑音変化が反復されるときのリンク故障を防ぐために、追加の保護を提供してもよい。
【００９２】
影響を受ける周波数に対する保護を増加させるために、６１５において用いることが出来る潜在的なカウンタ測定の概要は以下の通りである。
【００９３】
１．ＤＳＬリンクに対して追加のＳＮＲマージンが提供される。その結果、雑音変化は、負の値へのＳＮＲマージンの降下を生じさせない。これはＤＳＬリンクの最大データ速度を減少させることにより、又はより大きなＴＡＲＳＮＲＭ（ターゲットＳＮＲマージン）を要求することにより達成することが出来る。
【００９４】
２．突然の雑音変化に最も影響を受ける周波数は無効にされてもよい。これは、これらの周波数が如何なるビットもロードされていないことを確認するために、ＣＡＲＭＡＳＫ（搬送波マスク）、又はＰＳＤＭＡＳＫ（ＰＳＤマスク）のどちらかを使用して達成することが出来る。
【００９５】
３．突然の雑音変化によって最も影響を受ける周波数は、追加のマージンを提供されてもよい。これは、例えば、Ａｍａｔｉ  ＣｏｍｍｕｎｉｃａｔｉｏｎｓのＪｏｈｎ  Ｍ．  Ｃｉｏｆｆｉによる標準寄稿Ｔ１Ｅ１．４／１９９２−２０３において記載されたトーン依存ＴＡＲＳＮＲＭ［ｎ］パラメータを使用することによって、これらの周波数が他の周波数と比較してより大きなマージンを有することを確実にするために、構成パラメータを適切にプログラムすることによって、達成することが出来る。もう１つの非常に効果的な手法は、影響を受ける周波数が過多のビットをロードされることを防ぐために、トーン依存ビットキャップ（ＢＣＡＰ［ｎ］）を使用することである。このようにして、追加の保護を確実にする。
【００９６】
４．追加の保護を提供するための新しい手法は、トーン依存ＭＡＸＳＮＲＭ［ｎ］パラメータ、又は最大ＳＮＲマージンを使用することである。この手法により、超過のマージンによって特性化されるシステムは、所定のトーンが他のものよりも雑音に対してより大きな保護が可能であるように、電力削減を行うことが出来る。例えば、突然の雑音変化が影響を有することが観測されるトーンは、２０ｄＢのＭＡＸＳＮＲＭが許容されてもよい。一方、そのような影響を有さないトーンは、６ｄＢのみのＭＡＸＳＮＲＭが許容されてもよい。この実施は、超過のマージンと関連する場合に電力削減を強いる、ＭＡＸＳＮＲＭ設定を有する利点と、所定の周波数がより効果的に突然の雑音変化に対処出来るように、所定の周波数に対する優先的な措置を与える利点とを結合する。
【００９７】
５．突然の雑音変化を受けているそれらのトーンに対するよりよい保護を提供するためのもう１つの新しい手法は、ビットスワップ動作がそのようなトーンに対してより控えめであるように、そのようなトーンに印を付けることである。１実施形態では、印を付けられたトーンは、ビットスワップを使用して、ロードされるビットを増加させることが出来ないようにされる。このような手段は、時間可変雑音が、それらのトーンのロードされるビット数を減少させることのみが出来ることを保証する。このようにして、初期化後の雑音条件におけるいくつかの一時的な改良により、雑音が後に突然増加し、場合によっては望ましくない回線故障を引き起こす可能性があるそれらのトーンに対するより多数のビットを生じることとはならない。
【００９８】
６．もう１つの実施形態では、所定数のロードされたビットに到達するときにだけ、印を付けられたトーンは、ビットスワップを使用してロードされるビット数の増加を防ぐことが可能である。この手法はＢＣＡＰ［ｎ］の１種類とみなすことが出来るが、「ビットキャップ」制約がＳＨＯＷＴＩＭＥ中の動作にのみ適用され、必ずしも初期化中のロードアルゴリズムには適用されない点で大きく相違する。
【００９９】
６０５において、重大な雑音インパルス６２０がリンク不安定性の原因であると決定される場合、本発明の実施形態によれば、１つ以上の特定のステップ６２５が問題を減少させ得る。そのようなリンク不安定性を引き起こす重大な雑音インパルスは、一般的には、ＤＳＬモデムサージ保護回路の起動を引き起こすのに十分強力な電圧を有するインパルス雑音信号によって特性化される。その期間中、受信信号は深刻に破損し、かつ論理は再訓練を開始するために起動される可能性がある。再訓練のトリガはマージン損失（ＬＯＭ）表示、短期間中の超過数のコード違反、及びその他のような基準に基づくことが可能である。考えられる低減の戦略は、重大な雑音インパルスが観測される場合に再訓練が即座に開始されないように、再訓練のためのトリガ条件を調整することである。リンクに影響を与える重大な雑音インパルスの情報がある場合、再訓練の条件をより厳しくすることにより、再訓練イベントはより生じにくくなるであろう。次いで、ＤＳＬシステムはＳｈｏｗｔｉｍｅを保ち、かつＳｈｏｗｔｉｍｅ適応技術を使用する間に、そのような重大な雑音インパルスから回復することが出来る場合がある。このようなトリガ条件を調整する例は以下の通りである。
【０１００】
−  マージン損失（ｌｏｓｓ−ｏｆ−ｍａｒｇｉｎ）が再訓練のトリガとならないように、ＭＩＮＳＮＲＭをより小さな値に調整する。  
−  再訓練のトリガとなる、時間単位ごとのコード違反の閾値を調整する。  
−  再訓練のトリガとなる、時間単位ごとのデコーダエラーの閾値を調整する。
【０１０１】
これらのトリガ条件はＳＯＳイベントに関連する場合もある。レシーバが信号の重大な劣化を検出するときに、対応するＤＳＬモデムはデータ速度の実質的な減少を交渉するＳＯＳプロトコルを使用してもよい。この手法は、ＤＳＬサービスの停止が全くない、又は最小限の停止を招く、完全な再訓練のプロセスと比較して相当に高速であることが可能である。このようなＳＯＳイベントをトリガする条件は、マージン損失表示、期間内のコード違反の超過カウント、期間内のデコーダエラーの超過カウントなどのような、再訓練のための上述の記載と同様であってもよい。
【０１０２】
重大な雑音インパルスの発生を検出するために、論理がモデムのアナログフロンドエンドに含まれる場合、これらの方法はさらに向上させることが可能である。このような論理の出力は、再訓練が、重大な雑音インパルスの期間中に、かつ雑音インパルスが消えた数秒後に行われるべきではないことを示すであろうモデムのコントローラ回路への信号であろう。
【０１０３】
６０５において、電力損失イベント６３０が回線不安定性の原因であると決定される場合、次いで、６３５において、本発明の実施形態によれば、この効果を減少させるためにＤＳＬ再構成のステップは必要とされない。しかし、操作を通知する、又はこの問題の顧客に通知するような他の動作が必要とされてもよい。
【０１０４】
６０５において、断続的なインパルス雑音イベント６４０が不十分な回線品質の原因であると決定される場合、本発明の実施形態によるＤＳＬリンクの１つ以上の特定の再構成が問題を低減させる可能性がある。
【０１０５】
インパルス雑音の幅及び期間の推定を知り又は有することは、適切なインパルス雑音保護を提供するためにＤＳＬリンクを適切に構成するのを援助することが出来る。インパルス雑音の幅の推定は、最小のインパルス雑音保護のパラメータを選択するために役立つ。特に、最小インパルス雑音保護は、少なくとも推定されるインパルス雑音幅と同じ長さであるように選択されなければならない。同時に、符号語期間（ｃｏｄｅｗｏｒｄ  ｓｐａｎ）は推定されるインパルス雑音期間よりも短くされなければならない。符号語期間は、インターリーバ遅延の量によって近似することが出来る。ＤＳＬリンクを構成するための１組の条件は以下の通りである。
【０１０６】
１．最小インパルス雑音保護  ＞  推定されるインパルス雑音幅
２．最大遅延  ＜  推定されるインパルス雑音期間
【０１０７】
第２の条件を満たすことが出来ない場合、次いでＲＳ符号が符号語期間内の複数のインパルス雑音の発生に対処出来るように、最小インパルス雑音保護がさらに増加されなければならない。
【０１０８】
適切なインパルス雑音保護を提供するＤＳＬシステムの再送信モジュールを構成するために、同様の基準を用いることが出来る。ＰＨＹ層で再送信技術を実装する潜在的なＤＳＬシステムにおいて、最小インパルス雑音保護、最大遅延、最小内部到達（ｉｎｔｅｒ−ａｒｒｉｖａｌ）時間、及び最小ＲＳオーバヘッドのような再送信のための構成パラメータが存在する。このような構成パラメータは以下のようにプログラムされてもよい。
【０１０９】
１．最小インパルス雑音保護  ＞  推定インパルス雑音幅
２．最小内部到達時間  ＜  推定インパルス雑音期間
３．最大遅延  ＜  遅延バジェット（ｄｅｌａｙ  ｂｕｄｇｅｔ）
４．最小ＲＳオーバヘッド  ＞  ｘ  ＊  （ＲＳ符号語内の全バイト中の割合としてのエラーのあるバイトの推定数）、ここで、抹消デコード無しでｘ＝２であり、かつ抹消デコード有りで１＝＜ｘ＜２である。（最小ＲＳオーバヘッドは、直接的に、又は間接的に、例えばＦＥＣについてのパラメータの制御を介して、制御されてもよいことに留意しなければならない。）
【０１１０】
構成パラメータを選択する上記の規則がさらに説明される。所定のＤＳＬモデムは同時に、再送信モジュール並びに前方誤り訂正（ＦＥＣ、例えば、ＲＳ符号化／復号化）及びインターリーブを実装するモジュールを用いてもよい。このような場合、構成パラメータは、再送信モジュール並びにＦＥＣ及びインターリーブモジュールの双方に関連するパラメータを有してもよい。このような実施形態には、インパルス雑音を訂正するために、再送信及びＦＥＣの使用の間に存在するトレードオフがある。一方に対する他方への相対的な選択は、インパルス雑音特性に依存する。
【０１１１】
より詳細には、ＤＭＴシンボルの継続期間と比較して、推定インパルス雑音期間が相対的に短い場合、これは、インパルス雑音が持続的であり、かつ単独で使用される再送信スキームが適切な保護を提供することが出来ない可能性があることを示唆する。インパルス雑音が多数の連続するＤＭＴシンボルに影響を与える場合、これらのシンボルを再送信する試行はさらなる失敗となり、かつ結果的に再送信バッファのオーバフローを引き起こす可能性がある。他方、ＲＳ符号化が連続的なＤＭＴシンボル内のエラーのあるバイトを訂正することが可能な場合、再送信及びＲＳ符号化の組み合わせはエラーの無い送信をもたらすであろう。このような場合、上記のような構成パラメータの選択が最も有益であろう。
【０１１２】
最小インパルス雑音のための構成パラメータは、ＲＳデコーダ（又は再送信モジュール）の入力点で提供されるのであって、モデムのティップ・ツー・リング（ｔｉｐ−ｔｏ−ｒｉｎｇ）点ではない。ティップ・ツー・リングにおける所定長のインパルスは、レシーバプロセスを経た後、広がりかつより長い幅を有する。また、実用設計は、最小インパルス雑音保護、最大遅延、及びデータ速度についての可能な選択に限定を有することにも留意される。このような限定は、ＤＳＬリンクを構成するときに考慮に入れることが出来る。
【０１１３】
断続的なインパルス雑音の影響を低減するためのさらなる技術は、そのような雑音によって強い影響を受けると知られ又は疑われるトーンにロードするビットを調整することである。例示の方法が、本明細書に概説される。
【０１１４】
１．ＢＣＡＰ［ｎ］を使用して、トーンにより少数のビットをロードさせる。このようなＢＣＡＰ［ｎ］のプログラミングにより、多数のビットを有するトーンの数を減少させ、場合によっては少数のビットを有するトーンの数を増加させる。これは、特にインパルス雑音がレシーバクリッピングの結果である場合に、インパルス雑音排除性の効果を有する。インパルス雑音が影響を受けるトーン上にほぼ同じ強度を有すると仮定すれば（レシーバクリッピングの場合のように）、多数のビットをロードされるトーンと比較して、小数のビットをロードされるトーンは改善された排除性を有する。このようにして、多数のビットがトーンにロードされることを許容しないことにより、全体的なインパルス雑音排除性は改善される。
【０１１５】
２．インパルス雑音に強い影響を受ける可能性があるトーン上の保護を増加させる。これを達成するための例示の技術は以下を有する。
【０１１６】
ａ．ＣＡＲＭＡＳＫ、ＰＳＤＭＡＳＫ又は他の同等のパラメータを使用してのそれらのトーンの無効化。  
ｂ．少数のビットを強いるそれらのトーンに対するＢＣＡＰ［ｎ］の使用。  
ｃ．少数のビットを強いるそれらのトーンに対するＰＳＤＭＡＳＫ又はＴＡＲＳＮＲＭ［ｎ］の使用。
【０１１７】
インパルス雑音に対するＤＳＬリンクの堅牢性を改善するための、以下でより詳細に説明される、さらにもう１つの技術は、ＤＳＬレシーバのリードソロモン（ＲＳ）デコーダを支援するために、このような雑音によって最も影響を受けるトーンについての情報を使用することである。
【０１１８】
ＲＳ符号化は、ＲＳ符号語を形成するために所定数の「パリティ」バイトを「ペイロード」バイト数に加える。ＲＳデコーダにおいて、ＲＳ符号語ごとに訂正することが出来るエラーを有するバイト数は、一般的にパリティバイト数の半分に等しい。しかし、エラーを有するバイトの場所に関する情報が利用可能な場合は、エラー訂正能力は２倍になり、かつパリティバイト数と等しくなる。この後者の場合、「抹消（ｅｒａｓｕｒｅ）」復号化が行われると言われる。レシーバに抹消デコーダを実装する上での課題は、エラーを有するバイトの場所、又は抹消についての情報が必要な点である。
【０１１９】
しかし、インパルス雑音が最も強い影響を有するトーンの情報は抹消復号化に役立つ。本発明の実施形態によって提供されるトーン情報から開始して、インパルス雑音によって破損される可能性が高いＲＳ符号語内のバイトの場所を特定することが可能な、信頼出来る抹消予測プロセスを構築することが出来る。これは図７で例示される。
【０１２０】
６０５において、反復性インパルス雑音イベント６５０は回線不安定性の原因であると決定される場合、次いでステップ６５５において、所定のＤＳＬ再構成がこの効果の低減に役立つことが出来る。
【０１２１】
断続的なインパルス雑音について記載される同様の技術を適用することが可能であるが、１つの重大な差異を有する。すなわち、反復性インパルス雑音のために、平均レシーバ雑音（又は同等に測定されるマージン、若しくは測定されるＳＮＲレベル）がインパルスによる影響を受ける。この効果は、インパルス雑音が最も強力な効果を有する周波数をより正確に特定するための雑音特性化の間に好都合に用いることが出来る。
【０１２２】
これらの周波数を知ることにより、ビットロードを調整することによるインパルス雑音の影響を減少させる技術が、より効果的となることが出来る。例示的な方法は次に概説される。
【０１２３】
１．影響を受ける周波数に対応するｎの値について、ＢＣＡＰ［ｎ］＝ＢＩＴＳ［ｎ］−２に設定する。ＢＩＴＳ［ｎ］は前もって取得されるビット分布である。  
２．影響を受ける周波数に対応するｎの値について、ＢＣＡＰ［ｎ］＝０に設定する（又はＣＡＲＭＡＳＫ［ｎ］＝１に設定する、又はＰＳＤＭＡＳＫ［ｎ］＝−１００ｄＢｍ／Ｈｚに設定する）。  
３．影響を受ける周波数に対応するｎの値について、ＰＳＤＭＡＳＫ［ｎ］＝−７０ｄＢｍ／Ｈｚに設定する（又はＴＡＲＳＮＲＭ［ｎ］＝４０ｄＢに設定する）。
【０１２４】
図８は、本発明の１つ以上の実施形態によるユーザ及び／又はコントローラによって使用され得る典型的なコンピュータシステムの例示である。コンピュータシステム８００は、１次記憶装置８０６（典型的にはランダムアクセスメモリ、又はＲＡＭ）、１次記憶装置８０４（典型的には読み出し専用メモリ、又はＲＯＭ）を有する記憶装置に結合される任意の数のプロセッサ８０２（中央処理装置、又はＣＰＵとも呼ばれる）を有する。当業者には周知なように、１次記憶装置８０４はデータ及び命令を単方向的にＣＰＵに転送するように動作し、１次記憶装置８０６は一般的に双方向的にデータ及び命令を転送するために使用される。これらの１次記憶装置は両者共に、上述の任意の適切なコンピュータ可読媒体を有してもよい。大容量記憶装置８０８もまた、ＣＰＵ８０２に双方向的に結合され、かつ追加のデータ記憶容量を提供し、上述の任意のコンピュータ可読媒体を有してもよい。大容量記憶装置８０８はプログラム、データなどを記憶するのに使用されてもよく、典型的には１次記憶装置よりも低速であるハードディスクのような２次記憶媒体である。大容量記憶装置８０８内に保持される情報は、適切な場合には、標準的な方法で仮想メモリとして１次記憶装置８０６の一部として組み入れられることが理解されるであろう。ＣＤ−ＲＯＭ８１４のような特定の大容量記憶装置もまたＣＰＵに双方向的にデータを渡すことが可能である。
【０１２５】
ＣＰＵ８０２はまた、１つ以上のビデオモニタ、トラックボール、マウス、キーボード、マイクロホン、タッチセンサ式のディスプレイ、トランスデューサカードリーダ、磁気又は穿孔テープリーダ、タブレット、スタイラス、音声又は手書き認識、又は言うまでもなく他のコンピュータのような他の周知の入力装置を有するインタフェース８１０に結合される。最後に、８１２において概略的に示されるように、ＣＰＵ８０２はネットワーク接続を使用して、選択的にコンピュータ又は通信ネットワークに結合されてもよい。このようなネットワーク接続を用いて、ＣＰＵは上述の方法のステップを実行する過程でネットワークから情報を受信し、又はネットワークへ情報を出力する可能性が考えられる。上述の装置及び構成要素はコンピュータハードウェア及びソフトウェアの分野における当業者にはよく知られているであろう。上述のハードウェア要素は、本発明の動作を実行するための複数のソフトウェアモジュールを定義してもよい。例えば、符号語構成コントローラを実行するための命令が大容量記憶装置８０８又は８１４に記憶され、かつ１次メモリ８０６と連動してＣＰＵ８０２で実行されてもよい。好ましい実施形態では、コントローラはソフトウェアサブモジュールに分解される。
【０１２６】
本発明の多くの特徴及び利点は明細書から明らかであり、それ故に、添付の特許請求の範囲は本発明の全てのこのような特徴及び利点を包含することを意図するものである。さらに、当業者は多くの修正及び変更を容易に思いつくため、本発明は例示されかつ記載された正確な構造及び動作に限定されない。従って、記載された実施形態は例示的であり、限定的に解釈されるべきではなく、本発明は本明細書に記載されたその詳細に限定されるべきではなく以下の特許請求の範囲、及び、現在又は未来において予見可能であろうと予見不可能であろうと、その均等物の全範囲によって定義されるべきである。
【図１】
2010505288.tif 000003
【図２】
2010505288.tif 000004
【図３Ａ】
2010505288.tif 000005
【図３Ｂ】
2010505288.tif 000006
【図４】
2010505288.tif 000007
【図５】
2010505288.tif 000008
【図６】
2010505288.tif 000009
【図７】
2010505288.tif 000010
【図８】
2010505288.tif 000011