JP6283113B2 - 無線ｌａｎにおけるパワーセーブモードに基づく動作方法及び装置 - Google Patents

Description

本発明は、無線通信に関し、より詳しくは、無線ＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＷＬＡＮ）におけるパワーセーブモードに基づいて動作する方法及び装置に関する。

ＩＥＥＥ８０２．１１標準では、無線ＬＡＮ ＳＴＡ（ｓｔａｔｉｏｎ）の寿命を増加させるためにパワーセーブメカニズム（ｐｏｗｅｒ ｓａｖｅ ｍｅｃｈａｎｉｓｍ）（または、パワーセーブモード（ｐｏｗｅｒ ｓａｖｅ ｍｏｄｅ））が使われることができる。パワーセーブモードに基づいて動作するＳＴＡは、パワー節約のためにアウェイク状態（ａｗａｋｅ ｓｔａｔｅ）またはドーズ状態（ｄｏｚｅ ｓｔａｔｅ）で動作できる。アウェイク状態は、フレームの送信または受信や、チャネルスキャニングのようなＳＴＡの正常動作が可能な状態である。それに対し、ドーズ状態は、電力消耗を極端に減らしてフレームの送信または受信が不可能であり、チャネルスキャニングも不可能な状態である。一般的に、ＳＴＡがパワーセーブモードで動作する時、ドーズ状態にあったＳＴＡは、必要な場合、アウェイク状態に切り替えて電力消耗を減らすことができる。

ＳＴＡがドーズ状態で長い間動作する場合、ＳＴＡの電力消耗が減る。したがって、ＳＴＡの寿命が増えることができる。しかし、ドーズ状態では、フレームの送信または受信が不可能である。したがって、ＳＴＡは、ドーズ状態に長い間とどまることができない。ドーズ状態でペンディングフレームが発生した場合、ＳＴＡは、アウェイク状態に切り替えてフレームをＡＰに送信することができる。しかし、ＳＴＡがドーズ状態にあり、ＳＴＡに送信するペンディングフレームがＡＰに存在する場合、ＳＴＡは、ＡＰからペンディングフレームを受信することができず、ＡＰにペンディングフレームが存在するということも知ることができない。したがって、ＳＴＡは、ＡＰにペンディングフレームの存在可否に対する情報を取得し、ＡＰにペンディングフレームを受信するために周期的にアウェイクモードに切り替えて動作できる。

ＡＰは、ＳＴＡのアウェイクモード動作タイミングに対する情報を取得し、ＳＴＡのアウェイクモード動作タイミングに合わせてＡＰにペンディングフレームの存在可否に対する情報を送信することができる。

具体的に、ドーズ状態のＳＴＡは、ＡＰから受信するフレームの存在可否に対する情報を受信するために、周期的にドーズ状態からアウェイク状態に切り替えてビーコンフレームを受信することができる。ＡＰは、ビーコンフレームに含まれているＴＩＭ（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｍａｐ）に基づいて各ＳＴＡに送信するフレームの存在可否に対して知らせることができる。ＴＩＭは、ＳＴＡに送信されるユニキャストフレームの存在を知らせるために使われ、ＤＴＩＭ（ｄｅｌｉｖｅｒｙ ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｍａｐ）は、ＳＴＡに送信されるマルチキャストフレーム／ブロードキャストフレームの存在を知らせるために使われることができる。

本発明の目的は、無線ＬＡＮにおけるパワーセーブモードに基づく動作方法を提供することにある。

本発明の他の目的は、無線ＬＡＮにおけるパワーセーブモードに基づく動作装置を提供することにある。

前述した本発明の目的を達成するための本発明の一側面による、無線ＬＡＮにおけるパワーセーブモードに基づく動作方法は、ＳＴＡが第１のサービス区間上で前記ＡＰに第１のトリガフレームを送信するステップ；前記ＳＴＡが前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信するステップ；前記ＳＴＡが前記ダウンリンクフレームの受信以後、第２のサービス区間上でＡＰからトラフィック指示情報（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を受信するステップ；前記ＳＴＡが前記第２のサービス区間上で前記トラフィック指示情報に基づいて前記ＡＰにペンディングダウンリンクフレーム（ｐｅｎｄｉｎｇ ｄｏｗｎｌｉｎｋ ｆｒａｍｅ）の存在可否を決定するステップ；及び、前記ペンディングダウンリンクフレームの存在可否に基づいて前記ＳＴＡがパワー節約のためのモードを決定するステップ；を含み、前記トラフィック指示情報は、前記第２のサービス区間上で前記ＡＰにより送信される前記ペンディングダウンリンクフレームの存在に対する情報を含む。

前述した本発明の目的を達成するための本発明の他の側面による、無線ＬＡＮにおけるパワーセーブモードに基づいて動作するＳＴＡ（ｓｔａｔｉｏｎ）において、前記ＳＴＡは、無線信号を送信または受信するために具現されたＲＦ部；及び、前記ＲＦ部と動作可能なように（ｏｐｅｒａｔｉｖｅｌｙ）連結されるプロセッサ；を含み、前記プロセッサは、第１のサービス区間上で前記ＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信し、前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信し、前記ダウンリンクフレームの受信以後、第２のサービス区間上でＡＰからトラフィック指示情報（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を受信し、前記第２のサービス区間上で前記トラフィック指示情報に基づいて前記ＡＰにペンディングダウンリンクフレーム（ｐｅｎｄｉｎｇ ｄｏｗｎｌｉｎｋ ｆｒａｍｅ）の存在可否を決定し、前記ペンディングダウンリンクフレームの存在可否に基づいてパワー節約のためのモードを決定するように具現され、前記トラフィック指示情報は、前記第２のサービス区間上で前記ＡＰにより送信される前記ペンディングダウンリンクフレームの存在に対する情報を含む。
本明細書は、例えば、以下の項目も提供する。
（項目１）
無線ＬＡＮにおけるパワーセーブモードに基づく動作方法は、
ＳＴＡ（ｓｔａｔｉｏｎ）が第１のサービス区間上でＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信するステップ；
前記ＳＴＡが前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信するステップ；
前記ＳＴＡが前記ダウンリンクフレームの受信以後、第２のサービス区間上でＡＰからトラフィック指示情報（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を受信するステップ；
前記ＳＴＡが前記第２のサービス区間上で前記トラフィック指示情報に基づいて前記ＡＰにペンディングダウンリンクフレーム（ｐｅｎｄｉｎｇ ｄｏｗｎｌｉｎｋ ｆｒａｍｅ）の存在可否を決定するステップ；及び、
前記ペンディングダウンリンクフレームの存在可否に基づいて前記ＳＴＡがパワー節約のためのモードを決定するステップ；を含み、
前記トラフィック指示情報は、前記第２のサービス区間上で前記ＡＰにより送信される前記ペンディングダウンリンクフレームの存在に対する情報を含む方法。
（項目２）
前記パワー節約のためのモードを決定するステップは、
前記ペンディングダウンリンクフレームが存在しない場合、前記ＳＴＡが前記モードをアクティブモード（ａｃｔｉｖｅ ｍｏｄｅ）からスリープモード（ｓｌｅｅｐ ｍｏｄｅ）に切り替えるステップ；及び、
前記ペンディングダウンリンクフレームが存在する場合、前記ＳＴＡが前記モードを前記アクティブモードに維持し、前記ペンディングダウンリンクフレームをモニタリングするステップ；を含むことを特徴とする項目１に記載の方法。
（項目３）
前記ＳＴＡが前記ＵＴＩＭの受信以後一定時間以内に前記ペンディングダウンリンクフレームを前記ＡＰから受信することができない場合、前記ＳＴＡが第２のトリガフレームを送信するステップをさらに含み、
前記第２のトリガフレームは、前記第２のサービス区間上で前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガすることを特徴とする項目１に記載の方法。
（項目４）
前記ＳＴＡが前記第２のトリガフレームの送信以後、最大再送信実行区間を考慮して前記ペンディングダウンリンクフレームをモニタリングするステップをさらに含み、
前記最大再送信実行区間は、前記ペンディングダウンリンクフレームに対する再送信が実行される最大時間区間であり、
前記最大再送信実行区間は、前記第２のサービス区間の満了時までであることを特徴とする項目３に記載の方法。
（項目５）
前記ＳＴＡが前記最大再送信実行区間まで前記ペンディングダウンリンクフレームを受信することができない場合、前記ＳＴＡが第３のサービス区間上で第３のトリガフレームを前記ＡＰに送信するステップをさらに含み、
前記第３のトリガフレームは、前記第３のサービス区間上で前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガすることを特徴とする項目４に記載の方法。
（項目６）
無線ＬＡＮにおけるパワーセーブモードに基づいて動作するＳＴＡ（ｓｔａｔｉｏｎ）において、前記ＳＴＡは、
無線信号を送信または受信するために具現されたＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）部；及び、
前記ＲＦ部と動作可能なように（ｏｐｅｒａｔｉｖｅｌｙ）連結されるプロセッサ；を含み、
前記プロセッサは、第１のサービス区間上でＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信し、
前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信し、
前記ダウンリンクフレームの受信以後、第２のサービス区間上でＡＰからトラフィック指示情報（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を受信し、
前記第２のサービス区間上で前記トラフィック指示情報に基づいて前記ＡＰにペンディングダウンリンクフレーム（ｐｅｎｄｉｎｇ ｄｏｗｎｌｉｎｋ ｆｒａｍｅ）の存在可否を決定し、
前記ペンディングダウンリンクフレームの存在可否に基づいてパワー節約のためのモードを決定するように具現され、
前記トラフィック指示情報は、前記第２のサービス区間上で前記ＡＰにより送信される前記ペンディングダウンリンクフレームの存在に対する情報を含むＳＴＡ。
（項目７）
前記プロセッサは、
前記ペンディングダウンリンクフレームが存在しない場合、前記モードをアクティブモード（ａｃｔｉｖｅ ｍｏｄｅ）からスリープモード（ｓｌｅｅｐ ｍｏｅｄ）に切り替え、
前記ペンディングダウンリンクフレームが存在する場合、前記モードを前記アクティブモードに維持し、前記ペンディングダウンリンクフレームをモニタリングするように具現されることを特徴とする項目６に記載のＳＴＡ。
（項目８）
前記プロセッサは、
前記ＵＴＩＭの受信以後一定時間以内に前記ペンディングダウンリンクフレームを前記ＡＰから受信することができない場合、前記ＳＴＡが第２のトリガフレームを送信するように具現され、
前記第２のトリガフレームは、前記第２のサービス区間上で前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガすることを特徴とする項目６に記載のＳＴＡ。
（項目９）
前記プロセッサは、
前記第２のトリガフレームの送信以後、最大再送信実行区間を考慮して前記ペンディングダウンリンクフレームをモニタリングするように具現され、
前記最大再送信実行区間は、前記ペンディングダウンリンクフレームに対する再送信が実行される最大時間区間であり、
前記最大再送信実行区間は、前記第２のサービス区間の満了時までであることを特徴とする項目８に記載のＳＴＡ。
（項目１０）
前記プロセッサは、前記最大再送信実行区間まで前記ペンディングダウンリンクフレームを受信することができない場合、前記ＳＴＡが第３のサービス区間上で第３のトリガフレームを前記ＡＰに送信するように具現され、
前記第３のトリガフレームは、前記第３のサービス区間上で前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガすることを特徴とする項目９に記載のＳＴＡ。

