JP6353098B2 - スモールデータパケットの転送に関連付けられたオーバヘッドの低減 - Google Patents

Description

本発明は、無線通信に関する。

本出願は、その内容が参照により本明細書に組み込まれる、２０１２年９月１３日に出願された米国仮特許出願第６１／７００７２０号、および２０１３年６月６日に出願された米国仮特許出願第６１／８３１７５９号の利益を主張する。

無線ローカルエリアネットワーク（ＷＬＡＮ）は、無線デバイスまたは局（ＳＴＡ）を接続するＬＡＮである。インフラストラクチャ基本サービスセット（ＢＳＳ）モードでは、ＷＬＡＮは、ＢＳＳに対するアクセスポイント（ＡＰ）と、ＡＰに関連付けられた１または複数のＳＴＡとを含む。ＡＰは、ＢＳＳにトラフィックを搬送し、およびＢＳＳからトラフィックを搬送する、分散システム（ＤＳ）、または他のタイプの有線もしくは無線ネットワークへのアクセスまたはインターフェースを有することがある。ＢＳＳ外部から発信されるが、最終的に、ＢＳＳ内部のＳＴＡを宛先とするトラフィックは、それを適切なＳＴＡに配信することができるＡＰを通じて到着することがある。同様に、ＳＴＡから発信し、かつＢＳＳ外部のデバイスを宛先とするトラフィックは、ＢＳＳ外部の適切なデバイスに配信するためのＡＰに送信されることがある。ＢＳＳにおけるＳＴＡ間で交換されるトラフィックは（ピアツーピアトラフィックとも称される）、ＡＰを介して送信されることがあり、または電気電子技術者協会（ＩＥＥＥ）８０２．１１ｅ ダイレクトリンクセットアップ（ＤＬＳ）もしくはＩＥＥＥ８０２．１１ｚトンネルＤＬＳ（ＴＤＬＳ）を使用して、ＤＬＳで、ソースＳＴＡと宛先ＳＴＡとの間で直接に転送されることがある。独立ＢＳＳモードでは、ＷＬＡＮはＡＰを有さず、したがって、独立ＢＳＳモードにあるＳＴＡは、相互に直接、通信する。

少なくとも一部のＷＬＡＮの特性および動作に少なくとも起因して、ＷＬＡＮ ＳＴＡは、アップリンク（ＵＬ）スモールフレームを頻繁に送信する必要があることがある。そのようなＵＬスモールフレームは、例えば、省電力ポーリング（ＰＳ−Ｐｏｌｌ）、約１２０バイトの媒体アクセス制御（ＭＡＣ）サービスデータユニット（ＭＳＤＵ）フレームを有することができるボイスオーバインターネットプロトコル（ＶｏＩＰ）パケット、約６４バイトのサイズのＭＳＤＵをフレームが有することができる産業プロセスオートメーション（industrial process automation）、および約６４バイトのＭＳＤＵフレームを有することができるウェブブラウジングクリック上でのデータ（data on web browsing clicking）を含むパケットを含むことがある。

スモールパケットを転送するための方法、無線送信／受信ユニット（ＷＴＲＵ）、および基地局が説明される。ＷＴＲＵは、媒体アクセス制御（ＭＡＣ）または物理レイヤ収束（convergence）プロトコル（ＰＬＣＰ）ヘッダの１または複数を有するパケットを生成し、ＭＡＣまたはＰＬＣＰヘッダの１または複数は、フィールドを含む。送信するためにバッファリングされたデータをＷＴＲＵが有する条件で、ＷＴＲＵは、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間を示す情報を、フィールドに含める。ＷＴＲＵは、無線ネットワークにおける別のＷＴＲＵにパケットを送信する。ＷＴＲＵは、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間に基づいて、許可送信機会（ＴＸＯＰ：granted transmission opportunity）で他のＷＴＲＵから別のパケットを受信する。

添付の図面とともに、例として与えられた以下の説明から、より詳細な理解を得ることができる。

１または複数の開示される実施形態を実装することができる例示的な通信システムのシステム図である。 図１Ａに示される通信システム内で使用することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａに示される通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 例示的なポイント調整機能（ＰＣＦ：point coordination function）フレーム転送を示す図である。 例示的な省電力マルチポーリング（ＰＳＭＰ：power-save multi-poll）動作を示す図である。 スモールパケットを転送する例示的な方法のフロー図である。 スモールパケットを転送する別の例示的な方法のフロー図である。 可変長フレームチェックシーケンス（ＦＣＳ）を使用するスモールパケットを転送する例示的な方法の図である。 可変長ＦＣＳを使用するスモールパケットを転送する別の例示的な方法の図である。 グループベースのチャネル競合（channel contention）の例を示す図である。 グループベースのチャネル競合の別の例を示す図である。 グループベースのチャネル競合の別の例を示す図である。 例示的なＣＧ内送信許可（Intra-CG transmission grant）および代理ポーリング（surrogate polling）プロシージャを示す図である。 例示的なグループ間送信許可（inter-CG transmission grant）および代理ポーリングプロシージャを示す図である。

図１Ａは、１または複数の開示される実施形態を実装することができる例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通じて、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの、１または複数のチャネルアクセス方法を利用してもよい。

図１Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含んでもよいが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を意図していることが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ならびに、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家電製品、局（ＳＴＡ）、およびアクセスポイント（ＡＰ）などを含んでもよい。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含んでもよい。基地局１１４ａ、１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインターフェースして、コアネットワーク１０６、インターネット１１０、および／または他のネットワーク１１２などの１または複数の通信ネットワークへのアクセスを促進するように構成された、任意のタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ基地局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１１４ａ、１１４ｂはそれぞれ、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されよう。

基地局１１４ａは、ＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４はまた、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と称されることがある特定の地理的領域内で、無線信号を送信および／または受信するように構成されてもよい。セルはさらにセルセクタに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施形態では、基地局１１４ａは、３つの送受信機、すなわち、セルのセクタ毎に１つの送受信機を含んでもよい。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、したがって、セルのセクタ毎に複数の送受信機を利用してもよい。

基地局１１４ａ、１１４ｂは、エアインターフェース１１６上で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数と通信してもよく、エアインターフェース１１６は、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であってもよい。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。

特に、上述したように、通信システム１００は、多元接続システムであってもよく、ならびに、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０４における基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１６を確立することができる、ユニバーサル移動体通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

別の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１６を確立することができる、進化型ＵＭＴＳ地上波無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよい。

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅ ｆｏｒ ＧＳＭ（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、ならびに、職場、自宅、自動車、およびキャンパスなどの局所的エリアにおいて無線接続性を促進するための任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。さらなる別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって、基地局１１４ｂは、コアネットワーク１０６を介して、インターネット１１０にアクセスすることが要求されなくてもよい。

ＲＡＮ１０４は、コアネットワーク１０６と通信してもよく、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成された、任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイルロケーションベースサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供ししてもよく、および／または、ユーザ認証などの高レベルのセキュリティ機能を実行してもよい。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用する、他のＲＡＮと直接的または間接的に通信してもよいことが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することができるＲＡＮ１０４に接続されることに加えて、コアネットワーク１０６はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示されず）とも通信してもよい。

コアネットワーク１０６はまた、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスする、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄに対するゲートウェイとしてサービスしてもよい。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用することができる、１または複数のＲＡＮに接続された別のコアネットワークを含んでもよい。

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部またはすべては、マルチモード機能を含んでもよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信する複数の送受信機を含んでもよい。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用することができる基地局１１４ａと通信し、および、ＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、上記の要素の任意のサブコンビネーションを含んでもよいことが理解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、および状態機械などであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能を実行してもよい。プロセッサ１１８は、送受信機１２０に結合されてもよく、送受信機１２０は、送信／受信要素１２２に結合されてもよい。図１Ｂは、プロセッサ１１８と送受信機１２０を別々のコンポーネントとして示しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内にともに統合されてもよいことが理解されよう。

送信／受信要素１２２は、エアインターフェース１１６上で、基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミタ／ディテクタであってもよい。さらなる別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが理解されよう。

加えて、図１Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６上で無線信号を送信および受信する２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含んでもよい。

送受信機１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、および、送信／受信要素１２２によって受信された信号を復調するように構成されてもよい。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有してもよい。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にする、複数の送受信機を含んでもよい。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、および、それらからユーザ入力データを受信してもよい。プロセッサ１１８は、また、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの、任意のタイプの適切なメモリからの情報にアクセスし、ならびに、それらにデータを記憶してもよい。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータなどの（図示しない）、ＷＴＲＵ１０２上に物理的に位置していないメモリからの情報にアクセスし、および、それらにデータを記憶してもよい。

プロセッサ１１８は、電源１３４から電力を受信してもよく、ならびに、ＷＴＲＵ１０２における他のコンポーネントへの電力を分配および／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力供給する任意の適切なデバイスであってもよい。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含んでもよい。

プロセッサ１１８は、ＧＰＳチップセット１３６にも結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、エアインターフェース１１６上で、基地局（例えば、基地局１１４ａ、１１４ｂ）から位置情報を受信してもよく、および／または２つ以上の近隣の基地局から受信された信号のタイミングに基づいて、自身の位置を判定してもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、任意の適切な位置判定方法によって、位置情報を取得してもよいことが理解されよう。

プロセッサ１１８は、他の周辺機器１３８にさらに結合されてもよく、他の周辺機器１３８は、追加的な特徴、機能、および／または有線もしくは無線接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでもよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用の）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含んでもよい。

図１Ｃは、実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。ＲＡＮ１０４は、ＩＥＥＥ８０２．１６無線技術を採用して、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する、アクセスサービスネットワーク（ＡＳＮ）であってもよい。以下でさらに説明されるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０４、およびコアネットワーク１０６の異なる機能エンティティ間の通信リンクは、参照ポイントとして定義されてもよい。

図１Ｃに示されるように、ＲＡＮ１０４は、基地局１４０ａ、１４０ｂ、１４０ｃ、およびＡＳＮゲートウェイ１４２を含んでもよいが、ＲＡＮ１０４は、実施形態との整合性を維持しながら、任意の数の基地局およびＡＳＮゲートウェイを含んでもよいことが理解されよう。基地局１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０４における特定のセル（図示されず）に関連付けられてもよく、および、それぞれが、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する１または複数の送受信機を含んでもよい。一実施形態では、基地局１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、基地局１４０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および、ＷＴＲＵ１０２ａから無線信号を受信してもよい。基地局１４０ａ、１４０ｂ、１４０ｃはまた、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシ実施などの、モビリティ管理機能を提供してもよい。ＡＳＮゲートウェイ１４２は、トラフィック集約ポイントとしてサービスしてもよく、ならびに、ページング、加入者プロファイルのキャッシング、およびコアネットワーク１０６へのルーティングなどを担当してもよい。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０４との間のエアインターフェース１１６は、ＩＥＥＥ８０２．１６仕様を実装する、Ｒ１参照ポイントとして定義されてもよい。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０６との論理インターフェース（図示されず）を確立してもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０６との間の論理インターフェースは、Ｒ２参照ポイントとして定義されてもよく、Ｒ２参照ポイントは、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理に使用されてもよい。

基地局１４０ａ、１４０ｂ、１４０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間でのデータの転送を促進するプロトコルを含む、Ｒ８参照ポイントとして定義されてもよい。基地局１４０ａ、１４０ｂ、１４０ｃとＡＳＮゲートウェイ１４２との間の通信リンクは、Ｒ６参照ポイントとして定義されてもよい。Ｒ６参照ポイントは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連付けられたモビリティイベントに基づいて、モビリティ管理を促進するプロトコルを含んでもよい。

図１Ｃに示されるように、ＲＡＮ１０４は、コアネットワーク１０６に接続されてもよい。ＲＡＮ１０４とコアネットワーク１０６との間の通信リンクは、例えばデータ転送およびモビリティ管理機能を促進するプロトコルを含む、Ｒ３参照ポイントとして定義されてもよい。コアネットワーク１０６は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１４４、認証・認可・課金（ＡＡＡ）サーバ１４６、およびゲートウェイ１４８を含んでもよい。上記の要素の各々は、コアネットワーク１０６の一部として示されているが、これらの要素のいずれか１つは、コアネットワークオペレータとは異なるエンティティによって所有および／または運営されてもよいことが理解されよう。

ＭＩＰ−ＨＡは、ＩＰアドレス管理を担当してもよく、ならびに、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、異なるＡＳＮの間で、および／または異なるコアネットワークの間でローミングすることを可能にしてもよい。ＭＩＰ−ＨＡ１４４は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進してもよい。ＡＡＡサーバ１４６は、ユーザ認証、およびユーザサービスのサポートを担当してもよい。ゲートウェイ１４８は、他のネットワークとの相互作用を促進してもよい。例えば、ゲートウェイ１４８は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を促進してもよい。加えて、ゲートウェイ１４８は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができるネットワーク１１２へのアクセスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。

図１Ｃには示されていないが、ＲＡＮ１０４は、他のＡＳＮに接続されてもよく、および、コアネットワーク１０６は、他のコアネットワークに接続されてもよいことが理解されよう。ＲＡＮ１０４と他のＡＳＮとの間の通信リンクは、Ｒ４参照ポイントとして定義されてもよく、Ｒ４参照ポイントは、ＲＡＮ１０４と他のＡＳＮとの間で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するプロトコルを含んでもよい。コアネットワーク１０６と他のコアネットワークとの間の通信リンクは、Ｒ５参照ポイントとして定義されてもよく、Ｒ５参照ポイントは、ホームコアネットワークと移動先コアネットワークとの間の相互作用を促進するプロトコルを含んでもよい。

他のネットワーク１１２はさらに、ＩＥＥＥ８０２．１１ベースの無線ローカルエリアネットワーク（ＷＬＡＮ）１６０に接続されてもよい。ＷＬＡＮ１６０は、アクセスルータ１６５を含んでもよい。アクセスルータは、ゲートウェイ機能を含んでもよい。アクセスルータ１６５は、複数のアクセスポイント（ＡＰ）１７０ａ、１７０ｂと通信してもよい。アクセスルータ１６５とＡＰ１７０ａ、１７０ｂとの間の通信は、有線イーサネット（ＩＥＥＥ８０２．３規格）、または任意のタイプの無線通信プロトコルを介してもよい。ＡＰ１７０ａは、ＷＴＲＵ１０２ｄとエアインターフェース上で無線通信する。

上述したように、少なくとも一部のＷＬＡＮシステムについて、ＷＬＡＮ ＳＴＡは、ＵＬスモールフレームを頻繁に送信する必要があることがある。そのようなＷＬＡＮシステムの一部のより具体的な例は、特に、ポイント調整機能（ＰＣＦ）、サービス品質（ＱｏＳ）ハイブリッド調整機能制御チャネルアクセス（ＨＣＣＡ：hybrid coordination function controlled channel access）、省電力マルチポーリング（ＰＳＭＰ）、および１ＧＨｚ未満に割り当てられたスペクトル（サブ１ＧＨｚスペクトル）におけるＷＬＡＮ動作に関するものに従う。

