JP4374001B2 - 通信装置、通信方法、および通信システム - 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規格のＱｏＳについて言及しており、無線ネットワークにおける通信装置間の通信に優先順位を付与する方法を開示する。
米国特許第５３２９５３１号明細書 特開２００２−３１４５４６公報

通信速度の高速化の実現において既存の規格と同一の周波数帯を用いるのであれば、新たに提供される通信装置は、既存の規格に従う通信装置との共存が可能であって、後方互換性も維持されることが好ましい。したがって、ＭＡＣ層のプロトコルは基本的には既存の規格と整合するＣＳＭＡ／ＣＡに従うのが良いと考えられる。この場合、ＣＳＭＡ／ＣＡに係わる時間的なパラメータ、例えばフレーム間の時間間隔(IFS: Interframe Space)やバックオフ期間を既存の規格と揃える必要がある。

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

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

本発明はかかる問題を解決すべくなされたものであり、既存の装置との共存が可能であって、しかもフレームフォーマットの効率化により複数のフレームを送信することに伴うオーバヘッドを解消して通信の実質的なスループットを向上できる通信装置、通信方法、および通信システムを提供することを目的とする。

本発明の一観点に係る通信装置は、複数のＭＡＣフレームがアグリゲートされた１つの物理フレームを作成する物理フレーム作成手段と、
前記物理フレームを送信する送信手段と、前記物理フレームの終了に暗黙の送達確認要求として応答された送達確認フレームを受信する受信手段とを具備する通信装置である。

本発明のさらに別の観点に係る通信装置は、複数のＭＡＣフレームがアグリゲートされた１つの物理フレームを受信する受信手段と、前記受信手段が受信した物理フレームの終了に暗黙の送達確認要求として応答し、該物理フレーム内の複数のＭＡＣフレームについての受信状況を送達確認ビットマップとして含み、該物理フレームにおいて正常に受信できた先頭のＭＡＣフレームのシーケンス番号が送達確認始点シーケンス番号に設定された送達確認フレームを作成する作成手段と、前記送達確認フレームを送信する送信手段とを具備する通信装置である。

本発明によれば、フレームフォーマットの効率化により複数のフレームを送信することに伴うオーバーヘッドを解消して通信の実質的なスループットを向上できる通信装置、通信方法、および通信システムを提供できる。

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

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

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

IEEE802.11e Draft 8.0によれば、MAC(媒体アクセス制御；Media Access Control)層の伝送効率を改善するための技術として、ブロックACK(Block ACK)が提案されている。ブロックACKでは、端末が、あるチャネル使用期間(TXOP: Transmission Opportunity)の間、QoS(Quality of Service)データをSIFS(Short Inter Frame Space)とよばれる最小フレーム間隔で送信し、その後、受信端末に対し、過去の受信履歴状況を要求するためにブロックACK要求(Block ACK Request)を任意のタイミングで送信する。受信側では、ブロックACK要求の定める始点シーケンス番号を元に、過去の受信ステータス状況をビットマップ形式に変換し、ブロックACK(Block ACK)として応答する。

図２及び図３は、IEEE802.11e Draft 8.0で規定されているブロックACK要求のフレームフォーマット、及びブロックACKのフレームフォーマットをそれぞれ示したものである。図２及び図３におけるFrame Control(フレーム制御)フィールド、Duration(期間)フィールド、Receiver Address(宛先アドレス)、Transmitter Address(送信元アドレス)は、IEEE802.11で規定されているMACヘッダーである。BAR Control(Block ACK Request Control)フィールドには、4ビットのTID(Traffic Identifier: 優先度識別子)が存在する。QoSデータは優先度(TID)毎に存在し、それぞれ独立的にシーケンス番号、及びフラグメント番号が割り当てられることから、ブロックACKにおける受信ステータスも、優先度毎に用意する必要がある。ブロックACK要求のBAR ControlのTIDフィールドは、この優先度を指定するために用いられる。図２のブロックACK要求のBlock ACK Starting Sequence Control（始点シーケンス制御）は、4ビットのフラグメント番号フィールド、及び12ビットのStarting Sequence Number(始点シーケンス番号)フィールドから構成されている。Starting Sequence Numberは、受信端末が過去の受信履歴を遡り、Starting Sequence Numberに対応するシーケンス番号からの相対的な受信ステータスを元にブロックACKを作成するために用いられる。図３のブロックACKのBA Controlは、図２のBAR Controlと同様に、4ビットのTIDフィールドを含む。Block ACK Starting Sequence Control（始点シーケンス制御）は、該ブロックACK中のBlock ACK Bitmap３０の示す受信ステータスの始点シーケンス番号を示す。IEEE802.11e Draft 8.0によれば、Block ACK Bitmap３０のサイズは1024ビットの固定長であり、これにより最大64MSDU(MAC Service Data Unit)のデータに対する受信履歴を通知することが可能である。1MSDUは、最大で16個のフラグメント(分割)化されたMPDU(MAC Protocol Data Unit)を含むことができる。尚、図２及び図３のそれぞれのMACフレームには、誤り検査のためのFCS(Frame Check Sequence)が付加される。従って、最大1024MPDUに対する受信履歴の通知を行なうために、Block ACK Bitmap３０のサイズは1024となる。

図４及び図５はHCCA(Hybrid coordination function Controlled Channel Access)におけるブロックACK伝送のシーケンス例を示している。同図に示すHC(Hybrid Coordinator)は、IEEE802.11e Draft 8.0におけるQoSアクセスポイント(QoS-AP)であり、スケジューリングの主体となって、QoS端末(QSTA: QoS Station)へのチャネル使用期間(TXOP)の付与、ダウンリンク(HCからQSTAへの下り方向)伝送を行う。QSTAへのTXOPの付与は、HCからのQoS CF-Pollフレーム(QoS Contention Free-Poll: HCがQSTAに送信を許可するために送信するQoS対応ポーリングフレーム)を元に行われる。図４において、まずHCがQSTA1に対し、QoS CF-Pollフレームを送信することでチャネル使用期間(TXOP1)を与える。QSTAはTXOPの間、任意のフレームを送信することが可能であるが、図４の例では、QSTA2にQoSデータをSIFS間隔で送信している。QSTA1のTXOP期間が終了すると、今度はHCがQSTA1に対しQoSデータをバースト的に送信している(TXOP2)。HCのチャネル期間が終了すると、HCはQSTA1に再びチャネル使用期間(TXOP3)を付与する。QSTA1は、QSTA2にブロックACK要求を送信することで、Block ACK Starting Sequence Controlで指定される相対的な受信ステータスを宛先に要求する。図４は、即時型ブロックACKの例であり、この場合、ブロックACK要求を受信した端末はSIFS期間後にブロックACKを応答しなくてはならない。具体的には、QSTA2はQSTA1からのブロックACK要求４０に対しSIFS期間後にブロックACK４１を応答しなければならない。また、TXOP4において、QSTA2はHCからのブロックACK要求４２に対しSIFS期間後にブロックACK４３を応答しなければならない。

一方、図５は遅延型ブロックACKの例を示しており、ブロックACK要求を受信した端末は、まずIEEE802.11のACKを返し、任意の期間後にブロックACKを送信する。具体的には、QSTA1からのブロックACK要求５０を受信したQSTA2は、まずIEEE802.11のACK５１を返し、任意の期間後にブロックACK５２を返す。最後にブロックACKを受け取ったデータ送信端末が、ACKを返信することで遅延型ブロックACKの一連のシーケンスが完了する。尚、ブロックACK対象のQoSデータは、従来のMACヘッダーに対しIEEE802.11e Draft 8.0用に拡張されたQoS Control field中の、Ack Policyフィールドを用いて受信側に通知される。

