JP2013534120A

JP2013534120A - ネットワーク符号化３ノード双方向協働による伝送のためのメディア・アクセス制御レイヤ・プロトコルであるトリプル・プレイ・プロトコル

Info

Publication number: JP2013534120A
Application number: JP2013519634A
Authority: JP
Inventors: ガオ，ウエン; リ，ジアリン
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2010-07-13
Filing date: 2010-07-13
Publication date: 2013-08-29
Anticipated expiration: 2030-07-13
Also published as: JP5619281B2; US8913540B2; CN102986157A; US20130077555A1; WO2012008950A1; KR20130098276A; CN102986157B; EP2594031A1; KR101762472B1; BR112012031708A2; EP2594031B1

Abstract

送信要求信号を伝送すること、送信可信号および逆方向伝送要求信号が受信されているかどうかを判定すること、第１の判定に応答して、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送すること、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求信号が受信されているかどうかを判定すること、第２の判定に応答して、第２のブロック確認応答信号を伝送すること、第３のブロック確認応答信号が受信されているかどうかを判定すること、ならびに第３の判定に応答して、第４のブロック確認応答信号を伝送することを含む、方法および装置について記載する。さらに、チャネルをリッスンすること、リッスンに応答してチャネル状態を推定すること、信号が受信されているかどうかを判定すること、チャネル状態が中継ノードとして働くのに十分であるかどうかを判定すること、第１および第２の判定に応答して、中継ノード送信可信号をマルチキャストすること、ならびに第１および第２の判定に応答して、ブロック確認応答信号およびデータをマルチキャストすることを含む、方法および装置についても記載する。

Description

本発明は、ドラフトＩＥＥＥ８０２．１１ｎ標準の双方向伝送（通信）を補助する３ノード協働方式に関する。

マルチキャストおよびブロードキャストの分野では、有線ネットワークおよび／または無線ネットワークを介して、１つのサーバから複数の受信機にデータが伝送される。本明細書で用いるマルチキャスト・システムは、１つのサーバが同じデータを複数の受信機に同時に伝送し、これらの受信機が、全受信機の一部分または全体であるシステムである
。ブロードキャスト・システムは、１つのサーバが、同じデータを全ての受信機に同時に伝送するシステムである。すなわち、定義によれば、マルチキャスト・システムはブロードキャスト・システムを含むことができる。

１つのアクセス・ポイント（ＡＰ）およびいくつかのノードを有するマルチキャスト（ダウンリンク）およびマルチアクセス（アップリンク）チャネルを考える。ＩＥＥＥ８０２．１１ｎドラフト標準では、逆方向（ＲＤ）プロトコルを導入して、送信機会（ＴＸＯＰ）内の双方向トラフィック・フローの高速スケジューリングを行う。この逆方向プロトコルによって、ＴＸＯＰを得たノードは、ＴＸＯＰの制御権を維持したまま、別のノードの逆方向伝送を認可することができる。ノード間のチャネル状態が不適切（低品位）である場合には、これら２つのノード間の伝送の質が低下する。この質の低下は、データ転送速度の低下および／またはスループットの低下であることがある。

ＩＥＥＥ８０２．１１ｎドラフト標準では、逆方向（ＲＤ）プロトコルは、図１に示すように提案されている。ＩＥＥＥ８０２．１１ｎドラフト標準の逆方向プロトコルは、２つのノード間の双方向伝送のスケジューリングしか行わない。ＩＥＥＥ８０２．１１ＷＬＡＮ標準には、３ノード双方向伝送のための既存のスケジューリング・プロトコルはない。

第３のノードを２つのノードのための中継ノードとして作用させれば、有利であろう。しかし、このような第３の（中継）ノードを使用すると、２つのノード間の通信（伝送）が複雑になる。

本明細書で用いるノードは、局（ＳＴＡ）、移動装置、移動端末、デュアル・モード・スマート・フォン、コンピュータ、ラップトップ・コンピュータ、またはＩＥＥＥ８０２．１１ｎドラフト標準で動作可能な任意の他の等価な装置を含む（ただしこれらに限定されない）。

１つのアクセス・ポイント（ＡＰ）およびいくつかのノードを有するマルチキャスト（ダウンリンク）およびマルチアクセス（アップリンク）チャネルを考える。ＩＥＥＥ８０２．１１ｎドラフト標準では、逆方向（ＲＤ）プロトコルを導入して、送信機会（ＴＸＯＰ）内の双方向トラフィック・フローの高速スケジューリングを行う。この逆方向プロトコルによって、ＴＸＯＰを得たノードは、ＴＸＯＰの制御権を維持したまま、別のノードの逆方向伝送を認可することができる。これら２つのノード間の伝送が第３のノードである半二重中継ノード（ＲＮ）を介した協働を含むときには、状況がより複雑になるが、無線ネットワーク符号化を利用して、システムのスループットをさらに向上させることができる。本発明では、ネットワーク符号化３ノード双方向協働によって伝送をスケジューリングするＭＡＣレイヤにおけるトリプル・プレイ・プロトコルについて述べる。

