(57)【要約】  本発明は、無線環境での通信でより効率的なバーストＡＣＫ方法及び装置に関する。  本発明によるＡＣＫフレーム伝送方法は、送信デバイスからフレームを受信し、該受信されたフレームの識別情報を保存する段階と、前記保存された識別情報を用いて前記受信された各フレームに対するビット対の集合を記録して第１フィールドを生成させる段階と、生成された第１フィールドを含んでＡＣＫフレームを生成させる段階と、生成されたＡＣＫフレームを送信デバイスに伝送する段階とを含み、前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第１ビットと、第１ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第２ビットとで構成される。
2008509622.tif 000002
【特許請求の範囲】
【請求項１】
送信デバイスから複数のフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送方法であって、
（ａ）前記送信デバイスからフレームを受信し、前記受信されたフレームの識別情報を保存する段階と、
（ｂ）前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録することで第１フィールドを生成させる段階と、
（ｃ）前記生成された第１フィールドを含んでＡＣＫフレームを生成させる段階と、
（ｄ）前記生成されたＡＣＫフレームを前記送信デバイスに伝送する段階と、を含み、
前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第１ビットと、
前記第１ビットが、該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第２ビットで構成されることを特徴とするＡＣＫフレーム伝送方法。
【請求項２】
前記（ｃ）段階は、
（ｃ１）前記識別情報のうち最初の識別情報を記録する第２フィールドを生成させる段階を含むことを特徴とする請求項１に記載のＡＣＫフレーム伝送方法。
【請求項３】
前記（ｃ）段階は、
（ｃ２）前記第１フィールドがバイト単位にならない場合には、所定のダミービットを追加してバイト単位に作る段階をさらに含むことを特徴とする請求項２に記載のＡＣＫフレーム伝送方法。
【請求項４】
前記識別情報は、
前記受信されたフレームのＭＳＤＵ  ｎｕｍｂｅｒ及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒを含むことを特徴とする請求項３に記載のＡＣＫフレーム伝送方法。
【請求項５】
前記最初の識別情報は、前記ＭＳＤＵ  ｎｕｍｂｅｒの最も先立つ識別情報のうちＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒの最も先立つ識別情報であることを特徴とする請求項４に記載のＡＣＫフレーム伝送方法。
【請求項６】
前記第１ビットは、該当フレームが正常的に受信された場合に１と、それ以外には０と記録され、
前記第２ビットは、前記第１ビットが該当フレーム一つに対する受信確認を表わすものであれば１と、それ以外には０と記録されると仮定する時、前記（ｂ）段階は、
（ｂ１）特定ＭＳＤＵ順番に対してＭＳＤＵ  ｎｕｍｂｅｒが存在しなければ、ビット対を‘０１’と記録し、存在すれば、前記順番のＭＳＤＵがフラグメントされたか否かを判断する段階と、
（ｂ２）前記ＭＳＤＵがフラグメントされていない場合には、ビット対を‘１Ｘ’と記録する段階を含み、
前記Ｘは、１または０のうち何れか一つの値であることを特徴とする請求項１に記載のＡＣＫフレーム伝送方法。
【請求項７】
前記ＭＳＤＵがフラグメントされた場合に前記（ｂ）段階は、
（ｂ３）最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒより小さなＦｒａｇｍｅｎｔ順番のそれぞれに対して順次にビット対を記録する段階と、
（ｂ４）最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒが最終Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒと同じであれば、ビット対を‘１Ｘ’と記録する段階と、をさらに含むことを特徴とする請求項６に記載のＡＣＫフレーム伝送方法。
【請求項８】
前記最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒが最終Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒと同じではなければ、ビット対を‘１０’と記録し、相次ぐビット対を‘０１’と記録する段階をさらに含むことを特徴とする請求項７に記載のＡＣＫフレーム伝送方法。
【請求項９】
前記（ｂ）段階は、
前記送信デバイスからＡＣＫフレーム伝送要請を受けた場合に実行されることを特徴とする請求項１に記載のＡＣＫフレーム伝送方法。
【請求項１０】
送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送方法であって、
（ａ）前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、
（ｂ）前記保存された情報を用いて前記受信されたデータフレームのそれぞれに対するビット対の集合を記録する段階であって、前記ビット対は該当フレームが正常的に伝送されたか否かを確認する第１ビットと、前記第１ビットが表わすデータフレームの範囲を表わす第２ビットとで構成される、段階と、
（ｃ）前記記録されたビット対の集合を含むＡＣＫフレームを生成させる段階と、
（ｄ）前記生成されたＡＣＫフレームを前記送信ステーションに伝送する段階と、を含むことを特徴とするＡＣＫフレーム伝送方法。
【請求項１１】
前記ビット対の集合は、可変大きさを有することを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項１２】
前記データフレームの範囲は、
一つのフラグメントを表わす範囲と、または一つのＭＳＤＵに属する現在フラグメント以後のすべてのフラグメントを表わす範囲のうち一つであることを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項１３】
前記（ｃ）段階は、
前記ビット対の集合で伝送確認を始めようとするフレームの識別番号と、伝送確認を始めようとするフレームのフラグメント番号とを記録する段階を含むことを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項１４】
前記（ｃ）段階は、
前記ビット対の集合がＯｃｔｅｔ単位にならない場合には、Ｏｃｔｅｔ単位になるようにダミービットを追加する段階をさらに含むことを特徴とする請求項１３に記載のＡＣＫフレーム伝送方法。
【請求項１５】
前記識別番号は、
前記受信されたデータフレームが属するＭＳＤＵのシーケンス番号であることを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項１６】
前記最終フラグメント番号は、前記受信されたデータフレームのＳｕｂｔｙｐｅフィールドに記録されることを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項１７】
前記第１ビットは、
該当フレームが正常的に受信された場合に１と、それ以外には０と記録されることを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項１８】
前記第２ビットは、
前記第１ビットが該当フレーム一つに対する伝送確認を表わすものであれば１と、それ以外には０と記録されることを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項１９】
前記（ｂ）段階は、
前記送信ステーションからＡＣＫフレーム伝送要請を受けた場合に実行されることを特徴とする請求項１０に記載のＡＣＫフレーム伝送方法。
【請求項２０】
送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送方法であって、
（ａ）前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、
（ｂ）前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する段階と、
（ｃ）前記記録されたビットを含むＡＣＫフレームを生成させる段階と、
（ｄ）前記生成されたＡＣＫフレームを前記送信ステーションに伝送する段階と、を含むことを特徴とするＡＣＫフレーム伝送方法。
【請求項２１】
前記ビットの集合は、可変大きさを有することを特徴とする請求項２０に記載のＡＣＫフレーム伝送方法。
【請求項２２】
前記（ｃ）段階は、
前記ビット対の集合で伝送確認を始めようとするフレームの識別番号と、伝送確認を始めようとするフレームのフラグメント番号とを記録する段階を含むことを特徴とする請求項２０に記載のＡＣＫフレーム伝送方法。
【請求項２３】
前記識別番号は、
前記受信されたデータフレームのシーケンス番号であることを特徴とする請求項２０に記載のＡＣＫフレーム伝送方法。
【請求項２４】
前記ビットは、
該当フレームが正常的に受信された場合に１と、それ以外には０と記録されることを特徴とする請求項２０に記載のＡＣＫフレーム伝送方法。
【請求項２５】
前記（ｂ）段階は、
前記送信ステーションからＡＣＫフレーム伝送要請を受けた場合に実行されることを特徴とする請求項２０に記載のＡＣＫフレーム伝送方法。
【請求項２６】
送信デバイスから複数のフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送装置であって、
前記送信デバイスからフレームを受信する第１手段と、
前記受信されたフレームの識別情報を保存する第２手段と、
前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録することで第１フィールドを生成させ、前記生成された第１フィールドを含んでＡＣＫフレームを生成させる第３手段と、
前記生成されたＡＣＫフレームを前記送信デバイスに伝送する第４手段と、を含み、
前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第１ビットと、
前記第１ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第２ビットで構成されることを特徴とするＡＣＫフレーム伝送装置。
【請求項２７】
前記第３手段は、
前記識別情報のうち最初の識別情報を記録する第２フィールドを生成させることを特徴とする請求項２６に記載のＡＣＫフレーム伝送装置。
【請求項２８】
前記第３手段は、
前記第１フィールドがバイト単位にならない場合には、所定のダミービットを追加してバイト単位に作ることを特徴とする請求項２７に記載のＡＣＫフレーム伝送装置。
【請求項２９】
前記識別情報は、
前記受信されたフレームのＭＳＤＵ  ｎｕｍｂｅｒ及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒを含むことを特徴とする請求項２８に記載のＡＣＫフレーム伝送装置。
【請求項３０】
前記最初の識別情報は、前記ＭＳＤＵ  ｎｕｍｂｅｒの最も先立つ識別情報のうちＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒの最も先立つ識別情報であることを特徴とする請求項２９に記載のＡＣＫフレーム伝送装置。
【請求項３１】
前記第３手段は、
前記送信デバイスからＡＣＫフレーム伝送要請を受けることによって動作することを特徴とする請求項２６に記載のＡＣＫフレーム伝送装置。
【請求項３２】
送信ステーションから少なくとも一つ以上のフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送装置であって、
前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、
前記保存された情報を用いて前記受信されたデータフレームそれぞれに対するビット対の集合を記録する手段であって、前記ビット対は該当フレームが正常的に伝送されたか否かを確認する第１ビットと、前記第１ビットが表わすデータフレームの範囲を表わす第２ビットで構成される、手段と、
前記記録されたビット対の集合を含むＡＣＫフレームを生成させる手段と、
前記生成されたＡＣＫフレームを前記送信ステーションに伝送する手段と、を含むことを特徴とするＡＣＫフレーム伝送装置。
【請求項３３】
送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送装置であって、
前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、
前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する手段と、
前記記録されたビットを含むＡＣＫフレームを生成させる手段と、
前記生成されたＡＣＫフレームを前記送信ステーションに伝送する手段と、を含むことを特徴とするＡＣＫフレーム伝送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信方法に係り、より詳細には、より効率的なバーストＡＣＫ（ｂｕｒｓｔ  ＡＣＫ）を利用した無線通信方法に関する。
【背景技術】
【０００２】
ネットワークが無線化されていて大容量のマルチメディアデータ伝送要求の増大によって無線ネットワーク環境での効果的な伝送法についての研究が要求されている。与えられた無線資源を多くのデバイスが共有して使う無線ネットワークの特性上、競争が増加すれば通信中に衝突によって貴重な無線資源を浪費する可能性が大きい。このような衝突を減らして安定的にデータを送受信させるために、無線ＬＡＮ（ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）環境では競争基盤のＤＣＦ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）または無競争方式のＰＣＦ（Ｐｏｉｎｔ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）を使っており、無線ＰＡＮ（ｗｉｒｅｌｅｓｓ  Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）環境ではチャンネル時間割当て（ｃｈａｎｎｅｌ  ｔｉｍｅ  ａｌｌｏｃａｔｉｏｎ）という時分割方式を使っている。
【０００３】
このような方法にして、無線環境で衝突なしに安定的にデータを送受信できるが、一つのデバイスが通信する間には同じ電波範囲内に存在する他のデバイスは待機するしかないので、デバイスの数が増えれば伝送率は相当減少する。したがって、無線ネットワーク環境で安定的な通信を保障しながらも同時にデータ伝送率を向上させることが重要な争点になっている。
【０００４】
伝送率を向上させるためには、主に伝送するデータから不要なオーバーヘッドを減らす方法、またはデバイスの間に時間割当てをより効率的にする方法などがある。本発明はこの中でも、無線ネットワーク環境（無線ＬＡＮ、無線ＰＡＮなど）で頻繁に使われるＡＣＫフレーム（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ  ｆｒａｍｅ）の構造をより効率的に簡略化してＡＣＫフレームによるトラフィック（ｔｒａｆｆｉｃ）を減少させるためのことである。
【０００５】
一般的に、データを伝送するデバイス（以下、送信デバイスと言う）がデータを受信するデバイス（以下、受信者デバイス）にデータフレームを伝送すれば、受信デバイスが前記データフレームを正しく受信した場合には、これを知らせるＡＣＫフレームを前記送信デバイスに伝送する。
【０００６】
このようなＡＣＫフレームには一つのフレームを受信する度に、正しく受信したという事実を直ちに知らせるＡＣＫフレームと、一定回数の間に複数のフレームを受信し、その複数のフレーム全体に対して一度に受信如何を知らせるＡＣＫフレームがある。前者のＡＣＫ  フレームを即時ＡＣＫフレーム（Ｉｍｍｅｄｉａｔｅ  ＡＣＫ  ｆｒａｍｅ）に、後者のＡＣＫフレームをバーストＡＣＫフレーム（Ｂｕｒｓｔ  ＡＣＫ  ｆｒａｍｅ）に定義できるが、本発明はこの中でもバーストＡＣＫフレームの構造改善に主眼点を置いている。
【０００７】
一般的なバーストＡＣＫフレームは、図１に表わす方式のように伝送される。送信デバイスは、ｎ個のデータフレームを受信デバイスに伝送すれば、受信デバイスはｎ個のデータフレームに対するＡＣＫフレームを一度に送ることで、その度にＡＣＫフレームをいちいち送ることに比べてトラフィックを減少させうる。
【０００８】
実際に、このようなバーストＡＣＫフレームの概念として、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ）８０２．１５．３無線ＰＡＮ標準では遅延ＡＣＫフレーム（Ｄｅｌａｙｅｄ  ＡＣＫ  ｆｒａｍｅ）を使い、ＩＥＥＥ８０２．１１ｅ無線ＬＡＮ標準ではブロックＡＣＫフレーム（Ｂｌｏｃｋ  ＡＣＫ  ｆｒａｍｅ）を使う。
【０００９】
図２は、ＩＥＥＥ８０２．１５．３標準による遅延ＡＣＫフレーム１０の構成を表わしたものである。ＩＥＥＥ８０２．１５．３でフレームフォーマットは、右側から表示することが一般的なので右側端にＭＡＣ  ｈｅａｄｅｒ１１が表示されている。遅延ＡＣＫフレーム１０は、ＭＡＣ  ｈｅａｄｅｒ１１と、遅延ＡＣＫを待機しているフレームのうち最大ＭＡＣフレームサイズを有するフレームの数を表わすＭａｘ  ｂｕｒｓｔフィールド１２と、遅延ＡＣＫで一度に処理できる最大フレーム数を表わすＭａｘ  ｆｒａｍｅｓフィールド１３０と、ｎ個のＭＰＤＵ（ＭＡＣ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）ＩＤ  ｂｌｏｃｋフィールド１５、１６などと、エラーチェックサム（ｃｈｅｃｋｓｕｍ）を計算するためのＦＣＳフィールド１７とで構成されうる。
【００１０】
ＭＰＤＵ  ＩＤ  ｂｌｏｃｋフィールド１５、１６、などのそれぞれは、また送信デバイスのＭＡＣ端で上位層（例えば、ＬＬＣ（Ｌｏｇｉｃａｌ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層）からＭＳＤＵ（ＭＡＣ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）を受信する度に一つずつ増加するＭＳＤＵ番号（すなわち、ＭＳＤＵの識別番号）が記録されるＭＳＤＵ  ｎｕｍｂｅｒフィールド１８と、ＭＳＤＵがフラグメント化されて送信される時、フラグメント化順序が記録されるＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１９とで構成される。受信デバイスは、自身が受信したデータに対してＭＳＤＵ  ｎｕｍｂｅｒと、Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒを記録して送信デバイスに伝送することによって、送信デバイスは伝送したデータのうちどのデータ（ＭＳＤＵ自体、またはＭＳＤＵの一部フラグメント）が正しく伝送されなかったのかが分かる。以後送信デバイスは、正しく伝送されていないデータのみを受信デバイスに再伝送する。
【００１１】
図２に表わしたように、ＩＥＥＥ８０２．１５．３標準ではＭＳＤＵ  ｎｕｍｂｅｒフィールド１８には９ビットが割り当てられ、Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１９には７ビットが割り当てられるので、一つのＭＰＤＵ  ＩＤ  ｂｌｏｃｋフィールド１５、１６、などは２バイト（２ｏｃｔｅｔ）が割り当てられる。
【００１２】
図３は、ＩＥＥＥ８０２．１１ｅ標準によるブロックＡＣＫフレーム２０の構成を表わしたものである。ブロックＡＣＫフレーム２０は、ＭＡＣ  ｈｅａｄｅｒ２１と、ブロックＡＣＫフレームの動作を制御するためのＢＡ  Ｃｏｎｔｒｏｌフィールド２２と、最初のＭＰＤＵのｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒとｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒが記録されるＢｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド２３と、以後のＭＰＤＵに対する‘受信確認情報’（特定データを正しく受信したのかを表わす情報）が順に記録されるＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド２４と、エラーチェックサムを計算するためのＦＣＳフィールド２５とで構成されうる。
【００１３】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド２４には、１２８バイトが割り当てられるので、一つのＭＳＤＵに対して２バイトずつ割り当てれば、最大、６４個のＭＳＤＵに対する受信確認情報が記録されうる。このように、一つのＭＳＤＵに対して２バイトが割り当てられるのは、ＩＥＥＥ８０２．１１ｅで一つのＭＳＤＵは、最大１６個まで断片化（ｆｒａｇｍｅｎｔａｔｉｏｎ）されうるので、最大フラグメント化個数ほどのビット数（１６×１ビット）、すなわち、２バイトが割り当てられたものである。したがって、実際に断片化されないか、１６より小さな数ほど断片化がなされた場合にも、２バイトが一律的に割り当てられるので、このように一つのビットで受信確認情報を表わすことは効率的ではない。
【００１４】
図２または図３に表わしたように、一つのＭＳＤＵを表現するが、２バイトを使うとすれば、バーストＡＣＫフレームの大きさが必要以上に大きくなる問題がある。もし、ｎ個のデータを伝送し、これに対するバーストＡＣＫフレームを受信するとすれば、バーストＡＣＫフレームのペイロード（ｐａｙｌｏａｄ）は２ｎバイト以上になる。したがって、データの伝送回数が増加するにつれて、バーストＡＣＫフレームサイズも大きくなって無線ネットワーク環境に不要なトラフィックを誘発する。
【００１５】
したがって、既存のバーストＡＣＫフレームの機能をそのまま実行しながら、より小さな大きさを有するバーストＡＣＫフレームを開発してＡＣＫフレームによるトラフィックを減少させる必要がある。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明は、前記問題点を考慮して創案されたものであって、ＡＣＫフレームのオーバーヘッド（ｏｖｅｒｈｅａｄ）を減少させる方法を提供することを目的とする。
【００１７】
また、本発明は、一つのＭＳＤＵに対して２ビットで受信確認情報を表示できる方法を提供することを目的とする。
【課題を解決するための手段】
【００１８】
前記目的を果たすために、送信デバイスから複数のフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送方法であって、（ａ）前記送信デバイスからフレームを受信し、前記受信されたフレームの識別情報を保存する段階と、（ｂ）前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録して第１フィールドを生成させる段階と、（ｃ）前記生成されたフィールドを含んでＡＣＫフレームを生成させる段階と、（ｄ）前記生成されたＡＣＫフレームを前記送信デバイスに伝送する段階と、を含み、前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第１ビットと、前記第１ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第２ビットとで構成される。
【００１９】
前記目的を果たすために、送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送方法であって、（ａ）前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、（ｂ）前記保存された情報を用いて前記受信されたデータフレームそれぞれに対するビット対の集合を記録する段階であって、前記ビット対は、該当フレームが正常的に伝送されたか否かを確認する第１ビットと、前記第１ビットが表わすデータフレームの範囲を表わす第２ビットとで構成される、前記段階と、（ｃ）前記記録されたビット対の集合を含むＡＣＫフレームを生成させる段階と、（ｄ）前記生成されたＡＣＫフレームを前記送信ステーションに伝送する段階と、を含む。
【００２０】
前記目的を果たすために、送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送方法であって、（ａ）前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、（ｂ）前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する段階と、（ｃ）前記記録されたビットを含むＡＣＫフレームを生成させる段階と（ｄ）前記生成されたＡＣＫフレームを前記送信ステーションに伝送する段階と、を含む。
【００２１】
前記目的を果たすために、送信デバイスから複数のフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送装置であって、前記送信デバイスからフレームを受信する第１手段と、前記受信されたフレームの識別情報を保存する第２手段と、前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録して第１フィールドを生成させ、前記生成されたフィールドを含んでＡＣＫフレームを生成させる第３手段と、前記生成されたＡＣＫフレームを前記送信デバイスに伝送する第４手段と、を含み、前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第１ビットと、前記第１ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第２ビットとで構成される。
【００２２】
前記目的を果たすために、送信ステーションから少なくとも一つ以上のフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送装置であって、前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、前記保存された情報を用いて前記受信されたデータフレームそれぞれに対するビット対の集合を記録する手段であって、前記ビット対は、該当フレームが正常的に伝送されたか否かを確認する第１ビットと、前記第１ビットが表わすデータフレームの範囲を表わす第２ビットとで構成される、前記手段と、前記記録されたビット対の集合を含むＡＣＫフレームを生成させる手段と、前記生成されたＡＣＫフレームを前記送信ステーションに伝送する手段と、を含む。
【００２３】
前記目的を果たすために、送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのＡＣＫフレームとして確認応答を行うＡＣＫフレーム伝送装置であって、前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する手段と、前記記録されたビットを含むＡＣＫフレームを生成させる手段と、前記生成されたＡＣＫフレームを前記送信ステーションに伝送する手段と、を含む。
【発明の効果】
【００２４】
本発明によれば、バーストＡＣＫフレームまたはブロックＡＣＫフレームを伝送するにおいてオーバーヘッドを節減する。
【００２５】
また、本発明によれば、前記ＡＣＫフレームのオーバーヘッド節減によって無線ネットワーク全体で総データ伝送率を向上させる。
【発明を実施するための最良の形態】
【００２６】
以下、添付された図面を参照して、本発明の望ましい実施形態を詳しく説明する。本発明の利点及び特徴、そしてそれらの達成方法は、添付図面と共に詳細に後述されている実施形態を参照すれば、明確になる。しかし、本発明は、以下で開示される実施形態に限定されず、相異なる多様な形態で具現でき、単に本実施形態は本発明の開示を完全にし、当業者に発明の範ちゅうを完全に知らせるために提供され、本発明は特許請求の範囲によってのみ定義される。明細書全体にわたって同一参照符号は、同一構成要素を指称する。
【００２７】
本発明で提案するバーストＡＣＫフレームに関する実施形態は、大きくＩＥＥＥ８０２．１５．３標準による遅延ＡＣＫフレームを改善した実施形態（以下、第１実施形態と言う）と、ＩＥＥＥ８０２．１１系列標準によるブロックＡＣＫフレームを改善した実施形態（以下、第２実施形態と言う）に分けられうる。
【実施例１】
【００２８】
図４は、本発明の一実施形態によるバーストＡＣＫフレーム１００の構成を表わした図面である。バーストＡＣＫフレーム１００は、ＭＡＣ  ｈｅａｄｅｒ１１０とペイロード領域１２０、１３０、１４０とで構成されうる。ＭＡＣ  ｈｅａｄｅｒ１１０は、図５のように従来のＩＥＥＥ８０２．１５．３標準のＭＡＣ  ｈｅａｄｅｒと同一の構成を有しうる。
【００２９】
ペイロード領域は、ＭＰＤＵ  ＩＤフィールド１２０と、Ｂｉｔｍａｐフィールド１３０と、Ｐａｄフィールド１４０を含んで構成されうる。ＭＰＤＵ  ＩＤフィールド１２０は、ＡＣＫ応答を行う対象になるフレーム（以下‘対象フレーム’と定義する）のうち最初のフレームの識別情報が記録されるが、これはまたＭＳＤＵ  ｎｕｍｂｅｒフィールド１２１と、Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１２２とに分けられうる。本発明によるバーストＡＣＫフレーム１００は、受信されたフレームだけではなく、受信されていないフレームを含んだ全体伝送フレームに受信如何を応答するので、前記対象フレームとは、一定期間内の全体伝送フレーム（ＡＣＫを要する伝送フレームに限定される）を意味する。
【００３０】
ＭＳＤＵ  ｎｕｍｂｅｒフィールド１２１には、対象フレームのうち最初のフレームのＭＳＤＵ  ｎｕｍｂｅｒが記録され、Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１２２には、対象フレームのうち最初のフレームのＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒが記録される。ＭＳＤＵ  ｎｕｍｂｅｒと、Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒは受信される対象フレームのＭＡＣヘッダを見れば分かる。
【００３１】
Ｂｉｔｍａｐフィールド１３０には、対象フレームに対するＡＣＫビットとＴｙｐｅビットの対（以下、ビット対と言う）が順に記録されるが、前記ビット対の個数（ｍ）は最小である場合、総ＭＳＤＵの個数と同じであり、最大である場合、総フラグメントの個数と同じである。
【００３２】
周知の如く、対象フレームは断片化がなされていない場合には、一つのＭＳＤＵからなり、断片化がなされた場合には、ＭＳＤＵのうち一部フラグメントからなりうる。
【００３３】
Ｂｉｔｍａｐフィールド（１３０）の中で、ＡＣＫビットには該当フレームが正常的に受信されたか否かを確認するビットが記録されるが、正常的に受信された場合には１と、そうではない場合には０と記録されうる。そして、Ｔｙｐｅビットには、前記ＡＣＫビットが該当フレーム（ＭＳＤＵまたはフラグメント）に対する受信確認を表わすものか（前者）、ＭＳＤＵ内で現在フラグメント以後のすべてのフラグメントに対する受信確認を表わすものか（後者）を区別するビット情報が記録される。Ｔｙｐｅビットは、前者の場合０と、後者の場合１と記録されうる。
【００３４】
Ｐａｄフィールド１４０は、可変ビットとしてすべてダミービット（例：０）で満たされる。このフィールド１４０は、Ｂｉｔｍａｐフィールド１３０がビット単位なので所定個数のダミービット（ｄｕｍｍｙ  ｂｉｔｓ）、例えば、所定個数の０を満たしてバイトないしオクテット（ｏｃｔｅｔ）単位に作るために使われる。したがって、Ｂｉｔｍａｐフィールド１３０とＰａｄフィールド１４０との大きさを合わせれば、いつもバイト単位になる。しかし、Ｐａｄフィールド１４０は、本発明によるプロトコルを定義するための必須項目ではないので省略されることもある。
【００３５】
以下、図６ないし図１０は、さまざまな実施形態によってバーストＡＣＫフレーム１００が如何に決定されるかを説明するための図面である。ここで、［Ａ：Ｂ］は、フレームを識別する表示であって、Ａは送信デバイスが伝送したＭＳＤＵ  ｎｕｍｂｅｒに付与した順番（以下、ＭＳＤＵ順番と言う）を、ＢはＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒ（０から開始）を意味する。例として、送信デバイスが、ＭＳＤＵ  ｎｕｍｂｅｒが１２３４から１２３であるフレームを伝送したとすれば、それぞれ順に１から４までＭＳＤＵ順番が与えられる。このようなＭＳＤＵ順番は、送信デバイスが伝送したＭＳＤＵ  ｎｕｍｂｅｒを基準とすることであり、受信デバイスが受信して保存したＭＳＤＵ  ｎｕｍｂｅｒを基準とすることではない。もし、送信デバイスは、ＭＳＤＵ  ｎｕｍｂｅｒが１２３４から１２３７であるフレームを伝送したが、受信デバイスは１２３５、及び１２３７であるフレームのみを受信したとしても、ＭＳＤＵ順番は１２３４から１２３７まで全体に対して順次に与えられる。
【００３６】
図６は、［１：０］、［２：０］、［３：０］、［４：０］をすべて正常的に受信した場合にバーストＡＣＫフレーム１００の構造を表したもので断片化が全然生じない場合である。ＭＰＤＵ  ＩＤフィールド１２０には、［１：０］のＭＳＤＵ  ｎｕｍｂｅｒ（＝１）及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒ（＝０）が記録される。そして、Ｂｉｔｍａｐフィールド１３０には、対象フレームに対するＡＣＫビットとＴｙｐｅビットとからなるビット対が順に記録される。ところが、Ｂｉｔｍａｐフィールド１３０のみでバイト単位になるので、別途のＰａｄフィールドは不要である。ここで、順序と言うことは、ＭＳＤＵ  ｎｕｍｂｅｒ及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒによる順序であり、フレームを受信した順序ではないことを明確に明らかにする。なぜならば、先に伝送したフレームが如何なる理由で後に受信されることもあるためである。
【００３７】
［１：０］、［２：０］、［３：０］、［４：０］は、すべて正常的に受信されたので、ビット対の最初のビットは１で満される。二番目のビット対（Ｘに表示される）は０または１のうちいずれの値で満たしても良い。そのフレームで該当ＭＳＤＵが完結されるために１と表示することもでき、一方、一つのフレームに対するＡＣＫ如何表示でもあるために０と表示することもできる。さらに、いずれのＭＳＤＵが断片化されたのかは送信デバイスと受信デバイスとがそれに関する情報を共有することで互いに分かっているために混同を誘発する可能性はない。しかし、一応一つのＭＳＤＵで完結されたという意味を明確にする側面で１で満たすことがより望ましい。以下、Ｘは本実施形態と同じ意味に解釈される。
【００３８】
図７は、［１：０］、［２：０］、［２：１］、［３：０］、［４：０］をすべて正常的に受信した場合にバーストＡＣＫフレーム１００の構造を表したもので二番目のＭＳＤＵで断片化が生じた場合である。図６と同様に、ＭＰＤＵ  ＩＤフィールド１２０には、［１：０］のＭＳＤＵ  ｎｕｍｂｅｒ（＝１）及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒ（＝０）が記録される。そして、Ｂｉｔｍａｐフィールド１３０には、対象フレームに対するＡＣＫビットとＴｙｐｅビットとからなるビット対が順に記録される。
［１：０］、［２：０］、［２：１］、［３：０］、［４：０］は、すべて正常的に受信されたのでビット対の最初のビットは１で満たされて、このうち［１：０］、［３：０］、［４：０］は、完結されたフレームなので二番目のビットはＸで満たされる。但し、［２：０］以後に同じＭＳＤＵ  ｎｕｍｂｅｒ及び他のＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒを有する［２：１］が存在するので、［２：０］に対するビット対のうち二番目のビットは１と表示して［２：０］以後のすべてのフラグメントが正常的に受信されることを表示する。
【００３９】
このようにフラグメントになったＭＳＤＵに対して一度に表示することが望ましいが、同一の状況でバーストＡＣＫフレーム１００を図８のようにＭＳＤＵがフラグメントになった場合には、各フラグメント別に表示する方法も考えられる。
【００４０】
図９は、送信デバイスが、［１：０］、［２：０］、［２：１］、［２：２］、［３：０］を伝送したが、受信デバイスでは［１：０］、［２：０］、［３：０］のみを正常的に受信した場合にバーストＡＣＫフレーム１００の構造を表わしたものである。ここで、二番目のＭＳＤＵは、３個のフラグメントに分けられたことが分かる。ＭＰＤＵ  ＩＤフィールド１２０には、［１：０］のＭＳＤＵ  ｎｕｍｂｅｒ（＝１）及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒ（＝０）が記録される。そして、Ｂｉｔｍａｐフィールド１３０には、送信デバイスが伝送したすべての対象フレームに対してＡＣＫビットとＴｙｐｅビットとからなるビット対が順に記録される。
【００４１】
［１：０］、［３：０］は、すべて正常的に受信されたのでビット対の最初のビットは１で満たされ、完結されたフレームなので二番目のビットはＸで満たされる。ところが、［２：０］は正常的に受信されたが、その後のフラグメントが存在するので該当フレーム、すなわち、該当フラグメントに対する受信確認のみを行うために該当位置に‘１０’が記録される。しかし、［２：１］及び［２：２］は正常的に受信されることができなかったので、この二つのフレームを代表して［２：１］の位置に該当するビット対の最初のビットは０と表示される。そして、二番目のビットは１として表示されるが、これは最初のビットが該当位置の以後、すなわち、［２：１］及び［２：２］に対するＡＣＫビットであることを意味する。
【００４２】
ところが、受信デバイスが［２：０］のみを受信したが、［２：１］及び［２：２］の存否が如何に分かるかが問題になる。しかし、これは［２：０］のＭＡＣヘッダを見れば分かる。これについてのより詳しい説明は、図１３の説明で後述する。
【００４３】
図１０は、送信デバイスが、［１：０］、［２：０］、［２：１］、［２：２］、［３：０］を伝送したが、受信デバイスでは［１：０］、［３：０］のみを正常的に受信した場合に、バーストＡＣＫフレーム１００の構造を表わしたものである。ここで、受信デバイスは、二番目のＭＳＤＵに関するデータを一つも受信することができなかったので、それが３個のフラグメントからなされていることは分からない。しかし、［１：０］、及び［３：０］を受信したので、２番目のＭＳＤＵに対するフレームが伝送されなかったということが分かる。
【００４４】
ＭＰＤＵ  ＩＤフィールド１２０には、［１：０］のＭＳＤＵ  ｎｕｍｂｅｒ（＝１）及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒ（＝０）が記録される。そして、Ｂｉｔｍａｐフィールド１３０には、送信デバイスが伝送したすべての対象フレームに対してＡＣＫビットとＴｙｐｅビットとからなるビット対が順に記録される。
【００４５】
［１：０］、［３：０］は、すべて正常的に受信されたので、ビット対の最初のビットは１で満たされ、完結されたフレームなので二番目のビットはＸで満たされる。ところが、ＭＳＤＵが１であるフレームと３であるフレームとが受信されたことを見れば、ＭＳＤＵが２であるフレームも送信されたがエラーによって受信されることができなかったことが分かる。このように、二番目のＭＳＤＵに対するフレームは全然受信することができなかったが、［２：０］の位置に最初のビットを０で満たし、二番目のビットを１で満たすことによって、［２：０］以後のすべてのフラグメントは受信されることができなかったことを表示できる。
【００４６】
図１１は、以上のようなバーストＡＣＫフレーム１００を伝送する、本発明の一実施形態による無線デバイス２００の構成を表わしたブロック図である。無線デバイス２００は、バーストＡＣＫ生成モジュール２１０と、ＭＡＣモジュール２２０と、上位層モジュール２３０と、ＰＨＹモジュール２４０と、メモリ２５０と、制御ユニット２６０とを含んで構成されうる。
【００４７】
バーストＡＣＫ生成モジュール２１０は、受信されるデータフレームのヘッダ情報から該当フレームの識別情報として、ＭＰＤＵ  ＩＤ情報を判読し、この情報を用いて本発明によるバーストＡＣＫフレーム１００のペイロードを生成させる。バーストＡＣＫ生成モジュール２１０は、また図１２のような詳細構造を有する。すなわち、バーストＡＣＫ生成モジュール２１０は、生成制御モジュール２１１と、ＭＰＤＵ  ＩＤ生成モジュール２１２と、ビットマップ生成モジュール２１３と、パッド生成モジュール２１４とを含んで構成されうる。
【００４８】
生成制御モジュール２１１は、特定送信デバイスから受信された所定個数のフレームに対するバーストＡＣＫフレーム１００を生成させるための条件（以下、‘ＡＣＫ生成条件’と言う）をチェックして、条件が完成されていない間には前記特定送信デバイスから受信されるフレームのＭＡＣヘッダに含まれるＭＰＤＵ  ＩＤ情報をＭＡＣモジュール２２０から受信してメモリ２５０に保存しておく。そして、条件が完成されれば、ＭＰＤＵ  ＩＤ生成モジュール２１２、ビットマップ生成モジュール２１３、及びパッド生成モジュール２１４をして前記保存されたＭＰＤＵ  ＩＤ情報を用いてバーストＡＣＫフレーム１００のペイロードを生成させる。
【００４９】
ここで、ＭＰＤＵ  ＩＤ情報は、受信されたフレームのＭＳＤＵに対する固有一連番号を表わす‘ＭＳＤＵ  ｎｕｍｂｅｒ’とフラグメントになった順序を表わす‘Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒ’とを含む。ＭＰＤＵ  ＩＤ情報は、図１のようなＩＥＥＥ８０２．１５．３標準によるＭＡＣ  Ｈｅａｄｅｒ１１０にも表われている。
【００５０】
図１３のＭＡＣ  Ｈｅａｄｅｒ１１０でＦｒａｇｍｅｎｔａｔｉｏｎ  Ｃｏｎｔｒｏｌフィールド１１２は、ＭＳＤＵ  ｎｕｍｂｅｒフィールド１１７と、Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１１８と、Ｌａｓｔ  ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１１９とに分けられる。したがって、Ｆｒａｇｍｅｎｔａｔｉｏｎ  Ｃｏｎｔｒｏｌフィールド１１２を読取ることでＭＳＤＵ  ＩＤ情報が分かる。但し、図１２とは異なって、フラグメントになったすべてのフレームには、Ｌａｓｔ  ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１１９に最後のフラグメントの番号が記録されるので、図９のような場合に［２：０］のみを受信しても［２：１］及び［２：２］が存在することが分かる。
【００５１】
再び図１２に戻って、生成制御モジュール２１１がチェックする条件は、送信デバイスが受信デバイスに対象フレームを伝送する時、ＭＡＣヘッダのうちバーストＡＣＫフレームを要請する一部ビット（以下、‘要請ビット’と言う）がＯＮになっているか否かを基準としてできる。すなわち、対象フレームを受信する度に該当フレームの‘要請ビット’の値を判読して、その値がＯＦＦを表わすビット（＝０）であれば、ＡＣＫ生成条件が満足していないと、その値がＯＮを表わすビット（＝１）であれば、ＡＣＫ生成条件が満足したと判断することである。
【００５２】
もし、送信デバイスが［１：０］、［２：０］、［３：０］を伝送し、［３：０］に要請ビットがＯＮに設定された場合に、受信デバイスが［１：０］、［２：０］のみを受信したとすれば、受信デバイスはＡＣＫ生成条件が満足していないので、バーストＡＣＫフレームを生成しない。その後、送信デバイスは、一定時間内にバーストＡＣＫフレームが受信されなければ、伝送エラーがあると見てまた要請ビットをＯＮに設定して［３：０］を伝送する。
【００５３】
以上では、ＡＣＫ生成条件を送信デバイスが決定するとしたが、これに限らず一定個数以上の対象フレームが受信されれば、ＡＣＫ生成条件が満足されることにする方法も可能である。
【００５４】
ＭＰＤＵ  ＩＤ生成モジュール２１２は、メモリ２５０に保存されたＭＳＤＵ  ＩＤ情報を用いて、ＭＰＤＵ  ＩＤフィールド１２０、すなわち、対象フレームのうち最初のフレームのＭＳＤＵ  ｎｕｍｂｅｒフィールド１２１と、対象フレームのうち最初のフレームのｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１２２を記録する。
【００５５】
ビットマップ生成モジュール２１３は、前記ＭＰＤＵ  ＩＤフィールド１２０に付け加えて対象フレームに対するビット対を順次に記録する。最初のビット（ＡＣＫビット）には、現在ビット対が表わすフレームが正常的に受信されたか否か（正常に受信されれば１、それとも０）を確認するビットが記録され、二番目のビット（Ｔｙｐｅビット）には前記最初のビットが該当フレームに対する受信確認を表わすもの（０に記録）なのか、一つのＭＳＤＵ内で現在フラグメント以後のすべてのフラグメントに対する受信確認を表わすもの（１に記録）なのかを区別するビット情報が記録される。
【００５６】
パッド生成モジュール２１４は、ビットマップの大きさがバイト単位にならない場合に、残りのビットを０で満たしてバイト単位にする。
【００５７】
また図１１を参照すれば、ＭＡＣモジュール２２０は、ＭＡＣ層（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌａｙｅｒ）での動作を管掌する。すなわち、上位層モジュール２３０からＭＳＤＵを伝達されてここに図１３のようなＭＡＣヘッダを付着し、その結果をＰＨＹモジュール２４０に伝達する。また、ＭＡＣモジュール２２０は、バーストＡＣＫ生成モジュール２１０からバーストＡＣＫフレームのペイロードを伝達され、同様にここにＭＡＣヘッダを付着してＰＨＹモジュール２４０に伝達する。
【００５８】
また、ＰＨＹモジュール２４０から他のデバイスから伝送されたフレームを受信すれば、ここでＭＡＣヘッダを判読した後、ＭＡＣヘッダを除去してその結果を上位層モジュール２３０に伝達する。そして、ＭＡＣヘッダのうち判読されるＭＰＤＵ  ＩＤ情報をバーストＡＣＫ生成モジュール２１０に伝達する。
【００５９】
上位層モジュール２３０は、ＭＳＤＵを生成させてＭＡＣモジュール２２０に伝達し、ＭＡＣモジュール２２０からＭＡＣヘッダが除去されたデータを伝達される。このような上位層モジュール２３０は、ＬＬＣ階（Ｌｏｇｉｃａｌ  Ｌｉｎｋ  Ｌａｙｅｒ）以上のネットワーク層を管掌する。
【００６０】
ＰＨＹモジュール２４０は、物理層（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ）での動作を管掌する。すなわち、ＭＡＣモジュール２２０からＭＰＤＵを伝達されてＰＰＤＵ（ＰＡＣＫｅｔ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を生成させ、これを含む無線信号を生成させて伝送する。また、無線媒体を通じて伝達される信号を受信して加工した後、これをＭＡＣモジュール２２０に伝達する。ＰＨＹモジュール２４０は、また細分化してベースバンドプロセッサ（ｂａｓｅ  ｂａｎｄ  ｐｒｏｃｅｓｓｏｒ）とＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）モジュールとに細分化されうる。
【００６１】
メモリ２５０は、受信されたフレームに対するＭＰＤＵ  ＩＤ情報を保存してからバーストＡＣＫ生成モジュール２１０の要請があれば、この情報を提供する。
【００６２】
制御ユニット２６０は、無線デバイス２００内の他のモジュールの動作を制御するが、中央処理ユニット（ＣＰＵ）、マイコン（Ｍｉｃｒｏｃｏｍｐｕｔｅｒ）などによって具現されうる。
【００６３】
図１４は、本発明の一実施形態によるバーストＡＣＫフレーム１００生成過程を表わしたフローチャートである。
【００６４】
まず、ＡＣＫ生成条件が完成される前まで（Ｓ２０のいいえ）、ＰＨＹモジュール２４０を通じて‘対象フレーム’を受信し（Ｓ１０）、生成制御モジュールは、前記受信される対象フレームのＭＰＤＵ  ＩＤ情報を保存する過程（Ｓ２５）を反復する。ＭＰＤＵ  ＩＤ情報には、該当対象フレームのＭＳＤＵ  ｎｕｍｂｅｒ及びＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒを含む。
【００６５】
もし、生成制御モジュール２１１は、  ＡＣＫ生成条件が完成されたか否かを判断して完成されれば（Ｓ２０のはい）、初めてバーストＡＣＫフレーム１００のペイロードを生成させるように制御する。前記ペイロードを生成させる過程は、Ｓ３０ないしＳ６９段階からなる。
【００６６】
まず、ＭＰＤＵ  ＩＤ生成モジュール２１２は、メモリ２５０に保存された対象フレームのうち最初フレームのＭＳＤＵ  ｎｕｍｂｅｒフィールド１２１とｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１２２とを記録することでＭＰＤＵ  ＩＤフィールド１２０を生成させる（Ｓ４０）。
【００６７】
ビットマップ生成モジュール２１３は、前記ＭＰＤＵ  ＩＤフィールド１２０に付け加えて対象フレームに対するビット対を順次に記録することでＢｉｔｍａｐフィールド１３０を生成させる（Ｓ５０）。Ｓ５０段階についてより詳しい過程は、図１５の説明から後述する。
【００６８】
前記生成されたＢｉｔｍａｐフィールド１３０の大きさがバイト単位である場合には（Ｓ６８のはい）、Ｐａｄフィールド１４０を生成させる必要がないが、そうではない場合には、所定のビットの連続された０値を有するＰａｄフィールド１４０を前記Ｂｉｔｍａｐフィールド１３０に連続して付け加える。前記連続された０値を有するビット数は、Ｂｉｔｍａｐフィールド１３０とＰａｄフィールド１４０とを合わせてバイト単位にする個数である。
【００６９】
ＭＡＣモジュール１２０は、Ｓ５０またはＳ６９で生成されたバーストＡＣＫフレーム１００のペイロードにＭＡＣヘッダを付着してバーストＡＣＫフレーム１００を生成させる（Ｓ７０）。そして、ＰＨＹモジュール１４０は、対象フレームを伝送したデバイスに生成されたバーストＡＣＫフレーム１００を無線媒体を通じて伝送する（Ｓ８０）。
【００７０】
図１５は、図１４のＳ５０段階をより詳しく表わしたフローチャートである。
【００７１】
まず、メモリ２５０に保存されたＭＳＤＵ  ｎｕｍｂｅｒに‘ＭＳＤＵ順番’を付与する（Ｓ５１）。例えば、保存されたＭＳＤＵ  ｎｕｍｂｅｒが１２３４から１２３７までとすれば、ＭＳＤＵ  ｎｕｍｂｅｒのＭＳＤＵ順番（ｋ）は順に１から４になる。もし、保存されたＭＳＤＵ  ｎｕｍｂｅｒが連続的ではない場合、例えば、１２３４、１２３６、１２３７である場合にも存在していない１２３５に対しても、すべて正しく受信された場合と同様に、ＭＳＤＵ順番（ｋ＝３）が与えられる。
【００７２】
次に、初期値としてｋを１に置いて最後のＭＳＤＵ順番をＮに置く（Ｓ５２）。
【００７３】
受信エラーがあり得るので、よってすべてのＭＳＤＵ順番（ｋ）に対してメモリ２５０に保存されたＭＳＤＵ  ｎｕｍｂｅｒが存在するものではない。したがって、ｋ番目のＭＳＤＵ順番に対してＭＳＤＵ  ｎｕｍｂｅｒが存在するかどうかを判断して（Ｓ５３）、存在しなければ（Ｓ５３のいいえ）、Ｂｉｔｍａｐフィールド１３０にビット対を‘０１’と記録する（Ｓ５９）。
【００７４】
もし、存在する場合には、ｋ番目のＭＳＤＵがフラグメントされたか否かを判断して（Ｓ５４）、フラグメントされていなければ（Ｓ５４のいいえ）、Ｂｉｔｍａｐフィールド１３０にビット対を‘１Ｘ’に記録する。ここで、Ｘは、１または０のいずれの値を記録しても良いという意味である。
【００７５】
フラグメントされていれば（Ｓ５４のはい）、ｋ番目のＭＳＤＵに該当する保存されたすべてのフラグメントのＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒを読取る（Ｓ５５）。そして、保存されたＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒのうち最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒより小さな‘Ｆｒａｇｍｅｎｔ順番’それぞれに対してＢｉｔｍａｐフィールド１３０に順次にビット対を記録する（Ｓ５６）。前記Ｆｒａｇｍｅｎｔ順番もＭＳＤＵ順番と同様に送信デバイスが伝送したフレームを基準として順次に与えられる。
【００７６】
例えば、［２：０］、［２：１］、［２：２］、及び［２：３］が伝送されたが、［２：１］と［２：３］のみが受信された場合を考えれば、保存されたフラグメントのＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒは１、３なので最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒは３になる。３より小さな‘Ｆｒａｇｍｅｎｔ順番’は０、１、２を意味するので、これに対してＢｉｔｍａｐフィールド１３０に順次にビット対を記録すれば、‘００’、‘１０’、‘００’になる。
【００７７】
次に、最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒが最終Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒと同じであれば（Ｓ５７のはい）、Ｂｉｔｍａｐフィールド１３０にビット対を‘１Ｘ’と記録する。ここで、最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒは、前述したようにメモリ２５０に保存されたＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒのうち最大値を意味し、最終Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒは、送信デバイスが伝送した対象フレームの最終Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒを意味する。最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒが最終Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒであるか否かは、図１３でＬａｓｔ  ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド１１９を参照すれば分かる。
【００７８】
Ｓ５７段階で、‘いいえ’である場合には、Ｂｉｔｍａｐフィールド１３０に最大Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒを有するフラグメントに対するビット対、すなわち、‘１０’を記録し（Ｓ６１）、以後のすべてのＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒに対するビット対は‘０１’に総括して記録する（Ｓ６２）。
【００７９】
Ｓ５８段階、Ｓ５９段階、Ｓ６０段階、またはＳ６６段階を実行した以後には、ｋがＮと同じであれば、Ｂｉｔｍａｐフィールド１３０の記録は完了したので終了し、そうではなければｋを１増加させた後、再びＳ５３段階に戻る。
【実施例２】
【００８０】
ＩＥＥＥ８０２．１１ｎタスクグループ（Ｔａｓｋ  Ｇｒｏｕｐ）では、大容量マルチメディア伝送要求に応じようと１００Ｍｂｐｓ以上の帯域幅を有する新しい形式の無線ＬＡＮ標準化作業を施行している。ＩＥＥＥ８０２．１１ｎは、ＩＥＥＥ８０２．１１ｅ基盤のＱｏＳ向上技術を基盤にしてＭＩＭＯ（Ｍｕｌｔｉ  Ｉｎｐｕｔ  Ｍｕｌｔｉ  Ｏｕｔｐｕｔ）技術を適用した無線ＬＡＮ標準の一つである。ＩＥＥＥ８０２．１１ｎは、既存の無線ＬＡＮと共存が可能で必要な場合、通信も可能である。また多様な機能が付加されたが、そのうち一つがブロック伝送（Ｂｌｏｃｋ  Ｔｒａｎｓｍｉｓｓｉｏｎ；ＡＣＫ受信なしに連続して送信されるデータフレームの伝送を意味する）である。
【００８１】
無線ＬＡＮの特性上、チャンネルを信頼することができないためにデータ伝送結果を確認するために一般的にＡＣＫフレームが使われる。ところが、ＩＥＥＥ８０２．１１ｎでは、ブロック伝送の結果としてブロックＡＣＫ要請フレーム（Ｂｌｏｃｋ  ＡＣＫ  Ｒｅｑｕｅｓｔ  Ｆｒａｍｅ）とブロックＡＣＫフレームとが使われる。ここで、ブロックＡＣＫフレームは、最大６４個のＭＳＤＵ、最大１０２４個の断片化されたフレーム（ｆｒａｇｍｅｎｔｅｄ  ｆｒａｍｅ）に対する伝送確認結果を含みうる。しかし、前記ブロックＡＣＫフレームは、伝送されるブロック伝送の個数とは無関係に１５２バイトの固定大きさを有しているために非効率的である。
【００８２】
ブロックＡＣＫ方式では、ブロックＡＣＫ要請フレームとブロックＡＣＫフレームとが使われる。従来のブロックＡＣＫ要請フレーム３１０は、図１６で図示した構成を有する。前記フレーム３１０のｔｙｐｅはｃｏｎｔｒｏｌであり、ｓｕｂｔｙｐｅは‘１０００’であり、ＢＡ  ｃｏｎｔｒｏｌフィールド３１１及びＢｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅフィールド３１２を含む。ＢＡ  ｃｏｎｔｒｏｌフィールド３１１は、またＲｅｓｅｒｖｅｄフィールド３１１ａとＴＩＤフィールド３１１ｂとに細分化され、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅフィールド３１２は、またＦｒａｇｍｅｎｔ  Ｎｕｍｂｅｒフィールド３１２ａ及びＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールド３１２ｂに細分化される。
【００８３】
一方、図１７は、従来のブロックＡＣＫフレーム３２０の構成を表わしたもので、図３をより詳しく表わした図面である。前記フレーム３２０のｔｙｐｅは  ｃｏｎｔｒｏｌであり、ｓｕｂｔｙｐｅは１００１である。ブロックＡＣＫフレーム３２０は、ブロックＡＣＫ要請フレーム３１０で要求するＢＡ  ｃｏｎｔｒｏｌフィールド３２１、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅフィールド３２２、及び先立ってブロック伝送されたデータの伝送確認結果を含むＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３２３を含む。
【００８４】
受信者（Ｒｅｃｉｐｉｅｎｔ）は、伝送者（ｏｒｉｇｉｎａｔｏｒ）によって伝送されたブロックＡＣＫ要請フレームを成功的に受信した後、先立って受信したブロック伝送によるデータ伝送確認結果をブロックＡＣＫフレーム３２０にあるＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３２３に記録して伝送者に伝送する。一般的に、伝送者は、データを伝送するステーション（ｓｔａｔｉｏｎ）を意味し、受信者は、データを受信するステーションを意味することで使われる。
【００８５】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３２３は、固定長１２８ｂｙｔｅｓであり、６４個のＭＳＤＵを表現できるように構成される。すなわち、一つのＭＳＤＵ当り２ｂｙｔｅｓが割り当てられ、これは１６個のフラグメント（ｆｒａｇｍｅｎｔ）を表現できる。このように最大６４ＭＳＤＵ、最大１０２４個のフラグメントの伝送確認結果は、１０２４ビットのビットマップ（Ｂ０ないしＢ１０２３）に表現されうる。
【００８６】
このように、従来のブロックＡＣＫフレーム３２０を使えば、いつも固定長のビットマップを使って伝送確認がなされるのでフレームの記録及び判読の簡単な側面があることはある。しかし、無線チャンネル資源が十分ではない無線ネットワーク環境では、チャンネルの効率的使用を阻害する要素と作用できる。
【００８７】
実際に、一つのＭＳＤＵは、最大１６個のフラグメントで構成されうるが、ほとんどの場合、データは断片化（ｆｒａｇｍｅｎｔａｔｉｏｎ）されないで単一ＭＳＤＵからなり伝送される。しかし、従来のＢｌｏｃｋ  ＡＣＫフレーム３２０は、いつも６４のＭＳＤＵ、すなわち、１０２４個のフラグメントを記録できるように構成されているために、大部分前記フレーム３２０には無駄使いになる領域が多数発生する。そして、小さな大きさのブロック伝送が発生してもいつも固定大きさのビットマップを含んで伝送されるために、チャンネル占有時間が増えるようになって、これによってチャンネル使用の非効率をもたらす。
【００８８】
もし、断片化が全然なされていない６４個のＭＳＤＵを受信した受信者が、これに対する従来のブロックＡＣＫフレーム３２０を伝送するとすれば、前記フレーム３２０には（０２４−６４）ビットほどの意味のない情報を含むために、前記フレーム３２０に含まれるビットマップの効率のみを考えれば、約９４％の無駄使いをもたらすわけになる。したがって、従来の機能をそのまま実行しながらより小さな大きさを有するブロックＡＣＫフレームの構成を開発して、無線通信のトラフィックを減少させる必要がある。
【００８９】
ブロックＡＣＫメカニズムは、ＳＩＦＳ（Ｓｈｏｒｔ  Ｉｎｔｅｒｆｒａｍｅ  Ｓｐａｃｅ）ほどの時間間隔を有するデータのブロック（ＡＣＫ受信なしに連続して伝送されるデータフレームの集合）を伝送可能にする。前記メカニズムは、複数のＡＣＫを一つのフレーム（ブロックＡＣＫフレーム）に代えることでチャンネル効率を向上させる。このようなブロックＡＣＫメカニズムには、‘ｉｍｍｅｄｉａｔｅ’タイプと‘ｄｅｌａｙｅｄ’タイプとがある。ＩｍｍｅｄｉａｔｅタイプのブロックＡＣＫは、高帯域幅（ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ）及び低いトラフィックレイテンシー（ｔｒａｆｆｉｃ  ｌａｔｅｎｃｙ）を要する環境に適し、ｄｅｌａｙｅｄタイプのブロックＡＣＫは、或る程度のレイテンシーを勘耐できる環境に適している。
【００９０】
ブロックＡＣＫメカニズムは、図１８のようにＡＤＤＢＡ要請（ＡＤＤＢＡ  ｒｅｑｕｅｓｔ）フレームの伝送によって始まる。以後、データのブロックは、伝送者から受信者に伝送される。ＱｏＳデータの間の時間間隔は、ＳＩＦＳで維持される。以後、伝送者が受信者にＢｌｏｃｋ  ＡＣＫ要請（Ｂｌｏｃｋ  ＡＣＫ  Ｒｅｑ）を行うによって受信者が伝送者にＢｌｏｃｋ  ＡＣＫフレームを伝送する。
【００９１】
最後に、伝送者が受信者にＤＥＬＢＡ要請（ＤＥＬＢＡ  ｒｅｑｕｅｓｔ）を送ることで全体過程が終了されうる。図１８の例では、セットアップ過程及び解除過程を含んでいるが、これは一例に過ぎず、本発明を実行するためにセットアップ過程及び解除過程が必ずしも要求されるものではない。
【００９２】
図１９は、本発明の一実施形態によるデータフレーム３５０の構成を図示した図面である。データフレーム３５０は、従来のＩＥＥＥ８０２．１１ａのようにＦｒａｍｅ  Ｃｏｎｔｒｏｌフィールドと、Ｄｕｒａｔｉｏｎ／ＩＤフィールドと、４個のＡｄｄｒｅｓｓフィールドＡｄｄｒｅｓｓ１、Ａｄｄｒｅｓｓ２、Ａｄｄｒｅｓｓ３、Ａｄｄｒｅｓｓ４、及びＳｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールドを含むＭＡＣヘッダと、Ｆｒａｍｅ  ｂｏｄｙと、ＦＣＳフィールドを含んで構成されうる。このうちＦＣＳフィールドは、３２ｂｉｔ  ＣＲＣ（ｃｙｃｌｉｃ  ｒｅｄｕｎｄａｎｃｙ  ｃｈｅｃｋｉｎｇ）エラーチェックのためのフィールドで本発明を実施するための必須的な構成要素ではない。
【００９３】
Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド３５１は、少なくともＴｙｐｅフィールド３５２と、Ｓｕｂｔｙｐｅフィールド３５３を含む。本発明で後述するビット対で構成されたビットマップ方式またはＡＣＫビットで構成されたビットマップ方式を利用するために、伝送者が断片化されたＭＰＤＵで構成されたＭＳＤＵが伝送する場合には、これと共に受信者に最終フラグメント番号（Ｌａｓｔ  Ｆｒａｇｍｅｎｔ  Ｎｕｍｂｅｒ）を伝達することとする。ここで、最終フラグメント番号は、現在伝送するＭＳＤＵの全体フラグメント数、すなわち、全体フラグメントのうち最後のフラグメントの一連番号を意味する。
【００９４】
このような最終フラグメント番号は、多様な方法で伝達されうるが、本発明ではその一例として前記Ｔｙｐｅフィールド３５２とＳｕｂｔｙｐｅフィールド３５３とを利用することとする。
【００９５】
従来のＴｙｐｅフィールドには、フレームのタイプ値（ｔｙｐｅ  ｖａｌｕｅ）が記録されるが、その値は‘００’、‘０１’、‘１０’を有することができ、順にそれぞれ‘Ｍａｎａｇｅｍｅｎｔ’フレームタイプ、‘Ｄａｔａ’フレームタイプ、‘Ｃｏｎｔｒｏｌ’フレームタイプを示す。そして、‘１１’値は予備（ｒｅｓｅｒｖｅｄ）されている。本発明は、従来の標準と互換性とをそのまま維持させるため、前記予備された値を利用する。本発明で、Ｔｙｐｅフィールド３５２に‘１１’が記録されたらデータフレームが断片化されて伝送されることを意味する。Ｔｙｐｅフィールド３５２が‘１１’である場合、Ｓｕｂｔｙｐｅフィールド３５３には最終フラグメント番号が記録される。従来のＴｙｐｅフィールドが‘１１’である場合、Ｓｕｂｔｙｐｅフィールドは、‘００００’から‘５２１’まで予備されているので、これを利用することで従来標準と互換性とを図る。但し、これは一つの実施形態に過ぎず、最終フラグメント番号を伝達するためにはいくらでも他の方式を使うことができるということは当業者には自明な事実である。
【００９６】
Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド３５１は、Ｔｙｐｅフィールド３５２とＳｕｂｔｙｐｅフィールド３５３との以外に、従来のようにＰｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎフィールド、Ｔｏ  ＤＳフィールド、Ｆｒｏｍ  ＤＳフィールド、Ｒｅｔｒｙフィールド、Ｐｗｒ  Ｍｇｔフィールド、Ｍｏｒｅ  Ｄａｔａフィールド、ＷＥＰフィールド、及びＯｔｈｅｒフィールドとをさらに含みうる。
【００９７】
Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３５４は、現在データフレーム（ないし現在フラグメント）のフラグメント番号が記録されるＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド３５５と、現在フレームが属するＭＳＤＵの識別番号（ＩＥＥＥ８０２．１１系列の標準では、シーケンス番号がこれに該当する）が記録されるＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールド３５６に分けられる。例えば、３個に断片化されたデータが伝送される時、［シーケンス番号：フラグメント番号］は、それぞれ［１：０］、［１：１］、［１：２］に表わすことができる。
【００９８】
図２０は、本発明の一実施形態によるブロックＡＣＫフレーム３１００の構成を図示した図面である。本発明でブロックＡＣＫ要請フレーム３１０は、従来と同一の形態をそのまま使うことができるので別途に定義しない。
【００９９】
ブロックＡＣＫフレーム３１００は、ＭＡＣヘッダ領域３１９０とペイロード領域３１５０、３１６０、３１７０とで構成されうる。そして、図１９で説明したようなＦＣＳフィールド３１８０をさらに含みうる。ＭＡＣヘッダ領域は、Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド３１１０と、Ｄｕｒａｔｉｏｎフィールド３１２０と、ＲＡフィールド３１３０と、ＴＡフィールド３１４０とを含むことができ、ペイロード領域は、ＢＡ  Ｃｏｎｔｒｏｌフィールド３１５０と、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０と、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０とを含みうる。
【０１００】
Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド３１１０は、図１９で表われた形式と同一である。ブロックＡＣＫフレーム３１００の場合、Ｔｙｐｅフィールド３５２は、ｃｏｎｔｒｏｌフレームを表わす値が記録され、Ｓｕｂｔｙｐｅフィールド３５３には、ＡＣＫフレーム３１００のｓｕｂｔｙｐｅ値が記録される。前記ｓｕｂｔｙｐｅ値は、予備されている値のうち一つを指定して使うことができる。
【０１０１】
Ｄｕｒａｔｉｏｎフィールド３１２０には、ブロックＡＣＫフレーム３１００の伝送時間及びＳＩＦＳ間隔を加えた値以上の値が記録される。そして、ＲＡフィールド３１３０には、ブロックＡＣＫを要請してブロックＡＣＫを受信するステーションのアドレスが記録され、ＴＡフィールド３１４０には、ブロックＡＣＫを伝送するステーションのアドレスが記録される。
【０１０２】
ＢＡ  Ｃｏｎｔｒｏｌフィールド３１５０は、ビット対のビットマップ方式のうち‘一般モード（Ｎｏｒｍａｌ  Ｍｏｄｅ）’と‘圧縮モード（Ｃｏｍｐｒｅｓｓｉｏｎ  Ｍｏｄｅ）’と‘１ビットモード’（３１ｂｉｔ  Ｍｏｄｅ）とを区分するビット値（以下、“モードビット”と言う）が記録されるＭｏｄｅ  Ｓｅｌｅｃｔｉｏｎフィールド３１５２とトラフィック識別子（ｔｒａｆｆｉｃ  ｉｄｅｎｔｉｆｉｅｒ；以下、ＴＩＤと言う）が記録されるＴＩＤフィールド３１５３とを含む。ここで、一般モード及び圧縮モードは、ビット対を用いて表現する方法である一方、１ビットモードは一つのフラグメントに対する伝送確認を行うが１個のビットを使う方法である。それぞれのモードに関する実施形態は後述する。
【０１０３】
そして、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０に含まれるビット対の個数（ｍ）が記録されるＢｉｔｍａｐ  Ｌｅｎｇｔｈフィールド３１５１をさらに含みうる。
【０１０４】
Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０は、ビット対の集合によって伝送確認を始めようとするフレームが属するＭＳＤＵの識別番号、すなわち、開始シーケンス番号（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）が記録されるＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールド３１６２と伝送確認を始めようとするフレームのフラグメント番号が記録されるＦｒａｇｍｅｎｔ  Ｎｕｍｂｅｒフィールド３１６１とで構成されている。
【０１０５】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０には、少なくとも一つ以上のビット対３１７１など（以下、ビット対の集合と言う）で構成されたビットマップが記録される。このようなビット対（Ｂｉｔ  Ｐａｉｒ）は、既存のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールドの記録方式を改善してより効率的に伝送確認結果を記録するために本発明で提案された形式である。一般的に、ビット対の大きさ総合がＯｃｔｅｔ単位にならない場合があり得るので、ビット対に引き継いでＰａｄｄｉｎｇフィールド３１７４を付け加えることもできる。Ｐａｄｄｉｎｇフィールド３１７４は、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０に記録されるビット対と大きさとを合わせてＯｃｔｅｔ単位にする最小ビット数のｄｕｍｍｙビット（例：０）が記録される。もし、ビット対大きさの総合が２６ビットとする時、パッディングフィールド３１７４の大きさを６ビットに取ると、全体的に３２ビット、すなわち、４バイトを合わせることができる。但し、パッディングフィールド３１４０は、本発明によるプロトコルを定義するための必須項目ではないので省略されることもできる。
【０１０６】
ビット対３１７１、３１７２、３１７３などは、ＡＣＫビット３１７１ａと、ＭＳＤＵビット３１７１ｂからなる。ＡＣＫビット３１７１ａには、該当フレームが正常的に伝送されたか否かを確認するビットが記録されるが、正常的に受信された場合には１と、そうではない場合には０と記録されうる。
【０１０７】
そして、ＭＳＤＵビット３１７１ｂには、前記第１ビットが表わすデータフレームの“範囲”を表わすビットが記録される。本発明の一実施形態によれば、前記範囲は、ＭＳＤＵビット３１７１ｂには、前記ＡＣＫビットが一つのフラグメント（一つのＭＳＤＵが断片化されていない場合は、一つのＭＳＤＵ）に対する伝送確認を表わすものなのか（前者）、一つのＭＳＤＵに属する現在フラグメント以後のすべてのフラグメントに対する伝送確認を表わすものなのか（後者）を区別する意味に理解されうる。ＭＳＤＵビット３１７１ｂは、前者の場合は０と、後者の場合は１と記録されうる。
【０１０８】
以下、図２１ないし図２６は、さまざまな実施形態によってブロックＡＣＫフレーム３１００が如何に構成されるかを説明するための図面である。本発明で、ビット対を用いてビットマップを構成する方法では、一般モードで表現する方法と、圧縮モードで表現する方法がある。以下で、［Ａ：Ｂ］はフレームを識別する表示であって、Ａは伝送者が伝送したフラグメントが属するＭＳＤＵに付与された識別番号、すなわち、シーケンス番号（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）を、Ｂはフラグメントの順番、すなわち、フラグメント番号（０から開始）を意味することとする。
【０１０９】
図２１は、［１：０］、［２：０］、［３：０］、［４：０］をすべて正常的に受信した場合に、ブロックＡＣＫフレーム３１００の構造を表わしたもので断片化が全然生じない場合である。この場合には、一般モードである場合と圧縮モードである場合とが同様に表われる。この場合、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０には、フレーム［１：０］の開始シーケンス番号（Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ＝１）及びフラグメント番号（Ｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒ＝０）が記録される。そして、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０には、対象フレームに対するＡＣＫビットとＭＳＤＵビットとからなるビット対が順に記録される。ところが、この場合、ビット対だけでもバイト単位になるので、別途のＰａｄｄｉｎｇフィールドは不要である。
【０１１０】
［１：０］、［２：０］、［３：０］、［４：０］は、すべて正常的に受信されたのでビット対の最初のビットは１で満たされる。二番目のビット対（Ｘに表示される）は、０または１のうちいずれの値で満たしても良い。該当フレームでＭＳＤＵが完結されるために１と表示することもできる一方、一つのフレームに対するＡＣＫ如何表示でもあるために０と表示することもできるためである。しかし、一応一つのＭＳＤＵで完結されたという意味を明確にする側面で１で満たすことがより望ましいことである。以下、Ｘは、本実施形態のような意味に解釈される。
【０１１１】
図２２は、［１：０］、［２：０］、［２：１］、［３：０］、［４：０］をすべて正常的に受信した場合にブロックＡＣＫフレーム３１００の構造を圧縮モードで表わしたものである。ここで、二番目のＭＳＤＵ（シーケンス番号＝２）が断片化されている。図２１と同様にＢｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０には、［１：０］の開始シーケンス番号（＝１）及びフラグメント番号（＝０）が記録される。そして、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０には、対象フレームに対するＡＣＫビット３１７１ａとＭＳＤＵビット３１７２ｂとからなるビット対が順に記録される。
【０１１２】
［１：０］、［２：０］、［２：１］、［３：０］、［４：０］は、すべて正常的に受信されたのでビット対の最初のビット（ＡＣＫビット）は１で満たされ、このうち［１：０］、［３：０］、［４：０］は完結されたフレームであるので二番目のビット（ＭＳＤＵビット）はＸで満たされる。但し、［２：０］以後にこのようなシーケンス番号及び他のフラグメント番号を有する［２：１］が存在するので、［２：０］に対するビット対のうち二番目のビットは１と表示して［２：０］以後のすべてのフラグメントが正常的に受信されることを表示する。
【０１１３】
このようにフラグメントになったＭＳＤＵに対して一度に表示することが望ましいが、同一の状況でブロックＡＣＫフレーム３１００を図２３のようにＭＳＤＵがフラグメントになった場合には、各フラグメント別に表示する方法も考えられる。図２２のように一つのＭＳＤＵに対して一度に表示する方式を“圧縮モード”と定義し、図２３にように各フラグメント別にそれぞれ表示する方式を“一般モード”と定義する。
【０１１４】
図２４は、伝送者が［１：０］、［２：０］、［２：１］、［２：２］、［３：０］を伝送したが、受信者は［１：０］、［２：０］、［３：０］のみを正常的に受信した場合のブロックＡＣＫフレーム３１００の構造を表わしたものである。ここで、二番目のＭＳＤＵは、３個のフラグメントに分けられたことが分かる。Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０には、フレーム［１：０］の開始シーケンス番号（＝１）及びフラグメント番号（＝０）が記録される。
【０１１５】
［１：０］、［３：０］は、すべて正常的に受信されたのでビット対の最初のビットは１で満たされ、完結されたフレームなので二番目のビットはＸで満たされる。ところが、［２：０］は正常的に受信されたが、その後のフラグメントが存在するので該当フレーム、すなわち、該当フラグメントに対する伝送確認のみを行うために該当位置に‘１０’が記録される。しかし、［２：１］及び［２：２］は、正常的に受信できなかったのでこの二つのフレームを代表して［２：１］の位置に該当するビット対の最初のビットは０と表示される。そして、二番目のビットは１として表示されるが、これは最初のビットが該当位置以後、すなわち、［２：１］及び［２：２］に対するＡＣＫビットであることを意味する。このように、受信者が複数のフラグメントのうち一部のみ受信してからも残りのフラグメントを受信することができなかったということが分かることは、伝送確認の対象となるデータフレーム３５０のＬａｓｔ  Ｆｒａｍｅ  Ｎｕｍｂｅｒフィールド３５３に全体フラグメント数が記録されているためである。
【０１１６】
図２１ないし図２４までの実施形態のうち、図２１の実施形態は圧縮モード及び一般モードで表現される例であり、図２３の実施形態は一般モードで表現した例であり、図２２、及び図２４の実施形態は圧縮モードで表現した例である。実施形態のうち両方とも表現可能な場合には、一般モードに比べて圧縮モードがより効率的であると考えられる。しかし、すべての場合に対して一般モード及び圧縮モードで表現可能なことではなく、一般モードでのみまたは圧縮モードでのみ表現可能な場合もあり得る。
【０１１７】
図２５の実施形態のように連続されたフラグメントのうちから中間の一部が抜け落ちされた場合には、一般モードでのみ表現可能であり、圧縮モードでは表現可能ではない。伝送者が［１：０］、［２：０］、［２：１］、［２：２］、［３：０］を伝送したが、受信者ではこの中で［２：１］のみを受信することができなかった場合にブロックＡＣＫフレーム３１００を一般モードで表現すれば、図２５のようである。
【０１１８】
図２６の実施形態は、伝送者が［１：０］、［２：０］、［２：１］、［２：２］、［３：０］を伝送したが、受信者側では［１：０］、［３：０］のみを正常的に受信した場合、ブロックＡＣＫフレーム３１００を圧縮モードで表現したものである。この場合には、圧縮モードでのみ表現可能である。なぜならば、受信者がＭＳＤＵが２であるフレームは一つも受けることができなかったので、全体フラグメント数が３ということが分からないためである。
【０１１９】
この場合、［１：０］、［３：０］は、すべて正常的に受信されたのでビット対の最初のビットは１で満たされ、完結されたフレームなので二番目のビットはＸで満たされる。ところが、ＭＳＤＵが１であるフレームと３であるフレームが受信されたことを見ればＭＳＤＵが２であるフレームも伝送されたが正常的に受信されることはできなかったことが分かる。このように、二番目のＭＳＤＵに対するフレームは一つも受信することができなかったが、［２：０］の位置に最初のビットを０で満たし、二番目のビットを１で満たすことで、［２：０］及びその以後のすべてのフラグメントは受信されることができなかったことを表示することができるのである。
【０１２０】
以上のように実施形態によって一般モード及び圧縮モードのうち一つのモードでのみ表現のみが可能な場合もあり、二つのモードにすべて表現可能な場合もある。両方とも表現可能な場合ならより効率的な圧縮モードを使うことが望ましい。
【０１２１】
一方、前記一般モードで表現可能な場合には、より改善した方式で伝送確認ができる。前述した一般モードと圧縮モードは、すべてビット対を用いて表現した実施形態である。しかし、一般モードである場合には、それぞれのフラグメント別に伝送確認を行うので、ＭＳＤＵビット３１７１ｂはすべて０であると表現できる。したがって、一般モードで表現可能な場合には、ＡＣＫビット３１７１ａ一つのみ使って伝送確認ができるが、このように１ビットに表現するモードを“１ビットモード”と定義する。
【０１２２】
図２７は、１ビットモードを使う場合にＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０の構成を表わしたものである。この場合、前記フィールド３１７０は、ビット対の代わりに１ビットのＡＣＫビット３１７５、１７６、１７７のみで構成され、やっぱりＯｃｔｅｔを合わせるためにＰａｄｄｉｎｇフィールド３１７４が使われうる。図２５のように、一般モードで表現された場合を１ビットモードで表現すれば、図２８のようになる。この結果は、一般モードでのビット対でＭＳＤＵビット３１７１ｂを省略したことと同一である。
【０１２３】
従来のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド（図１７の２３）も伝送確認のためのビットの集合でなされているという側面では同一である。しかし、本発明での１ビットモードは従来とは異なって、可変大きさのＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０を使う。また、従来のＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド（図１７の２３）は、断片化されていない一つのフレームまたは１６個以下に断片化されたフレーム（フラグメント）に対する伝送確認でも一律的に１６ビットを割り当てしたが、１ビットモードは一つのフレームまたはフラグメントにはそれぞれ１ビットずつ割り当てすることで確かなビット節減効果がある。これにより１ビットモードによってＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０にＡＣＫビット３１７５などを記録する時には従来とは異なって、連続して記録する。本発明では伝送者は、データフレームを通じて受信者にフラグメント数（最終フラグメント番号）を知らせることによって、伝送者及び受信者間にフラグメント情報を明確に分かるので、このように連続して記録しても混同の恐れがない。
【０１２４】
一方、どのモードを使ってビットマップを構成したのかは、図２０のＭｏｄｅ  Ｓｅｌｅｃｔｉｏｎフィールド３１５２に記録されうる。例えば、‘００’は一般モードを、‘０１’は圧縮モードを、そして、‘１０’は１ビットモードを表わすことでできる。
【０１２５】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０に含まれるビット対（圧縮モード及び一般モードの場合）またはビット（ＡＣＫ  ｂｉｔ；１ビットモードの場合）の個数（ｍ）は、Ｂｉｔｍａｐ  Ｌｅｎｇｔｈフィールド３１５１に記録されうる。例えば、図２２のような場合でＢｉｔｍａｐ  Ｌｅｎｇｔｈフィールド３１５１には４が記録され、図２３の場合でＢｉｔｍａｐ  Ｌｅｎｇｔｈフィールド３１５１には５が記録される。但し、受信者で各モードの規則によってビット対（３１７１など）またはＡＣＫビット３１７５などが記録される時、その大きさは一義的に決まることができる。したがって、ビット対またはＡＣＫビットを順次に記録して伝送者に伝送するだけでも、複数のデータフレームに対する伝送確認が十分に可能である。したがって、Ｂｉｔｍａｐ  Ｌｅｎｇｔｈフィールド３１５１は、本発明を実行するために必ずしも必要なものではなく、Ｂｉｔｍａｐ  Ｌｅｎｇｔｈフィールド３１５１部分を予備フィールドに代置することもできることを明らかにしておく。
【０１２６】
図２９は、以上のようなブロックＡＣＫフレーム３１００を伝送する、本発明の一実施形態による無線ステーション３２００の構成を表わしたブロック図である。無線ステーション３２００は、ブロックＡＣＫ生成モジュール３２１０と、ＭＡＣヘッダ判読モジュール３２２０と、送受信モジュール３２３０と、制御モジュール３２４０と、メモリ３２５０とを含んで構成されうる。
【０１２７】
ＭＡＣヘッダ判読モジュール３２２０は、受信されるデータフレームのＭＡＣヘッダから該当フレームが属するＭＳＤＵのシーケンス番号と、該当フレームのフラグメント番号、及び該当フレームが属するＭＳＤＵのフラグメント数を判読する。ＭＳＤＵのシーケンス番号は、前記ＭＡＣヘッダのＳｅｑｕｅｎｃｅ  ｎｕｍｂｅｒフィールド３５６から分かって、フラグメント番号はＭＡＣヘッダのＦｒａｇｍｅｎｔ  ｎｕｍｂｅｒフィールド３５５から分かる。そして、ＭＳＤＵのフラグメント数（ないし最終フラグメント番号）は、ＭＡＣヘッダのＳｕｂｔｙｐｅフィールド３５３から分かる。これは、ＭＳＤＵが断片化されて伝送される場合、各フラグメントからなるデータフレームのＴｙｐｅフィールド３５２は‘１１’で満たされ、このとき、Ｓｕｂｔｙｐｅフィールド３５３には、最終フラグメント番号が記録されるためである。
【０１２８】
このように、ＭＡＣヘッダから判読された情報は、メモリ３２５０に保存される。
【０１２９】
ブロックＡＣＫ生成モジュール３２１０は、メモリ３２５０に保存された前記ＭＡＣヘッダから判読された情報を用いて本発明によるブロックＡＣＫフレーム３１００のペイロードを生成させる。前記ペイロードは、ＢＡ  Ｃｏｎｔｒｏｌフィールド３１５０と、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０と、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０とを含んで構成されうる。
【０１３０】
ＢＡ  Ｃｏｎｔｒｏｌフィールド３１５０は、ビットマップを構成する方式のうち一般モード、圧縮モード、及び１ビットモードを区分するビット値が記録されるＭｏｄｅ  Ｓｅｌｅｃｔｉｏｎフィールド３１５２と、トラフィック識別子が記録されるＴＩＤフィールド３１５３とを含み、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０に含まれるビット対の個数（ｍ）、または１ビットモードの場合には、ＡＣＫビットの個数（ｋ）が記録されるＢｉｔｍａｐ  Ｌｅｎｇｔｈフィールド３１５１をさらに含みうる。
【０１３１】
Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０は、ビットマップによって伝送確認を始めようとするフレームが属するＭＳＤＵの識別番号、すなわち、シーケンス番号が記録されるＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールド３１６２と伝送確認を始めようとするフレームのフラグメント番号が記録されるＦｒａｇｍｅｎｔ  Ｎｕｍｂｅｒフィールド３１６１とで構成される。
【０１３２】
Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０は、少なくとも一つ以上のビット対３１７１などまたは少なくとも一つ以上のＡＣＫビット３１７５などで構成される。そして、ビット対またはＡＣＫビットに引き継いで全体Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０をＯｃｔｅｔ単位に合わせるためのＰａｄｄｉｎｇフィールド３１７４をさらに含みうる。
【０１３３】
一般モード及び圧縮モードの場合に、Ｂｉｔｍａｐフィールド３１７０を構成するビット対３１７１などは、ＡＣＫビット３１７１ａと、ＭＳＤＵビット３１７１ｂからなる。ＡＣＫビット３１７１ａには、該当フレームが正常的に伝送されたか否かを確認するビットが記録される。そして、ＭＳＤＵビット３１７１ｂには、前記ＡＣＫビットが一つのフラグメント（または、ＭＳＤＵ）に対する伝送確認を表わすものなのか、一つのＭＳＤＵに属する現在フラグメント以後のすべてのフラグメントに対する伝送確認を表わすものなのかを区別するビット情報が記録される。
【０１３４】
一方、１ビットモードである場合に、Ｂｉｔｍａｐフィールド３１７０を構成するＡＣＫビット３１７５などには、該当フレームが正常的に伝送されたか否かを確認するビットが記録される。
【０１３５】
また、ブロックＡＣＫ生成モジュール３２１０は、ＢＡ  Ｃｏｎｔｒｏｌフィールド３１５０、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０、及びＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０からなる、ブロックＡＣＫフレーム３１００のペイロードを生成させた以後には、前記ペイロード伝送のために必要なＭＡＣヘッダ３１９０を生成させて付け加えることによって、ブロックＡＣＫフレーム３１００を生成させる。
【０１３６】
制御モジュール３２４０は、無線ステーション３１００内の他のモジュールの動作を制御するが、中央処理ユニット（ＣＰＵ）、マイコン（Ｍｉｃｒｏｃｏｍｐｕｔｅｒ）などによって具現されうる。
【０１３７】
送受信モジュール３２３０は、他の無線ステーション、すなわち、伝送者からデータフレーム及びブロックＡＣＫ要請フレーム３１０を受信し、ブロックＡＣＫ生成モジュール３２１０によって生成されたブロックＡＣＫフレーム３１００を前記伝送者に伝送する。このような送受信モジュール３２３０は、受信された無線信号を復調して二進データを復元し、伝送する二進データを無線信号に変調して空間上に伝送する。
【０１３８】
今までの説明で、“モジュール（ｍｏｄｕｌｅ）”という用語は、ソフトウェア構成要素（Ｓｏｆｔｗａｒｅ  ｃｏｍｐｏｎｅｎｔ）またはＦＰＧＡ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）またはＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）のようなハードウェア構成要素（ｈａｒｄｗａｒｅ  ｃｏｍｐｏｎｅｎｔ）を意味し、モジュールは所定の役割を実行する。しかし、モジュールは、ソフトウェアまたはハードウェアに限定される意味ではない。モジュールは、アドレッシング（ａｄｄｒｅｓｓｉｎｇ）できる記録媒体にあるように構成することもでき、一つまたはそれ以上のプロセッサを実行させるように構成することもできる。したがって、一例としてモジュールは、ソフトウェア構成要素、客体志向ソフトウェア構成要素、クラス（ｃｌａｓｓ）構成要素及びタスク（ｔａｓｋ）構成要素のような構成要素と、プロセス（ｐｒｏｃｅｓｓｅｓ）、関数（ｆｕｎｃｔｉｏｎｓ）、属性（ｐｒｏｐｅｒｔｉｅｓ）、プロシージャ（ｐｒｏｃｅｄｕｒｅｓ）、サブルーチン（Ｓｕｂ−ｒｏｕｔｉｎｅｓ）、プログラムコード（ｐｒｏｇｒａｍ  ｃｏｄｅ）のセグメント（Ｓｅｇｍｅｎｔｓ）、ドライバー（ｄｒｉｖｅｒｓ）、ファームウェア（ｆｉｒｍｗａｒｅｓ）、マイクロコード（ｍｉｃｒｏ−ｃｏｄｅｓ）、回路（ｃｉｒｃｕｉｔｓ）、データ（ｄａｔａ）、データベース（ｄａｔａｂａｓｅｓ）、データ構造（ｄａｔａ  ｓｔｒｕｃｔｕｒｅｓ）、テーブル（ｔａｂｌｅｓ）、アレイ（ａｒｒａｙｓ）、及び変数（ｖａｒｉａｂｌｅｓ）を含む。構成要素とモジュール内で提供される機能は、さらに小さな数の構成要素及びモジュールに結合されるか追加的な構成要素とモジュールとにさらに分離されうる。それだけでなく、構成要素及びモジュールは、通信システム内の一つまたはそれ以上のコンピューターを実行させるように具現されることもできる。
【０１３９】
図３０は、本発明の一実施形態による全体動作を表わしたフローチャートである。
まず、無線ステーション３２００は、データフレームを他の無線ステーションから受信する（Ｓ３１０）。そして、前記データフレームのＭＡＣヘッダを判読する（Ｓ３２０）。ＭＡＣヘッダ判読過程で、少なくとも前記データフレームが属するＭＳＤＵのシーケンス番号と、該当フレームのフラグメント番号とを判読する。そして、もし、前記データフレームが断片化されたＭＳＤＵ中の一部フラグメントを含むとすれば、前記ＭＳＤＵのフラグメント数も判読する。前記データフレームが断片化されたか否かはＴｙｐｅフィールド３５２が‘１１’であるかをチェックすれば分かり、そのときのフラグメント数はＳｕｂｔｙｐｅフィールド３５３を判読することで分かる。そして、無線ステーション３２００は、シーケンス番号、フラグメント番号、及び最終フラグメント番号（存在すれば）をメモリ３２５０に保存する（Ｓ３３０）。
【０１４０】
前記Ｓ１０ないしＳ３０の過程は、無線ステーション３２００が伝送者からブロックＡＣＫ要請フレーム３１０を受信するまで反復される。もし、ブロックＡＣＫ要請フレームを無線ステーション３２００が受信したとすれば（Ｓ３４０のはい）、以後にはブロックＡＣＫフレームを生成させて伝送する過程（Ｓ３５０ないしＳ３９０）が実行される。
【０１４１】
無線ステーション３２００は、まず、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０に伝送確認を始めようとするフレームが属するＭＳＤＵのシーケンス番号及び伝送確認を始めようとするフレームのフラグメント番号を記録する（Ｓ３５０）。
【０１４２】
もし、ビットマップに記録されるビット対を圧縮モードで表現する場合には、圧縮モードによってＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０にビット対を記録し（Ｓ３６０）、一般モードで表現する場合には、一般モードによってＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０にビット対を記録する（Ｓ３６５）。そして、１ビットモードで表現しようとする場合には、１ビットモードによってＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０にＡＣＫビット３１７５などを記録する（Ｓ３６９）。このように、モードを選択する例として、圧縮モードと１ビットモードとにすべて表現可能な場合には、実際の各モードに対して構成したビットマップの大きさが小さな方のモードを選択できる。一般モードで表現可能な場合には、いつも１ビットモードでも表現可能なのでより効率的な１ビットモードを使うことが望ましい。
【０１４３】
次に、各モードに該当するモードビットをＢＡ  Ｃｏｎｔｒｏｌフィールド３１５０に記録する（Ｓ３７０）。
【０１４４】
無線ステーション３２００は、前記ＢＡ  Ｃｏｎｔｒｏｌフィールド３１５０と、Ｂｌｏｃｋ  ＡＣＫ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド３１６０と、Ｂｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールド３１７０からなるペイロードにＭＡＣヘッダ３１９０を付け加えてブロックＡＣＫフレーム３１００を生成させる（Ｓ３８０）。そして、生成されたブロックＡＣＫフレーム３１００を前記他の無線ステーションに伝送する。
【０１４５】
以上、添付された図面を参照して本発明の実施形態を説明したが、当業者ならば本発明がその技術的思想や必須的な特徴を変更せずとも、他の具体的な形態に実施できるということを理解できるであろう。したがって、前述した実施形態は、あらゆる面で例示的なものであり、限定的ではないと理解せねばならない。
【図面の簡単な説明】
【０１４６】
【図１】一般的なバーストＡＣＫフレーム伝送方式を説明する図である。
【図２】ＩＥＥＥ８０２．１５．３標準による遅延ＡＣＫフレームの構成を表わした図である。
【図３】ＩＥＥＥ８０２．１１ｅ標準によるブロックＡＣＫフレームの構成を表わした図である。
【図４】本発明の一実施形態によるバーストＡＣＫフレームの構成を表わした図である。
【図５】従来のＩＥＥＥ８０２．１１系列標準のＭＡＣ  ｈｅａｄｅｒ及びＩＥＥＥ８０２．１５．３標準のＭＡＣ  ｈｅａｄｅｒの構造を表わした図である。
【図６】さまざまな実施形態によってバーストＡＣＫフレームが如何に決定されるかを説明するための図である。
【図７】さまざまな実施形態によってバーストＡＣＫフレームが如何に決定されるかを説明するための図である。
【図８】さまざまな実施形態によってバーストＡＣＫフレームが如何に決定されるかを説明するための図である。
【図９】さまざまな実施形態によってバーストＡＣＫフレームが如何に決定されるかを説明するための図である。
【図１０】さまざまな実施形態によってバーストＡＣＫフレームが如何に決定されるかを説明するための図である。
【図１１】本発明の一実施形態による無線デバイスの構成を表わしたブロック図である。
【図１２】バーストＡＣＫ生成モジュールの詳細構成を表わしたブロック図である。
【図１３】従来のＩＥＥＥ８０２．１５．３標準によるＭＡＣ  Ｈｅａｄｅｒの構成を詳しく図示した図である。
【図１４】本発明の一実施形態によるバーストＡＣＫフレーム生成過程を表わしたフローチャートである。
【図１５】図１４のＳ５０段階に対するより詳しい過程を表わしたフローチャートである。
【図１６】従来のブロックＡＣＫ要請フレームの構成を表わした図である。
【図１７】従来のブロックＡＣＫフレームの構成を表わした図である。
【図１８】ブロックＡＣＫメカニズムを簡略に表わす図である。
【図１９】本発明の一実施形態によるデータフレームの構成を図示した図である。
【図２０】本発明の一実施形態によるブロックＡＣＫフレームの構成を図示した図である。
【図２１】さまざまな実施形態によってブロックＡＣＫフレームが如何に構成されるかを説明するための図である。
【図２２】さまざまな実施形態によってブロックＡＣＫフレームが如何に構成されるかを説明するための図である。
【図２３】さまざまな実施形態によってブロックＡＣＫフレームが如何に構成されるかを説明するための図である。
【図２４】さまざまな実施形態によってブロックＡＣＫフレームが如何に構成されるかを説明するための図である。
【図２５】さまざまな実施形態によってブロックＡＣＫフレームが如何に構成されるかを説明するための図である。
【図２６】さまざまな実施形態によってブロックＡＣＫフレームが如何に構成されるかを説明するための図である。
【図２７】１ビットモードを使う場合にＢｌｏｃｋ  ＡＣＫ  Ｂｉｔｍａｐフィールドの構成を表わした図である。
【図２８】図２５の場合を１ビットモードで表現した例を表わした図である。
【図２９】本発明の一実施形態による無線ステーションの構成を表わしたブロック図である。
【図３０】本発明の一実施形態による全体動作を表わしたフローチャートである。
【図１】
2008509622.tif 000003
【図２】
2008509622.tif 000004
【図３】
2008509622.tif 000005
【図４】
2008509622.tif 000006
【図５】
2008509622.tif 000007
【図６】
2008509622.tif 000008
【図７】
2008509622.tif 000009
【図８】
2008509622.tif 000010
【図９】
2008509622.tif 000011
【図１０】
2008509622.tif 000012
【図１１】
2008509622.tif 000013
【図１２】
2008509622.tif 000014
【図１３】
2008509622.tif 000015
【図１４】
2008509622.tif 000016
【図１５】
2008509622.tif 000017
【図１６】
2008509622.tif 000018
【図１７】
2008509622.tif 000019
【図１８】
2008509622.tif 000020
【図１９】
2008509622.tif 000021
【図２０】
2008509622.tif 000022
【図２１】
2008509622.tif 000023
【図２２】
2008509622.tif 000024
【図２３】
2008509622.tif 000025
【図２４】
2008509622.tif 000026
【図２５】
2008509622.tif 000027
【図２６】
2008509622.tif 000028
【図２７】
2008509622.tif 000029
【図２８】
2008509622.tif 000030
【図２９】
2008509622.tif 000031
【図３０】
2008509622.tif 000032
【国際調査報告】
2008509622.tif 000033
2008509622.tif 000034