JP2024511187A - Ｒｔａトラフィックとのｅｄｃａ ｔｘｏｐの共有 - Google Patents

Abstract

リアルタイムアプリケーション（ＲＴＡ）のためのフレームが共有送信機会（ＴＸＯＰｓ）を利用して送信遅延を低減することができるシングルＥＤＣＡ及び／又はマルチユーザ（ＭＵ）ＥＤＣＡを使用する無線ローカルエリアネットワーク（ＷＬＡＮ）のための通信回路とプロトコル。このプロトコルは、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために最低限必要なチャネルリソースを保証することなどによって通信公平性を保証するように多くの方法で構成される。ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤもサポートされ、これらは、どのリンクを使用してトラフィックストリームを送信すべきであるかを決定する際に、このトラフィックストリームを、同じトラフィック識別子（ＴＩＤ）を有する他のトラフィックストリームと区別することに関する情報を交換することができる。【選択図】 図２９

Description

〔関連出願との相互参照〕
本出願は、２０２１年３月３１日に出願された米国仮特許出願シリアル番号第６３／１６８，４３４号に対する優先権及びその利益を主張するものであり、この文献は全体が引用により本明細書に組み入れられる。

〔連邦政府が支援する研究又は開発に関する記述〕
該当なし

〔著作権保護を受ける資料の通知〕
本特許文献中の資料の一部は、アメリカ合衆国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、合衆国特許商標庁の一般公開ファイル又は記録内に表される通りに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定ではないが米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておく権利のいずれも本明細書によって放棄するものではない。

本開示の技術は、一般に複数のアクセスカテゴリ（ＡＣ）を定める拡張分散チャネルアクセス（ＥＤＣＡ）を使用する無線ネットワーク通信に関し、具体的には、リアルタイムアプリケーション（ＲＴＡ）パケット送信が送信機会（ＴＸＯＰ）共有を利用して遅延時間を低減できるようにすることに関する。

ＣＳＭＡ／ＣＡを使用する現在の無線８０２．１１技術は、ネットワークの高スループット性能には重点を置いているが、ＲＴＡフレームを送信するリアルタイムアプリケーション（ＲＴＡ）が必要とするような低遅延トラフィックを十分にサポートしていない。各ＲＴＡフレームは、一定時間内に配信された場合にのみ有効であるという高適時性要件に起因して低遅延を必要とする。また、ＲＴＡトラフィックでは、複数のアクセスカテゴリ（ＡＣ）を定める拡張分散チャネルアクセス（ＥＤＣＡ）を使用する際に問題が発生する。

従って、ＥＤＣＡを使用する際にＴＸＯＰのＲＴＡトラフィック共有処理を強化することに対するニーズが存在する。本開示は、このニーズを満たすとともにさらなる利点を提供するものである。

拡張分散チャネルアクセス（ＥＤＣＡ）を使用する現在の無線通信システムはＲＴＡパケットを非ＲＴＡパケットと区別せず、従ってＥＤＣＡ下では全てのパケットが同じＴＸＯＰ共有ルールを使用する。本開示は、遅延時間を低減するために、ＥＤＣＡ送信機会（ＴＸＯＰ）共有を利用する際のＲＴＡパケット送信の柔軟性を高めるように構成される。開示するプロトコルは、（ａ）プライマリＡＣからの未送信フレームが存在する時に、ＳＴＡがＲＴＡフレームを送信するためにプライマリＡＣのＴＸＯＰを共有できること、及び（ｂ）プライマリＡＣのフレームの送信と非プライマリＡＣからのＲＴＡフレームの送信との間の公平性（一様性、平等性）を考慮すること、といった主な利点をもたらす。

本明細書の以下の部分では、本明細書で説明する技術のさらなる態様が明らかになり、この詳細な説明は、本技術の好ましい実施形態を限定することなく完全に開示するためのものである。

本明細書で説明する技術は、例示のみを目的とする以下の図面を参照することによって十分に理解されるであろう。

ＩＥＥＥ８０２．１１で定められるＴＳＰＥＣ要素コンテンツのデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるＴＳ情報要素のデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ要素のデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ処理要素のデータフィールド図である。 ＩＥＥＥ８０２．１１で定められる、ダウンリンクマルチユーザ送信に使用されるＨＥマルチユーザ（ＭＵ）ＰＰＤＵフォーマットのデータフィールド図である。 ＩＥＥＥ８０２．１１で定められる、アップリンクマルチユーザ送信に使用されるＨＥトリガベース（ＴＢ）ＰＰＤＵフォーマットのデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるトリガーフレーム（ＴＦ）のデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるＴＦの共通情報フィールドのデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるトリガフレーム（ＴＦ）のユーザ情報フィールドのデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるＭＵ－ＢＡＲのトリガフレーム（ＴＦ）のトリガ依存ユーザ情報フィールドのデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるブロックＡＣＫ（ＢＡ）フレームのデータフィールド図である。 ＩＥＥＥ８０２．１１で定められるバッファ状態要求（ＢＳＲ）フレームのデータフィールド図である。 ＩＥＥＥ８０２．１１で利用される、ＯＦＤＭＡを使用するダウンリンクマルチユーザ送信の通信図である。 ＩＥＥＥ８０２．１１で定められる、直交周波数分割多重アクセス（ＯＦＤＭＡ）を利用するアップリンクマルチユーザ送信の通信図である。 ＩＥＥＥ８０２．１１で定められる、直交周波数分割多重アクセス（ＯＦＤＭＡ）を利用するアップリンクマルチユーザ送信の通信図である。 ＩＥＥＥ８０２．１１で定められる、（拡張型ＤＣＦチャネルアクセス）ＥＤＣＡの参照モデルの送信キュー図である。 ＩＥＥＥ８０２．１１で定められるＥＤＣＡのチャネルアクセス手順を実行する通信図である。 本開示の少なくとも１つの実施形態による無線局ハードウェアのハードウェアブロック図である。 本開示の少なくとも１つの実施形態による、マルチリンク装置ハードウェアなどに含まれる局構成のハードウェアブロック図である。 本開示の少なくとも１つの実施例による、７つのＳＴＡを有し、そのうちの６つが３つのＭＬＤ内に存在するＷＬＡＮのトポロジーである。 本開示の少なくとも１つの実施例による、ＬＬＴＳを終了又は修正する通信図である。 本開示の少なくとも１つの実施例によるＬＬＴＳ要求フレームのデータフィールド図である。 本開示の少なくとも１つの実施例によるＬＬＴＳ記述子フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施例によるＲＴＡ－ＴＳＰＥＣフィールドコンテンツのデータフィールド図である。 本開示の少なくとも１つの実施例による、上位層ストリームＩＤを搬送する任意のサブ要素のデータフィールド図である。 本開示の少なくとも１つの実施例による、ＬＬＴＳ／ＴＩＤ対リンクマッピングを搬送する任意のサブ要素のデータフィールド図である。 本開示の少なくとも１つの実施例によるＬＬＴＳ応答フレームのデータフィールド図である。 本開示の少なくとも１つの実施例によるＬＬＴＳ状態フィールドのデータフィールド図である。 本開示の少なくとも１つの実施例による、ＲＴＡトラフィックと非ＲＴＡトラフィックとを区別するフロー図である。 本開示の少なくとも１つの実施例による、非プライマリＡＣワークからのＲＴＡトラフィックを送信するＴＸＯＰ共有のフロー図である。 本開示の少なくとも１つの実施例によるＡＰ１又はＭＬＤ１のＥＤＣＡキューの送信キュー図である。 本開示の少なくとも１つの実施例による、ＡＰ１がＴＸＯＰ中にのみ非プライマリＡＣからのＲＴＡフレームを送信する通信図である。 本開示の少なくとも１つの実施例によるＡＰ１又はＭＬＤ１の別のＥＤＣＡキュー状態の送信キュー図である。 本開示の少なくとも１つの実施例による、ＡＰ１がＴＸＯＰ中にプライマリＡＣからのフレームよりも前に優先度の高い非プライマリＡＣからのＲＴＡフレームを送信する通信図である。 本開示の少なくとも１つの実施例による、ＴＸＯＰ中にＡＰ１が最初にプライマリＡＣからのＲＴＡフレームを送信し、次に非プライマリＡＣからのＲＴＡフレームを送信し、その後にプライマリＡＣからの非ＲＴＡフレームを送信する通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１がプライマリＡＣよりも優先度の低い非プライマリＡＣからのＲＴＡフレームを送信する通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態の第３の実施例の送信キュー図である。 本開示の少なくとも１つの実施例による、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、非プライマリＡＣからのＲＴＡフレームの送信要求によってＭＵ ＰＰＤＵの期間が決定される通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、プライマリＡＣからのＲＴＡフレームの遅延要件によってＭＵ ＰＰＤＵの期間が決定される通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、プライマリＡＣからのＲＴＡフレームの遅延要件によってＭＵ ＰＰＤＵの期間が決定される別の例を示す通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、プライマリＡＣからのＲＴＡフレームの送信要件によってＭＵ ＰＰＤＵの期間が決定される通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１がＴＸＯＰ共有の時間を制限する通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１がプライマリＡＣからのフレームを一定数送信した後にＴＸＯＰを共有する通信図である。 本開示の少なくとも１つの実施例による、ＡＰ１がプライマリＡＣからのフレームを一定時間にわたって送信した後にＴＸＯＰを共有する通信図である。 本開示の少なくとも１つの実施例による、専用時間パラメータ設定を搬送するフレームのデータフィールド図である。 本開示の少なくとも１つの実施例による、ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態の第４の実施例の送信キュー図である。 本開示の少なくとも１つの実施例による、ＡＰ１がＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、各ユーザについて非プライマリＡＣからのＲＴＡフレームがプライマリＡＣからのフレームよりも早く送信される通信図である。 本開示の少なくとも１つの実施例による、ＭＵ ＰＰＤＵにおいてＡＰが非プライマリＡＣからのＲＴＡフレームをプライマリＡＣからのＲＴＡフレームよりも遅く、ただし各ユーザについてプライマリＡＣからの非ＲＴＡフレームよりも早く送信する際のＴＸＯＰ共有の通信図である。

１．序文
リアルタイムアプリケーション（ＲＴＡ）は低遅延を必要とし、ベストエフォート通信を使用する。ＲＴＡから発生するデータはＲＴＡトラフィックと呼ばれ、送信側の局（ＳＴＡ）においてＲＴＡフレームとしてパケット化される。また、本明細書では非時間依存アプリケーションから発生するデータを非ＲＴＡトラフィックと呼び、これらは、フレームを搬送するパケットをチャネル（リンク）を介して受信側ＳＴＡに転送する送信側ＳＴＡにおいて非ＲＴＡフレームとしてパケット化される。

ＲＴＡトラフィックは、ＥＤＣＡキューに到着するとフレーム単位でカプセル化される。ＲＴＡトラフィックを搬送するフレームはＲＴＡフレームによって表され、非ＲＴＡトラフィックを搬送するフレームは非ＲＴＡフレームによって表される。１つのパケットには１又は２以上のフレームを含めてリンク又はチャネルを介して送信することができる。ＥＤＣＡ ＴＸＯＰを獲得したＥＤＣＡＦに関連するＡＣはプライマリＡＣと呼ばれる。

ＲＴＡフレームは、一定時間内に配信された場合にのみ有効であるため、配信に対する高適時性要件に起因して低遅延を必要とする。ＣＳＭＡ／ＣＡ無線技術における１つの解決策は、例えばＲＴＡフレームの送信に高優先度ＡＣなどを使用して、ＳＴＡがＲＴＡフレームを送信する機会を増やすことである。

ＳＴＡは、ランダムチャネルアクセスシナリオに起因して、各フレームの送信前にチャネルを検知し、チャネルアクセス権を求めて競合する必要がある。ＥＤＣＡでは、ＳＴＡは、高優先度ＡＣの短いチャネル競合時間を使用してチャネルアクセスを加速させることができる。しかしながら、低優先度ＡＣの方が高優先度ＡＣよりも早くチャネルにアクセスする可能性もある。高優先度ＡＣからのＲＴＡフレーム送信遅延の原因は、低優先度ＡＣによって取得されるＴＸＯＰ時間にある。

ＳＴＡは、低優先度ＡＣによって取得されたＴＸＯＰ時間に起因する遅延を回避するために、低優先度ＡＣによって取得されたＴＸＯＰ時間を使用してＲＴＡフレームを送信することができる。非プライマリＡＣからのフレームを送信するためにプライマリＡＣのＴＸＯＰを共有するタスクは、ＲＴＡトラフィックと非ＲＴＡトラフィックとの共存に起因して困難である。このプロセスの課題は、（ａ）ＲＴＡトラフィックと非ＲＴＡトラフィックとを区別し、プライマリＡＣからの未送信パケットが存在する際にプライマリＡＣのＴＸＯＰを共有して非プライマリＡＣからのＲＴＡパケットを送信すること、として要約することができる。

２．現在の８０２．１１動作
２．１．ＴＳＰＥＣ要素
図１に、ＩＥＥＥ８０２．１１で定められるＴＳＰＥＣ要素の内容を示しており、これらは以下のフィールドを有する。要素（Ｅｌｅｍｅｎｔ）ＩＤは要素のタイプを示し、この事例ではＴＳＰＥＣ要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドは、ＴＳＰＥＣ要素の長さを示す。ＴＳ情報（ＴＳ Ｉｎｆｏ）フィールドはトラフィックストリーム情報を示し、図２に示すサブフィールドを有する。公称ＭＳＤＵサイズ（Ｎｏｍｉｎａｌ ＭＳＤＵ Ｓｉｚｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵの公称サイズを示す。最大ＭＳＤＵサイズ（Ｍａｘｉｍｕｍ ＭＳＤＵ Ｓｉｚｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵの最大サイズを示す。最小サービス間隔（Ｍｉｎｉｍｕｍ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｖａｌ）フィールドは、連続する２つのサービス期間（ＳＰ）の開始時間の間の最小時間を示す。最大サービス間隔（Ｍａｘｉｍｕｍ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｖａｌ）フィールドは、連続する２つのＳＰの開始時間の間の最大時間を示す。非作動間隔（Ｉｎａｃｔｉｖｉｔｙ Ｉｎｔｅｒｖａｌ）フィールドは、ＴＳの削除前にそのＴＳに属するＭＳＤＵの到着又は送信がない時間間隔を示す。停止間隔（Ｓｕｓｐｅｎｓｉｏｎ Ｉｎｔｅｒｖａｌ）フィールドは、ＴＳのＱｏＳ（＋）ＣＦ－Ｐｏｌｌの生成の停止前にそのＴＳに属するＭＳＤＵの到着又は送信がない期間を示す。

サービス開始時刻（Ｓｅｒｖｉｃｅ Ｓｔａｒｔ Ｔｉｍｅ）フィールドは、最初のＳＰの開始時刻を含む。最小データレート（Ｍｉｎｉｍｕｍ Ｄａｔａ Ｒａｔｅ）フィールドは、ＭＡＣ ＳＡＰによって指定された、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための最低データレートを示す。平均データレート（Ｍｅａｎ Ｄａｔａ Ｒａｔｅ）フィールドは、ＭＡＣ ＳＡＰによって指定された、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための平均データレートを示す。ピークデータレート（Ｐｅａｋ Ｄａｔａ Ｒａｔｅ）フィールドは、ＭＡＣ ＳＡＰによって指定された、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための最大データレートを示す。バーストサイズ（Ｂｕｒｓｔ Ｓｉｚｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵのピークデータレートでの最大バーストを示す。遅延限界（Ｄｅｌａｙ Ｂｏｕｎｄ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するために許容される最大時間を示す。最小ＰＨＹレート（Ｍｉｎｉｍｕｍ ＰＨＹ Ｒａｔｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための最小ＰＨＹレートを示す。余剰帯域幅許可（Ｓｕｒｐｌｕｓ Ｂａｎｄｗｉｄｔｈ Ａｌｌｏｗａｎｃｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵの送信及びその再送に使用される帯域と、このＭＳＤＵ又はＡ－ＭＳＤＵを最小ＰＨＹレートで１度送信するために使用される帯域との比率を示す。媒体時間（Ｍｅｄｉｕｍ Ｔｉｍｅ）フィールドは、媒体にアクセスするために認められる時間を示す。ＤＭＧ属性（ＤＭＧ Ａｔｔｒｉｂｕｔｅｓ）フィールドは、ＴＳＰＥＣが指向性マルチギガビット（ＤＭＧ）ＢＳＳに適用される際に提示される。

図２に、ＩＥＥＥ８０２．１１で定められるＴＳ情報フィールドの内容を示す。トラフィックタイプ（Ｔｒａｆｆｉｃ Ｔｙｐｅ）フィールドは、トラフィックが周期的であるか否かを指定する。ＴＳＩＤフィールドは、ＴＳを識別するためのＩＤ番号を示す。方向（Ｄｉｒｅｃｔｉｏｎ）フィールドは、データ送信の方向を指定する。アクセスポリシー（Ａｃｃｅｓｓ Ｐｏｌｉｃｙ）フィールドは、チャネルアクセス権を獲得する方法を指定する。アグリゲーション（Ａｇｇｒｅｇａｔｉｏｎ）フィールドは、アグリゲーションスケジュールが必要であるかどうかを指定する。ＡＰＳＤフィールドは、自動ＰＳ配信が使用されるかどうかを示す。ユーザ優先度（Ｕｓｅｒ Ｐｒｉｏｒｉｔｙ）フィールドは、ＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵのユーザ優先度を示す。ＴＳＩｎｆｏ ＡＣＫポリシー（ＴＳＩｎｆｏ Ａｃｋ Ｐｏｌｉｃｙ）フィールドは、Ａｃｋが必要であるかどうか、及びどの形態のＡＣＫを使用すべきであるかを示す。スケジュール（Ｓｃｈｅｄｕｌｅ）フィールドは、スケジュールのタイプを示す。

２．２．ＴＣＬＡＳ要素
図３に、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＣＬＡＳ要素である。長さ（Ｌｅｎｇｔｈ）フィールドはＴＳＰＥＣ要素の長さを示す。ユーザ優先度（Ｕｓｅｒ Ｐｒｉｏｒｉｔｙ）フィールドは上位層からのユーザ優先度を示す。フレーム分類器（Ｆｒａｍｅ Ｃｌａｓｓｉｆｉｅｒ）フィールドは、上位層からのフレームを分類する方法を示す。

