JP5497189B2 - 無線ネットワークにおける再送信技術 - Google Patents

Description

無線ネットワークは、ますます一般的になっている。例えばＩＥＥＥ８０２．１１無線ローカルエリアネットワーク（ＷＬＡＮｓ）のような多くの無線ネットワークが、コンテンションベースのメディアアクセス技術を採用し、送信デバイスに無線通信メディア（例えば、チャンネル）へのアクセスを提供する。例えば、ＩＥＥＥ８０２．１１ＷＬＡＮｓは、搬送波感知多重アクセス（ＣＳＭＡ）技術を採用する。

ＣＳＭＡ技術は、共有する通信メディアに送信信号（トランスミッション）を送る前に、他のトラフィックがないことを確認する送信デバイスを含む。この確認には、送信デバイスがどんなネットワークトラフィックのためにも「リスニングする」ことを含む。送信信号が送られると、送信デバイスは、一般的には、目的の受信デバイスによる成功の受領の確認（ＡＣＫ）を待つだろう。

しかしながら、ＩＥＥＥ８０２．１１規格は、ＣＳＭＡ技術を使用して送られた損傷の送信に応じて、受信デバイスに対して、否定的な確認（ＮＡＣＫ）を供給しない。その代わり、送信デバイスが、所定期間内に「ＡＣＫ」を受信しないと、待ち時間（「バックオフ」インターバル）後に、再送信信号（リトランスミッション）を送信することを続行してもよい。独自のＮＡＣＫが存在しないにもかかわらず、ＮＡＣＫは、特定の干渉形式を解決する際のアシスタンスを供給しない。

コンテンションベースの技術は、パケットエラーが主としてネットワークステーションからの送信信号間の衝突に起因するときには、良好に機能する。しかし、この技術は、例えば、集中的な帯域外エミッション、プラットフォームノイズ、及び／又は隠れノードの衝突のような同一チャネル衝突を扱う際に効果的ではない。

以下の図面では、同様の参照番号は、同一の、機能的に類似の、及び／又は、構造的に類似の要素を一般的に示す。或る要素が最初に現れる図面は、参照番号の最も左側の桁によって指し示される。本発明は、付属の図面を参照して説明される。
図１は、例示的な動作環境の図を示す。 図２は、例示的な操作順序のフローを示す。 図３は、例示的な操作順序のフローを示す。 図４は、例示的な操作順序のフローを示す。 図５は、例示的なパケットの図を示す。 図６は、例示的なデバイスの実装図を示す。

実施形態は、協調的な再送信技術を提供する。これらの技術は、ＣＳＭＡのようなコンテンションベースのアクセス方式を採用するネットワークにおいて使用されてもよい。例えば、デバイスは、損傷したパケットを送信デバイスから受信し、その損傷の原因を判定してもよい。その損傷の判定された原因が、ネットワーク内のパケット衝突であるときは、そのデバイスは、その送信デバイスに、コンテンションベースのアクセス方式に従って、パケットの再送信信号（リトランスミッション）を送信することを許可する。しかし、その損傷の判定された原因が、ネットワーク内のパケット衝突以外であるときは、そのデバイスは、その送信デバイスに、再送信アシスタンスを供給する。この再送信アシスタンスは、再送信のためのチャネル予約、及び／又は、送信デバイスのための１つ以上のリンク適応示唆を含む。

従って、サイレント状態である代わりに、受信デバイスは、有用な情報を集め、検出した失敗原因に応じて送信デバイスの再送信を援助する。更に詳しくは、受信デバイスは、その送信デバイスに、受領失敗の原因に適した再送信の機会を供給する。その結果、コンテンション時間と再送信の衝突割合とは、有利に減少されることがある。

こうした技術は、従来のコンテンションベースのメディアアクセス技術を採用するネットワークのパフォーマンスを向上することがある。上述のように、伝統的なＷＬＡＮ規格（例えば、ＴＸＯＰモードで動作しないＩＥＥＥ８０２．１１nシステム）は、パケットが受信エラーのとき、送信されるべきＮＡＣＫを供給しない。従って、送信デバイスは「タイムアウト」し、再送信を開始する前に、スロットの乱数（即ち、バックオフ）を待つ。本技術の目的は、他のデバイスのＣＳＭＡ送信との衝突を回避することである。

しかしながら、多くのパケットエラーは、同一チャンネル衝突（例えば、集中的な帯域外エミッション）、プラットフォームノイズ、及び／又は隠れノードの衝突）といった他の原因により生ずることがある。これらのケースでは、バックオフを用いることは、ネットワーク容量の浪費になることがある。そうした浪費を低減するため、実施形態は、受信デバイスでのパケット失敗の原因を判定してもよい。この判定結果に基づいて、受信デバイスは、再送信に他の情報を与えることにより、再送信により送信デバイスを補助してもよい。

例えば、この判定は、損傷したパケットのソフトビットが集中的なパターンで損傷しているかどうか、又は、他方のプリアンブル及び／又はチャンネルトレーニングシンボルが、損傷パケットの受領の間に存在していたかどうかを、受信デバイスがチェックすることを含んでもよい。この判定結果に基づいて、受信デバイスは、パケットの再送信のためのメディアを予約してもよい。

また、受信デバイスは、送信デバイスのリンクパラメータ及び／又はコンテンションパラメータ適応を示唆してもよい。そうした適応の例は、パケット断片化設定、レート調節、空間ストリーム調節、及び／又はコンテンションウインドウ調節を含む（しかし、それらに限定されない）。干渉が制限されるネットワーク（例えば、ＷＬＡＮなど）においては（例えば、密集した配置やマルチ無線の共存に起因して）、送信と受信デバイス間のそのような協調は、スループットを有利に増大する。