図６及び図７を参照してブロックACK作成に必要な処理手順を説明する。図６において、送信端末がQoSデータをバースト的に送信した後、任意のBlock ACK Starting Sequence Controlを指定(図６の例ではシーケンス番号「1」、フラグメント番号「0」)したブロックACK要求を送信する。受信端末では、送信元アドレス、優先度(TID)毎に受信履歴を記憶しており、Block ACK Starting Sequence Controlに該当するフレームまで遡って、そこからの相対的な受信ステータスを64MSDU分(1024ビット)のブロックACKビットマップ(Block ACK Bitmap)として作成する。図６及び図７の例では、送信側が、シーケンス番号「1」のMSDU(3分割にフラグメント)、シーケンス番号「2」のMSDU(フラグメント無)等を送信した場合を想定している。図６のビット番号６０はブロックACKビットマップの先頭からの相対位置を示している。図６のブロックACKビットマップ６１の例では、送信側が送ったQoSデータのうち、シーケンス番号「1」のMSDU(フラグメント番号６３が「0」「1」「2」)は正常に受信しているが、シーケンス番号「2」のMSDU(フラグメント無)は誤り等により受信失敗したことを示している。ブロックACKのBlock ACK Starting Sequence Control６２は、ブロックACK要求で指定された値をコピーして送信する。図７の送信端末は、ブロックACKのBlock ACK Starting Sequence Control、及びブロックACKビットマップの内容を元に、再送すべきフレームを決定する。図６及び図７の例では、シーケンス番号「2」(フラグメント無)が誤っていることから、ブロックACKビットマップ６１の該当部分が"0"になっている。結果、送信端末はシーケンス番号「2」のMSDU(フラグメント無)を再送しなくてはならないことを判断する。

以上のように、IEEE802.11e Draft 8.0で定められているブロックACKは、QoSデータ受信側でするべき処理が多く、ブロックACK要求を受信してからSIFS期間後にブロックACKを応答する、即時型ブロックACKの実現が一般に難しいと考えられている。

そこで本発明の実施形態では、かかる問題を解決するための手法を提案する。本発明の第一の実施形態は、複数MPDUがアグリゲートされ、かつ該複数MPDUの末尾にブロックACK要求がアグリゲートされたPSDUを受信した場合、受信ステータスを反射的に即時型ブロックACKとして応答するというものである。

IEEE802.11の規定によれば、フレームのサイズが予め定められた閾値よりも大きい場合、フラグメント(分割)処理がなされる。フラグメント化したMPDUには、フラグメント番号が割り当てられる。MACヘッダー内のフラグメント番号はMSDU内での当該MPDUの相対位置を表す値で、通常は0から始まる連続値を取る。受信端末では、このフラグメント番号、及びシーケンス番号を元に、元のMSDUへと組み立てる。

一般に、IEEE802.11及びIEEE802.11e Draft 8.0のMAC伝送手順では、フラグメント化したMPDUをSIFS間隔で送信することから、フレーム間隔(SIFS)分のオーバーヘッドが生じて伝送効率が低下する。したがって、ハイスループット化を実現するためには、フラグメント化をしないことが望ましい。フラグメントをしないことを前提とする本実施形態に従えば、図８に示すように、Block ACK Bitmap８０のビット数を最大64MPDU分に圧縮することが可能である。つまり、block ACK Bitmap８０のサイズは、１つのMSDUに対し１つのMPDUが対応する場合の、最大MSDU数に相当し、64ビット、つまり従来の16分の1に抑えられる。

以後、図８に示すようなブロックACKフレームを「圧縮ブロックACK（圧縮送達確認）」と呼ぶことにする。送受信端末間で圧縮ブロックACKを用いてブロックACK伝送を行う際には、予めネゴシエーションを行ってもよい。具体的なネゴシエーションの方法としては、例えばIEEE802.11e Draft 8.0に記述されるブロックACK設定の手順を拡張することが考えられる。つまり、ADDBA要求により圧縮ブロックACKを用いることを要求し、ADDBA応答により圧縮ブロックACKの使用許可、ないしは拒絶を行なうといったものである。この設定の対象となったデータ、ブロックACK要求、（圧縮）ブロックACKのフレーム交換に際し、全てが圧縮ブロックACKで応答しなければならないという制約を設けても良いし、通常のブロックACKと圧縮ブロックACKを取り混ぜて応答することを許容しても良い。また、ブロックACK要求に通常のブロックACKではなく、圧縮ブロックACKを要求または許容する情報を追加しても良い。ブロックACK要求で圧縮ブロックACKを要求または許容する方法は、事前のブロックACK設定手順がある場合にも、無い場合にも適用することが出来る。

また、MACレベルでハイスループットを実現するために、個々のMPDUを１つのPSDUにアグリゲートし、一度に送信する方法が考えられる。図９及び図１０に複数MPDUのアグリゲート例を示す。図９の例では、PSDU内の個々のMPDUの先頭に、MPDUの長さを示すフィールドと、MPDUの長さ情報に対するCRC(Cyclic Redundancy Check)が存在する。MPDUの長さ情報とCRCを併せて、以下、「MPDUセパレーションフィールド」と呼ぶことにする。なお、MPDUセパレーションフィールドには、他の付加的な情報、予約領域、バイトアラインメントを整えるための領域（例えば4バイトアラインメントに揃うようにする）などが含まれていても構わない。図９のようなPSDUを受信した端末は、先頭から順に、MPDUセパレーションフィールドが誤りでなければ、後続するMPDUを切り出し、MPDUのFCS(Frame Check Sequence)を計算する。MPDUセパレーションフィールドが誤りであった場合、続くMPDUの長さが分からないため、適切なバイト単位で連続的にMPDUセパレーションフィールドのCRCを計算(スキャン)していく。CRC計算の結果が正しいMPDUセパレーションに関しては、後続のMPDUに対するFCSを計算し、正常に受信できたかどうかの判断をする。

一方、図１０のアグリゲート例では、PSDUの先頭に複数のMPDUに対する長さ情報がヘッダーとして存在し、複数の長さ情報に対するCRCが付加される。以後、このヘッダーを「MACスーパーフレームヘッダー」と呼ぶことにする。図１０のPSDUを受信した端末は、MACスーパーフレームヘッダーのCRC計算を行い、誤りであれば、全てのMPDUが誤ったと判断する。MACスーパーフレームヘッダーが正常に受信できていれば、アグリゲートされた個々のMPDUに対してFCSの計算を行い、正常に受信できたかどうかの判断をする。

さらに、図９及び図１０の例では、複数MPDUをアグリゲートしたPSDUの最後に、ブロックACK要求フレーム９０，１０１をそれぞれアグリゲートしている。尚、図９及び図１０の例では、アグリゲート可能なMPDUの最大数を8としているが、この数は8に制限されたものではなく、任意の数を取ってもよいことは言うまでもない。アグリゲート可能な最大数は、予め取り決めておくか、送受信端末間で何かしらのネゴシエーション等を行なう必要があるが、具体的な手続き方法に関しては、詳細には説明しない。

