特表 2022-541620 リアルタイムアプリケーショントラフィックのための競合衝突回避

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-09-26

(54)【発明の名称】リアルタイムアプリケーショントラフィックのための競合衝突回避

(51)【国際特許分類】

   H04W 74/02 20090101AFI20220915BHJP

   H04W 84/12 20090101ALI20220915BHJP

【ＦＩ】

H04W74/02

H04W84/12

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022504259

(86)(22)【出願日】2020-07-09

(85)【翻訳文提出日】2022-01-21

(86)【国際出願番号】 IB2020056488

(87)【国際公開番号】W WO2021014263

(87)【国際公開日】2021-01-28

(31)【優先権主張番号】62/878,190

(32)【優先日】2019-07-24

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/714,179

(32)【優先日】2019-12-13

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】100092093

【弁理士】

【氏名又は名称】辻居 幸一

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100151987

【弁理士】

【氏名又は名称】谷口 信行

(72)【発明者】

【氏名】シン リャンシャオ

(72)【発明者】

【氏名】アブエルサウード モハメド

(72)【発明者】

【氏名】迫田 和之

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA14

5K067DD34

5K067EE02

5K067EE10

(57)【要約】

リアルタイムアプリケーション（ＲＴＡ）トラフィックと非ＲＴＡトラフィックとが共存するキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートする無線ローカルエリアネットワーク（ＷＬＡＮ）を介して動作する無線通信回路。リアルタイムアプリケーション（ＲＴＡ）トラフィックを送信するためのチャネル時間を、ＲＴＡパケットの予想到着時間に基づいてスケジュールし、このスケジュールを近隣局と共有する。チャネルを求めて競合する複数のＲＴＡトラフィックのチャネル競合衝突を防ぐために、近隣局のスケジュールに基づいてスケジュール時間を調整する。チャネルアクセス遅延時間及び競合衝突を低減しながらＲＴＡ送信をサポートする様々な機構について説明する。
【選択図】図１０

【特許請求の範囲】

【請求項1】

ネットワークにおける無線通信装置であって、
（ａ）自機の受信エリア内のローカルエリアネットワーク（ＷＬＡＮ）上の少なくとも１つの他の無線局と少なくとも１つのチャネルを介して無線で通信するように構成された無線通信回路と、
（ｂ）前記ＷＬＡＮ上で動作するように構成された局内の、前記無線通信回路に結合されたプロセッサと、
（ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリと、
を備え、
（ｄ）前記命令は、前記プロセッサによって実行された時に、
（ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィックと非ＲＴＡトラフィックとが共存するキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを介した通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させることと、
（ｉｉ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することと、
（ｉｖ）予想されるＲＴＡパケット到着時間に基づいて、リアルタイムアプリケーション（ＲＴＡ）トラフィックを送信するためのチャネル時間をスケジュールすることと、
（ｖ）スケジュールされたチャネル時間情報を近隣無線局と共有することと、
（ｖｉ）複数のＲＴＡトラフィックが前記チャネルを求めて競合している時にチャネル競合衝突を防ぐために、近隣無線局の少なくとも１つの前記スケジュールされたチャネル時間に基づいて、スケジュールされたチャネル時間を調整することと、
を含むステップを実行する、
ことを特徴とする装置。

【請求項2】

前記命令は、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別するように前記プロセッサによって実行された時に、事前ネゴシエーション情報又はパケットヘッダ情報を使用することに応答してＲＴＡトラフィックと非ＲＴＡトラフィックとを区別することを含むステップをさらに実行する、
請求項１に記載の装置。

【請求項3】

前記命令は、前記プロセッサによって実行された時に、前記無線局がアクセスポイント（ＡＰ）として動作し、スケジュールされたチャネル時間情報をそのビーコンにおいて発行して、前記スケジュールされたチャネル時間を自機の近隣無線局に広告することを含むステップをさらに実行する、
請求項１に記載の装置。

【請求項4】

前記命令は、前記プロセッサによって実行された時に、近隣無線局のスケジュールされたチャネル時間を受け取り、前記情報を前記無線局のＢＳＳのタイミング同期機能（ＴＳＦ）において解析することを含むステップをさらに実行する、
請求項１に記載の装置。