前述の性能に基づいて、実施形態は、複数の機能をもつ応答パケットを供給する。例えば、応答パケットは、（ＮＡＣＫに類似する）再送信要求、チャネル予約、及びリンク適応示唆を含む。そうした応答パケットは、様々な方法で実現されてもよい。例えば、実施形態は（応答パケットとして）、送信可（Ｃｌｅａｒ Ｔｏ Ｓｅｎｄ：ＣＴＳ）パケットを用いてもよく、そのＣＴＳパケットは現行のＩＥＥＥ８０２．１１無線システムに準拠する。そうしたＣＴＳパケットは、再送信パケット要求及びチャネル予約を含んでもよい。しかし、実施形態は、こうした例示的な応答パケットに限定されるものではない。

本明細書全体を通して、「一実施形態」あるいは「或る実施形態」の参照は、その実施形態に関連して述べられる所定の特徴、構造、又は特性が少なくとも１つの実施形態に含まれることを意味する。従って、本明細書全体を通じて様々な箇所で現れる「一実施形態では」あるいは「或る実施形態では」のフレーズは、必ずしも全てが同一の実施形態を参照しているわけではない。さらに、所定の特徴、構造、又は特性は、１つ以上の実施形態で、任意の適切な方法で組み合わされてもよい。

図１は、例示的な動作環境１００のダイアグラムであり、その動作環境では、本明細書で説明する技術が採用されてもよい。この環境は、複数のデバイスを含む。詳しくは、図１は、アクセスポイント（ＡＰ）１０２、ステーション（ＳＴＡ）１０４ａ―ｂ、及び外部エミッションソース１０６を示す。これらのデバイスは、ハードウェア及び／又はソフトウェアの任意の組合せによって実現してもよい。

ＡＰ１０２とＳＴＡ１０４ａ―ｂは、例えばＣＳＭＡ、衝突回避方式のＣＳＭＡ（ＣＳＭＡ／ＣＡ）等々のコンテンションベースのアクセス方式に従って、互いに通信してもよい。従って、これらのデバイスは、ＩＥＥＥ８０２．１１ＷＬＡＮ（例えば、ＩＥＥＥ８０２．１１ｎＷＬＡＮ）として動作してもよい。しかし、実施形態は、ＩＥＥＥ８０２．１１ＷＬＡＮの実装に限定するものではない。さらに、実施形態は、ＣＳＭＡアクセス方式に限定するものではない。従って、そうした通信は、本明細書で説明する技術に従って再送信信号を送信するＳＴＡ１０４ａ―ｂを含む。例えば、そうした再送信信号は、ＡＰ１０２によって送信される応答パケットに基づいてもよい。

例示目的として、図１は、パケット１２０をＡＰ１０２に送信するＳＴＡ１０４ａを示す。ＡＰ１０２でのパケット１２０の受信は、１つ以上の他の送信信号によって損傷されることがある。例えば、図１は、衝突するパケット１２２を送信するＳＴＡ１０４ｂ、及び、干渉する送信信号１２４を生成する外部エミッションソース１０６を示す。

上述したように、ノイズ及び干渉は、パケットエラーを生じ得る。干渉は、ネットワーク外部のソースから発生することがある。ネットワーク外部のソースの例には、ブルートゥース、３Ｇ，近接チャネルＷｉＦｉ、ＷｉＭＡＸ及び電子レンジなどの他の無線を含む。

図１を参照すると、干渉する送信信号１２４（外部エミッションソース１０６によって生成される）は、ネットワーク外部のソースからの干渉の例である。外部エミッションソース１０６は、ＳＴＡ１０４ａから分離して別のデバイスの中にあってもよい。あるいは、外部エミッションソース１０６は、ＳＴＡ１０４ａの中に（ＳＴＡ１０４ａと同じ場所に配置されて）あってもよい。そうしたケースでは、マルチ無線の協調がないことは、同じ場所に配置されるエミッションソースからの帯域外エミッションにより生ずる同一チャネル干渉を増大することがある。

そうした同一チャネル干渉は、無作為に、所望の無線送信を妨害することがある。一例として、ブルートゥース送信は、別の周波数に移る前に、２００−３００マイクロ秒の間、ＷＬＡＮ送信と干渉することがある（周波数分離によって、干渉は低減又は増大する）。

あるいは、干渉は、ネットワーク内部の衝突トラフィックから発生することがある。そうしたトラフィックの例が、衝突パケット１２２であり、その衝突パケット１２２は、ＳＴＡ１０４ｂによって送信される。そうした衝突の結果、再送信は、例えばＷＬＡＮのような配置では、一般的で必要でさえあるかもしれない。

従って、従来のＷＬＡＮ ＭＡＣプロトコルの場合は、受信デバイス（例えばＡＰ１０２）は、正しく受信するパケットのために確認応答（ＡＣＫ）（ＳＩＦＳ時間の後に）を送信する。従って、送信デバイス（例えばＳＴＡ１０４ａ）は、送信信号を送り、受信デバイスからのＡＣＫを待つ。その送信デバイスが（ＳＩＦＳ時間後）所定期間内にＡＣＫを受信しないのなら、その送信デバイスは、パケット衝突を想定し、再送信信号を送信するチャネルを争いあう。

このチャネルコンテンションは、一般的には、送信デバイス（例えばＳＴＡ１０４ａ）が、コンテンションウインドウの大きさを倍にし、このウインドウ内のスロットの乱数を待ち、その後に再送信信号を送信することを含む。この動作は、パケット衝突に有効となるよう設計されている。しかし、そうした従来のＷＬＡＮ ＭＡＣプロトコルに関して、３つの観察がある。第一に、無作為な待ち時間は、ラテンシー（latency）を増加し、スループットを低減する。第二に、受信デバイスは、再送信のために、送信デバイスにアシスタンスを供給しない。第三に、そうしたコンテンションプロトコルは、パケット衝突によるパケット損失と、他の干渉タイプによるパケット損失との間で区別がつかない。

