JP5852128B2 - バースト的ノイズ環境に対する通信技術 - Google Patents

Description

本発明は、バースト的ノイズ環境に対する通信技術に関する。

高データ転送速度のアプリケーションを提供する無線通信技術が次第に多くの機器において利用されるようになってきている。これらのアプリケーションの例としては、限定するものではないが、ビデオストリーミングパーソナルエリアネットワーク（ＰＡＮ）モード及びワイヤレスディスプレイ（ＷｉＤｉ）アプリケーションが挙げられる。このようなアプリケーションでは、パケットロスに対して非常に敏感である。例えば、ＷｉＤｉでは、１つのパケットロスによって、画像フレームの破壊を招き、画像の「縞模様（banding）」問題が発生することとなる。更に、継続したパケットロスは、画像の大きな影響を与え、フリーズする結果を招く。

無線通信は、様々なソースからの妨害ノイズの影響をしばしば受ける。例えば、家庭環境において、バーストノイズは、産業科学医療用（ＩＳＭ）周波数バンド（２．４−２．５ＧＨｚ）では、よく発生する。このようなノイズは、電子レンジ、近くにあるラジオ、及びその他のデバイスによるものである。典型的には、オン／オフスイッチの際のこのノイズは、非常に短い。したがって、チャネルの品質は、２つの状態（空き（clear）及び混雑状態（jammed））の間を非常に速く行き来する。

リンクアダプテーション技術は、妨害ノイズの影響を減少させるために採用され得る。しかしながら、従来のリンクアダプテーション技術は、混雑と空きの状態の間で高速に変化することに対しては、対処できるものではなかった。このため、この技術は、低いデータ転送速度を持つ変調及び符号化方式（ＭＣＳ）を採用する点に単に関連しているだけである。残念なことに、このために、速度は許容されるレベルを下回ることとなる。

本発明の一側面によって、１つ以上の試験パケットを、ソースデバイスから宛先デバイスに送信するステップと；前記１つ以上の試験パケットの応答結果に基づいて、レート適応送信技術、及びレート適応でない送信技術のいずれかを選択するステップと；
１つ以上のデータパケットを、前記選択された送信技術に従って、前記ソースデバイスから前記宛先デバイスに送信するステップと；を有する方法が提供される。

様々なソースからのノイズを示す図である。 様々なソースからのノイズを示す図である。 様々なソースからのノイズを示す図である。 例示的な動作環境のブロック図である。 論理フローを示す図である。 例示的なコントロールパケットの図である。 例示的なコントロールパケットの図である。 典型的なＲＴＳ／ＣＴＳプロテクション方式を示す図である。 典型的なＲＴＳ／ＣＴＳプロテクション方式を示す図である。 試験的な交換を示す図である。 試験的な交換を示す図である。 例示的なデバイスの相互通信を示す図である。 例示的なデバイスの相互通信を示す図である。 フローチャートを示す図である。 パフォーマンス特徴を示す図である。 無線通信デバイスの例示的インプリメンテーションを示す図である。

図面において、同様の参照番号は、同一、機能的に同様、及び／又は構造的に同様の要素を示す。参照番号の左側の番号は、図面の番号を表している。本発明に関して、図面を参照しながら説明する。

実施例によって、バースト的なノイズ環境における通信に対する技術を提供する。例えば、ソースデバイスは、試験パケットを宛先デバイスに送信する。この試験パケットは、通信メディア（例えば、１つ以上の周波数チャネル）が、現在（例えば、バースト的ノイズのために）ビジーであるか又は混雑した状態であるかを判断するものである。より具体的には、試験パケットの肯定応答が受信されたか否かに基づいて、ソースデバイスは、そのチャネルが混雑しているか（又はビジーであるか）又は空いているか（clear）を判断する。

例えば、肯定応答を得ていない試験パケットは、チャネルが混雑しているか又はビジーであることを示している。これに対して、肯定応答を得ている試験パケットは、チャネルが空いていることを示している。このチャネルが空いていると判断されることを示す場合、ソースデバイスは、１つ以上のデータパケットを宛先デバイスに送信することができる。このようなデータパケットの伝送は、レート適応によらない技術に基づいている。実施例は、ＩＥＥＥ８０２．１１ネットワーク（例えば８０２．１１ａ／ｂ／ｇ／ｎネットワーク）に利用し得る。しかしながら、実施例は、これらのネットワークに限定されるものではない。

上述のように、バースト的なノイズは、併存している、又は近くに存在する無線エネルギー源によりもたらされることが多い。異なるソース毎に、異なるバースト的な特徴の強度を有する。例えば、近くに存在するブルートゥース（登録商標）無線は、１０％ないし４０％のデューティサイクルで妨害を与える。従来の電子レンジは、１０％のデューティサイクルで妨害を与える。インバータタイプの電子レンジは、５０％ないし６０％のデューティサイクルで妨害を与える（これらは、通信トラフィックパターンに依存する）。

図１Ａないし図１Ｃは、異なる複数のソースからの妨害を示している。例えば、図１Ａのグラフ１００は、電子レンジからの妨害を示している。図１Ｂのグラフ１１０は、（ＳＣＯリンクによる音声トラフィックのための）ブルートゥース無線の妨害を示している。

図１Ｃのグラフ１２０は、（５メガビット／秒（Ｍｂｐｓ）アップリンクトラフィックの）ＷｉＦｉ（ＩＥＥＥ８０２．１１）無線からの妨害を示している。

上述のように、リンク適応技術は、妨害及びノイズに対処するために採用される技術である。従来のリンク適応技術は、パケットが正しく受信されない場合、データ転送速度を低下させる傾向がある。このような従来技術は、バースト的でないノイズに適している。例えば、付加ホワイトガウスノイズが挙げられる。この理由は、これらのノイズが常に発生していると仮定されているからである。したがって、このような、常に発生するノイズに対して、（低いビットエラー確率を提供することによって）データ転送速度を低下させることは効果的である。

しかしながら、通常の「現実の生活」の環境においては、バースト的なノイズ（たとえば、「オン」「オフ」の時間）が発生する。このようなバースト的なノイズによって、従来のレート適応技術は、効果的ではない。なぜなら、バースト的なノイズが存在する場合、データ転送速度／またはＭＣＳを低下させることは、データ転送の時間（たとえば、ＷｉＦｉパケット）を増加させるばかりでなく、バースト的なノイズに衝突するデータパケットの確率を増加させる。このため、ＷｉＦｉのパフォーマンスは、結果的に低下してしまう。

従来のアプローチとは異なり、実施例では、バースト的なノイズ環境に直面した場合には、データ転送速度を減少させることを控える。この結果、パケットの時間は増加しない。これは、好適に、バースト的なノイズ環境下におけるエラーフリーの通信の確率を増加させるのである。