【請求項5】

前記命令は、前記プロセッサによって実行された時に、ＲＴＡトラフィックを送信するためのチャネル時間をスケジュールする前記プロセス中に、ＲＴＡパケット送信のための前記スケジュールされたチャネル時間中に非ＲＴＡパケットの送信を控えることを含むステップをさらに実行する、
請求項１に記載の装置。

【請求項6】

前記命令は、前記プロセッサによって実行された時に、チャネル競合衝突を回避しながら前記チャネルのための競合をいつ開始すべきであるかを決定するためにＲＴＡ内部タイマを利用することを含むステップをさらに実行する、
請求項１に記載の装置。

【請求項7】

前記命令は、ＲＴＡ内部タイマを利用する前記プロセッサによって実行された時に、前記ＲＴＡパケットの前記目標遅延時間に基づいて前記ＲＴＡ内部時間をランダム化することをさらに含む、
請求項７に記載の装置。

【請求項8】

前記命令は、前記プロセッサによって実行された時に、短い送信機動作期間（ＴＸＯＰ）で送信要求（ＲＴＳ）形態のシグナリングを利用して、ＲＴＡパケット送信のための将来的なチャネル時間を予約することを含むステップをさらに実行する、
請求項１に記載の装置。

【請求項9】

ネットワークにおける無線通信装置であって、
（ａ）自機の受信エリア内のローカルエリアネットワーク（ＷＬＡＮ）上の少なくとも１つの他の無線局と少なくとも１つのチャネルを介して無線で通信するように構成された無線通信回路と、
（ｂ）前記ＷＬＡＮ上で動作するように構成された局内の、前記無線通信回路に結合されたプロセッサと、
（ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリと、
を備え、
（ｄ）前記命令は、前記プロセッサによって実行された時に、
（ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィックと非ＲＴＡトラフィックとが共存するキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを介した通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させることと、
（ｉｉ）事前ネゴシエーション情報又はパケットヘッダ情報を使用することに応答して、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することと、
（ｉｖ）予想されるＲＴＡパケット到着時間に基づいて、リアルタイムアプリケーション（ＲＴＡ）トラフィックを送信するためのチャネル時間をスケジュールすることと、
（ｖ）スケジュールされたチャネル時間情報を近隣無線局と共有することと、
（ｖｉ）複数のＲＴＡトラフィックが前記チャネルを求めて競合している時にチャネル競合衝突を防ぐために、近隣無線局の少なくとも１つの前記スケジュールされたチャネル時間に基づいて、スケジュールされたチャネル時間を調整することと、
（ｖｉｉ）ＲＴＡトラフィック送信のためのチャネル時間をスケジュールする前記プロセス中に、ＲＴＡパケット送信のための前記スケジュールされたチャネル時間中に非ＲＴＡパケットの送信を控えることと、
を含むステップを実行する、
ことを特徴とする装置。

【請求項10】

前記命令は、前記プロセッサによって実行された時に、前記無線局がアクセスポイント（ＡＰ）として動作し、スケジュールされたチャネル時間情報をそのビーコンにおいて発行して、前記スケジュールされたチャネル時間を自機の近隣無線局に広告することを含むステップをさらに実行する、
請求項９に記載の装置。

【請求項11】

前記命令は、前記プロセッサによって実行された時に、近隣無線局のスケジュールされたチャネル時間を受け取り、前記情報を前記無線局のＢＳＳのタイミング同期機能（ＴＳＦ）において解析することを含むステップをさらに実行する、
請求項９に記載の装置。

【請求項12】

前記命令は、前記プロセッサによって実行された時に、チャネル競合衝突を回避しながら前記チャネルのための競合をいつ開始すべきであるかを決定するためにＲＴＡ内部タイマを利用することを含むステップをさらに実行する、
請求項９に記載の装置。

【請求項13】

前記命令は、ＲＴＡ内部タイマを利用する前記プロセッサによって実行された時に、前記ＲＴＡパケットの前記目標遅延時間に基づいて前記ＲＴＡ内部時間をランダム化することをさらに含む、
請求項１２に記載の装置。

