JP4086304B2 - 通信装置、通信システム、および通信制御プログラム - Google Patents

Description

本発明は媒体アクセス制御（ＭＡＣ）を行なう通信装置、通信システム、および通信制御プログラムに関し、特に、１つの物理フレームに複数の媒体アクセス制御フレーム（ＭＡＣフレーム）を含めるフレームアグリゲーションを行うものに関する。

同一の媒体を共有して通信を行なう複数の通信装置がどのように媒体を利用して通信データを送信するかを決めるのが、媒体アクセス制御(ＭＡＣ: Media Access Control)である。媒体アクセス制御は、同時に２つ以上の通信装置が同一の媒体を利用して通信データの送信を行なった結果、受信側の通信装置が通信データを分離できなくなる事象（衝突）がなるべく少なくなり、一方、送信要求を持つ通信装置が存在するにもかかわらず媒体がいずれの通信装置によっても利用されない事象がなるべく少なくなるように、通信装置から媒体へのアクセスを制御するための技術である。

しかし、特に無線通信においては、通信装置がデータを送信しながら同時に送信データをモニタすることは困難であることから、衝突検出を前提としない媒体アクセス制御（ＭＡＣ）が必要である。無線ＬＡＮの代表的な技術標準であるIEEE802.11はＣＳＭＡ／ＣＡ(Carrier Sense Multiple Access with Collision Avoidance)を採用している。IEEE802.11のＣＳＭＡ／ＣＡでは、ＭＡＣフレームのヘッダーに、該フレームに続く１つ以上のフレーム交換からなる一連のシーケンスが終了するまでの期間(Duration)が設定される。この期間において、該シーケンスに関係がなく送信権を持たない通信装置は、媒体の仮想的な占有状態を判断することにより、送信を待機する。したがって、衝突の発生が回避される。一方、該シーケンスで送信権を持つ通信装置は、実際に物理媒体が占有されている期間を除き、媒体は使用されていないものと認識する。IEEE802.11では、このようなＭＡＣ層の仮想キャリアセンスと、物理層の物理キャリアセンスとの組み合わせによって媒体の状態を判定し、媒体アクセスを制御する旨が規定されている。

ＣＳＭＡ／ＣＡを採用しているIEEE802.11は、これまで主として物理層プロトコルを変更することによって通信速度の高速化を図ってきた。２．４ＧＨｚ帯についてはIEEE802.11（１９９７年、２Ｍｂｐｓ）からIEEE802.11b（１９９９年、１１Ｍｂｐｓ）へ、そしてIEEE802.11g（２００３年、５４Ｍｂｐｓ）へと変遷している。５ＧＨｚ帯については、今のところIEEE802.11a（１９９９年、５４Ｍｂｐｓ）のみが標準として存在する。そして、２．４ＧＨｚ帯および５ＧＨｚ帯の両方で更なる高速化を目指す標準規格を策定するためにIEEE802.11 TGn(Task Group n)が既に設立されている。

さらに、サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御も幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するＱｏＳとして、従来のポーリング手順を拡張したＨＣＣＡ（HCF Controlled Access；ＨＣＦコントロールド・アクセス）がある。ＨＣＣＡでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。特許文献２は、IEEE802.11e規格のＱｏＳについて言及しており、無線ネットワークにおける通信装置間の通信に優先順位を付与する方法を開示する。
米国特許第５３２９５３１号明細書 特開２００２−３１４５４６公報

物理層に関して通信速度の高速化を図れたとしても、通信の実質的なスループットを向上できないという問題点がある。すなわち、物理層の高速化が実現された場合、ＰＨＹフレームのフォーマットはもはや効率的ではなくなり、このことに起因するオーバヘッドがスループットの向上を阻害すると考えられる。ＰＨＹフレームにおいて、ＣＳＭＡ／ＣＡに係わる時間的なパラメータはＭＡＣフレームに固定的に付随している。また、ＰＨＹフレームヘッダーは各ＭＡＣフレーム毎にそれぞれ必要である。

オーバヘッドを解消してスループットを向上させる方法の一つとして、最近のdraft IEEE802.11e draft 5.0 (IEEE802.11のQoS強化)で導入されたブロック応答(Block ACK)機構がある。しかし、ブロック応答機構によればバックオフ無しで複数のMACフレームを連続的に送信でき、これによりバックオフ量を幾分は削減できるものの、物理層のヘッダーのオーバヘッドまでは効果的に削減されない。また、初期のdraft IEEE802.11eで導入されたアグリゲーションによれば、バックオフ量と物理層ヘッダーのいずれをも削減可能とされているが、従来の物理層の制約によりMACフレームを含む物理層のフレームの長さを約4k byte以上にはできないため、効率向上には大きな制約がある。仮に、物理層のフレームを長くできたとしても、エラー耐性が低下するという別の問題が生じる。

したがって、フレームフォーマットの効率化により複数のフレームを送信することに伴うオーバヘッドを解消し、通信の実質的なスループットを向上することが必要とされる。

一方、従来のＨＣＣＡによれば、トラフィックストリーム毎に品質を保証することができ、優先度に応じたデータ伝送を実現できる。このようなＱｏＳはスループットを更に向上した新たな通信方式においても利用することが好ましい。例えば、１つのＰＨＹ（物理）フレームに複数のＭＡＣフレームを含めて送信することにより伝送効率を向上するフレームアグリゲーションにおいてもＱｏＳを利用することが好ましい。しかしながら、ＨＣＣＡのようなＱｏＳに従来のフレームアグリゲーションをそのまま適用すると、次のような問題点が生じる。

すなわち、フレームの優先度を考慮しないフレームアグリゲーションでは、送信キュー（TxQ）内の一連のフレームをアグリゲーション対象フレームとするとき、比較的低優先度のＦＴＰ(File Transfer Protocol)フレームが高優先度のＶｏＩＰ(Voice over IP)フレームに先行して取り出され、送信用のアグリゲーションフレームにアグリゲートされ得る。このことは、フレームの優先度を考慮したＱｏＳの維持および向上の妨げとなり得る。

また、受信エラーが生じた一部のフレームを指定して再送を要求するパーシャルＡＣＫフレームの手順についても、ＱｏＳに固有のＡＣＫ手順（例えば無応答（No_ACK）手順）との複合利用を図るべき問題もある。

本発明はかかる事情を考慮してなされたものであり、複数の通信フレームのアグリゲーションによりスループットを向上できる通信装置、通信システム、および通信制御プログラムを提供することを目的とする。

本発明の一態様に係る通信装置は、複数のＭＡＣフレームを含む単一の物理フレームを作成する作成手段と、前記作成手段により作成された物理フレームを送信する送信手段とを具備し、前記物理フレームは、前記複数のＭＡＣフレームのそれぞれに対応するビットからなる可変長のビットマップ情報と、該ビットマップ情報の長さ情報とを有することを特徴とする通信装置である。

本発明によれば、複数の通信フレームのアグリゲーションによりスループットを向上できる通信装置、通信システム、および通信制御プログラムを提供できる。

以下、図面を参照しながら本発明の実施の形態の例を説明する。
図１は本発明の一実施形態に係る通信装置の構成を示すブロック図である。この通信装置１００は無線リンクを介して他の通信装置と通信する装置であり、物理層、ＭＡＣ層、およびリンク層のそれぞれに相当する処理ユニット１０１、１０２、１０３を有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはＬＳＩに組み込まれたＣＰＵにより実行されるファームウェア等として実現される。物理層の処理ユニット１０１にはアンテナ１０４が接続されている。ＭＡＣ層１０２は本発明に係わるアグリゲーション（集約）処理部１０５を有する。

アグリゲーション処理部１０５は、複数の媒体アクセス制御（ＭＡＣ）フレームを含むＰＨＹ（物理）フレームを作成する。媒体アクセス制御フレームとしては、例えばＭＰＤＵ(MAC Protocol Data Unit)であり、自明な変形を行ってMACヘッダーを含まないＭＳＤＵ(MAC Size Data Unit)とすることもできる。作成された物理フレームは物理層の処理ユニット１０１により処理され、アンテナ１０４より送信される。このような通信方式のことを本明細書では「フレームアグリゲーション」という。フレームアグリゲーションは現在策定中の次世代超高速無線ＬＡＮ通信（IEEE802.11n規格）に好適である。

MACスーパーフレーム（MACアグリゲーションフレーム）の基本的なフレームフォーマットは、少なくとも一つのMACスーパーフレームヘッダーと、該MACスーパーフレームヘッダーに続く少なくとも一つのMACスーパーフレームペイロードとを有する、というものである。

ＭＡＣスーパーフレームを受信した端末は、まず自分宛のアドレスであるかどうか判断し、各ＭＰＤＵのＣＲＣ（cyclic redundancy check；巡回冗長検査）計算を行う。その後、ＭＡＣスーパーフレームヘッダー内のＡＣＫポリシービットマップフィールドをチェックし、パーシャルＡＣＫを必要とする「1」のフラグが立っていれば、パーシャルＡＣＫフレームの該当するビットマップに「1」または「0」の値を設定する(ＣＲＣを計算して正しく受信できていれば「1」、誤っていれば「0」とする)。また、ＡＣＫポリシービットマップが「0」であるＭＰＤＵは、「No_ACK」による転送を希望しているので、ＣＲＣの計算結果に関わらず、「0」の値を設定する。

ＭＡＣスーパーフレームを送信した端末が、宛先端末からのパーシャルＡＣＫを受信した場合、自分のキャッシュしているＡＣＫポリシービットマップ情報とパーシャルＡＣＫビットマップ(Partial ACK Bitmap)とを照らし合わせる。ＡＣＫを必要としているにもかかわらず、パーシャルＡＣＫビットマップのビット情報が「0」になっていれば、該当するデータフレームを再送する。

フレームアグリゲーションにおけるパーシャルＡＣＫ(Partial_ACK)について説明する。ＭＡＣスーパーフレームを送信する端末のＭＡＣ層は、上位層から下りてくるデータフレームに対し、ＡＣＫポリシーをそれぞれ決定していく。この場合、ＡＣＫポリシーをパーシャルＡＣＫに指定することは、「そのデータフレームをフレームアグリゲーションの対象にし、かつ受信側からのＡＣＫ応答を必要としている」ことを意味する。

いかなるＡＣＫメカニズムを用いてフレームを転送するかについては、「Normal_Ack（ノーマルＡＣＫ）」，「No_ACK（無応答）」，「Block_ACK（ブロックＡＣＫ）」の３種類がIEEE802.11eで既に規定されている。

「Normal_Ack」は、IEEE802.11でサポートされている通常のデータ送信方法であり、１つのユニキャストデータフレームを送信した後、宛先端末からのＡＣＫフレームを受信するまで一定時間待機する。タイムアウトが起これば、再度バックオフを行ってデータフレームを再送する。「Normal_Ack」に指定されたデータフレームは、フレームアグリゲーションの対象にせず、既存のIEEE802.11規格の手順で送信を行う。

「No_ACK」は、伝送路が比較的安定している場合に用いられるデータ送信方法であり、相手端末からのＡＣＫフレームの受信を待たずに（つまりACKを必要としない）、新たなデータフレームを送信する。

「Block_ACK」は、ユニキャストデータフレームをＳＩＦＳ(Short Inter Frame Space)間隔でバースト的に連続送信するデータ送信方法であり、ブロックＡＣＫフレームにより選択的再送（Selective Repeat転送）を実現するものである。

なお、ＭＡＣスーパーフレームの種々の構成例、応答制御（送達確認）、再送制御、ＱｏＳ、ならびにサイマルキャスト等については、本出願と同一出願人による先の出願に係る特願２００４−００４８４７明細書、特願２００４−０６３２３７明細書、特願２００４−１１０４４６明細書の記載を参考にすることができる。

（第１の実施形態）
第１の実施形態は、１つの物理フレームに複数のMACフレーム（MPDU）をアグリゲートする際に、可変長のビットマップ情報と該ビットマップのデータ長とをMACスーパーフレームヘッダー中に含めるように構成された通信装置に関する。具体的には、物理フレームは、複数のＭＡＣフレームのそれぞれに対応するビットからなる可変長のビットマップ情報と、該ビットマップ情報の長さ情報とを有する。

図２に示すように、ACK Policy Bitmap２０をMACスーパーフレームヘッダー２１中に含めてMACスーパーフレームを送信する際に、送受信端末間で、事前にネゴシエーションをしておき、ACK Policy Bitmap２０の長さを受信側で把握していることが必要である。このネゴシエーション方法としては、ビーコンやIEEE802.11eのHCCAにおけるトラフィックストリームのセットアップなど様々な方法が考えられる。なお、本発明はACK Policy Bitmap長のネゴシエーションによる通知を特定の方法に限定するものではない。MACスーパーフレームの受信側は、このようなサイズ情報をあらかじめ知っていない限り、ACK Policy Bitmap２０を正しく取り出すことはできない。

一方、第１の実施形態は可変長のビットマップ情報を記載することを可能にするものであり、図３に示すような、Bitmap Informationフィールドを定義する。すなわち、Bitmap IDフィールド３１によって、Bitmapの種別(ACK Policy Bitmapなど)を規定し、Lengthフィールドにおいて、実際のビットマップ情報(Bitmap Informationフィールド３３)の長さを例えばバイト単位(Bytes)で指定する。これにより、ACK Policy Bitmapは、事前にネゴシエーションを行なわなくても、MACスーパーフレーム単位に可変長(バイト単位)の大きさで埋め込むことができる。

図３に示すビットマップエレメントは、例えばACKポリシービットマップ（"ACK Policy Bitmap"）、マルチアドレスビットマップ（"Multi Address Bitmap"）等があり、Bitmap ID３１はこれらを識別可能にする。なお、ビットマップエレメント（ビットマップＩＤ）はこれらに限定されないことは言うまでもない。

図４の例のように、MACスーパーフレーム４０中に１２個のMPDUをアグリゲートする場合、ACK Policy Bitmapとしては２バイトの大きさのビットマップが必要であり、このためBitmap Information３３のLengthフィールド３２には「2」が指定される。Bitmap IDフィールド３１には、ACK Policy Bitmapに相当するＩＤが指定される。

（第２の実施形態）
第２の実施形態に係る通信装置はMACスーパーフレーム受信端末であって、受信バッファからの取り出しと上位層への明け渡しを優先度毎に、タイマーにより時間管理する通信装置と、MACスーパーフレーム送信端末であって、優先度毎のバッファからの取り出しと上位層への明け渡しのタイマー設定を受信側に対して指定する通信装置である。