図２は、例示的な動作環境２００を示している。この環境において、第１のデバイス２０２は、無線で第２のデバイス２０４にデータ送信２３０を行う。しかしながら、この無線送信は、妨害によりエラーが発生する。たとえば、図２において、妨害しているデバイス２０６は、妨害送信２３２を発生させる。これは、データ送信２３０が正確にデバイス２０４によって受信されることを阻止する。

このような妨害送信は、バースト的に発生する。たとえば、例示的な送信は、図１に示すような特徴を呈する。したがって、妨害しているデバイス２０６は、たとえば、電子レンジ、併存又は近隣の無線機（ＷｉＦｉ無線、ブルートゥース無線等）又はバースト的妨害のその他のソースが挙げられる。

実施例において、デバイス２０２は、通信メディア（たとえば無線チャネル）が、現在バースト的ノイズの状態にあるか否か、又は、通信メディアが現在、実質的にバースト的なノイズが無い状態であるか否かを判断する、試験技術（probing technique）によって、バースト的な妨害を取り扱うことができる。このような判断に基づいて、デバイス２０２は、対応する通信技術を採用することができる。

実施例において、図２の環境は、無線ディスプレイ（ＷｉＤｉ）アプリケーションに関連する（なお、これらに限られるものではない）。デバイス２０２は、たとえばパーソナルコンピュータ（ＰＣ）、ノートブック又はラップトップコンピュータ、あるいは、その他の適切なデバイス等の、コンピューティングプラットフォームである。そして、デバイス２０４は、ディスプレイであってもよい。動作中において、デバイス２０２は、ディスプレイデータ（例えば、データ送信２３０）をデバイス２０４に送信する。このデータは、様々なディスプレイ、ビデオ、及び／又は画像符号化フォーマットにエンコードされる。受信すると、デバイス２０４は、受信したディスプレイデータをデコードし、表示する。

デバイス２０２は、様々な要素を含み、これらは、ハードウエア、及び／又はソフトウエアのいかなる組み合わせによってもインプリメントされ得る。例えば、図２において、デバイス２０２は、ＷｉＤｉモジュール２１０を含む。これは、無線ディスプレイデータ送信を生成する。このディスプレイデータは、デバイス２０２で動作している１つ以上のアプリケーション及び／又はプロセス２１２によって提供される。このようなアプリケーション／プロセスは、ハードウエア及び／又はソフトウエアのあらゆる組み合わせによって実行され得る。実施例として、図２において、デバイス２０２は、記憶媒体（例えばメモリ）２１６を含み、記憶媒体はこれらのアプリケーション及び／又はプロセスに関連する命令を格納する。また、図２において、デバイス２０２は、これらの命令を実行する１つ以上のプロセッサ（例えばマイクロプロセッサ）２１４を含む。

図２に示すように、デバイス２０４は、無線データを受信するためのＷｉＤｉモジュール２２０を含む。さらに、図２に示すように、このディスプレイデータをデコードロジック２２２、及びデコードされたディスプレイデータを視覚的に出力するための物理的ディスプレイディバイス２２４を含む。デバイス２０４の要素は、ハードウエア及び／又はソフトウエアのいかなる組み合わせによってインプリメントされてもよい。例えば、デバイス２０４は、記憶媒体（例えばメモリ）及び１つ以上のプロセッサを含むことができる。これらは、ＷｉＤｉモジュール２２０及びデコードロジック２２２の機能を提供する命令を記憶し実行することができる。

ＷｉＤｉモジュール２１０及び２２０は、様々な無線ネットワーク標準に従って動作することができる。例えば、これらのモジュールは、米国電気電子学会（ＩＥＥＥ）８０２．１１標準（ＷｉＦｉ標準）の１つ以上に従って、動作することができる。なお、実施例は、これらの標準に限定されるものではない。更に、実施例は、無線ディスプレイの利用に限定されるものではない。

従来のＩＥＥＥ８０２．１１のレート適応メカニズムについて以下に詳述する。このメカニズムに従って、無線通信デバイスは、データ転送速度を選択するドライバを用いることができる。この動的な選択は、近いデータ転送速度のうちで、長期間の推定されたスループットの最適なものを提供することを目的としている。このデバイスは、最初のデータ転送速度として、選択されたデータ転送速度を用いる。この最初のデータ転送速度の決定プロセスは、信号及びノイズの遅い変化をトラッキングする。この例としては、アクセスポイントから離れたところで歩いていることによる変化が挙げられる。

この選択に基づいて、デバイスは転送速度テーブル（rate table）を作成する。例えば、典型的な転送速度テーブルとしては、段階的に減少するようにアレンジされた１６個の転送速度を含むテーブルが挙げられる。この転送速度テーブルによって、デバイスは、（例えば、マイクロコードの実行によって）短期間の転送速度の調整を実行できる。

このような短期間の転送速度の調整は、（例えば、弱い信号又は妨害ノイズに基づく衝突による）パケットの損失が発生した場合になされる。例えば、パケット損失が発生した場合（例えば、受信側デバイスから対応するＡＣＫを受信しない場合）、デバイスは、テーブルにおける、より遅い転送速度によって自動的にパケットを再送する。更にパケット損失がある場合には、転送速度テーブルにおける、次の、より遅い転送速度によって、後の送信を行う。パケット送信が成功した場合、次の送信は、最初のデータ転送速度を採用するようにする。

したがって、データ転送速度を低下させることによって、この技術は、ＡＷＧＮ（付加ホワイトガウスノイズ）チャネルにおけるパケットの成功確率を向上させる。しかしながら、この短期間の調整技術は、パケットの期間より長いものとしてしまう。上述のように、このような期間の増加は、バースト的なノイズの環境において成功裏にパケットを送信するできる確率を低下させることとなる。

このようなアプローチに加えて、実施例は、無線チャネル（無線メディア）の試験（probe）を行う技術を採用する。このような技術は、好適にバースト的なノイズの環境を管理し、しかも従来の通信速度調整技術のようにパケットの期間を過度に増加させることがない。

このような技術では、送信デバイスは、無線試験パケットを宛先デバイスに送信する。この試験パケットが受信デバイスに正しく受信された場合、送信デバイスは、１つ以上のデータパケットを受信デバイスに送信する。この送信デバイスは、このデータパケットが所定の数になるまで、１つ１つ、これらのデータパケットを送信することができる。このロスが発生した場合、送信デバイスは、他の試験パケットを受信デバイスに送る。事実、送信デバイスは、正しく受信するまで、この試験パケットを何回も送ることができる。