ＰＣＦは、ＩＥＥＥ８０２．１１ベースの無線ローカルエリアネットワーク（ＷＬＡＮ）において使用することができる技術であり、それによって、ポイントコーディネータ（ＰＣ：point coordinator）ＡＰは、ネットワーク内で、コンテンションフリー（ＣＦ：contention-free）フレーム転送を調整する。ＰＣＦ ＣＦフレーム転送は、ＢＳＳのＡＰにおいて動作するＰＣによって制御することができる、ポーリングスキームに基づいてもよい。

図２は、例示的なＰＣＦフレーム転送２００の図である。図２に示される例示的なＰＣＦフレーム転送２００は、コンテンションフリー反復間隔（contention-free repetition interval）２０２を含み、それは、コンテンションフリー期間（ＣＦＰ：contention-free period）２０４と、その後に続く、コンテンション期間（contention period）２１２とを含む。ＰＣＦの実施形態では、コンテンションフリー反復間隔２０２は、期間にわたって無線媒体へのコンテンションフリーおよびコンテンションベースのアクセスを提供するように繰り返されてもよい。

ＰＣは、ＣＦパラメータセット要素をビーコン２１４内に含めることによって、ＣＦＰ２０４を開始してもよい。ビーコン２１４を受信するいずれの局も、ＮＡＶ２０６を各ＣＦＰ２０４の予定開始時間（nominal start time）に設定して、非ポーリング送信を防止してもよい。

ＰＣは、ポーリングフレームを使用して、ＵＬ送信に対するＣＦポーリング可能ＳＴＡ（CF-Pollable STA）をポーリングしてもよい。図２に示される例では、ＰＣは、ビーコン２１４の後、ショートフレーム間隔（ＳＩＦＳ：short interframe space）期間２１０ａを待機して、その第１のポーリングフレーム２１６を送信する。実施形態では、ＰＣは、例えば、Ｄａｔａ＋ＣＦ−Ｐｏｌｌフレーム、Ｄａｔａ＋ＣＦ−ＡＣＫ＋ＣＦ−Ｐｏｌｌフレーム、またはＣＦ−Ｐｏｌｌフレームを含む、いくつかの異なるフレームのいずれか１つをポーリングフレームとして使用してもよい。これらの異なるタイプのポーリングフレームの使用は、ＰＣが、ポーリングフレームを効率的に使用して、送信するのに有する他のデータも送信することを可能にすることができる。例えば、ＰＣは、送信するＤＬデータを有する場合、ポーリングフレームでＤＬデータを送信するのに、Ｄａｔａ＋ＣＦ−Ｐｏｌｌフレームを使用してもよい。別の例として、ＰＣは、送信するＤＬデータおよび確認応答（ＡＣＫ）を有する場合、ＤＬデータおよびＡＣＫを送信するのに、Ｄａｔａ＋ＣＦ−ＡＣＫ＋ＣＦ−Ｐｏｌｌフレームを使用してもよい。ＰＣは、送信する他のデータを有さない場合、単にＣＦ−Ｐｏｌｌフレームを送信してもよい。ＣＦＰ（例えば、ＣＦＰ２０４）の間に送信されたフレームの確認応答は、確認応答されることになるフレームの直後にデータまたはヌルフレームが続く場合、Ｄａｔａ＋ＣＦ−ＡＣＫ、ＣＦ−ＡＣＫ、Ｄａｔａ＋ＣＦ−ＡＣＫ＋ＣＦ−Ｐｏｌｌ、またはＣＦ−ＡＣＫ＋ＣＦ−Ｐｏｌｌフレームの１つを使用して達成されてもよく、それによって、別個のＡＣＫフレームによるオーバヘッドを回避することができる。

ポーリングされたことに応答して、ＣＦポーリング可能ＳＴＡは、ＳＩＦＳ期間の後、競合なしに、ＵＬフレームを送信してもよい。これは、分散調整機能（ＤＣＦ：distributed coordination function）の下で行われる送信よりも高い媒体利用を提供することができる。図２に示される例では、ＰＣが第１のポーリングフレーム２１６を送信した後、ポーリングされたＳＴＡは、ＳＩＦＳ期間２１０ｂを待機し、そして、１または複数のＵＬフレーム２１８を送信する。別のＳＩＦＳ期間２１０ｃの後、ＰＣは、次のポーリングフレーム２２０を送信してもよく、および、別のＳＩＦＳ期間２１０ｄの後、ポーリングされたＳＴＡは、１または複数のＵＬフレーム２２２を送信してもよい。別のＳＩＦＳ期間２１０ｅの後、ＰＣは、次のポーリングフレーム２２４を送信してもよい。優先フレーム間隔（ＰＩＦＳ：priority interframe space）期間２０８ｂ内に、ＰＣがポーリングフレーム２２４に対する応答を受信しない場合、ＰＣは、次のポーリングフレーム２２６を送信してもよい。別のＳＩＦＳ期間２１０ｆの後、ポーリングされているＳＴＡは、１または複数のＵＬフレーム２２８を送信してもよい。

ＰＣが、ＢＳＳにおけるＳＴＡのすべてにポーリングしたら、ＰＣは、ＳＩＦＳ期間２１０ｇを待機し、ＣＦ−Ｅｎｄフレーム２３０を送信して、ＣＦＰ２０４の終了を示してもよい。ＣＦ−Ｅｎｄフレーム２３０を受信したことに応答して、ＳＴＡは、ＮＡＶをリセットしてもよく（２３２）、および、コンテンション期間２１２が開始してもよい。コンテンション期間２１２の後、ＰＣは、例えば、ＣＦパラメータセット要素をビーコン内に含めることによって、次のＣＦ期間を開始する前に、ＳＩＦＳ期間（例えば、ＳＩＦＳ期間２０８ａ）を待機してもよい。

ＩＥＥＥ８０２．１１ｅシステムは、ＨＣＣＡプロシージャを使用して、集中コントローラを使用してチャネルアクセスを制御してもよい。ＰＣＦおよびＨＣＣＡの両方は、集中制御を使用して、チャネルアクセスを制御するが、ＨＣＣＡとＰＣＦは、少なくとも、ＨＣＣＡが、ＣＰまたはＣＦＰの両方で行われてもよいという点で、およびＨＣＣＡ ＳＴＡが、ＱｏＳ（＋）ＣＦ−Ｐｏｌｌフレームにおいて指定された期間でポーリングされたＴＸＯＰを許可されてもよいという点で異なる。ＳＴＡは、ＴＸＯＰ期間の制限を受ける所与のポーリングされたＴＸＯＰ内で複数のフレーム交換シーケンスを送信してもよい。

ＩＥＥＥ８０２．１１ｎシステムは、省電力マルチポーリング（ＰＳＭＰ）メカニズムを使用してもよく、そのメカニズムでは、ＨＣＣＡにおいて使用される直接ＱｏＳ（＋）ＣＦ−Ｐｏｌｌを使用する代わりに、単一のＰＳＭＰフレームが、複数のＳＴＡをスケジュールするのに使用されてもよい。ＰＳＭＰは、ＳＴＡが少量のデータを定期的に送信する必要がある状況において、ＱｏＳ（＋）ＣＦ−Ｐｏｌｌよりも効率的であることがある。

図３は、３つのＳＴＡについての例示的なＰＳＭＰ動作３００の図である。図３に示される例示的なＰＳＭＰ動作では、ＡＰ３２２は、ＢＳＳにおけるＳＴＡ３２４、３２６、３２８のすべてによって受信することができるＰＳＭＰフレーム３０６を送信する。ＡＰは、ＳＴＡに、ＤＬフェーズ３０２の間にそれらがＤＬデータフレームを受信するのにいつアウェイクする必要があるかを示し、およびＵＬフェーズ３０４の間に各ＳＴＡがＵＬデータの送信を開始することを許可される個々の時間を示すスケジュールを、ＰＳＭＰフレーム３０６内に含めてもよい。図３に示される例では、ＤＬフェーズ３０２は、ブロードキャスト期間３０８と、それに続く、ＤＬ期間３１０、３１２、３１４とを含み、ＤＬ期間３１０、３１２、３１４の間に、それぞれのＳＴＡ３２４、３２６、３２８の各々がＤＬデータを受信してもよい。例示的なＵＬフェーズ３０４は、ＵＬ期間３１６、３１８、３２０を含み、ＵＬ期間３１６、３１８、３２０の間に、ＳＴＡ３２４、３２６、３２８は、それぞれＵＬ送信を行ってもよい。

ＰＳＭＰの使用は、各ＳＴＡが、ＤＬフェーズにおいて必要とされるまで受信機をシャットダウンし、ＵＬフェーズの間に、空きチャネル判定（ＣＣＡ：clear channel assessment）を実行する必要なしに、スケジュールされたときだけ送信するように、ＰＳＭＰフェーズの開始時にＵＬおよびＤＬスケジュールを提供することによって、ＳＴＡによる電力消費を低減させることができる。

一部のＷＬＡＮシステム（例えば、ＩＥＥＥ８０２．１１規格上で構築されたＷＬＡＮシステム）は、サブ１ＧＨｚスペクトルにおいて動作するように設計される。そのようなスペクトルは、それらが備えるチャネルのサイズおよび帯域幅で完全に制限されることがある。加えて、そのようなスペクトルは、利用可能なチャネルが隣接せず、およびより大きな帯域幅送信に対して組み合わされないという点で、断片化されることがある。そのようなスペクトルの制限を与えられると、それで動作するＷＬＡＮシステムは、高スループット／超高スループット（ＨＴ／ＶＨＴ）ＷＬＡＮシステム（ＩＥＥＥ８０２．１１ｎおよび／または８０２．１１ａｃ規格に基づいたＷＬＡＮシステムなど）と比較して、より小さい帯域幅およびより低いデータレートをサポートすることができるにすぎない。

サブ１ＧＨｚ帯域で動作可能なＩＥＥＥ８０２．１１ａｈシステムに関しては、テレビジョンホワイトスペース（ＴＶＷＳ：television white space）帯域を除く免許不用帯域（license-exempt bands）において１ＧＨｚ未満で動作可能なＯＦＤＭ物理レイヤ（ＰＨＹ）が望ましいことがある。さらに、ＰＨＹ、ならびに他のシステム（例えば、ＩＥＥＥ８０２．１５．４およびＩＥＥＥ Ｐ８０２．１５．４ｇシステム）との共存を供給するのに、ＭＡＣへの拡張が望ましいことがある。またさらに、レート対範囲の性能（例えば、最大１ｋｍ（戸外（outdoor））の距離、および１００Ｋｂｉｔ／ｓよりも大きいデータレート）を最適化することが望ましいことがある。センサおよびメータ、バックホールセンサおよびメータデータ、ならびにセルラオフロードのための拡大範囲のＷｉＦｉを含む、３つの使用ケースが考察されている。

一部の国におけるスペクトル割り当ては、完全に制限されることがある。例えば、中国では、４７０〜５６６および６１４〜７８７ＭＨｚ帯域は、１ＭＨｚ帯域幅スペクトル割り当てを許可するにすぎないことがある。１ＭＨｚモードを有する２ＭＨｚオプションをサポートすることに加えて、１ＭＨｚ限定オプション（1 MHz only option）をサポートすることが望ましいことがある。

ＩＥＥＥ８０２．１１ａｈ ＰＨＹは、１ＧＨｚ未満で動作し、およびＩＥＥＥ８０２．１１ａｃ ＰＨＹに基づいていてもよい。ＩＥＥＥ８０２．１１ａｈによって必要とされる狭帯域幅に対応するために、ＩＥＥＥ８０２．１１ａｃ ＰＨＹは、１０倍にダウンクロック（down-clocked）されてもよい。２、４、８、および１６ＭＨｚに対するサポートは、１／１０ダウンクロックによって達成されてもよいが、１ＭＨｚ帯域幅に対するサポートは、３２の高速フーリエ変換（ＦＦＴ）サイズでＰＨＹ定義を必要とすることがある。

ＩＥＥＥ８０２．１１ａｈセンサおよびメータの使用ケースは、単一のＢＳＳ内で最大で６０００のＳＴＡに対するサポートを必要とする。スマートメータおよびセンサなどのデバイスは、サポートされるＵＬおよびＤＬトラフィックに関して大きく異なる要件を有する。例えば、センサおよびメータは、データをサーバに定期的にアップロードするように構成されてもよく、それは、ほとんどの場合、ＵＬトラフィックのみである。センサおよびメータはまた、サーバによって問い合わせまたは構成されてもよい。サーバがセンサおよびメータを問い合わせまたは構成する場合、問い合わされたデータがセットアップされた間隔内で到着すべきことが予想されてもよい。同様に、サーバ／アプリケーションは、一定の間隔内で実行された任意の構成に対する確認を予想してもよい。これらのタイプのトラフィックパターンは、ＷＬＡＮシステムに対して仮定された従来のトラフィックパターンとは大きく異なることがある。

上記例では、ＳＴＡは、例えば、ＰＳ−Ｐｏｌｌ、産業プロセスオートメーション（フレームが６４バイトのＭＳＤＵサイズを有してもよい）、ウェブブラウジングクリック（フレームが６４バイトのＭＳＤＵサイズを有してもよい）、およびＶｏＩＰ（フレームが６４バイトのＭＳＤＵサイズを有してもよい）を含むＵＬスモールフレームを頻繁に送信する必要があることがある。

さらに、ＳＴＡのセットは、ビーコン間隔、ビーコンサブ間隔、またはある時間間隔の間に、媒体アクセスを行うようにスケジュールされてもよい。ＤＣＦベースのアクセスが使用される場合、ＤＣＦフレーム間隔（ＤＩＦＳ）、バックオフ、パケット衝突および再送信を含む、さらなるオーバヘッドが、ＵＬパケットの送信に関連付けられてもよい。オーバヘッドは、スモールＵＬフレームに対して特に重大になることがある。ＵＬ送信のコンテンションフリー方法が使用される場合（例えば、各ＳＴＡがパケットを送信するのにタイムスロットを割り当てられる）、一部のＳＴＡが送信するＵＬデータパケットを有しているが、他のＳＴＡは、単に、ＰＳ−Ｐｏｌｌフレームを送信して、バッファリングされたＤＬフレームを取り出すので、さらなるオーバヘッドは存在しないことがある。割り当てられたスロットのいくつかの部分は、ＳＴＡが送信を完了した後、次のタイムスロットの開始まで、アイドルのままでいることがある。したがって、割り当てスロットのこれらの部分は、浪費されることがある。

ＳＴＡのセットは、いくつかの方法の少なくとも１つで、ビーコン間隔、ビーコンサブ間隔、または所定の時間間隔において、媒体アクセスを行うようにスケジュールされてもよい。ＡＰは、管理または制御フレームを使用して、一定間隔の間ウェイクアップするようにＳＴＡに命令してもよい。ＡＰは、ＵＬ ＰＳ−Ｐｏｌｌフレームを送信して、バッファリングされたＤＬパケットを取り出すＳＴＡに対する、肯定（positive）トラフィックインジケーションマップ（ＴＩＭ：traffic indication map）をビーコンまたはショートビーコンに含めてもよい。ＡＰはまた、ＵＬ送信を行うのに一定間隔にアクセスすることを許可されたＳＴＡのセットのＩＤ、クラス、または他のインジケータのインジケーションをビーコンに含めてもよい。