IEEE802.11eのHCCA方式を元にして１つの物理フレームに複数のMACフレームをアグリゲートして送信する場合、それぞれのトラフィックストリーム(TS)毎に、シーケンス番号が付与される。シーケンス番号は連続している必要があり、図５に示すように受信側でフレームのバッファリングが行なわれる。

図５の例では、MACスーパーフレームに「高優先度」「中優先度」「低優先度」の３つの優先度のMACフレーム５０，５１，５２が存在し、それぞれの先頭のフレーム５３，５４，５５が受信誤りであった場合を示している。トラフィックストリーム毎に、シーケンス番号が連続して受信できている場合、MAC層より上位の層(例えばネットワーク層)にフレームを渡すことができるが、図５のような場面では、それぞれシーケンス番号「1」のフレームを受信するまで、後続のフレーム(シーケンス番号「2」以降)がバッファで待機することになる（受信バッファ状態５６，５７，５８）。

IEEE802.11では、一定時間経過しても、受信側のバッファ内で待機しているフレームよりもシーケンス番号の若いフレームが受信できない場合、タイムアウトが生じ、全ての蓄積フレームが上位層(例えばIP)に渡される。優先度毎のスライディングウィンドウ制御を行なっている場合、送受信側では優先度に応じて、シーケンス番号の管理が行なわれる。したがって、遅延時間に敏感なトラフィックストリームも、遅延時間に対して比較的大きな許容を持つトラフィックストリームも同様に扱われてしまうという問題がある。

そこで、第２の実施形態では、図６のように、MACスーパーフレーム受信側でトラフィックストリーム毎のバッファ６０，６１，６２のそれぞれにタイマー１，２，３を設け、独立して動作するこれらタイマーの動作に従ってトラフィックストリーム毎にバッファ管理をする。タイマー１，２，３がタイムアウトすると、対応するバッファ６０，６１，６２に格納されているフレームがバッファから開放され、上位層に渡される。

タイマー１，２，３の各々にセットする値（タイムアウト時間）は、トラフィックストリームをセットアップする際の、図７（ａ）に示すTSPEC(Traffic Specification)７０のDelay Boundフィールド７１を元に決定してもよい。Delay Boundフィールド７１はQoSデータの遅延時間の許容を示すもので、Delay Boundを過ぎたフレームは、再送上限回数に達する前でも送信側で廃棄される。このようなDelay Boundをトラフィックストリームの優先度毎に設定し、タイマー１，２，３にセットする値に対応させる。

あるいは、図７（ｂ）に示すTSPECのTS Infoフィールド７２が有するReservedフィールド７３を活用し、MACスーパーフレーム受信側での各トラフィックストリームのタイムアウト時間をミリ秒単位で指定してもよい。あるいは、TSPECに新規のフィールドを拡張し、タイムアウトの指定を行う情報を追加してもよい。

（第３の実施形態）
第３の実施形態に係る通信装置は、複数の優先度のMACフレームを１つの物理フレームにアグリゲートして送信した後、受信側からの部分応答情報を元に、優先度毎にウインドウサイズ(一度に送信可能な最大数)の変更を行い、MACスーパーフレームを再送する通信装置である。

図８に示すように、１つの物理フレームに複数の優先度のMACフレーム(MPDU)を詰め込み、ＭＡＣスーパーフレーム８０として送信したとする。図８の例では、ウィンドウ８１，８２，８３のそれぞれのウインドウサイズ(一度に送信可能なフレーム数)が優先度毎に定義されており、高優先度（例えばＶｏＩＰ）を「3」、中優先度（例えばＶｉｄｅｏ）を「3」、低優先度（例えばｆｔｐ）を「2」としている。また、MACスーパーフレーム８０にアグリゲート可能なMACフレームの最大数は、送受信端末間で予めネゴシエーションを取ったことを前提とし、例えば８個であったとする（このネゴシエーションは、ビーコンを利用しても良いし、トラフィックストリームセットアップ時に行なっても良い。ネゴシエーションの方法に関しては、特に規定しない）。もちろん、この数は状況に応じて可変である。そして、図９に示すように、パーシャル(Partial)ACK（部分応答）９０に基づくMACスーパーフレームの再送が行われる場合を考える。すなわち、パーシャルACK９０内のパーシャルACKビットマップ９１によると、高優先度の先頭のフレームは正常に受信されなかったためにシーケンス番号「1」のフレームのみが再送対象とされる。一方、中優先度、低優先度のフレームは、正常に受信できており再送が要求されていないことから、それぞれのウインドウ８２，８３の始点を移動してウィンドウサイズに相当する数の新たなフレームをアグリゲートでき、再送のためのMACスーパーフレーム９２が作成される。ここで、アグリゲート可能なMACフレームの最大数は上述のように８個であるものの、図９のように作成されたMACスーパーフレーム９２が含むMACフレームは６個であり、チャネル利用率が最大限まで活かされていない。これは、優先度毎のウインドウサイズを常に固定としていることによる。

そこで本実施形態では、MACスーパーフレーム受信端末からの部分応答を元に、優先度毎のシーケンス番号の始点を移動させると共に、ウィンドウサイズの大きさを適応的に変更する。これにより、MACスーパーフレームの伝送効率を高めることができる。

例えば図１０に示すように、高優先度のフレームは１つしか詰めることができないが、MACスーパーフレーム全体においてアグリゲート可能な数には余裕がある。そこで、アグリゲート可能な最大数を上限とし、中優先度のフレームをアグリゲートする数をできるだけ増加させる。図８の段階では、中優先度の送信可能な初期値は３個であったが、高優先度のフレームを１つしか送れないことから、中優先度のウィンドウ１００のウインドウサイズを３個から５個に拡大する。

したがって、本実施形態に従い作成されるMACスーパーフレーム１０１には、アグリゲート可能な最大数に相当する８個のフレームがアグリゲートされ、図９に示したように６個のフレームがアグリゲートされるMACスーパーフレーム９２よりも伝送効率を高めることができる。

再送処理が行なわれた結果、高優先度のフレームが多く送信できるようになれば、再び各優先度のウィンドウサイズを初期値(この例では、高優先度を「3」、中優先度を「3」、低優先度を「2」)に戻し、MACスーパーフレームにQoSデータをアグリゲートする。

（第４の実施形態）
第４の実施形態はブロックＡＣＫに関する。図１１に標準的なブロックACKのシーケンス（即時型）を示す。一方、IEEE802.11eでは、図１２に示すように、MACヘッダー１２０にQoS Controlフィールド１２１が追加されており、ACK Policy１２２を指定することで、No ACK(ACKを必要としない伝送)、Block ACK、Normal ACK(通常のACK)などの様々な応答パターンを実現することができる。ここで、Block ACKに指定されたQoSデータに関しては、図１１に示すように、SIFS(Short Inter Frame Space)間隔で送信された後、ブロックACK要求１１０が送信される。送信端末は、ブロックACK要求に応じた宛先端末からのブロックACK１１１を受信する。ブロックACK要求１１０とブロックACK１１１は、それぞれ、TID(Traffic Identifier)優先度毎に用意する必要がある。

［ブロックＡＣＫのアグリゲーション例１］
ブロックＡＣＫのアグリゲーション例１は、SIFS間隔で送信するブロックACK対象のQoSデータフレームを１つの物理フレームにアグリゲートして送信するというものである。

例えば図１３に示すように、MACスーパーフレームヘッダー１３０に続き、ACK PolicyがBlock ACKであって同一宛先、同一TIDを有するQoSデータに限定されたMACフレーム１３１がアグリゲートされる。

図１４に示すように、まずTID1についてのQoSデータがアグリゲートされたMACスーパーフレーム１４０が送信される。続いてSIFS後にTID2についてのQoSデータがアグリゲートされたMACスーパーフレーム１４１が送信される。そのSIFS後にTID1についてのブロックACK要求１４２が送信され、さらにSIFS後にTID1についてのブロックACK１４３の受信が行われる。TID1についてのブロックACK１４３のSIFS後に、TID2についてのブロックACK要求１４４が送信され、さらにSIFS後にTID2についてのブロックACK１４５の受信が行われる。尚、ブロックACK要求を送信するタイミングは、対応するTIDのQoSデータを送った後であれば、特に限定する必要はない。すなわち、図１４において、MACスーパーフレーム１４０を送信した後、SIFS後に、ブロックACK要求１４２を送信することもできる。

このようなブロックＡＣＫのアグリゲーション例１によれば、ブロックACK対象の複数のQoSデータフレームを１つのMACスーパーフレームにアグリゲートして送信することにより伝送効率を向上できる。

［ブロックＡＣＫのアグリゲーション例２］
ブロックＡＣＫのアグリゲーション例２は、図１５に示すように、SIFS間隔でバースト的に送信するブロックACK対象のQoSデータフレーム１５０を１つの物理フレームにアグリゲートすることのみならず、ブロックACK要求フレーム１５１をも１つの物理フレーム（MACスーパーフレーム）にアグリゲートするというものである。

MACスーパーフレームのアグリゲート最大数を例えば８個とする場合（最大アグリゲート数を予めネゴシエーションを通じて認識したことを前提）、ブロックACK対象の７個のQoSデータをアグリゲートし、それに対するブロックACK要求フレームが末尾に添付される。MACスーパーフレームヘッダーのMPDU Lengthフィールド１５２に基づいて、ブロックACK要求フレーム１５１は受信側で適切に処理される。ここで、ブロックACK要求は、QoSデータよりも前方部にアグリゲートすることはできない。なぜなら、ブロックACK要求フレーム１５１に示されるように、Block ACK Starting Sequence Controlフィールドによって、QoSデータの受信ステータス対象の開始シーケンス番号を決定するため、QoSデータの処理（誤り計算）を前もって行う必要があるからである。

本例のブロックＡＣＫシーケンスを図１６に示す。ブロックACK対象の複数のQoSデータフレームに加え、ブロックACK要求がさらにアグリゲートされたMACスーパーフレーム１６０、１６１とすることにより、伝送効率を向上できる。

［ブロックＡＣＫのアグリゲーション例３］
ブロックＡＣＫのアグリゲーション例３は、複数のTID毎に存在するQoSデータフレームおよび対応するブロックACK要求をまとめて１つの物理フレームにアグリゲートして送信するというものである。

図１７に示すように、異なるTIDについてのブロックACK対象QoSデータ１７０，１７１と、これらに対応するブロックACK要求１７２，１７３とを１つの物理フレームアグリゲートしてMACスーパーフレームを作成する。図１８に示すように、作成されたMACスーパーフレーム１８０を伝送することにより、伝送効率を一層改善することができる。

［ブロックＡＣＫのアグリゲーション例４］
ブロックＡＣＫのアグリゲーション例４に係る通信装置は、ACKを必要としないNo ACKポリシーのMACフレームと、バースト的に送信されたMACフレームに対応する一つの応答（ブロックACK）を必要とするブロックACKポリシーのMACフレームとが混在するMACフレームアグリゲーションを行うものである。

図１９に示すように、本例のMACスーパーフレームはMACスーパーフレームヘッダーにおいてビットマップID(Bitmap ID)フィールド１９０、Length（ビットマップ長）フィールド１９１、可変長のビットマップ(Bitmap Information)１９２を有する。Bitmap ID１９０には、ビットマップ種別(Bitmap element)がNo ACKポリシーとブロックACKポリシーとの複合ポリシーであることを識別するための識別子(ID)が記載される。Lengthフィールド１９１には、Bitmap Information１９２の長さが例えばバイト単位で記載される。

Bitmap Information１９２には、MACスーパーフレームにアグリゲートされた複数のMACフレームにおいて、どのMACフレームがNo ACKであり、どのMACフレームがブロックACKであるかを識別するための情報が記載される。図１９に示すフレームアグリゲーション例では、例えば全部で８個のMACフレームがアグリゲートされており、そのうちブロックACKを必要とするフレームは３つ（QoS Data1〜3）であり、ACKを必要としない(No ACK)のフレームが５つ（図１９では QoS Data 1,2のみが示される）である。

この場合、ブロックACKを必要とするためのビットを例えば１とすると、ビットマップ情報(Bitmap Information)１９２は「11100000」となり、送信側でセットされる（なお、ビットを負論理としてもよいことは言うまでもない）。受信端末は、このようなビットマップ情報１９２に基づいてブロックACKを作成し、送信端末に返信する。

例えば図２０に示すように、MACスーパーフレーム２００２が送信端末から送信され、該MACスーパーフレーム２００２に続いてブロックACK要求２００３が送信端末から送信されたとする。受信側端末は、MACスーパーフレーム２００２においてブロックACKを必要とするMACフレームはMACスーパーフレーム２００２の前半の３つであり、残りの５つのMACフレームはACKが必要でないことを同MACスーパーフレーム２００２に含まれるビットマップ情報２００１から判断する。受信側端末は、送信端末からのブロックACK要求２００３に応じ、この情報をブロックACK２００４を返す。

ブロックＡＣＫのアグリゲーション例４によれば、ACKポリシーが異なるMACフレームのアグリゲーションにより伝送効率を向上できる。なお、ビットマップ情報は、本例のように必ずしも可変長である必要はなく、固定長としてもよい。この場合、Length情報は不要となる。

尚、ブロックＡＣＫのアグリゲーション例４は、QoSデータとブロックACK要求とのフレームアグリゲーション、あるいは複数TID毎のQoSデータとブロックACK要求とのフレームアグリゲーションと組み合わせて実施可能であり、これらの場合においてNo ACKとBlock ACKの双方のACK Policyをサポートした伝送を実現することができる。

（第５の実施形態）
第５の実施形態に係る通信装置は、トラフィックストリームのMSDUサイズを固定にして１つの物理フレームに複数のMPDUをアグリゲートする際に、MPDUの個数を示す情報をMACスーパーフレームヘッダーに含めるよう構成される。

IEEE802.11eでは、HCCAを用いた通信を行う際、QoS STA(QSTA)は、QoS AP(HC: Hybrid Coordinator)にトラフィックストリームをセットアップする。図２１はトラフィックストリームのセットアップ時に用いられるTSPEC(Traffic Specification)２１０を示している。TSPECはNominal MSDU Size（名目のＭＳＤＵサイズ）フィールド２１１を有する。同フィールド２１１は２バイト長であり、１５ビットのSize（サイズ)サブフィールド(MSDUの長さを指定)２１２と、１ビットのFixed(固定指定)サブフィールド２１３とが存在する。Fixedサブフィールド２１３が「1」に指定されていれば、そのTSIDで示されるデータフレームのMSDU(MAC Size Data Unit)はSizeサブフィールド２１２に記載された固定長となり、それ以外の大きさのフレームは送信することができない。