こうした観察は、現行の再送信手順（例えば、バックオフ及び倍のウインドウサイズ）が、これらの他の干渉タイプのため、パケット損傷の解消には有利でないことがあることを表している。従って、実施形態は、パケット損失の原因で区別する。こうした区別をすることにより、実施形態は、有意なパフォーマンスの向上をもたらす再送信及び干渉認識のリンク適応技術を提供する。

そうした技術は、損傷したパケットからの有用な情報を判定する受信デバイス（例えばＡＰ１０２）を含んでもよい。この情報から、受信デバイスは、続く送信（特に再送信）を作る際に、送信デバイスを支援（アシスト）してもよい。

無線ネットワーク（例えばＷＬＡＮ）では、データパケットは、復号化されたパケットにおいてショートエラーシーケンスを生ずることがある、集中的な干渉（干渉バースト）を受けやすい。そうしたショートエラーシーケンスは、（ブロックコードに代えて）畳み込みエラー訂正コードを採用するシステムには、より明らかである。データパケットは、ＭＡＣコントロール情報、例えば送信及び受信デバイスのアドレスなど、を含む。この情報（通常、パケットの最初のＭＡＣヘッダーに位置する）は、一般的には、全体のパケットの小さい部分のみを占める。従って、パケット内でバーストエラーが発生するときは、相対的に小さいＭＡＣヘッダーはそのまま（損傷なく）受信される可能性が高いだろう。

受信デバイスは、ＭＡＣヘッダーに応じたソフトビットのマグニチュード（即ち、復調されたビットの対数尤度）をチェックすることにより、損傷パケット内のＭＡＣヘッダーが成功裏に復号されたかを確認してもよい。より詳しくは、ソフトビットのマグニチュードが増加するに従って、ＭＡＣヘッダーを適切に受信する信頼性が増加する。例えば、ＷＬＡＮパケットの最初の２００−３００ソフトビットが大きなマグニチュードを有するのであれば、ＭＡＣヘッダーは非常に高い可能性で正確に復号化することができる。

従って、ソフトビットを使用することにより、受信デバイスは、ＭＡＣヘッダーの検出比を予想することが出来る。そうした予想は、周知の技術により実行されてもよい。例えば、そうした技術は、全体のパケットが受信される前に、ＭＡＣヘッダーの早期の検出に適用されてきた。この早期の検出は、省電力を可能にする（例えば、パケットのデータ部分の受領は、そのパケットが受信デバイスに意図されていないのなら、スキップされてもよい）。

パケットのＭＡＣヘッダーは、送信者のアドレスやパケットデュレーション（packet duration）などの有用な情報を含む。受信デバイスが損傷パケットのＭＡＣヘッダーを正確に復号化するとき、その受信デバイスは、再送信信号を送る際に送信デバイスをアシストするため、その情報を使用してもよい。このアシスタンスは、再送信のチャネルを予約することを含む。さらに、このアシスタンスは、使用を検討するため、送信デバイスのためのリンク適応示唆を含んでもよい。そうしたリンク適応示唆は、パケット断片化、変調符号方式（ＭＣＳ）及び／又は空間ストリーム情報を含んでもよい（しかし、これらに限定されない）。

実施形態の操作は、さらに、以下の図面と付随する例を参照して説明される。幾つかの図面は、ロジックフローを含む。ここで示される図面は、所定のロジックフローを含んでもよいが、そのロジックフローは、ここで説明する一般的な機能性がいかに実施されるかの例を、単に提供するものであることは理解されよう。さらに、所定のロジックフローは、他に示す場合を除き、必ずしも、表示の順序で実行される必要はない。加えて、所定のロジックフローは、ハードウェア要素、プロセッサにより実行されるソフトウェア要素、又は、それらのどのような組合せによっても実施されてもよい。実施形態は、この文脈に限定されない。

図２は、ロジックフロー２００を示す図であって、ここで述べる１つ以上の実施形態によって実行される操作の代表例であってもよい。図２は、所定のシーケンスを示すが、他のシーケンスが採用されてもよい。また、描かれた操作は、各種のパラレル及び／又はシーケンシャルの組合せで実行されてもよい。

図２のフローは、第１デバイス及び第２デバイスの文脈で説明される。第１デバイスは、モバイルステーション（例えば、図１のＳＴＡ１０４ａ）でもよく、第２デバイスは、アクセスポイント（例えば、図１のＡＰ１０２）でもよい。これらのデバイスは、ＷＬＡＮ（例えば、ＩＥＥＥ８０２．１１ネットワーク）に関与する。しかし、実施形態は、ＷＬＡＮや図１の文脈に限定されるものではない。

ブロック２０２では、第１デバイスは、第２デバイスに送信信号（トランスミッション）を送る。この送信信号は、ＣＳＭＡのようなコンテンションベースのアクセス方式に従って送られるパケットであってもよい。ブロック２０４では、第２デバイスは、この送信信号を受信する。

ブロック２０６では、第２デバイスは、受信した送信信号が損傷しているかどうかを判定する。これは、エラー検出復号化、周期的冗長性チェック、及び／又は他の技術を実行することを含んでもよい。また、これは、受信した送信信号のＭＡＣヘッダーから様々な情報を推定する第２デバイスを含んでもよい。例えば、第２デバイスは、自分がパケットの受信者であること、及び、第１デバイスがパケットの送信デバイスであると判定してもよい。ここで説明するように、第２デバイスは、この情報を使用して、損傷した送信信号の再送信を予定してもよい。従って、従来のＷＬＡＮ（例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎシステム）と異なり、実施形態は、要求される再送信を提供する。