高速フレーム交換（speed frame exchange）メカニズムがまた、ＩＥＥＥ８０２．１１に対して考慮されている。例えば、ＳＴＡは、ＭＡＣヘッダにおけるさらなるデータフィールドを使用して、ＵＬデータの存在を示してもよい。別の例では、ＵＬまたはＤＬ送信のいずれかに対し、データフレームが、有効な応答フレームとして使用されてもよい。別の例では、ＰＬＣＰヘッダにおける早期ＡＣＫインジケーションビットが、現在のフレームへの応答フレームとしてのデータフレームの送信に関連付けられた媒体予約時間（
medium reservation time)を示すのに使用されてもよい。

ＢＳＳが、バースト性のアップリンク（ＵＬ）トラフィックでの多数のＳＴＡを含む場合、多くのオーバヘッドが、ＵＬパケットの送信および配信に関連付けられてもよい。このオーバヘッドの一部は、ＰＨＹ収束プロトコル（ＰＬＣＰ）およびＭＡＣヘッダ、フレームチェックシーケンス（ＦＣＳ）、送信要求（ＲＴＳ）／送信許可（ＣＴＳ）および確認応答（ＡＣＫ）フレーム、チャネルアクセスを取得するのにＳＴＡが待機しなければならない時間（例えば、ＤＩＦＳおよびバックオフカウントダウン）、ならびに衝突に起因する再送信の送信を含むことがある。送信オーバヘッドに関連付けられた時間が、データまたはパケット自体の実際の送信時間よりも数倍長くなることがあるので、ＰＳ−Ｐｏｌｌなど、長さの短いデータまたはフレームの送信に関連付けられるオーバヘッドは、特に顕著となることがある。その結果、ＷＬＡＮシステムは、かなりのリソースを使用してオーバヘッドを送信し、したがって、低ＭＡＣ効率を有することがある。したがって、ＷＬＡＮシステムにおいて、オーバヘッドを低減させ、ＭＡＣ効率を改善するためのメカニズムが望ましいことがある。

本明細書では、スモールデータパケットの転送に関連付けられたオーバヘッドを低減させることができる実施形態が説明される。実施形態では、ＳＴＡなどの無線送信／受信ユニット（ＷＴＲＵ）は、転送するのにそれが有するパケットに関するより詳細な情報を送信してもよく、それが、より高いＭＡＣおよび電力効率を提供することができる。別の実施形態では、ＵＬスモールデータフレームの送信に関連付けられたオーバヘッドを最小化するために、可変長のフレームチェックシーケンス（ＦＣＳ）が使用されてもよく、ＦＣＳの動的な長さは、例えば、フレーム本体の長さに依存する。別の実施形態では、ＷＴＲＵは、グループベースのチャネル競合を使用して、媒体にアクセスしてもよい。

図４Ａは、例えば、ＷＬＡＮなどの無線ネットワークにおいて、スモールパケットを転送する例示的な方法のフロー図４００Ａである。図４Ａに示される例では、ＳＴＡなどのＷＴＲＵは、送信するのにバッファリングされたデータをＷＴＲＵが有することを示すフィールドを有するＭＡＣヘッダを有するパケットを生成する（４０２）。ＷＴＲＵは、送信するためにＷＴＲＵがバッファリングしたデータに関するより詳細な情報を提供するフィールドをパケットに（例えば、ＭＡＣまたはＰＨＹレイヤ収束プロシージャ（ＰＬＣＰ）ヘッダに）含めてもよい（４０４）。

ＷＴＲＵは、送信するためにバッファリングされたデータをそれが有することを、例えば、ＭＡＣ（例えば、ＩＥＥＥ８０２．１１ ＭＡＣ）またはＰＬＣＰヘッダにおけるモアデータフィールド（More Data Field）を使用して示してもよい。実施形態では、ＷＴＲＵは、送信するためにバッファリングされたデータをＷＴＲＵが有することを示すビットをモアデータフィールドに含めてもよい。送信するためにＷＴＲＵがバッファリングしたデータに関するより詳細な情報は、例えば、情報要素（ＩＥ）（例えば、バッファリングされたトラフィックＩＥ）として、もしくはＭＡＣ／ＰＬＣＰヘッダにおいて、初期スクランブリングシード（scrambling seed）として、または任意の管理フレーム、制御フレーム、データフレーム、もしくは他のタイプのフレームのフィールドもしくはサブフィールド（例えば、バッファトラフィックインジケーションフィールド（buffered traffic indication field）もしくはサブフィールド）として示されてもよい。送信するためにＷＴＲＵがバッファリングしたデータに関するより詳細な情報は、例えば、ＭＡＣヘッダにおけるＱｏＳ制御フィールドの全体またはサブフィールドなど、任意のフィールドまたはサブフィールドを再使用することによっても示されてもよい。

実施形態では、ＷＴＲＵは、より詳細な情報を、別のＷＴＲＵまたは基地局（例えば、ＡＰ）に送信してもよく、別のＷＴＲＵまたは基地局は、ＷＴＲＵ（例えば、ＢＳＳにおけるＳＴＡ）によって提供されたより詳細な情報に基づいて、例えば、送信機会（ＴＸＯＰ）をＷＴＲＵに割り当てることによって、より詳細な情報を使用して、より効率的なスモールパケット送信を可能にすることができる。

送信するためにＷＴＲＵがバッファリングしたデータに関するより詳細な情報は、例えば、送信するためにＷＴＲＵがバッファリングした少なくとも１つのパケットを送信するために必要とされる時間、送信するためにＷＴＲＵがバッファリングしたパケットの数、送信するためにＷＴＲＵがバッファリングしたパケットの各々のサイズ（例えば、バイト単位の）、または送信するためにＷＴＲＵがバッファリングしたパケットのすべての合計サイズの１または複数を含んでもよい。送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間は、例えば、送信するためにＷＴＲＵがバッファリングした各パケットをＷＴＲＵが送信するために必要とされる推定時間もしくはＴＸＯＰ、または送信するためにＷＴＲＵがバッファリングしたＵＬもしくはＤＬパケットのすべてをＷＴＲＵが送信するために必要とされる（例えば、マイクロ秒もしくは他の任意の時間単位の）合計時間もしくはＴＸＯＰの少なくとも１つを含んでもよい。

図４Ｂは、例えば、ＷＬＡＮなどの無線ネットワークにおいて、スモールパケットを転送する別の例示的な方法のフロー図４００Ｂである。図４Ｂに示される例では、ＷＴＲＵ（例えば、ＳＴＡ）は、送信するためにバッファリングされたデータをＷＴＲＵが有することを示すフィールドと、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間を示すフィールドとを有するＭＡＣヘッダを有するパケットを生成する（４１０）。ＷＴＲＵは、無線ネットワークにおける別のＷＴＲＵ（例えば、アクセスポイント（ＡＰ））にパケットを送信してもよい（４１２）。ＷＴＲＵは、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間に基づいて許可された送信機会（ＴＸＯＰ）を有する別のパケットを、他のＷＴＲＵから受信する（４１４）。

実施形態では、許可されたＴＸＯＰは、パケットのＭＡＣヘッダにおいて提供された時間に基づいた期間を有する。パケットは、省電力ポーリング（ＰＳ−Ｐｏｌｌ）フレーム、ＡＣＫフレーム、データフレーム、およびブロック確認応答（ＢＡ）フレームの１つであってもよい。

実施形態では、ＷＴＲＵは、バッファトラフィックインジケーションフィールドを含む、新たなフレームフォーマットを使用してもよい。そのような新たなフレームフォーマットは、例えば、ＰＳ−Ｐｏｌｌ＋バッファトラフィック（ＢＴ）フレームフォーマット、ＡＣＫ＋ＢＴフレームフォーマット、データ＋ＢＴフレームフォーマット、ショートＡＣＫ＋ＢＴフレームフォーマット、ＢＡ＋ＢＴフレームフォーマット、またはショートＢＡ＋ＢＴフレームフォーマットを含んでもよい。別の実施形態では、ＰＬＣＰ／ＭＡＣヘッダにおける、またはＰＳ−Ｐｏｌｌフレーム、ＡＣＫフレーム、データフレーム、ＢＡフレーム、ショートＡＣＫフレーム、もしくはショートＢＡフレームなど、任意のフレームの他の任意の部分におけるバッファトラフィックインジケーションフィールドの存在を示すためのビットが使用されてもよい。バッファトラフィックインジケーションフィールドはまた、例えば、新規または既存のフレームのＰＬＣＰテイルビットまたは初期スクランブリングシードに含まれてもよい。実施形態では、バッファトラフィックインジケーションフィールドの存在を示すのに、ＵＬ／ＤＬ方向においてモアデータビットが設定されてもよい。

バッファトラフィックインジケーションフィールドは、送信ＷＴＲＵにおいてバッファリングされたＵＬまたはＤＬトラフィックの１または複数に関する詳細な情報を含んでもよい。送信ＷＴＲＵが非ＡＰ ＳＴＡであり、パケットの送信先がＡＰである場合、バッファトラフィックインジケーションフィールドは、バッファリングされたＵＬパケットに関する詳細な情報を示すために使用されてもよい。送信ＷＴＲＵがＡＰであり、パケットの送信先が非ＡＰ ＳＴＡである場合、バッファトラフィックインジケーションフィールドは、バッファリングされたＤＬパケットに関する詳細な情報を示すのに使用されてもよい。送信ＷＴＲＵが非ＡＰ ＳＴＡであり、パケットの送信先が非ＡＰ ＳＴＡである場合、バッファトラフィックインジケーションフィールドは、バッファリングされたピアツーピアパケットに関する詳細な情報を示すのに使用されてもよい。バッファトラフィックインジケーションフィールドはまた、ＳＴＡの特定のセットに対するバッファリングされたブロードキャストまたはマルチキャストパケットに関する詳細な情報を示すのに使用されてもよい。

８０２．１１ａｈ ＳＴＡに対するＰＳ−Ｐｏｌｌフレーム、ＡＣＫフレーム、データフレーム、およびＢＡフレームなどのフレームに対し、ＰＬＣＰ／ＭＡＣヘッダにおける１ビット（例えば、フレーム制御フィールドまたはモアデータフィールドにおける）が、バッファトラフィックインジケーションフィールドまたはサブフィールドの存在を示すのに使用されてもよい。そのようなインジケーションはまた、例えば、ＰＬＣＰテイルビットまたは初期スクランブリングシードにも含まれてもよい。バッファトラフィックインジケーションフィールドは、上述したように、バッファリングされたＤＬおよび／またはＵＬパケットに関する詳細な情報を含んでもよい。さらに、バッファトラフィックインジケーションフィールドは、ＱｏＳ制御フィールドの全フィールドとして、またはサブフィールドとして実装されてもよい。

実施形態では、例えば、肯定ＴＩＭインジケーションを受信し、またはスリープ状態からウェイクアップし、および媒体へのアクセスを取得したＷＴＲＵ（例えば、ＳＴＡ）は、送信するＵＬデータをＷＴＲＵが有する場合、バッファトラフィックインジケーションフィールドを有するデータフレームを送信してもよい。ここで、バッファトラフィックインジケーションフィールドの存在は、モアデータビットによって示されてもよい。実施形態では、ＷＴＲＵは、スリープ状態からウェイクアップし、スリープ状態からウェイクアップしたことに応答して、送信するＵＬデータをＷＴＲＵが有している条件で、バッファトラフィックインジケーションフィールドを有するＰＳ−Ｐｏｌｌフレームを送信してもよい。ここで、バッファトラフィックインジケーションフィールドの存在は、モアデータビットによって示されてもよい。ＷＴＲＵは、送信するＵＬデータをＷＴＲＵが有さない場合、バッファトラフィックインジケーションフィールドを有さないＰＳ−Ｐｏｌｌフレーム（または、バッファリングされたパケットがゼロであることを示すバッファトラフィックインジケーションフィールド）を送信してもよい。実施形態では、ＷＴＲＵは、ＰＳ−Ｐｏｌｌフレームおよびデータフレーム、ならびにバッファトラフィックインジケーションフィールド／ＩＥを含む新たなタイプのフレームの任意の組み合わせを含む、集約されたＭＰＤＵ（Ａ−ＭＰＤＵ）または集約されたＭＳＤＵ（Ａ−ＭＳＤＵ）を送信してもよい。

別のＷＴＲＵまたは基地局（例えば、ＡＰまたは別のＳＴＡ）は、以下の１つを実行してもよい。他のＷＴＲＵは、バッファトラフィックインジケーションフィールドを有するデータフレームを受信したとき、ＵＬ専用送信（UL only transmissions）、またはＵＬおよびＤＬ送信の両方（他のＷＴＲＵがまた送信するＤＬパケットを有するＡＰであるとき）に対して、許可されたＴＸＯＰを（例えば、ＭＡＣヘッダにおける期間フィールド、またはＱｏＳ制御フィールドのサブフィールドにおいて）有するデータフレームをＷＴＲＵに送信してもよい。他のＷＴＲＵによって送信されるデータフレームはまた、ＷＴＲＵを宛先とする他のＷＴＲＵにおいて、バッファリングされた任意のＤＬパケットに対するバッファトラフィックインジケーションフィールドを含んでもよい。他のＷＴＲＵは、バッファトラフィックインジケーションフィールドを有するデータフレームを受信したとき、ＵＬ専用送信、またはＵＬおよびＤＬ送信両方（ＡＰがまた送信するＤＬパケットを有するとき）に対して、許可されたＴＸＯＰを（例えば、ＭＡＣヘッダの期間フィールドにおいて）有するＡＣＫ／ＢＡフレーム（または、ＡＣＫ／ＢＡは、この目的では、ＭＡＣヘッダにＱｏＳ制御フィールドを含めてもよく、もしくはそれのサブフィールドであってもよい）をＷＴＲＵに送信してもよい。他のＷＴＲＵによって送信されるＡＣＫ／ＢＡフレームはまた、ＷＴＲＵを宛先とする他のＷＴＲＵにおいて、任意のバッファリングされたＤＬパケットに対するバッファトラフィックインジケーションフィールドを含んでもよい。他のＷＴＲＵは、データフレーム、ＡＣＫ／ＢＡ、または許可されたＴＸＯＰもしくはＤＬパケットに対するバッファトラフィックインジケーションフィールド／ＩＥのいずれかを含む任意の新たなタイプのフレームの任意の組み合わせを含む、Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵを送信してもよい。Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵはまた、ＭＡＣヘッダにおける期間フィールドもしくはＱｏＳ制御フィールドに、または他の任意のフィールドもしくはサブフィールドに、許可されたＴＸＯＰについての情報を含んでもよい。許可されたＴＸＯＰを有するフレームを受信した全ての他のＷＴＲＵは、ＴＸＯＰが終了するまで、エネルギー節約のためにスリープに入ってもよい。他のＷＴＲＵはまた、制約アクセスウィンドウ（ＲＡＷ：Restricted Access Window）スロットまたはターゲットウェイク時間（ＴＷＴ：Target Wake Time）形式などの、許可されたＴＸＯＰに関するスケジュール情報を、ＭＡＣ／ＰＬＣＰヘッダ、またはＲＰＳ要素など、パケットの任意のフィールドまたはサブフィールドに含めてもよい。

