JP4364165B2 - 無線通信装置 - Google Patents

Description

本発明は、無線を介してデータの送受信を行う、例えば携帯電話や無線ＬＡＮ等の無線通信機器を含む無線通信システムにおいて、劣悪な無線伝播環境でもロバストな無線通信方式を実現する方法に関する。

ＩＥＥＥ８０２．１１標準規格に対して媒体アクセス制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ： ＭＡＣ）層のＱｏＳ （Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）に関する拡張した無線ＬＡＮ規格ＩＥＥＥ８０２．１１ｅでは、送信側通信装置（Ｉｎｉｔｉａｔｏｒ）がデータを送信することの出来る期間ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）期間を獲得する方法としてＥＤＣＡ（ｅｎｈａｎｃｅｄ ｄｉｓｔｒｉｂｕｔｅｄ ｃｈａｎｎｅｌ ａｃｃｅｓｓ）方式とＨＣＣＡ（ＨＣＦ ｃｏｎｔｒｏｌｌｅｄ ｃｈａｎｎｅｌ ａｃｃｅｓｓ）方式とがある（非特許文献１参照）。

更なる高速伝送を目指したＩＥＥＥ８０２．１１ｎでは、ＩＥＥＥ８０２．１１ｅにおける送受信動作の際に各フレーム間に存在したオーバーヘッドを削減すべく、Ａ−ＭＰＤＵ（Ａｇｇｒｅｇａｔｅｄ − ＭＡＣ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）、ＨＴＰ（ｈｉｇｈ−ｔｈｒｏｕｇｈｐｕｔ ＰＨＹ） Ｂｕｒｓｔといった複数の方法が提案されている。

Ａ−ＭＰＤＵでは、複数のＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）フレームそれぞれの先頭に各フレーム間を識別するフィールドをつけて一つのＰＨＹ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）フレームに結合したＡｇｇｒｅｇａｔｉｏｎフレームを送信する（非特許文献２参照）。

ＨＴＰ Ｂｕｒｓｔでは、ＰＨＹフレーム同士を、従来のバースト伝送で使用していたＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）期間よりも短縮したＲＩＦＳ（Ｒｅｄｕｃｅｄ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）時間開けて送信する。ＨＴＰ Ｂｕｒｓｔでは、複数の受信側通信装置（Ｒｅｓｐｏｎｄｅｒ）それぞれへ異なる伝送レートや送信電力で送信動作を行う際には、各ＰＨＹフレームの間にＲＩＦＳ間あける事によって、伝送レートや送信電力を変えて各ＰＨＹフレームを送信する事ができる（非特許文献２及び非特許文献３参照）。

また、ＩＥＥＥ８０２．１１ｎでは、ＴＸＯＰ時間を獲得したＩｎｉｔｉａｔｏｒがＴＸＯＰ時間の一部（ＴＸＯＰ分与時間）をＲｅｓｐｏｎｄｅｒに与えて、Ｉｎｉｔｉａｔｏｒが獲得したＴＸＯＰ時間中にピギーバック手法による双方向通信をする手法すなわちＲｅｖｅｒｓｅ Ｄｉｒｅｃｔｉｏｎ（ＲＤ）方式による伝送効率向上が提案されている。

ＩＥＥＥ８０２．１１ｎにおいて、ＲＤ方式（ＩｎｉｔｉａｔｏｒがＥＤＣＡ方式あるいはＨＣＣＡ方式で獲得したＴＸＯＰ時間中にピギーバック手法でＲｅｓｐｏｎｄｅｒとの双方向通信を行う方式）にＡ−ＭＰＤＵを用るとすると、ＩｎｉｔｉａｔｏｒがＩＡＣ（Ｉｎｉｔｉａｔｏｒ Ａｇｇｒｅｇａｔｉｏｎ Ｃｏｎｔｒｏｌ）フレームを送信し、その送信後からＳＩＦＳだけ経過した後に、ＲｅｓｐｏｎｄｅｒがＲＡＣ（Ｒｅｓｐｏｎｄｅｒ Ａｇｇｒｅｇａｔｉｏｎ Ｃｏｎｔｒｏｌ）フレームを返信するＩＡＣ−ＲＡＣフレーム交換が行われる。このようなＩＡＣ−ＲＡＣフレーム交換を行うことを前提としてＲＤ方式を採るならば、Ｉｎｉｔｉａｔｏｒは、獲得したＴＸＯＰ時間のなかでの通信にＲＤ方式を採用することを書き込んだＩＡＣフレームをＲｅｓｐｏｎｄｅｒ宛で送信する。ＩＡＣフレームを受信してこのＴＸＯＰ時間のなかでの通信にＲＤ方式を採用することを通知されたＲｅｓｐｏｎｄｅｒは、ＴＸＯＰ時間の一部を与えられた場合に自分が送信する事が出来るＤａｔａフレーム数と送信データレートを、ＲＡＣフレームに書き込んで宛先をＩｎｉｔｉａｔｏｒにして送信する。Ｉｎｉｔｉａｔｏｒは、ＲＡＣフレームに書かれたＤａｔａフレーム数と送信データレートから、Ｒｅｓｐｏｎｄｅｒに対して分け与えるＴＸＯＰ時間の一部としてＲＤＧ（Ｒｅｖｅｒｓｅ Ｄｉｒｅｃｔｉｏｎ Ｇｒａｎｔ） Ｄｕｒａｔｉｏｎを決める。Ｉｎｉｔｉａｔｏｒは、決定したＲＤＧ ＤｕｒａｔｉｏｎをＩＡＣフレームに書き込み、送信するＡｇｇｒｅｇａｔｉｏｎフレームの先頭にそれを付けて、ＲＡＣフレーム受信完了後のＳＩＦＳだけ経った時点で送信する。

このとき、Ｄａｔａフレームの送達確認方法（ＡｃｋＰｏｌｉｃｙ）がＢｌｏｃｋＡｃｋ方式であり、このＢｌｏｃｋＡｃｋ方式にはＩＥＥＥ８０２．１１ｅに規定されているＩｍｍｅｄｉａｔｅ ＢｌｏｃｋＡｃｋ方式（送達確認要求フレーム（ＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレーム）を受信するとＳＩＦＳ後に送達確認フレーム（ＢｌｏｃｋＡｃｋフレーム）を送信する方式）を使用している場合は、Ｉｎｉｔｉａｔｏｒから送信されるＡｇｇｒｅｇａｔｉｏｎフレームの最後にＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームも結合される（ただし、ＩＥＥＥ８０２．１１ｎで提案されているＩｍｐｌｉｃｉｔ Ｂｌｏｃｋ Ａｃｋ方式ではＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔを省略する）。

上記の場合、Ｒｅｓｐｏｎｄｅｒは、ＩｎｉｔｉａｔｏｒからのＡｇｇｒｅｇａｔｉｏｎフレーム受信後にＳＩＦＳだけ経過した時点で、Ｂｌｏｃｋ Ａｃｋフレームによる受信状況を送信しなければならない。ＲＤであれば、ＳＩＦＳ後にＢｌｏｃｋ Ａｃｋフレームを返信する際に、ピギーバック手法を用いて、ＲｅｓｐｏｎｄｅｒからのＤａｔａフレームをＢｌｏｃｋ ＡｃｋフレームにＡｇｇｒｅｇａｔｅしたＡｇｇｒｅｇａｔｉｏｎフレームを送信する。このＡｇｇｒｅｇａｔｉｏｎフレームの送信にかかる時間は、ＩＡＣフレームに書かれたＲＤＧ Ｄｕｒａｔｉｏｎを越えなてはならない。ＲｅｓｐｏｎｄｅｒがＡｇｇｒｅｇａｔｉｏｎフレームを送信する際にさらにＲＤＧ Ｄｕｒａｔｉｏｎを要求する場合は、送信準備の出来ている（すなわち今回送信する予定の）データフレーム数と送信データレートをＲＡＣフレームに入れて、今回送信するＡｇｇｒｅｇａｔｉｏｎフレームの先頭に付けて返信する（非特許文献２参照）。
ＩＥＥＥ ８０２．１１ｅ Ｄｒａｆｔ １３．０、ＩＥＥＥ Ｐ８０２．１１ｅ／Ｄ１３．０， Ｊａｎｕａｒｙ ２００５． ＴＧｎ Ｓｙｎｃ Ｐｒｏｐｏｓａｌ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＩＥＥＥ ８０２．１１−０４／８８９ｒ６， Ｍａｙ ２００５． ＷＷｉＳＥ Ｐｒｏｐｏｓａｌ： Ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ ｅｘｔｅｎｓｉｏｎ ｔｏ ｔｈｅ ８０２．１１ Ｓｔａｎｄａｒｄ， ＩＥＥＥ ８０２．１１−０５／０１４９ｒ２， Ｍａｒｃｈ ２００５．

しかしながら、上記ＲＤ方式では、Ｄａｔａフレーム群にＢｌｏｃｋＡｃｋフレーム及びＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームを、結合して１つのＰＨＹフレームとして送信するので、Ｄａｔａフレーム群とＢｌｏｃｋＡｃｋフレーム及びＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームとを同じ伝送レートで送信することになる。その為、無線伝播環境の悪化や衝突の発生などによる伝送エラーの確率がＤａｔａフレーム群とＢｌｏｃｋＡｃｋフレーム及びＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームとでほぼ同じになってしまう。

一般に、高い伝送レートを用いると伝送エラーの確率が高まるので、ＢｌｏｃｋＡｃｋフレーム及びＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームの送達の確率を上げるためにはＡｇｇｒｅｇａｔｉｏｎフレームの伝送レートを下げる必要がある。ただし、伝送レートを下げると、Ａｇｇｒｅｇａｔｉｏｎフレームが長くなってしまい、スループットが低下してしまう。

逆にＤａｔａフレームを速く送受信するために伝送レートを上げるとＢｌｏｃｋＡｃｋフレーム及びＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームの送達の確率が下がり、ＢｌｏｃｋＡｃｋフレームやＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームの受信に失敗したＩｎｉｔｉａｔｏｒあるいはＲｅｓｐｏｎｄｅｒはＡｇｇｒｅｇａｔｉｏｎフレームを再送することになる。これは、通信効率が極端な悪化、すなわちスループットの大幅な劣化要因となる。本発明は上記の問題を解決するためになされたものであり、ＢｌｏｃｋＡｃｋフレームやＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームなどの送達確認に使用するフレームの送信成功確率を向上させることを目的とする。

本発明の一観点に係る無線通信装置は、データ送信用の送信期間を獲得してデータ送信を行う際に、獲得した送信期間の一部を、該データ送信に係る受信側となる無線通信装置へデータ送信用として分け与えることのできる通信方式に従う無線通信装置において、受信したデータに対する送達確認フレームを含む第一の物理フレームおよび複数の送信データフレームがアグリゲートされた第二の物理フレームを生成する生成手段と、前記第一の物理フレームを第一の伝送レートで送信し、該第一の物理フレームの送信時点から一定期間が経過した後に第二の伝送レートで前記第二の物理フレームを送信する送信手段と、を具備する無線通信装置である。

本発明によれば、コントロールフレームの受信失敗によるＲｅｓｐｏｎｄｅｒの再送依頼を抑えることと、Ｄａｔａフレームの高速送信との両立が出来る。

（第１の実施の形態）
図１は、無線ＬＡＮ通信規格のＩＥＥＥ８０２．１１ｎにて提案されている内容をサポートする無線通信装置１０１の一例に係るブロック図である。すなわち、ＩＥＥＥ８０２．１１ｎにて提案されているＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）方式の高速な伝送レートや、２０ＭＨｚ帯から４０ＭＨｚ帯に周波数帯域を拡張した伝送方式をサポートしているものとして以下説明する。

なお、ここで記述するＩＥＥＥ８０２．１１ｎにて提案されている内容には、ＩＥＥＥ８０２．１１標準規格およびＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｅなど（ａｍｅｎｄｍｅｎｔやｒｅｃｏｍｍｅｎｄｅｄ ｐｒａｃｔｉｃｅなどとして位置づけられているものも含む）は全て含まれるものとする。

但し、ＩＥＥＥ８０２．１１ｎは、あくまで本発明の一例であり、本発明が無線通信方式全般に適用出来ることは言うまでもない。

無線通信装置１０１は、送信データ管理部１０２、アクセス制御部１０３、フレーム生成・送信部１０４、受信処理部１０５を備える。

送信データ管理部１０２は、送信データをバッファする送信キュー１０６を備える。送信データ管理部１０２は送信キュー１０６内の送信データを管理する。

アクセス制御部１０３は、フレームの送受信処理や、再送処理などの、アクセス制御を行う。アクセス制御部１０３が扱うフレームには、送信キュー１０６にバッファされた送信データを含むデータ（Ｄａｔａ）フレームが含まれる。また、送達確認フレーム（ＢｌｏｃｋＡｃｋフレームなど）や、ＩＡＣフレーム、ＲＡＣフレーム、ＲＴＳフレーム、ＣＴＳフレームなどのコントロールフレームや、マネジメントフレームも含まれる。アクセス制御部１０３は、送受信方法決定部１０７と送受信状態管理部１０８とキャリアセンス部１０９と備える。

送受信方法決定部１０７は、Ａｇｇｒｅｇａｔｉｏｎ方式やＲｅｖｅｒｓｅ Ｄｉｒｅｃｔｉｏｎ（ＲＤ）方式やＲＴＳ−ＣＴＳフレーム交換の有無などを含む送受信方法を決定する。

送受信状態管理部１０８は、前記データ送受信方式決定部１０７が決定した送受信方法に係る、送受信のタイミング管理や再送処理などのアクセス制御を行う。

キャリアセンス部１０９は、受信処理部１０５を監視し、受信したフレーム内のＤｕｒａｔｉｏｎフィールドに書かれたＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）の値が示す時間中はＢｕｓｙとなるバーチャルキャリアセンス処理と、受信電力が所定の値よりも大きいときにＢｕｓｙとなるキャリアセンス処理とを行う。

フレーム生成・送信処理部１０４は、コントロールフレームやＤａｔａフレームを生成する。またフレーム生成・送信処理部１０４はフレームのＡｇｇｒｅｇａｔｉｏｎをして、送信処理を行う。

受信処理部１０５は、受信フレームの識別処理と送達確認のビットマップを作成するなどの受信処理を行う。

図２はＲＤ方式で送受信する際にＨＴＰ Ｂｕｒｓｔ方式を使用して、ＢｌｏｃｋＡｃｋフレームと複数のＤａｔａフレームとを異なる伝送レートで送信する方法を説明するタイミングチャートである。また、図３は端末Ａ２０１の動作に係るフローチャート、図４は端末Ｂ２０２の動作に係るフローチャートである。

以下説明する双方向通信では、Ｉｎｉｔｉａｔｏｒである端末Ａ２０１からの送信データは全てＲｅｓｐｏｎｄｅｒである端末Ｂ２０２宛てのデータであり、端末Ｂ２０２からの送信データも全て端末Ａ２０１宛てのデータであるとして説明する。これら端末Ａ２０１および端末Ｂ２０２は無線通信装置１０１の構成であるものとし、図１の対応する符号を用いる。

この双方向通信は図５のように、端末Ａ２０１と端末Ｂ２０２が属している無線通信システムに端末Ａ２０１及び端末Ｂ２０２以外にも、送信データの宛先とならない端末Ｃ２０３、端末Ｄ２０４、端末Ｅ２０５、端末Ｆ２０６も存在するものとする。

端末Ｃ２０３は、端末Ａ２０１と端末Ｂ２０２との双方向通信が始まるときに、端末Ａ２０１の送信波を受信できる範囲２０７および端末Ｂ２０２の送信波を受信できる範囲２０８の内にある。

端末Ｄ２０４は、端末Ａ２０１と端末Ｂ２０２との双方向通信が始まるときに、端末Ａ２０１の送信波を受信できる範囲２０７の内であって端末Ｂ２０２の送信波を受信できる範囲２０８の外にある。

端末Ｅ２０５は、端末Ａ２０１と端末Ｂ２０２との双方向通信が始まるときに、端末Ａ２０１の送信波を受信できる範囲２０７の外であって端末Ｂ２０２の送信波を受信できる範囲２０８の内にある。

端末Ｆ２０６は、端末Ａ２０１と端末Ｂ２０２との双方向通信が始まるときには、端末Ａ２０１および端末Ｂ２０２のの送信波を受信できず、端末Ａ２０１と端末Ｂ２０２との双方向通信の開始後（すなわちＲＴＳ−ＣＴＳ交換が完了した後）に端末Ａ２０１およんび端末Ｂ２０２の送信波を受信できるようになるものとする。

Ｄａｔａフレームの送達確認方法（ＡｃｋＰｏｌｉｃｙ）をＩＥＥＥ８０２．１１ｎで提案されているＢｌｏｃｋＡｃｋ方式のうちのＩｍｐｌｉｃｉｔＢｌｏｃｋＡｃｋ方式とする。ＢｌｏｃｋＡｃｋ方式では、送信者が送信したフレームの送達確認として、受信者からＢｌｏｃｋＡｃｋフレームを送信する。また、ＩｍｐｌｉｃｉｔＢｌｏｃｋＡｃｋ方式では、送信者がＢｌｏｃｋＡｃｋフレームの送信要求をとしての送達確認要求フレーム（ＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレーム）を送信しない。

端末Ａ２０１は、予めアソシエーションなどのマネジメントフレーム交換を端末Ｂ２０２と行い、端末Ｂ２０２がＲＤ方式をサポートしていることと、端末Ｂ２０２が端末Ａ２０１へ送信したいデータの量とを知っているものとする。

またこのマネジメントフレーム交換で、ＲＤ方式のネゴシエーションをするのであれば端末Ａ２０１が最初に送信するＡｇｇｒｅｇａｔｉｏｎフレーム３０４の次からはＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを互いに送信してくることを、マネジメントフレームに書き込むことによって、端末Ａ２０１と端末Ｂ２０２との両方が知る。その後、端末Ａ２０１と端末Ｂ２０２との両方は、ＲＤ方式の通信における待ち受けの際にはＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを待ち受けることにする。

ただし、ＲＤ方式で双方向通信を行うことがわかった時点で（すなわちマネジメントフレーム交換をするまでもなく）ＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを待ち受けることにするよう取り決めてあってもよい。

ただし、ＲＤ方式の通信における待ち受けの際にＲＩＦＳ時間を挟んだ、３つあるいはそれ以上のＰＨＹフレームを待ち受けることにするよう決めてもよい。

あるいは端末Ａ２０１が基地局としての動作を行う場合は、端末Ａ２０１から送信するＢｅａｃｏｎフレームに、ＲＤ方式をするのであれば端末Ａ２０１が最初のＡｇｇｒｅｇａｔｉｏｎフレーム３０４の次からはＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを送信することを書き込むことにしてもよい。

（１−１−１．端末ＡのＲＴＳフレーム送信）
端末Ａ２０１では双方向通信を開始するに先立って送信キュー１０６にデータが蓄積されると、送信データ管理部１０２は送受信状態管理部１０８に、蓄積された送信データの優先度と量と送信宛先とを渡す（図３のステップ１）。

送信状態管理部１０８は、受け取った送信データの優先度について、キャリアセンス部１０９に送信可能か否かを問い合わせる。キャリアセンス部１０９は受信電力が一定値以上である（Ｉｄｌｅ）か否（Ｂｕｓｙ）か監視している（キャリアセンス処理）。またキャリアセンス部１０９は送信帯域の予約がなされているか否かを監視する（バーチャルキャリアセンス処理）。送信状態管理部１０８は、キャリアセンス部１０９のキャリアセンスとバーチャルキャリアセンスとの結果が共にＩｄｌｅで送信帯域の予約がなされていない期間が、ＡＩＦＳ＋Ｂａｃｋｏｆｆ時間（Ｂａｃｋｏｆｆは場合によっては行わない。以下も同様。）だけ継続している場合に、送信可能であると判断する。送信可能であると判断した送信状態管理部１０８は、送信データの優先度と量と送信宛先とを送受信方法決定部１０７へ渡す（図３のステップ２）。

送受信方法決定部１０７では、ＲＴＳフレーム３０１とＣＴＳフレーム３０３の交換を行うこととＲＤ方式で双方向通信を行うことと、ＴＸＯＰ時間のなかで帯域予約をする時間（ＮＡＶ時間）の長さ（本実施の形態ではＴＸＯＰ時間と等しい）と、端末Ｂ２０２に分け与えるＴＸＯＰ時間の一部（ＴＸＯＰ 分与時間）の長さとを決定する（図３のステップ３）。

ここで、ＮＡＶ時間やＴＸＯＰ分与時間は例えば一定の値としてもよいし、いかなる計算方法によって算出されるものであってもよい。計算方法については本願発明の趣旨ではないため説明を省略する。