送信要求信号を伝送すること、送信可信号および逆方向伝送要求信号が受信されているかどうかを判定すること、第１の判定に応答して、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送すること、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求信号が受信されているかどうかを判定すること、第２の判定に応答して、第２のブロック確認応答信号を伝送すること、第３のブロック確認応答信号が受信されているかどうかを判定すること、ならびに第３の判定に応答して、第４のブロック確認応答信号を伝送することを含む、方法および装置について述べる。また、送信要求信号が受信されているかどうかを判定すること、第１の判定に応答して、送信可信号、逆方向伝送要求信号を伝送すること、第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号が受信されているかどうかを判定すること、第２の判定に応答して、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求を伝送すること、第２のブロック確認応答信号および第３のデータが受信されているかどうかを判定すること、ならびに第３の判定に応答して、第３のブロック確認応答信号を伝送することを含む、方法および装置について述べる。さらに、チャネルをリッスンすること、リッスンに応答してチャネル状態を推定すること、信号が受信されているかどうかを判定すること、チャネル状態が中継ノードとして働くのに十分であるかどうかを判定すること、第１および第２の判定に応答して、中継ノード送信可信号をマルチキャストすること、ならびに第１および第２の判定に応答して、ブロック確認応答信号およびデータをマルチキャストすることを含む、方法および装置について述べる。

このようなＭＡＣレイヤ・トリプル・プレイ・プロトコルは、将来のＩＥＥＥ８０２．１１超高スループット（ＶＨＴ）標準に不可欠となる可能性がある。本発明のトリプル・プレイ・プロトコルの利点は、将来の標準に加える変更が最小限に抑えられるように、ＩＥＥＥ８０２．１１ｎドラフト標準に提案されている逆方向（ＲＤ）プロトコルに基づいて設計されており、逆方向互換性が高い点である。

本発明は、以下の詳細な説明を添付の図面と関連付けて読めば、最もよく理解される。添付の図面は、以下に簡単に説明する図面を含む。

逆方向伝送を要求するＩＥＥＥ８０２．１１ｎ標準に従って動作する２つのノードの動作を示す図である。ＲＮとの初期ハンドシェーキングを行わない、本発明のトリプル・プレイ・プロトコルの第１の実施形態を示す図である。ＲＮとの初期ハンドシェーキングを行う、本発明のトリプル・プレイ・プロトコルの第２の実施形態を示す図である。本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード_１の動作の流れ図である。本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード_２の動作の流れ図である。本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるＲＮの動作の流れ図である。本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード_１の動作の流れ図である。本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード_２の動作の流れ図である。本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるＲＮの動作の流れ図である。本発明の原理による例示的な装置のブロック図である。

本発明の３ノード双方向協働プロトコルでは、２つのノード、ノード_１およびノード_２は、両者の間に双方向トラフィック・フローがあるという点でそれぞれがソース・ノードにも宛先ノードにもなり、第３のノードＲＮが中継ノードとなって、双方向伝送を補助する。どのノードがソース・ノードになってもよく、どのノードが宛先ノードになってもよく、どのノードがＲＮになってもよいことに留意されたい。実際に、１つのノードが、同時にソース・ノード、宛先ノード、ＲＮとして動作することもできる。一般性を失わずに、ノード_１がＴＸＯＰを取得し、ノード_１がノード_２との双方向通信（トラフィック・フロー、伝送）を開始するものと仮定する。ただし、２つのノード間の直接リンクのチャネル状態が低品質であるため、協働中継ノード（ＲＮ）を利用して、両ノードにデータを転送し、両ノードにおける復号処理プロセスを補助する。復号処理は、データ伝送（通信）の受信後に一方のノードで行われる。復号処理は、データの信頼性を高めるために使用された符号化処理を逆に行うために使用される。例えば、リード・ソロモン／ビタビ符号化または単純なパリティ検査さえ使用して、伝送データの信頼性を高める。データは、オーディオ・データ、ビデオ・データ、マルチメディア・データ、コンテンツ・データ、またはその他の任意の形態のデータを含むことができる（ただしこれらに限定されない）。データは、パケットおよび／またはフレームにフォーマット化され使用されるが、これらの用語は、本明細書では、任意のフォーマット化方式を示すために交換可能に使用される。

無線ネットワーク符号化は、協働によってデータ伝送（通信）の信頼性を向上させることと、直接リンクを介した１方向伝送の所与のデータ転送速度を維持することとの間の兼ね合いである。中継ノード（ＲＮ）は、ノード_１およびノード_２の両方から（異なる時間スロットで、または同時に）データを受信し、これら２組のデータを混合（結合）して新たな１組のデータを生成し、この新たな混合データを両方のノードにブロードキャスト（マルチキャスト）する。各ノード（ソースおよび宛先）は、他方のノード（ソースおよび宛先）からの所望のデータの伝送と、ＲＮからの伝送とを受信する。その後、各ノードは、当該ノードが伝送（送出）したデータの知識に基づいて、所望のデータをまとめて復号処理する。

ＲＮにおける混合データは、２組の受信データによって決まる。ＲＮがデータを混合する方法は、ネットワーク符号化に基づく。当技術分野で既知のネットワーク符号化の例のいくつかと、可能なデータ混合方法とを、以下に与える。なお、以下に挙げる例は、全ての例を網羅したものではないことを理解されたい。

（１）データは、復号転送法に基づいてネットワーク符号化することができる、すなわち、２つの復号情報ビット・シーケンスのバイナリ付加とすることができる。

（２）データは、ソフト復号転送法に基づいてネットワーク符号化することができる、すなわち、２つのデータのソフト復号ビットの対数尤度比（ＬＬＲ）の組合せとすることができる。

（３）データは、増幅転送法または圧縮転送法に基づいてネットワーク符号化することができる、すなわち、２つの重み付けした受信信号の線形結合とすることができる。データは、中継ノード（ＲＮ）が両ノードから個々の信号を別々に受信するか、あるいは１つの混合信号を受信するかに応じて、ディジタル・ネットワーク符号化とアナログ・ネットワーク符号化にさらに分割することができる。

（４）データは、物理レイヤ・ネットワーク符号化することができる、すなわち、物理レイヤ領域の動作とすることができるが、バイナリ領域のバイナリ付加と等価である。

