第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継する中継装置
【課題】 空間ダイバーシチ利得と前方誤り訂正の利点を活用することを可能にする、無線ネットワークにおける協調的な通信のためのより効率のよい概念を提供する。
【解決手段】 第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継する中継装置（１００）であって、データパケットを受信して、受信確認パケットを受信する受信ユニット（１１０）を備える中継装置（１００）である。中継装置（１００）は、ヘルプインジケータを提供するヘルプ検出部（１２０）と、ヘルプインジケータに応じてデータパケットを送信する送信ユニット（１３０）とをさらに備える。ヘルプが必要とされる状況は、中継装置（１００）と第２のパートナートランシーバとの間の第１の通信リンクが、第１と第２のパートナートランシーバとの間の第２の通信リンクより良好であるかどうかに基づいて検出される。
【解決手段】 第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継する中継装置（１００）であって、データパケットを受信して、受信確認パケットを受信する受信ユニット（１１０）を備える中継装置（１００）である。中継装置（１００）は、ヘルプインジケータを提供するヘルプ検出部（１２０）と、ヘルプインジケータに応じてデータパケットを送信する送信ユニット（１３０）とをさらに備える。ヘルプが必要とされる状況は、中継装置（１００）と第２のパートナートランシーバとの間の第１の通信リンクが、第１と第２のパートナートランシーバとの間の第２の通信リンクより良好であるかどうかに基づいて検出される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ネットワークの分野に関する。ここで、ネットワークは、固定インフラストラクチャネットワーク、アドホックネットワークまたはマルチホップネットワーク、及びこれらの組み合わせと考えられ、無線ローカルエリアネットワーク、無線メッシュネットワークまたは無線マルチホップネットワークとしても知られている。
【背景技術】
【０００２】
端末と該端末に関連付けられたアクセスポイント（ＡＰ）との間の確実で高速な通信は、あらゆる無線ローカルエリアネットワーク（ＷＬＡＮ）内において再送信の際の電力の浪費を回避し、共用の無線チャネルにおけるトラフィック量を最小限まで減らすための重要な問題の１つである。事実、何回も再送信を行うことは、通常、端末のバッテリーにより提供される貴重なエネルギーリソースの浪費である。また、再送信は、無線リソースを非効率的に利用し、ネットワーク内のトラフィック量が比較的多い場合には、トラフィック輻輳を引き起こす可能性もある。ＩＥＥＥ８０２．１１規格に基づくＷＬＡＮにおける送信機は、自己の変調スキームと符号化速度を現在のチャネル状態に合わせて、スループットを最大にする。変調スキームとコードレートの組み合わせはそれぞれ、信号対雑音比（ＳＮＲ）に対するデータスループットの曲線を有し、この曲線がさらに、受信機における所与のビット誤り率（ＢＥＲ）要件に最も適した変調スキームとコードレートの組み合わせを定める。
【０００３】
データレートの自動選択を実施する手法は、ベンダーによる設計の問題であるが、基本的には、統計ベースの手法とＳＮＲベースの手法との２つに分けることができる。一般的には、データレート選択のメカニズムに関わらず、ＡＰの近くに位置する端末が、より高次の変調とコードレートを利用することができる。したがって、ＡＰから離れたところに位置する端末よりも高いデータレートでデータの送受信を行うことができる。
【０００４】
ＷＬＡＮシステムにおいて低いデータレートで送受信を行う端末は、ネットワーク全体のスループットを低減する傾向にあり、高いデータレートで送信する端末の通信に悪影響を与えることは周知である（非特許文献１参照）。これは、データフレームが正常に送信されるまでに要する時間が、スループット、遅延、ジッタなどのサービス品質パラメータに関して評価されるＷＬＡＮシステムの性能の背後にある主な要因だからである。例えば、輻輳したＩＥＥＥ８０２．１１ａ／ｇ（ＷＬＡＮ）ネットワークにおける６Ｍｂｐｓのデータレートでの大きなデータフレームの再送信は、５４Ｍｂｐｓのデータレートでの同じデータフレームの再送信よりもネットワークの全般的な性能にはるかに大きな影響を及ぼす。
【０００５】
無線ネットワークにおける協調的な（cooperative）通信は、近年、学会でも業界でも大いに注目を引いている新しい研究分野である（非特許文献２参照）。協調的なネットワークでは、２つ以上のノードがそれらのデータを共用し、仮想アンテナアレイとして共同で送信を行う。図１４ａから１４ｃに、従来技術のいくつかの概念を示している。図１４ａには、単純で一般的な送信概念である、受信機１４１０へ直接送信を行う送信機１４００が示されている。図１４ｂには、中継局１４２０を介して受信機１４１０と通信する送信機１４００が示されている。この例では、送信機１４００が中継局１４２０へデータパケットを送信し、中継局１４２０が、このデータパケットを受信機１４１０へさらに転送する。
【０００６】
図１４ｃには、中継局１４２０と送信機１４００と受信機１４１０とが関与する別の通信の概念が示されている。図１４ｂと図１４ｃに示す概念の違いは、図１４ｃの受信機１４１０が、送信機１４００から直接送信されたものと、送信信号の中継局１４２０から中継されたバージョンとを受信することである。図１４ｃでは受信機１４１０が、同じ送信の２つのバージョン、すなわち、送信機１４００から送信されたバージョンと中継局１４２０から送信されたバージョンとを受信するため、ダイバーシチ利得が得られる。図１４ｃの送信機１４００と中継局１４２０とは、仮想アンテナアレイとして働く。これは、送信機１４００と中継局１４２０とが、個々に得られるはずのものより高いデータレートとダイバーシチを得ることを可能にする。類似の概念が、非特許文献３〜５にも記載されている。
【０００７】
例えば、ＷＬＡＮシステムにおける協調的ネットワークの概念の実用化は、単一のアンテナを備えた端末が、他のピア端末と協働して多入力多出力（ＭＩＭＯ）システムと同様の時空間ダイバーシチを提供することができるため、ネットワーク全体の性能を向上させる大きな可能性を有する。従来技術から分かる伝送の概念には、モバイル環境では適切な中継局を効率よく特定することができず、そのため、仮想アンテナアレイまたはＭＩＭＯ伝送の利益を活用することができないという問題がある。
【０００８】
例えば、ＩＥＥＥ８０２．１１ベースの機構から、従来技術の一部として、二方向と四方向のフレーム交換が知られている。二方向フレーム交換では、任意の単一データフレームの正常な復号化および受信が、受信機から送信機へ返信される受信確認（ＡＣＫ：acknowledgement）制御により確認できる。送信機は、ＡＣＫフレームを受信しない場合に、分散制御用フレーム間隔（DIFS: Distributed-coordination-function inter-frame space）と、しばしばTime_Slot×[0,CW]と表される、別の時間間隔の範囲内のランダムバックオフ期間との和により定まる期間の後にそのデータフレームを再送信する。この場合、ＩＥＥＥ８０２．１１プロトコルで規定されているように、Ｔｉｍｅ＿Ｓｌｏｔは、物理層におけるタイムスロットの期間を表し、ＣＷは、［ＣＷｍｉｎ，ＣＷｍａｘ］の範囲内のコンテンションウィンドウであり、ＣＷｍｉｎは最小のコンテンションウィンドウであり、ＣＷｍａｘは最大のコンテンションウィンドウである。パラメータＣＷは、値ＣＷｍｉｎから開始し、パケットが再送信されるたびに２倍にされ、特に複数回の再送信が必要なときには高い遅延を生じさせる。
【０００９】
第２の伝送のメカニズムは、前述のものと同じデータ及び受信確認フレームの交換を使用し、さらにそれに先行して送信要求（RTS: request to send）フレームとそれに続く受信準備完了（CTS: clear to send）フレームを含む二方向フレーム交換が行われる、四方向フレーム交換である。ＲＴＳフレーム及びＣＴＳフレームの交換は、隠れノードの問題に対処することを目的としている。これは、送信機がそのチャネル感知範囲外にある第３のノードの送信により受信機に生じる干渉をいう。
【００１０】
前述のように、データフレーム送信後のＡＣＫフレームを受信しないことは、常に送信の失敗と認識され、よって、その後に同じデータフレームの再送信が行われる。ＡＣＫフレームの不受信には、以下の２つの理由がある。
・例えば、受信機における巡回冗長検査（CRC: cyclic redundancy check）の計算により検出されるデータパケットのエラーである。このエラーは、２つの理由によって引き起こされる可能性がある。第１の理由は、送信機と受信機との間の不良なチャネル状態によって生じるビット誤りである。第２の理由は、フレームを同時に送信しようとする２つ以上の端末により生じる衝突によるものである。
・例えば、元の送信機におけるＣＲＣの計算により検出される、受信機から送られたＡＣＫフレームのエラーである。このＡＣＫフレームの受信エラーは、通常は不良なチャネル状態によって生じるビット誤りに起因するが、パケット衝突によって生じることもある。
【００１１】
ＡＣＫフレームの不受信の背景にある理由に関わらず、元のデータフレームは再送信される。一般に、ＡＰから遠くに位置する端末は、より悪いチャネル状態を有する傾向があり、よって、ＡＰのより近くに位置する端末より低いデータレートで動作する。さらに、ＡＰからより離れたところに位置する端末は、同じセル内の他の端末にとって隠れノードとなる確率がより高い。これらの理由から、一般に、低いデータレートの端末による再送信は、高いデータレートの端末による再送信よりもはるかに望ましくない。従来技術の概念には、特に、低いデータレートの端末が、これらのチャネル状態が劣るためにより多くの再送信を必要とするという欠点がある。これにより、セル容量またはシステム容量の点での全体的なシステム性能またはセル性能が劣化する。
【００１２】
非特許文献６において、主要な観点から見た不良な媒体アクセス制御（MAC: medium access control）の問題を軽減する新たな手法が提案されている。著者らは、ユーザ協調によって提供される空間ダイバーシチを導入することにより、既存のＩＥＥＥ８０２．１１無線ローカルエリアネットワークＭＡＣプロトコルを機能強化する、協調的ＭＡＣ（ＣＭＡＣ）と呼ばれる新しいＭＡＣプロトコルを提案している。このスキームでは、相手の端末が、ＡＰによる受信確認を受信していない他の端末により送られたフレームを再送信する。再送信されるフレームは、ＩＥＥＥ８０２．１１ｅ規格によって定められている機構に基づき、より高いチャネルアクセス優先順位を有する特別なキューに格納される。この方法では、相手選択の方法も前方誤り訂正も考慮されていない。さらに、このスキームでは、アップリンクチャネル、すなわち、端末からアクセスポイントまでの送信についてのみ定められている。しかしながら、ダウンリンク、すなわちアクセスポイントから端末までの伝送方向には、依然として既知の欠点がある。一般には、ダウンリンクトラフィックの方がはるかに大きいため、これは大きな欠点となり得る。
【００１３】
著者らは、さらに、無線チャネルでの信頼性を向上させるための前方誤り訂正（FEC=forward error correction）スキームを有するＭＡＣの修正、いわゆるＦＣＭＡＣ（FCMAC: FEC CMAC）も提案している。静的で適応可能なＦＥＣアルゴリズムは、無線ネットワークの性能を改善することもあり、これらのオーバーヘッドが元となるチャネル誤りに正しくマッチしない場合、特に、経路損失が大幅に変動するときには、無線ネットワークの性能を低下させることもある。提案されたスキームは、前述のような協調的通信ＭＡＣに基づくものであり、協調的な前方誤り訂正のスキームを導入している。データフレームはいくつかのリードソロモン符号化データブロックに分割され、これらの符号化データブロックは、それぞれの相手が符号化データブロックの１つだけを処理するようにいくつかの相手により独立して送信される。相手選択の機構は定義されておらず、やはり、提案されたスキームは、アップリンクチャネルだけにしか適用できない。ダウンリンクチャネル、すなわち、アクセスポイントから端末までの伝送には依然として既知の欠点がある。
【００１４】
非特許文献７には、例えばＩＥＥＥ８０２．１１媒体アクセス制御プロトコルの性能を改善するための無線ネットワークにおけるユーザ協調の概念が提示されている。この新しいＭＡＣプロトコルは、ＩＥＥＥ８０２．１１ｂのマルチレート機能を利用し、アクセスポイントから遠く離れた移動局が、中間局を中継局として使って、より高速で送信することを可能にする。この新しいＭＡＣプロトコルの２つの改良の概要が説明されており、両方とも、ネットワーク全体のスループットを増大させ、平均パケット遅延を低減することができる。
【００１５】
図１５ａと図１５ｂに提案された方法を示している。図１５ａと図１５ｂには、受信機Ｓdへデータパケットを送信しようとしている送信機Ｓsが示されている。両者の中間には中継局Ｓhがある。中継局Ｓhは、提案のスキームによれば送信機Ｓsが受信機Ｓdへデータパケットを送信するのを支援することができる。図１５ａと図１５ｂには、さらに、チャネル競合（チャネルコンテンション）に関与する別の２つの端末ＳＴＡ１とＳＴＡ２とが示されている。前述の四方向フレーム交換スキームによれば、送信機ＳsがＲＴＳパケットを送信し、そのＲＴＳパケットは、受信機Ｓdと中継局Ｓhが受信することになる。次いで、中継局Ｓhは、送信機Ｓsへヘルプ可能（HR: help ready）パケットを送ることにより、中継局Ｓhを介した経路が、受信機Ｓdへの直接の経路よりも良好なデータレートを提供することを送信機Ｓsに対して示すことができる。次いで、図１５ｂによれば、送信機Ｓsは、まず中継局Ｓhへデータを送信し、その直後に中継局Ｓhが受信機Ｓdへそのデータを転送する。次いで、受信機ＳdはＡＣＫフレームを送ることにより、送信機Ｓsに対してデータを正常に受信したことを受信確認する。この論文に記載されている概念には、伝送経路がただ１つしかなく、受信機にダイバーシチ利得を提供できないという欠点がある。
【００１６】
このスキームは、宛先に直接フレームを送るか、それとも中継ノードを使ってフレームを送るかを選択する方法を無線ネットワーク内の各局に対して提供する。最適な経路を選択する基準は宛先までの総伝送時間であり、これは、関与するノード間の相対的なチャネル状態の測定によって提供される。この論文で定められている機構は、マルチホップネットワークにおける伝送に最適な経路を選択することに焦点を当てている。この機構には、再送信の機構も、前方誤り訂正協調の使用も考慮されていないという欠点がある。さらに、提案された方法には、ＨＲパケットを介して、ネットワーク内での追加オーバーヘッドが導入され、そのための貴重な伝送リソースが必要となるという欠点もある。
【００１７】
図１６は、従来のＩＥＥＥ８０２．１１規格、すなわち、従来技術の無線ＬＡＮにおいて実施される従来技術の伝送を示している。図１６には、アクセスポイントＡＰと、３つの端末Ｓ１、Ｓ２およびＳ３と、時間軸とが示されている。端末Ｓ１は、時刻ｉ＝１にアクセスポイントＡＰへデータパケットを送信しようと試みる。これは、時間軸上の時刻ｉ＝１にも示されている。端末Ｓ１からアクセスポイントＡＰへの第１の送信は失敗し、よって、アクセスポイントはデータパケットを受信しない。しかしながら、このパケットは、チャネルをオーバーヒアしている他の２つの端末Ｓ２およびＳ３が正常に受信する。受信機において、すなわち、アクセスポイントＡＰにおいて、フレームチェックシーケンス（FCS: frame check sequence）が考慮され、すなわち、受信パケットのチェックサムが評価される。チェックサムが、パケットが正常に受信されなかったことを示す場合、データパケットは破棄され、または削除される。時間軸においてデータパケットの第１の送信の後に示されているように、端末Ｓ１は、分散制御用フレーム間隔（DIFS: Distributed-coordination-function inter-frame space）と呼ばれる時間にわたって待機し、その後、コンテンションウィンドウ機構に従ってバックオフ期間が発生する。次の送信時刻ｉ＝２において、端末Ｓ１は、同じデータパケットの第１の再送信を行う。最初の送信の場合と同様に、データパケットは、アクセスポイントＡＰが正常に受信せず、その直後に端末Ｓ１は再度１つの直接フレーム間隔にわたって待機し、新しいランダムバックオフ期間を生じさせ、その場合、第２の再送信ではコンテンションウィンドウの範囲が２倍となる。端末Ｓ１が受信確認フレームを受信しないときは常に再送信が行われる。すべての再送信は、同じパケット損失の危険を有する。
【００１８】
したがって、この従来技術の概念には、通信リンクが効率よく利用できないという問題がある。考察した例では、「チャネルをオーバーヒアするプロミスキャスモード」である端末Ｓ２とＳ３は、最初の２つの送信を正常に受信するが、これらのパケットは破棄される。
【００１９】
図１６に示した例では、端末Ｓ１は、時間軸に示されている第３の試行ｉ＝３においてデータパケットを正常に送信する。よって、データパケットの第３の送信の後、アクセスポイントＡＰから受信確認フレームを受信する。この例は、従来技術の概念が無線リソースを効率よく利用できないことを示すものである。アクセスポイントＡＰにおいてフレームチェックシーケンスが正常に計算できない理由は、例えば、不良なチャネル状態、すなわち、ビット誤りが生じていたり、同時に送信を行う２つ以上の端末によりパケット衝突が生じていたりするためである。別の障害点が、端末Ｓ１における受信確認のフレームチェックシーケンスの計算であり、これもまた、不良なチャネル状態とビット誤りの発生、または送信の衝突により失敗することがある。図１６の例に示されているように、送信が正常に行われないときは常にコンテンションウィンドウが２倍となり、ランダムバックオフ期間が計算される。
【００２０】
非特許文献８は、集中型と分散型両方の無線ネットワークにおいてダイバーシチを得る効率のよい手法として、ユーザ協調に焦点を当てている。著者らは、準静的なレイリーフェージング条件の下で符号化協調システムを検討し、相手選択の範囲または相手選択の問題を吟味している。著者らは、協調が有利となるユーザ間およびユーザ宛先間のチャネル品質の条件を見出している。著者らは、フレーム誤り率をメトリックに用いて、個々のチャネルコードが使用されるときの、直接送信に対する協調送信の相対的な性能改善を評価するユーザ協調利得（Ｇ）を定めている。
【００２１】
著者らは、ユーザ宛先間の平均受信信号対雑音比（ＳＮＲ）の関数である協調決定パラメータ（ＣＤＰ）を導入し、協調が有用であるか否か（Ｇ＞１またはＧ＜１）が、ユーザ間のリンク品質ではなく、ＣＤＰのみに左右されることを示している。著者らは、ＣＤＰの解析を使ってユーザ協調利得を吟味し、ユーザが、協調利得を最大にするために可能な相手の中からどのようにして選択できるかについての洞察を提供している。著者らは、まず、一方の相手または両方の相手が宛先において高い平均受信ＳＮＲを有するときの漸近的性能を考察している。次いで、著者らは、協調が任意のＳＮＲについて有利となるべき、ユーザと宛先の位置の条件を提供する。著者らは、これらの協調領域を示し、最適な相手選択のための幾何学的な条件を研究している。また、著者らは、システム協調利得を定義し、両方のユーザにとっての協調利益を示している。理論的な結果は、数値例によって検証されている。
【００２２】
非特許文献９では、送信元が中継局へデータをブロードキャストし、中継局の一部または全部が協調してビーム形成してデータを宛先へ転送する、協調的な無線ネットワークを考察している。ネットワークは、全般的な障害の制約を被る。著者らは、協調的な通信のための標準的手法を、以下の２つの点において一般化している。１つ目は、これらの手法は、チャネル状態情報（ＣＳＩ）を得るコストを明示的にモデル化し、考慮に入れるということである。２つ目は、これらの手法は、中継局のためのより一般的で、かつ単純な選択の規則を考慮し、中継局間で最適なものを計算する。これらの規則は、特殊な事例として、この文献で提案されているいくつかの中継選択の基準を含む。これらは、各リンクが同一の平均チャネル利得を有する均一な事例での解析的結果を提示するものである。この事例では、最適な送信スキームが、単純であって効率よく計算できることが示されている。数値結果は、ＣＳＩの訓練とフィードバックのコストは大きいが、それでもなお中継協調が有益であることを示している。
【００２３】
別の関連する従来技術の文献として非特許文献１０〜１３がある。
【００２４】
【非特許文献１】M. Heusse, F. Rousseau, G. Berger-Sabattel and A. Duda, "Performance Anomaly of IEEE 802.11b", Proc. of INFOCOM 2003
【非特許文献２】A. Nosratinia, T. E. Hunter, and A. Hedayat, "Cooperative Communication in Wireless Networks", IEEE Communications Magazine, October 2004
【非特許文献３】A. Sendonaris, E. Erkip, and B. Aazhang, "User cooperation diversity-Part I: System Description", IEEE Trans. Commun., vol.51, no.11, pp.1927-1938, November 2003
【非特許文献４】A. Sendonaris, E. Erkip, and B. Aazhang, "User cooperation diversity- Part II: Implementation aspects and performance analysis", IEEE Transaction on Communications, vol.51, no.11, pp.1939-1948, November 2003
【非特許文献５】J. N. Laneman and G. W. Wornell, "Energy-efficient antenna sharing and relaying for wireless networks", in Proc. IEEE Wireless Communications and Networking Conference (WCNC), September 2000, pp. 7-12
【非特許文献６】S. Shankar, C. Chou and M. Ghosh, "Cooperative Communi-cation MAC (CMAC)-A New MAC Protocol for Next Generation Wireless LANs", in Proc. of the IEEE International Confer-ence on Wireless Networks, Communications and Mobile Com-puting 2005
【非特許文献７】P. Liu, Z. Tao and S. Panwar, "A Cooperative MAC Protocol for Wireless Local Area Networks", in Proc. Of IEEE In-ternational Conference on Communications 2005
【非特許文献８】“Cooperative Regions and Partner Choice in Coded Coop-erative Systems", IEEE transactions on communications, vol. 54, no. 7, July 2006, Z. Lin, E. Erkip and A. Stefanov
【非特許文献９】“Energy-Efficient Cooperative Relaying over Fading Channels with Simple Relay Selection" by R. Madan, N. B. Mehta, A. F. Molisch, and J. Zhang
【非特許文献１０】"Multiuser Detection for Cooperative Networks and Performance Analysis", L. Venturino, X. Wang, and M.Lops, IEEE transactions on signal processing, vol. 54, no. 9, September 2006
【非特許文献１１】"A Simple Distributed Method for Relay Selection in Cooperative Diversity Wireless Networks, based on Re-ciprocity and Channel Measurements", A. Bletsas, A. Lippman, and D. P. Reed
【非特許文献１２】"Grouping and Partner Selection in Cooperative Wire-less Networks" by A. Nosratinia and T. E. Hunter
【非特許文献１３】“Cooperative Source and Channel Coding for Wireless Video Transmission", Y. Wang, E. Erkip and H. Y. Mok, Polytechnic University, Brooklyn, New York, http://vision.poly.edu:8080/~hoiyin/project1.htm
【発明の開示】
【発明が解決しようとする課題】
【００２５】
本発明の目的は、空間ダイバーシチ利得と前方誤り訂正の利点を活用することを可能にする、無線ネットワークにおける協調的な（cooperative）通信のためのより効率のよい概念を提供することである。
【課題を解決するための手段】
【００２６】
上記目的は、請求項１に記載の中継装置と、請求項２５に記載のデータパケットを中継する方法とによって達成される。
【００２７】
上記目的は、第１のパートナートランシーバから第２のパートナートランシーバへ送信されるデータパケットを中継する中継装置であって、データパケットを受信し、第２のパートナートランシーバがデータパケットを正常に受信したときに第２のパートナートランシーバから第１のパートナートランシーバへ送信される受信確認パケットを受信する受信ユニットを備えた中継装置によって達成される。この中継装置は、ヘルプが必要とされる状況が検出された場合にヘルプインジケータを提供するヘルプ検出部と、ヘルプインジケータに応じてデータパケットを送信する送信ユニットとをさらに備えている。ヘルプが必要とされる状況は、中継装置（１００）と第２のパートナートランシーバとの間の第１の通信リンクが、データパケットから得られる情報によって評価される、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクよりも良好であるかどうかに基づいて検出される。
【００２８】
上記目的は、第１のパートナートランシーバから第２のトランシーバへ送信されるデータパケットを中継する方法であって、データパケットを受信するステップと、第２のパートナートランシーバがデータパケットを正常に受信したときに第２のパートナートランシーバから第１のパートナートランシーバへ送信される受信確認パケットを受信するステップとを含む方法により達成される。この方法は、中継装置（１００）と第２のパートナートランシーバとの間の第１の通信リンクを評価するステップと、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクを評価するステップとをさらに含む。この方法は、ヘルプが必要とされる状況が検出されるとヘルプインジケータを提供するステップと、ヘルプインジケータに応じて、元のデータパケットまたはデータパケットを符号化したバージョンを送信するステップとをさらに含む。ヘルプが必要とされる状況は、第１の通信リンクが、データパケットから得られる情報によって評価される第２の通信リンクよりも良好であるかどうかに基づいて検出される。
【００２９】
本発明は、無線ネットワークにおいて、符号化と空間ダイバーシチを活用して低いデータレートを有する端末による再送信を回避することができ、したがって、全般的なネットワーク効率またはスループットを増大させることができるという知見に基づくものである。本発明に係る装置は、パートナートランシーバまたはアクセスポイントまでのより良好なリンクを有する端末が、低いデータレートの端末により送受信される、復号化に失敗したフレームを符号化したバージョンを再送信することを可能にする。最初に低いデータレートのチャネルを通して送信された符号化データフレームを迅速に再送信すれば、平均伝送時間を低減することができ、よって、ネットワークの全般的スループットが増大し、例えばＷＬＡＮシステムなどで利用されるリアルタイムアプリケーションの重要なパラメータである伝送遅延が低減される。協調スキームは、低いデータレートと不良なチャネル状態を有する端末の代わりに、元の形、またはより短い符号化バージョンとしてパケットを再送信する、高いデータレートと良好なチャネル状態を有する端末を有する。
【００３０】
本発明は、ＩＥＥＥ８０２．１１に基づくＷＬＡＮにおいて符号化再送信を実施する方法を含む。相手の選択は、オンザフライ、例えば、端末間の信号対雑音比（ＳＮＲ）、データレート、パケット損失比などの相対的なチャネル品質関連パラメータの比較を通じて同じ端末により分散スキームで行われる。または、例えば、文献「S. Mangold et al., "IEEE 802.11e Wireless LAN for Quality of Service", Proceedings of European Wireless 2002」などに記載されているＩＥＥＥ８０２．１１ｅによって提供されるものなどのチャネルアクセス優先順位決定によって制御することもできる。本発明の一実施形態では、符号化再送信の相手のオンザフライの自己選択は、ＩＥＥＥ８０２．１１プロトコルで定義されている物理層コンバージェンス手順（PLCP: physical layer convergence procedure）ヘッダのデータレートフィールドをオーバーヒアすることにより得られる、送信元端末または第１のパートナートランシーバのデータレートに基づくものである。
【００３１】
本発明の別の実施形態では、符号化再送信の相手選択を、トラフィッククラスに基づくものとすることができる。その場合、符号化再送信の相手選択は、トラフィッククラスごとに別々に、すなわち、例えば、ボイスオーバＩＰ（VoIP: voice over internet protocol）などの遅延に弱いサービスを実行する相手間で行うこともでき、または、以前の再送信回数に応じて動的にトラフィッククラスをアップグレードすることにより、または一般に符号化再送信データフレームのための他の何らかの種類のアクセス優先順位決定の機構を組み込むことにより実行することもできる。トラフィッククラスは、ＩＥＥＥ８０２．１１のサービス品質拡張に関するＩＥＥＥ８０２．１１ｅの規格で定義されている。ＩＥＥＥ８０２．１１ｅトラフィッククラスと共に、新たなトラフィッククラスを、特に、符号化再送信パケットのために生成することもでき、例えば、一実施形態では、データフレームが、再送信されるたびにより高いアクセス優先順位クラスにアップグレードされる。さらに、再送信データフレームの優先順位決定のための新しい動的自動再送信要求（ARQ: automatic repeat request）機構の生成を考慮することもできる。
【００３２】
本発明の実施形態は、例えば、ＷＬＡＮシステムなどにおいて送信されるトラフィックの量が、再送信をより確実にすることにより低減できるという利点を提供する。さらに、本発明に係る中継装置または本発明に係る方法は、例えば、ＷＬＡＮなどにおける総スループットを、再送信に費やされる時間量を低減することにより増大させる。これが可能となるのは、高いデータレートの局が、低いデータレートの局に代わって符号化パケットを再送信できるからである。さらに、本発明の手法は、単一のアンテナだけを備える端末のために、ＭＩＭＯのような特徴を有する協調的伝送システムを作り出し、あるいは、仮想アンテナアレイを生成できる。本発明の実施形態は、さらにＩＥＥＥ８０２．１１プロトコルへの任意選択の変更により、ＷＬＡＮシステムの実際的な協調的再送信スキームを定義し、規定するという利点も提供する。さらに、本発明の実施形態では、前方誤り訂正符号化が容易に実施できる。本発明の実施形態は、両方の伝送方向において、アップリンク、すなわち端末からアクセスポイントへ送信するときも、ダウンリンク、すなわちアクセスポイントから端末へ送信するときにも、大きな利益と利点を提供する。本発明の手法は、ネットワークに信号交換のオーバーヘッドを導入せずにオンザフライで相手選択を可能にする。
【００３３】
本発明の実施形態をについて、添付の図面を使って詳細に説明する。
【発明を実施するための最良の形態】
【００３４】
図１は、本発明に係る中継装置１００の一実施形態のブロック図を示している。図１には、受信ユニット１１０と、ヘルプ検出部１２０と、送信ユニット１３０とが示されている。第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継する中継装置１００は、データパケットを受信して、第２のパートナートランシーバがデータパケットを正常に受信したときに第２のパートナートランシーバから第１のパートナートランシーバへ送信される受信確認パケットを受信する受信ユニット１１０を備えている。
【００３５】
以下では、本発明のいくつかの実施形態について説明する。インフラストラクチャシナリオでは、アップリンクとダウンリンクの伝送方向が区別されている。本発明に係る中継装置１００は、第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを受信する。本発明の実施形態は、例えば、アップリンクにおいて、いくつかの端末または送信機が１つのアクセスポイントまたは受信機へ信号を送信するＷＬＡＮシステムなどを指す。このシナリオでは、第１のパートナートランシーバは、アクセスポイントまたは第２のパートナー受信機へデータパケットを送信しようとする端末となる。本発明に係る中継装置１００は、端末内またはアクセスポイント内に統合することもでき、したがって、実施形態では、すべての端末またはアクセスポイントを本発明に係る中継装置１００とすることができる。ダウンリンクでは、アクセスポイントまたは送信機が、端末または受信機へデータパケットを送信し、よって、このシナリオでは、第１のパートナートランシーバはアクセスポイントであり、第２のパートナー受信機は端末である。前述の場合と同様に、本発明に係る中継装置は、任意の端末内またはアクセスポイント内に統合することもできる。
【００３６】
データパケットの正常な受信は、例えば、ビット誤り率、信号対雑音比、フレームチェックシーケンスなどを評価することにより、第２のパートナートランシーバが検出できる。第２のトランシーバがデータパケットの受信に成功したか否かを検出するための様々な機構が考えられる。本発明に係る中継装置１００にとって重要なのは、第２のトランシーバがデータパケットの正常な受信を確認していないことである。
【００３７】
さらに、中継装置１００は、ヘルプが必要とされる状況が検出された場合にヘルプインジケータを提供するヘルプ検出部１２０を備えている。その場合、ヘルプが必要とされる状況は、中継装置１００と第２のパートナートランシーバとの間の第１の通信リンクが、データパケットから得られる情報によって評価される、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクより良好であるかどうかに基づいて検出される。ヘルプが必要とされる状況は、第２のトランシーバが受信確認パケットにより正常な受信を確認していないことに密接に結びついている。本発明の実施形態では、このようなヘルプが必要とされる状況は、例えば、正常な受信を確認しなかった第２のトランシーバへデータパケットを送信しようとしている第１のトランシーバにより作り出され得る。一実施形態では、ヘルプ検出部１２０は、さらに、受信確認パケットが、データパケットの受信後ある時間内に受信しない場合に終了するタイマーを用いたタイマー終了に基づいてヘルプが必要とされる状況を検出することもできる。
【００３８】
中継装置１００が、第１のパートナートランシーバと第２のパートナートランシーバとに対して、第１のパートナートランシーバと第２のパートナートランシーバとの間のチャネル状態より良好なチャネル状態または通信リンクを有する場合であって、中継装置１００がデータパケットを正常に受信している場合、中継装置は、第１のトランシーバのためにそのデータパケットまたはそのデータパケットを符号化したバージョンを再送信することにより貴重な伝送リソースを節約することができる。中継装置１００と第１のパートナートランシーバと第２のパートナートランシーバとの間の通信チャネルの状態は、様々な評価メトリックによって決定できる。一実施形態では、データパケットから明示的に得られる、すなわちデータパケットの制御情報部分またはヘッダ部分に含まれる情報によって通信リンクを評価することができる。ＷＬＡＮを示す一実施形態では、データレートをパケットのヘッダから読み取ることができる。
【００３９】
本発明の一実施形態では、評価メトリックが、データパケット自体から決定でき、例えばＷＬＡＮネットワークシナリオでは、評価メトリックが、使用されるデータレートに対応する物理層コンバージェンス手順ヘッダから決定できる。
【００４０】
別の実施形態では、データパケットサイズ、伝送期間、変調スキーム、伝送帯域幅を求めることによる通信リンク品質の推測など、データパケットから暗黙的に得られる情報によって通信リンクを評価することを利用することもできる。
【００４１】
ヘルプインジケータに応じたデータパケットの転送または送信は、本発明に係る中継装置１００に備えられている送信ユニット１３０によって実行できる。
【００４２】
前述のように、中継装置１００、あるいはヘルプ検出部１２０は、中継装置１００と第１及び第２のパートナートランシーバとの間の通信リンク、または、第１のパートナートランシーバと第２のパートナートランシーバとの間の通信リンクを、データレート、信号対雑音比、信号対雑音干渉比、パケット損失比、ビット誤り率、平均再送信回数またはトラフィッククラスのうちの１つまたはこれらの組み合わせに基づいて評価することができる。この評価に基づき、本発明の別の実施形態では、パートナートランシーバが決定される。すなわち、すべての潜在的なトランシーバがパートナートランシーバであるとは限らない。潜在的なパートナートランシーバの選択は、本発明の一実施形態では、通信リンクの評価メトリックに基づくものとすることもできる。本発明の一実施形態では、ヘルプインジケータが、パートナートランシーバから受信したデータパケットについてのみ提供され、この場合、パートナートランシーバは、中継装置１００と第２のパートナートランシーバとの間の第１の通信リンクが、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクより良好であるという基準を満たす。一実施形態では、第１の通信リンクは、受信データパケットから読み取られたデータレートによって評価できる。第２の通信リンクは、中継装置１００においてローカルに作成されたデータパケットの以前の送信に使用された自己のデータレートまたは自己の平均データレートによって評価することもできる。一実施形態では、ヘルプが必要とされる状況が、自己のデータレートまたは自己の平均データレートが、受信データパケットから読み取られたデータレートより高い場合にのみ検出される。別の実施形態では、ヘルプが必要とされる状況を決定するときに、第１のパートナートランシーバと中継装置との間の第３の通信リンクの評価も考慮できる。第３の通信リンクは特に、例えば、ヘルプが必要とされる状況が、ダウンリンク送信にも有効であるアップリンク送信から決定される場合に評価することができる。すなわち、一実施形態では、２つのパートナートランシーバの間で相互にヘルプが必要とされる状況を確立できる。
【００４３】
本発明の別の実施形態では、本発明に係る中継装置１００は、別のトランシーバから受信したものでなく、ローカルに作成されて送信が予定されている、送信できる別のデータパケットを有する場合にのみ、ヘルプインジケータを作成し、あるいは受信したデータパケットを転送する。送信ユニット１３０は、この実施形態では、データパケットと別のデータパケットを一緒に、例えばピギーバックスキームで送信することができる。さらに、本発明に係る中継装置１００は、本発明の実施形態では、受信確認パケットを第２のパートナートランシーバから受信した場合、または第１のパートナートランシーバからデータパケットを受信した後、一定の破棄時間が経過した場合に受信データパケットを破棄することができる。別の実施形態では、本発明に係る中継装置１００は、一定の再送信時間が経過した後に送信を繰り返すことができ、あるいは、送信ユニット１３０が、しかるべく再送信を実行することもできる。
【００４４】
本発明の別の実施形態では、再送信インジケータを、例えばビットまたはフラグとして含めることができる。これらの実施形態では、転送されたデータパケットは、送信がすでに協調的な再送信であることを他のトランシーバへ指示するために、本発明に係る中継装置１００によりフラグが立てられる。本発明の別の実施形態では、フラグは、おそらく本発明に係るいくつかの中継装置からなる、ある中継経路を使用可能とするためのカウンタまたは識別番号で置き換えられている。中継経路またはマルチホップ経路の長さを制限するようにカウンタを制限することもできる。さらに、本発明の別の実施形態では、本発明に係る中継装置１００は、マルチ受信確認パケット（multi-acknowledgement packet）または合成受信確認パケット（combined-acknowledgement packet）を受信することができる。このとき、複数のデータパケットまたはあるデータパケットと別のデータパケットとが同時に確認され、その場合、一方のデータパケットを中継されたパケットとし、他方をローカルで作成されたパケットとすることもできる。
【００４５】
本発明の別の実施形態では、本発明に係る中継装置１００は、受信データパケットをトランスコードすることができる。この実施形態は、前方誤り訂正符号化を行い、ここで中継装置１００は例えば、パリティビット、またはデータパケットをトランスコードしたバージョンだけを転送することもできる。一実施形態では、元のデータパケットを再送信するときにはチェイス合成法（chase combining）、または、元のデータパケットをトランスコードしたバージョンが提供されるときには増分的冗長性合成法（incremental redundancy combining）が、第２のパートナートランシーバにおいて使用可能となる。別の実施形態では、トランスコードが、中継装置１００と第２のパートナートランシーバとの間のチャネル品質または通信リンクの品質に適合している。
【００４６】
一実施形態は、アクセスポイントまでの良好な通信リンクを有する第１の端末が音声セッションを実行し、したがって、短い高速伝送のみを行うＷＬＡＮシナリオにおけるものとすることができる。より悪い通信リンクを有する第２の端末は、ビデオコールからアクセスポイントに向けて、より長い伝送を利用してより低速でビデオパケットを送信しようと試みる。第１の端末が第２の端末からビデオパケットを正しく受信したが、アクセスポイントは失敗した場合、第１の端末は、第２の端末から受信したパケットを転送することができる。ヘルプが必要とされる状況を検出するためのリンクの条件は満たされている。その理由は、第１の端末が第２の端末より高いデータレートをサポートし、それを、第１の端末によるビデオデータパケットのパケットヘッダなどから読み取ることができるからである。実施形態は、より高いシステム容量といくつかのサービスでの適用範囲の拡張という利点を提供することが上記の例から分かり、この場合、第１の端末が本発明に係る中継装置１００として機能しなければ、第２の端末はビデオコールを確立することができない。
【００４７】
図２は、本発明に係る中継装置と本発明に係る方法とを詳述するシナリオ例を示している。図２には、８つの各データレート区域が、６Ｍｂｐｓから５４Ｍｂｐｓまでに及ぶ異なるデータレートの表示を有する同心円で表された、一般的なＩＥＥＥ８０２．１１ａ／ｇ ＷＬＡＮの一例が示されている。いくつかの端末がカバー領域全体に分散しており、以下の例では、そのうちのノード１と表されている端末とノード２と表されている端末と、中心にあるアクセスポイントＡＰだけを説明する。端末のデータレートは、それぞれのチャネル状態に適合するように調整されたデータレートが生じた後は、比較的安定しているものと仮定する。端末は、例えば、最後のＮ個の送信データフレームの所与のデータレートＤにおける正常送信の割合がＫ％を上回る場合には、安定したデータレートＤを有するものとみなされる。本発明の以下の説明では、「安定したデータレート」という用語は、任意の関与する端末における前述の要件を満たすデータレートを指すものとする。よって、この例では、アクセスポイントは第２のパートナートランシーバとして機能し、ノード１は第１のパートナートランシーバであり、ノード２は中継装置である。
【００４８】
本発明に係る方法と本発明に係る中継装置とによれば、DR_thr_up以上の安定したデータレートを有するあらゆる端末は、以下の式を満たすようにより低いデータレートを有する端末の代わりにデータフレームを再送信することができる。
DR_thr_up=α・DR_tx
ここで、α＞１であり、DR_txはより低いデータレートを有する端末のデータレートであり、DR_thr_up≦Max_Data_Rateである。よって、[DR_thr_up, Max_Data_Rate]の範囲内のデータレートを有するあらゆる端末は、送信に失敗した端末の潜在的な再送信機または中継装置となり得る。本発明の一実施形態では、通信リンク間の関連がデータレートのメトリックによって評価できる。例えば、ＩＥＥＥ８０２．１１ａまたはｇの場合、パラメータMax_Data_Rateは５４Ｍｂｐｓに設定される。
【００４９】
DR_txは、例えば、他の端末がアクセスポイントＡＰへ送信したデータフレームの物理層コンバージェンス手順（ＰＬＣＰ）ヘッダをオーバーヒアすることによって得られる。すなわち、本発明のこの実施形態では、通信リンクのメトリックに関する情報は、データパケット自体に含まれている。ＰＬＣＰは常に、物理層によってサポートされる最低データレート、例えば、ＩＥＥＥ８０２．１１ａまたはｇの場合には６Ｍｂｐｓで送信される。
【００５０】
わかりやすくするために、図２に示した例ではα＝２が選択されており、ノード１からＡＰへ６Ｍｂｐｓで送信されたデータフレームは、アクセスポイントＡＰにより正常に復号化できないものと仮定する。しかしながら、別の実施形態では、αを動的に調整することもできることに留意すべきである。αは、例えばネットワークまたはトラフィック条件に応じて動的に調整することもできる。例えば、アクセスポイントＡＰの巡回冗長検査（ＣＲＣ）の計算が成功しない場合、アクセスポイントＡＰは受信確認フレームを送らず、例えばT_apと呼ばれる一定の期間（この期間は、実施上の問題であるが、基本的にはこの説明の後段で扱う許容される符号化再送信の回数Ｍにより定めるべきである）にわたって特別なバッファ内に復号化に失敗したデータフレームを保持し、データフレームを正常に復号化するために、ノード１からの通常の再送信、または中継ノードまたは中継装置からのフレームのＦＥＣ符号化（FEC: forward error correction）再送信を待つ。これが、正常に復号化できないパケットが受信機において直ちに削除される８０２．１１のような従来のシステムとの大きな違いである。ノード１が送信したデータフレームをオーバーヒアした、以下の３つの条件を満たすすべての端末は、ノード１が送信したデータフレームを符号化したバージョンを作成し、中継装置として機能することができる。
・α＝２とした場合、DR_thr_upが１２Ｍｂｐｓ以上の安定したデータレートを有すること。
・任意の条件として、送信されるのを待つ少なくとも１つのパケットをバッファ内に有すること。この条件は、絶対的に必要なものではない。その理由は、送信すべきパケットを有さない端末は、他の端末によって送信され正常に復号化されたパケットを自己の送信バッファに追加し、よって、８０２．１１で定義されるチャネルコンテンションに関与することができるからである。どちらを選択するかは実施上の問題であるが、ピギーバックスキームの方が、帯域幅利用の点からみればより効率的である。
・ノード１が送信したパケットのＣＲＣをオーバーヒアし、正常に計算していること。
【００５１】
前述の条件を満たした端末の１つが、アクセスポイントＡＰによってノード１に送られた受信確認フレームをオーバーヒアせず、ノード１の前に、共通のCSMA/CA（CSMA/CA: Channel Sensing Multiple Access / Collision Avoidance）によってそのチャネルに偶然アクセスした場合、その端末は、ノード１によって送られたＦＥＣ符号化データフレームをアクセスポイントＡＰへ送信する前に自己のデータフレームにピギーバックする。上記の３つの条件は、この実施形態では、ヘルプの指示を作成する本発明に係る中継装置に備えられているヘルプ検出部の要件を定義するものであることに留意されたい。図２のノード２は、前述の３つの要件を満たし、ノード１の送信失敗後にチャネルを取得する。すなわち、アクセスポイントＡＰがノード１へ受信確認フレームを送らなかったものと仮定する。ノード２は、自己のデータフレームに対して、ノード１が以前に送信したＦＥＣ符号化フレームをピギーバックし、次いで、この１つで２つのデータフレームをアクセスポイントＡＰへ送信する。アクセスポイントＡＰは、このパケットを正常に復号化できた場合、２つの一連の受信確認フレーム、すなわちノード１に対するものとノード２に対するものとを送る。
【００５２】
代替的に、ノード２のデータフレームとノード１のデータフレームとの両方の正常なＣＲＣ計算を確認するマルチ受信確認フレームを送ることもできる。両方、すなわちノード１とノード２の確認済みデータフレームのＭＡＣヘッダが含まれている、この新しい種類のマルチ受信確認フレームでは、ＩＥＥＥ８０２．１１受信の動作の変更が必要とされるはずである。その理由は、８０２．１１では単一のＭＡＣ宛先アドレスフィールドしか存在せず、ノードがそれ自体にアドレス指定されていないすべてのフレームを破棄するからである。ノード１とノード２とが送信したデータフレームを符号化したバージョンを以前に格納したすべての相手ノードまたはパートナートランシーバは、受信確認フレームをオーバーヒアし次第、または、例えばT_bufferなどのバッファリング時間が経過した場合、これらのデータフレームを特別なバッファから削除しなければならない。ノード１はアクセスポイントＡＰから受信確認フレームを受信したが、以前にノード１のデータフレームを格納したノード１の中継ノードのいくつかが受信していない場合、これらの中継ノードは、ノード１のデータフレームを符号化したバージョンを再送信しようとする。アクセスポイントＡＰは、ノード１への受信確認フレームを送ることにより、これらの中継ノードのそれぞれに対してノード１のデータフレームの再送信が不要であると応答する必要がある。任意の最適化として、すでに正常に送信されたノード１への受信確認フレームをオーバーヒアしていない可能性のある他の再送信の相手によって生じる受信確認フレームの重複を回避するために、対応するノード１のデータフレームのシーケンス制御フィールドを受信確認フレームが含むことができる。これら既存のＩＥＥＥ８０２．１１プロトコルへの任意の拡張を以下にまとめる。
【００５３】
一般には、提案するスキームでは、パリティビットだけの送信を許容する任意の系統的な符号化を使用できる。すなわち、リードソロモン符号（例えば、文献「Bernard Sklar, "Digital Communications", Prentice Hall International, 2001」参照）、または系統的なレート可変パンクチャターボ符号（RCPT: Rate Compatible Punctured Turbo Codes）（文献「D. N. Rowitch and L. B. Milstein, "On the performance of hybrid FEC/ARQ systems using rate compatible punctured turbo (RCPT) codes", IEEE Trans. On Comm., vol. 48, pages 948-959, June 2000」参照）を使用できる。１つの可能な方法は、中継端末に対して、例えば最近のT_past_up秒間の現在の送信機に関連する総送信回数に対する正常な送信回数の比率に基づいて、特定のモードの誤り訂正機能、すなわちコードレートを選択させることである。正常な送信回数の比率は、データフレームヘッダに定義された特別なフィールドを介して送信機ノードから直接得ることもでき、送信機によって送られたデータフレームとそれらの受信確認フレームとをオーバーヒアすることができるような、送信側ノードの送信範囲内に位置する任意の端末においてローカルで計算することもできる。よって、あらゆる中継端末は、最近のT_past_up秒間にオーバーヒアしている任意の所与の送信側端末の正常な送信回数の比率に対する誤り訂正機能の表を有している。
【００５４】
このような表は、事前に構成された、すなわち固定的のものでもよいし、動的なものでもよい。以下の表は、リードソロモン符号を使ってパリティビットが送信される場合の固定的で事前に構成された表の一例である。最近のT0秒間（T0≧T_past_up）に送信が検出されなかったとき、表には隣接端末からの送信が全く格納されず、あるいは、これに関連付けられたエントリが表から削除される。
【表１】
【００５５】
図３、図４及び図５は、それぞれアップリンク伝送を考察する、本発明の一実施形態としての中継端末と、対応する関連のアクセスポイント（第２のパートナートランシーバ）と、送信側の第１のパートナートランシーバとに対応するフローチャートの例である。
【００５６】
図３は、本発明に係る中継装置の一実施形態のフローチャートである。このフローチャートは、ステップ３１０から開始し、続いてステップ３１２で中継装置が他の端末からのアップリンクフレームをオーバーヒアする。他の端末からのアップリンクフレームをオーバーヒアするステップの後、中継装置は、例えばステップ３１４でＣＲＣを評価することにより、別の端末からのアップリンクフレームが正しくオーバーヒアされたかどうかを検出する。ＣＲＣが正しくなかった場合、ステップ３１６でバックオフ状態の残りのタイムスロットの数を表すカウンタＮが減分され、その直後にステップ３１８でバックオフ状態がチェックされる。バックオフ状態Ｎがまだ、ステップ３１８でＮ＝０として示されているトリガに到達していない場合、中継装置はステップ３２０でチャネルがビジーであるか否かをチェックする。チャネルがビジーである場合、中継装置はステップ３１２でそのチャネルを使用する別の端末からのアップリンクフレームをオーバーヒアしようと試みる。チャネルがビジーでない場合、中継装置は、ステップ３１６にループしてカウンタを減分し、最終的にはバックオフ状態の終了に到達する。
【００５７】
中継装置が首尾よく正しいＣＲＣを有する別の端末からのアップリンクフレームをオーバーヒアした場合、ステップ３２２でその送信機のＭＡＣアドレスを記憶する。次いで、本発明に係る方法によれば、中継装置は、ステップ３２４でアクセスポイントからその特定の送信機への受信確認をオーバーヒアしようと試みる。受信確認フレームがアクセスポイントからオーバーヒアされた場合、中継装置はステップ３２６で送信バッファが空であるか否かをチェックする。アクセスポイントから受信確認フレームを受信しない場合、ステップ３２８で中継装置は対応する送信機がパートナートランシーバであるか否かを検証する。これは、中継装置のアクセスポイント方向のデータレートが、各送信機のアクセスポイントへのデータレートより高いかどうかをチェックすることによりステップ３２８に示されている。この要件が満たされない場合、中継装置はステップ３２６で送信バッファの状況を監視する。要件が満たされた場合、ステップ３３０で各送信機が正常な送信回数の比率に従って誤り訂正機能を設定し、その後ステップ３３２でのＦＥＣ符号化フレームを作成するステップと、ステップ３３４でのTime_to_bufferと呼ばれる一定の時間にわたって符号化フレームを記憶するステップが続く。ステップ３３４に続いてステップ３２６で送信バッファが監視される。
【００５８】
ステップ３２６では送信バッファが監視され、中継装置は送信バッファが空である限りこの状態に留まる。送信バッファ内に利用可能なデータがある場合、ステップ３２６に続いてステップ３１８でバックオフタイマーまたはバックオフ状態Ｎが検証される。ステップ３１８でバックオフ状態の終わりに到達した後、すなわち変数Ｎが値０に到達した後、中継装置はステップ３３６で各送信機からアクセスポイントに向けて以前に再送信が実行されているかどうかをチェックする。各送信機により再送信が行われている場合、中継装置はステップ３３８でＦＥＣ符号化フレームが削除される。各送信機からアクセスポイントへの再送信が行われていない場合、中継装置はステップ３４０で他の任意のノードまたは中継装置が各送信機の代わりに以前に符号化送信をしたかどうかをチェックする。別のノードが、すでに各送信機の代わりに符号化したバージョンを送信している場合、中継装置はステップ３３８で各送信機のＦＥＣ符号化フレームを削除する。以前に符号化送信が行われていない場合、中継装置はステップ３４２で制限時間T_bufferを超過しているか否かをチェックする。すでに時間T_bufferが経過している場合、中継装置はステップ３３８でＦＥＣ符号化フレームを削除する。まだT_bufferが経過していない場合、中継装置はステップ３４４で自己のデータフレームに対して、各送信機のピギーバック符号化フレームを加えたものを送信する。中継装置は、ステップ３３８で偶然にＦＥＣ符号化フレームを削除している場合には、ステップ３４６で自己のデータフレームだけを送信し、ステップ３４６での送信またはステップ３４４での送信の後、送信バッファを監視するステップ３２６の状態に戻ることになる。
【００５９】
図４は、アップリンク伝送時の例示的なアクセスポイント（第２のパートナートランシーバ）の動作に関連するフローチャートである。アクセスポイントは、ステップ４１０のデータフレーム受信から開始し、その直後にステップ４１２で正しいＣＲＣを計算しようと試みることになる。アクセスポイントは、ステップ４１２で首尾よく正しいＣＲＣを算出した場合、データフレームの送信機への通常の受信確認フレームの送信を含む通常の動作であるステップ４１４に進む。ステップ４１４からアクセスポイントはステップ４１０に戻り、次のデータフレームの受信を開始する。ステップ４１２でアクセスポイントが正しいＣＲＣを計算できなかった場合、アクセスポイントはステップ４１６で破損したフレームを特別なバッファに格納し、その直後に状態をステップ４１８に変更して再送信またはピギーバック符号化再送信を待つ。再送信もピギーバック符号化再送信も検出されない間は、アクセスポイントはステップ４１８に留まる。再送信またはピギーバック符号化再送信が検出された場合、アクセスポイントはステップ４２０で破損したフレームを修復しようと試み、これに成功した場合にはステップ４２２に進み、そこで送信元ノードへ受信確認フレームを送り、あるいは、送信元ノードへ複数のＡＣＫフレームを送ることもできる。ステップ４２２から、アクセスポイントＡＰはステップ４１４に進んで通常の動作を継続する。ステップ４２０でアクセスポイントが首尾よく破損したフレームを修復できなかった場合、アクセスポイントはステップ４１８に戻り、そこで次の再送信、あるいは次のピギーバック符号化再送信を待つ。
【００６０】
図５は、対応する送信機、すなわち、アップリンク伝送時の第１のパートナートランシーバのフローチャートである。送信機は、ステップ５１０から開始してデータフレームを送信する。ステップ５１０に続き、送信機はステップ５１２でTime_Outと呼ばれる一定の時間にわたってアクセスポイントからの受信確認フレームを待つ。対応する受信確認フレームを受信した場合、送信機はステップ５１４に進み、すなわち、通常の動作を続行し、ステップ５１４からステップ５１０に戻り、そこで次のデータフレームが送信される。
【００６１】
受信確認フレームを受信せずにTime_Outが経過した場合、送信機はステップ５１６でランダムバックオフ時間が計算され、再送信が開始される。ステップ５１６のランダムバックオフ時間の計算後、送信機はステップ５１８に進み、そこでバックオフ期間の間待機し、アクセスポイントによって送られたすべての受信確認フレームをチェックして、失敗したデータフレームについての起こり得る協調的な受信確認を検出する。その理由は、潜在的に中継ノードまたは装置が失われたデータフレームを転送できるからである。協調的な受信確認フレームを受信せずにバックオフ期間が経過した場合、ステップ５２０で再送信が開始され、送信機はステップ５１４の通常の動作に進む。ステップ５１８でバックオフ期間の間に協調的な受信確認フレームを受信した場合、ステップ５２２で各フレームが送信バッファから削除され、送信機は５１４の通常の動作に進む。
【００６２】
アクセスポイント（第２のパートナートランシーバ）から、協調的な端末、すなわち中継装置により符号化されて再送信されたデータフレームの受信確認フレームを受信しなかった場合、送信された１つで２つのデータフレームをオーバーヒアした別の中継ノードが再送信を行い、よって、最初のデータパケットを含む完全な１つで２つのフレームの符号化データパケットを提供することができる。これが可能なのは、このようなノードがコンテンションにおいてチャネルに最初にアクセスする場合と、データフレームのいわゆる再送信フラグが１に設定されていて第２の再送信が許容されている間である。任意の再送信フラグがない場合、本発明の一実施形態では符号化再送信が単一の元のパケット送信を修復するためだけに使用される。図２で、ノード１がアクセスポイントＡＰへのパケット送信に成功しないものと仮定された場合、ノード２はノード１の受信確認フレームがないことを認識した後、ノード１の符号化フレームを自己のデータフレームにピギーバックし、アクセスポイントＡＰへ１つで２つのデータフレームを送る。この送信もまた、不良なチャネル状態またはパケット衝突により成功しないと想定される場合、少なくともノード２のデータレートと同程度のデータレートを有する第３のノードであって、その送信バッファにパケットを有し、ノード２が送信した１つで２つのパケットを正常にオーバーヒアしているノードが、１つで２つのフレームの符号化データをピギーバックし、１つで３つのフレームを送信し、すでに中継されたデータパケットを中継する中継装置として動作することができる。
【００６３】
このため、第３のノードは、パケットの符号化されていない部分、すなわちノード２のデータを符号化し、パケットの符号化されている部分、すなわちノード１の符号化データをそのまま保持する。第３のノードがノード１により送られた符号化パケットを再度符号化しない理由は、同じ符号化パケットの再符号化により生じる符号化の弱点によるものである。次いで、第３のノードは２つの符号化データフレームをその送信バッファ内の第１のデータフレームにピギーバックし、自己のデータと、ノード１により送られたパケットの符号化バージョンと、ノード２により送られたパケットの符号化バージョンとを含む１つで３つのデータフレームを作成する。最大Ｍ個までの確認できなかった符号化パケットを合成し、ピギーバックさせることができる。パラメータＭは、最大パケットサイズの制約条件を超えないように選択する必要があり、ネットワーク管理者または製造者、あるいは動的なメカニズムでも設定できる。複数の符号化データフレームを有するパケットを他の端末から正常に受信すると、アクセスポイントＡＰは複数の受信確認フレーム、すなわち送信機ごとに１つずつ受信確認フレームを送らなければならず、あるいは、アクセスポイントＡＰは、マルチ受信確認フレームを送って、すべてのデータフレームの正常受信を確認することもできる。
【００６４】
この場合もやはり、送信バッファ内にデータフレームを有するという要件は、絶対的に必要なものではない。それゆえ、失敗したＦＥＣピギーバックデータフレームを正常にオーバーヒアした、送信バッファ内にデータフレームのないノードは、その送信バッファに１つで２つのフレームを記憶し、チャネルコンテンションに関与することができる。どちらを選択するかは実施上の問題である。
【００６５】
アップリンク伝送の場合は、受信機ノードが常にアクセスポイントＡＰであるため、ダウンリンク伝送より容易である。しかしながら、ダウンリンクチャネルの場合、送信機は常にアクセスポイントであるが、受信側ノードはアクセスポイントと関連付けられた、アクセスポイントのカバー領域内の任意の端末とすることができる。よって、他のノードに代わって再送信するノードを編成することがより難しいタスクとなるが、これもまた本発明に係る中継装置および中継方法によって解決できる。
【００６６】
ダウンリンクでは、アクセスポイントが第１のパートナートランシーバであり、第２のパートナーレシーバとして働く端末へデータパケットを送信し、中間にある任意の端末がいくつかの基準を満たす場合に中継装置として動作できる。ダウンリンクチャネルの再送信では、各端末がその隣接ノードと共に小さいデータベースを保持することができる。このデータベースは、例えば最近のT_SNR_down秒間に、他の端末とその端末自体とにより共通のアクセスポイントへ送信されたフレームの受信信号対雑音比を測定することにより作成できる。ＳＮＲを測定する手法は、無線リソース測定に関してIEEE802.11kによって定められている手法とすることができる。IEEE802.11k， "802.11k makes WLANs measure up"，Network World magazine，http://www.networkworld.com/news/tech/2004/0329techupdate.htmlを参照されたい。受信ＳＮＲが一定の閾値SNR_thr以上である場合、送信側端末の識別情報とそれに関連するＳＮＲとがデータベースに格納される。このデータベースのエントリは、時間Time_Out後にデータベースから削除される。
【００６７】
アクセスポイントＡＰにより任意の端末へ送信されたデータパケットが失敗した場合、すなわち、その端末からアクセスポイントＡＰへ受信確認フレームが送られなかった場合には、アクセスポイントＡＰにより送られた元のパケットに関するＣＲＣの計算に成功している、対象の受信機の近傍にある他の端末の１つが、アクセスポイントＡＰより高いデータレートで対象の受信機へ符号化バージョンを再送信し、中継装置として動作することもできる。前述のシナリオと同様の例示的なシナリオを図６に示している。図６には、アクセスポイント（第１のパートナートランシーバ）が中心にあり、端末ノード３（第２のパートナートランシーバ）へデータフレームを送信し、端末ノード４（中継装置）がそれらの中間にあるシナリオが示されている。図６に示した例はＷＬＡＮシナリオを指すものであり、この場合もやはり、異なるデータレートの領域が、個々のデータレートを示す対応するラベルを有する同心円として示されている。図６では、アクセスポイントＡＰがノード３へデータフレームを送信し、ノード３が正常に復号化することができないものと想定されている。ノード３は、受信したデータフレームの破損したコピーを特別なバッファに格納する。ノード３の近傍にある他の端末は、アクセスポイントＡＰにより送られたデータフレームを正常に復号化しており、このデータフレームの符号化バージョンを、例えばノード４を中継ノードとしてノード３へ再送信することができる。データフレームの符号化バージョンを再送信することのできる端末は、以下の３つの要件を満たすこととなる。
・最近のＴｄ秒間におけるノード３の過去の送信を受信した際の平均ＳＮＲが、SNR_thr以上でなければならない。
・アクセスポイントＡＰとの間でデータフレームを正常に送信または受信するのに使用される安定したデータレートが、DR_thr_down以上でなければならない。
・任意であるが、個々の送信バッファには１つまたは複数のパケットが格納されている。
【００６８】
最後の条件は絶対的に必要というわけではない。その理由は、送信すべきパケットのない端末は、アクセスポイントＡＰにより送られて正常に復号化されたパケットを自己の送信バッファに追加し、よって、送信すべきパケットを有する他の任意の端末の場合と同様にチャネル競合に関与することができるからである。どちらを選択するかは実施上の問題である。第３の要件を選択しない場合、すなわち、送信バッファ内のパケットを必要としない場合には、第２の要件も必要ではない。その理由は、この相手ノードは、アクセスポイントＡＰへ送信すべきものを有さず、主要パラメータが再送信側相手ノードから対象の受信側ノードへの伝送データレートだけになるからである。
【００６９】
図６では、ノード４が前述の３つの要件を満たすものと想定されている。ノード４が、ノード３からアクセスポイントＡＰへの受信確認フレームがなかったことを検出した後でこのチャネルにアクセスすることができる場合、ノード４は、アップリンク伝送において説明した前述の表と同様の表に従って、アクセスポイントＡＰからノード３へ送られたデータフレームの符号化バージョンを作成し、それを自己のデータフレームにピギーバックすることとなる。最後に、ノード４はその１つで２つのデータフレームをアクセスポイントＡＰとノード３の両方へ送信する。１つで２つのデータフレームのＣＲＣ計算に成功した場合、アクセスポイントＡＰは、ノード４へ受信確認フレームを送る。任意でアクセスポイントＡＰは送信する必要のある任意のデータフレームに受信確認フレームをピギーバックすることもでき、これにより必要な伝送回数が低減される。ノード３は、まず、アクセスポイントＡＰからのノード４のデータフレームへの受信確認フレームを待つ必要があり、ノード４のデータフレームを正常に受信した場合には、短いフレーム間隔（SIFS: Short Inter-frame Space）期間後に自己の受信確認フレームを任意にノード３の送信バッファ内のデータフレームにピギーバックして、アクセスポイントＡＰへ送信する。ノード４は、ノード３からアクセスポイントＡＰへの受信確認フレームをオーバーヒアし次第、または例えば、T_bufferなどで参照される一定時間の後にノード３の符号化パケットを削除することができる。アクセスポイントＡＰからノード４への受信確認フレームをオーバーヒアしなかった場合、ノード３は、正常な受信の際には一定時間ACK_time_outの後、アクセスポイントＡＰへ自己の受信確認フレームを送信する。
【００７０】
図７、図８および図９は、本発明のダウンリンク伝送の実施形態を示す例示的な中継装置と、例示的なアクセスポイントと、例示的な受信機とのフローチャートである。
【００７１】
図７は、本発明に係る中継装置の一実施形態のフローチャートである。中継装置は、ステップ７１０から開始し、続いてステップ７１２でダウンリンクデータフレームをオーバーヒアする。ステップ７１２の後、中継装置はステップ７１４でオーバーヒアしたダウンリンクフレームの正しいＣＲＣを計算しようと試みる。中継装置は正しいＣＲＣを計算できない場合、ステップ７１６で図７の例にカウンタＮで示したバックオフ期間カウンタが減分される。ステップ７１６でバックオフ期間カウンタが減分された後、中継装置はステップ７１８で前述の場合と同様にバックオフ状態の終わりに到達しているかどうかをチェックする。まだバックオフ状態の終わりに到達していない場合、中継装置はステップ７２０に進み、そこでチャネルがビジーであるかどうかをチェックし、使用中である場合にはステップ７１２に進み、そこでダウンリンクフレームをオーバーヒアしようと試みる。
【００７２】
ステップ７２０でチャネルがビジーでないと検出された場合、受信機装置はステップ７１６に進み、そこでカウンタＮを減分する。中継装置はステップ７１４で首尾よく正しいＣＲＣを計算した場合、ステップ７２２に進み、そこでデータフレームの対象の受信機のＭＡＣアドレスを格納し、ステップ７２４に進んで対応する受信機から受信確認フレームを受信したかどうかをチェックする。受信確認フレームがオーバーヒアされた場合、中継装置はステップ７２６に進み、そこで利用可能なデータフレームがないか送信バッファを監視する。
【００７３】
ステップ７２４で受信確認フレームを受信しなかった場合、中継装置はステップ７２８に進み、本発明のこの実施形態では、ステップ７２８で対象の受信機からのＳＮＲがSNR_thrより大きいかどうかを検証する。この要件が満たされない場合、中継装置はステップ７２６に進み、そこで送信バッファが監視される。ステップ７２８で要件が満たされる場合、中継装置はステップ７３０で自己のアクセスポイントＡＰへの送信データレートがDR_thr_downより大きいかどうかをチェックし、この要件が満たされない場合にはステップ７２６に戻る。ステップ７３０で要件が満たされた場合、中継装置はステップ７３２に進み、そこで各受信機の正常送信の比率を検索し、ステップ７３４でＦＥＣ符号化フレームを作成し、ステップ７３６で対応するタイマーを開始して符号化フレームを格納し、ステップ７２６に戻って送信バッファを監視する。
【００７４】
ステップ７２６で送信バッファが空のままの間、中継装置はこの状態に留まる。送信用データが利用可能になると、中継装置はステップ７１８に進み、そこでバックオフ状態が監視される。バックオフ状態の終わり、すなわちＮ＝０に到達すると中継装置はステップ７３８に進み、そこでアクセスポイントＡＰにより各受信機への再送信がすでに実行されているかどうか検証し、実行されている場合には中継装置はステップ７４０に進み、そこでＦＥＣ符号化フレームを削除する。アクセスポイントＡＰによりまだ再送信が実行されていない場合、中継装置はステップ７４２で別の中継装置が各受信機のためのピギーバックフレームを送信しているかどうかをチェックする。ステップ７３８の一部として再送信も実行されておらず、ステップ７４２によるピギーバックフレームも送られていない場合、中継装置はステップ７４４で制限時間T_bufferが経過しているか否かをチェックする。経過していない場合、中継装置はステップ７４６で自己のデータフレームに各受信機のピギーバック符号化フレームを加えたものを送信する。アクセスポイントＡＰにより再送信が行われており、または別の中継装置がピギーバックフレームを送信しており、または制限時間T_bufferが経過している場合には、ステップ７４０でＦＥＣ符号化フレームが削除され、中継装置はステップ７４８で自己のデータフレームだけを送信する。データフレームまたはデータフレームとピギーバックフレームの送信の後、中継装置はステップ７２６に戻り、そこで送信バッファが監視される。
【００７５】
図８は、ダウンリンク伝送時の例示的なアクセスポイント（第１のパートナートランシーバ）のフローチャートである。アクセスポイントＡＰは、ステップ８１０でデータフレームの送信を開始する。データフレームが送信された後、アクセスポイントはステップ８１２に進み、そこで各受信機からの受信確認を待ち、あるいはタイマーTime_Outの終了を待つ。各受信機から受信確認を受信した場合、アクセスポイントＡＰはステップ８１４に進み、そこで通常の動作を続行し、すなわちステップ８１０に戻って次のデータフレームを送信する。ステップ８１２で各受信機から受信確認を受信する前にタイマーが終了した場合、アクセスポイントＡＰはステップ８１６に進み、そこでランダムバックオフを計算し、再送信を開始する。バックオフ期間中、アクセスポイントＡＰはステップ８１８で起こり得る受信確認を検出するために、他の送信機から受信したすべてのフレームをトラッキングする。別のタイムアウトに対応するバックオフ期間内に受信確認も協調的な受信確認も受信しなかった場合、ステップ８２０で再送信が開始され、その直後にアクセスポイントＡＰはステップ８１４に進んで通常の動作を続行する。ステップ８１８で協調的な受信確認を受信した場合、ステップ８２２で再送信バッファから各フレームが削除され、アクセスポイントＡＰはステップ８１４に進んで通常の動作を続行する。
【００７６】
図９は、例示的な受信端末（第２のパートナートランシーバ）のフローチャートである。受信端末は、ステップ９１０から開始し、そこでデータフレームを受信する。ステップ９１０でデータフレームを受信した後、受信端末は引き続きステップ９１２で正しいＣＲＣを計算しようと試みる。ステップ９１２で正しいＣＲＣの計算に成功した場合、受信端末はステップ９１４に進んで通常の動作を続行し、その後に次のデータフレームの送信を行ってステップ９１０に戻る。受信端末は、ステップ９１２で正しいＣＲＣの計算に成功しなかった場合、ステップ９１６に進んで特別なバッファに破損したフレームを格納する。ステップ９１６で破損したフレームがバッファに格納された後、受信端末はステップ９１８に進み、そこで再送信またはピギーバック符号化再送信を待つ。受信端末は、再送信またはピギーバック符号化再送信を受信すると、ステップ９２０で破損したフレームを修復しようと試み、正しいＣＲＣの計算に成功しない限り、ステップ９２０で破損したフレームが修復されるまでステップ９１８に戻り、破損したフレームが修復され次第、ステップ９２２で関連するアクセスポイントへ受信確認フレームを送る。ステップ９２２で受信確認フレームを送った後、受信端末はステップ９１４に進んで通常の動作を続行する。
【００７７】
本発明のいくつかの実施形態では、符号化データフレームの再送信の連鎖反応を回避するために、あらゆるデータフレームが、フラグすなわち例えばフレームが再送信されるべきか否かを示す１ビットのインジケータなどを有する。あらゆるデータフレームは、最大Ｍ回まで、確認されなかった符号化パケットを合成してピギーバックすることができるように、継続してＭ回にわたって再送信フラグを「再送信可能」を意味する１に設定することができる。パラメータＭは、最大パケットサイズの制約条件を超えず、システム性能を低下させないように選択する必要がある。パラメータＭは、例えばネットワーク管理者、製造者によって、または動的または適応的なメカニズムにより設定できる。よって、データフレームの任意のピギーバック符号化再送信により、フラグがそのフレームが次の端末により再送信され得ないことを意味する０に設定されることもある。また、適当な期間の経過後に送信バッファを空にするために、他のノードにより送られたパケットを特別なバッファ内に保持する時間の限界、例えばT_bufferなどを指定する必要もある。T_bufferの値の適切な設定は、正常に送信された受信確認フレームがすべての潜在的な協調ノードによりオーバーヒアされないときの異なる相手ノードによる同じデータフレームの複数回の再送信を回避するのに役立つ。時間T_bufferは、アクセスポイントＡＰまたは端末のどちらかである対象の受信機でも、任意の協調ノードでも有効である。
【００７８】
本発明の実施形態は、本発明に係る中継装置または方法を十分に利用するために、ＩＥＥＥ８０２．１１プロトコルを拡張することもできる。ＩＥＥＥ８０２．１１プロトコルの１つの可能な拡張が、マルチ受信確認フレームの定義である。この場合、マルチ受信確認フレームは、ＩＥＥＥ８０２．１１に準拠した、複数の送信機のための複数の受信確認制御フレームを搬送する単一のフレームである。送信機ごとの別々の受信確認フレームの送信を回避するのに使用されるマルチ受信確認フレームは、その送信をより効率的にする。しかしながら、デフォルトオプションは、送信機ごとに別々の受信確認フレームを送信するものである。
【００７９】
別の拡張として、調整可能な受信確認タイムアウトパラメータとすることもできる。マルチ受信確認のメカニズムの利用に関係なく、本発明の手法は、システム性能を低下させないよう最大でも所与の限界までであるが、最初の送信元からの不要な再送信を回避するために受信確認タイムアウトパラメータを増加させることを提案する。
【００８０】
本発明の実施形態が実行できる別の拡張は、受信確認フレームに元のデータフレームのシーケンスＩＤを含めることである。マルチ受信確認の実施形態の利用とは関係なく、本発明は、送信された受信確認を正常にオーバーヒアしていない他の相手端末からの複数の送信によって生じる、送信元端末における受信確認の重複を避ける（discard）ために、確認されたデータフレームのシーケンスＩＤを受信確認フレームに含めることを提案する。
【００８１】
本発明の実施形態により提案される別の拡張は、ピギーバック符号化再送信データフレームである。送信バッファ内にデータフレームを有する端末Ｔ１は、自己のデータフレームに対して、別の端末Ｔ２によりアクセスポイントＡＰへ送信された正常にオーバーヒアされたデータフレームのより短い符号化バージョンをピギーバックさせることができる。結果として生じるデータフレームは、合成された１つで２つのデータフレームであり、これは、再送信側ノードＴ１の独自のデータフレームと、Ｔ２により送信された失敗データフレームに関連付けられたパリティビットとを有する。パリティビットは、例えば、リードソロモンエンコーダ２５６、２２４とすることのできる、Ｔ１を使用する特定の系統的なエンコーダによる与えられる。再送信側ノードＴ１において使用されるエンコーダの誤り訂正機能は、Ｔ２に関連する正常送信比の関数であって、誤り訂正機能は、監視されるＴ２のフレーム誤り率に伴って増加する。所与の正常送信比率での再送信側のエンコーダは、必ずしもすべての端末において同じである必要はない。しかしながら、この場合、アクセスポイントＡＰは、どのエンコーダがそれぞれの再送信機と関連付けられているか認識している必要がある。この情報は、データフレーム内で送ることもでき、アクセスポイントＡＰに対して事前に知られていてもよい。異なるエンコーダを使用すれば、アクセスポイントＡＰへの再送信における符号ダイバーシチを提供することができ、したがって、正常に復号化される再送信データフレームの比率を向上させる。
【００８２】
図１０は、協調的な符号化を説明するための別の例示的なシナリオを示している。図１０には、４つの端末、Ｓ１、Ｓ２、Ｓ３およびＳ４が示されている。第１のステップ（１）で端末Ｓ１は端末Ｓ２へデータパケットを送信しようと試みる。したがって、端末Ｓ１は第１のパートナートランシーバとして動作し、端末Ｓ２は第２のパートナートランシーバとして動作する。端末Ｓ２は、そのデータパケットの正しいＣＲＣの計算に失敗し、そのためデータパケットを正しく受信できない。しかしながら、端末Ｓ３と端末Ｓ４は、そのパケットをオーバーヒアして首尾よく正しいＣＲＣを計算し、したがって、潜在的な中継装置である。次に、続く第２のステップ（２）で、Ｓ４がＳ２へデータパケットを送信し、このデータパケットは、第１のデータパケットの符号化バージョンとすることも元のバージョンとすることもできる。
【００８３】
図１０に示したシナリオでは、端末Ｓ４と端末Ｓ２の間の伝送チャネルが、端末Ｓ１と端末Ｓ２との間の通信チャネルより良好な通信リンクを可能にするものと想定されている。これにより、端末Ｓ４が端末Ｓ１のために再送信を行うとき、伝送リソースが節約される。本発明に係る中継装置によれば、ヘルプが必要とされる状況が検出された場合、ヘルプインジケータが作成される。図１０に示したシナリオにおいて、端末Ｓ４と端末Ｓ２との間のチャネルを介した情報交換が、端末Ｓ１と端末Ｓ２との間のチャネルを介した情報交換より良好である場合、本発明の一実施形態では端末Ｓ４によりヘルプが必要とされる状況が検出される。より良好な情報の交換とは、より良好な信号対雑音比、より低いビット誤り率、より短い遅延、より良好な最大データレートまたは平均データレートなどを意味する。
【００８４】
さらに、図１０の端末Ｓ４に対応する本発明に係る中継装置は、誤り訂正を実行し、例えばリードソロモン符号を利用して、端末Ｓ１から受信したパケットの符号化バージョンを送信することができる。協調的な符号化の一部として説明される方法は、例えばＩＥＥＥ８０２．１１ＷＬＡＮシステムを使用することもできる。相手の選択は、例えば前述のパラメータのような相対的チャネル品質に関連するパラメータの比較によりオンザフライで実行できる。アップリンクとダウンリンクにおける伝送のために、データレートと信号対雑音比に基づく選択を考慮することができる。さらにＩＥＥＥ８０２．１１ｅベースのネットワークを利用した実施形態の一部として、協調的な相手の選択を、例えばチャネルアクセス優先順位決定により制御することもできる。これにより、ＷＬＡＮシステムへの下位互換性を維持することもできる。
【００８５】
アップリンクにおける協調的な符号化再送信のための別のシナリオの例を図１１に示している。図１１の上部には、アクセスポイントＡＰに加えて、３つの端末Ｓ１、Ｓ２およびＳ３が示されている。第１の送信ステップ（１）で、端末Ｓ１（第１のパートナートランシーバ）は、アクセスポイントＡＰ（第２のパートナートランシーバ）へデータパケットｐ１を送信する。アクセスポイントＡＰは、正しいＣＲＣを計算することができず、そのためデータパケットｐ１は正しく受信できない。端末Ｓ２も端末Ｓ３もパケットｐ１をオーバーヒアし、ＣＲＣを正しく計算する（中継装置）。端末Ｓ１はアクセスポイントＡＰに対して６Ｍｂｐｓチャネルを有し、端末Ｓ２と端末Ｓ３はアクセスポイントＡＰに対して５４Ｍｂｐｓチャネルを有している。端末Ｓ２は、その送信バッファ内に送信用の別のデータパケットを有し、端末Ｓ１にとってヘルプが必要な状況を検出する。したがって、その後の第２の送信ステップ（２）で端末Ｓ２は自己のデータパケットに対して正しく受信したデータパケットｐ１をピギーバックし、それをアクセスポイントＡＰに向けて送信する。アクセスポイントＡＰは、破損パケット受信バッファにパケットｐ１の破損コピーを記憶しており、次に、端末Ｓ２からの追加の受信情報を用いてデータパケットｐ１を正しく復号化しようと試みる。この例では、端末Ｓ２はいずれにしても自己のデータパケットのためにこの送信チャネルにアクセスするはずである。後続の送信ステップ（２’）で表される別の例では、端末Ｓ３は送信ステップ（１）から正常にオーバーヒアしたデータパケットｐ１を再送信する。しかしながら、端末Ｓ３は自己の送信に利用できるデータを有しておらず、そのためもっぱらデータパケットｐ１だけを送信する。
【００８６】
図１１の下部には２つの送信事例が事例ａ）および事例ｂ）と示されている時間軸と共に示されている。事例ａ）では、第１の送信ステップｉ＝０において、データパケットｐ１がアクセスポイントＡＰにより正しく受信されない。次いで端末Ｓ１はバックオフ期間に入り、これは、事例ａの時間軸の下に、直接フレーム間隔にコンテンションウィンドウを加えたものとして示されている。端末Ｓ１のバックオフ期間が経過する前に、端末Ｓ２はデータパケットｐ１の誤り訂正符号化バージョンをアクセスポイントＡＰへ転送する。その直後、アクセスポイントＡＰはデータパケットｐ１を正しく復号化することができ、端末Ｓ１による再送信は不要となる。事例ｂ）は、端末Ｓ３が自己の送信に利用できるデータを有さずにデータパケットｐ１の誤り訂正符号化バージョンを転送することを除けば、前述のものと同様である。要約すると、アクセスポイントＡＰは、まず、端末Ｓ１からパケットｐ１の破損コピーを受信し、次いでデータパケットｐ１の誤り訂正符号化バージョンを受信し、データパケットｐ１の２つのコピーを合成して、アクセスポイントＡＰは例えば増分的冗長性合成（incremental redundancy combining）を使用可能とすることにより、正しく復号化されたデータパケットを得ることができる。本発明の別の実施形態では、誤り訂正符号化が実行されず、データパケットはチェイス合成を可能にするデータパケットの元の符号化された状態で転送される。この場合もやはりＩＥＥＥ８０２．１１ｅ規格を参照して、再送信パケットまたは転送パケットにより高い優先順位を与えるより具体的なメカニズムが考えられる。
【００８７】
本発明の一実施形態では、端末がヘルプを必要とする状況を検出するには、３つの条件が満たされる必要がある。第１の条件は、第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットをオーバーヒアし、そのフレームチェックシーケンスを正常に計算していることである。第２の要件は、第１のパートナートランシーバが第２のパートナートランシーバに対して有するデータレート以上の安定したデータレートを有することとすることができる。他の端末のデータレートは、例えば物理層コンバージェンス手順ヘッダのデータレートフィールドをオーバーヒアすることにより得られる。第３の要件は、送信バッファ内に送信可能な少なくとも１つのパケットを有することとすることができ、この要件は任意であり、ピギーバックパケットだけを可能とし、これは、いくつかのシナリオではより効率的となり得る。したがって、ヘルプが必要とされる状況は、端末がこれらの３つの条件を満たすが、第２のパートナートランシーバから第１のパートナートランシーバへと送られたどんな受信確認もオーバーヒアせず、偶然、第１のパートナートランシーバの前にこのチャネルにアクセスした場合に検出され得る。次いで、この端末は、第２のトランシーバへパケットの符号化バージョンを送信する。第２のトランシーバ自体はパケットを正常に復号化すると、転送側トランシーバと第１のトランシーバとへそれぞれ別個の受信確認フレームを送信し、または現在のＷＬＡＮ規格には準拠しないはずであるが、複数の受信確認フレーム（multiple acknowledgement frame）を利用することもできる。さらに、元のパケットの符号化バージョンを有する他のトランシーバは、元のトランシーバの受信確認または複数の受信確認をオーバーヒアした後で、または元のトランシーバ自体または他のヘルプ側トランシーバからのものであるはずのいくつかの送信の試行をオーバーヒアした後で、またはまれにしか発生しない状況である受信確認の紛失を防ぐためのオプションであるタイムアウト期間が経過した後で、他のトランシーバの送信バッファからこれらのバージョンを削除する。
【００８８】
図１２は、協調的な符号化ダウンリンク伝送での別の例示的なシナリオを示している。図１２の上部には、アクセスポイントＡＰに加えて、３つの端末Ｓ１、Ｓ２およびＳ３が示されている。図１１に示すシナリオと同様に、アクセスポイントと端末Ｓ２およびＳ３との間の通信チャネルは５４Ｍｂｐｓを許容し、アクセスポイントＡＰと端末Ｓ１の間のチャネルは、毎秒６Ｍビットしか許容しないものと想定する。加えて、本発明のこの実施形態では、端末Ｓ２と端末Ｓ３は、これらの端末Ｓ１に向かうデータレートのサポートを決定する必要がある。この場合もやはり、本発明の一実施形態では、３つの条件を考慮する必要がある。第１の条件は、ある一定の期間にわたる送信元端末からの平均信号対雑音比とすることができ、この期間は、例えば最近のＴｄ秒間などであり、例えばSNR_thrなどの閾値以上としなければならない。第２の条件は、検討するトランシーバの送信バッファ内で待機している少なくとも１つのパケットがあることとすることができ、この場合もやはりこの要件は任意である。第３の要件は、アクセスポイントＡＰとの間でデータフレームを正常に送信し、または受信するのに使用される安定したデータレートが、例えばT_Rate_Downlink_Thresholdなどの別の閾値以上でなければならないこととすることができる。この場合、第３の要件は第２の要件に依存する。
【００８９】
これらの要件または条件を満たす端末が、該当する第２のパートナートランシーバからアクセスポイントＡＰ（第１のパートナートランシーバ）へと送られたどんな受信確認フレームもオーバーヒアせず、偶然にアクセスポイントＡＰの再送信の前にこのチャネルにアクセスした場合、この端末は例えば符号化バージョンや元のパケットを宛先端末へ送信し、中継装置として動作することになる。図１２を参照すると、これは、第１の送信ステップ（１）で、アクセスポイントＡＰ（第１のパートナートランシーバ）が、端末Ｓ１（第２のパートナートランシーバ）へデータパケットｐ１を送信しようと試みることを意味する。端末Ｓ１は、データパケットｐ１のＣＲＣを正しく計算することができず、破損受信バッファに破損パケットを格納し、受信確認フレームを送信しない。その後の第２の送信ステップ（２）で、データパケットｐ１を正常に受信した端末Ｓ３（中継装置）は、アクセスポイントＡＰが再送信を実行する前に、端末Ｓ１へデータパケットｐ１の誤り訂正符号化バージョンを転送する。代替的な実施形態において端末Ｓ２（中継装置）は送信ステップ（２’）で端末Ｓ１へパケットｐ１の誤り訂正符号化バージョンをピギーバックスキームで転送する。この例では、端末Ｓ２は送信に利用可能な自己のデータを有していたため、いずれにしてもこのチャネルにアクセスしている。
【００９０】
図１２の下部には、やはり２つの事例が事例ａ）と事例ｂ）とを区別して時間軸に沿って示されている。第１の送信ステップ、すなわちｉ＝０でアクセスポイントＡＰが端末Ｓ１へデータパケットｐ１を送信し、端末Ｓ１はデータパケットｐ１を正しく受信することができない。図１１の例に示したのと同様にバックオフ期間が満了する前に事例ａ）では端末Ｓ２からパケットｐ１の誤り訂正符号化バージョンが受信され、事例ｂ）では端末Ｓ３からパケットのピギーバック誤り訂正符号化バージョンが受信される。次いで、端末Ｓ１は、まず第１の送信ステップ（ｉ＝０）でパケットｐ１の破損コピーを受信し、第２の送信ステップ（ｉ＝１）でパケットｐ１の誤り訂正符号化バージョンを受信し、これらを合成して正しく復号化されたデータパケットｐ１を得ることができる。
【００９１】
一実施形態では、端末Ｓ１が受信したパケットのバージョンが、両方、すなわち中継ノードのパケットのアクセスポイントと、必然的にＡＰの対象の宛先端末とにより別々に確認され、後者の送信が前者の送信の後に行われる。この場合もやはり、元のパケットｐ１の符号化バージョンを有する他のノードは、対象の宛先端末からアクセスポイントへの受信確認フレームをオーバーヒアした後、または送信元または他の端末からのいくつかの送信の試行をオーバーヒアした後、またはまれにしか発生しない状況である受信確認フレームの紛失を防ぐためのオプションである例えばT_bufferなどのタイムアウト期間が経過した後でこれらを削除する。
【００９２】
本発明の別の実施形態を、アップリンク方向の協調的な符号化送信の別のシナリオである図１３に示している。図１３には、アクセスポイントＡＰに加えて３つの端末Ｓ１、Ｓ２およびＳ３が示されている。図１１を利用して説明したのと同様に、第１の送信ステップ（１）で端末Ｓ１は６Ｍｂｐｓチャネルを通してアクセスポイントへデータパケットｐ１を送信しようと試みる。端末Ｓ２と端末Ｓ３は、アクセスポイントに向かう毎秒５４Ｍビットのチャネルを利用する。アクセスポイントは、第１の送信ステップ（１）の間に受信したパケットの正しいＣＲＣを計算するのに失敗し、パケットｐ１の破損コピーを破損パケット受信バッファに保持する。しかしながら、端末Ｓ２も端末Ｓ３も第１の送信ステップ（１）の間にデータパケットｐ１を正しく受信する。本発明の手法によれば、端末Ｓ２は、第２の送信ステップ（２）でアクセスポイントＡＰに向けてデータパケットｐ１を転送する。しかしながら、図１３に示したシナリオでは端末Ｓ２は送信ステップ（２）の間、ピギーバックパケットを正常に送信するのに失敗する。最後に第３の送信ステップ（３）で端末Ｓ３がデータパケットｐ１をアクセスポイントへピギーバックスキームで転送し、その直後、アクセスポイントはデータパケットｐ１の正常に復号化されたバージョンを得ることができるようになる。
【００９３】
端末Ｓ３は、１つのパケットで、元のデータパケットｐ１と、端末Ｓ２が送信ステップ（２）で送信しようとしたデータパケットの符号化バージョンと、自己のデータパケットとを転送する。これによりアクセスポイントは、最初に送信ステップ（１）で送信された元のデータパケットｐ１と、端末Ｓ２が送信ステップ（２）の間に送った元のデータパケットｐ１がピギーバックされた追加のデータパケットと、端末Ｓ２のデータパケットと元のデータパケットｐ１とがピギーバックされた、端末Ｓ３によって送られた別のデータパケットとを復号化することができる。
【００９４】
端末Ｓ２などの協調的な端末によって符号化され、再送信されたデータフレームに対して端末Ｓ１からアクセスポイントＡＰへと送られた受信確認フレームが検出されない場合、送信された１つで２つのデータフレームをオーバーヒアした別のノードが、最初のデータパケットを含む完全な１つで２つのフレームの符号化データを再送信して、提供することができる。本発明の一実施形態では、この送信が再送信であり、あるいは再度再送信され得ることを示すために、再送信フラグが１に設定されなければならない。同様にこのスキームはダウンリンクでも実行できる。
【００９５】
本発明の実施形態は、再送信をより確実にすることにより、例えばＷＬＡＮシステムにおいて送られるトラフィック量を低減するという利点を有する。さらに本発明の実施形態は、再送信に費やされる時間量を低減することにより、例えばＷＬＡＮシステムの総スループットを増大させる。これが可能なのは、高いデータレートの局が低いデータレートの局の代わりに符号化パケットを再送信することができるからである。さらに、本発明の実施形態は、単一のアンテナを備えた端末に対して、ＭＩＭＯのような特徴を有する協調的な伝送システムを作り出すという利点も提供する。さらに本発明の実施形態は、ＩＥＥＥ８０２．１１プロトコルへの任意の変更だけを用いてＷＬＡＮシステムのための実用的で協調的な再送信スキームを定義し、規定する。本発明の実施形態は、追加のプロトコルまたは信号交換のオーバーヘッドを導入せずにオンザフライで相手選択を実行する。
【００９６】
本発明に係る方法のいくつかの実施上の要件に応じて、本発明に係る方法は、ハードウェアとしてもソフトウェアとしても実施できる。この実施は、デジタル記憶媒体、特にプログラム可能なコンピュータシステムと協働して本発明に係る方法を実行する、電子的に読み取り可能な制御信号が格納されたディスク、ＤＶＤまたはＣＤを使って実行できる。したがって、本発明は一般に、本発明に係る方法をコンピュータに実行させるプログラムコードが機械可読媒体上に格納されているコンピュータプログラム製品である。したがって、言い換えると、本発明に係る方法は、コンピュータ、携帯電話機、ＰＤＡまたはＷＬＡＮに接続することのできる任意の携帯用機器に対して、本発明に係る方法の少なくとも１つを実行させるプログラムコードを有するコンピュータプログラムである。
【図面の簡単な説明】
【００９７】
【図１】本発明に係る中継装置の一実施形態を示すブロック図である。
【図２】本発明に係る方法が利用されるシナリオ例を示す説明図である。
【図３】アップリンク伝送での本発明に係る中継装置の一実施形態を示すフローチャートの例である。
【図４】アップリンク伝送でのアクセスポイントの例を示すフローチャートである。
【図５】アップリンク伝送での送信機の例を示すフローチャートである。
【図６】ダウンリンク伝送での本発明に係る方法のシナリオ例を示す説明図である。
【図７】ダウンリンク伝送での本発明に係る中継装置の例を示すフローチャートである。
【図８】ダウンリンク伝送でのアクセスポイントの例を示すフローチャートである。
【図９】ダウンリンク伝送での受信機の例を示すフローチャートである。
【図１０】本発明の協調的な符号化送信の一実施形態のシナリオ例を示す説明図である。
【図１１】アップリンクチャネルにおける本発明の協調的な符号化再送信の一実施形態のシナリオを示す説明図である。
【図１２】ダウンリンクチャネルにおける本発明の協調的符号化再送信の方法のシナリオを示す説明図である。
【図１３】本発明の複数の符号化再送信の方法のシナリオを示す説明図である。
【図１４ａ．１４ｂ．１４ｃ】従来技術の伝送概念を示す説明図である。
【図１５ａ．１５ｂ】従来技術の通信を実行するシナリオを示す説明図である。
【図１６】ＷＬＡＮの従来技術の通信を示す説明図である。
【技術分野】
【０００１】
本発明は、無線ネットワークの分野に関する。ここで、ネットワークは、固定インフラストラクチャネットワーク、アドホックネットワークまたはマルチホップネットワーク、及びこれらの組み合わせと考えられ、無線ローカルエリアネットワーク、無線メッシュネットワークまたは無線マルチホップネットワークとしても知られている。
【背景技術】
【０００２】
端末と該端末に関連付けられたアクセスポイント（ＡＰ）との間の確実で高速な通信は、あらゆる無線ローカルエリアネットワーク（ＷＬＡＮ）内において再送信の際の電力の浪費を回避し、共用の無線チャネルにおけるトラフィック量を最小限まで減らすための重要な問題の１つである。事実、何回も再送信を行うことは、通常、端末のバッテリーにより提供される貴重なエネルギーリソースの浪費である。また、再送信は、無線リソースを非効率的に利用し、ネットワーク内のトラフィック量が比較的多い場合には、トラフィック輻輳を引き起こす可能性もある。ＩＥＥＥ８０２．１１規格に基づくＷＬＡＮにおける送信機は、自己の変調スキームと符号化速度を現在のチャネル状態に合わせて、スループットを最大にする。変調スキームとコードレートの組み合わせはそれぞれ、信号対雑音比（ＳＮＲ）に対するデータスループットの曲線を有し、この曲線がさらに、受信機における所与のビット誤り率（ＢＥＲ）要件に最も適した変調スキームとコードレートの組み合わせを定める。
【０００３】
データレートの自動選択を実施する手法は、ベンダーによる設計の問題であるが、基本的には、統計ベースの手法とＳＮＲベースの手法との２つに分けることができる。一般的には、データレート選択のメカニズムに関わらず、ＡＰの近くに位置する端末が、より高次の変調とコードレートを利用することができる。したがって、ＡＰから離れたところに位置する端末よりも高いデータレートでデータの送受信を行うことができる。
【０００４】
ＷＬＡＮシステムにおいて低いデータレートで送受信を行う端末は、ネットワーク全体のスループットを低減する傾向にあり、高いデータレートで送信する端末の通信に悪影響を与えることは周知である（非特許文献１参照）。これは、データフレームが正常に送信されるまでに要する時間が、スループット、遅延、ジッタなどのサービス品質パラメータに関して評価されるＷＬＡＮシステムの性能の背後にある主な要因だからである。例えば、輻輳したＩＥＥＥ８０２．１１ａ／ｇ（ＷＬＡＮ）ネットワークにおける６Ｍｂｐｓのデータレートでの大きなデータフレームの再送信は、５４Ｍｂｐｓのデータレートでの同じデータフレームの再送信よりもネットワークの全般的な性能にはるかに大きな影響を及ぼす。
【０００５】
無線ネットワークにおける協調的な（cooperative）通信は、近年、学会でも業界でも大いに注目を引いている新しい研究分野である（非特許文献２参照）。協調的なネットワークでは、２つ以上のノードがそれらのデータを共用し、仮想アンテナアレイとして共同で送信を行う。図１４ａから１４ｃに、従来技術のいくつかの概念を示している。図１４ａには、単純で一般的な送信概念である、受信機１４１０へ直接送信を行う送信機１４００が示されている。図１４ｂには、中継局１４２０を介して受信機１４１０と通信する送信機１４００が示されている。この例では、送信機１４００が中継局１４２０へデータパケットを送信し、中継局１４２０が、このデータパケットを受信機１４１０へさらに転送する。
【０００６】
図１４ｃには、中継局１４２０と送信機１４００と受信機１４１０とが関与する別の通信の概念が示されている。図１４ｂと図１４ｃに示す概念の違いは、図１４ｃの受信機１４１０が、送信機１４００から直接送信されたものと、送信信号の中継局１４２０から中継されたバージョンとを受信することである。図１４ｃでは受信機１４１０が、同じ送信の２つのバージョン、すなわち、送信機１４００から送信されたバージョンと中継局１４２０から送信されたバージョンとを受信するため、ダイバーシチ利得が得られる。図１４ｃの送信機１４００と中継局１４２０とは、仮想アンテナアレイとして働く。これは、送信機１４００と中継局１４２０とが、個々に得られるはずのものより高いデータレートとダイバーシチを得ることを可能にする。類似の概念が、非特許文献３〜５にも記載されている。
【０００７】
例えば、ＷＬＡＮシステムにおける協調的ネットワークの概念の実用化は、単一のアンテナを備えた端末が、他のピア端末と協働して多入力多出力（ＭＩＭＯ）システムと同様の時空間ダイバーシチを提供することができるため、ネットワーク全体の性能を向上させる大きな可能性を有する。従来技術から分かる伝送の概念には、モバイル環境では適切な中継局を効率よく特定することができず、そのため、仮想アンテナアレイまたはＭＩＭＯ伝送の利益を活用することができないという問題がある。
【０００８】
例えば、ＩＥＥＥ８０２．１１ベースの機構から、従来技術の一部として、二方向と四方向のフレーム交換が知られている。二方向フレーム交換では、任意の単一データフレームの正常な復号化および受信が、受信機から送信機へ返信される受信確認（ＡＣＫ：acknowledgement）制御により確認できる。送信機は、ＡＣＫフレームを受信しない場合に、分散制御用フレーム間隔（DIFS: Distributed-coordination-function inter-frame space）と、しばしばTime_Slot×[0,CW]と表される、別の時間間隔の範囲内のランダムバックオフ期間との和により定まる期間の後にそのデータフレームを再送信する。この場合、ＩＥＥＥ８０２．１１プロトコルで規定されているように、Ｔｉｍｅ＿Ｓｌｏｔは、物理層におけるタイムスロットの期間を表し、ＣＷは、［ＣＷｍｉｎ，ＣＷｍａｘ］の範囲内のコンテンションウィンドウであり、ＣＷｍｉｎは最小のコンテンションウィンドウであり、ＣＷｍａｘは最大のコンテンションウィンドウである。パラメータＣＷは、値ＣＷｍｉｎから開始し、パケットが再送信されるたびに２倍にされ、特に複数回の再送信が必要なときには高い遅延を生じさせる。
【０００９】
第２の伝送のメカニズムは、前述のものと同じデータ及び受信確認フレームの交換を使用し、さらにそれに先行して送信要求（RTS: request to send）フレームとそれに続く受信準備完了（CTS: clear to send）フレームを含む二方向フレーム交換が行われる、四方向フレーム交換である。ＲＴＳフレーム及びＣＴＳフレームの交換は、隠れノードの問題に対処することを目的としている。これは、送信機がそのチャネル感知範囲外にある第３のノードの送信により受信機に生じる干渉をいう。
【００１０】
前述のように、データフレーム送信後のＡＣＫフレームを受信しないことは、常に送信の失敗と認識され、よって、その後に同じデータフレームの再送信が行われる。ＡＣＫフレームの不受信には、以下の２つの理由がある。
・例えば、受信機における巡回冗長検査（CRC: cyclic redundancy check）の計算により検出されるデータパケットのエラーである。このエラーは、２つの理由によって引き起こされる可能性がある。第１の理由は、送信機と受信機との間の不良なチャネル状態によって生じるビット誤りである。第２の理由は、フレームを同時に送信しようとする２つ以上の端末により生じる衝突によるものである。
・例えば、元の送信機におけるＣＲＣの計算により検出される、受信機から送られたＡＣＫフレームのエラーである。このＡＣＫフレームの受信エラーは、通常は不良なチャネル状態によって生じるビット誤りに起因するが、パケット衝突によって生じることもある。
【００１１】
ＡＣＫフレームの不受信の背景にある理由に関わらず、元のデータフレームは再送信される。一般に、ＡＰから遠くに位置する端末は、より悪いチャネル状態を有する傾向があり、よって、ＡＰのより近くに位置する端末より低いデータレートで動作する。さらに、ＡＰからより離れたところに位置する端末は、同じセル内の他の端末にとって隠れノードとなる確率がより高い。これらの理由から、一般に、低いデータレートの端末による再送信は、高いデータレートの端末による再送信よりもはるかに望ましくない。従来技術の概念には、特に、低いデータレートの端末が、これらのチャネル状態が劣るためにより多くの再送信を必要とするという欠点がある。これにより、セル容量またはシステム容量の点での全体的なシステム性能またはセル性能が劣化する。
【００１２】
非特許文献６において、主要な観点から見た不良な媒体アクセス制御（MAC: medium access control）の問題を軽減する新たな手法が提案されている。著者らは、ユーザ協調によって提供される空間ダイバーシチを導入することにより、既存のＩＥＥＥ８０２．１１無線ローカルエリアネットワークＭＡＣプロトコルを機能強化する、協調的ＭＡＣ（ＣＭＡＣ）と呼ばれる新しいＭＡＣプロトコルを提案している。このスキームでは、相手の端末が、ＡＰによる受信確認を受信していない他の端末により送られたフレームを再送信する。再送信されるフレームは、ＩＥＥＥ８０２．１１ｅ規格によって定められている機構に基づき、より高いチャネルアクセス優先順位を有する特別なキューに格納される。この方法では、相手選択の方法も前方誤り訂正も考慮されていない。さらに、このスキームでは、アップリンクチャネル、すなわち、端末からアクセスポイントまでの送信についてのみ定められている。しかしながら、ダウンリンク、すなわちアクセスポイントから端末までの伝送方向には、依然として既知の欠点がある。一般には、ダウンリンクトラフィックの方がはるかに大きいため、これは大きな欠点となり得る。
【００１３】
著者らは、さらに、無線チャネルでの信頼性を向上させるための前方誤り訂正（FEC=forward error correction）スキームを有するＭＡＣの修正、いわゆるＦＣＭＡＣ（FCMAC: FEC CMAC）も提案している。静的で適応可能なＦＥＣアルゴリズムは、無線ネットワークの性能を改善することもあり、これらのオーバーヘッドが元となるチャネル誤りに正しくマッチしない場合、特に、経路損失が大幅に変動するときには、無線ネットワークの性能を低下させることもある。提案されたスキームは、前述のような協調的通信ＭＡＣに基づくものであり、協調的な前方誤り訂正のスキームを導入している。データフレームはいくつかのリードソロモン符号化データブロックに分割され、これらの符号化データブロックは、それぞれの相手が符号化データブロックの１つだけを処理するようにいくつかの相手により独立して送信される。相手選択の機構は定義されておらず、やはり、提案されたスキームは、アップリンクチャネルだけにしか適用できない。ダウンリンクチャネル、すなわち、アクセスポイントから端末までの伝送には依然として既知の欠点がある。
【００１４】
非特許文献７には、例えばＩＥＥＥ８０２．１１媒体アクセス制御プロトコルの性能を改善するための無線ネットワークにおけるユーザ協調の概念が提示されている。この新しいＭＡＣプロトコルは、ＩＥＥＥ８０２．１１ｂのマルチレート機能を利用し、アクセスポイントから遠く離れた移動局が、中間局を中継局として使って、より高速で送信することを可能にする。この新しいＭＡＣプロトコルの２つの改良の概要が説明されており、両方とも、ネットワーク全体のスループットを増大させ、平均パケット遅延を低減することができる。
【００１５】
図１５ａと図１５ｂに提案された方法を示している。図１５ａと図１５ｂには、受信機Ｓdへデータパケットを送信しようとしている送信機Ｓsが示されている。両者の中間には中継局Ｓhがある。中継局Ｓhは、提案のスキームによれば送信機Ｓsが受信機Ｓdへデータパケットを送信するのを支援することができる。図１５ａと図１５ｂには、さらに、チャネル競合（チャネルコンテンション）に関与する別の２つの端末ＳＴＡ１とＳＴＡ２とが示されている。前述の四方向フレーム交換スキームによれば、送信機ＳsがＲＴＳパケットを送信し、そのＲＴＳパケットは、受信機Ｓdと中継局Ｓhが受信することになる。次いで、中継局Ｓhは、送信機Ｓsへヘルプ可能（HR: help ready）パケットを送ることにより、中継局Ｓhを介した経路が、受信機Ｓdへの直接の経路よりも良好なデータレートを提供することを送信機Ｓsに対して示すことができる。次いで、図１５ｂによれば、送信機Ｓsは、まず中継局Ｓhへデータを送信し、その直後に中継局Ｓhが受信機Ｓdへそのデータを転送する。次いで、受信機ＳdはＡＣＫフレームを送ることにより、送信機Ｓsに対してデータを正常に受信したことを受信確認する。この論文に記載されている概念には、伝送経路がただ１つしかなく、受信機にダイバーシチ利得を提供できないという欠点がある。
【００１６】
このスキームは、宛先に直接フレームを送るか、それとも中継ノードを使ってフレームを送るかを選択する方法を無線ネットワーク内の各局に対して提供する。最適な経路を選択する基準は宛先までの総伝送時間であり、これは、関与するノード間の相対的なチャネル状態の測定によって提供される。この論文で定められている機構は、マルチホップネットワークにおける伝送に最適な経路を選択することに焦点を当てている。この機構には、再送信の機構も、前方誤り訂正協調の使用も考慮されていないという欠点がある。さらに、提案された方法には、ＨＲパケットを介して、ネットワーク内での追加オーバーヘッドが導入され、そのための貴重な伝送リソースが必要となるという欠点もある。
【００１７】
図１６は、従来のＩＥＥＥ８０２．１１規格、すなわち、従来技術の無線ＬＡＮにおいて実施される従来技術の伝送を示している。図１６には、アクセスポイントＡＰと、３つの端末Ｓ１、Ｓ２およびＳ３と、時間軸とが示されている。端末Ｓ１は、時刻ｉ＝１にアクセスポイントＡＰへデータパケットを送信しようと試みる。これは、時間軸上の時刻ｉ＝１にも示されている。端末Ｓ１からアクセスポイントＡＰへの第１の送信は失敗し、よって、アクセスポイントはデータパケットを受信しない。しかしながら、このパケットは、チャネルをオーバーヒアしている他の２つの端末Ｓ２およびＳ３が正常に受信する。受信機において、すなわち、アクセスポイントＡＰにおいて、フレームチェックシーケンス（FCS: frame check sequence）が考慮され、すなわち、受信パケットのチェックサムが評価される。チェックサムが、パケットが正常に受信されなかったことを示す場合、データパケットは破棄され、または削除される。時間軸においてデータパケットの第１の送信の後に示されているように、端末Ｓ１は、分散制御用フレーム間隔（DIFS: Distributed-coordination-function inter-frame space）と呼ばれる時間にわたって待機し、その後、コンテンションウィンドウ機構に従ってバックオフ期間が発生する。次の送信時刻ｉ＝２において、端末Ｓ１は、同じデータパケットの第１の再送信を行う。最初の送信の場合と同様に、データパケットは、アクセスポイントＡＰが正常に受信せず、その直後に端末Ｓ１は再度１つの直接フレーム間隔にわたって待機し、新しいランダムバックオフ期間を生じさせ、その場合、第２の再送信ではコンテンションウィンドウの範囲が２倍となる。端末Ｓ１が受信確認フレームを受信しないときは常に再送信が行われる。すべての再送信は、同じパケット損失の危険を有する。
【００１８】
したがって、この従来技術の概念には、通信リンクが効率よく利用できないという問題がある。考察した例では、「チャネルをオーバーヒアするプロミスキャスモード」である端末Ｓ２とＳ３は、最初の２つの送信を正常に受信するが、これらのパケットは破棄される。
【００１９】
図１６に示した例では、端末Ｓ１は、時間軸に示されている第３の試行ｉ＝３においてデータパケットを正常に送信する。よって、データパケットの第３の送信の後、アクセスポイントＡＰから受信確認フレームを受信する。この例は、従来技術の概念が無線リソースを効率よく利用できないことを示すものである。アクセスポイントＡＰにおいてフレームチェックシーケンスが正常に計算できない理由は、例えば、不良なチャネル状態、すなわち、ビット誤りが生じていたり、同時に送信を行う２つ以上の端末によりパケット衝突が生じていたりするためである。別の障害点が、端末Ｓ１における受信確認のフレームチェックシーケンスの計算であり、これもまた、不良なチャネル状態とビット誤りの発生、または送信の衝突により失敗することがある。図１６の例に示されているように、送信が正常に行われないときは常にコンテンションウィンドウが２倍となり、ランダムバックオフ期間が計算される。
【００２０】
非特許文献８は、集中型と分散型両方の無線ネットワークにおいてダイバーシチを得る効率のよい手法として、ユーザ協調に焦点を当てている。著者らは、準静的なレイリーフェージング条件の下で符号化協調システムを検討し、相手選択の範囲または相手選択の問題を吟味している。著者らは、協調が有利となるユーザ間およびユーザ宛先間のチャネル品質の条件を見出している。著者らは、フレーム誤り率をメトリックに用いて、個々のチャネルコードが使用されるときの、直接送信に対する協調送信の相対的な性能改善を評価するユーザ協調利得（Ｇ）を定めている。
【００２１】
著者らは、ユーザ宛先間の平均受信信号対雑音比（ＳＮＲ）の関数である協調決定パラメータ（ＣＤＰ）を導入し、協調が有用であるか否か（Ｇ＞１またはＧ＜１）が、ユーザ間のリンク品質ではなく、ＣＤＰのみに左右されることを示している。著者らは、ＣＤＰの解析を使ってユーザ協調利得を吟味し、ユーザが、協調利得を最大にするために可能な相手の中からどのようにして選択できるかについての洞察を提供している。著者らは、まず、一方の相手または両方の相手が宛先において高い平均受信ＳＮＲを有するときの漸近的性能を考察している。次いで、著者らは、協調が任意のＳＮＲについて有利となるべき、ユーザと宛先の位置の条件を提供する。著者らは、これらの協調領域を示し、最適な相手選択のための幾何学的な条件を研究している。また、著者らは、システム協調利得を定義し、両方のユーザにとっての協調利益を示している。理論的な結果は、数値例によって検証されている。
【００２２】
非特許文献９では、送信元が中継局へデータをブロードキャストし、中継局の一部または全部が協調してビーム形成してデータを宛先へ転送する、協調的な無線ネットワークを考察している。ネットワークは、全般的な障害の制約を被る。著者らは、協調的な通信のための標準的手法を、以下の２つの点において一般化している。１つ目は、これらの手法は、チャネル状態情報（ＣＳＩ）を得るコストを明示的にモデル化し、考慮に入れるということである。２つ目は、これらの手法は、中継局のためのより一般的で、かつ単純な選択の規則を考慮し、中継局間で最適なものを計算する。これらの規則は、特殊な事例として、この文献で提案されているいくつかの中継選択の基準を含む。これらは、各リンクが同一の平均チャネル利得を有する均一な事例での解析的結果を提示するものである。この事例では、最適な送信スキームが、単純であって効率よく計算できることが示されている。数値結果は、ＣＳＩの訓練とフィードバックのコストは大きいが、それでもなお中継協調が有益であることを示している。
【００２３】
別の関連する従来技術の文献として非特許文献１０〜１３がある。
【００２４】
【非特許文献１】M. Heusse, F. Rousseau, G. Berger-Sabattel and A. Duda, "Performance Anomaly of IEEE 802.11b", Proc. of INFOCOM 2003
【非特許文献２】A. Nosratinia, T. E. Hunter, and A. Hedayat, "Cooperative Communication in Wireless Networks", IEEE Communications Magazine, October 2004
【非特許文献３】A. Sendonaris, E. Erkip, and B. Aazhang, "User cooperation diversity-Part I: System Description", IEEE Trans. Commun., vol.51, no.11, pp.1927-1938, November 2003
【非特許文献４】A. Sendonaris, E. Erkip, and B. Aazhang, "User cooperation diversity- Part II: Implementation aspects and performance analysis", IEEE Transaction on Communications, vol.51, no.11, pp.1939-1948, November 2003
【非特許文献５】J. N. Laneman and G. W. Wornell, "Energy-efficient antenna sharing and relaying for wireless networks", in Proc. IEEE Wireless Communications and Networking Conference (WCNC), September 2000, pp. 7-12
【非特許文献６】S. Shankar, C. Chou and M. Ghosh, "Cooperative Communi-cation MAC (CMAC)-A New MAC Protocol for Next Generation Wireless LANs", in Proc. of the IEEE International Confer-ence on Wireless Networks, Communications and Mobile Com-puting 2005
【非特許文献７】P. Liu, Z. Tao and S. Panwar, "A Cooperative MAC Protocol for Wireless Local Area Networks", in Proc. Of IEEE In-ternational Conference on Communications 2005
【非特許文献８】“Cooperative Regions and Partner Choice in Coded Coop-erative Systems", IEEE transactions on communications, vol. 54, no. 7, July 2006, Z. Lin, E. Erkip and A. Stefanov
【非特許文献９】“Energy-Efficient Cooperative Relaying over Fading Channels with Simple Relay Selection" by R. Madan, N. B. Mehta, A. F. Molisch, and J. Zhang
【非特許文献１０】"Multiuser Detection for Cooperative Networks and Performance Analysis", L. Venturino, X. Wang, and M.Lops, IEEE transactions on signal processing, vol. 54, no. 9, September 2006
【非特許文献１１】"A Simple Distributed Method for Relay Selection in Cooperative Diversity Wireless Networks, based on Re-ciprocity and Channel Measurements", A. Bletsas, A. Lippman, and D. P. Reed
【非特許文献１２】"Grouping and Partner Selection in Cooperative Wire-less Networks" by A. Nosratinia and T. E. Hunter
【非特許文献１３】“Cooperative Source and Channel Coding for Wireless Video Transmission", Y. Wang, E. Erkip and H. Y. Mok, Polytechnic University, Brooklyn, New York, http://vision.poly.edu:8080/~hoiyin/project1.htm
【発明の開示】
【発明が解決しようとする課題】
【００２５】
本発明の目的は、空間ダイバーシチ利得と前方誤り訂正の利点を活用することを可能にする、無線ネットワークにおける協調的な（cooperative）通信のためのより効率のよい概念を提供することである。
【課題を解決するための手段】
【００２６】
上記目的は、請求項１に記載の中継装置と、請求項２５に記載のデータパケットを中継する方法とによって達成される。
【００２７】
上記目的は、第１のパートナートランシーバから第２のパートナートランシーバへ送信されるデータパケットを中継する中継装置であって、データパケットを受信し、第２のパートナートランシーバがデータパケットを正常に受信したときに第２のパートナートランシーバから第１のパートナートランシーバへ送信される受信確認パケットを受信する受信ユニットを備えた中継装置によって達成される。この中継装置は、ヘルプが必要とされる状況が検出された場合にヘルプインジケータを提供するヘルプ検出部と、ヘルプインジケータに応じてデータパケットを送信する送信ユニットとをさらに備えている。ヘルプが必要とされる状況は、中継装置（１００）と第２のパートナートランシーバとの間の第１の通信リンクが、データパケットから得られる情報によって評価される、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクよりも良好であるかどうかに基づいて検出される。
【００２８】
上記目的は、第１のパートナートランシーバから第２のトランシーバへ送信されるデータパケットを中継する方法であって、データパケットを受信するステップと、第２のパートナートランシーバがデータパケットを正常に受信したときに第２のパートナートランシーバから第１のパートナートランシーバへ送信される受信確認パケットを受信するステップとを含む方法により達成される。この方法は、中継装置（１００）と第２のパートナートランシーバとの間の第１の通信リンクを評価するステップと、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクを評価するステップとをさらに含む。この方法は、ヘルプが必要とされる状況が検出されるとヘルプインジケータを提供するステップと、ヘルプインジケータに応じて、元のデータパケットまたはデータパケットを符号化したバージョンを送信するステップとをさらに含む。ヘルプが必要とされる状況は、第１の通信リンクが、データパケットから得られる情報によって評価される第２の通信リンクよりも良好であるかどうかに基づいて検出される。
【００２９】
本発明は、無線ネットワークにおいて、符号化と空間ダイバーシチを活用して低いデータレートを有する端末による再送信を回避することができ、したがって、全般的なネットワーク効率またはスループットを増大させることができるという知見に基づくものである。本発明に係る装置は、パートナートランシーバまたはアクセスポイントまでのより良好なリンクを有する端末が、低いデータレートの端末により送受信される、復号化に失敗したフレームを符号化したバージョンを再送信することを可能にする。最初に低いデータレートのチャネルを通して送信された符号化データフレームを迅速に再送信すれば、平均伝送時間を低減することができ、よって、ネットワークの全般的スループットが増大し、例えばＷＬＡＮシステムなどで利用されるリアルタイムアプリケーションの重要なパラメータである伝送遅延が低減される。協調スキームは、低いデータレートと不良なチャネル状態を有する端末の代わりに、元の形、またはより短い符号化バージョンとしてパケットを再送信する、高いデータレートと良好なチャネル状態を有する端末を有する。
【００３０】
本発明は、ＩＥＥＥ８０２．１１に基づくＷＬＡＮにおいて符号化再送信を実施する方法を含む。相手の選択は、オンザフライ、例えば、端末間の信号対雑音比（ＳＮＲ）、データレート、パケット損失比などの相対的なチャネル品質関連パラメータの比較を通じて同じ端末により分散スキームで行われる。または、例えば、文献「S. Mangold et al., "IEEE 802.11e Wireless LAN for Quality of Service", Proceedings of European Wireless 2002」などに記載されているＩＥＥＥ８０２．１１ｅによって提供されるものなどのチャネルアクセス優先順位決定によって制御することもできる。本発明の一実施形態では、符号化再送信の相手のオンザフライの自己選択は、ＩＥＥＥ８０２．１１プロトコルで定義されている物理層コンバージェンス手順（PLCP: physical layer convergence procedure）ヘッダのデータレートフィールドをオーバーヒアすることにより得られる、送信元端末または第１のパートナートランシーバのデータレートに基づくものである。
【００３１】
本発明の別の実施形態では、符号化再送信の相手選択を、トラフィッククラスに基づくものとすることができる。その場合、符号化再送信の相手選択は、トラフィッククラスごとに別々に、すなわち、例えば、ボイスオーバＩＰ（VoIP: voice over internet protocol）などの遅延に弱いサービスを実行する相手間で行うこともでき、または、以前の再送信回数に応じて動的にトラフィッククラスをアップグレードすることにより、または一般に符号化再送信データフレームのための他の何らかの種類のアクセス優先順位決定の機構を組み込むことにより実行することもできる。トラフィッククラスは、ＩＥＥＥ８０２．１１のサービス品質拡張に関するＩＥＥＥ８０２．１１ｅの規格で定義されている。ＩＥＥＥ８０２．１１ｅトラフィッククラスと共に、新たなトラフィッククラスを、特に、符号化再送信パケットのために生成することもでき、例えば、一実施形態では、データフレームが、再送信されるたびにより高いアクセス優先順位クラスにアップグレードされる。さらに、再送信データフレームの優先順位決定のための新しい動的自動再送信要求（ARQ: automatic repeat request）機構の生成を考慮することもできる。
【００３２】
本発明の実施形態は、例えば、ＷＬＡＮシステムなどにおいて送信されるトラフィックの量が、再送信をより確実にすることにより低減できるという利点を提供する。さらに、本発明に係る中継装置または本発明に係る方法は、例えば、ＷＬＡＮなどにおける総スループットを、再送信に費やされる時間量を低減することにより増大させる。これが可能となるのは、高いデータレートの局が、低いデータレートの局に代わって符号化パケットを再送信できるからである。さらに、本発明の手法は、単一のアンテナだけを備える端末のために、ＭＩＭＯのような特徴を有する協調的伝送システムを作り出し、あるいは、仮想アンテナアレイを生成できる。本発明の実施形態は、さらにＩＥＥＥ８０２．１１プロトコルへの任意選択の変更により、ＷＬＡＮシステムの実際的な協調的再送信スキームを定義し、規定するという利点も提供する。さらに、本発明の実施形態では、前方誤り訂正符号化が容易に実施できる。本発明の実施形態は、両方の伝送方向において、アップリンク、すなわち端末からアクセスポイントへ送信するときも、ダウンリンク、すなわちアクセスポイントから端末へ送信するときにも、大きな利益と利点を提供する。本発明の手法は、ネットワークに信号交換のオーバーヘッドを導入せずにオンザフライで相手選択を可能にする。
【００３３】
本発明の実施形態をについて、添付の図面を使って詳細に説明する。
【発明を実施するための最良の形態】
【００３４】
図１は、本発明に係る中継装置１００の一実施形態のブロック図を示している。図１には、受信ユニット１１０と、ヘルプ検出部１２０と、送信ユニット１３０とが示されている。第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継する中継装置１００は、データパケットを受信して、第２のパートナートランシーバがデータパケットを正常に受信したときに第２のパートナートランシーバから第１のパートナートランシーバへ送信される受信確認パケットを受信する受信ユニット１１０を備えている。
【００３５】
以下では、本発明のいくつかの実施形態について説明する。インフラストラクチャシナリオでは、アップリンクとダウンリンクの伝送方向が区別されている。本発明に係る中継装置１００は、第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを受信する。本発明の実施形態は、例えば、アップリンクにおいて、いくつかの端末または送信機が１つのアクセスポイントまたは受信機へ信号を送信するＷＬＡＮシステムなどを指す。このシナリオでは、第１のパートナートランシーバは、アクセスポイントまたは第２のパートナー受信機へデータパケットを送信しようとする端末となる。本発明に係る中継装置１００は、端末内またはアクセスポイント内に統合することもでき、したがって、実施形態では、すべての端末またはアクセスポイントを本発明に係る中継装置１００とすることができる。ダウンリンクでは、アクセスポイントまたは送信機が、端末または受信機へデータパケットを送信し、よって、このシナリオでは、第１のパートナートランシーバはアクセスポイントであり、第２のパートナー受信機は端末である。前述の場合と同様に、本発明に係る中継装置は、任意の端末内またはアクセスポイント内に統合することもできる。
【００３６】
データパケットの正常な受信は、例えば、ビット誤り率、信号対雑音比、フレームチェックシーケンスなどを評価することにより、第２のパートナートランシーバが検出できる。第２のトランシーバがデータパケットの受信に成功したか否かを検出するための様々な機構が考えられる。本発明に係る中継装置１００にとって重要なのは、第２のトランシーバがデータパケットの正常な受信を確認していないことである。
【００３７】
さらに、中継装置１００は、ヘルプが必要とされる状況が検出された場合にヘルプインジケータを提供するヘルプ検出部１２０を備えている。その場合、ヘルプが必要とされる状況は、中継装置１００と第２のパートナートランシーバとの間の第１の通信リンクが、データパケットから得られる情報によって評価される、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクより良好であるかどうかに基づいて検出される。ヘルプが必要とされる状況は、第２のトランシーバが受信確認パケットにより正常な受信を確認していないことに密接に結びついている。本発明の実施形態では、このようなヘルプが必要とされる状況は、例えば、正常な受信を確認しなかった第２のトランシーバへデータパケットを送信しようとしている第１のトランシーバにより作り出され得る。一実施形態では、ヘルプ検出部１２０は、さらに、受信確認パケットが、データパケットの受信後ある時間内に受信しない場合に終了するタイマーを用いたタイマー終了に基づいてヘルプが必要とされる状況を検出することもできる。
【００３８】
中継装置１００が、第１のパートナートランシーバと第２のパートナートランシーバとに対して、第１のパートナートランシーバと第２のパートナートランシーバとの間のチャネル状態より良好なチャネル状態または通信リンクを有する場合であって、中継装置１００がデータパケットを正常に受信している場合、中継装置は、第１のトランシーバのためにそのデータパケットまたはそのデータパケットを符号化したバージョンを再送信することにより貴重な伝送リソースを節約することができる。中継装置１００と第１のパートナートランシーバと第２のパートナートランシーバとの間の通信チャネルの状態は、様々な評価メトリックによって決定できる。一実施形態では、データパケットから明示的に得られる、すなわちデータパケットの制御情報部分またはヘッダ部分に含まれる情報によって通信リンクを評価することができる。ＷＬＡＮを示す一実施形態では、データレートをパケットのヘッダから読み取ることができる。
【００３９】
本発明の一実施形態では、評価メトリックが、データパケット自体から決定でき、例えばＷＬＡＮネットワークシナリオでは、評価メトリックが、使用されるデータレートに対応する物理層コンバージェンス手順ヘッダから決定できる。
【００４０】
別の実施形態では、データパケットサイズ、伝送期間、変調スキーム、伝送帯域幅を求めることによる通信リンク品質の推測など、データパケットから暗黙的に得られる情報によって通信リンクを評価することを利用することもできる。
【００４１】
ヘルプインジケータに応じたデータパケットの転送または送信は、本発明に係る中継装置１００に備えられている送信ユニット１３０によって実行できる。
【００４２】
前述のように、中継装置１００、あるいはヘルプ検出部１２０は、中継装置１００と第１及び第２のパートナートランシーバとの間の通信リンク、または、第１のパートナートランシーバと第２のパートナートランシーバとの間の通信リンクを、データレート、信号対雑音比、信号対雑音干渉比、パケット損失比、ビット誤り率、平均再送信回数またはトラフィッククラスのうちの１つまたはこれらの組み合わせに基づいて評価することができる。この評価に基づき、本発明の別の実施形態では、パートナートランシーバが決定される。すなわち、すべての潜在的なトランシーバがパートナートランシーバであるとは限らない。潜在的なパートナートランシーバの選択は、本発明の一実施形態では、通信リンクの評価メトリックに基づくものとすることもできる。本発明の一実施形態では、ヘルプインジケータが、パートナートランシーバから受信したデータパケットについてのみ提供され、この場合、パートナートランシーバは、中継装置１００と第２のパートナートランシーバとの間の第１の通信リンクが、第１のパートナートランシーバと第２のパートナートランシーバとの間の第２の通信リンクより良好であるという基準を満たす。一実施形態では、第１の通信リンクは、受信データパケットから読み取られたデータレートによって評価できる。第２の通信リンクは、中継装置１００においてローカルに作成されたデータパケットの以前の送信に使用された自己のデータレートまたは自己の平均データレートによって評価することもできる。一実施形態では、ヘルプが必要とされる状況が、自己のデータレートまたは自己の平均データレートが、受信データパケットから読み取られたデータレートより高い場合にのみ検出される。別の実施形態では、ヘルプが必要とされる状況を決定するときに、第１のパートナートランシーバと中継装置との間の第３の通信リンクの評価も考慮できる。第３の通信リンクは特に、例えば、ヘルプが必要とされる状況が、ダウンリンク送信にも有効であるアップリンク送信から決定される場合に評価することができる。すなわち、一実施形態では、２つのパートナートランシーバの間で相互にヘルプが必要とされる状況を確立できる。
【００４３】
本発明の別の実施形態では、本発明に係る中継装置１００は、別のトランシーバから受信したものでなく、ローカルに作成されて送信が予定されている、送信できる別のデータパケットを有する場合にのみ、ヘルプインジケータを作成し、あるいは受信したデータパケットを転送する。送信ユニット１３０は、この実施形態では、データパケットと別のデータパケットを一緒に、例えばピギーバックスキームで送信することができる。さらに、本発明に係る中継装置１００は、本発明の実施形態では、受信確認パケットを第２のパートナートランシーバから受信した場合、または第１のパートナートランシーバからデータパケットを受信した後、一定の破棄時間が経過した場合に受信データパケットを破棄することができる。別の実施形態では、本発明に係る中継装置１００は、一定の再送信時間が経過した後に送信を繰り返すことができ、あるいは、送信ユニット１３０が、しかるべく再送信を実行することもできる。
【００４４】
本発明の別の実施形態では、再送信インジケータを、例えばビットまたはフラグとして含めることができる。これらの実施形態では、転送されたデータパケットは、送信がすでに協調的な再送信であることを他のトランシーバへ指示するために、本発明に係る中継装置１００によりフラグが立てられる。本発明の別の実施形態では、フラグは、おそらく本発明に係るいくつかの中継装置からなる、ある中継経路を使用可能とするためのカウンタまたは識別番号で置き換えられている。中継経路またはマルチホップ経路の長さを制限するようにカウンタを制限することもできる。さらに、本発明の別の実施形態では、本発明に係る中継装置１００は、マルチ受信確認パケット（multi-acknowledgement packet）または合成受信確認パケット（combined-acknowledgement packet）を受信することができる。このとき、複数のデータパケットまたはあるデータパケットと別のデータパケットとが同時に確認され、その場合、一方のデータパケットを中継されたパケットとし、他方をローカルで作成されたパケットとすることもできる。
【００４５】
本発明の別の実施形態では、本発明に係る中継装置１００は、受信データパケットをトランスコードすることができる。この実施形態は、前方誤り訂正符号化を行い、ここで中継装置１００は例えば、パリティビット、またはデータパケットをトランスコードしたバージョンだけを転送することもできる。一実施形態では、元のデータパケットを再送信するときにはチェイス合成法（chase combining）、または、元のデータパケットをトランスコードしたバージョンが提供されるときには増分的冗長性合成法（incremental redundancy combining）が、第２のパートナートランシーバにおいて使用可能となる。別の実施形態では、トランスコードが、中継装置１００と第２のパートナートランシーバとの間のチャネル品質または通信リンクの品質に適合している。
【００４６】
一実施形態は、アクセスポイントまでの良好な通信リンクを有する第１の端末が音声セッションを実行し、したがって、短い高速伝送のみを行うＷＬＡＮシナリオにおけるものとすることができる。より悪い通信リンクを有する第２の端末は、ビデオコールからアクセスポイントに向けて、より長い伝送を利用してより低速でビデオパケットを送信しようと試みる。第１の端末が第２の端末からビデオパケットを正しく受信したが、アクセスポイントは失敗した場合、第１の端末は、第２の端末から受信したパケットを転送することができる。ヘルプが必要とされる状況を検出するためのリンクの条件は満たされている。その理由は、第１の端末が第２の端末より高いデータレートをサポートし、それを、第１の端末によるビデオデータパケットのパケットヘッダなどから読み取ることができるからである。実施形態は、より高いシステム容量といくつかのサービスでの適用範囲の拡張という利点を提供することが上記の例から分かり、この場合、第１の端末が本発明に係る中継装置１００として機能しなければ、第２の端末はビデオコールを確立することができない。
【００４７】
図２は、本発明に係る中継装置と本発明に係る方法とを詳述するシナリオ例を示している。図２には、８つの各データレート区域が、６Ｍｂｐｓから５４Ｍｂｐｓまでに及ぶ異なるデータレートの表示を有する同心円で表された、一般的なＩＥＥＥ８０２．１１ａ／ｇ ＷＬＡＮの一例が示されている。いくつかの端末がカバー領域全体に分散しており、以下の例では、そのうちのノード１と表されている端末とノード２と表されている端末と、中心にあるアクセスポイントＡＰだけを説明する。端末のデータレートは、それぞれのチャネル状態に適合するように調整されたデータレートが生じた後は、比較的安定しているものと仮定する。端末は、例えば、最後のＮ個の送信データフレームの所与のデータレートＤにおける正常送信の割合がＫ％を上回る場合には、安定したデータレートＤを有するものとみなされる。本発明の以下の説明では、「安定したデータレート」という用語は、任意の関与する端末における前述の要件を満たすデータレートを指すものとする。よって、この例では、アクセスポイントは第２のパートナートランシーバとして機能し、ノード１は第１のパートナートランシーバであり、ノード２は中継装置である。
【００４８】
本発明に係る方法と本発明に係る中継装置とによれば、DR_thr_up以上の安定したデータレートを有するあらゆる端末は、以下の式を満たすようにより低いデータレートを有する端末の代わりにデータフレームを再送信することができる。
DR_thr_up=α・DR_tx
ここで、α＞１であり、DR_txはより低いデータレートを有する端末のデータレートであり、DR_thr_up≦Max_Data_Rateである。よって、[DR_thr_up, Max_Data_Rate]の範囲内のデータレートを有するあらゆる端末は、送信に失敗した端末の潜在的な再送信機または中継装置となり得る。本発明の一実施形態では、通信リンク間の関連がデータレートのメトリックによって評価できる。例えば、ＩＥＥＥ８０２．１１ａまたはｇの場合、パラメータMax_Data_Rateは５４Ｍｂｐｓに設定される。
【００４９】
DR_txは、例えば、他の端末がアクセスポイントＡＰへ送信したデータフレームの物理層コンバージェンス手順（ＰＬＣＰ）ヘッダをオーバーヒアすることによって得られる。すなわち、本発明のこの実施形態では、通信リンクのメトリックに関する情報は、データパケット自体に含まれている。ＰＬＣＰは常に、物理層によってサポートされる最低データレート、例えば、ＩＥＥＥ８０２．１１ａまたはｇの場合には６Ｍｂｐｓで送信される。
【００５０】
わかりやすくするために、図２に示した例ではα＝２が選択されており、ノード１からＡＰへ６Ｍｂｐｓで送信されたデータフレームは、アクセスポイントＡＰにより正常に復号化できないものと仮定する。しかしながら、別の実施形態では、αを動的に調整することもできることに留意すべきである。αは、例えばネットワークまたはトラフィック条件に応じて動的に調整することもできる。例えば、アクセスポイントＡＰの巡回冗長検査（ＣＲＣ）の計算が成功しない場合、アクセスポイントＡＰは受信確認フレームを送らず、例えばT_apと呼ばれる一定の期間（この期間は、実施上の問題であるが、基本的にはこの説明の後段で扱う許容される符号化再送信の回数Ｍにより定めるべきである）にわたって特別なバッファ内に復号化に失敗したデータフレームを保持し、データフレームを正常に復号化するために、ノード１からの通常の再送信、または中継ノードまたは中継装置からのフレームのＦＥＣ符号化（FEC: forward error correction）再送信を待つ。これが、正常に復号化できないパケットが受信機において直ちに削除される８０２．１１のような従来のシステムとの大きな違いである。ノード１が送信したデータフレームをオーバーヒアした、以下の３つの条件を満たすすべての端末は、ノード１が送信したデータフレームを符号化したバージョンを作成し、中継装置として機能することができる。
・α＝２とした場合、DR_thr_upが１２Ｍｂｐｓ以上の安定したデータレートを有すること。
・任意の条件として、送信されるのを待つ少なくとも１つのパケットをバッファ内に有すること。この条件は、絶対的に必要なものではない。その理由は、送信すべきパケットを有さない端末は、他の端末によって送信され正常に復号化されたパケットを自己の送信バッファに追加し、よって、８０２．１１で定義されるチャネルコンテンションに関与することができるからである。どちらを選択するかは実施上の問題であるが、ピギーバックスキームの方が、帯域幅利用の点からみればより効率的である。
・ノード１が送信したパケットのＣＲＣをオーバーヒアし、正常に計算していること。
【００５１】
前述の条件を満たした端末の１つが、アクセスポイントＡＰによってノード１に送られた受信確認フレームをオーバーヒアせず、ノード１の前に、共通のCSMA/CA（CSMA/CA: Channel Sensing Multiple Access / Collision Avoidance）によってそのチャネルに偶然アクセスした場合、その端末は、ノード１によって送られたＦＥＣ符号化データフレームをアクセスポイントＡＰへ送信する前に自己のデータフレームにピギーバックする。上記の３つの条件は、この実施形態では、ヘルプの指示を作成する本発明に係る中継装置に備えられているヘルプ検出部の要件を定義するものであることに留意されたい。図２のノード２は、前述の３つの要件を満たし、ノード１の送信失敗後にチャネルを取得する。すなわち、アクセスポイントＡＰがノード１へ受信確認フレームを送らなかったものと仮定する。ノード２は、自己のデータフレームに対して、ノード１が以前に送信したＦＥＣ符号化フレームをピギーバックし、次いで、この１つで２つのデータフレームをアクセスポイントＡＰへ送信する。アクセスポイントＡＰは、このパケットを正常に復号化できた場合、２つの一連の受信確認フレーム、すなわちノード１に対するものとノード２に対するものとを送る。
【００５２】
代替的に、ノード２のデータフレームとノード１のデータフレームとの両方の正常なＣＲＣ計算を確認するマルチ受信確認フレームを送ることもできる。両方、すなわちノード１とノード２の確認済みデータフレームのＭＡＣヘッダが含まれている、この新しい種類のマルチ受信確認フレームでは、ＩＥＥＥ８０２．１１受信の動作の変更が必要とされるはずである。その理由は、８０２．１１では単一のＭＡＣ宛先アドレスフィールドしか存在せず、ノードがそれ自体にアドレス指定されていないすべてのフレームを破棄するからである。ノード１とノード２とが送信したデータフレームを符号化したバージョンを以前に格納したすべての相手ノードまたはパートナートランシーバは、受信確認フレームをオーバーヒアし次第、または、例えばT_bufferなどのバッファリング時間が経過した場合、これらのデータフレームを特別なバッファから削除しなければならない。ノード１はアクセスポイントＡＰから受信確認フレームを受信したが、以前にノード１のデータフレームを格納したノード１の中継ノードのいくつかが受信していない場合、これらの中継ノードは、ノード１のデータフレームを符号化したバージョンを再送信しようとする。アクセスポイントＡＰは、ノード１への受信確認フレームを送ることにより、これらの中継ノードのそれぞれに対してノード１のデータフレームの再送信が不要であると応答する必要がある。任意の最適化として、すでに正常に送信されたノード１への受信確認フレームをオーバーヒアしていない可能性のある他の再送信の相手によって生じる受信確認フレームの重複を回避するために、対応するノード１のデータフレームのシーケンス制御フィールドを受信確認フレームが含むことができる。これら既存のＩＥＥＥ８０２．１１プロトコルへの任意の拡張を以下にまとめる。
【００５３】
一般には、提案するスキームでは、パリティビットだけの送信を許容する任意の系統的な符号化を使用できる。すなわち、リードソロモン符号（例えば、文献「Bernard Sklar, "Digital Communications", Prentice Hall International, 2001」参照）、または系統的なレート可変パンクチャターボ符号（RCPT: Rate Compatible Punctured Turbo Codes）（文献「D. N. Rowitch and L. B. Milstein, "On the performance of hybrid FEC/ARQ systems using rate compatible punctured turbo (RCPT) codes", IEEE Trans. On Comm., vol. 48, pages 948-959, June 2000」参照）を使用できる。１つの可能な方法は、中継端末に対して、例えば最近のT_past_up秒間の現在の送信機に関連する総送信回数に対する正常な送信回数の比率に基づいて、特定のモードの誤り訂正機能、すなわちコードレートを選択させることである。正常な送信回数の比率は、データフレームヘッダに定義された特別なフィールドを介して送信機ノードから直接得ることもでき、送信機によって送られたデータフレームとそれらの受信確認フレームとをオーバーヒアすることができるような、送信側ノードの送信範囲内に位置する任意の端末においてローカルで計算することもできる。よって、あらゆる中継端末は、最近のT_past_up秒間にオーバーヒアしている任意の所与の送信側端末の正常な送信回数の比率に対する誤り訂正機能の表を有している。
【００５４】
このような表は、事前に構成された、すなわち固定的のものでもよいし、動的なものでもよい。以下の表は、リードソロモン符号を使ってパリティビットが送信される場合の固定的で事前に構成された表の一例である。最近のT0秒間（T0≧T_past_up）に送信が検出されなかったとき、表には隣接端末からの送信が全く格納されず、あるいは、これに関連付けられたエントリが表から削除される。
【表１】
【００５５】
図３、図４及び図５は、それぞれアップリンク伝送を考察する、本発明の一実施形態としての中継端末と、対応する関連のアクセスポイント（第２のパートナートランシーバ）と、送信側の第１のパートナートランシーバとに対応するフローチャートの例である。
【００５６】
図３は、本発明に係る中継装置の一実施形態のフローチャートである。このフローチャートは、ステップ３１０から開始し、続いてステップ３１２で中継装置が他の端末からのアップリンクフレームをオーバーヒアする。他の端末からのアップリンクフレームをオーバーヒアするステップの後、中継装置は、例えばステップ３１４でＣＲＣを評価することにより、別の端末からのアップリンクフレームが正しくオーバーヒアされたかどうかを検出する。ＣＲＣが正しくなかった場合、ステップ３１６でバックオフ状態の残りのタイムスロットの数を表すカウンタＮが減分され、その直後にステップ３１８でバックオフ状態がチェックされる。バックオフ状態Ｎがまだ、ステップ３１８でＮ＝０として示されているトリガに到達していない場合、中継装置はステップ３２０でチャネルがビジーであるか否かをチェックする。チャネルがビジーである場合、中継装置はステップ３１２でそのチャネルを使用する別の端末からのアップリンクフレームをオーバーヒアしようと試みる。チャネルがビジーでない場合、中継装置は、ステップ３１６にループしてカウンタを減分し、最終的にはバックオフ状態の終了に到達する。
【００５７】
中継装置が首尾よく正しいＣＲＣを有する別の端末からのアップリンクフレームをオーバーヒアした場合、ステップ３２２でその送信機のＭＡＣアドレスを記憶する。次いで、本発明に係る方法によれば、中継装置は、ステップ３２４でアクセスポイントからその特定の送信機への受信確認をオーバーヒアしようと試みる。受信確認フレームがアクセスポイントからオーバーヒアされた場合、中継装置はステップ３２６で送信バッファが空であるか否かをチェックする。アクセスポイントから受信確認フレームを受信しない場合、ステップ３２８で中継装置は対応する送信機がパートナートランシーバであるか否かを検証する。これは、中継装置のアクセスポイント方向のデータレートが、各送信機のアクセスポイントへのデータレートより高いかどうかをチェックすることによりステップ３２８に示されている。この要件が満たされない場合、中継装置はステップ３２６で送信バッファの状況を監視する。要件が満たされた場合、ステップ３３０で各送信機が正常な送信回数の比率に従って誤り訂正機能を設定し、その後ステップ３３２でのＦＥＣ符号化フレームを作成するステップと、ステップ３３４でのTime_to_bufferと呼ばれる一定の時間にわたって符号化フレームを記憶するステップが続く。ステップ３３４に続いてステップ３２６で送信バッファが監視される。
【００５８】
ステップ３２６では送信バッファが監視され、中継装置は送信バッファが空である限りこの状態に留まる。送信バッファ内に利用可能なデータがある場合、ステップ３２６に続いてステップ３１８でバックオフタイマーまたはバックオフ状態Ｎが検証される。ステップ３１８でバックオフ状態の終わりに到達した後、すなわち変数Ｎが値０に到達した後、中継装置はステップ３３６で各送信機からアクセスポイントに向けて以前に再送信が実行されているかどうかをチェックする。各送信機により再送信が行われている場合、中継装置はステップ３３８でＦＥＣ符号化フレームが削除される。各送信機からアクセスポイントへの再送信が行われていない場合、中継装置はステップ３４０で他の任意のノードまたは中継装置が各送信機の代わりに以前に符号化送信をしたかどうかをチェックする。別のノードが、すでに各送信機の代わりに符号化したバージョンを送信している場合、中継装置はステップ３３８で各送信機のＦＥＣ符号化フレームを削除する。以前に符号化送信が行われていない場合、中継装置はステップ３４２で制限時間T_bufferを超過しているか否かをチェックする。すでに時間T_bufferが経過している場合、中継装置はステップ３３８でＦＥＣ符号化フレームを削除する。まだT_bufferが経過していない場合、中継装置はステップ３４４で自己のデータフレームに対して、各送信機のピギーバック符号化フレームを加えたものを送信する。中継装置は、ステップ３３８で偶然にＦＥＣ符号化フレームを削除している場合には、ステップ３４６で自己のデータフレームだけを送信し、ステップ３４６での送信またはステップ３４４での送信の後、送信バッファを監視するステップ３２６の状態に戻ることになる。
【００５９】
図４は、アップリンク伝送時の例示的なアクセスポイント（第２のパートナートランシーバ）の動作に関連するフローチャートである。アクセスポイントは、ステップ４１０のデータフレーム受信から開始し、その直後にステップ４１２で正しいＣＲＣを計算しようと試みることになる。アクセスポイントは、ステップ４１２で首尾よく正しいＣＲＣを算出した場合、データフレームの送信機への通常の受信確認フレームの送信を含む通常の動作であるステップ４１４に進む。ステップ４１４からアクセスポイントはステップ４１０に戻り、次のデータフレームの受信を開始する。ステップ４１２でアクセスポイントが正しいＣＲＣを計算できなかった場合、アクセスポイントはステップ４１６で破損したフレームを特別なバッファに格納し、その直後に状態をステップ４１８に変更して再送信またはピギーバック符号化再送信を待つ。再送信もピギーバック符号化再送信も検出されない間は、アクセスポイントはステップ４１８に留まる。再送信またはピギーバック符号化再送信が検出された場合、アクセスポイントはステップ４２０で破損したフレームを修復しようと試み、これに成功した場合にはステップ４２２に進み、そこで送信元ノードへ受信確認フレームを送り、あるいは、送信元ノードへ複数のＡＣＫフレームを送ることもできる。ステップ４２２から、アクセスポイントＡＰはステップ４１４に進んで通常の動作を継続する。ステップ４２０でアクセスポイントが首尾よく破損したフレームを修復できなかった場合、アクセスポイントはステップ４１８に戻り、そこで次の再送信、あるいは次のピギーバック符号化再送信を待つ。
【００６０】
図５は、対応する送信機、すなわち、アップリンク伝送時の第１のパートナートランシーバのフローチャートである。送信機は、ステップ５１０から開始してデータフレームを送信する。ステップ５１０に続き、送信機はステップ５１２でTime_Outと呼ばれる一定の時間にわたってアクセスポイントからの受信確認フレームを待つ。対応する受信確認フレームを受信した場合、送信機はステップ５１４に進み、すなわち、通常の動作を続行し、ステップ５１４からステップ５１０に戻り、そこで次のデータフレームが送信される。
【００６１】
受信確認フレームを受信せずにTime_Outが経過した場合、送信機はステップ５１６でランダムバックオフ時間が計算され、再送信が開始される。ステップ５１６のランダムバックオフ時間の計算後、送信機はステップ５１８に進み、そこでバックオフ期間の間待機し、アクセスポイントによって送られたすべての受信確認フレームをチェックして、失敗したデータフレームについての起こり得る協調的な受信確認を検出する。その理由は、潜在的に中継ノードまたは装置が失われたデータフレームを転送できるからである。協調的な受信確認フレームを受信せずにバックオフ期間が経過した場合、ステップ５２０で再送信が開始され、送信機はステップ５１４の通常の動作に進む。ステップ５１８でバックオフ期間の間に協調的な受信確認フレームを受信した場合、ステップ５２２で各フレームが送信バッファから削除され、送信機は５１４の通常の動作に進む。
【００６２】
アクセスポイント（第２のパートナートランシーバ）から、協調的な端末、すなわち中継装置により符号化されて再送信されたデータフレームの受信確認フレームを受信しなかった場合、送信された１つで２つのデータフレームをオーバーヒアした別の中継ノードが再送信を行い、よって、最初のデータパケットを含む完全な１つで２つのフレームの符号化データパケットを提供することができる。これが可能なのは、このようなノードがコンテンションにおいてチャネルに最初にアクセスする場合と、データフレームのいわゆる再送信フラグが１に設定されていて第２の再送信が許容されている間である。任意の再送信フラグがない場合、本発明の一実施形態では符号化再送信が単一の元のパケット送信を修復するためだけに使用される。図２で、ノード１がアクセスポイントＡＰへのパケット送信に成功しないものと仮定された場合、ノード２はノード１の受信確認フレームがないことを認識した後、ノード１の符号化フレームを自己のデータフレームにピギーバックし、アクセスポイントＡＰへ１つで２つのデータフレームを送る。この送信もまた、不良なチャネル状態またはパケット衝突により成功しないと想定される場合、少なくともノード２のデータレートと同程度のデータレートを有する第３のノードであって、その送信バッファにパケットを有し、ノード２が送信した１つで２つのパケットを正常にオーバーヒアしているノードが、１つで２つのフレームの符号化データをピギーバックし、１つで３つのフレームを送信し、すでに中継されたデータパケットを中継する中継装置として動作することができる。
【００６３】
このため、第３のノードは、パケットの符号化されていない部分、すなわちノード２のデータを符号化し、パケットの符号化されている部分、すなわちノード１の符号化データをそのまま保持する。第３のノードがノード１により送られた符号化パケットを再度符号化しない理由は、同じ符号化パケットの再符号化により生じる符号化の弱点によるものである。次いで、第３のノードは２つの符号化データフレームをその送信バッファ内の第１のデータフレームにピギーバックし、自己のデータと、ノード１により送られたパケットの符号化バージョンと、ノード２により送られたパケットの符号化バージョンとを含む１つで３つのデータフレームを作成する。最大Ｍ個までの確認できなかった符号化パケットを合成し、ピギーバックさせることができる。パラメータＭは、最大パケットサイズの制約条件を超えないように選択する必要があり、ネットワーク管理者または製造者、あるいは動的なメカニズムでも設定できる。複数の符号化データフレームを有するパケットを他の端末から正常に受信すると、アクセスポイントＡＰは複数の受信確認フレーム、すなわち送信機ごとに１つずつ受信確認フレームを送らなければならず、あるいは、アクセスポイントＡＰは、マルチ受信確認フレームを送って、すべてのデータフレームの正常受信を確認することもできる。
【００６４】
この場合もやはり、送信バッファ内にデータフレームを有するという要件は、絶対的に必要なものではない。それゆえ、失敗したＦＥＣピギーバックデータフレームを正常にオーバーヒアした、送信バッファ内にデータフレームのないノードは、その送信バッファに１つで２つのフレームを記憶し、チャネルコンテンションに関与することができる。どちらを選択するかは実施上の問題である。
【００６５】
アップリンク伝送の場合は、受信機ノードが常にアクセスポイントＡＰであるため、ダウンリンク伝送より容易である。しかしながら、ダウンリンクチャネルの場合、送信機は常にアクセスポイントであるが、受信側ノードはアクセスポイントと関連付けられた、アクセスポイントのカバー領域内の任意の端末とすることができる。よって、他のノードに代わって再送信するノードを編成することがより難しいタスクとなるが、これもまた本発明に係る中継装置および中継方法によって解決できる。
【００６６】
ダウンリンクでは、アクセスポイントが第１のパートナートランシーバであり、第２のパートナーレシーバとして働く端末へデータパケットを送信し、中間にある任意の端末がいくつかの基準を満たす場合に中継装置として動作できる。ダウンリンクチャネルの再送信では、各端末がその隣接ノードと共に小さいデータベースを保持することができる。このデータベースは、例えば最近のT_SNR_down秒間に、他の端末とその端末自体とにより共通のアクセスポイントへ送信されたフレームの受信信号対雑音比を測定することにより作成できる。ＳＮＲを測定する手法は、無線リソース測定に関してIEEE802.11kによって定められている手法とすることができる。IEEE802.11k， "802.11k makes WLANs measure up"，Network World magazine，http://www.networkworld.com/news/tech/2004/0329techupdate.htmlを参照されたい。受信ＳＮＲが一定の閾値SNR_thr以上である場合、送信側端末の識別情報とそれに関連するＳＮＲとがデータベースに格納される。このデータベースのエントリは、時間Time_Out後にデータベースから削除される。
【００６７】
アクセスポイントＡＰにより任意の端末へ送信されたデータパケットが失敗した場合、すなわち、その端末からアクセスポイントＡＰへ受信確認フレームが送られなかった場合には、アクセスポイントＡＰにより送られた元のパケットに関するＣＲＣの計算に成功している、対象の受信機の近傍にある他の端末の１つが、アクセスポイントＡＰより高いデータレートで対象の受信機へ符号化バージョンを再送信し、中継装置として動作することもできる。前述のシナリオと同様の例示的なシナリオを図６に示している。図６には、アクセスポイント（第１のパートナートランシーバ）が中心にあり、端末ノード３（第２のパートナートランシーバ）へデータフレームを送信し、端末ノード４（中継装置）がそれらの中間にあるシナリオが示されている。図６に示した例はＷＬＡＮシナリオを指すものであり、この場合もやはり、異なるデータレートの領域が、個々のデータレートを示す対応するラベルを有する同心円として示されている。図６では、アクセスポイントＡＰがノード３へデータフレームを送信し、ノード３が正常に復号化することができないものと想定されている。ノード３は、受信したデータフレームの破損したコピーを特別なバッファに格納する。ノード３の近傍にある他の端末は、アクセスポイントＡＰにより送られたデータフレームを正常に復号化しており、このデータフレームの符号化バージョンを、例えばノード４を中継ノードとしてノード３へ再送信することができる。データフレームの符号化バージョンを再送信することのできる端末は、以下の３つの要件を満たすこととなる。
・最近のＴｄ秒間におけるノード３の過去の送信を受信した際の平均ＳＮＲが、SNR_thr以上でなければならない。
・アクセスポイントＡＰとの間でデータフレームを正常に送信または受信するのに使用される安定したデータレートが、DR_thr_down以上でなければならない。
・任意であるが、個々の送信バッファには１つまたは複数のパケットが格納されている。
【００６８】
最後の条件は絶対的に必要というわけではない。その理由は、送信すべきパケットのない端末は、アクセスポイントＡＰにより送られて正常に復号化されたパケットを自己の送信バッファに追加し、よって、送信すべきパケットを有する他の任意の端末の場合と同様にチャネル競合に関与することができるからである。どちらを選択するかは実施上の問題である。第３の要件を選択しない場合、すなわち、送信バッファ内のパケットを必要としない場合には、第２の要件も必要ではない。その理由は、この相手ノードは、アクセスポイントＡＰへ送信すべきものを有さず、主要パラメータが再送信側相手ノードから対象の受信側ノードへの伝送データレートだけになるからである。
【００６９】
図６では、ノード４が前述の３つの要件を満たすものと想定されている。ノード４が、ノード３からアクセスポイントＡＰへの受信確認フレームがなかったことを検出した後でこのチャネルにアクセスすることができる場合、ノード４は、アップリンク伝送において説明した前述の表と同様の表に従って、アクセスポイントＡＰからノード３へ送られたデータフレームの符号化バージョンを作成し、それを自己のデータフレームにピギーバックすることとなる。最後に、ノード４はその１つで２つのデータフレームをアクセスポイントＡＰとノード３の両方へ送信する。１つで２つのデータフレームのＣＲＣ計算に成功した場合、アクセスポイントＡＰは、ノード４へ受信確認フレームを送る。任意でアクセスポイントＡＰは送信する必要のある任意のデータフレームに受信確認フレームをピギーバックすることもでき、これにより必要な伝送回数が低減される。ノード３は、まず、アクセスポイントＡＰからのノード４のデータフレームへの受信確認フレームを待つ必要があり、ノード４のデータフレームを正常に受信した場合には、短いフレーム間隔（SIFS: Short Inter-frame Space）期間後に自己の受信確認フレームを任意にノード３の送信バッファ内のデータフレームにピギーバックして、アクセスポイントＡＰへ送信する。ノード４は、ノード３からアクセスポイントＡＰへの受信確認フレームをオーバーヒアし次第、または例えば、T_bufferなどで参照される一定時間の後にノード３の符号化パケットを削除することができる。アクセスポイントＡＰからノード４への受信確認フレームをオーバーヒアしなかった場合、ノード３は、正常な受信の際には一定時間ACK_time_outの後、アクセスポイントＡＰへ自己の受信確認フレームを送信する。
【００７０】
図７、図８および図９は、本発明のダウンリンク伝送の実施形態を示す例示的な中継装置と、例示的なアクセスポイントと、例示的な受信機とのフローチャートである。
【００７１】
図７は、本発明に係る中継装置の一実施形態のフローチャートである。中継装置は、ステップ７１０から開始し、続いてステップ７１２でダウンリンクデータフレームをオーバーヒアする。ステップ７１２の後、中継装置はステップ７１４でオーバーヒアしたダウンリンクフレームの正しいＣＲＣを計算しようと試みる。中継装置は正しいＣＲＣを計算できない場合、ステップ７１６で図７の例にカウンタＮで示したバックオフ期間カウンタが減分される。ステップ７１６でバックオフ期間カウンタが減分された後、中継装置はステップ７１８で前述の場合と同様にバックオフ状態の終わりに到達しているかどうかをチェックする。まだバックオフ状態の終わりに到達していない場合、中継装置はステップ７２０に進み、そこでチャネルがビジーであるかどうかをチェックし、使用中である場合にはステップ７１２に進み、そこでダウンリンクフレームをオーバーヒアしようと試みる。
【００７２】
ステップ７２０でチャネルがビジーでないと検出された場合、受信機装置はステップ７１６に進み、そこでカウンタＮを減分する。中継装置はステップ７１４で首尾よく正しいＣＲＣを計算した場合、ステップ７２２に進み、そこでデータフレームの対象の受信機のＭＡＣアドレスを格納し、ステップ７２４に進んで対応する受信機から受信確認フレームを受信したかどうかをチェックする。受信確認フレームがオーバーヒアされた場合、中継装置はステップ７２６に進み、そこで利用可能なデータフレームがないか送信バッファを監視する。
【００７３】
ステップ７２４で受信確認フレームを受信しなかった場合、中継装置はステップ７２８に進み、本発明のこの実施形態では、ステップ７２８で対象の受信機からのＳＮＲがSNR_thrより大きいかどうかを検証する。この要件が満たされない場合、中継装置はステップ７２６に進み、そこで送信バッファが監視される。ステップ７２８で要件が満たされる場合、中継装置はステップ７３０で自己のアクセスポイントＡＰへの送信データレートがDR_thr_downより大きいかどうかをチェックし、この要件が満たされない場合にはステップ７２６に戻る。ステップ７３０で要件が満たされた場合、中継装置はステップ７３２に進み、そこで各受信機の正常送信の比率を検索し、ステップ７３４でＦＥＣ符号化フレームを作成し、ステップ７３６で対応するタイマーを開始して符号化フレームを格納し、ステップ７２６に戻って送信バッファを監視する。
【００７４】
ステップ７２６で送信バッファが空のままの間、中継装置はこの状態に留まる。送信用データが利用可能になると、中継装置はステップ７１８に進み、そこでバックオフ状態が監視される。バックオフ状態の終わり、すなわちＮ＝０に到達すると中継装置はステップ７３８に進み、そこでアクセスポイントＡＰにより各受信機への再送信がすでに実行されているかどうか検証し、実行されている場合には中継装置はステップ７４０に進み、そこでＦＥＣ符号化フレームを削除する。アクセスポイントＡＰによりまだ再送信が実行されていない場合、中継装置はステップ７４２で別の中継装置が各受信機のためのピギーバックフレームを送信しているかどうかをチェックする。ステップ７３８の一部として再送信も実行されておらず、ステップ７４２によるピギーバックフレームも送られていない場合、中継装置はステップ７４４で制限時間T_bufferが経過しているか否かをチェックする。経過していない場合、中継装置はステップ７４６で自己のデータフレームに各受信機のピギーバック符号化フレームを加えたものを送信する。アクセスポイントＡＰにより再送信が行われており、または別の中継装置がピギーバックフレームを送信しており、または制限時間T_bufferが経過している場合には、ステップ７４０でＦＥＣ符号化フレームが削除され、中継装置はステップ７４８で自己のデータフレームだけを送信する。データフレームまたはデータフレームとピギーバックフレームの送信の後、中継装置はステップ７２６に戻り、そこで送信バッファが監視される。
【００７５】
図８は、ダウンリンク伝送時の例示的なアクセスポイント（第１のパートナートランシーバ）のフローチャートである。アクセスポイントＡＰは、ステップ８１０でデータフレームの送信を開始する。データフレームが送信された後、アクセスポイントはステップ８１２に進み、そこで各受信機からの受信確認を待ち、あるいはタイマーTime_Outの終了を待つ。各受信機から受信確認を受信した場合、アクセスポイントＡＰはステップ８１４に進み、そこで通常の動作を続行し、すなわちステップ８１０に戻って次のデータフレームを送信する。ステップ８１２で各受信機から受信確認を受信する前にタイマーが終了した場合、アクセスポイントＡＰはステップ８１６に進み、そこでランダムバックオフを計算し、再送信を開始する。バックオフ期間中、アクセスポイントＡＰはステップ８１８で起こり得る受信確認を検出するために、他の送信機から受信したすべてのフレームをトラッキングする。別のタイムアウトに対応するバックオフ期間内に受信確認も協調的な受信確認も受信しなかった場合、ステップ８２０で再送信が開始され、その直後にアクセスポイントＡＰはステップ８１４に進んで通常の動作を続行する。ステップ８１８で協調的な受信確認を受信した場合、ステップ８２２で再送信バッファから各フレームが削除され、アクセスポイントＡＰはステップ８１４に進んで通常の動作を続行する。
【００７６】
図９は、例示的な受信端末（第２のパートナートランシーバ）のフローチャートである。受信端末は、ステップ９１０から開始し、そこでデータフレームを受信する。ステップ９１０でデータフレームを受信した後、受信端末は引き続きステップ９１２で正しいＣＲＣを計算しようと試みる。ステップ９１２で正しいＣＲＣの計算に成功した場合、受信端末はステップ９１４に進んで通常の動作を続行し、その後に次のデータフレームの送信を行ってステップ９１０に戻る。受信端末は、ステップ９１２で正しいＣＲＣの計算に成功しなかった場合、ステップ９１６に進んで特別なバッファに破損したフレームを格納する。ステップ９１６で破損したフレームがバッファに格納された後、受信端末はステップ９１８に進み、そこで再送信またはピギーバック符号化再送信を待つ。受信端末は、再送信またはピギーバック符号化再送信を受信すると、ステップ９２０で破損したフレームを修復しようと試み、正しいＣＲＣの計算に成功しない限り、ステップ９２０で破損したフレームが修復されるまでステップ９１８に戻り、破損したフレームが修復され次第、ステップ９２２で関連するアクセスポイントへ受信確認フレームを送る。ステップ９２２で受信確認フレームを送った後、受信端末はステップ９１４に進んで通常の動作を続行する。
【００７７】
本発明のいくつかの実施形態では、符号化データフレームの再送信の連鎖反応を回避するために、あらゆるデータフレームが、フラグすなわち例えばフレームが再送信されるべきか否かを示す１ビットのインジケータなどを有する。あらゆるデータフレームは、最大Ｍ回まで、確認されなかった符号化パケットを合成してピギーバックすることができるように、継続してＭ回にわたって再送信フラグを「再送信可能」を意味する１に設定することができる。パラメータＭは、最大パケットサイズの制約条件を超えず、システム性能を低下させないように選択する必要がある。パラメータＭは、例えばネットワーク管理者、製造者によって、または動的または適応的なメカニズムにより設定できる。よって、データフレームの任意のピギーバック符号化再送信により、フラグがそのフレームが次の端末により再送信され得ないことを意味する０に設定されることもある。また、適当な期間の経過後に送信バッファを空にするために、他のノードにより送られたパケットを特別なバッファ内に保持する時間の限界、例えばT_bufferなどを指定する必要もある。T_bufferの値の適切な設定は、正常に送信された受信確認フレームがすべての潜在的な協調ノードによりオーバーヒアされないときの異なる相手ノードによる同じデータフレームの複数回の再送信を回避するのに役立つ。時間T_bufferは、アクセスポイントＡＰまたは端末のどちらかである対象の受信機でも、任意の協調ノードでも有効である。
【００７８】
本発明の実施形態は、本発明に係る中継装置または方法を十分に利用するために、ＩＥＥＥ８０２．１１プロトコルを拡張することもできる。ＩＥＥＥ８０２．１１プロトコルの１つの可能な拡張が、マルチ受信確認フレームの定義である。この場合、マルチ受信確認フレームは、ＩＥＥＥ８０２．１１に準拠した、複数の送信機のための複数の受信確認制御フレームを搬送する単一のフレームである。送信機ごとの別々の受信確認フレームの送信を回避するのに使用されるマルチ受信確認フレームは、その送信をより効率的にする。しかしながら、デフォルトオプションは、送信機ごとに別々の受信確認フレームを送信するものである。
【００７９】
別の拡張として、調整可能な受信確認タイムアウトパラメータとすることもできる。マルチ受信確認のメカニズムの利用に関係なく、本発明の手法は、システム性能を低下させないよう最大でも所与の限界までであるが、最初の送信元からの不要な再送信を回避するために受信確認タイムアウトパラメータを増加させることを提案する。
【００８０】
本発明の実施形態が実行できる別の拡張は、受信確認フレームに元のデータフレームのシーケンスＩＤを含めることである。マルチ受信確認の実施形態の利用とは関係なく、本発明は、送信された受信確認を正常にオーバーヒアしていない他の相手端末からの複数の送信によって生じる、送信元端末における受信確認の重複を避ける（discard）ために、確認されたデータフレームのシーケンスＩＤを受信確認フレームに含めることを提案する。
【００８１】
本発明の実施形態により提案される別の拡張は、ピギーバック符号化再送信データフレームである。送信バッファ内にデータフレームを有する端末Ｔ１は、自己のデータフレームに対して、別の端末Ｔ２によりアクセスポイントＡＰへ送信された正常にオーバーヒアされたデータフレームのより短い符号化バージョンをピギーバックさせることができる。結果として生じるデータフレームは、合成された１つで２つのデータフレームであり、これは、再送信側ノードＴ１の独自のデータフレームと、Ｔ２により送信された失敗データフレームに関連付けられたパリティビットとを有する。パリティビットは、例えば、リードソロモンエンコーダ２５６、２２４とすることのできる、Ｔ１を使用する特定の系統的なエンコーダによる与えられる。再送信側ノードＴ１において使用されるエンコーダの誤り訂正機能は、Ｔ２に関連する正常送信比の関数であって、誤り訂正機能は、監視されるＴ２のフレーム誤り率に伴って増加する。所与の正常送信比率での再送信側のエンコーダは、必ずしもすべての端末において同じである必要はない。しかしながら、この場合、アクセスポイントＡＰは、どのエンコーダがそれぞれの再送信機と関連付けられているか認識している必要がある。この情報は、データフレーム内で送ることもでき、アクセスポイントＡＰに対して事前に知られていてもよい。異なるエンコーダを使用すれば、アクセスポイントＡＰへの再送信における符号ダイバーシチを提供することができ、したがって、正常に復号化される再送信データフレームの比率を向上させる。
【００８２】
図１０は、協調的な符号化を説明するための別の例示的なシナリオを示している。図１０には、４つの端末、Ｓ１、Ｓ２、Ｓ３およびＳ４が示されている。第１のステップ（１）で端末Ｓ１は端末Ｓ２へデータパケットを送信しようと試みる。したがって、端末Ｓ１は第１のパートナートランシーバとして動作し、端末Ｓ２は第２のパートナートランシーバとして動作する。端末Ｓ２は、そのデータパケットの正しいＣＲＣの計算に失敗し、そのためデータパケットを正しく受信できない。しかしながら、端末Ｓ３と端末Ｓ４は、そのパケットをオーバーヒアして首尾よく正しいＣＲＣを計算し、したがって、潜在的な中継装置である。次に、続く第２のステップ（２）で、Ｓ４がＳ２へデータパケットを送信し、このデータパケットは、第１のデータパケットの符号化バージョンとすることも元のバージョンとすることもできる。
【００８３】
図１０に示したシナリオでは、端末Ｓ４と端末Ｓ２の間の伝送チャネルが、端末Ｓ１と端末Ｓ２との間の通信チャネルより良好な通信リンクを可能にするものと想定されている。これにより、端末Ｓ４が端末Ｓ１のために再送信を行うとき、伝送リソースが節約される。本発明に係る中継装置によれば、ヘルプが必要とされる状況が検出された場合、ヘルプインジケータが作成される。図１０に示したシナリオにおいて、端末Ｓ４と端末Ｓ２との間のチャネルを介した情報交換が、端末Ｓ１と端末Ｓ２との間のチャネルを介した情報交換より良好である場合、本発明の一実施形態では端末Ｓ４によりヘルプが必要とされる状況が検出される。より良好な情報の交換とは、より良好な信号対雑音比、より低いビット誤り率、より短い遅延、より良好な最大データレートまたは平均データレートなどを意味する。
【００８４】
さらに、図１０の端末Ｓ４に対応する本発明に係る中継装置は、誤り訂正を実行し、例えばリードソロモン符号を利用して、端末Ｓ１から受信したパケットの符号化バージョンを送信することができる。協調的な符号化の一部として説明される方法は、例えばＩＥＥＥ８０２．１１ＷＬＡＮシステムを使用することもできる。相手の選択は、例えば前述のパラメータのような相対的チャネル品質に関連するパラメータの比較によりオンザフライで実行できる。アップリンクとダウンリンクにおける伝送のために、データレートと信号対雑音比に基づく選択を考慮することができる。さらにＩＥＥＥ８０２．１１ｅベースのネットワークを利用した実施形態の一部として、協調的な相手の選択を、例えばチャネルアクセス優先順位決定により制御することもできる。これにより、ＷＬＡＮシステムへの下位互換性を維持することもできる。
【００８５】
アップリンクにおける協調的な符号化再送信のための別のシナリオの例を図１１に示している。図１１の上部には、アクセスポイントＡＰに加えて、３つの端末Ｓ１、Ｓ２およびＳ３が示されている。第１の送信ステップ（１）で、端末Ｓ１（第１のパートナートランシーバ）は、アクセスポイントＡＰ（第２のパートナートランシーバ）へデータパケットｐ１を送信する。アクセスポイントＡＰは、正しいＣＲＣを計算することができず、そのためデータパケットｐ１は正しく受信できない。端末Ｓ２も端末Ｓ３もパケットｐ１をオーバーヒアし、ＣＲＣを正しく計算する（中継装置）。端末Ｓ１はアクセスポイントＡＰに対して６Ｍｂｐｓチャネルを有し、端末Ｓ２と端末Ｓ３はアクセスポイントＡＰに対して５４Ｍｂｐｓチャネルを有している。端末Ｓ２は、その送信バッファ内に送信用の別のデータパケットを有し、端末Ｓ１にとってヘルプが必要な状況を検出する。したがって、その後の第２の送信ステップ（２）で端末Ｓ２は自己のデータパケットに対して正しく受信したデータパケットｐ１をピギーバックし、それをアクセスポイントＡＰに向けて送信する。アクセスポイントＡＰは、破損パケット受信バッファにパケットｐ１の破損コピーを記憶しており、次に、端末Ｓ２からの追加の受信情報を用いてデータパケットｐ１を正しく復号化しようと試みる。この例では、端末Ｓ２はいずれにしても自己のデータパケットのためにこの送信チャネルにアクセスするはずである。後続の送信ステップ（２’）で表される別の例では、端末Ｓ３は送信ステップ（１）から正常にオーバーヒアしたデータパケットｐ１を再送信する。しかしながら、端末Ｓ３は自己の送信に利用できるデータを有しておらず、そのためもっぱらデータパケットｐ１だけを送信する。
【００８６】
図１１の下部には２つの送信事例が事例ａ）および事例ｂ）と示されている時間軸と共に示されている。事例ａ）では、第１の送信ステップｉ＝０において、データパケットｐ１がアクセスポイントＡＰにより正しく受信されない。次いで端末Ｓ１はバックオフ期間に入り、これは、事例ａの時間軸の下に、直接フレーム間隔にコンテンションウィンドウを加えたものとして示されている。端末Ｓ１のバックオフ期間が経過する前に、端末Ｓ２はデータパケットｐ１の誤り訂正符号化バージョンをアクセスポイントＡＰへ転送する。その直後、アクセスポイントＡＰはデータパケットｐ１を正しく復号化することができ、端末Ｓ１による再送信は不要となる。事例ｂ）は、端末Ｓ３が自己の送信に利用できるデータを有さずにデータパケットｐ１の誤り訂正符号化バージョンを転送することを除けば、前述のものと同様である。要約すると、アクセスポイントＡＰは、まず、端末Ｓ１からパケットｐ１の破損コピーを受信し、次いでデータパケットｐ１の誤り訂正符号化バージョンを受信し、データパケットｐ１の２つのコピーを合成して、アクセスポイントＡＰは例えば増分的冗長性合成（incremental redundancy combining）を使用可能とすることにより、正しく復号化されたデータパケットを得ることができる。本発明の別の実施形態では、誤り訂正符号化が実行されず、データパケットはチェイス合成を可能にするデータパケットの元の符号化された状態で転送される。この場合もやはりＩＥＥＥ８０２．１１ｅ規格を参照して、再送信パケットまたは転送パケットにより高い優先順位を与えるより具体的なメカニズムが考えられる。
【００８７】
本発明の一実施形態では、端末がヘルプを必要とする状況を検出するには、３つの条件が満たされる必要がある。第１の条件は、第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットをオーバーヒアし、そのフレームチェックシーケンスを正常に計算していることである。第２の要件は、第１のパートナートランシーバが第２のパートナートランシーバに対して有するデータレート以上の安定したデータレートを有することとすることができる。他の端末のデータレートは、例えば物理層コンバージェンス手順ヘッダのデータレートフィールドをオーバーヒアすることにより得られる。第３の要件は、送信バッファ内に送信可能な少なくとも１つのパケットを有することとすることができ、この要件は任意であり、ピギーバックパケットだけを可能とし、これは、いくつかのシナリオではより効率的となり得る。したがって、ヘルプが必要とされる状況は、端末がこれらの３つの条件を満たすが、第２のパートナートランシーバから第１のパートナートランシーバへと送られたどんな受信確認もオーバーヒアせず、偶然、第１のパートナートランシーバの前にこのチャネルにアクセスした場合に検出され得る。次いで、この端末は、第２のトランシーバへパケットの符号化バージョンを送信する。第２のトランシーバ自体はパケットを正常に復号化すると、転送側トランシーバと第１のトランシーバとへそれぞれ別個の受信確認フレームを送信し、または現在のＷＬＡＮ規格には準拠しないはずであるが、複数の受信確認フレーム（multiple acknowledgement frame）を利用することもできる。さらに、元のパケットの符号化バージョンを有する他のトランシーバは、元のトランシーバの受信確認または複数の受信確認をオーバーヒアした後で、または元のトランシーバ自体または他のヘルプ側トランシーバからのものであるはずのいくつかの送信の試行をオーバーヒアした後で、またはまれにしか発生しない状況である受信確認の紛失を防ぐためのオプションであるタイムアウト期間が経過した後で、他のトランシーバの送信バッファからこれらのバージョンを削除する。
【００８８】
図１２は、協調的な符号化ダウンリンク伝送での別の例示的なシナリオを示している。図１２の上部には、アクセスポイントＡＰに加えて、３つの端末Ｓ１、Ｓ２およびＳ３が示されている。図１１に示すシナリオと同様に、アクセスポイントと端末Ｓ２およびＳ３との間の通信チャネルは５４Ｍｂｐｓを許容し、アクセスポイントＡＰと端末Ｓ１の間のチャネルは、毎秒６Ｍビットしか許容しないものと想定する。加えて、本発明のこの実施形態では、端末Ｓ２と端末Ｓ３は、これらの端末Ｓ１に向かうデータレートのサポートを決定する必要がある。この場合もやはり、本発明の一実施形態では、３つの条件を考慮する必要がある。第１の条件は、ある一定の期間にわたる送信元端末からの平均信号対雑音比とすることができ、この期間は、例えば最近のＴｄ秒間などであり、例えばSNR_thrなどの閾値以上としなければならない。第２の条件は、検討するトランシーバの送信バッファ内で待機している少なくとも１つのパケットがあることとすることができ、この場合もやはりこの要件は任意である。第３の要件は、アクセスポイントＡＰとの間でデータフレームを正常に送信し、または受信するのに使用される安定したデータレートが、例えばT_Rate_Downlink_Thresholdなどの別の閾値以上でなければならないこととすることができる。この場合、第３の要件は第２の要件に依存する。
【００８９】
これらの要件または条件を満たす端末が、該当する第２のパートナートランシーバからアクセスポイントＡＰ（第１のパートナートランシーバ）へと送られたどんな受信確認フレームもオーバーヒアせず、偶然にアクセスポイントＡＰの再送信の前にこのチャネルにアクセスした場合、この端末は例えば符号化バージョンや元のパケットを宛先端末へ送信し、中継装置として動作することになる。図１２を参照すると、これは、第１の送信ステップ（１）で、アクセスポイントＡＰ（第１のパートナートランシーバ）が、端末Ｓ１（第２のパートナートランシーバ）へデータパケットｐ１を送信しようと試みることを意味する。端末Ｓ１は、データパケットｐ１のＣＲＣを正しく計算することができず、破損受信バッファに破損パケットを格納し、受信確認フレームを送信しない。その後の第２の送信ステップ（２）で、データパケットｐ１を正常に受信した端末Ｓ３（中継装置）は、アクセスポイントＡＰが再送信を実行する前に、端末Ｓ１へデータパケットｐ１の誤り訂正符号化バージョンを転送する。代替的な実施形態において端末Ｓ２（中継装置）は送信ステップ（２’）で端末Ｓ１へパケットｐ１の誤り訂正符号化バージョンをピギーバックスキームで転送する。この例では、端末Ｓ２は送信に利用可能な自己のデータを有していたため、いずれにしてもこのチャネルにアクセスしている。
【００９０】
図１２の下部には、やはり２つの事例が事例ａ）と事例ｂ）とを区別して時間軸に沿って示されている。第１の送信ステップ、すなわちｉ＝０でアクセスポイントＡＰが端末Ｓ１へデータパケットｐ１を送信し、端末Ｓ１はデータパケットｐ１を正しく受信することができない。図１１の例に示したのと同様にバックオフ期間が満了する前に事例ａ）では端末Ｓ２からパケットｐ１の誤り訂正符号化バージョンが受信され、事例ｂ）では端末Ｓ３からパケットのピギーバック誤り訂正符号化バージョンが受信される。次いで、端末Ｓ１は、まず第１の送信ステップ（ｉ＝０）でパケットｐ１の破損コピーを受信し、第２の送信ステップ（ｉ＝１）でパケットｐ１の誤り訂正符号化バージョンを受信し、これらを合成して正しく復号化されたデータパケットｐ１を得ることができる。
【００９１】
一実施形態では、端末Ｓ１が受信したパケットのバージョンが、両方、すなわち中継ノードのパケットのアクセスポイントと、必然的にＡＰの対象の宛先端末とにより別々に確認され、後者の送信が前者の送信の後に行われる。この場合もやはり、元のパケットｐ１の符号化バージョンを有する他のノードは、対象の宛先端末からアクセスポイントへの受信確認フレームをオーバーヒアした後、または送信元または他の端末からのいくつかの送信の試行をオーバーヒアした後、またはまれにしか発生しない状況である受信確認フレームの紛失を防ぐためのオプションである例えばT_bufferなどのタイムアウト期間が経過した後でこれらを削除する。
【００９２】
本発明の別の実施形態を、アップリンク方向の協調的な符号化送信の別のシナリオである図１３に示している。図１３には、アクセスポイントＡＰに加えて３つの端末Ｓ１、Ｓ２およびＳ３が示されている。図１１を利用して説明したのと同様に、第１の送信ステップ（１）で端末Ｓ１は６Ｍｂｐｓチャネルを通してアクセスポイントへデータパケットｐ１を送信しようと試みる。端末Ｓ２と端末Ｓ３は、アクセスポイントに向かう毎秒５４Ｍビットのチャネルを利用する。アクセスポイントは、第１の送信ステップ（１）の間に受信したパケットの正しいＣＲＣを計算するのに失敗し、パケットｐ１の破損コピーを破損パケット受信バッファに保持する。しかしながら、端末Ｓ２も端末Ｓ３も第１の送信ステップ（１）の間にデータパケットｐ１を正しく受信する。本発明の手法によれば、端末Ｓ２は、第２の送信ステップ（２）でアクセスポイントＡＰに向けてデータパケットｐ１を転送する。しかしながら、図１３に示したシナリオでは端末Ｓ２は送信ステップ（２）の間、ピギーバックパケットを正常に送信するのに失敗する。最後に第３の送信ステップ（３）で端末Ｓ３がデータパケットｐ１をアクセスポイントへピギーバックスキームで転送し、その直後、アクセスポイントはデータパケットｐ１の正常に復号化されたバージョンを得ることができるようになる。
【００９３】
端末Ｓ３は、１つのパケットで、元のデータパケットｐ１と、端末Ｓ２が送信ステップ（２）で送信しようとしたデータパケットの符号化バージョンと、自己のデータパケットとを転送する。これによりアクセスポイントは、最初に送信ステップ（１）で送信された元のデータパケットｐ１と、端末Ｓ２が送信ステップ（２）の間に送った元のデータパケットｐ１がピギーバックされた追加のデータパケットと、端末Ｓ２のデータパケットと元のデータパケットｐ１とがピギーバックされた、端末Ｓ３によって送られた別のデータパケットとを復号化することができる。
【００９４】
端末Ｓ２などの協調的な端末によって符号化され、再送信されたデータフレームに対して端末Ｓ１からアクセスポイントＡＰへと送られた受信確認フレームが検出されない場合、送信された１つで２つのデータフレームをオーバーヒアした別のノードが、最初のデータパケットを含む完全な１つで２つのフレームの符号化データを再送信して、提供することができる。本発明の一実施形態では、この送信が再送信であり、あるいは再度再送信され得ることを示すために、再送信フラグが１に設定されなければならない。同様にこのスキームはダウンリンクでも実行できる。
【００９５】
本発明の実施形態は、再送信をより確実にすることにより、例えばＷＬＡＮシステムにおいて送られるトラフィック量を低減するという利点を有する。さらに本発明の実施形態は、再送信に費やされる時間量を低減することにより、例えばＷＬＡＮシステムの総スループットを増大させる。これが可能なのは、高いデータレートの局が低いデータレートの局の代わりに符号化パケットを再送信することができるからである。さらに、本発明の実施形態は、単一のアンテナを備えた端末に対して、ＭＩＭＯのような特徴を有する協調的な伝送システムを作り出すという利点も提供する。さらに本発明の実施形態は、ＩＥＥＥ８０２．１１プロトコルへの任意の変更だけを用いてＷＬＡＮシステムのための実用的で協調的な再送信スキームを定義し、規定する。本発明の実施形態は、追加のプロトコルまたは信号交換のオーバーヘッドを導入せずにオンザフライで相手選択を実行する。
【００９６】
本発明に係る方法のいくつかの実施上の要件に応じて、本発明に係る方法は、ハードウェアとしてもソフトウェアとしても実施できる。この実施は、デジタル記憶媒体、特にプログラム可能なコンピュータシステムと協働して本発明に係る方法を実行する、電子的に読み取り可能な制御信号が格納されたディスク、ＤＶＤまたはＣＤを使って実行できる。したがって、本発明は一般に、本発明に係る方法をコンピュータに実行させるプログラムコードが機械可読媒体上に格納されているコンピュータプログラム製品である。したがって、言い換えると、本発明に係る方法は、コンピュータ、携帯電話機、ＰＤＡまたはＷＬＡＮに接続することのできる任意の携帯用機器に対して、本発明に係る方法の少なくとも１つを実行させるプログラムコードを有するコンピュータプログラムである。
【図面の簡単な説明】
【００９７】
【図１】本発明に係る中継装置の一実施形態を示すブロック図である。
【図２】本発明に係る方法が利用されるシナリオ例を示す説明図である。
【図３】アップリンク伝送での本発明に係る中継装置の一実施形態を示すフローチャートの例である。
【図４】アップリンク伝送でのアクセスポイントの例を示すフローチャートである。
【図５】アップリンク伝送での送信機の例を示すフローチャートである。
【図６】ダウンリンク伝送での本発明に係る方法のシナリオ例を示す説明図である。
【図７】ダウンリンク伝送での本発明に係る中継装置の例を示すフローチャートである。
【図８】ダウンリンク伝送でのアクセスポイントの例を示すフローチャートである。
【図９】ダウンリンク伝送での受信機の例を示すフローチャートである。
【図１０】本発明の協調的な符号化送信の一実施形態のシナリオ例を示す説明図である。
【図１１】アップリンクチャネルにおける本発明の協調的な符号化再送信の一実施形態のシナリオを示す説明図である。
【図１２】ダウンリンクチャネルにおける本発明の協調的符号化再送信の方法のシナリオを示す説明図である。
【図１３】本発明の複数の符号化再送信の方法のシナリオを示す説明図である。
【図１４ａ．１４ｂ．１４ｃ】従来技術の伝送概念を示す説明図である。
【図１５ａ．１５ｂ】従来技術の通信を実行するシナリオを示す説明図である。
【図１６】ＷＬＡＮの従来技術の通信を示す説明図である。
【特許請求の範囲】
【請求項１】
第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継する中継装置（１００）であって、
前記データパケットを受信し、前記第２のパートナートランシーバが前記データパケットを正常に受信したときに前記第２のパートナートランシーバから前記第１のパートナートランシーバへと送信される受信確認パケットを受信する受信ユニット（１１０）と、
ヘルプが必要とされる状況が検出された場合にヘルプインジケータを提供するヘルプ検出部（１２０）と、
前記ヘルプインジケータに応じて前記データパケットを送信する送信ユニット（１３０）と
を備え、
ここで前記ヘルプが必要とされる前記状況は、
前記データパケットを受信してからある時間内に前記受信確認パケットを受信しないときに生じるタイマーの終了と、
前記中継装置（１００）と前記第２のパートナートランシーバとの間の第１の通信リンクが、前記第１のパートナートランシーバと前記第２のパートナートランシーバとの間の第２の通信リンクであって、前記データパケットから得られる情報により評価される第２の通信リンクよりも良好であるか否かという点と
に基づいて検出されるものである、
中継装置（１００）。
【請求項２】
前記ヘルプ検出部（１２０）が、前記データパケットから得られる前記第２の通信リンクに関するデータレート情報と、前記データレート情報が前記第１の通信リンクでサポートされるデータレートより低いデータレートを示すか否かという点とに基づいて、前記ヘルプが必要とされる前記状況を検出するものである、請求項１に記載の中継装置（１００）。
【請求項３】
前記ヘルプ検出部（１２０）が、前記データパケットの制御セクション部分またはヘッダ部分に明示的に含まれる情報により前記通信リンクを評価するものである、請求項１または２に記載の中継装置（１００）。
【請求項４】
前記ヘルプ検出部（１２０）が、前記データパケットから暗黙的に得られる情報により前記通信リンクを評価するものである、請求項１〜３のいずれか一項に記載の中継装置（１００）。
【請求項５】
前記データパケットから暗黙的に得られる前記情報が、データパケットサイズ、変調、伝送期間または伝送帯域幅から推測されるものである、請求項４に記載の中継装置（１００）。
【請求項６】
前記ヘルプ検出部（１２０）が、データレートと信号対雑音比とパケット損失比とビット誤り率と平均再送信回数とのうちの１つまたはこれらの組み合わせに基づいた評価メトリックにより前記通信リンクを評価するものである、請求項１〜５のいずれか一項に記載の中継装置（１００）。
【請求項７】
前記ヘルプ検出部（１２０）が前記受信ユニットから前記評価メトリックを受信するものであり、前記受信ユニット（１１０）が前記評価メトリックを決定するものである、請求項６に記載の中継装置（１００）。
【請求項８】
前記送信ユニット（１３０）が、前記中継装置（１００）から前記第２のパートナートランシーバへの以前の送信についての自己データレートまたは自己平均データレートを決定するものである、請求項１〜７のいずれか一項に記載の中継装置（１００）。
【請求項９】
前記ヘルプ検出部（１２０）が、前記自己データレートまたは前記自己平均データレートと受信パケットから得られるデータレートとの比較に基づいて、前記ヘルプが必要とされる前記状況を決定し、前記自己データレートまたは前記自己平均データレートが前記受信パケットから得られるデータレートより大きい場合に前記ヘルプインジケータを提供するものである、請求項８に記載の中継装置（１００）。
【請求項１０】
前記ヘルプ検出部（１２０）が、前記中継装置（１００）と前記第１のパートナートランシーバとの間の第３の通信リンクの評価メトリックに基づいて、前記ヘルプが必要とされる前記状況を決定するものである、請求項１〜９のいずれか一項に記載の中継装置（１００）。
【請求項１１】
前記受信ユニット（１１０）が、異なる送信機または中継装置から受信したデータパケットに対する受信確認を含んだマルチ受信確認パケットを受信するものである、請求項１〜１０のいずれか一項に記載の中継装置（１００）。
【請求項１２】
中継されたデータパケットを中継する請求項１〜１１のいずれか一項に記載の中継装置（１００）。
【請求項１３】
前記ヘルプ検出部（１２０）が、前記中継装置（１００）においてローカルに作成される別のデータパケットが送信に利用できる場合にのみ前記ヘルプインジケータを提供するものである、請求項１〜１２のいずれか一項に記載の中継装置（１００）。
【請求項１４】
前記送信ユニット（１３０）が、前記データパケットと前記別のデータパケットとを共通のデータパケットとして一緒に送信するものである、請求項１３に記載の中継装置（１００）。
【請求項１５】
あるトランシーバによるデータパケットの送信に続いてある期間内に前記ヘルプ検出部（１２０）がヘルプインジケータを提供することができるか否かという点に基づいて、前記トランシーバをパートナートランシーバとして区別する請求項１〜１４のいずれか一項に記載の中継装置（１００）。
【請求項１６】
前記第２のパートナートランシーバから前記第１のパートナートランシーバへと送信される前記受信確認パケットを受信した場合、または前記データパケットを受信してから破棄時間が経過した後に前記データパケットを破棄する請求項１〜１５のいずれか一項に記載の中継装置（１００）。
【請求項１７】
前記送信ユニット（１３０）が、再送信時間が経過した後に送信を繰り返すものである、請求項１〜１６のいずれか一項に記載の中継装置（１００）。
【請求項１８】
前記送信ユニット（１３０）が、あるデータパケットをパートナートランシーバから受信したかどうかを表すインジケータを送信に含めるものである、請求項１〜１７のいずれか一項に記載の中継装置（１００）。
【請求項１９】
前記受信ユニット（１１０）は、前記データパケットに対してＣＲＣ検査を適用し、前記ＣＲＣ検査が正しい場合に前記データパケットが正常に受信されたとみなすものである、請求項１〜１８のいずれか一項に記載の中継装置（１００）。
【請求項２０】
前記受信ユニット（１１０）が、合成受信確認パケットを送信した送信機が複数のデータパケットを正常に受信したことを確認するための前記合成受信確認パケットを受信するものである、請求項１〜１９のいずれか一項に記載の中継装置（１００）。
【請求項２１】
前記受信ユニット（１１０）または前記送信ユニット（１３０）が、第１の符号化スキームを用いて符号化されているデータパケットを第２の符号化スキームへトランスコードするものであり、ここで前記第２の符号化スキームはローカルに作成されたデータパケットに対して使用される符号化スキームとは異なるものである、請求項１〜２０のいずれか一項に記載の中継装置（１００）。
【請求項２２】
前記ヘルプ検出部（１２０）は、再送信回数もしくはあるデータパケットの再送信が実行されるべきか否かを表す、前記データパケットから得られる再送信インジケータに基づいて前記ヘルプが必要とされる前記状況を検出するか、または、最大再送信回数に基づいて前記ヘルプが必要とされる前記状況を検出するものである、請求項１〜２１のいずれか一項に記載の中継装置（１００）。
【請求項２３】
前記送信ユニット（１３０）が、前記中継装置（１００）と前記第２のパートナートランシーバとの間の前記第１の通信リンク、または前記中継装置（１００）と前記第１のパートナートランシーバとの間の前記第３の通信リンクに対して前記第２の符号化スキームを適応させるものである、請求項２２に記載の中継装置（１００）。
【請求項２４】
前記受信ユニット（１１０）と前記送信ユニット（１３０）とが、ＩＥＥＥ８０２．１１規格に基づいて通信を行うものである、請求項１〜２３のいずれか一項に記載の中継装置（１００）。
【請求項２５】
第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継装置が中継する方法であって、
前記中継装置が前記データパケットを受信するステップと、
前記第２のパートナートランシーバが前記データパケットを正常に受信すると前記第２のパートナートランシーバから前記第１のパートナートランシーバへと送信される受信確認パケットを受信することにより、前記第２のパートナートランシーバが前記データパケットを受信したことを検出するステップと、
前記中継装置と前記第２のパートナートランシーバとの間の第１の通信リンクを評価するステップと、
前記第１のパートナートランシーバと前記第２のパートナートランシーバとの間の第２の通信リンクを評価するステップと、
ヘルプが必要な状況が検出されるとヘルプインジケータを提供するステップであって、前記ヘルプが必要な前記状況が、前記データパケットを受信してからある時間内に前記受信確認パケットを受信しないときに生じるタイマーの終了と、前記データパケットから得られる情報により評価される前記第２の通信リンクよりも前記第１の通信リンクが良好であるか否かという点とに基づいて検出される、ステップと
前記ヘルプインジケータに応じて元のデータパケット、または前記データパケットを符号化したバージョンを送信するステップと
を含む方法。
【請求項２６】
請求項２５に記載の方法をコンピュータに実行させるプログラムコードを含むコンピュータプログラム。
【請求項１】
第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継する中継装置（１００）であって、
前記データパケットを受信し、前記第２のパートナートランシーバが前記データパケットを正常に受信したときに前記第２のパートナートランシーバから前記第１のパートナートランシーバへと送信される受信確認パケットを受信する受信ユニット（１１０）と、
ヘルプが必要とされる状況が検出された場合にヘルプインジケータを提供するヘルプ検出部（１２０）と、
前記ヘルプインジケータに応じて前記データパケットを送信する送信ユニット（１３０）と
を備え、
ここで前記ヘルプが必要とされる前記状況は、
前記データパケットを受信してからある時間内に前記受信確認パケットを受信しないときに生じるタイマーの終了と、
前記中継装置（１００）と前記第２のパートナートランシーバとの間の第１の通信リンクが、前記第１のパートナートランシーバと前記第２のパートナートランシーバとの間の第２の通信リンクであって、前記データパケットから得られる情報により評価される第２の通信リンクよりも良好であるか否かという点と
に基づいて検出されるものである、
中継装置（１００）。
【請求項２】
前記ヘルプ検出部（１２０）が、前記データパケットから得られる前記第２の通信リンクに関するデータレート情報と、前記データレート情報が前記第１の通信リンクでサポートされるデータレートより低いデータレートを示すか否かという点とに基づいて、前記ヘルプが必要とされる前記状況を検出するものである、請求項１に記載の中継装置（１００）。
【請求項３】
前記ヘルプ検出部（１２０）が、前記データパケットの制御セクション部分またはヘッダ部分に明示的に含まれる情報により前記通信リンクを評価するものである、請求項１または２に記載の中継装置（１００）。
【請求項４】
前記ヘルプ検出部（１２０）が、前記データパケットから暗黙的に得られる情報により前記通信リンクを評価するものである、請求項１〜３のいずれか一項に記載の中継装置（１００）。
【請求項５】
前記データパケットから暗黙的に得られる前記情報が、データパケットサイズ、変調、伝送期間または伝送帯域幅から推測されるものである、請求項４に記載の中継装置（１００）。
【請求項６】
前記ヘルプ検出部（１２０）が、データレートと信号対雑音比とパケット損失比とビット誤り率と平均再送信回数とのうちの１つまたはこれらの組み合わせに基づいた評価メトリックにより前記通信リンクを評価するものである、請求項１〜５のいずれか一項に記載の中継装置（１００）。
【請求項７】
前記ヘルプ検出部（１２０）が前記受信ユニットから前記評価メトリックを受信するものであり、前記受信ユニット（１１０）が前記評価メトリックを決定するものである、請求項６に記載の中継装置（１００）。
【請求項８】
前記送信ユニット（１３０）が、前記中継装置（１００）から前記第２のパートナートランシーバへの以前の送信についての自己データレートまたは自己平均データレートを決定するものである、請求項１〜７のいずれか一項に記載の中継装置（１００）。
【請求項９】
前記ヘルプ検出部（１２０）が、前記自己データレートまたは前記自己平均データレートと受信パケットから得られるデータレートとの比較に基づいて、前記ヘルプが必要とされる前記状況を決定し、前記自己データレートまたは前記自己平均データレートが前記受信パケットから得られるデータレートより大きい場合に前記ヘルプインジケータを提供するものである、請求項８に記載の中継装置（１００）。
【請求項１０】
前記ヘルプ検出部（１２０）が、前記中継装置（１００）と前記第１のパートナートランシーバとの間の第３の通信リンクの評価メトリックに基づいて、前記ヘルプが必要とされる前記状況を決定するものである、請求項１〜９のいずれか一項に記載の中継装置（１００）。
【請求項１１】
前記受信ユニット（１１０）が、異なる送信機または中継装置から受信したデータパケットに対する受信確認を含んだマルチ受信確認パケットを受信するものである、請求項１〜１０のいずれか一項に記載の中継装置（１００）。
【請求項１２】
中継されたデータパケットを中継する請求項１〜１１のいずれか一項に記載の中継装置（１００）。
【請求項１３】
前記ヘルプ検出部（１２０）が、前記中継装置（１００）においてローカルに作成される別のデータパケットが送信に利用できる場合にのみ前記ヘルプインジケータを提供するものである、請求項１〜１２のいずれか一項に記載の中継装置（１００）。
【請求項１４】
前記送信ユニット（１３０）が、前記データパケットと前記別のデータパケットとを共通のデータパケットとして一緒に送信するものである、請求項１３に記載の中継装置（１００）。
【請求項１５】
あるトランシーバによるデータパケットの送信に続いてある期間内に前記ヘルプ検出部（１２０）がヘルプインジケータを提供することができるか否かという点に基づいて、前記トランシーバをパートナートランシーバとして区別する請求項１〜１４のいずれか一項に記載の中継装置（１００）。
【請求項１６】
前記第２のパートナートランシーバから前記第１のパートナートランシーバへと送信される前記受信確認パケットを受信した場合、または前記データパケットを受信してから破棄時間が経過した後に前記データパケットを破棄する請求項１〜１５のいずれか一項に記載の中継装置（１００）。
【請求項１７】
前記送信ユニット（１３０）が、再送信時間が経過した後に送信を繰り返すものである、請求項１〜１６のいずれか一項に記載の中継装置（１００）。
【請求項１８】
前記送信ユニット（１３０）が、あるデータパケットをパートナートランシーバから受信したかどうかを表すインジケータを送信に含めるものである、請求項１〜１７のいずれか一項に記載の中継装置（１００）。
【請求項１９】
前記受信ユニット（１１０）は、前記データパケットに対してＣＲＣ検査を適用し、前記ＣＲＣ検査が正しい場合に前記データパケットが正常に受信されたとみなすものである、請求項１〜１８のいずれか一項に記載の中継装置（１００）。
【請求項２０】
前記受信ユニット（１１０）が、合成受信確認パケットを送信した送信機が複数のデータパケットを正常に受信したことを確認するための前記合成受信確認パケットを受信するものである、請求項１〜１９のいずれか一項に記載の中継装置（１００）。
【請求項２１】
前記受信ユニット（１１０）または前記送信ユニット（１３０）が、第１の符号化スキームを用いて符号化されているデータパケットを第２の符号化スキームへトランスコードするものであり、ここで前記第２の符号化スキームはローカルに作成されたデータパケットに対して使用される符号化スキームとは異なるものである、請求項１〜２０のいずれか一項に記載の中継装置（１００）。
【請求項２２】
前記ヘルプ検出部（１２０）は、再送信回数もしくはあるデータパケットの再送信が実行されるべきか否かを表す、前記データパケットから得られる再送信インジケータに基づいて前記ヘルプが必要とされる前記状況を検出するか、または、最大再送信回数に基づいて前記ヘルプが必要とされる前記状況を検出するものである、請求項１〜２１のいずれか一項に記載の中継装置（１００）。
【請求項２３】
前記送信ユニット（１３０）が、前記中継装置（１００）と前記第２のパートナートランシーバとの間の前記第１の通信リンク、または前記中継装置（１００）と前記第１のパートナートランシーバとの間の前記第３の通信リンクに対して前記第２の符号化スキームを適応させるものである、請求項２２に記載の中継装置（１００）。
【請求項２４】
前記受信ユニット（１１０）と前記送信ユニット（１３０）とが、ＩＥＥＥ８０２．１１規格に基づいて通信を行うものである、請求項１〜２３のいずれか一項に記載の中継装置（１００）。
【請求項２５】
第１のパートナートランシーバから第２のパートナートランシーバへと送信されるデータパケットを中継装置が中継する方法であって、
前記中継装置が前記データパケットを受信するステップと、
前記第２のパートナートランシーバが前記データパケットを正常に受信すると前記第２のパートナートランシーバから前記第１のパートナートランシーバへと送信される受信確認パケットを受信することにより、前記第２のパートナートランシーバが前記データパケットを受信したことを検出するステップと、
前記中継装置と前記第２のパートナートランシーバとの間の第１の通信リンクを評価するステップと、
前記第１のパートナートランシーバと前記第２のパートナートランシーバとの間の第２の通信リンクを評価するステップと、
ヘルプが必要な状況が検出されるとヘルプインジケータを提供するステップであって、前記ヘルプが必要な前記状況が、前記データパケットを受信してからある時間内に前記受信確認パケットを受信しないときに生じるタイマーの終了と、前記データパケットから得られる情報により評価される前記第２の通信リンクよりも前記第１の通信リンクが良好であるか否かという点とに基づいて検出される、ステップと
前記ヘルプインジケータに応じて元のデータパケット、または前記データパケットを符号化したバージョンを送信するステップと
を含む方法。
【請求項２６】
請求項２５に記載の方法をコンピュータに実行させるプログラムコードを含むコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４ａ．１４ｂ．１４ｃ】
【図１５ａ．１５ｂ】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４ａ．１４ｂ．１４ｃ】
【図１５ａ．１５ｂ】
【図１６】
【公開番号】特開２００８−１３１６４９（Ｐ２００８−１３１６４９Ａ）
【公開日】平成２０年６月５日（２００８．６．５）
【国際特許分類】
【外国語出願】
【出願番号】特願２００７−３００１５２（Ｐ２００７−３００１５２）
【出願日】平成１９年１１月２０日（２００７．１１．２０）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成２０年６月５日（２００８．６．５）
【国際特許分類】
【出願番号】特願２００７−３００１５２（Ｐ２００７−３００１５２）
【出願日】平成１９年１１月２０日（２００７．１１．２０）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]