特許 6377614 クロストーク環境におけるロバストハンドシェーク手順

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6377614

(24)【登録日】2018年8月3日

(45)【発行日】2018年8月22日

(54)【発明の名称】クロストーク環境におけるロバストハンドシェーク手順

(51)【国際特許分類】

   H04B 3/32 20060101AFI20180813BHJP

【ＦＩ】

   H04B3/32

【請求項の数】20

【全頁数】11

(21)【出願番号】特願2015-527628(P2015-527628)

(86)(22)【出願日】2013年8月15日

(65)【公表番号】特表2015-529414(P2015-529414A)

(43)【公表日】2015年10月5日

(86)【国際出願番号】US2013055089

(87)【国際公開番号】WO2014028705

(87)【国際公開日】20140220

【審査請求日】2016年5月24日

【審判番号】不服2017-4052(P2017-4052/J1)

【審判請求日】2017年3月21日

(31)【優先権主張番号】61/683,611

(32)【優先日】2012年8月15日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】506009350

【氏名又は名称】イカノス・コミュニケーションズ・インコーポレイテッド

【氏名又は名称原語表記】ＩＫＡＮＯＳ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ，ＩＮＣ．

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(72)【発明者】

【氏名】ラオ、ムルリ・モハン

【合議体】

【審判長】 中木 努

【審判官】 松永 稔

【審判官】 北岡 浩

(56)【参考文献】

【文献】 米国特許第７１８０９３６（ＵＳ，Ｂ１）

【文献】 米国特許第６９５２４４２（ＵＳ，Ｂ２）

【文献】 米国特許出願公開第２００９／０２７００３８（ＵＳ，Ａ１）

【文献】 特開２００７−０６７７６１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

IPC H04B 3/00-3/44, H04B 3/50-3/60, H04L 29/08

(57)【特許請求の範囲】

【請求項1】

方法において、
第１のトランシーバと第２のトランシーバとの間で、複数のハンドシェークメッセージを含むハンドシェークフェーズを開始することと、
前記第１のトランシーバにおいて、前記第１のトランシーバに一意的に関係付けられている一意的な識別子（ＩＤ）を発生させることと、
前記ハンドシェークメッセージのうちの１つを使用して、前記第１のトランシーバから前記第２のトランシーバに対して、前記第１のトランシーバに一意的に関係付けられている一意的なＩＤを送信することと、
前記第１のトランシーバにおいて、後続するハンドシェークメッセージを受信することと、
前記受信した後続するハンドシェークメッセージが、前記第１のトランシーバに一意的に関係付けられている一意的なＩＤを含まない場合に、前記第１のトランシーバにおいて、前記ハンドシェークフェーズを中止することとを含み、
前記第１のトランシーバに一意的に関係付けられている一意的なＩＤと前記第２のトランシーバに一意的に関係付けられている一意的なＩＤとは異なる方法。

【請求項2】

前記複数のハンドシェークメッセージのうちの少なくとも１つは、Ｇ．９９４．１ハンドシェーク（ｇ．ｈｓ）メッセージを含む請求項１記載の方法。

【請求項3】

前記複数のハンドシェークメッセージのうちの少なくとも１つは、モード要求／能力リストおよび要求（ＭＲ／ＣＬＲ）ｇ．ｈｓメッセージを含む請求項２記載の方法。

【請求項4】

前記複数のハンドシェークメッセージのうちの少なくとも１つは、モード選択／能力リスト（ＭＳ／ＣＬ）ｇ．ｈｓメッセージを含む請求項２記載の方法。

【請求項5】

前記受信した後続するハンドシェークメッセージは、ＭＳ／ＣＬｇ．ｈｓメッセージを含む請求項２記載の方法。

【請求項6】

前記受信した後続するハンドシェークメッセージは、肯定応答（ＡＣＫ）ｇ．ｈｓメッセージを含む請求項２記載の方法。

【請求項7】