（５）データは、ノイズ除去転送法に基づいてネットワーク符号化することができる、すなわち可能な伝送データを表す別に設計されたコードブックを使用することができる。

本発明のトリプル・プレイ・プロトコルは、単一アンテナ技術および／またはマルチアンテナ技術と結合することができる。空間多重化、時空間ブロック符号、伝送ビーム形成および／または受信ビーム形成は、全ての伝送に適用することができる。

このトリプル・プレイ・プロトコルは、２つの実施形態を有する。第１の実施形態では、初期ハンドシェーキングを行わないが、第２の実施形態では、ノード（ノード_１、ノード_２およびＲＮ）間の初期ハンドシェーキングを行う。本発明のトリプル・プレイ・プロトコルでは、ノード_１のＴＸＯＰ内で、３つのノードからの伝送をスケジューリングすることを試みる。

ＩＥＥＥ８０２．１１ｎドラフト標準に記載されているフレーム・アグリゲーションおよびマルチ・トラフィックＩＤブロック確認応答（ＭＴＢＡ）が、本発明のトリプル・プレイ・プロトコルにおける前提とする。従って、本発明のシステムは、ＲＮが、２つのノード（ソースおよび宛先）によってデータを正しく復号処理されないサブフレームのみを処理する場合に、データ転送速度をさらに向上させることができる。

第１の実施形態は、ＲＮとの初期ハンドシェーキングを行わない、本発明のトリプル・プレイ・プロトコルである。この実施形態では、ノード_１とノード_２との間の２つの伝送を良好に受信できる任意のノードが、競合して中継ノード（ＲＮ）として機能することができる。図２は第１の実施形態を示す。本発明のトリプル・プレイ・プロトコルは、初期ハンドシェーキングを行わず、以下のように動作する。

（１）ノード_２は、送信可（ＣＴＳ）メッセージ（信号）を送信することによって、ノード_１から伝送（送信）された送信要求（ＲＴＳ）信号（メッセージ）の（ノード_１に対して）確認応答を行うとき、双方向通信である逆方向伝送の要求も行う。次いで、ノード_１は、データ_１およびブロック確認応答（ＡＣＫ）要求を伝送し、ノード_２にＲＤ伝送を認可する。本発明の別の実施形態では、ノード_１は、ノード_２からの明示的な要求がなくても、ノード_２にＲＤ伝送を認可することができる。

（２）ノード_２は、データ_１の正しく受信されなかったすべてのサブフレームに関する情報を含むブロックＡＣＫ（ＢＡ_１）をノード_１に戻す。ノード_２は、さらにそのデータ_２とその後にそのブロックＡＣＫ要求とを送信する。

（３）ノード_１は、データ_２の正しく受信されなかったすべてのサブフレームに関する情報を含むブロックＡＣＫ（ＢＡ_２）をノード_２に送信する。ノード_２がデータ_１中の全てのサブフレームを正しく受信していない、且つ／またはノード_１がデータ_２中の全てのサブフレームを正しく受信していない場合には、ノード_１は、Ｒｅｑｕｅｓｔ＿ＲＳ＿Ｔｏ＿Ｓｅｎｄ（Ｒ＿ＲＳ＿ＴＳ）メッセージ（信号）をポストして、ＲＮのヘルプを求める。

（４）ＲＮが、ノード_２におけるデータ_１の欠けている部分およびノード_１におけるデータ_２の欠けている部分を正しく受信しており、且つＲ＿ＲＳ＿ＴＳメッセージ（信号）を受信した場合には、Ｃｌｅａｒ＿ＲＳ＿Ｔｏ＿Ｓｅｎｄ（Ｃ＿ＲＳ＿ＴＳ）メッセージ（信号）を伝送（送出）して、自分がＲＮとして機能していることをノード_１およびノード_２に通知することができる。次いで、ＲＮは、データ_１およびデータ_２の欠けている部分を両方とも自分が受信したことを報告するためにブロックＡＣＫ（ＢＡ_１＆２）をマルチキャスト（ブロードキャスト）して、その後上記の例に挙げたような様々なネットワーク符号化方式の何れか１つに基づいて、データ_１およびデータ_２の欠けている部分の両方を結合したデータ_３をマルチキャスト（ブロードキャスト）する。ＲＮは、上記の例に挙げたような任意のネットワーク符号化方式を用いてデータの欠けている部分を混合（結合）することができるようにどんなデータが欠けている（正しく受信されなかった、失われた、破壊された、損傷した）のかを判定するために、ＢＡ_１およびＢＡ_２であるデータの欠けている部分の両方を受信することが前提となる。

なお、ＲＮは、ノード_２におけるデータ_１の欠けている部分の一部分およびノード_１におけるデータ_２の欠けている部分の一部分しか正しく受信していない場合には、上記の例示的なネットワーク符号化方式に基づいてこれらのデータの部分を結合して、それをデータ_３として伝送（通信、送信）することもできる。

ＢＡ_１＆２には、データ_１の正しく受信された欠けている部分のみに関する情報を含み、その後にデータ_２の正しく受信された欠けている部分のみに関する情報を含むように自動的に要約されたビットマップがある。ノード_１およびノード_２は両方ともこのビットマップに気づいて（のことを知って）いるので、ＲＮは、その伝送後にブロックＡＣＫ要求を伝送（通信、送出）する必要はない。

（５）ノード_２が最初にブロックＡＣＫ（ＢＡ_３２）を送出（伝送、通信）して、それがデータ_１の欠けている部分を受信したことを報告し、次いでノード_１が、ＢＡ_３１を通信（送出、伝送）して、それがデータ_２の欠けている部分のみを受信したことを報告する。本発明の代替実施形態では、ブロックＡＣＫを送信する順序が逆になる。