【請求項14】

前記命令は、前記プロセッサによって実行された時に、短い送信機動作期間（ＴＸＯＰ）で送信要求（ＲＴＳ）形態のシグナリングを利用して、ＲＴＡパケット送信のための将来的なチャネル時間を予約することを含むステップをさらに実行する、
請求項９に記載の装置。

【請求項15】

ネットワークにおける無線通信の実行方法であって、前記装置は、
（ａ）リアルタイムアプリケーション（ＲＴＡ）トラフィックと非ＲＴＡトラフィックとが共存するキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを介した通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として無線通信回路を動作させることと、
（ｂ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することと、
（ｃ）予想されるＲＴＡパケット到着時間に基づいて、リアルタイムアプリケーション（ＲＴＡ）トラフィックを送信するためのチャネル時間をスケジュールすることと、
（ｄ）スケジュールされたチャネル時間情報を近隣無線局と共有することと、
（ｅ）複数のＲＴＡトラフィックが前記チャネルを求めて競合している時にチャネル競合衝突を防ぐために、近隣無線局の少なくとも１つの前記スケジュールされたチャネル時間に基づいて、スケジュールされたチャネル時間を調整することと、
を含むことを特徴とする方法。

【請求項16】

事前ネゴシエーション情報又はパケットヘッダ情報を使用することに応答して、ＲＴＡトラフィックと非ＲＴＡトラフィックとを区別することをさらに含む、
請求項１５に記載の方法。

【請求項17】

前記無線局がアクセスポイント（ＡＰ）として動作し、スケジュールされたチャネル時間情報をそのビーコンにおいて発行して、前記スケジュールされたチャネル時間を自機の近隣無線局に広告することを含む、
請求項１５に記載の方法。

【請求項18】

近隣無線局のスケジュールされたチャネル時間を受け取り、前記情報を前記無線局のＢＳＳのタイミング同期機能（ＴＳＦ）において解析することをさらに含む、
請求項１５に記載の方法。

【請求項19】

ＲＴＡトラフィックを送信するためのチャネル時間をスケジュールする前記プロセス中に、ＲＴＡパケット送信のための前記スケジュールされたチャネル時間中に非ＲＴＡパケットの送信を控えることをさらに含む、
請求項１５に記載の方法。

【請求項20】

チャネル競合衝突を回避しながら前記チャネルのための競合をいつ開始すべきであるかを決定するためにＲＴＡ内部タイマを利用することをさらに含む、
請求項１５に記載の方法。

【請求項21】

前記ＲＴＡパケットの前記目標遅延時間に基づいて前記ＲＴＡ内部時間をランダム化することをさらに含む、
請求項２０に記載の方法。

【請求項22】

短い送信機動作期間（ＴＸＯＰ）で送信要求（ＲＴＳ）形態のシグナリングを利用して、ＲＴＡパケット送信のための将来的なチャネル時間を予約することをさらに含む、
請求項１５に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

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

【0002】

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

【0003】

〔コンピュータプログラム付属書の引用による組み入れ〕
該当なし

【0004】

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

【0005】

本開示の技術は、一般に無線通信局に関し、具体的には、リアルタイムトラフィックと非リアルタイムトラフィックとの組み合わせを通信する無線ローカルエリアネットワーク（ＷＬＡＮ）局に関する。

【背景技術】

【0006】

キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を利用する現在の無線システムは、ネットワーク全体の高スループットには重点を置いているが、リアルタイムアプリケーション（ＲＴＡ）を適切にサポートする低遅延能力に欠けている。

【0007】

ＲＴＡは低遅延通信を必要とし、最善努力型通信を使用する。ＲＴＡから生成されるデータはＲＴＡトラフィックと呼ばれ、送信側局（ＳＴＡ）においてＲＴＡパケットとしてパケット化されるのに対し、非時間依存アプリケーションから生成されるデータは非ＲＴＡトラフィックと呼ばれ、送信側ＳＴＡにおいて非ＲＴＡパケットとしてパケット化される。これらのＲＴＡパケットは、一定期間内に配信できる場合にのみ有効であるため、パケット配信に対する高適時性要件（リアルタイム）に起因して低遅延時間を必要とする。

