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

Abstract

無線ＬＡＮにおけるパワーセーブモードに基づく動作方法及び装置が開示されている。無線ＬＡＮにおけるパワーセーブモードに基づく動作方法は、ＳＴＡが第１のサービス区間上でＡＰに第１のトリガフレームを送信するステップ、ＳＴＡが第１のサービス区間上で第１のトリガフレームに基づいてＡＰにより送信されたダウンリンクフレームを受信するステップ、ＳＴＡがダウンリンクフレームの受信以後、第２のサービス区間上でＡＰからトラフィック指示情報を受信するステップ、ＳＴＡが第２のサービス区間上でトラフィック指示情報に基づいてＡＰにペンディングダウンリンクフレームが存在するかどうかを決定するステップ、及びペンディングダウンリンクフレームの存在可否に基づいてＳＴＡがパワーセーブのためのモードを決定するステップを含む。【選択図】図２

Description

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

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

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

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

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

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

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

前述した本発明の目的を達成するための本発明の一側面による、無線ＬＡＮにおけるパワーセーブモードに基づく動作方法は、ＳＴＡ（ｓｔａｔｉｏｎ）が第１のサービス区間上で前記ＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信するステップ、前記ＳＴＡが前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信するステップ、前記ＳＴＡが前記ダウンリンクフレームの受信以後、第２のサービス区間上で前記ＡＰから送信されるペンディングダウンリンクフレームまたはナルデータフレームをモニタリングするステップ、前記第２のサービス区間上で前記ペンディングダウンリンクフレームまたは前記ナルデータフレームの受信可否によって前記ＳＴＡがパワーセーブのためのモードを決定するステップを含み、前記ペンディングダウンリンクフレームは、前記ＳＴＡに対してペンディングとなっているダウンリンクデータが存在する場合、前記ＡＰにより送信され、前記ナルデータフレームは、前記ペンディングダウンリンクデータが存在しない場合、前記ＡＰにより送信される。

前述した本発明の目的を達成するための本発明の他の側面による、無線ＬＡＮにおけるパワーセーブモードに基づいて動作するＳＴＡ（ｓｔａｔｉｏｎ）において、前記ＳＴＡは、無線信号を送信または受信するために具現されたＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）部及び前記ＲＦ部と動作可能に（ｏｐｅｒａｔｉｖｅｌｙ）連結されるプロセッサを含み、前記プロセッサは、第１のサービス区間上で前記ＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信し、前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信し、前記ダウンリンクフレームの受信以後、第２のサービス区間上で前記ＡＰから送信されるペンディングダウンリンクフレームまたはナルデータフレームをモニタリングし、前記第２のサービス区間上で前記ペンディングダウンリンクフレームまたは前記ナルデータフレームの受信可否によってパワーセーブのためのモードを決定するように具現され、前記ペンディングダウンリンクフレームは、前記ＳＴＡに対してペンディングとなっているダウンリンクデータが存在する場合、前記ＡＰにより送信され、前記ナルデータフレームは、前記ペンディングダウンリンクデータが存在しない場合、前記ＡＰにより送信される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

既存の無線ＬＡＮにおいて、パワーセーブモードで動作するＳＴＡは、ＳＴＡでリアルタイムアプリケーション（ｒｅａｌｔｉｍｅ ａｐｐｌｉｃａｔｉｏｎ）（例えば、ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ））がサポートされにくい。

既存のパワーセーブモードでは、トリガフレーム（ｔｒｉｇｇｅｒ ｆｒａｍｅ）がサービス区間（ｓｅｒｖｉｃｅ Ｉｎｔｅｒｖａｌ）毎に送信される。したがって、密集（Ｄｅｎｓｅ）環境で多くの数のＳＴＡから送信されるトリガフレームは、チャネル混雑（ｃｈａｎｎｅｌ ｃｏｎｇｅｓｔｉｏｎ）を増加させることができる。具体的に、既存のパワーセーブモードでは、ＶｏＩＰサービスのジッター要求（ｊｉｔｔｅｒ ｒｅｑｕｉｒｅｍｅｎｔ）（例えば、３０ｍｓ）を満たすために、ＳＴＡは、サービス区間（または、トリガ区間）（例えば、２０ｍｓ）間隔にアップリンクトリガフレームをＡＰに送信することができる。このような多くのアップリンクトリガフレームの送信は、高い密集度の無線ＬＡＮ（ｈｉｇｈ ｄｅｎｓｅ ＷＬＡＮ）環境でシグナルフラッディング（ｓｉｇｎａｌ ｆｌｏｏｄｉｎｇ）を誘発することができる。

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

ＳＴＡがＵ−ＨＡＰＳＤを使用する場合、ＳＴＡは、アップリンクトリガフレームの頻繁な送信なしでリアルタイムアプリケーションに基づくサービスを受けることができる。ＳＴＡが頻繁にアップリンクトリガフレームを送信しないため、シグナルフラッディングは誘発されない。また、ＳＴＡがＵ−ＨＡＰＳＤを使用する場合、既存のパワーセーブモードで動作時よりＳＴＡのパワーが節約されることができる。

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

