JP2002538670A

JP2002538670A - マルチキャリア伝送システムにおける高速ビットスワッピング

Info

Publication number: JP2002538670A
Application number: JP2000601800A
Authority: JP
Inventors: チュインホー・ルイーズ・ミン; サルベカー・アチュル; アルダナ・カルロス; シオフィ・ジョン・エム．; チャウ・ピーター・エス．; カルロ・ジム
Original assignee: Leland Stanford Junior University
Current assignee: Leland Stanford Junior University
Priority date: 1999-02-24
Filing date: 2000-02-24
Publication date: 2002-11-12
Anticipated expiration: 2020-02-24
Also published as: WO2000051304A1; EP1157513A1; KR20010108265A; AU3504600A; JP4733835B2

Abstract

(57)【要約】【解決手段】マルチキャリア通信信号においてパラメータ（サブキャリアビットの割り当ておよび／またはゲイン）を適応的に変更するための方法およびデバイスを開示する。本発明の１つの態様では、変更の必要性を決定するユニットが、第２のユニットに高速変更要求を送信する。変更要求は、変更される１つまたはそれ以上の特定のサブキャリアを識別し、識別された各サブキャリアに関して変更されるパラメータの所望値を識別する。次に、要求ユニットは、受信した通信信号をモニタすることによって、要求された変更が実現されたか否かを決定する。要求された変更が実現されたか否かの決定は、変更を意図された受信された通信信号の一部分を分析することに、少なくとも部分的に基づく。本発明の他の態様において、変更要求コマンドは、ヘッダと、制御フィールドと、少なくとも１つのサブキャリア識別子と、少なくとも１つの所望のパラメータ値インジケータと、エラーフィールドとを含む。ヘッダは、コマンドを変更要求コマンドとして識別する。制御フィールドは、変更されるトーン数を示すトーンカウントを含む。各サブキャリア識別子は、変更される特定のサブキャリアを識別し、各所望パラメータ値インジケータは、関連のサブキャリアの所望のパラメータ値を識別する。エラーフィールドによって、変更要求を受信するユニットは、変更要求コマンドの分析にエラーが存在するか否かを検出することが可能になる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は一般に、マルチキャリア変調を用いた高速データ伝送システムに関す
る。より詳細には、マルチキャリア伝送システムでの利用に適した高速パラメー
タ変更コマンドおよびプロトコルが開示されている。

【０００２】

【従来の技術】

近年、高速モデムでのマルチキャリア変調の利用が注目を集めてきた。例えば
、ＡＮＳＩ（米国規格協会）の規格グループの認定を受けたグループである通信
情報ソリューション連合（ＡＴＩＳ）は、非対称型デジタル加入者網（ＡＤＳＬ
）でのデジタルデータ伝送のための離散マルチトーンに基づいた基準を発表した
。その基準は主に、通常の電話回線でのデータ伝送を意図したものであるが、様
々な他の用途でも同様に用いることができる。北米の基準はＡＮＳＩＴ１．４
１３ＡＤＳＬ基準と呼ばれており、参照により本明細書に含まれる。ＡＤＳＬ
基準のもとでの伝送速度は、ツイストペア電話回線で少なくとも毎秒６百万ビッ
ト（すなわち６Ｍｂｉｔ／ｓ）までの速度で情報を伝送するのを容易にすること
を意図している。基準化されたシステムは、順（下流）方向で、それぞれが４．
３１２５ｋＨｚの幅を持つ２５６の「トーン」すなわち「サブチャンネル」を用
いる離散マルチトーン（ＤＭＴ）システムの使用を定義している。電話システム
においては、下流方向は、電話局（通例は電話会社が所有）からエンドユーザ（
すなわち自宅もしくはビジネス利用者）である遠隔地への伝送として定義されて
いる。

【０００３】ＡＤＳＬ基準は広く受け入れられているが、Ｔ１．４１３ＡＤＳＬ基準の改
善と、他のデータ速度での通信のためのＡＤＳＬもしくはその他の基準の提供に
努力がなされている。例えば、現在、特に１２８のトーンのみを用いる簡易版の
基準を定義する努力がなされている。この努力は、Ｔ１．４１３によってなされ
ており、一般に、Ｇ．ライト基準化の取り組みと呼ばれている。また、かなり高
速なデータのための基準を定義する努力もある。その取り組みは、ＶＤＳＬ（超
高速デジタル加入者網）基準と呼ばれている。ＶＤＳＬ基準は、下流方向で少な
くとも２５．９６Ｍｂｉｔ／ｓ、好ましくは少なくとも５１．９２Ｍｂｉｔ／ｓ
の伝送速度を容易にすることを意図している。これらの速度を実現するためには
、ツイストペア電話回線での伝送距離を一般に、ＡＤＳＬで許容される長さより
も短くする必要がある。同時に、デジタルオーディオビデオ協会（ＤＡＶＩＣ）
が、同様のシステムに関する活動を行っている。そのシステムは、ファイバトゥ
ーザカーブ（ＦＴＴＣ）と呼ばれる。「カーブ」から顧客の建物までの伝送メデ
ィアは、標準的な非遮蔽ツイストペア（ＵＴＰ）電話回線である。

【０００４】マルチキャリア変調を用いる高速ＤＳＬモデムに固有の１つの問題は、回線の
状態の変動をどう処理するかというものである。例えば、Ｔ１．４１３基準とそ
の他の提案されたＤＭＴベースのシステムでは、通信モデムは、データ通信が始
まる前に短いトレーニング期間を経る。トレーニング期間中に、試験信号が伝送
され、様々な周波数で回線の品質が効果的に試験される。一般に、回線の品質は
、それぞれのトーンでの信号／ノイズ比（ＳＮＲ）によって決定される。次に、
それぞれのトーンに割り当てられる「ビット」の数が、主に検出されたトレーニ
ング信号に基づき決定される。しかしながら、トレーニング期間の後、伝送回線
には、いくつかのトーンで割り当てられた速度で情報を伝送する能力に影響しう
る変化が生じることがある。伝送回線の変化は、以下の様々な原因から生じる。
顧客による受話器の上げ下ろし、温度により生じる回線の変化、近接した回線が
活動もしくは非活動となることによる混線ノイズの変化、夜間のＡＭラジオ信号
の増加。

【０００５】時が過ぎて回線の品質が低下すると、エラーが起こる可能性が高くなり、割り
当てられたビットアロケーションを調整するために何らかの作業を行う必要があ
る。ビットアロケーションを調整する１つの方法は、単にモデムを再トレーニン
グするという方法である。しかしながら、再トレーニングは、比較的多くの時間
が掛かるという欠点があり、短時間の停電が生じる。Ｔ１．４１３基準で定義さ
れたビットアロケーションを調整する他の方法は、「ビットスワッピング」と呼
ばれる手順である。ビットスワッピングプロトコルは、或るトーンでエラーが検
出された際に、そのトーンで伝送される情報の量をある程度のビット数を削減す
ることを意図するものである。他のトーンが余分のＳＮＲを持っていると思われ
る場合には、相当する量だけ、情報伝送量が増加される。

【０００６】Ｔ１．４１３基準では、ビットスワッピングプロトコルが明確に定義されてい
る。より詳細には、あるレシーバが、ビットスワッピングが必要であると決定し
た場合に、そのレシーバは、オーバヘッドチャンネル（通例、ＡＯＣ−ＡＤＳＬ
オーバヘッドチャンネルと呼ばれる）を通じてビットスワッピングの要求を送る
。ビットスワッピング要求は、図１に示されている指定フォーマットを持ってい
る。示されているように、ビットスワッピング要求の第１のバイトはメッセージ
ヘッダ１２である。メッセージヘッダ１２は、コマンドをビットスワッピングと
して識別するヘッダすべてからなる。メッセージヘッダ１２の後には、８（また
は１２）バイトのメッセージ１４が続く。メッセージ１４は、４（または６）の
セグメントに分割され、それぞれのセグメントは、メッセージフィールド１６と
呼ばれる。それぞれのメッセージフィールド１６は、１バイトのトーンインデッ
クス２０が続く１バイトのコマンド１８を含む。トーンコマンドは、コマンドが
適用されるトーンを識別する。１バイトのコマンドは、以下の機能を含む。ビッ
トの付加、ビットの消去、１，２，３ｄＢのパワー増加、１，２，３ｄＢのパワ
ー減少、何も行わない、および独自のコマンド。

【０００７】Ｔ１．４１３は、さらに、３バイトのビットスワッピング応答コマンドがビッ
トスワッピングを要求したユニットに送り返され、ビットスワッピング要求の受
信が確認されることを必要とする。ビットスワッピング応答コマンドは、スワッ
ピングが実行される特定のシンボルカウントを指定する。応答コマンドは、単に
新しいビット分布の実装を検出するために用いられるが、応答は、スワッピング
の速度を遅くし、なお、応答が受信されない場合に障害を引き起こす可能性があ
る。

【０００８】Ｔ１．４１３プロトコルは、さらに、ビットスワッピング要求コマンドが５回
連続で伝送されることと、受信ユニットがそれら５回の伝送のほとんどを受信し
た場合に、受信ユニットのみがビットスワッピングコマンドに応答することを命
令する。それゆえ、要求に応答するために１バイトと１５バイトの移動を要求す
るには、４５バイト必要となる（また、５回繰り返す必要がある）。待ち時間を
無視すると、スワッピングに掛かる最短の時間は、３０ｍｓのオーダである（１
６キロバイト／秒で６０バイト）。しかしながら、現在の基準は実際に、８００
ｍｓに１回以上の頻度でスワッピングが起こらないことを要求している。それに
よって、トランシーバの簡略化が可能となるが、さらに、４つ以上のトーンが変
更される場合には、スワッピングプロセスが遅くなる。それゆえ、標準的なＡＤ
ＳＬビットスワッピングは、トランスミッタの遅い変動を許容する。しかしなが
ら、スプリッタレスＡＤＳＬの出現と一般でのＤＳＬの普及に伴って、ＤＳＬ回
線は、ビット分布の大幅な変更を必要とする突然の変更の影響を受けることが明
らかとなった。基準化されたビットスワッピングプロトコルの遅さと再トレーニ
ングが必要となるという欠点を考慮して、マルチキャリア伝送システム内でビッ
トの再分布を実行する時間を減らすためには、さらに効率的なメカニズムが必要
であることが明らかとなった。

【０００９】

【発明の概要】

本発明の以下の目的およびその他の目的を達成するために、マルチキャリアベ
ースの伝送システムにおいて通信信号のパラメータ（サブキャリアゲインまたは
ビットアロケーションなど）を適応的に変更するための方法およびデバイスが開
示されている。本発明の１つの態様では、変更の必要性を決定するユニットが、
第２のユニットへ変更要求を送る。変更要求は、変更される１つ以上の特定のサ
ブキャリアと、それぞれ識別されたサブキャリアに関するパラメータに対する所
望の値を識別する。次に、要求ユニットは、要求した変更が実現されたか否かを
決定するために受信する通信信号をモニタリングする。要求した変更が実現され
たか否かの決定は、少なくとも一部は、変更されることになっていた受信された
通信信号の一部の解析に基づく。

【００１０】好ましい実施形態では、変更要求は、それぞれ識別されたサブキャリアに関す
るパラメータに対する所望の値だけでなく、変更される複数の特定のサブキャリ
アを識別するのに適している。例えば、パラメータは、関連するサブキャリアに
対する所望のビットアロケーションもしくは所望のパワーレベル（ゲイン）でも
よい。所望の値は、絶対値（例えば、このトーン上で８ビットを伝送）でも相対
値（例えば、このトーン上で伝送されるビットの数を２だけ増加）でもよい。他
の好ましい実施形態では、プロトコルは、変更要求が受信もしくは実現されたと
いう明確な応答を含まない。