（６）ＲＮの伝送後、ノード_１およびノード_２の一方または両方が依然としていくつかのサブフレームの再伝送を必要としており、ＴＸＯＰが満了していない（期限切れになっていない）場合には、ノード_１およびノード_２の一方が、別のＲ＿ＲＳ＿ＴＳを伝送（送出、通信）して再度ヘルプを求め、前と同じノードまたは別のノードがＲＮとして機能することができ、または他方のソース・ノード（例えば、ノード_１が依然として欠けているデータを必要としており、先に別のＲ＿ＲＳ＿ＴＳメッセージ（信号）を送出した場合には、ノード_２が他方のソース・ノードとなる）が再伝送を行うことができる。

（７）制御フレームは、スケジューリングおよび信号送出において不可欠な役割を果たすので、データ・フレームより重要であるため、制御フレームは低いデータ転送速度を用いて送信（伝送、通信）し、その一方、データを高いデータ転送速度を用いて送信（伝送、通信）し、宛先における両者の受信に差が生じるようにすることが推奨される。その性質上、低いデータ転送速度の伝送の方が、信頼性が高くなるはずである。

（８）なお、本発明のトリプル・プレイ・プロトコルでは、ＲＮは、ノード_１とは無関係に指定されるが、実際には、このようなＲＮが存在しないことや、あるいは全てのＲＮが両方のデータ・セットまたは両方のデータ・セットの大部分をうまく復号できないこともあることに留意されたい。このような場合、ノード_１が一定期間待機して、それでもＣ＿ＲＳ＿ＴＳを受信しない場合、すなわちヘルプできるＲＮが存在しない場合には、ノード_１は、ノード_２がＢＡ_２において示す、ノード_２が正しく受信しなかったデータを、再伝送しなければならない。

第２の実施形態は、ＲＮとの初期ハンドシェーキングを行う、本発明のトリプル・プレイ・プロトコルである。この実施形態の第１の実施形態に優る利点は、以下の通りである。第１に、ノード_１およびノード_２は、専用のＲＮが存在していることを知っているので、それらの伝送（通信）をさらに積極的にすることができる。第２に、ＲＮは、両ノード（ソースおよび宛先）からの伝送に対して感度があり、データを復元して処理する。第３に、両ノード（ソースおよび宛先）から信号を受信することもあるその他のノードが、常にチャネルをリッスンしていなくてもよいので、緩和した（ｒｅｌａｘｅｄ）状態である。ただし、ＲＮを含め自由な状態（利用可能な状態）にあるその他のノードは、それらがＲＮとして機能する場合にそれらがネットワークにもたらす恩恵を最もよく推定することができるように、依然として何らかの方法でチャネルをリッスンし、他のノードからチャネル情報を取得する必要があることもある。さらに、ＲＮになるための競合は、単にデータの受信状態が良好であるだけでなく、むしろＲＮになろうとすることによるところが大きいので、他のノードを支える十分なチャネル品質（状態）または最良のチャネル品質（状態）を有していないノードが、ＲＮになる可能性もある。従って、チャネル状態に基づく良好なＲＮ競合機構が必要とされている。図３に第２の実施形態を示す。第２の実施形態の説明は、以下の通りである。

（１）ＲＮは、ノード_１のＲＴＳを受信した場合には、Ｃ＿ＲＳ＿ＴＳ（Ｃｌａｅｒ＿ＲＳ＿Ｔｏ＿Ｓｅｎｄ）フレームを送出（伝送、通信）して、ノード_２がＣＴＳを送信（伝送、通信）する前に、自分がＲＮとして機能していることを他のノードに通知することができる。ノード_１およびノード_２は、両方ともＣ＿ＲＳ＿ＴＳを受信することができなければならない。次いで、ノード_１およびノード_２は、これらのそれぞれとＲＮとの間のチャネル状態に基づいてそれぞれのデータ転送速度を決定することができる。チャネル状態が十分に良好である場合には、ノード_１およびノード_２は、両者の間の直接リンクの能力よりも高いデータ転送速度を使用することもできる。次いで、ノード_２は、双方向通信を求める要求であるそのＲＤ伝送要求とともに、そのＣＴＳを送出（伝送、通信）する。これで、ＲＮとのハンドシェーキングが終了する。

（２）次いで、ノード_１は、データ_１およびブロックＡＣＫ要求を伝送し、ノード_２にＲＤ伝送を認可する。ノード_２は、データ_１の正しく受信されなかった（失われた、破壊された、損傷した）すべてのサブフレームに関する情報を含むブロックＡＣＫ（ＢＡ_１）をノード_１に送信し、その後にそのデータ_２とそのブロックＡＣＫ要求を送信する。本発明の別の実施形態では、ノード_１は、ノード_２からの明示的な要求がなくても、ノード_２にＲＤ伝送を認可することができる。

（３）以降の処理は、ノード_１がＲ＿ＲＳ＿ＴＳフレームとその後のＲＮのＣ＿ＲＳ＿ＴＳフレームを送出する必要がなくなることを除けば、初期ハンドシェーキングを行わないトリプル・プレイ・プロトコルと同様である。

