JP4314294B2 - 通信装置、通信システム、通信方法、および通信制御プログラム - 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)が既に設立されている。
米国特許第５３２９５３１号明細書

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

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

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

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

本発明の一態様に係る通信装置は、１の物理フレーム内に宛先の異なる複数の媒体アクセス制御フレームを含む物理フレームであって該物理フレーム内の媒体アクセス制御フレームのうち同一の宛先を持つフレームについて連続するように配列された物理フレームを作成する物理フレーム作成手段と、前記物理フレーム作成手段により作成された物理フレームを送信する送信手段とを具備することを特徴とする通信装置である。

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

以下、図面を参照しながら本発明の実施の形態の例を説明する。

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

アグリゲーション処理部１０５は、複数の媒体アクセス制御（ＭＡＣ）フレーム（ＭＰＤＵ）を含むＰＨＹ（物理）フレームを作成する。ＭＰＤＵはＭＡＣプロトコルデータユニット(MAC Protocol Data Unit)の略である。また、ＰＳＤＵは物理層変換プロトコルサービスデータユニット(Physical layer convergence protocol Service Data Unit)の略である。

作成された物理フレームは物理層の処理ユニット１０１により処理され、アンテナ１０４より送信される。このような通信方式のことを本明細書では「フレームアグリゲーション」という。フレームアグリゲーションは現在策定中の次世代超高速無線ＬＡＮ通信（IEEE802.11n規格）に好適である。なお、本発明の実施形態において、アグリゲーション処理部１０５は宛先が異なる複数のＭＡＣフレームのフレームアグリゲーションを行う。より具体的には、本発明の第１の実施形態は1つの物理フレームに宛先が異なる複数のＭＡＣフレームをアグリゲートすることにより、APからのダウンリンク伝送時のチャネル利用率を改善する無線通信システムである。

図２（ａ）はアクセスポイント（AP）と複数の端末(STA)との間のダウンリンク、および該ダウンリンクにおけるユニキャストフレームの送信シーケンスを示す図である。ダウンリンク２０においては、APからSTA1,2,3に向けてフレームが送信される。逆に、STA1,2,3からAPに向けてフレームが送信されることをアップリンク伝送という。この図２（ａ）の例は、DCF(Distributed Coordination Function)によるアクセスに、フレームアグリゲーションが適用された場合であり、DCFに従いデータ送信およびACK受信のためのフレームシーケンスが実行される。なお、本発明の実施形態はDCFに限定されるものではなく、PCF(Point Coordinate Function)によるアクセスや、QoSを考慮したアクセスにも適用可能である。なお、QoSを考慮する場合については第２の実施形態以降で説明する。

APから複数のSTAに対してユニキャストフレームを送信する場合を考える。図２（ｂ）から分かるように、ACKを受信し、キャリアセンス（ここではDIFS期間）とバックオフの期間を経過した後でなければ、次の宛先にフレームを送ることができない。多数の宛先に送信する場合は、チャネル未使用の期間が増えてフレームの伝送効率が低下してしまう。

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

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

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

まず、送信側(ここではAP)について説明する。図４に示すように、APは複数のアドレス（宛先）が存在することを示す情報４１をＭＡＣスーパーフレームヘッダー４０に追加する。以下、この情報４１のことを「マルチアドレスビットマップ(Multi Address Bitmap)」と呼ぶことにする。また、このように拡張されたＭＡＣスーパーフレーム全体のフォーマット例を図５に示す。尚、図４におけるマルチアドレスビットマップ４１は、最大アグリゲート数を８とした場合の、対応するビットマップ情報として、８ビットの大きさが指定されているが、この情報サイズはMACフレームのアグリゲート最大数（実装依存）に応じて任意に定めても良い。

次に、本発明の実施形態に係るマルチアドレスビットマップについて説明する。マルチアドレスビットマップは、複数の宛先の存在を示す情報であって、該情報はアグリゲートされたＭＡＣフレームの各々に対応するビットからなり、複数の宛先の区切りを示す。つまり、マルチアドレスビットマップは当該ＭＡＣスーパーフレームを含む物理フレーム内のＭＡＣフレームのうち先のＭＡＣフレームの宛先と比べてその宛先が変化するフレームの含まれる位置に関する情報でもある。

図６に示すように、ある宛先が開始される時点で対応する位置のビットを立てることで、当該ビット位置が宛先の区切りであることを示すことができる。なお、図６に示すマルチアドレスビットマップ４３では、宛先が開始する時点で、ビットを1に指定しているが、1の代わりに0を使用しても良い。この場合、図６のマルチアドレスビットマップは「01101011」のように示される。

また、宛先が変化したことを示す意味でマルチアドレスビットマップを使用することもできる。この場合、図７に示すように、宛先が次の異なる宛先に変化した時点で、対応するビットを立てる。なお、図７に示すマルチアドレスビットマップ４４では、変化した時点で1のビットが指定されているが、前述のように、1の代わりに0を使用しても良い。

複数の宛先を持つＭＡＣスーパーフレームを作成する送信端末(AP)は、宛先ごとにＭＡＣフレームを区切ってアグリゲートすることが必要となる。ここで、「宛先ごとにＭＡＣフレームを区切る」ことは、ＭＡＣスーパーフレーム内において同一の宛先を持つフレームについて連続するように配列することを含む。

フレームアグリゲーション方式では、ＭＡＣスーパーフレームの受信側において、ＭＡＣスーパーフレームヘッダーに誤りが生じていなければ、アグリゲートされた各ＭＡＣフレームを抽出し、抽出された各ＭＡＣフレームに対し誤り計算を行って受信状態（ステータス）を検出する。これにより検出された受信ステータス結果は送信側にパーシャルACK（部分応答）により返信される。図８はパーシャルACKのビットマップ情報の一例を示している。図８のMACスーパーフレームボディ４２において、×印が付いている部分は、MACスーパーフレームにアグリゲートされたMACフレームが誤っていることを示している。図８では、MACスーパーフレーム送信端末に対し、パーシャルACKを返信する際、「１」を正常受信とした場合であり、誤ったMACフレーム部分に関しては、正しく受信できなかったことを示す「０」が記載されている。

ここで、図９（ａ）に示すように、MPDU(s)90の宛先が順不同でアグリゲートされていると、受信端末(STA)側で、どの宛先のフレームが幾つ存在し、またその受信状況がどうであったかを判断できず、送信側に部分応答を正しく伝えることができない。

例えば、図９（ａ）の状態に、マルチアドレスビットマップ４０を追加したとしても、宛先が変化したことを伝える用途でマルチアドレスビットマップ４０を使用した場合（0 1 1 1 1 1 1 1)は、宛先毎に幾つのＭＡＣフレームが存在するか判断することは不可能である。この状況では、マルチアドレスビットマップ４０の情報から、MACスーパーフレームを受信した端末は、8種類の宛先が存在すると判断してしまうが、実際には、３つの宛先しか存在しない。

一方、図９（ｂ）のように、宛先毎に区切ってアグリゲートしたとしても、その区切りを示す情報（すなわちマルチアドレスビットマップ）を含まないヘッダー９１の場合は、DEST2へのフレームが全て誤りであったとすると、DEST3のフレームはどこから始まっているのか判断できず、やはり送信側に部分応答のビットマップ情報を正しく伝えることができない。

これらの問題を解決するために、送信端末(AP)は、複数の異なる宛先のフレームを1つの物理フレームにアグリゲートする際に、宛先毎に区切ることと、その区切りの情報をＭＡＣスーパーフレームヘッダーに記載することが必要となる。

複数の宛先のＭＡＣフレームを1つの物理フレームに宛先毎にアグリゲートし、その複数宛先の情報をＭＡＣスーパーフレームのヘッダーに書き込んだ後、APはSTAに対し、ＭＡＣスーパーフレームをサイマルキャストする。

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

すなわち、各STAは受信した物理フレームから、当該STAを宛先とするＭＡＣフレームをマルチアドレスビットマップに基づいて特定して抽出し、これにより抽出されたＭＡＣフレームに対する応答フレーム（パーシャルACK）を宛先の区切りの順序に対応する時間間隔に従い送信する。

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

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

例えば図１１に示すように、DEST1に該当する受信端末へのＭＡＣフレームは1番目にアグリゲートされており（Ｎ＝１）、この受信端末は通常のフレームアグリゲーションと同様のシーケンスで、SIFS期間（ステップＳ１５）後にパーシャルACKフレーム１１０（あるいはブロックＡＣＫ）を送信する（ステップＳ１６）。なお、１１１は対応するパーシャルACKビットマップである。その後、他の端末(図１１の例では、DEST2、DEST3)が、時間差的にパーシャルACKを返信している間は、NAV112を設定して、データフレーム等の送信を停止する（ステップＳ１７）。尚、NAV112の期間は、(残りの端末数×(SIFS+ACK転送時間))で決定される。また、本発明の実施形態においては、各STAからのACKの転送レートが同一であることを仮定しているが、ACK転送レートがSTA毎に異なる場合は、それぞれに対応したACK転送時間を計算する。