送受信状態管理部１０８では、送受信方法決定部１０７で決定した事に従って、フレーム生成・送信処理部１０４にＲＴＳフレーム３０１のＤｕｒａｔｉｏｎフィールドに書き込むＮＡＶの値を渡す（図３のステップ４）。ＲＴＳフレーム３０１に書き込むＮＡＶの値は、ＲＤ方式で使用するＴＸＯＰＬｉｍｉｔまでの時間として扱われる。

フレーム生成・送信処理部１０４は、受け取ったＴＸＯＰ時間の長さをＮＡＶの値としてＤｕｒａｔｉｏｎフィールドに書き込んだＲＴＳフレーム３０１を生成し、第１の伝送レートで送信する（図３のステップ５）。

第１の伝送レートは例えば８０２．１１ａ規格などの伝送レートもしくはベーシックレートである。あるいは８０２．１１ｎにおける低いほうの伝送レートもしくはベーシックレートである。例えば、８０２．１１ｎをサポートしていないが８０２．１１ａはサポートしている端末が端末Ａ２０１あるいは端末Ｂ２０２ の送信波を受信できる位置にある場合は８０２．１１ａの伝送レートとする。逆に、端末Ａ２０１あるいは端末Ｂ２０２ の送信波を受信できる位置に８０２．１１ｎをサポートしている端末しかない場合は８０２．１１ｎの低いほうの伝送レートもしくはベーシックレートとする。または８０２．１１ｎをサポートしていない端末が存在するが８０２．１１ｎをサポートしていない端末には既に帯域予約がなされている場合は、８０２．１１ｎの低いほうの伝送レートもしくはベーシックレートとする。端末Ａ２０１が送信した端末Ｂ２０２宛のＲＴＳフレーム３０１は端末Ｃ２０３および端末Ｄ２０４にも受信される。端末Ｃ２０３および端末Ｄ２０４は、受信したＲＴＳフレーム３０１の宛先が端末Ｂ２０２であることがわかると、その送信帯域を用いての通信をＮＡＶ時間だけ行わないようにする。その結果、端末Ａ２０１にとっては送信帯域の予約ができたことになる。

ＲＴＳフレーム３０１の送信が済むと、受信処理部１０５はＳＩＦＳ時間に加えて１ｓｌｏｔ分の時間だけ端末Ｂ２０２からのＣＴＳフレーム３０３を待ち受ける。もしＳＩＦＳ時間に１ｓｌｏｔ分の時間を加えた時間内にＣＴＳフレーム３０３を受信開始できなかったら、ＲＴＳフレーム３０１を再送するためのＢａｃｋｏｆｆ処理を開始する（図３のステップ６）
（１−１−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
端末Ｂ２０２の受信処理部１０５は、ＲＴＳフレーム３０１を受信し、それが完了してからＳＩＦＳ時間後にＣＴＳフレーム３０３を第１の伝送レートで送信する（図４のステップ１０１）。ＣＴＳフレーム３０３にはＮＡＶの値として、ＲＴＳフレーム３０１に書かれたＮＡＶの値からＳＩＦＳ時間とＣＴＳフレーム３０３の送信にかかる時間を差し引いた値が書き込まれている（各フレーム単体の長さは予めわかっており、送信レートも決めているので、送信にかかる時間もわかる）。これらＲＴＳフレーム３０１とＣＴＳフレーム３０３は、既存の規格であるＩＥＥＥ８０２．１１の通常のＲＴＳ−ＣＴＳ交換と同様の為、この時点では端末Ｂ２０２は、端末Ａ２０１がＲＤ方式を使用する事を知らない。

ＣＴＳフレーム３０３の送信が済むと、受信処理部１０５はＤａｔａフレームを受信するまで待ち受ける（図４のステップ１０２）。

端末Ｂ２０２が送信した端末Ａ２０１宛のＣＴＳフレーム３０３は端末Ｅ２０５にも受信される。端末Ｅ２０５は、受信したＣＴＳフレーム３０３の宛先が端末Ａ２０１であることがわかると、その送信帯域を用いての通信を、ＣＴＳフレーム３０３に書き込まれたＮＡＶの値だけ行わないようにする。その結果、端末Ａ２０１にとっては送信帯域の予約ができたことになる。

（１−１−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
端末Ａ２０１では、端末Ｂ２０２からのＣＴＳフレーム３０３を受信処理部１０５が受信すると、ＣＴＳフレーム３０３を受信したことを表す値と、ＣＴＳフレーム３０３に書かれたＮＡＶの値とを、送受信状態管理部１０８に渡す（図３のステップ７）。

送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、送受信方法決定部１０７が決定したＴＸＯＰ 分与時間と共に、フレーム生成・送信処理部１０４へ渡す（図３のステップ８）。

フレーム生成・送信処理部１０４では、送信データから、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームとしてＤａｔａ１−Ａ３０５を、Ｄａｔａフレームとして Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８を、それぞれ作成する。またこれらのフレームを、Ｄａｔａ１−Ａ３０５を先頭として、Ｄａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８の順にそれぞれの先頭に各フレーム間を識別するフィールドをつけて結合したＡｇｇｒｅｇａｔｉｏｎフレーム３０４を作成する（図３のステップ９）。

ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ１−Ａ３０５のＱｏＳ ＣｏｎｔｒｏｌフィールドにはＴＸＯＰ 分与時間が書き込まれる。本実施の形態ではこのＴＸＯＰ分与時間は、ＲＩＦＳ時間と、後述するＡｇｇｒｅｇａｔｉｏｉｎ ｆｒａｍｅ３１１の送信にかかる時間と、ＳＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｉｎ ｆｒａｍｅ３１１に対するＢｌｏｃｋＡｃｋフレーム３１７の送信にかかる時間とを足し合わせた値である。Ｄａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８それぞれには、端末Ｂ２０２が送信したＣＴＳフレーム３０３に書かれていたＮＡＶの値から、ＳＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の送信にかかる時間とを差し引いた値がＮＡＶの値として書き込まれる。このＮＡＶの値はすなわち、Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。

フレーム生成・送信処理部１０４は、端末Ｂ２０２のＣＴＳフレーム３０３を受信処理部１０５が受信完了してからＳＩＦＳ時間後に、Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の送信を開始する（図３のステップ１０）。この送信は、第１の伝送レートよりも高い第２の伝送レートで行われる。この第２の伝送レートは例えば８０２．１１ｎ規格の高いほうの伝送レート、例えばＭＩＭＯによる高いレートである。

Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の送信が済むと、受信処理部１０５はＳＩＦＳ時間に加えて１ｓｌｏｔ分の時間だけ端末Ｂ２０２からのＢｌｏｃｋＡｃｋフレーム３１０を待ち受ける。もしＳＩＦＳ時間に１ｓｌｏｔ分の時間を加えた時間内にＢｌｏｃｋＡｃｋフレーム３１０を受信できなかったら、Ａｇｇｒｅｇａｔｉｏｎフレーム３０４を再送する（図３のステップ１１）。

ここで、端末Ａ２０１は自らがＲＤ方式を使用することを知っているので、このあとの待ち受けにおいて、受信処理部１０５にＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを待ち受けさせる。

（１−１−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
Ａｇｇｒｅｇａｔｉｏｎフレーム３０４を受信した端末Ｂ２０２の受信処理部１０５は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値と、Ｄａｔａ１−Ａ３０５内に書かれたＴＸＯＰ分与時間と、Ｄａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８それぞれに書かれたＮＡＶの値とを、送受信状態管理部１０８に渡す。また、受信処理部１０５は、端末Ａ２０１から送信されたＤａｔａ１−Ｂ３１２，Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を相手に通知するＢｉｔｍａｐを作成し、送受信状態管理部１０８に渡す。（図４のステップ１０３）。

端末Ｂ２０２は、ＴＸＯＰ分与時間を与えられたことを通知するＰｏｌｌフレームとしての機能も持ったＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信した時点ではじめて、端末Ａ２０１がＲＤ方式を使用することを知る。ＲＤ方式を使用することを知った端末Ｂ２０２は、ＴＸＯＰ分与時間のなかで端末Ａ２０１へ送信したい送信データをＤａｔａフレームにして送信する。

端末Ａ２０１がＲＤ方式を使用することを知った端末Ｂ２０２は、このあとの待ち受けにおいて、受信処理部１０５にＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを待ち受けさせる。

送受信状態管理部１０８は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値から、端末Ａ２０１がＲＤ方式で通信していると判断する。そして送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、ＴＸＯＰ分与時間と、受信処理部１０５から受け取ったＮＡＶの値と送達確認を相手に通知するＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図４のステップ１０４）。送信キュー１０６から取り出す送信データの量については後述する。

フレーム生成・送信処理部１０４は送達確認を相手に通知するＢｉｔｍａｐを用いて、端末Ａ２０１から送信されたＤａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８に対する送達確認（ＢｌｏｃｋＡｃｋ）フレーム３１０を作成する。またフレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５を作成する。Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５を結合してＡｇｇｒｅｇａｔｉｏｎフレーム３１１を作成する。

ここでフレーム生成・送信処理部１０４は、受け取ったＮＡＶの値からＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３１０の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３１０にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム３１０の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。

フレーム生成・送信処理部１０４は、 ＢｌｏｃｋＡｃｋフレーム３１０に書き込んだＮＡＶの値からＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム３１１を送信にかかる時間とを差し引いた値を、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、Ａｇｇｒｅｇａｔｉｏｎフレーム３１１の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。（図４のステップ１０５）。

以下、ＢｌｏｃｋＡｃｋフレームとＡｇｇｒｅｇａｔｉｏｎフレームとの間にＲＩＦＳ時間を挟んだものを、ＨＴＰ Ｂｕｒｓｔ フレームと呼ぶ（詳しくは第１０の実施の形態にて述べる）。送受信状態管理部１０８が送信キュー１０６から取り出してフレーム生成・送信処理部１０４に渡す送信データの量は、ＨＴＰ Ｂｕｒｓｔフレーム３５１のフレーム長が、Ｄａｔａ１−Ａ３０５に書き込まれていたＴＸＯＰ 分与時間を超えない量とする。フレーム生成・送信処理部１０４は、端末Ａ２０１から送信されたＡｇｇｒｅｇａｔｉｏｎフレーム３０４を受信処理部１０５が受信完了してからＳＩＦＳ時間後に、作成したＨＴＰ Ｂｕｒｓｔフレーム３５１の送信を開始する。

ＨＴＰ Ｂｕｒｓｔフレーム３５１の送信について詳述する。まずＢｌｏｃｋＡｃｋフレーム３１０の送信を開始する（図４のステップ１０６）。ＢｌｏｃｋＡｃｋフレーム３１０の送信の伝送レートを第１の伝送レートとする。

フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３１０の送信を完了した後にＲＩＦＳ時間だけ、Ａｇｇｒｅｇａｔｉｏｎフレーム３１１の送信を開始するのを待つ（図４のステップ１０７）。この間にフレーム生成・送信処理部１０４は、伝送レートを第１の伝送レートから第２の伝送レートに変更する。

フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３１０の送信を完了した後にＲＩＦＳ時間だけ経つと、第２の伝送レートで、Ａｇｇｒｅｇａｔｉｏｎフレーム３１１を送信する（図４のステップ１０８）。
Ａｇｇｒｅｇａｔｉｏｎフレーム３１１の送信が済むと、受信処理部１０５は端末Ａ２０１からのフレームを待ち受ける（図４のステップ１０９）。

（１−１−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ＨＴＰ Ｂｕｒｓｔフレームを受信したときに、端末Ｂ２０２へ送信したいデータが送信キュー１０６に蓄積されている場合の端末Ａ２０１の動作について説明する。

ＨＴＰ Ｂｕｒｓｔフレーム３５１を受信した端末Ａ２０１の受信処理部１０５は、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を示す送達確認を相手に通知するＢｉｔｍａｐを生成し、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５それぞれに書かれたＮＡＶの値と共に送受信状態管理部１０８に渡す。また受信処理部１０５は、ＢｌｏｃｋＡｃｋフレーム３１０に書き込まれた、受信したＢｉｔｍａｐも送受信状態管理部１０８に渡す（図３のステップ１２）。

送受信状態管理部１０８は、受信したＢｉｔｍａｐにＤａｔａ１−Ａ３０５，Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８それぞれの不送達を示す値が書き込まれている場合はそのＤａｔａフレームを再送すべく、後述するＡｇｇｒｅｇａｔｉｏｎフレーム３１８に入れる。また送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、送受信方法決定部１０７から受け取ったＴＸＯＰ 分与時間と受信処理部１０５から受け取ったＮＡＶの値と送信Ｂｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図３のステップ１３）。

フレーム生成・送信処理部１０４は受け取った送信Ｂｉｔｍａｐを用いて、端末Ｂ２０２から送信されたＤａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５に対するＢｌｏｃｋＡｃｋフレーム３１７を作成する。またフレーム生成・送信処理部１０４は、送信データからＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームとしてのＤａｔａ５−Ａ３１９と、ＤａｔａフレームとしてのＤａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２のＡｇｇｒｅｇａｔｉｏｎフレーム３１８を作成する。ただし、再送するＤａｔａフレームがある場合は、ここで作成する新規のＤａｔａフレームの前に再送するＤａｔａフレームをつける。ただし再送するＤａｔａフレームの数が多い場合、新規のＤａｔａフレームの数を減らすか、新規のＤａｔａフレームをつけないようにする。ここでフレーム生成・送信処理部１０４は、受信処理部１０５から受け取ったＮＡＶの値からＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３１７の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３１７にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム３１７の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。

フレーム生成・送信処理部１０４は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ１−Ａ３０５にはＴＸＯＰ 分与時間を書き込む。

フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３１７に書き込んだＮＡＶの値からＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム３１８を送信にかかる時間とを差し引いた値を、Ｄａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、Ａｇｇｒｅｇａｔｉｏｎフレーム３１８の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる（図３のステップ１４）。フレーム生成・送信処理部１０４は、端末Ｂ２０２から送信されたＨＴＰ Ｂｕｒｓｔフレーム３５１を受信処理部１０５が受信完了してからＳＩＦＳ時間後に、作成したＨＴＰ Ｂｕｒｓｔフレーム３５２の送信を開始する。

ＨＴＰ Ｂｕｒｓｔフレーム３５２の送信について詳述する。まずＢｌｏｃｋＡｃｋフレーム３１７の送信を開始する（図３のステップ１５）。ＢｌｏｃｋＡｃｋフレーム３１７の送信の伝送レートを第１の伝送レートとする。

フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３１７の送信を完了した後にＲＩＦＳ時間だけ、Ａｇｇｒｅｇａｔｉｏｎフレーム３１８の送信を開始するのを待つ（図３のステップ１６）。この間にフレーム生成・送信処理部１０４は、伝送レートを第１の伝送レートから第２の伝送レートに変更する。

フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３１７の送信を完了した後にＲＩＦＳ時間だけ経つと、第２の伝送レートで、Ａｇｇｒｅｇａｔｉｏｎフレーム３１８を送信する（図３のステップ１７）。

端末Ｆ２０６は端末Ａ２０１が送信したＲＴＳフレーム３０１や端末Ｂ２０２が送信したＣＴＳフレーム３０３は、それらが送信されたときに受信できる状態でなかったので受信できなかったが、通信を受信できるようになったあとでいずれかのＢｌｏｃｋＡｃｋフレームあるいはＡｇｇｒｅｇａｔｉｏｎフレームを受信することで、その中に書き込まれたＮＡＶの値を知り、そのＮＡＶの値の時間だけはその送信帯域を用いての通信を行わないようにする。その結果、端末Ａ２０１にとっては送信帯域の予約が端末Ｆ２０６に対してもできたことになる。

また端末Ｆ２０６が８０２．１１ｎをサポートしておらずＡｇｇｒｅｇａｔｉｏｎフレームの受信やＭＩＭＯによる高い伝送レートで送信されるフレームを受信できなくても、Ｄａｔａフレームに先立って、端末Ｆ２０６も受信できる第１の伝送レートでＢｌｏｃｋＡｃｋフレーム３１７が送信される為、端末Ｆ２０６はＡｇｇｒｅｇａｔｉｏｎ ｆｔｒａｍｅ３１８として送られてくるＤａｔａフレームを受信する前にＢｌｏｃｋＡｃｋフレーム３１７よってその宛先とＮＡＶの値を知ることができる。端末Ｆ２０６はこの宛先とＮＡＶの値を知ることで、その後に送られてくるＤａｔａフレームを受信できない場合であっても、帯域予約されていることおよびその長さを知ることができる。

ＨＴＰ Ｂｕｒｓｔフレーム３５２の送信が済むと、受信処理部１０５はＳＩＦＳ時間に加えて１ｓｌｏｔ分の時間だけ端末Ａ２０１からのＢｌｏｃｋＡｃｋフレーム３２４を待ち受ける。もしＳＩＦＳ時間に１ｓｌｏｔ分の時間を加えた時間内にＢｌｏｃｋＡｃｋフレーム３２４を受信できなかったらＨＴＰ Ｂｕｒｓｔフレーム３５２を再送する（図３のステップ１８）。

（１−１−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ＲＩＦＳ時間を挟んだ２つのＰＨＹフレーム、すなわちＨＴＰ Ｂｕｒｓｔフレーム３５２を受信した端末Ｂ２０２の受信処理部１０５は、Ｄａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２の受信成否状況から、送達確認を示す、送達確認を相手に通知するＢｉｔｍａｐを生成する。受信処理部１０５は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値と、Ｄａｔａ５−Ａ３１９内に書かれたＴＸＯＰ 分与時間と、Ｄａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２それぞれに書かれたＮＡＶの値と、送達確認を相手に通知するＢｉｔｍａｐと、ＢｌｏｃｋＡｃｋフレーム３１７に書き込まれ受信したＢｉｔｍａｐとを、送受信状態管理部１０８に渡す（図４のステップ１１０）。

送受信状態管理部１０８は、受信したＢｉｔｍａｐにＤａｔａ１−Ｂ３１２，Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５それぞれの不送達を示す値が書き込まれている場合はそのＤａｔａフレームを再送すべく、後述するＡｇｇｒｅｇａｔｉｏｎフレーム３２５に入れる。また送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、受信処理部１０５から受け取ったＮＡＶの値と、送達確認を相手に通知するＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図４のステップ１１１）。送信キュー１０６から取り出す送信データの量については後述する。

フレーム生成・送信処理部１０４は送達確認を相手に通知するＢｉｔｍａｐを用いて、端末Ａ２０１から送信されたＤａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２に対するＢｌｏｃｋＡｃｋフレーム３２４を作成する。

またフレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９を作成する。Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９を結合してＡｇｇｒｅｇａｔｉｏｎフレーム３２５を作成する（図４のステップ１１２）。

ここでフレーム生成・送信処理部１０４は、受け取ったＮＡＶの値からＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３２４の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３２４にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム３２４の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。

またフレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３２４に書き込んだＮＡＶの値からＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム３２５を送信にかかる時間とを差し引いた値を、Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、Ａｇｇｒｅｇａｔｉｏｎフレーム３２５の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。送受信状態管理部１０８が送信キュー１０６から取り出してフレーム生成・送信処理部１０４に渡す送信データの量は、ＢｌｏｃｋＡｃｋフレーム３２４とＡｇｇｒｅｇａｔｉｏｎフレーム３２５との間にＲＩＦＳ時間を挟んだＨＴＰ Ｂｕｒｓｔフレームのフレーム長が、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ５−Ａ３１９に書き込まれていたＴＸＯＰ 分与時間を超えない量とする。ただし、再送すべきＤａｔａフレームがある場合は、ここで作成するＤａｔａフレームの数をその分だけ減らす。つまり、送受信状態管理部１０８が送信キュー１０６から取り出してフレーム生成・送信処理部１０４に渡す送信データの量は、ＢｌｏｃｋＡｃｋフレーム３２４とＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム３２５とで形成するＨＴＰ Ｂｕｒｓｔフレーム３５３のフレーム長がＴＸＯＰ 分与時間を超えない量とする。

フレーム生成・送信処理部１０４は、端末Ａ２０１から送信されたＨＴＰ Ｂｕｒｓｔフレームを受信処理部１０５が受信完了してからＳＩＦＳ時間後に、作成したＨＴＰ Ｂｕｒｓｔフレーム３５３の送信を開始する。

ＨＴＰ Ｂｕｒｓｔフレーム３５３の送信について詳述する。まずＢｌｏｃｋＡｃｋフレーム３２４の送信を開始する（図４のステップ１１３）。ＢｌｏｃｋＡｃｋフレーム３２４の送信の伝送レートを第１の伝送レートとする。

フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３２４の送信を完了した後にＲＩＦＳ時間だけ、Ａｇｇｒｅｇａｔｉｏｎフレーム３２５の送信を開始するのを待つ（図４のステップ１１４）。この間にフレーム生成・送信処理部１０４は、伝送レートを第１の伝送レートから第２の伝送レートに変更する。

フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３２４の送信を完了した後にＲＩＦＳ時間だけ経つと、第２の伝送レートで、Ａｇｇｒｅｇａｔｉｏｎフレーム３２５を送信する（図４のステップ１１５）。

ＨＴＰ Ｂｕｒｓｔフレーム３５３の送信が済むと、受信処理部１０５は端末Ａ２０１からのフレームを待ち受ける（図４のステップ１１６）。

（１−１−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＢｌｏｃｋＡｃｋフレーム送信）
ＨＴＰ Ｂｕｒｓｔフレーム３５３を受信したときに、端末Ｂ２０２へ送信したいデータが送信キュー１０６になく、再送するＤａｔａフレームもない場合、あるいＴＸＯＰ時間の終了間際でこれ以上送信を継続できない場合のＮＡＶ時間の終了における端末Ａ２０１の動作について説明する。

ＲＩＦＳ時間を挟んだ２つのＰＨＹフレーム、すなわちＨＴＰ Ｂｕｒｓｔフレーム３５３を受信した端末Ａ２０１の受信処理部１０５は、Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９の受信成否状況から、送達確認を示すＢｉｔｍａｐを生成し、Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９それぞれに書かれたＮＡＶの値と共に送受信状態管理部１０８に渡す。また受信処理部１０５は、ＢｌｏｃｋＡｃｋフレーム３２４に書き込まれた、受信したＢｉｔｍａｐも送受信状態管理部１０８に渡す（図３のステップ１９）。

送受信状態管理部１０８は、受信したＢｉｔｍａｐから、Ｄａｔａ５−Ａ３１９，Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２それぞれの送達成否を確認する。また送受信状態管理部１０８は、受信処理部１０５から受け取ったＮＡＶの値をフレーム生成・送信処理部１０４へ渡す（図３のステップ２０）。

フレーム生成・送信処理部１０４は受け取ったＢｉｔｍａｐを用いて、端末Ｂ２０２から送信されたＤａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９に対するＢｌｏｃｋＡｃｋフレーム３３１を作成する。

ここでフレーム生成・送信処理部１０４は、受信処理部１０５から受け取ったＮＡＶの値からＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３３１の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３３１にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム３３１の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。（図３のステップ２１）。

フレーム生成・送信処理部１０４は、端末Ａ２０１から送信されたＨＴＰ Ｂｕｒｓｔフレーム３５３を受信処理部１０５が受信完了してからＳＩＦＳ時間後に、作成したＢｌｏｃｋＡｃｋフレーム３３１の送信を開始する（図３のステップ２２）。ＢｌｏｃｋＡｃｋフレーム３３１の送信の伝送レートは第１の伝送レートとする。

（１−１−８．ＴＸＯＰ時間の終了）
ＢｌｏｃｋＡｃｋフレーム３３１の送信終了時刻から、端末Ａ２０１が送信したＢｌｏｃｋＡｃｋフレーム３３１に書き込んだＮＡＶの値だけ時間が経過すると帯域予約が解かれて端末Ａ２０１と端末Ｂ２０２との双方向通信が終了する。この双方向通信が終了すると、端末Ａ２０１と端末Ｂ２０２それぞれの受信処理部１０５は、ＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを待ち受けるのをやめ、通常の待ち受け状態になる。さらにこの双方向通信を行いたい場合は帯域予約が解かれてからＡＩＦＳ＋Ｂａｃｋｏｆｆ 時間だけ経過した後、１−１−１の手順から再度行う。あるいは他の端末と本実施の形態のような双方向通信もしくは通常の通信を行いたい場合は、帯域予約が解かれてからＡＩＦＳ＋Ｂａｃｋｏｆｆ 時間だけ経過した後、他の端末を端末Ｂ２０２として１−１−１の手順から再度行う。

以上のように、本実施の形態では、コントロールフレームを低い伝送レートで送信しＤａｔａフレームを高い伝送レートで送信する。

低い伝送レートで送信するとノイズ等による伝送エラーの発生を抑えられる。逆に、高い伝送レートで送信すれば高速な送信が可能となる。

本発明によれば、コントロールフレームの受信失敗によるＲｅｓｐｏｎｄｅｒの再送依頼を抑えることと、Ｄａｔａフレームの高速送信との両立が出来る。

なお、本実施の形態の端末Ａ２０１および端末Ｂ２０２が、データを送信する周波数帯域として、従来のＩＥＥＥ８０２．１１ａ／ｂ／ｇなどで利用されている２０ＭＨｚ帯域の周波数帯域ではなく、ＩＥＥＥ８０２．１１ｎで提案されているような２つの２０ＭＨｚ帯域の周波数を束ねた４０ＭＨｚ帯域の周波数帯を使用する場合に、通常の送信データを４０ＭＨｚ帯域の周波数帯域で送信し、ＲＴＳフレーム３０１やＣＴＳフレーム３０３やＢｌｏｃｋＡｃｋフレーム３０５、３１０、３１７、３２４、３３１などのＮＡＶの値が書き込まれたフレームを、アナログ部の周波数帯域を４０ＭＨｚ帯域としたまま、デジタル処理部のＰＨＹレイヤーにて送信周波数帯域を２０ＭＨｚ帯域に切り替えて、２０ＭＨｚ帯域のフレームとして送信する事により、ＩＥＥＥ８０２．１１ａ／ｂ／ｇなどの２０ＭＨｚ帯域のみを使用する端末に対してＮＡＶの値を通知する事ができる。

２０ＭＨｚ帯域のみを使用する端末が存在しないか、２０ＭＨｚ帯域のみを使用する端末に対して既にＮＡＶが張られている場合など、コントロールフレームで２０ＭＨｚ帯域を使用する無線通信装置に対するＮＡＶを通知する必要がない場合は、ＢｌｏｃｋＡｃｋフレームを４０ＭＨｚ帯域での低い伝送レートに下げる事により、ＢｌｏｃｋＡｃｋフレームが無線通信システム内の全ての端末へ到達する可能性を高くすることが出来る。 また、本実施の形態では端末Ａ２０１からＲＴＳフレーム３０１を送信して端末Ｂ２０２からＣＴＳフレーム３０３を送信するＲＴＳ−ＣＴＳフレーム交換によってＮＡＶの値を通知するものとして説明した。しかしＮＡＶの値の通知方法はこれに限るものではない。いわゆるＩＡＣ−ＲＡＣフレーム交換や、ＣＴＳ−ｓｅｌｆフレームを送信したＳＩＦＳ時間だけ後にＡｇｇｒｅｇａｔｉｏｎフレームを送信する方法などにおいても、本実施の形態のようなＨＴＰ Ｂｕｒｓｔフレームを送信することが可能であることはいうまでもない。

または、ＨＣＣＡ方式による通信のように基地局からＨＣＣＡ時間のＮＡＶによる帯域予約がなされている場合は、ＲＴＳ−ＣＴＳフレーム交換などを行わずにＡｇｇｒｅｇａｔｉｏｎフレームの送信からＲＤ方式を開始してもよい。

また、本実施の形態ではＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームにＴＸＯＰ 分与時間を書き込むとして説明したが、ＱｏＳ Ｃｆ−Ｐｏｌｌ フレームとＤａｔａフレームとを分け、ＱｏＳ Ｃｆ−Ｐｏｌｌ フレームのＱｏＳ ＣｏｎｔｒｏｌフィールドにＴＸＯＰ 分与時間を書き込む構成としてもよい。

また、本実施の形態では端末Ａ２０１と端末Ｂ２０２との双方向通信であるとして説明したが、端末Ａ２０１や端末Ｂ２０２が基地局であっても端末局であっても何ら問題はない。ただし、端末Ａ２０１が基地局である場合は、予約されていた送信帯域が解放された後にＲＴＳフレームの送信をしようとする場合、解放から、ＡＩＦＳ＋Ｂａｃｋｏｆｆ時間ででアクセスを開始するＥＤＣＡ方式によるアクセスを行ってもよい。あるいは、ＰＩＦＳ時間だけ経過した後にＲＴＳフレームやＱｏＳ Ｃｆ−ＰｏｌｌフレームやＤａｔａフレームの送信を行うＨＣＣＡ方式によるアクセスを行ってもよい。

（第１の実施の形態の変形例１）
第１の実施の形態では、端末Ａ２０１がＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームにＴＸＯＰ 分与時間を書き込んでいた。すなわち、端末Ａ２０１がＴＸＯＰ 分与時間を端末Ｂ２０２に通知した。端末Ｂ２０２は与えられたＴＸＯＰ分与時間を越えない量の送信データを送信していた。

しかし端末Ｂ２０２がＴＸＯＰ分与時間に関係なく送りたいだけ送信データを送信するよう構成してもよい。

その場合、端末Ａ２０１がＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームにＴＸＯＰ 分与時間を書き込む必要がない。図４のステップ１０５やステップ１１２において、送受信状態管理部１０８が送信キュー１０６から取り出してフレーム生成・送信処理部１０４に渡す送信データの量を任意にすればよい。

このようにしても、端末Ｂ２０２が送信するＢｌｏｃｋＡｃｋフレームのあとＲＩＦＳ時間を挟んで送られてくるＡｇｇｒｅｇａｔｉｏｎフレームの長短が変わるだけなので、端末Ａ２０１は問題なく受信することができる。以上のようにした結果、端末Ａ２０１はＴＸＯＰ分与時間を計算する必要がなくなる。

（第１の実施の形態の変形例２）
図６は、本変形例に係る無線通信装置２１０１の一例に係るブロック図である。図７は端末Ａ１２０１の動作に係るフローチャート、図８は端末Ｂ１２０２の動作に係るフローチャートである。

第１の実施の形態では、端末Ａ２０１および端末Ｂ２０２は共に、相手から受信したコントロールフレームあるいはＤａｔａフレームに書かれたＮＡＶの値から、自らのフレームの送信とＳＩＦＳ時間と相手が次に送信するＢｌｏｃｋＡｃｋフレームの送信にかかる時間にかかる時間を差し引いた値を自らが送信するフレームに書き込むＮＡＶの値とするものとして説明した。

本変形例は、タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、自らのフレームの送信とＳＩＦＳ時間と相手が次に送信するＢｌｏｃｋＡｃｋフレームの送信にかかる時間にかかる時間を差し引いた値を自らが送信するフレームに書き込むＮＡＶの値とする構成について説明する。

端末Ａ２０１および端末Ｂ２０２は、次に説明する無線通信装置１１０１の構成であるものとする。

無線通信装置１１０１は、図１に示した無線通信装置１０１の構成に加えて、タイマー１１０を備える。タイマー１１０は送受信状態管理部 １０８に、ある時刻までの残り時間情報を提供する。

その他の構成は図１の無線通信装置１０１と同様である。

（１−３−１．端末ＡのＲＴＳフレーム送信）
図７のステップ１００１からステップ１００４までは図３のステップ１からステップ４までと同様である。

フレーム生成・送信処理部１０４は、受け取ったＴＸＯＰ時間の長さをＮＡＶの値としてＤｕｒａｔｉｏｎフィールドに書き込んだＲＴＳフレーム３０１を生成し、第１の伝送レートで送信する。ＲＴＳフレーム３０１の送信を開始するとき、タイマー１１０はＮＡＶの値を初期値としてカウントダウンを開始する。（図７のステップ１００５）。

この後に続くステップ１００６は図３のステップ６と同様である。

（１−３−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
端末Ｂ１２０２のタイマー１１０は、受信処理部１０５が受信したＲＴＳフレーム３０１のＮＡＶの値を初期値としてカウントダウンを開始する。

また受信処理部１０５は、ＲＴＳフレーム３０１の受信完了からＳＩＦＳ時間後にＣＴＳフレーム３０３を第１の伝送レートで送信する（図８のステップ１１０１）。またＣＴＳフレーム３０３にはＮＡＶの値として、タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、ＳＩＦＳ時間とＣＴＳフレーム３０３を送信にかかる時間を差し引いた値が書き込まれている。

この後に続くステップ１１０２は図４のステップ１０２と同様である。

（１−３−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
端末Ａ１２０１では、端末Ｂ１２０２からのＣＴＳフレーム３０３を受信処理部１０５が受信すると、ＣＴＳフレーム３０３を受信したことを表す値を送受信状態管理部１０８に渡す（図７のステップ１００７）。

この後に続くステップ２００８は図３のステップ８と同様である。

フレーム生成・送信処理部１０４では、送信データから、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームとしてＤａｔａ１−Ａ３０５を、Ｄａｔａフレームとして Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８を、それぞれ作成する。またこれらのフレームを、Ｄａｔａ１−Ａ３０５を先頭として、Ｄａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８の順にそれぞれの先頭に各フレーム間を識別するフィールドをつけて結合したＡｇｇｒｅｇａｔｉｏｎフレーム３０４を作成する（図７のステップ１００９）。

ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ１−Ａ３０５にはＴＸＯＰ 分与時間が書き込まれる。Ｄａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８それぞれには、タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、ＳＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の送信にかかる時間とを差し引いた値がＮＡＶの値として書き込まれる。

この後に続くステップ１０１０からステップ１０１１までは図３のステップ１０からステップ１１までと同様である。

（１−３−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
Ａｇｇｒｅｇａｔｉｏｎフレーム３０４を受信した端末Ｂ２０２の受信処理部１０５は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値と、Ｄａｔａ１−Ａ３０５内に書かれたＴＸＯＰ 分与時間とを、送受信状態管理部１０８に渡す。また、受信処理部１０５は、端末Ａ２０１から送信されたＤａｔａ１−Ｂ３１２，Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を相手に通知するためのＢｉｔｍａｐを作成し、送受信状態管理部１０８に渡す。（図８のステップ１１０３）。

送受信状態管理部１０８は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値から、端末Ａ２０１がＲＤ方式で通信していると判断する。そして送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、ＴＸＯＰ 分与時間とＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図８のステップ１１０４）。

フレーム生成・送信処理部１０４はＢｉｔｍａｐを用いて、端末Ａ２０１から送信されたＤａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８に対するＢｌｏｃｋＡｃｋフレーム３１０を作成する。またフレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５を作成する。Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５を結合してＡｇｇｒｅｇａｔｉｏｎフレーム３１１を作成する。

ここでフレーム生成・送信処理部１０４は、タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、ＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３１０の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３１０にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム３１０の送信完了からＮＡＶ時間の終わりの時刻までの長さを示す値となる。

さらにフレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３１０に書き込んだＮＡＶの値から、ＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム３１１を送信にかかる時間とを差し引いた値を、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５にＮＡＶの値として書き込む（図８のステップ１１０５）。

この後に続くステップ１１０６からステップ１１０９までは図４のステップ１０６からステップ１０９までと同様である。

（１−３−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ＨＴＰ Ｂｕｒｓｔフレーム３５１を受信した端末Ａ１２０１の受信処理部１０５は、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を示すＢｉｔｍａｐを生成して送受信状態管理部１０８に渡す。（図７のステップ１０１２）。

送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、送受信方法決定部１０７から受け取ったＴＸＯＰ 分与時間と受信処理部１０５から受け取ったＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図７のステップ１０１３）。

フレーム生成・送信処理部１０４は受け取ったＢｉｔｍａｐを用いて、端末Ｂ１２０２から送信されたＤａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５に対するＢｌｏｃｋＡｃｋフレーム３１７を作成する。またフレーム生成・送信処理部１０４は、送信データからＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームとしてのＤａｔａ５−Ａ３１９と、ＤａｔａフレームとしてのＤａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２のＡｇｇｒｅｇａｔｉｏｎフレーム３１８を作成する。

ここでフレーム生成・送信処理部１０４は、タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、ＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３１７の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３１７にＮＡＶの値として書き込む。フレーム生成・送信処理部１０４は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ１−Ａ３０５にはＴＸＯＰ 分与時間を書き込む。フレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３１７に書き込んだＮＡＶの値からＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム３１８を送信にかかる時間とを差し引いた値を、Ｄａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２にＮＡＶの値として書き込む。（図７のステップ１０１４）。

この後に続くステップ１０１５からステップ１０１８までは図３のステップ１５からステップ１８までと同様である。

（１−３−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ＲＩＦＳ時間を挟んだ２つのＰＨＹフレーム、すなわちＨＴＰ Ｂｕｒｓｔフレーム３５２を受信した端末Ｂ２２０２の受信処理部１０５は、Ｄａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２の受信成否状況から、送達確認を示すＢｉｔｍａｐを生成する。受信処理部１０５は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値と、作成したＢｉｔｍａｐとを、送受信状態管理部１０８に渡す（図８のステップ１１１０）。

送受信状態管理部１０８は送信キュー１０６にバッファされた送信データを取り出し、受信処理部１０５から受け取ったＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図８のステップ１１１１）。

フレーム生成・送信処理部１０４はＢｉｔｍａｐを用いて、端末Ａ１２０１から送信されたＤａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２に対するＢｌｏｃｋＡｃｋフレーム３２４を作成する。またフレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９を作成する。Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９を結合してＡｇｇｒｅｇａｔｉｏｎフレーム３２５を作成する。

ここでフレーム生成・送信処理部１０４は、タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、ＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３２４の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３２４にＮＡＶの値として書き込む。

またフレーム生成・送信処理部１０４は、ＢｌｏｃｋＡｃｋフレーム３２４に書き込んだＮＡＶの値からＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム３２５を送信にかかる時間とを差し引いた値を、Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９にＮＡＶの値として書き込む（図８のステップ１１１２）。

この後に続くステップ１１１３からステップ１１１６までは図４のステップ１１３からステップ１１６までと同様である。

（１−３−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＢｌｏｃｋＡｃｋフレーム送信）
ＲＩＦＳ時間を挟んだ２つのＰＨＹフレーム、すなわちＨＴＰ Ｂｕｒｓｔフレーム３５３を受信した端末Ａ２２０１の受信処理部１０５は、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を示すＢｉｔｍａｐを生成して送受信状態管理部１０８に渡す。（図７のステップ１０１９）。

送受信状態管理部１０８は、受信処理部１０５から受け取ったＢｉｔｍａｐをフレーム生成・送信処理部１０４へ渡す（図７のステップ１０１９）。

フレーム生成・送信処理部１０４は受け取ったＢｉｔｍａｐを用いて、端末Ｂ１２０２から送信されたＤａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９に対するＢｌｏｃｋＡｃｋフレーム３３１を作成する。

ここでフレーム生成・送信処理部１０４は、受信処理部１０５から受け取ったＮＡＶの値からＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３３１の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３３１にＮＡＶの値として書き込む。

タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、ＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム３３１の送信にかかる時間とを差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３３１にＮＡＶの値として書き込む。（図７のステップ１０２０）。

この後に続くステップ１０２１からステップ２２までは図３のステップ２１からステップ２２までと同様である。

（１−３−８．ＴＸＯＰ時間の終了）
端末Ｂ２０２のタイマー１１０のカウントダウンが終了すると帯域予約が解かれて端末Ａ２０１と端末Ｂ２０２との双方向通信が終了する。さらにこの双方向通信を行いたい場合は、帯域予約が解かれてからＡＩＦＳ＋Ｂａｃｋｏｆｆ 時間だけ経過した後、１−１の手順から再度行う。

以上のように、タイマー１１０でカウントするＮＡＶ時間の終了までの残り時間から、自らのフレームの送信にかかる時間を差し引いた値を自らが送信するフレームに書き込むＮＡＶの値とする。その結果、相手から受信したコントロールフレームあるいはＤａｔａフレームにエラーがあったとしても確実にＮＡＶ時間の終了を認識することができる。

（第１の実施の形態の変形例３）
図９は、本変形例に係る無線通信装置２１０１の一例に係るブロック図である。図１０は端末Ａ２０１の動作に係るフローチャート、図１１は端末Ｂ２０２の動作に係るフローチャートである。

第１の実施の形態では、端末Ａ２０１および端末Ｂ２０２は共に、相手から受信したコントロールフレームあるいはＤａｔａフレームに書かれたＮＡＶの値から、自らのフレームの送信にかかる時間とＳＩＦＳ時間と相手が次に送信するＢｌｏｃｋＡｃｋフレームの送信にかかる時間を差し引いた値を自らが送信するフレームに書き込むＮＡＶの値とするものとして説明した。

本変形例は、ＲＴＣ（リアルタイムクロック）１１１が供給する時刻からＮＡＶの値を算出する構成について説明する。具体的には、ＲＴＣ１１１から得られる時刻情報を用いてＮＡＶ時間の終了時刻を控えておき、それから自らのフレームの送信開始時刻と、そのフレームの送信にかかる時間とＳＩＦＳ時間と相手が次に送信するＢｌｏｃｋＡｃｋフレームの送信にかかる時間を差し引いた値を、自らが送信するフレームに書き込むＮＡＶの値とする構成について説明する。

