JP4012172B2 - 無線通信装置及び無線通信方法 - Google Patents

Description

本発明は媒体アクセス制御を行なう無線通信装置に関し、特に、サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御に関する。

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

さらに、サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御も幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するＱｏＳとして、従来のポーリング手順を拡張したＨＣＣＡ（HCF Controlled Access；ＨＣＦコントロールド・アクセス）がある。ＨＣＣＡでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。

また、特許文献１は、IEEE802.11e規格のＱｏＳについて言及しており、無線ネットワーク局間の通信に優先順位を付与する方法を開示する。
特開２００２−３１４５４６公報

IEEE802.11eにおけるHC内部には、QSTAへのポーリングフレームの送信や、ダウンリンクのデータを送信するタイミングを司るスケジューリング処理部が存在する。スケジューリング処理部は、QSTAからのトラフィックストリーム(TS: Traffic Stream)セットアップを用いて要求されるサービス品質を満たすように、優先度毎にポーリングフレームやデータの送信を行なう。

HC内部のスケジューリング処理部からの要求で、あるQSTAに向けてデータを送信する必要が生じた場合、宛先、優先度をキーとして、再送用のサブキューにフレームを格納し、MACスーパーフレームとして送信する方法が考えられる。ここで、同じ宛先に対する複数の優先度のフレームを１つのサブキュー内に格納し、MACスーパーフレームとして送信することも出来るが、宛先端末からのパーシャルACK応答を用いて、優先度毎のスライディングウィンドウ制御を行なう際の処理が複雑化し、場合によっては装置内部の処理性能の低下を招くこともありうる。

本発明はこのような事情を考慮してなされたものであり、通信のサービス品質（ＱｏＳ）を維持しつつも通信フレームのアグリゲーションによりスループットを向上するにあたり、処理が複雑化するのを回避して実装を容易化することを目的とする。

本発明の一観点に係る無線通信装置は、ＭＡＣフレームを蓄積するためのメインキューと、該メインキューに関連付けられ、優先度毎の再送制御に用いられる複数のサブキューと、前記メインキューから宛先、優先度識別子を元にＭＡＣフレームを取り出し、優先度毎に前記複数のサブキューのいずれかに振り分ける手段と、前記複数のサブキューからＭＡＣフレームを取り出し、ＭＡＣスーパフレームを作成する手段と、を具備する無線通信装置である。

本発明によれば、通信のサービス品質（ＱｏＳ）を維持しつつも通信フレームのアグリゲーションによりスループットを向上できる無線通信装置を提供できる。

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

本発明の実施の形態に係る無線通信装置は、無線リンクを介して他の通信装置と通信する装置であり、物理層、ＭＡＣ層、およびリンク層のそれぞれに相当する処理ユニットを有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはＬＳＩに組み込まれたＣＰＵにより実行されるファームウェア等として実現される。物理層の処理ユニットにはアンテナが接続されている。ＭＡＣ層の処理ユニットはアグリゲーション処理部を有する。このアグリゲーション処理部はキャリアセンス制御部と再送制御部とスケジューリング制御部とを備える。

（第１の実施形態） ［1-1.HCCA時のフレームアグリゲーション実装(優先度毎のサブキュー)］
IEEE802.11eのHCCA(HCF controlled channel access)使用時に、MACフレームアグリゲーションを行なう際、再送用のサブキューが１つしか存在しないならば、図１のようなキュー構成となる。ここでCfQとは、ポーリング期間中に送信可能なQoSアクセスポイント(HC: Hybrid Coordinator)からQoS端末(QSTA: QoS Station)への下り方向(ダウンリンク)のデータ、あるいはQSTAからHCへの上り方向(アップリンク)のデータを蓄積するためのメインキューであり、様々な宛先、優先度のMACフレームが存在する。

IEEE802.11eにおけるHC内部には、図２に示すように、QSTAへのポーリングフレームの送信や、ダウンリンクのデータを送信するタイミングを司るスケジューリング処理部が存在する。スケジューリング処理部は、QSTAからのトラフィックストリーム(TS: Traffic Stream)セットアップを用いて要求されるサービス品質を満たすように、優先度毎にポーリングフレームやデータの送信を行なうものとする。

HC内部のスケジューリング処理部からの要求で、あるQSTAに向けてデータを送信する必要が生じた場合、図１に示したように、宛先、優先度をキーとして、再送用のサブキューにフレームを格納し、MACスーパーフレームとして送信する方法が考えられる。ここで、図３に示すように、同じ宛先に対する複数の優先度のフレームを１つのサブキュー内に格納し、MACスーパーフレームとして送信することも出来るが、宛先端末からのパーシャルACK応答を用いて、優先度毎のスライディングウィンドウ制御を行なう際の処理が複雑化し、場合によっては装置内部の処理性能の低下を招くこともありうる。

そこで本実施形態では、図４に示すように、優先度毎に複数の再送制御用サブキューを用意することで、複数優先度毎のスライディングウィンドウ制御や、優先度毎のフレームアグリゲーションをより簡単に実現でき、通信装置内部での並列的な処理を行うことも可能となる。まず、HC内部のスケジューリング処理部から、ある宛先(図の例ではSTA1)へのある優先度(図の例では高優先度)のダウンリンク送信の要求が生じた際、アグリゲーション処理部は、要求に該当する宛先、優先度のフレームをメインキューから取り出し、優先度毎に用意されたサブキューに格納する。1つのMACスーパーフレームにアグリゲート可能なMPDU(MAC Protocol Data Unit)の数は、予めネゴシエーションを行なって定められており、図４の例では、8個を上限としている。尚、ネゴシエーションの方法については、特定の方法に限定されない。