前記１つのハンドシェークメッセージは、前記一意的なＩＤに対するフィールドを含む請求項１記載の方法。

【請求項8】

前記一意的なＩＤは、１６ビット数を含む請求項１記載の方法。

【請求項9】

前記一意的なＩＤを発生させることは、乱数を発生させることを含む請求項１記載の方法。

【請求項10】

前記第２のトランシーバにおいて、前記第２のトランシーバに関係付けられている第２の一意的なＩＤを発生させることと、
前記ハンドシェークメッセージのうちの別の１つを使用して、前記第２のトランシーバから前記第１のトランシーバに対して、前記第２の一意的なＩＤを送信することと、
前記第２のトランシーバにおいて、後続するハンドシェークメッセージを受信することと、
前記受信した後続するハンドシェークメッセージが前記第２の一意的なＩＤを含まない場合に、前記第２のトランシーバにおいて、前記ハンドシェークフェーズを中止することとをさらに含む請求項１記載の方法。

【請求項11】

前記ハンドシェークフェーズが中止されなかった場合に、Ｇ．ベクトル初期化のＯ−シグニチャフェーズに進行することと、
前記Ｏ−シグニチャフェーズの間に、前記第１のトランシーバから前記第２のトランシーバに対して、前記第１のトランシーバに関係付けられている一意的なＩＤを送信することと、
前記Ｏ−シグニチャフェーズの間に送信された一意的なＩＤが、前記ハンドシェークフェーズの間に送信された一意的なＩＤに一致しない場合に、前記第２のトランシーバにおいて、前記Ｏ−シグニチャフェーズを中止することとをさらに含む請求項１記載の方法。

【請求項12】

通信デバイスにおいて、
プロセッサと、
前記プロセッサと電子通信するメモリと、
前記メモリ中に記憶されている命令とを具備し、
前記命令は、前記通信デバイスに、
複数のハンドシェークメッセージを含む、遠隔トランシーバとのハンドシェークフェーズを開始させ、
前記通信デバイスに一意的に関係付けられている一意的な識別子（ＩＤ）を発生させ、
前記ハンドシェークメッセージのうちの１つを使用させて、前記通信デバイスに一意的に関係付けられている一意的なＩＤを、前記遠隔トランシーバに対して送信させ、
後続するハンドシェークメッセージを受信させ、
少なくとも１つの前記受信させた後続するハンドシェークメッセージが、前記通信デバイスに一意的に関係付けられている一意的なＩＤを含まない場合に、前記ハンドシェークフェーズを中止させるように前記プロセッサによって実行可能であり、
前記通信デバイスに一意的に関係付けられている一意的なＩＤと前記遠隔トランシーバに一意的に関係付けられている一意的なＩＤとは異なる通信デバイス。

【請求項13】

前記複数のハンドシェークメッセージのうちの少なくとも１つは、Ｇ．９９４．１ハンドシェーク（ｇ．ｈｓ）メッセージを含む請求項１２記載の通信デバイス。

【請求項14】

前記複数のハンドシェークメッセージのうちの少なくとも１つは、モード要求／能力リストおよび要求（ＭＲ／ＣＬＲ）ｇ．ｈｓメッセージを含む請求項１３記載の通信デバイス。

【請求項15】

前記複数のハンドシェークメッセージのうちの少なくとも１つは、モード選択／能力リスト（ＭＳ／ＣＬ）ｇ．ｈｓメッセージを含む請求項１３記載の通信デバイス。

【請求項16】

前記受信させた後続するハンドシェークメッセージは、ＭＳ／ＣＬｇ．ｈｓメッセージを含む請求項１３記載の通信デバイス。

【請求項17】

前記受信させた後続するハンドシェークメッセージは、肯定応答（ＡＣＫ）ｇ．ｈｓメッセージを含む請求項１３記載の通信デバイス。

【請求項18】

前記１つのハンドシェークメッセージは、前記一意的なＩＤに対するフィールドを含む請求項１２記載の通信デバイス。