したがって、実施例は、バーストノイズを検出するために試験パケットを採用する。例えば、この試験パケットは、現在、「バースト妨害の期間」（「on period」とも称す）が存在するか、又は、「バースト妨害期間外」（「off period」とも称す）を検出することができる。）この検出に基づいて、送信デバイスは、「オフ期間」の間にデータを送信し、「オン期間」の間は、バックオフ（back off:送信を延期）する。オフ期間において、データ転送速度は、従来のＩＥＥＥ８０２．１１技術に従って決定された最初のデータ転送速度である（この点については、既に述べた）。試験パケットの送信が成功することは、データパケットの送信が成功する可能性が高いことを示すが、それよりも高くない場合は、そうでないような試験パケットのデータ転送速度を選択することが望ましい。例えば、試験パケットは、最初のデータ転送速度よりも少しだけ高いデータ転送速度であることが望ましく、これによって、短いパケット長となる。したがって、試験パケットのデータ転送速度は、レート適応技術に従って、（例えば、このような適応技術の最初のデータ転送速度に基づいて）選択され得る。

実施例において、送信デバイスは、受信デバイスが１つ以上の試験パケットの受信に失敗した場合、「オン期間」であることを検出する。これに対して、送信デバイスが、受信デバイスが試験パケットの受信に成功した場合、「オフ期間」を検出する。実施例において、受信デバイスは、肯定応答（ＡＣＫ）を送信デバイスに送信することを介して、受信が成功したことを示す。

追加的な通信オーバーヘッド（すなわち、データパケットに加えて、試験パケットを採用することによるオーバーヘッド）が発生することとなるが、この技術は、衝突の発生を好適に減少させる。更に、この技術によって、減少方向のデータ転送速度の調整は、好適に回避することができる。この結果、追加的なオーバーヘッドが発生するにもかかわらず、より良いパフォーマンスが達成される。

このような技術によって、パケット（例えば、試験パケット又はデータパケット）の受信が成功したことは、送信デバイスが受信デバイスから対応する肯定応答（ＡＣＫ）を受信することによって示される。逆に、受信デバイスからの対応する肯定応答の受信を送信デバイスが失敗することによって、パケットロスが示される。

図３は、例示的なフローチャート３００を示している。これは、本明細書の１つ以上の実施例によって実行される動作の例を示す。まず、このフローは図２の構成に基づいている。しかしながら、実施例は、これに限定されるものではない。また、図３は、特定のシーケンスを示すが、他のシーケンスが採用されても良いことは言うまでもない。更に、記載された動作は、パラレル及び／又はシーケンシャルの様々な組み合わせで実行され得る。

図３のフローチャートは、ソースデバイス及び宛先デバイスに関連して描かれている。図２において、ソースデバイスは、デバイス２０２であり、宛先デバイスは、デバイス２０４である。しかしながら、実施例はこの例に限定されるものではない。

ブロック３０２で、ソースデバイスは、無線通信メディア（例えば、１つ以上のＩＥＥＥ８０２．１１チャネル）を試験する。そして、チャネルのノイズ状態を判断する。上述したように、これは、ソースデバイスが、１つ以上の試験パケットを送信することに関連する。試験パケットの例としては、送信要求（ＲＴＳ：ready-to-send）パケット及び専用の（dedicated）試験パケットが挙げられる（なお、これらに限定されるものではない）。そして、ソースデバイスは、これらの試験パケットに対する宛先デバイスからの応答を待つ。この応答は、送信可（ＣＴＳ：clear-to-send）パケット、専用応答パケット、及び／又はその他の適切な送信であってもよい。

ブロック３０４で、ソースデバイスは、無線通信メディアが（clear：バーストノイズ、又はバースト的な状態でない）空き、であるか否かを判断する。その場合には、処理は３０６に進む。

ブロック３０６で、ソースデバイスは、１つ以上のデータパケットを宛先デバイスに送信する。実施例において、このデータ転送は、レート適応技術（例えば、上述の従来のＩＥＥＥ８０２．１１のレート適応メカニズム）を採用しない。データパケットが成功裏に宛先デバイスによって受信された場合、宛先デバイスは、肯定応答（ＡＣＫ）パケットをソースデバイスに送信する。このようにして、ソースデバイスは、送信されたデータパケットの受信の各々の肯定応答を待つ。

ブロック３０８に示すように、ソースデバイスは、試験状態が存在するかを判断する。試験状態の例としては、宛先デバイスからのデータパケットの肯定応答の受信の失敗が挙げられる。例えば、肯定応答の無いデータパケットの数が所定の閾値に達した場合には、ソースデバイスは、試験状態が存在すると判断する。

図３に示すように、試験状態が存在する場合、処理は、３０２に戻る。そして、無線メディアに対して、更に試験が行われる。したがって、ソースデバイスは、データパケットの送信を中断し、後のデータパケット送信の再開のために、通信メディアの試験を再度行う。

上述のように、コントロールパケットが、メディアを試験するために採用される。

様々なタイプの試験パケットが採用され得る。例えば、実施例において、ＲＴＳパケットを試験パケットとして採用することができる。この場合、対応する肯定応答パケットは、ＣＴＳパケットであってもよい。あるいは、又は追加的に、実施例において、Ｎｕｌｌデータパケットを試験パケットとして採用してもよい。あるいは／これに加えて、ＡＣＫパケットを対応する肯定応答パケットとして採用してもよい。更に、専用の試験コントロールパケットを採用してもよい。この点については、図４及び図５を用いて説明する。なお、実施例は、これらの例示に限定されるものではない。

図４及び図５は、例示的コントロールパケットのダイヤグラムを示している。図４は、例示的な専用試験パケット４００を示す。図５は、例示的な専用試験応答パケット５００を示す。

図４に示されるように、試験パケット４００は、フレームコントロールフィールド４０２と、受信ＳＴＡアドレスフィールド４０４と、送信されたＳＴＡアドレスフィールド４０６と、ＣＲＣフィールド４０８とを含む。更に、図４は、各フィールドに対して例示的にバイトでサイズを示している。フレームコントロールフィールド４０２は、パケット４００が試験パケットであることを識別するためのものである。受信ＳＴＡアドレスフィールド４０４は、宛先の受信デバイスを示す。送信されたＳＴＡアドレスフィールド４０６は、送信デバイスを示す。ＣＲＣフィールド４０８は、パケット４００におけるエラーの検出を可能とさせる。

図５において、試験応答パケット５００は、フレーム制御フィールド５０２と、受信されたＳＴＡアドレスフィールド５０４と、ＣＲＣフィールド５０２とを含む。フレーム制御フィールド５０２は、パケット５００が、試験応答パケットであることを識別させるためのものである。受信されたＳＴＡアドレスフィールド５０４は、宛先の受信デバイスを示す。ＣＲＣフィールド５０６は、パケット５００におけるエラーの検出を可能とさせる。