MACスーパーフレームにアグリゲートされたMPDU(MAC Protocol Data Unit)のサイズを可変長とする場合、それぞれの区切りを識別するためのMPDU Lengthフィールドが必須であるが、トラフィックストリームセットアップ時に、MSDUの長さが固定長であることを事前に通知すればMPDU Lengthフィールドを省略し、これに代えてアグリゲートされたMPDUの個数とすることができる。したがって、MPDU Lengthフィールドが格納されるMACスーパーフレームヘッダーのサイズを削減できる。

図２２は第５の実施形態に係り、ＭＰＤＵ長を固定長とするＭＡＣスーパーフレームを示している。ＭＡＣスーパーフレームヘッダー２２０内の、アグリゲートされたMPDUの個数を表すフィールド(図２２ではAggregation Numberフィールド)２２１に基づき、MPDU1,2,3...をそれぞれ取り出すことができる。尚、図２２の例では、MACスーパーフレームにアグリゲートするのは、TSID２２２の値が同一であるものとしている。

MPDUは、MSDUにMACヘッダー(IEEE802.11eの場合はQoS Controlフィールドを含む)を追加したものであるが、MACスーパーフレームの受信端末は、まずMACスーパーフレームヘッダーの誤り計算(Header CRC２２３を利用)を行い、正しく受信できていれば、TSIDフィールド２２２から、そのMACスーパーフレームヘッダーにアグリゲートされているMPDUのTSIDを判断する。TSID情報を取得すれば、トラフィックストリームのセットアップを通じて、MSDUの固定長が検出される。一方、各MPDUの長さ（固定長）は、Nominal MSDU Length(Fixed)とQoS Controlフィールドを含むMACヘッダー長との和に相当する。受信端末は、各MPDUの各々の受信状態を判定し、その結果をもとに部分応答(パーシャルACK)を作成してMACスーパーフレームの送信端末に対し返信する。

例えばFTP(File Transfer Protocol)などのTCP(Transmission Control Protocol)アプリケーションでは、通信の終了間際(ファイルをダウンロードし終わる時期)になるとデータフレームの長さが短くなる場合がある。トラフィックストリーム上で固定長のNominal MSDU Lengthが指定されているとMAC層でフレームを送受信できなくなるが、この場合はMSDUを作成する際に、「0」のビット列を後部にパディング(追加)して長さを固定長にする。受信側では、MACよりも上位層においてIPヘッダーのLengthフィールドなどを用い、正しい長さのペイロードを取り出す。MSDUの長さは、トラフィックストリームのセットアップ時に指定された固定長であるため、MAC層における通信は正しく行える。

さて、複数のトラフィックストリームがセットアップされ、トラフィックストリームのそれぞれに対応するNominal MSDU Lengthフィールドが全て固定長に指定されているならば、一つのMACスーパーフレームを複数の異なるTSID(Traffic Stream Identifier)のMPDUをアグリゲートによるものとし、１つの物理フレームとして送信することが可能である。

本実施形態に係る他の通信装置は、複数のトラフィックストリームのそれぞれ固定長に指定されたMACフレームを１つの物理フレームにアグリゲートし、それらのトラフィックストリーム識別子を示す情報とトラフィックストリーム毎のアグリゲートしたMPDUの個数を示す情報とをヘッダーに含めて送信する通信装置である。

図２３はこのような複数TSIDの混在時の固定長MACフレームのアグリゲーションを示す図である。本例では、MACスーパーフレームヘッダー２３０中に、アグリゲートされたTSIDの数を示すフィールド(Number of TSID)２３１が追加される。また、MACスーパーフレームヘッダー２３０は、TSIDと該TSIDについてアグリゲートされたMPDUの個数を示すフィールドとからなる組（ペア）をTSIDの数に応じて有する可変長フィールド２３２を有する。

このようなMACスーパーフレームを受信した端末側では、アグリゲートされたTSIDと各MPDUの個数とをMACスーパーフレームヘッダー２３０に基づいて検知する。固定長を有するMPDU長については、トラフィックストリーム毎に、上述と同様に固定MSDU長とMACヘッダー(QoS Controlフィールド含む)との合計値として算出する。また、上述したFTPのようなTCPアプリケーションの場合のように、上位層からのデータフレームの長さが短くなる場合には、MSDUの後半部に「0」をパディングして長さを固定長にすればよい。このようにしても、IPヘッダーのIPデータグラム長を示すフィールドの値は書き換えないため、上位層のデータペイロードに影響を与えることはない。尚、MACスーパーフレームの形式は、MACスーパーフレームヘッダーのMPDU Lengthフィールドを用いて、それぞれ長さの異なるMPDUをアグリゲートしても良いし、本実施形態のように、固定長のMPDUをアグリゲートして、その個数を示す情報をMACスーパーフレームヘッダーに付加しても良い。MACスーパーフレームヘッダーがどちらの形式を取るかは、送受信機の間で予めネゴシエーションを行なっておくことを前提とする（具体的なネゴシエーション方法については、本実施例の対象外としている）。

以下、第６乃至第１１の実施形態は、複数の宛先を対象とする複数のMACフレームのアグリゲーションに係わり、サイマルキャスト送信を行うものである。

無線ＬＡＮのＭＡＣ層において、一般的には１つのＭＡＣフレームを１つの宛先端末に向けて送信することを「ユニキャスト」といい、また、複数の宛先を受信対象とする１つのＭＡＣフレームを送信することを「マルチキャスト」という。これに対し本発明の実施形態の説明においては、複数のＭＡＣフレームを１つの物理フレームにアグリゲートし、複数の宛先を受信対象として送信することを「サイマルキャスト」と呼ぶことにする。

ここで、単純に複数の宛先のＭＡＣフレームを１つの物理フレームにアグリゲートし、APから各STAに向けて、サイマルキャストすることを考える。この場合、サイマルキャストされたＭＡＣスーパーフレームに対する各受信端末からのパーシャルACKフレームが衝突し、通信が正常に行えなくなってしまうという問題がある。IEEE802.11の規定によると、ユニキャストデータフレームを受信したSTAは、チャネル状態を確認することなく、SIFS期間が経過したら直ちにACKフレームを返信する。したがって、複数のSTAからのACKフレームが衝突する可能性は高い。

そこで、本発明の実施形態に係る通信システムでは、複数の宛先を含んだＭＡＣスーパーフレームをAPからSTAに対してサイマルキャストし、各STAがAPに対しACKフレームを送信するにあたり、他のSTAからのACKフレームとの衝突を回避するよう、それぞれ送信タイミングをずらすことが好ましい(これを時間差ACKという)。

他の端末が時間差的にパーシャルACKを返信している間は、各端末により適切にNAVを設定して、データフレーム等の送信を停止する。尚、このNAVの期間は、(残りの端末数×(SIFS+ACK転送時間))で決定される。また、本発明の実施形態においては、各STAからのACKの転送レートが同一であることを仮定しているが、もしACK転送レートがSTA毎に異なる場合は、それぞれに対応したACK転送時間を計算することが好ましい。

（第６の実施形態）
第６の実施形態に係る通信装置は、複数の宛先に対するMACフレームを１つの物理フレームにアグリゲートして送信する際に、それぞれのMACフレームの前方部に、該MACフレームが何番目の宛先に対応するかを示す情報を付加する。

複数の宛先に対するMACフレームを１つの物理フレームにアグリゲートして送信する場合、MACスーパーフレームヘッダーに各宛先の区切りを示す情報（マルチアドレスビットマップ(Multi Address Bitmap)）を付加することが考えられるが、本実施形態では、図２４に示すように、それぞれのMPDU(MAC Protocol Data Unit)の前方部に１バイト程度の大きさの付加フィールド２４０を追加し、マルチアドレスビットマップに代える。付加フィールド２４０には、それぞれ、当該MPDUが何番目の宛先であるかを示す情報（POS(ition)フィールドという）を記載する。

マルチアドレスビットマップ(Multi Address Bitmap)は、宛先の異なる複数の媒体アクセス制御フレームを含む物理フレームを構築する際に、該物理フレーム内の媒体アクセス制御フレームのうち先の媒体アクセス制御フレームの宛先と比べてその宛先が変化するフレームの含まれる位置に関する情報を表す。具体的には、アグリゲートされた媒体アクセス制御フレームの各々に対応するビットからなり、複数の宛先の区切りを示す。

図２４の例は、8個のMPDUをアグリゲートした場合であるが、この数は固定されたものではない。例えば図２４の例では、宛先(DEST)「α」へのMACフレームが先頭から４個目までアグリゲートされており、それぞれの前方部に付加されたPOSフィールドには、１番目の宛先であることを示す「1」という情報が追加される。続く宛先βへのMACフレームの前方部のPOSフィールドには、２番目の宛先であることを示す「2」という情報が記載される。ここで、もし全てのPOSフィールドの値が「1」であるならば、MACスーパーフレーム中には１つの宛先へのMACフレームしかアグリゲートされていないことを意味する。

MACスーパーフレームヘッダーがMPDU Lengthフィールドを有する場合、これには各MACフレームの長さが記載され、MACスーパーフレームペイロード中にアグリゲートされたデータフレームを長さに基づいて切り出すことができる。一方、POSフィールドがMPDUの前方部に付加された本例の場合、MPDU Lengthフィールドには、(POSフィールド(今回は１バイト) + MPDU長)の値を記入する。また、FCS(Frame Check Sequence)では、POSフィールドから、MACヘッダー、MACフレームボディまでの誤り検出を行なう。

MACスーパーフレームヘッダー中のMulti Address Bitmapによれば、複数の宛先のMPDUの存在を判断できるが、Multi Address Bitmapに依らないフォーマットとすることができる。例えば図２５に示すように、MACスーパーフレームヘッダー２５０中に、アグリゲートされた宛先数を示すNumber of Destinationsフィールド２５１を追加する。このフィールド２５１の値が１であるならば、MACスーパーフレーム中には１種類の宛先しか存在しないことになる。その後ろに続くDestinationフィールド２５２とPOSフィールド２５３は、それぞれ、宛先のアドレスと何番目の宛先であるかを示す。例えば図２５の例では、MACスーパーフレームに、宛先が「α」であるMPDUと、宛先「β」へのMPDUがアグリゲートされていたとする。Number of Destinationsフィールド２５１は、２つの宛先が存在することを示すために、「2」という値が記載される。Destinationフィールド２５２とPOSフィールド２５３は、固定長でそれぞれ６バイト(MACアドレス分)、１バイトとしている。図２５の例のDestination 1フィールドでは、宛先αのMACアドレスが記載され、POS 1フィールドには、宛先αが何番目の宛先として存在するかを示す情報が記載されている。Destination 2フィールドでは、宛先βのMACアドレスが記載され、POS 2フィールドには、宛先βが何番目の宛先として存在するか(本例では２番目)を示す情報が記載される。

なお、MACスーパーフレームヘッダー２５０中のDestinationフィールド２５２を、アグリゲートしたMACフレームの順番通りに記載することを前提としている場合は、POSフィールド２５３は不要である。

（第７の実施形態）
第７の実施形態に係る通信装置は、複数の宛先に対するMACフレームを１つの物理フレームにアグリゲートして送信する際に、複数宛先の回線利用期間をMACスーパーフレームヘッダー中に含めるものである。

複数宛先に対してMACスーパーフレームをサイマルキャストする場合、各宛先から時間差的に送信されるACKは、全て同一の回線使用期間(Duration)であることを前提とする必要はない。

第７の実施形態は、各ACKが可変長である場合であり、図２６に示すように、宛先毎の回線使用期間(Duration1, Duration2)２６１がMACスーパーフレームヘッダー２６０中に記載される。通常、IEEE802.11の規格において、ユニキャストデータMACフレームのDurationフィールドには、(SIFS(Short Inter Frame Space)時間＋ACK転送時間)が記載される。尚、ACK転送時間は、IEEE802.11の手続きに従い、BSS Basic Rate Setの最大物理伝送レート、ACKフレーム長により計算する。なお、図２７に示すように、MACスーパーフレームヘッダー２７０を構成してもよい。この場合、マルチアドレスビットマップを含まず、宛先(Destination)とともに回線使用期間が記載される。MACスーパーフレーム中にアグリゲートするMPDUが宛先毎であるという前提であれば、MACスーパーフレームヘッダー２７０のDestinationフィールドは特に必要ない。

MACスーパーフレームに対するパーシャルACK応答は、アグリゲートされたMPDUの数に比例してサイズが大きくなる。例えば、MACスーパーフレームにアグリゲートするMPDUの数が８個までなら、パーシャルACK応答のパーシャルACKビットマップは１バイトの大きさで済むが、アグリゲートされたMPDUの数が９個以上(１６個以内)になると、パーシャルACKビットマップは２バイトの大きさが必要となる。すなわち、MACスーパーフレーム送信端末は、宛先毎に幾つのMPDUをアグリゲートして送信するかの情報により、宛先からの時間差的なACKの各転送時間を推測することができる。

例えば図２８のように、DEST1、DEST2という２つの宛先に対し、１６個のMPDUをアグリゲートして送信する場合を考える(DEST1に１３個、DEST2に３個)。各宛先が作成するパーシャルACK応答の長さは異なるため、それぞれに対応したDuration値２８０、２８１が決定される。MPDUを13個アグリゲートしたDEST1への場合は、パーシャルACKビットマップが２バイトの大きさであり、MPDUを３個アグリゲートしたDEST2へは１バイトの大きさとなる。

図２８の例では、サイマルキャストされたMACスーパーフレームを受信後、DEST1の端末がSIFS後にパーシャルACK２８２を返信する。DEST2の端末は、自分の宛先が２番目に存在しており、Duration 1の値(DEST1がパーシャルACKを送信終了するまで)＋SIFS時間待機した後、自身のパーシャルACK２８３を送信する。DEST1は、パーシャルACK２８２を送信し終えてから、残りのDuration値の合計に相当するNAV(Network Allocation Vector)２８４を設定する。また、MACスーパーフレーム中に、自分の宛先が存在しない端末は、MACスーパーフレームヘッダーのDurationフィールドの合計値分のNAVを設定する。図２８の例では、DEST1、DEST2以外の端末(OTHER STA)は、MACスーパーフレームヘッダーのDurationの値の合計（ここではDuration 1の値とDuration 2の値を加算した値）に相当するNAV２８５を設定する。

図２９は、受信端末の動作を示すフローチャートである。複数の宛先を持つＭＡＣスーパーフレームを受信した後（ステップＳ１）、受信端末はＭＡＣスーパーフレームのヘッダーに対する誤り計算を行う（ステップＳ２）。この誤り計算の結果、エラーであれば、ＭＡＣスーパーフレームを廃棄し（ステップＳ３）、チャネルがアイドルになった後、EIFS(Extended Inter Frame Space)の期間キャリアセンスを行う（ステップＳ４）。