ＵＬフレームを送信するのにＴＸＯＰを受信したことに応答して、ＷＴＲＵは、ＴＸＯＰを使用して、即時ＡＣＫ／ＢＡを有し、または即時ＡＣＫ／ＢＡなしで、データフレーム、Ａ−ＭＰＤＵ、またはＡ−ＭＳＤＵなどの、任意の許容可能な送信シーケンスを使用してＵＬ送信を完了してもよい。他のＷＴＲＵは、合意されたＡＣＫポリシに従って、ＡＣＫ、ショートＡＣＫ、ＢＡ、ショートＢＡ、またはデータフレームを使用して、これらのＵＬパケットの受信を確認応答してもよい。その送信が終了すると、ＷＴＲＵは、ＣＦ−Ｅｎｄフレームの送信に対して十分な時間が存在する場合、ＣＦ−Ｅｎｄフレームを送信して、ＴＸＯＰをキャンセルしてもよい。他のＷＴＲＵ（例えば、ＡＰ）は、ＷＴＲＵに送信するいかなるＤＬフレームを有さない場合、ＣＦ−Ｅｎｄフレームを繰り返してもよい。他のＷＴＲＵはまた、ＣＦ−ＥｎｄフレームからのＳＩＦＳ期間後に、ＷＴＲＵまたは他の任意のＷＴＲＵにＤＬパケットの送信を開始してもよい。

別の実施形態では、ＷＴＲＵ（例えば、ＳＴＡ）は、肯定ＴＩＭインジケーションを受信してもよく、またはスリープ状態からウェイクアップしてもよい（例えば、そのターゲットウェイク時間（ＴＷＴ）において）。ＷＴＲＵが、媒体へのアクセスを取得したとき、送信するＵＬデータをＳＴＡが有する場合、バッファトラフィックインジケーションフィールドを有するデータフレームを送信してもよい。バッファトラフィックインジケーションフィールドの存在は、モアデータビットまたは他のタイプのインジケーションによって示されてもよい。ＷＴＲＵは、送信するＵＬデータをＳＴＡが有する場合、バッファトラフィックインジケーションフィールドを有する、ＰＳ−Ｐｏｌｌフレーム、ＮＤＰ ＰＳ−Ｐｏｌｌフレーム、または別のタイプのトリガフレームを送信してもよい。バッファトラフィックインジケーションフィールドの存在は、モアデータビットまたは他のタイプの表示によって示されてもよい。ＷＴＲＵは、送信するＵＬデータをＳＴＡが有さない場合、バッファトラフィックインジケーションフィールドを有さないＰＳ−Ｐｏｌｌフレーム（または、バッファリングされたパケットがゼロであることを示すバッファトラフィックインジケーションフィールド）を送信してもよい。ＷＴＲＵは、ＰＳ−Ｐｏｌｌフレーム、データフレーム、および／またはバッファトラフィックインジケーションフィールド／ＩＥを含む新たなタイプのフレームの任意の組み合わせを含む、Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵを送信してもよい。

ＳＴＡによって送信されたフレームの宛先であるＷＴＲＵ（例えば、ＡＰまたは別のＳＴＡ）は、バッファトラフィックインジケーションフィールドを有するフレームを受信したとき、ＵＬ専用送信、またはＵＬおよびＤＬ送信両方（ＡＰがまた送信するＤＬパケットを有するとき）に対し、許可されたＴＸＯＰを有する（例えば、ＭＡＣヘッダにおける期間フィールド、ＱｏＳ制御フィールドのサブフィールド、またはＰＬＣＰ／ＭＡＣヘッダの別の部分、フレーム本体などにおいて）データフレームをＳＴＡに送信してもよい。ＡＰによって送信されるデータフレームはまた、ＳＴＡに対するＡＰにおいて、任意のバッファリングされたＤＬパケットに対するバッファトラフィックインジケーションフィールドを含んでもよい。許可されたＴＸＯＰは、１つのＵＬおよび／またはＤＬ専用フレーム送信に対するものであってもよい。例えば、許可されたＴＸＯＰは、ＭＡＸ＿ＰＰＵＤ＿Ｔｉｍｅとして実装することができる、１つのＭＳＤＵの送信に対するＴＸＯＰであってもよい。

ＷＴＲＵは、バッファトラフィックインジケーションフィールドを有するフレームを受信したとき、ＵＬ専用送信、またはＵＬおよびＤＬ送信両方（ＡＰがまた送信するＤＬパケットを有するとき）に対し、許可されたＴＸＯＰを有する（例えば、ＭＡＣヘッダの期間フィールド、ＰＬＣＰ／ＭＡＣヘッダの別の部分、またはフレーム本体において）ＡＣＫ／ＢＡフレーム（または代替として、ＡＣＫ／ＢＡは、この目的では、ＭＡＣヘッダにおいてＱｏＳ制御フィールドのサブフィールドを含んでもよい）をＳＴＡに送信してもよい。ＡＰによって送信されるＡＣＫ／ＢＡフレームはまた、ＳＴＡに対するＡＰにおいて、任意のバッファリングされたＤＬパケットに対するバッファトラフィックインジケーションフィールドも含んでもよい。許可されたＴＸＯＰは、１つのＵＬおよび／またはＤＬ専用フレームの送信に対するものであってもよい。例えば、許可されたＴＸＯＰは、ＭＡＸ＿ＰＰＵＤ＿Ｔｉｍｅとして実装することができる、１つのＭＳＤＵの送信に対するＴＸＯＰであってもよい。

ＷＴＲＵは、データフレーム、ＡＣＫ／ＢＡフレーム、または許可されたＴＸＯＰもしくはＤＬパケットに対するバッファトラフィックインジケーションフィールド／ＩＥのいずれかを含む任意の新たなタイプのフレームの任意の組み合わせを含む、Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵを送信してもよい。Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵはまた、ＭＡＣヘッダにおける期間フィールドもしくはＱｏＳ制御フィールドにおいて、または他の任意のフィールドもしくはサブフィールドにおいて、許可されたＴＸＯＰに関する情報を含んでもよい。ＷＴＲＵは、延期パケット（deferral packet）を送信してもよく、それは、１または複数のＲＡＷ／ＴＷＴ／アクセスウィンドウ／ビーコン間隔／ビーコンサブ間隔がＳＴＡに対して予約されていることをＳＴＡに通知する、制御フレーム、アクションフレーム、ＡＣＫなしのアクションフレーム、管理フレーム、または拡張フレームであってもよく、ＳＴＡは、ＵＬ送信および／またはＤＬ受信を完了するのに、その期間の間、アクティブである必要があることがある。これは、ＳＴＡに関連付けられたＵＬおよび／またはＤＬトラフィックの量が大きく、割り当てられたスロット／アクセスウィンドウ／ＲＡＷ／ビーコン（サブ）間隔内では完全に送信することができず、そのため、追加のスロット／ＴＷＴ／アクセスウィンドウ／ＲＡＷ／ビーコン（サブ）間隔が割り当てられる必要があるからである。そのようなフレームは、リソース割り当てフレーム、ＳＩＧアクション／拡張フレーム、または任意の制御フレーム、管理フレーム、データフレーム、もしくは拡張フレーム、もしくは他のタイプのフレームを使用して実装されてもよく、それらは、この目的では、ＲＡＷ、ＴＷＴ、または他のタイプのスケジューリングＩＥおよびフィールド／サブフィールドを使用してもよい。代わりに、ＡＰおよびＳＴＡは、通常通り、フレーム交換を送信してもよく、ＡＰは、ＡＰおよびＳＴＡが、新たなスロット／ＴＷＴ／アクセスウィンドウ／ＲＡＷ／ビーコン（サブ）間隔においてＵＬおよび／またはＤＬ送信を完了することができるように、現在のスロット／ＴＷＴ／アクセスウィンドウ／ＲＡＷ／ビーコン（サブ）間隔の終了時に、延期パケットをＳＴＡに送信してもよい。

許可されたＴＸＯＰを有するフレームを受信した全ての他のＳＴＡは、ＴＸＯＰが終了するまで、エネルギー節約のためにスリープに入ってもよい。ＳＴＡは、ＵＬフレームを送信するのにＴＸＯＰを受信すると、ＴＸＯＰを使用して、即時ＡＣＫ／ＢＡを有し、または即時ＡＣＫ／ＢＡを有さない、データフレーム、Ａ−ＭＰＤＵ、またはＡ−ＭＳＤＵなどの、任意の許容可能な送信シーケンスを使用してＵＬ送信を完了してもよい。ＳＴＡによって送信される任意のフレームは、バッファリングされたＵＬトラフィックの量に関する更新された情報を有する、追加のバッファトラフィックインジケーションフィールドを含んでもよく、更新された情報は、送信／配信に成功した任意のバッファリングされたＵＬ情報、およびＵＬ送信に対して新たに到着した任意のパケットを考慮してもよい。

ＡＰは、合意されたＡＣＫポリシに従って、ＡＣＫ、ショートＡＣＫ、ＢＡまたはショートＢＡ、データフレームを使用して、これらのＵＬパケットの受信を確認応答してもよい。同様に、ＳＴＡに対して、ＡＰによって送信されるフレームは、バッファリングされたＤＬトラフィックの量に関する更新された情報を有する、追加のバッファトラフィックインジケーションフィールドを含んでもよく、更新された情報は、送信／配信に成功した任意のバッファリングされたＤＬ情報、およびＤＬ送信に対して新たに到着した任意のパケットを考慮してもよい。

ＳＴＡは、その送信の終了において、ＣＦ−Ｅｎｄフレームを送信するのに十分な時間が存在する場合、ＣＦ−Ｅｎｄフレームを送信して、ＴＸＯＰをキャンセルしてもよい。ＡＰは、ＳＴＡに送信すするいかなるＤＬフレームを有さない場合、ＣＦ−Ｅｎｄフレームを繰り返してもよい。それはまた、ＣＦ−ＥｎｄフレームからＳＩＦＳ時間後に、ＳＴＡまたは他の任意のＳＴＡにＤＬパケットの送信を開始してもよい。

ＳＴＡは、ＵＬおよび／またはＤＬトラフィックに対する異なるスロット／ＴＷＴ／アクセスウィンドウ／ＲＡＷ／ビーコン（サブ）間隔を使用するようにそれに命令する延期フレームをＡＰから受信した場合、その時間までスリープしてもよい。それは、ウェイクアップすると、ＡＰの命令に従ったチャネルアクセスポリシに従って、チャネルにアクセスしてもよい。ＳＴＡは、バッファトラフィックインジケーションフィールドを含むことができるデータなど、ＰＳ−Ｐｏｌｌフレーム、ＮＤＰ ＰＳ−Ｐｏｌｌフレーム、または他の任意のタイプのトリガフレームを使用して、フレーム交換シーケンスを開始してもよい。ＡＰは、バッファトラフィックインジケーションフィールドも含むことができる、データフレーム、制御フレーム、管理フレーム、または拡張フレームなど、任意のタイプのフレームを使用して、フレーム交換シーケンスを開始してもよい。

別の実施形態では、ＵＬスモールデータフレームの送信に関連付けられたオーバヘッドを最小化するために、可変長のフレームチェックシーケンス（ＦＣＳ）が使用されてもよく、ＦＣＳの動的な長さは、例えば、フレーム本体の長さに依存する。標準のＦＣＳフィールドは、４バイト長であってもよいが、短いフレームに対して常にそれだけの長さが必要なわけではない。したがって、動的なＦＣＳフィールドの使用は、長さが短いパケットまたはフレームに関連付けられた送信オーバヘッドを低減させることができる。

ＦＣＳフィールドの長さ、およびＦＣＳフィールドの設計は、ＰＬＣＰ／ＭＡＣヘッダにおいて（例えば、ＰＬＣＰヘッダのＳＩＧ、ＳＩＧＡ、および／もしくはＳＩＧＢフィールドにおいて、またはＭＡＣヘッダにおけるフレーム制御フィールドにおいて）示されてもよく、初期スクランブラシード内に含まれてもよく、または暗黙的に定義されてもよい。図４Ｂを参照すると、実施形態では、４０２においてＷＴＲＵによって生成されたパケットは、パケットに含まれる動的なＦＣＳフィールドの長さを示すフィールドをさらに含んでもよい。実施形態では、フィールドの長さは、ＰＬＣＰ／ＭＡＣヘッダにおいて、バイトの数（例えば、１〜Ｎ）として示されてもよい。例えば、ＦＣＳフィールドは、４バイト未満の長さを有してもよい。ＦＣＳフィールドの設計は、新たな多項式を使用する新たなＦＣＳであってもよく、または既存のＦＣＳシーケンスおよびパンクチュアレート（puncture rate）からパンクチュア（punctured）されてもよい。

加えて、フレームに対する短い／動的なＦＣＳ長の使用は、単一ユーザフレーム圧縮プロシージャ、またはグループ内データ／フレーム圧縮プロシージャのいずれかによって事前にネゴシエートされてもよい。ＦＣＳフィールドの長さ、およびＦＣＳ構成のタイプは、送信ＳＴＡと受信ＳＴＡとの間で、またはＳＴＡのグループの間で、特定の圧縮データ／フレームタイプの仕様の一部として抽象化され（abstracted）てもよい。特定のＦＣＳ長もしくは構成または他の属性を有する圧縮データ／フレームのタイプは、ＰＬＣＰ／ＭＡＣヘッダにおいて（例えば、ＰＬＣＰヘッダのＳＩＧ、ＳＩＧＡ、およびＳＩＧＢフィールドにおいて、またはＭＡＣヘッダにおけるフレーム制御フィールドにおいて）示されてもよく、初期スクランブラシードによって示されてもよく、またはそれは暗黙的に定義されてもよい。

ＷＴＲＵは、それが動的なＦＣＳフィールド長を使用する能力を有することを、例えば、ビーコンに含まれる能力フィールド、または他の任意のフィールド、サブフィールド、もしくはＩＥにおいて示してもよい。または、ＷＴＲＵは、動的なＦＣＳフィールド長についての能力を、プローブ要求およびプローブ応答フレーム、アソシエーション要求および（再）アソシエーション応答フレーム、または他の任意のタイプの管理フレーム、制御フレーム、もしくは拡張フレームにおいて示してもよい。動的なＦＣＳ長を使用する能力は、アソシエーションの時点および他の任意の時点で交換されてもよい。特定のフレームにおける動的なＦＣＳ長または短縮化されたＦＣＳ長の使用は、ＰＬＣＰヘッダにおける１または複数のビットによって示されてもよい。