図４を参照するに、本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード_１の動作の流れ図である。４０５で、ノード_１は、ＲＴＳ信号（メッセージ）を伝送（通信、送出）する。４１０で、ノード_１が、ノード_１が伝送したＲＴＳメッセージ（信号）に応答するＣＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_１が、ＣＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信していない場合には、処理は、４１０に戻る。ノード_１が、ＣＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信している場合には、４１５で、ノード_１は、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可を伝送（通信、送出）する。４２０で、ノード_１が、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２を受信しているかどうかを判定するテストを実行する。ノード_１が、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２信号（メッセージ）を受信していない場合には、処理は、４２０に戻る。ノード_１が、ＢＡ_１、データ_２、およびブロックＡＣＫ要求_２信号（メッセージ）を受信している場合には、４２５で、ノード_１は、ＢＡ_２およびＲ＿ＲＳ＿ＴＳメッセージ（信号）を伝送（通信、送出）する。４２７で、Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されているかどうかを判定するテストを実行する。Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されている場合には、４３０で、ノード_１がＢＡ_３２メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_１がＢＡ_３２メッセージ（信号）を受信していない場合には、処理は、４３０に戻る。ノード_１が、ＢＡ_３２メッセージ（信号）を受信している場合には、４３５で、ノード_１はＢＡ_３１を伝送（通信、送出）する。ＢＡ_３１は、ＲＮからのブロードキャスト（マルチキャスト）で受信されるデータ_３に応答して送出される。ＢＡ_３２は、ＲＮからブロードキャスト（マルチキャスト）され受信されるデータ_３に応答して、ノード_２から受信される。Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されていない場合には、処理は、４２７に戻る。図４では、タイマを示していない。しかし、テストを実行する各ポイントでは、タイマを使用する。例えば、４０５でＲＴＳ信号（メッセージ）が送信（伝送）された後でタイマをセットし、４１０で、タイマが満了になる前にＣＴＳ信号（メッセージ）が受信されなかった場合に、ノード_１は、ＲＴＳ信号（メッセージ）を再送する。ＣＴＳ信号（メッセージ）が受信され、ＲＤ信号（メッセージ）が受信されない場合には、ノード_１は、次のステップに進み、ＲＤ要求信号（メッセージ）が存在していないと仮定するか、あるいはＲＤ要求信号（メッセージ）が暗黙であったと仮定する場合もある。同様に、４１５で、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可の後でタイマがセットされる。タイマが満了してもＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）が受信されていない場合には、ノード_１は、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を再伝送する。あるいは、タイマが満了してもＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）が受信されていない場合には、ノード_１は、Ｒ＿ＲＳ＿ＴＳ信号（メッセージ）を送出して、中継ノードのヘルプを要求する。同様に、４２７および４３０で、タイマをセットしてＣ＿ＲＳ＿ＴＳ信号（メッセージ）およびＢＡ_３２の受信を待機する。

次に、図５を参照するに、本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるノード_２の動作の流れ図である。５０５で、ノード_２がノード_１から伝送（通信、送出）されたＲＴＳメッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_２が、ノード_１から送出（伝送、通信）されたＲＴＳメッセージ（信号）を受信していない場合には、処理は、５０５に戻る。ノード_２が、ノード_１から送出（伝送、通信）されたＲＴＳメッセージ信号を受信している場合には、５１０で、ノード_２は、ＣＴＳメッセージ（信号）およびＲＤ伝送要求を伝送（通信、送出）する。５１５で、ノード_２がデータ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_２が、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可メッセージ（信号）を受信していない場合には、処理は、５１５に戻る。ノード_２が、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可メッセージ（信号）を受信している場合には、５２０で、ノード_２は、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２を伝送（通信、送出）する。５２５で、ノード_２が、ＲＮからブロードキャスト（マルチキャスト）されたＣ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ_１＆２およびデータ_３を受信しているかどうかを判定するテストを実行する。ノード_２が、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ_１＆２およびデータ_３を受信していない場合には、処理は、５２５に戻る。ノード_２が、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ_１＆２およびデータ_３を受信している場合には、５３０で、ノード_２は、ＢＡ_３２を伝送する。ＢＡ_３２は、ＲＮからのブロードキャスト（マルチキャスト）され受信されるデータ_３に応答して、ノード_２から受信される。図５では、タイマを示していない。しかし、テストを実行するほとんどのポイントでは、タイマを使用する。例えば、５１０でノード_２がＣＴＳおよびＲＤ伝送要求を伝送（通信、送出）した後でタイマをセットし、５１５で、タイマが満了になる前にデータ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可の信号（メッセージ）が受信されなかった場合に、ノード_２は、ＣＴＳおよびＲＤ伝送要求の信号（メッセージ）を再伝送する。同様に、５２５で、ノード_２がＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を伝送（通信、送出）した後でタイマをセットし、ノード_２がＣ＿ＲＳ＿ＴＳ、ＢＡ_１＆２およびデータ_３を受信していない場合に、ノード_２は、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を再伝送する。

次に、図６を参照するに、本発明のトリプル・プレイ・プロトコルの第１の実施形態の原理によるＲＮの動作の流れ図である。６０５で、ＲＮは、チャネルをリッスンし、チャネル状態を推定する。信号対雑音比（ＳＮＲ）や受信信号強度指標（ＲＳＳＩ）など（ただしこれらに限定されない）、様々な信号品質測度のうちいずれかの測度を使用して、チャネル状態を示すことができる。６１０で、ＲＮが、ノード_１からＲ＿ＲＳ＿ＴＳメッセージ（信号）を受信しているかどうかを判定するテストを実行する。ＲＮが、Ｒ＿ＲＳ＿ＴＳメッセージ（信号）を受信していない場合には、処理は、６０５に戻る。ＲＮが、Ｒ＿ＲＳ＿ＴＳメッセージ（信号）を受信している場合には、６１５で、（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好であるかどうかを判定するテストを実行する。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好でない場合には、処理は、６０５に戻る。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好である場合には、６２０で、ＲＮは、Ｃ＿ＲＳ＿ＴＳ、ＢＡ_１＆２およびデータ_３をブロードキャスト（マルチキャスト）する。上記で説明および議論したデータ_３は、データ_１とデータ_２の欠けている部分を混合したもの（組合せ）である。ＲＮは、ＲＮがブロックＡＣＫ、データ_１およびデータ_２において傍受（ｏｖｅｒｈｅａｒ）した情報に基づいてこの混合したもの（組合せ）を作成する。