図４の例のように、STA1への高優先度フレームのダウンリンク送信を行う際、高優先度用サブキューに格納したフレームの個数が、MACスーパーフレームにアグリゲート可能な最大数に満たない場合、同一宛先の異なる優先度のMACフレームを対応するサブキューに格納する。図４の例では、アグリゲート可能な最大数が8であるのに対し、スケジューリング処理部から要求のあった高優先度のフレームがサブキュー内に5個しか格納されていないため、中優先度のフレームを3個まで中優先度サブキューに格納する。図に示すように、IEEE802.11eの規定に従って、シーケンス番号は優先度毎に割り当てられている。ここで、HC内部のスケジューリング処理部からの要求は、「宛先、優先度」とする方法(MACスーパーフレームにアグリゲート可能な最大数に達するまで、メインキューからMACフレームを取り出す)や、「宛先、優先度、フレーム個数」とする方法(スケジューリング処理部から指定された個数だけ、メインキューからMACフレームを取り出す)、「宛先、優先度1、優先度1のフレーム個数、優先度2、優先度2のフレーム個数」とする方法(スケジューリング処理部から、複数の優先度の送信とそれぞれの個数を指定する)などが考えられるが、優先度毎のサブキューへの格納は、どれも図４の例と同様に行なう。

実際にMACスーパーフレームを作成する際は、高い優先度のサブキューから優先してMACフレームを取り出し、MACスーパーフレームの前方からアグリゲートしていく。図５の例のような場合を考えた際、高優先度のサブキューに5個のMACフレーム、中優先度に3個のMACフレームが格納されているとする。これらのフレームの合計は、1つのMACスーパーフレームにアグリゲート可能な最大数(図の例では8個)に等しくなっているが、該当する宛先、優先度のフレームがメインキューに存在しない場合は、アグリゲート可能な最大数に満たなくても良い。また、図５において、例えば中優先度のMACフレームが、メインキュー内部に2個しか存在しなかった場合は、更に低優先度のフレームを低優先度サブキューに格納し、MACスーパーフレームの後方にアグリゲートする。優先度毎にアグリゲートする理由は、物理フレームが長くなるほど、フレームの後半部分のチャネル推定精度が低下し、誤りが生じやすくなることを考慮し、高優先度のMPDUを保護することを目的としている。

尚、本実施形態は、HCからのダウンリンクトラフィックのみならず、QSTAからのアップリンクトラフィック送信時にも適用することが可能である。

（第２の実施形態） ［1-2.HCCA時のフレームアグリゲーション実装(優先度毎のパーシャルACKビットマップ)］
MACスーパーフレーム内に優先度毎にアグリゲートされているMPDUに関し、高優先度のフレーム群が一番前方に、中優先度のフレーム群が2番目に、低優先度のフレーム群が3番目といったように、予め各優先度がアグリゲートされる相対的な順番が定められており、送受信端末間双方で、これを認識している場合について考える。図６に示すように、MACスーパーフレーム受信端末は、アグリゲートされたMPDUの受信ステータスをパーシャルACKビットマップに記載して、パーシャルACKを返信する。この時、アグリゲートされたMPDUの優先度の種類や並び順は、パーシャルACKビットマップの作成に影響を与えない。MACスーパーフレーム送信端末側にパーシャルACKが返信されると、優先度毎のサブキューに再送用に蓄積されたMACフレームの個数から、パーシャルACKビットマップの中で、各優先度分のビットマップ情報を判断することが出来る。優先度毎の送信状況を切り出すことで、優先度毎のスライディングウィンドウ制御をより効率的に行なうことが可能である。

ここで、図７のように、MACスーパーフレームにアグリゲートされるMPDUが、必ずしも優先度毎に区切られていない場合、宛先端末からのパーシャルACKを受信しても、各優先度の送信状況をすぐ様判断することは難しい。この解決方法としては、MACスーパーフレーム送信側で、どの優先度をどの場所にアグリゲートしたかのキャッシュ情報を持っておく方法もありうるが、図８に示すように、パーシャルACKビットマップを優先度毎に用意する方法も考えられる。拡張したパーシャルACKフレームは、”Number of Priority”フィールド、並びに優先度毎のパーシャルACKビットマップを有する。”Number of Priority”フィールドは、パーシャルACK内に存在する優先度の数を示しており、”TID”フィールドは、IEEE802.11eの優先度識別子 (TID: Traffic Identifier) の値に対応している。図に示すように、拡張されたパーシャルACKフレームでは、それぞれのTID毎に、パーシャルACKビットマップが存在することになる。尚、パーシャルACKフレーム内の”TID”フィールド、及び”パーシャルACKビットマップ”の個数は、MACスーパーフレーム内にアグリゲートされた優先度の数に応じて可変であり、図８の例では、MACスーパーフレーム内に、3種類の優先度のMPDUが存在した場合を示している。また、図の例ではMACスーパーフレームにアグリゲート可能なMPDUの最大数を8とした場合で、パーシャルACKビットマップのフィールドサイズも1オクテットとなっているが、このサイズも最大アグリゲート数に応じて可変としても良い。