ヘッダーが誤りでなければ、各ＭＡＣフレームに対するエラーチェックを実施する（ステップＳ５）。次に、ＭＡＣスーパーフレーム内にアグリゲートされたＭＡＣフレームの宛先の数（Ｍ個）と、自端末のＭＡＣアドレスが何番目（Ｎ番目）の宛先として存在するかを検査する（ステップＳ９）。

例えばDEST1に該当する受信端末へのＭＡＣフレームは1番目にアグリゲートされており（Ｎ＝１）、この受信端末は通常のフレームアグリゲーションと同様のシーケンスで、SIFS期間（ステップＳ１５）後にパーシャルACKフレーム（あるいはブロックＡＣＫ）を送信する（ステップＳ１６）。その後、他の端末(DEST2、OTHER STA)が、時間差的にパーシャルACKを返信している間は、Duration 2〜Mの値の合計期間に対応するNAVを設定して、データフレーム等の送信を停止する（ステップＳ１７）。

2番目にアグリゲートされているDEST2は、DEST1がパーシャルACKを送信した後（ステップＳ１１）、SIFS期間が経過してから（ステップＳ１２）、パーシャルACKを送信する（ステップＳ１３）。そして自端末がパーシャルACKを送信した後は、Duration N+1〜Mの値の合計期間に対応するNAVを設定する（ステップＳ１４）。

ＭＡＣスーパーフレームに自端末を宛先とするＭＡＣフレームが存在しない場合は、Duration 1〜Mの値の合計期間に対応するNAVを設定する（ステップＳ７）。