図２では、ＡＰがダウンリンクフレームナルデータフレームに基づいてペンディングダウンリンクデータ（または、送信されるダウンリンクデータ（または、ダウンリンクフレーム））の存在に対する情報を送信する方法に対して開示する。

図２を参照すると、ＳＴＡは、Ｕ−ＨＡＰＳＤ開始（ｉｎｉｔｉａｔｉｏｎ）サービス区間２５０でトリガフレーム２００を送信することができる。トリガフレーム２００は、ＡＰのペンディングダウンリンクフレームの送信をトリガすることができる。ＳＴＡは、ＡＰからトリガフレーム２００に対するＡＣＫフレーム２０５を受信し、Ｕ−ＨＨＡＰＳＤ開始サービス区間２５０上でトリガフレーム２００に基づくダウンリンクフレーム２１５をＡＰから受信することができる。

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

ＳＴＡは、Ｕ−ＨＡＰＳＤ連続（ｃｏｎｔｉｎｕｉｎｇ）サービス区間でトリガフレームの送信なしで、ＡＰから送信されるダウンリンクフレームまたはナルデータフレームをモニタリングすることができる。

ＡＰは、Ｕ−ＨＡＰＳＤ連続サービス区間上でペンディングダウンリンクフレームの存在可否によってダウンリンクフレームまたはナルデータフレームをＳＴＡに送信することができる。具体的に、Ｕ−ＨＡＰＳＤ連続サービス区間の開始以後、ＡＰは、ペンディングダウンリンクフレームの存在可否に対して決定できる。ペンディングダウンリンクフレームが存在する場合、ＡＰは、ダウンリンクフレームをトリガフレームの受信なしでＳＴＡに送信することができる。それに対し、ペンディングダウンリンクフレームが存在しない場合、ＡＰは、ナルデータフレームをＳＴＡに送信することができる。ナルデータフレームは、データフィールド（または、ペイロード）なしでヘッダ情報のみを含むフレームまたはパディングされたデータフィールド（または、ペイロード）を含むフレームである。

ナルデータフレームは、ペンディングデータの不在を指示するナルデータパケット指示子（ｎｕｌｌ ｄａｔａ ｐａｃｋｅｔ ｉｎｄｉｃａｔｉｏｎ）を含むことができる。例えば、ナルデータパケット指示子は、ＥＯＳＰまたはＭｏｒｅＤａｔａである。１に設定されたナルデータフレームのＥＯＳＰは、Ｕ−ＨＡＰＳＤ連続サービス区間の終了を指示することができる。また、０に設定されたナルデータフレームのＭｏｒｅＤａｔａは、サービス区間で送信されるダウンリンクデータの不在を指示することもできる。

Ｕ−ＨＡＰＳＤ連続サービス区間１ ２６０では、ペンディングダウンリンクフレーム２３０が存在する場合、ＡＰとＳＴＡの動作が開始される。

Ｕ−ＨＡＰＳＤ連続サービス区間１ ２６０では、ＳＴＡは、トリガフレームの送信なしで、ＡＰから送信されるダウンリンクフレーム２３０またはナルデータフレームをモニタリングすることができる。ＡＰにペンディングダウンリンクフレーム２３０が存在する場合、ＡＰは、ダウンリンクフレーム２３０をＳＴＡに送信することができる。ＳＴＡは、ダウンリンクフレーム２３０を受信し、ダウンリンクフレーム２３０に含まれているＥＯＳＰ情報及びＭｏｒｅＤａｔａ情報に基づいてパワー状態（ｐｏｗｅｒ ｓｔａｔｅ）をアウェイク状態からドーズ状態に切り替えるかどうかを決定することができる。ダウンリンクフレームのＥＯＳＰ情報及び／またはＭｏｒｅＤａｔａ情報が追加的にペンディングダウンリンクデータの存在を指示する場合、ＳＴＡは、Ｕ−ＨＡＰＳＤ連続サービス区間１ ２６０上でアウェイク状態を維持することができる。それに対し、ＥＯＳＰ情報及び／またはＭｏｒｅＤａｔａ情報が追加的なペンディングダウンリンクデータの不在を指示する場合、残りのＳＴＡは、Ｕ−ＨＡＰＳＤ連続サービス区間１ ２６０上でドーズ状態に切り替えられることができる。

Ｕ−ＨＡＰＳＤ連続サービス区間２ ２７０では、ＡＰにペンディングダウンリンクフレームが存在しない場合、ＡＰとＳＴＡの動作が開始される。

Ｕ−ＨＡＰＳＤ連続サービス区間２ ２７０では、ＳＴＡは、トリガフレームの送信なしで、ＡＰから送信されるダウンリンクフレームまたはナルデータフレームをモニタリングすることができる。ペンディングダウンリンクフレームが存在しない場合、ＡＰは、ナルデータフレーム２４０をＳＴＡに送信することができる。ＳＴＡは、ナルデータフレーム２４０を受信し、パワー状態をアウェイク状態からドーズ状態に切り替えることができる。

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