２．３．ＴＣＬＡＳプロセス要素
図４に、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ処理要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＣＬＡＳ処理要素である。長さ（Ｌｅｎｇｔｈ）フィールドはＴＣＬＡＳ処理要素の長さを示す。処理（Ｐｒｏｃｅｓｓｉｎｇ）フィールドは、複数のＴＣＬＡＳ要素が存在する場合に上位層からのトラフィックを分類する方法を示す。

２．４．マルチユーザ送信
ＩＥＥＥ８０２．１１などの無線ネットワークでは、マルチユーザ送信が利用可能である。ＩＥＥＥ８０２．１１ａｘ以降、ネットワークは、アップリンク及びダウンリンクの両方でマルチユーザ送信をサポートすることができる。ＩＥＥＥ８０２．１１ａｘのマルチユーザ送信はＭＩＭＯモード及びＯＦＤＭＡモードを含み、これらは単独で又は合わせて利用することができる。

ＩＥＥＥ８０２．１１ａｘでは、図５及び図６に示すようなマルチユーザ送信パケットフォーマットを使用してマルチユーザモードでデータを送信する。複数のユーザがマルチユーザ送信パケットを送信又は受信する際には、全てのユーザがマルチユーザ送信パケットの同じＰＬＣＰヘッダを共有する。その後、各ユーザは、ＲＵ割り当て及びＭＣＳなどを含む個別リソースブロックを使用して、マルチユーザ送信パケットによって搬送されるデータを送信又は受信する。

ＩＥＥＥ８０２．１１ａｘは、異なるマルチユーザ送信においてパケットを送信するために複数のＰＬＣＰプロトコルデータユニット（ＰＰＤＵ）フォーマットを規定しており、これについては後述する。なお、ＰＬＣＰは、ＰＨＹ層集束プロトコル（ＰＨＹ Ｌａｙｅｒ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）の頭文字である。

図５に、ＩＥＥＥ８０２．１１ａｘにおいてダウンリンクマルチユーザ送信に使用されるＨＥマルチユーザ（ＭＵ）ＰＰＤＵフォーマットを示す。これらのフィールドを、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、ＨＥ－ＳＩＧ－Ａ、ＨＥ－ＳＩＧ－Ｂ、ＨＥ－ＳＴＦ、ＨＥ－ＬＴＦ、データ（Ｄａｔａ）及びＰＥとして示す。

図６に、ＩＥＥＥ８０２．１１ａｘにおいてアップリンクマルチユーザ送信に使用されるＨＥトリガーベース（ＴＢ）ＰＰＤＵフォーマットを示す。ＨＥ ＴＢ ＰＰＤＵフォーマットのフィールドは、ＨＥ－ＳＴＦフィールドが８μｓであることを除いてＨＥシングルユーザＰＰＤＵフォーマットのフィールドと同一である。これらのフィールドを、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、ＨＥ－ＳＩＧ－Ａ、ＨＥ－ＳＴＦ、ＨＥ－ＬＴＦｓ、データ（Ｄａｔａ）及びＰＥとして示す。

図７に、トリガーフレーム（ＴＦ）の内容を示す。フレーム制御（ｆｒａｍｅ ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。期間（ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。共通情報（Ｃｏｍｍｏｎ Ｉｎｆｏ）フィールドは、以下の図８に示す全ての割り当てられたＳＴＡのための情報を含む。ユーザ情報（Ｕｓｅｒ Ｉｎｆｏ）フィールドは、図９に示す各ＳＴＡの情報を含む。共通情報フィールド及びユーザ情報フィールドは、各ユーザに個別リソースブロック割り当て情報を提供する。

図８に、図７に示すトリガフレームの共通情報フィールドを示す。共通情報フィールドのサブフィールドを、トリガタイプ（Ｔｒｉｇｇｅｒ Ｔｙｐｅ）、長さ（Ｌｅｎｇｔｈ）、カスケーディング指示（Ｃａｓｃａｄｉｎｇ Ｉｎｄｉｃａｔｉｏｎ）、必要ＣＳ（ＣＳ Ｒｅｑｕｉｒｅｄ）、ＢＷ、ＧＩ及びＬＴＦタイプ（ＧＩ ａｎｄ ＬＴＦ Ｔｙｐｅ）、ＭＵ ＭＩＭＯ ＬＴＦモード（ＭＵ ＭＩＭＯ ＬＴＦ Ｍｏｄｅ）、ＨＥ－ＬＴＦシンボル数（Ｎｕｍｂｅｒ ｏｆ ＨＥ－ＬＴＦ Ｓｙｍｂｏｌｓ）、ＬＤＰＣ追加シンボルセグメント（ＳＴＢＣ、ＬＤＰＣ Ｅｘｔｒａ Ｓｙｍｂｏｌ Ｓｅｇｍｅｎｔ）、ＡＰ ＴＸ電力（ＡＰ ＴＸ Ｐｏｗｅｒ）、パケット拡張（Ｐａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎ）、空間再使用（Ｓｐａｔｉａｌ Ｒｅｕｓｅ）、ドップラー（Ｄｏｐｐｌｅｒ）、ＧＩ及びＬＴＦタイプ、ＨＥ－ＳＩＧ－Ａ予約（ＨＥ－ＳＩＧ－Ａ Ｒｅｓｅｒｖｅｄ）、予備（Ｒｅｓｅｒｖｅｄ）、及びトリガー依存共通情報（Ｔｒｉｇｇｅｒ Ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏ）として示す。

図９に、図７に示すトリガフレームのユーザ情報フィールドを示しており、このフィールドは以下のサブフィールドを有する。これらは、ＡＩＤ１２、ＲＵ割り当て（ＲＵ Ａｌｌｏｃａｔｉｏｎ）、コーディングタイプ（Ｃｏｄｉｎｇ Ｔｙｐｅ）、ＭＣＳ、ＤＣＭ、ＳＳ割り当て（ＳＳ Ａｌｌｏｃａｔｉｏｎ）、ターゲットＲＳＳＩ（Ｔａｒｇｅｔ ＲＳＳＩ）、予備（Ｒｅｓｅｒｖｅｄ）、及びトリガー依存共通情報（Ｔｒｉｇｇｅｒ Ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏ）である。

図７に示すトリガフレームは、共通情報フィールドのトリガタイプを「２」に設定することによってマルチユーザブロックＡＣＫ要求（ＭＵ－ＢＡＲ）として送信することができる。トリガフレームがＭＵ－ＢＡＲである場合、トリガフレーム内の（図９に図示す）トリガ依存型ユーザ情報フィールドの内容は図１０に示す通りである。

図１０に、ＭＵ－ＢＡＲの場合のトリガフレーム内のトリガ依存ユーザ情報フィールドを示しており、サブフィールドＢＡＲ制御及びＢＡＲ情報を示す。

図１１に、以下のサブフィールドを有するブロックＡＣＫ（ＢＡ）フレームの内容を示す。フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。期間（Ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。ＢＡ制御（ＢＡ Ｃｏｎｔｒｏｌ）フィールドは、ブロックＡＣＫのポリシーを示す。ＢＡ情報（ＢＡ ｉｎｆｏ）フィールドは、送信のフィードバックを含む。

図１２に、以下のフィールドを有するバッファ状態要求（ＢＳＲ）フレームの内容を示す。フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。期間（Ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。ＨＴ制御（ＨＴ Ｃｏｎｔｒｏｌ）フィールドは、ＢＳＲ制御サブフィールドの変種を示す。フォーマット指示（Ｆｏｒｍａｔ Ｉｎｄｉｃａｔｉｏｎ）フィールドは、ＨＴ制御フィールドのフォーマットを示すために使用される。Ｂ０及びＢ１が第１の状態（例えば、「１」）に設定された場合には、ＨＴ制御フィールドがＨＥフォーマットを使用することを示す。このフィールドの後にはＡ－制御（Ａ－Ｃｏｎｔｒｏｌ）フィールドが存在する。Ａ－制御フィールドは、バッファ状態レポートを搬送する。制御ＩＤ（Ｃｏｎｔｒｏｌ ＩＤ）フィールドは、ＢＳＲが制御情報フィールド内で搬送されることを示す。制御情報（Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）フィールドは、ＢＳＲ制御サブフィールドの変種を搬送する。ＡＣＩビットマップ（ACI Bitmap）フィールドは、バッファ状態が報告されるアクセスカテゴリを示す。デルタＴＩＤ（Delta TID）フィールドは、バッファ状態が報告されるＴＩＤの数を示す。ＡＣＩ高（ＡＣＩ Ｈｉｇｈ）フィールドは、キューサイズ高フィールドで報告されるアクセスカテゴリを示す。スケーリングファクタ（Ｓｃａｌｉｎｇ Ｆａｃｔｏｒ）フィールドは、キューサイズ高フィールド及びキューサイズ全フィールドの単位を示す。キューサイズ高（Ｑｕｅｕｅ Ｓｉｚｅ Ｈｉｇｈ）フィールドは、ＡＣＩ高に示されるＡＣのキューサイズをスケーリングファクタの単位で示す。キューサイズ全（Ｑｕｅｕｅ Ｓｉｚｅ Ａｌｌ）フィールドは、ＡＣＩビットマップに示されるＡＣのキューサイズを示し、やはりスケーリングファクタの単位である。

図１３に、ＯＦＤＭＡを使用するダウンリンクマルチユーザ送信の例を示す。送信側ＡＰは、ＨＥ ＭＵ ＰＰＤＵフォーマットを使用してその受信側１、２、３及び４にデータパケットを送信する。ＡＰは、最初の送信を終えた後に、全ての受信側にマルチユーザブロックＡＣＫ要求（ＭＵ－ＢＡＲ）を送信する。その後、受信側はそれぞれＡＰにブロックＡＣＫ（ＢＡ）を返送する。ＡＰは、ＢＡの内容に従って、受信側１、３及び４にパケットを再送すると決定する。ＡＰはチャネルを求めて競合し、所与のバックオフ時間を待機する。ＡＰがチャネルアクセス権を獲得した後に最初の再送が行われる。

図１４Ａ及び図１４Ｂに、ＯＦＤＭＡを使用するアップリンクマルチユーザ送信の例を示す。ＡＰは、最初に全ての送信側１、２、３及び４にバッファ状態レポート要求（ＢＳＲＰ）トリガフレームを送信する。次に、送信側はＢＳＲＰトリガーフレームを受け取り、ＡＰにバッファ状態レポート（ＢＳＲ）を返送する。その後、ＡＰは全ての送信側１、２、３及び４にトリガーフレームを送信する。トリガーフレームでは、ＳＴＡから受け取られたＢＳＲに基づいてチャネルリソースが割り当てられる。送信側はトリガフレームを受け取り、トリガフレームによって割り当てられたリソースブロックを使用して最初の送信を開始する。マルチユーザ送信パケットは、ＨＥ－ＴＢ ＰＰＤＵフォーマットを使用する。ＡＰは送信側からパケットを受け取り、ＢＡフレームを送信して送信が正しく受け取られたかどうかを報告する。

２．５．ＥＤＣＡシステム
図１５に、ＩＥＥＥ８０２．１１における（拡張型ＤＣＦチャネルアクセス）ＥＤＣＡキューの参照モデルを示す。このシステムは、６つの送信キュー及び４つのアクセスカテゴリ（ＡＣ）を含む。各ＡＣは、その対応する送信キュー内のパケットを送信できるように、ＥＤＣＡ機能（ＥＤＣＡＦ）を使用してチャネルアクセス権を求めて競合する。ボイス（ＶＯ）、代替ボイス（Ａ＿ＶＯ）、代替ビデオ（Ａ＿ＶＩ）、ビデオ（ＶＩ）、ベストエフォート（ＢＥ）バックグラウンド（ＢＫ）としての６つの送信キューを示す。各送信キューは、キュー内のパケットの送信順を決定する。

図示の４つのＡＣは、ボイス（ＶＯ）、ビデオ（ＶＩ）、ベストエフォート（ＢＥ）及びバックグラウンド（ＢＫ）である。各ＡＣは、チャネル競合の機能を提供するＥＤＣＡ機能（ＥＤＣＡＦ）を有する。複数のＥＤＣＡＦが同時にチャネルにアクセスしようと試みる際には、内部衝突回避機構が使用される。内部衝突が発生した場合には、より高い優先度のＥＤＣＡＦがチャネルアクセス権を獲得する。

表１に、ＩＥＥＥ８０２．１１のＥＤＣＡキューにおいて使用されるＵＰ－ＡＣマッピングをリストする。２列目及び３列目は、トラフィックのユーザ優先度及びその対応するＩＥＥＥ８０２．１Ｄでの指定を表す。各行では、ユーザ優先度に従って、トラフィックが対応する送信キュー及びアクセスカテゴリに加えられる。優先度は、最上行から最下行に向かって高くなる。優先度の高いトラフィックほど早く送信される確率が高い。

図１６に、ＥＤＣＡのチャネルアクセス手順の実行を示す。図示のように、分散協調機能（ＤＣＦ）のみを使用する場合のＥＤＣＡチャネルアクセスも比較している。

ＤＣＦのみを使用する場合、ＳＴＡは直ちにチャネルにアクセスすることができ、媒体はＤＣＦフレーム間隔（ＤＩＦＳ）よりも長く空いている。そうでなければ、ＳＴＡは、ＣＳＭＡ／ＣＡを使用してチャネルを求めて競合する。ＳＴＡは、ＤＩＦＳ時間にわたってチャネルがアイドルであることを感知した後に、媒体がアイドルである限りバックオフをカウントダウンし始める。バックオフスロットの数は、ゼロとコンテンションウィンドウとの間でランダムに選択される。ＳＴＡは、ＣＣＡビジーが発生し、例えばチャネルがビジーであることを感知すると、バックオフのカウントダウンを一時停止する。バックオフがゼロまでカウントダウンすると、ＳＴＡはパケットを送信し始めることができる。

ＥＤＣＡでは、媒体がＡＣの仲裁的フレーム送信間隔（ＡＩＦＳ）時間よりも長く空いている場合、図１５に示すような各ＥＤＣＡＦが、チャネルアクセス権を獲得するために直ちにチャネルにアクセスすることができる。なお、図示のＡＩＦＳ［ｉ］は、所与のＡＣを表すＡＣ ｉのＡＩＦＳ時間を表す。そうでなければ、各ＥＤＣＡＦはＣＳＭＡ／ＣＡを使用して、チャネルアクセス権を獲得しようと試みている各ＡＣのためのチャネルアクセス権を求めて競合する。ＳＴＡは、ＡＩＦＳ時間にわたってチャネルがアイドルであることを感知した後に、媒体がアイドルである限りバックオフをカウントダウンし始める。バックオフスロットの数は、ゼロとコンテンションウィンドウサイズとの間でランダムに選択される。ＳＴＡは、ＣＣＡビジーが発生し、例えばチャネルビジーを感知すると、バックオフのカウントダウンを一時停止する。ＳＴＡは、バックオフがゼロまでカウントダウンすると、そのＡＣのパケット送信を開始する。なお、複数のＥＤＣＡＦが同時にチャネルを求めて競合することもできる。例えば、図１６に示すように、（いずれかの２つのＡＣを表す）ＡＣ ｉ及びＡＣ ｊのＥＤＣＡＦは同時にチャネルを求めて競合することができる。

内部衝突が発生すると、優先度の高いＥＤＣＡＦがチャネルアクセス権を獲得し、優先度の低いＥＤＣＡＦはそのコンテンションウィンドウを２倍にする。ＡＣは、ＶＯ又はＶＩである場合には、パケットを送信するためにＴＸＯＰなどの非競合期間を予約することができる。ＴＸＯＰの最大継続時間はＴＸＯＰ制限と呼ばれる。

表２に、ＥＤＣＡチャネルアクセスのためのデフォルトパラメータ設定を示す。各ＡＣは、独自の最小コンテンションウィンドウ及び最大コンテンションウィンドウを有する。ＡＩＦＳＮは、ＡＩＦＳ期間をバックオフスロット数の観点から表す。ＴＸＯＰ制限は、各ＡＣが毎回予約できるＴＸＯＰの最大期間を表す。

２．６．ＩＥＥＥ８０２．１１ａｘにおけるＴＸＯＰの共有。
ＳＴＡは、プライマリＡＣからの全てのフレームが送信された場合、又はＳＴＡがＭＵ ＰＰＤＵを送信する場合にのみ、非プライマリＡＣからのＲＴＡフレームを送信するためにＴＸＯＰを共有することができる。ＴＸＶＥＣＴＯＲパラメータＮＵＭ＿ＵＳＥＲＳが１よりも大きなＭＵ ＤＬ ＭＩＭＯ ＰＰＤＵ（ＶＨＴ ＭＵ ＰＰＤＵ）に優先度の低い非プライマリＡＣからのフレームが含まれている場合、これらのフレームは、プライマリＡＣのフレーム及び優先度の高いＡＣからのいずれかのフレームの送信に必要な期間を越えてＰＰＤＵの期間を増加させない。より優先度の高い又は低い非プライマリＡＣからのフレームがＡＰによってＨＥ ＭＵ ＰＰＤＵに含められている場合、これらのフレームは、プライマリＡＣのフレーム及び優先度の高いＡＣからのいずれかのフレームの送信に必要な期間を越えてＨＥ ＭＵ ＰＰＤＵの期間を増加させない。ＶＨＴ／ＨＥ ＭＵ ＰＰＤＵ内の所与のユーザについては、プライマリＡＣからのいずれかのフレームが最初に送信され、その後に次に優先度の高いＡＣからのいずれかのフレームが送信されなければならない。

３．課題の記述
ＥＤＣＡを使用する現在の無線通信システムはＲＴＡフレームと非ＲＴＡフレームとを識別せず、全てのパケットが同じＴＸＯＰ共有ルールを使用する。本開示は、遅延時間を低減するために、ＲＴＡパケットに特定のＴＸＯＰ共有機構を使用する柔軟性をＳＴＡに提供する機構について説明する。

４．本開示の寄与
本開示を利用することにより、ＳＴＡは、プライマリＡＣからのフレームが送信されていない時に、プライマリＡＣのＴＸＯＰを共有してＲＴＡフレームを送信することができる。少なくとも１つの好ましい実施形態では、開示するプロトコルが、プライマリＡＣのフレームの送信と非プライマリＡＣからのＲＴＡフレームの送信との間の「公平性」（公平なチャネル使用）を考慮する。