図３０、図３１はそれぞれ、本発明を適用可能な無線通信システムの構成例を示している。１つの物理フレームに複数のMACフレームをアグリゲートする通信方式は、AP(もしくはIEEE802.11eのHybrid Coordinator)とSTAとの間のダウンリンクおよびアップリンク伝送、および、STAとSTAとの間(IBSS(Independent Basic Service Set)によるアドホック通信、IEEE802.11eのDLP(Direct Link Protocol)によるQSTA同士の通信に適用可能である。

（第８の実施形態）
第８の実施形態は、サイマルキャストを行う場合におけるブロックＡＣＫに関する。第８の実施形態に係る通信装置は、複数の宛先に対するブロックACK対象のMACフレームを１つの物理フレームにアグリゲートして送信し、宛先毎のブロックACK要求送信、ブロックACK受信処理を行う。本実施形態に係る別の通信装置は、複数の宛先に対するブロックACK対象のMACフレーム、並びにブロックACK要求フレームを１つの物理フレームにアグリゲートして送信し、複数宛先からのブロックACKを時間差的に受信する。

図３２に示すように、IEEE802.11eにおいて、ブロックACK対象のQoSデータフレームはSIFS間隔で送信される。

本実施形態では、複数宛先へのQoSデータフレームを１つの物理フレームにアグリゲートし、これにより伝送効率を高めるものである。図３３に示すように、MACスーパーフレームヘッダーに複数宛先の存在を示す情報が付加され、ペイロード部には、宛先毎に区切ってQoSデータフレームがアグリゲートされる。この時、MACスーパーフレームを前述の図２４、図２５のように構成してもよい。あくまで複数宛先の存在と、その相対的な位置がMACスーパーフレーム受信端末側で判断できればよい。図３３の例では、Multi Address Bitmap３３１を使用している。

そして図３４に示すように、複数宛先へのブロックACK対象QoSデータフレームを１つの物理フレームにアグリゲートしてＭＡＣスーパーフレーム３４０として送信することで、伝送効率を高めることができる。図３４には、ＭＡＣスーパーフレーム３４０に続くブロックＡＣＫ要求３４１，３４２に応じ、各宛先(QSTA1, QSTA2)からブロックＡＣＫ３４３、３４４が送達される様子が示されている。

さらに、図３５に示すように、データフレームのみならず、ブロックACK要求３５０，３５１をもアグリゲートすることも好ましい。この場合、宛先毎に区切ってアグリゲートを行い、各フレーム(データ、ブロックACK要求)のフレームサイズを記載することで、データフレームを適切に取り出し、ブロックACKの時間差的な送信を行うことも可能になる。図３６の例では、QSTA1へのデータフレーム３つと、QSTA1に対するブロックACK要求、QSTA2へのデータフレーム３つと、QSTA2に対するブロックACK要求を有するＭＡＣスーパーフレーム３６０を作成し、これを１つの物理フレームとしてHCからQSTA1,2にサイマルキャストしており、各QSTAからのブロックACK３６１，３６２を時間差的に受信することで、システム全体の伝送効率を向上させている。

（第９の実施形態）
第９の実施形態に係る通信装置は、ある宛先に対する複数のMACフレームを１つの物理フレームにアグリゲートして送信する際、この宛先の端末がSIFS期間後にACKを送信できない場合に、予め多めに設定したNAV期間内に、再度ACKフレームを送信できるようにする通信装置である。

本実施形態に係る別の通信装置は、ある宛先に対する複数のMACフレームを１つの物理フレームにアグリゲートして送信する際、この宛先の端末がSIFS期間後にACKを送信できない場合、１つの物理フレームに他の宛先へのMACフレームをアグリゲートして送信することで、ACKフレームを時間差的に送信できるようにする通信装置である。

さらに、本実施形態に係る別の通信装置は、複数の宛先に対する複数のMACフレームを１つの物理フレームにアグリゲートして送信する際、１番目にアグリゲートされた宛先がMACスーパーフレームを受信してからSIFS期間後にACKを送信できない場合、予め多めに設定されたNAV期間内に、１番目の宛先から順番にACKフレームを送信する通信装置である。

第９の実施形態では、通信装置において、復号処理に時間の掛かるターボ符号やLDPC(Low Density Parity Check)符号が採用された場合、IEEE802.11で定められているSIFS(Short Inter Frame Space)期間中に処理が間に合わないことに対処するものである。ある宛先に対し複数のMACフレームが１つの物理フレームにアグリゲートして送信された後、当該宛先端末は、SIFS期間後にACKを返信しなくてはならないが、復号処理のためACKが送信できない場合が起こり得る。

この場合、図３７に示すように、宛先以外の端末に対して設定するデュレーションの値を多めに設定することで、宛先端末が再度ACKフレームを送信する機会を与えるようにする。宛先以外の端末は、デュレーションで定められる期間のNAV(Network Allocation Vector)３７０を設定し、送信を停止しているため、宛先端末がACKフレームの送信をしても、衝突が生じることはない。なお、ある宛先が一般的に処理時間の掛かる符号化処理を行っていて、SIFS期間後にACKを返せないことが予想される場合、その旨をBSS(Basic Service Set)内の他端末に予め通知しておく。図３７の例では、１つの宛先に対してのみMACフレームをアグリゲートしている。宛先以外の受信端末は、MPDUに記載されているデュレーションの例えば２倍の期間NAVを設定する。ここで、２倍という数値は特に固定された値ではなく、無線端末間でデュレーションの期間を通知しあってもよい。また、MACスーパーフレーム送信端末側で、MPDUのデュレーションフィールドに適切な値を記載してもよい。

図３７のような状態（すなわちMACスーパーフレームに１種類の宛先のMACフレームのみをアグリゲートしている状態）では、一般に復号処理時間が多く掛かることも考えられる。この場合、図３８に示すように、複数宛先のフレーム(例えばDEST2,DEST3宛てのフレーム)をアグリゲートすれば、１番目の宛先の端末がSIFS期間後にACKを送信できる可能性が高まる。これは、シンボル単位で符号化処理を行うことを前提とし、MACスーパーフレーム全体の中で、１番目の宛先のフレーム（図３８の例ではMPDU３つ分）を復号する時間だけであれば、一般に、より少ない処理時間でACKを送信することができるからである。

ここで、複数宛先へのMACフレームを１つの物理フレームにアグリゲートして送信した場合、１番目の宛先がどうしてもACKをSIFS期間後に送信できない場合を考える。このような状況では、SIFS期間でACKを送信できない旨の情報を予め他端末との間で通知しあう必要がある。図３９に示すように、１番目にアグリゲートされた端末以外の端末DEST2,DEST3, OTHER STAは、通常より多くのNAV３９０，３９１，３９２を設定する。多めに設定するNAVは、(SIFS+１番目の宛先がACKを送信する時間)に相当する。図３９の例では、他の端末が予め多くのNAVを張っているため、１番目の宛先は、MACスーパーフレームを受信してから、SIFS期間後にACKを返信できない場合でも、再度ACK３９３を送信することが可能である。なお、図３９の例では、他の全ての端末がACKを送信し終わった後に１番目の宛先がACKを送信しているが、図４０のように、１番目の宛先から順番にACK４００，４０１，４０２を送信することとしてもよい。

（第１０の実施形態）
第１０の実施形態はＡＣＫの送信時点（タイミング）を指定するものに関する。第１０の実施形態に係る通信装置は、複数の宛先に対するMACフレームを１つの物理フレームにアグリゲートして送信し、各宛先端末に対し、ACKを送信する時間を指定する情報をMACスーパーフレームヘッダーに含める。

ACKを送信するタイミングをMACスーパーフレームの受信端末側で計算することに代えて、本実施形態はMACスーパーフレーム送信側で、予めACKを送信する時点を指定するよう構成される。ACKを送信する時点を送信側で指定する場合のフレームフォーマットを図４１乃至図４４に示す。

図４１および図４２は、それぞれのMACスーパーフレームヘッダー４１０、４２０中に、ACK送信タイミングの時間指定情報が含まれる例である。ACK Transfer Start Timeは、各宛先がACKを送信すべき時点を示す。具体的には、MACスーパーフレームを受信した後、SIFS+N(μ秒)後にACKを送信することとし、Nの値がACK Transfer Start Timeに記載されている。この場合、先頭の宛先に対するACK Transfer Start Time 1は、「0」が指定されている。あるいは、MACスーパーフレームを受信してから、Nμ秒後にACKを返信するといったような指定方法を行なってもよい。２番目以降の宛先のACK送信タイミングは、パーシャルACKのサイズ、物理伝送レート、何番目の宛先であるかの情報を用いて、送信側で計算する。Transfer End Timeは、全てのACKが送信し終わる予定時刻を示す。これは、MACスーパーフレームを受信してから何μ秒後に全てのACKが送信し終わるかの情報である。尚、図４１のMACスーパーフレームヘッダー420のDestinationフィールドは、各MPDUが宛先の順序通りにアグリゲートされていれば必要ないが、それ以外（アグリゲートされたMPDUの順番がばらばらである場合）などには必要な情報である。

図４３は、MACスーパーフレームにアグリゲートされたMPDUの前方部に、ACK Transfer Start Time４３０、Transfer End Time４３１を付加したもので、この場合、MPDU Lengthフィールドの値は、ACK Transfer Start Time４３０とTransfer End Time４３１のフィールド長だけ増える。図４４は、MACスーパーフレームにアグリゲートされたMPDUの前方部に、ACK Transfer Start Time４４０を付加し、MACスーパーフレームヘッダー４４１に一つのTransfer End Time４４２を付加するものである。図４３では、MACスーパーフレームペイロード中のFCS計算は、Timeフィールド、Endフィールド、MACヘッダー、MACフレームまでを対象として行われる。図４４では、Timeフィールド、MACヘッダー、MACフレームまでがFCSの計算対象である。

図４５に示すように、DEST1の受信端末はACK Transfer Start Time４５０にACK(Partial ACK)４５５の送信を開始するとともに、同ACK送信後にTransfer End Time４５２までのNAV４５３を設定する。DEST2の受信端末はACK Transfer Start Time４５１にACK(Partial ACK)４５６の送信を開始する。同ACK４５６の送信終了時点はTransfer End Time４５２に一致しており、NAVの設定は行わない。フレーム受信の対象ではない他の端末(OTHER STA)はTransfer End Time４５２までのNAV４５４を設定する。

（第１１の実施形態）
第１１の実施形態に係る通信装置は、複数の宛先に対するACK必要、不必要のMACフレームを優先度毎に束ねて１つの物理フレームにアグリゲートして送信する。各宛先端末は時間差的にACKを送信する。

図４６に示すように、MACスーパーフレームヘッダー４６０はマルチアドレスビットマップ(Multi Address Bitmap)４６１とACKポリシービットマップ(ACK Policy Bitmap)４６２の双方を含む。各受信端末は、マルチアドレスビットマップ(Multi Address Bitmap)４６１に基づくことで適切にNAVを設定し、ACKの送信タイミングを算出できる。一方、ACKポリシービットマップ(ACK Policy Bitmap)４６２によれば、ある宛先宛のMPDUが全てNo ACK Policyであるならば、その宛先はACKを送信しないため、続く宛先端末がACKを送信する、といったACK制御を行える。

例えば図４７に示すように、DEST 2に対するMPDUは全てNo ACK Policyであるため、DEST 3は、DEST 1がACK４７０を送信し終えた後に、ただちにACK４７１を送信できる。DEST 2の端末は、全てのACKが送信し終わるまでNAV４７２を設定する。尚、図４６に示すMACスーパーフレームのヘッダー構成はあくまで一例であり、上述したヘッダーフォーマットを適宜組み合わせたり、ACKの送信タイミングを指定したりすることで、効率向上を図ることができる。

（第１２の実施形態）
図４８は本発明の第１２の実施形態に係る通信装置（アクセスポイント）の構成を示すブロック図である。この通信装置１００Ａは無線リンクを介して他の通信装置と通信する装置であり、物理層、MAC層、およびリンク層のそれぞれに相当する処理ユニット１０１Ａ、１０２Ａ、１０３Ａを有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはＬＳＩに組み込まれたＣＰＵにより実行されるファームウェア等として実現される。物理層の処理ユニット（以下、「処理ユニット」の表記を省略）１０１Ａにはアンテナ１０４Ａが接続されている。MAC層１０２Ａは本発明に係わるアグリゲーション（集約）処理部１０５Ａを有する。このアグリゲーション処理部１０５Ａはキャリアセンス制御部１０６Ａ、メディアアクセス制御部１０８Ａ、ポーリング・データ送信スケジュール制御部１０５１、再送制御部１０７Ａを備える。物理層１０１Ａは、二種類の物理層プロトコルに対応可能に構成される。それぞれのプロトコル処理のために、物理層１０１Ａは第一種の物理層プロトコル処理部１０９Ａおよび第二種の物理層プロトコル処理部１１０Ａを有する。なお、実装では第一種の物理層プロトコル処理部１０９Ａと第二種の物理層プロトコル処理部１１０Ａとの間で回路の共用などがしばしば行なわれるため、これらは必ずしも独立して存在するわけではない。

本発明の実施形態では、第一種の物理層プロトコルはIEEE802.11aに規定されるプロトコルとし、第二種の物理層プロトコルは送信側と受信側とでそれぞれ複数のアンテナを用いる、いわゆるMIMO(Multiple Input Multiple Output)によるプロトコルと仮定する。周波数帯域を同一に保ってもアンテナの数にほぼ比例した伝送容量の増加が見込めることから、MIMOはIEEE802.11の更なる高スループット化を目指すために利用可能な技術の一つである。リンク層１０３Ａに関しては、IEEE802で規定される通常のリンク層機能を有するものとする。伝送レートを向上するために採用する技術はMIMOに限定されない。例えば、周波数占有帯域を増やすような方法、およびそれとMIMOの組み合わせでも構わない。

図４９は本実施形態に係る通信装置（端末）の構成を示すブロック図である。図４８に示す通信装置（アクセスポイント）１００Ａとの大きな相違は、アクセスポイント１００ＡのMAC層１０２Ａはポーリング制御も行なうことができるポーリング・データ送信スケジュール制御部１０５１を持つのに対し、端末１００ＳのMAC層１０２Ｓはポーリング制御なしのデータ送信スケジュール制御部１０５２を持つ点である。他の構成要素についてはアクセスポイント１００Ａと同様であり、参照数字の末尾を「Ｓ」としている。

図５０は本実施形態に係る通信装置が用いるフレームフォーマットの一例を示す図である。フレームフォーマット２００は物理層およびMAC層に係わるフレーム構造を概略的に示しており、具体的にはIEEE802.11またはその拡張に従うものを想定する。なお、IEEE802.11のフレームは制御フレーム、管理フレーム、データフレームの三種類に大別され、本発明の実施形態においては主にデータフレームと制御フレームに適用されることを想定するが、必ずしも管理フレームへの適用が除外されるものではない。図５０に示すように、このフレームフォーマット２００はPHYヘッダー２０１と、MACスーパーフレームヘッダー２０２およびMACスーパーフレームペイロード２０３と、PHYトレーラ２０４とから構成されている。MACスーパーフレームヘッダー２０２およびMACスーパーフレームペイロード２０３は後述するPHYペイロードに相当する。

PHYヘッダー２０１は受信側通信装置（アクセスポイント、または端末）の物理層１０１により処理される。すなわち物理層１０１は受信したPHYヘッダー２０１に基づいて、フレーム先頭の検出、キャリアセンス、タイミング同期確立、増幅器の増幅度制御(AGC: Automatic Gain Control)、送信側キャリア周波数への追随(Automatic Frequency Control)、伝送路推定などを行う。また物理層１０１はPHYヘッダー２０１に続くPHYペイロードの変調方式や符号化率、ならびに伝送レートおよびデータ長の検出も行う。

図５１は第一種のPHYフレームのフォーマットの一例を示す図である。このフォーマットはIEEE802.11aに規定のものと同じである。第一種のPHYフレームは本発明に係る通信装置が既存の通信装置と通信する際に用いられ、物理層１０１の第一種の物理層プロトコル処理部１０９によって処理される（ここでは、IEEE802.11aによる通信とする）。図５１に示すように、第一種のPHYフレームすなわち第一種のPLCPフレームは、PLCP(Physical Layer Convergence Protocol)ショートプリアンブル３０１およびPLCPロングプリアンブル３０２と、シグナルフィールド３０３と、データフィールド３０４とから構成される。シグナルフィールド３０３は、ＰＣＬＰヘッダー３０５に相当し、同図に示すように伝送レート(Rate)フィールド３０６とデータ長(Length)フィールド３０７とを有する。なお、第一種のPHYフレームはIEEE802.11aに規定のもののみに限定されないことは言うまでもない。

図５２は第二種のPHYフレームのフォーマットの一例を示す図である。第二種のPHYフレームすなわち第二種のPLCPフレームは、第一種の物理層プロトコルのための第１のヘッダー部４０１と、第二種の物理層プロトコルのための第２のヘッダー部４０２とを有する。第１のヘッダー部４０１と第２のヘッダー部４０２とは時系列に沿って配置されており、図５０に示したPHYヘッダー２０１に対応する。

また、第二種のPHYフレームは第２のヘッダー部４０２に続くPHYペイロード４０３と、テイル(Tail)およびパッドビット(Pad bits)４０４とを有する。PHYペイロード４０３は図におけるMACスーパーフレームヘッダー２０２およびMACスーパーフレームペイロード２０３に対応しており、物理層のフォーマットにおけるPSDU(PLCP Service Data Unit)に相当する。また、テイルおよびパッドビット４０４は図５０のPHYトレーラ２０４に対応している。

第一種の物理層プロトコルのための第１のヘッダー部４０１は、PLCPショートプリアンブル４０５と、PLCPロングプリアンブル４０６と、シグナルフィールド４０７とから構成される。シグナルフィールド４０７はPLCPヘッダーの全部又は一部に相当し、少なくとも伝送レートフィールド４０８およびデータ長フィールド４０９には物理キャリアセンスを行えるように有効な値が設定される。このようなシグナルフィールド４０７は、図５１に示した第一種のPHYフレームのPLCPヘッダー３０５との間で対応する情報内容および変調方式などが同一である。

第二種の物理層プロトコルのための第２のヘッダー部４０２は、MIMOシグナルフィールド４１１と、MIMO用PLCPロングプリアンブル４１０と、MIMOサービスフィールド４１２とから構成される。MIMOシグナルフィールド４１１は、同図に示すように伝送レートフィールド４１３およびデータ長フィールド４１４を有し、物理キャリアセンスにおいて参照される。MIMO用PLCPロングプリアンブル４１０は、第二種の物理プロトコルを解釈可能なMIMOの受信側通信装置が、復号処理に必要な伝送路情報を取得する際に用いられる。

第二種のPHYフレームを図５２に示すようなフォーマットとしていることにより、第一種の物理層プロトコルのみに従って動作可能な既存の通信装置は、少なくとも最初のシグナルフィールド４０７は解釈できるので該シグナルフィールド４０７に基づいて正しく物理層のキャリアセンスを行える。したがって、このような既存の通信装置と、第一種に加え第二種の物理層プロトコルにも従って動作可能な通信装置との間で同一の物理層のキャリアセンス情報を共有することが可能となる。なお、既存の通信装置はMAC層のキャリアセンス情報は共有できないが、このことは、パーシャルＡＣＫにより問題とはならない。

物理媒体上をPHYペイロードが送信される際の該PHYペイロードによる媒体占有期間（以下、「物理的占有期間」という）を表す情報は、信号強度と共に物理層のキャリアセンス情報として利用される。受信側通信装置は、当該PHYペイロードの物理的占有期間を物理キャリアセンスにより知った時点で、該期間は物理媒体が占有されている(PHYビジー(busy))と解釈する。また、信号強度が一定の閾値を超えている期間も物理媒体が占有されていると解釈する。PHYペイロードの物理的占有期間は、受信側通信装置において検出されたPHYペイロードの伝送レート（４０８または４１３）とデータ長（４０９または４１４）とから計算により求めることができる。具体的には、オクテット長で表されるデータ長フィールドの値を伝送レートフィールドの値で除算することで求めることができる。これは図５１に示した第一種のPHYフレームについても同様である。
なお、第一種の物理層プロトコルが許容するPHYペイロードの最大データ長（IEEE802.11aにおいては４０９６オクテット）が、実際には第二種の物理層プロトコルの許容するPHYペイロードの最大データ長よりも短い場合には、PHYペイロードの物理的占有期間が適切となるように伝送レートフィールド４０８とデータ長フィールド４０９とを意図的に偽って設定すれば、物理層のキャリアセンス情報の共有が可能となる。

ここで、図５０を参照する説明に戻る。一つのMACスーパーフレームは複数のMACフレームを含む単一のPHYフレームから成る。同図に示すフレームフォーマット２００において、MACスーパーフレームヘッダー２０２は、８つのMACフレームのデータ長フィールド１〜８を固定的に持つ。なお、本実施形態ではMACスーパーフレームヘッダー２０２は固定長とするが、MACフレーム数を示す情報を追加することにより、MACスーパーフレームヘッダー２０２を可変長としても良い。

MACスーパーフレームペイロード２０３には例えば４つのMACフレーム１〜４のみが含まれる場合、同ペイロード２０３内には存在しないMACフレーム５〜８に対応するMACフレームデータ長フィールド５〜８にはゼロの値が埋められる。また、後述する再送制御の際に、例えば、MACフレーム１とMACフレーム３は再送が必要だが、MACフレーム２とMACフレーム４は再送の必要がない場合、MACフレームデータ長１＞０、MACフレームデータ長２＝０、MACフレームデータ長３＞０、MACフレームデータ長４＝０という具合に、再送の対象でないMACフレームを指定する際にもMACフレームデータ長はゼロに設定され得る。

なお、MACフレームが存在しないことを示すために、MACフレームデータ長をゼロと設定する以外の方法をとっても良い。例えば、MACスーパーフレームペイロードに最大８個のMACフレームを含むことができ、かつ当該MACスーパーフレームにはMACフレーム１〜４が存在し、MACフレーム５〜８が存在しない場合、存在の有無を８ビットのビットマップで示しても良い。このビットマップはMACスーパーフレームヘッダーの一部となる（図示せず）。

ＨＣＳ２０５はヘッダーチェックシーケンス(Header Check Sequence)のことであり、MACスーパーフレームヘッダー２０２の誤りを検出可能にするため同ヘッダー２０２に付加される。受信側通信装置がＨＣＳ２０５によりMACスーパーフレームヘッダー２０２の誤りを検出した場合には、当該MACスーパーフレームペイロード２０３に含まれる全てのMACフレームは壊れているものと解釈する。

受信側通信装置におけるバッファあふれを防止するために、MACスーパーフレームペイロード２０３に含めるMACフレーム数を動的に制限することが好ましい（スライディング・ウインドウ(Sliding Window)制御）。

図５３はMACフレームのフォーマットの一例を示す図である。図５０のMACスーパーフレームペイロード２０３に含める一つのMACフレームは、MACヘッダー５００と、フレーム本体５０１と、ＦＣＳ(frame check sequence)５０２とから構成される。MACヘッダー５００は、フレーム制御フィールド５０３と、期間(Duration)フィールド５０４と、アドレスフィールド５０５〜５０７，５０９と、シーケンス制御フィールド５０８とから構成される。フレーム本体５０１は０〜２３１２オクテット長の範囲で可変長であり、MPDU(MAC Protocol Data Unit)に相当するMACフレームのペイロードである。

第二種の物理層プロトコル（本実施形態では例えばMIMOとしている）による物理層の高速化に伴い、本実施形態ではMACスーパーフレームとしてPHYフレームに複数のMACフレームを含めることでフォーマットを効率的に構成していることから、フォーマットに起因するPHYフレームごとのオーバヘッド、すなわちPLCPヘッダー、各種IFS(Inter Frame Space)およびバックオフなど、を回避して通信の実質的なスループットを向上できる。

図５４は、本発明の第１２の実施形態に係る通信システムの一例を示す図である。この通信システムにおいて、無線リンクを介して通信装置１（アクセスポイント）、通信装置２〜４（端末）が通信を行うものとする。同図に示す通信装置１は図４８に示した構成を有する。また、通信装置２、３（端末）は図４９に示した構成を有する。これに対し通信装置４（レガシー端末）は第一種の物理層プロトコル処理部１０９Ｓのみを備え、第二種の物理層プロトコル処理部１１０Ｓを備えておらず、よってMACスーパーフレームの送信を行わない既存の通信端末に相当する。

図５５（ａ）にパーシャルACK（部分応答）フレームのフォーマット例を示す。フレーム制御フィールド５５０のtype / subtypeフィールドに、当該フレームがパーシャル(Partial)ACKであることを示す値が入る。パーシャルACKビットマップ５５１には、送達確認の対象となるデータフレームが、受信側の端末あるいはアクセスポイントで正常に受信されたか否かの送達確認状態を示す値が入る。パーシャルACKは、選択的な再送制御（いわゆるSelective Repeat）を行なうために用いられる。パーシャルACKフレームには、物理層レベルの情報を返すために、PHYフィードバック情報５５２を含めても良い。また、パーシャルACKによるポールを可能にする情報（ビット）を付与しても良い（図示せず）。

図５５（ｂ）にポール(Poll(no data))フレームのフォーマット例を示す。フレーム制御フィールド５５３のtype / subtypeフィールドには、当該フレームがデータを含まないポールフレーム（「Poll(no data)」と記す）であることを示す値が入る。Poll(no data)フレームは、アクセスポイントが端末に対して送信権を与えるために用いられる。このアクセスポイントは、IEEE802.11e “Medium Access Control(MAC) Quality of Service (QoS) Enhancement”（現在はドラフト仕様）、ないしはその拡張に従うものであっても良いし、そうではなくても良い。なお、IEEE802.11eでは、物理的なアクセスポイントとハイブリッドコーディネータ(Hybrid Coordinator)と呼ばれるスケジュール管理の論理的な実体とが区別されているが、本発明に従う実施形態は両者を特に区別することなく実現することができる。

図５６（ａ）にデータ(Data)フレームのフォーマット例を示す。フレーム制御フィールド５６０のtype / subtypeフィールドに、当該フレームがデータフレームであることを示す値が入る。MACペイロード(あるいはMSDU: MAC Service Data Unit)５６１には、ユーザデータ（一般にはリンク層がMAC層に送信を要求するデータ）が入る。

図５６（ｂ）にData + Pollフレームのフォーマット例を示す。フレーム制御フィールドのtype / subtypeフィールドには、当該フレームがデータを含んだポールフレーム（「Data + Poll」と記す）であることを示す値が入る。Data + Pollフレームは、アクセスポイントが端末に対して送信権を与える必要があり、かつアクセスポイントが端末に対してユーザデータ５６２を送信するために用いられる。

これらのフレーム（MACフレーム）は、アグリゲートされない単独のMACフレームとして送受信されても良いし、他のMACフレームとともに単一の物理フレームにアグリゲートされ、ＭＡＣスーパーフレームとして送受信される場合もある。

なお、従来の通信装置４(レガシー端末)は、単独のMACフレームのみ送受信可能であって、通信装置１（アクセスポイント）と通信装置２、３（MIMO対応端末）は、単独のMACフレームと、ＭＡＣスーパーフレームのいずれをも送受信可能であると仮定する。

図５７は、図５０に示した複数のMACフレームを単一の物理フレームにアグリゲートする場合の基本的なアグリゲートフレームフォーマットの全てのMACフレーム（MACフレーム１〜４）をデータフレームとした場合を例示している。図５７のフレームは、端末とアクセスポイントとの間、ないしは端末間で相互にユーザデータを送受信するために用いられる。

図５８は、アグリゲートフレームフォーマットのMACフレーム１をパーシャルACKフレームとし、MACフレーム２をData + Pollフレームとし、MACフレーム３、４をデータフレームとした場合を例示している。図５８のフレームは、アクセスポイントが端末に対する送達確認（パーシャルACK）を行うとともに端末に対し送信権を与え、かつ端末にユーザデータを送信する際に用いる。ここで送達確認対象の端末、送信権を与える端末、データ送信対象の端末は、一般には同じであるが、それぞれ異なることを禁止するものではない。

図５９は、アグリゲートフレームフォーマットのMACフレーム１をパーシャルACKフレームとし、MACフレーム2をPoll(no data)フレームとした場合を例示している。図５９のフレームは、アクセスポイントが端末に対する送達確認を行い、かつ端末に対し送信権を与える際に用いる。ここで送達確認対象の端末、送信権を与える端末は、一般には同じであるが、それぞれ異なっても構わない。

図６０は、アグリゲートフレームフォーマットのMACフレーム１をPoll(no data)フレームとした場合を例示している。図５９のフレームは、アクセスポイントが端末に対し送信権を与える際に用いる。

なお、アグリゲートフレームへの複数のMACフレームの組み合わせ方は、上述したもののみに限定されず、他の様々な組み合わせ方が可能である。

図６１（ａ）に、MACヘッダーにQoS制御フィールドを持つ、QoSデータフレームのフォーマット例を示す。フレーム制御フィールド６１０のtype / subtypeフィールドに、当該フレームがQoSデータフレームであることを示す値が入る。MACペイロード(あるいはMSDU: MAC Service Data Unit)６１１には、ユーザデータ（一般にはリンク層がMAC層に送信を要求するデータ）が入る。

図６１（ｂ）に、MACヘッダーにQoS制御フィールドを持つ、QoS Data + Pollフレームのフォーマット例を示す。フレーム制御フィールド６１２のtype / subtypeフィールドに、当該フレームがQoS Data + Pollフレームであることを示す値が入る。QoS Data + Pollフレームは、アクセスポイントが端末に対して送信権を与える必要があり、かつアクセスポイントが端末に対してユーザデータ６１３を送信するために用いられる。

図６１（ａ）に示すQoSデータフレーム、および図６１（ｂ）に示すQoS Data + Pollフレームは、それぞれ図５６（ａ）のデータフレーム、および図５６（ｂ）のData + PollフレームのQoS拡張であり、IEEE802.11eないしはその拡張に準拠する場合に用いられる。

図６２は、アグリゲートフレームフォーマットの全てのMACフレーム（MACフレーム１〜４）をQoSデータフレームとした場合を例示している。図６２のフレームは、端末とアクセスポイント間、ないしは端末間で、相互にユーザデータを送受信するために用いられる。その他、これまでに示したアグリゲートフレームフォーマットにおけるデータフレームをQoSデータフレームに置き換えたものや、QoSデータフレームを含むそれ以外の組み合わせも可能である。

図６３は、IEEE802.11-1999仕様に規定される、PCF(Point Coordination Function)を用いた際のフレーム交換シーケンスの一例を示している。IEEE802.11では、コンテンション（競合；Contention）期間６３０においては、CSMA/CAベースのDCF(Distributed Coordination Function)により、端末とアクセスポイントが対等にメディアを取り合うが、コンテンションフリー（無競合状態すなわち解放；Contention Free）期間６３１においては、アクセスポイント（あるいはアクセスポイント内のポイントコーディネータ(Point Coordinator)と呼ばれる論理的な実体）がポーリングにより全てのメディアアクセスを制御する。アクセスポイントは定期的にビーコン(Beacon)フレーム６３２を送信する。コンテンションフリー期間６３１は、Contention Free Repetition Interval（ビーコン送信間隔の整数倍）６３３に対応するビーコンにより開始され、アクセスポイントが送信するCF-End(Contention Free End)フレーム６３４により終了し、あるいはCF_Max_duration６３５の経過によっても終了する。コンテンションフリー期間６３１においてアクセスポイント以外の端末はNAV６３６を設定し、MAC層のレベルでメディアがビジーであると解釈する。これによりポーリングによらない自発的な送信が抑制される。

CF期間（６３１）中は、アクセスポイントはPoll、Data、Data + Ack、Data + Poll、Data + Ack + PollなどのMACフレームを送信することができる。Pollされた端末はData、Data + Ackなどを送信することができる。Pollされていない端末はDataを送信することはできないが、アクセスポイントから送信されたDataに対するAckを送信することはできる。アクセスポイントは、端末がSIFSで応答すると仮定して動作する。SIFSで期待する応答が返ってこない場合には、アクセスポイントはPIFS後に、次にスケジュールすると予定していたフレームシーケンスを開始しても良い。

アクセスポイントがポーリング機能(PCF)を持つか否かは、ビーコンないしProbe Responseフレームに含まれるCapability Information Fieldによって判定できる。ポーリング対象となることを希望する端末は、ポーリング機能を持つアクセスポイントに対し、自端末がポーリングを受ける能力を持ち、かつポーリングのスケジュールに登録することを示すCapability Information Fieldを含むAssociation Requestフレームを送信する。

アクセスポイントがポーリングによりメディアアクセス制御を行なう方法は、IEEE802.11eにより拡張(HCCA: HCF Controlled channel access, HCF: Hybrid Coordination Function)されている。図６４に示すように、IEEE802.11との大きな相違は、アクセスポイント(Hybrid Coordinator)が、コンテンション（競合）期間６４０中の任意の時点でポーリング制御のためのコントロールド・アクセス期間（CAP：Controlled Access Period)６４１，６４２，６４３等を開始できる点にある。即ちアクセスポイントは、PIFS期間のメディアの空き状態を確認した後に、仕様で定められた任意のフレームシーケンスを開始できる。ポーリング対象となった端末は、PollフレームのQoS制御フィールドに指定されるTXOP(Transmission Opportunity)の期間の送信権を与えられる。TXOPの期間において、端末は複数のMACフレームをSIFS間隔で連続的に送受信しても構わない。端末はnull dataフレームを送信することで、与えられたTXOPの終了以前に送信権をアクセスポイントに返上しても良い。