図２で示されるように、第２デバイスは送信信号が損傷していないと判定すると、ブロック２０８へ操作が続く。ブロック２０８では、第２デバイスは、１つ以上のプロトコルレイヤーに従って、送信信号を処理する。さらに、送信が正しく受信されているなら、ブロック２０８は、送信デバイスに応じて、確認応答（ＡＣＫ）を送信することを含んでもよい。

しかし、第２デバイスが送信信号が損傷していると判定すると、ブロック２１０へ操作が続く。ブロック２１０では、第２デバイスは、損傷の起こり得る原因を判定する。これは、ソフトビット値を処理する第２デバイスを含んでもよい。ブロック２１０の判定に関する例示的な詳細は、図３を参照して以下で説明される。

図２は、第２デバイスが、ネットワーク内のパケット衝突が損傷を起こしていると判定すると、操作はブロック２１２へ続く。しかし、第２デバイスが、損傷がそうした衝突原因から生じていないと判定すると、操作はブロック２１４へ続く。

ブロック２１２では、第２デバイスは、コンテンションベースのアクセス方式に従って、動作する。従って、ＣＳＭＡアクセスにとって、第２デバイスは、確認応答を送らない。これに基づいて、第１デバイスは、ブロック２１３で、（やがて）確認応答がないことを認識するだろう。

このことから、第１デバイスは、ブロック２１５で、再送信信号を送るメディアアクセスを競い合う。この競い合い（コンテンション）は、採用されるコンテンションベースのアクセス方式（例えば、ＣＳＭＡ、ＣＳＭＡ／ＣＤなどの）に従う。従来のＷＬＡＮの文脈では、これは、ＳＩＦＳがタイムアウトするまで待ち、最初からチャネルを争うことを含む。例えば、第１デバイスは、カウントダウンの前に、まず、コンテンションウインドウを１５から３１へ倍にしてもよい。従って、その平均の待ち時間は、１５スロットである（即ち、８０２．１１ａネットワークの１３５マイクロ秒）。

あるいは、ブロック２１４では、第２デバイスは、第１デバイスに、再送信アシスタンスを供給する。これは、第１デバイスにメディアアクセスを供給するチャネルを予約することを含んでよい。さらに、これは、第１デバイスに１つ以上のリンク適応示唆を供給することを含んでよい。そうしたアシスタンスに関する例示的詳細は、図４を参照して、以下で説明する。

図２は、ブロック２１６で、第１デバイスがアシスタンスを受けることを示す。このアシスタンスに従って、第１デバイスはブロック２１８で再送信信号を送信する。

上述したように、受信デバイス（例えば、図２の第２デバイス）は、パケット損傷の原因を判定してもよい。そうした判定の例示的なロジックフロー３００は、図３に示される。図３は、所定のシーケンスを示すが、他のシーケンスが採用されてもよい。また、示される操作は、様々なパラレルな、及び／又は、シーケンシャルな組合せで実行されてもよい。

ブロック３０１では、受信デバイスは、受信した送信信号（トランスミッション）を分析する。図３で示すように、これは、ブロック３０２と３０８とを含む。ブロック３０２では、受信デバイス（例えば多数の受信アンテナを備えたもの）は、パケットを検出する間、受信した信号サンプルをモニタする。これは、他のプリアンブル及び／又はチャネルトレーニングシンボルが他のデバイスから来ているかどうかを検出するために行われてもよい。ブロック３０４では、他のプリアンブル及び又はチャネルトレーニングシンボルが、受信したパケットのデータ検出中に検出されるかどうかを判定する。もしそうであれば、受信デバイスは、ブロック３０６で、衝突が発生したかどうかを判定する（あるいは隠れノードから）。

ブロック３０８では、受信デバイスは、受信した送信信号のソフトビット値を検査する。これらの値から、一群の連続ソフトビットのマグニチュードが小さいかどうかを判定する（ブロック３１０で）。もしそうでれば、受信デバイスは、干渉のバーストが発生したことを判定する（ブロック３１２で）。

図３は、衝突するプリアンブル（及び／又はチャネルトレーニングシンボル）も、バースト干渉損傷も検知されないなら、受信デバイスは、パケット失敗が熱ノイズにより発生したことを判定する（ブロック３１４で）ことを示す。

上述したように、受信デバイスは、送信デバイスに、再送信信号を送る際のアシスタンスを供給してもよい。そうしたアシスタンスは、送信デバイスが、従来のコンテンションベースのアクセス方式によって、別なふうに経験する待ち時間を取り除くのに役立つことがある。図４は、そうしたアシスタンスの例示的なロジックフロー４００を提供する。

図４で示されるように、（ブロック４０１で）受信デバイスは、１つ以上のリンク適応示唆（もしあれば）を判定する。実施例では、各種の示唆が判定されてもよい。例えば、受信デバイスは、もし、失敗がバースト干渉に起因するものであれば、送信デバイスが再送信されたパケットを断片化することを示唆してもよい。また、もし、パケット失敗がサーマルノイズに起因するものであれば、受信デバイスは、送信デバイスがその変調／符号方式（ＭＣＳ）の割合を低下することを示唆してもよい。さらに、受信デバイスは、送信デバイスがそのコンテンションウインドウサイズを増加しないことを示唆してもよい。また、受信デバイスは、その受信デバイスと共に用いる空間ストリームの数を、送信デバイスが変更することを示唆してもよい。これらの示唆は、例示目的であって、限定ではない。これらの示唆の種類（タイプ）の如何なる組合せが採用されてもよい。さらに、幾つかの実施形態が、他の種類の示唆を採用してもよい。