ここで、図９のように、MACスーパーフレーム内にアグリゲートされたMPDUが、CRC計算の結果、誤りであったとする。この時、MACスーパーフレーム受信側では、どの優先度がどのような受信状況であったかを確定することが不可能となる。そこで、図１０に示すように、MACスーパーフレームヘッダーに、新たに”TID Bitmap”フィールドを追加する。”Num of TID”フィールドは、MACスーパーフレーム内にアグリゲートされた優先度の数を示す。優先度識別子を表す”TID”フィールド(長さは１オクテットであり、そのうち４ビットをTIDに、残り４ビットを予約フィールドに割り当てる)に続き、”TID Bitmap”フィールドが存在する。”TID Bitmap”フィールドは、その優先度のフレームが、MACスーパーフレーム内の何番目にアグリゲートされているかの情報である。このビットマップ情報をMACスーパーフレームヘッダー内に含むことによって、ヘッダーCRC誤り以外の、MPDUの部分的な誤りが生じた際、MACスーパーフレーム受信端末側で、どの優先度が何番目に存在し、またその受信ステータスがどうであったかを判断することが可能となる。

図１１に、”TID Bitmap”の使用例を示す。図のように、MACスーパーフレーム内に、「中優先度」「高優先度」「中優先度」「高優先度」「低優先度」「高優先度」「高優先度」「低優先度」の3種類の優先度のMPDUをアグリゲートした場合を考える。尚、この図の例では、アグリゲート可能なMPDUの最大数を8としているが、もちろんこの数に固定されるわけではない。この時、高優先度の”TID Bitmap”は「0 1 0 1 0 1 1 0」となり、中優先度の”TID Bitmap”は「1 0 1 0 0 0 0 0」、低優先度の”TID Bitmap”は「0 0 0 0 1 0 0 1」のように示される。すなわち、その優先度に対応するMPDUがMACスーパーフレーム内のどこに存在しているかを示すための識別情報である。

“TID Bitmap”のフォーマットとしては、図１２に示すような”Bitmap Information”フィールドを用いれば、”Number of TID”フィールドを省略することも可能である。MACスーパーフレームヘッダー内の”TID Bitmap”フィールドの長さは、アグリゲート可能なMPDUの最大数に対応しているが、最大アグリゲート数は予めネゴシエーションを通じて、送受信端末双方が認識をしているため、受信側でも”TID Bitmap”フィールドの長さを判断できる。図１３の例では、最大アグリゲート数8のMACスーパーフレームヘッダー内に、3種類の優先度のMPDUがアグリゲートされており、MACスーパーフレームヘッダー内の”TID”フィールドの長さは固定長の1オクテット、”TID Bitmap”フィールドの長さもこの場合は１オクテット(最大アグリゲート数が8)であるため、”Bitmap Information”フィールドの長さ(“Length”フィールドに記載されるオクテット単位の値)は、6オクテットとなる。”Bitmap ID”フィールドには、”TID Bitmap”のための識別子が記載され、図１２の例では、2となっているが、この数値に限定されないことは言うまでもない。

図１４は本実施形態における、”TID Bitmap”フィールドを拡張したMACスーパーフレーム、優先度毎のパーシャルACKビットマップを拡張したパーシャルACKによる通信の流れを示している。図の例のように、MACスーパーフレーム内に複数の優先度のMPDUをアグリゲートした際、MACスーパーフレームヘッダー内の”TID Bitmap”フィールドには、その優先度の存在する場所の識別情報が記載される。図の例では、「1を存在」のように定めているが、もちろん負論理で実現することも可能である。MACスーパーフレーム受信端末は、MACスーパーフレームヘッダーのヘッダーCRC計算を行い、その結果ヘッダーが誤りでなければ、アグリゲートされた各MPDUのCRC計算を実行する。また、MACスーパーフレームヘッダー内の”TID Bitmap”を活用することにより、優先度毎のパーシャルACKビットマップを作成することも容易である。図の例のように、優先度毎のパーシャルACKビットマップ作成に関し、高優先度のMPDUは”TID Bitmap”から４個存在すると判断でき、かつ前方2個のMPDUはCRC計算の結果誤りであるため、「0 0 1 1 0 0 0 0」のようなビットマップ構成となる。パーシャルACKビットマップは、オクテット単位で長さが指定されるため、結果として図１４の例では、前方4ビットが受信ステータスを示す情報となる。

優先度毎のパーシャルACKビットマップを拡張したパーシャルACKが、MACスーパーフレーム送信端末側で受信されれば、優先度毎に用意した再送用サブキューからのMACフレームの削除等の手続きを並列的に行うことができ、より効率的な処理を実現することが可能となる。

（第３の実施形態） ［1-3.HCCA時のフレームアグリゲーション実装(優先度毎のスライディングウィンドウ)］
優先度毎のパーシャルACKビットマップを備えるパーシャルACKフレームを受信した際、優先度毎に用意されたサブキューに蓄積されているMACフレームをキューから削除する。図１５に示すように、高優先度と中優先度のサブキューにそれぞれMACフレームが蓄積されている場合、優先度毎のパーシャルACKビットマップを参照して、宛先に正しく送信することのできたMACフレームを削除していく。ここで、MACスーパーフレーム内のMPDUが優先度毎に区切ってアグリゲートされており、かつ高い優先度のフレームほど、前方部に詰められているという前提であれば、優先度毎のサブキューに格納されているMACフレームの個数から、パーシャルACKビットマップの内容を解釈し、それぞれの優先度のMACフレームをサブキューから削除していく。

