ホーム > 特許ランキング > ソニーグループ株式会社
知財求人 - 知財ポータルサイト「IP Force」
▶ ソニー株式会社の特許一覧 ▶ ソニー コーポレイション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-07-26
(54)【発明の名称】制限付きターゲットウェイクタイムサービス期間の終了
(51)【国際特許分類】
H04W 84/18 20090101AFI20240719BHJP
H04W 84/12 20090101ALI20240719BHJP
H04W 72/0446 20230101ALI20240719BHJP
H04W 74/0808 20240101ALI20240719BHJP
【ＦＩ】
H04W84/18
H04W84/12
H04W72/0446
H04W74/0808
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024508033
(86)(22)【出願日】2022-07-20
(85)【翻訳文提出日】2024-02-08
(86)【国際出願番号】 IB2022056657
(87)【国際公開番号】W WO2023017340
(87)【国際公開日】2023-02-16
(31)【優先権主張番号】63/260,155
(32)【優先日】2021-08-11
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/844,555
(32)【優先日】2022-06-20
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(71)【出願人】
【識別番号】504257564
【氏名又は名称】ソニー コーポレイション オブ アメリカ
(74)【代理人】
【識別番号】100092093
【弁理士】
【氏名又は名称】辻居 幸一
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100141553
【弁理士】
【氏名又は名称】鈴木 信彦
(72)【発明者】
【氏名】シン リャンシャオ
(72)【発明者】
【氏名】スン リ－シャン
(72)【発明者】
【氏名】シャー チン
(72)【発明者】
【氏名】アブエルサウード モハメド
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067CC13
5K067CC22
5K067EE02
5K067EE10
5K067EE25
(57)【要約】
ＣＳＭＡ／ＣＡ、ＥＤＣＡ及びＲ－ＴＷＴを使用してＲＴＡトラフィック送信を優先する無線通信プロトコル。Ｒ－ＴＷＴ ＳＰ中にＲＴＡトラフィックが優先的に送信され、Ｒ－ＴＷＴ ＳＰの正しい指示及び終了を保証するメカニズムを提供する。このプロセス中、メンバーＳＴＡは、送信すべきフレームをそれ以上有していない時にＲ－ＴＷＴスケジュール側ＡＰと通信する。Ｒ－ＴＷＴスケジュール側ＡＰは、予定終了時刻前にＲ－ＴＷＴ ＳＰを終了させて、非メンバーＳＴＡが直ちにチャネルを求めて競合することを可能にすることもできる。また、Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰ中のＲ－ＴＷＴメンバーＳＴＡとのフレーム交換が完了した後に、Ｒ－ＴＷＴ機能を有しているがＲ－ＴＷＴメンバーＳＴＡではないＳＴＡとフレームを交換することもできる。
【選択図】 図２３
【選択図】 図２３
【特許請求の範囲】
【請求項1】
ネットワークにおける無線通信のための装置であって、（ａ）マルチリンク装置（ＭＬＤ）とは別の、又はマルチリンク装置（ＭＬＤ）に関連する局（ＳＴＡ）であって、制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）のスケジューリングサービス期間（ＳＰ）にわたってＩＥＥＥ８０２プロトコルに従って無線ローカルエリアネットワーク（ＷＬＡＮ）上でキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してパケットでのフレームの送信を実行する他の無線局（ＳＴＡ）とチャネルを介して無線で通信するように構成された局（ＳＴＡ）としての無線通信回路と、
（ｂ）前記ＳＴＡに結合されてＷＬＡＮ上で動作するプロセッサと、
（ｃ）前記プロセッサによって実行可能な、通信プロトコル内の他のＳＴＡと通信するための命令を記憶する非一時的メモリと、
を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、Ｒ－ＴＷＴのメンバーＳＴＡとフレームを交換するためのＲ－ＴＷＴスケジューリングを告知する上で、
（ｉ）Ｒ－ＴＷＴスケジューリングを実行するように構成されたアクセスポイント（ＡＰ）として動作する、Ｒ－ＴＷＴスケジュール側ＡＰとしての前記局が、Ｒ－ＴＷＴ ＳＰに入った後に、Ｒ－ＴＷＴスケジューリングを告知してＲ－ＴＷＴのメンバーＳＴＡとフレームを交換することと、
（ｉｉ）終了条件が検出されることと、
（ｉｉｉ）前記Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰ中に全てのフレーム交換が完了した後に、前記Ｒ－ＴＷＴ ＳＰの終了を示す信号を終了告知において送信することと、
を含む１又は２以上のステップを実行する、
ことを特徴とする装置。
【請求項2】
前記終了条件は、Ｒ－ＴＷＴメンバーＳＴＡとして動作する前記ＳＴＡが、通信すべきフレームをそれ以上有していないと判定した後に、前記Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームをそれ以上有していないことを示す信号を前記Ｒ－ＴＷＴスケジュール側ＡＰに送信した時に発生する、請求項１に記載の装置。
【請求項3】
前記終了条件は、前記Ｒ－ＴＷＴスケジュール側ＡＰが前記Ｒ－ＴＷＴ ＳＰを終了させるために、前記Ｒ－ＴＷＴ ＳＰの予定終了時刻前に発生する、請求項１に記載の装置。
【請求項4】
前記Ｒ－ＴＷＴ ＳＰ中に前記Ｒ－ＴＷＴスケジュール側ＡＰと前記Ｒ－ＴＷＴメンバーＳＴＡとの間でフレームを交換することをさらに含む、請求項１に記載の装置。
【請求項5】
前記Ｒ－ＴＷＴスケジュール側ＡＰが前記Ｒ－ＴＷＴ ＳＰ中に前記Ｒ－ＴＷＴメンバーＳＴＡとのフレーム交換を完了した後に、前記Ｒ－ＴＷＴスケジュール側ＡＰと、Ｒ－ＴＷＴ機能を有しているがＲ－ＴＷＴメンバーＳＴＡではないＳＴＡとの間でフレームを交換することをさらに含む、請求項４に記載の装置。
【請求項6】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴメンバーＳＴＡが、前記Ｒ－ＴＷＴ ＳＰ中に送信すべきアップリンク（ＵＬ）フレーム又はピアツーピア（Ｐ２Ｐ）フレームを有していない時に前記Ｒ－ＴＷＴスケジュール側ＡＰに信号を送信することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項7】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴメンバーＳＴＡが、前記Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームを有していないことを示すフレームを送信することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項8】
前記Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームを有していないことを示す前記フレームは、（ａ）サービス品質（ＱｏＳ）データフレーム又はＱｏＳヌルフレームではないフレームと、（ｂ）前記Ｒ－ＴＷＴメンバーＳＴＡが前記Ｒ－ＴＷＴ ＳＰ中に送信すべきさらなるフレームを有していないことを表す状態にあるさらなるデータフィールドとしての、さらなるデータを有しているかどうかを示すフィールドを含むフレームと、を含む、請求項３に記載の装置。
【請求項9】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴメンバーＳＴＡが、前記Ｒ－ＴＷＴ ＳＰ中に送信すべきＵＬ及び／又はＰ２Ｐフレームを有していないことを示す状態に設定されたＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームを前記Ｒ－ＴＷＴメンバーＳＴＡが送信することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項10】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、前記ＥＯＳＰサブフィールドが前記Ｒ－ＴＷＴ ＳＰの終了を示す状態に設定されたＱｏＳデータフレーム又はＱｏＳヌルフレームを送信することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項11】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、送信すべきさらなるデータが存在するかどうかを示すさらなるデータフィールドとしてのフィールドを有するフレームであって、前記さらなるデータフィールドが前記Ｒ－ＴＷＴ ＳＰの終了を示す値に設定されたＱｏＳデータフレームでもＱｏＳヌルフレームでもないフレームを送信することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項12】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、前記Ｒ－ＴＷＴ ＳＰの終了を示すために競合なし（ＣＦ）終了フレームを送信することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項13】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、さらなるトリガーフレームが存在するかどうかを示すフィールドを有する、いずれの特定のＲ－ＴＷＴメンバーＳＴＡにもアドレス指定されていないトリガーフレームを送信し、前記フィールドを、Ｒ－ＴＷＴ ＳＰの終了を示すように設定することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項14】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、前記Ｒ－ＴＷＴ ＳＰの終了を示すＲ－ＴＷＴ識別に等しく設定されたＴＷＴフロー識別フィールドを有するＴＷＴ情報フレームを送信することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項15】
前記命令は、前記プロセッサによって実行された時に、前記メンバーＳＴＡが、前記Ｒ－ＴＷＴ ＳＰが終了した旨の指示を含むフレームを前記Ｒ－ＴＷＴスケジュール側ＡＰから受け取ったことに応答して前記Ｒ－ＴＷＴ ＳＰが終了したことを認識することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項16】
前記命令は、前記プロセッサによって実行された時に、前記メンバーＳＴＡが、前記Ｒ－ＴＷＴ ＳＰが終了したことを示す確認応答を前記Ｒ－ＴＷＴスケジュール側ＡＰから受け取ったことに応答して前記Ｒ－ＴＷＴ ＳＰが終了したことを認識することを含むステップをさらに実行する、請求項１に記載の装置。
【請求項17】
ネットワークにおける無線通信のための装置であって、（ａ）マルチリンク装置（ＭＬＤ）とは別の、又はマルチリンク装置（ＭＬＤ）に関連する局（ＳＴＡ）であって、制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）のスケジューリングサービス期間（ＳＰ）にわたってＩＥＥＥ８０２プロトコルに従って無線ローカルエリアネットワーク（ＷＬＡＮ）上でキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してパケットでのフレームの送信を実行する他の無線局（ＳＴＡ）とチャネルを介して無線で通信するように構成された局（ＳＴＡ）としての無線通信回路と、
（ｂ）前記ＳＴＡに結合されてＷＬＡＮ上で動作するプロセッサと、
（ｃ）前記プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリと、
を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、Ｒ－ＴＷＴのメンバーＳＴＡとフレームを交換するためのＲ－ＴＷＴスケジューリングを告知する上で、
（ｉ）Ｒ－ＴＷＴスケジューリングを実行するように構成されたアクセスポイント（ＡＰ）として動作する前記局がＲ－ＴＷＴスケジュール側ＡＰであり、前記Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴメンバーＳＴＡがＲ－ＴＷＴ ＳＰに入ることと、
（ｉｉ）前記Ｒ－ＴＷＴスケジュール側ＡＰが、前記Ｒ－ＴＷＴ ＳＰの予定終了時刻前に前記Ｒ－ＴＷＴ ＳＰを終了させて前記チャネル上で終了告知を送信することと、
（ｉｉｉ）前記ネットワーク上の前記Ｒ－ＴＷＴのメンバーＳＴＡではない他のＳＴＡが、前記終了告知を受け取ったことに応答してチャネルを求めて直ちに競合できることと、
を含む１又は２以上のステップを実行する、
ことを特徴とする装置。
【請求項18】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、前記Ｒ－ＴＷＴ ＳＰの終了を示す信号を、前記チャネルを介して送信することを含むステップをさらに実行する、請求項１７に記載の装置。
【請求項19】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴメンバーＳＴＡが、前記Ｒ－ＴＷＴ ＳＰの終了後に前記Ｒ－ＴＷＴ ＳＰの予定終了時刻に到達するまでチャネルを求めて競合できないことを含むステップをさらに実行する、請求項１７に記載の装置。
【請求項20】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴ ＳＰが終了した後に前記Ｒ－ＴＷＴ ＳＰの予定終了時刻まで、前記Ｒ－ＴＷＴメンバーＳＴＡが該Ｒ－ＴＷＴメンバーＳＴＡの通常のＥＤＣＡパラメータ設定よりも低い優先度でチャネルを求めて競合することを許可することを含むステップをさらに実行する、請求項１７に記載の装置。
【請求項21】
ネットワークにおける無線通信のための装置であって、（ａ）マルチリンク装置（ＭＬＤ）とは別の、又はマルチリンク装置（ＭＬＤ）に関連する局（ＳＴＡ）であって、制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）のスケジューリングサービス期間（ＳＰ）にわたってＩＥＥＥ８０２プロトコルに従って無線ローカルエリアネットワーク（ＷＬＡＮ）上でキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してパケットでのフレームの送信を実行する他の無線局（ＳＴＡ）とチャネルを介して無線で通信するように構成された局（ＳＴＡ）としての無線通信回路と、
（ｂ）前記ＳＴＡに結合されてＷＬＡＮ上で動作するプロセッサと、
（ｃ）前記プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリと、
を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、Ｒ－ＴＷＴのメンバーＳＴＡとフレームを交換するためのＲ－ＴＷＴスケジューリングを告知する上で、
（ｉ）Ｒ－ＴＷＴスケジューリングを実行するように構成されたアクセスポイント（ＡＰ）として動作する、Ｒ－ＴＷＴスケジュール側ＡＰとしての前記局と、Ｒ－ＴＷＴメンバーＳＴＡとがＲ－ＴＷＴ ＳＰに入ることと、
（ｉｉ）前記Ｒ－ＴＷＴ ＳＰ中に、前記Ｒ－ＴＷＴスケジュール側ＡＰと前記Ｒ－ＴＷＴメンバーＳＴＡとの間でフレームを交換することと、
（ｉｉｉ）前記Ｒ－ＴＷＴ ＳＰ中に前記Ｒ－ＴＷＴスケジュール側ＡＰが前記Ｒ－ＴＷＴメンバーＳＴＡとの間でフレーム交換を完了した後に、前記Ｒ－ＴＷＴスケジュール側ＡＰと、Ｒ－ＴＷＴ機能を有しているがＲ－ＴＷＴメンバーＳＴＡではないＳＴＡとの間でフレームを交換することと、
を含む１又は２以上のステップを実行する、
ことを特徴とする装置。
【請求項22】
前記命令は、前記プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、前記Ｒ－ＴＷＴメンバーＳＴＡとのフレーム交換のための送信機会（ＴＸＯＰ）を、前記Ｒ－ＴＷＴ ＳＰの予定終了時刻を超えて延長することを含むステップをさらに実行する、請求項２１に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
〔関連出願との相互参照〕
本出願は、２０２２年６月２０日に出願された米国特許出願シリアル番号第１７／８４４，５５５号に対する優先権及びその利益を主張するものであり、この文献は全体が引用により本明細書に組み入れられる。本出願は、２０２１年８月１１日に出願された米国仮特許出願シリアル番号第６３／２６０，１５５号に対する優先権及びその利益を主張ものであり、この文献は全体が引用により本明細書に組み入れられる。
本出願は、２０２２年６月２０日に出願された米国特許出願シリアル番号第１７／８４４，５５５号に対する優先権及びその利益を主張するものであり、この文献は全体が引用により本明細書に組み入れられる。本出願は、２０２１年８月１１日に出願された米国仮特許出願シリアル番号第６３／２６０，１５５号に対する優先権及びその利益を主張ものであり、この文献は全体が引用により本明細書に組み入れられる。
【0002】
〔連邦政府が支援する研究又は開発に関する記述〕
該当なし
該当なし
【0003】
〔著作権保護を受ける資料の通知〕
本特許文献中の資料の一部は、アメリカ合衆国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、合衆国特許商標庁の一般公開ファイル又は記録内に表される通りに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定ではないが米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておく権利のいずれも本明細書によって放棄するものではない。
本特許文献中の資料の一部は、アメリカ合衆国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、合衆国特許商標庁の一般公開ファイル又は記録内に表される通りに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定ではないが米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておく権利のいずれも本明細書によって放棄するものではない。
【0004】
本開示の技術は、一般にＣＳＭＡ／ＣＡを使用する無線ローカルエリアネットワークに関し、具体的には、制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）サービス期間（ＳＰ）を終了させることに関する。
【背景技術】
【0005】
ＣＳＭＡ／ＣＡを使用する現在の無線技術は、高スループットネットワーク性能を達成することに重点を置いているが、低遅延能力に欠けている。しかしながら、リアルタイムアプリケーション（ＲＴＡ）などの数多くのアプリケーションは低遅延を必要とする。
【0006】
リアルタイムアプリケーションは低遅延通信を必要とし、ベストエフォート通信を使用する。ＲＴＡから生成されるデータはＲＴＡトラフィックと呼ばれ、送信側ＳＴＡにおいてＲＴＡフレームとしてパケット化される。これとは対照的に、非時間依存アプリケーションから生成されるデータは非ＲＴＡトラフィックと呼ばれ、送信側ＳＴＡにおいて非ＲＴＡフレームとしてパケット化される。その後、送信側ＳＴＡは、フレーム内のパケットをチャネル経由で受信側ＳＴＡに送信する。
【0007】
ＲＴＡフレームは、配信の高適時性要件に起因して低遅延を必要とする。ＲＴＡフレームは、一定時間内に配信された場合に有効である。ＣＳＭＡ／ＣＡ無線プロトコルにおける１つの解決策は、ＲＴＡフレーム交換のために制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）のためのサービス期間（ＳＰ）をスケジュールすることである。Ｒ－ＴＷＴ ＳＰ中、ＲＴＡフレームは他のフレームよりも高い送信優先度を有する。しかしながら、効率性及び公正使用に関してＲ－ＴＷＴ問題が発生することがある。
【発明の概要】
【発明が解決しようとする課題】
【0008】
従って、改善されたＲ－ＴＷＴ動作に対するニーズが存在する。本開示は、このニーズを満たすとともに、さらなるＲ－ＴＷＴの利点を提供するものである。
【課題を解決するための手段】
【0009】
ＩＥＥＥ８０２．１１ｂｅなどによる現在の無線通信システムは、ＲＴＡトラフィック送信を優先するためにＥＤＣＡ及びＲ－ＴＷＴを利用する。Ｒ－ＴＷＴ ＳＰ中には、ＲＴＡトラフィックが優先的に送信される。しかしながら、Ｒ－ＴＷＴ ＳＰ期間は事前にスケジュールされて告知されるので、いくつかの事例では、Ｒ－ＴＷＴメンバーＳＴＡが必要とする送信時間よりもＲ－ＴＷＴ ＳＰ期間の方が長くなってしまうことがある。
【0010】
本開示は、Ｒ－ＴＷＴ ＳＰ中に全てのＲＴＡトラフィックが送信された直後にＲ－ＴＷＴ ＳＰが終了した旨を伝えるメカニズムを含むプロトコルについて説明し、ＵＬ、ＤＬ又はＰ２Ｐであることができる送信済みＲＴＡフレームをＡＰが識別するＲ－ＴＷＴスケジューリング課題に対処するものである。
【0011】
従って、Ｒ－ＴＷＴ ＳＰのチャネル使用の効率性を改善して公正使用問題（ｆａｉｒ ｕｓｅ ｉｓｓｕｅｓ）（乱用（ａｂｕｓｅ））を回避するために、Ｒ－ＴＷＴ ＳＰは、ＲＴＡフレーム交換が完了した直後に終了すべきである。
【0012】
本開示では、Ｒ－ＴＷＴスケジュール側ＡＰ（Ｒ－ＴＷＴ ｓｃｈｅｄｕｌｉｎｇ ＡＰ）及びＲ－ＴＷＴのメンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰ中にどのトラフィックがスケジュールされるかをネゴシエートしてそのトラフィックを優先する。
【0013】
本開示では、メンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰ中に送信すべきスケジュールされたＵＬ及び／又はＰ２Ｐをそれ以上有していないことを示す信号をＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴスケジュール側ＡＰに送信することができる。
【0014】
本開示では、Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰ中に全てのスケジュールされたトラフィックが送信された後に、Ｒ－ＴＷＴ ＳＰの終了を示す信号を他のＳＴＡに送信することができる。
【0015】
本開示では、Ｒ－ＴＷＴ ＳＰ中に全てのスケジュールされたトラフィック送信が終了した後に、Ｒ－ＴＷＴスケジュール側ＡＰが、被Ｒ－ＴＷＴスケジュール側ＳＴＡ（Ｒ－ＴＷＴ ｓｃｈｅｄｕｌｅｄ ＳＴＡｓ）であるがそのＲ－ＴＷＴのメンバーＳＴＡではないＳＴＡとの間で、Ｒ－ＴＷＴ ＳＰの残り時間をフレーム交換のために共有することができる。
【0016】
具体的には、本開示の少なくとも１つの実施形態では、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴメンバーＳＴＡが、これらの間のフレーム交換のためにＲ－ＴＷＴ ＳＰを開始する。Ｒ－ＴＷＴメンバーＳＴＡは、Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームをそれ以上有していない場合、Ｒ－ＴＷＴスケジュール側ＡＰに信号を送信する。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰ中に全てのフレーム交換を実行し終えると、Ｒ－ＴＷＴ ＳＰの終了を示す信号を送信する。
【0017】
本開示の少なくとも１つの他の実施形態では、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴメンバーＳＴＡが、これらの間でフレーム交換を実行するためにＲ－ＴＷＴ ＳＰを開始する。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの予定終了時刻前にＲ－ＴＷＴ ＳＰを終了する。Ｒ－ＴＷＴのメンバーＳＴＡでないＳＴＡは、Ｒ－ＴＷＴ ＳＰの終了直後にチャネルを求めて競合を開始する。
【0018】
本開示の少なくとも１つのさらなる実施形態では、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴメンバーＳＴＡがＲ－ＴＷＴ ＳＰを開始する。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰ中にＲ－ＴＷＴメンバーＳＴＡとフレームを交換する。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴメンバーＳＴＡではないＳＴＡとフレームを交換し、Ｒ－ＴＷＴ ＳＰ中にＲ－ＴＷＴメンバーＳＴＡとのフレーム交換を終了した後にＲ－ＴＷＴ機能を実装させる。本開示の要素及び利点は他にも数多く存在する。
【0019】
本明細書の以下の部分では、本明細書で説明する技術のさらなる態様が明らかになり、この詳細な説明は、本技術の好ましい実施形態を限定することなく完全に開示するためのものである。
【0020】
本明細書で説明する技術は、例示のみを目的とする以下の図面を参照することによって十分に理解されるであろう。
【図面の簡単な説明】
【0021】
【図1】ＩＥＥＥ８０２．１１で定められるＴＳＰＥＣ要素のデータフィールド図である。
【図3】ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ要素の内容のデータフィールド図である。
【図4】ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ処理要素の内容のデータフィールド図である。
【図5】ＩＥＥＥ８０２．１１ａｘで定められるＴＷＴ要素のデータフィールド図である。
【図7】特定のネゴシエーションタイプに対して有効なブロードキャストＴＷＴパラメータ情報フィールドのデータフィールド図である。
【図8】ブロードキャストＴＷＴパラメータ情報フィールドの要求タイプフィールドのデータフィールド図である。
【図10】ＩＥＥＥ８０２．１１ｂｅ（草案Ｐ８０２．１１ｂｅ＿Ｄ１．０１）で定められるＳＣＳ設定の通信図である。
【図11】ＳＣＳ要求フレームのデータフィールド図である。
【図13】ＳＣＳ応答フレームのフォーマットのデータフィールド図である。
【図14】ＳＣＳステータスサブフィールドのデータフィールド図である。
【図15】ＩＥＥＥ８０２．１１ａｘで定められるＴＷＴ設定の通信図である。
【図16】ＴＷＴ設定フレームのデータフィールド図である。
【図17】Ｒ－ＴＷＴ ＳＰ通信の通信図である。
【図18】本開示の少なくとも１つの実施形態による、局（ＳＴＡ）ハードウェアのハードウェアブロック図である。
【図19】本開示の少なくとも１つの実施形態による、マルチリンク装置（ＭＬＤ）ハードウェア構成のハードウェアブロック図である。
【図20】本開示の少なくとも１つの実施形態による、ネットワーク例のネットワークトポロジーである。
【図21】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴメンバーシップ設定の通信図である。
【図22】本開示の少なくとも１つの実施形態による、ＳＣＳトラフィック情報を含むＴＷＴ設定フレームのデータフィールド図である。
【図23】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰを終了するフロー図である。
【図24】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴｘメンバーＳＴＡが、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームがＲ－ＴＷＴｘ ＳＰ中に送信されたことを示す信号を送信するフロー図である。
【図25】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴｘメンバーＳＴＡが、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームがＲ－ＴＷＴｘ ＳＰ中に送信されたことを示す信号を送信するフロー図である。
【図26】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴｘメンバーＳＴＡが、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームがＲ－ＴＷＴｘ ＳＰ中に送信されたことを示す信号を送信するフロー図である。
【図27】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴのためのＱｏＳデータ及びＱｏＳヌルフレーム内のＱｏＳ制御フィールドのデータフィールド図である。
【図28】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴ ＳＰの終了を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＲ－ＴＷＴスケジュール側ＡＰがブロードキャストする通信図である。
【図29】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴ ＳＰ中にＲ－ＴＷＴメンバーＳＴＡがチャネルを求めて競合できるＲ－ＴＷＴ ＳＰの通信図である。
【図30】終了指示が正常に受け取られなかったＲ－ＴＷＴ ＳＰの通信図である。
【図31】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴ ＳＰ中にトリガーされたＴＸＯＰ共有時間を終了するために、ＥＯＳＰが第２の状態（例えば、「０」）に設定されたＱｏＳヌルフレームをＳＴＡが送信する通信図である。
【図32】Ｒ－ＴＷＴ ＳＰ中にトリガーされたＴＸＯＰ共有時間を終了するために、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＳＴＡが送信する通信図である。
【図33】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡの送信を手配する通信図である。
【図34】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰ中にスケジュールされたＵＬトラフィックの到着を待つ通信図である。
【図35】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴのスケジュールされたトラフィックストリームのフレームがそれ以上送信される予定でない場合にＲ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰを終了する通信図である。
【図36】本開示の少なくとも１つの実施形態による、Ｒ－ＴＷＴスケジュール側ＡＰがスケジュールされたトラフィックの到着を待っている時にＲ－ＴＷＴ非メンバーＳＴＡとフレームを交換する通信図である。
【図37】本開示の少なくとも１つの実施形態による、各リンク上でのマルチリンクＲ－ＴＷＴ ＳＰの終了を別々に示す通信図である。
【図38】本開示の少なくとも１つの実施形態による、１つのリンク上でのＭＬ Ｒ－ＴＷＴ ＳＰの終了の通信図である。
【発明を実施するための形態】
【0022】
１．８０２．１１要素概論
１．１．トラフィック仕様（ＴＳＰＥＣ）
図１に、ＩＥＥＥ８０２．１１で定められるＴＳＰＥＣ要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＳＰＥＣ要素のものであることを示す。長さ（Ｌｅｎｇｔｈ）フィールドは、ＴＳＰＥＣ要素の長さを示す。ＴＳ情報（Ｉｎｆｏ）フィールドは、図２に示すようなトラフィックストリーム情報を含む。
１．１．トラフィック仕様（ＴＳＰＥＣ）
図１に、ＩＥＥＥ８０２．１１で定められるＴＳＰＥＣ要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＳＰＥＣ要素のものであることを示す。長さ（Ｌｅｎｇｔｈ）フィールドは、ＴＳＰＥＣ要素の長さを示す。ＴＳ情報（Ｉｎｆｏ）フィールドは、図２に示すようなトラフィックストリーム情報を含む。
【0023】
なお、本開示では、説明しないフィールドは、他の要素で指定する先行フィールドと同じ機能を有する。
【0024】
公称ＭＳＤＵサイズ（Ｎｏｍｉｎａｌ ＭＳＤＵ Ｓｉｚｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵの公称サイズを示す。最大ＭＳＤＵサイズ（Ｍａｘｉｍｕｍ ＭＳＤＵ Ｓｉｚｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵの最大サイズを含む。最小サービス間隔（Ｍｉｎｉｍｕｍ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｖａｌ）フィールドは、連続する２つのサービス期間（ＳＰ）の開始時刻間の最小時間を示す。最大サービス間隔（Ｍａｘｉｍｕｍ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｖａｌ）フィールドは、連続する２つのＳＰの開始時刻間の最大時間を示す。非作動間隔（Ｉｎａｃｔｉｖｉｔｙ Ｉｎｔｅｒｖａｌ）フィールドは、ＴＳの削除前にそのＴＳに属するＭＳＤＵの到着又は送信がない時間を示す。停止間隔（Ｓｕｓｐｅｎｓｉｏｎ Ｉｎｔｅｒｖａｌ）フィールドは、ＴＳのサービス品質（ＱｏＳ）（＋）競合なし（ＣＦ）ポーリングの生成の停止前にそのＴＳに属するＭＳＤＵが到着又は送信を伴わずに発生し得る時間を示す。サービス開始時刻（Ｓｅｒｖｉｃｅ Ｓｔａｒｔ Ｔｉｍｅ）フィールドは、最初のＳＰの開始時刻を示す。最小データレート（Ｍｉｎｉｍｕｍ Ｄａｔａ Ｒａｔｅ）フィールドは、ＭＡＣ ＳＡＰによって指定された、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための最低データレートを示す。平均データレート（Ｍｅａｎ Ｄａｔａ Ｒａｔｅ）フィールドは、ＭＡＣ ＳＡＰによって指定された、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための平均データレートを示す。
【0025】
ピークデータレート（Ｐｅａｋ Ｄａｔａ Ｒａｔｅ）フィールドは、ＭＡＣ ＳＡＰによって指定される、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための最大データレートを示す。バーストサイズ（Ｂｕｒｓｔ Ｓｉｚｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵのピークデータレートでの最大バーストを示す。遅延限界（Ｄｅｌａｙ Ｂｏｕｎｄ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するために許容される最大時間を示す。最小ＰＨＹレート（Ｍｉｎｉｍｕｍ ＰＨＹ Ｒａｔｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵを送信するための最小ＰＨＹレートを示す。余剰帯域幅許可（Ｓｕｒｐｌｕｓ Ｂａｎｄｗｉｄｔｈ Ａｌｌｏｗａｎｃｅ）フィールドは、このＴＳＰＥＣ下のＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵの送信及びその再送に利用される帯域と、このＭＳＤＵ又はＡ－ＭＳＤＵを最小ＰＨＹレートで１度送信するために使用される帯域との比率を示す。媒体時間（Ｍｅｄｉｕｍ Ｔｉｍｅ）フィールドは、ＳＴＡが媒体へのアクセスに認められる時間を示す。ＤＭＧ属性（ＤＭＧ Ａｔｔｒｉｂｕｔｅｓ）フィールドは、ＴＳＰＥＣが指向性マルチギガビット（ＤＭＧ）ＢＳＳに適用される際に提示される。
【0026】
図２に、ＩＥＥＥ８０２．１１で定められる図１のＴＳ情報フィールドの内容を示す。ＴＳ情報フィールドのサブフィールドは以下の通りである。トラフィックタイプ（Ｔｒａｆｆｉｃ Ｔｙｐｅ）サブフィールドは、トラフィックが周期的であるか否かを指定する。ＴＳＩＤサブフィールドは、ＴＳを識別するためのＩＤ番号を示す。方向（Ｄｉｒｅｃｔｉｏｎ）サブフィールドは、データ送信の方向を指定する。アクセスポリシー（Ａｃｃｅｓｓ Ｐｏｌｉｃｙ）サブフィールドは、チャネルアクセス権を獲得する方法を指定する。アグリゲーション（Ａｇｇｒｅｇａｔｉｏｎ）サブフィールドは、アグリゲーションスケジュールが必要であるかどうかを指定する。ＡＰＳＤサブフィールドは、自動ＰＳ配信が使用されるかどうかを示す。ユーザ優先度（Ｕｓｅｒ Ｐｒｉｏｒｉｔｙ）サブフィールドは、ＴＳに属するＭＳＤＵ又はＡ－ＭＳＤＵのユーザ優先度を示す。ＴＳＩｎｆｏ ＡＣＫポリシー（ＴＳＩｎｆｏ Ａｃｋ Ｐｏｌｉｃｙ）サブフィールドは、Ａｃｋが必要であるかどうか、及びどの形態のＡｃｋを使用すべきであるかを示す。スケジュール（Ｓｃｈｅｄｕｌｅ）サブフィールドは、スケジュールのタイプを示す。
【0027】
１．１．２．ＴＣＬＡＳ要素
図３に、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＣＬＡＳ要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドはＴＣＬＡＳ要素の長さを示す。ユーザ優先度（Ｕｓｅｒ Ｐｒｉｏｒｉｔｙ）フィールドは上位層からのユーザ優先度を示す。フレーム分類器（Ｆｒａｍｅ Ｃｌａｓｓｉｆｉｅｒ）フィールドは、上位層からのフレームを分類するために利用すべき方法を示す。
図３に、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＣＬＡＳ要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドはＴＣＬＡＳ要素の長さを示す。ユーザ優先度（Ｕｓｅｒ Ｐｒｉｏｒｉｔｙ）フィールドは上位層からのユーザ優先度を示す。フレーム分類器（Ｆｒａｍｅ Ｃｌａｓｓｉｆｉｅｒ）フィールドは、上位層からのフレームを分類するために利用すべき方法を示す。
【0028】
１．１．３．ＴＣＬＡＳプロセス要素
図４に、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ処理要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＣＬＡＳ処理要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドはＴＣＬＡＳ処理要素の長さを示す。処理（Ｐｒｏｃｅｓｓｉｎｇ）フィールドは、複数のＴＣＬＡＳ要素が存在する場合に上位層からのトラフィックを分類する方法を示す。
図４に、ＩＥＥＥ８０２．１１で定められるＴＣＬＡＳ処理要素の内容を示す。要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）フィールドは要素のタイプを示し、この事例ではＴＣＬＡＳ処理要素であることを示す。長さ（Ｌｅｎｇｔｈ）フィールドはＴＣＬＡＳ処理要素の長さを示す。処理（Ｐｒｏｃｅｓｓｉｎｇ）フィールドは、複数のＴＣＬＡＳ要素が存在する場合に上位層からのトラフィックを分類する方法を示す。
【0029】
１．１．４．ＴＷＴ要素
図５に、ＩＥＥＥ８０２．１１ａｘで定められる、要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）、長さ（Ｌｅｎｇｔｈ）、制御（Ｃｏｎｔｒｏｌ）及びＴＷＴパラメータ情報（ＴＷＴ Ｐａｒａｍｅｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）のためのフィールドを有するＴＷＴ要素のフォーマットを示す。
図５に、ＩＥＥＥ８０２．１１ａｘで定められる、要素ＩＤ（Ｅｌｅｍｅｎｔ ＩＤ）、長さ（Ｌｅｎｇｔｈ）、制御（Ｃｏｎｔｒｏｌ）及びＴＷＴパラメータ情報（ＴＷＴ Ｐａｒａｍｅｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）のためのフィールドを有するＴＷＴ要素のフォーマットを示す。
【0030】
図６には、図５に示すＴＷＴ要素の制御フィールドを示しており、このフィールドは、ＮＤＰページングインジケータ（ＮＤＰ Ｐａｇｉｎｇ ｉｎｄｉｃａｔｏｒ）、応答者ＰＭモード（Ｒｅｓｐｏｎｄｅｒ ＰＭ Ｍｏｄｅ）、ネゴシエーションタイプ（Ｎｅｇｏｔｉａｔｉｏｎ Ｔｙｐｅ）、ＴＷＴ情報フレーム無効化（ＴＷＴ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｒａｍｅ Ｄｉｓａｂｌｅｄ）、ウェイク期間単位（Ｗａｋｅ Ｄｕｒａｔｉｏｎ Ｕｎｉｔ）、予備（Ｒｅｓｅｒｖｅｄ）というフィールドを有する。ネゴシエーションタイプサブフィールドは、実行すべきネゴシエーションのタイプを示す。
【0031】
図７には、図６で説明したネゴシエーションタイプが「２」又は「３」に設定された時に有効であるブロードキャストＴＷＴパラメータ情報（Ｂｒｏａｄｃａｓｔ ＴＷＴ ｐａｒａｍｅｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）要素を示す。サブフィールドは、要求タイプ（Ｒｅｑｕｅｓｔ Ｔｙｐｅ）、ターゲットウェイクタイム（Ｔａｒｇｅｔ Ｗａｋｅ Ｔｉｍｅ）、公称最小ＴＷＴウェイク期間（Ｎｏｍｉｎａｌ Ｍｉｎｉｍｕｍ ＴＷＴ Ｗａｋｅ Ｄｕｒａｔｉｏｎ）、ＴＷＴウェイク間隔仮数（ＴＷＴ Ｗａｋｅ Ｉｎｔｅｒｖａｌ Ｍａｎｔｉｓｓａ）、ブロードキャストＴＷＴ情報（Ｂｒｏａｄｃａｓｔ ＴＷＴ Ｉｎｆｏｒｍａｔｉｏｎ）として示す。
【0032】
なお、ＩＥＥＥ８０２．１１ｂｅ（草案Ｐ８０２．１１ｂｅ＿Ｄ１．０１）には更新版が存在する。ブロードキャストＴＷＴパラメータ情報フィールドの要求タイプフィールド内のブロードキャストＴＷＴ推奨フィールドが「４」に設定されている場合には、ブロードキャストＴＷＴパラメータ情報フィールドに示されるブロードキャストＴＷＴ（Ｂ－ＴＷＴ）が制限付きＴＷＴ（Ｒ－ＴＷＴ）であることを示す。
【0033】
図８には、ブロードキャストＴＷＴパラメータ情報フィールドの要求タイプフィールドを示しており、このフィールドは、ＴＷＴ要求（ＴＷＴ Ｒｅｑｕｅｓｔ）、ＴＷＴ設定コマンド（ＴＷＴ Ｓｅｔｕｐ Ｃｏｍｍａｎｄ）、トリガー、最後のブロードキャストパラメータセット（Ｌａｓｔ Ｂｒｏａｄｃａｓｔ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、フロータイプ（Ｆｌｏｗ Ｔｙｐｅ）、ブロードキャストＴＷＴ推奨（Ｂｒｏａｄｃａｓｔ ＴＷＴ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ）、ＴＷＴウェイク間隔指数（ＴＷＴ Ｗａｋｅ Ｉｎｔｅｒｖａｌ Ｅｘｐｏｎｅｎｔ）、及び予備（Ｒｅｓｅｒｖｅｄ）というサブフィールドを有する。
【0034】
図９には、ブロードキャストＴＷＴパラメータ情報フィールド内のブロードキャストＴＷＴ情報フィールドを示しており、このフィールドは、ブロードキャストＴＷＴ ＩＤサブフィールド、及びブロードキャストＴＷＴ永続性サブフィールドを有する。
【0035】
１．２．ＳＣＳシグナリング
図１０に、ＩＥＥＥ８０２．１１ｂｅ（草案Ｐ８０２．１１ｂｅ＿Ｄ１．０１）で定められるＳＣＳ設定の例を示す。ＳＴＡの相互作用モデルは、ＩＥＥＥ８０２．１１標準で定められるものと同じであることができる。
図１０に、ＩＥＥＥ８０２．１１ｂｅ（草案Ｐ８０２．１１ｂｅ＿Ｄ１．０１）で定められるＳＣＳ設定の例を示す。ＳＴＡの相互作用モデルは、ＩＥＥＥ８０２．１１標準で定められるものと同じであることができる。
【0036】
非ＡＰ ＳＴＡは、ＡＰとの間でＳＣＳ設定手順を開始すると決定する。非ＡＰ ＳＴＡの局管理エンティティ（ＳＭＥ）は、そのＭＡＣ副層管理エンティティ（ＭＬＭＥ）にＭＬＭＥ－ＳＣＳ．ｒｅｑｕｅｓｔメッセージを送信する。非ＡＰ ＳＴＡのＭＬＭＥは、ＭＬＭＥ－ＳＣＳ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＭＬＭＥ－ＳＣＳ．ｒｅｑｕｅｓｔメッセージ内の情報を収集して、ＡＰにＳＣＳ要求フレームを送信する。ＡＰのＭＬＭＥはフレームを受け取り、そのＳＭＥに対してＭＬＭＥ－ＳＣＳ．ｉｎｄｉｃａｔｉｏｎメッセージを生成する。
【0037】
次に、ＡＰのＳＭＥは、そのＭＬＭＥにＳＣＳ設定結果を含むＭＬＭＥ－ＳＣＳ．ｒｅｓｐｏｎｓｅメッセージを送信する。その後、ＡＰのＭＬＭＥは、非ＡＰ ＳＴＡにＳＣＳ応答フレームを送信する。非ＡＰ ＳＴＡのＭＬＭＥはフレームを受け取り、そのＳＭＥにＭＬＭＥ－ＳＣＳ．ｃｏｎｆｉｒｍメッセージを送信する。この結果、非ＡＰは、ＳＣＳ設定に成功したか否かを認識することができる。
【0038】
【0039】
【0040】
【0041】
図１４には、ＳＣＳＩＤフィールドに示されるＳＣＳのＳＣＳ設定結果（例えば、受諾、拒絶、理由付き拒絶及び終了など）を表すＳＣＳステータスサブフィールドを示す。
【0042】
１．３．Ｒ－ＴＷＴシグナリング
図１５に、ＩＥＥＥ８０２．１１ａｘで定められるＴＷＴ設定の例を示す。ＳＴＡの相互作用モデルは、ＩＥＥＥ８０２．１１標準に定められているものと同じであることができる。
図１５に、ＩＥＥＥ８０２．１１ａｘで定められるＴＷＴ設定の例を示す。ＳＴＡの相互作用モデルは、ＩＥＥＥ８０２．１１標準に定められているものと同じであることができる。
【0043】
非ＡＰ ＳＴＡが、ＡＰとの間でＴＷＴ設定手順を開始すると決定する。非ＡＰ ＳＴＡの局管理エンティティ（ＳＭＥ）は、そのＭＡＣ副層管理エンティティ（ＭＬＭＥ）にＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｒｅｑｕｅｓｔメッセージを送信する。非ＡＰ ＳＴＡのＭＬＭＥは、ＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｒｅｑｕｅｓｔメッセージ内の情報を収集して、ＡＰにＴＷＴ設定フレーム（ＴＷＴ要求フレーム）を送信する。ＡＰのＭＬＭＥはフレームを受け取り、この要求を処理するＳＭＥに対してＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｉｎｄｉｃａｔｉｏｎメッセージを生成する。
【0044】
次に、ＡＰのＳＭＥは、ＴＷＴ設定結果を含むＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｒｅｓｐｏｎｓｅメッセージをそのＭＬＭＥに送信する。その後、ＡＰのＭＬＭＥは、非ＡＰ ＳＴＡにＴＷＴ設定フレーム（すなわち、ＴＷＴ応答フレーム）を送信する。非ＡＰ ＳＴＡのＭＬＭＥはこのフレームを受け取り、そのＳＭＥにＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｃｏｎｆｉｒｍメッセージを送信する。この結果、非ＡＰは、ＴＷＴ設定に成功したか否かを認識する。
【0045】
ＩＥＥＥ８０２．１１ｂｅの規定によれば、Ｒ－ＴＷＴスケジュール側ＡＰと呼ばれる制限付きＴＷＴ Ｒ－ＴＷＴスケジュール側ＡＰは、制限付きＴＷＴ動作をサポートして、送信されるＥＨＴ能力（ＥＨＴ Ｃａｐａｂｉｌｉｔｉｅｓ）要素内の制限付きＴＷＴサポート（Ｒｅｓｔｒｉｃｔｅｄ ＴＷＴ Ｓｕｐｐｏｒｔ）サブフィールドを「１」に設定するＥＨＴ ＡＰである。
【0046】
被Ｒ－ＴＷＴスケジュール側ＳＴＡと呼ばれる被制限付きＴＷＴ Ｒ－ＴＷＴスケジュール側ＳＴＡは、制限付きＴＷＴ動作をサポートして、送信されるＥＨＴ能力要素内の制限付きＴＷＴサポートサブフィールドを「１」に設定する非ＡＰ ＥＨＴ ＳＴＡである。
【0047】
被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴスケジュール側ＡＰによってスケジュールされた１又は２以上のＲ－ＴＷＴのメンバーシップを確立することができる。Ｒ－ＴＷＴ設定シグナリングは、被Ｒ－ＴＷＴスケジュール側ＳＴＡとＲ－ＴＷＴスケジュール側ＡＰとの間のＲ－ＴＷＴのメンバーシップネゴシエーションに使用される、追加パラメータ設定を含むブロードキャストＴＷＴと同じものである。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴスケジュール側ＡＰによってスケジュールされたＲ－ＴＷＴのメンバーシップを確立した後には、Ｒ－ＴＷＴのＳＰ中に高優先度を有し、又はＲ－ＴＷＴスケジュール側ＡＰとのフレーム交換を許可される。一方で、Ｒ－ＴＷＴのメンバーでない被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴ ＳＰ中に低優先度を有し、又はＲ－ＴＷＴスケジュール側ＡＰとのフレーム交換を許可されない。
【0048】
図１６に、フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）、期間（Ｄｕｒａｔｉｏｎ）、複数のアドレス（Ａｄｄｒｅｓｓｅｓ）、シーケンス制御（Ｓｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌ）、及びデータ（ｄａｔａ）というフィールドを含むＴＷＴ設定フレームを示す。データフィールドは、カテゴリ（Ｃａｔｅｇｏｒｙ）、アクション（Ａｃｔｉｏｎ）、ダイアログトークン（Ｄｉａｌｏｇ Ｔｏｋｅｎ）、及びＴＷＴ要素（ＴＷＴ ｅｌｅｍｅｎｔ）というサブフィールドを含む。
【0049】
フレーム制御フィールドはフレームのタイプを示し、このフレームがアクションフレームであることを示すことができる。期間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。アドレス１フィールドは、フレーム受信者のアドレスを含む。アドレス２フィールドは、フレームを送信したＳＴＡのアドレスを含む。アドレス３フィールドは、フレームの受信者であるＳＴＡのＢＳＳＩＤを含む。シーケンス制御フィールドは、フレームのシーケンス番号を示す。
【0050】
カテゴリ及びアクションフィールドは、アクションフレームがＴＷＴ設定フレームであることを示し、ＴＷＴ要素を伝える。ダイアログトークンは、ＴＷＴ設定フレームを識別するために使用される。ＴＷＴ要素は、図５に示すフォーマットを有するＴＷＴ設定情報を示す。
【0051】
図１７に、Ｒ－ＴＷＴ ＳＰ通信の例を示す。ＡＰ１は、Ｒ－ＴＷＴ１スケジューリングを告知してＲ－ＴＷＴ１のメンバーを管理するＲ－ＴＷＴスケジュール側ＡＰである。ＳＴＡ１及びＳＴＡ２は、Ｒ－ＴＷＴ１のメンバーＳＴＡである。Ｒ－ＴＷＴ１ ＳＰ中、ＡＰ１は、メンバーＳＴＡとのフレーム交換（例えば、ＳＴＡ１とのＳＣＳ１のＵＬ ＰＰＤＵ、及びＳＴＡ２とのＳＣＳ２のＤＬ ＰＰＤＵ）をスケジュールして優先度付けする。Ｒ－ＴＷＴスケジューリングを受け取って認識できるＳＴＡは、被Ｒ－ＴＷＴスケジュール側ＳＴＡと呼ばれる。ＳＴＡ３は、被Ｒ－ＴＷＴスケジュール側ＳＴＡであるが、Ｒ－ＴＷＴ１のメンバーＳＴＡではない。ＳＴＡ３は、Ｒ－ＴＷＴ１ ＳＰの開始時刻前にそのＴＸＯＰを終了する必要がある。ＳＴＡ３は、Ｒ－ＴＷＴ１ ＳＰ中にクワイエットモードに入ることも、又は単にチャネルを求めて競合しないこともできる。スケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰ中にクワイエット間隔を告知するためにクワイエット要素をブロードキャストすることができ、この要素を認識したＳＴＡはクワイエットモードに入ることができる。
【0052】
２．課題の記述
ＥＤＣＡ及びＲ－ＴＷＴを使用する現在の無線通信システムはＲＴＡトラフィック送信を優先することができ、例えばＲ－ＴＷＴ ＳＰ中にはＲＴＡトラフィックが優先的に送信される。しかしながら、Ｒ－ＴＷＴ ＳＰ期間は予めスケジュールされて告知され、いくつかの事例では、Ｒ－ＴＷＴメンバーＳＴＡが必要とする送信時間よりもＲ－ＴＷＴ ＳＰ期間の方が長い場合もあり、これによって未使用のチャネル帯域幅（低効率送信）が生じる。
ＥＤＣＡ及びＲ－ＴＷＴを使用する現在の無線通信システムはＲＴＡトラフィック送信を優先することができ、例えばＲ－ＴＷＴ ＳＰ中にはＲＴＡトラフィックが優先的に送信される。しかしながら、Ｒ－ＴＷＴ ＳＰ期間は予めスケジュールされて告知され、いくつかの事例では、Ｒ－ＴＷＴメンバーＳＴＡが必要とする送信時間よりもＲ－ＴＷＴ ＳＰ期間の方が長い場合もあり、これによって未使用のチャネル帯域幅（低効率送信）が生じる。
【0053】
３．本発明の寄与
Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴのメンバーＳＴＡが、そのＲ－ＴＷＴ ＳＰ中にどのトラフィックの送信をスケジュールするかをネゴシエートする。スケジュールされたトラフィックは、Ｒ－ＴＷＴ ＳＰ中に優先的に送信される。本開示は、Ｒ－ＴＷＴメンバーＳＴＡが必要とする送信時間よりもＲ－ＴＷＴ ＳＰ期間の方が長い場合に発生する問題を確認済みである。
Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴのメンバーＳＴＡが、そのＲ－ＴＷＴ ＳＰ中にどのトラフィックの送信をスケジュールするかをネゴシエートする。スケジュールされたトラフィックは、Ｒ－ＴＷＴ ＳＰ中に優先的に送信される。本開示は、Ｒ－ＴＷＴメンバーＳＴＡが必要とする送信時間よりもＲ－ＴＷＴ ＳＰ期間の方が長い場合に発生する問題を確認済みである。
【0054】
Ｒ－ＴＷＴ ＳＰの全てのＲＴＡトラフィックが送信された直後にＲ－ＴＷＴ ＳＰが終了したことを示すメカニズムについて説明する。対処される課題の１つは、ＲＴＡフレームがＵＬ、ＤＬ及び／又はＰ２Ｐのいずれかであり得る場合に、全てのＲＴＡフレームが送信されたことをＲ－ＴＷＴスケジュール側ＡＰがどのように識別するかである。
【0055】
このプロトコルでは、メンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰ中に送信すべきスケジュールされたＵＬ及びＰ２Ｐを有していないことを示す信号をＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴスケジュール側ＡＰに送信することができる。
【0056】
Ｒ－ＴＷＴ ＳＰ中に全てのスケジュールされたトラフィックが送信されると、Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰを終了する信号を送信することができる。
【0057】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰ中に全てのスケジュールされたトラフィックの送信を完了した後に、被Ｒ－ＴＷＴスケジュール側ＳＴＡではあるがそのＲ－ＴＷＴのメンバーＳＴＡではないＳＴＡとＲ－ＴＷＴ ＳＰの残り時間を共有してフレーム交換などを実行することができる。
【0058】
４．Ｒ－ＴＷＴ終了の実施形態
４．１．ＳＴＡ及びＭＬＤハードウェア構成
図１８に、本開示のプロトコルを実行するように構成されたＳＴＡハードウェアの実施形態例１０を示す。外部Ｉ／Ｏ接続１４が回路１２の内部バス１６に結合し、内部バス１６上には、通信プロトコルを実装する（単複の）プログラムを実行するためにＣＰＵ１８及びメモリ（例えば、ＲＡＭ）２０が接続されることが好ましい。ホストマシンは、１又は複数のアンテナ２９、２６ａ、２６ｂ、２６ｃ～２６ｎにそれぞれが接続された少なくとも１つのＲＦモジュール２４、２８に結合された、通信をサポートする少なくとも１つのモデム２２を収容する。複数のアンテナ（例えば、アンテナアレイ）を有するＲＦモジュールは、送信及び受信中にビームフォーミングを実行することを可能にする。このように、ＳＴＡは、複数組のビームパターンを使用して信号を送信することができる。
４．１．ＳＴＡ及びＭＬＤハードウェア構成
図１８に、本開示のプロトコルを実行するように構成されたＳＴＡハードウェアの実施形態例１０を示す。外部Ｉ／Ｏ接続１４が回路１２の内部バス１６に結合し、内部バス１６上には、通信プロトコルを実装する（単複の）プログラムを実行するためにＣＰＵ１８及びメモリ（例えば、ＲＡＭ）２０が接続されることが好ましい。ホストマシンは、１又は複数のアンテナ２９、２６ａ、２６ｂ、２６ｃ～２６ｎにそれぞれが接続された少なくとも１つのＲＦモジュール２４、２８に結合された、通信をサポートする少なくとも１つのモデム２２を収容する。複数のアンテナ（例えば、アンテナアレイ）を有するＲＦモジュールは、送信及び受信中にビームフォーミングを実行することを可能にする。このように、ＳＴＡは、複数組のビームパターンを使用して信号を送信することができる。
【0059】
バス１４は、センサ及びアクチュエータなどの様々な装置をＣＰＵに接続することができる。プロセッサ１８上では、ＳＴＡがアクセスポイント（ＡＰ）局又は通常の局（非ＡＰ ＳＴＡ）の機能を実行することを可能にするように実行される通信プロトコルを実装するプログラムを実行するための、メモリ２０からの命令が実行される。また、このプログラミングは、現在の通信状況でどのような役割を果たしているかに応じて異なるモード（ＴＸＯＰ所有者、ＴＸＯＰ共有参加者、ソース、中間、宛先、第１のＡＰ、他のＡＰ、第１のＡＰに関連する局、他のＡＰに関連する局、調整機（ｃｏｏｒｄｉｎａｔｏｒ）、被調整機（ｃｏｏｒｄｉｎａｔｅｅ）、ＯＢＳＳ内のＡＰ、及びＯＢＳＳ内のＳＴＡなど）で動作するように構成されると理解されたい。
【0060】
従って、図示のＳＴＡ ＨＷは、少なくとも１つのモデムと、少なくとも１つの帯域上での通信を提供するための関連するＲＦ回路とで構成される。
【0061】
なお、本開示は、それぞれが任意の数のＲＦ回路に結合された複数のモデム２２を使用して構成することができると理解されたい。一般に、使用するＲＦ回路の数が多ければ多いほど、アンテナビーム方向のカバレッジは広くなる。なお、利用するＲＦ回路の数及びアンテナの数は、特定の装置のハードウェア制約によって決まると理解されたい。ＲＦ回路及びアンテナの一部は、ＳＴＡが近隣ＳＴＡと通信する必要がないと判定した時に無効にすることができる。少なくとも１つの実施形態では、ＲＦ回路が周波数変換器及びアレイアンテナコントローラなどを含み、送受信のためにビームフォーミングを実行するように制御される複数のアンテナに接続される。このように、ＳＴＡは、各ビームパターン方向がアンテナセクタとみなされる複数のビームパターンの組を使用して信号を送信することができる。
【0062】
また、図示のような局ハードウェアの複数のインスタンスはマルチリンク装置（ＭＬＤ）に組み合わせることができ、通常、このＭＬＤは活動を協調させるためにプロセッサ及びメモリを有するが、必ずしもＭＬＤ内の各ＳＴＡに別々のＣＰＵ及びメモリが必要なわけではない。
【0063】
図１９に、マルチリンク装置（ＭＬＤ）ハードウェア構成の実施形態例４０を示す。ソフトＡＰ ＭＬＤは、ＡＰとして動作する１又は２以上の所属するＳＴＡから成るＭＬＤである。ソフトＡＰ ＭＬＤは、２．４ＧＨｚ、５ＧＨｚ及び６ＧＨｚ上で複数の無線動作をサポートすべきである。複数の無線のうちの基本リンクセットは、例えば基本リンクセット（２．４ＧＨｚ及び５ＧＨｚ）、基本リンクセット（２．４ＧＨｚ及び６ＧＨｚ）などの同時送受信（ＳＴＲ）モードを満たすリンクペアである。
【0064】
条件付きリンクは、何らかの基本リンクと非同時送受信（ＮＳＴＲ）リンクペアを形成するリンクである。例えば、これらのリンクペアは、５ＧＨｚが基本リンクである場合には、５ＧＨｚリンクに対応する条件付きリンクとして６ＧＨｚリンクを含むことができ、６ＧＨｚが基本リンクである場合には、６ＧＨｚリンクに対応する条件付きリンクとして５ＧＨｚリンクを含むことができる。ソフトＡＰは、Ｗｉ－Ｆｉホットスポット及びテザリングを含む異なるシナリオで使用される。
【0065】
ＭＬＤには複数のＳＴＡが所属し、各ＳＴＡは異なる周波数のリンク上で動作する。ＭＬＤは、アプリケーションへの外部Ｉ／Ｏアクセスを有し、このアクセスは、ＣＰＵ６２及びメモリ（例えば、ＲＡＭ）６４を有するＭＬＤ管理エンティティ４８に接続して、ＭＬＤレベルで通信プロトコルを実装する（単複の）プログラムの実行を可能にする。ＭＬＤは、ここではＳＴＡ１ ４２、ＳＴＡ２ ４４～ＳＴＡ Ｎ４６として例示する接続先の各所属する局にタスクを配分してこれらから情報を収集し、所属するＳＴＡ間で情報を共有することができる。
【0066】
少なくとも１つの実施形態では、ＭＬＤの各ＳＴＡが独自のＣＰＵ５０及びメモリ（ＲＡＭ）５２を有し、これらは、１又は２以上のアンテナを有する少なくとも１つのＲＦ回路５６に接続された少なくとも１つのモデム５４にバス５８を通じて結合される。本例では、ＲＦ回路が、アンテナアレイなどの形の複数のアンテナ６０ａ、６０ｂ、６０ｃ～６０ｎを有する。ＲＦ回路及び関連する（単複の）アンテナと組み合わせたモデムは、近隣のＳＴＡとの間でデータフレームを送信／受信する。少なくとも１つの実装では、ＲＦモジュールが、周波数変換器、アレイアンテナコントローラ、及びそのアンテナと連動するためのその他の回路を含む。
【0067】
ＭＬＤの各ＳＴＡは、特定のＭＬＤ実装に応じて互いに及び／又はＭＬＤ管理エンティティとリソースを共有することができるので、必ずしも独自のプロセッサ及びメモリを必要としないと理解されたい。なお、上記のＭＬＤ図は限定ではなく一例として示すものであり、本開示は幅広いＭＬＤ実装と共に動作することができると理解されたい。
【0068】
４．２．使用例のＳＴＡトポロジー
図２０に、本開示の目的を説明するために利用するネットワークトポロジーの実施形態例７０を示す。なお、本開示の装置及び方法は特定のネットワークトポロジーに限定されるものではないため、このトポロジー（及び本明細書で例示するいずれかのトポロジー）は限定ではなく一例として示すものであると理解されたい。また、本開示全体を通じて参照する特定のＭＬＤ、ＳＴＡ及びリンクは、動作の理解を単純化するために示すものにすぎない。
図２０に、本開示の目的を説明するために利用するネットワークトポロジーの実施形態例７０を示す。なお、本開示の装置及び方法は特定のネットワークトポロジーに限定されるものではないため、このトポロジー（及び本明細書で例示するいずれかのトポロジー）は限定ではなく一例として示すものであると理解されたい。また、本開示全体を通じて参照する特定のＭＬＤ、ＳＴＡ及びリンクは、動作の理解を単純化するために示すものにすぎない。
【0069】
あるＭＬＤにＡＰ局が所属している場合、そのＭＬＤはＡＰ ＭＬＤである。あるＭＬＤに非ＡＰ ＳＴＡが所属している場合、そのＭＬＤは非ＡＰ ＭＬＤである。
【0070】
図２０に示すように、このシナリオでは、ここでは部屋として例示する所与のエリア内に３つのＭＬＤから成る６つのＳＴＡを示す。ＡＰ１及びＡＰ２は、ＭＬＤ１として示すマルチリンク装置（ＭＬＤ）に所属し、ＳＴＡ１及びＳＴＡ４はＭＬＤ２に所属し、ＳＴＡ３及びＳＴＡ５はＭＬＤ３に所属する。ＳＴＡ２及びＳＴＡ６は、リンク１上で動作する非ＡＰ ＳＴＡ又はシングルリンクＭＬＤ（すなわち、１つのＳＴＡのみを有して１つのリンク上で動作する特別なＭＬＤ）であることができる。ＳＴＡ１、ＳＴＡ２、ＳＴＡ３、ＳＴＡ６はリンク１を介してＡＰ１に関連付けられ、ＳＴＡ４及びＳＴＡ５はリンク２を介してＡＰ２に関連付けられる。全てのＳＴＡは、全てのリンク上でランダムチャネルアクセス（ＣＳＭＡ／ＣＡ）のためにＥＤＣＡを使用する。
【0071】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴをスケジュールして告知することができる。被Ｒ－ＴＷＴスケジュール側ＳＴＡ（スケジューリング対応ＳＴＡ）は、Ｒ－ＴＷＴスケジュール側ＡＰからのＲ－ＴＷＴ告知を受け取って認識し、Ｒ－ＴＷＴ動作をサポートできる非ＡＰ ＳＴＡである。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴスケジュール側ＡＰとの間でＲ－ＴＷＴのメンバーシップをネゴシエートすることができる。被Ｒ－ＴＷＴスケジュール側ＳＴＡがＲ－ＴＷＴのメンバーＳＴＡになると、被Ｒ－ＴＷＴスケジュール側ＳＴＡ（すなわち、Ｒ－ＴＷＴメンバーＳＴＡ）のトラフィック（例えば、ＵＬ、ＤＬ及び／又はＰ２Ｐ）がスケジュールされ、そのＲ－ＴＷＴのＳＰ中に優先的に送信される。
【0072】
ＡＰ１及びＡＰ２はＲ－ＴＷＴスケジュール側ＡＰであり、ＳＴＡ１～ＳＴＡ５は被Ｒ－ＴＷＴスケジュール側ＳＴＡであり、ＳＴＡ６は被Ｒ－ＴＷＴスケジュール側ＳＴＡではない。
【0073】
４．３．ＳＣＳトラフィックのためのＲ－ＴＷＴスケジューリングのネゴシエーション
Ｒ－ＴＷＴｘによって示すＲ－ＴＷＴのスケジューリングは、Ｒ－ＴＷＴスケジュール側ＡＰによって告知される。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴｘのメンバーシップを要求することができる。さらに、Ｒ－ＴＷＴｘ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰは、どのトラフィックストリームが高優先度で送信されると予想されるかを決定／認識することができる。本節では、被Ｒ－ＴＷＴスケジュール側ＳＴＡが、Ｒ－ＴＷＴｘのメンバーシップを設定する際にＲ－ＴＷＴｘ ＳＰ中にどのトラフィックストリームを高優先度で送信すべきかについてＲ－ＴＷＴスケジュール側ＡＰとネゴシエートする方法について説明する。被Ｒ－ＴＷＴスケジュール側ＳＴＡがＲ－ＴＷＴｘのメンバーＳＴＡになった後、Ｒ－ＴＷＴｘメンバーシップ合意されたこれらのトラフィックストリームはＲ－ＴＷＴｘ ＳＰ中に高優先度で送信され、このようなトラフィックストリームをＲ－ＴＷＴｘのスケジュールされたトラフィックストリームとして示す。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームのみがＲ－ＴＷＴｘ ＳＰ中の送信を許可される。例えば、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームに属していないフレームは、Ｒ－ＴＷＴｘ ＳＰ中に送信を許可されず、又は低優先度での送信しか許可されない。なお、高優先度のトラフィックは、低優先度のトラフィックよりも早く送信される確率が高いトラフィックを表す。さらに、少なくとも１つの実施形態／モード／事例では、高優先度のトラフィックを低優先度のトラフィックよりも早く送信する必要がある。
Ｒ－ＴＷＴｘによって示すＲ－ＴＷＴのスケジューリングは、Ｒ－ＴＷＴスケジュール側ＡＰによって告知される。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴｘのメンバーシップを要求することができる。さらに、Ｒ－ＴＷＴｘ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰは、どのトラフィックストリームが高優先度で送信されると予想されるかを決定／認識することができる。本節では、被Ｒ－ＴＷＴスケジュール側ＳＴＡが、Ｒ－ＴＷＴｘのメンバーシップを設定する際にＲ－ＴＷＴｘ ＳＰ中にどのトラフィックストリームを高優先度で送信すべきかについてＲ－ＴＷＴスケジュール側ＡＰとネゴシエートする方法について説明する。被Ｒ－ＴＷＴスケジュール側ＳＴＡがＲ－ＴＷＴｘのメンバーＳＴＡになった後、Ｒ－ＴＷＴｘメンバーシップ合意されたこれらのトラフィックストリームはＲ－ＴＷＴｘ ＳＰ中に高優先度で送信され、このようなトラフィックストリームをＲ－ＴＷＴｘのスケジュールされたトラフィックストリームとして示す。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームのみがＲ－ＴＷＴｘ ＳＰ中の送信を許可される。例えば、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームに属していないフレームは、Ｒ－ＴＷＴｘ ＳＰ中に送信を許可されず、又は低優先度での送信しか許可されない。なお、高優先度のトラフィックは、低優先度のトラフィックよりも早く送信される確率が高いトラフィックを表す。さらに、少なくとも１つの実施形態／モード／事例では、高優先度のトラフィックを低優先度のトラフィックよりも早く送信する必要がある。
【0074】
一方で、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームと同じＴＩＤを有していて再送される必要があるフレームが存在する場合には例外が発生することもあるが、これらのフレームはＲ－ＴＷＴｘのスケジュールされたトラフィックストリームに属していないので、Ｒ－ＴＷＴｘ ＳＰ中に送信することができる。ＳＴＡがそのＴＩＤにブロック確認応答を使用する場合、これらのフレームは、そのＳＴＡがＲ－ＴＷＴｘ ＳＰ中に同じＴＩＤを有するＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームを送信する前に送信すべきである。この例外が発生する理由は、これらのフレームのシーケンス番号が割り当てられており、これらのフレームがＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームよりも小さいからである。
【0075】
【0076】
図２１には、被Ｒ－ＴＷＴスケジュール側ＳＴＡとＲ－ＴＷＴスケジュール側ＡＰとの間のＳＣＳトラフィックストリーム情報を伴うＲ－ＴＷＴｘのメンバーシップ設定（ネゴシエーション）のシグナリングを示す。図１５と同様に、非ＡＰ ＳＴＡ（被Ｒ－ＴＷＴスケジュール側ＳＴＡ）は、ＡＰ（Ｒ－ＴＷＴスケジュール側ＡＰ）にＲ－ＴＷＴｘのメンバーシップを要求するＴＷＴ設定フレーム（すなわち、Ｒ－ＴＷＴメンバーシップ要求フレーム）を送信する。その後、ＡＰは、非ＡＰ ＳＴＡのＲ－ＴＷＴｘメンバーシップステータスの結果を示すＴＷＴ設定フレーム（すなわち、Ｒ－ＴＷＴメンバーシップ応答フレーム）を返送する。
【0077】
図１５と比較すると、ここでの違いは、Ｒ－ＴＷＴメンバーシップ設定手順中にＴＷＴ設定フレームがＳＣＳトラフィックストリームの情報を伝えることができる点である。図２２には、ＳＣＳトラフィックストリーム情報を含むＴＷＴ設定フレームのフォーマットを示す。
【0078】
Ｒ－ＴＷＴ設定を実行するには、非ＡＰ ＳＴＡ ＳＭＥ１１２が非ＡＰ ＳＴＡ ＭＬＭＥ１１４にＭＬＭＥ－ＴＷＴＳＥＴＵＰ要求１２０を送信し、非ＡＰ ＳＴＡ ＭＬＭＥ１１４が、ＳＣＳトラフィック情報１２２を含むＴＷＴ設定フレームをＡＰ ＭＬＭＥ１１６に送信する。ＡＰは、これをそのＳＭＥ１１８にＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｉｎｄｉｃａｔｉｏｎ１２４として送信し、ＳＭＥは、この要求を処理して、そのＭＬＭＥ１１６にＭＬＭＬ－ＴＷＴＳＥＴＵＰ．ｒｅｓｐｏｎｓｅ１２８を出力し、ＭＬＭＥ１１６は、ＳＣＳトラフィック情報１３０を含むＴＷＴ設定フレームを非ＡＰ ＳＴＡ ＭＬＭＥ１１４に送信し、非ＡＰ ＳＴＡ ＭＬＭＥ１１４は、そのＳＭＥ１１２にＭＬＭＥ－ＴＷＴＳＥＴＵＰ．ｃｏｎｆｉｒｍ１３２を送信する。
【0079】
例えば、ＴＷＴ設定フレーム内のブロードキャストＴＷＴパラメータセットフィールドがＲ－ＴＷＴｘのためのものである場合、そのブロードキャストＴＷＴパラメータセットフィールド内のＳＣＳＩＤリストは、ＳＣＳトラフィックストリームの情報を伝える。非ＡＰ ＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ中にＡＰがこれらのＳＣＳトラフィックストリームの送信をスケジュールすることを要求する目的で、ＴＷＴ設定フレームにＲ－ＴＷＴｘメンバーシップネゴシエーションの一部としてＳＣＳトラフィックストリームの情報を埋め込む。ＡＰは、非ＡＰ ＳＴＡからのＲ－ＴＷＴｘメンバーシップ要求を受け入れると、対応するＲ－ＴＷＴ設定フレームにＳＣＳトラフィックストリームの情報を埋め込んで、これらのＳＣＳトラフィックストリームがＲ－ＴＷＴｘのスケジュールされたトラフィックストリームであることを示すことができる。なお、ＡＰは、Ｒ－ＴＷＴｘのメンバーシップ要求を受け入れるかどうかを、Ｒ－ＴＷＴｘのＳＣＳトラフィックストリームの情報に基づいて判定する。ＡＰは、Ｒ－ＴＷＴｘ ＳＰ中にＳＣＳトラフィックストリームのＱｏＳ要件を満たすことができる場合、非ＡＰ ＳＴＡからのＲ－ＴＷＴｘメンバーシップ要求を受け入れることができる。その後、ＡＰは、Ｒ－ＴＷＴ設定フレームの対応するブロードキャストＴＷＴパラメータセットフィールド内に、ＡＰがＳＣＳＩＤリストフィールドに示されるＳＣＳトラフィックストリームをＲ－ＴＷＴｘ ＳＰ中に送信できることを示すようにＳＣＳＩＤリストフィールドを設定することができる。そうでなければ、ＡＰはＲ－ＴＷＴ メンバーシップ要求を拒絶することができる。
【0080】
少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴメンバーシップ要求が受け入れられた時に、Ｒ－ＴＷＴメンバーシップ応答フレームの対応するブロードキャストＴＷＴパラメータセットフィールド内のＳＣＳＩＤリストフィールドが、対応するＲ－ＴＷＴメンバーシップ要求内のものと重複する。
【0081】
少なくとも１つの実施形態／モード／事例では、ＡＰが、Ｒ－ＴＷＴｘメンバーシップ要求を受け入れる場合に、Ｒ－ＴＷＴｘメンバーシップ要求に対する応答にＳＣＳトラフィックストリーム情報を埋め込まない。この時、対応するＲ－ＴＷＴメンバーシップ要求に示されるＳＣＳトラフィックストリームは、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームである。
【0082】
ＳＣＳＩＤリスト（ＳＣＳＩＤ ｌｉｓｔ）フィールドは、ＳＣＳＩＤフィールドの数を識別する数字、及びその後の同じ数のＳＣＳＩＤフィールドから成る。各ＳＣＳＩＤは、非ＡＰとＡＰとの間で確立された既存のＳＣＳを表す。なお、ＳＣＳ設定手順については既に図１０で説明している。
【0083】
少なくとも１つの実施形態では、ＳＣＳＩＤリストフィールドの存在を示すためにブロードキャストＴＷＴパラメータセットフィールド内の予備ビットが利用される。例えば、１つの実施形態では、このビットが第１の状態（例えば、「１」）に設定された場合、ブロードキャストＴＷＴパラメータセットフィールド内にＳＣＳＩＤリストフィールドが存在することを示す。このビットが第２の状態（例えば、「０」）に設定された場合には、ブロードキャストＴＷＴパラメータセットフィールド内にＳＣＳＩＤリストフィールドが存在しないことを示す。
【0084】
被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームと共にＲ－ＴＷＴｘのメンバーＳＴＡになると、Ｒ－ＴＷＴｘ ＳＰ中に送信又は受信すべきＲ－ＴＷＴｘのスケジュールされたトラフィックストリームを有する。Ｒ－ＴＷＴｘのメンバーＳＴＡ及びＲ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰ中に交換すべきＲ－ＴＷＴｘの各スケジュールされたトラフィックストリームの量を表す範囲を予想する。限定ではなく一例として、以下の範囲タイプについて説明する。
【0085】
（ａ）Ｒ－ＴＷＴｘのスケジュールされたＤＬ（又はＵＬ及び／又はＰ２Ｐ）ＳＣＳトラフィックストリームは、そのＴＳＰＥＣ要素内に、Ｒmin（ビット／秒）に設定された最小データレートフィールドを有する。２つの連続するＲ－ＴＷＴｘ ＳＰの終了時刻間の時間をｔ（秒）とする。すると、時間ｔ中にＲ－ＴＷＴスケジュール側ＡＰ（又は、このスケジュールされたトラフィックストリームを有するＲ－ＴＷＴｘメンバーＳＴＡ）に到着すると予想されるスケジュールされたＤＬ（又はＵＬ及び／又はＰ２Ｐ）トラフィックストリームの最小量はＲmin
*ｔ（ビット）である。Ｒ－ＴＷＴスケジュール側ＡＰ（又は、このスケジュールされたトラフィックストリームを有するＲ－ＴＷＴｘメンバーＳＴＡ）は、第２のＲ－ＴＷＴｘ ＳＰの終了前に少なくともＲmin
*ｔ（ビット）のトラフィックを送信していると予想することができる。
【0086】
（ｂ）Ｒ－ＴＷＴｘのスケジュールされたＤＬ（又はＵＬ及び／又はＰ２Ｐ）ＳＣＳトラフィックストリームは、そのＴＳＰＥＣ要素内に、Ｒmean（ビット／秒）に設定された平均データレートフィールドを有する。２つの連続するＲ－ＴＷＴｘ ＳＰの終了時刻間の時間をｔ（秒）とする。すると、時間ｔ中にＲ－ＴＷＴスケジュール側ＡＰ（又は、このスケジュールされたトラフィックストリームを有するＲ－ＴＷＴｘメンバーＳＴＡ）に到着すると予想されるスケジュールされたＤＬ（又はＵＬ及びＰ２Ｐ）トラフィックストリームの平均量はＲmean
*ｔ（ビット）である。従って、Ｒ－ＴＷＴスケジュール側ＡＰ（又は、このスケジュールされたトラフィックストリームを有するＲ－ＴＷＴｘメンバーＳＴＡ）は、第２のＲ－ＴＷＴｘ ＳＰの終了前に平均してＲmean
*ｔ（ビット）のトラフィックを送信していると予想することができる。
【0087】
（ｃ）Ｒ－ＴＷＴｘのスケジュールされたＤＬ（又はＵＬ及び／又はＰ２Ｐ）ＳＣＳトラフィックストリームは、そのＴＳＰＥＣ要素内に、Ｒmax（ビット／秒）に設定されたピークデータレートフィールドを有する。２つの連続するＲ－ＴＷＴｘ ＳＰの終了時刻間の時間をｔ（秒）とする。すると、時間ｔ中にＲ－ＴＷＴスケジュール側ＡＰ（又は、このスケジュールされたトラフィックストリームを有するＲ－ＴＷＴｘメンバーＳＴＡ）に到着すると予想されるスケジュールされたＤＬ（又はＵＬ及び／又はＰ２Ｐ）トラフィックストリームの平均量はＲmax
*ｔ（ビット）である。Ｒ－ＴＷＴスケジュール側ＡＰ（又は、このスケジュールされたトラフィックストリームを有するＲ－ＴＷＴｘメンバーＳＴＡ）は、第２のＲ－ＴＷＴｘ ＳＰの終了前に最大でＲmax
*ｔ（ビット）のトラフィックを送信すると予想することができる。
【0088】
Ｒ－ＴＷＴのブロードキャストＴＷＴパラメータセットフィールドには、（図７に示すような）ＩＥＥＥ８０２．１１ａｘで定められるフィールドの他に、少なくとも１つの実施形態／モード／事例ではそのＲ－ＴＷＴ ＳＰがスケジュールされるリンクを示すリンクＩＤフィールドが追加される。少なくとも１つの実施形態／モード／事例では、このリンクＩＤフィールドの存在を示すために、ブロードキャストＴＷＴパラメータセットフィールドの予備ビットが利用される。このビットが第１の状態（例えば、「１」）に設定された場合、ブロードキャストＴＷＴパラメータセットフィールド内にリンクＩＤフィールドが存在することを示す。このビットが第２の状態（例えば、「０」）に設定された場合には、ブロードキャストＴＷＴパラメータセットフィールド内にリンクＩＤフィールドが存在せず、このブロードキャストＴＷＴパラメータセットフィールドが送信されるリンク上でＲ－ＴＷＴ ＳＰがスケジュールされることを示す。
【0089】
１つのＴＷＴ要素は、同じ又は異なるＲ－ＴＷＴ ＩＤ（すなわち、図９に示すようなブロードキャストＴＷＴ ＩＤフィールドに設定された値）を有する複数のブロードキャストＴＷＴパラメータセットフィールドを有することができる。同じＲ－ＴＷＴ ＩＤ及び異なるリンクＩＤを有する複数のブロードキャストＴＷＴパラメータセットフィールドを１つのＴＷＴ要素に組み込んで、複数のリンク上でスケジュールされるＳＰを有するＲ－ＴＷＴを示すことができる。例えば、１つのＴＷＴ要素における、Ｒ－ＴＷＴ ＩＤが「４」に等しくリンクＩＤが「１」に等しい１つのブロードキャストＴＷＴパラメータセットフィールド、及びＲ－ＴＷＴ ＩＤが「４」に等しくリンクＩＤが「２」に等しい１つのブロードキャストＴＷＴパラメータセットフィールドは、ＴＷＴ ＩＤが「４」であってリンク１上及びリンク２上でＳＰがスケジュールされるＲ－ＴＷＴを表す。
【0090】
４．４．Ｒ－ＴＷＴメンバーではない被Ｒ－ＴＷＴスケジュール側ＳＴＡへの報奨
Ｒ－ＴＷＴ ＳＰ中、ＳＴＡは、被Ｒ－ＴＷＴスケジュール側ＳＴＡではあるがそのＲ－ＴＷＴのメンバーＳＴＡでない場合、ＳＰの存在に起因して、送信機会（ＴＸＯＰ）を取得する機会又はチャネルにアクセスする機会を犠牲にすることがある。例えば、ＳＴＡは、ＳＰの開始時刻前にそのＴＸＯＰを終了し、或いはＳＰ中にチャネルを求める競合を停止（中止）する。従って、本開示の少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴ動作のサポートを促すために、このようなＳＴＡ、特にＲ－ＴＷＴスケジュール側ＡＰによってスケジュールされたいずれかのＲ－ＴＷＴのメンバーでないＳＴＡのための報酬メカニズムを提供する。なお、Ｒ－ＴＷＴ ＳＰ中には、そのＲ－ＴＷＴのメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡはスリープ状態に入るように構成されていないのでアウェイク中のはずである。
Ｒ－ＴＷＴ ＳＰ中、ＳＴＡは、被Ｒ－ＴＷＴスケジュール側ＳＴＡではあるがそのＲ－ＴＷＴのメンバーＳＴＡでない場合、ＳＰの存在に起因して、送信機会（ＴＸＯＰ）を取得する機会又はチャネルにアクセスする機会を犠牲にすることがある。例えば、ＳＴＡは、ＳＰの開始時刻前にそのＴＸＯＰを終了し、或いはＳＰ中にチャネルを求める競合を停止（中止）する。従って、本開示の少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴ動作のサポートを促すために、このようなＳＴＡ、特にＲ－ＴＷＴスケジュール側ＡＰによってスケジュールされたいずれかのＲ－ＴＷＴのメンバーでないＳＴＡのための報酬メカニズムを提供する。なお、Ｒ－ＴＷＴ ＳＰ中には、そのＲ－ＴＷＴのメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡはスリープ状態に入るように構成されていないのでアウェイク中のはずである。
【0091】
ＩＥＥＥ８０２．１１ｂｅにおける被Ｒ－ＴＷＴスケジュール側ＳＴＡは、制限付きＴＷＴ動作をサポートして、送信されるＥＨＴ能力要素内の制限付きＴＷＴサポートサブフィールドを第１の状態（例えば、「１」）に設定する、非ＡＰ極高スループット（Ｅｘｔｒｅｍｅｌｙ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ：ＥＨＴ）ＳＴＡである。非ＡＰ ＥＨＴ ＳＴＡが制限付きＴＷＴ動作をサポートしていない場合、このＳＴＡは被Ｒ－ＴＷＴスケジュール側ＳＴＡではなく、送信されるＥＨＴ能力要素内の制限付きＴＷＴサポートサブフィールドを第２の状態（例えば、「０」）に設定する。なお、非ＡＰ ＥＨＴ ＳＴＡは、自機のＥＨＴ能力を示すために、関連するＡＰにＥＨＴ能力要素を送信する。従って、Ｒ－ＴＷＴスケジュール側ＡＰは、ＥＨＴ ＳＴＡから受け取った送信されたＥＨＴ能力要素の制限付きＴＷＴサポートサブフィールドに従って、関連するＥＨＴ ＳＴＡが被制限付きＴＷＴ（Ｒ－ＴＷＴ）スケジュール側ＳＴＡであるか否かを識別することができる。
【0092】
Ｒ－ＴＷＴスケジュール側ＡＰによってスケジュールされるＲ－ＴＷＴ（スケジューリング）をＲ－ＴＷＴｘとする。すると、非ＡＰ ＳＴＡは、Ｒ－ＴＷＴｘのＳＰ中に以下の３つのタイプのうちの１つであることができる。
【0093】
（ａ）被Ｒ－ＴＷＴスケジュール側ＳＴＡであるがＲ－ＴＷＴｘのメンバーＳＴＡではないＳＴＡ。このＳＴＡは、Ｒ－ＴＷＴｘ ＳＰの開始時刻前にそのＴＸＯＰを終了する。このＳＴＡは、Ｒ－ＴＷＴｘのＳＰと重複するクワイエット間隔中にクワイエットモードに入ることができる。このＳＴＡは、いくつかの事例ではＲ－ＴＷＴｘのＳＰ中にチャネルアクセス権を求めて競合することができる。なお、Ｒ－ＴＷＴスケジュール側ＡＰは、ＳＴＡがＲ－ＴＷＴｘのＳＰと重複するクワイエット間隔中にクワイエットモードに入るかどうか、或いはＲ－ＴＷＴｘのＳＰ中にチャネルを求める競合を停止するか否かを、ＳＴＡがＲ－ＴＷＴスケジュール側ＡＰにこの情報を送信しない限り知らない場合がある。例えば、このＳＴＡは、この情報をＲ－ＴＷＴスケジュール側ＡＰに送信するために、送信されるＥＨＴ能力要素（又は他の要素）内にＲ－ＴＷＴクワイエットサポート（Ｒ－ＴＷＴ ｑｕｉｅｔ Ｓｕｐｐｏｒｔ）サブフィールド及びＲ－ＴＷＴチャネル競合（Ｒ－ＴＷＴ ｃｈａｎｎｅｌ ｃｏｎｔｅｎｔｉｏｎ）サブフィールドを追加することができる。
【0094】
（ａ）（ｉ）Ｒ－ＴＷＴクワイエットサポート（Ｒ－ＴＷＴ ｑｕｉｅｔ Ｓｕｐｐｏｒｔ）サブフィールドは、Ｒ－ＴＷＴ ＳＰと重複するクワイエット間隔中にこのフィールドの送信側がクワイエットモードに入るかどうかを示すように設定される。このフィールドが第１の状態（例えば、「１」）に設定された場合、このフィールドの送信側は、Ｒ－ＴＷＴ ＳＰと重複するクワイエット間隔中にクワイエットモードに入る。そうでなければ、このフィールドは第２の状態（例えば、「０」）に設定され、このフィールドの送信側は、Ｒ－ＴＷＴ ＳＰと重複するクワイエット間隔中にクワイエットモードに入らない。このフィールドを受け取ったＲ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰと重複するクワイエット間隔中に予想される送信側ＳＴＡの動作を判定することができる。なお、クワイエット間隔は、Ｒ－ＴＷＴスケジュール側ＡＰからのクワイエット要素によって告知される。
【0095】
（ａ）（ｉｉ）Ｒ－ＴＷＴチャネル競合サブフィールドは、このフィールドの送信側がそのＲ－ＴＷＴ ＳＰのメンバーでない（すなわち、このＳＰをスケジュールするＲ－ＴＷＴのメンバーでない）場合にＲ－ＴＷＴ ＳＰ中にチャネルを求めて競合するかどうかを示すように設定される。このフィールドが第１の状態（例えば、「１」）に設定された場合、このフィールドの送信側は、そのＲ－ＴＷＴ ＳＰのメンバーでない場合にＲ－ＴＷＴ ＳＰ中にチャネルを求めて競合する。そうでなければ、このフィールドは第２の状態（例えば、「０」）に設定され、このフィールドの送信側は、Ｒ－ＴＷＴ ＳＰのメンバーＳＴＡでない場合にＲ－ＴＷＴ ＳＰ中にチャネルを求めて競合しない。このようなＳＴＡは、メンバーではないＲ－ＴＷＴ ＳＰ中にバックオフカウンタを一時停止することができる。このフィールドを受け取ったＲ－ＴＷＴスケジュール側ＡＰは、特に送信側ＳＴＡがそのＲ－ＴＷＴ ＳＰのメンバーＳＴＡでない場合に、Ｒ－ＴＷＴ ＳＰ中の送信側ＳＴＡの予想されるチャネル競合動作を判定することができる。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴスケジュール側ＡＰによってスケジュールされたＲ－ＴＷＴのメンバーである被Ｒ－ＴＷＴスケジュール側ＳＴＡが、自機がメンバーＳＴＡではない全てのＲ－ＴＷＴ ＳＰ中にチャネルを求める競合を強制的に停止（中止）する必要がある。
【0096】
（ｂ）Ｒ－ＴＷＴｘのメンバーＳＴＡであるＳＴＡ。Ｒ－ＴＷＴｘのメンバーＳＴＡは、４．３節に示すようなＲ－ＴＷＴｘメンバーシップネゴシエーション中に、ＩＥＥＥ８０２．１１ｂｅに定められるようなＳＣＳトラフィックストリーム又はＲ－ＴＷＴ ＴＩＤなどのＲ－ＴＷＴｘのスケジュールされたトラフィックストリームをネゴシエートすることができる。
【0097】
（ｃ）被Ｒ－ＴＷＴスケジュール側ＳＴＡではないＳＴＡ。このようなＳＴＡは、Ｒ－ＴＷＴｘ ＳＰの開始時刻前にそのＴＸＯＰを終了することも、Ｒ－ＴＷＴｘのＳＰ中にチャネルを求める競合を停止することもない。
【0098】
（ｃ）（ｉ）いくつかの事例では、このようなＳＴＡが、クワイエット要素によって告知されたクワイエット間隔中にクワイエット状態を維持することができる。このようなＳＴＡは、クワイエット間隔中にクワイエットモードに入った場合、Ｒ－ＴＷＴクワイエットサポートサブフィールドを第１の状態（例えば、「１」）に設定することによってＲ－ＴＷＴスケジュール側ＡＰにその旨を報告することができる。
【0099】
Ｒ－ＴＷＴｘ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームの送信（すなわちフレーム交換）を優先し、及び／又はこのような送信のみを許可する。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰの予定終了時刻前に全てのＲ－ＴＷＴｘメンバーＳＴＡとの間でＲ－ＴＷＴｘの全てのスケジュールされたトラフィックストリームを送信し終えた場合、残りのＳＰ時間を使用して、被Ｒ－ＴＷＴスケジュール側ＳＴＡであるがＲ－ＴＷＴｘのメンバーＳＴＡではないＳＴＡ、及び被Ｒ－ＴＷＴスケジュール側ＳＴＡではないがＲ－ＴＷＴクワイエットサポートサブフィールドを第１の状態（例えば、「１」）に設定したままのＳＴＡとフレームを交換することができる。
【0100】
Ｒ－ＴＷＴスケジュール側ＡＰは、（ａ）これらのＳＴＡからのＴＢ ＰＰＤＵをトリガーするトリガーフレーム、（ｂ）これらのＳＴＡへのＤＬ ＰＰＤＵ、及び／又は（ｃ）ＩＥＥＥ８０２．１１ｂｅで定められるＭＵ－ＲＴＳ ＴＸＳフレームなどのトリガーフレームを送信して、これらのＳＴＡが送信に使用できるトリガーされたＴＸＯＰ共有時間を開始することができる。
【0101】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰの終了を示すためにのみこれらのＳＴＡにフレームを送信し、従ってチャネルを求めて競合するために直ちにこれらを解放することができる。
【0102】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたトラフィックストリームをＭＵ ＰＰＤＵで送信する場合、スケジュールされたトラフィックストリームに必要とされるＭＵ ＰＰＤＵの送信時間が増加しなければ、被Ｒ－ＴＷＴスケジュール側ＳＴＡであるがＲ－ＴＷＴｘのメンバーＳＴＡではないＳＴＡとの間でフレームを送信するためにリソースユニット（ＲＵ）を割り当てることができる。
【0103】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたＵＬトラフィックストリームをトリガーするトリガーフレームを送信する場合、スケジュールされたＵＬトラフィックストリームに必要とされるＴＢ ＰＰＤＵの送信時間が増加しなければ、被Ｒ－ＴＷＴスケジュール側ＳＴＡであるがＲ－ＴＷＴｘのメンバーＳＴＡではないＳＴＡからのフレームをトリガーするためにＲＵを割り当てることができる。
【0104】
Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのバッファが存在しない場合にも、スケジュール側ＡＰは、被Ｒ－ＴＷＴスケジュール側ＳＴＡであるがＲ－ＴＷＴｘのメンバーＳＴＡではないＳＴＡとフレームを交換することができる。
【0105】
Ｒ－ＴＷＴスケジュール側ＡＰが、被Ｒ－ＴＷＴスケジュール側ＳＴＡであるがＲ－ＴＷＴｘのメンバーＳＴＡではないＳＴＡからのＴＢ ＰＰＤＵをトリガーするトリガーフレームを送信できる場合、これらのＳＴＡは、ＴＢ ＰＰＤＵの送信後にＭＵ－ＥＤＣＡを使用しないことも、或いはチャネルを求めて競合するためにバックオフカウンタをリセットしないこともできる。トリガーフレームは、特定のＳＴＡグループがＲＡ－ＲＵを通じてＴＢ ＰＰＤＵを送信するためのＲＡ－ＲＵアップリンクＯＦＤＭＡランダムアクセス（ＵＯＲＡ）を有することができる。
【0106】
ＲＡ－ＲＵのユーザ情報フィールドのＡＩＤは、例えば現在のＩＥＥＥ８０２．１１ａｘで予備とされる「２０４７」～「４０９４」の間の選択値範囲内でＳＴＡグループを表すことができる。ＳＴＡは、自機が属するＳＴＡグループに設定されたＡＩＤを受け取ると、ＲＡ－ＲＵにアクセスすることができる。
【0107】
ＳＴＡグループは複数存在することができ、各グループは異なるＡＩＤを使用する。ＳＴＡは、複数のＳＴＡグループ（例えば、ｓｕｂｇｒｏｕｐ１～ｓｕｂｇｒｏｕｐ６）に属することができる。
【0108】
トリガーフレームは、１又は２以上の個々のＳＴＡにＲＵを割り当てることができる。個々のＳＴＡは、後述するようなサブグループの一部のＳＴＡであることしかできない。例えば、個々のＳＴＡはＳｕｂｇｒｏｕｐ１のＳＴＡであることしかできない。
【0109】
ＳＴＡグループは、１又は２以上の以下のサブグループから成ることができる。
【0110】
（１）Ｓｕｂｇｒｏｕｐ１：Ｒ－ＴＷＴスケジュール側ＡＰのいずれのＲ－ＴＷＴのメンバーＳＴＡでもなく、Ｒ－ＴＷＴチャネル競合サブフィールドを第１の状態（例えば、「１」）に等しく設定した全ての被Ｒ－ＴＷＴスケジュール側ＳＴＡ。
【0111】
（２）Ｓｕｂｇｒｏｕｐ２：Ｒ－ＴＷＴスケジュール側ＡＰのいずれのＲ－ＴＷＴのメンバーＳＴＡでもなく、Ｒ－ＴＷＴチャネル競合サブフィールドを第２の状態（例えば、「０」）に設定し、Ｒ－ＴＷＴクワイエットサポートサブフィールドを第１の状態（例えば、「１」）に設定した全ての被Ｒ－ＴＷＴスケジュール側ＳＴＡ。
【0112】
（３）Ｓｕｂｇｒｏｕｐ３：Ｒ－ＴＷＴスケジュール側ＡＰのいずれのＲ－ＴＷＴのメンバーＳＴＡでもなく、Ｒ－ＴＷＴチャネル競合サブフィールドを第２の状態（例えば、「０」）に設定し、Ｒ－ＴＷＴクワイエットサポートサブフィールドを第２の状態（例えば、「０」）に設定した全ての被Ｒ－ＴＷＴスケジュール側ＳＴＡ。
【0113】
（４）Ｓｕｂｇｒｏｕｐ４：被Ｒ－ＴＷＴスケジュール側ＳＴＡでなく、Ｒ－ＴＷＴクワイエットサポートサブフィールドを第１の状態（例えば、「１」）に設定した全てのＳＴＡ。
【0114】
（５）Ｓｕｂｇｒｏｕｐ５：Ｒ－ＴＷＴｘのメンバーＳＴＡではないがＲ－ＴＷＴスケジュール側ＡＰの他のＲ－ＴＷＴのメンバーＳＴＡであり、Ｒ－ＴＷＴチャネル競合サブフィールドを第１の状態（例えば、「１」）に設定した全ての被Ｒ－ＴＷＴスケジュール側ＳＴＡ。
【0115】
（６）Ｓｕｂｇｒｏｕｐ６：Ｒ－ＴＷＴｘのメンバーＳＴＡではないがＲ－ＴＷＴスケジュール側ＡＰの他のＲ－ＴＷＴのメンバーであり、Ｒ－ＴＷＴチャネル競合サブフィールドを第２の状態（例えば、「０」）に設定した全ての被Ｒ－ＴＷＴスケジュール側ＳＴＡ。
【0116】
少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘ ＳＰ時間を使用する優先度をこれらのサブグループ間で設定することができる。一般に、複数のＲ－ＴＷＴ動作をサポートするサブグループのＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ時間を使用する優先度が高くなる。残りのＲ－ＴＷＴｘ ＳＰ時間を使用するＳＴＡの優先度は、例えばサブグループ番号順などの所望の優先順位、又は他のいずれかの所望のパターンで設定することができる。
【0117】
４．５．Ｒ－ＴＷＴ ＳＰの終了
４．３節では、被Ｒ－ＴＷＴスケジュール側ＳＴＡが、そのＲ－ＴＷＴのメンバーシップ及びＳＣＳトラフィックストリームなどのスケジュールされたトラフィックストリームをネゴシエートする方法について説明した。なお、Ｒ－ＴＷＴのメンバーＳＴＡは、そのＲ－ＴＷＴのスケジュールされたトラフィックストリームを複数有することができる。Ｒ－ＴＷＴは、複数のＲ－ＴＷＴメンバーＳＴＡを有することができる。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ、Ｒ－ＴＷＴｙ及びＲ－ＴＷＴｚなどの複数のＲ－ＴＷＴを告知することができる。
４．３節では、被Ｒ－ＴＷＴスケジュール側ＳＴＡが、そのＲ－ＴＷＴのメンバーシップ及びＳＣＳトラフィックストリームなどのスケジュールされたトラフィックストリームをネゴシエートする方法について説明した。なお、Ｒ－ＴＷＴのメンバーＳＴＡは、そのＲ－ＴＷＴのスケジュールされたトラフィックストリームを複数有することができる。Ｒ－ＴＷＴは、複数のＲ－ＴＷＴメンバーＳＴＡを有することができる。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ、Ｒ－ＴＷＴｙ及びＲ－ＴＷＴｚなどの複数のＲ－ＴＷＴを告知することができる。
【0118】
本節では、Ｒ－ＴＷＴ ＳＰを終了させる方法について説明する。本開示は、Ｒ－ＴＷＴのメンバーＳＴＡに、これらのＳＴＡがそのＲ－ＴＷＴ ＳＰ中に送信すべきスケジュールされたトラフィックストリームのフレームをそれ以上有していないことを示す信号をＲ－ＴＷＴスケジュール側ＡＰに送信させることを可能にする。Ｒ－ＴＷＴスケジュール側ＡＰは、全てのスケジュールされたトラフィックが送信されたことを認識すると、そのＲ－ＴＷＴのＳＰの終了を示す信号を送信する。
【0119】
Ｒ－ＴＷＴスケジュール側ＡＰ及び被Ｒ－ＴＷＴスケジュール側ＳＴＡは、図２７に示すようなＱｏＳ制御フィールドをＱｏＳデータ又はＱｏＳヌルフレームに埋め込むことができる。
【0120】
図２３に、Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰ（すなわち、Ｒ－ＴＷＴｘのＳＰ）を終了する実施形態例１７０を示す。説明を単純にするために、Ｒ－ＴＷＴスケジュール側ＡＰによってスケジュールされるＲ－ＴＷＴをＲ－ＴＷＴｘとして示す。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰ中に、Ｒ－ＴＷＴｘメンバーＳＴＡとの間でＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームの交換を開始する（１７２）。なお、Ｒ－ＴＷＴｘメンバーＳＴＡは、４．３節で説明したようにＲ－ＴＷＴｘのスケジュールされたトラフィックストリームをネゴシエートすることができる。
【0121】
最初に、図２３のフローチャートの概要を示す。ブロック１７２において、スケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘメンバーＳＴＡとの間でＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームの交換を開始する。
【0122】
チェック１７４において、Ｒ－ＴＷＴｘ ＳＰの予定終了時刻前に全てのスケジュールされたトラフィックが送信されたかどうかを判定する。全てのトラフィックが送信されていない場合、ブロック１８０において、スケジュール側ＡＰが予定終了時刻にＲ－ＴＷＴｘ ＳＰを終了し、プロセスは終了することができる。
【0123】
一方で、全てのスケジュールされたトラフィックが送信されて条件が満たされた場合、ブロック１７６において、スケジュール側ＡＰが、Ｒ－ＴＷＴｘ ＳＰの残り時間中にＲ－ＴＷＴｘのメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡとフレームを交換する。その後、スケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰの終了を示す信号を送信して（１７８）プロセスを終了する。
【0124】
以下の節では、図２３に示すやりとりのさらなる詳細を階層形態で示す。
【0125】
（ａ）いくつかの事例では、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴｘメンバーＳＴＡがＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレーム交換を開始する前に、Ｒ－ＴＷＴスケジュール側ＡＰ又はＲ－ＴＷＴメンバーＳＴＡのいずれかが、フレーム交換のためのＴＸＯＰを取得するためにチャネルを求めて競合する必要がある。少なくとも１つの実施形態又はモードでは、Ｒ－ＴＷＴスケジュール側ＡＰ又はＲ－ＴＷＴｘメンバーＳＴＡが、そのバッファ内にＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームが存在する場合にのみチャネルを求めて競合することができる。いくつかの事例では、Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのバッファを有していなくてもチャネルを求めて競合することができる。
【0126】
（ｂ）Ｒ－ＴＷＴスケジュール側ＡＰ又はＲ－ＴＷＴｘメンバーＳＴＡがチャネルアクセス権を獲得すると、ＲＴＳ／ＭＵ－ＲＴＳとＣＴＳとの交換を使用してＴＸＯＰを予約することができる。少なくとも１つの実施形態／モード／事例では、ＴＸＯＰ期間が、スケジュールされたＲ－ＴＷＴｘ ＳＰ時間（Ｒ－ＴＷＴｘ ＳＰの予定終了時刻－Ｒ－ＴＷＴｘ ＳＰのＲ－ＴＷＴ予定開始時刻）以下である必要がある。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘ ＳＰの予定終了時刻を超えるＴＸＯＰの予約が許可されない。ＴＸＯＰ中には、全てのＲ－ＴＷＴｘのスケジュールされたトラフィックストリームをＴＸＯＰのプライマリＡＣからのトラフィックとして送信することができる。
【0127】
（ｃ）少なくとも１つの実施形態／モード／事例では、被Ｒ－ＴＷＴスケジュール側ＳＴＡが、Ｒ－ＴＷＴｘ ＳＰと重複するＴＸＯＰを取得する予定である場合に、（ＭＵ）ＲＴＳ／ＣＴＳ交換を使用してそのＴＸＯＰを取得せざるを得ない。Ｒ－ＴＷＴスケジュール側ＡＰは、被Ｒ－ＴＷＴスケジュール側ＳＴＡによるＴＸＯＰの取得を許可しないこのようなＲＴＳを被Ｒ－ＴＷＴスケジュール側ＳＴＡから受け取った場合、ＣＴＳに応答しないことができる。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴスケジュール側ＡＰが、被Ｒ－ＴＷＴスケジュール側ＳＴＡからのこのようなＲＴＳに応答して、ＣＴＳフレーム内に任意のＮＡＶを設定する。その後、被Ｒ－ＴＷＴスケジュール側ＳＴＡは、ＣＴＳフレーム内のＮＡＶに等しいＴＸＯＰのみを取得する。
【0128】
（ｄ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘメンバーＳＴＡからのＲ－ＴＷＴｘのスケジュールされたＵＬトラフィックストリームのためのトリガーフレームを送信する。トリガーフレームは、いずれかのＳＴＡ（又は４．４節で説明したような１又は２以上のサブグループ）がＵＬ送信に使用できるＲＡ－ＲＵ（ＵＯＲＡ）を含むことができる。ＳＴＡにＲＡ－ＲＵを割り当てる優先度は、４．４節で説明したようなサブグループの優先度に従うことができる。少なくとも１つの実施形態／モード／事例では、トリガーフレーム内のＲＡ－ＲＵが、Ｒ－ＴＷＴｘのスケジュールされたＵＬトラフィックストリームに必要な求められるＴＢ ＰＰＤＵの送信時間がそのＲＡ－ＲＵによって増加しない場合にのみ許可される。
【0129】
（ｅ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴｘメンバーＳＴＡが、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの送信のためのＴＸＯＰを取得するためにＥＤＣＡを使用する。ＥＤＣＡ ＴＸＯＰが取得されると、少なくとも１つの実施形態／モード／事例では、プライマリＡＣ及び非プライマリＡＣからのものを含むＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの全てのフレームをこのＥＤＣＡ ＴＸＯＰ中に送信することができる。なお、プライマリＡＣは、ＥＤＣＡＦがＴＸＯＰを取得するＡＣに相当する。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームをバッファ内に有するＡＣのＥＤＣＡＦのみがチャネルを求めて競合することができる。
【0130】
（ｆ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのブロードキャストＴＷＴパラメータ情報フィールドの要求タイプフィールド内のトリガーフィールドがＲ－ＴＷＴスケジュール側ＡＰによって第１の状態（例えば、「１」）に設定されている場合、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴスケジュール側ＡＰのみがチャネルを求めて競合することができる。このフィールドが第２の状態（例えば、「０」）に設定されている場合には、Ｒ－ＴＷＴｘメンバーＳＴＡもＲ－ＴＷＴｘ ＳＰ中にチャネルを求めて競合することができる。
【0131】
（ｇ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームと同じＴＩＤを有するフレームが存在し、これらのフレームを再送する必要があるが、これらがいずれのＲ－ＴＷＴｘのスケジュールされたトラフィックストリームにも属していない場合、Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰ中にこれらのフレームを送信する。少なくとも１つの実施形態／モード／事例では、そのＴＩＤにブロック確認応答が使用される場合に、Ｒ－ＴＷＴスケジュール側ＡＰが、同じＴＩＤを有するＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームよりも早くＲ－ＴＷＴｘ ＳＰ中にこれらのフレームを送信する。このことが有益である理由は、これらのフレームのシーケンス番号が割り当てられており、これらのフレームの方がＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームよりも小さいからである。
【0132】
Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレーム交換を継続する。スケジュールされたトラフィックストリームは、アップリンク（ＵＬ）ストリーム、ダウンリンク（ＤＬ）ストリーム、及び／又はピアツーピア（Ｐ２Ｐ）ストリームであることができる。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘメンバーＳＴＡのスケジュールされたトラフィックストリームの全てのフレームがＲ－ＴＷＴｘ ＳＰ中に送信されたかどうかを知る（決定／認識する）必要がある。なお、Ｒ－ＴＷＴｘメンバーＳＴＡのＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの空のバッファステータスは、スケジュールされたトラフィックストリームの全てのフレームがＲ－ＴＷＴｘ ＳＰ中に送信された旨の有効な指標でない場合もある。スケジュールされたトラフィックストリームのフレームは、後でＲ－ＴＷＴｘ ＳＰの途中などにＲ－ＴＷＴｘメンバーＳＴＡに到着することもある。従って、本開示は、Ｒ－ＴＷＴｘメンバーＳＴＡのスケジュールされたトラフィックストリームの全てのフレームがＲ－ＴＷＴｘ ＳＰ中に送信されたことを明示的に示す信号を利用する一方で、空のバッファステータスレポートを使用することに依拠しない。明示的信号は、以下の形態をとることができる。
【0133】
（ａ）Ｒ－ＴＷＴｘのスケジュールされたＵＬ又はＰ２Ｐトラフィックストリームが存在する場合、Ｒ－ＴＷＴスケジュール側ＡＰは、図２４～図２６のフローチャートで説明するように、Ｒ－ＴＷＴｘ ＳＰ中に、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームを有する各Ｒ－ＴＷＴｘメンバーＳＴＡから、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームを送信したこと（すなわち、送信すべきＲ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームのフレームをそれ以上有していないこと）を示す信号を受け取ると予想する。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームを有する全てのＲ－ＴＷＴｘメンバーＳＴＡからこのような信号を受け取ると、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームが送信されたと認識する。
【0134】
（ｂ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘメンバーＳＴＡがＲ－ＴＷＴｘ ＳＰ中に送信すべきＲ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームのフレームをそれ以上有していないことを示す信号を送信する代わりに、Ｒ－ＴＷＴスケジュール側ＡＰが、以下の２つの条件が満たされた時に、Ｒ－ＴＷＴｘメンバーが送信すべきＲ－ＴＷＴｘのスケジュールされたＵＬトラフィック又はＰ２Ｐトラフィックストリームのさらなるフレームを有していないと認識する。
【0135】
（ｂ）（ｉ）Ｒ－ＴＷＴｘメンバーＳＴＡに到着すると予想される各スケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの最小量がＲ－ＴＷＴスケジュール側ＡＰによって受け取られる。例えば、Ｒ－ＴＷＴｘのスケジュールされたＵＬ ＳＣＳトラフィックストリームは、そのＴＳＰＥＣ要素内にＲmin（ビット／秒）に設定された最小データレートフィールドを有する。結果としての２つのＲ－ＴＷＴｘ ＳＰの終了時刻間の時間をｔ（秒）とする。すると、時間ｔ中にＲ－ＴＷＴｘメンバーＳＴＡに到着すると予想されるスケジュールされたＵＬ ＳＣＳトラフィックストリームの最小量はＲmin
*ｔ（ビット）である。Ｒ－ＴＷＴスケジュール側ＡＰは、第２のＲ－ＴＷＴｘ ＳＰの終了前にこれらＲmin
*ｔ（ビット）のトラフィックを全て受け取るべきである。
【0136】
（ｂ）（ｉｉ）全てのＲ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックステームのバッファが空である。Ｒ－ＴＷＴスケジュール側ＡＰは、この情報を要求するためにＢＳＲＰを送信することができる。また、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ中に、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームのバッファステータスのみをＲ－ＴＷＴｘスケジュール側ＡＰに報告することができる。
【0137】
（ｂ）（続き）Ｒ－ＴＷＴｘの各スケジュールされたＵＬ又はＰ２Ｐトラフィックストリームの最小量は、４．３節で説明したように計算できるＲ－ＴＷＴｘの各スケジュールされたＤＬトラフィックストリームの平均量又は最大量、或いは同様の相対的尺度に置き換えることができる。
【0138】
（ｃ）Ｒ－ＴＷＴスケジュール側ＡＰは、以下の２つの条件が満たされた時に、送信すべきスケジュールされたＤＬトラフィックストリームのさらなるフレームを有していないと認識することができる。
【0139】
（ｃ）（ｉ）Ｒ－ＴＷＴスケジュール側ＡＰに到着すると予想されるＲ－ＴＷＴｘの各スケジュールされたＤＬトラフィックストリームの最小量が送信済みである。例えば、Ｒ－ＴＷＴｘのスケジュールされたＤＬ ＳＣＳトラフィックストリームは、そのＴＳＰＥＣ要素内にＲmin（ビット／秒）に設定された最小データレートフィールドを有する。結果としての２つのＲ－ＴＷＴｘ ＳＰの終了時刻間の時間をｔ（秒）とする。すると、時間ｔ中にＲ－ＴＷＴスケジュール側ＡＰに到着すると予想されるスケジュールされたＤＬトラフィックストリームの最小量はRmin
*ｔ（ビット）である。Ｒ－ＴＷＴスケジュール側ＡＰは、第２のＲ－ＴＷＴｘ ＳＰの終了前にこれらＲmin
*ｔ（ビット）のトラフィックを全て送信すべきである。Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘの複数のスケジュールされたＤＬトラフィックストリームを有することができる。
【0140】
（ｃ）（ｉｉ）全てのＲ－ＴＷＴｘのスケジュールされたＤＬトラフィックストリームのバッファが空である。
【0141】
（ｃ）（続き）Ｒ－ＴＷＴｘの各スケジュールされたＤＬトラフィックストリームの最小量は、４．３節で説明したように計算できるＲ－ＴＷＴｘの各スケジュールされたＤＬトラフィックストリームの平均量又は最大量、或いは同様の相対的尺度に置き換えることができる。
【0142】
（ｄ）チェック１７４において、Ｒ－ＴＷＴｘ ＳＰの予定終了時刻前にＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの全てのフレームが送信された場合、Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの残り時間中にＲ－ＴＷＴｘメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡとフレーム１７６を交換することができる。これは、Ｒ－ＴＷＴｘメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡのＲ－ＴＷＴ動作のサポートに報いるためである。詳細については４．４節で説明している。
【0143】
（ｅ）Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームの全てのフレームの送信後であってＲ－ＴＷＴｘ ＳＰの予定終了時刻前に、Ｒ－ＴＷＴｘ ＳＰの終了を示す信号を送信（１７８）することができる。例えば、Ｒ－ＴＷＴ ＳＰの終了を示す信号は、以下のいずれかであることができる。
【0144】
（ｅ）（ｉ）ＥＯＳＰサブフィールドが第１の状態（例えば、「１」）に等しく設定されることにより、フレームのＱｏＳ制御フィールドが図２７に示す通り又はＩＥＥＥ８０２．１１ａｘで定められる通りであることができるＱｏＳデータフレーム又はＱｏＳヌルフレーム（なお、ＥＯＳＰが「１」に設定されたＱｏＳヌルフレームがブロードキャストされる必要がある）。
【0145】
（ｅ）（ｉｉ）さらなるデータ（Ｍｏｒｅ Ｄａｔａ）フィールドが第２の状態（例えば、「０」）に等しく、ＩＥＥＥ８０２．１１ａｘで定められるものと同じであることができる、（Ａｃｋ又はＢＡフレームを含む）ＱｏＳデータフレームでもＱｏＳヌルフレームでもないフレーム。なお、さらなるデータフィールドは、フレーム制御フィールド内、又はＨＴ制御フィールドのＣＡＳ制御のＲＤＧ／さらなるデータフィールド内に存在することができる。この場合、さらなるデータサブフィールドが第１の状態（例えば、「１」）に設定された時には、ＥＯＳＰが第２の状態（例えば、「０」）に設定された場合と同じ効果がある。さらなるデータサブフィールドが第２の状態（例えば「０」）に設定された時には、第１の状態（例えば「１」）に等しいＥＯＳＰと同じ効果がある。
【0146】
（ｅ）（ｉｉｉ）Ｒ－ＴＷＴ ＳＰの終了を示すＣＦ終了（ＣＦ－Ｅｎｄ）フレーム。
【0147】
（ｅ）（ｉｖ）第２の状態（例えば、「０」）に等しいさらなるＴＦ（Ｍｏｒｅ ＴＦ）フィールドを有し、どのＲ－ＴＷＴメンバーＳＴＡにもアドレス指定されていないトリガーフレーム。
【0148】
（ｅ）（ｖ）Ｒ－ＴＷＴ ＳＰの終了を示すＲ－ＴＷＴ ＩＤと等しいＴＷＴフロー識別フィールドを有する、ＩＥＥＥ８０２．１１ａｘで定められるＴＷＴ情報フレーム。
【0149】
（ｅ）（ｖｉ）Ｒ－ＴＷＴ ＳＰ中にさらなるデータフィールド（例えば、フレーム制御フィールド内のさらなるデータサブフィールド又はＨＴ制御フィールドのＣＡＳ制御内のＲＤＧ／さらなるデータフィールドのいずれか）がフレーム内で第１の状態（例えば、「１」）に等しい、ＱｏＳデータフレームでもＱｏＳヌルフレームでもないフレーム（Ａｃｋ又はＢＡフレームを含む）。
【0150】
なお、Ｒ－ＴＷＴ ＳＰ中には、さらなるデータサブフィールドが第１の状態（例えば、「１」）に設定されると、ＥＯＳＰが第１の状態（例えば、「１」）に等しい場合と同じ効果がある。さらなるデータサブフィールドが第２の状態（例えば「０」）に設定された時には、ＥＯＳＰが第２の状態（例えば、「０」）に等しい場合と同じ効果がある。なお、Ｒ－ＴＷＴ ＳＰ外の場合には、さらなるデータフィールドを現在のＩＥＥＥ８０２．１１ａｘの場合と同じように利用することができる。
【0151】
（ｆ）ＳＴＡは、以下の条件下でＲ－ＴＷＴｘ ＳＰの終了を認識することができる。
【0152】
（ｆ）（ｉ）即時応答を要求しない、Ｒ－ＴＷＴ ＳＰの終了を示すフレーム（例えば、ブロードキャストフレーム）をＲ－ＴＷＴスケジュール側ＡＰから受け取った場合。
【0153】
（ｆ）（ｉｉ）Ｒ－ＴＷＴ ＳＰの終了を示すフレームに応答して確認応答を送信する場合。なお、Ｒ－ＴＷＴ ＳＰの終了を示すフレームはＲ－ＴＷＴスケジュール側ＡＰによって送信される。
【0154】
（ｇ）Ｒ－ＴＷＴｘメンバーＳＴＡでない被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴｘ ＳＰの終了を認識した直後にチャネルを求めて競合を開始又は継続することができる。
【0155】
（ｈ）Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰの終了を認識すると、（ｉ）省電力モードにある場合にはスリープ状態に入り、又は（ｉｉ）直ちにチャネル競合を開始又は継続し、又は（ｉｉｉ）Ｒ－ＴＷＴｘ ＳＰの予定終了時刻までチャネルを求めて競合することができない。
【0156】
（ｊ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘメンバーＳＴＡがＲ－ＴＷＴｘ ＳＰの終了後にチャネルを求めて競合し始める時に、例えばＩＥＥＥ８０２．１１ａｘにおけるＭＵ－ＥＤＣＡ要素などのＥＤＣＡパラメータセットを利用して、Ｒ－ＴＷＴｘメンバーＳＴＡのチャネル競合プロセスを一定期間（例えば、ＭＵ－ＥＤＣＡにおける各ＡＣのＭＵ ＥＤＣＡタイマーフィールド）にわたって低速化する（遅延させる）ことができる。
【0157】
（ｋ）Ｒ－ＴＷＴｘ ＳＰの予定終了時刻までにＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの全てのフレームを送信できない場合、Ｒ－ＴＷＴスケジュール側ＡＰ又はＲ－ＴＷＴメンバーＳＴＡは、予定終了時刻にＲ－ＴＷＴｘ ＳＰを終了し（１８０）、或いは取得したＴＸＯＰを延長することによってＲ－ＴＷＴｘ ＳＰを延長することができる。
【0158】
図２４～図２６に、Ｒ－ＴＷＴｘメンバーＳＴＡがＲ－ＴＷＴｘ ＳＰ中にそのＲ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームが送信されたことを示す信号を送信するプロセスを示す。
【0159】
【0160】
チェック１９４において、Ｒ－ＴＷＴｘ ＳＰ中に送信するためのＵＬ及び／又はＰ２ＰトラフィックストリームをＲ－ＴＷＴｘメンバーＳＴＡがそのバッファ内に有しているかどうかを判定する。この条件が満たされた場合、ブロック１９６において、Ｒ－ＴＷＴｘメンバーＳＴＡは、そのバッファ内のＲ－ＴＷＴｘのスケジュールされたＵＬ又はＰ２Ｐトラフィックストリームのフレームを送信し、実行は図２５のブロック２００に進む。
【0161】
ブロック２００において、Ｒ－ＴＷＴｘメンバーＳＴＡがそのＲ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックの全てのフレームをＲ－ＴＷＴｘ ＳＰ中に送信したかどうかを判定するチェックを行う。全てのフレームが送信されていない場合、実行はブロック１９２に戻る。そうでなければ、全てのフレームが送信済みであるため、実行はブロック２０２に進み、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームを送信したことを示す信号をスケジュール側ＡＰに送信する。
【0162】
実行は判定ブロック２０４に到達し、Ｒ－ＴＷＴｘメンバーＳＴＡがＲ－ＴＷＴｘ ＳＰのいずれかの終了信号を受け取ったかどうかを判定する。終了信号が受け取られた場合、ブロック２０６においてＲ－ＴＷＴｘ ＳＰは終了し、Ｒ－ＴＷＴｘメンバーＳＴＡはチャネルを求めて競合することができ、又は他のトラフィックがチャネルを求めて競合することができ、プロセスは終了する。そうでなければ、ブロック２０８において、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰがその予定終了時刻に終了するまでチャネルを求めて競合することができない。
【0163】
次に図２４のブロック１９４に戻り、ブロック１９４の条件が満たされない場合、判定ブロック１９８に到達して２つのオプション間で判定を行う。オプション２では、ブロック１９２に戻ってフレームの到着を待ち続け、一方でオプション１が実行されると、既に説明した図２５のブロック２０２に進む。
【0164】
【0165】
最初に、Ｒ－ＴＷＴｘメンバーＳＴＡは、そのバッファ内にＲ－ＴＷＴｘのスケジュールされたＵＬ又はＰ２Ｐトラフィックストリームが到着するのを待つ（１９２）。ブロック１９４において、Ｒ－ＴＷＴｘメンバーＳＴＡがＲ－ＴＷＴｘ ＳＰ中にそのバッファ内にＲ－ＴＷＴｘのスケジュールされたＵＬ又はＰ２Ｐトラフィックストリームのフレームを有していると判定された場合、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ中にこれらのＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームをＲ－ＴＷＴスケジュール側ＡＰに送信し始める（１９６）。なお、４．３節で説明したように、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームをネゴシエートすることができる。このネゴシエーションは、以下のいずれかの方法で実行することができる。
【0166】
（ａ）いくつかの事例では、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴｘメンバーＳＴＡがＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレーム交換を開始する前に、Ｒ－ＴＷＴスケジュール側ＡＰ又はＲ－ＴＷＴｘメンバーＳＴＡのいずれかがフレーム交換のためのＴＸＯＰを取得するためにチャネルを求めて競合する必要がある。Ｒ－ＴＷＴスケジュール側ＡＰ又はＲ－ＴＷＴメンバーＳＴＡがチャネルアクセス権を取得すると、ＲＴＳ／ＭＵ－ＲＴＳ及びＣＴＳの交換を使用してＴＸＯＰを予約することができる。少なくとも１つの実施形態／モード／事例では、ＴＸＯＰ期間が、スケジュールされたＲ－ＴＷＴｘ ＳＰ時間以下でなければならない。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘ ＳＰの終了時刻を超えて延長するようにＴＸＯＰを予約することはできない。ＴＸＯＰ中には、全てのスケジュールされたトラフィックストリームをＴＸＯＰのプライマリＡＣからのトラフィックとして送信することができる。
【0167】
（ｂ）少なくとも１つの実施形態／モード／事例では、被Ｒ－ＴＷＴスケジュール側ＳＴＡが、Ｒ－ＴＷＴ ＳＰと重複するＴＸＯＰを取得する予定である場合に、（ＭＵ）ＲＴＳ／ＣＴＳ交換を使用してそのＴＸＯＰを取得せざるを得ない。Ｒ－ＴＷＴスケジュール側ＡＰは、被Ｒ－ＴＷＴスケジュール側ＳＴＡによるＴＸＯＰの取得を許可しないこのようなＲＴＳを被Ｒ－ＴＷＴスケジュール側ＳＴＡから受け取った場合、ＣＴＳに応答しないことができる。Ｒ－ＴＷＴスケジュール側ＡＰは、被Ｒ－ＴＷＴスケジュール側ＳＴＡからのこのようなＲＴＳに応答して、ＣＴＳフレーム内に任意のＮＡＶを設定することもできる。その後、被Ｒ－ＴＷＴスケジュール側ＳＴＡは、ＣＴＳフレーム内のＮＡＶに等しいＴＸＯＰのみを取得する。
【0168】
（ｃ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴｘメンバーＳＴＡが、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの送信のためのＴＸＯＰを取得するためにＥＤＣＡを使用する。ＥＤＣＡ ＴＸＯＰが取得されると、いくつかの事例では、プライマリＡＣ及び非プライマリＡＣからのものを含むＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの全てのフレームをこのＥＤＣＡ ＴＸＯＰ中に送信することができる。なお、プライマリＡＣは、ＥＤＣＡＦがＴＸＯＰを取得するＡＣに相当する。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームをバッファ内に有するＡＣのＥＤＣＡＦのみがチャネルを求めて競合することができる。
【0169】
（ｄ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのブロードキャストＴＷＴパラメータ情報フィールドの要求タイプフィールドのトリガーフィールドがＲ－ＴＷＴスケジュール側ＡＰによって第１の状態（例えば、「１」）に設定されている場合、Ｒ－ＴＷＴｘメンバーＳＴＡはＲ－ＴＷＴｘ ＳＰ中にチャネルを求めて競合することができない。このフィールドが第１の状態（例えば、「０」）に設定されている場合には、Ｒ－ＴＷＴｘメンバーＳＴＡもＲ－ＴＷＴｘ ＳＰ中にチャネルを求めて競合することができる。
【0170】
（ｅ）Ｒ－ＴＷＴｘのスケジュールされたトラフィックストリームと同じＴＩＤを有していて再送する必要があるが、いずれのＲ－ＴＷＴｘのスケジュールされたトラフィックストリームにも属していないフレームが存在する場合、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ中にこれらのフレームを送信することができる。そのＴＩＤにブロック確認応答が使用される場合、Ｒ－ＴＷＴｘメンバーＳＴＡは、同じＴＩＤを有するＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームよりも早くＲ－ＴＷＴｘ ＳＰ中にこれらのフレームを送信すべきである。この理由は、これらのフレームのシーケンス番号が割り当てられており、これらのフレームの方がＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームよりも小さいからである。
【0171】
Ｒ－ＴＷＴｘメンバーＳＴＡは、ブロック１９４において、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームのフレームをそのバッファ内に有していないと判定された場合、フレームの到着を待ち続ける（１９２）か、それともＲ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームを送信したことを示す信号をＲ－ＴＷＴスケジュール側ＡＰに送信する（２０２）か、のオプションを決定することができる（１９８）。すなわち、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ中にスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームのフレームのさらなる到着及び送信はないと予想する。
【0172】
Ｒ－ＴＷＴｘメンバーＳＴＡは、ブロック２００において、そのバッファ内のＲ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームの全てのフレームを送信したが、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたＵＬ又はＰ２Ｐトラフィックストリームのフレームがさらに到着すると予想していると判定された場合、これらのフレームの到着を待ち続けるべきである（１９２）。
【0173】
Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴ ＳＰ中にＲ－ＴＷＴｘ ＵＬ及び／又はＰ２Ｐトラフィックストリームの全てのフレームを送信した場合にはこのような指示を含む信号を送信し（２０２）、以下ではこのプロセスについてさらに概説する。
【0174】
（ａ）なお、Ｒ－ＴＷＴｘメンバーＳＴＡは、以下の２つの条件が満たされた場合に、送信すべきＲ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームのフレームをそれ以上有していないと認識することができる。
【0175】
（ａ）（ｉ）Ｒ－ＴＷＴメンバーＳＴＡに到着すると予想される各スケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの最小量が送信済みである。例えば、Ｒ－ＴＷＴｘのスケジュールされたＵＬ ＳＣＳトラフィックストリームは、Ｒmin（ビット／秒）に設定された最小データレートフィールドをＴＳＰＥＣ要素内に有する。２つの連続するＲ－ＴＷＴｘ ＳＰの終了時刻間の時間をｔ（秒）とする。すると、時間ｔ中にＲ－ＴＷＴｘメンバーＳＴＡに到着すると予想されるＵＬ ＳＣＳトラフィックストリームの最小量はＲmin
*ｔ（ビット）である。Ｒ－ＴＷＴｘメンバーＳＴＡは、第２のＲ－ＴＷＴｘ ＳＰの終了前にこれらのＲmin
*ｔ（ビット）のトラフィックを全て送信すべきである。Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘの複数のスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームを有することができる。
【0176】
（ａ）（ｉｉ）これらのＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのバッファがＲ－ＴＷＴｘメンバーＳＴＡにおいて空である。
【0177】
（ａ）（続き）Ｒ－ＴＷＴｘの各スケジュールされたＤＬトラフィックストリームの最小量は、４．３節で説明したように決定（例えば、計算）できるＲ－ＴＷＴｘの各スケジュールされたＤＬトラフィックストリームの平均量又は最大量、或いは同様の相対的尺度に置き換えることができる。
【0178】
（ｂ）少なくとも１つの実施形態では、Ｒ－ＴＷＴメンバーＳＴＡがそのＲ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームをＲ－ＴＷＴｘ ＳＰ中に送信したことを示す信号が以下から選択される。
【0179】
（ｂ）（ｉ）この信号は、さらなるデータ（Ｍｏｒｅ Ｄａｔａ）フィールドが第２の状態（例えば、「０」）に等しく、ＩＥＥＥ８０２．１１ａｘで定められるものと同じであることができる、（Ａｃｋ又はＢＡフレームを含む）ＱｏＳデータフレームでもＱｏＳヌルフレームでもないフレームであることができる。さらなるデータフィールドは、フレーム制御フィールド内、又はフレームのＨＴ制御フィールドのＣＡＳ制御のＲＤＧ／さらなるデータフィールド内に存在することができる。さらなるデータサブフィールドが第１の状態（例えば、「１」）に設定された時には、ＥＯＳＰが第２の状態（例えば、「０」）に設定された場合と同じ効果がある。さらなるデータサブフィールドが第２の状態（例えば「０」）に設定された時には、ＥＯＳＰが第１の状態（例えば「１」）に設定された場合と同じ効果がある。
【0180】
（ｂ）（ｉｉ）この信号は、図１７に示すことができるフレームのＱｏＳ制御フィールド内のＥＯＳＰサブフィールドが「１」に等しいＱｏＳデータフレーム又はＱｏＳヌルフレームであることができる。
【0181】
（ｂ）（ｉｉｉ）この信号は、Ｒ－ＴＷＴ ＳＰ中にさらなるデータフィールド（例えば、フレーム制御フィールド内のさらなるデータサブフィールド又はＨＴ制御フィールドのＣＡＳ制御内のＲＤＧ／さらなるデータフィールドのいずれか）がフレーム内で第１の状態（例えば、「１」）に等しい、ＱｏＳデータフレームでもＱｏＳヌルフレームでもない（Ａｃｋ又はＢＡフレームを含む）フレームであることができる。なお、Ｒ－ＴＷＴ ＳＰ中には、ＲＤＧ／さらなるデータサブフィールドが第１の状態（例えば、「１」）に設定されると、ＥＯＳＰが第１の状態（例えば、「１」）に設定された場合と同じ効果がある。ＲＤＧ／さらなるデータサブフィールドが第２の状態（例えば「０」）に設定された時には、ＥＯＳＰが第２の状態（例えば、「０」）に設定された場合と同じ効果がある。なお、Ｒ－ＴＷＴ ＳＰ外の場合には、さらなるデータフィールドが現在のＩＥＥＥ８０２．１１ａｘの場合と同じように使用されることが好ましい。
【0182】
（ｃ）この信号がデータフレームによって伝えられる場合、このデータフレームは、Ｒ－ＴＷＴｘメンバーＳＴＡによって送信されるＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの最後のデータフレームであることができる。少なくとも１つの実施形態／モード／事例では、この信号が、Ｒ－ＴＷＴｘメンバーＳＴＡによって送信された最後のＰＰＤＵ内の全てのデータフレームによって伝えられ、例えば最後のＰＰＤＵ内の全てのデータフレームは、ＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定する。そして、この信号は、最後のデータフレームを伝えるＰＰＤＵ全体が正常に受け取られた時、又はＰＰＤＵ内のＲ－ＴＷＴｘのスケジュールされたトラフィックストリームの全てのフレームが正常に受け取られた時に、Ｒ－ＴＷＴスケジュール側ＡＰによって正常に受け取られる。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘ ＳＰ中に、ＰＰＤＵがＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームのみを伝えることができる。
【0183】
（ｄ）信号が正常に送信されない場合、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴスケジュール側ＡＰにこの信号を再送する必要がある。
【0184】
（ｅ）この信号は、Ｒ－ＴＷＴｘメンバーＳＴＡがそのバッファ内にＲ－ＴＷＴｘのスケジュールされたＵＬ又はＰ２Ｐトラフィックストリームのフレームを有しておらず、Ｒ－ＴＷＴｘメンバーＳＴＡによってＲ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームが送信される予定であるにもかかわらず、Ｒ－ＴＷＴｘスケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰを終了できることを知らせる時に、Ｒ－ＴＷＴｘメンバーＳＴＡが一方的に送信することができる。
【0185】
（ｆ）少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームを有していないＲ－ＴＷＴｘメンバーＳＴＡが、Ｒ－ＴＷＴｘ ＳＰ中にこのような信号を送信することができない。別の実施形態／モード／事例では、Ｒ－ＴＷＴｘのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームを有していないＲ－ＴＷＴｘメンバーＳＴＡもこのような信号を送信する必要がある。
【0186】
（ｇ）Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘのスケジュールされたＤＬトラフィックストリームを有しておらず、省電力モードで動作している場合、Ｒ－ＴＷＴスケジュール側ＡＰに正常に信号を送信した直後にスリープモードに入る（スリープする）ことができる。
【0187】
従って、図２４～図２６で説明したように、Ｒ－ＴＷＴスケジュール側ＡＰは、全てのスケジュールされたトラフィックストリームが送信された後に、Ｒ－ＴＷＴｘ ＳＰの終了を示す信号を送信することができる。Ｒ－ＴＷＴｘメンバーＳＴＡは、ブロック２０４においてＲ－ＴＷＴｘ ＳＰの終了を認識していると判定されると、直ちにチャネルを求めて競合２０６を開始することができる。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴｘメンバーＳＴＡが、チャネル競合の優先度を低下させるために、一定期間にわたって異なるＥＤＣＡパラメータ設定を利用することができる。例えば、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰの終了後にチャネル競合のためにＭＵ－ＥＤＣＡパラメータを使用する。Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰの終了時に、チャネルを求めて競合する代わりに節電のためにスリープモードに入ることもできる。そうでなければ、Ｒ－ＴＷＴｘメンバーＳＴＡは、Ｒ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームを送信した（２０８）ことを示す信号を送信した後に、Ｒ－ＴＷＴｘ ＳＰの予定終了時刻にＲ－ＴＷＴｘ ＳＰが終了するまでチャネルを求めて競合することができない。
【0188】
４．６．Ｒ－ＴＷＴのＱｏＳデータ及びヌルフレーム内のＱｏＳ制御フィールド。
図２７に、Ｒ－ＴＷＴのためのＱｏＳデータ及びＱｏＳヌルフレーム内のＱｏＳ制御フィールドの実施形態例２１０を示す。なお、少なくとも１つの実施形態では、ＱｏＳデータフレームが、ＱｏＳデータ＋ＣＦ Ａｃｋフレームも含む。ＱｏＳデータ及びＱｏＳヌルフレームは、予約されたフレームタイプ（例えば、ＩＥＥＥ８０２．１１のフレーム制御フィールド内のタイプとサブタイプとの組み合わせ）を使用することによって、又はＲ－ＴＷＴ ＳＰ中にフレームを送信することによって、又はＲ－ＴＷＴスケジュール側ＡＰ又は被Ｒ－ＴＷＴスケジュール側ＳＴＡによって送信されることによって、このフレームタイプがＲ－ＴＷＴのためのものであることを示すことができる。ＱｏＳデータ及びＱｏＳヌルフレームがＲ－ＴＷＴのためのものである場合には、図２７に示すＱｏＳ制御フィールドがフレーム内で使用される。
図２７に、Ｒ－ＴＷＴのためのＱｏＳデータ及びＱｏＳヌルフレーム内のＱｏＳ制御フィールドの実施形態例２１０を示す。なお、少なくとも１つの実施形態では、ＱｏＳデータフレームが、ＱｏＳデータ＋ＣＦ Ａｃｋフレームも含む。ＱｏＳデータ及びＱｏＳヌルフレームは、予約されたフレームタイプ（例えば、ＩＥＥＥ８０２．１１のフレーム制御フィールド内のタイプとサブタイプとの組み合わせ）を使用することによって、又はＲ－ＴＷＴ ＳＰ中にフレームを送信することによって、又はＲ－ＴＷＴスケジュール側ＡＰ又は被Ｒ－ＴＷＴスケジュール側ＳＴＡによって送信されることによって、このフレームタイプがＲ－ＴＷＴのためのものであることを示すことができる。ＱｏＳデータ及びＱｏＳヌルフレームがＲ－ＴＷＴのためのものである場合には、図２７に示すＱｏＳ制御フィールドがフレーム内で使用される。
【0189】
ＴＩＤフィールドは、このＱｏＳ制御フィールドを伝えるフレームのデータのＴＩＤを表すように設定される。ＴＩＤは、「０」～「７」、又は「８」～「１５」、又は「０」～「１５」の数に設定することができる。このフィールドは、ＱｏＳヌルフレームで送信される時にも予約することができる。
【0190】
ＥＯＳＰフィールドは、被Ｒ－ＴＷＴスケジュール側ＳＴＡによって、Ｒ－ＴＷＴ ＳＰ中に被Ｒ－ＴＷＴスケジュール側ＳＴＡがＲ－ＴＷＴのスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームの全てのフレームを送信したかどうかを示すように設定される。このフィールドが第１の状態（例えば、「１」）に設定された場合、被Ｒ－ＴＷＴスケジュール側ＳＴＡは、そのＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームを送信し終えている。そうでなければ、このフィールドは第２の状態（例えば、「０」）に設定され、被Ｒ－ＴＷＴスケジュール側ＳＴＡは、そのＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴのスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームのさらなるフレームを有している。このフィールドがＱｏＳデータフレームで送信される場合、この情報は、スケジュールされたトラフィックストリームの全てのデータフレームがＱｏＳデータフレームの同じＰＰＤＵ（又は全ＰＰＤＵ）で正常に受け取られたことを示すフィードバックをＲ－ＴＷＴスケジュール側ＡＰが送信する際に、Ｒ－ＴＷＴスケジュール側ＡＰによって確認応答される。この情報がＲ－ＴＷＴスケジュール側ＡＰによって確認応答されなかった場合、被Ｒ－ＴＷＴスケジュール側ＳＴＡはこの情報を再送することができる。Ｒ－ＴＷＴスケジュール側ＡＰは、このフィールドを現在のＲ－ＴＷＴ ＳＰの終了を示すように設定する。このフィールドが第１の状態（例えば、「１」）に設定された場合、現在のＲ－ＴＷＴ ＳＰは終了する。そうでなければ、このフィールドは第２の状態（例えば、「０」）に設定され、現在のＲ－ＴＷＴ ＳＰは終了しない。ＳＴＡは、このフィールドを受け取ることによってＲ－ＴＷＴ ＳＰの終了を認識することができる。
【0191】
Ａｃｋポリシーインジケータ（Ａｃｋ Ｐｏｌｉｃｙ Ｉｎｄｉｃａｔｏｒ）フィールドは、ＩＥＥＥ８０２．１１で定められるＱｏＳ制御フィールド内のものと同一であることができる。Ａ－ＭＳＤＵ存在（Ａ－ＭＳＤＵ Ｐｒｅｓｅｎｔ）フィールドは、ＩＥＥＥ８０２．１１で定められるＱｏＳ制御フィールド内のものと同一であることができる。
【0192】
ＨＴ制御存在（ＨＴ Ｃｏｎｔｒｏｌ Ｐｒｅｓｅｎｔ）フィールドは、フレームのＭＡＣヘッダ内にＨＴ制御フィールドが存在するかどうかを示すように設定される。このフィールドが第１の状態（例えば、「１」）に設定された場合には、ＨＴ制御フィールドが存在する。ＨＴ制御フィールドは、ＢＳＲなどのさらなる情報を伝えることができる。このフィールドが第２の状態（例えば、「０」）に設定された場合には、ＭＡＣヘッダ内にＨＴ制御フィールドが存在しない。
【0193】
４．７．Ｒ－ＴＷＴを終了する例
本節では、Ｒ－ＴＷＴ ＳＰの終了の複数の例を示す。４．３節で説明したように、Ｒ－ＴＷＴはＲ－ＴＷＴスケジュール側ＡＰによってスケジュールされる。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴのメンバーシップを要求し、そのＲ－ＴＷＴのスケジュールされたＳＣＳトラフィックストリームをネゴシエートする。
本節では、Ｒ－ＴＷＴ ＳＰの終了の複数の例を示す。４．３節で説明したように、Ｒ－ＴＷＴはＲ－ＴＷＴスケジュール側ＡＰによってスケジュールされる。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴのメンバーシップを要求し、そのＲ－ＴＷＴのスケジュールされたＳＣＳトラフィックストリームをネゴシエートする。
【0194】
本節の例では、Ｒ－ＴＷＴスケジュール側ＡＰ及び被Ｒ－ＴＷＴスケジュール側ＳＴＡが、ＱｏＳデータ又はＱｏＳヌルフレームに図２７に示すようなＱｏＳ制御フィールドを埋め込むことができる。
【0195】
表１に、異なるＲ－ＴＷＴ ＳＰ中に送信されるようにスケジュールされた５つのＳＣＳトラフィックストリームをリストする。
【0196】
ＳＣＳ１は、ＭＬＤ２とＭＬＤ１との間に確立される。ＳＣＳ１トラフィックストリームの方向はアップリンク（ＭＬＤ２からＭＬＤ１へのトラフィックフロー）である。このトラフィックストリームは、リンク１上のＲ－ＴＷＴ１のスケジュールされたトラフィックストリームである。
【0197】
ＳＣＳ２は、ＳＴＡ２とＭＬＤ１との間に確立される。このＳＣＳ２トラフィックストリームの方向はダウンリンク（すなわち、ＭＬＤ１からＳＴＡ２へのトラフィックフロー）である。このトラフィックストリームは、リンク１上のＲ－ＴＷＴ１のスケジュールされたトラフィックストリームである。
【0198】
ＳＣＳ３は、ＳＴＡ２とＳＴＡ１との間に確立される。ＳＣＳ３トラフィックストリームの方向はＰ２Ｐ（ＳＴＡ２からＳＴＡ１へのトラフィックフロー）である。このトラフィックストリームは、リンク１上のＲ－ＴＷＴ２のスケジュールされたトラフィックストリームである。
【0199】
ＳＣＳ４は、ＭＬＤ３とＭＬＤ１との間に確立される。ＳＣＳ３トラフィックストリームの方向はアップリンク（ＭＬＤ３からＭＬＤ１へのトラフィックフロー）である。このトラフィックストリームは、リンク１及びリンク２上のＲ－ＴＷＴ４のスケジュールされたトラフィックストリームである。
【0200】
ＳＣＳ５は、ＭＬＤ３とＭＬＤ１との間に確立される。このＳＣＳ３トラフィックストリームの方向はダウンリンク（ＭＬＤ１からＭＬＤ３へのトラフィックフロー）である。このトラフィックストリームは、リンク１及びリンク２上のＲ－ＴＷＴ５のスケジュールされたトラフィックストリームである。
【0201】
ＳＣＳ６は、ＳＴＡ２とＭＬＤ１との間に確立される。ＳＣＳ６トラフィックストリームの方向はアップリンク（ＳＴＡ２からＭＬＤ１へのトラフィックフロー）である。このトラフィックストリームは、リンク１上のＲ－ＴＷＴ２のスケジュールされたトラフィックストリームである。
【0202】
本節の例は、表１に示すようなＲ－ＴＷＴスケジューリングに従う。この例では、図２０に示すネットワークトポロジーを使用する。
【0203】
図２８に、Ｒ－ＴＷＴ ＳＰの終了を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＲ－ＴＷＴスケジュール側ＡＰがブロードキャストする実施形態例２３０を示す。図示のＳＴＡは、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0204】
Ｒ－ＴＷＴ１ ＳＰ２４０中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）、ＳＴＡ２及びＳＴＡ１（Ｒ－ＴＷＴ１メンバーＳＴＡ）が、表１に示すようなＳＣＳ１及びＳＣＳ２トラフィックストリームのフレームを交換する。
【0205】
図示のように、ＳＣＳ１のアップリンク（ＵＬ）送信を行うために、ＡＰ１がＳＴＡ１にＢＳＲＰ２４２を送信してＳＴＡ１のバッファステータスを要求する。次に、ＳＴＡ１が、ＡＰ１にＳＣＳ１トラフィックストリームのバッファステータス２４４を報告する（例えば、ＳＴＡ１はＳＣＳ１トラフィックストリームのバッファステータスのみをＢＳＲで報告する）。次に、ＡＰ１は、ここではＳＴＡ２へのＳＣＳ２のダウンリンク（ＤＬ）送信２４６として示す送信を最初に開始することができる。ＳＣＳ２のＤＬ ＰＰＤＵは、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのさらなるフレームが存在することを示すように第２の状態（例えば、「０」）に設定されたＥＯＳＰを有することができる。なお、ＡＰ１は、ＳＣＳ２の予想されるフレームが全てそのバッファに到着して送信されたかどうかを判定することができる。ＳＴＡ２は受信を確認応答する（２４８）。
【0206】
次に、ＡＰ１がＳＣＳ１のＵＬ送信をトリガーする。図示のように、ＡＰ１は、ＳＣＳ１のＵＬ送信を２５０及び２５６の２回トリガーするように例示されている。ＳＣＳ１の第１のＵＬ ＰＰＤＵ２５２は、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきさらなるＵＬ ＰＰＤＵが存在することを示す第２の状態（例えば、「０」）に設定されたＥＯＳＰを有する。ＳＣＳ１の第２のＵＬ ＰＰＤＵ２５８は、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたＵＬトラフィックストリームのフレームをＳＴＡ１がそれ以上有していないことを示す第１の状態（例えば、「１」）に設定されたＥＯＳＰを有する。ＡＰ１は、各アップリンク２５４及び２６０を確認応答（例えば、ＢＡ）する。ＳＴＡ１は、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＳＣＳ１のＵＬ ＰＰＤＵに応答して、全てのＵＬ送信が正常に受け取られたことを示すＢＡを受け取る。
【0207】
その後、Ｒ－ＴＷＴ１のスケジュールされたトラフィックストリーム（すなわち、ＳＣＳ１及びＳＣＳ２）の全てのフレームがＲ－ＴＷＴ１ ＳＰの予定終了時刻前に送信されたので、ＡＰ１は、Ｒ－ＴＷＴ１ ＳＰの終了２６４を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム２６２をブロードキャストする。このＱｏＳヌルフレームを受け取った他のＳＴＡは、直ちにチャネルを求めて競合を開始することができる。
【0208】
なお、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定することができる。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0209】
少なくとも１つの実施形態／モード／事例では、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵがＱｏＳデータもＱｏＳヌルフレームも伝えない。この場合、これらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを利用してＥＯＳＰサブフィールドを置き換えることができる。
【0210】
少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴスケジュール側ＡＰによる送信のためにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームが、Ｒ－ＴＷＴ１ ＳＰの終了を示すためにＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えられる。
【0211】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、これらの両方を使用すべきではない。
【0212】
図２９に、Ｒ－ＴＷＴ ＳＰの終了を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＲ－ＴＷＴスケジュール側ＡＰがブロードキャストする実施形態例２７０を示す。前の例は、Ｒ－ＴＷＴ１のブロードキャストＴＷＴパラメータ情報フィールドの要求タイプフィールド内のトリガーフィールドがＲ－ＴＷＴスケジュール側ＡＰによって第１の状態（例えば、「１」）に設定された時に発生できるのに対し、この例は、Ｒ－ＴＷＴ１のブロードキャストＴＷＴパラメータ情報フィールドの要求タイプフィールド内のトリガーフィールドがＲ－ＴＷＴスケジュール側ＡＰによって第２の状態（例えば、「０」）に設定された時に発生することができる。図示のＳＴＡは、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0213】
Ｒ－ＴＷＴ１ ＳＰ２４０中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）、ＳＴＡ２及びＳＴＡ１（Ｒ－ＴＷＴ１メンバーＳＴＡ）が、表１に示すようなＳＣＳ１及びＳＣＳ２トラフィックストリームのフレームを交換する。
【0214】
図示のように、ＳＣＳ１のアップリンク（ＵＬ）送信を行うために、ＳＴＡ１がバックオフ２７２を実行してチャネルを求めて競合する。ＳＴＡ１は、チャネルアクセス権を取得すると、ＳＣＳ１のフレームを伝えるＵＬ ＰＰＤＵ２７４及び２７８の送信を開始し、ＡＰ１はこれらのフレームの受信を確認応答する（２７６、２８０）。ＳＴＡ１は、ＳＣＳ１の最後のフレームを送信する時に、そのフレーム内でＥＯＳＰを第１の状態（例えば、「１」）に設定する。ＡＰ１が、ＳＣＳ１の最後のフレームを伝えるＰＰＤＵが正常に受け取られたことを示すＢＡ２８０を送信すると、これにより、ＳＴＡ１がＲ－ＴＷＴ１ ＳＰ中にＲ－ＴＷＴ１のスケジュールされたＵＬ及び／又はＰ２Ｐトラフィックストリームの全てのフレームを送信したことが示される。
【0215】
また、ＡＰ１は、Ｒ－ＴＷＴ１のスケジュールされたダウンリンク（ＤＬ）トラフィックストリーム２８４、すなわちＳＣＳ２のフレームをＳＴＡ２に送信するためにチャネルを求めて競合する（２８２）。ＳＣＳ２のＤＬ ＰＰＤＵは、たとえこのＰＰＤＵが正常に受け取られた後にＲ－ＴＷＴ１のスケジュールされたトラフィックストリームの全てのフレームが送信される場合でも、Ｒ－ＴＷＴ１ ＳＰが終了しないことを示すようにＥＯＳＰを第２の状態（例えば、「０」）に設定することができる。
【0216】
ＳＣＳ２のＤＬ ＰＰＤＵが正常に受け取られたことを示すＢＡ２８６をＳＴＡ２が送信した後には、Ｒ－ＴＷＴ１ ＳＰの予定終了時刻までにＲ－ＴＷＴ１のスケジュールされたトラフィックストリーム（すなわち、ＳＣＳ１及びＳＣＳ２）の全てのフレームが送信済みである。その後、ＡＰ１は、Ｒ－ＴＷＴ１ ＳＰの終了を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム２８８をブロードキャストし、その後にＲ－ＴＷＴ ＳＰの予定終了時刻２６４が発生する。このＱｏＳヌルフレームを受け取った他のＳＴＡは、直ちにチャネルを求めて競合を開始することができる。
【0217】
なお、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定する。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0218】
少なくとも１つの実施形態／モード／事例では、図のＤＬ ＰＰＤＵ及び／又はＵＬ ＰＰＤＵがＱｏＳデータもＱｏＳヌルフレームも伝えない。この場合、これらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを使用してＥＯＳＰサブフィールドを置き換えることができる。
【0219】
少なくとも１つの実施形態／モード／事例では、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームを、Ｒ－ＴＷＴ１ ＳＰの終了を示すためにＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0220】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、同時にこれらの両方を使用すべきではない。
【0221】
図３０に、Ｒ－ＴＷＴ ＳＰの終了指示が正常に受け取られなかった実施形態例３１０を示す。この例では、ＳＴＡ２及びＳＴＡ１は省電力モードで動作しているものと仮定する。図示のＳＴＡは先の図と同じであり、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0222】
Ｒ－ＴＷＴ１ ＳＰ２４０中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）、ＳＴＡ２及びＳＴＡ１（Ｒ－ＴＷＴ１メンバーＳＴＡ）が、表１に示すようなＳＣＳ１及びＳＣＳ２トラフィックストリームのフレームを交換する。
【0223】
図示のように、Ｒ－ＴＷＴ１ ＳＰ中にＳＴＡ１及びＳＴＡ２がアウェイクしていることを確認するために、ＡＰ１がＳＴＡ２及びＳＴＡ１にトリガーフレーム３１２を送信する。ＳＴＡ２は、自機がアウェイク中であってＲ－ＴＷＴスケジュール側ＡＰからＲ－ＴＷＴ１のスケジュールされたＤＬトラフィックストリームを受け取る準備ができていることを示すＰＳポール（ＰＳ－Ｐｏｌｌ）３１４を送信する。ＳＴＡ１は、アウェイク中であることを示すためにＱｏＳヌルフレーム３１６を送信する。ＱｏＳヌルフレームは、ＳＴＡ１側のＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのバッファを報告するＢＳＲをＨＴ制御フィールドで伝えることができる。ＡＰ１は、ＢＡ３１８でＱｏＳヌルに応答する。
【0224】
ＱｏＳヌルフレームがＨＴ制御フィールドでＢＳＲを伝えていない場合、Ｒ－ＴＷＴスケジュール側ＡＰは、図示のようなＳＴＡ１におけるＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのバッファのためのＢＳＲ３２２をＳＴＡ１に要求するためにＢＳＲＰ３２０を送信することができる。
【0225】
次に、ＡＰ１は、ＳＣＳ１のＵＬ送信３２６をトリガーする（３２４）。ＡＰ１は、図示のようにＳＣＳ１のＵＬ送信を２回トリガーする。図示のように、ＳＣＳ１の第１のＵＬ ＰＰＤＵ３２６は、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＵＬ ＰＰＤＵがそれ以上存在しないことを示す第１の状態（例えば、「１」）に設定されたＥＯＳＰを有する。しかしながら、ＢＡ応答３２８によって再送が必要であることが示され、ＡＰ１は、ＳＣＳ１のＵＬ送信３３２のための別のトリガーフレーム３３０を送信する。このＳＣＳ１の第２のＵＬ ＰＰＤＵ３３２もＥＯＳＰを第１の状態（例えば、「１」）に設定し、その応答ＢＡ３３４フレームはＵＬ送信に成功したことを示す。その後、ＳＴＡ１は、現在のＲ－ＴＷＴ１ ＳＰ中にＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのＵＬ送信を終了する。ＳＴＡ１は省電力モードで動作しており、Ｒ－ＴＷＴ１のスケジュールされたＵＬトラフィックストリームしか有していないため、直ちにスリープすることができる。
【0226】
その後、ＡＰ１は、ＳＴＡ２に対してＳＣＳ２のダウンリンク（ＤＬ）送信３３６を開始することが分かる。ＳＣＳ２のＤＬ ＰＰＤＵは、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィック送信がそれ以上存在しないことを示すように第１の状態（例えば、「１」）に設定されたＥＯＳＰを有することができる。しかしながら、ＳＴＡ２からの応答ＢＡ３３８は再送が必要であることを示しており、従ってＲ－ＴＷＴ１ ＳＰを終了することができない。
【0227】
ＡＰ１は、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＳＣＳ２の別のＤＬ ＰＰＤＵ３４０を再送のために送信する。なお、ＰＰＤＵは、再送を必要とするフレームのみを伝えればよい。ＳＴＡ２は、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＳＣＳ２のＤＬ ＰＰＤＵが正常に受け取られたことを示すＢＡ３４２を返送すると、現在のＲ－ＴＷＴ１ ＳＰが終了したと認識する。その後、ＳＴＡ２は省電力モードで動作しているため、直ちにスリープする（スリープモードに入る）ことができる。
【0228】
ＡＰ１は、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム３４４をブロードキャストすることができる。従って、このフレームを受け取った他のＳＴＡはＲ－ＴＷＴ１ ＳＰ２６４の終了を認識し、直ちにチャネルを求めて競合を開始することができる。
【0229】
なお、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定することができる。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0230】
少なくとも１つの実施形態／モード／事例では、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵがＱｏＳデータもＱｏＳヌルフレームも伝えない。この場合、これらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを使用してＥＯＳＰサブフィールドを置き換えることができる。
【0231】
少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴスケジュール側ＡＰによって送信されたものとしてＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームを、Ｒ－ＴＷＴ１ ＳＰの終了を示すためにＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0232】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、同時にこれらの両方を使用すべきではない。
【0233】
図３１に、トリガーされたＴＸＯＰ共有時間をＲ－ＴＷＴ ＳＰ中に終了するようにＥＯＳＰが第２の状態（例えば、「０」）に設定されたＱｏＳヌルフレームをＳＴＡが送信する実施形態例３７０を示す。図示のＳＴＡは先の図と同じであり、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0234】
Ｒ－ＴＷＴ２ ＳＰ２４０中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）及びＳＴＡ２（Ｒ－ＴＷＴ２メンバーＳＴＡ）が、表１に示すようなＳＣＳ３及びＳＣＳ６トラフィックストリームのフレームを交換する。
【0235】
図示のように、ＳＣＳ３のＰ２Ｐ送信を行うために、ＡＰ１がＳＴＡ２にＢＳＲＰ３７２を送信してＳＴＡ１のバッファステータスを要求する。次に、ＳＴＡ１が、ＡＰ１にＳＣＳ３トラフィックストリームのバッファステータスを報告する（例えば、ＳＴＡ３はＳＣＳ３トラフィックストリームのバッファステータスのみをＢＳＲ３７４で報告する）。次に、ＡＰ１は、ＳＣＳ３のＰ２Ｐ送信を開始することができる。ＡＰ１は、ＳＴＡ２との間でＴＸＯＰ時間を共有するために、ＩＥＥＥ８０２．１１ｂｅで定められるようなＭＵ－ＲＴＳ ＴＸＳフレーム３７６を送信することができる。ＳＴＡ２は、ＭＵ－ＲＴＳ ＴＸＳフレームに応答してＣＴＳフレーム３７８を送信した後に、ＳＣＳ３のＰ２Ｐ ＰＰＤＵ３８０及び３８４をＳＴＡ１に送信し始め、ＢＡ３８２及び３８６を受け取る。ＳＴＡ２は、Ｐ２Ｐ送信を終了した後に、トリガーされたＴＸＯＰ共有の終了を示すようにＥＯＳＰが第２の状態（例えば、「０」）に設定されたＱｏＳヌルフレーム３８８を送信するが、ＳＴＡ２は、現在のＲ－ＴＷＴ２ ＳＰ中に送信すべきＲ－ＴＷＴ２のスケジュールされたトラフィックストリームのさらなるフレームを有している。
【0236】
ＡＰ１は、今回はＳＣＳ６のＵＬバッファ３９２を報告するＢＳＲをＳＴＡ２に要求するためにＢＳＲＰ３９０を送信する。次に、ＡＰ１は、ＳＣＳ６のＵＬ送信のための別のトリガーＴＸＯＰ共有を開始するために別のＭＵ－ＲＴＳ ＴＸＳフレーム３９４を送信する。その後、ＳＴＡ２は、ＣＴＳ３９６を送信した後に、ＳＴＡ２が現在のＲ－ＴＷＴ２ ＳＰ中にそのＲ－ＴＷＴ２のスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレーム送信を終えたことを示す第１の状態（例えば、「１」）に設定されたＥＯＳＰを有するＳＣＳ６のＵＬ ＰＰＤＵ３９８を送信する。このＥＯＳＰは、トリガーされたＴＸＯＰ共有時間の終了も示す第１の状態（例えば、「１」）に設定される。ＡＰ１は、ＢＡ４００で受信を確認応答する。
【0237】
なお、ＡＰ１は、ＢＳＲ内のＰ２ＰバッファとＵＬバッファとを区別できない可能性があるため、ＵＬ ＰＰＤＵ送信にはトリガーフレームの代わりにＭＵ－ＲＴＳ ＴＸＳフレームを使用する。Ｒ－ＴＷＴ２のスケジュールされたＰ２Ｐトラフィックストリームが存在するので、ＡＰ１は、トリガーされたＴＸＯＰ共有を開始するためにＭＵ－ＲＴＳ ＴＸＳフレームを使用する。すなわち、Ｒ－ＴＷＴ ＳＰ中にＰ２Ｐトラフィック及びＵＬトラフィックの両方がスケジュールされている場合、Ｒ－ＴＷＴスケジュール側ＡＰは、Ｐ２Ｐトラフィック及びＵＬトラフィックをトリガーするためにＭＵ－ＲＴＳ ＴＸＳフレームを使用すべきである。
【0238】
次に、Ｒ－ＴＷＴ２のスケジュールされたトラフィックストリーム（すなわち、ＳＣＳ３及びＳＣＳ６）の全てのフレームがＲ－ＴＷＴ２ ＳＰの予定終了時刻前に送信されたので、ＡＰ１は、Ｒ－ＴＷＴ２ ＳＰ２６４の終了を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム４０２をブロードキャストする。このＱｏＳヌルフレームを受け取った他のＳＴＡは、直ちにチャネルを求めて競合を開始することができる。
【0239】
なお、図のＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定することができる。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0240】
少なくとも１つの実施形態／モード／事例では、図のＵＬ ＰＰＤＵがＱｏＳデータ又はＱｏＳヌルフレームを伝えない。この場合、これらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを利用してＥＯＳＰサブフィールドを置き換えることができる。
【0241】
少なくとも１つの実施形態／モード／事例では、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームを、Ｒ－ＴＷＴ１ ＳＰの終了を示すためにＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0242】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、これらの両方を使用すべきではない。
【0243】
ＳＴＡは、トリガーされたＴＸＯＰ共有を終了するための信号をいつでも使用することができ、この信号はＲ－ＴＷＴ ＳＰのみに限定されない。少なくとも１つの実施形態／モード／事例では、ＥＯＳＰを有するＱｏＳヌルフレームがフィードバックのためのＡｃｋ／ＢＡを要求する。
【0244】
なお、１つのＭＵ－ＲＴＳ ＴＸＳフレームによってトリガーされたＴＸＯＰ共有時間中には、ＭＵ－ＲＴＳ ＴＸＳフレームの対象受信者であるＳＴＡが、トリガーされたＴＸＯＰ共有時間間隔中にいずれかの所望の数のＰＰＤＵを送信することができる。
【0245】
図３２に、Ｒ－ＴＷＴ ＳＰ中にトリガーされたＴＸＯＰ共有時間を終了するようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＳＴＡが送信する実施形態例４３０を示す。この例には、ＳＴＡがＲ－ＴＷＴ ＳＰ中にトリガーされたＴＸＯＰ共有時間を終了するために空のバッファを報告するＢＳＲを伝えるフレームを送信する事例も示す。図示のＳＴＡは先の図と同じであり、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0246】
Ｒ－ＴＷＴ２ ＳＰ２４０中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）及びＳＴＡ２（Ｒ－ＴＷＴ２メンバーＳＴＡ）が、表１に示すようなＳＣＳ３及びＳＣＳ６のトラフィックストリームのフレームを交換する。
【0247】
図示のように、ＳＣＳ３及びＳＣＳ６のＰ２Ｐ送信及び／又はＵＬ送信を行うために、ＡＰ１がＳＴＡ２にＢＳＲＰ４３２を送信してＳＴＡ１のバッファステータスを要求する。次に、ＳＴＡ１が、ＡＰ１にバッファステータス（ＢＳＲ）４３４を報告することができる（例えば、ＳＴＡ３はＳＣＳ３及びＳＣＳ６トラフィックストリームのバッファステータスのみをＢＳＲで報告することができる）。次に、ＡＰ１は、ＳＴＡ２との間でＴＸＯＰ時間を共有するために、ＩＥＥＥ８０２．１１ｂｅで定められるようなＭＵ－ＲＴＳ ＴＸＳフレーム４３６を送信することができる。ＳＴＡ２は、ＭＵ－ＲＴＳ ＴＸＳフレームに応答してＣＴＳフレーム４３８を送信した後に、ＳＣＳ６のＵＬ ＰＰＤＵ４４０をＡＰ１に送信し始める。ＵＬ ＰＰＤＵは、バッファが空であることを示すＢＳＲを含む。次に、このＵＬ ＰＰＤＵを使用して、トリガーされたＴＸＯＰ共有は終了したが、Ｒ－ＴＷＴ２ ＳＰ中に送信すべきＲ－ＴＷＴ２のスケジュールされたトラフィックストリームのフレームをＳＴＡ２がさらに有していることを示すことができる。ＡＰ１は、ＳＣＳ６のＵＬ ＰＰＤＵを正常に受け取った後にＢＡフレーム４４２で応答して、トリガーされたＴＸＯＰ共有を終了する。
【0248】
その後、ＡＰ１は、ＳＴＡ２にＢＳＲを要求するためにＢＳＲＰ４４４を送信し、ＳＴＡ２は、今回はバッファ内にＲ－ＴＷＴ２のスケジュールされたトラフィックストリームのフレームがさらに存在することを報告するＢＳＲフレームと共にそのバッファ状態４４６を報告する。次に、ＡＰ１は、別のＭＵ－ＲＴＳ ＴＸＳフレーム４４８を送信して別のトリガーＴＸＯＰ共有を開始し、ＳＴＡ３はこれを使用して、図示のようにＳＣＳ３のＰ２Ｐ送信をＳＴＡ１に送信する。ＳＴＡ２は、ＣＴＳ４５０を送信した後にＰ２Ｐ送信４５２を開始する。ＳＴＡ２は、Ｐ２Ｐ送信が完了してＳＴＡ１からＢＡ４５４を受け取った後に、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム４５６をＡＰ１に送信する。このＱｏＳヌルフレームは、ＳＴＡ２が現在のＲ－ＴＷＴ２ ＳＰ中にＲ－ＴＷＴ２のスケジュールされたＵＬ及びＰ２Ｐトラフィックストリームの全てのフレームの送信を完了したことを示す。なお、ＡＰ１は、ＢＳＲ内のＰ２ＰバッファとＵＬバッファとを区別できない可能性があるため、ＵＬ ＰＰＤＵ送信にはトリガーフレームの代わりにＭＵ－ＲＴＳ ＴＸＳフレームを使用する。Ｒ－ＴＷＴ２のスケジュールされたＰ２Ｐトラフィックストリームが存在するので、ＡＰ１は、トリガーされたＴＸＯＰ共有を開始するためにＭＵ－ＲＴＳ ＴＸＳフレームを使用する。すなわち、Ｒ－ＴＷＴ ＳＰ中にＰ２Ｐトラフィック及びＵＬトラフィックの両方がスケジュールされている場合、Ｒ－ＴＷＴスケジュール側ＡＰは、Ｐ２Ｐトラフィック及びＵＬトラフィックをトリガーするためにＭＵ－ＲＴＳ ＴＸＳフレームを使用すべきである。
【0249】
次に、Ｒ－ＴＷＴ２のスケジュールされたトラフィックストリーム（すなわち、ＳＣＳ３及びＳＣＳ６）の全てのフレームがＲ－ＴＷＴ２ ＳＰの予定終了時刻前に送信されたので、ＡＰ１は、Ｒ－ＴＷＴ２ ＳＰ２６４の終了を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム４５８をブロードキャストする。このＱｏＳヌルフレームを受け取った他のＳＴＡは、直ちにチャネルを求めて競合を開始できると認識することができる。
【0250】
なお、図のＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定することができる。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0251】
少なくとも１つの実施形態／モード／事例では、図のＵＬ ＰＰＤＵがＱｏＳデータもＱｏＳヌルフレームも伝えない。この場合、これらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを利用してＥＯＳＰサブフィールドを置き換えることができる。
【0252】
少なくとも１つの実施形態／モード／事例では、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームを、Ｒ－ＴＷＴ１ ＳＰの終了を示すためにＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0253】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、同時にこれらの両方を使用すべきではない。
【0254】
ＳＴＡは、トリガーされたＴＸＯＰ共有を終了するための信号をいつでも利用することができ、この信号はＲ－ＴＷＴ ＳＰでの使用に限定されない。少なくとも１つの実施形態／モード／事例では、ＥＯＳＰを有するＱｏＳヌルフレームがフィードバックのためのＡｃｋ／ＢＡとして機能する。
【0255】
なお、１つのＭＵ－ＲＴＳ ＴＸＳフレームによってトリガーされたＴＸＯＰ共有時間中には、ＭＵ－ＲＴＳ ＴＸＳフレームの対象受信者であるＳＴＡが、トリガーされたＴＸＯＰ共有時間内に収まるいずれかの所望の数のＰＰＤＵを送信することができる。
【0256】
図３３に、Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡの送信を手配する実施形態例４７０を示す。図示のＳＴＡは先の図と同じであり、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0257】
この例は、ＵＬ送信後に実行される内容を除き、図２８に示す例と同様である。
【0258】
Ｒ－ＴＷＴ１ ＳＰ２４０中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）、ＳＴＡ２及びＳＴＡ１（Ｒ－ＴＷＴ１メンバーＳＴＡ）が、表１に示すようなＳＣＳ１及びＳＣＳ２トラフィックストリームのフレームを交換する。ＳＣＳ１のアップリンク（ＵＬ）送信を行うために、ＡＰ１がＳＴＡ１にＢＳＲＰ４７２を送信してＳＴＡ１のバッファステータスを要求する。次に、ＳＴＡ１が、ＡＰ１にＳＣＳ１トラフィックストリームのバッファステータス４７４を報告する（例えば、ＳＴＡ１はＳＣＳ１トラフィックストリームのバッファステータスのみをＢＳＲで報告する）。次に、ＡＰ１は、ここではＳＴＡ２へのＳＣＳ２のダウンリンク（ＤＬ）送信４７６として示す送信を最初に開始することができる。ＳＣＳ２のＤＬ ＰＰＤＵは、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのフレームがさらに存在することを示すように第２の状態（例えば、「０」）に設定されたＥＯＳＰを有することができる。なお、ＡＰ１は、ＳＣＳ２の予想されるフレームが全てそのバッファに到着して送信されたかどうかを判定することができる。ＳＴＡ２は受信を確認応答する（４７８）。
【0259】
次に、図示のように、ＡＰ１はＳＣＳ１のＵＬ送信を４８０及び４８６の２回トリガーする。ＳＣＳ１の第１のＵＬ ＰＰＤＵ４８２は、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＵＬ ＰＰＤＵがさらに存在することを示す第２の状態（例えば、「０」）に設定されたＥＯＳＰを有する。ＳＣＳ１の第２のＵＬ ＰＰＤＵ４８８は、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたＵＬトラフィックストリームのフレームをＳＴＡ１がそれ以上有していないことを示す第１の状態（例えば、「１」）に設定されたＥＯＳＰを有する。ＡＰ１は、各アップリンク４８４及び４９０を確認応答（例えば、ＢＡ）する。
【0260】
図２８との違いは、Ｒ－ＴＷＴ１のスケジュールされたトラフィックストリーム（すなわち、ＳＣＳ１及びＳＣＳ２）の全てのフレームがＲ－ＴＷＴ１ ＳＰの予定終了時刻前に送信された時に発生する。図２８に示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームを送信するのではなく、図３３では、ＡＰ１がＳＴＡ３からのＵＬ送信４９４をトリガーするためのベーシックトリガーフレーム４９２をＳＴＡ３に送信し、スケジュールされたＲ－ＴＷＴ１ ＳＰの終了時にＢＡ４９６で応答する。トリガー４９２を送信する際には、ＡＰ１がＳＴＡ３のバッファステータスを決定しているものと仮定する。
【0261】
少なくとも１つの実施形態／モード／事例では、ＡＰ１が、ＳＴＡ３からのＵＬ送信をトリガーする前に、ＳＴＡ３のバッファステータスを要求するためにＢＳＲＰを送信する。その後、ＳＴＡ３は、ベーシックトリガーフレームによってトリガーされたＵＬ ＰＰＤＵをＡＰ１に送信することができる。なお、ＳＴＡ３は、Ｒ－ＴＷＴ１ ＳＰのメンバーではない被Ｒ－ＴＷＴスケジュール側ＳＴＡである。少なくとも１つの実施形態／モード／事例では、ＡＰ１が、現在のＲ－ＴＷＴ ＳＰのメンバーではない被Ｒ－ＴＷＴスケジュール側ＳＴＡの送信のみを手配することができる。すなわち、例えばＡＰ１は、ＳＴＡ６のいかなる送信もトリガーすべきではない。
【0262】
なお、Ｒ－ＴＷＴ非メンバーＳＴＡのみに送信されるベーシックトリガーフレームは、現在のＲ－ＴＷＴ ＳＰの終了を示すことができる。ベーシックトリガーフレームは、現在のＲ－ＴＷＴ ＳＰの終了を示すために、そのさらなるＴＦフィールドを第２の状態（例えば、「０」）に等しく設定する必要があり得る。例えば、ＡＰ１は、Ｒ－ＴＷＴ１の非メンバーＳＴＡに複数のベーシックトリガーフレームを送信することができる。最後のベーシックトリガーフレームは、さらなるＴＦフィールドを第２の状態（例えば、「０」）に設定し、他のベーシックトリガーフレームは、さらなるＴＦフィールドを第１の状態（例えば、「１」）に設定すべきである。
【0263】
Ｒ－ＴＷＴスケジュール側ＡＰとＲ－ＴＷＴ非メンバーＳＴＡとの間のフレーム交換は、Ｒ－ＴＷＴ ＳＰの予定終了時刻前に完了又は別様に終了しなければならない。
【0264】
図３４に、Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰ中にスケジュールされたＵＬトラフィックの到着を待つ実施形態例５３０を示す。Ｒ－ＴＷＴ１ ＳＰ中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）、ＳＴＡ２及びＳＴＡ１（Ｒ－ＴＷＴ１メンバーＳＴＡ）は、表１に示すようなＳＣＳ１及びＳＣＳ２トラフィックストリームのフレームを交換する。図示のＳＴＡは先の図と同じであり、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0265】
図示のように、ＳＣＳ１のアップリンク（ＵＬ）送信を行うために、ＡＰ１がＳＴＡ１にＢＳＲＰ５３２を送信してＳＴＡ１のバッファステータスを要求する。次に、ＳＴＡ１が、ＡＰ１にＳＣＳ１トラフィックストリームのバッファステータス５３４を報告することができる（例えば、ＳＴＡ１は、ＳＣＳ１トラフィックストリームのバッファステータスのみをＢＳＲで報告する）。しかしながら、この事例では、ＳＴＡ１が、そのバッファステータスが空であることを報告する（５３４）。この時点で、スケジュールされたトラフィックストリームＳＣＳ１のフレームはＳＴＡ１に到着していない。
【0266】
次に、ＡＰ１は、ＳＴＡ２に対してＳＣＳ２のダウンリンク（ＤＬ）送信５３６及び５４０を開始し、ＢＡ５３８及び５４２を受け取る。ＳＣＳ２のＤＬ ＰＰＤＵは、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのフレームがさらに存在することを示すように第２の状態（例えば、「０」）に設定されたＥＯＳＰを有することができる。なお、ＡＰ１は、ＳＣＳ２の全ての予想されるフレームがそのバッファに到着して送信されたかどうかを判定／認識することができる。
【0267】
次に、ＡＰ１は、ＳＴＡ１のバッファステータスを要求するために別のＢＳＲＰ５４４を送信し、ＳＴＡ１は、自機のバッファが空でないことを示すＢＳＲフレーム５４６で応答する。すなわち、スケジュールされたトラフィックストリームＳＣＳ１のフレームがＳＴＡ１に到着済みである。ＡＰ１は、ＳＣＳ１のＵＬ送信をトリガーする。図示のように、ＡＰ１は、ＳＣＳ１のＵＬ送信を１回（１度）のみトリガーする。図示のように、ＳＣＳ１のＵＬ ＰＰＤＵ５５０は、現在のＲ－ＴＷＴ１ ＳＰ中にＲ－ＴＷＴ１のスケジュールされたＵＬトラフィックストリームのフレーム送信をＳＴＡ１が終了することを示す、第１の状態（例えば、「１」）に設定されたＥＯＳＰを有する。ＡＰ１は、ＢＡ５５２を送信することによってＵＬ ＰＰＤＵ５５０の受信を確認応答する。
【0268】
ＳＣＳ１のＵＬ送信終了後には、Ｒ－ＴＷＴ１ ＳＰ中にスケジュールされたトラフィックストリームの全てのフレームが送信されている。ＡＰ１は、Ｒ－ＴＷＴ１ ＳＰの終了を示すために、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム５５４をブロードキャストする。このＱｏＳヌルフレームを受け取った他のＳＴＡは、直ちにチャネルを求めて競合を開始することができる。
【0269】
なお、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定することができる。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0270】
少なくとも１つの実施形態／モード／事例では、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵがＱｏＳデータもＱｏＳヌルフレームも伝えないことにより、これらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを利用してＥＯＳＰサブフィールドを置き換えることができる。
【0271】
少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴ１ ＳＰの終了を示すために、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0272】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、同時にこれらの両方を使用すべきではない。
【0273】
図３５に、Ｒ－ＴＷＴのスケジュールされたトラフィックストリームのフレームをそれ以上送信する予定でない場合にＲ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰを終了する実施形態例５７０を示す。Ｒ－ＴＷＴ１ ＳＰ中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）、ＳＴＡ２及びＳＴＡ１（Ｒ－ＴＷＴ１メンバーＳＴＡ）は、表１に示すようなＳＣＳ１及びＳＣＳ２トラフィックストリームのフレームを交換する。図示のＳＴＡは先の図と同じであり、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0274】
図示のように、ＳＣＳ１のアップリンク（ＵＬ）送信を行うために、ＡＰ１がＳＴＡ１にＢＳＲＰ５３２を送信してＳＴＡ１のバッファステータスを要求する。次に、ＳＴＡ１が、ＡＰ１にＳＣＳ１トラフィックストリームのバッファステータスを報告することができる（例えば、ＳＴＡ１は、ＳＣＳ１トラフィックストリームのバッファステータスのみをＢＳＲで報告する）。しかしながら、今回は、ＳＴＡ１が、バッファステータスが空であることを報告する（５３４）。スケジュールされたトラフィックストリームＳＣＳ１のフレームは未だＳＴＡ１に到着していない。
【0275】
次に、ＡＰ１は、ＳＴＡ２に対してＳＣＳ２のダウンリンク（ＤＬ）送信を開始することができる。ＳＣＳ２のＤＬ ＰＰＤＵは、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのフレームがさらに存在することを示すようにＥＯＳＰが第２の状態（例えば、「０」）に設定されたＳＣＳ２フレームを有することができる。なお、ＡＰ１は、ＳＣＳ２の全てのフレームがそのバッファに到着して送信されているかどうかを判定／認識する。従って、異なる局への複数のＤＬ送信５３６及び５４０が実行され、確認応答される（５３８及び５７４）。なお、ＤＬ ＰＰＤＵ５４０は、送信すべきＳＣＳ２の最後のＤＬ ＰＰＤＵ５７２である。
【0276】
次に、ＡＰ１は、ＳＴＡ１のバッファステータスを要求するために別のＢＳＲＰ５７６を送信し、ＳＴＡ１は、自機のバッファが依然として空であることを示すＢＳＲフレーム５７８で応答する。
【0277】
送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのフレームがバッファに存在しないので、ＡＰ１は、Ｒ－ＴＷＴ１ ＳＰの終了２６４を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム５８０をブロードキャストする。他のＳＴＡは、このＱｏＳヌルフレームを受け取ると、直ちにチャネルを求めて競合を開始できると認識する。
【0278】
なお、図のＤＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームを伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定すべきである。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0279】
少なくとも１つの実施形態／モード／事例では、図のＤＬ ＰＰＤＵが、ＱｏＳデータ又はＱｏＳヌルフレームを送信せず、従ってこれらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを使用してＥＯＳＰサブフィールドを置き換えることができる。
【0280】
少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴ１ ＳＰの終了を示すために、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0281】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、これらの両方を使用すべきではない。
【0282】
図３６に、Ｒ－ＴＷＴスケジュール側ＡＰが、スケジュールされたトラフィックの到着を待っている時にＲ－ＴＷＴ非メンバーＳＴＡとフレームを交換する実施形態例６３０を示す。Ｒ－ＴＷＴ１ ＳＰ中に、ＡＰ１（Ｒ－ＴＷＴスケジュール側ＡＰ）、ＳＴＡ２及びＳＴＡ１（Ｒ－ＴＷＴ１メンバーＳＴＡ）が、表１に示すようなＳＣＳ１及びＳＣＳ２トラフィックストリームのフレームを交換する。図示のＳＴＡは先の図と同じであり、ＭＬＤ１のＡＰ１ ２３２、ＳＴＡ２ ２３４、ＭＬＤ２のＳＴＡ１ ２３６、及びその他のＳＴＡ２３８である。
【0283】
図示のように、ＳＣＳ１のアップリンク（ＵＬ）送信を行うために、ＡＰ１がＳＴＡ１にＢＳＲＰ５３２を送信してＳＴＡ１のバッファステータスを要求する。次に、ＳＴＡ１が、ＡＰ１にＳＣＳ１トラフィックストリームのバッファステータスを報告することができる（例えば、ＳＴＡ１は、ＳＣＳ１トラフィックストリームのバッファステータスのみをＢＳＲで報告する）。しかしながら、この事例では、ＳＴＡ１が、そのバッファステータス５３４が空であることを報告する。スケジュールされたトラフィックストリームＳＣＳ１のフレームはＳＴＡ１に到着していない。
【0284】
次に、ＡＰ１は、ＳＴＡ２に対してＳＣＳ２のダウンリンク（ＤＬ）送信５３６及び５４０を開始し、確認応答（ＢＡ）５３８及び６３２を受け取っていることが分かる。なお、ＤＬ ＰＰＤＵ５４０は、送信すべきＳＣＳ２の最後のＤＬ ＰＰＤＵである（５７２）。ＳＣＳ２のＤＬ ＰＰＤＵは、現在のＲ－ＴＷＴ１ ＳＰ中に送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのフレームがさらに存在することを示すように第２の状態（例えば、「０」）に設定されたＥＯＳＰを有することができる。なお、ＡＰ１は、ＳＣＳ２の全ての予想されるフレームがそのバッファに到着して送信されているかどうかを判定／認識する。
【0285】
次に、ＡＰ１は、ＳＴＡ１のバッファステータスを要求するために別のＢＳＲＰ６３４を送信し、ＳＴＡ１は、そのバッファが依然として空であることを示すＢＳＲフレーム６３６で応答する。
【0286】
送信すべきＲ－ＴＷＴ１のスケジュールされたトラフィックストリームのフレームがそれ以上バッファに存在しないので、ＡＰ１は、被Ｒ－ＴＷＴスケジュール側ＳＴＡであってＲ－ＴＷＴメンバーＳＴＡではないＳＴＡ３にＤＬ ＰＰＤＵ６３８を送信する。ＡＰ１は、ＳＴＡ３へのＤＬ送信を終了してＢＡ６４０を受け取った後に、バッファ報告のためにＳＴＡ１に別のＢＳＲＰ６４２を送信する。今回、ＳＴＡ１はＳＣＳ１のバッファを報告（ＢＳＲ）し（６４４）、ＡＰ１は、ＳＣＳ１のＵＬ送信６４８をトリガーするために直ちにベーシックトリガー６４６を送信する。ＳＣＳ１のＵＬ ＰＰＤＵは１つしか存在せず、ＳＴＡ１は、ＵＬ ＰＰＤＵの最後のＭＰＤＵ内のＥＯＳＰフィールドを第１の状態（例えば、「１」）に設定する。ＡＰ１が、ＳＣＳ１のＵＬ ＰＰＤＵが正常に送信されたことを示すＢＡ６５０を送信すると、Ｒ－ＴＷＴ１ ＳＰは終了するが、このＢＡは、Ｔ－ＴＷＴ１ ＳＰの予定終了時刻２６４後に送信される。
【0287】
また、この例には、Ｒ－ＴＷＴ ＳＰの予定終了時刻までにそのＲ－ＴＷＴのスケジュールされたトラフィックストリームの全てのフレームを送信できない場合にＲ－ＴＷＴ ＳＰを延長できる可能性も示す。例えば、図示のようにＲ－ＴＷＴ１ ＳＰが予定終了時刻よりも遅れて終了している。ＴＸＯＰ所有者は、Ｒ－ＴＷＴ ＳＰを延長して現在のＴＸＯＰを延ばすことができる。例えば、図示のように、ＡＰ１が送信した最後のトリガーフレームによってＴＸＯＰを延長することができる。
【0288】
なお、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定することができる。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0289】
少なくとも１つの実施形態／モード／事例では、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵがＱｏＳデータもＱｏＳヌルフレームも伝えないことにより、これらのフレーム内に設定すべき関連するＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを利用してＥＯＳＰサブフィールドを置き換えることができる。
【0290】
少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴ１ ＳＰの終了を示すために、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームをＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0291】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、同時にこれらの両方を使用すべきではない。
【0292】
図３７に、各リンク上のマルチリンクＲ－ＴＷＴ ＳＰの終了の実施形態例６７０を別々に示す。この例では、Ｒ－ＴＷＴスケジュール側ＡＰが、１つのリンク上で信号を送信してそのリンク上のマルチリンクＲ－ＴＷＴ ＳＰを終了させる。ＳＴＡ例は、ＭＬＤ３ ６７２のＳＴＡ３ ６７６及びＳＴＡ５ ６７８、並びにＭＬＤ１ ６７４のＡＰ１ ６８０及びＡＰ２ ６８２として示す。
【0293】
図示のように、Ｒ－ＴＷＴスケジュール側ＡＰ ＭＬＤ１からＲ－ＴＷＴ４ ６８４が告知され、リンク１及びリンク２の両方でＲ－ＴＷＴ４ ＳＰがスケジュールされる。４．３節で説明したように、複数のリンク上のＲ－ＴＷＴは、１つのＴＷＴ要素内の同じＲ－ＴＷＴ ＩＤ及び異なるリンクＩＤを有する複数のブロードキャストＴＷＴパラメータセットフィールドによって示すことができる。例えば、ＡＰ ＭＬＤ１は、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク１に設定された１つのブロードキャストＴＷＴパラメータセットフィールドと、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク２に設定された他のブロードキャストＴＷＴパラメータセットフィールドとをビーコンフレームのＴＷＴ要素内に有することによって、リンク１及びリンク２上のＲ－ＴＷＴ４ ＳＰを告知することができる。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク１に設定された１つのブロードキャストＴＷＴパラメータセットフィールドと、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク２に設定された他のブロードキャストＴＷＴパラメータセットフィールドとをＴＷＴ要素が有するＴＷＴ設定フレームをリンク１上又はリンク２上で送信することによって、リンク１及びリンク２上のＲ－ＴＷＴ４ ＳＰのメンバーシップを要求することができる。
【0294】
Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク１に設定された１つのブロードキャストＴＷＴパラメータセットフィールドと、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク２に設定された他のブロードキャストＴＷＴパラメータセットフィールドとをＴＷＴ要素が有するＴＷＴ設定フレームをリンク１又はリンク２上で送信することによって、リンク１及びリンク２上のＲ－ＴＷＴ４ ＳＰのメンバーシップ要求に応答することができる。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴのメンバーシップを要求するＴＷＴ設定フレーム、及びメンバーシップ要求に応答するＴＷＴ設定フレームを、異なるリンクを介して送信することができる。
【0295】
また、非ＡＰ ＭＬＤ３は、Ｒ－ＴＷＴ４のメンバーシップを要求する場合、ＳＣＳ５及びＳＣＳ４がＲ－ＴＷＴ４のスケジュールされたトラフィックストリームであることを示すことができる。Ｒ－ＴＷＴ４のＳＰ中には、ＭＬＤ１（Ｒ－ＴＷＴスケジュール側ＡＰ）に所属するＡＰ１及びＡＰ２と、ＭＬＤ３に所属するＳＴＡ３及びＳＴＡ５（Ｒ－ＴＷＴ４メンバーＳＴＡ）とが、表１に示すようなＳＣＳ４及びＳＣＳ５トラフィックストリームのフレームを交換する。
【0296】
図示のように、ＳＣＳ４のアップリンク（ＵＬ）送信を行うために、ＡＰ１及びＡＰ２は、それぞれＳＴＡ３及びＳＴＡ５にＢＳＲＰ６８６及び６８８を送信してバッファステータス情報を要求する。ＳＴＡ３及びＳＴＡ５は、リンク１上及びリンク２上での送信のためにそれぞれＡＰ１及びＡＰ２にトリガーするように要求しているバッファを示すためにバッファを報告することができる。ＳＣＳ４はリンク１及びリンク２を介して送信することができるが、いくつかの事例では、ＳＴＡ３がＳＣＳ４のバッファステータス６９０を報告できる一方で、ＳＴＡ５は、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム６９２で空のバッファを報告することができる。
【0297】
ＡＰ１は、ＳＴＡ３から受け取られたバッファ報告に従って、リンク１上のＳＣＳ４のＵＬ送信６９８として示す送信をトリガー（ベーシックトリガー６９４）することができる。ＡＰ２は、リンク２上のＲ－ＴＷＴ４ ＳＰ中にＳＴＡ５がＵＬ送信を有していないと判定／認識する。なお、ＭＬＤ３は、２つのリンク上でどのようにバッファを報告するかを決定することができる。
【0298】
ＳＴＡ３は、ＳＴＡ３がリンク１上の現在のＲ－ＴＷＴ４ ＳＰ中にＲ－ＴＷＴ４のスケジュールされたＵＬトラフィックストリームの全てのフレームを終了したことを示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＳＣＳ４のＵＬ ＰＰＤＵ６９８を送信する。
【0299】
次に、ＡＰ１は、ＳＴＡ３からＢＡ７０２を受け取った後に、リンク１上でＳＣＳ５のＤＬ送信７０６を開始することができる。ＡＰ１は、ＳＣＳ５の全てのＤＬ送信をリンク１上で送信してＢＡ７１２を受け取った後に、リンク１上のＲ－ＴＷＴ４の終了７１６を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム７１４をブロードキャストする。
【0300】
再びリンク２を参照すると、ＡＰ２は、ベーシックトリガー６９４を受け取った後に、ＳＴＡ５からのバッファレポートに従ってリンク２上でのＳＣＳ５のＵＬ送信をトリガーしないことが分かる。ＳＴＡ５は、リンク２上の現在のＲ－ＴＷＴ４ ＳＰ中に送信すべきＲ－ＴＷＴ４のスケジュールされたトラフィックストリームのフレームがさらに存在することを示すように第２の状態（例えば、「０」）に設定されたＥＯＳＰを有することができるＳＣＳ５のＤＬ ＰＰＤＵ６９６及び７０４を送信し、ＡＰ２からＢＡ７００及び７０８を受け取る６８２。その後、ＡＰ２は、リンク２上でのＲ－ＴＷＴ４ ＳＰの終了を示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム７１０をブロードキャストする。
【0301】
なお、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームを伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定することができる。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0302】
少なくとも１つの実施形態／モード／事例では、図示のようなＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵがＱｏＳデータ又はＱｏＳヌルフレームを伝えず、従ってこれらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを使用してＥＯＳＰサブフィールドを置き換えることができる。
【0303】
少なくとも１つの実施形態／モード／事例では、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームを、Ｒ－ＴＷＴ１ ＳＰの終了を示すためにＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0304】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、同時にこれらの両方を使用すべきではない。
【0305】
図３８に、１つのリンク上のＭＬ Ｒ－ＴＷＴ ＳＰの終了の実施形態例７７０を示す。この例では、Ｒ－ＴＷＴスケジュール側ＡＰが、異なるリンク上でスケジュールされている同じＲ－ＴＷＴのＳＰを終了させる信号を１つのリンク上で送信する。
【0306】
図示のＳＴＡは先の図と同じであり、ＭＬＤ３ ６７２のＳＴＡ３ ６７６及びＳＴＡ５ ６７８、並びにＭＬＤ１ ６７４のＡＰ１ ６８０及びＡＰ２ ６８２である。
【0307】
図示のように、Ｒ－ＴＷＴスケジュール側ＡＰ ＭＬＤ１からＲ－ＴＷＴ４が告知され（６８４）、リンク１及びリンク２の両方でＲ－ＴＷＴ４ ＳＰがスケジュールされる。４．３節で説明したように、複数のリンク上のＲ－ＴＷＴは、１つのＴＷＴ要素内の同じＲ－ＴＷＴ ＩＤ及び異なるリンクＩＤを有する複数のブロードキャストＴＷＴパラメータセットフィールドによって示すことができる。例えば、ＡＰ ＭＬＤ１は、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク１に設定された１つのブロードキャストＴＷＴパラメータセットフィールドと、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク２に設定された他のブロードキャストＴＷＴパラメータセットフィールドとをビーコンフレームのＴＷＴ要素内に有することによって、リンク１及びリンク２上のＲ－ＴＷＴ４ ＳＰを告知することができる。被Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク１に設定された１つのブロードキャストＴＷＴパラメータセットフィールドと、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク２に設定された他のブロードキャストＴＷＴパラメータセットフィールドとをＴＷＴ要素が有するＴＷＴ設定フレームをリンク１上又はリンク２上で送信することによって、リンク１及びリンク２上のＲ－ＴＷＴ４ ＳＰのメンバーシップを要求することができる。Ｒ－ＴＷＴスケジュール側ＳＴＡは、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク１に設定された１つのブロードキャストＴＷＴパラメータセットフィールドと、Ｒ－ＴＷＴ ＩＤがＲ－ＴＷＴ４に設定されてリンクＩＤがリンク２に設定された他のブロードキャストＴＷＴパラメータセットフィールドとをＴＷＴ要素が有するＴＷＴ設定フレームをリンク１又はリンク２上で送信することによって、リンク１及びリンク２上のＲ－ＴＷＴ４ ＳＰのメンバーシップ要求に応答することができる。少なくとも１つの実施形態／モード／事例では、Ｒ－ＴＷＴのメンバーシップを要求するＴＷＴ設定フレーム、及びメンバーシップ要求に応答するＴＷＴ設定フレームを、異なるリンクを介して送信することができる。
【0308】
また、非ＡＰ ＭＬＤ３は、Ｒ－ＴＷＴ４のメンバーシップを要求する場合、ＳＣＳ５及びＳＣＳ４がＲ－ＴＷＴ４のスケジュールされたトラフィックストリームであることを示すことができる。Ｒ－ＴＷＴ４のＳＰ中には、ＭＬＤ１（Ｒ－ＴＷＴスケジュール側ＡＰ）に所属するＡＰ１及びＡＰ２と、ＭＬＤ３に所属するＳＴＡ３及びＳＴＡ５（Ｒ－ＴＷＴ４メンバーＳＴＡ）とが、表１に示すようなＳＣＳ４及びＳＣＳ５トラフィックストリームのフレームを交換する。
【0309】
図示のように、ＳＣＳ４のアップリンク（ＵＬ）送信を行うために、ＡＰ１及びＡＰ２は、それぞれＳＴＡ３及びＳＴＡ５にＢＳＲＰ７７２及び７７４を送信してバッファステータスを要求し、ＳＴＡ３及びＳＴＡ５は、これらのバッファステータス７７６及び７７８を報告することができる。なお、この例では、ＳＴＡ３及びＳＴＡ５が同じバッファステータスを報告する（例えば、ＳＴＡ３及びＳＴＡ５は、ＳＣＳ４トラフィックストリームのバッファステータスのみをＢＳＲで報告する）。
【0310】
次に、ＡＰ１は、リンク１上でのＳＣＳ４のＵＬ送信をトリガーするためにリンク１上でベーシックトリガーフレーム７８０を送信する。ＳＴＡ３は、ＳＴＡ３がリンク１上及びリンク２上の現在のＲ－ＴＷＴ４ ＳＰ中にＲ－ＴＷＴ４のスケジュールされたＵＬトラフィックストリームの全てのフレーム送信を終了したことを示すようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＳＣＳ４のＵＬ ＰＰＤＵ７８４を送信する。次に、ＡＰ１は、ＢＡ７８８を受け取った後にリンク１上でＳＣＳ５のＤＬ送信７９２を開始することができ、そのためにＢＡ７９８を受け取る。
【0311】
前に戻ると、ＡＰ２は、ＳＴＡ５からのバッファレポートに従って、リンク２上でのＳＣＳ５のＵＬ送信を開始しないと決定する。すなわち、リンク１上のＳＣＳ４の１つのＵＬ ＰＰＤＵで十分と考えられる。ＡＰ２は、ＳＴＡ５に対してＳＣＳ５のダウンリンク（ＤＬ）送信７８２、７９０及び７９６を開始し、確認応答（ＢＡ）７８６、７９４及び８０４を受け取る。
【0312】
ＳＣＳ５のＤＬ ＰＰＤＵはリンク１上で送信されているため、ＡＰ２は、ＳＣＳ５の全てのＤＬ ＰＰＤＵをリンク２上で送信する場合にはＲ－ＴＷＴ４ ＳＰを終了することができない。４．４節で説明したように、ＡＰ２は、ＳＴＡ４などの被スケジュール側Ｒ－ＴＷＴ ＳＴＡであるＳＴＡといくつかの送信を開始することができる。
【0313】
ＡＰ１は、リンク１上でのＳＣＳ５の最後のＤＬ ＰＰＤＵに応答して、ＳＣＳ５の全てのＤＬ ＰＰＤＵが正常に受け取られたことを示すＢＡフレーム７９８を受け取った後に、リンク１上及びリンク２上でのＲ－ＴＷＴ４を終了させるようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム８００をブロードキャストすることができる（８０２）。その後、ＡＰ２は、リンク１上及びリンク２上のＲ－ＴＷＴ４を終了させるようにＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレーム８０６をリンク２上でブロードキャストすることもできる。
【0314】
なお、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵは、図２７に示すようなＱｏＳ制御フィールド内のＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームをフレームで伝えることが必要となり得る。１つのＰＰＤＵが複数のＱｏＳデータ又はＱｏＳヌルフレームを伝える場合の少なくとも１つの実施形態／モード／事例では、最後のフレームのみがＥＯＳＰサブフィールドを第１の状態（例えば、「１」）に設定すべきである。図示のＰＰＤＵ内のＥＯＳＰ設定は、これらのＰＰＤＵの最後のＥＯＳＰサブフィールド値を表す。
【0315】
少なくとも１つの実施形態／モード／事例では、図のＤＬ ＰＰＤＵ及びＵＬ ＰＰＤＵがＱｏＳデータもＱｏＳヌルフレームも伝えず、従ってこれらのフレーム内に設定すべきＥＯＳＰサブフィールドは存在しない。代わりに、４．５節で説明したように、フレーム内のさらなるデータサブフィールドを利用してＥＯＳＰサブフィールドを置き換えることができる。
【0316】
少なくとも１つの実施形態／モード／事例では、ＥＯＳＰが第１の状態（例えば、「１」）に設定されたＱｏＳヌルフレームを、Ｒ－ＴＷＴ１ ＳＰの終了を示すためにＣＦ終了フレーム又はＴＷＴ情報フレームに置き換えることができる。
【0317】
Ｒ－ＴＷＴ ＳＰ中、Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴ１メンバーＳＴＡは、ＥＯＳＰサブフィールド又はさらなるデータサブフィールドのいずれかを使用すべきであるが、これらの両方を共に使用すべきではない。
【0318】
５．実施形態の一般的範囲
本明細書では、コンピュータプログラム製品としても実装できる、本技術の実施形態による方法及びシステム、及び／又は手順、アルゴリズム、ステップ、演算、数式又はその他の計算表現のフローチャートを参照して本技術の実施形態を説明することができる。この点、フローチャートの各ブロック又はステップ、及びフローチャートのブロック（及び／又はステップ）の組み合わせ、並びにいずれかの手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、ハードウェア、ファームウェア、及び／又はコンピュータ可読プログラムコードの形で具体化された１又は２以上のコンピュータプログラム命令を含むソフトウェアなどの様々な手段によって実装することができる。理解されるように、このようないずれかのコンピュータプログラム命令は、以下に限定されるわけではないが、汎用コンピュータ又は専用コンピュータ、又は機械を生産するための他のいずれかのプログラマブル処理装置を含む１又は２以上のコンピュータプロセッサによって実行して、コンピュータプロセッサ又は他のプログラマブル処理装置上で実行されるコンピュータプログラム命令が、（単複の）特定される機能を実施するための手段を生み出すようにすることができる。
本明細書では、コンピュータプログラム製品としても実装できる、本技術の実施形態による方法及びシステム、及び／又は手順、アルゴリズム、ステップ、演算、数式又はその他の計算表現のフローチャートを参照して本技術の実施形態を説明することができる。この点、フローチャートの各ブロック又はステップ、及びフローチャートのブロック（及び／又はステップ）の組み合わせ、並びにいずれかの手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、ハードウェア、ファームウェア、及び／又はコンピュータ可読プログラムコードの形で具体化された１又は２以上のコンピュータプログラム命令を含むソフトウェアなどの様々な手段によって実装することができる。理解されるように、このようないずれかのコンピュータプログラム命令は、以下に限定されるわけではないが、汎用コンピュータ又は専用コンピュータ、又は機械を生産するための他のいずれかのプログラマブル処理装置を含む１又は２以上のコンピュータプロセッサによって実行して、コンピュータプロセッサ又は他のプログラマブル処理装置上で実行されるコンピュータプログラム命令が、（単複の）特定される機能を実施するための手段を生み出すようにすることができる。
【0319】
従って、本明細書で説明したフローチャートのブロック、並びに手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、（単複の）特定の機能を実行する手段の組み合わせ、（単複の）特定の機能を実行するステップの組み合わせ、及びコンピュータ可読プログラムコードロジック手段の形で具体化されるような、（単複の）特定の機能を実行するコンピュータプログラム命令をサポートする。また、本明細書で説明したフローチャートの各ブロック、並びにいずれかの手順、アルゴリズム、ステップ、演算、数式、又は計算表現、及びこれらの組み合わせは、（単複の）特定の機能又はステップを実行する専用ハードウェアベースのコンピュータシステム、又は専用ハードウェアとコンピュータ可読プログラムコードとの組み合わせによって実装することもできると理解されるであろう。
【0320】
さらに、コンピュータ可読プログラムコードなどの形で具体化されるこれらのコンピュータプログラム命令を、コンピュータプロセッサ又は他のプログラマブル処理装置に特定の態様で機能するように指示することができる１又は２以上のコンピュータ可読メモリ又はメモリ装置に記憶して、これらのコンピュータ可読メモリ又はメモリ装置に記憶された命令が、（単複の）フローチャートの（単複の）ブロック内に指定される機能を実施する命令手段を含む製造の物品を生産するようにすることもできる。コンピュータプログラム命令をコンピュータプロセッサ又は他のプログラマブル処理装置によって実行し、コンピュータプロセッサ又は他のプログラマブル処理装置上で一連の動作ステップが実行されるようにしてコンピュータで実施される処理を生成し、コンピュータプロセッサ又は他のプログラマブル処理装置上で実行される命令が、（単複の）フローチャートの（単複の）ブロック、（単複の）手順、（単複の）アルゴリズム、（単複の）ステップ、（単複の）演算、（単複の）数式、又は（単複の）計算表現に特定される機能を実施するためのステップを提供するようにすることもできる。
【0321】
さらに、本明細書で使用する「プログラム」又は「プログラム実行文」という用語は、本明細書で説明した１又は２以上の機能を実行するために１又は２以上のコンピュータプロセッサが実行できる１又は２以上の命令を意味すると理解されるであろう。命令は、ソフトウェア、ファームウェア、又はソフトウェアとファームウェアとの組み合わせで具体化することができる。命令は、装置の非一時的媒体に局所的に記憶することも、又はサーバなどに遠隔的に記憶することもでき、或いは命令の全部又は一部を局所的に又は遠隔的に記憶することもできる。遠隔的に記憶された命令は、ユーザが開始することによって、或いは１又は２以上の要因に基づいて自動的に装置にダウンロード（プッシュ）することができる。
【0322】
さらに、本明細書で使用するプロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、中央処理装置（ＣＰＵ）及びコンピュータという用語は、命令、並びに入力／出力インターフェイス及び／又は周辺装置との通信を実行できる装置を示すために同義的に使用されるものであり、プロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、ＣＰＵ及びコンピュータという用語は、単一の又は複数の装置、シングルコア装置及びマルチコア装置、及びこれらの変種を含むように意図するものであると理解されるであろう。
【0323】
本明細書の説明から、本開示は、限定ではないが以下の内容を含む複数の技術実装を含むと理解されるであろう。
【0324】
ネットワークにおける無線通信のための装置であって、（ａ）マルチリンク装置（ＭＬＤ）とは別の、又はマルチリンク装置（ＭＬＤ）に関連する局（ＳＴＡ）であって、制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）のスケジューリングサービス期間（ＳＰ）にわたってＩＥＥＥ８０２プロトコルに従って無線ローカルエリアネットワーク（ＷＬＡＮ）上でキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してパケットでのフレームの送信を実行する他の無線局（ＳＴＡ）とチャネルを介して無線で通信するように構成された局（ＳＴＡ）としての無線通信回路と、（ｂ）前記ＳＴＡに結合されてＷＬＡＮ上で動作するプロセッサと、（ｃ）プロセッサによって実行可能な、通信プロトコル内の他のＳＴＡと通信するための命令を記憶する非一時的メモリとを備え、（ｄ）前記命令は、プロセッサによって実行された時に、Ｒ－ＴＷＴのメンバーＳＴＡとフレームを交換するためのＲ－ＴＷＴスケジューリングを告知する上で、（ｄ）（ｉ）Ｒ－ＴＷＴスケジューリングを実行するように構成されたアクセスポイント（ＡＰ）として動作する前記局が、Ｒ－ＴＷＴスケジュール側ＡＰとして、Ｒ－ＴＷＴ ＳＰに入った後に、Ｒ－ＴＷＴスケジューリングを告知してＲ－ＴＷＴのメンバーＳＴＡとフレームを交換することと、（ｄ）（ｉｉ）終了条件が検出されることと、（ｄ）（ｉｉｉ）前記Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰ中に全てのフレーム交換が完了した後に、Ｒ－ＴＷＴ ＳＰの終了を示す信号を終了告知において送信することと、を含む１又は２以上のステップを実行する、装置。
【0325】
ネットワークにおける無線通信のための装置であって、（ａ）マルチリンク装置（ＭＬＤ）とは別の、又はマルチリンク装置（ＭＬＤ）に関連する局（ＳＴＡ）であって、制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）のスケジューリングサービス期間（ＳＰ）にわたってＩＥＥＥ８０２プロトコルに従って無線ローカルエリアネットワーク（ＷＬＡＮ）上でキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してパケットでのフレームの送信を実行する他の無線局（ＳＴＡ）とチャネルを介して無線で通信するように構成された局（ＳＴＡ）としての無線通信回路と、（ｂ）前記ＳＴＡに結合されてＷＬＡＮ上で動作するプロセッサと、（ｃ）プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリとを備え、（ｄ）前記命令は、プロセッサによって実行された時に、Ｒ－ＴＷＴのメンバーＳＴＡとフレームを交換するためのＲ－ＴＷＴスケジューリングを告知する上で、（ｄ）（ｉ）Ｒ－ＴＷＴスケジューリングを実行するように構成されたアクセスポイント（ＡＰ）として動作する前記局がＲ－ＴＷＴスケジュール側ＡＰであり、前記Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴメンバーＳＴＡがＲ－ＴＷＴ ＳＰに入ることと、（ｄ）（ｉｉ）前記Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰの予定終了時刻前に前記Ｒ－ＴＷＴ ＳＰを終了させてチャネル上で終了告知を送信することと、（ｄ）（ｉｉｉ）ネットワーク上のＲ－ＴＷＴのメンバーＳＴＡではない他のＳＴＡが、前記終了告知を受け取ったことに応答してチャネルを求めて直ちに競合できることと、を含む１又は２以上のステップを実行する、装置。
【0326】
ネットワークにおける無線通信のための装置であって、（ａ）マルチリンク装置（ＭＬＤ）とは別の、又はマルチリンク装置（ＭＬＤ）に関連する局（ＳＴＡ）であって、制限付きターゲットウェイクタイム（Ｒ－ＴＷＴ）のスケジューリングサービス期間（ＳＰ）にわたってＩＥＥＥ８０２プロトコルに従って無線ローカルエリアネットワーク（ＷＬＡＮ）上でキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してパケットでのフレームの送信を実行する他の無線局（ＳＴＡ）とチャネルを介して無線で通信するように構成された局（ＳＴＡ）としての無線通信回路と、（ｂ）前記ＳＴＡに結合されてＷＬＡＮ上で動作するプロセッサと、（ｃ）プロセッサによって実行可能な、他のＳＴＡと通信するための命令を記憶する非一時的メモリとを備え、（ｄ）前記命令は、プロセッサによって実行された時に、Ｒ－ＴＷＴのメンバーＳＴＡとフレームを交換するためのＲ－ＴＷＴスケジューリングを告知する上で、（ｄ）（ｉ）Ｒ－ＴＷＴスケジューリングを実行するように構成されたアクセスポイント（ＡＰ）として動作するＲ－ＴＷＴスケジュール側ＡＰとしての前記局とＲ－ＴＷＴメンバーＳＴＡとがＲ－ＴＷＴ ＳＰに入ることと、（ｄ）（ｉｉ）前記Ｒ－ＴＷＴ ＳＰ中に、前記Ｒ－ＴＷＴスケジュール側ＡＰとＲ－ＴＷＴメンバーＳＴＡとの間でフレームを交換することと、（ｄ）（ｉｉｉ）Ｒ－ＴＷＴ ＳＰ中に前記Ｒ－ＴＷＴスケジュール側ＡＰが前記Ｒ－ＴＷＴメンバーＳＴＡとの間でフレーム交換を完了した後に、前記Ｒ－ＴＷＴスケジュール側ＡＰと、Ｒ－ＴＷＴ機能を有しているがＲ－ＴＷＴメンバーＳＴＡではないＳＴＡとの間でフレームを交換することと、を含む１又は２以上のステップを実行する、装置。
【0327】
パケットの送信を行う無線通信システム／装置であって、システム／装置においてＣＳＭＡ／ＣＡが適用され、Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴスケジューリングを告知してＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴのメンバーＳＴＡとフレームを交換し、（ａ）Ｒ－ＴＷＴスケジュール側ＡＰ及びＲ－ＴＷＴメンバーＳＴＡが、これらの間のフレーム交換のためのＲ－ＴＷＴ ＳＰを開始することと、（ｂ）Ｒ－ＴＷＴメンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰ中に送信すべきさらなるフレームを有していない時にＲ－ＴＷＴスケジュール側ＡＰに信号を送信することと、（ｃ）Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰ中に全てのフレーム交換が終了した時にＲ－ＴＷＴ ＳＰの終了を示す信号を送信することと、を含む、無線通信システム／装置。
【0328】
前記終了条件は、Ｒ－ＴＷＴメンバーＳＴＡとして動作する前記ＳＴＡが、通信すべきフレームをそれ以上有していないと判定した後に、Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームをそれ以上有していないことを示す信号を前記Ｒ－ＴＷＴスケジュール側ＡＰに送信した時に発生する、いずれかの先行する実装の装置又は方法又はシステム。
【0329】
前記終了条件は、前記Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰを終了させるために、前記Ｒ－ＴＷＴ ＳＰの予定終了時刻前に発生する、いずれかの先行する実装の装置又は方法又はシステム。
【0330】
前記Ｒ－ＴＷＴ ＳＰ中に前記Ｒ－ＴＷＴスケジュール側ＡＰとＲ－ＴＷＴメンバーＳＴＡとの間でフレームを交換することをさらに含む、いずれかの先行する実装の装置又は方法又はシステム。
【0331】
前記Ｒ－ＴＷＴスケジュール側ＡＰがＲ－ＴＷＴ ＳＰ中にＲ－ＴＷＴメンバーＳＴＡとのフレーム交換を完了した後に、前記Ｒ－ＴＷＴスケジュール側ＡＰと、Ｒ－ＴＷＴ機能を有しているがＲ－ＴＷＴメンバーＳＴＡではないＳＴＡとの間でフレームを交換することをさらに含む、いずれかの先行する実装の装置又は方法又はシステム。
【0332】
前記命令は、プロセッサによって実行された時に、Ｒ－ＴＷＴメンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰ中に送信すべきアップリンク（ＵＬ）フレーム又はピアツーピア（Ｐ２Ｐ）フレームを有していない時に前記Ｒ－ＴＷＴスケジュール側ＡＰに信号を送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0333】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴメンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームを有していないことを示すフレームを送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0334】
Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームを有していないことを示す前記フレームは、（ａ）サービス品質（ＱｏＳ）データフレーム又はＱｏＳヌルフレームではないフレームと、（ｂ）前記Ｒ－ＴＷＴメンバーＳＴＡがＲ－ＴＷＴ ＳＰ中に送信すべきさらなるフレームを有していないことを表す状態にあるさらなるデータフィールドとしての、さらなるデータを有しているかどうかを示すフィールドを含むフレームと、を含む、いずれかの先行する実装の装置又は方法又はシステム。
【0335】
前記命令は、プロセッサによって実行された時に、Ｒ－ＴＷＴメンバーＳＴＡが、Ｒ－ＴＷＴメンバーＳＴＡがＲ－ＴＷＴ ＳＰ中に送信すべきＵＬ及び／又はＰ２Ｐフレームを有していないことを示す状態に設定されたＥＯＳＰサブフィールドを有するＱｏＳデータ又はＱｏＳヌルフレームを送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0336】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、ＥＯＳＰサブフィールドがＲ－ＴＷＴ ＳＰの終了を示す状態に設定されたＱｏＳデータフレーム又はＱｏＳヌルフレームを送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0337】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、送信すべきさらなるデータが存在するかどうかを示すさらなるデータフィールドとしてのフィールドを有するフレームであって、前記さらなるデータフィールドがＲ－ＴＷＴ ＳＰの終了を示す値に設定されたＱｏＳデータフレームでもＱｏＳヌルフレームでもないフレームを送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0338】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰの終了を示すために競合なし（ＣＦ）終了フレームを送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0339】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、さらなるトリガーフレームが存在するかどうかを示すフィールドを有する、いずれの特定のＲ－ＴＷＴメンバーＳＴＡにもアドレス指定されていないトリガーフレームを送信し、フィールドを、Ｒ－ＴＷＴ ＳＰの終了を示すように設定することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0340】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰの終了を示すＲ－ＴＷＴ識別に等しく設定されたＴＷＴフロー識別フィールドを有するＴＷＴ情報フレームを送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0341】
前記命令は、プロセッサによって実行された時に、前記メンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰが終了した旨の指示を含むフレームを前記Ｒ－ＴＷＴスケジュール側ＡＰから受け取ったことに応答してＲ－ＴＷＴ ＳＰが終了したことを認識することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0342】
前記命令は、前記プロセッサによって実行された時に、前記メンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰが終了したことを示す確認応答を前記Ｒ－ＴＷＴスケジュール側ＡＰから受け取ったことに応答してＲ－ＴＷＴ ＳＰが終了したことを認識することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0343】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴ ＳＰの終了を示す信号を、チャネルを介して送信することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0344】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴメンバーＳＴＡが、Ｒ－ＴＷＴ ＳＰの終了後にＲ－ＴＷＴ ＳＰの予定終了時刻に到達するまでチャネルを求めて競合できないことを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0345】
前記命令は、プロセッサによって実行された時に、Ｒ－ＴＷＴ ＳＰが終了した後にＲ－ＴＷＴ ＳＰの予定終了時刻まで、Ｒ－ＴＷＴメンバーＳＴＡが該Ｒ－ＴＷＴメンバーＳＴＡの通常のＥＤＣＡパラメータ設定よりも低い優先度でチャネルを求めて競合することを許可することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0346】
前記命令は、プロセッサによって実行された時に、前記Ｒ－ＴＷＴスケジュール側ＡＰが、Ｒ－ＴＷＴメンバーＳＴＡとのフレーム交換のための送信機会（ＴＸＯＰ）を、Ｒ－ＴＷＴ ＳＰの予定終了時刻を超えて延長することを含むステップをさらに実行する、いずれかの先行する実装の装置又は方法又はシステム。
【0347】
Ｒ－ＴＷＴメンバーＳＴＡは、Ｒ－ＴＷＴ ＳＰ中に送信すべきＵＬフレーム又はＰ２Ｐフレームを有していない時に、Ｒ－ＴＷＴスケジュール側ＡＰに信号を送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0348】
Ｒ－ＴＷＴメンバーＳＴＡは、Ｒ－ＴＷＴ ＳＰ中に送信すべきフレームを有していないことを示すために、さらなるデータフィールドが０に等しいＱｏＳデータでもＱｏＳヌルフレームでもないフレームを送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0349】
Ｒ－ＴＷＴメンバーＳＴＡは、Ｒ－ＴＷＴ ＳＰ中に送信すべきＵＬフレーム及びＰ２Ｐフレームを有していないことを示すために、ＥＯＳＰサブフィールドが１に等しいＱｏＳデータ又はＱｏＳヌルフレームを送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0350】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの終了を示すために、ＥＯＳＰサブフィールドが１に等しいＱｏＳデータ又はＱｏＳヌルフレームを送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0351】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの終了を示すために、さらなるデータフィールドが０に等しいＱｏＳデータでもＱｏＳヌルフレームでもないフレームを送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0352】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの終了を示すためにＣＦ終了フレームを送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0353】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの終了を示すために、さらなるＴＦフィールドが０に等しくいずれのＲ－ＴＷＴメンバーＳＴＡにもアドレス指定されていないトリガーフレームを送信することができる、先行する実装の装置又は方法又はシステム。
【0354】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの終了を示すために、Ｒ－ＴＷＴ ＩＤに等しいＴＷＴフロー識別フィールドを有するＴＷＴ情報フレームを送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0355】
ＳＴＡは、即時応答を要求しないＲ－ＴＷＴ ＳＰの終了を示すフレームをＲ－ＴＷＴスケジュール側ＡＰから受け取った時に、Ｒ－ＴＷＴ ＳＰの終了を認識することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0356】
ＳＴＡは、Ｒ－ＴＷＴスケジュール側ＡＰから送信されたＲ－ＴＷＴ ＳＰの終了を示すフレームに応答して確認応答を受け取った時に、Ｒ－ＴＷＴ ＳＰの終了を認識することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0357】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴ ＳＰの終了を示す信号を送信することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0358】
Ｒ－ＴＷＴメンバーＳＴＡは、Ｒ－ＴＷＴ ＳＰが終了した後にＲ－ＴＷＴ ＳＰの予定終了時刻までチャネルを求めて競合することができない、先行する実装の装置又は方法又はシステム。
【0359】
Ｒ－ＴＷＴメンバーＳＴＡは、Ｒ－ＴＷＴ ＳＰが終了した後にＲ－ＴＷＴ ＳＰの予定終了時刻まで低い優先度でチャネルを求めて競合することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0360】
Ｒ－ＴＷＴスケジュール側ＡＰは、Ｒ－ＴＷＴメンバーＳＴＡとのフレーム交換のＴＸＯＰを、Ｒ－ＴＷＴ ＳＰの予定終了時刻を超えて延長することができる、いずれかの先行する実装の装置又は方法又はシステム。
【0361】
本明細書で使用する「実装」という用語は、本明細書で説明する技術を実践するための実施形態、実施例、又はその他の形態を制限なく含むように意図される。
【0362】
本明細書で使用する単数形の「ａ、ａｎ（英文不定冠詞）」及び「ｔｈｅ（英文定冠詞）」は、文脈において別途明確に示されていない限り複数形の照応を含む。ある物体に対する単数形での言及は、明確にそう述べていない限り「唯一」を意味するものではなく、「１又は２以上」を意味する。
【0363】
本開示における「Ａ、Ｂ及び／又はＣ」などの表現構造は、Ａ、Ｂ又はＣのいずれか、或いは項目Ａ、Ｂ及びＣのいずれかの組み合わせが存在し得ることを表す。「～のうちの少なくとも１つ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ）」の後にリストされた一群の要素が続くものなどを示す表現構造は、該当する際にはこれらのリストされた要素のいずれかの考えられる組み合わせを含む、これらの一群の要素のうちの少なくとも１つが存在することを示す。
【0364】
本開示における「ある実施形態」、「少なくとも１つの実施形態」又は同様の実施形態という言い回しについて言及する参照は、説明する実施形態に関連して説明した特定の特徴、構造又は特性が本開示の少なくとも１つの実施形態に含まれることを示す。従って、これらの様々な実施形態の表現は、必ずしも全てが同じ実施形態、又は説明されている他の全ての実施形態とは異なる特定の実施形態を意味するわけではない。実施形態という表現は、所与の実施形態の特定の特徴、構造又は特性を、開示する装置、システム又は方法の１又は２以上の実施形態においていずれかの好適な形で組み合わせることができることを意味するものとして解釈すべきである。
【0365】
本明細書で使用する「組（ｓｅｔ）」という用語は、１又は２以上の物体の集合を意味する。従って、例えば物体の組は、単一の物体又は複数の物体を含むことができる。
【0366】
本文書における第１及び第２、頂部及び底部などの関係語は、１つの実体又は行動を別の実体又は行動と区別するために使用しているにすぎず、必ずしもこのような実体又は行動同士のこのようないずれかの実際の関係又は順序を必要としたり、又は意味したりするものではない。
【0367】
「備える、有する、含む（ｃｏｍｐｒｉｓｅｓ、ｃｏｍｐｒｉｓｉｎｇ、ｈａｓ、ｈａｖｉｎｇ、ｉｎｃｌｕｄｅｓ、ｉｎｃｌｕｄｉｎｇ、ｃｏｎｔａｉｎｓ、ｃｏｎｔａｉｎｉｎｇ）」という用語、又はこれらの用語の他のあらゆる変化形は、非排他的包含を含むことが意図されており、従って、ある要素リストを備える、有する又は含むプロセス、方法、物品又は装置は、これらの要素のみを含むのではなく、明示的に列挙していない、又はこのようなプロセス、方法、物品又は装置に特有の他の要素を含むこともできる。「～を備える、有する、又は含む（ｃｏｍｐｒｉｓｅｓ … ａ、ｈａｓ … ａ、ｉｎｃｌｕｄｅｓ … ａ、ｃｏｎｔａｉｎｓ … ａ）」に続く要素は、その要素を備える、有する又は含むプロセス、方法、物品又は装置にさらなる同一要素が存在することを、さらなる制約を受けることなく除外するものではない。
【0368】
本明細書で使用する「近似的に（ａｐｐｒｏｘｉｍａｔｅｌｙ）」、「近似する（ａｐｐｒｏｘｉｍａｔｅ）」、「実質的に（ｓｕｂｓｔａｎｔｉａｌｌｙ）」、「基本的に（ｅｓｓｅｎｔｉａｌｌｙ）」及び「約（ａｂｏｕｔ）」という用語、又はこれらのいずれかの変形形態は、わずかな変動の記述及び説明のために使用するものである。これらの用語は、事象又は状況に関連して使用した時には、これらの事象又は状況が間違いなく発生する場合、及びこれらの事象又は状況が発生する可能性が非常に高い場合を意味することができる。これらの用語は、数値に関連して使用した時には、その数値の±５％以下、±４％以下、±３％以下、±２％以下、±１％以下、±０．５％以下、±０．１％以下、又は±０．０５％以下などの、±１０％以下の変動範囲を意味することができる。例えば、「実質的に」整列しているということは、±５°以下、±４°以下、±３°以下、±２°以下、±１°以下、±０．５°以下、±０．１°以下、又は±０．０５°以下などの、±１０°以下の角度変動範囲を意味することができる。
【0369】
また、本明細書では、量、比率及びその他の数値を範囲形式で示すこともある。このような範囲形式は、便宜的に単純化して使用するものであり、範囲の限界として明確に指定された数値を含むが、この範囲に含まれる全ての個々の数値又は部分的範囲も、これらの各数値及び部分的範囲が明確に示されているかのように含むものであると柔軟に理解されたい。例えば、約１～約２００の範囲内の比率は、約１及び約２００という明確に列挙した限界値を含むが、約２、約３、約４などの個々の比率、及び約１０～約５０、約２０～約１００などの部分的範囲も含むと理解されたい。
【0370】
本明細書で使用する「結合される（ｃｏｕｐｌｅｄ）」という用語は、「接続される」と定義されるが、必ずしも直接的な機械的接続ではない。特定の形で「構成される（ｃｏｎｆｉｇｕｒｅｄ）」装置又は構造は、少なくともその形で構成されるが、列挙していない形で構成することもできる。
【0371】
利点、長所、問題解決手段、及びいずれかの利点、長所又は解決手段を生じさせる、又はより顕著にするいずれかの（単複の）要素は、本明細書で説明した技術、或いは一部又は全部の請求項の重要な、必要な又は不可欠な特徴又は要素として解釈すべきでない。
【0372】
また、上述した開示では、開示を合理化する目的で様々な実施形態において様々な特徴を共にグループ化することができる。本開示の方法は、請求項に記載する実施形態が、各請求項に明示的に記載する特徴よりも多くの特徴を必要とするという意図を反映したものであると解釈すべきではない。本発明の主題は、開示した単一の実施形態の全ての特徴よりも少ないものによって成立することができる。
【0373】
本開示の要約書は、読者が技術開示の本質を素早く確認できるように示すものである。要約書は、特許請求の範囲又はその意味を解釈又は限定するために使用されるものではないという理解の下で提示するものである。
【0374】
管轄によっては、出願後に本開示の１又は２以上の部分の削除を求める慣行もあると理解されたい。従って、読者は、本開示の元々の内容については出願日時点の出願を参照すべきである。開示内容のいずれかの削除は、当初出願時の出願のいずれかの主題の放棄、失権又は公衆への献呈として解釈すべきではない。
【0375】
以下の特許請求の範囲は、各請求項が単独の発明主題として自立した状態で本開示に組み込まれる。
【0376】
本明細書の説明は多くの詳細を含んでいるが、これらは本開示の範囲を限定するものではなく、現在のところ好ましい実施形態の一部を例示するものにすぎないと解釈すべきである。従って、本開示の範囲は、当業者に明らかになると考えられる他の実施形態も完全に含むと理解されるであろう。
【0377】
当業者に周知の本開示の実施形態の要素の構造的及び機能的同等物も、引用によって本明細書に明確に組み入れられ、本特許請求の範囲に含まれるように意図される。さらに、本開示の要素、構成要素又は方法ステップは、これらが特許請求の範囲に明示されているかどうかにかかわらず、一般に公開されるように意図するものではない。本明細書における請求項の要素については、その要素が「～のための手段」という表現を使用して明確に示されていない限り、「ミーンズプラスファンクション」の要素として解釈すべきではない。また、本明細書における請求項の要素については、その要素が「～のためのステップ」という表現を使用して明確に示されていない限り、「ステッププラスファンクション」の要素として解釈すべきではない。
【符号の説明】
【0378】
１７０ 実施形態例
１７２ スケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘメンバーＳＴＡとの間でＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームの交換を開始
１７４ Ｒ－ＴＷＴｘ ＳＰの予定終了時刻前に全てのスケジュールされたトラフィックが送信されたか？
１７６ スケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰの残り時間中にＲ－ＴＷＴｘのメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡとフレームを交換
１７８ スケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰの終了を示す信号を送信
１８０ スケジュール側ＡＰが予定終了時刻にＲ－ＴＷＴｘ ＳＰを終了
表１
Ｒ－ＴＷＴ ＳＰ中に送信をスケジュールされるＳＣＳトラフィックストリーム
１７２ スケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰ中にＲ－ＴＷＴｘメンバーＳＴＡとの間でＲ－ＴＷＴｘのスケジュールされたトラフィックストリームのフレームの交換を開始
１７４ Ｒ－ＴＷＴｘ ＳＰの予定終了時刻前に全てのスケジュールされたトラフィックが送信されたか？
１７６ スケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰの残り時間中にＲ－ＴＷＴｘのメンバーＳＴＡではない被Ｒ－ＴＷＴスケジュール側ＳＴＡとフレームを交換
１７８ スケジュール側ＡＰがＲ－ＴＷＴｘ ＳＰの終了を示す信号を送信
１８０ スケジュール側ＡＰが予定終了時刻にＲ－ＴＷＴｘ ＳＰを終了
表１
Ｒ－ＴＷＴ ＳＰ中に送信をスケジュールされるＳＣＳトラフィックストリーム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【国際調査報告】