フレームが動的なＦＣＳを有することを示すフレームを受信したことに応答して、受信ＷＴＲＵ（例えば、ＳＴＡ）は、指定されたＦＣＳ長に従ってＦＣＳフィールドを取得し、フレームの正確性をチェックし、および正確に受信されなかったとしてフレームを破棄し、またはフレームを上位レイヤに中継するかを決定してもよい。ＦＣＳ仕様が事前ネゴシエートされる場合（例えば、単一ユーザまたはグループデータ／フレーム圧縮プロシージャを使用して）、受信ＷＴＲＵは、特定のタイプの圧縮データ／フレームに関連付けられたＦＣＳ仕様に対する事前ネゴシエートされた記録を検索してもよい。

図５Ａは、可変長ＦＣＳを使用するスモールパケットを転送する例示的な方法５００Ａの図である。図５Ａに示される例では、ＷＴＲＵ（例えば、ＳＴＡ）は、ＦＣＳと、ＦＣＳの長さを示すＰＬＣＰおよび／またはＭＡＣヘッダとを有するフレームを生成する（５０２）。ＦＣＳの長さは可変であってもよい。ＷＴＲＵは、別のＷＴＲＵ（例えば、異なるＳＴＡまたはＡＰ）にパケットを送信してもよい（５０４）。

図５Ｂは、可変長ＦＣＳを使用するスモールパケットを転送する別の例示的な方法５００Ｂの図である。図５Ｂに示される例では、ＷＴＲＵまたは基地局（例えば、ＡＰまたはＳＴＡ）は、ＦＣＳと、ＦＣＳの長さを示すＰＬＣＰおよび／またはＭＡＣヘッダとを有するフレームを（例えば、別のＡＰまたはＳＴＡなどの別のＷＴＲＵから）受信する（５１０）。ＦＣＳの長さは可変であってもよい。ＷＴＲＵまたは基地局は、ＰＬＣＰおよび／またはＭＡＣヘッダにおいて示された長さを使用して、パケットからＦＣＳフィールドを取得してもよい（５１２）。ＷＴＲＵまたは基地局は、パケットから取得されたＦＣＳフィールドを使用して、フレームの正確性をチェックしてもよい（５１４）。フレームが正確であるとＷＴＲＵまたは基地局が判定したことを条件に（５１６）、ＷＴＲＵまたは基地局は、フレームを上位レイヤに中継してもよい（５２０）。フレームが正確でないとＷＴＲＵまたは基地局が判定した場合、ＷＴＲＵまたは基地局は、フレームを破棄してもよい（５１８）。

実施形態では、ＷＴＲＵは、媒体にアクセスするために、グループベースのチャネル競合を使用してもよい。ここで、ＵＬスモールデータフレームの送信に関連付けられたオーバヘッドを最小化するために、ＵＬ送信に対する媒体アクセスに対して、ＳＴＡツーＳＴＡ許可（STA-to-STA grant）が提供されてもよい。

グループベースのチャネル競合では、ＵＬ送信（例えば、ＰＳ−Ｐｏｌｌ、データフレーム、または他のタイプのフレーム）を行うことを許可されたＷＴＲＵ（例えば、ＳＴＡ）のセットは、コンテンショングループ（ＣＧ：contention group）と称される１または複数のグループに分割されてもよい。したがって、個々の各ＷＴＲＵがチャネルに対して競合する代わりに、例えば、ＣＧの各々における１つのＷＴＲＵが選択されて、ＣＧを対してチャネル競合を実行してもよい。例えば、２０のＳＴＡが、ある間隔でＵＬ媒体アクセスを行うようにスケジュールされる場合、２０のＳＴＡのセットは各々、４つのＳＴＡの５つのＣＧに分割されてもよい。５つのＣＧの各々における１つのＳＴＡが、ＣＧに対して競合者（contender）であるように選択されてもよく、およびＣＧ全体に対する媒体アクセスを開始することを担当してもよい。したがって、２０のＳＴＡが媒体アクセスに対して競合する代わりに、５つの競合者のみが、媒体アクセスに対して競合してもよく、それは、衝突および再送信の可能性を著しく低下させることができる。ＣＧの競合者が媒体へのアクセスを取得すると、それは、ＣＧ全体が媒体へのアクセスを取得し、そのＣＧに対する送信期間が開始することができることを暗黙的に示してもよい。

加えて、グループベースの競合は、イベントドリブンＳＴＡにおいてＵＬ送信の量を潜在的に減少させる追加の利益を有することができる。例えば、同一の地理的エリアに位置する一部の火災センサがＣＧにグループ化され、かつ競合者がチャネルへのアクセスを取得し、イベント（例えば、火災が検出され、または検出されなかったことのいずれか）を報告するパケットを送信した場合、同一のＣＧにおける他のＳＴＡは、それらが同一のデータを報告していることを報告するのに、フレームの圧縮バージョンを送信してもよい。このように、衝突および再送信を減少させるのに加えて、フレームを送信するＣＧにおけるＳＴＡによって生じる媒体占有時間を著しく低減させることができる。

ＣＧ競合者の役割は、いくつかの方法の少なくとも１つで、コンテンショングループにおけるＷＴＲＵに割り当てられてもよい。実施形態では、ＡＰなどの基地局またはＷＴＲＵが、ＣＧにおけるＳＴＡなどのＷＴＲＵに競合者になるように、管理フレーム、制御フレーム、もしくは他のタイプのフレームで明示的に、または暗黙的（例えば、肯定ＴＩＭインジケーションによって暗示されて）に割り当てられてもよい。例えば、ＡＰは、肯定ＴＩＭインジケーションがいくつかのＣＧに分割され、各ＣＧがＮ個のＳＴＡを含むことを、ＳＴＡと事前ネゴシエートしてもよい。最初のＮ個の肯定ＴＩＭインジケーションに関連付けられたＮ個のＳＴＡは、ＣＧ１にあってもよく、第１の肯定ＴＩＭインジケーションに関連付けられたＳＴＡが、ＣＧ１に対する競合者であってもよい。同様に、第（Ｎ＋１）から第２Ｎの肯定ＴＩＭインジケーションに関連付けられた次のＮ個のＳＴＡは、ＣＧ２にあってもよく、第（Ｎ＋１）の肯定ＴＩＭインジケーションに関連付けられたＳＴＡが、ＣＧ２に対する競合者であってもよい。

別の実施形態では、ＣＧは、すべての時間にわたって競合者であるように割り当てられた特定のＳＴＡを有してもよい。代わりに、ＣＧにおけるＳＴＡは、ＣＧの競合者の役割を交替で引き受けてもよい（rotate to take on）。ここで、ＳＴＡは、事前に判定された順序に従って、競合者になってもよい（例えば、ＳＴＡに対するＭＡＣアドレスまたはアソシエーションＩＤ（ＡＩＤ）の順序）。別の実施形態では、競合者は、競合者の役割をＣＧにおける別のＳＴＡに明示的に引き渡してもよい。

ＣＧを競合するとき、競合者は、異なるアクセスカテゴリ、または拡張型分散チャネルアクセス（ＥＤＣＡ：enhanced distributed channel access）パラメータの異なるセットの１または複数を使用してもよい。例えば、新たなアクセスカテゴリが、グループ競合に対して定義されてもよく、それは、ＳＴＡベースのアクセスカテゴリよりも高い優先度を有してもよい。そのような新たなアクセスカテゴリは、ＡＣ＿ＧＰ＿ＶＯ（音声トラフィックに対するグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿ＶＩ（ビデオトラフィックに対するグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿ＢＥ（ベストエフォートトラフィックに対するグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿ＢＫ（バックグラウンドトラフィックに対するグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿ＭＧ（グループ管理および／または制御フレームに対するグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿ＳＥＮ（センサおよび／またはメータに対するグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿Ｅｍｅｒｇｅｎｃｙ（火事、侵入者検出、または患者の心臓発作などの、緊急事態の報告に対するグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿ＰＳ（ＳＴＡの電力を節約するためのグループアクセスカテゴリ）、ＡＣ＿ＧＰ＿ＬＳ（長期スリープ中のＳＴＡの電力を節約し、長いバッテリ寿命を追求するためのグループアクセスカテゴリ）、ならびにＡＣ＿ＧＰ＿ＦＩＬＳ（例えば、ともに移動しているＳＴＡのグループに対する高速初期リンクセットアップに対するグループアクセスカテゴリ）を含んでもよい。これらのアクセスカテゴリは、ローカルＥＤＣＡパラメータの別個のセットを使用することによって、明示的または暗黙的に定義されてもよい。加えて、これらのアクセスカテゴリは、既存のアクセスカテゴリよりも高いまたは低い優先度を有してもよい。

図６は、グループベースのチャネル競合の例６００の図である。図６に示される例では、グループベースのチャネルコンテンション期間は、基地局またはＷＴＲＵ（例えば、ＡＰ）が次の間隔において媒体アクセスを許可されたＷＴＲＵのセットを公表する、ビーコン、ショートビーコン、または他のタイプの管理フレーム、制御フレーム、もしくは拡張フレーム６０２によって先行されてもよい。実施形態では、媒体にアクセスすることを許可されたＷＴＲＵのセットはまた、グループベースのチャネル競合の開始時にウェイクアップするようにスケジュールされてもよい。実施形態では、グループベースのチャネル競合に参加するＣＧにおけるＷＴＲＵは、他のＷＴＲＵが送信することを許可されない特別な間隔に割り当てられてもよい。これらのＷＴＲＵはまた、トラフィック優先度、ＳＴＡタイプなどに基づいて、異なるＥＤＣＡパラメータで、またはそれらなしで、他のＷＴＲＵが通常の（例えば、ＳＴＡベースの）チャネル競合を行う間隔において、グループベースのチャネル競合を行ってもよい。

グループベースのコンテンション期間の開始時に、各ＣＧに対する競合者は、異なるＥＤＣＡパラメータで、またはそれらなしで、例えば、通常の（Ｅ）ＤＣＦプロシージャに従って、チャネルを競合してもよい。図６に示される例では、ＤＩＦＳ期間６０４およびバックオフスロット６１６の後、ＣＧ１に対する競合者は、チャネルへのアクセスを取得し、および、第１のパケット６１８（例えば、ＵＬまたはピアツーピア）を送信する。第１のパケットは、正規のフォーマットまたは短いフォーマットのＰＰＤＵであってもよい。それはまた、ＭＳＤＵ、Ａ−ＭＰＤＵ、またはＡ−ＭＳＤＵを含んでもよい。競合者からの第１のパケットは、ＰＬＣＰ／ＭＡＣヘッダ、初期スクランブリングシード、またはフレーム本体において、ＣＧに関する情報（例えば、ＣＧのＩＤもしくはＣＧにおけるＳＴＡの順序）、ＣＧ１送信期間６０６に対する媒体を確保するためのＮＡＶ情報、またはＵＬもしくはピアツーピアパケット（例えば、ＰＳ−ＰｏｌｌもしくはＡＰへのデータフレーム）の１または複数を含んでもよい。

媒体へのアクセスを有さないＣＧにおけるＷＴＲＵは、媒体アクセスを取得したＣＧの競合者（例えば、図６ではＣＧ１に対する競合者）からの第１のパケットに含まれるＮＡＶ設定の期間にスリープしてもよい。ＮＡＶ値は、さらなる媒体アイドル（したがって、浪費した）時間を回避するために、残りのＣＧが、現在のＣＧ送信期間の終了時に合わせて（in time at the end of the current CG transmission）ウェイクアップするように、何らかの最小値になるように計算されてもよい。

ＣＧ１に対するＣＧ送信期間６０６０は、ＣＧ１の競合者からの第１のパケット６１８に続く。ＣＧ１に対する送信期間６０６が終了した後、他のＣＧの競合者は、ＤＩＦＳ期間６０８を待機し、そして、トラフィック優先度、ＳＴＡタイプなどに基づいて、ＥＤＣＡパラメータセットで、またはそれらなしで、例えば、通常の（Ｅ）ＤＣＦプロシージャに従って、それぞれのＣＧに対する媒体へのアクセスの競合を開始する。図６に示される例では、ＣＧ５に対する競合者が、チャネルへのアクセスを取得し、および第１のパケット６２０を送信する。ＣＧ５に対するＣＧ送信期間６１０は、ＣＧ５の競合者からの第１のパケット６２０に続く。ＣＧ５に対する送信期間６１０が終了した後、他のＣＧの競合者は、ＤＩＦＳ期間６１２を待機し、そして、それぞれのＣＧに対する媒体へのアクセスの競合を開始する。この時、図６に示される例では、ＣＧ２に対する競合者は、チャネルへのアクセスを取得し、および第１のパケット６２２を送信する。ＣＧ２に対するＣＧ送信期間６１４は、ＣＧ２の競合者からの第１のパケット６２２に続く。このプロセスは、同様の方法で繰り返されてもよい。

図７は、グループベースのチャネル競合の別の例７００の図である。図７に示される例では、グループベースのチャネルコンテンション期間は、基地局またはＷＴＲＵ（例えば、ＡＰ）がＣＧ１の競合者のＩＤまたはＣＧ１のＩＤを公表する、ビーコン、ショートビーコン、または他のタイプの管理制御フレーム７０２によって先行されてもよい。ＣＧ１の競合者は、ビーコン、ショートビーコン、または他のタイプの管理フレーム、制御フレーム、もしくは拡張フレーム７０２の終了の後のＳＩＦＳ期間７０４に、第１のパケット７１６の送信を開始してもよい。実施形態では、ＣＧ１に対する競合者はまた、グループベースのチャネルコンテンション期間のスケジュールされた開始時間に即時に送信を開始してもよい。

ＣＧ１に対する送信期間７０６が終了した後、他のＣＧの競合者は、ＤＩＦＳ期間７０８を待機し、そして、トラフィック優先度、ＳＴＡタイプなどに基づいて、ＥＤＣＡパラメータセットで、またはそれなしで、例えば、通常の（Ｅ）ＤＣＦプロシージャに従って、それぞれのＣＧに対する媒体へのアクセスの競合を開始してもよい。図７に示される例では、ＣＧ５に対する競合者は、チャネルへのアクセスを取得し、および第１のパケット７１８を送信する。ＣＧ５に対するＣＧ送信期間７１０は、ＣＧ５の競合者からの第１のパケット７１８に続く。ＣＧ５に対する送信期間７１０が終了した後、他のＣＧの競合者は、ＤＩＦＳ期間７１２を待機し、そして、それぞれのＣＧに対する媒体へのアクセスの競合を開始してもよい。この時、図７に示される例では、ＣＧ２に対する競合者は、チャネルへのアクセスを取得し、および第１のパケット７２０を送信する。ＣＧ２に対するＣＧ送信期間７１４は、ＣＧ２の競合者からの第１のパケット７２０に続く。このプロセスは、少なくとも各ＣＧが媒体にアクセスする機会を有するまで、繰り返されてもよい。