図１１乃至図１３を参照して、本発明の実施形態に係る基本的な概念を説明する。ここで、送信端末は連続的に割り当てられたシーケンス番号「1」〜「7」のMPDUを送信するものとする。送信端末は、図９又は図１０に示したいずれかの手法で複数のMPDU(QoSデータ)を１つのPSDUにアグリゲートし、その末尾に、複数MPDUに対するブロックACK要求１１１をアグリゲートする。ブロックACK要求１１１のBlock ACK Starting Sequence Controlの値は、PSDU内にアグリゲートした先頭のMPDUのMACヘッダーに記載されているシーケンス番号と同一にする。ここで送信端末は、様々な宛先、優先度のMACフレームを格納するメインのキューと、アグリゲートしたMPDUを再送するためのサブキューを持つ。図１１の例では、シーケンス番号「1」〜「7」のMPDUのコピーを再送に備えてサブキュー内に保存しておく。複数MPDUがアグリゲートされたPSDUを受信した端末は、前記の方法によって複数MPDUの誤り計算を行なう。例えば、図１１の例では、PSDU内のシーケンス番号「2」と「5」のMPDUがFCS計算の結果、誤りであった場合である。本発明の実施形態において、PSDU受信端末は、その時点での受信ステータスをBlock ACK Bitmap（ブロックACKビットマップ）１１２として作成する。すなわち、図１１の例では、1が正常受信、0が受信失敗として、1011011のようなビットマップ構成で表される。ここで、正論理と負論理を入れ替えて使用しても良いことは言うまでもない。そして、PSDU内にアグリゲートされた最後のMPDUが正常に受信できていた場合、データ送信端末に対し、その時点で作成したBlock ACK Bitmap１１２を用いて、図１２に示すような圧縮ブロックACK１１３を作成する。

１つのPSDU内にアグリゲート可能な最大数に対し、アグリゲートされていたMPDUの数が少ない場合、Block ACK Bitmap１１２には0を入れてパディングする。図１１の例でアグリゲート可能な最大数を64MPDUとすると、10110110000...で示されるビットマップ構成となる。もしくは、受信端末側で、PSDU内にアグリゲートされていたMPDUの個数に応じて、Block ACK Bitmap１１２のビットマップ長を可変にしても良い。可変にした場合、図８のブロックACKのBAコントロールフィールドにビットマップ長を示す情報を追加しても良い。圧縮ブロックACK１１３のBlock ACK Starting Sequence Controlの値は、ブロックACK要求１１１の値をコピーする。図１２において、ブロックACKを受信したデータ送信端末は、圧縮ブロックACK１１３のBlock ACK Starting Sequence Controlの示す値と、自身の送信したMPDUのシーケンス番号とを対比し、Block ACK Bitmap１１２の情報から、正常に送信できたMPDUを検出し、再送の必要のあるMPDUを決定する。図１２の例では、シーケンス番号「2」と「5」の部分のBlock ACK Bitmap１１２が0になっているため、この２つのフレームが再送の必要なMPDUであると判断する。

再送すべきMPDUを決定した後、受信端末側のバッファ容量の許す範囲内であれば、新規にMACフレーム１２０をメインキューから取り出し、シーケンス番号の割り当てとPSDUへのアグリゲーションを行なう。この時、サブキュー内のMPDUはキューの先頭から連続的に送信成功したものを削除することができる。新規に追加するMPDU１２０の個数等は、例えばスライディングウィンドウ制御と呼ばれる技術を用いて実現される。再送分１２１を含めた複数MPDUをアグリゲートしたPSDUの末尾には、それらに対するブロックACK要求１２２をアグリゲートする。

図１３は、以上の内容を踏まえた基本的なシーケンス例を示している。端末が与えられたTXOP期間内で、複数のQoSデータを１つの物理フレームにアグリゲートし、PSDUの末尾にブロックACK要求をアグリゲートすることで、受信側に対し、即時的なブロックACKの送信を促す。データ受信側では、PSDU内の複数MPDUの受信ステータスをブロックACK要求の部分を除いて計算し、その情報をそのままBlock ACK Bitmapに対応付けて圧縮ブロックACKを返信する。具体的には、例えばTXOP期間1において、QSTA1は複数のQoSデータを１つのPSDU１３０にアグリゲートし、該PSDU１３０の末尾にブロックACK要求１３１をアグリゲートすることで、受信側に対し、即時的なブロックACKの送信を促す。データ受信側のQSTA2は、PSDU１３０内の複数MPDUの受信ステータスをブロックACK要求１３１の部分を除いて計算し、その情報をそのままBlock ACK Bitmapに対応付けて圧縮ブロックACK１３２を返信する。

従来方式とは異なり、過去の受信履歴をブロックACK要求のBlock ACK Starting Sequence Controlに基づいて検索するようなことはないため、比較的負荷の大きい検索処理を削減し、SIFSという限られた期間で部分応答を返すことがより容易となる。また、一般に検索時間と回路規模はトレードオフの関係にあるため、許容される最大処理遅延が同じ場合に、回路規模を削減することが出来るという言い方も出来る。

次に、受信に誤りが生じた際の再送制御例について説明する。

まず、図１４乃至図１６を参照して、再送制御例１を説明する。本例では、データ送信端末がシーケンス番号「1」〜「7」のMPDUを１つのPSDUにアグリゲートし、PSDUの末尾にブロックACK要求をアグリゲートして送信した状況を想定する。図１４の例のように、ブロックACK要求の部分１４０がFCS計算の結果誤りであると、受信端末は圧縮ブロックACKを返信することができない。そこで本発明の実施形態では、複数のMPDUがアグリゲートされたPSDUを受信した端末は、たとえ圧縮ブロックACKを返信できないとしても、その時点での複数MPDUの受信ステータスを１回分のBlock ACK Bitmapとして記憶しておくものとする。図１４の例では、1011011というビットマップ情報１４１が受信側で記憶される。また受信側では、当該端末が最後に正常受信したMPDUのシーケンス番号を併せて記憶する。図１４では、シーケンス番号「7」のMPDUがこれに該当する。１回分の圧縮ブロックACK用のビットマップ情報１４１と最後に受信したMPDUのシーケンス番号は、データ送信端末、優先度毎に記憶しておくことが望ましい。