【００１１】モニタリングは、様々な方法で行ってよい。例えば、いくつかの実施形態では
、要求ユニットは、パラメータのカレント値とパラメータの所望の値の両方を用
いて、受信された通信信号を重複してデコードする。この実施形態では、要求さ
れた変更が実現されたか否かの決定は、少なくとも一部はデコーディングに基づ
いて行われる。例えば、要求した変更が実現されたか否かの決定は、少なくとも
一部は、それぞれのデコーディングを用いて検出されたエラーの解析と、エラー
の少ないデコーディングの選択に基づいてもよい。もう１つのアプローチは、カ
レント値のデコードに基づく第１の前進型誤り訂正シンドロームと所望の値のデ
コードに基づく第２の前進型誤り訂正シンドロームを生成することである。この
アプローチでは、変更要求が実現されたか否かの決定は、そのシンドロームの解
析に基づいている。

【００１２】いくつかの実施形態では、モニタリング工程は、変更要求によって変更される
ことになっている１つ以上の特定のサブキャリアをモニタリングする工程を含む
。特定のサブキャリア上で変更が検出された場合、変更が実現されたと決定され
る。ここでも、モニタリングは、様々なメカニズムを使って行ってよい。例えば
、マルチキャリア信号がＤＭＴ信号である場合、１つ以上のトーンのエネルギレ
ベルをモニタリングすることができる。例えば、そのトーンに対して許容可能な
パワーを増加する変更を行ってもよい。このシナリオでは、カレントのパラメー
タ値を用いて期待されたよりも大きいエネルギがそのトーンで検出された場合に
、要求された変更が実現されたことを決定することができる。あるいは、トーン
の１つをゼロにするか、ゼロにされたトーンをアクティブにすることもできる。
これらの種類のアプローチは、比較的実施しやすく、変更を要求するユニットか
ら明確なフィードバックを要求することなしに、変更の実現を検出するのを容易
にする。

【００１３】本発明の他の態様では、変更要求コマンドは、ヘッダ、高速スワッピング制御
、少なくとも１つのサブキャリア識別子、少なくとも１つの所望のパラメータ値
インジケータ、エラーフィールドを含む。ヘッダは、コマンドを変更要求コマン
ドとして識別する。高速スワッピング制御は、変更されたトーンカウントを指定
する。トーンカウントは、変更要求コマンドによって変更されるトーンの数を示
すものである。それぞれのサブキャリア識別子は、変更要求コマンドによって変
更される特定のサブキャリアを識別する。それぞれの所望パラメータ値インジケ
ータは、関連するサブキャリアのパラメータの所望の値を識別する。エラーフィ
ールドは、変更要求を受信するユニットが変更要求コマンドの解釈にエラーがあ
るか否かを検出することを可能にする。いくつかの実施形態では、スーパーフレ
ームナンバは、ヘッダに含まれていてもよい。他の実施形態では、スーパーフレ
ームナンバは、高速スワッピング制御に含まれていてもよい。さらに、スーパー
フレームナンバは、後に続くスーパーフレームがいくつあるか、もしくは、どの
スーパーフレームで高速スワッピングが起こるかを特定する。

【００１４】好ましい実施形態では、所望パラメータ値インジケータは、関連するサブキャ
リアに対する所望のビットアロケーションと所望のゲインの少なくとも一方を識
別する。いくつかの実施形態では、特定のサブキャリアに対する所望のビットア
ロケーションと所望のゲイン両方を識別するために、１バイトを用いることがで
きる。

【００１５】本発明の他の態様では、レシーバ内に重複デコーダを含む改良モデム設計が開
示されている。重複デコーダは、変更要求コマンドによって変更されることにな
っている少なくとも１つのサブキャリアに対する様々なパラメータを用いて、復
調されたマルチキャリア信号をデコードするよう構成されている。次に、どの重
複デコーダが訂正信号をデコードしたかを決定するために、アナライザが提供さ
れている。

【００１６】一実施形態では、重複デコーダは、同一のサブキャリアをデコードするよう構
成されたサブキャリアデコーダである。他の実施形態では、重複デコーダは、マ
ルチキャリア信号の複数のサブキャリアをデコードするよう構成された信号デコ
ーダである。或る特定の実装では、アナライザは、重複デコーダによってデコー
ドされた信号のシンドロームを生成するよう構成された重複シンドロームジェネ
レータを含む。

【００１７】

【発明の実施の形態】

いくつかの好ましい実施形態を参照し、関連する図を用いて、マルチキャリア
伝送システムでの高速ビットスワッピングの実装に適した方法、デバイス、プロ
トコルを詳細に説明する。以下の説明では、本発明を完全に理解するために、数
々の具体的な詳細が示されている。しかしながら、本発明がこれらの具体的な詳
説のいくつかまたは全てをなしに実現できることは、当業者にとって明らかであ
る。本発明を不必要に不明瞭にしないように、よく知られたプロセスのステップ
は説明されていない。

【００１８】マルチキャリアベースの通信システムにおいては、チャンネルを適応的に変更
する工程を容易にすることが一般的に望まれている。或る現行の実装（Ｔ１．４
１３ＡＤＳＬ基準など）では、チャンネルを適応的に変更する工程を容易にする
ために、ビットスワッピングのコンセプトが用いられている。しかしながら、標
準的なビットスワッピングの構成は、比較的遅く、そのために、特にチャンネル
の多くの変更を扱う際には有効ではない。したがって、本発明は、チャンネルに
対して適応的な変更を実現するための改良メカニズムを提供することを意図する
。

【００１９】一般に、本発明では、変更が妥当であるとトランシーバが決定した際に、トラ
ンシーバは、相手側に高速の変更要求を送信することが熟考されている。次に、
要求しているトランシーバは、要求された変更が実現されたか否かを決定する信
号をモニタリングし、それに従って受信された信号をデコードする。実例を挙げ
るために、本発明は、離散マルチトーン変調を用いるＤＳＬベースのポイントツ
ーポイント双方向通信システムを用いて説明されている。しかしながら、記述さ
れている技術はポイントツーポイントシステムだけでなく任意のマルチキャリア
伝送システムに容易に応用可能であることは明らかである。

【００２０】従来のビットスワッピング（ＳＢ）と開示されている拘束スワッピング（ＥＳ
）の両方において、レシーバは、入力信号で発生しているエラーの量に基づき、
変更の必要性を決定する。変更が必要であると決定されると、レシーバは、問題
のあるトーンに対して最良の可能なビットアロケーションを決定する。例えば、
レシーバが、或る特定のトーンでノイズ（エラーを起こすのに十分なノイズ）の
増加を計測した場合、レシーバは、ビットの一部をそのトーンからノイズの少な
い他のトーンへ再割り当てする。レシーバは、テーブル（通例、ビットおよびゲ
インアロケーションテーブルと呼ばれる）に所望のビットアロケーションを格納
する。ほとんどの場合、ビットおよびゲインアロケーションテーブルは、マルチ
キャリア信号で用いられるトーンすべてに対するエントリを持っており、それぞ
れのトーンエントリは、対応するトーンに関するビットアロケーションとゲイン
またはパワーレベルを含んでいる。変更が望まれると、レシーバは、トランスミ
ッタに要求を送り、新しいアロケーションに対応する信号での変更を要求する。

【００２１】議論を簡単にするために、図２は、典型的なビットおよびゲインテーブル５０
を大まかに示している。ビットおよびゲインテーブル５０は一般に、トーンナン
バフィールド５２、ビットアロケーションフィールド５４、ゲインまたはパワー
レベルフィールド５６を含む。トーンナンバフィールド５２は、Ｇ．ライト基準
に準拠した動作に対しては１２８のトーンのためのエントリを、Ｇ．ｄｍｔ基準
に準拠した動作に対しては２５６のトーンのためのエントリを含んでいる。他の
システム（ＶＤＳＬ計画など）では、かなり多くのトーンが提案されているので
、エントリの数が、広く変化する可能性がある。さらに、それぞれのトーンエン
トリ（１２８または２５６トーンの一方）は一般に、関連したトーンで伝送され
るビットの数を決定するビットアロケーションを含む。それぞれのトーンのため
のビットアロケーションは通例、ビットアロケーションフィールド５４に含まれ
ている。或る特定のトーンに割り当てられたビットの数は、回線の状態、所望の
伝送速度、用いられるプロトコルなどに基づいて広く変化する。例えば、それぞ
れのトーンに割り当てられたビットの数は、Ｇ．ライト伝送方式では０〜１１の
範囲で、Ｇ．ｄｍｔ伝送方式では０〜１５の範囲で変化する。また、これらの数
は、他のシステムにおいては広く変化することもある。さらに、それぞれのトー
ンエントリは一般に、関連したトーンで伝送エネルギレベルを決定するゲインア
ロケーションを含む。それぞれのトーンのためのゲインアロケーションは通例、
ゲインアロケーションフィールド５６に含まれている。

【００２２】次に、図３を参照して、本発明の一実施形態に従い、高速スワッピングコマン
ドのフォーマットを説明する。上述したように、変更が必要であるとレシーバが
決定した場合、レシーバは、高速スワッピングコマンドをトランスミッタに送る
。高速スワッピングコマンド１００は、メッセージヘッダフィールド１０２、高
速スワッピング制御フィールド１０４、１つ以上の一連のトーンメッセージ１０
６、エラーフィールド１０８を含む。ヘッダフィールド１０２は、コマンドを変
更要求コマンドとして識別するヘッダ値を含む。高速スワッピング制御１０４は
一般に、後に続くスーパーフレームの数、もしくは、高速スワッピングの行われ
るスーパーフレームを示すスーパーフレームナンバと、変更要求コマンドによっ
て変更されるトーンの数を示すトーンカウントを含む。それぞれのトーンメッセ
ージ１０６は、変更要求コマンドによって変更されるサブキャリアを識別するト
ーンインデックスと、識別されたトーンに対して所望のビット割り当てとゲイン
パラメータを示す所望値インジケータを含む。エラーフィールド１０８により、
変更要求を受信するユニットが、変更要求コマンドの解釈にエラーがあるか否か
を検出することが可能となる。

【００２３】より詳細には、メッセージヘッダ１０２は、コマンドが変更要求コマンドであ
ることと、適切なサイズであることを識別する。例えば、説明されている実施形
態において、メッセージヘッダは、１バイトを占め、高速スワッピングコマンド
として事前に定義されるビットパターン（例えば１１１１００１１）を含んでい
る。Ｇ．ｄｍｔもしくはＧ．ライトの実装において、スワッピングコマンドは、
補助オーバヘッドチャンネル（ＡＯＣ）で伝送され、定義されたパターンで始ま
るＡＯＣで伝送されたメッセージはすべて、直ちに高速スワッピングコマンドと
して認識される。さらに、ヘッダがコマンドの前に示されているが、ヘッダの位
置に制限はなく、コマンドのどこに位置してもよいことに注意すべきである。

【００２４】メッセージヘッダ１０２の後には、高速スワッピング制御１０４が続く。それ
は、高速スワッピングの行われるスーパーフレームと、変更要求コマンドによっ
て変更されるトーンの数を示す。例えば、トーン（＃２、＃８０、＃９５）が変
更要求で変更されることになっている場合、トーンカウントは３である。説明さ
れている実施形態では、高速スワッピング制御１０４も、１バイトを占める。例
えば、高速スワッピング制御１０４は、トランスミッタが次のスーパーフレーム
で高速スワッピングを実施する場合には、最も重要なビットを０に設定し、トラ
ンスミッタが次の次のスーパーフレームで高速スワッピングを実施する場合には
、１に設定する。さらに、残りのビットには、トーンの数ｎが並び、それらは、
コマンドで次の２ｎバイトによって変更される。Ｇ．ライト基準では、１２８の
トーンが用いられるため、１バイト（残りの７ビット）は、１つのコマンドで変
更されるトーンの任意の数もしくはすべてであっても許容できるほどに十分であ
る。しかしながら、Ｇ．ｄｍｔ基準では、２５６のトーンが用いられるため、高
速スワッピング制御のサイズを（例えば、８ビットに）増やすことが望まれる。
さらに、他のシステムでは、２５６よりもかなり多いトーンを用いることが考え
られている。例えば、提案されているＶＤＳＬシステムでは、４０９６のトーン
を用いることが計画されている。そのようなシステムでも、高速スワッピング制
御のサイズを（例えば、１２ビットに）増やすことが望まれる。

