ホーム > 特許ランキング > ソニーグループ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-09-13
(54)【発明の名称】ＭＵ－ＭＩＭＯパケット到着前チャネル競合
(51)【国際特許分類】
H04W 72/12 20090101AFI20220906BHJP
H04W 16/28 20090101ALI20220906BHJP
H04W 84/12 20090101ALI20220906BHJP
H04W 72/04 20090101ALI20220906BHJP
【ＦＩ】
H04W72/12 110
H04W16/28 130
H04W84/12
H04W72/04 131
H04W72/04 132
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2021577585
(86)(22)【出願日】2020-06-30
(85)【翻訳文提出日】2021-12-27
(86)【国際出願番号】 IB2020056147
(87)【国際公開番号】W WO2021001749
(87)【国際公開日】2021-01-07
(31)【優先権主張番号】62/870,149
(32)【優先日】2019-07-03
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/710,217
(32)【優先日】2019-12-11
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(74)【代理人】
【識別番号】100092093
【弁理士】
【氏名又は名称】辻居 幸一
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100109335
【弁理士】
【氏名又は名称】上杉 浩
(74)【代理人】
【識別番号】100120525
【弁理士】
【氏名又は名称】近藤 直樹
(74)【代理人】
【識別番号】100151987
【弁理士】
【氏名又は名称】谷口 信行
(72)【発明者】
【氏名】アブエルサウード モハメド
(72)【発明者】
【氏名】迫田 和之
(72)【発明者】
【氏名】シン リャンシャオ
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA14
5K067BB21
5K067DD11
5K067EE02
5K067EE10
5K067EE22
5K067KK03
(57)【要約】
リアルタイムアプリケーション（ＲＴＡ）パケットをサポートする無線ローカルエリアネットワーク（ＷＬＡＮ）通信のためのシステム、装置及び方法。アクセスポイント（ＡＰ）が、ＲＴＡパケット到着前にパケット送信にリソースを配分することによって、ＲＴＡパケットのアップリンク（ＵＬ）又はダウンリンク（ＤＬ）のマルチユーザ（ＭＵ）多入力多出力（ＭＩＭＯ）送信をスケジュールする。ＡＰは、ＤＬ又はＵＬ方向のＲＴＡパケットの予想到着時刻前にチャネルアクセスのために競合する。この動作は、ＷＬＡＮにおけるＲＴＡパケットの遅延時間を低減する。
【選択図】図２４
【選択図】図２４
【特許請求の範囲】
【請求項1】
ネットワークにおける無線通信装置であって、（ａ）自機の受信エリア内の少なくとも１つの他の無線ローカルエリアネットワーク（ＷＬＡＮ）局と無線で通信してアクセスポイント（ＡＰ）又は非ＡＰのいずれかとして動作する局として構成された無線通信回路と、
（ｂ）前記ＷＬＡＮ上で動作するように構成された局内の、前記無線通信回路に結合されたプロセッサと、
（ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリと、
を備え、
（ｄ）前記命令は、前記プロセッサによって実行された時に、
（ｉ）通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させることと、
（ｉｉ）事前ネゴシエーション、又はパケットヘッダ情報、或いは事前ネゴシエーションとパケットヘッダ情報との組み合わせによって、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することと、
（ｉｉｉ）ＤＬ ＭＵ－ＭＩＭＯ送信を実行するＡＰとして動作する際、又はＵＬ ＭＵ ＭＩＭＯ送信を実行する非ＡＰ局として動作する際に、ＲＴＡパケット到着時刻及び周期性に関する情報を取得することと、
を含むステップを実行し、
（ｉｖ）ＲＴＡパケットのアップリンク（ＵＬ）又はダウンリンク（ＤＬ）のマルチユーザ（ＭＵ）多入力多出力（ＭＩＭＯ）送信をスケジュールするアクセスポイント（ＡＰ）として動作する前記局は、ＲＴＡパケット到着前にパケット送信にリソースを配分することを実行し、前記ステップは、
（ｖ）ＡＰ局として動作する際に、前記ＤＬ又はＵＬ方向における前記ＲＴＡパケットの前記予想到着時刻前にチャネルアクセスのために競合して、（Ａ）前記ＡＰが前記ＲＴＡパケットの前記到着時刻の後又は該到着時刻に前記チャネルへのアクセス権を獲得した場合、前記配分されたリソース（ＲＵ）上で直ちにＲＴＡパケット送信をスケジュールし、又は（Ｂ）前記ＡＰが前記ＲＴＡパケットの前記予想到着時刻前に前記チャネルへのアクセス権を獲得した場合、ＵＬ又はＤＬ送信のために前記同じ配分されたリソース（ＲＵ）上で別の局及びＲＴＡ局のカスケード化された送信をスケジュールすることをさらに含む、
ことを特徴とする装置。
【請求項2】
前記命令は、ＤＬ ＭＩＭＯのＡＰとして動作する前記プロセッサによって実行された時に、前記ＡＰが前記ＲＴＡパケットの到着前に前記チャネルへのアクセス権を獲得した場合、将来的なＤＬ ＲＴＡパケットをスケジュールすることと、前記ＤＬ ＲＴＡパケットの前記到着まで、パディングとして動作するダミーパケットを送信することとを含むステップを実行する、請求項１に記載の装置。
【請求項3】
前記命令は、ＤＬ ＭＩＭＯのＡＰとして動作する前記プロセッサによって実行された時に、ＤＬ ＭＵ－ＭＩＭＯフレームのプリアンブルを修正することによって、前記配分されたリソース（ＲＵ）での送信が遅延することを非ＡＰ局に通知して、前記非ＡＰ ＳＴＡが前記リソースを解析することで、前記パディング又はダミーパケットが送信された後に前記ＤＬ ＲＴＡパケットを予想することを可能にすることを含むステップをさらに実行する、請求項２に記載の装置。
【請求項4】
前記命令は、ＤＬ ＭＩＭＯのＡＰとして動作する前記プロセッサによって実行された時に、ＤＬ ＭＵ－ＭＩＭＯフレームのプリアンブルを修正することによって、前記配分されたリソース（ＲＵ）での送信が遅延することを非ＡＰ局に通知して、前記非ＡＰ ＳＴＡが前記リソースを解析することで、前記他の局の送信が完了した後に前記ＤＬ ＲＴＡパケットを予想することを可能にすることを含むステップをさらに実行する、請求項２に記載の装置。
【請求項5】
前記命令は、ＤＬ ＭＩＭＯのＡＰとして動作する前記プロセッサによって実行された時に、リソース配分（ＲＵ）上で将来的なＤＬ ＲＴＡパケットをスケジュールすることと、前記ＤＬ ＲＴＡパケットの前記到着まで、前記リソース配分（ＲＵ）を時間共有する別のＤＬ送信をスケジュールすることとを含むステップを実行する、請求項１に記載の装置。
【請求項6】
前記命令は、ＤＬ ＭＩＭＯのＡＰとして動作する前記プロセッサによって実行された時に、（ｉ）前記配分されたリソースが共有されることを示すように前記ユーザフィールド内のビットを設定して、別の局の前記情報を示す又は前記送信のパディングのための別のユーザフィールドを送信すること、或いは（ｉｉ）新たなユーザフィールドを定義して、前記遅延したＤＬ ＭＩＭＯ送信が開始する予定である前記ＤＬ ＭＩＭＯ送信の前記開始に関連する時間値を送信すること、のいずれかに応答して、非ＡＰ局に送信されるユーザフィールドのプリアンブルを、前記割り当てられたリソース（ＲＵ）が他の局と時間共有されることを示すように修正することをさらに含むステップを実行し、リソースを時間共有する両送信は、ＰＨＹパラメータを共有する、請求項５に記載の装置。
【請求項7】
前記命令は、アップリンク（ＵＬ）送信で非ＡＰ局として動作する前記プロセッサによって実行された時に、前記ＡＰにＲＴＡストリームセッション要求を送信して前記ＡＰに前記ＲＴＡセッション及び該ＲＴＡセッションのパラメータについて通知し、これに対してＡＰが確認応答及び前記ＲＴＡストリームセッション要求の受諾又は拒絶で応答して、前記アップリンク（ＵＬ）方向の送信にパケットが利用可能になる度にバッファステータスレポート（ＢＳＲ）を送信することに伴う遅延を排除することを含むステップを実行する、請求項１に記載の装置。
【請求項8】
前記命令は、アップリンク（ＵＬ）送信でＡＰ局として動作する前記プロセッサによって実行された時に、ＵＬ ＲＴＡパケット送信のためにリソース（ＲＵ）を配分することと、非ＡＰ ＳＴＡにトリガフレームを送信することとを含むステップを実行する、請求項１に記載の装置。
【請求項9】
前記命令は、アップリンク（ＵＬ）送信でＡＰ局として動作する前記プロセッサによって実行された時に、前記ＲＴＡパケットの到着前にリソース（ＲＵ）を配分するステップを実行する、請求項８に記載の装置。
【請求項10】
前記命令は、アップリンク（ＵＬ）送信でＡＰ局として動作する前記プロセッサによって実行された時に、前記ＰＨＹパラメータを示す第１のユーザフィールド及び前記ＵＬ送信の遅延した開始を示す第２のユーザフィールドという２つのユーザフィールドを前記非ＡＰ局にトリガフレーム内で送信することによって、前記ＲＴＡパケットを受け取った後にＵＬ送信を遅延させるように非ＡＰ ＳＴＡをスケジュールすることを含むステップを実行する、請求項８に記載の装置。
【請求項11】
前記命令は、アップリンク（ＵＬ）送信でＡＰ局として動作する前記プロセッサによって実行された時に、前記非ＡＰ ＳＴＡが前記配分されたリソース（ＲＵ）でパケットを送信していない時に前記非ＡＰ ＳＴＡがパディングデータ又はダミーパケットを送信するように要求することを含むステップを実行する、請求項１０に記載の装置。
【請求項12】
前記命令は、アップリンク（ＵＬ）送信でＡＰ局として動作する前記プロセッサによって実行された時に、局のＵＬデータの送信が遅延している時に他の局が送信を行うようにスケジュールすることを含むステップを実行する、請求項８に記載の装置。
【請求項13】
前記命令は、前記プロセッサによって実行された時に、前記配分されたリソース（ＲＵ）を時間共有していることを別の局に通知し、ＰＨＹパラメータを示す第１のユーザフィールド及び前記アップリンク（ＵＬ）送信の終了を示す第２のユーザフィールドという２つのユーザフィールドを前記別の局に前記トリガフレーム内で送信することを含むステップによって他の局のスケジューリングを実行する、請求項８に記載の装置。
【請求項14】
前記命令は、アップリンク（ＵＬ）送信で非ＡＰ局として動作する前記プロセッサによって実行された時に、前記ＡＰにＲＴＡパケットの待ち行列バッファ状態を送信してＲＴＡパケットスケジュール時間の推定値を更新することを含むステップを実行する、請求項１に記載の装置。
【請求項15】
ネットワークにおける無線通信装置であって、（ａ）自機の受信エリア内の少なくとも１つの他の無線ローカルエリアネットワーク（ＷＬＡＮ）局と無線で通信してアクセスポイント（ＡＰ）又は非ＡＰのいずれかとして動作する局として構成された無線通信回路と、
（ｂ）前記ＷＬＡＮ上で動作するように構成された局内の、前記無線通信回路に結合されたプロセッサと、
（ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリと、
を備え、
（ｄ）前記命令は、前記プロセッサによって実行された時に、
（ｉ）通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させることと、
（ｉｉ）事前ネゴシエーション、又はパケットヘッダ情報、或いは事前ネゴシエーションとパケットヘッダ情報との組み合わせによって、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することと、
（ｉｉｉ）ＤＬ ＭＵ－ＭＩＭＯ送信を実行するＡＰとして動作する際、又はＵＬ ＭＵ ＭＩＭＯ送信を実行する非ＡＰ局として動作する際に、ＲＴＡパケット到着時刻及び周期性に関する情報を取得することと、
を含むステップを実行し、
（ｉｖ）ＲＴＡパケットのアップリンク（ＵＬ）又はダウンリンク（ＤＬ）のマルチユーザ（ＭＵ）多入力多出力（ＭＩＭＯ）送信をスケジュールするアクセスポイント（ＡＰ）として動作する前記局は、ＲＴＡパケット到着前にパケット送信にリソースを配分することを実行し、ＤＬ ＭＩＭＯのＡＰとして動作する際に、前記ＡＰが前記ＲＴＡパケットの到着前に前記チャネルへのアクセス権を獲得した場合、将来的なＤＬ ＲＴＡパケットをスケジュールし、前記ＤＬ ＲＴＡパケットの前記到着まで、パディングとして動作するダミーパケットを送信し、前記ステップは、
（ｖ）ＡＰ局として動作する際に、前記ＤＬ又はＵＬ方向における前記ＲＴＡパケットの前記予想到着時刻前にチャネルアクセスのために競合して、（Ａ）前記ＡＰが前記ＲＴＡパケットの前記到着時刻の後又は該到着時刻に前記チャネルへのアクセス権を獲得した場合、前記配分されたリソース（ＲＵ）上で直ちにＲＴＡパケット送信をスケジュールし、又は（Ｂ）前記ＡＰが前記ＲＴＡパケットの前記予想到着時刻前に前記チャネルへのアクセス権を獲得した場合、ＵＬ又はＤＬ送信のために前記同じ配分されたリソース（ＲＵ）上で別の局及びＲＴＡ局のカスケード化された送信をスケジュールすることをさらに含む、
ことを特徴とする装置。
【請求項16】
前記命令は、ＤＬ ＭＩＭＯのＡＰとして動作する前記プロセッサによって実行された時に、リソース配分（ＲＵ）上で将来的なＤＬ ＲＴＡパケットをスケジュールすることと、前記ＤＬ ＲＴＡパケットの前記到着まで、前記リソース配分（ＲＵ）を時間共有する別のＤＬ送信をスケジュールすることとを含むステップを実行する、請求項１５に記載の装置。
【請求項17】
前記命令は、アップリンク（ＵＬ）送信で非ＡＰ局として動作する前記プロセッサによって実行された時に、前記ＡＰにＲＴＡストリームセッション要求を送信して前記ＡＰに前記ＲＴＡセッション及び該ＲＴＡセッションのパラメータについて通知し、これに対してＡＰが確認応答及び前記ＲＴＡストリームセッション要求の受諾又は拒絶で応答して、前記アップリンク（ＵＬ）方向の送信にパケットが利用可能になる度にバッファステータスレポート（ＢＳＲ）を送信することに伴う遅延を排除することを含むステップを実行する、請求項１５に記載の装置。
【請求項18】
前記命令は、アップリンク（ＵＬ）送信でＡＰ局として動作する前記プロセッサによって実行された時に、ＵＬ ＲＴＡパケット送信のためにリソース（ＲＵ）を配分することと、非ＡＰ ＳＴＡにトリガフレームを送信することとを含むステップを実行する、請求項１５に記載の装置。
【請求項19】
前記命令は、アップリンク（ＵＬ）送信で非ＡＰ局として動作する前記プロセッサによって実行された時に、前記ＡＰにＲＴＡパケットの待ち行列バッファ状態を送信してＲＴＡパケットスケジュール時間の推定値を更新することを含むステップを実行する、請求項１５に記載の装置。
【請求項20】
ネットワークにおける無線通信の実行方法であって、（ａ）無線通信回路を、自機の受信エリア内の少なくとも１つの他の無線ローカルエリアネットワーク（ＷＬＡＮ）局と無線で通信して、通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするアクセスポイント（ＡＰ）又は非ＡＰのいずれかとして動作する局として構成されたＷＬＡＮ局として動作させることと、
（ｂ）事前ネゴシエーション、又はパケットヘッダ情報、或いは事前ネゴシエーションとパケットヘッダ情報との組み合わせによって、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することと、
（ｃ）ＤＬ ＭＵ－ＭＩＭＯ送信を実行するＡＰとして動作する際、又はＵＬ ＭＵ ＭＩＭＯ送信を実行する非ＡＰ局として動作する際に、ＲＴＡパケット到着時刻及び周期性に関する情報を取得することと、
を含み、
（ｄ）ＲＴＡパケットのアップリンク（ＵＬ）又はダウンリンク（ＤＬ）のマルチユーザ（ＭＵ）多入力多出力（ＭＩＭＯ）送信をスケジュールするアクセスポイント（ＡＰ）として動作する前記局は、ＲＴＡパケット到着前にパケット送信にリソースを配分することを実行し、前記方法は、
（ｅ）ＡＰ局として動作する際に、前記ＤＬ又はＵＬ方向における前記ＲＴＡパケットの前記予想到着時刻前にチャネルアクセスのために競合して、（Ａ）前記ＡＰが前記ＲＴＡパケットの前記到着時刻の後又は該到着時刻に前記チャネルへのアクセス権を獲得した場合、前記配分されたリソース（ＲＵ）上で直ちにＲＴＡパケット送信をスケジュールし、又は（Ｂ）前記ＡＰが前記ＲＴＡパケットの前記予想到着時刻前に前記チャネルへのアクセス権を獲得した場合、ＵＬ又はＤＬ送信のために前記同じ配分されたリソース（ＲＵ）上で別の局及びＲＴＡ局のカスケード化された送信をスケジュールすることをさらに含む、
ことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【0001】
〔関連出願との相互参照〕
本出願は、２０１９年７月３日に出願された米国仮特許出願第６２／８７０，１４９号に対する優先権及びその利益を主張するものであり、この文献はその全体が引用により本明細書に組み入れられる。
本出願は、２０１９年７月３日に出願された米国仮特許出願第６２／８７０，１４９号に対する優先権及びその利益を主張するものであり、この文献はその全体が引用により本明細書に組み入れられる。
【0002】
〔連邦政府が支援する研究又は開発に関する記述〕
該当なし
該当なし
【0003】
〔コンピュータプログラム付属書の引用による組み入れ〕
該当なし
該当なし
【0004】
〔著作権保護を受ける資料の通知〕
本特許文献中の資料の一部は、アメリカ合衆国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、合衆国特許商標庁の一般公開ファイル又は記録内に表される通りに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定ではないが米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておく権利のいずれも本明細書によって放棄するものではない。
本特許文献中の資料の一部は、アメリカ合衆国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、合衆国特許商標庁の一般公開ファイル又は記録内に表される通りに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定ではないが米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておく権利のいずれも本明細書によって放棄するものではない。
【0005】
本開示の技術は、一般に無線通信局に関し、具体的には、リアルタイムトラフィックと非リアルタイムトラフィックとの組み合わせを通信する無線ローカルエリアネットワーク（ＷＬＡＮ）局に関する。
【背景技術】
【0006】
市場に投入される電子装置は、Ｗｉ－Ｆｉを通じてインターネットにアクセスできる割合がますます増えている。これらのＷｉ－Ｆｉネットワークは、日々拡大してより高いスループットを可能にするとともに、各ネットワークにより多くのユーザを接続できるようになっている。しかしながら、高密度環境又は干渉が存在する状況では遅延時間及び信頼性が保証されず、従ってＷｉ－Ｆｉネットワークは、一般に最善努力型通信（ｂｅｓｔ ｅｆｆｏｒｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ）とみなされる。
【発明の概要】
【発明が解決しようとする課題】
【0007】
リアルタイムゲーム、遠隔モニタリング及び制御、並びにその他の遅延感度の高いアプリケーションは、最小限のパケット遅延及びトラフィック信頼性に大きな価値がある急成長カテゴリである。通信されるパケットは、遅延すると容易にその価値を失ってしまう恐れがある。他のアプリケーションでは、エンドツーエンド遅延がエンドユーザに気付かれない限り、許容可能なユーザ体験レベルに達することができる。これらの問題を考慮すると、あらゆる遅延スパイクは性能を損ない、及び／又は偽の結果（ｓｐｕｒｉｏｕｓ ｒｅｓｕｌｔｓ）をもたらす恐れがあるので、システム設計では、最悪遅延時間などのパラメータを研究してこれに対処することが非常に重要である。
【0008】
ＣＳＭＡ／ＣＡを使用する現在の無線技術は、ネットワークの高スループット性能には重点を置いているが低遅延動作をもたらさない。従って、リアルタイムアプリケーション（ＲＴＡ）などの多くのアプリケーションは低遅延時間を必要とするため技術格差が生じている。ＲＴＡデータは、一定期間内に配信される場合にのみ有効であるため、ＲＴＡトラフィックは、そのパケット配信に対する高い適時性要件に起因して低遅延時間を必要とする。
【0009】
従って、パケット遅延時間を低減する無線通信装置及び方法に対するニーズが存在する。本開示は、このニーズを満たすとともに、これまでの技術を凌駕するさらなる利点をもたらすものである。
【課題を解決するための手段】
【0010】
局（ＳＴＡ）がより短いチャネル競合時間でより高速にチャネルにアクセスすることを可能にすることにより、リアルタイムアプリケーション（ＲＴＡ）のパケット遅延時間の低減に到達することができる。ＳＴＡは、現在のランダムアクセスチャネルシナリオに起因して、各パケットの送信前にチャネルアクセスを検知してこのために競合する必要があり、このことがパケット遅延の原因になる場合がある。他の遅延原因としては、エンドツーエンドのパケット送信遅延を増大させる節電モードの動作、待ち行列遅延及び送信遅延が挙げられる。
【0011】
本開示は、現在の８０２．１１プロトコルのＭＡＣ層及びＰＨＹ層を、ＲＴＡの最悪遅延時間を抑制して接続信頼性を改善できるように変更するものである。
【0012】
リアルタイムアプリケーション（ＲＴＡ）パケットのアップリンク（ＵＬ）又はダウンリンク（ＤＬ）のマルチユーザ（ＭＵ）多入力多出力（ＭＩＭＯ）送信をスケジュールするアクセスポイント（ＡＰ）が、ＲＴＡパケットの到着前にパケット送信にリソース（ＲＵ）を配分し、予想されるＲＴＡパケットの到着前であってもチャネルへのアクセス権を獲得することができる。
【0013】
本明細書の以下の部分では、本明細書で説明する技術のさらなる態様が明らかになり、この詳細な説明は、本技術の好ましい実施形態を制限することなく完全に開示するためのものである。
【0014】
本明細書で説明する技術は、例示のみを目的とする以下の図面を参照することによって十分に理解されるであろう。
【図面の簡単な説明】
【0015】
【図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】本開示の少なくとも１つの実施形態による、高効率（ＨＥ）マルチユーザ（ＭＵ）ＰＰＤＵフレームフォーマットのデータフィールド図である。
【図39】本開示の少なくとも１つの実施形態に従って実行される、別のＳＴＡ送信をカスケード化するようにＲＴＡ ＳＴＡを割り当てる前及び後のＲＴＡユーザフィールド図である。
【図40】本開示の少なくとも１つの実施形態に従って実行される、別のＳＴＡ送信をカスケード化するようにＲＴＡ ＳＴＡを割り当てる前及び後のＲＴＡユーザフィールド図である。
【図41】本開示の少なくとも１つの実施形態による、ＡＰのＲＴＡデータのＤＬ ＯＦＤＭＡ競合前及び将来的スケジューリングのフロー図である。
【図42】本開示の少なくとも１つの実施形態による、ＭＵ－ＭＩＭＯ又は遅延したＲＴＡパケット送信をスケジュールするフロー図である。
【図43】本開示の少なくとも１つの実施形態による、ＡＰから受け取られた、ＲＴＡパケットの将来的スケジューリングを含むパケットをＳＴＡが処理するフロー図である。
【図44】本開示の少なくとも１つの実施形態による、他のＳＴＡによって共有されるＲＵが複数存在する場合のユーザフィールドを示すデータフィールド図である。
【図45】本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡを実行しているＳＴＡとのＵＬ ＯＦＤＭＡ／ＭＵ－ＭＩＭＯを例示するＲＵ送信図である。
【図46A】本開示の少なくとも１つの実施形態に従って実行されるＵＬ ＲＴＡ要求のＲＵ送信図である。
【図46B】本開示の少なくとも１つの実施形態に従って実行されるＵＬ ＲＴＡ要求のＲＵ送信図である。
【図47】本開示の少なくとも１つの実施形態に従って実行される、非ＡＰ ＳＴＡからＡＰにＲＴＱＴＤフィードバックメッセージを送信することを通じてＲＴＡパケットのスケジュール時間を調整するＲＵ送信図である。
【図48】本開示の少なくとも１つの実施形態に従って実行される、非ＡＰ ＳＴＡがＡＰ ＳＴＡとフレームを交換する通信シーケンス図である。
【図49】本開示の少なくとも１つの実施形態に従って実行されるＵＬ ＲＴＡスケジューリングのＲＵ送信図である。
【図50】本開示の少なくとも１つの実施形態に従って実行される、２つのＳＴＡがＲＵを共有するＵＬ ＳＴＡスケジューリングのＲＵ送信図である。
【図51A】本開示の少なくとも１つの実施形態による、ＡＰがＭＵ－ＭＩＭＯ技術を使用してＵＬ ＲＴＡパケット送信をスケジュールするフロー図である。
【図51B】本開示の少なくとも１つの実施形態による、ＡＰがＭＵ－ＭＩＭＯ技術を使用してＵＬ ＲＴＡパケット送信をスケジュールするフロー図である。
【図52】本開示の少なくとも１つの実施形態による、ＵＬ ＭＩＭＯ又は遅延したＵＬ ＲＴＡパケット送信をスケジュールするフロー図である。
【図53A】本開示の少なくとも１つの実施形態による、ＡＰから受け取られた、ＲＴＡパケットのＵＬスケジューリング及び将来的スケジューリングを含む基本トリガフレームをＳＴＡが処理するフロー図である。
【図53B】本開示の少なくとも１つの実施形態による、ＡＰから受け取られた、ＲＴＡパケットのＵＬスケジューリング及び将来的スケジューリングを含む基本トリガフレームをＳＴＡが処理するフロー図である。
【図54】本開示の少なくとも１つの実施形態による、ＵＬ ＭＵ－ＭＩＭＯ／ＯＦＤＭＡ送信のためにリソースを配分するトリガフレームのデータフィールド図である。
【図56A】本開示の少なくとも１つの実施形態による、複数のＳＴＡのカスケード化された送信の場合又は１つのＳＴＡ送信が遅延してこのＳＴＡがパディング情報を送信する必要がある場合に送信されるトリガフレームのデータフィールド図である。
【図56B】本開示の少なくとも１つの実施形態による、複数のＳＴＡのカスケード化された送信の場合又は１つのＳＴＡ送信が遅延してこのＳＴＡがパディング情報を送信する必要がある場合に送信されるトリガフレームのデータフィールド図である。
【図57】本開示の少なくとも１つの実施形態による、非ＡＰ ＳＴＡによってＡＰ ＳＴＡに送信されるＰＰＡＣＣ要求フレームのデータフィールド図である。
【図58】本開示の少なくとも１つの実施形態による、ＡＰ ＳＴＡによって非ＡＰ ＳＴＡに送信されるＰＰＡＣＣ応答フィールドのデータフィールド図である。
【図59】本開示の少なくとも１つの実施形態による、非ＡＰ ＳＴＡによってＡＰ ＳＴＡに送信されるＥＣＡ期間要求のデータフィールド図である。
【図60】本開示の少なくとも１つの実施形態による、ＡＰ ＳＴＡによって非ＡＰ ＳＴＡに送信されるＥＣＡ期間応答フレームのデータフィールド図である。
【図61】本開示の少なくとも１つの実施形態による、ＳＴＡによって関連するＡＰに送信されるＲＴＡストリーム開始要求のデータフィールド図である。
【図62】本開示の少なくとも１つの実施形態による、ＡＰによって関連するＳＴＡに送信されるＲＴＡストリーム開始応答のデータフィールド図である。
【図63】本開示の少なくとも１つの実施形態による、ＳＴＡによって関連するＡＰに送信されるＲＴＱＴＤフィードバックフィールドのデータフィールド図である。
【図64】本開示の少なくとも１つの実施形態による、ＲＴＡ送信の予測時間を更新するためにＳＴＡによって関連するＡＰに送信されるＲＴＱＴＤフィードバック確認応答のデータフィールド図である。
【発明を実施するための形態】
【0016】
１．８０２．１１ＷＬＡＮシステムの説明
無線ローカルエリアネットワーク（ＷＬＡＮ）性能を改善するために、具体的には２．４ＧＨｚ及び５ＧＨｚ帯に重点を置く提案などの数多くの８０２．１１修正案が提案されている。これらの過去の修正案の大部分は、最大受信データレートを当初提案されていた２Ｍビット／秒から８０２．１１ａｘ修正案では場合によって最大９．６ＧＨｚに改善することを目的としたものである。例えば、チャネル帯域幅の２０ＭＨｚから最大１６０ＭＨｚへの増加、新たな変調及び符号化スキームの使用、並びに多入力多出力（ＭＩＭＯ）及びマルチユーザ（ＭＵ）送信の導入を通じて物理層のデータレートを高める多くの技術が利用されてきた。送信のオーバーヘッドを低下させ、従ってデータスループットを向上させるために、他の媒体アクセス制御（ＭＡＣ）層の改善も導入されてきた。なお、ＭＡＣ層は、開放型システム間相互接続（ＯＳＩ）通信モデルで規定される７つ層のうちの１つである。このオーバーヘッドの低下は、例えばフレーム間隔を短縮し、パケットの集約化及びセグメント化を行い、Ｗｉ－Ｆｉネットワークにおけるサービス品質（ＱｏＳ）対応を改善し、局が節電のためにアウェイク状態とドーズ（スリープ）状態とを繰り返す電力消費プロトコルを適用することによって達成することができる。
無線ローカルエリアネットワーク（ＷＬＡＮ）性能を改善するために、具体的には２．４ＧＨｚ及び５ＧＨｚ帯に重点を置く提案などの数多くの８０２．１１修正案が提案されている。これらの過去の修正案の大部分は、最大受信データレートを当初提案されていた２Ｍビット／秒から８０２．１１ａｘ修正案では場合によって最大９．６ＧＨｚに改善することを目的としたものである。例えば、チャネル帯域幅の２０ＭＨｚから最大１６０ＭＨｚへの増加、新たな変調及び符号化スキームの使用、並びに多入力多出力（ＭＩＭＯ）及びマルチユーザ（ＭＵ）送信の導入を通じて物理層のデータレートを高める多くの技術が利用されてきた。送信のオーバーヘッドを低下させ、従ってデータスループットを向上させるために、他の媒体アクセス制御（ＭＡＣ）層の改善も導入されてきた。なお、ＭＡＣ層は、開放型システム間相互接続（ＯＳＩ）通信モデルで規定される７つ層のうちの１つである。このオーバーヘッドの低下は、例えばフレーム間隔を短縮し、パケットの集約化及びセグメント化を行い、Ｗｉ－Ｆｉネットワークにおけるサービス品質（ＱｏＳ）対応を改善し、局が節電のためにアウェイク状態とドーズ（スリープ）状態とを繰り返す電力消費プロトコルを適用することによって達成することができる。
【0017】
１．１．８０２．１１ａｘ－ＰＰＤＵフォーマット
図１に、ＩＥＥＥ８０２．１１ａｘでのシングルユーザ送信に使用される、ＩＥＥＥ８０２．１１ａｘのＨＥシングルユーザ（ＳＵ）ＰＰＤＵフォーマットを示す。なお、ＰＰＤＵは、物理層収束手順プロトコルデータユニット（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｃｅｄｕｒｅ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）の略である。ＰＰＤＵフレームは、ＰＳＤＵ＋ＰＨＹヘッダ及びプリアンブルを含む。高効率（ＨＥ）シングルユーザ（ＳＵ）ＰＰＤＵフレームは、（ａ）非ＨＴ短期訓練フィールドであるＬ－ＳＴＦ、（ｂ）非ＨＴ長期訓練フィールドであるＬ－ＬＴＦ、（ｃ）非ＨＴ信号フィールドであるＬ－ＳＩＧ、（ｄ）反復する非ＨＴ信号フィールドであるＲＬ－ＳＩＧ、（ｅ）ＨＥ信号ＡフィールドであるＨＥ－ＳＩＧ－Ａ、（ｆ）ＨＥ短期訓練フィールドであるＨＥ－ＳＴＦ、（ｇ）ＨＥ長期訓練フィールドであるＨＥ－ＬＴＦ、（ｈ）ＰＳＤＵを搬送するデータフィールドであるデータ（Ｄａｔａ）、及び（ｉ）パケット拡張フィールドであるＰＥを含む。
図１に、ＩＥＥＥ８０２．１１ａｘでのシングルユーザ送信に使用される、ＩＥＥＥ８０２．１１ａｘのＨＥシングルユーザ（ＳＵ）ＰＰＤＵフォーマットを示す。なお、ＰＰＤＵは、物理層収束手順プロトコルデータユニット（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｃｅｄｕｒｅ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）の略である。ＰＰＤＵフレームは、ＰＳＤＵ＋ＰＨＹヘッダ及びプリアンブルを含む。高効率（ＨＥ）シングルユーザ（ＳＵ）ＰＰＤＵフレームは、（ａ）非ＨＴ短期訓練フィールドであるＬ－ＳＴＦ、（ｂ）非ＨＴ長期訓練フィールドであるＬ－ＬＴＦ、（ｃ）非ＨＴ信号フィールドであるＬ－ＳＩＧ、（ｄ）反復する非ＨＴ信号フィールドであるＲＬ－ＳＩＧ、（ｅ）ＨＥ信号ＡフィールドであるＨＥ－ＳＩＧ－Ａ、（ｆ）ＨＥ短期訓練フィールドであるＨＥ－ＳＴＦ、（ｇ）ＨＥ長期訓練フィールドであるＨＥ－ＬＴＦ、（ｈ）ＰＳＤＵを搬送するデータフィールドであるデータ（Ｄａｔａ）、及び（ｉ）パケット拡張フィールドであるＰＥを含む。
【0018】
図２に、ダウンリンクマルチユーザ送信に使用されるＩＥＥＥ８０２．１１ａｘのＨＥマルチユーザ（ＭＵ）ＰＰＤＵフォーマットを示す。このフォーマットは、図１に示すシングルユーザＰＰＤＵフォーマットと比較すると、各ユーザに個別のリソースブロック配分情報を提供するＨＥ－ＳＩＧ－Ｂフィールドをフォーマットに追加する。
【0019】
図３に、アップリンクマルチユーザ送信に使用されるＨＥトリガベース（ＴＢ）のＰＰＤＵフォーマットを示す。ＨＥ ＴＢ ＰＰＤＵフォーマットのフィールドは、ＨＥ－ＳＴＦフィールドが８μｓであることを除いて図１のＨＥシングルユーザＰＰＤＵフォーマットのフィールドと同一である。
【0020】
図４に、ＩＥＥＥ８０２．１１ａｘのトリガフレームフォーマットの内容を示す。フレーム制御（ｆｒａｍｅ ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。継続時間（ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。
【0021】
図５に、各ＳＴＡのための情報を含むユーザ情報（ｕｓｅｒ Ｉｎｆｏ）フィールドを示す。共通情報（ｃｏｍｍｏｎ ｉｎｆｏ）フィールド及びユーザ情報フィールドは、各ユーザに個別のリソースブロック配分情報を提供する。これらのフィールドは、ＡＩＤ１２、ＲＵ配分（ＲＵ Ａｌｌｏｃａｔｉｏｎ）、コーディングタイプ（Ｃｏｄｉｎｇ Ｔｙｐｅ）、ＭＣＳ、ＤＣＭ、ＳＳ配分（ＳＳ Ａｌｌｏｃａｔｉｏｎ）、ターゲットＲＳＳＩ（Ｔａｒｇｅｔ ＲＳＳＩ）、及び予約（Ｒｅｓｅｒｖｅｄ）と共に示される。
【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】
７．３．早期競合ウィンドウ期間
ＳＴＡは、ＲＴＡセッションを確立すると、次のＲＴＡパケット到着のためのタイマを実行し始める。本開示によれば、ＳＴＡは、ＲＴＡパケットの到着前であってもチャネルアクセスのために競合することができる。この目的は、パケット到着の直前に誰かがチャネルへのアクセス権を獲得するのを避けるためである。パケット到着よりも早期競合ウィンドウ期間だけ早い期間中にチャネルが使用中である場合、ＳＴＡは競合を開始すべきである。この時間中にチャネルが空いている場合、ＳＴＡはチャネルの状態をモニタし続ける。早期競合ウィンドウ期間のサイズは、チャネルの占有率が高いこと（例えば、ＳＴＡが多いこと、チャネルの占有時間が長いこと、チャネルアクセス遅延率が高いこと、又はバックオフタイマ割り込み率が高いこと）を示している収集された統計に関連すべきである。早期競合ウィンドウ期間長は、手動で固定値に設定することも、或いはチャネル統計に従って動的に調整することもできる。
ＳＴＡは、ＲＴＡセッションを確立すると、次のＲＴＡパケット到着のためのタイマを実行し始める。本開示によれば、ＳＴＡは、ＲＴＡパケットの到着前であってもチャネルアクセスのために競合することができる。この目的は、パケット到着の直前に誰かがチャネルへのアクセス権を獲得するのを避けるためである。パケット到着よりも早期競合ウィンドウ期間だけ早い期間中にチャネルが使用中である場合、ＳＴＡは競合を開始すべきである。この時間中にチャネルが空いている場合、ＳＴＡはチャネルの状態をモニタし続ける。早期競合ウィンドウ期間のサイズは、チャネルの占有率が高いこと（例えば、ＳＴＡが多いこと、チャネルの占有時間が長いこと、チャネルアクセス遅延率が高いこと、又はバックオフタイマ割り込み率が高いこと）を示している収集された統計に関連すべきである。早期競合ウィンドウ期間長は、手動で固定値に設定することも、或いはチャネル統計に従って動的に調整することもできる。
【0086】
図２４に、早期競合ウィンドウ期間の動的調整を表す実施形態例１７０を示す。ルーチンが開始されると（１７２）、ＲＴＡセッションが開始され（１７４）、早期競合ウィンドウ（ＥＣＷ）期間がゼロ又は初期値に設定される（１７６）。チャネルの統計は、このフローチャートではループとして示す一定期間にわたって更新され、チャネルが混雑していればしているほどＥＣＷ期間の値が増加する。チャネルの混雑度が低下するとＥＣＷ期間の値も減少する。
【0087】
具体的には、チャネル統計を収集し（１７８）、チャネルの占有率が高いかそれとも低いかをチェックする（１８０）。この判定は閾値レベルに依存し、閾値レベルよりも上ではチャネルの占有率が「高い」とみなされ、閾値レベルよりも下ではチャネルの占有率が「低い」とみなされる。占有率が低いことが分かった場合、実行はブロック１８２に到達し、ＥＣＷ期間値を最小値（例えば、ゼロ）に向けて減少させる。或いは、占有率が高いことが分かった場合、実行はブロック１８４に到達し、ＥＣＷ期間値を最大値に向けて増加させる。いずれの場合にも、その後にＲＴＡセッションが依然としてアクティブであるかどうかをチェックする（１８６）。依然としてアクティブである場合には、タイマの満了を待って（１８８）ブロック１７８に戻り、そうでなければ実行は終了する（１８９）。
【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】
ＭＡＣヘッダにおいて未だＲＴＡパケットが利用可能でない場合、実行はブロック５５６に到達し、ＲＴＡパケットの推定到着時刻を認識しているＡＰは、ＲＴＡパケットがＴＸのために利用可能になるまでの残り時間を推定し、この時間を使用してＲＴＡパケットＴＸ時間をスケジュールする。次に、ブロック５５８において、この推定された残り時間内に収まる、他のＳＴＡへの送信に利用可能なパケットが存在するかどうかを判定するチェックを行う。これらの条件が満たされる場合、ＡＰは、ブロック５６６においてこのＲＴＡパケット及び他のＳＴＡパケット送信にＲＵを割り当て、ブロック５６８において他のＳＴＡにパケットを送信し、その後にＲＴＡパケットが利用可能である場合にはＲＴＡパケットを送信した上でプロセスは終了する（５６４）。
【0136】
一方で、ブロック５５８の条件が満たされない場合、ＡＰは、ブロック５６０においてＲＴＡパケット送信にＲＵを割り当て、ＲＴＡパケットが利用可能になる時点まで割り当てられたＲＵで送信されるようにパディングを追加して（５６２）プロセスは終了する（５６４）。
【0137】
８．１．８．ＲＴＡ ＳＴＡのフロー図
図４３に、ＡＰから受け取られたＲＴＡパケットの将来的なスケジューリングを含むパケットをＳＴＡが処理する実施形態例５７０を示す。プロセスが開始し（５７２）、ＭＵ－ＭＩＭＯ／ＯＦＤＭＡ ＰＰＤＵを含むパケットをＳＴＡがＡＰから受け取ったかどうかを判定するチェックを行い（５７４）、その後にアクティブなＲＴＡセッションを有しているかどうか、又は将来的なパケットスケジューリングを予想／有効化するかどうかをチェックする（５７６）。これらの条件がいずれも満たされない場合、実行は直接ブロック５８４に進んでパケットデータを処理し、処理を終了する（５９０）。
図４３に、ＡＰから受け取られたＲＴＡパケットの将来的なスケジューリングを含むパケットをＳＴＡが処理する実施形態例５７０を示す。プロセスが開始し（５７２）、ＭＵ－ＭＩＭＯ／ＯＦＤＭＡ ＰＰＤＵを含むパケットをＳＴＡがＡＰから受け取ったかどうかを判定するチェックを行い（５７４）、その後にアクティブなＲＴＡセッションを有しているかどうか、又は将来的なパケットスケジューリングを予想／有効化するかどうかをチェックする（５７６）。これらの条件がいずれも満たされない場合、実行は直接ブロック５８４に進んでパケットデータを処理し、処理を終了する（５９０）。
【0138】
一方で、ブロック５７４及び５７６の条件がいずれも満たされる場合にはブロック５７８に到達し、プリアンブルを解析してＰＰＤＵプリアンブルからスケジューリング情報を抽出する。ＲＵの時間共有についてチェックを行う（５８０）。このチェックによってＳＴＡが他のＳＴＡとＲＵを時間的に共有していることが示された場合、実行はブロック５８６に到達して、スケジュールされた送信のためにプリアンブルのＨＥ－ＳＩＧ－Ｂフィールドの最後からユーザフィールド情報を抽出し、この情報は、第１のＳＴＡがパケット送信を終了した後に識別されたＲＵ上でＲＴＡ送信が行われる（５８８）と予想されることを示す。受信機は、割り当てられたＲＵ上で送信されるパケットをモニタする。モニタされたＲＵにおけるＯＦＤＭＡフレームの最初には、パケットは第１の受信機に送信されない。第１のユーザへのパケットの送信が完了した後に、ＲＴＡユーザへのパケットが送信される。従って、受信機はＲＵをモニタしてＲＵ上でのデータ受信を予想し、その後にパケットデータが処理されて（５８４）プロセスは終了する（５９０）。
【0139】
一方で、チェック５８０において他のＳＴＡがこのＳＴＡとＲＵを時間的に共有していないことが判明した場合にはブロック５８２に到達し、ＳＴＡは、割り当てられたＲＵ上で受信データを解析し、ダミーＳＴＡに送信されるダミーパケットの形態のどのようなパディングがパケットの最初に必要になり得るかを判定する。ＳＴＡは、パディング又は他のＳＴＡ送信のＭＡＣヘッダを読み取って、そのパケットの最後及び自機のパケットの開始を知る。パディング５８２の後に、ＳＴＡのためのパケットが送信されて（５８４）プロセスは終了する（５９０）。
【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】
早期競合ウィンドウ期間長は、手動で固定値に設定することも、或いはチャネル統計に従って動的に調整することもできる。ＡＰは、早期チャネルアクセス期間までチャネルが空いていることを発見した場合、予想されるＲＴＡパケットの到着時刻を待つことなく直接チャネルにアクセスする。この期間は短いものと想定され、他のＳＴＡがチャネルへのアクセス権を獲得し、従ってＲＴＡパケット送信を遅延させないことを保証すべきである。
【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】
１７０ 実施形態例
１７２ 開始
１７４ ＲＴＡストリームの開始
１７６ ＥＣＷ長＝０
１７８ チャネル統計を収集
１８０ チャネルの占有率が高いかそれとも低いか？
１８２ ＥＣＷを最小値ゼロまで減少
１８４ 最大値を超えないようにＥＣＷを増加
１８６ ＲＴＡセッションが依然としてアクティブであるか？
１８８ 次の統計更新時間が期限切れか？
１８９ 終了
１７２ 開始
１７４ ＲＴＡストリームの開始
１７６ ＥＣＷ長＝０
１７８ チャネル統計を収集
１８０ チャネルの占有率が高いかそれとも低いか？
１８２ ＥＣＷを最小値ゼロまで減少
１８４ 最大値を超えないようにＥＣＷを増加
１８６ ＲＴＡセッションが依然としてアクティブであるか？
１８８ 次の統計更新時間が期限切れか？
１８９ 終了
【図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】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46A】
【図46B】
【図47】
【図48】
【図49】
【図50】
【図51A】
【図51B】
【図52】
【図53A】
【図53B】
【図54】
【図55】
【図56A】
【図56B】
【図57】
【図58】
【図59】
【図60】
【図61】
【図62】
【図63】
【図64】
【国際調査報告】