次に、図７を参照するに、本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード_１の動作の流れ図である。７０５で、ノード_１は、ＲＴＳ信号（メッセージ）を伝送（通信、送出）する。７１０で、ノード_１が、ノード_１が伝送したＲＴＳメッセージ（信号）に応答するＣＴＳ信号（メッセージ）、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）およびＲＤ伝送要求メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_１が、ＣＴＳ信号（メッセージ）、Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信していない場合には、処理は、７１０に戻る。ノード_１が、ＣＴＳ信号（メッセージ）、Ｃ＿ＲＳ＿ＴＳ信号（メッセージ）およびＲＤ伝送要求メッセージ（信号）を受信している場合には、７１５で、ノード_１は、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可を伝送（通信、送出）する。７２０で、テストを実行して、ノード_１が、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２を受信しているかどうかを判定する。ノード_１が、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を受信していない場合には、処理は、７２０に戻る。ノード_１が、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を受信している場合には、７２５で、ノード_１は、ＢＡ_２を伝送（通信、送出）する。７３０で、ノード_１が、ＢＡ_３２メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_１が、ＢＡ_３２メッセージ（信号）を受信していない場合には、処理は、７３０に戻る。ノード_１が、ＢＡ_３２メッセージ（信号）を受信している場合には、７３５で、ノード_１は、ＢＡ_３１を伝送（通信、送出）する。ＢＡ_３１は、ＲＮからのブロードキャスト（マルチキャスト）で受信されるデータ_３に応答して送出される。ＢＡ_３２は、ＲＮからのブロードキャスト（マルチキャスト）で受信されるデータ_３に応答して、ノード_２から受信される。図７では、タイマを示していない。しかし、テストを実行する各ポイントでは、タイマを使用する。例えば、７０５でＲＴＳ信号（メッセージ）が送信（伝送）された後でタイマをセットし、７１０で、タイマが満了になる前にＣＴＳ信号（メッセージ）およびＣ＿ＲＳ＿ＴＳ信号（メッセージ）が受信されなかった場合に、ノード_１は、ＲＴＳ信号（メッセージ）を再送する。ＣＴＳ信号（メッセージ）およびＣ＿ＲＳ＿ＴＳメッセージ（信号）が受信され、ＲＤ信号（メッセージ）が受信されない場合には、ノード_１は、次のステップに進み、ＲＤ要求信号（メッセージ）が存在していないと仮定するか、あるいはＲＤ要求信号（メッセージ）が暗黙であったと仮定する場合もある。ＣＴＳ信号（メッセージ）が受信され、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）およびＲＤ信号（メッセージ）が受信されない場合には、ノード_１は、次のステップに進み、中継ノードが存在しておらず、ＲＤ要求信号（メッセージ）が存在しないと仮定するか、あるいはＲＤ要求信号（メッセージ）が暗黙であったと仮定する場合もある。同様に、７１５で、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可の伝送の後でタイマがセットされる。タイマが満了してもＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）が受信されていない場合には、ノード_１は、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を再伝送する。同様に、７３０で、タイマをセットしてＢＡ_３２の受信を待機する。

次に、図８を参照するに、本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるノード_２の動作の流れ図である。８０５で、ノード_２が、ノード_１が伝送（通信、送出）したＲＴＳメッセージ（信号）およびＲＮがブロードキャスト（マルチキャスト）したＣ＿ＲＳ＿ＴＳメッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_２が、ノード_１が送出（伝送、通信）したＲＴＳメッセージ（信号）およびＲＮがブロードキャスト（マルチキャスト）したＣ＿ＲＳ＿ＴＳメッセージ（信号）を受信していない場合には、処理は、８０５に戻る。ノード_２が、ノード_１が送出（伝送、通信）したＲＴＳメッセージ（信号）およびＲＮがブロードキャスト（マルチキャスト）したＣ＿ＲＳ＿ＴＳメッセージ（信号）を受信している場合には、８１０で、ノード_２は、ＣＴＳメッセージ（信号）およびＲＤ伝送要求を伝送（通信、送出）する。８１５で、ノード_２が、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可メッセージ（信号）を受信しているかどうかを判定するテストを実行する。ノード_２が、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可メッセージ（信号）を受信していない場合には、処理は、８１５に戻る。ノード_２が、データ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可メッセージ（信号）を受信している場合には、８２０で、ノード_２は、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２を伝送（通信、送出）する。８２５で、ノード_２が、ＲＮがブロードキャスト（マルチキャスト）したＢＡ_１＆２およびデータ_３を受信しているかどうかを判定するテストを実行する。ノード_２が、ＢＡ_１＆２およびデータ_３を受信していない場合には、処理は、８２５に戻る。ノード_２が、Ｃ＿ＲＳ＿ＴＳメッセージ（信号）、ＢＡ_１＆２およびデータ_３を受信している場合には、８３０で、ノード_２は、ＢＡ_３２を伝送する。ＢＡ_３２は、ＲＮからのブロードキャスト（マルチキャスト）され受信されるデータ_３に応答して、ノード_２によって伝送（通信、送出）される。図８では、タイマを示していない。しかし、テストを実行するほとんどのポイントでは、タイマを使用する。例えば、８１０でノード_２がＣＴＳおよびＲＤ伝送要求を伝送（通信、送出）した後でタイマをセットし、８１５で、タイマが満了になる前にデータ_１、ブロックＡＣＫ要求_１およびＲＤ伝送認可の信号（メッセージ）が受信されなかった場合に、ノード_２は、ＣＴＳおよびＲＤ伝送要求の信号（メッセージ）を再伝送する。同様に、８２５で、ノード_２がＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を伝送（通信、送出）した後でタイマをセットし、ノード_２がＢＡ_１＆２およびデータ_３を受信していない場合に、ノード_２が、ＢＡ_１、データ_２およびブロックＡＣＫ要求_２の信号（メッセージ）を再伝送する。