【発明の概要】

【発明が解決しようとする課題】

【0008】

ＳＴＡは、ランダムチャネルアクセスシナリオに起因して、各パケットを送信する前にチャネルアクセスを検知し、これを求めて競合する必要がある。短いチャネル競合時間を取得すればチャネルアクセスは加速するが、パケット衝突の可能性が高くなってしまう。パケット衝突に固有の遅延は、各再送に必要とされるチャネル競合時間に起因して依然として有意である。ＳＴＡは、パケット衝突を回避してパケット配信成功率を高めるために、パケット衝突後のさらに長いチャネル競合期間の後にパケットを再送し、これによってパケットがさらに遅延する。

【0009】

上記の点から、ＣＳＭＡ／ＣＡシステム又は同様の機構を利用する無線ネットワーク内には、時間依存的なＲＴＡパケットを通信することに伴う著しい遅延時間が存在することが分かる。

【0010】

従って、リアルタイムアプリケーション（ＲＴＡ）パケットの取り扱いを強化してパケット遅延時間を大幅に低減するというニーズが存在する。本開示は、このニーズを満たすとともに、これまでの技術を凌駕するさらなる利点をもたらすものである。

【課題を解決するための手段】

【0011】

トラフィックと非ＲＴＡトラフィックとが共存するキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）及び同様の機構をサポートしながら無線ローカルエリアネットワーク（ＷＬＡＮ）を介して通信するためのリアルタイムアプリケーション（ＲＴＡ）無線通信回路、方法及びプロトコル。近隣局とスケジューリング情報を共有することで、リアルタイムアプリケーション（ＲＴＡ）トラフィックを送信するためのチャネル時間が、予想されるＲＴＡパケット到着時間に基づいてスケジュールされる。スケジュール時間は、チャネルを求めて競合する複数のＲＴＡトラフィックのチャネル競合衝突を防ぐように、近隣局のスケジュールに基づいて調整される。

【0012】

本開示のＲＴＡパケットは、非ＲＴＡパケットよりも高い優先度を有する一方で、ＲＴＡパケット自体が優先度ランキングを有しており、優先度の高いパケットの方が優先度の低いＲＴＡパケットよりも早く送信される。このことは、全てのパケット送信間に公平なアクセスを提供することを目的とするＣＳＭＡ／ＣＡのランダムチャネルアクセススキームに反する。従来のＣＳＭＡ／ＣＡは、ＳＴＡ間の協調が存在しないような分散型チャネルアクセス機構であり、これによって複数のＳＴＡが同時にチャネルを求めて競合する確率が高くなり、従って競合衝突が生じることによって再送が必要になる。

【0013】

上記に照らして、本開示の装置、方法及びプロトコルは、ＲＴＡパケット送信中に遅延時間を低減して衝突を抑えることができる。

【0014】

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

【0015】

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

【図面の簡単な説明】

【0016】

【図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】本開示の少なくとも１つの実施形態に従って利用される、ＳＴＡがＲＴＡ－ＳＰにわたって予めチャネルを占有するために通常のＲＴＳフレームを送信する通信シーケンス図である。

【発明を実施するための形態】

【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】

４．６．３節で説明したように、ＡＰ及びＳＴＡは、これらの複数のＲＴＡ－ＳＰを互いに共有することができる。ＳＴＡ０、ＳＴＡ２及びＳＴＡ５は、ｎによって示す重複するＲＴＡ－ＳＰの数に基づいて競合ウィンドウサイズを設定する。値Ｄｉは、ＲＴＡ－ＳＰセッションｉの遅延時間要件を表し、競合ウィンドウサイズを決定（計算）するために使用することができる。競合ウィンドウサイズを計算する関数は、ｆ（ｎ，Ｄ_i）によって示される。例えば、１つの考えられる競合ウィンドウサイズの計算はｆ（ｎ，Ｄ_i）＝２ⁿ＋Ｄ_i／ｃであり、ｃは定数である。