【請求項19】

前記一意的なＩＤを発生させることは、乱数を発生させることを含む請求項１２記載の通信デバイス。

【請求項20】

前記命令はさらに、前記プロセッサに、
前記ハンドシェークフェーズが中止されなかった場合に、Ｇ．ベクトル初期化のＯ−シグニチャフェーズに進行させ、
前記Ｏ−シグニチャフェーズの間に、前記一意的なＩＤを、前記遠隔トランシーバに対して送信させ、
前記Ｏ−シグニチャフェーズの間に送信された一意的なＩＤが、前記ハンドシェークフェーズの間に送信された一意的なＩＤに一致しない場合に、前記Ｏ−シグニチャフェーズの前記遠隔トランシーバにおける中止の表示を受信させる請求項１２記載の通信デバイス。

【発明の詳細な説明】

【関連出願に対する相互参照】

【0001】

［０００１］
本出願は、２０１２年８月１５日に出願された米国仮出願番号６１／６８３，６１１号に対して優先権を主張する。その仮出願の内容は、その全体が参照によってここに組み込まれている。

【発明の分野】

【0002】

［０００２］
本発明は概して通信に関連しており、さらに詳細には、ｘＤＳＬ通信システムにおけるトランシーバのトレーニングに関連している。

【発明の背景】

【0003】

［０００３］
ＤＳＬトランシーバが能力情報を交換して共通の動作モードを選択するための柔軟なメカニズムをＧ．９９４．１は提供する。しかしながら、１つの接続がクロストークチャネルを介している高クロストーク環境において、１つの遠隔トランシーバに対して２つ以上のトランシーバがトレーニングアップするのを防ぐ能力をＧ．９９４．１は欠いている。

【0004】

［０００４］
例えば、非常に多くの場合、１つのトランシーバが遠隔トランシーバに対してダイレクトチャネル上でトレーニングアップする一方で、別のトランシーバが同一の遠隔トランシーバに対してＦＥＸＴチャネル上でトレーニングアップする。このＦＥＸＴチャネルトランシーバは非常に多くの場合、アクティブ化に失敗する前に、ハンドシェークや、チャネル発見のいくつかのフェーズを通過する。この誤ったトレーニングは、ベクトル化ＶＤＳＬ２（Ｇ．ベクトル）システムに対して非常に問題であることがあり、また、他のラインに再トレーニングさせることもある。

【0005】

［０００５］
例えば、ベクトル化ＶＤＳＬ２において、ハンドシェークセッションの後に、１つのＶＴＵ−Ｏ（すなわち、中央オフィス（ＣＯ）ベースのＶＤＳＬ２モデム）が２つのＶＴＵ−Ｒ（すなわち、カスタマー構内位置ベースのモデム（ＣＰＥ））との接続を同時に確立することが観測されている。この事象において、例として、ラインのＣＰＥ側における２つのモデムがこのラインのＣＯ側における単一のモデムと初期化しようとする可能性がある。通常の動作条件、特にベクトリングなしのＶＤＳＬ動作の下では、ダイレクトチャネル上のＣＰＥモデムは初期化のトレーニングフェーズの間に（望ましくは）著しくより良好なＳＮＲを観測し、クロストークチャネルを通したＣＰＥモデムはかなり悪いＳＮＲを観測してやがては初期化を中止するであろう。しかしながら、この事象がベクトル化ＶＤＳＬ２システムにおいて生じる場合、新たなラインが加わろうとして、クロストークパスを介した第２のラインもまたベクトル化グループに加わろうとしているときに、チャネル行列の更新においていくつかの問題が生じることがある。これは図１において説明している状況である。

【0006】