以下説明する双方向通信では、Ｉｎｉｔｉａｔｏｒである端末Ａ２０１からの送信データは全てＲｅｓｐｏｎｄｅｒである端末Ｂ２０２宛てのデータであり、端末Ｂ２０２からの送信データも全て端末Ａ２０１宛てのデータであるとして説明する。

これら端末Ａ２０１および端末Ｂ２０２は、次に説明する無線通信装置２１０１の構成であるものとする。

無線通信装置２１０１は、図１に示した無線通信装置１０１の構成に加えて、ＲＴＣ１１１を備える。ＲＴＣ１１１は送受信状態管理部１０８に時刻情報を提供する。

その他の構成は図１の無線通信装置１０１と同様である。

（１−４−１．端末ＡのＲＴＳフレーム送信）
図１０のステップ２００１からステップ２００６までは図３のステップ１からステップ３までと同様である。

（１−４−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
端末Ｂ２０２の送受信状態管理部１０８は、受信処理部１０５が受信したＲＴＳフレーム３０１のＮＡＶの値をＮＡＶ時間の終了時刻として記憶する。また受信処理部１０５は、ＲＴＳフレーム３０１の受信完了からＳＩＦＳ時間後にＣＴＳフレーム３０３を第１の伝送レートで送信する（図１１のステップ２１０１）。またＣＴＳフレーム３０３にはＮＡＶの値として、ＮＡＶ時間の終了時刻からＣＴＳフレーム３０３の送信完了予定時刻を差し引いた値が書き込まれている。ＣＴＳフレーム３０３の送信完了予定時刻は、ＲＴＣ１１１から得る時刻とＣＴＳフレーム３０３の送信にかかる時間から算出する。

この後に続くステップ２１０２は図４のステップ１０２と同様である。

（１−４−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
端末Ａ２０１では、端末Ｂ２２０２からのＣＴＳフレーム３０３を受信処理部１０５が受信すると、ＣＴＳフレーム３０３を受信したことを表す値を送受信状態管理部１０８に渡す（図１０のステップ２００７）。

この後に続くステップ２００８は図３のステップ８と同様である。

フレーム生成・送信処理部１０４では、送信データから、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームとしてＤａｔａ１−Ａ３０５を、Ｄａｔａフレームとして Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８を、それぞれ作成する。またこれらのフレームを、Ｄａｔａ１−Ａ３０５を先頭として、Ｄａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８の順にそれぞれの先頭に各フレーム間を識別するフィールドをつけて結合したＡｇｇｒｅｇａｔｉｏｎフレーム３０４を作成する。（図１０のステップ２００９）。ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ１−Ａ３０５にはＴＸＯＰ 分与時間が書き込まれる。Ｄａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８それぞれには、ＮＡＶ時間の終了時刻からＡｇｇｒｅｇａｔｉｏｎフレーム３０４の送信開始時刻とＡｇｇｒｅｇａｔｉｏｎフレーム３０４の送信にかかる時間とを差し引いた値がＮＡＶの値として書き込まれる。Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の送信開始時刻は、ＣＴＳフレーム３０３の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻からＡｇｇｒｅｇａｔｉｏｎフレーム３０４の送信開始時刻を算出することができる。

この後に続くステップ２０１０からステップ２０１１までは図３のステップ１０からステップ１１までと同様である。

（１−４−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
Ａｇｇｒｅｇａｔｉｏｎフレーム３０４を受信した端末Ｂ２２０２の受信処理部１０５は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値と、Ｄａｔａ１−Ａ３０５内に書かれたＴＸＯＰ 分与時間とを、送受信状態管理部１０８に渡す。また、受信処理部１０５は、端末Ａ２２０１から送信されたＤａｔａ１−Ｂ３１２，Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を示すＢｉｔｍａｐを作成し、送受信状態管理部１０８に渡す。（図１１のステップ２１０３）。

送受信状態管理部１０８は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値から、端末Ａ２０１がＲＤ方式で通信していると判断する。そして送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、ＴＸＯＰ 分与時間とＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図１１のステップ２１０４）。

フレーム生成・送信処理部１０４はＢｉｔｍａｐを用いて、端末Ａ２０１から送信されたＤａｔａ１−Ａ３０５， Ｄａｔａ２−Ａ３０６， Ｄａｔａ３−Ａ３０７， Ｄａｔａ４−Ａ３０８に対するＢｌｏｃｋＡｃｋフレーム３１０を作成する。またフレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５を作成する。Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５を結合してＡｇｇｒｅｇａｔｉｏｎフレーム３１１を作成する。

ここでフレーム生成・送信処理部１０４は、ＮＡＶ時間の終了時刻からＢｌｏｃｋＡｃｋフレーム３１０の送信開始時刻とＢｌｏｃｋＡｃｋフレーム３１０の送信にかかる時間を差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３１０にＮＡＶの値として書き込む。

ＢｌｏｃｋＡｃｋフレーム３１０の送信開始時刻は、Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻からＢｌｏｃｋＡｃｋフレーム３１０の送信開始時刻を算出することができる。

さらにフレーム生成・送信処理部１０４は、ＮＡＶ時間の終了時刻からＡｇｇｒｅｇａｔｉｏｎフレーム３１１の送信開始時刻とＡｇｇｒｅｇａｔｉｏｎフレーム３１１の送信にかかる時間を差し引いた値を、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５にＮＡＶの値として書き込む。

Ａｇｇｒｅｇａｔｉｏｎフレーム３１１の送信開始時刻は、Ａｇｇｒｅｇａｔｉｏｎフレーム３０４の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻かららＡｇｇｒｅｇａｔｉｏｎフレーム３１１の送信開始時刻を算出することができる（図１１のステップ２１０５）。

この後に続くステップ２１０６からステップ２１０９までは図４のステップ１０６からステップ１０９までと同様である。

（１−４−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ＨＴＰ Ｂｕｒｓｔフレームを受信した端末Ａ２０１の受信処理部１０５は、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を示すＢｉｔｍａｐを生成して送受信状態管理部１０８に渡す。（図１０のステップ２０１２）。

送受信状態管理部１０８は、送信キュー１０６にバッファされた送信データを取り出し、送受信方法決定部１０７から受け取ったＴＸＯＰ 分与時間と受信処理部１０５から受け取ったＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図１０のステップ２０１３）。

フレーム生成・送信処理部１０４は受け取ったＢｉｔｍａｐを用いて、端末Ｂ２０２から送信されたＤａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５に対するＢｌｏｃｋＡｃｋフレーム３１７を作成する。またフレーム生成・送信処理部１０４は、送信データからＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームとしてのＤａｔａ５−Ａ３１９と、ＤａｔａフレームとしてのＤａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２のＡｇｇｒｅｇａｔｉｏｎフレーム３１８を作成する。

ここでフレーム生成・送信処理部１０４は、ＮＡＶ時間の終了時刻からＢｌｏｃｋＡｃｋフレーム３１７の送信開始時刻とＢｌｏｃｋＡｃｋフレーム３１７の送信にかかる時間を差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３１７にＮＡＶの値として書き込む。フレーム生成・送信処理部１０４は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ１−Ａ３０５にはＴＸＯＰ 分与時間を書き込む。ＢｌｏｃｋＡｃｋフレーム３１７の送信開始時刻は、Ａｇｇｒｅｇａｔｉｏｎフレーム３１１の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻からＢｌｏｃｋＡｃｋフレーム３１７の送信開始時刻を算出することができる。

フレーム生成・送信処理部１０４は、ＮＡＶ時間の終了時刻からＡｇｇｒｅｇａｔｉｏｎフレーム３１８の送信開始時刻とＡｇｇｒｅｇａｔｉｏｎフレーム３１８の送信にかかる時間を差し引いた値を、Ｄａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２にＮＡＶの値として書き込む。Ａｇｇｒｅｇａｔｉｏｎフレーム３１８の送信開始時刻は、Ａｇｇｒｅｇａｔｉｏｎフレーム３１１の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻からＡｇｇｒｅｇａｔｉｏｎフレーム３１８の送信開始時刻を算出することができる（図１０のステップ２０１４）。

この後に続くステップ２０１５からステップ２０１８までは図３のステップ１５からステップ１８までと同様である。

（１−４−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ＨＴＰ Ｂｕｒｓｔフレームを受信した端末Ｂ２０２の受信処理部１０５は、Ｄａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２の受信成否状況から、送達確認を示すＢｉｔｍａｐを生成する。受信処理部１０５は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを受信したことを表す値と、Ｄａｔａ５−Ａ３１９内に書かれたＴＸＯＰ 分与時間と、作成したＢｉｔｍａｐとを、送受信状態管理部１０８に渡す（図１１のステップ２１１０）。

送受信状態管理部１０８は送信キュー１０６にバッファされた送信データを取り出し、受信処理部１０５から受け取ったＢｉｔｍａｐと共に、フレーム生成・送信処理部１０４へ渡す（図１１のステップ２１１１）。

フレーム生成・送信処理部１０４はＢｉｔｍａｐを用いて、端末Ａ２０１から送信されたＤａｔａ５−Ａ３１９， Ｄａｔａ６−Ａ３２０， Ｄａｔａ７−Ａ３２１， Ｄａｔａ８−Ａ３２２に対するＢｌｏｃｋＡｃｋフレーム３２４を作成する。またフレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９を作成する。Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９を結合してＡｇｇｒｅｇａｔｉｏｎフレーム３２５を作成する。

ここでフレーム生成・送信処理部１０４は、ＮＡＶ時間の終了時刻からＢｌｏｃｋＡｃｋフレーム３２４の送信開始時刻とＢｌｏｃｋＡｃｋフレーム３２４の送信にかかる時間を差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３２４にＮＡＶの値として書き込む。

ＢｌｏｃｋＡｃｋフレーム３２４の送信開始時刻は、Ａｇｇｒｅｇａｔｉｏｎフレーム３１８の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻からＢｌｏｃｋＡｃｋフレーム３２４の送信開始時刻を算出することができる
またフレーム生成・送信処理部１０４は、ＮＡＶ時間の終了時刻からＡｇｇｒｅｇａｔｉｏｎフレーム３２５の送信開始時刻とＡｇｇｒｅｇａｔｉｏｎフレーム３２５の送信にかかる時間を差し引いた値を、Ｄａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９にＮＡＶの値として書き込む。Ａｇｇｒｅｇａｔｉｏｎフレーム３２５の送信開始時刻は、Ａｇｇｒｅｇａｔｉｏｎフレーム３１８の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻からＡｇｇｒｅｇａｔｉｏｎフレーム３２５の送信開始時刻を算出することができる（図１１のステップ２１１２）。

この後に続くステップ２１１３からステップ２１１６までは図４のステップ１１３からステップ１１６までと同様である。

（１−４−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＢｌｏｃｋＡｃｋフレーム送信）
ＨＴＰ Ｂｕｒｓｔフレームを受信した端末Ａ２２０１の受信処理部１０５は、Ｄａｔａ１−Ｂ３１２， Ｄａｔａ２−Ｂ３１３， Ｄａｔａ３−Ｂ３１４， Ｄａｔａ４−Ｂ３１５の受信成否状況から、送達確認を示すＢｉｔｍａｐを生成して送受信状態管理部１０８に渡す。（図１０のステップ２０１９）。

送受信状態管理部１０８は、受信処理部１０５から受け取ったＢｉｔｍａｐをフレーム生成・送信処理部１０４へ渡す（図１０のステップ２０２０）。

フレーム生成・送信処理部１０４は受け取ったＢｉｔｍａｐを用いて、端末Ｂ２０２から送信されたＤａｔａ５−Ｂ３２６， Ｄａｔａ６−Ｂ３２７， Ｄａｔａ７−Ｂ３２８， Ｄａｔａ８−Ｂ３２９に対するＢｌｏｃｋＡｃｋフレーム３３１を作成する。ここでフレーム生成・送信処理部１０４は、ＮＡＶ時間の終了時刻からＢｌｏｃｋＡｃｋフレーム３３１の送信開始時刻とＢｌｏｃｋＡｃｋフレーム３３１の送信にかかる時間を差し引いた値を、ＢｌｏｃｋＡｃｋフレーム３３１にＮＡＶの値として書き込む。ＢｌｏｃｋＡｃｋフレーム３３１の送信開始時刻は、Ａｇｇｒｅｇａｔｉｏｎフレーム３２５の受信完了時刻からＳＩＦＳ時間後と定めてある。そのため、ＲＴＣ１１１から得られる時刻からＢｌｏｃｋＡｃｋフレーム３３１の送信開始時刻を算出することができる（図１０のステップ２０２１）。

この後に続くステップ２０２１は図３のステップ２２と同様である。

（１−４−８．ＴＸＯＰ時間の終了）
ＮＡＶ時間の終了時刻になると帯域予約が解かれて端末Ａ２０１と端末Ｂ２０２との双方向通信が終了する。さらにこの双方向通信を行いたい場合は、帯域予約が解かれてからＡＩＦＳ＋Ｂａｃｋｏｆｆ 時間だけ経過した後、１−１の手順から再度行う。

以上のように、ＲＴＣ１１１から得られる時刻情報を用いてＮＡＶ時間の終了時刻を控えておき、それから自らのフレームの送信開始時刻とそのフレームの送信にかかる時間を差し引いた値を、自らが送信するフレームに書き込むＮＡＶの値とする。その結果、相手から受信したコントロールフレームあるいはＤａｔａフレームにエラーがあったとしても確実にＮＡＶ時間の終了を認識することができる。

（第１の実施の形態の変形例４）
図１２は第１の実施の形態に対して、ＡｃｋＰｏｌｉｃｙを、ＤａｔａフレームのＡｇｇｒｅｇａｔｉｏｎフレームの後ろにＢＡＲ（ＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔ）フレームを接続する、ＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔとした場合のタイミングチャートである。

本変形例では、第１の実施の形態におけるＡｇｇｒｅｇａｔｉｏｎフレーム３３０４の送信の後にＲＩＦＳ時間を挟んでＢＡＲフレーム３３０９を送信する。フレーム生成・送信処理部１０４は、この間にフレーム生成・送信処理部１０４は伝送レートを、Ａｇｇｒｅｇａｔｉｏｎフレーム３３０４を送信したときの第２の伝送レートから、第１の伝送レートに変更する。フレーム生成・送信処理部１０４は、ＢＡＲフレーム３３０９を第１の伝送レートで送信する。

Ａｇｇｒｅｇａｔｉｏｎフレーム３３１５１５８，３３２５を第２の伝送レートで送信した後にも、それぞれＲＩＦＳ時間だけ待ってからＢＡＲフレーム３３１６，３３２３，３３３０を第１の伝送レートで送信する。

なお、本変形例におけるＨＴＰ Ｂｕｒｓｔフレームは、それぞれのＰＨＹフレーム同士の間にＲＩＦＳ時間を挟んだ３つのＰＨＹフレームである。すなわち本変形例において端末Ａ３２０１が送信するＨＴＰ Ｂｕｒｓｔフレーム３３５２は、図２で示したＨＴＰ Ｂｕｒｓｔフレーム３５２の後ろにＲＩＦＳ時間を挟んでＢＡＲフレーム３３２３を持つものである。また、端末Ｂ３２０１が送信するＨＴＰ Ｂｕｒｓｔフレーム３３５１は、図２で示したＨＴＰ Ｂｕｒｓｔフレーム３５１の後ろにＲＩＦＳ時間を挟んでＢＡＲフレーム３３１６を持つものである。

端末Ｂ３２０２は、アソシエーションやマネジメントフレーム交換などによって、ＲＤ方式をするのであれば端末Ａ２０１が最初のＡｇｇｒｅｇａｔｉｏｎフレーム３３０４の次からはＲＩＦＳ時間を挟んだ３つのＰＨＹフレームを送信してくることを知っているものとする。

あるいは端末Ａ３２０１が基地局としての動作を行う場合は、端末Ａ２０１から送信するＢｅａｃｏｎフレームに、ＲＤ方式をするのであれば端末Ａ２０１が最初のＡｇｇｒｅｇａｔｉｏｎフレーム３３０４の次からはＲＩＦＳ時間を挟んだ３つのＰＨＹフレームを送信することを書き込むことにしてもよい。

この場合端末Ａ３２０１の受信処理部１０５は、図３のステップ１１のあとでそれぞれのＰＨＹフレーム同士の間にＲＩＦＳ時間を挟んだ３つのＰＨＹフレームを待ち受けるようにする。また端末Ｂ３２０１の受信処理部１０５は、図４のステップ１０３のあとでそれぞれのＰＨＹフレーム同士の間にＲＩＦＳ時間を挟んだ３つのＰＨＹフレームを待ち受けるようにする。上記のように、ＢＡＲフレームも含むコントロールフレームを低い伝送レートで送信し、Ｄａｔａフレームを高い伝送レートで送信する。低い伝送レートで送信するとノイズ等による伝送エラーの発生を抑えられる。逆に、高い伝送レートで送信すれば高速な送信が可能となる。したがって、ＢＡＲフレームを含むコントロールフレームの受信失敗によるＲｅｓｐｏｎｄｅｒの再送依頼を抑えることと、Ｄａｔａフレームの高速送信との両立が出来る。

（第２の実施の形態）
図１３は本実施の形態のタイミングチャートである。なお、端末Ａ４２０１は図３に示す第１の実施の形態の端末Ａ２０２の動作のフローチャート、端末Ｂ４２０２は図４に示す第１の実施の形態の端末Ｂ２０２の動作のフローチャートに従って動作するものとして説明する。

第１の実施の形態では、端末Ａ２０１が送信するＲＴＳフレーム３０１と端末Ｂ２０２が送信するＣＴＳフレーム３０３とに、それぞれの送信完了から端末Ａ２０１が開始したＲＤ方式のＴＸＯＰ期間が終了するまでの長さをＮＡＶの値として書き込むものとして説明した。

本実施の形態は、送信者のＲＴＳフレームに書き込むＮＡＶの値を、送信者が送信する最初のＡｇｇｒｅｇａｔｉｏｎフレームと、それに対して受信者が返信するＢｌｏｃｋＡｃｋフレームの送信完了までの値とする。また、どちらかがＢｌｏｃｋＡｃｋフレームを送信してこのＢｌｏｃｋＡｃｋフレームのＲＩＦＳ時間だけ後にＤａｔａフレームのＡｇｇｒｅｇａｔｉｏｎフレームを送信して、このＡｇｇｒｅｇａｔｉｏｎフレームに対するＢｌｏｃｋＡｃｋフレームを受信する度にそのＢｌｏｃｋＡｃｋフレームに書き込まれたＮＡＶの値だけＮＡＶ時間４３６１から延長する構成について説明する。

（２−１−１．端末ＡのＲＴＳフレーム送信）
図３のステップ１からステップ２までは同様である。

ステップ３にて決定するＮＡＶ時間４３６１の長さは、第１の実施の形態と違い、ＲＴＳフレーム４３０１の送信開始から、端末Ｂ４２０２から受信するＢｌｏｃｋＡｃｋフレーム４３１０の受信完了までの時間である。

ステップ４からステップ６までは同様である。

（２−１−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
図４のステップ１０１からステップ１０２までは同様である。

（２−１−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
図３のステップ７からステップ１１までは同様である。

（２−１−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図４のステップ１０３からステップ１０４までは同様である。

ステップ１０５にて、フレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム４３１１の送信にかかる時間と、ＳＩＦＳ時間と、次に端末Ａ４２０１が送信するＢｌｏｃｋＡｃｋフレーム４３１７の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム４３１０にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム４３１０の送信完了から、次に端末Ａ４２０１が送信するＢｌｏｃｋＡｃｋフレーム４３１７の送信完了までの長さを示す値となる。

ステップ１０６からステップ１０９までは同様である。

端末Ｃ２０３はＢｌｏｃｋＡｃｋフレーム４３１０を受信完了すると、ＢｌｏｃｋＡｃｋフレーム４３１０に書き込んだＮＡＶの値が表す時間だけ、端末Ａ４２０１と端末Ｂ４２０２とが双方向通信している帯域を用いての通信を行わないようにする。

以下、ＲＴＳフレーム４３０１のＮＡＶの値で規定された帯域予約の終了時刻から、ＢｌｏｃｋＡｃｋフレーム４３１０に書き込んだＮＡＶの値で規定された帯域予約の終了時刻までの長さを、ＮＡＶ延長時間４３６２とする。

（２−１−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図３のステップ１２からステップ１３までは同様である。

ステップ１４にてフレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム３１８の送信にかかる時間と、ＳＩＦＳ時間と、次に端末Ｂ４２０２が送信するＢｌｏｃｋＡｃｋフレーム４３２４の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム４３１７にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム４３１７の送信完了から、次に端末Ｂ４２０２が送信するＢｌｏｃｋＡｃｋフレーム４３２４の送信完了までの長さを示す値となる。