【0151】

ＳＴＡは、ｆ（ｎ，Ｄ_i）によって計算される一定の競合ウィンドウサイズを使用してＲＴＡ－ＳＰ中のバックオフ時間を設定する。図３６に示すように、ＳＴＡ０は、ＲＴＡセッション０によって生成されるＲＴＡパケットを送信するために、自機の競合ウィンドウサイズをｆ（３，Ｄ_i）に設定する。バックオフ時間は、０～ｆ（ｎ，Ｄ_i）の一様な確率変数によって決定することができる。ＳＴＡは、パケットを送信する前に、常にバックオフ遅延だけ待機してチャネルにアクセスする。例えば、ＳＴＡ５は、ＲＴＡセッション５によって生成されるＲＴＡパケットを再送するために、チャネルを求めて競合するための同じ競合ウィンドウサイズｆ（３、Ｄ₅）を２倍に設定する。

【0152】

図３７に、競合ウィンドウを使用してＲＴＡパケット送信間の競合衝突を回避する別の考えられる解決策を示す実施形態例７５０を示す。この例は、重複するＲＴＡ－ＳＰの数及びその他のパラメータの変化に従って競合ウィンドウサイズを動的に計算できる点を除き、上記の例と同じものである。

【0153】

図示のように、ＲＴＡパケットの再送回数を表すＲＴＡパケットの再試行カウントをｒによって示す。競合ウィンドウサイズを計算する関数は、ｆ（ｎ，Ｄ_i，ｒ）で示される。例えば、１つの考えられる競合ウィンドウサイズの計算はｆ（ｎ，Ｄ_i，ｒ）＝２ⁿ＋Ｄ_i／ｃ×ｒであり、ｃは定数である。

【0154】

ＲＴＡ－ＳＰ７５２の最初には、同時にチャネルを求めて競合する３つのＲＴＡ－ＳＰ、具体的にはＳＴＡ０ ７５４、ＳＴＡ２ ７５６及びＳＴＡ５ ７６０に関連するＲＴＡ－ＳＰが存在し、これらのＳＴＡは、ｎ＝３に設定することによって自機の競合ウィンドウサイズを決定し、これらのバックオフは、７６２ａ、７６２ｂ及び７６２ｃであることが分かる。これらの全てのＲＴＡパケットは初めて送信されるので、関数ｆ（ｎ，Ｄ_i，ｒ）においてｒ＝１に設定する。図示のように、ＳＴＡ２が最初にチャネルアクセス権を獲得してＳＴＡ０ ７５４にＲＴＡパケット７６４を送信し始め、一方でＳＴＡ６ ７５８及びＳＴＡ５ ７６０は、マークＣＣＡ使用中７６６ａ、７６６ｂを設定する。ＳＴＡ０は、受信後にＳＴ２ ７５６にＡＣＫ７６８を送信する。

【0155】

この図では、次にＳＴＡ０ ７５４及びＳＴＡ５ ７６０がバックオフ７７０ａ、７７０ｂを使用してチャネルを求めて競合することが分かる。ＳＴＡ５は、チャネルアクセス権を獲得する第２のＳＴＡであってＳＴＡ６ ７５８にＲＴＡパケット７７２を送信し、ＳＴＡ０ ７５４及びＳＴＡ２ ７５６は、ＣＣＡ使用中７７４ａ、７７４ｂを設定する。ＡＣＫの不在によって示すように、ＳＴＡ６への初期送信は失敗している。

【0156】

次に、ＳＴＡ５は、ＲＴＡパケットを再送するためにチャネルを求めて再競合する必要がある。今回、ＳＴＡ５は、ＳＴＡ２がＲＴＡ－ＳＰを終了しており、チャネルを求めて競合しているＲＴＡ－ＳＰが２つしか存在しないことを認識している。ＳＴＡ５は、ｎ＝２及びｒ＝２である関数ｆ（ｎ，Ｄ_i，ｒ）を使用して競合ウィンドウサイズを計算する。従って、ＳＴＡ０及びＳＴＡ５の両方がバックオフ７６６ａ、７６６ｂを使用してチャネルを求めて競合することが分かる。ＳＴＡ５ ７６０は、チャネルを取得してＳＴＡ６ ７５８にパケット７７８を送信し、その時間中にＳＴＡ０及びＳＴＡ２はＣＣＡ使用中７８０ａ、７８０ｂを有する。ＳＴＡ６は、パケットの受信後にＡＣＫ７８２で応答する。