上述したように、実施形態は、用いられる空間ストリームの数を変更することを示唆してもよい。例えば、応答（図５を参照して、以下に述べられるパケットのような）が、送信デバイスによって用いられる空間ストリームの数を変更するよう示唆してもよい。その空間ストリームの減少は、受信者の干渉をゼロにする容量を増大させる。例えば、干渉（例として、パーソナルコンピュータ上のバスクロック等のプラットフォームノイズによって生ずる干渉）は、受信デバイスのアンテナアレイに、各副搬送波の或る空間方向から、影響を及ぼす。多数の受信アンテナを使用することで、受信デバイスは、干渉をゼロにするため、干渉ソースの方向へのヌルポインティング（null pointing）を形成することができる。もし、多重データストリームが送信デバイスによって送られるのなら、受信デバイスは、多重データストリームを受信する間の干渉をゼロにするのに充分なアンテナを有しないかもしれない。

ブロック４０２では、受信デバイスは、送信チャネルが利用可能であるかを判定する。実施形態では、これは、ＣＳ／ＣＣＡによるチャネルセンシングの実行を含んでもよい。ブロック４０４では、そのチャネルが利用可能かどうかを示し、もしそうならば、ブロック４０６が実行される。ブロック４０６では、受信デバイスが再送信のためのチャネルを予約する。これは、１つ以上の応答を送信デバイスに送ることを含んでもよい。例えば、ブロック４０６は、ＣＴＳパケットを送信デバイスに送る受信デバイスを含んでもよい。

ブロック４０８では、送信デバイスは、受信デバイスから応答を受信する。その応答が意図する受信者であると判定した後、送信デバイスは、ブロック４１０で、応答を処理する。ここで述べるように、応答は、ＣＴＳパケットの形式であってもよい。従って、４１０での処理は、ＲＴＳが、プレリュードとしてＣＴＳに送られたかどうかの判定を含んでもよい。もし、送信デバイスが、それがデータ送信許可要求（ＲＴＳ）をＣＴＳの直前に送らなかったと判定すれば、送信デバイスは、そのＣＴＳをＮＡＣＫと解釈する。

従って、ブロック４１２では、送信デバイスは、当初送られたパケットを再送信する（図２のブロック２１６を参照して上記で説明したように）。ＩＥＥＥ８０２．１１ネットワークの文脈では、これは、ＳＩＦＳタイムインターバルの発生後に発生してもよい。

ブロック４１４では、受信デバイスは、その再送信信号を受信したかどうかを判定する。これは、プリアンブルが検出されたかどうかの判定を含んでもよい（例えば、ＳＩＦＳタイムインターバルの後に）。

もし、その再送信信号が受信されたのなら、受信デバイスは、ブロック４１６で、その再送信を処理する。これは、エラー検出復号化、周期的冗長性チェック、１つ以上のプロトコルレイヤーに従う操作、及び／又は、各種の他の操作の実行を含んでもよい。さらに、もし、その再送信が正しく受信されたのなら、ブロック４１６は、確認応答（ＡＣＫ）を送信デバイスに送ることを含んでもよい。

しかしながら、もし再送信信号が受信されなかったのなら、受信デバイスは、送信デバイスがブロック４０８で送られた応答を解釈できないと決定してもよい。例えば、ＩＥＥＥ８０２．１１ネットワークの文脈では、送信デバイスは、ＣＴＳ応答をＮＡＣＫとして解釈できない既存のデバイスであってもよい。故に、これは、もしチャネルがクリアなら、ＣＦ−Ｅｎｄパケットを送ることを含んでもよい。幾つかの実施形態では、ブロック４１８は、所定の応答数が送られた後に実行されてもよい。

上記の説明は、或る受信デバイスが、パケット失敗を生じた干渉の種類に関する情報を判定してもよいことを示す。この情報から、受信デバイスは、そうしたパフォーマンス制限の干渉に対処する技術を含んでもよい。上述のように、そうした技術は、パケット断片化設定、コンテンションウインドウ設定、空間ストリーム設定、及び／又は、ＭＣＳ設定の示唆を含んでもよい（しかし、限定されない）。また、受信デバイスは、再送信を容易にしてもよい（例えばチャネルの予約）。

受信デバイスは、そうした示唆、及び／又は、チャネル予約を、送信デバイスへ、１つ以上のＭＡＣコントロールメッセージで送ってもよい（例えば図４のブロック４０６で）。実施形態では、受信デバイスは、そうした支援（ヘルプ）を単一の応答パケットの中に統合してもよい。そうした応答パケットの例が図５に示される。

詳しくは、図５は、受信デバイス（例えばＡＰ１０２）が、送信デバイス（例えばＳＴＡ１０４ａ）から受信する損傷パケット５０２を示す。損傷パケット５０２は、複数の損傷ビット５０６ａ―ｄを有するデータ部分５０４を含む。その結果、データ部分５０４は、受信することができない（例えば、正しく復号化）。また、図５は、損傷パケット５０２は、損傷していないＭＡＣヘッダー部分５０７を有する。このヘッダーは、例えば送信デバイスと受信デバイスのＭＡＣアドレスといった情報を含む。

損傷していないＭＡＣヘッダー部分５０７から、受信デバイスは、損傷パケット５０２がその受信デバイスを目的としていたことを判定してもよい。その結果、受信デバイスは、応答パケット５０８を生成し、それを送信デバイスに送る。上述のように、応答パケット５０８は、統合情報を含んでもよい。例えば、図５は、応答パケット５０８が、送信者アドレス５１０、再送信要求５１２、予約期間５１４、ＭＣＳ調節インジケータ５１６、コンテンションウインドウサイズ調節インジケータ５１８、及び、空間ストリーム調節インジケータ５１９（採用される空間ストリーム数の調節を示唆する）を含む。しかしながら、実施形態はこの例に限定されない。故に、応答パケットは、他の情報の組合せを含んでもよい。

