(57)【特許請求の範囲】
【請求項１】
マルチキャリア変調を使用した伝送システムにおいて通信信号のパラメータを適応的に変更する方法であって、
前記変更は、前記通信信号が変更要求が受信または実現されたことを示すものとして規定された応答を含まないという条件下で行なわれ、
レシーバからトランスミッタへと変更要求を伝送する工程であって、前記変更要求は、変更される特定のサブキャリアを個別に識別し、前記識別された各サブキャリアに関連付けられたパラメータの所望値を個別に識別するように構成され、前記パラメータの各所望値は、前記パラメータの現在の値であるカレント値と異なる、工程と、
前記受信された通信信号をモニタし、前記要求された変更が実現されたかを決定する工程であって、前記要求された変更が実現されたか否かの決定は、前記受信された通信信号のうち変更することを意図された一部分の分析に、少なくとも部分的に基づく、工程と
を備える方法。
【請求項２】
請求項１記載の方法であって、
前記変更要求は、変更される複数の特定のサブキャリアを識別し、識別された各サブキャリアに対してそのサブキャリアに関連付けられたパラメータの所望値を識別するように構成される、方法。
【請求項３】
請求項１または請求項２記載の方法であって、
前記モニタリングの工程は、前記パラメータの前記カレント値と前記パラメータの前記所望値とを使用して前記受信された通信信号をデコードし、前記要求された変更が少なくとも部分的に前記デコーディングに基づいて実現されたか否かを決定することを含む、方法。
【請求項４】
請求項３記載の方法であって、さらに、
前記カレント値のデコードに基づく第１の前進型誤り訂正シンドロームと、前記所望値のデコードに基づく第２の前進型誤り訂正シンドロームとを生成する工程であって、前記変更要求が実現されたか否かの決定は、前記シンドロームの分析に基づいて下される工程を、備える方法。
【請求項５】
請求項１ないし請求項４のうちの任意の１つに記載の方法であって、
前記モニタリングの工程は、前記変更要求によって変更されることを意図された前記特定のサブキャリアをモニタし、前記要求された変更が実現されたか否かを決定することを含む、方法。
【請求項６】
請求項１ないし請求項５のうちの任意の１つに記載の方法であって、
前記要求された変更が実現されたか否かの決定は、前記パラメータの前記カレント値および前記所望値を使用して前記通信信号をデコードすることに基づいて検出されたエラーの分析に、少なくとも部分的に基づいて下される、方法。
【請求項７】
請求項１ないし請求項６のうちの任意の１つに記載の方法であって、
前記モニタリングの工程は、第１の時点における前記サブキャリアの第１の布置を、第２の時点における前記サブキャリアの第２の布置によって分析することを含み、
前記変更の要求は、前記第２の布置が前記第１の布置と異なる場合に実現されたことが知られる、方法。
【請求項８】
請求項１ないし請求項７のうちの任意の１つに記載の方法であって、
前記モニタリングの工程は、前記通信信号のサブキャリアの１つをモニタし、該サブキャリアが前記変更要求の実現に基づいて０に等しくなるように変更されたことを含み、
前記サブキャリア上における伝送エネルギの欠如は、前記要求された変更が前記トランスミッタによって実現されたことを示す、方法。
【請求項９】
適応マルチキャリア伝送信号を使用し、１対のモデム間における双方向の通信を促進する方法であって、
第１のモデムから第２のモデムに変更要求コマンドを伝送する工程であって、該変更要求コマンドは、変更される特定のサブキャリアを識別し、前記マルチキャリア伝送信号内の特定のサブキャリアに関連付けられたパラメータ値における所望の変更を通信するように構成され、前記パラメータ値における所望された変更は、現在のパラメータ値と異なる値への変更である、工程と、
前記変更要求コマンドにより要求された変更が実現されたかを決定するために、前記第１のモデムにおいて受信された通信信号をモニタする工程であって、前記要求された変更が実現されたか否かの決定は、前記通信信号に当該変更要求が受信または実現されたことを示すものとして規定された応答を含まないという条件下で、前記受信された通信信号のうち変更することを意図された一部分の分析に、少なくとも部分的に基づいて行なわれる、工程と、
を備え、
前記変更要求コマンドは、
前記コマンドを変更要求コマンドとして識別するように構成されたヘッダと、
前記変更要求コマンドによって変更されるトーンの数を示すように構成された制御フィールドと、
前記変更要求コマンドによって変更される特定のサブキャリアを識別するようにそれぞれが構成された、少なくとも１つのサブキャリア識別子と、
関連のサブキャリア識別子によって識別されたサブキャリアに関連付けられたパラメータの所望値を識別するようにそれぞれが構成された、少なくとも１つの所望パラメータ値インジケータと、
エラーフィールドと
を備える、方法。
【請求項１０】
請求項９記載の方法であって、
前記所望パラメータ値インジケータは、前記関連のサブキャリア識別子によって識別された前記サブキャリアによって伝送される情報のビット数を識別する、方法。
【請求項１１】
請求項１０記載の方法であって、
前記インジケータの前記所望値は、ある特定のサブキャリアに関して変更されるビットの総数である、方法。
【請求項１２】
請求項９記載の方法であって、
前記所望パラメータ値インジケータは、前記関連のサブキャリア識別子によって識別された前記サブキャリアによって使用されるゲインを識別する、方法。
【請求項１３】
請求項１２記載の方法であって、
前記インジケータの前記所望値は、約−４．０ｄＢ〜約＋３．５ｄＢの範囲で約０．５ｄＢづつ増分する、方法。
【請求項１４】
請求項９ないし請求項１３のうちの任意の１つに記載の方法であって、
前記エラーフィールドは巡回冗長検査コードを含む、方法。
【請求項１５】
請求項９ないし請求項１４のうちの任意の１つに記載の方法であって、
前記ヘッダは、前記変更要求がいつ行われるかを示すスーパーフレームの番号を含む、方法。
【請求項１６】
請求項９ないし請求項１４のうちの任意の１つに記載の方法であって、
前記制御フィールドは、前記変更要求がいつ行われるかを示すスーパーフレームの番号を含む、方法。
【請求項１７】
マルチキャリア変調を使用した伝送システムにおいて通信信号のパラメータを適応的に変更する方法であって、
レシーバからの変更要求をトランスミッタにおいて受信する工程であって、前記変更要求は、変更される１組の特定のサブキャリアを識別し、前記識別されたサブキャリアの各々に関連付けられた少なくとも１つのパラメータに対して、対応する１組の所望値を識別するように構成され、前記所望値は、前記パラメータの現在の値であるカレント値と異なり、前記１組の所望値の各所望値を、前記識別されたサブキャリアの各々を変更するために適用し、変更のための前記要求は、前記変更要求によって変更されるサブキャリアの数を示すように構成されたサブキャリアカウントを含む、工程と、
前記変更の要求を実現することによって、前記識別されたサブキャリアに関連付けられた前記パラメータの前記所望値を保持するように前記識別されたサブキャリアを変更する工程と、
前記実現された変更要求を含み、前記変更要求が受信または実現されたことを示すものとして規定された応答コマンドを含まない、マルチキャリア信号を伝送する工程と
を備える、方法。
【請求項１８】
請求項１７記載の方法であって、
前記変更の要求は、前記変更の要求を識別するように構成されたヘッダを含む、方法。
【請求項１９】
請求項１７または請求項１８記載の方法であって、
前記変更の要求は、前記変更要求によって変更される特定のサブキャリアを識別するようにそれぞれが構成された、少なくとも１つのサブキャリア識別子を含む、方法。
【請求項２０】
請求項１７ないし請求項１９のうちの任意の１つに記載の方法であって、
前記変更の要求は、関連のサブキャリア識別子によって識別されたサブキャリアに関連付けられたパラメータの所望値を識別するようにそれぞれが構成された、少なくとも１つのインジケータを含む、方法。
【請求項２１】
請求項１７ないし請求項２０のうちの任意の１つに記載の方法であって、
前記変更の要求はエラーフィールドを含む、方法。
【請求項２２】
請求項１７ないし請求項２１のうちの任意の１つに記載の方法であって、
前記変更の要求は、前記変更要求がいつ行われるかを示すスーパーフレームの番号を含む、方法。
【請求項２３】
不連続マルチトーン伝送システムにおいて高速ビットスワッピングを行う方法であって、
レシーバから変更要求を伝送する工程であって、前記変更要求は、変更される特定のトーンを識別し、前記識別されたトーンに関連付けられたパラメータの所望値を識別するように構成され、前記所望値は、前記パラメータの現在の値であるカレント値と異なる、工程と、
トランスミッタにおいて前記変更要求を受信する工程であって、前記変更要求は、変更されるべき特定のトーンを識別し、前記識別されたトーンに関連付けられたパラメータの所望値を識別するように構成され、前記所望値は、前記パラメータのカレント値と異なる、工程と、
前記変更の要求を前記トランスミッタにおいて実現することによって、前記識別されたトーンに関連付けられた前記パラメータの前記所望値を保持するように前記識別されたトーンを変更する工程と、
前記実現された変更要求を含むマルチトーン信号を前記トランスミッタから伝送する工程と、
前記マルチトーン信号を前記レシーバにおいて受信する工程と、
前記受信されたマルチトーン信号を、少なくとも前記パラメータの前記所望値に基づいてインタープリットし、前記要求された変更が実現されたか否かを決定する工程と
を備える、方法。
【請求項２４】
請求項２３記載の方法であって、
前記変更要求は、実質的なトーン数に影響するように構成されている、方法。
【請求項２５】
請求項２３または請求項２４記載の方法であって、
前記マルチトーン信号は、前記変更要求が受信または実現されたことを示すものとして規定された応答コマンドを含まない、方法。
【請求項２６】
トランスミッタと通信する不連続マルチトーンモデムであって、
前記トランスミッタに変更要求を伝送するように構成されたレシーバであって、前記変更要求は、変更される特定のトーンを識別し、前記識別された特定のトーンに関連付けられたパラメータの所望値を識別するように構成され、前記レシーバは、前記トランスミッタからマルチトーン信号を受信し、前記変更の要求が前記トランスミッタによって実現されたか否かを決定するように構成され、前記変更の要求が実現されたか否かの決定は、変更されることを意図された前記マルチトーン信号の一部分の分析に少なくとも部分的に基づいて下され、
前記変更の要求が実現されたか否かの決定は、前記変更の要求が実現されたという前記トランスミッタからの前記変更要求が受信または実現されたことを示すものとして規定された応答を含まず、
前記パラメータの前記所望値は前記パラメータの現在の値であるカレント値と異なる、
モデム。
【請求項２７】
請求項２６記載のモデムであって、
前記レシーバは、受信された複数の第１のトーンと、受信された複数の第２のトーンとを分析するように構成され、前記第１のトーンは、前記第１のトーンに関連付けられたパラメータを含み、前記第２のトーンは、前記変更の要求に基づいて変更されたパラメータを含み、前記変更の要求は、前記トランスミッタにおいて実現され、前記レシーバは、前記第１のトーンの前記パラメータを前記第２のトーンの前記変更されたパラメータと比較することによって、前記第１のトーンが前記第２のトーンと異なるか否かを決定するように構成され、
前記第１および第２のトーンの前記パラメータが実質的に同じである場合は、前記変更は実現されず、前記第１および第２のトーンの前記パラメータが実質的に同じでない場合は、前記変更は実現された、モデム。
【請求項２８】
請求項２６記載のモデムであって、
前記レシーバは、第１のデコーダと第２のデコーダとを備え、前記第１のデコーダは、第１のトーンセットに関連付けられた複数の第１のパラメータ値を含み、前記第２のデコーダは、第２のトーンセットに関連付けられた複数の第２のパラメータ値を含み、前記第１のデコーダは第１のシンドロームジェネレータを備え、前記第２のデコーダは第２のシンドロームジェネレータを備え、これらのシンドロームジェネレータは、前記第１のシンドロームジェネレータに関連付けられた第１のシンドロームと、前記第２のシンドロームジェネレータに関連付けられた第２のシンドロームとを計算するように構成され、前記第１のシンドロームは、受信された複数のトーンのパラメータの値を、前記第１のトーンセットに関連付けられた前記第１のパラメータ値と比較するように構成され、前記第２のシンドロームは、受信された複数のトーンのパラメータの値を、前記第２のトーンセットに関連付けられた前記第２のパラメータ値と比較するように構成される、モデム。
【請求項２９】
請求項２６ないし請求項２８のうちの任意の１つに記載のモデムであって、
前記レシーバは、前記通信信号のトーンの１つをモニタし、第１の時点における前記トーンの第１の布置を、第２の時点における前記トーンの第２の布置によって分析するように構成される、モデム。
【請求項３０】
請求項２６ないし請求項２９のうちの任意の１つに記載のモデムであって、
前記レシーバは、前記通信信号のサブキャリアの１つをモニタし、該サブキャリアが前記変更要求の実現に基づいて０に等しくなるように変更されたモニタを含む、モデム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般に、マルチキャリア変調を用いた高速データ伝送システムに関する。より詳細には、マルチキャリア伝送システムでの利用に適した高速パラメータ変更コマンドおよびプロトコルが開示されている。
【０００２】
【従来の技術】
近年、高速モデムでのマルチキャリア変調の利用が注目を集めてきた。例えば、ＡＮＳＩ（米国規格協会）の規格グループの認定を受けたグループである通信情報ソリューション連合（ＡＴＩＳ）は、非対称型デジタル加入者網（ＡＤＳＬ）でのデジタルデータ伝送のための離散マルチトーンに基づいた基準を発表した。その基準は主に、通常の電話回線でのデータ伝送を意図したものであるが、様々な他の用途でも同様に用いることができる。北米の基準はＡＮＳＩ  Ｔ１．４１３  ＡＤＳＬ基準と呼ばれており、参照により本明細書に含まれる。ＡＤＳＬ基準のもとでの伝送速度は、ツイストペア電話回線で少なくとも毎秒６百万ビット（すなわち６Ｍｂｉｔ／ｓ）までの速度で情報を伝送するのを容易にすることを意図している。基準化されたシステムは、順（下流）方向で、それぞれが４．３１２５ｋＨｚの幅を持つ２５６の「トーン」すなわち「サブチャンネル」を用いる離散マルチトーン（ＤＭＴ）システムの使用を定義している。電話システムにおいては、下流方向は、電話局（通例は電話会社が所有）からエンドユーザ（すなわち自宅もしくはビジネス利用者）である遠隔地への伝送として定義されている。
【０００３】
ＡＤＳＬ基準は広く受け入れられているが、Ｔ１．４１３  ＡＤＳＬ基準の改善と、他のデータ速度での通信のためのＡＤＳＬもしくはその他の基準の提供に努力がなされている。例えば、現在、特に１２８のトーンのみを用いる簡易版の基準を定義する努力がなされている。この努力は、Ｔ１．４１３によってなされており、一般に、Ｇ．ライト基準化の取り組みと呼ばれている。また、かなり高速なデータのための基準を定義する努力もある。その取り組みは、ＶＤＳＬ（超高速デジタル加入者網）基準と呼ばれている。ＶＤＳＬ基準は、下流方向で少なくとも２５．９６Ｍｂｉｔ／ｓ、好ましくは少なくとも５１．９２Ｍｂｉｔ／ｓの伝送速度を容易にすることを意図している。これらの速度を実現するためには、ツイストペア電話回線での伝送距離を一般に、ＡＤＳＬで許容される長さよりも短くする必要がある。同時に、デジタルオーディオビデオ協会（ＤＡＶＩＣ）が、同様のシステムに関する活動を行っている。そのシステムは、ファイバトゥーザカーブ（ＦＴＴＣ）と呼ばれる。「カーブ」から顧客の建物までの伝送メディアは、標準的な非遮蔽ツイストペア（ＵＴＰ）電話回線である。
【０００４】
マルチキャリア変調を用いる高速ＤＳＬモデムに固有の１つの問題は、回線の状態の変動をどう処理するかというものである。例えば、Ｔ１．４１３基準とその他の提案されたＤＭＴベースのシステムでは、通信モデムは、データ通信が始まる前に短いトレーニング期間を経る。トレーニング期間中に、試験信号が伝送され、様々な周波数で回線の品質が効果的に試験される。一般に、回線の品質は、それぞれのトーンでの信号／ノイズ比（ＳＮＲ）によって決定される。次に、それぞれのトーンに割り当てられる「ビット」の数が、主に検出されたトレーニング信号に基づき決定される。しかしながら、トレーニング期間の後、伝送回線には、いくつかのトーンで割り当てられた速度で情報を伝送する能力に影響しうる変化が生じることがある。伝送回線の変化は、以下の様々な原因から生じる。顧客による受話器の上げ下ろし、温度により生じる回線の変化、近接した回線が活動もしくは非活動となることによる混線ノイズの変化、夜間のＡＭラジオ信号の増加。
【０００５】
時が過ぎて回線の品質が低下すると、エラーが起こる可能性が高くなり、割り当てられたビットアロケーションを調整するために何らかの作業を行う必要がある。ビットアロケーションを調整する１つの方法は、単にモデムを再トレーニングするという方法である。しかしながら、再トレーニングは、比較的多くの時間が掛かるという欠点があり、短時間の停電が生じる。Ｔ１．４１３基準で定義されたビットアロケーションを調整する他の方法は、「ビットスワッピング」と呼ばれる手順である。ビットスワッピングプロトコルは、或るトーンでエラーが検出された際に、そのトーンで伝送される情報の量をある程度のビット数を削減することを意図するものである。他のトーンが余分のＳＮＲを持っていると思われる場合には、相当する量だけ、情報伝送量が増加される。
【０００６】
Ｔ１．４１３基準では、ビットスワッピングプロトコルが明確に定義されている。より詳細には、あるレシーバが、ビットスワッピングが必要であると決定した場合に、そのレシーバは、オーバヘッドチャンネル（通例、ＡＯＣ−ＡＤＳＬオーバヘッドチャンネルと呼ばれる）を通じてビットスワッピングの要求を送る。ビットスワッピング要求は、図１に示されている指定フォーマットを持っている。示されているように、ビットスワッピング要求の第１のバイトはメッセージヘッダ１２である。メッセージヘッダ１２は、コマンドをビットスワッピングとして識別するヘッダすべてからなる。メッセージヘッダ１２の後には、８（または１２）バイトのメッセージ１４が続く。メッセージ１４は、４（または６）のセグメントに分割され、それぞれのセグメントは、メッセージフィールド１６と呼ばれる。それぞれのメッセージフィールド１６は、１バイトのトーンインデックス２０が続く１バイトのコマンド１８を含む。トーンコマンドは、コマンドが適用されるトーンを識別する。１バイトのコマンドは、以下の機能を含む。ビットの付加、ビットの消去、１，２，３ｄＢのパワー増加、１，２，３ｄＢのパワー減少、何も行わない、および独自のコマンド。
【０００７】
Ｔ１．４１３は、さらに、３バイトのビットスワッピング応答コマンドがビットスワッピングを要求したユニットに送り返され、ビットスワッピング要求の受信が確認されることを必要とする。ビットスワッピング応答コマンドは、スワッピングが実行される特定のシンボルカウントを指定する。応答コマンドは、単に新しいビット分布の実装を検出するために用いられるが、応答は、スワッピングの速度を遅くし、なお、応答が受信されない場合に障害を引き起こす可能性がある。
【０００８】
Ｔ１．４１３プロトコルは、さらに、ビットスワッピング要求コマンドが５回連続で伝送されることと、受信ユニットがそれら５回の伝送のほとんどを受信した場合に、受信ユニットのみがビットスワッピングコマンドに応答することを命令する。それゆえ、要求に応答するために１バイトと１５バイトの移動を要求するには、４５バイト必要となる（また、５回繰り返す必要がある）。待ち時間を無視すると、スワッピングに掛かる最短の時間は、３０ｍｓのオーダである（１６キロバイト／秒で６０バイト）。しかしながら、現在の基準は実際に、８００ｍｓに１回以上の頻度でスワッピングが起こらないことを要求している。それによって、トランシーバの簡略化が可能となるが、さらに、４つ以上のトーンが変更される場合には、スワッピングプロセスが遅くなる。それゆえ、標準的なＡＤＳＬビットスワッピングは、トランスミッタの遅い変動を許容する。しかしながら、スプリッタレスＡＤＳＬの出現と一般でのＤＳＬの普及に伴って、ＤＳＬ回線は、ビット分布の大幅な変更を必要とする突然の変更の影響を受けることが明らかとなった。基準化されたビットスワッピングプロトコルの遅さと再トレーニングが必要となるという欠点を考慮して、マルチキャリア伝送システム内でビットの再分布を実行する時間を減らすためには、さらに効率的なメカニズムが必要であることが明らかとなった。
【０００９】
【発明の概要】
本発明の以下の目的およびその他の目的を達成するために、マルチキャリアベースの伝送システムにおいて通信信号のパラメータ（サブキャリアゲインまたはビットアロケーションなど）を適応的に変更するための方法およびデバイスが開示されている。本発明の１つの態様では、変更の必要性を決定するユニットが、第２のユニットへ変更要求を送る。変更要求は、変更される１つ以上の特定のサブキャリアと、それぞれ識別されたサブキャリアに関するパラメータに対する所望の値を識別する。次に、要求ユニットは、要求した変更が実現されたか否かを決定するために受信する通信信号をモニタリングする。要求した変更が実現されたか否かの決定は、少なくとも一部は、変更されることになっていた受信された通信信号の一部の解析に基づく。
【００１０】
好ましい実施形態では、変更要求は、それぞれ識別されたサブキャリアに関するパラメータに対する所望の値だけでなく、変更される複数の特定のサブキャリアを識別するのに適している。例えば、パラメータは、関連するサブキャリアに対する所望のビットアロケーションもしくは所望のパワーレベル（ゲイン）でもよい。所望の値は、絶対値（例えば、このトーン上で８ビットを伝送）でも相対値（例えば、このトーン上で伝送されるビットの数を２だけ増加）でもよい。他の好ましい実施形態では、プロトコルは、変更要求が受信もしくは実現されたという明確な応答を含まない。
【００１１】
モニタリングは、様々な方法で行ってよい。例えば、いくつかの実施形態では、要求ユニットは、パラメータのカレント値とパラメータの所望の値の両方を用いて、受信された通信信号を重複してデコードする。この実施形態では、要求された変更が実現されたか否かの決定は、少なくとも一部はデコーディングに基づいて行われる。例えば、要求した変更が実現されたか否かの決定は、少なくとも一部は、それぞれのデコーディングを用いて検出されたエラーの解析と、エラーの少ないデコーディングの選択に基づいてもよい。もう１つのアプローチは、カレント値のデコードに基づく第１の前進型誤り訂正シンドロームと所望の値のデコードに基づく第２の前進型誤り訂正シンドロームを生成することである。このアプローチでは、変更要求が実現されたか否かの決定は、そのシンドロームの解析に基づいている。
【００１２】
いくつかの実施形態では、モニタリング工程は、変更要求によって変更されることになっている１つ以上の特定のサブキャリアをモニタリングする工程を含む。特定のサブキャリア上で変更が検出された場合、変更が実現されたと決定される。ここでも、モニタリングは、様々なメカニズムを使って行ってよい。例えば、マルチキャリア信号がＤＭＴ信号である場合、１つ以上のトーンのエネルギレベルをモニタリングすることができる。例えば、そのトーンに対して許容可能なパワーを増加する変更を行ってもよい。このシナリオでは、カレントのパラメータ値を用いて期待されたよりも大きいエネルギがそのトーンで検出された場合に、要求された変更が実現されたことを決定することができる。あるいは、トーンの１つをゼロにするか、ゼロにされたトーンをアクティブにすることもできる。これらの種類のアプローチは、比較的実施しやすく、変更を要求するユニットから明確なフィードバックを要求することなしに、変更の実現を検出するのを容易にする。
【００１３】
本発明の他の態様では、変更要求コマンドは、ヘッダ、高速スワッピング制御、少なくとも１つのサブキャリア識別子、少なくとも１つの所望のパラメータ値インジケータ、エラーフィールドを含む。ヘッダは、コマンドを変更要求コマンドとして識別する。高速スワッピング制御は、変更されたトーンカウントを指定する。トーンカウントは、変更要求コマンドによって変更されるトーンの数を示すものである。それぞれのサブキャリア識別子は、変更要求コマンドによって変更される特定のサブキャリアを識別する。それぞれの所望パラメータ値インジケータは、関連するサブキャリアのパラメータの所望の値を識別する。エラーフィールドは、変更要求を受信するユニットが変更要求コマンドの解釈にエラーがあるか否かを検出することを可能にする。いくつかの実施形態では、スーパーフレームナンバは、ヘッダに含まれていてもよい。他の実施形態では、スーパーフレームナンバは、高速スワッピング制御に含まれていてもよい。さらに、スーパーフレームナンバは、後に続くスーパーフレームがいくつあるか、もしくは、どのスーパーフレームで高速スワッピングが起こるかを特定する。
【００１４】
好ましい実施形態では、所望パラメータ値インジケータは、関連するサブキャリアに対する所望のビットアロケーションと所望のゲインの少なくとも一方を識別する。いくつかの実施形態では、特定のサブキャリアに対する所望のビットアロケーションと所望のゲイン両方を識別するために、１バイトを用いることができる。
【００１５】
本発明の他の態様では、レシーバ内に重複デコーダを含む改良モデム設計が開示されている。重複デコーダは、変更要求コマンドによって変更されることになっている少なくとも１つのサブキャリアに対する様々なパラメータを用いて、復調されたマルチキャリア信号をデコードするよう構成されている。次に、どの重複デコーダが訂正信号をデコードしたかを決定するために、アナライザが提供されている。
【００１６】
一実施形態では、重複デコーダは、同一のサブキャリアをデコードするよう構成されたサブキャリアデコーダである。他の実施形態では、重複デコーダは、マルチキャリア信号の複数のサブキャリアをデコードするよう構成された信号デコーダである。或る特定の実装では、アナライザは、重複デコーダによってデコードされた信号のシンドロームを生成するよう構成された重複シンドロームジェネレータを含む。
【００１７】
【発明の実施の形態】
いくつかの好ましい実施形態を参照し、関連する図を用いて、マルチキャリア伝送システムでの高速ビットスワッピングの実装に適した方法、デバイス、プロトコルを詳細に説明する。以下の説明では、本発明を完全に理解するために、数々の具体的な詳細が示されている。しかしながら、本発明がこれらの具体的な詳説のいくつかまたは全てをなしに実現できることは、当業者にとって明らかである。本発明を不必要に不明瞭にしないように、よく知られたプロセスのステップは説明されていない。
【００１８】
マルチキャリアベースの通信システムにおいては、チャンネルを適応的に変更する工程を容易にすることが一般的に望まれている。或る現行の実装（Ｔ１．４１３ＡＤＳＬ基準など）では、チャンネルを適応的に変更する工程を容易にするために、ビットスワッピングのコンセプトが用いられている。しかしながら、標準的なビットスワッピングの構成は、比較的遅く、そのために、特にチャンネルの多くの変更を扱う際には有効ではない。したがって、本発明は、チャンネルに対して適応的な変更を実現するための改良メカニズムを提供することを意図する。
【００１９】
一般に、本発明では、変更が妥当であるとトランシーバが決定した際に、トランシーバは、相手側に高速の変更要求を送信することが熟考されている。次に、要求しているトランシーバは、要求された変更が実現されたか否かを決定する信号をモニタリングし、それに従って受信された信号をデコードする。実例を挙げるために、本発明は、離散マルチトーン変調を用いるＤＳＬベースのポイントツーポイント双方向通信システムを用いて説明されている。しかしながら、記述されている技術はポイントツーポイントシステムだけでなく任意のマルチキャリア伝送システムに容易に応用可能であることは明らかである。
【００２０】
従来のビットスワッピング（ＳＢ）と開示されている拘束スワッピング（ＥＳ）の両方において、レシーバは、入力信号で発生しているエラーの量に基づき、変更の必要性を決定する。変更が必要であると決定されると、レシーバは、問題のあるトーンに対して最良の可能なビットアロケーションを決定する。例えば、レシーバが、或る特定のトーンでノイズ（エラーを起こすのに十分なノイズ）の増加を計測した場合、レシーバは、ビットの一部をそのトーンからノイズの少ない他のトーンへ再割り当てする。レシーバは、テーブル（通例、ビットおよびゲインアロケーションテーブルと呼ばれる）に所望のビットアロケーションを格納する。ほとんどの場合、ビットおよびゲインアロケーションテーブルは、マルチキャリア信号で用いられるトーンすべてに対するエントリを持っており、それぞれのトーンエントリは、対応するトーンに関するビットアロケーションとゲインまたはパワーレベルを含んでいる。変更が望まれると、レシーバは、トランスミッタに要求を送り、新しいアロケーションに対応する信号での変更を要求する。
【００２１】
議論を簡単にするために、図２は、典型的なビットおよびゲインテーブル５０を大まかに示している。ビットおよびゲインテーブル５０は一般に、トーンナンバフィールド５２、ビットアロケーションフィールド５４、ゲインまたはパワーレベルフィールド５６を含む。トーンナンバフィールド５２は、Ｇ．ライト基準に準拠した動作に対しては１２８のトーンのためのエントリを、Ｇ．ｄｍｔ基準に準拠した動作に対しては２５６のトーンのためのエントリを含んでいる。他のシステム（ＶＤＳＬ計画など）では、かなり多くのトーンが提案されているので、エントリの数が、広く変化する可能性がある。さらに、それぞれのトーンエントリ（１２８または２５６トーンの一方）は一般に、関連したトーンで伝送されるビットの数を決定するビットアロケーションを含む。それぞれのトーンのためのビットアロケーションは通例、ビットアロケーションフィールド５４に含まれている。或る特定のトーンに割り当てられたビットの数は、回線の状態、所望の伝送速度、用いられるプロトコルなどに基づいて広く変化する。例えば、それぞれのトーンに割り当てられたビットの数は、Ｇ．ライト伝送方式では０〜１１の範囲で、Ｇ．ｄｍｔ伝送方式では０〜１５の範囲で変化する。また、これらの数は、他のシステムにおいては広く変化することもある。さらに、それぞれのトーンエントリは一般に、関連したトーンで伝送エネルギレベルを決定するゲインアロケーションを含む。それぞれのトーンのためのゲインアロケーションは通例、ゲインアロケーションフィールド５６に含まれている。
【００２２】
次に、図３を参照して、本発明の一実施形態に従い、高速スワッピングコマンドのフォーマットを説明する。上述したように、変更が必要であるとレシーバが決定した場合、レシーバは、高速スワッピングコマンドをトランスミッタに送る。高速スワッピングコマンド１００は、メッセージヘッダフィールド１０２、高速スワッピング制御フィールド１０４、１つ以上の一連のトーンメッセージ１０６、エラーフィールド１０８を含む。ヘッダフィールド１０２は、コマンドを変更要求コマンドとして識別するヘッダ値を含む。高速スワッピング制御１０４は一般に、後に続くスーパーフレームの数、もしくは、高速スワッピングの行われるスーパーフレームを示すスーパーフレームナンバと、変更要求コマンドによって変更されるトーンの数を示すトーンカウントを含む。それぞれのトーンメッセージ１０６は、変更要求コマンドによって変更されるサブキャリアを識別するトーンインデックスと、識別されたトーンに対して所望のビット割り当てとゲインパラメータを示す所望値インジケータを含む。エラーフィールド１０８により、変更要求を受信するユニットが、変更要求コマンドの解釈にエラーがあるか否かを検出することが可能となる。
【００２３】
より詳細には、メッセージヘッダ１０２は、コマンドが変更要求コマンドであることと、適切なサイズであることを識別する。例えば、説明されている実施形態において、メッセージヘッダは、１バイトを占め、高速スワッピングコマンドとして事前に定義されるビットパターン（例えば１１１１００１１）を含んでいる。Ｇ．ｄｍｔもしくはＧ．ライトの実装において、スワッピングコマンドは、補助オーバヘッドチャンネル（ＡＯＣ）で伝送され、定義されたパターンで始まるＡＯＣで伝送されたメッセージはすべて、直ちに高速スワッピングコマンドとして認識される。さらに、ヘッダがコマンドの前に示されているが、ヘッダの位置に制限はなく、コマンドのどこに位置してもよいことに注意すべきである。
【００２４】
メッセージヘッダ１０２の後には、高速スワッピング制御１０４が続く。それは、高速スワッピングの行われるスーパーフレームと、変更要求コマンドによって変更されるトーンの数を示す。例えば、トーン（＃２、＃８０、＃９５）が変更要求で変更されることになっている場合、トーンカウントは３である。説明されている実施形態では、高速スワッピング制御１０４も、１バイトを占める。例えば、高速スワッピング制御１０４は、トランスミッタが次のスーパーフレームで高速スワッピングを実施する場合には、最も重要なビットを０に設定し、トランスミッタが次の次のスーパーフレームで高速スワッピングを実施する場合には、１に設定する。さらに、残りのビットには、トーンの数ｎが並び、それらは、コマンドで次の２ｎバイトによって変更される。Ｇ．ライト基準では、１２８のトーンが用いられるため、１バイト（残りの７ビット）は、１つのコマンドで変更されるトーンの任意の数もしくはすべてであっても許容できるほどに十分である。しかしながら、Ｇ．ｄｍｔ基準では、２５６のトーンが用いられるため、高速スワッピング制御のサイズを（例えば、８ビットに）増やすことが望まれる。さらに、他のシステムでは、２５６よりもかなり多いトーンを用いることが考えられている。例えば、提案されているＶＤＳＬシステムでは、４０９６のトーンを用いることが計画されている。そのようなシステムでも、高速スワッピング制御のサイズを（例えば、１２ビットに）増やすことが望まれる。
【００２５】
スーパーフレームナンバは、高速スワッピング制御の一部として記述されているが、これは制限ではなく、様々な方法で変更のタイミングを示すことができることに注意すべきである。例えば、スーパーフレームナンバまたはスーパーフレーム指定は、メッセージヘッダの一部でよく、また、タイミングは、レシーバとトランスミッタの間の固定されたアグリーメントの一部でもよい。例えば、スーパーフレームナンバの指定は、様々なメッセージヘッダを用いて行うことができる。さらに、スーパーフレームナンバは必ずしも必要でないことに注意すべきである。必要のない場合には、スーパーフレームナンバをコマンドから省くことができる。
【００２６】
高速スワッピング制御１０４の後には、一連のトーンメッセージ１０６が続き、それぞれが、トーンインデックス１１０と所望値インジケータ１１２を含む。それぞれのトーンインデックスは、変更要求コマンドによって変更される特定のサブキャリアを識別する。それぞれの所望値インジケータは、関連するトーンインデックスによって識別されたトーンに対して変更されるトーンパラメータのための所望の値を示す。開示されている実施形態では、トーンビットの割り当てとトーンパワー（ゲイン）が、変更される２つのパラメータである。それゆえ、所望値インジケータ１１２は、関連するトーンインデックスによって識別されたトーンのためのトーンビットの割り当てとゲインを識別する。所望の値は、絶対値（例えば、このトーンで８ビットを伝送し、ゲインを＋１．５に設定する）の形でも、相対値（例えば、このトーンで伝送するビットの数を２だけ増加し、ゲインをあるレベル増大させる）の形でもよい。
【００２７】
説明されている実施形態では、トーンインデックス１１０と所望値インジケータ１１２はそれぞれが、１バイトを占め、ここでも、システムの必要に応じてそれらのサイズを変更することができる。トーンインデックスのサイズは主に、利用可能なトーンの数による。２５６よりも多くのトーンが利用可能である場合には、トーンカウントは１バイトよりも大きい必要がある。しかしながら、Ｇ．ｄｍｔ基準（２５６トーンを想定）とＧ．ライト基準（１２８トーンを想定）では、１バイトで十分である。例えば、提案されているＶＤＳＬシステムでは、４０９６のトーンが想定されているため、そのような実装に対しては、トーンインデックスのサイズを１２ビットに増やすことが望まれる。
【００２８】
所望値インジケータ１１２は、関連するトーンインデックス１１０によって識別されたトーンのための所望のトーンビットの割り当てと所望のゲインを示す所望値インジケータ１１２の上位のニブル（すなわち最初の４ビット）は、関連するトーンに割り当てられる新しいビット数を示す。いずれのトーンの最大ビット数も、Ｇ．ライトでは１１（Ｇ．ｄｍｔでは１５）である。それゆえ、上位のニブルは、０ビットに対しては００００、２ビットに対しては００１０、．．．、１５ビットに対しては１１１１という具合にエンコードしてもよい。所望値インジケータ１１２の下位のニブル（すなわち後の４ビット）は、所望のゲインレベルを示す。割り当てられている４ビットにより、１６の異なるゲインレベルを指定することができる。ここでも、所望のゲインの値は、絶対値のレベルの形でも、相対値の変更量（例えば、１、２もしくは３ｄＢだけパワー増加、１もしくは２ｄＢだけパワー減少、変更せず）の形でもよい。例えば、離散マルチトーンの例では、いくつかの名義ゲインレベルに対して−４から＋３．５（０．５ｄＢごと）までの１６の異なるゲインレベルを、或る特定のゲインレベルに関するそれぞれの潜在的な値と共に指定することができる。均一なゲインレベルが説明されているが、所望のゲインの変更に利用できるゲインレベルの分布の方法には様々なものがあることを理解すべきである。さらに、増加量の相対サイズだけでなく、ゲインレベルの数も、ある特定のシステムの必要に応じて広く変化させることができる。
【００２９】
また、増加量は一様である必要はない。１５ビット以上をいずれかのトーンで伝送することができる場合、もしくは、１６以上のパワーレベルが望まれる場合には、所望値インジケータ１１２に１バイトを提供することが好ましい。例えば、サイズを２バイトに増やすと、実質的に解像度が増すことになる。もちろん、異なる、付加的もしくはより少数のパラメータが、或る特定のサブキャリアもしくはトーンに対して制御される場合には、それに従って、適切な情報を運ぶように所望値インジケータを適応させることができる。
【００３０】
一般に、２つのモデムが同期しない場合、次のスワッピングコマンドが所望の値を明確に示すので、所望の値として絶対値を用いると、ビットおよびゲインアロケーションを増加させることにより（相対的に）変更するよりも、やや信頼性が高いと考えられている。逆に、ビットスワッピングのように、パラメータを増加させることにより変更する場合、システムが同期から抜けても、システムの再トレーニングの不足を再同期化するメカニズムが存在しない。
【００３１】
高速スワッピングコマンドがビットエラーを含む可能性があるため、エラーフィールド１０８が、そのエラーを検出するために用いられる。エラーフィールドは、トランスミッタによる高速スワッピングコマンドの解釈を検証するために用いられる値（例えば、チェックサム）を含む。トランスミッタが、高速スワッピングコマンドの解釈にエラーを検出すると、トランスミッタは、要求された変更を実現しない。エラーなく有効に伝送された変更要求のみをトランスミッタが実現できるように、エラー検出が用いられる。また、エラーフィールド１０８のサイズは、適切なエラー検査構成の実装を容易にするために、広く変化させることができる。例えば、示されている実施形態では、エラーフィールド１０８は、高速スワッピングコマンドの後ろの２バイトを占めており、ＣＲＣ（巡回冗長検査）値を格納している。
【００３２】
ＣＲＣは、当業者に周知であるので、簡単のため、詳しく説明しない。しかしながら、高速スワッピングコマンドの伝送において１３ｄＢのマージンのロス（逆方向のリンクが、順方向のリンクと同じ障害に影響されるために、一時的に高いエラー確率を示すことがある）があった場合でさえ、ＣＲＣの失敗は、およそ２０年に一度しか起こらないと推定されていることに言及すべきである。そのため、回線の補修が必要なほど壊滅的なイベントを防ぐには、高速スワッピングコマンド伝送が実に信頼できる。
【００３３】
本発明の別の実施形態では、ＶＤＳＬのような他のフォーマットに対応するように、高速スワッピングコマンドを少し変更してもよい。そのような一実施形態では、サブチャンネルのＳＮＲの変更を検出する際に、レシーバは、ＶＤＳＬオーバヘッドチャンネル（ＶＯＣ）を経由してトランスミッタに高速スワッピング要求を送り返すことにより、高速スワッピングを開始する。ここでも、高速スワッピングコマンドは、一回だけ送信され、コマンドの伝送により、ｎトーンのビット分布（もしくはゲイン分布）の変更を可能とする。１つの実装では、ＶＤＳＬ高速スワッピングコマンドは、ＶＯＣメッセージフィールド、高速スワッピング制御フィールド、一連の１つ以上のトーンメッセージフィールド、ダミービットフィールド、エラーフィールドを含む。ＶＯＣメッセージヘッダは、１バイトを占め、１１１１００１０もしくは１１１１００１１のパターンのいずれかからなり、保証高速スワッピング要求を示す。ヘッダパターン１１１１００１０は、高速スワッピングが次のビットスワッピングフレームで実行されるべきであることを意味し、パターン１１１１００１１は、高速スワッピングが次の次のビットスワッピングフレームで実行されるべきであることを意味する。高速スワッピング制御は一般に、１２ビットを用い、ビット／ゲイン分布が更新される必要があるトーンの総数（ｎ）を示すよう構成されている。あるいは、ＶＤＳＬコマンドは、１つのヘッダ（１１１１００１１）と、高速スワッピングを実施するビットスワッピングフレームもしくは高速ビットスワッピングを実施するフレームの数を指定するための１ビットとトーンカウントを指定するための１２ビットを含むＥＳ制御のみを持つことにより、上述の高速スワッピングコマンドと同様に構成されていてもよい。
【００３４】
トーンメッセージは一般に、２０ビットを用い、サブチャンネルインデックスと所望値インジケータを含む。最初の１２ビットはサブチャンネルインデックスを示し、次の８ビットは所望値インジケータを示す。所望値インジケータの４ビットの上位ニブルは、ビットの新しい絶対数（０ビットは００００、２ビットは００１０、１５ビットは１１１１となる０から１５までの数）をエンコードし、４ビットの下位ニブルは、最も重要なビットサインビットとして、いくつかの既知の公称値に対する所望のゲインレベルをエンコードする（（０．５ｄＢずつ増加する）−４から＋３．５の間の２’ｓコンプリメント４ビット量による）。ダミービットフィールドは、コマンドがバイトに一様に記述されるように、高速スワッピングコマンドに対する総ビット量を調整するよう構成されている。したがって、ｎ（更新が必要なトーンの数）が偶数である場合には、ダミービットフィールドは、コマンドに４ビットを付加し、ｎが奇数である場合には、ダミーフィールドは、コマンドに任意のビットを付加する。エラーフィールドは一般に、エラーの検出に１６ビットのＣＲＣ保護を用いる。さらに、ダミーフィールドは制限とならず、コマンドは他の方法で構成されてもよいことに注意すべきである。例えば、コマンドは、可変長のエラーフィールドを持つように構成されていてもよい。
【００３５】
或るコマンドに対する特定のビットカウントと特定のビットパターンを実装例で説明したが、割り当てられるビットの実際の数と、特定のコマンドもしくはフィールドに用いられる特定のビットパターンは、いかなる場合の必要にも応じるよう広く変更することが可能であることは明らかである。
【００３６】
ビットスワッピングにおいて、応答コマンドは通例、トランスミッタによってレシーバに送られ、スワッピングが実施される時間を調整する。すなわち、トランスミッタは、或る特定のシンボルで変更を実現するという情報をレシーバに送る。対照的に、高速スワッピングにおいては、高速スワッピングを開始するレシーバが、返された信号をモニタリングし、トランスミッタによってコマンドが実現されたか否かを決定する。記述している高速スワッピングには、０ビットのスワッピング応答コマンドがある。これらの応答コマンドは、スワッピングのための実行時間を増加し、高速スワッピングでは回避されることが好ましいため、高速スワッピングが行われた時間を知るためにレシーバを必要とする。
【００３７】
次に、図４を参照して、本発明の一実施形態に従い、開示している高速スワッピング伝送方式の実装に適したモデムアーキテクチャを説明する。モデム２００は、トランスミッタ２０２を含む。トランスミッタは、エンコーダ２０６、離散マルチトーン変調器２０８、ウィンドウ操作フィルタ２１０、コントローラ２１１を含むいくつかの要素が組み込まれている。エンコーダ２０６は、伝送されるデータ（ビデオデータなど）を多重化、同期化、エンコードする機能を持つ。より詳細には、エンコーダは、多重なサブチャンネル各々に対して、入力ビットを同位相の直交要素に変換する。エンコードは、様々なエラー訂正方式を用いて行うことができる。例えば、前進型誤り訂正は十分に機能する。エンコーダ２０６は通例、システムに利用可能なサブチャンネルの数と等しいサブシンボルシーケンスの数を出力するよう構成される。例えば、２５６のサブチャンネルを有するシステムでは、エンコーダ２０６は、制限された周波数帯域で２５６サブシンボルシーケンスからサブチャンネルの数を引いた値を出力する。これらの入力は、離散マルチトーン変調器２０８に通される複合入力である。変調器２０８は一般に、任意の適したアルゴリズムにより逆フーリエ変換を計算するＩＦＦＴ変調器である。
【００３８】
エンコードされた信号が変調され、離散マルチトーン信号を形成した後、変調された信号は、ウィンドウ操作フィルタ２１０および／またはその他のフィルタを通され、帯域エネルギの不足を最小化する。リモートレシーバのアナログインタフェースが飽和するのを防ぐには、これが望ましい。ウィンドウ操作は、様々な従来のウィンドウ操作プロトコルによって行うことができる。また、トランスミッタは、アナログインタフェース２１２を含んでいる。アナログインタフェースは、離散マルチトーン信号を伝送メディアに送信する。ツイストペア電話回線や同軸ケーブルのような配線システムでは、アナログインタフェース２１２は回線ドライバの形を取ってもよい。
【００３９】
また、モデム２００は、トランスミッタからマルチトーン信号を受信するためのレシーバ２０４を含む。レシーバ２０４は一般に、アナログインタフェース２１４、タイムドメインイコライザ（ＴＥＱ）２１６、復調器２１８、デコーダ２２０、コントローラ２２１を含む。モデム２０４によって（トランスミッタから）受信された信号は、まず、アナログインタフェース２１４を通して受信される。タイムドメインイコライザ２１６は、受信された信号に対してフィルタリング機能を有効に実行する。ウィンドウ操作フィルタ（図示せず）を用いてもよい。復調器２１８は、等化された離散マルチトーン信号を復調し、デコーダ２２０は、復調された信号をデコードする。復調器２１８とデコーダ２２０はそれぞれ、変調器２０８とエンコーダ２０６の逆の機能を有効に実行する。例えば、復調器２１８は一般に、任意の適したアルゴリズムによりフーリエ変換を計算するＦＦＴ変調器である。次に、デコードされた信号は、デコーダ２２０から、テレビ電話、テレビ、コンピュータ、その他の適切な受信装置などのリモートデバイス２２２へ通される。
【００４０】
離散マルチトーンシステム（ＤＭＴ）では、ＤＭＴ信号のビット分布は、システムの伝送性能を向上するように適応的に決定される。これを容易にするために、システムは一般に、通信回線をモニタリングして利用可能なサブチャンネル各々の回線の質を決定する回線モニタ（図示せず）を備える。一実施形態では、回線モニタは、ノイズレベル、各サブチャンネルのゲインおよび位相の変動を決定する。目的は、各サブチャンネルの信号／ノイズ比を評価することである。それゆえ、上述のパラメータに加えてもしくはその代わりに、他のパラメータをモニタリングしてもよい。各サブチャンネルで伝送されるデータ量の決定はもちろん、エンコードされたデータを伝送するサブチャンネルの決定も、いくつかの要素に基づき動的に行われる。その要素は、検出された回線品質パラメータ、サブチャンネルゲインパラメータ、許容パワーマスク、所望の最大サブキャリアビット誤り率を含む。それらの要素は、サブチャンネルの間で一定である必要がなく、使用中に変化してもよいことが注目される。さらに注目に値することには、回線品質パラメータは、繰り返し検査されることが可能であり、リアルタイムで変調方式での調整がなされ、様々なサブチャンネルの回線品質が使用中に変化するのに応じて、動的に変調を調整する。チャンネルのモニタリングについては、以下で詳細に説明する。
【００４１】
ほとんどの構成で、レシーバ２０４は、チャンネルの性能をモニタリングしＤＭＴの適応を制御するよう構成されている。例えば、コントローラ２２１は、上述したように回線モニタを備えてもよい。特に、レシーバ２０４は、チャンネル出力信号をモニタリングし、トランスミッタのビットおよびゲインテーブル２２４の変更の必要性を確認する。そのテーブルは、ビット数とそれに対応した伝送エネルギ（もしくは同等物）を格納し、各ＤＭＴトーン（もしくはサブチャンネル）によって用いられる。トランスミッタ２０２とレシーバ２０４は共に、同じテーブルのコピーを格納し、それぞれが、エンコードとデコードのためにそれらを用いる。例えば、図２に示され説明されているテーブルを用いてもよい。理解されるように、伝送回線が時間と共に変化するのに応じて伝送性能の改善を引き起こすこれらのテーブルの変更が、連続的なモニタリングにより決定される。さらに、ＡＯＣ（ＡＤＳＬオーバヘッドチャンネル）２２６は通例、点線で示されているように、レシーバ２０４からトランスミッタ２０２に戻される。よく知られているように、ＡＯＣ２２６は、通信のためにレシーバとトランスミッタの間で用いられるシステムの全帯域の専用部分である。例えば、２５６トーンのシステムの最初の３２のトーンは、ＡＯＣ２２６のために確保してもよい。
【００４２】
変更の必要性を決定する際、コマンド（例えば、変更の要求）が、ＡＯＣ２２６を通してトランスミッタ２０２に送られる。ほとんどの実施形態で、トランスミッタのビットおよびゲインテーブル２２４の構成（例えば、ＤＭＴ伝送に用いられる各トーンのビット数および／または伝送エネルギレベル）を変更するよう、トランスミッタ２０２に命令するために、コマンドが用いられる。例えば、コマンドは、図３に示され説明されている高速スワッピングコマンドでもよい。コマンド受信後に、トランスミッタ２０２は、要求された変更を実現する。上述のように、エラーなく有効に転送された変更要求のみをトランスミッタ２０２が実現できるように、ＡＯＣ２２６上でエラー検出が用いられてもよい。
【００４３】
高速スワッピングにおいて、レシーバ２０４は、入力ＤＭＴ信号をモニタリングして、要求された変更がトランスミッタによって行われたか否かを決定するように構成されている。より詳細には、レシーバ２０４は、現在用いられている信号（「カレント信号」）に関するトーン（サブチャンネル）と、所望の信号（「要求信号」）に関するトーンを認識するように構成されている。この情報に関して、レシーバは、入力信号のトーンをカレント信号のトーンもしくは所望の信号（変更要求の信号）のトーンと比較することにより、変更の要求が実現されたか否かを確認できる。カレント信号を例とすると、入力信号のトーンがカレント信号のトーンと実質的に同じである場合、レシーバは、変更の要求が実現されていないと決定することができる。一方、入力信号のトーンがカレント信号のトーンと実質的に異なる場合、レシーバは、要求が実現されたと決定することができる。本発明は、カレント信号もしくは変更要求信号を別個に用いることに限定されず、それらを組み合わせて用いてもよいことに注意すべきである。すなわち、入力信号のトーンを、カレント信号のトーンと変更要求信号のトーン両方と比較することができる。
【００４４】
さらに詳しく述べると、高速スワッピングレシーバは一般に、古いビット／ゲインテーブル２２７と新しいビット／ゲインテーブル２２８とを含む。古いビット／ゲインテーブル２２７は、レシーバ２０４が変更の必要を決定する前に用いられていた信号に関するもので、新しいビット／ゲインテーブル２２８は、レシーバ２０４が変更の必要を決定した後に要求された信号に関するものである。デコーダ２２０は、両方のテーブルを用いて、入力信号が古いか新しいかを決定する。すなわち、古いチャンネルゲイン（古いテーブル）、新しいチャンネルゲイン（新しいテーブル）、もしくは新旧両方のチャンネルゲインの組み合わせ（古いテーブルと新しいテーブル）に従って、入力信号をデコードすることができる。それに応じて、入力信号が、古いビット／ゲインテーブル２２７で動作する場合、デコーダ２２０が信号を古いビット／ゲインテーブル２２７と比較する際のエラーは少数で、デコーダ２２０が信号を新しいビット／ゲインテーブル２２８と比較する際のエラーは多数である傾向があるだろう。逆に、入力信号が、新しいビット／ゲインテーブル２２８で動作する場合、デコーダ２２０が信号を新しいビット／ゲインテーブル２２８と比較する際のエラーは少数で、デコーダ２２０が信号を古いビット／ゲインテーブル２２７と比較する際のエラーは多数である傾向があるだろう。したがって、レシーバ２０４は、これらのデコードに基づいて変更がなされたか否かを決定することができる。
【００４５】
さらに、レシーバが上述の比較を行うことが可能であっても、比較的迅速に行う必要がある。それゆえ、レシーバは、或る特定の期間、入力信号を解析するように構成され、この期間内に変更の要求が検出されない場合には、レシーバは、トランスミッタが変更を実現しなかったことを認識する。例えば、最後のＡＯＣバイトが送られた後に、レシーバが、受信されたチャンネル出力のビットテーブルに変更がないことを認識した場合、レシーバは、トランスミッタが何らかの理由で高速スワッピングを実行できなかった、もしくは、実行できないことを認識する。一実施形態では、ダウンストリームとアップストリームの待ち時間と中断時間を合わせた間に、変更の要求が検出されなかった場合、レシーバは、トランスミッタがコマンドを実現しなかったと認識する。次に、レシーバは、性能が許容不可能な場合には、高速スワッピングコマンドの再送信、他の正しいコマンドの利用、再トレーニングの実行のいずれかを選択すればよい。１つの特定の実施形態では、中断時間が次のスーパーフレームの境界に選ばれる。それは、上手く機能すると思われる。この実施形態では、最悪の場合の中断時間１７ｍｓが提供されている。しかしながら、中断時間は、非常に速くなるように構成されている。例えば、中断時間は、約２ｍｓに構成されていてもよい。
【００４６】
モデムアーキテクチャを詳細に説明したが、本発明の趣旨および範囲から逸脱しない範囲内で、他の多くの特定の形態でモデムアーキテクチャを実現できることを理解する必要がある。
【００４７】
本発明の一態様に従って、要求レシーバは、２つのデコーダを用いて、古いビット／ゲインテーブル（例えば、カレント信号）と新しいビット／ゲインテーブル（例えば、変更要求信号）により入力信号をデコードするよう構成されている。要求された変更が実現されたか否かの決定は、少なくとも一部はこれら２つのデコードに基づいてなされる。例えば、変更の要求が実現されたか否かの決定は、少なくとも一部は、各デコードを用いて検出されたエラーの解析と、エラーの量が最小のデコードの選択に基づいて行うことができる。通例、エラーの量が最小の信号は、伝送されている信号である。したがって、レシーバは、変更の要求が実現されたか否かを決定することができる。
【００４８】
図５を参照し、デュアルデコーディングレシーバ３００を本発明の１つの実施形態にしたがって説明する。デュアルデコーディングレシーバ３００は、第１のデコーダ３０２と、該第１のデコーダ３０２に実質的に類似の第２のデコーダ３０４とを備える。この実施形態において、第１のデコーダ３０２は、第１のトーン（例えばカレント信号）のセットに関連付けられたビット／ゲインテーブル２２７を格納するように構成され、第２のデコーダ３０４は、第２のトーン（例えば変更の要求を含んだ新しい信号）のセットに関連付けられたビット／ゲインテーブル２２８を格納するように構成されている。
【００４９】
デュアルデコーディングレシーバ３００は、また、第１のデコーダ３０２に関連付けられた第１のシンドロームジェネレータ３０５と、第２のデコーダ３０４に関連付けられた第２のシンドロームジェネレータ３０６と、を備える。例えば、前進型誤り信号訂正（ＦＥＣ）シンドロームを利用したＦＥＣデコーダを使用しても良い。第１のシンドロームジェネレータ３０５は、カレントチャンネルのゲインおよびノイズを使用し、入力信号の受信トーンに関して第１のシンドロームを計算するように構成されている。同様に、第２のシンドロームジェネレータ３０６は、新しいまたは推定されたチャンネルのゲインおよびノイズを使用し、入力信号の受信トーンに関して第２のシンドロームを計算するように構成されている。最小量のエラーを検出するシンドロームジェネレータによって、コレクトマッチを獲得することができる。ここで、レシーバ３００が、一般に、（例えば変更の要求後に）スワップが発生することを知っている場合にシンドロームを計算するように構成されていることに、注意が必要である。また、デュアルデコーディングレシーバ３００は、コレクトシンドロームを有した信号を開放するために一般的に使用されるスイッチ３０８を備える。コントローラ２２１は、コントローラ２２１内に設けられたスイッチ３０８を制御するために使用されるのが通常である。ただし、（図示されるように）これは必要不可欠ではない。
【００５０】
さらに詳述すると、算出されたシンドロームにおいては、コレクトマッチが０で示され、インコレクトマッチが１で示されるのが一般的である。例えば、第１のシンドロームジェネレータ３０５の計算結果が０で、第２のシンドロームジェネレータ３０６の計算結果が１である場合は、入力信号が第１のトーンセットのビット／ゲインテーブルに正しくマッチするので、レシーバ３００は、実現するべき変更要求がまだ存在すると認識する。前述したように、これが特定期間に渡って生じると、レシーバはタイムアウトし、変更の要求が実現しなかったと認識する。この場合、レシーバは、別の高速スワップコマンドや何らかの他のコマンドを送信するか、または性能が許容不可能である場合には再トレーニングするかのいずれかを選択しても良い。反対に、第１のシンドロームジェネレータ３０５の計算結果が１で、第２のシンドロームジェネレータ３０６の計算結果が０である場合は、入力信号が第２のトーンセットのビット／ゲインテーブルに正しくマッチするので、レシーバは、変更の要求が実現されたことを知る。
【００５１】
さらに、これらのシンドロームの計算結果がともに０でない場合、回線の状態は、もともと要求された高速スワップが正しくなかったものと考えられる。これは、レシーバの設計ミスであり、許可されたビット分布に対する回線の動作が不能になったので、モデムは、インジケータ（例えば不良ＬＥＤ）を再トレーニングするまたは起動する必要がある。すなわち、レシーバシステムが高速スワップによって回線を修復できない場合は、回線のメインテナンス状態を再トレーニングするまたは合図する必要がある。さらにまた、これらのシンドロームの計算結果がともに０である場合は、チャンネルビット／バイトのエラーパターンが厳密に別の（インコレクト）コードワードに対応するので、エラーの検出は失敗すると考えられる。このような故障が生じる可能性は、ＣＲＣの失敗が生じる可能性より大幅に小さいので、実際の用途においては０であると想定することができる。それにも拘らずこのような故障が生じた場合、レシーバは、次のコードワードをチェックして次いでカレントテーブルおよび直前のテーブルをピックすることによって、出力をさらに遅延させるように選択することができる。故障率は、これ以上の引き下げが不要なほどに低いのが通常である。ここで、この珍しいタイプの故障ですらモデムに対して破壊的でも弱点でもなく、単に、エラー（１つのコードワード）が生じてもモデムが上手く動作を続けていくことを意味するだけだということに、注意する必要がある。
【００５２】
本発明の別の態様に従うと、変更の要求が実現したか否かの決定は、変更要求によって変更されることを意図される１つまたはそれ以上のトーンをモニタすることを含む。これらのトーン上で変更が検出されたら、変更は実現されたと想定される。高速スワップはこれ以外の場合は変更を要求していないので、このようなトーンは他よりも信頼度が高い。１つまたはそれ以上のトーンのエネルギのレベルおよびビットアロケーションがモニタされる。例えば、変更によって、特定のトーンに使用可能なパワーが増す。このシナリオでは、カレント信号を使用した場合よりも多くのエネルギがその特定のトーン上で検出された場合に、要求された変更が実現されたと想定することができる。別の実施例では、変更によって、特定のトーンのビット数が減少する。カレント信号を使用した場合よりも少ないエネルギがその特定のトーン上で検出された場合は、要求された変更が実現されたと想定することができる。
【００５３】
１つの実施形態において、要求を出すレシーバは、変調された出力（ＦＦＴ出力）のトーンを少なくとも１つモニタするように構成されている。これらのトーンは、高速スワップによってビット数の増加を要求されたトーンであることが好ましい。これらのトーンは、さらに多数のビットを扱えるようになるので、一般により強健（例えばノイズがより少ない）である。しかしながら、これは限定的ではなく、ビット数が減少されたトーンを使用しても良いことに注意する必要がある。変更の要求が実現されたか否かの決定は、少なくとも部分的には、入力信号の出力布置の変更に基づいて下される。出力布置は、特定のトーンにおけるビットの分布を図示したものである。出力布置は、一般に、位相の推移と特定トーンの振幅との両方を含む。議論を促進するため、図６ａに、４ビットを割り当てられたトーンの代表的なＦＥＱ（周波数イコライザ）出力布置４００を示した。出力布置は当該分野で周知であるので、簡略化を図るためこれ以上の説明を省略する。
【００５４】
さらに詳述すると、第１の信号における特定トーンの第１の出力布置と、第２の信号における同じトーンの第２の出力布置とを比較することによって、変更の要求が実現されたか否かが決定される。第２の出力布置が第１の出力布置より大きい場合、レシーバは、変更の要求が実現されたことを知る。例えば、変更の要求によって特定トーン上のビット数が２だけ増加した場合、そのトーンの出力布置上の点は４倍に増える。議論を促進するため、図６ｂに、６ビットの出力布置５００（すなわち、２ビットが増加した後の４ビットの出力布置４００）を示す。４ビットの出力布置４００には１６個、そして６ビットの出力布置５００には６４個の点が存在する。図６ａが第１の信号を表し、図６ｂが第２の信号を表すと仮定すると、レシーバは、変更の要求が実現されたか否かを受信信号の性質に基づいて決定することができる。例えば、（１６点の布置から得られる）第１の信号の最大ゲイン（振幅）は、（６４点の布置を有した）第２の信号の最大ゲイン（振幅）より小さい。
【００５５】
特定の実装形態では、特定のトーンに対して重複した１対のトーンデコーダを利用することによって、出力布置の比較を行っても良い。デコーダは、マルチトーン信号で使用される各トーンに対して複数の個々のトーンデコーダを有するのが一般的である（例えば、Ｇ．ライトに対して１２８個、Ｇ．ｄｍｔに対して２５６個）。個々のトーンデコーダは、伝送された信号をデコードする際に、そのトーンに対して特定の出力布置を出力する。特定のトーンに対するトーンデコーダの数を倍に増やすと、第１の出力布置を有した第１の伝送信号を第２の出力布置を有した第２の伝送信号と比較することによって、変更の要求が実現したか否かを決定することができる。しかしながら、特定のトーンデコーダを全て倍に増やすことは可能であるものの、適切な信頼度でもって変更を決定するためには、数個のトーンデコーダを倍に増やすだけで良い。
【００５６】
重要なのは、ノイズの存在下では、１ｄＢまたは２ｄＢのゲインの変更を正しく識別できないことである。しかしながら、他のトーン上のゲイン変更に関連して生じる１トーン上のゲイン変更は、より高い信頼度で検出することが可能である。したがって、レシーバは、変更の要求が実現されたか否かを決定するに当たって、１つのトーンをモニタリングすることに限定されない。レシーバは、ビットの増加および／または減少ならびに追加のゲイン変更を生じた複数のトーンをモニタリングしても良い。
【００５７】
別の実施形態において、レシーバは、高速スワッピングコマンド内のグッドトーンを一時的に０にし、変更要求がトランスミッタによって実現されたか否かを決定するように構成されても良い。そのトーン上における伝送エネルギの欠如は、トランスミッタによって変更要求が実現されたことを示す。同じトーンを後に再作動させる（そしてエネルギの存在によって再検出される）第２の高速スワッピングコマンドは、マージンをフルレベルまで再格納することができる。１トーンの損失が性能に及ぼす影響は小さいのが通常であるが、一般にはチャンネルにも依存する。
【００５８】
以上から、ＤＭＴシステムにおいて高速スワップ（または任意のスワッピング）を有効に使用するためには、正確且つ迅速なチャンネルの識別が非常に重要であることが理解できる。低精度または不正確なチャンネルのモニタリングは、他のあらゆるリーズナブルな回線変更よりもずっとＤＭＴの伝送故障を招きやすいが、これは突然に生じる。したがって、チャンネルを首尾良くモニタリングするための実施形態を幾つか説明する。ここで、以下で述べる方法は限定的ではなく、回線の状態をモニタリングするための独創的なメカニズムは数多く存在することを、理解する必要がある。また、これらの方法が、一般に、ビット／ゲイン分布におけるマイナーな差異よりも、チャンネルのグロス変更を扱う場合において最も有用であることを、理解する必要がある。例えば、チャンネルのグロス変更は、ＤＭＴシステムの少なくとも１つのトーンにおいてスライサービットエラーを生じるほどにグロスである可能性がある。このようなチャンネル変更を識別できるならば、高速スワッピングは、このタイプの状況でチャンネルを迅速に訂正するのに有用である。
【００５９】
例えば、少なくとも３種類の測定によってグロス変更が強く示される。すなわち、シンドロームが０でないこと、ＣＲＣバイオレーションがスーパーフレームレベルであること、そして瞬間または短期の平均平方エラー／ノイズの推定値が高いことの３つである。レシーバは、これら３つのうち任意または全部を平凡に測定し、グロス変更状態に入ることを決定することができる。グロス変更状態では、チャンネルの出力パワーを迅速に測定することができる。ノイズは、対象となる任意のトーン上において、レシーバに送信される信号より少なくとも１０ｄＢだけ低いのが通常であるので、瞬間的なチャンネル出力パワーの推定値は、チャンネルゲインの変更を確認できるだけの精度を有する。例えばオフ／オンフックインピーダンスの変更によって生じたチャンネルゲインの変更は、同時に多くのサブチャンネルにも影響するので、新しく作動されたクロストークノイズから容易に識別することが可能である。
【００６０】
チャンネルの変更は、一般に、測定されたチャンネルの移送機能の変更に対応している。これらの変更は、回線の減衰やチャンネルの遅延等の変更と同じくらい顕著である。チャンネル温度の変化は、非常に低速であって且つＳＢまたはＥＳのいずれかによって充分に扱えるチャンネルの変更を引き起こす。雨天時において水が入ったケーブルによって生じる湿度の変化は急速である（そして回線の故障を引き起こす場合が多い）。湿度が充分に小さく、チャンネルが動作可能な状態を維持できる場合、チャンネルは、１秒またはそれ以内で急速に変更することができる。オフ／オンフックインピーダンスの変更は、チャンネルゲインの変化のうち最も急速なタイプであり、ほぼ全部の伝送バンドに渡って１〜１０ｄＢの減衰ロス／ゲインを引き起こすのが通常である。
【００６１】
ゲインの変更を検出するため、レシーバは受信パワー全体をモニタリングする。受信パワーが大きく変化した場合は、ゲインパスの追跡が行われ、ノイズパワーは変化しなかったものと推定される。チャンネルの総出力パワーの変化は、一般に、チャンネル出力サンプルの平方の和をモニタリングすることによって検出される。チャンネル出力パワーの１ｄＢまたはそれ以上の変更は、１０００個またはそれ未満のサンプルを使用することによって、（Ｇ．ライトサンプリング率では１ｍｓ、他のＤＳＬではさらに高速で）高い信頼度で推定するこことができる。周波数（トーン）に対するチャンネル変更の依存性を識別する方法は、同期シンボル（最悪でも１７ｍｓしか離れていない）が次に生じた際に、チャンネルＦＦＴ出力を既知の同期シンボルＦＦＴによって割るものである。ノイズは変化していないので、任意の使用済みトーン上の信号よりかなり小さい。新しく推定されたトーンゲインのセットは、格納された過去からのチャンネルプロフィルと比較することができる。レシーバイコライザは、新しく算出されたゲインに応じて直ちに更新することができ、結果として得られる新しいビット分布が、ＥＳコマンドによって直ちにトランスミッタに伝達される。全体の推定時間は、新しいビット分布が既知となるまでに２０ｍｓぐらいで良い。
【００６２】
第ｎトーン上の周波数領域において、出力Ｙnは数１によって入力Ｘnに関連付けられている。
【００６３】
【数１】
0004733835.tif 000002
【００６４】
ここで、ＨnおよびＮnはチャンネルゲインおよびノイズパワーである。（事前の初期化、再トレーニング、または高速スワップをもとに）事前に識別されたチャンネルゲインのセットは、ＤＭＴシステムが事前に識別した各チャンネルプロフィルために格納することができる。これらの格納されたプロフィルは、ｌ＝１，...,の場合にＰl,nで表される。ＤＭＴシステムクロックは、プロフィルが最後に生じたときから相対的なタイミングオフセットεだけずれるので、古いプロフィルの設定から線形に位相偏移を生じる。
【００６５】
【数２】
0004733835.tif 000003
【００６６】
首尾良いプロフィル検出によって、事前のプロフィルのなかに、同期シンボルの既知のＸnに対して最後に測定されたＨnに最も良くマッチするプロフィルが存在するか否かが識別される。
【００６７】
先ず、プロフィルは既知でないので、プロフィルを生成しなければならない。Ｈnの単純な推定値は、数３である。
【００６８】
【数３】
0004733835.tif 000004
【００６９】
ここで、Ｍは使用された同期シンボルの数である。Ｍが大きいほど正確なチャンネル推定値を得ることができるが、訂正高速スワップの実現は遅れる。推定値の差異はＭに比例して減少するのが一般的であるので、測定されたＳＮＲは、９９％の確定度で、数４だけ高すぎるまたは低すぎる（高すぎると問題になる）。
【００７０】
【数４】
0004733835.tif 000005
【００７１】
４つの同期シンボルを経ると、算出されたＳＮＲエラーは９９％の確定度で２ｄＢ未満になる。あらゆるレシーバゲイン／位相回転（一般に「ＦＥＱ」と称される）を、数５の比で直ちに調整する必要がある。そして、もし必要ならば、新しいチャンネルをプロフィルの１つとして格納することができる。
【００７２】
【数５】
0004733835.tif 000006
【００７３】
しかしながら、あるプロフィルが事前に識別されていた場合は、このプロフィルの再発生を最大尤度のプロフィル検出に従って高信頼度で検出するために、同期信号を単独で使用することができ、こうして、（可能なベクトルプロフィルＰlに対する）和を最小化するプロフィルが選択される。
【００７４】
【数６】
0004733835.tif 000007
【００７５】
偽のプロフィルが検出される可能性は、ノイズおよびプロフィル間の近さに依存し、特に、数７による制約を受ける。
【００７６】
【数７】
0004733835.tif 000008
【００７７】
ここで重要なのは、互いに混同された２つのプロフィルが近すぎて、対応するビット／ゲインテーブルが機能的である場合は、偽の検出はリンクの機能異常に対応しないことである。レシーバエキスパートシステムによってプロフィルを厳密に維持することによって、対応する訂正ビット分布がＤＭＴのリンク故障に通じる偽の検出を生じる可能性が非常に低いように、プロフィルを選択する必要がある。
【００７８】
さらに、パワーの合計測定値によって顕著なチャンネルゲイン（または出力パワー）の変更が検出されなかった場合は、顕著なノイズの変更が想定される。ノイズの差異を正確に推定するためには、トレーニング信号を使用した場合であっても、ＤＳＬモデムにおいて数秒の時間を要する。しかしながら、通常のように、ノイズ導入前のマージンが高かった場合は、サブチャンネルを慎重にロードすることが可能である。ガウスのノイズサンプルは、０．９９７の可能性で±３σ（３標準偏差）分布点の範囲内に入るのが通常である。ノイズが１０ｄＢまたはそれ以上増加すると、６ｄＢのマージンで１ｅ−７でもともと動作しているＤＳＬモデムにおいて、許容不可能なほど高い誤差率が引き起こされる。レシーバ内のＦＦＴ出力におけるスライサーエラーの有無に拘らず、大きいノイズに対するエラーサンプルの分布には、より大きな差異が存在する。レシーバは、一般に、その分布を推定することができる（ガウスノイズに関しては、この分布によって差異が推定される）。新しいノイズの厳密な差異を非常に正確に推定するためには相当数のサンプルが必要である（１／１０ｄＢの精度を得るためには３２００程度のサンプルが必要であり、これは、非効率的なエスティメータを使用した場合でも１秒以内のトレーニングですむ）一方で、大きな変更に対応してより高速なグロスインジケータを使用することも可能である。顕著なノイズの増加が検出されたこれらのトーンは、ＥＳを介してビットテーブル内でゼロ化される。これらのトーンがＥＳ要求に応じて非動作されるのに伴って、後続のノイズの推定を継続することができる。ローディングの結果がより正確である場合は、後続のＥＳコマンドによって、より詳細化されたビット分布を伝送することができる。さらに、ＩＳＤＮクロストーク、ＨＤＳＬクロストーク、または他タイプの既知のクロストークに近いノイズプロフィルを最初に概算し、次いで高性能のレシーバで詳細化することによって、ＥＳコマンドを介した非常に高速な調整が可能になる。
【００７９】
さらに詳述すると、ノイズの変更が大きい場合は、何の信号も伝送しない、すなわちトーンから０を出力することが、ノイズを決定する効果的な方法である。以下では、トーンの出力ゼロ化によってノイズを推定する方法を幾つか説明する。
【００８０】
一般に、チャンネルの変更がなくて（仮定）同期シンボルが既知である場合には、各トーンの瞬間的なノイズサンプルを決定することができる。これは、数８によって最適に表される。
【００８１】
【数８】
0004733835.tif 000009
【００８２】
ノイズパワーは、数９によって推定される。
【００８３】
【数９】
0004733835.tif 000010
【００８４】
次いで、レシーバは、これらのトーンをゼロ化するよう、ＥＳコマンドを介してトランスミッタに通知する。ここで、数１０は、もとのノイズパワーに比例した特定の閾値より大きい。
【００８５】
【数１０】
0004733835.tif 000011
【００８６】
一般に、ノイズの推定を高速化するためには、レシーバが、小さい値をＭとして選択しなければならない。すると、ノイズパワーの推定が不正確になり、このためにトーンの出力ゼロ化のプロフィルが不正確になる恐れがある。トーンの出力ゼロ化のプロフィルの精度は、ノイズ差異のパワースペクトル密度が比較的滑らかであると想定することによって、改善することが可能である。このような滑らかさを想定することを利用したクラスタ化の方法は、数多く存在する。
【００８７】
１つの実施形態において、連続したトーンセットをクラスタ内で規定する状況は、一般に、ゼロ化されたまたは未使用のトーンであるエンドトーンであり、クラスタに先行するおよび後続するトーンは使用後のトーンである。この実施形態では、モデムによる使用を意図したトーン（すなわち非ＰＯＴＳトーン）のみを対象とする。一般に、ゼロ化トーンは、ノイズが充分大量に増加したために０ビットを伝送するトーンとして規定され、使用後のトーンは、新しいローディング後も非ゼロビットを伝送するトーンとして規定され、未使用のトーンは、チャンネルの低ゲインまたはノイズの高差異のいずれかが原因で、ローディング前にゼロビットを伝送していたトーンとして規定される。
【００８８】
以下に上げる実施例において、クラスタ化の方法を示す。ここでは、記号０、Ｘ、Ｕが、ゼロ化トーン、使用後のトーン、未使用のトーンをそれぞれ表すものとする。２０トーンに対し、次のようなトーンの出力ゼロ化プロフィルが与えられると、
【００８９】
【表１】
0004733835.tif 000012
【００９０】
可能なクラスタは、（２，２０）、（２，１８）、（２，９）、（２，６）、（４，２０）、（４，１８）、（４，９）、（４，６）、（８，２０）、（８，１８）、（８，９）、（１２，２０）、（１２，１８）である。
【００９１】
クラスタの識別に続く次の工程は、どのクラスタの非ゼロ化トーンをゼロ化するかを決定する工程である。これは、以下の経験則に従って行うことができる。先ず、少なくとも一定割合のトーンがゼロ化された最大サイズのクラスタを探し、次に、同じ割合のトーンがゼロ化された次に大きいサイズのクラスタを探し、これを、全部のクラスタが探されるまで繰り返す。このクラスタのサイズが使用後のトーン数と同じである場合は、リテインする。それ以外の場合は、クラスタ内の非ゼロ化トーンをゼロ化し、もし可能ならば使用後の他のトーンにビットを移動させ、すでにゼロ化されたクラスタは無視して第１の工程に戻る。上述した実施例において、上述した割合が７５％である場合は、トーン３、７、１９がゼロ化される。
【００９２】
ＥＳコマンドを送信する必要なしにトーンをゼロ化する代替の方法は、トランスミッタおよびレシーバにとってともに既知である所定のシーケンスを使用して、トーンのサブセットをゼロ化するものである。この場合は、このトーンゼロ化の方法の開始を合図するコマンドが必要である。測定される信号がノイズのみであるゼロ化されたトーンでは、ノイズパワーの移動平均推定値を得ることができる。ゼロ化されたトーンに関して、信号の平均が４０シンボルを超える場合、信号は、９９％の信頼性で真のノイズ差異の２．０ｄＢの範囲内にある、または９９．９％の信頼性で真のノイズ差異の３ｄＢの範囲内にあることができる。
【００９３】
ノイズ推定値のセットが得られたら、最大尤度法によって、格納されたノイズプロフィルと突き合わせることができる。クロストークノイズプロフィルの典型例として、ＩＳＤＮ、ＨＤＳＬ、およびＴ１が挙げられる。
【００９４】
最も適当なプロフィルの選択方法として最尤見積もりを使用するに当たり、得られたノイズサンプルに最も一致するノイズ差異のプロフィルを探す必要がある。プロフィルがどれもそれらしい場合は、数１１を求める必要がある。
【００９５】
【数１１】
0004733835.tif 000013
【００９６】
ここで、数１２は、ｋ番目のトーン上におけるノイズ測定を含むＬ次元の複素ベクトルであって、Ωjは、差異を含むｊ番目のクロストークプロフィルである。Ｌは、ｋ番目のトーン上で行われたノイズ測定の番号を示す。この式（数１１）は、数１３のように簡略化される。
【００９７】
【数１２】
0004733835.tif 000014
【数１３】
0004733835.tif 000015
【００９８】
ここで、Ｌは、ノイズ差異を推定するために使用されるシンボルの数であり、σ2j,iはｊ番目のプロフィル内のｉ番目のトーンの差異であり、数１４、数１５であり、Ｎk,iは、ｉ番目のプロフィルの時刻ｋにおけるノイズの測定値であり、Ｄiはｉ番目のトーン上における経験的なノイズ差異である。上記の式（数１３）によって、ノイズの測定値に最も近いノイズプロフィルを識別することが可能になる。
【００９９】
【数１４】
0004733835.tif 000016
【数１５】
0004733835.tif 000017
【０１００】
以下に挙げる３つの実施例では、高速スワッピングおよびビットスワッピングの実現速度を比較する。
【０１０１】
実施例１：１つのビットをスワップする
従来のビットスワッピングで１ビットを移動させる場合は、６０バイトのＡＯＣ帯域幅が必要である。これは、論理的には、双方向のＡＯＣチャンネルを約３０ｍｓ（６０バイト／（２０００バイト／秒））で横断することができる。しかしながら、Ｇ．ライトおよびＧ．ｄｍｔの標準では、（実装の遅延が原因で）８００ｍｓ以内で１ビット以上のスワップ変換を行うことはできない。８００ｍｓは、高速スワッピングには適用されない。逆方向の相互運用性のため、従来のビットスワッピングからこの８００ｍｓの問題を排除することは難しい（しかしながら、高速スワッピングを使用するモデムでは、このような問題は存在しない）。反対に、高速スワッピングは、一方向性のＡＯＣチャンネルのみを使用する８バイトのコマンドを必要とするので、約２１ｍｓ（８バイト／（２０００バイト／秒））＋１７ｍｓ（最悪の場合のタイムアウト）の時間がかかる。
【０１０２】
【表２】
0004733835.tif 000018
【０１０３】
実施例２：１０トーン上で４０ビットを移動させる
このタイプのスワップとしては、例えばＡＭラジオレシーバのパワーが夜間にレベルアップする場合のような、回線上における緩やかなノイズ変化が代表的である。従来のビットスワッピングでは、論理的に、最低でも６０バイト×（４０ビット）＝２４００バイトが必要であり、１．２秒の時間がかかる。実際にかかる時間は、（１ビットのスワップごとに最低８００ｍｓが必要だと考えて）４０（．８ｓ）＝３２秒である。これに対して高速スワッピングでは、２バイト×（１０トーン）＋４バイト＝２４バイトが必要で、２９ｍｓの時間がかかる（最悪の場合のタイムアウトである１７ｍｓを含む）。したがって、ビット数が多いほどスピードアップも大きくなる。
【０１０４】
【表３】
0004733835.tif 000019
【０１０５】
実施例３：１００トーン上における４００ビットのプロフィル変更
このタイプのスワップとしては、例えばオフフックのインピーダンス変更等の、回線上における激しいチャンネル変更が代表的である。ビットのスワッピングプロトコルでは、論理的に１２秒そして実際には３２０秒が必要である。この場合は、ビットのスワッピングによって問題を修正している間にエラーを生じる可能性があるので、リテインは明らかに高速であり、使用する必要があると考えられる。高速スワッピングが２０４バイトのＡＯＣコマンドで４００ビット全部を移動させるのに、１１９ｍｓの時間が必要である。ビットスワッピングの高速化は著しく、サービスの介入がないので、リテインより大幅に高速である（ただし、チャンネルの特性が著しく変化した場合は、高速スワッピングインターバルにおいて幾らかのビットエラーを生じる可能性がある）。
【０１０６】
【表４】
0004733835.tif 000020
【０１０７】
さらに詳述すると、ＥＳの実現には（２ｎ＋４）／ＲAOC＋Ｔtime-out秒が必要であり、ここで、ｎ＝該当トーンの数、ＲAOC＝バイト／秒で表されたＡＯＣのチャンネル速度、Ｔtime-out＝タイムアウトの時間である。タイムアウトの時間は、最悪の場合で１７ｍｓであり、もっとずっと速くても良い。タイムアウトの時間とは、ＡＯＣバイトが最後に送信された後、レシーバによって、受信されたチャンネル出力のビットテーブル内において何の変更も見出されなかった場合に、レシーバが、トランスミッタは何らかの理由でＥＳを実現できなかったまたは実現できないと想定するのに必要な時間である。簡略化のため、タイムアウトは、次のスーパーフレーム境界となるように選択される（ただし論理上はもっと小さい）。従来のスワッピングでは、移動されたビット数をｂとした場合に、必要な時間は僅か０．８ｂ秒であった。図７は、ｋ＝１，２，５，１０の各場合に関し、ｂ＝ｋｎの改善度を該当トーン数に対してプロットしたグラフである。（この特定のプロットは、実際には２ｍｓのタイムアウトを使用しており、これはやはり対象範囲内である）図示されるように、ＥＳプロトコルの改善度はいずれの場合も非常に大きい。したがって、このプロトコル自体が、高速スワッピングを行うに足る能力を有する。
【０１０８】
以上からわかるように、本発明は従来技術と比べて多くの利点を有する。例えば、高速スワッピングによってビットスワッピングが高速化される。高速スワッピングの速度がビットスワッピングの１０，０００倍の速度に達する場合もある。さらに、高速スワッピングの実行時間はほとんど瞬間的であり、特に大きいクロストーカが突然導入された場合などに、多数の著しい変更間で接続性を維持するのに充分である。また、高速スワッピングコマンドの使用では、初期化中に追加の情報を引き渡す必要はない。すなわち、確認通知パケットはなく、変更要求コマンドは１度だけ送信されれば良い。さらにまた、高速スワッピングは、より高速な変更が要求される状況における接続の信頼度を高めることによって、再トレーニングの必要性および頻度を低減することができる。
【０１０９】
ビットスワッピングに関連した詳細は、次に挙げる参考文献にも記述されている。すなわち、Salvekar et al.「CHANNEL GAIN CHANGE DETECTION AND CHANNEL PROFILE SELECTION IN A MULTCARRIER SYSTEM（マルチキャリアシステムにおけるチャンネルゲインの変更の検出およびチャンネルプロフィルの選択）」Globecom，１９９９年１２月、John M.Cioffi「VDSL ALLIANCE:VDSL TRANSMISSION SPECIFICATION（ＶＤＳＬ伝送仕様）（００−１１６）」T1E1.4:VDSL，２０００年２月、およびCioffi et al.「G.LITE.BIS:ANALYSIS OF EXPRESS SWAPPING SPEEDS AND RELIABILITY（高速スワッピングの速度および信頼性の分析）」１９９９年４月であり、これらの文献を、本明細書に引用として組み込むものとする。
【０１１０】
次に、スワップの速度を増加させる代替の方法を説明する。この新しい方法は、ともにチャンネルをモニタリングして様々なチャンネル変更のプロフィルを格納するレシーバおよびトランスミッタを含む。処理中に変更が検出されたら、レシーバおよびトランスミッタは、格納された同じプロフィル（１６プロフィルのうちの１つ）に切り換えて動作を継続する。したがって、高速スワップコマンドや他のコマンドがレシーバから送信されることはなく、このためより高速なスワップが行われる。さらに具体的に言うと、レシーバおよびトランスミッタは、チャンネルの性能をモニタリングして信号の適応化を制御するための回線モニタを備えるように構成される。例えば、レシーバおよびトランスミッタが、上述したように回線モニタを備えても良い。レシーバおよびトランスミッタは、また、特定の回線変更に対応する複数の所定プロフィルを格納するようにも構成されている。したがって、モニタによってチャンネル内の変更が検出された場合、レシーバおよびトランスミッタは、関連のデバイスに対し、所望の変更に最も良く一致する所定のプロフィルを選択するように指示する。この方法では、レシーバおよびトランスミッタの両方が、所定のプロフィルで動作することができる。例えば、所定のプロフィルに、マルチトーン信号の各トーンに対するビットおよびゲインの分布が含まれていても良い。
【０１１１】
以上では、幾つかの実施形態を詳細に説明したが、本発明の趣旨および範囲から逸脱しない範囲内で、他の多くの特定の形態で本発明を実現できることを、理解する必要がある。本発明は、特に、離散マルチトーンシステムのための高速スワッピングに関して説明されている。しかしながら、本発明が、他の様々なシステムにおいても使用可能であることを、理解する必要がある。例えば、サブチャンネル（サブキャリアビットおよびゲイン）の動的な適応化を必要とするマルチチャンネルまたはマルチキャリアシステムが挙げられる。さらに、レシーバのモニタリングは様々な方法で実現可能であり、本発明の範囲を逸脱しない範囲内で大幅な変更が可能であると考えられる。したがって、上述した実施例は例示的であって限定的ではないと考えられ、本発明は、ここで挙げた詳細に限定されず、添付した特許請求の範囲内で変更することが可能である。
【図面の簡単な説明】
【図１】  Ｔ１．４１３ビットスワッピング要求のフォーマットを示す図である。
【図２】  典型的なビットおよびゲインテーブルを示す図である。
【図３】  本発明の一実施形態に従って、高速スワッピング要求のフォーマットを示す図である。
【図４】  本発明の一実施形態に従って、モデムのアーキテクチャを示す図である。
【図５】  本発明の一実施形態に従って、レシーバを示す図である。
【図６ａ】  ４ビットアロケーションのトーンに対する典型的な出力コンステレーションを示す図である。
【図６ｂ】  ６ビットアロケーションのトーンに対する典型的な出力コンステレーションを示す図である。
【図７】  高速スワッピングの改善因子対影響されたトーンの数をプロットしたグラフである。
【符号の説明】
１２…メッセージヘッダ
１４…メッセージ
１６…メッセージフィールド
１８…コマンド
２０…トーンインデックス
５０…ビットおよびゲインテーブル
５２…トーンナンバフィールド
５４…ビットアロケーションフィールド
５６…ゲインまたはパワーレベルフィールド
１００…高速スワッピングコマンド
１０２…メッセージヘッダフィールド
１０４…高速スワッピング制御フィールド
１０６…トーンメッセージ
１０８…エラーフィールド
１１０…トーンインデックス
１１２…所望値インジケータ
２００…モデム
２０２…トランスミッタ
２０４…レシーバ
２０６…エンコーダ
２０８…変調器
２１０…ウィンドウ操作フィルタ
２１１…コントローラ
２１２…アナログインタフェース
２１４…アナログインタフェース
２１６…タイムドメインイコライザ
２１８…復調器
２２０…デコーダ
２２１…コントローラ
２２２…リモートデバイス
２２３…伝送メディア
２２４…ビットおよびゲインテーブル
２２６…ＡＤＳＬオーバヘッドチャンネル
２２７…古いビット／ゲインテーブル
２２８…新しいビット／ゲインテーブル
３００…DMTレシーバ
３０２…第１のデコーダ
３０４…第２のデコーダ
３０５…シンドロームジェネレータ
３０６…シンドロームジェネレータ
３０８…スイッチ
４００…４ビットの布置
５００…６ビットの布置
【図１】
0004733835.tif 000021
【図２】
0004733835.tif 000022
【図３】
0004733835.tif 000023
【図４】
0004733835.tif 000024
【図５】
0004733835.tif 000025
【図６ａ】
0004733835.tif 000026
【図６ｂ】
0004733835.tif 000027
【図７】
0004733835.tif 000028