新しいパワーセーブモードを定義することによって、密集環境でリアルタイムトラフィック送信効率が増加され、ＳＴＡで消耗されるパワーが節約されることができる。

無線ＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＷＬＡＮ）の構造を示す概念図である。 本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。 本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。 本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。 本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。 本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。 本発明の実施例に係るＳＴＡのＵＴＩＭ ＩＤ割当方法を示す概念図である。 本発明の実施例に係るＵ−ＨＡＰＳＤを使用するＳＴＡの動作を示す概念図である。 本発明の実施例に係るＵ−ＨＡＰＳＤを使用するＡＰの動作を示す概念図である。 本発明の実施例に係るＳＴＡのアップリンクデータ送信方法を示す概念図である。 本発明の実施例に係るＳＴＡのアップリンクデータ送信方法を示す概念図である。 本発明の実施例に係るダウンリンク専用チャネルを介したダウンリンクフレームの送信を実行するためのＰＰＤＵフォーマットを示す概念図である。 本発明の実施例が適用されることができる無線装置を示すブロック図である。

図１は、無線ＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＷＬＡＮ）の構造を示す概念図である。

図１の上段は、ＩＥＥＥ（ｉｎｓｔｉｔｕｔｅ ｏｆ ｅｌｅｃｔｒｉｃａｌ ａｎｄ ｅｌｅｃｔｒｏｎｉｃ ｅｎｇｉｎｅｅｒｓ）８０２．１１のインフラストラクチャＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）の構造を示す。

図１の上段を参照すると、無線ＬＡＮシステムは、一つまたはそれ以上のインフラストラクチャＢＳＳ１００、１０５（以下、ＢＳＳ）を含むことができる。ＢＳＳ１００、１０５は、成功的に同期化されて互いに通信できるＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）１２５及びＳＴＡ１（Ｓｔａｔｉｏｎ）１００−１のようなＡＰとＳＴＡのセットであり、特定領域を示す概念ではない。ＢＳＳ１０５は、一つのＡＰ１３０に一つ以上の結合可能なＳＴＡ１０５−１、１０５−２を含むこともできる。

ＢＳＳは、少なくとも一つのＳＴＡ、分散サービス（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｅｒｖｉｃｅ）を提供するＡＰ１２５、１３０及び複数のＡＰを連結させる分散システム（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ、ＤＳ）１１０を含むことができる。

分散システム１１０は、複数のＢＳＳ１００、１０５を連結して拡張されたサービスセットであるＥＳＳ（ｅｘｔｅｎｄｅｄ ｓｅｒｖｉｃｅ ｓｅｔ）１４０を具現することができる。ＥＳＳ１４０は、一つまたは複数個のＡＰ１２５、１３０が分散システム１１０を介して連結されて構成された一つのネットワークを指示する用語として使われることができる。一つのＥＳＳ１４０に含まれるＡＰは、同じＳＳＩＤ（ｓｅｒｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を有することができる。

ポータル（ｐｏｒｔａｌ）１２０は、無線ＬＡＮネットワーク（ＩＥＥＥ８０２．１１）と他のネットワーク（例えば、８０２．Ｘ）との連結を実行するブリッジ役割を遂行することができる。

図１の上段のようなＢＳＳでは、ＡＰ１２５、１３０間のネットワーク及びＡＰ１２５、１３０とＳＴＡ１００−１、１０５−１、１０５−２との間のネットワークが具現されることができる。しかし、ＡＰ１２５、１３０なしでＳＴＡ間でもネットワークを設定して通信を実行することも可能である。ＡＰ１２５、１３０なしでＳＴＡ間でもネットワークを設定して通信を実行するネットワークをアドホックネットワーク（Ａｄ−Ｈｏｃ ｎｅｔｗｏｒｋ）または独立ＢＳＳ（ｉｎｄｅｐｅｎｄｅｎｔ ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ、ＩＢＳＳ）と定義する。

図１の下段は、ＩＢＳＳを示す概念図である。

図１の下段を参照すると、ＩＢＳＳは、アドホックモードで動作するＢＳＳである。ＩＢＳＳは、ＡＰを含まないため、中央で管理機能を遂行するエンティティ（ｃｅｎｔｒａｌｉｚｅｄ ｍａｎａｇｅｍ ｅｎｔｅｎｔｉｔｙ）がない。即ち、ＩＢＳＳにおいて、ＳＴＡ１５０−１、１５０−２、１５０−３、１５５−４、１５５−５は、分散された方式（ｄｉｓｔｒｉｂｕｔｅｄ ｍａｎｎｅｒ）に管理される。ＩＢＳＳにおいて、全てのＳＴＡ１５０−１、１５０−２、１５０−３、１５５−４、１５５−５は、移動ＳＴＡからなることができ、分散システムへの接続が許容されなくて自己完備的ネットワーク（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ ｎｅｔｗｏｒｋ）を構築する。

ＳＴＡは、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１標準の規定に従う媒体接続制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、ＭＡＣ）と無線媒体に対する物理階層（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）インターフェースを含む任意の機能媒体であり、広義では、ＡＰと非ＡＰ ＳＴＡ（Ｎｏｎ−ＡＰ Ｓｔａｔｉｏｎ）を両方とも含む意味として使われることができる。

ＳＴＡは、移動端末（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｌ）、無線機器（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、無線送受信ユニット（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ；ＷＴＲＵ）、ユーザ装備（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ）、移動局（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ；ＭＳ）、モバイル加入者ユニット（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）または単純にユーザ（ｕｓｅｒ）などの多様な名称で呼ばれることもある。

以下、本発明の実施例では、ＡＰからＳＴＡに送信されるデータ（または、フレーム）をダウンリンクデータ（または、ダウンリンクフレーム）、ＳＴＡからＡＰに送信されるデータ（または、フレーム）をアップリンクデータ（または、アップリンクフレーム）という用語で表現できる。また、ＡＰからＳＴＡへの送信は、ダウンリンク送信、ＳＴＡからＡＰへの送信は、アップリンク送信という用語で表現できる。

既存の無線ＬＡＮにおいて、パワーセーブモードで動作するＳＴＡは、Ｕ−ＡＰＳＤ（ｕｎｓｃｈｅｄｕｌｅｄ ａｕｔｏｍａｔｉｃ ｐｏｗｅｒ ｓａｖｅ ｄｅｌｉｖｅｒｙ）、Ｓ−ＡＰＳＤ（ｓｃｈｅｄｕｌｅｄ ａｕｔｏｍａｔｉｃ ｐｏｗｅｒ ｓａｖｅ ｄｅｌｉｖｅｒｙ）などに基づいて動作できる。ＳＴＡがＵ−ＡＰＳＤ、Ｓ−ＡＰＳＤを使用する場合、ＳＴＡでリアルタイムアプリケーション（ｒｅａｌｔｉｍｅ ａｐｐｌｉｃａｔｉｏｎ）（例えば、ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ））がサポートされにくい。

Ｕ−ＡＰＳＤでは、トリガフレーム（ｔｒｉｇｇｅｒ ｆｒａｍｅ）がサービス区間（ｓｅｒｖｉｃｅ Ｉｎｔｅｒｖａｌ）毎に送信される。したがって、密集（Ｄｅｎｓｅ）環境で多くの数のＳＴＡから送信されるトリガフレームは、チャネル混雑（ｃｈａｎｎｅｌ ｃｏｎｇｅｓｔｉｏｎ）を増加させることができる。具体的に、ＳＴＡがＵ−ＡＰＳＤを使用する場合、ＶｏＩＰサービスのジッター要求（ｊｉｔｔｅｒ ｒｅｑｕｉｒｅｍｅｎｔ）（例えば、３０ｍｓ）を満たすために、ＳＴＡは、ダウンリンクデータの受信のためにサービス区間（または、トリガ区間）（例えば、２０ｍｓ）間隔にアップリンクトリガフレームをＡＰに送信することができる。このような多くのアップリンクトリガフレームの送信は、高い密集度の無線ＬＡＮ（ｈｉｇｈ ｄｅｎｓｅ ＷＬＡＮ）環境でシグナルフラッディング（ｓｉｇｎａｌ ｆｌｏｏｄｉｎｇ）を誘発することができる。また、ＳＴＡがＳ−ＡＰＳＤを使用する場合、密集環境でスケジューリングされた送信が難しくて、サービス区間の間にダウンリンクデータがない、または送信の失敗時、ＳＴＡの電力消耗が増加する問題点がある。

以下、本発明の実施例では、既存のパワーセーブモード動作時の問題点を解決するためのＵ−ＨＡＰＳＤ（ｕｎｓｃｈｅｄｕｌｅｄ ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｐｏｗｅｒ ｓａｖｅ ｄｅｌｉｖｅｒｙ）が開示される。Ｕ−ＨＡＰＳＤは、リアルタイムサービス（例えば、双方向ビデオ（ｉｎｔｅｒａｃｔｉｖｅ ｖｉｄｅｏ）、ＶｏＩＰ等）をサポートするために使われることができる。

ＳＴＡがＵ−ＨＡＰＳＤを使用する場合、ＳＴＡは、アップリンクトリガフレームの頻繁な送信なしでリアルタイムアプリケーションに基づくサービスを受けることができる。ＳＴＡが頻繁にアップリンクトリガフレームを送信しないため、シグナルフラッディングは誘発されない。また、ＳＴＡがＵ−ＨＡＰＳＤを使用する場合、既存のパワーセーブモードで動作時よりＳＴＡのパワーが節約されることができる。本発明の実施例に係るパワーセーブモードに基づく送信方法は、Ｕ−ＨＡＰＳＤ（ｕｎｓｃｈｅｄｕｌｅｄ ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｐｏｗｅｒ ｓａｖｅ ｄｅｌｉｖｅｒｙ）という用語で表現されることができる。

図２は、本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。

図２を参照すると、Ｕ−ＨＡＰＳＤを使用するＳＴＡは、サービス区間（ｓｅｒｖｉｃｅ ｉｎｔｅｒｖａｌ）毎にＡＰにトリガフレーム２００を送信しない。