［０００６］
図１において示されているように、ショータイムにおいて、ベクトル化グループ１０２において動作する（ＣＯ側ＤＳＬＡＭ１１０中のＶＴＵ−Ｏ＃１からＶＴＵ−Ｏ＃３によって表される）多数のラインが存在し、ベクトル化グループ内のクロストークは、ＣＯ中のＶＣＥによって消去されている。さらに示されているように、ＣＰＥモデムＶＴＵ−Ｒ＃Ｊ１ １０６に関係付けられているライン＃Ｊ１は、ベクトル化グループ１０２に加わることを望む。しかしながら、ハンドシェークの間に、ＶＴＵ−Ｏ＃Ｊ１と通信している２つのＣＰＥモデム、所望のＶＴＵ−Ｒ＃Ｊ１ １０６と、クロストーク結合パスを介した別のモデムＶＴＵ−Ｒ＃Ｊ１Ｆ １０４とが存在する。ハンドシェークの間、両方のＣＰＥデバイスがＶＴＵ−Ｏ＃Ｊ１との通信を確立して初期化フェーズに入ることが可能である。チャネル発見フェーズの間に、ダウンストリーム方向においてＯ−シグニチャメッセージを介してパイロットシーケンスが通信され、アップストリームベクトリングがイネーブルされる場合、トレーニングシーケンスＲ−Ｐ−ベクトル１中で、アップストリーム方向において、アップストリームチャネルに対するパイロットシーケンスが適用のためにＣＰＥに通信されるであろう。このケースでは、２つのＣＰＥモデムがチャネル発見の間に、Ｒ−Ｐ−ベクトル１中で同一のパイロットシーケンスアップストリームを送信しているであろう。アップストリーム方向でのクロストークチャネル行列の更新において、２つのモデムが同一のパイロットシーケンスを送信しているという事実は混同を生じさせることがある。トレーニングフェーズになって初めてＳＮＲ測定が行われ、悪いＳＮＲ読取が原因で１つのラインが切断されることがあるが、このときまで、アップストリームクロストークチャネル行列に対して、何らかの潜在的な害が与えられているかもしれない。

【0007】

［０００７］
たとえダイレクトチャネルとは逆にクロストークチャネルを介して接続が確立されるとしても、ハンドシェークから外れた後の接続がただ１つのモデムペアによって行われ、１つより多くのラインにわたって１つのパイロットシーケンスが適用されるのを回避することが、強く望まれる。

【発明の概要】

【0008】

［０００８］
本発明の実施形態は、ＦＥＸＴチャネル上でトレーニングしようと試行するトランシーバをハンドシェークフェーズの間に分離して誤ったアクティブ化を中止するための、ロバストなメカニズムを提供する。本発明の態様にしたがうと、ハンドシェークフェーズの間に、いずれかまたは両方のトランシーバがもう一方のトランシーバの一意的な識別子に肯定応答する。このことによって、確実に、トレーニングおよびそれ以降もただ１つの他の遠隔トランシーバとともにトランシーバは進行する。ある追加の態様にしたがうと、１つの遠隔トランシーバに対して複数のトランシーバがアクティブ化しようとするという長年の問題をこのプロトコルは取り扱う。Ｇ．ベクトルシステムに関して、このことはある利点を提供することができる。現在、このようなプロトコルなしでは、両方のトランシーバがチャネル発見／トレーニングに進行するかもしれず、実際のおよびクロストークのチャネルトランシーバからのＦＥＸＴ寄与が識別できなくなる。このことは、準最適性能：より低いＳＮＲ、ＣＲＣ、およびライン再トレーニングへとつながるかもしれない。本発明は、とりわけこの問題を取り扱う。

【0009】