複数MPDUをアグリゲートしたPSDUを送信した後、一定時間経過しても宛先からの圧縮ブロックACKが受信できなかった場合、送信端末は、アグリゲートした複数MPDUのうち、先頭のMPDUのシーケンス番号をBlock ACK Starting Sequence Controlの値として、ブロックACK要求を再送する。通常は直前のPSDUにアグリゲートしたブロックACK要求をそのまま再送すればよい。但し第二の実施形態のようにブロックACK要求を省略して直前のPSDUにアグリゲートしなかった場合には、このようにブロックACK要求を新たに構成する必要がある。図１４の場合、Block ACK Starting Sequence Controlには、前回送信した「1」〜「7」のシーケンス番号を持つMPDUのうち、先頭のMPDUである「1」を記載する。また、このブロックACK要求１４２は、基本的に他のフレームとアグリゲートを行なわないものとする。他のMPDUがアグリゲートされていないブロックACK要求１４２を受信した端末は、ブロックACK要求１４２内のBlock ACK Starting Sequence Controlの値と当該端末が最後に正常受信したMPDUのシーケンス番号を比較する。Block ACK Starting Sequence Controlの値が、最後に受信したMPDUのシーケンス番号と同等であるか、それより古い(前の)番号であれば、１回分の圧縮ブロックACK送信用として保持しておいた、ビットマップ情報１４１をBlock ACK Bitmapの情報としてそのまま利用し、SIFS期間の後、図１５に示すように圧縮ブロックACK１５０で反射的に応答する。図１５の例では、前回受信したPSDU内の複数MPDUの受信ステータス1011011をそのままBlock ACK Bitmapとして、送信端末に圧縮ブロックACK１５０を返信する。圧縮ブロックACK１５０のBlock ACK Starting Sequence Controlの値は、ブロックACK要求１４２のBlock ACK Starting Sequence Controlの値をコピーする。
ビットマップ情報１４１を作成したときに前提としたBlock ACK Starting Sequence Controlと、ブロックACK要求１４２のBlock ACK Starting Sequnece Controlが異なる場合もある。これは、例えばアグリゲートされた先頭MPDUが壊れ、かつブロックACK要求も壊れており、受信側が正常に受信できた最初のMPDUのシーケンス番号を先頭と仮定して、ビットマップ情報１４１を作成したような場合に生じる。ビットマップ情報１４１の始点のシーケンス番号が後者と矛盾しなくなるようにビットマップ情報１４１を変換する。あるいは、ビットマップ情報１４１はそのままにして、応答するブロックACKのBlock ACK Starting Sequence Controlをビットマップ情報141を作成したときに前提とした値（つまりブロックACK要求とは異なる値）に設定する。なお、受信側はビットマップ情報１４１を生成した際に仮定した先頭のシーケンス番号を記憶しておいても良い。記憶していない場合でも、例えば最後に正常受信したMPDUのシーケンス番号とビットマップ情報１４１があれば、先頭のシーケンス番号は逆算できる。

図１６は、以上の制御例に係り、ブロックACK要求を再送した際のシーケンス例を示している。HCがQSTA1にQoS CF-Pollを送信してTXOP期間1を与える。図１６において、QSTA1は、TXOP期間の範囲内で、複数のQoSデータフレームと１つのブロックACK要求を１つの物理フレーム１６０にアグリゲートしてQSTA2に送信するが、ブロックACK要求部分１６１に誤りが生じ、圧縮ブロックACKが受信できないことが示されている。その後、QSTA2のTXOP期間2が終了して、HCが再びQSTA1にTXOP期間3を付与した際、QSTA1はブロックACK要求１６２を再送し、QSTA2からの圧縮ブロックACK１６３を受信することで一連のフレームシーケンスを終了する。

次に、図１７乃至図１９を参照して再送制御例２を説明する。図１７のように、送信端末が、シーケンス番号「1」〜「7」のMPDUと、ブロックACK要求を１つのPSDUにアグリゲートして送信したとする。受信側で、シーケンス番号「2」、「5」、ブロックACK要求の誤り検査の結果、これらを正常に受信できなかったことが判明した場合、その時点で受信したPSDU内の複数MPDUの受信ステータスをビットマップ情報として保持(図１７の例で、ビットマップは1011011となる)し、併せて最後に受信したMPDUのシーケンス番号 (図１７の例で、シーケンス番号「7」)を記憶する点は前述と同様である。
図１７の例において、データ受信端末は圧縮ブロックACKを応答することはできない。そこで送信端末は、一定時間経過しても圧縮ブロックACKを受信できないならば、ブロックACK要求を再送する。前述のように、ブロックACK要求のBlock ACK Starting Sequence Controlの値は、アグリゲートした先頭のMPDUのシーケンス番号(図１７の例では「1」)を記載する。ここで、ブロックACK要求を送信しても、圧縮ブロックACKが返答されてこない場合、当該データの再送を諦めることになる。IEEE802.11e Draft 8.0によれば、QoSデータには、優先度に応じて遅延限界(Delay Bound)が定められ、ネゴシエーションを通じて、この値を送受信端末間で相互に認識し合う。Delay Boundを超過したMACフレームはQoS品質を満たせなかったとして、送信端末(あるいは受信端末)で廃棄される。図１７の例で、送信端末がアグリゲートして送信したシーケンス番号「1」〜「7」のMACフレームが全てDelay Boundを超過して廃棄されると、次の送信シーケンスとして、新しいフレームがアグリゲートされることになる。
図１８の例では、新しいデータフレームとして、シーケンス番号「8」〜「14」のMPDU１８０とブロックACK要求１８１とを１つのPSDUにアグリゲートして送信している。PSDUの末尾にアグリゲートされたブロックACK要求１８１のBlock ACK Starting Sequence Controlの値は、先頭MPDUのシーケンス番号「8」を記載する。この複数MPDU(シーケンス番号「8」〜「14」)１８０とブロックACK要求１８１をアグリゲートしたPSDUが、衝突などの理由で全て誤りとなった場合、受信端末側では、受信ステータスの更新を一切行なっていない状態のままである。送信端末は、圧縮ブロックACKが一定時間経過しても受信できないと、Block ACK Starting Sequence Controlが「8」のブロックACK要求１８１を再送する。受信端末は、再送されたブロックACK要求１８１を受け取ると、該フレーム１８１のBlock ACK Starting Sequence Controlの値は「8」であり、自身が正常に受信した最後のMPDUのシーケンス番号「7」よりも大きい値であることが分かる。図１８の例において、圧縮ブロックACK１回分のビットマップ情報は、シーケンス番号「1」〜「7」のMPDUに対するものであるため、Block ACK Starting Sequence Controlが示す先の受信ステータスは一切記録していない状況である。ここで、図１９に示すように、それまで記憶しておいたシーケンス番号「1」〜「7」のMPDUの受信ステータス(図１８の例では、1011011)を0でクリアし、Block ACK Bitmap１９０を全て0にした状態の圧縮ブロックACK１９０を送信する。つまり、Block ACK Bitmap１９０は、正常受信されたＭＡＣフレームが無いことを示す。

シーケンス番号「8」〜「14」の複数MPDUをアグリゲートして送信した端末は、図１９において、宛先端末からの圧縮ブロックACK１９１を受信し、かつそのBlock ACK Bitmap１９０が全て0の場合、シーケンス番号「8」〜「14」の全てのMPDU１９２を再送対象とする。図１９の例では、シーケンス番号「8」〜「14」の再送対象のMPDU１９２とブロックACK要求(Block ACK Starting Sequence Controlは「8」)１９３を１つのPSDUにアグリゲートして送信する様子を示している。受信端末では、PSDU内に複数個アグリゲートされたMPDU１９２のうち、ブロックACK要求１９３を除いて、どれか１つでも正常に受信できれば、受信ステータスのビットマップと最後に正常受信したMPDUのシーケンス番号を更新する。

以上説明した本発明の第一の実施形態によれば、ＭＳＤＵのフラグメント化を行わない前提において、ブロックACKに含まれるビットマップ情報を削減し、MAC効率を向上することが出来る。この実施形態では、ブロックACK要求を受信してからSIFS期間後にブロックACKを応答する即時型ブロックACKを実現する例を示した具体的には、複数MPDUがアグリゲートされ、かつ該複数MPDUの末尾にブロックACK要求がアグリゲートされたPSDUを受信した場合、受信ステータスを反射的に即時型ブロックACKとして応答することができる。しかし、フラグメントが無い前提でビットマップ情報を圧縮することは、遅延型ブロックACKの場合にも同様に適用可能である。