ＳＴＡは、Ｕ−ＨＡＰＳＤに基づく通信を開始（ｉｎｉｔｉａｔｉｏｎ）するために１番目のサービス区間ではトリガフレーム２００をＡＰに送信することができる。ＳＴＡにトリガフレームを送信してＵ−ＨＡＰＳＤに基づく通信を開始するサービス区間は、Ｕ−ＨＡＰＳＤ開始サービス区間２５０という用語で表現できる。もし、ＳＴＡがＵ−ＨＡＰＳＤ開始区間２５０でダウンリンクフレームを受信することができない場合、ＳＴＡは、１番目のサービス区間以後の区間もＵ−ＨＡＰＳＤ開始区間２５０に設定してトリガフレーム２００をＡＰに送信することもできる。

具体的に、ＳＴＡは、Ｕ−ＨＡＰＳＤ開始サービス区間２５０でＡＰにより送信されるダウンリンクフレームの送信をトリガするためのトリガフレーム２００をＡＰに送信することができる。ＡＰは、ＳＴＡからトリガフレーム２００を成功的に受信した場合、ＡＣＫフレーム２１０をＳＴＡに送信することができる。ＡＰは、ＡＣＫフレーム２１０の送信以後一定時間（例えば、ＳＩＦＳ（ｓｈｏｒｔ ｉｎｔｅｒ ｆｒａｍｅ ｓｐａｃｅ）後にダウンリンクフレーム（例えば、ダウンリンクデータ（または、管理（ｍａｎａｇｅｍｅｎｔ））フレーム）２２０をＳＴＡに送信することができる。ＡＰからダウンリンクフレーム２２０を受信したＳＴＡは、ダウンリンクフレーム２２０を成功的に受信した場合、ＡＣＫフレーム２２５をＡＰに送信することができる。

ＡＰにより送信されたダウンリンクフレーム２２０に含まれているＥＯＳＰ（ｅｎｄ ｏｆ ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）情報は、サービス区間の終了可否を指示することができる。ダウンリンクフレーム２２０に含まれているＥＯＳＰ情報がサービス区間の終了を指示する場合（例えば、ＥＯＳＰ＝１の場合）、ＳＴＡは、ダウンリンクフレーム２２０に対するＡＣＫフレーム２２５をＡＰに送信した後、ドーズ（ｄｏｚｅ）状態（または、スリープ状態）に切り替えられることができる。また、ダウンリンクフレーム２２０に含まれているＭｏｒｅＤａｔａ情報は、ＳＴＡが追加的に受信するデータの存在可否を指示することができる。ＭｏｒｅＤａｔａ情報が０の場合、サービス区間から追加的に受信するダウンリンクフレームが存在しないことを指示することができる。

本発明の実施例によると、Ｕ−ＨＡＰＳＤ開始サービス区間２５０以後区間から、ＳＴＡは、ＵＴＩＭ（Ｕ−ＨＡＰＳＤ ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｍａｐ）ベースの動作を実行することができる。ＡＰからＵＴＩＭ２３０を受信するサービス区間は、Ｕ−ＨＡＰＳＤ実行サービス区間２６０という用語で表現できる。ＡＰは、ＵＴＩＭ２３０をＳＴＡに送信することができる。以下、ＵＴＩＭ２３０を伝達するフレームをＵＴＩＭフレームという用語で表現する。ＵＴＩＭフレームは、既存に定義された無線ＬＡＮフレームを活用したフレームであって、ＵＴＩＭ２３０に対する情報を含むフレームであり、またはＵＴＩＭ２３０のために新しく定義されたフレームである。ＵＴＩＭは、トラフィック指示情報（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）という用語で表現されることもできる。

ＵＴＩＭフレームは、Ｕ−ＨＡＰＳＤ実行サービス区間２６０の開始時点またはサービス区間の開始時点を基準にして一定時間以内（例えば、１〜２ｍｓ）にＡＰによりＳＴＡに送信されることができる。ＵＴＩＭ２３０は、Ｕ−ＡＰＳＤベースのフレーム交換のために定義された情報であって、サービス区間を介してＡＰにより少なくとも一つのＳＴＡに送信されるペンディングダウンリンクフレーム（ダウンリンクデータ）２４０に対する情報を含むことができる。ＵＴＩＭ２３０は、Ｕ−ＨＡＰＳＤのために定義されたＴＩＭである。具体的に、本発明の実施例に係るＵ−ＨＡＰＳＤで使われるＵＴＩＭ２３０は、既存のブロードキャストされるＴＩＭと異なるようにマルチキャストされる情報である。ＵＴＩＭ２３０は、Ｕ−ＨＡＰＳＤを使用する少なくとも一つのＳＴＡにマルチキャストされる情報である。ＵＴＩＭ２３０は、Ｕ−ＨＡＰＳＤを使用するＳＴＡに送信されるペンディングダウンリンクフレームの存在可否に対する情報を多様な形態の情報フォーマット（例えば、ビットマップ）で含むことができる。

ＳＴＡは、ＵＴＩＭフレームに基づいてＡＰにペンディングダウンリンクデータ（ダウンリンクフレーム）２４０の存在可否を確認することができる。例えば、ＳＴＡは、ＡＰへの初期アクセス過程でＵＴＩＭ ＩＤを取得することができる。以後受信したＵＴＩＭフレームに含まれているＵＴＩＭ ＩＤがＳＴＡのＵＴＩＭ ＩＤを指示する場合、ＳＴＡは、受信したＵＴＩＭフレームに基づいてペンディングダウンリンクデータ２４０の存在可否を確認することができる。具体的に、ＵＴＩＭフレームの識別子フィールドに含まれているＵＴＩＭ ＩＤとＳＴＡのＵＴＩＭ ＩＤが同じ場合、ＳＴＡは、ＵＴＩＭフレームの以後フィールドを追加的にデコーディングして受信するダウンリンクフレーム（または、ダウンリンクデータ）２４０に対する情報を取得することができる。

ＵＴＩＭフレームがＳＴＡに送信されるペンディングダウンリンクデータ２４０の存在を指示する場合、ＳＴＡは、Ｕ−ＨＡＰＳＤ実行サービス区間でアウェイク状態を維持しながらダウンリンクフレーム２４０をモニタリングすることができる。Ｕ−ＨＡＰＳＤを使用するＳＴＡは、ＵＴＩＭの受信以後、別途のフレーム（例えば、ＰＳ（ｐｏｗｅｒ ｓａｖｅ）−ｐｏｌｌフレーム）の送信なしで媒体を介して送信されるダウンリンクフレーム２４０をモニタリングすることができる。それに対し、ＵＴＩＭフレームがＳＴＡに送信されるペンディングダウンリンクフレーム２４０の存在を指示しない場合、ＳＴＡは、アウェイク状態からドーズ状態に切り替えられて、Ｕ−ＨＡＰＳＤ実行サービス区間２６０上の残りの時間リソース上でドーズ状態を維持することができる。即ち、ＵＴＩＭフレーム（または、ＵＴＩＭ）に基づいて、ＳＴＡは、パワー状態（ｐｏｗｅｒ ｓｔａｔｅ）を決定することができる。

無線ＬＡＮ ＳＴＡの寿命を増加させるために、パワーセーブメカニズム（ｐｏｗｅｒ ｓａｖｅ ｍｅｃｈａｎｉｓｍ）（または、パワーセーブモード（ｐｏｗｅｒ ｓａｖｅ ｍｏｄｅ））が使われることができる。パワーセーブモードに基づいて動作するＳＴＡは、パワー節約のためにパワー状態をアウェイク状態またはドーズ状態に決定して動作できる。アウェイク状態は、フレームの送信または受信や、チャネルスキャニングのようなＳＴＡの正常動作が可能な状態である。それに対し、ドーズ状態は、電力消耗を極端に減らしてフレームの送信または受信が不可能であり、チャネルスキャニングも不可能な状態である。一般的に、ＳＴＡがパワーセーブモードで動作する時、ドーズ状態にあったＳＴＡは、必要な場合、アウェイク状態に切り替えて電力消耗を減らすことができる。アウェイク状態は、他の用語でアクティブモード（ａｃｔｉｖｅ ｍｏｄｅ）、ドーズ状態は、他の用語でスリープモード（ｓｌｅｅｐ ｍｏｄｅ）という用語で表現されることができる。アクティブモード（または、アウェイク状態）、スリープモード（または、ドーズ状態）は、ＳＴＡのパワー節約のためのモード（パワーセーブモード）（または、パワー状態）である。

同様に、Ｕ−ＨＡＰＳＤ実行サービス区間２６０でも、ＳＴＡは、受信したダウンリンクフレーム２４０のＥＯＳＰ情報及び／またはＭｏｒｅＤａｔａ情報を確認し、ダウンリンクフレーム２４０に対するＡＣＫフレーム２４５の送信以後動作状態の切り替え可否を決定することができる。即ち、ＥＯＳＰ情報及び／またはＭｏｒｅＤａｔａ情報が追加に受信するサービス区間の終了及び／またはダウンリンクデータの不存在を指示する場合、アウェイク状態からドーズ状態に切り替えることができる。それに対し、ＥＯＳＰ情報及び／またはＭｏｒｅＤａｔａ情報が追加に受信するサービス区間の非終了及び／またはダウンリンクデータの存在を指示する場合、アウェイク状態を維持して媒体をモニタリングすることができる。

即ち、無線ＬＡＮにおいて、パワーセーブモードに基づく動作方法は、ＳＴＡが第１のサービス区間（Ｕ−ＨＡＰＳＤ開始サービス区間）上でＡＰに第１のトリガフレームを送信し、ＳＴＡが第１のサービス区間上で第１のトリガフレームに基づいてＡＰにより送信されたダウンリンクフレームを受信することができる。ＳＴＡは、ダウンリンクフレームの受信以後、第２のサービス区間（Ｕ−ＨＡＰＳＤ実行サービス区間）上でＡＰからトラフィック指示情報（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を受信し、ＳＴＡが第２のサービス区間上でトラフィック指示情報に基づいてＡＰにペンディングダウンリンクフレーム（ｐｅｎｄｉｎｇ ｄｏｗｎｌｉｎｋ ｆｒａｍｅ）の存在可否を決定し、ペンディングダウンリンクフレームの存在可否に基づいてＳＴＡがパワー状態（ｐｏｗｅｒ ｓｔａｔｅ）を決定することができる。トラフィック指示情報は、第２のサービス区間上でＡＰにより送信されるペンディングダウンリンクフレームの存在に対する情報を含むことができる。

例外的な状況を除いて、Ｕ−ＨＡＰＳＤ実行サービス区間２６０は、連続的に実行されることができる。例外的な状況は、ダウンリンクフレームの再送信、ペンディングアップリンクフレームの存在などである。これに対しては具体的に後述する。

図３は、本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。

図３では、Ｕ−ＨＡＰＳＤ実行サービス区間でＳＴＡがＵＴＩＭの受信を失敗した場合、ＳＴＡとＡＰの動作が開示される。