５．実施形態
５．１．ＳＴＡ及びＭＬＤハードウェア構成
図１７に、本開示のプロトコルを実行するように構成されたＳＴＡハードウェアの実施形態例１０を示す。外部Ｉ／Ｏ接続１４が内部バス１６に結合し、内部バス１６上には、通信プロトコルを実装する（単複の）プログラムを実行するためにＣＰＵ１８及びメモリ（例えば、ＲＡＭ）２０が接続されることが好ましい。ホストマシンは、１又は複数のアンテナ２９、２６ａ、２６ｂ、２６ｃ～２６ｎにそれぞれが接続された少なくとも１つのＲＦモジュール２４、２８に結合された、通信をサポートする少なくとも１つのモデム２２を収容する。複数のアンテナ（例えば、アンテナアレイ）を有するＲＦモジュールは、送信及び受信中にビームフォーミングを実行することを可能にする。このように、ＳＴＡは、複数組のビームパターンを使用して信号を送信することができる。

バス１４は、センサ及びアクチュエータなどの様々な装置をＣＰＵに接続することができる。プロセッサ１８上では、ＳＴＡがアクセスポイント（ＡＰ）局又は通常の局（非ＡＰ ＳＴＡ）の機能を実行することを可能にするように実行される通信プロトコルを実装するプログラムを実行するための、メモリ２０からの命令が実行される。また、このプログラミングは、現在の通信状況でどのような役割を果たしているかに応じて異なるモード（ＴＸＯＰ所有者、ＴＸＯＰ共有参加者、ソース、中間、宛先、第１のＡＰ、他のＡＰ、第１のＡＰに関連する局、他のＡＰに関連する局、調整機（ｃｏｏｒｄｉｎａｔｏｒ）、被調整機（ｃｏｏｒｄｉｎａｔｅｅ）など）で動作するように構成されると理解されたい。従って、図示のＳＴＡ ＨＷは、少なくとも１つのモデムと、サブ６ＧＨｚ帯及び／又はｍｍＷ帯などの少なくとも１つの帯域上での通信を提供するための関連するＲＦ回路とを使用して構成される。

また、図示のような局ハードウェアの複数のインスタンスはマルチリンク装置（ＭＬＤ）に組み合わせることができ、通常、このＭＬＤは活動を協調させるためにプロセッサ及びメモリを有するが、必ずしもＭＬＤ内の各ＳＴＡに別個のＣＰＵ及びメモリが必要なわけではない。

図１８に、マルチリンク装置（ＭＬＤ）ハードウェア構成の実施形態例４０を示す。ＭＬＤには複数のＳＴＡが所属し、各ＳＴＡは異なる周波数のリンク上で動作する。ＭＬＤは、アプリケーションへの外部Ｉ／Ｏ４１アクセスを有し、このアクセスは、ＣＰＵ６２及びメモリ（例えば、ＲＡＭ）６４を有するＭＬＤ管理エンティティ４８に接続して、ＭＬＤレベルで通信プロトコルを実装する（単複の）プログラムの実行を可能にする。ＭＬＤは、接続先の各所属する局であるＳＴＡ１ ４２、ＳＴＡ２ ４４～ＳＴＡ Ｎ ４６にタスクを配分してこれらから情報を収集し、所属するＳＴＡ間で情報を共有することができる。

少なくとも１つの実施形態では、ＭＬＤの各ＳＴＡが独自のＣＰＵ５０及びメモリ（ＲＡＭ）５２を有し、これらは、１又は２以上のアンテナ６０ａ、６０ｂ、６０ｃ～６０ｎを有する少なくとも１つのＲＦ回路５６に接続された少なくとも１つのモデム５４にバス５８を通じて結合される。本開示は、主に無指向性アンテナを伴うサブ６ＧＨｚ帯に関心がある。ＲＦ回路及び関連する（単複の）アンテナと組み合わせたモデムは、近隣のＳＴＡとの間でデータフレームを送信／受信する。少なくとも１つの実装では、ＲＦモジュールが、周波数変換器、アレイアンテナコントローラ、及びアンテナと連動するためのその他の回路を含む。

ＭＬＤの各ＳＴＡは、特定のＭＬＤ実装に応じて互いに及び／又はＭＬＤ管理エンティティとリソースを共有することができるので、必ずしも独自のプロセッサ及びメモリを必要としないと理解されたい。なお、上記のＭＬＤ図は限定ではなく一例として示すものであり、本開示は、幅広いＭＬＤ実装と共に動作することができると理解されたい。

５．２．検討するＳＴＡトポロジー
開示する技術の目的をより良く説明するために、実施例ではあるネットワークシナリオを利用する。

図１９に、限定ではなく一例としてトポロジー（ネットワークシナリオ）の実施形態例７０を示す。このトポロジーは、提案する技術の目的を説明するために示すものにすぎず、特定のＳＴＡ構成に限定するためのものではない。このトポロジー例では、（例えば、会議室として例示する）エリア内に７つの局（ＳＴＡ）が存在し、そのうちの６つが３つのＭＬＤ７２、７４及び７６に関連付けられているものと仮定する。ＡＰ１ ８０及びＡＰ２ ８２はマルチリンク装置（ＭＬＤ）＃１ ７２に所属しており、ＳＴＡ１ ８４及びＳＴＡ４ ８６はＭＬＤ＃２ ７４に所属しており、ＳＴＡ３ ８８及びＳＴＡ５ ９０はＭＬＤ＃３ ７６に所属している。ＳＴＡ２ ７８は、例えばリンク１ ９２上で動作する非ＡＰ ＳＴＡ、又はシングルリンクＭＬＤ（すなわち、１つのＳＴＡのみを有して１つのリンク上で動作する特殊なＭＬＤ）とすることができる。ＳＴＡ１、ＳＴＡ２及びＳＴＡ３は、リンク１ ９４ａ及び９６ａを介してＡＰ１に関連付けられ、ＳＴＡ４及びＳＴＡ５は、リンク２ ９４ｂ及び９６ｂを介してＡＰ２に関連付けられる。

各ＳＴＡ及びその関連するＡＰは互いに通信することができる。なお、２つのＢＳＳを、その２つのＡＰが同じＭＬＤに所属しているという理由で同じＢＳＳとみなすこともできる。この例では、全てのＳＴＡが全てのリンク上でランダムチャネルアクセスのためにＥＤＣＡを使用するものとみなす。

５．３．ＲＴＡトラフィックと非ＲＴＡトラフィックとの区別
５．３．１．低遅延トラフィックストリーム（ＬＬＴＳ）動作
本節では、ＲＴＡ トラフィックと非ＲＴＡトラフィックとを区別するために、低遅延トラフィックストリーム（ＬＬＴＳ）と呼ばれる機構を導入する。一般に、ＬＬＴＳは、遅延、ジッタ及び／又は信頼度などの特別なＱｏＳ要件を有するトラフィックストリームを他のトラフィックと区別するために利用することができる。

多くの場合、ＲＴＡは、本明細書ではＲＴＡセッションと呼ぶＳＴＡ間の接続指向通信として定期的にトラフィックを生成する。ＳＴＡは、ネットワーク内で複数のＲＴＡセッションを有することができる。ＳＴＡは、これらのＲＴＡセッションを正しく管理し、ＲＴＡセッションのＲＴＡパケットに正しい送信スキームを適用することができる。限定ではなく一例として、上位層からのＲＴＡセッションのＲＴＡトラフィックを識別するために低遅延トラフィックストリーム（ＬＬＴＳ）を利用することができる。

図２０に、ＬＬＴＳを終了又は修正する実施形態例１１０を示しており、このプロセスは、ＬＬＴＳの変更又は削除を含む他のＬＬＴＳ動作に利用することもできると理解されるであろう。ＳＴＡの相互作用モデルは、ＩＥＥＥ８０２．１１標準で定められるものと同じであることができる。発信者はＡＰ又は非ＡＰ ＳＴＡのいずれかであることができ、受信者もＡＰ又は非ＡＰ ＳＴＡのいずれかであることができる。説明を単純にするために、本節のＬＬＴＳ設定手順には、この例の発信者を非ＡＰ ＳＴＡと仮定し、受信者をＡＰと仮定する。この図には、非ＡＰ ＳＴＡのＳＭＥ１１２及びＭＬＭＥ１１４と、ＡＰのＭＬＭＥ１１６及びＳＭＥ１１８とを示す。

非ＡＰ ＳＴＡ又はＭＬＤは、ＡＰ又はＡＰ ＭＬＤとの間でＬＬＴＳ設定手順を開始すると決定する。非ＡＰ ＳＴＡ又はＭＬＤの局管理エンティティ（ＳＭＥ）は、そのＭＡＣサブレイヤ管理エンティティ（ＭＬＭＥ）に（表３に示すような）ＭＬＭＥ－ＬＬＴＳ．ｒｅｑｕｅｓｔメッセージ１２０を送信する。非ＡＰ ＳＴＡのＭＬＭＥは、ＭＬＭＥ－ＬＬＴＳ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＭＬＭＥ－ＬＬＴＳ．ｒｅｑｕｅｓｔメッセージ内の情報を収集して、ＡＰにＬＬＴＳ要求フレーム１２２を送信する。
ＡＰのＭＬＭＥはフレームを受け取り、そのＳＭＥ又は所属するＭＬＤのＳＭＥに対して（表４に示すような）ＭＬＭＥ－ＬＬＴＳ．ｉｎｄｉｃａｔｉｏｎメッセージ１２４を生成する。

次に、ＡＰのＳＭＥはＡＰ ＭＬＤのＬＬＴＳ要求を処理し（１２６）、そのＭＬＭＥにＬＬＴＳ設定結果を含む（表５に示すような）ＭＬＭＥ－ＬＬＴＳ．ｒｅｓｐｏｎｓｅメッセージ１３０を送信する。その後、ＡＰのＭＬＭＥは、非ＡＰ ＳＴＡにＬＬＴＳ応答フレーム１３２を送信する。非ＡＰ ＳＴＡのＭＬＭＥはフレームを受け取り、そのＳＭＥ又はその所属するＭＬＤのＳＭＥに（表６に示すような）ＭＬＭＥ－ＬＬＴＳ．ｃｏｎｆｉｒｍメッセージ１３４送信する。この結果、非ＡＰは、このメッセージに含まれる情報からＬＬＴＳ設定が成功したか否かを確認（認識又は判定）することができる。

ＡＰ又はＡＰ ＭＬＤは、非ＡＰ ＳＴＡ又はＭＬＤとのＬＬＴＳを変更又は終了すると決定することができる。ＡＰのＳＭＥ又はＡＰ ＭＬＤのＳＭＥは、ＡＰのＭＬＭＥ又は所属するＡＰのＭＬＭＥに（表７に示すような）ＭＬＭＥ－ＬＬＴＳ－ＴＥＲＭ．ｒｅｑｕｅｓｔメッセージ１３６を送信する。ＡＰのＭＬＭＥは、ＭＬＭＥ－ＬＬＴＳ－ＴＥＲＭ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＭＬＭＥ－ＬＬＴＳ－ＴＥＲＭ．ｒｅｑｕｅｓｔメッセージ内の情報を収集して、非ＡＰ ＳＴＡにＬＬＴＳ応答フレーム１３８を送信する。非ＡＰ ＳＴＡのＭＬＭＥはフレームを受け取り、ＳＭＥに対して（表８に示すような）ＭＬＭＥ－ＬＬＴＳ－ＴＥＲＭ．ｉｎｄｉｃａｔｉｏｎメッセージ１４０を生成する。その後、非ＡＰは、ＬＬＴＳが終了したこと又は修正されたことを認識する。

ＲＴＡセッションのＲＴＡトラフィックは、ＬＬＴＳ設定によって分類することができる。ＬＬＴＳ設定手順中には、ＴＣＬＡＳ要素及びＴＣＬＡＳプロセス要素が交換される。トラフィックの上位層情報が図２３に示すようなＲＴＡ－ＴＳＰＥＣ要素内の情報と一致する場合、上位層からのトラフィックはＲＴＡセッションのＲＴＡトラフィックであるとみなされる。

少なくとも１つの実施形態では、ＲＴＡセッションのトラフィックのＱｏＳ要件が、ＬＬＴＳ設定手順中にＲＴＡ－ＴＳＰＥＣ要素を交換することによってＡＰと非ＡＰ ＳＴＡとの間で共有される。ＬＬＴＳ設定は、ＡＰ及び非ＡＰ ＳＴＡがＲＴＡトラフィック送信をサポートするのに十分なリソースを有しているかどうかをチェックするために利用することもできる。

また、同じＬＬＴＳ設定手順のためのＬＬＴＳ要求フレーム及びＬＬＴＳ応答フレームを、異なるリンクを介して送信することもできる。

図２１に、本明細書で利用するＬＬＴＳ要求フレームフォーマットの実施形態例１５０を示す。フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。期間（Ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。アドレス１（Ａｄｄｒｅｓｓ １）フィールドは、フレームの受信者のアドレスを含む。アドレス２（Ａｄｄｒｅｓｓ ２）フィールドは、フレームを送信したＳＴＡのアドレスを含む。アドレス３（Ａｄｄｒｅｓｓ ３）フィールドはＢＳＳＩＤを含む。シーケンス制御（Ｓｅｑｕｅｎｃｅ ｃｏｎｔｒｏｌ）フィールドは、フレームのシーケンス番号を示す。ＨＴ制御（ＨＴ ｃｏｎｔｒｏｌ）フィールドは、フレームのためのさらなる制御情報を示す。アクション（Ａｃｔｉｏｎ）フィールドは、ＬＬＴＳ要求フレームである場合に実行すべき動作を示し、以下で概説するサブフィールドを有する。

カテゴリ（Ｃａｔｅｇｏｒｙ）フィールド及びＱｏＳアクション（ＱｏＳ Ａｃｔｉｏｎ）フィールドはアクションフィールドのタイプを示し、この事例ではアクションフィールドがＬＬＴＳ要求フレームであることを示す。ダイアログトークン（Ｄｉａｌｏｇ ｔｏｋｅｎ）フィールドはＬＬＴＳ要求トランザクションを指定し、少なくとも１つの実施形態では、ＬＬＴＳ要求フレームを識別する整数に設定することができる。受信側はこのトークンフィールドを受け取ると、同じダイアログトークンを使用してＬＬＴＳ応答フレームに応答すべきである。アクションフィールドは、（この例ではＬＬＴＳ要求要素であることを示す）要素のタイプを示す要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）、ＬＬＴＳ要求要素の長さを示す長さ（Ｌｅｎｇｔｈ）サブフィールド、及びＬＬＴＳ記述子フィールドのシーケンスを示すＬＬＴＳ記述子リスト（ＬＬＴＳ Ｄｅｓｃｒｉｐｔｏｒ Ｌｉｓｔ）というサブフィールドを有するＬＬＴＳ要求要素を含む。各ＬＬＴＳ記述子フィールドは、特定の仕様及び分類情報に従ってトラフィックのＬＬＴＳ設定要求を示すように設定される。この情報が受け取られると、トラフィックの仕様及び分類情報を認識した受信側ＳＴＡは、ＬＬＴＳ設定要求を容認するか、それとも拒絶するかを決定することができる。

図２２に、ＬＬＴＳ記述子フィールドフォーマットの実施形態例１７０を示す。ＬＬＩＤフィールドは、低遅延送信サービスの識別を提供し、非ＡＰ ＳＴＡは、この中でＬＬＴＳを表す番号を設定する。ＡＰは、この番号を受け取り、これを使用して、非ＡＰ ＳＴＡによって設定されたＬＬＴＳを識別することができる。少なくとも１つの実施形態又はモードでは、このフィールドが非ＡＰ ＳＴＡによって予約され、ＡＰのみがこのフィールドを設定することができる。このフィールドは、ＩＥＥＥ８０２．１１で定められるストリーム分類サービス（Ｓｔｒｅａｍｅｄ Ｃｌａｓｓｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ：ＳＣＳ）ＩＤであることができる。ＬＬ長さ（ＬＬ Ｌｅｎｇｔｈ）フィールドは、ＬＬＴＳ記述子フィールドの長さを含む。要求タイプ（Ｒｅｑｕｅｓｔ Ｔｙｐｅ）フィールドは、ＬＬＴＳ記述子のタイプを示すように設定される。非ＡＰ ＳＴＡ又はＭＬＤは、要求タイプフィールドを「追加（Ａｄｄ）」に設定した場合には、新たなＬＬＴＳを追加するように要求する。受信側ＡＰ又はＡＰ ＭＬＤは、新たなＬＬＴＳの追加を容認するか否かを応答すべきである。

非ＡＰ ＳＴＡ又はＭＬＤは、要求タイプフィールドを「変更（Ｃｈａｎｇｅ）」に設定した場合には、既存のＬＬＴＳを変更するように要求する。ＡＰ又はＡＰ ＭＬＤは、このフィールドを受け取ると、ＬＬＩＤを使用してＬＬＴＳを発見することができる。その後、ＡＰ又はＡＰ ＭＬＤは、このＬＬＴＳのパラメータの変更を容認又は拒絶する。

非ＡＰ ＳＴＡ又はＭＬＤは、要求タイプを「削除（Ｒｅｍｏｖｅ）」に設定した場合には、既存のＬＬＴＳを削除するように要求する。ＡＰ又はＡＰ ＭＬＤは、このフィールドを受け取ると、ＬＬＩＤを使用してＬＬＴＳを発見し、削除することができる。

ＴＣＬＡＳフィールドは、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ要素と同じものである。ＳＴＡ又はＭＬＤは、このフィールドを上位層からのトラフィックの情報を示すように設定する。トラフィックがダウンリンクであってトラフィックの上位層情報がＴＣＬＡＳ情報と一致する場合、ＳＴＡ又はＭＬＤは、この情報を使用して、この上位層から到着したこのＬＬＴＳ下のＲＴＡトラフィックを識別することができる。ＬＬＴＳ記述子（ＬＬＴＳ Ｄｅｓｃｒｉｐｔｏｒ）フィールドは、複数のＴＣＬＡＳフィールドを含むことができる。