2番目にアグリゲートされているDEST2は、DEST1がパーシャルACK110を送信した後（ステップＳ１１）、SIFS期間が経過してから（ステップＳ１２）、パーシャルACKビットマップ114を表すパーシャルACK113を送信する（ステップＳ１３）。そして自端末がパーシャルACK113を送信した後は、DEST1の場合と同様に、残りの端末がパーシャルACKを送信している期間の間、NAV115を設定する（ステップＳ１４）。DEST3は、自端末より前にアグリゲートされている宛先がパーシャルACK110,113を返す間待機しており、その後更にSIFS経過してから、自端末からのパーシャルACK116（パーシャルACKビットマップは114）を送信する。この待機時間は、自端末より前方にアグリゲートされている宛先数×(SIFS+ACK転送時間)で決定される。なお、自端末が、ＭＡＣスーパーフレームにアグリゲートされている最後の宛先（この場合はDEST3）であるならば、NAVの期間は0、つまり設定しないことになる。

ＭＡＣスーパーフレームに自端末を宛先とするＭＡＣフレームが存在しない場合は、(アグリゲートされた宛先数×(SIFS+ACK転送時間))の間、NAV118を設定する（ステップＳ７〜８）。また、アグリゲートされた宛先の数は、マルチアドレスビットマップの情報から得る（ステップＳ７）。すなわち、宛先の開始箇所にその情報を示すビットを立てる場合、有効になっているビットの数が、アグリゲートされた宛先の数に対応する。マルチアドレスビットマップは、ＭＡＣスーパーフレームのヘッダーに追加されるため、ＭＡＣスーパーフレームヘッダーが誤りでない限り、各ＭＡＣフレームが誤っていても、それらの位置情報、宛先数を判断することができる。

図１２（ａ）に示すように、DEST2宛の２つのフレームがいずれも誤っていた場合、DEST2は、自端末への宛先が含まれているかどうか判断不可能になることから、(アグリゲートされた宛先数×(SIFS+ACK転送時間))の期間、NAV120を設定する（ステップＳ７〜８）。なお、DEST3の端末はマルチアドレスビットマップの情報を頼りに、自端末宛のＭＡＣフレームがどこから始まっており、またその受信ステータスがどうであるかを判断できるため、図１２（ｂ）に示すように適切なタイミングでパーシャルACK121を送信側に伝えることができる。

ＭＡＣスーパーフレームを受信した端末への宛先のフレームが存在しない場合、前述の例のように、マルチアドレスビットマップ情報から宛先の数を取り出し、NAV期間を算出しても良いが、送信端末がＭＡＣスーパーフレームを作成する際、各ＭＡＣフレームのDurationフィールドに、(アグリゲートした宛先数×(SIFS+ACK転送時間))の値を記載しても良い。この場合、ＭＡＣスーパーフレーム受信端末は、自端末宛の宛先が存在しない場合、Durationフィールドに指定された期間の間、NAVを設定すればよい。

本発明の第１の実施形態によれば、複数の異なる宛先への通信フレームのアグリゲーションによりスループットを向上できる。図２で示したフレームシーケンスに本発明の実施形態を適用した様子を図１３に示す。具体的には、図１３によると、複数の宛先(図の例は３つ)のMPDUが混在するＭＡＣスーパーフレーム１３０を送信することで、図２において、宛先毎に必要となっていた、キャリアセンスとバックオフの時間を短縮できていることが分かる。このＭＡＣスーパーフレーム１３０へのSTAからのパーシャルACKは時間差でAPに送信されており、これらは衝突することがない。アグリゲートする宛先の数を増やせば、その分さらにオーバーヘッドを削減する事が可能である。また、"No ACK"ポリシーのフレームに対して本発明を適用すれば、パーシャルACKの受信を待つ必要がないため、さらに転送効率の向上が可能になる。

したがって、宛先毎に必要となっていたキャリアセンスとバックオフの期間を短縮することができ、チャネル利用率を有効に活用し、伝送効果を高めることができる。

（第２の実施形態）
サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御が幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するＱｏＳとして、ＨＣＣＡでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。本発明の第２の実施形態に係るＱｏＳとしてはトラフィックストリーム毎の品質を保証するＨＣＣＡを想定する。IEEE802.11e規格におけるＱｏＳには、ＤＣＦ(Distributed Coordination Function)、ＰＣＦ(Point Coordination Function)、ＥＤＣＡ(HCF Contention Access)、およびＨＣＣＡ(HCF Controlled Access；ＨＣＦコントロールド・アクセス)が存在する。ＨＣＣＡはＡＰからのポーリング制御を行う従来のＰＣＦの拡張方式である。ＰＣＦにおいて、HC(Hybrid Coordinator)と呼ばれるQoS-APがポーリング(スケジューリング)を行う主体となり、無線端末を集中制御する。ＡＰはポーリングリストに基づき、端末を順番にポーリングする。ＳＴＡはポーリングで自局が指定されたときフレームを送信する機会を得る。

図１４に示すように、通信を開始するにあたって、QoS-nonAP-STA(以後QSTA)は、HCとTS(Traffic Stream)をセットアップ(Uplink、Downlink、Bidirectional)する。TSとは、その端末がどういった種類のトラフィック (Voice over IPやFTP)を使用し、どれぐらいの帯域を必要としているかを示すデータの通り道のようなもので、TSPEC(Traffic Specification)によって一意に仕様が決まる。TSのセットアップ開始時には、QSTAからのTSPECが通知される。TSPECは、「TSID(そのTSPECで定められるTSの識別子)」や、「Mean Data Rate」(MAC_SAPで最低限保障したいTSのスループット)といった情報を含んでいる。TSは複数本張ることが可能で、HCはそれぞれのTSの要求を満たすようなスケジューリングを行う必要がある。但し、スケジューリングに関する具体的なアルゴリズムは、IEEE802.11eで規定されておらず、実装に依存している。QSTAは、HCから与えられたポーリングにより、TXOP(送信可能時間)を得、フレームを送信することになる。

このようなHCCAにおいてフレームアグリゲーションを実施する場合、各ＭＡＣフレームは独自のMACヘッダーを持ち、ヘッダー内のTID(IEEE802.11e用に拡張されたQoS Controlフィールド内に存在し、トラフィックを識別するもので、TSIDは8-15番を使用)により、TSを一意に特定できるため、複数のストリームをアグリゲートすることは可能である。

そして本発明の第２の実施形態は、図１５に示すHCからのダウンリンクトラフィック１５０の効率改善を主な焦点とするものである。

図１６に示すように、まずHCはTSを張っているQSTA毎にダウンリンクトラフィックの宛先キュー1100,1101を作成する。これら宛先キュー1100,1101内には、それぞれのQSTAを宛先とするフレームが詰め込まれていく。またQSTAの必要帯域は、TSPEC内のMean Data Rateから判断可能(QSTAが持つTS毎の値を合計)で、それらの比を計算し、多くの帯域を必要としているQSTAに対しては、WRR(重み付けラウンドロビン)でより多くの送信を行う。

例えば、QSTA1がHCからのダウンリンクトラフィックに関して8Mbpsを必要とし、QSTA2が4Mbps必要とし、QSTA3が同じく4Mbps必要としているならば、2:1:1の重み付けでHCが送信していく。各宛先のキュー内に、さらに優先度毎のキューを作成することで、フレームの優先度を考慮したフレームアグリゲーションも可能である。

ここで、WRR以外のスケジューリング方法として、HCからQSTAへのダウンリンクトラフィックに関し、TSを張ってHCに接続している端末の数で帯域を分割する。宛先端末には、図１７に示すようにRR(ラウンドロビン：1回ずつ均等に巡回)でフレームを送信していく。例えば、あるQSTA(通信事業者に対し、より高額な金を払っているユーザ端末)が、帯域確保の要求をHCに出し、HC内で登録されているQSTAならば、応答メッセージを返す。この後、HCからQSTAへの送信巡回はWRRとなり、該当QSTAへの送信機会を増やしてもよい。

図１８に示すように、HCはQSTAへのダウンリンクトラフィックについて、送信回数に重み付けを行う。ここでの「送信１回」とは、あるＭＡＣスーパーフレームを送る際、(再送も含めて)正しく宛先にフレームを送信できた時点(パーシャルACKのBitmapが全て1になっている)を1回とカウントする。例えば、[1] [2] [3] [4] [5] [6] [7] [8]のようにフレームをアグリゲートしたとする。ここでTSPECのMean Data Rateに応じて、1つの物理フレーム中の各優先度フレームの数は変動する。最初の送信で[1]〜[8]のフレーム全てを正しく送信(パーシャルACK受信)できたならば、「送信1回」がカウントされる。あるいは、[2]の再送が必要で、[2] [9]のようにＭＡＣスーパーフレームを再送して、パーシャルACKが受信できたならば、その時点で「送信1回」とカウントする。このように送信回数を定義し、TSPECから算出された各QSTAへの送信回数に重み付けを行っていく。

