【手続補正書】
【提出日】平成19年5月15日(2007.5.15)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【書類名】          明細書
【発明の名称】    通信装置
【特許請求の範囲】
【請求項１】  メッセージを送受信することでハンドシェイク手順を実行する通信装置において、
ハンドシェイク手順で定められた第１のメッセージを受信し、この第１のメッセージを受信した後に第２のメッセージを送信し、さらにこの第２のメッセージを送信した後に第３のメッセージを受信し、その後受信が予定されるメッセージを正しく受信できなかったと判断した場合には、第３のメッセージが最終正常受信メッセージである旨を含む再送信要求メッセージを送信し、一方、ハンドシェイク手順で定められた第１のメッセージを送信し、この第１のメッセージを送信した後に第２のメッセージを受信し、さらにこの第２のメッセージを受信した後に第３のメッセージ及び第４のメッセージを送信し、その後第３のメッセージが最終正常受信メッセージである旨を含む再送信要求メッセージを受信した場合には、第４のメッセージを再度送信する制御手段、
を具備する通信装置。
【請求項２】  前記第１、２、３、４のメッセージは、各々、ＩＴＵ−Ｔ勧告Ｇ．９９４．１で規定されたＣＬＲメッセージ、ＣＬメッセージ、ＡＣＫメッセージ、ＭＳメッセージである、
請求項１記載の通信装置。
【請求項３】  メッセージを送受信することでハンドシェイク手順を実行する通信装置において、
ハンドシェイク手順で定められた第１のメッセージを受信し、この第１のメッセージを受信した後に第２のメッセージを送信し、その後受信が予定されるメッセージを正しく受信できなかったと判断した場合には、第１のメッセージが最終正常受信メッセージである旨を含む再送信要求メッセージを送信し、一方、ハンドシェイク手順で定められた第１のメッセージを送信し、この第１のメッセージを送信した後に第２のメッセージを受信し、さらにこの第２のメッセージを受信した後に第３のメッセージを送信し、その後第１のメッセージが最終正常受信メッセージである旨を含む再送信要求メッセージを受信した場合には、第３のメッセージを再度送信する制御手段、
を具備する通信装置。
【請求項４】  前記第１、２、３のメッセージは、各々、ＩＴＵ−Ｔ勧告Ｇ．９９４．１で規定されたＣＬＲメッセージの１つのセグメント、ＡＣＫメッセージ、ＣＬＲメッセージの続きのセグメントである、
請求項３記載の通信装置。
【請求項５】  メッセージを送受信することでハンドシェイク手順を実行する通信装置において、
ハンドシェイク手順で定められた第１のメッセージを送信し、この第１のメッセージを送信した後に第２のメッセージを受信し、さらにこの第２のメッセージを受信した後に第３のメッセージを送信し、その後受信が予定されるメッセージを正しく受信できなかったと判断した場合には、第２のメッセージが最終正常受信メッセージである旨を含む再送信要求メッセージを送信し、一方、ハンドシェイク手順で定められた第１のメッセージを受信し、この第１のメッセージを受信した後に第２のメッセージを送信し、さらにこの第２のメッセージを送信した後に第３のメッセージを受信し、この第３のメッセージを受信した後に第４のメッセージを送信し、その後第２のメッセージが最終正常受信メッセージである旨を含む再送信要求メッセージを受信した場合には、第４のメッセージを再度送信する制御手段、
を具備する通信装置。
【請求項６】  前記第１、２、３、４のメッセージは、各々、ＩＴＵ−Ｔ勧告Ｇ．９９４．１で規定されたＣＬＲメッセージの１つのセグメント、このセグメントに対するＡＣＫメッセージ、ＣＬＲメッセージの続きのセグメント、この続きのセグメントに対するＡＣＫメッセージである、
請求項５記載の通信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、これらに限定されないが、モデム、ケーブルモデム、ｘＤＳＬモデム、衛星通信システム、ポイント間ワイヤ、あるいは無線通信等の、ハンドシェイクプロトコルあるいは開始プロトコルを含む高速通信機器に関し、特に、誤りを検出し誤りの生じた（errored）通信メッセージの再送信を要求することにより、誤りのない通信を提供する装置及び方法に関する。
【０００２】
【従来の技術】
（定義）
以下の議論において使用される定義を下記に示す。
キャリアセット−特定のｘＤＳＬ勧告のＰＳＤマスクに関連する１つ以上の周波数のセット；
下り回線−ｘＴＵ−ＣからｘＴＵ−Ｒへの送信方向；
ガルフ−８１２６の値を持つオクテット、すなわちＨＤＬＣフラッグの補数；
開始信号−起動処理を開始する信号；
開始局−起動処理を開始するＤＴＥ、ＤＣＥ及び関連する端末装置
メッセージ−変調送信によって伝達されるフレーム化情報
メタルローカルループ−通信チャネル５、顧客家屋との局部ループを形成する金属ワイヤ；
対応信号−開始信号に対応して送信される信号；
対応局−リモート局からの通信トランザクションの開始に対応する局；
セッション−コンピュータ間又はアプリケーション間における始動から終了までの実際の通信接続；
信号−トーンに基づいて伝達される情報；
信号系統−与えられたキャリア間隔周波数の整数倍であるキャリアセットの群；
スプリッタ−メタルローカルループを二つの動作周波数帯に分離するためのハイパスフィルタとローパスフィルタの組み合わせ；
トランザクション−肯定受信通知メッセージ[ＡＣＫ(1)]、否定受信通知メッセージ[ＮＡＫ]あるいは時間切れで終了するメッセージシーケンス；
端末−局；及び
上り回線−ｘＴＵ−ＲからｘＴＵ−Ｃへの送信方向。
（略語）
以下の議論において使用される略語を下記に示す。
ＡＣＫ−受信通知メッセージ；
ＡＤＳＬ−非対称デジタル加入者回線；
ＣＤＳＬ−コンシューマデジタル加入者回線；
ＤＳＬ−デジタル加入者回線；
ＦＳＫ−デジタル周波数変調；
ＨＤＳＬ−高ビットレートデジタル加入者回線；
ＨＳＴＵ−Ｃ−ｘＤＳＬセントラル端末ユニット（ｘＴＵ−Ｃ）のハンドシェイク部分；
ＨＳＴＵ−Ｒ−ｘＤＳＬリモート端末ユニット（ｘＴＵ−Ｃ）のハンドシェイク部分；
ＩＴＵ−Ｔ−国際電気通信連合電気通信標準化セクター；
ＰＯＴＳ−従来の通常電話システム；
ＰＳＴＮ−公衆電話回線網；
ＲＡＤＳＬ−速度適応型ＤＳＬ；
ＲＴＸ−要求再送信；
ＶＤＳＬ−超高速デジタル加入者回線；
ｘＤＳＬ−いずれかのタイプのＤＳＬ；
ｘＴＵ−Ｃ−ｘＤＳＬのセントラル端末ユニット；及び
ｘＴＵ−Ｒ−ｘＤＳＬのリモート端末ユニット。
【０００３】
近年、従来の音声帯域（例えば４ｋＨｚ周波数帯域）を越える周波数スペクトラムを使用し、ローカルツイストペアにおいて、データを送信する新しい通信方法が提案あるいは開発されている。例えば、これらに限定されないが、ＤＳＬ、ＡＤＳＬ、ＶＤＳＬ、ＨＤＳＬ、ＳＨＤＳＬ及びＳＤＳＬ（これらは通常ｘＤＳＬと称される）等の各種性質（バリエーション）のデジタル加入者回線（ＤＳＬ）モデムが開発されあるいは開発中である。各特定のｘＤＳＬ技術においては、ロバストな起動技術あるいは開始技術が要求される。
【０００４】
国際電気通信連合（ＩＴＵ−Ｔ）はデータ通信を開始するいくつかの勧告手順を発行している。それらの主題は名称を参照し下記に含めておく。
（１）Ｖ.８勧告、「通常電話回線におけるデータ送信の起動セッション用手順」、1994年9月発行；
（２）Ｖ.８bis勧告、「通常電話回線におけるデータ回路端末機器間（ＤＣＥ）とデータ端末機器間（ＤＴＥ）の動作共通モードの識別及び選択用手順」、1996年8月発行；
（３）Ｇ.９９４.１勧告、「デジタル加入者回線（ＤＳＬ）送信機用ハンドシェイク手順」、1999年6月発行。これは1999年3月に発行された暫時文書MA-006の最終版である。
上記の文書（１）及び（２）は音声帯域回線でデータ通信を開始する手順に関する。上記の文書（３）ｘＤＳＬ回線でのデータ通信開始に関する。
【０００５】
【発明が解決しようとする課題】
メッセージにおいてデータ受信誤りが生じると、誤りが１ビット長であっても、残念ながらデータ通信装置はハンドシェイク（開始）プロトコルを最初から完全に再開しなければならない。開始プロトコルは複数のメッセージあるいは複数のトランザクションを含むことがあり、このようにして最初から送信を再開すると、情報及び時間に重大な損失が生じる。これにより、開始プロトコルを完全に再開することなく、セッションの誤りの生じた部分のみ再送し、開始回復手順を最小にする装置及び方法が必要とされる。
【０００６】
従って、本発明は、ハンドシェイクあるいは開始プロトコル中に生じた誤りメッセージを送信する再送信機構を開発することを目的とする。
【０００７】
【課題を解決するための手段】
開示された実施例において、その手順は、ｘＤＳＬハンドシェイク及び選択手順（これらに限定されないが、前述のG.994.1、V.8及びV.8bis等）の延長として実行される。本発明によれば、通信装置は、セッション中に誤りの生じたメッセージを受信すると、最後に正確に受信したメッセージを示し、誤りの生じたメッセージの再送信を要求する。尚、本発明の特徴によれば、誤りフレームの発生削減を促進するために、再送信要求メッセージを用いて、通信装置が使用するメッセージ長を示唆することも可能である。
【０００８】
本発明の目的に従って、誤りの生じたメッセージを通信ハンドシェイク手順の間に受信した際、信号とメッセージの再送信を最小にする通信装置が開示されている。この通信装置は、通信開始装置からの信号を受信し、誤りの生じたメッセージが受信信号において受信された旨を検出する受信部と、通信開始装置に、誤りの生じたメッセージを受信した旨を示す再送信要求メッセージを送信する再送信装置とを具備する。受信部は、誤りが生じたメッセージを検知するために動作する誤り検知装置を含む。
【０００９】
本発明の特徴に従って、再送信要求メッセージは、正確なメッセージが通信装置によって最後に受信されたか否かを示すものであり得る。さらに、再送信要求メッセージは、例えば、送信される次のメッセージフレームの提案された長さや、マルチセグメントメッセージのフレーム番号などに関連する情報を含んでも良い。
【００１０】
本発明のその他の目的に従って、誤りの生じたメッセージを通信セッションのハンドシェイク手順の間に受信した際、信号とメッセージの再送信を最小にする方法が開示されている。この方法によれば、ハンドシェイク手順は受信信号が誤りの生じたメッセージを含むか判定するために監視される。監視されたハンドシェイク手順が誤りの生じたメッセージを含むと判定されると、ハンドシェイク手順部分の再送信を要求する再送信要求メッセージが送信される。
【００１１】
本発明の利点に従って、フレームチェックシーケンスに関連するデータを検査することにより、誤りの生じたメッセージを受信したか判定する。
【００１２】
本発明の他の利点に従って、再送信要求メッセージは、例えば、最後に正確に受信されたメッセージや、マルチセグメントメッセージのセグメントインデックス番号を含んでも良く、また、受信したメッセージのタイプ（或いは長さを）を記録しても良い。更に、更に、前記最後に正確に受信されたメッセージのメッセージタイプの予め決められたセットから特定のメッセージを再送信要求メッセージに符号化しても良い。
【００１３】
本発明の特徴に従って、再送信要求メッセージは、例えば、最後に正確に受信されたメッセージのフレーム長に基づいた、次に送信される信号の提案されたフレーム長を示すことができる。
【００１４】
本発明の他の特徴に従って、誤りが生じたメッセージが予め決められた数（例えば３のような）になったときに通信セッションを停止しても良い。
【００１５】
本発明の他の目的は、高速ハンドシェイク手順の予め決められたフレーム構造に関連する受信データを監視すること、及び、監視された予め決められたフレーム構造が、前記受信信号が誤りの生じたメッセージを含む旨示している場合、再送信要求メッセージを送信することによって、誤りの生じたメッセージを通信セッションのハンドシェイク手順の間に受信した際信号とメッセージの再送信を最小にする方法に関連する。さらに、予め決められた数の誤りの生じたメッセージ（例えば３つの誤りの生じたメッセージ）が送信されたならば通信セッションを停止しても良い。
【００１６】
本発明のさらに他の目的は、誤りの生じたメッセージを通信セッションのｘＤＳＬネゴシエーション手順の間に受信した際、信号とメッセージの再送信を最小にする方法に関する。フレームチェックシーケンスに関連する受信データを監視する。フレームチェックシーケンスが受信信号が誤りの生じたメッセージを含む旨示している場合、再送信要求メッセージを送信する。このメッセージは、最後に受信された正確なメッセージはどれであるか示す情報を含む。誤りの生じたメッセージが予め決められた数（３など）になったならば通信セッションを停止する。さらに、再送信要求メッセージは、次に送信される信号のフレーム長を提案する情報を含んでも良い。提案されたフレーム長は、最後に正確に受信されたメッセージのフレーム長に基づくことができる。
【００１７】
【発明の実施の形態】
以下、本発明の好ましい一実施の形態を新しいメッセージタイプ、プロトコル、及び、限定はされないが例えば、ＩＴＵ−Ｔ勧告Ｇ.９９４.１で規定されるｘＤＳＬ起動方法等の起動機構関連トランザクションを関連させて説明する。以下、この新しいメッセージタイプを「再送信要求（ＲＴＸ）」と称する。
【００１８】
ここにおける説明はあくまでも例としてなされるものであり、本発明の実施の形態の実例となる検討を目的としたものである。また、本発明の原理及び概念的形態を、簡潔に理解しうる最も有用な記述において提供しようとするものである。この観点において、本発明の基本的理解に必要とされる構成を示し、より詳細な説明は省くが、本発明の実施形態を当業者に明らかとする図面を用いて、説明はなされる。
【００１９】
本発明によれば、通信装置は、セッション中に誤りの生じたメッセージ（例えば、少なくとも１ビットの誤りを含むメッセージ）を受信すると、誤りの生じたメッセージの再送信（ＲＴＸ）を要求し、そのメッセージを送信した通信装置に対し、最後に正しく受信したメッセージを示す。データ伝送において誤りを含んだフレームの発生を未然に削減することを促進するために、通信装置が使用するメッセージ長を、再送信要求メッセージで随意に示唆することも可能である。
【００２０】
本発明はここではＩＴＵ−Ｔ勧告Ｇ．９９４．１に対して説明されるが、本発明の精神又は範囲を逸脱しないかぎり、再送信要求を用いる機能手段及び方法手段は、限定はされないが前述のＩＴＵ−Ｔ勧告Ｖ.８あるいはＶ.８bis等の他のハンドシェイクプロトコルに適用可能である。
【００２１】
図１は、本発明のハンドシェイクプロトコルを詳細に行うデータ通信システムの一例を示す。図１に示されるように、このデータ通信システムは、通信チャネル５を介して接続されるセントラルオフィスシステム２とリモートシステム４を具備する。
【００２２】
セントラルオフィスシステム２は、自局と通信チャネル５とのインターフェースとして機能する主配信フレーム（ＭＤＦ: Main Distribution Frame)１を含む。主配信フレーム１は、例えば、一方を外部からの電話回線（例：通信チャネル５）に、他方を内部回線（例：内部セントラルオフィス回線）に接続するために動作する。
【００２３】
リモートシステム４は、自局と通信チャネル５とのインターフェースとして機能するネットワークインターフェース装置（ＮＩＤ: Network Interface Device）３を含む。顧客の機器と通信網（例：通信チャネル５）は、ネットワークインターフェース装置３を介してインターフェース接続される。
【００２４】
本発明の精神又は範囲を逸脱しないかぎり、本発明は他の通信装置に適用できることは明らかである。また、本発明はツイストペアワイヤを利用する電話通信システムに係り説明されているが、本発明の精神又は範囲を逸脱しないかぎり、他の伝送環境、限定されないが例えばケーブル通信システム（例：ケーブルモデム）、光通信システム、無線システム、赤外通信システム等に適用できることは明らかである。
【００２５】
図２は、図１のデータ通信システムの第一の形態の詳細なブロック図を示す。この形態は代表的な設置を表し、セントラルオフィスシステム２とリモートシステム４の両方が本発明を実施する。
【００２６】
図２に示されるように、セントラルオフィスシステム２は、ローパスフィルタ３４とハイパスフィルタ３８、テストネゴシエーションブロック４６、高速データ受信部６８、高速データ送信部７０及びコンピュータ８２を具備する。コンピュータ８２は、セントラルオフィスに設置されるネットワーク機器への一般的インタフェースとしてよい。テストネゴシエーションブロック４６は、実際の高速データ通信の開始前に行われる、すべてのネゴシエーション及び検査プロトコルを実行する。
【００２７】
ローパスフィルタ３４及びハイパスフィルタ３８は、通信チャネル５へ転送される通信信号のフィルタリングを行う。テストネゴシエーションブロック４６は、セントラルオフィスシステム２、リモートシステム４及び通信チャネル５の状況及び容量等のテスト及びネゴシエーションを行う。テストネゴシエーションブロック４６の手順は、事前に完了し、高速モデム送受信部（例：モデム）６８及び７０の選択を開始する。高速データ受信部６８は、リモートシステム４から送信された高速データを受信するよう機能し、一方、高速データ送信部７０は、リモートシステム４へ高速データを送信するよう機能する。高速部６８及び７０は、限定はされないが例えば、ＡＤＳＬ、ＨＤＳＬ、ＳＨＤＳＬ、ＶＤＳＬ及びＣＤＳＬ等のモデムを含む。高速部６８及び７０は、初期ネゴシエーション手順の間共通ブロック４６を共有する、複数の高速送信装置でもよい。ネゴシエーションデータ受信部５２及び高速データ受信部６８は、コンピュータ８２へ信号を送信する。ネゴシエーションデータ送信部５４及び高速データ送信部６８は、コンピュータ８２から送出された信号を受信する。
【００２８】
開示された本実施の形態において、テストネゴシエーションブロック４６は、ネゴシエーションデータ受信部（例：受信部）５２とネゴシエーションデータ送信部（例：再送信要求装置）５４とを具備する。ネゴシエーションデータ受信部
５２はネゴシエーションデータを受信し、一方ネゴシエーションデータ送信部５４はネゴシエーションデータを送信する。セントラルオフィスシステム２の各部の詳細な動作は、後述される。
【００２９】
リモートシステム４は、ローパスフィルタ３６とハイパスフィルタ４０、テストネゴシエーションブロック４８、高速データ受信部７２、高速データ送信部６６及びコンピュータ８４を具備する。コンピュータ８４は、リモートシステムに設置されるネットワーク機器への一般的インタフェースとしてよい。テストネゴシエーションブロック４８は、実際の高速データ通信の前に行われる、すべてのネゴシエーション及び検査プロトコルを実行する。
【００３０】
ローパスフィルタ３６及びハイパスフィルタ４０は、通信チャネル５へ転送される通信信号のフィルタリングを行う。テストネゴシエーションブロック４８は、セントラルオフィスシステム２、リモートシステム４及び通信チャネル５の状況及び容量等のテスト及びネゴシエーションを行う。高速データ受信部７２は、セントラルオフィスシステム２から送信された高速データを受信するよう機能し、一方、高速データ送信部６６は、セントラルオフィスシステム２高速データを送信するよう機能する。ネゴシエーションデータ受信部５６及び高速データ受信部７２は、コンピュータ８４へ信号を送信する。ネゴシエーションデータ送信部５０及び高速データ送信部６６は、コンピュータ８４から送出された信号を受信する。
【００３１】
開示された本実施の形態において、テストネゴシエーションブロック４８は、ネゴシエーションデータ受信部５６とネゴシエーションデータ送信部５０とを具備する。ネゴシエーションデータ受信５６はネゴシエーションデータを受信し、一方ネゴシエーションデータ送信部５０はネゴシエーションデータを送信する。リモートシステム４の各部の詳細な動作は、後述される。
【００３２】
リモートシステム４のネゴシエーションデータ送信部５０は、セントラルオフィスシステム２のネゴシエーションデータ受信部５２へ、上りネゴシエーションデータを送信する。セントラルオフィスシステム２のネゴシエーションデータ送信部５４は、リモートシステム４のネゴシエーションデータ受信部５６へ、下りネゴシエーションデータを送信する。
【００３３】
セントラルオフィスシステム２は、リモートシステム４の複数のチャネル２２、２６、２８、３０及び３２と通信するために使用される複数のチャネル６、１０、１４、１６及び１８を含む。これに関し、本実施の形態では、チャネル６は、ローパスフィルタ３４及び３６でフィルタされていた、従来の音声帯域（例：０Ｈｚから約４Ｈｚ）における、対応するリモート音声チャネル３２と直接に通信するセントラル音声チャネルを備える。また、リモート音声チャネル３３は、セントラルオフィスシステム２によって制御されないリモートシステム４に設けられる。リモート音声チャネル３３は、通信チャネル５と（ローパスフィルタ３６の前で）平行に接続され、これにより、リモート音声チャネル３２と同様のサービスを提供する。しかしながら、リモート音声チャネル３３はローパスフィルタ３６の前で接続されるので、高速データ信号と音声信号の両方を含む。
【００３４】
これらのフィルタは異なる周波数特徴を有するように設けることも可能であり、他の低域通信方法、例えばＩＳＤＮを用いて、音声チャネル６と３２の間で通信を行ってもよい。ハイパスフィルタ３８及び４０は、４ｋＨｚ以上の周波数スペクトラムを保証するよう選択される。他のシステムにおいては、フィルタ３４、３６、３８及び４０のいくつか（あるいは全部）は必要とされないし、設置されない。
【００３５】
ビットストリーム１０、１４、１６及び１８と（セントラルオフィスシステム２）ビットストリーム２２、２６、２８及び３０（リモートシステム４）は、それぞれコンピュータ８２あるいは８４と通信するために使用されるデジタルビットストリームを具備する。本発明の範囲において、ビットストリーム１０、１４、１６及び１８は離散信号（図示）で、インターフェースにバンドルされ、ケーブルで、あるいは一ストリームに多重化され、本発明の範囲及び機能を変更しないかぎり実施することが可能である。例えば、ビットストリーム１０、１４、１６及び１８は、（限定はされないが）ＲＳ−２３２、パラレル、ファイアワイヤ（IEEE-1394）、ＵＳＢ（Universal Serial Bus）、無線、あるいは赤外（ＩｒＤＡ）の標準に準ずるインターフェースとして構成することが可能である。同様に、ビットストリーム２２、２６、２８及び３０は、前述のように、（図示されている）離散信号で、インターフェースにバンドルされ、ケーブルで、あるいは一ストリームに多重化され実施することが可能である。
【００３６】
通信チャネルの状態（例：周波数特性、ノイズ特性、スプリッタの有無等）、機器の性能及びユーザとアプリケーションとの要求に応じたネゴシエーションデータ（例：制御情報）は、セントラルオフィスシステム２のネゴシエーションデータ受信部５２とネゴシエーションデータ送信部５４とリモートシステム４のネゴシエーションデータ受信部５６とネゴシエーションデータ送信部５０との間で交換される。
【００３７】
本発明のハードウエアに関する本質的特徴は、テストネゴシエーションブロック部４６及び４８の機能性にあり、これらは、セントラルオフィスシステム２、リモートシステム４及び通信チャネル５の状態と性能等とのテスト及びネゴシエーションを行う。特に、セントラルオフィスシステムとリモートシステム４の構成は多くの変形が考えられる。例えば、外部音声チャネル３３の構成は、セントラルオフィスシステム２を制御している構成要素によって制御されない。同様に、通信チャネル５の性能と構成も多くの変形が考えられる。本実施の形態において、テストネゴシエーションブロック４６及び４８は、それぞれモデム４２と４４とに埋め込まれている。しかしながら、テストネゴシエーションブロック４６及び４８の機能性は、モデム４２と４４とは別に独立して実行することが可能である。テストネゴシエーションブロック４６と４８との間で送受信される信号は、環境そのものをテストするとともに、セントラルオフィスシステムとリモートシステム４との間のテスト結果を通信するために使用される。
【００３８】
以下、図２における各信号パスの目的と、次に、信号を発生させるために用いる装置について説明する。また、各種周波数に対する具体的な値の例も、詳細に議論される。
【００３９】
本実施の形態において、セントラルオフィスシステム２とリモートシステム４との間の情報交換のための各種通信パスには、周波数分割多重（ＦＤＭ）が利用される。しかしながら、他の技術（限定はされないが例えば、ＣＤＭＡ、ＴＤＭＡ、スペクトル拡散等）も、本発明の精神及び範囲を逸脱しないかぎり利用可能である。
【００４０】
０Ｈｚから４ｋＨｚの周波数帯域は、ＰＳＴＮ音声帯域と称される典型的な領域である。いくつかの新しい通信方法は、典型的には、４ｋＨｚ以上の周波数スペクトラムをデータ通信に使おうというものである。典型的には、送信パワが許容される第一周波数は２５ｋＨｚあたりにある。しかしながら、どの周波数を使用してもよい。これに関して注目されるのは、周波数３４．５ｋＨｚにおけるトーンバーストは、Ｔ１Ｅ１  Ｔ１．４１３  ＡＤＳＬモデムを始動させるために使用されるということである。そのため、可能ならば、その周波数は先行ネゴシエーション方法に使用する周波数スペクトラムとしては避けるべきである。
【００４１】
通信パスは対で定義され、一つはリモートシステム４からセントラルオフィスシステム２への上り通信のためのパスであり、もう１つはセントラルオフィスシステム２からリモートシステム４への下り通信のためのパスである。ネゴシエーション上りビットは、リモートシステム４のネゴシエーションデータ送信部５０により送信され、セントラルオフィスシステム２のネゴシエーションデータ受信部５２により受信される。ネゴシエーション下りビットは、セントラルオフィスシステム２のネゴシエーションデータ送信部５４により送信され、リモートシステム４のネゴシエーションデータ受信部５６により受信される。ネゴシエーション及び高速トレーニングが一度完了すると、セントラルオフィスシステム２とリモートシステム４とは高速データ送信部６６及び７０と高速データ受信部７２及び６８とを使用しデュプレックス通信を行う。
【００４２】
本発明のすべてのメッセージは、例えば差分（バイナリ）デジタル位相変調を用いて、一つ以上のキャリアによって送出される。送信ビットが１ならば、送信点は過去の点から１８０度回転される。一方送信ビットが０ならば、送信点は過去の点から回転されない。各メッセージは、任意のキャリア位相における点に先行される。以下、キャリア周波数と、キャリアとメッセージの変調を開始する手順とを説明する。
【００４３】
本発明は、ハンドシェイク手順前も及びハンドシェイク手順が行われているときも、スペクトラム的に正しくかつ可能なかぎり突出しないよう、できうるかぎり尽力する。キャリアの代表的な選択は、下りパスと上りパスで異なるように、既存システムで発行されているトーンを避けるように、変調間製品に対して妥当なロバストになるように、十分な間隔となるよう等を考慮してなされる。４．３１２５ｋＨｚと４．０ｋＨｚをベース周波数として用いたキャリアトーンの適切な組み合わせを下記の表１に示す。
【表１】
2003500919.tif 000001
【００４４】
リモートシステム４は機器の性能とアプリケーション要求と回線制限とを解析した後、使用する通信方法の最終決定を行う。
【００４５】
セントラルオフィスシステム２が最終決定を受信した後、ネゴシエーション下りデータの送信は中止される。リモートシステム４が、セントラルオフィスシステム２からのエネルギ（キャリア）損失を検出すると、リモートシステム４はネゴシエーション上りデータの送信を中断する。しばらくの遅延の後、ネゴシエーション通信方法はその開始手順を始める。
【００４６】
セントラルオフィス又はリモートシステムの一つが高速通信セッションを開始すると、他方に受信させる信号を送信するが、この信号は予め決められた信号の送信に対応するものであり、例えばハンドシェイクセッションにおいて要求される信号等である。これらの信号は半二重あるいは全二重起動手順の一つを処理する。このような起動手順の例は、例えば、アメリカ出願No.０９/４７３，６８３(１９９９年１２月２９日出願)に記載されている。そこでの開示は、ここにすべて含まれる。しかしながら、本発明の精神あるいは範囲を逸脱しないかぎり、他の起動手順が使用可能であるのは明らかである。起動手順はハンドシェイクセッションに用いられる双方向通信チャネルを確立する。ハンドシェイクセッションの他の例としては、限定はされないが、ＩＴＵ−Ｔ勧告Ｖ.８、Ｖ.８bis、Ｇ.９９４.１（以前はＧ.ｈｓと称された）等がある。
【００４７】
ハンドシェイクセッションが開始されたのち停止される前に、一つ以上のトランザクションが使用され、ｘＴＵ−ＣとｘＴＵ−Ｒ間でデータを交換する。各トランザクションは、データ及び/あるいは要求を含む少なくとも一つのメッセージを有し、通知メッセージ（あるいは負の通知メッセージ）で完了する。
【００４８】
データは、限定はされないが例えば、機器の性能、回線容量、使用可能な動作モード、ユーザ要求、アプリケーション要求、サービス要求等を含む。要求は、限定はされないが例えば、要求された動作モード、要求されたデータ速度、要求されたプロトコルを含む。メッセージに対応するユニットは、（受信通知メッセージを用いて）受諾、（否定受信通知メッセージを用いて）拒否、あるいは要求メッセージを用いて、異なるタイプのメッセージの開始の要望を示す。対応に応じて、ユニットは他のトランザクションを開始するか、あるいはハンドシェイクセッションを停止することもできる。モード選択メッセージへの受信通知メッセージは、ハンドシェイクセッションを停止させ、既知の技術を用いモード選択メッセージにおける通信モード選択を開始させる。
【００４９】
以下の本発明の説明においては、メッセージは、下記の表２に示されるように、ＩＴＵ−Ｔ勧告Ｇ.９９４.１（前述）に基づくフレーム構造とする。二つのフレームチェックシーケンス（ＦＣＳ）オクテットは、メッセージが誤って受信されたかどうか判定するために用いられることに注意する。しかしながら、本発明の精神あるいは範囲を逸脱しないかぎり、他のフレーム構造も使用可能である。
【表２】
2003500919.tif 000002
【００５０】
メッセージの情報フィールド（表２に示す）の全構成要素を下記の表３に示す。これはＲＴＸメッセージを含む。
【表３】
2003500919.tif 000003
【００５１】
表４に、ＩＴＵ−Ｔ勧告Ｇ.９９４.１で規定される典型的なメッセージタイプを表にしたものであり、さらに、本発明の新しいＲＴＸメッセージのサポートを加えた。表５に、リビジョン番号がエンコードされたマナーを示す。このリビジョン番号について、ＲＴＸメッセージタイプがサポートされているか否かを決定するために検討した。特に、リビジョン番号を１以下にセットした場合、ＩＴＵ−Ｔ勧告Ｇ.９９４.１に対する（本発明の）メッセージ拡張はサポートされない。すなわち、誤りの生じたメッセージを受信した場合、先行技術のリカバリー技術（例えば、ＮＡＫ−ＥＦメッセージの送信、次いで、セッションのクリアダウン及び完全リスタート）を利用しなければならない。本発明のＲＴＸメッセージ及びその改良した再送信スキームを利用するためには、リビジョン番号は１よりも大きくしなければならない。
【表４】
2003500919.tif 000004
【表５】
2003500919.tif 000005
【００５２】
ＲＴＸメッセージは下記表６に示すフォーマットを有している。
【表６】
2003500919.tif 000006
【００５３】
上記表６中の各オクテットの詳細について以下説明する。
【００５４】
メッセージタイプオクテットは、表４に示すようなＲＴＸメッセージタイプの独特の番号を含んでいる。
【００５５】
リビジョン番号（Revision Number）オクテットは、現在送信されているトランザクションプロトコルのバージョン番号を示している。このオクテットは、新しいメッセージタイプであることを示すために１よりも大きくなければならない。上記表５では、エンコードする値を示す。
【００５６】
最終正常受信メッセージ（Last Correctly Received Message; ＬＣＲＭ）オクテットは、最終正常受信メッセージのメッセージタイプコードを含む。本実施の形態において、ＮＵＬＬメッセージコード（FF16）は、誤りなし（error free）メッセージがセッション内に届かなかった場合にＬＣＲＭオクテットに使用される。しかしながら、替わりのメッセージコードを、本発明の精神及び／又は範囲を逸脱しない限り利用可能である。
【００５７】
マルチセグメントフレーム番号（Multi-Segment Frame Number; ＭＳＦＮ）オクテットは、複数のフレームに分割されているメッセージのセグメントインデックス番号を含む。最初のセグメント（又は、１つのフレームに含まれるメッセージ）のＭＳＦＮ値は０である。フレームの中に含まれる2番目のセグメントのＭＳＦＮ値は１であり、以下同様である。セグメントフレームは明ら様には数えられていないけれども、ＨＳＴＵ−Ｒ及びＨＳＴＵ−Ｃ通信装置はそれぞれ内部カウンタを保持しておりＭＳＦＮ値のトラックを暗に管理している。
【００５８】
提案フレームサイズ（Suggested Frame Size）オクテットは、他方（例えば、ＳＦＳオクテットを含むＲＴＸメッセージがセントラルオフィス２により送信された場合のリモートシステム４、又は、ＳＦＳオクテットを含むＲＴＸメッセージがリモートシステム４により送信された場合のセントラルオフィスシステム２）に対して前記他方により送信されるサブシーケンスメッセージフレームの長さを提案する値を含む。このオクテットの値は次のようにエンコードされる。：
FF16  −  将来の使用のための予備
0016  −  提案されたフレームサイズの変更なし
00xx xxxx2    −  フレームサイズ
これらの上記の値は、この実施の形態により実施される例として提供されたものであると理解される。しかしながら、このような値は例としてのみ提供され、本発明の精神及び範囲を逸脱しない限り変更可能であると理解される。
【００５９】
本実施の形態において、ＲＴＸメッセージに含まれる（データ通信を初期化するための）ハンドシェイクトランザクションは、次の４つの最小限のルールを堅守しなければならない。
（１）ＨＳＴＵ−ｘは誤りを生じたメッセージを受信した場合、ＨＳＴＵ-ｘはＲＴＸメッセージを送信（送出）する。最終正常受信メッセージ（ＬＣＲＭ）フィールドは、最終正常受信メッセージのタイプを含む。マルチセグメントフレーム番号（ＭＳＦＮ）オクテット及び提案フレームサイズ（ＳＦＳ）オクテットは、上述の方法でエンコードされる。図３にトランザクションの例を示し、後述する。
（２）ＨＳＴＵ−ｘが誤りを生じたマルチセグメントメッセージを受信した場合、マルチセグメントフレーム番号（ＭＳＦＮ）フィールドは、メッセージセグメント番号を含む。先に説明したように、本実施の形態において、最初のセグメントのＭＳＦＮ値は０である。2番目のセグメントのＭＳＦＮ値は１であり、以下同様である。セグメントフレームは明ら様にフレームに番号を付けるフィールドを含んでいないが、ＨＳＴＵ−Ｒ（例えば、リモートシステム４）及びＨＳＴＵ−Ｃ（例えば、セントラルシステム２）は受信したフレームの番号の暗黙のカウンタを保持していなければならない。図４にトランザクションの例を示し、後述する。
（３）ＨＳＴＵ−ｘは、ハンドシェイクトランザクションの最中に誤りなしメッセージを受信しなかった場合、最終正常受信メッセージ（ＬＣＲＭ）オクテットは、ＮＵＬＬメッセージコードを含んでいなければならない。このようなセッションの例を図５に示し、後述する。
（４）ＨＳＴＵ−Ｃが、ＮＵＬＬにセットされた最終正常受信メッセージ（ＬＣＲＭ）を含むＲＴＸメッセージを受信した場合、ＨＳＴＵ−Ｃは、ＮＡＫ−ＣＤメッセージで応答し、セッションをクリアダウン（例えば、ハングアップ／終了）しなければならない。このようなセッションの例を図６に示し、後述する。
【００６０】
開示された好適な実施例には二つの追加ルールが含まれている。これらは、
（１）ＨＳＴＵ−ｘは、三つの連続したＲＴＸメッセージを受信すると、セッションをクリアダウン（例えば、ハングアップ／終了）するためにＮＡＫ−ＣＤを送信しなければならない、また、
（２）ＲＸＴメッセージは「承認」されない、というものである。したがって、トランザクションは、まるで誤りメッセージ（errored message）もＲＴＸメッセージも送信されていないように進行する。
【００６１】
図３から図１２に示すセッションの例に関して、矢印は受信に成功したメッセージを示し、「Ｘ」は誤りのある受信メッセージを示している。
【００６２】
注意すべきは、ＨＳＴＵ−Ｘは、ＲＴＸメッセージ受信前にメッセージで送信したビット列と全く同一のビット列を再送信する必要がないということである。誤りメッセージタイプは積極的には知り得ないので、受信ＨＳＴＵ−Ｘは、誤りフレームの内容についてどんな仮定をもするべきではない。送信ＨＳＴＵ−Ｘは、ＲＴＸについて知っている場合、提案フレームサイズ（ＳＦＳ）オクテットに従ってメッセージ長を短くすることを決めることができる。さらに、送信ＨＳＴＵ−Ｘは、通信チャネルに将来誤りが生じがちであることを知っている場合、内容（又はメッセージタイプ）を変更することを決めることができる。
【００６３】
上記の議論は、第１のメッセージが常にＨＳＴＵ−Ｒによって送信される実施例に対して提供されてきた。しかし、本発明は、第１のメッセージがＨＳＴＵ−Ｃによって送信される場合にも等しく適用可能である。したがって、第１のメッセージは、もちろん、本発明の精神及び／又は範囲から逸脱することなくＨＳＴＵ−Ｃによって送信可能である。
【００６４】
次いで、図３から図１２を参照して本発明の利用法を説明する。これに関して、以下の具体例は、もちろん、単に説明のために提供されるものであって、本発明の範囲を制限するものではない。
【００６５】
図３に示す例において、ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒによって送信されたＣＬＲメッセージを成功裡に受信する。次いで、ＨＳＴＵ−Ｒは、ＨＳＴＵ−ＣからのＣＬメッセージを受信する。その後、ＨＳＴＵ−Ｒは、ＡＣＫメッセージ、そしてＭＳメッセージをＨＳＴＵ−Ｒに送信する。ＨＳＴＵ−ＲはＭＳメッセージをＨＳＴＵ−Ｃに送信するけれども、ＨＳＴＵ−Ｃはメッセージを誤りなく受信しない。ＨＳＴＵ−Ｒからの最後に正しく受信したメッセージはＡＣＫメッセージであったので、ＨＳＴＵ−Ｃは、ＬＣＲＭフィールドがＡＣＫメッセージのコードにセットされているＲＴＸメッセージを準備する。ＨＳＴＵ−Ｒは、ＲＴＸメッセージを受信すると、ＡＣＫメッセージは正しく受信されたが、その後のデータ（例えば、ＭＳメッセージ）は正しく受信されなかったと決定する。その結果、ＨＳＴＵ−ＲはＭＳメッセージを送信する。図３には示されていないが、その後トランザクションは標準のトランザクションルールを用いて続行される。
【００６６】
図４は、ＨＳＴＵ−ＲによるマルチセグメントＣＬＲメッセージの送信を示している。ここで、各セグメントは、ＡＣＫ（２）メッセージによって承認される。第１のセグメントには暗黙のうちに０の番号が付され、第２のセグメントには暗黙のうちに１の番号が付され、以下同様である。ＨＳＴＵ−Ｒによって送信されたＣＬＲメッセージの第３セグメントは、どんな誤りもなくＨＳＴＵ−Ｃによって受信されることはない。したがって、ＨＳＴＵ−Ｃは、ＬＣＲＭがＣＬＲにセットされているＲＴＸメッセージを準備する。ＣＬＲメッセージはマルチセグメントメッセージであるため、ＭＳＦＮフィールドは、マルチセグメントメッセージの第２セグメントが正しく受信された最後のセグメントであったことを示すために１で符号化される（例えば、ＣＬＲ１）。ＨＳＴＵ−Ｒは、ＲＴＸメッセージを受信すると、第２セグメント（例えば、ＣＬＲ１）は誤りなく受信されたが第３セグメント（例えば、ＣＬＲ２）は受信されなかったと決定する。したがって、ＨＳＴＵ−Ｒは、ＣＬＲマルチセグメントメッセージの第３セグメント（例えば、ＣＬＲ２）を再送信する。図４には示されていないが、その後トランザクションは標準のトランザクションルールを用いて続行される。
【００６７】
図５は、ＨＳＴＵ−ＲがＨＳＴＵ−Ｃによって送信された第１メッセージを受信しない例を示している。トランザクションは、ＨＳＴＵ−ＣがＨＳＴＵ−Ｒによって送信されたＣＬＲメッセージを成功裡に受信することで開始される。次いで、ＨＳＴＵ−Ｃは、ＣＬメッセージをＨＳＴＵ−Ｒに送信する。しかし、ＣＬメッセージは、誤りなくＨＳＴＵ−Ｒによって受信されない。ＨＳＴＵ−Ｃからの最後に正しく受信されたメッセージは存在しないため、ＨＳＴＵ−Ｒは、ＬＣＲＭフィールドがＮＵＬＬのコードにセットされているＲＴＸメッセージを準備する。ＨＳＴＵ−Ｃは、正しく受信されたメッセージは存在しないと決定する。したがって、ＨＳＴＵ−Ｃは、第１のメッセージ（例えば、ＣＬメッセージ）を再送信する。図５には示されていないが、その後トランザクションは標準のトランザクションルールを用いて続行される。
【００６８】
図６に示す例では、通信チャネルは最初は誤りなしではない。ＨＳＴＵ−ＲはＣＬＲメッセージをＨＳＴＵ−Ｃに送信するが、ＨＳＴＵ−Ｃによって誤りなく受信されない。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒにこの誤りを、ＬＣＲＭにＮＵＬＬがセットされているＲＴＸメッセージを送信することによって通知する。しかし、例えば、通信チャネルに関する問題のため、このメッセージもまた誤りなしではない。その結果、ＲＴＸメッセージは、ＨＳＴＵ−Ｒによって正しく受信されない。したがって、ＨＳＴＵ−Ｒは、ＬＣＲＭがＮＵＬＬにセットされている自分自身のＲＴＸメッセージを準備する。このメッセージは、ＨＳＴＵ−Ｒがどんな誤りもなくＨＳＴＵ−Ｃからのメッセージを受信していないことを示している。この例では、回線状態が今や改善されており、ＲＴＸメッセージはＨＳＴＵ−Ｃによって誤りなく受信される。ＲＴＸメッセージはＮＵＬＬのＬＣＲＭメッセージを有するので、ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒからの誤りなしメッセージを受信していないことを示すそのＲＴＸメッセージ（例えば、図６に示す第１のＲＴＸ（ＮＵＬＬ））もまた誤りなく受信されなかったと決定する。したがって、ＨＳＴＵ−Ｃは、ＮＡＫ−ＣＤメッセージをＨＳＴＵ−Ｒに送信することによってセッションを終了する。
【００６９】
図７は、通信チャネルの品質がトランザクションの間で劣化し（この結果２つのメッセージを誤って受信し）、この通信チャネルの品質が改善された後、ハンドシェイキングセッションの間で誤りなくメッセージを受信することを可能とする一例を示している。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒにより送信されたＣＬＲメッセージを受信することに成功する。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒに対してＣＬメッセージを送信するが、ＨＳＴＵ−Ｒは、このＣＬメッセージを誤って受信する。ＨＳＴＵ−Ｒは、ＨＳＴＵ−Ｃから誤りなく受信したメッセージを有していないので、ＬＣＲＭ部分がＮＵＬＬに設定されたＲＴＸメッセージを用意する。チャネルの品質が劣化することが依然として問題となっているので、ＨＳＴＵ−Ｃは、誤りなくメッセージを受信することに再度失敗する。したがって、ＨＳＴＵ−Ｃは、ＬＣＲＭ部分がＣＬＲに設定されたＲＴＸメッセージを用意して送信する。この時点において、通信チャネルの品質が改善されているので、ＨＳＴＵ−Ｒは、上記ＲＴＸメッセージを受信し、このＨＳＴＵ−Ｒにより送信された上記ＲＴＸ（ＮＵＬＬ）メッセージが誤って受信されたことを認識し、ＬＣＲＭ部分がＮＵＬＬに設定されたＲＴＸメッセージを再送信する。ＨＳＴＵ−Ｃは、このＲＴＸメッセージを受信し、ＨＳＴＵ−Ｃにより送信された上記ＣＬメッセージが誤って受信されたことを認識し、このＣＬメッセージを再送信する。図７には示されていないが、この後のトランザクションは、標準的なトランザクション規則を用いて引き続き行われる。
【００７０】
図８は、通信チャネルの品質が上記トランザクションの間で劣化し（この結果３つのメッセージを誤って受信し）、この通信チャネルの品質が改善された後、上記ハンドシェイキングセッションの間で誤りなくメッセージを受信することを可能とする一例を示している。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒにより送信されたＣＬＲメッセージを受信することに成功する。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒに対して、ＣＬメッセージを送信するが、ＨＳＴＵ−Ｒは、このＣＬメッセージを誤って受信する。ＨＳＴＵ−Ｒは、ＨＳＴＵ−Ｃから誤りなく受信したメッセージを有していないので、ＬＣＲＭ部分がＮＵＬＬに設定されたＲＴＸメッセージを送信する。しかし、チャネルの品質が劣化することが依然として問題となっているので、ＨＳＴＵ−Ｃは、誤りなくメッセージを受信することに再度失敗する。したがって、ＨＳＴＵ−Ｃは、ＬＣＲＭ部分がＣＬＲに設定されたＲＴＸメッセージを用意して送信する。チャネルの品質が劣化することが依然として問題となっているので、ＨＳＴＵ−Ｒは、誤りなくメッセージを受信することに再度失敗する。再度、ＨＳＴＵ−Ｒは、一度もＨＳＴＵ−Ｃから誤りなくメッセージを受信できていないので、ＬＣＲＭ部分がＮＵＬＬに設定されたＲＴＸメッセージを用意する。この時点において、通信チャネルの品質が改善されているので、ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒから送信されたＲＴＸメッセージを受信し、このＨＳＴＵ−Ｃにより最初に送信されたＣＬメッセージが誤って受信されたことを認識し、ＣＬメッセージを再送信する。図８には示されていないが、この後のトランザクションは、標準的なトランザクション規則を用いて引き続き行われる。
【００７１】
図９は、本発明を利用しないＨＳＴＵ−Ｒと接続された、本発明を利用するＨＳＴＵ−Ｃによりなされるトランザクションの一例を示す。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒにより送信されたＣＬＲメッセージを受信することに成功する。この時点において、通信チャネルの品質は劣化しているので、ＨＳＴＵ−ＣによりＨＳＴＵ−Ｒに対して送信されたＣＬメッセージは、ＨＳＴＵ−Ｒにより誤って受信される。ＨＳＴＵ−Ｒは本発明を利用しないので、従来技術が用いられる。具体的には、ＨＳＴＵ−Ｒは、通信セッションの終了に引き続くＮＡＫ−ＥＦ（誤ったフレーム）を、用意して送信する。チャネルの品質が劣化することが引き続き問題となっているので、ＨＳＴＵ−Ｃは、誤りなくメッセージを受信することに再度失敗する。ＨＳＴＵ−Ｃ（上述したように、このＨＳＴＵ−Ｃは本発明を利用する）は、ＬＣＲＭ部分がＣＬＲに設定されたＲＴＸメッセージを用意して送信する。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒから応答を受けることに失敗するので、ＨＳＴＵ−Ｃは、タイムアウト期間が経過した後、通信を終了する。
【００７２】
図１０は、ＡＣＫメッセージが誤って受信されるトランザクションの一例を示す。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒにより送信されたＭＳメッセージを受信することに成功する。しかし、ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒに対してＡＣＫメッセージを送信するが、ＨＳＴＵ−Ｒは、このＡＣＫメッセージを誤って受信する。ＨＳＴＵ−Ｒは、ＨＳＴＵ−Ｃから誤りなく受信したメッセージを有していないので、ＬＣＲＭ部分がＮＵＬＬに設定されたＲＴＸメッセージを用意して応答する。ＨＳＴＵ−Ｃは、誤りなくメッセージを受信できていないことを認識するので、ＨＳＴＵ−Ｃは、ＡＣＫメッセージを再送信してトランザクションを完了させる。
【００７３】
図１１は、トランザクションの途中で２つの誤りが発生し、ＡＣＫがこの誤りのうちの１つのメッセージであるようなトランザクションの一例を示す。ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒにより送信されたＭＳメッセージを受信することに成功する。この後、ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒに対してＡＣＫメッセージを送信するが、通信チャンルの品質が劣化していることに起因して、ＨＳＴＵ−Ｒは、このメッセージを誤って受信する。ＨＳＴＵ−Ｒは、ＨＳＴＵ−Ｃにから誤りなく受信したメッセージを有していないので、ＬＣＲＭ部分がＮＵＬＬに設定されたＲＴＸメッセージを用意する。チャネルの品質が劣化することが引き続き問題となっているので、ＨＳＴＵ−Ｃは、メッセージを誤りなく受信することに失敗する。したがって、ＨＳＴＵ−Ｃは、ＬＣＲＭ部分がＭＳに設定されたＲＴＸメッセージを用意して送信する。この時点において、通信チャネルの品質が改善されているので、ＨＳＴＵ−Ｒは、ＨＳＴＵ−Ｃにより送信されたＲＴＸメッセージを受信し、このＨＳＴＵ−Ｒにより送信されたＲＴＸ（ＮＵＬＬ）メッセージが誤って受信されたことを認識し、ＬＣＲＭ部分がＮＵＬＬに設定されたＲＴＸメッセージを再送信する。ＨＳＴＵ−Ｃは、このＲＴＸメッセージを受信し、このＨＳＴＵ−Ｃにより送信されたＡＣＫメッセージが誤って受信されたことを認識し、ＡＣＫメッセージを再送信する。これによりトランザクションは完了する。
【００７４】
図１２は、複数の部分に分割されたメッセージに対するＡＣＫ（２）が誤って受信されるトランザクションの一例を示す。複数の部分に分割されたＣＬＲメッセージは、ＨＳＴＵ−Ｒにより送信され、各部分はＡＣＫ（２）メッセージにより認識される。第１部分には暗黙のうちに０が付され、第２部分には暗黙のうちに１が付され、以後同様に番号が付されている。ＨＳＴＵ−Ｃにより送信された第２ＡＣＫ（２）は、ＨＳＴＵ−Ｒにより誤って受信される。したがって、ＨＳＴＵ−Ｒは、ＬＣＲＭがＡＣＫ（２）に設定されたＲＴＸメッセージを用意する。ＡＣＫ（２）メッセージは、複数の部分に分割されたメッセージについての受信の認識を示すものであるので、複数の部分に分割されたメッセージのうちの第１ＡＣＫ（２）は、誤りなく受信された現時点で最も新しい部分であることを示すために、ＭＳＦＮ部分に０が付される（すなわちＡＣＫ（２）０となる）。
【００７５】
ＨＳＴＵ−Ｃは、ＨＳＴＵ−Ｒにより送信されたＲＴＸメッセージを受信した際には、第１部分（すなわちＡＣＫ（２）０）は誤りなく受信されたが第２ＡＣＫ（２）（すなわちＡＣＫ（２）１）は、誤って受信されたことを認識する。したがって、ＨＳＴＵ−Ｃは、第２ＡＣＫ（２）（すなわちＡＣＫ（２）１）を再送信する。この後、ＨＳＴＵ−Ｒは、ＣＬＲメッセージのうちの第３部分（すなわちＣＬＲ２）を送信して、トランザクションを継続させる。図１２には示されていないが、この後のトランザクションは、標準的なトランザクション規則を用いて行われる。
【００７６】
上述した議論は、単なる説明を目的としてなされたものであり、本発明を限定するものとして解釈されない。本発明は、模範的な実施例を参照して説明されているが、ここで用いられた用語は、限定のための用語ではなく、記述及び説明のための用語である、と理解するべきである。本発明の特徴において本発明の範囲及び思想から逸脱することなく、現時点で記載された添付クレーム及び補正された添付クレームの範囲内で、いかなる修正を加えることが可能である。本発明は、ここでは、特定の手段、材料及び実施例を参照して説明されているが、本発明は、ここで開示された個々の事項に限定されるものではない。すなわち、本発明の範囲は、添付クレームの範囲内にあるような、機能的に均等である構造物、方法及び用途のいかなるものをも含む。例えば、本発明は、ＩＴＵ−Ｔ勧告G.９４４.１で規定されたｘＤＳＬ手順を参照して説明されているが、本発明は、この手順での使用に限定されるものではなく、例えば、ＩＴＵ−Ｔ勧告Ｖ.８及びＶ.８bis.のようなその他の手順での使用にも同様に適用可能なものである。ここで説明された方法は、特定の集積回路、プログラマブル論理アレイ、及び、ここで記載された方法を実現するために構成されたその他のハードウェアデバイス等（に限定されない）を含む特定のハードウェアによる形態をも含む。しかし、本発明は、コンピュータにより実行されるソフトウェア（例えばソフトウェアモデム）で実現することが可能なものである。さらに、ここで記載された方法を実現するために、分配処理もしくは構成／オブジェクト分配処理、並列処理、又は、擬似機械処理等（に限定されない）を含む、その他のソフトウェアによる形態を用いることが可能である。なお、本明細書では、特定の規格及びプロトコルを参照して、実施の形態で実現される構成要素及び機能が記載されているが、本発明はこのような規格やプロトコルに限定されない。従来技術の代表例としては、インターネット及びその他のパケット切替ネットワーク伝送の規格（例えば、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ、ＨＴＭＬ、ＳＨＴＭＬ、ＤＨＴＭＬ、ＸＭＬ、ＰＰＰ、ＦＴＰ、ＳＭＴＰ、ＭＩＭＥ）、周辺制御（ＩｒＤＡ、ＲＳ２３２Ｃ、ＵＳＢ、ＩＳＡ、ＥｘＣＡ、ＰＣＭＣＩＡ）、及び、公衆電話網（ＩＳＤＮ、ＡＴＭ、ｘＤＳＬ）等が挙げられる。本質的に同一の機能を有するより高速かつより効率的な均等物が、定期的に、上述したような規格に取って代わって用いられる。
【００７７】
上記同一の機能を有する代替規格及び代替プロトコルは、均等物として考えることが可能である。
【００７８】
本明細書は、１９９９年５月２１日出願の米国仮出願６０／１３５，３０８及び５月２６日出願の米国仮出願６０／１３６，２３０に基づくものである。これらの開示内容はすべてここに含めておく。
【図面の簡単な説明】
【図１】
本発明の一実施例に係るモデム装置を使用するデータ通信システムのブロック図
【図２】
図１のデータ通信システムの詳細なブロック図
【図３】
ＨＳＴＵ−Ｒからのメッセージが誤りを含んでいるトランザクションの一例
【図４】
マルチセグメントメッセージの一フレームが誤りを含んでいるトランザクションの一例
【図５】
ＨＳＴＵ−Ｒからのメッセージが誤りを含んでいるトランザクションの一例
【図６】
多重誤りの生じた代表的トランザクションの一例
【図７】
トランザクションの中間で二つの誤りが生じたトランザクションの一例
【図８】
トランザクションの中間で三つの誤りが生じたトランザクションの一例
【図９】
本発明を利用するＨＳＴＵ−Ｃと本発明を利用しないＨＳＴＵ−Ｒが相互作用しているトランザクションの一例
【図１０】
誤りのないＡＣＫメッセージが受信されないトランザクションの一例
【図１１】
誤りの生じたメッセージのひとつとしてＡＣＫのトランザクションの中間で、二つの誤りが生じたトランザクションの一例
【図１２】
マルチセグメントメッセージ用ＡＣＫが誤った状態で受信されたトランザクションの一例
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2003500919.tif 000007
【図２】
2003500919.tif 000008
【図３】
2003500919.tif 000009
【図４】
2003500919.tif 000010
【図５】
2003500919.tif 000011
【図６】
2003500919.tif 000012
【図７】
2003500919.tif 000013
【図８】
2003500919.tif 000014
【図９】
2003500919.tif 000015
【図１０】
2003500919.tif 000016
【図１１】
2003500919.tif 000017
【図１２】
2003500919.tif 000018