次に、図９を参照するに、本発明のトリプル・プレイ・プロトコルの第２の実施形態の原理によるＲＮの動作の流れ図である。９０５で、ＲＮは、チャネルをリッスンし、チャネル状態を推定する。信号対雑音比（ＳＮＲ）や受信信号強度指標（ＲＳＳＩ）など（ただしこれらに限定されない）、様々な信号品質測度のうちいずれかの測度を使用して、チャネル状態を示すことができる。９１０で、ＲＮが、ノード_１からＲＴＳメッセージ（信号）を受信（傍受）しているかどうかを判定するテストを実行する。ＲＮが、ＲＴＳメッセージ（信号）を受信（傍受）していない場合には、処理は、９０５に戻る。ＲＮが、ＲＴＳメッセージ（信号）を受信（傍受）している場合には、９１５で、（様々な信号品質測度の何れか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好であるかどうかを判定するテストを実行する。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好でない場合には、処理は、９０５に戻る。（様々な信号品質測度のいずれか１つまたは複数に基づいて）チャネル状態がＲＮとして働くのに十分に良好である場合には、９２０で、ＲＮは、Ｃ＿ＲＳ＿ＴＳをブロードキャスト（マルチキャスト）し、９２５で、ＲＮは、ＢＡ_１＆２およびデータ_３をブロードキャスト（マルチキャスト）する。上記で説明および議論したデータ_３は、データ_１とデータ_２の欠けている部分を混合したもの（組合せ）である。ＲＮは、ＲＮがブロックＡＣＫ、データ_１およびデータ_２において傍受した情報に基づいてこの混合したもの（組合せ）を作成する。

図１０は、本発明の原理による例示的な装置のブロック図である。いかなるノードも様々な時点でソース・ノード、宛先ノードおよび中継ノードとして挙動することができるので、図１０の装置は様々な時点でこれらのデバイス（装置）のうちのいずれかとなる。トランシーバが、データおよび任意の制御信号を実際に伝送および受信し、制御ロジックが、その他の全ての機能を実行する。

具体的には、ソース・ノードとして挙動しているときには、図１０の装置の制御ロジック部分は、送信可信号および逆方向伝送要求信号が受信されているかどうかを判定する手段と、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求信号が受信されているかどうかを判定する手段と、第３のブロック確認応答信号が受信されているかどうかを判定する手段とを含む。（ソース・ノードとして挙動する）本発明の第２の実施形態では、第１の判定手段は、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含む。ソース・ノードとして挙動する図１０の装置のトランシーバ部分は、送信要求信号を伝送する手段と、第１の判定手段に応答して、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送する手段と、第２の判定手段に応答して、第２のブロック確認応答信号を伝送する手段と、上記第３の判定手段に応答して、第４のブロック確認応答信号を伝送する手段とを含む。（ソース・ノードとして挙動する）本発明の第１の実施形態は、第２の判定手段に応答して、中継ノード送信要求信号を伝送する手段をさらに含む。

具体的には、宛先ノードとして挙動しているときには、図１０の装置の制御ロジック部分は、送信要求信号が受信されているかどうかを判定する手段と、第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号が受信されているかどうかを判定する手段と、第２のブロック確認応答信号および第３のデータが受信されているかどうかを判定する手段とを含む。（宛先ノードとして挙動する）本発明の第１の実施形態では、制御ロジックにおいて、第３の判定手段は、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含む。（宛先ノードとして挙動する）本発明の第２の実施形態では、制御ロジックにおいて、第１の判定手段は、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含む。（宛先ノードとして挙動する）図１０の装置のトランシーバ部分は、第１の判定手段に応答して、送信可信号および逆方向伝送要求信号を伝送する手段と、第２の判定手段に応答して、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求を伝送する手段と、第３の判定手段に応答して、第３のブロック確認応答信号を伝送する手段とを含む。

具体的には、中継ノードとして挙動しているときには、図１０の装置の制御ロジック部分は、チャネルをリッスンする手段と、リッスン手段に応答して、チャネル状態を推定する手段と、第１のノードから第１のデータを受信する手段と、第２のノードから第２のデータを受信する手段と、信号が受信されているかどうかを判定する手段と、チャネル状態が中継ノードとして働くのに十分であるかどうかを判定する手段とを含む。（中継ノードとして挙動する）本発明の第１の実施形態では、その信号は、中継ノード送信要求信号である。（中継ノードとして挙動する）本発明の第２の実施形態では、その信号は、送信要求信号である。（中継ノードとして挙動する）図１０の装置のトランシーバ部分は、上記第１および第２の判定手段に応答して、中継ノード送信可信号をマルチキャストする手段と、第１および第２の判定手段に応答して、ブロック確認応答信号および第３のデータをマルチキャストする手段とを含む。