［０００９］
これらのおよび他の態様にしたがうと、本発明の実施形態にしたがったＦＥＸＴチャネル上でトレーニングするトランシーバを識別するための方法は、第１のトランシーバと第２のトランシーバとの間での複数のハンドシェークメッセージを含むハンドシェークフェーズを開始することと、第１のトランシーバにおいて一意的なＩＤを発生させることと、ハンドシェークメッセージのうちの１つを使用して、第１のトランシーバから第２のトランシーバに一意的なＩＤを送信することと、ハンドシェークメッセージのうちの、ＩＤ値を含む異なる１つを受信することと、受信したＩＤ値が一意的なＩＤと一致しない場合に、ハンドシェークフェーズを中止することとを含んでいる。最終の確認のために、Ｏ−シグニチャメッセージの間にも、一意的なチャネルを通してＩＤを通信してもよい。

【図面の簡単な説明】

【0010】

［００１０］
本発明の特定の実施形態の以下の記述を、付随する図面とともにレビューするとき、本発明のこれらの態様および特徴、ならびに、他の態様および特徴が、当業者に明白となろう。

【図1】［００１１］ 図１は、既存のＶＤＳＬシステムにおけるいくつかの問題を図示しているダイヤグラムである。

【図2】［００１２］ 図２は、本発明の実施形態にしたがった、ハンドシェーク手順のための例示的な方法を図示しているフローチャートである。

【図3】［００１３］ 図３は、本発明の実施形態にしたがった、ハンドシェーク手順の例示的なインプリメンテーションを図示しているダイヤグラムである。

【好ましい実施形態の詳細な説明】

【0011】

［００１４］
当業者が発明を実施できるように、発明の実例となる例として提供している図面を参照して、本発明をここで詳細に説明する。特に、以下の図面および例は本発明の範囲を単一の実施形態に限定することを意味しているのではなく、説明または図示した要素のうちのいくつかまたはすべての交換によって他の実施形態が可能である。さらに、本発明のある要素を既知のコンポーネントを使用して部分的にまたは完全に実現できる場合、このような既知のコンポーネントのうちの、本発明の理解のために必要である部分のみを説明し、発明を曖昧にしないように、このような既知のコンポーネントのうちの他の部分の詳細な説明は省略する。ソフトウェア中で実現するとして説明する実施形態はそれに限定すべきではなく、ここでそうでないと特定しない限りは、当業者に明白となるようにハードウェア中、またはソフトウェアとハードウェアとの組み合わせで実現する実施形態も含むことができ、逆もまた同じである。本明細書において、単数のコンポーネントを示す実施形態は限定的であると見なされるべきでなく、むしろ、ここでそうでないと明示的に示さない限りは、複数の同一のコンポーネントを含む他の実施形態を発明が含んでいるように意図しており、逆もまた同じである。さらに、明示的にそうであるとして述べていない限り、明細書または特許請求の範囲中の任意の用語が一般的でない意味または特別な意味に帰するようには出願人は意図していない。さらに、ここで実例として言及している既知のコンポーネントに対する現在および将来の既知の均等物を本発明は含んでいる。

【0012】

［００１５］
ある態様にしたがうと、１つのトランシーバが一意的に遠隔トランシーバを識別することを可能にするロバストなプロトコルを本発明は提供する。このことによって、確実に、トレーニングおよびそれ以降もただ１つの他の遠隔トランシーバとともにトランシーバは進行する。したがって、例えば、トランシーバの識別子が予期した識別子と一致しないとき、最終的にクロストークチャネルを介してアクティブ化することになる任意のトランシーバを、ハンドシェーク初期に検出することができる。

【0013】

［００１６］
図２は、本発明の実施形態にしたがった、例示的な方法論を図示しているフローチャートである。

【0014】

［００１７］
図２の例において、ラインがベクトル化グループに加わることを要求する（ステップＳ２０２）ときに、プロセスは開始する。例えば、ＣＰＥモデムを電源投入または再始動するときのように、新たなＣＰＥモデムがオンラインになった後に、このことは生じうる。

【0015】

［００１８］
Ｇ．９９３．２の、標準化されたベクトル化ＤＳＬプロトコルにしたがうと、新たなラインがベクトル化グループに加わることを要求するプロセスのかなり初期に、Ｇ．９９４．１によって特定されるようなハンドシェーク手順が開始される（ステップＳ２０４）。例えば、ＣＰＥモデムと同一のラインにアタッチされているＣＯモデムによって、このハンドシェーク手順が開始される。