図３を参照すると、ＡＰがチャネルアクセスを失敗してＵＴＩＭフレーム３００を送信することができない、またはＳＴＡがＵＴＩＭフレーム３００のデコーディングを失敗した場合、ＳＴＡは、トリガフレーム３１０をＡＰに送信することができる。ＳＴＡは、Ｕ−ＨＡＰＳＤ実行サービス区間でＡＰによるＵＴＩＭフレーム３００の送信タイミングを考慮してトリガフレーム３１０の送信タイミングを決定することができる。例えば、トリガフレーム３１０の送信タイミングは、他のＳＴＡの媒体の占有を制限するために、予想ＵＴＩＭフレームの送信タイミング以後ＳＩＦＳ以内である。または、トリガフレーム３１０の送信タイミングは、ＵＴＩＭフレーム３００以後に送信されるダウンリンクフレームの送信前に優先的に送信されるように決定されることができる。

ＵＴＩＭフレーム３００がＵ−ＨＡＰＳＤ実行サービス区間の開始以後一定時間以内にＳＴＡに送信されない、または受信したＵＴＩＭフレーム３００のデコーディングが失敗した場合、ＳＴＡは、トリガフレーム３１０を生成してＡＰに送信できる。

トリガフレーム３１０を受信したＡＰは、ＳＴＡにＡＣＫフレーム３２０を送信し、ＳＴＡに送信するペンディングダウンリンクフレーム３３０が存在する場合、ＳＴＡにダウンリンクフレームを送信することができる。

図４は、本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。

図４では、Ｕ−ＨＡＰＳＤ実行サービス区間でＳＴＡがダウンリンクフレームの受信を失敗した場合、ＳＴＡとＡＰの動作が開示される。

図４を参照すると、ＡＰがチャネルアクセスを失敗してダウンリンクフレーム４２０をＳＴＡに送信することができない、またはＳＴＡがダウンリンクフレーム４２０のデコーディングを失敗した場合、ＳＴＡは、トリガフレーム４４０をＡＰに送信することができる。ＳＴＡは、サービス区間でＡＰによるダウンリンクフレーム４２０の送信タイミングを考慮してトリガフレーム４４０の送信タイミングを決定することができる。例えば、トリガフレーム４４０の送信タイミングは、他のＳＴＡの媒体の占有を制限するために、予想ダウンリンクフレームの送信タイミング以後ＳＩＦＳ以内である。

ＳＴＡは、ＵＴＩＭフレーム４００の受信以後一定時間以内にダウンリンクフレーム４２０を受信することができない、または受信したダウンリンクフレーム４２０のデコーディングを失敗した場合、トリガフレーム４００を生成してＡＰに送信できる。ＳＴＡにより送信されるトリガフレーム４００は、ダウンリンクフレーム４２０の受信失敗を指示する情報（または、ダウンリンクフレームの再送信を要求する情報）を含むこともできる。

トリガフレーム４００を受信したＡＰは、ＡＣＫフレーム４６０をＳＴＡに送信し、ダウンリンクフレーム４８０をＳＴＡに送信することができる。ＡＰによりＡＣＫフレーム４６０の送信以後送信されるダウンリンクフレーム４８０は、以前に送信されたダウンリンクフレーム４２０と同じ、または以前に送信されたダウンリンクフレーム４２０に含まれているデータのうち一部が含まれる再送信フレームである。ダウンリンクフレームの再送信に対しては図５で具体的に開示する。

図５は、本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。

図５では、Ｕ−ＨＡＰＳＤ実行サービス区間でＳＴＡがＵＴＩＭフレーム５００の受信及びダウンリンクフレーム５１０の受信を失敗し、ＡＰがＳＴＡにより送信されたトリガフレーム５２０の受信を失敗した場合、ＡＰによるダウンリンクフレーム５１０の再送信が開始される。ダウンリンクフレームのみの受信を失敗した場合にも、同様な方式にＡＰによるダウンリンクフレーム５１０の再送信が実行されることができる。

図５を参照すると、ＡＰがチャネルアクセスを失敗してＵＴＩＭフレーム５００及びダウンリンクフレーム５１０を送信することができない、またはＳＴＡがＵＴＩＭフレーム５００及びダウンリンクフレーム５１０のデコーディングを失敗した場合、ＳＴＡは、トリガフレーム５２０をＡＰに送信することができる。ＡＰは、ダウンリンクフレーム５１０に対するＡＣＫフレームを受信することができない、またはトリガフレーム５２０も受信することができない場合、以前に送信したダウンリンクフレーム５１０に対する再送信を実行することができる。

ＡＰは、一定の回数または一定の時間区間上でのみダウンリンクフレーム５１０に対する再送信を実行することができる。例えば、ダウンリンクフレーム５１０の再送信は、一つのＵ−ＨＡＰＳＤ実行サービス区間５８０内でのみ制限的に実行されることができる。Ｕ−ＨＡＰＳＤ実行サービス区間５８０内でダウンリンクフレーム５１０の再送信が失敗した場合、以後サービス区間は、Ｕ−ＨＡＰＳＤ開始サービス区間５９０に設定され、ＳＴＡによるトリガフレーム５５０が送信された場合にのみ、ＡＰがダウンリンクフレーム５６０をＳＴＡに再送信することができる。

他の例として、ＡＰは、予め設定された最大再送信回数までのみダウンリンクフレーム５１０の再送信を実行し、最大再送信回数までダウンリンクフレーム５１０に対する再送信を実行した以後にはダウンリンクフレーム５１０に対する再送信を実行しない。

ＳＴＡは、ＡＰのダウンリンクフレーム５１０の再送信実行区間を考慮して該当区間の間に再送信されるダウンリンクフレーム５３０、５４０をモニタリングすることができる。ダウンリンクフレーム５１０の再送信が一つのサービス区間でのみ制限的に実行される場合、ダウンリンクフレーム５１０の最大再送信実行区間は、現在サービス区間の満了時までである。ダウンリンクフレーム５１０の再送信が設定された最大再送信回数までのみ実行される場合、ダウンリンクフレーム５１０の最大再送信実行区間は、ダウンリンクフレーム５１０の最大再送信回数で再送信時に必要な時間までである。

以下、本発明の実施例では、ダウンリンクフレームの再送信が一つのサービス区間でのみ制限的に実行される場合を仮定して説明する。

ＳＴＡが第１のサービス区間（Ｕ−ＨＡＰＳＤ実行サービス区間５８０）上でＡＰにより再送信されたダウンリンクフレーム５３０、５４０に対するデコーディングを失敗した場合、ＳＴＡは、第２のサービス区間（Ｕ−ＨＡＰＳＤ開始サービス区間５９０）上でトリガフレーム５５０をＡＰに再送信することができる。ＡＰは、第１のサービス区間上で再送信されたダウンリンクフレーム５３０、５４０に対するＡＣＫフレームをＳＴＡから受信することができない場合（または、ダウンリンクフレームに対する再送信を失敗した場合）、第２のサービス区間でＳＴＡから再送信されるトリガフレーム５５０をモニタリングすることができる。

ＡＰは、第２のサービス区間上で再送信されたトリガフレーム５５０を受信した場合、ＡＰは、第２のサービス区間上でもダウンリンクフレーム５６０に対する再送信を実行することができる。ＳＴＡに送信するペンディングとなっている追加的な他のダウンリンクデータ（または、ダウンリンクフレーム）５７０がＡＰに存在する場合、再送信されるダウンリンクフレーム５６０は、以後送信されるペンディングダウンリンクデータの存在を指示することができる。例えば、再送信されるダウンリンクフレーム５６０のＥＯＳＰ情報は０であり、ＭｏｒｅＤａｔａ情報は１である。ＳＴＡは、再送信されたダウンリンクフレーム５６０のＥＯＳＰ情報及び／またはＭｏｒｅＤａｔａ情報に基づいて、ＡＰにペンディングとなっている他のダウンリンクデータの存在を知ることができる。ＡＰにペンディングとなっている追加的なダウンリンクデータが存在する場合、ＳＴＡは、アウェイクモードを維持し、ＡＰから送信される他のダウンリンクフレーム５７０をモニタリングすることができる。

図６は、本発明の実施例に係るＵ−ＨＡＰＳＤ手順を示す概念図である。

図６では、Ｕ−ＨＡＰＳＤ開始サービス区間以後のＵ−ＨＡＰＳＤ実行サービス区間でＳＴＡに送信されたＵＴＩＭフレームが、ＳＴＡに対してペンディングとなっているダウンリンクデータ（ダウンリンクフレーム）が無いことを指示した場合、ＳＴＡの動作が開示される。

図６を参照すると、ＡＰにより送信されたＵＴＩＭ６００は、ＳＴＡに対してペンディングとなっているダウンリンクデータが存在しないことを指示することができる。例えば、ＵＴＩＭ６００は、仮想ビットマップ（ｖｉｒｔｕａｌ ｂｉｔｍａｐ）であり、ＳＴＡに対してペンディングとなっているダウンリンクデータの存在可否を指示することができる。

このような場合、ＳＴＡは、アウェイク状態からドーズ状態に状態を切り替えて電力消耗を減少させることができる。

図７は、本発明の実施例に係るＳＴＡのＵＴＩＭ ＩＤ割当方法を示す概念図である。

ＳＴＡは、ＵＴＩＭ ＩＤに基づいてＡＰにより送信されたＵＴＩＭがＳＴＡのためのＵＴＩＭかどうかを判断することができる。ＳＴＡのＵＴＩＭ ＩＤは、多様な方法により決定されることができる。例えば、ＳＴＡは、初期アクセスステップで、ＡＰによりＵＴＩＭ ＩＤの割当を受け、またはＵ−ＨＡＰＳＤに基づく通信の開始（ｉｎｉｔｉａｔｉｏｎ）時にＵＴＩＭ ＩＤの割当を受けることができる。ＵＴＩＭ ＩＤは、ＳＴＡのＰＡＩＤ（ｐａｒｔｉａｌ ａｓｓｏｃｉａｔｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）であり、またはＳＴＡのＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）アドレスである。

ＵＴＩＭ ＩＤがＰＡＩＤ（ｐａｒｔｉａｌ ａｓｓｏｃｉａｔｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）の場合、ＳＴＡは、ＵＴＩＭフレームを伝達する（ｃａｒｒｙｉｎｇ）ＰＰＤＵのシグナルフィールド（例えば、ＨＥ−ＳＩＧ−Ａフィールド）に含まれているＰＡＩＤ情報に基づいてＵＴＩＭフレームに含まれているＵＴＩＭがＳＴＡのためのものかどうかを決定することができる。

ＵＴＩＭ ＩＤがＭＡＣアドレスの場合、ＳＴＡは、ＵＴＩＭフレームのＭＡＣヘッダのＲＡ（ｒｅｃｅｉｖｉｎｇ ａｄｄｒｅｓｓ）フィールドを確認することができる。ＳＴＡは、ＵＴＩＭフレームのＭＡＣヘッダがＳＴＡのＭＡＣアドレスを指示するかどうかを判断して、ＵＴＩＭフレームに含まれているＵＴＩＭがＳＴＡのためのものかどうかを判断することができる。