IEEE802.11eにおける更なる相違として、ポーリングを望む端末は、アクセスポイントに対してトラフィックストリーム(Traffic Stream)の設定を要求することが規定されている。トラフィックストリームの設定が行なわれると、帯域・遅延などのQoS要求を満たすように、アクセスポイントが当該端末のメディアアクセスを制御する。つまり、アクセスポイントから端末へのデータ送信については、指定したTCLAS(Traffic Classifier)に合致するMSDUが、指定されたQoS要求を満たして送信されるよう、送信のスケジューリングがなされる。端末からアクセスポイントへのデータ送信については、指定されたQoS要求を満たすように、アクセスポイントが端末をポーリングする。

IEEE802.11-1999、あるいはIEEE802.11eの仕様では、ポーリング制御に用いられるMACフレーム、およびポーリング制御によって交換を許されるMACフレームは、物理フレームと１対１で対応する単独のMACフレームであり、一つの物理フレームに複数のMACフレームがアグリゲートされたMACスーパーフレームではない。しかし、複数のMACフレームを単一の物理フレームにアグリゲートすることにより、物理フレーム毎に付随するオーバヘッド（プリアンブル、物理ヘッダー、IFS(Inter Frame Space)など）を削減することができるため、MACの効率が向上する。以下では、アグリゲートされたMACフレームに関するポーリングシーケンスに関して説明を行なう。

図６５は、PCFをフレームアグリゲーションにより拡張した場合の、ポーリングシーケンスの一例を示している。コンテンションフリー期間はビーコンフレーム６５０により開始される。ビーコンフレーム６５０を送信する時刻（時点）は、アクセスポイントのポーリング・データ送信スケジュール制御部１０５１により決定される。当該時刻にビーコン６５０を送る前にPIFS期間のメディアの空きが要求されるが、これはキャリアセンス制御部１０６Ａにより確認され、確認後にメディアアクセス制御部１０８Ａによりビーコンフレーム６５０が物理層に渡される。ビーコンフレーム６５０は、IEEE802.11a準拠端末と仮定される通信装置４(STA3 Legacy)を含む、全ての端末装置が受信可能でなければならない。したがって、IEEE802.11aの送受信を司る第一種の物理層プロトコル制御部１０９Ａによって第一種(IEEE802.11a)の物理フレームとして形成され、送信される。

ここでシーケンス図に表れる記号を例に挙げて説明する。

・F{BC(beacon)}: ブロードキャスト(broadcast)アドレス宛のビーコンMACフレームであって、MACスーパーフレームでない単一のMACフレームとして送信されるフレームを表す。

・SF{STA1(poll (no data))}: STA1宛てのpoll(no data)MACフレームであって、MACスーパーフレームとして送信されるフレームを表す。

・SF{STA1(pack), STA2(poll(no data))}: STA1宛てのパーシャルACKのMACフレームとSTA2宛てのpoll(no data)MACフレームとがアグリゲートされたMACスーパーフレームとして送信されるフレームを表す。

ビーコンフレーム送信後のSIFS経過後に、アクセスポイントはSTA1に対して、poll(no data)フレーム６５１を送信することにより、STA1に送信権を与える。この時点でSTA1に送信権を与えるという決定は、アクセスポイントのポーリング・データ送信スケジュール制御部１０５１が行なう。この例では、poll(no data)フレーム６５１をMACスーパーフレームとして送信している(図中の"SF"は"Super Frame"の略である)。

このMACスーパーフレームは、MIMOの送受信を司る第二種の物理層プロトコル制御部１１０Ａによって第二種の物理フレームとして形成され、送信される。しかし、ここで必要なMACフレームは１つだけなので、通常のMACフレームとして送信しても良い。この場合、IEEE802.11aの送受信を司る第一種の物理層プロトコル制御部１０９ＡによってIEEE802.11aの物理フレームとして形成され、送信されても良い。

pollフレーム６５１がアクセスポイントから第二種の物理フレームとして送信された場合、端末(STA1)はMIMO PLCPロングプリアンブル（図５２）によって、アクセスポイントと端末との間のMIMOチャネルの状態を推定することができる。一般に、チャネル状態を検出し、送信側で適切な制御（例えば、MIMOの複数ストリームやOFDMの複数サブキャリアに対して、電力あるいは情報量を均等に割り当てるのではなく、適切に傾斜配分する、パワーローディングやビットローディング、およびその組み合わせ）を行なうことによって、伝送路の容量が増大することが知られている。また、より単純な送信制御、例えば端末で測定した受信電力などの情報により、端末が送信する際の適切な送信レート（変調方式・符号化率など）を制御しても良い。

また、MACスーパーフレームヘッダーのPHYフィードバック情報５０００（図５０参照）に、当該フレームをアクセスポイントが送信する際のパラメータ、例えば送信電力やアンテナ利得の情報を含めることにより、端末による上記チャネル状態の推定を補正することができる。即ち、アクセスポイントと端末との間の送信電力やアンテナ利得の差により、チャネル推定の結果を誤って解釈することを防ぐことができる。例えば、アクセスポイントの送信電力が端末の送信電力より大きいのに、同じと仮定した端末がチャネル推定を行なえば、チャネル状態を誤認する。誤認したチャネル状態で可能と解釈した最大のレートを選択して、端末がアクセスポイントにフレームの送信を行なえば、アクセスポイントでは当該フレームを受信できない可能性が高くなる。したがって、MACスーパーフレームヘッダーのPHYフィードバック情報５０００に、同一端末からアクセスポイントへの直前の送信に基づく物理層の受信状態データ（チャネル推定情報、誤り訂正量、受信電力）などを含めることは、端末側での適切な送信制御に有用である。

図６５の説明に戻る。アクセスポイントからのポーリングを受けた端末(STA1)は、アクセスポイント宛の複数のデータフレームを単一のMACスーパーフレーム６５２にアグリゲートし、送信する。送信すべきデータフレームは、図４９に示すデータ送信スケジュール制御部１０５２により選択される。QoSなどを意識する必要がなければ、単純にキューの先頭のデータフレームから順番に送信対象として選択すればよい。QoSが必要な場合には、優先度の高いデータフレームや、定期的に送信すべきタイミングにあるデータフレームから送信対象として選択する。単一のMACスーパーフレームに、複数優先度のデータフレームが含まれてもよい。

図４９に示す端末のメディアアクセス制御部１０８Ｓは、自端末へのポーリングを受信したら、SIFS後にMACスーパーフレームを送信するように制御する。MACスーパーフレームは、データ送信スケジュール制御部１０５２が上記のように選択したデータフレームを含むように構成される。このMACスーパーフレームは、MIMOの送受信を司る第二種の物理層プロトコル制御部１１０Ｓによって第二種の物理フレームとして形成され、送信される。

アクセスポイントは、このフレームを受信すると、最初にMIMOの送受信を司る第二種の物理層プロトコル制御部１１０Ａ（図４８）により、物理層１０１Ａの受信処理を行い、MACスーパーフレームを取り出し、MAC層１０２Ａに渡す。この際に、物理層１０１Ａにおける受信状態の情報を付加情報としてMAC層１０２Ａに渡しても良い。

アクセスポイントの再送制御部１０７Ａは、MACスーパーフレームに含まれる各データフレームが正常に受信されたか否かをFCSにより決定し、送達確認情報(パーシャルACKビットマップ)を含むパーシャルACKフレームを作成する。更に、パーシャルACKフレームのPHYフィードバック情報に、物理層１０１Ａにおける受信状態の情報を含めても良い。ポーリング・データ送信スケジュール制御部１０５１は、当該端末(STA1)に送信すべきデータが無いことを確認し、かつ当該端末への送信権付与を継続すべきだと判断したとする。この場合、端末(STA1)宛てのパーシャルACKフレームとPoll(no data)フレームをアグリゲートして、MACスーパーフレーム６５３を作成する。メディアアクセス制御部１０８Ａは、このように作成されたMACスーパーフレーム６５３をSIFS後に送信するようメディアへのアクセスを制御する。このMACスーパーフレーム６５３は、MIMOの送受信を司る第二種の物理層プロトコル制御部１１０Ａによって第二種の物理フレームとして形成され、送信される。