図３では、ＳＴＡのナルデータフレーム３００の受信後のＵ−ＨＡＰＳＤ手順が開示される。

図３を参照すると、ＳＴＡは、Ｕ−ＨＡＰＳＤ連続サービス区間３５０上でナルデータフレーム３００を受信した以後、残りのＵ−ＨＡＰＳＤ連続サービス区間上でドーズ状態を維持することができる。本発明の実施例によると、ナルデータフレーム３００を受信したＵ−ＨＡＰＳＤ連続サービス区間３５０以後のサービス区間は、Ｕ−ＨＡＰＳＤ再開始（ｒｅ−ｉｎｉｔｉａｔｉｏｎ）サービス区間３６０に設定されることができる。即ち、ＳＴＡは、Ｕ−ＨＡＰＳＤ再開始サービス区間３６０上で再びトリガフレーム３１０を送信し、ＡＰのダウンリンクフレーム３３０の送信をトリガすることができる。

ＳＴＡは、Ｕ−ＨＡＰＳＤ再開始サービス区間３６０の開始以後、トリガフレーム３１０をＡＰに送信することができる。ＡＰは、トリガフレーム３１０に対するＡＣＫフレーム３２０をＳＴＡに送信し、ペンディングダウンリンクフレーム３３０が存在する場合、ＳＴＡにダウンリンクフレーム３３０を送信することができる。Ｕ−ＨＡＰＳＤ再開始サービス区間３６０以後のサービス区間は、再びＵ−ＨＡＰＳＤ連続サービス区間３７０に設定されることができる。

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

図４では、ＳＴＡのナルデータフレーム４００の受信後のＵ−ＨＡＰＳＤ手順が開示される。

図４を参照すると、ＳＴＡは、Ｕ−ＨＡＰＳＤ連続サービス区間４５０上でナルデータフレーム４００を受信した以後、残りのＵ−ＨＡＰＳＤ連続サービス区間上でドーズ状態を維持することができる。

図３で前述したように、ＳＴＡは、Ｕ−ＨＡＰＳＤ再開始サービス区間４６０の開始以後、トリガフレーム４１０をＡＰに送信することができる。ＡＰは、トリガフレーム４１０に対するＡＣＫフレームをＳＴＡに送信することができる。ＡＰは、ペンディングダウンリンクフレームが存在しない場合、ＳＴＡにナルデータフレーム４２０を再送信することができる。このような場合、ＳＴＡは、アウェイク状態からドーズ状態に切り替えられることができる。このような場合、Ｕ−ＨＡＰＳＤ再開始サービス区間４６０以後のサービス区間は、再びＵ−ＨＡＰＳＤ再開始サービス区間４７０に設定されることができる。

本発明の実施例に係るＵ−ＨＡＰＳＤ手順で、ＡＰにより送信されるナルデータフレームに含まれるナルデータパケット指示子は、多様な情報フォーマットを有することができる。例えば、ナルデータパケット指示子は、ＭＡＣヘッダのＭｏｒｅＤａｔａフィールドである。ＭｏｒｅＤａｔａフィールドが０に設定される場合、追加的なペンディングデータの不在が指示されることができる。または、ナルデータパケット指示子は、ナルデータフレームを伝達するＰＰＤＵ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）ヘッダに含まれることもできる。ナルデータフレームは、多様なフレームフォーマットを有することができる。

図５は、本発明の実施例に係るナルデータフレームを示す概念図である。

図５では、最小限のヘッダ情報を含むナルデータフレームとして使われるＮＤＰバッファリングされたダウンリンクデータ通知フレーム（ｎｕｌｌ ｄａｔａ ｐａｃｋｅｔ ｄｏｗｎｌｉｎｋ ｂｕｆｆｅｒｅｄ ｄａｔａ ａｎｎｏｕｎｃｅｍｅｎｔ ｆｒａｍｅ）が開示される。ＮＤＰバッファリングされたダウンリンクデータ通知フレームは、制御フレーム（ｃｏｎｔｒｏｌ ｆｒａｍｅ）である。図５に開示されているＮＤＰバッファリングされたダウンリンクデータ通知フレームは、一つの例示に過ぎず、多様な制御フレームまたは管理フレーム（ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ）がナルデータフレームとして使われることができる。

図５を参照すると、ＮＤＰバッファリングされたダウンリンクデータ通知フレームは、フレームタイプフィールド５００、ＲＡ（ｒｅｃｅｉｖｅｒ ａｄｄｒｅｓｓ）フィールド５１０、ＴＡ（ｔｒａｎｓｍｉｔｔｅｒ ａｄｄｒｅｓｓ）フィールド５２０、ＭｏｒｅＤａｔａ指示フィールド５３０及びサービス区間変化フィールド５４０を含むことができる。

フレームタイプフィールド５００は、送信されたフレームのタイプに対する情報を含むことができる。フレームタイプフィールド５００に含まれている情報は、ＮＤＰバッファリングされたダウンリンクデータ通知フレームを指示することができる。フレームタイプフィールド５００のために、３ビットが割り当てられることができる。