ステップ１５からステップ１８まで同様である。

ここで、端末Ｃ２０３はＢｌｏｃｋＡｃｋフレーム４３１７を受信完了すると、ＢｌｏｃｋＡｃｋフレーム４３１７に書き込んだＮＡＶの値が表す時間だけ、端末Ａ４２０１と端末Ｂ４２０２とが双方向通信している帯域を用いての通信を行わないようにする。

以下、ＢｌｏｃｋＡｃｋフレーム４３１０のＮＡＶの値で規定された帯域予約の終了時刻から、ＢｌｏｃｋＡｃｋフレーム４３１７に書き込んだＮＡＶの値で規定された帯域予約の終了時刻までの長さを、ＮＡＶ延長時間４３６３とする。

（２−１−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ステップ１１０からステップ１１１までは同様である。

ステップ１１２にて、フレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム３２５の送信にかかる時間と、ＳＩＦＳ時間と、次に端末Ａ４３３１が送信するＢｌｏｃｋＡｃｋフレーム４３１７の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム４３２４にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム４３２４の送信完了から、次に端末Ａ４２０１が送信するＢｌｏｃｋＡｃｋフレーム４３３１の送信完了までの長さを示す値となる。

ステップ１１３からステップ１１６までは同様である。

端末Ｃ２０３はＢｌｏｃｋＡｃｋフレーム４３２４を受信完了すると、ＢｌｏｃｋＡｃｋフレーム４３２４に書き込んだＮＡＶの値が表す時間だけ、端末Ａ４２０１と端末Ｂ４２０２とが双方向通信している帯域を用いての通信を行わないようにする。

以下、ＢｌｏｃｋＡｃｋフレーム４３１７のＮＡＶの値で規定された帯域予約の終了時刻から、ＢｌｏｃｋＡｃｋフレーム４３２４に書き込んだＮＡＶの値で規定された帯域予約の終了時刻までの長さを、ＮＡＶ延長時間４３６４とする。

（２−１−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＢｌｏｃｋＡｃｋフレーム送信）
図３のステップ１９からステップ２０までは同様である。

ステップ２１にてフレーム生成・送信処理部１０４は、ＮＡＶの値として０を書き込む。このＮＡＶの値はすなわち、帯域予約を解除、すなわちＮＡＶ時間４３６１の終了を示す値となる。ステップ２２は同様である。

以上のように、本実施の形態では、最初に設定したＮＡＶ時間からさらにＮＡＶ延長時間ずつ延長していくことができる。

なお、本実施の形態でＮＡＶの値は予め定められたＮＡＶ時間の最大限度（ＴＸＯＰ Ｌｉｍｉｔ）を超えないようにすることが必要である。

端末Ａ４０２１のみがＴＸＯＰＬｉｍｉｔを超えないようにＮＡＶの値を監視する場合は例えば以下のようにする。すなわち、端末Ａ４０２１が送信するＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームであるＤａｔａ１−Ａ４３１９のＱｏＳ Ｃｏｎｔｒｏｌフィールドに、ＲＤ方式で通信を行うことを示す値に代えて、ＴＸＯＰ分与限度時間を書き込む。端末Ｂ４２０２はＴＸＯＰ分与限度時間を、ＤａｔａフレームのＡｇｇｒｅｇａｔｉｏｎフレームの送信にかかる時間と、ＳＩＦＳ時間と、ＢｌｏｃｋＡｃｋフレームの送信にかかる時間とを足し合わせた値の上限として、自らが送信するデータの量を決める。もし、ＢｌｏｃｋＡｃｋフレーム４３１７に書き込んだＮＡＶの値とＴＸＯＰ分与限度時間とを足し合わせた値が、ＢｌｏｃｋＡｃｋフレーム４３１７の送信完了からＴＸＯＰ Ｌｉｍｉｔまでの長さよりも長い場合は、ＴＸＯＰ分与限度時間を短くして、端末Ｂ４２０２が送信するＨＴＰ Ｂｕｒｓｔフレーム４３５３の送信にかかる時間とＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレーム４３３１の送信にかかる時間とを足し合わせた値がＴＸＯＰ Ｌｉｍｉｔまでの残り時間よりも短くなるように調整する。あるいは、ＢｌｏｃｋＡｃｋフレーム４３１７に書き込んだＮＡＶの値とＴＸＯＰ分与限度時間とを足し合わせた値が、ＢｌｏｃｋＡｃｋフレーム４３１７の送信完了からＴＸＯＰ Ｌｉｍｉｔまでの長さよりも場合にだけ端末Ａ４０２１は、ＨＴＰ Ｂｕｒｓｔフレーム４３５２を送信するようにしてもよい。

また、端末Ｂ４０２２もＴＸＯＰＬｉｍｉｔを超えないようにＮＡＶの値を監視する場合は例えば以下のようにする。端末Ａ４２０１と端末Ｂ４２０２はそれぞれ、自らが送信するＨＴＰ ＢｕｒｓｔフレームとＳＩＦＳ時間とそのＨＴＰ Ｂｕｒｓｔ フレームに含まれるＤａｔａフレームに対するＢｌｏｃｋＡｃｋフレームの送信にかかる時間とを足し合わせた値がＴＸＯＰ Ｌｉｍｉｔまでの残り時間よりも短くなるように、そのＨＴＰ ＢｕｒｓｔフレームのＡｇｇｒｅｇａｔｉｏｎフレームのデータ量を減らす。

（第３の実施の形態）
図１４は本実施の形態のタイミングチャートである。なお、端末Ａ５２０１は図３に示す第１の実施の形態の端末Ａ２０２の動作のフローチャート、端末Ｂ５２０２は図４に示す第１の実施の形態の端末Ｂ２０２の動作のフローチャートに従って動作するものとして説明する。

本実施の形態は、端末Ａ５２０１のＲＴＳフレーム５３０１に書き込むＮＡＶの値を、端末Ｂ５２０２がＨＴＰ Ｂｕｒｓｔ フレーム５３５２を受信した後に返信するＢｌｏｃｋＡｃｋフレーム５３２４の送信完了までの値とする構成について説明する。

（３−１−１．端末ＡのＲＴＳフレーム送信）
ステップ１からステップ２までは同様である。

ステップ３にて決定するＮＡＶ時間５３６１の長さは、第１の実施の形態と違い、ＳＩＦＳ時間５つ分と、ＣＴＳフレーム５３０３の送信にかかる時間と、端末Ａ５２０１が送信するＡｇｇｒｅｇａｔｉｏｎフレーム５３０４の送信にかかる時間と、端末Ｂ５２０２が送信するＨＴＰ Ｂｕｒｓｔフレーム５３５１の送信にかかる時間と、端末Ａ５２０１が送信するＨＴＰ Ｂｕｒｓｔフレーム５３５２の送信にかかる時間と、端末Ｂ５２０２が送信するＢｌｏｃｋＡｃｋフレーム５３２４の送信にかかる時間と、を足し合わせた値を、ＲＴＳフレーム５３０１にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＲＴＳフレーム５３０１の送信完了から、端末Ｂ５２０２が送信する２つめのＢｌｏｃｋＡｃｋフレーム５３２４の送信完了までの長さを示す値となる。

図３のステップ４からステップ６までは同様である。

（３−１−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
ステップ１０１からステップ１０２までは同様である。

（３−１−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
ステップ７からステップ１１までは同様である。

（３−１−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ステップ１０３からステップ１０９までは同様である。

（３−１−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ステップ１２からステップ１３までは同様である。

ステップ１４にてフレーム生成・送信処理部１０４は、ＲＩＦＳ時間１つ分と、ＳＩＦＳ時間２つ分と、Ａｇｇｒｅｇａｔｉｏｎフレーム３１８の送信にかかる時間と、ＨＴＰ Ｂｕｒｓｔフレーム５３５３の送信にかかる時間と、ＢｌｏｃｋＡｃｋフレーム５３３１の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム５３１７にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム５３１７の送信完了から、次に端末Ａ５２０１自らが送信するＢｌｏｃｋＡｃｋフレーム５３３１の送信完了までの長さを示す値となる。

ステップ１５からステップ１８まで同様である。

端末Ｃ２０３と端末Ｄ２０４はＢｌｏｃｋＡｃｋフレーム５３１７を受信完了すると、ＢｌｏｃｋＡｃｋフレーム５３１７に書き込んだＮＡＶの値が表す時間だけ、端末Ａ５２０１と端末Ｂ５２０２とが双方向通信している帯域を用いての通信を行わないようにする。

以下、ＲＴＳフレーム４３０１のＮＡＶの値で規定された帯域予約の終了時刻から、ＢｌｏｃｋＡｃｋフレーム５３１７に書き込んだＮＡＶの値で規定された帯域予約の終了時刻までの長さを、ＮＡＶ延長時間４３６２とする。

（３−１−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
ステップ１１０からステップ１１１までは同様である。

ステップ１１２にてフレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム３２５の送信にかかる時間と、ＳＩＦＳ時間と、次に端末Ａ５３３１が送信するＢｌｏｃｋＡｃｋフレーム５３２４の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム５３２４にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム５３２４の送信完了から、次に端末Ａ５２０１が送信するＢｌｏｃｋＡｃｋフレーム５３３１の送信完了までの長さを示す値であり、かつＢｌｏｃｋＡｃｋフレーム５３１７に書き込んだＮＡＶの値で規定された帯域予約の終了時刻までの残り時間を示す値である。

ステップ１１３からステップ１１６までは同様である。

（３−１−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＢｌｏｃｋＡｃｋフレーム送信）
ステップ１９からステップ２０までは同様である。

ステップ２１にてフレーム生成・送信処理部１０４は、ＮＡＶの値として０を書き込む。ステップ２２は同様である。

以上のように、ＲＴＳ−ＣＴＳ交換で開始したＮＡＶが終了するまでに、端末Ａ５２０１と端末Ｂ５２０２の両方から、ＮＡＶを延長したことを通知する。したがって、端末Ａ５２０１の送信波しか受信できない端末や、端末Ｂ５２０２の送信波しか受信できない端末などに対しても確実に、ＮＡＶを延長したことを通知することができる。

（第４の実施の形態）
図１５は本実施の形態のタイミングチャートである。

なお、基地局Ａ６２０１は図３に示す第１の実施の形態の端末Ａ２０１の動作のフローチャート、端末Ｂ５２０２は図４に示す第１の実施の形態の端末Ｂ２０２の動作のフローチャートに従って動作するものとして説明する。

本実施の形態は、この双方向通信は図１６のように、端末Ａ６２０１と端末Ｂ６２０２が属している無線通信システムに端末Ａ６２０１及び端末Ｂ６２０２以外にも、送信データの宛先とならない端末Ｃ２０３、端末Ｄ２０４、端末Ｅ２０５も存在するものとする。

端末Ａ６２０１の送信波は、端末Ａ２０１と端末Ｂ２０２との双方向通信が始まるときに、端末Ｃ２０３、端末Ｄ２０４、端末Ｅ２０５は受信することができるものとする。すなわち、端末Ａ６２０１の送信波を受信できない、端末Ａ６２０１に対する隠れ端末はないものとする。

（４−１−１．端末ＡのＲＴＳフレーム送信）
ステップ１からステップ２までは同様である。

ステップ３にて決定するＮＡＶ時間６３６１の長さは、第２の実施の形態と同様である。

ステップ４からステップ６までは同様である。

（４−１−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
図４のステップ１０１からステップ１０２までは同様である。

（４−１−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
図３のステップ７からステップ１１までは同様である。

（４−１−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図４のステップ１０３からステップ１０９までは同様である。

（４−１−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図３のステップ１２からステップ１３までは同様である。

ステップ１４にてフレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、２つのＳＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム６３１８の送信にかかる時間と、Ｄａｔａ５−Ａ６３１９に書き込むＴＸＯＰ分与時間と、ＢｌｏｃｋＡｃｋフレーム６３３１の送信にかかる時間とを足し合わせたものをＢｌｏｃｋＡｃｋフレーム６３１７にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム６３１７の送信完了から、次に端末Ａ６２０１自らが送信するＢｌｏｃｋＡｃｋフレーム６３３１の送信完了までの長さを示す値となる。

図３のステップ１５からステップ１８までは同様である。

端末Ｃ２０３と端末Ｄ２０４はＢｌｏｃｋＡｃｋフレーム６３１７を受信完了すると、ＢｌｏｃｋＡｃｋフレーム６３１７に書き込んだＮＡＶの値が表す時間だけ、端末Ａ６２０１と端末Ｂ６２０２とが双方向通信している帯域を用いての通信を行わないようにする。

以下、ＲＴＳフレーム４３０１のＮＡＶの値で規定された帯域予約の終了時刻から、ＢｌｏｃｋＡｃｋフレーム６３１７に書き込んだＮＡＶの値で規定された帯域予約の終了時刻までの長さを、ＮＡＶ延長時間６３６２とする。

（４−１−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図４のステップ１１０からステップ１１６までは同様である。

（４−１−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＢｌｏｃｋＡｃｋフレーム送信）
図３のステップ１９からステップ２２までは同様である。

以上のように、ＲＴＳ−ＣＴＳ交換で開始したＮＡＶが終了するまでに、基地局Ａ６２０１がＮＡＶを延長するＢｌｏｃｋＡｃｋフレーム６３１７を送信する。

端末Ｃ２０３、端末Ｄ２０４、端末Ｅ２０５の全てが基地局Ａ６２０１の送信波を受信でき、基地局Ａ６２０１がＢｌｏｃｋＡｃｋフレーム６３１７を送信完了してＮＡＶ延長時間を全端末に通知するまで、その前に規定したＮＡＶ時間が継続するので、基地局Ａ６２０１を含むシステムにおいてもＮＡＶ時間をを途切れさせることなく延長していくことができる。

なお、ＮＡＶを延長するときに基地局Ａ６２０１は、ＮＡＶ延長時間の終了時刻がＴＸＯＰ Ｌｉｍｉｔを超えないように調整する。

本実施の形態では基地局Ａ６２０１を基地局と称した。しかし、隠れ端末がないことを前提とすれば、基地局Ａ６２０１は端末であってもよい。

（第５の実施の形態）
図１７は本実施の形態のタイミングチャート、図１８は端末Ａ７２０１の動作に係るフローチャート、図１９は端末Ｂ７２０２の動作に係るフローチャートである。

端末Ａ７２０１は図５の端末Ａ２０１の位置に、端末Ｂ７２０２は図５の端末Ｂ２０２の位置に、それぞれあるものとして説明する。

本実施の形態では、第１の実施の形態について、端末Ａ７２０１が与えたＴＸＯＰ分与時間を端末Ｂ７２０２が使いきらない場合はその余った時間だけ繰り上げて双方向通信を行うよう変更を加えた構成について説明する。

（５−１−１．端末ＡのＲＴＳフレーム送信）
図１８のステップ７００１からステップ７００６までは図３のステップ１からステップ６までと同様である。

（５−１−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
図１９のステップ７１０１からステップ７１０２までは図４のステップ１０１からステップ１０２までと同様である。

（５−１−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
図１８のステップ７００７からステップ７０１１までは図３のステップ７からステップ１１までと同様である。

（５−１−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１９のステップ７１０３からステップ７１０４までは図４のステップ１０３からステップ１０４までと同様である。

ステップ７１０５にて、フレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ１−Ｂ７３１２， Ｄａｔａ２−Ｂ７３１３， Ｄａｔａ３−Ｂ７３１４を作成する。

ここで注意すべきは、ＴＸＯＰ分与時間が、ＲＩＦＳ時間とＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレームの送信にかかる時間に加えてＤａｔａフレームを４つ送信することができる値であるのに対して、端末Ｂ７２０２はＤａｔａ１−Ｂ７３１２と Ｄａｔａ２−Ｂ７３１３と Ｄａｔａ３−Ｂ７３１４といった３つのＤａｔａフレームしか作成しない点である。これは例えば、端末Ｂ７２０２が４つのＤａｔａフレームを作成するほどの量の端末Ａ７２０１宛送信データを送信キュー１０６に有しない場合などである。

つづいてフレーム生成・送信処理部１０４はＤａｔａ１−Ｂ７３１２， Ｄａｔａ２−Ｂ７３１３， Ｄａｔａ３−Ｂ７３１４，を結合してＡｇｇｒｅｇａｔｉｏｎフレーム７３１１を作成する。

ここでフレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、３つのＤａｔａフレームからなるＡｇｇｒｅｇａｔｉｏｎフレーム３１１の送信にかかる時間（すなわちＤａｔａフレームを３つ送るのにかかる時間）と、ＳＩＦＳ時間と、次に端末Ａ７２０１が送信するＢｌｏｃｋＡｃｋフレーム７３１７の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム７３１０にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム７３１０の送信完了から、次に端末Ａ７２０１が送信するＢｌｏｃｋＡｃｋフレーム７３１７の送信完了までの長さを示す値となる。

図１９のステップ７１０６からステップ７１０９までは図４のステップ１０６からステップ１０９までと同様である。

ここで、端末Ｃ２０４はＢｌｏｃｋＡｃｋフレーム７３１０を受信しても、ＢｌｏｃｋＡｃｋフレーム７３１０に書き込まれたＮＡＶの値に拘わらず、ＲＴＳ−ＣＴＳフレーム交換で規定したＮＡＶ時間７３６１の終了あるいは後述するＣｆ−ｅｎｄフレーム７３３２を受信するまではその送信帯域を用いての通信を行わない。

（５−１−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１８のステップ７０１２からステップ７０１８は図３のステップ１２からステップ１８までと同様である。

ここで、端末Ｂ７２０２が送信したＢｌｏｃｋＡｃｋフレーム７３１０に書き込まれたＮＡＶの値が、ここではＴＸＯＰ時間と等価であるＮＡＶ時間７３６１の終了時刻までの残り時間よりも短い場合、端末Ａ７２０１は、Ｄａｔａ１−Ａ４３０５に書き込んだＴＸＯＰ分与時間がその短い分だけ余ったことを知る。

（５−１−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１９のステップ７１１０からステップ７１１０までは図４のステップ１１０からステップ１１０までと同様である。

ステップ７１１１にて、送受信状態管理部１０８はＢｌｏｃｋＡｃｋフレーム７３１７のＢｉｔｍａｐから再送すべきＤａｔａフレームがあるか否かを判断して再送すべきＤａｔａフレームを用意した後に、送信キュー１０６から新たな送信データを取り出す処理を行う。ここで端末Ａ７２０１宛の送信データが送信キュー１０６にないので、送受信状態管理部１０８はフレーム生成・送信処理部１０４に、送達確認を通知するＢｉｔｍａｐを渡すと共に、端末Ａ７２０１宛の送信データがないことを通知する。

ステップ７１１２にて、フレーム生成・送信処理部１０４はＢｉｔｍａｐを用いて、端末Ａ７２０１から送信されたＤａｔａ５−Ａ７３１９， Ｄａｔａ７−Ａ７３２０， Ｄａｔａ７−Ａ７３２１， Ｄａｔａ８−Ａ７３２２に対するＢｌｏｃｋＡｃｋフレーム７３２４を作成する。またフレーム生成・送信処理部１０４は、端末Ａ７２０１宛の送信データがないこと通知されているので、端末Ａ７２０１宛の送信データがないことを端末Ａ７２０１に通知するためのＱｏＳ Ｎｕｌｌフレーム７３２６を作成する。フレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、ＱｏＳ Ｎｕｌｌフレーム７３２６の送信にかかる時間と、ＳＩＦＳ時間と、次に端末Ａ７３３１が送信するＢｌｏｃｋＡｃｋフレーム７３１７の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム７３２４にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム７３２４の送信完了から、次に端末Ａ７２０１が送信するＢｌｏｃｋＡｃｋフレーム７３３１の送信完了までの長さを示す値となる。

フレーム生成・送信処理部１０４は、 ＢｌｏｃｋＡｃｋフレーム７３２４に書き込んだＮＡＶの値からＲＩＦＳ時間とＱｏＳ Ｎｕｌｌフレーム７３２６を送信にかかる時間とを差し引いた値を、ＱｏＳ Ｎｕｌｌフレーム７３２６にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、ＱｏＳ Ｎｕｌｌフレーム７３２６の送信完了から次に端末Ａ７２０１が送信するＢｌｏｃｋＡｃｋフレーム７３３１の送信完了までの長さを示す値となる。

図１９のステップ７１１３からステップ７１１６までは、図４のステップ１１３からステップ１１６までにおける送信ＡｇｇｒｅｇａｔｉｏｎフレームをＱｏＳ Ｎｕｌｌフレームに読み替えるだけである。