ＴＣＬＡＳ処理（ＴＣＬＡＳ Ｐｒｏｃｅｓｓｉｎｇ）フィールドは、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ処理要素と同一である。ＬＬＴＳ記述子フィールド内に複数のＴＣＬＡＳフィールドが存在する場合、非ＡＰ ＳＴＡは、複数のＴＣＬＡＳフィールドを使用してＲＴＡトラフィックを識別するルールを示すようにこのフィールドを設定する。ＡＰは、ＬＬＴＳ記述子フィールド内でこのフィールドを受け取ると、複数のＴＣＬＡＳフィールドを使用して上位層からのトラフィックを識別することができると認識する。

ＲＴＡ－ＴＳＰＥＣフィールドは、ＬＬＴＳ下のＲＴＡトラフィックの仕様及びＱｏＳ要件を示すように非ＡＰ ＳＴＡによって設定される。ＡＰは、このフィールドを受け取ると、このフィールド内の情報を利用して、ＬＬＴＳ要求を容認すべきであるか、それとも拒絶すべきであるかを決定することができる。このフィールドは、このＬＬＴＳ下のトラフィック方向（例えば、アップリンク、ダウンリンク、ピアツーピア、又は双方向）の情報も含む。ＡＰは、このＬＬＴＳ下のＲＴＡトラフィックの送信に割り当てることができるチャネルリソースを示すこともできる。

任意のサブ要素（Ｏｐｔｉｏｎａｌ Ｓｕｂｅｌｅｍｅｎｔｓ）フィールドは、このＬＬＴＳ下のトラフィックの追加要求又は情報を示すようにＳＴＡによって設定される。ＡＰは、このフィールドを受け取ると、任意のサブ要素の情報を考慮して、ＬＬＴＳを容認すべきであるか、それとも拒絶すべきであるかを決定することができる。任意のサブ要素のいくつかの例は、図２４及び図２５に示す。

図２３に、ＲＴＡ－ＴＳＰＥＣフィールドコンテンツの実施形態例１９０を示す。ＴＳＰＥＣフィールドは、ＩＥＥＥ８０２．１１で定められるＴＳＰＥＣ要素と同一であることができる。ＳＴＡは、このフィールドを、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのためのＬＬＴＳ下のＲＴＡトラフィックのＴＳＩＤ、トラフィック特性及び部分的ＱｏＳ要件を示すように設定する。一部の例外として、ＴＳＰＥＣ要素のＴＳ情報フィールド内のＴＳＩＤフィールドは、０～７、又は０～１５、又は８～１５の値に設定することができる。

ＲＴＡ属性（ＲＴＡ Ａｔｔｒｉｂｕｔｅｓ）フィールドは、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのためのさらなるＱｏＳ要件を示す。このフィールドは、ＳＴＡ及びＡＰの両方にＬＬＴＳが実装されている時にのみ、ＴＳＰＥＣ要素と共に又はＴＳＰＥＣ要素内に現れることができる。

信頼度（Ｒｅｌｉａｂｉｌｉｔｙ）フィールドは、ＲＴＡ－ＴＳＰＥＣのＲＴＡトラフィックのパケット損失要件を示すようにＳＴＡによって設定される。ＡＰは、このフィールドを受け取ると、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックの送信のためのリソース配分を、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのパケット損失が信頼度フィールドに示されるパケット損失未満になるように推定すべきである。

信頼度フィールドは、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのパケットエラー率の値に設定することができる。ＡＰは、ＲＴＡトラフィックのＬＬＴＳを容認した後に、ＲＴＡトラフィックのパケットエラー率がフィールド内に設定された値よりも高くならないことを確実にすべきである。例えば、このフィールドが５％に設定されている場合、ＡＰは、１００個のＲＴＡフレームのうち、送信に失敗したＲＴＡフレームを最大５個まで有することができる。ＡＰは、このパケットエラー率レベルを保証できない場合にはＬＬＴＳ設定要求を拒絶することができる。

或いは、信頼度フィールドは、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのパケット配信率の値に設定することもできる。ＡＰは、ＲＴＡトラフィックのＬＬＴＳを容認した後に、ＲＴＡトラフィックのパケット配信率がフィールド内に設定された値よりも低くならないことを確実にすべきである。例えば、ＡＰは、このフィールドを９５％に設定した場合、１００個のＲＴＡフレームのうち少なくとも９５個のＲＴＡフレームを正常に送信する必要がある。ＡＰは、このレベルのパケット配信率を保証できない場合にはＬＬＴＳ設定要求を拒絶することができる。

ジッタ（Ｊｉｔｔｅｒ）フィールドは、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのジッタ要件を示すようにＳＴＡによって設定される。ＡＰは、このフィールドを受け取ると、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックの送信のためのリソース配分を、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのジッタ要件を満たすことができるように推定する。

ジッタフィールドは、このＲＴＡ－ＴＳＰＥＣ要素下のＲＴＡトラフィックの平均遅延要件を示すように、オリジナルのＴＳＰＥＣ要素の遅延限界フィールドと組み合わせて利用することができる。例えば、遅延限界フィールドが１５ｍｓに設定され、ジッタフィールドが５ｍｓに設定されている場合、このＲＴＡ－ＴＳＰＥＣ要素下のＲＴＡトラフィックの平均遅延要件は、（遅延限界－ジッタ）＝１５ｍｓ－５ｍｓ＝１０ｍｓである。１つの代替方法では、このＲＴＡ－ＴＳＰＥＣ要素下のＲＴＡトラフィックの平均遅延要件が、（遅延限界－ジッタ／２）＝１５ｍｓ－５ｍｓ／２＝１２．５ｍｓである。ＡＰは、ジッタ要件を満たすために、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックの平均遅延が平均遅延要件よりも小さいことを保証すべきである。

ＭＳＤＵ有効期限（ＭＳＤＵ Ｌｉｆｅｔｉｍｅ）フィールドは、キュー内にＭＳＤＵを記憶できる時間を表す。決定論的サービス（Ｄｅｔｅｒｍｉｎｉｓｔｉｃ Ｓｅｒｖｉｃｅ）フィールドが第１の状態（例えば、「１」）に設定されている場合、ＳＴＡは、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのＭＳＤＵ又はＡ－ＭＳＤＵ有効期限を示すようにこのフィールドを設定する。ＳＴＡがこのフィールドを受け取って決定論的サービスフィールドが第１の状態（例えば、「１」）に設定されている場合には、このＭＳＤＵ有効期限内にＭＳＤＵ又はＡ－ＭＳＤＵが正常に送信されなければＭＳＤＵ又はＡ－ＭＳＤＵは破棄される。決定論的サービスフィールドが第２の状態（例えば、「０」）に設定されている場合、このフィールドは予備である。なお、このフィールドは、ＴＳＰＥＣ要素内の遅延限界フィールドに置き換えることができる。

決定論的サービス（Ｄｅｔｅｒｍｉｎｉｓｔｉｃ Ｓｅｒｖｉｃｅ）フィールドは、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのＭＳＤＵの有効期限が過ぎた時にＭＳＤＵが破棄されるかどうかを示すようにＳＴＡによって設定される。ＳＴＡがこのフィールドを第１の状態（例えば、「１」）に設定した場合、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのＭＳＤＵは、その有効期限が過ぎた時に破棄される。そうでなければ、ＳＴＡはこのフィールドを第２の状態（例えば、「０」）に設定する。第１の状態（例えば、「１」）に設定されたこのフィールドをＳＴＡが受け取った場合、このＲＴＡ－ＴＳＰＥＣ下のＲＴＡトラフィックのＭＳＤＵは、ＭＳＤＵ有効期限フィールドに示されるその有効期限が過ぎた時に破棄される。「０」に設定されたこのフィールドをＳＴＡが受け取った場合、ＭＳＤＵ有効期限フィールドは予備である。

図２４に、上位層ストリームＩＤを搬送する任意のサブ要素の実施形態例２１０を示す。サブ要素ＩＤ（Ｓｕｂ－ｅｌｅｍｅｎｔ ＩＤ）フィールドは、サブ要素のタイプを含み、この事例ではＬＬＴＳ要求要素下での任意のサブ要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドは、任意のサブ要素フィールドの長さを示す。上位層ストリームＩＤ（Ｈｉｇｈｅｒ Ｌａｙｅｒ Ｓｔｒｅａｍ ＩＤ）フィールドは、上位層からの上位層ストリームＩＤを示す。ＳＴＡは、このフィールドの受信者が現在のＬＬＴＳを上位層のトラフィックフローにマッピングできるようにこのフィールドをフレーム内に設定する。

図２５に、ＬＬＴＳ／ＴＩＤ対リンクマッピングを搬送する任意のサブ要素の実施形態例２３０を示す。サブ要素ＩＤ（Ｓｕｂ－ｅｌｅｍｅｎｔ ＩＤ）フィールドはサブ要素のタイプを示し、この事例ではＬＬＴＳ要求要素下での任意のサブ要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドは、任意のサブ要素フィールドの長さを示す。ＬＬＴＳレベルリンクマッピング（ＬＬＴＳ ｌｅｖｅｌ ｌｉｎｋ ｍａｐｐｉｎｇ）フィールドは、使用すべきリンクマッピングのタイプを決定するための機構を提供する。少なくとも１つの実施形態では、このフィールドが１ビット指示を含むことができる。このフィールドが第１の状態（例えば、「１」）に設定されている場合、ＬＬＴＳ／ＴＩＤ対リンクマッピングフィールドは、マッピング内のＬＬＴＳがＬＬＴＳ記述子フィールド内に示されたＬＬＴＳであるＬＬＴＳ対リンクマッピングを使用するためのものである。このフィールドが第２の状態（例えば、「０」）に設定されている場合、ＬＬＴＳ／ＴＩＤ対リンクマッピングフィールドは、ＴＩＤがＬＬＴＳ記述子フィールド内に示されたＬＬＴＳのＴＩＤであるＴＩＤ対リンクマッピングを使用するためのものである。

ＬＬＴＳ／ＴＩＤ対リンクマッピング（ＬＬＴＳ／ＴＩＤ ｔｏ Ｌｉｎｋ ｍａｐｐｉｎｇ）フィールドは、ＬＬＴＳ／ＴＩＤ対リンクマッピングを示す。ＳＴＡは、ＬＬＴＳ下のトラフィックを送信できるリンクを示すようにこのフィールドを設定する。このフィールドは以下のサブフィールドを含む。

ＬＬＩＤフィールドは、低遅延送信サービスの識別を含む。非ＡＰ ＳＴＡは、ＬＬＴＳを表す番号を設定する。ＡＰは、この番号を受け取って、非ＡＰ ＳＴＡで設定されたＬＬＴＳを識別するために利用することができる。このフィールドは、ＩＥＥＥ８０２．１１で定められるストリーム分類サービス（ＳＣＳ）を識別することができる。リンク数（Ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋｓ）フィールドは、ＬＬＴＳ／ＴＩＤ対リンクマッピングフィールド内のリンクＩＤフィールドの数を示すように設定される。リンクＩＤ（Ｌｉｎｋ ＩＤ）フィールドは、ＬＬＴＳのトラフィックを送信できるリンクを示すように設定される。１又は２以上のリンクＩＤフィールドを利用することができ、この例には複数（１個～ｎ個）のリンクＩＤフィールドを示す。ＳＴＡは、ＬＬＴＳ要求フレームにおいてＬＬＴＳ／ＴＩＤ対リンクマッピングを送信する際に、このＬＬＴＳ下のトラフィックをどのリンクで送信すべきであるかを示唆するようにこのフィールドを設定することができる。

図２６に、ＬＬＴＳ応答フレームの実施形態例２５０を示す。フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。期間（Ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。アドレス１（Ａｄｄｒｅｓｓ １）フィールドは、フレームの受信者のアドレスを含む。アドレス２（Ａｄｄｒｅｓｓ ２）フィールドは、フレームを送信したＳＴＡのアドレスを含む。アドレス３（Ａｄｄｒｅｓｓ ３）フィールドは、ＢＳＳＩＤを含む。シーケンス制御（Ｓｅｑｕｅｎｃｅ ｃｏｎｔｒｏｌ）フィールドは、フレームのシーケンス番号を示す。ＨＴ制御（ＨＴ ｃｏｎｔｒｏｌ）フィールドは、フレームのためのさらなる制御情報を示す。アクション（Ａｃｔｉｏｎ）フィールドは、ＬＬＴＳ要求フレームの場合に実行すべきアクションを示す。アクションフィールドは、以下のサブフィールドを含む。

カテゴリ（Ｃａｔｅｇｏｒｙ）サブフィールド及びＱｏＳアクション（ＱｏＳ Ａｃｔｉｏｎ）サブフィールドはアクションフィールドのタイプを示し、この事例ではＬＬＴＳ応答フレーム内に存在する。ダイアログトークン（Ｄｉａｌｏｇ ｔｏｋｅｎ）サブフィールドはＬＬＴＳ応答トランザクションを指定し、少なくとも１つの実施形態では、ＬＬＴＳ応答フレームを識別する整数に設定することができる。ＬＬＴＳ応答フレームがＬＬＴＳ要求フレームに対する応答である場合、このフィールドはＬＬＴＳ要求フレームと同様に設定されるべきである。受信側はこのフィールドを受け取ると、ＬＬＴＳ応答フレームが、同じダイアログトークンを有するＬＬＴＳ要求フレームに対する応答であると認識する。

アクションフィールドは、ＬＬＴＳ応答要素も含む。ＬＬＴＳ要求要素のフォーマットは以下の通りである。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＬＬＴＳ応答要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドはＬＬＴＳ応答要素の長さを示す。ＬＬＴＳ状態リスト（ＬＬＴＳ Ｓｔａｔｕｓ Ｌｉｓｔ）フィールドは、一連のＬＬＴＳ状態フィールドを含む。各ＬＬＴＳ状態フィールドは、特定の仕様及び分類情報下でのトラフィックのＬＬＴＳ設定応答を示すように設定される。受信側ＳＴＡは、この情報を受け取ると、ＲＴＡトラフィックのＬＬＴＳ設定の結果又は既存のＬＬＴＳの変更を判定することができる。

図２７に、ＬＬＴＳ状態フィールドの実施形態例２７０を示す。ＬＬＩＤフィールドは、低遅延送信サービスの識別を含む。ＬＬ長さ（ＬＬ Ｌｅｎｇｔｈ）フィールドは、ＬＬＴＳ状態フィールドの長さを含む。応答タイプ（Ｒｅｓｐｏｎｓｅ Ｔｙｐｅ）フィールドは、ＬＬＴＳ設定結果のタイプを示すように設定される。ＡＰは、応答タイプフィールドを「容認（Ａｃｃｅｐｔ）」に設定した場合には、非ＡＰ ＳＴＡからのＬＬＴＳ設定要求を容認する。非ＡＰ ＳＴＡは、このフィールドを受け取ると、ＬＬＴＳ設定が成功したかどうかを判定することができる。ＡＰは、応答タイプフィールドを「修正（Ｍｏｄｉｆｉｅｄ）」に設定した場合には、非ＡＰ ＳＴＡとの既存のＬＬＴＳを修正する。非ＡＰ ＳＴＡは、このフィールドを受け取ると、対応するＬＬＩＤを有するＬＬＴＳがＡＰによって修正されたと判定することができる。非ＡＰ ＳＴＡは、修正を容認するか、或いはこのＡＰをネゴシエートするために別のＬＬＴＳを開始することができる。ＡＰは、応答タイプフィールドを「拒否（Ｄｅｎｉｅｄ）」に設定した場合には、非ＡＰ ＳＴＡからのＬＬＴＳ設定要求を拒絶する。非ＡＰ ＳＴＡは、このフィールドを受け取ると、ＡＰとの別のＬＬＴＳ設定を開始することができる。ＡＰは、応答タイプを「終了（Ｔｅｒｍｉｎａｔｅ）」に設定した場合には、非ＡＰ ＳＴＡとの既存のＬＬＴＳを終了させる。非ＡＰ ＳＴＡは、このフィールドを受け取ると、対応するＬＬＩＤのＬＬＴＳが終了したことを認識し、ＬＬＴＳを削除すべきである。なお、このフィールドは、ＩＥＥＥ８０２．１１で定められる状態コード（Ｓｔａｔｕｓ Ｃｏｄｅ）フィールドと同一であることができる。

ＴＣＬＡＳフィールドは、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ要素と同一であることができる。ＡＰは、上位層からのトラフィックの情報を示すようにこのフィールドを設定する。非ＡＰ ＳＴＡは、このフィールドを受け取ると、この上位層から到着したＴＴＬＳ下のトラフィックがアップリンクである場合、この情報を使用してトラフィックを識別することができる。ＬＬＴＳ状態フィールドは、複数のＴＣＬＡＳフィールドを含むことができる。

ＴＣＬＡＳ処理フィールドは、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ処理要素と同一であることができる。ＬＬＴＳ状態フィールドに複数のＴＣＬＡＳフィールドが存在する場合、ＡＰは、複数のＴＣＬＡＳフィールドを使用してＲＴＡ トラフィックを識別するルールを示すようにこのフィールドを設定する。非ＡＰ ＳＴＡは、ＬＬＴＳ状態フィールド内でこのフィールドを受け取ると、複数のＴＣＬＡＳフィールドを使用して上位層からのトラフィックを識別する方法を決定することができる。

ＲＴＡ－ＴＳＰＥＣフィールドは、図２３に定めるＲＴＡ－ＴＳＰＥＣ要素と同一であることができる。ＡＰは、このフィールドをＲＴＡトラフィックの仕様及びＱｏＳ要件を示すように設定する。非ＡＰ ＳＴＡは、このフィールドを受け取ると、ＲＴＡ－ＴＳＰＥＣ下のトラフィックのためにＬＬＴＳの決定が行われると認識する。このフィールドは、このＬＬＴＳ下のＲＴＡトラフィックの方向（例えば、アップリンク、ダウンリンク、ピアツーピア、又は双方向）の情報も含む。ＡＰは、このＬＬＴＳのＲＴＡトラフィックの送信に割り当てることができるチャネルリソースを示すこともできる。

任意のサブ要素（Ｏｐｔｉｏｎａｌ Ｓｕｂ－ｅｌｅｍｅｎｔｓ）フィールドは、このＬＬＴＳのトラフィックの追加情報又は設定を示すようにＡＰによって設定される。任意のサブ要素のいくつかの例については、図２４及び図２５に示している。