スライディングウィンドウ制御は、優先度毎に行なわれるが、ここで、図１６〜図１９のようなケースを考える。これらの図は、高優先度と中優先度の2種類のMPDUがMACスーパーフレームにアグリゲートされている場合であるが、本発明の実施に当たっては、優先度の数に制限はないものとする。これらの図において、W_allは、連続的に送信できるMACフレームの最大数を定義したものである。各時点のウィンドウW(高)(中)は、ある優先度が1度にアグリゲート可能なMPDUの最大数を示しており、パーシャルACKビットマップの状況に応じて、ウィンドウは後方にスライドする。また優先度に関係なく、図の例ではMACスーパーフレームにアグリゲート可能な最大数を8であることを前提としている。さらに、図１６および図１７は受信側のバッファが物理的に1つの場合であり、図１８および図１９は、受信側のバッファが優先度毎に物理的に複数用意されている場合のスライディングウィンドウ制御となっている。優先度毎に複数の物理バッファを用意することは、受信機内で並列して処理を実行出来るという利点がある。優先度毎に複数の受信バッファが存在する時、MACスーパーフレーム送信端末は、宛先端末の優先度毎の受信バッファサイズに応じて、それぞれのウィンドウWを決定する。本発明はウィンドウサイズの決定のための特定のネゴシエーション方法に限定されない。

図１６〜図１９において、”Null”という表記は、アグリゲート対象のフレームがメインキュー内に存在しなかったことを意味しており、”Zero”という表記は前回送ったフレームが宛先で正しく受信できたこと、更に”NoAdd”は、1MACスーパーフレームにアグリゲート可能な最大数の関係から、メインキュー内に該当フレームがあったとしても(なかったとしても)新たに詰めない(詰めてはいけない)ことを意味している。

まずMACスーパーフレーム受信側のバッファが物理的に１つしか存在しない場合のスライディングウィンドウ制御の様子を、図１６および図１７の例を元に示す。図１６および図１７の各時点のウィンドウサイズW(高)は、宛先端末の物理バッファ(単一)に基づいて決定される。ウィンドウサイズW(中)は、高優先度のフレームのアグリゲート個数に応じて可変長となる。

図１６において、高優先度のMPDUを5個、中優先度のMPDUを3個アグリゲートして送信したとする。ここで高優先度を5個アグリゲートすると、ウィンドウサイズW1(高)に満たなく、余りが生じるため、ウィンドウサイズW1(中)は3個分の大きさを確保できる。これら複数の優先度のMPDUをアグリゲートする際は、優先度毎に区切って、高い優先度を前方にアグリゲーションすることが望ましい。その後、宛先からのパーシャルACKの情報から、高優先度のMPDUは全て正常に送信し、中優先度のMPDUは先頭のMPDUが誤っていたことが分かる。W2(高)において、高優先度はスライディングウィンドウを行うが、中優先度の先頭のフレーム(3個送ったうちの先頭)が誤っているため、宛先端末のバッファ内には中優先度の2個のフレームが格納されていることを確認する。そのため、高優先度が新たにアグリゲートできるMPDUは、Seq6〜10の5個分だけとなる。高優先度はそれ以上詰めることができないため、”NoAdd”が表示されている。中優先度は、ウィンドウサイズの大きさの変更は行なわず、Seq1の再送フレームのみをアグリゲートの対象とする。

続いて図１８の例を考える。TX1までの動作は図１６と同様である。宛先からのパーシャルACKによって、高優先度の2番目のMPDUが誤っており、中優先度のMPDUは全て正常に送信出来ていたことが分かる。スライディングウィンドウ制御を行なった後、高優先度に詰めるべきMACフレームがメインキューに存在しないならば、中優先度のウィンドウサイズはその大きさを拡大することができる。中優先度は、高優先度のMPDU3個が受信側のバッファに蓄積されていることを理解しているため、再送用の高優先度のフレーム1個と併せて、4個のフレーム分は受信側バッファ(単一)で埋まっていると考えなければならない。そのため、ウィンドウサイズW2(高)の8から4を引いた残りが、ウィンドウサイズW2(中)の大きさとなる。(ウィンドウサイズ(高)の大きさはこの場合固定長となっている)すなわち、Seq4〜7の4つのフレームをMACスーパーフレームにアグリゲートすることが可能である。

以上のような再送制御を行なっていき、W_allで示される個数の範囲内でMPDUをアグリゲートしていく。またアグリゲートのフレーム追加は、あくまで高優先度のMPDUを優先して対処する。

受信機側で優先度毎に複数の物理バッファを備える場合の、図１８および図１９について考える。複数の物理バッファを用意した場合、無線通信装置内部で、並列処理を行うことが可能である。この場合、優先度毎に受信側のバッファサイズをMACスーパーフレーム送信端末に通知し、送信側では優先度毎にウィンドウサイズWの大きさを決定する。図１８において、TX1(高)(中)から示されるように、MACスーパーフレームに、高優先度のMPDU5個と中優先度のMPDU3個をアグリゲートして送信したとする。TX1(高)のNullは、ある宛先に対する高優先度のフレームが存在しないことを意味しており、図１８の例では、TX1の時点で、高優先度のフレームが5つのみメインキューに格納されていることを示している。RX1(高)(中)時に作成されるパーシャルACKビットマップの内容に応じて、サブキューからMACフレームを削除した後、中優先度のフレーム1個に関して再送が必要であることが分かる。その後、優先度毎に各時点のウィンドウW(高)(中)をスライドさせる。MACスーパーフレームにアグリゲートされる優先度が１種類のみである場合は、各時点のウィンドウWのEndまでフレームを詰めることが可能であるが、中優先度で再送すべきフレーム1個が存在するため、TX2(高)において、Seq.No6〜12までの7個のフレームをMACスーパーフレームにアグリゲートする対象とする。TX2(中)は、高優先度のフレーム7個と中優先度で再送される1個の合計が、1つのMACスーパーフレームにアグリゲート可能な最大フレーム数に達しているため、それ以上フレームを追加しない。