ＵＴＩＭ ＩＤがＰＡＩＤまたはＭＡＣアドレスでない別途の識別情報により定義され、ＳＴＡは、ＵＴＩＭフレームを伝達する（ｃａｒｒｙｉｎｇ）ＰＰＤＵのシグナルフィールド（例えば、ＨＥ−ＳＩＧ−Ａフィールド）に含まれているＵＴＩＭ ＩＤに対する情報に基づいて、ＵＴＩＭフレームに含まれているＵＴＩＭがＳＴＡのためのものかどうかを決定することもできる。

図７では、初期アクセスステップで、ＡＰによるＵＴＩＭ ＩＤ割当方法が開示される。初期アクセスステップは、スキャニングステップ、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）ステップ、結合（ａｓｓｏｃｉａｔｉｏｎ）ステップを含むことができ、ＵＴＩＭ ＩＤは、結合ステップで、ＳＴＡに割り当てられることができる。

図７を参照すると、ＳＴＡは、結合要求フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅ）７００をＡＰに送信することができる。結合要求フレーム７００は、ＳＴＡのＵ−ＨＡＰＳＤ能力（ｃａｐａｂｉｌｉｔｙ）に対する情報を含むことができる。例えば、結合要求フレーム７００に含まれている拡張能力要素（ｅｘｔｅｎｄｅｄ ｃａｐａｂｉｌｉｔｉｅｓ ｅｌｅｍｅｎｔ）は、Ｕ−ＨＡＰＳＤが可能であることを指示する情報を含むことができる。また、結合要求フレーム７００のＱｏＳ情報（ＱｏＳ Ｉｎｆｏｒｍａｔｉｏｎ）は、ＡＣ（ａｃｃｅｓｓ ｃａｔｅｇｏｒｙ）別にＵ−ＨＡＰＳＤの可能可否を指示する情報を含むことができる。アクセスカテゴリは、トラフィックの送信優先順位を異なるように設定するために使われることができる。例えば、トラフィックのアクセスカテゴリは、ＡＣ＿ＶＯ（ｖｏｉｃｅ）、ＡＣ＿ＶＩ（ｖｉｄｅｏ）、ＡＣ＿ＢＥ（ｂｅｓｔ ｅｆｆｏｒｔ）、ＡＣ＿ＢＫ（ｂａｃｋｇｒｏｕｎｄ）のうち一つとして決定されることができ、トラフィックのアクセスカテゴリによって互いに異なるチャネルアクセスパラメタに基づいてチャネルアクセスが実行されることができる。

具体的に、結合要求フレーム７００のＱｏＳ情報（ＱｏＳ Ｉｎｆｏｒｍａｔｉｏｎ）は、ＡＣ＿ＶＯに対するＵ−ＨＡＰＳＤの可能可否に対する情報７２０、ＡＣ＿ＶＩに対するＵ−ＨＡＰＳＤの可能可否に対する情報７３０、ＡＣ＿ＢＫに対するＵ−ＨＡＰＳＤの可能可否に対する情報７４０及びＡＣ＿ＢＥに対するＵ−ＨＡＰＳＤの可能可否に対する情報７５０を含むことができる。即ち、アクセスカテゴリ別にＵ−ＨＡＰＳＤの可能可否が決定されることができる。

ＡＰは、ＳＴＡに結合応答フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）７１０を送信してＵＴＩＭ ＩＤを割り当てることができる。ＡＰにより割り当てられるＵＴＩＭ ＩＤは、前述したように、ＰＡＩＤ、ＭＡＣアドレスまたは別途のＵＴＩＭのための識別情報である。ＵＴＩＭ ＩＤがＰＡＩＤ、ＭＡＣアドレスの場合、結合応答フレーム７１０は、ＵＴＩＭ ＩＤに対する情報を別途に送信しない。

ＵＴＩＭ送信区間は、サービス区間の開始点を基準にして以後１〜２ｍｓに対応される予め決められた時間区間である場合もあり、ＵＴＩＭ送信区間に対する情報もＡＰによりＳＴＡに送信されることができる。ＡＰは、ＳＴＡの初期アクセス手順時に送信されるフレーム（例えば、結合応答フレーム７１０）を介してＵＴＩＭ送信区間に対する情報をＳＴＡに送信することができる。

図８は、本発明の実施例に係るＵ−ＨＡＰＳＤを使用するＳＴＡの動作を示す概念図である。

図８を参照すると、ＳＴＡは、トリガフレームをＡＰに送信することができる。

Ｕ−ＨＡＰＳＤ開始サービス区間では、ＳＴＡによりトリガフレームが送信されることができる（ステップＳ８００）。トリガフレームは、Ｕ−ＨＡＰＳＤ手順の開始（ｉｎｉｔｉａｔｉｏｎ）のために使われることができる。

Ｕ−ＨＡＰＳＤ開始サービス区間で、ＳＴＡがＡＰからトリガフレームに対するＡＣＫフレームを受信した場合（ステップＳ８０５）、ＳＴＡは、ＡＰにより送信されるダウンリンクフレームをモニタリングすることができる（ステップＳ８１０）。

ＳＴＡがＵ−ＨＡＰＳＤ開始サービス区間でダウンリンクフレームを受信した場合（ステップＳ８１５）、以後サービス区間をＵ−ＨＡＰＳＤ実行サービス区間に設定して、Ｕ−ＨＡＰＳＤ実行サービス区間上のＵＴＩＭ送信区間でＵＴＩＭの送信をモニタリングすることができる（ステップＳ８２０）。

ＳＴＡがＵ−ＨＡＰＳＤ開始サービス区間でダウンリンクフレーム（または、ダウンリンクデータ）を受信することができない場合（ステップＳ８１５）、ＳＴＡは、Ｕ−ＨＡＰＳＤ開始サービス区間以後のサービス区間を再びＵ−ＨＡＰＳＤ開始サービス区間に設定してトリガフレームを送信することができる（ステップＳ８２５）。

即ち、Ｕ−ＨＡＰＳＤ開始サービス区間上で、ＳＴＡがＡＰからダウンリンクフレーム（または、ダウンリンクデータ）を受信したかどうか（ステップＳ８１５）によって、Ｕ−ＨＡＰＳＤ開始サービス区間以後のサービス区間がＵ−ＨＡＰＳＤ開始サービス区間またはＵ−ＨＡＰＳＤ実行サービス区間のうち一つとして設定されることができる。

ＳＴＡがＵ−ＨＡＰＳＤ実行サービス区間上のＵＴＩＭ送信区間でＵＴＩＭを受信し（ステップＳ８３０）、ＵＴＩＭがＳＴＡに対してペンディングとなっているダウンリンクデータの存在を指示する場合（ステップＳ８３５）、ＳＴＡは、アウェイク状態でＡＰから送信されるダウンリンクフレームをモニタリングして受信することができる（ステップＳ８４０）。

ＳＴＡがＵ−ＨＡＰＳＤ実行サービス区間上のＵＴＩＭ送信区間でＵＴＩＭを受信し（ステップＳ８３０）、ＵＴＩＭがＳＴＡに対してペンディングとなっているダウンリンクデータの存在を指示しない場合、ＳＴＡは、アウェイク状態からドーズ状態に切り替えて、ＵＴＩＭの受信以後に対応されるサービス区間上でドーズ状態を維持することができる（ステップＳ８４５）。

もし、ＳＴＡが送信したトリガフレームに対するＡＣＫフレームを受信することができない場合（ステップＳ８０５）、ＳＴＡは、ＡＰにトリガフレームを再送信することができる。ＳＴＡは、設定された最大再送信回数ほどトリガフレームのＡＰへの再送信の実行可否を判断し（ステップＳ８５０）、トリガフレームをＡＰに再送信することができる（ステップＳ８５５）。

即ち、ＳＴＡは、設定された最大再送信回数ほどトリガフレームの再送信を実行しない場合（ステップＳ８５０）、ＳＴＡは、トリガフレームに対するＡＣＫフレームを受信する時までトリガフレームを最大再送信回数以内で送信することができる（ステップＳ８５５）。

ＳＴＡがトリガフレームに対するＡＣＫフレームを受信することができなくてＳＴＡが設定された最大再送信回数ほどトリガフレームのＡＰへの再送信を実行した場合、ＳＴＡは、Ｕ−ＨＡＰＳＤに基づく通信を実行する他のチャネルをスキャニングすることができる（ステップＳ８６０）。

図９は、本発明の実施例に係るＵ−ＨＡＰＳＤを使用するＡＰの動作を示す概念図である。

図９を参照すると、ＡＰは、Ｕ−ＨＡＰＳＤ開始サービス区間でＳＴＡにより送信されるトリガフレームをモニタリングすることができる（ステップＳ９００）。

ＡＰは、Ｕ−ＨＡＰＳＤ開始サービス区間でトリガフレームを受信した場合（ステップＳ９０５）、トリガフレームに対する応答としてＡＣＫフレームをＳＴＡに送信することができる（ステップＳ９１０）。

ＡＰは、ＳＴＡに送信するペンディングダウンリンクデータ（または、バッファされた（ｂｕｆｆｅｒｅｄ）ダウンリンクデータ）の存在可否を判断することができる（ステップＳ９１５）。

ＳＴＡに送信するペンディングダウンリンクデータが存在する場合、ＡＰは、Ｕ−ＨＡＰＳＤ開始サービス区間でダウンリンクフレームを介してダウンリンクデータをＳＴＡに送信することができる（ステップＳ９２０）。

ＳＴＡに送信するペンディングダウンリンクデータが存在しない場合（ステップＳ９１５）、ＡＰは、Ｕ−ＨＡＰＳＤ開始サービス区間でナルデータパケット（ｎｕｌｌ ｄａｔａ ｐａｃｋｅｔ）をＳＴＡに送信することができる（ステップＳ９２５）。ナルデータパケットは、ＭＰＤＵ（ＭＡＣ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）でＭＡＣヘッダを除外したＭＳＤＵ（ＭＡＣ ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）である。

ＳＴＡは、Ｕ−ＨＡＰＳＤ開始サービス区間でＡＰにより送信されるダウンリンクフレーム（または、ダウンリンクデータ）を受信する場合、Ｕ−ＨＡＰＳＤ開始サービス区間以後のサービス区間をＵ−ＨＡＰＳＤ実行サービス区間に決定してＵＴＩＭをモニタリングすることができる。したがって、ＡＰは、Ｕ−ＨＡＰＳＤ開始サービス区間上でナルデータパケットをＳＴＡに送信して、ナルデータパケットに対するＡＣＫフレームを受信した後、Ｕ−ＨＡＰＳＤ開始サービス区間以後のサービス区間をＵ−ＨＡＰＳＤ実行サービス区間に設定してＵＴＩＭを送信することができる（ステップＳ９３０）。

