以下、図面を参照しながら本発明の実施の形態の例を説明する。
図1は本発明の一実施形態に係る通信装置の構成を示すブロック図である。この通信装置100は無線リンクを介して他の通信装置と通信する装置であり、物理層、MAC層、およびリンク層のそれぞれに相当する処理ユニット101、102、103を有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはLSIに組み込まれたCPUにより実行されるファームウェア等として実現される。物理層の処理ユニット101にはアンテナ104が接続されている。MAC層102は本発明に係わるアグリゲーション(集約)処理部105を有する。
アグリゲーション処理部105は、複数の媒体アクセス制御(MAC)フレームを含むPHY(物理)フレームを作成する。媒体アクセス制御フレームとしては、例えばMPDU(MAC Protocol Data Unit)であり、自明な変形を行ってMACヘッダーを含まないMSDU(MAC Size Data Unit)とすることもできる。作成された物理フレームは物理層の処理ユニット101により処理され、アンテナ104より送信される。このような通信方式のことを本明細書では「フレームアグリゲーション」という。フレームアグリゲーションは現在策定中の次世代超高速無線LAN通信(IEEE802.11n規格)に好適である。
MACスーパーフレーム(MACアグリゲーションフレーム)の基本的なフレームフォーマットは、少なくとも一つのMACスーパーフレームヘッダーと、該MACスーパーフレームヘッダーに続く少なくとも一つのMACスーパーフレームペイロードとを有する、というものである。
MACスーパーフレームを受信した端末は、まず自分宛のアドレスであるかどうか判断し、各MPDUのCRC(cyclic redundancy check;巡回冗長検査)計算を行う。その後、MACスーパーフレームヘッダー内のACKポリシービットマップフィールドをチェックし、パーシャルACKを必要とする「1」のフラグが立っていれば、パーシャルACKフレームの該当するビットマップに「1」または「0」の値を設定する(CRCを計算して正しく受信できていれば「1」、誤っていれば「0」とする)。また、ACKポリシービットマップが「0」であるMPDUは、「No_ACK」による転送を希望しているので、CRCの計算結果に関わらず、「0」の値を設定する。
MACスーパーフレームを送信した端末が、宛先端末からのパーシャルACKを受信した場合、自分のキャッシュしているACKポリシービットマップ情報とパーシャルACKビットマップ(Partial ACK Bitmap)とを照らし合わせる。ACKを必要としているにもかかわらず、パーシャルACKビットマップのビット情報が「0」になっていれば、該当するデータフレームを再送する。
フレームアグリゲーションにおけるパーシャルACK(Partial_ACK)について説明する。MACスーパーフレームを送信する端末のMAC層は、上位層から下りてくるデータフレームに対し、ACKポリシーをそれぞれ決定していく。この場合、ACKポリシーをパーシャルACKに指定することは、「そのデータフレームをフレームアグリゲーションの対象にし、かつ受信側からのACK応答を必要としている」ことを意味する。
いかなるACKメカニズムを用いてフレームを転送するかについては、「Normal_Ack(ノーマルACK)」,「No_ACK(無応答)」,「Block_ACK(ブロックACK)」の3種類がIEEE802.11eで既に規定されている。
「Normal_Ack」は、IEEE802.11でサポートされている通常のデータ送信方法であり、1つのユニキャストデータフレームを送信した後、宛先端末からのACKフレームを受信するまで一定時間待機する。タイムアウトが起これば、再度バックオフを行ってデータフレームを再送する。「Normal_Ack」に指定されたデータフレームは、フレームアグリゲーションの対象にせず、既存のIEEE802.11規格の手順で送信を行う。
「No_ACK」は、伝送路が比較的安定している場合に用いられるデータ送信方法であり、相手端末からのACKフレームの受信を待たずに(つまりACKを必要としない)、新たなデータフレームを送信する。
「Block_ACK」は、ユニキャストデータフレームをSIFS(Short Inter Frame Space)間隔でバースト的に連続送信するデータ送信方法であり、ブロックACKフレームにより選択的再送(Selective Repeat転送)を実現するものである。
なお、MACスーパーフレームの種々の構成例、応答制御(送達確認)、再送制御、QoS、ならびにサイマルキャスト等については、本出願と同一出願人による先の出願に係る特願2004−004847明細書、特願2004−063237明細書、特願2004−110446明細書の記載を参考にすることができる。
(第1の実施形態)
第1の実施形態は、1つの物理フレームに複数のMACフレーム(MPDU)をアグリゲートする際に、可変長のビットマップ情報と該ビットマップのデータ長とをMACスーパーフレームヘッダー中に含めるように構成された通信装置に関する。具体的には、物理フレームは、複数のMACフレームのそれぞれに対応するビットからなる可変長のビットマップ情報と、該ビットマップ情報の長さ情報とを有する。
図2に示すように、ACK Policy Bitmap20をMACスーパーフレームヘッダー21中に含めてMACスーパーフレームを送信する際に、送受信端末間で、事前にネゴシエーションをしておき、ACK Policy Bitmap20の長さを受信側で把握していることが必要である。このネゴシエーション方法としては、ビーコンやIEEE802.11eのHCCAにおけるトラフィックストリームのセットアップなど様々な方法が考えられる。なお、本発明はACK Policy Bitmap長のネゴシエーションによる通知を特定の方法に限定するものではない。MACスーパーフレームの受信側は、このようなサイズ情報をあらかじめ知っていない限り、ACK Policy Bitmap20を正しく取り出すことはできない。
一方、第1の実施形態は可変長のビットマップ情報を記載することを可能にするものであり、図3に示すような、Bitmap Informationフィールドを定義する。すなわち、Bitmap IDフィールド31によって、Bitmapの種別(ACK Policy Bitmapなど)を規定し、Lengthフィールドにおいて、実際のビットマップ情報(Bitmap Informationフィールド33)の長さを例えばバイト単位(Bytes)で指定する。これにより、ACK Policy Bitmapは、事前にネゴシエーションを行なわなくても、MACスーパーフレーム単位に可変長(バイト単位)の大きさで埋め込むことができる。
図3に示すビットマップエレメントは、例えばACKポリシービットマップ("ACK Policy Bitmap")、マルチアドレスビットマップ("Multi Address Bitmap")等があり、Bitmap ID31はこれらを識別可能にする。なお、ビットマップエレメント(ビットマップID)はこれらに限定されないことは言うまでもない。
図4の例のように、MACスーパーフレーム40中に12個のMPDUをアグリゲートする場合、ACK Policy Bitmapとしては2バイトの大きさのビットマップが必要であり、このためBitmap Information33のLengthフィールド32には「2」が指定される。Bitmap IDフィールド31には、ACK Policy Bitmapに相当するIDが指定される。
(第2の実施形態)
第2の実施形態に係る通信装置はMACスーパーフレーム受信端末であって、受信バッファからの取り出しと上位層への明け渡しを優先度毎に、タイマーにより時間管理する通信装置と、MACスーパーフレーム送信端末であって、優先度毎のバッファからの取り出しと上位層への明け渡しのタイマー設定を受信側に対して指定する通信装置である。
IEEE802.11eのHCCA方式を元にして1つの物理フレームに複数のMACフレームをアグリゲートして送信する場合、それぞれのトラフィックストリーム(TS)毎に、シーケンス番号が付与される。シーケンス番号は連続している必要があり、図5に示すように受信側でフレームのバッファリングが行なわれる。
図5の例では、MACスーパーフレームに「高優先度」「中優先度」「低優先度」の3つの優先度のMACフレーム50,51,52が存在し、それぞれの先頭のフレーム53,54,55が受信誤りであった場合を示している。トラフィックストリーム毎に、シーケンス番号が連続して受信できている場合、MAC層より上位の層(例えばネットワーク層)にフレームを渡すことができるが、図5のような場面では、それぞれシーケンス番号「1」のフレームを受信するまで、後続のフレーム(シーケンス番号「2」以降)がバッファで待機することになる(受信バッファ状態56,57,58)。
IEEE802.11では、一定時間経過しても、受信側のバッファ内で待機しているフレームよりもシーケンス番号の若いフレームが受信できない場合、タイムアウトが生じ、全ての蓄積フレームが上位層(例えばIP)に渡される。優先度毎のスライディングウィンドウ制御を行なっている場合、送受信側では優先度に応じて、シーケンス番号の管理が行なわれる。したがって、遅延時間に敏感なトラフィックストリームも、遅延時間に対して比較的大きな許容を持つトラフィックストリームも同様に扱われてしまうという問題がある。
そこで、第2の実施形態では、図6のように、MACスーパーフレーム受信側でトラフィックストリーム毎のバッファ60,61,62のそれぞれにタイマー1,2,3を設け、独立して動作するこれらタイマーの動作に従ってトラフィックストリーム毎にバッファ管理をする。タイマー1,2,3がタイムアウトすると、対応するバッファ60,61,62に格納されているフレームがバッファから開放され、上位層に渡される。
タイマー1,2,3の各々にセットする値(タイムアウト時間)は、トラフィックストリームをセットアップする際の、図7(a)に示すTSPEC(Traffic Specification)70のDelay Boundフィールド71を元に決定してもよい。Delay Boundフィールド71はQoSデータの遅延時間の許容を示すもので、Delay Boundを過ぎたフレームは、再送上限回数に達する前でも送信側で廃棄される。このようなDelay Boundをトラフィックストリームの優先度毎に設定し、タイマー1,2,3にセットする値に対応させる。
あるいは、図7(b)に示すTSPECのTS Infoフィールド72が有するReservedフィールド73を活用し、MACスーパーフレーム受信側での各トラフィックストリームのタイムアウト時間をミリ秒単位で指定してもよい。あるいは、TSPECに新規のフィールドを拡張し、タイムアウトの指定を行う情報を追加してもよい。
(第3の実施形態)
第3の実施形態に係る通信装置は、複数の優先度のMACフレームを1つの物理フレームにアグリゲートして送信した後、受信側からの部分応答情報を元に、優先度毎にウインドウサイズ(一度に送信可能な最大数)の変更を行い、MACスーパーフレームを再送する通信装置である。
図8に示すように、1つの物理フレームに複数の優先度のMACフレーム(MPDU)を詰め込み、MACスーパーフレーム80として送信したとする。図8の例では、ウィンドウ81,82,83のそれぞれのウインドウサイズ(一度に送信可能なフレーム数)が優先度毎に定義されており、高優先度(例えばVoIP)を「3」、中優先度(例えばVideo)を「3」、低優先度(例えばftp)を「2」としている。また、MACスーパーフレーム80にアグリゲート可能なMACフレームの最大数は、送受信端末間で予めネゴシエーションを取ったことを前提とし、例えば8個であったとする(このネゴシエーションは、ビーコンを利用しても良いし、トラフィックストリームセットアップ時に行なっても良い。ネゴシエーションの方法に関しては、特に規定しない)。もちろん、この数は状況に応じて可変である。そして、図9に示すように、パーシャル(Partial)ACK(部分応答)90に基づくMACスーパーフレームの再送が行われる場合を考える。すなわち、パーシャルACK90内のパーシャルACKビットマップ91によると、高優先度の先頭のフレームは正常に受信されなかったためにシーケンス番号「1」のフレームのみが再送対象とされる。一方、中優先度、低優先度のフレームは、正常に受信できており再送が要求されていないことから、それぞれのウインドウ82,83の始点を移動してウィンドウサイズに相当する数の新たなフレームをアグリゲートでき、再送のためのMACスーパーフレーム92が作成される。ここで、アグリゲート可能なMACフレームの最大数は上述のように8個であるものの、図9のように作成されたMACスーパーフレーム92が含むMACフレームは6個であり、チャネル利用率が最大限まで活かされていない。これは、優先度毎のウインドウサイズを常に固定としていることによる。
そこで本実施形態では、MACスーパーフレーム受信端末からの部分応答を元に、優先度毎のシーケンス番号の始点を移動させると共に、ウィンドウサイズの大きさを適応的に変更する。これにより、MACスーパーフレームの伝送効率を高めることができる。
例えば図10に示すように、高優先度のフレームは1つしか詰めることができないが、MACスーパーフレーム全体においてアグリゲート可能な数には余裕がある。そこで、アグリゲート可能な最大数を上限とし、中優先度のフレームをアグリゲートする数をできるだけ増加させる。図8の段階では、中優先度の送信可能な初期値は3個であったが、高優先度のフレームを1つしか送れないことから、中優先度のウィンドウ100のウインドウサイズを3個から5個に拡大する。
したがって、本実施形態に従い作成されるMACスーパーフレーム101には、アグリゲート可能な最大数に相当する8個のフレームがアグリゲートされ、図9に示したように6個のフレームがアグリゲートされるMACスーパーフレーム92よりも伝送効率を高めることができる。
再送処理が行なわれた結果、高優先度のフレームが多く送信できるようになれば、再び各優先度のウィンドウサイズを初期値(この例では、高優先度を「3」、中優先度を「3」、低優先度を「2」)に戻し、MACスーパーフレームにQoSデータをアグリゲートする。
(第4の実施形態)
第4の実施形態はブロックACKに関する。図11に標準的なブロックACKのシーケンス(即時型)を示す。一方、IEEE802.11eでは、図12に示すように、MACヘッダー120にQoS Controlフィールド121が追加されており、ACK Policy122を指定することで、No ACK(ACKを必要としない伝送)、Block ACK、Normal ACK(通常のACK)などの様々な応答パターンを実現することができる。ここで、Block ACKに指定されたQoSデータに関しては、図11に示すように、SIFS(Short Inter Frame Space)間隔で送信された後、ブロックACK要求110が送信される。送信端末は、ブロックACK要求に応じた宛先端末からのブロックACK111を受信する。ブロックACK要求110とブロックACK111は、それぞれ、TID(Traffic Identifier)優先度毎に用意する必要がある。
[ブロックACKのアグリゲーション例1]
ブロックACKのアグリゲーション例1は、SIFS間隔で送信するブロックACK対象のQoSデータフレームを1つの物理フレームにアグリゲートして送信するというものである。
例えば図13に示すように、MACスーパーフレームヘッダー130に続き、ACK PolicyがBlock ACKであって同一宛先、同一TIDを有するQoSデータに限定されたMACフレーム131がアグリゲートされる。
図14に示すように、まずTID1についてのQoSデータがアグリゲートされたMACスーパーフレーム140が送信される。続いてSIFS後にTID2についてのQoSデータがアグリゲートされたMACスーパーフレーム141が送信される。そのSIFS後にTID1についてのブロックACK要求142が送信され、さらにSIFS後にTID1についてのブロックACK143の受信が行われる。TID1についてのブロックACK143のSIFS後に、TID2についてのブロックACK要求144が送信され、さらにSIFS後にTID2についてのブロックACK145の受信が行われる。尚、ブロックACK要求を送信するタイミングは、対応するTIDのQoSデータを送った後であれば、特に限定する必要はない。すなわち、図14において、MACスーパーフレーム140を送信した後、SIFS後に、ブロックACK要求142を送信することもできる。
このようなブロックACKのアグリゲーション例1によれば、ブロックACK対象の複数のQoSデータフレームを1つのMACスーパーフレームにアグリゲートして送信することにより伝送効率を向上できる。
[ブロックACKのアグリゲーション例2]
ブロックACKのアグリゲーション例2は、図15に示すように、SIFS間隔でバースト的に送信するブロックACK対象のQoSデータフレーム150を1つの物理フレームにアグリゲートすることのみならず、ブロックACK要求フレーム151をも1つの物理フレーム(MACスーパーフレーム)にアグリゲートするというものである。
MACスーパーフレームのアグリゲート最大数を例えば8個とする場合(最大アグリゲート数を予めネゴシエーションを通じて認識したことを前提)、ブロックACK対象の7個のQoSデータをアグリゲートし、それに対するブロックACK要求フレームが末尾に添付される。MACスーパーフレームヘッダーのMPDU Lengthフィールド152に基づいて、ブロックACK要求フレーム151は受信側で適切に処理される。ここで、ブロックACK要求は、QoSデータよりも前方部にアグリゲートすることはできない。なぜなら、ブロックACK要求フレーム151に示されるように、Block ACK Starting Sequence Controlフィールドによって、QoSデータの受信ステータス対象の開始シーケンス番号を決定するため、QoSデータの処理(誤り計算)を前もって行う必要があるからである。
本例のブロックACKシーケンスを図16に示す。ブロックACK対象の複数のQoSデータフレームに加え、ブロックACK要求がさらにアグリゲートされたMACスーパーフレーム160、161とすることにより、伝送効率を向上できる。
[ブロックACKのアグリゲーション例3]
ブロックACKのアグリゲーション例3は、複数のTID毎に存在するQoSデータフレームおよび対応するブロックACK要求をまとめて1つの物理フレームにアグリゲートして送信するというものである。
図17に示すように、異なるTIDについてのブロックACK対象QoSデータ170,171と、これらに対応するブロックACK要求172,173とを1つの物理フレームアグリゲートしてMACスーパーフレームを作成する。図18に示すように、作成されたMACスーパーフレーム180を伝送することにより、伝送効率を一層改善することができる。
[ブロックACKのアグリゲーション例4]
ブロックACKのアグリゲーション例4に係る通信装置は、ACKを必要としないNo ACKポリシーのMACフレームと、バースト的に送信されたMACフレームに対応する一つの応答(ブロックACK)を必要とするブロックACKポリシーのMACフレームとが混在するMACフレームアグリゲーションを行うものである。
図19に示すように、本例のMACスーパーフレームはMACスーパーフレームヘッダーにおいてビットマップID(Bitmap ID)フィールド190、Length(ビットマップ長)フィールド191、可変長のビットマップ(Bitmap Information)192を有する。Bitmap ID190には、ビットマップ種別(Bitmap element)がNo ACKポリシーとブロックACKポリシーとの複合ポリシーであることを識別するための識別子(ID)が記載される。Lengthフィールド191には、Bitmap Information192の長さが例えばバイト単位で記載される。
Bitmap Information192には、MACスーパーフレームにアグリゲートされた複数のMACフレームにおいて、どのMACフレームがNo ACKであり、どのMACフレームがブロックACKであるかを識別するための情報が記載される。図19に示すフレームアグリゲーション例では、例えば全部で8個のMACフレームがアグリゲートされており、そのうちブロックACKを必要とするフレームは3つ(QoS Data1〜3)であり、ACKを必要としない(No ACK)のフレームが5つ(図19では QoS Data 1,2のみが示される)である。
この場合、ブロックACKを必要とするためのビットを例えば1とすると、ビットマップ情報(Bitmap Information)192は「11100000」となり、送信側でセットされる(なお、ビットを負論理としてもよいことは言うまでもない)。受信端末は、このようなビットマップ情報192に基づいてブロックACKを作成し、送信端末に返信する。
例えば図20に示すように、MACスーパーフレーム2002が送信端末から送信され、該MACスーパーフレーム2002に続いてブロックACK要求2003が送信端末から送信されたとする。受信側端末は、MACスーパーフレーム2002においてブロックACKを必要とするMACフレームはMACスーパーフレーム2002の前半の3つであり、残りの5つのMACフレームはACKが必要でないことを同MACスーパーフレーム2002に含まれるビットマップ情報2001から判断する。受信側端末は、送信端末からのブロックACK要求2003に応じ、この情報をブロックACK2004を返す。
ブロックACKのアグリゲーション例4によれば、ACKポリシーが異なるMACフレームのアグリゲーションにより伝送効率を向上できる。なお、ビットマップ情報は、本例のように必ずしも可変長である必要はなく、固定長としてもよい。この場合、Length情報は不要となる。
尚、ブロックACKのアグリゲーション例4は、QoSデータとブロックACK要求とのフレームアグリゲーション、あるいは複数TID毎のQoSデータとブロックACK要求とのフレームアグリゲーションと組み合わせて実施可能であり、これらの場合においてNo ACKとBlock ACKの双方のACK Policyをサポートした伝送を実現することができる。
(第5の実施形態)
第5の実施形態に係る通信装置は、トラフィックストリームのMSDUサイズを固定にして1つの物理フレームに複数のMPDUをアグリゲートする際に、MPDUの個数を示す情報をMACスーパーフレームヘッダーに含めるよう構成される。
IEEE802.11eでは、HCCAを用いた通信を行う際、QoS STA(QSTA)は、QoS AP(HC: Hybrid Coordinator)にトラフィックストリームをセットアップする。図21はトラフィックストリームのセットアップ時に用いられるTSPEC(Traffic Specification)210を示している。TSPECはNominal MSDU Size(名目のMSDUサイズ)フィールド211を有する。同フィールド211は2バイト長であり、15ビットのSize(サイズ)サブフィールド(MSDUの長さを指定)212と、1ビットのFixed(固定指定)サブフィールド213とが存在する。Fixedサブフィールド213が「1」に指定されていれば、そのTSIDで示されるデータフレームのMSDU(MAC Size Data Unit)はSizeサブフィールド212に記載された固定長となり、それ以外の大きさのフレームは送信することができない。
MACスーパーフレームにアグリゲートされたMPDU(MAC Protocol Data Unit)のサイズを可変長とする場合、それぞれの区切りを識別するためのMPDU Lengthフィールドが必須であるが、トラフィックストリームセットアップ時に、MSDUの長さが固定長であることを事前に通知すればMPDU Lengthフィールドを省略し、これに代えてアグリゲートされたMPDUの個数とすることができる。したがって、MPDU Lengthフィールドが格納されるMACスーパーフレームヘッダーのサイズを削減できる。
図22は第5の実施形態に係り、MPDU長を固定長とするMACスーパーフレームを示している。MACスーパーフレームヘッダー220内の、アグリゲートされたMPDUの個数を表すフィールド(図22ではAggregation Numberフィールド)221に基づき、MPDU1,2,3...をそれぞれ取り出すことができる。尚、図22の例では、MACスーパーフレームにアグリゲートするのは、TSID222の値が同一であるものとしている。
MPDUは、MSDUにMACヘッダー(IEEE802.11eの場合はQoS Controlフィールドを含む)を追加したものであるが、MACスーパーフレームの受信端末は、まずMACスーパーフレームヘッダーの誤り計算(Header CRC223を利用)を行い、正しく受信できていれば、TSIDフィールド222から、その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をアグリゲートによるものとし、1つの物理フレームとして送信することが可能である。
本実施形態に係る他の通信装置は、複数のトラフィックストリームのそれぞれ固定長に指定されたMACフレームを1つの物理フレームにアグリゲートし、それらのトラフィックストリーム識別子を示す情報とトラフィックストリーム毎のアグリゲートしたMPDUの個数を示す情報とをヘッダーに含めて送信する通信装置である。
図23はこのような複数TSIDの混在時の固定長MACフレームのアグリゲーションを示す図である。本例では、MACスーパーフレームヘッダー230中に、アグリゲートされたTSIDの数を示すフィールド(Number of TSID)231が追加される。また、MACスーパーフレームヘッダー230は、TSIDと該TSIDについてアグリゲートされたMPDUの個数を示すフィールドとからなる組(ペア)をTSIDの数に応じて有する可変長フィールド232を有する。
このようなMACスーパーフレームを受信した端末側では、アグリゲートされたTSIDと各MPDUの個数とをMACスーパーフレームヘッダー230に基づいて検知する。固定長を有するMPDU長については、トラフィックストリーム毎に、上述と同様に固定MSDU長とMACヘッダー(QoS Controlフィールド含む)との合計値として算出する。また、上述したFTPのようなTCPアプリケーションの場合のように、上位層からのデータフレームの長さが短くなる場合には、MSDUの後半部に「0」をパディングして長さを固定長にすればよい。このようにしても、IPヘッダーのIPデータグラム長を示すフィールドの値は書き換えないため、上位層のデータペイロードに影響を与えることはない。尚、MACスーパーフレームの形式は、MACスーパーフレームヘッダーのMPDU Lengthフィールドを用いて、それぞれ長さの異なるMPDUをアグリゲートしても良いし、本実施形態のように、固定長のMPDUをアグリゲートして、その個数を示す情報をMACスーパーフレームヘッダーに付加しても良い。MACスーパーフレームヘッダーがどちらの形式を取るかは、送受信機の間で予めネゴシエーションを行なっておくことを前提とする(具体的なネゴシエーション方法については、本実施例の対象外としている)。
以下、第6乃至第11の実施形態は、複数の宛先を対象とする複数のMACフレームのアグリゲーションに係わり、サイマルキャスト送信を行うものである。
無線LANのMAC層において、一般的には1つのMACフレームを1つの宛先端末に向けて送信することを「ユニキャスト」といい、また、複数の宛先を受信対象とする1つのMACフレームを送信することを「マルチキャスト」という。これに対し本発明の実施形態の説明においては、複数のMACフレームを1つの物理フレームにアグリゲートし、複数の宛先を受信対象として送信することを「サイマルキャスト」と呼ぶことにする。
ここで、単純に複数の宛先のMACフレームを1つの物理フレームにアグリゲートし、APから各STAに向けて、サイマルキャストすることを考える。この場合、サイマルキャストされたMACスーパーフレームに対する各受信端末からのパーシャルACKフレームが衝突し、通信が正常に行えなくなってしまうという問題がある。IEEE802.11の規定によると、ユニキャストデータフレームを受信したSTAは、チャネル状態を確認することなく、SIFS期間が経過したら直ちにACKフレームを返信する。したがって、複数のSTAからのACKフレームが衝突する可能性は高い。
そこで、本発明の実施形態に係る通信システムでは、複数の宛先を含んだMACスーパーフレームをAPからSTAに対してサイマルキャストし、各STAがAPに対しACKフレームを送信するにあたり、他のSTAからのACKフレームとの衝突を回避するよう、それぞれ送信タイミングをずらすことが好ましい(これを時間差ACKという)。
他の端末が時間差的にパーシャルACKを返信している間は、各端末により適切にNAVを設定して、データフレーム等の送信を停止する。尚、このNAVの期間は、(残りの端末数×(SIFS+ACK転送時間))で決定される。また、本発明の実施形態においては、各STAからのACKの転送レートが同一であることを仮定しているが、もしACK転送レートがSTA毎に異なる場合は、それぞれに対応したACK転送時間を計算することが好ましい。
(第6の実施形態)
第6の実施形態に係る通信装置は、複数の宛先に対するMACフレームを1つの物理フレームにアグリゲートして送信する際に、それぞれのMACフレームの前方部に、該MACフレームが何番目の宛先に対応するかを示す情報を付加する。
複数の宛先に対するMACフレームを1つの物理フレームにアグリゲートして送信する場合、MACスーパーフレームヘッダーに各宛先の区切りを示す情報(マルチアドレスビットマップ(Multi Address Bitmap))を付加することが考えられるが、本実施形態では、図24に示すように、それぞれのMPDU(MAC Protocol Data Unit)の前方部に1バイト程度の大きさの付加フィールド240を追加し、マルチアドレスビットマップに代える。付加フィールド240には、それぞれ、当該MPDUが何番目の宛先であるかを示す情報(POS(ition)フィールドという)を記載する。
マルチアドレスビットマップ(Multi Address Bitmap)は、宛先の異なる複数の媒体アクセス制御フレームを含む物理フレームを構築する際に、該物理フレーム内の媒体アクセス制御フレームのうち先の媒体アクセス制御フレームの宛先と比べてその宛先が変化するフレームの含まれる位置に関する情報を表す。具体的には、アグリゲートされた媒体アクセス制御フレームの各々に対応するビットからなり、複数の宛先の区切りを示す。
図24の例は、8個のMPDUをアグリゲートした場合であるが、この数は固定されたものではない。例えば図24の例では、宛先(DEST)「α」へのMACフレームが先頭から4個目までアグリゲートされており、それぞれの前方部に付加されたPOSフィールドには、1番目の宛先であることを示す「1」という情報が追加される。続く宛先βへのMACフレームの前方部のPOSフィールドには、2番目の宛先であることを示す「2」という情報が記載される。ここで、もし全てのPOSフィールドの値が「1」であるならば、MACスーパーフレーム中には1つの宛先へのMACフレームしかアグリゲートされていないことを意味する。
MACスーパーフレームヘッダーがMPDU Lengthフィールドを有する場合、これには各MACフレームの長さが記載され、MACスーパーフレームペイロード中にアグリゲートされたデータフレームを長さに基づいて切り出すことができる。一方、POSフィールドがMPDUの前方部に付加された本例の場合、MPDU Lengthフィールドには、(POSフィールド(今回は1バイト) + MPDU長)の値を記入する。また、FCS(Frame Check Sequence)では、POSフィールドから、MACヘッダー、MACフレームボディまでの誤り検出を行なう。
MACスーパーフレームヘッダー中のMulti Address Bitmapによれば、複数の宛先のMPDUの存在を判断できるが、Multi Address Bitmapに依らないフォーマットとすることができる。例えば図25に示すように、MACスーパーフレームヘッダー250中に、アグリゲートされた宛先数を示すNumber of Destinationsフィールド251を追加する。このフィールド251の値が1であるならば、MACスーパーフレーム中には1種類の宛先しか存在しないことになる。その後ろに続くDestinationフィールド252とPOSフィールド253は、それぞれ、宛先のアドレスと何番目の宛先であるかを示す。例えば図25の例では、MACスーパーフレームに、宛先が「α」であるMPDUと、宛先「β」へのMPDUがアグリゲートされていたとする。Number of Destinationsフィールド251は、2つの宛先が存在することを示すために、「2」という値が記載される。Destinationフィールド252とPOSフィールド253は、固定長でそれぞれ6バイト(MACアドレス分)、1バイトとしている。図25の例のDestination 1フィールドでは、宛先αのMACアドレスが記載され、POS 1フィールドには、宛先αが何番目の宛先として存在するかを示す情報が記載されている。Destination 2フィールドでは、宛先βのMACアドレスが記載され、POS 2フィールドには、宛先βが何番目の宛先として存在するか(本例では2番目)を示す情報が記載される。
なお、MACスーパーフレームヘッダー250中のDestinationフィールド252を、アグリゲートしたMACフレームの順番通りに記載することを前提としている場合は、POSフィールド253は不要である。
(第7の実施形態)
第7の実施形態に係る通信装置は、複数の宛先に対するMACフレームを1つの物理フレームにアグリゲートして送信する際に、複数宛先の回線利用期間をMACスーパーフレームヘッダー中に含めるものである。
複数宛先に対してMACスーパーフレームをサイマルキャストする場合、各宛先から時間差的に送信されるACKは、全て同一の回線使用期間(Duration)であることを前提とする必要はない。
第7の実施形態は、各ACKが可変長である場合であり、図26に示すように、宛先毎の回線使用期間(Duration1, Duration2)261がMACスーパーフレームヘッダー260中に記載される。通常、IEEE802.11の規格において、ユニキャストデータMACフレームのDurationフィールドには、(SIFS(Short Inter Frame Space)時間+ACK転送時間)が記載される。尚、ACK転送時間は、IEEE802.11の手続きに従い、BSS Basic Rate Setの最大物理伝送レート、ACKフレーム長により計算する。なお、図27に示すように、MACスーパーフレームヘッダー270を構成してもよい。この場合、マルチアドレスビットマップを含まず、宛先(Destination)とともに回線使用期間が記載される。MACスーパーフレーム中にアグリゲートするMPDUが宛先毎であるという前提であれば、MACスーパーフレームヘッダー270のDestinationフィールドは特に必要ない。
MACスーパーフレームに対するパーシャルACK応答は、アグリゲートされたMPDUの数に比例してサイズが大きくなる。例えば、MACスーパーフレームにアグリゲートするMPDUの数が8個までなら、パーシャルACK応答のパーシャルACKビットマップは1バイトの大きさで済むが、アグリゲートされたMPDUの数が9個以上(16個以内)になると、パーシャルACKビットマップは2バイトの大きさが必要となる。すなわち、MACスーパーフレーム送信端末は、宛先毎に幾つのMPDUをアグリゲートして送信するかの情報により、宛先からの時間差的なACKの各転送時間を推測することができる。
例えば図28のように、DEST1、DEST2という2つの宛先に対し、16個のMPDUをアグリゲートして送信する場合を考える(DEST1に13個、DEST2に3個)。各宛先が作成するパーシャルACK応答の長さは異なるため、それぞれに対応したDuration値280、281が決定される。MPDUを13個アグリゲートしたDEST1への場合は、パーシャルACKビットマップが2バイトの大きさであり、MPDUを3個アグリゲートしたDEST2へは1バイトの大きさとなる。
図28の例では、サイマルキャストされたMACスーパーフレームを受信後、DEST1の端末がSIFS後にパーシャルACK282を返信する。DEST2の端末は、自分の宛先が2番目に存在しており、Duration 1の値(DEST1がパーシャルACKを送信終了するまで)+SIFS時間待機した後、自身のパーシャルACK283を送信する。DEST1は、パーシャルACK282を送信し終えてから、残りのDuration値の合計に相当するNAV(Network Allocation Vector)284を設定する。また、MACスーパーフレーム中に、自分の宛先が存在しない端末は、MACスーパーフレームヘッダーのDurationフィールドの合計値分のNAVを設定する。図28の例では、DEST1、DEST2以外の端末(OTHER STA)は、MACスーパーフレームヘッダーのDurationの値の合計(ここではDuration 1の値とDuration 2の値を加算した値)に相当するNAV285を設定する。
図29は、受信端末の動作を示すフローチャートである。複数の宛先を持つMACスーパーフレームを受信した後(ステップS1)、受信端末はMACスーパーフレームのヘッダーに対する誤り計算を行う(ステップS2)。この誤り計算の結果、エラーであれば、MACスーパーフレームを廃棄し(ステップS3)、チャネルがアイドルになった後、EIFS(Extended Inter Frame Space)の期間キャリアセンスを行う(ステップS4)。
ヘッダーが誤りでなければ、各MACフレームに対するエラーチェックを実施する(ステップS5)。次に、MACスーパーフレーム内にアグリゲートされたMACフレームの宛先の数(M個)と、自端末のMACアドレスが何番目(N番目)の宛先として存在するかを検査する(ステップS9)。
例えばDEST1に該当する受信端末へのMACフレームは1番目にアグリゲートされており(N=1)、この受信端末は通常のフレームアグリゲーションと同様のシーケンスで、SIFS期間(ステップS15)後にパーシャルACKフレーム(あるいはブロックACK)を送信する(ステップS16)。その後、他の端末(DEST2、OTHER STA)が、時間差的にパーシャルACKを返信している間は、Duration 2〜Mの値の合計期間に対応するNAVを設定して、データフレーム等の送信を停止する(ステップS17)。
2番目にアグリゲートされているDEST2は、DEST1がパーシャルACKを送信した後(ステップS11)、SIFS期間が経過してから(ステップS12)、パーシャルACKを送信する(ステップS13)。そして自端末がパーシャルACKを送信した後は、Duration N+1〜Mの値の合計期間に対応するNAVを設定する(ステップS14)。
MACスーパーフレームに自端末を宛先とするMACフレームが存在しない場合は、Duration 1〜Mの値の合計期間に対応するNAVを設定する(ステップS7)。
図30、図31はそれぞれ、本発明を適用可能な無線通信システムの構成例を示している。1つの物理フレームに複数のMACフレームをアグリゲートする通信方式は、AP(もしくはIEEE802.11eのHybrid Coordinator)とSTAとの間のダウンリンクおよびアップリンク伝送、および、STAとSTAとの間(IBSS(Independent Basic Service Set)によるアドホック通信、IEEE802.11eのDLP(Direct Link Protocol)によるQSTA同士の通信に適用可能である。
(第8の実施形態)
第8の実施形態は、サイマルキャストを行う場合におけるブロックACKに関する。第8の実施形態に係る通信装置は、複数の宛先に対するブロックACK対象のMACフレームを1つの物理フレームにアグリゲートして送信し、宛先毎のブロックACK要求送信、ブロックACK受信処理を行う。本実施形態に係る別の通信装置は、複数の宛先に対するブロックACK対象のMACフレーム、並びにブロックACK要求フレームを1つの物理フレームにアグリゲートして送信し、複数宛先からのブロックACKを時間差的に受信する。
図32に示すように、IEEE802.11eにおいて、ブロックACK対象のQoSデータフレームはSIFS間隔で送信される。
本実施形態では、複数宛先へのQoSデータフレームを1つの物理フレームにアグリゲートし、これにより伝送効率を高めるものである。図33に示すように、MACスーパーフレームヘッダーに複数宛先の存在を示す情報が付加され、ペイロード部には、宛先毎に区切ってQoSデータフレームがアグリゲートされる。この時、MACスーパーフレームを前述の図24、図25のように構成してもよい。あくまで複数宛先の存在と、その相対的な位置がMACスーパーフレーム受信端末側で判断できればよい。図33の例では、Multi Address Bitmap331を使用している。
そして図34に示すように、複数宛先へのブロックACK対象QoSデータフレームを1つの物理フレームにアグリゲートしてMACスーパーフレーム340として送信することで、伝送効率を高めることができる。図34には、MACスーパーフレーム340に続くブロックACK要求341,342に応じ、各宛先(QSTA1, QSTA2)からブロックACK343、344が送達される様子が示されている。
さらに、図35に示すように、データフレームのみならず、ブロックACK要求350,351をもアグリゲートすることも好ましい。この場合、宛先毎に区切ってアグリゲートを行い、各フレーム(データ、ブロックACK要求)のフレームサイズを記載することで、データフレームを適切に取り出し、ブロックACKの時間差的な送信を行うことも可能になる。図36の例では、QSTA1へのデータフレーム3つと、QSTA1に対するブロックACK要求、QSTA2へのデータフレーム3つと、QSTA2に対するブロックACK要求を有するMACスーパーフレーム360を作成し、これを1つの物理フレームとしてHCからQSTA1,2にサイマルキャストしており、各QSTAからのブロックACK361,362を時間差的に受信することで、システム全体の伝送効率を向上させている。
(第9の実施形態)
第9の実施形態に係る通信装置は、ある宛先に対する複数のMACフレームを1つの物理フレームにアグリゲートして送信する際、この宛先の端末がSIFS期間後にACKを送信できない場合に、予め多めに設定したNAV期間内に、再度ACKフレームを送信できるようにする通信装置である。
本実施形態に係る別の通信装置は、ある宛先に対する複数のMACフレームを1つの物理フレームにアグリゲートして送信する際、この宛先の端末がSIFS期間後にACKを送信できない場合、1つの物理フレームに他の宛先へのMACフレームをアグリゲートして送信することで、ACKフレームを時間差的に送信できるようにする通信装置である。
さらに、本実施形態に係る別の通信装置は、複数の宛先に対する複数のMACフレームを1つの物理フレームにアグリゲートして送信する際、1番目にアグリゲートされた宛先がMACスーパーフレームを受信してからSIFS期間後にACKを送信できない場合、予め多めに設定されたNAV期間内に、1番目の宛先から順番にACKフレームを送信する通信装置である。
第9の実施形態では、通信装置において、復号処理に時間の掛かるターボ符号やLDPC(Low Density Parity Check)符号が採用された場合、IEEE802.11で定められているSIFS(Short Inter Frame Space)期間中に処理が間に合わないことに対処するものである。ある宛先に対し複数のMACフレームが1つの物理フレームにアグリゲートして送信された後、当該宛先端末は、SIFS期間後にACKを返信しなくてはならないが、復号処理のためACKが送信できない場合が起こり得る。
この場合、図37に示すように、宛先以外の端末に対して設定するデュレーションの値を多めに設定することで、宛先端末が再度ACKフレームを送信する機会を与えるようにする。宛先以外の端末は、デュレーションで定められる期間のNAV(Network Allocation Vector)370を設定し、送信を停止しているため、宛先端末がACKフレームの送信をしても、衝突が生じることはない。なお、ある宛先が一般的に処理時間の掛かる符号化処理を行っていて、SIFS期間後にACKを返せないことが予想される場合、その旨をBSS(Basic Service Set)内の他端末に予め通知しておく。図37の例では、1つの宛先に対してのみMACフレームをアグリゲートしている。宛先以外の受信端末は、MPDUに記載されているデュレーションの例えば2倍の期間NAVを設定する。ここで、2倍という数値は特に固定された値ではなく、無線端末間でデュレーションの期間を通知しあってもよい。また、MACスーパーフレーム送信端末側で、MPDUのデュレーションフィールドに適切な値を記載してもよい。
図37のような状態(すなわちMACスーパーフレームに1種類の宛先のMACフレームのみをアグリゲートしている状態)では、一般に復号処理時間が多く掛かることも考えられる。この場合、図38に示すように、複数宛先のフレーム(例えばDEST2,DEST3宛てのフレーム)をアグリゲートすれば、1番目の宛先の端末がSIFS期間後にACKを送信できる可能性が高まる。これは、シンボル単位で符号化処理を行うことを前提とし、MACスーパーフレーム全体の中で、1番目の宛先のフレーム(図38の例ではMPDU3つ分)を復号する時間だけであれば、一般に、より少ない処理時間でACKを送信することができるからである。
ここで、複数宛先へのMACフレームを1つの物理フレームにアグリゲートして送信した場合、1番目の宛先がどうしてもACKをSIFS期間後に送信できない場合を考える。このような状況では、SIFS期間でACKを送信できない旨の情報を予め他端末との間で通知しあう必要がある。図39に示すように、1番目にアグリゲートされた端末以外の端末DEST2,DEST3, OTHER STAは、通常より多くのNAV390,391,392を設定する。多めに設定するNAVは、(SIFS+1番目の宛先がACKを送信する時間)に相当する。図39の例では、他の端末が予め多くのNAVを張っているため、1番目の宛先は、MACスーパーフレームを受信してから、SIFS期間後にACKを返信できない場合でも、再度ACK393を送信することが可能である。なお、図39の例では、他の全ての端末がACKを送信し終わった後に1番目の宛先がACKを送信しているが、図40のように、1番目の宛先から順番にACK400,401,402を送信することとしてもよい。
(第10の実施形態)
第10の実施形態はACKの送信時点(タイミング)を指定するものに関する。第10の実施形態に係る通信装置は、複数の宛先に対するMACフレームを1つの物理フレームにアグリゲートして送信し、各宛先端末に対し、ACKを送信する時間を指定する情報をMACスーパーフレームヘッダーに含める。
ACKを送信するタイミングをMACスーパーフレームの受信端末側で計算することに代えて、本実施形態はMACスーパーフレーム送信側で、予めACKを送信する時点を指定するよう構成される。ACKを送信する時点を送信側で指定する場合のフレームフォーマットを図41乃至図44に示す。
図41および図42は、それぞれのMACスーパーフレームヘッダー410、420中に、ACK送信タイミングの時間指定情報が含まれる例である。ACK Transfer Start Timeは、各宛先がACKを送信すべき時点を示す。具体的には、MACスーパーフレームを受信した後、SIFS+N(μ秒)後にACKを送信することとし、Nの値がACK Transfer Start Timeに記載されている。この場合、先頭の宛先に対するACK Transfer Start Time 1は、「0」が指定されている。あるいは、MACスーパーフレームを受信してから、Nμ秒後にACKを返信するといったような指定方法を行なってもよい。2番目以降の宛先のACK送信タイミングは、パーシャルACKのサイズ、物理伝送レート、何番目の宛先であるかの情報を用いて、送信側で計算する。Transfer End Timeは、全てのACKが送信し終わる予定時刻を示す。これは、MACスーパーフレームを受信してから何μ秒後に全てのACKが送信し終わるかの情報である。尚、図41のMACスーパーフレームヘッダー420のDestinationフィールドは、各MPDUが宛先の順序通りにアグリゲートされていれば必要ないが、それ以外(アグリゲートされたMPDUの順番がばらばらである場合)などには必要な情報である。
図43は、MACスーパーフレームにアグリゲートされたMPDUの前方部に、ACK Transfer Start Time430、Transfer End Time431を付加したもので、この場合、MPDU Lengthフィールドの値は、ACK Transfer Start Time430とTransfer End Time431のフィールド長だけ増える。図44は、MACスーパーフレームにアグリゲートされたMPDUの前方部に、ACK Transfer Start Time440を付加し、MACスーパーフレームヘッダー441に一つのTransfer End Time442を付加するものである。図43では、MACスーパーフレームペイロード中のFCS計算は、Timeフィールド、Endフィールド、MACヘッダー、MACフレームまでを対象として行われる。図44では、Timeフィールド、MACヘッダー、MACフレームまでがFCSの計算対象である。
図45に示すように、DEST1の受信端末はACK Transfer Start Time450にACK(Partial ACK)455の送信を開始するとともに、同ACK送信後にTransfer End Time452までのNAV453を設定する。DEST2の受信端末はACK Transfer Start Time451にACK(Partial ACK)456の送信を開始する。同ACK456の送信終了時点はTransfer End Time452に一致しており、NAVの設定は行わない。フレーム受信の対象ではない他の端末(OTHER STA)はTransfer End Time452までのNAV454を設定する。
(第11の実施形態)
第11の実施形態に係る通信装置は、複数の宛先に対するACK必要、不必要のMACフレームを優先度毎に束ねて1つの物理フレームにアグリゲートして送信する。各宛先端末は時間差的にACKを送信する。
図46に示すように、MACスーパーフレームヘッダー460はマルチアドレスビットマップ(Multi Address Bitmap)461とACKポリシービットマップ(ACK Policy Bitmap)462の双方を含む。各受信端末は、マルチアドレスビットマップ(Multi Address Bitmap)461に基づくことで適切にNAVを設定し、ACKの送信タイミングを算出できる。一方、ACKポリシービットマップ(ACK Policy Bitmap)462によれば、ある宛先宛のMPDUが全てNo ACK Policyであるならば、その宛先はACKを送信しないため、続く宛先端末がACKを送信する、といったACK制御を行える。
例えば図47に示すように、DEST 2に対するMPDUは全てNo ACK Policyであるため、DEST 3は、DEST 1がACK470を送信し終えた後に、ただちにACK471を送信できる。DEST 2の端末は、全てのACKが送信し終わるまでNAV472を設定する。尚、図46に示すMACスーパーフレームのヘッダー構成はあくまで一例であり、上述したヘッダーフォーマットを適宜組み合わせたり、ACKの送信タイミングを指定したりすることで、効率向上を図ることができる。
(第12の実施形態)
図48は本発明の第12の実施形態に係る通信装置(アクセスポイント)の構成を示すブロック図である。この通信装置100Aは無線リンクを介して他の通信装置と通信する装置であり、物理層、MAC層、およびリンク層のそれぞれに相当する処理ユニット101A、102A、103Aを有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはLSIに組み込まれたCPUにより実行されるファームウェア等として実現される。物理層の処理ユニット(以下、「処理ユニット」の表記を省略)101Aにはアンテナ104Aが接続されている。MAC層102Aは本発明に係わるアグリゲーション(集約)処理部105Aを有する。このアグリゲーション処理部105Aはキャリアセンス制御部106A、メディアアクセス制御部108A、ポーリング・データ送信スケジュール制御部1051、再送制御部107Aを備える。物理層101Aは、二種類の物理層プロトコルに対応可能に構成される。それぞれのプロトコル処理のために、物理層101Aは第一種の物理層プロトコル処理部109Aおよび第二種の物理層プロトコル処理部110Aを有する。なお、実装では第一種の物理層プロトコル処理部109Aと第二種の物理層プロトコル処理部110Aとの間で回路の共用などがしばしば行なわれるため、これらは必ずしも独立して存在するわけではない。
本発明の実施形態では、第一種の物理層プロトコルはIEEE802.11aに規定されるプロトコルとし、第二種の物理層プロトコルは送信側と受信側とでそれぞれ複数のアンテナを用いる、いわゆるMIMO(Multiple Input Multiple Output)によるプロトコルと仮定する。周波数帯域を同一に保ってもアンテナの数にほぼ比例した伝送容量の増加が見込めることから、MIMOはIEEE802.11の更なる高スループット化を目指すために利用可能な技術の一つである。リンク層103Aに関しては、IEEE802で規定される通常のリンク層機能を有するものとする。伝送レートを向上するために採用する技術はMIMOに限定されない。例えば、周波数占有帯域を増やすような方法、およびそれとMIMOの組み合わせでも構わない。
図49は本実施形態に係る通信装置(端末)の構成を示すブロック図である。図48に示す通信装置(アクセスポイント)100Aとの大きな相違は、アクセスポイント100AのMAC層102Aはポーリング制御も行なうことができるポーリング・データ送信スケジュール制御部1051を持つのに対し、端末100SのMAC層102Sはポーリング制御なしのデータ送信スケジュール制御部1052を持つ点である。他の構成要素についてはアクセスポイント100Aと同様であり、参照数字の末尾を「S」としている。
図50は本実施形態に係る通信装置が用いるフレームフォーマットの一例を示す図である。フレームフォーマット200は物理層およびMAC層に係わるフレーム構造を概略的に示しており、具体的にはIEEE802.11またはその拡張に従うものを想定する。なお、IEEE802.11のフレームは制御フレーム、管理フレーム、データフレームの三種類に大別され、本発明の実施形態においては主にデータフレームと制御フレームに適用されることを想定するが、必ずしも管理フレームへの適用が除外されるものではない。図50に示すように、このフレームフォーマット200はPHYヘッダー201と、MACスーパーフレームヘッダー202およびMACスーパーフレームペイロード203と、PHYトレーラ204とから構成されている。MACスーパーフレームヘッダー202およびMACスーパーフレームペイロード203は後述するPHYペイロードに相当する。
PHYヘッダー201は受信側通信装置(アクセスポイント、または端末)の物理層101により処理される。すなわち物理層101は受信したPHYヘッダー201に基づいて、フレーム先頭の検出、キャリアセンス、タイミング同期確立、増幅器の増幅度制御(AGC: Automatic Gain Control)、送信側キャリア周波数への追随(Automatic Frequency Control)、伝送路推定などを行う。また物理層101はPHYヘッダー201に続くPHYペイロードの変調方式や符号化率、ならびに伝送レートおよびデータ長の検出も行う。
図51は第一種のPHYフレームのフォーマットの一例を示す図である。このフォーマットはIEEE802.11aに規定のものと同じである。第一種のPHYフレームは本発明に係る通信装置が既存の通信装置と通信する際に用いられ、物理層101の第一種の物理層プロトコル処理部109によって処理される(ここでは、IEEE802.11aによる通信とする)。図51に示すように、第一種のPHYフレームすなわち第一種のPLCPフレームは、PLCP(Physical Layer Convergence Protocol)ショートプリアンブル301およびPLCPロングプリアンブル302と、シグナルフィールド303と、データフィールド304とから構成される。シグナルフィールド303は、PCLPヘッダー305に相当し、同図に示すように伝送レート(Rate)フィールド306とデータ長(Length)フィールド307とを有する。なお、第一種のPHYフレームはIEEE802.11aに規定のもののみに限定されないことは言うまでもない。
図52は第二種のPHYフレームのフォーマットの一例を示す図である。第二種のPHYフレームすなわち第二種のPLCPフレームは、第一種の物理層プロトコルのための第1のヘッダー部401と、第二種の物理層プロトコルのための第2のヘッダー部402とを有する。第1のヘッダー部401と第2のヘッダー部402とは時系列に沿って配置されており、図50に示したPHYヘッダー201に対応する。
また、第二種のPHYフレームは第2のヘッダー部402に続くPHYペイロード403と、テイル(Tail)およびパッドビット(Pad bits)404とを有する。PHYペイロード403は図におけるMACスーパーフレームヘッダー202およびMACスーパーフレームペイロード203に対応しており、物理層のフォーマットにおけるPSDU(PLCP Service Data Unit)に相当する。また、テイルおよびパッドビット404は図50のPHYトレーラ204に対応している。
第一種の物理層プロトコルのための第1のヘッダー部401は、PLCPショートプリアンブル405と、PLCPロングプリアンブル406と、シグナルフィールド407とから構成される。シグナルフィールド407はPLCPヘッダーの全部又は一部に相当し、少なくとも伝送レートフィールド408およびデータ長フィールド409には物理キャリアセンスを行えるように有効な値が設定される。このようなシグナルフィールド407は、図51に示した第一種のPHYフレームのPLCPヘッダー305との間で対応する情報内容および変調方式などが同一である。
第二種の物理層プロトコルのための第2のヘッダー部402は、MIMOシグナルフィールド411と、MIMO用PLCPロングプリアンブル410と、MIMOサービスフィールド412とから構成される。MIMOシグナルフィールド411は、同図に示すように伝送レートフィールド413およびデータ長フィールド414を有し、物理キャリアセンスにおいて参照される。MIMO用PLCPロングプリアンブル410は、第二種の物理プロトコルを解釈可能なMIMOの受信側通信装置が、復号処理に必要な伝送路情報を取得する際に用いられる。
第二種のPHYフレームを図52に示すようなフォーマットとしていることにより、第一種の物理層プロトコルのみに従って動作可能な既存の通信装置は、少なくとも最初のシグナルフィールド407は解釈できるので該シグナルフィールド407に基づいて正しく物理層のキャリアセンスを行える。したがって、このような既存の通信装置と、第一種に加え第二種の物理層プロトコルにも従って動作可能な通信装置との間で同一の物理層のキャリアセンス情報を共有することが可能となる。なお、既存の通信装置はMAC層のキャリアセンス情報は共有できないが、このことは、パーシャルACKにより問題とはならない。
物理媒体上をPHYペイロードが送信される際の該PHYペイロードによる媒体占有期間(以下、「物理的占有期間」という)を表す情報は、信号強度と共に物理層のキャリアセンス情報として利用される。受信側通信装置は、当該PHYペイロードの物理的占有期間を物理キャリアセンスにより知った時点で、該期間は物理媒体が占有されている(PHYビジー(busy))と解釈する。また、信号強度が一定の閾値を超えている期間も物理媒体が占有されていると解釈する。PHYペイロードの物理的占有期間は、受信側通信装置において検出されたPHYペイロードの伝送レート(408または413)とデータ長(409または414)とから計算により求めることができる。具体的には、オクテット長で表されるデータ長フィールドの値を伝送レートフィールドの値で除算することで求めることができる。これは図51に示した第一種のPHYフレームについても同様である。
なお、第一種の物理層プロトコルが許容するPHYペイロードの最大データ長(IEEE802.11aにおいては4096オクテット)が、実際には第二種の物理層プロトコルの許容するPHYペイロードの最大データ長よりも短い場合には、PHYペイロードの物理的占有期間が適切となるように伝送レートフィールド408とデータ長フィールド409とを意図的に偽って設定すれば、物理層のキャリアセンス情報の共有が可能となる。
ここで、図50を参照する説明に戻る。一つのMACスーパーフレームは複数のMACフレームを含む単一のPHYフレームから成る。同図に示すフレームフォーマット200において、MACスーパーフレームヘッダー202は、8つのMACフレームのデータ長フィールド1〜8を固定的に持つ。なお、本実施形態ではMACスーパーフレームヘッダー202は固定長とするが、MACフレーム数を示す情報を追加することにより、MACスーパーフレームヘッダー202を可変長としても良い。
MACスーパーフレームペイロード203には例えば4つのMACフレーム1〜4のみが含まれる場合、同ペイロード203内には存在しないMACフレーム5〜8に対応するMACフレームデータ長フィールド5〜8にはゼロの値が埋められる。また、後述する再送制御の際に、例えば、MACフレーム1とMACフレーム3は再送が必要だが、MACフレーム2とMACフレーム4は再送の必要がない場合、MACフレームデータ長1>0、MACフレームデータ長2=0、MACフレームデータ長3>0、MACフレームデータ長4=0という具合に、再送の対象でないMACフレームを指定する際にもMACフレームデータ長はゼロに設定され得る。
なお、MACフレームが存在しないことを示すために、MACフレームデータ長をゼロと設定する以外の方法をとっても良い。例えば、MACスーパーフレームペイロードに最大8個のMACフレームを含むことができ、かつ当該MACスーパーフレームにはMACフレーム1〜4が存在し、MACフレーム5〜8が存在しない場合、存在の有無を8ビットのビットマップで示しても良い。このビットマップはMACスーパーフレームヘッダーの一部となる(図示せず)。
HCS205はヘッダーチェックシーケンス(Header Check Sequence)のことであり、MACスーパーフレームヘッダー202の誤りを検出可能にするため同ヘッダー202に付加される。受信側通信装置がHCS205によりMACスーパーフレームヘッダー202の誤りを検出した場合には、当該MACスーパーフレームペイロード203に含まれる全てのMACフレームは壊れているものと解釈する。
受信側通信装置におけるバッファあふれを防止するために、MACスーパーフレームペイロード203に含めるMACフレーム数を動的に制限することが好ましい(スライディング・ウインドウ(Sliding Window)制御)。
図53はMACフレームのフォーマットの一例を示す図である。図50のMACスーパーフレームペイロード203に含める一つのMACフレームは、MACヘッダー500と、フレーム本体501と、FCS(frame check sequence)502とから構成される。MACヘッダー500は、フレーム制御フィールド503と、期間(Duration)フィールド504と、アドレスフィールド505〜507,509と、シーケンス制御フィールド508とから構成される。フレーム本体501は0〜2312オクテット長の範囲で可変長であり、MPDU(MAC Protocol Data Unit)に相当するMACフレームのペイロードである。
第二種の物理層プロトコル(本実施形態では例えばMIMOとしている)による物理層の高速化に伴い、本実施形態ではMACスーパーフレームとしてPHYフレームに複数のMACフレームを含めることでフォーマットを効率的に構成していることから、フォーマットに起因するPHYフレームごとのオーバヘッド、すなわちPLCPヘッダー、各種IFS(Inter Frame Space)およびバックオフなど、を回避して通信の実質的なスループットを向上できる。
図54は、本発明の第12の実施形態に係る通信システムの一例を示す図である。この通信システムにおいて、無線リンクを介して通信装置1(アクセスポイント)、通信装置2〜4(端末)が通信を行うものとする。同図に示す通信装置1は図48に示した構成を有する。また、通信装置2、3(端末)は図49に示した構成を有する。これに対し通信装置4(レガシー端末)は第一種の物理層プロトコル処理部109Sのみを備え、第二種の物理層プロトコル処理部110Sを備えておらず、よってMACスーパーフレームの送信を行わない既存の通信端末に相当する。
図55(a)にパーシャルACK(部分応答)フレームのフォーマット例を示す。フレーム制御フィールド550のtype / subtypeフィールドに、当該フレームがパーシャル(Partial)ACKであることを示す値が入る。パーシャルACKビットマップ551には、送達確認の対象となるデータフレームが、受信側の端末あるいはアクセスポイントで正常に受信されたか否かの送達確認状態を示す値が入る。パーシャルACKは、選択的な再送制御(いわゆるSelective Repeat)を行なうために用いられる。パーシャルACKフレームには、物理層レベルの情報を返すために、PHYフィードバック情報552を含めても良い。また、パーシャルACKによるポールを可能にする情報(ビット)を付与しても良い(図示せず)。
図55(b)にポール(Poll(no data))フレームのフォーマット例を示す。フレーム制御フィールド553のtype / subtypeフィールドには、当該フレームがデータを含まないポールフレーム(「Poll(no data)」と記す)であることを示す値が入る。Poll(no data)フレームは、アクセスポイントが端末に対して送信権を与えるために用いられる。このアクセスポイントは、IEEE802.11e “Medium Access Control(MAC) Quality of Service (QoS) Enhancement”(現在はドラフト仕様)、ないしはその拡張に従うものであっても良いし、そうではなくても良い。なお、IEEE802.11eでは、物理的なアクセスポイントとハイブリッドコーディネータ(Hybrid Coordinator)と呼ばれるスケジュール管理の論理的な実体とが区別されているが、本発明に従う実施形態は両者を特に区別することなく実現することができる。
図56(a)にデータ(Data)フレームのフォーマット例を示す。フレーム制御フィールド560のtype / subtypeフィールドに、当該フレームがデータフレームであることを示す値が入る。MACペイロード(あるいはMSDU: MAC Service Data Unit)561には、ユーザデータ(一般にはリンク層がMAC層に送信を要求するデータ)が入る。
図56(b)にData + Pollフレームのフォーマット例を示す。フレーム制御フィールドのtype / subtypeフィールドには、当該フレームがデータを含んだポールフレーム(「Data + Poll」と記す)であることを示す値が入る。Data + Pollフレームは、アクセスポイントが端末に対して送信権を与える必要があり、かつアクセスポイントが端末に対してユーザデータ562を送信するために用いられる。
これらのフレーム(MACフレーム)は、アグリゲートされない単独のMACフレームとして送受信されても良いし、他のMACフレームとともに単一の物理フレームにアグリゲートされ、MACスーパーフレームとして送受信される場合もある。
なお、従来の通信装置4(レガシー端末)は、単独のMACフレームのみ送受信可能であって、通信装置1(アクセスポイント)と通信装置2、3(MIMO対応端末)は、単独のMACフレームと、MACスーパーフレームのいずれをも送受信可能であると仮定する。
図57は、図50に示した複数のMACフレームを単一の物理フレームにアグリゲートする場合の基本的なアグリゲートフレームフォーマットの全てのMACフレーム(MACフレーム1〜4)をデータフレームとした場合を例示している。図57のフレームは、端末とアクセスポイントとの間、ないしは端末間で相互にユーザデータを送受信するために用いられる。
図58は、アグリゲートフレームフォーマットのMACフレーム1をパーシャルACKフレームとし、MACフレーム2をData + Pollフレームとし、MACフレーム3、4をデータフレームとした場合を例示している。図58のフレームは、アクセスポイントが端末に対する送達確認(パーシャルACK)を行うとともに端末に対し送信権を与え、かつ端末にユーザデータを送信する際に用いる。ここで送達確認対象の端末、送信権を与える端末、データ送信対象の端末は、一般には同じであるが、それぞれ異なることを禁止するものではない。
図59は、アグリゲートフレームフォーマットのMACフレーム1をパーシャルACKフレームとし、MACフレーム2をPoll(no data)フレームとした場合を例示している。図59のフレームは、アクセスポイントが端末に対する送達確認を行い、かつ端末に対し送信権を与える際に用いる。ここで送達確認対象の端末、送信権を与える端末は、一般には同じであるが、それぞれ異なっても構わない。
図60は、アグリゲートフレームフォーマットのMACフレーム1をPoll(no data)フレームとした場合を例示している。図59のフレームは、アクセスポイントが端末に対し送信権を与える際に用いる。
なお、アグリゲートフレームへの複数のMACフレームの組み合わせ方は、上述したもののみに限定されず、他の様々な組み合わせ方が可能である。
図61(a)に、MACヘッダーにQoS制御フィールドを持つ、QoSデータフレームのフォーマット例を示す。フレーム制御フィールド610のtype / subtypeフィールドに、当該フレームがQoSデータフレームであることを示す値が入る。MACペイロード(あるいはMSDU: MAC Service Data Unit)611には、ユーザデータ(一般にはリンク層がMAC層に送信を要求するデータ)が入る。
図61(b)に、MACヘッダーにQoS制御フィールドを持つ、QoS Data + Pollフレームのフォーマット例を示す。フレーム制御フィールド612のtype / subtypeフィールドに、当該フレームがQoS Data + Pollフレームであることを示す値が入る。QoS Data + Pollフレームは、アクセスポイントが端末に対して送信権を与える必要があり、かつアクセスポイントが端末に対してユーザデータ613を送信するために用いられる。
図61(a)に示すQoSデータフレーム、および図61(b)に示すQoS Data + Pollフレームは、それぞれ図56(a)のデータフレーム、および図56(b)のData + PollフレームのQoS拡張であり、IEEE802.11eないしはその拡張に準拠する場合に用いられる。
図62は、アグリゲートフレームフォーマットの全てのMACフレーム(MACフレーム1〜4)をQoSデータフレームとした場合を例示している。図62のフレームは、端末とアクセスポイント間、ないしは端末間で、相互にユーザデータを送受信するために用いられる。その他、これまでに示したアグリゲートフレームフォーマットにおけるデータフレームをQoSデータフレームに置き換えたものや、QoSデータフレームを含むそれ以外の組み合わせも可能である。
図63は、IEEE802.11-1999仕様に規定される、PCF(Point Coordination Function)を用いた際のフレーム交換シーケンスの一例を示している。IEEE802.11では、コンテンション(競合;Contention)期間630においては、CSMA/CAベースのDCF(Distributed Coordination Function)により、端末とアクセスポイントが対等にメディアを取り合うが、コンテンションフリー(無競合状態すなわち解放;Contention Free)期間631においては、アクセスポイント(あるいはアクセスポイント内のポイントコーディネータ(Point Coordinator)と呼ばれる論理的な実体)がポーリングにより全てのメディアアクセスを制御する。アクセスポイントは定期的にビーコン(Beacon)フレーム632を送信する。コンテンションフリー期間631は、Contention Free Repetition Interval(ビーコン送信間隔の整数倍)633に対応するビーコンにより開始され、アクセスポイントが送信するCF-End(Contention Free End)フレーム634により終了し、あるいはCF_Max_duration635の経過によっても終了する。コンテンションフリー期間631においてアクセスポイント以外の端末はNAV636を設定し、MAC層のレベルでメディアがビジーであると解釈する。これによりポーリングによらない自発的な送信が抑制される。
CF期間(631)中は、アクセスポイントは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)されている。図64に示すように、IEEE802.11との大きな相違は、アクセスポイント(Hybrid Coordinator)が、コンテンション(競合)期間640中の任意の時点でポーリング制御のためのコントロールド・アクセス期間(CAP:Controlled Access Period)641,642,643等を開始できる点にある。即ちアクセスポイントは、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フレームは、物理フレームと1対1で対応する単独のMACフレームであり、一つの物理フレームに複数のMACフレームがアグリゲートされたMACスーパーフレームではない。しかし、複数のMACフレームを単一の物理フレームにアグリゲートすることにより、物理フレーム毎に付随するオーバヘッド(プリアンブル、物理ヘッダー、IFS(Inter Frame Space)など)を削減することができるため、MACの効率が向上する。以下では、アグリゲートされたMACフレームに関するポーリングシーケンスに関して説明を行なう。
図65は、PCFをフレームアグリゲーションにより拡張した場合の、ポーリングシーケンスの一例を示している。コンテンションフリー期間はビーコンフレーム650により開始される。ビーコンフレーム650を送信する時刻(時点)は、アクセスポイントのポーリング・データ送信スケジュール制御部1051により決定される。当該時刻にビーコン650を送る前にPIFS期間のメディアの空きが要求されるが、これはキャリアセンス制御部106Aにより確認され、確認後にメディアアクセス制御部108Aによりビーコンフレーム650が物理層に渡される。ビーコンフレーム650は、IEEE802.11a準拠端末と仮定される通信装置4(STA3 Legacy)を含む、全ての端末装置が受信可能でなければならない。したがって、IEEE802.11aの送受信を司る第一種の物理層プロトコル制御部109Aによって第一種(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)フレーム651を送信することにより、STA1に送信権を与える。この時点でSTA1に送信権を与えるという決定は、アクセスポイントのポーリング・データ送信スケジュール制御部1051が行なう。この例では、poll(no data)フレーム651をMACスーパーフレームとして送信している(図中の"SF"は"Super Frame"の略である)。
このMACスーパーフレームは、MIMOの送受信を司る第二種の物理層プロトコル制御部110Aによって第二種の物理フレームとして形成され、送信される。しかし、ここで必要なMACフレームは1つだけなので、通常のMACフレームとして送信しても良い。この場合、IEEE802.11aの送受信を司る第一種の物理層プロトコル制御部109AによってIEEE802.11aの物理フレームとして形成され、送信されても良い。
pollフレーム651がアクセスポイントから第二種の物理フレームとして送信された場合、端末(STA1)はMIMO PLCPロングプリアンブル(図52)によって、アクセスポイントと端末との間のMIMOチャネルの状態を推定することができる。一般に、チャネル状態を検出し、送信側で適切な制御(例えば、MIMOの複数ストリームやOFDMの複数サブキャリアに対して、電力あるいは情報量を均等に割り当てるのではなく、適切に傾斜配分する、パワーローディングやビットローディング、およびその組み合わせ)を行なうことによって、伝送路の容量が増大することが知られている。また、より単純な送信制御、例えば端末で測定した受信電力などの情報により、端末が送信する際の適切な送信レート(変調方式・符号化率など)を制御しても良い。
また、MACスーパーフレームヘッダーのPHYフィードバック情報5000(図50参照)に、当該フレームをアクセスポイントが送信する際のパラメータ、例えば送信電力やアンテナ利得の情報を含めることにより、端末による上記チャネル状態の推定を補正することができる。即ち、アクセスポイントと端末との間の送信電力やアンテナ利得の差により、チャネル推定の結果を誤って解釈することを防ぐことができる。例えば、アクセスポイントの送信電力が端末の送信電力より大きいのに、同じと仮定した端末がチャネル推定を行なえば、チャネル状態を誤認する。誤認したチャネル状態で可能と解釈した最大のレートを選択して、端末がアクセスポイントにフレームの送信を行なえば、アクセスポイントでは当該フレームを受信できない可能性が高くなる。したがって、MACスーパーフレームヘッダーのPHYフィードバック情報5000に、同一端末からアクセスポイントへの直前の送信に基づく物理層の受信状態データ(チャネル推定情報、誤り訂正量、受信電力)などを含めることは、端末側での適切な送信制御に有用である。
図65の説明に戻る。アクセスポイントからのポーリングを受けた端末(STA1)は、アクセスポイント宛の複数のデータフレームを単一のMACスーパーフレーム652にアグリゲートし、送信する。送信すべきデータフレームは、図49に示すデータ送信スケジュール制御部1052により選択される。QoSなどを意識する必要がなければ、単純にキューの先頭のデータフレームから順番に送信対象として選択すればよい。QoSが必要な場合には、優先度の高いデータフレームや、定期的に送信すべきタイミングにあるデータフレームから送信対象として選択する。単一のMACスーパーフレームに、複数優先度のデータフレームが含まれてもよい。
図49に示す端末のメディアアクセス制御部108Sは、自端末へのポーリングを受信したら、SIFS後にMACスーパーフレームを送信するように制御する。MACスーパーフレームは、データ送信スケジュール制御部1052が上記のように選択したデータフレームを含むように構成される。このMACスーパーフレームは、MIMOの送受信を司る第二種の物理層プロトコル制御部110Sによって第二種の物理フレームとして形成され、送信される。
アクセスポイントは、このフレームを受信すると、最初にMIMOの送受信を司る第二種の物理層プロトコル制御部110A(図48)により、物理層101Aの受信処理を行い、MACスーパーフレームを取り出し、MAC層102Aに渡す。この際に、物理層101Aにおける受信状態の情報を付加情報としてMAC層102Aに渡しても良い。
アクセスポイントの再送制御部107Aは、MACスーパーフレームに含まれる各データフレームが正常に受信されたか否かをFCSにより決定し、送達確認情報(パーシャルACKビットマップ)を含むパーシャルACKフレームを作成する。更に、パーシャルACKフレームのPHYフィードバック情報に、物理層101Aにおける受信状態の情報を含めても良い。ポーリング・データ送信スケジュール制御部1051は、当該端末(STA1)に送信すべきデータが無いことを確認し、かつ当該端末への送信権付与を継続すべきだと判断したとする。この場合、端末(STA1)宛てのパーシャルACKフレームとPoll(no data)フレームをアグリゲートして、MACスーパーフレーム653を作成する。メディアアクセス制御部108Aは、このように作成されたMACスーパーフレーム653をSIFS後に送信するようメディアへのアクセスを制御する。このMACスーパーフレーム653は、MIMOの送受信を司る第二種の物理層プロトコル制御部110Aによって第二種の物理フレームとして形成され、送信される。
端末は、このフレーム653を受信すると、最初にMIMOの送受信を司る第二種の物理層プロトコル制御部110S(図49)により、物理層101Sの受信処理を行い、MACスーパーフレームを取り出してMAC層102Sに渡す。この際に、物理層101Sにおける受信状態の情報を付加情報としてMAC層102Sに渡しても良い。
このMACスーパーフレーム653には、パーシャルACKとpoll(no data)が含まれている。ポーリングされているため、端末(STA1)は、アクセスポイント宛の複数のデータフレームを単一のMACスーパーフレームにアグリゲートし、送信することができる。送信すべきデータフレームは、図49に示す再送制御部107Sとデータ送信スケジュール制御部1052により選択される。つまり、パーシャルACKにより再送すべきMACフレームを識別し、更にデータ送信スケジュール制御部1052が、新規に送信するMACフレームと再送すべきMACフレームの優先度を勘案して、実際に送信するMACフレームを選択する。単純には優先度の高いものを先に送信すれば良い。あるいは、例えば、MACフレームに割り当てた優先度が低くても、当該MACフレームを廃棄すべきタイムアウトの残り時間が少なければ、優先度が高いがタイムアウト時間まで余裕のあるMACフレームより先に送信するという風に制御しても良い。単一のMACスーパーフレームに、複数優先度のデータフレームが含まれても問題は無い。
図49に示す端末のメディアアクセス制御部108Sは、自端末へのポーリングを受信したら、SIFS後にMACスーパーフレーム654を送信するように制御する。MACスーパーフレーム654は、データ送信スケジュール制御部1052が上記のように選択したデータフレームを含むように構成される。更に、MACスーパーフレーム654のPHYフィードバック情報5000に、物理層における受信状態の情報を含めても良い。このMACスーパーフレーム654は、MIMOの送受信を司る第二種の物理層プロトコル制御部110Sによって第二種の物理フレームとして形成され、送信される。
送信の際に、受信した物理フレームから得たチャネル状態に関する情報、受信したパーシャルACKフレームに含まれていたアクセスポイントからのPHYフィードバック情報、パーシャルACKビットマップから得られた正常な受信率などを勘案して、変調方式、符号化率、パワー・ビットローディングなどの送信制御を行なっても良い。
パーシャルACKビットマップで、後半のMACフレームが正常に受信されない傾向にある場合は、チャネルの寿命よりもMACスーパーフレーム送信に要する時間が長い可能性がある。そこで、送信するMACスーパーフレームの最大長を制限するように制御しても良い。また、MACスーパーフレームを担う物理フレームについて、フレームの先頭だけでなく、途中でもチャネル推定できる情報(ミッドアンブルなどの既知情報)を適応的に追加することで、チャネル状態が大きく変わる前に、チャネル推定の補正を行なえるようにしても良い。
以下、ポーリングシーケンスの他の例を図65の例との相違点を中心に説明する。
アクセスポイントは、応答を要するフレームを受信すると、再送制御部107AがパーシャルACKフレームを作成する。ここで、ポーリング・データ送信スケジュール制御部1051が、端末STA1へのPollおよびパーシャルACK送信よりも、端末STA2への送信権付与を優先すべきと判断したとする。また、端末STA2とのこれまでのフレーム交換に基づくSTA2に対するパーシャルACKフレームが形成済みであり、かつ端末STA2に送信すべきフレームはなかったとする。この場合、端末(STA2)宛てのパーシャルACKフレームとPoll(no data)フレームをアグリゲートし、MACスーパーフレームを構成する。メディアアクセス制御部108Aは、このように構成されたMACスーパーフレームをSIFS後に送信するようメディアへのアクセスを制御する。このMACスーパーフレームは、MIMOの送受信を司る第二種の物理層プロトコル制御部110Aによって第二種の物理フレームとして形成され、送信される。
このMACスーパーフレームを受信した端末STA2は、既述の方法と同様に、送信すべきデータフレームを選択し、MACスーパーフレームを構成し、SIFS後にアクセスポイント宛に送信する。
図65には示していないが、このようなポーリング制御を行なうコンテンションフリー期間は、図63に示したように、アクセスポイントがCF-Endフレーム634を送信するか、CF_Max_Duration635の時間経過によって終了する。
図66に示す他のシーケンス例は、アクセスポイントがCTS-Self660を自アクセスポイント宛に送信することによりCAP期間を生成する点で、図65に示したような、ビーコンフレームによりCF期間を開始するポーリングシーケンスとは異なる。このCAP期間はTXOPで示される時間が経過すると終了する。また、アクセスポイントが、SF{STA1(Pack),STA2(Poll(no data))}という1つのMACスーパーフレーム661により、端末STA1に対するパーシャルACKフレーム送信と、端末STA2に対するPoll(no data)フレーム送信とを行なっている点でも異なる。このMACスーパーフレーム661は、端末STA1からのデータフレームが全てアクセスポイントによって受信され、端末STA1からの再送の必要が無い場合などに有効である。
図67は、アクセスポイントが端末STA3(Legacy)に対するポーリングを行うポーリングシーケンスを示している。端末STA3は第一種の物理層プロトコル(例えばIEEE802.11a)のみを実装するレガシー端末であり、ポーリング制御のフレームを含むアクセスポイントと端末STA3との間のフレーム交換は、第一種の物理層プロトコルに準拠して行なわれる。また、端末STA3は、MACスーパーフレームを扱えないことが仮定されており、アグリゲーション無しのMACフレームが個別に送受信される。
このような端末STA3がMACフレームを連続的に送信する際には、IEEE802.11eに規定されたブロック(Block)ACKのフレーム交換手順に従う。つまり、SIFS間隔を空けて別々の物理フレームとしてデータフレーム670,671が次々とバースト送信され、その送達確認がブロックACK要求(Block ACK Request)フレーム672とブロックACKフレーム673により行なわれる。
レガシーな端末STA3に対してはポーリング、データ、および応答フレーム等についてMACスーパーフレームを用いない(アグリゲーションを抑制)ことにより、アクセスポイントは、ネットワークがレガシーな端末STA3を有する場合であっても共存して動作することができる。なお、ポーリング対象の端末がMACアグリゲーションに対応しないレガシーな端末であるか否かについて、アクセスポイントは事前の、何らかのフレーム交換により検出することができる。
図68は、図65に示したシーケンス例の変形に係わり、ポールフレームをMACスーパーフレームにより送信する場合において、データを有さないPoll(no data)のみならず、データを有するPoll(data)を許容するものである。
以上説明した本発明の実施形態は次のように変形することができる。これは、MACスーパーフレームヘッダーのフォーマットをMPDUと同じにするというものである。図69にMPDUと同じフォーマットを持つMACスーパーフレームヘッダー1900の一例を示す。例えばフレーム制御(Frame Control)フィールドに含まれるType / Sub-type領域に、MACスーパーフレームヘッダーであることを示す値を新たに規定して割り当てる。受信側の通信装置のMAC層は、この値にしたがって以後MACスーパーフレームの処理を行うべきか、通常のMACフレームの処理を行うべきかを決定する。期間(Duration)504の値は、当該MACスーパーフレームに含まれる他のMACフレームの期間の値の計算方法に準じて設定される。アドレス1フィールド505(Receiver Address)の値は、当該MACスーパーフレームに含まれる他のMACフレームのアドレス1と同じになるように設定される。このようにアドレス1フィールド505には受信側の通信装置を特定するアドレスが設定される。
MACスーパーフレームヘッダー1900は、分割(fragment)されずまた再送されることもないので、シーケンス制御(Sequence Control)フィールド508の値は特に意味を持たない。よってMACスーパーフレームのTypeを制御(Control)フレームとして割り当てれば、このシーケンス制御フィールド508が省略されるためより好ましい。
TypeをManagementまたはDataとして定義すると、シーケンス制御フィールド508を持つ必要があるが、その値は本発明に係る実施形態の再送制御と整合が取れるように扱う必要がある。既存の通信では例えばMACスーパーフレームの一連の再送制御において再送対象となるMACフレームのシーケンス番号(Sequence number)は連続値を取ると仮定されているので、シーケンス番号が不連続な値を設定する場合は当該MACスーパーフレームの一連の再送制御をいったん終了し、別のシーケンスによる再送制御を開始する必要がある。このためシーケンス番号の不連続が起きないようにするか、不連続になったとしても一連の再送制御を継続できるようにする必要がある。これを解決する一例として、本発明の別の実施形態に示すような再送時のウィンドウ制御をしているときは、一連の再送制御で再送対象のMACフレームに割り当てられる可能性のある最大のシーケンス番号の値がわかるので、この最大値を超える値のシーケンス番号となるように順次割り当てるという方法がある。またこの値には再送対象のMACフレームも含めて連続的な値を割り当てる必要があるのだが、再送制御をするときには再送対象のMACフレームのシーケンス番号を無視することで不連続になっても良いように制御するという方法も可能である。
図69に示すペイロードに相当する部分1901には、当該MACスーパーフレームに含まれる各MACフレームの長さを設定する。ペイロード1901には分割(fragment)に対応するためのフラグメント番号(fragment number)を含めても良い。
またFCS502は図50におけるHCS205に対応しており、FCS502を用いて通常のMPDUと同様の扱いとすれば良い。たとえばFCS502にはMACスーパーフレームヘッダー全体に対して計算したCRC値を設定する。MACスーパーフレームヘッダー1900に付随するFCS502により、受信側通信装置でMACスーパーフレームヘッダー1900が壊れていると認識した場合には、HCS205により誤りが検出された場合と同様に扱い、これを検出した受信側通信装置はMACスーパーフレーム全体を廃棄する。
(第13の実施形態)
第13の本実施形態は、単一の物理フレームに含まれる、複数のMACフレームのMACヘッダから、冗長要素を取り除き、更に効率を向上させるものである。
以下、冗長要素を取り除いたMACヘッダを、縮約MACヘッダと称する。図70に縮約MACヘッダを持つMACフレームを含むMACスーパフレーム構成の一例を示す。この例では、MACフレーム1は通常のMACヘッダを持つが、MACフレーム2、3,4は縮約MACフレームを持つように構成されている。
図71に送信側における、通常のMACヘッダを持つMACフレームからの縮約MACヘッダを持つMACフレームの生成処理と、受信側における、縮約MACヘッダを持つMACフレームから通常のMACヘッダを持つMACフレームの再現処理の一例を示す。
図70に示すように、MACスーパフレームは通常のMACヘッダを持つMACフレームを少なくとも1つ持っていると仮定する。例えば、アドレスSAを持つ有線端末が、アドレスTAを持つアクセスポイント経由で、アドレスRAを持つ端末に送信した複数のMACフレームを、単一のMACスーパフレームにアグリゲートしたと想定する。この場合アドレスSA、アドレスTA(BSSID)、アドレスRAは全てのMACフレームに共通であり、MACヘッダにアドレス情報として含まれる。送信側アクセスポイントで、単一のMACフレーム1のMACヘッダにのみアドレスSA,アドレスTA,アドレスRAを残し、他のMACフレーム2,3,4のMACヘッダからは、アドレスSA,アドレスTA,アドレスRAを省略したとしても、受信側端末で、MACフレーム1のMACヘッダから、MACフレーム2,3,4のMACヘッダを再現することが可能である(図72)。これが、図72における送信側処理、「MACスーパフレームに含まれる、他のMACフレームから再現可能なMACヘッダ情報を削除する」、受信側処理「MACスーパフレームに含まれる、他のMACフレームから再現可能なMACヘッダ情報を再現する」の一例である。また、単一のMACスーパフレームに含まれる全てのMACフレームのMACヘッダにおいて、期間フィールドの値が同じである場合も考えられる。そのような場合には、アドレスに加えて、期間フィールドも削除・再現対象となる(図73)。
通常のMACヘッダを持つMACフレームが、必ず先頭のMACフレーム1であると約束すれば、どのMACフレームが通常のMACヘッダを持つかは送信側と受信側で暗黙に了解される。あるいは、複数宛先のMACフレームが単一のMACスーパフレームに含まれる場合には、送信側STAが、各宛先の先頭のMACフレームを受信側STAに示す情報を、MACスーパフレームに含めておけばよい。これは、例えば、MACふーレムヘッダに含まれるビットマップ情報で示すことができる。ここで各宛先の先頭MACフレームは通常のMACヘッダを持つと仮定している。また、複数の属性、例えばQoS属性 (TID, TSIDなど)が単一のMACスーパフレームに含まれる場合には、送信側STAが、属性の変化するMACフレームを受信側STAで識別できる情報を含めておけばよい。ここで同一属性を持つMACフレーム群の先頭MACフレームは通常のMACヘッダを持つと仮定している。
図74に、暗号・メッセージ認証を含む場合の、縮約MACヘッダを持つMACフレームの生成、および縮約MACヘッダからのMACヘッダ再現処理の一例を示す。IEEE802.11のセキュリティ拡張を規定するIEEE802.11i (Security Enhancement) のドラフトに規定される、ユーザデータ暗号・メッセージ認証方式 (TKIPおよびCCMP) は、MACフレームのペイロード部分のみならず、MACヘッダ情報の一部もセキュリティ保護の対象としている。MACヘッダは暗号(秘匿)化の対象とはされないが、MACフレームに含まれる情報の一部(アドレス情報などを含む)は、改変を検出するためのメッセージ認証コードの計算対象となっている。このため、送信側STAと受信側STAにおけるセキュリティ処理とMACヘッダの縮約・再現処理の処理手順に依存関係が生じる。
送信側STAにおいては、最初に平文のMACヘッダとMACペイロードとの組を生成する。これを暗号化・メッセージ認証コード (ICV : Integrity Checki Value) 付与処理に渡す。これによりMACペイロードは暗号化され、かつMACペイロードにICVが付与される。MACヘッダとMACペイロード(暗号化MACペイロード + ICV)との全体に対しFCSが計算され付与される。この後でMACヘッダの縮約処理を行い、MACスーパフレームにアグリゲートして送信される。
受信側STAにおいては、最初に縮約されたMACヘッダから、通常のMACヘッダの再現処理が行なわれる。次にMACヘッダとMACペイロード(暗号化MACペイロード + ICV)の全体に対するFCSが計算され、MACフレームに付与されていたFCSと比較される。一致すれば正常受信で、一致しなければ壊れていると判断する。次に暗号化MACペイロードを復号化し、かつMACヘッダの一部とMACフレームに対するICVを計算して、一致すれば改変なし、不一致なら改変ありと判断する。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。