応答パケット５０８内の情報は、一緒に符号化又はインデックスを付けられてもよい。例えば、実施形態では、ＭＣＳ調節インジケータ５１６、コンテンションウインドウサイズ調節インジケータ５１８、及び、空間ストリーム調節インジケータ５１９は、それぞれ３つの値（即ち、増加、減少、及び変化なし）を有してもよい。これらの２つのインジケータは、２ビットの代わりに３ビットで、一緒に符号化することが可能である。また、実施形態では、送信者アドレス５１０は、もしその送信者のアドレスが損傷したパケット５０２において確実に復号化されていなかったのなら、空であってもよい。

図５の応答パケットへの代替として、実施形態は、現行のＩＥＥＥ８０２．１１標準規格に準拠するパケットを用いてもよい。例えば、受信デバイスは、ＣＴＳパケットを送信デバイスに送ってもよい。このＣＴＳパケットは、送られるべき再送信のためのチャネルを保護するため、ＮＡＶを含んでもよい。そのＣＴＳパケットは、ＮＡＶを設定することで、送信デバイスの再送信のためのチャネルを予約する。もし、その前回の受信エラーが、隠れノード送信に起因するものであるなら、そのＣＴＳパケットは、その隠れノードからの送信をブロックし、それにより、送信デバイスの再送信を保護する。

図６は、ここで述べる技術を採用する例示的な実装６００を示す図である。この実装は、図１のＡＰ１０２，ＳＴＡ１０４ａ、及び／又は、ＳＴＡ１０４ｂのような無線デバイスの中に含まれてもよい。しかしながら、この実装は、他の文脈においても採用されてもよい。実装６００は、各種の要素を含んでもよい。例えば、図６は、マルチアンテナ６０２ａ―ｃ、トランシーバーモジュール６０４、ホストモジュール６０６、パケット失敗分析モジュール６０７、及び再送信管理モジュール６０８を含んだ実装６００を示している。これらの要素は、ハードウェア、ソフトウェア、又は、それらの任意の組合せで実現されてもよい。

アンテナ６０２ａ―ｃは、無線信号をリモートデバイスと交換する。３つのアンテナが描かれるが、任意の数のアンテナが用いられてもよい。また、実施形態は、１つ以上の送信アンテナ及び１つ以上の受信アンテナを用いてもよい。そうしたマルチアンテナ構成は、ビーム形成のため、及び／又は、多重空間ストリームのため、リモートデバイスとともに用いられてもよい。

図６で示されるように、トランシーバーモジュール６０４は、送信部分６１０と受信部分６１２とを含む。動作中は、トランシーバーモジュール６０４は、アンテナ６０２ａ―ｃと、例えば、ホストモジュール６０２、パケット失敗分析モジュール６０７、及び／又は、再送信管理モジュール６０８といった他の要素との間のインターフェースを供給する。例えば、送信部分６１０は、そうした要素からシンボルを受信し、１つ以上のアンテナ６０２ａ―ｃによる無線送信のための対応する信号を生成する。これは、例えば、変調、増幅、及び／又は、フィルタリングといった操作を含んでもよい。しかし、他の操作が用いられてもよい。

反対に、受信部分６１２は、１つ以上のアンテナ６０２ａ―ｃにより受信される信号を取得し、対応するシンボルを生成する。順々に、これらのシンボルは、ホストモジュール６０６、パケット失敗分析モジュール６０７、及び／又は、再送信管理モジュール６０８といった要素に供給されてもよい。このシンボル６２６の生成は、復調、増幅、及び／又はフィルタリングを含んだ操作を有してもよい（しかし限定されない）。

トランシーバーモジュール６０４によって生成され受信される信号は、様々な形式であってもよい。例えば、これらの信号は、直交周波数分割多重（ＯＦＤＭ）方式に従って変調されてもよい。しかしながら、他の方式や形式（例えば、ＱＰＳＫ，ＢＰＳＫ，ＦＳＫ等）が用いられてもよい。

こうした諸機能を供給するため、送信部分６１０と受信部分６１２の各々は、変調器、復調器、増幅器、フィルタ、バッファ、アップコンバーター、及び／又は、ダウンコンバーターといった様々なコンポーネントを含んでもよい。そうしたコンポーネントは、ハードウェア（例えば、電子部品）、ソフトウェア、又は、それらの如何なる組合せで実現されてもよい。

トランシーバーモジュール６０４と他の要素との間で交換されるシンボルは、１つ以上のプロトコル、及び／又は、１つ以上のユーザーアプリケーションに従ったメッセージ又は情報を形成してもよい。故に、これらの要素は、そうしたプロトコル及び／又はユーザーアプリケーションに対応した操作を実行してもよい。例示のプロトコルは、各種のメディアアクセスコントロールとディスカバリープロトコルを含む（しかし限定されない）。例示のユーザーアプリケーションは、電話、メッセージング、電子メール、ウェブブラウジング、コンテンツ（例えば動画や音声）配信／受信、等々が含まれる。

更にまた、信号を送信するとき、トランシーバーモジュール６０４は、様々な技術を用いてもよい。例えば、トランシーバーモジュール６０４は、ＣＳＭＡ，ＣＳＭＡ／ＣＡ等々のコンテンションベースの技術を用いてもよい。しかし、実施形態は、こうした技術に限定されない。

実施形態では、パケット失敗分析モジュール６０７は、トランシーバーモジュール６０４によって受信されたパケットの損傷の、起こり得る原因を判定する。この判定は、ここで述べる技術に従ってもよい。従って、パケット失敗分析モジュール６０７は、受信部分６１２から、各種の情報を受信してもよい。例えば、図６は、この情報が、パケット失敗インジケータ６２０、復号化された損傷パケット６２２、及び、パケットの対応ソフトシンボル値６２４を含んでもよい。