５．３．２．ＲＴＡトラフィックの区別
図２８に、ＲＴＡトラフィックと非ＲＴＡトラフィックとを区別する実施形態例３１０を示す。ＳＴＡ又はＭＬＤのＭＡＣ層が上位層からトラフィックを受け取る（３１２）と、上位層からのトラフィックが既存のＬＬＴＳに属しているかどうかを判定するチェックが行われる（３１４）。トラフィックが既存のＬＬＴＳに属する上位層からのものである場合、ブロック３１６において、このトラフィックがそのＬＬＴＳに属するＲＴＡトラフィックであることが登録される。一方で、上位層からのトラフィックが既存のＬＬＴＳに属していない場合、ブロック３１８において、このトラフィックが非ＲＴＡトラフィックであることが登録される。

５．３．３．ＬＬＴＳの例
表９にＬＬＴＳ（例えば、ＬＬＴＳ１～ＬＬＴＳ６）の例を示す。表内の発信者列は、ＬＬＴＳ設定手順を開始する、すなわちＬＬＴＳ要求フレームを送信するＳＴＡ又はＭＬＤを示す。受信者列は、ＬＬＴＳ要求フレームを受け取ってＬＬＴＳ応答フレームを送信するＳＴＡ又はＭＬＤを表す。例えば、テーブルの２行目は、例えばＬＬＴＳ１などのＬＬＩＤが１に等しいＬＬＴＳを表す。このＬＬＴＳの発信者はＳＴＡ２であり、受信者はＡＰ１又はＭＬＤ１であることができる。方向列は、ＬＬＴＳの方向に関する。これがダウンリンクである場合、このＬＬＴＳのＲＴＡトラフィックはＡＰ１（又はＭＬＤ１）からＳＴＡ２に送信され、一方でアップリンクの場合には逆方向であり、このＬＬＴＳのＴＩＤが８であり、ユーザ優先度（ＵＰ）が６であることが例示される。リンク列は、このＬＬＴＳ下のトラフィックがどのリンク（例えば、リンク１及び／又はリンク２）を通じて送信されるかを示す。

ＳＴＡは、＜ＬＬＩＤ、発信者＞、＜ＬＬＩＤ、受信者＞又は＜ＬＬＩＤ、発信者、受信者＞などのＬＬＴＳ情報のタプルによってＬＬＴＳを識別することができる。ＡＰ又はＡＰ ＭＬＤは、そのＢＳＳ内の各ＬＬＴＳの一意のＬＬＩＤを使用することにより、各ＳＴＡがＬＬＩＤを利用してＢＳＳ内のＬＬＴＳをＬＬＩＤのみによって識別できるようにすることも、或いは＜ＬＬＩＤ、ＢＳＳＩＤ＞のタプルを使用してＢＳＳ及びＯＢＳＳ内のＬＬＴＳを識別できるようにすることもできる。

５．４．ＲＴＡパケットを送信するためのＴＸＯＰ共有
５．４．１．フローチャート
非プライマリＡＣからＲＴＡフレームを送信するためのＴＸＯＰ共有の手順について説明する。開示する技術は、ＩＥＥＥ８０２．１１ａｘにおける現在のＴＸＯＰ共有ルールと比べて、たとえプライマリＡＣからの未送信フレームが存在する場合でも、ＳＴＡがプライマリＡＣのＴＸＯＰを共有して非プライマリＡＣからのＲＴＡフレームを送信することを可能にする。

図２９に、非プライマリＡＣからのＲＴＡトラフィックを送信するＴＸＯＰ共有の実施形態例３３０を示す。ＲＴＡトラフィックは、ＥＤＣＡキューに到着するとフレーム単位でカプセル化される。ＲＴＡトラフィックを搬送するフレームはＲＴＡフレームとして表され、非ＲＴＡトラフィックを搬送するフレームは非ＲＴＡフレームとして表される。１又は２以上のフレームを１つのパケットに含め、リンク又はチャネルを介して送信することができる。ＴＸＯＰを獲得したＥＤＣＡＦに関連するＡＣはプライマリＡＣと呼ばれる。

ＳＴＡがプライマリＡＣのＴＸＯＰを取得する（３３２）と、このＴＸＯＰ中に非プライマリＡＣからのフレームを送信するためにＴＸＯＰを共有するか否かについての決定が行われる（３３４）。

ＳＴＡが非プライマリＡＣからの非ＲＴＡフレームを送信するためにＴＸＯＰを共有しないと決定した場合、ブロック３３８において、ＩＥＥＥ８０２．１１ａｘで定められる現在のＴＸＯＰ共有ルールに従ってフレーム３４０を送信することができる。

一方で、ＳＴＡが非プライマリＡＣからのＲＴＡフレームを送信するためにそのＴＸＯＰを共有すると決定した場合には、たとえプライマリＡＣからの未送信フレームが存在する場合でも、非プライマリＡＣからのＲＴＡフレームを送信することができる（３３６）。その後、ブロック３４０において、ＳＴＡは、ＴＸＯＰ中に（単複の）非プライマリＡＣからのフレームを送信する。

局が非プライマリＡＣからのＲＴＡフレームを送信するためにＴＸＯＰを共有すると決定した場合には、以下の点に注意すべきである。ブロック３３６における非プライマリＡＣは、プライマリＡＣよりも高い優先度を有するＡＣのみを表すことができる。この場合の非プライマリＡＣからのＲＴＡフレームは、有効期限が迫っているフレーム（例えば、このフレームはＴＸＯＰの終了前に有効期限切れになる）のみを表すことができる。

ＴＸＯＰ中には以下のシーケンスが可能である。

（１）ＳＴＡは、非プライマリＡＣからの全部／一部のＲＴＡフレームを最初に送信し、その後にプライマリＡＣからのフレームを送信するものとする／することができる。ＳＴＡは、例えば以下のルールのうちのいずれか１つに従うことができる。（ａ）プライマリＡＣよりも優先度の高い非プライマリＡＣからのＲＴＡフレームを最初に送信し、その直後にプライマリＡＣからのフレームを送信するものとする／することができる。（ｂ）プライマリＡＣからのＲＴＡフレームを最初に送信し、その後にプライマリＡＣよりも優先度の高い非プライマリＡＣからのＲＴＡフレームを送信し、次にプライマリＡＣからの非ＲＴＡフレームを送信するものとする／することができる。（ｃ）（単複の）再送であってプライマリＡＣよりも優先度の高い非プライマリＡＣからの（単複の）ＲＴＡフレームを最初に送信し、その後にプライマリＡＣからのフレームを送信するものとする／することができる。

（２）ＳＴＡは、プライマリＡＣよりも優先度の低い非プライマリＡＣからのＲＴＡフレームを以下の場合にのみ送信することができる。（ａ）これらのＲＴＡフレームの有効期限が迫っている場合（例えば、このフレームはＴＸＯＰの終了前に有効期限切れとなる）、及び／又は（ｂ）プライマリＡＣからの全てのフレームが送信済みである場合、及び／又は（ｃ）この低優先度ＡＣが以前にプライマリＡＣとＴＸＯＰを共有していた場合。例えば、（２）（ｃ）の場合、この低優先度ＡＣは、ビーコン間隔などの現在の周期的時間にプライマリＡＣとＴＸＯＰを共有していたものとする。この低優先度ＡＣとのＴＸＯＰ共有時間は、低優先度ＡＣが現在の周期的時間中にプライマリＡＣと共有していたＴＸＯＰ時間よりも長くなってはならない。

（３）ＳＴＡは、プライマリＡＣよりも優先度の高い非プライマリＡＣからのＲＴＡフレームをプライマリＡＣからのＲＴＡフレームと同様に取り扱う。さらに、ＳＴＡは、プライマリＡＣよりも優先度の高い非プライマリＡＣからのＲＴＡフレームをプライマリＡＣからのＲＴＡフレームとして取り扱うこともできる。

（４）ＳＴＡがＭＵ ＰＰＤＵ（例えば、ＭＵ－ＭＩＭＯ又はＭＵ－ＯＦＤＭＡのＭＵ ＰＰＤＵ）を送信する際には、優先度の高い又は低い非プライマリＡＣからのＲＴＡフレーム及び非ＲＴＡフレームをＭＵ ＰＰＤＵに含めることができる。

（ａ）ＭＵ ＰＰＤＵの期間は、ＭＵ ＰＰＤＵ内の特定のフレームの送信及び遅延要件によって決定することができる。他のフレームがＭＵ ＰＰＤＵに含まれている場合、これらはＭＵ ＰＰＤＵの期間をこの要件よりも増加させてはならない。例えば、特定のフレームは、（ｉ）プライマリＡＣのみからのフレーム又はＲＴＡフレーム、及び／又は（ｉｉ）全ての非プライマリＡＣからの、又はプライマリＡＣよりも優先度の高い非プライマリＡＣからの、又はＭＵ ＰＰＤＵにおいて最も優先度の高い非プライマリＡＣからのＲＴＡフレームとすることができる。

（ｂ）所与のユーザ（すなわち、ＭＵ ＰＰＤＵの受信側ＳＴＡ）について、プライマリＡＣよりも優先度の高い非プライマリＡＣからのＲＴＡフレームは、プライマリＡＣからのフレームよりも早く送信されるものとする／することができる。例えば、（ｉ）プライマリＡＣからのいずれかのＲＴＡフレームが最初に送信され、その後に優先度の高いＡＣからのいずれかのＲＴＡフレームが送信され、次にプライマリＡＣからのいずれかの非ＲＴＡフレームが送信されるものとする／することができる。（ｉｉ）優先度の高いＡＣからのいずれかのＲＴＡフレームが最初に送信され、その直後にプライマリＡＣからのいずれかのフレームが送信されるものとする／することができる。（ｉｉｉ）プライマリＡＣからのいずれかのフレームが最初に送信され、その直後に優先度の高いＡＣからのいずれかのフレームが送信されるものとする／することができる。（ｉｖ）有効期限（例えば、ＭＳＤＵ有効期限）の短いフレームが先に送信されるものとする／することができる。

（５）ＳＴＡは、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために何らかのチャネルリソースを割り当てることを保証する。例えば、ＴＸＯＰ中のルールは以下の通りである。（ａ）ＳＴＡは、プライマリＡＣからの１又は２以上のフレームが送信されるまで非プライマリＡＣからのフレームを送信してはならない。（ｂ）ＳＴＡは、非プライマリＡＣからのＲＴＡフレームを送信するためにＴＸＯＰ共有の期間を制限するものとする。例えば、ＳＴＡは、ＴＸＯＰ共有の時間をＴＸＯＰ毎に又は周期的時間（例えばビーコン間隔）毎に（０．３ｍｓなどのＴＸＯＰ期間の長さ、又は２０％などのＴＸＯＰ期間の比率単位で）制限する。ＡＰは、この時間制限を関連するＳＴＡにおいて設定することができる。（ｃ）ＳＴＡは、専用時間によって示される（０．３ｍｓなどのＴＸＯＰ期間の長さ、又は２０％などのＴＸＯＰ期間の比率単位の）一定量のＴＸＯＰ時間がプライマリＡＣからのフレームの送信に使用されるまで、或いはプライマリＡＣからの全てのフレーム（又は全てのＲＴＡフレーム）が送信されるまで、非プライマリアＡＣからＲＴＡフレームを送信してはならない。（ｄ）ＳＴＡは、例えば専用バイトで（例えば、バイト単位で）示されるようなプライマリＡＣからの一定量のフレームが送信されるまで、或いはプライマリＡＣからの全てのフレーム（又は全てのＲＴＡフレーム）が送信されるまで、非プライマリＡＣからのＲＴＡフレームを送信してはならない。（ｅ）ＳＴＡは、ＴＸＯＰの開始時刻以降、専用時間によって（０．３ｍｓなどのＴＸＯＰ期間の長さ、又は２０％などのＴＸＯＰ期間の比率単位で）示される一定期間にわたり、ＩＥＥＥ８０２．１１ａｘで定められるＴＸＯＰ共有ルールに従うものとする。

（６）ＳＴＡは、ＩＥＥＥ８０２．１１ｂｅで定められるＲ－ＴＷＴ ＳＰなどの特別なチャネル期間中に、非プライマリＡＣからのＲＴＡフレームをプライマリＡＣからのものであるかのように取り扱う。

５．４．２．実施例
本節では、ＳＴＡが非プライマリＡＣからのＲＴＡフレームを送信するためにプライマリＡＣのＴＸＯＰを共有する方法を説明する複数の実施例を示す。これらの実施例のネットワークトポロジーについては図１９に示している。ＲＴＡと非ＲＴＡとの間のトラフィック分類プロセスは、５．３節で説明したＬＬＴＳ動作又は他のいずれかのトラフィック分類手順と同一又は同様であることができる。一例として、ここではネットワークトポロジー内の各ＳＴＡ又はＭＬＤが表９に示すようなＲＴＡのトラフィックフローを有するものと仮定する。ＬＬＴＳ下のトラフィックは、表１に示すＵＰ－ｔｏ－ＡＣマッピングに従ってＥＤＣＡキューに入ることができる。なお、ＬＬＴＳ下のトラフィックのＵＰは、ＬＬＴＳ設定では表９に示すＵＰのように示される。

図３０に、ＡＰ１又はＭＬＤ１のＥＤＣＡキューの状態の実施形態例３５０を示す。フレーム（ＭＳＤＵ、ＵＰ、ＲＴＡ）がマッピングされ（３５２）、キュー内に配置される。

ＡＣ＿ＶＯキュー３５４は、ここではＡＣ＿ＶＯ（１）～ＡＣ＿ＶＯ（３）として例示するＬＬＴＳ１下の３つのＲＴＡフレームを有するように例示するＡＣ ＶＯのＥＤＣＡキューを表す。

ＡＣ＿ＶＩキュー３５６は、ここではＡＣ＿ＶＩ（１）及びＡＣ＿ＶＩ（２）として例示するＬＬＴＳ２下の２つのＲＴＡフレームと、ＡＣ＿ＶＩ（３）として例示する１つの非ＲＴＡフレームとを有するように示すＡＣ ＶＩのＥＤＣＡキューを表す。

ＡＣ＿ＢＥキュー３５８は、ＡＣ＿ＢＥ（１）～ＡＣ＿ＢＥ（３）として例示する３つの非ＲＴＡフレームを有するように示すＡＣ ＢＥのＥＤＣＡキューを表す。

ＡＣ＿ＢＫキュー３６０は、キュー内にフレームが存在せず空であるように例示するＡＣ ＢＫのＥＤＣＡキューを表す。

これらのキューは、チャネル３７０を求めて競合するＥＤＣＡＦ３６２、３６４、３６６及び３６８に接続する。

図３１に、ＡＰ１がＴＸＯＰ中にのみ非プライマリＡＣからのＲＴＡフレームを送信する実施形態例３９０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態については図３０に示している。

この例では、ＡＰ１がＥＤＣＡ ＴＸＯＰを開始してＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しない場合のキュー状態を想定している。また、キュー状態がＭＬＤ１のものである場合、この例に示すＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、ＡＣ＿ＶＯ（１）４０４、ＡＣ＿ＶＯ（２）４１０及びＡＣ＿ＶＯ（３）４１６として例示するＲＴＡフレームを、それぞれのプリアンブル４０２、４０８及び４１４と共にＡＣ＿ＶＯキューからＳＴＡ２に送信する。この例に示すように、ＡＰ１は、ＴＸＯＰ中にのみＡＣ＿ＶＯキューからＲＴＡフレームを送信する。ＳＴＡ２は、これらの各送信を受け取ると、ブロック確認応答４０６、４１２及び４１８を生成する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを使用してＴＸＯＰを予約することができる。

図３２に、ＡＰ１又はＭＬＤ１の別のＥＤＣＡキュー状態の実施形態例４３０を示す。フレームは、図示のキュー内にマッピングされる（４３２）。図示のように、ＡＣ＿ＶＯキュー４３４は、ＡＣ＿ＶＯ（１）として例示するＬＬＴＳ１下の１つのＲＴＡフレームと、ＡＣ＿ＶＯ（２）として例示する１つの非ＲＴＡフレームとを有するＡＣ ＶＯのＥＤＣＡのキューを表す。ＡＣ＿ＶＩキュー４３６は、ＡＣ＿ＶＩ（１）として例示するＬＬＴＳ２下の１つのＲＴＡフレームと、ＡＣ＿ＶＩ（２）として例示する１つの非ＲＴＡフレームとを有するＡＣ ＶＩのＥＤＣＡのキューを表す。ＡＣ＿ＢＥキュー４３８は、ＡＣ＿ＢＥ（１）として例示するＬＬＴＳ３以下のＲＴＡフレームと、ＡＣ＿ＢＥ（２）として例示する非ＲＴＡフレームとを１つ有するＡＣ ＢＥのＥＤＣＡキューを表す。ＡＣ＿ＢＫキュー４４０は、キュー内にフレームが存在しないＡＣ ＢＫのＥＤＣＡキューを表す。各キューの下方には、チャネル４５０を取得してチャネル４５０上で送信するためのそれぞれのＥＤＣＡ機能４４２、４４４、４４６及び４４８を示す。

図３３に、ＡＰ１がＴＸＯＰ中にプライマリＡＣからのフレームよりも前に優先度の高い非プライマリＡＣからのＲＴＡフレームを送信する実施形態例４７０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態については図３２に示しており、この例では、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。また、キュー状態がＭＬＤ１のものである場合、この例に示すＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、最初にＡＣ＿ＶＯ（１）４７４として例示するＡＣ＿ＶＯキューからのＲＴＡフレームをＳＴＡ２に送信する。次に、ＡＣ＿ＶＩ（１）４８０として例示するＡＣ＿ＶＩキューからのＲＴＡフレームをＳＴＡ１に送信し、その後にＡＣ＿ＶＩ（２）４８６として例示するＡＣ＿ＶＩキューからの非ＲＴＡフレームをＳＴＡ３に送信する。これらの各送信を、それぞれのプリアンブル４７２、４７８及び４８４と共に示す。受信側の局は、ブロック確認応答（ＢＡ）４７６、４８２及び４８８で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図３４に、ＴＸＯＰ中にＡＰ１が最初にプライマリＡＣからのＲＴＡフレームを送信し、次に非プライマリＡＣからのＲＴＡフレームを送信し、その後にプライマリＡＣからの非ＲＴＡフレームを送信する実施形態例５１０を示す。ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は図３２に示す通りであり、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。また、キュー状態がＭＬＤ１のものである場合、例示するＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、最初にＡＣ＿ＶＩ（１）５１４として例示するＡＣ＿ＶＩキューからのＲＴＡフレームをＳＴＡ１に送信する。次に、ＡＣ＿ＶＯ（１）５２０として例示するＡＣ＿ＶＯキューからのＲＴＡフレームをＳＴＡ２に送信する。次に、ＡＣ＿ＶＩ（２）５２６として例示するＡＣ＿ＶＩキューからの非ＲＴＡフレームをＳＴＡ３に送信する。