【００２５】スーパーフレームナンバは、高速スワッピング制御の一部として記述されてい
るが、これは制限ではなく、様々な方法で変更のタイミングを示すことができる
ことに注意すべきである。例えば、スーパーフレームナンバまたはスーパーフレ
ーム指定は、メッセージヘッダの一部でよく、また、タイミングは、レシーバと
トランスミッタの間の固定されたアグリーメントの一部でもよい。例えば、スー
パーフレームナンバの指定は、様々なメッセージヘッダを用いて行うことができ
る。さらに、スーパーフレームナンバは必ずしも必要でないことに注意すべきで
ある。必要のない場合には、スーパーフレームナンバをコマンドから省くことが
できる。

【００２６】高速スワッピング制御１０４の後には、一連のトーンメッセージ１０６が続き
、それぞれが、トーンインデックス１１０と所望値インジケータ１１２を含む。
それぞれのトーンインデックスは、変更要求コマンドによって変更される特定の
サブキャリアを識別する。それぞれの所望値インジケータは、関連するトーンイ
ンデックスによって識別されたトーンに対して変更されるトーンパラメータのた
めの所望の値を示す。開示されている実施形態では、トーンビットの割り当てと
トーンパワー（ゲイン）が、変更される２つのパラメータである。それゆえ、所
望値インジケータ１１２は、関連するトーンインデックスによって識別されたト
ーンのためのトーンビットの割り当てとゲインを識別する。所望の値は、絶対値
（例えば、このトーンで８ビットを伝送し、ゲインを＋１．５に設定する）の形
でも、相対値（例えば、このトーンで伝送するビットの数を２だけ増加し、ゲイ
ンをあるレベル増大させる）の形でもよい。

【００２７】説明されている実施形態では、トーンインデックス１１０と所望値インジケー
タ１１２はそれぞれが、１バイトを占め、ここでも、システムの必要に応じてそ
れらのサイズを変更することができる。トーンインデックスのサイズは主に、利
用可能なトーンの数による。２５６よりも多くのトーンが利用可能である場合に
は、トーンカウントは１バイトよりも大きい必要がある。しかしながら、Ｇ．ｄ
ｍｔ基準（２５６トーンを想定）とＧ．ライト基準（１２８トーンを想定）では
、１バイトで十分である。例えば、提案されているＶＤＳＬシステムでは、４０
９６のトーンが想定されているため、そのような実装に対しては、トーンインデ
ックスのサイズを１２ビットに増やすことが望まれる。

【００２８】所望値インジケータ１１２は、関連するトーンインデックス１１０によって識
別されたトーンのための所望のトーンビットの割り当てと所望のゲインを示す所
望値インジケータ１１２の上位のニブル（すなわち最初の４ビット）は、関連す
るトーンに割り当てられる新しいビット数を示す。いずれのトーンの最大ビット
数も、Ｇ．ライトでは１１（Ｇ．ｄｍｔでは１５）である。それゆえ、上位のニ
ブルは、０ビットに対しては００００、２ビットに対しては００１０、．．．、
１５ビットに対しては１１１１という具合にエンコードしてもよい。所望値イン
ジケータ１１２の下位のニブル（すなわち後の４ビット）は、所望のゲインレベ
ルを示す。割り当てられている４ビットにより、１６の異なるゲインレベルを指
定することができる。ここでも、所望のゲインの値は、絶対値のレベルの形でも
、相対値の変更量（例えば、１、２もしくは３ｄＢだけパワー増加、１もしくは
２ｄＢだけパワー減少、変更せず）の形でもよい。例えば、離散マルチトーンの
例では、いくつかの名義ゲインレベルに対して−４から＋３．５（０．５ｄＢご
と）までの１６の異なるゲインレベルを、或る特定のゲインレベルに関するそれ
ぞれの潜在的な値と共に指定することができる。均一なゲインレベルが説明され
ているが、所望のゲインの変更に利用できるゲインレベルの分布の方法には様々
なものがあることを理解すべきである。さらに、増加量の相対サイズだけでなく
、ゲインレベルの数も、ある特定のシステムの必要に応じて広く変化させること
ができる。

【００２９】また、増加量は一様である必要はない。１５ビット以上をいずれかのトーンで
伝送することができる場合、もしくは、１６以上のパワーレベルが望まれる場合
には、所望値インジケータ１１２に１バイトを提供することが好ましい。例えば
、サイズを２バイトに増やすと、実質的に解像度が増すことになる。もちろん、
異なる、付加的もしくはより少数のパラメータが、或る特定のサブキャリアもし
くはトーンに対して制御される場合には、それに従って、適切な情報を運ぶよう
に所望値インジケータを適応させることができる。

【００３０】一般に、２つのモデムが同期しない場合、次のスワッピングコマンドが所望の
値を明確に示すので、所望の値として絶対値を用いると、ビットおよびゲインア
ロケーションを増加させることにより（相対的に）変更するよりも、やや信頼性
が高いと考えられている。逆に、ビットスワッピングのように、パラメータを増
加させることにより変更する場合、システムが同期から抜けても、システムの再
トレーニングの不足を再同期化するメカニズムが存在しない。

【００３１】高速スワッピングコマンドがビットエラーを含む可能性があるため、エラーフ
ィールド１０８が、そのエラーを検出するために用いられる。エラーフィールド
は、トランスミッタによる高速スワッピングコマンドの解釈を検証するために用
いられる値（例えば、チェックサム）を含む。トランスミッタが、高速スワッピ
ングコマンドの解釈にエラーを検出すると、トランスミッタは、要求された変更
を実現しない。エラーなく有効に伝送された変更要求のみをトランスミッタが実
現できるように、エラー検出が用いられる。また、エラーフィールド１０８のサ
イズは、適切なエラー検査構成の実装を容易にするために、広く変化させること
ができる。例えば、示されている実施形態では、エラーフィールド１０８は、高
速スワッピングコマンドの後ろの２バイトを占めており、ＣＲＣ（巡回冗長検査
）値を格納している。

【００３２】ＣＲＣは、当業者に周知であるので、簡単のため、詳しく説明しない。しかし
ながら、高速スワッピングコマンドの伝送において１３ｄＢのマージンのロス（
逆方向のリンクが、順方向のリンクと同じ障害に影響されるために、一時的に高
いエラー確率を示すことがある）があった場合でさえ、ＣＲＣの失敗は、およそ
２０年に一度しか起こらないと推定されていることに言及すべきである。そのた
め、回線の補修が必要なほど壊滅的なイベントを防ぐには、高速スワッピングコ
マンド伝送が実に信頼できる。

【００３３】本発明の別の実施形態では、ＶＤＳＬのような他のフォーマットに対応するよ
うに、高速スワッピングコマンドを少し変更してもよい。そのような一実施形態
では、サブチャンネルのＳＮＲの変更を検出する際に、レシーバは、ＶＤＳＬオ
ーバヘッドチャンネル（ＶＯＣ）を経由してトランスミッタに高速スワッピング
要求を送り返すことにより、高速スワッピングを開始する。ここでも、高速スワ
ッピングコマンドは、一回だけ送信され、コマンドの伝送により、ｎトーンのビ
ット分布（もしくはゲイン分布）の変更を可能とする。１つの実装では、ＶＤＳ
Ｌ高速スワッピングコマンドは、ＶＯＣメッセージフィールド、高速スワッピン
グ制御フィールド、一連の１つ以上のトーンメッセージフィールド、ダミービッ
トフィールド、エラーフィールドを含む。ＶＯＣメッセージヘッダは、１バイト
を占め、１１１１００１０もしくは１１１１００１１のパターンのいずれかから
なり、保証高速スワッピング要求を示す。ヘッダパターン１１１１００１０は、
高速スワッピングが次のビットスワッピングフレームで実行されるべきであるこ
とを意味し、パターン１１１１００１１は、高速スワッピングが次の次のビット
スワッピングフレームで実行されるべきであることを意味する。高速スワッピン
グ制御は一般に、１２ビットを用い、ビット／ゲイン分布が更新される必要があ
るトーンの総数（ｎ）を示すよう構成されている。あるいは、ＶＤＳＬコマンド
は、１つのヘッダ（１１１１００１１）と、高速スワッピングを実施するビット
スワッピングフレームもしくは高速ビットスワッピングを実施するフレームの数
を指定するための１ビットとトーンカウントを指定するための１２ビットを含む
ＥＳ制御のみを持つことにより、上述の高速スワッピングコマンドと同様に構成
されていてもよい。

【００３４】トーンメッセージは一般に、２０ビットを用い、サブチャンネルインデックス
と所望値インジケータを含む。最初の１２ビットはサブチャンネルインデックス
を示し、次の８ビットは所望値インジケータを示す。所望値インジケータの４ビ
ットの上位ニブルは、ビットの新しい絶対数（０ビットは００００、２ビットは
００１０、１５ビットは１１１１となる０から１５までの数）をエンコードし、
４ビットの下位ニブルは、最も重要なビットサインビットとして、いくつかの既
知の公称値に対する所望のゲインレベルをエンコードする（（０．５ｄＢずつ増
加する）−４から＋３．５の間の２’ｓコンプリメント４ビット量による）。ダ
ミービットフィールドは、コマンドがバイトに一様に記述されるように、高速ス
ワッピングコマンドに対する総ビット量を調整するよう構成されている。したが
って、ｎ（更新が必要なトーンの数）が偶数である場合には、ダミービットフィ
ールドは、コマンドに４ビットを付加し、ｎが奇数である場合には、ダミーフィ
ールドは、コマンドに任意のビットを付加する。エラーフィールドは一般に、エ
ラーの検出に１６ビットのＣＲＣ保護を用いる。さらに、ダミーフィールドは制
限とならず、コマンドは他の方法で構成されてもよいことに注意すべきである。
例えば、コマンドは、可変長のエラーフィールドを持つように構成されていても
よい。

【００３５】或るコマンドに対する特定のビットカウントと特定のビットパターンを実装例
で説明したが、割り当てられるビットの実際の数と、特定のコマンドもしくはフ
ィールドに用いられる特定のビットパターンは、いかなる場合の必要にも応じる
よう広く変更することが可能であることは明らかである。

【００３６】ビットスワッピングにおいて、応答コマンドは通例、トランスミッタによって
レシーバに送られ、スワッピングが実施される時間を調整する。すなわち、トラ
ンスミッタは、或る特定のシンボルで変更を実現するという情報をレシーバに送
る。対照的に、高速スワッピングにおいては、高速スワッピングを開始するレシ
ーバが、返された信号をモニタリングし、トランスミッタによってコマンドが実
現されたか否かを決定する。記述している高速スワッピングには、０ビットのス
ワッピング応答コマンドがある。これらの応答コマンドは、スワッピングのため
の実行時間を増加し、高速スワッピングでは回避されることが好ましいため、高
速スワッピングが行われた時間を知るためにレシーバを必要とする。

【００３７】次に、図４を参照して、本発明の一実施形態に従い、開示している高速スワッ
ピング伝送方式の実装に適したモデムアーキテクチャを説明する。モデム２００
は、トランスミッタ２０２を含む。トランスミッタは、エンコーダ２０６、離散
マルチトーン変調器２０８、ウィンドウ操作フィルタ２１０、コントローラ２１
１を含むいくつかの要素が組み込まれている。エンコーダ２０６は、伝送される
データ（ビデオデータなど）を多重化、同期化、エンコードする機能を持つ。よ
り詳細には、エンコーダは、多重なサブチャンネル各々に対して、入力ビットを
同位相の直交要素に変換する。エンコードは、様々なエラー訂正方式を用いて行
うことができる。例えば、前進型誤り訂正は十分に機能する。エンコーダ２０６
は通例、システムに利用可能なサブチャンネルの数と等しいサブシンボルシーケ
ンスの数を出力するよう構成される。例えば、２５６のサブチャンネルを有する
システムでは、エンコーダ２０６は、制限された周波数帯域で２５６サブシンボ
ルシーケンスからサブチャンネルの数を引いた値を出力する。これらの入力は、
離散マルチトーン変調器２０８に通される複合入力である。変調器２０８は一般
に、任意の適したアルゴリズムにより逆フーリエ変換を計算するＩＦＦＴ変調器
である。