ＲＡフィールド５１０は、ＮＤＰバッファリングされたダウンリンクデータ通知フレームを受信するＳＴＡの識別情報（例えば、ＭＡＣアドレス）を含むことができる。

ＴＡフィールド５２０は、ＮＤＰバッファリングされたダウンリンクデータ通知フレームを送信するＡＰの識別情報（例えば、ＭＡＣアドレス）を含むことができる。

ＭｏｒｅＤａｔａ指示フィールド５３０は、ＡＰにバッファリングされた（ペンディングとなっている）データが存在するかどうかを指示することができる。ＭｏｒｅＤａｔａ指示フィールド５３０は、ナルデータパケット指示子である。

サービス区間変化フィールド５４０は、サービス区間の長さを変化させるための情報を含むことができる。例えば、サービス区間変化フィールド５４０の値が０の場合、以前サービス区間を維持し、サービス区間変化フィールド５４０の値が１の場合、サービス区間を以前サービス区間の２倍に設定し、サービス区間変化フィールド５４０の値が２の場合、サービス区間を以前サービス区間の４倍に設定し、サービス区間変化フィールド５４０の値が３の場合、サービス区間を以前サービス区間の８倍に設定することができる。サービス区間変化フィールド５４０のために、３ビットが割り当てられた場合、４〜７は保存された（ｒｅｓｅｒｖｅｄ）値である。

サービス区間変化フィールド５４０に基づいて変更されたサービス区間に基づいてＵ−ＨＡＰＳＤ手順が実行されることができる。

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

図６では、Ｕ−ＨＡＰＳＤ手順のためのサービス区間を変更する方法が開示される。

図６を参照すると、ペンディングダウンリンクデータがない場合、ＡＰは、ナルデータフレーム６００を送信することができる。

ナルデータフレーム６００にはサービス区間を変化させるためのサービス区間変化フィールドが含まれることができる。ＡＰは、一定期間の間にＳＴＡに送信するデータが存在するかどうか（または、ＳＴＡへのダウンリンク送信タイミング）を考慮してサービス区間を変化させることができる。図６では、サービス区間の長さを２倍に設定した場合を仮定する。

ナルデータフレーム６００を受信したＳＴＡは、サービス区間変化フィールドに基づいてサービス区間の変化に対する情報を取得することができる。サービス区間変化フィールドに基づいて延長された（または、変化された）サービス区間は、Ｕ−ＨＡＰＳＤ延長サービス区間６６０という用語で表現されることができる。ＳＴＡは、Ｕ−ＨＡＰＳＤ延長サービス区間６６０の間にドーズ状態を維持することができる。

例えば、サービス区間変化フィールドに基づいてサービス区間の長さが２倍に設定された場合、ナルデータフレーム６００に対するＡＣＫフレームを送信した以後、残りのＵ−ＨＡＰＳＤ連続サービス区間６５０及びＵ−ＨＡＰＳＤ延長サービス区間６６０の間にドーズ状態を維持することができる。

ナルデータフレームが前記ＡＰにより送信された場合、ＳＴＡは、パワー状態をアウェイク状態からドーズ状態に切り替えることができ、ドーズ状態の維持時間は、サービス区間変化フィールドにより指示されたサービス区間の変化された長さに基づいて決定されることができる。

Ｕ−ＨＡＰＳＤ延長サービス区間６６０以後、Ｕ−ＨＡＰＳＤ再開始サービス区間が実行されることができる。ＳＴＡは、Ｕ−ＨＡＰＳＤ再開始サービス区間でドーズ状態からアウェイク状態に切り替えられることができ、トリガフレームを送信することができる。Ｕ−ＨＡＰＳＤ延長サービス区間６６０以後のサービス区間の長さは、元Ｕ−ＨＡＰＳＤサービス区間（Ｕ−ＨＡＰＳＤ開始サービス区間またはＵ−ＨＡＰＳＤ連続サービス区間）の長さに復元されることができる。または、変更されたサービス区間の長さを維持してＵ−ＨＡＰＳＤサービス区間（Ｕ−ＨＡＰＳＤ開始サービス区間またはＵ−ＨＡＰＳＤ連続サービス区間）の長さが延長されることもできる。

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

Ｕ−ＨＡＰＳＤ延長サービス区間７４０以後、Ｕ−ＨＡＰＳＤ再開始サービス区間７５０が実行されることができる。Ｕ−ＨＡＰＳＤ再開始サービス区間７５０は、サービス区間変化フィールドに基づいて延長され、または元のサービス区間の長さを有することができる。

図７では、ナルデータフレーム７１０に基づいて延長されたＵ−ＨＡＰＳＤサービス区間（Ｕ−ＨＡＰＳＤ開始サービス区間またはＵ−ＨＡＰＳＤ連続サービス区間）が開示される。