図１９に示すように、パーシャルACK受信後のスライディングウィンドウ処理を行った結果、TX2(高)において、高優先度のフレームが再送用のフレーム2個のみをアグリゲートするため、中優先度のTX2(中)はSeq.No4〜9までの6個(受信側で指定された中優先度用のバッファ最大量)のフレームをアグリゲートすることが可能である。それぞれの優先度に対して、ウィンドウサイズWがW_allの範囲に収まるように、連続的に送信するMPDUの数を決定する。

（第４の実施形態） ［2-1.Block Ackの処理効率化］
IEEE802.11eで規定されているブロックACKは、Selective Repeatによる効率的な伝送をサポートしている。図２０に標準的な即時型ブロックACKのシーケンスを示す。同図に示すように、HCCAにおけるブロックACKの伝送は、QoSアクセスポイント(HC: Hybrid Coordinator)が指定したチャネル使用期間(TXOP: Transmission Opportunity)の範囲内で調整される。尚、図２０の例はCAP(Controlled Access Period)期間内に、QSTAへのポーリング、ないしはダウンリンクへのデータ送信を行なう様子を示している。図２０のHCは、QoS CF-Pollフレーム(HCがQSTAに送信を許可するために送信するQoS対応ポーリングフレーム)をQSTA1に送信する。QSTA1は与えられたTXOPの範囲内であれば自由にフレームを伝送することができ、図２０ではブロックACK対象のQoSデータをQSTA2にバースト的に送信してその期間を終えている。その後、HCは、TXOP期間2の間、QSTA2にブロックACK対象のQoSデータをSIFS間隔でバースト的に送信している。TXOP期間3におけるQSTA1は、QSTA2に対してブロックACK要求を送信しブロックACKを待つ。更にTXOP期間4で、HCがQSTA2にブロックACK要求を送信し、ブロックACKを待つというシーケンスになっている。

ここで、IEEE802.11eのブロックACKでは、受信機側で、受信ステータスを示すブロックACKビットマップを作成するために、最大で64MSDU(MSDU: MAC Size Data Unit)分の1024個までの受信履歴を、宛先、TID(Traffic Identifier)毎に管理しておく必要がある。現在の仕様では、ある宛先からバースト的に送信されるQoSデータのすぐ後にブロックACK要求を送信しなければならないという規定がないことから、ブロックACK要求受信毎に、その宛先(かつTID)の受信ステータスを確認し、ブロックACKを作成する作業により、一般に受信機側の処理負荷が重くなってしまう。これにより、SIFSの期間に間に合わず、図２１に示すような遅延型ブロックACKによる伝送しか実現できない場合もありうる。遅延型ブロックACKは、ブロックACK要求を受信した後、一定時間経過してからブロックACKを送信するものであり、伝送効率の低下が生じることが明らかである。これは、ある端末の送信期間内に実行されたブロックACK伝送が次のTXOP期間にまたぐような場合、他の端末からのブロックACK伝送のQoSデータが割り込み、受信側でそれぞれの受信ステータスを管理する機構が複雑になることを要因としている。

そこで本実施形態の第１の構成例では、TXOPを得た端末は、その期間内にQoSデータのバースト送信、ブロックACK要求の送信、ブロックACKの受信までの一連のシーケンスを全て包含するようにスケジューリングを行なう。図２２に、フレームシーケンスの様子を示す。図２０のブロックACKシーケンスでは、あるTXOP期間が与えられても、そのTXOP期間内に必ずしもブロックACK要求を送信することはないが、図２２に示す本実施形態では、TXOP期間内にQoSデータのバースト伝送、ブロックACK要求の送信、ブロックACK受信までを必ず終えるように、端末内部でスケジュールする。具体的には、バースト送信するQoSデータの数を減らし、ブロックACKを確実に受信できるように、余裕を持ってブロックACK要求を送信する。ブロックACK要求送信のタイミングについては、各QoSデータのデュレーション、個数、及び物理伝送レートから適切な時機を計算する。なお、本発明はブロックACK要求送信のタイミングの計算方法を特定の方法に限定するものではない。尚、あるTXOP期間内では、複数の優先度(TID)のQoSデータをバースト的に送信することができるが、この場合も、バースト伝送するQoSデータの数を制限するなどの処置をして、図２３のように、TID毎のブロックACKがTXOP内に受信できるように、フレーム送信スケジューリングを行なう。更に、図２４のように、TXOP期間内では、複数の宛先に対してブロックACKによる伝送を行なっても良いが、ここでもTXOP期間内にそれぞれの宛先からのブロックACKを受信できるように、送信端末側でフレーム伝送のスケジューリングを行なう。もし、QoSデータを1個伝送してブロックACK要求を送信することのできない時間しか残されていないならば、その宛先(あるいはTID)へのブロックACKを前提としたデータ伝送を次の機会(TXOP)に先送りすることが望ましい。