したがって、実施例においては、従来の受信要求／送信可（ＲＴＳ／ＣＴＳ）プロテクション方式に対して好適な、試験パケット技術を採用することができる。この従来のＲＴＳ／ＣＴＳプロテクション方式は、送信デバイス（例えば、ＷｉＤｉに対しては、パーソナルコンピュータの内部のＷｉＦｉモジュール）がＲＴＳパケットを送信することを採用している。ＲＴＳパケットの受信に応答して、受信デバイス（例えば、ワイヤレスディスプレイのＷｉＤｉアダプタ）がＣＴＳパケットを送信する。

このＲＴＳ／ＣＴＳプロテクションスキームにおいて、ＲＴＳ及びＣＴＳフレームの交換が成功裏に行われた場合、送信デバイスは、所定の時間期間（ＳＩＦＳ間隔：short Interframe spacing interval）だけ待った後、データパケットを送信することができる。しかしながら、所定の時間間隔内で、送信デバイスがＣＴＳパケットを受信しない場合、その送信デバイスは、バックオフタイムウィンドウの後に、ＲＴＳパケットを再送信する。

この従来のＲＴＳ／ＣＴＳプロテクション方式の例を、図６Ａ及び図６Ｂに示す。特に、図６Ａは、ＲＴＳ／ＣＴＳ交換６００の例（ブロックＡとしても表記されている）を示している。この交換において、ソースデバイス６１０は、ＲＴＳパケット６０２を、宛先デバイス６２０に分散されたフレーム間スペース期間（ＤＩＦＳ：Distributed Interframe Space）の後に送信する。

これに対して、宛先デバイス６２０は、ＳＩＦＳ（short Interframe space）期間の後、ＣＴＳパケット６０４をソースデバイス６１０に送信することにより応答する。

ＣＴＳパケット６０４を受信すると、ソースデバイス６１０は、ＳＩＦＳ期間だけ待ち、データパケット６０６を宛先デバイス６２０に送信する。このデータパケットを受信すると、宛先デバイス６２０は、肯定応答（ＡＣＫ）パケット６０８を送信する。ＡＣＫ６０８の受信の後、ソースデバイス６１０は、ＤＩＦＳ期間、及びバックオフ（BO）時間間隔だけ待つ。

図６Ｂは、「ブロックＡ」交換６００の例を示している。特に、図６Ｂは、連続的に実行される二つの交換（６００ａ及び６００ｂ）を示している。更に、図６Ｂは、これらの交換が、バースト的ノイズがオフの期間６５０の間に実行されることを示している。この期間は、バースト的なノイズ６５２ａ及び６５２ｂの間に位置している。

図６Ａ及び図６Ｂの従来のＲＴＳ／ＣＴＳプロテクション方式は、特定の状況の時には、利用価値がある。例えば、この従来の方式は、混雑している領域（例えば、ＷＬＡＮネットワークがオーバーラップしている領域）において利用価値がある。この従来の方式によって、同一の物理的チャネルに存在する各ステーションは、ネットワークアロケーションベクトル（ＮＡＶ）を受信する。そして、（異なるネットワークに対する構成された状態であったとしても）それらのメディアアクセスを適切に遅らせる。更に、この従来方式は、よく知られた非常時ノード（hidden node）及び表示ノード（exposed node）の問題を解決するのに利用できる。

しかしながら、バースト的ノイズの存在する環境を取り扱うために、従来のＲＴＳ／ＣＴＳプロテクション方式を用いることに対する欠点も存在する。例えば、データパケットの各々をＲＴＳ及びＣＴＳパケットでラッピングすることによって、この方式は、過度の通信バンド幅を消費してしまうことになる。この結果、全体的なスループットが、許容できないレベルにまで落ちてしまう。

ここに説明するように、実施例では、試験パケットがバースト的ノイズの「オン期間」又は「オフ期間」が存在するか否かを検出するために用いられる。試験パケットは、様々な態様でインプリメントされ得る。例えば、ＲＴＳ／ＣＴＳパケット、及び専用の試験パケットが採用され得る。しかしながら、送信及び受信デバイスが、同じ試験パケットの定義を採用し、かつ、それらのパケットがメディア（チャネル）の状態を通信できる限り、いかなるパケットの形式が利用されてもよい。

試験メカニズムの例が、図７Ａ及び図９に示されている。

図７Ａ及び図７Ｂは、試験パケットの交換の例を示している。この交換は、「ブロックＢ」としても記載されている。特に、図７Ａにおいて、試験パケットは、ＲＴＳ／ＣＴＳパケットでインプリメントされている。これに対して、図７Ｂは、専用の試験パケットの採用が示されている。

例えば、図７Ａにおいて、ソースデバイス７１０は（ＤＩＦＳインターバルの後）ＲＴＳパケット７０２を、試験パケットとして、宛先デバイス７２０に送信する。このＲＴＳパケットを受信すると、宛先デバイス７２０は、（ＳＩＦＳインターバルの後）ＣＴＳパケット７０４をソースデバイス７１０に送信する。図７Ａに示すように、ＳＩＦＳインターバルは、ＣＴＳパケット７０４の後に続く。図７Ｂは、図７Ａと同じ交換を採用している。しかしながら、図７Ｂにおいては、専用の試験パケット７０６及び専用の試験応答パケット７０８が採用されている。これらのパケットは、図４及び図５に従ってフォーマットされ得る。なお、実施例は、これに限定されるものではない。

図８は、ソースデバイスと、本明細書で説明した試験の技術を用いた、宛先デバイスとの間での例示的な交換を示している。特に、図８において、ノイズオフ期間で、「ブロックＢ」の交換が実行されている（ブロックＢ（＃１）として示す）。図７Ａ及び図７Ｂに関連して既に述べたように、ブロックＢの交換においては、ソースデバイスが試験パケットを送り、そして、宛先デバイスが対応する試験レスポンスを応答する。

ブロックＢの交換に続いて、図８においては、第１のデータパケット（データ（＃１）として示す）がソースデバイスから宛先デバイスに送信される。このデータパケットにＳＩＦＳインターバルと、宛先デバイスからソースデバイスへのＡＣＫ送信と、ＤＩＦＳインターバルと、バックオフ（ＢＯ）インターバルとが続く。図８において、第２のパケット（データ（＃２）として示す）についても実行される。同様に第３のデータパケット（データ（＃３）として示す）についても同様である。