ＡＰにより送信されるＵＴＩＭ情報は、Ｕ−ＨＡＰＳＤ実行サービス区間上でＳＴＡにより受信されるダウンリンクデータの存在可否に対する情報を含むことができる。

ＳＴＡに送信されるペンディングダウンリンクデータがＡＰに存在しない場合（ステップＳ９３５）、ＡＰは、次のＵ−ＨＡＰＳＤ実行サービス区間上で再びＵＴＩＭフレームを送信することができる（ステップＳ９３０）。

ＳＴＡに送信されるペンディングダウンリンクデータがＡＰに存在する場合（ステップＳ９３５）、ＡＰは、ＵＴＩＭフレームの送信後、ダウンリンクデータを含むダウンリンクフレームをＳＴＡに送信することができる（ステップＳ９４０）。ダウンリンクフレームの送信以後、ＡＰは、ダウンリンクフレームに対するＡＣＫフレームの送信可否によってダウンリンクフレームを再送信することができる。

ＡＰは、ダウンリンクフレームに対するＡＣＫフレームを受信し（ステップＳ９４５）、ＳＴＡに追加的に送信される追加ダウンリンクフレームが存在する場合、追加ダウンリンクフレームを送信することができる。ＡＰは、ダウンリンクフレームに対するＡＣＫフレームを受信して、ＳＴＡに追加的に送信される追加ダウンリンクフレームが存在しない場合、現在Ｕ−ＨＡＰＳＤ実行サービス区間が満了された後、次のＵ−ＨＡＰＳＤ実行サービス区間で再びＵＴＩＭフレームを送信することができる。

ＡＰは、ダウンリンクフレームに対するＡＣＫフレームを受信することができない場合（ステップＳ９４５）、ＡＰは、ダウンリンクフレームに対する再送信手順を実行することができる。前述したように、ＡＰは、Ｕ−ＨＡＰＳＤ実行サービス区間を終了しない（ステップＳ９５０）、または最大再送信回数を超えない場合（ステップＳ９６０）、ダウンリンクフレームをＳＴＡに再送信することができる（ステップＳ９７０）。

ＡＰは、Ｕ−ＨＡＰＳＤ実行サービス区間を終了し、または最大再送信回数を超えた場合（ステップＳ９６０）、次のサービス区間をＵ−ＨＡＰＳＤ開始サービス区間に設定し、ＳＴＡから送信されるトリガフレームをモニタリングしてＳＴＡによりトリガフレームが送信された場合（ステップＳ９５５、Ｓ９６５）、ダウンリンクフレームに対する再送信を実行することができる。

図１０は、本発明の実施例に係るＳＴＡのアップリンクデータ送信方法を示す概念図である。

図１０では、Ｕ−ＨＡＰＳＤ実行サービス区間上でＳＴＡにペンディングアップリンクデータが発生した場合、ＳＴＡがアップリンクデータを含むアップリンクフレーム１０００をＡＰに送信する方法が開示される。具体的に、ＵＴＩＭ受信前にＳＴＡ上でアップリンクデータが生成されてペンディングとなっている場合、アップリンクフレーム１０００の送信方法が開示される。

図１０を参照すると、ＳＴＡは、再びＵ−ＨＡＰＳＤ開始サービス区間と同様に、サービス区間でペンディングデータを含むアップリンクフレーム１０００を優先的に送信することができる。ＳＴＡによりアップリンクフレーム１０００が送信されるサービス区間は、Ｕ−ＨＡＰＳＤフォールバックサービス区間１０５０という用語で表現されることができる。

Ｕ−ＨＡＰＳＤフォールバックサービス区間１０５０で、ＳＴＡは、ＡＰから送信されるＵＴＩＭの送信タイミングより速くチャネルアクセスを実行してアップリンクフレーム１０００をＡＰに送信することができる。

ＳＴＡからアップリンクフレーム１０００を受信したＡＰは、アップリンクフレーム１０００に対するＡＣＫフレーム１０２０をＳＴＡに送信することができる。ＳＴＡに送信するペンディングダウンリンクデータが存在する場合、ＡＰは、ＡＣＫフレームの送信以後、ダウンリンクフレーム１０４０を送信することができる。

図１１は、本発明の実施例に係るＳＴＡのアップリンクデータ送信方法を示す概念図である。

図１１では、Ｕ−ＨＡＰＳＤ実行サービス区間上でＳＴＡにペンディングアップリンクデータが発生した場合、ＳＴＡがアップリンクデータを含むアップリンクフレーム１１００をＡＰに送信する方法に対して開示する。具体的に、ＵＴＩＭ受信してダウンリンクフレームを受信した以後にアップリンクデータが生成されてペンディングとなっている場合、アップリンクフレーム１１００の送信方法が開示される。

図１１を参照すると、ＡＰにより送信されたダウンリンクフレーム１１２０に含まれているＥＯＳＰが１に設定されたため、ＳＴＡは、Ｕ−ＨＡＰＳＤ実行サービス区間の残ったサービス区間をドーズ状態に切り替えることができる。ＳＴＡは、次のＵ−ＨＡＰＳＤ実行サービス区間をＵ−ＨＡＰＳＤフォールバックサービス区間１１５０に設定してＵＴＩＭの送信タイミングより速くチャネルアクセスを実行してアップリンクフレームを送信することができる。

ＳＴＡは、リアルタイムトラフィックの性格に対して区分できる。リアルタイムトラフィックは、ライブビデオ（ｌｉｖｅ ｖｉｄｅｏ）、バッファリングされたビデオ（ｂｕｆｆｅｒｅｄ ｖｉｄｅｏ）、双方向ビデオ（ｉｎｔｅｒａｃｔｉｖｅ ｖｉｄｅｏ）（例えば、ビデオコンファレンス（ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｉｎｇ））及びボイス（ｖｏｉｃｅ｝などに区分されることができる。

本発明の実施例では、リアルタイムサービスに使われることができるＵ−ＨＡＰＳＤ手順に対して開示した。Ｕ−ＨＡＰＳＤ手順は、パワーセーブモードで駆動されるＳＴＡのために使われることができる。

既存のアクセスクラス（ａｃｃｅｓｓ ｃｌａｓｓ）、アクセスカテゴリまたはＴＩＤ（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）によっては、リアルタイムトラフィックのカテゴリを具体的に区分することが不可能である。即ち、既存のアクセスクラス、アクセスカテゴリまたはＴＩＤは、ライブビデオ、バッファリングされたビデオ、双方向ビデオまたはボイス（ｖｏｉｃｅ｝などのようなリアルタイムトラフィックのカテゴリを細部的に区分するためのＡＣ及びＴＩＤを定義していない。

既存の技術によっては、ＳＴＡがリアルタイムトラフィックの各々に対する互いに異なるパワーセーブモードを使用して動作することが不可能である。ＳＴＡは、上位端から下りるトラフィックがライブビデオか、またはバッファリングされたビデオか、または双方向ビデオかに対して知ることができない。

したがって、本発明の実施例では、ＳＴＡがリアルタイムトラフィックのカテゴリを区分するための方法を下記のように実行することができる。

まず、ＳＴＡは、ドメイン名に基づいてリアルタイムトラフィックのカテゴリを区分することができる。各ドメインに対応されるウェブサイトで提供されるサービスの性格は、互いに異なり、それによって提供されるリアルタイムトラフィックのカテゴリも異なる。

例えば、ドメイン名が の場合、リアルタイムトラフィックのカテゴリはライブビデオであり、ドメイン名が の場合、リアルタイムトラフィックのカテゴリはバッファリングされたビデオであり、ドメイン名が の場合、リアルタイムトラフィックのカテゴリはブラウジング（ｂｒｏｗｓｉｎｇ）データであると判断されることができる。

サービスのために連結されたドメイン名がＭＬＭＥプリミティブ（ｐｒｉｍｉｔｉｖｅ）に基づいてＳＴＡに送信され、ＳＴＡは、送信または受信されるリアルタイムトラフィックのカテゴリを区分することができる。

本発明の他の実施例によると、ＯＳ ＩＤ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ ＩＤ）（例えば、アンドロイド（Ａｎｄｒｏｉｄ）またはｉＯＳ）またはアプリケーションＩＤ（ａｐｐｌｉｃａｔｉｏｎ ＩＤ、ＡＰ ＰＩＤ）（例えば、Ｓｋｙｐｅ、ＭＬＢ ＴＶ ａｐｐ）の組合せでリアルタイムトラフィックのカテゴリが区分されることもできる。

ＳＴＡは、ＯＳ ＩＤとＡＰＰ ＩＤに基づいてリアルタイムトラフィックを区分することができる。例えば、ＳＴＡがＭＬＢ ＴＶ ａｐｐを実行した場合、ＳＴＡにＯＳ ＩＤ（例えば、アンドロイド指示識別子）とＡＰＰ ＩＤ（ＭＬＢ ＴＶ指示識別子）をＭＬＭＥプリミティブに知らせることで、ＳＴＡは、送受信するリアルタイムトラフィックを区分することができるようにする。

ＳＴＡは、リアルタイムトラフィックのカテゴリによってパワーセーブモードを選択することができる。例えば、ＳＴＡは、リアルタイムトラフィックのカテゴリによって本発明の実施例に係るＵ−ＨＡＰＳＤを使用するだけでなく、ＰＳ−Ｐｏｌｌ、Ｕ−ＡＰＳＤ、Ｓ−ＡＰＳＤ ａｎｄ ＰＳＭＰのうち一つを使用することができる。

図１２は、本発明の実施例に係るフレームを伝達するＰＰＤＵフォーマットを示す概念図である。

図１２では、本発明の実施例に係るＰＰＤＵフォーマットに対して開示する。ＰＰＤＵフォーマットのＰＰＤＵヘッダは、ＵＴＩＭフレームを受信するＳＴＡのＵＴＩＭ ＩＤ情報を含むことができる。ＰＰＤＵヘッダは、ＰＰＤＵのＰＨＹヘッダ及びＰＨＹプリアンブルを含む意味で使われることができる。

図１２の上段を参照すると、ダウンリンクＰＰＤＵのＰＰＤＵヘッダは、Ｌ−ＳＴＦ（ｌｅｇａｃｙ−ｓｈｏｒｔ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、Ｌ−ＬＴＦ（ｌｅｇａｃｙ−ｌｏｎｇ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、Ｌ−ＳＩＧ（ｌｅｇａｃｙ−ｓｉｇｎａｌ）、ＨＥ−ＳＩＧ Ａ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ−ｓｉｇｎａｌ Ａ）、ＨＥ−ＳＴＦ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ−ｓｈｏｒｔ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、ＨＥ−ＬＴＦ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ−ｌｏｎｇ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、ＨＥ−ＳＩＧ Ｂ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ−ｓｉｇｎａｌ−Ｂ）を含むことができる。 ＰＰＤＵ ヘッダにおいて、Ｌ−ＳＩＧまではレガシ部分（ｌｅｇａｃｙ ｐａｒｔ）と、Ｌ−ＳＩＧ以後のＨＥ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ）部分（ＨＥ ｐａｒｔ）と、に区分されることができる。