【００３８】エンコードされた信号が変調され、離散マルチトーン信号を形成した後、変調
された信号は、ウィンドウ操作フィルタ２１０および／またはその他のフィルタ
を通され、帯域エネルギの不足を最小化する。リモートレシーバのアナログイン
タフェースが飽和するのを防ぐには、これが望ましい。ウィンドウ操作は、様々
な従来のウィンドウ操作プロトコルによって行うことができる。また、トランス
ミッタは、アナログインタフェース２１２を含んでいる。アナログインタフェー
スは、離散マルチトーン信号を伝送メディアに送信する。ツイストペア電話回線
や同軸ケーブルのような配線システムでは、アナログインタフェース２１２は回
線ドライバの形を取ってもよい。

【００３９】また、モデム２００は、トランスミッタからマルチトーン信号を受信するため
のレシーバ２０４を含む。レシーバ２０４は一般に、アナログインタフェース２
１４、タイムドメインイコライザ（ＴＥＱ）２１６、復調器２１８、デコーダ２
２０、コントローラ２２１を含む。モデム２０４によって（トランスミッタから
）受信された信号は、まず、アナログインタフェース２１４を通して受信される
。タイムドメインイコライザ２１６は、受信された信号に対してフィルタリング
機能を有効に実行する。ウィンドウ操作フィルタ（図示せず）を用いてもよい。
復調器２１８は、等化された離散マルチトーン信号を復調し、デコーダ２２０は
、復調された信号をデコードする。復調器２１８とデコーダ２２０はそれぞれ、
変調器２０８とエンコーダ２０６の逆の機能を有効に実行する。例えば、復調器
２１８は一般に、任意の適したアルゴリズムによりフーリエ変換を計算するＦＦ
Ｔ変調器である。次に、デコードされた信号は、デコーダ２２０から、テレビ電
話、テレビ、コンピュータ、その他の適切な受信装置などのリモートデバイス２
２２へ通される。

【００４０】離散マルチトーンシステム（ＤＭＴ）では、ＤＭＴ信号のビット分布は、シス
テムの伝送性能を向上するように適応的に決定される。これを容易にするために
、システムは一般に、通信回線をモニタリングして利用可能なサブチャンネル各
々の回線の質を決定する回線モニタ（図示せず）を備える。一実施形態では、回
線モニタは、ノイズレベル、各サブチャンネルのゲインおよび位相の変動を決定
する。目的は、各サブチャンネルの信号／ノイズ比を評価することである。それ
ゆえ、上述のパラメータに加えてもしくはその代わりに、他のパラメータをモニ
タリングしてもよい。各サブチャンネルで伝送されるデータ量の決定はもちろん
、エンコードされたデータを伝送するサブチャンネルの決定も、いくつかの要素
に基づき動的に行われる。その要素は、検出された回線品質パラメータ、サブチ
ャンネルゲインパラメータ、許容パワーマスク、所望の最大サブキャリアビット
誤り率を含む。それらの要素は、サブチャンネルの間で一定である必要がなく、
使用中に変化してもよいことが注目される。さらに注目に値することには、回線
品質パラメータは、繰り返し検査されることが可能であり、リアルタイムで変調
方式での調整がなされ、様々なサブチャンネルの回線品質が使用中に変化するの
に応じて、動的に変調を調整する。チャンネルのモニタリングについては、以下
で詳細に説明する。

【００４１】ほとんどの構成で、レシーバ２０４は、チャンネルの性能をモニタリングしＤ
ＭＴの適応を制御するよう構成されている。例えば、コントローラ２２１は、上
述したように回線モニタを備えてもよい。特に、レシーバ２０４は、チャンネル
出力信号をモニタリングし、トランスミッタのビットおよびゲインテーブル２２
４の変更の必要性を確認する。そのテーブルは、ビット数とそれに対応した伝送
エネルギ（もしくは同等物）を格納し、各ＤＭＴトーン（もしくはサブチャンネ
ル）によって用いられる。トランスミッタ２０２とレシーバ２０４は共に、同じ
テーブルのコピーを格納し、それぞれが、エンコードとデコードのためにそれら
を用いる。例えば、図２に示され説明されているテーブルを用いてもよい。理解
されるように、伝送回線が時間と共に変化するのに応じて伝送性能の改善を引き
起こすこれらのテーブルの変更が、連続的なモニタリングにより決定される。さ
らに、ＡＯＣ（ＡＤＳＬオーバヘッドチャンネル）２２６は通例、点線で示され
ているように、レシーバ２０４からトランスミッタ２０２に戻される。よく知ら
れているように、ＡＯＣ２２６は、通信のためにレシーバとトランスミッタの間
で用いられるシステムの全帯域の専用部分である。例えば、２５６トーンのシス
テムの最初の３２のトーンは、ＡＯＣ２２６のために確保してもよい。

【００４２】変更の必要性を決定する際、コマンド（例えば、変更の要求）が、ＡＯＣ２２
６を通してトランスミッタ２０２に送られる。ほとんどの実施形態で、トランス
ミッタのビットおよびゲインテーブル２２４の構成（例えば、ＤＭＴ伝送に用い
られる各トーンのビット数および／または伝送エネルギレベル）を変更するよう
、トランスミッタ２０２に命令するために、コマンドが用いられる。例えば、コ
マンドは、図３に示され説明されている高速スワッピングコマンドでもよい。コ
マンド受信後に、トランスミッタ２０２は、要求された変更を実現する。上述の
ように、エラーなく有効に転送された変更要求のみをトランスミッタ２０２が実
現できるように、ＡＯＣ２２６上でエラー検出が用いられてもよい。

【００４３】高速スワッピングにおいて、レシーバ２０４は、入力ＤＭＴ信号をモニタリン
グして、要求された変更がトランスミッタによって行われたか否かを決定するよ
うに構成されている。より詳細には、レシーバ２０４は、現在用いられている信
号（「カレント信号」）に関するトーン（サブチャンネル）と、所望の信号（「
要求信号」）に関するトーンを認識するように構成されている。この情報に関し
て、レシーバは、入力信号のトーンをカレント信号のトーンもしくは所望の信号
（変更要求の信号）のトーンと比較することにより、変更の要求が実現されたか
否かを確認できる。カレント信号を例とすると、入力信号のトーンがカレント信
号のトーンと実質的に同じである場合、レシーバは、変更の要求が実現されてい
ないと決定することができる。一方、入力信号のトーンがカレント信号のトーン
と実質的に異なる場合、レシーバは、要求が実現されたと決定することができる
。本発明は、カレント信号もしくは変更要求信号を別個に用いることに限定され
ず、それらを組み合わせて用いてもよいことに注意すべきである。すなわち、入
力信号のトーンを、カレント信号のトーンと変更要求信号のトーン両方と比較す
ることができる。

【００４４】さらに詳しく述べると、高速スワッピングレシーバは一般に、古いビット／ゲ
インテーブル２２７と新しいビット／ゲインテーブル２２８とを含む。古いビッ
ト／ゲインテーブル２２７は、レシーバ２０４が変更の必要を決定する前に用い
られていた信号に関するもので、新しいビット／ゲインテーブル２２８は、レシ
ーバ２０４が変更の必要を決定した後に要求された信号に関するものである。デ
コーダ２２０は、両方のテーブルを用いて、入力信号が古いか新しいかを決定す
る。すなわち、古いチャンネルゲイン（古いテーブル）、新しいチャンネルゲイ
ン（新しいテーブル）、もしくは新旧両方のチャンネルゲインの組み合わせ（古
いテーブルと新しいテーブル）に従って、入力信号をデコードすることができる
。それに応じて、入力信号が、古いビット／ゲインテーブル２２７で動作する場
合、デコーダ２２０が信号を古いビット／ゲインテーブル２２７と比較する際の
エラーは少数で、デコーダ２２０が信号を新しいビット／ゲインテーブル２２８
と比較する際のエラーは多数である傾向があるだろう。逆に、入力信号が、新し
いビット／ゲインテーブル２２８で動作する場合、デコーダ２２０が信号を新し
いビット／ゲインテーブル２２８と比較する際のエラーは少数で、デコーダ２２
０が信号を古いビット／ゲインテーブル２２７と比較する際のエラーは多数であ
る傾向があるだろう。したがって、レシーバ２０４は、これらのデコードに基づ
いて変更がなされたか否かを決定することができる。

【００４５】さらに、レシーバが上述の比較を行うことが可能であっても、比較的迅速に行
う必要がある。それゆえ、レシーバは、或る特定の期間、入力信号を解析するよ
うに構成され、この期間内に変更の要求が検出されない場合には、レシーバは、
トランスミッタが変更を実現しなかったことを認識する。例えば、最後のＡＯＣ
バイトが送られた後に、レシーバが、受信されたチャンネル出力のビットテーブ
ルに変更がないことを認識した場合、レシーバは、トランスミッタが何らかの理
由で高速スワッピングを実行できなかった、もしくは、実行できないことを認識
する。一実施形態では、ダウンストリームとアップストリームの待ち時間と中断
時間を合わせた間に、変更の要求が検出されなかった場合、レシーバは、トラン
スミッタがコマンドを実現しなかったと認識する。次に、レシーバは、性能が許
容不可能な場合には、高速スワッピングコマンドの再送信、他の正しいコマンド
の利用、再トレーニングの実行のいずれかを選択すればよい。１つの特定の実施
形態では、中断時間が次のスーパーフレームの境界に選ばれる。それは、上手く
機能すると思われる。この実施形態では、最悪の場合の中断時間１７ｍｓが提供
されている。しかしながら、中断時間は、非常に速くなるように構成されている
。例えば、中断時間は、約２ｍｓに構成されていてもよい。

【００４６】モデムアーキテクチャを詳細に説明したが、本発明の趣旨および範囲から逸脱
しない範囲内で、他の多くの特定の形態でモデムアーキテクチャを実現できるこ
とを理解する必要がある。

【００４７】本発明の一態様に従って、要求レシーバは、２つのデコーダを用いて、古いビ
ット／ゲインテーブル（例えば、カレント信号）と新しいビット／ゲインテーブ
ル（例えば、変更要求信号）により入力信号をデコードするよう構成されている
。要求された変更が実現されたか否かの決定は、少なくとも一部はこれら２つの
デコードに基づいてなされる。例えば、変更の要求が実現されたか否かの決定は
、少なくとも一部は、各デコードを用いて検出されたエラーの解析と、エラーの
量が最小のデコードの選択に基づいて行うことができる。通例、エラーの量が最
小の信号は、伝送されている信号である。したがって、レシーバは、変更の要求
が実現されたか否かを決定することができる。

【００４８】図５を参照し、デュアルデコーディングレシーバ３００を本発明の１つの実施
形態にしたがって説明する。デュアルデコーディングレシーバ３００は、第１の
デコーダ３０２と、該第１のデコーダ３０２に実質的に類似の第２のデコーダ３
０４とを備える。この実施形態において、第１のデコーダ３０２は、第１のトー
ン（例えばカレント信号）のセットに関連付けられたビット／ゲインテーブル２
２７を格納するように構成され、第２のデコーダ３０４は、第２のトーン（例え
ば変更の要求を含んだ新しい信号）のセットに関連付けられたビット／ゲインテ
ーブル２２８を格納するように構成されている。

【００４９】デュアルデコーディングレシーバ３００は、また、第１のデコーダ３０２に関
連付けられた第１のシンドロームジェネレータ３０５と、第２のデコーダ３０４
に関連付けられた第２のシンドロームジェネレータ３０６と、を備える。例えば
、前進型誤り信号訂正（ＦＥＣ）シンドロームを利用したＦＥＣデコーダを使用
しても良い。第１のシンドロームジェネレータ３０５は、カレントチャンネルの
ゲインおよびノイズを使用し、入力信号の受信トーンに関して第１のシンドロー
ムを計算するように構成されている。同様に、第２のシンドロームジェネレータ
３０６は、新しいまたは推定されたチャンネルのゲインおよびノイズを使用し、
入力信号の受信トーンに関して第２のシンドロームを計算するように構成されて
いる。最小量のエラーを検出するシンドロームジェネレータによって、コレクト
マッチを獲得することができる。ここで、レシーバ３００が、一般に、（例えば
変更の要求後に）スワップが発生することを知っている場合にシンドロームを計
算するように構成されていることに、注意が必要である。また、デュアルデコー
ディングレシーバ３００は、コレクトシンドロームを有した信号を開放するため
に一般的に使用されるスイッチ３０８を備える。コントローラ２２１は、コント
ローラ２２１内に設けられたスイッチ３０８を制御するために使用されるのが通
常である。ただし、（図示されるように）これは必要不可欠ではない。