また、本実施形態では１つのPSDUに１つのブロックACK要求、1つのブロックACKが含まれる例を示したが、１つのPSDUに複数のブロックACK要求、複数のブロックACKを含むように拡張することも出来る。例えば同じ宛先だが、TIDの異なる複数のMPDUを１つのPSDUにアグリゲートする際に、そのPSDUに含まれるTIDそれぞれに対し、ブロックACK要求を対応付けても良い。一部のTIDが即時にACKを必要としない場合、あるいは全くACKを必要としない場合には、TIDの数はブロックACK要求の数よりも多くても良い。また、これに応答するブロックACKもブロックACK要求毎に生成され送信される。応答するブロックACKは１つのPSDUにアグリゲートするのが自然だが、個別のPSDUとして送信することも可能である。また、複数宛先のMPDUを１つのPSDUにアグリゲートする際に、そのPSDUに含まれる宛先それぞれに対し、ブロックACK要求を対応付けても良い。これに対する応答のブロックACKは、宛先に対応する各受信側装置から個別に送信される。各受信側装置が送信するブロックACKの応答は、互いにぶつからないようにスケジュールされるものとする。複数TIDと複数宛先を組み合わせることも可能である。

また、HCによってスケジュール制御されない、通常のCSMA/CAの場合にも同様に適用される。

（第二の実施形態）
本発明の第一の実施形態においては、複数のMPDUを１つのPSDUにアグリゲートした際、PSDUの末尾にブロックACK要求を必ずアグリゲートしていた。この場合、該PSDUを受信した端末が、アグリゲートされた複数MPDUの誤り検査を行い、その中にブロックACK要求の存在を確認すれば、圧縮ブロックACKを反射的に返信する方法である。これに対し本発明の第二の実施形態は、複数のMPDUをアグリゲートした際、PSDU内の末尾にブロックACK要求をアグリゲートしない状態で物理フレームを送信するというものである。
図２０及び図２１に本発明の第二の実施形態における、複数MPDUをアグリゲートしたPSDUのフレーム構成例を示す。図２０では、複数のMPDUの先頭に、MPDUの長さを示す情報（MPDU長）２０１、及び長さ情報に対するCRC２０２が付加される。MPDU長２０１とCRC２０２を併せて、第一の実施形態と同様に、「MPDUセパレーション」２０３と呼ぶ。図２０から分かるように、第二の実施形態では、複数のMPDUがアグリゲートされたPSDUの末尾にブロックACK要求は存在しない。各MPDUは、MPDUセパレーション２０３のCRC計算が正しく、かつMPDU長２０１で示されるMPDUのFCSの計算結果が正常であれば、受信成功したとみなす。図２１は、複数のMPDUの長さ情報をアグリゲートしたMPDU群の先頭にヘッダーとして付加するもので、このヘッダーを第一の実施形態と同様に「MACスーパーフレームヘッダー」２１０と呼ぶ。MACスーパーフレームヘッダー２１０には、ヘッダーのCRC２１１が付属する。MACスーパーフレームヘッダー２１０のCRC計算の結果が誤りであれば、全てのMPDUを誤りであるとみなす。尚、MPDU長情報は、MACヘッダーからFCSまでの長さをバイト単位で指定する。第二の実施形態では、図２０及び図２１のように、物理(PHY)ヘッダー（図２０の２００,図２１の２１２）及び物理(PHY)トレーラ（図２０の２０４,図２１の２１３）に挟まれたPSDU内に複数のMPDUがアグリゲートされている物理フレームを受信した端末は、その時点での受信ステータスを圧縮ブロックACKとして反射的に応答する。

図２２乃至図２４を参照して、本発明の第二の実施形態における基本的な送受信シーケンスを示す。図２２において、送信端末は、連続的に割り当てられたシーケンス番号「1」〜「8」のMPDUを１つのPSDUにアグリゲートして送信する。上述した第一の実施形態と同様に、送信端末は再送用のサブキューを有し、図２２のシーケンス番号「1」〜「8」のMPDUのコピーを該サブキュー内に格納する。図２２の例において、複数MPDUがアグリゲートされたPSDUを受信した受信端末は、各MPDUの受信ステータスを計算してBlock ACK Bitmap２２０に変換し、圧縮ブロックACKを反射的に送信する。第一の実施形態とは異なり、ブロックACK要求はアグリゲートされていないため、PSDU内のMPDUをどれか１つでも正常に受信できれば、そのPSDUが終了した時点で圧縮ブロックACKを応答する。図２２の例では、シーケンス番号「2」、「5」、「7」のMPDUがFCS計算の結果、誤りであった場合を示している。受信端末は、当該PSDU内で正常に受信できた先頭のMPDUのシーケンス番号を、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値とする。Block ACK Bitmap２２０は、最初に受信できたMPDUからの相対的な位置関係から作成される。図２２において、受信ステータスのビットマップ構成は、10110101のように示すことができる。また圧縮ブロックACKのBlock ACK Starting Sequence Controlは「1」である。上述した第一の実施形態と同様に、１つのPSDU内にアグリゲート可能なMPDUの最大個数に満たない場合は、ビットマップフィールドの後半を0でパディング等を行なう。もしくは、受信端末側で、PSDU内にアグリゲートされていたMPDUの個数に応じて、Block ACK Bitmap２２０のビットマップ長を可変にしても良い。図２３において、データ送信端末は、宛先からの圧縮ブロックACK２３０を受信した際、まず該フレーム２３０のBlock ACK Starting Sequence Controlを確認する。図２３の例では、送信端末が送信した先頭のMPDUのシーケンス番号「1」と等しいため、圧縮ブロックACK２３０のBlock ACK Bitmap２３１から、当該端末が送信したMPDUの送信状況を判断する。図２３のBlock ACK Bitmap２３１は、10110101に示される構成となっており、その結果、送信端末はシーケンス番号「2」、「5」、「7」のMPDUが正しく送信できなかったことを検出する。そこで、シーケンス番号「2」、「5」、「7」のMPDUは再送の対象とし、再送時に再びアグリゲートされ、本発明の第一の実施形態と同じように、受信側のバッファ容量が許す範囲内で、新しいフレーム２３２を一緒にアグリゲートして送信する。再送フレーム２３３を含めて、複数MPDUをアグリゲートしたPSDUを送信する際も、末尾にブロックACK要求をアグリゲートすることはしない。
図２４に示すように、HCからTXOP期間1を与えられたQSTA1は、QSTA2に対し、複数のQoSデータがアグリゲートされた物理フレーム２４０を送信し、該フレーム２４０を受信したQSTA2は、SIFS期間の後、圧縮ブロックACK２４１を応答する。HCからQSTA1に対するダウンリンク伝送も同様の手続きで行なわれる。すなわち、HCのTXOP期間2において、QSTA1に対し複数のQoSデータがアグリゲートされた物理フレーム２４２を送信し、QSTA1から圧縮ブロックACK２４３を受信することで一連の送信シーケンスを完了する。

本発明の第二の実施形態によれば、ブロックACK要求はPSDU内にアグリゲートしないことから、MAC効率を向上できる。また、受信側でのブロックACK要求フレームを受信する処理負担の軽減を実現することも可能である。