Ｌ−ＳＴＦ１２００は、短いトレーニングＯＦＤＭシンボル（ｓｈｏｒｔ ｔｒａｉｎｉｎｇ ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ ｓｙｍｂｏｌ）を含むことができる。Ｌ−ＳＴＦ１２００は、フレーム探知（ｆｒａｍｅ ｄｅｔｅｃｔｉｏｎ）、ＡＧＣ（ａｕｔｏｍａｔｉｃ ｇａｉｎ ｃｏｎｔｒｏｌ）、ダイバーシティ探知（ｄｉｖｅｒｓｉｔｙ ｄｅｔｅｃｔｉｏｎ）、コース周波数／時間同期化（ｃｏａｒｓｅ ｆｒｅｑｕｅｎｃｙ／ｔｉｍｅ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）のために使われることができる。

Ｌ−ＬＴＦ１２１０は、長いトレーニングＯＦＤＭシンボル（ｌｏｎｇ ｔｒａｉｎｉｎｇ ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ ｓｙｍｂｏｌ）を含むことができる。Ｌ−ＬＴＦ１２１０は、ファイン周波数／時間同期化（ｆｉｎｅ ｆｒｅｑｕｅｎｃｙ／ｔｉｍｅ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）及びチャネル予測のために使われることができる。

Ｌ−ＳＩＧ１２２０は、制御情報を送信するために使われることができる。Ｌ−ＳＩＧ１２２０は、データ送信率（ｒａｔｅ）、データ長さ（ｌｅｎｇｔｈ）に対する情報を含むことができる。

本発明の実施例によると、ＨＥ−ＳＩＧ Ａ１２３０は、ＵＴＩＭフレームを受信するＳＴＡのＵＴＩＭ ＩＤ情報を含むことができる。また、ＨＥ−ＳＩＧ Ａ１２３０は、ＵＴＩＭ送信区間に対する情報を含むこともできる。

または、ダウンリンクチャネルがＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ ａｃｃｅｓｓ）に基づいて複数のＳＴＡに分けて割り当てられる場合、ＨＥ−ＳＩＧ Ａ１２３０は、複数のＳＴＡの各々に割り当てられたダウンリンク専用動作チャネルに対する情報を含むことができる。ダウンリンクチャネルは、複数の下位ダウンリンクチャネルを含むことができる。例えば、ＯＦＤＭＡに基づいて、４０ＭＨｚのダウンリンクチャネルのうち、２０ＭＨｚは、ＳＴＡ１にダウンリンクフレームを送信するために使われる第１の下位ダウンリンクチャネルに割り当てられ、残りの２０ＭＨｚは、ＳＴＡ２にダウンリンクフレームを送信するための第２の下位ダウンリンクチャネルに割り当てられることができる。ＳＴＡ１及びＳＴＡ２の各々は、第１の下位ダウンリンクチャネル及び第２の下位ダウンリンクチャネルの各々上でＵ−ＨＡＰＳＤ動作を実行することもできる。

また、Ｈ−ＳＩＧ Ａ１２３０は、ダウンリンクＰＰＤＵを受信するターゲットＳＴＡを指示するためのＳＴＡの識別情報を含むことができる。複数のＳＴＡが同じＵ−ＨＡＰＳＤ区間上で動作できる。このような場合、ＳＴＡは、ダウンリンクＰＰＤＵのＨ−ＳＩＧ Ａに含まれているＳＴＡの識別子情報に基づいて、ダウンリンクＰＰＤＵがＳＴＡをターゲットとしたＰＰＤＵかどうかを判断することができる。ダウンリンクＰＰＤＵのＨ−ＳＩＧ Ａに基づいてＳＴＡが指示された場合、ＳＴＡは、ダウンリンクＰＰＤＵに対する追加的なデコーディングを実行することができる。ＨＥ−ＳＴＦ１２４０は、ＭＩＭＯ（ｍｕｌｔｉｌｐｌｅ ｉｎｐｕｔ ｍｕｌｔｉｐｌｅ ｏｕｔｐｕｔ）環境またはＯＦＤＭＡ環境で自動利得制御推定（ａｕｔｏｍａｔｉｃ ｇａｉｎ ｃｏｎｔｒｏｌ ｅｓｔｉｍａｔｉｏｎ）を向上させるために使われることができる。

ＨＥ−ＬＴＦ１２５０は、ＭＩＭＯ環境またはＯＦＤＭＡ環境でチャネルを推定するために使われることができる。

ＨＥ−ＳＩＧ Ｂ１２６０は、各ＳＴＡに対するＰＳＤＵ（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）の長さＭＣＳ（ｍｏｄｕｌａｔｉｏｎ ａｎｄ ｃｏｄｉｎｇ ｓｃｈｅｍｅ）に対する情報及びテールビットなどを含むことができる。

ＨＥ−ＳＴＦ１２４０及びＨＥ−ＳＴＦ１２４０以後のフィールドに適用されるＩＦＦＴの大きさと、ＨＥ−ＳＴＦ１２４０以前のフィールドに適用されるＩＦＦＴの大きさは、互いに異なる。例えば、ＨＥ−ＳＴＦ１２４０及びＨＥ−ＳＴＦ１２４０以後のフィールドに適用されるＩＦＦＴの大きさは、ＨＥ−ＳＴＦ１２４０以前のフィールドに適用されるＩＦＦＴの大きさより４倍大きい。ＳＴＡがＵＴＩＭフレームを受信した場合、ＳＴＡは、ＵＴＩＭフレームのＨＥ−ＳＩＧ Ａ１２３０をデコーディングし、ＨＥ−ＳＩＧ Ａ１２３０に含まれているＵＴＩＭ ＩＤ情報に基づいてＨＥ−ＳＩＧ Ａ１２３０以後フィールドのデコーディング可否を決定することができる。このような場合、ＨＥ−ＳＩＧ Ａ１２３０に含まれているＵＴＩＭ ＩＤ情報がＳＴＡのＵＴＩＭ ＩＤを指示する場合、ＳＴＡは、ＨＥ−ＳＴＦ１２４０及びＨＥ−ＳＴＦ１２４０以後フィールドから変更されたＦＦＴサイズに基づいてデコーディングを実行することができる。それに対し、ＨＥ−ＳＩＧ Ａ１２３０に含まれているＵＴＩＭ ＩＤ情報がＳＴＡのＵＴＩＭ ＩＤを指示しない場合、ＳＴＡは、デコーディングを中断し、ＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を設定することができる。ＨＥ−ＳＴＦ１２４０のＣＰ（ｃｙｃｌｉｃ ｐｒｅｆｉｘ）は、他のフィールドのＣＰより大きい大きさを有することができ、このようなＣＰ区間の間に、ＳＴＡは、ＦＦＴサイズを変化させてダウンリンクＰＰＤＵに対するデコーディングを実行することができる。

図１２の上段で開示されたＰＰＤＵのフォーマットを構成するフィールドの順序は、変わることもできる。例えば、図１２の中段に開示されたように、ＨＥ部分のＨＥ−ＳＩＧ Ｂ１２１５がＨＥ−ＳＩＧ Ａ１２０５の直後に位置することもできる。ＳＴＡは、ＨＥ−ＳＩＧ Ａ１２０５及びＨＥ−ＳＩＧ Ｂ１２１５までデコーディングし、必要な制御情報を受信し、ＮＡＶを設定することができる。同様に、ＨＥ−ＳＴＦ１２２５及びＨＥ−ＳＴＦ１２２５以後のフィールドに適用されるＩＦＦＴの大きさは、ＨＥ−ＳＴＦ１２２５以前のフィールドに適用されるＩＦＦＴの大きさと異なる。

ＳＴＡは、ＨＥ−ＳＩＧ Ａ１２０５及びＨＥ−ＳＩＧ Ｂ１２１５を受信することができる。ＨＥ−ＳＩＧ Ａ１２０５のＵＴＩＭ ＩＤによりダウンリンクＰＰＤＵの受信が指示される場合、ＳＴＡは、ＨＥ−ＳＴＦ１２２５からはＦＦＴサイズを変化させてダウンリンクＰＰＤＵに対するデコーディングを実行することができる。それに対し、ＳＴＡは、ＨＥ−ＳＩＧ Ａ１２０５を受信し、ＨＥ−ＳＩＧ Ａ１２０５に基づいてダウンリンクＰＰＤＵの受信が指示されない場合、ＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を設定することができる。

図１２の下段を参照すると、ＤＬ（ｄｏｗｎｌｉｎｋ）ＭＵ（ｍｕｌｔｉ−ｕｓｅｒ）送信のためのダウンリンクＰＰＤＵフォーマットが開示される。ダウンリンクＰＰＤＵは、ＯＦＤＭＡに基づいて互いに異なるダウンリンク送信リソース（周波数リソースまたは空間的ストリーム）を介してＳＴＡに送信されることができる。即ち、ダウンリンクＰＰＤＵは、下位ダウンリンクチャネルを介して複数のＳＴＡに送信されることができる。このような方法に基づいて複数のＳＴＡとＡＰがＵ−ＨＡＰＳＤ手順に基づく通信を実行することができる。

ダウンリンクＰＰＤＵ上でＨＥ−ＳＩＧ Ｂ１２４５の以前フィールドは、互いに異なるダウンリンク送信リソースの各々でデュプリケートされた形態で送信されることができる。ＨＥ−ＳＩＧ Ｂ１２４５は、全体送信リソース上でエンコーディングされた形態で送信されることができる。ＨＥ−ＳＩＧ Ｂ１２４５以後のフィールドは、ダウンリンクＰＰＤＵを受信する複数のＳＴＡの各々のための個別情報を含むことができる。

ダウンリンクＰＰＤＵに含まれるフィールドがダウンリンク送信リソースの各々を介して各々送信される場合、フィールドの各々に対するＣＲＣがダウンリンクＰＰＤＵに含まれることができる。それに対し、ダウンリンクＰＰＤＵに含まれる特定フィールドが全体ダウンリンク送信リソース上でエンコーディングされて送信される場合、フィールドの各々に対するＣＲＣがダウンリンクＰＰＤＵに含まれない。したがって、ＣＲＣに対するオーバーヘッドが減少されることができる。即ち、本発明の実施例によるＤＬ ＭＵ送信のためのダウンリンクＰＰＤＵフォーマットは、全体送信リソース上でエンコーディングされた形態のＨＥ−ＳＩＧ Ｂ１２４５を使用することによって、ダウンリンクフレームのＣＲＣオーバーヘッドを減少させることができる。

