(57)【特許請求の範囲】
【請求項１】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送する方法であって、
前記第１のノードが、前記第２のノードに送信要求信号を伝送する第１の伝送ステップと、
前記第１のノードが、前記第２のノードから送信可信号および逆方向伝送要求信号を受信したかどうかを判定する第１の判定ステップと、
前記第１のノードが、前記第１の判定に応答して、前記第２のノードに、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送する第２の伝送ステップと、
前記第１のノードが、前記第２のノードから、第１のブロック確認応答信号、前記第２のデータおよび第２のブロック確認応答要求信号を受信したかどうかを判定する第２の判定ステップであって、該第１のブロック確認応答信号が全ての正しく受信されなかった第１のデータに関する情報を含む、該第２の判定ステップと、
前記第１のノードが、前記第２の判定に応答して、前記第２のノードに第２のブロック確認応答信号を伝送する第３の伝送ステップであって、該第２のブロック確認応答信号が全ての正しく受信されなかった第２のデータに関する情報を含む、該第３の伝送ステップと、
前記第１のノードが、前記第２のデータを正しく受信したかどうかを判定する第３の判定ステップであって、該第２のデータを正しく受信していない場合は、該第３の判定に応答して、前記中継ノードに中継ノード送信要求信号を伝送する、該第３の判定ステップと、
前記第１のノードが、前記第３の判定に応答して、前記中継ノードから中継ノード送信可信号を受信したかどうかを判定する第４の判定ステップと、
前記第１のノードが、前記中継ノードから第４のブロック確認応答信号および第３のデータを受信したかどうかを判定する第５の判定ステップであって、該第４のブロック確認応答信号が前記第１のデータの欠けている部分および前記第２のデータの欠けている部分の受信に関する情報を含む、該第５の判定ステップと、
前記第１のノードが、前記第３のデータを復号して前記第２のデータの欠けている部分を修復するステップと、
前記第１のノードが、前記第３のデータを正しく受信した場合は第４のブロック確認応答信号を伝送する第４の伝送ステップと、
を含む、前記方法。
【請求項２】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送する装置であって、
前記第１のノードが、前記第２のノードに送信要求信号を伝送する第１の伝送手段と、
前記第１のノードが、前記第２のノードから送信可信号および逆方向伝送要求信号を受信したかどうかを判定する第１の判定手段と、
前記第１のノードが、前記第１の判定手段に応答して、前記第２のノードに、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送する第２の伝送手段と、
前記第１のノードが、前記第２のノードから、第１のブロック確認応答信号、前記第２のデータおよび第２のブロック確認応答要求信号を受信したかどうかを判定する第２の判定手段であって、該第１のブロック確認応答信号が全ての正しく受信されなかった第１のデータに関する情報を含む、該第２の判定手段と、
前記第１のノードが、前記第２の判定手段に応答して、前記第２のノードに第２のブロック確認応答信号を伝送する第３の伝送手段であって、該第２のブロック確認応答信号が全ての正しく受信されなかった第２のデータに関する情報を含む、該第３の伝送手段と、
前記第１のノードが、前記第２のデータを正しく受信したかどうかを判定する第３の判定手段であって、該第２のデータを正しく受信していない場合は、該第３の判定手段に応答して、前記中継ノードに中継ノード送信要求信号を伝送する、該第３の判定手段と、
前記第１のノードが、前記第３の判定手段に応答して、前記中継ノードから中継ノード送信可信号を受信したかどうかを判定する第４の判定手段と、
前記第１のノードが、前記中継ノードから第４のブロック確認応答信号および第３のデータを受信したかどうかを判定する第５の判定手段であって、該第４のブロック確認応答信号が前記第１のデータの欠けている部分および前記第２のデータの欠けている部分の受信に関する情報を含む、該第５の判定手段と、
前記第１のノードが、前記第３のデータを復号して前記第２のデータの欠けている部分を修復する手段と、
前記第１のノードが、前記第３のデータを正しく受信した場合は第４のブロック確認応答信号を伝送する第４の伝送手段と、
を含む、前記装置。
【請求項３】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送する方法であって、
前記第２のノードが、前記第１のノードから送信要求信号を受信したかどうかを判定する第１の判定ステップと、
前記第２のノードが、前記第１の判定に応答して、前記第１のノードに送信可信号および逆方向伝送要求信号を伝送する第１の伝送ステップと、
前記第２のノードが、前記第１のノードから、前記第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号を受信したかどうかを判定する第２の判定ステップと、
前記第２のノードが、前記第２の判定に応答して、前記第１のノードに、第１のブロック確認応答信号、前記第２のデータおよび第２のブロック確認応答要求信号を伝送する第２の伝送ステップと、
前記第２のノードが、前記中継ノードから第２のブロック確認応答信号および第３のデータを受信したかどうかを判定する第３の判定ステップであって、前記第１の判定および該第３の判定のうちの一方が前記中継ノードから中継ノード送信可信号を受信したかどうかを判定するステップをさらに含む、該第３の判定ステップと、
前記第２のノードが、前記第３の判定に応答して、前記第１のノードに第３のブロック確認応答信号を伝送する第３の伝送ステップと、
を含む、前記方法。
【請求項４】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送するための装置であって、
前記第１のノードから送信要求信号を受信したかどうかを判定する第１の判定手段と、
前記第１の判定手段に応答して、前記第１のノードに送信可信号および逆方向伝送要求信号を伝送する第１の伝送手段と、
前記第１のノードから、前記第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号を受信したかどうかを判定する第２の判定手段と、
前記第２の判定手段に応答して、前記第１のノードに、第１のブロック確認応答信号、前記第２のデータおよび第２のブロック確認応答要求信号を伝送する第２の伝送手段と、
前記中継ノードから第２のブロック確認応答信号および第３のデータを受信したかどうかを判定する第３の判定手段であって、前記第１の判定手段および該第３の判定手段のうちの一方が前記中継ノードから中継ノード送信可信号を受信したかどうかを判定する手段をさらに含む、該第３の判定手段と、
前記第３の判定手段に応答して、前記第１のノードに第３のブロック確認応答信号を伝送する第３の伝送手段と、
を備え、
当該装置が前記第２のノードである、前記装置。
【請求項５】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送する方法であって、
前記中継ノードが、チャネルをリッスンするステップと、
前記中継ノードが、前記第１のノードから前記第１のデータを受信する第１の受信ステップと、
前記中継ノードが、前記第２のノードから前記第２のデータを受信する第２の受信ステップと、
前記中継ノードが前記第２のノードからの第１のブロック確認応答信号および前記第１のノードからの第２のブロック確認応答信号を傍受しているかどうかを判定する第１の判定ステップと、
前記中継ノードが、中継ノード送信要求信号および送信要求信号のうちの１つである信号を受信したかどうかを判定する第２の判定ステップと、
前記リッスンに応答して、チャネル状態が前記中継ノードとして働くのに十分であるかどうかを判定する第３の判定ステップと、
前記第１および第２の判定に応答して、中継ノード送信可信号をマルチキャストするステップと、
前記第１および第２の判定に応答して、ブロック確認応答信号および第３のデータをマルチキャストするステップであって、該第３のデータが、前記第１のデータの破損部分と前記第２のデータの破損部分の組合せである、該ステップと、
を含む、前記方法。
【請求項６】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送するための装置であって、
チャネルをリッスンする手段と、
前記第１のノードから前記第１のデータを受信する第１の受信手段と、
前記第２のノードから前記第２のデータを受信する第２の受信手段と、
前記中継ノードが前記第２のノードからの第１のブロック確認応答信号および前記第１のノードからの第２のブロック確認応答信号を傍受しているかどうかを判定する第１の判定手段と、
前記中継ノードが、中継ノード送信要求信号および送信要求信号のうちの１つである信号を受信したかどうかを判定する第２の判定手段と、
前記リッスンする手段に応答して、チャネル状態が前記中継ノードとして働くのに十分であるかどうかを判定する第３の判定手段と、
前記第１および第２の判定手段に応答して、中継ノード送信可信号をマルチキャストする手段であって、当該装置が前記中継ノードである、該手段と、
前記第１および第２の判定手段に応答して、ブロック確認応答信号および第３のデータをマルチキャストする手段であって、該第３のデータが、前記第１のデータの破損部分と前記第２のデータの破損部分の組合せである、該手段と、
を備え、
当該装置が前記中継ノードである、前記装置。
【請求項７】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送する方法であって、
前記第１のノードが、送信要求信号を伝送する第１の伝送ステップと、
前記第１のノードが、中継ノード送信可信号を受信したかどうかを判定する第１の判定ステップであって、該中継ノード送信可信号を受信していた場合は前記第１のノードと中継ノードとの間のチャネル状態に基いて転送のためのデータ速度を決定する、該第１の判定ステップと、
前記第１のノードが、前記第２のノードから送信可信号および逆方向伝送要求信号を受信したかどうかを判定する第２の判定ステップと、
前記第１のノードが、前記第１の判定に応答して、前記第２のノードに、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送する第２の伝送ステップと、
前記第１のノードが、前記第２のノードから、第１のブロック確認応答信号、前記第２のデータおよび第２のブロック確認応答要求信号を受信したかどうかを判定する第３の判定ステップであって、該第１のブロック確認応答信号が全ての正しく受信されなかった第１のデータに関する情報を含む、該第３の判定ステップと、
前記第１のノードが、前記第３の判定に応答して、前記第２のノードに第２のブロック確認応答信号を伝送する第３の伝送ステップであって、該第２のブロック確認応答信号が全ての正しく受信されなかった第２のデータに関する情報を含む、該第３の伝送ステップと、
前記第１のノードが、前記中継ノードから第４のブロック確認応答信号および第３のデータを受信したかどうかを判定する第４の判定ステップであって、該第４のブロック確認応答信号が前記第１のデータの欠けている部分および前記第２のデータの欠けている部分の受信に関する情報を含む、該第４の判定ステップと、
前記第１のノードが、前記第３のデータを復号して前記第２のデータの欠けている部分を修復するステップと、
前記第１のノードが、前記第２のノードから第３のブロック確認応答信号を受信したかどうかを判定する第５の判定ステップと、
前記第１のノードが、前記第３のデータを正しく受信した場合は第４のブロック確認応答信号を伝送する第４の伝送ステップと、
を含む、前記方法。
【請求項８】
中継ノードを介して、第１のノードから第２のノードに第１のデータを伝送し、前記第２のノードから前記第１のノードに第２のデータを伝送する装置であって、
前記第１のノードが、送信要求信号を伝送する第１の伝送手段と、
前記第１のノードが、中継ノード送信可信号を受信したかどうかを判定する第１の判定手段であって、該中継ノード送信可信号を受信していた場合は前記第１のノードと中継ノードとの間のチャネル状態に基いて転送のためのデータ速度を決定する、該第１の判定手段と、
前記第１のノードが、前記第２のノードから送信可信号および逆方向伝送要求信号を受信したかどうかを判定する第２の判定手段と、
前記第１のノードが、前記第１の判定手段に応答して、前記第２のノードに、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送する第２の伝送手段と、
前記第１のノードが、前記第２のノードから、第１のブロック確認応答信号、前記第２のデータおよび第２のブロック確認応答要求信号を受信したかどうかを判定する第３の判定手段であって、該第１のブロック確認応答信号が全ての正しく受信されなかった第１のデータに関する情報を含む、該第３の判定手段と、
前記第１のノードが、前記第３の判定手段に応答して、前記第２のノードに第２のブロック確認応答信号を伝送する第３の伝送手段であって、該第２のブロック確認応答信号が全ての正しく受信されなかった第２のデータに関する情報を含む、該第３の伝送手段と、
前記第１のノードが、前記中継ノードから第４のブロック確認応答信号および第３のデータを受信したかどうかを判定する第４の判定手段であって、該第４のブロック確認応答信号が前記第１のデータの欠けている部分および前記第２のデータの欠けている部分の受信に関する情報を含む、該第４の判定手段と、
前記第１のノードが、前記第３のデータを復号して前記第２のデータの欠けている部分を修復する手段と、
前記第１のノードが、前記第２のノードから第３のブロック確認応答信号を受信したかどうかを判定する第５の判定手段と、
前記第１のノードが、前記第３のデータを正しく受信した場合は第４のブロック確認応答信号を伝送する第４の伝送手段と、
を備える、前記装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ドラフトＩＥＥＥ８０２．１１ｎ標準の双方向伝送（通信）を補助する３ノード協働方式に関する。
【背景技術】
【０００２】
マルチキャストおよびブロードキャストの分野では、有線ネットワークおよび／または無線ネットワークを介して、１つのサーバから複数の受信機にデータが伝送される。本明細書で用いるマルチキャスト・システムは、１つのサーバが同じデータを複数の受信機に同時に伝送し、これらの受信機が、全受信機の一部分または全体であるシステムである
。ブロードキャスト・システムは、１つのサーバが、同じデータを全ての受信機に同時に伝送するシステムである。すなわち、定義によれば、マルチキャスト・システムはブロードキャスト・システムを含むことができる。
【０００３】
１つのアクセス・ポイント（ＡＰ）およびいくつかのノードを有するマルチキャスト（ダウンリンク）およびマルチアクセス（アップリンク）チャネルを考える。ＩＥＥＥ８０２．１１ｎドラフト標準では、逆方向（ＲＤ）プロトコルを導入して、送信機会（ＴＸＯＰ）内の双方向トラフィック・フローの高速スケジューリングを行う。この逆方向プロトコルによって、ＴＸＯＰを得たノードは、ＴＸＯＰの制御権を維持したまま、別のノードの逆方向伝送を認可することができる。ノード間のチャネル状態が不適切（低品位）である場合には、これら２つのノード間の伝送の質が低下する。この質の低下は、データ転送速度の低下および／またはスループットの低下であることがある。
【０００４】
ＩＥＥＥ８０２．１１ｎドラフト標準では、逆方向（ＲＤ）プロトコルは、図１に示すように提案されている。ＩＥＥＥ８０２．１１ｎドラフト標準の逆方向プロトコルは、２つのノード間の双方向伝送のスケジューリングしか行わない。ＩＥＥＥ８０２．１１ＷＬＡＮ標準には、３ノード双方向伝送のための既存のスケジューリング・プロトコルはない。
【０００５】
第３のノードを２つのノードのための中継ノードとして作用させれば、有利であろう。しかし、このような第３の（中継）ノードを使用すると、２つのノード間の通信（伝送）が複雑になる。
【０００６】
本明細書で用いるノードは、局（ＳＴＡ）、移動装置、移動端末、デュアル・モード・スマート・フォン、コンピュータ、ラップトップ・コンピュータ、またはＩＥＥＥ８０２．１１ｎドラフト標準で動作可能な任意の他の等価な装置を含む（ただしこれらに限定されない）。
【発明の概要】
【０００７】
１つのアクセス・ポイント（ＡＰ）およびいくつかのノードを有するマルチキャスト（ダウンリンク）およびマルチアクセス（アップリンク）チャネルを考える。ＩＥＥＥ８０２．１１ｎドラフト標準では、逆方向（ＲＤ）プロトコルを導入して、送信機会（ＴＸＯＰ）内の双方向トラフィック・フローの高速スケジューリングを行う。この逆方向プロトコルによって、ＴＸＯＰを得たノードは、ＴＸＯＰの制御権を維持したまま、別のノードの逆方向伝送を認可することができる。これら２つのノード間の伝送が第３のノードである半二重中継ノード（ＲＮ）を介した協働を含むときには、状況がより複雑になるが、無線ネットワーク符号化を利用して、システムのスループットをさらに向上させることができる。本発明では、ネットワーク符号化３ノード双方向協働によって伝送をスケジューリングするＭＡＣレイヤにおけるトリプル・プレイ・プロトコルについて述べる。
【０００８】
送信要求信号を伝送すること、送信可信号および逆方向伝送要求信号が受信されているかどうかを判定すること、第１の判定に応答して、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送すること、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求信号が受信されているかどうかを判定すること、第２の判定に応答して、第２のブロック確認応答信号を伝送すること、第３のブロック確認応答信号が受信されているかどうかを判定すること、ならびに第３の判定に応答して、第４のブロック確認応答信号を伝送することを含む、方法および装置について述べる。また、送信要求信号が受信されているかどうかを判定すること、第１の判定に応答して、送信可信号、逆方向伝送要求信号を伝送すること、第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号が受信されているかどうかを判定すること、第２の判定に応答して、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求を伝送すること、第２のブロック確認応答信号および第３のデータが受信されているかどうかを判定すること、ならびに第３の判定に応答して、第３のブロック確認応答信号を伝送することを含む、方法および装置について述べる。さらに、チャネルをリッスンすること、リッスンに応答してチャネル状態を推定すること、信号が受信されているかどうかを判定すること、チャネル状態が中継ノードとして働くのに十分であるかどうかを判定すること、第１および第２の判定に応答して、中継ノード送信可信号をマルチキャストすること、ならびに第１および第２の判定に応答して、ブロック確認応答信号およびデータをマルチキャストすることを含む、方法および装置について述べる。
【０００９】
このようなＭＡＣレイヤ・トリプル・プレイ・プロトコルは、将来のＩＥＥＥ８０２．１１超高スループット（ＶＨＴ）標準に不可欠となる可能性がある。本発明のトリプル・プレイ・プロトコルの利点は、将来の標準に加える変更が最小限に抑えられるように、ＩＥＥＥ８０２．１１ｎドラフト標準に提案されている逆方向（ＲＤ）プロトコルに基づいて設計されており、逆方向互換性が高い点である。
【００１０】
本発明は、以下の詳細な説明を添付の図面と関連付けて読めば、最もよく理解される。添付の図面は、以下に簡単に説明する図面を含む。
【図面の簡単な説明】
【００１１】
【図１】逆方向伝送を要求するＩＥＥＥ８０２．１１ｎ標準に従って動作する２つのノードの動作を示す図である。
【図２】ＲＮとの初期ハンドシェーキングを行わない、本発明のトリプル・プレイ・プロトコルの第１の実施形態を示す図である。
【図３】ＲＮとの初期ハンドシェーキングを行う、本発明のトリプル・プレイ・プロトコルの第２の実施形態を示す図である。
【図４】本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード１の動作の流れ図である。
【図５】本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード２の動作の流れ図である。
【図６】本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるＲＮの動作の流れ図である。
【図７】本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード１の動作の流れ図である。
【図８】本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード２の動作の流れ図である。
【図９】本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるＲＮの動作の流れ図である。
【図１０】本発明の原理による例示的な装置のブロック図である。
【発明を実施するための形態】
【００１２】
本発明の３ノード双方向協働プロトコルでは、２つのノード、ノード１およびノード２は、両者の間に双方向トラフィック・フローがあるという点でそれぞれがソース・ノードにも宛先ノードにもなり、第３のノードＲＮが中継ノードとなって、双方向伝送を補助する。どのノードがソース・ノードになってもよく、どのノードが宛先ノードになってもよく、どのノードがＲＮになってもよいことに留意されたい。実際に、１つのノードが、同時にソース・ノード、宛先ノード、ＲＮとして動作することもできる。一般性を失わずに、ノード１がＴＸＯＰを取得し、ノード１がノード２との双方向通信（トラフィック・フロー、伝送）を開始するものと仮定する。ただし、２つのノード間の直接リンクのチャネル状態が低品質であるため、協働中継ノード（ＲＮ）を利用して、両ノードにデータを転送し、両ノードにおける復号処理プロセスを補助する。復号処理は、データ伝送（通信）の受信後に一方のノードで行われる。復号処理は、データの信頼性を高めるために使用された符号化処理を逆に行うために使用される。例えば、リード・ソロモン／ビタビ符号化または単純なパリティ検査さえ使用して、伝送データの信頼性を高める。データは、オーディオ・データ、ビデオ・データ、マルチメディア・データ、コンテンツ・データ、またはその他の任意の形態のデータを含むことができる（ただしこれらに限定されない）。データは、通常、パケットおよび／またはフレームにフォーマット化されるが、これらの用語は、本明細書では、任意のフォーマット化方式を示すために交換可能に使用される。
【００１３】
無線ネットワーク符号化は、協働によってデータ伝送（通信）の信頼性を向上させることと、直接リンクを介した１方向伝送の所与のデータ転送速度を維持することとの間の兼ね合いである。中継ノード（ＲＮ）は、ノード１およびノード２の両方から（異なる時間スロットで、または同時に）データを受信し、これら２組のデータを混合（結合）して新たな１組のデータを生成し、この新たな混合データを両方のノードにブロードキャスト（マルチキャスト）する。各ノード（ソースおよび宛先）は、他方のノード（ソースおよび宛先）からの所望のデータの伝送と、ＲＮからの伝送とを受信する。その後、各ノードは、当該ノードが伝送（送出）したデータの知識に基づいて、所望のデータをまとめて復号処理する。
【００１４】
ＲＮにおける混合データは、２組の受信データによって決まる。ＲＮがデータを混合する方法は、ネットワーク符号化に基づく。当技術分野で既知のネットワーク符号化の例のいくつかと、可能なデータ混合方法とを、以下に与える。なお、以下に挙げる例は、全ての例を網羅したものではないことを理解されたい。
【００１５】
（１）データは、復号転送法に基づいてネットワーク符号化することができる、すなわち、２つの復号情報ビット・シーケンスのバイナリ付加とすることができる。
【００１６】
（２）データは、ソフト復号転送法に基づいてネットワーク符号化することができる、すなわち、２つのデータのソフト復号ビットの対数尤度比（ＬＬＲ）の組合せとすることができる。
【００１７】
（３）データは、増幅転送法または圧縮転送法に基づいてネットワーク符号化することができる、すなわち、２つの重み付けした受信信号の線形結合とすることができる。データは、中継ノード（ＲＮ）が両ノードから個々の信号を別々に受信するか、あるいは１つの混合信号を受信するかに応じて、ディジタル・ネットワーク符号化とアナログ・ネットワーク符号化にさらに分割することができる。
【００１８】
（４）データは、物理レイヤ・ネットワーク符号化することができる、すなわち、物理レイヤ領域の動作とすることができるが、バイナリ領域のバイナリ付加と等価である。
【００１９】
（５）データは、ノイズ除去転送法に基づいてネットワーク符号化することができる、すなわち可能な伝送データを表す別に設計されたコードブックを使用することができる。
【００２０】
本発明のトリプル・プレイ・プロトコルは、単一アンテナ技術および／またはマルチアンテナ技術と結合することができる。空間多重化、時空間ブロック符号、伝送ビーム形成および／または受信ビーム形成は、全ての伝送に適用することができる。
【００２１】
このトリプル・プレイ・プロトコルは、２つの実施形態を有する。第１の実施形態では、初期ハンドシェーキングを行わないが、第２の実施形態では、ノード（ノード１、ノード２およびＲＮ）間の初期ハンドシェーキングを行う。本発明のトリプル・プレイ・プロトコルでは、ノード１のＴＸＯＰ内で、３つのノードからの伝送をスケジューリングすることを試みる。
【００２２】
ＩＥＥＥ８０２．１１ｎドラフト標準に記載されているフレーム・アグリゲーションおよびマルチ・トラフィックＩＤブロック確認応答（ＭＴＢＡ）が、本発明のトリプル・プレイ・プロトコルにおける前提とする。従って、本発明のシステムは、ＲＮが、２つのノード（ソースおよび宛先）によってデータを正しく復号処理されないサブフレームのみを処理する場合に、データ転送速度をさらに向上させることができる。
【００２３】
第１の実施形態は、ＲＮとの初期ハンドシェーキングを行わない、本発明のトリプル・プレイ・プロトコルである。この実施形態では、ノード１とノード２との間の２つの伝送を良好に受信できる任意のノードが、競合して中継ノード（ＲＮ）として機能することができる。図２は第１の実施形態を示す。本発明のトリプル・プレイ・プロトコルは、初期ハンドシェーキングを行わず、以下のように動作する。
【００２４】
（１）ノード２は、送信可（ＣＴＳ）メッセージ（信号）を送信することによって、ノード１から伝送（送信）された送信要求（ＲＴＳ）信号（メッセージ）の（ノード１に対して）確認応答を行うとき、双方向通信である逆方向伝送の要求も行う。次いで、ノード１は、データ１およびブロック確認応答（ＡＣＫ）要求を伝送し、ノード２にＲＤ伝送を認可する。本発明の別の実施形態では、ノード１は、ノード２からの明示的な要求がなくても、ノード２にＲＤ伝送を認可することができる。
【００２５】
（２）ノード２は、データ１の正しく受信されなかったすべてのサブフレームに関する情報を含むブロックＡＣＫ（ＢＡ１）をノード１に戻す。ノード２は、さらにそのデータ２とその後にそのブロックＡＣＫ要求とを送信する。
【００２６】
（３）ノード１は、データ２の正しく受信されなかったすべてのサブフレームに関する情報を含むブロックＡＣＫ（ＢＡ２）をノード２に送信する。ノード２がデータ１中の全てのサブフレームを正しく受信していない、且つ／またはノード１がデータ２中の全てのサブフレームを正しく受信していない場合には、ノード１は、Ｒｅｑｕｅｓｔ＿ＲＳ＿Ｔｏ＿Ｓｅｎｄ（Ｒ＿ＲＳ＿ＴＳ）メッセージ（信号）をポストして、ＲＮのヘルプを求める。
【００２７】
（４）ＲＮが、ノード２におけるデータ１の欠けている部分およびノード１におけるデータ２の欠けている部分を正しく受信しており、且つＲ＿ＲＳ＿ＴＳメッセージ（信号）を受信した場合には、Ｃｌｅａｒ＿ＲＳ＿Ｔｏ＿Ｓｅｎｄ（Ｃ＿ＲＳ＿ＴＳ）メッセージ（信号）を伝送（送出）して、自分がＲＮとして機能していることをノード１およびノード２に通知することができる。次いで、ＲＮは、データ１およびデータ２の欠けている部分を両方とも自分が受信したことを報告するためにブロックＡＣＫ（ＢＡ１＆２）をマルチキャスト（ブロードキャスト）して、その後上記の例に挙げたような様々なネットワーク符号化方式の何れか１つに基づいて、データ１およびデータ２の欠けている部分の両方を結合したデータ３をマルチキャスト（ブロードキャスト）する。ＲＮは、上記の例に挙げたような任意のネットワーク符号化方式を用いてデータの欠けている部分を混合（結合）することができるようにどんなデータが欠けている（正しく受信されなかった、失われた、破壊された、損傷した）のかを判定するために、ＢＡ１およびＢＡ２であるデータの欠けている部分の両方を受信することが前提となる。
【００２８】
なお、ＲＮは、ノード２におけるデータ１の欠けている部分の一部分およびノード１におけるデータ２の欠けている部分の一部分しか正しく受信していない場合には、上記の例示的なネットワーク符号化方式に基づいてこれらのデータの部分を結合して、それをデータ３として伝送（通信、送信）することもできる。
【００２９】
ＢＡ１＆２には、データ１の正しく受信された欠けている部分のみに関する情報を含み、その後にデータ２の正しく受信された欠けている部分のみに関する情報を含むように自動的に要約されたビットマップがある。ノード１およびノード２は両方ともこのビットマップに気づいて（のことを知って）いるので、ＲＮは、その伝送後にブロックＡＣＫ要求を伝送（通信、送出）する必要はない。
【００３０】
（５）ノード２が最初にブロックＡＣＫ（ＢＡ３２）を送出（伝送、通信）して、それがデータ１の欠けている部分を受信したことを報告し、次いでノード１が、ＢＡ３１を通信（送出、伝送）して、それがデータ２の欠けている部分のみを受信したことを報告する。本発明の代替実施形態では、ブロックＡＣＫを送信する順序が逆になる。
【００３１】
（６）ＲＮの伝送後、ノード１およびノード２の一方または両方が依然としていくつかのサブフレームの再伝送を必要としており、ＴＸＯＰが満了していない（期限切れになっていない）場合には、ノード１およびノード２の一方が、別のＲ＿ＲＳ＿ＴＳを伝送（送出、通信）して再度ヘルプを求め、前と同じノードまたは別のノードがＲＮとして機能することができ、または他方のソース・ノード（例えば、ノード１が依然として欠けているデータを必要としており、先に別のＲ＿ＲＳ＿ＴＳメッセージ（信号）を送出した場合には、ノード２が他方のソース・ノードとなる）が再伝送を行うことができる。
【００３２】
（７）制御フレームは、スケジューリングおよび信号送出において不可欠な役割を果たすので、データ・フレームより重要であるため、制御フレームは低いデータ転送速度を用いて送信（伝送、通信）し、その一方、データを高いデータ転送速度を用いて送信（伝送、通信）し、宛先における両者の受信に差が生じるようにすることが推奨される。その性質上、低いデータ転送速度の伝送の方が、信頼性が高くなるはずである。
【００３３】
（８）なお、本発明のトリプル・プレイ・プロトコルでは、ＲＮは、ノード１とは無関係に指定されるが、実際には、このようなＲＮが存在しないことや、あるいは全てのＲＮが両方のデータ・セットまたは両方のデータ・セットの大部分をうまく復号できないこともあることに留意されたい。このような場合、ノード１が一定期間待機して、それでもＣ＿ＲＳ＿ＴＳを受信しない場合、すなわちヘルプできるＲＮが存在しない場合には、ノード１は、ノード２がＢＡ２において示す、ノード２が正しく受信しなかったデータを、再伝送しなければならない。
【００３４】
第２の実施形態は、ＲＮとの初期ハンドシェーキングを行う、本発明のトリプル・プレイ・プロトコルである。この実施形態の第１の実施形態に優る利点は、以下の通りである。第１に、ノード１およびノード２は、専用のＲＮが存在していることを知っているので、それらの伝送（通信）をさらに積極的にすることができる。第２に、ＲＮは、両ノード（ソースおよび宛先）からの伝送に対して感度があり、データを復元して処理する。第３に、両ノード（ソースおよび宛先）から信号を受信することもあるその他のノードが、常にチャネルをリッスンしていなくてもよいので、緩和した（ｒｅｌａｘｅｄ）状態である。ただし、ＲＮを含め自由な状態（利用可能な状態）にあるその他のノードは、それらがＲＮとして機能する場合にそれらがネットワークにもたらす恩恵を最もよく推定することができるように、依然として何らかの方法でチャネルをリッスンし、他のノードからチャネル情報を取得する必要があることもある。さらに、ＲＮになるための競合は、単にデータの受信状態が良好であるだけでなく、むしろＲＮになろうとすることによるところが大きいので、他のノードを支える十分なチャネル品質（状態）または最良のチャネル品質（状態）を有していないノードが、ＲＮになる可能性もある。従って、チャネル状態に基づく良好なＲＮ競合機構が必要とされている。図３に第２の実施形態を示す。第２の実施形態の説明は、以下の通りである。
【００３５】
（１）ＲＮは、ノード１のＲＴＳを受信した場合には、Ｃ＿ＲＳ＿ＴＳ（Ｃｌａｅｒ＿ＲＳ＿Ｔｏ＿Ｓｅｎｄ）フレームを送出（伝送、通信）して、ノード２がＣＴＳを送信（伝送、通信）する前に、自分がＲＮとして機能していることを他のノードに通知することができる。ノード１およびノード２は、両方ともＣ＿ＲＳ＿ＴＳを受信することができなければならない。次いで、ノード１およびノード２は、これらのそれぞれとＲＮとの間のチャネル状態に基づいてそれぞれのデータ転送速度を決定することができる。チャネル状態が十分に良好である場合には、ノード１およびノード２は、両者の間の直接リンクの能力よりも高いデータ転送速度を使用することもできる。次いで、ノード２は、双方向通信を求める要求であるそのＲＤ伝送要求とともに、そのＣＴＳを送出（伝送、通信）する。これで、ＲＮとのハンドシェーキングが終了する。
【００３６】
（２）次いで、ノード１は、データ１およびブロックＡＣＫ要求を伝送し、ノード２にＲＤ伝送を認可する。ノード２は、データ１の正しく受信されなかった（失われた、破壊された、損傷した）すべてのサブフレームに関する情報を含むブロックＡＣＫ（ＢＡ１）をノード１に送信し、その後にそのデータ２とそのブロックＡＣＫ要求を送信する。本発明の別の実施形態では、ノード１は、ノード２からの明示的な要求がなくても、ノード２にＲＤ伝送を認可することができる。
【００３７】
（３）以降の処理は、ノード１がＲ＿ＲＳ＿ＴＳフレームとその後のＲＮのＣ＿ＲＳ＿ＴＳフレームを送出する必要がなくなることを除けば、初期ハンドシェーキングを行わないトリプル・プレイ・プロトコルと同様である。
【００３８】
図４を参照するに、本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード１の動作の流れ図である。４０５で、ノード１は、ＲＴＳ信号（メッセージ）を伝送（通信、送出）する。４１０で、ノード１が、ノード１が伝送したＲＴＳメッセージ（信号）に応答するＣＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード１が、ＣＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信していない場合には、処理は、４１０に戻る。ノード１が、ＣＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信している場合には、４１５で、ノード１は、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可を伝送（通信、送出）する。４２０で、ノード１が、ＢＡ１、データ２およびブロックＡＣＫ要求２を受信しているかどうかを判定するテストを実行する。ノード１が、ＢＡ１、データ２およびブロックＡＣＫ要求２信号（メッセージ）を受信していない場合には、処理は、４２０に戻る。ノード１が、ＢＡ１、データ２、およびブロックＡＣＫ要求２信号（メッセージ）を受信している場合には、４２５で、ノード１は、ＢＡ２およびＲ＿ＲＳ＿ＴＳメッセージ（信号）を伝送（通信、送出）する。４２７で、Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されているかどうかを判定するテストを実行する。Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されている場合には、４３０で、ノード１がＢＡ３２メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード１がＢＡ３２メッセージ（信号）を受信していない場合には、処理は、４３０に戻る。ノード１が、ＢＡ３２メッセージ（信号）を受信している場合には、４３５で、ノード１はＢＡ３１を伝送（通信、送出）する。ＢＡ３１は、ＲＮからのブロードキャスト（マルチキャスト）で受信されるデータ３に応答して送出される。ＢＡ３２は、ＲＮからブロードキャスト（マルチキャスト）され受信されるデータ３に応答して、ノード２から受信される。Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されていない場合には、処理は、４２７に戻る。図４では、タイマを示していない。しかし、テストを実行する各ポイントでは、タイマを使用する。例えば、４０５でＲＴＳ信号（メッセージ）が送信（伝送）された後でタイマをセットし、４１０で、タイマが満了になる前にＣＴＳ信号（メッセージ）が受信されなかった場合に、ノード１は、ＲＴＳ信号（メッセージ）を再送する。ＣＴＳ信号（メッセージ）が受信され、ＲＤ信号（メッセージ）が受信されない場合には、ノード１は、次のステップに進み、ＲＤ要求信号（メッセージ）が存在していないと仮定するか、あるいはＲＤ要求信号（メッセージ）が暗黙であったと仮定する場合もある。同様に、４１５で、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可の後でタイマがセットされる。タイマが満了してもＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）が受信されていない場合には、ノード１は、ＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を再伝送する。あるいは、タイマが満了してもＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）が受信されていない場合には、ノード１は、Ｒ＿ＲＳ＿ＴＳ信号（メッセージ）を送出して、中継ノードのヘルプを要求する。同様に、４２７および４３０で、タイマをセットしてＣ＿ＲＳ＿ＴＳ信号（メッセージ）およびＢＡ３２の受信を待機する。
【００３９】
次に、図５を参照するに、本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード２の動作の流れ図である。５０５で、ノード２がノード１から伝送（通信、送出）されたＲＴＳメッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード２が、ノード１から送出（伝送、通信）されたＲＴＳメッセージ（信号）を受信していない場合には、処理は、５０５に戻る。ノード２が、ノード１から送出（伝送、通信）されたＲＴＳメッセージ信号を受信している場合には、５１０で、ノード２は、ＣＴＳメッセージ（信号）およびＲＤ伝送要求を伝送（通信、送出）する。５１５で、ノード２がデータ１、ブロックＡＣＫ要求１およびＲＤ伝送認可メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード２が、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可メッセージ（信号）を受信していない場合には、処理は、５１５に戻る。ノード２が、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可メッセージ（信号）を受信している場合には、５２０で、ノード２は、ＢＡ１、データ２およびブロックＡＣＫ要求２を伝送（通信、送出）する。５２５で、ノード２が、ＲＮからブロードキャスト（マルチキャスト）されたＣ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ１＆２およびデータ３を受信しているかどうかを判定するテストを実行する。ノード２が、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ１＆２およびデータ３を受信していない場合には、処理は、５２５に戻る。ノード２が、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ１＆２およびデータ３を受信している場合には、５３０で、ノード２は、ＢＡ３２を伝送する。ＢＡ３２は、ＲＮからのブロードキャスト（マルチキャスト）され受信されるデータ３に応答して、ノード２から受信される。図５では、タイマを示していない。しかし、テストを実行するほとんどのポイントでは、タイマを使用する。例えば、５１０でノード２がＣＴＳおよびＲＤ伝送要求を伝送（通信、送出）した後でタイマをセットし、５１５で、タイマが満了になる前にデータ１、ブロックＡＣＫ要求１およびＲＤ伝送認可の信号（メッセージ）が受信されなかった場合に、ノード２は、ＣＴＳおよびＲＤ伝送要求の信号（メッセージ）を再伝送する。同様に、５２５で、ノード２がＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を伝送（通信、送出）した後でタイマをセットし、ノード２がＣ＿ＲＳ＿ＴＳ、ＢＡ１＆２およびデータ３を受信していない場合に、ノード２は、ＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を再伝送する。
【００４０】
次に、図６を参照するに、本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるＲＮの動作の流れ図である。６０５で、ＲＮは、チャネルをリッスンし、チャネル状態を推定する。信号対雑音比（ＳＮＲ）や受信信号強度指標（ＲＳＳＩ）など（ただしこれらに限定されない）、様々な信号品質測度のうちいずれかの測度を使用して、チャネル状態を示すことができる。６１０で、ＲＮが、ノード１からＲ＿ＲＳ＿ＴＳメッセージ（信号）を受信しているかどうかを判定するテストを実行する。ＲＮが、Ｒ＿ＲＳ＿ＴＳメッセージ（信号）を受信していない場合には、処理は、６０５に戻る。ＲＮが、Ｒ＿ＲＳ＿ＴＳメッセージ（信号）を受信している場合には、６１５で、（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好であるかどうかを判定するテストを実行する。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好でない場合には、処理は、６０５に戻る。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好である場合には、６２０で、ＲＮは、Ｃ＿ＲＳ＿ＴＳ、ＢＡ１＆２およびデータ３をブロードキャスト（マルチキャスト）する。上記で説明および議論したデータ３は、データ１とデータ２の欠けている部分を混合したもの（組合せ）である。ＲＮは、ＲＮがブロックＡＣＫ、データ１およびデータ２において傍受（ｏｖｅｒｈｅａｒ）した情報に基づいてこの混合したもの（組合せ）を作成する。
【００４１】
次に、図７を参照するに、本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード１の動作の流れ図である。７０５で、ノード１は、ＲＴＳ信号（メッセージ）を伝送（通信、送出）する。７１０で、ノード１が、ノード１が伝送したＲＴＳメッセージ（信号）に応答するＣＴＳ信号（メッセージ）、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）およびＲＤ伝送要求メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード１が、ＣＴＳ信号（メッセージ）、Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信していない場合には、処理は、７１０に戻る。ノード１が、ＣＴＳ信号（メッセージ）、Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信している場合には、７１５で、ノード１は、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可を伝送（通信、送出）する。７２０で、テストを実行して、ノード１が、ＢＡ１、データ２およびブロックＡＣＫ要求２を受信しているかどうかを判定する。ノード１が、ＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を受信していない場合には、処理は、７２０に戻る。ノード１が、ＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を受信している場合には、７２５で、ノード１は、ＢＡ２を伝送（通信、送出）する。７３０で、ノード１が、ＢＡ３２メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード１が、ＢＡ３２メッセージ（信号）を受信していない場合には、処理は、７３０に戻る。ノード１が、ＢＡ３２メッセージ（信号）を受信している場合には、７３５で、ノード１は、ＢＡ３１を伝送（通信、送出）する。ＢＡ３１は、ＲＮからのブロードキャスト（マルチキャスト）で受信されるデータ３に応答して送出される。ＢＡ３２は、ＲＮからのブロードキャスト（マルチキャスト）で受信されるデータ３に応答して、ノード２から受信される。図７では、タイマを示していない。しかし、テストを実行する各ポイントでは、タイマを使用する。例えば、７０５でＲＴＳ信号（メッセージ）が送信（伝送）された後でタイマをセットし、７１０で、タイマが満了になる前にＣＴＳ信号（メッセージ）およびＣ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されなかった場合に、ノード１は、ＲＴＳ信号（メッセージ）を再送する。ＣＴＳ信号（メッセージ）およびＣ＿ＲＳ＿ＴＳメッセージ（信号）が受信され、ＲＤ信号（メッセージ）が受信されない場合には、ノード１は、次のステップに進み、ＲＤ要求信号（メッセージ）が存在していないと仮定するか、あるいはＲＤ要求信号（メッセージ）が暗黙であったと仮定する場合もある。ＣＴＳ信号（メッセージ）が受信され、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）およびＲＤ信号（メッセージ）が受信されない場合には、ノード１は、次のステップに進み、中継ノードが存在しておらず、ＲＤ要求信号（メッセージ）が存在しないと仮定するか、あるいはＲＤ要求信号（メッセージ）が暗黙であったと仮定する場合もある。同様に、７１５で、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可の伝送の後でタイマがセットされる。タイマが満了してもＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）が受信されていない場合には、ノード１は、ＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を再伝送する。同様に、７３０で、タイマをセットしてＢＡ３２の受信を待機する。
【００４２】
次に、図８を参照するに、本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード２の動作の流れ図である。８０５で、ノード２が、ノード１が伝送（通信、送出）したＲＴＳメッセージ（信号）およびＲＮがブロードキャスト（マルチキャスト）したＣ＿ＲＳ＿ＴＳメッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード２が、ノード１が送出（伝送、通信）したＲＴＳメッセージ（信号）およびＲＮがブロードキャスト（マルチキャスト）したＣ＿ＲＳ＿ＴＳメッセージ（信号）を受信していない場合には、処理は、８０５に戻る。ノード２が、ノード１が送出（伝送、通信）したＲＴＳメッセージ（信号）およびＲＮがブロードキャスト（マルチキャスト）したＣ＿ＲＳ＿ＴＳメッセージ（信号）を受信している場合には、８１０で、ノード２は、ＣＴＳメッセージ（信号）およびＲＤ伝送要求を伝送（通信、送出）する。８１５で、ノード２が、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード２が、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可メッセージ（信号）を受信していない場合には、処理は、８１５に戻る。ノード２が、データ１、ブロックＡＣＫ要求１およびＲＤ伝送認可メッセージ（信号）を受信している場合には、８２０で、ノード２は、ＢＡ１、データ２およびブロックＡＣＫ要求２を伝送（通信、送出）する。８２５で、ノード２が、ＲＮがブロードキャスト（マルチキャスト）したＢＡ１＆２およびデータ３を受信しているかどうかを判定するテストを実行する。ノード２が、ＢＡ１＆２およびデータ３を受信していない場合には、処理は、８２５に戻る。ノード２が、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ１＆２およびデータ３を受信している場合には、８３０で、ノード２は、ＢＡ３２を伝送する。ＢＡ３２は、ＲＮからのブロードキャスト（マルチキャスト）され受信されるデータ３に応答して、ノード２によって伝送（通信、送出）される。図８では、タイマを示していない。しかし、テストを実行するほとんどのポイントでは、タイマを使用する。例えば、８１０でノード２がＣＴＳおよびＲＤ伝送要求を伝送（通信、送出）した後でタイマをセットし、８１５で、タイマが満了になる前にデータ１、ブロックＡＣＫ要求１およびＲＤ伝送認可の信号（メッセージ）が受信されなかった場合に、ノード２は、ＣＴＳおよびＲＤ伝送要求の信号（メッセージ）を再伝送する。同様に、８２５で、ノード２がＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を伝送（通信、送出）した後でタイマをセットし、ノード２がＢＡ１＆２およびデータ３を受信していない場合に、ノード２が、ＢＡ１、データ２およびブロックＡＣＫ要求２の信号（メッセージ）を再伝送する。
【００４３】
次に、図９を参照するに、本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるＲＮの動作の流れ図である。９０５で、ＲＮは、チャネルをリッスンし、チャネル状態を推定する。信号対雑音比（ＳＮＲ）や受信信号強度指標（ＲＳＳＩ）など（ただしこれらに限定されない）、様々な信号品質測度のうちいずれかの測度を使用して、チャネル状態を示すことができる。９１０で、ＲＮが、ノード１からＲＴＳメッセージ（信号）を受信（傍受）しているかどうかを判定するテストを実行する。ＲＮが、ＲＴＳメッセージ（信号）を受信（傍受）していない場合には、処理は、９０５に戻る。ＲＮが、ＲＴＳメッセージ（信号）を受信（傍受）している場合には、９１５で、（様々な信号品質測度の何れか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好であるかどうかを判定するテストを実行する。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好でない場合には、処理は、９０５に戻る。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好である場合には、９２０で、ＲＮは、Ｃ＿ＲＳ＿ＴＳをブロードキャスト（マルチキャスト）し、９２５で、ＲＮは、ＢＡ１＆２およびデータ３をブロードキャスト（マルチキャスト）する。上記で説明および議論したデータ３は、データ１とデータ２の欠けている部分を混合したもの（組合せ）である。ＲＮは、ＲＮがブロックＡＣＫ、データ１およびデータ２において傍受した情報に基づいてこの混合したもの（組合せ）を作成する。
【００４４】
図１０は、本発明の原理による例示的な装置のブロック図である。いかなるノードも様々な時点でソース・ノード、宛先ノードおよび中継ノードとして挙動することができるので、図１０の装置は様々な時点でこれらのデバイス（装置）のうちのいずれかとなる。トランシーバが、データおよび任意の制御信号を実際に伝送および受信し、制御ロジックが、その他の全ての機能を実行する。
【００４５】
具体的には、ソース・ノードとして挙動しているときには、図１０の装置の制御ロジック部分は、送信可信号および逆方向伝送要求信号が受信されているかどうかを判定する手段と、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求信号が受信されているかどうかを判定する手段と、第３のブロック確認応答信号が受信されているかどうかを判定する手段とを含む。（ソース・ノードとして挙動する）本発明の第２の実施形態では、第１の判定手段は、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含む。ソース・ノードとして挙動する図１０の装置のトランシーバ部分は、送信要求信号を伝送する手段と、第１の判定手段に応答して、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送する手段と、第２の判定手段に応答して、第２のブロック確認応答信号を伝送する手段と、上記第３の判定手段に応答して、第４のブロック確認応答信号を伝送する手段とを含む。（ソース・ノードとして挙動する）本発明の第１の実施形態は、第２の判定手段に応答して、中継ノード送信要求信号を伝送する手段をさらに含む。
【００４６】
具体的には、宛先ノードとして挙動しているときには、図１０の装置の制御ロジック部分は、送信要求信号が受信されているかどうかを判定する手段と、第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号が受信されているかどうかを判定する手段と、第２のブロック確認応答信号および第３のデータが受信されているかどうかを判定する手段とを含む。（宛先ノードとして挙動する）本発明の第１の実施形態では、制御ロジックにおいて、第３の判定手段は、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含む。（宛先ノードとして挙動する）本発明の第２の実施形態では、制御ロジックにおいて、第１の判定手段は、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含む。（宛先ノードとして挙動する）図１０の装置のトランシーバ部分は、第１の判定手段に応答して、送信可信号および逆方向伝送要求信号を伝送する手段と、第２の判定手段に応答して、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求を伝送する手段と、第３の判定手段に応答して、第３のブロック確認応答信号を伝送する手段とを含む。
【００４７】
具体的には、中継ノードとして挙動しているときには、図１０の装置の制御ロジック部分は、チャネルをリッスンする手段と、リッスン手段に応答して、チャネル状態を推定する手段と、第１のノードから第１のデータを受信する手段と、第２のノードから第２のデータを受信する手段と、信号が受信されているかどうかを判定する手段と、チャネル状態が中継ノードとして働くのに十分であるかどうかを判定する手段とを含む。（中継ノードとして挙動する）本発明の第１の実施形態では、その信号は、中継ノード送信要求信号である。（中継ノードとして挙動する）本発明の第２の実施形態では、その信号は、送信要求信号である。（中継ノードとして挙動する）図１０の装置のトランシーバ部分は、上記第１および第２の判定手段に応答して、中継ノード送信可信号をマルチキャストする手段と、第１および第２の判定手段に応答して、ブロック確認応答信号および第３のデータをマルチキャストする手段とを含む。
【００４８】
本発明は、ハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサ、またはそれらの組合せといった様々な形態で実施することができることを理解されたい。本発明は、ハードウェアとソフトウェアの組合せとして実施されることが好ましい。さらに、ソフトウェアは、プログラム記憶装置に有形に実施されたアプリケーション・プログラムとして実施されることが好ましい。アプリケーション・プログラムは、任意の適当なアーキテクチャを備える機械にアップロードし、この機械によって実行することができる。この機械は、１つまたは複数の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）および１つまたは複数の入出力（Ｉ／Ｏ）インタフェースなどのハードウェアを有するコンピュータ・プラットフォーム上に実施されることが好ましい。コンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロ命令コードも含む。本明細書に記載する様々なプロセスおよび機能は、オペレーティング・システムを介して実行される、マイクロ命令コードの一部またはアプリケーション・プログラムの一部（あるいはそれらの組合せ）とすることができる。さらに、追加のデータ記憶装置や印刷装置など、その他の様々な周辺装置をコンピュータ・プラットフォームに接続することもできる。
【００４９】
さらに、添付の図面に示すシステム構成要素および方法ステップの一部はソフトウェアで実施することが好ましいので、システム構成要素（またはプロセス・ステップ）間の実際の接続は、本発明をプログラミングする方法によって異なっていてもよいことも理解されたい。本明細書の教示があれば、当業者なら、本発明の上記の実施態様または構成およびそれらに類似した実施態様または構成を思いつくことができるであろう。
【図１】
0005619281.tif 000002
【図２】
0005619281.tif 000003
【図３】
0005619281.tif 000004
【図４】
0005619281.tif 000005
【図５】
0005619281.tif 000006
【図６】
0005619281.tif 000007
【図７】
0005619281.tif 000008
【図８】
0005619281.tif 000009
【図９】
0005619281.tif 000010
【図１０】
0005619281.tif 000011