(57)【特許請求の範囲】
【請求項１】
受信確認フレームの生成方法において、
データフレームを受信するステップと、
前記受信されたデータフレームに含まれたサブフレームが差等エラー訂正符号化（ＵＥＰ：Ｕｎｅｑｕａｌ  Ｅｒｒｏｒ  Ｐｒｏｔｅｃｔｉｏｎ）モードでコーディングされたか否かを判断する第１判断ステップと、
前記第１判断ステップの判断に基づいて、ＵＥＰモードでコーディングされていないと判断される場合には、前記サブフレームのそれぞれの受信如何を表す第１  ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フィールドを含む受信確認フレームを生成し、かつ、ＵＥＰモードでコーディングされたと判断される場合には、前記サブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２  ＡＣＫフィールドを含む受信確認フレームを生成するステップと、を含むことを特徴とする受信確認フレームの生成方法。
【請求項２】
所定のサブフレームまたは少なくとも一つのマックサービスデータユニット（ＭＳＤＵ：ＭＡＣ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）の含まれた受信確認フレームを要請するデータ挿入ＡＣＫ要請フィールドが前記データフレームに含まれているか否かを判断する第２判断ステップをさらに含み、
前記受信確認フレームを生成するステップは、前記第２判断ステップの判断に基づいて、サブフレームまたは少なくとも一つのＭＳＤＵをさらに備える受信確認フレームを選択的に生成することを特徴とする請求項１に記載の受信確認フレームの生成方法。
【請求項３】
前記受信確認フレームを生成するステップは、
ＭＡＣヘッダ、前記第１  ＡＣＫフィールド、または前記第２  ＡＣＫフィールドを備えるサブヘッダ、及び前記ＭＡＣヘッダと前記サブヘッダとのエラーを検出するためのＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）フィールドを備える受信確認フレームを生成することを特徴とする請求項１に記載の受信確認フレームの生成方法。
【請求項４】
前記第１判断ステップの判断結果、前記データフレームに含まれたサブフレームがＵＥＰモードでコーディングされていないと判断されれば、
前記第１  ＡＣＫフィールドには、前記サブフレームのそれぞれに対して受信如何についての情報が２回ずつ記録されることを特徴とする請求項１に記載の受信確認フレームの生成方法。
【請求項５】
前記第２判断ステップの判断結果、前記データフレームに前記データ挿入ＡＣＫ要請フィールドが備えられていると判断されれば、サブフレームまたは少なくとも一つのＭＳＤＵ、ＭＡＣサブヘッダ、及びＭＡＣヘッダを備える受信確認フレームを生成し、
前記ＭＡＣサブヘッダは、前記サブフレームまたは前記少なくとも一つのＭＳＤＵに適用されたＵＥＰモードと関連した情報を表すＵＥＰフィールド及び前記第１  ＡＣＫフィールド、または前記第２  ＡＣＫフィールドを備えることを特徴とする請求項２に記載の受信確認フレームの生成方法。
【請求項６】
前記ＵＥＰフィールドは、
前記サブフレームまたは前記少なくとも一つのＭＳＤＵがＵＥＰモードでコーディングされたか否かを表すＵＥＰ可能フィールド、ＵＥＰモードでコーディングされたサブフレームまたは少なくとも一つのＭＳＤＵに適用された変調及びコーディング方式（Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｃｈｅｍｅ：ＭＣＳ）を表すＵＥＰ  ＭＣＳフィールドを備えることを特徴とする請求項５に記載の受信確認フレームの生成方法。
【請求項７】
前記受信確認フレームは、
ＵＥＰモードでコーディングされていないサブフレームまたは少なくとも一つのＭＳＤＵに適用されたＭＣＳを表すＭＣＳフィールドを備えるＰＨＹ（Ｐｈｙｓｉｃａｌ）ヘッダをさらに備えることを特徴とする請求項５に記載の受信確認フレームの生成方法。
【請求項８】
前記データフレームは、前記サブフレーム及び前記サブフレームについての情報を表すサブヘッダを備え、
前記第１判断ステップは、前記サブヘッダに基づいて、前記判断を行うことを特徴とする請求項１に記載の受信確認フレームの生成方法。
【請求項９】
前記サブフレームでの前記第１タイプビットは、前記サブフレームでの最上位ビット（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔｓ：ＭＳＢ）であり、前記第２タイプビットは、前記サブフレームでの最下位ビット（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔｓ：ＬＳＢ）であることを特徴とする請求項１に記載の受信確認フレームの生成方法。
【請求項１０】
受信確認フレーム生成装置において、
データフレームを受信する受信部と、
前記受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断する第１判断部と、
前記第１判断ステップの判断に基づいて、ＵＥＰモードでコーディングされていないと判断される場合には、前記サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールドを含む受信確認フレームを生成し、かつ、ＵＥＰモードでコーディングされたと判断される場合には、前記サブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２  ＡＣＫフィールドを含む受信確認フレームを生成するフレーム生成部と、を備えることを特徴とする受信確認フレーム生成装置。
【請求項１１】
所定のサブフレームまたは少なくとも一つのＭＳＤＵの含まれた受信確認フレームを要請するデータ挿入ＡＣＫ要請フィールドが前記データフレームに含まれているか否かを判断する第２判断部をさらに備え、
前記フレーム生成部は、前記第２判断部の判断に基づいて、サブフレームまたは少なくとも一つのＭＳＤＵをさらに備える受信確認フレームを選択的に生成することを特徴とする請求項１０に記載の受信確認フレーム生成装置。
【請求項１２】
前記フレーム生成部は、
ＭＡＣヘッダ、前記第１  ＡＣＫフィールド、または前記第２  ＡＣＫフィールドを備えるサブヘッダ、及び前記ＭＡＣヘッダと前記サブヘッダとのエラーを検出するためのＦＣＳフィールドを備える受信確認フレームを生成することを特徴とする請求項１０に記載の受信確認フレーム生成装置。
【請求項１３】
前記第１判断部の判断結果、前記データフレームに含まれたサブフレームがＵＥＰモードでコーディングされていないと判断されれば、前記第１  ＡＣＫフィールドには、前記サブフレームのそれぞれに対して受信如何についての情報が２回ずつ記録されることを特徴とする請求項１０に記載の受信確認フレーム生成装置。
【請求項１４】
前記第２判断部の判断結果、前記データフレームに前記データ挿入ＡＣＫ要請フィールドが備えられていると判断されれば、前記フレーム生成部は、サブフレームまたは少なくとも一つのＭＳＤＵ、ＭＡＣサブヘッダ、及びＭＡＣヘッダを備える受信確認フレームを生成し、
前記ＭＡＣサブヘッダは、前記サブフレームまたは前記少なくとも一つのＭＳＤＵに適用されたＵＥＰモードと関連した情報を表すＵＥＰフィールド及び前記第１  ＡＣＫフィールド、または前記第２  ＡＣＫフィールドを備えることを特徴とする請求項１１に記載の受信確認フレーム生成装置。
【請求項１５】
前記ＵＥＰフィールドは、
前記サブフレームまたは前記少なくとも一つのＭＳＤＵがＵＥＰモードでコーディングされたか否かを表すＵＥＰ可能フィールド、ＵＥＰモードでコーディングされたサブフレームまたは少なくとも一つのＭＳＤＵに適用されたＭＣＳを表すＵＥＰ ＭＣＳフィールドを備えることを特徴とする請求項１４に記載の受信確認フレーム生成装置。
【請求項１６】
前記受信確認フレームは、
ＵＥＰモードでコーディングされていないサブフレームまたは少なくとも一つのＭＳＤＵに適用されたＭＣＳを表すＭＣＳフィールドを備えるＰＨＹヘッダをさらに備えることを特徴とする請求項１４に記載の受信確認フレーム生成装置。
【請求項１７】
前記データフレームは、前記サブフレーム及び前記サブフレームについての情報を表すサブヘッダを備え、
前記第１判断部は、前記サブヘッダに基づいて前記判断を行うことを特徴とする請求項１０に記載の受信確認フレーム生成装置。
【請求項１８】
前記サブフレームでの前記第１タイプビットは、前記サブフレームでのＭＳＢであり、前記第２タイプビットは、前記サブフレームでのＬＳＢであることを特徴とする請求項１０に記載の受信確認フレーム生成装置。
【請求項１９】
請求項１ないし９のうち何れか一項に記載の方法を実行させるためのプログラムが記録されたコンピュータで読み取り可能な記録媒体。
【請求項２０】
データフレームを受信するステップと、
前記受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断する第１判断ステップと、
所定のサブフレームまたは少なくとも一つのＭＳＤＵの含まれた受信確認フレームを要請するデータ挿入ＡＣＫ要請フィールドが前記データフレームに含まれているか否かを判断する第２判断ステップと、
前記第１判断ステップの判断に基づいて、ＵＥＰモードでコーディングされていないと判断される場合には、前記サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールドを含む受信確認フレームを生成し、かつ、ＵＥＰモードでコーディングされたと判断される場合には、前記サブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２  ＡＣＫフィールドを含む受信確認フレームを生成するステップと、を含み、
前記第２判断ステップの判断結果、前記データフレームに前記データ挿入ＡＣＫ要請フィールドが備えられていると判断されれば、サブフレームまたは少なくとも一つのＭＳＤＵ、ＭＡＣサブヘッダ、及びＭＡＣヘッダを備える受信確認フレームが生成されることを特徴とする受信確認フレームの生成方法。
【請求項２１】
無線デバイスにおいて、 
前記デバイスのそれぞれのユニットを連結するバスと、
前記バスに連結される少なくとも一つのプロセッサと、
前記バス及び前記少なくとも一つのプロセッサと連結され、命令を保存する少なくとも一つのメモリと、を備え、
前記少なくとも一つのプロセッサは、データフレームを受信し、前記受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断し、前記判断に基づいて、ＵＥＰモードでコーディングされていないと判断される場合には、前記サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールドを含む受信確認フレームを生成し、かつ、ＵＥＰモードでコーディングされたと判断される場合には、前記サブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２  ＡＣＫフィールドを含む受信確認フレームを生成する動作を行うことを特徴とする無線デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信確認フレームの生成方法及びその装置に関する。
【背景技術】
【０００２】
ＷＰＡＮ（Ｗｉｒｅｌｅｓｓ  Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）は、家庭や事務室などの比較的距離の短い個人領域での無線接続を提供するネットワークである。ＷＰＡＮでは、約１０ｍの範囲を有するピコネットでデバイスがＴＤＭＡ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）方式で通信し、アドホックネットワークを構成する。
【０００３】
このような個人領域での通信標準を提供するために、ＩＥＥＥ  ８０２.１５  ＷＧ（Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ）が設けられ、ＩＥＥＥ  ８０２.１５  ＷＧに属する４つのＴＧ（Ｔａｓｋ  Ｇｒｏｕｐ）のうち、ＩＥＥＥ  ８０２.１５.３では、高速のデータ伝送のための規格であるＨＲ（Ｈｉｇｈ  Ｒａｔｅ）−ＷＰＡＮの標準化を完了した。
【０００４】
このような無線ネットワーク環境で安定した通信を保証するためにＡＣＫフレームが使われる。例えば、送信デバイスがデータフレームを受信デバイスに伝送した場合に、受信デバイスがその伝送されたデータフレームを受信すれば、その受信デバイスは、ＡＣＫフレームを送信デバイスに伝送する。
【０００５】
また、送信デバイスの伝送するデータフレームが複数のサブフレームで構成された場合には、受信デバイスがそのそれぞれのサブフレームに対するブロックＡＣＫフレームを送信デバイスに伝送する。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明が解決しようとする目的は、受信確認フレームの生成方法及びその装置を提供することである。
【課題を解決するための手段】
【０００７】
前記目的を達成するための本発明の一実施形態による受信確認フレームの生成方法は、データフレームを受信するステップと、前記受信されたデータフレームに含まれたサブフレームが差等エラー訂正符号化（ＵＥＰ：Ｕｎｅｑｕａｌ  Ｅｒｒｏｒ  Ｐｒｏｔｅｃｔｉｏｎ）モードでコーディングされたか否かを判断する第１判断ステップと、前記第１判断ステップの判断に基づいて、前記サブフレームのそれぞれの受信如何を表す第１  ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅ）フィールド、または前記サブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信可否を表す第２  ＡＣＫフィールドのうち、一つを含む受信確認フレームを生成するステップと、を含む。
【０００８】
望ましくは、本発明の一実施形態による受信確認フレームの生成方法は、所定のサブフレームまたは少なくとも一つのマックサービスデータユニット（ＭＳＤＵ：ＭＡＣ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）の含まれた受信確認フレームを要請するデータ挿入ＡＣＫ要請フィールドが前記データフレームに含まれているか否かを判断する第２判断ステップをさらに含み、前記受信確認フレームを生成するステップは、前記第２判断ステップの判断に基づいて、サブフレームまたは少なくとも一つのＭＳＤＵをさらに備える受信確認フレームを選択的に生成することを特徴とする。
【０００９】
望ましくは、前記受信確認フレームを生成するステップは、ＭＡＣヘッダ、前記第１  ＡＣＫフィールド、または前記第２  ＡＣＫフィールドを備えるサブヘッダ、及び前記ＭＡＣヘッダと前記サブヘッダとのエラーを検出するためのＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｗｅｑｕｅｎｃｅ）フィールドを備える受信確認フレームを生成することを特徴とする。
【００１０】
望ましくは、前記第１判断ステップの判断結果、前記データフレームに含まれたサブフレームがＵＥＰモードでコーディングされていないと判断されれば、前記第１  ＡＣＫフィールドには、前記サブフレームのそれぞれに対して受信如何についての情報が２回ずつ記録されることを特徴とする。
【００１１】
望ましくは、前記第２判断ステップの判断結果、前記データフレームに前記データ挿入ＡＣＫ要請フィールドが備えられていると判断されれば、サブフレームまたは少なくとも一つのＭＳＤＵ、ＭＡＣサブヘッダ、及びＭＡＣヘッダを含む受信確認フレームを生成し、前記ＭＡＣサブヘッダは、前記サブフレームまたは前記少なくとも一つのＭＳＤＵに適用されたＵＥＰモードと関連した情報を表すＵＥＰフィールド及び前記第１  ＡＣＫフィールド、または前記第２  ＡＣＫフィールドを備えることを特徴とする。
【００１２】
望ましくは、前記ＵＥＰフィールドは、前記サブフレームまたは前記少なくとも一つのＭＳＤＵがＵＥＰモードでコーディングされたか否かを表すＵＥＰ可能フィールドと、ＵＥＰモードでコーディングされたサブフレームまたは少なくとも一つのＭＳＤＵに適用された変調及びコーディング方式（Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｃｈｅｍｅ：ＭＣＳ）を表すＵＥＰ  ＭＣＳフィールドとを備えることを特徴とする。
【００１３】
望ましくは、前記受信確認フレームは、ＵＥＰモードでコーディングされていないサブフレームまたは少なくとも一つのＭＳＤＵに適用されたＭＣＳを表すＭＣＳフィールドを備えるＰＨＹ（Ｐｈｙｓｉｃａｌ）ヘッダをさらに備えることを特徴とする。
【００１４】
望ましくは、前記データフレームは、サブフレーム及び前記サブフレームについての情報を表すサブヘッダを備え、前記第１判断ステップは、前記サブヘッダに基づいて前記判断を行うことを特徴とする。
【００１５】
望ましくは、前記サブフレームでの前記第１タイプビットは、前記サブフレームでの最上位ビット（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔｓ：ＭＳＢ）であり、前記第２タイプビットは、前記サブフレームでの最下位ビット（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔｓ：ＬＳＢ）であることを特徴とする。
【００１６】
また、前記目的を達成するための本発明の一実施形態による受信確認フレーム生成装置は、データフレームを受信する受信部と、前記受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断する第１判断部と、前記第１判断部の判断に基づいて、前記サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールド、または前記サブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２
ＡＣＫフィールドのうち、一つを含む受信確認フレームを生成するフレーム生成部と、を備えることを特徴とする。
【００１７】
望ましくは、本発明の一実施形態による受信確認フレーム生成装置は、所定のサブフレームまたは少なくとも一つのＭＳＤＵの含まれた受信確認フレームを要請するデータ挿入ＡＣＫ要請フィールドが前記データフレームに含まれているか否かを判断する第２判断部をさらに備え、前記フレーム生成部は、前記第２判断部の判断に基づいて、サブフレームまたは少なくとも一つのＭＳＤＵをさらに備える受信確認フレームを選択的に生成することを特徴とする。
【００１８】
また、前記目的を達成するための本発明の一実施形態は、データフレームを受信するステップと、前記受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断する第１判断ステップと、前記第１判断ステップの判断に基づいて、前記サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールド、または前記サブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２  ＡＣＫフィールドのうち、一つを備える受信確認フレームを生成するステップと、を含む受信確認フレームの生成方法を実行させるためのプログラムが記録されたコンピュータで読み取り可能な記録媒体を提供する。
【発明を実施するための最良の形態】
【００１９】
以下、添付された図面を参照して、本発明の望ましい実施形態について詳細に説明する。
【００２０】
図１は、本発明による受信確認フレームの生成方法の一実施形態を説明するために示すフローチャートである。
【００２１】
ステップ１１０では、データフレームを受信する。
【００２２】
ステップ１２０では、その受信されたデータフレームに含まれたサブフレームがＵＥＰ（Ｕｎｅｑｕａｌ  Ｅｒｒｏｒ  Ｐｒｏｔｅｃｔｉｏｎ）モードでコーディングされたか否かを判断する。
【００２３】
このとき、受信されたデータフレームにサブフレームについての情報を表すサブヘッダがさらに備えられるが、このような場合には、そのサブヘッダに基づいて、そのデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断する。
【００２４】
ステップ１３０では、その判断に基づいて、サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールド、またはサブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２  ＡＣＫフィールドのうち一つを備える受信確認フレームを生成する。
【００２５】
さらに具体的には、データフレームのサブフレームがＵＥＰモードではなく、均等エラー訂正符号化（Ｅｑｕａｌ  Ｅｒｒｏｒ  Ｐｒｏｔｅｃｔｉｏｎ：ＥＥＰ）モードによってコーディングされたと判断されれば、受信確認フレームは、第１  ＡＣＫフィールドを備えるように生成され、その第１  ＡＣＫフィールドを構成するビットは、サブフレームのそれぞれの受信如何を表すために利用される。例えば、第１  ＡＣＫフィールドが２５６ビットで構成された場合には、２５６個のサブフレームのそれぞれに対する受信如何を表示しうる。
【００２６】
しかしながら、データフレームのサブフレームがＵＥＰモードでコーディングされたと判断されれば、データフレームは、第１タイプビット及び第２タイプビットで構成されるが、受信確認フレームは、このような２種類のビットの受信如何を表すための第２  ＡＣＫフィールドを備えるように生成される。
【００２７】
例えば、第２  ＡＣＫフィールドは、２５６個のサブフレームでの第１タイプビットと第２タイプビットとのそれぞれの受信如何を表すために５１２ビットを利用しうる。このとき、２５６ビットは、第１タイプビットのための第２  ＡＣＫフィールドとして利用され、残りの２５６ビットは、第２タイプビットのための第２  ＡＣＫフィールドとして利用される。
【００２８】
このとき、具現例によっては、第１タイプビットは、サブフレームでのＭＳＢであり、第２タイプビットは、サブフレームでのＬＳＢであるが、これに限定されない。
【００２９】
例えば、ＲＧＢデータの場合、１バイトの上位４ビットは、下位４ビットに比べて重要な情報を有するが、このように相対的に重要なビットがＭＳＢとなり、相対的により重要ではないビットがＬＳＢとなる。但し、１バイトで上位何ビットがＭＳＢとなるかは、データの種類及び具現例によって変わり、１バイトでＭＳＢを除外した残りのビットは、何れもＬＳＢとなる。
【００３０】
図２は、本発明による受信確認フレームの生成方法の第２実施形態を説明するために示すフローチャートである。
【００３１】
ステップ２１０では、データフレームを受信する。
【００３２】
ステップ２２０では、その受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断する。
【００３３】
ステップ２３０では、ステップ２２０での判断結果、データフレームのサブフレームがＵＥＰモードでコーディングされていないと判断されれば、そのデータフレームに所定のサブフレームまたは少なくとも一つのＭＳＤＵの含まれた受信確認フレームを要請するデータ挿入ＡＣＫ要請フィールドが備えられているか否かを判断する。
【００３４】
このとき、データ挿入ＡＣＫ要請フィールドは、受信されたデータフレームのＭＡＣヘッダに備えられ、このようなＭＡＣヘッダには、ブロックＡＣＫ形態の受信確認フレームを要請するブロックＡＣＫ要請フィールドがさらに備えられることもある。
【００３５】
ステップ２３２では、そのデータフレームにデータ挿入ＡＣＫ要請フィールドが備えられた場合に、サブフレーム及び第１  ＡＣＫフィールドを備える受信確認フレームを生成する。
【００３６】
このとき、サブフレームの代りに、少なくとも一つのＭＳＤＵが受信確認フレームに含まれることもある。
【００３７】
ステップ２３４では、そのデータフレームにデータ挿入ＡＣＫ要請フィールドが備えられない場合に、第１  ＡＣＫフィールドのみを備える受信確認フレームを生成する。
【００３８】
ステップ２４０では、ステップ２２０での判断結果、データフレームのサブフレームがＵＥＰモードでコーディングされたと判断されれば、そのデータフレームにデータ挿入ＡＣＫ要請フィールドが備えられているか否かを判断する。
【００３９】
ステップ２４２では、そのデータフレームにデータ挿入ＡＣＫ要請フィールドが備えられた場合に、サブフレーム及び第２  ＡＣＫフィールドを備える受信確認フレームを生成する。
【００４０】
このとき、サブフレームの代りに、少なくとも一つのＭＳＤＵが受信確認フレームに含まれることもある。
【００４１】
ステップ２４４では、そのデータフレームにデータ挿入ＡＣＫ要請フィールドが備えられない場合に、第２  ＡＣＫフィールドのみを備える受信確認フレームを生成する。
【００４２】
図３は、本発明による受信確認フレーム構造の一実施形態を説明するために示す図である。図３を参照するに、本発明の一実施形態による受信確認フレーム構造は、ＭＡＣヘッダ３１０、サブヘッダ３２０及びＦＣＳ  ３３０フィールドを備える。
【００４３】
ＭＡＣヘッダ３１０は、ＭＡＣ階層で使われるヘッダである。
【００４４】
サブヘッダ３２０は、ＡＣＫ／ＮＡＣＫビットマップで表示された第１  ＡＣＫフィールド３２２，３２４で構成されるか、またはＭＳＢ  ＡＣＫビットマップ及びＬＳＢ  ＡＣＫビットマップで表示された第２  ＡＣＫフィールド３２２，３２４で構成されうる。
【００４５】
さらに具体的には、受信されたデータフレームに含まれたサブフレームがＥＥＰモードでコーディングされた場合には、サブヘッダ３２０がサブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールド３２２，３２４で構成され、受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされた場合には、サブヘッダ３２０がそれぞれサブフレームでのＭＳＢのための第２  ＡＣＫフィールド３２２とＬＳＢのための第２  ＡＣＫフィールド３２４とで構成されうる。
【００４６】
このように、本発明の一実施形態による受信確認フレーム構造を利用すれば、データフレームを受信した装置は、受信したデータフレームのサブフレームでのＭＳＢまたはＬＳＢのそれぞれに対する受信如何を独立的に通知できるという長所がある。
【００４７】
一方、具現例によっては、図３の実施形態のように、サブフレームの一つの受信如何についての情報が２回ずつ記録されうる。これは、サブフレームがＵＥＰモードでコーディングされた場合に、一つのサブフレームの受信如何を表すために２ビットが利用されるが、ＥＥＰモードでコーディングされたサブフレームの受信如何を表示する時にも、これと同じ数のビットを利用するためである。
【００４８】
但し、本発明による受信確認フレーム構造は、これに限定されず、サブフレームの一つの受信如何についての情報が第１  ＡＣＫフィールドに１回ずつしか記録されないこともある。
【００４９】
ＦＣＳフィールド３３０は、ＭＡＣヘッダ３１０及びサブヘッダ３２０のエラーを検出するためのフィールドである。
【００５０】
図４は、本発明による受信確認フレーム構造の第２実施形態を説明するために示す図である。図４には、ＭＳＤＵを備える受信確認フレーム構造が示されている。但し、受信確認フレームは、ＭＳＤＵの代りに、サブフレームを含むこともできる。
【００５１】
ＰＨＹヘッダ４１０には、ＭＳＤＵ  ４３０がＵＥＰモードでコーディングされていない場合に、そのＭＳＤＵ  ４３０に適用されたＭＣＳを表すＭＣＳフィールド（図示せず）が備えられる。
【００５２】
ＭＡＣサブヘッダ４２０は、ＵＥＰフィールド４２２、ブロックＡＣＫフィールド４２４及びＨＣＳ（Ｈｅａｄｅｒ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）フィールド４２６を備える。
【００５３】
ＵＥＰフィールド４２２は、ＭＳＤＵ  ４３０に適用されたＵＥＰモードと関連した情報を含み、ＵＥＰ可能フィールド４２２ａ及びＵＥＰ  ＭＣＳフィールド４２２ｂを含む。
【００５４】
ＵＥＰ可能フィールド４２２ａは、ＭＳＤＵ  ４３０がＵＥＰモードでコーディングされたか否かを表す。図４の実施形態では、ＵＥＰ可能フィールド４２２ａが０で表示されており、ＭＳＤＵがＵＥＰにコーディングされていない状態であることを表す。
【００５５】
ＵＥＰ  ＭＣＳフィールド４２２ｂは、ＵＥＰモードでコーディングされたＭＳＤＵに適用されたＭＣＳを表すフィールドであるが、本実施形態では、ＭＳＤＵ  ４３０がＵＥＰモードでコーディングされていないので、ＵＥＰ  ＭＣＳフィールド４２２ｂは使われない。
【００５６】
ブロックＡＣＫフィールド４２４は、受信されたデータフレームのサブフレームのそれぞれの受信如何を表すフィールドであって、受信確認フレームに含まれたＭＳＤＵ  ４３０とは関連のないフィールドである。
【００５７】
図４のブロックＡＣＫフィールド４２４は、サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールド４２４ａ，４２４ｂ，４２４ｃで構成されるが、受信されたデータフレームのサブフレームがＥＥＰモードでコーディングされた場合には、このようなにブロックＡＣＫフィールド４２４が第１  ＡＣＫフィールド４２４ａ，４２４ｂ，４２４ｃで構成される。また、図４のブロックＡＣＫフィールド４２４は、３２バイトで構成されて２５６ビットを有するので、２５６個のサブフレームに対する受信如何を表示しうる。但し、ブロックＡＣＫフィールド４２４の大きさは、３２バイトに限定されない。
【００５８】
ＨＣＳフィールド４２６は、ＵＥＰフィールド４２２及びブロックＡＣＫフィールド４２４のエラーを検出するためのＣＲＣコードであるＨＣＳが記録されるフィールドである。
【００５９】
ＭＳＤＵ  ４３０には、任意のデータが含まれるが、受信されたデータフレームに含まれたサブフレームに対応するデータが含まれることもある。例えば、受信されたデータフレームが画像会議と関連したデータであったならば、ＭＳＤＵ  ４３０にも画像会議と関連したデータが含まれる。また、受信されたデータフレームが動画と関連したものならば、ＭＳＤＵ  ４３０には、その動画を伝送した装置の電源をオンにするか、またはボリュームを調節するための制御信号が含まれる。
【００６０】
このように、本発明の一実施形態による受信確認フレーム構造を利用すれば、データフレームを受信した装置は、所定のデータと受信確認フレームとを別途に伝送する必要がなく、一つの受信確認フレームを利用して、所定のデータとブロックＡＣＫとを一度に伝送しうるという長所がある。
【００６１】
図４に示された受信確認フレーム構造での他のフィールドに対しては、ＩＥＥＥ  ８０２.１５.３Ｃ標準文書に説明されているので、このようなフィールドについての説明は省略する。
【００６２】
図５は、本発明による受信確認フレーム構造の第３実施形態を説明するために示す図である。図５を参照するに、ＵＥＰ可能フィールド５２２ａが１で表示されているが、これは、ＭＳＤＵ  ５３０がＵＥＰモードでコーディングされたということを意味する。
【００６３】
図４で前述したように、ＵＥＰ  ＭＣＳ  ５２２ｂには、ＭＳＤＵ  ５３０をＵＥＰモードによってコーディングする時に適用されたＭＣＳが記録される。
【００６４】
図５のブロックＡＣＫフィールド５２４は、ＭＳＢのための第２  ＡＣＫフィールド５２４ａ，５２４ｃ，５２４ｅとＬＳＢのための第２  ＡＣＫフィールド５２４ｂ，５２４ｄ，５２４ｆとで構成されるが、受信されたデータフレームのサブフレームがＵＥＰモードでコーディングされた場合に、ブロックＡＣＫフィールド５２４は、このような第２  ＡＣＫフィールド５２４ａ，５２４ｂ，５２４ｃ，５２４ｄ，５２４ｅ，５２４ｆで構成される。
【００６５】
また、図５のブロックＡＣＫフィールド５２４は、６４バイトで構成されるが、ＭＳＢのための第２  ＡＣＫフィールド５２４ａ，５２４ｃ，５２４ｅが３２バイト、ＬＳＢのための第２  ＡＣＫフィールド５２４ｂ，５２４ｄ，５２４ｆが３２バイトの大きさを有する。但し、ブロックＡＣＫフィールド４２４の大きさは、６４バイトに限定されない。
【００６６】
このような差異点を除いては、図５に示されたフィールドについての説明は、図４と同じであるので、これについての説明は省略する。
【００６７】
図６は、本発明による受信確認フレーム生成装置の一実施形態を説明するために示す図である。図６を参照するに、本発明の一実施形態による受信確認フレーム生成装置は、受信部６１０、判断部６２０及びフレーム生成部６３０を備える。
【００６８】
受信部６１０は、データフレームを受信する。
【００６９】
判断部６２０は、第１判断部６２２及び第２判断部６２４を備える。
【００７０】
第１判断部６２２は、受信されたデータフレームに含まれたサブフレームがＵＥＰモードでコーディングされたか否かを判断する。
【００７１】
第２判断部６２２は、所定のサブフレームまたは少なくとも一つのＭＳＤＵの含まれた受信確認フレームを要請するデータ挿入ＡＣＫ要請フィールドが受信されたデータフレームに含まれているか否かを判断する。
【００７２】
但し、判断部６２０は、第１判断部６２２のみで構成されることもある。
【００７３】
フレーム生成部６３０は、判断部６２０の判断に基づいて、サブフレームのそれぞれの受信如何を表す第１  ＡＣＫフィールド、またはサブフレームでの第１タイプビット及び第２タイプビットのそれぞれの受信如何を表す第２  ＡＣＫフィールドのうち一つを含む受信確認フレームを生成する。
【００７４】
一方、このような受信確認フレーム生成装置は、自身が生成できる受信確認フレームの種類を他の装置に通知することもできる。このとき、その受信確認フレーム生成装置が支援する受信確認フレーム生成能力についての情報を含む能力情報フレームが利用されうる。
【００７５】
図７は、本発明による能力情報フレームの一実施形態を説明するために示す図である。図７を参照するに、本発明の一実施形態による能力情報フレームは、全体能力フィールド７１０、長フィールド７２０及び能力情報ＩＤ  ７３０を備える。
【００７６】
全体能力フィールド７１０は、デバイス能力フィールド７１２及びＰＮＣ（Ｐｉｃｏｎｅｔ  Ｃｏｒｄｉｎａｔｏｒ）能力フィールド７１４を備える。
【００７７】
デバイス能力フィールド７１２は、受信確認フレーム生成装置が支援する能力を表すフィールドであって、データが挿入された受信確認フレームを生成できるか否か、ブロックＡＣＫを生成できるか否か、併合を行えるか否か及び双方向通信を支援するか否かについての情報を含みうる。
【００７８】
このとき、併合に関する情報は、ＭＳＤＵ併合、ＭＰＤＵ（ＭＡＣ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｅｔ）併合、ＰＰＤＵ（ＰＨＹ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）併合のうち、いかなる併合を行えるかについての情報を含みうる。
【００７９】
ＰＮＣ能力フィールド７１４は、ピコネット調整子としての能力を支援するか否かを表すフィールドである。
【００８０】
長フィールド７２０は、能力情報フレームの長さを表すフィールドである。
【００８１】
能力情報ＩＤ  ７３０は、能力情報フレームを識別するためのＩＤを表すフィールドである。
【００８２】
受信確認フレーム生成装置は、このような能力情報フレームを他の装置に伝送することによって、受信確認フレーム生成装置が支援できる能力を他の装置に通知しうる。
【００８３】
一方、前記本発明の実施形態は、コンピュータで実行できるプログラムで作成可能であり、コンピュータで読み取り可能な記録媒体を利用して、前記プログラムを動作させる汎用デジタルコンピュータで具現されうる。
【００８４】
前記コンピュータで読み取り可能な記録媒体は、マグネチック記録媒体（例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、フロッピー（登録商標）ディスク、ハードディスクなど）、光学的判読媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤなど）のような記録媒体を含む。本発明の少なくとも一つの一実施形態を含むキャリアウェーブ（例えば、インターネットを通じた伝送）がコンピュータで判読可能な記録媒体に臨時的にまたは永久的に保存されうる。本発明の権利範囲を超えずに、多様な方法で本発明の一実施形態によるコンピュータ基盤の命令の構成及び具現が具現されうる。
【００８５】
本発明では、特定用語を利用して例示的な実施形態について図示して説明したが、そのような実施形態と用語とは、本発明を説明するために利用されたものであり、請求項によって定義される本発明の権利範囲を限定するためのものと推定されてはならない。望ましい実施形態は、説明のために考慮したものに過ぎず、発明の目的を限定するために使用されてはならない。本発明の一実施形態によるＷＰＡＮは、高画質ビデオ及びオーディオファイルを伝送し、かつ受信できるホームエンタテインメントシステムのための有線またはケーブル代替技術のような多様なアプリケーションに適用されうる。
【００８６】
以上、本発明についてその望ましい実施形態を中心に説明した。当業者は、本発明が本発明の本質的な特性から逸脱しない範囲で変形された形態で具現されるということが分かるであろう。したがって、開示された実施形態は、限定的な観点ではなく、説明的な観点で考慮されねばならない。本発明の範囲は、前述した説明ではなく、特許請求の範囲に現れており、それと同等な範囲内にある全ての差異点は、本発明に含まれていると解釈されねばならない。
【産業上の利用可能性】
【００８７】
本発明は、無線ネットワーク関連の技術分野に適用可能である。
【図面の簡単な説明】
【００８８】
【図１】本発明による受信確認フレームの生成方法の一実施形態を説明するために示すフローチャートである。
【図２】本発明による受信確認フレームの生成方法の第２実施形態を説明するために示すフローチャートである。
【図３】本発明による受信確認フレーム構造の一実施形態を説明するために示す図である。
【図４】本発明による受信確認フレーム構造の第２実施形態を説明するために示す図である。
【図５】本発明による受信確認フレーム構造の第３実施形態を説明するために示す図である。
【図６】本発明による受信確認フレーム生成装置の一実施形態を説明するために示す図である。
【図７】本発明による能力情報フレームの一実施形態を説明するために示す図である。
【符号の説明】
【００８９】
６１０  受信部
６２０  判断部
６２２  第１判断部
６２４  第２判断部
６３０  フレーム生成部
【図１】
0005280781.tif 000002
【図２】
0005280781.tif 000003
【図３】
0005280781.tif 000004
【図４】
0005280781.tif 000005
【図５】
0005280781.tif 000006
【図６】
0005280781.tif 000007
【図７】
0005280781.tif 000008