端末は、このフレーム６５３を受信すると、最初にMIMOの送受信を司る第二種の物理層プロトコル制御部１１０Ｓ（図４９）により、物理層１０１Ｓの受信処理を行い、MACスーパーフレームを取り出してMAC層１０２Ｓに渡す。この際に、物理層１０１Ｓにおける受信状態の情報を付加情報としてMAC層１０２Ｓに渡しても良い。

このMACスーパーフレーム６５３には、パーシャルACKとpoll(no data)が含まれている。ポーリングされているため、端末(STA1)は、アクセスポイント宛の複数のデータフレームを単一のMACスーパーフレームにアグリゲートし、送信することができる。送信すべきデータフレームは、図４９に示す再送制御部１０７Ｓとデータ送信スケジュール制御部１０５２により選択される。つまり、パーシャルACKにより再送すべきMACフレームを識別し、更にデータ送信スケジュール制御部１０５２が、新規に送信するMACフレームと再送すべきMACフレームの優先度を勘案して、実際に送信するMACフレームを選択する。単純には優先度の高いものを先に送信すれば良い。あるいは、例えば、MACフレームに割り当てた優先度が低くても、当該MACフレームを廃棄すべきタイムアウトの残り時間が少なければ、優先度が高いがタイムアウト時間まで余裕のあるMACフレームより先に送信するという風に制御しても良い。単一のMACスーパーフレームに、複数優先度のデータフレームが含まれても問題は無い。

図４９に示す端末のメディアアクセス制御部１０８Ｓは、自端末へのポーリングを受信したら、SIFS後にMACスーパーフレーム６５４を送信するように制御する。MACスーパーフレーム６５４は、データ送信スケジュール制御部１０５２が上記のように選択したデータフレームを含むように構成される。更に、MACスーパーフレーム６５４のPHYフィードバック情報５０００に、物理層における受信状態の情報を含めても良い。このMACスーパーフレーム６５４は、MIMOの送受信を司る第二種の物理層プロトコル制御部１１０Ｓによって第二種の物理フレームとして形成され、送信される。

送信の際に、受信した物理フレームから得たチャネル状態に関する情報、受信したパーシャルACKフレームに含まれていたアクセスポイントからのPHYフィードバック情報、パーシャルACKビットマップから得られた正常な受信率などを勘案して、変調方式、符号化率、パワー・ビットローディングなどの送信制御を行なっても良い。

パーシャルACKビットマップで、後半のMACフレームが正常に受信されない傾向にある場合は、チャネルの寿命よりもMACスーパーフレーム送信に要する時間が長い可能性がある。そこで、送信するMACスーパーフレームの最大長を制限するように制御しても良い。また、MACスーパーフレームを担う物理フレームについて、フレームの先頭だけでなく、途中でもチャネル推定できる情報（ミッドアンブルなどの既知情報）を適応的に追加することで、チャネル状態が大きく変わる前に、チャネル推定の補正を行なえるようにしても良い。

以下、ポーリングシーケンスの他の例を図６５の例との相違点を中心に説明する。
アクセスポイントは、応答を要するフレームを受信すると、再送制御部１０７ＡがパーシャルACKフレームを作成する。ここで、ポーリング・データ送信スケジュール制御部１０５１が、端末STA1へのPollおよびパーシャルACK送信よりも、端末STA2への送信権付与を優先すべきと判断したとする。また、端末STA2とのこれまでのフレーム交換に基づくSTA2に対するパーシャルACKフレームが形成済みであり、かつ端末STA2に送信すべきフレームはなかったとする。この場合、端末(STA2)宛てのパーシャルACKフレームとPoll(no data)フレームをアグリゲートし、MACスーパーフレームを構成する。メディアアクセス制御部１０８Ａは、このように構成されたMACスーパーフレームをSIFS後に送信するようメディアへのアクセスを制御する。このMACスーパーフレームは、MIMOの送受信を司る第二種の物理層プロトコル制御部１１０Ａによって第二種の物理フレームとして形成され、送信される。

このMACスーパーフレームを受信した端末STA2は、既述の方法と同様に、送信すべきデータフレームを選択し、MACスーパーフレームを構成し、SIFS後にアクセスポイント宛に送信する。

図６５には示していないが、このようなポーリング制御を行なうコンテンションフリー期間は、図６３に示したように、アクセスポイントがCF-Endフレーム６３４を送信するか、CF_Max_Duration６３５の時間経過によって終了する。

図６６に示す他のシーケンス例は、アクセスポイントがCTS-Self６６０を自アクセスポイント宛に送信することによりCAP期間を生成する点で、図６５に示したような、ビーコンフレームによりCF期間を開始するポーリングシーケンスとは異なる。このCAP期間はTXOPで示される時間が経過すると終了する。また、アクセスポイントが、SF{STA1(Pack),STA2(Poll(no data))}という１つのMACスーパーフレーム６６１により、端末STA1に対するパーシャルACKフレーム送信と、端末STA2に対するPoll(no data)フレーム送信とを行なっている点でも異なる。このMACスーパーフレーム６６１は、端末STA1からのデータフレームが全てアクセスポイントによって受信され、端末STA1からの再送の必要が無い場合などに有効である。

図６７は、アクセスポイントが端末STA3(Legacy)に対するポーリングを行うポーリングシーケンスを示している。端末STA3は第一種の物理層プロトコル(例えばIEEE802.11a)のみを実装するレガシー端末であり、ポーリング制御のフレームを含むアクセスポイントと端末STA3との間のフレーム交換は、第一種の物理層プロトコルに準拠して行なわれる。また、端末STA3は、MACスーパーフレームを扱えないことが仮定されており、アグリゲーション無しのMACフレームが個別に送受信される。

このような端末STA3がMACフレームを連続的に送信する際には、IEEE802.11eに規定されたブロック(Block)ACKのフレーム交換手順に従う。つまり、SIFS間隔を空けて別々の物理フレームとしてデータフレーム６７０，６７１が次々とバースト送信され、その送達確認がブロックACK要求(Block ACK Request)フレーム６７２とブロックACKフレーム６７３により行なわれる。

レガシーな端末STA3に対してはポーリング、データ、および応答フレーム等についてMACスーパーフレームを用いない（アグリゲーションを抑制）ことにより、アクセスポイントは、ネットワークがレガシーな端末STA3を有する場合であっても共存して動作することができる。なお、ポーリング対象の端末がMACアグリゲーションに対応しないレガシーな端末であるか否かについて、アクセスポイントは事前の、何らかのフレーム交換により検出することができる。

図６８は、図６５に示したシーケンス例の変形に係わり、ポールフレームをＭＡＣスーパーフレームにより送信する場合において、データを有さないPoll(no data)のみならず、データを有するPoll(data)を許容するものである。

以上説明した本発明の実施形態は次のように変形することができる。これは、ＭＡＣスーパーフレームヘッダーのフォーマットをＭＰＤＵと同じにするというものである。図６９にＭＰＤＵと同じフォーマットを持つＭＡＣスーパーフレームヘッダー１９００の一例を示す。例えばフレーム制御(Frame Control)フィールドに含まれるType / Sub-type領域に、ＭＡＣスーパーフレームヘッダーであることを示す値を新たに規定して割り当てる。受信側の通信装置のＭＡＣ層は、この値にしたがって以後ＭＡＣスーパーフレームの処理を行うべきか、通常のＭＡＣフレームの処理を行うべきかを決定する。期間(Duration)５０４の値は、当該ＭＡＣスーパーフレームに含まれる他のＭＡＣフレームの期間の値の計算方法に準じて設定される。アドレス１フィールド５０５(Receiver Address)の値は、当該ＭＡＣスーパーフレームに含まれる他のＭＡＣフレームのアドレス１と同じになるように設定される。このようにアドレス１フィールド５０５には受信側の通信装置を特定するアドレスが設定される。

ＭＡＣスーパーフレームヘッダー１９００は、分割(fragment)されずまた再送されることもないので、シーケンス制御(Sequence Control)フィールド５０８の値は特に意味を持たない。よってＭＡＣスーパーフレームのTypeを制御(Control)フレームとして割り当てれば、このシーケンス制御フィールド５０８が省略されるためより好ましい。

TypeをManagementまたはDataとして定義すると、シーケンス制御フィールド５０８を持つ必要があるが、その値は本発明に係る実施形態の再送制御と整合が取れるように扱う必要がある。既存の通信では例えばＭＡＣスーパーフレームの一連の再送制御において再送対象となるＭＡＣフレームのシーケンス番号(Sequence number)は連続値を取ると仮定されているので、シーケンス番号が不連続な値を設定する場合は当該ＭＡＣスーパーフレームの一連の再送制御をいったん終了し、別のシーケンスによる再送制御を開始する必要がある。このためシーケンス番号の不連続が起きないようにするか、不連続になったとしても一連の再送制御を継続できるようにする必要がある。これを解決する一例として、本発明の別の実施形態に示すような再送時のウィンドウ制御をしているときは、一連の再送制御で再送対象のＭＡＣフレームに割り当てられる可能性のある最大のシーケンス番号の値がわかるので、この最大値を超える値のシーケンス番号となるように順次割り当てるという方法がある。またこの値には再送対象のＭＡＣフレームも含めて連続的な値を割り当てる必要があるのだが、再送制御をするときには再送対象のＭＡＣフレームのシーケンス番号を無視することで不連続になっても良いように制御するという方法も可能である。

図６９に示すペイロードに相当する部分１９０１には、当該ＭＡＣスーパーフレームに含まれる各ＭＡＣフレームの長さを設定する。ペイロード１９０１には分割(fragment)に対応するためのフラグメント番号(fragment number)を含めても良い。

またＦＣＳ５０２は図５０におけるＨＣＳ２０５に対応しており、ＦＣＳ５０２を用いて通常のＭＰＤＵと同様の扱いとすれば良い。たとえばＦＣＳ５０２にはＭＡＣスーパーフレームヘッダー全体に対して計算したＣＲＣ値を設定する。ＭＡＣスーパーフレームヘッダー１９００に付随するＦＣＳ５０２により、受信側通信装置でＭＡＣスーパーフレームヘッダー１９００が壊れていると認識した場合には、ＨＣＳ２０５により誤りが検出された場合と同様に扱い、これを検出した受信側通信装置はＭＡＣスーパーフレーム全体を廃棄する。

（第１３の実施形態）
第１３の本実施形態は、単一の物理フレームに含まれる、複数のＭＡＣフレームのＭＡＣヘッダから、冗長要素を取り除き、更に効率を向上させるものである。

以下、冗長要素を取り除いたＭＡＣヘッダを、縮約ＭＡＣヘッダと称する。図７０に縮約ＭＡＣヘッダを持つＭＡＣフレームを含むＭＡＣスーパフレーム構成の一例を示す。この例では、ＭＡＣフレーム１は通常のＭＡＣヘッダを持つが、ＭＡＣフレーム２、３，４は縮約ＭＡＣフレームを持つように構成されている。

図７１に送信側における、通常のＭＡＣヘッダを持つＭＡＣフレームからの縮約ＭＡＣヘッダを持つＭＡＣフレームの生成処理と、受信側における、縮約ＭＡＣヘッダを持つＭＡＣフレームから通常のＭＡＣヘッダを持つＭＡＣフレームの再現処理の一例を示す。

図７０に示すように、ＭＡＣスーパフレームは通常のＭＡＣヘッダを持つＭＡＣフレームを少なくとも１つ持っていると仮定する。例えば、アドレスＳＡを持つ有線端末が、アドレスＴＡを持つアクセスポイント経由で、アドレスＲＡを持つ端末に送信した複数のＭＡＣフレームを、単一のＭＡＣスーパフレームにアグリゲートしたと想定する。この場合アドレスＳＡ、アドレスＴＡ（ＢＳＳＩＤ）、アドレスＲＡは全てのＭＡＣフレームに共通であり、ＭＡＣヘッダにアドレス情報として含まれる。送信側アクセスポイントで、単一のＭＡＣフレーム１のＭＡＣヘッダにのみアドレスＳＡ，アドレスＴＡ，アドレスＲＡを残し、他のＭＡＣフレーム２，３，４のＭＡＣヘッダからは、アドレスＳＡ，アドレスＴＡ，アドレスＲＡを省略したとしても、受信側端末で、ＭＡＣフレーム１のＭＡＣヘッダから、ＭＡＣフレーム２，３，４のＭＡＣヘッダを再現することが可能である（図７２）。これが、図７２における送信側処理、「ＭＡＣスーパフレームに含まれる、他のＭＡＣフレームから再現可能なＭＡＣヘッダ情報を削除する」、受信側処理「ＭＡＣスーパフレームに含まれる、他のＭＡＣフレームから再現可能なＭＡＣヘッダ情報を再現する」の一例である。また、単一のＭＡＣスーパフレームに含まれる全てのＭＡＣフレームのＭＡＣヘッダにおいて、期間フィールドの値が同じである場合も考えられる。そのような場合には、アドレスに加えて、期間フィールドも削除・再現対象となる（図７３）。

通常のＭＡＣヘッダを持つＭＡＣフレームが、必ず先頭のＭＡＣフレーム１であると約束すれば、どのＭＡＣフレームが通常のＭＡＣヘッダを持つかは送信側と受信側で暗黙に了解される。あるいは、複数宛先のＭＡＣフレームが単一のＭＡＣスーパフレームに含まれる場合には、送信側ＳＴＡが、各宛先の先頭のＭＡＣフレームを受信側ＳＴＡに示す情報を、ＭＡＣスーパフレームに含めておけばよい。これは、例えば、ＭＡＣふーレムヘッダに含まれるビットマップ情報で示すことができる。ここで各宛先の先頭ＭＡＣフレームは通常のＭＡＣヘッダを持つと仮定している。また、複数の属性、例えばＱｏＳ属性 (ＴＩＤ， ＴＳＩＤなど)が単一のＭＡＣスーパフレームに含まれる場合には、送信側ＳＴＡが、属性の変化するＭＡＣフレームを受信側ＳＴＡで識別できる情報を含めておけばよい。ここで同一属性を持つＭＡＣフレーム群の先頭ＭＡＣフレームは通常のＭＡＣヘッダを持つと仮定している。