この情報から、パケット失敗分析モジュール６０７は、パケット失敗の起こり得る原因を判定してもよい。実施形態では、この判定は、図３の技術に従ってもよい。しかし、実施形態は、この例に限定されない。

この判定結果に基づいて、図６は、パケット失敗分析モジュール６０７が失敗原因インジケータ６２６を再送信管理モジュール６０８へ送ってもよいことを示す。再送信管理モジュール６０８は、再送信の操作を管理する。例えば、失敗原因インジケータ６２６の受信に基づいて、再送信管理モジュール６０８は、その失敗したパケットの再送信信号を供給するよう操作を実行してもよい。加えて、再送信管理モジュール６０８は、ここで述べるように、リモートのデバイスのために１つ以上の示唆を判定してもよい。従って、ここで述べるように、送信部分６１０と共同で、再送信管理モジュール６０８は応答をリモートデバイスに送信してもよい。

追加的に又は代替的に、再送信管理モジュール６０８は、また、失敗パケットを送るデバイスの諸機能を供給してもよい。例えば、再送信管理モジュール６０８は、リモートデバイスから（例えば、受信部分６１２を通じて）受信した予約、及び／又は、示唆を扱ってもよい。順々に、再送信管理モジュール６０８は、送信部分６１０を、予約及び／又は応答に従って、操作するように方向付けてもよい。

ホストモジュール５０６は、リモートデバイスと交換される無線信号に対応するシンボルを、トランシーバーモジュール５０４と交換してもよい。これらのシンボルは、１つ以上のプロトコル、及び／又は、１つ以上のユーザーアプリケーションに関連するメッセージ又は情報を形成してもよい。故に、ホストモジュール５０６は、そうしたプロトコル及び／又はユーザーアプリケーションに対応する操作を実行してもよい。例示のプロトコルは、様々なメディアアクセス、ネットワーク、トランスポート、及び／又は、セッションレイヤーのプロトコルを含む。例示のユーザーアプリケーションは、電話、メッセージング、電子メール、ウェブブラウジング、コンテンツ（例えば動画や音声）配信／受信、等々を含む。

ここで述べるように、様々な実施形態は、ハードウェア要素、ソフトウェア要素、又はそれらの如何なる組合せをも使用して実現してもよい。ハードウェア要素の例には、プロセッサ、マイクロプロセッサ、回路、回路要素（例えば、トランジスタ、レジスタ、キャパシタ、インダクタ、等々）、集積回路、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能ロジックデバイス（ＰＬＤ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ロジックゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、等々を含む。

ソフトウェアの例には、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、マシーンプログラム、オペレーションシステムプログラム、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、ファンクション、方法、プロシージャ、ソフトウェアインターフェース、アプリケーションプログラムインターフェース（ＡＰＩ）、インストラクションセット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値（バリュー）、シンボル、又はそれらの任意の組合せを含む。

幾つかの実施形態は、例えば、保存メディア又は機械可読のアーティクル（article）を用いて実現してもよい。保存メディアは、インストラクション、又はインストラクションセットを保存してもよく、（もしそのインストラクションが機械によって実施されるのなら）その機械に、実施形態に従った方法及び／又は操作を実行させる。そうした機械は、例えば、任意の適切なプロセッシングプラットフォーム、コンピューティングプラットフォーム、コンピューティングデバイス、プロセッシングデバイス、コンピューティングシステム、プロセッシングデバイス、コンピュータ、プロセッサ、又は類似するものを含み、ハードウェア及び／又はソフトウェアの任意の適切な組合せを使用して、実現してもよい。

保存メディア又はアーティクルは、例えば、任意の適切なタイプのメモリユニット、メモリデバイス、メモリアーティクル、メモリメディア、保存デバイス、保存アーティクル、保存メディア、及び／又は、保存ユニット、例えば、メモリ、着脱可能又は着脱不可能なメディア、消去可能又は消去不可能なメディア、書き込み可能又は書き換え可能メディア、デジタル又はアナログメディア、ハードディスク、フロッピー（登録商標）ディスク、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、記録可能コンパクトディスク（ＣＤ−Ｒ），書き換え可能ンパクトディス（ＣＤ−ＲＷ）、光学ディスク、磁気メディア、光磁気メディア、着脱可能メモリカード又はディスク、各種のデジタルビデオディスク（ＤＶＤ）、テープ、カセット、又は類似するものを含む。インストラクションは、例えば、ソースコード、コンパイルされたコード、インタープリター型コード、実行コード、静的コード、動的コード、暗号化コード、及び類似するものといった各種の任意のコードを含んでもよく、任意の高レベル、低レベル、オブジェクト指向、ビジュアル型、コンパイル型、及び／又は、インタープリター型プログラミング言語を用いて実現してもよい。

本発明の様々な実施形態が上記で説明されたが、それらの実施形態は、説明目的でのみ示されたものであって、限定ではないことは理解されるべきである。例えば、ここで説明された技術は、ＩＥＥＥ８０２．１１ネットワークに限定されない。従って、これらの技術は、指向送信、再使用（リユース）、及び／又は、予定したメディアアクセス技術の任意の組合せを用いる他のネットワークにおいても用いられてよい。

さらに、ここで述べられた技術は、ステーションとアクセスポイントとの間の通信の文脈に限定されない。故に、これらの技術は、各種のビアツーピア（peer-to-peer）の文脈で使用されてもよい。ピアツーピア実装においては、一方の応答（例えば、ＮＡＣＫ−ＣＴＳ）が他方の応答（例えば、ＮＡＣＫ−ＣＴＳ）に衝突し、もし、最初のパケットエラーがパケット衝突に起因するものであれば、より長い遅延を発生することがあることが懸念されるかもしれない。しかし、こうしたことは起こりえない。例えば、もし最初に衝突したパケットが同時にスタートしたのなら、両方のＭＡＣアドレスヘッダーのソフトビットのマグニチュードは小さい。従って、復号化ＭＡＣヘッダーは、使用されず、どのＮＡＣＫ−ＣＴＳも送られない。しかしながら、もし最初に衝突したパケットが一方を他方よりも早くスタートさせたのなら、その早い方のＭＡＣヘッダーは正しく受信され、故に１つのＮＡＣＫ−ＣＴＳだけが送られる。