【００５０】さらに詳述すると、算出されたシンドロームにおいては、コレクトマッチが０
で示され、インコレクトマッチが１で示されるのが一般的である。例えば、第１
のシンドロームジェネレータ３０５の計算結果が０で、第２のシンドロームジェ
ネレータ３０６の計算結果が１である場合は、入力信号が第１のトーンセットの
ビット／ゲインテーブルに正しくマッチするので、レシーバ３００は、実現する
べき変更要求がまだ存在すると認識する。前述したように、これが特定期間に渡
って生じると、レシーバはタイムアウトし、変更の要求が実現しなかったと認識
する。この場合、レシーバは、別の高速スワップコマンドや何らかの他のコマン
ドを送信するか、または性能が許容不可能である場合には再トレーニングするか
のいずれかを選択しても良い。反対に、第１のシンドロームジェネレータ３０５
の計算結果が１で、第２のシンドロームジェネレータ３０６の計算結果が０であ
る場合は、入力信号が第２のトーンセットのビット／ゲインテーブルに正しくマ
ッチするので、レシーバは、変更の要求が実現されたことを知る。

【００５１】さらに、これらのシンドロームの計算結果がともに０でない場合、回線の状態
は、もともと要求された高速スワップが正しくなかったものと考えられる。これ
は、レシーバの設計ミスであり、許可されたビット分布に対する回線の動作が不
能になったので、モデムは、インジケータ（例えば不良ＬＥＤ）を再トレーニン
グするまたは起動する必要がある。すなわち、レシーバシステムが高速スワップ
によって回線を修復できない場合は、回線のメインテナンス状態を再トレーニン
グするまたは合図する必要がある。さらにまた、これらのシンドロームの計算結
果がともに０である場合は、チャンネルビット／バイトのエラーパターンが厳密
に別の（インコレクト）コードワードに対応するので、エラーの検出は失敗する
と考えられる。このような故障が生じる可能性は、ＣＲＣの失敗が生じる可能性
より大幅に小さいので、実際の用途においては０であると想定することができる
。それにも拘らずこのような故障が生じた場合、レシーバは、次のコードワード
をチェックして次いでカレントテーブルおよび直前のテーブルをピックすること
によって、出力をさらに遅延させるように選択することができる。故障率は、こ
れ以上の引き下げが不要なほどに低いのが通常である。ここで、この珍しいタイ
プの故障ですらモデムに対して破壊的でも弱点でもなく、単に、エラー（１つの
コードワード）が生じてもモデムが上手く動作を続けていくことを意味するだけ
だということに、注意する必要がある。

【００５２】本発明の別の態様に従うと、変更の要求が実現したか否かの決定は、変更要求
によって変更されることを意図される１つまたはそれ以上のトーンをモニタする
ことを含む。これらのトーン上で変更が検出されたら、変更は実現されたと想定
される。高速スワップはこれ以外の場合は変更を要求していないので、このよう
なトーンは他よりも信頼度が高い。１つまたはそれ以上のトーンのエネルギのレ
ベルおよびビットアロケーションがモニタされる。例えば、変更によって、特定
のトーンに使用可能なパワーが増す。このシナリオでは、カレント信号を使用し
た場合よりも多くのエネルギがその特定のトーン上で検出された場合に、要求さ
れた変更が実現されたと想定することができる。別の実施例では、変更によって
、特定のトーンのビット数が減少する。カレント信号を使用した場合よりも少な
いエネルギがその特定のトーン上で検出された場合は、要求された変更が実現さ
れたと想定することができる。

【００５３】１つの実施形態において、要求を出すレシーバは、変調された出力（ＦＦＴ出
力）のトーンを少なくとも１つモニタするように構成されている。これらのトー
ンは、高速スワップによってビット数の増加を要求されたトーンであることが好
ましい。これらのトーンは、さらに多数のビットを扱えるようになるので、一般
により強健（例えばノイズがより少ない）である。しかしながら、これは限定的
ではなく、ビット数が減少されたトーンを使用しても良いことに注意する必要が
ある。変更の要求が実現されたか否かの決定は、少なくとも部分的には、入力信
号の出力布置の変更に基づいて下される。出力布置は、特定のトーンにおけるビ
ットの分布を図示したものである。出力布置は、一般に、位相の推移と特定トー
ンの振幅との両方を含む。議論を促進するため、図６ａに、４ビットを割り当て
られたトーンの代表的なＦＥＱ（周波数イコライザ）出力布置４００を示した。
出力布置は当該分野で周知であるので、簡略化を図るためこれ以上の説明を省略
する。

【００５４】さらに詳述すると、第１の信号における特定トーンの第１の出力布置と、第２
の信号における同じトーンの第２の出力布置とを比較することによって、変更の
要求が実現されたか否かが決定される。第２の出力布置が第１の出力布置より大
きい場合、レシーバは、変更の要求が実現されたことを知る。例えば、変更の要
求によって特定トーン上のビット数が２だけ増加した場合、そのトーンの出力布
置上の点は４倍に増える。議論を促進するため、図６ｂに、６ビットの出力布置
５００（すなわち、２ビットが増加した後の４ビットの出力布置４００）を示す
。４ビットの出力布置４００には１６個、そして６ビットの出力布置５００には
６４個の点が存在する。図６ａが第１の信号を表し、図６ｂが第２の信号を表す
と仮定すると、レシーバは、変更の要求が実現されたか否かを受信信号の性質に
基づいて決定することができる。例えば、（１６点の布置から得られる）第１の
信号の最大ゲイン（振幅）は、（６４点の布置を有した）第２の信号の最大ゲイ
ン（振幅）より小さい。

【００５５】特定の実装形態では、特定のトーンに対して重複した１対のトーンデコーダを
利用することによって、出力布置の比較を行っても良い。デコーダは、マルチト
ーン信号で使用される各トーンに対して複数の個々のトーンデコーダを有するの
が一般的である（例えば、Ｇ．ライトに対して１２８個、Ｇ．ｄｍｔに対して２
５６個）。個々のトーンデコーダは、伝送された信号をデコードする際に、その
トーンに対して特定の出力布置を出力する。特定のトーンに対するトーンデコー
ダの数を倍に増やすと、第１の出力布置を有した第１の伝送信号を第２の出力布
置を有した第２の伝送信号と比較することによって、変更の要求が実現したか否
かを決定することができる。しかしながら、特定のトーンデコーダを全て倍に増
やすことは可能であるものの、適切な信頼度でもって変更を決定するためには、
数個のトーンデコーダを倍に増やすだけで良い。

【００５６】重要なのは、ノイズの存在下では、１ｄＢまたは２ｄＢのゲインの変更を正し
く識別できないことである。しかしながら、他のトーン上のゲイン変更に関連し
て生じる１トーン上のゲイン変更は、より高い信頼度で検出することが可能であ
る。したがって、レシーバは、変更の要求が実現されたか否かを決定するに当た
って、１つのトーンをモニタリングすることに限定されない。レシーバは、ビッ
トの増加および／または減少ならびに追加のゲイン変更を生じた複数のトーンを
モニタリングしても良い。

【００５７】別の実施形態において、レシーバは、高速スワッピングコマンド内のグッドト
ーンを一時的に０にし、変更要求がトランスミッタによって実現されたか否かを
決定するように構成されても良い。そのトーン上における伝送エネルギの欠如は
、トランスミッタによって変更要求が実現されたことを示す。同じトーンを後に
再作動させる（そしてエネルギの存在によって再検出される）第２の高速スワッ
ピングコマンドは、マージンをフルレベルまで再格納することができる。１トー
ンの損失が性能に及ぼす影響は小さいのが通常であるが、一般にはチャンネルに
も依存する。

【００５８】以上から、ＤＭＴシステムにおいて高速スワップ（または任意のスワッピング
）を有効に使用するためには、正確且つ迅速なチャンネルの識別が非常に重要で
あることが理解できる。低精度または不正確なチャンネルのモニタリングは、他
のあらゆるリーズナブルな回線変更よりもずっとＤＭＴの伝送故障を招きやすい
が、これは突然に生じる。したがって、チャンネルを首尾良くモニタリングする
ための実施形態を幾つか説明する。ここで、以下で述べる方法は限定的ではなく
、回線の状態をモニタリングするための独創的なメカニズムは数多く存在するこ
とを、理解する必要がある。また、これらの方法が、一般に、ビット／ゲイン分
布におけるマイナーな差異よりも、チャンネルのグロス変更を扱う場合において
最も有用であることを、理解する必要がある。例えば、チャンネルのグロス変更
は、ＤＭＴシステムの少なくとも１つのトーンにおいてスライサービットエラー
を生じるほどにグロスである可能性がある。このようなチャンネル変更を識別で
きるならば、高速スワッピングは、このタイプの状況でチャンネルを迅速に訂正
するのに有用である。

【００５９】例えば、少なくとも３種類の測定によってグロス変更が強く示される。すなわ
ち、シンドロームが０でないこと、ＣＲＣバイオレーションがスーパーフレーム
レベルであること、そして瞬間または短期の平均平方エラー／ノイズの推定値が
高いことの３つである。レシーバは、これら３つのうち任意または全部を平凡に
測定し、グロス変更状態に入ることを決定することができる。グロス変更状態で
は、チャンネルの出力パワーを迅速に測定することができる。ノイズは、対象と
なる任意のトーン上において、レシーバに送信される信号より少なくとも１０ｄ
Ｂだけ低いのが通常であるので、瞬間的なチャンネル出力パワーの推定値は、チ
ャンネルゲインの変更を確認できるだけの精度を有する。例えばオフ／オンフッ
クインピーダンスの変更によって生じたチャンネルゲインの変更は、同時に多く
のサブチャンネルにも影響するので、新しく作動されたクロストークノイズから
容易に識別することが可能である。

【００６０】チャンネルの変更は、一般に、測定されたチャンネルの移送機能の変更に対応
している。これらの変更は、回線の減衰やチャンネルの遅延等の変更と同じくら
い顕著である。チャンネル温度の変化は、非常に低速であって且つＳＢまたはＥ
Ｓのいずれかによって充分に扱えるチャンネルの変更を引き起こす。雨天時にお
いて水が入ったケーブルによって生じる湿度の変化は急速である（そして回線の
故障を引き起こす場合が多い）。湿度が充分に小さく、チャンネルが動作可能な
状態を維持できる場合、チャンネルは、１秒またはそれ以内で急速に変更するこ
とができる。オフ／オンフックインピーダンスの変更は、チャンネルゲインの変
化のうち最も急速なタイプであり、ほぼ全部の伝送バンドに渡って１〜１０ｄＢ
の減衰ロス／ゲインを引き起こすのが通常である。

【００６１】ゲインの変更を検出するため、レシーバは受信パワー全体をモニタリングする
。受信パワーが大きく変化した場合は、ゲインパスの追跡が行われ、ノイズパワ
ーは変化しなかったものと推定される。チャンネルの総出力パワーの変化は、一
般に、チャンネル出力サンプルの平方の和をモニタリングすることによって検出
される。チャンネル出力パワーの１ｄＢまたはそれ以上の変更は、１０００個ま
たはそれ未満のサンプルを使用することによって、（Ｇ．ライトサンプリング率
では１ｍｓ、他のＤＳＬではさらに高速で）高い信頼度で推定するこことができ
る。周波数（トーン）に対するチャンネル変更の依存性を識別する方法は、同期
シンボル（最悪でも１７ｍｓしか離れていない）が次に生じた際に、チャンネル
ＦＦＴ出力を既知の同期シンボルＦＦＴによって割るものである。ノイズは変化
していないので、任意の使用済みトーン上の信号よりかなり小さい。新しく推定
されたトーンゲインのセットは、格納された過去からのチャンネルプロフィルと
比較することができる。レシーバイコライザは、新しく算出されたゲインに応じ
て直ちに更新することができ、結果として得られる新しいビット分布が、ＥＳコ
マンドによって直ちにトランスミッタに伝達される。全体の推定時間は、新しい
ビット分布が既知となるまでに２０ｍｓぐらいで良い。