（５−１−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＢｌｏｃｋＡｃｋフレーム送信）
ＲＩＦＳ時間を挟んだ２つのＰＨＹフレーム、すなわちＨＴＰ Ｂｕｒｓｔフレーム７３５３を受信した端末Ａ７２０１の受信処理部１０５は、ＱｏＳ Ｎｕｌｌフレーム７３２６を正常に受信するとＡｃｋフレーム７３３１の送信要求を送受信状態管理部１０８に渡す（図１８のステップ７０１９）。

送受信状態管理部１０８は、Ａｃｋフレーム７３３１の送信要求をフレーム生成・送信処理部１０４へ渡す（図１８のステップ７０２０）。

フレーム生成・送信処理部１０４は受け取った送信要求に従って、端末Ｂ７２０２から送信されたＱｏＳ Ｎｕｌｌフレーム７３２６に対するＡｃｋフレーム７３３１を作成する。またフレーム生成・送信処理部１０４は、ＮＡＶ時間を強制終了させるＣｆ−ｅｎｄフレーム７３３２を作成する（図１８のステップ７０２１）。

フレーム生成・送信処理部１０４は、端末Ｂ７２０２から送信されたＨＴＰ Ｂｕｒｓｔフレーム７３５３を受信処理部１０５が受信完了してからＳＩＦＳ時間後に、作成したＨＴＰ Ｂｕｒｓｔフレーム７３５４の送信を開始する。

ＨＴＰ Ｂｕｒｓｔフレーム７３５４の送信について詳述する。まずＡｃｋフレーム７３３１の送信を開始する（図１８のステップ２２）。Ａｃｋフレーム７３３１の送信の伝送レートを第１の伝送レートとする。

フレーム生成・送信処理部１０４は、Ａｃｋフレーム７３３１の送信を完了した後にＲＩＦＳ時間だけ経つと、、Ａｃｋフレーム７３３１の伝送レートと同じく第１の伝送レートで、Ｃｆ−ｅｎｄフレーム７３３２を送信する（図１８のステップ２３）。

端末Ｃ２０３はＣｆ−ｅｎｄフレーム７３３２を受信することで、端末Ａ７２０１の帯域予約が解除されてその帯域を用いてもよいことを知る。

さらにこの双方向通信もしくは他の端末との通信を行いたい場合は、ＡＩＦＳ＋Ｂａｃｋｏｆｆ 時間だけ経過した後、１−１−１の手順から再度行う。

以上のように、本実施の形態では、端末Ａ７２０１が与えたＴＸＯＰ分与時間を端末Ｂ７２０２が使いきらない場合に、その余った時間だけ繰り上げて双方向通信を行うことができる。また、端末Ｂ７２０２に端末Ａ７２０１宛の送信データがないことを通知することができる。

その結果、端末Ｂ７２０２が余らせた時間を送受信が行われない無駄時間にしてしまうことなく、双方向通信を早く終了することができる
なお、本実施の形態ではステップ１１６でＱｏＳ Ｎｕｌｌフレーム７３２６を送信するものとして説明した。しかし、何れかのフレームで、端末Ｂ７２０２の送信キュー１０６に端末Ａ７２０１宛送信データがないことを端末Ａ７２０１に通知することができる場合、ＱｏＳ Ｎｕｌｌフレーム７３２６を他のフレームに置き換えることは可能である。これは例えば、ＢｌｏｃｋＡｃｋフレーム７３２４に書き込むＮＡＶの値が０である場合に、端末Ｂ７２０２は端末Ａ７２０１宛送信データを持たない、と端末Ａ７２０１が見なすものと取り決めてくことで実現できる。

また、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｅの規格にしか対応していない端末に対してもＣｆ−ｅｎｄフレーム６２０の受信を保証するために、Ａｃｋフレーム７３３１とＣｆ−ｅｎｄフレーム７３３２を、ＲＩＦＳ時間だけ挟んでＨＴＰ Ｂｕｒｓｔフレームとして送信するのではなく、ＳＩＦＳ時間を挟んで送信する構成としてもよい。

また、Ａｃｋフレーム７３３１を送信せずに、端末Ｂ７２０２から送信されたＨＴＰ Ｂｕｒｓｔフレーム７３５３を受信処理部１０５が受信完了してからＳＩＦＳ時間後にＣｆ−ｅｎｄフレーム７３３２を送信する構成としてもよい。この場合端末Ｂ７２０２は、Ｃｆ−ｅｎｄフレーム７３３２の受信を以って、ＨＴＰ Ｂｕｒｓｔフレームが送達し、双方向通信が終了するものとみなすものとする。この場合は、ＱｏＳ Ｎｕｌｌフレーム７３２６に対するＡｃｋフレーム７３３１は不要であり、ＨＴＰ Ｂｕｒｓｔフレーム７３５４の代わりにＣｆ−ｅｎｄフレーム７３３２を単独で送信する。

また、本実施の形態では端末Ａ７２０１がＡｃｋフレーム７３３１の送信を完了した後のＲＩＦＳ時間中に伝送レートを第１の伝送レートから第２の伝送レートに変更するものとして説明したが、Ｃｆ−ｅｎｄフレーム７３３２を第１の伝送レートで送信するよう構成してもよい。

（第６の実施の形態）
図２０は本実施の形態のタイミングチャート、図２１は端末Ａ８２０１の動作に係るフローチャートである。

なお、端末Ｂ８２０２は図１９に示す第５の実施の形態の端末Ｂ８２０２の動作のフローチャートに従って動作するものとして説明する。

また、端末Ａ８２０１は図５の端末Ａ２０１の位置に、端末Ｂ８２０２は図５の端末Ｂ２０２の位置に、それぞれあるものとして説明する。

本実施の形態では、第２の実施の形態について、端末Ａ８２０１が与えたＴＸＯＰ分与時間を端末Ｂ８２０２が使いきらない場合はその余った時間だけ繰り上げて双方向通信を行うよう変更を加えた構成について説明する。

（６−１−１．端末ＡのＲＴＳフレーム送信）
図２１のステップ８００１からステップ８００２までは図１８のステップ７００１からステップ７００２までと同様である。

ステップ８００３にて決定するＮＡＶ時間８３６１の長さは、第２の実施の形態同様である。

図２１のステップ８００４からステップ８００６までは図１８のステップ７００４からステップ７００６までと同様である。

（６−１−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
図１９のステップ７１０１からステップ１０２までは同様である。

（６−１−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
図２１のステップ８００７からステップ８０１１までは図１８のステップ７００８からステップ７０１１までと同様である。

（６−１−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１９のステップ７１０３からステップ７１０４までは同様である。

ステップ７１０５にて、フレーム生成・送信処理部１０４は、送信データからＤａｔａフレームとしてＤａｔａ１−Ｂ８３１２， Ｄａｔａ２−Ｂ８３１３， Ｄａｔａ３−Ｂ８３１４を作成する。

ここで注意すべきは、ＴＸＯＰ分与時間が、ＲＩＦＳ時間とＳＩＦＳ時間とＢｌｏｃｋＡｃｋフレームの送信にかかる時間に加えてＤａｔａフレームを４つ送信することができる値であるのに対して、端末Ｂ８２０２はＤａｔａ１−Ｂ８３１２と Ｄａｔａ２−Ｂ８３１３と Ｄａｔａ３−Ｂ８３１４といった３つのＤａｔａフレームしか作成しない点である。これは例えば、端末Ｂ８２０２が４つのＤａｔａフレームを作成するほどの量の端末Ａ８２０１宛送信データを送信キュー１０６に有しない場合などである。

つづいてフレーム生成・送信処理部１０４はＤａｔａ１−Ｂ８３１２， Ｄａｔａ２−Ｂ８３１３， Ｄａｔａ３−Ｂ８３１４，を結合してＡｇｇｒｅｇａｔｉｏｎフレーム８３１１を作成する。

ここでフレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム８３１１の送信にかかる時間（すなわちＤａｔａフレームを３つ送るのにかかる時間）と、ＳＩＦＳ時間と、次に端末Ａ８２０１が送信するＢｌｏｃｋＡｃｋフレーム８３１７の送信にかかる時間と、を足し合わせた値を、ＢｌｏｃｋＡｃｋフレーム８３１０にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＢｌｏｃｋＡｃｋフレーム８３１０の送信完了から、次に端末Ａ８２０１が送信するＢｌｏｃｋＡｃｋフレーム８３１７の送信完了までの長さを示す値となる。

フレーム生成・送信処理部１０４は、 ＢｌｏｃｋＡｃｋフレーム８３１０に書き込んだＮＡＶの値からＲＩＦＳ時間とＡｇｇｒｅｇａｔｉｏｎフレーム７３１１を送信にかかる時間とを差し引いた値を、Ｄａｔａ１−Ｂ８３１２， Ｄａｔａ２−Ｂ８３１３， Ｄａｔａ３−Ｂ８３１４， Ｄａｔａ４−Ｂ８３１５にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、Ａｇｇｒｅｇａｔｉｏｎフレーム７３１１の送信完了から次に端末Ａ８２０１が送信するＢｌｏｃｋＡｃｋフレーム８３１７の送信完了までの長さを示す値となる。

図１９のステップ７１０６からステップ７１０９までは同様である。

ここで、端末Ｃ２０４はＢｌｏｃｋＡｃｋフレーム８３１０を受信すると、ＢｌｏｃｋＡｃｋフレーム８３１０の受信完了からＢｌｏｃｋＡｃｋフレーム８３１０に書き込まれたＮＡＶの値で表される時間端末Ａ８２０１と端末Ｂ８２０２とが双方向通信している帯域を用いての通信を行わない。すなわち、端末Ａ８２０１の端末Ｃ２０４に対する帯域予約が延長される。

（６−１−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図２１のステップ８０１２からステップ８０１８は図１８のステップ７０１２からステップ７０１８までと同様である。

ここで、端末Ｂ８２０２が送信したＢｌｏｃｋＡｃｋフレーム８３１０に書き込まれたＮＡＶの値がＤａｔａ１−Ａ８３０５に書き込んだＴＸＯＰ分与時間の終了までの残り時間よりも短い場合、端末Ａ８２０１は、ＢｌｏｃｋＡｃｋフレーム４３０５に書き込んだＴＸＯＰ分与時間がその短い分だけ余ったことを知る。

（６−１−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１９のステップ７１１０からステップ７１１１までは同様である。

ステップ７１１２にて、フレーム生成・送信処理部１０４はＢｉｔｍａｐを用いて、端末Ａ８２０１から送信されたＤａｔａ５−Ａ８３１９， Ｄａｔａ８−Ａ８３２０， Ｄａｔａ８−Ａ８３２１， Ｄａｔａ８−Ａ８３２２に対するＡｃｋフレーム８３２４を作成する。またフレーム生成・送信処理部１０４は、ＱｏＳ Ｎｕｌｌフレーム８３２６を作成する。

フレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、ＱｏＳ Ｎｕｌｌフレーム８３２６の送信にかかる時間と、ＳＩＦＳ時間と、次に端末Ａ８３３１が送信するＡｃｋフレーム８３１７の送信にかかる時間と、を足し合わせた値を、Ａｃｋフレーム８３２４にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、このＡｃｋフレーム８３２４の送信完了から、次に端末Ａ８２０１が送信するＡｃｋフレーム８３３１の送信完了までの長さを示す値となる。

フレーム生成・送信処理部１０４は、 Ａｃｋフレーム８３２４に書き込んだＮＡＶの値からＲＩＦＳ時間とＱｏＳ Ｎｕｌｌフレーム８３２６を送信にかかる時間とを差し引いた値を、ＱｏＳ Ｎｕｌｌフレーム８３２６にＮＡＶの値として書き込む。このＮＡＶの値はすなわち、ＱｏＳ Ｎｕｌｌフレーム８３２６の送信完了から次に端末Ａ８２０１が送信するＡｃｋフレーム８３３１の送信完了までの長さを示す値となる。

図１９のステップ７１１３からステップ７１１５までは同様である。

また、ステップ７１１６についても送信するフレームをＱｏＳ Ｎｕｌｌフレーム８３２６に読み替えるだけなので説明を省略する。

（６−１−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＡｃｋフレーム送信）
図２１のステップ８０１９からステップ８０２０までは図１８のステップ７０１９からステップ７０２０までと同様なので説明を省略する。

フレーム生成・送信処理部１０４は受け取ったＢｉｔｍａｐを用いて、端末Ｂ８２０２から送信されたＱｏＳ Ｎｕｌｌフレーム８３２６に対するＡｃｋフレーム８３３１を作成する。（図２０のステップ８０２１）。

フレーム生成・送信処理部１０４は、端末Ｂ８２０２から送信されたＨＴＰ Ｂｕｒｓｔフレーム８３５３を受信処理部１０５が受信完了してからＳＩＦＳ時間後に、作成したＡｃｋフレーム８３３１を送信する（図２０のステップ２２）。

本実施の形態ではＡｃｋフレーム８３３１の送信完了の時点でＮＡＶ延長時間８３６４が終了するので、Ｃｆ−ｅｎｄフレーム８３３２は送信する必要がない。

さらにこの双方向通信を行いたい場合は、ＡＩＦＳ＋Ｂａｃｋｏｆｆ 時間だけ経過した後、１−１−１の手順から再度行う。

以上のように、本実施の形態では、第２の実施の形態においても、端末Ａ８２０１が与えたＴＸＯＰ分与時間を端末Ｂ８２０２が使いきらない場合に、その余った時間だけ繰り上げて双方向通信を行うことができることを示した。

その結果、端末Ｂ８２０２が余らせた時間だけ双方向通信を早く終了することができる
（第７の実施の形態）
図２２は本実施の形態のタイミングチャートである。

なお、基地局Ａ９２０１は図１８に示す第５の実施の形態の端末Ａ７２０１の動作のフローチャート、端末Ｂ９２０２は図１９に示す第５の実施の形態の端末Ｂ７２０２の動作のフローチャートに従って動作するものとして説明する。また、基地局Ａ９２０１は図５の端末Ａ２０１の位置に、端末Ｂ９２０２は図５の端末Ｂ２０２の位置に、それぞれあるものとして説明する。

本実施の形態では、第４の実施の形態について、基地局Ａ９２０１が与えたＴＸＯＰ分与時間を端末Ｂ９２０２が使いきらない場合はその余った時間だけ繰り上げて双方向通信を行うよう変更を加えた構成について説明する。

（７−１−１．端末ＡのＲＴＳフレーム送信）
図１８のステップ７００１からステップ７００２までは同様である。

ステップ３にて決定するＮＡＶ時間９３６１の長さは、第４の実施の形態と同様である。

ステップ７００４からステップ７００６までは同様である。

（７−１−２．端末ＢのＲＴＳフレーム受信とＣＴＳフレーム送信）
図１９のステップ７１０１からステップ１０２までは同様である。

（７−１−３．端末ＡのＣＴＳフレーム受信とＡｇｇｒｅｇａｔｉｏｎフレーム送信）
図１８のステップ７００７からステップ７０１１までは同様である。

（７−１−４．端末ＢのＡｇｇｒｅｇａｔｉｏｎフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１９のステップ７１０３からステップ７１０９までは同様である。

（７−１−５．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１８のステップ７０１２からステップ７０１３は同様である。

ステップ１４にてフレーム生成・送信処理部１０４は、ＲＩＦＳ時間と、２つのＳＩＦＳ時間と、Ａｇｇｒｅｇａｔｉｏｎフレーム９３１８の送信にかかる時間と、Ｄａｔａ５−Ａ９３１９に書き込むＴＸＯＰ分与時間と、ＢｌｏｃｋＡｃｋフレーム９３３１の送信にかかる時間とを足し合わせたものをＢｌｏｃｋＡｃｋフレーム９３１７にＮＡＶの値として書き込み、帯域予約を延長する。

図１８のステップ７０１５からステップ７０１８は同様である。

（７−１−６．端末ＢのＨＴＰ Ｂｕｒｓｔフレーム受信とＨＴＰ Ｂｕｒｓｔフレーム送信）
図１９のステップ７１１０からからステップ７１１５までは同様である。

また、ステップ７１１６についても第５の実施の形態や第６の実施の形態と同様に、送信するフレームをＱｏＳ Ｎｕｌｌフレーム９３２６に読み替えるだけなので説明を省略する。

（７−１−７．端末ＡのＨＴＰ Ｂｕｒｓｔフレーム受信とＡｃｋフレーム送信）
図１８のステップ７０１９からステップ７０２４までと同様である。

なお、本実施の形態ではＡｃｋフレーム９３３１の送信完了の時点で、ＢｌｏｃｋＡｃｋフレーム９３１７で規定したＮＡＶ延長時間９３６４が継続しているので、Ｃｆ−ｅｎｄフレーム８３３２を送信する必要がある。

以上のように、本実施の形態では、第４の実施の形態においても、基地局Ａ９２０１が与えたＴＸＯＰ分与時間を端末Ｂ９２０２が使いきらない場合に、その余った時間だけ繰り上げて双方向通信を行うことができることを示した。

その結果、端末Ｂ９２０２が余らせた時間だけ双方向通信を早く終了することができる。

（第８の実施の形態）
図１７に示す第５の実施の形態のタイミングチャートを参照しながら以下説明する。ただし、ＢｌｏｃｋＡｃｋフレーム７３１７をＣＴＳ−Ｓｅｌｆフレーム７３１７と読み替えるものとする。

端末Ａ７２０１が、端末Ｂ７２０２が送信するＨＴＰ Ｂｕｒｓｔフレームを正常に受信できないときには以下の４つうちいずれかの状態になる。本実施の形態では、第５の実施の形態について、それらの状態に陥ったとき毎に、リカバリについて説明する。

（１）ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームが結合されたＡｇｇｒｅｇａｔｉｏｎフレームの送信完了からＳＩＦＳ＋１Ｓｌｏｔ時間経過しても、キャリアセンス部１０９がキャリアセンス処理において受信電力のＢｕｓｙを検出しない場合
Ａｇｇｒｅｇａｔｉｏｎフレームの送信完了からＳＩＦＳ＋１Ｓｌｏｔ時間経つまでに受信電力のＢｕｓｙが検出されるか監視した後、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームが結合されたＡｇｇｒｅｇａｔｉｏｎフレームが再送される。もしくは、ＢｌｏｃｋＡｃｋフレームを送信することにしてもよい。これらはＩＥＥＥ８０２．１１ｅに規定された方法と同様である。

（２）ＢｌｏｃｋＡｃｋフレームの正常に受信してからＲＩＦＳ時間後に、キャリアセンス部１０９がキャリアセンス処理において受信電力のＢｕｓｙを検出しない場合
端末Ａ７２０１が最初のＡｇｇｒｅｇａｔｉｏｎフレーム７３０４を送信完了した後は、ＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを互いに送信しあうことがマネジメントフレーム交換などによって予めわかっている。

そのため、ＢｌｏｃｋＡｃｋフレーム７３１４すなわち１つめのＰＨＹフレームの受信を完了してからＲＩＦＳ時間後に端末Ａ７２０１のキャリアセンス部１０９がキャリアセンス処理においてＩｄｌｅである場合であっても、端末Ｂ７２０２は何らかのフレーム（ここではＡｇｇｒｅｇａｔｉｏｎフレーム７３１１）を２つめのＰＨＹフレームとして送信しているはずである。

ここで従来のようにカバリ方法に従えば、端末Ａ７２０１が１つめのＰＨＹフレームであるＢｌｏｃｋＡｃｋフレーム７３１０を受信した後ＰＩＦＳ時間（ＳＩＦＳ＋１Ｓｌｏｔ）が経過してから再送すべきフレームを送信することになる。

しかしそれでは、ＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを待ち受けている端末Ｂ７２０２は、端末Ａ７２０１が再送したフレームを受信することができない。また、端末Ａ７２０１が再送したフレームが、端末Ｂ７２０２が送信している何らかのフレームと衝突してしまう。

これを避けるには、端末Ａ７２０１が端末Ｂ７２０２に与えたＴＸＯＰ分与時間だけ送信を控える手法も考えられる。しかし本実施の形態ではこの場合はにおいて、端末Ａ７２０１がＢｌｏｃｋＡｃｋフレーム７３２４を受信した後、端末Ｂ７２０２がＢｌｏｃｋＡｃｋフレーム７３１０に書き込んだＮＡＶの値から、端末Ｂ７２０２が送信するＡｇｇｒｅｇａｔｉｏｎフレームの長さと、ＳＩＦＳ時間と、ＢｌｏｃｋＡｃｋフレームの送信にかかる時間がわかる。そのおかげで、ＢｌｏｃｋＡｃｋフレーム７３１０に書き込んだＮＡＶの値が表す時間が経過してから、ＣＴＳ−Ｓｅｌｆフレーム７３１７を送信する。その後にＲＩＦＳ時間だけ経過してからＤａｔａフレームを送信する。つまり、ＣＴＳ−Ｓｅｌｆフレーム７３１７を、ＤａｔａフレームとのＨＴＰ Ｂｕｒｓｔ フレーム７３５２として送信する。