次に、本実施形態の第２の構成例は、与えられたTXOP期間でバースト伝送する最後のQoSデータにブロックACK要求をアグリゲートして送信するというものである。図２５に示すように、QoSデータとブロックACK要求を1つの物理フレームにアグリゲートして伝送することで、よりチャネル効率を有効に使用することができる。図２６、図２７は、アグリゲートしたQoSデータとブロックACK要求のフレームフォーマットである。図２６の例では、IEEE802.11のMACヘッダー(IEEE802.11eのQoS制御用情報を含む場合もある)の、”Type”、”Sub Type”、”Length”等の情報を元に、アグリゲートしたMPDUの区切り(長さ)を示す情報を、MACペーロードとして備えるフォーマットを示している。このフィールドをアグリゲーションフィールドと呼ぶ。また、802.11MACヘッダー、MPDUの長さを示すフィールドに対するFCS(Frame Check Sequence)が付加される。アグリゲーションフィールドには、機能拡張を目的とした、ビットマップ情報などを追加することも可能である。図２７のでは、アグリゲートされたMPDUの長さを示す識別ヘッダーを新たに設けた場合の例を示している。このヘッダーを、アグリゲーションヘッダーと呼ぶ。アグリゲーションヘッダーには、ヘッダーの誤りを計算するためのHeader CRCが付加され、ヘッダーが誤っていた場合は、アグリゲートされたフレームを全て廃棄する。アグリゲートされたQoSデータ、ブロックACK要求などのデータペイロードの前方には、このアグリゲーションヘッダーが付加される。尚、図２７のアグリゲーションヘッダーのフォーマットは、アグリゲート可能な最大数を8とした場合であることから、図２８のように複数のQoSデータをアグリゲートすることも、もちろん可能であり、ブロックACK要求ではなく、ブロックACK対象のQoSデータのみをアグリゲートすることもできる。1つの物理フレームにアグリゲート可能なMPDUの最大数は予め何らかのネゴシエーションを通じて、送受信端末間で認識している必要があるが、具体的なネゴシエーションの方法は、本発明の対象外とする。

ここで、図２９のように、QoSデータのみを1つの物理フレームにアグリゲートしてバースト的に送信することも出来る。図３０のように、あるTXOP期間内に複数の優先度のQoSデータをバースト伝送している場合も、最後のQoSデータに複数TID毎のブロックACK要求をアグリゲートして送信することで、伝送効率を改善することができる。また、宛先端末からもTID毎のブロックACKをアグリゲートして送信すれば、より効果は大きい。ここで、図３０のSIFS間隔でバースト伝送される複数のQoSデータは、図３１のように、アグリゲートして1つの物理フレームとして送信することももちろん可能である。

次に、ブロックACKによるQoSデータの受信機側について説明する。

図３２は、ブロックACKによるQoSデータの受信機側に相当する無線通信装置のブロック図である。受信機は、バースト伝送されるQoSデータ、ブロックACK要求を受信する制御部、ブロックACKを作成する制御部を持つ。さらに、即時型ブロックACKに備えた記憶領域と、遅延型ブロックACK用の記憶領域を有する。

ある宛先からQoSデータのバースト的な受信を開始した場合、即時型ブロックACK用記憶領域に、データフレームの受信ステータスを格納していく。この領域は、TID毎に1024個分の受信ステータスを確保する。1024は、ブロックACK期間内に連続して送信可能な最大MSDU(MAC Size Data Unit)数×１MSDUあたりのフラグメントフレーム最大数を掛けた値である。図２２のように、TXOP期間が終了するまでに、即時型ブロックACK用記憶領域に受信ステータスを格納している宛先からブロックACK要求が来れば、直ちにブロックACK応答を返信する。複数の宛先からのQoSデータが混ざることがないため、1宛先に対するブロックACKを作成する処理の負荷軽減が実現できる。

また、図２０の例のように、QSTA2がHCからブロックACK対象のQoSデータをバースト的に連続して受信している最中に、次のTXOP期間が始まり、他の宛先であるQSTA1からブロックACKのQoSデータの受信が開始されるような場合、図３２の即時型ブロックACK用記憶領域に余裕がないのであれば、そこに格納されているHC用の受信ステータス情報を、遅延型ブロックACK用記憶領域に移動し、新しい宛先(QSTA1)の受信ステータス情報を即時型ブロックACK用記憶領域に作成する。以後、古い宛先(図のHC)に対しては、遅延型ブロックACKでの応答を行なう。

以上のように、本実施形態によればBlock Ackの処理効率化が実現され、ブロックACK作成に関する受信機側での処理負荷を軽減することが可能である。

なお、EDCA時は自分が使用するチャネル使用期間を他の端末に伝えるために、RTS-CTSを用いるが、RTSフレーム内のデュレーション(回線使用期間)には、QoSデータ、ブロックACK要求、ブロックACKまでの一連のシーケンスが収まるように、TXOPの計算を行なう。

（第５の実施形態） ［3-1.EDCAにおけるフレームアグリゲーション］
EDCA(Enhanced Distributed Channel Access)は、優先度毎に複数のアクセスカテゴリ(AC: Access Category)を設け、それらが並列してキャリアセンス・バックオフ制御を行う。ACはそれぞれ独自のIFS(AIFS)期間を持ち、高優先度のACになるほど短い時間のキャリアセンスでフレームの送信開始を可能とする。MAC内部で複数のAC間の送信処理が同時に起こった場合は、優先度の高いACのフレームをPHYに送信し、低優先度のACはCW(コンテンションウィンドウ)を増やした後、再度ランダムなバックオフ待ち時間に入る。EDCAにおけるチャネルアクセスの様子を図３３に示す。また、図３４に表現するように、EDCAにおいて上位層からのデータは、IEEE802.1DのUser Priorityに従って、TID(Traffic Identifier)の0〜7番にマッピングされる。マッピングされたTIDは、ACに振り分けられる。その結果、ACには複数のTIDのMACフレームが蓄積されることになる。