【００６２】第ｎトーン上の周波数領域において、出力Ｙ_nは数１によって入力Ｘ_nに関連付
けられている。

【００６３】

【数１】

【００６４】ここで、Ｈ_nおよびＮ_nはチャンネルゲインおよびノイズパワーである。（事前
の初期化、再トレーニング、または高速スワップをもとに）事前に識別されたチ
ャンネルゲインのセットは、ＤＭＴシステムが事前に識別した各チャンネルプロ
フィルために格納することができる。これらの格納されたプロフィルは、ｌ＝１
，...,の場合にＰ_l,nで表される。ＤＭＴシステムクロックは、プロフィルが最
後に生じたときから相対的なタイミングオフセットεだけずれるので、古いプロ
フィルの設定から線形に位相偏移を生じる。

【００６５】

【数２】

【００６６】首尾良いプロフィル検出によって、事前のプロフィルのなかに、同期シンボル
の既知のＸ_nに対して最後に測定されたＨ_nに最も良くマッチするプロフィルが存
在するか否かが識別される。

【００６７】先ず、プロフィルは既知でないので、プロフィルを生成しなければならない。
Ｈ_nの単純な推定値は、数３である。

【００６８】

【数３】

【００６９】ここで、Ｍは使用された同期シンボルの数である。Ｍが大きいほど正確なチャ
ンネル推定値を得ることができるが、訂正高速スワップの実現は遅れる。推定値
の差異はＭに比例して減少するのが一般的であるので、測定されたＳＮＲは、９
９％の確定度で、数４だけ高すぎるまたは低すぎる（高すぎると問題になる）。

【００７０】

【数４】

【００７１】４つの同期シンボルを経ると、算出されたＳＮＲエラーは９９％の確定度で２
ｄＢ未満になる。あらゆるレシーバゲイン／位相回転（一般に「ＦＥＱ」と称さ
れる）を、数５の比で直ちに調整する必要がある。そして、もし必要ならば、新
しいチャンネルをプロフィルの１つとして格納することができる。

【００７２】

【数５】

【００７３】しかしながら、あるプロフィルが事前に識別されていた場合は、このプロフィ
ルの再発生を最大尤度のプロフィル検出に従って高信頼度で検出するために、同
期信号を単独で使用することができ、こうして、（可能なベクトルプロフィルＰ _l に対する）和を最小化するプロフィルが選択される。

【００７４】

【数６】

【００７５】偽のプロフィルが検出される可能性は、ノイズおよびプロフィル間の近さに依
存し、特に、数７による制約を受ける。

【００７６】

【数７】

【００７７】ここで重要なのは、互いに混同された２つのプロフィルが近すぎて、対応する
ビット／ゲインテーブルが機能的である場合は、偽の検出はリンクの機能異常に
対応しないことである。レシーバエキスパートシステムによってプロフィルを厳
密に維持することによって、対応する訂正ビット分布がＤＭＴのリンク故障に通
じる偽の検出を生じる可能性が非常に低いように、プロフィルを選択する必要が
ある。

【００７８】さらに、パワーの合計測定値によって顕著なチャンネルゲイン（または出力パ
ワー）の変更が検出されなかった場合は、顕著なノイズの変更が想定される。ノ
イズの差異を正確に推定するためには、トレーニング信号を使用した場合であっ
ても、ＤＳＬモデムにおいて数秒の時間を要する。しかしながら、通常のように
、ノイズ導入前のマージンが高かった場合は、サブチャンネルを慎重にロードす
ることが可能である。ガウスのノイズサンプルは、０．９９７の可能性で±３σ
（３標準偏差）分布点の範囲内に入るのが通常である。ノイズが１０ｄＢまたは
それ以上増加すると、６ｄＢのマージンで１ｅ−７でもともと動作しているＤＳ
Ｌモデムにおいて、許容不可能なほど高い誤差率が引き起こされる。レシーバ内
のＦＦＴ出力におけるスライサーエラーの有無に拘らず、大きいノイズに対する
エラーサンプルの分布には、より大きな差異が存在する。レシーバは、一般に、
その分布を推定することができる（ガウスノイズに関しては、この分布によって
差異が推定される）。新しいノイズの厳密な差異を非常に正確に推定するために
は相当数のサンプルが必要である（１／１０ｄＢの精度を得るためには３２００
程度のサンプルが必要であり、これは、非効率的なエスティメータを使用した場
合でも１秒以内のトレーニングですむ）一方で、大きな変更に対応してより高速
なグロスインジケータを使用することも可能である。顕著なノイズの増加が検出
されたこれらのトーンは、ＥＳを介してビットテーブル内でゼロ化される。これ
らのトーンがＥＳ要求に応じて非動作されるのに伴って、後続のノイズの推定を
継続することができる。ローディングの結果がより正確である場合は、後続のＥ
Ｓコマンドによって、より詳細化されたビット分布を伝送することができる。さ
らに、ＩＳＤＮクロストーク、ＨＤＳＬクロストーク、または他タイプの既知の
クロストークに近いノイズプロフィルを最初に概算し、次いで高性能のレシーバ
で詳細化することによって、ＥＳコマンドを介した非常に高速な調整が可能にな
る。

【００７９】さらに詳述すると、ノイズの変更が大きい場合は、何の信号も伝送しない、す
なわちトーンから０を出力することが、ノイズを決定する効果的な方法である。
以下では、トーンの出力ゼロ化によってノイズを推定する方法を幾つか説明する
。

【００８０】一般に、チャンネルの変更がなくて（仮定）同期シンボルが既知である場合に
は、各トーンの瞬間的なノイズサンプルを決定することができる。これは、数８
によって最適に表される。

【００８１】

【数８】

【００８２】ノイズパワーは、数９によって推定される。

【００８３】

【数９】

【００８４】次いで、レシーバは、これらのトーンをゼロ化するよう、ＥＳコマンドを介し
てトランスミッタに通知する。ここで、数１０は、もとのノイズパワーに比例し
た特定の閾値より大きい。

【００８５】

【数１０】

【００８６】一般に、ノイズの推定を高速化するためには、レシーバが、小さい値をＭとし
て選択しなければならない。すると、ノイズパワーの推定が不正確になり、この
ためにトーンの出力ゼロ化のプロフィルが不正確になる恐れがある。トーンの出
力ゼロ化のプロフィルの精度は、ノイズ差異のパワースペクトル密度が比較的滑
らかであると想定することによって、改善することが可能である。このような滑
らかさを想定することを利用したクラスタ化の方法は、数多く存在する。

【００８７】１つの実施形態において、連続したトーンセットをクラスタ内で規定する状況
は、一般に、ゼロ化されたまたは未使用のトーンであるエンドトーンであり、ク
ラスタに先行するおよび後続するトーンは使用後のトーンである。この実施形態
では、モデムによる使用を意図したトーン（すなわち非ＰＯＴＳトーン）のみを
対象とする。一般に、ゼロ化トーンは、ノイズが充分大量に増加したために０ビ
ットを伝送するトーンとして規定され、使用後のトーンは、新しいローディング
後も非ゼロビットを伝送するトーンとして規定され、未使用のトーンは、チャン
ネルの低ゲインまたはノイズの高差異のいずれかが原因で、ローディング前にゼ
ロビットを伝送していたトーンとして規定される。

【００８８】以下に上げる実施例において、クラスタ化の方法を示す。ここでは、記号０、
Ｘ、Ｕが、ゼロ化トーン、使用後のトーン、未使用のトーンをそれぞれ表すもの
とする。２０トーンに対し、次のようなトーンの出力ゼロ化プロフィルが与えら
れると、

【００８９】

【表１】

【００９０】可能なクラスタは、（２，２０）、（２，１８）、（２，９）、（２，６）、（
４，２０）、（４，１８）、（４，９）、（４，６）、（８，２０）、（８，１
８）、（８，９）、（１２，２０）、（１２，１８）である。

【００９１】クラスタの識別に続く次の工程は、どのクラスタの非ゼロ化トーンをゼロ化す
るかを決定する工程である。これは、以下の経験則に従って行うことができる。
先ず、少なくとも一定割合のトーンがゼロ化された最大サイズのクラスタを探し
、次に、同じ割合のトーンがゼロ化された次に大きいサイズのクラスタを探し、
これを、全部のクラスタが探されるまで繰り返す。このクラスタのサイズが使用
後のトーン数と同じである場合は、リテインする。それ以外の場合は、クラスタ
内の非ゼロ化トーンをゼロ化し、もし可能ならば使用後の他のトーンにビットを
移動させ、すでにゼロ化されたクラスタは無視して第１の工程に戻る。上述した
実施例において、上述した割合が７５％である場合は、トーン３、７、１９がゼ
ロ化される。

【００９２】ＥＳコマンドを送信する必要なしにトーンをゼロ化する代替の方法は、トラン
スミッタおよびレシーバにとってともに既知である所定のシーケンスを使用して
、トーンのサブセットをゼロ化するものである。この場合は、このトーンゼロ化
の方法の開始を合図するコマンドが必要である。測定される信号がノイズのみで
あるゼロ化されたトーンでは、ノイズパワーの移動平均推定値を得ることができ
る。ゼロ化されたトーンに関して、信号の平均が４０シンボルを超える場合、信
号は、９９％の信頼性で真のノイズ差異の２．０ｄＢの範囲内にある、または９
９．９％の信頼性で真のノイズ差異の３ｄＢの範囲内にあることができる。

【００９３】ノイズ推定値のセットが得られたら、最大尤度法によって、格納されたノイズ
プロフィルと突き合わせることができる。クロストークノイズプロフィルの典型
例として、ＩＳＤＮ、ＨＤＳＬ、およびＴ１が挙げられる。

【００９４】最も適当なプロフィルの選択方法として最尤見積もりを使用するに当たり、得
られたノイズサンプルに最も一致するノイズ差異のプロフィルを探す必要がある
。プロフィルがどれもそれらしい場合は、数１１を求める必要がある。

【００９５】

【数１１】

【００９６】ここで、数１２は、ｋ番目のトーン上におけるノイズ測定を含むＬ次元の複素
ベクトルであって、Ω_jは、差異を含むｊ番目のクロストークプロフィルである
。Ｌは、ｋ番目のトーン上で行われたノイズ測定の番号を示す。この式（数１１
）は、数１３のように簡略化される。

【００９７】

【数１２】

【数１３】

【００９８】ここで、Ｌは、ノイズ差異を推定するために使用されるシンボルの数であり、
σ² _j,iはｊ番目のプロフィル内のｉ番目のトーンの差異であり、数１４、数１５
であり、Ｎ_k,iは、ｉ番目のプロフィルの時刻ｋにおけるノイズの測定値であり
、Ｄ_iはｉ番目のトーン上における経験的なノイズ差異である。上記の式（数１
３）によって、ノイズの測定値に最も近いノイズプロフィルを識別することが可
能になる。

【００９９】

【数１４】

【数１５】

【０１００】以下に挙げる３つの実施例では、高速スワッピングおよびビットスワッピング
の実現速度を比較する。

【０１０１】実施例１：１つのビットをスワップする従来のビットスワッピングで１ビットを移動させる場合は、６０バイトのＡＯ
Ｃ帯域幅が必要である。これは、論理的には、双方向のＡＯＣチャンネルを約３
０ｍｓ（６０バイト／（２０００バイト／秒））で横断することができる。しか
しながら、Ｇ．ライトおよびＧ．ｄｍｔの標準では、（実装の遅延が原因で）８
００ｍｓ以内で１ビット以上のスワップ変換を行うことはできない。８００ｍｓ
は、高速スワッピングには適用されない。逆方向の相互運用性のため、従来のビ
ットスワッピングからこの８００ｍｓの問題を排除することは難しい（しかしな
がら、高速スワッピングを使用するモデムでは、このような問題は存在しない）
。反対に、高速スワッピングは、一方向性のＡＯＣチャンネルのみを使用する８
バイトのコマンドを必要とするので、約２１ｍｓ（８バイト／（２０００バイト
／秒））＋１７ｍｓ（最悪の場合のタイムアウト）の時間がかかる。