図７を参照すると、Ｕ−ＨＡＰＳＤ再開始サービス区間７５０で、ＳＴＡは、トリガフレーム７００をＡＰに送信することができる。ＡＰは、トリガフレーム７００に対するＡＣＫフレームを送信し、ＡＰは、ＳＴＡに送信されるペンディングダウンリンクフレームが存在するかどうかを決定することができる。

Ｕ−ＨＡＰＳＤ延長サービス区間７４０以後、Ｕ−ＨＡＰＳＤ再開始サービス区間７５０で、ＡＰにペンディングダウンリンクフレーム７１０が存在しない場合がある。このような場合、Ｕ−ＨＡＰＳＤ再開始サービス区間７５０の長さは、Ｕ−ＨＡＰＳＤ再開始サービス区間７５０上で送信されたナルデータフレーム７１０のサービス区間変換フィールドに基づいて延長されることができる。ＳＴＡは、ナルデータフレーム７１０を受信し、延長されたＵ−ＨＡＰＳＤ再開始サービス区間７５０の間にドーズ状態を維持することができる。Ｕ−ＨＡＰＳＤ再開始サービス区間７５０で、ナルデータフレームが送信された場合、以後のサービス区間は、再びＵ−ＨＡＰＳＤ再開始サービス区間に設定され、ＳＴＡは、トリガフレームをＡＰに送信することができる。

図７では、ナルデータフレーム７１０のサービス区間変化フィールドが１を指示し、Ｕ−ＨＡＰＳＤ再開始サービス区間７５０が２倍に延長された場合である。２０ｍｓのＵ−ＨＡＰＳＤ再開始サービス区間が４０ｍｓのＵ−ＨＡＰＳＤ再開始サービス区間７５０に延長されることができる。４０ｍｓは、一つの例に過ぎず、サービス区間変化フィールドによって８０ｍｓ、１６０ｍｓなどがＵ−ＨＡＰＳＤ再開始サービス区間の長さに設定されることができる。

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

図８では、Ｕ−ＨＡＰＳＤ延長サービス区間８５０以後、Ｕ−ＨＡＰＳＤ再開始サービス区間８６０で、ＡＰにペンディングダウンリンクフレーム８１０が存在する場合が開示される。

図８を参照すると、Ｕ−ＨＡＰＳＤ再開始サービス区間８６０で、ＳＴＡは、トリガフレーム８００をＡＰに送信することができる。ＡＰは、トリガフレーム８００に対するＡＣＫフレームを送信し、ＳＴＡに送信されるペンディングダウンリンクフレームがＡＰに存在するかどうかを決定することができる。

ＡＰにペンディングダウンリンクフレーム８１０が存在する場合、ＡＰは、ダウンリンクフレーム８１０をＳＴＡに送信することができる。ＳＴＡは、ダウンリンクフレーム８１０に対するＡＣＫフレームをＡＰに送信することができる。Ｕ−ＨＡＰＳＤ再開始サービス区間８６０で、ダウンリンクフレーム８１０が送信された場合、以後のサービス区間は、Ｕ−ＨＡＰＳＤ連続サービス区間８７０に設定されることができる。

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

図９では、Ｕ−ＨＡＰＳＤ連続サービス区間で、ダウンリンクフレームに対する送信または受信が失敗した場合、ダウンリンクフレームの再送信手順が開示される。

図９を参照すると、ＳＴＡは、Ｕ−ＨＡＰＳＤ連続サービス区間９５０で送信されるダウンリンクフレーム９００をモニタリングすることができる。ＡＰの送信失敗またはＳＴＡの受信失敗により、ＡＰからＳＴＡにダウンリンクフレーム９００が送信されない場合がある。例えば、ＡＰがチャネルアクセスを失敗してダウンリンクフレーム９００を送信することができない、またはＳＴＡがダウンリンクフレーム９００に対するデコーディングを失敗することができる。

ＡＰは、ダウンリンクフレーム９００に対するＡＣＫフレームを受信することができない場合、再送信ダウンリンクフレーム９１０を送信することができる。

ＳＴＡは、Ｕ−ＨＡＰＳＤ連続サービス区間上でダウンリンクフレーム９００またはナルデータフレームを受信することができない場合、一定区間の間にダウンリンクフレーム９００をモニタリングすることができる。

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

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

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

ＳＴＡがＵ−ＨＡＰＳＤ連続サービス区間９５０上でＡＰにより再送信されたダウンリンクフレームに対するデコーディングを失敗した場合、ＳＴＡは、Ｕ−ＨＡＰＳＤ再開始サービス区間９６０上でトリガフレーム９２０をＡＰに再送信することができる。

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

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

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

図１０では、Ｕ−ＨＡＰＳＤ連続サービス区間１０５０上でＳＴＡにペンディングアップリンクフレームが発生した場合、ＳＴＡがペンディングアップリンクフレーム１０００をＡＰに送信する方法が開示される。