これらの各送信を、それぞれのプリアンブル５１２、５１８、５２４と共に示す。受信側の局は、ブロック確認応答（ＢＡ）５１６、５２２及び５２８で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図３５に、ＡＰ１がプライマリＡＣよりも低い優先度を有する非プライマリＡＣからのＲＴＡフレームを送信する実施形態例５３０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態については図３２に示しており、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、この例に示すＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰを取得すると最初にＡＣ＿ＶＩ（１）５３４として例示するＡＣ＿ＶＩキューからのＲＴＡフレームをＳＴＡ１に送信する。次に、ＡＣ＿ＶＯ（１）５４０として例示するＡＣ＿ＶＯキューからのＲＴＡフレームをＳＴＡ２に送信する。次に、ＡＣ＿ＢＥ（１）５４６として例示するＡＣ＿ＢＥキューからのＲＴＡフレームを、ＴＸＯＰの終了時刻前に発生する有効期限切れ５５０がまもなく生じるという理由でＳＴＡ３に送信する。

これらの各送信を、それぞれのプリアンブル５３２、５３８及び５４４と共に示す。受信側の局は、ブロック確認応答（ＢＡ）５３６、５４２及び５４８で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図３６に、ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態の第３の例を示す実施形態例５７０を示す。フレームは、図示のキュー内にマッピングされる（４３２）。ＡＣ＿ＶＯキュー５７４は、ＬＬＴＳ１下の１つのＲＴＡフレームＡＣ＿ＶＯ（１）と、１つの非ＲＴＡフレームＡＣ＿ＶＯ（２）とを有する。ＡＣ＿ＶＩキュー５７６は、ＬＬＴＳ２下の２つのＲＴＡフレームと、１つの非ＲＴＡフレームＡＣ＿ＶＩ（３）とを有する。ＡＣ＿ＢＥキュー５７８は、３つの非ＲＴＡフレームを有する。ＡＣ＿ＢＫキュー５８０は、キュー内にフレームが存在しない。

各キューの下方には、チャネル５９０を取得してチャネル５９０上で送信するように構成されたそれぞれのＥＤＣＡ機能５８２、５８４、５８６及び５８８を示す。

図３７に、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、非プライマリＡＣからのＲＴＡフレームの送信要求によってＭＵ ＰＰＤＵの期間が決定される実施形態例６１０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態については図３６に示しており、この図では、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、この例に示すＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、ＡＣ＿ＶＩ（１）として例示するＡＣ＿ＶＩからＳＴＡ１のキューへのＲＴＡフレーム、ＡＣ＿ＶＯ（１）として例示するＡＣ＿ＶＯからＳＴＡ２へのＲＴＡフレーム、及びＡＣ＿ＶＩ（３）として例示するＡＣ＿ＶＯキューからＳＴＡ３への非ＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信する（６１４）。なお、ＭＵ ＯＦＤＭＡ ＰＰＤＵの期間は、フレームＡＣ＿ＶＩ（１）及びＡＣ＿ＶＩ（３）の期間ではなくフレームＡＣ＿ＶＯ（１）の期間によって決定される。

その後、ＡＰ１は、ＩＥＥＥ８０２．１１のＴＸＯＰ共有ルールに従って、ＡＣ＿ＶＩ（２）として例示するＡＣ＿ＶＩキューからのＲＴＡフレームと、ＡＣ＿ＶＯ（２）及びＡＣ＿ＢＥ（２）として示す非ＲＴＡフレームとを含む６２０の別のＭＵ ＯＦＤＭ ＰＰＤＵを送信する。

なお、この例及び以降の例には、パディングされる短いフレームを示す。

この例に示すＭＵ ＯＦＤＭＡ ＰＰＤＵは、ＭＵ ＭＩＭＯ ＰＰＤＵに置き換えることができる。この結果、ＭＵ ＰＰＤＵの各フレームは、異なるＲＵの代わりに異なる空間ストリームを通じて送信される。この図では、ＭＵ ＰＰＤＵのＡＣＫ又はＢＡなどの求められるフィードバックも、ＭＵ ＭＩＭＯ ＰＰＤＵのフィードバックに変更される。

送信６１４及び６２０は、それぞれのプリアンブル６１２及び６１８と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６１６で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図３８に、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、プライマリＡＣからのＲＴＡフレームの遅延要件によってＭＵ ＰＰＤＵの期間が決定される実施形態例６３０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態については図３６に示しており、ここではＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、例示するＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、ＡＣ＿ＶＩ（１）として例示するＡＣ＿ＶＩキューからＳＴＡ１へのＲＴＡフレーム、ＡＣ＿ＶＯ（１）として例示するＡＣ＿ＶＯキューからＳＴＡ２へのＲＴＡフレーム、及びＡＣ＿ＶＩ（３）として例示するＡＣ＿ＶＯキューからＳＴＡ３への非ＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信する（６３６）。なお、ＭＵ ＯＦＤＭＡ ＰＰＤＵの期間は、有効期限切れ６３８として示すフレームＡＣ＿ＶＯ（１）の期間によって決定され、ＭＵ ＯＦＤＭＡ ＰＰＤＵの期間は、フレームＡＣ＿ＶＩ（１）の最大期間（有効期間）６３２を超えることはできない。

その後、ＡＰ１は、ＩＥＥＥ８０２．１１のＴＸＯＰ共有ルールに従って、ＡＣ＿ＶＩ（２）として例示するＡＣ＿ＶＩキューからのＲＴＡフレームと、ＡＣ＿ＶＯ（２）及びＡＣ＿ＢＥ（２）として例示する非ＲＴＡフレームとを含むの別のＭＵ ＯＦＤＭ ＰＰＤＵを送信している（６４４）ことが分かる。

この例に示すＭＵ ＯＦＤＭＡ ＰＰＤＵは、ＭＵ ＭＩＭＯ ＰＰＤＵに置き換えることができ、この場合、ＭＵ ＰＰＤＵの各フレームは、異なるＲＵの代わりに異なる空間ストリームを通じて送信される。ＭＵ ＰＰＤＵのＡＣＫ又はＢＡなどの求められるフィードバックも、ＭＵ ＭＩＭＯ ＰＰＤＵのフィードバックに変更される。

送信６３６及び６４４は、それぞれのプリアンブル６３４及び６４２と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図３９に、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、プライマリＡＣからのＲＴＡフレームの遅延要件によってＭＵ ＰＰＤＵの期間が決定される別の実施形態例６５０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

図３６に示すＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は、ここではＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、この例に示すＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、ＡＣ＿ＶＩ（１）として例示するＡＣ＿ＶＩキューからＳＴＡ１へのＲＴＡフレーム、ＡＣ＿ＶＯ（１）として例示するＡＣ＿ＶＯキューからＳＴＡ２へのＲＴＡフレーム、及びＡＣ＿ＶＩ（３）として例示するＡＣ＿ＶＯキューからＳＴＡ３への非ＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信する（６３６）。なお、ＭＵ ＯＦＤＭＡ ＰＰＤＵの期間６３２はフレームＡＣ＿ＶＯ（１）の期間によって決定されるが、ＭＵ ＯＦＤＭＡ ＰＰＤＵの期間及び予想されるフィードバック（例えば、ＢＡ）は、有効期限切れ６５２として示すフレームＡＣ＿ＶＩ（１）の有効期間６５２を超えることはできない。

ＡＰ１は、ＩＥＥＥ８０２．１１のＴＸＯＰ共有ルールに従って、ＡＣ＿ＶＩ（２）として例示するＡＣ＿ＶＩキューからのＲＴＡフレームと、ＡＣ＿ＶＯ（２）及びＡＣ＿ＢＥ（２）として示す非ＲＴＡフレームとを搬送する別のＭＵ ＯＦＤＭ ＰＰＤＵをＳＴＡ１に送信する（６４４）。

この例に示すＭＵ ＯＦＤＭＡ ＰＰＤＵはＭＵ ＭＩＭＯ ＰＰＤＵに置き換えることができ、この場合、ＭＵ ＰＰＤＵ内の各フレームは、異なるＲＵの代わりに異なる空間ストリームを通じて送信される。この場合、ＭＵ ＰＰＤＵのＡＣＫ又はＢＡなどの求められるフィードバックも、ＭＵ ＭＩＭＯ ＰＰＤＵに使用されるフィードバックに変更される。

送信６３６及び６４４は、それぞれのプリアンブル６３４及び６４２と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図４０に、ＡＰ１が非プライマリＡＣからのＲＴＡフレームを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、プライマリＡＣからのＲＴＡフレームの送信要件によってＭＵ ＰＰＤＵの期間が決定される実施形態例６７０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

図３６に示すＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は、この例ではＡＰ１がＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、ＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、ＡＣ＿ＶＩ（１）として例示するＡＣ＿ＶＩキューからＳＴＡ１へのＲＴＡフレームと、ＡＣ＿ＶＯ（２）として例示するＳＴＡ２への非ＲＴＡフレームと、ＡＣ＿ＶＩ（３）として例示するＡＣ＿ＶＯキューからＳＴＡ３への非ＲＴＡフレームとを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信する（６７２）。フレームＡＣ＿ＶＯ（１）はフレームＡＣ＿ＶＩ（１）の期間よりも長いので、最初のＭＵ ＯＦＤＭＡ ＰＰＤＵには含まれない。

次に、ＡＰ１は、ＲＴＡフレームＡＣ＿ＶＩ（２）、ＲＴＡフレームＡＣ＿ＶＯ（１）及び非ＲＴＡフレームＡＣ＿ＢＥ（２）を搬送する別のＭＵ ＯＦＤＭ ＰＰＤＵを送信する（６７４）。フレームＡＣ＿ＶＯの期間は、フレームＡＣ＿ＶＩ（２）の期間よりも短い。

この例に示すＭＵ ＯＦＤＭＡ ＰＰＤＵはＭＵ ＭＩＭＯ ＰＰＤＵに置き換えることができ、ＭＵ ＰＰＤＵ内の各フレームは、異なるＲＵの代わりに異なる空間ストリームを通じて送信される。ＭＵ ＰＰＤＵのＡＣＫ又はＢＡなどの求められるフィードバックも、ＭＵ ＭＩＭＯ ＰＰＤＵに必要なフィードバックに変更される。

送信６７２及び６７４は、それぞれのプリアンブル６３４及び６４２と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図４１に、ＡＰ１がＴＸＯＰ共有の時間を制限する実施形態例７１０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

図３６に示すＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、ＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、最初にＡＣ＿ＶＩ（１）として例示するからのＲＴＡフレームをＡＣ＿ＶＩキューＳＴＡ１に送信する（７１２）。次に、ＡＰ１は、ＡＣ＿ＶＯ（１）として例示するＡＣ＿ＶＯキューからのＲＴＡフレームをＳＴＡ２に送信する（７１６）。ＡＰ１は、フレームＡＣ＿ＶＯの送信を終えた後に、現在のＴＸＯＰ中の最大ＴＸＯＰ共有時間７１４を利用し終える。

次に、ＡＰ１は、ＡＣ＿ＶＩ（２）として例示するＡＣ＿ＶＩキューからのフレームをＳＴＡ１に送信する（７１８）。

送信７１２、７１４及び７１８は、それぞれのプリアンブル６３２と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

図４２に、プライマリＡＣからのフレームを一定数送信した後にＡＰ１がＴＸＯＰを共有する実施形態例７５０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

図３６に示すＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、ＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

図示のように、ＡＰ１は、そのＴＸＯＰを送信のために共有する前に、ＴＸＯＰの開始後にｄｅｄｉｃａｔｅｄ＿ｂｙｔｅで示すプライマリＡＣ ＶＩからの一定量のフレームを送信する必要がある。ＡＰ１は、たとえプライマリＡＣからの未送信フレームが存在する場合でも、プライマリＡＣからのフレームの総バイトがｄｅｄｉｃａｔｅｄ＿ｂｙｔｅを超えた後に非プライマリＡＣからのＲＴＡフレームとＴＸＯＰを共有することができる。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、最初にＡＣ＿ＶＩ（１）及びＡＣ＿ＶＩ（２）として例示するＡＣ＿ＶＩキューからのＲＴＡフレームをＳＴＡ１に送信する（７５４及び７５６）。その後、ＡＰ１は、ＴＸＯＰ中にプライマリＡＣ ＶＩからのフレームを送信するのに専用時間よりも多くを費やす。その後、ＡＰ１は、ＴＸＯＰを共有して、ＡＣ＿ＶＯ（１）として例示するＡＣ＿ＶＯキューからのＲＴＡフレームを送信する（７５８）。

ＡＰ１は、各ＳＴＡの専用時間を設定するために、図４４に示すような情報を搬送するフレームを送信することができる。

送信７５４、７５６及び７５８はそれぞれのプリアンブル６３２と共に示しており、各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

ＡＰ１は、プライマリフレームのｄｅｄｉｃａｔｅｄ＿ｂｙｔｅに達する前に、ＩＥＥＥ８０２．１１で定められるルールに従ってＴＸＯＰを共有することができる。

図４３に、ＡＰ１がプライマリＡＣからのフレームを一定時間にわたって送信した後にＴＸＯＰを共有する実施形態例７９０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

図３６に示すＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、ＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

図示のように、ＴＸＯＰの開始以降、プライマリＡＣ ＶＩの専用時間７９２が存在する。ＡＰ１は、たとえプライマリＡＣからの未送信フレームが存在する場合でも、専用時間の終了後にＴＸＯＰを共有して非プライマリＡＣからのＲＴＡフレームを送信することができる。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、最初にＡＣ＿ＶＩ（１）、ＡＣ＿ＶＩ（２）として例示するＡＣ＿ＶＩキューからのＲＴＡフレーム７９４及び７９６をＳＴＡ１に送信する。その後、ＡＰ１は、ＴＸＯＰ中にプライマリＡＣ ＶＩからのフレームを送信するのに専用時間７９２よりも多くを費やす。その後、ＡＰ１は、ＴＸＯＰを共有して、ＡＣ＿ＶＯ（１）として例示するＡＣ＿ＶＯキューからのＲＴＡフレームをＳＴＡ２に送信する（７９８）。

なお、ＡＰ１は、各ＳＴＡの専用時間を設定するために、図４４に示すような情報を搬送するフレームを送信することができる。

送信７９４、７９６及び７９８は、それぞれのプリアンブル６３２と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

ＡＰ１は、ｄｅｄｉｃａｔｅｄ＿ｔｉｍｅの有効期限切れ前に、ＩＥＥＥ８０２．１１で定められるルールに従ってＴＸＯＰを共有することができる。

図４４に、専用時間パラメータ設定を搬送するフレームの実施形態例８３０を示す。ＡＰなどの１つのＳＴＡは、関連するＳＴＡなどの別のＳＴＡに与えられる専用時間の量を設定するために、この時間パラメータ設定を含むフレームをそのＳＴＡに送信することができる。いくつかの事例では、ＡＰが、その関連する全てのＳＴＡの専用時間を設定するためにこのようなフレームをブロードキャストすることもできる。

少なくとも１つの実施形態では、専用時間パラメータが以下のフィールドを含む。フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。期間（Ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。アドレス１（Ａｄｄｒｅｓｓ １）フィールドは、フレームの受信者のアドレスを含む。アドレス２（Ａｄｄｒｅｓｓ ２）フィールドは、フレームを送信したＳＴＡのアドレスを含む。アドレス３（Ａｄｄｒｅｓｓ ３）フィールドはＢＳＳＩＤを含む。シーケンス制御（Ｓｅｑｕｅｎｃｅ ｃｏｎｔｒｏｌ）フィールドは、フレームのシーケンス番号を示す。ＨＴ制御（ＨＴ ｃｏｎｔｒｏｌ）フィールドは、フレームのためのさらなる制御情報を示す。

専用時間設定（Ｄｅｄｉｃａｔｅｄ Ｔｉｍｅ Ｓｅｔ）フィールドは、ＳＴＡによって受信側ＳＴＡの各ＡＣの専用時間の量に設定される。受信側ＳＴＡは、このフィールド内のパラメータをＴＸＯＰ共有に利用することができる。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを識別し、この事例では専用時間設定要素である。長さ（Ｌｅｎｇｔｈ）フィールドは、専用時間設定要素の長さを示す。

ＬＬＴＳ ＴＸＯＰ共有（ＬＬＴＳ ＴＸＯＰ ｓｈａｒｉｎｇ）フィールドは、共有ルールを示すように設定される。少なくとも１つの実施形態では、このフィールドを、受信側ＳＴＡが非プライマリＡＣからのＲＴＡフレームを送信するために５．４．１節で説明したようなルールを使用してＴＸＯＰを共有できることを示すために第１の状態（例えば、「１」）に設定される１ビットフィールドとすることができる。そうでなければ、このフィールドは第２の状態（例えば、「０」）に設定され、受信側ＳＴＡは、ＩＥＥＥ８０２．１１で定められるＴＸＯＰ共有ルールのみに従う。

専用時間有効化（Ｅｎａｂｌｅ Ｄｅｄｉｃａｔｅｄ Ｔｉｍｅ）フィールドは、各ＴＸＯＰ中に専用時間が存在するかどうかを示すように設定される。このフィールドが第１の状態（例えば、真）に設定された場合には、例えばＴＸＯＰの先頭からマーキングするような専用時間が各ＴＸＯＰ中に存在する。専用時間中には、プライマリＡＣからのトラフィックのみを送信することができる。

専用時間（Ｄｅｄｉｃａｔｅｄ Ｔｉｍｅ）フィールドは、送信側ＳＴＡによって各ＡＣのために設定される。この専用時間情報を受け取ったＳＴＡは、ＴＸＯＰ開始時刻から開始するＡＣの専用時間をそのＡＣからのフレームの送信に費やす。受信側ＳＴＡは、その後にようやくＴＸＯＰを共有すると決定することができる。