本実施形態の目的は、あくまでダウンリンクトラフィックを効率化することにあり、HCからQSTAへのダウンリンクの送信と、QSTAに対しポーリングでTXOP(送信機会)を与えるアップリンクの送信とは分けて考える。つまりHCは、「ダウンリンクにフレームを送信する時間」と「各QSTAにポーリングしてTXOPを与える時間」を交互に繰り返してスケジューリングを行っていくことにする。

HCはダウンリンクへの(連続した)トランスミッションを始める前、各TSのTSPEC内にあるディレイバウンド(Delay Bound)に基づいて、TXOPの期間を決定する。ディレイバウンドは、伝送路上の誤りによる再送も考慮しており、そのためHCが初期に決定するTXOPの期間は、比較的大きい値になる。しかしディレイバウンドの具体的な決定方法は、IEEE802.11eでも規定されていない部分である。

HCは、QoSデータフレームをQSTAに向けてサイマルキャストする。データフレームの中には、HCがダウンリンクトラフィックの送信に必要とするTXOPの値がデュレーションとして含まれており、各QSTAは、その間NAVを張って、一切のフレーム送信が出来ない状態となる。伝送路上で誤りが多く、フレームの再送が何度も起きると、予め指定したTXOPでは足りなくなる(全てのQSTAに順番通りフレームを送信していく)ため、図１９に示すCAP(Controlled Access Phase)の間であれば、SIFS待った後、再度TXOP(2回目)2を得る。フレームを全てのQSTAに対し(WRRで)送信し終わると、予約したTXOP期間が余る場合があるが、その時はQoS-Nullフレームを送り、各QSTAに張られたNAVの解除を行う。CAPは、HCがPIFSの間キャリアセンスを行ってチャネル状態がアイドルの場合、再度獲得される期間である。新しいCAPを獲得すれば、QSTAに対し、アップリンクトラフィックの送信(あるいはDLPによるQSTA同士の通信でも良い)を許可するための、QoS CF-Pollを送る。ポーリングフレームの中には、各QSTAに与えられたTXOPの値がデュレーションとして含まれており、その期間、他の端末はNAVを張って一切の送信が出来ない。

実際の処理シーケンスとして、例えば図２０（ａ）のようなケース(QSTA1に2の重み、QSTA2に1の重み、QSTA3に1の重みが必要な場合)を考える。

図２０（ｂ）に示すように、まずQSTA1への送信1回目に、「[1] [2] [3] [4] [5] [6] [7] [8] to QSTA1」のようにフレーム２０１をアグリゲートし、送信したとする。このＭＡＣスーパーフレーム２０１に対し、パーシャルACK202が戻され、正しく送信出来た時点で、1回とカウントする。そして今回、WRR(重み付け巡回方式)で送信権利を渡すことを前提としていることから、重みが2であるQSTA1に、「[9] [10] [11] [12] to QSTA1」のように再度、フレーム２０３を送信したとする。

キューにフレームがあまり溜まっていなかった場合、端末毎に決められている最大アグリゲート数よりも少ない数のフレームが詰め込まれることになるかもしれない。（フレーム２０３）QSTA1へのフレーム送信(2回)が終われば、パーシャルACK204に続いてQSTA2へのフレーム２０５の送信シーケンスに移行する（「[1] [2] [3] [4] to QSTA2」）。

QSTA2へのフレーム２０５に対するパーシャルACK206の後、同様に、QSTA3へのＭＡＣスーパーフレーム２０７を送信する（「[1] [2] [3] [4] [5] [6] [7] to QSTA3」）。

ここで、本実施形態では、例えばHCはQSTA1への2回目のフレーム送信と、QSTA2へのフレーム送信を1つのＭＡＣスーパーフレーム２１１に束ねて送信し、時間差でパーシャルACK212,213を受信させる。つまり、1つのＭＡＣスーパーフレーム214中に、1つの宛先(QSTA1)のフレームをアグリゲートするのではなく、HCは、複数の宛先を持つＭＡＣスーパーフレームを含む物理フレームを作成する。

本実施形態においても、第１の実施形態の図４に示したように、ＭＡＣスーパーフレームヘッダー４０を拡張し、マルチアドレスビットマップ(Multi Address Bitmap)フィールド４１を追加する。このフィールド４１は、アグリゲートされたＭＡＣスーパーフレームの中で、異なる宛先アドレスを持つMPDUが存在する場合の情報を示すビットフィールドである。このビットフィールドの使用方法は、ＭＡＣスーパーフレームの中に、宛先毎にアグリゲートされたMPDUに対して、宛先が変化した時点で、その部分のビットを1に立てる。

図５に示した場合と同様に、１つのＭＡＣスーパーフレーム中に、2つの宛先へのＭＡＣフレーム(MPDU)４２がアグリゲートされ、DEST2へのMPDUが５つ目の部分から現れたとする。この場合、マルチアドレスビットマップ４１は、「0 0 0 1 0 0 0」のように示される。ここで、ビットの値が０から１に変化している箇所は、宛先が変化したフレーム位置に相当する。

図５の例の場合では、アグリゲート可能なMPDUの最大数を8としているため、マルチアドレスビットマップも8ビットになるが、この大きさはアグリゲート数に応じて可変とする。また、マルチアドレスビットマップ４１を用いることで、そのＭＡＣスーパーフレームに、幾つの宛先が存在するか受信側で判断することができる。上記の例では、宛先が変化した回数が1回なので、ＭＡＣスーパーフレーム内に存在する宛先の数は２つと判定できる。もし、1つの宛先へのMPDUしかアグリゲートされていない場合は、「0 0 0 0 0 0 0 0」のように示される。すなわち、マルチアドレスビットマップは全てのビットの値が0になっていることが分かる。

同一の宛先についてのフレームアグリゲーションの実装では、ＭＡＣスーパーフレームを受信した各端末は、先頭のMPDUのアドレスのみをチェックすれば、フレーム全体が自端末宛かそうでないか判断することができる。宛先の異なるフレームをアグリゲートする本発明の場合、マルチアドレスビットマップフィールドを追加したことで、その値が全て0（マルチアドレスビットマップを、宛先変化の意味で用いた場合。各宛先の始まりを示す用途で用いているなら、宛先の数が１つなら、先頭のビットが１になっており、以後のビットは全て０になる。）であれば、ＭＡＣスーパーフレーム中のMPDU(s)の宛先は1つに限定されるので、この場合は先頭MPDUのアドレスをチェックするのみで以後のチェックは不要である。

マルチアドレスビットマップのいずれかのビットフィールドに1の値が入っていれば、そのビット位置に直接アクセスすることにより、そのMPDUの宛先を判断できる。このようにマルチアドレスビットマップフィールドを用いることで、MPDUのヘッダーの中身をチェックする回数は、ＭＡＣスーパーフレーム中に単一の宛先しか存在しない場合、1回の比較で済む。また、マルチアドレスビットマップのビットが1になっている部分が、宛先の変化している箇所であるので、その部分を直接チェックしていけば、自端末宛の宛先が含まれているかどうか、より簡単に判断することができる。（「１」が各宛先の始まりを示す用途で用いられている場合）
ＭＡＣスーパーフレーム内に、複数の宛先のMPDUがあることを判断(マルチアドレスビットマップから判断)したQSTAは、その宛先のいずれかに自端末のアドレスが含まれているかを判断する。そして自端末のアドレスが、相対的に前方にあるか後方にあるかでパーシャルACKを返信する順番を決定する。例えば、「[DEST1] [DEST1] [DEST1] [DEST1] [DEST2] [DEST2] [DEST2] [DEST2]」というＭＡＣスーパーフレームを受信した場合、受信端末のアドレスが「DEST1」であった場合、SIFS後にパーシャルACKを送信することが求められる。そしてアドレスが「DEST2」の端末は、アドレス「DEST１」の端末がパーシャルACKを送信したSIFS後に、パーシャルACKをHCに返信する。この時、DEST1のQSTAは、1-4番目のMPDUに対するＣＲＣ（cyclic redundancy check；巡回冗長検査）計算結果を返し、アドレス2のQSTAは、5-8番目のMPDUに対するＣＲＣ計算結果を返す。