図８は、グループベースのチャネル競合８００の別の例の図である。図８に示される例では、グループベースのチャネルコンテンション期間は、基地局またはＷＴＲＵ（例えば、ＡＰ）がＣＧのＩＤおよびＣＧの送信の順序を公表する、ビーコン、ショートビーコン、または他のタイプの管理フレーム、制御フレーム、もしくは拡張フレーム８０２によって先行されてもよい。公表された順序に従って、ＣＧ１に対する競合者は、ビーコン、ショートビーコン、または他のタイプの管理制御フレーム８０２の終了時からＳＩＦＳ期間８０４経過後に、第１のパケット８１６の送信を開始してもよい。実施形態では、ＣＧ１に対する競合者は、グループベースのチャネルコンテンション期間に対してスケジュールされた開始時間に即時に送信を開始してもよい。第Ｎの送信ＣＧの送信期間の終了後に、第（Ｎ＋１）のＣＧに対する競合者は、第Ｎの送信ＣＧの送信期間における最後のパケットであることを示す、第ＮのＣＧにおけるＳＴＡによって送信されたパケットを受信したときに（例えば、ＭＡＣヘッダにおけるエンドオブサービス期間（ＥＯＳＰ）ビットを１になるように設定し、および／もしくはモアデータビットを０になるように設定して）、またはグループ間送信許可を通じて（以下でより詳細に説明される）、媒体へのアクセスを取得してもよい。第（Ｎ＋１）のＣＧに対する競合者は、第Ｎの送信ＣＧの送信期間の最終パケットの終了後のＳＩＦＳ時間に、またはグループ間送信許可を含むパケットの終了後のＳＩＦＳ期間に、送信を開始してもよい。

図８に示される例では、ＣＧ１に対する送信期間８０６の終了時に、ＣＧ２に対する競合者は、ＣＧ１に対する送信期間８０６における最後のパケットであることを示す、ＣＧ１におけるＳＴＡによって送信されたパケット（図示されず）を受信したときに、媒体へのアクセスを取得する。ＣＧ２に対する競合者は、ＣＧ１に対する送信期間８０６における最後のパケットの終了後のＳＩＦＳ期間８０８に、またはグループ間送信許可を含むパケットの終了後のＳＩＦＳ期間８０８に、第１のパケット８１８の送信を開始してもよい。ＣＧ２に対する送信期間８１０の終了時に、ＣＧ３に対する競合者は、ＣＧ２に対する送信期間８１０における最後のパケットであることを示す、ＣＧ２におけるＳＴＡによって送信されたパケット（図示されず）を受信したときに、媒体へのアクセスを取得する。ＣＧ３に対する合者は、ＣＧ２に対する送信期間８１０の最後のパケットの終了後のＳＩＦＳ期間８１２に、またはグループ間送信許可を含むパケットの終了後のＳＩＦＳ期間８１２に、第１のパケット８２０の送信を開始してもよい。このプロセスは、公表された順序に従って、すべてのＣＧが媒体にアクセスする順番を得るまで繰り返されてもよい。

第１のパケットがＣＧの競合者によって送信されると、ＣＧの送信期間が開始する。所与のＣＧに対する送信期間の間、ＣＧにおけるＷＴＲＵは、ＣＧ内送信許可および代理ポーリングを使用して、媒体にアクセスしてもよい。

ＣＧ内送信許可および代理ポーリングに対し、送信するＵＬパケットをＣＧにおける全てのＳＴＡが常に有することが想定されてもよい。ビーコンまたはショートビーコンにおける肯定ＴＩＭインジケーションで、ＷＴＲＵによってＣＧが形成される場合、すべてのＷＴＲＵは、バッファリングされたＤＬデータパケットを取り出すために、ＰＳ−Ｐｏｌｌを送信する必要がある。ＴＩＭインジケーションまたはビーコンをリスンしないＷＴＲＵによってＣＧが形成される場合、ＷＴＲＵは、バッファリングされたデータの存在について問い合わせるために、ＰＳ−ＰｏｌｌをＡＰに送信する必要がある。ＣＧにおけるＷＴＲＵは、送信するＵＬデータを有する場合、それがポーリングされているとき、またはＣＧ内送信許可を受信したときに、別のＷＴＲＵまたは基地局（例えば、ＡＰ）にデータを送信してもよい。ＷＴＲＵが、送信するＵＬデータを有し、およびＣＧに属さない場合、それは、同一または異なるＥＣＤＡパラメータで、通常のＤＣＦプロシージャを使用して、媒体アクセスを競合してもよい。

ＣＧ送信期間は、ＣＧに対する競合者（例えば、ＳＴＡ１）が、第１のパケットを送信した後に開始してもよい。この第１のパケットは、上述したように、多くのタイプのフレームの１つであってもよい。例えば、ＳＴＡ１からの第１のパケットは、ＡＰに送信されるＰＳ−Ｐｏｌｌまたは他の任意のタイプのＵＬパケットであってもよい。ＳＴＡ１からの第１のパケットに応答して、ＡＰは、ＳＴＡ１に対するＤＬデータパケット、ＳＴＡ１に対するバッファリングされたパケットが存在しないことを示すフレーム、またはＡＣＫフレーム（この場合、ＡＰはＳＴＡ１に対するＤＬデータパケットを後で送信してもよい）の１つを送信してもよい。

ＡＰが、ＰＳ−ＰｏｌｌまたはＳＴＡ１からの他の任意のタイプのＵＬパケットにＡＣＫフレームで応答するとき、ＡＰは、ＡＣＫフレームに続くＳＩＦＳ間隔後に、ＳＴＡ１に対するＤＬデータパケットを送信してもよく、それに応答して、ＳＴＡ１は、ショートＡＣＫ、ＡＣＫ、ＢＡ、ＡＣＫ＋Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴ（ＡＣＫおよびグループ内送信許可（Intra-Group Transmission Grant））、ＡＣＫ＋ＳＵＲ−Ｐｏｌｌ（ＡＣＫおよびグループ内代理ポーリング（Intra-Group Surrogate poll））、データフレーム、またはＡＣＫ＋ＥｎｄＣＧＴＸ（ＡＣＫおよびＥｎｄ−ＣＧ−ＴｒａｎｓｍｉｓｓｉｏＰｅｒｉｏｄ）などのフレームを使用して、ＤＬデータパケットの受信に確認応答してもよい。

ＡＰが、ＰＳ−ＰｏｌｌまたはＳＴＡ１からＡＰへの他の任意のタイプのＵＬパケットに、ＳＴＡ１に対するバッファリングされたパケットが存在しないことを示すフレームで応答するとき、ＡＰからのＡＣＫフレームを受信すると、ＳＴＡ１は、ＳＩＦＳ間隔の後、Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴフレームを送信して、ＣＧにおける次のＳＴＡ（例えば、ＳＴＡ２）にグループ内送信許可を提供してもよい。代わりに、ＳＴＡ１はまた、Ｓｕｒ−Ｐｏｌｌフレームを送信して、ＳＴＡ２に対する代理ポーリングを行ってもよい。現在のＳＴＡがＣＧにおける最後の送信ＳＴＡである場合、ＳＴＡは、ＥｎｄＣＧＴＸフレームを送信して、ＣＧ送信期間の終了を公表してもよい。代わりに、ＳＴＡ１が、第１のＵＬパケットにおいて、送信するさらなるＵＬパケットを有さないことを示す場合、短いまたは正規のＡＣＫまたはＢＡの代わりに、ＡＰは、ＡＣＫ＋ＰｏｌｌフレームまたはＡＣＫ−Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレームを送信して、ＣＧにおける次のＳＴＡ（例えば、ＳＴＡ２）に、ＰＳ−Ｐｏｌｌまたはデータなどの任意のＵＬパケットを送信するための媒体アクセスを許可してもよい。

ＡＰが、ＰＳ−Ｐｏｌｌ（またはＳＴＡ１からの他の任意のタイプのＵＬパケット）にＤＬデータフレームで応答するとき、ＳＴＡ１は、送信するさらなるＵＬデータを有する場合、データフレームを用いて応答してもよく、またはＳＴＡ１に送信するさらなるＤＬデータを有することをＡＰが示した場合、短いもしくは通常のＡＣＫもしくはＢＡで、ＤＬデータフレームの受信に確認応答してもよい。ＳＴＡ１に送信するさらなるＤＬデータを有さないことをＡＰが示した場合、ＳＴＡ１は、ＣＧにおける次のＳＴＡ（例えば、ＳＴＡ２）にグループ内送信許可を提供するために、ＡＣＫ＋Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴでＤＬデータフレームの受信に確認応答してもよい。ＳＴＡ１はまた、ＤＬデータフレームの受信に確認応答するとともに、ＳＴＡ２に対する代理ポーリングを行うために、ＡＣＫ＋ＳＵＲ−Ｐｏｌｌを送信してもよい。ＳＴＡ１に送信するさらなるＤＬデータを有さないことをＡＰが示した場合、ＳＴＡ１は、ＣＧ送信期間の終了を示すのに加えて、ＡＣＫ−ＥｎｄＣＧＴＸフレームで、ＤＬデータフレームの受信に確認応答してもよい。異なる実施形態では、ＣＧにおけるＳＴＡの送信順序は、固定されてもよく、または事前構成されたスケジュールもしくはランダムなスケジュールに従って交代されてもよい。

フレームＩｎｔｒａ−ＣＧ−ＴＸ−ＧＴ、ＳＵＲ−Ｐｏｌｌ、ＥｎｄＣＧＴＸ、ＡＣＫ＋Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴ、ＡＣＫ＋ＳＵＲ−Ｐｏｌｌ、ＡＣＫ＋ＥｎｄＣＧＴＸのデザインは、管理フレーム、制御フレーム、拡張フレームの新たなサブタイプ、または新たなタイプのフレームとして実装されてもよい。それらはまた、アクションフレームまたはＡＣＫなしのアクションフレームとして実装されてもよい。例えば、それらは、タイプＨＴ、ＶＨＴ、ＴＶ高スループット（ＴＶＨＴ）、ＩＥＥＥ８０２．１１ａｈ、高効率ＷＬＡＮ（ＨＥＷ）のアクションフレームもしくはＡＣＫなしのアクションフレームとして、または新たなタイプのアクションフレームとして実装されてもよい。それらはまた、全ての情報がＰＬＣＰヘッダ部で搬送されるショートフレームとしても実装されてもよい。

Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴフレームに関して、これらのフレームは、ＷＴＲＵ（例えば、ＳＴＡまたはＡＰ）によって、グループ内送信許可が提供されるＣＧにおける別のＷＴＲＵ（例えば、ＡＰまたは次のＳＴＡ（例えば、ＳＴＡ２））に送信されてもよい。フレームがＣＧにおける次のＳＴＡに送信される場合、ＡＰは、ＢＳＳまたはＯＢＳＳにおける隠れノードを防止するために、ＳＩＦＳ期間の後、Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴフレームを繰り返すことを選択してもよい。Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴがＡＰに送信される場合、それは、ＡＩＤ、ＭＡＣアドレス、またはＡＰと送信ＳＴＡが合意した他のタイプのＩＤなど、ＳＴＡ２の明示的なＩＤを、ＰＬＣＰ／ＭＡＣヘッダ、フレーム本体、初期スクランブラシーケンスなどに含めてもよい。例えば、ＳＴＡ２のＩＤは、ＭＡＣヘッダのアドレス３および／またはアドレス４フィールドに含まれてもよい。ＰＬＣＰまたはＭＡＣヘッダにおけるビット（例えば、フレーム制御フィールドにおける）は、アドレス３もしくはアドレス４フィールドが使用中であることを示すために、および／またはフレームタイプ／サブタイプ／アクションフレームカテゴリフィールドの組合せで、アドレス３もしくはアドレス４フィールドがグループ内送信許可を受信するＳＴＡのＩＤに対して使用されることを示すために使用されてもよい。Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴフレームがＡＰによって送信される場合、ＣＦ−Ｐｏｌｌ、ＰＳ−Ｐｏｌｌ、Ｄａｔａ＋Ｐｏｌｌなどのフレームが、Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴフレームとして再利用されてもよい。特定のプロトコルに応じて、ＣＧにおけるピアＳＴＡから、またはＡＰからＩｎｔｒａ−ＣＧ−ＴＸ−ＧＴを受信したことに応答して、ＳＴＡは、ＳＩＦＳ期間の後、ＵＬフレームまたはピアツーピアフレームの送信を開始してもよい。Ｉｎｔｒａ−ＣＧ−ＴＸ−ＧＴフレームがＣＧにおけるピアＳＴＡから受信され、およびＡＰがＩｎｔｒａ−ＣＧ−ＴＸ−ＧＴを繰り返すように構成される場合、グループ内送信許可を受信するＳＴＡは、ＡＰからＩｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレームを受信した後のＳＩＦＳ期間にのみ、送信を開始してもよい。

ＳＵＲ−Ｐｏｌｌフレームに関して、これらのフレームは、ＣＧにおける別のピアＳＴＡ（例えば、ＳＴＡ２）に対するバッファリングされたいずれかのＤＬフレームの存在について問い合わせるために、ＣＧにおけるＳＴＡからＡＰに送信されてもよい。ＳＵＲ−Ｐｏｌｌフレームは、ＡＩＤ、ＭＡＣアドレス、またはＡＰと送信ＳＴＡが合意した他のタイプのＩＤなど、ＳＴＡ２の明示的なＩＤを、ＰＬＣＰ／ＭＡＣヘッダ、フレーム本体、初期スクランブラシーケンスなどに含めてもよい。例えば、ＳＴＡ２のＩＤは、ＭＡＣヘッダのアドレス３および／またはアドレス４フィールドに含まれてもよい。ＰＬＣＰまたはＭＡＣヘッダにおけるビット（例えば、フレーム制御フィールドにおける）は、アドレス３もしくはアドレス４フィールドが使用中であることを示すために、および／またはフレームタイプ／サブタイプ／アクションフレームカテゴリフィールドの組み合わせで、アドレス３もしくはアドレス４フィールドが、送信ＳＴＡが代理ポーリングを行っているＳＴＡのＩＤのために使用されることを示すために使用されてもよい。ＳＴＡ２に対するＳＵＲ−Ｐｏｌｌを受信すると、ＡＰは、ＳＴＡ２に対するＤＬフレームの送信を即時に開始してもよい。代わりに、ＡＰは、最初にＡＣＫフレームで応答し、ＳＩＦＳ時間の後、ＳＴＡ２に対するＤＬフレームの送信を開始してもよい。ＡＰはまた、ＳＴＡ２に対するバッファリングされたフレームが存在しないことを示す、ＳＴＡ２へのポーリングなどのフレームで応答し、ＳＴＡ２が有することができる任意のＵＬフレームを送信することをＳＴＡ２に許可してもよい。

ＥｎｄＣＧＴＸフレームに関して、これらのフレームは、現在のＣＧ送信期間が終了したことを示すために、ＣＧにおけるＳＴＡによって、またはＡＰによって送信されてもよい。このフレームは、ＡＰに送信されてもよく、またはブロードキャストもしくはマルチキャストアドレスに送信されてもよい。それはまた、グループ間送信許可として機能する、次のＣＧのＡＰ／競合者に送信されてもよい。ＥｎｄＣＧＴＸフレームを受信すると、ＡＰおよびＳＴＡは、またＣＧにおけるＳＴＡとともに、チャネルアクセスルールに従って媒体を競合してもよい。