図１０を参照すると、Ｕ−ＨＡＰＳＤ連続サービス区間１０５０上でＳＴＡにペンディングアップリンクフレームが生成された場合、ＳＴＡは、ダウンリンクフレームに対するモニタリングより優先してアップリンクフレーム１０００をＡＰに送信することができる。ＳＴＡによりアップリンクフレーム１０００が送信されるサービス区間は、他の用語でＵ−ＨＡＰＳＤフォールバックサービス区間１０５０という用語で表現されることができる。

例えば、Ｕ−ＨＡＰＳＤフォールバックサービス区間１０５０で、ＳＴＡは、サービス区間の終了を指示し（ＥＯＳＰ＝１）、または追加にペンディングダウンリンクデータが存在しないことを指示する（ＭｏｒｅＤａｔａ＝０）ダウンリンクフレームまたはナルデータフレームの送信タイミングより速くチャネルアクセスを実行することでアップリンクフレーム１０００をＡＰに送信することができる。

ＳＴＡがサービス区間の終了を指示し（ＥＯＳＰ＝１）、または追加にペンディングダウンリンクデータが存在しないことを指示する（ＭｏｒｅＤａｔａ＝０）ダウンリンクフレームまたはナルデータフレームを受信する場合、ドーズ状態に切り替えられる。したがって、ＳＴＡは、このようなダウンリンクフレームの送信以前にチャネルアクセスを実行することでアップリンクフレーム１０００を送信することができる。

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

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

図１１では、Ｕ−ＨＡＰＳＤ連続サービス区間上でＳＴＡにペンディングアップリンクフレームが発生した場合、ＳＴＡがペンディングアップリンクフレーム１１００をＡＰに送信する方法が開示される。

図１１を参照すると、Ｕ−ＨＡＰＳＤ連続サービス区間でサービス区間の終了を指示し（ＥＯＳＰ＝１）、または追加にペンディングダウンリンクデータが存在しないことを指示する（ＭｏｒｅＤａｔａ＝０）ダウンリンクフレーム１１００がＳＴＡに送信されることができる。このような場合、ダウンリンクフレーム１１００の受信以後、ＳＴＡにペンディングアップリンクフレームが発生した場合、ＳＴＡは、直ちにアップリンクフレーム１１２０を送信することができず、ドーズ状態に切り替えられることができる。

ＳＴＡは、次のサービス区間をＵ−ＨＡＰＳＤフォールバックサービス区間１１５０に設定してアップリンクフレームを送信することができる。ＳＴＡは、Ｕ−ＨＡＰＳＤフォールバックサービス区間１１５０でダウンリンクフレームまたはナルデータフレームの送信前にアップリンクフレーム１１２０を送信することができる。

Ｕ−ＨＡＰＳＤフォールバックサービス区間１１５０でアップリンクフレーム１１２０の送信が完了した場合、Ｕ−ＨＡＰＳＤフォールバックサービス区間１１５０以後のサービス区間は、Ｕ−ＨＡＰＳＤ連続サービス区間に設定されることができる。

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

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

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

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

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

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

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

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

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

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

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

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

図１２では、本発明の実施例に係るＰＰＤＵフォーマットに対して開示する。ＰＰＤＵフォーマットのＰＰＤＵヘッダは、ナルデータパケット指示子を含むことができる。

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

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

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

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

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

また、Ｈ−ＳＩＧ Ａ１２３０は、ダウンリンクＰＰＤＵを受信するターゲットＳＴＡを指示するためのＳＴＡの識別情報を含むことができる。複数のＳＴＡが同じＵ−ＨＡＰＳＤ区間上で動作できる。このような場合、ＳＴＡは、ダウンリンクＰＰＤＵのＨ−ＳＩＧ Ａ１２３０に含まれているＳＴＡの識別子情報に基づいて、ダウンリンクＰＰＤＵがＳＴＡをターゲットにしているＰＰＤＵかどうかを判断できる。ダウンリンクＰＰＤＵのＨ−ＳＩＧ Ａ１２３０に基づいてＳＴＡが指示された場合、ＳＴＡは、ダウンリンクＰＰＤＵに対する追加的なデコーディングを実行することができる。

ＨＥ−ＳＴＦ１２４０は、ＭＩＭＯ（ｍｕｌｔｉｌｐｌｅ ｉｎｐｕｔ ｍｕｌｔｉｐｌｅ ｏｕｔｐｕｔ）環境またはＯＦＤＭＡ環境で自動利得制御推定（ａｕｔｏｍａｔｉｃ ｇａｉｎ ｃｏｎｔｒｏｌ ｅｓｔｉｍａｔｉｏｎ）を向上させるために使われることができる。

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

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