EDCAにおいて、1つの物理フレームに複数のMPDUをアグリゲートする場合、通常、図３５に示すように1つの宛先、1つのTID毎に詰め込まれる。これは、EDCAが競合ベースのアクセス制御方式(Prioritized QoS)であるため、HCCAのような、トラフィックストリーム毎の品質を保証するものではないからである。すなわち、AC毎に用意されているメインキューの先頭からMACフレームを取り出し、そのフレームと宛先、TIDが等しいフレームを、アグリゲートすることになる。この場合、図３５から分かるように、1つの物理フレームにアグリゲート可能な最大MPDU数に満たないこともあり、チャネルの利用効率を最大限に活かしきれていないことも考えられる。

そこで、本実施形態においては、あるACが送信権利を得てデータフレームを送信する際、AC毎のメインキューの先頭からMACフレームを取り出し、1つの物理フレームにアグリゲート可能な最大数に満たない場合、もう片方のTID(EDCAではAC内に蓄積されるTIDの種類は2つと規定されている)のMACフレームをアグリゲートの対象にする。この時、AC毎のメインキューから取り出したMACフレームを、再送用に格納するサブキューをTID毎に用意することが望ましい。TID毎にサブキューを用意することで、スライディングウィンドウの制御をより簡単に行なうことができる。

図３４からも分かるように、同じAC内でもTIDによって優先度の違いがあるため、本実施形態では例えば図３６に示すように高い優先度のTID毎に区切ってフレームをアグリゲートする。OFDMにおけるチャネル推定(伝送路での位相と振幅の歪みをサブキャリア毎に推定すること)では、受信機に記憶された既知のプリアンブル信号を用いて実現する。パケットモードでの通信であり、かつパケット(フレーム)内での伝送路の時間変動が少ない無線ＬＡＮでは、パケット毎に独立してプリアンブル信号の先頭でチャネル推定を行う手法が一般的である。しかしアグリゲートしたフレームのようにフレーム長が大きくなると、伝送路が時間的に変動するため、フレームの後半部分になるほど、プリアンブル受信時に計算された推定結果が正確に反映されない場合がある（図３７）。そのため、高い優先度のMPDUを前方部分にアグリゲートすることで、優先度が高いTIDのデータフレームのエラー耐性を高める効果が得られる。

また、シーケンス番号はTID毎に連続して割り当てられているため、アグリゲートしたフレームを送信する無線通信装置は、受信側からの部分応答によって、TID毎にスライディングウィンドウ制御を行なう。

尚、これまでは同一AC内の複数のTIDのフレームをアグリゲートしていたが、あるAC内で他のTIDのMACフレームが存在せず、かつ衝突回避メカニズムの結果、内部で複数のAC間の送信タイミングが重なっていた場合、そのACよりも低い優先度のACのメインキューから、宛先が等しいMACフレームを取り出し、1つの物理フレームにアグリゲートしても良い。その場合、優先度の低いACは内部衝突が起こっているため、アグリゲートしたフレームの送信後は、コンテンションウィンドウを増加させてバックオフを取ることが望ましい。

以上のように、本実施形態によればEDCA時のフレームアグリゲーションの効果を高めることができる。

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

従来のキュー構成を示す図 ＨＣの装置構成（ＭＡＣ層）を示すブロック図 サブキューと複数優先度フレームを示す図 本発明の実施形態に係る優先度毎のサブキューを示す図 ＭＡＣスーパーフレームの作成を説明するための図 優先度の順番を予め認識している場合を示す図 優先度の順番が不定である場合を示す図 拡張したパーシャルＡＣＫフレームを示す図 ＣＲＣ誤りと優先度の判断について説明するための図 “ＴＩＤ Ｂｉｔｍａｐ”の追加を示す図 “ＴＩＤ Ｂｉｔｍａｐ”の使用例を示す図 “Ｂｉｔｍａｐ Ｉｎｆｏｒｍａｔｉｏｎ”フォーマットを示す図 Ｂｉｔｍａｐ Ｉｎｆｏｒｍａｔｉｏｎの活用を示す図 ＣＲＣ誤りと優先度の判断について説明するための図 優先度毎サブキューからのフレーム削除を示す図 本発明の実施形態に係る複数優先度毎のスライディングウィンドウ制御の一例を示す図 複数優先度毎のスライディングウィンドウ制御の他の例を示す図 受信側が優先度毎にバッファを持つ場合のスライディングウィンドウ制御の一例を示す図 受信側が優先度毎にバッファを持つ場合のスライディングウィンドウ制御の他の例を示す図 ブロックＡＣＫシーケンス（即時型）の例を示す図 遅延型ブロックＡＣＫシーケンスを示す図 本発明の実施形態に係るＴＸＯＰ内のブロックＡＣＫスケジューリングを説明するための図 ＴＸＯＰ内の複数優先度のスケジューリングを示す図 ＴＸＯＰ内の複数宛先のスケジューリングを示す図 最後のＱｏＳデータとブロックＡＣＫ要求の第１のアグリゲート例を示す図 ＱｏＳデータとブロックＡＣＫ要求の第１のアグリゲート例を示す図 ＱｏＳデータとブロックＡＣＫ要求の第２のアグリゲート例を示す図 ＱｏＳデータとブロックＡＣＫ要求の第３のアグリゲート例を示す図 最後のＱｏＳデータとブロックＡＣＫ要求の第２のアグリゲート例を示す図 最後のＱｏＳデータ、複数優先度のブロックＡＣＫ要求の第３のアグリゲート例を示す図 アグリゲーションによるブロックＡＣＫの効率化を説明するための図 即時型ブロックＡＣＫと遅延型ブロックＡＣＫ用の受信ステータス記憶領域を示す図 ＥＤＣＡにおけるチャネルアクセスの様子を示す図 ＡＣとＵｓｅｒ Ｐｒｉｏｒｉｔｙとのマッピングを示す図 ＥＤＣＡ時のフレームアグリゲーション時の問題を説明するための図 本発明の実施形態に係るＥＤＣＡ時の複数ＴＩＤのフレームアグリゲーションを示す図 高い優先度のＴＩＤ毎のアグリゲーションにおける、時間軸に沿ったチャネル推定精度を示す図