図８では、このようなデータ送信は、ノイズオフ期間８２０の間に行われる。これは、ノイズオン期間８２２ａ及び８２２ｂの間に存在する。更に、ノイズオン期間８２２ｂが開始されると、ソースデバイスは、宛先デバイスからデータパケットの肯定応答を受信しなくなる。このため、ソースデバイスは、試験を再開する。例えば、図８において、ブロックＢの交換（「ブロックＢ（＃２）」として示す）は、その後のノイズオフ期間８２４で行われている。ここで示されているように、この交換の成功は、バーストノイズオフ期間として示されている。そして、ここに記載されている技術に基づくデータ送信が実行される。

図９は、ソースデバイス９０２と、宛先デバイス９０４との間の更なる交換のフローが記載されている。この交換は、本明細書に開示されている試験（probing）の技術が採用されている。図９に示すように、ノイズオン期間９０６において、ソースデバイス９０２は、データパケット９１０を宛先デバイス９０４に送信する。しかしながら、ノイズのために、ソースデバイス９０２は、対応する肯定応答を宛先デバイス９０４から受信しない。

このため、ソースデバイス９０２は、メディアの試験を開始する。より具体的には、ソースデバイス９０２は、ＲＴＳパケット９１２、９１４、９１６、及び９１８を宛先デバイスに送信する。図９に示すように、ＲＴＳパケット９１８は、ノイズオフ期間９０７において送信される。したがって、ソースデバイス９０２は、対応する試験応答をＣＴＳパケット９２０の形で受信する。

ＣＴＳパケット９２０を受信することに基づいて、ソースデバイス９０２は、データパケットのシーケンスを宛先デバイス９０４に送信する。より具体的には、図９において、ソースデバイス９０２は、データパケット９２２、９２６、９３０、及び９４０を送信する。これらの各々のデータパケットに対して、ソースデバイスは、肯定応答（ＡＣＫ）を宛先デバイス９０４から受信する。これらのＡＣＫは、図９において、ＡＣＫ９２４、９２８、９３２、及び９３６として示されている。

図９において、データパケット９４０に対して、ソースデバイス９０２は、対応する肯定応答を宛先デバイス９０４から受信しない。したがって、ソースデバイス９０２は、メディアに対して試験を再度開始する。例えば、図９のソースデバイス９０２は、（試験パケットとして）ＲＴＳパケット９４２、９４４、及び９４６を宛先デバイス９０４に送信する。

期間９０８におけるノイズの後、ソースデバイス９０２は、試験応答（ＣＴＳパケット９４８）を宛先デバイス９０４から受信する。このようにして、ソースデバイス９０２は、データパケット９５０を宛先デバイス９０４に送信することによって、データ送信を再開する。これに応答して、ソースデバイス９０２は、対応するＡＣＫ９５２を宛先デバイス９０４から受信する。

したがって、図９に示すように、無線通信デバイスは、試験パケットを用いることによって、無線チャネル（無線メディア）を試験することができる。この試験から、デバイスは、無線メディアが現在バースト的な妨害を受けているか否かを検出することができる。換言すれば、デバイスは、バースト的妨害の「オン期間」又は「オフ期間」か否かを検出することができる。

無線デバイスが「オフ期間」を検出した場合、そのデバイスは、データパケットの送信を開始又は再開することができる。デバイスは、データパケットを１つずつ送信する。これは、特定の回数を超える再送信がなされるまで続く。この状況の場合には、バースト的妨害の「オン期間」が存在していることを示す。

実施例において、試験パケット（例えば、ＲＴＳパケット）は、特定の時間間隔において通信デバイスを占有（reserve）する。しかしながら、実施例では、予測される試験応答パケット（例えばＣＴＳパケット）を受信する期間よりも、メディアをより長い時間占有することは避けることができる。この理由は、目的の受信デバイスは混雑している（Jammed）が、他のデバイスは、この弊害を受けず、かつメディアを使用することもできるからである。

例えば、通信メディアを占有することを維持することによって、他のデバイスは、メディアをリリースするための（contention-free-end）が送信されるまで、そのメディアを利用することができない。したがって、実施例において、試験パケット（例えば、ＲＴＳパケット）は、正確にＣＴＳとソースデバイスのデータパケットのプリアンブルの間、メディアを占有する。

図１０は、例示的なフローチャート１０００を示している。これは、１つ以上の実施例によって実行される動作の例を示している。図２の環境において、この動作が行われてもよい。なお、実施例は、これに限定されるものではない。図１０は、特定のシーケンスを示しているが、他のシーケンスが採用されてもよい。加えて、示されている動作は、同時的、及び／又は時系列的に様々に実行されてもよい。

図１０のフローチャートは、ソースデバイス及び宛先デバイスに関して記載されている。図２に示されたように、ソースデバイスはデバイス２０２であり、宛先デバイスはデバイス２０４である。なお、実施例はこれらに限定されるものではない。

ブロック１００２で、ソースデバイスは、試験パケットを宛先デバイスに送信する。これに対して、ソースデバイスは、試験パケットの肯定応答が、宛先デバイスから受信されたか否かを判断する（ブロック１００４）。もし、そうであれば、動作はブロック１０１２に進む。それ以外の場合には、動作はブロック１００６に進む。

ブロック１００６で、試験パケットの再送信の回数が、試験再送信閾値Ｎよりも、小さいか否かを判断する。そうであれば、動作はブロック１００８に移る。それ以外の場合には、ブロック１０１０に進む。例示的に、図１０において、閾値Ｎは１５である。なお、他のＮの値が採用されてもよい。

ブロック１００８で、ソースデバイスは、試験パケットを再送信する。図１０では、この再送信の後、動作はブロック１０４に戻る。したがって、この状態で、ソースデバイスは、試験パケットの肯定応答が受信されたか否かを判断する。

上述のように、ブロック１０１０は、試験パケットの再送信が閾値Ｎに達した場合に実行される。図１０のブロック１０１０において、ソースデバイスは、従来のデータ送信プロトコルを採用する。より具体的には、ソースデバイスは、データを送信し、従来のＩＥＥＥ８０２．１１技術に従って（肯定応答が受信されたかに基づいて）短期間レート調整（short term rate adjustment）を採用する。図１０に示すように、動作は、（例えば、パケット送信の成功又は所定の時間後に）ブロック１０１０からブロック１００２に戻る
上述のように、ブロック１０１２は、ソースデバイスが、試験パケットの肯定応答が受信されたと判断した場合（ブロック１００４）に、実行される。このブロックにおいて、ソースデバイスは、無線で、宛先デバイスにデータパケットを送信する。

この後、ブロック１０１４で、ソースデバイスは、宛先デバイスからデータパケットの肯定応答が受信されたか否かを判断する。その場合には、動作は、ブロック１０１２に戻る。ここで、ソースデバイスは更なるデータパケットを宛先デバイスに送信してもよい。