ＨＥ−ＳＴＦ１２４０及びＨＥ−ＳＴＦ１２４０以後のフィールドに適用されるＩＦＦＴの大きさとＨＥ−ＳＴＦ１２４０以前のフィールドに適用されるＩＦＦＴの大きさは、互いに異なる。例えば、ＨＥ−ＳＴＦ１２４０及びＨＥ−ＳＴＦ１２４０以後のフィールドに適用されるＩＦＦＴの大きさは、ＨＥ−ＳＴＦ１２４０以前のフィールドに適用されるＩＦＦＴの大きさより４倍大きい。ＳＴＡがＨ−ＳＩＧ Ａ１２３０に基づいて指示される場合、ＳＴＡは、ＨＥ−ＳＴＦ１２４０及びＨＥ−ＳＴＦ１２４０以後フィールドから変更されたＦＦＴサイズに基づいてデコーディングを実行することができる。それに対し、ＳＴＡがＨ−ＳＩＧ Ａ１２３０に基づいて指示されない場合、ＳＴＡは、ＨＥ−ＳＴＦ１２４０及びＨＥ−ＳＴＦ１２４０以後フィールドに対するデコーディングを中断してＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を設定することができる。

ＨＥ−ＳＴＦ１２４０のＣＰ（ｃｙｃｌｉｃ ｐｒｅｆｉｘ）は、他のフィールドのＣＰより大きい大きさを有することができ、このようなＣＰ区間の間に、ＳＴＡは、ＦＦＴサイズを変化させてダウンリンクＰＰＤＵに対するデコーディングを実行することができる。

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

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

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

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

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

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

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

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

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

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

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

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

例えば、プロセッサ１３１０は、第１のサービス区間（例えば、Ｕ−ＨＡＰＳＤ開始サービス区間）上ではＳＴＡからトリガフレームを受信し、ペンディングダウンリンクフレームを送信することができる。また、プロセッサ１３１０は、第２のサービス区間（例えば、Ｕ−ＨＡＰＳＤ開始サービス区間）上で、ＡＰは、ＳＴＡに対するペンディングダウンリンクフレームが存在するかどうかによってペンディングダウンリンクフレームまたはナルデータフレームをＳＴＡに送信するように具現されることができる。

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

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

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

例えば、プロセッサ１３６０は、第１のサービス区間（例えば、Ｕ−ＨＡＰＳＤ開始サービス区間）上でＡＰに第１のトリガフレームを送信し、第１のサービス区間上で第１のトリガフレームに基づいてＡＰにより送信されたダウンリンクフレームを受信するように具現されることができる。

また、プロセッサ１３６０は、ダウンリンクフレームの受信以後、第２のサービス区間（例えば、Ｕ−ＨＡＰＳＤ連続サービス区間）上でＡＰから送信されるペンディングダウンリンクフレームまたはナルデータフレームをモニタリングし、第２のサービス区間上でペンディングダウンリンクフレームまたはナルデータフレームの受信可否によってパワー状態を決定するように具現されることができる。

ペンディングダウンリンクフレームは、ＳＴＡに対してペンディングとなっているダウンリンクデータが存在する場合、ＡＰにより送信され、ナルデータフレームは、ペンディングダウンリンクデータが存在しない場合、ＡＰにより送信されることができる。

また、プロセッサ１３６０は、最大再送信実行区間を考慮してペンディングダウンリンクフレームをモニタリングするように具現され、最大再送信実行区間は、ペンディングダウンリンクフレームに対する再送信が実行される最大時間区間であり、最大再送信実行区間は、ＡＰの最大再送信回数を考慮して決定されることができる。最大再送信実行区間までＡＰによりペンディングとなっているダウンリンクフレームが送信されない場合、プロセッサ１３６０は、第３のサービス区間（例えば、Ｕ−ＨＡＰＳＤ再開始サービス区間）上で第２のトリガフレームをＡＰに送信するように具現されることができる。

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

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

Claims (10)

1. 無線ＬＡＮにおけるパワーセーブモードに基づく動作方法は、
   ＳＴＡ（ｓｔａｔｉｏｎ）が第１のサービス区間上でＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信するステップ；
   前記ＳＴＡが前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信するステップ；
   前記ＳＴＡが前記ダウンリンクフレームの受信以後、第２のサービス区間上で前記ＡＰから送信されるペンディングダウンリンクフレームまたはナルデータフレームをモニタリングするステップ；及び、
   前記第２のサービス区間上で前記ペンディングダウンリンクフレームまたは前記ナルデータフレームの受信可否によって前記ＳＴＡがパワーセーブのためのモードを決定するステップ；を含み、
   前記ペンディングダウンリンクフレームは、前記ＳＴＡに対してペンディングとなっているダウンリンクデータが存在する場合、前記ＡＰにより送信され、
   前記ナルデータフレームは、前記ペンディングダウンリンクデータが存在しない場合、前記ＡＰにより送信される方法。
2. 前記パワーセーブのためのモードを決定するステップは、
   前記ＡＰにより前記ペンディングダウンリンクフレームが送信される場合、前記ＳＴＡが前記モードをアクティブモード（ａｃｔｉｖｅ ｍｏｄｅ）に維持するステップ；及び、
   前記ＡＰにより前記ナルデータフレームが送信される場合、前記ＳＴＡが前記モードを前記アクティブモードからスリープモード（ｓｌｅｅｐ ｍｏｄｅ）に切り替えるステップ；を含むことを特徴とする請求項１に記載の方法。