符号の説明

HC…QoSアクセスポイント(Hybrid Coordinator)、QSTA…QoS端末(QoS Station)

Claims (12)

1. 複数のＱｏＳデータがアグリゲートされた物理フレームを受信する受信部と、
   前記複数のＱｏＳデータの受信ステータスを表すビットマップを格納するための即時型用記憶領域と、
   前記複数のＱｏＳデータに対するブロックＡＣＫ要求を受信すると、前記即時型用記憶領域から前記ビットマップを読み出し、該ビットマップに基づく即時型ブロックＡＣＫを作成するとともに送信する制御部と、を具備する無線通信装置。
2. 前記ビットマップは、前記物理フレームにおいて前記複数のＱｏＳデータがアグリゲートされた順に対応して該複数のＱｏＳデータの各々の受信成否を表すビット列を含む請求項１記載の無線通信装置。
3. ＴＩＤ（Ｔｒａｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ）毎に前記即時型用記憶領域を複数備えることを特徴とする請求項１又は２記載の無線通信装置。
4. 前記受信部は、前記ブロックＡＣＫ要求の受信からＳＩＦＳが経過したときに前記即時型ブロックＡＣＫを送信することを特徴とする請求項１乃至３のいずれかに記載の無線通信装置。
5. 遅延型用の記憶領域をさらに具備し、
   前記受信部が前記ＱｏＳデータの受信中に、他の宛先からのＱｏＳデータを受信すると、
   前記制御部は、前記即時型用の記憶領域に保存しておいた受信ステータスを前記遅延型用の記憶領域に退避し、前記ブロックＡＣＫ要求に対するＡＣＫ応答を送った後、一定時間後に遅延型ブロックＡＣＫを送信する請求項１乃至４のいずれかに記載の無線通信装置。
6. 前記他の宛先からのＱｏＳデータの受信ステータスを前記即時型用の記憶領域に保存しておき、前記受信部が前記他の宛先からのブロックＡＣＫ要求を受信したときに、前記制御部は、前記他の宛先からのＱｏＳデータの受信ステータスを表すビットマップに基づく即時型ブロックＡＣＫを作成して送信する請求項５記載の無線通信装置。
7. 複数のＱｏＳデータがアグリゲートされた物理フレームを受信する受信ステップと、
   前記複数のＱｏＳデータの受信ステータスを表すビットマップを即時型用記憶領域に格納するステップと、
   前記複数のＱｏＳデータに対するブロックＡＣＫ要求を受信すると、前記即時型用記憶領域から前記ビットマップを読み出し、該ビットマップに基づく即時型ブロックＡＣＫを作成するとともに送信する送信ステップと、を有する無線通信方法。
8. 前記ビットマップは、前記物理フレームにおいて前記複数のＱｏＳデータがアグリゲートされた順に対応して該複数のＱｏＳデータの各々の受信成否を表すビット列を含む請求項７記載の無線通信方法。
9. ＴＩＤ（Ｔｒａｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ）毎の複数の即時型用記憶領域に、対応するＱｏＳデータの受信ステータスを表すビットマップを格納することを特徴とする請求項７又は８記載の無線通信方法。
10. 前記送信ステップにおいて、前記ブロックＡＣＫ要求の受信からＳＩＦＳが経過したときに前記即時型ブロックＡＣＫを送信することを特徴とする請求項７乃至９のいずれかに記載の無線通信方法。
11. 前記受信ステップにおける前記ＱｏＳデータの受信中に、他の宛先からのＱｏＳデータを受信すると、
    前記即時型用の記憶領域に保存しておいた受信ステータスを遅延型用の記憶領域に退避し、前記ブロックＡＣＫ要求に対するＡＣＫ応答を送った後、一定時間後に遅延型ブロックＡＣＫを送信する請求項７乃至１０のいずれかに記載の無線通信方法。
12. 前記他の宛先からのＱｏＳデータの受信ステータスを前記即時型用の記憶領域に保存しておき、前記他の宛先からのブロックＡＣＫ要求を受信したときに、前記他の宛先からのＱｏＳデータの受信ステータスを表すビットマップに基づく即時型ブロックＡＣＫを作成して送信する請求項１１記載の無線通信方法。

Images