しかしながら、ソースデバイスが、データパケットの肯定応答を受信しない場合、動作はブロック１０１４から１０１６に進む。ブロック１０１６で、ソースデバイスは、データパケットの再送信が、データ送信閾値Ｋよりも小さい回数、繰り返されているか否かを判断する。この場合には、ブロック１０１８に進む。

これ以外の場合には、動作はブロック１００２に戻る。例示的目的のため、図１０において、閾値Ｋの値は３である。なお、Ｋの値としてその他の値が採用されてもよい。

図１０に示すように、ソースデバイスは、ブロック１０１８で、データパケットを再送信する。

この後、動作はブロック１０１４に進む。

図１０においては、実施例は、既存のレート適応アルゴリズムを補足する技術を提供する。このような既存のアルゴリズムは、信号強度及びノイズの遅い変化に適合する場合に適切であるが、実施例におけるこの新たな技術は、バースト的なノイズを回避する
したがって、図１０のフローは、基本的に２つのフローを含んでいると解釈できる。第１のループは、ブロック１００２、１００４、１００６、１０１０、及び１００２に戻るものである。このループは、従来のレート適応方式に該当する。したがって、（ブロック１００６の）閾値Ｎが０になる場合、従来のレート適応技術が行う非常にルーズなパフォーマンスとなる。しかも、このフローにおいて、この従来の技術は、パケットの成功の統計に基づいて、一時的に最良の初期データ通信速度で採用される。

第２のループは、ブロック１０１２、１０１４、１０１６、及び１０１８のブロックに沿って進む。この、レート適応によらない技術は、ブロック１０１０で、レート適応技術に従って選択された初期設定の（に基づく）データ転送速度を採用するものである。上述のように、ブロック１０１０は、バースト的ノイズオフ状態の間に実行される。ブロック１０１０は、試験の転送速度での送信の成功がデータパケットの成功する転送確率が高いことを示し、かつこれよりも過剰な速度でないように、この最初のデータ転送速度を決定する。

図１１のグラフ１１００は、バーストノイズのデューティサイクルの範囲に亘って、３つの異なる送信技術のパフォーマンス特徴をシミュレートしたものである。より具体的には、グラフ１１００において、カーブ１１０２は、既存のＷｉＦｉレート適応技術を採用した（試験の技術又はＲＴＳ／ＣＴＳプロテクションを採用しない）通信に対するスループットの特徴を示している。カーブ１１０４は、従来のＲＴＳ／ＣＴＳプロテクション方式を採用した通信のスループットの特徴を示している。そして、カーブ１１０６は、図１０と共に本明細書において説明した試験ベースの技術を採用した通信のスループットの特徴を示している。

このカーブのプロットにおいて、ノイズは、１６．６ミリ秒の間継続するとしてシミュレートしている。図１１に示すように、バースト的ノイズのデューティサイクルは、ノイズのオン及びオフの期間を決定するため、大きな影響を与える。

カーブ１１０６のデータに対して、試験パケット及び試験応答パケットは、ＲＴＳ及びＣＴＳと同じ構造を採用している。これらのパケットは、物理的通信速度として、２４Ｍｂｐｓ（メガビット／秒）で送信される。採用されたコンテンションウィンドウは、最小で７、最高で３１である（これらは、ＷｉＤｉアプリケーションにおいて採用されている）。チャネル状態は、バースト的ノイズがオフのとき極めて良好であり、バースト的ノイズがオンのとき、極めて悪いと仮定している。

カーブ１１０２の既存のＷｉＦｉレート適応メカニズムにおいて、データ転送速度は、一度再送信が発生すると、自動的に低下する。このため、ＷｉＦｉパケットはより長い送信期間を必要とする。図１１に示すように、このメカニズムは、バースト的ノイズが長期間オンの場合、パフォーマンスが悪化する。

カーブ１１０４の従来のＲＴＳ／ＣＴＳプロテクションメカニズムは、共有無線チャネル／メディアの利用において、よりよいコントロールを提供する。そして、ＲＦ妨害からのコリジョンを減少させるが、オーバーヘッドを伴う。なぜなら、ＲＴＳ／ＳＣＴ交換は、各パケットで行われるからであり、バーストノイズがオフの期間においても行われるからである。このような、過剰なオーバーヘッドは、本明細書における試験技術とは対称的である。この場合、試験パケットの交換は、バーストノイズのオフの期間で、１回のみ発生する。

図１１に示すように、本明細書におけるこの試験技術（カーブ１１０６）は、他の技術によるスループットよりも、大きなスループットを提供することができる。例えば、カーブ１１０６は、定常的に、カーブ１１０４よりも３５％ないし４０％高い値を示す。しかも、バースト的ノイズのデューティサイクルが４０％を超える場合、カーブ１１０６は、カーブ１１０２（既存のＷｉＦｉレート適応技術）に比較して非常に高いスループットを示す。

図１２は、インプリメンテーション１２００のブロック図を示している。これは、基地局（例えば、ＢＳ １２０ａ−ｇ）及び又はモバイルステーション（例えば、ＭＳ １０４ａ−ｈ）等のワイヤレスデバイスに含まれ得る。インプリメンテーション１２００は、様々な要素を含む。例えば、図１２で、インプリメンテーション１２００は、複数のアンテナ１２０２ａ−ｃ、トランシーバモジュール１２０４、ホストモジュール１２０６、及びコントロールモジュール１２０８を含む。これらの要素は、ハードウエア、ソフトウエア、又は、これらのいかなる組合せによってもインプリメントすることができる。

アンテナ１２０２ａ−ｃは、リモートデバイスと無線信号を交換するために提供される。

３つのアンテナが示されているが、いかなる数（１つ以上）のアンテナが用いられてもよい。更に、実施例において、１つ以上の送信アンテナ、及び１つ以上の受信アンテナが用いられてもよい。このような、複数のアンテナの構成は、ビームを形成するように、及び／又は、複数の空間的ストリームをリモートデバイスに形成するよう採用されてもよい。

トランシーバモジュール１２０４は、他のデバイスとの情報の交換をするために提供される。したがって、トランシーバモジュール１２０４は、本明細書に記載されているように、（アンテナ１２０２ａ−ｃを介して）様々な伝送を送信しかつ受信する。この伝送は、試験パケット及びデータパケットを含むが、これらに限定されるものではない。