3. 前記ナルデータフレームは、ペンディングデータ指示フィールド及びサービス区間変化フィールドを含み、
   前記ペンディングデータ指示フィールドは、前記ペンディングダウンリンクデータが存在するかどうかを指示する情報を含み、
   前記サービス区間変化フィールドは、前記第２のサービス区間の変化された長さに対する情報を含み、
   前記ＳＴＡが前記ナルデータフレームを受信した場合、前記モードは、アクティブモード（ａｃｔｉｖｅ ｍｏｄｅ）からスリープモード（ｓｌｅｅｐ ｍｏｄｅ）に切り替えられ、
   前記ドーズ状態の維持時間は、前記第２のサービス区間の前記変化された長さに基づいて決定されることを特徴とする請求項１に記載の方法。
4. 前記ＳＴＡが最大再送信実行区間を考慮して前記ペンディングダウンリンクフレームをモニタリングするステップをさらに含み、
   前記最大再送信実行区間は、前記ペンディングダウンリンクフレームに対する再送信が実行される最大時間区間であり、
   前記最大再送信実行区間は、前記ＡＰの最大再送信回数を考慮して決定されることを特徴とする請求項１に記載の方法。
5. 前記ＳＴＡが前記最大再送信実行区間まで前記ペンディングダウンリンクフレームを受信することができない場合、前記ＳＴＡが第３のサービス区間上で第２のトリガフレームを前記ＡＰに送信するステップをさらに含み、
   前記第２のトリガフレームは、前記第３のサービス区間上で前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガすることを特徴とする請求項４に記載の方法。
6. 無線ＬＡＮにおけるパワーセーブモードに基づいて動作するＳＴＡ（ｓｔａｔｉｏｎ）において、前記ＳＴＡは、
   無線信号を送信または受信するために具現されたＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）部；及び、
   前記ＲＦ部と動作可能に（ｏｐｅｒａｔｉｖｅｌｙ）連結されるプロセッサ；を含み、
   前記プロセッサは、第１のサービス区間上でＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）に第１のトリガフレームを送信し、
   前記第１のサービス区間上で前記第１のトリガフレームに基づいて前記ＡＰにより送信されたダウンリンクフレームを受信し、
   前記ダウンリンクフレームの受信以後、第２のサービス区間上で前記ＡＰから送信されるペンディングダウンリンクフレームまたはナルデータフレームをモニタリングし、
   前記第２のサービス区間上で前記ペンディングダウンリンクフレームまたは前記ナルデータフレームの受信可否によってパワーセーブのためのモードを決定するように具現され、
   前記ペンディングダウンリンクフレームは、前記ＳＴＡに対してペンディングとなっているダウンリンクデータが存在する場合、前記ＡＰにより送信され、
   前記ナルデータフレームは、前記ペンディングダウンリンクデータが存在しない場合、前記ＡＰにより送信されるＳＴＡ。
7. 前記プロセッサは、前記ＡＰにより前記ペンディングダウンリンクフレームが送信される場合、前記モードをアクティブモード（ａｃｔｉｖｅ ｍｏｄｅ）に維持し、前記ＡＰにより前記ナルデータフレームが送信される場合、前記モードを前記アクティブモードからスリープモード（ｓｌｅｅｐ ｍｏｄｅ）に切り替えるように具現されることを特徴とする請求項６に記載のＳＴＡ。
8. 前記ナルデータフレームは、ペンディングデータ指示フィールド及びサービス区間変化フィールドを含み、
   前記ペンディングデータ指示フィールドは、前記ペンディングダウンリンクデータが存在するかどうかを指示する情報を含み、
   前記サービス区間変化フィールドは、前記第２のサービス区間の変化された長さに対する情報を含み、
   前記ナルデータフレームが前記ＡＰにより送信された場合、前記プロセッサは、前記モードをアクティブモード（ａｃｔｉｖｅ ｍｏｄｅ）からスリープモード（ｓｌｅｅｐ ｍｏｄｅ）に切り替えるように具現され、
   前記スリープモードの維持時間は、前記第２のサービス区間の前記変化された長さに基づいて決定されることを特徴とする請求項６に記載のＳＴＡ。
9. 前記プロセッサは、最大再送信実行区間を考慮して前記ペンディングダウンリンクフレームをモニタリングするように具現され、
   前記最大再送信実行区間は、前記ペンディングダウンリンクフレームに対する再送信が実行される最大時間区間であり、
   前記最大再送信実行区間は、前記ＡＰの最大再送信回数を考慮して決定されることを特徴とする請求項６に記載のＳＴＡ。
10. 前記最大再送信実行区間まで前記ＡＰにより前記ペンディングダウンリンクフレームが送信されない場合、前記プロセッサは、第３のサービス区間上で第２のトリガフレームを前記ＡＰに送信するように具現され、
    前記第２のトリガフレームは、前記第３のサービス区間上で前記ＡＰによる前記ペンディングダウンリンクフレームの送信をトリガすることを特徴とする請求項９に記載のＳＴＡ。