(57)【要約】  ブロックＡＣＫフレームの伝送方法および装置を提供する。ブロックＡＣＫフレームの伝送方法は、送信ステーションから複数のフレームを受信するステップと、前記送信ステーションから、圧縮されたブロックＡＣＫフレームの伝送が要請されるステップと、前記受信したフレームの受信状態を確認するステップと、前記受信したフレームの受信状態を示すランレングス符号化方式のビットマップを有する圧縮されたブロックＡＣＫフレームを生成するステップと、前記圧縮されたブロックＡＣＫフレームを前記送信ステーションに伝送するステップとを含む。
2008511243.tif 000002
【特許請求の範囲】
【請求項１】
送信ステーションから複数のフレームを受信するステップと、
前記送信ステーションから、圧縮されたブロックＡＣＫフレームの伝送が要請されるステップと、
前記受信したフレームの受信状態を確認するステップと、
前記受信したフレームの受信状態を示すランレングス符号化方式のビットマップを有する圧縮されたブロックＡＣＫフレームを生成するステップと、
前記圧縮されたブロックＡＣＫフレームを前記送信ステーションに伝送するステップとを含む、ブロックＡＣＫフレームの伝送方法。
【請求項２】
前記ビットマップは、前記所定の数のフレームのパターンを示すパターンフィールドと前記パターンフィールドに記録されたパターンの繰り返される回数を示すサイズフィールドの対を少なくとも１つ以上含む、請求項１に記載のブロックＡＣＫフレームの伝送方法。
【請求項３】
前記パターンフィールドおよびサイズフィールドの対は、１バイトの大きさを有する、請求項２に記載のブロックＡＣＫフレームの伝送方法。
【請求項４】
前記パターンフィールドは、２ビットパターンまたは４ビットパターンのうちいずれか１つである、請求項２に記載のブロックＡＣＫフレームの伝送方法。
【請求項５】
前記圧縮されたブロックＡＣＫフレームは、前記複数のフレームすべてをエラーなく受信した場合を示すためのＰＲフィールドと、前記複数のフレームすべてにエラーがあることを示すためのＰＢフィールドとを含む、請求項１に記載のブロックＡＣＫフレームの伝送方法。
【請求項６】
前記ＰＲフィールドは、繰り返し符号の形態で構成される、請求項５に記載のブロックＡＣＫフレームの伝送方法。
【請求項７】
送信ステーションから複数のフレームを受信するステップと、
前記送信ステーションから、圧縮されたブロックＡＣＫフレームの伝送が要請されるステップと、
前記受信したフレームの受信状態を確認するステップと、
前記受信したフレームの状態を圧縮されたブロックＡＣＫフレームで表す場合、基準サイズより小さくなるか否かを判断するステップと、
前記圧縮されたブロックＡＣＫフレームが基準サイズより小さい場合、圧縮されたブロックＡＣＫフレームを生成するステップと、
前記生成した圧縮されたブロックＡＣＫフレームを前記送信ステーションに伝送するステップとを含む、ブロックＡＣＫフレームの伝送方法。
【請求項８】
前記圧縮されたブロックＡＣＫフレームが基準サイズより大きい場合、前記受信したフレームの状態を示す圧縮されないブロックＡＣＫフレームを生成するステップと、前記生成した圧縮されないブロックＡＣＫフレームを前記送信ステーションに伝送するステップとをさらに含む、請求項７に記載のブロックＡＣＫフレームの伝送方法。
【請求項９】
前記基準サイズは、前記圧縮されないブロックＡＣＫフレームのサイズである、請求項８に記載のブロックＡＣＫフレームの伝送方法。
【請求項１０】
前記圧縮されたフレームは、前記受信したフレームの受信状態を示すランレングス符号化方式のビットマップを含む、請求項７に記載のブロックＡＣＫフレームの伝送方法。
【請求項１１】
前記ビットマップは、前記所定の数のフレームのパターンを示すパターンフィールドと前記パターンフィールドに記録されたパターンの繰り返される回数を示すサイズフィールドの対を少なくとも１つ以上含む、請求項１０に記載のブロックＡＣＫフレームの伝送方法。
【請求項１２】
前記パターンフィールドおよびサイズフィールドの対は、１バイトの大きさを有する、請求項１１に記載のブロックＡＣＫフレームの伝送方法。
【請求項１３】
前記パターンフィールドは、２ビットパターンまたは４ビットパターンのうちいずれか１つである、請求項１１に記載のブロックＡＣＫフレームの伝送方法。
【請求項１４】
前記圧縮されたブロックＡＣＫフレームは、前記複数のフレームすべてをエラーなく受信した場合を示すためのＰＲフィールドと、前記複数のフレームすべてにエラーがあることを示すためのＰＢフィールドとを含む、請求項７に記載のブロックＡＣＫフレームの伝送方法。
【請求項１５】
前記ＰＲフィールドは、繰り返し符号の形態で構成される、請求項１４に記載のブロックＡＣＫフレームの伝送方法。
【請求項１６】
受信した複数のフレームのエラーの有無を確認するＭＡＣモジュールと、
前記受信した複数のフレームのエラーの有無に応じて圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを生成し、前記ＭＡＣモジュールが圧縮されたブロックＡＣＫフレームを生成するように、前記圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを前記ＭＡＣモジュールに提供するブロックＡＣＫ選択モジュールと、
前記ＭＡＣモジュールが生成した圧縮されたブロックＡＣＫフレームを受信して伝送する物理層モジュールとを含む、ステーション。
【請求項１７】
前記ブロックＡＣＫ選択モジュールは、前記受信した複数のフレームのエラーの有無によるＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐのサイズが圧縮されないＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐのサイズより大きいか等しい場合、前記ＭＡＣモジュールが圧縮されないブロックＡＣＫフレームを生成するように、前記圧縮されないＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを前記ＭＡＣモジュールに提供する、請求項１６に記載のステーション。
【請求項１８】
送信ステーションから複数のフレームを受信するステップと、
前記送信ステーションから、圧縮されたブロックＡＣＫフレームの伝送が要請されるステップと、
前記受信したフレームの受信状態を確認するステップと、
前記受信したフレームの受信状態を示すランレングス符号化方式のビットマップを有する圧縮されたブロックＡＣＫフレームを生成するステップと、
前記圧縮されたブロックＡＣＫフレームを前記送信ステーションに伝送するステップとを含む、ブロックＡＣＫフレームの伝送方法を実行させるためのコンピュータによって読取可能なプログラムを記録した記録媒体。
【請求項１９】
送信ステーションから複数のフレームを受信するステップと、
前記送信ステーションから、圧縮されたブロックＡＣＫフレームの伝送が要請されるステップと、
前記受信したフレームの受信状態を確認するステップと、
前記受信したフレームの状態を圧縮されたブロックＡＣＫフレームで表す場合、基準サイズより小さくなるか否かを判断するステップと、
前記圧縮されたブロックＡＣＫフレームが基準サイズより小さい場合、圧縮されたブロックＡＣＫフレームを生成するステップと、
前記生成した圧縮されたブロックＡＣＫフレームを前記送信ステーションに伝送するステップとを含む、ブロックＡＣＫフレームの伝送方法を実行させるためのコンピュータによって読取可能なプログラムを記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信メカニズムに関し、より詳しくは、効率的な無線通信のためのブロックＡＣＫの伝送メカニズムに関するものである。
【背景技術】
【０００２】
ネットワークが無線化しつつあり、大容量のマルチメディアデータの伝送に対する要求が増えるにつれて、無線ネットワーク環境における効果的な伝送方法に関する研究が要求されている。与えられた無線リソースを様々なステーションが共有して使用する無線ネットワークの特性上、競争が激しければ通信中の衝突によって貴重な無線リソースを無駄にする可能性が大きい。このような衝突を減らし、安定してデータを送受信するために、無線ＬＡＮ環境では競争基盤のＤＣＦ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）または無競争方式のＰＣＦ（Ｐｏｉｎｔ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）が提供される。
【０００３】
このような方法によって無線環境で衝突なく安定してデータを送受信することができるが、１つのステーションが通信する間には同じ電波範囲内に存在する他のステーションは待機しなければならないため、ステーション数が増えると伝送率はかなり減少することになる。したがって、無線ネットワーク環境において安定した通信を保障すると共にデータ伝送率を向上させることが重要な争点になる。
【０００４】
無線ネットワーク環境で安定した通信を保障するためにＡＣＫフレームが用いられる。一方、伝送率を向上させるためには主に伝送するデータで不要なオーバヘッドを減らすテクニックが研究されている。ＩＥＥＥ  ８０２．１１ｅ標準はＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を保障するための多様な技術を規定しており、その中の１つがブロックＡＣＫ技術である。ＩＥＥＥ  ８０２．１１標準によるＡＣＫ技術では、受信ステーションが個々のフレームを受信する度に受信したフレームに対するＡＣＫフレームを送信フレームに伝送する。ＩＥＥＥ  ８０２．１１ｅ標準は、以前のＡＣＫ技術だけでなく複数のフレームに対するブロックＡＣＫ技術を規定する。ブロックＡＣＫ技術では、受信ステーションが受信した複数のフレームに対する１つのブロックＡＣＫフレームを送信ステーションに伝送する。ブロックＡＣＫフレームは、受信したすべてのフレームに対する受信状態に関する情報を含む。
【０００５】
図１は、ＩＥＥＥ  ８０２．１１ｅ標準によるブロックＡＣＫメカニズムを示し、図２および図３は、各々ブロックＡＣＫ要請フレームとブロックＡＣＫフレームの構造を示す。
【０００６】
先ず図１を参照すれば、ブロックＡＣＫメカニズムは、大きくセットアップ過程（Ｓ１０）と、データの伝送過程（Ｓ２０）、および終了過程（Ｓ３０）に分けられる。
【０００７】
先ずセットアップ過程（Ｓ１０）では、ＱｏＳデータを送信しようとする送信ステーションは受信ステーションにＡＤＤＢＡ要請をする。ＡＤＤＢＡ要請フレームには、ＡＤＤＢＡ要請フレームを知らせる情報と、ダイアログトークンフィールドと、ブロックＡＣＫパラメータセットフィールド、およびブロックＡＣＫタイムアウト値が含まれる。
【０００８】
ＡＤＤＢＡ要請フレームを受信した受信ステーションは、送信ステーションにＡＤＤＢＡ応答をする。ＡＤＤＢＡ応答フレームには、ＡＤＤＢＡ応答フレームを知らせる情報と、受信したＡＤＤＢＡ要請フレームから得たダイアログトークンと、ＡＤＤＢＡ状態コードフィールドと、ブロックＡＣＫパラメータセットフィールドと、ブロックＡＣＫタイムアウト値とが含まれる。
【０００９】
ＡＤＤＢＡ要請とＡＤＤＢＡ応答が終われば、データの伝送過程（Ｓ２０）が開始される。データ伝送過程において送信ステーションは、複数のデータフレームを受信ステーションに伝送する。フレームをすべて伝送すれば、送信ステーションは受信ステーションにブロックＡＣＫ要請をする。ブロックＡＣＫ要請を受けた受信ステーションはブロックＡＣＫ応答をする。ブロックＡＣＫ要請フレームとブロックＡＣＫ応答フレームについては図２と図３を参照して後述する。
【００１０】
送信ステーションがブロックＡＣＫフレームを受信した後に終了過程（Ｓ３０）が実行されるが、送信ステーションは受信ステーションにＤＥＬＢＡ要請をする。ＤＥＬＢＡ要請フレームには、ＤＥＬＢＡ要請フレームを知らせる情報と、ＤＥＬＢＡパラメータフィールドとが含まれる。
【００１１】
図２は、ＩＥＥＥ  ８０２．１１ｅ標準によるブロックＡＣＫ要請フレームの構造を示す。
ブロックＡＣＫ要請フレーム２０は、ＭＡＣ  ｈｅａｄｅｒ２１と、ブロックＡＣＫ要請フレームの動作を制御するためにＴＩＤフィールド２２２と留保フィールド２２０とから構成されるＢＡＲ  Ｃｏｎｔｒｏｌフィールド２２と、開始ＭＰＤＵのｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド２３０とｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒフィールド２３２とから構成されるＢｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド２３と、エラーチェックサムを計算するためのＦＣＳフィールド２４とから構成される。
【００１２】
図３は、ＩＥＥＥ  ８０２．１１ｅ標準によるブロックＡＣＫフレームの構造を示す。
ブロックＡＣＫフレーム３０は、ＭＡＣ  ｈｅａｄｅｒ３１と、ブロックＡＣＫフレームの動作を制御するためにＴＩＤフィールド３２２と留保フィールド３２０とから構成されるＢＡ  Ｃｏｎｔｒｏｌフィールド３２と、開始ＭＰＤＵのｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド３３０とｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒフィールド３３２とから構成されるＢｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３３と、以後のＭＰＤＵに対する「受信確認情報」（特定データを正しく受信したかを示す情報）が順次記録されるＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３４と、エラーチェックサムを計算するためのＦＣＳフィールド３５とから構成される。
【００１３】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３４には１２８バイトが割り当てられるため、１つのＭＳＤＵに対して２バイトずつ割り当てられれば、最大６４個のＭＳＤＵに対する受信確認情報が記録され得る。１つのＭＳＤＵに対して２バイトが割り当てられるとは、ＩＥＥＥ  ８０２．１１ｅにおいて１つのＭＳＤＵは最大１６個までフラグメンテーションできるため、最大フラグメンテーション数だけのビット数（１６×１ビット）、すなわち２バイトが割り当てられるということである。したがって、実際にフラグメンテーションされていないか、１６より小さい数だけフラグメンテーションが行われた場合にも一律して２バイトが割り当てられるため、このように１つのビットで受信確認情報を示すのは効率的ではない。したがって、このように１つのＭＳＤＵを表すのに２バイトを用いれば、ブロックＡＣＫフレームの大きさが必要以上に大きくなる。
【００１４】
よって、以前のブロックＡＣＫフレームの機能をそのまま行いながら、より小さいサイズを有するブロックＡＣＫフレームが提供されれば有用となる。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明は上述したような必要性に応じて導き出されたものであり、さらに本発明は効率的なブロックＡＣＫフレームの伝送方法と装置を提供することにその目的がある。
【００１６】
本発明の目的は、以上で言及した目的に制限されず、言及していないまた他の目的は下記記載によって当業者が明確に理解できるものである。
【課題を解決するための手段】
【００１７】
前記目的を達成するために、本発明の一態様に係るブロックＡＣＫフレームの伝送方法は、送信ステーションから複数のフレームを受信するステップと、前記送信ステーションから、圧縮されたブロックＡＣＫフレームの伝送が要請されるステップと、前記受信したフレームの受信状態を確認するステップと、前記受信したフレームの受信状態を示すランレングス符号化方式のビットマップを有する圧縮されたブロックＡＣＫフレームを生成するステップと、前記圧縮されたブロックＡＣＫフレームを前記送信ステーションに伝送するステップとを含む。
【００１８】
前記目的を達成するために、本発明の他の態様に係るブロックＡＣＫフレームの伝送方法は、送信ステーションから複数のフレームを受信するステップと、前記送信ステーションから、圧縮されたブロックＡＣＫフレームの伝送が要請されるステップと、前記受信したフレームの受信状態を確認するステップと、前記受信したフレームの状態を圧縮されたブロックＡＣＫフレームで表す場合、基準サイズより小さくなるか否かを判断するステップと、前記圧縮されたブロックＡＣＫフレームが基準サイズより小さい場合、圧縮されたブロックＡＣＫフレームを生成するステップと、前記生成した圧縮されたブロックＡＣＫフレームを前記送信ステーションに伝送するステップとを含む。
【００１９】
前記目的を達成するために、本発明のまた他の態様に係るステーションは、受信した複数のフレームのエラーの有無を確認するＭＡＣモジュールと、前記受信した複数のフレームのエラーの有無に応じて圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを生成し、前記ＭＡＣモジュールが圧縮されたブロックＡＣＫフレームを生成するように、前記圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを前記ＭＡＣモジュールに提供するブロックＡＣＫ選択モジュールと、前記ＭＡＣモジュールが生成した圧縮されたブロックＡＣＫフレームを受信して伝送する物理層モジュールとを含む。
その他、実施形態の具体的な事項は、詳細な説明および図面に含まれている。
【発明の効果】
【００２０】
本発明によれば、無線通信のための効率的なＢｌｏｃｋ  ＡＣＫフレームを用いた無線ネットワーク通信が可能である。Ｂｌｏｃｋ  ＡＣＫフレームのサイズが小さくなるにつれてＢｌｏｃｋ  ＡＣＫフレームを伝送するのに必要な時間を短縮することができ、Ｂｌｏｃｋ  ＡＣＫの伝送中に生じるエラーを減らすことができる。
【発明を実施するための最良の形態】
【００２１】
本発明の利点および特徴、そしてそれらを達成する方法は、添付する図面と共に詳細に後述する実施形態を参照すれば明確になる。しかし、本発明は以下にて開示する実施形態に限定されず、互いに異なる多様な形態によって実施され、単に本実施形態は本発明の開示が完全なものとなるようにし、本発明が属する技術分野で通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであって、本発明は請求項の範疇によってのみ定義されるものである。
【００２２】
以下、添付した図面を参照して本発明の好ましい実施形態について詳しく説明する。
【００２３】
図４は、本発明の一実施形態によって提案されたブロックＡＣＫフレームの構造を示す。
ブロックＡＣＫフレーム４０は、図３に示す以前のブロックＡＣＫフレーム３０のように、ＭＡＣ  ｈｅａｄｅｒ４１と、ブロックＡＣＫフレームの動作を制御するためのＢＡ  Ｃｏｎｔｒｏｌフィールド４２と、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド４３と、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド４４と、エラーチェックサムを計算するためのＦＣＳフィールド４５とから構成される。
【００２４】
ＭＡＣ  ｈｅａｄｅｒ４１は、Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド、Ｄｕｒａｔｉｏｎフィールド、ＲＡフィールド、およびＴＡフィールドを含む。
Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールドは、以前のブロックＡＣＫフレームのようにブロックＡＣＫフレームのタイプが制御（ｃｏｎｔｒｏｌ）であることを知らせる情報と、ブロックＡＣＫフレームのサブタイプがブロックＡＣＫフレームであることを知らせる情報とを含む。
【００２５】
Ｄｕｒａｔｉｏｎフィールドには、以前のブロックＡＣＫフレームと等しい値が記録される。すなわち、ブロックＡＣＫフレームがブロックＡＣＫ要請フレームに対する応答として送られる場合には、ブロックＡＣＫ要請フレームのＤｕｒａｔｉｏｎフィールドで得た値からブロックＡＣＫフレームを伝送するのに必要な時間と１つのＳＩＦＳ（Ｓｈｏｒｔ  ＩｎｔｅｒＦｒａｍｅ  Ｓｐａｃｅ）間隔を引いた時間より大きいか等しい値がマイクロ秒単位で記録される。ブロックＡＣＫフレームがブロックＡＣＫ要請フレームに対する応答として送られない場合には、１つのＡＣＫフレームを伝送するのに必要な時間とＳＩＦＳ間隔を合わせた時間より大きいか等しい値がマイクロ秒単位で記録される。
【００２６】
ＲＡフィールドとＴＡフィールドには、各々受信ステーションと送信ステーションのＭＡＣアドレスが記録される。
ＢＡ  Ｃｏｎｔｒｏｌフィールド４２は、以前のブロックＡＣＫのようにＴＩＤフィールド４２４を含むが、以前のブロックＡＣＫとは異なりＣｏｍｐｒｅｓｓｉｎｇ  ｍｏｄｅフィールド４２２とＮＵＭフィールド４２０とをさらに含むことができる。Ｃｏｍｐｒｅｓｓｉｎｇ  ｍｏｄｅフィールド４２２は２つのビットを有し、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド４４の圧縮モードを知らせる。ＮＵＭフィールド４２０は、総フラグメント数に対する値を記録する。
【００２７】
Ｂｌｏｃｋ  Ａｃｋ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド４３は、以前のブロックＡＣＫのようにＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールド４３２を含むが、以前のＡＣＫとは異なりＰＲフィールド４３１とＰＢフィールド４３０とを含む。
【００２８】
ＰＲフィールド４３１はすべてのフレームをエラーなく受信する時にセッティングされ、ＰＢフィールド４３０はエラーなく受信したフレームが全くない時にセッティングされる。エラーとは、フレームの一部ビット値の損傷やフレームを受信することができないということを意味する。本実施形態におけるＰＲフィールドは、繰り返し符号（Ｒｅｐｅｔｉｔｉｏｎ  Ｃｏｄｅ）の形態で構成されているため、伝送中のエラーに強い特性を有する。
【００２９】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド４４は、以前のＡＣＫフレームとは異なり可変長さを有するが、これについては図５を参照して後述する。
ＦＣＳフィールド４５は、以前のＡＣＫフレームと同様にエラーチェックサムを計算するために用いられる。
【００３０】
図５は、本発明の一実施形態に係るブロックＡＣＫフレームのビットマップ構造を示す図面である。
本実施形態におけるＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド４４には、ランレングス符号化によって以前のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐ値を圧縮した値が記録される。
【００３１】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐ４４の基本的な構造は、パターンフィールド５１０とサイズフィールド５２０の対を少なくとも１つ以上含む。一実施形態において、１つのパターンフィールド５１０と１つのサイズフィールド５２０の大きさの和は１バイトとなる。
【００３２】
パターンフィールド５１０は、フレームの受信状態のパターンを表わすのに用いられる。一実施形態において、パターンフィールド５１０の大きさは一度に表わすフレームの数によって異なる。図５に示すように、一度に２つのフレームを表わす場合には２ビットの大きさを有するパターンフィールド５１２と６ビットの大きさを有するサイズフィールド５２２とが用いられ、一度に４個のフレームを表わす場合には４ビットの大きさを有するパターンフィールド５１４と４ビットの大きさを有するサイズフィールド５２４とが用いられる。
【００３３】
このように本実施形態でＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを圧縮するのにランレングス符号化を用いるのは、ブロックの伝送で生じるフレームのエラーが連続的である場合が多いためである。例えば、４８個のフレームが、伝送されたフレームのうちの正常に受信したフレーム（「１」と表示）と正常に受信していないフレーム（「０」と表示）とが「１１１１１１１１１１  １１１０００００００  ００００００００００  ０００００００００００  １０１０１０００」になると仮定する。以前のＢｉｔｍａｐ方式によれば４８バイトが用いられるが、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールドは１２８バイトの固定された長さを有する。しかし、本実施形態によれば、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールドの長さは以前の場合より短くなる。すなわち、２つのフレームを一度に表わす場合には、（１１、６個）（１０、１個）（００、１３個）（１０、３個）（００、１個）であって、総５バイトが必要となる。また、４つのフレームを一度に表わす場合には、（１１１１、３個）（１０００、１個）（００００、６個）（１０１０、１個）（１０００、１個）であって、総５バイトが必要となる。すなわち、以前の方式によれば、ブロックＡＣＫフレームは、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールドの長さを含み、総１５２バイトが必要となるが、本発明の実施形態によれば総２９バイトの長さであれば充分である。したがって、本発明の実施形態によれば、ブロックＡＣＫフレームの長さは以前の場合よりさらに短くなる。ブロックＡＣＫフレームの長さが短くなれば、データの伝送時間が短縮することを意味することにもなるが、ブロックＡＣＫフレームにエラーが生じる確率が低くなることも意味する。
【００３４】
一方、前述したＰＢフィールド４３０とＰＲフィールド４３１を用いる場合には、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐが省略され得る。すなわち、受信ステーションは、受信したすべてのフレームからエラーが生じたりすべてのフレームを受信しなかったりする場合にはＰＢフィールド４３０をセッティングすることができ、すべてのフレームを正常に受信した場合にはＰＲフィールド４３１をセッティングすることができる。この場合、ブロックＡＣＫフレームの長さは２４バイトを有する。
【００３５】
図６は、本発明の一実施形態に係るブロックＡＣＫ要請フレームの構造を示す図面である。
ブロックＡＣＫ要請フレーム６０は、図２のブロックＡＣＫフレームのようにＭＡＣ  ｈｅａｄｅｒ６１と、ＢＡＲ  Ｃｏｎｔｒｏｌフィールド６２と、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド６３と、エラーチェックサムを計算するためのＦＣＳフィールド６４とから構成される。
【００３６】
ＢＡＲ  Ｃｏｎｔｒｏｌフィールド６２は、以前のブロックＡＣＫフレームのようにＴＩＤフィールド６２４を含むが、以前のブロックＡＣＫフレームとは異なりＢＡ  Ｔｙｐｅフィールド６２２をさらに含む。
【００３７】
ＢＡ  Ｔｙｐｅフィールド６２２は、受信ステーションが伝送するブロックＡＣＫフレームのタイプをセッティングするフィールドである。例えば、以前のブロックＡＣＫフレームを受信しようとする場合には、送信ステーションはＢＡ  Ｔｙｐｅ値を「００」と設定し、本発明の実施形態に係るブロックＡＣＫフレームを受信しようとする場合には、ＢＡ  Ｔｙｐｅ値を「０１」と設定する。「１０」および「１１」の値は、また他のブロックＡＣＫフレームのために留保される。
【００３８】
図７は、本発明の一実施形態に係るブロックＡＣＫフレームの伝送過程を示す図面である。
送信ステーションが複数のフレームを伝送すれば、受信ステーションが伝送される複数のフレームを受信する（Ｓ７１０）。
【００３９】
複数のフレームを伝送した後、送信ステーションが本発明の実施形態により圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを有するブロックＡＣＫフレーム（以下、圧縮されたブロックＡＣＫフレーム）を要請する、圧縮されたブロックＡＣＫ要請フレームを伝送すれば、受信ステーションが圧縮されたブロックＡＣＫ要請フレームを受信する（Ｓ７２０）。受信ステーションは、受信したブロックＡＣＫ要請フレームのＢＡＲ  Ｃｏｎｔｒｏｌフィールドによって受信されたブロックＡＣＫ要請フレームが、圧縮されたブロックＡＣＫフレームを要請するフレームであることが分かる。
【００４０】
圧縮されたブロックＡＣＫ要請フレームを受信すれば、受信ステーションはＳ７１０段階で受信した複数のフレームの受信状態を確認する（Ｓ７３０）。すなわち、どのフレームが正常に受信され、どのフレームがエラーの生じた状態で受信されたかを確認する。
【００４１】
受信したフレームの状態を確認した後、受信ステーションは送信ステーションに伝送する圧縮されたブロックＡＣＫフレームを生成する（Ｓ７４０）。
【００４２】
圧縮されたブロックＡＣＫフレームが生成されれば、受信ステーションは圧縮されたブロックＡＣＫフレームを送信ステーションに伝送する（Ｓ７５０）。
【００４３】
受信ステーションの本発明の実施形態に係る圧縮されたブロックＡＣＫ要請フレームを支援しない場合、Ｓ７２０段階で受信ステーションは受信したフレームをブロックＡＣＫ要請フレームとして認識する。この場合、受信ステーションは送信ステーションに以前のブロックＡＣＫフレームを伝送する。すなわち、本発明の実施形態に係る圧縮されたブロックＡＣＫ要請フレームは、新しく定義したフレームではなく、以前のブロックＡＣＫフレームの留保したフィールドにセッティングされた情報によって区別されるフレームである。したがって、本発明の実施形態に係る圧縮されたブロックＡＣＫフレームを支援するステーションは、圧縮されたブロックＡＣＫフレームを支援しないステーションと互換することができる。
【００４４】
一方、場合によっては、圧縮されたブロックＡＣＫフレームの効率が以前のブロックＡＣＫフレームの効率より悪くなり得る。すなわち、エラーが生じるフレームのパターンが不規則である場合、ランレングス符号化の効率は低下することもある。よって、場合によっては圧縮されたブロックＡＣＫフレームが要請されても、受信したフレームの状態に応じて以前のブロックＡＣＫフレームを伝送する方式が必要となる。このような方式については図８を参照して説明する。
【００４５】
図８は、本発明の他の実施形態に係るブロックＡＣＫフレームの伝送過程を示す図面である。
送信ステーションが複数のフレームを伝送すれば、受信ステーションが伝送される複数のフレームを受信する（Ｓ８１０）。
【００４６】
複数のフレームを伝送した後、送信ステーションが本発明の実施形態によって圧縮されたブロックＡＣＫ要請フレームを伝送すれば、受信ステーションが圧縮されたブロックＡＣＫ要請フレームを受信する（Ｓ８２０）。図８の実施形態のように、受信ステーションは、受信したブロックＡＣＫ要請フレームのＢＡＲ  Ｃｏｎｔｒｏｌフィールドによって受信されたブロックＡＣＫ要請フレームが、圧縮されたブロックＡＣＫフレームを要請するフレームであることが分かる。
【００４７】
圧縮されたブロックＡＣＫ要請フレームを受信すれば、受信ステーションはＳ８１０段階で受信した複数のフレームの受信状態を確認する（Ｓ８３０）。すなわち、どのフレームが正常に受信され、どのフレームがエラーの生じた状態で受信されたかを確認する。
【００４８】
受信したフレームの状態を確認した後、受信ステーションは圧縮されたブロックＡＣＫ条件が満たされるか否かを判断する（Ｓ８４０）。圧縮されたブロックＡＣＫ条件は、生成される圧縮されたブロックＡＣＫフレームのサイズが基準サイズ、例えば以前のブロックＡＣＫフレームのサイズより小さい時に満たされる。すなわち、この場合に両者のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを比較して、どのフレームのサイズが小さいかを判断することができる。
【００４９】
圧縮されたブロックＡＣＫ条件が満たされる場合、受信ステーションは圧縮されたブロックＡＣＫフレームを生成する（Ｓ８５０）。次に、圧縮されたブロックＡＣＫフレームを送信ステーションに伝送する（Ｓ８６０）。
【００５０】
圧縮されたブロックＡＣＫ条件が満たされない場合、受信ステーションは以前のブロックＡＣＫフレームを生成する（Ｓ８７０）。次に、生成されたブロックＡＣＫフレームを送信ステーションに伝送する（Ｓ８８０）。
【００５１】
本実施形態においても、図７の実施形態のように本発明の実施形態に係る圧縮されたブロックＡＣＫ要請フレームを支援しないステーションは、Ｓ８２０段階で受信したフレームを以前のブロックＡＣＫ要請フレームとして認識する。この場合にも図７の実施形態のように、受信ステーションは送信ステーションに以前のブロックＡＣＫフレームを伝送する。
【００５２】
以上で説明したランレングス符号化方式によって圧縮されたブロックＡＣＫフレームは例示的なものであって、他の構造の圧縮されたブロックＡＣＫフレームも考えることができる。例えば、既存のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを一部修正したＢｉｔｍａｐを用いることもできる。これについては図９を参照して説明する。
【００５３】
図９は、本発明の他の実施形態に係るブロックＡＣＫフレームのビットマップ構造を示す図面である。
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド４４には、対象フレームに対するＡＣＫビット９１１とＴｙｐｅビット９１２との対（以下「ビット対」という）９１０が順次記録されるが、前記ビット対９１０の数ｍは、最小の場合は総ＭＳＤＵ数と等しく、最大の場合は総フラグメント数と等しい。
【００５４】
フレームは、フラグメンテーションが行われない場合には１つのＭＳＤＵからなり、フラグメンテーションが行われた場合にはＭＳＤＵのうちの一部フラグメントからなり得る。
【００５５】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド４４のうちのＡＣＫビット９１１には該当フレームが正常に受信されたかを確認するビットが記録されるが、正常に受信された場合は１と、そうでない場合は０と記録される。そして、Ｔｙｐｅビット９１２には、前記ＡＣＫビットが該当フレーム（ＭＳＤＵまたはフラグメント）に対する受信確認を示しているか（前者）と、ＭＳＤＵのうちの現フラグメント以後のすべてのフラグメントに対する受信確認を示しているか（後者）とを区別するビット情報が記録される。Ｔｙｐｅビット９１２は、前者の場合は０と、後者の場合は１と記録され得る。
【００５６】
前述した４８個のフレームが１０個のフラグメントを有した４個のＭＳＤＵと８個のフラグメントを有したＭＳＤＵである場合、「１１１１１１１１１１  １１１０００００００  ００００００００００  ０００００００００００  １０１０１０００」を表そうとすれば、ビット対を（１，１）、（１，０）（１，０）（１，０）（０，０）（０，０）（０，０）（０，０）（０，０）（０，０）（０，０）、（０，１）、（０，１）、（１，０）（０，０）（１，０）（０，０）（１，０）（０，０）（０，０）（０，０）で表すことができる。（１，１）は第１番目のＭＳＤＵのすべてのフラグメントを正常に受信したことを示し、（１，０）（１，０）（１，０）（０，０）（０，０）（０，０）（０，０）（０，０）（０，０）（０，０）は第２番目のＭＳＤＵの各フラグメントの受信状態を示し、（０，１）は第３番目のＭＳＤＵのすべてのフラグメントを正常に受信できなかったことを示し、（０，１）は第４番目のＭＳＤＵのすべてのフラグメントを正常に受信できなかったことを示し、（１，０）（０，０）（１，０）（０，０）（１，０）（０，０）（０，０）（０，０）は第５番目のＭＳＤＵの各フラグメントの受信状態を示す。この場合、総４２ビット、すなわち６バイト程度であればＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを十分表わすことができる。
【００５７】
したがって、以上で説明した圧縮されたブロックＡＣＫフレームの構造は例示的であると解釈しなければならない。
【００５８】
図１０は、本発明の一実施形態に係るステーションの構造を示すブロック図である。
ステーション１０００は、上位層モジュール１０１０と、ブロックＡＣＫ選択モジュール１０２０と、ＭＡＣモジュール１０３０と、制御ユニット１０４０と、ＰＨＹモジュール１０５０とを含む。
【００５９】
ＭＡＣモジュール１０３０は、ＭＡＣ層（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌａｙｅｒ）における動作を管理する。すなわち、上位層モジュール１０１０からＭＳＤＵが伝えられ、これにＭＡＣヘッダを取付け、その結果をＰＨＹモジュール１０５０に伝える。一方、ＭＡＣモジュール１０３０は、ブロックＡＣＫ選択モジュール１０２０によって生成されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを有するＢｌｏｃｋ  ＡＣＫフレームを生成し、ＰＨＹモジュール１０５０に伝える。
【００６０】
また、ＭＡＣモジュール１０３０は、ＰＨＹモジュール１０５０から他のステーションから伝送されたフレームを受信すれば、ここでＭＡＣヘッダを読み取った後にＭＡＣヘッダを除去し、その結果を上位層モジュール１０１０に伝える。ＭＡＣモジュール１０３０は、他のステーションから伝送されたフレームのＦＣＳフィールドによってエラーの有無をチェックし、エラーがない場合にフレームからＭＡＣヘッダを除去した後、上位層モジュール１０１０に伝える。
【００６１】
上位層モジュール１０１０は、ＭＳＤＵを生成してＭＡＣモジュール１０３０に伝え、ＭＡＣモジュール１０３０からＭＡＣヘッダが除去されたデータが伝えられる。このような上位層モジュール１０１０は、ＬＬＣ層（Ｌｏｇｉｃａｌ  Ｌｉｎｋ  Ｌａｙｅｒ）以上のネットワーク層を管理する。
【００６２】
ＰＨＹモジュール１０５０は、物理層における動作を管理する。すなわち、ＭＡＣモジュール１０３０からＭＰＤＵ（ＭＡＣ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）が伝えられ、ＰＰＤＵ（ＰＡＣＫｅｔ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を生成し、これを含む無線信号を生成して伝送する。また、無線媒体を介して伝えられる信号を受信して加工した後、これをＭＡＣモジュール１０３０に伝える。ＰＨＹモジュール１０５０は、再び細分化して、ベースバンドプロセッサとＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）モジュールに細分化することができる。
【００６３】
ブロックＡＣＫ選択モジュール１０２０は、受信したフレームの状態に応じてＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを生成し、これをＭＡＣモジュール１０３０に伝える。すなわち、ブロックＡＣＫ選択モジュール１０２０は、ＭＡＣモジュール１０３０において受信したフレームに対してエラーの有無をチェックすれば、これを用いてＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを生成する。一実施形態において、ステーション１０００が受信したフレームが圧縮されたブロックＡＣＫ要請フレームである場合、ブロックＡＣＫ選択モジュール１０２０は圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを生成する。他の実施形態において、ステーション１０００が受信したフレームが圧縮されたブロックＡＣＫ要請フレームである場合、ブロックＡＣＫ選択モジュール１０２０は圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐが既存のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐより小さいサイズになる場合のみに圧縮されたＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを生成し、そうでない場合には既存のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐを生成する。
【００６４】
制御モジュール１０４０は、ステーション１００内の他のモジュールの動作を制御するが、中央処理ユニット（ＣＰＵ）、マイクロコンピュータ等で具現することができる。
【００６５】
本実施形態で用いられる「モジュール」という用語は、ソフトウェアまたはＦＰＧＡまたはＡＳＩＣのようなハードウェア構成要素を意味し、モジュールはある役割を行う。ところが、モジュールは、ソフトウェアまたはハードウェアに限定される意味ではない。モジュールは、アドレッシングできる格納媒体にあるように構成することもでき、１つまたはそれ以上のプロセッサを再生させるように構成することもできる。したがって、一例としてモジュールはソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素およびタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、および変数を含む。構成要素とモジュールの中で提供されている機能は、さらに小さい数の構成要素およびモジュールに結合したり、追加的な構成要素とモジュールにさらに分離したりすることができる。それだけでなく、構成要素およびモジュールは通信システム内における１つまたはそれ以上のコンピュータを実行するように具現することもできる。
【００６６】
以上で説明した実施形態は、本発明を限定するものでなく、例示的なものであると判断しなければならない。したがって、本明細書に開示された実施形態と図面によって本発明は限定されず、当該発明の技術思想の範囲内で当業者であれば多様に変形することができるということは明らかである。
【図面の簡単な説明】
【００６７】
【図１】ＩＥＥＥ  ８０２．１１ｅ標準によるブロックＡＣＫメカニズムを示すシーケンス図である。
【図２】ＩＥＥＥ  ８０２．１１ｅ標準によるブロックＡＣＫ要請フレームの構造を示す図である。
【図３】ＩＥＥＥ  ８０２．１１ｅ標準によるブロックＡＣＫフレームの構造を示す図である。
【図４】本発明の一実施形態に係るブロックＡＣＫフレームの構造を示す図である。
【図５】本発明の一実施形態に係るブロックＡＣＫフレームのビットマップ構造を示す図である。
【図６】本発明の一実施形態に係るブロックＡＣＫ要請フレームの構造を示す図である。
【図７】本発明の一実施形態に係るブロックＡＣＫフレームの伝送過程を示す図である。
【図８】本発明の他の実施形態に係るブロックＡＣＫフレームの伝送過程を示す図である。
【図９】本発明の他の実施形態に係るブロックＡＣＫフレームのビットマップ構造を示す図である。
【図１０】本発明の一実施形態に係るステーションの構造を示すブロック図である。
【図１】
2008511243.tif 000003
【図２】
2008511243.tif 000004
【図３】
2008511243.tif 000005
【図４】
2008511243.tif 000006
【図５】
2008511243.tif 000007
【図６】
2008511243.tif 000008
【図７】
2008511243.tif 000009
【図８】
2008511243.tif 000010
【図９】
2008511243.tif 000011
【図１０】
2008511243.tif 000012
【国際調査報告】
2008511243.tif 000013
2008511243.tif 000014