【0016】

［００１９］
本発明の態様にしたがうと、ステップＳ２０６において示されているステップのような追加のステップによって、従来のハンドシェーク手順を補足する。ハンドシェークの間に、ＣＯ側モデムとＣＰＥ側モデム（すなわち、ｘＴＵ−ＲまたはｘＴＵ−Ｃ）のうちの１つまたは両方が、一意的なＩＤを発生させてもう一方のモデムに送信する。実施形態において、一意的なＩＤは、例えば擬似乱数発生器によって発生される１６ビット（すなわち、２バイト）数であってもよい。しかしながら、何らかの特定の長さ、または、何らかの特定の発生技術に、本発明が制限されるものではない。好ましくは、ＩＤ発生技術および長さは、特定の時間フレームおよび環境において誤った重複のかなり低い可能性をもたらすべきであり、これは当業者によって決定および確立することができる。

【0017】

［００２０］
次に、ステップＳ２０８において、後続するハンドシェークメッセージをモデムは交換する。ステップＳ２１０において、もう一方のモデムによるそれらのＩＤの肯定応答を後続するハンドシェークメッセージが含んでいるか否かを、一意的なＩＤを送信したモデムが決定する。言い換えれば、それらの一意的なＩＤをもう一方のモデムに送信した後に、モデムによって送信したのと同一の一意的なＩＤを、もう一方のモデムからの後続するハンドシェークメッセージが含むべきである（すなわち、もう一方のモデムによって一意的なＩＤが肯定応答される）。

【0018】

［００２１］
ステップＳ２０６において一意的なＩＤを送信したモデムが、送信したＩＤの肯定応答を受信しない場合、または、送信したＩＤと同一でないＩＤを後続するメッセージが含んでいる場合、ステップＳ２１４において、送信モデムによってハンドシェークシーケンスは中止される。そうでないならば、正常として完了されるまでハンドシェーク手順は継続し、その後、トレーニングのような後続する手順が始められる。

【0019】

［００２２］
図３は、本発明の実施形態にしたがった、ロバストなハンドシェーク手順の例示的なインプリメンテーションを図示している。

【0020】

［００２３］
図３に示されているように、トランシーバＸＴＵ−Ｃ−１およびトランシーバＸＴＵ−Ｒ−１によって終端するライン、または、トランシーバＸＴＵ−Ｃ−２およびトランシーバＸＴＵ−Ｒ−２によって終端するラインのいずれかが、有効なハンドシェーク手順を開始しようと試行しているのに対して、もう一方のラインの任意のトランシーバがクロストークチャネルを介して傍受しようと試行している。

【0021】

［００２４］
この例においては、Ｇ．９９４．１の既存のｇ．ｈｓメッセージに新たなフィールドを追加することによって、本発明のハンドシェーク手順は実現される。１つの例示的な実施形態では、図３において示されているように、ハンドシェークの間に以下の手順が追加され、アップストリームおよびダウンストリームの両方において遠隔トランシーバの曖昧性を除去している。

【表1】

【0022】

［００２５］
１つの例において、ｘｔｕｒ＿ｉｄおよびｘｔｕｃ＿ｉｄは１６ビット乱数である。しかしながら、この例は限定的ではない。

【0023】

［００２６］
図３において示しているように、上記のメカニズムを使用して、クロストークチャネルを介して‘傍受’しているｘＴＵ−ＲまたはｘＴＵ−Ｃトランシーバのいずれかが、遠隔トランシーバが他の誰かと話していることを初期に認識することができ、ラインアクティブ化を中止することができる。特に、図３の例では、本発明にしたがってクロストークチャネルを介してｘＴＵ−Ｒ−１から受信したｇ．ｈｓＡＣＫメッセージ中のｘｔｕｃ＿ｉｄ値が、ｘ−ＴＵ−Ｃ−２自身の一意的なｘｔｕｃ＿ｉｄ値に一致しない場合に、ｘ−ＴＵ−Ｃ−２はハンドシェーク手順を中止できる。