自端末宛の宛先が、ＭＡＣスーパーフレームに含まれていない場合、その端末はNAVを張ることになる。IEEE802.11で規定されているMACプロトコルでは、ユニキャストデータフレームを受信した際、基本的に、[SIFS時間 + ACK転送時間]に相当するDurationを設定するが、複数の受信端末から時間差的にパーシャルACKが返される本提案では、(（アグリゲートした宛先数- その宛先が何番目であるかの数値）×([SIFS時間 + ACK転送時間]）)のDuration値をHC(ＭＡＣスーパーフレーム送信端末)が各MACフレームに設定する。また、本発明の実施形態においては、各QSTAからのACKの転送レートが同一であることを仮定しているが、ACK転送レートがQSTA毎に異なる場合は、それぞれに対応したACK転送時間を計算する。

ＭＡＣスーパーフレーム中に自端末宛てのアドレスが存在する端末は、アグリゲートされた宛先の相対的な位置から、自端末がどのタイミングでパーシャルACKを返せばよいかを判断可能である。そして、ＭＡＣスーパーフレーム中に自端末宛の宛先が存在しなかった端末は、Durationの期間だけ、NAVを張る。

また、パーシャルACKを送信した端末は、ＭＡＣスーパーフレーム内の、相対的なアドレス情報から、自端末が最後にアグリゲートされたMPDUであればNAVを張る必要はないが、DEST1およびDEST2のように、後続のパーシャルACKが転送される見込みがある場合は、HC(ＭＡＣスーパーフレーム端末)が設定したNAVの終了期間まで、NAVを設定する。

例えば図１１に示したようにDEST2に対する全てのMPDUが誤っていて、DEST3へのMPDUがどの部分から始まっているか判断しようとする場合は、マルチアドレスビットマップフィールドを活用することで、そのＭＡＣスーパーフレーム内に幾つの宛先が存在しているか、またそれらの区切りはどこから始まっているかを判断することができる。

例えば、図１２に示したように、DEST2へのMPDUが全て誤っていた場合、マルチアドレスビットマップフィールドから、宛先の数が3つ存在することと、DEST3へのMPDUの始まりの部分がどこからであるか判断をすることは可能である。よって、DEST2は、自端末宛のMPDUが含まれていたかどうかも分からないので、（アグリゲートされた宛先数×（SIFS+ACK転送時間）だけNAVを張る。DEST3は自端末宛のMPDUを見つけた時点で、自端末が何番目の宛先であるか、自端末宛のMPDUの始まりの部分はどこであるかを、マルチアドレスビットマップから判断し、適切な時間の後、パーシャルACKを返す。図１２の例のように、端末2自体はパーシャルACKを応答しないが、端末3は本来端末２が送るべきパーシャルACK(+SIFS)の時間を考慮して、自身のパーシャルACKを返答する。

ＭＡＣスーパーフレーム送信端末は、どの宛先にどれだけのMPDUを詰めて送信したかの情報をキャッシュしておき、宛先端末から送られてくる時間差的なパーシャルACKを全て受信した後、再送すべきフレームを決定する。

図２０はHCからQSTAに対し異なる宛先のフレームをアグリゲートしない場合である。これに対し図２１に示すように、複数の宛先(図の例は2つ)のMPDUを混ぜて送信することで、SIFSの期間を短縮できていることが分かる。アグリゲートする宛先の数を増やせば、その分さらにSIFS(×α)のオーバーヘッドを短縮可能である。また、"No ACK"ポリシーのフレームに対して本発明を適用すれば、パーシャルACKの受信を待つ必要がないため、さらに転送効率の向上が可能になる。

複数の宛先に対し、ダウンリンクトラフィックを送信したHCは、宛先の数だけパーシャルACKが帰ってくるのを待ち、その後再送等の処理を行う。宛先毎に区切っているので、片方の宛先には新しいMPDUを詰めて送信しても良い。そのため、HCがセットすべきACKタイマーの値は、(宛先数 × （SIFS ＋ パーシャルACK送信時間) + 1スロット時間）で示される。

以上説明した本発明の第２の実施形態によれば、ＱｏＳを考慮する場合であっても、上述した第１の実施形態と同様に、複数の異なる宛先への通信フレームのアグリゲーションによりスループットを向上できる。また、アグリゲートする宛先の数を増やせば、その分さらにSIFS(×α)のオーバーヘッドを短縮可能である。したがって、宛先毎に必要となっていたキャリアセンスとバックオフの期間を短縮することができ、チャネル利用率を有効に活用し、伝送効果を高めることができる。

具体的には、例えば街中のホットスポットにおいて、インターネット経由でストリーミングによるビデオ配信を行う場合、APからのダウンリンクトラフィックの伝送効率を改善することができる。ホットスポットにおいて、より多くのクライアント端末を収容可能となる。

ＱｏＳによれば、遅延に敏感なアプリケーションの品質を保証し例えばジッタを均等に保つことができることや、複数の異なる宛先に対するフローをアグリゲートすることで効率の良い転送を実現(低優先度フローの帯域も保障)できるといった作用効果を奏する。

また、各宛先ＳＴＡ（ユーザ）毎に重み付けをすることで、課金制によるサービス品質のクラス分けも容易に実現できるようになる。これにより、例えば高い金額を払っているユーザ端末にはＷＲＲで優先的にＡＰからフレームを伝送できるようになる。

（第３の実施形態）
本発明の第３の実施形態は、IEEE802.11eで規定されたブロックＡＣＫ制御フレーム(ＴＳ毎のBlockAckReq/BlockAck)を１つのＰＨＹフレームの中に多数含ませて送信する通信装置に関する。IEEE802.11eにはデータフレームをＳＩＦＳ間隔でバースト的に送信するブロックＡＣＫが規定されている。ブロックＡＣＫによる通信手順はこれまでに述べたフレームアグリゲーションを行わない場合にも実施可能である。

本実施形態では、複数の異なる宛先へのブロックＡＣＫ（応答）要求フレームは、上述した第１および第２の実施形態と同様、サイマルキャストにより送信する。また、上述した第１および第２の実施形態と同様に、応答フレームの衝突を避けるため、ブロックＡＣＫフレームは時間差的に送信する。

IEEE802.11eで規定されているブロックACKによるフレームシーケンスは、図２２のように示される。図２２のフレームシーケンスの例は、即時型ブロックACKの場合である。ブロックACKの手順には、2通りの方式が存在し、送信側がブロックACK要求(Block ACK request)を送信してから、受信側が直ちに応答(ブロックACK)を返す即時型タイプと、送信側がブロックACK要求を送信し、受信側がしばらくしてから応答(ブロックACK)を返す遅延型が存在する。本発明における実施形態では、両者いずれの場合にも適応可能である。

図２２に示すように、ブロックACKの手続では、端末毎に決定される送信期間(TXOP: Transmission Opportunity)の間に、複数のユニキャストデータフレーム２２０をSIFS期間毎に連続的に送信する。そして、各宛先端末に対し、受信ステータスのビットマップ情報を持ったブロックACKフレームの送信要求をブロックACK要求221,223によって行う。このため、ブロックACK要求フレーム221,223は、宛先毎に分けて送信を行う必要がある。ブロックACK要求221に応じて、QSTA1はブロックACK222をHCに送信する。ブロックACK要求223に応じて、QSTA2はブロックACK224をHCに送信する。

本発明の第３の実施形態では、図２３に示すように、複数のブロックACK要求フレーム230,231,232,...23nを1つのフレームにアグリゲートする。これまで述べた複数宛先へのフレームアグリゲーションと同様に、ブロックACK要求送信端末は、宛先毎に区切って、ブロックACK要求フレームをアグリゲートし、ＭＡＣスーパーフレームヘッダー４０を付加する。そして、その区切りの情報をマルチアドレスビットマップ４１に書き込む。ＭＡＣスーパーフレームヘッダー４０は、ヘッダーのＣＲＣ４４を含んでおり、ヘッダー誤りなら、複数の宛先のブロックACK要求をアグリゲートしたブロックACK要求フレームを廃棄する。そして、チャネルがアイドルになった後、EIFS期間のキャリアセンスを設定する。これは前述のフローチャートと同様の手順とすることを意味している。

前述のように、アグリゲートされたブロックACK要求を受信した端末は、自端末の宛先が何番目にアグリゲートされているか検査し、上述した第１および第２の実施形態のように、時間差的にブロックACKを送信していく。自端末がブロックACKを送信した後は、残りの宛先がブロックACKを送信している期間、NAVを設定する。図２４に、そのシーケンスを示す。この図２４の例では、複数の宛先へのブロックACK要求がアグリゲートされたフレーム２４０を送信することで、SIFSの期間短縮が可能であり、チャネルの利用効率を高めることができる。図２４において、ブロックACK241,242は時間差で送信されている。また、ブロックACK241の送信後は、ブロックACK242との衝突を回避するよう、QSTA1がNAV243を設定している。

さらに、図２５に示すように、ブロックACK要求230,231,...23nのみならず、（ACKを必要としない）データフレーム250,..25nとともにアグリゲートすることが可能である。この場合も、宛先毎に区切ってアグリゲートを行い、各フレーム(データ、ブロックACK要求)のフレームサイズをMPDU Lengthフィールドに記載することで、データフレームの取り出し、ブロックACKの時間差的な送信を正しく行うことが可能となる。

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

物理層１０１は、二種類の物理層プロトコルに対応可能に構成される。それぞれのプロトコル処理のために、物理層１０１は第一種の物理層プロトコル処理部１０９および第二種の物理層プロトコル処理部１１０を有する。なお、実装では第一種の物理層プロトコル処理部１０９と第二種の物理層プロトコル処理部１１０との間で回路の共用などがしばしば行なわれるため、これらは必ずしも独立して存在するわけではない。

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

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

ＰＨＹヘッダ２０１は受信側通信装置の物理層１０１により処理される。すなわち物理層１０１は受信したＰＨＹヘッダ２０１に基づいて、フレーム先頭の検出、キャリアセンス、タイミング同期確立、増幅器の増幅度制御(AGC: Automatic Gain Control)、送信側キャリア周波数への追随(Automatic Frequency Control)、伝送路推定などを行う。また物理層１０１はＰＨＹヘッダ２０１に続くＰＨＹペイロードの変調方式や符号化率、ならびに伝送レートおよびデータ長の検出も行う
図２７では、単一の宛先に向けたＭＡＣフレームのアグリゲーションを示しているが、本実施形態では、上述した実施形態と同様、図２８に示すように複数の宛先に向けたＭＡＣフレームを１物理フレームにアグリゲートし、複数の宛先を受信対象として送信する「サイマルキャスト」を行う。

この場合、図２８に示すマルチアドレスビットマップ(Multi Address Bitmap)に基づいて、例えば送信元のＡＰ（アクセスポイント）は、各宛先端末（ＳＴＡ）からのパーシャルＡＣＫ（部分的な送達確認）フレームを時間差的に受信する（図２９）。このようなパーシャルＡＣＫの時間差受信についても上述した実施形態と同様である。

図３０は、本発明の第４の実施形態に係るキャリアセンス状態を示す図である。図３０に示す第一種の通信装置（以後、HT: High Throughput（ハイスループット）端末と呼ぶ）であるHT0(アドレス:a0)が、HT1(アドレス:a1)、HT2(アドレス:a2)、HT3(アドレス:a3)に向けたＭＡＣフレームを、１つの物理フレームにアグリゲートして送信したとする。ＭＡＣスーパフレームにアグリゲートされた、それぞれのＭＡＣフレームのＭＡＣヘッダには、チャネルを使用する期間の情報(duration値d1,d2,d3)が記載されており、その値に基づいてNAV(Network Allocation Vector)が設定される。

IEEE802.11の規定によると、ユニキャストデータフレームを送信した際のNAVの値は、宛先からのACKを受信するまでの時間、すなわちSIFS(Short Inter Frame Space)時間とACKの伝送時間との合計に等しい。この場合、図３１に示すように、DEST1のDuration期間、DEST2はNAVを設定し、DEST1はパーシャルACKを送信後DEST2のDuration期間だけNAVを設定する。この方法では、例えばパーシャルACKを時間差的に送信する端末が、ACKとともにデータフレームを１物理フレームにアグリゲートして送信するような場合を考えると、予め指定されたNAV(SIFS時間、ACK伝送時間の合計)を超えてしまうことになる。

一方、IEEE802.11eの規定によれば、HCがQSTAに対して、QoSデータを送信する際、該宛先へのポーリングフレームを抱き合わせ(piggyback)することが可能である。すなわち、MACヘッダのタイプ、サブタイプ情報から、QoS Data + CF-Pollのフレームであることを判断する。MACスーパフレームに対し、図３２のように、IEEE802.11eのQoS Data + CF-Pollフレームをアグリゲートすることで、図３０のHT1、HT2、HT3は、TXOPによる送信可能期間以内であれば、ACK応答に加え、HT0に対するデータフレームをアグリゲートして送信することが可能となる。

つまり、図３０のHT1、HT2、HT3が、HT0からのMACスーパフレームを受信した際、自分への宛先のMACフレームがQoS Data + CF-Pollフレームであり、かつ、CF-Pollで指定される送信許可時間(TXOP)の範囲に収まるのであれば、HT0へのデータフレームをパーシャルACKにアグリゲートして送信することができる。このとき、アグリゲートされたMACフレームのDuration(チャネル使用期間)には、SIFS時間+ACK伝送時間ではなく、SIFS時間+該無線端末のチャネル使用期間(TXOP)が指定される。これにより、HT1がHT0に対し、パーシャルACK（+データフレーム）を１物理フレームにアグリゲートして送信している間、他の端末(HT2、HT3)はNAVを設定することでフレームの衝突を回避出来る。また、HT1、HT2、HT3からのパーシャルACKにアグリゲートされたMACデータフレームに対する(パーシャル)ACK応答は、HT0から順次宛先毎に送信しても良いし、複数宛先へのパーシャルACK応答をアグリゲートして送信してもよい。なお、複数宛先へのMACフレームをアグリゲートしたMACスーパフレームを受信した際、該宛先へのフレームがパーシャルACKしか含まない場合は、DurationによるNAVを設定する必要はなく、ACK応答を返す必要もないことは言うまでもない。

なお、図３０の例では、第一種の物理層プロトコルで実現されるハイスループット端末(HT0〜HT3)の他に、第二種の物理層プロトコルで実現されるレガシー端末(Legacy)が存在する。レガシー端末は、図３３のような形態のMACスーパフレームを受信しても解釈不可能であため、チャネルがビジーからアイドルに移った後、EIFS(Extended IFS)のキャリアセンスを行い、その後もアイドル状態が続いていれば、バックオフを取る。

以上説明した本発明の第４の実施形態によれば、CF-Pollで指定されたTXOP等に基づいて時間差的パーシャルＡＣＫのタイミングを適切に設定できる場合は、パーシャルＡＣＫにデータをピギーバック（抱き合わせる）することによりスループットを向上できる。

（第５の実施形態）
図３０の例に示したように、第一種の物理層プロトコルで実現されるハイスループット端末並びに、第二種の物理層プロトコルで実現されるレガシー端末が共存している場合、レガシー端末はハイスループット端末のフレームを受信することができず、EIFSのキャリアセンスを行うことになる。一般にEIFSは、DIFS(Distributed Coordinate Function inter frame Space)やIEEE802.11eで規定されている優先度毎のフレーム間隔AIFS(Arbitration Inter Frame Space)よりも期間が長いため、メディアアクセスの権利が平等ではなくなる。そこで、図３４に示すように、複数の宛先へのパーシャルACKをアグリゲートする際に、MACスーパフレームの先頭にレガシー端末が理解できるMACヘッダを付加し、このMACヘッダとMACスーパフレーム本体（複数宛先のパーシャルACK）とを対象とする誤り計算を行なうためのFCSを末尾に付加する。

さらに、パーシャルACKがアグリゲートされたこの様なMACスーパフレームについては、第二種の物理層プロトコル(802.11aによるレガシー伝送)で送信する。該フレームを受信したレガシー端末は、PSDU(Protocol Size Data Unit)末尾に付加されているFCSによる誤り計算を元に、正しく受信することが出来ていれば、チャネルがアイドルになった後、図３５に示すように、ハイスループット端末と同様にDIFSのキャリアセンスを行なうことになる。

尚、タイプ、サブタイプはレガシー端末に認識される値ではないため、先頭のMACヘッダ以後の内容は、レガシー端末が解釈できる内容ではないが、PSDUが誤っていない限り、EIFSでなくDIFSのキャリアセンスを取ることが可能である。本実施形態を適用することにより、複数宛先へのデータ送信、送信期間内のパーシャルACK（アグリゲートしたデータ含む）の後、複数宛先へのパーシャルACKを送信する場合でも、レガシー端末でFCSの誤りになることはなく、DIFSの後、ハイスループット端末、並びにレガシー端末が平等にメディアアクセスを行なうことができる。

（第６の実施形態）
複数のMPDU(MAC Protocol Data Unit)を1つの物理フレームにアグリゲートするこれまでの実施形態は、アグリゲートされた複数のMPDUの前方部に、各MPDUの長さ情報(複数)と、及びそれらに対する1つのCRC(Cyclic Redundancy Check)を付加するというものであり、受信機側で、各MPDUの切り出しとFCS(Frame Check Sequence)の計算を行う。一方、本発明に係る第６の実施形態は、図３６に示すように、MPDU単位に、その長さを識別する情報等を付加するというものである。

図３６に示すように、各MPDUの前方に位置する"MPDU長"フィールド（要素）は、アグリゲートされたMPDUの長さをオクテット単位で示しており、"順番"フィールドは、この場合、PSDUの先頭からの連続的な番号を記載する。以下の実施形態の説明では、"MPDU長"、"順番"及びそれらに対するCRCフィールドを含み、アグリゲートされた各MPDUの先頭に付加されるこのような情報を「MPDUセパレーション」と呼ぶことにする。尚、第６及び第７の実施形態の説明では、アグリゲートするMPDUの数を8としているが、アグリゲート可能なMPDUの数は状況に応じて任意に定めることも可能である。

また、第６及び第７の実施形態において、複数MPDUをアグリゲートしたフレームに対しては、IEEE802.11eのQoS対応や複数宛先に対する送信のために、各種ビットマップを付加することも可能である。

図３７、図３８は、MPDUセパレーションのフォーマット例を示している。MPDUセパレーションは、後続のMPDUの長さをオクテット単位で示す"MPDU長"フィールド、MPDUセパレーションの番号を示す"順番"フィールド、及びMPDUセパレーションに対するCRCが存在する。

図３７の例1では、"MPDU長"、"順番"、"CRC"の他に、"予約"フィールドが1ビット存在する例を示しているが、もちろんこれらのフィールドの長さに限定はなく、図３７の例2のように、任意の固定長を取ることが可能であるのは言うまでもない。例えば、図３７の例2では、"予約"フィールドを0ビットのサイズにして、"順番"フィールドの大きさを拡張することもできる。図３７の例1、例2では、MPDUセパレーションの順番を、PSDUの先頭から連続的に数え上げていった場合に、その番号を"順番"フィールドに記載することを想定しているが、図３８のように、順番フィールドに対し、MPDUセパレーションに後続するMPDUの持つシーケンス番号、あるいはシーケンス番号及びフラグメント番号を指定することも可能である。PSDUの先頭から順次番号を割り当てる際は、数字が連続的であるならば、0、1、2、3、4のようにしても良いし、1、2、3、4、5のように割り当てても良い。MPDUのシーケンス番号(場合によってはフラグメント番号含む)に対応させる際は、アグリゲートしたフレームを送信する端末が、各MPDUのMACヘッダーを参照しながら、対応する値をMPDUセパレーション内に書き込んでいく。

典型的には図３６に示すようなMPDUセパレーションフィールドを有するフレームを受信した端末は、アグリゲートされたMPDU単位にFCSの検査を行い、受信ステータスをパーシャルACKとして送信側に返信する。MPDUセパレーションに付随するCRCは、"MPDU長"、"順番"などの情報を含めて保護しており、CRCの計算結果が正しければ、そのMPDUセパレーションは正常に受信できていると判断する。

図３９、図４０は、複数のMPDUをアグリゲートし、各MPDUの前方にMPDUセパレーションを追加したPSDUを受信した端末における受信状況の一例を示している。図３９に示すように、一番目のMPDUセパレーションがCRC検査の結果正常に受信出来ていた場合、その中に記載されている"MPDU長"の情報は正しいと判断されるため、後続するMPDU(図３９のMPDU 1)を切り出すことが出来る。各MPDUには、それぞれFCSが付随しているため、MPDUのFCSが正常であれば、そのMPDUを正しく受信したと判断することができる。

ここで、図３９の"MPDU セパレーション2"のように、あるMPDUセパレーションのCRC計算結果が誤りと診断された場合、次のMPDUセパレーションまで、連続的に検索処理を行う。この検索処理方法を図４１のフローチャートに示す。図４１に示すフローチャートにおけるポインタpは、PSDUの中での先頭からの相対的な位置を示す識別子であり、オクテット単位でPSDUの後ろに向けて移動するものとする。例えば、フローチャートで示されるように、ポインタpは最初PSDUの先頭を指しており（ステップＳ１）、その部分からMPDUセパレーションの長さ(この長さはCRCを含む。また、この長さは送受信間で互いに認識しているものとする)分を考慮して、MPDUセパレーションの誤り計算を行なう（ステップＳ２）。その結果、MPDUセパレーションが正常であれば、MPDUセパレーション内の"MPDU長"で指定される長さだけ、後続のMPDUを切り出し、該MPDUに対するFCSの計算を行なう（ステップＳ４）。前述したように、MPDUのFCSが正しければ、そのMPDUを正常に受信したとみなす。もしMPDUセパレーションのCRCが誤っているならば、ポインタpを1オクテット分だけ、PSDUの後ろに向けてずらす（ステップＳ３）。そして再度、MPDUセパレーション用のCRC計算を行なう。この時、ポインタpの示す位置から、MPDUセパレーションの長さ(CRC含む)分を考慮して、CRC計算を行なう。MPDUセパレーションに対するCRC計算の結果が誤りであれば、再度ポインタpを1オクテット後ろにずらして、MPDUセパレーションのCRC検査を行なう。この処理を続けて、MPDUセパレーション用のCRC検査が正常であれば、MPDUセパレーションフィールドの検索ルーチンを抜け出し、後続するMPDUのFCSの検査を行なう。MPDUの受信成功、失敗の判断は前述の手続きに従うものとする。

図３９の例に関して、"MPDUセパレーション2"が誤りであり、MPDUセパレーション探索の結果、"MPDUセパレーション3"が正常に受信できていたとする。MPDUセパレーションの長さは固定であり、その値が送受信機器間双方で認識されている場合を考えると、図３９の"MPDU 1"の後ろから、正常に受信できた"MPDUセパレーション3"までの間の長さが"MPDUセパレーション2"及び"MPDU 2"の占有する領域であると考えることができる。すなわち、そこからMPDUセパレーション長(固定)を差し引いた分が、MPDU長であることを推測できるため、該MPDUに対しFCSを検査することで、MPDUの受信状況を確認することが可能である。すなわち、MPDUの末尾はスキャンして見つける次の正常なMPDUセパレーションの直前であるとみなして誤り計算を行なう。つまり、図３９の例において、"MPDUセパレーション2"が誤っていても、"MPDU 2"の長さを推測してFCSを検査した結果が正常であれば、該MPDUを正常に受信できたと判断する。尚、図３９の"MPDU 2"に対するFCSの結果が誤りであれば、そのMPDUは正しく受信できなかったと判断することは言うまでもない。また、MPDUセパレーションへの"順番"が連続的に付与されるならば、図４０に示すように、2つの正常に受信できたMPDUセパレーションの番号が、2つ以上離れている場合は、それらに挟まれた複数のMPDU(図４０では、"MPDU2"、"MPDU3")が誤っていると判断する。

ここで、図４２、図４３の例を考える。シーケンス番号「1」〜「8」のMPDUを1つのPSDUにアグリゲートして送信し、その中で「2」「4」「6」が正常に受信されたとする。MPDUの受信状況の確認方法は前述の通りである。アグリゲートしたフレームの再送時に、「2」「4」「6」のMPDUに関しては、再送する(送る)必要がないため、図４３のように、MPDUセパレーションに続くMPDUのサイズは0にする。すなわち、図４３の"MPDUセパレーション「2」「4」「6」"内のMPDU長フィールドには、全て0を指定する。尚、ここでのMPDUセパレーションの"順番"は、MPDUのシーケンス番号に対応していても良いし、PSDUの先頭からの相対的な連続番号でも良いことは言うまでもない。あるいは、図５３のように、再送の必要のないMPDUに関しては、MPDUセパレーションそのものをなくし、"順番"もスキップさせることも出来る。図５３の例では、正常に送信できた「2」「4」「6」の番号を飛ばして、「1」「3」「5」「7」「8」の"順番"を持つMPDUセパレーション及びMPDUを1つの物理フレームにアグリゲートしている様子を示している。

（第７の実施形態）
上述した第６の実施形態では、MPDUセパレーションフィールド内に、"順番"(PSDUの先頭を基点とする番号、あるいはMPDUのシーケンス番号、フラグメント番号に対応する番号)の（サブ）フィールド要素が存在したが、本発明の第７の実施形態に係るMPDUセパレーションは、図４４に示すように、"順番"フィールドを含まないフォーマットとしている。

図４５に、"順番"フィールドが存在しない場合のMPDUセパレーションの具体的なフォーマットを示す。第６の実施形態の図３７、図３８のように、MPDUセパレーションに後続するMPDUの長さをオクテット単位で指定する"MPDU長"フィールド、"MPDU長"及び残りの"予約"フィールドに対するCRCが記載されることになる。

図４６、図４８に"順番"フィールドを含まないMPDUセパレーションフィールドを含む、PSDU(複数のMPDUがアグリゲートされている)の受信例を示す。図４６において、第６の実施形態と同様に、MPDUセパレーションのCRC計算の結果が正常であれば、その中の"MPDU長"の情報は正しいと判断できるので、続くMPDUを切り出し、FCSを検査することで、MPDUを正常に受信できたか否かを判断することが出来る。図４６において、一番目の"MPDUセパレーション"及び"MPDU1"は正常に受信されている。ここで、図４６において、PSDUの先頭から2番目の"MPDUセパレーション"のCRCが誤りであった場合を考える。この場合、第６の実施形態で述べたように、図４１に示したフローチャートの手続きに従って、1オクテットずつ連続的にCRCを検査することで、次の正しく受信されたMPDUセパレーションを検索していく。図４６の例では、PSDUの先頭から3番目の"MPDUセパレーション"が正常に受信された場合を仮定している。この時、第６の実施形態と同様に、正常に受信することのできた"MPDU 1"とPSDU先頭から3番目の"MPDUセパレーション"の間に、MPDUが存在すると仮定して、MPDUセパレーション長(送受信端末間で相互に認識している固定長)の長さを差し引き、該MPDUに対するFCSの検査を行なう。すなわち、MPDUの末尾はスキャンして見つける次の正常なMPDUセパレーションの直前であるとみなして、誤り計算を行なう。その結果、FCSが正常であれば、MPDUを正常に受信できていると判断する。図４６の例は、先頭から1番目と3番目の"MPDUセパレーション"がCRC検査の結果正常に受信出来ていて、それらの間を占有している2番目の"MPDUセパレーション"が誤っていても、直接、"MPDU2"に対してFCSによる誤り計算を実行することで、"MPDU2"が正常に受信できた場合の例を示している。MPDUへのFCSの計算結果が不正であれば、該MPDUは正しく受信出来なかった旨を表すパーシャルACKを作成することは言うまでもない。
図４７の例は、送信端末が、図４６のように複数のMPDUをアグリゲートして送信し、受信側での各MPDUセパレーション、及びMPDUに対する誤り計算の結果、一部のMPDUセパレーション(図４７では、先頭から3番目)が誤っていても、前後で正しく受信できたMPDUセパレーションの情報から、間に挟まれたMPDUが正常であった場合(MPDUのFCSを検査)であり、この時、アグリゲートしたフレームを受信した側が作成するパーシャルACKのビットマップは、全て正常を示す「1」が記載されている。尚、正常受信しているかどうかのビットは、正論理だけでなく、負論理でも実現可能であることは言うまでもない。

ここで、図４８に示すように、あるMPDUセパレーション(図の例では2番目)がCRC検査の結果誤っており、連続的に正常なMPDUセパレーションを検索していくとき、検索時に移動したオクテット数が、最大MPDU長(IEEE802.11規格で定められている、1MPDUが取り得る最大サイズであり、オクテット単位で指定)を越えた場合、2つ以上のMPDUセパレーション(及びMPDU)が誤っていると判断する。図４８における"最大MPDU長超"という表記は、最大MPDU長を越えた長さであることを示しており、以後同様に扱うことにする。この場合、受信機が返信するパーシャルACKフレームに対し、受信ステータスを示すパーシャルACKビットマップを作成する際、正常に受信できたフレームの相対位置が推測的となるが、図４９、図５０に示すような方法で送信側に受信状況を通知する。

図４９の例では、あるMPDUセパレーション(図では3番目のMPDUに対するMPDUセパレーション)が誤っており、次のMPDUセパレーションを検索するために連続的に1オクテットずつCRCを計算していった結果、5番目のMPDUへのMPDUセパレーションがCRC検査の結果、正常であった場合である。連続的にスキャンした結果、検索に要した移動数(オクテット数)が最大MPDU長を超えているため、2つの正常に受信できたMPDUセパレーションの間に存在する2つ以上のMPDUセパレーション(及びMPDU)が誤っていると判断することが出来る。ここで、1つのPSDUにアグリゲートされた複数のMPDUの長さは均等ではないため、2つの正常なMPDUセパレーションの間に、幾つのMPDUセパレーション(及びMPDU)が存在するか断定することは出来ない。よって、図４９のように、5番目のMPDUに後続する全てのMPDU（すなわち6番目のMPDU〜）が誤っていると判断し、パーシャルACKビットマップを作成する方法が考えられる。図４９の例では、先頭から2つまでのMPDUに対する受信が成功して、後のMPDUsが全て誤っている旨を送信側へのパーシャルACKによって通知する。尚、その結果、送信側は、3番目以降のMPDUを全て再送することになるが、1回目の送信で受信側では「5」番目のMPDUを正常に受信しているため、重複検査を経て、重複フレームを廃棄する。

パーシャルACK作成時の受信ステータスは、図４９のように後続のMPDUを全て誤りとみなす他、図５０のように、PSDUの最後から遡って推測する方法が挙げられる。ここでは、1PSDU内に存在するMPDUセパレーションの数が固定であり、その数を送受信端末が相互に認識しているものとする。図５０の例で、先頭から1番目、4番目の及び7番目、8番目のMPDUセパレーションがCRC計算の結果、正常に受信できていたとする。第７の実施形態において、順番を示す情報は含まれていない。PSDU内に存在するMPDUセパレーションの数が固定という前提で、1番目と4番目のMPDUセパレーションの間には2つのMPDUセパレーション(及びMPDU)、4番目と7番目のMPDUセパレーションの間にも2つのMPDUセパレーション(及びMPDU)が存在すると判断できる。正常なMPDUセパレーション間の検索に要したオクテット数が最大MPDU長を超えている場合、MPDUセパレーションに挟まれた間のMPDUに対するFCSを計算することは出来ないため、これらのMPDUは誤りとみなす。結果、図５０に示すように、受信側が送信側に返信するパーシャルACKのビットマップは、推測的に算出されたMPDUセパレーションの位置に対応したMPDUの受信ステータスを正しく(FCSの結果、正しく受信できたか否か)書き込み、検索期間が最大MPDU長を超えている部分に関しては、正常に受信出来なかった旨のビットマップを送信側に伝達する。

パーシャルACKを推測的に作成した場合、図５１のように、パーシャルACKビットマップ中の受信ステータスを示すビットが誤って(ずれて)伝達される場合も考えられる。この場合、図５１のように、PSDU中の2つのMPDUセパレーションが正しく検出され、それに続くMPDUのFCSが正常であったとしても、該MPDUが、アグリゲートされたPSDUの相対的にどの部分に存在するかの推定がずれる可能性がある。図５１の例では、「1」〜「8」のシーケンス番号のMPDUをアグリゲートして送信した場合で、1番目と5番目のMPDUセパレーション及びMPDUが正常に受信されていたとしている。この時、受信端末が作成するパーシャルACKは、図５１のように複数通りの受信ステータスが考えられることになる。MPDUセパレーション間を検索する長さが、最大MPDU長を超えている場合、2つの正常なMPDUセパレーション間に幾つのMPDUセパレーション(及びMPDU)があるかを判断することができないためである。図５１の例で作成されたパーシャルACKビットマップ2種類のうち、下段のビットマップ(1 0 0 0 1 0 0 0)は推定が成功した場合であり、この情報を持つパーシャルACKを受信した場合、アグリゲートしたフレームを送信した端末では、適切にウィンドウ制御並びに再送制御を行なうことが可能である。ここで、受信ステータスがずれた状態(図５１の上段：1 0 0 1 0 0 0 0)を持つパーシャルACKが返信されたならば、送信側ではシーケンス番号「4」のフレームを正常に送信できたとみなし(実際には送信できていない)、シーケンス番号「5」のフレームを再送対象とする（「5」は正常に送信済み）。
図５２は、これら再送時のフレーム制御を示したものである。パーシャルACK作成時の推定が成功した下段の例では、再送用の「2」「3」「4」「6」「7」「8」と、ウィンドウ制御によって新しい「9」のMPDUをアグリゲートした様子を示している。上段の例では、受信側では正しく受信された「5」を再送対象としている。しかし、上段の例においても、複数のMPDUをアグリゲートしたフレームを再送した際、受信側からのパーシャルACK(その時点で受信したアグリゲートフレームに対する受信ステータスを返す)や重複検査を利用する結果、シーケンス番号「4」のMPDUを受信側で諦めることによって、以後のフレームシーケンスに影響が出ることはない。パーシャルACKは、あくまで複数MPDUをアグリゲートしたフレームを受信した際、その時点で各MPDUに対する受信ステータスを送信側に通知する手段であるため、送信側でのウィンドウ制御に支障が出ることは無く、再送が無限に繰り返されるようなこともない。影響としては、おおよそ1個のMPDUが欠損する程度であるに過ぎない。

尚、第７の実施形態において、IEEE802.11eで規定されているトラフィックストリーム設定時に、伝送可能なMSDUのサイズを固定長にする方法や、適切な量のビットをパディングすることで、PSDU内にアグリゲートされた全てのMPDUが均等な固定長となる場合には、各MPDUの相対位置をより正確に判断することも可能である。

（第８の実施形態）
図５４のように、ある送信端末が複数のMPDUを1つのPSDUにアグリゲートして送信する場合を考える。アグリゲートされたフレームを受信した端末は、各MPDUの受信状況を検査し、パーシャルACKビットマップを作成、SIFS期間後に送信側に返信される。しかし、図５４のように、パーシャルACKが誤り、送信側で正しく受信されない場合、DIFS(Distributed Coordination Function Inter Frame Space)、あるいはIEEE802.11eで規定されている優先度毎のフレーム間隔であるAIFS(Arbitration Inter Frame Space)の期間のキャリアセンスと、バックオフを行なった後、全てのMPDUを再送しなくてはいけない問題がある。

そこで、本発明の第８の実施形態では、図５５のように、複数のMPDUを1つのPSDUにアグリゲートして送信した端末が、SIFS期間後にIEEE802.11の物理フレームを検出したものの、中身のPSDUがFCS検査の結果、誤りであった場合、PIFSあるいはSIFSの後に、パーシャルACKの再送要求を宛先に向けて送信する。このPIFSあるいはSIFSの期間は、その間他の端末からのフレーム送信の割り込みを防ぐ目的であり、本実施形態では、どちらか一方に限定されないことは言うまでもない。これらのフレーム間隔は、送受信端末間で何かしらのネゴシエーションを行なっても良いし、予め全ての端末間で合意が取れている前提でも良い。

パーシャルACK再送要求を受信した端末は、PIFSあるいはSIFS前(すなわち直前)に自身がパーシャルACKを送信しており、かつパーシャルACK再送要求を送信してきた端末に該当するならば、直前に送信したパーシャルACKの内容を、そのままパーシャルACK再送要求送信端末に向けて送信する。そのため、アグリゲートされたPSDUを受信した端末は、一定期間(最低PIFS)の間、受信ステータスを保持しておくことが望ましい。図５６に、パーシャルACK再送要求のフレームフォーマットを示す。IEEE802.11のMACヘッダー内のタイプ、及びサブタイプ情報により、受信側ではパーシャルACK再送要求フレームを識別する。あるいは、図５６のように新たなフレームを定義する代わりに、(MPDUセパレーション、あるいはMACスーパーフレームヘッダー内の)MPDU長情報を全て0に指定したPSDU(この時MPDUそのものはアグリゲートしていない)を送信し、受信側でPSDU内のMPDU長が全て0の場合、直前に送信したパーシャルACKを再送するように送受信端末間で取り定めても良い。また、図５６のように新しいフレームを定義する場合は、複数宛先に対する複数個のパーシャルACK再送要求フレームをアグリゲートし、第１の実施形態、第２の実施形態のように、時間差的なパーシャルACK(再送分)を送受信するような方式を取ることも出来る。

本発明の第８の実施形態によれば、送信側では全てのMPDUを送り直す必要がなく、より効率的な再送制御を行うことが可能となる。また、IEEE802.11eなどのQoS制御とも併せて使用できることは言うまでもない。

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

本発明の実施形態に係る通信装置の構成を示すブロック図 アクセスポイント（AP）と複数の端末(STA)との間のダウンリンク、および該ダウンリンクにおけるユニキャストフレームの送信シーケンスを示す図 パーシャルACKフレームの衝突を説明するための図 本発明の実施形態に係るＭＡＣスーパーフレームヘッダーのフォーマット例を示す図 本発明の実施形態に係るＭＡＣスーパーフレーム全体のフォーマット例を示す図 本発明の実施形態に係る宛先の開始位置を表すマルチアドレスビットマップを示す図 本発明の実施形態に係る宛先の変化を表すマルチアドレスビットマップを示す図 パーシャルACKのビットマップ情報の一例を示す図 宛先が順不同でアグリゲートされた場合およびマルチアドレスビットマップを用いない場合の問題を説明する図 本発明の実施形態に係る受信端末の動作を示すフローチャート 本発明の実施形態に係り、異なる時間間隔でパーシャルＡＣＫを送信する様子を示す図 本発明の実施形態に係り、異なる時間間隔でパーシャルＡＣＫを送信する様子を示す図であって、ある宛先の全てのＭＡＣフレームに受信エラーが生じた場合を説明するための図 本発明の第１の実施形態に係るフレームシーケンスを示す図 ＱｏＳを実施する場合の通信手順の概略図 本発明の第２の実施形態に係るダウントラフィックを示す図 QSTA毎のダウンリンクトラフィックの宛先キューを示す図 ラウンドロビンによるフレーム送信を説明するための図 QSTAへのダウンリンクトラフィックにおける送信回数に重み付けを説明するための図 CAP(Controlled Access Phase)を示す図 異なる宛先のアグリゲーションを行わない場合を示す図 本発明の第２の実施形態に係り、複数の宛先のフレームアグリゲーションをＱｏＳとともに実施する場合を示す図 IEEE802.11eで規定されているブロックACKによるフレームシーケンスを示す図 本発明の第３の実施形態に係り、複数のブロックACK要求フレームを1つのフレームにアグリゲートする場合のフレームフォーマットを示す図 本発明の第３の実施形態に係るフレームシーケンスを示す図 本発明の第３の実施形態に係り、ブロックACK要求のみならず、（ACKを必要としない）データフレームとともにアグリゲートする場合を示す図 本発明の第４の実施形態に係る通信装置の構成を示すブロック図 ＭＡＣスーパーフレームのフォーマットの一例を示す図 複数の宛先を持つＭＡＣスーパーフレームの一例を示す図 複数の宛先への送信およびパーシャルＡＣＫの時間差受信を示す図 本発明の第４の実施形態に係るキャリアセンス状態を示す図 宛先毎のＮＡＶの設定を示す図 ＱｏＳデータとＣＦ−Ｐｏｌｌフレームのアグリゲーション例を示す図 複数の宛先へのパーシャルＡＣＫフレームのアグリゲーション例を示す図 本発明の第５の実施形態に係り、レガシー端末によりフレームチェックが可能なフォーマットの一例を示す図 本発明の第５の実施形態に係るキャリアセンス状態を示す図 本発明の第６の実施形態に係るMPDUセパレーションフィールドとMPDUのアグリゲーションを示す図 MPDUセパレーションのフォーマットを示す図 MPDUセパレーションのフォーマットを示す図 PSDUの受信状態およびMPDUの抽出を説明するための図 PSDUの受信状態およびMPDUの抽出を説明するための図 MPDUセパレーションの検索手順を示すフローチャート アグリゲート送信とパーシャルACKを示す図 再送時のアグリゲーション例を示す図 本発明の第７の実施形態に係るMPDUセパレーションフィールドとMPDUのアグリゲーションを示す図 MPDUセパレーションのフォーマットを示す図 PSDUの受信状態およびMPDUの抽出を説明するための図 アグリゲート送信とパーシャルACKを示す図 PSDUの受信状態およびMPDUの抽出を説明するための図 アグリゲート送信とパーシャルACKを示す図 アグリゲート送信とパーシャルACKを示す図 パーシャルACKビットマップの推定について説明するための図 パーシャルACKビットマップの推定について説明するための図 再送時のアグリゲーション例を示す図 本発明の第８の実施形態に係るパーシャルACK再送要求を説明するための図 本発明の第８の実施形態に係るパーシャルACK再送要求を説明するための図 パーシャルACK再送要求のフレームフォーマットを示す図

符号の説明

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

Claims (3)

1. 複数のＭＰＤＵ（ＭＡＣプロトコルデータユニット）と前記複数のＭＰＤＵを分離する分離情報とを含む１つのフレームを生成し、宛先の通信装置に前記フレームを送信する送信手段を具備し、
   前記分離情報は、ＭＰＤＵの長さ情報と、前記ＭＰＤＵの長さ情報を保護するＣＲＣ（巡回冗長検査）情報とを有し、
   前記送信手段は、再送の対象でないＭＰＤＵの長さ情報がゼロの分離情報を生成することを特徴とする通信装置。
2. 複数のＭＰＤＵ（ＭＡＣプロトコルデータユニット）と前記複数のＭＰＤＵを分離する分離情報とを含む１つのフレームであって、前記分離情報は、ＭＰＤＵの長さ情報と、前記ＭＰＤＵの長さ情報を保護するＣＲＣ（巡回冗長検査）情報とを有し、再送の対象でないＭＰＤＵの長さ情報がゼロである分離情報を含むフレームを受信する手段と、
   前記ＣＲＣ情報を用いて、前記ＭＰＤＵの長さ情報に受信異常が生じたか否かを検査する手段と、
   前記ＭＰＤＵの長さ情報をもとに特定される当該ＭＰＤＵのＦＣＳ（フレームチェックシーケンス）を用いて、該ＭＰＤＵを正常に受信できたか否かを検査する手段と、
   各ＭＰＤＵを正常に受信できたか否かを表す受信ステータスを作成して送信する手段とを具備する通信装置。
3. 前記ＣＲＣ情報を用いる検査により受信異常が検出されたならば、正常に受信された次のＭＰＤＵの長さ情報を検索する手段と、
   検索されたＭＰＤＵの長さ情報に基づいて、対応するＭＰＤＵのＦＣＳ（フレームチェックシーケンス）を特定する手段と、
   特定されたＦＣＳを用いて前記ＭＰＤＵが正常に受信できた否かを検査する手段とを具備する請求項２記載の通信装置。

Images