（３）ＢｌｏｃｋＡｃｋフレームの正常に受信してからＲＩＦＳ時間後に、キャリアセンス部１０９がキャリアセンス処理において受信電力のＢｕｓｙを検出する場合
ＢｌｏｃｋＡｃｋフレーム７３１４すなわち１つめのＰＨＹフレームの受信を完了してからＲＩＦＳ時間後に端末Ａ７２０１のキャリアセンス部１０９がキャリアセンス処理においてＢｕｓｙである場合は、その後にＢｕｓｙからＩｄｌｅとなったときに、端末Ｂ７２０２が２つめのＰＨＹフレームとして送信した何らかのフレーム（ここではＡｇｇｒｅｇａｔｉｏｎフレーム７３１１）の送信が完了したものと考えられる。

そこでこの場合では、ＢｌｏｃｋＡｃｋフレーム７３１４すなわち１つめのＰＨＹフレームの受信を完了してからＲＩＦＳ時間後に端末Ａ７２０１のキャリアセンス部１０９がＢｕｓｙであった後に、ＩｄｌｅとなってからＰＩＦＳ時間経過した時点でＣＴＳ−Ｓｅｌｆフレーム７３１７を送信を開始し、完了した後にＲＩＦＳ時間だけ経過してからＤａｔａフレームもしくはＡｇｇｒｅｇａｔｉｏｎフレームを送信する。つまり、ＣＴＳ−Ｓｅｌｆフレーム７３１７を、ＤａｔａフレームとのＨＴＰ Ｂｕｒｓｔ フレーム７３５２として送信する。

（４）ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームが結合されたＡｇｇｒｅｇａｔｉｏｎフレームの送信完了からＳＩＦＳ後に、キャリアセンス部１０９がキャリアセンス処理において受信電力のＢｕｓｙを検出するが、受信したフレームが正常に読み取れない場合
この場合、これはＨＴＰ Ｂｕｒｓｔフレーム７３５１に対応して、Ａｇｇｒｅｇａｔｉｏｎフレーム７３０４の送信完了後にＳＩＦＳ時間が経過してから、ＢｌｏｃｋＡｃｋフレーム７３１４の送信に対応する時間だけＢｕｓｙとなり、ＲＩＦＳ時間だけＩｄｌｅとなり、さらにまたＢｕｓｙとなる。その次にＩｄｌｅになる時点がＨＴＰ Ｂｕｒｓｔフレーム７３５１の送信完了時点と対応すると考えられるので、その時点からＰＩＦＳ時間経過してからＣＴＳ−Ｓｅｌｆフレーム７３１７を送信を開始し、完了した後にＲＩＦＳ時間だけ経過してからＤａｔａフレームを送信する。つまり、ＣＴＳ−Ｓｅｌｆフレーム７３１７を、ＤａｔａフレームとのＨＴＰ Ｂｕｒｓｔ フレーム７３５２として送信する。

このようなリカバリを行うことによって、ＲＤ方式において、端末Ａ７２０１が送信するリカバリ動作用フレームと、端末Ｂ７２０２が送信するＨＴＰ Ｂｕｒｓｔフレームとの衝突を避けることができる。

また、端末Ａ７２０１が与えたＴＸＯＰ分与時間を端末Ｂ７２０２が使いきらない場合に、端末Ａ７２０１がＢｌｏｃｋＡｃｋフレーム７３１０を受信することができたならばその余った時間だけ繰り上げて双方向通信を行うことができる。

また、本実施の形態のようなリカバリを第５の実施の形態、第６の実施の形態、第７の実施の形態に対して組み合わせることによって、ＲＴＳ−ＣＴＳフレーム交換やＢｌｏｃｋＡｃｋフレームで張ったＮＡＶが端末Ｂ７２０２のＢｌｏｃｋＡｃｋフレーム７３１４で張るＮＡＶと同時に終了する場合でも、ＮＡＶの終了時刻前もしくは直後にＣＴＳ−Ｓｅｌｆフレーム７３１７を送信するので、ＮＡＶが終了してしまっていることがなく、端末Ａ７２０１と端末Ｂ７２０２以外の端末との送信フレームの衝突を避けることができる。

（第９の実施の形態）
図１４に示す第３の実施の形態のタイミングチャートを参照しながら以下説明する。ただし、ＢｌｏｃｋＡｃｋフレーム５３１７をＣＴＳ−Ｓｅｌｆフレーム５３１７と読み替えるものとする。

本実施の形態では、第３の実施の形態について、第８の実施の形態で述べた（２）の場合それぞれに対するリカバリを説明する。

なお、（１）（３）（４）の場合は第８の実施の形態と同様である。

（２）ＢｌｏｃｋＡｃｋフレームの正常に受信してからＲＩＦＳ時間後に、キャリアセンス部１０９がキャリアセンス処理において受信電力のＢｕｓｙを検出しない場合
端末Ａ５２０１が最初のＡｇｇｒｅｇａｔｉｏｎフレーム３０４を送信完了した後は、ＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを互いに送信しあうことがマネジメントフレーム交換などによって予めわかっている。

そのため、ＢｌｏｃｋＡｃｋフレーム５３１４すなわち１つめのＰＨＹフレームの受信を完了してからＲＩＦＳ時間後に端末Ａ５２０１のキャリアセンス部１０９がキャリアセンス処理において受信電力がＩｄｌｅである場合であっても、端末Ｂ５２０２は何らかのフレーム（ここではＡｇｇｒｅｇａｔｉｏｎフレーム５３１１）を２つめのＰＨＹフレームとして送信しているはずである。

ここで従来のようなリカバリ方法に従えば、端末Ａ５２０１が１つめのＰＨＹフレームであるＢｌｏｃｋＡｃｋフレーム５３１０を受信した後ＰＩＦＳ時間（ＳＩＦＳ＋１Ｓｌｏｔ）が経過してから再送すべきフレームを送信することになる。

しかしそれでは、ＲＩＦＳ時間を挟んだ２つのＰＨＹフレームを待ち受けている端末Ｂ５２０２は、端末Ａ５２０１が再送したフレームを受信することができない。また、端末Ａ５２０１が再送したフレームが、端末Ｂ５２０２が送信している何らかのフレームと衝突してしまう。

これを避けるため、この場合は、端末Ａ５２０１がＢｌｏｃｋＡｃｋフレーム５３２４を受信した後、端末Ａ５２０１が端末Ｂ５２０２に与えたＴＸＯＰ分与時間がが終了してから、ＣＴＳ−Ｓｅｌｆフレーム５３１７を送信完了した後にＲＩＦＳ時間だけ経過してからＤａｔａフレームやＡｇｇｒｅｇａｔｉｏｎフレームを送信する。つまり、ＣＴＳ−Ｓｅｌｆフレーム５３１７を、ＤａｔａフレームとのＨＴＰ Ｂｕｒｓｔ フレーム５３５２として送信する。

このようなリカバリを行うことによって、ＲＤ方式において、端末Ａ５２０１が送信するリカバリ動作用フレームと、端末Ｂ５２０２が送信するＨＴＰ Ｂｕｒｓｔフレームとの衝突を避けることができる。

また、端末Ａ５２０１が与えたＴＸＯＰ分与時間を端末Ｂ５２０２が使いきらない場合に、端末Ａ５２０１で受信電力のＢｕｓｙを検出することができたならばその余った時間だけ繰り上げて双方向通信を行うことができる。

また、本実施の形態のようなリカバリを第５の実施の形態に対して組み合わせることによって、ＲＴＳ−ＣＴＳフレーム交換やＢｌｏｃｋＡｃｋフレームで張ったＮＡＶが端末Ｂ５２０２のＢｌｏｃｋＡｃｋフレーム５３１４で張るＮＡＶと同時に終了する場合でも、ＣＴＳ−Ｓｅｌｆフレーム５３１７を送信する前にＮＡＶが終了してしまっていることがなく、端末Ａ５２０１と端末Ｂ５２０２以外の端末との送信フレームの衝突を避けることができる。

（第１０の実施の形態）
本願の各実施の形態のＨＴＰ Ｂｕｒｓｔフレームの構成と、ＨＴＰ Ｂｕｒｓｔフレーム受信時の受信動作に関して詳述する。

図２３（ａ）及び図２３（ｂ）は、ＰＨＹフレームの構成を、図２３（ｃ）及び図２３（ｄ）はＨＴＰ Ｂｕｒｓｔフレームの構成を示す。

本願の各実施の形態の各端末間で送受信されるフレームは、図２３（ａ）に示すように、ＤａｔａフレームやＢｌｏｃｋＡｃｋフレームなどのＭＡＣレイヤからＰＨＹレイヤに送信されるＭＡＣフレーム５の前に、データ送受信時にＰＨＹレイヤの制御に必要な伝送レートや送信フレーム長などの情報を記載するＰＨＹヘッダー３を付け、その前に、ＰＨＹレイヤでの受信時に時間同期を取る際に必要なプリアンブル１を付けたフレーム構成で送受信されている。

本願の各実施の形態では、図２３（ａ）の構成のフレームと、図２３（ａ）のフレームの後ろに、ＰＨＹヘッダー３とＭＡＣフレーム５とを交互に複数結合した図２３（ｂ）の構成フレーム（Ａｇｇｒｅｇａｔｉｏｎフレーム２０）を、ＰＨＹフレーム１０と呼んでいる。また、ＭＡＣレイヤでのＡｇｇｒｅｇａｔｉｏｎを行う際は、ＰＨＹヘッダー３抜きでＭＡＣフレーム５がＡｇｇｒｅｇａｔｉｏｎされたＡｇｇｒｅｇａｔｉｏｎフレームとなる。

ＨＴＰ Ｂｕｒｓｔフレームは、図２３（ｃ）のようなフレーム構成となっており、図２３（ａ）もしくは図２３（ｂ）で説明したＰＨＹフレーム１０を、プリアンブル１とＰＨＹヘッダー３も付けたままで、間にＲＩＦＳ間隔を開けたＡｇｇｒｅｇａｔｉｏｎ方式の一つであるＨＴＰ Ｂｕｒｓｔ方式として、バーストとして送信される。この、バースト送信のことを、本願の各実施の形態ではＨＴＰ Ｂｕｒｓｔフレームと呼んでいる。もしくは、図２３（ｄ）のように、ＲＩＦＳの後にプリアンブルを省略して結合する方法でもよい。

ＨＴＰ Ｂｕｒｓｔフレーム５０では、ＰＨＹフレーム１０の間にＲＩＦＳ時間７が空いているが、ＲＩＦＳ時間７は、従来のＩＥＥＥ８０２．１１規格で最小時間間隔であったＳＩＦＳ時間（ＩＥＥＥ８０２．１１ａで１６μｓ）よりも大幅に短い期間（２μｓ）である為、ＰＨＹレイヤでの受信処理を軽減する為にＲＩＦＳ時間７でデータが送信されるのか従来通りＳＩＦＳ間隔以上でデータが送信されるかを、事前にＰＨＹレイヤへ通知する必要がある。特に、図２３（ｄ）のようにプリアンブル１を省略した場合は、ＰＨＹレイヤが、２μｓ後にＰＨＹヘッダーが来ることを認識していないと、時間同期を取ることが出来ない為に受信する事が出来ない。

本願の各実施の形態では、ＲＤ方式では、Ｉｎｉｔｉａｔｏｒ端末が最初に送信するＡｇｇｒｅｇａｔｉｏｎフレーム以降の全てのＡｇｇｒｅｇａｔｉｏｎフレームは、Ａｇｇｒｅｇａｔｉｏｎフレームの先頭に１つのＢｌｏｃｋＡｃｋフレームを付け、ＲＩＦＳ時間７を空けて１つのＰＨＹフレーム１０をＡｇｇｒｅｇａｔｅした、２つのＰＨＹフレーム１０によるＨＴＰ Ｂｕｒｓｔ方式のＡｇｇｒｅｇａｔｉｏｎフレームで通信が行われると言う事を、ＲＤ方式による双方向のデータ送受信を開始する前に、Ｉｎｉｔｉａｔｏｒ端末とＲｅｓｐｏｎｄｅｒ端末の間で、アソシエーションなどのマネジメントフレーム交換などをして取り決めているため、ＲＤ方式での送受信が始まると、ＭＡＣレイヤではＲＩＦＳ時間７で受信する必要があることが分かる為、ＰＨＹレイヤに対して、ＲＩＦＳ時間７で受信処理を行うか否かの指示が可能となる。

また、上記の取り決めが、２つのＰＨＹフレーム１０ではなく、３つ以上のＰＨＹフレーム１０を使用すると取り決められており、取り決められたＰＨＹフレーム１０の数も、最大値を取り決めただけの場合は、ＰＨＹヘッダー部分に、該ＰＨＹフレーム１０を受信後、ＲＩＦＳで送信されるかどうかを示すことにより、ＭＡＣレイヤからの指示を行わなくても、ＲＩＦＳ時間７での連続した受信処理の準備を行うことが出来る。

また、本願の各実施の形態のＢｌｏｃｋＡｃｋフレームやＡｃｋフレームやＣｆ−ｅｎｄフレームのように、ＭＡＣレイヤでＲＤ方式の通信が終了し、２つのＰＨＹフレームをＲＩＦＳ間隔で送信する処理が行われないことがわかる場合は、当該フレームを受信後に、ＰＨＹレイヤにＲＩＦＳ時間７で受信する必要が無いことを通知し、ＰＨＹレイヤの受信モードを通常の状態に戻すことが出来る。

したがって、ＲＩＦＳ間隔でバースト送信されるＨＴＰ Ｂｕｒｓｔ方式では、ＲＩＦＳ間隔でデータ受信を行う特殊な状況と、通常の受信方法を、ＭＡＣレイヤから適宜制御することが出来る。また、ＰＨＹヘッダーを使用する事によって、ＰＨＹレイヤのみで制御可能となり、ＭＡＣレイヤからの通知動作を省略することが出来る。

（第１１の実施の形態）
第１の実施の形態では、ＲＤ方式のＩｎｉｔｉａｔｏｒ端末が一台のＲｅｓｐｏｎｄｅｒ端末と双方向のデータ送受信処理を行っていた。これに対して本実施の形態では、第１の実施の形態で記載したＲＴＳフレームとＣＴＳフレームでのＮＡＶによる帯域予約を、全ての送信期間であるＴＸＯＰ時間分行い、ＲＤ方式とＨＴＰ Ｂｕｒｓｔ方式を組合わせた送受信処理を行う際に、Ｒｅｓｐｏｎｄｅｒ端末が複数台存在しても、ＲＤ方式とＨＴＰ Ｂｕｒｓｔ方式を組合わせた送受信処理を行う方法に関して説明する。

本実施の形態は、Ｒｅｓｐｏｎｄｅｒ端末の台数が複数台となり、各データの送信先が異なる部分のみが第１の実施の形態と異なるので、第１の実施の形態と異なる部分を中心に記載する。

図２４はＲＤ方式とＨＴＰ Ｂｕｒｓｔ方式を組み合わせた送受信時に、Ｒｅｓｐｏｎｄｅｒ端末が複数台いる場合の送受信方法を説明する図である。

本実施の形態では、ＲＤ方式のＩｎｉｔｉａｔｏｒ端末である端末Ａ１５０１から、ＲＤ方式で使用するＴＸＯＰ時間をＮＡＶの値として書き込んだＲＴＳフレーム１５０４を、最初のＲｅｓｐｏｎｄｅｒ端末である端末Ｂ１５０２に対して送信する。ＲＴＳフレーム１５０４を受信した端末Ｂ１５０２は、ＲＴＳフレーム１５０４に記載されたＮＡＶの値からＳＩＦＳ時間とＣＴＳフレーム１５０５の送信にかかる時間分差し引いた値を、ＣＴＳフレーム１５０５に記載して、端末Ａ１５０１に対して返信する。次に端末Ａ１５０１は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレームを先頭に付けた、端末Ｂ１５０２宛ての送信データＤａｔａ１−Ａ， Ｄａｔａ２−Ａ， Ｄａｔａ３−Ａ， Ｄａｔａ４−ＡをＡｇｇｒｅｇａｔｅしたＡｇｇｒｅｇａｔｉｏｎ ｆｒａｍｅを送信し、それに対して、端末Ｂ１５０２が、ＢｌｏｃｋＡｃｋフレーム１５０８を先頭に付けたＨＴＰ Ｂｕｒｓｔフレーム１５０９を端末Ａ１５０１に対して返信する。ここまでの送受信動作は、第１の実施の形態と同様のである。

ＨＴＰ Ｂｕｒｓｔフレーム１５０９を受信した端末Ａ１５０１は、第１の実施の形態と異なり、ＨＴＰ Ｂｕｒｓｔフレーム１５０９に対するＢｌｏｃｋＡｃｋフレームを送信する際に、端末Ｃ１５０３とのＲＤ方式に切り替える。ここで、端末Ａ１５０１は、ＨＴＰ Ｂｕｒｓｔフレーム１５０９内の端末Ｂ１５０２から端末Ａ１５０１へ送信されたデータＤａｔａ１−Ｂ， Ｄａｔａ２−Ｂ， Ｄａｔａ３−Ｂ， Ｄａｔａ４−Ｂに対するＢｌｏｃｋＡｃｋフレームとして、ＢｌｏｃｋＡｃｋフレーム１５１０を作成する。次に、ＢｌｏｃｋＡｃｋフレーム１５１０のＲＩＦＳ後に、端末Ａ１５０１から端末Ｃ１５０３に対する送信データＤａｔａ５−Ａ， Ｄａｔａ６−Ａ， Ｄａｔａ７−Ａ， Ｄａｔａ８−ＡをＡｇｇｒｅｇａｔｅしたＨＴＰ Ｂｕｒｓｔフレーム１５１１を作成し、端末Ｂ１５０２と端末Ｃ１５０３宛てに送信する。本実施の形態では、ＨＴＰ Ｂｕｒｓｔフレーム１５１１内に、端末Ｂ１５０２宛てのＢｌｏｃｋＡｃｋフレーム１５１０と、端末Ｃ１５０３宛ての送信データＤａｔａ５−Ａ， Ｄａｔａ６−Ａ， Ｄａｔａ７−Ａ， Ｄａｔａ８−Ａの２つの端末宛てのフレームが結合される。また、端末Ｃ１５０３宛ての送信データＤａｔａ５−Ａは、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａタイプのフレームとなっており、端末Ｃ１５０３に対して、ＴＸＯＰ時間の一部を分け与える動作を行っている。

ＨＴＰ Ｂｕｒｓｔフレーム１５１１を受信した端末Ｂ１５０２は、ＢｌｏｃｋＡｃｋフレーム１５１０から、自局が送信したデータの送達確認状況を確認する。また、ＨＴＰ Ｂｕｒｓｔフレーム１５１１を受信した端末Ｃ１５０３は、ＢｌｏｃｋＡｃｋフレーム１５１０のＲＩＦＳ後のＱｏＳ Ｃｆ−Ｐｏｌｌ＋Ｄａｔａフレーム１５１２から、自局にＴＸＯＰ時間が割当てられたことが分かる。次に、端末Ｃ１５０３は、ＨＴＰ Ｂｕｒｓｔフレーム１５１１内のデータＤａｔａ５−Ａ， Ｄａｔａ６−Ａ， Ｄａｔａ７−Ａ， Ｄａｔａ８−Ａに対するＢｌｏｃｋＡｃｋフレーム１５１３を作成し、端末Ａ１５０１に対する送信データＤａｔａ１−Ｃ， Ｄａｔａ２−Ｃ， Ｄａｔａ３−Ｃ， Ｄａｔａ４−ＣをＢｌｏｃｋＡｃｋフレーム１５１３のＲＩＦＳ後にＡｇｇｒｅｇａｔｅした、ＨＴＰ Ｂｕｒｓｔフレーム１５１４を作成し、端末Ａ１５０１に対して返信する。ＨＴＰ Ｂｕｒｓｔフレーム１５１４を受信した端末Ａ１５０１は、ＨＴＰ Ｂｕｒｓｔフレーム１５１４内の端末Ａ１５０１に対する送信データＤａｔａ１−Ｃ， Ｄａｔａ２−Ｃ， Ｄａｔａ３−Ｃ， Ｄａｔａ４−Ｃに対するＢｌｏｃｋＡｃｋフレーム１５１５を作成して、ＨＴＰ Ｂｕｒｓｔフレーム１５１４を受信したＳＩＦＳ後に返信し、ＲＤ方式による端末Ｂ１５０２と端末Ｃ１５０３との送受信処理を終了する。

この時、ＨＴＰ Ｂｕｒｓｔフレーム内のＢｌｏｃｋＡｃｋフレームのＮＡＶ設定方法及び送信レートは、第１の実施の形態と同様の方法を用いる。