次に、図２５及び図２６を参照して、複数MPDUをアグリゲートしたPSDUの先頭から連続的にフレーム誤りが生じた場合の再送制御例を説明する。図２５のように、シーケンス番号「1」〜「8」のMPDUをアグリゲートして送信し、受信端末側でシーケンス番号「1」、「2」、「5」、「7」のMPDUがFCS計算の結果、誤りであったとする。第一の実施形態とは異なり、第二の実施形態ではブロックACK要求はPSDU内にアグリゲートされないため、PSDUの先頭がどのシーケンス番号であるかを判断することはできない。特に、図２０のように、複数MPDUの先頭にMPDUセパレーションフィールドを付加している場合、当該PSDU内に幾つのMPDUがアグリゲートされているかも分からないため、Block ACK Starting Sequence Controlを推測することもできない。そこで、本発明の第二の実施形態において、複数のMPDUをアグリゲートしたPSDUを受信した端末は、該PSDUの中で、正常に受信した最初のMPDUのシーケンス番号を、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値とし、該MPDUからの相対的な位置関係から、受信ステータスのビットマップを構成する。すなわち、図２５に示すように、データ受信端末側で正常に受信することのできた最初のMPDUは、シーケンス番号「3」のフレームであるため、圧縮ブロックACKのBlock ACK Starting Sequence Controlを「3」とする。さらに、PSDU内のシーケンス番号「3」のMPDUからの相対的な位置関係から、Block ACK Bitmap２５０を作成することになるが、図２５の例では、110101のようなビットマップを作成する。既に論じてきたように、１つのPSDU内にアグリゲート可能なMPDUの最大数に満たない場合、ビットマップの後半部分２５１は0でパディングする。もしくは、受信端末側で、PSDU内にアグリゲートされていたMPDUの個数に応じて、Block ACK Bitmap２５０のビットマップ長を可変にしても良い。複数のMPDUをアグリゲートして送信した後、圧縮ブロックACK２５２を受信すれば、当該端末の送信したMPDUのシーケンス番号とBlock ACK Starting Sequence Controlを比較する。
図２６の例のように、シーケンス番号「1」〜「8」のMPDUを送信しており、宛先端末からの圧縮ブロックACK２５２のBlock ACK Starting Sequence Controlの値が「3」である場合、Block ACK Starting Sequence Controlよりも前のシーケンス番号を持つMPDUは、全て誤りとみなす。すなわち、シーケンス番号「1」、「2」のMPDUは誤りだと判断する。またBlock ACK Starting Sequence Controlの値「3」を始点として、ビットマップの相対的な位置関係から、同じくシーケンス番号「5」、「7」のMPDUに誤りが生じていると判断する。送信端末は、このような圧縮ブロックACK２５２の受信によって、再送の必要が生じているMPDU２６０をアグリゲートし、もし受信側のバッファ容量に余裕があるならば、新たにフレームをアグリゲートして送信する。

図２７を参照し、送信端末がブロックACK要求を再送する場合を説明する。第一の実施形態でも述べたように、宛先からの圧縮ブロックACKが受信されない場合、送信端末はブロックACK要求を再送する。本発明の第二の実施形態において、QoSデータを１つの物理アグリゲートする場合は、末尾にブロックACK要求を含むことはないため、データ送信端末からブロックACK要求を送信するのは、圧縮ブロックACKが受信できなかった場合のみである。図２７の例では、シーケンス番号「1」、「2」、「5」、「7」のMPDUを再送分２６０としてアグリゲートして送信する。この時、ブロックACK要求２７０のBlock ACK Starting Sequence Controlは、前回送信したPSDUの先頭MPDUのシーケンス番号の値をコピーする。図２７において、ブロックACK要求２７０のBlock ACK Starting Sequence Controlは「1」である。ブロックACK要求２７０を受信した端末は、前回最後に受信したPSDU内の複数MPDUの受信ステータスを圧縮ブロックACKの１回分として記憶しており、該受信端末が最後に正常に受信したMPDUのシーケンス番号よりも、ブロックACK要求２７０のBlock ACK Starting Sequence Controlの値が小さいならば、記憶しておいたビットマップ情報をそのままBlock ACK Bitmapに変換し、反射的に圧縮ブロックACKを応答する。この時、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値は、ブロックACK要求からコピーするのではなく、前回受信したPSDUの中で、正常に受信できた先頭MPDUのシーケンス番号を記載する。なぜなら、ブロックACK要求の示すBlock ACK Starting Sequence Controlに対応するMPDUを必ずしも正常に受信しているわけではないためである。ないしは、ブロックACK要求からBlock ACK Starting Sequnce Controlをコピーし、記憶していたビットマップ情報の先頭のシーケンス番号より古い部分は正常に受信できなかったという内容にビットマップ情報を変換しても良い。

図２８に、本発明の第二の実施形態の再送処理を含めた基本的なフレーム交換シーケンスを示す。ここでデータ送信端末は、シーケンス番号「1」〜「8」のMPDUを１つのPSDU２８０にアグリゲートして送信する。受信側でPSDU２８０を受信した時、シーケンス番号「1」、「2」、「5」、「7」のMPDUが誤りであった場合、11010100のようなビットマップ構成で圧縮ブロックACK２８１を送信する。送信側では、圧縮ブロックACK２８１の内容から、シーケンス番号「1」、「2」、「5」、「7」のMPDUが正常に送信できなかったことを判断し、当該再送対象の複数のMPDUをアグリゲートしてPSDU２８２を再送する。この再送されたPSDU２８２が衝突などの理由により、受信側で全く受信できない場合、一定時間後に、送信端末はBlock ACK Starting Sequence Controlを「1」としてブロックACK要求２８３を再送する。ブロックACK要求２８３を受信した端末は、Block ACK Starting Sequence Controlの値が「1」であるが、該受信端末の前回受信したPSDU内の複数MPDUの中で、先頭のシーケンス番号は「3」であるため、圧縮ブロックACK２８４のBlock ACK Starting Sequence Controlの値を「3」として、記憶しておいた受信ステータスのビットマップをBlock ACK Bitmapとして応答する。送信端末が圧縮ブロックACK２８４を受け取ると、前回送信したMPDU２８２の中で、圧縮ブロックACK２８４のBlock ACK Starting Sequence Controlよりも前のシーケンス番号を持つMPDUを全て誤りだとみなし、かつビットマップの相対的な位置関係からも誤ったMPDUを検出する。すなわち、図２８の例では、再送されたMPDU２８２が全て誤っているため、結果として、シーケンス番号「1」、「2」、「5」、「7」の全てのMPDUを再送対象とし、これらがアグリゲートされたMPDU２８５を再送する。その後、宛先から圧縮ブロックACK２８６を受信することで、一連のフレーム交換シーケンスを終了したとみなす。