【０１０２】

【表２】

【０１０３】実施例２：１０トーン上で４０ビットを移動させるこのタイプのスワップとしては、例えばＡＭラジオレシーバのパワーが夜間に
レベルアップする場合のような、回線上における緩やかなノイズ変化が代表的で
ある。従来のビットスワッピングでは、論理的に、最低でも６０バイト×（４０
ビット）＝２４００バイトが必要であり、１．２秒の時間がかかる。実際にかか
る時間は、（１ビットのスワップごとに最低８００ｍｓが必要だと考えて）４０
（．８ｓ）＝３２秒である。これに対して高速スワッピングでは、２バイト×（
１０トーン）＋４バイト＝２４バイトが必要で、２９ｍｓの時間がかかる（最悪
の場合のタイムアウトである１７ｍｓを含む）。したがって、ビット数が多いほ
どスピードアップも大きくなる。

【０１０４】

【表３】

【０１０５】実施例３：１００トーン上における４００ビットのプロフィル変更このタイプのスワップとしては、例えばオフフックのインピーダンス変更等の
、回線上における激しいチャンネル変更が代表的である。ビットのスワッピング
プロトコルでは、論理的に１２秒そして実際には３２０秒が必要である。この場
合は、ビットのスワッピングによって問題を修正している間にエラーを生じる可
能性があるので、リテインは明らかに高速であり、使用する必要があると考えら
れる。高速スワッピングが２０４バイトのＡＯＣコマンドで４００ビット全部を
移動させるのに、１１９ｍｓの時間が必要である。ビットスワッピングの高速化
は著しく、サービスの介入がないので、リテインより大幅に高速である（ただし
、チャンネルの特性が著しく変化した場合は、高速スワッピングインターバルに
おいて幾らかのビットエラーを生じる可能性がある）。

【０１０６】

【表４】

【０１０７】さらに詳述すると、ＥＳの実現には（２ｎ＋４）／Ｒ_AOC＋Ｔ_time-out秒が必
要であり、ここで、ｎ＝該当トーンの数、Ｒ_AOC＝バイト／秒で表されたＡＯＣ
のチャンネル速度、Ｔ_time-out＝タイムアウトの時間である。タイムアウトの時
間は、最悪の場合で１７ｍｓであり、もっとずっと速くても良い。タイムアウト
の時間とは、ＡＯＣバイトが最後に送信された後、レシーバによって、受信され
たチャンネル出力のビットテーブル内において何の変更も見出されなかった場合
に、レシーバが、トランスミッタは何らかの理由でＥＳを実現できなかったまた
は実現できないと想定するのに必要な時間である。簡略化のため、タイムアウト
は、次のスーパーフレーム境界となるように選択される（ただし論理上はもっと
小さい）。従来のスワッピングでは、移動されたビット数をｂとした場合に、必
要な時間は僅か０．８ｂ秒であった。図７は、ｋ＝１，２，５，１０の各場合に
関し、ｂ＝ｋｎの改善度を該当トーン数に対してプロットしたグラフである。（
この特定のプロットは、実際には２ｍｓのタイムアウトを使用しており、これは
やはり対象範囲内である）図示されるように、ＥＳプロトコルの改善度はいずれ
の場合も非常に大きい。したがって、このプロトコル自体が、高速スワッピング
を行うに足る能力を有する。

【０１０８】以上からわかるように、本発明は従来技術と比べて多くの利点を有する。例え
ば、高速スワッピングによってビットスワッピングが高速化される。高速スワッ
ピングの速度がビットスワッピングの１０，０００倍の速度に達する場合もある
。さらに、高速スワッピングの実行時間はほとんど瞬間的であり、特に大きいク
ロストーカが突然導入された場合などに、多数の著しい変更間で接続性を維持す
るのに充分である。また、高速スワッピングコマンドの使用では、初期化中に追
加の情報を引き渡す必要はない。すなわち、確認通知パケットはなく、変更要求
コマンドは１度だけ送信されれば良い。さらにまた、高速スワッピングは、より
高速な変更が要求される状況における接続の信頼度を高めることによって、再ト
レーニングの必要性および頻度を低減することができる。

【０１０９】ビットスワッピングに関連した詳細は、次に挙げる参考文献にも記述されてい
る。すなわち、Salvekar et al.「CHANNEL GAIN CHANGE DETECTION AND CHANNEL
PROFILE SELECTION IN A MULTCARRIER SYSTEM（マルチキャリアシステムにおけ
るチャンネルゲインの変更の検出およびチャンネルプロフィルの選択）」Globec
om，１９９９年１２月、John M.Cioffi「VDSL ALLIANCE:VDSL TRANSMISSION SPE
CIFICATION（ＶＤＳＬ伝送仕様）（００−１１６）」T1E1.4:VDSL，２０００年
２月、およびCioffi et al.「G.LITE.BIS:ANALYSIS OF EXPRESS SWAPPING SPEED
S AND RELIABILITY（高速スワッピングの速度および信頼性の分析）」１９９９
年４月であり、これらの文献を、本明細書に引用として組み込むものとする。

【０１１０】次に、スワップの速度を増加させる代替の方法を説明する。この新しい方法は
、ともにチャンネルをモニタリングして様々なチャンネル変更のプロフィルを格
納するレシーバおよびトランスミッタを含む。処理中に変更が検出されたら、レ
シーバおよびトランスミッタは、格納された同じプロフィル（１６プロフィルの
うちの１つ）に切り換えて動作を継続する。したがって、高速スワップコマンド
や他のコマンドがレシーバから送信されることはなく、このためより高速なスワ
ップが行われる。さらに具体的に言うと、レシーバおよびトランスミッタは、チ
ャンネルの性能をモニタリングして信号の適応化を制御するための回線モニタを
備えるように構成される。例えば、レシーバおよびトランスミッタが、上述した
ように回線モニタを備えても良い。レシーバおよびトランスミッタは、また、特
定の回線変更に対応する複数の所定プロフィルを格納するようにも構成されてい
る。したがって、モニタによってチャンネル内の変更が検出された場合、レシー
バおよびトランスミッタは、関連のデバイスに対し、所望の変更に最も良く一致
する所定のプロフィルを選択するように指示する。この方法では、レシーバおよ
びトランスミッタの両方が、所定のプロフィルで動作することができる。例えば
、所定のプロフィルに、マルチトーン信号の各トーンに対するビットおよびゲイ
ンの分布が含まれていても良い。

【０１１１】以上では、幾つかの実施形態を詳細に説明したが、本発明の趣旨および範囲か
ら逸脱しない範囲内で、他の多くの特定の形態で本発明を実現できることを、理
解する必要がある。本発明は、特に、離散マルチトーンシステムのための高速ス
ワッピングに関して説明されている。しかしながら、本発明が、他の様々なシス
テムにおいても使用可能であることを、理解する必要がある。例えば、サブチャ
ンネル（サブキャリアビットおよびゲイン）の動的な適応化を必要とするマルチ
チャンネルまたはマルチキャリアシステムが挙げられる。さらに、レシーバのモ
ニタリングは様々な方法で実現可能であり、本発明の範囲を逸脱しない範囲内で
大幅な変更が可能であると考えられる。したがって、上述した実施例は例示的で
あって限定的ではないと考えられ、本発明は、ここで挙げた詳細に限定されず、
添付した特許請求の範囲内で変更することが可能である。

【図面の簡単な説明】

【図１】Ｔ１．４１３ビットスワッピング要求のフォーマットを示す図である。

【図２】典型的なビットおよびゲインテーブルを示す図である。

【図３】本発明の一実施形態に従って、高速スワッピング要求のフォーマットを示す図
である。

【図４】本発明の一実施形態に従って、モデムのアーキテクチャを示す図である。

【図５】本発明の一実施形態に従って、レシーバを示す図である。

【図６ａ】４ビットアロケーションのトーンに対する典型的な出力コンステレーションを
示す図である。

【図６ｂ】６ビットアロケーションのトーンに対する典型的な出力コンステレーションを
示す図である。

【図７】高速スワッピングの改善因子対影響されたトーンの数をプロットしたグラフで
ある。

【符号の説明】