図１２に示されるように、トランシーバモジュール１２０４は、送信部１２１０及び受信部１２１２とを有する。動作において、トランシーバモジュール１２０４は、アンテナ１２０２ａ−ｃと、他の要素との間の、インタフェースを提供する。例えば、ホストモジュール１２０６、及びコントロールモジュール１２０８である。例えば、送信部１２１０は、これらの要素からシンボルを受信する。そして、対応する信号を生成し、生成された信号はアンテナ１２０２ａ−ｃの１つ以上によって無線伝送される。これは、変調、増幅、及び／又はフィルタリングの動作を含むことができる。なお、他の動作が採用されてもよい。

これに対して、受信部１２１２は、１つ以上のアンテナ１２０２ａ−ｃによって受信された信号を取得し、対応するシンボルを生成する。これに応じて、これらのシンボルは、ホストモジュール１２０６、及びコントロールモジュール１２０８等の要素に提供される。このシンボルの生成は、復調、増幅、及び／又はフィルタリング等の動作を含むが、これらに限定されるものではない。

トランシーバモジュール１２０４によって生成され受信された信号は、様々な形態を取ることができる。例えば、これらの信号は、直交周波数分割多重（ＯＦＤＭ）方式に従って変調されてもよい。なお、例えばＱＰＳＫ、ＢＰＳＫ、ＦＳＫ、等の他の方式及びフォームが採用され得る。

この特徴を提供するために、送信部１２１０及び受信部１２１２は、各々様々なコンポーネントを含むことができる。例えば、変調器、復調器、増幅器、フィルタ、バッファ、アップコンバータ、及び／又はダウンコンバータ等が挙げられる。このようなコンポーネントは、ハードウエア（例えば、エレクトロニクス）、ソフトウエア、及びいかなるこれらの組合せをも含み得る。

トランシーバモジュール１２０４及び他の要素の間で交換されるこのシンボルは、メッセージ又は１つ以上のプロトコル及び／又は１つ以上のユーザアプリケーションに関連する情報を含み得る。したがって、これらの要素は、これらのプロトコル及び／又はユーザアプリケーションに対応する動作を実行することができる。プロトコルの例示としては、様々なメディアアクセスコントロール、及びディスカバリプロトコルが含まれるが、これらに限定されるものではない。例示的なユーザアプリケーションとしては、電話（テレフォニー）、メッセージング、電子メール、ウェブブラウジング、コンテンツ（例えばビデオ及びオーディオ）配信／受信等が挙げられる。

更に、信号を送信する際、トランシーバモジュール１２０４は、様々なアクセス技術を採用することができる。例えば、トランシーバモジュール１２０４は、デュプレクス技術、時分割デュプレクス（ＴＤＤ）、周波数分割デュプレクス（ＦＤＤ）等が挙げられる。なお、実施例は、これらの技術に限定されるものではない。

実施例において、コントロールモジュール１２０８は、本明細書において記載された様々な動作を実行することができる。例えば、図１２に示すように、コントロールモジュール１２０８は、状態判断モジュール１２１４、及び送信技術選択モジュール１２１６を含む。

状態判断モジュール１２１４は、無線通信メディアの現在の状態を判断する。例えば、トランシーバモジュール１２０４によって送信された試験パケット、及びトランシーバモジュール１２０４によって受信された試験応答パケット（もし存在すれば）に基づいて、状態判断モジュール１２１４は、通信メディアが空き（クリア）であるか否かを判断する。

この判断に基づいて、送信技術選択モジュール１２１６は、データパケットを送信するための技術を選択する。本明細書に記載したように、この選択は、レート適応技術でない技術、あるいは、レート適応技術である。

更に、状態判断モジュール１２１４は、データ送信の状態をモニタリングすることができる。例えば、状態判断モジュール１２１４は、肯定応答データパケットをカウントし、トランシーバモジュール１２０４が、更なるデータパケット送信が行われる前に、通信メディアの試験を行わなければならないかを判断する。

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

本明細書において記載されているように、様々な実施例は、ハードウエア、ソフトウエア、又はいかなるこれらの組合せを用いてもインプリメントすることができる。ハードウエア要素の例としては、プロセッサ、マイクロプロセッサ、回路、回路要素（例えば、トランジスタ、抵抗、コンデンサ、インダクタ等）、集積回路、特定アプリケーション用集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、ディジタルシグナルプロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレー（ＦＰＧＡ）、論理ゲート、抵抗、半導体デバイス、チップ、マイクロチップ、チップセット、等が含まれる。

ソフトウエアの要素としては、ソフトエアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、マシーンプログラム、オペレーティングシステムソフトウエア、ミドルウエア、ファームウエア、ソフトウエアモジュール、ルーチン、サブルー心、機能、方法、手順、ソフトウエアインタフェース、アプリケーションプログラムインタフェース（ＡＰＩ）、命令セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、シンボル、その他いかなるこれらの組合せも含む。

ある実施例は、例えば機械読み取り可能な記憶媒体又は部品を用いて、インプリメントすることができる。記憶媒体は、命令又は命令のセットを記憶することができ、この命令が機械によって実行された時に、機械が、実施例に従った方法及び／又は動作を実行することができる。このような機械は、例えば、適切なプロセッシングプラットフォーム、コンピューティングプラットフォーム、コンピューティングデバイス、プロセッシングデバイス、コンピューティングシステム、プロセッシングシステム、コンピュータ、プロセッサ等が挙げられる。そして、これらは、ハードウエア及び／又はソフトウエアのいかなる適切な組合せによってもインプリメントすることができる。

明細書に記載されているように、実施例は、記憶媒体、又は機械読み取り可能な製品を含むことができる。これらは、適切なタイプのメモリユニット、メモリデバイス、メモリ製品、メモリ媒体、記憶デバイス、記憶製品、記憶媒体及び／又は記憶ユニット、例えば、メモリ、取り出し可能、又は取り出し不可能な媒体、消去可能又は消去不可能な媒体、再書き込み可能媒体、デジタル又はアナログ媒体、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、光ディスク、磁気媒体、磁気光媒体、取り出し可能メモリカード又はディスク、様々なタイプのＤＶＤ、テープ、カセット等が挙げられる。命令は、いかなる適切なタイプのコードであってもよい。例えば、ソースコード、コンパイルされたコード、インタープリットされたコード、実行可能コード、静的コード、動的コード、暗号化コード等が挙げられる。これらは、いかなる適切なハイレベル、ローレベル、オブジェクトオリエンテッド、ビジュアル、コンパイルされた、及び／又は、インタープリトされたプログラミング言語であってもよい。

以上、様々な実施例を説明したが、これらは例示的なものであり、限定するためのものではない点に留意すべきである。

したがって、当業者は、本発明の精神及び発明の技術的範囲を逸脱しない範囲で、形式及び詳細について様々な変更が加えられてもよいことを認識すべきである。したがって、本発明の技術的範囲は、上述の例示的実施例によって限定されるものではなく、以下の請求項及びその均等物にのみによって、限定されるものである。