ＡＣＫ＋Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレームに関して、これらのフレームは、Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレームとほぼ等価であってもよい。しかしながら、相違点は、このフレームが、Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレームの送信の直前に送信ＳＴＡに送信されるフレームの受信を確認応答することであってもよい。ＡＣＫ＋Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレームはまた、送信ＳＴＡに送信されるフレームのシーケンスに対するブロックＡＣＫを提供するために、ＢＡにおけるフィールドに類似した、ブロックＡＣＫフィールドをそれが含むような方法でも実装されてもよい。

ＡＣＫ＋ＳＵＲ−Ｐｏｌｌフレームに関して、これらのフレームは、ＳＵＲ−Ｐｏｌｌフレームとほぼ等価であってもよい。唯一の違いは、このフレームがまた、ＡＣＫ＋ＳＵＲ−Ｐｏｌｌフレームの送信の直前に送信ＳＴＡに送信されるフレームの受信に確認応答することであってもよい。ＡＣＫ＋ＳＵＲ−Ｐｏｌｌフレームはまた、送信ＳＴＡに送信されるフレームのシーケンスに対するブロックＡＣＫを提供するための、ＢＡにおけるフィールドに類似した、ブロックＡＣＫフィールドをそれが含むような方法で実装されてもよい。

ＡＣＫ＋ＥｎｄＣＧＴＸフレームに関して、これらのフレームは、ＥｎｄＣＧＴＸフレームとほぼ等価であってもよい。唯一の違いは、このフレームが、ＡＣＫ＋ＥｎｄＣＧＴＸフレームの送信の直前に送信ＳＴＡに送信されるフレームの受信に確認応答することであってもよい。ＡＣＫ＋ＥｎｄＣＧＴＸフレームはまた、送信ＳＴＡに送信されるフレームのシーケンスに対するブロックＡＣＫを提供するための、ＢＡにおけるフィールドに類似した、ブロックＡＣＫフィールドをそれが含むような方法で実装されてもよい。

図９は、例示的なＣＧ内送信許可および代理ポーリングプロシージャ９００の図である。図９に示される例では、所与のＣＧに対する競合者（ＳＴＡ１）は、ビーコン９０２の後のＳＩＦＳ期間９０４経過に、第１のパケット９０８を送信してもよい。ＣＧに対する競合者（ＳＴＡ１）が第１のパケットを送信した後、所与のＣＧに対するＣＧ送信期間９０６が開始する。ここで、この第１のパケットは、ＰＳ−Ｐｏｌｌパケット９０８である。ＳＴＡ１からの第１のパケットに応答して、ＡＰは、ＳＴＡ１に対するＤＬデータパケット９１０を送信する。そして、ＡＰまたはＳＴＡ１は、ＡＣＫ＋Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレーム９１２をＳＴＡ２に送信することによって、グループ内送信許可９２８を次のＳＴＡ（ＳＴＡ２）に提供する。このフレームは、ＳＴＡ２にグループ内送信許可を提供し、また、直前にＳＴＡ１に送信されたフレームの受信に確認応答する。ＡＣＫ＋Ｉｎｔｒａ−ＧＰ−ＴＸ−ＧＴフレーム９１２を受信したことに応答して、ＳＴＡ２は、ＵＬデータ９１４を送信する（例えば、ＳＩＦＳ期間の後）。

そして、ＡＰは、ＡＣＫ＋Ｉｎｔｒａ−ＧＰ−Ｐｏｌｌフレーム９１６をＳＴＡ３に送信し、また、直前にＳＴＡ２によって送信されたＵＬデータ９１４に確認応答し、ＤＬデータに対してＳＴＡ３をポーリングすることによって、グループ内送信許可９３０を次のＳＴＡ（ＳＴＡ３）に提供してもよい。このフレームを受信したことに応答して、ＳＴＡ３は、ＵＬデータ９１８を送信し（例えば、ＳＩＦＳ期間の後）、また、ＡＰからＤＬデータ９２０を受信する。そして、ＳＴＡ３は、ＡＣＫ−ＳＵＲ−Ｐｏｌｌフレーム９２２をＡＰに送信し、ＳＴＡ４に対してバッファリングされたいずれかのＤＬフレームの存在について問い合わせ、ＤＬデータ９２０の受信に確認応答することによって、グループ内送信許可９３２を、次のＳＴＡ（ＳＴＡ４）に提供してもよい。ＡＣＫ−ＳＵＲ−Ｐｏｌｌフレーム９２２を受信したことに応答して、ＡＰは、ＤＬデータ９２４をＳＴＡ４に送信する。これが完了したとき、ＳＴＡ４は、ＡＣＫ＋ＥｎｄＣＧＴＸフレーム９２６を送信し、ＤＬデータ９２４の受信に確認応答し、ＣＧ送信期間９０６が終了したことを示す。

ＣＧ送信期間の終了時に、グループ間送信許可および代理ポーリングが発生してもよい。グループ間送信許可および代理ポーリングに対するプロシージャおよびフレーム設計は、グループ内送信許可およびポーリングのそれらと同様である。

図１０は、例示的なグループ間送信許可および代理ポーリングプロシージャ１０００の図である。ＣＧ（例えば、ＣＧ１）における最後のＳＴＡが送信している場合、それは、ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレームまたはＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレームを使用して、グループ間送信許可を次のＣＧ（例えば、ＣＧ２）に対する競合者に提供してもよい。図１０に示される例では、ＣＧ１に対する競合者は、ビーコン１００２の後のＳＩＦＳ期間１００４に、第１のパケット１０１６を送信し、ＣＧ１に対する送信期間１００６を開始する。ＣＧ１に対する送信期間１００６の終了時に、ＡＰまたはＣＧ１において送信する最後のＳＴＡは、ＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレーム１０１８を送信し、ＣＧ１に対する送信期間を終了し、ＣＧ２に対する競合者にグループ間送信許可１０２４を提供し、ＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレーム１０１８を送信する直前にＡＰまたはＣＧ１において送信する最後のＳＴＡによって受信されたフレームに確認応答する。実施形態では、ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴまたはＥｎｄＣＧＴＸ＋ＡＣＫ＿ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレームは、ＣＧ２に対する競合者に、グループＩＤなどのＣＧ２に関連付けられたアドレスまたはＡＰに送信されてもよい。ＡＰは、隠れノードを防止するために、ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴまたはＥｎｄＣＧＴＸ＋ＡＣＫ＿Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレームを繰り返すことを選択してもよい。

ＥｎｄＣＧＴＸ−Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴまたはＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレームを受信したことに応答して、ＣＧ２に対する競合者は、ＳＩＦＳ期間の後、送信を開始してもよい。図１０に示される例では、ＣＧ２に対する競合者は、ＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレーム１０１８を受信した後のＳＩＦＳ期間１００８に、第１のパケット１０２０を送信する。ＡＰが、ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴまたはＥｎｄＣＧＴＸ＋ＡＣＫ＿Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレームを繰り返すように構成される場合、ＣＧ２に対する競合者は、ＡＰによって送信された、繰り返されるＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴまたはＥｎｄＣＧＴＸ＋ＡＣＫ＿Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴフレームを受信した後のＳＩＦＳ期間に、送信を開始してもよい。図１０に示される例では、ＣＧ２に対する送信期間１０１０は、ＣＧ２に対する競合者による第１のパケット１０２０の送信に続いて開始する。

ＣＧにおける最後のＳＴＡが送信しているとき、それは、ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−ＰｏｌｌフレームまたはＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−Ｐｏｌｌフレームを使用して、次のＣＧ（例えば、ＣＧ３）の競合者に対するグループ間代理ポーリングを行ってもよい。図１０に示される例では、ＣＧ２において送信する最後のＳＴＡは、ＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−Ｐｏｌｌフレーム１０２６を送信し、ＣＧ２に対する送信期間１０１０を終了し、グループ間送信許可を次のＣＧ（ＣＧ３）１０３０に提供し、ＣＧ３の競合者に対してバッファリングされたいずれかのＤＬフレームの存在について問い合わせる。ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−ＰｏｌｌフレームまたはＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−Ｐｏｌｌフレームを受信したことに応答して、ＡＰは、次のＣＧの競合者に対するＤＬフレームを送信してもよく、またはＣＧ３の競合者に対してバッファリングされたパケットが存在しないことを示すフレームを送信してもよい。図１０に示される例では、ＳＩＦＳ期間１０１２の後、ＡＰは、ＣＧ３に対する競合者に対するＤＬデータ１０２８を送信し、ＣＧ３に対する送信期間１０１４を開始する。このプロシージャは、ＢＳＳにおけるＣＧのすべてが媒体にアクセスする機会を有するまで繰り返されてもよい。

ＣＧ１におけるすべてのＳＴＡが送信を完了したことをＡＰが検出し、またＣＧ１に対してバッファリングされたパケットをＡＰが有さない場合、ＡＰは、ポーリングフレームまたはＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴをＣＧ２またはＣＧ２の競合者に送信して、ＣＧ２に媒体アクセスを許可してもよい。

フレームＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴ、ＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴ、ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−Ｐｏｌｌフレーム、およびＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−Ｐｏｌｌの設計は、管理フレームもしくは制御フレームの新たなサブタイプとして、または新たなタイプのフレームとして実装されてもよい。加えて、それらは、アクションフレームまたはＡＣＫなしのアクションフレームとしても実装されてもよい。例えば、それらは、タイプＨＴ、ＶＨＴ、ＴＶＨＴ、ＩＥＥＥ８０２．１１ａｈのアクションフレームもしくはＡＣＫなしのアクションフレームとして、または新たなタイプのアクションフレームとして実装されてもよい。それらは、すべての情報がＰＬＣＰヘッダ部で搬送されるショートフレームとしても実装されてもよい。

フレームＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴ、ＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＴＸ−ＧＴ、ＥｎｄＣＧＴＸ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−Ｐｏｌｌフレーム、およびＥｎｄＣＧＴＸ＋ＡＣＫ＋Ｉｎｔｅｒ−ＧＰ−ＳＵＲ−Ｐｏｌｌは、ＡＩＤ、ＭＡＣアドレス、またはＡＰと送信ＳＴＡが合意した他のタイプのＩＤなど、ＷＴＲＵ（例えば、それに対してグループ間送信許可が提供される、またはグループ間代理ポーリングが行われるＳＴＡ）に対する明示的なＩＤを、ＰＬＣＰ／ＭＡＣヘッダ、フレーム本体、初期スクランブラシーケンスなどに含めてもよい。例えば、ＳＴＡ２のＩＤは、ＭＡＣヘッダのアドレス３および／またはアドレス４フィールドの少なくとも一方に含まれてもよい。ＰＬＣＰまたはＭＡＣヘッダにおける（例えば、フレーム制御フィールドにおける）のビットが、アドレス３もしくはアドレス４フィールドが使用中であることを示すために、および／またはフレームタイプ／サブタイプ／アクションフレームカテゴリフィールドと組み合わせて、アドレス３もしくはアドレス４フィールドが、それに対して送信ＳＴＡがグループ間送信許可を提供しており、もしくは代理ポーリングを行っているＳＴＡのＩＤに使用されることを示すために使用されてもよい。

実施形態では、グループ間送信許可および代理ポーリングは、１つのＳＴＡのみを含むＣＧの場合、ＳＴＡベースの送信許可および代理ポーリングに一般化されてもよい（generalized）。

データおよびフレーム圧縮はまた、送信オーバヘッドのさらなる低減のために、ＣＧにおけるＳＴＡに対して使用されてもよい。ＣＧにおけるＳＴＡに対し、それらがセキュリティ鍵を共有し、したがって、それらが互いのパケットを復号してもよいことが仮定されてもよい。同様のデータを検出するＣＧにおけるＳＴＡ（例えば、火災などのイベントを検出するイベントドリブンのセンサ）については、同一のデータ（火事が検出されたか否か）の繰り返しは、追加の情報を提供しない。代わりに、ＣＧは、圧縮パケットフォーマット、例えば、同一データインジケーションフレームについてネゴシエートしてもよく、同一データインジケーションフレームは、長さが短く、ＣＧ送信期間において送信したばかりの同一のＣＧにおける別のＳＴＡと同一のデータを送信ＳＴＡが観測したことを示してもよい。

ＣＧにおけるＳＴＡがフレームを送信する場合、同一のデータを観測する別のＳＴＡは、正規のフレームの代わりに、単に同一データインジケーションフレームを送信してもよい。同一データインジケーションフレームは、フレームの識別子（シーケンスまたはシーケンス制御番号などの）、およびＡＩＤ、ＭＡＣアドレス、またはＡＰと送信ＳＴＡが合意した他のタイプのＩＤなど、ＳＴＡ（同一のデータを送信したＳＴＡ）の明示的なＩＤを、ＰＬＣＰ／ＭＡＣヘッダ、フレーム本体、初期スクランブラシーケンスなどに含めてもよい。例えば、参照ＳＴＡのＩＤは、ＭＡＣヘッダのアドレス３および／またはアドレス４フィールドに含まれてもよい。ＰＬＣＰまたはＭＡＣヘッダにおける（例えば、フレーム制御フィールドにおける）ビットが、アドレス３もしくはアドレス４フィールドが使用中であることを示すために、および／またはフレームタイプ／サブタイプ／アクションフレームカテゴリフィールドと組み合わせて、アドレス３もしくはアドレス４フィールドが、同一のデータを観測するＳＴＡのＩＤのために使用されることを示すために使用されてもよい。

同一データインジケーションフレームは、管理フレームもしくは制御フレームの新たなサブタイプ、または新たなタイプのフレームとして実装されてもよい。加えて、それらはまた、アクションフレームまたはＡＣＫなしのアクションフレームとして実装されてもよい。例えば、それらは、タイプＨＴ、ＶＨＴ、ＴＶＨＴ、ＩＥＥＥ８０２．１１ａｈ、ＨＥＷのアクションフレームもしくはＡＣＫなしのアクションフレーム、または新たなタイプのアクションフレームとして実装されてもよい。それらはまた、すべての情報がＰＬＣＰヘッダ部で搬送されるショートフレームとしても実装されてもよい。特定のフレームにおける別のＷＴＲＵ（例えば、ＳＴＡ２）によって報告されたのと同一のデータをＳＴＡ１が観測したことを示す同一データインジケーションフレームをＷＴＲＵ（例えば、ＳＴＡ１）から受信したことに応答して、ＡＰは、ＳＴＡ２によって送信された特定のフレームのフレーム本体をコピーすることによって、ＳＴＡ１からの新たなデータフレームを再構成してもよい。

実施形態
１．無線ネットワークにおいてスモールパケットを転送する方法であって、無線送信／受信ユニット（ＷＴＲＵ）が、媒体アクセス制御（ＭＡＣ）または物理レイヤ収束プロトコル（ＰＬＣＰ）ヘッダの１または複数を有するパケットを生成するステップであって、ＭＡＣまたはＰＬＣＰヘッダの１または複数は、フィールドを含む、ステップを含む方法。

２．送信するためにバッファリングされたデータをＷＴＲＵが有する場合、ＷＴＲＵが、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間または送信機会（ＴＸＯＰ）の少なくとも一方を示す情報をフィールド内に含めるステップをさらに含む実施形態１に記載の方法。