図２９は、再送を含めたデータ送信端末でのバッファ管理を示したものである。様々な宛先、優先度のMACフレームを含むメインキューからMACフレームを取り出し、「1」〜「8」の連続的なシーケンス番号を割り当てて、再送用のサブキュー２９０に格納する。そして、シーケンス番号「1」〜「8」のMPDUのコピーを取り出し、１つのPSDUにアグリゲートして送信した後、当該送信端末が送信したMPDUのシーケンス番号を記憶しておく。図２９の例では、「1」、「2」、「3」、「4」、「5」、「6」、「7」、「8」という情報が送信側で記憶される。宛先端末から、Block ACK Starting Sequence Control「3」の圧縮ブロックACK２９１を受信した場合、それよりも前のシーケンス番号「1」、「2」のMPDUは双方とも誤りとみなす。併せて、Block ACK Bitmapの相対的な位置関係から、シーケンス番号「5」、「7」のMPDUも誤りとみなす。再送用のサブキュー２９０からは、その先頭から連続的に送信成功していれば、MPDUを前方から削除していくことができる。図２９の例では、シーケンス番号「1」のMPDUが誤っていると判断されているため、サブキューからフレームを１つも削除することはできない。ここで、サブキュー２９０内の送信成功したMACフレームに対しては、送信成功したことを示す何かしらの識別情報を与えて、そのままサブキュー内に格納しておくことが望ましい。これは、次のシーケンスで、圧縮ブロックACKを受信した際、ビットマップの相対的な位置関係から、送信成功したMPDU、正常に送信できなかったMPDUを区別することが困難になること等が挙げられるからである。ここで送信に成功したMPDUの実体は必ずしも格納しておく必要は無い。シーケンス番号毎の状態が重要である。その後、送信端末がシーケンス番号「1」、「2」、「5」、「7」のMPDUを再送して、シーケンス番号「7」のMPDUを除いて、受信側で全て正常に受信できたとすると、Block ACK Starting Sequence Control「1」の圧縮ブロックACK２９２が応答される。送信端末はシーケンス番号「1」、「2」、「5」のMPDUを正常に送信したことを判断するため、サブキュー２９０の先頭から連続的に、シーケンス番号「6」のMPDUまで削除していく。結果、サブキュー２９０の先頭には、シーケンス番号「7」のMPDUが格納されていることになる。

以上説明した本発明の第二の実施形態によって、ブロックACK要求をPSDUから削除できるため、MAC効率が向上する。また、MSDUのフラグメント化を行わない前提において、ブロックACKに含まれるビットマップ情報を削減し、MAC効率を向上することが出来る。更に、ブロックACK要求を受信してからSIFS期間後にブロックACKを応答する即時型ブロックACKを実現できる。ブロックACK要求をPSDUから削除してMAC効率を向上する方法は、遅延型ブロックACKの場合にも適用できる。

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

本発明の第一の実施形態に係る通信装置の構成を示すブロック図 IEEE802.11e Draft 8.0で規定されているブロックACK要求のフレームフォーマットを示す図 IEEE802.11e Draft 8.0で規定されているブロックACKのフレームフォーマットを示す図 ブロックACKシーケンス（即時型）を示す図 ブロックACKシーケンス（遅延型）を示す図 従来のブロックACK作成手順を説明するための図 従来のブロックACK作成手順を説明するための図 圧縮ブロックACKのフォーマットを示す図 複数MPDUをアグリゲートするフォーマットの一例を示す図 複数MPDUをアグリゲートするフォーマットの別の例を示す図 第一の実施形態に係る圧縮ブロックACK即時応答を説明するための図 第一の実施形態に係る圧縮ブロックACK即時応答を説明するための図 第一の実施形態に係る圧縮ブロックACK即時応答を説明するための図 第一の実施形態に係る再送制御例１を説明するための図 第一の実施形態に係る再送制御例１を説明するための図 第一の実施形態に係る再送制御例１を説明するための図 第一の実施形態に係る再送制御例２を説明するための図 第一の実施形態に係る再送制御例２を説明するための図 第一の実施形態に係る再送制御例２を説明するための図 第二の実施形態に係る複数MPDUをアグリゲートするフォーマットの一例を示す図 第二の実施形態に係る複数MPDUをアグリゲートするフォーマットの別の例を示す図 第二の実施形態に係るブロックACK要求省略時の再送手順の一例を説明するための図 第二の実施形態に係るブロックACK要求省略時の再送手順の一例を説明するための図 第二の実施形態に係るブロックACK要求省略時の再送手順の一例を説明するための図 第二の実施形態に係るブロックACK要求省略時の再送手順の別の例を説明するための図 第二の実施形態に係るブロックACK要求省略時の再送手順の別の例を説明するための図 第二の実施形態に係るブロックACK要求省略時の再送手順の別の例を説明するための図 第二の実施形態に係るブロックACK要求省略時の再送手順の別の例を説明するための図 再送を含めたデータ送信端末でのバッファ管理を示す図

符号の説明

１００…通信装置；
１０１…物理層(PHY)；
１０２…ＭＡＣ（媒体アクセス制御）層；
１０３…リンク層；
１０４…アンテナ；
１０５…アグリゲーション処理部；
１０６…キャリアセンス制御部；
１０７…再送制御部；
１０９…第一種の物理層プロトコル処理部；
１１０…第二種の物理層プロトコル処理部

Claims (10)

1. それぞれシーケンス番号及びＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）を有する第１のデータフレームと第２のデータフレームとを有する物理フレームを受信する受信手段と、
   始点シーケンス番号と、前記第１のデータフレーム及び前記第２のデータフレームのうちの少なくとも一方の受信状態を示すビットマップとを含む第１送達確認フレームを作成する作成手段と、
   前記受信手段で前記物理フレームを受信してから最小フレーム間隔経過した後に、前記物理フレームの送信元である通信装置に対して、前記第１送達確認フレームを送信する送信手段とを備え、
   前記物理フレームは、
   （ａ）前記第１のデータフレームと、前記第１のデータフレームの長さについての第１情報と、前記第１情報の誤りを検出するための第１誤り検出コードと、バイトアラインメントを行うための第１領域と、を有する第１フィールドと、
   （ｂ）前記第２のデータフレームと、前記第２のデータフレームの長さについての第２情報と、前記第２情報の誤りを検出するための第２誤り検出コードと、バイトアラインメントを行うための第２領域と、を有する第２フィールドとを有し、
   前記作成手段は、前記第１誤り検出コードで前記第１情報に誤りが検出されず、かつ前記第１データフレームのＦＣＳで誤りが検出されない場合に、前記第１のデータフレームを正しく受信したこととし、
   前記第１誤り検出コードで前記第１情報に誤りが検出されたか、あるいは前記第１データフレームのＦＣＳで誤りが検出された場合に、前記第１のデータフレームの受信に失敗したこととし、
   前記第２誤り検出コードで前記第２情報に誤りが検出されず、かつ前記第２データフレームのＦＣＳで誤りが検出されない場合に、前記第２のデータフレームを正しく受信したこととし、
   前記第２誤り検出コードで前記第２情報に誤りが検出されたか、あるいは前記第２データフレームのＦＣＳで誤りが検出された場合に、前記第２のデータフレームの受信に失敗したこととし、
   前記受信手段は、前記第１のデータフレームに付加されたシーケンス番号及び前記第２のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第１のデータフレーム及び前記第２のデータフレームのうちの少なくとも一方を再度受信することを特徴とする通信装置。
2. それぞれシーケンス番号及びＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）を有する第１のデータフレームと第２のデータフレームとを有する物理フレームを受信する受信手段と、
   始点シーケンス番号と、前記第１のデータフレーム及び前記第２のデータフレームの少なくとも一方の受信状態を示すビットマップとを含む第１送達確認フレームを作成する作成手段と、
   前記受信手段で前記物理フレームを受信してからＳＩＦＳ期間経過した後に、前記物理フレームの送信元である通信装置に対して、前記第１送達確認フレームを送信する送信手段とを備え、
   前記物理フレームは、
   （ａ）前記第１のデータフレームと、前記第１のデータフレームの長さについての第１情報と、前記第１情報の誤りを検出するための第１誤り検出コードと、バイトアラインメントを行うための第１領域と、を有する第１フィールドと、
   （ｂ）前記第２のデータフレームと、前記第２のデータフレームの長さについての第２情報と、前記第２情報の誤りを検出するための第２誤り検出コードと、バイトアラインメントを行うための第２領域と、を有する第２フィールドとを有し、
   前記作成手段は、前記第１誤り検出コードで前記第１情報に誤りが検出されず、かつ前記第１データフレームのＦＣＳで誤りが検出されない場合に、前記第１のデータフレームを正しく受信したこととし、
   前記第１誤り検出コードで前記第１情報に誤りが検出されたか、あるいは前記第１データフレームのＦＣＳで誤りが検出された場合に、前記第１のデータフレームの受信に失敗したこととし、
   前記第２誤り検出コードで前記第２情報に誤りが検出されず、かつ前記第２データフレームのＦＣＳで誤りが検出されない場合に、前記第２のデータフレームを正しく受信したこととし、
   前記第２誤り検出コードで前記第２情報に誤りが検出されたか、あるいは前記第２データフレームのＦＣＳで誤りが検出された場合に、前記第２のデータフレームの受信に失敗したこととし、
   前記受信手段は、前記第１のデータフレームに付加されたシーケンス番号及び前記第２のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第１のデータフレーム及び前記第２のデータフレームの少なくとも１つを再度受信することを特徴とする通信装置。