例えば、ＡＰがダウンリンクチャネルを介してＤＬ（ｄｏｗｎｌｉｎｋ）ＭＵ（ｍｕｌｔｉ−ｕｓｅｒ）ＯＦＤＭＡ送信に基づいてダウンリンクＰＰＤＵを送信した場合を仮定することができる。一つの下位ダウンリンクチャネル帯域幅が２０ＭＨｚの場合、ＳＴＡは、一つの下位ダウンリンクチャネルを介して送信されたＨＥ−ＳＩＧ Ａ１２３５をデコーディングしてダウンリンク送信リソースの割当を受けることができる。例えば、ＨＥ−ＳＩＧ Ａ１２３５は、ＳＴＡに割り当てられたダウンリンクチャネルが８０ＭＨｚであることを指示することができ、ＳＴＡは、８０ＭＨｚのダウンリンクチャネルを介して送信されるＨＥ−ＳＩＧ Ａ１２３５以後のフィールドをデコーディングすることができる。

ＤＬ ＭＵ送信のためのダウンリンクＰＰＤＵフォーマットも同様に、ＨＥ−ＳＴＦ１２５５及びＨＥ−ＳＴＦ１２５５以後のフィールドは、ＨＥ−ＳＴＦ１２５５以前のフィールドと異なるＩＦＦＴサイズに基づいてエンコーディングされることができる。したがって、ＳＴＡは、ＨＥ−ＳＩＧ Ａ１２３５及びＨＥ−ＳＩＧ Ｂ１２４５を受信し、ＨＥ−ＳＩＧ Ａ１２３５に基づいてダウンリンクＰＰＤＵの受信指示を受けた場合、ＨＥ−ＳＴＦ１２５５からはＦＦＴサイズを変化させてダウンリンクＰＰＤＵに対するデコーディングを実行することができる。

図１３は、本発明の実施例が適用されることができる無線装置を示すブロック図である。

図１３を参照すると、無線装置１３００は、前述した実施例を具現することができるＳＴＡであり、ＡＰ１３００または非ＡＰ ＳＴＡ（ｎｏｎ−ＡＰ ｓｔａｔｉｏｎ）（または、ＳＴＡ）１３５０である。

ＡＰ１３００は、プロセッサ１３１０、メモリ１３２０及びＲＦ部（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｕｎｉｔ）１３３０を含む。

ＲＦ部１３３０は、プロセッサ１３１０と連結して無線信号を送信／受信することができる。

プロセッサ１３１０は、本発明で提案された機能、過程及び／または方法を具現することができる。例えば、プロセッサ１３１０は、前述した本発明の実施例による無線装置の動作を実行するように具現されることができる。プロセッサは、図２乃至図１２の実施例で開示した無線装置の動作を実行することができる。

例えば、プロセッサ１３１０は、第１のサービス区間上でＳＴＡから受信したトリガフレームに基づいてＳＴＡにペンディングダウンリンクフレームを送信することができる。また、プロセッサ１３１０は、第２のサービス区間上でＵＴＩＭをＳＴＡに送信し、ペンディングダウンリンクフレームが存在する場合、ＳＴＡにペンディングフレームを送信するように具現されることができる。

ＳＴＡ１３５０は、プロセッサ１３６０、メモリ１３７０及びＲＦ部（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｕｎｉｔ）１３８０を含む。

ＲＦ部１３８０は、プロセッサ１３６０と連結して無線信号を送信／受信することができる。

プロセッサ１３６０は、本発明で提案された機能、過程及び／または方法を具現することができる。例えば、プロセッサ１３６０は、前述した本発明の実施例による無線装置の動作を実行するように具現されることができる。プロセッサは、図２乃至図１２の実施例で無線装置の動作を実行することができる。

例えば、プロセッサ１３６０は、第１のサービス区間上でＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信し、第１のサービス区間上で第１のトリガフレームに基づいてＡＰにより送信されたダウンリンクフレームを受信するように具現されることができる。また、プロセッサ１３６０は、ダウンリンクフレームの受信以後、第２のサービス区間上でＡＰからトラフィック指示情報（ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を受信し、第２のサービス区間上でトラフィック指示情報に基づいてＡＰにペンディングダウンリンクフレーム（ｐｅｎｄｉｎｇ ｄｏｗｎｌｉｎｋ ｆｒａｍｅ）の存在可否を決定し、ペンディングダウンリンクフレームの存在可否に基づいてパワー状態（ｐｏｗｅｒ ｓｔａｔｅ）を決定するように具現されることができる。トラフィック指示情報は、第２のサービス区間上でＡＰにより送信される前記ペンディングダウンリンクフレームの存在に対する情報を含むことができる。

プロセッサ１３１０、１３６０は、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、他のチップセット、論理回路、データ処理装置及び／またはベースバンド信号及び無線信号を相互変換する変換器を含むことができる。メモリ１３２０、１３７０は、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、フラッシュメモリ、メモリカード、格納媒体及び／または他の格納装置を含むことができる。ＲＦ部１３３０、１３８０は、無線信号を送信及び／または受信する一つ以上のアンテナを含むことができる。

実施例がソフトウェアで具現される時、前述した技法は、前述した機能を遂行するモジュール（過程、機能など）で具現されることができる。モジュールは、メモリ１３２０、１３７０に格納され、プロセッサ１３１０、１３６０により実行されることができる。メモリ１３２０、１３７０は、プロセッサ１３１０、１３６０の内部または外部にあり、よく知られた多様な手段でプロセッサ１３１０、１３６０と連結されることができる。

Claims (10)

1. ＷＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）におけるパワーセーブモードに基づく動作方法であって、前記方法は、
   ＳＴＡ（ｓｔａｔｉｏｎ）により、第１のサービス区間上でＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信することであって、前記第１のトリガフレームは、前記第１のサービス区間上での前記ＡＰによるダウンリンク送信をトリガする、ことと、
   前記ＳＴＡにより、前記第１のサービス区間上で前記第１のトリガフレームに応答して前記ＡＰにより送信されたダウンリンクフレームを受信することと、
   第２のトリガフレームを送信せずに、前記ＳＴＡにより、第２のサービス区間上で前記ＡＰからトラフィック指示情報を受信することであって、前記トラフィック指示情報は、個別に、少なくとも１つのＳＴＡに対する前記ＡＰによりバッファされた少なくとも１つのペンディングダウンリンクフレームの存在を指示する、ことと、
   前記ＳＴＡにより、前記第２のサービス区間上で前記トラフィック指示情報に基づいて前記ＡＰによりバッファされた前記ＳＴＡに対するペンディングダウンリンクフレームが存在するか否かを決定することと、
   前記ペンディングダウンリンクフレームが存在するか否かに基づいて、前記ＳＴＡにより、パワー節約のためのモードを決定することと
   を含む、方法。
2. 前記パワー節約のためのモードを決定することは、
   ペンディングダウンリンクフレームが存在しない場合、前記ＳＴＡにより、前記モードをアクティブモードからスリープモードに切り替えることと、
   前記ペンディングダウンリンクフレームが存在する場合、前記ＳＴＡにより、前記モードを前記アクティブモードとして維持し、前記ペンディングダウンリンクフレームをモニタリングすることと
   を含む、請求項１に記載の方法。
3. 前記ＳＴＡが前記トラフィック指示情報の受信以後一定時間以内に前記ペンディングダウンリンクフレームを前記ＡＰから受信しない場合、前記ＳＴＡにより、前記第２のトリガフレームを送信することをさらに含み、
   前記第２のトリガフレームは、前記第２のサービス区間上での前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガする、請求項１に記載の方法。
4. 前記ＳＴＡにより、前記第２のトリガフレームの送信の後の最大再送信実行区間を考慮して前記ペンディングダウンリンクフレームをモニタリングすることをさらに含み、
   前記最大再送信実行区間は、前記ペンディングダウンリンクフレームの再送信が実行される最大時間区間であり、
   前記最大再送信実行区間は、前記第２のサービス区間の満了時までである、請求項３に記載の方法。
5. 前記ＳＴＡが前記最大再送信実行区間上で前記ペンディングダウンリンクフレームを受信しない場合、前記ＳＴＡにより、第３のサービス区間上で第３のトリガフレームを前記ＡＰに送信することをさらに含み、
   前記第３のトリガフレームは、前記第３のサービス区間上での前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガする、請求項４に記載の方法。
6. ＷＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）におけるパワーセーブモードに基づいて動作するＳＴＡ（ｓｔａｔｉｏｎ）であって、前記ＳＴＡは、
   無線信号を送信または受信するように構成されたＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）部と、
   前記ＲＦ部と動作可能なように連結されるプロセッサと
   を含み、
   前記プロセッサは、
   第１のサービス区間上でＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信することであって、前記第１のトリガフレームは、前記第１のサービス区間上での前記ＡＰによるダウンリンク送信をトリガする、ことと、
   前記第１のサービス区間上で前記第１のトリガフレームに応答して前記ＡＰにより送信されたダウンリンクフレームを受信することと、
   第２のトリガフレームを送信せずに、第２のサービス区間上で前記ＡＰからトラフィック指示情報を受信することであって、前記トラフィック指示情報は、個別に、少なくとも１つのＳＴＡに対する前記ＡＰによりバッファされた少なくとも１つのペンディングダウンリンクフレームの存在を指示する、ことと、
   前記第２のサービス区間上で前記トラフィック指示情報に基づいて前記ＡＰによりバッファされた前記ＳＴＡに対するペンディングダウンリンクフレームが存在するか否かを決定することと、
   前記ペンディングダウンリンクフレームが存在するか否かに基づいてパワー節約のためのモードを決定することと
   を実行するように構成される、ＳＴＡ。
7. 前記プロセッサは、
   ペンディングダウンリンクフレームが存在しない場合、前記モードをアクティブモードからスリープモードに切り替えることと、
   前記ペンディングダウンリンクフレームが存在する場合、前記モードを前記アクティブモードとして維持し、前記ペンディングダウンリンクフレームをモニタリングすることと
   を実行するように構成される、請求項６に記載のＳＴＡ。
8. 前記プロセッサは、
   前記ＳＴＡが前記トラフィック指示情報の受信以後一定時間以内に前記ペンディングダウンリンクフレームを前記ＡＰから受信しない場合、前記第２のトリガフレームを送信するように構成され、
   前記第２のトリガフレームは、前記第２のサービス区間上での前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガする、請求項６に記載のＳＴＡ。
9. 前記プロセッサは、
   前記第２のトリガフレームの送信の後の最大再送信実行区間を考慮して前記ペンディングダウンリンクフレームをモニタリングするように構成され、
   前記最大再送信実行区間は、前記ペンディングダウンリンクフレームの再送信が実行される最大時間区間であり、
   前記最大再送信実行区間は、前記第２のサービス区間の満了時までである、請求項８に記載のＳＴＡ。
10. 前記プロセッサは、前記ＳＴＡが前記最大再送信実行区間上で前記ペンディングダウンリンクフレームを受信しない場合、第３のサービス区間上で第３のトリガフレームを前記ＡＰに送信するように構成され、
    前記第３のトリガフレームは、前記第３のサービス区間上での前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガする、請求項９に記載のＳＴＡ。