【0024】

［００２７］
上記の実施形態の任意のものにおいて付加的または代替的に、アップストリームパイロットシーケンスを送信するより前に、一意的な通信リンクの付加的または最終の検証のために、Ｇ．ベクトルのＯ−シグニチャメッセージ中で、トランシーバ間で一意的なＩＤを通信してもよい。

【0025】

［００２８］
特に本発明の好ましい実施形態を参照して本発明を説明してきたが、発明の精神および範囲から逸脱することなく、形態および詳細において変更および修正をしてもよいことは、当業者にとって容易に明白となるはずである。添付した特許請求の範囲は、このような変更および修正を含むことを意図されている。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［１］ＦＥＸＴチャネル上でトレーニングするトランシーバを識別するための方法において、
第１のトランシーバと第２のトランシーバとの間での複数のハンドシェークメッセージを含むハンドシェークフェーズを開始することと、
前記第１のトランシーバにおいて、一意的なＩＤを発生させることと、
前記ハンドシェークメッセージのうちの１つを使用して、前記第１のトランシーバから前記第２のトランシーバに前記一意的なＩＤを送信することと、
前記第１のトランシーバにおいて、後続するハンドシェークメッセージを受信することと、
前記受信した後続するハンドシェークメッセージが前記一意的なＩＤを含まない場合に、前記第１のトランシーバにおいて、前記ハンドシェークフェーズを中止することとを含む方法。
［２］前記複数のハンドシェークメッセージは、Ｇ．９９４．１ｇ．ｈｓメッセージを含む［１］記載の方法。
［３］前記１つのハンドシェークメッセージは、ＭＲ／ＣＬＲｇ．ｈｓメッセージを含む［２］記載の方法。
［４］前記１つのハンドシェークメッセージは、ＭＳ／ＣＬｇ．ｈｓメッセージを含む［２］記載の方法。
［５］前記受信した後続するハンドシェークメッセージは、ＭＳ／ＣＬｇ．ｈｓメッセージを含む［２］記載の方法。
［６］前記受信した後続するハンドシェークメッセージは、ＡＣＫｇ．ｈｓメッセージを含む［２］記載の方法。
［７］前記１つのハンドシェークメッセージは、前記一意的なＩＤに対するフィールドを含む［１］記載の方法。
［８］前記一意的なＩＤは、１６ビット数を含む［１］記載の方法。
［９］前記一意的なＩＤを発生させることは、乱数を発生させることを含む［１］記載の方法。
［１０］前記第２のトランシーバにおいて、第２の一意的なＩＤを発生させることと、
前記ハンドシェークメッセージのうちの別の１つを使用して、前記第２のトランシーバから前記第１のトランシーバに前記第２の一意的なＩＤを送信することと、
前記第２のトランシーバにおいて、後続するハンドシェークメッセージを受信することと、
前記受信した後続するハンドシェークメッセージが前記第２の一意的なＩＤを含まない場合に、前記第２のトランシーバにおいて、前記ハンドシェークフェーズを中止することとをさらに含む［１］記載の方法。
［１１］前記ハンドシェークフェーズが中止されなかった場合に、Ｇ．ベクトル初期化のＯ−シグニチャフェーズに進行することと、
前記Ｏ−シグニチャフェーズの間に、前記第１のトランシーバから前記第２のトランシーバに前記一意的なＩＤを送信することと、
前記ハンドシェークフェーズの間に送信された前記一意的なＩＤに前記一意的なＩＤが一致しない場合に、前記第２のトランシーバにおいて、前記Ｏ−シグニチャフェーズを中止することとをさらに含む［１］記載の方法。

【図1】

【図2】

【図3】