図７４に、暗号・メッセージ認証を含む場合の、縮約MACヘッダを持つMACフレームの生成、および縮約MACヘッダからのMACヘッダ再現処理の一例を示す。IEEE802.11のセキュリティ拡張を規定するIEEE802.11i (Security Enhancement) のドラフトに規定される、ユーザデータ暗号・メッセージ認証方式 (TKIPおよびCCMP) は、ＭＡＣフレームのペイロード部分のみならず、ＭＡＣヘッダ情報の一部もセキュリティ保護の対象としている。ＭＡＣヘッダは暗号（秘匿）化の対象とはされないが、ＭＡＣフレームに含まれる情報の一部（アドレス情報などを含む）は、改変を検出するためのメッセージ認証コードの計算対象となっている。このため、送信側ＳＴＡと受信側ＳＴＡにおけるセキュリティ処理とＭＡＣヘッダの縮約・再現処理の処理手順に依存関係が生じる。

送信側ＳＴＡにおいては、最初に平文のＭＡＣヘッダとＭＡＣペイロードとの組を生成する。これを暗号化・メッセージ認証コード (ICV : Integrity Checki Value) 付与処理に渡す。これによりＭＡＣペイロードは暗号化され、かつＭＡＣペイロードにICVが付与される。ＭＡＣヘッダとＭＡＣペイロード（暗号化ＭＡＣペイロード + ICV）との全体に対しＦＣＳが計算され付与される。この後でＭＡＣヘッダの縮約処理を行い、ＭＡＣスーパフレームにアグリゲートして送信される。

受信側ＳＴＡにおいては、最初に縮約されたＭＡＣヘッダから、通常のＭＡＣヘッダの再現処理が行なわれる。次にＭＡＣヘッダとＭＡＣペイロード（暗号化ＭＡＣペイロード + ICV）の全体に対するＦＣＳが計算され、ＭＡＣフレームに付与されていたＦＣＳと比較される。一致すれば正常受信で、一致しなければ壊れていると判断する。次に暗号化ＭＡＣペイロードを復号化し、かつＭＡＣヘッダの一部とＭＡＣフレームに対するICVを計算して、一致すれば改変なし、不一致なら改変ありと判断する。

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

本発明の一実施形態に係る通信装置を示すブロック図 固定長のACK Policy Bitmapを示す図 本発明の第１の実施形態に係るBitmap Informationフィールドを示す図 可変長ACK Policy Bitmapを持つMACスーパーフレームの一例を示す図 受信バッファ管理を説明するための図 本発明の第２の実施形態に係る優先度毎の受信バッファ管理を説明するための図 TSPECのフォーマットを示す図 優先度毎の第１の再送制御例を説明するための図 優先度毎の第２の再送制御例を説明するための図 本発明の第３の実施形態に係る優先度毎の再送制御例を説明するための図 標準的なブロックACKのシーケンス（即時型）を示す図 QoS Controlフィールドを示す図 本発明の第４の実施形態に係り、可変長ACK Policy Bitmapを持つMACスーパーフレームの一例を示す図 本発明の第４の実施形態に係り、QoSデータをアグリゲートしたブロックACKシーケンス(即時型)を示す図 本発明の第４の実施形態に係り、QoSデータとブロックACK要求のアグリゲート例を示す図 本発明の第４の実施形態に係り、QoSデータとブロックACK要求をアグリゲートしたブロックACKシーケンス(即時型)を示す図 本発明の第４の実施形態に係り、複数TIDのQoSデータとブロックACK要求のアグリゲート例を示す図 本発明の第４の実施形態に係り、複数TIDのQoSデータとブロックACK要求をアグリゲートしたブロックACKシーケンスを示す図 本発明の第４の実施形態に係り、No ACKとブロックACKポリシーフレームのアグリゲートを示す図 No ACKとブロックACKポリシーのMACフレームのアグリゲーションによるシーケンス例を示す図 本発明の第５の実施形態に係り、トラフィックストリームのセットアップ時に用いられるTSPEC(Traffic Specification)を示す図 本発明の第５の実施形態に係り、ＭＰＤＵ長を固定長とするＭＡＣスーパーフレームを示す図 本発明の第５の実施形態に係り、複数TSIDの混在時の固定長MACフレームのアグリゲーションを示す図 本発明の第６の実施形態に係り、複数の宛先を持つMACスーパーフレームの一例を示す図 本発明の第６の実施形態に係り、複数の宛先を持つMACスーパーフレームの他の例を示す図 本発明の第７の実施形態に係り、宛先毎の回線使用期間を表すＭＡＣスーパーフレームの一例を示す図 図２６のフレームの変形例を示す図 本発明の第７の実施形態に係り、複数宛先に異なるDurationを指定する場合を説明するための図 本発明の第７の実施形態に係る受信端末の動作を示すフローチャート 本発明を適用可能な無線通信システムの構成例を示す図 本発明を適用可能な無線通信システムの他の構成例を示す図 IEEE802.11eにおけるブロックACK対象のQoSデータフレームのシーケンスを示す図 本発明の第８の実施形態に係り、複数の宛先に対するブロックACK対象データフレームのアグリゲーション例を示す図 本発明の第８の実施形態に係り、アグリゲートされた複数宛先へのブロックACK対象データフレームのシーケンスを示す図 本発明の第８の実施形態に係り、複数の宛先に対するデータフレームとBlock ACK Requestフレームのアグリゲーション例を示す図 本発明の第８の実施形態に係り、アグリゲートされた複数宛先へのデータおよびBlock ACK Requestフレームのシーケンス例を示す図 本発明の第９の実施形態に係るACKの再送信を説明するための図 本発明の第９の実施形態に係る複数宛先のアグリゲート例を示す図 本発明の第９の実施形態に係る複数宛先アグリゲート時のACK再送信を示す図 本発明の第９の実施形態に係る複数宛先アグリゲート時のACK再送信の他の例を示す図 本発明の第１０の実施形態に係り、ACKを送信する時点を送信側で指定する場合のフレームフォーマット例を示す図 本発明の第１０の実施形態に係り、ACKを送信する時点を送信側で指定する場合のフレームフォーマットの一例を示す図 本発明の第１０の実施形態に係り、ACKを送信する時点を送信側で指定する場合のフレームフォーマットの他の例を示す図 本発明の第１０の実施形態に係り、ACKを送信する時点を送信側で指定する場合のフレームフォーマットの他の例を示す図 本発明の第１０の実施形態に係り、複数宛先のACK送信時間の指定を示す図 本発明の第１１の実施形態に係り、QoSを考慮した複数宛先へのMACスーパーフレームの一例を示す図 本発明の第１１の実施形態に係り、QoSを考慮した複数宛先へのサイマルキャストを示す図 本発明の第１２の実施形態に係る通信装置（アクセスポイント）のブロック図 本発明の第１２の実施形態に係る通信装置（端末）のブロック図 上記通信装置が用いるフレームフォーマットの一例を示す図 第一種のPHYフレームのフォーマットの一例を示す図 第二種のPHYフレームのフォーマットの一例を示す図 MACフレームのフォーマットの一例を示す図 本発明の第１２の実施形態に係る通信システムの一例を示す図 （ａ）はパーシャルACK（部分応答）フレームのフォーマット例を示す図、（ｂ）はポール(Poll(no data))フレームのフォーマット例を示す図 （ａ）はデータ(Data)フレームのフォーマット例を示す図、（ｂ）はData + Pollフレームのフォーマット例を示す図 Dataスーパーフレームの一例を示す図 Partial ACK + [Data + Poll] + Dataスーパーフレームの一例を示す図 Partial ACK + [Poll (no data)]スーパーフレームの一例を示す図 [Poll (no data)] スーパーフレームの一例を示す図 （ａ）はQoS Data フレームの一例を示す図、（ｂ）はQoS Data + Poll フレームの一例を示す図 Partial ACK + [QoS Data + Poll] + QoS Data スーパーフレームの一例を示す図 PCFフレーム交換の一例を示すシーケンス図 CAP / CFP / CPの例（CAP generation）を説明するための図 ポーリングシーケンス例（beaconによるCFP開始）を示す図 ポーリングシーケンス例(CTS-SelfでCAP生成、STA1へのPackとSTA2へのPollを相乗り)を示す図 ポーリングシーケンス例(Legacy STAを含む場合)を示す図 図６５に示したシーケンス例の変形例を示す図 ＭＡＣスーパーフレームヘッダーのフォーマットをＭＰＤＵと同じにする場合を示す図 本発明の第１３の実施形態に係る通信装置が用いる、縮約MACヘッダを持つフレームフォーマットの一例を示す図 本発明の第１３の実施形態に係り、縮約MACヘッダを持つMACフレームの生成、および縮約MACヘッダからのMACヘッダ再現処理の一例を示す図 本発明の第１３の実施形態に係り、縮約MACヘッダの第一の例を示す図 本発明の第１３の実施形態に係り、縮約MACヘッダの第二の例を示す図 本発明の第１３の実施形態に係り、暗号・メッセージ認証を含む場合の、縮約MACヘッダを持つMACフレームの生成、および縮約MACヘッダからのMACヘッダ再現処理の一例を示す図

符号の説明

１００…通信装置、１０１…物理層処理ユニット、１０２…ＭＡＣ層処理ユニット、１０３…リンク層処理ユニット、１０４…アンテナ、１０５…アグリゲーション処理部

Claims (7)

1. 複数のＱｏＳデータフレーム(Quality of Service)を含む単一の物理フレームを作成する作成手段と、
   前記作成手段により作成された物理フレームを送信する送信手段と、
   送信された物理フレームの受信状態を含む応答フレームを受信する受信手段とを具備し、
   前記物理フレームは、前記複数のＭＡＣフレームのそれぞれに対応する、属性を示す可変長のビットマップ情報と、該ビットマップ情報の長さ情報とを含むことを特徴とする通信装置。
2. ウインドウサイズに対応する複数のＱｏＳデータフレーム(Quality of Service)を含む単一の物理フレームを作成する作成手段と、
   前記作成手段により作成された物理フレームを送信する送信手段と、
   送信された物理フレームの受信状態を含む応答フレームを受信する受信手段と、
   前記受信手段で受信した前記応答フレームに含まれる受信状態に基づいて、正常に受信されなかったＱｏＳデータフレームを再送する再送手段と、
   前記再送手段による再送の際に、前記物理フレームに含めることが可能なＭＡＣフレームの最大数に相当する個数のＭＡＣフレームが含まれるように、前記ウインドウサイズを拡大する制御手段とを具備することを特徴とする通信装置。
3. 複数のＱｏＳデータフレーム(Quality of Service)を含む単一の物理フレームを作成する作成手段と、
   前記作成手段により作成された物理フレームを送信する送信手段と、
   送信された物理フレームの受信状態を含む応答フレームを受信する受信手段と、
   前記ＱｏＳデータフレームの第１，第２のサイズの指定を含む第１，第２のトラフィックストリームを設定する設定手段とを具備し、
   前記複数のＱｏＳデータフレームは、前記第１のトラフィック識別子に対応する前記第１のサイズの複数の第１ＱｏＳデータフレームと、該第１ＱｏＳデータフレームの総数を示す第１の情報と、前記第２のトラフィック識別子に対応する前記第２のサイズの複数の第２ＱｏＳデータフレームと、該第２ＱｏＳデータフレームの総数を示す第２の情報と、トラフィック識別子の総数とを含むことを特徴とする通信装置。
4. 複数のＱｏＳデータフレーム(Quality of Service)を含む単一の物理フレームを作成する作成手段と、
   前記作成手段により作成された物理フレームを送信する送信手段と、
   送信された物理フレームの受信状態を含む応答フレームを受信する受信手段とを具備し、
   前記複数のＱｏＳデータフレームは、宛先の順番を示す情報および第１の宛先を有する第１の複数のＱｏＳデータフレームと、宛先の順番を示す情報および第２の宛先を有する第２の複数のＱｏＳデータフレームとを含むことを特徴とする通信装置。
5. 複数のＱｏＳデータフレーム(Quality of Service)を含む単一の物理フレームを作成する作成手段と、
   前記作成手段により作成された物理フレームを送信する送信手段と、
   送信された物理フレームの受信状態を含む応答フレームを受信する受信手段とを具備し、
   前記複数のＱｏＳデータフレームは、宛先が異なっており、
   前記物理フレームは、前記ＱｏＳデータフレームのそれぞれに対応するビットからなり、宛先の区切りを示す第１のビットマップ情報と、前記ＱｏＳデータフレームのそれぞれに対応するビットからなり、送達確認ポリシーを示す第２のビットマップ情報と、を含むことを特徴とする通信装置。
6. 第１の優先度を有する第１のＱｏＳ(Quality of Service)データフレームと、第２の優先度を有する第２のＱｏＳデータフレームとを含む単一の物理フレームを受信する受信手段と、
   前記第１のＱｏＳデータフレームの受信に応じて開始され、前記第１の優先度に対応する第１のタイマー値を有する第１のタイマー手段と、
   前記第２のＱｏＳデータフレームの受信に応じて開始され、前記第２の優先度に対応する第２のタイマー値を有する第２のタイマー手段と、
   前記受信手段により受信された物理フレームに含まれる第１のＱｏＳデータフレームを記憶し、前記第１のタイマー手段が前記第１のタイマー値によりタイムアウトした時点で該第１のＱｏＳデータフレームを出力する第１の受信バッファと、
   前記受信手段により受信された物理フレームに含まれる第２のＱｏＳデータフレームを記憶し、前記第２のタイマー手段が前記第２のタイマー値によりタイムアウトした時点で該第２のＱｏＳデータフレームを出力する第２の受信バッファとを具備することを特徴とする通信装置。
7. 第１の優先度を有する第１のＱｏＳ(Quality of Service)データフレームと、第２の優先度を有する第２のＱｏＳデータフレームとを含む単一の物理フレームを作成する作成手段、前記第１の優先度に対応する第１のタイマー値および前記第２の優先度に対応する第２のタイマー値の少なくともいずれかを前記物理フレームに指定する指定手段、前記指定手段によりタイマー値の指定がなされた物理フレームを送信する送信手段を有する第１の通信装置と、
   前記送信手段から送信された物理フレームを受信する受信手段、前記第１のＱｏＳデータフレームの受信に応じて開始され、前記物理フレームに指定された第１のタイマー値が設定される第１のタイマー手段、前記第２のＱｏＳデータフレームの受信に応じて開始され、前記物理フレームに指定された第２のタイマー値が設定される第２のタイマー手段、前記受信手段により受信された物理フレームに含まれる第１のＱｏＳデータフレームを記憶し、前記第１のタイマー手段が前記第１のタイマー値によりタイムアウトした時点で該第１のＱｏＳデータフレームを出力する第１の受信バッファ、前記受信手段により受信された物理フレームに含まれる第２のＱｏＳデータフレームを記憶し、前記第２のタイマー手段が前記第２のタイマー値によりタイムアウトした時点で該第２のＱｏＳデータフレームを出力する第２の受信バッファを有する第２の通信装置とを具備することを特徴とする通信システム。

Images