【0157】

この時点でＳＴＡ０のみがパケットを有しており、ｎ＝１及びｒ＝１であるバックオフ７８４の後に直ちにチャネルにアクセスしてＳＴＡ２にＲＴＡパケット７８６を送信し、一方でＳＴＡ５及びＳＴＡ６はＣＣＡ使用中７８８ａ、７８８ｂである。ＳＴＡ２ ７５６は、パケットの受信時にＳＴＡ０ ７５４にＡＣＫ７８９を返送する。

【0158】

図３８に、複数の重複するＲＴＡ－ＳＰ７９２において競合ウィンドウを使用してＲＴＡパケット送信間の競合衝突を回避する第３の解決策である実施形態例７９０を示す。この例では、ＳＴＡが競合に勝つ度に、このＳＴＡが１回のＲＴＡパケット送信を終了した後に全てのＳＴＡが自機のバックオフ時間をリセットしてチャネルのために再競合する。

【0159】

この例では、図３６に示すシナリオと同じシナリオについて検討する。競合ウィンドウサイズを計算する関数ｆ（ｎ，Ｄ_i）は、図３６に示すものと同じとすることができるが、要望に応じて図３７に示すような関数ｆ（ｎ，Ｄ_i，ｒ）又はその他の関数を使用することもできる。

【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】

１３０ 実施形態例
１３２ 送信側においてＲＴＳトラフィックを識別
１３４ ＭＡＣ層が上位層からトラフィックを受信
１３６ ＲＴＡトラフィックを識別するために上位層によって埋め込まれた情報を抽出
１３８ 事前ネゴシエーションによって作成されたＲＴＡセッション記録を調べる
１４０ 既存のＲＴＡセッションを発見？
１４２ トラフィックは非ＲＴＡである
１４４ トラフィックはＲＴＡである
１４６ 終了





テーブル１
送信側においてＲＴＡトラフィックを識別するためのヘッダ情報

テーブル２
ＲＴＡセッションステータスのリスト

テーブル３
チャネルリソースのための割り当てオプションのリスト

テーブル４
ＳＴＡ０におけるＲＴＡセッションステータス

割り当て：Flex＝柔軟、Fixed＝固定、Ran＝ランダム
セッションステータス：Act＝アクティブ



テーブル５
ＳＴＡ０におけるＳＴＡ間ＲＴＡセッションの追加

割り当て：Flex＝柔軟、Fixed＝固定、Algo＝アルゴリズム、Ran＝ランダム
セッションステータス：Act＝アクティブ



テーブル６
時点０ｍｓにおけるＳＴＡ０のＲＴＡチャネルスケジューリングテーブル

割り当て：Ran＝ランダム、RUn＝リソースユニット「ｎ」、SSn－空間ストリーム「ｎ」
アクティビティ：Rx＝受信、Tx＝送信、Arr＝準備中

テーブル７
ＳＴＡ５からのビーコン受信（Ｒｘ）後のＳＴＡ０におけるＲＴＡチャネルスケジューリングテーブル

割り当て：Ran＝ランダム、RUn＝リソースユニット「ｎ」、SSn－空間ストリーム「ｎ」
アクティビティ：Rx＝受信、Tx＝送信、Lis＝リスン中、Arr＝準備中



テーブル８
ＲＴＡ－ＳＰ調整後のＳＴＡ０におけるＲＴＡチャネルスケジューリングテーブル

割り当て：Ran＝ランダム、RUn＝リソースユニット「ｎ」、SSn－空間ストリーム「ｎ」
アクティビティ：Rx＝受信、Tx＝送信、Lis＝リスン中、Arr＝準備中

【図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】

【国際調査報告】