なお、図４２で説明したように、「専用時間」は、専用バイトパラメータを設定するためにフレーム内で「専用バイト」に置き換えることもできる。

図４５に、ＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態の第４の実施例を示す実施形態例８５０を示す。フレームは、図示のようなキュー内にマッピングされる（８５２）。ＡＣ＿ＶＯキュー８５４は、ＬＬＴＳ１下のＡＣ＿ＶＯ（１）及びＬＬＴＳ６下のＡＣ＿ＶＯ（２）として例示する２つのＲＴＡフレームを搬送する。ＡＣ＿ＶＩキュー８５６は、ＡＣ＿ＶＩ（１）として例示するＬＬＴＳ２下の１つのＲＴＡフレームと、ＡＣ＿ＶＩ（２）として例示する１つの非ＲＴＡフレームとを保持する。ＡＣ＿ＢＥキュー８５８はＡＣ ＢＥのＥＤＣＡキューを表し、ＡＣ＿ＢＥ（１）～ＡＣ＿ＢＥ（３）として例示する３つの非ＲＴＡフレームを保持する。ＡＣ＿ＢＫキュー８６０は、そのキュー内にフレームが存在しない。

各キューの下方には、チャネル８７０を取得してチャネル８７０上で送信するためのそれぞれのＥＤＣＡ機能８６２、８６４、８６６及び８６８を示す。

図４６に、ＡＰ１がＭＵ ＯＦＤＭＡ ＰＰＤＵを送信し、各ユーザについて非プライマリＡＣからのＲＴＡフレームがプライマリＡＣからのフレームよりも早く送信される実施形態例８９０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

図４５に示すＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、図示のＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、ＡＣ＿ＶＯ（１）及びＡＣ＿ＶＯ（２）として例示するＡＣ＿ＶＯキューからＳＴＡ１及びＳＴＡ２へのＲＴＡフレームと、ＡＣ＿ＢＥ（２）として例示するＡＣ＿ＢＥキューからＳＴＡ３への非ＲＴＡフレームとを搬送するＭＵ ＯＦＤＭＡ ＰＰＤＵを送信する（８９２）。

次に、ＡＰ１は、ＲＴＡフレームＡＣ＿ＶＩ（１）及びＡＣ＿ＶＩ（２）と非ＲＴＡフレームＡＣ＿ＢＥ（３）とを搬送する別のＭＵ ＯＦＤＭ ＰＰＤＵをＳＴＡ１、ＳＴＡ２及びＳＴＡ３にそれぞれ送信する（８９４）。ＳＴＡ１、ＳＴＡ２については、ＡＰ１が、ＡＣ ＶＯとして例示する優先度の高い非プライマリＡＣからのＲＴＡフレームを最初に送信する。

この例に示すＭＵ ＯＦＤＭＡ ＰＰＤＵは、ＭＵ ＭＩＭＯ ＰＰＤＵに置き換えることができ、この場合、ＭＵ ＰＰＤＵの各フレームは、異なるＲＵの代わりに異なる空間ストリームを通じて送信される。求められるフィードバックも、ＭＵ ＰＰＤＵのＡＣＫ又はＢＡから図中のＭＵ ＭＩＭＯ ＰＰＤＵに適したフィードバックに変更される。

送信８９２及び８９４は、それぞれのプリアンブル６３２と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

なお、ＡＰ１は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

図４７に、ＭＵ ＰＰＤＵにおいてＡＰが非プライマリＡＣからのＲＴＡフレームをプライマリＡＣからのＲＴＡフレームよりも遅く、ただし各ユーザについてプライマリＡＣからの非ＲＴＡフレームよりも早く送信する際のＴＸＯＰ共有の実施形態例９３０を示す。この図には、ＴＸＯＰ４００中におけるＡＰ１ ３９２、ＳＴＡ１ ３９４、ＳＴＡ２ ３９６及びＳＴＡ３ ３９６間の相互作用を示す。

図示のＡＰ１は、ＭＵ ＯＦＤＭＡ ＰＰＤＵを送信する（９３２）ことで、各ユーザについて最初にプライマリＡＣからのＲＴＡフレームを送信し、次に高優先度ＡＣからのＲＴＡフレームを送信し、その後にプライマリＡＣからの非ＲＴＡフレームを送信する。

図４５に示すＡＰ１又はＭＬＤ１のＥＤＣＡキュー状態は、ＡＰ１がＴＸＯＰ４００を開始した時のキュー状態を想定するとともに、ＥＤＣＡ ＴＸＯＰ中に新たなフレームが到着しないと想定する。さらに、キュー状態がＭＬＤ１のものである場合、例示するＴＸＯＰ中にＭＬＤ１は他のリンク上で送信を行わないと想定する。

ＡＰ１は、ＶＩのＴＸＯＰ４００を取得すると、ＡＣ＿ＶＩ（１）及びＡＣ＿ＶＯ（１）として例示するＲＴＡフレームと、ＡＣ＿ＢＥ（２）として例示するＡＣ＿ＢＥキューからの非ＲＴＡフレームとを含むＭＵ ＯＦＤＭＡ ＰＰＤＵを送信する（９３２）。

次にＡＰ１は、ＲＴＡフレームＡＣ＿ＶＯ（２）及びＡＣ＿ＶＩ（２）と非ＲＴＡフレームＡＣ＿ＢＥ（３）とを含む別のＭＵ ＯＦＤＭ ＰＰＤＵを送信する（９３４）。ＡＰ１は、ユーザＳＴＡ１に対し、最初にＡＣ ＶＩとして例示するプライマリＡＣからのＲＴＡフレームを送信し、次にＡＣ＿ＶＯとして例示する優先度の高い非プライマリＡＣからのＲＴＡフレームを送信する。ＡＰ１は、ユーザＳＴＡ２に対し、最初にＡＣ＿ＶＯなどの優先度の高い非プライマリＡＣからのＲＴＡフレームを送信し、次にＡＣ＿ＶＩなどのプライマリＡＣからの非ＲＴＡフレームを送信する。

この例に示すＭＵ ＯＦＤＭＡ ＰＰＤＵは、ＭＵ ＭＩＭＯ ＰＰＤＵに置き換えることができ、この場合、ＭＵ ＰＰＤＵの各フレームは、異なるＲＵの代わりに異なる空間ストリームを通じて送信される。ＭＵ ＰＰＤＵのＡＣＫ又はＢＡなどの求められるフィードバックも、ＭＵ ＭＩＭＯ ＰＰＤＵに適したタイプのフィードバックに変更される。

送信９３２及び９３４は、それぞれのプリアンブル６３２と共に示す。各受信側の局は、これらの送信の受信にブロック確認応答（ＢＡ）６４０で応答する。

なお、ＡＰ（例えば、ＡＰ１）は、フレームを送信する前にＲＴＳ／ＣＴＳ又はＭＵ－ＲＴＳ／ＣＴＳを利用してＴＸＯＰを予約することができる。

６．実施形態の一般的範囲
本明細書では、コンピュータプログラム製品としても実装できる、本技術の実施形態による方法及びシステム、及び／又は手順、アルゴリズム、ステップ、演算、数式又はその他の計算表現のフローチャートを参照して本技術の実施形態を説明することができる。この点、フローチャートの各ブロック又はステップ、及びフローチャートのブロック（及び／又はステップ）の組み合わせ、並びにいずれかの手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、ハードウェア、ファームウェア、及び／又はコンピュータ可読プログラムコードの形で具体化された１又は２以上のコンピュータプログラム命令を含むソフトウェアなどの様々な手段によって実装することができる。理解されるように、このようないずれかのコンピュータプログラム命令は、以下に限定されるわけではないが、汎用コンピュータ又は専用コンピュータ、又は機械を生産するための他のいずれかのプログラマブル処理装置を含む１又は２以上のコンピュータプロセッサによって実行して、コンピュータプロセッサ又は他のプログラマブル処理装置上で実行されるコンピュータプログラム命令が、（単複の）特定される機能を実施するための手段を生み出すようにすることができる。

従って、本明細書で説明したフローチャートのブロック、並びに手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、（単複の）特定の機能を実行する手段の組み合わせ、（単複の）特定の機能を実行するステップの組み合わせ、及びコンピュータ可読プログラムコードロジック手段の形で具体化されるような、（単複の）特定の機能を実行するコンピュータプログラム命令をサポートする。また、本明細書で説明したフローチャートの各ブロック、並びにいずれかの手順、アルゴリズム、ステップ、演算、数式、又は計算表現、及びこれらの組み合わせは、（単複の）特定の機能又はステップを実行する専用ハードウェアベースのコンピュータシステム、又は専用ハードウェアとコンピュータ可読プログラムコードとの組み合わせによって実装することもできると理解されるであろう。

さらに、コンピュータ可読プログラムコードなどの形で具体化されるこれらのコンピュータプログラム命令を、コンピュータプロセッサ又は他のプログラマブル処理装置に特定の態様で機能するように指示することができる１又は２以上のコンピュータ可読メモリ又はメモリ装置に記憶して、これらのコンピュータ可読メモリ又はメモリ装置に記憶された命令が、（単複の）フローチャートの（単複の）ブロック内に指定される機能を実施する命令手段を含む製造の物品を生産するようにすることもできる。コンピュータプログラム命令をコンピュータプロセッサ又は他のプログラマブル処理装置によって実行し、コンピュータプロセッサ又は他のプログラマブル処理装置上で一連の動作ステップが実行されるようにしてコンピュータで実施される処理を生成し、コンピュータプロセッサ又は他のプログラマブル処理装置上で実行される命令が、（単複の）フローチャートの（単複の）ブロック、（単複の）手順、（単複の）アルゴリズム、（単複の）ステップ、（単複の）演算、（単複の）数式、又は（単複の）計算表現に特定される機能を実施するためのステップを提供するようにすることもできる。

さらに、本明細書で使用する「プログラム」又は「プログラム実行文」という用語は、本明細書で説明した１又は２以上の機能を実行するために１又は２以上のコンピュータプロセッサが実行できる１又は２以上の命令を意味すると理解されるであろう。命令は、ソフトウェア、ファームウェア、又はソフトウェアとファームウェアとの組み合わせで具体化することができる。命令は、装置の非一時的媒体に局所的に記憶することも、又はサーバなどに遠隔的に記憶することもでき、或いは命令の全部又は一部を局所的に又は遠隔的に記憶することもできる。遠隔的に記憶された命令は、ユーザが開始することによって、或いは１又は２以上の要因に基づいて自動的に装置にダウンロード（プッシュ）することができる。

さらに、本明細書で使用するプロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、中央処理装置（ＣＰＵ）及びコンピュータという用語は、命令、並びに入力／出力インターフェイス及び／又は周辺装置との通信を実行できる装置を示すために同義的に使用されるものであり、プロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、ＣＰＵ及びコンピュータという用語は、単一の又は複数の装置、シングルコア装置及びマルチコア装置、及びこれらの変種を含むように意図するものであると理解されるであろう。

本明細書の説明から、本開示は、限定ではないが以下の内容を含む複数の技術実装を含むと理解されるであろう。

ネットワークにおける無線通信のための装置であって、（ａ）アクセスポイント（ＡＰ）無線局（ＳＴＡ）又は非ＡＰ ＳＴＡのいずれかとして動作するＳＴＡとして、複数のアクセスカテゴリ（ＡＣ）に拡張分散チャネルアクセス（ＥＤＣＡ）が適用される無線ローカルエリアネットワーク（ＷＬＡＮ）上で、ＡＰ又は非ＡＰ ＳＴＡのいずれかである他の無線局（ＳＴＡ）と、チャネルを介して、フレームを搬送するパケットを無線で通信するように構成された無線通信回路と、（ｂ）前記無線通信回路に結合されてＷＬＡＮ上でＳＴＡとして動作するプロセッサと、（ｃ）プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリとを備え、（ｄ）前記命令は、プロセッサによって実行された時に、（ｄ）（ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィックを非ＲＴＡトラフィックと区別することと、（ｄ）（ｉｉ）プライマリＡＣの送信機会（ＴＸＯＰ）を取得することと、（ｄ）（ｉｉｉ）たとえＴＸＯＰ中にプライマリＡＣからの未送信のフレームが存在する可能性がある場合でも、ＴＸＯＰチャネルリソースの残り部分を利用して非プライマリＡＣからのＲＴＡフレームを送信することと、を含む１又は２以上のステップを実行する、装置。

ネットワークにおける無線通信のための装置であって、（ａ）アクセスポイント（ＡＰ）無線局（ＳＴＡ）又は非ＡＰ ＳＴＡのいずれかとして動作するＳＴＡとして、複数のアクセスカテゴリ（ＡＣ）に拡張分散チャネルアクセス（ＥＤＣＡ）が適用される無線ローカルエリアネットワーク（ＷＬＡＮ）上で、ＡＰ又は非ＡＰ ＳＴＡのいずれかである他の無線局（ＳＴＡ）と、チャネルを介して、フレームを搬送するパケットを無線で通信するように構成された無線通信回路と、（ｂ）前記無線通信回路に結合されてＷＬＡＮ上でＳＴＡとして動作するプロセッサと、（ｃ）プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリとを備え、（ｄ）前記命令は、プロセッサによって実行された時に、（ｄ）（ｉ）非ＡＰ ＭＬＤとＡＰ ＭＬとの間のトラフィックストリームを設定するために、サービス品質（ＱｏＳ）要件の仕様及びトラフィックフローの上位層情報を交換することと、（ｄ）（ｉｉ）トラフィックストリームと同じトラフィック識別子（ＴＩＤ）を有する他のトラフィックストリームとを区別するために、非ＡＰ ＭＬＤ又はＡＰ ＭＬＤがトラフィックストリームに低遅延識別（ＬＬＩＤ）を割り当てることと、（ｄ）（ｉｉｉ）非ＡＰ ＭＬＤ及び／又はＡＰ ＭＬＤがどの１又は複数のリンクを通じてトラフィックストリームを送信すべきであるかを決定することと、（ｄ）（ｉｖ）非ＡＰ ＭＬＤ及び／又はＡＰ ＭＬＤがトラフィックストリームに属するトラフィックを他のトラフィックと区別することと、を含む１又は２以上のステップを実行する、装置。

ネットワークにおける無線通信方法であって、装置は、（ａ）複数のアクセスカテゴリ（ＡＣ）に拡張分散チャネルアクセス（ＥＤＣＡ）が適用される無線ローカルエリアネットワーク（ＷＬＡＮ）上で、アクセスポイント（ＡＰ）又は非ＡＰ無線局（ＳＴＡ）のいずれかとして動作するＳＴＡから、ＡＰ又は非ＡＰ ＳＴＡのいずれかである他の無線局（ＳＴＡ）にチャネルを介して通信することと、（ｂ）リアルタイムアプリケーション（ＲＴＡ）トラフィックを非ＲＴＡトラフィックと区別することと、（ｃ）プライマリＡＣの送信機会（ＴＸＯＰ）を取得することと、（ｄ）たとえＴＸＯＰ中にプライマリＡＣからの未送信のフレームが存在する場合でも、チャネルリソースの残り部分を利用して非プライマリＡＣからのＲＴＡフレームを送信することと、を含む方法。

前記命令は、プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために最低限必要なチャネルリソースがチャネルリソース内で利用可能であることを保証することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

プライマリＡＣからのフレームを送信するために最低限必要なチャネルリソースを確保しているＳＴＡは、プライマリＡＣからの全てのフレームの送信が完了した場合に、最低限必要なチャネルリソースをＴＸＯＰ共有に利用することができる、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために最低限必要なチャネルリソースをＳＴＡが設定しないことをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣから所与の最小バイト数が送信されることをＳＴＡが保証することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために必要な最低限のチャネル時間が与えられることをＳＴＡが保証することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、たとえＴＸＯＰ中にプライマリＡＣからのフレームが送信されなかった場合でも、ＳＴＡが非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、プライマリＡＣからの全てのＲＴＡフレームが送信された場合にのみ、ＳＴＡがＴＸＯＰ中に非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＳＴＡが、プライマリＡＣからのＲＴＡフレームを送信する前に、ＴＸＯＰ中により優先度の高い非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＳＴＡがＴＸＯＰ中に優先度の低い非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、プライマリＡＣからのＲＴＡフレームの送信要件及び／又は遅延要件によって長さが決まるＭＵ ＰＰＤＵパケットをＳＴＡが送信することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＳＴＡがＴＸＯＰ共有の時間を制限することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、非プライマリＡＣからのＲＴＡフレームの有効期限が迫っている場合にのみ、これらのＲＴＡフレームをプライマリＡＣからのフレームよりも早く送信することをＳＴＡが許可することをさらに含むステップを実行する、先行するいずれかの実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＳＴＡがプライマリＡＣのＴＸＯＰを取得して、ＴＸＯＰを優先度の低い非プライマリＡＣと共有することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、非ＡＰ ＭＬＤが、ＡＰ ＭＬＤにトラフィックストリームを設定するように要求する際に、トラフィックフローの仕様、ＱｏＳ要件、上位層情報及びＬＬＩＤを含むフレームをＡＰ ＭＬＤに送信することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＡＰ ＭＬＤが、トラフィックストリームを設定するための要求に対し、要求を容認したかそれとも拒絶したかを示すために、トラフィックフローの仕様、ＱｏＳ要件、上位層情報、ＬＬＩＤ及び状態を含むフレームで非ＡＰ ＭＬＤに応答することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤが、ＩＥＥＥ８０２．１１ａｘで定められる、さらなるＱｏＳ要件を含むように構成されたトラフィック仕様（ＴＳＰＥＣ）要素を使用することにより、トラフィックフローの仕様、ＱｏＳ要件の交換を実行することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記さらなるＱｏＳ要件は、ジッタ及びパケット損失要件を含む、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤが異なるリンクを介してフレームを送信することによってトラフィックフロー情報を交換することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤが非ＡＰ ＭＡＣアドレス及びＬＬＩＤを含むタプルを通信したことに応答して、１つのトラフィックストリームを他のトラフィックストリームと区別することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