3. 前記第１のデータフレーム及び前記第２のデータフレームは、それぞれ、当該データフレームの送信元の通信装置を示す送信元アドレスと、当該データフレームの宛先の通信装置を示す宛先アドレスと、優先度識別子（ＴＩＤ：Ｔｒａｆｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ：）とをさらに含み、
   前記作成手段は、正しく受信したデータフレームに含まれる、シーケンス番号と、送信元アドレスと、宛先アドレスと、優先度識別子とを用いて、前記第１送達確認フレームを作成することを特徴とする請求項１又は請求項２に記載の通信装置。
4. 前記作成手段は、前記第１送達確認フレームの前記始点シーケンス番号を、前記第１のデータフレーム及び前記第２のデータフレームのシーケンス番号のいずれかとすることを特徴とする請求項１乃至請求項３のいずれか１項に記載の通信装置。
5. 前記第１送達確認フレームに含まれるビットマップを記憶する記憶手段をさらに備え、
   前記受信手段が送達確認要求フレームを受信した場合に、前記作成手段は、前記記憶手段に記憶されたビットマップによって第２送達確認フレームを作成し、
   前記送信手段は、前記第２送達確認フレームを送信することを特徴とする請求項４に記載の通信装置。
6. 前記送達確認要求フレームの始点シーケンス番号が、前記送達確認要求フレームを受信する前に受信したデータフレームのシーケンス番号よりも大きい場合、前記作成手段は、受信に成功したデータフレームが無いことを示す第３送達確認フレームを作成し、
   前記送信手段は、前記第３送達確認フレームを送信することを特徴とする請求項５に記載の通信装置。
7. 前記送達確認要求フレームの始点シーケンス番号が、前記記憶手段に記憶された前記ビットマップの最後のビットに対応するシーケンス番号以下であれば、前記作成手段は、前記ビットマップの少なくとも一部を含む第４送達確認フレームを作成し、
   前記送信手段は、前記第４送達確認フレームを送信することを特徴とする請求項５に記載の通信装置。
8. アンテナをさらに備え、
   前記受信手段は、前記アンテナを介して、前記物理フレームを受信し、
   前記送信手段は、前記アンテナを介して、前記第１送達確認フレームを送信することを特徴とする請求項１乃至請求項７のいずれか１項に記載の通信装置。
9. それぞれシーケンス番号及びＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）を有する第１のデータフレームと第２のデータフレームとを有する物理フレームを受信し、
   始点シーケンス番号と、前記第１のデータフレーム及び前記第２のデータフレームのうちの少なくとも一方の受信状態を示すビットマップとを含む第１送達確認フレームを作成し、
   前記物理フレームを受信してから最小フレーム間隔経過した後に、前記物理フレームの送信元である通信装置に対して、前記第１送達確認フレームを送信し、
   前記物理フレームは、
   （ａ）前記第１のデータフレームと、前記第１のデータフレームの長さについての第１情報と、前記第１情報の誤りを検出するための第１誤り検出コードと、バイトアラインメントを行うための第１領域と、を有する第１フィールドと、
   （ｂ）前記第２のデータフレームと、前記第２のデータフレームの長さについての第２情報と、前記第２情報の誤りを検出するための第２誤り検出コードと、バイトアラインメントを行うための第２領域と、を有する第２フィールドとを有し、
   前記第１送達確認フレームの作成においては、
   前記第１誤り検出コードで前記第１情報に誤りが検出されず、かつ前記第１データフレームのＦＣＳで誤りが検出されない場合に、前記第１のデータフレームを正しく受信したこととし、
   前記第１誤り検出コードで前記第１情報に誤りが検出されたか、あるいは前記第１データフレームのＦＣＳで誤りが検出された場合に、前記第１のデータフレームの受信に失敗したこととし、
   前記第２誤り検出コードで前記第２情報に誤りが検出されず、かつ前記第２データフレームのＦＣＳで誤りが検出されない場合に、前記第２のデータフレームを正しく受信したこととし、
   前記第２誤り検出コードで前記第２情報に誤りが検出されたか、あるいは前記第２データフレームのＦＣＳで誤りが検出された場合に、前記第２のデータフレームの受信に失敗したこととし、
   前記第１のデータフレームに付加されたシーケンス番号及び前記第２のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第１のデータフレーム及び前記第２のデータフレームのうちの少なくとも一方を再度受信することを特徴とする通信方法。
10. それぞれシーケンス番号及びＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）を有する第１のデータフレームと第２のデータフレームとを有する物理フレームを受信し、
    始点シーケンス番号と、前記第１のデータフレーム及び前記第２のデータフレームのうちの少なくとも一方の受信状態を示すビットマップとを含む第１送達確認フレームを作成し、
    前記物理フレームを受信してからＳＩＦＳ期間経過した後に、前記物理フレームの送信元である通信装置に対して、前記第１送達確認フレームを送信し、
    前記物理フレームは、
    （ａ）前記第１のデータフレームと、前記第１のデータフレームの長さについての第１情報と、前記第１情報の誤りを検出するための第１誤り検出コードと、バイトアラインメントを行うための第１領域と、を有する第１フィールドと、
    （ｂ）前記第２のデータフレームと、前記第２のデータフレームの長さについての第２情報と、前記第２情報の誤りを検出するための第２誤り検出コードと、バイトアラインメントを行うための第２領域と、を有する第２フィールドとを有し、
    前記第１送達確認フレームの作成においては、
    前記第１誤り検出コードで前記第１情報に誤りが検出されず、かつ前記第１データフレームのＦＣＳで誤りが検出されない場合に、前記第１のデータフレームを正しく受信したこととし、
    前記第１誤り検出コードで前記第１情報に誤りが検出されたか、あるいは前記第１データフレームのＦＣＳで誤りが検出された場合に、前記第１のデータフレームの受信に失敗したこととし、
    前記第２誤り検出コードで前記第２情報に誤りが検出されず、かつ前記第２データフレームのＦＣＳで誤りが検出されない場合に、前記第２のデータフレームを正しく受信したこととし、
    前記第２誤り検出コードで前記第２情報に誤りが検出されたか、あるいは前記第２データフレームのＦＣＳで誤りが検出された場合に、前記第２のデータフレームの受信に失敗したこととし、
    前記第１のデータフレームに付加されたシーケンス番号及び前記第２のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第１のデータフレーム及び前記第２のデータフレームのうちの少なくとも一方を再度受信することを特徴とする通信方法。

Images