Claims (19)

1. 通信メディアのバーストノイズ妨害を検出するように、１つ以上の試験パケットを送信するステップと；
   前記１つ以上の試験パケットの応答結果に基づいて、レート適応送信技術、及びレート適応でない送信技術のいずれかを選択するステップであって、レート適応でない送信技術は、ａ）前記通信メディアでバーストノイズ妨害が現在検出されない場合、データ転送に対して固定データ転送速度を使用し、ｂ）前記通信メディアでバーストノイズ妨害が検出されると、データ転送を停止し、ｃ）前記１つ以上の試験パケットを介して、前記通信メディアに前記バーストノイズ妨害が存在しないことが検出されると、前記固定データ転送速度でのデータ転送を再開すること、を含む、ステップと；
   を有する方法。
2. 前記通信メディアにおけるバーストノイズ妨害によって、前記試験パケットの再送信の失敗が所定の数だけ発生した場合に、前記レート適応送信技術が選択される、請求項１記載の方法。
3. 前記１つ以上の試験パケットのデータ転送速度、及び前記レート適応でない送信技術のデータ転送速度は、レート適応送信技術に従って決定される、請求項１記載の方法。
4. １つ以上の試験パケットを再送信するステップと；
   前記試験パケットの再送信の数が閾値に達した場合に、前記レート適応送信技術を選択するステップと；
   を更に有する請求項１記載の方法。
5. 前記１つ以上の試験パケットの各々は、Ｎｕｌｌデータパケットである、請求項１記載の方法。
6. ソースデバイス、及び宛先デバイスは、ＩＥＥＥ８０２．１１無線ローカルエリアネットワーク（ＷＬＡＮ）に含まれる、請求項１記載の方法。
7. 無線通信メディアが現在無線妨害の無い空きであるか否かを判断するように、１つ以上の試験パケットを使用するステップと；
   前記判断が、前記無線通信メディアが現在空きであることを示す場合、１つ以上のデータパケットを、前記無線通信メディアを介して、ソースデバイスから宛先デバイスに送信する送信ステップであって、前記送信ステップは、レート適応でない送信技術に従い、前記レート適応でない送信技術は：
   前記無線通信メディアを介する前記１つ以上のデータパケットの転送のための固定データ転送速度を用い；
   前記宛先デバイスが予め定められた回数の前記１つ以上のデータパケットの受信に失敗したことを検出すると、前記無線通信メディアに無線妨害があることを推測し；
   前記無線通信メディアが無線妨害の無い空きであることを検出するように、前記１つ以上の試験パケットを送信し；
   前記無線通信メディアにおいて前記無線妨害がもはや存在しなくなった場合、前記固定データ転送速度でデータ転送を再開する；
   ことを含む、送信ステップと；
   を有する方法。
8. 前記１つ以上の試験パケットが前記宛先デバイスに転送され、かつ前記無線通信メディアが現在空きであるか否か判断することは：
   前記１つ以上の試験パケットの各々に対して、前記宛先デバイスからの対応する試験応答パケットを待つこと、を含む請求項７記載の方法。
9. 前記無線通信メディアが現在空きであるか否かを判断することは、受信していない試験応答パケットの数が閾値に達した場合、前記無線通信メディアが空きでないと結論すること、を含む請求項８記載の方法。
10. 前記１つ以上の試験パケットの各々は、送信要求（ＲＴＳ）パケットであり、かつ、対応する試験応答パケットの各々は、送信可（ＣＴＳ）パケットである、請求項８記載の方法。
11. 前記宛先デバイスから、前記１つ以上のデータパケットの各々に対する肯定応答を待つステップと、受信していない肯定応答の数が、閾値に達した場合、前記無線通信メディアが無線妨害の無い空きであるか否かを再度判断するように、前記１つ以上の試験パケットを用いるステップと、を更に有する、請求項７記載の方法。
12. 無線通信メディアが、バーストノイズ妨害が無く現在空きであるか否か判断を行うように、１つ以上の試験パケットを使用するよう構成された状態判断モジュールと；
    前記状態判断モジュールが、前記無線通信メディアが現在空きであると判断した場合、レート適応でない技術に従って、宛先デバイスに１つ以上のデータパケットを送信するよう構成されたトランシーバモジュールであって、前記レート適応でない技術は、
    前記無線通信メディアを介する前記１つ以上のデータパケットの転送のための固定データ転送速度を用い；
    前記宛先デバイスが予め定められた回数の前記１つ以上のデータパケットの受信に失敗したことを検出すると、前記無線通信メディアに無線妨害があることを推測し；
    前記無線通信メディアが無線妨害の無い空きであることを検出するように、前記１つ以上の試験パケットを送信し；
    前記無線通信メディアにおいて前記無線妨害がもはや存在しなくなった場合、前記固定データ転送速度でデータ転送を再開する；
    トランシーバモジュールと；
    を有する装置。
13. 前記トランシーバモジュールは、宛先デバイスにおいて前記１つ以上のデータパケットの少なくとも１つを受信することができなかったことを検出すると、１つ以上の試験パケットを送信するよう構成された、
    請求項１２記載の装置。
14. 前記１つ以上の試験パケットの各々は、送信要求（ＲＴＳ）パケットである、請求項１３記載の装置。
15. 通信メディアのバーストノイズ妨害を検出するように、１つ以上の試験パケットを送信するステップと；
    前記１つ以上の試験パケットの応答結果に基づいて、レート適応送信技術、及びレート適応でない送信技術のいずれかを選択するステップであって、レート適応でない送信技術は、ａ）前記通信メディアでバーストノイズ妨害が検出されない場合、データ転送に対して固定データ転送速度を使用し、ｂ）前記通信メディアでバーストノイズ妨害が検出されると、データ転送を停止し、ｃ）前記通信メディアに前記バーストノイズ妨害が存在しないことが検出されると、前記固定データ転送速度でのデータ転送を再開すること、を含む、ステップと；
    を含む命令を、コンピュータに実行させるプログラム。
16. 前記バーストノイズ妨害は、略２．４ＧＨｚないし略２．５ＧＨｚの範囲の周波数を含む、請求項１記載の方法。
17. 前記バーストノイズ妨害は、無線周波数ノイズバーストのオン／オフシーケンスを含む、請求項１記載の方法。
18. 前記バーストノイズ妨害は、略１０％ないし略６０％のデューティーサイクルを持つノイズパルスのパターンを含む、請求項１記載の方法。
19. 前記バーストノイズ妨害は、マイクロ波デバイス、ブルートゥースデバイス、又はＷｉＦｉデバイスのうちの少なくとも１つによって生成される、請求項１記載の方法。

Images