１２…メッセージヘッダ１４…メッセージ１６…メッセージフィールド１８…コマンド２０…トーンインデックス５０…ビットおよびゲインテーブル５２…トーンナンバフィールド５４…ビットアロケーションフィールド５６…ゲインまたはパワーレベルフィールド１００…高速スワッピングコマンド１０２…メッセージヘッダフィールド１０４…高速スワッピング制御フィールド１０６…トーンメッセージ１０８…エラーフィールド１１０…トーンインデックス１１２…所望値インジケータ２００…モデム２０２…トランスミッタ２０４…レシーバ２０６…エンコーダ２０８…変調器２１０…ウィンドウ操作フィルタ２１１…コントローラ２１２…アナログインタフェース２１４…アナログインタフェース２１６…タイムドメインイコライザ２１８…復調器２２０…デコーダ２２１…コントローラ２２２…リモートデバイス２２３…伝送メディア２２４…ビットおよびゲインテーブル２２６…ＡＤＳＬオーバヘッドチャンネル２２７…古いビット／ゲインテーブル２２８…新しいビット／ゲインテーブル３００…DMTレシーバ３０２…第１のデコーダ３０４…第２のデコーダ３０５…シンドロームジェネレータ３０６…シンドロームジェネレータ３０８…スイッチ４００…４ビットの布置５００…６ビットの布置

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号６０／１２３，０９６ (32)優先日平成11年３月５日(1999．3．5) (33)優先権主張国米国（ＵＳ） (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者ホー・ルイーズ・ミンチュインアメリカ合衆国カリフォルニア州94305 −9515 スタンフォード，スター・ラブ，パッカード 360 エムシー 9515 (72)発明者サルベカー・アチュルアメリカ合衆国カリフォルニア州94305 −9515 スタンフォード，スター・ラブ，パッカード 360 エムシー 9515 (72)発明者アルダナ・カルロスアメリカ合衆国カリフォルニア州94305 −9515 スタンフォード，スター・ラブ，パッカード 360 エムシー 9515 (72)発明者シオフィ・ジョン・エム．アメリカ合衆国カリフォルニア州94305 −9515 スタンフォード，スター・ラブ，パッカード 360 エムシー 9515 (72)発明者チャウ・ピーター・エス．アメリカ合衆国カリフォルニア州94022 ロス・アルトス，ウッドストック・レーン，750 (72)発明者カルロ・ジムアメリカ合衆国テキサス州75243 ダラス，ヘザーデイル・ドライブ，9208 Ｆターム(参考） 5K022 DD01 DD13 DD19 DD22 【要約の続き】リア識別子は、変更される特定のサブキャリアを識別し、各所望パラメータ値インジケータは、関連のサブキャリアの所望のパラメータ値を識別する。エラーフィールドによって、変更要求を受信するユニットは、変更要求コマンドの分析にエラーが存在するか否かを検出することが可能になる。

Claims

【特許請求の範囲】

【請求項１】マルチキャリア変調を使用した伝送システムにおいて通信信
号のパラメータを適応的に変更する方法であって、レシーバからトランスミッタへと変更要求を伝送する工程であって、前記変更
要求は、変更される特定のサブキャリアを識別し、前記識別されたサブキャリア
に関連付けられたパラメータの所望値を識別するように構成され、パラメータの
前記所望値は、前記パラメータのカレント値と異なる、工程と、前記受信された通信信号をモニタし、前記要求された変更が実現されたかを決
定する工程であって、前記要求された変更が実現されたか否かの決定は、前記受
信された通信信号のうち変更することを意図された一部分の分析に、少なくとも
部分的に基づく、工程とを備える方法。
【請求項２】請求項１記載の方法であって、前記変更要求は、変更される複数の特定のサブキャリアを識別し、識別された
各サブキャリアに対してそのサブキャリアに関連付けられたパラメータの所望値
を識別するように構成される、方法。
【請求項３】請求項１記載の方法であって、前記通信信号は、前記変更要求が受信または実現されたという明確な応答を何
ら含まない、方法。
【請求項４】請求項１記載の方法であって、前記モニタリングの工程は、前記パラメータの前記カレント値と前記パラメー
タの前記所望値とを使用して前記受信された通信信号をデコードし、前記要求さ
れた変更が少なくとも部分的に前記デコーディングに基づいて実現されたか否か
を決定することを含む、方法。
【請求項５】請求項４記載の方法であって、さらに、前記カレント値のデコードに基づく第１の前進型誤り訂正シンドロームと、前
記所望値のデコードに基づく第２の前進型誤り訂正シンドロームとを生成する工
程であって、前記変更要求が実現されたか否かの決定は、前記シンドロームの分
析に基づいて下される工程を、備える方法。
【請求項６】請求項１記載の方法であって、前記モニタリングの工程は、前記変更要求によって変更されることを意図され
た前記特定のサブキャリアをモニタし、前記要求された変更が実現されたか否か
を決定することを含む、方法。
【請求項７】請求項１記載の方法であって、前記要求された変更が実現されたか否かの決定は、前記パラメータの前記カレ
ント値および前記所望値を使用して前記通信信号をデコードすることに基づいて
検出されたエラーの分析に、少なくとも部分的に基づいて下される、方法。
【請求項８】請求項１記載の方法であって、前記モニタリングの工程は、第１の時点における前記サブキャリアの第１の布
置を、第２の時点における前記サブキャリアの第２の布置によって分析すること
を含み、前記変更の要求は、前記第２の布置が前記第１の布置と異なる場合に実現され
たことが知られる、方法。
【請求項９】請求項１記載の方法であって、前記モニタリングの工程は、前記通信信号のサブキャリアの１つをモニタし、
該サブキャリアが前記変更要求の実現に基づいて０に等しくなるように変更され
たことを含み、前記サブキャリア上における伝送エネルギの欠如は、前記要求された変更が前
記トランスミッタによって実現されたことを示す、方法。
【請求項１０】適応マルチキャリア伝送信号を使用し、１対のモデム間に
おける双方向の通信を促進するマルチキャリア通信システムにおいて、前記マル
チキャリア伝送信号内の特定のサブキャリアに関連付けられたパラメータ値にお
ける所望の変更を通信するように構成された変更要求コマンドであって、前記コマンドを変更要求コマンドとして識別するように構成されたヘッダと、前記変更要求コマンドによって変更されるトーンの数を示すように構成された
制御フィールドと、前記変更要求コマンドによって変更される特定のサブキャリアを識別するよう
にそれぞれが構成された、少なくとも１つのサブキャリア識別子と、関連のサブキャリア識別子によって識別されたサブキャリアに関連付けられた
パラメータの所望値を識別するようにそれぞれが構成された、少なくとも１つの
所望パラメータ値インジケータと、エラーフィールドとを備える、変更要求コマンド。
【請求項１１】請求項１０記載のコマンドであって、前記所望パラメータ値インジケータは、前記関連のサブキャリア識別子によっ
て識別された前記サブキャリアによって伝送される情報のビット数を識別する、
コマンド。
【請求項１２】請求項１１記載のコマンドであって、前記インジケータの前記所望値は、ある特定のサブキャリアに関して変更され
るビットの総数である、コマンド。
【請求項１３】請求項１０記載のコマンドであって、前記所望パラメータ値インジケータは、前記関連のサブキャリア識別子によっ
て識別された前記サブキャリアによって使用されるゲインを識別する、コマンド
。
【請求項１４】請求項１３記載のコマンドであって、前記インジケータの前記所望値は、約−４．０ｄＢ〜約＋３．５ｄＢの範囲で
約０．５ｄＢづつ増分する、コマンド。
【請求項１５】請求項１０記載のコマンドであって、前記エラーフィールドは巡回冗長検査コードを含む、コマンド。
【請求項１６】請求項１０記載のコマンドであって、前記ヘッダは、前記変更要求がいつ行われるかを示すスーパーフレームの番号
を含む、コマンド。
【請求項１７】請求項１０記載のコマンドであって、前記制御フィールドは、前記変更要求がいつ行われるかを示すスーパーフレー
ムの番号を含む、コマンド。
【請求項１８】マルチキャリア変調を使用した伝送システムにおいて通信
信号のパラメータを適応的に変更する方法であって、レシーバからの変更要求をトランスミッタにおいて受信する工程であって、前
記変更要求は、変更される特定のサブキャリアを識別し、前記識別されたサブキ
ャリアに関連付けられたパラメータの所望値を識別するように構成され、前記所
望値は、前記パラメータのカレント値と異なる、工程と、前記変更の要求を実現することによって、前記識別されたサブキャリアに関連
付けられた前記パラメータの前記所望値を再トレーニングするように前記識別さ
れたサブキャリアを変更する工程と、前記実現された変更要求を含み、明確な応答コマンドを含まない、マルチキャ
リア信号を伝送する工程とを備える、方法。
【請求項１９】請求項１８記載の方法であって、前記変更の要求は、前記変更の要求を識別するように構成されたヘッダを含む
、方法。
【請求項２０】請求項１８記載の方法であって、前記変更の要求は、前記変更要求によって変更されるサブキャリアの数を示す
ように構成されたサブキャリアカウントを含む、方法。
【請求項２１】請求項１８記載の方法であって、前記変更の要求は、前記変更要求によって変更される特定のサブキャリアを識
別するようにそれぞれが構成された、少なくとも１つのサブキャリア識別子を含
む、方法。
【請求項２２】請求項１８記載の方法であって、前記変更の要求は、関連のサブキャリア識別子によって識別されたサブキャリ
アに関連付けられたパラメータの所望値を識別するようにそれぞれが構成された
、少なくとも１つのインジケータを含む、方法。
【請求項２３】請求項１８記載の方法であって、前記変更の要求はエラーフィールドを含む、方法。
【請求項２４】請求項１８記載の方法であって、前記変更の要求は、前記変更要求がいつ行われるかを示すスーパーフレームの
番号を含む、方法。
【請求項２５】不連続マルチトーン伝送システムにおいて高速ビットスワ
ッピングを行う方法であって、レシーバから変更要求を伝送する工程であって、前記変更要求は、変更される
特定のトーンを識別し、前記識別されたトーンに関連付けられたパラメータの所
望値を識別するように構成され、前記所望値は、前記パラメータのカレント値と
異なる、工程と、トランスミッタにおいて前記変更要求を受信する工程であって、前記変更要求
は、変更されるべき特定のトーンを識別し、前記識別されたトーンに関連付けら
れたパラメータの所望値を識別するように構成され、前記所望値は、前記パラメ
ータのカレント値と異なる、工程と、前記変更の要求を前記トランスミッタにおいて実現することによって、前記識
別されたトーンに関連付けられた前記パラメータの前記所望値を再トレーニング
するように前記識別されたトーンを変更する工程と、前記実現された変更要求を含むマルチトーン信号を前記トランスミッタから伝
送する工程と、前記マルチトーン信号を前記レシーバにおいて受信する工程と、前記受信されたマルチトーン信号を、少なくとも前記パラメータの前記所望値
に基づいてインタープリットし、前記要求された変更が実現されたか否かを決定
する工程とを備える、方法。
【請求項２６】請求項２５記載の方法であって、前記変更要求は、実質的なトーン数に影響するように構成されている、方法。
【請求項２７】請求項２５記載の方法であって、前記マルチトーン信号は明確な応答コマンドを含まない、方法。
【請求項２８】トランスミッタと通信状態におる不連続マルチトーンモデ
ムであって、前記トランスミッタに変更要求を伝送するように構成されたレシーバであって
、前記変更要求は、変更される特定のトーンを識別し、前記識別されたトーンに
関連付けられたパラメータの所望値を識別するように構成され、前記レシーバは
、前記トランスミッタからマルチトーン信号を受信し、前記変更の要求が前記ト
ランスミッタによって実現されたか否かを決定するように構成され、前記変更の
要求が実現されたか否かの決定は、変更されることを意図された前記マルチトー
ン信号の一部分の分析に少なくとも部分的に基づいて下される、不連続マルチト
ーンモデム。
【請求項２９】請求項２８記載のモデムであって、前記変更の要求が実現されたか否かの決定は、前記変更の要求が実現されたと
いう前記トランスミッタからの明確な応答を含まない、モデム。
【請求項３０】請求項２８記載のモデムであって、前記パラメータの前記所望値は前記パラメータのカレント値と異なる、モデム
。
【請求項３１】請求項２８記載のモデムであって、前記レシーバは、受信された複数の第１のトーンと、受信された複数の第２の
トーンとを分析するように構成され、前記第１のトーンは、前記第１のトーンに
関連付けられたパラメータを含み、前記第２のトーンは、前記変更の要求に基づ
いて変更されたパラメータを含み、前記変更の要求は、前記トランスミッタにお
いて実現され、前記レシーバは、前記第１のトーンの前記パラメータを前記第２
のトーンの前記変更されたパラメータと比較することによって、前記第１のトー
ンが前記第２のトーンと異なるか否かを決定するように構成され、前記第１および第２のトーンの前記パラメータが実質的に同じである場合は、
前記変更は実現されず、前記第１および第２のトーンの前記パラメータが実質的
に同じでない場合は、前記変更は実現された、モデム。
【請求項３２】請求項２８記載のモデムであって、前記レシーバは、第１のデコーダと第２のデコーダとを備え、前記第１のデコ
ーダは、第１のトーンセットに関連付けられた複数の第１のパラメータ値を含み
、前記第２のデコーダは、第２のトーンセットに関連付けられた複数の第２のパ
ラメータ値を含み、前記第１のデコーダは第１のシンドロームジェネレータを備
え、前記第２のデコーダは第２のシンドロームジェネレータを備え、これらのシ
ンドロームジェネレータは、前記第１のシンドロームジェネレータに関連付けら
れた第１のシンドロームと、前記第２のシンドロームジェネレータに関連付けら
れた第２のシンドロームとを計算するように構成され、前記第１のシンドローム
は、受信された複数のトーンのパラメータの値を、前記第１のトーンセットに関
連付けられた前記第１のパラメータ値と比較するように構成され、前記第２のシ
ンドロームは、受信された複数のトーンのパラメータの値を、前記第２のトーン
セットに関連付けられた前記第２のパラメータ値と比較するように構成される、
モデム。
【請求項３３】請求項２８記載のモデムであって、前記レシーバは、前記通信信号のトーンの１つをモニタし、第１の時点におけ
る前記トーンの第１の布置を、第２の時点における前記トーンの第２の布置によ
って分析するように構成される、モデム。
【請求項３４】請求項２８記載の方法であって、前記レシーバは、前記通信信号のサブキャリアの１つをモニタし、該サブキャ
リアが前記変更要求の実現に基づいて０に等しくなるように変更されたモニタを
含む、方法。
【請求項３５】マルチキャリア信号を受信するように構成されたレシーバ
であって、様々なサブキャリアを有した受信されたマルチキャリア信号を復調するように
構成された復調器と、前記復調されたマルチキャリア信号を受信するように構成された１対の重複デ
コーダであって、前記様々なサブキャリアの少なくとも１つに関し、異なるパラ
メータを使用して前記復調されたマルチキャリア信号をデコードするように構成
された重複デコーダとを備える、レシーバ。
【請求項３６】請求項３５記載のレシーバであって、前記重複デコーダは同じサブキャリアをデコードするように構成される、レシ
ーバ。
【請求項３７】モデムであって、第１のルールセットと第２のルールセットとを有したレシーバであって、前記
第２のルールセットは前記第１のルールセットにおける変更に関連し、受信され
た信号を前記ルールの一方または両方と比較し、どのルールセットが前記受信信
号によって使用されているかを決定するように構成されているレシーバを備える
、モデム。