上記、本実施の形態で説明した方法は、ＱｏＳ Ｃｆ−Ｐｏｌｌ＋ＤａｔａフレームをＡｇｇｒｅｇａｔｉｏｎしたＡｇｇｒｅｇａｔｉｏｎ ｆｒａｍｅを受信して、ＳＩＦＳ後にＢｌｏｃｋＡｃｋフレームと各送信データを複数Ａｇｇｒｅｇａｔｉｏｎしたフレームとの間にＲＩＦＳ間隔空けたＨＴＰ Ｂｕｒｓｔフレームを送信する方法自体は、他の実施の形態と同様である為、本実施の形態のＲＤ方式による複数端末との送受信処理には、他の実施の形態の全ての送受信方法が適用でき、また、リカバリー動作も同様に動作する事ができる。

本実施の形態の送受信方法によって、ＲＤ方式による複数端末との双方向通信が可能となり、複数端末との双方向通信中に、ＢｌｏｃｋＡｃｋフレームの到達確率を送信データよりも向上させることができる。また、ＢｌｏｃｋＡｃｋフレームを送信データと異なるＰＨＹフレームにて送信することにより、ＢｌｏｃｋＡｃｋフレームを用いて、帯域予約期間を延長する事ができる。など、他の実施の形態にて記載した効果と同様の効果を持った上で、複数端末と効率的に双方向通信を行う事ができる。

（第１２の実施の形態）
本実施の形態では、複数の端末と双方向通信する際に、複数の端末に対して一度に送信期間を分け与えるマルチポールフレームを使用する以外は、第１１の実施の形態と同様であるため、第１１の実施の形態と異なる部分のみを記載する。

図２５はＭＭＰ（Ｍｕｌｔｉｐｌｅ ｒｅｃｅｉｖｅｒ ａｇｇｒｅｇａｔｅ ｍｕｌｔｉ−ｐｏｌｌ）フレームにて複数端末に送信期間を付与し、自局からの送信データと複数端末からの送信データを双方向通信する方法を説明する図である。

本実施の形態の複数端末との双方向通信を開始する端末である端末Ａ１６０１は、ＭＭＰフレーム１６０４を先頭に付け、ＲＩＦＳ後に端末Ｂ１６０２に対する送信データＤａｔａ１−Ａ， Ｄａｔａ２−Ａ， Ｄａｔａ３−Ａ， Ｄａｔａ４−Ａを一つのＰＨＹフレームにＡｇｇｒｅｇａｔｅしたフレームを結合し、さらにＲＩＦＳ後に端末Ｃ１６０３に対する送信データＤａｔａ５−Ａ， Ｄａｔａ６−Ａ， Ｄａｔａ７−Ａ， Ｄａｔａ８−Ａを接続したＨＴＰ Ｂｕｒｓｔフレーム１６１１を送信する。

ＭＭＰフレーム１６０４には、端末Ｂ１６０２に対して分け与える送信期間として、端末Ｂ１６０２に対するオフセット期間１６０７と端末Ｂ１６０２に与えるＴＸＯＰ時間１６０８が記載されており、また、端末Ｃ１６０３に対して分け与える送信期間として、端末Ｃ１６０３に対するオフセット期間１６０９と端末Ｃ１６０３に与えるＴＸＯＰ時間１６１０が記載される。また、ＭＭＰフレーム１６０４のは、ＭＭＰフレーム１６０４で開始する双方向通信期間１６０５の帯域予約を行うＮＡＶの値が記載される。

ＭＭＰフレーム１６０４を先頭に結合したＨＴＰ Ｂｕｒｓｔフレーム１６１１を受信した端末Ｂ１６０２は、ＭＭＰフレーム１６０４に書き込まれた端末Ｂ１６０２に対するオフセット期間１６０７を取り出し、端末Ｂ１６０２の送受信状態管理部１０８にてオフセット期間１６０７のタイマーをかける。次に、ＨＴＰ Ｂｕｒｓｔフレーム１６１１内の端末Ｂ１６０２宛ての送信データＤａｔａ１−Ａ， Ｄａｔａ２−Ａ， Ｄａｔａ３−Ａ， Ｄａｔａ４−Ａを受信して、ＢｌｏｃｋＡｃｋフレーム１６１１を作成する。

端末Ｂ１６０２がＨＴＰ Ｂｕｒｓｔフレーム１６１１を受信した後、送受信状態管理部１０８にてかけた端末Ｂ１６０２に対するオフセット期間１６０７のタイマーが切れると、端末Ｂ１６０２に与えるＴＸＯＰ時間１６０８となる。この時、端末Ｂ１６０２は、ＢｌｏｃｋＡｃｋフレーム１６１１を作成し、ＢｌｏｃｋＡｃｋフレーム１６１１のＲＩＦＳ後に、端末Ａ１６０１に対する送信データＤａｔａ１−Ｂ， Ｄａｔａ２−Ｂ， Ｄａｔａ３−Ｂ， Ｄａｔａ４−ＢをＡｇｇｒｅｇａｔｅしたＨＴＰ Ｂｕｒｓｔフレーム１６１２を作成して、端末Ａ１６０１に対して送信し、ＨＴＰ Ｂｕｒｓｔフレーム１６１２を送信したＳＩＦＳ後に端末Ａ１６０１からのＢｌｏｃｋＡｃｋフレーム１６１３を受信する。但し、ＨＴＰ Ｂｕｒｓｔフレーム１６１２は、端末Ｂ１６０２に与えるＴＸＯＰ時間１６０８を超えないように、Ａｇｇｒｅｇａｔｅするデータ数を調整する。図２５に示すように、ＨＴＰ Ｂｕｒｓｔフレーム１６１２は、ＢｌｏｃｋＡｃｋフレーム１６１１と端末Ａ１６０１に対する送信データＤａｔａ１−Ｂ， Ｄａｔａ２−Ｂ， Ｄａｔａ３−Ｂ， Ｄａｔａ４−Ｂの間にＲＩＦＳ期間あけている為、他の実施の形態と同様に、送信レートを変更する事が出来、またＮＡＶを通知する事が出来る。

次に端末Ｃ１６０３では、ＨＴＰ Ｂｕｒｓｔフレーム１６１１を受信した際に、端末Ｂ１６０２と同様に、ＭＭＰフレーム１６０４に記載された端末Ｃ１６０３に対するオフセット期間１６０９を取り出し、端末Ｃ１６０３の送受信状態管理部１０８にてオフセット期間１６０７のタイマーをかける。その後、ＨＴＰ Ｂｕｒｓｔフレーム１６１１内の端末Ｃ１６０３宛ての送信データＤａｔａ５−Ａ， Ｄａｔａ６−Ａ， Ｄａｔａ７−Ａ， Ｄａｔａ８−Ａを受信して、ＢｌｏｃｋＡｃｋフレームを作成する。端末Ｃ１６０３の送受信状態管理部１０８にてかけた、端末Ｃ１６０３に対するオフセット期間１６０９のタイマーが切れると、端末Ｃ１６０３に与えるＴＸＯＰ時間１６１０となり、端末Ｃ１６０３は、ＢｌｏｃｋＡｃｋフレーム１６１４を作成し、ＢｌｏｃｋＡｃｋフレーム１６１４のＲＩＦＳ語に、端末Ａ１６０１に対する送信データＤａｔａ１−Ｃ， Ｄａｔａ２−Ｃ， Ｄａｔａ３−Ｃ， Ｄａｔａ４−ＣをＡｇｇｒｅｇａｔｅしたＨＴＰ Ｂｕｒｓｔフレーム１６１５を作成して、端末Ａ１６０１に対して送信し、ＨＴＰ Ｂｕｒｓｔフレーム１６１５を送信したＳＩＦＳ後に端末Ａ１６０１からのＢｌｏｃｋＡｃｋフレーム１６１６を受信して、ＭＭＰフレーム１６１４で開始する双方向通信期間１６０５を終了する。

但し、端末Ｃ１６０３に与えるＴＸＯＰ時間１６１０は、端末Ｂ１６０２に与えるＴＸＯＰ時間１６０８終了後に開始する。

また、図２５に示すように、端末Ｂ１６０２の送信キューに蓄積するデータ数が少なく、端末Ｂ１６０２が、端末Ｂ１６０２に与えるＴＸＯＰ時間１６０８を全て使用出来なかった場合に、ＴＸＯＰ時間を分け与えた端末Ａ１６０１は、他の実施の形態と同様に、ＢｌｏｃｋＡｃｋフレームを受信したＲＩＦＳ後に一つのＰＨＹフレームを受信したことによって、与えたＴＸＯＰ時間の通信が完了したことを示すとすると、余ったＴＸＯＰ時間を、端末Ａ１６０１からの他端末宛てのデータ送信等に使用してもよい。但し、余ったＴＸＯＰ時間を使用する場合は、端末Ｃ１６０３に与えるＴＸＯＰ時間１６１０の開始時間までの期間とする。

以上、本実施の形態による通信方法を用いる事によって、複数の端末に対して一度に送信期間を分け与えるマルチポールフレームを使用する通信方法において、ＢｌｏｃｋＡｃｋフレームの到達確率を送信データよりも向上させることができる。また、ＢｌｏｃｋＡｃｋフレームを送信データと異なるＰＨＹフレームにて送信することにより、ＢｌｏｃｋＡｃｋフレームを用いて、帯域予約期間を再度通知することが可能となる。また、ＢｌｏｃｋＡｃｋフレームの、ＴＸＯＰを分け与えられた端末が使用する期間を記載する事によって、分け与えられたＴＸＯＰの内の使用しない期間を通知可能となり、ＴＸＯＰを分け与えられた端末が使用しない期間を有効に活用する事が出来る。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

第１の実施の形態に係る無線通信装置のブロック図。 第１の実施の形態に係るタイミングチャート。 第１の実施の形態の端末Ａの動作に係るフローチャート。 第１の実施の形態の端末Ｂの動作に係るフローチャート。 第１の実施の形態の端末の位置関係を示す図。 第１の実施の形態の変形例２に係る無線通信装置のブロック図。 第１の実施の形態の変形例２に端末Ａの動作に係るフローチャート。 第１の実施の形態の変形例２に端末Ｂの動作に係るフローチャート。 第１の実施の形態の変形例３に係る無線通信装置のブロック図。 第１の実施の形態の変形例３に端末Ａの動作に係るフローチャート。 第１の実施の形態の変形例３に端末Ｂの動作に係るフローチャート。 第１の実施の形態の変形例４に係るタイミングチャート。 第２の実施の形態に係るタイミングチャート。 第３の実施の形態に係るタイミングチャート。 第４の実施の形態の端末Ｂの動作に係るフローチャート。 第４の実施の形態の端末の位置関係を示す図。 第５の実施の形態に係るタイミングチャート。 第５の実施の形態の端末Ａの動作に係るフローチャート。 第５の実施の形態の端末Ｂの動作に係るフローチャート。 第６の実施の形態に係るタイミングチャート。 第６の実施の形態の端末Ａの動作に係るフローチャート。 第７の実施の形態に係るタイミングチャート。 第１０の実施の形態のフレーム構成を示す図。 第１１の実施の形態に係るタイミングチャート。 第１２の実施の形態に係るタイミングチャート。

符号の説明

１０１・・・無線通信装置、１０２・・・送信データ管理部、１０３・・・
アクセス制御部、１０４・・・フレーム生成・送信部、１０５・・・受信処理部、１０６・・・送信キュー、１０７・・・送受信方法決定部、１０８・・・送受信状態管理部、１０９・・・キャリアセンス部。

Claims (28)

1. 他の無線通信装置から、前記他の無線通信装置が送信することができる期間の一部を与えられ、前記他の無線通信装置との双方向通信を行う無線通信装置において、
   前記他の無線通信装置から、複数のデータフレームを受信する受信手段と、
   前記複数のデータフレームに対する送達確認フレームを含む第１物理フレームと、前記他の無線通信装置を宛先とする複数の送信データフレームを含む第２物理フレームを生成する生成手段と、
   前記他の無線通信装置から与えられた期間中に、前記第１物理フレームを第１の伝送レートで送信し、前記第１物理フレームの送信時点から一定期間が経過した後に第２の伝送レートで前記第２物理フレームを送信する送信手段と、を具備する無線通信装置。
2. 前記送信手段が前記第１物理フレームの送信を完了してから前記第２物理フレームの送信を開始するまでの期間が、ＲＩＦＳ（Ｒｅｄｕｃｅｄ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）であることを特徴とする請求項１記載の無線通信装置。
3. 前記受信手段が前記他の無線通信装置からＲＴＳフレームを受信し、前記送信手段が前記他の無線通信装置へＣＴＳフレームを送信した後に、前記他の無線通信装置との双方向通信が開始されることを特徴とする請求項１または請求項２に記載の無線通信装置。
4. 前記第１の伝送レートで送信されたフレームのエラー確率と、前記第２の伝送レートで送信されたフレームのエラー確率とが異なることを特徴とする請求項１乃至請求項３のいずれか１項に記載の無線通信装置。
5. 前記第１の伝送レートは、前記第２の伝送レートよりも低いことを特徴とする請求項１乃至請求項４のいずれか１項に記載の無線通信装置。
6. 前記第１物理フレームは、帯域を予約するための第１の帯域予約期間の値を含んでおり、
   前記第１の伝送レートで送信された前記第１物理フレームは、前記第１の伝送レートをサポートする第１無線通信装置と、前記第１伝送レートおよび前記第２伝送レートとをサポートする第２無線通信装置とによって受信可能であり、
   前記第２の伝送レートで送信された前記第２物理フレームは、前記第２無線通信装置によって受信可能であることを特徴とする請求項１乃至請求項５のいずれか１項に記載の無線通信装置。
7. 前記生成手段は、前記複数の送信データフレームについての送達確認フレームを要求するための送達確認要求フレームを含む第３物理フレームをさらに生成し、
   前記送信手段は、前記第２物理フレームの送信時点から一定期間が経過した後に第３の伝送レートで前記第３物理フレームを送信することを特徴とする請求項１乃至請求項６のいずれか１項に記載の無線通信装置。
8. 前記第３の伝送レートは、前記第２の伝送レートよりも低いことを特徴とする請求項７に記載の無線通信装置。
9. 他の無線通信装置から、前記他の無線通信装置が送信することができる期間の一部を与えられ、前記他の無線通信装置との双方向通信を行う無線通信方法において、
   前記他の無線通信装置から、複数のデータフレームを受信し、
   前記複数のデータフレームに対する送達確認フレームを含む第１物理フレームと、前記他の無線通信装置を宛先とする複数の送信データフレームを含む第２物理フレームを生成し、
   前記他の無線通信装置から与えられた期間中に、前記第１物理フレームを第１の伝送レートで送信し、
   前記他の無線通信装置から与えられた期間中に、前記第１物理フレームの送信時点から一定期間が経過した後に第２の伝送レートで前記第２物理フレームを送信することを特徴とする無線通信方法。
10. 前記第１物理フレームの送信を完了してから、前記第２物理フレームの送信を開始するまでの期間が、ＲＩＦＳ（Ｒｅｄｕｃｅｄ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）であることを特徴とする請求項９記載の無線通信方法。
11. 前記受信手段が前記他の無線通信装置からＲＴＳフレームを受信し、前記送信手段が前記他の無線通信装置へＣＴＳフレームを送信したあと、前記他の無線通信装置との双方向通信が開始されることを特徴とする請求項９または請求項１０に記載の無線通信方法。
12. 前記第１の伝送レートで送信されたフレームのエラー確率と、前記第２の伝送レートで送信されたフレームのエラー確率とが異なることを特徴とする請求項９乃至請求項１１のいずれか１項に記載の無線通信方法。
13. 前記第１の伝送レートは、前記第２の伝送レートよりも低いことを特徴とする請求項９乃至請求項１２のいずれか１項に記載の無線通信方法。
14. 前記第１物理フレームは、帯域を予約するための第１の帯域予約期間の値を含んでおり、
    前記第１の伝送レートで送信された前記第１物理フレームは、前記第１の伝送レートをサポートする第１無線通信装置と、前記第１伝送レートおよび前記第２伝送レートとをサポートする第２無線通信装置とによって受信可能であり、
    前記第２の伝送レートで送信された前記第２物理フレームは、前記第２無線通信装置によって受信可能であることを特徴とする請求項９乃至請求項１３のいずれか１項に記載の無線通信方法。
15. 前記第１物理フレームと前記第２物理フレームに加えて、前記複数の送信データフレームについての送達確認フレームを要求するための送達確認要求フレームを含む第３物理フレームをさらに生成し、
    前記第２物理フレームの送信時点から一定期間が経過した後に第３の伝送レートで前記第３物理フレームを送信することを特徴とする請求項９乃至請求項１４のいずれか１項に記載の無線通信方法。
16. 前記第３の伝送レートは、前記第２の伝送レートよりも低いことを特徴とする請求項１５に記載の無線通信方法。
17. 送信することができる送信可能期間の一部を他の無線通信装置に与え、前記他の無線通信装置と双方向通信を行う無線通信装置において、
    前記他の無線通信装置から複数のデータフレームを受信する受信手段と、
    前記複数のデータフレームに対する送達確認フレームを含む第１物理フレームと、前記他の無線通信装置を宛先とする複数の送信データフレームを含む第２物理フレームを生成する生成手段と、
    前記送信可能期間内に、前記第１物理フレームを第１の伝送レートで送信し、該第１物理フレームの送信時点から一定期間が経過した後に第２の伝送レートで前記第２物理フレームを送信する送信手段と、を具備する無線通信装置。
18. 前記第１の伝送レートで送信されたフレームのエラー確率と、前記第２の伝送レートで送信されたフレームのエラー確率とが異なることを特徴とする請求項１７項に記載の無線通信装置。
19. 前記第１の伝送レートは、前記第２の伝送レートよりも低いことを特徴とする請求項１７または請求項１８に記載の無線通信装置。
20. 前記第１物理フレームは、帯域を予約するための第１の帯域予約期間の値を含んでおり、
    前記第１の伝送レートで送信された前記第１物理フレームは、前記第１の伝送レートをサポートする第１無線通信装置と、前記第１伝送レートおよび前記第２伝送レートとをサポートする第２無線通信装置とによって受信可能であり、
    前記第２の伝送レートで送信された前記第２物理フレームは、前記第２無線通信装置によって受信可能であることを特徴とする請求項１７乃至請求項１９のいずれか１項に記載の無線通信装置。
21. 前記生成手段は、前記複数の送信データフレームについての送達確認フレームを要求するための送達確認要求フレームを含む第３物理フレームをさらに生成し、
    前記送信手段は、前記第２物理フレームの送信時点から一定期間が経過した後に第３の伝送レートで前記第３物理フレームを送信することを特徴とする請求項１７乃至２０のいずれか１項に記載の無線通信装置。
22. 前記第３の伝送レートは、前記第２の伝送レートよりも低いことを特徴とする請求項２１に記載の無線通信装置。
23. 送信することができる送信可能期間の一部を他の無線通信装置に与え、前記他の無線通信装置と双方向通信を行う無線通信方法において、
    前記他の無線通信装置から複数のデータフレームを受信し、
    前記複数のデータフレームに対する送達確認フレームを含む第１物理フレームと、前記他の無線通信装置を宛先とする複数の送信データフレームを含む第２物理フレームを生成し、
    前記送信可能期間内に、前記第１物理フレームを第１の伝送レートで送信し、該第１物理フレームの送信時点から一定期間が経過した後に第２の伝送レートで前記第２物理フレームを送信することを特徴とする無線通信方法。
24. 前記第１の伝送レートで送信されたフレームのエラー確率と、前記第２の伝送レートで送信されたフレームのエラー確率とが異なることを特徴とする請求項２３項に記載の無線通信方法。
25. 前記第１の伝送レートは、前記第２の伝送レートよりも低いことを特徴とする請求項２３または請求項２４記載の無線通信方法。
26. 前記第１物理フレームは、帯域を予約するための第１の帯域予約期間の値を含んでおり、
    前記第１の伝送レートで送信された前記第１物理フレームは、前記第１の伝送レートをサポートする第１無線通信装置と、前記第１伝送レートおよび前記第２伝送レートとをサポートする第２無線通信装置とによって受信可能であり、
    前記第２の伝送レートで送信された前記第２物理フレームは、前記第２無線通信装置によって受信可能であることを特徴とする請求項２３乃至請求項２５のいずれか１項に記載の無線通信方法。
27. アンテナをさらに具備し、
    前記受信手段は、前記アンテナを用いて前記複数のデータフレームを受信し、
    前記送信手段は、前記アンテナを用いて前記第１物理フレーム及び前記第２物理フレームを送信する
    請求項１−８のいずれか１項に記載の無線通信装置。
28. アンテナをさらに具備し、
    前記受信手段は、前記アンテナを用いて前記複数のデータフレームを受信し、
    前記送信手段は、前記アンテナを用いて前記第１物理フレーム及び前記第２物理フレームを送信する
    請求項１７−２２のいずれか１項に記載の無線通信装置。

Images