従って、本発明の精神と適用範囲から逸脱することなく、形式と詳細の各種の変更がそこになされることが可能であることは、関連分野の当業者には明らかだろう。故に、本発明の幅と範囲は、上述の例示的実施形態の何れによっても限定されるべきではなく、以下の特許請求の範囲とその均等物に従ってのみ定義されるべきである。

Claims (21)

1. 送信デバイスからパケットを受信するステップであって、前記パケットは損傷を有する、ステップ；
   前記損傷の原因を判定するステップであって、前記受信したパケットのデータ検出の期間内において、他のプリアンブル及びチャネル・トレーニング・シンボルのうちの少なくとも一つが検出されるならば、前記損傷の原因はネットワーク内のパケット衝突であると判定される、ステップ；
   判定された前記損傷原因がネットワーク内のパケット衝突であるときは、コンテンションベースのアクセス方式に従って、前記送信デバイスに前記パケットの再送信を送ることを許容するステップ；及び、
   判定された前記損傷原因がネットワーク内のパケット衝突以外であるときは、前記送信デバイスに再送信アシスタンスを供給するステップ；を含む、方法であって、
   当該再送信アシスタンスを供給するステップは、１つ以上のリンク適応示唆を前記送信デバイスに供給するステップを含む、
   方法。
2. 前記再送信アシスタンスを供給するステップは、応答を前記送信デバイスに送るステップを含む、請求項１記載の方法。
3. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、変調符号方式（ＭＣＳ）調整を含む、請求項１記載の方法。
4. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、パケット断片化設定を含む、請求項１記載の方法。
5. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、コンテンション・ウィンドウ調整を含む、請求項１記載の方法。
6. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、空間ストリーム数の調整を含む、請求項１記載の方法。
7. 前記コンテンションベースのアクセス方式は、搬送波感知多重システム（ＣＳＭＡ）方式を含む、請求項１記載の方法。
8. 前記損傷の原因を判定するステップには、前記受信したパケットのソフトビットを分析するステップを含む、請求項１記載の方法。
9. 前記損傷の原因を判定するステップには、一群の連続ソフトビットが小さい値を有するときに、干渉のバーストが発生したものと決定するステップを含む、請求項８記載の方法。
10. コンテンションベースのアクセス方式に従って、送信デバイスからパケットを受信するトランシーバーモジュールであって、前記パケットは損傷を有し；
    前記損傷の原因を判定する、パケット失敗分析モジュールであって、前記受信したパケットのデータ検出の期間内において、他のプリアンブル及びチャネル・トレーニング・シンボルのうちの少なくとも一つが検出されるならば、前記損傷の原因はネットワーク内のパケット衝突であると判定される、パケット失敗分析モジュール；及び、
    判定された前記損傷原因がネットワーク内のパケット衝突以外であるとき、再送信アシスタンスを前記送信デバイスに供給する、再送信管理モジュール；
    を有する、装置であって、
    当該再送信アシスタンスは、前記送信デバイスによる前記パケットの再送信のためのチャネル予約、及び／又は、前記送信デバイスのための１つ以上のリンク適応示唆を含む、
    装置。
11. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、変調符号方式（ＭＣＳ）調整を含む、請求項１０記載の装置。
12. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、パケット断片化設定を含む、請求項１０記載の装置。
13. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、空間ストリーム数の調整を含む、請求項１０記載の装置。
14. 前記送信デバイスのための前記１つ以上のリンク適応示唆は、コンテンション・ウィンドウ調整を含む、請求項１０記載の装置。
15. 前記判定された損傷の原因がネットワーク内のパケット衝突であるときは、前記再送信管理モジュールは、前記送信デバイスに、前記コンテンションベースのアクセス方式に従って、パケットの再送信を許容する、請求項１０記載の装置。
16. 前記コンテンションベースのアクセス方式は、搬送波感知多重アクセス（ＣＳＭＡ）方式である、請求項１０記載の装置。
17. パケット損傷の原因がネットワーク内のパケット衝突であると判定された時には、パケットを、コンテンションベースのアクセス方式に従って、送信デバイスに送り、そして、パケット損傷の原因がネットワーク内のパケット衝突以外の原因であると判定された時には、受信デバイスから前記パケットへの応答を受信する、トランシーバーモジュールであって、前記応答は、１つ以上のリンク適応示唆とを含み、前記受信したパケットのデータ検出の期間内において、他のプリアンブル及びチャネル・トレーニング・シンボルのうちの少なくとも一つが検出されるならば、前記損傷の原因はネットワーク内のパケット衝突であると判定される、トランシーバーモジュール；及び、
    前記トランシーバーモジュールに、前記チャネル予約と前記１つ以上のリンク適応示唆とに従って、パケットの再送信を送るよう方向付ける、再送信管理モジュール、
    を含む、装置。
18. 前記１つ以上のリンク適応示唆は、変調符号方式（ＭＣＳ）調整を含む、請求項１７記載の装置。
19. 前記１つ以上のリンク適応示唆は、パケット断片化設定を含む、請求項１７記載の装置。
20. 前記１つ以上のリンク適応示唆は、コンテンション・ウィンドウ調整を含む、請求項１７記載の装置。
21. 前記コンテンションベースのアクセス方式は、搬送波感知多重アクセス（ＣＳＭＡ）方式を含む、請求項１７記載の装置。

Images