３．ＷＴＲＵが、無線ネットワーク内の別のＷＴＲＵにパケットを送信するステップをさらに含む実施形態１または２に記載の方法。

４．ＷＴＲＵが、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間またはＴＸＯＰの一方に基づいた許可されたＴＸＯＰを有する別のパケットを他のＷＴＲＵから受信するステップをさらに含む実施形態１乃至３のいずれか１つに記載の方法。

５．送信するためにバッファリングされたデータをＷＴＲＵが有さない場合、ＷＴＲＵが、０をフィールド内に含めるステップをさらに含む実施形態１乃至４のいずれか１つに記載の方法。

６．ＷＴＲＵが、許可されたＴＸＯＰを使用して、少なくとも１つのパケットを送信するステップをさらに含む実施形態４または５に記載の方法。

７．送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間は、送信するためにＷＴＲＵがバッファリングしたデータの各パケットをＷＴＲＵが送信するために必要とされる時間、または送信するためにＷＴＲＵがバッファリングしたデータのパケットのすべてをＷＴＲＵが送信するために必要とされる合計時間の一方である実施形態２乃至６のいずれか１つに記載の方法。

８．フィールドは、バッファトラフィックインジケーションフィールドである実施形態１乃至７のいずれか１つに記載の方法。

９．ＷＴＲＵがパケットを生成するステップは、ＷＴＲＵがスリープ状態からウェイクアップするステップをさらに含む実施形態１乃至８のいずれか１つに記載の方法。

１０．ＷＴＲＵがスリープ状態からウェイクアップしたのに応答して、ＷＴＲＵが、バッファトラフィックインジケーションフィールドを含む省電力ポーリング（ＰＳ−Ｐｏｌｌ）フレームを送信するステップであって、バッファトラフィックインジケーションフィールドは、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされるＴＸＯＰ、または送信するためにバッファリングされたデータをＷＴＲＵが有さない場合の０のうちの少なくとも１つを示す、ステップをさらに含む実施形態９に記載の方法。

１１．許可されたＴＸＯＰは、フィールド内で提供された時間に基づいた期間を有する実施形態４乃至１０のいずれか１つに記載の方法。

１２．無線ネットワークは、無線ローカルエリアネットワーク（ＷＬＡＮ）である実施形態１乃至１１のいずれか１つに記載の方法。

１３．ＷＴＲＵは、ＷＬＡＮ内の非アクセスポイント（非ＡＰ）局（ＳＴＡ）である実施形態１乃至１２のいずれか１つに記載の方法。

１４．他のＷＴＲＵは、ＷＬＡＮ内のアクセスポイント（ＡＰ）である実施形態３乃至１３のいずれか１つに記載の方法。

１５．パケットは、省電力ポーリング（ＰＳ−Ｐｏｌｌ）フレーム、送達確認（ＡＣＫ）フレーム、データフレーム、およびブロック送達確認（ＢＡ）フレームのうちの１つである実施形態１乃至１４のいずれか１つに記載の方法。

１６．パケットのＭＡＣまたはＰＬＣＰヘッダの１または複数は、パケット内に含まれる動的なフレームチェックシーケンス（ＦＣＳ）フィールドの長さを示すフィールドをさらに含む実施形態１乃至１５のいずれか１つに記載の方法。

１７．ＦＣＳフィールドは、４バイト未満の長さを有する実施形態１６に記載の方法。

１８．媒体アクセス制御（ＭＡＣ）または物理レイヤ収束プロトコル（ＰＬＣＰ）ヘッダの１または複数を有するパケットを生成するように構成される処理ユニットであって、ＭＡＣまたはＰＬＣＰヘッダの１または複数は、フィールドを含む、処理ユニットを備える無線送信／受信ユニット（ＷＴＲＵ）。

１９．処理ユニットは、送信するためにバッファリングされたデータをＷＴＲＵが有する場合、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間または送信機会（ＴＸＯＰ）の少なくとも一方を示す情報をフィールド内に含めるようにさらに構成される実施形態１８に記載のＷＴＲＵ。

２０．無線ネットワーク内の別のＷＴＲＵにパケットを送信するように構成される送信ユニットをさらに備える実施形態１８または１９に記載のＷＴＲＵ。

２１．送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間に基づいたＴＸＯＰを有する別のパケットを他のＷＴＲＵから受信するように構成される受信ユニットをさらに備える実施形態１８乃至２０のいずれか１つに記載のＷＴＲＵ。

２２．処理ユニットは、送信するためにバッファリングされたデータをＷＴＲＵが有さない場合、０をフィールド内に含めるようにさらに構成される実施形態１８乃至２０のいずれか１つに記載のＷＴＲＵ。

２３．送信ユニットは、許可されたＴＸＯＰを使用して、少なくとも１つのパケットを送信するようにさらに構成される実施形態２０乃至２２のいずれか１つに記載のＷＴＲＵ。

２４．無線ネットワークは、無線ローカルエリアネットワーク（ＷＬＡＮ）である実施形態２０乃至２３のいずれか１つに記載のＷＴＲＵ。

２５．ＷＴＲＵは、ＷＬＡＮ内の非アクセスポイント局（非ＡＰ ＳＴＡ）である実施形態１８乃至２４のいずれか１つに記載のＷＴＲＵ。

２６．他のＷＴＲＵは、ＷＬＡＮ内のアクセスポイント（ＡＰ）である実施形態２０乃至２５のいずれか１つに記載のＷＴＲＵ。

２７．フィールドは、バッファトラフィックインジケーションフィールドである実施形態１８乃至２６のいずれか１つに記載のＷＴＲＵ。

２８．無線ネットワークにおいて無線送信／受信ユニット（ＷＴＲＵ）からパケットを受信するように構成される受信ユニットであって、パケットは、媒体アクセス制御（ＭＡＣ）または物理レイヤ収束プロトコル（ＰＬＣＰ）ヘッダの１または複数を含み、ＭＡＣまたはＰＬＣＰヘッダの１または複数は、送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間またはＴＸＯＰの少なくとも一方を示すフィールドを含む、受信ユニットを備える基地局。

２９．送信するためにＷＴＲＵがバッファリングしたデータの少なくとも１つのパケットを送信するために必要とされる時間に基づいて、ＷＴＲＵのための送信機会（ＴＸＯＰ）を生成するように構成される処理ユニットをさらに備える実施形態２８に記載の基地局。

３０．生成されたＴＸＯＰを有する別のパケットをＷＴＲＵに送信するように構成される送信ユニットをさらに備える実施形態２９に記載の基地局。

３１．基地局は、無線ネットワークのためのアクセスポイント（ＡＰ）である実施形態２８乃至３０のいずれか１つに記載の基地局。

３２．無線ネットワークは、無線ローカルエリアネットワーク（ＷＬＡＮ）である実施形態２８乃至３１のいずれか１つに記載の基地局。

３３．フレームは、フレームチェックシーケンス（ＦＣＳ）フィールドをさらに含む実施形態２８乃至３２のいずれか１つに記載の基地局。

３４．ＭＡＣヘッダは、ＦＣＳフィールドの長さの表示をさらに含み、ＦＣＳフィールドの長さは、可変である実施形態３３に記載の基地局。

３５．処理ユニットは、ＭＡＣヘッダにおいて示されたＦＣＳの長さを使用して、フレームからＦＣＳフィールドを獲得するようにさらに構成される実施形態３３または３４に記載の基地局。

３６．処理ユニットは、フレームから獲得されたＦＣＳフィールドを使用して、フレームの正しさをチェックするようにさらに構成される実施形態３５に記載の基地局。

３７．処理ユニットは、フレームは正しいと処理ユニットが決定した場合、フレームをより高位の層に中継するようにさらに構成される実施形態３６に記載の基地局。

３８．処理ユニットは、フレームは正しくないと処理ユニットが決定した場合、誤りありとしてフレームを破棄するようにさらに構成される実施形態３６または３７に記載の基地局。

３９．送信するためにＷＴＲＵがバッファリングした各パケットを送信するために必要とされる時間を示すフィールドを有する媒体アクセス制御（ＭＡＣ）ヘッダを有するパケットを生成するように構成される処理ユニットを備える無線送信／受信ユニット（ＷＴＲＵ）。

４０．無線ネットワーク内の別のＷＴＲＵにパケットを送信するように構成される送信ユニットをさらに備える実施形態３９に記載のＷＴＲＵ。

４１．送信するためにＷＴＲＵがバッファリングした各パケットを送信するために必要とされる時間に基づいた許可された送信機会（ＴＸＯＰ）を有する別のパケットを他のＷＴＲＵから受信するように構成される受信ユニットをさらに備える実施形態４０に記載のＷＴＲＵ。

上では特徴および要素が特定の組み合わせで説明されたが、各特徴または要素は、単独で使用されてもよく、または他の特徴および要素との任意の組み合わせで使用されてもよいことを当業者は理解されよう。加えて、本明細書で説明された方法は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実装されてもよい。コンピュータ可読媒体の例は、電子信号（有線または無線接続上で送信される）、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、それらに限定されない。ソフトウェアと連携するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用する無線周波送受信機を実装するために使用されてもよい。

Claims (18)

1. 無線ネットワークにおいてスモールパケットを転送する方法であって、
   局（ＳＴＡ）によって、制御フレームを生成するステップであって、前記制御フレームは、省電力（ＰＳ）ポール＋バッファトラフィック（ＢＴ）フレームまたはヌルデータパケット（ＮＤＰ）ＰＳポールフレームである、ステップと、
   前記ＳＴＡが送信に利用可能なデータを有していることを条件に、期間フィールドにおいて、またはトラフィックインジケーションを介して、マイクロ秒の推定時間を示すステップであって、前記推定時間は、少なくとも前記データの送信に必要な時間を含む、ステップと、
   前記制御フレームを送信するステップと、
   前記制御フレームと関連付けられた応答フレームを受信するステップであって、前記応答フレームは、少なくとも前記推定時間の値に設定された期間フィールド含む、ステップと
   を備えたことを特徴とする方法。
2. 前記応答フレームが前記ＮＤＰ ＰＳポールフレームと関連付けられる場合、前記応答フレームは、媒体へのアクセスを時間周期分遅延させるインジケーションを含むことを特徴とする請求項１に記載の方法。
3. アクセスを遅延させる前記インジケーションは、物理レイヤ収束プロトコル（ＰＬＣＰ）ヘッダにあることを特徴とする請求項２に記載の方法。
4. 前記ＳＴＡが送信に対するデータを有さない場合、前記のＳＴＡが前記トラフィックインジケーションを使用することを条件に、前記トラフィックインジケーションに０を含めるステップをさらに備えたことを特徴とする請求項１に記載の方法。
5. 前記応答フレームはさらに、アクセスポイント（ＡＰ）から前記ＳＴＡへの送信に対するデータのインジケーションを含むことを特徴とする請求項１に記載の方法。
6. 前記ＰＳポール＋ＢＴフレームまたは前記ＮＤＰ ＰＳポールフレームは、前記ＳＴＡがスリープ状態からウェイクアップすると生成されることを特徴とする請求項１に記載の方法。
7. 前記トラフィックインジケーションは、前記ＮＤＰ ＰＳポールフレームの物理レイヤ収束プロトコル（ＰＬＣＰ）ヘッダにあることを特徴とする請求項１に記載の方法。
8. 前記期間フィールドは、前記ＰＳポール＋ＢＴフレームの媒体アクセス制御（ＭＡＣ）ヘッダにあることを特徴とする請求項１に記載の方法。
9. 局（ＳＴＡ）であって
   制御フレームを生成し、前記制御フレームは、省電力（ＰＳ）ポール＋バッファトラフィック（ＢＴ）フレームまたはヌルデータパケット（ＮＤＰ）ＰＳポールフレームであり、および、
   前記ＳＴＡが送信に利用可能なデータを有していることを条件に、期間フィールドにおいて、またはトラフィックインジケーションを介して、マイクロ秒の推定時間を示し、前記推定時間は、少なくとも前記データの送信に必要な時間を含む
   ように少なくとも構成されたプロセッサと、
   前記制御フレームを送信するように少なくとも構成された送信機と、
   前記制御フレームと関連付けられた応答フレームを受信するように少なくとも構成された受信機であって、前記応答フレームは、少なくとも前記推定時間の値に設定された応答期間フィールドを含む、受信機と
   を備えたことを特徴とするＳＴＡ。
10. 前記応答フレームが前記ＮＤＰ ＰＳポールフレームと関連付けられる場合、前記応答フレームは、媒体へのアクセスを時間周期分遅延させるインジケーションを含むことを特徴とする請求項９に記載のＳＴＡ。
11. アクセスを遅延させる前記インジケーションは、物理レイヤ収束プロトコル（ＰＬＣＰ）ヘッダにあることを特徴とする請求項１０に記載のＳＴＡ。
12. 前記ＳＴＡが送信に対するデータを有さない場合、前記のＳＴＡが前記トラフィックインジケーションを使用することを条件に、前記プロセッサは、前記トラフィックインジケーションに０を含めるように少なくともさらに構成されていることを特徴とする請求項９に記載のＳＴＡ。
13. 前記応答フレームはさらに、アクセスポイント（ＡＰ）から前記ＳＴＡへの送信に対するデータのインジケーションを含むことを特徴とする請求項９に記載のＳＴＡ。
14. 前記ＰＳポール＋ＢＴフレームまたは前記ＮＤＰ ＰＳポールフレームは、前記ＳＴＡがスリープ状態からウェイクアップすると生成されることを特徴とする請求項９に記載のＳＴＡ。
15. 前記トラフィックインジケーションは、前記ＮＤＰ ＰＳポールフレームの物理レイヤ収束プロトコル（ＰＬＣＰ）ヘッダにあることを特徴とする請求項９に記載のＳＴＡ。
16. 前記期間フィールドは、前記ＰＳポール＋ＢＴフレームの媒体アクセス制御（ＭＡＣ）ヘッダにあることを特徴とする請求項９に記載のＳＴＡ。
17. 制御フレームを局（ＳＴＡ）から受信するように少なくとも構成されたプロセッサであって、前記制御フレームは、省電力（ＰＳ）ポール＋バッファトラフィック（ＢＴ）フレームまたはヌルデータパケット（ＮＤＰ）ＰＳポールフレームであり、前記制御フレームは、マイクロ秒の推定時間を示す期間フィールドまたはトラフィックインジケーションを含み、前記推定時間は、データの送信に必要な時間を少なくとも含む、プロセッサと、
    前記制御フレームに応答して、応答フレームを送信するように少なくとも構成された送信機であって、前記応答フレームは、少なくとも前記推定時間の値に設定された応答期間フィールドを含む、送信機と
    を備えたことを特徴とするアクセスポイント（ＡＰ）。
18. 前記応答フレームが前記ＮＤＰ ＰＳポールフレームと関連付けられる場合、前記応答フレームは、時間周期分の媒体への遅延アクセスに対するインジケーションを含むことを特徴とする請求項１７に記載のＡＰ。