本発明は、ハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサ、またはそれらの組合せといった様々な形態で実施することができることを理解されたい。本発明は、ハードウェアとソフトウェアの組合せとして実施されることが好ましい。さらに、ソフトウェアは、プログラム記憶装置に有形に実施されたアプリケーション・プログラムとして実施されることが好ましい。アプリケーション・プログラムは、任意の適当なアーキテクチャを備える機械にアップロードし、この機械によって実行することができる。この機械は、１つまたは複数の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）および１つまたは複数の入出力（Ｉ／Ｏ）インタフェースなどのハードウェアを有するコンピュータ・プラットフォーム上に実施されることが好ましい。コンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロ命令コードも含む。本明細書に記載する様々なプロセスおよび機能は、オペレーティング・システムを介して実行される、マイクロ命令コードの一部またはアプリケーション・プログラムの一部（あるいはそれらの組合せ）とすることができる。さらに、追加のデータ記憶装置や印刷装置など、その他の様々な周辺装置をコンピュータ・プラットフォームに接続することもできる。

さらに、添付の図面に示すシステム構成要素および方法ステップの一部はソフトウェアで実施することが好ましいので、システム構成要素（またはプロセス・ステップ）間の実際の接続は、本発明をプログラミングする方法によって異なっていてもよいことも理解されたい。本明細書の教示があれば、当業者なら、本発明の上記の実施態様または構成およびそれらに類似した実施態様または構成を思いつくことができるであろう。

Claims

送信要求信号を伝送するステップと、
送信可信号および逆方向伝送要求信号が受信されているかどうかを判定するステップと、
前記第１の判定に応答して、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送するステップと、
第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求信号が受信されているかどうかを判定するステップと、
前記第２の判定に応答して、第２のブロック確認応答信号を伝送するステップと、
第３のブロック確認応答信号が受信されているかどうかを判定するステップと、前記第２の判定に応答して、中継ノード送信要求信号を伝送するステップの１つと、前記第１の判定が、中継ノード送信可信号が受信されているかどうかを判定するステップをさらに含み、
前記第３の判定に応答して、第４のブロック確認応答信号を伝送するステップと、
を含む、方法。
送信要求信号を伝送する手段と、
送信可信号および逆方向伝送要求信号が受信されているかどうかを判定する手段と、
前記第１の判定手段に応答して、第１のデータ、第１のブロック確認応答要求信号および逆方向認可信号を伝送する手段と、
第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求信号が受信されているかどうかを判定する手段と、
前記第２の判定手段に応答して、第２のブロック確認応答信号を伝送する手段と、
第３のブロック確認応答信号が受信されているかどうかを判定する手段と、前記第２の判定に応答して、中継ノード送信要求信号を伝送する手段の１つと、前記第１の判定が、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含み、
前記第３の判定手段に応答して、第４のブロック確認応答信号を伝送する手段と、
を備える、装置。
送信要求信号が受信されているかどうかを判定するステップと、
前記第１の判定に応答して、送信可信号、逆方向伝送要求信号を伝送するステップと、
第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号が受信されているかどうかを判定するステップと、
前記第２の判定に応答して、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求を伝送するステップと、
第２のブロック確認応答信号および第３のデータが受信されているかどうかを判定するステップであって、前記第１の判定および前記第３の判定のうちの一方が、中継ノード送信可信号が受信されているかどうかを判定するステップをさらに含む、前記ステップと、
前記第３の判定に応答して、第３のブロック確認応答信号を伝送するステップと、
を含む、方法。
送信要求信号が受信されているかどうかを判定する手段と、
前記第１の判定手段に応答して、送信可信号、逆方向伝送要求信号を伝送する手段と、第１のデータ、第１のブロック確認応答要求信号および逆方向伝送認可信号が受信されているかどうかを判定する手段と、
前記第２の判定手段に応答して、第１のブロック確認応答信号、第２のデータおよび第２のブロック確認応答要求を伝送する手段と、
第２のブロック確認応答信号および第３のデータが受信されているかどうかを判定する手段であって、前記第１の判定手段および前記第３の判定手段のうちの一方が、中継ノード送信可信号が受信されているかどうかを判定する手段をさらに含む、前記手段と、
前記第３の判定手段に応答して、第３のブロック確認応答信号を伝送する手段と、
を備える、装置。
チャネルをリッスンするステップと、
第１のノードから第１のデータを受信するステップと、
第２のノードから第２のデータを受信するステップと、
信号が受信されているかどうかを判定するステップと、
前記リッスンに応答して、チャネル状態が中継ノードとして働くのに十分であるかどうかを判定するステップと、
前記第１および第２の判定に応答して、中継ノード送信可信号をマルチキャストするステップと、
を含む、方法。
前記第１および第２の判定に応答して、ブロック確認応答信号および第３のデータをマルチキャストするステップをさらに含み、該第３のデータが、前記第１のデータの破損部分と前記第２のデータの破損部分の組合せである、請求項５に記載の方法。
前記信号が、中継ノード送信要求信号および送信要求信号のうちの１つである、請求項５に記載の方法。
チャネルをリッスンする手段と、
第１のノードから第１のデータを受信する手段と、
第２のノードから第２のデータを受信する手段と、
信号が受信されているかどうかを判定する手段と、
前記リッスンに応答して、チャネル状態が中継ノードとして働くのに十分であるかどうかを判定する手段と、
前記第１および第２の判定に応答して、中継ノード送信可信号をマルチキャストする手段と、
を備える、装置。
前記第１および第２の判定手段に応答して、ブロック確認応答信号および第３のデータをマルチキャストする手段をさらに備え、該第３のデータが、前記第１のデータの破損部分と前記第２のデータの破損部分の組合せである、請求項８に記載の装置。
前記信号が、中継ノード送信要求信号および送信要求信号のうちの１つである、請求項８に記載の装置。