前記命令は、プロセッサによって実行された時に、既存のトラフィックストリームを終了又は修正するためにＡＰ ＭＬＤが未承諾フレームを送信することをさらに含むステップを実行する、いずれかの先行する実装の装置又は方法。

本明細書で使用する「実装」という用語は、本明細書で説明する技術を実践するための実施形態、実施例、又はその他の形態を制限なく含むように意図される。

本明細書で使用する単数形の「ａ、ａｎ（英文不定冠詞）」及び「ｔｈｅ（英文定冠詞）」は、文脈において別途明確に示されていない限り複数形の照応を含む。ある物体に対する単数形での言及は、明確にそう述べていない限り「唯一」を意味するものではなく、「１又は２以上」を意味する。

本開示における「Ａ、Ｂ及び／又はＣ」などの表現構造は、Ａ、Ｂ又はＣのいずれか、或いは項目Ａ、Ｂ及びＣのいずれかの組み合わせが存在し得ることを表す。「～のうちの少なくとも１つ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ）」の後にリストされた一群の要素が続くものなどを示す表現構造は、該当する際にはこれらのリストされた要素のいずれかの考えられる組み合わせを含む、これらの一群の要素のうちの少なくとも１つが存在することを示す。

本開示における「ある実施形態」、「少なくとも１つの実施形態」又は同様の実施形態という言い回しについて言及する参照は、説明する実施形態に関連して説明した特定の特徴、構造又は特性が本開示の少なくとも１つの実施形態に含まれることを示す。従って、これらの様々な実施形態の表現は、必ずしも全てが同じ実施形態、又は説明されている他の全ての実施形態とは異なる特定の実施形態を意味するわけではない。実施形態という表現は、所与の実施形態の特定の特徴、構造又は特性を、開示する装置、システム又は方法の１又は２以上の実施形態においていずれかの好適な形で組み合わせることができることを意味するものとして解釈すべきである。

本明細書で使用する「組（ｓｅｔ）」という用語は、１又は２以上の物体の集合を意味する。従って、例えば物体の組は、単一の物体又は複数の物体を含むことができる。

本文書における第１及び第２、頂部及び底部などの関係語は、１つの実体又は行動を別の実体又は行動と区別するために使用しているにすぎず、必ずしもこのような実体又は行動同士のこのようないずれかの実際の関係又は順序を必要としたり、又は意味したりするものではない。

「備える、有する、含む（ｃｏｍｐｒｉｓｅｓ、ｃｏｍｐｒｉｓｉｎｇ、ｈａｓ、ｈａｖｉｎｇ、ｉｎｃｌｕｄｅｓ、ｉｎｃｌｕｄｉｎｇ、ｃｏｎｔａｉｎｓ、ｃｏｎｔａｉｎｉｎｇ）」という用語、又はこれらの用語の他のあらゆる変化形は、非排他的包含を含むことが意図されており、従って、ある要素リストを備える、有する又は含むプロセス、方法、物品又は装置は、これらの要素のみを含むのではなく、明示的に列挙していない、又はこのようなプロセス、方法、物品又は装置に特有の他の要素を含むこともできる。「～を備える、有する、又は含む（ｃｏｍｐｒｉｓｅｓ … ａ、ｈａｓ … ａ、ｉｎｃｌｕｄｅｓ … ａ、ｃｏｎｔａｉｎｓ … ａ）」に続く要素は、その要素を備える、有する又は含むプロセス、方法、物品又は装置にさらなる同一要素が存在することを、さらなる制約を受けることなく除外するものではない。

本明細書で使用する「近似的に（ａｐｐｒｏｘｉｍａｔｅｌｙ）」、「近似する（ａｐｐｒｏｘｉｍａｔｅ）」、「実質的に（ｓｕｂｓｔａｎｔｉａｌｌｙ）」、「基本的に（ｅｓｓｅｎｔｉａｌｌｙ）」及び「約（ａｂｏｕｔ）」という用語、又はこれらのいずれかの変形形態は、わずかな変動の記述及び説明のために使用するものである。これらの用語は、事象又は状況に関連して使用した時には、これらの事象又は状況が間違いなく発生する場合、及びこれらの事象又は状況が発生する可能性が非常に高い場合を意味することができる。これらの用語は、数値に関連して使用した時には、その数値の±５％以下、±４％以下、±３％以下、±２％以下、±１％以下、±０．５％以下、±０．１％以下、又は±０．０５％以下などの、±１０％以下の変動範囲を意味することができる。例えば、「実質的に」整列しているということは、±５°以下、±４°以下、±３°以下、±２°以下、±１°以下、±０．５°以下、±０．１°以下、又は±０．０５°以下などの、±１０°以下の角度変動範囲を意味することができる。

また、本明細書では、量、比率及びその他の数値を範囲形式で示すこともある。このような範囲形式は、便宜的に単純化して使用するものであり、範囲の限界として明確に指定された数値を含むが、この範囲に含まれる全ての個々の数値又は部分的範囲も、これらの各数値及び部分的範囲が明確に示されているかのように含むものであると柔軟に理解されたい。例えば、約１～約２００の範囲内の比率は、約１及び約２００という明確に列挙した限界値を含むが、約２、約３、約４などの個々の比率、及び約１０～約５０、約２０～約１００などの部分的範囲も含むと理解されたい。

本明細書で使用する「結合される（ｃｏｕｐｌｅｄ）」という用語は、「接続される」と定義されるが、必ずしも直接的な機械的接続ではない。特定の形で「構成される（ｃｏｎｆｉｇｕｒｅｄ）」装置又は構造は、少なくともその形で構成されるが、列挙していない形で構成することもできる。

利点、長所、問題解決手段、及びいずれかの利点、長所又は解決手段を生じさせる、又はより顕著にするいずれかの（単複の）要素は、本明細書で説明した技術、或いは一部又は全部の請求項の重要な、必要な又は不可欠な特徴又は要素として解釈すべきでない。

また、上述した開示では、開示を合理化する目的で様々な実施形態において様々な特徴を共にグループ化することができる。本開示の方法は、請求項に記載する実施形態が、各請求項に明示的に記載する特徴よりも多くの特徴を必要とするという意図を反映したものであると解釈すべきではない。本発明の主題は、開示した単一の実施形態の全ての特徴よりも少ないものによって成立することができる。

本開示の要約書は、読者が技術開示の本質を素早く確認できるように示すものである。要約書は、特許請求の範囲又はその意味を解釈又は限定するために使用されるものではないという理解の下で提示するものである。

管轄によっては、出願後に本開示の１又は２以上の部分の削除を求める慣行もあると理解されたい。従って、読者は、本開示の元々の内容については出願日時点の出願を参照すべきである。開示内容のいずれかの削除は、当初出願時の出願のいずれかの主題の放棄、失権又は公衆への献呈として解釈すべきではない。

以下の特許請求の範囲は、各請求項が単独の発明主題として自立した状態で本開示に組み込まれる。

本明細書の説明は多くの詳細を含んでいるが、これらは本開示の範囲を限定するものではなく、現在のところ好ましい実施形態の一部を例示するものにすぎないと解釈すべきである。従って、本開示の範囲は、当業者に明らかになると考えられる他の実施形態も完全に含むと理解されるであろう。

当業者に周知の本開示の実施形態の要素の構造的及び機能的同等物も、引用によって本明細書に明確に組み入れられ、本特許請求の範囲に含まれるように意図される。さらに、本開示の要素、構成要素又は方法ステップは、これらが特許請求の範囲に明示されているかどうかにかかわらず、一般に公開されるように意図するものではない。本明細書における請求項の要素については、その要素が「～のための手段」という表現を使用して明確に示されていない限り、「ミーンズプラスファンクション」の要素として解釈すべきではない。また、本明細書における請求項の要素については、その要素が「～のためのステップ」という表現を使用して明確に示されていない限り、「ステッププラスファンクション」の要素として解釈すべきではない。

３３０ 実施形態例
３３２ ＳＴＡがプライマリＡＣによって表されるＡＣのＴＸＯＰを取得し、（単複の）非プライマリＡＣとＴＸＯＰを共有することを決定
３３４ ＳＴＡが（単複の）非プライマリＡＣからのフレームを送信するためにＴＸＯＰを共有すると決定したか？
３３６ ＳＴＡは、ＩＥＥＥ８０２．１１ａｘで定められる非ＲＴＡフレームのためのＴＸＯＰ共有ルールに従う
３３８ ＳＴＡは、送信すべきプライマリＡＣからのフレームが存在するか否かにかかわらず非プライマリＡＣからのＲＴＡフレームを送信できる
３４０ ＳＴＡが、ＴＸＯＰ中に（単複の）非プライマリＡＣからのフレームを送信


表１
ユーザ優先度－（ＵＰ）マッピング

表２
デフォルトパラメータ設定

表３
MLME-LLTS要求

表４
MLME-LLTS.indication

表５
MLME-LLTS.response

表６
MLME-LLTS.confirm

表７
MLME-LLTS-TERM.request

表８
MLME-LLTS-TERM.indication

表9
LLTS例

Claims (23)

1. ネットワークにおける無線通信のための装置であって、
   （ａ）アクセスポイント（ＡＰ）無線局（ＳＴＡ）又は非ＡＰ ＳＴＡのいずれかとして動作するＳＴＡとして、複数のアクセスカテゴリ（ＡＣ）に拡張分散チャネルアクセス（ＥＤＣＡ）が適用される無線ローカルエリアネットワーク（ＷＬＡＮ）上で、ＡＰ又は非ＡＰ ＳＴＡのいずれかである他の無線局（ＳＴＡ）と、チャネルを介して、フレームを搬送するパケットを無線で通信するように構成された無線通信回路と、
   （ｂ）前記無線通信回路に結合されてＷＬＡＮ上でＳＴＡとして動作するプロセッサと、
   （ｃ）前記プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリと、
   を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、
   （ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィックを非ＲＴＡトラフィックと区別することと、
   （ｉｉ）プライマリＡＣの送信機会（ＴＸＯＰ）を取得することと、
   （ｉｉｉ）たとえＴＸＯＰ中にプライマリＡＣからの未送信のフレームが存在する可能性がある場合でも、ＴＸＯＰチャネルリソースの残り部分を利用して非プライマリＡＣからのＲＴＡフレームを送信することと、
   を含む１又は２以上のステップを実行する、
   ことを特徴とする装置。
2. 前記命令は、前記プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために最低限必要なチャネルリソースがチャネルリソース内で利用可能であることを保証することをさらに含むステップを実行する、
   請求項１に記載の装置。
3. プライマリＡＣからのフレームを送信するために最低限必要なチャネルリソースを確保しているＳＴＡは、プライマリＡＣからの全てのフレームの送信が完了した場合に、前記最低限必要なチャネルリソースをＴＸＯＰ共有に利用することができる、
   請求項２に記載の装置。
4. 前記命令は、前記プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために最低限必要なチャネルリソースを前記ＳＴＡが設定しないことをさらに含むステップを実行する、
   請求項１に記載の装置。
5. 前記命令は、前記プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣから所与の最小バイト数が送信されることを前記ＳＴＡが保証することをさらに含むステップを実行する、
   請求項１に記載の装置。
6. 前記命令は、前記プロセッサによって実行された時に、ＴＸＯＰ中にプライマリＡＣからのフレームを送信するために必要な最低限のチャネル時間が与えられることを前記ＳＴＡが保証することをさらに含むステップを実行する、
   請求項１に記載の装置。
7. 前記命令は、前記プロセッサによって実行された時に、たとえＴＸＯＰ中にプライマリＡＣからのフレームが送信されなかった場合でも、前記ＳＴＡが非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、
   請求項１に記載の装置。
8. 前記命令は、前記プロセッサによって実行された時に、プライマリＡＣからの全てのＲＴＡフレームが送信された場合にのみ、前記ＳＴＡがＴＸＯＰ中に非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、
   請求項１に記載の装置。
9. 前記命令は、前記プロセッサによって実行された時に、前記ＳＴＡが、プライマリＡＣからのＲＴＡフレームを送信する前に、ＴＸＯＰ中により優先度の高い非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、
   請求項１に記載の装置。
10. 前記命令は、前記プロセッサによって実行された時に、前記ＳＴＡがＴＸＯＰ中に優先度の低い非プライマリＡＣからのＲＴＡフレームを送信することをさらに含むステップを実行する、
    請求項１に記載の装置。
11. 前記命令は、前記プロセッサによって実行された時に、プライマリＡＣからのＲＴＡフレームの送信要件及び／又は遅延要件によって長さが決まるＭＵ ＰＰＤＵパケットを前記ＳＴＡが送信することをさらに含むステップを実行する、
    請求項１に記載の装置。
12. 前記命令は、前記プロセッサによって実行された時に、前記ＳＴＡがＴＸＯＰ共有の時間を制限することをさらに含むステップを実行する、
    請求項１に記載の装置。
13. 前記命令は、前記プロセッサによって実行された時に、非プライマリＡＣからのＲＴＡフレームの有効期限が迫っている場合にのみ、これらのＲＴＡフレームをプライマリＡＣからのフレームよりも早く送信することを前記ＳＴＡが許可することをさらに含むステップを実行する、
    請求項１に記載の装置。
14. 前記命令は、前記プロセッサによって実行された時に、前記ＳＴＡがプライマリＡＣのＴＸＯＰを取得して、前記ＴＸＯＰを優先度の低い非プライマリＡＣと共有することをさらに含むステップを実行する、
    請求項１に記載の装置。
15. ネットワークにおける無線通信のための装置であって、
    （ａ）アクセスポイント（ＡＰ）無線局（ＳＴＡ）又は非ＡＰ ＳＴＡのいずれかとして動作するＳＴＡとして、複数のアクセスカテゴリ（ＡＣ）に拡張分散チャネルアクセス（ＥＤＣＡ）が適用される無線ローカルエリアネットワーク（ＷＬＡＮ）上で、ＡＰ又は非ＡＰ ＳＴＡのいずれかである他の無線局（ＳＴＡ）と、チャネルを介して、フレームを搬送するパケットを無線で通信するように構成された無線通信回路と、
    （ｂ）前記無線通信回路に結合されてＷＬＡＮ上でＳＴＡとして動作するプロセッサと、
    （ｃ）前記プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリと、
    を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、
    （ｉ）非ＡＰ ＭＬＤとＡＰ ＭＬとの間のトラフィックストリームを設定するために、サービス品質（ＱｏＳ）要件の仕様及びトラフィックフローの上位層情報を交換することと、
    （ｉｉ）前記トラフィックストリームと同じトラフィック識別子（ＴＩＤ）を有する他のトラフィックストリームとを区別するために、前記非ＡＰ ＭＬＤ又はＡＰ ＭＬＤが前記トラフィックストリームに低遅延識別（ＬＬＩＤ）を割り当てることと、
    （ｉｉｉ）前記非ＡＰ ＭＬＤ及び／又はＡＰ ＭＬＤがどの１又は複数のリンクを通じて前記トラフィックストリームを送信すべきであるかを決定することと、
    （ｉｖ）前記非ＡＰ ＭＬＤ及び／又はＡＰ ＭＬＤが前記トラフィックストリームに属するトラフィックを他のトラフィックと区別することと、
    を含む１又は２以上のステップを実行する、
    ことを特徴とする装置。
16. 前記命令は、前記プロセッサによって実行された時に、前記非ＡＰ ＭＬＤが、前記ＡＰ ＭＬＤにトラフィックストリームを設定するように要求する際に、トラフィックフローの仕様、ＱｏＳ要件、上位層情報及びＬＬＩＤを含むフレームを前記ＡＰ ＭＬＤに送信することをさらに含むステップを実行する、
    請求項１５に記載の装置。
17. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰ ＭＬＤが、前記トラフィックストリームを設定するための前記要求に対し、前記要求を容認したかそれとも拒絶したかを示すために、トラフィックフローの仕様、ＱｏＳ要件、上位層情報、ＬＬＩＤ及び状態を含むフレームで前記非ＡＰ ＭＬＤに応答することをさらに含むステップを実行する、
    請求項１６に記載の装置。
18. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰ ＭＬＤ及び前記非ＡＰ ＭＬＤが、ＩＥＥＥ８０２．１１ａｘで定められる、さらなるＱｏＳ要件を含むように構成されたトラフィック仕様（ＴＳＰＥＣ）要素を使用することにより、前記トラフィックフローの仕様、ＱｏＳ要件の交換を実行することをさらに含むステップを実行する、
    請求項１７に記載の装置。
19. 前記さらなるＱｏＳ要件は、ジッタ及びパケット損失要件を含む、
    請求項１８に記載の装置。
20. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰ ＭＬＤ及び前記非ＡＰ ＭＬＤが異なるリンクを介してフレームを送信することによってトラフィックフロー情報を交換することをさらに含むステップを実行する、
    請求項１５に記載の装置。
21. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰ ＭＬＤ及び前記非ＡＰ ＭＬＤが非ＡＰ ＭＡＣアドレス及びＬＬＩＤを含むタプルを通信したことに応答して、１つのトラフィックストリームを他のトラフィックストリームと区別することをさらに含むステップを実行する、
    請求項１５に記載の装置。
22. 前記命令は、前記プロセッサによって実行された時に、既存のトラフィックストリームを終了又は修正するために前記ＡＰ ＭＬＤが未承諾フレームを送信することをさらに含むステップを実行する、
    請求項１５に記載の装置。
23. ネットワークにおける無線通信方法であって、前記装置は、
    （ａ）複数のアクセスカテゴリ（ＡＣ）に拡張分散チャネルアクセス（ＥＤＣＡ）が適用される無線ローカルエリアネットワーク（ＷＬＡＮ）上で、アクセスポイント（ＡＰ）又は非ＡＰ無線局（ＳＴＡ）のいずれかとして動作するＳＴＡから、ＡＰ又は非ＡＰ ＳＴＡのいずれかである他の無線局（ＳＴＡ）にチャネルを介して通信することと、
    （ｂ）リアルタイムアプリケーション（ＲＴＡ）トラフィックを非ＲＴＡトラフィックと区別することと、
    （ｃ）プライマリＡＣの送信機会（ＴＸＯＰ）を取得することと、
    （ｄ）たとえＴＸＯＰ中にプライマリＡＣからの未送信のフレームが存在する場合でも、チャネルリソースの残り部分を利用して非プライマリＡＣからのＲＴＡフレームを送信することと、
    を含むことを特徴とする方法。

Images