(57)【要約】【課題】無線LAN 通信に際してIEEE802.11e に規定されているBlock Ack 機能を拡張した独自機能を使用し、効率のよいデータ通信を可能とし、データ量が多い映像データも効率よく伝送することを可能とする。【解決手段】無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、Block Ack フレームに含まれるBlock Ack Bitmapフィールドを作成する際、伝送データの内容に応じて適切なサイズを選択することによって映像データの伝送を可能とする。また、Block Ack プロトコルのシーケンスを見直し、より効率的な映像データの伝送を可能とする。【選択図】図１
2006217242.tif 000002
【特許請求の範囲】
【請求項１】
無線LAN 通信の規格IEEE802.11に準拠し、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、
前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドを作成する際、伝送データの内容に応じて適切なサイズを選択することによって映像データの伝送を可能とするステップを具備することを特徴とする無線通信方法。
【請求項２】
無線LAN 通信の規格IEEE802.11に準拠し、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、
前記Block Ack フレームとしてBlock Ack Bitmapフィールドを取り除いたBlock Ack フレームを作成し、解析するステップを具備することを特徴とする無線通信方法。
【請求項３】
無線LAN 通信の規格IEEE802.11に準拠し、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、
前記Block Ack フレームとしてBA Segment領域を追加したBlock Ack フレームを作成するステップを具備することを特徴とする無線通信方法。
【請求項４】
無線LAN 通信の規格IEEE802.11に準拠し、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信装置において、
前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドを作成する際、伝送データの内容に応じて適切なサイズを選択することによって映像データの伝送を可能とする手段を具備することを特徴とする無線通信装置。
【請求項５】
無線LAN 通信の規格IEEE802.11に準拠し、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信装置において、
前記Block Ack フレームとしてBA Segment領域を追加したBlock Ack フレームを作成する手段を具備することを特徴とする無線通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信方法および無線通信装置に係り、特に無線LAN 通信の規格IEEE802.11e におけるBlock Ack プロトコルのフレームフォーマットおよびプロトコルシーケンスに関するもので、無線データ通信に使用されるものである。
【背景技術】
【０００２】
無線LAN 通信とは、IEEE802.11で規定された通信制御用プロトコルに基づいた通信方式でデータ伝送を行う方式である。その規格内では、データ通信を行う際、送信相手に対してデータの受信確認を行う機能が含まれている。
【０００３】
IEEE802.11e （現時点ではドラフト段階）以前の規定では、無線LAN 通信は必ずDATAフレームの送達確認をフレーム単位で実施する必要があった。つまり、1 フレーム送信したら、その送信直後に送信したフレームに対する送達確認フレーム（Ack フレーム）を相手先端末から送信することになっていた。しかし、この方式では、データを受信する毎にAck フレームを送信しなければならず、Ack フレーム送信に伴う無線帯域占有率が非常に高くなってしまうという問題点が存在していた。
【０００４】
そこで、IEEE802.11e では、MAC(Media Access Control) 層プロトコル(Block Ackプロトコル) の複数のDATAフレームに対して、まとめて受信確認を行うことが可能なBlock Ack と呼ばれる機能（Block Ack メカニズム、Block Ack伝送方式）が導入された。
【０００５】
現時点で規定されているBlock Ack メカニズムは、送信側端末が送信したいフレームを連続して送信し、最後の送信フレームの直後に送達確認要求のフレーム（Block Ack Req フレーム）を送信する。受信側端末では、Block Ack Req フレームを受信した後、送達確認情報を含んだ送達確認フレーム（Block Ack フレーム）を返信する仕組みになっている。このBlock Ack Req フレーム内には、Starting Sequence Numberの領域（Block Ack Starting Sequence Control ）があり、受信側端末ではこのシーケンス番号以降の受信フレームに対して送達確認を実施し、その結果をBlock Ack フレーム内のBlock Ack Bitmap領域（フィールド）に格納して、送信側端末へ返信するようになっている。送信側端末ではそのビットマップデータ（Bitmap data）から受信端末側での受信確認情報を得ることができ、再送制御を行うことが可能となる。なお、このBlock Ack メカニズムの詳細については、本発明の実施形態において図１５および図１６を参照して後述する。
【０００６】
しかし、上記Block Ack Bitmapフィールドは128 バイトあり、一つのMPDU(MAC Protocol Data Unit)フレームに対して1 ビットが割り当てられている。よって、MPDU単位で1024フレーム分の送達確認情報を送信することが可能であり、これは一つのMSDU(MAC Service Data Unit) が16MPDUまで分割可能（フラグメント化可能）なことを考えると、64MSDUまでの受信確認情報を送信することが可能なことを表している。
【０００７】
しかし、上記Block Ack メカニズムには下記のような問題点が存在する。
【０００８】
（ａ）Block Ack フレーム内に含まれるデータの送達確認情報（ビットマップ）が128 バイトであり、Block Ack を利用して一度に送信するDATAフレーム数が少ない場合でも、常に128 バイトのビットマップを作成しなければいけない。
【０００９】
（ｂ）Block Ack フレーム内に含まれるデータの送達確認情報（ビットマップ）が固定長であるので、一度に送信するDATAフレーム数が動的に変化する場合であっても常に128バイトのビットマップを作成しなければいけない。
【００１０】
（ｃ）Block Ack フレーム内に含まれるデータの送達確認情報はMPDU単位で作成されているので、フラグメント化されていないデータを送信する場合でも常にMPDU情報を含めたビットマップを作成して送信しなければならない。
【００１１】
（ｄ）Block Ack フレーム内に含まれるデータの送達確認情報は、相手端末で判断した受信および未受信の情報を全てビットマップとして送信しなければならない。
【００１２】
（ｅ）Block Ack シーケンスはBlock Ack Req フレームやBlock Ack フレームの送信がプロトコル上で義務付けられており、場合によっては、非効率的な送信を余儀なくされることがある。
【００１３】
なお、IEEE802.11、IEEE802.11e の規格は、非特許文献１、２に記載されている。
【非特許文献１】IEEE802.11
【非特許文献２】IEEE802.11e
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明は前記した従来の問題点を解決すべくなされたもので、無線LAN 通信に際してIEEE802.11e に規定されているBlock Ack 機能を拡張した独自機能を使用し、効率のよいデータ通信が可能となり、データ量が多い映像データも効率よく伝送することが可能となる無線通信方法および無線通信装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の第１の実施態様の無線通信方法は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドを作成する際、伝送データの内容に応じて適切なサイズを選択することによって効率的な映像データの伝送を可能とするステップを具備する。
【００１６】
本発明の第２の実施態様の無線通信方法は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、前記Block Ack フレームとしてBlock Ack Bitmapフィールドを取り除いたBlock Ack フレームを作成し、解析するステップを具備する。
【００１７】
本発明の第３の実施態様の無線通信方法は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドのサイズを静的および動的に変更するステップを具備する。
【００１８】
本発明の第４の実施態様の無線通信方法は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、前記Block Ack フレームとしてBA Segment領域を追加したBlock Ack フレームを作成するステップを具備する。
【００１９】
本発明の第５の実施態様の無線通信方法は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法において、前記Block Ack Req フレームあるいは前記Block Ack フレームを送信しないで送達確認を行うステップを具備する。
【００２０】
本発明の第６の実施態様の無線通信装置は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信装置において、前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドを作成する際、伝送データの内容に応じて適切なサイズを選択することによって映像データの伝送を可能とする手段を具備する。
【００２１】
本発明の第７の実施態様の無線通信装置は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信装置において、前記Block Ack フレームとしてBlock Ack Bitmapフィールドを取り除いたBlock Ack フレームを作成し、解析する手段を具備する。
【００２２】
本発明の第８の実施態様の無線通信装置は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信装置において、前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドのサイズを静的および動的に変更する手段を具備する。
【００２３】
本発明の第９の実施態様の無線通信装置は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信装置において、前記Block Ack フレームとしてBA Segment領域を追加したBlock Ack フレームを作成する手段を具備する。
【００２４】
本発明の第１０の実施態様の無線通信装置は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信装置において、前記Block Ack Req フレームあるいは前記Block Ack フレームを送信しないで送達確認を行う手段を具備する。
【発明の効果】
【００２５】
本発明の無線通信方法および無線通信装置によれば、無線LAN 通信に際してIEEE802.11e に規定されているデータ伝送を効率よく行うためのBlock Ack 機能を拡張した独自機能を使用することにより、効率のよいデータ通信を実施でき、さらにデータ量が多い映像データを効率良く伝送することもできる。
【発明を実施するための最良の形態】
【００２６】
本発明は、図１５および図１６に示したBlock Ack BitmapサイズやBlock Ack フレーム、Block Ack Req フレームのフレームフォーマットの変更、そしてBlock Ack のプロトコルシーケンスを変更することにより、より効率的に送達確認を実施しようというものである。
【００２７】
本発明を説明する前に、まず、IEEE802.11e で規定されているBlock Ack のメカニズムについて詳細に説明する。
【００２８】
図１５は、IEEE802.11e で規定されているBlock Ack Req フレームのフレームフォーマット（フィールドおよびサイズ）を示す。図１６は、IEEE802.11e で規定されているBlock Ack フレームのフレームフォーマットを示す。図１５および図１６において、各フィールドの詳細は下記の通りであり、各フィールドのカッコ内の数字はバイト数を表す。
【００２９】
Frame Control：フレーム制御情報
Duration/ID：送信禁止時間、またはPower Saveモード時のAID
RA：Receiver Address (受信端末のMAC アドレス)
TA：Transmitter Address ( 送信端末のMAC アドレス)
BAR Control     bit 0-11：Reserved
bit 12-15：TID
Block Ack Starting Sequence Number
bit 0-3：フラグメント番号
bit 4-15：Starting Sequence Number
（送達確認を実施したいフレームのうち一番シーケンス番号の小さいフレームを指定）
Block Ack Bitmap: 64MSDU(MAC Service Data Unit) 分の送達確認用ビットマップ
FCS：Frame Check Sequence （32bit-CRC によりフレームの誤り検出を行う）
IEEE802.11e で現在規定されているBlock Ack のメカニズムは、送信側端末が送信したいフレームを連続して送信し、最後の送信フレームの直後に送達確認要求のフレーム（Block Ack Req フレーム）を送信する。受信側端末では、Block Ack Req フレームを受信した後、送達確認情報を含んだ送達確認フレーム（Block Ack フレーム）を返信する仕組みになっている。このBlock Ack Req フレーム内には、Starting Sequence Numberの領域（Block Ack Starting Sequence Control ）があり、受信側端末ではこのシーケンス番号以降の受信フレームに対して送達確認を実施し、その結果をBlock Ack フレーム内のBlock Ack Bitmap領域（フィールド）に格納して、送信側端末へ返信するようになっている。送信側端末ではそのビットマップデータから受信端末側での受信確認情報を得ることができ、再送制御を行うことが可能となる。
【００３０】
以下、図面を参照して本発明の実施形態を説明する。この説明に際して、全図にわたり共通する部分には共通する参照符号を付す。
【００３１】
＜第１の実施形態＞
図１は、本発明の無線通信装置の第１の実施形態に係る無線LAN機器のベースバンド部を搭載した半導体チップのハードウェア構成の一例を示すブロック図である。
【００３２】
図１に示す半導体チップ１０において、システムバス１１には、ＣＰＵ（中央演算処理装置）１２、外部Ｉ／Ｆ（インターフェース）制御部１３、ＭＡＣ処理部１４、メモリ制御部１５が接続されている。ＭＡＣ処理部１４には、ＰＨＹ（物理層）処理部１６が接続されている。メモリ制御部１５には、内部メモリ１７が接続されており、必要に応じてチップ外部の外部メモリ１８が接続される。なお、メモリ制御部１５には、外部メモリ１８のみが接続される場合もある。
【００３３】
図２は、図１中のベースバンド部を制御するためのソフトウェア構成の一例を示すブロック図である。図１中のメモリ部に格納されるファームウェア（ＦＷ）２０として、データ伝送処理部２１と、プロトコル処理部２２と、ホストＩ／Ｆ処理部２３と、ハードウェア（ＨＷ）ドライバ２４を有する。ホストＩ／Ｆ処理部２３は、ホストドライバ２５を介して上位アプリケーション２６とデータのやり取りを行う。
【００３４】
図３および図４は、本発明の第１の実施形態の無線通信方法および無線通信装置で採用するIEEE802.11e 準拠のBlock Ack フレームのフレームフォーマット（フィールドおよびサイズ）の第１の例および第２の例を示す。
【００３５】
図３および図４に示すフレームにおいて、Frame Control フィールドは２バイト、Duration ID フィールドは２バイト、RAフィールドは６バイト、TAフィールドは６バイトである。これらの各フィールドは、MAC header部を構成している。BA Controlフィールドは２バイト、Block Ack Starting Sequence Control フィールドは２バイト、Block Ack Bitmapフィールドは８バイトあるいは２バイト、FCS フィールドは４バイトである。
【００３６】
即ち、図３に示すフレームは、図１６を参照して前述したBlock Ack フレームと比べて、Block Ack Bitmapサイズを128 バイトから８バイトに変更した点が異なる。また、図４に示すフレームは、図１６を参照して前述したBlock Ack フレームと比べて、Block Ack Bitmapサイズを128 バイトから２バイトに変更した点が異なる。
【００３７】
図７は、本発明の無線通信方法の第１の実施形態で採用するBlock Ack Req フレームのフレームフォーマットを示す。
【００３８】
図７に示すフレームにおいて、Frame Control フィールドは２バイト、Duration ID フィールドは２バイト、RAフィールドは６バイト、TAフィールドは６バイトである。これらの各フィールドは、MAC header部を構成している。BAR Control フィールドは２バイト、Block Ack Starting Sequence Control フィールドは２バイト、FCS フィールドは４バイトである。即ち、図７に示すフレームは、図１５を参照して前述したBlock Ack フレームと同様である。
【００３９】
表１は、本発明で採用するIEEE802.11e 準拠のBlock Ack Req フレーム内およびBlock Ack フレーム内のBA ControlフィールドおよびBA Segment Size フィールドの内容の一例を詳細に示している。表１に示したような値を取ることにより、IEEE802.11e で規定されている既存のBlock Ack フレームと併用しても互換性が保たれることになる。
【表１】
2006217242.tif 000003
【００４０】
次に、図３あるいは図４のBlock Ack フレームを使用する方式について表１を参照しながら説明する。
【００４１】
第１の実施形態においては、Block Ack フレームのBlock Ack Bitmap内の1 ビットを1MSDU 単位の送達確認情報に割り当てることにより、Block Ack Bitmapサイズを８バイトにまで短縮する。また、映像データ伝送時に必要十分な16MSDU分の送達確認情報を送信するためには、Block Ack Bitmapサイズを２バイトにまで短縮する。
【００４２】
ここで、IEEE802.11で規定されている無線LAN フレームのFrame Bodyサイズ(MAC PDU)は0-2304バイトとなっており、現在一般的に広く使用されているイーサネット（登録商標）通信のFrame Bodyサイズ(1500 バイト) と比較しても十分大きいものである。つまり、現時点で製品として多く市場に出回っているイーサポート付きの無線LAN 装置の場合、イーサネット（登録商標）フレームから無線LAN フレームへの変換等はMPDUへフラグメント化することなしに、そのままMSDUとして送信することが可能である。また、上位アプリケーションから無線LAN フレームへマッピングする場合も、Frame Bodyサイズの最大が2304バイトという大きさを考慮すればフラグメント化することなしに送信できる可能性が高い。
【００４３】
そして、図３のBlock Ack(8) フレームを使用することにより、MPDU単位での送達確認からMSDU単位での送達確認を実施し、それに伴いBlock Ackのフレームサイズを縮小することが可能となる。また、図４のBlock Ack(2) フレームを使用することにより、映像ストリーム伝送時に最適なBlock Ack フレームを作成することが可能となる。
【００４４】
上記した第１の実施形態は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質(Quality of Service;QoS)優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack （ブロックアクノレッジ）機能を使用する無線通信方法（無線通信装置）において、Block Ack フレームに含まれるBlock Ack Bitmapフィールドを作成する際、伝送データの内容に応じて適切なサイズを選択することによって映像データの伝送を可能とするステップ（手段）を具備することを特徴とするものである。
【００４５】
上記構成によれば、図３および図４に示したようにビットマップを８バイトや２バイトに短縮することにより、ビットマップサイズを従来例の1/16、1/64にまで縮小することが可能となる。ここで、前記８バイトは既存の128 バイト時に定義されていた送達確認MSDUサイズ(64MSDU 分) を確保し、かつ、フラグメント化部分の送達確認情報(MPDU 部分の送達確認情報) を省いたものである。また、前記２バイトは、映像伝送データのようなストリーミングデータを送信する時に最適なビットマップサイズであり、特に、高精細ＴＶ画像データの送信時に適用して有効である。
【００４６】
このようにビットマップサイズを縮小することにより、余分なビットマップ作成処理の削除や、無線帯域の効率化（有効利用）を図ることが可能となり、効率のよい無線通信を実施することが可能となり、映像データのようなデータ量が多いために広帯域が必要なデータ通信であっても、不要な無線帯域の使用を避けて伝送することが可能となる。
【００４７】
なお、第１の実施形態を適用する送信端末／受信端末の組み合わせの具体例としては、無線LAN ステーション(AP)／無線LAN 端末(STA) とかSTA ／STA である。また、各端末の構成は高周波(RF)部やアナログ／デジタル変換部とコントローラ部などに大別して形成される。各端末を半導体チップで構成する場合、コントローラ部はＣＰＵとプログラムとを内蔵してソフトウェア的に実現することによって１チップ化でき、また、高周波(RF)部やアナログ／デジタル変換部とコントローラ部とを分離して２チップ化することもできる。
【００４８】
＜第２の実施形態＞
図５は、本発明の第２の実施形態の無線通信方法および無線通信装置で採用するBlock Ack フレームのフレームフォーマットを示す。
【００４９】
図５に示すフレームは、図３あるいは図４を参照して前述したBlock Ack フレームと比べて、Block Ack Bitmapサイズを０バイトに変更した（Block Ack Bitmapを削除した）点が異なる。
【００５０】
次に、図５のBlock Ack フレームを使用する方式について表１を参照しながら説明する。通常、Block Ack Req フレームを受信した端末は、自身が受信したフレーム情報に基づいてBlock Ack Bitmapを作成し、それをBlock Ack フレームとして送信側端末へ送信することになる。送信側端末は、受信側端末から送信されてきたBlock Ack フレーム内のビットマップ情報に基づいてフレーム送達確認を行い、必要に応じて再送することになる。この処理をより簡略化するために、ビットマップサイズが0 のフレーム（削除されたフレーム) を導入する。
【００５１】
受信側端末において、もし全フレームを正常に受信した場合は、Block Ack Bitmapを作成せずに（0 バイトとして）送信側端末へ送信する。送信側端末では、Block Ack Bitmapが含まれていないBlock Ack フレームを受信した場合には、受信側端末が全フレームを正常に受信したと判断することが可能となり、ビットマップを作成しなくても送達確認を行うことが可能となる。
【００５２】
また、本フレームに関しては、全フレームを正常に受信できなかった場合においても同様に適用することができる。Block Ack Bitmapが削除されているフレームを受信した場合に、全フレームとも正常受信と判断するか、全フレームとも未受信と判断するかは、BA Control領域のビットを利用して設定する。また、この判断の仕方を予め双方の端末間で決定しておくモードも存在する。
【００５３】
即ち、図５のBlock Ack(0) フレームを使用することにより、受信端末側での全受信確認又は全未受信確認を行うことを可能にし、かつ、Block Ackフレームを短くすることで無線帯域を有効活用することができる。
【００５４】
上記した第２の実施形態は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成してBlock Ack 機能を使用する無線通信方法（無線通信装置）において、Block Ack フレームとしてBlock Ack Bitmapフィールドを取り除いたBlock Ack フレームを作成し、解析するステップ（手段）を具備することを特徴とするものである。
【００５５】
上記構成によれば、ビットマップサイズを0 バイトにすることにより無線帯域を効率よく利用することが可能となる。また、不要なビットマップ作成処理やフレーム生成処理を実施する必要がなくなり、端末内部での処理を高速化できる。換言すれば、無線通信装置の内部処理の効率化、パフォーマンスの向上、低消費電力化が可能になる。
【００５６】
＜第３の実施形態＞
図６は、本発明の無線通信方法および無線通信装置の第３の実施形態で採用するBA Segment可変長方式のBlock Ack フレームのフレームフォーマットを示す。
【００５７】
図６に示すBlock Ack(n)フレームは、図３あるいは図４を参照して前述したBlock Ackフレームと比べて、Block Ack Bitmapサイズを可変長（ｎバイト）に変更した点が異なり、その他は同じである。
【００５８】
次に、図６のBlock Ack(n)フレームを使用する方式について表１を参照しながら説明する。
【００５９】
送信端末側は、通常のBlock Ack Req フレームを送信する。受信端末側では、Block Ack Req フレームを受信後、受信したBlock Ack Req フレーム内に格納されているBlock Ack Starting Sequence Control から最後に受信したDATAフレームのシーケンス番号（Sequence Number ）までのビットマップを作成する。ビットマップサイズは、作成しなければいけないフレーム数から８フレーム毎の切り上げとすることにより、バイト単位でのビットマップ作成処理を行う。また、ビットマップサイズは、静的にも、動的にも可変にすることが可能である。静的に可変長とする場合は、予めビットマップサイズを両端末間で決定しておくか、または、Block Ack Req フレーム内のBA Controlフィールドを利用して相手端末に通知する。更に、動的に可変長とする場合は、Block Ack Req フレーム内のBAR Control フィールドを使用して通知する方法、Block Ack フレームのBA Controlフィールドを使用して通知する方法、および特に何も指定しない方法が考えられる。特に何も指定しない方法の場合は、Block Ack フレーム受信側で、Block Ack フレームサイズからBlock Ack Bitmapサイズを割り出すことにより可能となる。
【００６０】
即ち、図６のBlock Ack(n) フレームを使用することにより、一回のBlock Ack メカニズムで送信するフレーム数を変更するような場合でも、その都度、受信フレーム数に応じて適切な長さのビットマップを構築することができ、それに伴い無線帯域を有効活用することが可能となる。
【００６１】
上記した第３の実施形態は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成してBlock Ack 機能を使用する無線通信方法（無線通信装置）において、Block Ack フレームに含まれるBlock Ack Bitmapフィールドのサイズを静的および動的に変更するステップ（手段）を具備することを特徴とするものである。
【００６２】
上記構成によれば、ビットマップサイズを可変長とすることにより、DATAフレーム数に応じた柔軟な制御が可能となり、無線帯域を効率よく利用することが可能となる。また、不要なビットマップ作成処理を実施する必要がなくなり、端末内部での処理の効率化を図ることができる。
【００６３】
なお、上記したBlock Ack Bitmapサイズを可変長にした場合の具体例について、表２、表３、図１０、図１１を参照して説明する。
【００６４】
表２は、送信端末側の送信済みフレームシーケンス番号管理テーブルの一例を示す。
【表２】
2006217242.tif 000004
【００６５】
表２に示す例では最初に端末(00-00-00-00-00-01) 宛てに0x100 のシーケンス番号を持ったフレームを送信し、その後順に0x108 のシーケンス番号を持ったフレームまでを送信している。
【００６６】
図１０は、表２に示したフレームシーケンス番号管理テーブルを例にとった場合のBlock Ack Req フレームを示す。
【００６７】
表２では宛先端末(00-00-00-00-00-01) 宛てに0x100 のシーケンス番号を持ったフレームから送信しているので、図１０に示すようにフレームが送信されることになる。
【００６８】
表３は、受信側端末の受信済みフレームシーケンス番号管理テーブルの一例を示す。
【表３】
2006217242.tif 000005
【００６９】
表３に示す例では最初に端末(00-00-00-00-00-02) から0x100 のシーケンス番号を持ったフレームを受信し、その後、順に0x106 のシーケンス番号を持ったフレームまでを受信している。しかし、一部のフレームに関してはフレームロスが発生しており、シーケンス番号が連続していない様子が分かる。
【００７０】
図１１は、表３に示したフレームシーケンス番号管理テーブルを例にとった場合のBlock Ack(n)フレームを示す。
【００７１】
表３では宛先端末(00-00-00-00-00-02) から図１０のBlock Ack Req フレームを受信している。Block Ack Starting Sequence Control(Starting Sequence Number) として0x100 を指定してきているので、0x100 から受信した全てのフレームに関する情報を通知する。最後に受信したフレームのシーケンス番号が0x106 と分かるので、ビットマップサイズは７ビット分あればよい。よって、ビットマップサイズは８ビット単位で切り上げて1 バイト分作成する。フレーム受信判定ビットは、IEEE802.11e 規格に準じて、1 を受信、0 を未受信とする。
【００７２】
＜第４の実施形態＞
図８は、本発明の無線通信方法および無線通信装置の第４の実施形態で採用するBlock Ack 情報を多重化（ｍ重化）したBA Segment可変長方式のBlock Ack フレームのフレームフォーマットを示す。
【００７３】
図９は、図８においてｍ＝３の場合のBA Segment可変長方式のBlock Ack フレームのフレームフォーマットを示す。
【００７４】
図８に示すm-Extended Block Ack(n) フレームは、図６を参照して前述したBlock Ackフレームと比べて、BA Segment Size フィールドとBlock Ack Starting Sequence Control フィールドとBlock Ack BitmapフィールドとからなるBA segmentを多重化した点が異なり、その他は同じである。
【００７５】
即ち、図８に示すm-Extended Block Ack(n) フレームにおいて、Frame Control フィールドは２バイト、Duration ID フィールドは２バイト、RAフィールドは６バイト、TAフィールドは６バイトである。これらの各フィールドは、MAC header部を構成している。
【００７６】
図９に示す3-Extended Block Ack(n) Block Ack フレームおいて、BA Segmentは、BA Segment-1、BA Segment-2、BA Segment-3に三重化されており、FCS フィールドは４バイトである。
【００７７】
ここで、BA Segment-1は、BA Controlフィールドが２バイト、Block Ack Starting Sequence Control フィールドが２バイト、Block Ack Bitmapフィールドが１バイトである。BA Segment-2は、BA Controlフィールドが２バイト、Block Ack Starting Sequence Control フィールドが２バイト、Block Ack Bitmapフィールドが２バイトである。BA Segment-3は、BA Controlフィールドが２バイト、Block Ack Starting Sequence Control フィールドが２バイト、Block Ack Bitmapフィールドが３バイトである。
【００７８】
次に、図８のm-Extended Block Ack(n) フレームを使用する方式について表１を参照しながら説明する。
【００７９】
（概要）前記第３の実施形態と同様に、Block Ack Bitmapを作成する際に、必要なビット数（Block Ack Bitmap作成に必要なフレーム数）を計算し、それを８ビット単位で切り上げることにより必要最小限のBlock Ack Bitmapをバイト単位で作成する。この時、図８に示したように、Block Ack Starting Sequence  Controlのサイズ（２バイト）とBlock Ack Bitmapのサイズの合計値をBA Segment Size フィールドに格納する。このBA Segment Size フィールドは、BA Segmentを多重化した場合に、各々のBlock Ack Bitmapサイズを判断するために使用される。BA Segmentを多重化しない場合でも、Extended Block Ack(n) モードを使用する場合は、BA Segment Size フィールドが必要となる。
【００８０】
（ビットマップ作成方法）
Block Ack Req フレームを受信した場合。ここで、BA Controlが例えば、BA Type: Extended BA、BA Policy-1: Received Info、BA Policy-2: Normal であると仮定する。
【００８１】
Block Ack Req フレームで要求されたBlock Ack Starting Sequence Numberからビットマップテーブル作成対象となるフレームまでの受信確認状況を見ていく。まず、初めに、要求されたシーケンス番号から1 バイト分（８フレーム分）のビットマップを作成する。次に、２バイト目以降は、連続して16フレーム分（２バイト）以上、未受信フレームが存在した場合は、BA Segmentを一旦終了する。もし、16フレーム以内に受信しているフレームが1 フレームでも存在した場合は、同一のBA Segment領域にビットマップを作成する。
【００８２】
二つ目以降のBA Segmentは、受信フレームが見つかるまでシーケンス番号を検索する。受信フレームを見つけた場合は、そこから１バイト分（８フレーム分）の受信確認を実施してビットマップを作成する。そして、さらにその次の1 バイト分（つまり、最初の受信確認フレームから数えて9 フレーム目から15フレーム目まで）で受信しているフレームが存在していた場合、先程のビットマップを拡張してそのまま作成する。もし、受信フレームが存在していなかった場合は、さらに次の1 バイト分（つまり、16フレーム目から23フレーム目まで）の受信フレームを確認する。もし、受信フレームが存在していた場合は、先程のビットマップを拡張して受信確認を行う。もし、受信フレームが存在していなかった場合は、先程のビットマップの作成を終了する。つまり、最初に作成したビットマップの最後の受信フレームの次のフレーム（９フレーム目）の情報から、２バイト分以上（23フレーム目以上）受信フレームが存在しない場合は、ビットマップの作成を一旦終了し、再度受信フレームを探し始める。受信フレームが見つかった場合は、そこから上記と同様の手順で新しいビットマップ作成を試みる。
【００８３】
また、フラグメント化されているフレームの場合(MPDU の場合) は、MSDU単位でBA Segmentを構築することにより対応可能となる。
【００８４】
さらに、このBA Segmentを多重化することにより、BA Starting Sequence Controlフィールドのフラグメント情報から、MSDU単位での送達確認情報とMPDU単位での送達確認情報の両方を一つのBlock Ack フレームに挿入して送信することが可能となる。
【００８５】
なお、上記したBA Segmentを利用したBlock Ack Bitmap作成方法の具体例について、表４、図１２を参照して説明する。なお、この場合、Block Ack Req フレームは図１０と同じフレームとする。
【００８６】
表４は、ビットマップ作成対象フレームである送信側端末(MACアドレス：00-00-00-00-00-02)の送信済みフレームおよび受信側端末(MACアドレス：00-00-00-00-00-01)の受信済みフレームのそれぞれのシーケンス番号管理テーブルの一例を示す。
【表４】
2006217242.tif 000006
【００８７】
表４に示す例では、送信側端末から送信されたフレームが、受信側で受信できたかどうかを分かり易く並べて表示している。×印が未受信フレームを表す。また、ビットマップの作成対象フレームも示している。ビットマップ作成対象はBlock Ack Req フレーム内のStating Sequence Number が0x100 を指しているものとしている。まず始めに、0x100-0x107のフレーム(1バイト分) が１つ目のビットマップとして作成される。また、次の１バイト分(0x108-0x10f) にも受信フレームが存在しているので続けてビットマップを作成する。次のフレーム(0x110のフレーム) からは16フレーム以上受信フレームが存在しないので、一つ目のビットマップは0 x100-0x10fのフレーム分の受信情報となる。次の受信フレームは0x123 なので、今度はその位置からビットマップを作成することにする。送信側端末は0x12f までのフレームを送信しているが、受信側で最後に受信したフレームは0x126 なので、最後のビットマップは１バイト分の受信情報となる。
【００８８】
図１２は、表４に示したシーケンス番号管理テーブルを例にとった場合のm-Extended Block Ackフレームの一例として、m=２の場合を示す。
【００８９】
このm-Extended Block Ackフレームでは、一つ目のBlock Ack Bitmapは0x100 のシーケンス番号から1 バイト分作成し、次のBlock Ack Bitmapは0x119 から1 バイト分作成する。BA  SizeはいずれもBlock Ack Starting Sequence Control(2 バイト) とBlock Ack Bitmap(1バイト) を合計して3 バイトとなる。また、この例ではBlock Ack Bitmapが2 多重になっているが受信フレームのシーケンス番号によってはm 多重( m は整数) となる。
【００９０】
（送達確認方法：その１）
Block Ack Req フレームのBA Controlが例えば、BA Type: Extended BA、BA Policy-1: Received Info、BA Policy-2: Normal であると仮定して送達確認方法を説明する。
【００９１】
送信側端末では、受信したBlock Ack フレームから受信側端末で受信したフレーム情報を知ることができる。また、ビットマップの多重化によりBA Segment毎のSequence Number からフレームロスの情報も読み取ることができる。これは、一つ目のBA Segmentのシーケンス番号が0x00から始まり、かつ、Block Ack Bitmapサイズが２バイト（16フレーム）であり、二つ目のBA Segmentのシーケンス番号が0x20だった場合は、16フレーム分のBA Segment情報が存在しないことになる(0x20 - (0x00 + 0x0f))。これは、シーケンス番号が0x10-0x20 のフレームを正常に受信することができなかったことを意味している。
【００９２】
（送達確認方法：その２）
Block Ack Req フレームのBA Controlが例えば、BA Type: Extended BA、BA Policy-1: Un-Received Info 、BA Policy-2: Normal であると仮定して送達確認方法を説明する。  送信側端末では、受信したBlock Ack フレームから受信側端末で受信できなかったフレーム情報を知ることができる。また、ビットマップの多重化によりBA Segment毎のSequence Number から正常に受信したフレームの情報を読み取ることもできる。
【００９３】
なお、上記したBA Policy の多重化を利用したBlock Ack Bitmap作成方法の具体例については、図７、図８を参照して前述した通りである。
【００９４】
（ビットマップの多重数）
ビットマップの多重は、BA Segment単位で行うことができる。多重数は、無線LAN フレームの最大フレーム長内に収まる範囲で可能とする。
【００９５】
上記した第４の実施形態は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成してブロックアクノレッジ(Block Ack) 機能を使用する無線通信方法（無線通信装置）において、Block Ack フレームとしてBA Segment領域を追加した（取り入れた）Block Ack フレームを作成するステップ（手段）を具備することを特徴とするものである。
【００９６】
上記構成によれば、BA Segmentを導入してBlock Ack Bitmapを多重化した場合と第３の実施形態で説明したBlock Ack Bitmapサイズが可変長の場合とで大きく異なる点は、シーケンス番号が連続したフレームを受信できなかった場合等で、その途中のBlock Ack Bitmap作成を省略することができること、MSDUやMPDUといった区別をすることなく、一つのBlock Ack フレームを共通で使用できることである。
【００９７】
無線通信の場合には、連続してフレームロスが発生するようなバーストエラーが多発することが予想される。そのような場合においても、受信フレーム、または未受信フレームに対してBA Segmentを多重化してBlock Ack フレームを送信することにより、効率よく送達確認を実施することが可能となる。
【００９８】
また、フラグメント化されたフレームを対象にした場合、現状だと128 バイトものビットマップを作成する必要があるが、上記実施形態のBlock Ack フレームを使用することにより、最小で1 バイト（BA Segment Size を含めても３バイト）のBlock Ack Bitmapを作成すればよいことになり、効率のよい無線通信を行うことが可能となる。
【００９９】
また、さらに本フレームの特徴として、BA ControlおよびBAR Control フィールドを使用することにより、既存のBlock Ack Req フレームおよびBlock Ack フレームを拡張する形式を採用しているので、互換性を保つことができる。
【０１００】
＜第５の実施形態＞
図１３は、IEEE802.11e で規定されている二種類のBlock Ack モード(Immediate ModeおよびDelayed Mode) のシーケンス図を示す。
【０１０１】
Immediate ModeとDelayed Modeの主な違いは、Block Ack Req フレームの受信後にAck 送信を行うか否かである（このAck 送信は、Block Ack Req フレームの受信に対する応答であり、DATAフレームの受信に対する応答ではない）。
【０１０２】
ここで、図１３に示したシーケンスを簡単に説明する。送信端末は、受信端末に向けてDATAフレームを連続送信する。受信端末は、各DATAフレームの受信に対するAck フレームを送信せずに、送信端末からのDATAフレームを連続受信する。送信端末は、DATAフレームを送信後、Block Ack Req フレームを受信端末に送信する。受信端末は、Block Ack Reqフレームを受信後、作成したビットマップをBlock Ack フレームに格納して送信端末に送信する。送信端末は、受信端末からのビットマップ情報に基づいて、同一のDATAフレームを再送するか否かを判断する。
【０１０３】
図１４は、本発明の無線通信方法および無線通信装置の第５の実施形態で採用するIEEE802.11e の拡張版（図１３に示したBlock Ack シーケンスを改良し、伝送効率を高めたもの）のシーケンス図を示す。ここでは、Block Ack Req フレームの送信を停止するモード(no-Block Ack Req mode) と、Block Ack フレームの送信を停止するモード(no-Block Ack mode) の二種類を使用する場合を示している。
【０１０４】
なお、第５の実施形態は、IEEE802.11e で規格化されている二種類のBlock Ack モード(Immediate Mode およびDelayed Mode) のうち、どちらに対しても適用可能である。
【０１０５】
次に、図１４に示したシーケンスを使用する方式について概要を説明する。
【０１０６】
送信端末側は、送信データが無くなるまで、または、TXOP期間が無くなるまで、連続してDATAフレームを送信することが可能である。送信端末側で、no-Block Ack Reqモードを利用していた場合、送信端末側では、DATAフレーム送信後にBlock Ack Req フレームを送信せずに終了する。
【０１０７】
受信端末側は、送信端末側からの受信終了をTXOPの終了や自分宛へのフレームが一定期間未受信になったことにより知ることが可能である。受信端末側でno-Block Ackモードを利用していた場合、送信モードによりBlock Ack フレームの送信の有無を判断する。
【０１０８】
いま、Block Ack Req フレームのBA Controlが例えば、BA Type: Dynamic BA 、BA Policy-1:Received Info 、BA Policy-2:no-Block Ackであると仮定して説明する。
【０１０９】
この場合、もし正常に受信しているフレームが存在していたら、Block Ack フレームの生成を行って送信するが、もし、フレームロスが発生していたら、Block Ack フレームを送信しない。この時、Block Ack Bitmap作成のためのStarting Sequence Numberが必要となるが、これは受信側端末で自由に決めることができる。通常は、最初に受信したフレームのシーケンス番号からBlock Ack Bitmapを作成することになる。また、もし、no-Block Ack モードを利用していなかったら、受信端末側では必ずBlock Ack フレームを送信することになる。送信側端末では、Block Ack フレームを受信したら、ビットマップ情報を解析し、再送制御を実施するかどうかを判断する。
【０１１０】
なお、ビットマップの作成方法やBlock Ack のフレームに関しては、本発明で提案しているいずれの方法であっても対応可能である。
【０１１１】
上記した第５の実施形態は、無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成してブロックアクノレッジ(Block Ack) 機能を使用する無線通信方法（無線通信装置）において、Block Ack Req フレームあるいは前記Block Ack フレームを送信しないで送達確認を行うステップ（手段）を具備することを特徴とするものである。
【０１１２】
上記構成によれば、no-Block Ack Reqモードやno-Block Ack モードを導入することにより、無線帯域を効率よく利用することが可能となり、無線伝搬路の悪化時における再送手順の効率化を図ることができる。
【０１１３】
また、実装面においても、Block Ack Req フレームやBlock Ack フレームを生成する必要がないので、端末内部での処理の効率化を図ることができる。また、殆んどフレームロスが発生しないような環境の場合、no-Block Ack Reqおよびno-Block Ackモードを採用し、定期的に受信端末側からBlock Ack フレームをUn-Received モードで送信すれば、Block Ack Req フレームを送信することなく、かつ、Block Ack Bitmapを作成することなく送達確認を行うことが可能となる。
【０１１４】
次に、図１４に示したシーケンスを使用する方式について詳細に説明する。
【０１１５】
（no-Block Ack Reqメカニズム）
Block Ack メカニズムを使用すると、受信端末側では連続してDATAフレームを受信する。受信端末側はDATAフレーム受信中あるいはDATAフレーム受信後にビットマップを作成し、それをBlock Ack フレームにマッピングして送信端末側へ送信する。この際、ビットマップを作成するためにStarting Sequence Numberを決定する必要がある。通常のBlock Ackシーケンスの場合は、Block Ack Req フレーム内のBlock Ack Starting Sequence Numberを使用するが、本実施形態におけるno-Block Ack Reqメカニズムの場合、受信側端末で独自に決定できるものとする。通常は、最初に受信したシーケンス番号や、最初にフレームロスしたシーケンス番号になる。また、受信側端末では、上位アプリケーション等にデータを送信するために、受信バッファを早く開放したいことがある。その場合は、Block Ack のシーケンス番号としてバッファ解放を行うシーケンス番号を通知することも可能である。この通知に関しては、BA Controlフィールドを使用することにより通知可能である。また、受信端末側からのBlock Ack の送信は、自端末のバッファ解放タイミング、送信側へのフレーム送信要求時、TXOP期間終了時、SI(Service Interval)終了時、ある一定時間経過後のタイミングで、相手のバッファサイズを越えない量等を勘案して行う。
【０１１６】
（no-Block Ack メカニズム）
受信側端末では、全フレーム正常受信時または全フレーム未受信時には、Block Ack フレームを送信しないようにする。そのどちらのモードを使用するのかは、予め、両端末間で決定しておくか、または、BA Controlフィールドを利用して通知する。BA Controlフィールドで通知する場合は、Block Ack フレーム送信後に受信するAck フレームにより、相手へのBA Controlフィールド情報の通知を確認する。また、Block Ack フレームを送信しない場合は、DATAフレーム送信側のバッファ解放タイミングを見付ける必要がある。この解放は、前記no-Block Ack Reqメカニズムと同様のタイミングで、TXOP単位、SI(Service Interval)単位、ある一定周期単位、占有バッファ量に応じた単位等を勘案して行う。また、バッファ解放のためにBlock Ack Req フレームを送信することにより、Block Ackフレームを要求することや、あるいは、強制的に解放したことを、Block Ack Req フレームを送信することで通知することも可能とする。
【０１１７】
上記した第５の実施形態の方法は、前記した各実施形態で説明したビットマップの作成方法やBlock Ack フレームの作成方法等、いずれの方法と組み合わせて使用することも可能である。
【０１１８】
以上説明した本発明の実施形態を整理する。
【０１１９】
（１）無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質(Quality of Service;QoS)優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法（無線通信装置）において、前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドを作成する際、伝送データの内容に応じて適切なサイズを選択することによって映像データの伝送を可能とするステップ（手段）を具備する。
【０１２０】
（1a）前記（１）の無線通信方法（無線通信装置）において、前記Block Ack Bitmapを作成する際、フレームのフラグメントを考慮せずにMSDU単位で送達確認を実施したBlock Ack Bitmapを作成することが可能な機能を有する。
【０１２１】
（1b）前記（１）の無線通信方法（無線通信装置）において、前記Block Ack Bitmapを作成する際、映像データ送信時に必要なフレーム数のみの送達確認を実施したBlock Ack Bitmapを作成することが可能な機能を有する。
【０１２２】
（1c）前記（1a）および（1b）の無線通信方法（無線通信装置）において、前記Block Ack Bitmapを作成し、Block Ack フレームを送信することが可能な機能を有する。
【０１２３】
上記（１）、（1a）〜（1c）によれば、QoS 機能を実装することにより上位アプリケーションに適した通信路を確保することが可能となり、かつ、Block Ack 機能を実装することにより不要なAck 送信を削減し、無線帯域を効率よく利用することが可能となる。そして、上記Block Ack Bitmapを作成する際、MSDU単位や映像伝送に必要なサイズを持ったBlock Ack Bitmapを作成することにより、効率のよい送達確認を行うことが可能となる。
【０１２４】
（２）無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法（無線通信装置）において、前記Block Ack フレームとしてBlock Ack Bitmapフィールドを取り除いたBlock Ack フレームを作成し、解析するステップ（手段）を具備する。
【０１２５】
（2a）前記（２）の無線通信方法（無線通信装置）において、前記Block Ack Bitmapの作成方法として、全てのデータを受信した場合または全てのデータを受信できなかった場合は、Block Ack Bitmapを含まないBlock Ack フレームを作成することが可能な機能を有する。
【０１２６】
（2b）前記（2a）の無線通信方法（無線通信装置）において、全てのデータを受信した場合にBlock Ack Bitmapを含まないBlock Ack フレームを作成するのか、または、全てのデータを受信できなかった場合にBlock Ack Bitmapを含まないBlock Ack フレームを作成するのかを判断することが可能な機能を有する。
【０１２７】
（2c）前記（2a）の無線通信方法（無線通信装置）において、前記Block Ack Bitmapを含んでいないフレームを受信した場合でも、Block Ack 送信側端末が全てのフレームを受信することができたのか、あるいは全てのフレームを受信することができなかったのかを判別することが可能な機能を有する。
【０１２８】
（2d）前記（2b）の無線通信方法（無線通信装置）において、前記Block Ack Req フレーム内のBA Controlフィールドを参照することによりどちらのモードで送信するのかを決定することが可能な機能を有する。
【０１２９】
（2e）前記（2b）の無線通信方法（無線通信装置）において、前記Block Ack フレーム送信側が独自にどちらのモードで送信するのかを決定することが可能な機能を有する。（2f）
前記（2b）の無線通信方法（無線通信装置）において、前記Block Ack フレーム内のBA Controlフィールド内にどちらのモードで送信したのかを示すフレームを作成し、送信することが可能な機能を有する。
【０１３０】
（2g）前記（2a）の無線通信方法（無線通信装置）において、前記Block Ack Bitmapを含まないBlock Ack フレームを受信した場合に、BA Controlフィールド内に記されたモードを参照することにより送達確認を行うことが可能な機能を有する。
【０１３１】
上記（２）、（2a）〜（2g）によれば、QoS 機能を実装することにより上位アプリケーションに適した通信路を確保することが可能となり、かつ、Block Ack 機能を実装することにより不要なAck 送信を削減し、無線帯域を効率よく利用することが可能となる。そして、上記Block Ack フレームとしてBlock Ack Bitmapフィールドを取り除いたBlock Ackフレームを作成し、解析することにより、Block Ack Bitmap作成処理を無くすると同時に、それに伴い効率よく無線帯域を利用することができるようになる。
【０１３２】
（３）無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を使用する無線通信方法（無線通信装置）において、前記Block Ack フレームに含まれるBlock Ack Bitmapフィールドのサイズを静的および動的に変更するステップ（手段）を具備する。
【０１３３】
（3a）前記（３）の無線通信方法（無線通信装置）において、前記Block Ack フレームを受信し、解析することが可能な機能を有する。
【０１３４】
（3b）前記（３）の無線通信方法（無線通信装置）において、前記Block Ack Req フレーム内のBA Controlフィールドを利用して前記Block Ack Bitmapサイズを知ることが可能な機能を有する。
【０１３５】
（3c）前記（３）の無線通信方法（無線通信装置）において、前記Block Ack フレーム内のBA Controlフィールドを利用して前記Block Ack Bitmapサイズを知ることが可能な機能を有する。
【０１３６】
（3d）前記（３）の無線通信方法（無線通信装置）において、前記Block Ack フレームの受信側でBlock Ack フレームのサイズを調べることにより前記Block Ack Bitmapサイズを算出することが可能な機能を有する。
【０１３７】
上記（３）、（3a）〜（3d）によれば、QoS 機能を実装することにより上位アプリケーションに適した通信路を確保することが可能となり、かつ、Block Ack 機能を実装することにより不要なAck 送信を削減し、無線帯域を効率よく利用することが可能となる。そして、Block Ack Bitmapサイズを静的および動的に変更することが可能なBlock Ack フレームを作成および送信することにより、一回のBlock Ack メカニズムで送信可能なフレーム数に合わせた柔軟で効率のよいBlock Ack フレーム送信が可能となる。これにより無線帯域の節約に繋がる。
【０１３８】
（４）無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法（無線通信装置）において、前記Block Ack フレームとしてBA Segment領域を追加したBlock Ack フレームを作成するステップ（手段）を具備する。
【０１３９】
（4a）前記（４）の無線通信方法（無線通信装置）において、前記Block Ack フレーム内に（図８に示した）BA Segment領域を追加したフレームを作成し、送信することが可能な機能を有する。
【０１４０】
（4b）前記（４）の無線通信方法（無線通信装置）において、前記Block Ack フレーム内に図８に示した方法で多重化したBA Segment領域を追加したフレームを送信することが可能な機能を有する。
【０１４１】
（4c）前記（４）の無線通信方法（無線通信装置）において、前記Block Ack フレーム内にBA Segment領域が含まれたフレームを受信することにより送達確認を行うことが可能な機能を有する。
【０１４２】
（4d）前記（４）の無線通信方法（無線通信装置）において、図13に示した方法で前記BA Segment領域のBA Segmentを作成することが可能な機能を有する。
【０１４３】
上記（４）、（4a）〜（4d）によれば、QoS 機能を実装することにより上位アプリケーションに適した通信路を確保することが可能となり、かつ、Block Ack 機能を実装することにより不要なAck 送信を削減し、無線帯域を効率よく利用することが可能となる。そして、Block Ack Bitmapを多重化してBA Segmentという考え方を取り入れることにより、受信フレーム数に応じて適切なサイズのBlock Ack Bitmapを作成することが可能となる。また、BA Segment領域の多重化は、受信フレームまたは未受信フレームの送達確認情報を省略することを可能とし、より効率のよいデータ伝送を行うことができるようになる。また、MSDU単位での送達確認とMPDU単位での送達確認を一つのフレームで実施することが可能となる。よって、無線帯域の節約や、端末内部の処理を効率よく行うことができる。
【０１４４】
（５）無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法（無線通信装置）において、前記Block Ack Req フレームを送信しないで送達確認を行うステップ（手段）を具備する。
【０１４５】
（5a）前記（５）の無線通信方法（無線通信装置）において、前記Block Ack Req フレームの送信を停止するモードを取り入れている。
【０１４６】
（5b）前記（５）の無線通信方法（無線通信装置）において、予め両端末間で前記Block Ack Req フレームの送信モードを決めることが可能な機能を有する。
【０１４７】
（5c）前記（５）の無線通信方法（無線通信装置）において、前記BA Controlフィールドにモード情報を入れたフレームを作成し、送信することによって前記Block Ack Req フレームの送信モードを決めることが可能な機能を有する。
【０１４８】
（5d）前記（５）の無線通信方法（無線通信装置）において、前記Block Ack Req フレームの送信モードが前記BA Controlフィールドに書かれたフレームを受信側端末で受信した場合に解析し、理解することが可能な機能を有する。
【０１４９】
（5e）前記（５）の無線通信方法（無線通信装置）において、前記Block Ack Req フレームの送信を停止しても送達確認を行うことが可能な機能を有する。
【０１５０】
（5f）前記（５）の無線通信方法（無線通信装置）において、前記Block Ack Req フレームを受信しなくても、受信側端末で前記Block Ack Bitmapを作成し、送信することが可能な機能を有する。
【０１５１】
（5g）前記（５）の無線通信方法（無線通信装置）において、前記Block Ack Req フレームを受信しなくても、一定時間後に送信用バッファの開放を行うことが可能な機能を有する。
【０１５２】
（5h）前記（5g）の無線通信方法（無線通信装置）において、前記バッファの解放タイミングを、TXOPが終了した時点、または、SI(Service Interval)が終了した時点にすることが可能な機能を有する。
【０１５３】
上記（５）、（5a）〜（5h）によれば、QoS 機能を実装することにより上位アプリケーションに適した通信路を確保することが可能となり、かつ、Block Ack 機能を実装することにより不要なAck 送信を削減し、無線帯域を効率よく利用することが可能となる。そして、Block Ack Req フレームの送信を停止することにより、必要最低限のフレーム送信で効率のよい送達確認を行うことが可能となる。また、無線帯域の効率化および端末内部での処理量の削減を行うことができる。
【０１５４】
（６）無線LAN 通信の規格IEEE802.11に準拠し、かつ、サービス品質優先制御機能としてBlock Ack Req フレームおよびBlock Ack フレームを作成して複数のDATAフレームの受信確認を一括して行うBlock Ack 機能を有する無線通信方法（無線通信装置）において、前記Block Ack フレームを送信しないで送達確認を行うステップ（手段）を具備する。
【０１５５】
（6a）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームの送信を停止するモードを取り入れている。
【０１５６】
（6b）前記（６）の無線通信方法（無線通信装置）において、予め両端末間で前記Block Ack フレームの送信モードを決めることが可能な機能を有する。
【０１５７】
（6c）前記（６）の無線通信方法（無線通信装置）において、前記BA Controlフィールドにモード情報を入れたフレームを作成し、送信することによって前記Block Ack フレームの送信モードを決めることが可能な機能を有する。
【０１５８】
（6d）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームの送信モードが前記BA Controlフィールドに書かれたフレームを受信側端末で受信した場合に解析し、理解することが可能な機能を有する。
【０１５９】
（6e）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームの送信を停止しても送達確認を行うことが可能な機能を有する。
【０１６０】
（6f）前記（６）の無線通信方法（無線通信装置）において、前記BA Controlフィールドを利用して全受信および全未受信を確認することによって前記Block Ack フレームの送信を停止した場合の送達確認を行うことが可能な機能を有する。
【０１６１】
（6g）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームを送信しない場合は、受信端末側で全フレームを受信できた、あるいは全フレームを受信できなかったと確認することによって前記Block Ack フレームの送信を停止した場合の送達確認を行うことが可能な機能を有する。
【０１６２】
（6h）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームの送信タイミングとして、DATAフレーム送信側端末のバッファが越えない範囲でBlock Ack フレームを送信することが可能な機能を有する。
【０１６３】
（6i）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームの送信タイミングとして、TXOP期間終了時に送信することが可能な機能を有する。
【０１６４】
（6j）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームの送信タイミングとして、SI期間終了時に送信することが可能な機能を有する。
【０１６５】
（6k）前記（６）の無線通信方法（無線通信装置）において、前記Block Ack フレームの送信タイミングとして、ある一定周期で定期的に送信することが可能な機能を有する。
【０１６６】
（6l）前記（６）の無線通信方法（無線通信装置）において、送信側端末のバッファ解放を行いたい時に、前記Block Ack Req フレームを強制的に送信し、前記Block Ack フレームを要求することが可能な機能を有する。
【０１６７】
（6m）前記（６）の無線通信方法（無線通信装置）において、送信側端末のバッファ解放を行いたい時に、前記Block Ack Req フレームを強制的に送信することにより、受信側端末へバッファ解放を行うことを通知させることが可能な機能、および、受信側端末では前記フレームを理解することが可能な機能を有する。
【０１６８】
上記（６）、（6a）〜（6m）によれば、QoS 機能を実装することにより上位アプリケーションに適した通信路を確保することが可能となり、かつ、Block Ack 機能を実装することにより不要なAck 送信を削減し、無線帯域を効率よく利用することが可能となる。そして、Block Ack フレームの送信を停止することにより、必要最低限のフレーム送信で効率のよい送達確認を行うことが可能となる。また、無線帯域の効率化および端末内部での処理量の削減を行うことができる。
【０１６９】
（その他）
上記したような複数の機能を同時に実現することも可能である。また、前記BA Controlフィールドの作成方法として、表１に示したような意味を持たせることにより、より様々な機能を柔軟に制御することが可能である。
【０１７０】
このようにすれば、BA Controlフィールドや予め両端末間で送信モードを決定しておくことにより、様々な複数の機能を同時に実現することが可能となる。特に、BA ControlフィールドはBlock Ack シーケンス毎に決定することができるので、柔軟な制御が可能となり、無線帯域の効率化や端末内の処理量の削減を図ることが可能となる。また、表１に示した値は、既存のBlock Ack シーケンスのみをサポートした端末との互換性も保たれているので、多様な端末との接続性も確保されている。
【図面の簡単な説明】
【０１７１】
【図１】本発明の無線通信装置の第１の実施形態に係る無線LAN機器のベースバンド部を搭載した半導体チップのハードウェア構成の一例を示すブロック図。
【図２】図１中のベースバンド部を制御するためのソフトウェア構成の一例を示すブロック図。
【図３】本発明の無線通信方法および無線通信装置の第１の実施形態で採用するIEEE802.11e 準拠のBlock Ack フレームの第１の例を示すフレームフォーマット図。
【図４】本発明の無線通信方法および無線通信装置の第１の実施形態で採用するIEEE802.11e 準拠のBlock Ack フレームの第２の例を示すフレームフォーマット図。
【図５】本発明の無線通信方法および無線通信装置の第２の実施形態で採用するBlock Ack フレームを示すフレームフォーマット図。
【図６】本発明の無線通信方法および無線通信装置の第３の実施形態で採用するBA Segment可変長方式のBlock Ack フレームを示すフレームフォーマット図。
【図７】本発明の無線通信方法および無線通信装置の第１の実施形態で採用するBlock Ack Req フレームを示すフレームフォーマット図。
【図８】本発明の無線通信方法および無線通信装置の第４の実施形態で採用するBlock Ack 情報を多重化（ｍ重化）したBA Segment可変長方式のBlock Ack フレームの一例を示すフレームフォーマット図。
【図９】図８においてｍ＝３の場合のBA Segment可変長方式のBlock Ack フレームを示すフレームフォーマット図。
【図１０】表２に示したフレームシーケンス番号管理テーブルを例にとった場合のBlock Ack Req フレームを示すフレームフォーマット。
【図１１】表３に示したフレームシーケンス番号管理テーブルを例にとった場合のBlock Ack(n)フレームを示すフレームフォーマット。
【図１２】表４に示したシーケンス番号管理テーブルを例にとった場合のm-Extended Block Ackフレームを示すフレームフォーマット。
【図１３】IEEE802.11e で規定されている二種類のBlock Ack モード(Immediate Mode およびDelayed Mode) を示すシーケンス図。
【図１４】本発明の無線通信方法および無線通信装置の第５の実施形態で採用するIEEE802.11e の拡張版を示すシーケンス図。
【図１５】IEEE802.11e で規定されているBlock Ack Req フレームを示すフレームフォーマット図。
【図１６】IEEE802.11e で規定されているBlock Ack フレームを示すフレームフォーマット図。
【符号の説明】
【０１７２】
１０…半導体チップ、１１…システムバス、１２…ＣＰＵ、１３…外部Ｉ／Ｆ制御部、１４…ＭＡＣ処理部、１５…メモリ制御部、１６…ＰＨＹ処理部、１７…内部メモリ、１８…外部メモリ。
【図１】
2006217242.tif 000007
【図２】
2006217242.tif 000008
【図３】
2006217242.tif 000009
【図４】
2006217242.tif 000010
【図５】
2006217242.tif 000011
【図６】
2006217242.tif 000012
【図７】
2006217242.tif 000013
【図８】
2006217242.tif 000014
【図９】
2006217242.tif 000015
【図１０】
2006217242.tif 000016
【図１１】
2006217242.tif 000017
【図１２】
2006217242.tif 000018
【図１３】
2006217242.tif 000019
【図１４】
2006217242.tif 000020
【図１５】
2006217242.tif 000021
【図１６】
2006217242.tif 000022